Decifrar o fluxo RTP para análise de perda de pacotes no Wireshark para chamadas de voz e vídeo

Opções de download

PDF (1.2 MB)
Ver no Adobe Reader em vários dispositivos
ePub (835.4 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (944.8 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:28 de Julho de 2014

ID do documento:117881

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Problema

Introduction

Este documento descreve o processo de como decifrar o fluxo RTP (Real-Time Streaming) para análise de perda de pacotes no Wireshark para chamadas de voz e vídeo. Você pode usar os filtros do Wireshark para analisar capturas simultâneas de pacotes feitas na origem e no destino de uma chamada ou perto dela. Isso é útil quando você precisa solucionar problemas de qualidade de áudio e vídeo quando houver suspeita de perda de rede.

Problema

Este exemplo usa este fluxo de chamada:

Telefone IP A (site centralA) > switch 2960 > Roteador > Roteador WAN (site central) > IPWAN > Roteador WAN (site B) > Roteador > 2960 > Telefone IP B

Neste cenário, o problema encontrado é que as chamadas de vídeo do telefone IP A para o telefone IP B resultam em má qualidade de vídeo do site central A para a filial B, onde a central tem boa qualidade, mas a filial tem problemas.

Veja o receptor perdeu pacotes nas estatísticas de transmissão do telefone IP da filial:

Solução

A má qualidade é vista apenas na filial e como o site central vê uma boa imagem, parece que o fluxo da central para a filial parece estar perdendo pacotes pela rede.

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

As capturas de pacotes são feitas no roteador da WAN Central e da Filial e a WAN descarta esses pacotes. Foco no fluxo de RTP do telefone IP central (192.168.10.146) para o telefone IP da filial (192.168.207.231). Esse fluxo perde pacotes no roteador da WAN da filial se a WAN descartar os pacotes no fluxo do roteador da WAN central para o roteador da WAN da filial. Use as opções de filtro no wireshark para isolar o problema:

Abra a captura no wireshark.
Use o filtro ip.src==192.168.10.146 && ip.dst==192.168.207.231. Isso filtra todos os fluxos UDP do telefone IP central para o telefone IP da filial.
Execute a análise somente na captura do lado da filial, mas observe que você deve executar essas etapas para a captura central também.
Nesta captura de tela, o fluxo UDP é filtrado entre os endereços IP origem e destino e contém dois fluxos UDP (diferenciados pelos números de porta UDP). Esta é uma chamada de vídeo, portanto há dois fluxos: áudio e vídeo. Neste exemplo, os dois fluxos são:
- Fluxo 1: Porta de origem UDP: 20560, porta de destino : 20800
- Fluxo 2: Porta de origem UDP: 20561, porta de destino : 20801
Selecione um pacote de um dos fluxos e clique com o botão direito do mouse no pacote.
Selecionar Decodificar como... e digite RTP.
Clique em Aceitar e Ok para decodificar o fluxo como RTP.

Você é deixado com um fluxo decodificado como RTP e o outro como UDP não decodificado.
Selecione um pacote do fluxo não decodificado e decodifice-o como RTP. Isso decodifica os fluxos de áudio e vídeo no RTP.

Observação: o fluxo de áudio está no formato de codec G.722 e o tipo de payload Dynamic-RTP-97 indica o fluxo de vídeo RTP.

O problema agora está apenas na qualidade do vídeo. Concentre-se no fluxo de RTP de vídeo e use os números de porta UDP para esse fluxo para filtrar outros fluxos.
Visualize o número da porta selecionando um dos pacotes que exibe as informações da porta UDP no painel inferior do utilitário Wireshark. Na captura de tela anterior, um dos pacotes do fluxo de vídeo é selecionado e você pode ver as informações da porta Src (20568) e da porta Dst (20808) no painel inferior.

Tip: Use este filtro: (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 e udp.port eq 20808). Você verá apenas o fluxo de RTP de vídeo mostrado nesta captura de tela.

Note: Anote o primeiro e o último número de sequência RTP para este fluxo.

O primeiro número de sequência de RTP é 45514 e o último é 50449 para o fluxo de RTP de vídeo filtrado.
Certifique-se de que o primeiro e o último pacote de número de sequência RTP estejam presentes em ambas as capturas.por exemplo, capturas centrais e de ramificação) e observe que o SSRC para o fluxo seria o mesmo em ambas as capturas.
Refine o filtro para corresponder somente os pacotes entre o primeiro e o último fluxo de RTP.

Os números de sequência são usados para refinar o fluxo caso as capturas não tenham sido feitas simultaneamente, mas com um pequeno atraso entre elas.

Note: É possível que a filial inicie alguns números de sequência após 45514.
Selecione um número de sequência inicial e final. Esses pacotes estão presentes em ambas as capturas e refinam o filtro para exibir somente esses pacotes entre os números de sequência de RTP inicial e final. O filtro para isso é:
```
(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 )
```
Quando as capturas são feitas simultaneamente, nenhum pacote é perdido no início ou no fim das duas capturas. Se você vir que uma das capturas não inclui alguns pacotes no início/fim, use o primeiro número de sequência ou o último número de sequência na captura perdida em ambos os pacotes para refinar o filtro para ambas as capturas. Observe os pacotes capturados em ambos os pontos entre os mesmos números de sequência (intervalo de número de sequência RTP).

Ao aplicar o filtro, você vê isso no site central e na filial:

Site central:

Local da filial:

Observe a contagem de pacotes filtrados no painel inferior do utilitário Wireshark em ambas as capturas. A contagem exibida indica o número de pacotes que correspondem aos critérios de filtro desejados.

O local central tem 4.936 pacotes que correspondem aos critérios de filtragem desejados entre os números de sequência RTP de início (45514) e fim (50449), enquanto no local da filial há apenas 4.737 pacotes. Isso indica uma perda de 199 pacotes. Observe que esses 199 pacotes correspondem à contagem de "Rcvr Lost Pkts" de 199, vista nas estatísticas de transmissão do telefone IP da filial mostrada no início deste documento.

Isso confirma que todos os pacotes perdidos de Rcvr foram na verdade perdas de rede descartadas na WAN. É assim que o ponto de perda de pacotes na rede é isolado, enquanto os problemas de qualidade de áudio/vídeo são tratados com a suspeita de quedas de rede.