Topologies des flux d’appels

Cet article décrit les topologies de flux d’appels Azure Communication Services et détaille la façon dont le trafic appelant est chiffré. Pour une présentation des flux d’appels Azure Communication Services, consultez Les internes de mise en réseau des appels.

Contexte

Concepts réseau

Avant de passer en revue les topologies de flux d’appels, il est utile de comprendre les termes utilisés par cet article.

Un réseau client contient tous les segments réseau que vous gérez. Le réseau client peut inclure des réseaux câblés et sans fil au sein de votre bureau ou entre bureaux, centres de données et fournisseurs de services Internet.

Un réseau client a généralement plusieurs périmètres réseau avec des pare-feu ou des serveurs proxy qui appliquent les stratégies de sécurité de votre organisation. Nous vous recommandons d’effectuer une évaluation réseau complète pour obtenir les performances et la qualité optimales de votre solution de communication.

Le réseau Azure Communication Services est le réseau qui prend en charge Azure Communication Services. Microsoft gère ce réseau et le distribue dans le monde entier avec les centres de données appartenant à Microsoft qui sont les plus proches des clients finaux. Ce réseau est responsable du relais de transport, du traitement multimédia pour les appels de groupe et d’autres composants qui prennent en charge les communications multimédias riches et en temps réel.

Types de trafic

Azure Communication Services repose principalement sur deux types de trafic : les médias et les signalisations en temps réel.

Le média en temps réel est transmis via Real-Time protocole RTP (Transport Protocol). Ce protocole prend en charge la transmission de données audio, vidéo et de partage d’écran. Ces données sont sensibles aux problèmes de latence réseau. Bien qu’il soit possible de transmettre des supports en temps réel à l’aide de TCP ou HTTP, nous vous recommandons d’utiliser le protocole UDP (User Datagram Protocol) comme protocole de couche de transport pour prendre en charge les expériences utilisateur final hautes performances. Les charges utiles multimédias transmises via RTP sont sécurisées via le protocole SRTP (Secure RTP).

Les utilisateurs de votre solution Azure Communication Services se connectent à vos services à partir de leurs appareils clients. La signalisation gère la communication entre ces appareils et vos serveurs. Par exemple, la signalisation entre les appareils et votre service prend en charge l’initiation des appels et la conversation en temps réel. La plupart du trafic de signalisation utilise HTTPS REST. Dans certains scénarios, vous pouvez utiliser le protocole SIP (Session Initiation Protocol) comme protocole de signalisation du trafic. Bien que ce type de trafic soit moins sensible à la latence, la signalisation à faible latence offre une expérience agréable de l’utilisateur final.

Chiffrement multimédia

Les flux d’appels dans Azure Communication Services qui appellent des clients SDK et Teams sont basés sur l’offre RFC RFC 8866 (SDP) RFC 8866 sur HTTPS. Lorsque l’appelé accepte un appel entrant, l’appelant et l’appelé acceptent les paramètres de session.

Le trafic multimédia est chiffré et les flux entre l’appelant et l’appelé via SRTP, un profil de RTP qui fournit la protection contre les attaques de confidentialité, d’authentification et de relecture au trafic RTP. Dans la plupart des cas, le trafic multimédia client-à-client est négocié via la signalisation de connexion client à serveur et est chiffré via SRTP lors de l’passage directement du client au client.

Les instances Azure Communication Services qui appellent des clients sdk utilisent Datagram Transport Layer Security (DTLS) pour dériver une clé de chiffrement. Une fois la négociation DTLS terminée, le média commence à transiter par cette clé de chiffrement négociée par DTLS via SRTP.

Les instances Azure Communication Services qui appellent le Kit de développement logiciel (SDK) et les clients Teams utilisent un jeton basé sur des informations d’identification pour un accès sécurisé aux relais multimédias via TURN. Les relais multimédias échangent le jeton sur un canal sécurisé TLS (Transport Layer Security).

Le trafic multimédia qui se trouve entre deux points de terminaison qui participent au partage audio, vidéo et vidéo Azure Communication Services utilise SRTP pour chiffrer le flux multimédia. Les clés de chiffrement sont négociées entre les deux points de terminaison sur un protocole de signalisation, qui utilise un canal UDP/TCP chiffré tls 1.2 et AES-256 (en mode GCM).

Principes de flux d’appels

