Ik heb zes jaar lang dingen gebouwd op WebRTC, en ik ben nog steeds van mening dat het een van de meest onderschatte onderdelen van de webinfrastructuur is. Telkens wanneer je een Google Meet-gesprek voert, je scherm deelt in Discord, of je aansluit bij een telehealth-afspraak via je browser -- doet WebRTC het zware werk. Maar de meeste developers die ik spreek behandelen het als een black box. Ze pakken een library, verbinden wat event handlers en hopen het beste.

Dat werkt totdat het niet meer werkt. En wanneer het niet werkt -- wanneer gesprekken afbreken achter bedrijfsfirewalls, wanneer de videokwaliteit op mobiel instort, wanneer je niet uit kunt zoeken waarom er twee seconden vertraging is -- moet je echt begrijpen wat eronder gebeurt. Dus laten we dit ding openen.

Inhoudsopgave

How WebRTC Works in 2026: A Developer's Deep Dive

Wat is WebRTC eigenlijk?

WebRTC (Web Real-Time Communication) is een open-source set van protocollen, API's en standaarden waarmee browsers en mobiele apps audio, video en willekeurige data in real-time kunnen uitwisselen. Google gaf het project oorspronkelijk in 2011 vrij, het W3C standaardiseerde het in 2021, en in 2026 is het ingebouwd in vrijwel elke moderne browser -- Chrome, Firefox, Safari, Edge en hun mobiele tegenhangers.

Het sleutelonderdeel achter WebRTC is peer-to-peer-communicatie. In plaats van je videogesprek via een centrale server te leiden (wat latentie toevoegt en geld kost), probeert WebRTC een directe verbinding tussen twee apparaten tot stand te brengen. Je laptop communiceert rechtstreeks met de laptop van je collega. De rol van de server is minimaal -- het helpt gewoon de twee peers elkaar te vinden.

Natuurlijk doet "probeert" veel werk in die zin. De realiteit van NAT's, firewalls en bedrijfsnetwerken betekent dat directe verbindingen niet altijd mogelijk zijn. WebRTC heeft een volledig subsysteem gewijd aan het oplossen van dat probleem, waar we later op ingaan.

Maar eerst, de bouwstenen.

De drie kern-API's

WebRTC exposeert drie hoofdstuk JavaScript-API's. Begrijpen wat elk ervan doet is essentieel voordat je één regel code schrijft.

getUserMedia (MediaDevices API)

Dit is hoe je de camera en microfoon opent. Het retourneert een MediaStream-object met audio- en/of videotracks.

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  },
  audio: {
    echoCancellation: true,
    noiseSuppression: true,
    autoGainControl: true
  }
});

Let op die audio-constraints. WebRTC verwerkt echoonderdrukking en ruisonderdrukking op browserniveau -- je hoeft geen eigen audioverwerkingspijplijn in te brengen voor basisgebruik. In 2026 is browserinherent ruisonderdrukking opmerkelijk goed geworden, hoewel veel apps nog steeds AI-aangedreven modellen erbovenop leggen voor betere resultaten.

Je kunt ook getDisplayMedia() gebruiken voor schermsharing, die hetzelfde patroon volgt maar de gebruiker vraagt een scherm, venster of tabblad te selecteren.

RTCPeerConnection

Dit is het werkpaard. RTCPeerConnection vertegenwoordigt een verbinding tussen je lokale apparaat en een externe peer. Het verwerkt:

  • Codec-onderhandeling (welke formaten beide zijden begrijpen)
  • ICE-candidaatverzameling (het bepalen van netwerkpaden)
  • DTLS-handshake (versleuteling)
  • SRTP-mediatransport (werkelijke audio-/videogegevens)
  • Bandbreedteschatting en -aanpassing
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:your-turn-server.com:443',
      username: 'user',
      credential: 'pass'
    }
  ]
});

// Add local tracks to the connection
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Handle incoming tracks from the remote peer
pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0];
};

