Voz : Calidad de voz

VoIP sobre Frame Relay con calidad de servicio (fragmentación, diseño de tráfico y prioridad LLQ / IP RTP)

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 VoIP over Frame Relay
      Prioridad estricta para tráfico de voz (LLQ o prioridad IP RTP)
      FRTS para voz
      Fragmentación (FRF.12)
      ‘Reducción del ancho de banda’
Configurar
      LLQ
      Prioridad IP RTP
      Modelado del tráfico para voz
      Fragmentación (FRF.12)
      Diagrama de la red
      Configuraciones
Verificación y resolución de problemas
      Comandos de prioridad LLQ / IP RTP
      Comandos de fragmentación
      Frame Relay / Comandos de interfaz
      Problemas conocidos
      Ejemplo de resultado de los comandos show y debug
Discusiones relacionadas de la comunidad de soporte de Cisco
Información relacionada

Introducción

Este documento muestra la voz sobre IP (voip) sobre una configuración de muestra de red de Frame Relay con la Calidad de Servicio (QoS). 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.

Es importante observar que la configuración en este documento tiene dos routers de la voz que está conectado con la red Frame Relay. En muchas topologías sin embargo, los routeres habilitados de la voz pueden existir dondequiera. Generalmente, la conectividad LAN del uso del routers de la voz al otro routers que están conectadas con el WAN. Esto es importante porque si su routers de la voz no está conectado directamente con la red Frame Relay, todos los comandos de la configuración de WAN se deben configurar en eso routers conectado con el WAN, y no en el routers de la voz, según las indicaciones de las configuraciones en este documento.

Requisitos previos

Requisitos

No hay requisitos específicos para este documento.

Componentes utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Cisco 3640 router con la versión de software 12.2.6a (Enterprise Plus) de Cisco IOS®

  • Router del Cisco 2621 con la versión 12.2.6a (Enterprise Plus)

  • Low Latency Queuing (LLQ) en los circuitos virtuales permanentes (PVC) de Frame Relay. Esto se introduce en la versión 12.1. (2) T.

  • Prioridad del Protocolo de transporte en tiempo real (RTP) del Frame Relay IP que se introduce en la Versión 12.0(7)T del software del IOS de Cisco.

  • Foro de Frame Relay (FRF) .12 fragmentación que se introduce en la Versión 12.0(4)T del software del IOS de Cisco.

  • Las versiones que 12.0.5T contienen más adelante las mejoras significativas en el desempeño para el Compressed RTP (cRTP).

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

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 VoIP over Frame Relay

Existen dos requisitos básicos para una buena calidad de voz:

Para garantizar los requisitos previamente mencionados, utilizar estas guías de consulta:

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

Hay dos métodos principales para proporcionar a la prioridad estricta para el tráfico de voz:

  • Prioridad IP RTP (también denominada Cola prioritaria/Colocación en Weighted Fair Queuing [PQ/WFQ])

  • LLQ (también se lo llama PQ / Class Based Weighted Fair Queuing (PQ/CBWFQ))

Prioridad IP RTP

El ip rtp priority del Frame Relay crea una cola de prioridad estricta en un PVC de Frame Relay para un conjunto de los flujos del paquete RTP que pertenecen a los puertos destino de un rango del protocolo de datagrama de usuario (UDP). Mientras que los puertos reales usados se negocian dinámicamente entre los dispositivos finales o los Gateways, todos VoIP de Cisco los productos utilizan el mismo rango de puertos del UDP (16384 a 32767). Una vez que el router reconoce el tráfico VoIP, lo coloca en la cola de prioridad (PQ) estricta. Cuando el PQ es vacío, se procesan las otras coletas basaron en el WFQ estándar. La prioridad IP RTP no se activa hasta que exista congestión en la interfaz. Esta imagen ilustra el funcionamiento de la prioridad IP RTP:

pq-wfq.gif

Nota: El IP RTP Priority permite el repartir del PQ cuando hay anchura de banda disponible en la Weighted Fair Queuing (WFQ). Sin embargo, limpia terminantemente el contenido del PQ cuando hay congestión en la interfaz.