Il existe quatre principes généraux qui sous-tendent les flux d’appels Azure Communication Services :

• Le premier participant d’un appel de groupe Azure Communication Services détermine la région dans laquelle l’appel est hébergé. Il existe des exceptions à cette règle dans certaines topologies, que vous trouverez plus loin dans cet article.

• Le point de terminaison multimédia utilisé pour prendre en charge un appel Azure Communication Services est sélectionné en fonction des besoins de traitement multimédia et n’est pas affecté par le nombre de participants sur un appel.

  Par exemple, un appel point à point peut utiliser un point de terminaison multimédia dans le cloud pour traiter les médias pour la transcription ou l’enregistrement. Un appel avec deux participants peut ne pas utiliser de points de terminaison multimédias. Les appels de groupe utilisent un point de terminaison multimédia à des fins de mixage et de routage.

  Ce point de terminaison est sélectionné en fonction de la région dans laquelle l’appel est hébergé. Le trafic multimédia envoyé d’un client au point de terminaison multimédia peut être acheminé directement. Ou bien, il peut utiliser un relais de transport dans Azure si des restrictions de pare-feu réseau client l’exigent.

• Le trafic multimédia pour les appels d’égal à égal prend l’itinéraire le plus direct disponible, en supposant que l’appel n’a pas besoin d’un point de terminaison multimédia dans le cloud.

  L’itinéraire préféré est direct vers l’homologue distant (client). Si un itinéraire direct n’est pas disponible, un ou plusieurs relais de transport transfèrent le trafic. Le trafic multimédia ne doit pas traverser les serveurs qui agissent comme des modélisateurs de paquets ou des serveurs de réseau privé virtuel (VPN), ou remplir d’autres fonctions susceptibles de retarder le traitement et de dégrader l’expérience de l’utilisateur final.

• Le trafic de signalisation passe toujours au serveur le plus proche de l’utilisateur.

Pour plus d’informations sur les chemins multimédias, consultez la documentation conceptuelle sur les flux d’appels.

Flux d’appels dans plusieurs topologies

Azure Communication Services (Internet)

Cet exemple de topologie de flux d’appels illustre les clients qui utilisent Azure Communication Services à partir du cloud sans déploiement local, comme le routage direct Azure. Dans cette topologie, le trafic vers et à partir d’Azure Communication Services transite sur Internet.

La direction des flèches du diagramme précédent reflète la direction de la communication initiale qui affecte la connectivité au niveau des périmètres d’entreprise. Pour les supports UDP, les premiers paquets peuvent circuler dans la direction inverse, mais ces paquets peuvent être bloqués jusqu’à ce que les paquets circulent dans l’autre sens.

Descriptions de flux

• Flux 2 : représente un flux initié par un utilisateur sur le réseau client vers Internet dans le cadre de l’expérience Azure Communication Services de l’utilisateur. La transmission multimédia d’homologue à homologue et DNS sont des exemples de ce type de flux.
• Flow 2' : représente un flux initié par un utilisateur Azure Communication Services mobile distant avec VPN vers le réseau client.
• Flux 3 : représente un flux initié par un utilisateur Azure Communication Services mobile distant vers des points de terminaison Azure Communication Services.
• Flux 4 : représente un flux initié par un utilisateur sur le réseau client vers Azure Communication Services.
• Flux 5 : représente un flux multimédia pair à pair entre un utilisateur Azure Communication Services et un autre au sein du réseau client.
• Flux 6 : représente un flux multimédia d’égal à égal entre un utilisateur Azure Communication Services mobile distant et un autre utilisateur Azure Communication Services mobile distant via Internet.

Cas d’usage : appel un-à-un

Un appel un-à-un signifie qu’un utilisateur appelle directement un autre utilisateur. Pour initialiser l’appel, le SDK appelant obtient un ensemble de candidats qui se composent d’adresses IP et de ports. Cet ensemble comprend les candidats locaux, relais et réflexifs (adresse IP publique du client comme indiqué par le relais). Le Kit de développement logiciel (SDK) appelant envoie ces candidats à la partie appelée. Le parti appelé reçoit un ensemble similaire de candidats et les envoie à l’appelant.

