Dépannage SBC Teams Direct Routing : pannes SIP OPTIONS, erreurs TLS, problèmes audio et désactivation de domaine

Microsoft Teams Direct Routing possède un mode de défaillance frustrant : Teams vous indique rarement pourquoi quelque chose s’est cassé. Le trunk Direct Routing du SBC passe de “Active” à “Inactive” dans le centre d’administration, les appels cessent de se connecter, et le seul signal opérationnel que vous recevez est l’absence de signal. Le côté Microsoft de la connexion est une boîte noire ; tout ce qui est diagnosticable se trouve de votre côté.

C’est à cela que sert ce guide. Il parcourt les catégories de défaillance rencontrées dans les déploiements de production réels (pannes de heartbeat SIP OPTIONS, erreurs de handshake TLS, problèmes de média avec audio unidirectionnel et absence d’audio, désactivation de domaine Direct Routing, particularités NAT et pare-feu spécifiques à Teams DR) et vous propose un ordre de triage qui résout la plupart des incidents en moins d’une heure. Il suppose que le SBC est déjà déployé et qu’il a fonctionné à un moment donné, et que vous avez accès aux traces d’appel du SBC, à la capture de paquets et à la configuration du profil TLS. Si vous êtes encore en phase de déploiement initial, le guide Teams Direct Routing couvre les prérequis et la configuration initiale ; cet article prend le relais là où celui-ci s’arrête.

Le modèle mental à trois couches pour le triage

Presque tous les problèmes Teams Direct Routing se réduisent à une défaillance dans l’une des trois couches, et le symptôme observé vous indique laquelle examiner en premier. Construire ce modèle mental fait la différence entre trente minutes de triage et trois heures de tâtonnement.

Couche de signalisation. Le handshake TLS et l’échange SIP entre le proxy SIP de Microsoft et votre SBC. Les défaillances ici produisent des trunks marqués “Inactive”, des erreurs SIP OPTIONS soutenues et des appels qui n’atteignent jamais l’état de sonnerie.

Couche média. L’échange SRTP/RTP entre Teams (ou le Teams Media Processor) et votre SBC, puis entre le SBC et l’opérateur. Les défaillances ici produisent des appels qui se connectent et répondent normalement mais sans audio, avec un audio unidirectionnel, ou un audio qui coupe aléatoirement après une mise en attente ou une reprise d’appel.

Couche applicative. Les politiques de routage Teams, les routes vocales, les plans de numérotation, l’attribution des licences utilisateur et les règles de routage du SBC. Les défaillances ici produisent des utilisateurs spécifiques ou des modèles de numérotation spécifiques qui échouent tandis que tout le reste fonctionne.

L’erreur que commettent la plupart des équipes est de se lancer dans une capture de paquets avant de classifier quelle couche est en cause. Le tableau de triage rapide ci-dessous est conçu pour effectuer cette classification rapidement, en deux colonnes de décision avant d’ouvrir Wireshark.

Triage rapide : du symptôme à la cause probable

Associez ce que vous observez à la cause la plus probable et à la couche à examiner en premier. La plupart des incidents de production correspondent à l’une de ces lignes.

Une fois la couche identifiée, la section correspondante ci-dessous fournit le détail du diagnostic.

Pannes SIP OPTIONS : la cause de panne la plus fréquente

La panne SIP OPTIONS est la cause la plus fréquente d’une interruption Teams DR affectant l’ensemble du système plutôt qu’un appel utilisateur spécifique. Comprendre ce que fait OPTIONS, et exactement comment Teams réagit lorsqu’il cesse de fonctionner, vous amène à la cause racine plus rapidement qu’une capture de paquets.

Il s’agit d’un échange coordonné des deux côtés : Microsoft envoie des OPTIONS au FQDN de votre SBC sur le port TLS 5061, attend un 200 OK dans les quelques secondes et répète l’opération environ toutes les minutes. Votre SBC fait la même chose dans la direction inverse, envoyant des OPTIONS au proxy SIP régional de Microsoft et attendant un 200 OK en retour. Les deux directions doivent réussir en continu pour que Teams considère le trunk comme sain. Si l’une des directions échoue de manière constante pendant plusieurs minutes, Teams bascule le FQDN en “Inactive” et cesse de router les appels vers ou depuis ce SBC.

OPTIONS échoue à cause d’une défaillance TLS ou de résolution DNS, pas du SIP. La cause racine la plus fréquente d’une panne OPTIONS n’est pas la requête OPTIONS elle-même mais le handshake TLS qui doit réussir avant qu’une requête SIP puisse être envoyée. Si le TLS échoue, aucune requête OPTIONS n’est jamais échangée, le SBC ne voit rien, et Microsoft voit une absence totale de réponse. La section Handshake TLS ci-dessous couvre ces causes racines en détail.

