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

Bienvenue à la partie 4 de notre série Direct Routing pour Microsoft Teams Deep Dive! Si vous venez de nous rejoindre pour la première fois, je vous recommande de revenir sur les articles de blog précédents sur ce sujet . Dans cet article, nous aborderons la syntaxe SIP, le provisioning des utilisateurs, les bases du routage vocal et enfin quelques scénarios de configuration basiques et avancés impliqués dans le routage direct pour les équipes Microsoft.

Syntaxe SIP

Typiquement le fournisseur SBC certifié (AudioCodes , Ribbon, etc.) vous fournira les composants nécessaires à la configuration du SBC. Cependant, je vais juste parler de certains de ces composants au cas où. Lorsque vous examinez la syntaxe SIP du SBC vers O365, le SBC doit présenter l'en-tête Contact avec le nom de domaine complet SBC valide (correspondant au certificat) dans les messages SIP Invite et Options. Comme vous le verrez dans le diagramme ci-dessous, le champ inférieur "Contact" du morceau "@ sbc1.contoso.com" correspond à ce qui doit correspondre au nom de domaine complet SBC. Nous utilisons cet en-tête de contact pour définir le nom de domaine complet du SBC et pour nous assurer que nous avons une correspondance avec le certificat pour une connexion TLS sécurisée.

Remarque: l'envoi d'un enregistrement n'est pas recommandé. Si l'en-tête Record-Route est présenté, le FQDN du SBC dans Record-Route DOIT correspondre au nom de domaine complet SBC dans l'en-tête Contact.

Maintenant que notre SBC est associé à O365, nous pouvons commencer à provisionner nos utilisateurs. Comme vous vous en souvenez peut-être dans partie 1 de cette série nous avons mentionné que vous pouvez provisionner des utilisateurs avec soit le routage direct seulement ou une combinaison de Microsoft Calling Plan et Direct Routing. Dans le diagramme ci-dessous, vous verrez les deux scénarios pour le provisionnement des utilisateurs.

Dans le scénario Direct Routing uniquement, l'utilisateur doit posséder au moins la licence Skype Entreprise Online Plan, Microsoft Phone System et Microsoft Teams. Lorsqu'il s'agit de fournir un numéro de téléphone à l'utilisateur, il a la possibilité d'utiliser Active Directory sur site. Cela suppose que vous avez synchronisé Active Directory à O365 en utilisant Azure AD Connect. L'autre option que vous avez est de provisionner l'utilisateur directement dans Azure Active Directory. Du point de vue du routage, lorsque l'utilisateur tente d'effectuer un appel sortant, seules les routes configurées par l'administrateur seront évaluées. S'il n'existe aucun itinéraire qui corresponde au numéro que l'utilisateur tente de composer, l'appel sera simplement abandonné.

Dans le scénario Plan d'appel Microsoft mixte et routage direct, vous devez disposer d'au moins un Skype Entreprise Online (plan 2) licence, Microsoft Phone System, équipes Microsoft et un module complémentaire de plan d'appel Microsoft. Le module Calling Plan inclut la possibilité de composer le numéro au niveau national ou international, ce qui devrait être pris en compte lors de vos décisions de routage que nous aborderons sous peu. Du point de vue du provisionnement de numéros, étant donné qu'un plan d'appel Microsoft est attribué à l'utilisateur, le numéro sera acquis auprès de Microsoft ou il peut s'agir d'un numéro que vous transférez dans le système téléphonique dans O365. Plusieurs étapes se produisent lors d'une tentative d'appel sortant:

1. Nous évaluons les routes configurées par l'administrateur
2. S'il n'y a pas d'itinéraire correspondant au numéro que l'utilisateur tente de composer, nous vérifions l'appel de l'utilisateur plan
3. S'il s'agit d'un appel national ou international, nous vérifierons le plan d'appel correspondant assigné à l'utilisateur et à l'itinéraire, selon le cas.

