WebRTC: cos'è, architettura e principio di funzionamento

Cos'è WebRTC

WebRTC (Web Real-Time Communication) è un progetto open source avviato da Google nel 2011 e standardizzato dal W3C (JavaScript API) e IETF (protocolli). L'obiettivo principale è fornire comunicazione a bassa latenza tra browser e applicazioni senza installare plugin o software di terze parti.

A differenza delle soluzioni tradizionali (RTMP, HLS) dove il video passa attraverso un server, WebRTC utilizza architettura peer-to-peer: i dati vengono trasmessi direttamente tra i partecipanti. Questo offre una latenza di 200-500 ms rispetto ai 3-10 secondi di HLS — una differenza critica per chiamate vocali e video, streaming di giochi e chirurgia remota.

Secondo Google WebRTC Team (2025), la tecnologia è utilizzata in applicazioni con un totale di oltre 5 miliardi di installazioni: Google Meet, WhatsApp, Discord, Telegram, Zoom (parzialmente). Più dell'85% delle startup venture in telehealth ed edtech scelgono WebRTC come trasporto base in tempo reale.

Lo sviluppo mobile ha ricevuto il pieno supporto WebRTC nel 2013 con il rilascio di libjingle_peerconnection — un'implementazione nativa per Android e iOS. Oggi entrambe le piattaforme dispongono di SDK stabili con supporto per codifica hardware di H.264 e VP8, fotocamera, microfono e altoparlanti del dispositivo.

Architettura e protocolli WebRTC

L'architettura WebRTC è composta da tre livelli. Il livello superiore è JavaScript API (o API nativa per piattaforme mobili), il livello intermedio sono i protocolli di trasporto, il livello inferiore sono i codec e la sicurezza. Ogni livello risolve il proprio compito, ma tutti sono necessari per lo stabilimento della connessione.

API principali di WebRTC

MediaStream (getUserMedia) — cattura audio e video dal microfono e dalla fotocamera del dispositivo. RTCPeerConnection — gestisce la connessione P2P: codifica, trasporto, adattamento del bitrate. RTCDataChannel — trasmette dati arbitrari (testo, file, messaggi binari) sullo stesso canale.

// API JavaScript WebRTC (esempio browser)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Protocolli in tempo reale

WebRTC utilizza SRTP (Secure Real-Time Transport Protocol) per audio e video — una versione sicura di RTP con crittografia AES-128. La gestione della sessione avviene tramite SCTP (Stream Control Transmission Protocol) su DTLS. Ogni flusso di dati viene crittografato obbligatoriamente: WebRTC non ha modalità non sicura.

• SRTP/SRTCP — trasmissione crittografata di flussi multimediali con protezione da attacchi replay
• DTLS-SRTP — stabilimento delle chiavi di crittografia tramite Datagram TLS su UDP
• SCTP — consegna dati affidabile o parzialmente affidabile per DataChannel
• ICE (Interactive Connectivity Establishment) — framework per trovare un percorso di rete tra peer
• Trickle ICE — versione incrementale di ICE in cui i candidati vengono inviati man mano che vengono scoperti, accelerando lo stabilimento della connessione

NAT traversal: ICE, STUN e TURN

La principale sfida tecnica di WebRTC è stabilire una connessione P2P tra dispositivi che si trovano dietro NAT (Network Address Translation). Senza meccanismi speciali, i dispositivi non possono raggiungersi direttamente perché i loro indirizzi IP locali non sono visibili da internet.

STUN — determinazione dell'indirizzo pubblico

STUN (Session Traversal Utilities for NAT) — un server che risponde alla domanda “Qual è il mio IP e la mia porta pubblici?”. Il client invia una richiesta al server STUN, il server vede il suo indirizzo pubblico e lo restituisce al client. Google mantiene pubblicamente il server STUN stun:stun.l.google.com:19302.

// WebRTC su iOS — configurazione server ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — connessione relay

TURN (Traversal Using Relays around NAT) — un server relay per i casi in cui STUN non aiuta (NAT simmetrico o firewall aziendali). In questa modalità tutti i dati passano attraverso il server TURN — questo riduce la velocità e aumenta la latenza, ma garantisce connessione nel 99% dei casi.

