Dépannage de l'interopérabilité SIP : Codecs, DTMF et format de numéro

Bonjour ! Bienvenue dans cette nouvelle leçon du module 7 sur la normalisation et l'interopérabilité avancée.

Dans les modules précédents, nous avons vu comment construire les blocs de base de la configuration d'un SBC AudioCodes, comment créer des règles de routage et comment manipuler les messages SIP. Aujourd'hui, nous allons mettre ces connaissances en perspective en nous concentrant sur le "pourquoi" de ces manipulations : l'interopérabilité.

L'objectif de cette leçon est d'apprendre à identifier les problèmes d'interopérabilité SIP les plus courants. Un SBC est rarement une île ; il connecte des systèmes hétérogènes (opérateurs, Microsoft Teams, centres de contact, PBX internes) qui ne parlent pas toujours exactement le même "dialecte" SIP. Savoir repérer ces différences dans les traces est la première étape cruciale de tout dépannage ou projet d'intégration.

Nous allons nous concentrer sur trois catégories de problèmes :

1. Les conflits de codecs audio.
2. Les incompatibilités de signalisation DTMF.
3. Les divergences de format de numéro.

À la fin de cette leçon, vous saurez où regarder dans une trace SIP pour diagnostiquer ces problèmes, préparant ainsi le terrain pour les leçons suivantes où nous apprendrons à les corriger avec les outils d'AudioCodes.

1. Problèmes d'interopérabilité des Codecs

Un codec (codeur-décodeur) est un algorithme qui compresse et décompresse les données audio pour les transmettre sur un réseau IP. Pour que deux participants à un appel puissent s'entendre, leurs équipements doivent se mettre d'accord sur un codec commun.

Cette négociation se fait via le protocole SDP (Session Description Protocol), qui est transporté dans le corps des messages SIP INVITE et 200 OK.

• L'Offre (Offer) : Le premier message (INVITE) contient une liste de tous les codecs supportés par l'appelant.
• La Réponse (Answer) : Le message 200 OK renvoyé par l'appelé contient le codec choisi parmi ceux proposés dans l'offre, qui est commun aux deux équipements.

Le Problème : Le "Codec Mismatch"

Un "codec mismatch" se produit lorsque les deux équipements ne trouvent aucun codec en commun. Les conséquences sont généralement :

• Échec de l'appel : L'appelé rejette l'appel avec un message d'erreur SIP comme 415 Unsupported Media Type ou 488 Not Acceptable Here.
• Absence de son ("No Audio") : L'appel s'établit (signalisation SIP OK), mais aucun flux audio (RTP) n'est échangé car les points de terminaison ne savent pas comment décoder le son de l'autre.

Comment identifier un problème de codec ?

Pour identifier un problème de codec, vous devez inspecter la partie SDP des messages INVITE et 200 OK dans une trace Wireshark.

Pour vous familiariser avec l'analyse SDP dans Wireshark, je vous invite à visionner une partie de la vidéo suivante.

Dans Wireshark, vous regarderez :

