Validation d'appels entrants/sortants via Direct Routing E2E

Introduction

Cette leçon est le moment de vérité pour tout déploiement de Direct Routing. Nous allons passer notre premier appel et, plus important encore, apprendre à vérifier que tout fonctionne comme prévu et à diagnostiquer les problèmes si ce n'est pas le cas. Votre expérience en VoIP Cisco et en dépannage de flux d'appels sera un atout considérable ici, car les principes de signalisation SIP et d'analyse de traces sont universels.

L'objectif de cette leçon est de vous rendre capable de valider le fonctionnement d'un appel entrant et sortant de bout en bout.

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

• Effectuer des appels de test entrants et sortants.
• Utiliser les outils du Teams Admin Center pour analyser le flux d'un appel.
• Analyser les traces SIP de base sur le SBC pour suivre le chemin d'un appel.
• Appliquer une méthodologie de dépannage initial en cas d'échec d'un appel.

1. Le Test Pratique : Passer l'Appel

La validation commence par deux tests simples mais fondamentaux :

1. Appel Sortant : Depuis un client Microsoft Teams, composez un numéro externe (PSTN), comme votre numéro de téléphone mobile.
2. Appel Entrant : Depuis ce même téléphone mobile, appelez le numéro de ligne directe (SDA/DDI) attribué à votre utilisateur Teams.

Dans les deux cas, vous devriez non seulement pouvoir établir l'appel, mais aussi vérifier l'audio dans les deux sens (audio bidirectionnel).

La vidéo suivante montre une démonstration claire de ce processus. Le contexte est une intégration avec un Cisco Call Manager (CUCM), mais la partie qui nous intéresse — l'appel entre Teams et le monde extérieur via le SBC — est parfaitement illustrée.

Si l'appel aboutit avec un audio clair dans les deux sens, félicitations ! Votre configuration de base est fonctionnelle. Mais un vrai professionnel ne s'arrête pas là. Il doit savoir pourquoi cela a fonctionné et quoi faire si cela échoue.

2. Les Outils de Validation : Comment Savoir ce qu'il s'est Passé ?

Pour valider un appel de bout en bout, vous devez examiner les journaux des deux côtés de la connexion : Microsoft Teams et votre SBC.

Côté Microsoft : Le Teams Admin Center (TAC)

Le TAC offre des outils puissants pour visualiser la signalisation SIP du point de vue de Microsoft.

Pour analyser un appel spécifique, le meilleur outil est le rapport d'usage PSTN, qui contient un visualiseur de flux d'appels SIP.

Ce diagramme vous montre chaque message SIP échangé entre le Proxy SIP de Microsoft et votre SBC. C'est essentiel pour confirmer que Teams a bien envoyé l'appel (INVITE) à votre SBC et a reçu les bonnes réponses.

Côté SBC : Les Traces de Signalisation

Le SBC est le cœur de votre architecture. Ses journaux sont la source de vérité la plus détaillée. Chaque SBC certifié propose un outil de traçage en temps réel ou de collecte de logs.

La vidéo que vous avez vue précédemment montre également comment analyser le flux d'appel directement sur un SBC AudioCodes.

En comparant le flux SIP vu depuis le TAC et celui vu depuis le SBC, vous pouvez précisément isoler où un problème se produit.

3. Méthodologie de Dépannage de Base

Que faire si l'appel ne fonctionne pas ? Ne paniquez pas. Adoptez une approche structurée. Voici une checklist des premiers points à vérifier, qui résolvent 90% des problèmes initiaux.

Si ces vérifications de base ne révèlent rien, il faut creuser plus profondément dans les journaux. La vidéo suivante est une session de "deep dive" qui montre comment un ingénieur de Microsoft diagnostique un échec d'appel.

Votre méthodologie de dépannage devrait donc être :

1. Symptôme : L'appel échoue (pas de sonnerie, erreur "appel non abouti", etc.).
2. TAC - Analyse de l'appel :
   • Trouvez l'appel dans le rapport d'usage PSTN.
   • Quel est le Final SIP Code et le Call End Reason ? (ex: 404 Not Found, 488 Not Acceptable Here, Media Error). Le code vous donne un indice crucial.
3. SBC - Trace en direct :
   • Refaites l'appel en regardant la trace en direct sur le SBC.
   • Pour un appel sortant : Recevez-vous un INVITE de Teams ? Que répondez-vous ? Envoyez-vous bien l'appel à l'opérateur ? Quelle réponse l'opérateur vous retourne-t-il ?
   • Pour un appel entrant : Recevez-vous un INVITE de l'opérateur ? L'envoyez-vous bien à Teams (sip.pstnhub.microsoft.com) ? Que répond Teams ?
4. Corrélation : Comparez les deux vues. Le problème se situe là où la séquence s'interrompt ou là où un message d'erreur apparaît. Par exemple, si le TAC montre qu'il a envoyé un INVITE mais que votre SBC ne le voit jamais, le problème est probablement sur votre pare-feu.

Conclusion

Vous avez atteint une étape majeure. Vous êtes non seulement capable de faire fonctionner les appels en Direct Routing, mais vous disposez maintenant de la méthodologie et des outils pour valider la configuration et diagnostiquer les problèmes de manière professionnelle.

Points clés à retenir :

• La validation de bout en bout implique de tester les appels entrants et sortants, en vérifiant la signalisation SIP et le flux média RTP.
• Vos deux outils principaux sont le Teams Admin Center (rapports d'usage PSTN et état du SBC) et les traces de votre SBC.
• Une approche de dépannage structurée commence par les vérifications de base (santé du SBC, certificats, FQDN, pare-feu) avant de plonger dans l'analyse détaillée des journaux.
• Le code de réponse SIP est l'indice le plus important pour comprendre pourquoi un appel a échoué.

Prochaine étape :

Maintenant que nous savons valider un appel individuel, nous allons changer de perspective. Dans le prochain module, nous aborderons la supervision et le dépannage proactifs. La première leçon portera sur la supervision de l'état de santé des trunks Direct Routing via le Teams Admin Center, afin de détecter les problèmes avant qu'ils n'affectent vos utilisateurs.