STUN: scoprire il proprio indirizzo pubblico
Session Traversal Utilities for NAT (STUN), definito nell'RFC 8489, è un protocollo leggero a richiesta e risposta. Un dispositivo invia una richiesta di binding a un server STUN, e la risposta riporta l'indirizzo pubblico e la porta da cui è arrivata la richiesta, detti indirizzo server-reflexive del dispositivo. STUN aiuta due dispositivi a tentare una connessione diretta, ma non trasporta mai la sessione, quindi a un server STUN serve pochissima banda.
TURN: inoltrare quando la via diretta fallisce
Traversal Using Relays around NAT (TURN), definito nell'RFC 8656 come estensione di STUN, assegna un indirizzo su un server di relay. Entrambi i lati inviano il proprio traffico al relay, che lo inoltra. TURN funziona quando nient'altro funziona, ma ogni byte della sessione attraversa il relay, il che aggiunge latenza e costa banda a chi lo gestisce.
ICE: scegliere tra i due
Interactive Connectivity Establishment (ICE), RFC 8445, li mette insieme. Ogni lato raccoglie i candidati (indirizzi locali, indirizzi server-reflexive da STUN e indirizzi di relay da TURN), li scambia, prova le coppie e tiene la migliore che funziona, preferendo le vie dirette. WebRTC usa ICE, STUN e TURN esattamente in questo modo.
Come fa Vexaro Desk
Vexaro Desk non usa TURN. Quando una rete esclude una connessione diretta, la sessione passa invece dai relay di Vexaro, e il client si collega solo a un relay che riesce ad autenticare.
Le sessioni dirette hanno la crittografia end-to-end. Quando una rete impone una connessione tramite relay, il traffico resta cifrato in transito attraverso relay gestiti da Vexaro.