Teams: Local Media Optimization By Microsoft


Une des nouveautés dans l’environnement Teams consiste à mettre en place l’optimisation des flux TOIP (téléphonie sur IP) pour que ceux-ci soient acheminés au plus prêt du réseau téléphonique commuté. Acheminer les flux TOIP le plus rapidement possible est important pour d’une part conserver une bonne qualité audio et d’autre part respecter certaines obligations nationales.

One of the new features in the Teams environment is the optimization of TOIP (Telephony over IP) flows so that they are routed as close as possible to the switched telephone network. Routing the TOIP streams as quickly as possible is important in order to maintain good audio quality on the one hand, and to comply with certain national obligations on the other hand.

English version here

Dans ce premier article consacré a LMO voici la vision et les explications de Microsoft concernant le LMO. Document traduit de l’anglais consultable ici

. La voix sur le réseau téléphonique public commuté (RTPC) est considérée comme une application critique pour les entreprises, avec des attentes élevées en matière de qualité de la voix. Le routage direct vous permet de contrôler les flux de trafic média pour s’adapter à une multitude de topologies de réseau et de configurations de téléphonie locale pour diverses entreprises dans le monde entier.

L’optimisation des médias locaux appelé désormais LMO pour Local Media Optimization vous permet de gérer la qualité de la voix en

  • Contrôlant la façon dont le trafic média circule entre les clients Teams et les contrôleurs de session (SBC).
  • Maintenant le flux média dans les limites des sous-réseaux d’entreprise.
  • Autorisant les flux de médias entre les clients Teams et les SBC même si les SBC se trouvent derrière des pares-feux d’entreprise avec des IP privées et ne sont pas visibles directement par Microsoft.

L’optimisation des médias locaux (LMO) prend en charge deux scénarios :

  • La centralisation de tous les trunk Sip locaux par le biais d’un SBC centralisé connecté au Trunk SIP principal – fournissant des services de téléphonie à toutes les succursales locales de l’entreprise.
  • Création d’une topologie de réseau virtuel de SBC – où les SBC des succursales locales sont connectées à un SBC proxy centralisé qui est visible par le système téléphonique de Microsoft et communique avec lui par le biais de son adresse IP externe. Dans une topologie de réseau virtuel, les SBC en aval communiquent par le biais d’IP internes et ne sont pas directement visibles par le système téléphonique.

Cet article décrit par conséquent les fonctionnalités, ainsi que les scénarios et solutions pour les clients.

Scénarios Supportés

Dans cet exemple, supposons que la société Contoso gère plusieurs entreprises dans le monde entier comme suit. (Notez que l’Europe et les régions de l’APAC ne sont utilisées qu’à titre d’exemple. Une entreprise peut avoir plusieurs régions différentes avec des exigences similaires).

  • En Europe, Contoso a des bureaux dans environ 30 pays. Chaque bureau possède son propre autocommutateur privé (PBX).
  • Contoso s’est vu offrir la possibilité de centraliser les trunk en un seul endroit – Amsterdam – pour l’ensemble des 30 bureaux européens. Contoso a déployé le SBC à Amsterdam, a fourni suffisamment de bande passante pour faire passer les appels par le site centralisé, a connecté un trunk SIP central au site centralisé et a commencé à desservir tous les sites européens à partir d’Amsterdam.

En fonction de ses besoins commerciaux, Contoso a mis en œuvre deux solutions avec l’optimisation des médias locaux pour le routage direct :

En Europe, tous les trunk sont centralisés et les flux de médias entre le SBC central et les utilisateurs, en fonction de la localisation de l’utilisateur.

  • Si un utilisateur est connecté au sous-réseau local d’un réseau d’entreprise (c’est-à-dire que l’utilisateur est interne), le média circule entre l’IP interne du SBC central et le client Teams de l’utilisateur.
  • Si un utilisateur se trouve en dehors des limites du réseau d’entreprise (par exemple, s’il utilise une connexion Internet sans fil publique), il est alors considéré comme externe. Dans ce cas, le média circule entre l’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 le média entre l’interface de routage direct et les SBC en aval dans les succursales locales.

