SIP, RTP, SRTP i kodeki: co naprawdę trzeba wiedzieć

SIP zarządza sesją

IETF opisuje SIP jako protokół warstwy aplikacji, który może ustanawiać, modyfikować i kończyć sesje multimedialne. Pomaga odnaleźć użytkownika, sprawdzić jego dostępność, uzgodnić możliwości i zarządzać przebiegiem sesji. W typowym scenariuszu aplikacja rejestruje adres kontaktowy, wysyła zaproszenie do rozmowy i otrzymuje odpowiedzi wskazujące dalszy etap.

To nie znaczy, że SIP sam przenosi głos. Dokument RFC 3261 wprost umieszcza go w architekturze współpracującej z innymi protokołami, między innymi RTP i SDP. Dlatego można poprawnie zalogować konto, zobaczyć dzwonienie i nadal mieć problem z mediami. Rejestracja potwierdza określoną wymianę sygnalizacyjną, nie całą ścieżkę rozmowy.

Nazwy, które łatwo pomylić

Identyfikator użytkownika służy do rozpoznania konta. Osobny identyfikator autoryzacji może być używany przy uwierzytelnieniu. Domena lub serwer wskazują środowisko usługi, nazwa wyświetlana opisuje kontakt, a numer prezentowany odbiorcy zależy od uprawnień konta i sieci. Aplikacja może nazywać te pola inaczej. Nie zamieniaj ich miejscami tylko dlatego, że wszystkie przypominają numer lub adres.

RTP zwykle przenosi media

RTP zapewnia funkcje transportowe dla danych czasu rzeczywistego. Pakiety mają między innymi numery sekwencyjne i znaczniki czasu, co pozwala odbiornikowi porządkować strumień i oceniać jego dostarczanie. Towarzyszący protokół RTCP może przekazywać informacje pomocne w monitorowaniu odbioru.

RTP nie gwarantuje jednak, że pakiety dotrą na czas, w kolejności ani w ogóle. Nie rezerwuje jakości w niższych warstwach sieci. To wyjaśnia, dlaczego test prędkości pobierania nie jest pełnym testem głosu. Rozmowa potrzebuje przede wszystkim regularnego przepływu małych porcji danych; strata, nierówne opóźnienia i zbyt długi czas obiegu są słyszalne w dialogu.

Dzwoni, ale jest cisza

Jeżeli wywołanie dochodzi, lecz jedna strona nic nie słyszy, zapisz kierunek ciszy i rodzaj sieci. Sygnalizacja mogła przejść inną drogą niż media. Przyczyną może być NAT, zapora, niedopasowana informacja o adresie, brak wspólnego kodeka albo lokalna trasa mikrofonu i głośnika. Jeden objaw nie rozstrzyga przyczyny, dlatego potrzebne jest porównanie według macierzy testów.

TLS i SRTP chronią różne elementy

TLS może zabezpieczać połączenie używane przez sygnalizację SIP. Aktualne wdrożenie nie powinno wracać do TLS 1.0 lub 1.1, które IETF formalnie wycofał. Weryfikacja certyfikatu jest częścią zaufania do serwera; zaakceptowanie błędu na stałe nie jest neutralnym „testem łączności”.

SRTP jest profilem RTP zapewniającym mechanizmy poufności, integralności i ochrony przed powtórzeniem dla strumieni RTP i RTCP, zależnie od uzgodnionej konfiguracji. Ochrona wymaga również właściwego zarządzania kluczami. Sam wybór napisu „SRTP” w aplikacji nie dowodzi, że drugi koniec i wszystkie elementy usługi zestawiły oczekiwany wariant.

Szyfrowane nie zawsze oznacza end-to-end

Połączenie może być chronione na kolejnych odcinkach, a mimo to przechodzić przez serwer, bramę do sieci telefonicznej lub element przetwarzający media. SIPS i TLS dotyczą bezpiecznego dotarcia sygnalizacji zgodnie z architekturą SIP, nie są automatyczną obietnicą zaszyfrowanego głosu od rozmówcy do rozmówcy. SRTP chroni media, ale zakres i zakończenie ochrony wynikają z projektu usługi. Szukaj jednoznacznego opisu dostawcy, zamiast wnioskować z ikony kłódki.

