SBC multi-locataire pour Microsoft Teams Direct Routing : guide pour les MSP et fournisseurs de services

Tout commence généralement par un client qui demande la téléphonie Microsoft Teams. Puis trois autres suivent le mois suivant, et soudain, votre portefeuille est devenu majoritairement Teams. Si vous êtes un fournisseur de services gérés (MSP) ou un fournisseur de services qui installe encore un SBC distinct pour chaque client, les calculs ne tiennent plus. Entre les configurations dupliquées, les cycles de mise à jour par client et une pile croissante de groupes de jonctions que personne n’a le temps d’auditer, cela devient un emploi à temps plein.

Il existe un meilleur modèle. Un seul contrôleur de session en bordure (SBC) multi-locataire peut desservir chaque locataire Microsoft 365 de vos clients depuis un déploiement centralisé unique, avec une isolation complète entre les locataires et une gestion unifiée pour vous. Ce guide couvre le dossier commercial, l’architecture Microsoft qui rend cela possible, les fonctionnalités SBC dont vous avez besoin et les aspects économiques à l’échelle des MSP.

Pourquoi les MSP ont besoin d’une approche multi-locataire pour Teams Direct Routing

Teams Direct Routing est le principal déclencheur d’achat pour les MSP nord-américains qui évaluent un SBC. Le schéma est constant : l’équipe informatique d’un client décide de consolider sur Microsoft Teams pour la collaboration, puis demande à son MSP de connecter Teams à son système téléphonique existant ou à ses jonctions RTPC. Le MSP a besoin d’un SBC pour combler ce fossé.

Le modèle de déploiement par client fonctionne quand vous avez deux ou trois clients sur Teams. À 20 clients, il génère une charge opérationnelle réelle. Chaque déploiement nécessite ses propres certificats TLS, ses propres configurations de jonctions, ses propres politiques de sécurité et son propre calendrier de mises à jour. Quand votre administrateur SBC quitte l’entreprise, cette charge retombe sur son successeur, déclenchant souvent une conversation immédiate sur les services gérés.

Le modèle multi-locataire consolide tout cela dans une seule instance SBC. Vous gérez un seul déploiement avec une infrastructure partagée, mais le trafic de chaque client est entièrement isolé grâce à des groupes de jonctions distincts. Les politiques de sécurité, les règles de routage et les CDR restent par locataire. Vous mettez à jour un seul système, surveillez un seul tableau de bord et maintenez un seul jeu de certificats.

Pour les MSP, c’est aussi un modèle de revenus. Teams Direct Routing fourni en tant que service géré, avec l’infrastructure SBC centralisée sous votre contrôle, devient un poste récurrent mensuel plutôt qu’un projet ponctuel. (Pour une vue plus large de ce dont les MSP ont besoin d’un SBC au-delà de Teams DR, consultez notre guide SBC pour les MSP.)

Comment fonctionne l’architecture multi-locataire Direct Routing de Microsoft

Microsoft a conçu une architecture spécifique pour les opérateurs et fournisseurs de services afin de fournir Teams Direct Routing à travers plusieurs locataires Microsoft 365 depuis un SBC partagé. Comprendre cette architecture est un prérequis pour sélectionner et configurer votre SBC. (Pour une introduction plus large à Teams Direct Routing, incluant les déploiements à locataire unique, consultez notre guide SBC Microsoft Teams Direct Routing.)

Structure de domaine et sous-domaines

L’architecture utilise un domaine de base détenu par l’opérateur ou le MSP, avec un sous-domaine créé pour chaque locataire client. Par exemple, si votre MSP possède le domaine sbc.yourmsp.com, chaque locataire client obtient un sous-domaine : client1.sbc.yourmsp.com, client2.sbc.yourmsp.com, et ainsi de suite.

Le domaine de base est enregistré dans votre locataire opérateur (votre propre organisation Microsoft 365). Chaque sous-domaine est ensuite activé dans le locataire client correspondant. Cela permet à Microsoft d’associer les appels entrants et sortants au locataire correct tout en acheminant tout via votre SBC partagé.

Certificat TLS wildcard

Microsoft exige le chiffrement TLS pour toute la signalisation SIP sur les jonctions côté Teams. Pour un déploiement multi-locataire, votre SBC a besoin d’un certificat TLS wildcard correspondant au modèle de votre domaine de base, par exemple *.sbc.yourmsp.com. Ce certificat unique authentifie les connexions sur tous les sous-domaines des locataires, éliminant le besoin de certificats par client.

