SNG architektura i protokół SIP Materiały wykładowe do użytku wewnętrznego

Transkrypt

1 Instytut Telekomunikacji PW SNG architektura i protokół SIP Materiały wykładowe do użytku wewnętrznego SNG-SIP 1

2 Megaco/H.248 Megaco/H.248 Warstwa aplikacyjna? np. SS7/IP (czyli SIGTRAN) MGC Serwery SIP SIP MGC SIP MG RTP+RTCP UDP/IP MG Rel. 7 SNG-SIP 2

3 Zakres Podstawy architektury SIP charakterystyka, składniki funkcjonalne, SIP w skrócie - prosty przykład Model zgłoszenia: sesje, dialogi, transakcje Serwery i metody (wiadomości) także zasady kierowania wiadomości Negocjacja medium - SIP i SDP (Session Description Protocol) Współpraca z innymi systemami sygnalizacji (ISUP) Elementy zaawansowane rezerwacja zasobów (przykład przy okazji omawiania architektury IMS) modele zgłoszenia: 3pcc, B2BUA (Back-to-Back UA), sesje wielostronne usługi obecności (Presence) i Instant Messaging (por. IETF SIMPLE ważniejsze RFC: 3863, 4479, 4745, 5025 / 3428, 4975, 4976 ) pokonywanie NAT i Firewall Peer-To-Peer SIP (zobaczymy czy wystarczy czasu) SNG-SIP 3

4 Zakres Podstawy architektury SIP charakterystyka, składniki funkcjonalne, SIP w skrócie - prosty przykład Model zgłoszenia: sesje, dialogi, transakcje Serwery i metody (wiadomości) także zasady kierowania wiadomości Negocjacja medium - SIP i SDP (Session Description Protocol) Współpraca z innymi systemami sygnalizacji (ISUP) Elementy zaawansowane rezerwacja zasobów (przykład przy okazji omawiania wrchitektury IMS) modele zgłoszenia: 3pcc, B2BUA (Back-to-Back UA), sesje wielostronne usługi obecności (Presence) i Instant Messaging (por. IETF SIMPLE ważniejsze RFC: 3863, 4479, 4745, 5025 / 3428, 4975, 4976 ) pokonywanie NAT i Firewall Peer-To-Peer SIP (zobaczymy czy wystarczy czasu) SNG-SIP 4

5 Ogólna idea SIP Nawiązanie sesji (np. połączenia) wyszukiwanie (proxy) Aplikacja 1 Sygnalizacja (SIP) Aplikacja 2 F2 F1 F1 Fi sesja Fi Wzorowany trochę na HTTP, trochę na SMTP + nowe funkcje sesyjne GET /path/file.html HTTP/1.0 From: ktos@tele.pw.edu.pl User-Agent: HTTPTool/1.0 <CR/LF> HTTP/ OK Date: Fri, 14 Mar :59:59 GMT Content-Type: text/html Content-Length: 1354 HTTP <html> <body> SNG-SIP </body> </html> 5

6 SIP podstawowa charakterystyka SIP - Session Initiation Protocol (RFC >150 ) protokół koniec-koniec przeznaczony do nawiązywania sesji multimedialnych obejmuje następujące obszary związane z: lokalizowaniem użytkowników ustalaniem dostępności użytkowników informowaniem o właściwościach (cechach) użytkowników nawiązaniem sesji (z uwierzytelnieniem i negocjacją parametrów) zarządzaniem sesją (modyfikacja charakterystyki medium, zarządzanie stronami sesji wielostronnej), kończeniem sesji możliwość budowy wielu usług na bazie SIP dzięki otwartości styku do stosu SIP usługi: sesyjne - różne formy przekierowania, konferencje, interakcja z WWW,... elementy modelu publish/subscribe zdarzenia/obecność, krótkie wiadomości tekstowa składnia (czy to zaleta?) Czym SIP nie jest? np. protokołem transportowym, mechanizmem gwarantowania QoS, protokołem sterowania bramami, protokołem usługowym do pełnego sterowania konferencjami SNG-SIP 6

7 Składniki funkcjonalne Funkcje końcowe agent użytkownika (user agent - UA) klient (UA client) - inicjuje zgłoszenia (sesje) serwer (UA server) - odbiera zgłoszenia Funkcje sieciowe serwery serwery SIP serwer proxy (SIP Proxy Server) kieruje wiadomości SIP - routing (również po translacji adresu w Redirect) serwer przekierowań (SIP Redirect Server) informuje o konieczności kontaktu z innymi serwerami (translacja adresu) serwer rejestracji (SIP Registrar) rejestruje zgłoszenia użytkowników o ich lokalizacjach utrzymuje dane lokalizacyjne w bazie danych (Location Server) B2B UA (Back-To-Back User Agent) Przykładowa architektura Serwer lokalizacyjny Registrar UA Proxy np. Redirect/ Proxy UA 7

