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

Dans la partie 1 du Routage direct pour Microsoft Teams Deep Dive nous avons discuté des flux d'appels fondamentaux du client Teams. Dans cet article, nous continuerons la discussion en parlant de flux d'appels Direct Routing avec et sans bypass média. Enfin, nous allons voir une vue de haut niveau de la topologie globale lors de l'utilisation du routage direct.

Appel de routage direct d'équipe sans contournement de média

Certains des composants du diagramme ci-dessous vous sembleront familiers. Les codes CC, MC et MP que nous avions utilisés avec nos appels 1: 1 / P2P et multi-parties entrent également en ligne de compte lorsque nous parlons de contournement de média.

Cependant, il y a quelques composants supplémentaires à conscient de. Le premier s'appelle le Hub PSTN. Le concentrateur PSTN est responsable de la prise de décisions sur l'acheminement des appels particuliers. L'autre composant s'appelle le proxy SIP. Cela entre en jeu en raison du fait que le SBC ne peut pas comprendre la signalisation HTTP REST ainsi le proxy SIP est là pour convertir le trafic de signalisation HTTP REST en trafic SIP. En plus de ces deux composants, vous aurez une base de données centrale. La base de données centrale est responsable du stockage des données telles que:

• Voix
• Stratégies vocales
• Configuration du tronc SBC
• CDR (Call Detail Records)
• Information de surveillance
• Données de dépannage

, disons qu'Alice essaye de faire un appel au numéro +41 (Suisse) mentionné dans le dernier article de blog . Comme avant, Alice va mettre en place un canal de signalisation via HTTP REST vers le CC. CC pourra alors lire les différentes routes vocales et politiques de voix et déterminer que cet appel est destiné à l'infrastructure de routage direct. Ensuite, CC établira des connexions au concentrateur PSTN. Le concentrateur PSTN examinera ensuite la base de données principale pour déterminer la santé des différents SBC auxquels nous devons nous connecter. Le concentrateur PSTN devra prendre la bonne décision quant à l'acheminement de l'appel, mais nous voulons nous assurer que nous acheminons cet appel vers un SBC actuellement disponible / actif. Cela est effectué par un intervalle d'interrogation OPTIONS SIP que les contrôleurs SBC retourneront dans le service. Une fois que le PSTN Hub a déterminé où l'appel devrait être routé et que ces points d'extrémité sont en bonne santé, nous établirons une connexion avec les MC et les MP. Nous faisons cela pour que nous puissions attribuer un bon PM qui soit géographiquement le plus proche du SBC. Nous pouvons le déterminer en fonction de l'adresse IP publique que le SBC utilise lorsqu'il est enregistré dans O365. Le concentrateur PSTN se connectera ensuite au proxy SIP à l'aide de la signalisation HTTP REST, qui à son tour sera convertie en protocole SIP et établira la connexion au SBC local. Du point de vue des médias, le client Teams connectera ses médias au député correspondant. De même, le SBC connectera ses médias au député correspondant. Ainsi, permettant à cet appel de réussir. À la fin de l'appel, tous les différents composants enverront les informations CDR dans le service. Cela permet ensuite à l'administrateur du locataire d'accéder à l'outil Analyse des appels, de consulter les diverses informations publiées, puis d'utiliser ces informations à des fins de dépannage ou de rapport de qualité d'appel.

Appel de routage direct des équipes avec contournement de média

Dans certaines situations, le flux d'appels que nous venons d'examiner peut ne pas être le chemin le plus optimal. Par exemple, disons que vous avez un grand nombre d'utilisateurs hébergés dans le même bureau que le SBC local. En l'absence de contournement des médias, les utilisateurs devraient envoyer leur trafic sur Internet, jusqu'au député, puis revenir au SBC. C'est là que le contournement des médias peut être très pratique. Comme vous le verrez dans le diagramme ci-dessous, le flux de signalisation suit toujours le même chemin que le dernier scénario.

Cependant, lorsque nous allons établir une connexion média, plutôt que de renvoyer l'adresse IP du MP, nous retournons le ] Adresse IP publique du SBC . Cela permettrait au client Teams de se connecter directement à l'adresse IP publique du SBC au lieu de se connecter au service O365. Pour que cela fonctionne, l'adresse IP publique du SBC doit être accessible par le client Teams. Si le client Teams est sur le réseau client interne, nous devons toujours nous assurer que l'adresse IP publique du SBC est routable. Veuillez en tenir compte lorsque vous planifiez votre topologie de routage pour vous assurer que le contournement de média fonctionnera dans ce scénario. Une fois que le contournement de média a été configuré dans le service et que vous avez ouvert votre réseau de manière à ce que les plages de ports IP publiques et médias soient disponibles, le client Teams pourra se connecter directement au SBC.

non situé dans les locaux du client? Eh bien, d'abord les choses d'abord, tant que le contournement des médias est configuré, nous retournons l'adresse IP publique du SBC plutôt que le processeur de médias. À ce stade, le client Teams effectuera une vérification de connectivité. Si la vérification de connectivité réussit, le client Teams peut se connecter au SBC. Que faire si la vérification de la connectivité échoue? Il peut y avoir une multitude de raisons pour lesquelles cela pourrait échouer. Par exemple, l'équipe de sécurité n'a peut-être pas configuré une ACL (liste de contrôle d'accès) permettant d'accéder à cette adresse IP publique du SBC. Peut-être n'autorisent-ils que des adresses IP bien connues, comme celles d'Azure. Quoi qu'il en soit, vous aurez la possibilité d'utiliser le Relay à l'intérieur de O365. Comme vous le verrez dans le diagramme ci-dessous, cela permettra au client Teams de se connecter au relais ainsi que le SBC pour se connecter au relais.

Afin de soutenir Dans ce scénario, vous devez vous assurer que votre SBC prend en charge ICE (Interactive Connectivity Establishment) Lite. Tous les SBC certifiés de Microsoft prennent en charge ICE Lite, aussi longtemps que vous avez un SBC certifié Microsoft, vous répondez à cette exigence.

Vue globale de la topologie du nuage

Alors, où le routage direct est-il déployé? Pour simplifier, les composants de routage direct sont déployés dans trois zones géographiques différentes:

• Amérique du Nord
• Europe
• Asie

Chacune des régions mentionnées ci-dessus possède deux centres de données. Le centre de données correspondant sera gravé autour de l'adresse IP publique fournie par le SBC.

Merci d'avoir choisi la partie 2 du processus de routage direct pour les équipes Microsoft. Dans la partie 3 de cette série, je vais discuter des aspects de la configuration de Direct Routing.