SDP — co to jest, format opisu sesji i rola w WebRTC

Czym jest SDP (Session Description Protocol)?

SDP — to protokół warstwy aplikacji przeznaczony do opisu parametrów sesji multimedialnych w formacie tekstowym. Został opracowany w ramach grupy roboczej MMUSIC (Multiparty Multimedia Session Control) IETF i po raz pierwszy znormalizowany w RFC 2327 w 1998 roku. W 2021 roku opublikowano aktualną specyfikację RFC 8866, która zastąpiła poprzednią wersję RFC 4566.

Głównym zadaniem SDP jest dostarczenie uczestnikom sesji wszystkich niezbędnych informacji do nawiązania połączenia: jakie strumienie medialne będą przesyłane, jakie kodeki są obsługiwane, pod jakimi adresami sieciowymi i portami będzie odbywać się transmisja. SDP nie przesyła samych danych multimedialnych, a jedynie opisuje, jak powinno być zorganizowane połączenie.

Według IETF RFC 8866 format SDP składa się z zestawu wierszy, z których każdy zaczyna się od jednoliterowego typu, po którym następuje znak równości i wartość. Na przykład wiersz m=audio 5004 RTP/AVP 0 oznacza, że sesja obejmuje strumień audio na porcie 5004 z protokołem transportowym RTP/AVP i kodekiem PCMU (typ 0).

Historia i normalizacja SDP

Pierwsza wersja SDP została opublikowana w RFC 2327 w kwietniu 1998 roku jako wynik prac grupy MMUSIC. Protokół został początkowo stworzony do ogłaszania sesji multicast w ramach Mbone (Multicast Backbone). Wraz z rozwojem VoIP i wideokonferencji zakres zastosowania SDP rozszerzył się, a w 2006 roku opublikowano zaktualizowaną specyfikację RFC 4566.

Przełom w wykorzystaniu SDP nastąpił wraz z pojawieniem się WebRTC w 2011 roku. Google zintegrował SDP jako podstawowy mechanizm opisu sesji medialnych w swoim frameworku do komunikacji w czasie rzeczywistym w przeglądarkach. Od tego momentu SDP stał się obowiązkowym komponentem każdej implementacji WebRTC — od przeglądarek po aplikacje mobilne na iOS i Android.

W 2021 roku grupa robocza IETF opublikowała RFC 8866 — aktualną specyfikację SDP, która zastąpiła RFC 4566. Zaktualizowana wersja doprecyzowała obsługę ICE (Interactive Connectivity Establishment), wsparcie DTLS (Datagram Transport Layer Security) i rozszerzyła możliwości opisu sesji grupowych.

Różnica między SDP a protokołami transportowymi

SDP zasadniczo różni się od protokołów transportowych tym, że nie uczestniczy w przesyłaniu danych. Pełni wyłącznie funkcję opisową — podobnie jak metadane pliku multimedialnego. Podczas gdy RTP (Real-time Transport Protocol) przesyła pakiety audio i wideo, a RTCP kontroluje jakość transmisji, SDP jedynie wskazuje, których kodeków i portów użyć.

Analogią z programowania internetowego: SDP to znaczniki HTML opisujące strukturę strony, a RTP to same obrazy i tekst. Bez SDP uczestnicy sesji nie wiedzą, jak się ze sobą połączyć, nawet jeśli połączenie sieciowe jest już nawiązane. Mechanizm NAT-traversal (ICE) również polega na SDP do przesyłania informacji o kandydatach sieciowych.

Jak zbudowana jest struktura SDP

Struktura SDP jest zorganizowana jako sekwencja wierszy tekstowych, z których każdy ma format type=value. Jednoliterowy typ określa przeznaczenie wiersza, a wartość zawiera odpowiednią wartość. Wszystkie wiersze są oddzielone znakiem nowej linii CRLF.