8 SIP w skrócie - adresacja Adresy globalne użytkownik rejestruje swój adres komendą REGISTER klient (UA client) - inicjuje sesje (zgłoszenia) wywołania do niego są kierowane na ten adres Podstawowym schematem adresowym jest SIP-URI (RFC 3261) ogólna forma (również dla zewnętrznych źródeł danych adresowych) sip:user:password@host:port;uri-parameters?headers <sip:darek@tele.pw.edu.pl> <sip: @ :5060;user=phone?> ale poprawne są też inne schematy, np. <tel: ;service=pstn> mailto:... SIP-URI z zewnętrznego źródła to nie to samo co Request-URI <sip:tele.pw.edu.pl;method=register;transport=tcp?to=sip:honorka%40tele.pw.edu.pl> wykorzystanie mogłoby być takie (transakcja z wykorzystaniem protokołu TCP): REGISTER <sip:tele.pw.edu.pl> To: <sip:honorka@tele.pw.edu.pl> Contact: <jakiś adres> SNG-SIP 8

9 SIP w skrócie - rejestracja paradygmat mobilności osobistej (personal mobility) model serwera rejestracji HLR/HSS lub modniej Publish/Subscribe Związanie adresu URI użytkownika z lokalizacją darek@ vangogh.tele.pw.edu.pl Location Server (2) Registrar Domena: tele.pw.edu.pl [IpAddr... ; UDPport=5060 ] REGISTER sip:sipregtele.pw.edu.pl SIP/2.0 Via: darek@titan.tele.pw.edu.pl From: sip:darek@tele.pw.edu.pl (także Call-Id..., Cseq:1 REGISTER) To: <sip:darek@tele.pw.edu.pl> Contact: <sip:darek@vangogh.tele.pw.edu.pl> (1) (3) OK SIP/2.0 ( CallId...; Cseq: 1 REGISTER) adresat tej wiadomości (adres rutowalny IPAddr - wg konfiguracji lub odzyskiwany za pośrednictwem DNS) darek@tele.pw.edu.pl vangogh.tele.pw.edu.pl SNG-SIP 9

10 Obow. (2) (3) SIP w skrócie - nawiązanie sesji (0) uzyskanie adresu właściwego węzła SIP do przesłania doń wiadomości INVITE w celu osiągnięcia domeny tele.pw.edu.pl (adresat tej wiadomości, niekoniecznie użytkownik sesji) np.: DNS? sip:darek@tele.pw.edu.pl Odp: adres IP "odpowiedniego" proxy (IpAddr) (por. RFC 3263) Location Server Domena: tele.pw.edu.pl radek@spaget.waw.pl m1.spaget.waw.pl (1) [IpAddr... ; UDPport=5060 ] INVITE sip:darek@tele.pw.edu.pl Via: m1.spaget.waw.pl From: <sip:radek@spaget.waw.pl>, r-tag To: <sip:darek@tele.pw.edu.pl> Call-Id: 12345@m1.spaget.waw.pl ; Cseq:1 INVITE Contact: <sip:radek@m1.spaget.waw.pl> + SDP Ruter Proxy (6) [...] OK Via: m1.spaget.waw.pl From: <sip:radek@spaget.waw.pl>; r-tag To: <sip:darek@tele.pw.edu.pl>; d-tag Call-Id: 12345@m1.spaget.waw.pl ;Cseq=1 INVITE. Contact: <sip:darek@vangogh.tele.pw.edu.pl> + SDP (5) [...] OK Via: sipproxytele.pw.edu.pl Via: m1.spaget.waw.pl From:<sip:radek@spaget.waw.pl>; r-tag To: <sip:darek@tele.pw.edu.pl> d-tag Call-Id: 12345@m1.spaget.waw.pl ;Cseq... Contact: <sip:darek@vangogh.tele.pw.edu.pl> (7) [...] + SDP ACK sip:darek@vangogh.tele.pw.edu.pl From: <si::radek@spaget.waw.pl>; r-tag To: <sip:darek@tele.pw.edu.pl>; d-tag Call-Id: 12345@spaget.waw.pl ; Cseq:1 ACK (8) Medium/RTP/UDP/IP (4) [...] INVITE sip:darek@vangogh.tele.pw.edu.pl Via: sipproxy@tele.pw.edu.pl Via: m1.spaget.waw.pl From: <sip:radek@spaget.waw.pl>; r-tag To: <sip:darek@tele.pw.edu.pl> Call-Id: 12345@m1.spaget.waw.pl ; Cseq: 1 INVITE Contact: <sip::radek@m1.spaget.waw.pl> + SDP Ruter Cechy połączenia na podstawie danych wymienianych z użyciem SDP darek@tele.pw.edu.pl vangogh.tele.pw.edu.pl SNG-SIP 10

11 SIP w skrócie - zakończenie sesji Location Server Domena: tele.pw.edu.pl Proxy (tu: bezstanowy) (1) [Ipaddr... ; UDPaddr=5060 ] BYE sip:radek@m1.spaget.waw.pl *) Via: vangogh.tele.pw.edu.pl From: <sip:darek@tele.pw.edu.pl>; d-tag To: <sip:radek@spaget.waw.pl>; r-tag Call-Id: 12345@m1.spaget.waw.pl ; Cseq: 1 BYE. radek@spaget.waw.pl m1.spaget.waw.pl (2) [...] OK Via: vangogh.tele.pw.edu.pl From: <sip:darek@tele.pw.edu.pl>; d-tag To: <sip:radek@spaget.waw.pl>; r-tag Call-Id: 12345@m1.spaget.waw.pl ;Cseq: 1 BYE darek@tele.pw.edu.pl vangogh.tele.pw.edu.pl *) procedura zakończenia sesji może być realizowana bez pośrednictwa Proxy i nie musi wymagać odwołania do DNS Ruter Medium/RTP/UDP/IP Ruter SNG-SIP 11