Maintenant que nous avons discuté de l'approvisionnement, parlons de la configuration du routage vocal. Direct Routing

Principes de base du routage vocal

Dans l'exemple ci-dessous, disons que nous avons un utilisateur Teams en Allemagne qui appelle un numéro +1 (800).

Dans ce scénario, cela serait considéré comme un appel international pour l'utilisateur de l'Allemagne puisqu'il s'agit d'un numéro de téléphone américain en cours de numérotation. La première vérification du routage vocal consiste à déterminer si une stratégie de routage vocal existe et est attribuée à cet utilisateur. Si ce n'est pas le cas, la vérification suivante consiste à vérifier si l'utilisateur dispose d'un plan d'appel Microsoft. Si aucun plan d'appel Microsoft n'est affecté, l'appel échoue. Cela est dû au fait que cet utilisateur n'a pas les autorisations correctes pour effectuer ce type d'appel. Toutefois, si l'utilisateur dispose d'un plan d'appel Microsoft, la détermination suivante sera le type de plan d'appel disponible pour cet utilisateur (national ou international). Ainsi, dans ce scénario, si l'utilisateur n'avait qu'un plan d'appel domestique, cet appel échouerait puisque cet utilisateur effectue un appel international depuis l'Allemagne vers les États-Unis. Si l'utilisateur a un plan d'appel qui inclut l'appel international, alors cet appel réussira via le plan d'appel Microsoft. Si nous considérons qu'il existe une politique de routage vocal pour cet utilisateur particulier, nous ferions un retour en arrière en examinant la politique de routage vocal et en évaluant les usages dans l'ordre. Si vous n'êtes pas familier avec le terme «utilisation», cela signifie simplement le conteneur pour une correspondance de modèle et une route que nous voulons prendre. Donc, étant donné que l'utilisateur a une politique de routage de la voix, la prochaine question que vous voudriez examiner est de savoir si oui ou non ils ont une utilisation qui correspond au nombre qu'ils tentent de composer. Disons que bien qu'ils aient une politique de routage vocal, il n'y a pas de route vocale qui commence par "+1", donc il n'y a pas de correspondance. S'il n'y a pas de correspondance, nous basculons alors dans la vérification du plan d'appel et, s'ils n'ont pas de plan d'appel, l'appel échoue. D'un autre côté, si l'utilisateur a au moins une route qui correspond au modèle de numérotation, nous essaierons alors d'essayer l'appel via le SBC qui est attaché aux routes correspondantes. Comme vous vous en souvenez peut-être dans le blog précédent, nous passerons en revue notre composant PSTN Hub pour voir si notre SBC correspondant est en bonne santé. Si le SBC correspondant est en bonne santé, nous pouvons envoyer l'appel à ce SBC et l'appel sera acheminé avec succès via Direct Routing. Cependant, si le SBC n'est pas en bonne santé (ne plus envoyer d'options SIP), il est considéré comme non fonctionnel et l'appel échouera. Maintenant que nous avons couvert l'aspect routage vocal, terminons avec la configuration simple pour le routage direct.

Configuration de base

Dans la cmdlet ci-dessous, nous allons configurer un seul SBC et nous allons le configurer pour qu'il ait un route unique qui acheminera tous les appels vers ce SBC

Étape 1: Associez SBC à O365

New-CsOnlinePSTNGateway -FQDN sbc1.contoso.com -SipSignalingPort 5068 -Enabled $ true

Note: Ceci est l'ensemble minimum de paramètres qui devront être configurés

Étape 2: Configurer les utilisations du RTPC

Rappelons que les utilisations du RTPC ne sont que des conteneurs pour une série de routes. Cette commande construit donc le conteneur (appelé "Unrestricted") pour nous

Set-CsOnlinePSTNUsage -Identity Global -Usage @ {Add = "Unrestricted"}

Une fois le conteneur créé / Utilisations PSTN nous devons alors ajouter des routes dans l'usage.

