TelePresence : Cisco Unified IP Phone de la serie 7900

Uso de la información de estado 79xx para la resolución de problemas

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


Contenido


Introducción

Este documento se centra en la información de estatus que todos los Teléfonos IP de Cisco 79xx proporcionan en su visualización para resolver problemas los problemas. Esta información se puede utilizar para determinar el tipo de codificador-decodificador funcionando para una llamada en curso. También proporciona la información en tiempo real en las características del rendimiento para una llamada en curso.

Antes de comenzar

Convenciones

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

prerrequisitos

No hay requisitos previos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de 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 un comando antes de ejecutarlo.

Mostrar

La visualización del Cisco IP Phone 79xx se puede utilizar para los propósitos de Troubleshooting vía el botón de la información (i) en el teléfono al mostrar información en una llamada en curso. Presione este botón dos veces durante una llamada activa para activar esta característica.

/image/gif/paws/7415/telecaster-trouble_8.gif

Nota: “” Abotono los parecer esto /image/gif/paws/7415/telecaster-trouble_9.gif.

Este menú proporciona la siguiente información:

  • RxType/TxType — El codecs utilizado actualmente en la conversación actual de la voz activa.

  • RxSize/TxSize — El tamaño del payload del codecs, en este caso 20 milisegundos de la Voz/del paquete.

    Nota: El soporte de los Teléfonos IP 79xx MGCP solamente un Tamaño de carga útil de 10-40 milisegundo.

  • RxCount/TxCount — Cantidad de paquetes enviados/recibidos.

  • AvgJtr — La fluctuación promedio es la fluctuación promedio estimada observada en los paquetes RTP del último 16 (la función que hace un promedio es apenas un filtro de permiso reducido simple).

  • MaxJtr — La fluctuación máxima es la fluctuación máxima considerada durante la vida del RTP recibe la secuencia. Recuerde que esto no es para la vida de la llamada, pero para la secuencia. Si usted pone a una persona en el control, la secuencia sale y necesita ser recomenzada y por lo tanto los nuevos valores aquí.

  • RxDisc — El número de paquetes desechó entrante en este Cisco IP Phone 79xx.

  • RxLost — El número de paquetes que no llegaron entrante en este Cisco IP Phone 79xx.

Cosas a enfocarse encendido para resolver problemas:

  • El RxType/TxType le dice qué codificador-decodificador se está utilizando para la conversación entre este teléfono del IP y el otro dispositivo. Vea si hacen juego en los ambos lados. Si no hacen juego, verifique que el otro dispositivo pueda manejar la conversación de códecs o que un transcoder existe manejar el servicio.

  • El tamaño de las muestras de sonido debe hacer juego en ambos dispositivos. Esto se encuentra en los campos RxSize/TxSize.

  • El RxCount/TxCount es útil para resolver problemas los paquetes perdidos, los problemas de una Voz de la manera, y la detección de actividad de la Voz (VAD).

Fluctuación

En el mundo de la Voz, el jitter se relaciona con el intervalo inter de los paquetes en la red. Idealmente, los paquetes de voz se deben recibir síncrono con (pero no demasiado de largo) un retardo constante. Desafortunadamente, la mayoría de las redes entregan el asynchronously de los paquetes de voz. Es decir hay una variación en el tiempo entre los paquetes de voz. Esto se refiere como jitter. Cuando el tiempo entre los paquetes de voz (jitter) varía más allá de memorias intermedias de reproducción completa en el dispositivo receptor, la Parte llamada oirá los intervalos en la secuencia de voz.

En un mundo ideal, una secuencia de los paquetes que contienen la Voz llegaría el dispositivo extremo (Parte llamada) con exactamente la misma cantidad de brecha entre paquetes. Esto daría lugar a un valor del jitter de 0. En el mundo real, el intervalo entre los paquetes de voz puede variar del paquete al paquete que introduce el jitter en la secuencia.