13 Model zgłoszenia Podstawowe pojęcia Zgłoszenie_SIP może obejmować: wiele dialogów (>= 1) każdy dialog obejmuje dwóch użytkowników (UA) definicja: RFC 3261, p.12; obecnie 2 typy dialogów (INVITE, NOTIFY) dialog obejmuje jedną sesję_sip (<=1) (zbiór strumieni UA-UA) sesja jednoznacznie wynika z dialogu a do sterowania powyższymi służą metody SIP Zgłoszenia, dialogi i transakcje są rozróżnialne mają identyfikatory zgłoszenie/sesja pojęcia poziomu użytkownika dialog poziom protokołu (posiada stan!) Zgłoszenie SIP (konwersacja) Dialog UA Sesja SIP UA Call_id-1 Dialog 1 UA [Zgłoszenie SIP] UA Call_id-1 {Call-ID, From tag, To tag} Dialog 2 {Call-Id} zbiór strumieni: { (IP-addr, Port#, kodek)... } UA [Zgłoszenie SIP]' W modelu 2-party zgłoszenie SIP będziemy utożsamiać z dialogiem SNG-SIP 13

14 Model zgłoszenia cd. W ogólności sesja medialna może obejmować klientów nietożsamych z urządzeniami realizującymi funkcje sterowania UA np. układ MGC MG/MediaServer transakcje UA Dialog UA Medium Sesja SIP Medium SNG-SIP 14

15 Transakcje SIP Model dialogu SIP : klient-serwer Podstawowa koncepcja przyjęta w SIP - transakcje Transakcja klient ::= żądanie klienta do serwera + wszystkie odpowiedzi serwera dotyczy dialogu oraz może dotyczyć nowej sesji (zgłoszenia) Req Res-Provisional... Res-Provisional Res-Final Ack dla Res-Final serwer dla transakcji INVITE więcej - przy okazji proxy stanowego i SDP... Ogólny schemat transakcji: 1xReq żądanie nxres-provisional odpowiedzi tymczasowe 1xRes-Final odpowiedź końcowa Typy transakcji transakcja typu non-invite - schemat ogólny (j.w.) transakcja INVITE - schemat ogólny + potwierdzenie (ACK) dla Res-Final SNG-SIP 15

17 Odpowiedzi finalne Podstawowe wiadomości i typy odpowiedzi Żądania REGISTER INVITE - rozpoczęcie/modyfikacja sesji ACK - potwierdzenie dla odpowiedzi finalnej (final response) BYE - zakończenie wcześniej ustanowionej sesji CANCEL - przerwanie wykonywanej transakcji inne: OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY/EVENT, PRACK, UPDATE (zastąpił COMET), REGISTER Typy odpowiedzi (por. też odpowiedzi HTTP) 1xx: Provisional - żądanie otrzymane, trwa jego realizacja (por. ISUP - CPG, ACM) 2xx: Success - akcje związane z żądaniem zostały zrozumiane, zaakceptowane i wykonane 3xx: Redirection - w celu zrealizowania żądania należy wykonać dalszą akcję (wynikająca ze szczegółowego typu odpowiedzi) 4xx: Client Error - żądanie jest niepoprawne i nie może zostać zrealizowane przez serwer (np. składnia, autoryzacja, pętla, ograniczona funkcjonalność,...) 5xx: Server Error - serwer jest niezdolny do realizacji (skądinąd poprawnego) żądania 6xx: Global Failure - żądanie zasadniczo nie może być zrealizowane przez żaden serwer z przyczyn obiektywnych. SNG-SIP 17

18 Pola nagłówka (header fields) Obowiązkowe Wiadomości - składnia Szczegóły - por. RFC 3261 Ważniejsze elementy - na podstawie przykładu (opis nieformalny) żądanie "body" From: <sip:radek@spaget.waw.pl>;tag=123 Inicjator transakcji, local-tag (loc-tag fragment identyfik. dialogu) INVITE sip:darek@tele.pw.edu.pl SIP/2.0 Request line = Metoda Request-URI wersja SIP Request-URI - aktualny adresat wiadomości (ruting SIP) Via: m1.spaget.waw.pl Sekwencja węzłów na drodze wiadomości (dla Response transakcji) To: <sip:darek@tele.pw.edu.pl> adresat żądania Call-Id: 12345@m1.spaget.waw.pl Globalnie jednoznaczny identyfikator zgłoszenia SIP Cseq: 1 INVITE Id transakcji (<nr sekwencyjny + Metoda>) Contact: <sip:radek@m1.spaget.waw.pl> Adres konkretnego urządzenia klienta (np. FQDN, IPAddr) -do bezpośr. kontaktu (w kolejnych transakcjach Request-URI) Content-type... Content-length... Opis ciała (Body) wiadomości SDP Ciało - np. opis sesji (kodeki, adresy transportowe),"dowolne info" SNG-SIP 18

19 Obowiązkowe Wiadomości - składnia odpowiedź SIP/ OK Via: sipproxy.tele.pw.edu.pl Via: m1.spaget.waw.pl From: <sip:radek@spaget.waw.pl>;tag=123 To: <sip:darek@tele.pw.edu.pl>; tag=456 Call-Id: 12345@m1.spaget.waw.pl Cseq:1 INVITE Contact: <sip:darek@vangogh.tele.pw.edu.pl;...>... + SDP' Wersja SIP kod-odpowiedzi nazwa-odpowiedzi Via => Lista Request-URI - droga przebyta przez INVITE - umożliwia powrót odpowiedzi tą samą drogą... local-tag... remote-tag (rem-tag fragment identyfik. dialogu) {Call-Id, local-tag, remote-tag} identyfikuje dialog SIP rad INVITE From: rad; Tag=123 To: dar Call-ID: x Tagi dar OK From: rad; Tag=123 To:... Tag=456 Call-ID: x BYE From: dar; Tag=456 OK To: rad; Tag=123 From: dar; Tag=456 Call-ID: x To: rad; 123 SNG-SIP Call-ID: x 19

20 składnia cd. strony w zgłoszeniu ewolucja konfiguracji From A To B Logika Ruting SIP usługi logika usługi (SIP) (SIP) Contact C Contact D Logika usługi lub arch. fizyczna (wg opisu SDP) E <IP, Port> RTP-RTCP/UDP/IP F <IP, Port> Inicjator i pierwotny adresat dialogu Ostateczni uczestnicy dialogu Rzeczywiste adresy transportowe sesji por. slajd Model zgłoszenia cd. SNG-SIP 20

22 Serwery: Registrar Definicja: serwer akceptujący rozkazy REGISTER i przekazujący zawarte w nich informacje do usługi lokalizacyjnej w zarządzanej przez siebie domenie. Cel: zapewnienie odwzorowania między zewnętrznie znanym adresem(mi) użytkownika a jego obecnym adresem(mi) fizycznym(i). Także: do pobieranie aktualnych odwzorowań lokalizacyjnych Usługa lokalizacyjna: funkcja bazy danych (LDAP, SQL, centr/rozpr...) Scenariusz wykorzystania Domena macierzysta B@pw.edu.pl Serwer Registrar 2: zapisz dane(az,af) Usługa lokalizacyjna 1: REGISTER To:B@pw.edu.pl Contact: B@titan.pw.edu.pl) LDAP SQL... 4: pobierz dane(b@pw.edu.pl) 5: dane(b@pw.edu.pl, B@titan.pw.edu.pl) AZ: B@pw.edu.pl AF: titan.pw.edu.pl 3: INVITE B@titan.pw.edu.pl Serwer Proxy 3: INVITE B@pw.edu.pl SNG-SIP 22

23 Serwery: Redirect Definicja: serwer odbierający rozkazy SIP (Req) od klientów i wysyłający odpowiedzi (Res) typu 3xx (Redirection), kierujące klientów pod alternatywne zestawy adresów SIP Odpowiedzi typu Redirection (wg RFC 3261) 300 Multiple choices Adres zawarty w polu Request-URI żądania jest związany z wieloma wyborami; przykładowe zastosowanie: gdy użytkownik jest zarejestrowany w wielu lokalizacjach i serwer nie chce samodzialnie realizować przekierowania lub wywołania wielokrotnego (forking); 301 i 302 też mogą zawierać wielokrotne adresy, jednak uszczegółowiają przyczynę przekierowania 301 Moved permanently 302 Moved temporarily 305 Use proxy Użytkownik nie może zostać osiągnięty pod adresem określonym przez Request-URI i należy ponowić próbę (INVITE) pod nowymi adresami podanymi zwrotnie w Contact Użytkownik jest czasowo osiągalny pod nowymi adresami (czas ważności może zostać podany w uzupełnieniu pola Contact) (zastosować INVITE) Adresat może zostać osiągnięty za pośrednictwem serwera Proxy podanego w polu Contact (zastosować INVITE) 380 Alternative service Zgłoszenie nie może zostać zrealizowane w ramach architektury SIP, jednak istnieją usługi zamienne, opisane w ciele odpowiedzi (SDP). Wykorzystanie tej odpowiedzi w ramach SIP nie jest jeszcze dokładnie zdefiniowane. SNG-SIP 23

24 Serwery: Redirect - cd. Przykład przekierowania zgłoszenia z udziałem Proxy Usługa lokalizacyjna łącz do B UA A Redirect UA B UA X INVITE X 302 Moved Tmp Contact: B ACK INVITE B 200 OK ACK Contact: B Request-URI {local-tag, remote-tag, Call-ID} From: A; tag=1 To: X; tag=2 Call-ID=abc Cseq: 1 INVITE {local-tag, remote-tag, Call-ID} From: A; tag=1 To: X; tag=2 Call-ID=abc Cseq: 2 INVITE "ten sam" dialog ale nowa" transakcja Serwery Redirect są transakcyjne - transaction-stateful (nie są świadome dialogów, ale są świadome transakcji; obsługują "jedną" transakcję - INVITE) Własności: prostota operacji, wysoka skalowalność i wydajność działania Podstawowe zastosowania: realizacja złożonych polityk rutingowych (np. równoważenie obciążeń) SNG-SIP 24

25 Serwer Proxy Definicja: element kierujący żądania do serwerów-agentów użytkownika (UAS), a odpowiedzi - do klientów-agentów użytkownika (UAC). żądanie może przechodzić przez wiele serwerów Proxy każdy Proxy podejmuje decyzje rutingowe i może zmieniać żądanie przed wysłaniem do kolejnego węzła (ale w ograniczonym zakresie, np. nie-sdp) odpowiedzi (w ramach transakcji) wędrują przeciwnie niż żądanie (kolejność -1 ) (sl.16) Serwer Proxy można porównać z ruterem poziomu SIP, ale o logice wykraczającej poza zwykły ruting oparty o statyczne tablice rutingowe: sprawdzanie poprawności żądań uwierzytelnienie użytkowników powielanie żądań (fork requests) i operacje na adresach przerywanie martwych zgłoszeń detekcja i obsługa zapętleń rutingowych Szerokie zastosowania w zakresie polityk rutingowych Tryby pracy: domeny (Proxy brzegowe, rdzeniowe, firmowe) integracja z logiką poziomu aplikacyjnego (poprzez mechanizm skryptów, API,...) bez śledzenia stanu zgłoszenia (bezstanowe - stateless proxy) ze śledzeniem stanu zgłoszenia (stanowy - stateful proxy) 25

26 Serwer Proxy - bez śledzenia stanu (stateless proxy) Własności generyczne - jak proxy stanowy (uwierzytelnienie, ruting,... - por. dalej) po wysłaniu wiadomości nie jest zachowywany jej kontekst (dialog, transakcja) zwiększona efektywność i skalowalność, ale konsekwencje: nie widać związku odpowiedzi z żądaniem - nie można wykorzystywać wiedzy na temat rezultatu wykonania (powodzenia lub nie-) transakcji nie widać związku między wiadomościami i ich retransmitowanymi kopiami - obsługa anomalii leży po stronie stanowych agentów UA lub stanowych proxy nie widać transakcji i dialogów - nie można budować wyrafinowanych usług Zastosowania: głównie rdzeń sieci SNG-SIP 26

27 Serwer Proxy - ze śledzeniem stanu (stateful proxy) Model proxy Rdzeń: logika obsługi dialogu warstwa transakcyjna SIP cel: niezawodne przesyłanie wiadomości transakcje serwerowe i klienckie niektóre funkcje: obsługa Via, obsługa temporyzatorów w tym retransmisja Rdzeń proxy (proxy core object) (ruting, dialog, ) "najlepsza odpowiedź" wiadomości SIP spójnosć transakcji Req A Res Transakcja serwerowa Transakcja(e) SIP transaction layer Transakcja kliencka Transakcja kliencka Transakcja kliencka SIP transport layer Req Z Res Req Y Res Transakcja(e) Req X Res parsowane wiadomości SIP (bez kontroli poprawności logicznej) INVITE 100 Trying 180 Ringing UDP/TCP/SCTP/IP 27

28 Serwer Proxy - ze śledzeniem stanu (stateful proxy) Własności proxy ze śledzeniem stanu zalety - świadomość stanu transakcji i dialogu (usługi!) wady pełna obsługa retransmisji wiadomości, selektywne odwoływanie transakcji, "inteligentna" obsługa powielania żądań (forking) ograniczona wydajność (pamięć, przetwarzanie/przepustowość) złożoność oprogramowania (pamięć transakcji/zgłoszeń, złożone procedury) Dla porównania - stan UA UA przechowuje stan zgłoszeń, w których uczestniczy mimimalny zestaw informacji o stanie zgłoszenia obejmuje: local/remote tag, Call-ID, lokalny/partnerski CSeq, pole RouteSet informacja o stanie medium (np. sendonly, SendReceive, ) Powyższe info opisujące dialog/sesję (a także potrzebne ze względów niezawodnościowych) są pamiętane jeszcze po zakończeniu zgłoszenia. SNG-SIP 28

29 dodatek Stan UA cd. Ciekawostka: odległy (remote) CSeq jest wymagany do rozróżnienia między retransmisją INVITE a tzw. re-invite. re-invite służy do zmiany parametrów istniejącego lub nawiązywanego zgłoszenia. W przypadku re- INVITE zachowana zostaje wartość Call-Id i tag-ów, ale inkrementowana jest wartość CSeq. Dla odróżnienia, w przypadku retransmitowanego INVITE (w SIP obowiązuje strategia soft-state) wszystkie te parametry są takie same jak w poprzednim INVITE. Nawet po zakończeniu zgłoszenia z powodu zagubienia wiadomości stan jest przechowywany co najmniej przez czas 32 sek. (timer) umożliwia to obsługę zabłąkanych wiadomości. SNG-SIP 29

30 Operacje proxy (wybrane) Weryfikacja poprawności żądania (state -ful/-less) składnia schematy URI ftp:..., tel:...) (także: 416 Unsupported URI scheme) Max-Forwards (483 Too many hops) detekcja zapętleń (na podstawie pola Via - por. slajd 14) (482 Loop detected) uwierzytelnienie dedykowane pola nagłówka [WWW-Authenticate, (Proxy)Authorization, ] np. schemat Digest dla nawiązania sesji (jak HTTP digest) A Proxy B INVITE B 407 Proxy Authent. Required + wyzwanie (m.inn. nonce) ACK INVITE B + info uwierzytelniające (np. digest = MD5(user, realm, passwd, nonce, ) ) 100 Trying 200 OK ACK INVITE B 200 OK ACK i wiele innych SNG-SIP 30

