Diagnostic des problèmes d'interopérabilité SIP (415, 401)

Bonjour !

Dans la leçon précédente, nous avons appris à décortiquer les traces internes du SBC pour diagnostiquer les échecs de routage, tels que les erreurs 404 Not Found et 503 Service Unavailable. Vous savez désormais comment identifier un problème de logique de routage ou de disponibilité de la destination.

Aujourd'hui, nous allons nous intéresser à un scénario différent mais tout aussi courant : le routage est correct, la destination est en ligne, mais l'appel échoue quand même. Pourquoi ? Parce que les deux équipements ne parviennent pas à se "mettre d'accord" sur les modalités de la communication. C'est ce qu'on appelle un problème d'interopérabilité.

L'objectif de cette leçon est de vous apprendre à diagnostiquer les problèmes d'interopérabilité en analysant les messages SIP. Nous nous concentrerons sur deux cas d'école que vous rencontrerez très souvent : le désaccord sur les codecs (415 Unsupported Media Type) et l'échec d'authentification (401 Unauthorized).

1. Le Cas du "415 Unsupported Media Type" : Un Désaccord sur le Langage

Imaginez que vous essayez de passer un appel, la connexion s'établit, mais votre interlocuteur répond avec un message 415 Unsupported Media Type. C'est l'équivalent SIP de téléphoner à quelqu'un qui ne parle aucune des langues que vous connaissez. La communication est impossible.

Ce code d'erreur signifie que le corps du message INVITE (la partie SDP) contient une description de média que le destinataire ne peut pas gérer. Dans 99% des cas, il s'agit d'un problème de négociation de codec audio.

Le Processus de Négociation des Codecs (Rappel)

1. L'Offre : L'équipement qui initie l'appel (UAC - User Agent Client) envoie un message INVITE. Dans le corps de ce message, la section SDP (Session Description Protocol) liste tous les codecs qu'il est capable d'utiliser, généralement par ordre de préférence.

   v=0
   o=- 3781126759 3781126759 IN IP4 10.1.1.1
   ...
   m=audio 5000 RTP/AVP 8 0 18 101
   a=rtpmap:8 PCMA/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:18 G729/8000
   a=rtpmap:101 telephone-event/8000
   

   Ici, l'appelant propose les codecs PCMA (G.711a), PCMU (G.711u) et G.729.

2. La Réponse : L'équipement qui reçoit l'appel (UAS - User Agent Server) examine cette liste et la compare à sa propre liste de codecs autorisés.

   • S'il y a au moins un codec en commun, il choisit le premier de la liste de l'appelant qu'il supporte également, l'indique dans sa réponse 200 OK, et l'appel se poursuit.
   • S'il n'y a aucun codec en commun, il ne peut pas établir le flux audio. Il rejette alors l'appel en envoyant une réponse 415 Unsupported Media Type.

Diagnostiquer un Problème de Codec sur AudioCodes

Le guide de dépannage d'AudioCodes est très clair sur la marche à suivre lorsqu'on reçoit cette erreur.

La méthode de diagnostic est la suivante :

