Planifier le routage direct

  • Article
  • S’applique à:
    Microsoft Teams

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

Diagramme montrant la configuration de la connectivité RTC locale.

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 organization dans les cas suivants :

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

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

  • Votre organization 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 conférence 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 Exigences et considérations relatives à l’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 :

Configuration requise pour l’infrastructure Vous avez besoin des éléments suivants
Contrôleur de bordure de session (SBC) SBC pris en charge. Pour plus d’informations, consultez SBC pris en charge.
Jonctions de téléphonie connectées au SBC Une ou plusieurs jonctions de téléphonie connectées au SBC. À une extrémité, le SBC se connecte à Teams Phone via le routage direct. Le SBC peut également se connecter à des entités de téléphonie tierces, telles que des PBX, des adaptateurs de téléphonie analogique, etc. Toute option de connectivité RTC connectée au SBC fonctionne. (Pour la configuration des jonctions RTC vers le SBC, reportez-vous aux fournisseurs SBC ou aux fournisseurs de jonctions.)
Microsoft 365 organization Une organization Microsoft 365 que vous utilisez pour abriter vos utilisateurs Microsoft Teams, ainsi que la configuration et la connexion au SBC.
Bureau d’enregistrement d’utilisateurs L’utilisateur doit être hébergé dans Microsoft 365.
Si votre entreprise dispose d’un environnement Skype Entreprise local avec une connectivité hybride à Microsoft 365, vous ne pouvez pas activer la voix dans Teams pour un utilisateur hébergé localement.

Pour case activée le bureau d’enregistrement d’un utilisateur, utilisez l’applet de commande PowerShell Teams suivante :
Get-CsOnlineUser -Identity <user> | fl HostingProvider

La sortie de l’applet de commande doit afficher :
HostingProvider : sipfed.online.lync.com
Domaines Un ou plusieurs domaines ajoutés à vos organisations Microsoft 365 ou Office 365.

Vous ne pouvez pas utiliser le domaine par défaut, *.onmicrosoft.com, créé automatiquement pour votre locataire.

Pour afficher les domaines, vous pouvez utiliser l’applet de commande PowerShell Teams suivante :
Get-CsTenant | fl Domains

Pour plus d’informations sur les domaines et les organisations Microsoft 365 ou Office 365, consultez FAQ sur les domaines.
Adresse IP publique du SBC Adresse IP publique qui peut être utilisée pour se connecter au SBC. En fonction du type de SBC, le SBC peut utiliser NAT.
Nom de domaine complet (FQDN) pour le SBC Nom de domaine complet pour le SBC, où la partie domaine du nom de domaine complet est l’un des domaines inscrits dans votre microsoft 365 ou Office 365 organization. Pour plus d’informations, consultez Noms de domaine SBC.
Entrée DNS publique pour le SBC Entrée DNS publique mappant le nom de domaine complet SBC à l’adresse IP publique.
Certificat approuvé public pour le SBC Certificat pour le SBC à utiliser pour toutes les communications avec le routage direct. Pour plus d’informations, consultez Certificat approuvé public pour le SBC.
Points de connexion pour le routage direct Les points de connexion pour le routage direct sont les trois noms de domaine complets suivants :

sip.pstnhub.microsoft.com : le nom de domaine complet global doit d’abord être essayé.
sip2.pstnhub.microsoft.com : nom de domaine complet secondaire, mappe géographiquement à la deuxième région de priorité.
sip3.pstnhub.microsoft.com – FQDN tertiaire, mappe géographiquement à la troisième région prioritaire.

Pour plus d’informations sur la configuration requise, consultez Signalisation SIP : FQDN.
Adresses IP et ports de pare-feu pour le support de routage direct Le SBC communique avec les services suivants dans le cloud :

Proxy SIP, qui gère la signalisation
Processeur multimédia, qui gère les médias, sauf lorsque la déviation du trafic multimédia est activée

Ces deux services ont des adresses IP distinctes dans Microsoft Cloud, décrites plus loin dans ce document.

