Voz : Calidad de voz

Voz sobre IP sobre links PPP con calidad de servicio (LLQ/ prioridad IP RTP , LFI, cRTP)

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (19 Mayo 2008) | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este ejemplo de configuración estudia una VoIP con Protocolo punto a punto (PPP) en una configuración de línea alquilada con ancho de banda bajo. Este documento comprende información técnica previa sobre las funciones configuradas, pautas de diseño y estrategias básicas de verificación y resolución de problemas.

Nota: Es importante notar que, en la configuración a continuación, los dos routers están adosados en una línea alquilada. Sin embargo, en la mayoría de las topologías, los routers activados por voz pueden existir en cualquier lugar. Usualmente, los routers de voz utilizan conectividad LAN con otros routers conectados a la WAN (en otras palabras, una línea PPP alquilada). Es importante porque si su router de voz no está conectado directamente vía PPP a una línea arrendada, todos los comandos de configuración WAN deben ser configurados en los routers conectados a la WAN, y no en los routers de voz, como muestran las siguientes configuraciones.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Las configuraciones presentadas en este documento fueron probadas con este equipo:

  • Dos Cisco 3640s con el Software Release 12.2.6a del ½ del ¿Â de Cisco IOSï (IP Plus)

  • La prioridad RTP de IP fue introducida en la versión 12.0(5)T del Cisco IOS.

  • Se presentó el LLQ en la versión 12.0(7)T del IOS de Cisco.

  • LFI se presentó en la Versión 11.3 del IOS de Cisco.

  • Las versiones del Cisco IOS más allá de 12.0.5T contienen las mejoras significativas en el rendimiento para el cRTP.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Pautas de diseño de QoS para links de VoIP over PPP

Esta sección proporciona las pautas de diseño para configurar el VoIP sobre las líneas arrendadas PPP (con énfasis en los links de baja velocidad). Existen dos requisitos básicos para una buena calidad de voz:

  • Requisitos de ancho de banda de link optimizados y diseñados adecuadamente.

Para garantizar los requisitos antedichos, hay varias guías de consulta importantes que deben ser seguidas:

Pauta Descripción
Prioridad estricta para tráfico de voz (prioridad IP RTP o LLQ) Método para proporcionar prioridad estricta al tráfico de voz.
Fragmentación y entrelazado de link (LFI) Puede ser un requerimiento obligatorio para links de baja velocidad.
Compresión RTP No se requiere para proporcionar una buena calidad de voz, pero reduce el consumo de ancho de banda de la llamada. La recomendación general con respecto a la compresión RTP es aplicarla después que tiene una configuración en funcionamiento con la buena calidad de voz (simplifica el troubleshooting).
Control de admisión de la llamada (CAC) No se trata en este documento. CAC se utiliza para controlar la cantidad de llamadas que pueden establecerse por el link. Por ejemplo, si el link PÁLIDO entre los dos gatewayes tiene el ancho de banda para llevar solamente dos llamadas VoIP, la admisión de una tercera llamada puede empeorar la Calidad de voz de las tres llamadas. Para obtener más información, consulte: Control de admisión de llamadas VoIP.

Para resumir, porque el link de PPP de baja velocidad con el router/los gatewayes como solamente fuentes de tráfico de voz dos características es obligatorio:

  1. Prioridad estricta para el tráfico de voz

  2. Fragmentación y entrelazado de link (LFI)

Prioridad estricta para tráfico de voz (prioridad IP RTP o LLQ)

A partir del Cisco IOS Software Release 12.2, hay dos métodos principales para proporcionar la prioridad estricta para el tráfico de voz:

  • Prioridad IP RTP (también denominada PQ/WFQ: Priority queue/Weighted Fair Queuing)

  • Datos en espera de la latencia baja (también llamados PQ/CBWFQ: Cola de prioridad/ Cola equilibrada ponderada basada en clase).

Prioridad IP RTP

La prioridad de IP RTP crea una cola de prioridad estricta para un conjunto de los flujos del paquete RTP que pertenecen a un rango de los puertos destino del User Datagram Protocol (UDP). Mientras que los puertos reales utilizados son negociados dinámicamente entre dispositivos extremos o gateways, todos los productos de VoIP de Cisco utilizan el mismo rango de puerto UDP (16384-32767). Una vez que el router reconoce el tráfico VoIP, lo pone en la cola de prioridad estricta. Cuando el priority queue está vacío, las otras colas de administración del tráfico se procesan según La prioridad IP RTP no se activa hasta que haya congestión en la interfaz. Esta imagen ilustra el funcionamiento de la prioridad IP RTP:

pq-wfq.gif

Nota: La prioridad de IP RTP permite el repartir del priority queue (PQ) cuando hay ancho de banda disponible en la cola predeterminada (WFQ), pero limpia estrictamente el contenido del priority queue cuando hay congestión en la interfaz.

Colocación en cola de baja latencia

El LLQ es una característica que proporciona un PQ estricto al Class-Based Weighted Fair Queuing (CBWFQ). LLQ habilita una única cola prioritaria estricta dentro de CBWFQ a nivel de clase. Con LLQ, los datos sensibles al retardo (en la PQ) se quitan de la cola y se envían primero. En VoIP con implementación de LLQ, el tráfico de voz se ubica en la cola prioritaria estricta.