Eén RTCPeerConnection kan meerdere audio- en videotracks tegelijkertijd dragen. Je hebt geen afzonderlijke verbindingen nodig voor audio en video.

RTCDataChannel

Deze wordt vaak over het hoofd gezien, maar het is ongelooflijk nuttig. RTCDataChannel laat je willekeurige gegevens tussen peers verzenden -- tekstberichten, bestandsblokken, spelstatus, sensorgegevens, wat je ook nodig hebt.

const dataChannel = pc.createDataChannel('chat', {
  ordered: true,
  maxRetransmits: 3
});

dataChannel.onopen = () => {
  dataChannel.send(JSON.stringify({ type: 'message', text: 'Hello!' }));
};

dataChannel.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
};

Gegevenskanalen gebruiken SCTP (Stream Control Transmission Protocol) over DTLS, en je kunt ze configureren als geordend of ongeordend, betrouwbaar of onbetrouwbaar. Voor iets als een chatfunctie wil je geordend en betrouwbaar. Voor realtime spelstatus wil je misschien ongeordend en onbetrouwbaar om versheid boven volledigheid te prioriteren.

Signalering: Het gedeelte dat WebRTC niet behandelt

Hier stranden de meeste developers wanneer zij WebRTC voor het eerst tegenkomen: de spec definieert opzettelijk niet hoe peers elkaar vinden. WebRTC verwerkt alles nadat twee peers van elkaar afweten, maar de initiële ontdekking -- signalering genoemd -- wordt volledig aan jou overgelaten.

Signalering omvat het uitwisselen van twee soorten informatie:

  1. Sessiebeschrijvingen (SDP): Deze beschrijven welke mediaformaten, codecs en mogelijkheden elke peer ondersteunt.
  2. ICE-kandidaten: Dit zijn potentiële netwerkpaden die de verbinding zou kunnen gebruiken.

De uitwisseling volgt een aanbieding/antwoord-model:

// Peer A creates an offer
const offer = await pcA.createOffer();
await pcA.setLocalDescription(offer);
// Send offer to Peer B through your signaling server

// Peer B receives the offer and creates an answer
await pcB.setRemoteDescription(offer);
const answer = await pcB.createAnswer();
await pcB.setLocalDescription(answer);
// Send answer back to Peer A

// Peer A receives the answer
await pcA.setRemoteDescription(answer);

Je kunt je signaleringserver implementeren met WebSockets, Server-Sent Events, HTTP-polling, Firebase Realtime Database -- letterlijk alles dat berichten tussen twee clients kan doorgeven. Ik heb productiesystemen gezien met alles van Socket.io tot gewone REST API's met polling.

Het SDP-formaat zelf is... nou ja, laten we eerlijk zijn, het is lelijk. Het is een tientallen jaren oud tekstformaat dat er als volgt uitziet:

v=0
o=- 4611731400430051336 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 49170 RTP/SAVPF 111 103 104
a=rtpmap:111 opus/48000/2

Je hoeft SDP zelden handmatig te parseren, maar begrijpen dat het codecvoorkeuren, versleutelingsparameters en ICE-referenties bevat helpt enorm bij het debuggen van verbindingsproblemen.

How WebRTC Works in 2026: A Developer's Deep Dive - architecture

De connection dance: ICE, STUN en TURN

Dit is waar WebRTC werkelijk geniaal wordt -- en werkelijk ingewikkeld. Het probleem: de meeste apparaten op het internet staan achter NAT (Network Address Translation). Je laptop heeft geen openbaar IP-adres. Dat geldt ook niet voor je telefoon. Hoe spreken twee apparaten achter verschillende NAT's rechtstreeks met elkaar?

WebRTC gebruikt een framework genaamd ICE (Interactive Connectivity Establishment) om dit uit te zoeken.

STUN: Je openbare adres ontdekken

