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

Il y a un peu moins d'un mois, Microsoft a publié Direct Routing for Public Preview . Juste à ce moment-là, j'ai également écrit un article de blog couvrant Direct Routing à un niveau élevé . Aujourd'hui, je vais faire une plongée en profondeur (4 séries de pièces) pour vous tous, administrateurs et architectes de Skype for Business / Teams qui veulent savoir ce qui se passe réellement dans les coulisses. Avant de commencer cette plongée profonde, veuillez noter qu'il s'agit d'un contenu preview et qu'il est susceptible d'être modifié en termes de disponibilité générale

Terminology & Positioning

Microsoft Teams est connu comme le hub pour le travail d'équipe dans Office 365 L'un des composants qui vous permet d'envoyer et de recevoir des appels s'appelle Système téléphonique (également appelé PBX dans le monde des télécommunications). Phone System permet essentiellement aux utilisateurs de faire ce qui suit:

• Faire des appels
• Recevoir des appels
• Transférer des appels
• Appeler des Mute / Unmute

Vous pouvez effectuer toutes ces tâches de base n'importe où, avoir un accès internet. Cependant, afin de compléter ces appels, le système téléphonique doit être connecté à quelque chose appelé le réseau téléphonique public commuté (PSTN). Afin d'interconnecter le système téléphonique au PSTN, vous aurez deux options à choisir dans l'écosystème Microsoft:

1. Microsoft Calling Plans – Microsoft est votre fournisseur. Ils fournissent vos numéros de téléphone et vos interconnexions au RTPC.
2. Routage direct dans les équipes (services d'appels téléphoniques) – Cela permet aux clients d'interconnecter leurs propres services dans le nuage O365 grâce à l'architecture de routage direct.

Choisir l'une de ces options permettra à cette interconnexion et réaliser ce que nous appelons la tonalité de numérotation PSTN. Lorsque vous associez le système téléphonique à des plans d'appel Microsoft ou à un routage direct dans des équipes, vous disposez d'appels d'entreprise complets pour vos utilisateurs O365 dans les équipes à l'échelle mondiale. Maintenant que vous avez une compréhension fondamentale du fonctionnement du routage direct, revenons sur certains scénarios pour choisir le routage direct.

Scénarios pour choisir le routage direct

Un scénario serait celui où vous voulez connecter votre propre RTPC. coffre dans O365. Les entreprises se trouvent généralement dans cette situation lorsque les plans Microsoft Calling ne sont pas disponibles pour leur pays. Il entre également en jeu lorsque les clients veulent conserver leur contrat de téléphonie existant. Dans ces situations, vous utiliserez vos interconnexions RTC existantes et vous connecterez à un SBC (Session Border Controller) certifié Microsoft pour permettre l'accès à O365 Phone System.

Un autre scénario serait l'interopérabilité avec des systèmes tiers. Cela vous permettrait de mélanger deux systèmes. Par exemple, si vous avez des utilisateurs sur un ancien PBX (Avaya, Cisco, etc.) pendant que vous migrez d'autres utilisateurs vers Phone System dans O365 et que vous permettez toujours de communiquer entre eux. De plus, cela vous permettrait également de connecter quelque chose comme un adaptateur de téléphonie analogique (ATA).

Maintenant que nous connaissons les situations possibles où le routage direct entre en jeu, discutons des types de chemins empruntés à partir d'un utilisateur qui utilise Calling Plan par rapport à un utilisateur qui utilise Direct Routing.

)

Dans le schéma ci-dessus vous pouvez voir 2 utilisateurs qui utilisent le système téléphonique. Celui qui est le système téléphonique avec Calling Plan et celui qui est le système téléphonique avec routage direct. Si l'utilisateur avec Calling Plan compose un numéro sur le RTPC, cet appel traversera les centres de données Microsoft pour atteindre le RTPC. Si l'utilisateur avec le routage direct configuré compose un numéro sur le PSTN, l'appel traverse d'abord le SBC certifié local, puis le PSTN. Comme vous pouvez le voir, les deux ont le même résultat en ce qu'ils atteignent le RTPC.

Call Paths (utilisateur)

