SDP — wat is het, formaat voor sessiebeschrijving en rol in WebRTC

Wat is SDP (Session Description Protocol)?

SDP — is een protocol op applicatieniveau dat bedoeld is om parameters van multimediasessies in tekstformaat te beschrijven. Het is ontwikkeld binnen de MMUSIC-werkgroep (Multiparty Multimedia Session Control) van de IETF en voor het eerst gestandaardiseerd in RFC 2327 in 1998. In 2021 werd de huidige specificatie RFC 8866 gepubliceerd, die de vorige versie RFC 4566 verving.

De belangrijkste taak van SDP is om sessiedeelnemers alle benodigde informatie te geven voor het tot stand brengen van een verbinding: welke mediastromen worden verzonden, welke codecs worden ondersteund, via welke netwerkadressen en poorten de verzending plaatsvindt. SDP verzendt geen mediagegevens zelf, maar beschrijft alleen hoe de verbinding moet worden georganiseerd.

Volgens IETF RFC 8866 bestaat het SDP-formaat uit een reeks regels, die elk beginnen met een type van één letter, gevolgd door een gelijkteken en een waarde. Bijvoorbeeld, de regel m=audio 5004 RTP/AVP 0 betekent dat de sessie een audiostream op poort 5004 omvat met het transportprotocol RTP/AVP en de codec PCMU (type 0).

Geschiedenis en standaardisatie van SDP

De eerste versie van SDP werd gepubliceerd in RFC 2327 in april 1998 als resultaat van het werk van de MMUSIC-groep. Het protocol werd oorspronkelijk gemaakt voor het aankondigen van multicast-sessies binnen Mbone (Multicast Backbone). Met de ontwikkeling van VoIP en videoconferenties breidde het toepassingsgebied van SDP zich uit en in 2006 werd de bijgewerkte specificatie RFC 4566 gepubliceerd.

De echte doorbraak in het gebruik van SDP vond plaats met de komst van WebRTC in 2011. Google integreerde SDP als het belangrijkste mechanisme voor het beschrijven van mediasessies in zijn framework voor real-time browsercommunicatie. Sindsdien is SDP een verplicht onderdeel geworden van elke WebRTC-implementatie — van browsers tot mobiele apps op iOS en Android.

In 2021 publiceerde de IETF-werkgroep RFC 8866 — de huidige SDP-specificatie die RFC 4566 verving. De bijgewerkte versie verduidelijkte de verwerking van ICE (Interactive Connectivity Establishment), ondersteuning voor DTLS (Datagram Transport Layer Security) en breidde de mogelijkheden voor het beschrijven van groepssessies uit.

Verschil tussen SDP en transportprotocollen

SDP verschilt fundamenteel van transportprotocollen omdat het niet deelneemt aan gegevensoverdracht. Het vervult uitsluitend een beschrijvende functie — vergelijkbaar met metadata van een multimedia-bestand. Terwijl RTP (Real-time Transport Protocol) audio- en videopakketten verzendt en RTCP de transmissiekwaliteit controleert, geeft SDP alleen aan welke codecs en poorten moeten worden gebruikt.

Een analogie uit webontwikkeling: SDP is de HTML-opmaak die de paginastructuur beschrijft, en RTP zijn de afbeeldingen en tekst zelf. Zonder SDP weten sessiedeelnemers niet hoe ze verbinding met elkaar moeten maken, zelfs als de netwerkverbinding al tot stand is gebracht. Het NAT-traversal-mechanisme (ICE) vertrouwt ook op SDP voor het verzenden van informatie over netwerkkandidaten.

Hoe is de SDP-structuur opgebouwd

De SDP-structuur is georganiseerd als een reeks tekstregels, die elk het formaat type=value volgen. Het type van één letter bepaalt het doel van de regel en de waarde bevat de bijbehorende waarde. Alle regels worden gescheiden door het CRLF-regelterugloopteken.

