Diagnostic des échecs de routage direct via les rapports d'erreurs d'appel

Introduction

Une fois le trunk SIP établi, le travail n'est pas terminé. Des appels peuvent encore échouer pour de multiples raisons. L'objectif de cette leçon est de vous outiller pour analyser les rapports d'erreurs d'appel afin de diagnostiquer les échecs via Direct Routing. Nous allons passer de la surveillance du trunk au diagnostic d'un incident précis : "Pourquoi cet appel n'a-t-il pas abouti ?".

Votre expérience en support IT et avec la VoIP Cisco vous a déjà familiarisé avec l'analyse de logs et de codes d'erreur SIP. Nous allons appliquer cette même logique d'investigation aux outils que Microsoft Teams met à notre disposition.

À la fin de cette leçon, vous saurez :

• Utiliser le rapport d'utilisation PSTN pour identifier les appels ayant échoué.
• Interpréter les codes d'erreur SIP et les sous-codes Microsoft pour comprendre la cause d'un échec.
• Naviguer dans l'historique d'appel d'un utilisateur pour une analyse technique détaillée.
• Corréler les informations du Teams Admin Center avec les logs du SBC pour un diagnostic complet.

1. Le Point de Départ : Le Rapport d'Utilisation PSTN

Votre premier outil d'investigation est le rapport d'utilisation PSTN. C'est ici que vous trouverez le journal de tous les appels entrants et sortants qui transitent par votre Direct Routing, y compris les appels qui ont échoué.

Une fois dans le rapport, l'onglet Direct Routing est votre centre de commandement. Il liste chaque tentative d'appel avec des informations cruciales pour le diagnostic.

2. Interpréter les Données du Rapport

Un appel qui échoue est généralement marqué avec un Event type de type "Attempt" (tentative). Les colonnes les plus importantes pour comprendre la cause de l'échec sont :

• Final SIP code : Le code de réponse SIP final (ex: 404 Not Found, 503 Service Unavailable). C'est le langage standard de la téléphonie IP que vous connaissez bien.
• Final Microsoft subcode : Un code spécifique à Microsoft qui donne plus de contexte à l'erreur SIP.
• Final SIP phrase : Une description textuelle de l'erreur, combinant les deux codes précédents (ex: "Call failed to connect to the SBC.").
• SBC FQDN : Permet de savoir quel SBC était impliqué, essentiel dans un environnement multi-SBC.
• Correlation ID : Un identifiant unique pour l'appel. C'est la clé pour faire le lien entre les logs Teams et les logs de votre SBC.

Pour une analyse plus poussée, il est souvent plus simple d'exporter le rapport. Comme vous appréciez PowerShell, voici une astuce pratique pour formater correctement le fichier CSV exporté.

3. Analyse Détaillée : L'Historique d'Appel de l'Utilisateur

Le rapport PSTN est excellent pour identifier un problème, mais pour une analyse en profondeur, vous devez plonger dans l'historique d'appel de l'utilisateur concerné. Heureusement, le rapport PSTN offre un lien direct : il suffit de cliquer sur le nom de l'utilisateur.

Ce niveau de détail vous permet de distinguer un problème de réseau local chez l'utilisateur, un souci de périphérique, ou un problème de signalisation plus complexe entre Teams et votre SBC.

4. La Méthodologie Complète : Corrélation des Données

Les outils de Teams vous donnent la perspective de Microsoft. Pour avoir une vue à 360°, vous devez la croiser avec la perspective de votre SBC et du client Teams. C'est là que votre expertise technique prend toute sa valeur.

Cette vidéo propose un "deep dive" exceptionnel sur le dépannage d'un problème d'appel, en suivant une méthodologie d'expert.

Synthèse : Votre Workflow de Diagnostic d'Appel

En combinant ces outils et techniques, vous pouvez adopter une approche structurée pour chaque incident d'appel :

1. Identifier l'Échec (Vue Macro) :

   • Allez dans le Rapport d'utilisation PSTN (Direct Routing).
   • Filtrez par date et heure, et repérez les appels avec Event type: Attempt.
   • Notez le Final SIP Code, Final SIP Phrase et le Correlation ID.

2. Analyser l'Appel (Vue Micro) :

   • Cliquez sur le nom de l'utilisateur pour accéder à son historique d'appels.
   • Ouvrez l'appel en question et analysez les onglets Advanced et Debug.
   • Cherchez des anomalies dans les métriques réseau, les codecs, et les messages d'erreur détaillés.

3. Corréler les Sources (Vue 360°) :

   • Côté SBC : Utilisez le Correlation ID (et l'heure de l'appel) pour trouver la trace correspondante dans les logs de votre SBC. L'erreur SIP 410 dans la vidéo, par exemple, a été confirmée par les logs du SBC.
   • Côté Client : Si le problème semble lié au média (surtout en Media Bypass), utilisez le raccourci Ctrl+Alt+Shift+1 dans le client Teams pour collecter les logs. Cherchez le call controller code ou d'autres mots-clés pertinents.

4. Conclure et Résoudre :

   • En croisant les informations, déterminez la source du problème. Est-ce une mauvaise configuration du SBC ? Une règle de pare-feu ? Un problème sur le client ? La cause est rarement dans un seul système.

Conclusion

Vous êtes maintenant capable de mener une enquête complète sur un échec d'appel en Direct Routing. Vous savez passer d'un simple rapport d'erreur à une analyse technique détaillée, en exploitant les différents outils à votre disposition et en les corrélant avec vos propres systèmes.

Points clés à retenir :

• Le Rapport d'Utilisation PSTN est le point de départ pour identifier les appels ayant échoué et obtenir les premiers indices (codes SIP).
• L'analyse des appels d'un utilisateur fournit des détails techniques granulaires sur le réseau, les périphériques et les messages de débogage.
• La clé d'un diagnostic réussi réside dans la corrélation des données entre le Teams Admin Center, les logs de votre SBC et les logs du client Teams.
• Le Correlation ID est l'élément fondamental qui permet de lier toutes ces sources de données entre elles.

Prochaine étape :

Nous avons vu comment diagnostiquer les appels qui échouent complètement. Mais que faire des appels qui aboutissent mais dont la qualité est médiocre (écho, coupures, voix robotique) ? Dans la prochaine leçon, nous aborderons cet aspect en apprenant à utiliser le Call Quality Dashboard (CQD) pour isoler les problèmes de qualité audio spécifiques au Direct Routing.