LLQ

LLQ es una función que proporciona un estricto PQ a 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 configure la PQ, especifique en Kbps, la cantidad máxima de ancho de banda disponible para esa 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 rechaza para evitar que la función legacy priority-group de Cisco deje de alimentar las colas de menor prioridad.

Nota: Con la retransmisión de tramas LLQ, las colas se configuran sobre una base por PVC. Cada PVC tiene una cola prioritaria y una cantidad de colas justas asignadas.

llq.gif

Este método es más complejo y flexible que prioridad IP RTP. La opción entre los métodos necesita ser basada en los patrones del tráfico en su red real y sus necesidades.

LLQ vs. prioridad RTP IP

Este vector resume las diferencias principales entre el LLQ y el IP RTP Priority y proporciona a las guías de consulta de cuándo utilizar cada método.

LLQ

Prioridad IP RTP

Igualar tráfico de voz basado en:

  • Listas de acceso. Por ejemplo, el rango de los puertos UDP, direcciones de los hosts, campos de Tipo de servicio (ToS) de encabezado IP [como la precedencia IP, el Punto de código de servicios diferenciados (DSCP)].

  • Rango de puerto IP RTP.

  • TOS Campo-DSCP y/o IP precedence del IP.

  • Protocolos e interfaces de entrada.

  • Todos los criterios de concordancia válidos usados en CBWFQ.

Ventajas:

  • Más flexibilidad sobre cómo se compara y dirige el tráfico al PQ estricto y CBWFQ.

  • Puede configurar clases adicionales para garantizar el ancho de banda para otro tipo de tráfico como el video y la señalización VoIP.

Desventajas: Configuración compleja.

Igualar tráfico de voz basado en:

  • Basado en el rango de puerto RTP/UDP: 16384-32767

Ventajas: Configuración simple

Desventajas:

  • Tráfico (Señalización VoIP) del Protocolo de control de tiempo real (RTCP) servido en cola WFQ.

    Nota: El protocolo RTP utiliza RTCP para controlar la entrega de los paquetes RTP. Mientras que los puertos del RTP utilizan los números par, los puertos del RTCP utilizan los números impares en el rango de 16384-32767. La prioridad IP RTP coloca puertos RTP en la PQ, mientras que los puertos RTCP se atienden en la WFQ predeterminada.

  • Tráfico de VoIP de los servicios en el PQ. Sin embargo, 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 opción entre ellas necesidades de ser basado en los patrones del tráfico en su red real y sus necesidades reales.

  • Si usted necesita proporcionar a la prioridad estricta a su tráfico de voz, y el otro tráfico se puede tratar como solo tipo (datos), entonces el IP RTP Priority hace un buen trabajo para su red con una Configuración simple.

  • Si planea dar prioridad al tráfico de voz en función de otros criterios que no sean los puertos UDP. Por ejemplo, Comportamiento por salto (PHB) de Servicios diferenciados (DiffServ) y LLQ.

FRTS para voz

El FRTS proporciona a los parámetros que son útiles para manejar la congestión del tráfico de la red. FRTS elimina los cuellos de botella en redes de Frame Relay con conexiones de alta velocidad con el sitio central y conexiones de velocidad baja con las páginas web de las sucursales. Puede configurar los valores de límite de velocidad de forma tal que se limite la velocidad a la que se envía información desde el circuito virtual (VC) en el sitio central.

