STUN : découvrir son adresse publique
Session Traversal Utilities for NAT (STUN), défini dans la RFC 8489, est un protocole léger de requête-réponse. Un appareil envoie une requête Binding à un serveur STUN, et la réponse indique l'adresse et le port publics d'où provenait la requête, c'est-à-dire l'adresse « server-reflexive » de l'appareil. STUN aide deux appareils à tenter une connexion directe, mais ne transporte jamais la session elle-même : un serveur STUN consomme donc très peu de bande passante.
TURN : relayer quand le direct échoue
Traversal Using Relays around NAT (TURN), défini dans la RFC 8656 comme une extension de STUN, réserve une adresse sur un serveur relais. Les deux côtés envoient leur trafic au relais, qui le transfère. TURN fonctionne quand rien d'autre ne marche, mais chaque octet de la session traverse le relais, ce qui ajoute de la latence et coûte de la bande passante à l'exploitant.
ICE : choisir entre les deux
Interactive Connectivity Establishment (ICE), RFC 8445, assemble les deux. Chaque côté rassemble des candidats (adresses locales, adresses « server-reflexive » obtenues par STUN et adresses relayées obtenues par TURN), les échange, teste des paires et conserve la meilleure qui fonctionne, en privilégiant les chemins directs. C'est exactement ainsi que WebRTC utilise ICE, STUN et TURN.
L'approche de Vexaro Desk
Vexaro Desk n'utilise pas TURN. Lorsqu'un réseau empêche une connexion directe, la session passe par les propres relais de Vexaro, et le client ne se connecte qu'à un relais dont il peut vérifier l'authenticité.
Les sessions directes sont chiffrées de bout en bout. Lorsqu'un réseau impose une connexion relayée, le trafic reste chiffré en transit via des relais exploités par Vexaro.