PROTOKÓŁ SIP WILCZAK KRZYSZTOF KOPKA PIOTR

INFORMACJE WSTĘPNE SIP (Sesion Initiation Protocol) to protokół sygnalizacyjny, odpowiedzialny za tworzenie, zamykanie i modyfikację sesji multimedialnych pomiędzy jednym lub wieloma klientami przez sieć Internet.

INFORMACJE WSTĘPNE c.d. SIP jest tekstowym protokołem warstwy aplikacji niezależnym od topologii sieci. Stanowi rozwiązanie alternatywne w stosunku do H.323 Jego podstawową specyfikację można znaleźć w standardzie: - RFC 3216: SIP: Session Initiation Protocol Dostępnym na stronie:

Standardowy model odniesienia SIP obejmuje poziomy: Syntaktyki i kodowania – najniższa warstwa Transportu – definicja mechanizmów generacji i przekazywania żądań i odpowiedzi Transakcji – realizacja procesów wymiany i przetwarzania, począwszy od generacji żądania, aż do uzyskania odpowiedzi

Architektura sieciowa Składniki SIP: Aplikacje agentów (user agents) Serwery pośredniczące (proxy servers) Serwery przekierowania (redirect servers) Serwery rejestrujące (registar servers) Serwery lokalizacji (location servers) Serwery aplikacji (aplication servers)

Architektura sieciowa c.d. UA (User Agent). Aby można było przesyłać przez sieć z protokołem SIP głos w pakietach, taka sieć musi się składać z co najmniej dwóch połączonych ze sobą węzłów: agenta użytkownika UA, nazywanego też terminalem, oraz serwerów sieciowych przeznaczonych do różnych zadań. UAC (User Agent Client), UAS (User Agent Server) Agent użytkownika jest elementem pośredniczącym między użytkownikiem a siecią. Prowadzi komunikację dwukierunkowo między pozostałymi jednostkami SIP. Składa się z dwóch części: klienta UAC oraz serwera UAS. Każdy terminal sieci SIP jest węzłem typu host IP. Dzięki temu użytkownik może inicjować sesję – wysyłać żądania protokołu SIP, odbierać takie żądania od innych agentów oraz wysyłać do nich odpowiedzi.

Architektura sieciowa c.d. Proxy Serwers (SP). Serwery pośredniczące – żądania wysyłane od UAC są przyjmowane przez serwer pośredniczący, który jeśli nie jest w stanie obsłużyć żądania, przekazuje je następnemu serwerowi, aż żądanie dotrze do właściwego serwera Redirect Servers (SRed). Serwery przekierowujące – po odebraniu żądania zwracają do UAC adres kolejnego serwera, z którym powinien się on skontaktować. Location Servers (SL). Serwery lokalizacji – gromadzą informację o aktualnym położeniu UA, z której następnie korzystają serwery proxy lub redirect. Registar Servers (SR). Serwery rejestrowe – służą do zarejestrowania adresu zgłaszającego się w tym celu agenta użytkownika UA. Aplication Servers (SA). Serwery aplikacji – realizują funkcje związane ze świadczonymi usługami, np. serwer poczty głosowej.

Typowe konfiguracje elementów sieciowych[1] (1) Schemat bezpośredni – aplikacje agenta przygotowują się do ustanowienia sesji bez pośrednictwa serwerów proxy Schemat wykorzystywany również w: IPoCATV, LAN IPoE SP Internet CATV (Ethernet) SIP UA LAN (Ethernet)

Typowe konfiguracje elementów sieciowych[1] (2) Media LAN UAC UAS Internet DNSSR SP 1SP 2 Połączenie z udziałem serwerów proxy trapezoidalne

Registration Każdy użytkownik zamierzający ustanowić sesję musi się zarejestrować aby być widocznym dla pozostałych użytkowników. Proces rejestracji odbywa się zwykle za pośrednictwem pewnych elementów sieciowych, takich jak: serwery proxy (SP) przesyłających żądania i odpowiedzi na wskazane adresy, serwery lokalizacji (SL) tworzących powiązania adresowe pomiędzy domenami.

Rejestracja bezpośrednia Rejestracja składa się z wiadomości REGISTAR (F1) wysyłanej przez użytkownika do specjalnego serwera zwanego serwerem rejestracji w celu wskazania swojego aktualnego adresu kontaktowego. Informacja ta zostaje zapisana w bazie danych serwera lokalizacyjnego (SL) (F2). Zaproszenie do nawiązania sesji kierowane jest do serwera proxy (F3) a stamtąd do SL (F4). Odpowiedź (F5) dostarcza aktualny adres strony wywoływanej. Proxy informuje adresata o przychodzącej sesji (F6).

