Planifier le routage direct

Le routage direct permet aux organisations de connecter leur propre infrastructure téléphonique à la téléphonie Microsoft Teams à l’aide d’un contrôleur de frontière de session (SBC) pris en charge par le client. Cela permet aux organisations d’utiliser des opérateurs RTC existants, d’intégrer des systèmes de téléphonie tiers et de conserver un meilleur contrôle sur leur infrastructure vocale.

La planification de votre déploiement de routage direct est essentielle à la réussite de la mise en œuvre. Cet article fournit des conseils de planification concernant l’infrastructure, les licences, la mise en réseau, le contrôleur de frontière de session (SBC) et les exigences de connectivité avant de commencer le déploiement.

Pour obtenir des instructions de configuration, consultez Configurer le routage direct.

Pourquoi choisir le routage direct ?

Le routage direct est un bon choix pour les organisations qui :

• Avoir une relation d’opérateur RTCP existante.
• Nécessitent l’intégration avec des PBX tiers ou des périphériques analogiques.
• Besoin de fonctionnalités de routage vocal avancées.
• Veulent mieux contrôler leur infrastructure téléphonique.
• Prenez en charge les déploiements vocaux complexes ou multinationaux.

Les organisations peuvent également déployer le routage direct avec les forfaits d’appels Microsoft, Operator Connect et Teams Phone Mobile au sein du même locataire Microsoft Teams.

Vue d’ensemble du déploiement

La planification d’un déploiement de routage direct comprend généralement les étapes suivantes.

Architecture de routage direct

Le diagramme suivant montre comment le routage direct connecte la téléphonie Microsoft Teams à votre infrastructure téléphonique existante.

                Microsoft Teams

               +-------------+
               | Teams Phone |
               +------+------+
                      |
               Direct Routing
                      |
             +--------+--------+
             |  Certified SBC  |
             +--------+--------+
                      |
             +--------+----------------+
             |                         |
 +-----------+-----------+     +-------+--------+
 | Existing PSTN Carrier |     |  Existing PBX  |
 +-----------+-----------+     | Analog Devices |
                               |   SIP Trunks   |
                               +-------+--------+

Conditions d’infrastructure requises

L’infrastructure suivante est nécessaire pour déployer le routage direct.

Conditions d’octroi de licence

Les utilisateurs de routage direct ont besoin de :

• Microsoft Teams
• Téléphone Teams

Une licence supplémentaire peut être nécessaire en fonction de votre déploiement.

Pour les scénarios d’audioconférence, voir Routage direct avec audioconférence.

Pour plus d’informations sur les licences, consultez :

• Licences Microsoft Teams
• Licences de module complémentaire Microsoft Teams

Routage direct avec audioconférence

Lorsque les utilisateurs participent à des réunions planifiées, les numéros de connexion sont fournis par le biais de l’audioconférence Microsoft.

Si une licence d’audioconférence n’est pas attribuée à un utilisateur, les appels de conférence sortants sont acheminés via le routage direct.

Pour les environnements GCC High et DoD, Microsoft recommande d’effectuer le déploiement de routage direct avant d’attribuer les licences d’audioconférence.

Pour obtenir des conseils supplémentaires, consultez Audioconférence avec routage direct pour GCC High et DoD.

Escalade d’appels non planifiés et licence d’audioconférence

Un utilisateur Teams peut démarrer un appel Teams à RTC ou Teams à Teams et y ajouter un participant RTC. Le chemin d’accès emprunté par l’appel varie selon que l’utilisateur qui fait remonter l’appel dispose d’une licence de conférence audio Microsoft attribuée ou non :

• Si une licence de conférence audio Microsoft est attribuée à l’utilisateur Teams qui fait remonter l’appel, la réaffectation se produit par le biais du service d’audioconférence Microsoft. Le participant RTC distant invité à l’appel existant reçoit une notification sur l’appel entrant et voit le numéro du pont Microsoft attribué à l’utilisateur Teams qui a initié la réaffectation.