Estas definiciones se relacionan con el FRTS:

  • Velocidad de información comprometida (CIR)—La velocidad (en bits por segundo) que garantiza el proveedor de Frame Relay para la transferencia de datos. Los valores CIR son establecidos por el proveedor de servicios de retransmisión de tramas y configurados por el usuario en el router.

    Nota: El puerto/la velocidad de acceso a la interfaz puede ser más altos que el CIR. La tarifa se hace un promedio sobre un período de tiempo del intervalo de medición de velocidad comprometida (Tc).

  • Committed burst (Bc) - número máximo de bits que la red Frame Relay confía a la transferencia sobre un Tc. Tc = Bc / CIR.

  • Ráfaga en exceso (Be) - número máximo de bits disponibles que el switch de Frame Relay procura transferir más allá del CIR sobre el Tc.

  • Intervalo de medición de velocidad comprometida (Tc) - excedente del intervalo de tiempo que a.C. o (Bc+ sea) los bits se transmiten. El Tc se calcula como Tc = Bc/CIR. El valor del Tc no se configura directamente en los routeres de Cisco. Se calcula luego de configurar los valores Bc y CIR. El Tc no puede exceder los 125 ms.

  • Al revés notificación de congestión explícita (BECN) - un dígito binario en el encabezado de trama de Frame Relay que indica la congestión en la red. Cuando un switch de Frame Relay reconoce la congestión, fija el bit de notificación explícita de la congestión del reenvío en las tramas destinado para el router de origen y manda al router para reducir la velocidad de transmisión.

La configuración del FRTS para el tráfico de voz es diferente de la del modelado de tráfico para los datos solamente. Al configurar el FRTS para la calidad de la voz, los compromisos se hacen con los parámetros del tráfico de datos. Para más información sobre estas restricciones ver la sección de la fragmentación (FRF.12) en este documento.

Fragmentación (FRF.12)

Un gran desafío en la integración de voz y datos es controlar el retardo máximo unidireccional de extremo a extremo para el tráfico sensible al tiempo, como el de voz. Para la buena calidad de voz, este retardo necesita ser menos de el ms 150. Un parte importante de este retardo es el retraso de serialización en la interfaz. Cisco recomienda que éste sea el ms 10 y no debe exceder al ms 20. El retraso de serialización es el tiempo real que transcurre cuando ubican los bits en una interfaz.

Serialization Delay = frame size (bits) / link bandwidth (bps)

Por ejemplo, un paquete de 1500 bytes tarda 214 ms en abandonar el router en un enlace de 56 Kbps. Si un paquete de los datos en tiempo no real de 1500 bytes se envía, se hacen cola los paquetes de datos en tiempo real (de la voz) hasta que se transmite el paquete de datos grande. Este retraso es inaceptable para el tráfico de voz. Si los paquetes de datos que no son en tiempo real son fragmentados en tramas más pequeñas, éstos son entrelazados con tramas (de voz) en tiempo real. De este modo, tanto la trama de datos como la de voz pueden mantenerse juntas en enlaces de baja velocidad sin generar demasiado retardo al tráfico de voz en tiempo real.

lfi.gif

Para obtener más información sobre la fragmentación, consulte Fragmentación de Frame Relay para voz.

Nota: En caso de que usted tenga a conexión media t1 dedicada (768 kbps), usted no necesita probablemente una función de fragmentación. Sin embargo, usted todavía necesita un mecanismo de Calidad de Servicio (QoS) (IP RTP Priority o LLQ, en este caso). La T1 media o las velocidades mayores proporcionan un ancho de banda suficiente que permite que los paquetes de voz entren en la cola o salgan de ella en el rango recomendado de retraso de serialización (10 ms, no más de 20 ms). También, usted no necesita probablemente el cRTP, que ayuda a salvar la anchura de banda comprimiendo IP RTP las cabeceras, en el caso de un T1 lleno.

‘Reducción del ancho de banda’

cRTP

De acuerdo con RFC 2508leavingcisco.com , la característica del cRTP comprime el encabezado de paquete del IP/UDP/RTP a partir de 40 bytes a 2 o 4 bytes. Esto reduce el consumo de ancho de banda innecesario. Es un plan de compresión por salto. Por lo tanto, el cRTP se debe configurar en los ambos extremos de la conexión, a menos que se configure la opción pasiva.

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 salva el tiempo de resolución de problemas porque aísla las ediciones potenciales del cRTP.