Rejestracja bezpośrednia[1] UA Users phone SRed chicago.com REGISTER F1 Store F2 SL SP sip.chicago.com Query F4 Resp F5 INVITE F3 INVITE F6 UA Users phone

Brak odpowiedzi Wiadomość REGISTER po sfinalizowaniu jest przesyłana do warstwy transakcyjnej. Jeśli w ustalonym czasie żądanie pozostanie bez odpowiedzi, warstwa transakcyjna zwraca błąd (timeout error ) Agent UAC nie powinien ponawiać natychmiast żądania REGISTER, ale odczekać pewien racjonalny interwał czasowy na ustabilizowanie się sytuacji. Po tym czasie może ponowić żądanie. Pozwoli to zredukować obciążenie zasobów systemu. Specyfikacja SIP nie określa wartości tego parametru.

Ponawianie rejestracji Jeśli UAC otrzyma odpowiedź 423 (Interval Too Brief), może spróbować ponowić żądanie rejestracji po odczekaniu czasu expiration interval wszystkich adresów kontaktowych zawartych w żądaniu REGISTER, dla których czas ten jest równy lub większy od minimalnego czasu expiration interval w polu nagłówkowym Min-Expires wiadomości 423 (Interval Too Brief).

Uwierzytelnianie użytkownika Podstawowy scenariusz zapobiegania atakom na system z protokołem SIP polega na uwierzytelnianiu użytkownika. Po każdym odebraniu żądania serwer proxy lub aplikacja UA może zażądać od użytkownika poświadczenia jego autentyczności. Procedura ta jest określana mianem Digest. Mechanizm Digest jest prostym rozwiązaniem problemu sprawdzenia czy obydwie strony posiadają to samo hasło. Ponieważ wiadomość REGISTER informuje serwer o bieżącej lokalizacji, niepowołany użytkownik mógłby użyć jej w celu przejęcia wywołań. Dlatego serwer rejestrujący zawsze dokonać weryfikacji strony inicjującej transakcję.

Uwierzytelnianie użytkownika UAC SR REGISTER (bez uwierzytelnienia) 407 (Proxy Authentication Required) REGISTER (z uwierzytelnieniem) 200 OK

INVITATION Gdy UAC zamierza nawiązać sesję formułuję żądanie INVITE, które jest wysyłane za pośrednictwem serwerów proxy do jednego lub wielu użytkowników. Agenci UAS tych użytkowników mogą odpowiedzieć na żądanie INVITE pozytywnie (odpowiedzi 2xx) lub je odrzucić. Żądanie może również zostać nie zaakceptowane z innych względów nie zależnych od użytkowników (odpowiedzi 3xx, 4xx, 5xx lub 6xx). Przed podjęciem finalnej decyzji UAS może też wysłać odpowiedzi etapowe (1xx) informujące UAC o postępach w nawiązywaniu połączenia. Wiadomość INVITE może zawierać informacje o parametrach nawiązywanej sesji np. w przypadku rozmowy telefonicznej informacje o użytym kodeku. Opis ten zwany jest ofertą (offer). UAS wysyła wtedy swoją ofertę zwaną odpowiedzią (answer) z opisem, na które parametry się zgadza. Model komunikacji, w którym używa się ofert i odpowiedzi nazywa się modelem oferta-odpowiedź (offer/answer model).

Połączenie z jednym serwerm proxy Nawiązanie sesji przez dwóch użytkowników jest możliwe dzięki wiadomości INVITE, którą użytkownik pragnący rozpocząć sesję wysyła zwykle do serwera proxy (F1) Serwer proxy pośredniczy przy przekazywaniu wiadomości między terminalami użytkowników. Po otrzymaniu żądania INVITE (F2) terminal rozpoczyna alarmowanie abonenta. Podjęcie wywołania oznacza generację odpowiedzi 200 OK (F3, F4), która dociera do strony wywołującej. Wymianę kończy potwierdzenie ACK (F5, F6)

Połączenie z jednym serwerm proxy c.d SP caller callee ringing ACK F6 INVITE F2 200 Ok F3 INVITE F1 200 Ok F4 ACK F5

Brak odpowiedzi Po wysłaniu wiadomości INVITE UAC czeka na odpowiedź potwierdzającą. Jeśli po przekroczeniu czasu timeout nie otrzyma pozytywnej odpowiedzi, otrzymuje komunikat błędu warstwy transakcji, na który reaguje jak na odpowiedź 408 (Request Timeout)

