Exigences de l’infrastructure d’acheminement direct Azure

Article
12/09/2023

Cet article décrit l’infrastructure, les licences et les détails de la connectivité des contrôleurs de frontière de session (SBC) que vous devez garder à l’esprit lorsque vous planifiez votre déploiement du routage direct Azure.

Exigences de l’infrastructure

Les conditions requises d’infrastructure pour les SBC et domaines pris en charge, ainsi que d’autres conditions de connectivité réseau pour le déploiement du routage direct Azure, sont listées dans le tableau suivant :

Exigence d’infrastructure	Vous avez besoin de ceci
Contrôleur de frontière de session (SBC)	Un SBC pris en charge. Pour plus d’informations, consultez SBC pris en charge.
Réseaux téléphoniques connectés au SBC	Un ou plusieurs réseaux téléphoniques connectés au SBC. À une extrémité, le SBC se connecte à Azure Communication Services par le biais du routage direct. Le SBC peut également se connecter à des entités téléphoniques tierces, comme des PBX ou des adaptateurs de téléphonie analogique. Toute option de connectivité au réseau téléphonique commuté (RTC) qui est connectée au SBC fonctionne. (Pour la configuration des réseaux RTCP pour le SBC, reportez-vous aux fournisseurs SBC ou aux fournisseurs de réseau téléphonique.)
Abonnement Azure	Abonnement Azure que vous utilisez pour créer une ressource Communication Services, ainsi que la configuration et la connexion au SBC.
Jeton d’accès à Communication Services	Pour passer des appels, vous avez besoin d’un jeton d’accès valide avec l’étendue `voip`. Consultez Jetons d’accès
Adresse IP publique pour le SBC	Adresse IP publique qui peut être utilisée pour se connecter au SBC. En fonction du type de SBC, celui-ci peut utiliser la traduction d’adresses réseau (NAT).
Nom de domaine complet (FQDN) pour le SBC	Pour plus d’informations, consultez Certificats SBC et noms de domaine.
Entrée DNS publique pour le SBC	Entrée DNS publique mappant le nom de domaine complet du SBC à l’IP publique.
Certificat public approuvé pour le SBC	Certificat pour le SBC, à utiliser pour toutes les communications avec le routage direct Azure. Pour plus d’informations, consultez Certificats SBC et noms de domaine.
Adresses IP et ports du pare-feu pour la signalisation SIP et le multimédia	Le SBC communique avec les services suivants dans le cloud : Proxy SIP, qui gère la signalisation Processeur multimédia, qui gère le multimédia Ces deux services ont des adresses IP distinctes dans Microsoft Cloud, décrites plus loin dans ce document.

Certificats et noms de domaine du SBC

Microsoft vous recommande de demander le certificat pour le SBC à l’aide d’une demande de signature de certification (CSR). Pour obtenir des instructions spécifiques sur la génération d’une demande de signature de certification pour un SBC, reportez-vous aux instructions d’interconnexion ou à la documentation fournie par vos fournisseurs de SBC.

Remarque

La plupart des autorités de certification demandent que la taille de la clé privée soit au moins égale à 2 048. Gardez cela à l’esprit lorsque vous générez la demande de signature de certification.

Le certificat doit avoir le nom de domaine complet du SBC pour le champ Nom commun (CN) ou Autre nom du sujet (SAN). Le certificat doit être émis directement par une autorité de certification, et non par un fournisseur intermédiaire.

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

Les clients qui utilisent déjà Office 365 et ont un domaine inscrit dans le centre d’administration de Microsoft 365 peuvent utiliser le nom de domaine complet du SBC du même domaine.

Un exemple serait l’utilisation de *.contoso.com qui correspondrait au nom de domaine complet SBC sbc.contoso.com, mais ne correspondrait pas à sbc.test.contoso.com.

Remarque

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

Communication Services fait uniquement confiance aux certificats signés par des autorités de certification qui font partie du programme de certificat racine approuv de Microsoft. Assurez-vous que votre certificat de SBC est signé par une autorité de certification qui fait partie du programme et que l’extension Utilisation améliorée de la clé de votre certificat inclut l’authentification du serveur. En savoir plus :

Exigences du programme – Programme de certificat racine approuv de Microsoft

Liste des certificats d’autorité de certification inclus

Important

Le routage direct Azure Communication Services prend uniquement en charge TLS 1.2. Pour éviter tout impact sur le service, vérifiez que vos SBC sont configurés pour prendre en charge TLS1.2 et peuvent se connecter à l’aide de l’une des suites de chiffrement suivantes pour la signalisation SIP :

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, par exemple ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, par exemple ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, par exemple ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, par exemple ECDHE-RSA-AES128-SHA256

