WebRTC su larga scala: come Mandraki gestisce chiamate di gruppo massicce

Le videochiamate di gruppo sono una di quelle funzionalità che agli utenti sembrano semplici ma che implicano una considerevole complessità ingegneristica sotto la superficie. Una chiamata uno-a-uno è relativamente semplice — due peer si scambiano media direttamente. Ma non appena si aggiunge un terzo partecipante, le decisioni architetturali si moltiplicano, e quando si arriva a cinquanta partecipanti in più sessioni simultanee, ci si trova davanti a un problema di sistemi distribuiti genuinamente difficile.

Questo post spiega come l’architettura media in tempo reale di Mandraki sia progettata per una scala massiccia — senza scendere a compromessi su crittografia o sovranità dei dati.

Perché non peer-to-peer

In una topologia mesh peer-to-peer, ogni partecipante invia il proprio flusso media direttamente a ogni altro partecipante. Per una chiamata con N partecipanti, ciascuno invia N-1 flussi e riceve N-1 flussi. Il numero totale di connessioni è N*(N-1), e il requisito di banda di upload di ogni partecipante scala linearmente con il numero di partecipanti.

Funziona adeguatamente per tre o quattro partecipanti con buone connessioni internet. Oltre, crolla. Un partecipante con un upload da 5 Mbps che invia un flusso video da 1,5 Mbps può servire solo tre peer prima di saturare il proprio upload. L’uso della CPU per codificare più flussi cresce rapidamente. E le condizioni di rete tra coppie arbitrarie di partecipanti sono imprevedibili.

La topologia mesh è elegante in teoria e impraticabile su larga scala.

L’approccio SFU

Una Selective Forwarding Unit (SFU) si trova al centro della topologia della chiamata. Ogni partecipante invia un singolo flusso di upload all’SFU. L’SFU inoltra poi quel flusso a tutti gli altri partecipanti. La banda di upload del partecipante è costante indipendentemente dal numero di partecipanti — invia sempre un solo flusso. L’SFU gestisce il fan-out.

La parte “selective” è importante. L’SFU non si limita a trasmettere ogni flusso a ogni partecipante. Prende decisioni di inoltro intelligenti basate su condizioni di rete, visibilità dei partecipanti e banda disponibile. Se la connessione di download di un partecipante è limitata, l’SFU può inoltrare strati a risoluzione inferiore. Se un partecipante non è attualmente visibile nell’interfaccia (ad esempio, in una chiamata grande in cui solo l’oratore attivo è mostrato a dimensione piena), l’SFU può ridurre o sospendere l’inoltro del suo flusso.

Questo è fondamentalmente diverso da un Multipoint Control Unit (MCU), che decodifica tutti i flussi in entrata, li compone in un singolo flusso misto, lo ricodifica e invia il composito a ogni partecipante. Gli MCU sono ad alta intensità di CPU, aggiungono latenza di codifica e — punto critico — richiedono l’accesso al media in chiaro, rendendoli incompatibili con la crittografia end-to-end.

Un SFU inoltra pacchetti crittografati senza decodificarli. È ciò che rende possibile la crittografia end-to-end basata su SFrame in una chiamata di gruppo. L’SFU instrada il testo cifrato.

L’architettura SFU di Mandraki

Mandraki utilizza una libreria SFU open-source integrata direttamente nella nostra infrastruttura. Anziché affidarci a un server media monolitico di terze parti, incorporiamo l’SFU come libreria all’interno della nostra codebase. Ciò ci dà pieno controllo su come si integra con il nostro livello applicativo, il protocollo di segnalazione e il sistema di autenticazione.

L’SFU utilizza un’architettura multi-worker. Ogni worker è un processo nativo separato che gestisce l’effettivo routing dei media a prestazioni vicine al nativo. Il livello di coordinamento gestisce worker, trasporti e si interfaccia con la nostra logica applicativa. Questa separazione mantiene veloce il percorso dei media mentre il percorso di controllo rimane flessibile.

L’SFU supporta simulcast e SVC (Scalable Video Coding), essenziali per l’inoltro adattivo alla banda. I browser dei partecipanti codificano il video a più livelli di qualità simultaneamente. L’SFU seleziona il livello appropriato per ciascun destinatario in base alla banda disponibile e al contesto dell’interfaccia.

Scalare fino a centinaia di sessioni

Per le distribuzioni su larga scala, l’architettura è progettata attorno alla scalabilità orizzontale con instradamento intelligente delle sessioni.