Brak odpowiedzi c.d SP caller callee ringingINVITE F1INVITE F2 408 Request Timeout F3

Przekierowywanie połączenia do poczty głosowej Po wysłaniu wiadomości INVITE UAC czeka na odpowiedź potwierdzającą. Najpierw otrzymuje wiadomość 100 Trying, następnie 180 Ringing. Po ustalonym czasie strona odbiorcza wysyła wiadomość 302 Moved Temporarily i agent UAC nadawcy wysyła wiadomość INVITE do serwera z pocztą głosową. Następnie dochodzi do zwykłego połączenia.

Przekierowywanie połączenia do poczty głosowej[2] c.d SP caller callee ACK F13 INVITE F2 Trying F3 INVITE F1 Trying F4 ACK F8 Ringing F6 Ringing F5 Moved Temporarily F7 voic serwer INVITE F9INVITE F Ok F11200 Ok F12 ACK F13

Wyczerpanie terminu ważności INVITE UAC może umieścić w polu Expires w nagłówku wiadomości INVITE. Pole to określa czas przez jaki zaproszenie będzie ważne. Jeśli po tym czasie nie otrzyma żadnej finalnej odpowiedzi UAC generuje żądnaie CANCEL anulujące poprzednie żadanie INVITE. UAS odbierając wiadomość INVITE z polem Expires ustawia timer na wartość tego pola. Jeśli czas wyczerpie się zanim UAS wygeneruje finalną odpowiedź zostaje wysłana odpowiedź 487 (Request Terminated)

Przekierowanie połączenia UAS może zdecydować się przekierować rozmowę, wysyła wówczas jedną z odpowiedzi 3xx. 300 (Multiple Choices) 301 (Moved Permanently) 302 (Moved Temporarily) Odpowiedzi te powinny zawierać nagłówek Contact z nowymi adresami URI, na które została przekierowana rozmowa. Są one kierowane do serwera transakcji, który będzie ponawiał retransmisję na wskazane adresy.

Przekierowanie połączenia c.d W fazie wstępnej nadawca wywołuje usługę DNS (F1, F2) w celu uzyskania numeru IP adresata. SP w odpowiedzi na żądanie INVITE (F3) dostarcza stronie inicjującej aktualny adres kontaktowy korespondenta (F6). Po zakończeniu współpracy z serwerem (F7) UAC może ponowić żądanie (F8) na nowy adres. Wiadomości F10 i F11 finalizują proces połączenia.

Przekierowanie połączenia[2] c.d SP UAC Caller UAS callee INVITE F1 200 Ok F4 ACK F5 INVITE F3 302 (Moved temporarily) F6 Contact: ACK F7 Tom F4 F5SL F1 F2 DNS

Odrzucenie połączenia Typowy sytuacja występuje gdy użytkownik nie może lub nie chce nawiązać sesji. Wtedy zostaje wysłany komunikat 486 (Busy Here). Jeśli UAS wie, że sesja nie może być nawiązana z żadnego innego terminala może zamiast tego wysłać wiadomość 600 (Busy Everywhere). Odpowiedzi 600 są jednak rzadko stosowane. Odpowiedź jest przesyłana dalej do serwera transakcji, który będzie ponawiał retransmisję. Aby tego uniknąć UAS odrzucając ofertę zawartą w INVITE powinien wysłać odpowiedź 488 (Not Acceptable Here) zawierającą informację wyjaśniającą czemu oferta została odrzucona.

Odrzucenie połączenia c.d SP caller callee ringing ACK F6 INVITE F2 488 (Not Acceptable Here) F3 INVITE F1 488 (Not Acceptable Here) F3 ACK F5

Niepoprawne żądanie Serwer zawsze sprawdza czy żądanie zawiera pole Contact w nagłówku. Jeśli nie, pomija wszystkie czynności i przechodzi do ostatniego kroku. W przeciwnym wypadku sprawdza czy wystąpiła tylko jedna wartość w polu Contact i czy zawiera specjalne wskazanie * i nagłowek Expires. Jeśli żądanie zawiera dodatkowe pola Contact lub termin ważności ma inną wartość niż 0, żądanie jest niepoprawne i serwer zgłasza błąd 400 (Invalid Request). Następnie sprawdzane jest pole Call-ID. Jeśli nie jest ono poprawne serwer usuwa wszystkie powiązania. Jeśli natomiast jest poprawne. Serwer usuwa powiązania tylko w przypadku gdy pole CSeq ma większą wartość niż wartość przechowywana dla tego powiązania.

