| Une socket est établie pour tous les signaux WebRTC. La connexion est créée une fois et réutilisée pour tous les messages suivants. Une nouvelle connexion n'est pas créée pour le flux entrant, de sorte qu'un accès au réseau n'est pas nécessaire pour établir une connexion entrante. |
Lorsqu'un appel est lancé, le service multimédia en nuage ou Edge et le client WebRTC utilisent une demande STUN pour obtenir son adresse NAT réflexive (l'adresse publique et le port correspondant à ceux du client sur le réseau public). Plusieurs requêtes STUN sont tentées. |
Un NAT symétrique ne coopérera pas avec le processus STUN car une nouvelle traduction sera créée pour le flux média. Cela ne permettra pas au chemin direct des médias de se poursuivre, ce qui entraînera l'utilisation d'un canal TURN pour le flux des médias. |
Le client reçoit des candidats de son homologue et envoie une demande de liaison pour vérifier la connectivité. La réponse de liaison est utilisée pour valider la connexion et confirmer que le chemin prévu a été utilisé. Si le client utilise une adresse NAT différente de celle qu'il a utilisée pour contacter le serveur STUN, cela sera détecté et un nouveau candidat réflexif homologue sera produit. |
Un seul chemin média SRTP est nécessaire. Un chemin média direct peut être établi entre des adresses IP réelles (BYOC Premise) ou avec des adresses IP réflexives NAT (BYOC Cloud). Si un chemin média direct n'est pas accessible, un canal TURNs peut être utilisé pour contourner les problèmes d'accès au réseau ou de NAT. |