31 Operacje proxy, cd. Rola Proxy wyjściowe (outbound proxy) otrzymuje wszystkie żądania UA niezależnie od ich przeznaczenia (Request-URI) adres OutboundProxy jest skonfigurowany u klienta upraszcza klienta, ale i go izoluje/podporządkowuje go (polityki operatorskie) (ważne np. IMS) Polityki (server policy) swoboda w określaniu roli (proxy/redirect, śledzenie, powielanie, uwierzytelnienie...) decyzje oparte na wielu kryteriach (URI, metoda, inne pola, zewnętrzne parametry...) SNG-SIP 31

32 Kierowanie wiadomości Ogólnie: routing aplikacyjny (możliwości indywidualizacji rutingu) Kierowanie wiadomości INVITE główne kroki (por. RFC 3263) 1. krok wstępny: ew. translacja Request-URI i uformowanie wiadomości INVITE 2. określenie URI dla next-hop w warstwie SIP (następny proxy albo UA) Request-URI albo na podstawie nagłówków Path, Service-path 3. określenie transportowego adresu węzła next-hop dla wiadomości (translacja URI dla next-hop na adres transportowy) Ogólnie: sekwencja zapytań NAPTR => SRV => A Ostatecznie: a i => { adres IP, protokół transportowy, port } - adres transportowy zapewniona duża niezawodność, równoważenie obciążeń różne możliwości wykorzystania protokołów transportowych 32