Étape 3: Construire des routes

New-CsOnlineVoiceRoute -Identity "sans restriction" -NumberPattern ". *" -OnlinePSTNGatewayList sbc1.contoso.com -Priority 1 -OnlinePstnUsages "Unrestricted"

Dans l'applet de commande ci-dessus, nous avons donné un nom à la route vocale en ligne ("Unrestricted"). N'oubliez pas que nous prenons nos décisions de routage en fonction du numéro de téléphone de destination appelé. Dans l'exemple ci-dessus, nous avons utilisé ". *" Pour notre modèle de nombre, ce qui signifie que cela correspondra à n'importe quel schéma numérique composé. Ainsi, tout numéro appelé sera acheminé vers la passerelle ou SBC que nous déterminons. Dans ce cas, "OnlinePSTNGatewayList" sera l'endroit où nous avons l'intention d'acheminer cet appel. Dans ce scénario, puisque nous avons seulement un SBC, nous n'aurons qu'un seul article listé. Vous pouvez également définir la priorité, et encore une fois puisque nous avons seulement un SBC cela aura une priorité de "1". La dernière partie de cette applet de commande est le paramètre "OnlinePstnUsages" qui place la route dans l'utilisation du conteneur / PSTN que nous avons appelée "Unrestricted"

Étape 4: Créer une politique de routage vocal

Puisque vous ne pouvez pas affecter L'utilisation du RTPC directement à un utilisateur, vous devez créer une stratégie de routage vocal à attribuer à l'utilisateur. Dans la cmdlet ci-dessous, nous avons créé une nouvelle politique de routage vocal appelée "Unrestricted" et nous avons utilisé le paramètre "-OnlinePstnUsages" pour indiquer quelle (s) utilisation (s) devrait (doivent) être incluse (s) dans cette politique de routage vocal. "Unrestricted" -OnlinePstnUsages "Unrestricted"

Cette politique de routage vocal n'a qu'une utilisation ("Unrestricted") et à l'intérieur de cette utilisation nous avons seulement une route, qui indique d'envoyer un appel à la passerelle sbc1.contoso.

Étape 5: Assigner une politique de routage vocal

Une fois la politique de routage vocal créée, vous pouvez assigner la politique aux utilisateurs en utilisant la cmdlet ci-dessous:

Grant-CsOnlineVoiceRoutingPolicy -Identity "Brian Siefferman "-PolicyName" Unrestricted "

Configuration avancée

Dans la vie (et le travail) j'aime suivre le principe KISS. Si vous n'avez pas entendu parler du principe KISS (Keep It Simple, Stupid), c'est un acronyme inventé par la marine américaine en 1960. Je dirais que je suis ce principe avec environ 90% de tout ce que je fais. Cependant, parfois la solution la plus simple, ne fait pas la meilleure solution. Par exemple, dans le scénario précédent, un seul SBC en place fonctionne comme une preuve de concept ou un test initial et un déploiement. Cependant, il est toujours recommandé d'avoir en jeu des composants de haute disponibilité (HA) et de reprise après sinistre (DR) qui introduiront une certaine complexité. Cela dit, regardons un scénario où nous avons plusieurs SBC avec HA et DR.

Configuration multi-SBC avec scénario HA et DR

Dans ce scénario disons que nous avons 2 SBC dans notre datacenter Redmond (sbc1.contoso.com et sbc2.contoso.com). Comme vous vous en souvenez peut-être, nous devons d'abord coupler ces appareils à O365. Donc votre syntaxe devrait ressembler à ceci:

New-CsOnlinePSTNGateway -FQDN sbc1.contoso.com -SipSignalingPort 5068 -Enabled $ true

Nouveau-CsOnlinePSTNGateway -FQDN sbc2.contoso. com -SipSignalingPort 5068 -Enabled $ true

L'étape suivante consiste à configurer / construire vos usages PSTN. Dans ce scénario, nous allons créer une utilisation du RTPC appelée "États-Unis et Canada"