Een STUN-server (Session Traversal Utilities for NAT) is licht. Je browser stuurt er een verzoek heen en de STUN-server antwoordt met je openbare IP-adres en poort -- het adres zoals gezien van buiten. Stel je voor dat je iemand op straat vraagt "wat is mijn adres?" als je in een gebouw bent.

STUN-servers zijn goedkoop in gebruik en Google biedt gratis servers aan (zoals stun.l.google.com:19302). Ze sturen geen media door -- ze zeggen je gewoon wat je openbaar zichtbare adres is.

TURN: De relay-fallback

Soms zijn directe peer-to-peer-verbindingen gewoon onmogelijk. Symmetrische NAT's, bedrijfsfirewalls en bepaalde mobiele operatorconfiguraties blokkeren directe verbindingen. Als dat gebeurt, heb je een TURN-server (Traversal Using Relays around NAT) nodig.

Een TURN-server stuurt al het mediaverkeer tussen peers door. Dit betekent:

  • Hogere latentie (verkeer gaat via de relay in plaats van rechtstreeks)
  • Hogere bandbreedtekosten (je betaalt voor al dat videoverkeer)
  • Maar het werkt als niets anders werkt

In productie is voor ongeveer 10-20% van de verbindingen TURN-relay nodig, afhankelijk van je gebruikersbasis. Zakelijke gebruikers achter bedrijfsfirewalls raken dit getal veel harder -- soms 40-60%. Je moet TURN-servers draaien als je betrouwbare WebRTC in productie wilt. Ik kan dit niet genoeg benadrukken. Ik heb startups zien lanceren zonder TURN en zich dan afvragen waarom een kwart van hun gebruikers niet kan verbinden.

Het ICE-candidaatverzamelingsproces

Wanneer je een RTCPeerConnection maakt, begint ICE met het verzamelen van kandidaten -- potentiële netwerkroutes. Het verzamelt drie typen:

Candidaattype Bron Latentie Kosten
Host Lokale netwerkinterface Laagste (alleen LAN) Gratis
Server Reflexive (srflx) Ontdekt via STUN Laag Minimaal (STUN is goedkoop)
Relay Toegewezen op TURN-server Hoger Aanzienlijk (bandbreedtekosten)

ICE test vervolgens deze kandidaten in prioriteitsvolgorde en probeert eerst de snelste opties. Als een host-kandidaat werkt (beide peers op hetzelfde LAN), prima. Zo niet, dan probeert het STUN-ontdekte adressen. Als die mislukken, valt het terug op TURN-relay.

Dit gebeurt allemaal automatisch, maar je kunt ernaar kijken:

pc.onicecandidate = (event) => {
  if (event.candidate) {
    console.log('New ICE candidate:', event.candidate.type);
    // Send this candidate to the remote peer via signaling
  }
};

pc.oniceconnectionstatechange = () => {
  console.log('ICE state:', pc.iceConnectionState);
  // States: new -> checking -> connected -> completed
  // Or: new -> checking -> failed (uh oh)
};

Hoe media werkelijk stroomt

Zodra ICE een pad tot stand brengt, stroomt media over RTP (Real-time Transport Protocol), specifiek SRTP (Secure RTP) omdat WebRTC versleuteling verplicht stelt.

Hier is de vereenvoudigde stroom:

  1. Camera legt een frame vast
  2. De encoder comprimeert het met behulp van de onderhandelde codec (VP8, VP9, H.264 of AV1)
  3. Het gecomprimeerde frame wordt in RTP-pakketten opgesplitst
  4. Elk pakket wordt versleuteld met SRTP
  5. Pakketten worden verzonden via UDP (meestal) naar de externe peer
  6. De externe peer ontsleutelt, reassembleert en decodeert het frame
  7. Het frame wordt weergegeven in een <video>-element

Dit gebeurt 30 keer per seconde voor video. Voor audio (meestal Opus-codec) is het meer als 50 pakketten per seconde.