La PQ es controlada para garantizar que las colas justas no se saturen de ancho de banda. Cuando usted configura el PQ, usted especifica en el kbps la cantidad máxima de ancho de banda disponible al PQ. Cuando la interfaz se encuentra congestionada, se mantiene PQ hasta que la carga alcanza el valor configurado en Kbps en la sentencia de prioridad. El exceso de tráfico se suprime para evitar que la función legacy priority-group deje de alimentar las colas de menor prioridad.

/image/gif/paws/7111/llq.gif

Este método es más complejo y flexible que prioridad IP RTP. La elección entre los métodos debe basarse en los patrones de tráfico en su red real y sus necesidades verdaderas.

LLQ vs. prioridad RTP IP

Esta tabla resume las diferencias principales entre el LLQ y la prioridad de IP RTP y proporciona algunas guías de consulta de cuándo utilizar cada método.

Low Latency Queuing (LLQ) Prioridad IP RTP
Coincidencia del tráfico de voz según:
  • Listas de acceso (para rango de puertos UDP, direcciones de host, campos ToS del encabezado de IP: Precedencia IP, DSCP y más)
  • Rango de puerto IP RTP
  • Campos de ToS (Tipo de servicio) de IP: DCSP y/p precedencia IP
  • Protocolos e interfaces de entrada
  • Todos los criterios de concordancia válidos utilizados en CBWFQ
Ventajas:
  • Mayor flexibilidad en la coincidencia de tráfico y en cómo es dirigido a la PQ estricta y a CBWFQ
  • Puede configurar las clases adicionales para garantizar el ancho de banda para el otro tráfico por ejemplo: Video y señalización VoIP.
Desventajas:
  • Configuración compleja
Coincidencia del tráfico de voz según:
  • De acuerdo con el rango de puertos RTP UDP: 16384-32767
Ventajas:
  • Configuración simple
Desventajas:
  • Tráfico RTCP (Señalización de VoIP) servido en cola WFQ.

    Nota: El protocolo RTP utiliza RTCP (protocolo real time control) para controlar la entrega de paquetes RTP. Mientras que los puertos RTP utilizan los números par, los puertos RTCP utilizan los números impares en el rango de 16384-32767. La prioridad RTP de IP coloca a los puertos RTP en la PQ mientras que los puertos RTCP son colocados en la cola equilibrada ponderada predeterminada.

  • Sirve el tráfico de VoIP en el PQ, pero cualquier otro tráfico que necesite el trato preferencial y la garantía de ancho de banda se sirve en el WFQ. Mientras WFQ puede diferenciar flujos con pesos (basados en la precedencia IP), no puede asegurar una garantía de ancho de banda para ningún flujo.
Pautas
  • La elección entre ellos debe basarse en los patrones de tráfico en su red real y sus necesidades reales.
  • Si usted necesita proporcionar la prioridad estricta a su tráfico de voz, y el otro tráfico se puede tratar como tipo único (datos), después la prioridad de IP RTP hace un buen trabajo para su red con una Configuración simple.
  • Si usted planea dar prioridad al tráfico de voz basado en los criterios con excepción de los puertos UDP (por ejemplo DiffServ PHB), el LLQ es necesario.

Para más información sobre la correlación y las diferencias de los métodos para colocación en cola, refiera a la descripción general de la administración de congestión.

Pautas de configuración de LLQ