1. Le message INVITE (l'offre) : Cherchez la section "Session Description Protocol". Vous y trouverez une ligne m=audio ... suivie de plusieurs lignes a=rtpmap.... Chaque ligne rtpmap définit un codec.

   Exemple d'offre SDP dans un INVITE :

   m=audio 9386 RTP/AVP 0 8 18 101
   a=rtpmap:0 PCMU/8000  (G.711 mu-law)
   a=rtpmap:8 PCMA/8000   (G.711 A-law)
   a=rtpmap:18 G729/8000   (G.729)
   a=rtpmap:101 telephone-event/8000
   

2. Le message 200 OK (la réponse) : Comparez sa partie SDP avec celle de l'offre. La réponse ne doit contenir qu'un seul des codecs audio proposés dans l'offre.

   Exemple de réponse SDP dans un 200 OK :

   m=audio 7050 RTP/AVP 0 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:101 telephone-event/8000
   

   Ici, l'appelé a choisi le codec PCMU (G.711 mu-law) car il était présent dans l'offre.

Si la liste des codecs dans l'offre du INVITE est complètement différente de celle que l'équipement distant supporte, ce dernier ne pourra pas répondre avec un codec commun, menant à l'échec de l'appel. Dans les logs AudioCodes (Syslog), vous pourriez voir une alerte RP: RTP Payload is incorrect, comme mentionné dans le guide de dépannage AudioCodes.

2. Problèmes d'interopérabilité DTMF

Les tonalités DTMF (Dual-Tone Multi-Frequency) sont les sons que vous entendez lorsque vous appuyez sur les touches de votre téléphone. Elles sont essentielles pour interagir avec des systèmes vocaux interactifs (IVR), des messageries vocales, etc.

En VoIP, il existe plusieurs méthodes pour transporter ces tonalités :

1. In-band : Les tonalités DTMF sont envoyées comme de l'audio normal, dans le flux RTP. Cette méthode est simple mais peu fiable avec les codecs compressés (comme G.729), qui peuvent déformer les tonalités et les rendre méconnaissables.
2. RFC 2833 (ou RFC 4733) : C'est la méthode la plus courante et la plus fiable. Les événements DTMF sont envoyés dans des paquets RTP spéciaux, avec un "payload type" distinct (souvent 101) identifié comme telephone-event. Cela les protège de la compression audio.
3. SIP INFO / NOTIFY : Les chiffres DTMF sont transportés directement dans des messages de signalisation SIP (INFO ou NOTIFY), en dehors du flux média.

La vidéo suivante explique bien ces concepts.

Le Problème : Incompatibilité des méthodes DTMF

Le symptôme le plus courant est : "J'appelle un serveur vocal, j'appuie sur les touches, mais rien ne se passe". Cela se produit lorsque l'appelant envoie des DTMF via une méthode que le récepteur ne comprend pas (par exemple, l'appelant envoie en SIP INFO alors que le récepteur s'attend à du RFC 2833).

Comment identifier un problème de DTMF ?

1. Vérifiez la négociation RFC 2833 dans le SDP :
   Comme pour les codecs, la méthode DTMF (si RFC 2833 est utilisé) est négociée dans le SDP. Recherchez une ligne rtpmap contenant telephone-event.

   a=rtpmap:101 telephone-event/8000
   

   Si cette ligne est présente dans l'offre (INVITE) et dans la réponse (200 OK), alors les deux parties se sont mises d'accord pour utiliser RFC 2833.

2. Analysez les traces pendant l'appel :

   • Si RFC 2833 a été négocié : Appliquez un filtre Wireshark rtp.p_type == <payload_type_number>. Si le payload type négocié était 101, le filtre sera rtp.p_type == 101. Vous devriez voir apparaître des paquets RTP chaque fois qu'une touche est pressée.
   • Si RFC 2833 n'a pas été négocié : Appliquez un filtre Wireshark sip.method == INFO. Si vous voyez des messages INFO apparaître avec le contenu du chiffre pressé, alors la méthode SIP INFO est utilisée.
   • Si aucune des deux méthodes ci-dessus n'est visible : Il est probable que le DTMF soit envoyé en "in-band". C'est le cas le plus difficile à diagnostiquer car les tonalités sont mélangées au flux audio.

Le guide suivant d'AudioCodes fournit des exemples visuels très clairs de ce à quoi ressemblent les DTMF in-band et RFC 2833 dans les logs et les traces.

Ayant travaillé avec des SBC Oracle, vous reconnaîtrez peut-être le principe de médiation. Un SBC est souvent configuré pour "normaliser" le DTMF : il peut recevoir du DTMF en SIP INFO d'un côté et le convertir en RFC 2833 de l'autre côté pour assurer la compatibilité.

3. Problèmes de format de numéro

C'est peut-être le problème d'interopérabilité le plus fréquent. Les différents systèmes connectés au SBC (ITSP, Teams, PBX) ont souvent des exigences strictes sur le format des numéros, tant pour l'appelant (From) que pour l'appelé (To / Request-URI).

Exemples de formats :

• National : 0123456789
• International (E.164) : +33123456789
• Interne/Extension : 2001
• Préfixé : 00123456789 (pour une sortie internationale depuis un PBX)

Le Problème : "Number Mismatch"

Les conséquences d'un mauvais format de numéro sont variées :

• Échec du routage : L'équipement de destination ne reconnaît pas le format et rejette l'appel, souvent avec une erreur 404 Not Found.
• Mauvais affichage du numéro : Le destinataire voit un numéro incorrect ou "Anonyme".
• Appels bloqués : De nombreux opérateurs (ITSP) n'acceptent que des numéros appelants au format E.164 et rejettent tout le reste.
• Problèmes de rappel : Si le numéro appelant est affiché dans un format interne (2001), le destinataire ne pourra pas rappeler ce numéro depuis l'extérieur.

Comment identifier un problème de format de numéro ?

L'analyse se fait en examinant les headers clés dans le message INVITE sortant (envoyé par le SBC vers la destination) :

1. Request-URI : C'est la "destination" de l'appel. Le format de ce numéro doit correspondre à ce que l'équipement de destination attend. Par exemple, pour un appel vers Teams, le numéro doit être au format E.164.
2. Header To : Similaire au Request-URI, il contient le numéro de l'appelé.
3. Header From : Contient le numéro de l'appelant. C'est ce que le destinataire verra comme "Caller ID".
4. Header P-Asserted-Identity (PAI) : De nombreux opérateurs utilisent ce header pour authentifier l'identité de l'appelant. Il doit souvent contenir un numéro public valide au format E.164.

Le guide de dépannage d'AudioCodes aborde ces points, notamment les problèmes liés à l'identification de l'appelant (Caller ID).

Scénario Pratique :
Imaginez un utilisateur avec l'extension interne 4001 qui appelle le numéro mobile 0612345678. Le SBC doit router l'appel vers un opérateur SIP (ITSP).

• INVITE reçu par le SBC (depuis le PBX interne) :

  INVITE sip:0612345678@sbc.company.com SIP/2.0
  From: "User 4001" <sip:4001@pbx.company.com>
  To: <sip:0612345678@sbc.company.com>
  

• Problème : L'ITSP attend un numéro appelant public au format E.164 (+339...) et non une extension interne 4001. Il va probablement rejeter l'appel.
• Ce qu'il faut rechercher : Vous devez capturer la trace SIP entre le SBC et l'ITSP. Vous y verrez l' INVITE ci-dessus être envoyé, suivi d'une réponse d'erreur de l'ITSP (par exemple 403 Forbidden ou 404 Not Found). L'analyse des headers From et PAI dans l' INVITE sortant révélera le formatage incorrect. La solution (que nous verrons plus tard) consistera à utiliser des règles de manipulation pour changer 4001 en +33987654321.

Résumé de la Leçon

Aujourd'hui, nous avons appris à identifier les trois familles de problèmes d'interopérabilité SIP les plus courantes :

• Problèmes de Codecs :

  • Symptôme : Échec d'appel (415, 488), pas de son (no audio).
  • Où regarder : Les listes de codecs (a=rtpmap) dans le SDP des messages INVITE et 200 OK. Il doit y avoir au moins un codec audio en commun.

• Problèmes de DTMF :

  • Symptôme : Les touches pressées n'ont aucun effet sur un serveur vocal (IVR).
  • Où regarder :
    1. La négociation RFC 2833 (telephone-event) dans le SDP.
    2. Si elle est négociée, rechercher les paquets RTP avec le bon payload type.
    3. Sinon, rechercher des messages SIP INFO.
    4. Si rien, le DTMF est probablement "in-band" et incompatible avec un codec compressé.

• Problèmes de Format de Numéro :

  • Symptôme : Échec d'appel (404), mauvais affichage du numéro, appels bloqués par l'opérateur.
  • Où regarder : Les headers Request-URI, From, To et P-Asserted-Identity dans le message INVITE envoyé par le SBC. Le format doit correspondre aux exigences du système de destination.

Maintenant que vous savez comment diagnostiquer ces problèmes en lisant les traces, vous êtes prêt pour l'étape suivante.

Aperçu de la prochaine leçon : Dans la prochaine leçon, "Utiliser les 'IP Profiles' pour forcer la normalisation SIP", nous commencerons à résoudre ces problèmes. Nous verrons comment les IP Profiles sur un SBC AudioCodes peuvent être utilisés pour nettoyer et standardiser les messages SIP, par exemple en forçant la suppression de headers non-standard ou en ajustant certains paramètres pour améliorer la compatibilité.