Protokół RTP (Real-time Transport Protocol) – co to jest i gdzie ma zastosowanie?

Protokół RTP (Real-time Transport Protocol) to standard sieciowy służący do przesyłania danych audio i wideo w czasie rzeczywistym przez sieci oparte na architekturze IP. Znajduje on zastosowanie przede wszystkim w telefonii VoIP, wideokonferencjach, systemach monitoringu oraz strumieniowaniu multimediów w przeglądarkach internetowych. Wymagania są twarde. Albo głos dociera do odbiorcy natychmiast, albo cała rozmowa traci sens.

RTP tnie strumień multimedialny na małe pakiety. Każdy z nich dostaje znacznik czasu i numer sekwencyjny. To pozwala urządzeniu końcowemu złożyć wszystko w odpowiedniej kolejności. Czasami pakiety gubią się po drodze. I tu wchodzi protokół UDP. RTP działa w warstwie aplikacji, ale pod spodem opiera się na bezpołączeniowym UDP. Pytasz dlaczego? Bo nie mamy czasu na retransmisję zgubionych danych. Jeśli ułamek sekundy głosu przepada na łączach operatora, to przepada bezpowrotnie. Słuchacz usłyszy ciche trzaśnięcie w słuchawce. Czekanie na ponowne przesłanie tego samego dźwięku stworzyłoby potężne opóźnienie. To jest bez mała najgorsza opcja z wszystkich dostępnych scenariuszy inżynieryjnych.

Gdzie najczęściej wykorzystujemy protokół Real-time Transport Protocol?

Pracowaliśmy niedawno nad wdrożeniem systemu komunikacji dla dyspozytorni karetek na wrocławskim Ołbinie. Stara centrala analogowa po prostu umarła we wtorek rano. Musieliśmy na szybko postawić serwer SIP oparty na Asterisku. To tam protokół RTP pokazał swoje prawdziwe zadanie. Kiedy dyspozytor odbiera zgłoszenie o wypadku, strumień audio wędruje bezpośrednio między jego komputerem a telefonem komórkowym dzwoniącego. Używamy go w WebRTC. Stosujemy go w kamerach IP monitorujących ruch na skrzyżowaniach drogowych. Wykorzystujemy go w aplikacjach do telemedycyny przy zdalnych operacjach. Prawda jest zresztą absolutnie taka, że każda aplikacja do rozmów wideo na twoim smartfonie ma w tle wdrożony ten konkretny standard.

Zastosowania protokołu RTP wykraczają daleko poza biurowe telefony. Branża telewizyjna przesyła nim surowy materiał wideo z wozów transmisyjnych do studiów nagraniowych. Protokół ten określa typ ładunku (Payload Type). Mówi urządzeniom, jakim kodekiem skompresowano dźwięk. Czy to stary G.711 używany w faksach, czy nowoczesny Opus kompresujący muzykę w wysokiej jakości. Koder pakuje sygnał, RTP nadaje mu ramy czasowe, a sieć przepycha to do celu.

Dlaczego telefonia VoIP potrzebuje RTP do działania?

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. SIP (Session Initiation Protocol) ustala połączenie. To on dzwoni, negocjuje parametry i mówi „chcę rozmawiać”. Ale SIP nie przesyła głosu. Głos leci w RTP. Kiedy podnosisz słuchawkę, procesor DSP przetwarza twój głos na ciąg zer i jedynek. RTP bierze te dane, paczkuje je po 20 milisekund dźwięku i wysyła w świat. Bez niego systemy VoIP po prostu by nie istniały. Widzieliśmy dziesiątki przypadków, gdzie firewall na brzegu sieci blokował porty UDP od 10000 do 20000. Efekt? Połączenie zestawione, czas trwania rozmowy leci, a w słuchawce absolutna cisza. To klasyczny problem z NAT i routingiem pakietów multimedialnych na urządzeniach klienckich.

VoIP rozdziela logikę sygnalizacji od logiki mediów. Serwer centrali musi wiedzieć, kto do kogo dzwoni. Nie musi jednak przetwarzać samego dźwięku. Telefony IP po zestawieniu sesji mogą wysyłać pakiety RTP bezpośrednio do siebie, omijając centralę. Odciąża to procesor serwera. Zmniejsza to opóźnienie.

W jaki sposób WebRTC łączy się z transmisją czasu rzeczywistego?

WebRTC to technologia pozwalająca na wideorozmowy prosto z przeglądarki Chrome czy Firefox bez instalowania wtyczek. Pod maską używa ona dokładnie tego samego protokołu RTP. Zmieniliśmy te zasady na robocie. Wdrożyliśmy wymóg szyfrowania. WebRTC nie pozwala na wysłanie czystego, jawnego strumienia. Wymusza użycie SRTP (Secure Real-time Transport Protocol). Klucze szyfrujące są wymieniane na etapie zestawiania połączenia przez mechanizm DTLS. Nikt podsłuchujący ruch u dostawcy internetu nie złoży z przechwyconych pakietów sensownej rozmowy.