Les SBC en aval dans les succursales locales ne sont pas directement visibles par Direct Routing dans la région APAC, mais ils sont couplés en utilisant le cmdlet Set-CSOnlinePSTNGateway pour créer une topologie de réseau virtuel dans le système téléphonique de Microsoft. Les flux médias restent toujours locaux lorsque c’est possible. Les utilisateurs externes ont des médias qui circulent entre le client Teams et l’IP publique du proxy SBC.

Dans la région APAC, Contoso possède plusieurs bureaux dans différents pays.

Dans de nombreux pays, la société dispose encore de lignes de multiplexage temporel (TDM) dans ses succursales locales. La centralisation des lignes de multiplexage temporel n’est pas une option dans la région APAC, et le passage au SIP n’est donc pas possible. Supposons qu’il y ait plus de cinquante succursales de 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 d’interruptions locales d’Internet. En outre, certains pays imposent des exigences réglementaires qui ne peuvent être satisfaites sans disposer d’une connectivité au réseau PSTN local.

SBC central avec des Trunk centralisés

Pour mettre en place une solution où les services PSTN sont fournis à toutes les succursales locales par un seul SBC central avec un trunk SIP centralisé connecté, l’administrateur du Tenant de Contoso couple un SBC (centralsbc.contoso.com) au service ; le SBC a un trunk SIP centralisé qui lui est connecté.

  • Lorsqu’un utilisateur se trouve dans le réseau interne de l’entreprise, le SBC fournit l’IP interne du SBC pour les flux médias.
  • Lorsqu’un utilisateur se trouve en dehors du réseau de l’entreprise, le SBC fournit l’IP externe (publique) du SBC.

Remarque : toutes les valeurs figurant dans les exemples, les tableaux ou les diagrammes sont présentées à titre d’illustration uniquement.

Location

SBC FQDN

Internal subnet

External NAT (Trusted IP)

SBC external IP address

SBC internal IP address

     

Amsterdam

centralsbc.contoso.com

192.168.5.0/24

172.16.76.73

172.16.76.71

192.168.5.5

     

Germany

Not deployed

192.168.6.0/24

172.16.76.74

Not deployed

Not deployed

     

France

Not deployed

192.168.7.0/24

172.16.76.75

Not deployed

Not deployed

     

 

Utilisateur interne

Le schéma suivant montre le flux de trafic lorsqu’un utilisateur est connecté au réseau de l’entreprise dans sa succursale ou son site d’origine.

Lorsqu’il est sur place, l’utilisateur est affecté à la succursale locale en Allemagne. L’utilisateur passe un appel téléphonique à routage direct par l’intermédiaire de Teams.

  • Le client Teams de l’utilisateur communique directement avec le système téléphonique par l’intermédiaire de l’API REST, mais le média généré pendant l’appel est acheminé vers l’adresse IP interne du SBC central.
  • Le SBC redirige le flux vers le système téléphonique et le réseau RTPC connecté.
  • Le SBC central est visible pour le système téléphonique uniquement par l’intermédiaire de l’adresse IP externe.

Schéma 1. Flux de trafic lorsque l’utilisateur se trouve sur le site « d’origine » avec un SBC centralisé et avec un tronc SIP centralisé connecté

Diagramme montrant le flux de trafic Optimisation des médias locaux

Utilisateur externe

 

Le diagramme suivant montre le flux de trafic lorsqu’un utilisateur n’est pas dans les locaux et n’est pas connecté au réseau de l’entreprise (c’est-à-dire que l’appareil de l’utilisateur est connecté à l’internet par un appareil mobile ou un réseau Wi-Fi public). L’utilisateur passe un appel téléphonique par routage direct par l’intermédiaire des équipes :

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement par l’API REST, mais, dans ce cas, le média généré pendant l’appel est acheminé vers l’adresse IP externe du SBC central.
  • Le SBC redirige le flux vers le système téléphonique et le réseau PSTN connecté.
  • Le SBC central est visible pour le système téléphonique uniquement par l’intermédiaire de l’adresse IP externe.

 

