SIP jest najpopularniejszym protokołem w rozwiązaniach VoIP, a jego udział w rynku ciągle rośnie. Już teraz w swoich rozwiązaniach stosują go takie firmy, jak Cisco i Avaya, zaimplementował go także Microsoft. Dlatego zdecydowaliśmy się przybliżyć zasady jego działania.
Session Initiation Protocol jest protokołem opracowanym przez Internet Engineering Task Force (w odróżnieniu od H.323, który został opracowany przez International Telecommunications Union–Telecommunications Standard Sector). Służy do zestawiania sesji pomiędzy dwoma lub wieloma klientami. Wyróżnia się niewielkim narzutem, a jednocześnie w większości wypadków potrafi wykonać te same zadania, co bardzo rozbudowany H.323.
Architektura SIP bazuje na dwóch popularnych protokołach internetowych: SMTP oraz HTTP. Dodatkowo wykorzystuje funkcje zdefiniowane w protokołach Real Time Transport Protocol/Real Time Control Protocol (RTP/RTCP), które opisują format multimedialnych pakietów IP, oraz funkcje protokołu Session Description Protocol (SDP), które definiują parametry sesji multimedialnych.
SIP ma architekturę typu klient-serwer. Można wyróżnić dwa typy klientów:
- Klient agenta użytkownika (User Agent Client), który potrafi wysyłać żądania.
- Proxy, czyli urządzenie pośredniczące, które może działać jako klient i serwer, potrafiące przekazywać żądania do serwera.
Dokument RFC 3261 opisuje także kilka typów serwerów:
- User Agent Server, który generuje odpowiedzi na żądania SIP.
- Redirect Server, który przekazuje żądania klienta do innego serwera, który odpowie na żądanie.
- Registrar to serwer, który akceptuje żądania REGISTER i umieszcza później te informacje w usłudze lokalizacji.
Dzięki wykorzystaniu dobrze znanych protokołów (HTTP, SMTP) oraz architektury klient serwer, udało się stworzyć protokół o dużo mniejszym stopniu złożoności niż H.323. To właśnie prostota SIP jest uważana za największą zaletę tego protokołu.
SIP jest protokołem warstwy aplikacji, tzn. że dostarcza usługi użytkownikom końcowym. SIP wykorzystuje protokoły IP i UDP, dlatego może być postrzegany jako uzupełnienie pakietu protokołów internetowych opracowanych przez IETF.
Usługa, którą realizuje SIP, jest nazywana sesją. Można ją opisać jako uporządkowaną wymianę danych pomiędzy dwoma lub więcej urządzeniami. SIP musi najpierw utworzyć sesję, a następnie zarządzać nią tak długo, jak trwa komunikacja. Może się to wydać proste, ale pojawia się kilka komplikacji.
Pierwszą jest możliwość udziału w sesji więcej niż dwóch urządzeń końcowych, co oznacza że połączenie może mieć charakter wielopunktowy (konferencja). Po drugie, użytkownicy końcowi nie zawsze realizują połączenia z tej samej lokalizacji, co wymaga dodania funkcjonalności śledzenia użytkowników. Po trzecie, użytkownicy mogą korzystać z różnych mediów – tekstu, głosu, wideo, które mają różne wymagania co do przepustowości, opóźnień, itd.
Aby realizować usługę sesji, w dokumencie RFC 3261 opisano pięć aspektów zarządzania sesją SIP:
- Lokalizacja użytkownika: określenie, które urządzenie końcowe będzie wykorzystywane do komunikacji.
- Dostępność użytkownika: określenie, czy odbiorca rozmowy chce podjąć komunikację.
- Funkcjonalność użytkownika: wykrycie medium komunikacyjnego i jego parametrów, które będą wykorzystane podczas komunikacji.
- Konfiguracja sesji: uzgodnienie parametrów sesji pomiędzy uczestnikami połączenia.
- Zarządzanie sesją: obejmuje transfer i zakończenie sesji, modyfikowanie parametrów sesji oraz wywoływanie usług sesji.
Architektura klient-serwer
Jak już wspomnieliśmy, SIP wykorzystuje architekturę klient-serwer. Klient to element sieci, który wysyła żądania SIP i odbiera odpowiedzi. Natomiast serwer to element sieci, który odbiera żądania i wysyła odpowiedzi na nie.
Komunikacja SIP między klientem i serwerem, wzorowana na koncepcji żądań i odpowiedzi stosowanej w protokole HTTP, jest mocną stroną tego protokołu. W protokole HTTP klient wysyła żądanie zasobów sieciowych (np. strony WWW) do serwera, który odpowiada na te żądanie. W przypadku protokołu SIP klient (User Agent Client lub proxy) wysyła żądanie do serwera (User Agent Server, Redirect Server lub Registrar) przyznania zasobów komunikacyjnych lub modyfikacji już przydzielonych zasobów. Przykładowym żądaniem jest INVITE. Wskazuje ono, że wybrany użytkownik lub usługa jest zaproszona do sesji komunikacyjnej. Jeśli żądanie zawarte w wiadomości może być zrealizowane, serwer odeśle odpowiedź SUCCESS. Oczywiście, nie każde żadanie może być zrealizowane. Inne odpowiedzi mogą zawierać informacje o błędach lub warunkach niemożności realizacji żądania.
Formaty wiadomości
Żądania i odpowiedzi SIP są podobne do żądań i odpowiedzi HTTP. Żądanie SIP określa operacje wymagane przez klienta, natomiast odpowiedzi SIP informują klienta o statusie realizacji jego żądania.
Ponieważ w przypadku sesji SIP rezerwowanymi zasobami są zasoby sieciowe (a nie strony WWW, jak w przypadku protokołu HTTP), schemat identyfikacji czy adresacji tych zasobów musi być zdefiniowany zanim żądania i odpowiedzi SIP zostaną efektywnie zaimplementowane. Ten identyfikator jest znany jako SIP Uniform Resource Indicator (SIP URI) i zawiera informacje niezbędne do zainicjować sesji komunikacyjnej oraz zarządzania nią. Przykłady zasobów, które mogą potrzebować takiego identyfikatora, to: użytkownik usługi online, skrzynka pocztowa w systemie przesyłania wiadomości, logiczna grupa użytkowników (np. dział sprzedaży) czy numer telefonu w sieci Public Switched Telephone Network (PSTN), który wymaga komunikacji przez bramkę VoIP. SIP URI jest podobny do adresu e-mail (tym razem zapożyczenie z protokołu SMTP) i z reguły składa się z dwóch części: nazwy użytkownika i hosta, np. sip:rjanus@itfocus.com. Adresy SIP URI mogą przybierać też inne formy, o czym w dalszej części artykułu.
Przy tak rozumianym schemacie adresowania występuje sześć typów żądań, które różnią się między sobą tzw. metodą:
- REGISTER: to żądanie służy do zarejestrowania adresu w serwerze SIP.
- INVITE: wskazuje, że użytkownik lub usługa jest zaproszona do nawiązania sesji. Treść tej wiadomości zawiera opis sesji, do której uczestnik jest zapraszany.
- ACK: potwierdzenie, że klient odebrał finalną odpowiedź na żądanie INVITE. Ten komunikat jest używany tylko w powiązaniu z INVITE.
- CANCEL: wiadomość używana do anulowania wysłanego żądania.
- BYE: wysyłane przez klienta User Agent Client w celu zasygnalizowania serwerowi żądania zakończenia komunikacji.
- OPTIONS: wykorzystywane w celu odpytywania serwera o jego funkcjonalności.
Odpowiedzi na żądania zawierają Status Codes oraz Reason Phrases, które wskazują na aktualny status realizacji żądania. Wartości kodów statusu są podzielone na sześć kategorii:
- 1xx: Provisional – żądanie zostało odebrane i przekazane do dalszej realizacji.
- 2xx: Success – potwierdzenie ACK, wskazuje, że żądanie zostało przyjęte, prawidłowo odczytane i zaakceptowane.
- 3xx: Redirection – realizacja żądania wymaga dalszy działań.
- 4xx: Client Error – żądanie zawiera błędny składni i nie może być zrealizowane przez serwer.
- 5xx: Server Error – serwer nie był w stanie zrealizować prawidłowego żądania.
- 6xx: Global Failure – żądanie nie może być zrealizowane przez żaden serwer.
Szczegółowe informacje o formatach wiadomości SIP, kodach statusu i innych parametrach znajdziesz w dokumencie RFC 3261.
Sesja SIP może zawierać głos, wideo lub dane, dlatego konieczna jest standardowa metoda opisu inicjalizowanej sesji (z wykorzystaniem żądania INVITE). To zadanie jest realizowane przez Session Description Protocol (SDP), opisany w dokumencie RFC 2327.
Opis sesji SIP
Kolejnym elementem protokołu SIP jest opis sesji, czyli informacje, którymi muszą się wymienić strony połączenia na początku sesji. To zadanie realizują dwa protokoły: Session Announcement Protocol (SAP), opisany w dokumencie RFC 2974, oraz protokół Session Description Protocol (SDP), opisany w dokumencie RFC 2327. W skrócie, SAP służy do rozgłaszania sesji multimedialnych i obsługi komunikacji związanej z przesyłaniem informacji o sesjach do potencjalnych uczestników.
SDP definiuje format opisu sesji komunikacyjnej i może być wykorzystywany z różnymi protokołami transportowymi, jak SAP, SIP, HTTP i inne. Dokument RFC 2327 wyróżnia kilka najważniejszych informacji przekazywanych przez SDP:
- nazwa i cel sesji,
- czas trwania sesji,
- media obsługujące sesję,
- jak dotrzeć do tych mediów (adresy, porty, formaty).
Pozostałe informacje są opcjonalne:
- przepustowość wykorzystywana przez konferencję,
- informacje kontaktowe dla osób odpowiedzialnych za sesję.
Format SDP zawiera wiele linii tekstowych (np.
Opis sesji:
v= (wersja protokołu)
o= (twórca i identyfikator sesji)
s= (nazwa sesji)
i=* (informacje o sesji)
u=* (adres URI opisu)
e=* (adres e-mail)
p=* (numer telefonu)
c=* (informacje o połączeniu – nie wymagane, jeśli zawarte w opisie mediów)
b=* (informacje o przepustowości)
z=* (informacje o strefie czasowej)
k=* (klucz szyfrujący)
a=* (zero lub więcej linii atrybutów sesji)
Opis czasu
t= (czas trwania sesji)
r=* (czas zera lub więcej powtórzeń)
Opis mediów
m= (nazwa medium i adres transportowy)
i=* (tytuł medium)
c=* (informacje o medium – opcjonalne, jeśli zawarte w opisie sesji)
b=* (informacje o przepustowości)
k=* (klucz szyfrujący)
a=* (zero lub więcej linii atrybutów mediów)
Poniżej przykład opisu sesji zaczerpnięty z dokumentu RFC 2327:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
Zwróć uwagę, że występują dwa opisy mediów (wiersze zaczynające się od litery m), które definiują profil audio i wideo. Te profile są opisane w specyfikacji protokołu RTP.
Sygnalizacja SIP
Sygnalizacja związana z nawiązaniem połączenia przez protokół SIP jest podobna do sygnalizacji H.323, ale prostsza. Prostota ta jest wyraźnie widoczna w procedurze zestawiania połączenia. Do nawiązania bezpośredniego połączenia (bez pośrednictwa serwerów proxy) między urządzeniami końcowymi wykorzystywana jest tylko podstawowa konfiguracja. W prostym przykładzie, w celu zainicjowania sesji dzwoniący wysyła żądanie INVITE do odbiorcy, który odpowiada wiadomościami Ringing oraz OK. Uczestnik rozmowy może następnie wysłać potwierdzenie ACK, które zatwierdzi połączenie i pozwoli obu stronom połączenia wymieniać się informacjami. Kiedy połączenie zostanie zakończone, nastąpi przesłanie wiadomości BYE, a druga strona zwróci wtedy komunikat OK.
W bardziej złożonym przykładzie, opisanym w standardzie SIP, uwzględnimy wykorzystanie serwera proxy. Serwer proxy to urządzenie, które działa w imieniu innego urządzenia. Serwer SIP proxy działa jako pośrednik w celu nawiązywania połączeń w imieniu klientów SIP i w wielu przypadkach funkcjonuje w trybie routingu, przekazując żądania SIP do innych urządzeń, które są bliżej lokalizacji docelowej (drugiej strony połączenia).
W efekcie serwer SIP proxy spełnia podwójną rolę – działa jako serwer, gdy przetwarza żądania klientów, ale również jest klientem, gdy przekazuje dalej otrzymane żądania. Zwróć uwagę, że serwer proxy musi być przystosowany do interpretowania żądań SIP oraz generować nowe żądania przy przesyłaniu ich dalej. W dużych sieciach może być więcej niż jeden serwery proxy na ścieżce pomiędzy inicjującym połączenie a odbiorcą.
Dokument RFC 3261 opisuje ciekawy przykład procedury nawiązywania połączenia pomiędzy dwoma stacjami SIP znajdującymi się w dwóch różnych sieciach, pomiędzy którymi są dwa serwery proxy. Każda sieć ma własny serwer proxy o adresach atlanta.com oraz biloxi.com. Jeśli użytkownik z Atlanty dzwoni do Biloxi, telefon wysyła żądanie INVITE, które jest odczytywane i przekazywane przez serwer proxy atlanta.com:
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob
From: Alice
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
Zwróć uwagę, że wiadomość wymienia wiele protokołów, które opisujemy w tym artykule: adres SIP URI (sip:bob@biloxi.com) czy komendę Content-Type (application/sdp), które mogą zawierać informacje o medium obsługującym połączenie.
Gdy wiadomość przejdzie przez wszystkie pośredniczące sieci, osiągnie lokalizację docelową w Biloxi. Jeśli odbiorca chce odebrać połączenie i zainicjować połączenie, zostanie zwrócona wiadomość OK i przekazana przez serwer proxy biloxi.com:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob
From: Alice
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 131
Zwróć uwagę, że ten sam identyfikator połączenia (Call-ID: a84b4c76e66710@pc33.atlanta.com), który był wysłany w wiadomości INVITE jest zwracany w odpowiedzi OK, co pozwala odróżnić to połączenie od innych połączeń, które mogą być nawiązywane w tym samym czasie.
Powyższy przykład pokazuje, że podczas nawiązywania połączenia klient SIP przekazuje wiele parametrów. Więcej przykładów i obszerne opisy znajdują się w dokumencie RFC 3261.