Le système utilise les messages de vérification de la connectivité STUN pour rechercher les chemins d’accès multimédias tiers/appelants, puis sélectionne le meilleur chemin de travail. Une fois que le système a établi le chemin de connexion, il effectue une liaison DTLS sur la connexion pour garantir la sécurité. Après l’établissement d’une liaison DTLS, le système dérive les clés SRTP du processus d’établissement d'une liaison DTLS. Les supports (paquets RTP/RTCP sécurisés via SRTP) sont ensuite envoyés via la paire candidate sélectionnée. Le relais de transport est disponible dans le cadre d’Azure Communication Services.

Si l’adresse IP locale et les candidats de port ou les candidats réflexifs ont une connectivité, le chemin direct entre les clients (ou si vous utilisez une nat) est sélectionné pour les médias. Si les clients se trouvent tous deux sur le réseau client, le chemin direct doit être sélectionné. Cette sélection nécessite une connectivité UDP directe au sein du réseau client. Si les clients sont tous deux des utilisateurs nomades du cloud, alors en fonction du NAT/pare-feu, les médias peuvent utiliser une connectivité directe.

Si un client est interne sur le réseau client et qu’un client est externe (par exemple, un utilisateur cloud mobile), il est peu probable que la connectivité directe entre les candidats locaux ou réflexifs soit activée. Dans ce cas, vous pouvez utiliser l’un des candidats relais de transport à partir de l’un des clients. Par exemple, le client interne a obtenu un candidat relais à partir du relais de transport dans Azure, et le client externe doit être en mesure d’envoyer des paquets STUN/RTP/RTCP au relais de transport. Une autre option est que le client interne envoie au candidat relais obtenu par le client cloud mobile. Bien que nous recommandons vivement la connectivité UDP pour les médias, TCP est pris en charge.

Étapes de haut niveau

1. L’utilisateur Azure Communication Services A résout le nom de domaine d’URL (DNS) à l’aide de Flow 2.

2. L’utilisateur A alloue un port de relais multimédia sur le relais de transport Teams à l’aide du flux 4.

3. L’utilisateur A envoie une invitation avec les candidats ICE (Interactive Connectivity Establishment) à l’aide de Flow 4 vers Azure Communication Services.

4. Azure Communication Services avertit l’utilisateur B à l’aide de Flow 4.

5. L’utilisateur B alloue un port de relais multimédia sur le relais de transport Teams à l’aide du flux 4.

6. L’utilisateur B envoie une réponse avec les candidats ICE à l’aide de Flow 4, qui est transféré à l’utilisateur A à l’aide de Flow 4.

7. L’utilisateur A et l’utilisateur B appellent les tests de connectivité ICE et le meilleur chemin multimédia disponible est sélectionné. Passez en revue les diagrammes suivants pour voir différents cas d’usage.

8. Les deux utilisateurs envoient des données de télémétrie à Azure Communication Services à l’aide de Flow 4.

Réseau client (intranet)

À l’étape 7, le flux multimédia d’égal à égal 5 est sélectionné.

Cette transmission multimédia est bidirectionnelle. La direction du flux 5 indique qu’une partie initie la communication dans une optique de connectivité. Dans ce cas, il n’importe pas quelle direction est utilisée, car les deux points de terminaison se trouvent dans le réseau client.

Réseau client à un utilisateur externe (média relayé par le relais de transport Teams)

À l’étape 7, Flow 4 (du réseau client vers Azure Communication Services) et Flow 3 (d’un utilisateur Azure Communication Services mobile distant vers Azure Communication Services) sont sélectionnés.

Le relais de transport Teams gère ces flux dans Azure.

Cette transmission multimédia est bidirectionnelle. La direction indique quel côté lance la communication du point de vue de la connectivité. Dans ce cas, ces flux sont utilisés pour la signalisation et les médias, et ils utilisent différents protocoles et adresses de transport.

Du réseau client vers un utilisateur externe (transmission multimédia directe)

À l’étape 7, Flow 2 (du réseau client à l’homologue du client sur Internet) est sélectionné.

Le média direct avec un utilisateur mobile distant (non relayé via Azure) est facultatif. En d’autres termes, vous pouvez bloquer ce chemin pour appliquer un chemin multimédia via un relais de transport dans Azure.

Cette transmission multimédia est bidirectionnelle. La direction de Flow 2 vers l’utilisateur mobile distant indique qu’un côté lance la communication du point de vue de la connectivité.

Utilisateur VPN vers un utilisateur interne (média relayé par le relais de transport Teams)