Pour le média SRTP uniquement AES_CM_128_HMAC_SHA1_80 est pris en charge.

L’appairage des SBC fonctionne au niveau des ressources Communication Services. Cela signifie que vous pouvez appairer plusieurs SBC à une seule ressource Communication Services. Toutefois, vous ne pouvez pas associer un SBC unique à plusieurs ressources Communication Services. Des noms de domaine complets SBC uniques sont nécessaires pour l’appairage à différentes ressources.

Si la prise en charge du protocole TLS mutuel (MTLS) est activée pour la connexion de routage directe sur le SBC, vous devez installer le racine Baltimore CyberTrust et les certificats DigiCert Global Root G2 dans le magasin racine approuvé SBC du contexte TLS de routage direct. (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 Office 365. Pour plus d’informations, consultez modifications de certificat TLS Office.

Signalisation SIP : noms de domaine complets

Les points de connexion pour le routage direct de Communication Services sont les trois noms de domaine complets suivants :

sip.pstnhub.microsoft.com - Nom de domaine complet global - doit être essayé en premier. Lorsque le SBC envoie une requête pour résoudre ce nom, les serveurs DNS de Microsoft Azure renvoient une adresse IP qui pointe vers le centre de données Azure principal attribué au SBC. L’affectation est basée sur les métriques de performance des centres de données et sur 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 - mappé géographiquement à la région de deuxième priorité.
sip3.pstnhub.microsoft.com - Nom de domaine complet tertiaire - mappé géographiquement à la région de troisième priorité.

Ces trois noms de domaine complets dans l’ordre sont requis pour :

Offrir une expérience optimale (moins chargée et plus proche du centre de centres SBC affecté en interrogeant le premier nom de domaine complet).
Fournir un basculement lorsque la connexion depuis un SBC est établie avec 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 l’une des adresses IP suivantes :

52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Ouvrez les ports du pare-feu pour toutes ces plages d’adresses IP afin d’autoriser le trafic entrant et sortant vers et depuis les adresses pour la signalisation.

Signalisation SIP : Ports

Utilisez les ports suivants pour le routage direct Azure de Communication Services :

Trafic	Du	À	Port source	Port de destination
SIP/TLS	Proxy SIP	SBC	1024 à 65535	Défini sur le SBC
SIP/TLS	SBC	Proxy SIP	Défini sur le SBC	5061

Mécanisme de basculement pour la signalisation SIP

Le SBC fait une requête DNS pour résoudre sip.pstnhub.microsoft.com. En fonction de l’emplacement du SBC et des métriques de performance 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 essaie sip2.pstnhub.microsoft.com, dont la résolution aboutit au deuxième centre de données attribué, et, dans le rare cas où les centres de données de deux régions ne sont pas disponibles, le SBC réessaie le dernier nom de domaine complet (sip3.pstnhub.microsoft.com), qui fournit l’adresse IP du centre de données tertiaire.

Trafic de média : IP et plages de ports

Le trafic multimédia transite vers et depuis un service distinct appelé Processeur multimédia. Les plages d’adresses IP pour le trafic multimédia sont les mêmes que pour la signalisation :

52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Plages de ports

La plage de ports des processeurs multimédias sont indiquées dans le tableau suivant :

Trafic	Du	À	Port source	Port de destination
UDP/SRTP	Processeur multimédia	SBC	49152–53247	Défini sur le SBC
UDP/SRTP	SBC	Processeur multimédia	Défini sur le SBC	49152–53247

Remarque

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

Trafic multimédia : zone géographique des processeurs multimédias

Les processeurs multimédias sont placés dans les mêmes centres de données que les proxys SIP :

NOAM (USA Centre Sud, deux dans les centres de données USA Ouest et USA Est)
Europe (UE Ouest, UE Nord, Suède, France Centre)
Asie (centre de données de Singapour)
Japon (centres de données Japon Est et Ouest)
Australie (centres de données Australie Est et Sud-Ouest)
LATAM (Brésil Sud)
(Afrique) (Afrique du Sud Nord)

Trafic multimédia : codecs

Segment entre SBC et le processeur multimédia cloud.

L’interface de routage direct Azure sur le tronçon entre le SBC et le processeur multimédia cloud peut utiliser les codecs suivants :

SILK, G.711, G.722, G.729

Vous pouvez forcer l’utilisation du codec spécifique sur le SBC en excluant de l’offre les codecs indésirables.

Tronçon entre l’application du kit SDK Appel Azure Communication Services et le processeur multimédia Cloud

Sur le tronçon entre le processeur multimédia cloud et l’application du kit SDK Appel Azure Communication Services, G.722 est utilisé. L’ajout d’autres codecs sur ce tronçon est en cours.

Partager via

Exigences de l’infrastructure d’acheminement direct Azure