C’est une simplification opérationnelle significative. Au lieu de gérer des dizaines de certificats individuels avec des dates de renouvellement échelonnées, vous gérez un seul certificat wildcard.

Identification du locataire via les en-têtes SIP

Lorsqu’un appel arrive à l’interface Direct Routing de Microsoft 365, le système utilise le FQDN dans l’en-tête SIP Contact pour identifier à quel locataire appartient l’appel. Il ne recherche pas les locataires par numéro de téléphone, car les numéros non-DID peuvent se chevaucher entre les locataires. Le FQDN de l’en-tête Contact doit correspondre au sous-domaine correct pour chaque client.

Cela signifie que votre SBC doit être capable de manipuler les en-têtes SIP par groupe de jonctions, en insérant le FQDN de sous-domaine correct pour le trafic de chaque locataire. Un SBC avec une architecture B2BUA (Back-to-Back User Agent) gère cela nativement, car il termine et régénère la session SIP sur chaque segment avec un contrôle total sur le contenu des en-têtes.

Configuration des jonctions

Chaque locataire client nécessite une jonction configurée dans le centre d’administration Microsoft Teams, pointant vers le FQDN du sous-domaine (par exemple, client1.sbc.yourmsp.com). Sur votre SBC, chaque locataire correspond à un groupe de jonctions dédié avec ses propres règles de routage, politiques de sécurité et paramètres de codecs. Le SBC achemine les appels entre la jonction côté Teams (chiffrée, TLS/SRTP) et la jonction RTPC ou opérateur (qui peut utiliser un transport différent selon les exigences de votre opérateur).

Ce dont votre SBC a besoin pour prendre en charge Teams DR multi-locataire

Tous les SBC ne gèrent pas le Direct Routing multi-locataire Teams de la même façon. Voici les capacités techniques les plus importantes pour ce modèle de déploiement.

Capacité des groupes de jonctions et isolation des locataires

Chaque locataire dans votre déploiement multi-locataire nécessite au moins un groupe de jonctions dédié (souvent appelé NAP, ou Network Access Point). Si vous prévoyez de passer à 50, 100 ou 200 locataires clients, la limite de groupes de jonctions de votre SBC constitue un plafond absolu de croissance.

ProSBC prend en charge jusqu’à 1 024 NAP par serveur. À l’échelle des MSP, où la plupart des fournisseurs gèrent de 10 à 200 clients, cette capacité offre une marge considérable. Chaque NAP maintient ses propres politiques de sécurité, règles de routage et sortie CDR, de sorte que l’isolation des locataires est appliquée au niveau de la configuration, pas uniquement au niveau réseau.

TLS et SRTP pour chaque connexion de locataire

Microsoft Teams exige TLS pour la signalisation SIP et SRTP pour les flux média sur chaque connexion Direct Routing. Il n’y a aucune exception. Votre SBC doit prendre en charge TLS et SRTP côté Teams, et configurer indépendamment le transport côté opérateur.

Dans un déploiement multi-locataire typique, les jonctions côté Teams utilisent toutes TLS/SRTP, tandis que les jonctions côté opérateur peuvent utiliser UDP, TCP ou TLS selon les exigences de l’opérateur RTPC. Votre SBC peut convertir RTP en SRTP par jonction, comblant le fossé de chiffrement entre les deux segments.

ProSBC prend en charge SIP sur TLS et SRTP avec un transport configurable par NAP. Cela signifie que la jonction Teams de chaque locataire utilise TLS/SRTP, tandis que la jonction opérateur correspondante peut utiliser le transport requis par l’opérateur. Le SBC gère la conversion RTP vers SRTP entre les deux segments sans configuration supplémentaire par locataire.

Manipulation des en-têtes SIP pour le routage des locataires

L’architecture multi-locataire de Microsoft dépend du contenu précis des en-têtes SIP, en particulier le FQDN de l’en-tête Contact, pour acheminer les appels vers le locataire correct. Votre SBC a besoin d’un moteur de manipulation des en-têtes SIP capable de réécrire les en-têtes par groupe de jonctions.