Dans ce cas, le comportement est similaire que l’utilisateur soit local à la succursale en Allemagne ou à toute autre succursale. L’utilisateur est considéré comme externe parce qu’il se trouve en dehors des limites du réseau de l’entreprise.

Schéma 2. Flux de trafic lorsque l’utilisateur est externe avec un SBC centralisé et avec un tronc SIP centralisé connecté

SBC par procuration avec les SBC connectés en aval

Pour mettre en place une solution où les services PSTN sont fournis dans toutes les succursales locales de la région APAC où la centralisation des trunk TDM n’est pas une option, l’administrateur Contoso couple un SBC (proxysbc.contoso.com), également appelé le SBC proxy, au service de routage direct. (Direct routing)

Ensuite, l’administrateur Contoso ajoute quelques SBC en aval, indiquant qu’ils peuvent être atteints par le SBC proxy proxysbc.contoso.com. Les SBC en aval n’ont pas d’adresse IP publique, mais ils peuvent être affectés à des itinéraires vocaux. Le tableau ci-dessous présente des exemples de paramètres et de configuration de réseau.

Lorsqu’un utilisateur se trouve dans la succursale locale où se trouve le SBC en aval, le trafic Mé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 passe de l’utilisateur à l’IP publique du SBC mandataire, qui le transmet au(x) SBC en aval concerné(s).

SBC par procuration avec les SBC connectés en aval

Location

SBC FQDN

Internal subnet

External NAT (Trusted IP)

SBC external IP address

SBC internal IP address

Vietnam

VNsbc.contoso.com

192.168.1.0/24

172.16.240.110

None

192.168.1.5

Indonesia

IDsbc.contoso.com

192.168.2.0/24

172.16.240.120

None

192.168.2.5

Singapore

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 où un utilisateur se trouve à l’intérieur du bureau dans la région APAC. L’utilisateur, qui est affecté à un bureau local au Vietnam, et qui se trouve dans les locaux, passe un appel téléphonique de routage direct par l’intermédiaire de Teams

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement via l’API REST, mais le média généré pendant l’appel est acheminé vers l’adresse IP interne du SBC local.
  • Le SBC local redirige le flux vers le SBC proxy à Singapour et vers le réseau PSTN local connecté.
  • Le SBC proxy est visible pour le système téléphonique uniquement par l’adresse IP externe et redirige le flux du SBC en aval (dans ce cas, le SBC local au Vietnam) vers le système téléphonique.
  • Le SBC en aval dans la succursale locale n’est pas visible directement par le système téléphonique, mais il est mappé dans la topologie du réseau virtuel qui est 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 selon le mode d’optimisation des médias locaux configuré.

Pour plus d’informations sur les modes possibles et les comportements pertinents, voir Configurer l’optimisation des médias locaux.

Schéma 3. Flux de trafic lorsque l’utilisateur se trouve dans le réseau « domestique » avec un SBC proxy et avec des SBC connectés en aval

Utilisateur externe

 

Le schéma suivant montre le flux de trafic lorsqu’un utilisateur se trouve en dehors des limites du réseau de l’entreprise. L’utilisateur n’est pas dans les locaux (ne se trouve pas dans les limites du réseau d’entreprise). L’utilisateur passe un appel téléphonique en routage direct par l’intermédiaire des équipes vers un numéro de téléphone au Vietnam.

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement via l’API REST, mais le média généré pendant l’appel est d’abord acheminé vers l’adresse IP externe du proxy SBC à Singapour.
  • En fonction de la configuration et des politiques vocales (voir Configure Local Media Optimization pour plus de détails), 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 PSTN local connecté.
  • Le SBC proxy est visible par le système téléphonique uniquement via l’adresse IP externe.
  • Le SBC en aval dans la succursale locale n’est pas visible directement par le système téléphonique, mais il est mappé dans la topologie du réseau virtuel qui est 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 parce qu’il se trouve en dehors des limites du réseau d’entreprise.