33 kierowanie wiadomości Kierowanie żądań nie-invite w ramach dialogu (określenie next-hop) (też RFC 3263) adres transportowy lub URI znany na podstawie pól nagłówka: Contact-to Route (URI na wierzchołku stosu) wówczas: adres transportowy od razu albo określenie adresu transportowego dla wiadomości wg DNS translacja odpowiedniego pola nagłówka na adres transportowy mechanizm jest ogólny; przydatny w przypadku awarii serwerów proxy;» ale nieodpowiedni dla klientów ukrytych za NAT SNG-SIP 33

34 kierowanie wiadomości - mechanizmy VIA - kierowanie odpowiedzi Via - mechanizm rutingu odpowiedzi w ramach jednej transakcji przykład z przejściem sygnalizacyjnym przez NAT składnia pola Via zapewnia np. identyfikację odpowiedzi dla żądań powielonych (forking por. dalej) przejście sygnalizacji przez NAT (parametry received, rport) RFC RFC 3581 zasady dla Via (w tym NAT) Via: SIP/2.0/UDP darek.tele.pw.edu.pl:5060; rport; branch=jkghy INVITE Request-URI Via: aaa; rport IP: ; 4567 pamiętaj adres po NAT IP: ; 8765 Via: SIP/2.0/TCP sip.tele.pw.edu.pl; Via: SIP/2.0/UDP darek.tele.pw.edu.pl:5060; received= ; rport=8765; branch=jkghy INVITE Request-URI Via: bbb Via: aaa Request-URI aaa bbb ccc NAT OK Via: aaa użyj adresu po NAT Via: bbb Via: aaa OK Via: bbb Via: aaa rport ::= response-port SNG-SIP 34

