STUN: averiguar la dirección pública
Session Traversal Utilities for NAT (STUN), especificado en el RFC 8489, es un protocolo ligero de petición y respuesta. Un dispositivo envía una petición Binding a un servidor STUN, y la respuesta indica la dirección y el puerto públicos de los que llegó la petición: la dirección server-reflexive del dispositivo. STUN ayuda a dos dispositivos a intentar una conexión directa, pero nunca transporta la sesión, así que un servidor STUN necesita muy poco ancho de banda.
TURN: reenviar cuando falla la ruta directa
Traversal Using Relays around NAT (TURN), especificado en el RFC 8656 como extensión de STUN, reserva una dirección en un servidor relay. Los dos lados envían su tráfico al relay, que lo reenvía. TURN funciona cuando nada más lo hace, pero cada byte de la sesión atraviesa el relay, lo que añade latencia y le cuesta ancho de banda a quien lo opera.
ICE: elegir entre ellos
Interactive Connectivity Establishment (ICE), RFC 8445, une los dos. Cada lado reúne candidatos (direcciones locales, direcciones server-reflexive de STUN y direcciones de relay de TURN), los intercambia, prueba pares y se queda con el mejor que funcione, dando prioridad a las rutas directas. Así es exactamente como WebRTC usa ICE, STUN y TURN.
Cómo lo hace Vexaro Desk
Vexaro Desk no usa TURN. Cuando una red impide la conexión directa, la sesión pasa por los relays propios de Vexaro, y el cliente solo se conecta a un relay cuya autenticidad puede comprobar.
Las sesiones directas van cifradas de extremo a extremo. Cuando una red obliga a usar una conexión retransmitida, el tráfico sigue cifrado en tránsito a través de relays operados por Vexaro.