SIP, RTP i SBC — mapa jednego połączenia w wirtualnej centrali
Telefon może się zarejestrować, a głos nadal nie działać. Rozdziel sygnalizację od mediów i sprawdź każdy punkt drogi połączenia.
Najczęstszy błąd na diagramie telefonii IP polega na narysowaniu jednej strzałki od telefonu do „chmury”. Taki obraz nie wyjaśnia, gdzie urządzenie się rejestruje, kto podejmuje decyzję o trasie, jak uzgadniany jest kodek ani którędy faktycznie płynie głos. Gdy wystąpi jednostronny dźwięk lub zerwanie po określonym czasie, jedna strzałka nie daje punktu zaczepienia.
Prawidłowa mapa oddziela co najmniej sygnalizację, opis sesji i media. Dodaje też granice sieci, elementy pośrednie, system administracyjny oraz styk z publiczną siecią telefoniczną.
Rejestracja mówi, gdzie znaleźć urządzenie
Klient SIP może wysłać żądanie rejestracji do usługi, aby powiązać tożsamość użytkownika z aktualnym miejscem kontaktu. Udana rejestracja potwierdza, że część sygnalizacyjna działa: nazwa, uwierzytelnienie, DNS, transport i droga do serwera pozwoliły wykonać tę operację. Nie potwierdza natomiast, że każde połączenie zostanie poprawnie zestawione ani że media przejdą w obu kierunkach.
Na diagramie zaznacz urządzenie, serwer rejestracji, używany transport, brzeg zapory i miejsce zakończenia TLS. Jeśli telefon otrzymuje konfigurację automatycznie, narysuj osobny serwer provisioningu. Dostęp do niego może ujawniać poświadczenia, książkę adresową i ustawienia urządzenia, dlatego zasługuje na własne zabezpieczenia oraz logi.
SIP steruje sesją, SDP opisuje media
RFC 3261 definiuje SIP jako protokół sterujący, który może zestawiać, modyfikować i kończyć sesje. Przy typowym połączeniu żądanie INVITE rozpoczyna negocjację, odpowiedzi informują o stanie, a BYE kończy istniejącą sesję. Szczegóły konkretnego przebiegu zależą od architektury i usług pośrednich.
Wiadomości mogą nieść opis sesji SDP: adresy, porty, kodeki i parametry ochrony mediów. To nadal nie jest głos. Jeśli urządzenie ogłosi adres prywatny, którego druga strona nie może osiągnąć, rozmowa może zostać zestawiona bez prawidłowego dźwięku. Manipulowanie nagłówkami bez zrozumienia SDP często tylko przenosi problem.
RTP niesie dźwięk, RTCP opisuje odbiór
RTP jest przeznaczony do danych czasu rzeczywistego. Numery sekwencyjne i znaczniki czasu pomagają odbiorcy odtworzyć kolejność oraz tempo strumienia. Towarzyszący protokół sterujący RTCP przekazuje raporty o odbiorze. RFC 3550 definiuje między innymi skumulowaną utratę, odsetek utraconych pakietów w okresie oraz estymację jittera.
Rozszerzenia RTCP XR mogą dostarczać dodatkowe dane o pakietach utraconych i odrzuconych, okresach pogorszenia, opóźnieniu i działaniu bufora. To ważne rozróżnienie: pakiet może dotrzeć do urządzenia, ale zbyt późno, by dało się go odtworzyć. Wówczas problem nie zawsze wygląda jak strata widziana na łączu.
SRTP chroni media mechanizmami poufności, uwierzytelnienia i ochrony przed powtórzeniem, lecz wymaga właściwego zarządzania kluczami. RFC 8862 opisuje dobre praktyki dla bezpiecznych mediów zestawianych przez SIP. W projekcie trzeba wskazać każdy odcinek, na którym ochrona działa, oraz każde miejsce terminacji.
NAT wymaga kontrolowanego przejścia
NAT tłumaczy adresy i porty, więc informacja widziana lokalnie nie musi odpowiadać drodze osiągalnej z internetu. STUN pomaga klientowi poznać mapowanie utworzone przez NAT. ICE zbiera kandydatów, sprawdza ich łączność i wybiera parę zdolną przenosić media. Jeżeli bezpośrednia ścieżka nie działa, TURN może przekazać ruch przez serwer pośredni.
Te mechanizmy nie są zamiennymi nazwami jednej funkcji. STUN nie jest przekaźnikiem mediów, TURN nim jest, a ICE koordynuje wybór drogi. Nie każdy telefon SIP implementuje ICE tak jak klient WebRTC, dlatego zachowanie trzeba potwierdzić w dokumentacji używanego systemu.
SBC stoi na granicy, ale ma określoną rolę
Session Border Controller może egzekwować politykę sygnalizacji, normalizować różnice między domenami, ograniczać niepożądany ruch, ukrywać topologię i pośredniczyć w mediach. Może też zmieniać nagłówki, adresy SDP albo wykonywać transkodowanie. Każda z tych funkcji wpływa na diagnostykę, wydajność i granicę zaufania.
Zapytaj, czy SBC jest tylko sygnalizacyjny, czy kotwiczy wszystkie media. Ustal, gdzie kończą się TLS i SRTP, kto aktualizuje reguły, jak działa nadmiarowość oraz które logi są dostępne. Sam fakt obecności SBC nie potwierdza odporności na ataki ani awarie.
Jak narysować przepływ krok po kroku
Zacznij od urządzenia dzwoniącego. Narysuj kolejno DNS, sieć dostępową, zaporę, serwer SIP lub SBC, centralę, styk operatorski i urządzenie odbierające. Dla każdej relacji użyj dwóch osobnych linii: sygnalizacja oraz media. Dodaj protokół, transport, uwierzytelnienie, szyfrowanie i właściciela elementu.
Następnie przygotuj trzy warianty: połączenie wewnętrzne, wychodzące do sieci publicznej oraz rozmowę pracownika zdalnego. Sprawdź, które elementy zmieniają się między wariantami. Dodaj przepływ nagrania i metadanych do magazynu danych. Na końcu oznacz miejsca, z których można uzyskać logi oraz metryki.
Diagnostyka według warstw
Brak rejestracji badaj od DNS i łączności przez certyfikat oraz uwierzytelnienie do odpowiedzi SIP. Brak zestawienia połączenia analizuj na trasie żądania i odpowiedzi, regułach centrali oraz styku operatorskim. Jednostronny dźwięk kieruje uwagę na SDP, NAT, zaporę i drogę RTP. Pogorszona jakość wymaga metryk w obu kierunkach, danych o kolejce łącza i informacji z punktów końcowych.
Taki podział nie rozwiązuje problemu automatycznie, ale pozwala zbierać dowody w miejscu, w którym usterka faktycznie powstaje.
Źródła
Działanie SIP, RTP i ochrony mediów opisano za dokumentami wymienionymi w tekście: RFC 3261, RFC 3550 i RFC 8862. Tekst wyjaśnia zasadę działania, a nie ustawienia konkretnej centrali.