knowledge-base

SIP-fundamenten: wat elke ontwikkelaar moet weten

Een evergreen kennisbankartikel uit de pronk.it-redactie — SIP-fundamenten: wat elke ontwikkelaar moet weten.

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

TL;DR

Inleiding

Session Initiation Protocol (SIP) is het de facto standard voor signaling in Voice over IP (VoIP), videoconferentie en andere realtime multimedia‑toepassingen. Gedefinieerd in RFC 3261 en uitgebreid door tal van aanvullende RFC’s, beschrijft SIP hoe eindpunten sessies kunnen initiëren, wijzigen en beëindigen, ongeacht het onderliggende transportmedium. Het protocol is bewust ontworpen om extensibel te zijn, waardoor nieuwe functies zoals aanwezigheid, instant messaging en‑lijn‑integratie zonder wijziging van de kernspecificatie kunnen worden toegevoegd.

Voor ontwikkelaars, VoIP‑ingenieurs en PBX‑beheerders is een grondig begrip van SIP essentieel om interoperabele systemen te bouwen, problemen te diagnosticeren en beveiliging te waarborgen. In dit artikel worden de kernconcepten, message‑structuur, veelgebruikte methoden en statuscodes, beveiligingsmechanismen en praktische aandachtspunten voor NAT‑traversal behandeld. Alle verwijzingen verwijzen naar openbaar beschikbare specificaties en standaarden, zodat de informatie toekomstbestendig blijft.

SIP basis en message flow

SIP berichten zijn tekstueel en bestaan uit een startlijn, één of meer header‑velden, een lege lijn en optioneel een lichaam. De startlijn geeft aan of het een verzoek (request) of een antwoord (response) is. Een verzoek begint met een methode, gevolgd door het SIP‑adres van de bestemming en de SIP‑versie. Een antwoord start met de SIP‑versie, een numerieke statuscode en een reden‑tekst.

Voorbeeld van een INVITE‑verzoek:

INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Bob <sip:bob@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

v=0
o=bob 2890844526 2890844526 IN IP4 pc33.atlanta.com
s=-
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Het antwoord kan bijvoorbeeld 100 Trying, 180 Ringing en uiteindelijk 200 OK bevatten. Bij 200 OK bevat het lichaam vaak de SDP‑beschrijving van de antwoordende partij, waarna de mediastream direct tussen de peers wordt opgezet (of via een media‑relay, afhankelijk van de architectuur).

SIP maakt gebruik van het concept van een dialog: een peer‑to‑peer relatie tussen twee gebruikersagents die een reeks uitwisselingen omvat, bijvoorbeeld een volledige telefoongesprek. Een dialog wordt uniek geïdentificeerd door de combinatie van Call-ID, From‑tag en To‑tag. Dit maakt het mogelijk om latere verzoeken (bijvoorbeeld BYE of UPDATE) binnen dezelfde sessie te correleren zonder de volledige adressering opnieuw te versturen.

SIP methoden en statuscodes

SIP definieert een set kernmethoden die elk een specifieke actie uitvoeren. De belangrijkste zijn:

Methode Doel
INVITE Start een sessie of wijzig bestaande parameters (bijv. codec‑wissel).
ACK Bevestigt de ontvangst van een final response op een INVITE.
BYE Beëindigt een dialoog.
OPTIONS Vraag capaciteiten op zonder sessie te starten.
REGISTER Registreert een gebruikersagent bij een SIP‑registrar (bijv. een PBX).
SUBSCRIBE / NOTIFY Implementeert event‑notification (bijv. aanwezigheid).
MESSAGE Verzendt instant‑messaging payload.
INFO Verzendt mid‑session signaling (bijv. DTMF‑tonen).
UPDATE Wijzig sessieparameters zonder de dialog‑staat te veranderen.
PRACK Bevestigt provisional responses (betrouwbaarheid).

Elke methode kan worden gecombineerd met verschillende header‑velden om het gedrag te finetunen, zoals Route voor het specificeren van een proxy‑pad of Expires voor de levensduur van een registratie.

Statuscodes zijn ingedeeld in zes klassen, vergelijkbaar met HTTP:

Het begrijpen van welke code bij welke fase hoort, is cruciaal voor het debuggen van call‑flows. Een veelvoorkomend patroon is bijvoorbeeld: INVITE → 100 Trying → 180 Ringing → 200 OK → ACK → [media] → BYE → 200 OK.

SIP headers en body (SDP)

SIP maakt uitgebreid gebruik van header‑velden om informatie over het verzoek, de routering, authenticatie en de mediabeschrijving over te brengen. Enkele belangrijke headers zijn:

