Routage direct Microsoft Teams (Direct Routing) : fonctionnement, exigences et choix du bon SBC

Si votre organisation utilise Microsoft Teams et paie pour les forfaits d’appel Microsoft (Calling Plans) pour accéder au réseau téléphonique, il y a de fortes chances que vous laissiez de l’argent sur la table. Le routage direct Microsoft Teams (Direct Routing) vous permet de connecter Teams Phone System à n’importe quel opérateur PSTN de votre choix, en conservant vos contrats existants, vos jonctions SIP et les tarifs que vous avez déjà négociés.
Le pont qui rend tout cela possible est un contrôleur de session en bordure (SBC). Le SBC se positionne entre votre infrastructure opérateur et Microsoft 365, gérant le chiffrement, la normalisation SIP et la traduction de protocole exigés par Teams. Ce guide couvre le fonctionnement du Direct Routing, les exigences techniques de Microsoft pour votre SBC, comment évaluer un SBC pour un déploiement en production et les étapes de configuration pour acheminer les appels.

Qu’est-ce que le routage direct Microsoft Teams (Direct Routing) ?

Le routage direct Microsoft Teams (Direct Routing) est une fonctionnalité de Teams Phone System qui connecte Microsoft 365 à n’importe quel opérateur PSTN via un contrôleur de session en bordure. Plutôt que d’acheter des forfaits d’appel Microsoft (Calling Plans) ou de souscrire auprès d’un fournisseur Operator Connect, vous apportez votre propre opérateur et votre propre SBC.

Différences avec les forfaits d’appel et Operator Connect

Modèle	Choix de l’opérateur	SBC requis	Flexibilité
Direct Routing	N’importe quel opérateur	Votre propre SBC	Contrôle total
Operator Connect	Programme limité	Géré par l’opérateur	Modéré
Forfaits d’appel coûteux	Microsoft uniquement	Non requis	Limitée

Quand choisir le Direct Routing

• Contrats de jonctions SIP existants à des tarifs négociés que vous ne souhaitez pas remplacer.
• Migration d’un PBX existant : passerelle entre Teams et la téléphonie sur site pendant une transition.
• Exigences de conformité : enregistrement des appels, duplication des appels ou configurations de résidence des données appliquées au niveau du SBC.
• Interopérabilité des jonctions SIP : optimisez votre structure de coûts et assurez la redondance tout en maintenant l’interopérabilité avec différents fournisseurs de jonctions SIP.
• Prestation de services gérés : fournir la voix Teams à plusieurs locataires d’entreprise en utilisant votre propre backbone opérateur.

Ce que Microsoft exige de votre SBC

Microsoft a publié des exigences techniques détaillées pour les SBC utilisés en Direct Routing. Elles sont non négociables : Teams refusera de se connecter à un SBC qui ne les satisfait pas.

Enregistrement du FQDN

Votre SBC doit disposer d’un nom de domaine pleinement qualifié (FQDN) résolvable publiquement, enregistré dans le Centre d’administration Teams. Microsoft l’utilise pour la signalisation SIP et la validation du certificat TLS. Les adresses IP nues ne sont pas acceptées.

TLS pour la signalisation SIP (obligatoire)

Toute la signalisation SIP entre Teams et votre SBC doit utiliser Transport Layer Security (TLS), version minimale TLS 1.2, avec un certificat d’une autorité de certification approuvée par Microsoft dont le Subject Alternative Name correspond au FQDN de votre SBC.

SRTP pour le chiffrement des médias (obligatoire)

Tous les médias RTP doivent être chiffrés à l’aide du Secure Real-time Transport Protocol (SRTP). Teams n’accepte pas le RTP non chiffré provenant du SBC. Comme de nombreux opérateurs PSTN délivrent encore du RTP non chiffré, votre SBC doit convertir de manière transparente entre les deux formats, gérant l’échange de clés sur chaque segment de manière indépendante, pour que ni l’opérateur ni Teams n’ait besoin de modifier quoi que ce soit.

Pulsation SIP OPTIONS

Teams envoie périodiquement des requêtes SIP OPTIONS pour vérifier que votre SBC est actif, et le SBC doit répondre avec un 200 OK. Une réponse manquante ou retardée amène Teams à marquer le SBC comme hors ligne, et inversement. C’est l’une des causes les plus courantes des tickets d’assistance « Le SBC apparaît hors ligne dans le Centre d’administration Teams ».