L’architecture B2BUA de ProSBC vous donne un contrôle total sur la signalisation SIP sur les deux segments de l’appel. Puisque le SBC termine la session SIP entrante et en génère une nouvelle sur le segment sortant, chaque en-tête peut être inspecté, modifié ou remplacé. Ce n’est pas un proxy SIP léger qui transmet les en-têtes tels quels. Le modèle B2BUA vous permet de normaliser le trafic SIP depuis n’importe quel format d’opérateur vers le format exact attendu par Microsoft, par locataire, sans interférence entre locataires.

Cette capacité répond également aux environnements multi-opérateurs. Si différents clients utilisent différents opérateurs RTPC avec différentes conventions d’en-têtes SIP, le SBC normalise le tout vers un format cohérent côté Teams.

Haute disponibilité pour l’infrastructure partagée

Lorsqu’un seul SBC dessert tous vos clients, une panne affecte l’ensemble de votre base clients simultanément. La haute disponibilité (HA) n’est pas optionnelle pour les déploiements multi-locataires.

ProSBC offre la HA 1+1 avec redondance actif/veille, assurant une disponibilité maximale et un temps d’arrêt minimal. Cette option est disponible même pour les petits déploiements : une configuration HA de 500 sessions (ProSBC+) coûte $2,000 par an. Pour les MSP qui construisent un service Teams DR générateur de revenus, l’investissement HA est faible par rapport aux revenus qu’il protège.

Sécurité en bordure de réseau

Un SBC multi-locataire est une frontière de sécurité partagée. Il doit protéger chaque locataire contre :

• Attaques DoS/DDoS : ProSBC inclut une atténuation intégrée des attaques par déni de service et déni de service distribué, empêchant les attaques par inondation SIP de perturber le service pour tous les locataires.
• Balayage d’enregistrement SIP : Détection et blocage des attaques par inondation d’enregistrement qui tentent de sonder votre SBC à la recherche d’identifiants valides.
• Liste noire dynamique : Blocage de plages IP spécifiques ou de numéros appelants/appelés, incluant un greylisting basé sur un pourcentage pour le trafic suspecté de fraude.
• Masquage de topologie : Dissimule les adresses IP de votre réseau interne aux parties externes. Dans un modèle multi-locataire, cela empêche également l’opérateur d’un locataire de découvrir la topologie réseau d’un autre locataire.

Ces protections s’appliquent globalement et par NAP, vous permettant d’appliquer des politiques de sécurité de base à tous les locataires tout en personnalisant les règles pour des clients spécifiques. (Pour un examen plus approfondi des capacités de sécurité SBC, consultez notre guide sur la sécurité VoIP et la prévention de la fraude.)

Conformité STIR/SHAKEN pour tous les locataires

Si vous fournissez des services d’appel RTPC à plusieurs clients aux États-Unis, la conformité STIR/SHAKEN n’est pas optionnelle. La FCC exige des fournisseurs de services d’origine qu’ils signent les appels sortants avec une attestation d’identité de l’appelant. Pour un MSP exploitant un SBC multi-locataire, cela signifie que votre SBC centralisé doit gérer la signature STIR/SHAKEN pour le trafic d’appels sortants de chaque locataire.

ProSBC s’intègre aux services de signature STIR/SHAKEN externes (tels que TransNexus ClearIP ou Neustar) via son moteur de routage configurable. Le SBC envoie les demandes de signature à votre service de signature choisi, reçoit l’en-tête Identity signé et l’insère dans le SIP INVITE sortant. Cette intégration prend en charge les niveaux d’attestation A (complet), B (partiel) et C (passerelle), le niveau étant déterminé par votre relation avec l’appelant pour chaque locataire.

L’avantage clé pour les MSP est la flexibilité. Le modèle d’intégration ouvert de ProSBC fonctionne avec tout service de signature tiers. Certains SBC concurrents utilisent des implémentations STIR/SHAKEN propriétaires qui vous lient à un partenaire de signature choisi par le vendeur. Avec ProSBC, vous sélectionnez le service de signature qui convient à votre entreprise, et vous pouvez utiliser différents services pour différents locataires si nécessaire.

Pour la redondance, ProSBC prend en charge des URL de service de signature primaire et secondaire. Si le service primaire est indisponible après les tentatives de reconnexion, le SBC ajoute un en-tête P-Identity-Bypass et complète l’appel plutôt que de le rejeter. Ce mécanisme de repli empêche les pannes du service de signature de bloquer tous les appels sortants de vos locataires.

