Routage direct pour les équipes Microsoft Deep Dive: Partie 3

Bienvenue à nouveau! La dernière fois, dans la partie 2 du Direct Routing pour Microsoft Teams Deep Dive nous avons discuté du flux d'appels Direct Routing avec et sans contournement de média en place. Dans cet article de blog, nous aborderons les aspects de configuration du routage direct.

Lorsque vous parlez des aspects de configuration du routage direct, il est important de comprendre les composants de la solution qui sont impliqués dans le routage direct. Comme vous le verrez dans le diagramme ci-dessous, les composants de la solution sont séparés en 3 sections principales:

1. Microsoft
2. Customer
3. Fournisseur de service / PSTN

La première section est Microsoft a fourni des composants. Microsoft fournit au client ce qui suit:

• Phone System
• Teams Client
• Support (y compris les transferts d'incidents entre Microsoft et les fournisseurs SBC)
  • Si un dossier de support est ouvert avec Microsoft et que les ingénieurs de support déterminent qu'il y a une mauvaise configuration sur le SBC certifié, Microsoft transférera ce dossier en conséquence au lieu de faire un incident séparé au client.
• Orientation / documentation de la configuration

La deuxième section représente les composants fournis Customer . Le client (vous-même) devra fournir l'accès à:

• Licence appropriée pour le système téléphonique (E3 + Module de licence du système téléphonique Microsoft E5)
• Contrat avec votre fournisseur / opérateur de télécommunication
• Fournir un support SBC (y compris le contrat de soutien)
• Accès à la SBC à partir de O365
  • Par Internet ou par voie express
• Le SBC certifié doit avoir:
  • IP publique
  • FQDN
  • Certificat
  • Configuration du SBC avec O365 et transporteur (peut être des partenaires Microsoft)

La dernière section est la Carrier fournie des composants. Cela inclut:

• Trunk de téléphonie
  • T1 / E1 dans SBC
  • tronc SIP directement à partir de l'opérateur

Maintenant que nous avons couvert les notions de base sur les composants impliqués dans le routage direct, jetons un coup d'œil aux plages IP et aux ports requis

IP Ranges and Ports

verra dans le diagramme ci-dessous, sur le côté gauche sera un ensemble d'adresses IP répertoriées à la fois pour le SIP Hub et Media Processors (MP).

Comme mentionné dans partie 1 sur les flux d'appels la signalisation traversera le composant SIP Hub alors que les médias traverseront les divers processeurs média (MP), en supposant que nous n'utilisons pas de contournement des médias. Si nous nous concentrons sur l'aspect Hub SIP, vous vous souviendrez qu'il existe 3 zones géographiques différentes où le routage direct est déployé: Amériques, Europe et Asie. Comme vous pouvez le voir, chaque emplacement de centre de données géographique a un nom de domaine complet et une adresse IP correspondants requis pour pouvoir accéder au canal de signalisation pour le routage direct. Du point de vue des médias, Microsoft n'offre pas actuellement une plage d'adresses IP fixe, mais celle-ci sera fournie ultérieurement. Actuellement, la demande du député peut provenir de n'importe quelle adresse IP située dans la gamme Azure Network. Pour déterminer cette plage de réseau, vous pouvez utiliser l'URL ici . Maintenant, si nous passons à la partie droite du diagramme, vous verrez les ports de signalisation SIP (TLS / SIP) ainsi que les ports média (UDP / SRTP). Du point de vue du port de signalisation SIP, lorsque le proxy SIP dans O365 communique avec le SBC, il utilisera un port source (1024 – 65 535) et utilisera un port de destination que vous définirez sur le SBC lorsque vous le configurerez. Le trafic qui passe du SBC au proxy SIP utilisera un port source que nous définissons sur le SBC et le proxy SIP dans O365 écoutera sur le port 5061. Du point de vue des médias, les médias utiliseront UDP / SRTP. Le média qui circule du MP dans O365 vers le SBC correspondant utilisera le port source (49, 152-53, 247) et un port de destination défini sur le SBC. De même, le trafic inverse entre le SBC et le point d'accès utilisera le port source que vous avez défini sur le SBC et le port de destination correspondant (49, 152-53, 247). Maintenant que nous avons considéré l'adresse IP et les plages de ports nécessaires pour le routage direct, discutons du nom de domaine complet qui sera utilisé pour le SBC

FQDN SBC

Lorsque vous enregistrerez votre locataire O365, vous recevrez un nom par défaut qui se termine par .onmicrosoft.com . Tous les noms de domaine * .onmicrosoft.com ne sont pas pris en charge en tant que noms SBC. Cela dit, pour utiliser Direct Routing, vous devez ajouter au moins un domaine personnalisé à votre locataire O365. Par exemple, dans le diagramme ci-dessous, vous verrez que contoso.onmicrosoft.com ne peut pas être utilisé comme un nom de domaine complet SBC, donc nous ajouterons contoso.com à notre locataire O365.

Une fois ajouté, vous pouvez ensuite utiliser une série de noms pour le SBC (comme vu ci-dessus). Tous les noms de domaine complets sont des noms valides car ils sont mappés au nom DNS correspondant enregistré dans le locataire O365.

Remarque: Vous ne pouvez pas enregistrer / utiliser des sous-domaines (voir ci-dessus). Obtention du certificat pour SBC

Alors, que se passe-t-il si vous avez plusieurs domaines, par exemple contoso.com et adatum.com? Eh bien, la bonne nouvelle est que vous n'aurez pas à créer de nom de domaine complet SBC pour chaque domaine que vous possédez. Il suffit de créer un nom de domaine complet pour votre SBC et de le faire servir à tous les utilisateurs, quel que soit le nom de domaine qu'ils utilisent. Maintenant que les pare-feu sont ouverts pour les plages d'adresses IP et de ports correctes, ainsi qu'un nom correspondant pour le SBC, notre prochaine étape consiste à obtenir un certificat pour le SBC. Scénario 1: Réduction du coût du certificat

Ce scénario est le scénario le plus simple, qui consiste simplement à demander un certificat générique. Dans ce cas, si nous avons 1 ou 10 SBC nous pouvons identifier un certificat avec * .contoso.com et nous pouvons utiliser ce certificat sur tous les différents SBC. Dans certains cas, ce n'est peut-être pas le meilleur choix. Par exemple, peut-être que les SBC sont dans un endroit non géré / non sécurisé ou peut-être que votre organisation ne se sent pas à l'aise d'avoir un certificat générique sur le SBC particulier

Scénario 2: Équilibrer le coût et la sécurité [19659002] Ce scénario permet le meilleur des deux mondes (coût et sécurité). Dans ce scénario, vous n'utilisez pas un caractère générique complet comme dans le scénario précédent, mais vous incluez le nom de chaque SBC dans votre champ SAN du certificat. Comme indiqué dans le diagramme ci-dessus, le SN (nom du sujet) pour ce certificat particulier est gw1.contoso.com mais nous avons ajouté les entrées SAN de gw1.conotoso.com, gw2.contoso.com, gw3.conotoso.com, et gw4.contoso.com au certificat. Cela équilibre l'aspect sécurité car vous n'aurez pas de certificat générique et sera plus adapté aux noms SBC spécifiques

Scénario 3: Maximiser la sécurité

Ce scénario permet une sécurité maximale puisque nous avoir un certificat séparé pour chaque SBC. Cependant, cela coûtera également plus cher que les deux scénarios précédents, donc ceci devrait être pris en compte lorsque vous déciderez quel scénario convient le mieux à votre organisation.

Enfin, sur le diagramme ci-dessus, vous verrez une liste des autorités de certification supportées . Cette liste est à jour en juin 2018 mais il est recommandé de toujours vérifier les articles de Docs de Microsoft juste au cas où.

Jumeler le SBC

Jusqu'à présent nous avons configuré notre pare-feu pour permettre la connectivité au bon Les plages d'adresses IP et de port, ont ajouté le (s) nom (s) FQDN approprié (s) à notre SBC, et nous avons obtenu un certificat pour notre SBC. Il est maintenant temps de coupler SBC avec O365. Pour ce faire, nous devons d'abord établir une session PowerShell distante à O365. De là, nous pouvons utiliser la cmdlet "New-CsOnlinePSTNGateway". Dans la capture d'écran ci-dessous, vous verrez un exemple de cette applet de commande.

Certains paramètres de cette applet de commande incluent:

• FQDN de SBC
• SipSignalingPort – Ports défini sur SBC
• MaxConcurrentSessions – Détermine le nombre d'appels que SBC peut gérer. Ceci est utilisé pour utiliser des décisions de routage intelligentes
• ForwardPAI – Indique si l'en-tête P-Asserted Identity est transmis avec l'appel. Cet en-tête fournit un moyen d'identifier un appelant.
  • Par défaut, cette valeur est false
• ForwardCallHistory – Indique si les informations sur l'historique des appels seront transmises via la jonction. Si cette option est activée, 2 en-têtes supplémentaires seront envoyés (Historique et Référé par).
  • Par défaut, cette valeur est false
• SIPOptionsEnabled – Ceci est un paramètre critique, car il permet le battement de coeur entre le SBC et O365.
  • Vous devez vous assurer que ce paramètre est activé.
• Activé – Il est possible de définir le SBC sur "-Enabled $ false", par exemple lorsque vous effectuez une maintenance sur le SBC et que vous souhaitez drainer l'une des connexions et interdire toute nouvelle connexion.
  • S'il s'agit du seul SBC de l'itinéraire, le paramètre "Enabled" est ignoré. Même si "Enabled" est défini sur false, les appels continueront à envoyer des appels au noeud final. En effet, le routage de l'appel est plus important que de déterminer qu'il n'y a qu'un seul SBC avec le paramètre "Enabled" défini sur false. Vous voudrez en tenir compte lors de l'architecture de votre topologie de routage direct et vous assurer que vous disposez des routes HA et de sauvegarde appropriées si nécessaire.
• EnableFastFailoverTimer – Lorsqu'il est défini sur 10 (valeur par défaut), les appels sortants auxquels la passerelle ne répond pas dans les 10 secondes sont acheminés vers le prochain tronçon disponible
  • S'il n'y a pas de lignes réseau supplémentaires, l'appel est automatiquement supprimé. Dans une organisation avec des réseaux lents et des réponses de passerelle, cela pourrait potentiellement entraîner une suppression inutile des appels. La valeur par défaut est 10.

Pour plus d'informations sur cette applet de commande, veuillez consulter la documentation Microsoft sur le routage direct .

Dans cet article, nous avons abordé divers aspects de la configuration du routage direct. Restez à l'écoute pour la partie 4 de la série, car dans le prochain article, nous abordons certains aspects de la syntaxe SIP pour le SBC lui-même, ainsi que les aspects de provisioning utilisateur et de routage vocal pour le routage direct.