Comprensión de la fluctuación en las redes de voz en paquetes (plataformas Cisco IOS)
Contenido
Introducción
Este documento describe la fluctuación y cómo medirla y compensarla.
Prerequisites
Requirements
Quienes lean este documento deben tener conocimiento de los siguientes temas:
-
Configuración de voz básica de Cisco IOS®
-
Comprensión básica de la Calidad de Servicio (QoS)
Componentes Utilizados
La información que contiene este documento se aplica a las gateways de voz del IOS de Cisco y a los routers.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Convenciones
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Fluctuación en redes de voz en paquetes
La fluctuación se define como una variación en la demora de los paquetes recibidos. En el lado emisor, los paquetes se envían aparte de forma espaciada en un flujo continuo y uniforme. Debido a una congestión de la red, a un envío a cola incorrecto o a errores de configuración, este flujo continuo puede dejar de ser uniforme o la demora entre cada paquete puede convertirse en variable en vez de seguir siendo constante.
Este diagrama ilustra cómo se administra una secuencia continua de paquetes.
Cuando un router recibe un flujo de audio del Protocolo en Tiempo Real (RTP) para la voz sobre IP (VoIP), debe compensar la fluctuación que está presente. El mecanismo que controla esta función es el buffer de demora de reproducción. El buffer de demora de reproducción debe almacenar en el buffer estos paquetes y, a continuación, reproducirlos en una secuencia constante hacia los procesadores de señales digitales (DSP) para convertirse de nuevo a una secuencia analógica de audio. También suele hacerse referencia al búfer de retardo de reproducción como búfer de eliminación de fluctuación.
Este diagrama ilustra cómo se maneja la fluctuación.
Si la fluctuación es tan grande que provoca que los paquetes se reciban fuera del alcance de este buffer, los paquetes que se encuentran fuera del rango se descartan y se aprecian interrupciones en el audio. Para las pérdidas pequeñas de solo un paquete, el DSP interpola lo que cree que debería ser el audio y ya no se perciben más problemas de audio. Cuando la fluctuación excede lo que DSun P puede hacer para compensar los paquetes perdidos, se registran problemas de audio.
Este diagrama ilustra cómo se maneja la fluctuación excesiva.
Determinación de la gravedad de la fluctuación
Para confirmar a través de CISCO IOS la presencia de un exceso de fluctuación, realice los pasos siguientes.
-
Una vez que una llamada está establecida y activa, y se sospecha que hay fluctuación, comuníquese mediante Telnet a una de los gateways involucradas.
-
Habilite Terminal Monitor para poder ver los mensajes de la consola a través de su sesión Telnet.
Nota: Este paso no es necesario si está conectado al puerto de la consola.
-
Ingrese el comando show voice call summary . Aparece una salida similar a esta:
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
Seleccione la llamada donde se produce la fluctuación. En este ejemplo, es 1/0/1.
-
Para ver esta llamada específica, ingrese el comando show voice call.
En este ejemplo es show voice call 1/0/1. La salida que se obtiene proviene del DSP que administra la llamada y que es similar a:
1/0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset(ms): 0, Rx Delay Est(ms): 50 Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): 0 Silence Conceal(ms): 0, Retroact Mem Update(ms): 0 Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0 ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0 Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0 Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0 Rx Early Pkts: 0, Rx Late Pkts: 0 ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0 ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 ***DSP LEVELS*** TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
Vea la sección ***DSP VOICE VP_ERROR STATISTICS*** de la salida.
En esta sección, hay varios parámetros para tener en cuenta. El más importante de ellos es el número de Buf Overflow Discard (ms) . Éste cuenta los paquetes que están fuera del alcance de la memoria intermedia para el retardo de reproducción completa (perdidos). Esto puede contener algún valor, siempre que no aumente constantemente. Es normal recibir algunos desbordamientos cuando una llamada se inicia por primera vez, pero este valor no debería incrementar cuando el comando show voice call X/X/X se repite. Este número es una indicación directa de fluctuación excesiva.
De forma predeterminada, este buffer se ejecuta en un modo adaptable, es decir, se ajusta dinámicamente a la cantidad presente de fluctuación (hasta cierto límite). Configure el comando playout-delay para cambiar los valores predeterminados de la conducta dinámica del buffer de eliminación de fluctuación. Este búfer únicamente se puede configurar en modo fijo. Esto puede resolver algunos problemas con la fluctuación. Para más información, refiera a Mejoras de la Demora de Reproducción para la Voz sobre IP.
¿Qué provoca la fluctuación?
La fluctuación suele estar causada por la congestión en la red IP. La congestión puede ocurrir en las interfaces del router o en una red del proveedor o del operador de servicios de telefonía si el circuito no está correctamente equipado.
Consideraciones sobre encapsulación
El lugar más fácil y mejor para comenzar a buscar fluctuaciones es en las interfaces del router, puesto que el usuario tiene un control directo sobre esta parte del circuito. El modo usado para rastrear el origen de la fluctuación depende en gran medida de la encapsulación y el tipo de link en el que se produce la fluctuación. En general, si están configurados correctamente, los circuitos ATM no experimentan fluctuaciones debido a la velocidad de celdas constante involucrada. Esto proporciona una latencia coherente. Si la fluctuación se aprecia en un entorno ATM, es preciso examinar la configuración de ATM. Cuando ATM trabaja correctamente (sin caída de células), puede esperar que la latencia no sea un problema. En la encapsulación del Protocolo Punto a Punto (PPP), la fluctuación está provocada casi siempre por la demora de serialización. Esto puede administrarse fácilmente con la fragmentación y el entrelazado de enlaces en el enlace PPP. La naturaleza de PPP significa que los puntos finales PPP se comunican directamente entre sí, sin la intervención de una red de switches. De este modo, el administrador de la red tiene el control sobre todas las interfaces implicadas.
Fluctuación en un entorno Frame Relay
Se necesita direccionar tres parámetros para encontrar la fluctuación en un entorno de Frame Relay.
Para ver configuraciones de muestra e información relacionada al respecto, refiera a Frame Relay de Voz sobre IP con Calidad de Servicio.
Modelado de tráfico
Debe asegurarse de modelar el tráfico que abandona el router según la Velocidad de información comprometida (CIR) que proporciona la portadora. Para verificarlo, consulte las estadísticas de Frame Relay y póngase en contacto con el operador de servicios de telefonía. El primer lugar donde debe buscar es en las estadísticas de Frame Relay. Utilice el comando show frame-relay pvc xx, donde xx es el numero del identificador de conexión de link de datos (DLCI). Debe recibir una salida similar a la siguiente:
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 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 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
Refiera a la descripción de show frame-relay pvc para obtener una explicación completa de todos los campos.
Qué buscar
Lo que debe interesarle en el resultado del comando son los valores que muestran si hubo una congestión en la red de trama. Estos valores son los parámetros FECN (notificación de congestión explícita hacia delante), BECN ((notificación de congestión explícita hacia atrás) y DE (apto para descarte). Su única preocupación debería limitarse a los paquetes de entrada, ya que Cisco no los envía. Puede que uno o varios de estos valores se incrementen. Esto depende del tipo y de la configuración de los switches de tramas que usa el proveedor. Por lo general, si dispone de catalogación de tráfico de Frame Relay y está configurada para el mismo CIR que el circuito, estos valores no deberían incrementar nunca. Si observa que aumentan, y se ajusta al CIR real del circuito, significa que algún elemento de la red del proveedor de la trama no está configurado correctamente.
Un buen ejemplo de esto es si adquiere un circuito CIR cero pero tiene un valor de ráfaga. Algunos proveedores venden el Circuito virtual permanente (PVC) de CIR cero. Esto es correcto para los datos pero causa problemas con la calidad de la voz. Si observa la salida del comando desde un circuito CIR cero, el número de paquetes DE o FECN es el mismo que el de paquetes de entrada. Supongamos ahora que cuenta con un PVC con un rendimiento de 128 kbs establecido por la operadora de servicios de telefonía y el CIR del router está establecido en 512 kbs. Observará como estos contadores aumentan (a una velocidad más lenta). Recuerde que únicamente está observando los paquetes que entran en la interfaz del router y que esta velocidad está controlada por los parámetros de catalogación de tráfico configurados en el router en el extremo opuesto del PVC. Inversamente, es posible controlar el flujo de entrada en el otro router en función de los parámetros de catalogación de tráfico configurados en el extremo local.
Es muy importante que no exceda el CIR para el PVC aplicado por el operador de servicios de telefonía. Puede estar en este CIR sin tener problemas. Sin embargo, si se excede, se producirá una congestión.
Puede ver la congestión de esta forma debido a que la CIR que está configurada para un PVC específico en un switch de tramas determina la velocidad a la que pasa el tráfico por dicho switch (para ese PVC). Cuando el CIR configurado en el switch de tramas es excedido por la velocidad de datos que recibe, debe almacenar en el búfer las tramas que excedan el CIR hasta que esté disponible la capacidad de reenvío de paquetes guardados en el búfer. El switch de la trama asigna a todos los paquetes almacenados en el buffer el conjunto de bits DE o el conjunto de bits FECN.
Como es habitual, es aconsejable que también examine de cerca las estadísticas de la interfaz y busque errores para estar seguro de que todo funciona correctamente en la capa física. A tal efecto, utilice el comando show interface.
La relación que esto guarda con las fluctuaciones es que si ocurre, y se deben almacenar en buffer algunos paquetes en la red de tramas, tienen una mayor latencia para llegar al router remoto. Sin embargo, cuando no hay congestión, los paquetes se transmiten normalmente en el tiempo de latencia esperado. Esto causa una variación en el tiempo delta entre los paquetes recibidos en el router remoto. De ahí las fluctuaciones.
Fragmentación
La fragmentación se asocia más con la demora de serialización que con la fluctuación. Sin embargo, bajo ciertas condiciones, la fluctuación puede ser la causante. La fragmentación se debe configurar siempre en la clase de mapa de Frame Relay cuando se utiliza la voz empaquetada. La configuración de este parámetro tiene dos efectos en la interfaz. El primer efecto es que todos los paquetes superiores al tamaño especificado se fragmentan. El segundo efecto es menos evidente, pero igualmente importante. Si se observa la interfaz en la que se configura la fragmentación, se puede comprobar el efecto de este comando. Sin la fragmentación, la estrategia de envío a la cola de la salida del comando show interface x muestra que se está usando el envío a la cola FIFO (primero en entrar, primero en salir). Una vez que la fragmentación se ha aplicado a la clase de mapa de Frame Relay, la salida de este comando muestra la estrategia de envío a la cola como FIFO dual. Esto crea la cola de prioridades que se utiliza para el tráfico de voz en la interfaz. Se recomienda establecer el valor de fragmentación en los valores indicados en la sección sobre fragmentación del documento VoIP over Frame Relay with QoS. Si sigue experimentando problemas de fluctuación en el valor recomendado, reduzca el valor de fragmentación un punto gradualmente hasta que la calidad de la voz sea aceptable.
Cola
Existen dos métodos de almacenamiento en cola generalmente aceptados para el tráfico VoIP en este tipo de entorno:
Tanto un método como el otro pueden ser utilizados, pero no deberían configurarse ambos. Si la operación de envío a cola parece correcta según la documentación, es lógico llegar a la conclusión de que el envío a cola funciona correctamente y que el problema reside en otra parte. Por lo general, el envío a cola no provoca fluctuaciones puesto que las variaciones en la demora creada son relativamente pequeñas. Sin embargo, si los paquetes de VoIP no se envía correctamente a la cola y hay datos en el mismo circuito, pueden producirse fluctuaciones.
Conclusión
La fluctuación es una variación en la latencia de paquete para los paquetes de voz. Los DSP dentro del router pueden compensar una cierta cantidad de fluctuación, pero una fluctuación excesiva puede abrumarlos. Esto da lugar a una calidad de voz deficiente. La causa de la fluctuación es el almacenamiento en cola o retraso de un paquete en alguna parte del circuito, donde no había otros paquetes en cola o retrasados. Esto provoca una variación en la latencia. La fluctuación puede estar causada tanto por una configuración incorrecta del router como por una configuración errónea del PVC del proveedor u operador de servicios de telefonía.
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)