Standaard RFC 8866 definieert verschillende verplichte en optionele velden. Verplichte velden omvatten de protocolversie (v=), sessienaam (s=), start- en eindtijd van de sessie (t=). De overige velden zijn optioneel, maar voor WebRTC-sessies zijn ook media-beschrijvingen (m=), attributen (a=) en netwerkinformatie (c=) nodig.

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

In het bovenstaande voorbeeld wordt een typisch SDP-segment voor een WebRTC-sessie getoond. De regel v=0 geeft de protocolversie aan. Het veld o= bevat de identificatie van de sessie-eigenaar en de versie ervan. De regel s=- stelt de sessienaam in (een koppelteken betekent een lege naam). Het veld t=0 0 geeft aan dat de sessie niet in tijd is beperkt.

Het veld a=group:BUNDLE audio video is een attribuut dat meerdere mediastromen in één transportkanaal groepeert. Het BUNDLE-mechanisme bespaart netwerkbronnen door audio en video via één verbinding te verzenden. Dit is vooral belangrijk voor mobiele apparaten met beperkte bandbreedte.

Verplichte SDP-velden

Specificatie RFC 8866 definieert een reeks verplichte en optionele velden. Verplichte velden omvatten v= (versie), s= (sessienaam) en t= (tijd). Het veld o= (eigenaar), hoewel niet strikt verplicht volgens RFC, is in de praktijk bijna altijd aanwezig in echte implementaties.

Het veld m= (media) is een van de belangrijkste. Het beschrijft een specifieke mediastroom en bevat het mediatype (audio, video, text, application), poort, transportprotocol en een lijst met ondersteunde codecs. In WebRTC worden meestal de typen audio en video gebruikt met de transportprotocollen RTP/SAVPF (Secure Audio/Video Profile with Feedback) of UDP/TLS/RTP/SAVPF.

Het veld a= (attribute) is het meest flexibel en uitbreidbaar. Het kan rtpmap (toewijzing van codecnummer aan naam), fmtp (codecparameters), fingerprint (DTLS-sleutelvingerafdruk), ice-ufrag en ice-pwd (ICE-referenties) en vele andere attributen bevatten. Via attributen ondersteunt SDP moderne beveiligingsmechanismen en NAT-traversal.

Hoe werkt SDP in WebRTC

In de WebRTC-architectuur speelt SDP de rol van signaleringprotocol voor het beschrijven en afstemmen van parameters van een mediasessie tussen twee deelnemers. SDP zelf definieert geen mechanisme voor het verzenden van deze beschrijvingen — deze taak wordt opgelost door het signaleringskanaal dat de ontwikkelaar zelf implementeert via WebSocket, HTTP of een ander protocol.

Het proces begint met het maken van een SDP-aanbod — Offer door de initiator (beller). Hiervoor roept de browser de methode createOffer() aan op het RTCPeerConnection-object. De gegenereerde SDP-beschrijving bevat alle sessieparameters van de initiator: ondersteunde codecs, netwerkadressen, ICE-kandidaten en beveiligingseisen.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Maak SDP-aanbod op Android
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Verzend SDP-string naar externe deelnemer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Na het maken van Offer en het instellen van de lokale beschrijving via setLocalDescription(), stuurt de initiator de SDP-string naar de externe deelnemer via het signaleringskanaal. De externe deelnemer maakt na ontvangst van het SDP Offer een SDP-antwoord — Answer — en stuurt dit terug. Deze uitwisseling wordt signaleringsuitwisseling (signaling exchange) genoemd en is een verplichte stap voordat een peer-to-peer-verbinding tot stand wordt gebracht.

Volgens de W3C WebRTC-specificatie moet de SDP-uitwisseling plaatsvinden voordat ICE-kandidaten worden uitgewisseld. In de praktijk sturen veel implementaties ICE-kandidaten parallel met SDP, met behulp van het ICE trickle-mechanisme. Dit verkort de tijd om een verbinding tot stand te brengen, vooral voor mobiele netwerken met hoge latentie.

De rol van ICE in SDP

