Introduction
Ce document décrit comment dépanner les problèmes audio liés au réseau dans un environnement de voix sur IP (VoIP).
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- QoS
- Réseaux VoIP
- SPAN (Analyseur de port de commutation)
- Wireshark
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Catalyst 9200
- Catalyst 9300
- Catalyst 9400
- Catalyst 9500
- Catalyst 9600
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Dans une infrastructure VoIP, la qualité de l'audio peut être affectée par des problèmes liés au réseau, dont les symptômes incluent :
- Intervalles intermittents dans la voix ou le son instable.
- Audio unidirectionnel.
- Non pas isolée pour un seul utilisateur, mais pour un groupe d’utilisateurs qui ont des caractéristiques communes, comme le partage du même VLAN ou le partage du même commutateur d’accès.
Afin de résoudre les problèmes liés au réseau, il est important d'avoir une topologie claire de la source à la destination des paquets vocaux. Le diagnostic du problème peut commencer à n’importe quel point du réseau où les paquets vocaux sont commutés ou routés. Toutefois, il est recommandé de commencer le dépannage au niveau de la couche d’accès et de passer à la couche de routage.
Diagramme du réseau
Sélectionnez un point de capture dans le tracé. Il peut s'agir de A (le plus proche d'un téléphone IP), B (avant le routage), C (le plus proche de la destination).
La capture SPAN est normalement prise dans les deux sens (TX et RX) afin d'identifier les deux côtés de la conversation et d'extraire l'audio respectif, ainsi que d'autres variables telles que la gigue, ou la perte de paquets, de la capture pour une analyse ultérieure.
Après avoir déterminé le point de capture, configurez la fonctionnalité SPAN sur le commutateur.
Switch(config)#monitor session 1 source interface Gig1/0/1 both
Switch(config)#monitor session 1 destination interface Gig1/0/6 encapsulation replicate
Switch#show monitor session all
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/6
Encapsulation : Replicate
Ingress : Disabled
Lancez un appel test pour capturer le flux audio à partir du point de capture choisi sur un PC/ordinateur portable avec Wireshark.
Analyse de capture
1. Ouvrez la capture de paquets effectuée à l’aide de Wireshark et accédez à Statistiques > Conversations. Recherchez la conversation audio en fonction de l'adresse IP des périphériques concernés (source et destination du téléphone IP).
2. Normalement, les flux audio sont transportés par le protocole UDP, et la plupart du temps, ils ne sont pas décodés dans le format approprié pour Wireshark pour extraire l’audio qui y est incorporé. Ensuite, l'étape suivante consiste à décoder le flux UDP au format audio, par défaut RTP est utilisé. Cliquez avec le bouton droit sur n'importe quel paquet du flux, puis cliquez sur Decode as.
3. Recherchez la colonne Current et choisissez RTP. Cliquez sur OK.
Wireshark décode l’ensemble du flux UDP en RTP et nous pouvons maintenant analyser son contenu.
Attention : RTP Player peut lire n'importe quel codec pris en charge par un plug-in installé. Les codecs pris en charge par le lecteur RTP dépendent de la version de Wireshark que vous utilisez. Les builds officielles contiennent tous les plugins maintenus par les développeurs Wireshark, mais les builds personnalisées/de distribution ne contiennent pas certains de ces codecs. Pour vérifier vos plug-ins de codec Wireshark installés, procédez comme suit : Ouvrez Aide > À propos de Wireshark. Sélectionnez l'onglet Plugins. Dans le menu Filtrer par type, sélectionnez Codec.
4. Vérifiez les statistiques RTP pour voir s'il y a une gigue ou une perte dans le flux audio. Pour afficher l'analyse, accédez à Telephony > RTP > RTP Stream Analysis.
Jitter : est le délai d'envoi des paquets vocaux sur le réseau. Cela est souvent dû à un encombrement du réseau ou à des changements de route. Cette mesure doit être < 30 ms.
Lost : paquets qui n'ont pas été reçus dans le cadre du flux audio. La perte de paquets ne doit pas être supérieure à 1 %.
5. Convertissez l'onde audio de ce flux dans Téléphonie > RTP > Flux RTP
6. Sélectionnez le flux pour le convertir en audio et cliquez sur Lire les flux.
Une onde audio doit apparaître et le bouton de lecture est disponible pour écouter les données audio. L'écoute de l'audio permet d'identifier les éventuels problèmes de voix instable ou d'audio unidirectionnel avec les flux.
7. Exportez le flux dans un fichier audio avec l'extension .wav en cliquant dans Export > File Synchronized Audio.
Dépannage
Après avoir utilisé la fonctionnalité SPAN pour collecter et analyser la capture avec Wireshark, nous saurions si le problème peut être lié à la gigue, à la perte de paquets ou à l'audio unidirectionnel. Si des problèmes sont détectés dans les captures de paquets, l’étape suivante consiste à vérifier le périphérique sur lequel la capture a été effectuée pour détecter d’éventuels problèmes courants pouvant avoir un impact sur un flux audio RTP.
Son instable
Une bande passante insuffisante, une gigue et/ou une perte de paquets peuvent être des causes courantes d'une voix cassée ou d'une distorsion dans la capture audio.
1. Vérifiez si la gigue de la capture est > 30 ms. Si tel est le cas, cela indique un délai de réception des paquets qui peut être causé par des politiques de QoS ou des problèmes de routage.
2. Vérifiez si le paquet perdu lors de la capture est supérieur à 1 %. Si cette valeur est élevée, vous devez rechercher les pertes de paquets le long du chemin du flux de flux audio.
3. Recherchez les abandons sur les interfaces d’entrée et de sortie impliquées dans le chemin.
Switch#show interface Gi1/0/1 | inc drops
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops
Switch#show interfaces Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Gi1/0/1 0 0 0 0 0 0
Vérifiez qu'il n'y a pas d'incrémentation des pertes d'entrée/sortie ou d'autres erreurs d'incrémentation sur les interfaces.
4. Vérifiez la stratégie de sortie QoS sur les interfaces impliquées dans le chemin. Assurez-vous que votre trafic est mappé/classé dans la file d'attente Priorité et qu'il n'y a pas de pertes dans cette file d'attente.
Switch#show platform hardware fed switch 1 qos queue stats interface Gi1/0/1
----------------------------------------------------------------------------------------------
AQM Global counters
GlobalHardLimit: 3976 | GlobalHardBufCount: 0
GlobalSoftLimit: 15872 | GlobalSoftBufCount: 0
----------------------------------------------------------------------------------------------
High Watermark Soft Buffers: Port Monitor Disabled
----------------------------------------------------------------------------------------------
Asic:0 Core:1 DATA Port:0 Hardware Enqueue Counters
----------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
-- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 707354 2529238 0 <<< Priority Q
1 0 0 0 1858516 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
Asic:0 Core:1 DATA Port:0 Hardware Drop Counters
--------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
-- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0 <<< Priority Q Drops
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
Remarque : si des abandons sont présents, assurez-vous de profiler correctement le trafic vocal avec les marquages EF (Expedite Forwarding) DSCP et vérifiez qu'aucun autre flux indésirable n'a été marqué par erreur avec le bit EF, ce qui encombre la file d'attente Priority.
Son unidirectionnel
Lorsqu'un appel téléphonique est établi, seul l'un des interlocuteurs reçoit l'audio. Les causes courantes de ce problème sont liées à des problèmes d'accessibilité, de routage ou de NAT/pare-feu.
1. Envoyez une requête ping au sous-réseau de destination ou à la passerelle de destination pour confirmer l’accessibilité bidirectionnelle.
Switch#ping 192.168.1.150
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.150, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
2. Effectuez une commande traceroute depuis le sous-réseau source vers le sous-réseau de destination et inversement. Cela peut aider à vérifier combien de sauts se trouvent dans le chemin et s'il est symétrique.
Switch#traceroute 192.168.1.150
Type escape sequence to abort.
Tracing the route to 192.168.1.150
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.2.12 2 msec * 1 msec
2 192.168.1.12 2 msec * 1 msec
3 192.168.1.150 2 msec 2 msec 1 msec
3. Vérifiez que le périphérique de passerelle de chaque sous-réseau dispose d’un routage optimal et qu’aucun chemin asymétrique n’affecte potentiellement la communication.
Conseil : les problèmes audio unidirectionnels courants sont liés à des listes de contrôle d'accès mal configurées sur des règles de pare-feu ou des problèmes NAT. Il est conseillé de vérifier si ces éléments peuvent affecter le flux du flux audio.
4. Effectuez une capture de paquets sur le dernier périphérique dans lequel le trafic audio a été détecté pour la direction défaillante. Cela peut aider à isoler dans quel périphérique du chemin le flux audio a été perdu. Ceci est important car le trafic ping peut être autorisé via NAT ou un pare-feu, mais le trafic audio spécifique peut être bloqué ou mal traduit.
Informations connexes