Siga estas guías de consulta para configurar el LLQ:

  1. Cree un mapa de la clase para el tráfico de VoIP y defina los criterios de concordancia

    Estos comandos explican cómo completar esta tarea:

    maui-voip-sj(config)#class-map ?
           WORD 		class-map name
           match-all 	Logical-AND all matching statements under this classmap
           match-any 	Logical-OR all matching statements under this classmap
    maui-voip-sj(config)#class-map match-all voice-traffic 
    
    !-- Choose a descriptive class_name. 
    
    
    maui-voip-sj(config-cmap)#match ?  
    access-group         Access group  
    any                  Any packets  
    class-map            Class map  
    cos                  IEEE 802.1Q/ISL class of service/user priority values  
    destination-address  Destination address  
    input-interface      Select an input interface to match  
    ip                   IP specific values  
    mpls                 Multi Protocol Label Switching specific values  
    not                  Negate this match result  
    protocol             Protocol 
    qos-group            Qos-group  
    source-address       Source address
    
    !-- In this example, the access-group matching option is used for its 
    !-- flexibility (it uses an access-list)
    
    
    maui-voip-sj(config-cmap)#match access-group ?
      <1-2699>  Access list index  name      Named Access List
    maui-voip-sj(config-cmap)#match access-group 102
    
    
    !-- Now, create the access-list to match the class-map access-group:
    
    maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776
    
    
    !-- Safest and easiest way is to match with UDP port range 16384-32767
    !-- This is the port range Cisco IOS H.323 products utilize to transmit 
    !-- VoIP packets.
    
    

    Estas listas de acceso se pueden también utilizar para hacer juego el tráfico de voz con el comando match access-group:

    access-list 102 permit udp any any precedence critical 
    !-- This list filters traffic based on the IP packet TOS: Precedence field.  
    !-- Note: Ensure that other non-voice traffic does NOT uses the 
    !-- same precedence value.              
    
    access-list 102 permit udp any any dscp ef
    !-- In order for this list to work, ensure that VoIP packets are tagged with 
    !-- the dscp ef code before they exit on the LLQ WAN interface. 
    !-- For more information on DSCP refer to: 
    !-- Implementing Quality of Service Policies with DSCP
    !-- Note: If endpoints are not trusted on their packet marking, you can mark
    !-- incoming traffic by applying an inbound service policy on an inbound
    !-- interface. This procedure is out of the scope of this doc. 
        
    Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
    
    !-- This access-list can be used in cases where the VoIP devices cannot 
    !-- do precedence or dscp marking and you cannot determine the 
    !-- VoIP UDP port range. 
    
    

    Éstos son otros métodos de compatibilización que se pueden utilizar en vez de los grupos de acceso:

    • Comienzo con la Versión 12.1.2.T del IOS de Cisco, para LLQ se implementa la funcionalidad de Prioridad IP RTP. Esta función hace coincidir los contenidos de las clases de prioridad en los puertos UDP configurados y está sujeta a la limitación de servir sólo a los puertos pares del PQ.

      class-map voice 
        match ip rtp 16384 16383 
      
      
    • Estos dos métodos actúan bajo suposición que los paquetes de VoIP son marcados en los host de origen, o correspondido con y marcado en el router antes de aplicar la operación de LLQ saliente.

      class-map voice 
        match ip precedence 5 
      

      o

      class-map voice 
        match ip dscp ef 
      

      Nota: A partir de la versión 12.2.2T del IOS, los pares de marcado VoIP pueden marcar paquetes portadores de voz y de señalización antes de la operación LLQ. Esto permite una forma escalable de marcado e identificación de paquetes VoIP a través de valores de código DSCP para LLQ.

  2. Realice un mapa de clase para la señalización de VoIP y defina un criterio de coincidencia (opcional).

    Estos comandos explican cómo completar esta tarea:

     class-map voice-signaling
      match access-group 103
     !
     access-list 103 permit tcp any eq 1720 any 
     access-list 103 permit tcp any any eq 1720
    

    Nota: Las llamadas VoIP pueden establecerse mediante H.323, SIP, MGCP o Skinny (Protocolos propietarios utilizados por Cisco CallManager). El ejemplo anterior presupone H.323 Fast Connect. Esta lista sirve como referencia para los puertos usados por la señalización VoIP/los canales de control:

    • H.323/H.225 = TCP 1720

    • H.323/H.245 = TCP 11xxx (Conexión estándar)

    • H.323/H.245 = TCP 1720 (Conexión rápida)

    • H.323/H.225 RAS = TCP 1719

    • Skinny = TCP 2000-2002 (CM Encore)

    • ICCP = TCP 8001-8002 (CM Encore)

    • MGCP = UDP 2427, TCP 2428 (CM Encore)

    • SIP= UDP 5060, TCP 5060 (configurable)

  3. Cree una correspondencia de políticas y asocíese al VoIP class-maps

    El propósito de la correspondencia de políticas es definir cómo los recursos del link se comparten o se asignan a las diversas clases de la correspondencia. Estos comandos explican cómo completar esta tarea:

    maui-voip-sj(config)#policy-map VOICE-POLICY
    
    !-- Choose a descriptive policy_map_name.
    
    
    maui-voip-sj(config-pmap)#class voice-traffic
    maui-voip-sj(config-pmap-c)#priority ?  
    <8-2000000>  Kilo Bits per second
    
    !-- Configure the voice-traffic class to the strict priority
    !-- Queue (priority command) and assign the bandwidth.
    
    
    maui-voip-sj(config-pmap)#class voice-signaling
    maui-voip-sj(config-pmap-c)#bandwidth 8
    
    !-- Assign 8 Kbps to the voice-signaling class
    
    
    maui-voip-sj(config-pmap)#class class-default
    maui-voip-sj(config-pmap-c)#fair-queue 
    
    !-- The remaining data traffic is treated as Weighted Fair Queue
    
    

    Nota: Aunque sea posible hacer cola los diversos tipos de tráfico en tiempo real al PQ, Cisco recomienda que usted dirige solamente el tráfico de voz a él. El tráfico en tiempo real, tal como vídeo, podría introducir la variación en el retardo (el PQ es un (Primero en Entrar, Primero en Salir FIFO) - First In First Out - cola). El tráfico de voz requiere que la demora sea invariable para evitar la fluctuación.

    Nota: La suma de los valores para la prioridad y las sentencias de ancho de banda necesita ser el inferior o igual 75 por ciento del ancho de banda de link. De lo contrario, la política de servicio no puede ser asignada al link (para ver los mensajes de error, asegúrese de que la consola de registro esté habilitada para el acceso a la consola y de que el monitor de terminal esté habilitado para el acceso a Telnet).

    Nota: Al configurar el VoIP sobre un link de kbps 64 para soportar dos llamadas de voz, es común afectar un aparato el más de 75 por ciento (48Kbps) del ancho de banda de link al PQ. En estos casos, usted puede utilizar el comando max-reserved-bandwidth 80 de aumentar el ancho de banda disponible al 80 por ciento (51 kbps).

    Para obtener más información acerca de los comandos de ancho de banda y de prioridad, vea Comparación de los comandos de ancho de banda y de prioridad de una política de servicios de QoS.

  4. Permiso LLQ: Aplicar el mapa de políticas a la interfaz WAN saliente

    Estos comandos explican cómo completar esta tarea:

    maui-voip-sj(config)#interface multilink 1
    maui-voip-sj(config-if)#service-policy output VOICE-POLICY
    
    !-- In this scenario (MLPPP LFI), the service policy is applied to
    !-- the Multilink interface.
    
    
    

