Architecture du Direct Routing et rôle du SBC

Bonjour et bienvenue dans ce nouveau module dédié à l'intégration de Microsoft Teams Direct Routing. Dans le module précédent, nous avons assemblé une méthodologie complète pour gérer l'interopérabilité SIP en nous concentrant sur les numéros, les headers, les codecs et les DTMF. Vous disposez maintenant d'un cadre solide pour le dépannage.

Nous allons immédiatement mettre ces connaissances en pratique. Le Direct Routing est l'un des cas d'usage les plus courants pour un SBC AudioCodes aujourd'hui, et il exige une maîtrise parfaite de l'interopérabilité.

L'objectif de cette première leçon est de décrire l'architecture spécifique du Direct Routing et le rôle du SBC. Avant de configurer quoi que ce soit, il est essentiel de comprendre le "pourquoi" et le "comment" de cette solution. Nous allons décortiquer les composants impliqués, les flux de communication et le rôle central et indispensable que joue le SBC dans ce puzzle.

À la fin de cette leçon, vous aurez une vision claire de l'écosystème Direct Routing, ce qui est le prérequis pour aborder sereinement les leçons de configuration à venir.

Qu'est-ce que le Direct Routing ?

Microsoft Teams, en plus de ses fonctionnalités de collaboration, peut servir de système téléphonique complet (PBX). Pour permettre aux utilisateurs de passer et recevoir des appels vers le réseau téléphonique public commuté (RTC ou PSTN en anglais), Microsoft propose deux solutions :

1. Les Forfaits d'appels Microsoft (Calling Plans) : Microsoft agit comme votre opérateur téléphonique. Ils vous fournissent les numéros de téléphone et gèrent toute la connectivité. C'est une solution simple mais disponible uniquement dans certains pays et moins flexible.
2. Le Routage Direct (Direct Routing) : Vous apportez votre propre opérateur téléphonique (Bring Your Own Carrier). Cette option vous permet de connecter Teams au réseau téléphonique via un équipement que vous gérez : un Session Border Controller (SBC) certifié par Microsoft.

C'est cette deuxième option qui nous intéresse. Elle offre une flexibilité maximale, vous permettant de conserver vos contrats opérateurs existants, d'intégrer des équipements non-Microsoft (comme votre ancien PBX ou un centre de contact NICE) et de déployer une solution téléphonique mondiale.

L'Architecture Globale du Direct Routing

Maintenant que le concept est clair, examinons les pièces du puzzle. L'architecture du Direct Routing s'articule autour de trois pôles principaux : le Cloud Microsoft, votre réseau d'entreprise (ou celui de votre hébergeur), et le réseau de votre opérateur téléphonique.

Les composants clés sont :

• Microsoft 365 / Teams Phone System : Le "cerveau" dans le cloud qui gère les utilisateurs, les files d'attente, les serveurs vocaux et la logique d'appel.
• Le Session Border Controller (SBC) : C'est la pièce maîtresse, le point de démarcation et de contrôle. Il doit être certifié par Microsoft pour garantir une compatibilité parfaite. AudioCodes est l'un des principaux fournisseurs de SBC certifiés.
• La connexion Opérateur (SIP Trunk) : Le lien fourni par votre opérateur qui connecte le SBC au réseau téléphonique mondial.
• (Optionnel) Équipements tiers : Un PBX existant, un centre de contact (comme NICE), des téléphones analogiques, etc., qui peuvent également être connectés au SBC.

Le Rôle Central du SBC

Dans cette architecture, le SBC AudioCodes n'est pas un simple "traducteur". Il remplit plusieurs fonctions critiques, qui font écho à ce que nous avons vu dans les modules précédents.

1. Connectivité et Routage : Le SBC est le pont physique et logique. Il reçoit les appels de Teams et les route vers le bon opérateur (ou PBX), et vice-versa. C'est lui qui sait "parler" aux deux mondes.