WebRTC gebruikt UDP in plaats van TCP voor mediatransport. TCP garandeert aflevering door verloren pakketten opnieuw te verzenden, wat goed klinkt totdat je je realiseert dat een opnieuw verzonden videoframe van 500ms geleden erger dan nutteloos is -- het is actief schadelijk omdat het nieuwere frames vertraagt. UDP laat WebRTC friheid boven volledigheid prioriteren, wat precies is wat je wilt voor realtime media.

RTCP: De feedbacklus

Naast RTP gebruikt WebRTC RTCP (RTP Control Protocol) om statistieken tussen peers uit te wisselen. Elke kant rapporteert:

  • Paketverliespercentage
  • Jitter (variatie in aankomsttijd van pakketten)
  • Roundtrip-tijd
  • Beschikbare bandbreedteschattingen

Deze feedback stuurt het adaptieve bitrate-systeem, waar we daarna op ingaan.

Codecs en adaptieve bitrate in 2026

WebRTC ondersteunt meerdere codecs, en het landschap is de afgelopen jaren aanzienlijk verschoven.

Videocodecs

Codec Browserondersteuning (2026) Compressie-efficiëntie CPU-gebruik Opmerkingen
VP8 Universeel Basislijn Laag Legacy, maar nog steeds de verplichte codec
VP9 Universeel ~30% beter dan VP8 Gemiddeld Grote balans voor de meeste gevallen
H.264 Universeel Vergelijkbaar met VP8 Laag (hardwareversneld) Vereist voor Safari-interop historisch
AV1 Chrome, Firefox, Safari 18+ ~30% beter dan VP9 Hoog (verbetert) De toekomst, maar CPU-kosten matteren nog steeds op mobiel

AV1-adoptie is in 2026 versneld. Ondersteuning voor hardwarecodering op nieuwere apparaten (Apple M4, recente Qualcomm Snapdragon-chips) heeft het grootste klacht opgelost -- CPU-gebruik. Voor nieuwe projecten zou ik VP9 standaard gebruiken met AV1 als voorkeur wanneer beide peers het ondersteunen.

Audiocodecs

Opus is koning. Het is sinds het begin de verplichte audiocodec voor WebRTC, en terecht -- het verwerkt alles van narrowband-spraak tot volledige bandbreedte-muziek, past zich aan aan veranderende netwerkvoorwaarden en heeft uitstekende foutverberging. Je zult zelden over audiocodecs hoeven na te denken.

Adaptieve bitrate

Dit is één van WebRTC's beste functies en het gebeurt automatisch. De zender bewaakt continu netwerkvoorwaarden via RTCP-feedback en past de coderingsbitrate in realtime aan.

Wanneer de bandbreedte afneemt (bijvoorbeeld als je met je telefoon in een lift stapt), zal WebRTC:

  1. De videoresolutie verlagen
  2. Het frame-rate verlagen
  3. Compressie verhogen (kwaliteit verminderen)

Wanneer de voorwaarden verbeteren, schaalt het terug omhoog. Google's congestiecontrolealgoritme (GCC) verwerkt dit, en in 2026 is het zo verfijnd dat het binnen seconden reageert op netwerkveranderingen. Je hoeft niets van dit zelf te implementeren -- het is ingebouwd in de WebRTC-stack van de browser.

Beveiligingsmodel: versleuteling standaard

WebRTC is ontworpen met verplichte versleuteling. Er is geen manier om het uit te schakelen. Elke WebRTC-verbinding gebruikt:

  • DTLS (Datagram Transport Layer Security): Verwerkt sleuteluitwisseling. Stel je het voor als TLS maar voor UDP.
  • SRTP (Secure Real-time Transport Protocol): Versleutelt de werkelijke mediapakketten met sleutels die zijn afgeleid van de DTLS-handshake.

Voor gegevenskanalen is de versleuteling DTLS over SCTP.

