Il collaudo e l'orizzonte

Bentornati sulle due rive, per l'ultima volta in questa stagione.

Il ponte è progettato, protetto, costruito. Ma ogni ingegnere sa che un ponte non è finito quando è costruito: è finito quando è collaudato. E poi, dalla riva, conviene alzare lo sguardo e guardare cosa si sta costruendo più a valle, lungo il fiume.

Il primo strumento di collaudo è già nel vostro browser.

In Chrome, e in tutti i browser basati su Chromium, aprite una nuova scheda e scrivete chrome due punti slash slash webrtc trattino internals. È una pagina nascosta che registra tutto quello che succede in ogni RTCPeerConnection aperta: le chiamate alle API, le lettere SDP scambiate, i candidati ICE, i cambi di stato, e decine di grafici in tempo reale. In Firefox l'equivalente si chiama about due punti webrtc.

Due consigli pratici. Aprite la pagina prima di avviare la chiamata, perché registra solo le connessioni create mentre è aperta. E usate la funzione di esportazione: quando un utente vi dice che la chiamata non funziona, chiedergli di mandarvi quel file vale più di cento descrizioni a parole.

Il registro è perfetto per voi sviluppatori, ma i vostri utenti non lo apriranno. Per sapere come vanno le chiamate in produzione serve l'API getStats.

getStats restituisce un rapporto fatto di decine di oggetti, ognuno con un tipo. Non serve guardarli tutti. Ne contano soprattutto quattro.

La coppia di candidati scelta, quella su cui passa il ponte. Vi dice il percorso: se uno dei due candidati è di tipo relay, la chiamata passa dal traghetto. Vi dice il tempo di andata e ritorno, e la banda disponibile stimata dal controllo della congestione. Se la banda stimata è bassa, il problema è la rete.

Il flusso in entrata, inbound rtp. Pacchetti persi, jitter, fotogrammi al secondo, fotogrammi scartati. È la qualità che l'utente vede.

Il flusso in uscita, outbound rtp. Qui c'è la metrica più preziosa di tutte, e la meno conosciuta: il motivo per cui la qualità è limitata. Può valere nessuno, banda, oppure processore. Se vale processore, la rete va benissimo: è il computer dell'utente che non ce la fa a codificare. E nessuna ottimizzazione della rete lo risolverà. Magari conviene un codec meno pesante, o una risoluzione più bassa.

Infine il rapporto del ricevente remoto, che vi dice come l'altra riva vede il vostro flusso.

Nelle note trovate una funzione che ogni due secondi riassume tutto questo in poche righe. Mandate quei numeri al vostro server, anche a campione, e avrete per la prima volta una visione reale della qualità delle chiamate.

Dopo un po' di cantieri, i guasti si somigliano tutti. Ecco quelli che incontrerete quasi certamente.

La chiamata funziona in ufficio e non a casa, o viceversa: quasi sempre manca il traghetto, oppure il traghetto c'è ma è configurato male. Due errori classici di coturn: l'indirizzo pubblico non dichiarato, quando il server sta dietro a un NAT del cloud, e l'intervallo di porte per le allocazioni non aperto sul firewall. Il collaudo con la politica relay li trova in un minuto.

Il ponte si costruisce ma non si sente niente: spesso è la politica di riproduzione automatica dei browser, che blocca l'audio finché l'utente non interagisce con la pagina. Serve un pulsante, un gesto dell'utente. Sui dispositivi Apple, il video deve avere anche l'attributo playsinline, altrimenti tenta di aprirsi a tutto schermo.

L'eco: quasi sempre qualcuno ha disattivato la cancellazione dell'eco nei vincoli, o il proprio video locale non è silenziato e l'audio rientra nel microfono.

E infine le collisioni: il ponte funziona nel novantanove per cento dei casi e si blocca in modo misterioso quando i due accendono la videocamera nello stesso momento. È il glare del secondo episodio. La cura è la negoziazione perfetta.

Collaudare a mano, con due finestre, va bene all'inizio. Poi serve qualcosa di ripetibile.