Przeglądarka internetowa przechwytuje obraz z kamery internetowej. Kompresuje go kodekiem VP8 lub H.264. Rozcina na kawałki i pakuje w SRTP. Wymaga to ogromnej mocy obliczeniowej od procesora. Dlatego starsze laptopy mocno się grzeją podczas telekonferencji na kilkadziesiąt osób. Przesyłanie wideo w czasie rzeczywistym to matematyczna rzeźnia dla sprzętu.

Jakie są techniczne różnice między RTP a TCP i UDP?

TCP to kurier, który daje ci pokwitowanie do podpisania po dostarczeniu paczki. UDP to listonosz wrzucający ulotki przez płot bez sprawdzania, czy ktoś je podniósł. RTP to z kolei instrukcja przypięta do tych ulotek, mówiąca w jakiej kolejności należy je czytać. Wrzucam to zestawienie bezpośrednio.

To u nas w sumie chyba hipoteza z wczoraj bo pewności do tych trendów rynkowych nikt obecnie nie ma o 2025 r. Kiedyś próbowano pchać wideo przez TCP. Buforowanie wynikające z retransmisji zabijało cały sens transmisji na żywo. Wyobraź sobie, że oglądasz mecz piłki nożnej. Zgubiono pakiet z podaniem. TCP wstrzymuje odtwarzanie, prosi serwer o ponowne wysłanie, czeka ułamek sekundy i wznawia. Obraz zamarza. RTP pozwala na zignorowanie błędu. Zobaczysz na ekranie przez ułamek sekundy zielony kwadrat z artefaktami kompresji, ale akcja będzie toczyć się dalej.

Z jakimi problemami borykamy się konfigurując pakiety RTP na serwerach?

Największy ból głowy inżyniera to Jitter. Czasami pakiety przychodzą nierównomiernie przez obciążenie ruterów operatora. Jeden dotrze w 20 milisekund, drugi w 80 milisekund. Rozmowa zaczyna brzmieć jak z wnętrza pracującej pralki. (Swoją drogą, kiedy czytam te wszystkie zachodnie manuale o konfiguracji sieci, mam wrażenie że piszą je ludzie, którzy nigdy nie zarabiali kabla RJ45 w ciemnej piwnicy przy minus pięciu stopniach. Czysta teoria oderwana od brudu serwerowni). Używamy buforów jittera (Jitter Buffer) w telefonach IP, żeby wyrównać ten ruch na wejściu. Pakiety są przetrzymywane przez chwilę i układane w równych odstępach. Ale bufor to fizyczne opóźnienie. Za duży bufor i ludzie zaczynają wchodzić sobie w słowo podczas narady. ZROBILIŚMY na wdrożeniu testy z oscyloskopem. Zmniejszenie bufora o 10 milisekund usunęło problem nakładania się głosów u dyrekcji szpitala.

Kolejna usterka to przechodzenie przez NAT (Network Address Translation). Twój telefon ma prywatny adres IP w biurze. Serwer jest w chmurze. Kiedy wysyłasz zaproszenie SIP, podajesz swój prywatny adres jako miejsce do wysyłania mediów. Serwer próbuje wysłać odpowiedź na adres z puli 192.168.x.x i ruch trafia w próżnię. Rozwiązaniem jest stosowanie serwerów STUN (Session Traversal Utilities for NAT). Telefon pyta serwer STUN o swój publiczny adres IP i dopiero ten adres umieszcza w nagłówkach protokołu SDP. Kiedy to nie pomaga, bo firewall jest zbyt restrykcyjny, przepychamy cały ruch przez serwery TURN (Traversal Using Relays around NAT). To jednak drastycznie obciąża procesory.

Co robi RTCP i dlaczego dodajemy go do głównego strumienia?

RTP przesyła surowe dane multimedialne. RTCP (Real-time Transport Control Protocol) przesyła statystyki z sieci. To taki raport z frontu bitwy o pakiety.

• Odbiorca wysyła do nadawcy informację zwrotną o jakości. Mówi wprost: „gubię bez mała prawie pięćdziesiąt procent pakietów na łączu, zrób coś z tym natychmiast”. Nadawca oprogramowania widząc taki raport może samodzielnie zmienić kodek na mniej wymagający. Obniża jakość wideo z HD na SD, żeby ratować płynność dźwięku.
• Protokół RTCP działa zawsze na porcie UDP o numerze wyższym o jeden od przypisanego portu RTP. Zawsze.
• Synchronizuje różne strumienie medialne w czasie. Na przykład dźwięk i obraz z dwóch różnych kamer internetowych, żeby ruch ust prezentera zgadzał się ze słowami na ekranie. Czasami to nie wychodzi na tanim sprzęcie i mamy efekt azjatyckiego dubbingu.
• To daje wiele.

