Protokół SIP (Session Initiation Protocol) – co to jest i jak działa w VoIP?

Protokół SIP (Session Initiation Protocol) to tekstowy standard komunikacyjny służący do nawiązywania, modyfikowania i kończenia sesji multimedialnych pomiędzy wieloma użytkownikami. W technologii VoIP działa on jako cyfrowy operator centrali, który lokalizuje rozmówcę w sieci, ustala parametry połączenia, a następnie przekazuje zarządzanie strumieniem głosu do innych protokołów.

To absolutna podstawa nowoczesnej telekomunikacji. Reszta to detale techniczne, które musisz pojąć, żeby sprzęt w ogóle zadziałał. Odrzuciliśmy stare kable miedziane dawno temu. Teraz wszystko to pakiety danych przesyłane przez internet. I tutaj pojawia się problem. Zestawienie połączenia głosowego w rozproszonej sieci komputerowej wymaga precyzyjnego dyrygenta. SIP robi dokładnie to. Wysyła komendy, czeka na odpowiedź serwera, a potem usuwa się w cień.

Protokół SIP (Session Initiation Protocol) – co to jest i jak działa w VoIP od strony technicznej?

Architektura tego rozwiązania opiera się na modelu żądanie-odpowiedź. Bardzo przypomina to zwykły ruch na stronach WWW obsługiwany przez HTTP. Masz urządzenie końcowe, czyli telefon IP lub aplikację na komputerze. Nazywamy to User Agent (UA). Kiedy podnosisz słuchawkę i wybierasz numer, twój sprzęt wysyła wiadomość SIP INVITE. To zwykły tekst. Możesz go przeczytać w analizatorze ruchu sieciowego bez żadnego dekodowania. To prosta wymiana wiadomości.

Zestawienie sesji to proces trójetapowy. Telefon wysyła INVITE. Serwer odpowiada kodem 200 OK. Ty odsyłasz ACK. Połączenie nawiązane.

Prawda jest zresztą absolutnie taka, że SIP w ogóle nie dotyka twojego głosu. Zaskakujące? Dla wielu początkujących administratorów tak. Ten protokół nie przenosi ani jednego ułamka sekundy dźwięku. On tylko ustala, kto z kim rozmawia, na jakim adresie IP i na jakim porcie sprzęt będzie nasłuchiwał. Resztę roboty przejmują inne mechanizmy.

Kto odpowiada za przesyłanie głosu, jeśli SIP tylko zestawia połączenie?

Odpowiedź brzmi: protokół RTP (Real-Time Transport Protocol). SIP to wyłącznie negocjator. Zgadza się z drugą stroną co do tego, gdzie wysyłać dźwięk. Potem RTP bierze na siebie cały ciężar transportu próbek audio przez sieć. Używa do tego protokołu UDP. W rozmowie na żywo nie mamy czasu na retransmisję zgubionych pakietów. Stracisz sylabę? Trudno. Rozmowa toczy się dalej bez przerw na buforowanie.

Równolegle działa jeszcze SDP (Session Description Protocol). To on jest zaszyty w treści wiadomości SIP. SDP mówi drugiej stronie: „Mam kodeki G.711 i G.729, potrafię przyjąć wideo w H.264 na porcie 10000”. Jeśli druga strona to akceptuje, wysyła swoją odpowiedź SDP. Wtedy strumień RTP rusza z miejsca.

Jakie funkcje pełni serwer SIP proxy i dlaczego go potrzebujemy?

W małej sieci biurowej dwa telefony mogą dzwonić do siebie bezpośrednio po adresach IP. Wystarczy wpisać 192.168.1.10 na klawiaturze. Ale w prawdziwym biznesie to nierealne rozwiązanie. Ludzie zmieniają biurka, telefony dostają adresy z DHCP, a pracownicy zdalni logują się z domowych routerów. Potrzebujemy centralnego punktu zarządzania. Tym punktem jest serwer SIP proxy.

Proxy działa jak router pocztowy. Odbiera twoje żądanie INVITE skierowane do „[email protected]” i sprawdza w swojej bazie, pod jakim obecnym adresem IP ukrywa się telefon Jana. Następnie przekazuje to żądanie dalej. Proxy nie generuje własnych żądań. Ono tylko pośredniczy. Zmieniliśmy te zasady na robocie w zeszłym roku, wymuszając ruch przez dwa niezależne proxy dla zachowania ciągłości działania.

Czy rejestrator SIP jest tym samym co proxy?

Technicznie to dwa różne komponenty, choć w centralach PBX (np. Asterisk czy 3CX) są zamknięte w jednym oprogramowaniu. Rejestrator (Registrar Server) zajmuje się wyłącznie przyjmowaniem wiadomości REGISTER od telefonów. Kiedy rano włączasz telefon IP na biurku, wysyła on informację: „Cześć, jestem [email protected] i dzisiaj mój adres to 10.0.0.52”. Rejestrator zapisuje to w bazie lokalizacji.

