SDP — vad det är, format för sessionsbeskrivning och roll i WebRTC

Vad är SDP (Session Description Protocol)?

SDP — är ett applikationslagerprotokoll avsett att beskriva parametrar för multimediesessioner i textformat. Det utvecklades inom ramen för IETF:s MMUSIC-arbetsgrupp (Multiparty Multimedia Session Control) och standardiserades första gången i RFC 2327 1998. År 2021 publicerades den aktuella specifikationen RFC 8866, som ersatte den tidigare versionen RFC 4566.

SDP:s huvuduppgift är att ge sessionsdeltagare all nödvändig information för att upprätta en anslutning: vilka mediaströmmar som ska överföras, vilka codecs som stöds, via vilka nätverksadresser och portar överföringen ska ske. SDP överför inte själva mediadata, utan beskriver bara hur anslutningen ska organiseras.

Enligt IETF RFC 8866 består SDP-formatet av en uppsättning rader, var och en som börjar med en bokstavstyp, följt av ett likhetstecken och ett värde. Till exempel betyder raden m=audio 5004 RTP/AVP 0 att sessionen inkluderar en ljudström på port 5004 med transportprotokollet RTP/AVP och codec PCMU (typ 0).

SDP:s historia och standardisering

Den första versionen av SDP publicerades i RFC 2327 i april 1998 som ett resultat av MMUSIC-gruppens arbete. Protokollet skapades ursprungligen för att annonsera multicast-sessioner inom Mbone (Multicast Backbone). Med utvecklingen av VoIP och videokonferenser utökades SDP:s tillämpningsområde och 2006 publicerades den uppdaterade specifikationen RFC 4566.

Det verkliga genombrottet i användningen av SDP kom med WebRTC 2011. Google integrerade SDP som den huvudsakliga mekanismen för att beskriva mediesessioner i sitt ramverk för realtidskommunikation i webbläsaren. Sedan dess har SDP blivit en obligatorisk komponent i varje WebRTC-implementering — från webbläsare till mobila applikationer på iOS och Android.

2021 publicerade IETF:s arbetsgrupp RFC 8866 — den aktuella SDP-specifikationen som ersatte RFC 4566. Den uppdaterade versionen förtydligade hanteringen av ICE (Interactive Connectivity Establishment), stöd för DTLS (Datagram Transport Layer Security) och utökade möjligheterna att beskriva gruppsessioner.

Skillnad mellan SDP och transportprotokoll

SDP skiljer sig fundamentalt från transportprotokoll eftersom det inte deltar i dataöverföring. Det fyller enbart en beskrivande funktion — liknande metadata för en multimediafil. Medan RTP (Real-time Transport Protocol) överför ljud- och videopaket och RTCP kontrollerar överföringskvaliteten, anger SDP bara vilka codecs och portar som ska användas.

En analogi från webbutveckling: SDP är HTML-koden som beskriver sidstrukturen, och RTP är själva bilderna och texten. Utan SDP vet sessionsdeltagarna inte hur de ska ansluta till varandra, även om nätverksanslutningen redan är upprättad. NAT-traversal-mekanismen (ICE) förlitar sig också på SDP för att överföra information om nätverkskandidater.

Hur SDP-strukturen är uppbyggd

SDP-strukturen är organiserad som en sekvens av textrader, var och en som följer formatet type=value. Typen med en bokstav bestämmer radens syfte och värdet innehåller motsvarande värde. Alla rader separeras av CRLF-radbrytningstecknet.

Standarden RFC 8866 definierar flera obligatoriska och valfria fält. Obligatoriska fält inkluderar protokollversion (v=), sessionsnamn (s=), start- och sluttid för sessionen (t=). Övriga fält är valfria, men för WebRTC-sessioner behövs även mediabeskrivningar (m=), attribut (a=) och nätverksinformation (c=).

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

I exemplet ovan visas ett typiskt SDP-segment för en WebRTC-session. Raden v=0 anger protokollversionen. Fältet o= innehåller identifieraren för sessionsägaren och dess version. Raden s=- anger sessionsnamnet (bindestrecket betyder tomt namn). Fältet t=0 0 indikerar att sessionen inte är tidsbegränsad.

Fältet a=group:BUNDLE audio video är ett attribut som grupperar flera mediaströmmar i en transportkanal. BUNDLE-mekanismen gör det möjligt att spara nätverksresurser genom att överföra ljud och video via en enda anslutning. Detta är särskilt viktigt för mobila enheter med begränsad bandbredd.

Obligatoriska SDP-fält

Specifikationen RFC 8866 definierar en uppsättning obligatoriska och valfria fält. Obligatoriska fält inkluderar v= (version), s= (sessionsnamn) och t= (tid). Fältet o= (ägare), även om det inte är strikt obligatoriskt enligt RFC, är praktiskt taget alltid närvarande i verkliga implementeringar.

