Voz : Calidad de voz

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

19 Mayo 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (2 Febrero 2006) | Comentarios

Contenidos

Introducción
Requisitos previos
     Requisitos
     Componentes utilizados
     Convenciones
Pautas de diseño de QoS para enlaces de VoIP over PPP
     Prioridad estricta para tráfico de voz (prioridad IP RTP o LLQ)
     Pautas de configuración de LLQ
     Instrucciones de configuración de prioridad RTP IP
     Fragmentación y entrelazado de enlace (LFI): PPP de enlaces múltiples
     Protocolo Compressed Real-time (cRTP)
     Otros consejos para la reducción del ancho de banda
Diagrama de la red
Configuraciones
Comandos de verificación y resolución de problemas
Resultado de ejemplo de show y debug
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Esta configuración, que se ofrece a modo de ejemplo, estudia una configuración de VoIP con Protocolo punto a punto (PPP) en una línea arrendada de ancho de banda baja. Este documento incluye información técnica complementaria sobre las funciones configuradas, las pautas de diseño y estrategias básicas de verificación y resolución de problemas.

Nota: Es importante tener en cuenta que en la configuración a continuación, los dos routers están adosados a través de una línea arrendada. Sin embargo, en la mayoría de las topologías, los routers habilitados para voz pueden situarse en cualquier lugar. Normalmente, los routers de voz, utilizan una conectividad LAN para conectarse a otros routers que están conectados a la WAN (es decir, una línea arrendada PPP). Esto es importante porque si los routers de voz no se conectan directamente a través de PPP sobre una línea arrendada, todos los comandos de configuración WAN se deben configurar en los routers que estén conectados a la WAN, y no en los routers de voz, tal como se muestra en las configuraciones a continuación.

Requisitos previos

Requisitos

No hay requisitos específicos para este documento.

Componentes utilizados

Las configuraciones que se presentan en este documento se han probado con el siguiente equipo:

  • Dos routers 3640 de Cisco con la versión 12.2.6a (IP Plus) del software Cisco IOS®.

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

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

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

  • Las versiones posteriores a la versión 12.0.5T del software Cisco IOS contienen mejoras importantes con respecto al desempeño del cRTP.

Convenciones

Si desea obtener más información sobre las convenciones utilizadas en este documento, consulte las Convenciones sobre consejos técnicos de Cisco.

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

Esta sección contiene pautas de diseño para la configuración de VoIP sobre líneas arrendadas PPP (con énfasis en los enlaces de baja velocidad). Existen dos requisitos básicos para obtener una buena calidad de voz:

Para garantizar los requisitos anteriores, se debe seguir un número de pautas importantes:

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 de enlace y entrelazado (LFI)

Puede ser un requisito obligatorio para enlaces de baja velocidad.

Compresión RTP

No es necesaria para garantizar 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 utilizarla después de tener una configuración que funcione correctamente con una buena calidad de voz (hace más fácil la resolución de problemas).

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 sobre el enlace. Por ejemplo, si el enlace WAN entre las dos gateways dispone de un ancho de banda que permite ejecutar sólo dos llamas VoIP, la admisión de una tercera llamada podría afectar la calidad de voz de las tres llamadas. Para obtener más información, consulte: Control de admisión de llamadas VoIP.

En resumen, para los enlaces PPP de baja velocidad en los que el router o gateways sean los únicos orígenes de tráfico de voz, existen dos funciones obligatorias:

  1. Prioridad estricta para tráfico de voz

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

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