Standard RFC 8866 definiuje kilka pól obowiązkowych i opcjonalnych. Pola obowiązkowe obejmują wersję protokołu (v=), nazwę sesji (s=), czas rozpoczęcia i zakończenia sesji (t=). Pozostałe pola są opcjonalne, ale dla sesji WebRTC niezbędne są również opisy mediów (m=), atrybuty (a=) i informacje sieciowe (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

W powyższym przykładzie pokazano typowy segment SDP dla sesji WebRTC. Wiersz v=0 oznacza wersję protokołu. Pole o= zawiera identyfikator właściciela sesji i jej wersję. Wiersz s=- określa nazwę sesji (myślnik oznacza pustą nazwę). Pole t=0 0 wskazuje, że sesja nie jest ograniczona czasowo.

Pole a=group:BUNDLE audio video to atrybut grupujący kilka strumieni medialnych w jeden kanał transportowy. Mechanizm BUNDLE pozwala oszczędzać zasoby sieciowe poprzez przesyłanie audio i wideo przez jedno połączenie. Jest to szczególnie ważne dla urządzeń mobilnych o ograniczonej przepustowości.

Pola obowiązkowe SDP

Specyfikacja RFC 8866 definiuje zestaw pól obowiązkowych i opcjonalnych. Do obowiązkowych należą v= (wersja), s= (nazwa sesji) i t= (czas). Pole o= (właściciel), choć nie jest ściśle obowiązkowe według RFC, praktycznie zawsze występuje w rzeczywistych implementacjach.

Pole m= (media) jest jednym z najważniejszych. Opisuje konkretny strumień medialny i zawiera typ mediów (audio, video, text, application), port, protokół transportowy i listę obsługiwanych kodeków. W WebRTC najczęściej używane są typy audio i video z protokołami transportowymi RTP/SAVPF (Secure Audio/Video Profile with Feedback) lub UDP/TLS/RTP/SAVPF.

Pole a= (attribute) jest najbardziej elastyczne i rozszerzalne. Może zawierać rtpmap (mapowanie numeru kodeka na nazwę), fmtp (parametry kodeka), fingerprint (odcisk klucza DTLS), ice-ufrag i ice-pwd (dane uwierzytelniające ICE) oraz wiele innych atrybutów. To właśnie poprzez atrybuty SDP zapewnia obsługę nowoczesnych mechanizmów bezpieczeństwa i NAT-traversal.

Jak SDP działa w WebRTC

W architekturze WebRTC SDP pełni rolę protokołu sygnalizacyjnego do opisu i uzgadniania parametrów sesji medialnej między dwoma uczestnikami. Sam SDP nie definiuje mechanizmu przesyłania tych opisów — to zadanie rozwiązuje kanał sygnalizacyjny, który programista implementuje samodzielnie przez WebSocket, HTTP lub inny protokół.

Proces rozpoczyna się od utworzenia przez inicjatora (caller) oferty SDP — Offer. W tym celu przeglądarka wywołuje metodę createOffer() na obiekcie RTCPeerConnection. Wygenerowany opis SDP zawiera wszystkie parametry sesji po stronie inicjatora: obsługiwane kodeki, adresy sieciowe, kandydatów ICE i wymagania bezpieczeństwa.

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

// Utwórz ofertę SDP na Androidzie
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Wyślij ciąg SDP do zdalnego uczestnika
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

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

Po utworzeniu Offer i ustawieniu opisu lokalnego przez setLocalDescription(), inicjator wysyła ciąg SDP do zdalnego uczestnika przez kanał sygnalizacyjny. Zdalny uczestnik, po otrzymaniu SDP Offer, tworzy odpowiedź SDP — Answer — i wysyła ją z powrotem. Ta wymiana nazywana jest wymianą sygnalizacyjną (signaling exchange) i jest obowiązkowym etapem przed nawiązaniem połączenia peer-to-peer.

Według W3C WebRTC Specification, wymiana SDP powinna nastąpić przed rozpoczęciem wymiany kandydatów ICE. W praktyce wiele implementacji wysyła kandydatów ICE równolegle z SDP, używając mechanizmu ICE trickle. Skraca to czas nawiązywania połączenia, szczególnie w sieciach mobilnych o dużych opóźnieniach.

Rola ICE w SDP

ICE (Interactive Connectivity Establishment) — to mechanizm wykorzystujący atrybuty SDP do przesyłania informacji o kandydatach sieciowych. Kandydaci ICE opisują możliwe ścieżki połączenia: host (adres lokalny), srflx (adres po NAT, uzyskany przez STUN) i relay (adres serwera TURN).

W SDP kandydaci ICE są przesyłani przez atrybuty a=candidate:, a także przez pola ice-ufrag i ice-pwd do uwierzytelniania ruchu ICE. Każdy kandydat zawiera protokół transportowy (UDP, TCP), adres IP, port i priorytet. Udane połączenie jest nawiązywane przez pierwszego kandydata, który przejdzie test łączności. Mechanizm ICE restart pozwala odświeżyć połączenie przy zmianie sieci.

Dla aplikacji mobilnych kandydaci ICE są szczególnie ważne, ponieważ urządzenia często znajdują się za NAT lub firmowymi zapami ogniowymi. Mechanizm ICE pozwala znaleźć działającą ścieżkę nawet w skomplikowanych warunkach sieciowych, a SDP służy jako kontener transportowy dla tych informacji.

Bezpieczeństwo SDP w WebRTC

SDP w WebRTC obowiązkowo zawiera atrybuty bezpieczeństwa, w szczególności odcisk DTLS (fingerprint) i parametry SRTP. Pole a=fingerprint:sha-256 zawiera odcisk certyfikatu DTLS używany do uwierzytelniania i szyfrowania strumienia medialnego. Bez tego atrybutu połączenie WebRTC nie zostanie nawiązane.

Dodatkowe mechanizmy bezpieczeństwa obejmują atrybut a=setup:, który określa rolę uzgadniania DTLS (active, passive, actpass), oraz a=ice-lite: dla uproszczonej implementacji ICE po stronie serwera. Wszystkie te parametry są przesyłane wewnątrz SDP i weryfikowane przez obie strony przed rozpoczęciem transmisji danych multimedialnych.

Typy SDP: Offer i Answer

W modelu WebRTC istnieją dwa typy komunikatów SDP: Offer (oferta) i Answer (odpowiedź). Offer jest tworzony przez inicjatora połączenia i zawiera pełny opis pożądanej sesji medialnej. Answer jest tworzony przez zdalnego uczestnika w odpowiedzi na Offer i zawiera jego możliwości z uwzględnieniem ograniczeń narzuconych przez ofertę.

Główna różnica między Offer i Answer polega na semantyce atrybutów. Offer wymienia wszystkie obsługiwane kodeki, protokoły transportowe i adresy sieciowe, które może zaoferować inicjator. Answer wybiera podzbiór tych możliwości obsługiwany przez zdalną stronę. Na przykład, jeśli Offer oferuje opus, ISAC i PCMU, Answer może wybrać tylko opus jako najbardziej preferowany kodek.

Proces wymiany jest regulowany przez specyfikację W3C WebRTC i obejmuje kilka stanów RTCPeerConnection. Po utworzeniu Offer przez createOffer() i ustawieniu go jako opisu lokalnego, połączenie przechodzi w stan have-local-offer. Po otrzymaniu Answer i ustawieniu go jako opisu zdalnego przez setRemoteDescription(), połączenie przechodzi w stan stable — końcowy stan gotowy do transmisji mediów.

Użycie SDP w mobilnych SDK

Mobilne SDK dla WebRTC — Google WebRTC dla Androida i WebRTC.framework dla iOS — w pełni obsługują wymianę SDP przez Offer i Answer. Na Androidzie do tworzenia Offer używana jest klasa PeerConnection z metodą createOffer(), analogiczną do API przeglądarki. Otrzymany opis SDP jest przesyłany jako ciąg znaków przez kanał sygnalizacyjny.

Na iOS praca z SDP opiera się na klasie RTCSessionDescription z frameworka WebRTC. Podczas inicjalizacji podaje się typ (RTCSdpTypeOffer lub RTCSdpTypeAnswer) i ciąg SDP. Platforma automatycznie parsuje SDP i konfiguruje połączenie zgodnie z przesłanymi parametrami.

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żliwość bezpośredniej pracy z ciągiem SDP daje programistom elastyczność: można modyfikować SDP przed wysłaniem, dodając lub usuwając określone kodeki, konfigurując parametry ICE lub dodając niestandardowe atrybuty. Dla aplikacji na Androida często wymagane jest wyłączenie wideo w SDP przy niskiej przepustowości sieci — robi się to poprzez usunięcie odpowiednich wierszy m= z opisu SDP.

SDP w programowaniu mobilnym

W programowaniu mobilnym SDP jest używane przede wszystkim w kontekście WebRTC — do tworzenia aplikacji z połączeniami wideo, czatami głosowymi i streamingiem. Aplikacje mobilne na Androida i iOS mogą występować zarówno w roli inicjatora, jak i odbiorcy komunikatów SDP, co pozwala na budowanie symetrycznych połączeń peer-to-peer.

Specyfiką aplikacji mobilnych jest konieczność pracy z SDP w warunkach zmiennej jakości sieci. Podczas przełączania między Wi-Fi a internetem mobilnym, a także przy zmianie przepustowości, może być wymagane wygenerowanie nowego opisu SDP. Służy do tego mechanizm renegotiation — ponowna wymiana SDP przez createOffer() i setLocalDescription().

Według Google WebRTC team (2023), optymalizacja wymiany SDP dla urządzeń mobilnych obejmuje użycie ICE restart przy zmianie sieci, priorytetyzację kodeków o niskiej przepływności (opus dla audio, VP8 dla wideo) oraz minimalny rozmiar ciągu SDP poprzez wykluczenie niepotrzebnych strumieni medialnych. Kluczową zaletą jest zmniejszenie opóźnienia przy nawiązywaniu połączenia w sieciach mobilnych.

Optymalizacja SDP dla sieci mobilnych

Jednym z kluczowych zadań podczas pracy z SDP na urządzeniach mobilnych jest minimalizacja rozmiaru opisu SDP. Pełny SDP dla typowej sesji WebRTC z audio i wideo może zajmować 2–5 KB, co jest istotne dla wolnych sieci. Optymalizacja obejmuje użycie BUNDLE (łączenie strumieni), usuwanie nieobsługiwanych kodeków i kompresję kandydatów ICE.

Dodatkowym problemem urządzeń mobilnych jest ograniczony czas życia SDP. W warunkach niestabilnego połączenia SDP może stracić ważność, zanim zdalny uczestnik zdąży go przetworzyć. Rozwiązaniem jest użycie krótkich limitów czasu na otrzymanie Answer i ponowne wysłanie SDP w razie potrzeby. Mechanizm ICE restart pozwala odświeżyć połączenie bez całkowitego odtwarzania RTCPeerConnection. Atrybut a=ice-lite upraszcza implementację ICE po stronie serwera.

Popularne biblioteki do pracy z SDP

Programiści aplikacji mobilnych mają do dyspozycji gotowe biblioteki ułatwiające pracę z SDP. libjingle_peerconnection (Google WebRTC) — główna biblioteka dla Androida, udostępniająca pełne API do zarządzania SDP. Dla iOS używany jest WebRTC.framework z analogiczną funkcjonalnością. Obie biblioteki automatycznie generują i parsują SDP, ale dają dostęp do surowego ciągu SDP w razie potrzeby.

Do bardziej szczegółowej kontroli nad SDP istnieją zewnętrzne rozwiązania: sdp-transform (JavaScript lub Node.js) do parsowania i modyfikacji SDP, NICENICE (Java) do pracy z kandydatami ICE oraz gotowe SDK od dostawców infrastruktury WebRTC, które przejmują całą wymianę sygnalizacyjną, w tym SDP.