Monitorear la utilización de la CPU del router. Invalidar el cRTP si está sobre 75 por ciento. En velocidades de enlace más altas, los ahorros de ancho de banda del cRTP se pudieron potencialmente compensar por el adicional carga de la CPU. Cisco recomienda solamente el usar del cRTP con las conexiones más bajo de 768 Kbps, a menos que el router se ejecute en una tarifa baja de la utilización de la CPU.

Nota: Debido a la ausencia de un estándar, se desarrolló cRTP para Frame Relay en la encapsulación propiedad de Cisco. Por lo tanto, no trabaja con la encapsulación de la Fuerza de tareas de ingeniería en Internet (IETF) (IETF) del Frame Relay. Recientemente, el FRF.20 fue concluido para hacer la compresión del encabezado RTP posible en la encapsulación de IETF. Sin embargo, desde la fecha de la última actualización de este documento (mayo de 2002), no se soporta FRF.20.

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

Selección del codificador/del decodificador (Codec)

Utilice códecs de baja velocidad de bits en los tramos de llamadas de VoIP. El G.729 (8 Kbps) es el codec predeterminado para el voip dial-peer.

Nota: Aunque el tono dual de múltiples frecuencias (DTMF) se transporta generalmente exactamente cuando se utiliza el codecs de la voz del high-bit-rate (por ejemplo el G.711), el codecs del low-bit-rate (tal como G.729 y G.723.1), se optimiza altamente para los patrones de voz y tiende para torcer los tonos del 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. Transporta los tonos del DTMF out-of-band o a parte de la secuencia de voz codificada. Si usted utiliza el codecs del low-bit-rate (G.729, G.723) girar el comando dtmf relay bajo el voip dial-peer.

Detección de actividad de voz (VAD) habilitada

Una conversación típica pudo potencialmente contener el porciento de silencio 35 a 50. Se suprimen los paquetes de silencio cuando se utiliza el VAD. Para las hojas de operación (planning) del ancho de banda de VoIP, asumir que el VAD reduce la anchura de banda por 35 por ciento. VAD está configurado de forma predeterminado en pares de marcado VoIP.

Configurar

En esta sección encontrará la información para configurar las funciones descritas en este documento.

Nota: Para obtener información adicional sobre los comandos que se utilizan en este documento, use la herramienta Command Lookup (Búsqueda de comandos) (sólo para clientes registrados).

LLQ