Il est également possible de configurer un seul utilisateur avec des plans d'appel et de routage direct. Cela nous permettra de contrôler le chemin emprunté en fonction du numéro de destination en cours de composition. Par exemple, dans le diagramme ci-dessous disons que cet utilisateur (appelons-le simplement Bob …) est configuré pour utiliser à la fois Calling Plan et Direct Routing.

Quand Bob fait un appel Au code de pays +49 (Allemagne) basé sur la configuration de routage en place, Bob traversera les centres de données Microsoft et sortira vers le PSTN. Maintenant, disons que Bob devait appeler +41 (Suisse) ou un numéro de téléphone assigné à un appareil analogique suspendu sur le PBX d'un tiers sur place. En fonction de la configuration de routage en place, il prendrait la décision d'acheminer l'appel via le chemin de routage direct. Cela signifie que les appels de Bob vers +41 ou un périphérique analogique sur le PBX tiers utilisent le chemin de routage direct en traversant le SBC. Lorsque l'appel atteint le SBC, le SBC détermine si l'appel doit être acheminé vers l'ATA, vers le PBX tiers ou, s'il s'agit d'un numéro +41, vers le PSTN. L'avantage ici est que le SBC pourrait potentiellement être situé en Suisse, ce qui pourrait être considéré comme un appel local par opposition à un appel international. Maintenant que vous avez une compréhension des chemins pour les niveaux locataire et utilisateur, nous pouvons passer à l'architecture, les flux d'appels et la topologie technique.

Flux d'appels 1: 1 des équipes (la voix peut circuler directement)

un flux d'appels 1: 1 / Peer-to-peer dans les équipes Microsoft, nos deux utilisateurs (nous les appellerons Alice et Bob) doivent d'abord établir un canal de signalisation. Si Alice appelait Bob, son client Teams se connecterait à un composant dans O365 appelé Call Controller (CC). C'est le plan de signalisation et c'est là que la messagerie de signalisation passe par HTTP REST au composant O365. Le CC verra que cet appel est pour Bob, et à son tour, cherchera à voir tous les points d'extrémité actifs de Bob et établira une SONNERIE sur les points d'extrémité actifs de Bob. Dans le diagramme ci-dessous, Bob recevra une notification "toast" d'un appel entrant d'Alice.

Si Bob et Alice sont dans une situation où ils ont une connectivité directe à un un autre (c'est-à-dire situé dans le même bureau dans le même bâtiment), les médias seront en fait autorisés à s'écouler directement les uns vers les autres. Dans ce cas, les médias sont des médias sRTP (protocole de transport sécurisé en temps réel), ce qui est très similaire dans le monde Skype for Business.

Flux d'appels 1: 1 des équipes (pas de connectivité directe, exemple: NAT)

Maintenant, disons que Alice et Bob n'ont pas de connectivité directe. Par exemple, Alice pourrait être dans un café ou sur son réseau domestique où les connexions sont limitées par les appareils NAT. Dans ce scénario, si Alice et Bob essayaient de connecter leurs médias entre eux, cela échouerait finalement (comme le montre l'image ci-dessous).

Et bien s'ils le peuvent t se connecter de cette façon, alors comment sont-ils connectés? La réponse courte est via un relais qui se trouve dans O365. En utilisant ce périphérique de relais dans Azure, Alice et Bob peuvent maintenant connecter leur trafic multimédia

Équiper le flux d'appels multipièces de 1: 1

Disons qu'Alice et Bob discutaient entre eux dans une session 1: 1 / P2P et voulaient faire glisser Charlie dans l'appel. Comme précédemment, nous exploitons notre signalisation via HTTP REST vers le contrôleur d'appel (CC). CC doit travailler avec le MC (Media Controller) et le MP (Media Prossessor) pour établir un MCU (Multi-point Control Unit) multi-parties pour qu'ils aient l'appel multipartite. Ensuite, d'un point de vue de la signalisation, CC informera Bob et Charlie que la session est en train d'être escaladée pour un appel multipartite. Le député manipule alors tout le son et le distribue à tous les participants de l'appel

Dans le prochain article de blog, nous parlerons du routage direct avec et sans contournement des médias. en place. Restez à l'écoute!