Planifier le routage direct

Le routage direct vous permet de connecter un contrôleur de frontière de session (SBC) fourni par le client à Microsoft Teams Phone. Avec cette fonctionnalité, vous pouvez configurer la connectivité RTC (Public Switched Telephone Network) local avec Teams, comme illustré dans le diagramme suivant :

La planification de votre déploiement de routage direct est essentielle à la réussite de l’implémentation. Cet article décrit les exigences en matière d’infrastructure et de licence, et fournit des informations sur la connectivité SBC. Veillez à lire cet article avant de commencer votre configuration, qui est décrite dans Configurer le routage direct.

Avec le routage direct, vous pouvez connecter votre SBC à presque n’importe quelle jonction de téléphonie ou interconnecter avec un équipement RTC tiers. Le routage direct vous permet de :

• Utilisez pratiquement n’importe quelle jonction RTC avec Teams Phone.

• Configurez l’interopérabilité entre les équipements de téléphonie appartenant au client, tels qu’un pbX tiers, des appareils analogiques et Teams.

Microsoft propose également des solutions vocales tout-dans-le-cloud, telles que le forfait d’appels Microsoft. Toutefois, le routage direct peut être idéal pour votre organisation dans les cas suivants :

• Le forfait d’appels Microsoft n’est pas disponible dans votre pays/région.

• Votre organisation nécessite une connexion à des appareils analogiques tiers, des centres d’appels, etc.

• Votre organisation a un contrat existant avec un opérateur RTC.

Pour plus d’informations sur les solutions vocales, consultez Planifier votre solution vocale Teams.

Avec le routage direct, lorsque les utilisateurs participent à une réunion planifiée, le numéro de connexion est fourni par le service d’audioconférence Microsoft, qui nécessite une licence appropriée. Lors de la numérotation sortante, l’audioconférence passe l’appel à l’aide des fonctionnalités d’appel en ligne, ce qui nécessite une licence appropriée. Si un utilisateur n’a pas de licence d’audioconférence Microsoft, l’appel est acheminé via le routage direct. Pour plus d’informations, consultez Routage direct avec audioconférence.

Le routage direct prend également en charge les utilisateurs qui disposent d’une autre licence pour le forfait d’appels Microsoft. Pour plus d’informations, consultez Routage direct avec forfait d’appels et connexion d’opérateur.

Conditions d’infrastructure requises

Les exigences d’infrastructure pour les SBC, domaines et autres exigences de connectivité réseau prises en charge pour déployer le routage direct sont répertoriées dans le tableau suivant :

Licences et autres exigences

Les utilisateurs de routage direct doivent disposer des licences suivantes attribuées dans Microsoft 365 :

• Téléphone Teams
• Microsoft Teams

Pour plus d’informations sur le moment où une licence d’audioconférence est requise, consultez Routage direct avec audioconférence.

Le routage direct prend également en charge les utilisateurs disposant d’une licence pour le forfait d’appels Microsoft. Pour plus d’informations, consultez Routage direct avec forfait d’appels et connexion d’opérateur.

Pour plus d’informations sur les licences, consultez Licences Microsoft Teams et Licences de module complémentaire Microsoft Teams.

Remarque : le routage direct n’est pas pris en charge en mode Îles.

Routage direct avec audioconférence

Cette section décrit les exigences et les considérations relatives à l’utilisation du routage direct et de l’audioconférence.

• Pour les utilisateurs GCC High et DoD G5, Microsoft vous recommande de désactiver le composant d’audioconférence inclus dans G5 jusqu’à ce que vous configuriez le routage direct et que vous ayez ajouté des numéros d’audioconférence au locataire de votre organisation.

• Pour les utilisateurs GCC High et DoD G3, Microsoft recommande de ne pas attribuer le module complémentaire de licence d’audioconférence tant que vous n’avez pas configuré le routage direct et que vous n’avez pas ajouté des numéros d’audioconférence au locataire de votre organisation.

Pour plus d’informations, consultez Audioconférence avec routage direct pour GCC High et DoD.

Escalade d’appel non planifiée et licence d’audioconférence

Un utilisateur Teams peut démarrer un appel Teams-à-un Teams-to-PSTN ou Teams-to-Teams et y ajouter un participant RTC. Le chemin d’accès à l’appel dépend de l’attribution ou non d’une licence d’audioconférence Microsoft à l’utilisateur qui effectue l’escalade de l’appel :

