Bonjour !
Dans la leçon précédente, nous avons appris à utiliser le Call Quality Dashboard (CQD) pour obtenir une vue d'ensemble de la qualité des appels et identifier les tendances de dégradation sur votre infrastructure Direct Routing. Vous savez maintenant comment repérer les sites ou les SBC qui souffrent de problèmes de gigue ou de perte de paquets.
Introduction
Aujourd'hui, nous allons descendre d'un niveau pour passer de l'analyse "macro" de la qualité à l'investigation "micro" de la signalisation. Certains des problèmes les plus complexes ne sont pas liés à une mauvaise qualité audio, mais à l'établissement même de l'appel : une communication qui n'aboutit pas, un transfert qui échoue, une présentation de numéro incorrecte. La clé pour résoudre ces mystères se trouve dans les traces de signalisation.
L'objectif de cette leçon est de vous apprendre à analyser une trace de signalisation SIP pour diagnostiquer un problème de routage ou de négociation d'appel.
Votre expérience avec Cisco VoIP et les protocoles de téléphonie vous donne une excellente base. Vous connaissez déjà le rôle fondamental du protocole SIP (Session Initiation Protocol) dans l'établissement des appels. Nous allons maintenant appliquer et approfondir cette connaissance dans le contexte spécifique de l'interconnexion entre Microsoft Teams et un SBC.
À la fin de cette leçon, vous serez capable de :
- Utiliser les outils intégrés au Teams Admin Center pour visualiser un flux d'appel SIP.
- Lire et interpréter les messages et codes d'erreur SIP les plus courants dans une trace.
- Utiliser des outils comme les logs d'un SBC ou Wireshark pour isoler un appel et analyser les en-têtes SIP critiques.
- Inspecter le protocole SDP pour diagnostiquer les problèmes de négociation média.
1. Visualiser le Flux d'Appel : Le Diagramme SIP dans le Teams Admin Center
Le premier outil, et le plus accessible pour l'analyse SIP, se trouve directement dans le Teams Admin Center (TAC). Il présente le flux d'appel sous la forme d'un "diagramme en échelle" (ladder diagram), qui montre la séquence chronologique des messages échangés entre le SIP Proxy de Microsoft et votre SBC.
Pour y accéder et l'interpréter, la documentation Microsoft est un bon point de départ.
SIP call flow for Direct Routing in Microsoft Teams
Ce document officiel explique comment trouver et interpréter la fonctionnalité de flux d'appel SIP dans le TAC. C'est votre première étape de diagnostic.
Lisez les sections suivantes : "Access SIP call flow" : Suivez les étapes pour accéder au diagramme depuis le rapport d'utilisation PSTN. "Understanding the SIP call flow view" : Concentrez-vous sur la manière dont le diagramme est structuré. Chaque "barreau" de l'échelle est un message SIP, la flèche indique la direction, et vous pouvez cliquer sur chaque message pour voir les détails des en-têtes.
Cet outil est parfait pour avoir une vue rapide d'un échec d'appel. Par exemple, si vous voyez un INVITE de Teams vers votre SBC, mais aucune réponse de celui-ci, le problème est probablement lié à la connectivité réseau ou à un souci sur le SBC lui-même. Si le SBC répond avec un code d'erreur comme 503 Service Unavailable, le problème est clairement identifié côté SBC.
2. Analyse Approfondie : Les Logs du SBC
Le diagramme du TAC est utile, mais il ne montre que la perspective de Microsoft. Pour une analyse de bout en bout, il est indispensable de consulter les logs de votre SBC. Étant donné votre expérience avec Cisco, nous allons nous baser sur un exemple concret avec un Cisco CUBE, ce qui devrait vous être familier.
La commande debug ccsip messages sur un CUBE génère une trace texte de tous les messages SIP entrants et sortants. C'est dans cette trace que se cachent souvent les détails cruciaux.
Troubleshoot Microsoft Teams Direct Routing with Cisco CUBE
Cet article de blog présente un cas de dépannage réel et très courant : un appel qui échoue après un transfert vers une messagerie vocale partagée dans Teams. Il illustre parfaitement la méthodologie d'analyse d'une trace SIP.
Lisez l'article en suivant le raisonnement de l'auteur : Analyse : Repérez le message d'erreur SIP/2.0 403 Forbidden renvoyé par Microsoft. Lisez attentivement la ligne REASON, qui contient l'explication : Provided Trunk FQDN ‘10.10.253.36’ is not allowed. Microsoft refuse la communication car l'identité présentée par le CUBE (une adresse IP privée) n'est pas celle attendue (le FQDN public du SBC). Inspection : Examinez le message INVITE que le CUBE a envoyé juste avant. Cherchez l'en-tête Contact. Vous verrez qu'il contient l'adresse IP privée sip:10.10.253.36:5061. Solution : L'article conclut qu'il faut corriger le profil SIP sur le CUBE pour qu'il insère son FQDN public dans l'en-tête Contact lors des re-INVITE. C'est une erreur de configuration classique.
Ce cas pratique met en lumière deux points essentiels :
- Les codes d'erreur SIP (4xx, 5xx) vous pointent dans la bonne direction.
- L'en-tête
Contactest critique. Il indique à l'autre partie où envoyer les futures requêtes pour cet appel (comme unBYEou un re-INVITE). Une mauvaise configuration de cet en-tête est une source fréquente de problèmes.
3. L'Outil Ultime : Wireshark
Lorsque les logs du SBC ne suffisent pas, ou si vous suspectez un problème réseau (ex: paquets SIP perdus), Wireshark est l'outil de référence. Il capture tout le trafic sur une interface réseau et vous permet de le disséquer.
L'analyse de captures Wireshark peut être intimidante en raison du volume de données. Apprendre à filtrer efficacement est la compétence la plus importante.
How To Analyze SIP Calls in Wireshark
Cette vidéo est un excellent tutoriel pour démarrer avec l'analyse SIP dans Wireshark. Elle couvre les techniques de base pour isoler et visualiser un appel.
Regardez la vidéo en vous concentrant sur les techniques suivantes : Filtres de base (00:18) : Appliquez simplement sip ou rtp pour n'afficher que ces protocoles. Visualisation du flux (01:46) : Utilisez le menu Telephony > VoIP Calls pour obtenir un diagramme en échelle similaire à celui du TAC, mais construit à partir de votre capture locale. Isoler un appel (02:15) : C'est la technique la plus importante. Trouvez le Call-ID d'un appel qui vous intéresse, faites un clic droit et appliquez-le comme filtre (Apply as Filter > Selected). Cela masquera tous les autres appels et ne vous laissera que la conversation pertinente. Gérer les erreurs de parsing (03:46) : Parfois, Wireshark ne reconnaît pas le trafic SIP s'il utilise un port non standard. La fonction Decode As... permet de forcer l'interprétation du trafic en tant que SIP.
4. Le Média : Comprendre le SDP (Session Description Protocol)
SIP établit la session, mais c'est le SDP qui négocie les détails du flux média (audio, vidéo). Le SDP est transporté à l'intérieur des messages SIP (généralement dans les INVITE et 200 OK). Des problèmes dans le SDP mènent à des symptômes comme l'audio unidirectionnel ou l'absence totale d'audio.
Les éléments clés à vérifier dans le SDP sont :
- La ligne
c=(connection data) : Elle spécifie l'adresse IP qui doit recevoir le flux média (RTP). Si cette IP est incorrecte (par exemple, une IP privée alors que le client est externe), vous aurez de l'audio unidirectionnel. - La ligne
m=(media description) : Elle définit le port et les codecs proposés pour l'appel. Si les deux parties ne trouvent aucun codec en commun, l'appel échouera.
Parfois, il est difficile d'obtenir une capture réseau côté client. Il existe une astuce pour extraire le SDP directement depuis le client Teams dans un navigateur.
Troubleshooting Microsoft Teams Voice [Deep Dive]
Cette vidéo de dépannage avancé montre une technique très pratique pour visualiser le SDP côté client sans avoir besoin de Wireshark. Elle montre également un cas concret où une erreur média est diagnostiquée.
Regardez ces deux segments : Diagnostiquer une erreur média (25:29 - 28:50) : L'expert analyse un échec d'appel avec un code d'erreur 410 (Media Error). En examinant les logs, il découvre que l'adresse IP publique annoncée dans le SDP par le SBC est incorrecte à cause d'une règle NAT mal configurée sur le pare-feu. Cela lie directement un code d'erreur SIP à un problème de configuration média. Extraire le SDP du navigateur (30:49 - 32:23) : Suivez la démonstration pour capturer le SDP. La méthode consiste à ouvrir Teams dans un navigateur, lancer les outils de développement (F12), filtrer le trafic réseau sur cs.proxy, passer un appel sortant, et copier le contenu du "blob" média pour l'analyser. C'est une technique puissante pour voir exactement quels candidats média votre client propose.
Conclusion
Vous maîtrisez désormais la dernière étape du dépannage de Direct Routing : l'analyse de la signalisation. Vous savez que lorsque les rapports du TAC ou du CQD indiquent un problème mais ne donnent pas la cause racine, la trace SIP est la source de vérité.
Points clés à retenir :
- Commencez simple : Le diagramme en échelle du Teams Admin Center est votre premier point d'entrée pour visualiser un flux d'appel.
- Creusez plus profond : Les logs du SBC (
debug ccsip messagessur un CUBE) ou une capture Wireshark sont essentiels pour une analyse détaillée. - Filtrez par
Call-ID: C'est la compétence fondamentale pour isoler une seule conversation dans un flot de trafic. - Cherchez les indices : Les codes d'erreur (4xx/5xx) et le contenu de l'en-tête
Reasonvous disent ce qui a mal tourné. L'en-têteContactvous dit où la communication s'est rompue. - N'oubliez pas le média : Les problèmes d'audio (unidirectionnel ou absent) sont souvent cachés dans le SDP, vérifiez les adresses IP (
c=) et les codecs (m=).
Prochaine étape :
Avec cette leçon, nous achevons notre module sur la supervision et le dépannage du Direct Routing. Vous avez maintenant une vision complète, de l'analyse des tendances de qualité avec le CQD jusqu'à l'inspection au niveau du paquet avec Wireshark.
Nous allons maintenant aborder le deuxième grand pilier de votre objectif de formation : les Microsoft Teams Rooms (MTR). Dans la prochaine leçon, nous commencerons par les bases en découvrant le concept MTR, les licences nécessaires, les différences entre les plateformes Windows et Android, et nous ferons un premier tour d'horizon des équipements Lenovo ThinkSmart que vous avez à votre disposition.