Set-CsOnlinePstnUsage -Identity Global -Usage @ {Add = "États-Unis et Canada"}

Essentiellement Tout ce qui contient un "+1" sera contenu dans cette utilisation.

Du point de vue du routage, la syntaxe suivante va construire les routes de façon à ce que tout numéro que l'utilisateur appelle commence par "+1425" ou "+1206" suivi de 7 chiffres supplémentaires redirigera vers ces SBC (sbc1.contoso.com et sbc2.contoso.com). Comme dans le scénario précédent, nous utiliserions l'applet de commande "New-CsOnlineVoiceRoute" pour répondre à cette exigence.

New-CsOnlineVoiceRoute -Identity "Redmond 1" -NumberPattern "^ + 1 (425 | 206) ( d {7}) $ "-OnlinePstnGatewayList sbc1.contoso.com, sbc2.contoso.com -Priority 1 -OnlinePstnUsages" États-Unis et Canada "

Maintenant, disons que nous avons ajouté deux SBC supplémentaires (sbc3 .contoso.com & sbc4.contoso.com) dans notre datacenter Bellevue pour servir de notre chemin de sauvegarde / passif. Donc, tout comme avec nos deux premiers SBC, la première étape sera de les coupler à O365.

New-CsOnlinePSTNGateway -FQDN sbc3.contoso.com -SipSignalingPort 5068 -Enabled $ true

New-CsOnlinePSTNGateway -FQDN sbc4.contoso.com -SipSignalingPort 5068 -Enabled $ true

Ensuite, nous configurerons nos routes vocales de la même manière que nous l'avons fait précédemment.

New-CsOnlineVoiceRoute -Identité "Redmond 2" -NumberPattern "^ + 1 (425 | 206) ( d {7}) $" -OnlinePstnGatewayList sbc3.contoso.com, sbc4.contoso.com -Priorité 2 -OnlinePstnUsages "États-Unis et Canada"

Note: Vous avez peut-être remarqué que nous avons sauté en créant une utilisation PSTN. C'est parce que nous allons utiliser celui qui a déjà été créé ("États-Unis et Canada").

Comme vous pouvez le voir dans la cmdlet ci-dessus, nous avons créé la route vocale pour notre emplacement de sauvegarde 2 "qui utilisera le même modèle de nombre. Toutefois, cela s'appliquera à la place à SBC3.contoso.com et SBC4.contoso.com. En outre, nous avons défini cela avec une priorité de "2" car il s'agit de notre site de sauvegarde. Donc, pour résumer, lorsqu'un utilisateur à qui est assignée une politique de voix qui inclut ces usages et qui inclut ces routes pour composer les numéros "+1425" ou "+1206", nous enverrons d'abord ces appels à SBC1 ou SBC2. Ce n'est que si SBC1 et SBC2 sont en panne que nous utiliserons alors la route de priorité 2 et enverrons les appels à SBC3 ou SBC4

Donc, cela fonctionne très bien si ces utilisateurs veulent composer les numéros +1425 ou +1206, mais qu'en est-il? voulait composer toute autre variation de nombres comme un numéro +1312 ou +1800? Eh bien, cela ne correspondrait à aucune des routes ici et cela pourrait être mauvais à moins d'ajouter une autre paire de SBC. Dans le scénario suivant, nous ajouterons 2 SBC supplémentaires (sbc5.contoso.com et sbc6.contoso.com) à notre centre de données de Chicago. Notre intention est d'avoir un autre numéro aux États-Unis et au Canada pour aller à nos SBC de Chicago. Pour ce faire, nous devrons commencer par associer les SBC à O365 comme nous l'avons fait auparavant.

New-CsOnlinePSTNGateway -FQDN sbc5.contoso.com -SipSignalingPort 5068 -Enabled $ true

