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

Protokół SDP (Session Description Protocol) to tekstowy format służący do opisywania parametrów sesji multimedialnych, który pozwala urządzeniom ustalić wspólne zasady przesyłania dźwięku i obrazu w sieci. Działa on jak cyfrowa wizytówka wymieniana przed rozpoczęciem połączenia, zawierająca informacje o adresach IP, dostępnych portach oraz obsługiwanych kodekach.

Zmieniliśmy te zasady na robocie lata temu. Kiedyś urządzenia telekomunikacyjne po prostu rzucały w siebie danymi w ciemno. Dzisiaj WebRTC i klasyczne systemy VoIP wymuszają sztywną negocjację. SDP nie przenosi samego dźwięku. To jest fakt. On tylko mówi, gdzie ten dźwięk wysłać i jak go spakować.

Jakie informacje przenosi protokół SDP w sieciach IP?

Siedziałem wczoraj o 3 nad ranem przy zrzutach z serwera. System po prostu wywalał błąd negocjacji wideo. Zmęczenie materiału robi swoje u każdego inżyniera. Klient zgłaszał brak obrazu na terminalach. Okazało się, że w pakiecie brakowało prostej linii opisującej profil kodeka. To brutalnie uczy pokory do starych standardów tekstowych. Protokół ten definiuje parametry w oparciu o czysty tekst ASCII. Nie ma tu miejsca na binarną magię.

Wewnątrz takiego komunikatu znajdziemy ściśle określone dane. Adres IP maszyny, która chce odbierać ruch. Numer portu UDP dla protokołu RTP. Listę kodeków ułożoną według preferencji. Parametry przepustowości. Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Urządzenia często mają problem z interpretacją atrybutów specyficznych dla danego oprogramowania. Zwykła literówka w nazwie profilu H.264 kładzie całą wideokonferencję.

Struktura opiera się na liniach typu klucz-wartość. Zawsze jedna litera, znak równości i wartość. Wymienię tu podstawy bez owijania w bawełnę:

• v=0 definiuje wersję protokołu i od lat jest to zawsze zero, bo nikt nigdy nie wdrożył wersji pierwszej i prawdopodobnie nigdy tego nie zrobi z uwagi na kompatybilność wsteczną miliardów urządzeń.
• o= to identyfikator właściciela sesji i numer wersji samej sesji.
• m= określa typ mediów, port i protokół transportowy.
• a= to atrybuty. Tutaj dzieje się cała brudna robota związana z parametrami kodeków, kluczami szyfrującymi dla SRTP czy kandydatami ICE do omijania NAT. Czasem tych linii w jednym bloku jest kilkadziesiąt i serwer musi to wszystko przetworzyć w ułamek sekundy. Wtedy pro​tokół pokazuje swoje możliwości.

Dlaczego WebRTC i SIP nie mogą działać bez SDP?

SIP odpowiada za sygnalizację. Dzwoni, odbiera, rozłącza. Ale SIP jest ślepy i głuchy. Nie wie, co to jest dźwięk. Dlatego w ciele wiadomości SIP INVITE zawsze siedzi doklejony komunikat SDP. W telekomunikacji nazywamy to modelem Offer/Answer.

Jeden telefon wysyła ofertę. Pokazuje swoje karty. Mam adres IP taki a taki, obsługuję kodek Opus i G.711, mój port to 10000. Drugi telefon odbiera ten tekst. Czyta go. Zgadza się na Opus, wybiera swój port i odsyła odpowiedź. Wtedy następuje zestawienie strumienia. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, ile dokładnie sesji pada przez błędy w atrybutach formatowania w skali globalnej, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed zmianą oprogramowania w centralach. Prawda jest zresztą absolutnie taka, że połowa problemów z VoIP to źle sformułowana odpowiedź SDP.

WebRTC korzysta z tego samego mechanizmu. Przeglądarka internetowa generuje potężny blok tekstu. Często waży on kilka kilobajtów. Znajdują się tam odciski palców certyfikatów DTLS. WebRTC bez tego tekstu po prostu nie wie, jak nawiązać bezpieczne połączenie bezpośrednio między dwoma komputerami. Wymusza to na deweloperach stosowanie zjawiska zwanego SDP munging, czyli ręcznej edycji tego tekstu w locie za pomocą JavaScriptu, żeby wymusić na przeglądarce konkretne zachowanie.