• Si une licence d’audioconférence Microsoft est attribuée à l’utilisateur Teams qui effectue l’escalade de l’appel, l’escalade se produit via le service d’audioconférence Microsoft. Le participant RTC distant qui est invité à l’appel existant reçoit une notification concernant l’appel entrant et voit le numéro du pont Microsoft affecté à l’utilisateur Teams qui a initié l’escalade.

• Si la licence d’audioconférence Microsoft n’est pas attribuée à l’utilisateur Teams qui effectue l’escalade de l’appel, l’escalade se produit par le biais d’un contrôleur de bordure de session connecté à l’interface de routage direct. Le participant RTC distant qui est invité à l’appel reçoit une notification concernant l’appel entrant et voit le numéro de l’utilisateur Teams qui a initié l’escalade. Le SBC spécifique utilisé pour l’escalade est défini par la stratégie de routage de l’utilisateur.

Vous devez vérifier ce qui suit :

• CsOnlineVoiceRoutingPolicy est attribué à l’utilisateur.

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

Routage direct avec forfaits d’appels et connexion d’opérateur

Le routage direct prend également en charge les utilisateurs disposant d’une licence pour le plan d’appels Microsoft ou auxquels un numéro de téléphone Operator Connect est attribué. Les utilisateurs de Téléphone Teams avec forfait d’appels ou Connexion d’opérateur peuvent acheminer certains appels à l’aide de l’interface de routage direct.

La combinaison d’un forfait d’appels ou d’une connexion d’opérateur et d’une connectivité de routage direct pour le même utilisateur est facultative, mais peut être utile. Par exemple, lorsque l’utilisateur se voit attribuer un forfait d’appels Microsoft ou un numéro de connexion d’opérateur, mais qu’il souhaite router certains appels à l’aide du SBC.

L’un des scénarios les plus courants est les appels à des PBX tiers. Avec cette configuration, les appels aux téléphones connectés au PBX tiers sont routés à l’aide du routage direct et restent donc dans le réseau d’entreprise, sans traverser le réseau RTC. Pendant ce temps, tous les autres appels sont routés vers le RTC en fonction de la méthode de connectivité RTC attribuée aux utilisateurs : Plan d’appels Microsoft ou Connexion opérateur.

Pour plus d’informations sur les licences de téléphone Teams, consultez Licences de module complémentaire Microsoft Teams.

Points de terminaison pris en charge

Vous pouvez utiliser les éléments suivants comme point de terminaison :

• N’importe quel client Teams.

• Téléphones de zone commune. Vous n’avez pas besoin d’une licence de forfait d’appels lors de la configuration d’un téléphone de zone commune avec le routage direct. Pour plus d’informations, consultez Configurer des téléphones de zone commune pour Microsoft Teams.

Noms de domaine SBC

Le nom de domaine SBC doit provenir de l’un des noms inscrits dans Domaines du locataire.

Le tableau suivant présente des exemples de noms DNS inscrits pour le locataire, indique si le nom peut être utilisé comme nom de domaine complet pour le SBC, ainsi que des exemples de noms de nom de domaine complet valides. Notez que vous ne pouvez pas utiliser le locataire *.onmicrosoft.com pour le nom de domaine complet du SBC.

Supposons que vous souhaitiez utiliser un nouveau nom de domaine. Par exemple, votre locataire a contoso.com en tant que nom de domaine inscrit dans votre locataire, et vous souhaitez utiliser sbc1.sip.contoso.com.

Avant de pouvoir coupler un SBC avec le nom sbc1.sip.contoso.com, vous devez inscrire le nom de domaine sip.contoso.com dans Domaines dans votre locataire. Si vous essayez de coupler un SBC avec sbc1.sip.contoso.com avant d’inscrire le nom de domaine, vous obtenez l’erreur suivante : « Impossible d’utiliser le domaine « sbc1.sip.contoso.com », car il n’a pas été configuré pour ce locataire. »

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. Jusqu’à 24 heures peuvent être nécessaires pour approvisionner entièrement le nom de domaine après son ajout aux domaines de votre locataire, pour créer un utilisateur avec un nouveau nom et pour attribuer une licence à l’utilisateur.

Il est possible qu’une entreprise ait plusieurs espaces d’adressage SIP dans 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 une adresse user@contoso.com et d’autres ont l’adresse user@fabrikam.com.