• Si la licence de conférence audio Microsoft n’est pas attribuée à l’utilisateur Teams qui transfère l’appel, l’escalade se produit via un contrôleur de frontière de session connecté à l’interface de routage direct. Le participant RTC distant invité à l’appel reçoit une notification sur l’appel entrant et voit le numéro de l’utilisateur Teams à l’origine de la réaffectation. Le SBC spécifique utilisé pour la réaffectation est défini par la stratégie de routage de l’utilisateur.

Vous devez vous assurer des points suivants :

• CsOnlineVoiceRoutingPolicy est attribuée à l’utilisateur.

• L’option Autoriser les appels privés est activée au niveau du locataire pour Microsoft Teams.

Routage direct avec les forfaits d’appels et Operator Connect

Le routage direct prend également en charge les utilisateurs disposant d’une licence pour les forfaits d’appels Microsoft ou d’un numéro de téléphone Operator Connect. Les utilisateurs de Teams Phone disposant d’un forfait d’appels ou d’Operator Connect peuvent acheminer certains appels via le routage direct.

Le mélange de forfaits d’appels ou de connexion d’opérateur et de connectivité directe pour un même utilisateur est facultatif, mais peut être utile. Par exemple, lorsque l’utilisateur reçoit un forfait d’appels Microsoft ou un numéro Operator Connect mais souhaite acheminer certains appels en interne à l’aide du SBC.

Le routage des appels suit un ordre d’évaluation défini. Teams évalue d’abord les itinéraires vocaux de routage direct associés à la stratégie de routage vocal en ligne de l’utilisateur. Lorsqu’aucun itinéraire de routage direct applicable ne correspond au numéro appelé, Teams vérifie si l’utilisateur dispose d’un forfait d’appels ou d’une connexion d’opérateur disponible et tente de terminer l’appel à l’aide de cette connectivité.

Voici un modèle de déploiement courant :

• Forfaits d’appels Microsoft ou Operator Connect pour les appels RTC.
• Routage direct pour les appels vers des PBX tiers.
• Routage direct pour les périphériques analogiques.
• Routage direct pour les scénarios de routage spécialisés.

Ce déploiement hybride permet aux organisations d’optimiser le routage des appels tout en conservant les investissements existants en matière de téléphonie.

Pour plus d’informations sur les licences Teams Phone, consultez Licences des modules complémentaires Microsoft Teams.

Points de terminaison pris en charge

Le routage direct prend en charge :

• Clients mobiles et de bureau Microsoft Teams
• Téléphones certifiés Teams
• Téléphones de zone commune

Pour les téléphones de zone commune, une licence de forfaits d’appels n’est pas nécessaire lorsque le routage direct est utilisé. Pour plus d’informations, voir Configurer des téléphones de zone commune pour Microsoft Teams.

Noms de domaine SBC

Le nom de domaine complet SBC doit appartenir à un domaine vérifié au sein de votre client Microsoft 365.

Vous ne pouvez pas utiliser le domaine *.onmicrosoft.com par défaut.

Par exemple :

Si vous créez un sous-domaine, vous devez d’abord enregistrer ce domaine dans Microsoft 365 avant de coupler le SBC. Par exemple, si contoso.com est inscrit dans votre client et que vous souhaitez utiliser sbc1.sip.contoso.com , commencez par inscrire sip.contoso.com .

Avant de pouvoir coupler un SBC avec le nom sbc1.sip.contoso.com, vous devez enregistrer le nom de domaine sip.contoso.com dans Domaines de votre client. Si vous essayez de coupler un SBC avec sbc1.sip.contoso.com avant d’enregistrer le nom de domaine, vous obtiendrez l’erreur suivante : Can't use the "sbc1.sip.contoso.com" domain as it wasn't configured for this tenant.

Après avoir ajouté le nom de domaine, vous devez créer un utilisateur avec UPN user@sip.contoso.com et attribuer une licence Teams. La mise en service complète du nom de domaine après son ajout aux domaines de votre locataire peut prendre jusqu’à 24 heures, la création d’un utilisateur avec un nouveau nom et l’attribution d’une licence à l’utilisateur.