Pautas de configuración de prioridad RTP IP

Para configurar el uso de la prioridad de IP RTP estas guías de consulta:

  • Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth
    
    
    Comando Descripción
    starting-rtp-port-number
    
    Límite inferior del puerto UPD. El número de puerto menor al cual se envían los paquetes. Para VOIP, configure este valor en 16384.
    port-number-range
    
    El rango de los puertos de destino UDP. Un número, que agregó al empezar-RTP-puerto-número, rinde el número del puerto más alto UDP. Para VOIP, configure este valor en 16383 (32767 - 16384 = 16383).
    bandwidth
    
    Máximo de ancho de banda permitido (kbps) en la cola de prioridad. Fije este número según el número de llamadas simultáneas los soportes de sistema.

    Configuración de ejemplo:

    interface Multilink1
    
       !--- Some output omitted
    
       bandwidth 64
       ip address 172.22.130.2 255.255.255.252
       ip tcp header-compression
       fair-queue
       no cdp enable
       ppp multilink
       ppp multilink fragment-delay 10
       ppp multilink interleave
       multilink-group 1
       ip rtp header-compression iphc-format
       ip rtp priority 16384 16383 45
    

Fragmentación de enlaces e intercalado (LFI): PPP de links múltiples

Mientras que 1500 bytes es un tamaño normal para paquetes de datos, un paquete VoIP típico (que transporta tramas de voz G.729) puede pesar alrededor de 66 bytes (20 bytes de carga útil de voz, 6 bytes de encabezado de capa 2, 20 bytes de encabezado RTP & UDP y 20 bytes de encabezado IP).

Ahora, imagine un link de línea arrendada de 56Kbps en el que coincidan la voz y el tráfico de datos. Si un paquete de voz está listo para ser serializado en el momento en que se comienza a transmitir un paquete de datos sobre el link, estaremos en presencia de un problema. El paquete de la voz sensible al retraso tiene que esperar 214 milisegundos antes de ser transmitido (tarda 214 milisegundos para serializar un paquete de bytes 1500 sobre un link 56Kbps).

Como puede verse, los grandes paquetes de datos puede retrasar desfavorablemente la entrega de los paquetes de voz pequeños y así disminuir la calidad de voz. Hacer fragmentos de estos paquetes de datos grandes en los más pequeños y la interpolación de los paquetes de voz entre los fragmentos reduce el jitter y el retardo. La función de fragmentación y entrelazado del link (LFI) del IOS de Cisco cumple los requisitos de entrega en tiempo real de VoIP. Esta imagen ilustra la operación del LFI:

lfi.gif

Como se muestra en la Tabla 1, la cantidad de retraso en la serialización (el tiempo real que transcurre para ubicar los bits en una interfaz) introducido en links WAN de baja velocidad puede ser significativo, considerando que el retraso unidireccional de extremo a extremo de destino no tendría que exceder los 150 ms. (Recomendación ITU-T el G.114 especifica 150 de punta a punta unidireccionales máximos del ms.)

Retraso de serialización del cuadro 1. para los diversos tamaños de trama en el ancho de banda del retraso de serialización = del tamaño de trama de los links de baja velocidad (bits) /link (BPS)

1 byte 64 bytes Bytes 128 Bytes 256 512 bytes 1024 bytes 1500 bytes
56 kbps 143 us 9 ms ms 18 36 ms 72 ms 144 ms ms 214
64 kbps 125 us 8 ms 16 ms 32 m 64 ms 126 ms ms 187
kbps 128 62.5 us 4 ms 8 ms 16 ms 32 m 64 ms ms 93
256 kbps 31 us 2 ms 4 ms 8 ms 16 ms 32 m ms 46
512 kbps 15.5 nosotros 1 ms 2 ms 4 ms 8 ms 16 ms 32 m
768 kbps 10 us 640 us 1.28 ms 2.56 ms 5.12 ms 10.24 ms 15 ms
1536 kbps 5 nosotros 320 us 640 us 1.28 ms 2.56 ms 5.12 ms 7.5 ms

Nota: Para las Aplicaciones de voz, el retardo de serialización recomendado (por la base del salto) es el ms 10 y no debe exceder al ms 20.

El tamaño del fragmento del enlace se puede configurar en milisegundos (mseg) con el comando ppp multilink fragment-delay. LFI requiere que los ppp multilink se configure en la interfaz con ppp multilink interleave activado. Para más información sobre configurar el LFI, refiera a la sección de este documento.

Nota: En los casos en que hay más de una conexión T1 (768 Kbps) a la mitad, no es necesario contar con la característica de fragmentación. (Usted todavía, sin embargo, necesita un mecanismo de Calidad de servicio (QoS), tal como LLQ o prioridad de IP RTP). La mitad de T1 ofrece suficiente ancho de banda como para permitir el ingreso y la salida de los paquetes de voz de la cola sin problemas de retraso. Además, quizás no necesite Compresión para el protocolo de tiempo real (cRTP), el cual ayuda a conservar el ancho de banda al comprimir los encabezados RTP IP, en caso de media T1.

Protocolo de transporte en tiempo real comprimido (cRTP)

