Calidad de servicio (QoS) : Real-Time Protocol (RTP)

Descifre la secuencia RTP para el análisis de la pérdida del paquete en Wireshark para las llamadas de la Voz y del vídeo

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

Contenidos
          Introducción
          Problema
          Solución

Introducción

Este documento describe el proceso de cómo descifrar la secuencia en tiempo real del (RTP) que fluye para el análisis de la pérdida del paquete en Wireshark para las llamadas de la Voz y del vídeo. Usted puede utilizar los filtros de Wireshark para analizar a las capturas de paquetes simultáneas tomadas en o cerca de la fuente y del destino de una llamada. Esto es útil cuando usted debe resolver problemas los problemas del audio y de calidad del video cuando se sospechan las pérdidas de la red.

Contribuido por Shyam Venkatesh, ingeniero de Cisco TAC.

Problema

Este ejemplo utiliza este flujo de llamada:

Teléfono del IP A (siteA central) > 2960 Switch > router de WAN del Router> (sitio central) > IPWAN > router de WAN (sitio B) > Router> 2960 > teléfono del IP B

En este escenario, el problema encontrado es que el vídeo llama el resultado del teléfono del IP A a del teléfono del IP B en el mún calidad del video del sitio central A al sitio secundario B en donde la central tiene buena calidad pero el lado de la bifurcación tiene problemas.

Vea los paquetes perdidos receptor en las estadísticas que fluyen del teléfono del IP de la bifurcación:

Solución

La mala calidad se considera solamente en el lado de la bifurcación y porque el sitio central ve una buena imagen, parece la secuencia de la central al sitio secundario parece ser paquetes perdidosos sobre 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

Toman en la central y ramifican las capturas de paquetes router de WAN y WAN cae estos paquetes. Céntrese en la secuencia RTP del teléfono del IP central (192.168.10.146) para ramificar el teléfono del IP (192.168.207.231). Esta secuencia falta los paquetes en el router de WAN de la bifurcación si WAN cae los paquetes en la secuencia del router de WAN central para ramificar router de WAN. Utilice las opciones de filtro en el wireshark de aislar el problema:

  1. Abra la captura en el wireshark.

  2. Utilice el && ip.dst==192.168.207.231 del filtro ip.src==192.168.10.146. Esto filtra hacia fuera todas las secuencias UDP del teléfono del IP central para ramificar teléfono del IP.

  3. Realice el análisis en la captura del lado de la bifurcación solamente pero obsérvele debe realizar estos pasos para la captura central también.

  4. En este tiro de pantalla, la secuencia UDP se filtra entre la fuente y los IP Address de destino y contiene dos secuencias UDP (distinguidas por los números del puerto UDP). Esto es una llamada video tan allí es dos secuencias: audio y vídeo. En este ejemplo, las dos secuencias son:

    • Secuencia 1: Puerto de origen UDP: 20560, puerto destino: 20800

    • Secuencia 2: Puerto de origen UDP: 20561, puerto destino: 20801



  5. Seleccione un paquete a partir de la una de las secuencias y haga clic con el botón derecho del ratón el paquete.

  6. Selecto decodifique como… y teclee el RTP.

  7. El tecleo valida y aprueba para decodificar la secuencia como RTP.



    Le dejan con una secuencia decodificada como RTP y la otra como UDP undecoded.



  8. Seleccione un paquete de la secuencia undecoded y decodifiqúelo como RTP. Esto decodifica el audio y los secuencia de video en el RTP.

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





    El problema ahora está solamente con el calidad del video. Céntrese en la secuencia del vídeo RTP y utilice los números del puerto UDP para que esta secuencia filtre hacia fuera otras secuencias.

  9. Vea el número del puerto seleccionando uno de los paquetes que visualice la información de puerto UDP en el cristal inferior en la utilidad de Wireshark. En el tiro de pantalla anterior, uno de los paquetes del secuencia de video se selecciona y usted puede ver el puerto del src (20568) e informaciones del puerto del dst (las 20808) sobre el cristal inferior.

    Consejo: Utilice este filtro: (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (eq 20568 udp.port y eq 20808 udp.port). Usted verá solamente la secuencia del vídeo RTP mostrada en este tiro de pantalla.



    Nota: Anote el primer y los números de secuencia del último RTP para esta secuencia.







    El primer número de secuencia RTP es 45514 el último es 50449 para hacia fuera filtrada la secuencia video RTP.

  10. Aseegurese que el primer y los paquetes del número de secuencia del último RTP están presentes en el ejemplo ambos captures.for, la central y las capturas de la bifurcación) y observan que el SSRC para el secuencia sería lo mismo en ambos las capturas.
  11. Refine el filtro para hacer juego solamente los paquetes entre los primeros y las secuencias del último RTP. 

    Los números de secuencia se utilizan para refinar la secuencia en caso de que las capturas no fueran tomadas simultáneamente, pero con el leve retraso entre ellos.

    Nota: Es posible que el sitio secundario pudo encender algunos números de secuencia después de 45514.



  12. Seleccione un comienzo y termine el número de secuencia. Estos paquetes están presentes en las capturas y refinan el filtro para visualizar solamente esos paquetes entre el comienzo y los números de secuencia del extremo RTP. 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 las capturas se toman simultáneamente, no se falta al principio ni terminan ningunos paquetes en ambas capturas. Si usted ve que una de las capturas no incluye algún al principio/extremo de los paquetes, utilice el primer número de secuencia o el número de secuencia más reciente en la captura faltada en ambos paquetes para refinar el filtro para ambas las capturas. Observe los paquetes que capturaron en ambas puntas entre los mismos números de secuencia (rango del número de secuencia RTP).

    Cuando usted aplica el filtro, usted ve esto en el sitio central y el sitio secundario:

    Sitio central:



    Sitio secundario:



    Observe la cuenta de paquetes filtrada en el cristal inferior en la utilidad de Wireshark en ambas capturas. La cuenta visualizada indica el número de paquetes que corresponden con los criterios deseados del filtro.

    El sitio central tiene 4,936 paquetes que hagan juego los criterios deseados del filtro entre el comienzo (45514) y los números de secuencia del extremo (50449) RTP mientras que en el sitio secundario hay solamente 4,737 paquetes. Esto indica una pérdida de 199 paquetes. Observe que estos 199 paquetes hacen juego “Rcvr perdieron la cuenta del pkts” de 199 que fue considerada en las estadísticas que fluían del teléfono del IP del lado de la bifurcación mostrado al inicio de este documento.

    Esto confirma que todos los paquetes perdidos Rcvr eran realmente pérdidas de la red caídas a través de WAN. Éste es cómo la punta de la pérdida del paquete en la red se aísla mientras que los problemas del audio/de calidad del video se manejan que implican los descensos sospechosos de la red.


Document ID: 117881