Il est possible qu’une entreprise ait plusieurs espaces d’adressage SIP chez un seul locataire. Par exemple, une entreprise peut avoir contoso.com comme espace d’adressage SIP et fabrikam.com comme deuxième espace d’adressage SIP. Certains utilisateurs ont des adresses telles que user@contoso.com ; d’autres ont des adresses telles que user@fabrikam.com .

Le SBC n’a besoin que d’un seul FQDN et peut servir les utilisateurs à partir de n’importe quel espace d’adressage dans le locataire apparié. Par exemple, un SBC portant le nom sbc1.contoso.com peut recevoir et envoyer le trafic PSTN pour les utilisateurs avec des adresses user@contoso.com et user@fabrikam.com à condition que ces espaces d’adressage SIP soient enregistrés dans le même locataire.

Certificat de confiance public pour le SBC

Microsoft recommande de demander un certificat en générant une demande de signature de certificat (CSR) directement à partir de votre SBC. Pour obtenir des instructions spécifiques sur la génération d’une CSR pour un SBC, consultez les instructions d’interconnexion ou la documentation fournie par vos fournisseurs SBC.

Le certificat doit :

• Utilisez le FQDN SBC comme nom commun (CN) ou autre nom de sujet (SAN).
• Être signé par une autorité de certification incluse dans le programme racine de confiance Microsoft.
• Incluez l’authentification du serveur EKU.

Les certificats génériques sont pris en charge lorsqu’ils sont conformes à la norme RFC HTTP sur TLS. Un exemple serait d’utiliser *.contoso.com, qui correspondrait au nom de domaine complet SBC sbc.contoso.com, mais ne correspondrait pas à sbc.test.contoso.com.

L’interface SIP de routage direct approuve uniquement les certificats signés par les autorités de certification qui font partie du programme de certificat racine de confiance Microsoft. Assurez-vous qu’une autorité de certification qui fait partie du programme signe votre certificat SBC. Assurez-vous également que l’extension EKU (Extended Key Usage) de votre certificat inclut l’authentification du serveur. Pour plus d’informations, consultez Exigences du programme - Programme racine de confiance Microsoft.

Pour le routage direct dans les environnements Office 365 GCCH et DoD, les autorités de certification racine suivantes sont actuellement prises en charge :

• Autorité de certification racine DigiCert Global
• Autorité de certification racine DigiCert High Assurance EV
• DigiCert Global Root G2

Les clients peuvent demander que d’autres autorités de certification soient ajoutées à la liste prise en charge via leur canal de support habituel.

Pour vérifier que la connexion MTLS provient de l’infrastructure Teams, le SBC doit être configuré pour implémenter les vérifications suivantes sur le certificat côté serveur Teams :

• Vérifiez que la chaîne de certificats mène à l’une des autorités de certification racines répertoriées dans la section « Autorités de certification racines » de la page de détails de l’autorité de certification Azure.
• Vérifiez que le certificat « Autre nom de l’objet » inclut « sip.pstnhub.microsoft.com ».

signalisation SIP

Le routage direct est proposé dans les environnements suivants :

• Microsoft 365 ou Office 365
• Office 365 GCC
• Office 365 GCC High
• Office 365 DoD

Pour plus d’informations sur les environnements gouvernementaux, tels que GCC, GCC High et DoD, voir Environnements Office 365 et US Government.

Les sections suivantes décrivent les noms de domaine complets (FQDN), les ports et le comportement de basculement requis utilisés pour le routage direct.

signalisation SIP : FQDN

Pour Microsoft 365, Office 365 et Office 365 GCC, configurez les points de connexion suivants par ordre de priorité.

Si votre SBC utilise IPv6, configurez les FQDN suivants :

Ces noms de domaine complets fournissent :

• Routage géographique vers le centre de données Microsoft le plus proche.
• Basculement automatique lors d’interruptions de service. Pour plus d’informations, voir Mécanisme de basculement.
• Haute disponibilité pour la signalisation SIP.

Les noms de domaine complets se résolvent en plages d’adresses IP Microsoft :

• 52.112.0.0/14
• 52.120.0.0/14

Dans le cas d’IPv6, les noms de domaine complets se résolvent en plage IP Microsoft :

• 2603:1063:400::/40

