Devenir fournisseur Microsoft Teams Direct Routing : les exigences SBC

Chaque entreprise utilisant Microsoft Teams Phone finit par poser la même question : qui va assurer la connexion au réseau téléphonique, et à quel prix ? Pour les fournisseurs de services gérés (MSP), les FAI et les opérateurs, cette question représente une opportunité. Plutôt que de voir vos clients payer les tarifs Microsoft Calling Plans ou confier leur voix à un opérateur Operator Connect, vous pouvez fournir la connectivité PSTN vous-même avec vos propres numéros, vos propres tarifs et votre propre routage. C’est précisément ce que signifie devenir fournisseur Microsoft Teams Direct Routing.

Le modèle repose entièrement sur un élément d’infrastructure : un contrôleur de session en périphérie (SBC). Microsoft ne connecte pas Teams directement à un opérateur. Un SBC validé doit se placer à la frontière, terminant le trunk Teams d’un côté et votre trunk opérateur de l’autre. Teams refuse simplement de se connecter à un SBC qui ne satisfait pas ses exigences techniques en matière de chiffrement, de normalisation SIP et de signalisation de disponibilité. Ce guide porte sur ces exigences. Si vous comprenez déjà ce qu’est le Teams Direct Routing, l’étape suivante consiste à savoir exactement ce que le SBC doit faire pour offrir le Direct Routing en tant que service et comment le dimensionner pour de nombreux locataires clients. Le volet commercial (tarification, packaging et vente du service) est traité séparément dans le guide MSP du service géré.

Pourquoi offrir le Teams Direct Routing en tant que service ?

Microsoft offre aux entreprises trois façons de connecter Teams Phone au monde extérieur, et deux d’entre elles laissent de l’argent et du contrôle sur la table pour le client. Les Microsoft Calling Plans regroupent les minutes aux tarifs de Microsoft sans choix d’opérateur. Operator Connect limite les clients aux opérateurs inscrits au programme Microsoft. Le Direct Routing est la voie ouverte : n’importe quel opérateur, n’importe quels tarifs, un contrôle total du routage, le tout délivré via un SBC. Pour une comparaison détaillée des trois modèles, consultez Operator Connect versus Teams Direct Routing.

Cette voie ouverte est celle où le fournisseur s’insère. Si vous exploitez déjà des trunks SIP, des minutes en gros ou une activité de PBX hébergé, le Direct Routing vous permet d’ajouter la voix Teams à ce que vous vendez déjà. Sur le marché nord-américain, le Teams Direct Routing est la première raison pour laquelle un fournisseur de services gérés se met à chercher un SBC. Le client veut la téléphonie Teams, il ne veut pas gérer son propre SBC, et il préfère acheter la voix auprès d’un fournisseur de confiance plutôt qu’auprès de Microsoft.

Qui devient fournisseur Direct Routing

• Les fournisseurs de services gérés ajoutent la téléphonie Teams à une base existante de clients FreePBX, 3CX ou NetSapiens, livrant la voix à des dizaines ou des centaines de clients professionnels depuis une seule plateforme. Consultez comment les MSP évaluent un SBC pour le point de vue de l’acheteur.
• Les FAI et les opérateurs possèdent déjà les trunks SIP et la numérotation. Le Direct Routing leur permet de monter en gamme, passant de la connectivité de gros à un service Teams de détail.
• Les opérateurs de centres de contact et CPaaS utilisent le même SBC pour fournir des chemins Bring Your Own Carrier vers Teams en parallèle de leurs autres plateformes.

Trois façons de livrer le Direct Routing

Avant d’examiner le SBC lui-même, choisissez le modèle de livraison que vous construisez. Ce choix détermine la part de la plateforme que vous exploitez et ce que vos clients touchent.