OPTIONS échoue parce que le SBC a cessé d’envoyer ou que la résolution DNS a échoué. La direction inverse (SBC vers Microsoft) se casse si le NAP sortant vers Microsoft est mal configuré, si son profil TLS pointe vers le mauvais certificat, ou si une règle de routage bloque la méthode SIP OPTIONS sur le chemin sortant. Le signal dans le journal du SBC est « no response » ou « timeout » contre l’adresse du proxy SIP de Microsoft, sans 200 OK entrant correspondant.

Le 200 OK qui semble correct mais ne l’est pas. Un SBC peut répondre aux OPTIONS de Microsoft avec un 200 OK contenant des en-têtes Contact ou Via que Teams n’accepte pas. Teams traite la réponse comme malformée et peut toujours marquer le FQDN “Inactive” malgré le succès apparent. Si le journal du SBC montre que les OPTIONS sont reçus et qu’un 200 OK est envoyé, mais que le trunk reste “Inactive”, capturez le 200 OK complet dans une trace de paquets et inspectez chaque en-tête. L’en-tête Contact doit faire référence au FQDN du SBC, et non à son IP, et la chaîne d’en-têtes Via doit être valide.

Comment Teams décide de désactiver. Microsoft ne publie pas de seuils exacts, mais en pratique, une panne OPTIONS soutenue (plusieurs minutes consécutives d’échec dans l’une ou l’autre direction) suffit à basculer le trunk en “Inactive”. La récupération n’est pas toujours immédiate une fois la cause corrigée : Teams attend généralement un succès soutenu avant de revenir à “Active”, ce qui peut prendre de cinq à quinze minutes après la mise en place de la correction. Ne supposez pas que votre correctif n’a pas fonctionné simplement parce que le centre d’administration est lent à se rafraîchir.

Échecs de handshake TLS

Les échecs TLS sont la cause racine la plus fréquente d’une panne Direct Routing, et ils ont un ensemble restreint de déclencheurs bien compris. Le tableau ci-dessous les résume, avec le signal dans les journaux que vous pouvez utiliser pour confirmer chacun et le correctif.

Deux de ces déclencheurs méritent un examen plus approfondi. La mise à jour des CA racines Microsoft entrée en vigueur au cours de 2026 a provoqué une vague d’échecs « Unknown CA » dans les déploiements Direct Routing, car le magasin de confiance du SBC ne contenait pas les nouvelles racines DigiCert et Microsoft 2017 que Microsoft commençait à présenter dans ses certificats serveur. Si votre SBC utilise l’ancienne configuration du magasin de confiance et que votre trunk a été intermittent ou hors service depuis début 2026, c’est la cause la plus probable et la résolution consiste à importer les sept CA racines requises dans le magasin de confiance.

L’autre déclencheur à surveiller est l’incompatibilité de FQDN après un renouvellement de certificat. Les renouvellements suppriment parfois une entrée Subject Alternative Name (SAN), en particulier dans les déploiements multi-tenant où le SBC présente un certificat wildcard couvrant plusieurs sous-domaines. Après chaque renouvellement de certificat, exécutez un test TLS contre le FQDN du SBC sur le port 5061 et confirmez que le certificat servi inclut chaque FQDN enregistré pour ce SBC dans Teams. Le guide de configuration TLS et SRTP du SBC couvre l’ensemble des schémas de configuration ; cet article se concentre sur ce qui les casse.

Problèmes d’audio unidirectionnel et d’absence d’audio

Lorsque la signalisation fonctionne (les appels se connectent, le téléphone de l’appelé sonne, les deux côtés décrochent) mais que l’audio est absent dans une ou les deux directions, le problème se situe dans le chemin média. La difficulté du triage média réside dans le fait que plusieurs causes distinctes produisent toutes le même symptôme apparent, et seule une capture de paquets ou un rapport MOS par appel permet de les différencier.

Incompatibilité du contexte cryptographique SRTP. Les deux extrémités s’accordent sur SRTP dans le SDP, mais la clé cryptographique, la suite de chiffrement ou la longueur de la balise d’authentification ne correspondent pas. Le côté Teams exige AES-CM avec HMAC-SHA1 ; si le SDP côté opérateur propose un chiffrement différent ou omet l’attribut crypto, le SBC négocie des contextes incohérents sur chaque segment et doit effectuer lui-même le rechiffrement SRTP, au prix de performances et de latence. Le correctif consiste à imposer la liste de chiffrements AES-CM sur les deux profils NAP et à confirmer que le SBC effectue la réécriture cryptographique entre les segments au lieu de laisser passer le SDP sans modification. L’aperçu SRTP couvre les options de chiffrement en détail.

