Protokół SDP (Session Description Protocol) – do czego służy i jak działa?

Session Description Protocol (SDP) jest fundamentem nowoczesnych systemów komunikacji multimedialnej, pozwalając punktom końcowym opisywać i negocjować parametry sesji, niezależnie od tego, czy to Voice over IP, wideokonferencje czy streaming. SDP nie transportuje mediów, lecz precyzyjnie opisuje warunki ich wymiany: kodeki, adresy IP, porty, protokoły i właściwości transmisji.

Treść (pokaż)

Od RFC 2327 (1998) do RFC 8866 (2021) specyfikacja ewoluowała, zachowując prostotę i zgodność wsteczną. Tekstowy format i rozszerzalność poprzez atrybuty czynią SDP wyjątkowo czytelnym oraz łatwym do debugowania.

Fundamentalne charakterystyki i geneza Session Description Protocol

SDP powstał w IETF, by standaryzować opis parametrów sesji multimedialnych w sposób uniwersalny i niezależny od protokołu transportowego.

W praktyce SDP najczęściej podróżuje z protokołami sygnalizacyjnymi. Oto najczęstsze kanały przenoszenia SDP:

SIP – dominujący w telefonii IP oraz wideopołączeniach;
SAP – ogłoszenia sesji multicast;
RTSP – opisy strumieni w streamingu;
HTTP/HTTPS – aplikacje i interfejsy webowe;
poczta elektroniczna i inne – alternatywne ścieżki dystrybucji.

Kluczowe jest zrozumienie charakteru wymiany: SDP nie „negocjuje” mediów jak dialog – oferent deklaruje możliwości, a odpowiadający wybiera z oferty. Taka asymetryczność upraszcza proces, czyni go deterministycznym i eliminuje kolizje równoczesnych ofert.

Przed SDP rynek borykał się z brakiem wspólnego formatu, co skutkowało problemami interoperacyjności. Pojawienie się SDP wniosło czytelny, tekstowy opis możliwy do zinterpretowania przez dowolną zgodną implementację.

Wewnętrzna struktura i komponenty Session Description Protocol

Opis SDP to zestaw linii w formacie <typ>=<wartość>, gdzie <typ> to jeden znak, a <wartość> zależy od typu. Spacje wokół znaku równości są niedozwolone. Opis zawiera sekcje: opis sesji, opisy czasowe i opisy mediów.

Sekcja opisu sesji

Poniżej zebrano najważniejsze pola sekcji opisu sesji i ich znaczenie:

v= – wersja protokołu (zawsze 0);
o= – identyfikacja originatora i sesji (nazwa użytkownika, identyfikator sesji, wersja, typ sieci, typ adresu, adres);
s= – nazwa sesji (co najmniej jeden znak UTF‑8; w razie braku sensownej nazwy zalecana pojedyncza spacja lub myślnik);
i= – opis informacyjny sesji (opcjonalny);
u= – URI z dodatkowymi informacjami o sesji (opcjonalny);
e= / p= – kontakt: e‑mail i telefon (opcjonalne);
c= – informacje o połączeniu (typ sieci, typ adresu, adres połączenia);
b= – przepustowość z modyfikatorami (np. AS, RS, RR);
z= – korekty stref czasowych i czasu letniego (opcjonalne).

Sekcja opisów czasowych

Obowiązkowe opisy czasowe definiują okna aktywności sesji. Linia t= podaje czas startu i zakończenia w formacie NTP (sekundy od 1900‑01‑01).

Jeśli koniec to 0, sesja jest bezterminowa; jeśli start i koniec to 0, sesja jest permanentna. Opcjonalne r= określa powtórzenia (np. tygodniowe), niezależne od lokalnej strefy czasowej.

Sekcja opisów mediów

Każdy strumień zaczyna linia m= z typem mediów, portem, protokołem (np. RTP/AVP) i listą formatów. Opcjonalne i= dodaje tytuł strumienia, a c= na poziomie mediów może nadpisać parametry połączenia z poziomu sesji.

Atrybuty a= precyzują szczegóły, m.in. mapowanie RTP (a=rtpmap:), parametry formatów (a=fmtp:) czy kierunek strumienia. Najczęściej używane kierunki to:

a=sendrecv – dwukierunkowa wymiana mediów;
a=sendonly – wysyłanie bez odbioru;
a=recvonly – odbiór bez wysyłania;
a=inactive – brak wymiany mediów.

Atrybuty są kluczowym mechanizmem rozszerzania SDP, bez zmiany podstaw protokołu.

Model offer/answer w Session Description Protocol

Negocjacja odbywa się w modelu offer/answer z RFC 3264, zwykle przenoszonym przez SIP.

Oferent (offerer) wysyła ofertę SDP z listą strumieni, kodeków, adresów i portów;
Odpowiadający (answerer) wybiera kompatybilne kodeki i kierunki, lub odrzuca strumień, ustawiając port na 0;
Kierunek wymiany mediów definiują atrybuty a=sendrecv, a=sendonly, a=recvonly, a=inactive.

Model offer/answer zapewnia determinizm i zapobiega konfliktom przy równoczesnych ofertach.

SDP w systemach komunikacji Voice over IP

W VoIP protokół SIP inicjuje, modyfikuje i kończy połączenia, a SDP przenosi szczegóły mediów. Inicjator wysyła INVITE z ofertą SDP, a abonent odpowiada 200 OK z odpowiedzią SDP.

RTP faktycznie transportuje audio/wideo na podstawie parametrów wynegocjowanych w SDP.

Jeśli strony nie mają co najmniej jednego wspólnego kodeka, połączenie nie powstanie (np. błąd 488 Not Acceptable Here). Dla bezpieczeństwa interoperacyjności oferent powinien uwzględnić przynajmniej PCMU (G.711).

Przykładowe, często używane kodeki w VoIP i ich podstawowe parametry są pokazane poniżej:

Kodek	Payload type	Clock rate	Uwagi
PCMU (G.711 μ-law)	0	8000 Hz	powszechny kodek bazowy
PCMA (G.711 A-law)	8	8000 Hz	standard w regionach stosujących A-law
G.729	18	8000 Hz	niski bitrate, wymaga licencji w części wdrożeń
Opus	dynamiczny (96–127)	8000–48000+ Hz	elastyczny, wysoka jakość w zmiennych warunkach
DTMF (telephone-event)	często 101 (dynamiczny)	8000 Hz	sygnalizacja tonów, `a=rtpmap` i `a=fmtp` wymagane

SDP w Web Real-Time Communication (WebRTC)

W WebRTC SDP jest „językiem możliwości” wymienianym kanałem sygnalizacyjnym (np. WebSocket, HTTPS). Oferta powstaje metodą RTCPeerConnection.createOffer(), a odpowiedź – createAnswer().

SDP w WebRTC zawiera m.in. ICE candidates, które opisują potencjalne ścieżki łączności. Typowe kategorie kandydatów to:

host – bezpośrednie interfejsy sieciowe urządzenia;
server-reflexive – adresy ujawnione przez serwer STUN;
relay – adresy uzyskane przez serwer TURN.

Po wymianie SDP strony wykonują ICE connectivity checks, korzystając z STUN/TURN do wyboru najlepszego połączenia.

Ważne funkcje WebRTC oparte na SDP to m.in. BUNDLE (multipleksacja wielu strumieni przez jedno połączenie) oraz simulcast (wielowariantowa wysyłka wideo dopasowana do warunków sieci).

SDP w Real-Time Streaming Protocol (RTSP)

W RTSP opis SDP określa parametry strumieni oferowanych przez serwer. Klient wysyła DESCRIBE, a serwer zwraca SDP z informacjami o portach, kodekach, szybkościach próbkowania i innych parametrach.

RTSP ma architekturę klient–serwer, w której serwer transmituje media do klientów, odmiennie od modelu peer‑to‑peer charakterystycznego dla WebRTC.

Struktura praktycznego opisu SDP

Poniżej prosty przykład SDP dla sesji audio:

v=0 o=MyStreamer 2398026505 2307593197 IN IP4 10.20.30.40 s=MyStreamer Audio Session c=IN IP4 10.11.12.13 t=0 0 m=audio 15010 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv

v=0 to wersja SDP. o= identyfikuje originatora i sesję. s= zawiera nazwę sesji, a c= wskazuje adres docelowy mediów. t=0 0 oznacza sesję permanentną. m= definiuje audio na porcie 15010 z RTP/AVP i formatami 0 (PCMU) oraz 101 (telephone‑event). Atrybuty a=rtpmap mapują typy ładunku na kodeki i częstotliwości, a a=sendrecv – kierunek dwukierunkowy.

Poniżej przykład z audio, wideo i zabezpieczeniem SRTP:

v=0 o=alice 2890844526 2890844526 IN IP4 192.0.2.1 s=Alice's Video Session c=IN IP4 192.0.2.1 t=0 0 m=audio 49170 RTP/SAVP 111 a=rtpmap:111 opus/48000/2 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:... m=video 51372 RTP/SAVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e01e a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:...

Ten opis używa profilu RTP/SAVP oraz a=crypto do negocjacji parametrów SRTP. Audio w Opus (stereo), wideo w H.264 z określonym profilem.

Negocjacja parametrów transmisji i przepustowości

Przepustowość ustala się polem b= z modyfikatorami. Poniżej najważniejsze z nich:

AS – całkowita przepustowość dla strumienia mediów (zwykle w kb/s);
RS – przepustowość RTCP dla nadawców (RFC 3556);
RR – przepustowość RTCP dla odbiorców (RFC 3556).

Dla multicastu wartości interpretowane są jako łączna przepustowość dla wszystkich węzłów. Na poziomie pojedynczego strumienia wartości na warstwie mediów mogą nadpisywać ustawienia sesji.

Atrybuty SDP i mechanizmy rozszerzenia

Atrybuty pozwalają rozbudowywać możliwości bez zmiany podstaw protokołu. Wybrane, najczęściej używane atrybuty:

a=rtpmap: – mapowanie RTP payload type na kodek i clock rate;
a=fmtp: – parametry formatu i kodeka (np. profil, poziom, przepływność);
a=candidate: – kandydaci ICE z adresami, portami i typami;
a=ice-ufrag: – identyfikator użytkownika dla ICE;
a=ice-pwd: – hasło dla ICE;
a=group:BUNDLE – grupowanie wielu m‑linii do jednego połączenia.

Rozszerzenia z RFC 5939 i RFC 6871 wprowadzają negocjację możliwości (capability negotiation), m.in.:

a=tcap: – możliwości transportu (np. profile RTP, w tym Secure RTP);
a=rmcap: – możliwości formatów mediów dla RTP;
a=omcap: – możliwości formatów poza RTP.

Bezpieczeństwo w Session Description Protocol

Bezpieczeństwo mediów zapewnia SRTP z sygnalizacją w SDP. Wybrane mechanizmy:

a=crypto – negocjacja zestawów kryptograficznych i materiału kluczowego (RFC 4568);
DTLS‑SRTP – preferowane w WebRTC, z odciskami palców certyfikatu w SDP;
SIPS/S/MIME – ochrona transportu i treści SDP w SIP; w WebRTC zwykle HTTPS/WebSocket Secure.

Materiał kluczowy i parametry kryptograficzne muszą być chronione co najmniej tak dobrze, jak same media. Dla prywatności warto minimalizować dane ujawniane w polu o= i innych częściach opisu.

Praktyczne scenariusze negocjacji i rozwiązywanie problemów

Najczęstsze problemy i ich przyczyny:

brak wspólnego kodeka – oferta i odpowiedź nie mają części wspólnej; skutkuje to błędem 488 Not Acceptable Here;
DTMF/telephone‑event z niespójnymi payload type – a=fmtp odwołuje się do innego numeru niż w linii m=;
WebRTC: ICE/kodeki/DTLS – niepoprawni kandydaci, rozbieżne profile kodeków lub błąd w fingerprint; diagnoza przez inspekcję faktycznego SDP i logów przeglądarki (console.log()).

Zaawansowane koncepty i rozszerzenia

BUNDLE multipleksuje wiele strumieni (audio, wideo) przez jedno połączenie sieciowe, redukując narzut i opóźnienia zestawiania.

Simulcast umożliwia wysyłanie tego samego wideo w kilku rozdzielczościach/przepływnościach, aby odbiorca mógł wybrać wariant zgodny z warunkami sieci i możliwościami urządzenia. Parametry określają a=rid: i a=simulcast:.