Descifrar el flujo RTP para el análisis de pérdida de paquetes en Wireshark para llamadas de voz y vídeo

Opciones de descarga

PDF (1.2 MB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (836.1 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (945.8 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:28 de julio de 2014

ID del documento:117881

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Introducción

Problema

Introducción

Este documento describe el proceso de descifrar el flujo de transmisión en tiempo real (RTP) para el análisis de pérdida de paquetes en Wireshark para llamadas de voz y vídeo. Puede utilizar los filtros de Wireshark para analizar las capturas de paquetes simultáneas realizadas en o cerca del origen y el destino de una llamada. Esto es útil cuando debe resolver problemas de calidad de audio y vídeo cuando se sospechan pérdidas de red.

Problema

Este ejemplo utiliza este flujo de llamada:

Teléfono IP A (sitio centralA) > Switch 2960 > Router > Router WAN (sitio central) > IPWAN > Router WAN (sitio B) > Router > 2960 > Teléfono IP B

En este escenario, el problema encontrado es que las videollamadas desde el teléfono IP A al teléfono IP B dan como resultado una mala calidad de vídeo desde el sitio central A a la sucursal B, donde central tiene buena calidad pero el lado de la sucursal tiene problemas.

Vea el receptor perdió paquetes en las estadísticas de transmisión del teléfono IP de la sucursal:

Solución

La mala calidad se ve solamente en el lado de la sucursal y como el sitio central ve una buena imagen, parece que el flujo de la central a la sucursal parece estar perdiendo paquetes por la red.

IP addressing scheme
Central IP phone: 192.168.10.146
Central Gateway: 192.168.10.253
Central WAN router: 192.168.10.254
Branch WAN router: 192.168.206.210
Branch Gateway: 192.168.206.253
Branch IP phone: 192.168.207.231

Las capturas de paquetes se realizan en el router WAN central y de la sucursal y la WAN descarta estos paquetes. Céntrese en el flujo RTP desde el teléfono IP central (192.168.10.146) hasta el teléfono IP de sucursal (192.168.207.231). Este flujo pierde paquetes en el router WAN de la sucursal si la WAN descarta los paquetes en el flujo desde el router WAN central al router WAN de la sucursal. Utilice las opciones de filtro de Wireshark para aislar el problema:

Abra la captura en wireshark.
Utilice el filtro ip.src==192.168.10.146 && ip.dst==192.168.207.231. Esto filtra todos los flujos UDP del teléfono IP central al teléfono IP de la sucursal.
Realice el análisis en la captura del lado de la bifurcación solamente pero tenga en cuenta que debe realizar estos pasos para la captura central también.
En esta captura de pantalla, el flujo UDP se filtra entre las direcciones IP de origen y de destino y contiene dos secuencias UDP (diferenciadas por los números de puerto UDP). Esta es una videollamada, por lo que hay dos transmisiones: audio y vídeo. En este ejemplo, las dos secuencias son:
- Flujo 1: Puerto de origen UDP: 20560, puerto de destino: 20800
- Flujo 2: Puerto de origen UDP: 20561, puerto de destino: 20801
Seleccione un paquete de una de las secuencias y haga clic con el botón derecho del ratón en el paquete.
Seleccione Decodificar como... y escriba RTP.
Haga clic en Aceptar y Aceptar para decodificar la secuencia como RTP.

Se queda con una secuencia decodificada como RTP y la otra como UDP no decodificado.
Seleccione un paquete de la secuencia sin decodificar y descodificarlo como RTP. Esto decodifica tanto el audio como los flujos de vídeo en RTP.

Nota: La secuencia de audio está en formato de códec G.722 y el tipo de carga útil Dynamic-RTP-97 indica la secuencia RTP de vídeo.

El problema ahora es sólo con la calidad del vídeo. Céntrese en el flujo RTP de vídeo y utilice los números de puerto UDP para este flujo para filtrar otras secuencias.
Vea el número de puerto seleccionando uno de los paquetes que muestra la información del puerto UDP en el panel inferior de la utilidad Wireshark. En la captura de pantalla anterior, se selecciona uno de los paquetes de la secuencia de vídeo y puede ver la información del puerto Src (20568) y del puerto Dst (20808) en el panel inferior.

Consejo: Utilice este filtro: (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 y udp.port eq 20808). Solo verá la secuencia RTP de vídeo que se muestra en esta captura de pantalla.

Nota: Anote los primeros y últimos números de secuencia RTP para esta secuencia.

El primer número de secuencia RTP es 45514 y el último es 50449 para el flujo RTP de vídeo filtrado.
Asegúrese de que los primeros y últimos paquetes de número de secuencia RTP estén presentes en ambas capturas.por ejemplo, capturas centrales y de rama) y observe que el SSRC para el flujo sería el mismo en ambas capturas.
Refinar el filtro para que coincida sólo con los paquetes entre los flujos RTP primero y último.

Los números de secuencia se utilizan para refinar la secuencia en caso de que las capturas no se hayan tomado simultáneamente, pero con un ligero retraso entre ellas.

Nota: Es posible que la sucursal inicie algunos números de secuencia después de 45514.
Seleccione un número de secuencia inicial y final. Estos paquetes están presentes tanto en las capturas como en la refinación del filtro para mostrar solamente esos paquetes entre los números de secuencia RTP inicial y final. El filtro para esto es:
```
(ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 
 and udp.port eq 20808) && ( rtp.seq>=44514 && rtp.seq<=50449 )
```
Cuando se toman capturas simultáneamente, no se pierden paquetes al principio o al final en ambas capturas. Si ve que una de las capturas no incluye algunos paquetes en el inicio/fin, utilice el primer número de secuencia o el último número de secuencia en la captura perdida en ambos paquetes para refinar el filtro para ambas capturas. Observe los paquetes que capturaron en ambos puntos entre los mismos números de secuencia (rango de números de secuencia RTP).

Cuando aplica el filtro, lo ve en el sitio central y en el sitio de la sucursal:

Sitio central:

Sucursal:

Observe el recuento de paquetes filtrados en el panel inferior de la utilidad Wireshark en ambas capturas. El conteo Mostrado indica el número de paquetes que coinciden con los criterios de filtro deseados.

El sitio central tiene 4,936 paquetes que coinciden con los criterios de filtro deseados entre los números de secuencia RTP inicial (45514) y final (50449) mientras que en el sitio de la sucursal hay sólo 4,737 paquetes. Esto indica una pérdida de 199 paquetes. Tenga en cuenta que estos 199 paquetes coinciden con el recuento "Rcvr Lost Pkts" de 199 que se vio en las estadísticas de streaming del teléfono IP del lado de la sucursal que se muestran al inicio de este documento.

Esto confirma que todos los paquetes perdidos de Rcvr fueron pérdidas de red descartadas a través de la WAN. Así es como se aísla el punto de pérdida de paquetes en la red mientras se gestionan los problemas de calidad de audio/vídeo que implican caídas sospechosas de la red.