Niepoprawne żądanie. UAC SR Request 400 (Invalid Request) Błąd odbioru Request

Sesja SIP z wykorzystaniem usługi lokalizacji Użytkownik inicjujący wysyła wiadomość INVITE (F1) skierowaną do użytkownika, z którym zamierza nawiązać sesję poprzez serwer proxy. Po wysłaniu potwierdzenia (F2) SP ustala adres serwera odpowiedzialnego za domenę strony wywoływanej. Korzysta w tym celu z usługi DNS (F3, F4). Dzięki temu wiadomość INVITE zostaje właściwie skierowana (F5, F6). Następnie zostaje wywołana usługa lokalizacji (F7, F8), której celem jest sprawdzenie osiągalności adresata i jego aktualnego adresu, po której następuje przekazanie docelowej aplikacji UAS żądania INVITE (9). W kolejnych krokach UAC jest informowany o wywołaniu (F10, F11, F12) i akceptacji (F13, F14, F15). Finalne potwierdzenie ACK (16)konczy proces ustanawiania sesji

Sesja SIP z wykorzystaniem usługi lokalizacji[2] c.d ACK F16 UAC UAS DNS SR SP 1 SP 2 F1 F2 F12 F15 F3F4F8F7 F5 F6 F11 F14 F9 F10 F13

Stos protokołów TCP/IP Warstwa aplikacji HTTP FTP SMTP Telnet DNS SNMP SIP Warstwa transportowa TCP UDP Warstwa internetowa IP ARP ICMP IGMP Warstwa interfejsu sieciowego

Źródło:

Współpraca z UDP i TCP Protokół SIP jest protokołem warstwy aplikacji. W warstwie transportowej używa on różnych protokołów m.in. TCP, UDP. Protokół UDP nie posiada gwarancji wysłania poprawnego wiadomości. Dlatego też protokół SIP posiada kilka elementów wbudowanych do współpracy z protokołem typu UDP.

Współpraca z UDP Wiadomości akceptujące połączenie 2xx jak też inne ostateczne odpowiedzi są okresowo retransmitowane przez UAS, ponieważ część drogi połączeniowej między UAC a UAS może byś realizowane przez protokół UDP. Scenariusz. Nadawcy wysyła wiadomość BYE. Odbiorcy wysyła wiadomość 200 ok. Ginie ona w sieci. Po jakimś czasie jest retransmitowana i trafia do nadawcy.

Rozłączenie używając UDP[2] SPcallee ringing 200 ok F4 BYE F2 200 ok F3 BYE F1 200 ok F5 caller UDP DATAGRAM Source Ip: Source Port: Destination IP: Destination Port:5060 UDP DATAGRAM Source Ip: Source Port: Destination IP: Destination Port:5060 UDP DATAGRAM Source Ip: Source Port: Destination IP: Destination Port:5060 UDP DATAGRAM Source Ip: Source Port: Destination IP: Destination Port:5060 UDP DATAGRAM Source Ip: Source Port: Destination IP: Destination Port:5060

Współpraca z TCP Protokół TCP jest protokołem gwarantującym dostarczenie wiadomości, ale powoduje dużo większe opóźnienia niż UDP. Protokół UDP może powodować jednak utratę części wiadomości lub zbytnie zagęszczenie ruchu w sieci, dlatego gdy wiadomości są duże (powyżej 1300 bajtów) to stosuje się protokół TCP.

Współpraca z TCP. Przekierowanie połączenia. Nadawca tworzy połączenie TCP. Następnie wysyła wiadomość INVITE (F1). UAS odbiorcy wysyła wiadomość 302 Moved Temporarily (F3). Nadawcy wysyła potwierdzenie ACK i zamyka połączenie TCP.

Współpraca z TCP. Prekierowanie połączenia[2] c.d SPcallercallee ringing ACK F6 INVITE F2 302 Moved F3 INVITE F1 ACK F5 Open TCP connection Source Ip: Source Port: Destination IP: Destination Port:5060 Source Ip: Source Port: Destination IP: Destination Port: Moved F4 Close TCP connection

Bibliografia [1] Marek Bromirski Telefonia VOiP Multimedialne sieci IP Wyd. BTC Warszawa 2006 [2] [3] Alan B. Johnston SIP : understanding the Session Initiation Protocol Artech House Warszawa 2004 [4] Internet Communications Using SIP Autorzy Henry Sinnreich, Alan B. Johnston