35 Kierowanie wiadomości - mechanizmy Record-route/Route Mechanizm rutingu źródłowego Record-route/Route (forma source routing, w SIP tzw. loose routing) Typowe użycie: ustalenie ścieżki na poziomie proxy podczas inicjalizacji dialogu (INVITE) wykorzystanie tej ścieżki podczas kolejnych transakcji danego dialogu A B C D E INVITE Record-route: B Record-route: B Record-route: D Record-route: B Record-route: D Record-route: B Record-route: D Record-route: B Record-route: D Record-route: B Record-route: D Record-route: B OK (wg Via) Request Route: B, D Route: D OK (wg Via) Request Route: B Route: D, B SNG-SIP 35

36 Mechanizmy, cd. Nagłówki rutingowe fazy rejestracji (pola nagłówka Path, Service-route) nagłówki ustalane podczas realizacji transakcji REGISTER Path ustawiane w ramach transakcji REGISTER przez te proxy pośrednie, które chcą uczestniczyć w kolejnych dialogach rejestrowanego terminala (RFC 3327) sytuacja: gdy UA jest ukryty za outbound proxy względem REGISTRAR a (IMS/P-CSCF) analogiczne do Record-route; jest nowe tylko dla wstecznej kompatybilności» następnie typowe zastosowanie: Route: <Path> Service-route ustawiane przez REGISTRAR (RFC 3608) lista serwerów proxy z obrębu domeny UA, które są usługowe dla tego UA (zazwyczaj nie outbound), (IMS/S-CSCF) sytuacja: REGISTRAR zna listę proxy usługowych dla UA i umieszcza ją jako Serviceroute w odpowiedzi OK» następnie typowe zastosowanie: Route: <.> <Service-route> Service-route odróżnia serwery proxy macierzyste od tych z Path (które są dowolne); zasadność zastosowania na odpowiedzialność REGISTRAR a kombinacja obu list w kolejnych żądaniach nawiązania dialogu ustawiana przez UA: Route: Path, Service-route na REGISTRAR i UA spada łączna odpowiedzialność za spójność ścieżki ale w ramach samego dialogu wymuszenie ścieżki poprzez Record-route/Route kluczowe znaczenie w IMS, autorstwo 3GPP SNG-SIP 36