Schéma 4. Flux de trafic lorsque l’utilisateur est externe avec un SBC proxy et avec des SBC connectés en aval

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 passera par l’adresse IP interne du SBC local en aval, quel que soit l’endroit où se trouve l’utilisateur interne, par exemple dans la même succursale où se trouve le SBC en aval ou dans une autre succursale.
  • Mode 2 : uniquement pour les utilisateurs locaux. Dans ce mode, le média sera directement transmis à l’adresse IP interne du SBC local en aval uniquement lorsqu’il est généré par l’utilisateur interne situé dans la même succursale que le SBC en aval.

Pour distinguer les modes d’optimisation des médias locaux, l’administrateur du locataire doit définir le paramètre -BypassMode sur « Toujours » ou « Seulement pour les utilisateurs locaux » pour chaque SBC en utilisant le cmdlet Set-CSonlinePSTNGateway. Pour plus d’informations, voir Configurer l’optimisation des médias locaux.

Mode 1 : Toujours contourner

Si vous avez une bonne connexion entre les succursales, le mode recommandé est « Toujours contourner ».

Par exemple, supposons qu’une entreprise dispose d’un Trunk SIP centralisé à Amsterdam, qui dessert 30 pays 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 « Always bypass ». Les utilisateurs, quel que soit leur emplacement, se connecteront directement au SBC via l’adresse IP interne du SBC (par exemple de la France vers l’Allemagne ; voir le schéma ci-dessous pour référence).

Deux scénarios sont décrits ci-après :

  • Scénario 1. L’utilisateur se trouve au même endroit que le SBC défini dans la politique d’acheminement de la 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 endroit que le SBC défini dans la politique d’acheminement de la voix en ligne

Le SBC d’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 deux SBC (proxy et aval) sont configurés pour le mode « Always Bypass ». Les politiques d’acheminement de la voix en ligne précisent qu’en cas d’appels en Allemagne (avec l’indicatif régional +49), ils doivent être acheminés vers le SBC local en Allemagne. Tous les autres appels – et en cas d’échec du SBC en Allemagne, les appels en Allemagne – doivent être acheminés vers le SBC proxy à Amsterdam. Le tableau suivant résume l’exemple de configuration.

Exemple de configuration pour le scénario 1

Scénario 1. L’utilisateur se trouve au même endroit que le SBC défini dans la politique d’acheminement de la voix en ligne

User physical location

L’utilisateur appelle un numéro

Online Voice Routing Policy

Mode configured for SBC

Media Flow

Germany

+49 1 437 2800

Priority 1: ^+49(\d{8})$ -DEsbc.contoso.com
Priority 2: .* – proxysbc.contoso.com

DEsbc.contoso.com – Always Bypass
proxysbc.contoso.com – Always Bypass

Teams User <–> DEsbc.contoso.com

 

Le diagramme ci-dessous montre le flux de trafic de haut niveau pour l’utilisateur interne en Allemagne qui passe un appel téléphonique de Direct Routing par l’intermédiaire de Teams au numéro en Allemagne.

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement par l’intermédiaire de l’API REST.
  • Le média généré lors de l’appel est acheminé vers l’adresse IP interne du SBC local.
  • Le SBC local redirige le flux vers le SBC proxy à Amsterdam et vers le réseau PSTN local connecté.
  • Le SBC proxy est visible pour le système téléphonique uniquement par l’adresse IP externe et redirige le flux du SBC en aval (dans ce cas, le SBC local en Allemagne) vers le système téléphonique.
  • Le SBC en aval dans la succursale locale n’est pas visible directement par le système téléphonique, mais il est mappé dans la topologie du réseau virtuel définie par l’administrateur Contoso lors de la configuration de l’optimisation des médias locaux.

Schéma 5. Flux de trafic avec le mode « Always Bypass » et l’utilisateur se trouve sur le site « home

