Bonjour !
Dans la leçon précédente, nous avons appris à superviser la santé de vos trunks Direct Routing en utilisant le Health Dashboard du Teams Admin Center. Vous savez maintenant interpréter des indicateurs clés comme l'état de la connectivité TLS et des options SIP. C'est la première étape : savoir que quelque chose ne va pas.
Introduction
Aujourd'hui, nous passons à l'étape suivante : le diagnostic. L'objectif de cette leçon est de vous rendre capable de diagnostiquer les problèmes d'enregistrement du SBC et de connectivité du trunk SIP à l'aide des options de supervision. Nous allons décortiquer les raisons pour lesquelles un SBC peut être marqué comme "Inactif" ou présenter un avertissement, et comment identifier la cause racine.
Votre expérience avec la VoIP Cisco vous a déjà confronté à des problèmes d'enregistrement de passerelle et de connectivité de trunk. Les principes que nous allons aborder sont similaires : une communication qui repose sur des certificats, des règles de pare-feu et une configuration SIP précise. Nous allons simplement les appliquer à l'écosystème Teams.
À la fin de cette leçon, vous saurez :
- Décrire le processus de communication qui mène un SBC à être "Actif".
- Identifier les causes courantes des échecs de connexion TLS (certificats, FQDN).
- Diagnostiquer les problèmes de réseau qui bloquent les options SIP (pare-feu, NAT).
- Reconnaître les erreurs de configuration SIP qui empêchent l'enregistrement.
1. Le "Handshake" : Comment un SBC Devient-il "Actif" ?
Avant de diagnostiquer une panne, il est essentiel de comprendre le fonctionnement normal. Pour qu'un SBC soit marqué comme "Actif" dans le Teams Admin Center, une séquence précise d'échanges doit avoir lieu. C'est ce qu'on appelle la négociation des options SIP, qui agit comme le "battement de cœur" de la connexion.
SBC connectivity issues - Microsoft Teams
Ce document de Microsoft décompose parfaitement ce processus. Comprendre cette séquence est la clé pour savoir où chercher lorsqu'elle échoue.
Lisez attentivement la section "Overview of the SIP options process". Visualisez cette séquence comme une check-list : L'SBC initie une connexion TLS vers le proxy SIP de Teams. Le proxy valide le certificat de l'SBC. Si valide, l'SBC envoie un message SIP OPTIONS. Le proxy valide le FQDN dans le message et répond par 200 OK. Le proxy envoie à son tour ses propres SIP OPTIONS à l'SBC. L'SBC répond par 200 OK. Le statut passe à Active.
Si l'une de ces étapes échoue, le SBC n'atteindra jamais l'état "Actif". Nos diagnostics consisteront à déterminer quelle étape a échoué et pourquoi.
2. Catégorie de Problème n°1 : La Connexion TLS
La toute première étape est l'établissement de la connexion TLS. C'est la fondation sécurisée sur laquelle tout le reste est construit. Si cette étape échoue, aucun message SIP ne sera jamais échangé. Les causes sont presque toujours liées aux certificats.
SBC connectivity issues - Microsoft Teams
Cet article liste les problèmes de connexion TLS les plus courants. C'est la première chose à vérifier en cas de panne totale.
Lisez la section "TLS connection issues". Portez une attention particulière aux points suivants : Certificat auto-signé ou non approuvé : Le certificat de votre SBC doit provenir d'une autorité de certification publique approuvée par Microsoft. L'SBC ne fait pas confiance au proxy SIP : Votre SBC doit avoir le certificat racine "Baltimore CyberTrust Root" (ou son successeur) installé pour faire confiance aux serveurs Teams. Certificat invalide ou expiré : Une cause simple mais fréquente. Chaîne de certificats manquante : L'SBC doit présenter non seulement son propre certificat, mais aussi les certificats intermédiaires qui le lient à la racine de confiance.
Un autre point crucial est la correspondance entre le nom de domaine (FQDN) et le certificat.
Le FQDN que vous avez déclaré à Teams via la commande PowerShell New-CsOnlinePSTNGateway doit correspondre exactement au Common Name (CN) ou à un Subject Alternative Name (SAN) du certificat de l'SBC.
Configuring Audiocodes SBC for Microsoft Teams Direct Routing
Cette vidéo montre un exemple pratique très parlant de l'importance des certificats racine.
Regardez le segment de 07:13 à 08:44. L'administrateur installe le certificat racine "Baltimore" sur l'SBC. Observez dans l'interface de supervision de l'SBC (à partir de 08:20) comment le statut des proxys Microsoft passe immédiatement à "online". C'est la preuve directe de l'importance de cette chaîne de confiance.
3. Catégorie de Problème n°2 : Pare-feu et Réseau
Supposons que vos certificats soient parfaits. La connexion peut toujours échouer si le trafic réseau est bloqué. Les pare-feu et les configurations NAT (Network Address Translation) sont les suspects habituels.
Le symptôme typique est que le Health Dashboard affiche un avertissement pour les options SIP, ou que l'SBC reste inactif, même si la configuration semble correcte.
Configuring Audiocodes SBC for Microsoft Teams Direct Routing
Voici un exemple de diagnostic en direct où l'administrateur identifie un problème de pare-feu.
Regardez de 08:44 à 10:01. Malgré des certificats corrects, le statut dans le Teams Admin Center reste "inactive". L'administrateur réalise que le port de signalisation SIP (5061/TCP) n'est pas ouvert pour le trafic entrant sur son routeur. C'est une erreur de configuration classique qui bloque les options SIP envoyées par Microsoft vers l'SBC.
Les points à vérifier sont :
- Pare-feu : Le port 5061/TCP doit être autorisé en entrée depuis toutes les adresses IP de signalisation de Microsoft 365 vers l'interface publique de votre SBC.
- NAT : Si votre SBC est derrière un NAT, vous devez vous assurer que le trafic arrivant sur votre IP publique sur le port 5061 est correctement transféré vers l'IP privée de l'SBC sur ce même port.
4. Catégorie de Problème n°3 : Configuration SIP
La connexion TLS est établie et le réseau est ouvert, mais l'SBC ne devient toujours pas "Actif". Le problème se situe probablement au niveau du contenu des messages SIP eux-mêmes.
SBC connectivity issues - Microsoft Teams
Retournons à notre guide de dépannage. Cette section aborde les problèmes qui surviennent après l'établissement de la connexion TLS.
Lisez la section "SIP options issues". Les points clés à retenir sont : L'SBC reçoit une réponse 200 OK mais pas les options SIP de Microsoft : Vérifiez vos règles de pare-feu en entrée, comme nous l'avons vu. Le statut est "intermittently inactive" (inactif par intermittence) : Cela arrive souvent si l'SBC est configuré pour envoyer des options SIP à des adresses IP spécifiques au lieu des FQDN (sip.pstnhub.microsoft.com, sip2..., sip3...). Les IP peuvent changer, mais les FQDN sont stables. Le domaine n'est pas activé : N'oubliez pas qu'après avoir ajouté un domaine SBC, vous devez y assigner au moins un utilisateur avec une licence (E3/E5 + Teams Phone) pour l'activer dans tout l'environnement Microsoft 365.
Enfin, une vérification de base mais essentielle est de s'assurer que l'envoi des options SIP est bien activé sur votre SBC et du côté de Teams.
Configuring and Managing Teams Phone Direct Routing
Cette vidéo rappelle le paramètre fondamental qui active la surveillance par options SIP.
Regardez le passage de 08:40 à 09:57. Le présentateur met en évidence le paramètre -SipOptionsEnabled dans la configuration du PSTNGateway côté Teams. Il doit être à $true (c'est la valeur par défaut). Il insiste sur le fait de ne jamais le désactiver, car Teams n'aurait plus aucun moyen de savoir si l'SBC est fonctionnel.
Synthèse : Votre Check-list de Diagnostic
Face à un SBC inactif ou en alerte, voici une approche méthodique inspirée de votre expérience en support IT :
-
Consulter le Symptôme (Teams Admin Center) : Quel est le statut exact dans le Health Dashboard ? (
Inactive,Warning: No SIP Options,Warning: Certificate Expired). -
Analyser la Couche 1 (TLS/Certificats) :
- Le certificat de l'SBC est-il valide et émis par une autorité de confiance ?
- La chaîne de certificats est-elle complète sur l'SBC ?
- Le FQDN de l'SBC correspond-il au CN/SAN du certificat ?
- L'SBC a-t-il le bon certificat racine pour faire confiance à Microsoft ?
-
Analyser la Couche 2 (Réseau/Pare-feu) :
- Le port 5061/TCP est-il bien ouvert en entrée vers l'SBC ?
- La règle de NAT est-elle correcte ?
- La résolution DNS du FQDN de l'SBC pointe-t-elle vers la bonne IP publique ?
-
Analyser la Couche 3 (SIP/Configuration) :
- L'envoi des options SIP est-il activé sur l'SBC ?
- Le paramètre
SipOptionsEnabledest-il à$truedans la configuration du gateway Teams ? - L'SBC est-il configuré pour envoyer les options SIP aux FQDN de Microsoft, et non à des IP fixes ?
- Le domaine du SBC est-il bien activé dans votre tenant ?
Conclusion
Vous avez maintenant les outils intellectuels pour passer de la simple observation à un diagnostic actif des problèmes de connectivité du Direct Routing. Vous comprenez que derrière un simple statut "Inactif" se cache une chaîne de dépendances techniques, et vous savez investiguer méthodiquement chaque maillon de cette chaîne.
Points clés à retenir :
- Le statut "Actif" d'un SBC est le résultat d'un échange réussi de messages SIP OPTIONS, qui dépend d'une connexion TLS valide.
- Les problèmes de certificats sont la cause la plus fréquente des échecs de connexion TLS initiale.
- Les règles de pare-feu et de NAT sont la deuxième cause la plus courante, bloquant souvent les options SIP entrantes de Microsoft.
- Une configuration SIP incorrecte (FQDN dans les en-têtes, utilisation d'IP au lieu de FQDN) peut causer des problèmes même lorsque le réseau et les certificats sont corrects.
Prochaine étape :
Maintenant que nous savons comment nous assurer que le trunk SIP est bien "en vie", la prochaine leçon portera sur le diagnostic des problèmes au niveau des appels eux-mêmes. Nous apprendrons à analyser les rapports d'erreurs d'appel pour comprendre pourquoi un appel spécifique a échoué via le Direct Routing.