En el caso de la versión 12.4(7) del software Cisco IOS, existen dos métodos principales para proporcionar prioridad estricta para tráfico de voz:

  • Prioridad IP RTP (también denominada PQ/WFQ: Cola prioritaria / Colocación en cola (equilibrada ponderada)

  • Low Latency Queuing (también se lo conoce como PQ / CBWFQ: Cola prioritaria / Cola equilibrada basada en clase).

Prioridad IP RTP

La prioridad IP RTP crea una cola de prioridad estricta para un conjunto de flujos de paquetes RTP que pertenecen a un rango de puertos de destino de Protocolo de datagrama de usuario (UDP). Mientras que la negociación de los puertos que se utilizan realmente se realiza de manera dinámica entre dispositivos finales o gateways, todos los productos de VoIP de Cisco utilizan el mismo rango de puertos UDP (16384-32767). Una vez que el router reconoce el tráfico VoIP, lo coloca en la cola de prioridad estricta. Cuando la cola de prioridad está vacía, se procesan las otras colas de acuerdo al estándar Weighted Fair Queuing (WFQ). La prioridad IP RTP no se activa hasta que exista alguna congestión en la interfaz. Esta imagen demuestra cómo funciona la prioridad IP RTP:

pq-wfq.gif

Nota: La prioridad IP RTP permite ejecutar ráfagas en la cola prioritaria (PQ) cuando existe ancho de banda disponible en la cola predeterminada (WFQ), pero controla estrictamente el contenido de la cola prioritaria cuando existe algún tipo de congestión en la interfaz.

Colocación en Low Latency Queuing

LLQ es una función que proporciona una PQ estricta para la Marcación de paquetes equilibrada basada en clase (CBWFQ). LLQ habilita una única PQ estricta dentro de CBWFQ en el nivel de clase. Con LLQ, los datos sensibles al retraso (en la PQ) se quitan de la cola y se envían en primer lugar. En una configuración VoIP con implementación de LLQ, el tráfico de voz se coloca en la PQ estricta.

La PQ se controla para garantizar que no le falte ancho de banda a las colas justas. Al configurar la PQ, especifique en Kbps la cantidad máxima de ancho de banda disponible para dicha PQ. Cuando la interfaz se encuentra congestionada, la PQ se procesa hasta que la carga alcanza el valor configurado en Kbps en la sentencia de prioridad. El exceso de tráfico se descarta para evitar que la función legacy priority-group de Cisco deje las colas de menor prioridad sin ancho de banda.

llq.gif

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

LLQ vs. prioridad RTP IP

Esta tabla proporciona un resumen de las principales diferencias entre LLQ y la prioridad IP RTP y ofrece algunas pautas sobre cuándo utilizar cada método.

Colocación en 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 o precedencia IP

  • Protocolos e interfaces de entrada

  • Todos los criterios de concordancia válidos utilizados en CBWFQ

Ventajas:

  • Mayor flexibilidad sobre cómo se hace coincidir el tráfico y cómo éste se dirige a la PQ estricta y CBWFQ.

  • Se pueden configurar clases adicionales para garantizar el ancho de banda para otro tipo de tráfico como, por ejemplo, Video y señalización VoIP.

Desventajas:

  • Configuración compleja

Coincidencia del tráfico de voz según:

  • Basado en el rango de puerto 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 el Protocolo de control en tiempo real (RTCP) para controlar la entrega de los paquetes RTP. Mientras que los puertos RTP utilizan números pares, los puertos RTCP utilizan números impares que se incluyen en el rango de 16384 a 32767. La prioridad IP RTP coloca puertos RTP en la PQ mientras que los puertos RTCP se procesan en la cola equilibrada ponderada predeterminada.

  • Sirve tráfico VoIP en la PQ, pero cualquier otro tráfico que requiera tratamiento preferencial y garantía de ancho de banda se procesa en WFQ. Si bien WFQ puede diferenciar flujos mediante ponderaciones (según la precedencia IP), no puede garantizar ancho de banda para ningún flujo.

Pautas

  • La elección entre ellos debe basarse en los patrones de tráfico en la red real y las necesidades verdaderas del usuario.

  • Si necesita proporcionar prioridad estricta al tráfico de voz, y que el otro tráfico sea tratado como datos de tipo simple, la prioridad IP RTP es una buena opción para la red con una configuración sencilla.

  • Si tiene la intención de dar prioridad al tráfico de voz en función de otros criterios que no sean los puertos UDP (por ejemplo DiffServ PHB), necesitará una LLQ.

Para obtener más información sobre la correlación y las diferencias que existen entre los métodos de almacenamiento en cola, consulte la sección Descripción general de la administración de congestión.

Pautas de configuración de LLQ

Siga estas pautas para configurar la LLQ.

  1. Cree una correspondencia de clases para el tráfico VoIP y defina el criterio de concordancia.

    Los comandos siguientes explican cómo realizar 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
    !-- Elija un class_name (nombre de clase) descriptivo. 
    
    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
    !--En este ejemplo, la opción de concordancia de grupos de acceso se utiliza
    !--por su flexibilidad (usa una lista de acceso)
    
    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
    
    !--Ahora, cree la lista de acceso de modo que coincida con el grupo de acceso de correspondencias de clases:
    maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776
    
    !-- La forma más fácil y segura es coincidir con el rango del puerto UDP 16384-32767
    !-- Este es el rango de puerto que utilizan los productos H.323 del software Cisco IOS para transmitir
    !-- paquetes VoIP.
    

    Estas listas de acceso también se pueden utilizar para que hagan coincidir 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:
    !-- Implementación de políticas de Calidad de Servicio (QoS) con DSCP
    !-- Nota: 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
    !-- Esta lista de acceso se puede utilizar en los casos en que los dispositivos VoIP
    !-- no puedan llevar a cabo la precedencia o la marcación dscp y el usuario no puede determinar
    !--el rango de puerto VoIP UDP. 
    

    Estos son otros métodos de concordancia que se pueden usar en lugar de los grupos de acceso:

    • A partir de la versión 12.1.2.T del software Cisco IOS, se implementa la funcionalidad de prioridad IP RTP para LLQ. Esta función hace coincidir el contenido de las clases de prioridad en los puertos UDP configurados y está sujeta a la limitación de procesar sólo los puertos pares de la PQ.

      class-map voice
        match ip rtp 16384 16383
      
    • Estos dos métodos funcionan bajo la suposición de que los paquetes VoIP se marcan en los hosts de origen, o bien se hace coincidir y se marcan en el router antes de aplicar la operación de salida LLQ.

      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. Cree una correspondencia de clases para la señalización de VoIP y defina un criterio de concordancia (opcional).

    Los comandos siguientes explican cómo realizar 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 que utilizan la señalización VoIP y 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 asóciela a las correspondencias de clases de VoIP.

    El propósito de la correspondencia de políticas es definir cómo se comparten o asignan los recursos de enlaces a las diferentes clases de correspondencia. Los comandos siguientes explican cómo realizar esta tarea:

    maui-voip-sj(config)#policy-map VOICE-POLICY
    !-- Elija un nombre de correspondencia de políticas descriptivo.
    
    maui-voip-sj(config-pmap)#class voice-traffic
    maui-voip-sj(config-pmap-c)#priority ?
    <8-2000000>  Kilo Bits per second
    !--Configure la clase de tráfico de voz con la cola de prioridad estricta
    !--(comando de prioridad) y asigne el ancho de banda.
    
    maui-voip-sj(config-pmap)#class voice-signaling
    maui-voip-sj(config-pmap-c)#bandwidth 8
    !-- Asigne 8 Kbps a la clase de señalización de voz
    
    maui-voip-sj(config-pmap)#class class-default
    maui-voip-sj(config-pmap-c)#fair-queue 
    !-- El tráfico de datos restante se trata como Cola equilibrada
    

    Nota: Aunque es posible poner en cola a los distintos tipos de tráfico en tiempo real en la PQ, Cisco recomienda que dirija hacia ella sólo el tráfico de voz. El tráfico en tiempo real, como el video, podría introducir una variación en el retraso (la PQ es una cola tipo FIFO, Primero en entrar, primero en salir). El tráfico de voz requiere que la demora sea invariable para evitar la fluctuación.

    Nota: La suma de los valores para las sentencias priority y bandwidth debe ser inferior o igual al 75 por ciento del ancho de banda del enlace. De lo contrario, service-policy no se podrá asignar al enlace (para ver los mensajes de error, asegúrese de que el comando logging console esté habilitado para el acceso a la consola y de que el comando terminal monitor esté habilitado para el acceso a Telnet).

    Nota: Cuando VoIP se configura sobre un enlace de 64 Kbps para soportar dos llamadas de voz, es normal asignar a la PQ más del 75 por ciento (48 Kbps) del ancho de banda del enlace. En estos casos, es posible utilizar el comando max-reserved-bandwidth 80 para aumentar el ancho de banda disponible al 80 por ciento (51 Kbps).

    Para obtener más información sobre los comandos bandwidth y priority, consulte la sección Comparación de los comandos bandwidth y priority de una política de servicio de QoS..

  4. Habilite LLQ: aplique la correspondencia de políticas a la interfaz WAN saliente

    Los comandos a continuación explican cómo realizar esta tarea:

    maui-voip-sj(config)#interface multilink 1
    maui-voip-sj(config-if)#service-policy output VOICE-POLICY
    !-- En este escenario (MLPPP LFI), se aplica la política de servicio a
    !--la interfaz de enlaces múltiples.
    

Instrucciones de configuración de prioridad RTP IP

Utilice las pautas siguientes para configurar la prioridad IP RTP:

  • 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 más bajo al cual se envían los paquetes. Para VoIP, configure este valor en 16383.

    port-number-range

    El rango de puertos de destino UDP. Un número que si se suma a starting-rtp-port-number, da como resultado el número más alto de puerto 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. Configure este número de acuerdo con el número de llamadas simultáneas que soporta el sistema.

    Configuración de ejemplo:

    interface Multilink1
    !--- Se ha omitido parte del resultado
       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
       Prioridad ip rtp 16384 16383 45
    

Fragmentación y entrelazado de enlace (LFI): PPP de enlaces 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 ser de alrededor de 66 bytes (20 bytes de carga útil de voz, 6 bytes de encabezado de capa 2, 20 bytes de encabezado RTP y UDP y 20 bytes de encabezado IP).

Ahora, imagine un enlace de línea arrendada de 56 Kbps en el que existe conjuntamente tráfico de voz y de datos. Si un paquete de voz está listo para ser serializado en el momento en que se comienza la transmisión de un paquete de datos sobre el enlace, estaremos en presencia de un problema. El paquete de voz sensible al retraso debe esperar 214 mseg antes de poder ser transmitido (se tardan 214 mseg para serializar un paquete de 1500 bytes sobre un enlace de 56 Kbps).

Como puede verse, los paquetes de datos de gran tamaño pueden retrasar desfavorablemente la entrega de los paquetes de voz de pequeño tamaño y así disminuir la calidad de voz. La fragmentación de estos paquetes de datos de gran tamaño en paquetes más pequeños y el entrelazado de paquetes de voz entre los fragmentos reduce la fluctuación y el retraso. La función Fragmentación y entrelazado de enlace (LFI) del software Cisco IOS cumple los requisitos de entrega en tiempo real de VoIP. Esta imagen demuestra el funcionamiento de LFI:

lfi.gif

Como se muestra en la Tabla 1, la cantidad de retraso en la serialización (el tiempo real que transcurre para colocar los bits en una interfaz) introducido en enlaces WAN de baja velocidad puede ser significativa, teniendo en cuenta que el retraso unidireccional de extremo a extremo de destino no debería superar los 150 ms (las recomendaciones ITU-T G.114 especifican un máximo unidireccional de extremo a extremo de 150 ms).

Tabla 1. Retraso de serialización para distintos tamaños de tramas en baja velocidad Retraso de serialización de enlace = tamaño de la trama (bits)/ancho de banda del enlace (bps)

1 Byte

64 bytes

128 bytes

256 bytes

512 bytes

1024 bytes

1500 bytes

56 Kbps

143 us

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 Kbps

125 us

8 ms

16 ms

32 m

64 ms

126 ms

187 ms

128 Kbps

62.5 us

4 ms

8 ms

16 ms

32 m

64 ms

93 ms

256 Kbps

31 us

2 ms

4 ms

8 ms

16 ms

32 m

46 ms

512 Kbps

15.5 us

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 us

320 us

640 us

1,28 ms

2,56 ms

5,12 ms

7,5 ms

Nota: Para las aplicaciones de voz, el retraso de serialización recomendado (por salto) es 10 ms y no debe superar los 20 ms.

El tamaño del fragmento del enlace se puede configurar en milisegundos (mseg) con el comando ppp multilink fragment-delay. LFI requiere que el comando ppp multilink se configure en la interfaz con el comando ppp multilink interleave activado. Si desea obtener más información acerca de la configuración de LFI, consulte 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. (Sin embargo, es probable que aún necesite un mecanismo de Calidad de Servicio (QoS), como por ejemplo, LLQ o prioridad 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 Compressed Real-time (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.

Según RFC 2508, la función de compresión de encabezados RTP comprime el encabezado IP/UDP/RTP de 40 bytes a 2 ó 4 bytes, disminuyendo el consumo innecesario del ancho de banda. Es un plan de compresión por salto, por lo tanto, cRTP debe configurarse en ambos extremos del enlace (a menos que la opción passive esté configurada). Para configurar cRTP, utilice el comando siguiente en el nivel de la interfaz:

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

Dado que el proceso de compresión puede suponer un uso intensivo de la CPU, la compresión del encabezado RTP se implementa en los trayectos de conmutación rápida y de conmutación CEF como en la versión 12.0.(7)T de IOS. En algunas ocasiones, estas implementaciones están dañadas, y por lo tanto, la única manera de hacer funcionar esta operación es mediante el cambio de procesos. Cisco sólo recomienda utilizar cRTP con enlaces de menos de 768 Kbps, a menos que el router se ejecute con un bajo índice de uso de la CPU. Supervise la utilización que hace el router de la CPU e inhabilite cRTP si supera el 75 por ciento.

Nota: Al configurar el comando ip rtp header-compression, el router agregará el comando ip tcp header-compression a la configuración de forma predeterminada. Esto se utiliza para comprimir los paquetes TCP/IP de los encabezados. La compresión de los encabezados es de especial utilidad en las redes que tienen un alto porcentaje de paquetes pequeños, como por ejemplo, aquellas que soportan muchas conexiones Telnet. La técnica de compresión de encabezados TCP, que se describe en detalle en RFC 1144, se soporta en las líneas seriales que utilizan encapsulación HDLC o PPP.

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

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

Para obtener más información: Protocolo de transporte en tiempo real comprimido.

Otros consejos para la reducción del ancho de banda

  • Utilice codificadores y decodificadores (CODEC) de baja velocidad binaria en los tramos de llamadas VoIP. Se recomienda G.729 (8 Kbps). (Se trata del códec predeterminado en los pares de marcado VoIP). Para configurar distintos códecs, utilice el comando router(config-dial-peer)#codec bajo el par de marcado 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 el 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 utilizan códecs de baja velocidad de bits (G.729, G.723), active el comando dtmf relay bajo el par de marcado VoIP.

  • Una conversación típica puede contener de un 35 a un 50 por ciento de silencio. Al utilizar la Detección de actividad de voz (VAD), se eliminan los paquetes de silencio. Para la planificación del ancho de banda de VoIP, debe suponer que VAD reducirá el ancho de banda en un 35 por ciento. VAD está configurado de forma predeterminado en pares de marcado VoIP. Para habilitar o inhabilitar VAD, utilice los comandos router(config-dial-peer)#vad y router(config-dial-peer)# no vad para el par de marcado VoIP deseado.

Diagrama de la red

mlppp.gif

Configuraciones

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec
!--- < Se ha omitido parte del resultado >
!
hostname maui-voip-sj
!
ip subnet-zero
!
no ip domain-lookup
!
!-- Definición de la señalización de voz y de la correspondencia de clases de tráfico
!-- la clase "tráfico de voz" utiliza la lista de acceso 102 para su criterio de concordancia.
!-- la clase "señalización de voz" utiliza la lista de acceso 103 para su criterio de concordancia.
Class-map match-all voice-signaling
  match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
!-- La correspondencia de políticas define cómo se asignan los recursos del enlace
!-- a las diferentes clases de correspondencia. En esta configuración, la cola de prioridad
!-- estricta se asigna a la clase "tráfico de voz" (según la ACL en
!-- voz de clase) con un máximo de ancho de banda = 45 Kbps. 
policy-map VOICE-POLICY
  class voice-traffic
    priority 48
 class voice-signaling
   bandwidth 8
    !-- Asigna una cola para el tráfico de "señalización de voz" que garantiza 8 Kbps.
    !-- Tenga en cuenta que esto es opcional y no tiene nada que ver con una buena calidad de voz
    !-- sino más bien con una señalización segura.
  class class-default
   fair-queue
!-- La clase predeterminada se utiliza para clasificar el tráfico que no
    !-- pertenece a ninguna de las clases definidas.
    !-- El comando fair-queue asocia la puesta en cola WFQ predeterminada de la clase.
!
call rsvp-sync
!
!-- Tenga en cuenta que MLPPP es estrictamente un mecanismo LFI. No es necesario
!--que agrupe múltiples interfaces seriales a la misma interfaz virtual como
!-- dice su nombre (este agrupamiento se lleva a cabo para datos y NO se recomienda
!-- para voz). El resultado final podría manifestarse como fluctuaciones sin 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 es una operación de salida y se aplica a la interfaz WAN de
  !-- salida.
 no cdp enable
ppp multilink
 ppp multilink fragment-delay 10
  !-- El valor configurado de 10 establece el tamaño del fragmento de tal modo que
  !-- todos los fragmentos tienen un retraso máximo de serialización de 10 ms.
 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
  !-- es necesario configurar el comando bandwidth correctamente para
  !-- que se pueda calcular el tamaño de fragmento adecuado.
 no ip address
 encapsulation ppp
 clockrate 128000
 ppp multilink
 multilink-group 1
  !-- Este comando enlaza la interfaz de enlaces múltiples a la
  !-- interfaz serial física.
!
router eigrp 69
 network 172.22.0.0
 auto-summary
 no eigrp log-neighbor-changes
!
!-- la lista de acceso 102 coincide con el tráfico de VoIP según el rango de puertos UDP.
!-- Tanto los puertos pares como los impares se colocan en la PQ.
!--la lista de acceso 103 se utiliza para asociar el protocolo de señalización VoIP. En este
!-- caso, se utiliza H.323 V2 con la función de inicio rápido.
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 una vez que disponga de una configuración que funcione.
 !-- Esto ayuda a aislar los problemas potenciales de cRTP.
!
Interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 128
 sin dirección de IP
 encapsulación 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 la ejecución de cualquier comando de depuración, consulte la sección Información importante sobre los comandos de depuración. Para obtener más información sobre los comandos que aquí se enumeran, consulte la sección Resultado de ejemplo de show y debug en este documento.

Comandos de interfaz:

  • show interface [serial | multilink]: utilice este comando para comprobar el estado de la interfaz serial. Asegúrese de que las interfaces seriales y de enlaces múltiples estén abiertas y en funcionamiento.

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

Comandos LFI:

  • show ppp multilink: este comando muestra la información sobre agrupamientos para 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. Este resultado de comando también identifica el número de secuencia del paquete y el tamaño de los fragmentos.

Comandos de prioridad LLQ / IP RTP

  • show policy-map interface multilink interface#: este comando resulta de gran utilidad para ver la operación LLQ y cualquier pérdida en la PQ. Para obtener más información sobre los diversos campos de este comando, consulte Introducción a los contadores de paquetes en el resultado de show policy-map interface.

  • show policy-map policy_map_name: este comando muestra información sobre la configuración de la correspondencia de políticas.

  • show queue interface-type interface-number: este comando enumera la configuración de colas justas y las estadísticas para una interfaz en particular.

  • Debug priority: este comando de depuración muestra eventos de cola prioritaria e indica si ocurren caídas en esta cola. Consulte también Resolución de problemas de paquetes descartados en colas de salida con organización de cola según la prioridad.

  • show class-map class_name: este comando muestra información sobre la configuración de la correspondencia de clases.

  • show call active voice: este comando es de gran utilidad a la hora de comprobar los paquetes perdidos en el nivel DSP.

Otros comandos/referencias

Problemas conocidos:

Pautas:

A continuación se incluyen algunos pasos básicos para la resolución de problemas, una vez que el enlace ppp esté funcionando (MLPPP, Fragmentación, Entrelazado):

  1. show call active voice: use este comando para comprobar los paquetes perdidos en el nivel DSP.

  2. show interface: use este comando para comprobar si existen problemas con la línea serial o con la interfaz. 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: use este comando para comprobar si existen pérdidas en LLQ y la configuración de la cola. No debe indicar ninguna pérdida que represente una infracción de la política.

  4. show ip rtp header-compression utilice este comando para comprobar si existen problemas específicos a cRTP.

Resultado de ejemplo de show y debug

 
!-----------------------------------------------
 !-----------------------------------------------
 !---- Para capturar secciones de este resultado, el ancho de banda LLQ PQ
 !--- se disminuyó y el tráfico de datos grandes se colocó
 !--- en el enlace para forzar algunas caídas de paquetes.
 !-----------------------------------------------
 !-----------------------------------------------

 !---- Verificación de la caída de paquetes (durante una llamada activa)

 !--- Suponiendo que el enlace ppp está activo y en funcionamiento, el primer paso en la verificación
 !--- de los problemas de la calidad de voz es buscar si existen paquetes caídos
 !--- en el DSP. Nota:: Use el comando show call active voice
 !--- NO el comando show call active voice brief

 maui-voip-austin#show call active voice
 Tramos totales de llamada: 2
 !--- Indica que la conexión está establecida y que existen ambos tramos
 GENERIC:
          SetupTime=155218260 ms
          Index=1
          Dirección de entidad par=5000
          PeerSubAddress=
          PeerId=2
          PeerIfIndex=13
          LogicalIfIndex=0
          ConnectTime=155218364
          CallDuration=00:00:27
          CallState=4
 !--- indica que es la llamada activa
 !--- (#define D_callActiveCallState_active 4).          CallOrigin=2
          ChargedUnits=0
          InfoType=2
         TransmitPackets=365
          TransmitBytes=7300
          Paquetes recibidos=229
          Bytes recibidos=4580

 VOIP:
!--- Para esta llamada, se trata de la gateway de terminación.
 !--- En esta gateway, la llamada comenzó en el tramo VoIP.
          ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          RemoteIPAddress=172.22.130.1
 !--- Indica desde qué dirección IP se origina el flujo RTP.
          RemoteUDPPort=18778
          RemoteSignallingIPAddress=172.22.130.1
 !--- Indica desde qué dirección IP provienen los mensajes de señalización.
          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
 !--- Indica la presencia de fluctuaciones, paquetes perdidos o
 !--- paquetes dañados.
 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


 !----------------------------------------------------------
 !--- Verificación de la interfaz

 !---Asegúrese de que se muestra lo siguiente:
 !--- LCP abierto, enlaces múltiples abierto: Sentencia abierta de protocolo de control de enlaces (LCP)
 !---indica que la conexión está establecida.
 !--- Abierto:IPCP. Indica que el tráfico IP se puede transmitir a través de un enlace PPP.

 maui-voip-sj#show interface multilink 1

Multilink1 está activada, el protocolo de línea está activado
   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
   PPP de encapsulado, loopback not set
   Keepalive set (10 sec)
   DTR is pulsed for 2 seconds on reset
   LCP abierto, enlaces múltiples abierto:
   Abierto: 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
----------------------------------------------------------------
!-- Nota: No existen pérdidas en el nivel de la interfaz.
!-- Todo el tráfico que se pierde debido a la vigilancia se
!-- descarta antes de llegar a la cola de interfaz.

maui-voip-austin#show interface
 serial 0/0Serial0/0 está activado, el protocolo de línea está activado
  Hardware is QUICC Serial
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 49/255, rxload 47/255
  PPP de encapsulado, loopback not set
  Keepalive set (10 sec)
  LCP abierto, enlaces múltiples abiertos:
  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); Caídas totales de resultados: 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

!-----------------------------------
!--- Verificación LLQ

maui-voip-austin#show policy-map int multilink 1
 Multilink1
 Service-policy output:  política de voz

 Correspondencia de clases: señalización de voz (coinciden todos)
!--- Se trata de la clase para el tráfico de señalización de voz.
         10 packets, 744 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 103
         Cola equilibrada ponderada
         Output Queue: Conversation 42
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts coincidentes/bytes coincidentes) 10/744
         (profundidad/caídas totales/caídas sin búfer) 0/0/0

 Mapa de clases: tráfico de voz (coinciden todos)
!--- Se trata de la clase de PQ para el tráfico de voz.
         458 packets, 32064 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 102
         Weighted Fair Queueing
         Prioridad estricta
         Output Queue: Conversation 40
         Ancho de banda 15 (Kbps) Burst 375 (Bytes)
!--- Notice that the PQ bandwidth was lowered to force packet drops.
         (pkts matched/bytes matched) 458/29647
         (caídas totales/pérdidas de bytes) 91/5890
!--- Some packets were dropped. In a well designed link,
!--- there should be no (or few) drops of the PQ class.

 Correspondencia de clases: clases predeterminadas (coincide cualquiera)
         814 packets, 731341 bytes
         5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any
         Cola equilibrada ponderada
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 32
         (total queued/total drops/no-buffer drops) 0/0/0
!---------------------------------------------
!--- Verificar la configuración de la correspondencia de clases
maui-voip-austin#show class-map
 Class Map match-all señalización de voz (id 2)
   Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-alltráfico de voz(id 3)
         Match access-group 102

!--- Verificar las listas de acceso de las correspondencias de clases
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)

!--- Verificar la configuración de la correspondencia de políticas
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)
   Clase de tráfico de voz
      Cola equilibrada ponderada
            Prioridad estricta
            Ancho de banda 50 (Kbps) Ráfaga 1250 (Bytes)
    Class class-default
      Weighted Fair Queueing
            Flow based Fair Queueing Max Threshold 64 (packets)