Distribuzione SFU multi-istanza. Più istanze SFU girano su zone di disponibilità diverse. Ogni istanza registra la propria capacità presso un livello di coordinamento. Quando viene creata una nuova chiamata, il sistema seleziona l’istanza SFU con la maggiore capacità disponibile. I partecipanti alla stessa chiamata vengono sempre instradati alla stessa istanza SFU per un routing dei media ottimale.

Parallelismo a livello di worker. Ogni processo SFU genera più worker nativi — tipicamente corrispondenti al numero di core CPU disponibili. Ogni worker può gestire più sale chiamata in modo indipendente. Ciò significa che un singolo server SFU con 16 core può gestire efficientemente decine di chiamate simultanee, ciascuna con fino a 50 partecipanti.

Inoltro adattivo alla banda. Per le chiamate con molti partecipanti, diverse ottimizzazioni si attivano automaticamente. La rilevazione dell’oratore attivo riduce il numero di flussi ad alta qualità che devono essere inoltrati. La selezione dei livelli simulcast diventa più aggressiva, favorendo livelli inferiori per i partecipanti non visibili. Il fallback solo audio è disponibile per i partecipanti con banda gravemente limitata.

Distribuzione europea multi-zona. L’infrastruttura di Mandraki gira su più zone di disponibilità all’interno dell’UE su infrastruttura iperscalare europea. Le istanze SFU sono distribuite vicino agli utenti, riducendo la latenza di andata e ritorno per i pacchetti media. Tutto il routing dei media rimane entro i confini europei — nessun media viene mai instradato attraverso infrastruttura extra-UE.

Attraversamento NAT

Il più grande punto di forza di WebRTC — la connettività peer-to-peer diretta — è anche la sua più grande sfida. La maggior parte dei dispositivi si trova dietro firewall NAT (Network Address Translation) che impediscono connessioni in entrata dirette. WebRTC usa ICE (Interactive Connectivity Establishment) per scoprire un percorso di rete praticabile, provando in sequenza connessione diretta, connessione mediata da STUN e relay TURN.

Mandraki gestisce server TURN dedicati accanto all’infrastruttura SFU. TURN agisce come relay di ultima istanza — quando un partecipante non può stabilire una connessione diretta all’SFU (a causa di firewall restrittivi, NAT simmetrico o server proxy aziendali), i media passano attraverso il server TURN. Ciò aggiunge un po’ di latenza ma garantisce la connettività.

I server TURN supportano sia UDP che TCP, oltre a TLS per ambienti che consentono solo traffico HTTPS. Come tutto il resto nel nostro stack, girano interamente all’interno dell’UE.

Crittografia end-to-end su larga scala

L’architettura SFU è scelta specificamente perché preserva la compatibilità con la crittografia end-to-end. Utilizzando WebRTC Encoded Transforms e il protocollo SFrame (RFC 9605), i frame media vengono crittografati sul dispositivo del mittente prima di raggiungere l’SFU. L’SFU inoltra i frame crittografati ai destinatari, che li decifrano localmente.

L’SFU non ha mai accesso ai media in chiaro. Instrada il testo cifrato. Ciò significa che anche su larga scala — con decine di partecipanti e più chiamate simultanee — le garanzie di crittografia tengono. Nessun server nella nostra infrastruttura vede o elabora mai audio o video non crittografati.

Questa è una scelta architetturale fondamentale. Molte piattaforme dichiarano crittografia ma utilizzano architetture basate su MCU che richiedono la decodifica lato server. L’approccio SFU di Mandraki significa che la crittografia non è solo una funzionalità — è una garanzia strutturale.

Monitoraggio e affidabilità

I problemi WebRTC sono notoriamente difficili da diagnosticare. Raccogliamo telemetria lato client che include transizioni di stato della connessione ICE, tipi di coppia di candidati selezionati, stime di tempo di andata e ritorno, tassi di perdita pacchetti e stime di banda. Queste metriche vengono raggruppate in batch e inviate al nostro endpoint di telemetria per l’aggregazione.

Lato server, l’SFU registra eventi di trasporto, il ciclo di vita di producer e consumer e la stima della banda. Combinata con la telemetria lato client, ciò fornisce una visione completa della qualità delle chiamate che ci consente di identificare e affrontare i problemi in modo sistematico.

La comunicazione in tempo reale su larga scala è una profonda sfida ingegneristica. Continuiamo a investire nell’infrastruttura media che rende le chiamate di Mandraki affidabili, a bassa latenza e crittografate end-to-end — il tutto all’interno di infrastruttura europea sovrana.