Modèle	Qui exploite le SBC	Profil idéal	Multi-tenant
Direct Routing as a Service	Le fournisseur héberge	MSP servant de nombreux locataires PME	Requis
Hébergé par le client, géré par le fournisseur	Cloud du client, vous exploitez	Grands locataires avec exigences de conformité	Par déploiement
Auto-hébergé par l’entreprise	Le client l’exploite	Grande entreprise unique, équipe voix interne	Mono-locataire

La plupart des fournisseurs qui construisent un service reproductible optent pour le premier modèle, livrant le Direct Routing as a Service depuis un SBC partagé et multi-tenant. Il offre le coût par client le plus bas et l’intégration la plus rapide, car un nouveau locataire est un changement de configuration plutôt qu’un nouveau déploiement. Le modèle intermédiaire convient aux clients qui ont besoin du SBC dans leur propre compte cloud pour des raisons de résidence des données ou de conformité, tout en vous laissant l’exploitation au quotidien. Il s’agit d’un choix technique d’hébergement ; le compromis commercial entre exploiter le SBC vous-même et le revendre en service géré est analysé dans le guide MSP du service géré. Quel que soit le modèle choisi, les exigences SBC ci-dessous s’appliquent.

Ce que Microsoft exige d’un SBC Direct Routing

Microsoft publie un ensemble d’exigences techniques que chaque SBC Direct Routing doit satisfaire, et Teams refuse simplement de se connecter à un SBC qui ne les respecte pas. En tant que fournisseur, vous les remplissez une fois, correctement, puis réutilisez la même configuration pour chaque locataire que vous intégrez.

Un SBC validé et un FQDN enregistré

Microsoft maintient une liste de SBC validés pour le Direct Routing, et votre SBC doit figurer sur cette liste ou satisfaire l’interface Direct Routing attendue par Teams. Chaque SBC nécessite un Fully Qualified Domain Name publiquement résolvable, enregistré dans le Teams Admin Center, que Teams utilise pour le routage SIP et la validation du certificat TLS. Les adresses IP nues ne sont pas acceptées.

TLS pour la signalisation SIP

Toute la signalisation SIP entre Teams et votre SBC doit utiliser Transport Layer Security, avec un certificat émis par une autorité de certification approuvée par Microsoft dont le Subject Alternative Name correspond au FQDN du SBC. Puisque Teams et le SBC s’authentifient mutuellement, il s’agit en pratique d’une relation de confiance mutuelle, et la chaîne de certificats doit rester valide dans le temps. Microsoft met périodiquement à jour les racines CA qu’il approuve pour le Direct Routing, de sorte que le maintien du certificat fait partie intégrante de l’exploitation du service.

SRTP pour le chiffrement des médias

Teams n’accepte que des médias chiffrés, donc tout le RTP provenant du SBC doit être en Secure RTP. De nombreux opérateurs livrent encore du RTP non chiffré, ce qui signifie que votre SBC convertit de manière transparente entre les deux formats, gérant l’échange de clés sur chaque segment de manière indépendante afin que ni l’opérateur ni Teams n’ait besoin de changer quoi que ce soit.

Le heartbeat SIP OPTIONS

Teams envoie périodiquement des requêtes SIP OPTIONS pour confirmer que le SBC est actif, et le SBC doit répondre à chacune par un 200 OK. Une réponse manquée ou retardée amène Teams à marquer ce trunk comme hors ligne, et pour un fournisseur multi-tenant, une seule mauvaise configuration peut affecter le locataire qui le partage. Les réponses OPTIONS manquées sont la cause la plus fréquente derrière les tickets « le SBC apparaît hors ligne », un schéma couvert en détail dans le guide de dépannage Direct Routing.

Compatibilité des messages SIP

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

Ce qu’un SBC de niveau fournisseur exige au-delà du minimum

Satisfaire les exigences de Microsoft permet de connecter un seul locataire. Exploiter un service Direct Routing à travers de nombreux locataires exige davantage du SBC, et c’est là que le choix de plateforme sépare un service viable d’un fardeau de support.

Multi-tenancy et isolation par locataire

