STUN: descobrir o endereço público
O Session Traversal Utilities for NAT (STUN), especificado no RFC 8489, é um protocolo leve de pedido e resposta. Um dispositivo envia um pedido Binding a um servidor STUN, e a resposta indica o endereço e a porta públicos de onde veio o pedido, ou seja, o endereço server-reflexive do dispositivo. O STUN ajuda dois dispositivos a tentar uma ligação direta, mas nunca transporta a sessão em si, pelo que um servidor STUN precisa de muito pouca largura de banda.
TURN: reencaminhar quando o direto falha
O Traversal Using Relays around NAT (TURN), especificado no RFC 8656 como extensão do STUN, reserva um endereço num servidor relay. Os dois lados enviam o seu tráfego para o relay, que o reencaminha. O TURN funciona quando mais nada funciona, mas cada byte da sessão passa pelo relay, o que acrescenta latência e custa largura de banda a quem o opera.
ICE: escolher entre os dois
O Interactive Connectivity Establishment (ICE), RFC 8445, junta os dois. Cada lado reúne candidatos (endereços locais, endereços server-reflexive do STUN e endereços de relay do TURN), troca-os, testa pares e fica com o melhor que funcionar, dando prioridade aos caminhos diretos. É exatamente assim que o WebRTC usa o ICE, o STUN e o TURN.
Como o Vexaro Desk o faz
O Vexaro Desk não usa TURN. Quando uma rede impede a ligação direta, a sessão passa pelos relays da própria Vexaro, e o cliente só se liga a um relay cuja autenticidade consiga verificar.
As sessões diretas são cifradas ponta a ponta. Quando uma rede obriga a uma ligação retransmitida, o tráfego mantém-se cifrado em trânsito através de relays operados pela Vexaro.