Déterminez le flux RTP pour l'analyse des pertes de paquets dans Wireshark pour les appels vocaux et vidéo

Options de téléchargement

PDF (1.2 MB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (836.6 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (946.2 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:28 juillet 2014

ID du document:117881

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Contenu

Introduction

Problème

Introduction

Ce document décrit le processus de déchiffrement du flux RTP (Real-Time Streaming) pour l'analyse de perte de paquets dans Wireshark pour les appels vocaux et vidéo. Vous pouvez utiliser des filtres Wireshark afin d'analyser les captures de paquets simultanées prises à la source et à la destination d'un appel ou à proximité de celle-ci. Cela est utile lorsque vous devez résoudre des problèmes de qualité audio et vidéo lorsque vous soupçonnez des pertes de réseau.

Problème

Cet exemple utilise ce flux d'appels :

Téléphone IP A (site central A) > Commutateur 2960 > Routeur > Routeur WAN (site central) > IPWAN > Routeur WAN (site B) > Routeur > 2960 > Téléphone IP B

Dans ce scénario, le problème rencontré est que les appels vidéo du téléphone IP A au téléphone IP B entraînent une mauvaise qualité vidéo du site central A au site de filiale B, où le site central est de bonne qualité, mais où le côté succursale présente des problèmes.

Reportez-vous à la section Réception des paquets perdus dans les statistiques de diffusion du téléphone IP de la filiale :

Solution

La mauvaise qualité n'est visible que du côté de la succursale et comme le site central voit une bonne image, il semble que le flux du site central vers le site de la succursale semble perdre des paquets sur le réseau.

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

Les captures de paquets sont prises sur le routeur WAN central et de filiale et le WAN abandonne ces paquets. Concentrez-vous sur le flux RTP du téléphone IP central (192.168.10.146) au téléphone IP de filiale (192.168.207.231). Ce flux manque des paquets sur le routeur WAN de la filiale si le WAN abandonne les paquets sur le flux du routeur WAN central au routeur WAN de la filiale. Utilisez les options de filtre de wireshark pour isoler le problème :

Ouvrez la capture dans Wireshark.
Utilisez le filtre ip.src==192.168.10.146 && ip.dst==192.168.207.231. Cela filtre tous les flux UDP du téléphone IP central au téléphone IP de filiale.
Effectuez l'analyse sur la capture côté succursale uniquement, mais notez que vous devez également effectuer ces étapes pour la capture centrale.
Dans cette capture d'écran, le flux UDP est filtré entre les adresses IP source et de destination et contient deux flux UDP (différenciés par les numéros de port UDP). Il s'agit d'un appel vidéo, il y a donc deux flux : audio et vidéo. Dans cet exemple, les deux flux sont :
- Flux 1 : Port source UDP : 20560, port de destination : 20800
- Flux 2 : Port source UDP : 20561, port de destination : 20801
Sélectionnez un paquet dans l'un des flux et cliquez avec le bouton droit sur le paquet.
Sélectionnez Décoder en tant que... et tapez RTP.
Cliquez sur Accept et Ok afin de décoder le flux en tant que RTP.

Vous restez avec un flux décodé en tant que RTP et l'autre en tant qu'UDP non décodé.
Sélectionnez un paquet dans le flux non décodé et décodez-le en tant que RTP. Cela décode les flux audio et vidéo dans RTP.

Remarque : le flux audio est au format de codec G.722 et le type de charge utile Dynamic-RTP-97 indique le flux RTP vidéo.

Le problème est maintenant uniquement lié à la qualité vidéo. Concentrez-vous sur le flux vidéo RTP et utilisez les numéros de port UDP de ce flux pour filtrer d'autres flux.
Affichez le numéro de port en sélectionnant l'un des paquets qui affiche les informations de port UDP dans le volet inférieur de l'utilitaire Wireshark. Dans la capture d'écran précédente, l'un des paquets du flux vidéo est sélectionné et vous pouvez voir les informations du port Src (20568) et du port Dst (20808) dans le volet inférieur.

Astuce : Utilisez ce filtre : (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port équip 20568 et udp.port équip 2080 ). Vous ne verrez que le flux vidéo RTP présenté dans cette capture d'écran.

Note: Notez les premiers et derniers numéros de séquence RTP pour ce flux.

Le premier numéro de séquence RTP est 45514 et le dernier est 50449 pour le flux RTP vidéo filtré.
Assurez-vous que les premiers et les derniers paquets de numéros de séquence RTP sont présents dans les deux captures (par exemple, les captures centrales et de filiale) et notez que le SSRC pour le flux serait le même sur les deux captures.
Affinez le filtre pour qu'il corresponde uniquement aux paquets entre le premier et le dernier flux RTP.

Les numéros de séquence sont utilisés pour affiner le flux au cas où les captures n'étaient pas prises simultanément, mais avec un léger retard entre elles.

Note: Il est possible que le site de la branche commence certains numéros d'ordre après 45514.
Sélectionnez un numéro de séquence de début et de fin. Ces paquets sont présents dans les captures et affinent le filtre pour afficher uniquement les paquets entre les numéros de séquence RTP de début et de fin. Le filtre pour ceci est :
```
(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 )
```
Lorsque des captures sont prises simultanément, aucun paquet n'est manqué au début ou à la fin des deux captures. Si vous voyez que l'une des captures n'inclut pas quelques paquets au début/à la fin, utilisez le premier numéro de séquence ou le dernier numéro de séquence de la capture manquée dans les deux paquets pour affiner le filtre des deux captures. Observez les paquets capturés aux deux points entre les mêmes numéros de séquence (plage de numéros de séquence RTP).

Lorsque vous appliquez le filtre, vous voyez ceci sur le site central et le site de la succursale :

Site central :

Site de la succursale :

Notez le nombre de paquets filtrés dans le volet inférieur de l'utilitaire Wireshark sur les deux captures. Le nombre affiché indique le nombre de paquets correspondant aux critères de filtre souhaités.

Le site central contient 4 936 paquets qui correspondent aux critères de filtre souhaités entre les numéros de séquence RTP de début (45514) et de fin (50449), tandis qu'au site de la filiale il n'y a que 4 737 paquets. Cela indique une perte de 199 paquets. Notez que ces 199 paquets correspondent au nombre de « Rcvr Lost Pkts » de 199 qui a été vu dans les statistiques de diffusion du téléphone IP côté succursale affichées au début de ce document.

Ceci confirme que tous les paquets perdus Rcvr étaient en fait des pertes de réseau abandonnées sur le WAN. C'est ainsi que le point de perte de paquets dans le réseau est isolé tandis que les problèmes de qualité audio/vidéo sont traités avec des suppositions de perte de réseau.