telefonia sip session initiation protocol rfc 3261 rfc 2543
DESCRIPTION
Telefonia SIP Session Initiation Protocol RFC 3261 RFC 2543. 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 - PowerPoint PPT PresentationTRANSCRIPT
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:[email protected] SIP/2.0Via: SIP/2.0/UDP host.wcom.com:5060From: Alan Johnston <sip:[email protected]>To: Jean Luc Picard <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]: 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
lion
INVITE [email protected]: [email protected] To: [email protected] Call-ID: [email protected]
200 OKFrom: [email protected] To: [email protected] Call-ID: [email protected]
200 OK
hgsINVITE hgs@playFrom: [email protected] To: [email protected] Call-ID: [email protected]
play
200 OKFrom: [email protected] To: [email protected] Call-ID: [email protected]
ACK hgs@play From: [email protected] To: [email protected] Call-ID: [email protected]
200 OK
cs.columbia.edu
1
7
ACK [email protected] Call-ID: [email protected]
8
11
henning2 hgs@play
3
4
6
9
10
proxy
5
SIP redirect
cs.tu-berlin.de
lion
INVITE [email protected]: [email protected] To: [email protected] Call-ID: [email protected]
302 Moved temporarilyLocation:[email protected]: [email protected] To: [email protected] Call-ID: [email protected]
play
cs.columbia.edu
1
4
2
7
henning
2play.cs.columbia.edu3
redirect
INVITE [email protected]: [email protected] To: [email protected] Call-ID: [email protected]
200 OKFrom: [email protected] To: [email protected] Call-ID: [email protected] 2
ACK [email protected] Call-ID: [email protected] 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ę