Les aspects économiques de la fourniture Teams DR multi-locataire

L’argument financier pour un déploiement SBC multi-locataire repose sur la consolidation : un seul déploiement coûte moins cher que plusieurs, et la tarification par session évolue linéairement avec votre base clients.

Tarification par session à l’échelle des MSP

ProSBC utilise un modèle d’abonnement annuel par session à partir de seulement $1.40 par session par an. Le module complémentaire Teams Direct Routing est à partir de seulement $1.40 par session par an. C’est un modèle OPEX, pas une dépense d’investissement en appliances matérielles.

Voici un exemple concret pour un MSP avec 50 clients et 500 sessions simultanées au total :

Cela représente $5,375 par an pour un SBC multi-locataire de classe opérateur, protégé par la HA, desservant 50 locataires clients avec Teams Direct Routing. Pour mettre en perspective, un déploiement Oracle Acme Packet unique à un nombre de sessions comparable coûterait environ $50,000 par an au tarif Oracle d’environ $100 par session.

L’option de service géré

Si votre équipe n’a pas la capacité de gérer l’infrastructure SBC, TelcoBridges propose un service entièrement géré. Celui-ci inclut ProSBC+ avec HA 1+1, support 24/7, installation, intégration, tests et surveillance continue. Vous choisissez l’hébergement : TelcoBridges peut héberger le SBC pour vous, ou le déployer sur votre propre infrastructure (AWS, Azure, VMware ou KVM). Vous conservez un accès complet dans les deux cas.

Opportunité de revenus

Le modèle multi-locataire transforme Teams Direct Routing en un poste de service géré. Vos clients vous paient mensuellement pour la téléphonie Teams, vous la fournissez depuis votre SBC centralisé, et la marge entre ce que vous facturez et ce que l’infrastructure SBC vous coûte constitue un revenu récurrent.

Avec les aspects économiques par session de ProSBC, même une tarification modeste par utilisateur à vos clients génère des marges saines. Un client payant $3 à $5 par utilisateur par mois pour la téléphonie Teams gérée ne vous coûte qu’une fraction de ce montant en licence SBC.

Gestion de plusieurs opérateurs à travers les locataires

En pratique, votre déploiement multi-locataire ne se connectera pas à un seul opérateur RTPC. Différents clients apportent leurs propres relations opérateur, ou vous en tant que MSP maintenez des accords de jonction avec plusieurs opérateurs pour la couverture géographique, l’optimisation des coûts ou la redondance. Le SBC doit gérer cela sans prolifération de configurations.

Chaque NAP sur ProSBC peut se connecter à un opérateur différent avec son propre profil SIP, ses préférences de transport et ses exigences de codecs. Le moteur de routage configurable du SBC prend en charge le routage basé sur des règles avec priorité, vous permettant de définir des tables de routage par locataire qui sélectionnent les opérateurs selon les modèles de numéros appelés, l’heure de la journée, le coût ou les métriques de qualité. Si une route d’opérateur principale échoue, le SBC bascule automatiquement sur les routes secondaires.

Pour les MSP gérant des clients dans différentes régions ou pays, cette flexibilité de routage par locataire est essentielle. Un client au Texas peut être acheminé via un opérateur régional avec des tarifs locaux compétitifs, tandis qu’un client à New York utilise un opérateur national avec de meilleurs tarifs longue distance. Le SBC applique les règles de routage de chaque client indépendamment, sans interférence de routage entre locataires.

ProSBC génère également des CDR par NAP, vous fournissant des données de facturation séparées par locataire. C’est essentiel pour les MSP qui facturent les clients à l’utilisation : vous pouvez extraire les volumes d’appels, les durées et les destinations par client directement depuis le SBC sans corrélation manuelle.

Options de déploiement pour Teams DR multi-locataire

ProSBC fonctionne sur l’infrastructure que vous avez déjà. Les déploiements Teams DR multi-locataires sont pris en charge sur :

• AWS : La plateforme de déploiement la plus populaire et éprouvée pour ProSBC. Cloud natif, aucun matériel à acquérir.
• Microsoft Azure : Choix logique si votre pratique MSP est déjà alignée sur Azure. L’infrastructure vocale reste dans le même cloud que Teams.
• VMware ou KVM/Proxmox : Pour les MSP exploitant leur propre infrastructure de virtualisation sur site ou en colocation.
• Serveurs baremetal : Pour les environnements nécessitant du matériel dédié.