37 Operacje proxy cd.2 Powielanie żądań (forking) wysłanie kilku żądań naraz do różnych adresatów Współbieżne, sekwencyjne, mieszane rola proxy stanowego dla forking przykład Usługa lokalizacyjna 1 REGISTER... From: B To: B Contact: B1, B2... User B powielenie współbieżne UA A UA B1 UA B2 INVITE B INVITE B1 (Cseq = x INVITE) INVITE B2 200 OK 200 OK 100 Trying CANCEL 200 OK ACK Stateful Proxy ACK 487 Request terminated (Cseq= x INVITE) ACK 37

38 Proxy - inne elementy Rola DNS w architekturze SIP (RFC 3263) do wyszukiwania składników fizycznych i określania protokołów transportowych oraz ENUM (Electronic Number Mapping System/TElephone NUmber Mapping) translacja numerów telefonicznych E.164 na adresy SIP ENUM is simply the convergence of Public Switched Telephone Networks (PSTN) to Internet Protocol (IP) Networks in other words, the mapping of telephone numbers like ' ', to URIs (Uniform Resource Identifiers, RFC2396), like 'sip:user@sipservice.com using a Domain Name System (DNS)-based architecture. ENUM helps to facilitate such services as Voice over IP (VoIP), and allows network elements to find services on the Internet using only a telephone number. ENUM is also the title of RFC 2916, 3761, the approved protocol documents that discuss the use of DNS for the storage of E.164 numbers and the available services connected to an E.164 number. SNG-SIP 38

39 SIP - inne elementy cd. Wykorzystanie protokołów transportowych przez SIP UDP: szybki, ale zła obsługa przeciążeń, TCP: zapewnia obsługę przeciążeń, ale trudno zgrać timer y TCP z tymi poziomu SIP, ; ma szerokie wsparcie SCTP: keep-alive, elastyczność w sensie trybów pracy, ; mniejsze wsparcie por. Bezpieczeństwo w SIP Mechanizmy stosowane w SIP Mechanizmy aplikacyjne Mechanizmy transportowe Mechanizmy sieciowe HTTP Digest S/MIME TLS IPSec UAC-UAS / UAC-serwer_SIP (choć TLS raczej rzadko por. RFC 5630) serwer_sip serwer_sip (np. w IMS IPSec dla UA P-CSCF) SNG-SIP 39

40 Zakres Podstawy architektury SIP charakterystyka, składniki funkcjonalne, SIP w skrócie - prosty przykład Model zgłoszenia: sesje, dialogi, transakcje Serwery i metody (wiadomości) także zasady kierowania wiadomości Negocjacja medium - SIP i SDP (Session Description Protocol) Współpraca z innymi systemami sygnalizacji (ISUP) Elementy zaawansowane rezerwacja zasobów (przykład przy okazji omawiania wrchitektury IMS) modele zgłoszenia: 3pcc, B2BUA (Back-to-Back UA), sesje wielostronne RFC Framework for Transcoding with the Session Initiation Protocol (SIP) usługi obecności (Presence) i Instant Messaging (por. IETF SIMPLE ważniejsze RFC: 3863, 4479, 4745, 5025 / 3428, 4975, 4976 ) pokonywanie NAT i Firewall Peer-To-Peer SIP (zobaczymy czy wystarczy czasu) SNG-SIP 40

41 Negocjacja medium, SDP Model propozycji/odpowiedzi Req(propozycja) Res-Provisional propozycja ::= proponowany opis sesji czyli zbiór proponowanych mediów (medium = strumień) Klient UA... Res-Provisional(odpowiedź-A) Res-Final (odpowiedź-b) Serwer UA odpowiedź ::= opis akceptowanej sesji czyli zbiór zaakceptowanych strumieni (np. opis jednego strumienia może zawierać wiele kodeków) SDP (Session Description Protocol) cel: przesłanie opisu sesji (struktura przesyłanej informacji) także do modyfikacji parametrów istniejącej sesji Cd SNG-SIP 41

42 cd. składnia SDP: Session Description Protocol (RFC 2327) Conventions for the use of the Session Description Protocol (RFC 3108) Opis sesji Informacje poziomu sesji wersja protokołu SDP inicjator i ID sesji nazwa sesji username, session ID, version, network type, address type, address (inicjatora) o= darek IN IP4 vangogh.tele.pw.edu.pl np. "nr sekwenc." przy modyfikacji cech sesji Opis 1-go medium ID medium i opis transportu atrybuty informacja o połączeniu Opis n-go medium ID medium i opis transportu: media type, port, transport, format m= video RTP/AVP (audio, video, audio/video) atrybuty - specyficzne cechy medium (np. sendonly, recvonly, sendrecv) a=recvonly informacja o połączeniu: network type, address type, connection address c= IN IP4 mserver.tele.pw.edu.pl m= audio RTP/AVP 0 2 a=sendrecv UWAGA: porównać model SIP/SDP z modelem MPEG-DASH, np.