Dit betekent dat zelfs als iemand de pakketten onderschept (zoals je ISP of iemand op hetzelfde Wi-Fi-netwerk), ze de audio- of video-inhoud niet kunnen decoderen. De versleuteling loopt end-to-end tussen peers -- met één belangrijk voorbehoud.

Als je een TURN-relay-server gebruikt, kan de TURN-server de versleutelde pakketten zien maar kan ze niet decoderen. De versleuteling eindigt bij de peers, niet de relay. Echter, als je een SFU (Selective Forwarding Unit) gebruikt voor groepsgesprekken -- wat de meeste productiesystemen doen -- moet de SFU traditioneel media decoderen en opnieuw coderen. Dit is waar Insertable Streams (nu beschikbaar in alle grote browsers in 2026) belangrijk wordt, waardoor je end-to-end-versleuteling mogelijk is zelfs via een SFU door je een extra versleutelingslaag toe te staan die de SFU niet kan verwijderen.

WebRTC vs. WebTransport vs. traditionele VoIP

Ik word hierover constant gevraagd, dus laten we het uitleggen.

Functie WebRTC WebTransport Traditionele VoIP (SIP)
Transport UDP (primair) QUIC (HTTP/3) UDP/TCP
Peer-to-peer Ja Nee (client-server) Ja (in theorie)
Browserinherent Ja Ja Nee (softphone/plugin nodig)
Mediaverwerking Ingebouwd DIY Ingebouwd
Versleuteling Verplicht (DTLS/SRTP) Verplicht (TLS 1.3) Optioneel (SRTP als geconfigureerd)
Gegevenskanalen Ja (SCTP) Ja (QUIC-streams) Nee
NAT-doorgang ICE/STUN/TURN Niet nodig (op server gebaseerd) STUN/TURN of SBC
Latentie Sub-seconde Sub-seconde Sub-seconde
Beste voor P2P-gesprekken, conferencing Eenrichtingsstreaming, gaming Bedrijfstelefoonie

WebTransport, gebouwd op QUIC/HTTP/3, heeft in 2026 grip gekregen voor specifieke gebruiksgevallen -- met name eenrichtingsstream naar veel veel waar je niet de volledige peer-to-peer-machinery nodig hebt. Het vervangt WebRTC niet; het is aanvullend. Als je tweerichtingsvideooproepen bouwt, is WebRTC nog steeds de juiste keus. Als je een uitzendplatform bouwt waar één bron naar duizenden streamt, is WebTransport (of Media over QUIC, dat erop gebouwd is) het overwegen waard.

Traditionele SIP-gebaseerde VoIP verdwijnt ook niet, vooral in ondernemingen met bestaande PBX-infrastructuur. Veel productiesystemen in 2026 draaien WebRTC-naar-SIP-gateways om browsergebaseerde clients met traditionele telefoonsystemen te verbinden.

Wat is er veranderd in 2026

WebRTC in 2026 is niet fundamenteel anders dan WebRTC in 2023, maar verschillende ontwikkelingen doen eraan:

AI-integratie is mainstream geworden

Realtime-AI-functies draaien nu rechtstreeks op WebRTC-streams:

  • Achtergrondruisonderdrukking voorbij wat browsers inheems bieden (hulpmiddelen als Krisp of ingebouwde modellen in Google Meet)
  • Realtime-transcriptie en -vertaling tijdens oproepen
  • AI-spraakagenten die als peers deelnemen aan WebRTC-oproepen, klantenservice verhandelen of vergadersamenvattingen leveren
  • Sentimentanalyse op audiostreams voor call-center-applicaties

Het lage-latentie-transport dat WebRTC biedt is precies wat deze AI-modellen nodig hebben. Je kunt geen realtime-transcriptie draaien op een stream met twee seconden vertraging.

AV1-hardwarecodering is echt

