WebRTC: wat is het, architectuur en werkingsprincipe

Wat is WebRTC

WebRTC (Web Real-Time Communication) is een open-sourceproject dat in 2011 door Google is gestart en gestandaardiseerd door W3C (JavaScript API) en IETF (protocollen). De belangrijkste taak is het bieden van laag-latency communicatie tussen browsers en apps zonder plug-ins of software van derden te installeren.

In tegenstelling tot traditionele oplossingen (RTMP, HLS) waarbij video via een server loopt, maakt WebRTC gebruik van peer-to-peer architectuur: gegevens worden rechtstreeks tussen deelnemers verzonden. Dit levert een vertraging op van 200-500 ms versus 3-10 seconden bij HLS — een kritisch verschil voor spraak- en video-oproepen, game-streaming en chirurgie op afstand.

Volgens Google WebRTC Team (2025) wordt de technologie gebruikt in apps met in totaal meer dan 5 miljard installaties: Google Meet, WhatsApp, Discord, Telegram, Zoom (gedeeltelijk). Meer dan 85% van de venture capital-startups in telehealth en edtech kiezen voor WebRTC als primair real-time transport.

Mobiele ontwikkeling kreeg volledig functionele WebRTC in 2013 met de release van libjingle_peerconnection — een native implementatie voor Android en iOS. Momenteel hebben beide platforms stabiele SDK's met ondersteuning voor hardwarecodering van H.264 en VP8, camera, microfoon en luidsprekers van het apparaat.

WebRTC architectuur en protocollen

De WebRTC-architectuur bestaat uit drie niveaus. Het bovenste niveau — JavaScript API (of native API voor mobiele platforms), het middelste — transportprotocollen, het onderste — codecs en beveiliging. Elk niveau lost zijn eigen taak op, maar ze zijn allemaal noodzakelijk om een verbinding tot stand te brengen.

Belangrijkste WebRTC API's

MediaStream (getUserMedia) — vastleggen van audio en video van de microfoon en camera van het apparaat. RTCPeerConnection — beheer van P2P-verbinding: codering, transport, bitrate-aanpassing. RTCDataChannel — verzenden van willekeurige gegevens (tekst, bestanden, binaire berichten) via hetzelfde kanaal.

// JavaScript API WebRTC (browservoorbeeld)
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);

Real-time protocollen

WebRTC gebruikt SRTP (Secure Real-Time Transport Protocol) voor audio en video — een beveiligde versie van RTP met AES-128-versleuteling. Sessiebeheer verloopt via SCTP (Stream Control Transmission Protocol) via DTLS. Elke gegevensstroom wordt verplicht versleuteld: in WebRTC bestaat er geen onbeveiligde modus.

• SRTP/SRTCP — versleutelde overdracht van mediastromen met bescherming tegen replay-aanvallen
• DTLS-SRTP — instellen van versleutelingssleutels via Datagram TLS via UDP
• SCTP — betrouwbare of gedeeltelijk betrouwbare levering van gegevens voor DataChannel
• ICE (Interactive Connectivity Establishment) — framework voor het vinden van een netwerkpad tussen peers
• Trickle ICE — incrementele versie van ICE waarbij kandidaten worden verzonden zodra ze worden ontdekt, wat het opzetten van de verbinding versnelt

NAT traversal: ICE, STUN en TURN

De belangrijkste technische uitdaging van WebRTC is het tot stand brengen van een P2P-verbinding tussen apparaten die zich achter NAT (Network Address Translation) bevinden. Zonder speciale mechanismen kunnen apparaten elkaar niet rechtstreeks bereiken, omdat hun lokale IP-adressen niet zichtbaar zijn vanaf internet.

STUN — bepalen van het openbare adres

STUN (Session Traversal Utilities for NAT) — server die antwoord geeft op de vraag „wat is mijn openbare IP en poort?”. De client stuurt een verzoek naar de STUN-server, de server ziet zijn openbare adres en retourneert dit naar de client. Google biedt openbaar de STUN-server aan stun:stun.l.google.com:19302.

// WebRTC op iOS — configuratie van ICE-servers
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 — relay-verbinding

TURN (Traversal Using Relays around NAT) — retransmissieserver voor gevallen waarin STUN niet helpt (symmetrische NAT of bedrijfsfirewalls). In deze modus gaan alle gegevens via de TURN-server — dit vermindert de snelheid en verhoogt de vertraging, maar garandeert verbinding in 99% van de gevallen.