Para hacer frente a este problema, los teléfonos 79xx contienen un primero en entrar, la cola del primero en salir ((Primero en Entrar, Primero en Salir FIFO)) que actúa como almacén intermedio del paquete elástico. Intenta guardar el flujo de paquetes de voz a los constantes DSP realizando los paquetes con una brecha entre paquetes constante. Esto ayuda a asegurar la Calidad de voz aceptable. El buffer del jitter 79xx manejará hasta dos segundos de jitter. El jitter se mide en el ms.

Si la brecha entre paquetes de una secuencia de voz entrante varía entre 0 ms y 2 s, memoria intermedia primero en entrar, primero en salir 79xx's podrá enmascarar esta variación y no se detectará ningunos intervalos en la secuencia de voz entrante por la Parte llamada. Por otra parte, si una secuencia de voz entrante experimenta una brecha entre paquetes superior a 2 s, memoria intermedia primero en entrar, primero en salir 79xx's habrá sido drenada mientras que espera los paquetes de voz siguientes. En esta situación abre en la secuencia de voz será detectado. Esto se explica más detalladamente abajo.

En el ejemplo debajo de cada paquete tiene exactamente la misma cantidad de retardo entre ella y el próximo paquete en la secuencia. En este caso el valor de retraso constante entre los paquetes (ms 5) da lugar a un valor del jitter de 0.

/image/gif/paws/7415/telecaster_trouble_1.gif

En una situación de la red real el retardo de los entre paquetes es raramente constante:

/image/gif/paws/7415/telecaster_trouble_2.gif

Mientras que una secuencia de los paquetes de voz pasa a través de los buffers de cualquier Routers y Switches que existan entre la fuente y el destino, los intervalos se insertan entre los paquetes. Estos intervalos variarán de tamaño porque la carga en el Routers y el Switches entre la fuente y el destino cambiará constantemente.

En el diagrama antedicho podemos ver el rango de la brecha entre paquetes a partir del 5 a 14 a 10. Los dispositivos extremos en la red (Teléfonos IP en este caso) tienen que compensar estas variaciones para realizar los paquetes al módulo de escucha (Parte llamada) a una velocidad constante. Esto requiere que memorias intermedias primero en entrar, primero en salir tengan siempre paquetes de voz disponibles realizarse.

El tamaño de memoria intermedia primero en entrar, primero en salir 79xx's varía basado en la cantidad de jitter experimentada en la secuencia de voz entrante. Si el valor del jitter de una secuencia de voz entrante es bajo, el 79xx utilizará memoria intermedia primero en entrar, primero en salir más pequeña que cuando el valor del jitter de una secuencia de voz entrante es alto. Es posible sin embargo, eso que la velocidad de cambio en el valor del jitter será más rápida que el 79xx puede hacer frente a. En este caso, el módulo de escucha (Parte llamada) experimentará un intervalo abreviado en la secuencia de voz mientras que el 79xx ajusta su tamaño de búfer FIFO.

Nota: El Cisco IP Phone 79xx aumenta el tamaño de búfer FIFO rápidamente y lo disminuye lentamente.

El tamaño de memoria intermedia primero en entrar, primero en salir tiene un efecto directo en el retardo entre los paquetes de voz que son enviados y que son recibidos por el destino. Mientras que memoria intermedia primero en entrar, primero en salir crece más grande, el retardo en memoria intermedia primero en entrar, primero en salir móvil de los de los paquetes aumenta. Vea la siguiente sección en el retardo para más información sobre este tema.

El diagrama siguiente muestra memoria intermedia primero en entrar, primero en salir que quita el jitter de una secuencia de voz entrante.

telecaster_trouble_3.gif

Si usted está experimentando los intervalos en sus llamadas de voz (recortes) marcan los valores de AvgJtr y de MaxJtr. Si, por ejemplo, el valor de la fluctuación promedio es 5 y el valor de la fluctuación máxima es 3000, hay una ocasión de un problema porque la variación entre los dos valores es muy alta. Si sucedió esto rápidamente, no pudo haber habido bastante tiempo para que la cola primero en entrar, primero en salir 79xx's compense. Este tipo de conducta puede ser encontrado en las redes que tienen altas tasas de actividad periódica tales como actualizaciones de la tabla de ruteo o transferencias de archivo por lote grandes. En estas cargas de tráfico de los casos vaya de bajo o de medio a alto y de posterior otra vez en mismo un período corto.