Scénario 2 : l’utilisateur et les passerelles se trouvent sur des sites différents

Le SBC d’Amsterdam est configuré pour être un SBC proxy pour un SBC local en aval en Allemagne. Les deux SBC (proxy et aval) sont configurés pour le mode « Always Bypass ». L’utilisateur interne en France, situé dans la succursale locale, passe un appel de routage direct vers l’Allemagne. Les politiques d’acheminement de la voix en ligne précisent 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 – et, en cas d’échec de la SBC en Allemagne, tous les appels en Allemagne – doivent être acheminés vers la SBC mandataire à Amsterdam. Le tableau suivant résume l’exemple de configuration.

Tableau 4. Exemple de configuration pour le scénario 2

User physical location

User makes a call to a number

Online Voice Routing Policy

Mode configured for SBC

Media Flow

France

+49 1 437 2800

Priority 1: ^+49(\d{8})$ -DEsbc.contoso.com
Priority 2: .* – proxysbc.contoso.com

DEsbc.contoso.com – Always Bypass proxysbc.contoso.com – Always Bypass

Teams User <– > DEsbc.contoso.com

 

Le diagramme suivant montre le flux de trafic élevé lorsque l’utilisateur interne allemand situé en France passe un appel téléphonique de Direct Routing par l’intermédiaire des équipes au numéro en Allemagne.

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement par l’intermédiaire de l’API REST.
  • Le média généré pendant l’appel est directement acheminé vers le SBC dans l’adresse IP interne de l’Allemagne.
  • Le SBC en Allemagne redirige le flux vers le SBC proxy à Amsterdam et vers le réseau RTC local connecté.

 

Schéma 6. Flux de trafic avec le mode « Always Bypass » et l’utilisateur n’est pas dans son site « d’origine » mais dans le réseau interne

Mode 2 : uniquement pour les utilisateurs locaux

S’il existe de mauvaises connexions entre les succursales locales mais de bonnes connexions entre chaque succursale locale et le bureau régional, le mode recommandé est « Uniquement pour les utilisateurs locaux ».

Par exemple, dans la région APAC, supposons que Contoso possède plusieurs bureaux dans différents pays. Pour de nombreux pays, le passage au SIP n’est pas possible car l’entreprise dispose encore de Trunk dans de nombreuses succursales locales. La centralisation des Trunk TDM n’est pas une option dans la région APAC. En outre, il existe plus de cinquante succursales de Contoso dans la région APAC, avec des centaines de passerelles (SBC).

Pour mettre en place une solution dans laquelle les services PTSN sont fournis dans toutes les succursales locales de la région APAC où la centralisation des tronçons TDM n’est pas une option, l’administrateur Contoso a couplé un SBC régional à Singapour comme 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 le SBC régional de Singapour. Pour le SBC régional, l’administrateur choisit le mode « Always Bypass » et pour les SBC locaux en aval, l’administrateur choisit le mode « Only For Local Users ».

Deux scénarios sont décrits ci-après :

  • Scénario 1. L’utilisateur se trouve au même endroit que le SBC défini dans la politique d’acheminement de la 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 endroit que le SBC défini dans la politique d’acheminement de la voix en ligne

Supposons que le SBC de Singapour soit configuré pour être une SBC proxy pour les SBC locales en aval au Vietnam et en Indonésie. L’utilisateur se trouve au Vietnam au même endroit que la SBC locale. Les politiques de routage de la voix 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 – et, si le SBC au Vietnam échoue, les appels au Vietnam – doivent être acheminés vers le SBC proxy à Singapour. Le tableau suivant résume l’exemple de configuration.

Tableau 5. Exemple de configuration pour le mode « uniquement pour les utilisateurs locaux » Scénario 1

User physical location

User makes a call to a number

Online Voice Routing Policy

Mode configured for SBC

Media Flow

Vietnam

+84 4 3926 3000

Priority 1: ^+84(\d{9})$ -VNsbc.contoso.com
Priority 2: .* – proxysbc.contoso.com