Fältet m= (media) är ett av de viktigaste. Det beskriver en specifik mediaström och innehåller mediatyp (audio, video, text, application), port, transportprotokoll och en lista över codecs som stöds. I WebRTC används oftast typerna audio och video med transportprotokollen RTP/SAVPF (Secure Audio/Video Profile with Feedback) eller UDP/TLS/RTP/SAVPF.

Fältet a= (attribute) är det mest flexibla och utbyggbara. Det kan innehålla rtpmap (mappning av codec-nummer till namn), fmtp (codec-parametrar), fingerprint (DTLS-nyckelavtryck), ice-ufrag och ice-pwd (ICE-referenser) och många andra attribut. Genom attribut stöder SDP moderna säkerhetsmekanismer och NAT-traversal.

Hur SDP fungerar i WebRTC

I WebRTC-arkitekturen spelar SDP rollen som signaleringsprotokoll för att beskriva och förhandla om parametrar för en mediesession mellan två deltagare. SDP själv definierar inte någon mekanism för att överföra dessa beskrivningar — denna uppgift löses av signaleringskanalen som utvecklaren själv implementerar via WebSocket, HTTP eller ett annat protokoll.

Processen börjar med att initiativtagaren (den som ringer) skapar ett SDP-erbjudande — Offer. För detta anropar webbläsaren metoden createOffer() på RTCPeerConnection-objektet. Den genererade SDP-beskrivningen innehåller alla sessionsparametrar från initiativtagarens sida: codecs som stöds, nätverksadresser, ICE-kandidater och säkerhetskrav.

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

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

// Skicka SDP-sträng till fjärranvändare
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Efter att ha skapat Offer och ställt in den lokala beskrivningen via setLocalDescription(), skickar initiativtagaren SDP-strängen till den fjärrbaserade deltagaren via signaleringskanalen. Den fjärrbaserade deltagaren skapar efter att ha tagit emot SDP Offer ett SDP-svar — Answer — och skickar tillbaka det. Detta utbyte kallas signaleringsutbyte (signaling exchange) och är ett obligatoriskt steg innan en peer-to-peer-anslutning upprättas.

Enligt W3C WebRTC-specifikationen bör SDP-utbytet ske innan utbytet av ICE-kandidater påbörjas. I praktiken skickar många implementeringar ICE-kandidater parallellt med SDP med hjälp av ICE trickle-mekanismen. Detta förkortar tiden för att upprätta en anslutning, särskilt för mobila nätverk med hög latens.

ICE:s roll i SDP

ICE (Interactive Connectivity Establishment) — är en mekanism som använder SDP-attribut för att överföra information om nätverkskandidater. ICE-kandidater beskriver möjliga anslutningsvägar: host (lokal adress), srflx (adress efter NAT, erhållen via STUN) och relay (adress till TURN-server).

I SDP överförs ICE-kandidater via attributen a=candidate:, samt via fälten ice-ufrag och ice-pwd för autentisering av ICE-trafik. Varje kandidat inkluderar transportprotokoll (UDP, TCP), IP-adress, port och prioritet. En lyckad anslutning upprättas via den första kandidaten som klarar anslutningstestet. ICE restart-mekanismen gör det möjligt att uppdatera anslutningen vid nätverksändring.

För mobila applikationer är ICE-kandidater särskilt viktiga eftersom enheter ofta befinner sig bakom NAT eller företagsbrandväggar. ICE-mekanismen gör det möjligt att hitta en fungerande väg även under komplexa nätverksförhållanden, och SDP fungerar som en transportcontainer för denna information.

Säkerhet för SDP i WebRTC

SDP i WebRTC innehåller obligatoriskt säkerhetsattribut, särskilt DTLS-avtryck (fingerprint) och SRTP-parametrar. Fältet a=fingerprint:sha-256 innehåller avtrycket från DTLS-certifikatet som används för autentisering och kryptering av mediaströmmen. Utan detta attribut kommer ingen WebRTC-anslutning att upprättas.

Ytterligare säkerhetsmekanismer inkluderar attributet a=setup:, som bestämmer rollen för DTLS-handskakningen (active, passive, actpass), och a=ice-lite: för en förenklad ICE-implementering på serversidan. Alla dessa parametrar överförs inom SDP och kontrolleras av båda parter innan överföringen av mediadata påbörjas.

SDP-typer: Offer och Answer

I WebRTC-modellen finns det två typer av SDP-meddelanden: Offer (erbjudande) och Answer (svar). Offer skapas av initiativtagaren till anslutningen och innehåller en fullständig beskrivning av den önskade mediesessionen. Answer skapas av den fjärrbaserade deltagaren som svar på Offer och innehåller dess kapacitet med hänsyn till de begränsningar som erbjudandet ålägger.