Nota: No se necesita cRTP para asegurar la buena calidad de voz. Es una función que reduce el consumo del ancho de banda. Configure cRTP una vez que se hayan cumplido con las demás condiciones y la calidad de voz sea satisfactoria. Este procedimiento puede ahorrar tiempo de resolución de problemas al aislar potenciales inconvenientes de cRTP.

De acuerdo con el RFC 2508, la característica de la Compresión de cabecera RTP comprime la encabezado IP/UDP/RTP desde 40 bytes a 2 o 4 bytes, reduciendo el consumo de ancho de banda innecesario. Es un plan de compresión por salto; por lo tanto, cRTP debe configurarse en ambos extremos del link (a menos que la opción pasiva esté configurada). Para configurar el cRTP, utilice este comando en el nivel de la interfaz:

  • Router(config-if)#ip rtp header-compression [passive]

Dado que el proceso de compresión puede ser intensivo para la CPU, la compresión del encabezado de RTP se implementa en el fast switching y en los trayectos de CEF switching como en la versión 12.0.(7)T de IOS. Estas implementaciones están a veces quebradas, y entonces la única forma que trabaja será conmutada procesado. Cisco sólo recomienda utilizar cRTP con links de menos de 768 Kbps, a menos que el router esté ejecutando a una velocidad baja de utilización de CPU Supervise la utilización de la CPU del router y desactive cRTP si supera el 75%.

Nota: Cuando usted configura el comando ip rtp header-compression, el router agrega el comando ip tcp header-compression a la configuración por abandono. Esto se utiliza para comprimir los paquetes TCP/IP de las encabezados. La compresión del encabezamiento es determinado útil en las redes con un gran porcentaje de los pequeños paquetes, tales como ésos que soportan muchas conexiones Telnet. La técnica de la Compresión de cabecera TCP, descrita completamente en el RFC 1144, se soporta en las líneas seriales usando el HDLC o la encapsulación PPP.

Para comprimir los encabezados TCP sin habilitar el cRTP, utilice este comando:

  • Router(config-if)#ip tcp header-compression [passive] 

Para más información: Protocolo Compressed Real-time Transport

Otros consejos para la reducción del ancho de banda

  • Utilice el codificador/los decodificadores (codificador-decodificador) del low-bit-rate en las piernas de la llamada VoIP; Se recomienda G.729 (8 kbps). (Éste es el codificador-decodificador predeterminado en los VoIP dial-peer). Para configurar diverso codecs utilice el comando router(config-dial-peer)-codec bajo el dial-peer del VoIP deseado.

  • Aunque la multifrecuencia de tono dual (DTMF) normalmente se transporta con precisión cuando se utilizan codecs de voz de alta velocidad de bits tales como G.711, los codecs de baja velocidad de bits (tales como G.729 y G.723.1) están altamente optimizados para patrones de voz y tienden a distorsionar los tonos DTMF. Este enfoque puede ocasionar problemas de acceso a los sistemas de respuesta de voz interactiva (IVR). El comando dtmf relay soluciona este problema de distorsión DTMF mediante el transporte de los tonos DTMF “fuera de la banda” o separados de la secuencia de voz codificada. Si se utiliza el codecs del low-bit-rate (G.729, G.723), gire el relé dtmf bajo el VoIP dial-peer.

  • Una conversación típica puede contener el porciento de silencio 35-50. Al utilizar la Detección de actividad de voz (VAD), se eliminan los paquetes de silencio. Para las hojas de operación (planning) del ancho de banda de VoIP, asuma que el VAD reduce el ancho de banda por el 35 por ciento. VAD está configurado de forma predeterminado en pares de marcado VoIP. Para habilitar o inhabilitar el VAD, utilice los comandos router(config-dial-peer)-vad y router(config-dial-peer)- no vad bajo el dial-peers del VoIP deseado.

Diagrama de la red

/image/gif/paws/7111/mlppp.gif

Configuraciones

maui-voip-sj (Cisco 3640)
version 12.2service timestamps debug datetime msec

!-- < Some output omitted >

!
hostname maui-voip-sj
!
ip subnet-zero
!
no ip domain-lookup
!

!-- Definition of the voice signaling and traffic class maps
!-- "voice-traffic" class uses access-list 102 for its matching criteria.
!-- "voice-signaling" class uses access-list 103 for its matching criteria.


Class-map match-all voice-signaling
  match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

!-- The policy-map defines how the link resources are assigned 
!-- to the different map classes. In this configuration, strict priority
!-- queue is assigned to "voice-traffic" class with (based on ACL in 
!-- class voice) with max bandwidth = 45 Kbps. 

policy-map VOICE-POLICY
  class voice-traffic
    priority 48
 class voice-signaling
   bandwidth 8

    !-- Assigns a queue for "voice-signaling" traffic that ensures 8 Kbps.
    !-- Note that this is optional and has nothing to do with good voice 
    !-- quality, but rather a way to secure signaling.

  class class-default
   fair-queue

!-- The class-default class is used to classify traffic that does 
    !-- not fall into one of the defined classes.
    !-- The fair-queue command associates the default class WFQ queueing.

!
call rsvp-sync
!

!-- Note that MLPPP is strictly an LFI mechanism. It does not
!-- bundle multiple serial interfaces to the same virtual interface as 
!-- the name stands (This bundling is done for data and NOT recommended 
!-- for voice). The end result may manifest itself as jitter and no audio.