Zrobiliśmy na wdrożeniu centrali PBX w małym zakładzie produkcyjnym pod Radomiem spory błąd. Producent twierdził, że ich telefony same przejdą przez NAT. Oczywiście sprzęt zawiesił się na pierwszej próbie rejestracji, więc wprowadzono poprawkę na routerze brzegowym przed poniedziałkiem. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Takie problemy z maskowaniem adresów IP to codzienność.

Dlaczego wdrożenie SIP trunkingu opłaca się firmom bardziej niż stare linie ISDN?

ISDN to przeżytek. Kosztowny, sztywny i fizycznie uwiązany do lokalizacji. SIP trunking to wirtualna rura podłączona do twojego operatora telekomunikacyjnego przez zwykłe łącze internetowe. Pozwala przesyłać dziesiątki jednoczesnych połączeń bez kładzenia nowych kabli w budynku.

Koszty spadają radykalnie. Płacisz za przepustowość i zużyte minuty, a nie za fizyczne porty na centrali. Potrzebujesz nagle dodać dziesięć nowych kanałów głosowych dla call center? W ISDN musiałbyś czekać na technika i montaż nowych kart rozszerzeń. W SIP trunkingu dzwonisz do operatora, on zmienia parametr w swoim systemie i po pięciu minutach masz to, czego chciałeś.

Wymaga to jednak solidnego łącza. Głos nie toleruje opóźnień. Jeśli jitter (zmienność opóźnień) skacze powyżej 30 milisekund, ludzie zaczną słyszeć metaliczny pogłos i cięcia.

Jakie problemy z NAT i zaporami sieciowymi psują wdrożenia VoIP?

To jest bez mała najgorsza opcja z wszystkich. Protokół SIP ma jedną, bardzo specyficzną cechę, która sprawia ogromne problemy przy zaporach sieciowych (Firewall) i translacji adresów (NAT). SIP umieszcza adresy IP wewnątrz samej wiadomości tekstowej (w nagłówkach Contact i w ciele SDP), a nie tylko w nagłówku pakietu IP.

Twój domowy router zmienia adres źródłowy pakietu IP na publiczny. Ale nie zagląda do środka wiadomości SIP. W efekcie serwer operatora dostaje żądanie, w którym telefon twierdzi, że jego adres to 192.168.1.15. Serwer próbuje odesłać dźwięk na ten prywatny adres, co oczywiście trafia w próżnię w internecie. Słyszysz ciszę w słuchawce.

• Rozwiązaniem jest użycie serwerów STUN (Session Traversal Utilities for NAT). Telefon pyta serwer STUN o swój publiczny adres IP, zanim wygeneruje wiadomość SIP. Wtedy wkleja poprawny adres do nagłówków, maskując swój lokalny adres przed operatorem. To działa w bez mała prawie osiemdziesiąt procent przypadków w prostych sieciach domowych.
• W trudniejszych sytuacjach, przy symetrycznym NAT, wdraża się serwery TURN, które fizycznie przekazują cały ruch audio przez siebie.
• Możesz też włączyć SIP ALG.
• Wyłączenie SIP ALG na routerze brzegowym to często pierwszy krok u weteranów IT. Producenci tanich routerów implementują tę funkcję tak fatalnie, że zamiast pomagać, ucina ona nagłówki SIP i całkowicie niszczy pakiety, uniemożliwiając rejestrację urządzeń.

Kodeki dźwięku a SIP – jak negocjowane są parametry sesji (SDP)?

Wybór odpowiedniego kodeka decyduje o tym, ile pasma zużyje jedna rozmowa i jaka będzie jej jakość. Kodek to algorytm kompresujący próbki głosu do postaci cyfrowej. G.711 to standard nieskompresowany. Daje jakość zwykłego telefonu stacjonarnego, ale pochłania około 80 kbps pasma w obie strony. W sieciach lokalnych to żaden problem.

Kiedy pracujesz na łączu mobilnym, wkracza G.729. Ten kodek ściska dźwięk do 8 kbps. Brzmi trochę jak z krótkofalówki, ale oszczędza pasmo. Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Okazało się, że operator wymuszał transkodowanie G.722 (HD Voice) na G.729, co pożerało zasoby procesora na centrali PBX.

Proces negocjacji w SDP jest prosty. Telefon A wysyła listę: „Chcę G.722, G.711 albo G.729”. Telefon B patrzy na to i odpowiada: „Mam tylko G.711 i G.729, więc wybieram G.711, bo jest wyżej na twojej liście”. Koniec negocjacji.

SIP a bezpieczeństwo – jak chronić telefonię IP przed atakami hakerów?

Domyślnie SIP jest całkowicie czystym tekstem. Każdy, kto wepnie się w twoją sieć z programem Wireshark, może przeczytać, do kogo dzwonisz, wyciągnąć hashe autoryzacyjne, a nawet złożyć pakiety RTP z powrotem w plik WAV i podsłuchać całą rozmowę. Widziałem to na własne oczy u wielu klientów, którzy myśleli, że telefonia IP nie wymaga szyfrowania.

Zabezpieczenie wymaga dwóch kroków. Po pierwsze, musisz włączyć TLS (Transport Layer Security) dla sygnalizacji SIP. To szyfruje same wiadomości tekstowe. Zamiast portu 5060 UDP używasz portu 5061 TCP z certyfikatami. Nikt nie podejrzy, z kim się łączysz.

