Planifier l’optimisation des médias locaux pour le routage direct
La voix RTC (Public Switched Telephone Network) est considérée comme une application critique pour l’entreprise avec des attentes élevées en matière de qualité vocale. Le routage direct pour Téléphonie Microsoft Teams vous permet de contrôler les flux de trafic multimédia pour prendre en charge une multitude de topologies réseau et de configurations de téléphonie locale pour différentes entreprises du monde entier.
L’optimisation des médias locaux pour le routage direct vous permet de gérer la qualité de la voix en :
Contrôle de la façon dont le trafic multimédia circule entre les clients Teams et les contrôleurs de frontière de session (SBC) du client.
Maintenir les médias locaux dans les limites des sous-réseaux du réseau d’entreprise.
Autoriser les flux multimédias entre les clients Teams et les SBC, même si les SBC se trouvent derrière des pare-feu d’entreprise avec des adresses IP privées et ne sont pas directement visibles par Microsoft.
L’optimisation des médias locaux prend en charge deux scénarios :
Centralisation de toutes les jonctions locales via un SBC centralisé connecté à la jonction SIP (Session Initiation Protocol) main. Ce scénario fournit des services de téléphonie à toutes les succursales locales de l’entreprise.
Topologie de réseau virtuel de SBC. Dans ce scénario, les contrôleurs SBC des filiales locales sont connectés à un SBC proxy centralisé qui est visible et communique avec Téléphonie Teams via son adresse IP externe. Dans une topologie de réseau virtuel, les SBC en aval communiquent via des adresses IP internes et ne sont pas directement visibles par Téléphonie Teams.
Cet article décrit les fonctionnalités, ainsi que les scénarios et solutions des clients. Pour plus d’informations sur la configuration, consultez Configurer l’optimisation des médias locaux.
Remarque
Si vous souhaitez conserver les médias locaux dans les limites de votre intranet, l’optimisation des médias locaux est recommandée. Toutefois, si vous disposez déjà de Media Bypass et que vous utilisez uniquement les adresses IP publiques de vos SBC, vous n’avez pas besoin de passer à l’optimisation des médias locaux. Vous pouvez continuer à utiliser la déviation du trafic multimédia. Pour plus d’informations, consultez Planifier la déviation du trafic multimédia.
Pour plus d’informations sur les fournisseurs SBC qui prennent en charge l’optimisation des médias locaux, consultez Contrôleurs de frontière de session certifiés pour le routage direct.
Scénarios clients pris en charge
Pour cette discussion, supposons que Contoso gère plusieurs entreprises à travers le monde comme suit. (Notez que les régions Europe et APAC sont utilisées uniquement comme exemples. Une entreprise peut avoir plusieurs régions différentes avec des exigences similaires.)
En Europe, Contoso a des bureaux dans environ 30 pays/régions. Chaque bureau a son propre pbx (Private Branch Exchange).
Contoso a eu la possibilité de centraliser les tronçons dans un seul emplacement - Amsterdam - pour les 30 bureaux européens. Contoso a déployé le SBC à Amsterdam, fourni suffisamment de bande passante pour exécuter des appels via l’emplacement centralisé, connecté une jonction SIP centrale à l’emplacement centralisé et a commencé à servir tous les emplacements européens à partir d’Amsterdam.
Dans la région APAC, Contoso a plusieurs bureaux dans différents pays/régions.
Dans de nombreux pays/régions, l’entreprise a encore des jonctions de multiplexage de division temporelle (TDM) dans les succursales locales. La centralisation des jonctions TDM n’est pas une option dans la région APAC. Il n’est donc pas possible de passer à SIP. Supposons qu’il existe plus de 50 succursales Contoso dans la région APAC avec des centaines de passerelles (SBC). Dans ce scénario, il n’est pas possible de coupler toutes les passerelles à l’interface de routage direct en raison d’un manque d’adresses IP publiques et/ou de breakouts Internet locaux. En outre, certains pays/régions imposent des exigences réglementaires qui ne peuvent pas être respectées sans disposer d’une connectivité réseau RTC locale.
En fonction de ses besoins métier, Contoso a implémenté deux solutions avec l’optimisation des médias locaux pour le routage direct :
En Europe, toutes les jonctions sont centralisées et les flux multimédias entre le SBC central et les utilisateurs, en fonction de l’emplacement de l’utilisateur.
Si un utilisateur est connecté au sous-réseau local d’un réseau d’entreprise (autrement dit, l’utilisateur est interne), le média circule entre l’adresse IP interne du SBC central et le client Teams de l’utilisateur.
Si un utilisateur est en dehors des limites du réseau d’entreprise, par exemple, si l’utilisateur utilise une connexion Internet sans fil publique, l’utilisateur est considéré comme externe. Dans ce cas, le média circule entre l’adresse IP externe du SBC central et le client Teams.
Dans la région APAC, un SBC proxy centralisé est couplé à Microsoft Direct Routing, qui dirige les médias entre l’interface de routage direct et les SBC en aval dans les succursales locales.
Les SBC en aval dans les filiales locales ne sont pas directement visibles par le routage direct dans APAC, mais ils sont associés à l’aide de l’applet de commande Set-CSOnlinePSTNGateway pour créer une topologie de réseau virtuel dans Téléphonie Teams. Le média reste toujours local lorsque c’est possible. Les utilisateurs externes ont des médias circulant entre le client Teams et l’adresse IP publique du proxy SBC.
SBC central avec jonctions centralisées
Pour créer une solution où les services RTC sont fournis à toutes les succursales locales par le biais d’un SBC central unique avec une jonction SIP centralisée connectée, l’administrateur du locataire Contoso associe un SBC (centralsbc.contoso.com) au service. Un tronçon SIP centralisé est connecté au SBC.
Lorsqu’un utilisateur se trouve dans le réseau interne de l’entreprise, le SBC fournit l’adresse IP interne du SBC pour les médias.
Lorsqu’un utilisateur est en dehors du réseau d’entreprise, le SBC fournit l’adresse IP externe (publique) du SBC.
Remarque
Toutes les valeurs contenues dans des exemples, des tables ou des diagrammes sont présentées à des fins d’illustration uniquement.
Tableau 1. Exemples de paramètres réseau pour les SBC
| Lieu | Nom de domaine complet SBC | Sous-réseau interne | NAT externe (ADRESSE IP approuvée) | Adresse IP externe SBC | Adresse IP interne SBC |
|---|---|---|---|---|---|
| Amsterdam | centralsbc.contoso.com | 192.168.5.0/24 | 172.16.76.73 | 172.16.76.71 | 192.168.5.5 |
| Allemagne | Non déployé | 192.168.6.0/24 | 172.16.76.74 | Non déployé | Non déployé |
| France | Non déployé | 192.168.7.0/24 | 172.16.76.75 | Non déployé | Non déployé |
Utilisateur interne
Le diagramme suivant montre le flux de trafic lorsqu’un utilisateur est connecté au réseau d’entreprise dans la succursale ou le site de l’utilisateur.
En local, l’utilisateur est affecté à la succursale locale en Allemagne. L’utilisateur effectue un appel téléphonique de routage direct via Teams.
Le client Teams de l’utilisateur communique avec Téléphonie Teams directement via l’API REST, mais le média généré pendant l’appel est transmis à l’adresse IP interne du SBC central.
Le SBC redirige le flux vers Téléphonie Teams et le réseau RTC connecté.
Le SBC central est visible par Téléphonie Teams via l’adresse IP externe uniquement.
Diagramme 1. Flux de trafic lorsque l’utilisateur se trouve sur le site « d’accueil » avec un SBC centralisé et une jonction SIP centralisée connectée
Utilisateur externe
Le diagramme suivant montre le flux de trafic lorsqu’un utilisateur n’est pas local et n’est pas connecté au réseau d’entreprise (autrement dit, l’appareil de l’utilisateur est connecté à Internet via un appareil mobile ou un Wi-Fi public). L’utilisateur effectue un appel téléphonique de routage direct via Teams :
Le client Teams de l’utilisateur communique avec Téléphonie Teams directement via l’API REST, mais, dans ce cas, le média généré pendant l’appel circule vers l’adresse IP externe du SBC central.
Le SBC redirige le flux vers Téléphonie Teams et le réseau RTC connecté.
Le SBC central est visible par Téléphonie Teams via l’adresse IP externe uniquement.
Dans ce cas, le comportement est similaire, que l’utilisateur soit local de la succursale en Allemagne ou d’une autre succursale. L’utilisateur est considéré comme externe, car il se trouve en dehors des limites du réseau d’entreprise.
Diagramme 2. Flux de trafic lorsque l’utilisateur est externe avec un SBC centralisé et une jonction SIP centralisée connectée
Proxy SBC avec des SBC en aval connectés
Pour créer une solution où les services RTC sont fournis dans toutes les succursales locales de la région APAC où la centralisation des jonctions TDM n’est pas une option, l’administrateur contoso associe un SBC (proxysbc.contoso.com), également appelé SBC proxy, au service de routage direct.
Par la suite, l’administrateur contoso ajoute des SBC en aval, indiquant qu’ils sont accessibles via le proxy SBC proxysbc.contoso.com. Les SBC en aval n’ont pas d’adresses IP publiques ; Toutefois, ils peuvent être affectés à des itinéraires vocaux. Le tableau ci-dessous présente des exemples de paramètres réseau et de configuration.
Lorsqu’un utilisateur se trouve dans la succursale locale où se trouve le SBC en aval, le trafic multimédia circule directement entre l’utilisateur et le SBC local en aval. Si un utilisateur se trouve en dehors du bureau (sur un Internet public), le média circule de l’utilisateur vers l’adresse IP publique du SBC proxy, qui le proxy vers le ou les SBC en aval appropriés.
Tableau 2. Exemple d’informations réseau SBC
| Lieu | Nom de domaine complet SBC | Sous-réseau interne | NAT externe (ADRESSE IP approuvée) | Adresse IP externe SBC | Adresse IP interne SBC |
|---|---|---|---|---|---|
| Vietnam | VNsbc.contoso.com | 192.168.1.0/24 | 172.16.240.110 | Aucun | 192.168.1.5 |
| Indonésie | IDsbc.contoso.com | 192.168.2.0/24 | 172.16.240.120 | Aucun | 192.168.2.5 |
| Singapour | proxysbc.contoso.com | 192.168.3.0/24 | 172.16.240.130 | 172.16.240.133 | 192.168.3.5 |
Utilisateur interne
Le diagramme suivant montre le flux de trafic de haut niveau pour le scénario lorsqu’un utilisateur se trouve à l’intérieur du bureau dans la région APAC. L’utilisateur, qui est affecté à une succursale locale au Vietnam et qui se trouve localement, effectue un appel téléphonique de routage direct via Teams.
Le client Teams de l’utilisateur communique avec Téléphonie Teams directement par le biais de l’API REST, mais les médias générés pendant l’appel sont transmis à l’adresse IP interne du SBC local.
Le SBC local redirige le flux vers le SBC proxy à Singapour et vers le réseau RTC local connecté.
Le SBC proxy est visible par Téléphonie Teams via l’adresse IP externe uniquement et achemine le flux du SBC en aval (dans ce cas le SBC local au Vietnam) vers Téléphonie Teams.
Le SBC en aval dans la succursale locale n’est pas visible directement par Téléphonie Teams, mais il est mappé dans la topologie de réseau virtuel définie par l’administrateur Contoso lors de la configuration de l’optimisation des médias locaux.
Remarque
Le comportement peut être différent pour les utilisateurs locaux et les utilisateurs non locaux en fonction du mode d’optimisation des médias locaux configuré.
Pour plus d’informations sur les modes possibles et le comportement approprié, consultez Configurer l’optimisation des médias locaux.
Diagramme 3. Flux de trafic lorsque l’utilisateur se trouve sur le réseau « d’accueil » avec un SBC proxy et avec des SBC en aval connectés
Utilisateur externe
Le diagramme suivant montre le flux de trafic lorsqu’un utilisateur est en dehors des limites du réseau d’entreprise. L’utilisateur n’est pas local (n’est pas dans les limites du réseau d’entreprise). L’utilisateur effectue un appel téléphonique de routage direct via Teams vers un numéro de téléphone au Vietnam.
Le client Teams de l’utilisateur communique directement avec Téléphonie Teams via l’API REST, mais le média généré pendant l’appel est d’abord acheminé vers l’adresse IP externe du SBC proxy à Singapour.
En fonction de la configuration et des stratégies vocales (voir Configurer l’optimisation des médias locaux), le SBC proxy redirige le flux vers le SBC en aval au Vietnam.
Le SBC en aval au Vietnam redirige le flux vers le réseau RTC local connecté.
Le SBC proxy est visible par Téléphonie Teams via l’adresse IP externe uniquement.
Le SBC en aval dans la succursale locale n’est pas visible directement par Téléphonie Teams, mais il est mappé dans la topologie de réseau virtuel définie par l’administrateur Contoso lors de la configuration de l’optimisation des médias locaux. Dans l’exemple, l’utilisateur est considéré comme externe, car il se trouve en dehors des limites du réseau d’entreprise.
Diagramme 4. Flux de trafic lorsque l’utilisateur est externe avec un SBC proxy et avec des SBC en aval connectés
Modes d’optimisation des médias locaux
L’optimisation des médias locaux prend en charge deux modes :
Mode 1 : Toujours contourner. Dans ce cas, si l’utilisateur est interne, le média transite par l’adresse IP interne du SBC local en aval, quel que soit l’emplacement réel de l’utilisateur interne ; par exemple, dans la même succursale que celle où se trouve le SBC en aval ou dans une autre succursale.
Mode 2 : uniquement pour les utilisateurs locaux. Dans ce mode, les flux multimédias sont directement dirigés vers l’adresse IP interne du SBC en aval local uniquement lorsqu’ils sont générés par l’utilisateur interne situé dans la même succursale que le SBC en aval.
Pour faire la distinction entre les modes d’optimisation des médias locaux, l’administrateur client doit définir le paramètre -BypassMode sur « Always » ou « OnlyForLocalUsers » pour chaque SBC à l’aide de l’applet de commande Set-CSonlinePSTNGateway. Pour plus d’informations, consultez Configurer l’optimisation des médias locaux.
Remarque
Lorsque les utilisateurs sont internes, la connectivité multimédia entre l’utilisateur et le SBC via l’adresse IP interne est requise. Il n’y a pas de secours aux relais de transport public pour les médias dans ce cas, car le SBC fournira une adresse IP interne pour la connectivité multimédia.
Mode 1 : Toujours contourner
Si vous disposez d’une bonne connexion entre les succursales, le mode recommandé est Toujours contourner.
Par exemple, supposons qu’une entreprise dispose d’une jonction SIP centralisée à Amsterdam, qui dessert 30 pays/régions et dispose d’une bonne connectivité entre les 30 sites et les utilisateurs locaux. Il existe également une succursale en Allemagne où un SBC local est déployé.
Le SBC en Allemagne peut être configuré en mode « Toujours contourner ». Les utilisateurs, quel que soit leur emplacement, se connectent directement au SBC via l’adresse IP interne du SBC ; par exemple, de la France à l’Allemagne. Pour plus d’informations, consultez le diagramme ci-dessous.
Les éléments suivants décrivent deux scénarios :
Scénario 1. L’utilisateur se trouve au même emplacement que le SBC défini dans la stratégie de routage des voix en ligne.
Scénario 2. L’utilisateur et les passerelles se trouvent sur des sites différents.
Scénario 1. L’utilisateur se trouve au même emplacement que le SBC défini dans la stratégie de routage des voix en ligne
Le SBC à Amsterdam est configuré pour être un SBC proxy pour un SBC local en aval en Allemagne. L’utilisateur se trouve en Allemagne dans le même sous-réseau que le réseau d’entreprise du SBC local. Les SBC (proxy et aval) sont configurés pour le mode Always Bypass. Les stratégies de routage des voix en ligne spécifient que les appels en Allemagne (avec l’indicatif régional +49) doivent être acheminés vers le SBC local en Allemagne. Tous les autres appels doivent être routés vers le SBC proxy à Amsterdam. Toutefois, si le SBC en Allemagne échoue, les appels en Allemagne doivent également être acheminés vers le proxy SBC à Amsterdam. Le tableau suivant récapitule l’exemple de configuration.
Tableau 3. Exemple de configuration pour le scénario 1
| Emplacement physique de l’utilisateur | L’utilisateur passe un appel à un numéro | Stratégie de routage des voix en ligne | Mode configuré pour SBC | Flux multimédia |
|---|---|---|---|---|
| Allemagne | +49 1 437 2800 | Priorité 1 : ^+49(\d{8})$ -DEsbc.contoso.com Priorité 2 : .* - proxysbc.contoso.com |
DEsbc.contoso.com – Toujours contourner proxysbc.contoso.com – Toujours contourner |
Utilisateur <Teams :> DEsbc.contoso.com |
Le diagramme ci-dessous montre le flux de trafic de haut niveau pour l’utilisateur interne en Allemagne effectuant un appel téléphonique de routage direct via Teams vers le numéro en Allemagne.
Le client Teams de l’utilisateur communique directement avec Téléphonie Teams via l’API REST.
Le média généré pendant l’appel circule vers l’adresse IP interne du SBC local.
Le SBC local redirige le flux vers le SBC proxy à Amsterdam et vers le réseau RTC local connecté.
Le SBC proxy est visible par Téléphonie Teams via l’adresse IP externe uniquement et achemine le flux du SBC en aval (dans ce cas, le SBC local en Allemagne) vers Téléphonie Teams.
Le SBC en aval dans la succursale locale n’est pas visible directement par Téléphonie Teams, mais il est mappé dans la topologie de réseau virtuel définie par l’administrateur Contoso lors de la configuration de l’optimisation des médias locaux.
Diagramme 5. Flux de trafic en mode « Always Bypass » et l’utilisateur se trouve sur le site « d’accueil »
Scénario 2 : L’utilisateur et les passerelles se trouvent sur des sites différents
Le SBC à Amsterdam est configuré pour être un SBC proxy pour un SBC local en aval en Allemagne. Les SBC (proxy et aval) sont configurés pour le mode Always Bypass. L’utilisateur interne en France, situé dans la succursale locale, effectue un appel de routage direct vers l’Allemagne. Les stratégies de routage des voix en ligne spécifient que les appels vers l’Allemagne (avec l’indicatif régional +49) doivent être acheminés vers le SBC local en Allemagne. Tous les autres appels doivent être routés vers le SBC proxy à Amsterdam. Toutefois, si le SBC en Allemagne échoue, tous les appels en Allemagne doivent être routés vers le proxy SBC à Amsterdam. Le tableau suivant récapitule l’exemple de configuration.
Tableau 4. Exemple de configuration pour le scénario 2
| Emplacement physique de l’utilisateur | L’utilisateur passe un appel à un numéro | Stratégie de routage des voix en ligne | Mode configuré pour SBC | Flux multimédia |
|---|---|---|---|---|
| France | +49 1 437 2800 | Priorité 1 : ^+49(\d{8})$ -DEsbc.contoso.com Priorité 2 : .* - proxysbc.contoso.com |
DEsbc.contoso.com – Always Bypass proxysbc.contoso.com – Always Bypass | Utilisateur <Teams : > DEsbc.contoso.com |
Le diagramme suivant montre le flux de trafic de haut niveau lorsque l’utilisateur allemand interne situé en France effectue un appel téléphonique de routage direct via Teams au numéro en Allemagne.
Le client Teams de l’utilisateur communique directement avec Téléphonie Teams via l’API REST.
Le média généré pendant l’appel est directement dirigé vers le SBC dans l’adresse IP interne de l’Allemagne.
Le SBC en Allemagne redirige le flux vers le proxy SBC à Amsterdam et vers le réseau RTC local connecté.
Diagramme 6. Flux de trafic en mode « Toujours contourner » et l’utilisateur n’est pas sur le site « d’accueil », mais sur le réseau interne
Mode 2 : uniquement pour les utilisateurs locaux
S’il existe des connexions incorrectes entre les succursales locales, mais de bonnes connexions entre chaque succursale locale et la succursale régionale, le mode recommandé est « Uniquement pour les utilisateurs locaux ».
Par exemple, dans la région APAC, supposons que Contoso a plusieurs bureaux dans différents pays/régions. Pour de nombreux pays/régions, le passage à SIP n’est pas possible, car l’entreprise dispose toujours de jonctions TDM dans de nombreuses succursales locales. La centralisation des jonctions TDM n’est pas une option dans la région APAC. En outre, il existe plus de 50 succursales Contoso dans la région APAC avec des centaines de passerelles (SBC).
Pour créer une solution où les services RTC sont fournis dans toutes les succursales locales de la région APAC où la centralisation des jonctions TDM n’est pas une option, l’administrateur contoso associe un SBC régional à Singapour en tant que SBC proxy au service de routage direct. La connexion directe entre les succursales locales n’est pas bonne, mais il existe une bonne connexion entre chaque succursale locale et la SBC régionale à Singapour. Pour le SBC régional, l’administrateur choisit le mode « Always Bypass ». Pour les SBC en aval locaux, l’administrateur choisit le mode « Uniquement pour les utilisateurs locaux ».
Les éléments suivants décrivent deux scénarios :
Scénario 1. L’utilisateur se trouve au même emplacement que le SBC défini dans la stratégie de routage des voix en ligne
Scénario 2. L’utilisateur et les passerelles se trouvent sur des sites différents
Scénario 1. L’utilisateur se trouve au même emplacement que le SBC défini dans stratégie de routage vocal en ligne
Supposons que le SBC à Singapour est configuré pour être un SBC proxy pour les SBC en aval locaux au Vietnam et en Indonésie. L’utilisateur se trouve au Vietnam au même emplacement que le SBC local. Les stratégies de routage vocal en ligne spécifient que les appels au Vietnam (avec l’indicatif régional +84) doivent être acheminés vers le SBC local au Vietnam. Tous les autres appels doivent être routés vers le SBC proxy à Singapour. Toutefois, si le SBC au Vietnam échoue, les appels au Vietnam doivent être acheminés vers le proxy SBC à Singapour. Le tableau suivant récapitule l’exemple de configuration.
Tableau 5. Exemple de configuration pour le mode « Uniquement pour les utilisateurs locaux » Scénario 1
| Emplacement physique de l’utilisateur | L’utilisateur passe un appel à un numéro | Stratégie de routage des voix en ligne | Mode configuré pour SBC | Flux multimédia |
|---|---|---|---|---|
| Vietnam | +84 4 3926 3000 | Priorité 1 : ^+84(\d{9})$ -VNsbc.contoso.com Priorité 2 : .* - proxysbc.contoso.com |
VNsbc.contoso.com : uniquement pour les utilisateurs locaux proxysbc.contoso.com – Toujours contourner |
Utilisateur <Teams :> VNsbc.contoso.com |
Dans le diagramme suivant, un utilisateur affecté à la succursale locale au Vietnam, alors qu’il est en local, effectue un appel téléphonique de routage direct via Teams.
Le client Teams de l’utilisateur communique directement avec Téléphonie Teams via l’API REST.
Le média généré pendant les flux d’appel vers l’adresse IP interne du SBC local.
Le SBC local redirige le flux vers le SBC proxy à Singapour et vers le réseau RTC local connecté.
Le SBC proxy est visible par Téléphonie Teams via l’adresse IP externe uniquement et achemine le flux du SBC en aval (dans ce cas, le SBC local au Vietnam) vers Téléphonie Teams.
Le SBC en aval dans la filiale locale n’est pas visible directement par Téléphonie Teams, mais il est mappé dans la topologie du réseau virtuel.
Diagramme 7. Flux de trafic en mode « Uniquement pour les utilisateurs locaux » et l’utilisateur se trouve sur le site « accueil »
Scénario 2. L’utilisateur et les passerelles se trouvent sur des sites différents
Supposons que le SBC à Singapour est configuré pour être un SBC proxy pour les SBC en aval locaux au Vietnam et en Indonésie. L’utilisateur interne en Indonésie, situé dans la succursale locale, effectue un appel de routage direct au Vietnam. Les stratégies de routage des voix en ligne spécifient que les appels vers le Vietnam (avec l’indicatif régional +84) doivent être acheminés vers le SBC local au Vietnam. Tous les autres appels doivent être routés vers le SBC proxy à Singapour. Toutefois, si le SBC au Vietnam échoue, les appels au Vietnam doivent être acheminés vers le proxy SBC à Singapour. Le SBC proxy à Singapour est défini sur le mode « Always Bypass » et le SBC local au Vietnam est défini sur le mode « Uniquement pour les utilisateurs locaux ». Le tableau suivant récapitule l’exemple de configuration.
Tableau 6. Configuration utilisateur
| Emplacement physique de l’utilisateur | L’utilisateur passe un appel à un numéro | Stratégie de routage des voix en ligne | Mode configuré pour SBC | Flux multimédia |
|---|---|---|---|---|
| Indonésie | +84 4 3926 3000 | Priorité 1 : ^+84(\d{9})$ -VNsbc.contoso.com Priorité 2 : .* - proxysbc.contoso.com |
VNsbc.contoso.com : uniquement pour les utilisateurs locaux proxysbc.contoso.com – Toujours contourner |
Utilisateur <Teams –> proxysbc.contoso.com <–> VNsbc.contoso.com |
Dans le diagramme suivant, l’utilisateur interne, en local dans la succursale indonésienne, effectue un appel téléphonique de routage direct via Teams à un numéro au Vietnam.
Le client Teams de l’utilisateur communique directement avec Téléphonie Teams via l’API REST.
Média généré pendant les flux d’appels vers l’adresse IP interne du proxy SBC en premier.
Le SBC proxy à Singapour redirige le flux vers l’adresse IP interne du SBC en aval au Vietnam et vers Téléphonie Teams.
Le SBC en aval au Vietnam achemine le flux vers le réseau RTC local connecté.
Le SBC proxy est visible par Téléphonie Teams via l’adresse IP externe uniquement.
Les SBC en aval dans les filiales locales ne sont pas visibles directement par Téléphonie Teams, mais sont mappés dans la topologie de réseau virtuel.
Diagramme 8. Flux de trafic en mode « Uniquement pour les utilisateurs locaux » et l’utilisateur n’est pas sur le site « d’accueil », mais sur le réseau interne
Comportements connus
Voici une liste de comportements qui peuvent être observés lors de l’utilisation de l’optimisation des médias locaux.
| Comportements des produits | Remarques |
|---|---|
| Le client Teams n’est pas identifié comme interne lorsque l’adresse IP publique du client Teams correspond à la liste d’adresses IP approuvées du client, mais ne correspond pas au site réseau. | L’optimisation des médias locaux nécessite un site réseau correspondant pour chaque connexion établie à partir d’une adresse IP approuvée répertoriée. |
| L’utilisateur Teams met l’appel en attente. La musique est lue à l’extrémité RTC et l’optimisation des médias locaux fonctionne. L’utilisateur Teams reprend l’appel. L’appel à PSTN reprend, mais l’optimisation des médias locaux ne fonctionne pas et l’appel se poursuit via le SBC central (proxy). | Lorsqu’un utilisateur parse un appel pour lancer la musique en attente (MoH), il est remonté de 1 :1 à un appel multipartite par le contrôleur d’appel pour appeler le contrôleur multimédia et le processeur multimédia (servant de mixer AVMCU) par le biais duquel le moH atteint un utilisateur qui a été mis en attente. La réaffectation à un appel 1 :1 après la reprise de l’appel ne se produit jamais selon la conception. |
| Pendant qu’un appel est en cours d’établissement, l’utilisateur peut entendre le silence pendant quelques secondes. | Cela peut se produire dans certains cas en raison de la complexité de l’architecture d’optimisation des médias locaux, |
| Applications vocales (par exemple, standard automatique et file d’attente d’appels). | Les applications vocales peuvent être déployées dans un environnement avec LMO configuré. Toutefois, les appels impliquant des applications vocales ne sont pas optimisés pour l’optimisation des médias locaux. Au lieu de cela, ils transitent par le SBC proxy, à l’exception des transferts du standard automatique vers les utilisateurs d’optimisation des médias locaux. Dans ce cas, l’appel suit le chemin optimisé d’optimisation des médias locaux, car il s’agit d’un appel direct 1 :1. Pour Location-Based scénarios de routage, consultez Applications vocales (standard automatique ou file d’attente d’appels). |