Chromium accetta due opzioni da riga di comando pensate proprio per questo: una che usa dispositivi finti, con un video di prova e un tono audio, e una che accetta automaticamente i permessi. Con uno strumento come Playwright potete aprire due pagine, farle entrare nella stessa stanza, e verificare che il video remoto abbia una dimensione maggiore di zero. È esattamente il modo in cui è stato provato il codice dell'episodio scorso.

Per la rete, su Linux esiste uno strumento chiamato netem, che aggiunge ritardo, jitter e perdite di pacchetti a una scheda di rete. Centocinquanta millisecondi di ritardo e il tre per cento di perdite: è una rete mobile mediocre, ed è lì che vedrete se il vostro ponte regge.

Alziamo lo sguardo. WebRTC è un pacchetto completo: cattura, codifica, trasporto, sicurezza, adattamento alla rete, tutto insieme. È il suo pregio, ed è anche il suo limite. Se volete fare qualcosa di diverso da quello che il pacchetto prevede, è difficile.

Per questo negli ultimi anni i browser hanno cominciato a offrire i mattoni separati. WebCodecs dà accesso diretto ai codificatori e decodificatori audio e video del browser: fotogramma per fotogramma, senza tutto il resto. WebTransport è un trasporto moderno tra browser e server, basato su HTTP tre e QUIC, con flussi affidabili e datagrammi inaffidabili. È disponibile nei principali browser basati su Chromium e in Firefox.

Messi insieme, permettono di costruire il proprio sistema multimediale con controllo totale. Al prezzo, ovviamente, di dover fare a mano tutto quello che WebRTC fa da solo: il controllo della congestione, il buffer contro il jitter, la sincronizzazione tra audio e video.

Su queste basi, alla IETF lavora un gruppo chiamato Media over QUIC. L'obiettivo è ambizioso: un'unica tecnologia che vada bene sia per la conversazione, con ritardi bassissimi, sia per la distribuzione a milioni di persone, attraverso una rete di server intermedi simile a quella che oggi serve i video su HTTP. Oggi, per avere entrambe le cose, si usano due mondi diversi: WebRTC per l'interazione e HLS o DASH per il grande pubblico.

È un lavoro ancora in bozza, con prime realizzazioni sperimentali. Vale la pena seguirlo, ma non è ancora il momento di costruirci sopra un prodotto.

E allora, nel 2026, cosa si usa? Ecco una guida che potete usare domani.

Per una conversazione tra due o tre persone: WebRTC diretto, con un traghetto. Per le riunioni e le lezioni: WebRTC con un'isola, cioè una SFU, e simulcast. Per una diretta in cui il pubblico interagisce, come un'asta o una sessione di domande: WebRTC, con WHIP per chi trasmette e WHEP o una SFU per chi guarda. Per un grande pubblico che accetta qualche secondo di ritardo: HLS o DASH a bassa latenza, che costano molto meno e scalano su qualunque rete di distribuzione. Per i dati tra client e server: WebSocket, o WebTransport. Per i dati tra utenti, senza passare dal server: i canali dati di WebRTC.

E così chiudiamo il cantiere. Siamo partiti da due rive di un fiume e da un'idea semplice: farle parlare direttamente. Abbiamo incontrato il messaggero che porta il progetto, le mura e i guardiani dei cancelli, la vedetta e il traghetto, la parola d'ordine. Abbiamo fatto passare i carri e aperto la passerella, costruito un'isola in mezzo al fiume, messo le mani nel codice, e oggi abbiamo collaudato il ponte e guardato più a valle.

Se c'è una cosa che vorrei vi portaste via da questa stagione, è questa: WebRTC non vi dà una connessione. Vi dà gli attrezzi per costruire un ponte. E il ponte regge solo se avete pensato anche alle parti che il browser non fa per voi: il messaggero, il traghetto, il collaudo.

Grazie per essere stati sulle due rive con me. Ci sentiamo nella prossima stagione.