Pour plus d’informations, consultez la section Microsoft Teams dans URL et plages d’adresses IP.
Profil de transport de média TCP/RTP/SAVP
UDP/RTP/SAVP
Adresses IP et ports de pare-feu pour les médias Microsoft Teams Pour plus d’informations, consultez URL et plages d’adresses IP.

Licences et autres exigences

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

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.

Exigences et considérations relatives à l’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 ayez entièrement configuré le routage direct et que vous ayez ajouté des numéros d’audioconférence au locataire de votre organization.

  • 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 entièrement configuré le routage direct et que vous avez ajouté des numéros d’audioconférence au locataire de votre organization.

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

Réaffectation d’appel ad hoc 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 :

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.

Nom DNS Peut être utilisé pour le nom de domaine complet SBC Exemples de noms de domaine complet
contoso.com Oui Noms valides :
sbc1.contoso.com
ssbcs15.contoso.com
europe.contoso.com
contoso.onmicrosoft.com Non L’utilisation de domaines *.onmicrosoft.com n’est pas prise en charge pour les noms 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.

Remarque

Le nom de domaine complet SBC dans Azure Communication Services routage direct doit être différent du nom de domaine complet SBC dans le routage direct Teams.

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.

Remarque

La plupart des autorités de certification exigent que la taille de la clé privée soit d’au moins 2 048. Gardez cela à l’esprit lors de la génération de la csr.

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.

Remarque

À la fin du mois d’août 2023, Microsoft 365 mettra à jour ses services pour utiliser les certificats TLS émis par la nouvelle autorité de certification « DigiCert Global Root G2 ». Pour éviter les erreurs susceptibles d’affecter votre service, vous devez mettre à jour le magasin racine de certificats de votre SBC pour inclure la nouvelle autorité de certification racine. Pour plus d’informations, consultez Changement de certificat SIP vers l’autorité de certification MSPKI.

Pour le routage direct dans Office 365 environnements 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

Remarque

Si la prise en charge du protocole TLS mutuel (MTLS) est activée pour la connexion Teams sur le SBC, vous devez installer les certificats Baltimore CyberTrust Root et DigiCert Global Root G2 dans le magasin racine de confiance SBC du contexte TLS Teams. (Cela est dû au fait que les certificats de service Microsoft utilisent l’un de ces deux certificats racines.) Pour télécharger ces certificats racines, consultez Chaînes de chiffrement Microsoft 365. Pour plus d’informations, consultez Modifications des certificats TLS Office.

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 :

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, consultez 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 doD Office 365 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.

Office 365 environnement 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é :

Trafic De À Port source Port de destination
SIP/TLS SIP Proxy SBC 1024 – 65535 Défini sur le SBC (Pour Office 365 GCC High/DoD, seul le port 5061 doit être utilisé)
SIP/TLS SBC SIP Proxy Défini sur le SBC 5061

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 :

Si le centre de données principal est EMEA NOAM ASIE
Centre de données secondaire (sip2.pstnhub.microsoft.com) NOUS UE NOUS
Centre de données tertiaire (sip3.pstnhub.microsoft.com) ASIE ASIE UE

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.

Remarque

Les plages d’adresses IP présentées dans ce document sont spécifiques au routage direct et peuvent différer de celles recommandées pour le client Teams.

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)

Office 365 environnement DoD

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

  • 52.127.64.0/21

Office 365 environnement 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 De À Port source Port de destination
UDP/SRTP Processeur multimédia SBC 3478-3481 et 49152 – 53247 Défini sur le SBC
UDP/SRTP SBC Processeur multimédia Défini sur le SBC 3478-3481 et 49152 – 53247

Remarque

Microsoft recommande au moins deux ports par appel simultané sur le SBC.

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.

Remarque

Le re-ciblage multimédia n’est pas pris en charge. Pendant un appel de routage direct, si le SBC envoie une nouvelle adresse IP multimédia au routage direct, bien qu’elle soit négociée dans la signalisation SIP, le média n’est jamais envoyé à la nouvelle adresse IP à partir du routage direct.

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 Téléphonie – Grandes entreprises est essentiel 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 qui ont été 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