SDP — mi ez, a munkamenet-leírás formátuma és szerepe a WebRTC-ben

Mi az SDP (Session Description Protocol)?

SDP — egy alkalmazásrétegbeli protokoll, amely multimédiás munkamenetek paramétereinek szöveges formátumban történő leírására szolgál. Az IETF MMUSIC (Multiparty Multimedia Session Control) munkacsoportjának keretében fejlesztették ki, és először az RFC 2327-ben szabványosították 1998-ban. 2021-ben megjelent a jelenlegi RFC 8866 specifikáció, amely felváltotta az előző RFC 4566 verziót.

Az SDP fő feladata, hogy a munkamenet résztvevőinek minden szükséges információt megadjon a kapcsolat létrehozásához: milyen médiafolyamok kerülnek továbbításra, milyen kodekek támogatottak, milyen hálózati címeken és portokon keresztül történik az adatátvitel. Az SDP nem továbbítja magát a médiaadatot, csak leírja, hogyan kell a kapcsolatot megszervezni.

Az IETF RFC 8866 szerint az SDP formátum sorok halmazából áll, amelyek mindegyike egybetűs típussal kezdődik, amelyet egyenlőségjel és érték követ. Például az m=audio 5004 RTP/AVP 0 sor azt jelenti, hogy a munkamenet egy audio folyamot tartalmaz az 5004-es porton RTP/AVP szállítási protokollal és PCMU kodekkel (0-as típus).

Az SDP története és szabványosítása

Az SDP első verzióját az RFC 2327-ben tették közzé 1998 áprilisában az MMUSIC csoport munkájának eredményeként. A protokollt eredetileg multicast munkamenetek bejelentésére hozták létre az Mbone (Multicast Backbone) keretében. A VoIP és videokonferenciák fejlődésével az SDP alkalmazási területe kibővült, és 2006-ban megjelent a frissített RFC 4566 specifikáció.

Az SDP használatában az igazi áttörés a WebRTC 2011-es megjelenésével következett be. A Google integrálta az SDP-t a böngésző valós idejű kommunikációs keretrendszerében a médiamunkamenetek leírásának fő mechanizmusaként. Ettől kezdve az SDP minden WebRTC-implementáció kötelező elemévé vált — a böngészőktől az iOS és Android mobilalkalmazásokig.

2021-ben az IETF munkacsoport kiadta az RFC 8866-ot — az RFC 4566-ot felváltó jelenlegi SDP specifikációt. A frissített verzió pontosította az ICE (Interactive Connectivity Establishment) kezelését, a DTLS (Datagram Transport Layer Security) támogatását, és kibővítette a csoportos munkamenetek leírásának lehetőségeit.

Az SDP különbsége a szállítási protokolloktól

SDP alapvetően különbözik a szállítási protokolloktól, mivel nem vesz részt az adatátvitelben. Kizárólag leíró funkciót tölt be — hasonlóan egy multimédiás fájl metaadataihoz. Míg az RTP (Real-time Transport Protocol) audio- és videocsomagokat továbbít, és az RTCP vezérli az átvitel minőségét, az SDP csak jelzi, hogy mely kodekeket és portokat kell használni.

Egy analógia a webfejlesztésből: az SDP az oldal szerkezetét leíró HTML jelölés, az RTP pedig maguk a képek és a szöveg. SDP nélkül a munkamenet résztvevői nem tudják, hogyan kapcsolódjanak egymáshoz, még akkor sem, ha a hálózati kapcsolat már létrejött. A NAT-traversal mechanizmus (ICE) szintén az SDP-re támaszkodik a hálózati jelöltekről szóló információk továbbításában.

Hogyan épül fel az SDP szerkezete

Az SDP szerkezete szövegsorok sorozataként van megszervezve, amelyek mindegyike a type=value formátumot követi. Az egybetűs típus meghatározza a sor célját, az érték pedig a megfelelő értéket tartalmazza. Az összes sort a CRLF újsor karakter választja el.

Az RFC 8866 szabvány több kötelező és opcionális mezőt határoz meg. A kötelező mezők közé tartozik a protokoll verziója (v=), a munkamenet neve (s=), a munkamenet kezdési és befejezési ideje (t=). A többi mező opcionális, de a WebRTC-munkamenetekhez a média leírások (m=), attribútumok (a=) és hálózati információk (c=) is szükségesek.

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