Toutes les options de déploiement prennent en charge la même architecture multi-locataire, la même configuration NAP et les mêmes capacités HA. Le logiciel SBC est identique quel que soit l’endroit où il s’exécute.

Pour les MSP dont les clients sont dans des secteurs réglementés ou des régions avec des exigences de résidence des données, tous les déploiements peuvent être hébergés sur l’infrastructure propre du client pour la conformité GDPR et la protection des données.

Surveillance d’un déploiement multi-locataire

La surveillance centralisée devient de plus en plus importante à mesure que vous ajoutez des locataires. Un seul SBC multi-locataire transportant le trafic de tous vos clients nécessite une visibilité proactive sur la qualité des appels, la santé des jonctions et les événements de sécurité pour chaque locataire simultanément.

ProSBC fournit un accès API RESTful pour la gestion à distance de l’état et de la configuration, la prise en charge SNMP pour l’intégration avec les plateformes de surveillance réseau existantes, et le scoring MOS (Mean Opinion Score) pour l’évaluation de la qualité des appels en temps réel. La capture Wireshark en direct et les fonctionnalités de traçage d’appels vous permettent de résoudre les problèmes d’appels par locataire sans perturber le trafic des autres locataires.

Pour les MSP qui souhaitent la surveillance sans la charge opérationnelle, TelcoBridges propose Monitoring as a Service (MaaS) en tant que produit autonome. MaaS assure une surveillance continue de votre déploiement ProSBC, mais c’est uniquement un produit de surveillance, pas un déploiement géré. Si vous souhaitez une gestion opérationnelle complète (déploiement, mises à jour, dépannage et support), le forfait Service géré inclut MaaS dans l’offre.

Premiers pas : du laboratoire à la production

ProSBC offre un parcours de zéro à la production qui ne nécessite ni appel commercial, ni bon de commande, ni expédition de matériel.

1. Déployer le laboratoire ProSBCLe laboratoire ProSBC est une licence gratuite et permanente de 3 sessions disponible en téléchargement immédiat. L’installation prend environ 20 minutes, et le laboratoire inclut la fonctionnalité Teams Direct Routing. C’est votre environnement de test pour valider la configuration multi-locataire avant d’engager un budget.
2. Configurer votre domaine de base et votre certificat wildcardEnregistrez votre domaine de base (par exemple, sbc.yourmsp.com) et obtenez un certificat TLS wildcard auprès d’une autorité de certification de confiance. Configurez le certificat sur votre instance laboratoire ProSBC.
3. Configurer les NAP pour les locataires de testCréez des NAP distincts pour deux ou trois locataires de test. Configurez chaque NAP avec son FQDN de sous-domaine, sa jonction TLS/SRTP côté Teams et sa jonction côté opérateur.
4. Valider le flux d’appelsConfirmez que les vérifications de santé SIP OPTIONS passent pour chaque locataire, effectuez des appels test dans les deux sens et vérifiez que les CDR sont générés par locataire.
5. Passer en productionQuand le laboratoire a validé votre architecture, passez à l’essai gratuit de 30 jours avec 500 sessions simultanées. Cela vous donne une capacité à l’échelle commerciale pour intégrer vos premiers clients en production.
6. Évaluer le service géréSi la charge opérationnelle de gestion du SBC n’est pas là où vous souhaitez investir le temps de votre équipe, contactez TelcoBridges au sujet de l’option de service géré. Le service géré couvre le déploiement, la surveillance, les mises à jour et le support 24/7, permettant à votre équipe de se concentrer sur les relations clients plutôt que sur la maintenance du SBC.

Questions fréquemment posées

Prochaines étapes

Un SBC multi-locataire pour Teams Direct Routing est l’infrastructure qui transforme la demande client pour la téléphonie Teams en un service géré évolutif et rentable. La combinaison de la tarification par session, de la haute capacité en NAP pour l’isolation des locataires et de l’option de déléguer les opérations à un service géré rend ce modèle viable pour les MSP de toute taille.

Commencez avec le laboratoire ProSBC pour valider votre configuration Teams DR multi-locataire en moins d’une heure. Quand vous êtes prêt à passer à l’échelle, l’essai gratuit de 30 jours vous donne 500 sessions pour intégrer vos premiers clients en production.