Un SBC fournisseur doit servir de nombreux clients depuis une seule instance tout en maintenant le routage, la numérotation et le trafic de chaque locataire logiquement séparés. Le mécanisme concret est la configuration par trunk group : chaque locataire dispose de son propre trunk group avec ses propres règles SIP et son propre routage, et un FQDN de base avec des sous-domaines par locataire permet à Teams de s’adresser à chacun. L’architecture sous-jacente est détaillée dans SBC multi-tenant pour Teams Direct Routing. Sans un multi-tenancy solide, chaque nouveau client devient un nouveau déploiement et le modèle économique ne fonctionne jamais.

Capacité en trunk groups et sessions

Vérifiez le plafond du SBC en sessions concurrentes, trunk groups et enregistrements de points de terminaison par rapport à votre plan de croissance, pas seulement votre nombre de clients actuel. Une plateforme capable de supporter environ un millier de trunk groups et des dizaines de milliers de sessions concurrentes par instance offre au fournisseur une véritable marge de manœuvre pour ajouter des locataires sans ré-architecturer.

Architecture B2BUA

Un Back-to-Back User Agent (B2BUA) termine intégralement la session SIP d’un côté et en réinitie une nouvelle de l’autre, donnant au SBC un contrôle total sur chaque message dans les deux sens. Un simple proxy SIP transmet les messages avec une capacité de modification limitée, ce qui devient une contrainte forte lorsqu’il faut supprimer des en-têtes propriétaires d’un opérateur avant qu’ils n’atteignent Teams ou ajuster les en-têtes d’identité par locataire. L’architecture B2BUA est ce qui permet la manipulation approfondie des en-têtes, le chiffrement indépendant par segment et le masquage de topologie. La différence est expliquée plus en détail dans qu’est-ce qu’un SBC.

Manipulation configurable des en-têtes SIP

Différents opérateurs et différents locataires nécessitent des traitements SIP différents. Un moteur de manipulation d’en-têtes basé sur des règles, configurable par trunk group, est donc essentiel. Plus le moteur est configurable, plus il est facile d’intégrer un opérateur avec une implémentation SIP inhabituelle ou un locataire avec des règles spécifiques de présentation de l’appelant, sans toucher à la configuration de qui que ce soit d’autre.

Sécurité en périphérie

Votre SBC fait face à Internet du côté opérateur, ce qui en fait une cible. La protection intégrée contre les DoS et DDoS, la protection contre le scan d’enregistrement SIP et le blocage dynamique de plages d’adresses IP ou de modèles de numéros sont des attentes de base pour une infrastructure vocale exposée sur Internet. Pour un fournisseur livrant le Direct Routing à des clients payants, l’évaluation de fraude par appel compte également, car la fraude téléphonique sur une plateforme partagée devient votre exposition de facturation sur l’ensemble des locataires.

Haute disponibilité

Lorsqu’une entreprise exploite son propre SBC, une panne affecte une seule société. Lorsqu’un fournisseur exploite un SBC partagé, une panne affecte tous les locataires. Cela fait passer la haute disponibilité du statut d’option à celui d’exigence de base. Recherchez une redondance active/standby, généralement exprimée en 1+1 HA, pour que la maintenance et les pannes ne mettent pas hors service toute votre base de clients.

Déploiement cloud et hybride

Teams Phone fonctionne dans Microsoft Azure, donc un SBC déployable nativement dans Azure maintient une latence faible vers l’infrastructure Teams. Pour les fournisseurs disposant de centres de données existants, ou les clients exigeant le SBC dans leur propre compte cloud, la disponibilité sur Azure et AWS ou sur VMware, KVM et baremetal vous permet de placer le SBC là où l’activité l’exige.

Exigences SBC fournisseur en un coup d’œil