Le SBC n’a besoin que d’un seul nom de domaine complet et peut traiter les utilisateurs à partir de n’importe quel espace d’adressage dans le locataire jumelé. Par exemple, un SBC portant le nom sbc1.contoso.com peut recevoir et envoyer le trafic RTC pour les utilisateurs avec des adresses user@contoso.com et user@fabrikam.com tant que ces espaces d’adressage SIP sont inscrits dans le même locataire.

Certificat approuvé public pour le SBC

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

Le certificat doit avoir le nom de domaine complet SBC comme champ nom commun (CN) ou autre nom d’objet (SAN).

Le routage direct prend également en charge un caractère générique dans le CN et/ou le SAN, et le caractère générique doit être conforme à la norme RFC HTTP Over TLS.

Par exemple, vous pouvez 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 certificats racines approuvés Microsoft. Assurez-vous qu’une autorité de certification qui fait partie du programme signe votre certificat SBC. Vérifiez également que l’extension Utilisation étendue de la clé (EKU) de votre certificat inclut l’authentification du serveur et l’authentification du client.

Pour plus d’informations, consultez Configuration requise du programme - Programme racine approuvé Microsoft et Liste de certificats d’autorité de certification incluses.

Pour le routage direct dans les environnements Office 365 GCCH et DoD, l’une des autorités de certification racine suivantes doit générer le certificat :

• DigiCert Global Root CA
• DigiCert High Assurance EV Root CA

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 d’émission de certificat provient de l’une des autorités de certification racines suivantes :

  • Certificat racine de CyberTrust Baltimore
  • DigiCert Global Root G2

• Vérifiez que le certificat « Autre nom de l’objet » inclut « sip.pstnhub.microsoft.com ».

Signalisation SIP : noms de domaine complets, ports, mécanisme de basculement

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 des informations sur les noms de domaine complets, les ports et les mécanismes de basculement.

Signalisation SIP : noms de domaine complets

Les sections suivantes décrivent les points de connexion FQDN pour différents environnements cloud Microsoft.

Environnements Microsoft 365, Office 365 et Office 365 GCC

Dans ces environnements, les points de connexion pour le routage direct sont les trois noms de domaine complets suivants :

• sip.pstnhub.microsoft.com (nom de domaine complet global) doit d’abord être essayé. Lorsque le SBC envoie une demande de résolution de ce nom, les serveurs DNS Microsoft Azure retournent une adresse IP pointant vers le centre de données Azure principal affecté au SBC. L’affectation est basée sur les métriques de performances des centres de données et la proximité géographique du SBC. L’adresse IP retournée correspond au nom de domaine complet principal.

• sip2.pstnhub.microsoft.com ( nom de domaine complet secondaire) est mappé géographiquement à la deuxième région de priorité.

• sip3.pstnhub.microsoft.com ( nom de domaine complet tertiaire) correspond géographiquement à la troisième région prioritaire.

Il est nécessaire de placer ces trois noms de domaine complets dans l’ordre pour :

• Fournir une expérience optimale (moins chargé et le plus proche du centre de données SBC affecté en interrogeant le premier nom de domaine complet).

• Fournir un basculement lorsque la connexion d’un SBC est établie à un centre de données qui rencontre un problème temporaire. Pour plus d’informations, consultez Mécanisme de basculement.

Les noms de domaine complets sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com et sip3.pstnhub.microsoft.com sont résolus en adresses IP à partir des sous-réseaux suivants :

• 52.112.0.0/14
• 52.122.0.0/15

Vous devez ouvrir des ports pour toutes ces plages d’adresses IP dans votre pare-feu afin d’autoriser le trafic entrant et sortant vers et depuis les adresses pour la signalisation.

Remarque : Le trafic SIP entrant vers les SBC à partir des points de terminaison SIP Teams peut provenir de n’importe quelle adresse IP dans ces sous-réseaux, et non seulement des adresses IP qui sont résolues à partir des noms de domaine complets mentionnés précédemment. Pour plus d’informations sur la configuration du peering SIP, consultez votre documentation SBC.

Environnement Office GCC DoD

Dans l’environnement Office GCC DoD, le point de connexion pour le routage direct est le nom de domaine complet suivant :

sip.pstnhub.dod.teams.microsoft.us : nom de domaine complet global. Étant donné que l’environnement Office 365 DoD existe uniquement dans les centres de données américains, il n’existe pas de noms de domaine complets secondaires et tertiaires.

Le nom de domaine complet sip.pstnhub.dod.teams.microsoft.us est résolu en 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 pour la signalisation, vous devez ouvrir des ports pour toutes ces adresses IP dans votre pare-feu.