VNsbc.contoso.com – Only For Local Users
proxysbc.contoso.com – Always Bypass

Teams User <–> VNsbc.contoso.com

 

Dans le schéma suivant, un utilisateur affecté à la succursale locale au Vietnam, lorsqu’il est sur place, passe un appel téléphonique à routage direct par l’intermédiaire des équipes.

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement par l’intermédiaire de l’API REST.
  • Le média généré pendant l’appel est transmis à l’adresse IP interne du SBC local.
  • Le SBC local redirige le flux vers le SBC proxy à Singapour et vers le réseau PSTN local connecté.
  • Le SBC proxy est visible pour le système téléphonique uniquement par l’adresse IP externe et redirige le flux du SBC en aval (dans ce cas, le SBC local au Vietnam) vers le système téléphonique.
  • Le SBC en aval dans la succursale locale n’est pas visible directement par le système téléphonique, mais il est représenté dans la topologie du réseau virtuel.

Diagramme 7. Flux de trafic avec le mode « Uniquement pour les utilisateurs locaux » et l’utilisateur est dans le site « d’origine

User physical location

User makes a call to a number

Online Voice Routing Policy

Mode configured for SBC

Media Flow

Indonesia

+84 4 3926 3000

Priority 1: ^+84(\d{9})$ -VNsbc.contoso.com
Priority 2: .* – proxysbc.contoso.com

VNsbc.contoso.com – Only For Local Users
proxysbc.contoso.com – Always Bypass

Teams User <–> proxysbc.contoso.com <–> VNsbc.contoso.com

Scénario 2. L’utilisateur et les passerelles se trouvent sur des sites différents

Supposons que la SBC de Singapour soit configurée pour être une SBC proxy pour les SBC locales en aval au Vietnam et en Indonésie. L’utilisateur interne en Indonésie, situé dans la succursale locale, effectue un appel de routage direct vers le Vietnam. Les politiques de routage de la 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 – et, en cas d’échec de la SBC au Vietnam, les appels vers le Vietnam – doivent être acheminés vers la SBC mandataire à Singapour. Le SBC proxy de Singapour est réglé sur le mode « Always Bypass », et le SBC local du Vietnam est réglé sur le mode « Only For Local Users ». Le tableau suivant résume l’exemple de configuration.

Tableau 6. Configuration de l’utilisateur

User physical location

User makes a call to a number

Online Voice Routing Policy

Mode configured for SBC

Media Flow

Indonesia

+84 4 3926 3000

Priority 1: ^+84(\d{9})$ -VNsbc.contoso.com
Priority 2: .* – proxysbc.contoso.com

VNsbc.contoso.com – Only For Local Users
proxysbc.contoso.com – Always Bypass

Teams User <–> proxysbc.contoso.com <–> VNsbc.contoso.com

 

Dans le schéma suivant, l’utilisateur interne, alors qu’il se trouve dans les locaux de la succursale indonésienne, passe un appel téléphonique à routage direct par l’intermédiaire des équipes vers un numéro au Vietnam.

  • Le client Teams de l’utilisateur communique avec le système téléphonique directement par l’intermédiaire de l’API REST.
  • Le média généré pendant l’appel est d’abord acheminé vers l’adresse IP interne du proxy SBC.
  • Le proxy SBC à Singapour redirige le flux vers l’adresse IP interne du SBC en aval au Vietnam et vers Phone System.
  • Le SBC en aval au Viêt Nam achemine le flux vers le réseau RTPC local connecté.
  • Le SBC mandataire est visible par le système téléphonique uniquement par l’intermédiaire de l’adresse IP externe.
  • Les SBC en aval dans les succursales locales ne sont pas visibles directement par le système téléphonique mais sont cartographiés dans la topologie du réseau virtuel.

Schéma 8. Flux de trafic en mode « uniquement pour les utilisateurs locaux », et l’utilisateur n’est pas dans son site « d’origine » mais dans le réseau interne

 

Votre commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s