Analyse de traces d'appels complexes (CUCM-SME-SBC-PSTN)

1. L'anatomie d'un appel SIP

Pour analyser un flux d'appel, il faut d'abord comprendre le langage qu'il utilise : le Session Initiation Protocol (SIP). SIP est le protocole de signalisation qui établit, modifie et termine les appels. La voix elle-même transite via un autre protocole, le Real-time Transport Protocol (RTP).

Pour cette section, je vous invite à consulter un document de référence qui détaille les fondamentaux de SIP.

Pour résumer les points essentiels de cette lecture :

• Dialogue SIP : Un appel est un dialogue entre deux ou plusieurs équipements. Il commence généralement par un message INVITE.
• En-têtes (Headers) : Chaque message SIP contient des informations vitales.
  • Call-ID: Un identifiant unique pour l'ensemble de l'appel à travers tous les équipements. C'est le fil conducteur principal pour suivre un appel.
  • From / To: L'appelant et l'appelé.
  • Via: Chaque équipement qui traite le message ajoute une ligne Via. En lisant les en-têtes Via de bas en haut, on peut retracer le chemin exact de la signalisation.
  • CSeq: Un numéro de séquence pour appairer les requêtes et les réponses.
• Codes de Réponse : Ils indiquent le résultat d'une requête.
  • 1xx (Information) : La requête est en cours de traitement (ex: 180 Ringing).
  • 2xx (Succès) : La requête a été acceptée (ex: 200 OK).
  • 4xx (Erreur Client) : La requête est mal formée ou ne peut être traitée par le serveur (ex: 404 Not Found - le numéro n'existe pas). C'est un indicateur clé de problème de routage ou de configuration.
  • 5xx (Erreur Serveur) : Le serveur a rencontré une erreur interne en essayant de traiter une requête valide (ex: 503 Service Unavailable).
• SDP (Session Description Protocol) : C'est la "charge utile" des messages INVITE et 200 OK. Il décrit le média :
  • c= : L'adresse IP où envoyer le flux RTP (la voix).
  • m= : Le port et le protocole pour le média, ainsi que la liste des codecs proposés (payload types).
  • a= : Des attributs additionnels, comme les détails des codecs (rtpmap).

2. Les Outils du Dépannage : Capturer et Visualiser les Traces

Maintenant que nous connaissons la théorie, voyons comment capturer et lire ces messages en pratique.

Outil universel : Wireshark

Wireshark est l'outil standard pour l'analyse de paquets réseau. Il est capable de décoder les protocoles SIP et RTP pour les présenter de manière lisible.

Les deux fonctionnalités à retenir de cette vidéo sont :

1. Le filtrage : Pour isoler le trafic qui vous intéresse dans une capture potentiellement énorme. Le filtre sip.call_id == "votre-call-id" est le plus puissant pour suivre un appel unique.
2. Le diagramme de flux (Flow Sequence) : C'est la meilleure façon de visualiser les échanges entre les différents équipements (CUCM, SME, SBC, etc.) sous forme d'un diagramme en échelle.

Outils spécifiques à votre infrastructure

Votre expérience avec l'écosystème Cisco et AudioCodes est précieuse ici. Chaque constructeur a ses propres outils pour générer des traces.

• AudioCodes SBC : La méthode standard est de configurer le SBC pour qu'il envoie des messages syslog à un serveur. L'outil AudioCodes Syslog Viewer est conçu pour recevoir et interpréter ces logs. Il possède une fonction de diagramme de flux très similaire à celle de Wireshark.

• Cisco CUCM : Les traces SIP sont incluses dans les traces SDL (Signal Distribution Layer). Elles peuvent être collectées via l'interface de Serviceability ou RTMT et analysées avec des outils comme TranslatorX (mentionné dans le PDF LINK à la diapositive 78).

3. Analyse d'un Flux Complexe et Scénarios de Défaillance

Appliquons maintenant ces connaissances pour suivre un appel à travers votre infrastructure et identifier les points de décision et de panne.

Un flux d'appel CUCM > SME > SBC > PSTN implique plusieurs "sauts" où des décisions sont prises.

Point de décision 1 : CUCM
Quand un utilisateur interne compose un numéro externe, le CUCM doit décider où envoyer l'appel. Il utilise sa logique de routage interne pour cela.

Point de décision 2 : SME (Session Management Edition)
Le SME reçoit l'appel du CUCM. Son rôle est d'agréger et de router les sessions SIP entre différents systèmes (par exemple, entre plusieurs clusters CUCM ou vers la sortie de l'entreprise). Il analyse l'INVITE reçu et, sur la base de sa configuration, le transfère au prochain maillon, ici le SBC AudioCodes.

Point de décision 3 : SBC AudioCodes
Le SBC reçoit l'appel du SME. Il agit comme une "tour de contrôle" pour le trafic entrant et sortant du réseau de l'entreprise. Il doit décider vers quel opérateur PSTN (ou quel trunk spécifique) envoyer l'appel.

Étude de cas : analyse de pannes

La meilleure façon d'apprendre est d'analyser des appels qui ont échoué. La vidéo suivante, bien qu'utilisant un CUBE Cisco en guise de SBC, illustre parfaitement la méthodologie de dépannage applicable à votre SBC AudioCodes.

Ce qu'il faut retenir de cette étude de cas :

1. Le coupable n'est pas toujours celui qui crie : Dans les deux scénarios, c'est le CUCM qui envoie l'erreur 404 Not Found. Cependant, la cause première du premier échec était sur le SBC (CUBE), et celle du second était bien sur le CUCM. Seule une analyse complète du flux de signalisation et de la configuration des équipements permet de trouver la véritable origine de la panne.
2. Identifier le point de rupture : En suivant le message INVITE de bout en bout et en examinant le premier message d'erreur (4xx, 5xx), vous pouvez localiser précisément où la chaîne a été rompue. À partir de là, vous savez sur quel équipement concentrer vos recherches de configuration.
3. Les scénarios de défaillance typiques :
   • Problème de traduction/manipulation de numéro : Le SBC ou le CUCM modifie le numéro de l'appelant ou de l'appelé d'une manière qui le rend non routable par l'équipement suivant.
   • Problème de routage/autorisation : Le numéro est correct, mais l'équipement (CUCM via un CSS, ou SBC via ses tables de routage) n'a pas la permission ou la route pour l'acheminer vers la destination.
   • Incompatibilité de codecs : Les deux parties ne parviennent pas à s'accorder sur un codec commun dans le SDP. La réponse est souvent un 488 Not Acceptable Here.
   • Problème réseau/sécurité : Le message INVITE n'arrive jamais à destination (pare-feu), ou une liaison TLS échoue. On observe alors un timeout de la transaction SIP.

Conclusion

Félicitations pour avoir terminé cette première leçon intensive ! C'est le socle sur lequel nous allons construire toute la méthodologie de votre projet.

Points clés à retenir :

• Un appel est un dialogue SIP (signalisation) qui établit un flux RTP (média).
• Chaque équipement sur le chemin d'un appel (CUCM, SME, SBC) est un point de décision qui applique sa propre logique de routage et de manipulation.
• Des outils comme Wireshark et AudioCodes Syslog Viewer permettent de visualiser ces dialogues sous forme de diagrammes de flux, rendant l'analyse plus intuitive.
• Les codes de réponse SIP (en particulier les 4xx) et l'inspection des en-têtes SIP et du corps SDP sont les clés pour identifier la nature et la localisation d'une panne.
• Analyser une trace est un travail de détective : il faut suivre les indices (Call-ID, Via headers) et corréler ce que l'on voit dans la trace avec la configuration des équipements.

Prochaine étape :
Maintenant que vous savez disséquer un appel, nous allons prendre de la hauteur. Dans la prochaine leçon, nous apprendrons à schématiser l'interaction globale entre CUCM, SME et les SBCs, en détaillant tous les chemins possibles de signalisation et de média. Cela nous permettra de construire la carte complète de l'existant avant de planifier les changements.