Changement de clé cryptographique SRTP au cours des échanges SDP. Microsoft Teams exige que la clé cryptographique SRTP reste la même pendant toute la durée de l’appel. Aucune renégociation de clé SRTP ne doit avoir lieu ; sinon, l’audio peut être coupé ou mal déchiffré, et l’appel pourrait même être raccroché par Teams.

Le chemin média du SBC ne s’ouvre jamais vers un côté. Si le SBC possède plusieurs interfaces réseau (une interface publique côté Teams et une interface privée côté opérateur), le routage média doit être explicitement lié à la bonne interface par NAP. Une mauvaise configuration produit un chemin RTP à moitié ouvert : le SBC envoie le média vers un côté et les paquets retour vont vers une interface obsolète. Le signal est « no RTP received » sur un segment dans la trace d’appel, tandis que l’autre segment affiche des compteurs de paquets normaux.

La translation NAT casse le port RTP entrant. Lorsque le SBC se trouve derrière un NAT, l’adresse publique annoncée dans le SDP doit correspondre à l’adresse que le pare-feu mappe effectivement. Un mode de défaillance courant est que le média du SBC est lié à son adresse privée, le SDP annonce cette adresse, et l’extrémité distante tente alors d’envoyer du RTP vers une destination non routable. Le correctif consiste à définir l’adresse média externe du SBC explicitement sur le NAP côté Teams et à confirmer que le pare-feu dispose d’un mappage de port stable pour la plage média.

Incompatibilité offre/réponse de codec. Teams DR exige SILK, OPUS ou G.711 côté Teams. Si le côté opérateur propose AMR, GSM ou iLBC et que le SBC ne dispose pas de transcodeur matériel, le SBC négocie G.711 côté Teams et ne parvient pas à livrer de média côté opérateur. Le signal est « no compatible codec » ou un 488 Not Acceptable Here sur un segment. Alignez la liste de codecs sur le trunk opérateur ou ajoutez un transcodeur.

Media bypass activé sans préparation du pare-feu. Le media bypass modifie le chemin média : au lieu que le média passe par le Media Processor régional de Microsoft, il circule directement entre le client Teams et le SBC. Le pare-feu du SBC doit désormais accepter le média provenant de l’ensemble de la plage IP média de Microsoft (et non uniquement de la plage du proxy SIP), et sur l’internet public plutôt qu’au sein du réseau contrôlé de Microsoft. Un bypass qui fonctionnait en laboratoire casse souvent en production parce que cette modification du pare-feu n’a jamais été effectuée.

L’audio coupe à un intervalle régulier. Un audio qui coupe au même intervalle est presque toujours un problème de timer de session SIP (RFC 4028) plutôt qu’un problème média. L’un des côtés ne rafraîchit pas la session via re-INVITE ou UPDATE, le timer expire, et l’appel est terminé. Le timer de session est le messager plutôt que la cause racine, qui est presque toujours un problème d’interopérabilité SRTP lors de la négociation SDP affectant la séquence de rollover des paquets RTP. L’étape de dépannage reste de configurer le SBC pour rafraîchir la session du côté qui ne le fait pas.

Domaine Direct Routing marqué « Inactive »

L’état “Inactive” dans le Teams Admin Center est le seul signal opérationnel visible que Microsoft vous donne, et il est en aval de la défaillance qui l’a causé. Traitez “Inactive” comme un symptôme, pas comme un diagnostic.

L’état est affiché sous Voice → Direct Routing → SBCs dans le Teams Admin Center, par FQDN de SBC. La page affiche la santé actuelle du SBC et l’heure du dernier échange SIP OPTIONS réussi dans chaque direction. Lorsque le FQDN est “Inactive”, Teams cesse de router les nouveaux appels sortants vers ce SBC et rejette les INVITE entrants provenant de celui-ci. Les appels en cours continuent généralement jusqu’à leur terminaison naturelle.

La séquence de récupération est cohérente pour la plupart des causes :