---------------------------
!--- El comando Debug priority ofrece una respuesta inmediata en caso de
!--- que el paquete VoIP sufra una caída.
!--- El resultado siguiente muestra el mensaje de error que aparece cuando los paquetes VoIP
!---se caen de la cola de prioridad estricta. 
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

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

!--- Verificación de fragmentación y entrelazado de enlace (LFI)

maui-voip-sj#show ppp multilink
!--- Verifique el tamaño de la fragmentación y de los enlaces múltiples
Multilink1, el nombre de agrupamiento es 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
        Enlaces miembro: 1 activo, 0 inactive (max not set, min not set)
         Serial0/0, desde 00:08:09, last rcvd seq 00006C 160 weight
  !--- Tenga en cuenta que el tamaño de la fragmentación es de 160 bytes. El enlace está configurado con un
  !--- ancho de banda de 128 Kbps y un retraso de serialización de 10 mseg.
  !--- Tamaño del fragmento (en bits) = ancho de banda * retraso de serialización.
  !--- Nota: Un byte contiene 8 bits.

-------------------------------------------------------
!--- Verificación de fragmentación y entrelazado de enlace (LFI)

!--- Prueba LFI de enlaces PPP de enlaces múltiples
!---Este resultado muestra información sobre la fragmentación y el entrelazado
!--- cuando el enlace PPP de 128 Kbps contiene paquetes de datos y paquetes VoIP de gran tamaño.
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: Paquete entrelazado de la cola 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
-------------------------------------------------------------------

!--- Ejemplo de resultado del comando show ip rtp header-compression
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

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

!--- Este comando muestra información sobre el comando voip dial-peers.
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:
        tipo = 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
        códec = g729r8,   payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
        VAD= habilitado, 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.

-------------------------------------------------------------------------
!---La utilización de la CPU por parte del router no debe ser superior a un 50 ó 60 por ciento
!--- durante cualquier intervalo de 5 minutos.
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



Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 7111