Telefonia SIP Telefonia SIP

Session Initiation ProtocolSession Initiation ProtocolRFC 3261RFC 3261

RFC 2543

H.323 SIPRSVP RTCP RTP

TCP UDP

IP4, IP6

PPP

V.34

ALL3/4 ALL5

ATM Ethernet

SDP

Stos protokołów realizacji usługi głosowej w sieci IP na bazie protokołu SIP

RSVP Resource Reservation ProtocolSDP Session Description ProtocolSIP Session Initiation ProtocolRTCP RTP Control ProtocolRTP Real Time Protocol

SIP (Session Initiation Protocol) jest protokołem tekstowym warstwy aplikacji, typu klient-serwer, przeznaczonym do inicjowania, modyfikacji i kończenia interaktywnych multimedialnych sesji komunikacyjnych dla dwóch lub więcej uczestników.

Sesją może być:• wideokonferencja,• wideotelefonia, • telefonia internetowa (VoIP),• konferencja danych, itp.

Architektura funkcjonalna sieci IP wykorzystującej protokół SIP składa się z węzłów dwóch typów:

1. Agentów użytkowników UA (User Agent).2. Serwerów o różnym przeznaczeniu i sposobach

działania.

Agent użytkownika (UA) jest elementem pośredniczącym w komunikacji między użytkownikiem a siecią. UA łączy w sobie funkcje klienta UAC (UA Client) i serwera UAS (UA Server). Każdy terminal sieci SIP pełni rolę UA (UAC+UAS) i jest jednocześnie węzłem typu host w znaczeniu internetowym. Umożliwia to wysyłanie przez użytkownika zarówno żądań (np. inicjowanie sesji) jak i odpowiadanie na żądania przychodzące (np. przyjęcie zaproszenia do sesji).

Serwery sieciowe można podzielić na:

1. Serwery pośredniczące (Proxy Server);2. Serwery przekazujące (Redirect Server);3. Serwery lokalizacji (Location Server);4. Serwery rejestrowe (Registrar Server);5. Serwery mediów (Media Server);6. Serwery aplikacji (Aplication Server).

Żądanie i odpowiedzi SIP:

Format żądania: Request-line = Method Request-URI SIP-Version

Format odpowiedzi:Status-line = SIP-Version Status-Code Reason-Phrase

      

Odpowiedzi mają postać podobną jak odpowiedzi w protokole HTTP. W szczególności zawierają one trzycyfrowy kod odpowiedzi wraz z towarzyszącym mu słownym wyjaśnieniem. Wyróżniono sześć typów odpowiedzi:

informacyjne (1xx - Provisional) – wskazujące postęp w wywołaniu metody, np.: 100 Trying, 180 Ringing, 181 Call Is Being Forworded, 182 Queued;

osiągnięto sukces (2xx - Success) - żądanie zostało poprawnie otrzymane, zrozumiane oraz zaakceptowane. Interpretacja odpowiedzi zależy od użytej metody;

przekierowanie (3xx - Redirection) - wskazanie konieczności podjęcia dodatkowych akcji związanych z obsługą żądania. Odpowiedź zawiera informację o lokalizacji wywoływanego użytkownika lub o alternatywnej usłudze. Nowe wywołanie powinno zostać wysłane pod nowy adres. UAC lub serwer proxy muszą sprawdzić czy pod otrzymany adres nie wysyłano już wcześniej tego żądania (detekcja pętli);

błąd po stronie klienta (4xx - Client Error) - żądanie jest niepoprawne lub nie może być zrealizowane przez dany serwer, np.: 407 Proxy Authentication Required;

błąd po stronie serwera (5xx - Server Error) - dany serwer nie może obsłużyć żądania, np.: 500 Internal Server Error;

błąd globalny (6xx - Global Failure) - żądanie nie może być spełnione przez żaden serwer, np.:600 Busy Everywhere.

Wiadomości - metody

1. INVITE inicjuje połączenie i stanowi zaproszenie do sesji. W nagłówkach wiadomości zawarte są informacje o adresach użytkowników, temacie połączenia, priorytetach. Treść wiadomości zawiera opis sesji (rodzaje mediów, które terminal wywołujący może obsłużyć, typy kodeków, metody kompresji, protokoły, itp.). Jeżeli podczas trwania połączenia użytkownik odbierze wiadomość z metodą INVITE od użytkownika, z którym jest połączony oznacza to żądanie zmiany parametrów sesji. Może ono zostać przyjęte lub odrzucone przez wysłanie odpowiedzi z proponowanymi nowymi parametrami sesji.

2. ACK jest wysyłana jako potwierdzenie, że klient otrzymał końcową odpowiedź na żądanie z metodą INVITE. Żądanie z metodą ACK może zawierać treść wiadomości. W tym przypadku zawiera ona ostateczne parametry połączenia używane przez wywołującego. W przeciwnym razie obowiązują parametry połączenia zawarte w żądaniu INVITE.

3. OPTIONS jest wysyłana w celu uzyskania informacji o stanie użytkownika. Gdy jest on w stanie gotowości może odpowiedzieć wiadomością zawierającą obsługiwane przez niego media, protokoły, itp. Gdy jest zajęty może odesłać odpowiedź zawierającą adres poczty elektronicznej lub głosowej.

4. BYE jest wysyłana w celu zakończenia połączenia. Adresat powinien zaprzestać wysyłania danych tylko do tego użytkownika, który przesłał tę wiadomość. Mechanizm ten pozwala rezygnować z uczestnictwa w sesji grupowej – konferencji.

Wiadomości - metody

