OpenAI ha ricostruito il suo stack WebRTC attorno a un relay stateless che instrada il traffico basandosi sull'ICE ufrag

Il vincolo che ha imposto la riprogettazione: il modello a porte di WebRTC contro Kubernetes

Il team di OpenAI inquadra il problema in termini operativi, non di prodotto. Servire più di 900 milioni di utenti attivi settimanali significava che il pattern di deployment WebRTC convenzionale — una porta UDP pubblica per ogni sessione — non era più compatibile con la loro infrastruttura.

Ne spiegano il motivo. Ad alta concorrenza, avere una porta per sessione ti costringe a esporre e gestire intervalli enormi di porte UDP pubbliche. I load balancer cloud e i servizi Kubernetes non sono pensati per decine di migliaia di porte UDP pubbliche. Quella superficie è difficile da proteggere, difficile da controllare e ostile all'autoscaling, dato che i pod vengono continuamente creati, rimossi e riprogrammati, mentre ognuno dovrebbe riservare e annunciare un intervallo di porte stabile.

La soluzione ovvia — un'unica porta UDP per server con demultiplexing a livello applicativo — risolve il problema del numero di porte ma ne crea un secondo. ICE e DTLS sono stateful, quindi il processo che ha creato una sessione deve continuare a ricevere i pacchetti di quella sessione. Su una flotta bilanciata dal load balancer, il primo pacchetto può comunque finire sull'istanza sbagliata.

Instradare su un campo che esiste già nell'handshake

La risposta di OpenAI separa l'instradamento dei pacchetti dalla terminazione del protocollo. Un relay leggero scritto in Go, con una superficie pubblica minima, si trova davanti a un transceiver stateful che gestisce l'intera sessione WebRTC — i controlli di connettività ICE, l'handshake DTLS, le chiavi SRTP e il ciclo di vita. Il relay non decifra mai il media né esegue le macchine a stati di ICE: legge solo i metadati del pacchetto necessari a scegliere una destinazione.

La mossa intelligente riguarda dove risiede l'indicazione di instradamento. Invece di aggiungere un servizio di lookup nel percorso critico, OpenAI codifica i metadati di instradamento nell'ICE username fragment (ufrag), un breve identificatore già scambiato durante la configurazione e ripetuto nelle richieste di binding STUN. Il transceiver genera un ufrag lato server che contiene informazioni sufficienti a identificare il cluster di destinazione e il transceiver proprietario.

Quindi il primo pacchetto del percorso media del client — di solito una richiesta di binding STUN inviata a un VIP relay condiviso come 203.0.113.10:3478 — viene analizzato dal relay, che decodifica l'ufrag e lo inoltra al transceiver corretto. I pacchetti DTLS, RTP e RTCP successivi fluiscono senza bisogno di ridecodifica. Se un relay si riavvia, il pacchetto STUN successivo ricostruisce la mappatura a partire dall'ufrag; una cache Redis mantiene la mappatura tra IP del client e transceiver, così il recupero può avvenire ancora più rapidamente.

Ciò che il browser non nota mai

Per chi lavora sul frontend, la caratteristica distintiva di questo lavoro è negativa: il client non vede nulla di nuovo. OpenAI è esplicita: dal punto di vista del client, nulla cambia nella sessione WebRTC. Il transceiver continua a presentare un flusso WebRTC normale e continua a gestire tutto lo stato del protocollo; è cambiato solo l'instradamento interno.

Per noi, questo ha significato cambiare la forma del nostro deployment WebRTC senza cambiare ciò che i client si aspettano da WebRTC stesso.Montana Labs

Si tratta di un principio di design deliberato che elencano come "preservare la semantica del protocollo ai margini". Poiché i client continuano a parlare WebRTC standard, l'interoperabilità con browser e mobile resta intatta — il team riesce a ridisegnare la propria infrastruttura senza distribuire comportamenti client personalizzati e senza frammentare il supporto tra le piattaforme. La complessità è stata spostata in un sottile livello di instradamento, non in ogni singolo servizio backend né nel client.

Il post riconosce anche il merito dell'ecosistema WebRTC su cui si basa, notando che Justin Uberti, uno degli architetti originali di WebRTC, e Sean DuBois, creatore dell'implementazione Go Pion, sono ora colleghi in OpenAI. La prima implementazione del transceiver era un singolo servizio Go costruito su Pion.

Scegliere l'opzione più prudente: niente SFU, niente kernel bypass

Due decisioni si distinguono per la loro cautela. Primo, OpenAI ha scartato l'SFU (selective forwarding unit) su cui molti team si orientano di default. Un SFU ha senso per le chiamate multiparty, ma il traffico di OpenAI è per lo più 1:1 — un utente con un modello — e sensibile alla latenza a ogni turno. Il risultato ottenuto con relay più transceiver, scrivono, ha confermato che un design senza SFU era la scelta giusta di default e ha permesso ai servizi di inferenza di scalare come servizi ordinari, invece di comportarsi come peer WebRTC.

Secondo, hanno rinunciato al kernel bypass. Il relay funziona interamente in userspace come un normale processo Go, ottimizzato con SO_REUSEPORT per distribuire i pacchetti tra i worker, runtime.LockOSThread per fissare i flussi ai core della CPU e migliorare la cache locality, e buffer pre-allocati per evitare l'overhead del garbage collection. Questo si è rivelato sufficiente per gestire il traffico media in tempo reale a livello globale con una superficie relay relativamente piccola, quindi hanno mantenuto il design più semplice.

La geografia si aggiunge come ulteriore livello: Global Relay posiziona i punti di ingresso vicino agli utenti per abbreviare il primo salto, mentre il geo-steering e il proximity steering di Cloudflare instradano la segnalazione verso un cluster di transceiver vicino, con l'ufrag che garantisce che il media arrivi comunque al transceiver ancorato.

La lezione: i metadati di instradamento appartengono al protocollo che già usi

L'implicazione specifica di questo annuncio è che l'ICE ufrag può fungere anche da router deterministico per il primo pacchetto. Incorporando indicazioni di instradamento in un campo che WebRTC già trasporta, OpenAI ha ottenuto un forwarding sticky per sessione su tutta la flotta senza dipendere da un servizio di lookup nel percorso critico e senza rompere il comportamento standard dei client.

Per i team che costruiscono voce in tempo reale su WebRTC, la lezione riutilizzabile non è il transceiver o il relay in sé — è la sequenza delle scelte. Risolvi prima il disallineamento di deployment (porte UDP contro Kubernetes) con un sottile livello di forwarding stateless, mantieni le parti stateful più complesse in un unico punto, e ricorri a strumenti esotici come il kernel bypass solo quando il caso comune lo richiede davvero. Il percorso di OpenAI suggerisce che, di solito, non è necessario.