43 SDP - cd.1 Przykład negocjacji A INVITE B... Cseq= 1122 INVITE Content-Length:... Content-Type: application/sdp B v=0 o=darek IN IP4 vangogh.tele.pw.edu.pl c= IN IP4 vangogh.tele.pw.edu.pl t=0 0 m=audio 4444 RTP/AVP 0 2 SIP/2.0 OK (lub 183 Session progress)... Cseq= 1122 INVITE Content-Length:... Content-Type: application/sdp v=0 o=radek IN IP4 spaget.waw.pl c= IN IP4 spaget.waw.pl t=0 0 m=audio 6666 RTP/AVP 2 SNG-SIP 43

44 Zakres Podstawy architektury SIP charakterystyka, składniki funkcjonalne, SIP w skrócie - prosty przykład Model zgłoszenia: sesje, dialogi, transakcje Serwery i metody (wiadomości) także zasady kierowania wiadomości Negocjacja medium - SIP i SDP (Session Description Protocol) Współpraca z innymi systemami sygnalizacji (ISUP) Elementy zaawansowane rezerwacja zasobów (przykład przy okazji omawiania wrchitektury IMS) modele zgłoszenia: 3pcc, B2BUA (Back-to-Back UA), sesje wielostronne usługi obecności (Presence) i Instant Messaging (por. IETF SIMPLE ważniejsze RFC: 3863, 4479, 4745, 5025 / 3428, 4975, 4976 ) pokonywanie NAT i Firewall RFC 5626 Peer-To-Peer SIP (zobaczymy czy wystarczy czasu) SNG-SIP 44

45 Współpraca z innymi systemami sygnalizacji Przykład: współpraca z ISUP (SIP=>ISUP, nawiązanie rozmowy ) więcej np.: A Proxy MGC+MG B INVITE 100 Trying INVITE 100 Trying IAM 183 Session progress m=... a=sendonly 183 Session progress m=... a=sendonly ACM ACK 200 OK m=... a=sendrecv ACK głos jednokierunkowy 200 OK m=... a=sendrecv ANM głos dwukierunkowy SNG-SIP 45

46 Zakres Podstawy architektury SIP charakterystyka, składniki funkcjonalne, SIP w skrócie - prosty przykład Elementy zaawansowane rezerwacja zasobów wykorzystanie PRACK, np. w IMS modele zgłoszenia: 3pcc, B2BUA (Back-to-Back UA), sesje wielostronne, np. (metoda REFER, pole nagłówka Join) RFC Framework for Transcoding with the Session Initiation Protocol (SIP) usługi obecności (Presence) i Instant Messaging (por. IETF SIMPLE ważniejsze RFC: 3863, 4479, 4745, 5025 / 3428, 4975, 4976 ) pokonywanie NAT i Firewall + RFC 5626 Peer-To-Peer SIP (P2P-SIP) (złączenie SIP z wyszukiwaniem opartym na DHT) propozycja: opracować samodzielnie na podstawie Google( Chord: A scalable peer-to-peer look-up protocol for internet applications morris) 46

47 Megaco/H.248 Megaco/H.248 NGN a SIP - interpretacja Warstwa aplikacyjna? Dane konfigur. konkretne role => konkretna architektura (np. IMS w UMTS) np. SS7/IP (czyli SIGTRAN) MGC Serwery SIP SIP MGC SIP MG RTP+RTCP UDP/IP MG SNG-SIP 47

48 Funkcje zarządzania NGN a SIP interpretacji cd. NGN wg ITU-T Rec. Y.2001 Warstwa aplikacyjna domena platform otwartych ANI Aplikacje dostawców Funkcje aplikacyjne Profile usługowe użytkowników Funkcje sterowania sieciowe i usługowe Funk. użytk. końco wych Profile transportowe użytkowników Funkcje sterowania dostępem do sieci Warstwa transportowa Funkcje sterowania zasobami i przyjmowaniem zgł. Transportowe funkcje sterowania Funkcje przetwarzania mediów Inne sieci Funkcje dostępowe Dostępowe funkcje transportowe Funkcje brzegowe Funkcje transferowe Rdzeniowe funkcje transportowe Funkcje bramowe UNI NNI SNG-SIP 48

49 Literatura uzupełniająca - wybór RFC 3261, SIP: Session Initiation Protocol RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers (opis zasad rutingu sip-owego) -draft-ietf-sipping-call-flows-00.txt -draft-ietf-sipping-service-examples-07 -RFC 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples przykładowe sekwencje wiadomości draft-ietf-sipping-cc-framework-xx.txt - A Call Control and Multiparty usage framework for the Session Initiation Protocol RFC Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol Dobre źródło: tamże np. zakładka SIP Architecture SNG-SIP 49