Gdy analizujemy zrzuty ruchu sieciowego w programie Wireshark, pakiety RTCP są pierwszym miejscem do szukania usterek. Widać w nich frakcję utraconych pakietów (Fraction Lost) oraz kumulatywną liczbę błędów. Jeśli te wartości rosną, winny jest zazwyczaj przeciążony switch po drodze, a nie sam serwer telefonii.

Jak poprawić jakość połączenia i zmniejszyć jitter w sieciach lokalnych?

Nie piszemy o tym, że sprzęt biurowy musi być fabrycznie nowy. To bzdura z ulotek reklamowych. Dobrym pomysłem jest włączenie QoS (Quality of Service) oraz standardu DSCP na routerach brzegowych firmy. Nadajesz pakietom RTP najwyższy priorytet w kolejkowaniu. Kiedy ktoś w księgowości zaczyna pobierać wielki plik z aktualizacją systemu, router najpierw przepuści pakiety z głosem, a dopiero potem resztę danych pobieranych w tle. Brak wdrożonego QoS to gwarancja problemów przy łączach poniżej 100 Mbps.

Inna sprawa to wyłączenie funkcji SIP ALG (Application-Level Gateway) na routerach dostarczanych przez lokalnych operatorów internetowych. Ten wbudowany mechanizm ma w teorii pomagać przy przechodzeniu przez NAT. W zdecydowanej większości modyfikuje on nagłówki pakietów w taki sposób, że zrywa nam połączenia równo po 30 sekundach od odebrania połączenia. Wyłącz to od razu. Zablokuj kalendarz, wejdź w panel administracyjny routera i odznacz tę opcję. To rozwiązuje 90 procent problemów z głosem w małych firmach.

Zadbaj o dobór kodeków. W sieciach lokalnych (LAN) przepustowość jest duża, więc używamy kodeka G.711 alaw, który wcale nie kompresuje dźwięku. Daje doskonałą jakość, ale zżera 64 kbps plus narzut nagłówków per kanał. Gdy łączymy dwa odległe oddziały firmy przez niestabilny VPN, wymuszamy użycie kodeka G.729. Obcina on jakość do poziomu starego telefonu komórkowego, ale wymaga zaledwie 8 kbps przepustowości. Zmiana kodeka potrafi uratować komunikację na zapchanych radioliniach.

Sprawdź logi na swojej centrali telefonicznej. Zaloguj się przez SSH na serwer Linuxa i odpal polecenie tcpdump na interfejsie sieciowym. Zobacz na własne oczy, jak setki pakietów UDP przelatują przez terminal. Przeanalizuj ich porty i adresy źródłowe. Jeśli tego nie zrobisz, dalej będziesz zgadywać po omacku, dlaczego klienci dzwoniący na infolinię narzekają na uciętą pierwszą sylabę w rozmowie. Zostawiam cię z tym zadaniem na serwerowni do rozwiązania na dzisiaj.

Często zadawane pytania (FAQ)

• Co to jest RTP?
  To protokół sieciowy służący do przesyłania dźwięku i obrazu w czasie rzeczywistym przez sieci IP.
• Jaki port używa protokół RTP?
  Nie ma jednego stałego portu. Zazwyczaj używa parzystych portów UDP z zakresu od 10000 do 20000, ustalanego w fazie sygnalizacji.
• Czy RTP szyfruje przesyłane dane?
  W standardowej wersji nie. Do szyfrowania głosu i obrazu używa się rozszerzenia SRTP.
• Czym różni się RTP od RTCP?
  RTP przesyła właściwy dźwięk i obraz. RTCP przesyła statystyki o jakości tego połączenia i utraconych pakietach.
• Dlaczego RTP używa UDP zamiast TCP?
  Ponieważ w transmisji głosu na żywo opóźnienia są gorsze niż utrata pojedynczych ułamków sekundy dźwięku. UDP nie wymusza retransmisji.
• Jak naprawić brak dźwięku w telefonie VoIP?
  Najczęstszą przyczyną jest blokowanie portów UDP na firewallu lub włączona opcja SIP ALG na routerze operatora. Należy otworzyć porty i wyłączyć ALG.

Bibliografia

1. Internet Engineering Task Force – https://www.ietf.org
2. Cisco Systems – https://www.cisco.com
3. Wydawnictwo Naukowe PWN – https://pwn.pl
4. Instytut Łączności – Państwowy Instytut Badawczy – https://www.il-pib.pl
5. Asterisk Project – https://www.asterisk.org