knowledge-base

WebRTC vs SIP: wanneer welke kiezen

Een evergreen kennisbankartikel uit de pronk.it-redactie — WebRTC vs SIP: wanneer welke kiezen.

The pronk.it editorial team (AI-assisted, human-reviewed) · · 7 min lezen

TL;DR

Inleiding

Session Initiation Protocol (SIP) en Web Real‑Time Communication (WebRTC) zijn beide fundamentele technologieën voor realtime communicatie over IP‑netwerken, maar ze dienen verschillende lagen van de stack. SIP is een gestandaardiseerd signaling‑protocol (RFC 3261 en gerelateerde RFC’s) dat vooral wordt gebruikt door VoIP‑centrales, SIP‑telefoons en sessie‑border‑controllers om oproepen tot stand te brengen en te beheren. WebRTC daarentegen is een verzameling JavaScript‑API’s en native‑code onderdelen die browsers en mobiele apps in staat stellen om directe audio‑, video‑ en datakanalen op te zetten zonder tussenkomst van een plugin of aparte client‑software.

Hoewel beide technologieën uiteindelijk media‑stromen kunnen transporteren, verschillen ze sterk in hoe signaling wordt afgehandeld, welke infrastructuur nodig is en welke gebruiksscenario’s het meest geschikt zijn. In dit artikel worden de technische verschillen, voor‑ en nadelen en praktische richtlijnen vergeleken, zodat VoIP‑ingenieurs, PBX‑beheerders en technische besluitvormers een gefundeerde keuze kunnen maken tussen een puur SIP‑gebaseerde oplossing, een WebRTC‑gebaseerde oplossing of een hybride architectuur waarin beide elkaar aanvullen.

Technische grondslagen

SIP werkt op de toepassingslaag en maakt gebruik van tekst‑gebaseerde berichten die sterk lijken op HTTP‑verzoeken en -antwoorden. Een typisch SIP‑dialog begint met een INVITE‑verzoek, wordt bevestigd met een 200 OK‑antwoord en afgesloten met een BYE. Het protocol definieert een set methoden (INVITE, ACK, BYE, REGISTER, OPTIONS, SUBSCRIBE, NOTIFY, MESSAGE, INFO, UPDATE, PRACK) en een reeks statuscodes (1xx‑6xx) die de voortgang van een sessie aangeven. Het lichaam van een SIP‑bericht bevat vaak een Session Description Protocol (SDP) blok (RFC 4566) waarin codecs, poorten en mediaparameters worden onderhandeld.

WebRTC bestaat uit drie hoofd‑API’s:

  1. getUserMedia – toegang tot lokale microfoon en camera.
  2. RTCPeerConnection – onderhandeling en transport van media‑ en datakanalen via het ICE‑protocol (RFC 8445), DTLS‑versleuteling en SRTP/RTCP voor de mediastream.
  3. RTCDataChannel – willekeurige bi‑directionele data‑stroom gebaseerd op SCTP (RFC 4960).

In tegenstelling tot SIP bevat WebRTC geen ingebouwde signaling‑mechanisme; de ontwikkelaar moet zelf een weg kiezen om sessiebeschrijvingen (offer/answer) en controle‑berichten uit te wisselen. Dit kan gebeuren via WebSocket, HTTP‑polling, of zelfs via een bestaand SIP‑signaling‑kanaal (SIP‑over‑WebSocket). Omdat de media‑stack binnen de browser wordt afgehandeld, zijn er geen aparte plugins nodig en wordt gebruikgemaakt van de ingebouwde beveiligingsvoorzieningen van het browser‑sandboxmodel.

Signaling en mediawege

SIP signaling

SIP signaling wordt meestal afgehandeld door dedicated servers: registrars, proxy’s, redirect servers en session‑border‑controllers (SBC’s). Een typische call‑flow ziet er als volgt uit:

  1. UE‑A stuurt een REGISTER naar de registrar om zijn adres bekend te maken.
  2. UE‑A stuurt een INVITE naar de proxy, die het verzoek doorstuurt naar UE‑B (via een eventuele SBC voor NAT‑traversal en interworking).
  3. UE‑B antwort met 180 Ringing, vervolgens 200 OK met SDP.
  4. UE‑A bevestigt met ACK; de mediastroom wordt direct tussen de UE’s opgezet (of via een media‑relay in de SBC).
  5. Bij beëindiging stuurt een van de partijen een BYE, waarna de andere met 200 OK reageert.

Omdat signaling en media vaak gescheiden zijn, kan een SBC de media‑stroom transcoderen, opnemen of statistieken verzamelen zonder de signaling‑path te verstoren.

WebRTC signaling

