Telefonia SIP Session Initiation Protocol RFC 3261 RFC 2543

1. Telefonia SIP Session Initiation Protocol RFC 3261 RFC 2543

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

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

4. Architektura funkcjonalna sieci IP wykorzystującej protokół SIP składa się z węzłów dwóch typów: • Agentów użytkowników UA (User Agent). • 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).

5. Serwery sieciowe można podzielić na: • Serwery pośredniczące (Proxy Server); • Serwery przekazujące (Redirect Server); • Serwery lokalizacji (Location Server); • Serwery rejestrowe (Registrar Server); • Serwery mediów (Media Server); • Serwery aplikacji (Aplication Server).

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

7. 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łądglobalny (6xx - Global Failure) - żądanie nie może być spełnione przez żaden serwer, np.:600 Busy Everywhere. q

8. Wiadomości - metody • 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. • 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.

9. Wiadomości - metody • 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. • 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.

10. Wiadomości - metody • 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. • 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.

11. Specyfikacja SDP Session Description Protocol (RFC 2327) 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)orazopisu 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 jestnajnowsza <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ę;

12. 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> - modyfikatormoż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

13. Deskryptory danych audio/wideo: m=<media> <port> <transport> <fmt list> - sekcja opisu danych ma czteryparametry: <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,

14. Przykład opisu SDP INVITE sip:picard@wcom.com SIP/2.0 Via: SIP/2.0/UDP host.wcom.com:5060 From: Alan Johnston <sip:alan.johnston@wcom.com> To: Jean Luc Picard <sip:picard@wcom.com> 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 Powyższe żądanie inicjuje sesję dźwiękową opartą na protokole transportowym RTP. Osobą inicjującą sesję jest host host.wcom.com.

15. 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;

16. SIP proxy cs.columbia.edu 5 3 2 henning hgs@play INVITE hgs@play From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs hgs 4 INVITE henning@cs.columbia.edu From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs 1 cs.tu-berlin.de 200 OK From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs 6 200 OK From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs cz@cs.tu-berlin.de 7 play ACK hgs@play From: cz@cs.tu-berlin.de To: henning@cs.columbia.edu Call-ID: 19970827@lion.cs ACK henning@cs.columbia.edu Call-ID: 19970827@lion.cs 9 8 proxy 10 200 OK lion 11 200 OK

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

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

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

20. Dziękuję za uwagę