La signalisation entre le VPN et le réseau client utilise Flow 2'. La signalisation entre le réseau client et Azure utilise Flow 4. Toutefois, le média contourne le VPN et est routé via Flow 3 et 4 via Azure Media Relay.

D’un utilisateur VPN vers un utilisateur interne (transmission multimédia directe)

La signalisation entre le VPN et le réseau client utilise Flow 2'. La signalisation entre le réseau client et Azure utilise Flow 4. Toutefois, les médias contournent le VPN et sont acheminés via Flow 2 du réseau client vers Internet.

Cette transmission multimédia est bidirectionnelle. La direction de Flow 2 vers l’utilisateur mobile distant indique qu’un côté lance la communication du point de vue de la connectivité.

D’un utilisateur VPN vers un utilisateur externe (transmission multimédia directe)

La signalisation entre l’utilisateur VPN et le réseau client utilise Flow 2' et Flow 4 vers Azure. Toutefois, les médias contournent le VPN et sont routés via Flow 6.

Cette transmission multimédia est bidirectionnelle. La direction de Flow 6 vers l’utilisateur mobile distant indique qu’un côté lance la communication du point de vue de la connectivité.

Cas d’usage : client Azure Communication Services vers RTC via une jonction Azure Communication Services

Azure Communication Services permet de placer et de recevoir des appels à partir du réseau téléphonique commuté public (PSTN). Si la jonction RTC est connectée via des numéros de téléphone fournis par Azure Communication Services, il n’existe aucune configuration de connectivité particulière pour ce cas d’usage. Si vous souhaitez connecter votre propre jonction RTC locale à Azure Communication Services, vous pouvez utiliser le routage direct Azure.

Dans ce cas, la signalisation et les médias du réseau client vers Azure utilisent Flow 4.

Cas d’usage : appels de groupe Azure Communication Services

Le service qui fournit le partage audio, vidéo et d’écran fait partie d’Azure Communication Services. Il a une adresse IP publique qui doit être accessible à partir du réseau client et d’un client cloud nomade. Chaque client et point de terminaison doit être en mesure de se connecter au service.

Les clients internes obtiennent des candidats locaux, réflexifs et relais de la même manière que pour les appels un-à-un. Les clients envoient ces candidats au service dans une invitation. Le service n’utilise pas de relais, car il a une adresse IP accessible publiquement, de sorte qu’il répond avec son candidat d’adresse IP locale. Le client et le service vérifient la connectivité de la même manière que celle décrite pour les appels un-à-un.

Restrictions d’interopérabilité

Les médias qui circulent via Azure Communication Services sont limités comme suit :

• Contrôleur de frontière de session tiers (SBC) : un SBC sur la limite avec RTC doit mettre fin au flux RTP/RTCP, sécurisé via SRTP et ne pas le relayer au tronçon suivant. Si vous relayez le flux au tronçon suivant, il est possible qu’il ne soit pas compris.

• Serveurs proxy SIP tiers : une boîte de dialogue SIP signalant Azure Communication Services avec un SBC tiers et/ou une passerelle peut traverser des proxys SIP natifs Microsoft (comme Teams). L’interopérabilité avec des proxys SIP tiers n’est pas prise en charge.

• B2BUA (ou SBC) tiers : un SBC tiers met fin à ces flux multimédias Azure Communication Services vers et depuis le RTC. L’interopérabilité avec un SBC tiers au sein du réseau Azure Communication Services (dans lequel un SBC tiers médiate deux points de terminaison Azure Communication Services) n’est pas prise en charge.

Technologies non prises en charge

• VPN : Azure Communication Services ne prend pas en charge la transmission multimédia sur les VPN. Si vos utilisateurs utilisent des clients VPN, le client doit fractionner et router le trafic multimédia sur une connexion non VPN, comme spécifié dans l’activation du média Lync pour contourner un tunnel VPN.

  Remarque

  Bien que le titre indique Lync, il s’applique à Azure Communication Services et Teams.

• Les modélisateurs de paquets : les appareils de mise en forme de paquets, d’inspection des paquets ou de mise en forme de paquets ne sont pas pris en charge et peuvent dégrader considérablement la qualité.

Étape suivante

Contenu connexe

• En savoir plus sur les types d’appels.
• Découvrez l’architecture client-serveur.