5. CANCEL jest wysłana w celu zakończenia przetwarzania żądań będących w toku, lecz nie rozłącza połączeń w ramach już zestawionych sesji. Przykładowe zastosowanie to zakończenie wywoływania użytkownika na wszystkich terminalach po odebraniu przez niego połączenia na jednym terminalu.

6. REGISTRER służy do rejestracji użytkownika w serwerze lokalizacji. Zapis w serwerze może zawierać dodatkowe informacje o użytkowniku, np.: o czasie dostępności użytkownika, przyczynie nieobecności i planowanym czasie powrotu.

Wiadomości - metody

Opis SDP składa się z linii tekstu w formacie <typ>=<wartość>, gdzie <typ> jest zawsze jednym znakiem, natomiast <wartość> jest strukturalnym tekstem, którego format zależy od pola <tup>.Opis sesji składa się z właściwego opisu sesji (session level-description) oraz opisu transportowanych danych (media-level descriptions). Dekskryptory sesji:v=<version> - wersja protokołu SDP,o= informacja o twórcy i identyfikatorze sesji: <username> - identyfikator hosta źródłowego; <session id> - ciąg alfanumeryczny, unikalny identyfikator sesji; <version> - wersja zapowiedzi, używana do określenia, która z wielu zapowiedzi jest najnowsza <network type> - ciąg tekstowy, określający typ sieci, (Internet – IN); <address type> - ciąg tekstowy definiujący typ adresu (IP4 lub IP6);  <address> - adres hosta, który utworzył sesję.s*=<session name> - nazwa sesji, każda sesja musi mieć jedną (i tylko jedną) nazwę;i*=<session information> - pole informacyjne o sesji;u*=<URI of description> - więcej informacji o sesji; e*=<eamil address> - osoby odpowiedzialnej za sesję;P*=<phone number> - osoby odpowiedzialnej za sesję;

Specyfikacja SDP Session Description Protocol (RFC 2327)

c*= informacja o połączeniu: <network type> - typ sieci (Internet IN) <address type> - typ adresu (np. IP4) <connection address> - aktualny adres hosta dostarczającego dane audio/wideo

b*=<modifier>:<bandwidth-value >

<modifier> - modyfikator może przyjąć dwie wartości: CT – (conference total) i AS (application- specific max)- informacje o paśmie;

<bandwidth-value> podany jest w kilobajtach

t*=<start time> <stop time> - czas startu i końca sesji

z*= - strefa czasowa

a*= - atrybuty dodatkowe

 Deskryptory danych audio/wideo:

m=<media> <port> <transport> <fmt list> - sekcja opisu danych ma cztery parametry: <media> - charakterystyka danych (np.: audio, video, itd.), <port> - numer portu,  <transport> - protokół transportowy dla danych (np. RTP),  <fmt list> - lista formatów.i= - tytuł,b= - informacje o paśmie,

INVITE sip:picard@wcom.com SIP/2.0Via: SIP/2.0/UDP host.wcom.com:5060From: Alan Johnston <sip:alan.johnston@wcom.com>To: Jean Luc Picard <sip:picard@wcom.com>Call-ID: 314159@host.wcom.comCSeq: 1 INVITEContact: sip:alan.johnston@wcom.comSubject: Where are you these days?Content-Type: application/sdp Content-Length: 124 v=0o=ajohnston 5462346 332134 IN IP4 host.wcom.coms=Let's Talkt=0 0c=IN IP4 10.64.1.1m=audio 49170 RTP/AVP 0 3  

Zapytanie SIP

Opis SDP

Przykład opisu SDP

Powyższe żądanie inicjuje sesję dźwiękową opartą na protokole transportowym RTP. Osobą inicjującą sesję jest host host.wcom.com.

Przykład realizacji VoIP na bazie SIP

• klienci usługi VoIP: SIP (UAC+UAS), konfiguracja hosta IP;• zlokalizowane serwery: SIP Proxy, Redirect, Registrar, Location (DNS);• konfiguracja serwerów SIP – konta użytkowników;

SIP proxy

cs.tu-berlin.de

cz@cs.tu-berlin.de

lion

INVITE henning@cs.columbia.eduFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs

200 OKFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs

200 OK

hgsINVITE hgs@playFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs

play

200 OKFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs

ACK hgs@play From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs

200 OK

cs.columbia.edu

1

7

ACK henning@cs.columbia.edu Call-ID: 19970827@lion.cs

8

11

henning2 hgs@play

3

4

6

9

10

proxy

5

SIP redirect

cs.tu-berlin.de

cz@cs.tu-berlin.de

lion

INVITE henning@cs.columbia.eduFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs

302 Moved temporarilyLocation:hgs@play.cs.columbia.eduFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs

play

cs.columbia.edu

1

4

2

7

henning

2play.cs.columbia.edu3

redirect

INVITE hgs@play.cs.columbia.eduFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs

200 OKFrom: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs 2

ACK hgs@play.cs.columbia.edu Call-ID: 970827@lion.cs 2

8

200 OK9

6

hgs@play

VoIP SIP w ofercie SNOM

Sieć z protokołem IP

IP

Firewall, Ruter

(filtrowanie i zliczanie ruchu)

SIP UA

SIP Proxy

SIP Redirect

Media server

SIP UA

IP

SIP UA

SIP UA

DNS

Następne kroki implementacji VoIP

• zbadanie funkcjonalności sygnalizacji SIP• zbadanie wpływu metody kodowania głosu na ruch RTP/UDP/IP• określenie i przebadanie współpracy z SIP (SNOM) usługi DNS• określenie wpływu parametrów i typu sieci na działanie SIP• przyjazne usłudze metody kształtowania ruchu na firewallu i ruterze• zbadanie sygnalizacji przy realizacji usług dodatkowych

Dziękuję za uwagę Dziękuję za uwagę