1. Confirmez que le FQDN du SBC est résolvable publiquement et que le SBC est accessible sur TCP/TLS 5061 depuis l’internet public.
2. Confirmez la résolution DNS du SBC.
3. Confirmez que le certificat du SBC n’est pas expiré et inclut le FQDN enregistré dans son SAN.
4. Confirmez que le magasin de confiance du SBC inclut les CA racines Microsoft actuelles (chaîne DigiCert Global Root G2 plus les racines Microsoft 2017, tel qu’exigé par la mise à jour des CA racines de 2026).
5. Inspectez la trace d’appel du SBC pour les OPTIONS entrants et sortants. Confirmez que les deux directions sont présentes et retournent un 200 OK.
6. Si les deux directions semblent saines au niveau du SBC et que le trunk reste “Inactive”, capturez une trace de paquets de la réponse 200 OK et inspectez chaque en-tête. Des en-têtes Contact ou Via malformés sont le tueur silencieux d’une réponse par ailleurs valide.

Si le FQDN n’est jamais passé à “Active” (un nouveau SBC en cours d’ajout), la cause racine la plus probable est une incompatibilité de FQDN entre le SAN du certificat et la valeur enregistrée dans Teams, ou un DNS pas encore propagé pour le FQDN. Les deux produisent un état “Inactive” indéfini sans récupération ; il n’y a pas de défaillance à corriger car le chemin de confiance ne s’est jamais établi.

NAT et pare-feu : particularités spécifiques à Teams DR

Les règles génériques de pare-feu SIP ne suffisent pas pour Teams Direct Routing. Microsoft utilise un ensemble spécifique d’adresses de signalisation, la plage d’adresses média est bien plus grande que ce à quoi la plupart des équipes s’attendent, et la fonctionnalité de pare-feu la plus susceptible d’interférer (SIP ALG) est activée par défaut sur de nombreux pare-feu d’entreprise. Trois choses cassent Teams DR plus que toute autre.

Le SIP ALG doit être désactivé. Les passerelles de couche applicative SIP (SIP ALG) réécrivent les en-têtes SIP et les adresses SDP en transit, ce qui n’est presque jamais compatible avec mTLS (le pare-feu ne peut pas voir à l’intérieur du flux chiffré pour le réécrire) et n’est jamais compatible avec le comportement SDP prévisible attendu par Teams. Si le pare-feu sur l’interface publique du SBC a le SIP ALG activé, Teams DR fonctionnera de manière intermittente ou pas du tout, et le mode de défaillance ressemblera à un problème média ou un problème d’en-tête SIP. Désactivez le SIP ALG sur le pare-feu, point final. L’aperçu de la sécurité SBC explique pourquoi l’application SIP doit être gérée par le SBC, et non par le pare-feu.

La plage d’adresses de signalisation de Microsoft doit être accessible. La signalisation Teams DR provient d’une plage IP Microsoft documentée (les FQDN des proxy SIP sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com et sip3.pstnhub.microsoft.com se résolvent dans cette plage). Le pare-feu doit autoriser le TLS entrant sur le port 5061 depuis ces adresses vers le FQDN de votre SBC. Microsoft met à jour cette plage périodiquement ; si votre pare-feu utilise une liste d’autorisation statique, vous verrez des pannes intermittentes lorsque Microsoft élargit la plage. Utilisez des règles d’autorisation basées sur le FQDN ou abonnez-vous au flux d’URL et de plages d’adresses IP de Microsoft.

La plage d’adresses média est plus grande que prévu. Le Teams Media Processor utilise une plage d’adresses ; le media bypass en utilise une autre (l’adresse du client Teams, qui peut être n’importe où sur l’internet public). Si votre pare-feu SBC n’ouvre que la plage du Media Processor, le media bypass échouera. Si vous souhaitez le bypass, la plage de ports média du SBC doit être accessible depuis n’importe quelle IP source, le filtrage SIP du SBC effectuant la validation par appel plutôt que le pare-feu.

Une autre particularité qui revient régulièrement : le NAT asymétrique sur un SBC multi-homed. Si le SBC a des interfaces publique et privée séparées et que le binding média est incorrect, le RTP sort par une interface et les paquets retour arrivent sur l’autre. Le SBC les rejette car la source ne correspond pas à la session établie. Verrouillez le binding média explicitement sur la bonne interface du NAP côté Teams.

Lecture des traces SIP pour Teams DR

Une fois la couche identifiée et les causes évidentes éliminées, l’outil de diagnostic est la trace SIP. Les deux fonctionnalités ProSBC les plus utilisées pour le triage Teams DR sont la trace d’appel par NAP (qui enregistre la signalisation SIP au niveau du trunk-group) et la capture Wireshark en direct (qui offre une visibilité complète au niveau des paquets sur la messagerie SIP, la résolution DNS et le média). Les deux s’exécutent sur le SBC sans sondes externes.

Voici une courte liste d’éléments à inspecter en premier dans toute trace Teams DR.