Kodek zamienia głos na dane i z powrotem

Kodek wpływa na sposób kodowania, wymagane zasoby, odporność na niektóre warunki i zgodność z drugim końcem. RFC 7587 opisuje przenoszenie Opus w RTP; Opus obsługuje różne pasma audio i może zmieniać parametry strumienia. RFC 3551 opisuje między innymi PCMA i PCMU, oparte na G.711, w profilu RTP.

Nie wynika z tego uniwersalny zwycięzca. Konto łączące się z tradycyjną bramą może mieć inne wymagania niż rozmowa aplikacja–aplikacja. Na zużycie danych wpływa nie tylko bitrate kodeka, lecz także nagłówki, częstotliwość pakietów, mechanizmy bezpieczeństwa i ruch sterujący. Najlepszy punkt wyjścia to kolejność kodeków podana przez dostawcę, a nie włączenie wszystkich albo wymuszenie modnego formatu.

Jak bezpiecznie porównać kodeki

Najpierw wykonaj próbę na ustawieniu domyślnym i zapisz wynegocjowany kodek, jeśli aplikacja go pokazuje. Zmień tylko priorytet wskazany w dokumentacji, powtórz tego samego rozmówcę i sieć, a potem porównaj jakość oraz stabilność. Brak połączenia po zmianie jest wynikiem testu, nie zachętą do manipulowania dalszymi parametrami bez punktu odniesienia.

ICE, STUN i TURN pomagają przejść przez NAT

Smartfon zwykle działa za translacją adresów. ICE opisuje procedurę zebrania możliwych adresów transportowych i sprawdzenia par, które faktycznie mogą przenosić dane. Korzysta przy tym ze STUN oraz może użyć adresu przekazywanego przez serwer TURN. TURN jest drogą pośrednią, gdy bezpośrednia ścieżka nie działa; nie jest „akceleratorem”, który należy dodać do każdego konta.

Te mechanizmy muszą być wspierane i skonfigurowane przez aplikację oraz usługę. Przypadkowy publiczny serwer może ujawnić metadane, zawieść lub nie być uprawniony do obsługi twojego ruchu. Podobnie ręczne przekierowanie szerokiego zakresu portów na routerze zwiększa powierzchnię ekspozycji i nie jest uniwersalnym lekarstwem na jednostronny dźwięk.

Diagnozuj od warstwy najbliższej objawowi

Gdy konto nie rejestruje się, porównaj dane, transport, czas urządzenia i komunikat z dokumentacją. Gdy wywołanie nie wychodzi mimo rejestracji, sprawdź format numeru i uprawnienia konta. Gdy rozmowa jest zestawiona bez mediów, zapisz kierunek, sieć, kodek i trasę audio. Gdy problem występuje tylko w tle, zbadaj powiadomienia oraz integrację systemową zamiast zmieniać RTP.

Do dostawcy przekaż minimalny, zamaskowany raport. Nie udostępniaj hasła, tokenu rejestracji, całego pliku konfiguracyjnego ani pełnego przechwycenia ruchu publicznie. Jeśli pomoc wymaga diagnostyki zaawansowanej, ustal zaufany kanał, zakres danych i sposób ich usunięcia po sprawie.

Najważniejsza lekcja jest prosta: SIP mówi o sesji, RTP o mediach, kodek o reprezentacji głosu, a TLS i SRTP o ochronie różnych warstw. Kiedy oddzielisz te role, mniej ustawień trzeba dotykać, a zgłoszenie problemu staje się krótsze i dokładniejsze.

Wróć do konfiguracji VoIP na smartfonie.

Źródła:

• IETF RFC 3261, SIP.
• IETF RFC 3550, RTP.
• IETF RFC 3551, profil RTP i formaty PCMA/PCMU.
• IETF RFC 3711, SRTP.
• IETF RFC 8445, ICE.
• IETF RFC 7587, Opus w RTP.
• IETF RFC 8996, wycofanie TLS 1.0 i 1.1.