TURN è il componente più costoso dell'infrastruttura WebRTC, poiché il server fa passare tutto il traffico multimediale attraverso di sé. Secondo Coturn Project (2025), un server TURN tipico con 8 vCPU e 16 GB di RAM gestisce circa 200 chiamate audio simultanee o 40 videochiamate in HD.

Processo ICE

ICE raccoglie tutti i possibili candidati (IP locale, IP pubblico tramite STUN, relay tramite TURN) e tenta di stabilire una connessione in ordine di priorità. Non appena almeno una coppia di candidati (locale-remoto) supera il controllo di connettività, la connessione si considera stabilita.

• Host candidates — indirizzo IP locale del dispositivo nella sottorete (più veloce, ma non funziona dietro NAT)
• Server Reflexive candidates — IP pubblico ottenuto tramite un server STUN
• Relay candidates — indirizzo del server TURN attraverso cui avviene il relay (più lento, più affidabile)

WebRTC nelle app mobili

Per lo sviluppo mobile, Google mantiene libWebRTC — una libreria nativa per Android (AAR) e iOS (XCFramework). La libreria include l'intero stack di protocolli, codec (VP8, VP9, H.264, AV1) e accelerazione hardware per codifica/decodifica.

WebRTC su Android

L'SDK Android fornisce le classi PeerConnectionFactory, PeerConnection, MediaStream. L'app crea una factory, configura i codec video, cattura il flusso della fotocamera tramite VideoCapturer e stabilisce la connessione peer tramite SDP offer/answer.

// WebRTC su Android — inizializzazione
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC su iOS

L'SDK iOS utilizza un'API Objective-C con wrapper RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. La codifica hardware H.264 è disponibile tramite VideoToolbox. Per la visualizzazione video si utilizza RTCMTLVideoView (Metal) o RTCVideoRenderer.

// WebRTC su iOS — cattura video dalla fotocamera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Selezione fotocamera (anteriore/posteriore)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Avvia cattura con FPS massimo
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Per le videochiamate in produzione, le app mobili utilizzano solitamente wrapper SDK su libWebRTC: Twilio Video, Agora, Daily.co. Questi SDK semplificano la segnalazione, la gestione delle stanze e forniscono componenti UI pronti per visualizzare la griglia video dei partecipanti.

Segnalazione e stabilimento della connessione

WebRTC non specifica un protocollo di segnalazione — lo scambio di messaggi SDP (Session Description Protocol) tra peer. Lo sviluppatore sceglie il trasporto per la segnalazione: WebSocket, MQTT, SIP, XMPP o API REST. La segnalazione consegna offer, answer e candidati ICE da un peer all'altro.

Scambio SDP Offer/Answer

Il processo inizia con la creazione di un offer (l'iniziatore descrive le proprie capacità multimediali), trasmesso tramite segnalazione al secondo peer, che risponde con un answer. Dopo lo scambio SDP, ogni peer avvia ICE e lancia DTLS-SRTP per la crittografia del flusso.

// Android — creazione e invio di offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Invia sdp.description al server di segnalazione
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protocolli di segnalazione

Per le app mobili, la segnalazione più popolare è tramite WebSocket — un canale bidirezionale su TCP che mantiene una connessione persistente con il server. Il server di segnalazione è spesso un microservizio separato (Node.js, Golang, Elixir) che instrada i messaggi tra i partecipanti della stanza.

• WebSocket — connessione bidirezionale persistente, overhead minimo, scelta standard per la segnalazione
• SIP su WebSocket — protocollo VoIP standard, si integra con l'infrastruttura telefonica esistente
• MQTT — protocollo pub/sub leggero per IoT e reti deboli, ma con latenza maggiore
• Matrix / XMPP — protocolli decentralizzati per applicazioni incentrate sulla privacy

Dopo il completamento di ICE e DTLS-SRTP, la segnalazione non partecipa più alla trasmissione dei dati — tutto il traffico multimediale fluisce direttamente P2P (o tramite un relay TURN). Il server di segnalazione può essere spento senza interrompere le chiamate attive. Questo è il vantaggio chiave dell'architettura decentralizzata di WebRTC.