Éléments internes des réseaux d’appel

L’article décrit les flux d’appels dans Azure Communication Services. La signalisation et les flux multimédias dépendent des types d’appels que vos utilisateurs effectuent. Parmi les types d’appels, citons les appels individuels VoIP, les appels individuels du réseau téléphonique commuté public (PSTN) et les appels de groupe contenant une combinaison de participants connectés en VoIP et PSTN. Pour plus d’informations, consultez Types d’appels.

Protocoles de signalisation et de média

Lorsque vous établissez un appel d’égal à égal ou de groupe, deux protocoles sont utilisés en arrière-plan : HTTPS (REST) pour la signalisation et le protocole SRTP (Secure Real-time Transport Protocol) pour les médias.

La signalisation entre les kits SDK ou entre les kits SDK et les contrôleurs de signalisation Communication Services est gérée avec HTTPS REST (TLS). Azure Communication Services utilise TLS 1.2. Pour le trafic multimédia en temps réel (RTP), nous vous recommandons le protocole UDP (User DataGram Protocol). Si le pare-feu empêche l’utilisation d’UDP, le Kit de développement logiciel (SDK) utilise le protocole de contrôle de transmission (TCP) pour les médias.

Examinons les protocoles de signalisation et de média dans différents scénarios.

Cas de flux d’appels

Cas 1 : VoIP avec une connexion directe entre deux appareils

Dans les appels VoIP ou vidéo d’un à un, le trafic préfère le chemin le plus direct. Le chemin direct signifie que si deux kits SDK peuvent se joindre directement, ils établissent une connexion directe. Le chemin direct est possible lorsque deux SDKs se trouvent dans le même sous-réseau (par exemple, dans un sous-réseau 192.168.1.0/24) ou lorsque les deux appareils se trouvent dans des sous-réseaux qui sont en communication (les SDKs dans les sous-réseaux 10.10.0.0/16 et 192.168.1.0/24 peuvent se connecter entre eux).

Cas 2 : VoIP dans lequel une connexion directe entre les appareils n’est pas possible, mais une connexion entre les appareils NAT est possible

Si deux appareils se trouvent dans des sous-réseaux qui ne peuvent pas se joindre les uns aux autres, mais que la connexion entre les appareils nat (Network Address Translation) est possible, les kits SDK côté client établissent une connectivité via des appareils NAT. Par exemple, si Alice travaille à partir d’un café et bob travaille à partir d’un bureau à domicile.

Pour Alice, c’est la NAT du café et pour Bob c’est la NAT du bureau à domicile. L’appareil d’Alice envoie l’adresse externe de son NAT et Bob fait de même. Les SDK apprennent les adresses externes à partir des utilitaires de traversée de session pour le NAT (STUN) qu'Azure Communication Services fournit gratuitement. La logique qui gère le processus de poignée de main entre Alice et Bob est intégrée dans les SDK fournis par Azure Communication Services. Vous n’avez pas besoin d’une configuration ajoutée.

Cas 3 : VoIP dans lequel ni une connexion directe ni NAT n'est possible

Si un ou les deux appareils clients se trouvent derrière une NAT symétrique, un service cloud distinct est requis pour relayer le média entre les deux kits SDK. Ce service est appelé transit via des relais NAT (TURN) et est également fourni par les Services de Communication Azure. Le Kit de développement logiciel (SDK) Communication Services Calling utilise automatiquement les services TURN en fonction des conditions réseau détectées. Les frais TURN sont inclus dans le prix de l’appel.

Cas 4 : Appels de groupe avec RTPC

La signalisation et les médias pour les appels PSTN utilisent la ressource de téléphonie des Azure Communication Services. Cette ressource est interconnectée avec d’autres opérateurs.

Le trafic média du réseau téléphonique commuté (RTC) transite par un processeur de média.

Pour les appels de groupe, les médias et les signalisations circulent toujours via le serveur principal Azure Communication Services. L’audio et/ou la vidéo de tous les participants sont mélangés dans le processeur multimédia. Tous les membres d’un appel de groupe envoient leurs flux audio et vidéo au processeur multimédia, qui retourne des flux multimédias mixtes.

Le protocole RTP (Real-Time Protocol) par défaut pour les appels de groupe est le protocole UDP (User DataGram Protocol).

Si le Kit de développement logiciel (SDK) ne peut pas utiliser UDP pour les médias en raison de restrictions de pare-feu, il tente d’utiliser le protocole TCP (Transmission Control Protocol). Le composant processeur multimédia nécessite UDP. Dans ce cas, le service COMMUNICATION Services TURN est ajouté à l’appel de groupe pour traduire TCP en UDP. Les frais TURN sont inclus dans le prix de l’appel.

Cas 5 : Kit de développement logiciel (SDK) Communication Services et Microsoft Teams dans une réunion Teams planifiée

La signalisation transite par le contrôleur de signalisation. Le média transite par le processeur multimédia. Le contrôleur de signalisation et le processeur multimédia sont partagés entre Communication Services et Microsoft Teams.

Cas 6 : Médias précoces

Fait référence aux médias échangés, tels que l’audio et la vidéo, avant l’acceptation de la session par l’appelé. Pour le flux multimédia précoce, le contrôleur de bordure de session (SBC) doit se connecter au premier point de terminaison qui démarre le streaming multimédia ; le flux multimédia peut commencer avant que les candidats ne soient nommés. SBC doit prendre en charge l’envoi à double tonalité multi-fréquence (DTMF) pendant cette phase pour activer les scénarios de messagerie vocale/réponse vocale interactive (IVR). SBC doit utiliser le chemin d’accès de priorité le plus élevé sur lequel il reçoit des vérifications, si les nominations ne sont pas terminées.

Étapes suivantes

Articles connexes

• En savoir plus sur les types d’appels
• En savoir plus sur l’architecture client-serveur
• En savoir plus sur les topologies de flux d’appels