Server STUN e TURN: cosa serve a una videochiamata per collegarsi

In teoria, una videochiamata nel browser dovrebbe essere semplice. WebRTC invia audio e video direttamente da un dispositivo all’altro, senza nessun server in mezzo. Poi la provi fuori dalla tua rete, e alcune chiamate squillano, ricevono risposta e restano mute, con lo schermo nero. Il più delle volte il codice va bene. Quello che manca è un server STUN, un server TURN, o entrambi.

Questo articolo spiega cosa fa ciascuno dei due, perché una chiamata ne ha bisogno, cosa serve per gestire un tuo server TURN e cosa fare con le chiamate che nemmeno un relay riesce a collegare.

Perché due dispositivi non possono semplicemente collegarsi

Quasi nessun dispositivo su internet ha un indirizzo pubblico tutto suo. Un portatile a casa sta dietro un router, un telefono dietro il suo operatore e un computer in ufficio dietro un firewall. Ognuno conosce solo il proprio indirizzo privato, come 192.168.1.23, che per l’altro capo della chiamata non significa nulla.

Prima che una chiamata possa iniziare, ogni dispositivo deve scoprire come si può raggiungere l’altro, e i due devono provare quelle strade finché una non funziona. WebRTC lo fa con ICE, che raccoglie gli indirizzi candidati di ogni dispositivo e li prova a coppie. Alcuni di quei candidati arrivano da STUN e TURN.

Cosa fa un server STUN

Un server STUN risponde a una sola domanda: “qual è il mio indirizzo, visto da te?” Un dispositivo gli invia una piccola richiesta, e il server risponde con l’indirizzo pubblico e la porta da cui la richiesta è arrivata. Il dispositivo aggiunge quell’indirizzo ai suoi candidati, l’altro capo lo prova, e sulla maggior parte delle reti domestiche la chiamata si collega direttamente.

STUN costa poco. Vede qualche piccolo pacchetto all’inizio di una chiamata e poi più nulla, quindi un solo server STUN può servire moltissime chiamate, e ce ne sono di pubblici che chiunque può usare. Quando esiste un percorso diretto, a una chiamata basta STUN.

Cosa fa un server TURN

A volte un percorso diretto non esiste. Un firewall rigido non lascia entrare nulla, un operatore mobile assegna al telefono una porta pubblica diversa per ogni nuova destinazione, oppure una rete aziendale consente solo il traffico web. L’indirizzo riportato da STUN non funziona per l’altro capo, e la chiamata fallisce.

Un server TURN è un relay per queste chiamate. Entrambi i dispositivi si collegano in uscita al server, che passa il loro audio e video dall’uno all’altro. Dato che i dispositivi aprono solo connessioni in uscita, consentite da quasi ogni rete, la chiamata passa dove una chiamata diretta non riesce.

Fare da relay ha un costo che STUN non ha: ogni secondo di audio e video passa per il relay, in entrambe le direzioni, per tutta la durata della chiamata. Una videochiamata uno a uno può farci passare diversi megabit al secondo. Per questo esistono server STUN pubblici ma nessun server TURN gratuito affidabile: un relay aperto a chiunque si ritrova presto a trasportare traffico che il suo proprietario non aveva mai voluto trasportare, e viene chiuso o messo dietro delle credenziali.

Gestire un tuo server TURN

Esistono server TURN open source che funzionano bene, e molti team partono da lì. Ecco cosa serve:

• Un server con un indirizzo pubblico e tanta banda, vicino ai tuoi utenti. Un relay in un altro continente aggiunge un ritardo che le persone sentono.
• Le porte giuste. La porta abituale è la 3478, su UDP e TCP. Per le reti che consentono solo il traffico web, il relay deve rispondere anche sulla porta 443 con TLS, il che vuol dire un certificato per il suo nome, rinnovato in tempo.
• Credenziali che scadono. Un server TURN non dovrebbe mai accettare un nome utente e una password fissi, scritti nella tua pagina dove chiunque può copiarli. Il modo abituale è un segreto condiviso tra la tua app e il relay: il tuo server crea per ogni chiamata un nome utente e una password che dopo un po’ smettono di funzionare.
• Più di uno, man mano che cresci. Un solo relay è un unico punto in cui ogni chiamata può fallire. Gli utenti in altre regioni ne vogliono uno vicino, e ognuno ha bisogno di monitoraggio, aggiornamenti e margine per crescere.
• Test da reti reali. Un relay che funziona dal tuo ufficio può fallire da un telefono sulla rete di un operatore o da un portatile sul Wi-Fi di un hotel. Fai i test dalle reti che usano i tuoi utenti.

Niente di tutto questo è difficile, ma è un servizio da tenere in funzione finché la tua app ha delle chiamate.

Quando nemmeno TURN riesce a collegare una chiamata

Un relay risolve la maggior parte delle chiamate fallite, ma non tutte. Alcune reti bloccano l’UDP che il relay preferisce, e alcune interferiscono con le connessioni lunghe anche sulla porta 443. In questi casi una chiamata può fare un passo in più, verso una stanza su un media server, come quelli su cui girano le chiamate di gruppo. Le due persone allora inviano al media server e da lì ricevono ciascuna ciò che invia l’altra, un percorso che regge su reti dove qualsiasi tipo di media peer-to-peer fa fatica.

Una chiamata che può spostarsi lì solo dopo essere fallita si chiuderebbe prima. Il modo migliore è tenere viva la chiamata mentre cambia percorso, così chi vi partecipa nota un attimo di blocco, non una chiamata caduta.

Come WordPlus Cloud collega le chiamate

WordPlus Cloud gestisce tutti e tre i percorsi, quindi una chiamata tra due persone si collega sempre, qualunque sia la rete:

1. Direttamente, tra i due dispositivi, sulla maggior parte delle reti. Il percorso più veloce.
2. Tramite i nostri relay, quando un firewall blocca il percorso diretto. Rispondono sulle porte del web, 443 e 80, oltre che sulla 3478, così una chiamata passa ovunque passino i siti web. Ogni persona in ogni chiamata riceve credenziali relay tutte sue, che scadono dopo qualche ora, così nessuno può usare i relay al di fuori delle tue chiamate.
3. Tramite i nostri media server, quando nemmeno i relay riescono a trasportare la chiamata. La chiamata si sposta lì e continua, senza riagganciare.

Le chiamate sono cifrate end-to-end su ogni percorso, con una chiave che distribuisce solo il tuo server, quindi relay e media server trasportano ciò che non possono leggere. Le chiamate tra due persone sono incluse in ogni piano, con o senza relay. È sempre il tuo server a decidere chi può chiamare chi, e il cloud lo fa rispettare.

Funziona allo stesso modo in Better Messages su WordPress e nelle tue app, da Next.js, Laravel, Django e altri stack con i nostri SDK. Videochiamate e chiamate di gruppo per la tua app mostra cosa ti danno gli SDK, e come funzionano le chiamate nella nostra documentazione mostra il codice.