Environnement Office 365 GCC High

Dans l’environnement Office 365 GCC High, le point de connexion pour le routage direct est le nom de domaine complet suivant :

sip.pstnhub.gov.teams.microsoft.us : nom de domaine complet global. Comme l’environnement GCC High existe uniquement dans les centres de données américains, il n’y a pas de FQDN secondaires et tertiaires.

Le nom de domaine complet sip.pstnhub.gov.teams.microsoft.us est résolu en 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 pour la signalisation, vous devez ouvrir des ports pour toutes ces adresses IP dans votre pare-feu.

Signalisation SIP : Ports

Vous devez utiliser les ports suivants pour les environnements Microsoft 365 ou Office 365 où le routage direct est proposé :

Signalisation SIP : mécanisme de basculement

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 attribué. Dans les rares cas où les centres de données de deux régions ne sont pas disponibles, le SBC retente le dernier nom de domaine complet (sip3.pstnhub.microsoft.com), qui fournit l’adresse IP du centre de données tertiaire.

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

Trafic multimédia : plages de ports, processeurs multimédias, CODECS

Trafic multimédia : plages de ports

Si vous souhaitez déployer le routage direct sans contournement de média, les conditions suivantes s’appliquent. Pour connaître les exigences de pare-feu pour la déviation du trafic multimédia, consultez Planifier la déviation du trafic multimédia avec le routage direct.

Le trafic multimédia circule vers et à partir d’un service distinct dans le cloud Microsoft. Les plages d’adresses IP pour le trafic multimédia sont les suivantes.

Environnements Microsoft 365, Office 365 et Office 365 GCC

Dans les environnements Microsoft 365, Office 365 et Office 365 GCC, les plages d’adresses IP sont les suivantes :

• 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)

Environnement Office 365 DoD

Dans l’environnement Office 365 DoD, les plages d’adresses IP sont les suivantes :

• 52.127.64.0/21

Environnement Office 365 GCC High

Dans l’environnement Office 365 GCC High, les plages d’adresses IP sont les suivantes :

• 52.127.88.0/21

Tous les environnements

Les plages de ports des processeurs multimédias sont indiquées dans le tableau suivant :

Trafic multimédia : zone géographique des processeurs

Le trafic multimédia transite 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 Royaume-Uni Sud, France Centre, Amsterdam et Dublin)
• Asie (centre de données de Singapour)
• Japon (centres de données JP Est et Ouest)
• Australie (centres de données Est et Sud-Est de l’UA)
• LATAM (Brésil Sud)

Trafic multimédia : Codecs

Les sections suivantes décrivent les codecs pour le trafic multimédia.

Étape entre SBC et le processeur multimédia cloud ou le client Microsoft Teams

S’applique aux cas de contournement de média et aux cas de non-contournement.

L’interface de routage direct située entre le contrôleur de bordure de session et le processeur multimédia cloud (sans déviation du trafic multimédia) ou entre le client Teams et le SBC (si la déviation du trafic multimédia est activée) peut utiliser les codecs suivants :

• Contournement non multimédia (processeur multimédia SBC vers cloud) : SILK, G.711, G.722, G.729
• Contournement du trafic multimédia (SBC vers le client Teams) : SILK, G.711, G.722, G.729

Vous pouvez forcer l’utilisation du codec spécifique sur le contrôleur de bordure 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 au cas de contournement de média. Avec la déviation du trafic multimédia, le média circule directement entre le client Teams et le SBC.

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

Contrôleurs de bordure de session (SBC) pris en charge

Microsoft prend uniquement en charge les SBC certifiés à coupler avec le routage direct. Étant donné que Voix Entreprise est essentielle pour les entreprises, Microsoft effectue 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 contrôleurs SBC pris en charge, consultez Contrôleurs de frontière de session certifiés pour le routage direct.

Limites de prise en charge

Microsoft prend uniquement en charge Teams Phone avec routage direct lorsqu’il est utilisé avec des appareils certifiés. En cas de problème, vous devez d’abord contacter le support technique de votre fournisseur SBC. Si nécessaire, le fournisseur SBC fait remonter le problème à Microsoft via des canaux internes. Microsoft se réserve le droit de rejeter les cas de support dans lesquels 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 réengager le fournisseur SBC pour obtenir du support.

Voir aussi

• Configurer le routage direct
• Session vidéo : Routage direct dans Microsoft Teams.