ICE (Interactive Connectivity Establishment) — is een mechanisme dat SDP-attributen gebruikt om informatie over netwerkkandidaten te verzenden. ICE-kandidaten beschrijven mogelijke verbindingspaden: host (lokaal adres), srflx (adres na NAT, verkregen via STUN) en relay (adres van de TURN-server).

In SDP worden ICE-kandidaten verzonden via de a=candidate:-attributen, evenals via de velden ice-ufrag en ice-pwd voor authenticatie van ICE-verkeer. Elke kandidaat omvat het transportprotocol (UDP, TCP), IP-adres, poort en prioriteit. Een succesvolle verbinding wordt tot stand gebracht via de eerste kandidaat die de connectiviteitstest doorstaat. Het ICE restart-mechanisme maakt het mogelijk de verbinding te vernieuwen bij netwerkwijziging.

Voor mobiele apps zijn ICE-kandidaten bijzonder belangrijk omdat apparaten zich vaak achter NAT of bedrijfsfirewalls bevinden. Het ICE-mechanisme maakt het mogelijk een werkend pad te vinden, zelfs in complexe netwerkomstandigheden, en SDP dient als transportcontainer voor deze informatie.

Beveiliging van SDP in WebRTC

SDP in WebRTC bevat verplicht beveiligingsattributen, met name de DTLS-vingerafdruk (fingerprint) en SRTP-parameters. Het veld a=fingerprint:sha-256 bevat de vingerafdruk van het DTLS-certificaat dat wordt gebruikt voor authenticatie en encryptie van de mediastroom. Zonder dit attribuut wordt geen WebRTC-verbinding tot stand gebracht.

Extra beveiligingsmechanismen omvatten het attribuut a=setup:, dat de rol van de DTLS-handshake bepaalt (active, passive, actpass), en a=ice-lite: voor een vereenvoudigde ICE-implementatie aan de serverzijde. Al deze parameters worden binnen SDP verzonden en door beide partijen gecontroleerd voordat de verzending van mediagegevens begint.

SDP-typen: Offer en Answer

In het WebRTC-model bestaan twee soorten SDP-berichten: Offer (aanbod) en Answer (antwoord). Offer wordt gemaakt door de initiator van de verbinding en bevat een volledige beschrijving van de gewenste mediasessie. Answer wordt gemaakt door de externe deelnemer als reactie op Offer en bevat zijn mogelijkheden, rekening houdend met de beperkingen die door het aanbod worden opgelegd.

Het belangrijkste verschil tussen Offer en Answer zit in de semantiek van de attributen. Offer somt alle ondersteunde codecs, transportprotocollen en netwerkadressen op die de initiator kan bieden. Answer selecteert een subset van deze mogelijkheden die door de externe partij worden ondersteund. Bijvoorbeeld, als Offer opus, ISAC en PCMU biedt, kan Answer alleen opus kiezen als de meest preferente codec.

Het uitwisselingsproces wordt geregeld door de W3C WebRTC-specificatie en omvat verschillende toestanden van RTCPeerConnection. Na het maken van Offer via createOffer() en het instellen ervan als lokale beschrijving, gaat de verbinding naar de toestand have-local-offer. Na ontvangst van Answer en het instellen ervan als externe beschrijving via setRemoteDescription(), gaat de verbinding naar stable — de uiteindelijke toestand, klaar voor media-overdracht.

Gebruik van SDP in mobiele SDK's

Mobiele SDK's voor WebRTC — Google WebRTC voor Android en WebRTC.framework voor iOS — ondersteunen volledig SDP-uitwisseling via Offer en Answer. Op Android wordt voor het maken van Offer de klasse PeerConnection gebruikt met de methode createOffer(), vergelijkbaar met de browser-API. De verkregen SDP-beschrijving wordt als string via het signaleringskanaal verzonden.

Op iOS werkt men met SDP via de klasse RTCSessionDescription uit het WebRTC-framework. Bij initialisatie worden het type (RTCSdpTypeOffer of RTCSdpTypeAnswer) en de SDP-string opgegeven. Het platform parseert automatisch de SDP en configureert de verbinding volgens de verzonden parameters.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