interface Multilink1
 ip address 172.22.130.1 255.255.255.252
 ip tcp header-compression iphc-format
 service-policy output VOICE-POLICY

  !-- LLQ is an outbound operation and applied to the outbound WAN 
  !-- interface.

 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
  
!-- The configured value of 10 sets the fragment size such that 
  !-- all fragments have a 10 ms maximum serialization delay.

 ppp multilink interleave
 multilink-group 1
  ip rtp header-compression iphc-format
!
interface Ethernet0/0
 ip address 172.22.113.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 128

  !-- the bandwidth command needs to be set correctly for the 
  !-- right fragment size to be calculated.

 no ip address
 encapsulation ppp
 clockrate 128000
 ppp multilink
 multilink-group 1

  !-- This command links the multilink interface to the physical 
  !-- serial interface.

!
router eigrp 69 
 network 172.22.0.0
 auto-summary
 no eigrp log-neighbor-changes
!

!-- access-list 102 matches VoIP traffic based on the UDP port range. 
!-- Both odd and even ports are put into the PQ.
!-- access-list 103 is used to match VoIP signaling protocol. In this
!-- case, H.323 V2 with fast start feature is used.

access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
voice-port 1/0/1
!
voice-port 1/1/0
!
voice-port 1/1/1
!
dial-peer cor custom
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:172.22.130.2

maui-voip-austin (Cisco 3640)
version 12.2
service timestamps debug datetime msec
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
!
ip subnet-zero
!
class-map match-all voice-signaling
  match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
policy-map voice-policy
  class voice-signaling
   bandwidth 8
  class voice-traffic
    priority 48
  class class-default
   fair-queue
!
interface Multilink1
 bandwidth 128
 ip address 172.22.130.2 255.255.255.252
 ip tcp header-compression iphc-format
 service-policy output voice-policy
 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
 multilink-group 1
 ip rtp header-compression iphc-format

 !-- Configure cRTP after you have a working configuration.
 !-- This helps isolate potential cRTP issues.

!
Interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation ppp
 no ip mroute-cache
 ppp multilink
 multilink-group 1
!
router eigrp 69
 network 172.22.0.0
 auto-summary
 no eigrp log-neighbor-changes
!
access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
voice-port 1/0/1
!
voice-port 1/1/0
!
voice-port 1/1/1
!
dial-peer cor custom
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:172.22.130.1

Comandos de verificación y resolución de problemas

Antes de intentar cualesquiera comandos debug, refiera a la información importante en los comandos Debug. Para más información sobre los comandos enumerados aquí, vea la sección del ejemplo de resultado de show y debug de este documento.

Comandos de interfaz:

  • muestre la interfaz [serial | multilink] — utilice este comando de marcar ese estatus de la interfaz serial. Aseegurese el serial y la interfaz de links múltiples está ascendente y abierta.

  • Resolución de problemas de líneas en serie

Comandos LFI:

  • show ppp multilink — Este comando muestra información sobre los agrupamientos de PPP de enlaces múltiples.

  • debug ppp multilink fragments—Este comando de depuración muestra información acerca de fragmentos individuales de enlaces múltiples y eventos de entrelazado. Esta salida de comando también identifica el número de secuencia del paquete y de los tamaños del fragmento.

Comandos de la prioridad de RTP LLQ/IP:

  • interface# del show policy-map interface multilink — Este comando es muy útil para considerar la operación LLQ y para considerar cualquier descenso en el PQ. Para obtener más información sobre los diversos campos de este comando, consulte Cómo funcionan los contadores de paquetes en los resultados del comando show policy-map interface.

  • show policy-map policy_map_name — Este comando visualiza la información sobre la configuración de correspondencia de políticas.

  • show queue interface-type interface-number — Este listas de comandos configuración para colocación en cola y estadísticas justas para una interfaz particular.

  • Prioridad del debug — Este comando debug visualiza los eventos de la espera de prioridad y muestra si la caída ocurre en esta cola. También refiera a los descensos del resultado de Troubleshooting con la cola prioritaria.

  • show class-map class_name — Este comando visualiza la información sobre el configuración class-map.

  • muestre la voz activa de la llamada — Este comando es útil de marcar para saber si hay paquetes perdidos en el DSP llano.

Otros comandos/referencias

Problemas conocidos:

Pautas:

Aquí están algunos pasos básicos para Troubleshooting, una vez que el link PPP es en servicio (MLPPP, fragmentación, interpolando):

  1. muestre la voz activa de la llamada — Utilice para marcar para saber si hay los paquetes perdidos en el DSP llano.

  2. interfaz de la demostración — Utilice para marcar para saber si hay la línea de serie general o para interconectar los problemas. Las interrupciones en la interfaz todavía no significan que exista un problema, pero es preferible eliminar el paquete de la cola de baja prioridad antes de que llegue a la cola de la interfaz.

  3. show policy-map interface — Utilice para marcar para saber si hay los descensos y configuración para colocación en cola LLQ. No debe señalar ninguna descensos que violen la directiva.

  4. compresión del encabezamiento de la demostración IP RTP — Utilice para marcar para saber si hay los problemas del específico del cRTP.

Resultado de ejemplo de show y debug

 