A fenti példa egy tipikus SDP szegmenst mutat be egy WebRTC-munkamenethez. A v=0 sor a protokoll verzióját jelzi. Az o= mező tartalmazza a munkamenet tulajdonosának azonosítóját és annak verzióját. Az s=- sor beállítja a munkamenet nevét (a kötőjel üres nevet jelent). A t=0 0 mező azt jelzi, hogy a munkamenet nincs időben korlátozva.

Az a=group:BUNDLE audio video mező egy attribútum, amely több médiafolyamot egyetlen szállítási csatornába csoportosít. A BUNDLE mechanizmus lehetővé teszi a hálózati erőforrások megtakarítását azáltal, hogy az audiót és videót egyetlen kapcsolaton keresztül továbbítja. Ez különösen fontos a korlátozott sávszélességű mobil eszközök esetében.

Az SDP kötelező mezői

Az RFC 8866 specifikáció egy sor kötelező és opcionális mezőt határoz meg. A kötelező mezők közé tartozik a v= (verzió), s= (munkamenet neve) és t= (idő). Az o= (tulajdonos) mező, bár az RFC szerint nem szigorúan kötelező, a gyakorlatban szinte mindig jelen van a valós implementációkban.

Az m= (media) mező az egyik legfontosabb. Leír egy adott médiafolyamot, és tartalmazza a médiatípust (audio, video, text, application), portot, szállítási protokollt és a támogatott kodekek listáját. A WebRTC-ben leggyakrabban az audio és video típusokat használják RTP/SAVPF (Secure Audio/Video Profile with Feedback) vagy UDP/TLS/RTP/SAVPF szállítási protokollokkal.

Az a= (attribute) mező a legrugalmasabb és legbővíthetőbb. Tartalmazhat rtpmap-ot (kodekszám hozzárendelése névhez), fmtp-t (kodek paraméterei), fingerprint-et (DTLS-kulcs ujjlenyomata), ice-ufrag-ot és ice-pwd-t (ICE hitelesítő adatok) és számos egyéb attribútumot. Az attribútumokon keresztül az SDP támogatja a modern biztonsági mechanizmusokat és a NAT-traversal-t.

Hogyan működik az SDP a WebRTC-ben

A WebRTC architektúrában az SDP jelzőprotokollként működik a médiamunkamenet paramétereinek leírására és egyeztetésére két résztvevő között. Maga az SDP nem határozza meg ezen leírások továbbításának mechanizmusát — ezt a feladatot a jelzőcsatorna oldja meg, amelyet a fejlesztő önállóan implementál WebSocket, HTTP vagy más protokoll segítségével.

A folyamat az SDP ajánlat — Offer — létrehozásával kezdődik a kezdeményező (hívó) által. Ehhez a böngésző meghívja a createOffer() metódust az RTCPeerConnection objektumon. A generált SDP leírás tartalmazza a munkamenet összes paraméterét a kezdeményező oldaláról: a támogatott kodekeket, hálózati címeket, ICE-jelölteket és biztonsági követelményeket.

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

// SDP ajánlat létrehozása Androidon
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP karakterlánc küldése a távoli félnek
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Az Offer létrehozása és a helyi leírás setLocalDescription() segítségével történő beállítása után a kezdeményező elküldi az SDP karakterláncot a távoli résztvevőnek a jelzőcsatornán keresztül. A távoli résztvevő az SDP Offer kézhezvétele után létrehoz egy SDP választ — Answer —, és visszaküldi azt. Ezt a cserét jelzőcserének (signaling exchange) nevezik, és kötelező lépés a peer-to-peer kapcsolat létrehozása előtt.

A W3C WebRTC specifikáció szerint az SDP cserének az ICE-jelöltek cseréje előtt kell megtörténnie. A gyakorlatban sok implementáció párhuzamosan küldi az ICE-jelölteket az SDP-vel, az ICE trickle mechanizmust használva. Ez lerövidíti a kapcsolat létrehozásának idejét, különösen a nagy késleltetésű mobil hálózatok esetében.

Az ICE szerepe az SDP-ben