L’échange OPTIONS. Confirmez que les OPTIONS sont reçus de Microsoft et renvoyés avec un 200 OK. Confirmez que les OPTIONS sont envoyés du SBC vers Microsoft et qu’un 200 OK revient. Si l’une des directions est absente, la relation de confiance est rompue et le trunk sera “Inactive” quel que soit le trafic d’appels.

Le handshake TLS. Si vous disposez d’une capture au niveau des paquets, le handshake TLS vous indique immédiatement si le problème est la validation du certificat, la négociation du chiffrement ou une incompatibilité de version. Un handshake qui aboutit mais est immédiatement suivi d’une alerte TLS de Microsoft signifie que le certificat a été accepté mais que quelque chose dans l’échange SIP était inacceptable.

Les en-têtes du 200 OK. Inspectez les en-têtes Contact et Via sur le 200 OK des OPTIONS. Le Contact doit être le FQDN de votre SBC sur le transport configuré. Le Via doit refléter le SBC, et non un système en aval.

Le SDP lors de l’établissement de l’appel. Pour les cas de panne audio, le SDP dans l’INVITE et le 200 OK de réponse vous indique la liste de codecs proposée par chaque côté, l’attribut crypto SRTP et l’adresse média. Comparez l’adresse annoncée avec l’adresse d’où le média arrive réellement. Les bonnes pratiques de surveillance VoIP couvrent ce qu’il faut suivre en continu pour que ce type de triage démarre sur une base plus riche.

Confirmation de la réécriture d’en-têtes. Teams a un dialecte SIP spécifique, et un déploiement Teams DR fonctionnel repose presque toujours sur la manipulation d’en-têtes SIP au niveau du SBC pour normaliser entre Teams et l’opérateur. Si les en-têtes ne sont pas réécrits, la trace montrera les en-têtes Teams passant inchangés vers l’opérateur (ou inversement), et l’un des côtés rejettera l’appel. Confirmez que les règles de réécriture sur les NAP concernés sont chargées.

Le guide de triage

Lorsqu’un incident Teams DR survient et que vous n’avez que « les appels ne fonctionnent plus », les étapes ci-dessous résolvent la plupart des cas en moins d’une heure. Elles sont ordonnées par probabilité, et non par sévérité.

1. Ouvrez le Teams Admin Center et vérifiez l’état du FQDN du SBC. S’il est “Inactive”, le problème est la signalisation et vous passez à l’étape 2. S’il est “Active”, le problème est le média ou l’applicatif et vous passez à l’étape 5.
2. Confirmez que le certificat du SBC n’est pas expiré et que le FQDN enregistré correspond à un Subject Alternative Name sur le certificat servi. La plupart des incidents “Inactive” constatés sont des problèmes de certificat.
3. Confirmez que le magasin de confiance du SBC contient les CA racines Microsoft actuelles (la mise à jour des CA racines de 2026 est le changement le plus récent à déployer). Les racines manquantes produisent des échecs de handshake « Unknown CA » et un état “Inactive” immédiat.
4. Inspectez la trace d’appel du SBC pour les OPTIONS entrants et sortants. Si les OPTIONS sortants sont absents, le NAP sortant vers Microsoft est mal configuré. Si les OPTIONS entrants arrivent mais que le 200 OK a un Contact ou Via malformé, la réponse est le problème.
5. Si le trunk est “Active” mais que les appels entrants n’atteignent pas l’utilisateur, la cause se situe dans la couche applicative Teams (politique de routage vocal, route vocale, plan de numérotation, attribution de licence, indicateur utilisateur activé pour Teams Phone). Le SBC est sain ; la configuration Teams ne l’est pas.
6. Si l’audio est absent sur des appels qui se connectent, capturez une trace au niveau RTP et confirmez que le média arrive au SBC depuis les deux directions. Un média manquant d’un côté est un problème de chemin média ou de NAT ; un média présent mais sans audio est un problème de contexte cryptographique SRTP.
7. Si l’audio coupe à des intervalles réguliers, la cause est généralement les timers de session RFC 4028, et non le chemin média. Configurez le SBC pour rafraîchir la session.
8. Si les problèmes sont nouveaux et sont apparus sans élément déclencheur, vérifiez l’expiration du certificat dans les 30 prochains jours, un timeout NAT plus court que l’intervalle OPTIONS, et les modifications récentes du pare-feu ou de la configuration opérateur.

Si vous atteignez la fin du guide et que le problème n’est pas résolu, l’étape suivante est une capture de paquets filtrée sur l’adresse du proxy SIP de Microsoft et les adresses média concernées. À ce stade, les données nécessaires pour une escalade au support, que ce soit vers TelcoBridges, votre opérateur ou Microsoft, sont en main.

Questions fréquentes