!-----------------------------------------------
 !-----------------------------------------------
 !---- To capture sections of this output, the LLQ PQ bandwidth 
 !---- was lowered and large data traffic was placed
 !---- on the link to force some packets drops.
 !-----------------------------------------------
 !-----------------------------------------------

 !---- Packet Drop Verification (During an Active Call)

 !--- Assuming your ppp link is up and running, the first step of voice 
 !--- quality problems verification is to check for lost packets 
 !--- at the DSP. Note: Use the show call active voice command 
 !--- NOT show call active voice brief


 maui-voip-austin#show call active voice
 Total call-legs: 2


 !--- Indicates that the connection is established and both legs exist


 GENERIC:
          SetupTime=155218260 ms
          Index=1
          PeerAddress=5000
          PeerSubAddress=
          PeerId=2
          PeerIfIndex=13
          LogicalIfIndex=0
          ConnectTime=155218364
          CallDuration=00:00:27
          CallState=4

 !--- indicates that it is the active call
 !--- (#define D_callActiveCallState_active 4).
          CallOrigin=2
          ChargedUnits=0
          InfoType=2
          TransmitPackets=365
          TransmitBytes=7300
          ReceivePackets=229
          ReceiveBytes=4580

 VOIP:

 !--- For this call, this was the terminating gateway.
 !--- At this gateway, the call started at the VoIP leg.

          ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          RemoteIPAddress=172.22.130.1

 !--- Indicates from which IP address the RTP stream is originating.

          RemoteUDPPort=18778
          RemoteSignallingIPAddress=172.22.130.1

 !--- Indicates from which IP address signaling messages are coming.

          RemoteSignallingPort=11010
          RemoteMediaIPAddress=172.22.130.1
          RemoteMediaPort=18778
          RoundTripDelay=50 ms
          SelectedQoS=best-effort
          tx_DtmfRelay=inband-voice
          FastConnect=TRUE

 Separate H245 Connection=FALSE

 H245 Tunneling=FALSE

 SessionProtocol=cisco
 SessionTarget=
 OnTimeRvPlayout=4570
 GapFillWithSilence=20 ms
 GapFillWithPrediction=1840 ms
 GapFillWithInterpolation=0 ms
 GapFillWithRedundancy=0 ms
 HiWaterPlayoutDelay=70 ms
 LoWaterPlayoutDelay=51 ms
 ReceiveDelay=51 ms
 LostPackets=90
 EarlyPackets=1
 LatePackets=0

 !--- Indicates the precense of jitter, lost packets, or 
 !--- corrupted packets.

 VAD = enabled
 CoderTypeRate=g729r8
 CodecBytes=20

 GENERIC:
          SetupTime=155218260 ms
          Index=2
          PeerAddress=6000
          PeerSubAddress=
          PeerId=1
          PeerIfIndex=12
          LogicalIfIndex=6
          ConnectTime=155218364
          CallDuration=00:00:34
          CallState=4
          CallOrigin=1
          ChargedUnits=0
          InfoType=2
          TransmitPackets=229
          TransmitBytes=4580
          ReceivePackets=365
          ReceiveBytes=7300
 TELE:
          ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          TxDuration=35360 ms
          VoiceTxDuration=730 ms
          FaxTxDuration=0 ms
          CoderTypeRate=g729r8
          NoiseLevel=-46
          ACOMLevel=2
          OutSignalLevel=-58
          InSignalLevel=-42
          InfoActivity=2
          ERLLevel=7
          SessionTarget=
          ImgPages=0Total call-legs: 2



 !----------------------------------------------------------
 !--- Interface Verification

 !--- Make sure you see this:
 !--- LCP Open, multilink Open: Link control protocol (LCP) open statement 
 !--- indicates that the connection is establish.
 !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link.


 maui-voip-sj#show interface multilink 1

 Multilink1 is up, line protocol is up
   Hardware is multilink group interface
   Internet address is 172.22.130.1/30
   MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation PPP, loopback not set
   Keepalive set (10 sec)
   DTR is pulsed for 2 seconds on reset
   LCP Open, multilink Open
   Open: IPCP
   Last input 00:00:01, output never, output hang never
   Last clearing of "show interface" counters 00:25:20
   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91
   Queueing strategy: weighted fair
   Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves)
      Conversations  0/3/32 (active/max active/max total)
      Reserved Conversations 1/1 (allocated/max allocated)
      Available Bandwidth 38 kilobits/sec
   5 minute input rate 0 bits/sec, 0 packets/sec
   5 minute output rate 0 bits/sec, 0 packets/sec
      8217 packets input, 967680 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      13091 packets output, 1254194 bytes, 0 underruns
      0 output errors, 0 collisions, 0 interface resets
      0 output buffer failures, 0 output buffers swapped out
      0 carrier transitions
----------------------------------------------------------------

!-- Note: There are no drops at the interface level.
!-- All traffic that is dropped due to policing, is 
!-- dropped before it gets to the interface queue.


maui-voip-austin#show interface
 serial 0/0Serial0/0 is up, line protocol is up
  Hardware is QUICC Serial
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 49/255, rxload 47/255
  Encapsulation PPP, loopback not set
  Keepalive set (10 sec)
  LCP Open, multilink Open
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:22:08
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair  [suspended, using FIFO]
  FIFO output queue 0/40, 0 drops
  5 minute input rate 24000 bits/sec, 20 packets/sec
  5 minute output rate 25000 bits/sec, 20 packets/sec     4851 packets input, 668983 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4586 packets output, 657902 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up


!-----------------------------------
!--- LLQ Verification