Po drugie, musisz wdrożyć SRTP (Secure RTP) dla strumienia audio. SRTP szyfruje same próbki głosu za pomocą kluczy AES wymieniających się podczas negocjacji zabezpieczonej przez TLS. Nawet jeśli haker przechwyci ruch, usłyszy tylko cyfrowy szum.

Nie wystawiaj też nigdy portu 5060 bezpośrednio na świat bez ochrony. Skanery sieciowe uderzają w publiczne adresy IP tysiące razy na minutę, próbując odgadnąć hasła do kont SIP (tzw. SIP Vicious attacks). Wystarczy słabe hasło na jednym z aparatów, a w weekend ktoś wydzwoni z twojego konta połączenia na Kubę lub do Somalii za kilkadziesiąt tysięcy złotych. Używamy list kontroli dostępu (ACL) by wpuszczać ruch tylko od konkretnych adresów IP operatora.

Konfiguracja telefonów IP – dlaczego sprzęt czasami odrzuca pakiety SIP?

Największym wrogiem protokołu opartego na UDP jest fragmentacja pakietów. Wiadomość SIP potrafi spuchnąć. Dodajesz nagłówki autoryzacyjne, skomplikowane drzewo kodeków wideo i audio w SDP, a nagle całe żądanie przekracza 1500 bajtów (standardowe MTU w sieciach Ethernet). UDP nie radzi sobie z dużą fragmentacją. Pakiety docierają w złej kolejności lub gubią się po drodze, a firewall odrzuca je jako uszkodzone.

Zmieniliśmy te zasady na robocie, przechodząc w całości na TCP dla protokołu SIP. TCP gwarantuje dostarczenie danych i samodzielnie składa pofragmentowane ramki w całość przed przekazaniem ich do aplikacji. To rozwiązuje większość problemów z rejestracją zaawansowanych wideotelefonów i systemów Unified Communications na zewnątrz sieci biurowej.

Kody odpowiedzi SIP są niemal identyczne z kodami HTTP. Jeśli dostajesz błąd 404 Not Found, oznacza to, że wybrałeś nieistniejący numer w centrali. Błąd 401 Unauthorized wymusza podanie hasła. Błąd 486 Busy Here to po prostu sygnał zajętości, bo rozmówca prowadzi inną konwersację. Kody z serii 5xx oznaczają awarię samego serwera proxy.

Zrozumienie działania protokołu SIP uwalnia od zgadywania przy rozwiązywaniu awarii. Wrzucasz ruch w analizator, filtrujesz po porcie 5060 i widzisz czarno na białym, gdzie urywa się komunikacja. To twarda inżynieria bez miejsca na domysły.

Twoje zadanie na dziś to pobranie darmowego oprogramowania Wireshark. Zainstaluj je na komputerze z uruchomionym softphonem. Złap paczki z ruchem, przefiltruj wpisując „sip” w pasku wyszukiwania, zadzwoń na swój telefon komórkowy i przeanalizuj nagłówki INVITE oraz SDP. Dopiero kiedy zobaczysz surowy tekst przelatujący przez kartę sieciową, zrozumiesz, kto naprawdę kontroluje twoje pakiety danych w firmie.

Najczęściej zadawane pytania (FAQ)

• Co to jest protokół SIP?
  Protokół SIP (Session Initiation Protocol) to tekstowy standard sieciowy służący do nawiązywania, modyfikowania i kończenia sesji komunikacyjnych, takich jak połączenia głosowe i wideo w technologii VoIP.
• Czy SIP przesyła głos w rozmowie telefonicznej?
  Nie. Protokół SIP odpowiada wyłącznie za zestawienie połączenia i negocjację parametrów. Przesyłaniem samego dźwięku zajmuje się protokół RTP (Real-Time Transport Protocol).
• Jakie porty sieciowe wykorzystuje protokół SIP?
  Domyślnie SIP używa portu 5060 dla nieszyfrowanego ruchu (UDP lub TCP) oraz portu 5061 dla ruchu szyfrowanego za pomocą TLS.
• Co to jest SIP Trunking?
  SIP Trunking to wirtualne połączenie między firmową centralą telefoniczną (PBX) a operatorem telekomunikacyjnym, pozwalające na realizację wielu jednoczesnych połączeń przez standardowe łącze internetowe.
• Dlaczego telefon VoIP nie dzwoni za routerem z NAT?
  NAT zmienia adres IP nagłówka pakietu, ale nie modyfikuje wewnętrznych nagłówków wiadomości SIP. Przez to serwer próbuje odesłać ruch na prywatny adres IP, co powoduje brak dźwięku lub problemy z rejestracją. Rozwiązaniem jest użycie serwerów STUN/TURN.
• Jak zaszyfrować połączenia SIP?
  Aby zabezpieczyć połączenia, należy wdrożyć protokół TLS do szyfrowania samej sygnalizacji SIP oraz protokół SRTP, który szyfruje bezpośrednio przesyłane próbki głosu.

Bibliografia

1. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
2. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Internet Engineering Task Force – https://ietf.org