WebRTC laat de keuze voor signaling volledig aan de applicatie. Een veelgebruikt patroon is een WebSocket‑verbinding naar een signaling‑server die JSON‑berichten uitwisselt. Een minimale stroom kan er als volgt uitzien:

  1. Client A maakt een RTCPeerConnection aan, genereert een offer (via createOffer) en stuurt dit via het signaling‑kanaal naar Client B.
  2. Client B ontvangt het offer, roept setRemoteDescription aan, genereert een answer (createAnswer) en stuurt dit terug.
  3. Beide partijen wisselen ICE‑candidates uit (via hetzelfde signaling‑kanaal) totdat een geldig paar is gevonden.
  4. Na succesvolle ICE‑completed‑event wordt de DTLS‑handshake uitgevoerd, waarna SRTP‑versleutelde media‑stromen worden opgezet.
  5. Data‑kanalen kunnen tegelijkertijd worden geopend via createDataChannel.

Omdat signaling losstaat van de media‑stack, kun je dezelfde signaling‑server gebruiken voor verschillende soorten clients (browser, native SDK, SIP‑gateway) zolang het formaat van de uitgewisselde berichten overeenkomen.

Browser- en apparaatondersteuning

SIP is een protocol‑agnostische standaard; elke client die een SIP‑stack kan implementeren (softphone, IP‑phone, PBX, mobiele app) kan er mee communiceren. Er zijn talloze open‑source en commerciële SIP‑bibliotheken (bijv. PJSIP, Sofia‑SIP, linphone) en veel hardware‑telefoons ondersteunen SIP natiu.

WebRTC wordt standaard ondersteund in alle moderne desktop‑browsers (Chrome, Firefox, Safari, Edge) en de meeste mobiele browsers (Chrome voor Android, Safari voor iOS). Er bestaan daarnaast native WebRTC‑SDK’s voor Android (WebRTC‑native) en iOS, waardoor dezelfde media‑stack ook buiten de browser kan worden gebruikt. Belangrijk is dat WebRTC vereist dat de client toegang heeft tot een betrouwbare signaling‑server en dat firewall‑regels UDP‑poorten voor ICE‑candidates (typisch hoog‑nummerbereik) toelaten.

Beveiliging en privacy

SIP beveiliging

Standaard SIP gebruikt UDP of TCP zonder versleuteling. Beveiliging wordt toegevoegd op twee lagen:

Voor een end‑to‑end beveiligde sessie moeten zowel signaling (sips:) als media (SRTP) versleuteld zijn. Daarnaast spelen authenticatie‑mechanismen zoals digest‑auth (RFC 3261 hoofdstuk 22) en token‑based schemes (bijv. OAuth‑2.0 voor SIP) een rol bij het voorkomen van ongeautoriseerde registraties.

WebRTC beveiliging

WebRTC dwingt beveiliging af op zowel signaling als media:

Omdat de media‑stack binnen de browser draait, profiteert WebRTC automatisch van de sandbox‑beperkingen (zelfde‑origin‑policy, CORS) en van de browser‑matige updates voor cryptografische bibliotheken.

Praktische toepassingen en hybride architecturen

Zuiver SIP‑gebaseerde systemen

Zuiver WebRTC‑gebaseerde systemen

Hybride benaderingen

Een veel voorkomend patroon is het gebruik van een SIP‑gateway die WebRTC‑clients via een signaling‑interface (bijv. SIP‑over‑WebSocket of een aangepast JSON‑protocol) verbindt met een bestaande SIP‑infrastructuur. Dit laat je profiteren van de rijke functies van een PBX (voicemail, conferentie‑bridges, call‑recording, IVR) terwijl je de gebruiksvriendelijkheid van WebRTC behoudt voor eind‑gebruikers in de browser.

Voorbeelden van hybride stromen:

  1. Browser‑client maakt een WebSocket‑verbinding naar een signaling‑server.
  2. Signaling‑server vertaalt de WebRTC‑offer/answer naar SIP‑INVITE/200 OK (met behulp van een B2BUA zoals Kamailio of Asterisk met ws module).
  3. De SIP‑kant zet de oproep door naar de PBX of naar een andere SIP‑endpoint.
  4. Media wordt, indien gewenst, doorgestuurd via een media‑relay (SBC) of blijft end‑to‑end tussen browser en de andere partij wanneer zowel beide WebRTC‑capable zijn.

Praktische checklist

Verder lezen

Met deze informatie kun je een weloverwogen beslissing nemen of je een zuiver SIP‑oplossing, een WebRTC‑oplossing of een combinatie daarvan gaat implementeren, afhankelijk van de specifieke eisen van je organisatie met betrekking tot interoperabiliteit, gebruikerservaring en operationele complexiteit.