Jak przebiega negocjacja parametrów w praktyce?

Mechanizm ten jest brutalnie prosty. Inicjator wysyła ofertę. Odbiorca wysyła odpowiedź. Jeśli odpowiedź nie pasuje do oferty, połączenie jest zrywane z błędem 488 Not Acceptable Here.

Warto spojrzeć na proces wymiany kandydatów ICE. Kiedy dwa urządzenia są za routerami z NAT, nie znają swoich publicznych adresów IP. SDP w WebRTC zawiera dziesiątki linii zaczynających się od a=candidate. To są potencjalne ścieżki połączenia. Maszyny testują je wszystkie naraz. Wygrywa ta ścieżka, która pierwsza przepuści pakiety. To czysta inżynieria oparta na brutal force.

Co oznaczają poszczególne linie w strukturze komunikatu SDP?

Rozbicie tego na czynniki pierwsze pokazuje, z czym tak naprawdę mierzy się parser w serwerze telekomunikacyjnym. Maszyna czyta to z góry na dół.

W sumie to fascynujące. Często branża telekomunikacyjna trzyma się standardów z lat dziewięćdziesiątych. Kiedyś na szkoleniu w starym budynku centrali na warszawskim Mokotowie pewien inżynier sieciowy powiedział mi, że sprzęt ma duszę z drutu miedzianego. My tylko próbujemy nakładać na to wirtualne maski. Miał rację. Dzisiejsze wirtualizacje kontenerowe i chmury ostatecznie sprowadzają się do przepychania tych samych nagłówków tekstowych przez wirtualne interfejsy. Nic się nie zmieniło na samym dole stosu sieciowego.

Czy SDP przesyła sam dźwięk lub obraz?

Format ten nigdy nie dotyka samego dźwięku. To ogromne nieporozumienie u początkujących administratorów. SDP to tylko mapa. Dźwięk i obraz płyną innym kanałem, korzystając z protokołu RTP (Real-time Transport Protocol). Jeśli mapa jest zła, RTP wyśle pakiety w próżnię.

Protokół o którym mowa działa w warstwie aplikacji i jest przenoszony przez inne protokoły. Sam z siebie nie posiada mechanizmu transportowego. W SIP lata wewnątrz ciał wiadomości. W WebRTC jest przesyłany przez WebSocket lub dowolny inny kanał sygnalizacyjny wybudowany przez programistę.

Jakie błędy w konfiguracji SDP psują połączenia głosowe?

Niezgodność kodeków to plaga. Ty oferujesz G.722, ja obsługuję tylko G.711a. Wymieniamy się plikami SDP. Serwer widzi brak części wspólnej. ODRZUCA cały ruch. Użytkownik słyszy krótki sygnał zajętości i koniec.

Kolejna sprawa to problem z adresacją w linii c=. Kiedy telefon z wewnętrznej sieci wyśle w ofercie swój prywatny adres IP (np. 10.0.0.5), urządzenie po drugiej stronie internetu będzie próbowało wysłać tam dźwięk. Pakiety trafią w czarną dziurę. To klasyczny problem braku dźwięku w jedną stronę (one-way audio). Rozwiązaniem jest stosowanie serwerów STUN/TURN, które podmieniają ten adres w tekście SDP na publiczny adres routera przed wysłaniem oferty w świat.

Pojawia się też kwestia asymetrii portów (Early Media). Zanim odbierzesz połączenie, słyszysz sygnał dzwonienia z centrali. To wymaga odczytania parametrów SDP jeszcze przed formalnym zestawieniem sesji (200 OK w SIP). Zmieniliśmy te zasady na robocie lata temu, wprowadzając mechanizm PRACK, by upewnić się, że wczesne media nie gubią się na łączach operatorskich.

Gdzie szukać przyczyny braku dźwięku w telefonii VoIP?