New-CsOnlinePSTNGateway -FQDN sbc6.contoso.com -SipSignalingPort 5068 -Enabled $ true

Ensuite, nous allons construire une nouvelle route vocale. Dans ce cas, nous l'appellerons notre route "Autre +1" et le modèle de nombre sera plus large que nos modèles numériques assignés aux 1-4 de SBC. Comme vous le verrez dans l'applet de commande ci-dessous, le modèle de numéro commence par "+1" suivi de 10 chiffres.

New-CsOnlineVoiceRoute -Identity "Autre +1" -NumberPattern "^ + 1 ( d {10}) $ "-OnlinePstnGatewayList sbc5.contoso.com, sbc6.contoso.com -Priorité 3 -OnlinePSTNUages" États-Unis et Canada "

Donc, essentiellement tout nombre qui commence par +1 suivi de 10 chiffres ( par exemple, +13124567890) acheminera vers la liste de passerelle PSTN de sbc5.contoso.com ou sbc6.contoso.com, à condition qu'elle ne commence pas par +1425 ou +1206. Lorsqu'il y a plusieurs SBC dans la même liste de passerelle, les appels seront distribués en conséquence. Ce n'est que lorsque les deux SBC seront en panne que nous évaluerons une autre route.

Voici un scénario amusant. Supposons qu'un de vos utilisateurs essaie d'appeler un numéro +1425 mais pour une raison quelconque, tous les SBC de Redmond et Bellevue sont en panne (peut-être que votre stagiaire touche accidentellement quelque chose qu'il n'était pas censé ?). Si les 1-4 de SBC sont tous hors ligne et que l'utilisateur essaie d'appeler ce numéro +1425, il correspondra toujours à cette route vocale "Autre +1", de sorte que l'appel peut toujours utiliser SBC5 et SBC6 comme route de secours. Alors, prenez votre stagiaire, après tout, la meilleure façon d'apprendre est de faire des erreurs [

Donc, pour faire tout ce travail, vous pouvez vous rappeler que nous ne sommes pas en mesure d'attribuer directement les utilisateurs PSTN aux utilisateurs, donc nous doit créer une politique de routage vocal. Dans ce scénario, nous élaborons une politique de routage vocal appelée "US Only" et nous souhaitons que cette politique de routage vocal inclue l'utilisation de "US and Canada" et que ce conteneur / utilisation contienne les 3 routes (Redmond 1, Redmond 2, et Autre +1) comme vu dans le diagramme ci-dessous

Nous accorderons / affecterons la politique de routage vocal à l'utilisateur spécifié. Cela nous permettra de prendre la décision de routage appropriée pour l'utilisateur. La cmdlet ressemblera à celle ci-dessous

Grant-CsOnlineVoiceRoutingPolicy -Identity "Brian Siefferman" -PolicyName "US Only"

Supposons que nous ayons laissé la configuration pour cet utilisateur. Si Brian (oui je me réfère à moi à la 3ème personne :-P) voulait appeler quelqu'un en Allemagne (+49) pour exprimer sa frustration face à la défaite de l'Allemagne dans les phases de groupes de la Coupe du Monde 🙁 malheureusement, son appel échouerait En effet, il est possible de configurer un utilisateur avec le routage direct et le plan d'appel Si Brian avait un plan d'appel assigné qui incluait des fonctionnalités de numérotation internationale, nous pourrions Ensuite, essayez d'acheminer son appel via l'infrastructure Microsoft Calling Plan.

Aujourd'hui nous avons discuté d'une pléthore de scénarios où le routage direct serait utilisé et la configuration nécessaire qui devrait être en place pour réussir. de cette série de blogs "Routage direct pour les équipes Microsoft: Deep Dive", nous aborderons les migrations depuis le Cloud PBX avec les clients de Skype for Business, ainsi que les migrations depuis le serveur Lync / Skype for Business sur site. J'ai trouvé cela utile, et j'ai hâte de vous voir dans le dernier blog de cette série.