ICE (Interactive Connectivity Establishment) — egy olyan mechanizmus, amely az SDP attribútumokat használja a hálózati jelöltekről szóló információk továbbítására. Az ICE-jelöltek leírják a lehetséges kapcsolódási útvonalakat: host (helyi cím), srflx (NAT utáni cím, STUN segítségével megszerezve) és relay (TURN-szerver címe).

Az SDP-ben az ICE-jelöltek az a=candidate: attribútumokon, valamint az ice-ufrag és ice-pwd mezőkön keresztül kerülnek továbbításra az ICE-forgalom hitelesítéséhez. Minden jelölt tartalmazza a szállítási protokollt (UDP, TCP), IP-címet, portot és prioritást. A sikeres kapcsolat az első olyan jelölten keresztül jön létre, amely átmegy a kapcsolódási teszten. Az ICE restart mechanizmus lehetővé teszi a kapcsolat frissítését hálózatváltáskor.

A mobilalkalmazások számára az ICE-jelöltek különösen fontosak, mivel az eszközök gyakran NAT vagy vállalati tűzfalak mögött találhatók. Az ICE mechanizmus lehetővé teszi a működő útvonal megtalálását még bonyolult hálózati körülmények között is, az SDP pedig szállítási konténerként szolgál ezen információk számára.

Az SDP biztonsága a WebRTC-ben

SDP a WebRTC-ben kötelezően tartalmaz biztonsági attribútumokat, különösen a DTLS ujjlenyomatot (fingerprint) és az SRTP paramétereket. Az a=fingerprint:sha-256 mező tartalmazza a médiafolyam hitelesítésére és titkosítására használt DTLS-tanúsítvány ujjlenyomatát. Ezen attribútum nélkül a WebRTC-kapcsolat nem jön létre.

További biztonsági mechanizmusok közé tartozik az a=setup: attribútum, amely meghatározza a DTLS-kézfogás szerepét (active, passive, actpass), és az a=ice-lite: az egyszerűsített ICE-implementációhoz a szerver oldalon. Mindezek a paraméterek az SDP-n belül kerülnek továbbításra, és mindkét fél ellenőrzi őket a médiaadatok továbbításának megkezdése előtt.

SDP-típusok: Offer és Answer

A WebRTC modellben kétféle SDP üzenet létezik: Offer (ajánlat) és Answer (válasz). Az Offer-t a kapcsolat kezdeményezője hozza létre, és tartalmazza a kívánt médiamunkamenet teljes leírását. Az Answer-t a távoli résztvevő hozza létre az Offer-re válaszul, és tartalmazza az ő képességeit, figyelembe véve az ajánlat által támasztott korlátozásokat.

A fő különbség az Offer és Answer között az attribútumok szemantikájában van. Az Offer felsorolja az összes támogatott kodeket, szállítási protokollt és hálózati címet, amelyet a kezdeményező kínálhat. Az Answer kiválasztja ezen képességek egy olyan részhalmazát, amelyet a távoli fél támogat. Például, ha az Offer opus-t, ISAC-ot és PCMU-t kínál, az Answer csak az opus-t választhatja a legpreferáltabb kodekként.

A csere folyamatát a W3C WebRTC specifikáció szabályozza, és az RTCPeerConnection több állapotát foglalja magában. Az Offer createOffer() segítségével történő létrehozása és helyi leírásként való beállítása után a kapcsolat a have-local-offer állapotba kerül. Az Answer kézhezvétele és setRemoteDescription() segítségével távoli leírásként való beállítása után a kapcsolat a stable állapotba kerül — a média továbbítására kész végleges állapotba.

Az SDP használata mobil SDK-kban

A WebRTC-hez készült mobil SDK-k — Google WebRTC Androidhoz és WebRTC.framework iOS-hez — teljes mértékben támogatják az SDP-cserét az Offer és Answer segítségével. Android rendszeren az Offer létrehozásához a PeerConnection osztályt használják a createOffer() metódussal, hasonlóan a böngésző API-hoz. A kapott SDP leírást karaktersorként továbbítják a jelzőcsatornán keresztül.

