Bonjour,
Dans notre leçon précédente, vous avez appris à construire un trunk SIP vers un opérateur ITSP en assemblant méthodiquement plusieurs briques de configuration (Coder Groups, IP Profiles, Proxy Sets, IP Groups). Cette approche modulaire est fondamentale pour maîtriser le SBC AudioCodes.
Aujourd'hui, nous allons appliquer cette même méthodologie pour un des cas d'usage les plus courants et les plus stricts en communications unifiées : l'interconnexion avec Microsoft Teams via Direct Routing. L'objectif est de configurer le SBC pour qu'il serve de passerelle entre votre téléphonie existante (PSTN/PBX) et l'écosystème Teams.
Bien que la logique de construction du trunk reste la même, l'intégration avec Teams introduit des exigences spécifiques et non négociables, notamment en matière de sécurité. Si la configuration d'un trunk ITSP peut parfois être flexible (UDP/TCP, RTP), la connexion à Teams impose l'utilisation de TLS pour la signalisation SIP et de SRTP pour le média. L'authentification ne se fait pas par login/mot de passe, mais par des certificats et un FQDN public. Votre expérience en gestion de projets de communications unifiées vous a sans doute déjà confronté à ces impératifs de sécurité et de conformité dans les environnements cloud.
Nous nous concentrerons sur la configuration du SBC AudioCodes, mais nous évoquerons les prérequis côté Microsoft 365 pour vous donner une vue d'ensemble du projet.
1. Architecture et Prérequis
Avant de configurer, il est essentiel de comprendre l'architecture. Le SBC agit comme une "frontière" sécurisée et un point de médiation entre le réseau public (Internet, où se trouve Microsoft Teams) et vos réseaux internes (LAN, PBX) ou votre connexion opérateur (PSTN).
Le déploiement d'un SBC pour Teams, qu'il soit physique ou virtuel, est une pratique si courante que les solutions AudioCodes sont directement disponibles sur la marketplace Azure.
Pour que cette architecture fonctionne, Microsoft impose des prérequis stricts avant même de toucher au SBC :
- Un nom de domaine public enregistré dans votre tenant Microsoft 365 (vous ne pouvez pas utiliser le domaine par défaut
*.onmicrosoft.com). - Un FQDN (Full Qualified Domain Name) public pour votre SBC, qui appartient à ce domaine (par exemple,
sbc.votreentreprise.com). - Une adresse IP publique pointant vers l'interface WAN de votre SBC.
- Un certificat SSL public émis par une autorité de certification approuvée par Microsoft (ex: DigiCert, GoDaddy), dont le
Common Name(CN) ou unSubject Alternative Name(SAN) correspond exactement au FQDN du SBC.
Ces éléments sont la fondation de la confiance et de la sécurité entre votre SBC et la plateforme Microsoft.
2. La Fondation de la Sécurité : Configuration TLS
La différence majeure avec un trunk ITSP standard est l'obligation d'utiliser TLS. Cela implique une gestion rigoureuse des certificats sur le SBC.
[PDF] Connecting AudioCodes' SBC to Microsoft Teams Direct Routing
Ce guide officiel d'AudioCodes est la référence pour la configuration du Direct Routing. Nous allons nous concentrer sur la section qui établit la connexion sécurisée.
Veuillez lire la section 4.3, intitulée "SIP TLS Connection Configuration". Elle détaille les étapes cruciales : Configuration du serveur NTP : Essentielle pour que les certificats puissent être validés (ils ont des dates d'expiration). Création d'un TLS Context : C'est un conteneur qui regroupera tous les paramètres de sécurité TLS pour Teams. Génération d'une requête de signature de certificat (CSR) : Notez bien que le Common Name [CN] et le Subject Alternative Name [SAN] doivent correspondre au FQDN public de votre SBC. Déploiement des certificats : Vous installerez d'abord votre propre certificat signé. Déploiement du certificat racine de confiance : C'est une étape critique souvent manquée. Le SBC doit faire confiance à l'autorité qui a signé le certificat de Microsoft. Pour cela, vous devez importer le certificat racine public de l'autorité de certification de Microsoft (actuellement DigiCert) dans le "Trusted Root Certificates store" de votre TLS Context.
La vidéo ci-dessous montre comment importer ce certificat racine (ici, le Baltimore CyberTrust Root, qui était le prédécesseur de DigiCert pour Microsoft), une étape indispensable pour établir la connexion TLS.
Configuring Audiocodes SBC for Microsoft Teams Direct Routing
Cette vidéo montre la configuration pratique. La séquence suivante illustre le téléchargement et l'importation du certificat racine de confiance sur le SBC.
Regardez la partie où l'ingénieur installe le certificat Baltimore. La procédure est identique pour le certificat DigiCert actuellement requis. Vous le trouverez, le téléchargez en format PEM, puis l'importez via l'interface du SBC dans la section TLS Contexts > Trusted Root Certificates.
3. Construction du Trunk Microsoft Teams
Maintenant que la base de sécurité est en place, nous reprenons notre processus de construction modulaire, en adaptant chaque brique aux spécificités de Teams.
Étape 1 : SIP Interface
Nous devons définir un "point d'écoute" pour les communications SIP venant de Teams.
Microsoft Teams Direct Routing with CUCM using Audiocodes SBC
Cette vidéo offre un excellent pas-à-pas de la configuration.
Regardez la création de l'interface SIP pour Teams. Notez les points clés : Elle est associée à l'interface réseau WAN. Le port UDP est à 0 (inutilisé). Le port TLS est 5061, le port standard pour Direct Routing. Le TLS Context créé précédemment est associé ici. L'option TLS Mutual Authentication est activée.
Étape 2 : Media Realm
Comme pour tout trunk, nous dédions un realm pour les flux média.
Microsoft Teams Direct Routing with CUCM using Audiocodes SBC
Continuons avec la même vidéo.
Observez la configuration du Media Realm pour Teams. Il est simplement associé à l'interface réseau WAN et on lui alloue une plage de ports UDP pour les flux SRTP.
Étape 3 : Proxy Set
Ici, nous indiquons au SBC les adresses des serveurs SIP de Microsoft.
Microsoft Teams Direct Routing with CUCM using Audiocodes SBC
La vidéo explique maintenant comment définir les destinations Microsoft.
Suivez la configuration du Proxy Set pour Teams. Les points importants sont : Il est associé à l'interface SIP Teams créée juste avant. Les trois FQDN fournis par Microsoft sont ajoutés comme Proxy Addresses : sip.pstnhub.microsoft.com:5061 sip2.pstnhub.microsoft.com:5061 sip3.pstnhub.microsoft.com:5061 Le type de transport pour chacun est obligatoirement TLS. L'utilisation de trois adresses assure la haute disponibilité.
Étape 4 : Coder Group & IP Profile
Nous définissons maintenant comment communiquer (codecs, comportement SIP).
Microsoft Teams Direct Routing with CUCM using Audiocodes SBC
La vidéo montre la création d'un profil de comportement spécifique à Teams.
Regardez la création de l'IP Profile pour Teams. C'est une étape dense, mais retenez les paramètres critiques : SBC Media Security Mode est mis sur Secured. C'est ce qui active le SRTP. Le Coders Group est configuré pour inclure les codecs supportés par Teams (SILK, G.711, etc.). D'autres paramètres SIP comme SIP UPDATE Support, Remote re-INVITE Support et ICE Mode sont ajustés selon les préconisations de Microsoft pour garantir l'interopérabilité.
Étape 5 : IP Group (Assemblage final)
Nous lions toutes les pièces ensemble dans l'IP Group qui représentera Microsoft Teams.
Microsoft Teams Direct Routing with CUCM using Audiocodes SBC
C'est l'étape finale de l'assemblage.
Observez l'édition de l'IP Group pour Teams. On y associe : Le Proxy Set Teams. L'IP Profile Teams. Le Media Realm Teams. De plus, deux paramètres spécifiques à Teams sont configurés : Local Host Name : Doit être renseigné avec le FQDN public du SBC. Teams Direct Routing Mode : Doit être mis sur Enable. Ceci instruit le SBC d'ajouter l'en-tête propriétaire X-MS-SBC que Microsoft utilise pour identifier l'équipement.
4. Routage, Classification et Vérification
Une fois le trunk "construit", il faut l'activer.
- Classification : Vous devez créer une règle de classification pour que le SBC identifie correctement le trafic entrant depuis les adresses IP de Microsoft comme appartenant à l'IP Group "Teams". Cette règle se base généralement sur l'interface SIP de réception et l'adresse IP source.
- Routage IP-to-IP : Comme dans la leçon précédente, vous créerez des règles pour acheminer les appels. Par exemple, une règle "de l'IP Group
PBX_Internevers l'IP GroupTeams" et une autre en sens inverse.
Enfin, comment vérifier que la connexion est établie ? Microsoft envoie en permanence des messages SIP OPTIONS à votre SBC sur le port 5061 pour vérifier sa disponibilité.
[PDF] Connecting AudioCodes' SBC to Microsoft Teams Direct Routing
Le guide de configuration explique comment valider le "pairing".
Lisez la section 5, "Verifying the Pairing". La méthode consiste à aller dans Monitor > VoIP Status > Proxy Set Status et à vérifier que le statut du Proxy Set de Teams est bien Online.
Si le statut reste Offline, le problème vient souvent d'un souci réseau externe au SBC. Une cause très fréquente est une règle de pare-feu ou de NAT manquante.
Configuring Audiocodes SBC for Microsoft Teams Direct Routing
Cette vidéo illustre parfaitement un problème de connectivité courant et sa résolution.
Regardez ce passage où l'ingénieur diagnostique un statut inactif. Il identifie que le port 5061 n'est pas redirigé (port forwarding) sur son routeur. Sans cette règle, les messages OPTIONS de Microsoft n'atteignent jamais le SBC. C'est une vérification essentielle dans tout projet de ce type.
Conclusion
La configuration d'un trunk pour Microsoft Teams Direct Routing, bien que plus exigeante, suit la même logique modulaire que pour un ITSP. La rigueur est simplement de mise à chaque étape, surtout sur les aspects sécurité.
Les points clés à retenir sont :
- Sécurité non négociable : La connexion repose sur TLS (via certificats) et SRTP (
SBC Media Security Mode = Secured). - Fondation par certificats : Le bon déploiement du certificat du SBC et des certificats racines de confiance de Microsoft est la première étape critique.
- Paramètres spécifiques à Teams : Des configurations précises dans l'IP Profile (gestion des re-INVITE, REFER...) et l'IP Group (
Local Host Name,Teams Direct Routing Mode) sont obligatoires pour l'interopérabilité. - Vérification systématique : Le statut
Onlinedu Proxy Set est le premier indicateur d'une configuration de base réussie. Les problèmes sont souvent liés au réseau (Firewall, NAT).
Dans notre prochaine leçon, nous aborderons la configuration d'un trunk SIP pour l'interconnexion avec un PBX IP de type Oracle. Cela vous permettra de comparer les exigences de différents environnements et de solidifier votre compréhension de l'approche modulaire d'AudioCodes.