2. Sécurité : C'est un rôle fondamental. Le SBC agit comme un pare-feu spécialisé pour la voix. Il protège votre infrastructure et le tenant Teams contre les attaques (déni de service, fraude, etc.). La communication entre le SBC et Microsoft 365 est obligatoirement chiffrée via TLS (Transport Layer Security), ce qui requiert l'installation de certificats de confiance.

3. Interopérabilité : C'est ici que vos compétences acquises prennent tout leur sens.

   • Traduction SIP : Microsoft a ses propres "dialectes" SIP. Le SBC s'assure que les messages SIP envoyés à l'opérateur sont parfaitement conformes à ce que ce dernier attend (manipulation des headers P-Asserted-Identity, Contact, From, etc.).
   • Transcodage Média : Les clients Teams utilisent des codecs modernes comme SILK ou Opus. Votre opérateur, lui, utilise probablement des codecs plus classiques comme le G.711 ou le G.729. Le SBC se charge de la conversion en temps réel de ces flux audio pour que tout le monde se comprenne. Sans cela, vous auriez des appels sans son.
   • Normalisation : Le SBC adapte les formats de numéros (par exemple, de national à international E.164 +33...) pour assurer un routage correct.

4. Intégration d'équipements existants : Comme vu dans le schéma, le SBC vous permet de faire cohabiter l'univers Teams avec des systèmes plus anciens (PBX, fax, interphones) durant une phase de migration ou pour des besoins spécifiques.

Les Flux de Signalisation et de Média

Pour bien dépanner, il faut comprendre ce qui transite et par où.

• Le flux de Signalisation (SIP) : C'est le dialogue qui établit, maintient et termine l'appel (INVITE, 200 OK, BYE). Il circule toujours entre le client Teams, le cloud Microsoft (via un composant appelé SIP Proxy), et le SBC. La signalisation passe toujours par le cloud Microsoft.

• Le flux Média (RTP/SRTP) : C'est le flux audio lui-même (la conversation). Son chemin est plus flexible :

  • Sans Media Bypass : Le flux audio monte depuis le client Teams vers un Media Processor dans le cloud Microsoft, qui le relaie ensuite vers le SBC. C'est le chemin par défaut.
  • Avec Media Bypass : Pour optimiser la qualité et réduire la latence, on peut configurer le SBC pour que le flux média s'établisse directement entre le client Teams et le SBC, sans passer par le cloud Microsoft.

Modèles de Déploiement

Enfin, il existe deux manières principales de déployer un SBC AudioCodes pour le Direct Routing.

1. Modèle Dédié (Enterprise) : Un SBC est déployé pour un seul client. Il peut être physique dans les locaux du client, ou virtuel dans un cloud public (comme Azure) ou privé. Ce modèle offre un contrôle et une flexibilité maximum. C'est celui que nous allons étudier dans ce cours.

2. Modèle Hébergé (Multi-tenant) : Un opérateur ou un partenaire déploie un gros SBC qu'il utilise pour fournir le service de Direct Routing à de multiples clients. C'est une approche "as a service" où le client final n'a pas à gérer le SBC.

Conclusion

Cette première leçon a posé les fondations de notre travail sur le Direct Routing. Vous devriez maintenant avoir une carte mentale claire de cette architecture.

Points clés à retenir :

• Le Direct Routing connecte Teams au réseau téléphonique via un SBC certifié, vous permettant de garder votre propre opérateur.
• Le SBC joue un rôle crucial de connectivité, de sécurité (via TLS et certificats), et surtout d'interopérabilité (traduction SIP et transcodage média).
• L'architecture implique des flux de signalisation (toujours via le cloud Microsoft) et des flux média (qui peuvent être optimisés avec le Media Bypass).
• Les prérequis d'infrastructure sont stricts : un SBC certifié, un nom de domaine public (FQDN), et un certificat public sont indispensables.

Aperçu de la prochaine leçon :
Maintenant que nous comprenons l'importance des certificats et de la communication sécurisée, notre prochaine étape pratique sera de configurer les interfaces TLS et les certificats requis pour la communication avec Teams. Nous commencerons à mettre les mains dans la configuration du SBC pour préparer la connexion au cloud Microsoft.