1. Capturez la trace : Utilisez Wireshark ou le Syslog du SBC pour capturer l'échange SIP.
2. Analysez l'INVITE : Isolez le message INVITE qui a initié l'appel. Regardez la section SDP (le corps du message) et notez la liste des codecs proposés dans la ligne m=audio ....
3. Analysez la réponse 415 : Confirmez que le SBC (ou l'équipement distant) répond bien avec un 415.
4. Vérifiez la configuration du SBC :
   • Connectez-vous à l'interface web d'AudioCodes.
   • Allez dans Setup > Signaling & Media > Coders & Profiles > Coder Groups.
   • Examinez le Coder Group qui est utilisé pour cet appel (il est généralement associé au Media Realm, lui-même lié à l'IP Group de la source ou de la destination).
   • Comparez la liste des codecs dans le Coder Group du SBC avec la liste des codecs dans le SDP de l'INVITE. Vous constaterez qu'il n'y a aucune correspondance.

Solution :

• Ajouter un codec commun : La solution la plus simple est de modifier le Coder Group sur le SBC pour y inclure l'un des codecs proposés par l'équipement distant.
• Activer le transcodage : Si les deux équipements n'ont vraiment aucun codec en commun et que vous ne pouvez pas modifier leur configuration, le SBC peut jouer le rôle de traducteur. C'est le transcodage. Le SBC décode le flux audio d'un côté (ex: G.729) et le ré-encode de l'autre (ex: G.711u). Cette fonction plus avancée, que nous verrons en détail plus tard, nécessite que l'appel transite entre deux Media Realms distincts et consomme des ressources DSP.

2. Les Échecs d'Authentification : "Montrez-moi vos Papiers !"

Les erreurs 401 Unauthorized et 407 Proxy Authentication Required sont des problèmes d'interopérabilité liés à l'identité. Le serveur ou le proxy auquel le SBC essaie de parler exige une preuve d'identité avant de traiter la requête. Bien que similaires, leur contexte est différent :

• 401 Unauthorized: Utilisé par un serveur de destination finale (ex: un registrar, un PBX). La requête doit être renvoyée avec un header Authorization.
• 407 Proxy Authentication Required: Utilisé par un proxy intermédiaire. La requête doit être renvoyée avec un header Proxy-Authorization.

Le Flux de l'Authentification "Digest"

Le mécanisme le plus courant est l'authentification "Digest". Il fonctionne comme un défi-réponse pour ne pas envoyer le mot de passe en clair sur le réseau.

En résumé, le dialogue est le suivant :

1. Requête initiale : Le SBC envoie un INVITE ou un REGISTER sans informations d'authentification.
2. Défi (Challenge) : Le serveur répond avec un 401 ou 407. Ce message contient un header (WWW-Authenticate ou Proxy-Authenticate) qui fournit un "challenge", incluant un realm (domaine d'authentification) et un nonce (un nombre unique).
3. Réponse au défi : Le SBC reçoit le 401/407. Il utilise alors les informations du challenge, ainsi que le nom d'utilisateur et le mot de passe qui sont configurés, pour calculer une "réponse" chiffrée (hash).
4. Nouvelle requête : Le SBC renvoie immédiatement la même requête (INVITE ou REGISTER), mais en ajoutant cette fois le header Authorization (ou Proxy-Authorization) contenant le nom d'utilisateur, le realm, le nonce et la réponse calculée.
5. Validation : Le serveur effectue le même calcul de son côté. Si les résultats correspondent, il accepte la requête et répond avec 200 OK. Sinon, l'appel échoue (souvent avec un 403 Forbidden).

Diagnostiquer un Problème d'Authentification

Les traces sont votre meilleur allié.

La méthode de diagnostic est la suivante :

1. Analysez les traces : Dans Wireshark ou le Syslog, observez la séquence. Voyez-vous bien le 401/407 suivi d'une nouvelle tentative ?

2. Identifiez la cause de l'échec :

   • Le plus courant : Identifiants incorrects. Si après la deuxième tentative, vous recevez un 403 Forbidden ou un autre 401, il est quasi certain que le nom d'utilisateur ou le mot de passe est erroné.
   • Pas de deuxième tentative : Si le SBC ne renvoie pas une deuxième requête avec le header Authorization, cela signifie qu'il n'est pas configuré pour s'authentifier auprès de cette destination.
   • Realm incorrect : Parfois, le realm fourni par le serveur dans le challenge doit correspondre à une valeur spécifique attendue.

3. Vérifiez la configuration du SBC :

   • Comme indiqué dans le CPE Troubleshooting Guide (resource LINK), la solution est presque toujours dans la page d'authentification.
   • Allez dans Setup > Signaling & Media > SIP Definitions > Authentication.
   • Vérifiez la ligne qui correspond à votre trunk SIP ou à votre utilisateur. Assurez-vous que le nom d'utilisateur (User Name) et le mot de passe (Password) sont exactement ceux fournis par l'opérateur ou l'administrateur du système distant. Une simple faute de frappe suffit à tout faire échouer.

3. Utiliser les Outils Efficacement

Pour diagnostiquer ces problèmes, il est essentiel de maîtriser vos outils.

Filtrer par Call-ID est une compétence cruciale. Dans un environnement de production avec des centaines d'appels simultanés, c'est le seul moyen d'isoler le dialogue SIP qui vous intéresse et d'analyser la séquence de messages sans être noyé sous le bruit.

Conclusion

Vous savez maintenant comment approcher les problèmes où le routage est correct mais où la communication échoue à un niveau protocolaire. Contrairement aux erreurs de routage, les problèmes d'interopérabilité se résolvent en analysant le "dialogue" entre les équipements.

Points Clés à Retenir :

• Les problèmes d'interopérabilité sont des échecs d'accord, pas des échecs de chemin.
• Un 415 Unsupported Media Type est presque toujours un désaccord sur les codecs. La solution se trouve en comparant le SDP de l'INVITE avec la configuration du Coder Group du SBC.
• Un 401 Unauthorized ou 407 Proxy Authentication Required signale un échec d'authentification. La solution est généralement dans la table Authentication du SBC (identifiants incorrects).
• La méthode de diagnostic est : Symptôme (code erreur) -> Analyse du dialogue SIP (Wireshark/Syslog) -> Corrélation avec la configuration SBC (GUI).

Aperçu de la prochaine leçon :

Nous avons vu comment résoudre les problèmes qui empêchent un appel de s'établir. Mais que se passe-t-il si l'appel s'établit (on reçoit un 200 OK), mais qu'il n'y a pas de son, ou du son dans un seul sens (one-way audio) ? Dans la prochaine leçon, nous plongerons dans le diagnostic des problèmes de média, en retournant analyser le SDP et en introduisant la vérification des flux RTP.