Ik noemde dit in de codecssectie, maar het verdient herhaling. AV1-ondersteuning voor hardwareencoder op nieuwere chips heeft het praktisch gemaakt voor realtime-gebruik. Je krijgt VP9-niveau CPU-gebruik met 30% betere compressie. Voor bandbreedtebeperkte scenario's (mobiel, ontwikkelingslanden) is dit een groot verschil.

WebCodecs API-volwassenheid

De WebCodecs API geeft je toegang tot de ingebouwde encoder/decoder van de browser zonder door de volledige WebRTC-stack te gaan. Dit is nuttig als je lage-niveaucontrole nodig hebt -- aangepaste videonverwerkingspijplijnen, codering voor opname terwijl je streamt, of het voeden van frames in ML-modellen. Het werkt goed met WebRTC's Insertable Streams voor aangepaste verwerking.

Verbeterde browserpariteit

Safari is historisch het probleemkind voor WebRTC geweest. In 2026 heeft Safari 18+ de meeste gaten gesloten -- simulcast werkt correct, Insertable Streams worden ondersteund en AV1-decodering is beschikbaar. Je moet nog steeds over browsers testen, maar de tijd van het schrijven van Safari-specifieke workarounds ligt grotendeels achter ons.

Bouwen met WebRTC: praktische overwegingen

Als je een product bouwt dat WebRTC gebruikt, is dit waar ik over zou nadenken:

Bouw je eigen SFU niet (waarschijnlijk)

Voor 1:1-oproepen is directe peer-to-peer prima. Voor groepsgesprekken met meer dan 3-4 deelnemers heb je een Selective Forwarding Unit nodig. Het bouwen van één vanaf nul is een serieuze onderneming. Overweeg open-source opties zoals mediasoup, Janus of Pion (op Go gebaseerd), of beheerde services als Twilio, Daily.co, LiveKit of Agora.

Budget voor TURN-servers

Gebruik coturn (open-source) of een beheerde TURN-service. Voer TURN uit op poort 443/TCP als fallback -- bepaalde bedrijfsfirewalls blokkeren alles behalve HTTP/HTTPS-poorten. Budget $200-500/maand voor een bescheiden implementatie; videorelay-bandbreedte loopt op.

Test op echte netwerken

WebRTC werkt prachtig op localhost. Het valt op interessante manieren uiteen op overvolle Wi-Fi, mobiele netwerken en achter bedrijfsproxy's. Chrome's chrome://webrtc-internals is je beste vriend voor debugging -- het toont ICE-candidaatverzameling, codec-onderhandeling, bandbreedteschattingen en paketverlies in realtime.

Overweeg je frontend-architectuur

Als je een webtoepassing bouwt die WebRTC-functies bevat, is het frontend-framework van belang. We hebben realtime-samenwerkingsfuncties in Next.js-applicaties gebouwd waar WebRTC-gegevenskanalen live-cursors en gedeelde status voeden. Voor inhoudszware sites met af en toe realtime-functies laat Astro's eilandarchitectuur je WebRTC-code alleen laden wanneer nodig, waardoor de initiële bundel slank blijft.

Als je een aangepaste WebRTC-oplossing nodig hebt geïntegreerd met een headless CMS -- bijvoorbeeld voor een telehealth-platform of live commerce-site -- dat is het soort project waar het goed architecturaal overeenkomen van het begin maanden pijn later spaart. Aarzel niet om contact op te nemen als je je specifieke setup wilt bespreken.

Veelgestelde vragen

Werkt WebRTC helemaal zonder server? Niet helemaal. Je hebt altijd een signaleringserver nodig om peers te helpen verbindingsinformatie uit te wisselen (SDP-aanbiedingen/antwoorden en ICE-kandidaten). Je zult ook op z'n minst een STUN-server nodig hebben voor NAT-doorgang, en realistisch gezien een TURN-server voor betrouwbaarheid. Maar de werkelijke media kan peer-to-peer stromen zonder je servers aan te raken.