iOS rendszeren az SDP-vel való munka a WebRTC keretrendszer RTCSessionDescription osztályán keresztül történik. Az inicializálás során megadják a típust (RTCSdpTypeOffer vagy RTCSdpTypeAnswer) és az SDP karakterláncot. A platform automatikusan elemzi az SDP-t, és a továbbított paramétereknek megfelelően konfigurálja a kapcsolatot.

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

Az SDP karakterlánccal való közvetlen munka lehetősége rugalmasságot biztosít a fejlesztőknek: módosíthatják az SDP-t a küldés előtt, bizonyos kodekek hozzáadásával vagy eltávolításával, ICE-paraméterek konfigurálásával vagy egyéni attribútumok hozzáadásával. Android alkalmazások esetében gyakran szükséges a videó letiltása az SDP-ben alacsony hálózati sávszélesség esetén — ez a megfelelő m= sorok eltávolításával történik az SDP leírásból.

SDP a mobilfejlesztésben

A mobilfejlesztésben az SDP-t elsősorban a WebRTC kontextusában használják — videohívásokat, hangchatet és streaminget tartalmazó alkalmazások létrehozására. Az Android és iOS mobilalkalmazások mind a kezdeményező, mind az SDP-üzenetek fogadójának szerepében felléphetnek, lehetővé téve szimmetrikus peer-to-peer kapcsolatok kiépítését.

A mobilalkalmazások sajátossága, hogy az SDP-vel változó hálózati minőség körülményei között kell dolgozniuk. A Wi-Fi és mobil internet közötti váltáskor, valamint a sávszélesség változásakor szükség lehet új SDP leírás generálására. Erre szolgál a renegotiation mechanizmus — az SDP ismételt cseréje a createOffer() és setLocalDescription() segítségével.

A Google WebRTC csapat (2023) szerint az SDP-csere optimalizálása mobil eszközökhöz magában foglalja az ICE restart használatát hálózatváltáskor, az alacsony bitsebességű kodekek előnyben részesítését (opus audiohoz, VP8 videóhoz) és az SDP karaktersor minimális méretét a szükségtelen médiafolyamok kizárásával. A fő előny a késleltetés csökkentése a kapcsolat létrehozásakor mobil hálózatokban.

Az SDP optimalizálása mobil hálózatokhoz

Az egyik kulcsfeladat az SDP-vel való munka során mobil eszközökön az SDP leírás méretének minimalizálása. A teljes SDP egy tipikus WebRTC-munkamenethez audióval és videóval 2–5 KB-ot foglalhat el, ami jelentős a lassú hálózatok számára. Az optimalizálás magában foglalja a BUNDLE használatát (folyamok összevonása), a nem támogatott kodekek eltávolítását és az ICE-jelöltek tömörítését.

A mobil eszközök további problémája az SDP korlátozott élettartama. Instabil kapcsolat körülményei között az SDP lejárhat, mielőtt a távoli résztvevő feldolgozhatná. A megoldás rövid időtúllépések használata az Answer fogadására és az SDP szükség szerinti újraküldése. Az ICE restart mechanizmus lehetővé teszi a kapcsolat frissítését az RTCPeerConnection teljes újralétrehozása nélkül. Az a=ice-lite attribútum egyszerűsíti az ICE-implementációt a szerver oldalon.

Népszerű könyvtárak az SDP-vel való munkához

A mobilalkalmazás-fejlesztők kész könyvtárakhoz férhetnek hozzá, amelyek megkönnyítik az SDP-vel való munkát. A libjingle_peerconnection (Google WebRTC) — a fő könyvtár Androidhoz, amely teljes API-t biztosít az SDP kezeléséhez. iOS rendszeren a WebRTC.framework-ot használják hasonló funkcionalitással. Mindkét könyvtár automatikusan generálja és elemzi az SDP-t, de szükség esetén hozzáférést biztosít a nyers SDP karaktersorhoz.

Az SDP finomabb vezérléséhez harmadik féltől származó megoldások állnak rendelkezésre: sdp-transform (JavaScript vagy Node.js) az SDP elemzéséhez és módosításához, NICENICE (Java) az ICE-jelöltekkel való munkához, és kész SDK-k a WebRTC-infrastruktúra-szolgáltatóktól, amelyek a teljes jelzőcserét, beleértve az SDP-t is, kezelik.