Routage direct mars 2019 (partie 3 de 5)

Bienvenue à la troisième partie de notre série de blogs sur le routage direct! Dans cet article, nous aborderons les principes de base du routage vocal et comment planifier le routage direct. Cela dit, passons directement au premier sujet sur les plans de numérotation.

Plans de numérotation

Qu'est-ce qui donne aux utilisateurs d’Équipes la possibilité de composer un numéro de téléphone? Plans de numérotation bien sûr! Selon la manière dont vous composez un numéro de téléphone, le réseau PSTN souhaitera que le numéro soit composé dans un format spécifique. Que se passe-t-il si vous avez composé le numéro de téléphone d'une manière différente de celle acceptée par le réseau PSTN? Eh bien, vous l'avez probablement deviné, l'appel échouerait. Pas de peur cependant, c’est là que les plans de composition entrent en jeu. Avec le concept de normalisation des numéros de téléphone, tous les numéros de téléphone seront normalisés au format E.164 qui inclut un «+» puis l’indicatif international (pour un numéro américain, ce sera 1), puis l’indicatif régional et enfin le numéro local. Par exemple, +1555123456 serait un numéro situé aux États-Unis. Cela se comprend, les utilisateurs ne voudront pas composer cette longue chaîne de chiffres chaque fois qu’ils voudront appeler leur pizzeria préférée au coin de la rue. Heureusement, nous avons des plans de numérotation intégrés pour traiter ces types de scénarios dans lesquels le numéro sera normalisé au format E.164 «automatiquement»! Les équipes disposent déjà de règles intégrées pour les types de normalisation les plus courants. Toutefois, vous avez la possibilité de configurer des règles de normalisation personnalisées pouvant être utilisées dans des scénarios dans lesquels des appels à chiffres courts ont lieu (c'est-à-dire, en composant les numéros directement). Donc, si vous voulez appeler cette pizzeria au coin de la rue, vous pouvez configurer cette règle personnalisée pour gérer l'utilisateur qui compose simplement le numéro local et les équipes se rendront compte que vous essayez de composer un emplacement dans votre indicatif régional pour que seul le 123456 soit requis. par la personne qui compose le numéro. En outre, si certains de vos collègues ont l'habitude de composer simplement le numéro de poste d'un autre collègue, ils peuvent continuer à le faire avec les équipes si la règle personnalisée appropriée est en place. J'entrerai dans les détails des règles personnalisées pouvant être créées dans les équipes d'un futur blog, pour ceux d'entre vous qui sont intéressés:).

Notions de base sur le routage vocal

Donc, maintenant que nous savons que la normalisation des numéros est possible via plans de numérotation, voyons comment tout cela «automagiquement» se produit sur le back-end en discutant des bases du routage vocal. Disons que nous avons quelqu'un d'Allemagne qui appelle à quelqu'un aux États-Unis. L’utilisateur en Allemagne tente d’appeler la TFN (numéro sans frais) au 1-800-123-4567. La première vérification par le système téléphonique consistera à déterminer s'il existe ou non une stratégie de routage vocal pour cet utilisateur particulier. Si ce n'est pas le cas, cet utilisateur ne pourra pas utiliser le routage direct pour cet appel, il sera donc replié sur le plan d'appel. Si l'utilisateur n'a même pas de plan d'appel en place, l'appel échouera. Toutefois, si l'utilisateur possède un plan d'appel, le système téléphonique vérifie ensuite si un plan d'appel national ou un plan d'appel international a été attribué à l'utilisateur. Si l’utilisateur en Allemagne ne dispose que d’un plan d’appel national, cet appel échouera car il essaie de composer le numéro international. Si l'utilisateur allemand dispose toutefois d'un plan d'appel international, l'appel est traité correctement via le plan d'appel Microsoft. Revenons donc en arrière, mais cette fois-ci, disons que l’utilisateur a une politique de routage vocal en place. Dans ce scénario, l'utilisateur utilise la méthode de routage direct pour passer l'appel. Cette politique de routage vocal contient des éléments appelés «utilisations PSTN» qui sont évalués dans l’ordre et qui peuvent consister en plusieurs itinéraires. Ainsi, pour résumer ce scénario jusqu'à présent, le système téléphonique recherchera la règle de routage vocal et, le cas échéant, quelles sont les utilisations PSTN associées à cette politique. Si le système téléphonique utilise toutes les utilisations du PSTN et est incapable de trouver une correspondance, ce qui signifie que l'utilisateur ne dispose pas d'une stratégie de routage vocal lui permettant de composer ce numéro de téléphone, puis nous revenons à la vérification d'origine pour savoir si l'utilisateur a bien une licence de plan d’appel attribuée. À partir de là, il suivrait le même chemin que le scénario précédent et se terminerait avec succès, à condition que l'utilisateur dispose du plan d'appels approprié. En sauvegardant une fois de plus, si nous avions une correspondance dans la règle de routage vocal dans laquelle au moins un itinéraire correspond au modèle composé, l'appel sera acheminé via le SBC (contrôleur de session en bordure) de l'itinéraire. Chaque route peut avoir plusieurs SBC aux fins de répartition de la charge et de basculement. Si cela réussit, l'appel sera passé via le routage direct. Cependant, si tous les SBC étaient en panne (Dieu nous en préserve), l’appel échouera. Je sais que nous venons de couvrir beaucoup de choses en très peu de temps, alors voyons comment vous pouvez vous préparer correctement au routage direct.

Préparation du routage direct

En ce qui concerne le déploiement du routage direct, vous devez tenir compte de plusieurs éléments. Voici les étapes à prendre en compte lors de la préparation de Direct Routing:

1. Choisissez qui hébergera le SBC (hébergé par un partenaire ou autoproduit par lui-même)
2. Déterminez les licences dont vous avez besoin et attribuez-les de manière appropriée
3. Choisissez le fournisseur et le modèle SBC
4. Configurer le contournement de support
5. Configurer le nom de domaine complet
6. Configurer votre pare-feu
7. Déterminez si plusieurs SBC sont nécessaires et comment les configurer
8. Si vous êtes l'hôte dont vous aurez besoin pour déterminer comment héberger le SBC

SBC auto-déployé vs SBC hébergé

Le routage direct vous offre la possibilité de déployer le SBC vous-même ou de faire en sorte que quelqu'un l'héberge en votre nom. Les deux options présentent certains avantages et inconvénients que vous pourrez voir dans le tableau ci-dessous.

Comme vous pouvez le voir ci-dessus, l'un des principaux avantages du déploiement du SBC vous-même inclut la possibilité d’avoir un contrôle total sur le SBC, ce qui signifie que vous pouvez y apporter des modifications à tout moment. Toutefois, cela signifie également que vous êtes seul responsable de la configuration, des correctifs et de la maintenance du SBC. Cela signifie également que vous devrez bien sûr acheter le SBC lui-même. D'un autre côté, si vous choisissez d'héberger votre SBC, l'un des plus gros avantages consiste à ne pas avoir à acheter, gérer et héberger le SBC. Toutefois, cela signifiera également que vous ne contrôlerez plus la configuration de SBC et compliquerez également le modèle de support.

Note: Si vous choisissez une option Option hébergée Assurez-vous de bien comprendre la structure de coûts, le processus de support et l'architecture du partenaire avant de choisir votre partenaire préféré.

Conditions de licence

Si vous souhaitez exploiter le routage direct dans votre environnement, vous devez: assurez-vous d'avoir les licences appropriées. Premier. et avant tout, tous les utilisateurs auront besoin d'une licence Teams, quelles que soient les circonstances. S'ils souhaitent utiliser le routage direct avec les équipes Microsoft, ils auront également besoin d'une licence de système téléphonique (incluse avec E5 ou Add-on pour E1, E3 et E4). Si vous souhaitez donner à vos utilisateurs la possibilité d'appeler via le routage direct et via le plan d'appel (national / international), vous aurez également besoin d'une licence complémentaire à la licence du plan d'appel. Enfin, vous avez la possibilité d'ajouter une conférence audio à vos utilisateurs. Vous pouvez également ajouter des numéros PSTN à leurs invitations à une réunion afin que les participants puissent se connecter via le réseau PSTN. Veuillez noter que les licences de plan d’appel et de conférence audio sont considérées comme facultatives et que vous n’êtes pas obligé de posséder ces licences pour tirer parti des équipes.

Exigences du contrôleur de session en bordure (SBC)

En plus de la licence, vous aurez besoin d’un SBC certifié si vous envisagez d’utiliser Direct Routing dans votre environnement. Le SBC servira de composant qui connectera les équipes au prochain saut PSTN. Le prochain saut PSTN peut inclure un PBX tiers (Cisco, Avaya, Juniper, Mitel, etc.) ou une ligne téléphonique (SIP, T1, E1, etc.). Pour obtenir la liste complète des SBC certifiés, vous pouvez consulter ici . En ce qui concerne les exigences SBC, vous devez vous assurer que Microsoft peut communiquer avec votre SBC via le nom de domaine complet de votre SBC. Cela dit, vous devez disposer d’un nom de domaine complet pour que Microsoft puisse localiser et retrouver votre SBC. Il est essentiel que le domaine soit enregistré auprès de Microsoft (domaines ou sous-domaines autorisés [ NO “.onmicrosoft.com”). Par exemple, si Perficient.com est notre domaine, cela signifie que certains noms valides pour SBC peuvent inclure:

• sbc1.perficient.com
• noam.perficient.com
• ussbc1.perficient.com

Cependant , vous ne pourrez pas utiliser quelque chose comme:

• sbc1.perficient.onmicrsosoft.com
• noam.perficient.onmicrosoft.com
• ussbc1.perficient.onmicrosoft.com

Lorsque vous vous enregistrez ce domaine, vous pouvez trouver la documentation sur ce processus ici .

Remarque : pour enregistrer votre domaine, vous devez vous assurer d'avoir accès à l'administrateur Office 365. centre avec privilèges d'administrateur global

Certificats

Un certain nombre de certificats sont également nécessaires pour valider l'identité du SBC approuvé. Si vous n'avez qu'un seul SBC dans votre environnement, vous n'aurez qu'à mettre le nom du SBC dans le SN (nom du sujet) et vous serez prêt! Toutefois, si vous avez plusieurs SBC dans votre environnement, vous pouvez structurer vos certificats de l’une des manières suivantes:

Cas d’utilisation: Optimisation du coût du certificat

• Description: Si vous souhaitez associer plusieurs SBC ou les modifier fréquemment. Utilisation d'un certificat générique
  • SN – gw1.perficient.com
  • SAN – * .perficient.com

Cas d’utilisation: équilibre entre coût et sécurité

• Description: Votre entreprise ne modifie pas très souvent les passerelles.
  • SN – gw1.perficient.com
  • SAN – gw1.perficient.com, gw2.perficient.com, gw3.perficient.com, gw4.perficient.com

Remarque : Si vous décidez d'ajouter un autre point d'accès au mélange (gw5.perficient.com), vous devrez modifier votre certificat ou obtenir un nouveau certificat. Essentiellement, plus vous sécurisez votre SBC, moins vos options deviennent flexibles.

Cas d'utilisation: sécurité maximale

• Description: Votre entreprise souhaite attribuer à chaque passerelle son propre certificat.
  • SN – gw1.perficient.com
  • SAN – gw1.perficient.com

Pour obtenir une liste de toutes les autorités de certification prises en charge, veuillez consulter le lien ici .

Zones de connexion IP et conditions requises pour le port

Vous pensez peut-être que j'ai déjà mis mes plages de ports pour mon client Teams, alors ne devrais-je pas être prêt? Bien pensé, mais malheureusement faux… En résumé, le SBC doit communiquer avec différents noms de domaine complets et utiliser des ports différents de ceux de votre client Teams. Le SBC peut être configuré avec une adresse IP publique ou placé derrière un NAT. La signalisation SIP entre le SBC et le proxy SIP dans O365 utilisera TLS / SIP pour communiquer entre eux.

• De SIP Porxy -> SBC
  • Port source: 1024 – 65,535
  • Port de destination: défini sur SBC
• De SBC -> Proxy SIP
  • Source du port: définie sur SBC
  • 5061

Les supports ont le même principe que la signalisation, sauf que dans ce cas, le processeur de supports devra communiquer avec le SBC et inversement. Les supports entre le processeur multimédia dans O365 et SBC utiliseront UDP / SRTP pour communiquer entre eux.

• À partir du processeur multimédia -> SBC
  • Port source: 49 152 – 53 247
  • Port de destination: défini sur SBC
• De SBC -> Processeur multimédia
  • Port source: défini sur SBC
  • Port de destination: 49 152 – 53 247

Pour les plages IP, Microsoft fournit des noms de domaine complet (FQDN) et des adresses IP distincts pour chaque proxy SIP. Il existe des mandataires SIP situés dans 3 régions différentes du monde (Amérique, Europe et Asie). Les noms de domaine complets (FQDN) et IP de ces mandataires IP sont les suivants:

SIP Proxy

• Amérique
  • FQDN du gestionnaire de trafic
    • sip-du-a-us.pstnhub.microsoft.com
  • FQDN et IP de centres de données
    • sip-du-a-uswe2.pstnhub.microsoft.com – 52.114.148.0
    • sip-du-a-usea.pstnhub.microsoft.com – 52.114.132.46
• Europe
  • FQDN du gestionnaire de trafic
    • sip-du-a-euwe.pstnhub.microsoft.com – 52.114.75.24
    • sip-du-a-euno.pstnhub.microsoft.com – 52.114.76.76
• Asie
  • FQDN du gestionnaire de trafic
    • sip-du-a-asea.pstnhub.microsoft.com – 52.114.7.24
    • sip-du-a-asse.pstnhub.microsoft.com – 52.114.14.70

Remarque: Le SBC devra parler à tous les partenaires IP et FQDN de toutes les régions à des fins de redondance. Par conséquent, si vous ne parvenez pas à parler aux noms de domaine complets américains, vous vous retrouverez face aux noms de domaine complets européens ou asiatiques.

Processeur multimédia

Les processeurs multimédia ont une plage d'adresses IP spécifique sur laquelle vous aurez besoin pour permettre à votre SBC de parler. La plage d'adresses IP est la suivante:

• 52.112.0.0/14 (52.112.0.1 – 52.112.255.254)

Suppression de support

Facultatif, si vous souhaitez utiliser le contournement de support dans votre environnement, il existe un quelques ports extra et plages d'adresses IP. Notez l'accent mis sur «extra», ce qui signifie que vous devrez ouvrir les ports suivants ci-dessous, en plus de ceux mentionnés précédemment.

• • Relais de transport: 52.112.0.0/14 (52.112.0.1 – 52.112.255.254)
• Ports de supports (UDP / SRTP)
  • Du relais de transport -> SBC
    • Port source: 50 000 – 59 999
    • Port de destination: défini sur SBC
  • De SBC -> Relais de transport
    • Port source: défini sur SBC
    • Port de destination: 50 000 à 59 999
• Dérivation interne des supports
  • Autoriser l'épingle à cheveux pour les clients internes
• Contournement de support externe
  • SBC aura besoin des capacités supplémentaires de communication avec les relais de médias

Ceci conclut le blog d’aujourd’hui sur le routage direct Microsoft Teams. Dans le prochain blog, nous verrons comment exploiter plusieurs SBC dans votre environnement et comment gérer le routage direct. J'espère que vous avez trouvé cet article de blog utile et j'espère que vous accorderez bientôt le prochain!