Waarom mislukken WebRTC-verbindingen soms achter bedrijfsfirewalls? Bedrijfsfirewalls blokkeren vaak UDP-verkeer en beperken uitgaande verbindingen tot alleen poorten 80 en 443. Omdat WebRTC primair UDP gebruikt op dynamische poorten, kan dit directe verbindingen voorkomen en zelfs STUN blokkeren. De oplossing is het uitvoeren van een TURN-server op poort 443 met TCP, die eruit ziet als normaal HTTPS-verkeer naar de firewall. Dit is waarom TURN-infrastructuur niet onderhandelbaar is voor ondernemingsimplementaties.

Hoe gaat WebRTC om met slechte of fluctuerende netwerkvoorwaarden? WebRTC gebruikt adaptieve bitrate-codering. Het bewaakt continu paketverlies, jitter en beschikbare bandbreedte via RTCP-feedback, en past de coderingsklaliteit in realtime aan. Op een slechte verbinding zie je lagere resolutie en frame-rate in plaats van bevrozen video. Google's congestiecontrolealgoritme (GCC) beheert dit automatisch -- je hoeft het niet zelf te implementeren.

Kan WebRTC schalen naar honderden of duizenden kijkers? Niet met pure peer-to-peer -- elke deelnemer zou een directe verbinding met alle anderen nodig hebben. Voor grote groepen (meer dan ~4 personen) heb je een Selective Forwarding Unit (SFU) nodig die de stream van elke deelnemer ontvangt en naar iedereen doorwerkt. Voor uitzending naar duizenden zou je WebRTC-opname met een CDN of een WebRTC-gebaseerd streamingplatform gebruiken dat fan-out verwerkt.

Is WebRTC versleuteld? Kan mijn ISP mijn videogesprekken zien? Ja, alle WebRTC-media is versleuteld met DTLS voor sleuteluitwisseling en SRTP voor mediatransport. Deze versleuteling is verplicht -- je kunt het letterlijk niet uitschakelen. Je ISP kan zien dat je een WebRTC-verbinding maakt en hoeveel gegevens stromen, maar ze kunnen de werkelijke audio- of video-inhoud niet decoderen.

Wat is het verschil tussen WebRTC en WebSockets voor realtime-functies? WebSockets zijn TCP-gebaseerd en ontworpen voor betrouwbare, geordende berichtaflevering -- perfect voor chat, meldingen en signalering. WebRTC gebruikt UDP voor mediatransport, waardoor lage latentie boven gegarandeerde aflevering wordt prioriteit, en ondersteunt peer-to-peer-verbindingen. Gebruik WebSockets voor je signaleringserver en tekstgebaseerde realtime-functies; gebruik WebRTC als je audio, video of lage-latentie-gegevenskanalen nodig hebt.

Moet ik WebRTC of WebTransport gebruiken voor mijn streamingproject in 2026? Het hangt af van de richting van de communicatie. Voor tweerichtingsinteractieve streaming (videogesprekken, telehealth, live commerce met publieksinteractie) is WebRTC de duidelijke keus. Voor één-naar-veel-uitzendstreaming waar sub-seconde latentie belangrijk is maar interactiviteit beperkt is, is WebTransport (en de opkomende Media over QUIC-standaard) het overwegen waard. Veel platforms gebruiken beide -- WebRTC voor opname en interactie, WebTransport of HLS/DASH voor distributie op grote schaal.

Welke hardware/bandbreedte heb ik nodig voor WebRTC-videogesprekken? Voor een 720p-videogesprek reken je op ongeveer 1,5-2 Mbps upload en download per deelnemer. 1080p duwt dat naar 2,5-4 Mbps. Elk modern apparaat (laptop, telefoon, tablet uit de afgelopen 5 jaar) heeft genoeg CPU voor WebRTC. Het knelpunt is bijna altijd netwerkklaliteit -- met name uploadbandbreedte en netwerkstabiliteit -- in plaats van verwerkingskracht.