Het lichaam bevat vaak een Session Description Protocol (SDP) blok, gedefinieerd in RFC 4566. SDP beschrijft de mediastreams: codec‑keuzes, poortnummers, transportprotocol (RTP/AVP of RTP/SAVP voor versleutelde streams), en attributen zoals a=rtpmap, a=crypto (voor SRTP) en a=ice‑ufrag / a=ice‑pwd (voor ICE‑candidates). Een typisch SDP‑fragment voor een audio‑stream met PCMU en een versleutelde variant:

m=audio 5004 RTP/SAVP 98 99
a=rtpmap:98 PCMU/8000
a=rtpmap:99 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7FQ==
a=sendrecv

Het correct parseren en genereren van SDP is essentieel voor interoperabiliteit tussen verschillende vendors, aangezien subtiele verschillen in attribute‑ordering of‑waarden het media‑nego­tiatieproces kunnen verstoren.

Beveiliging: TLS en SRTP

Standaard SIP wordt verzonden over UDP of TCP zonder versleuteling, waardoor signaling gevoelig is voor afluisteren en manipulatie. Om dit tegen te gaan, biedt SIP twee primaire beveiligingslagen:

  1. Transport Layer Security (TLS) voor de signaling zelf. SIP‑over‑TLS wordt aangeduid met het schema sips: in plaats van sip: en gebruikt poort 5061 standaard. Het handshake-proces verifieert de servercertificaat (eventueel met wederzijdse authenticatie) en versleutelt alle daaropvolgende SIP‑berichten. Voorbeelden van een Via‑header met TLS:

    Via: SIP/2.0/TLS pc33.atlanta.com;branch=z9hG4bK776asdhds;received=192.0.2.1

  2. Secure Real-time Transport Protocol (SRTP) voor de mediastream. SRTP wordt onderhandeld via SDP‑attributen zoals a=crypto. Het combineert AES‑versleuteling met HMAC‑authenticatie om vertrouwelijkheid en integriteit van audio‑ en videopakketten te garanderen. Een voorbeeld van een crypto‑lijn:

    a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7FQ==

Bij het implementeren van beveiliging moet men letten op:

Interoperabiliteit en NAT traversal (STUN/TURN, ICE)

Een veelvoorkomend obstakel in VoIP‑implementaties is Network Address Translation (NAT). Omdat SIP‑adressen vaak privé‑IP‑adressen bevatten, kan directe media‑uitwisseling mislukken wanneer beide partijen achter een NAT zitten. Het oplossen hiervan vereist een combinatie van signaling‑aanpassingen en mediapath‑technieken.

STUN (Session Traversal Utilities for NAT) – RFC 5389 – stelt een client in staat zijn publieke IP‑adres en poort te ontdekken door een verzoek naar een STUN‑server te sturen. Het antwoord bevat het gemapte adres dat vervolgens in de SDP‑c= en m= lijnen kan worden geplaatst.

TURN (Traversal Using Relays around NAT) – RFC 5766 – biedt een relay‑server wanneer directe UDP‑connectie niet mogelijk is (bijv. symmetrische NAT). De client stuurt haar media naar de TURN‑server, die deze doorstuurt naar de andere partij.

ICE (Interactive Connectivity Establishment) – RFC 8445 – combineert STUN en TURN om het beste pad te vinden. Kandidaten (lokale, geriflexeerde, relay) worden uitgewisseld via SDP‑attributen a=ice-ufrag, a=ice-pwd en een reeks a=candidate regels. Het proces verloopt als volgt:

  1. Elk eindpunt verzamelt kandidaten (lokale adressen, gesteunde adressen van STUN, relay‑adressen van TURN).
  2. Deze kandidaten worden in het SDP‑lichaam opgenomen.
  3. Via signaling wordt de lijst met kandidaten uitgewisseld.
  4. Beide partijen voeren connectiviteitstests uit (STUN‑binding requests) om het werkzaamste paar te bepalen.
  5. Het gekozen paar wordt gebruikt voor de daadwerkelijke RTP/SRTP‑stroom.

Een vereenvoudigd voorbeeld van een ICE‑gevulde SDP‑sectie:

m=audio 9 UDP/TLS/RTP/SAVPF 98 99
c=IN IP4 203.0.113.1
a=ice-ufrag:8hhY
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-options:trickle
a=candidate:1 1 UDP 2122260223 192.168.1.10 5060 typ host
a=candidate:2 1 UDP 1686052607 203.0.113.1 5062 typ srflx raddr 192.168.1.10 rport 5060
a=candidate:3 1 TCP 1690828800 10.0.0.2 8888 typ relay raddr 203.0.113.1 rport 5566

Door deze technieken te combineren, kunnen VoIP‑systemen betrouwbaar werken in diverse netwerkomgevingen, van eenvoudige thuisrouters tot complexe bedrijfsfirewalls.

Praktische checklist

Verder lezen

Met deze kennis kunnen ontwikkelaars en engineers robuuste, beveiligde en NAT‑bestendige SIP‑implementaties bouwen die voldoen aan de eisen van moderne communicatienetwerken.