Compatibilité des messages SIP

Teams utilise un dialecte SIP spécifique. Les en-têtes et corps SIP courants dans le SIP traditionnel des opérateurs (certains P-headers, extensions propriétaires, champs non standard) peuvent être rejetés. Votre SBC doit normaliser les en-têtes sur les deux segments : en supprimant ou remappant ce que Teams n’accepte pas en entrée, et en traduisant le SIP de Teams pour votre opérateur en sortie.

Ce qu’il faut rechercher dans un SBC pour le Direct Routing

Architecture B2BUA

Un agent utilisateur dos-à-dos (B2BUA) termine complètement la session SIP sur un segment et en réinitie une nouvelle de l’autre côté, donnant au SBC un contrôle total sur chaque message SIP dans les deux directions. Un proxy SIP transmet les messages avec une capacité de modification limitée, une limitation fondamentale lorsque vous devez supprimer des en-têtes propriétaires d’un opérateur avant qu’ils n’atteignent Teams, ou injecter des en-têtes d’identité qu’une plateforme UCaaS exige. Pour le Direct Routing, l’architecture B2BUA permet une manipulation approfondie des en-têtes, une négociation de transport indépendante par segment et le masquage de topologie.

Configuration TLS et SRTP indépendante par segment

Recherchez un SBC qui configure la sécurité du transport de manière indépendante sur chaque groupe de jonctions : TLS/SRTP vers Teams, quel que soit le protocole pris en charge par votre opérateur de l’autre côté. La conversion native RTP vers SRTP est essentielle. Le SBC agit comme la frontière de chiffrement entre votre réseau opérateur et l’infrastructure Teams, sans exiger de votre opérateur qu’il modifie quoi que ce soit.

Moteur de manipulation des en-têtes SIP

Un moteur basé sur des règles, configurable par groupe de jonctions, est essentiel pour tout déploiement Direct Routing non trivial. Plus ce moteur est configurable, plus il est facile de s’adapter lorsqu’un opérateur modifie son implémentation SIP ou lorsqu’un nouveau locataire d’entreprise nécessite un traitement différent.

Masquage de topologie

Le masquage de topologie dissimule les adresses IP internes de chaque côté par rapport à l’autre. Teams ne voit jamais l’adressage privé de votre opérateur, et votre opérateur ne voit jamais l’infrastructure de Microsoft. Il s’agit à la fois d’une mesure de sécurité et d’une nécessité pratique dans les environnements multi-opérateurs ou multi-locataires.

Capacité adaptée à la taille de votre déploiement

Vérifiez la capacité de sessions simultanées, le nombre maximal de groupes de jonctions et les limites d’enregistrement des points d’accès par rapport à votre charge anticipée. Pour les déploiements en production, la haute disponibilité 1+1 sans perte de service est une exigence de base ; un SBC défaillant signifie l’arrêt du trafic vocal pour tous les utilisateurs concernés.

Flexibilité de déploiement cloud et hybride

Teams Phone s’exécute dans Microsoft Azure. Un SBC déployable nativement dans Azure minimise la latence entre le SBC et l’infrastructure Microsoft 365. Pour les organisations ayant des besoins hybrides (un PBX sur site à relier, un centre de données existant), la disponibilité sur Azure et AWS ou sur VMware, KVM et baremetal vous donne la flexibilité de placer le SBC là où votre infrastructure se trouve réellement. Pour les MSP et les fournisseurs de services livrant la voix Teams à plusieurs locataires d’entreprise, l’isolation du routage par locataire et la capacité de groupes de jonctions comptent tout autant que le nombre brut de sessions.

Considérations de sécurité au niveau du SBC

Le SBC est la frontière entre votre infrastructure côté opérateur et le cloud Teams. L’exigence TLS/SRTP de Teams sécurise le segment Teams, mais le SBC est exposé à Internet et doit être durci contre le paysage de menaces propre aux infrastructures SIP accessibles au public.

Atténuation DoS et DDoS

Les SBC acceptant du SIP entrant depuis Internet sont des cibles pour les attaques par saturation SIP. L’atténuation intégrée des DoS/DDoS au niveau de la bordure du SBC, opérant avant que le trafic malveillant n’atteigne votre cœur de téléphonie, est une exigence standard pour tout déploiement exposé à Internet.

Protection contre le balayage d’enregistrement SIP