TURN is de duurste component van de WebRTC-infrastructuur, omdat de server al het mediacontrole door zichzelf laat passeren. Volgens Coturn Project (2025) verwerkt een typische TURN-server met 8 vCPU en 16 GB RAM ongeveer 200 gelijktijdige audio-oproepen of 40 video-oproepen in HD-kwaliteit.

ICE-proces

ICE verzamelt alle mogelijke kandidaten (lokaal IP, openbaar IP via STUN, relay via TURN) en probeert de verbinding in volgorde van prioriteit tot stand te brengen. Zodra ten minste één paar kandidaten (lokaal-remote) de connectivity check doorstaat, wordt de verbinding als tot stand gebracht beschouwd.

• Host candidates — lokaal IP-adres van het apparaat in het subnet (snelste, maar werkt niet achter NAT)
• Server Reflexive candidates — openbaar IP verkregen via STUN-server
• Relay candidates — adres van de TURN-server waarlangs de retransmissie plaatsvindt (langzaamste, meest betrouwbaar)

WebRTC in mobiele apps

Voor mobiele ontwikkeling onderhoudt Google libWebRTC — een native bibliotheek voor Android (AAR) en iOS (XCFramework). De bibliotheek bevat de volledige protocolstack, codecs (VP8, VP9, H.264, AV1) en hardwareversnelling voor codering/decodering.

WebRTC op Android

Android SDK biedt de klassen PeerConnectionFactory, PeerConnection, MediaStream. De app maakt een factory aan, configureert videocodecs, legt de stream van de camera vast via VideoCapturer en brengt een peer-to-peer verbinding tot stand via SDP offer/answer.

// Android WebRTC — initialisatie
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 op iOS

iOS SDK gebruikt Objective-C API met wrappers RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Hardwarecodering van H.264 is beschikbaar via VideoToolbox. Voor het weergeven van video wordt RTCMTLVideoView (Metal) of RTCVideoRenderer gebruikt.

// iOS WebRTC — videocaptuur van camera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Camerasselectie (voor/achter)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Starten van captuur met maximale FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Voor video-oproepen in productie gebruiken mobiele apps meestal SDK-wrappers over libWebRTC: Twilio Video, Agora, Daily.co. Deze SDK's vereenvoudigen signalering, kamerbeheer en bieden kant-en-klare UI-componenten voor het weergeven van het videorooster van deelnemers.

Signalering en verbinding opzetten

WebRTC specificeert geen signaleringsprotocol — uitwisseling van SDP-berichten (Session Description Protocol) tussen peers. De ontwikkelaar kiest zelf het transport voor signalering: WebSocket, MQTT, SIP, XMPP of REST API. Signalering levert offer, answer en ICE-kandidaten van de ene peer naar de andere.

SDP Offer/Answer-uitwisseling

Het proces begint met het maken van een offer (de initiator beschrijft zijn mediamogelijkheden), wordt via signalering naar de tweede peer gestuurd, die antwoordt met een answer. Na SDP-uitwisseling start elke peer ICE en initieert DTLS-SRTP voor het versleutelen van de stream.

// Android — aanmaken en verzenden van 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)
            // Verzenden van sdp.description naar signaleringsserver
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Signaleringsprotocollen

In mobiele apps is signalering via WebSocket het populairst — een bidirectioneel kanaal via TCP dat een permanente verbinding met de server onderhoudt. De signaleringsserver is vaak een aparte microservice (Node.js, Golang, Elixir) die berichten routeert tussen kamerdeelnemers.

• WebSocket — permanente bidirectionele verbinding, minimale overhead, standaardkeuze voor signalering
• SIP over WebSocket — standaard VoIP-protocol, integreert met bestaande telefooninfrastructuur
• MQTT — lichtgewicht pub/sub-protocol voor IoT en zwakke netwerken, maar met meer vertraging
• Matrix / XMPP — gedecentraliseerde protocollen voor apps met privacyvereisten

Na voltooiing van ICE en DTLS-SRTP neemt signalering niet langer deel aan gegevensoverdracht — al het mediacontrole gaat rechtstreeks P2P (of via TURN-relay). De signaleringsserver kan worden uitgeschakeld zonder actieve oproepen te onderbreken. Dit is het belangrijkste voordeel van de gedecentraliseerde architectuur van WebRTC.