Diagnostic des Problèmes Audio (SDP & RTP)

Bonjour !

Dans la leçon précédente, nous avons appris à diagnostiquer les problèmes d'interopérabilité qui empêchent un appel de s'établir, comme les erreurs 415 Unsupported Media Type et 401 Unauthorized. Vous avez vu que la solution réside dans l'analyse fine du dialogue SIP.

Aujourd'hui, nous abordons un scénario encore plus courant et souvent plus frustrant : l'appel est établi avec succès (vous voyez un 200 OK dans les traces), mais personne n'entend rien (problème de "no audio") ou une seule personne entend l'autre ("one-way audio").

L'objectif de cette leçon est de vous apprendre à diagnostiquer les problèmes de média (no audio, one-way audio) en vérifiant la négociation SDP et les flux RTP. Nous allons passer du monde de la signalisation (SIP) au monde du média (RTP) pour comprendre pourquoi l'audio ne passe pas, même si l'appel est connecté.

1. La Source du Problème : La Négociation Média via SDP

Le protocole SIP, comme nous l'avons vu, ne fait que "téléphoner" pour établir, maintenir et terminer la session. Le "contrat" de la conversation elle-même est négocié via un autre protocole embarqué dans les messages SIP : le SDP (Session Description Protocol). C'est dans le SDP que les deux équipements se mettent d'accord sur les détails techniques du flux audio.

Les problèmes de "no audio" ou "one-way audio" proviennent presque toujours d'une mauvaise négociation ou d'un non-respect de ce contrat SDP.

L'Offre et la Réponse SDP

Deux lignes du SDP sont absolument critiques pour diagnostiquer les problèmes de média :

1. La ligne c= (Connection): c=IN IP4 192.168.1.10

   • Signification : "Envoie tes paquets RTP à cette adresse IP."
   • Problème typique : L'adresse IP spécifiée est une adresse privée (comme 192.168.x.x) alors que l'interlocuteur est sur Internet. Les paquets RTP sont envoyés vers une destination inaccessible, provoquant du "one-way audio". C'est un problème très courant dans les scénarios avec du NAT (Network Address Translation).

2. La ligne m= (Media): m=audio 49152 RTP/AVP 0 8 101

   • Signification : "Envoie tes paquets RTP sur ce port (ici, 49152), en utilisant un de ces codecs (ici, 0=PCMU, 8=PCMA, 101=DTMF)."
   • Problème typique : Le port spécifié est bloqué par un pare-feu quelque part entre les deux équipements. Les paquets RTP sont envoyés mais n'arrivent jamais à destination.

Le Rôle Clé du SBC en tant que B2BUA

Un SBC AudioCodes fonctionne comme un Back-to-Back User Agent (B2BUA). Il ne se contente pas de relayer les messages. Il termine l'appel d'un côté (Leg A) et en initie un tout nouveau de l'autre (Leg B).

Cela signifie qu'il y a deux négociations SDP distinctes :

1. Entre l'appelant (A) et le SBC.
2. Entre le SBC et l'appelé (B).

Un problème de "one-way audio" se produit quand la négociation réussit sur un segment, mais que les paquets RTP sont perdus sur un autre.

2. Capturer les Preuves : Le "Debug Recording" d'AudioCodes

Pour voir ce qui se passe réellement avec les flux média, les traces Syslog ne suffisent pas. Il nous faut une capture complète du trafic, incluant SIP et RTP. L'outil intégré d'AudioCodes pour cela est le Debug Recording.

La configuration du Debug Recording est une étape fondamentale du dépannage média. Sans elle, vous ne capturerez que la signalisation, ce qui est insuffisant pour diagnostiquer un "no audio".

3. L'Enquête : Analyse des Traces SIP et RTP

Une fois la capture réalisée, l'enquête commence dans Wireshark. Votre objectif est de vérifier la cohérence entre ce qui a été négocié dans le SDP et les flux RTP réellement échangés.

Pour vous familiariser avec les techniques d'analyse dans Wireshark, regardons une vidéo qui couvre les manipulations essentielles.

Méthodologie de Diagnostic en 3 Étapes

Étape 1 : Valider la Négociation SDP pour les deux segments

1. Filtrez par sip dans Wireshark.
2. Repérez le dialogue complet de l'appel (INVITE, 100, 180, 200 OK, ACK).
3. Segment A (Appelant -> SBC) :
   • Examinez l'INVITE de l'appelant et le 200 OK du SBC.
   • Vérifiez les adresses IP et les ports dans les lignes c= et m= de chaque message. L'adresse IP dans l'INVITE est-elle joignable par le SBC ? L'adresse du SBC dans le 200 OK est-elle joignable par l'appelant ?
4. Segment B (SBC -> Appelé) :
   • Faites de même pour l'INVITE émis par le SBC vers l'appelé et le 200 OK en retour.

Étape 2 : Analyser les Flux RTP

C'est ici que vous confirmerez votre diagnostic. Un appel standard traversant un SBC devrait générer quatre flux RTP :

• Flux 1 : Appelant A -> SBC (Entrant)
• Flux 2 : SBC -> Appelé B (Sortant)
• Flux 3 : Appelé B -> SBC (Entrant)
• Flux 4 : SBC -> Appelant A (Sortant)

Dans un cas de one-way audio de A vers B (A entend B, mais B n'entend pas A), vous constaterez probablement que les flux 3 et 4 existent, mais que les flux 1 et/ou 2 sont absents.

Le menu Telephony > RTP > RTP Streams de Wireshark est votre meilleur outil. Il vous listera tous les flux RTP détectés, avec leurs adresses source/destination, ports, SSRC (identifiant de flux) et des statistiques de qualité. Si un des quatre flux attendus manque, vous avez trouvé la source du problème.

Étape 3 : Corréler avec les Syslogs AudioCodes

Parfois, le SBC lui-même vous donne des indices précieux dans ses logs. Avant même d'ouvrir une trace Wireshark complexe, une recherche rapide dans les syslogs peut vous orienter.

Si vous voyez un grand nombre de messages PL: ou RS: dans les syslogs du SBC pour l'appel en question, cela confirme un problème de transport RTP (souvent un pare-feu ou un problème de routage réseau).

Conclusion

Le diagnostic des problèmes de média est une compétence fondamentale pour tout expert VoIP. Il exige de passer de l'analyse de la signalisation à celle du média, en utilisant les bons outils et une méthodologie structurée.

Points Clés à Retenir :

• Les problèmes de "no audio" ou "one-way audio" sont des problèmes de média (RTP), souvent causés par une négociation SDP incorrecte ou non respectée.
• Votre analyse doit toujours commencer par la vérification des lignes c= (IP) et m= (port) dans le SDP des messages SIP pour les deux segments de l'appel.
• La capture de traces via le Debug Recording de l'AudioCodes est indispensable pour visualiser les flux RTP.
• Dans Wireshark, l'outil Telephony > RTP > RTP Streams est votre meilleur allié pour vérifier la présence et la direction des quatre flux média attendus.
• Les syslogs du SBC (messages PL, RS, RP) peuvent fournir des raccourcis de diagnostic rapides en confirmant les problèmes de réception RTP.

Aperçu de la prochaine leçon :

Nous avons maintenant exploré le dépannage au niveau le plus bas : le paquet. Mais comment surveiller la santé de centaines ou de milliers d'appels sans analyser chaque trace individuellement ? Dans la prochaine leçon, nous prendrons de la hauteur et verrons comment corréler les alarmes et les indicateurs de performance dans OVOC (le système de management AudioCodes) avec un incident en cours pour un dépannage plus proactif et à grande échelle.