Telefonia SIP Session Initiation Protocol RFC 3261 RFC 2543.

Prezentacja na temat: "Telefonia SIP Session Initiation Protocol RFC 3261 RFC 2543."— Zapis prezentacji:

1

2 Telefonia SIP Session Initiation Protocol RFC 3261 RFC 2543

3 H.323SIPRSVPRTCPRTP TCPUDP IP4, IP6 PPP V.34 ALL3/4ALL5 ATM Ethernet SDP Stos protokołów realizacji usługi głosowej w sieci IP na bazie protokołu SIP RSVP Resource Reservation Protocol SDP Session Description Protocol SIP Session Initiation Protocol RTCP RTP Control Protocol RTP Real Time Protocol

4 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.

5 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).

6 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).

7 Żądanie i odpowiedzi SIP: Format żądania: Request-line = Method Request-URI SIP-Version Format odpowiedzi: Status-line = SIP-Version Status-Code Reason-Phrase

8  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.

9 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.

10 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

11 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

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

13 c*= informacja o połączeniu: - typ sieci (Internet IN) - typ adresu (np. IP4) - aktualny adres hosta dostarczającego dane audio/wideo b*= : - modyfikator może przyjąć dwie wartości: CT – (conference total) i AS (application- specific max)- informacje o paśmie; podany jest w kilobajtach t*= - czas startu i końca sesji z*= - strefa czasowa a*= - atrybuty dodatkowe

14 Deskryptory danych audio/wideo: m= - sekcja opisu danych ma cztery parametry: - charakterystyka danych (np.: audio, video, itd.), - numer portu, - protokół transportowy dla danych (np. RTP), - lista formatów. i= - tytuł, b= - informacje o paśmie,

15 INVITE sip:picard@wcom.com SIP/2.0 Via: SIP/2.0/UDP host.wcom.com:5060 From: Alan Johnston To: Jean Luc Picard Call-ID: 314159@host.wcom.com CSeq: 1 INVITE Contact: sip:alan.johnston@wcom.com Subject: Where are you these days? Content-Type: application/sdp Content-Length: 124 v=0 o=ajohnston 5462346 332134 IN IP4 host.wcom.com s=Let's Talk t=0 0 c=IN IP4 10.64.1.1 m=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.

16 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;

17 SIP proxy cs.tu-berlin.de cz@cs.tu-berlin.de lion INVITE henning@cs.columbia.edu From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs 200 OK From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs 200 OK hgs INVITE hgs@play From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs play 200 OK From: 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 henning 2 hgs@play 3 4 6 9 10 proxy 5

18 SIP redirect cs.tu-berlin.de cz@cs.tu-berlin.de lion INVITE henning@cs.columbia.edu From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs 302 Moved temporarily Location:hgs@play.cs.columbia.edu From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs play cs.columbia.edu 1 4 2 7 henning 2 play.cs.columbia.edu 3 redirect INVITE hgs@play.cs.columbia.edu From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 970827@lion.cs 200 OK From: 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 OK 9 6 hgs@play

19 VoIP SIP w ofercie SNOM IP Firewall, Ruter (filtrowanie i zliczanie ruchu) SIP UA SIP Proxy SIP Redirect Media server SIP UA IP SIP UA DNS

20 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

21 Dziękuję za uwagę