Utilizar este procedimiento para configurar el LLQ:

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

    Estos comandos explican cómo terminar 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
    
    
    !--- Create the access-list to match the class-map access-group:
    
    
    maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32767
    
    !--- The 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 también se utilizan para corresponder con 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 the other non-voice traffic does not use 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,
    !--- mark incoming traffic by applying an inbound service policy on an
    !--- inbound interface. This procedure is out of the scope
    !--- of this document. 
    
    
    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 comandos access-group:

    • Con la versión 12.1.2.T y posterior, las funciones del IP RTP Priority se implementan para el LLQ. Esta característica corresponde con el contenido de clases de prioridad que mira los puertos del UDP configurados. Está conforme a la limitación de servir solamente los puertos uniformes en el PQ.

      class-map voice
        match ip rtp 16384 16383
      
    • Estos dos métodos funcionan bajo asunción que los paquetes de VoIP son marcados en los host de origen o correspondidos con y marcados en el router antes de que se aplique la operación de LLQ saliente:

      class-map voice
         match ip precedence 5
      

      O

      class-map voice
         match ip dscp ef
      

      Nota: En la versión 12.2.2T y posterior, el voip dial-peers puede marcar los paquetes del portador y de la señalización de la voz antes de la operación LLQ. Esto permite a modo escalable de marcar y de corresponder con los paquetes de VoIP con los valores del código del DSCP para el LLQ. Para más información consulte Clasificación de señalización de VoIP y medios con DSCP para QoS.

      Router(config-dial-peer)#ip qos dscp ?
      
  2. Cree un mapa de clase para la señalización VoIP y defina un criterio de coincidencia (opcional).

    Utilizar estos comandos de terminar 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, el Protocolo de inicio de sesión (SIP), el Protocolo de control de la puerta de enlace de medios (MGCP) o el Protocolo Skinny Call Control Protocol (SCCP), un protocolo patentado que utiliza Cisco Call Manager. El ejemplo anterior asume que el H.323 rápidamente conecta. Esta lista sirve como referencia para los puertos usados por 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

    • SCCP = TCP 2000-2002 (repetición del CM)

    • ICCP = TCP 8001-8002 (CM Encore)

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

    • SIP= UDP 5060, TCP 5060 (configurable)

  3. Cree un mapa de política y asócielo a los mapas de clase de VoIP.

    El propósito de la correspondencia de políticas es definir cómo los recursos de la conexión se comparten o se asignan a las diversas clases de la correspondencia. Utilizar estos comandos de terminar 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 PQ
    !--- (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 WFQ.
    
    

    Nota: Aunque es posible enqueue a los varios tipos de tráfico en tiempo real al PQ, el Cisco recomienda que usted dirige solamente el tráfico de voz a él. El tráfico en tiempo real, tal como vídeo, potencialmente introduce la variación en el retardo (el PQ es una coleta del Primero en entrar, primero en salir (FIFO)). El tráfico de voz requiere que la demora sea invariable para evitar la fluctuación.

    Nota: La suma de los valores para las declaraciones del priority y bandwidth necesita ser inferior o igual minCIR para el PVC. Si no, el comando service-policy no se puede asignar a la conexión. el minCIR es mitad del CIR por el valor por defecto. Para ver los mensajes de error, asegurarse de que el comando logging console es habilitado para el acceso a la consola y el comando terminal monitor es habilitado para el accesso del telnet.

    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. Para habilitar LLQ, implemente el mapa de política en la interfaz WAN de salida.

    Utilizar estos comandos de habilitar el LLQ:

    maui-voip-sj(config)#map-class frame-relay VoIPovFR
    maui-voip-sj(config-if)#service-policy output VOICE-POLICY
    
    !--- The service-policy is applied to the PVC
    !--- indirectly by configuring
    !--- it under the map-class associated to the PVC.
    
    

Prioridad IP RTP

Si usted no utiliza el LLQ, utilizar estas guías de consulta:

Router(config-map-class)#frame-relay ip rtp priority starting-rtp-port
port-range  bandwidth 
  • starting-rtp-port—El número del puerto de inicio UDP. El número de puerto menor al cual se envían los paquetes. Para VOIP, configure este valor en 16384.

  • port-range—El rango de puertos de destino UDP. El número, agregado al starting-rtp-port, rinde el número del puerto más alto del UDP. Para VOIP, configure este valor en 16383.

  • El anchura de banda-Máximo permitió la anchura de banda en el kbps para el priority queue. Fijar este número basado en el número de las llamadas simultáneas, agregando la anchura de banda de cada llamada por la llamada que los soportes de sistema.

Configuración de ejemplo:

map-class frame-relay VoIPovFR  frame-relay cir 64000
 frame-relay BC 600
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80
 frame-relay ip rtp priority 16384 16383 45

Modelado del tráfico para voz

Utilizar estas guías de consulta cuando usted configura el modelado de tráfico para la voz:

  • No exceda la CIR del PVC.

  • Invalidar el modelado adaptable de Frame Relay.

  • Configure el valor Bc como bajo para que el Tc (intervalo de formación) sea de 10 ms (Tc = Bc/CIR). Configure el valor Bc para forzar el valor Tc deseado.

  • Configure el valor de Be en 0.

Para más información de estas guías de consulta, referir al Frame Relay Traffic Shaping para el voip y VoFR.

Nota: Algunos clientes utilizan PVC para datos y para voz por separado. Si usted tiene dos PVC separados y desea repartir en el PVC de dato mientras que usted permanece en o debajo del CIR para la voz PVC, la calidad de la voz todavía sufre puesto que estos PVC utilizan la misma interfaz física. En tales casos, el proveedor de servicios de Frame Relay, así como el router, necesidad de dar la prioridad a la voz PVC. El último se puede hacer por el PVC Interface Priority Queueing (PIPQ) disponible en fecha la versión 12.1(1)T del software del IOS de Cisco.

Fragmentación (FRF.12)

Active la fragmentación para enlaces de velocidad baja (menos de 768 kbps). Fijar los tamaños del fragmento para no hacer fragmentos y no experimenten los paquetes de voz a ms mayor que 20 del retraso de serialización. Fijar los tamaños de fragmentación basados en la mínima velocidad de puerto entre el routers. Por ejemplo, si hay una topología de Frame Relay del hub and spoke donde el cubo tiene una velocidad T1 y los routeres remotos tienen 64 velocidades de puerto de K, los tamaños de fragmentación necesitan ser fijados para la velocidad de 64 K en ambo routers. Cualquier otro PVC que comparta la misma necesidad de la interfaz física de configurar la fragmentación a los tamaños utilizó por la voz PVC. Utilizar esta carta para determinar los valores de los tamaños de fragmentación.

Velocidad más baja del enlace en el trayecto.

Tamaño de fragmentación recomendada (para Serialización 10 ms)

56 Kbps

70 bytes

64 Kbps

80 bytes

128 Kbps

160 bytes

256 kbps

320 bytes

512 kbps

640 bytes

768 kbps

1000 bytes

1536 Kbps

1600 bytes

Configuración de ejemplo:

map-class frame-relay VoIPovFR 

!--- Some output is omitted.

 frame-relay fragment 80

Nota: Para el Kbps 1536, no hay fragmentación técnico necesaria. Sin embargo, la fragmentación es necesaria habilitar el dual fifo que hace cola el sistema para asegurar la calidad de la voz. Los tamaños del fragmento de 1600 bytes habilitan el dual fifo. Sin embargo, puesto que 1600 bytes son más altos que el Unidad máxima de transmisión de interfaz serial típica (MTU), los paquetes de datos grandes no se hacen fragmentos.

Diagrama de la red

Este documento utiliza la configuración de red que se muestra en este diagrama:

VoIP_FR.gif

Configuraciones

Este documento utiliza las configuraciones mostradas aquí:

  • maui-voip-sj (Cisco 3640)

  • maui-voip-austin (Cisco 3640)

maui-voip-sj (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-sj
!
logging buffered 10000 debugging
enable secret 5 $1$MYS3$TZ6bwrhWB25b2cVpEVgBo1
!
ip subnet-zero
!

!--- 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 PQ
!--- is assigned to the voice-traffic class
!--- with a maximum bandwidth of 45 Kbps.


policy-map VOICE-POLICY
  class voice-traffic
  priority 45
  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. Instead, it is 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.

!
interface Ethernet0/0
  ip address 172.22.113.3 255.255.255.0
  half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 no fair-queue
frame-relay traffic-shaping
 frame-relay ip rtp header-compression

!--- Turns on traffic shaping and cRTP. If traffic-shaping is not
!--- enabled, then map-class does not start and FRF.12 and LLQ  does
!--- not work.

!
interface Serial0/0.1 point-to-point
 bandwidth 128
 ip address 192.168.10.2 255.255.255.252
 frame-relay interface-dlci 300
  class VOIPovFR

!--- This command links the subinterface to a VoIPovFR map-class.
!--- See the map-class frame-relay VoIPovFR command  here:
!--- Note: The word VoIPovFR is selected by the user.
!

ip classless
ip route 172.22.112.0 255.255.255.0 192.168.10.1
!
map-class frame-relay VOIPovFR
 no frame-relay adaptive-shaping

!--- Disable Frame Relay BECNS. Note also that Be equals 0 by default.

frame-relay cir 64000
 frame-relay bc 640

!--- Tc = BC/CIR. In this case Tc is forced to its minimal
!--- configurable value of 10 ms.

frame-relay be 0
 frame-relay mincir 64000

!--- Although  adaptive shaping is disabled, make CIR equal minCIR
!--- as a double safety. By default minCIR  is half of CIR.

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

!--- Turns on FRF.12 fragmentation and sets the fragment size equal to 80 bytes.
!--- This value is based on the port speed of the slowest path link.
!--- This command also enables dual-FIFO.

!
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
!

!--- 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 matches VoIP signaling protocol. In this
!--- case, H.323 V2 is uesd with the fast start feature.

!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:192.168.10.1
 dtmf-relay cisco-rtp
 ip precedence 5

maui-voip-austin (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
logging buffered 1000000 debugging
!
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 45
  class class-default
   fair-queue
!
interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 64
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 no fair-queue
 frame-relay traffic-shaping
 frame-relay ip rtp header-compression
!
interface Serial0/0.1 point-to-point
 bandwidth 64
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 400
  class VOIPovFR
!
ip classless
ip route 172.22.113.0 255.255.255.0 192.168.10.2
!
map-class frame-relay VOIPovFR
no frame-relay adaptive-shaping
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 service-policy output voice-policy
 frame-relay fragment 80
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
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:192.168.10.2
 dtmf-relay cisco-rtp
 ip precedence 5

Verificación y resolución de problemas

En esta sección encontrará información que le permitirá confirmar que su configuración funcione correctamente.

La herramienta de Output Interpreter (sólo para clientes registrados) soporta algunos comandos show. Esto le permitirá ver un análisis del resultado del comando show.

Comandos de prioridad LLQ / IP RTP

Estos comandos show and debug le ayudan a verificar sus configuraciones del LLQ y del ip rtp priority.

Comandos de fragmentación

Utilizar estos comandos debug and show de verificar y de localizar averías las configuraciones de fragmentación.

  • el show frame-relay fragmento-Visualiza la información sobre la fragmentación de Frame Relay que ocurre en el router de Cisco.

  • el debug enmarcar-retransmite fragmento-Visualiza el acontecimiento o los mensajes de error relacionados con la fragmentación de Frame Relay. Sólo se activa en el nivel de PVC en la interfaz seleccionada.

Frame Relay / Comandos de interfaz

Utilizar estos comandos show de verificar y de localizar averías el Frame Relay/las configuraciones de la interfaz.

  • show traffic-shape queue interface - información de visualizaciones sobre los elementos hechos cola en el nivel del identificador de conexión de enlace de datos del VC (DLCI). Verificaban el funcionamiento de la prioridad IP RTP sobre el Frame Relay. Cuando se congestiona la conexión, los flujos de la voz se identifican con un peso igual a cero. Esto indica que el flujo de la voz utiliza el PQ. Ver a salida de muestra aquí.

  • mostrar tráfico-dimensión de una variable-Visualiza la información tal como Tc, esté a.C., y los valores configurados del CIR. Ver a salida de muestra.

  • show frame-relay pvc dlci-- - información de visualizaciones tal como parámetros de modelado del tráfico, valores de fragmentación, y paquetes perdidos. Ver a salida de muestra. Consulte también Solución de problemas de Frame Relay.

Problemas conocidos

Se identificó un error de funcionamiento con LLQ por VC donde la PQ estaba regulada de manera estricta, incluso cuando no existe una congestión en la interfaz. Ese fallo de funcionamiento ha estado fijado y ahora los paquetes de voz no conformes se caen solamente si la congestión ocurre en el VC. Esto hace el comportamiento del por VC LLQ igual que otras interfaces que utilicen el LLQ. Este comportamiento fue cambiado con la versión 12.2(3) y posteriores del software del IOS de Cisco.

Ejemplo de resultado de los comandos show y debug

Ésta es salida del comando show and debug de la muestra usada para la Verificación y resolución de problemas.


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

!--- Priority queue bandwidth  is lowered to 10 Kbps to force drops from the PQ.
!--- Note: To reset counters, use the clear counters command. 


maui-voip-sj#show policy-map inter ser 0/0.1
  Serial0/0.1: DLCI 300 -

  Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)
         26831 packets, 1737712 bytes
         5 minute offered rate 3000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 26311/1704020
         (total drops/bytes drops) 439/28964

   Class-map: voice-signaling (match-all)
         80 packets, 6239 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 62/4897
         (depth/total drops/no-buffer drops) 0/0/0

   Class-map: class-default (match-any)
         14633 packets, 6174492 bytes
         5 minute offered rate 10000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0



!--- These  commands are useful to verify the LLQ 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 45 (kbps) Burst 1125 (Bytes)
   Class class-default
        Weighted Fair Queueing
           Flow based Fair Queueing Max Threshold 64 (packets)

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


!--- Frame Relay verification command output.


maui-voip-sj#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0/0.1       300   end-to-end      80         4          4          0

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 7 output pkts 7 in bytes 926
         out bytes 918 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 2 out bcast bytes 598
         pvc create time 1w2d, last time pvc status changed 1w2d
      service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
         Weighted Fair Queueing
      Strict Priority
         Output Queue: Conversation 24
         Bandwidth 45 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

 Class-map: voice-signaling (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 0/0
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         7 packets, 918 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0


 Output queue size 0/max total 600/drops 0
 fragment type end-to-end fragment size 80
 cir 64000 bc 640 be 0 limit 80 interval 10
 mincir 64000 byte increment 80 BECN response no
 frags 13 bytes 962 frags delayed 8 bytes delayed 642

 shaping inactive
 traffic shaping drops 0


!--- In this Frame Relay verification command
!--- output, the PQ bandwidth is lowered and heavy traffic
!--- is placed on the interface to force drops.


maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 483 output pkts 445 in bytes 122731
         out bytes 136833 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 4 out bcast bytes 1196
         pvc create time 1w2d, last time pvc status changed 1w2d
         service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         352 packets, 22900 bytes
         5 minute offered rate 2000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 352/22900
         (total drops/bytes drops) 169/11188

 Class-map: voice-signaling (match-all)
         7 packets, 789 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 7/789
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         79 packets, 102996 bytes
         5 minute offered rate 4000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 5/0/0
         Output queue size 5/max total 600/drops 169
         fragment type end-to-end fragment size 80
         cir 64000 bc 640 be 0 limit 80 interval 10
         mincir 64000 byte increment 80 BECN response no
         frags 2158 bytes 178145 frags delayed 1968 bytes delayed 166021

 shaping active
         traffic shaping drops 169


!--- Notice that the Tc interval equals 10 ms,
!--- CIR equals 64000 BPS, and BC equals 640. 


maui-voip-sj#show traffic-shape
Interface  Se0/0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
300           64000     80     640       0          10        80         -



!--- This output is captured on an isolated lab enviroment where
!--- the routers are configured with IP RTP Priority instead of LLQ.


maui-voip-austin#show frame-relay PVC 100

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

  input pkts 336           output pkts 474          in bytes 61713
  out bytes 78960          dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  PVC create time 1w0d, last time PVC status changed 1w0d
 Current fair queue configuration:
   Discard      Dynamic       Reserved
   threshold    queue count   queue count
   64            16              2
 Output queue size 0/max total 600/drops 0
  fragment type end-to-end        fragment size 80
  cir 64000     BC   640      be 0     limit 125    interval 10
  mincir 32000    byte increment 125   BECN response no
  frags 1091      bytes 82880     frags delayed 671      bytes delayed 56000
  shaping inactive
  traffic shaping drops 0
  ip rtp priority parameters 16384 32767 45000


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


maui-voip-austin#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        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-target = `ipv4:192.168.10.2',
        technology prefix:
     ip precedence = 5, UDP checksum = disabled,
         session-protocol = cisco, req-qos = best-effort,
         acc-qos = best-effort,
     dtmf-relay = cisco-rtp,
        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 = 165830, Charged Units = 0,
        Successful Calls = 30, Failed Calls = 0,
        Accepted Calls = 30, Refused Calls = 0,
        Last Disconnect Cause is "10",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 69134010.

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: 12156