maui-voip-austin#show policy-map int multilink 1
 Multilink1
 Service-policy output: voice-policy

 Class-map: voice-signaling (match-all)

!--- This is the class for the voice signaling traffic.

         10 packets, 744 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 42
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 10/744
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: voice-traffic (match-all)

!--- This is PQ class for the voice traffic.

         458 packets, 32064 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 40
         Bandwidth 15 (kbps) Burst 375 (Bytes)
!--- Notice that the PQ bandwidth was lowered to force packet drops.
         (pkts matched/bytes matched) 458/29647
         (total drops/bytes drops) 91/5890
!--- Some packets were dropped. In a well designed link,
!--- there should be no (or few) drops of the PQ class.

 Class-map: class-default (match-any)
         814 packets, 731341 bytes
         5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 32
         (total queued/total drops/no-buffer drops) 0/0/0

!---------------------------------------------


!--- Verify the class-map configuration

maui-voip-austin#show class-map
 Class Map match-all voice-signaling (id 2)
   Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-all voice-traffic(id 3)
         Match access-group 102


!--- Verify the access-lists of the class-maps

maui-voip-austin#show access-lists
Extended IP access list 102
    permit udp any any range 16384 32767 (34947 matches)
Extended IP access list 103
    permit tcp any eq 1720 any (187 matches)
    permit tcp any any eq 1720 (86 matches)


!--- Verify the policy-pap configuration

maui-voip-austin#show policy-map voice-policy
  Policy Map voice-policy
    Class voice-signaling
      Weighted Fair Queueing
            Bandwidth 8 (kbps) Max Threshold 64 (packets)
    Class voice-traffic
      Weighted Fair Queueing
            Strict Priority
            Bandwidth 50 (kbps) Burst 1250 (Bytes)
    Class class-default
      Weighted Fair Queueing
            Flow based Fair Queueing Max Threshold 64 (packets)
---------------------------

!--- Debug priority command provides immediate feedback in case 
!--- of VoIP packet drops.
!--- The output below shows the error message when VoIP packets 
!--- are being dropped from the strict priority queue. 

maui-voip-sj#debug priority

priority output queueing debugging is on
maui-voip-sj#
Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0
Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0
Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0

-------------------------------------------------------------------



!--- Link Fragmentation and Interleaving (LFI) Verification



maui-voip-sj#show ppp multilink

!--- Verify the fragmentation size and multilink

Multilink1, bundle name is maui-voip-austin
         Bundle up for 00:08:04
         0 lost fragments, 0 reordered, 0 unassigned
         0 discarded, 0 lost received, 1/255 load
         0x6D received sequence, 0x6E sent sequence
         Member links: 1 active, 0 inactive (max not set, min not set)
         Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight

  !--- Notice the fragmentation size is 160 Bytes. The link is configured with a 
  !--- bandwidth of 128 kbps and a serialization delay of 10 msec. 
  !--- Fragment Size (in bits) = bandwidth * serialization delay.
  !--- Note: There are 8 bits in one byte.


-------------------------------------------------------


!--- Link Fragmentation and Interleaving (LFI) Verification 

!--- Testing Multilink PPP Link LFI
!--- This output displays fragmentation and interleaving information
!--- when the the 128kbps PPP link is loaded with big data and VoIP packets.

maui-voip-sj#debug ppp multilink fragments
Multilink fragments debugging is on

1w3d: Se0/0 MLP: O frag 800004CF size 160
1w3d: Se0/0 MLP: O frag 000004D0 size 160
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
1w3d: Mu1 MLP: Packet interleaved from queue 40
1w3d: Se0/0 MLP: O ppp IP (0021) size 64
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
1w3d: Se0/0 MLP: O frag 400004D1 size 106
1w3d: Se0/0 MLP: O ppp IP (0021) size 64
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct
1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct
1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
-------------------------------------------------------------------


!--- Sample output of show ip rtp header-compression command

maui-voip-sj#show ip tcp header-compression
TCP/IP header compression statistics:  Interface Multilink1:
    Rcvd:    10 total, 6 compressed, 0 errors
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    10 total, 7 compressed,
             230 bytes saved, 99 bytes sent
             3.32 efficiency improvement factor
    Connect: 16 rx slots, 16 tx slots,
             2 long searches, 1 misses 0 collisions, 0 negative cache hits
             90% hit ratio, five minute miss rate 0 misses/sec, 0 max

----------------------------------------------------------------------


!--- This command displays information of the voip dial-peers command.

maui-voip-sj#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `6000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation state is up,
        incoming called-number = `', connections/maximum = 0/unlimited,
        application associated:
        type = voip, session-tMarget = `ipv4:172.22.130.2',
        technology prefix:
        ip precedence = 0, UDP checksum = disabled,
        session-protocol = cisco, req-qos = best-effort,
        acc-qos = best-effort,
        fax-rate = voice,   payload size =  20 bytes
        codec = g729r8,   payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled,
        Connect Time = 283, Charged Units = 0,
        Successful Calls = 1, Failed Calls = 0,
        Accepted Calls = 1, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 93793451.

-------------------------------------------------------------------------

!---The CPU utilization of the router should not exceed the 50-60 percent
!--- during any five-minute interval.

maui-voip-austin#show processes cpu
CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   1         148    310794          0  0.00%  0.00%  0.00%   0 Load Meter
   2          76        23       3304  0.81%  0.07%  0.01%   0 Exec



Información Relacionada


Document ID: 7111