Signalisation SIP : GCC High

Pour Office 365 GCC High, utilisez :

sip.pstnhub.gov.teams.microsoft.us

La sip.pstnhub.gov.teams.microsoft.us FQDN est résolue en une adresse IP à partir du sous-réseau suivant : 52.127.88.0/21
Pour autoriser le trafic entrant et sortant vers et depuis les adresses de signalisation, vous devez ouvrir des ports pour toutes ces adresses IP dans votre pare-feu.

Signalisation SIP : DoD

Pour le DoD d’Office 365, utilisez :

sip.pstnhub.dod.teams.microsoft.us

Le sip.pstnhub.dod.teams.microsoft.us FQDN est résolu en une adresse IP à partir du sous-réseau suivant : 52.127.64.0/21
Pour autoriser le trafic entrant et sortant vers et depuis les adresses de signalisation, vous devez ouvrir des ports pour toutes ces adresses IP dans votre pare-feu.

Étant donné que ces environnements fonctionnent dans des clouds Microsoft Government dédiés, les noms de domaine complets secondaires et tertiaires ne sont pas nécessaires.

Ports de signalisation SIP

Le routage direct nécessite les ports SIP/TLS suivants.

Basculement de signalisation SIP

Pour résoudre sip.pstnhub.microsoft.com, le SBC effectue une requête DNS. En fonction de l’emplacement SBC et des métriques de performances du centre de données, le centre de données principal est sélectionné.

Si le centre de données principal rencontre un problème, le SBC tente sip2.pstnhub.microsoft.com, qui se résout en deuxième centre de données affecté. Dans les rares cas où les centres de données de deux régions ne sont pas disponibles, le SBC réessaie le dernier FQDN (sip3.pstnhub.microsoft.com), qui fournit l’adresse IP du centre de données tertiaire.

Le tableau suivant résume les relations entre les centres de données primaires, secondaires et tertiaires :

Trafic média

Le trafic multimédia utilise des processeurs Microsoft Media, sauf si la fonction de contournement de média est activée.

Pour obtenir des conseils sur la planification du contournement du média, consultez Planifier le contournement du média avec le routage direct.

Plages d’adresses IP du processeur multimédia

Environnements Microsoft 365 / Office 365 / Office 365 GCC

Autoriser le trafic multimédia pour :

• 52.112.0.0/14 (adresses IP de 52.112.0.0 à 52.115.255.255)
• 52.120.0.0/14 (adresses IP de 52.120.0.0 à 52.123.255.255)

Dans le cas d’IPv6, autorisez le trafic multimédia pour :

• 2603:1063:400::/40
• 2603:1063:100::/40

Environnement Office 365 GCC High

• 52.127.88.0/21

Environnement DoD d’Office 365

• 52.127.64.0/21

Ports multimédias

Les ports suivants sont utilisés pour les supports.

Emplacements du processeur multimédia

Le trafic multimédia passe par des composants appelés processeurs multimédias. Les processeurs multimédias sont placés dans les mêmes centres de données que les proxys SIP comme suit :

• NOAM (USA Centre Sud, deux dans les centres de données USA Ouest et USA Est)
• Europe (centres de données du Royaume-Uni Sud, France Centre, Amsterdam et Dublin)
• Asie (Singapour datacenter)
• Japon (JP Est et Ouest des centres de données)
• Australie (centres de données de l’est et du sud-est de l’Australie)
• LATAM (Brésil Sud)

Les médias sont acheminés vers le centre de données Microsoft le plus proche dans la mesure du possible.

Codecs multimédias pris en charge

Jambe entre SBC et Microsoft Cloud Media Processor

S’applique avec et sans contournement de média.

L’interface de routage direct prend en charge les codecs suivants sur le tronçon entre le contrôleur SBC (Session Border Controller) et le processeur multimédia Microsoft Cloud :

• SOIE
• G.711
• G.722
• G.729
• AMR-WB (sans contournement uniquement)

Les administrateurs peuvent forcer l’utilisation d’un codec spécifique sur le contrôleur de frontière de session en excluant les codecs indésirables de l’offre.