Un schéma d’attaque courant est le balayage d’enregistrement SIP : sonder le SBC avec de grands volumes de requêtes REGISTER pour énumérer les utilisateurs valides ou localiser les points d’accès vulnérables. La détection et le blocage automatiques des rafales d’enregistrement constituent une exigence de sécurité fondamentale.

Contrôle d’accès dynamique des appels

La mise en liste de blocage dynamique de plages d’adresses IP ou de schémas de numéros appelants/appelés (y compris la mise en liste grise pour le trafic anormal) permet une réponse en temps réel aux événements de fraude ou aux incidents opérateur sans mettre le SBC hors ligne pour reconfiguration.

Détection de fraude en temps réel

Pour les fournisseurs de services livrant le Direct Routing en tant que service géré, l’évaluation de la fraude par appel est une capacité requise. Le SBC doit inspecter chaque appel et attribuer un score de risque, appliqué nativement ou via l’intégration avec un partenaire validé de détection de fraude, pour intercepter la fraude aux appels longue distance, le robocalling ou les schémas d’usurpation d’identité avant qu’ils ne génèrent une exposition de facturation.

La frontière de chiffrement

Le SBC est le point de terminaison et de traduction du chiffrement. Il maintient TLS/SRTP vers Teams et négocie indépendamment le transport avec votre opérateur. Les médias non chiffrés provenant de votre opérateur sont convertis en SRTP avant d’atteindre Teams, maintenant votre infrastructure vocale sécurisée de bout en bout, quel que soit le transport de l’opérateur.

Exemple de configuration (vue d’ensemble)

Ce qui suit décrit les étapes clés d’un déploiement typique de SBC pour le Direct Routing. Pour un guide détaillé étape par étape, consultez la documentation de configuration Direct Routing Teams de votre fournisseur de SBC.

1. Enregistrez le FQDN de votre SBC dans le Centre d’administration Microsoft TeamsNaviguez vers Voix > Routage direct > Ajouter. Enregistrez le FQDN de votre SBC, l’identifiant que Teams utilise pour router les appels et valider le certificat TLS.
2. Obtenez et installez un certificat TLSInstallez un certificat d’une autorité de certification approuvée par Microsoft avec le SAN correspondant au FQDN de votre SBC. Si votre chaîne actuelle est affectée par le changement de certificat racine de juin 2026, effectuez la rotation avant la date limite.
3. Configurez un groupe de jonctions côté TeamsDéfinissez le transport sur TLS (port 5061), les médias sur SRTP, configurez les règles de manipulation des en-têtes SIP pour la compatibilité Teams et activez le masquage de topologie.
4. Configurez un groupe de jonctions côté opérateurConfigurez le transport et les médias pour correspondre à votre opérateur. Le SBC gère la traduction du chiffrement entre les deux groupes de jonctions.
5. Configurez le routage entre les groupes de jonctionsDéfinissez des règles pour diriger les appels entrants de Teams vers la jonction opérateur et les appels sortants de l’opérateur vers Teams, avec une logique de priorité et de basculement pour la résilience en production.
6. Testez avec SIP OPTIONS et un appel de testConfirmez que le SBC apparaît en ligne dans le Centre d’administration Teams, puis effectuez des appels de test dans les deux directions. Vérifiez l’audio de bout en bout et la bonne présentation de l’identifiant d’appelant.

Foire aux questions

Conclusion

Le routage direct Microsoft Teams (Direct Routing) offre aux organisations une flexibilité PSTN sans les forfaits d’appel Microsoft, sans le verrouillage d’Operator Connect et sans remplacer les relations opérateur existantes. Si vous évaluez comment connecter Teams au PSTN, le Direct Routing est la voie à suivre lorsque le choix de l’opérateur, le contrôle du routage ou la prestation de services multi-locataires sont des exigences. Le SBC est ce qui rend tout cela possible, gérant le TLS, le SRTP, la normalisation SIP, le masquage de topologie et la pulsation SIP OPTIONS qui confirme à Teams que l’infrastructure est active.
Lors de l’évaluation d’un SBC pour le Direct Routing, les facteurs clés sont l’architecture (B2BUA pour un contrôle total des en-têtes), le chiffrement par segment, la granularité des règles de manipulation SIP par jonction et la qualité des outils de débogage qui vous permettent de confirmer le comportement en conditions de production.