Nota: El Cisco IP Phone 79xx puede manejar típicamente el hasta 20 por ciento de pérdida del paquete sin la notable degradación de la calidad.

Demora

El retardo es la cantidad de tiempo que lleva los paquetes de voz (o la secuencia de voz) para viajar de la fuente el destino. En la mayoría de los casos el retardo variará a lo largo de una secuencia de voz (conversación). En una red correctamente ajustada, el retardo máximo entre el tiempo que una parte llamadora habla y la Parte llamada oye que lo que fue dicha es menos que lo que la persona media puede detectar. Es decir no hay retardo perceptible en la conversación - se oyen las palabras tan pronto como se hablen.

El retardo a través de la red aumentará en algunos casos a un nivel que sea perceptible por el oído humano. En un peor de los casos la conversación deteriorará a la punta donde cada persona tiene que indicar que han parado el discurso de modo que la otra persona sepa que pueden hablar sin la interrupción por los paquetes de voz que todavía no se han recibido. Si usted es familiar con los Ethernetes usted puede ser que llame este comportamiento un late collision.

Todas las redes imponen un cierto retardo en la transmisión de paquetes de la fuente al destino. Incluso una red con una brecha entre paquetes constante de < 1ms experimentará un cierto retardo en el tiempo entre cuando un dispositivo de origen envía un paquete y el dispositivo de destino lo recibe. Los links seriales despacio (64K y abajo) crean más retardo que un link de alta velocidad tal como un OC12 debido al tiempo que toma para serializar los bits sobre el medio de transmisión.

Las variaciones en el retardo son causadas por las mismas situaciones que llevan a las brechas entre paquetes largas según lo descrito en la sección en el jitter arriba. En el caso del retardo, sin embargo, las causas duran típicamente más de largo que algunos paquetes de voz. En vez de causar un aumento en la brecha entre paquetes para algunos paquetes en una conversación, estos problemas afectan a las conversaciones enteras.

Nota: El Cisco IP Phone 79xx no proporciona un contador del retardo. El retardo se puede medir por los analizadores de red y otros dispositivos de administración de red.

Los problemas de retraso menor no afectan a la Calidad de voz tan gravemente como puede el jitter. Esto es porque el jitter puede causar las roturas en la secuencia de voz donde las palabras habladas enteras pueden ser perdidas, mientras que con el retardo, llegarán todas las palabras habladas eventual. Es decir el jitter es muy similar a la pérdida del paquete en una red inscrita excesiva - los paquetes encima fluyen los buffers de la interfaz y consiguen caídos, así que significa que nunca llegan el destino.

El diagrama a continuación muestra el efecto combinado del retardo con el jitter, que van de común acuerdo. Los paquetes se transmiten a una velocidad constante. La red del IP no remite los paquetes como rápidamente o constantemente, que ha dado lugar a brechas entre paquetes más grandes y variadas. Además, el cuarto paquete todavía está en alguna parte en la red.

telecaster_trouble_6.gif

El retraso cumulativo en una red depende de cuánto conmuta el router y su tráfico necesita pasar a través entre la fuente y el destino de cualquier conversación.

En un entorno IP, una manera de medir el retardo sería utilizar la herramienta del traceroute, pero ésta trabajará solamente para los saltos del router. Además, algunos host que soportan el traceroute lo ejecutan en una prioridad de la CPU muy baja, que ayuda durante un ataque de Negación de servicio (DoS). Esto significa que hay un retardo impuesto de parte del CPU que será agregado al tiempo a que los paquetes tomaron para ir a partir de un salto a otro. Es decir - no ponga mucha fe en los números señalados por el traceroute.

Hay las herramientas de Análisis de red de tercera persona que pueden enviar los paquetes y el retardo de la medida abajo al nanosegundo. Son muy útiles para probar los prototipos del diseño de red bajo condiciones cargadas antes de implementarlas. Debe ser observado sin embargo que una red de voz robusta, bien diseñada y ajustada no debe tener problemas constantes de la fluctuación y retraso.


Información Relacionada


Document ID: 7415