Den huvudsakliga skillnaden mellan Offer och Answer ligger i attributens semantik. Offer listar alla codecs, transportprotokoll och nätverksadresser som initiativtagaren kan erbjuda. Answer väljer en delmängd av dessa kapaciteter som stöds av den fjärrbaserade parten. Till exempel, om Offer erbjuder opus, ISAC och PCMU, kan Answer välja endast opus som den mest föredragna codec.

Utbytesprocessen regleras av W3C WebRTC-specifikationen och omfattar flera tillstånd för RTCPeerConnection. Efter att ha skapat Offer via createOffer() och ställt in den som lokal beskrivning, går anslutningen till tillståndet have-local-offer. Efter att ha tagit emot Answer och ställt in den som fjärrbaserad beskrivning via setRemoteDescription(), går anslutningen till stable — det slutliga tillståndet redo för mediaöverföring.

Användning av SDP i mobila SDK:er

Mobila SDK:er för WebRTC — Google WebRTC för Android och WebRTC.framework för iOS — stöder fullt SDP-utbyte via Offer och Answer. På Android används klassen PeerConnection med metoden createOffer() för att skapa Offer, liknande webbläsarens API. Den erhållna SDP-beskrivningen överförs som en sträng via signaleringskanalen.

På iOS sker arbete med SDP via klassen RTCSessionDescription från WebRTC-ramverket. Vid initiering anges typen (RTCSdpTypeOffer eller RTCSdpTypeAnswer) och SDP-strängen. Plattformen tolkar automatiskt SDP och konfigurerar anslutningen enligt de överförda parametrarna.

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())

Möjligheten att arbeta direkt med SDP-strängen ger utvecklare flexibilitet: de kan modifiera SDP före sändning, lägga till eller ta bort specifika codecs, konfigurera ICE-parametrar eller lägga till anpassade attribut. För Android-applikationer krävs det ofta att video inaktiveras i SDP vid låg nätverksbandbredd — detta görs genom att ta bort motsvarande m=-rader från SDP-beskrivningen.

SDP inom mobil utveckling

Inom mobil utveckling används SDP främst inom WebRTC — för att skapa applikationer med videosamtal, röstchatt och streaming. Mobila applikationer på Android och iOS kan agera både som initiativtagare och mottagare av SDP-meddelanden, vilket möjliggör byggandet av symmetriska peer-to-peer-anslutningar.

Det särskilda med mobila applikationer är behovet av att arbeta med SDP under varierande nätverkskvalitet. Vid växling mellan Wi-Fi och mobilt internet, samt vid förändring av bandbredd, kan det vara nödvändigt att generera en ny SDP-beskrivning. För detta används renegotiation-mekanismen — upprepat SDP-utbyte via createOffer() och setLocalDescription().

Enligt Google WebRTC-teamet (2023) omfattar optimering av SDP-utbyte för mobila enheter användning av ICE restart vid nätverksändring, prioritering av codecs med låg bithastighet (opus för ljud, VP8 för video) och minimal SDP-strängstorlek genom att utesluta onödiga mediaströmmar. Den främsta fördelen är minskad latens vid upprättande av anslutning i mobila nätverk.

Optimering av SDP för mobila nätverk

En av nyckeluppgifterna vid arbete med SDP på mobila enheter är att minimera storleken på SDP-beskrivningen. Full SDP för en typisk WebRTC-session med ljud och video kan ta 2–5 KB, vilket är betydande för långsamma nätverk. Optimering inkluderar användning av BUNDLE (sammanfogning av strömmar), borttagning av codecs som inte stöds och komprimering av ICE-kandidater.

Ett ytterligare problem med mobila enheter är SDP:s begränsade livslängd. Under instabila anslutningsförhållanden kan SDP förfalla innan den fjärrbaserade deltagaren hinner behandla det. Lösningen är att använda korta timeouter för att ta emot Answer och återsända SDP vid behov. ICE restart-mekanismen gör det möjligt att uppdatera anslutningen utan att helt återskapa RTCPeerConnection. Attributet a=ice-lite förenklar ICE-implementeringen på serversidan.

Populära bibliotek för arbete med SDP

Utvecklare av mobila applikationer har tillgång till färdiga bibliotek som förenklar arbetet med SDP. libjingle_peerconnection (Google WebRTC) — huvudbiblioteket för Android, som tillhandahåller ett fullt API för SDP-hantering. För iOS används WebRTC.framework med liknande funktionalitet. Båda biblioteken genererar och tolkar automatiskt SDP, men ger tillgång till rå SDP-sträng vid behov.

För finare kontroll över SDP finns tredjepartslösningar: sdp-transform (JavaScript eller Node.js) för att tolka och modifiera SDP, NICENICE (Java) för att arbeta med ICE-kandidater och färdiga SDK:er från leverantörer av WebRTC-infrastruktur som hanterar hela signaleringsutbytet, inklusive SDP.