Odpal sniffera. Złap pakiet SIP INVITE. Zobacz, co siedzi w ciele wiadomości. Sprawdź linię c= oraz m=audio. Jeśli adres w linii c= to adres prywatny, a ty łączysz się przez internet, masz winowajcę. Jeśli port w linii m= to 0, oznacza to, że druga strona celowo odrzuciła ten konkretny strumień multimediów w negocjacji.

Kto wymyślił ten format i po co nam on dzisiaj?

IETF opublikowało specyfikację w RFC 4566. Organizacja ta zdefiniowała ramy, które przetrwały próbę czasu. Format powstał w czasach, gdy przepustowość sieci liczyło się w kilobitach, a procesory miały problem z przetwarzaniem skomplikowanych struktur XML.

Zastosowano czysty tekst. Maszyny parsują go błyskawicznie. Ludzie czytają go bezpośrednio z logów systemowych bez użycia dekompilatorów. Chociaż prawdę mówiąc brakuje nam twardych danych z tamtego okresu, kto dokładnie wklepał pierwszy wiersz kodu w laboratorium, to technologia ta wciąż trzyma w ryzach całą współczesną komunikację IP.

Nie używamy już starych kodeków sprzętowych. Zastąpił je Opus i VP9. Ale nadal opisujemy je za pomocą tego samego, asymetrycznego układu linii i liter. Atrybuty a=fmtp potrafią dzisiaj przenosić skomplikowane parametry dla sztucznej inteligencji odszumiającej dźwięk, ale nadal są tylko ciągiem znaków w starej, dobrej wizytówce.

Zostawiam was z jednym zadaniem. Odpalcie jutro rano Wiresharka na swojej karcie sieciowej. Zróbcie połączenie testowe z przeglądarki przez dowolny komunikator WebRTC. Wpiszcie w filtr słowo „sdp”. Zobaczcie na własne oczy, jak wasz komputer wypluwa kilkadziesiąt linii tekstu, tylko po to, żebyście mogli powiedzieć „halo” do mikrofonu. To uczy szacunku do warstwy sieciowej.

Często zadawane pytania (FAQ)

• Co to jest protokół SDP?
  SDP (Session Description Protocol) to tekstowy format używany do opisywania parametrów sesji multimedialnych. Zawiera informacje o adresach IP, portach i kodekach, pozwalając urządzeniom zestawić połączenie audio lub wideo.
• Czy SDP przesyła dźwięk i obraz?
  Nie. Protokół ten służy wyłącznie do negocjacji parametrów połączenia. Za właściwy transport mediów (dźwięku i obrazu) odpowiada protokół RTP.
• Do czego służy linia m= w komunikacie SDP?
  Linia m= (media announcement) określa typ przesyłanych mediów (np. audio lub wideo), port transportowy oraz wykaz obsługiwanych wariantów kodeków.
• Jak SDP współpracuje z protokołem SIP?
  SIP odpowiada za sygnalizację (dzwonienie, odbieranie), natomiast SDP jest przesyłany wewnątrz wiadomości SIP i definiuje, w jaki sposób urządzenia mają wymieniać między sobą dane multimedialne po odebraniu połączenia.
• Co oznacza błąd negocjacji kodeków?
  Występuje on, gdy w wymienianych plikach SDP urządzenia nie znajdą ani jednego wspólnego kodeka audio lub wideo. W takiej sytuacji połączenie jest natychmiast zrywane.
• Dlaczego adresy IP w SDP powodują brak dźwięku?
  Jeśli urządzenie znajduje się za routerem (NAT) i wyśle w ofercie SDP swój prywatny adres IP, druga strona będzie próbowała wysłać tam pakiety RTP. Pakiety zostaną odrzucone w internecie, co skutkuje brakiem słyszalności.

Bibliografia

1. Internet Engineering Task Force (IETF) – https://www.ietf.org
2. Wydawnictwo Naukowe PWN – https://pwn.pl
3. Instytut Łączności – Państwowy Instytut Badawczy – https://www.gov.pl/web/instytut-lacznosci
4. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
5. Naukowa i Akademicka Sieć Komputerowa (NASK) – https://www.nask.pl