Jambe entre le client Microsoft Teams et le processeur multimédia Cloud

S’applique uniquement lorsque la déviation de média est désactivée. Avec Media Bypass, le multimédia circule directement entre le client Teams et le SBC.

Sur le pied entre le processeur multimédia cloud et le client Teams, SILK ou G.722 est utilisé. Le choix du codec sur cette jambe est basé sur les algorithmes de Microsoft, qui prennent en compte plusieurs paramètres.

SBC (Session Border Controllers) pris en charge

Microsoft prend uniquement en charge les SBC certifiés à coupler avec le routage direct. La téléphonie – Grandes entreprises étant essentielle pour les entreprises, Microsoft exécute des tests intensifs avec les SBC sélectionnés et collabore avec les fournisseurs SBC pour s’assurer que les deux systèmes sont compatibles.

Les appareils validés sont répertoriés comme certifiés pour le routage direct Teams. Les appareils certifiés sont garantis pour fonctionner dans tous les scénarios.

Pour plus d’informations sur les SBC pris en charge, consultez Contrôleurs de frontière de session certifiés pour le routage direct.

Limites de prise en charge

Microsoft ne prend en charge Teams Phone avec routage direct que lorsqu’il est utilisé avec des appareils certifiés. En cas de problème, vous devez d’abord contacter le support client de votre fournisseur de SBC. Si nécessaire, le fournisseur SBC transmet le problème à Microsoft par les canaux internes.

Pour faire remonter les problèmes liés à SBC au support Microsoft, les clients doivent présenter un rapport d’enquête sur le fournisseur SBC. Ce document, contenant le numéro de référence du ticket du vendeur, sera fourni par son fournisseur SBC certifié.

Microsoft se réserve le droit de rejeter les cas de support où un appareil non certifié est connecté à Teams Phone via le routage direct. Si Microsoft détermine que le problème de routage direct d’un client concerne l’appareil SBC d’un fournisseur, le client doit contacter de nouveau le fournisseur SBC pour obtenir de l’aide.

Meilleures pratiques

Pour une expérience de routage direct optimale, Microsoft vous recommande de :

• Déployer des SBC certifiés.
• Configurez une connectivité SIP redondante.
• Utilisez des certificats publics approuvés.
• Configurez toutes les règles de pare-feu requises par Microsoft.
• Surveillez la qualité des appels après le déploiement.
• Testez les scénarios de basculement avant le déploiement en production.
• Passez en revue les conseils de planification du réseau Microsoft Teams avant le déploiement.

Étapes suivantes

Après avoir planifié votre déploiement de routage direct :

1. Configurez votre contrôleur de frontière de session (SBC) certifié.
2. Connectez le SBC à Microsoft Teams.
3. Configurez les itinéraires vocaux et les plans de numérotation.
4. Attribuez des licences téléphoniques Teams et des stratégies de routage vocal.
5. Validez les appels RTC entrants et sortants.
6. Surveillez la qualité des appels et l’intégrité du déploiement à l’aide des rapports Microsoft Teams.

Vérifier votre déploiement

Après avoir terminé la configuration :

• Vérifiez que le SBC signale une connexion saine à Microsoft Teams.
• Valider les appels RTC entrants.
• Valider les appels RTC sortants.
• Vérifiez la fonctionnalité d’appel d’urgence, si elle est configurée.
• Test de basculement entre les points de connexion SIP.
• Vérifiez que les stratégies de routage vocal sont correctement attribuées.
• Validez la qualité des appels dans des scénarios utilisateur représentatifs.

Voir aussi

• Configurer le routage direct
• Contrôleurs de frontière de session certifiés pour le routage direct
• Planifier votre solution vocale Teams
• Options de connectivité RTC
• Planifier la déviation du média avec le routage direct
• Licences Microsoft Teams
• Session vidéo : Routage direct dans Microsoft Teams
• Guide de dépannage (TSG) pour les problèmes de connectivité (OPTIONS TLS et SIP)
• TSG pour les problèmes d’appels sortants
• TSG pour les problèmes d’appels entrants
• TSG pour les problèmes de transfert d’appel
• Codes de réponse Microsoft SIP