De mogelijkheid om direct met de SDP-string te werken geeft ontwikkelaars flexibiliteit: ze kunnen SDP voor verzending aanpassen door bepaalde codecs toe te voegen of te verwijderen, ICE-parameters te configureren of aangepaste attributen toe te voegen. Voor Android-apps is het vaak nodig om video in SDP uit te schakelen bij lage netwerkbandbreedte — dit gebeurt door de overeenkomstige m=-regels uit de SDP-beschrijving te verwijderen.

SDP in mobiele ontwikkeling

In mobiele ontwikkeling wordt SDP voornamelijk gebruikt in de context van WebRTC — voor het maken van apps met videogesprekken, spraakchat en streaming. Mobiele apps op Android en iOS kunnen zowel als initiator als ontvanger van SDP-berichten fungeren, wat de bouw van symmetrische peer-to-peer-verbindingen mogelijk maakt.

Het bijzondere aan mobiele apps is de noodzaak om met SDP te werken onder wisselende netwerkkwaliteit. Bij het schakelen tussen Wi-Fi en mobiel internet, en bij verandering van bandbreedte, kan het nodig zijn een nieuwe SDP-beschrijving te genereren. Hiervoor wordt het renegotiation-mechanisme gebruikt — herhaalde SDP-uitwisseling via createOffer() en setLocalDescription().

Volgens het Google WebRTC-team (2023) omvat optimalisatie van SDP-uitwisseling voor mobiele apparaten het gebruik van ICE restart bij netwerkwijziging, prioritering van codecs met lage bitsnelheid (opus voor audio, VP8 voor video) en minimale SDP-stringgrootte door het uitsluiten van onnodige mediastromen. Het belangrijkste voordeel is verminderde latentie bij het tot stand brengen van de verbinding in mobiele netwerken.

Optimalisatie van SDP voor mobiele netwerken

Een van de belangrijkste taken bij het werken met SDP op mobiele apparaten is het minimaliseren van de grootte van de SDP-beschrijving. Volledige SDP voor een typische WebRTC-sessie met audio en video kan 2–5 KB in beslag nemen, wat aanzienlijk is voor langzame netwerken. Optimalisatie omvat het gebruik van BUNDLE (samenvoegen van streams), verwijderen van niet-ondersteunde codecs en compressie van ICE-kandidaten.

Een extra probleem van mobiele apparaten is de beperkte levensduur van SDP. In omstandigheden met een onstabiele verbinding kan SDP verlopen voordat de externe deelnemer het heeft kunnen verwerken. De oplossing is het gebruik van korte time-outs voor het ontvangen van Answer en het opnieuw verzenden van SDP indien nodig. Het ICE restart-mechanisme maakt het mogelijk de verbinding te vernieuwen zonder volledige herbouw van RTCPeerConnection. Het attribuut a=ice-lite vereenvoudigt de ICE-implementatie aan de serverzijde.

Populaire bibliotheken voor werken met SDP

Ontwikkelaars van mobiele apps hebben kant-en-klare bibliotheken tot hun beschikking die het werken met SDP vereenvoudigen. libjingle_peerconnection (Google WebRTC) — de hoofd bibliotheek voor Android, die een volledige API biedt voor SDP-beheer. Voor iOS wordt WebRTC.framework met vergelijkbare functionaliteit gebruikt. Beide bibliotheken genereren en parsen automatisch SDP, maar geven indien nodig toegang tot de ruwe SDP-string.

Voor fijnere controle over SDP zijn er externe oplossingen: sdp-transform (JavaScript of Node.js) voor het parsen en wijzigen van SDP, NICENICE (Java) voor het werken met ICE-kandidaten en kant-en-klare SDK's van WebRTC-infrastructuur providers die de gehele signaleringsuitwisseling, inclusief SDP, voor hun rekening nemen.