SDP — co to je, formát popisu relací a role ve WebRTC

Co je SDP (Session Description Protocol)?

SDP — je protokol aplikační vrstvy určený k popisu parametrů multimediálních relací v textovém formátu. Byl vyvinut v rámci pracovní skupiny MMUSIC (Multiparty Multimedia Session Control) IETF a poprvé standardizován v RFC 2327 v roce 1998. V roce 2021 byla zveřejněna aktuální specifikace RFC 8866, která nahradila předchozí verzi RFC 4566.

Hlavním úkolem SDP je poskytnout účastníkům relace všechny potřebné informace pro navázání spojení: jaké mediální toky budou přenášeny, jaké kodeky jsou podporovány, na jakých síťových adresách a portech bude probíhat přenos. SDP nepřenáší samotná mediální data, pouze popisuje, jak má být spojení organizováno.

Podle IETF RFC 8866 se formát SDP skládá z množiny řádků, z nichž každý začíná jednopísmenným typem, za nímž následuje znak rovná se a hodnota. Například řádek m=audio 5004 RTP/AVP 0 znamená, že relace zahrnuje audio tok na portu 5004 s transportním protokolem RTP/AVP a kodekem PCMU (typ 0).

Historie a standardizace SDP

První verze SDP byla zveřejněna v RFC 2327 v dubnu 1998 jako výsledek práce skupiny MMUSIC. Protokol byl původně vytvořen pro oznamování multicastových relací v rámci Mbone (Multicast Backbone). S rozvojem VoIP a videokonferencí se oblast použití SDP rozšířila a v roce 2006 byla zveřejněna aktualizovaná specifikace RFC 4566.

Skutečný průlom v používání SDP nastal s příchodem WebRTC v roce 2011. Google integroval SDP jako hlavní mechanismus popisu mediálních relací ve svém frameworku pro komunikaci v reálném čase v prohlížeči. Od té doby se SDP stalo povinnou součástí každé implementace WebRTC — od prohlížečů po mobilní aplikace na iOS a Androidu.

V roce 2021 pracovní skupina IETF zveřejnila RFC 8866 — aktuální specifikaci SDP, která nahradila RFC 4566. Aktualizovaná verze upřesnila zpracování ICE (Interactive Connectivity Establishment), podporu pro DTLS (Datagram Transport Layer Security) a rozšířila možnosti popisu skupinových relací.

Rozdíl mezi SDP a transportními protokoly

SDP se zásadně liší od transportních protokolů tím, že se neúčastní přenosu dat. Plní výhradně popisnou funkci — podobně jako metadata multimediálního souboru. Zatímco RTP (Real-time Transport Protocol) přenáší audio a video pakety a RTCP řídí kvalitu přenosu, SDP pouze určuje, které kodeky a porty použít.

Analogie z webového vývoje: SDP je HTML značení popisující strukturu stránky a RTP jsou samotné obrázky a text. Bez SDP účastníci relace nevědí, jak se navzájem propojit, i když je síťové spojení již navázáno. Mechanismus NAT-traversal (ICE) se rovněž spoléhá na SDP pro přenos informací o síťových kandidátech.

Jak je struktura SDP uspořádána

Struktura SDP je organizována jako sekvence textových řádků, z nichž každý následuje formát type=value. Jednopísmenný typ určuje účel řádku a hodnota obsahuje odpovídající hodnotu. Všechny řádky jsou odděleny znakem nového řádku CRLF.