Exigence	Nécessaire pour	Priorité fournisseur
SBC validé + FQDN enregistré	Que Teams accepte la connexion	Obligatoire
Signalisation TLS + certificat approuvé	Trunk Teams chiffré et authentifié	Obligatoire
SRTP avec conversion RTP vers SRTP	Relier les médias opérateur non chiffrés à Teams	Obligatoire
Multi-tenancy par locataire	Servir de nombreux clients depuis une seule instance	Critique pour le passage à l’échelle
Manipulation configurable des en-têtes SIP	Normaliser des opérateurs et locataires variés	Critique pour le passage à l’échelle
Sécurité en périphérie et évaluation de fraude	Protéger une plateforme partagée exposée sur Internet	Fortement recommandé
Haute disponibilité 1+1	Maintenir tous les locataires en ligne pendant les pannes	Fortement recommandé

Intégration d’un locataire : le parcours général

Une fois la plateforme opérationnelle, l’ajout d’un client suit une séquence reproductible. Les écrans exacts dépendent de votre SBC, mais la structure reste cohérente dans tout service Direct Routing bien construit.

1. Enregistrer le domaine du locataire dans le Teams Admin CenterAjoutez le FQDN ou le sous-domaine du SBC du client sous Voice, Direct Routing, afin que Teams sache où router les appels du locataire et quel certificat valider.
2. Confirmer que le certificat couvre le locataireVérifiez que votre certificat TLS, ou un certificat wildcard couvrant vos sous-domaines, est valide pour le FQDN du locataire et émis par une CA approuvée par Microsoft.
3. Créer le trunk group du locataire vers TeamsConfigurez le transport en TLS, le média en SRTP, appliquez vos règles de normalisation SIP compatibles Teams et activez le masquage de topologie, le tout limité à ce locataire.
4. Associer le locataire à un trunk opérateurDirigez le locataire vers le trunk opérateur qui acheminera son trafic PSTN, en utilisant soit un opérateur de gros partagé, soit un opérateur assigné à ce client.
5. Attribuer les numéros et configurer le routageProvisionnez les numéros du locataire et définissez le routage entrant et sortant entre le trunk Teams et le trunk opérateur, avec priorité et basculement pour la résilience.
6. Vérifier les OPTIONS et effectuer des appels de testConfirmez que le trunk du locataire apparaît comme sain dans le Teams Admin Center, puis testez les appels dans les deux sens et vérifiez la qualité audio et la présentation de l’identifiant de l’appelant avant la mise en production.

Le volet commercial : tarification et packaging

La structure de coûts du SBC détermine vos marges, et la licence basée sur les sessions convient bien à un modèle fournisseur, car votre coût évolue avec la capacité concurrente que vous utilisez réellement plutôt qu’un investissement matériel initial important. La manière dont vous tarifez et packagez ensuite la voix Teams pour vos propres clients (les modèles par siège, par canal ou par palier, les règles de sélection des comptes, et la responsabilité de l’attestation STIR/SHAKEN une fois que vous êtes l’opérateur d’origine) est une décision commerciale à part entière. Ce volet est traité de bout en bout dans comment offrir le Teams Direct Routing en service géré. Ce guide reste centré sur les exigences SBC qui rendent le service techniquement possible.

Questions fréquemment posées

Conclusion

Devenir fournisseur Microsoft Teams Direct Routing dépend moins de Teams que du SBC sur lequel vous construisez le service. Les exigences de Microsoft (un SBC validé avec un FQDN enregistré, la signalisation TLS, le média SRTP, le heartbeat OPTIONS et la compatibilité SIP) permettent de connecter un seul locataire. Transformer cela en activité commerciale exige un SBC véritablement multi-tenant, capable de monter en charge sur vos objectifs de trunk groups et de sessions, offrant un contrôle SIP configurable par locataire, protégeant une plateforme partagée en périphérie et restant disponible lorsque tous vos clients en dépendent.

Avec ces éléments en place, chaque nouveau client devient un changement de configuration plutôt qu’un projet, exactement le modèle économique dont un fournisseur a besoin. Que vous hébergiez le SBC vous-même ou le revendiez en service géré, la plateforme sous-jacente fait la différence entre une offre Direct Routing qui passe à l’échelle et une offre qui consume votre équipe de support.