Standard RFC 8866 definuje několik povinných a volitelných polí. Povinná pole zahrnují verzi protokolu (v=), název relace (s=), čas zahájení a ukončení relace (t=). Ostatní pole jsou volitelná, ale pro relace WebRTC jsou potřebné také popisy médií (m=), atributy (a=) a síťové informace (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

Ve výše uvedeném příkladu je zobrazen typický segment SDP pro relaci WebRTC. Řádek v=0 označuje verzi protokolu. Pole o= obsahuje identifikátor vlastníka relace a její verzi. Řádek s=- nastavuje název relace (pomlčka znamená prázdný název). Pole t=0 0 označuje, že relace není časově omezena.

Pole a=group:BUNDLE audio video je atribut, který seskupuje několik mediálních toků do jednoho transportního kanálu. Mechanismus BUNDLE umožňuje šetřit síťové zdroje přenosem audia a videa přes jedno spojení. To je zvláště důležité pro mobilní zařízení s omezenou šířkou pásma.

Povinná pole SDP

Specifikace RFC 8866 definuje sadu povinných a volitelných polí. Povinná pole zahrnují v= (verze), s= (název relace) a t= (čas). Pole o= (vlastník), i když podle RFC není striktně povinné, je v praxi téměř vždy přítomno v reálných implementacích.

Pole m= (media) je jedním z nejdůležitějších. Popisuje konkrétní mediální tok a obsahuje typ média (audio, video, text, application), port, transportní protokol a seznam podporovaných kodeků. Ve WebRTC se nejčastěji používají typy audio a video s transportními protokoly RTP/SAVPF (Secure Audio/Video Profile with Feedback) nebo UDP/TLS/RTP/SAVPF.

Pole a= (attribute) je nejflexibilnější a nejrozšiřitelnější. Může obsahovat rtpmap (mapování čísla kodeku na název), fmtp (parametry kodeku), fingerprint (otisk klíče DTLS), ice-ufrag a ice-pwd (přihlašovací údaje ICE) a mnoho dalších atributů. Právě prostřednictvím atributů SDP podporuje moderní bezpečnostní mechanismy a NAT-traversal.

Jak SDP funguje ve WebRTC

V architektuře WebRTC hraje SDP roli signalizačního protokolu pro popis a sjednávání parametrů mediální relace mezi dvěma účastníky. Samotné SPP nedefinuje mechanismus přenosu těchto popisů — tento úkol řeší signalizační kanál, který vývojář implementuje samostatně prostřednictvím WebSocketu, HTTP nebo jiného protokolu.

Proces začíná vytvořením SDP nabídky — Offer iniciátorem (volajícím). K tomu prohlížeč zavolá metodu createOffer() na objektu RTCPeerConnection. Vygenerovaný popis SDP obsahuje všechny parametry relace ze strany iniciátora: podporované kodeky, síťové adresy, ICE kandidáty a bezpečnostní požadavky.

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

// Vytvořit SDP nabídku na Androidu
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Odeslat řetězec SDP vzdálenému peerovi
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Po vytvoření Offer a nastavení lokálního popisu prostřednictvím setLocalDescription() odešle iniciátor řetězec SDP vzdálenému účastníkovi přes signalizační kanál. Vzdálený účastník po obdržení SDP Offer vytvoří SDP odpověď — Answer — a odešle ji zpět. Tato výměna se nazývá signalizační výměna (signaling exchange) a je povinným krokem před navázáním peer-to-peer spojení.

Podle specifikace W3C WebRTC by k výměně SDP mělo dojít před zahájením výměny ICE kandidátů. V praxi mnoho implementací odesílá ICE kandidáty paralelně s SDP pomocí mechanismu ICE trickle. To zkracuje dobu navázání spojení, zejména u mobilních sítí s vysokou latencí.

Role ICE v SDP

ICE (Interactive Connectivity Establishment) — je mechanismus, který používá atributy SDP k přenosu informací o síťových kandidátech. ICE kandidáti popisují možné cesty spojení: host (lokální adresa), srflx (adresa po NAT, získaná prostřednictvím STUN) a relay (adresa TURN serveru).

V SDP jsou ICE kandidáti přenášeni prostřednictvím atributů a=candidate:, stejně jako prostřednictvím polí ice-ufrag a ice-pwd pro autentizaci ICE provozu. Každý kandidát zahrnuje transportní protokol (UDP, TCP), IP adresu, port a prioritu. Úspěšné spojení je navázáno prostřednictvím prvního kandidáta, který projde testem konektivity. Mechanismus ICE restart umožňuje obnovení spojení při změně sítě.

Pro mobilní aplikace jsou ICE kandidáti obzvláště důležití, protože zařízení jsou často za NAT nebo firewally společností. Mechanismus ICE umožňuje najít funkční cestu i ve složitých síťových podmínkách a SDP slouží jako transportní kontejner pro tyto informace.

Bezpečnost SDP ve WebRTC

SDP ve WebRTC povinně zahrnuje bezpečnostní atributy, zejména otisk DTLS (fingerprint) a parametry SRTP. Pole a=fingerprint:sha-256 obsahuje otisk certifikátu DTLS používaný pro autentizaci a šifrování mediálního toku. Bez tohoto atributu nebude WebRTC spojení navázáno.

Další bezpečnostní mechanismy zahrnují atribut a=setup:, který určuje roli DTLS handshake (active, passive, actpass), a a=ice-lite: pro zjednodušenou implementaci ICE na straně serveru. Všechny tyto parametry jsou přenášeny uvnitř SDP a kontrolovány oběma stranami před zahájením přenosu mediálních dat.

Typy SDP: Offer a Answer

V modelu WebRTC existují dva typy SDP zpráv: Offer (nabídka) a Answer (odpověď). Offer je vytvořen iniciátorem spojení a obsahuje úplný popis požadované mediální relace. Answer je vytvořen vzdáleným účastníkem jako odpověď na Offer a obsahuje jeho možnosti s ohledem na omezení uložená nabídkou.

Hlavní rozdíl mezi Offer a Answer spočívá v sémantice atributů. Offer vyjmenovává všechny podporované kodeky, transportní protokoly a síťové adresy, které může iniciátor nabídnout. Answer vybírá podmnožinu těchto možností podporovaných vzdálenou stranou. Například, pokud Offer nabízí opus, ISAC a PCMU, Answer může vybrat pouze opus jako nejpreferovanější kodek.

Proces výměny je regulován specifikací W3C WebRTC a zahrnuje několik stavů RTCPeerConnection. Po vytvoření Offer prostřednictvím createOffer() a jeho nastavení jako lokálního popisu přejde spojení do stavu have-local-offer. Po obdržení Answer a jeho nastavení jako vzdáleného popisu prostřednictvím setRemoteDescription() přejde spojení do stavu stable — konečného stavu připraveného k přenosu médií.

Použití SDP v mobilních SDK

Mobilní SDK pro WebRTC — Google WebRTC pro Android a WebRTC.framework pro iOS — plně podporují výměnu SDP prostřednictvím Offer a Answer. Na Androidu se pro vytvoření Offer používá třída PeerConnection s metodou createOffer(), podobnou API prohlížeče. Získaný popis SDP je přenášen jako řetězec prostřednictvím signalizačního kanálu.

Na iOS je práce s SDP postavena na třídě RTCSessionDescription z frameworku WebRTC. Při inicializaci se zadává typ (RTCSdpTypeOffer nebo RTCSdpTypeAnswer) a řetězec SDP. Platforma automaticky analyzuje SDP a nakonfiguruje spojení podle přenášených parametrů.

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

Možnost přímo pracovat s řetězcem SDP poskytuje vývojářům flexibilitu: mohou SDP před odesláním upravit, přidávat nebo odebírat určité kodeky, konfigurovat parametry ICE nebo přidávat vlastní atributy. Pro Android aplikace je často vyžadováno vypnutí videa v SDP při nízké šířce pásma sítě — to se provádí odstraněním odpovídajících řádků m= z popisu SDP.

SDP v mobilním vývoji

V mobilním vývoji je SDP používáno převážně v kontextu WebRTC — pro vytváření aplikací s videohovory, hlasovými chaty a streamováním. Mobilní aplikace na Androidu a iOS mohou vystupovat jak v roli iniciátora, tak v roli příjemce SDP zpráv, což umožňuje budovat symetrická peer-to-peer spojení.

Specifikem mobilních aplikací je potřeba pracovat s SDP v podmínkách proměnlivé kvality sítě. Při přepínání mezi Wi-Fi a mobilním internetem, stejně jako při změně šířky pásma, může být vyžadováno vygenerování nového popisu SDP. K tomu slouží mechanismus renegotiation — opakovaná výměna SDP prostřednictvím createOffer() a setLocalDescription().

Podle týmu Google WebRTC (2023) zahrnuje optimalizace výměny SDP pro mobilní zařízení použití ICE restart při změně sítě, prioritizaci kodeků s nízkou bitovou rychlostí (opus pro audio, VP8 pro video) a minimální velikost řetězce SDP vyloučením nepotřebných mediálních toků. Klíčovou výhodou je snížení latence při navázání spojení v mobilních sítích.

Optimalizace SDP pro mobilní sítě

Jedním z klíčových úkolů při práci s SDP na mobilních zařízeních je minimalizace velikosti popisu SDP. Plné SDP pro typickou relaci WebRTC s audiem a videem může zabírat 2–5 KB, což je významné pro pomalé sítě. Optimalizace zahrnuje použití BUNDLE (sloučení toků), odstranění nepodporovaných kodeků a kompresi ICE kandidátů.

Dalším problémem mobilních zařízení je omezená životnost SDP. V podmínkách nestabilního spojení může SDP zastarat dříve, než ho vzdálený účastník stihne zpracovat. Řešením je použití krátkých časových limitů pro příjem Answer a opětovné odeslání SDP v případě potřeby. Mechanismus ICE restart umožňuje obnovení spojení bez úplného přetvoření RTCPeerConnection. Atribut a=ice-lite zjednodušuje implementaci ICE na straně serveru.

Populární knihovny pro práci s SDP

Vývojáři mobilních aplikací mají k dispozici hotové knihovny, které usnadňují práci s SDP. libjingle_peerconnection (Google WebRTC) — hlavní knihovna pro Android, poskytující plné API pro správu SDP. Pro iOS se používá WebRTC.framework s obdobnou funkcionalitou. Obě knihovny automaticky generují a analyzují SDP, ale v případě potřeby poskytují přístup k surovému řetězci SDP.

Pro jemnější kontrolu nad SDP existují řešení třetích stran: sdp-transform (JavaScript nebo Node.js) pro analýzu a úpravu SDP, NICENICE (Java) pro práci s ICE kandidáty a hotové SDK od poskytovatelů infrastruktury WebRTC, které přebírají celou signalizační výměnu včetně SDP.