SIP: przesłanki. Standard Internetowy. Wykorzystanie adresacji Internetowej. Wykorzystanie zasad kodowania HTTP

Transkrypt

1 SIP w skrócie

2 SIP: przesłanki Standard Internetowy IETF - RFC 3261 i wiele innych powiązanych norm RFC Wykorzystanie adresacji Internetowej URL, DNS, proxy Użycie bogactwa funkcjonalnego Internetu Wykorzystanie zasad kodowania HTTP Tekstowy protokół Niezależność od protokołów transportowych TCP, UDP, X.25, FR, ATM, Obsługa trybu multicast 2

3 SIP: Session Initiation Protocol Protokół aplikacyjny (tekstowy): ustanawianie, modyfikacja, likwidacja i zarządzanie przebiegiem multimedialnych sesji komunikacyjnych rozwinięcie HTTP i SMTP opracowane przez IETF Multiparty Multimedia Session Control (MMUSIC) WG RFC 3261 (wcześniej 2543bis) Model P2P (peer-to-peer) Alternatywa dla H.323 3

4 SIP aspekt usługowy Mobilność Dostęp do usług z dowolnego urządzenia z dowolnego miejsca w Internecie Obecność Czynnik otwierający nowy wzorzec komunikacji Natychmiastowa komunikacja Usługi głosowe Jakość lepsza niż w PSTN Wideopołączenia i widekonferencja Współpraca grupowa Interaktywne sesje 4

5 Co można zrobić za pomocą protokołu SIP Wykorzystanie środowiska SIP VoIP IM IPTV Audio i wideokonferencja NGN Wbudowanie komunikacji w aplikacje Poprawa produktywności Click to call, IM Zarządzanie połączeniami przez internet Identyfikacja, internet call waiting Poczta głosowa Integracja z procesami biznesowymi Automatyczna generacja połączeń dla scenariuszy współpracy 5

6 Geneza SIP Korzenie koncepcji SIP: Zapraszanie użytkowników do sesji multimedialnych w sieci Mbone Historia 1996 Mark Handley SIP, Henning Schulzrinne - SCIP Zainteresowanie w kręgach akademickich 1998 Początek zainteresowania komercyjnego SIP postrzegany jako realizacja VoIP zgodnie z duchem Internetu 1999 Pierwsza wersja RFC 2543 opublikowana przez IETF Bardzo duży wzrost zainteresowania ze strony usługodawców i dostawców. Uzupełnianie i korekta RFC 2543 kolejne wersje. 2001/10 RFC 2543bis wersja 05 przypominająca standardy ETSI i ITU-T 6

7 SIP historia Opracowany przez Internet Engineering Task Force (IETF) Pomysłodawcy: M. Handley, H. Schulzrinne, E. Schooler i J. Rosenberg Propozycja standardu i norma RFC 2543 w marcu 1999 w grupie roboczej IETF MMUSIC WG Powołanie oddzielnej grupy roboczej SIP WG we wrześniu 1999 Obecnie protokołem SIP zajmują się nowe grupy robocze: SIPPING - aplikacje SIMPLE obecność i natychmiastowa komunikacja (presence and instant messaging) RFC2543bis-09 stał się RFC 3261 w czerwcu 2002 Nowi współautorzy: G. Camarillo, A. Johnston, J. Peterson i R. Sparks Cała specyfikacja napisana od nowa przede wszystkim dla poprawienia czytelności, ale także pewne nowe funkcje Zgodność wstecz z RFC

8 Sieć wykorzystująca protokół SIP Punkty końcowe SIP urządzenia dołączone do Internetu lub sieci IP obsługujące SIP Telefony stacjonarne i komórkowe z SIP UA Aplikacje na PC i PDA SIP UA Bramy sieciowe Serwery SIP węzły sieci realizujące zestaw funkcji na żądanie punktów końcowych SIP Mogą inicjować żądania Mogą być zlokalizowane w innej sieci 8

9 SIP jako protokół rendezvous Możliwości punktu końcowego SIP UA Znajdowanie drugiego UA Znajdowanie serwera SIP, który umożliwia znalezienie drugiego UA Ustanowienie sesji medialnej poprzez wymianę oferty/odpowiedzi Modyfikacja trwającej sesji medialnej poprzez wymianę oferty/odpowiedzi Wyrażenie możliwości i funkcji UA Żądanie wykonania działań związanych ze sterowaniem sesją przez (zdalną) stronę trzecią Uzyskanie informacji o statusie, możliwościach funkcjonalnych i dostępności drugiego UA Wymiana informacji sygnalizacyjnej w trakcie sesji Wymiana wiadomości natychmiastowych z innymi UA 9

10 SIP - charakterystyka Typy adresacji: Internetowy adres sip adres Telefoniczny Rejestracja Numer telefoniczny E.164 Użytkownik może się zarejestrować wykorzystując swój ID w celu uzyskania dostępu do swoich danych i usług, niezależnie od rejestracji urządzenia 10

11 SIP: Przesłanki Łatwość implementacji Zasada IETF KISS (Keep It Simple Stupid!) Uwzględnienie wymagań i możliwości Internetu Uniknięcie narzucenia konkretnej architektury fizycznej i konkretnych usług Uniwersalna funkcjonalność Wykorzystanie najlepszych standardów IETF URL MIME RFC 822 Skalowalność 11

12 SIP:architektura Uogólnienie architektury internetowej pajęczyny WWW Prostota: model klient-serwer zasada żądanie-odpowiedź (Request - Response) Serwery Proxy, Redirect, Registrar Serwery aplikacji Konsekwencje: Upowszechnienie kreacji usług SIP Wiele SIP API (SIP servlets, CPL oparty na XML, JAIN) Rozwój narzędzi do projektowania usług (CGI) 12

13 SIP - koncepcja architektury Usługi Katalogi: DNS ENUM Ustanawianie sesji: SIP SDP Transport: RTP AAA: Radius Diameter SDP: Session Description Protocol RTP: Real-time Transport Protocol Sieć IP Ruting i QoS zapewniane przez sieć IP Punkty końcowe PSTN Brama PSTN Telefon IP Aplikacja VoIP System poczty głosowej 13

14 SIP stos protokołów Media HTTP H.323 SIP RTP RTCP TCP SCTP IPv4/IPv6 UDP PPP AALx Ethernet GPRS SONET V.x ATM 14

15 SIP: możliwości funkcjonalne Mobilność użytkownika: określenie bieżącego miejsca jego pobytu Charakterystyka możliwości komunikacyjnych użytkownika: negocjacja funkcjonalności i parametrów sesji (np. opis typu mediów - SDP) Dostępność: określenie gotowości użytkownika do uczestnictwa w sesji Zestawianie połączeń: Nadzorowanie połączenia - sesji przekazywanie połączeń, dołączanie nowych uczestników, odłączanie uczestników i rozłączanie połączeń 15

16 Trapez SIPowy DNS Server Location Server DNS Outbound Proxy Server SIP Inbound Proxy Server SIP RTP SIP User Agent A User Agent B 16

17 SIP: elementy architektury User Agent Client - UAC systemy końcowe wysyłają żądania SIP (np. żądanie ustanowienia połączenia) User Agent Server - UAS odbiera żądania połączeń wysyłane przez innych agentów wysyła odpowiedzi w imieniu użytkownika User Agent - Agent Użytkownika (typowy terminal) UAC + UAS Redirect Server Przekierowuje użytkownika na inny serwer Proxy Server reprezentuje żądanie do innego serwera. Może rozwidlić żądanie na wiele serwerów, budując drzewo przeszukiwania Registrar odbiera zgłoszenia rejestracyjne UA (User Agents) Location Server Baza danych o użytkownikach 17

18 SIP: adresacja Format zbliżony do formatu adresów lub SIP-URL = sip: ] hostport url-parameters [headers]: 18

19 SIP URI (Uniform Resource Indicators) Dwa warianty URI: (SIP URI) Najpopularniejsza forma wprowadzona w RFC 2543 sips:henry@siptest.wcom.com (Secure SIP URI) Nowa forma wprowadzona w RFC 3261 Wymaga TLS na TCP jako mechanizmu transportowego zapewniającego ochronę informacji Dwa typy SIP URI: Address of Record (AOR) (identyfikuje użytkownika) sip:henry@wcom.com (wymaga rekordów DNS SRV w celu lokalizacji serwerów SIP w domenie wcom.com) Fully Qualified Domain Name (FQDN) lub Contact (identyfikuje urządzenie) sip:henry@ lub sip:henry@cube43.lab.wcom.com (nie wymaga roztrzygania przy rutingu) 19

20 SIP i URI URI Uniform Resource Identifier - uogólnienie URL Adresy SIP są także identyfikatorami URL!!! SIP umożliwia użycie dowolnego URI w miejscu, w którym może być użyty SIP URL Zastosowania: przekierowywanie połączeń na stronę WWW przekierowywanie połączeń na złożone adresy URL w celu udostępnienia serwera WWW z bazą danych 20

21 Podstawowe wiadomości (metody) SIP INVITE inicjowanie ustanowienia sesji BYE zakończenie trwającej sesji OPTIONS zapytanie o opcje i funkcjonalność serwera lub UA CANCEL anulowanie żądania w toku ACK potwierdzenie finalnej odpowiedzi na INVITE REGISTER rejestracja URI użytkownika w serwerze rejestrowym SIP (związanie URI urządzenia z AOR) 21

22 Podstawowe wiadomości (metody) SIP INVITE BYE OPTIONS CANCEL ACK Inicjowanie ustanowienia sesji Zakończenie trwającej sesji Zapytanie o opcje i funkcjonalność serwera lub UA Anulowanie żądania w toku Potwierdzenie finalnej odpowiedzi na INVITE RFC 3261 RFC 3261 RFC 3261 RFC 3261 RFC 3261 REGISTER Rejestracja URI użytkownika w serwerze rejestrowym SIP (związanie URI urządzenia z AOR) RFC

23 Dodatkowe wiadomości (rozszerzenia) SIP INFO PRACK UPDATE REFER SUBSCRIBE PUBLISH NOTIFY MESSAGE Transport sygnalizacji w trakcie sesji Potwierdzenie prowizorycznej odpowiedzi Aktualizacja informacji o stanie sesji Transfer użytkownika pod adres określony przez URI Żądanie zaabonowania powiadamiania o zdarzeniach Przekazanie informacji o zmianie statusu do serwera Transport powiadomienia o zaabonowanym zdarzeniu Transport treści wiadomości natychmiastowych RFC 2976 RFC 6086 RFC 3262 RFC 3311 RFC 3515 RFC 3265 RFC 3903 RFC 3265 RFC

24 SIP obsługiwane schematy URI sip:, sips: tel: pres: im: http: xmpp: Adres SIP i bezpieczny adres SIP Numery telefoniczne i sekwencje wybierania Zasób obecności Zasób wymiany wiadomości natychmiastowych Hyper Text Transport Protocol dla stron internetowych Jabber IM i URI związane z obecnością RFC 3261 RFC 3999 RFC 3861 RFC 3861 RFC 2616 ID H323:, h323: URL H.323 RFC

25 SIP: odpowiedzi Kod Opis Przykłady 1xx 2xx 3xx 4xx 5xx 6xx Informacyjne żądanie odebrane, trwa kontynuacja przetwarzania żądania. Sukces akcja odebrana, zrozumiana i Zaakceptowana. Przekierowanie konieczne podjęcie dalszych działań w celu zakończenia żądania. Błąd klienta błędna postać żądania lub niemożność realizacji żądania przez dany serwer. Błąd serwera serwer nie był w stanie zrealizować żądania. Globalny błąd żądanie nie do zrealizowania przez dostępne serwery. 180 Ringing 181 Call is Being Forwarded 200 OK 300 Multiple Choices 302 Moved Temporarily 401 Unauthorized 404 Not found 408 Request Timeout 503 Service Unavailable 505 Version Not Suported 600 Busy Everywhere 603 Decline 25

26 2Callee SIP: zestawienie połączenia w trybie Proxy Serwer DNS Serwer lokalizacji Caller@sip.com DNS Srv Query? onet.com Reply : IP Address of onet.com SIP Server INVITE sip:bob@onet.com From: sip:caller@sip.com To: sip:bob@onet.com Call-ID: @sip.com 1 bob@ INVITE sip:bob@ From: sip:caller@sip.com To: sip:bob@onet.com Call-ID: @sip.com 4 bob@onet.com OK From: sip:caller@sip.com To: sip:bob@onet.com Call-ID: @sip.com PROXY 200 OK From: sip:caller@sip.com To: sip:bob@onet.com Call-ID: @sip.com 5 7 ACK sip:bob@onet.com 8 Media 26

27 SIP Proxy Pośredni element, który spełnia rolę zarówno serwera jak i klienta w celu realizacji żądań w imieniu innych klientów Ruting jako główna funkcja Przezroczystość dla urządzeń końcowych Interpretuje i jeśli zachodzi potrzeba modyfikuje żądanie przed przekazaniem go dalej Nagłówki, które mogą podlegać modyfikacji: Request-URI Via Record-Route Route Max-Forwards Proxy- Authorization 27

28 Callee SIP: serwer przekierowujący - Redirect LOCATION SERVER Caller@sip.com 2 Callee@home.com 3 1 INVITE Callee@example.com Moved Temporarily Contact:Callee@home.com 5 ACK Callee@example.com PROXY 6 INVITE Callee@home.com Callee@home.com OK INVITE 8 ACK Callee@home.com 28

29 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 301 Moved permanently 302 Moved temporarily 305 Use proxy 380 Alternative service 29

30 Serwer Registrar Serwer akceptujący rozkazy REGISTER i przekazujący zawarte w nich informacje do usługi lokalizacyjnej w zarządzanej przez siebie domenie. Zapewnienie odwzorowania miedzy zewnętrznie znanym adresem(ami) użytkownika a jego obecnym adresem(ami) fizycznym(i). Pobieranie aktualnych odwzorowań (odczytywanie). Usługa lokalizacyjna: baza danych (LDAP, SQL,...) 30

31 SIP Registrar Location Database Rejestracja ustanawia obecność przez 1 godzinę użytkownika: sip:marek@sredniawa.eu i wiąże ten adres SIP z bieżącą jego lokalizacją: #2 REGISTER sip:sredniawa.eu SIP/2.0 From: sip:marek@sredniawa.eu To: sip:marek@sredniawa.eu Contact: <sip: > Expires: 3600 #1 #3 SIP/ OK SIP Registrar (domena sredniawa.eu) 31

32 SIP wybrane nagłówki From Pole wskazujące SIP URL nadawcy. From: Dana Scully From: tag= f: sip: Max-Forwards Licznik zmiejszany przez każdy serwer proxy przy przekazywaniu wiadomości. Wyzerowanie licznika generuje odpowiedź 483 Too Many Hops Max-Forwards: 10 Priority Priorytet wiadomości. Priority: normal Priority: emergency Record-Route Dodawany do żądania przez serwer proxy, który musi się znaleźć na ścieżce wiadomości w przyszłości.. Record Route: sip.mci.com Require Wskazuje wymagane opcje sesji. Require: local.telephony Response-Key Zawiera klucz PGP key dla oczekiwanej zaszyfrowanej odpowiedzi. Response-Key: pgp info Retry-After Wskazuje termin kiedy zasób będzie dostęny. Retry-After: 3600 Retry-After: Sat, 01 Jan :01 GMT 32

33 SIP wybrane nagłówki Route Określa trasę wiadomości. Route: orinoco.brooks.net Subject To Unsupported Przekazuje pomocniczą informację o typie sesji. Obowiązkowe pole określające adresata sesji jego SIP URL. Listuje funckje nie obsługiwane przez serwer. Subject: More about SIP s: You d better answer! To: Fox Mulder <sip:mulder@ lonegunman.org> To: sip: @operator.mci.com; tag=314 t: sip:1800collect@telecom.mci.co m; tag=52 Unsupported: tcap.telephony Via Wskazuje ścieżkę, przez Via: SIP/2. 0/UDP sip.mfs.com którą przeszła wiadomość. Via: SIP/2.0/TCP uunet.com v: SIP/2.0/UDP Warning Kod i treść ostrzeżenia. Warning: 331 Unicast not available 33

34 Nagłówki SIP związane z rutingiem Request-URI: bieżące położnie, może się zmienić na ścieżce sygnalizacyjnej Contact: występuje w INVITE / OPTIONS / ACK / REGISTER i odpowiedziach. Wskazuje bezpośredni adres odpowiedzi, na który kolejne transakcje będą wysyłane. Via: Identyfikuje lokalizację gdzie ma być wysłana odpowiedź Record-Route: wstawiany przez proxy w żądaniu w celu wymuszenia aby przyszłe żądania w dialogu były kierowane przez dany węzeł proxy Route: służy do wymuszania rutingu żądania przez podana listę proxy 34

35 Ruting w protokole SIP Ruting żądań inicjujących sesję Oferowanie sesji adresatowi (np. dzwonek - informowanie o połączeniu przychodzącym ) Ruting odpowiedzi Poinformowanie inicjującego sesję o reakcji adresata sesji Ruting kolejnych żądań Monitotowanie przez serwery Proxy postępu sesji lub jej zakończenia 35

36 Ruting żądań i odpowiedzi Serwery Proxy przechowują informację o stanie transakcji maintain, która musi być usunięta w pewnych punktach Odpowiedzi przechodzą trasą żądań Każdy węzeł proxy dodaje swój nagłówek Via Proxy - P1 Proxy P2 Proxy P3 INVITE sip:bob@iptel.org Via: P1 INVITE sip:bob@iptel.org Via: P1 Via: P2 INVITE sip:bob@iptel.org Via: P1 Via: P2 Via:P3 INVITE sip:bob@iptel.org 36

37 Ruting żądań i odpowiedzi Odpowiedzi przechodzą ścieżkę wyznaczoną przez odwróconą listę adresów serwerów Proxy z nagłówków Via Proxy - P1 Proxy P2 Proxy P3 200 OK 200 OK Via: P1 200 OK Via: P2 Via: P1 200 OK Via: P3 Via: P2 Via: P1 ACK BYE 37

38 Ruting kolejnych żądań Serwery Proxy mogą być zainteresowane obserwacją wszystkich żądań związanych z poszczególnymi sesjami (monitorowanie, taryfikacja, realizacja usług) Żądania należące do tej samej sesji muszą przechodzić przez te serwery Proxy Każdy zainteresowany serwer Proxy dodaje swój nagłówek Record-route Proxy - P1 Proxy P2 Proxy P3 INVITE sip:bob@iptel.org Via: P1 Record-Route: P1 INVITE sip:bob@iptel.org Via: P1 Via: P2 Record-Route: P1 INVITE sip:bob@iptel.org Via: P1 Via: P2 Via: P3 Record-Route: P1 Record-Route: P3 INVITE sip:bob@iptel.org 38

39 Ruting żądań i odpowiedzi Proxy - P1 Proxy P2 Proxy P3 200 OK 200 OK Via: P1 Record-Route: P1 Record-Route: P3 200 OK Via: P2 Via: P1 Record-Route: P1 Record-Route: P3 200 OK Via: P3 Via: P2 Via: P1 Record-Route: P1 Record-Route: P3 39

40 Ruting żądań i odpowiedzi Kolejne żądania przechodzą przez tylko te węzły Proxy, które wcześniej dodały nagłówek Record-route Proxy - P1 Proxy P2 Proxy P3 ACK Via: P1 Record-Route: P3 ACK Record-Route: P1 Record-Route: P3 ACK Via: P3 Via: P1 40

41 Obsługa BYE bez i z Record route Bez Record Route UA1 SIP Proxy UA2 Z Record Route UA1 SIP Proxy UA2 BYE 200 OK BYE BYE 200 OK 200 OK 41

42 Nagłówek Route Wymusza ruting żądania przez podaną listę serwerów proxy Potwierdzenie odpowiedzi ACK na żądanie INVITE, musi zawierać pola nagłówka Route jeśli one wystąpiły w INVITE Przykłady: Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr> Address wskaźnik Loose Routing Route: <sip:server10.biloxi.com;lr> A B INVITE D INVITE D Route B,C Route C INVITE D C D 42

43 Protokoły związane z SIP SDP Session Description Protocol Tekstowa notacja służąca do opisu sesji medialnych Dane przekazywane w treści wiadomości SIP Wykorzystuje profile RTP/AVP dla najczęściej spotykanych typów mediów Zdefiniowany w normie RFC 2327 RTP Real-time Transport Protocol Wykorzystywany do trasportu pakietów mediów po IP RTP dodaje nagłówek zawierający: Nazwę źródła mediów Stempel czasowy Typ kodeka Numer sekwencyjny Zdefiniowany w RFC 1889 (H. Schulzrinne i inni) Profile zdefiniowane w RFC

44 Struktura wiadomości SIP - INVITE INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP :5060 To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: @ CSeq: 1 INVITE Contact: <sip:usera@ > Content-Length: 126 Nagłówek To nazwę użytkownika (User A), następnie URL inicjatora w nawiasach kątowych <> (sip:usera@here.com) 44

45 Struktura wiadomości SIP - INVITE INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP :5060 To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: @ CSeq: 1 INVITE Contact: <sip:usera@ > Content-Length: 126 Nagłówek Call-ID zawiera unikalny identyfikator sesji. Tworzą go unikalny lokalny losowo wygenerowany identyfikatora, i unikalna globalnie nazwa węzła (host) lub adres IP, tworząc unikalny łańcuch. Wszystkie żądania i odpowiedzi w trakcie sesji mają ten sam Call-ID. Unikalne łańcuchy Call-ID mogą być generowane również w inny sposób. 45

46 Struktura wiadomości SIP - INVITE INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP :5060 To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: @ CSeq: 1 INVITE Contact: <sip:usera@ > Content-Length: 126 CSeq stanowi numer sekwencyjny, zawierający liczbę całkowitą (w tym przypadku 1), a następnie oddzieloną odstępem nazwę metody (INVITE). Każde kolejne żądanie podczas sesji ma kolejny wyższy numer sekwencyjny CSeq. Obie strony sesji utrzymują oddzielne lokalne liczniki CSeq. 46

47 Struktura wiadomości SIP - INVITE INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP :5060 To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: @ CSeq: 1 INVITE Contact: <sip:usera@ > Content-Length: 126 Nagłówek Contact zawiera jeden lub więcej adresów SIP URL, które dostarczają informację dla drugiej strony uczestniczącej w sesji pozwalające skontaktować się z użytkownikiem A. 47

48 Struktura wiadomości SIP - INVITE INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP :5060 To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: @ CSeq: 1 INVITE Contact: <sip:usera@ > Content-Length: 126 Content-Length zawiera długość treści wiadomości wyrażoną w oktetach (bajtach) (126), która następuje po liście nagłówków SIPowych i jest oddzielona od nich pojedynczym pustym wierszem (CRLF). Content- Length równe 0 wskazuje, że wiadomość nie zawiera treści (składa się tylko z nagłówków). 48

49 Przykład sesji SIP SIP UA (A) Proxy Server Location Services SIP UA (B) 1 INVITE (SDPo) 2 Location Lookup Lookup Result Trying 180 Ringing 200 OK (SDP T ) INVITE (SDPo) 180 Ringing 200 OK (SDP T ) 6 8 Inicjowanie sesji 10 ACK Dwukierunkowa ścieżka dla głosu Sesja w toku 11 BYE 200 OK 12 Kończenie sesji 49

50 Negocjacja mediów Negocjacja mediów przy ustanawianiu sesji Model oferta-odpowiedź UA proponuje jeden lub kilka typów mediów, a drugi UA odpowiadając akceptuje bądź odrzuca jeden lub więcej proponowanych typów mediów Sekwencja - INVITE/200/ACK Dalsze negocjacje i zmiana typu mediów za pomocą ponownego żądania INVITE w trakcie wcześniej ustanowionej sesji Wykorzystanie SDP do opisu mediów Ograniczone możliwości negocjacji mediów Prace nad SDPng Wykorzystanie protokołu SAP do organizacji multimedialnych sesji komunikacyjnych w Internecie 50

51 SDP: negocjacja - model propozycja - odpowiedź Request (propozycja) Klient Res-Provisional Res-Provisional (odpowiedź-a) Res-Final (odpowiedź-b) Serwer propozycja - uporządkowany zbiór proponowanych sesji {opis strumieni} odpowiedź - (jeden) opis akceptowanej sesji opis strumieni 51

52 SDP RFC parametry v= (protocol version) o= (originator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* ( address) p=* (phone number) c=* (connection information -- not required if included in all media) b=* (zero or more bandwidth information lines) One or more time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) t= (time the session is active) r=* (zero or more repeat times) m= (media name and transport address) i=* (media title) c=* (connection information -- optional if included at session level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines) 52

53 Oferta-odpowiedź zasady Odrzucenie oferowanego opisu strumienia mediów W odpowiedzi numer portu = 0 dla odrzucanego strumienia Nowe strumienie mediów tworzone przez: Nowe, dodatkowe opisy mediów poniżej istniejących, lub Ponowne wykorzystanie szczeliny używanej przez stary strumień medialny, który został odrzucony przez ustawienie nr portu =0 Istniejące strumienie mediów są usuwane przez stworzenie nowego opisu w SDP i podanie nr portu = 0 Strumień mediów można zawiesić, np. zażądać tymczasowo jednego lub więcej strumieni w trybie unicast, przez: Oznaczenie dotychczasowego strumienia mediów z sendrecv na sendonly Oznaczenie dotychczasowego strumienia mediów z recvonly na inactive 53

54 SDP - oferta-odpowiedź przykład Oferta SDP v=0 o=alice IN IP4 host.anywhere.com s= c=in IP4 host.anywhere.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video RTP/AVP 31 a=rtpmap:31 H261/90000 m=video RTP/AVP 32 a=rtpmap:32 MPV/90000 Odpowiedź SDP v=0 o=bob IN IP4 host.example.com s= c=in IP4 host.example.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video RTP/AVP 32 a=rtpmap:32 MPV/

55 Modyfikacja sesji: re-invite Modyfikacja ustanowionej sesji przez ponowne użycie metody INVITE zmiana: mediów typu sesji używanych typów kodeków źródłowych adresów IP numeru portu 55

56 Modyfikacja sesji SIP UA SIP UA SIP UA SIP UA 1 INVITE sdp1 Niepowodzenie re-invite nie powoduje zakłócenia trwającej sesji Ringing OK sdp2 4 ACK Media Session Powodzenie drugiego re-invite ustanawia nową 5 INVITE sdp2 sesję medialną, która zastępuje poprzednią Not Acceptale 7 ACK 8 INVITE sdp OK sdp1 10 ACK New Media Session 56

57 Model stanowy - serwer Initial INVITE 1xx CANCEL 200 INVITE 1xx Call Proceeding status change 1xx BYE 200 INVITE status Failure failure >= 300 max(t1*2 n, T2) status Callee Answer 2xx Success INVITE status 32s - event message sent ACK - ACK - Confirmed BYE 200 BYE

58 Model stanowy - klient 7 INVITE sent - T1*2 n INVITE Initial Calling - INVITE give up BYE 1xx ACK Call Proceeding 1xx ACK give up BYE event request sent ACK Completed 32s (for proxy) 58

59 SIP Przykładowe scenariusze zgłoszeń Zgłoszenie - udane Zgłoszenie - nieudane Subskrypcja obecności Rejestracja Powiadomienie o obecności Wymiana wiadomości natychmiastowych Zgłoszenie udane Zawieszenie zgłoszenia Przekazanie zgłoszenia Szczegółowe przykłady opisane w normach IETF: RFC SIP Basic Call Flow Examples RFC SIP Public Switched Telephone Network (PSTN) Call Flows SIP Service Examples I-D: A. Johnston et al 59

60 Sesja SIP DNS Server Location Server Outbound Proxy Server 1. INVITE Contact: A SDP A Trying Inbound Proxy Server 1. A wybiera identyfikator SIP AOR URI sip:b@wcom.com. Agent użytkownika A wysyła INVITE do serwera Outbound Proxy. 2. Outbound Proxy wysyła odpowiedź 100 Trying User Agent A User Agent B (nie dołączony do sieci) 60

61 Sesja SIP DNS Server Location Server 3. DNS Query: wcom.com? Outbound Proxy Server 1. INVITE Contact: A SDP A Trying 4. Response: Inbound Proxy Server 3. Outbound Proxy inicjuje zapytanie do DNS w celu znalezienia serwera proxy dla domeny wcom.com 4. DNS odpowiada adresem IP serwera Proxy dla domeny wcom.com User Agent A User Agent B (nie dołączony do sieci) 61

62 Sesja SIP DNS Server Location Server 3. DNS Query: wcom.com? Outbound Proxy Server 1. INVITE Contact: A SDP A 4. Response: INVITE Contact: A SDP A Trying Inbound Proxy Server 5. Outbound Proxy wysyła wiadomość INVITE do serwera Inbound Proxy 6. Inbound Proxy wysyła odpowiedź 100 Trying Trying User Agent A User Agent B (nie dołączony do sieci) 62

63 Sesja SIP DNS Server Location Server 3. DNS Query: wcom.com? Outbound Proxy Server 1. INVITE Contact: A SDP A Trying 4. Response: INVITE Contact: A SDP A Trying 7. LS Query: B? 8. Response: Not Signed In Inbound Proxy Server 7. Inbound Proxy komunikuje się z Location Server 8. Location Server odpowiada Not Signed In User Agent A User Agent B (nie dołączony do sieci) 63

64 Sesja SIP DNS Server Location Server 3. DNS Query: wcom.com? Outbound Proxy Server 1. INVITE Contact: A SDP A Trying 4. Response: Trying 7. LS Query: B? 8. Response: Not Signed In 5. INVITE Contact: A SDP A Temporarily Unavailable 10. ACK Inbound Proxy Server 9. Inbound Proxy wysyła odpowiedź 480 Temporarily Unavailable 10. Outbound Proxy wysyła odpowiedź ACK User Agent A User Agent B (nie dołączony do sieci) 64

65 Sesja SIP DNS Server Location Server 3. Zapytanie do DNS : wcom.com? Outbound Proxy Server 4. Odpowiedź: INVITE Contact: A SDP A Trying 7. Zapytanie do LS : B? 8. Response: Not Signed In Inbound Proxy Server 11. Outbound Proxy przekazuje odpowiedź 480 do A. 12. A wysyła odpowiedź ACK 1. INVITE Contact: A SDP A Trying Temporarily Unavailable 10. ACK Temporarily Unavailable 12. ACK User Agent A User Agent B (nie dołączony do sieci) 65

66 SIP - obecność DNS Server Presence Server Outbound Proxy Server 1. SUBSCRIBE 2. SUBSCRIBE 3. SUBSCRIBE Inbound Proxy Server 1. A chce być informowany o statusie obecności B i w tym celu subskrybuje informację za pomocą wiadomości SUBSCRIBE 2. Outbound Proxy przekazuje wiadomość do Inbound Proxy 3. Inbound Proxy przekazuje wiadomość do serwera obecności B User Agent A User Agent B (nie dołączony do sieci) 66

67 SIP - obecność DNS Server Presence Server 3. SUBSCRIBE OK Outbound Proxy Server 1. SUBSCRIBE 2. SUBSCRIBE OK Inbound Proxy Server 4. Presence Server zezwala na subskrypcję wysyłając 200 OK. 5. i OK przekazywana zwrotnie do A OK User Agent A User Agent B (nie dołączony do sieci) 67

68 SIP - obecność DNS Server Presence Server Outbound Proxy Server OK 7. NOTIFY <Not Signed In> 8. NOTIFY <Not Signed In> OK Inbound Proxy Server 7. Presence Server wysyła wiadomość NOTIFY zawierającą status obecności B (nie dołączony do sieci). 8. i 9. NOTIFY jest zwracana doa 9. NOTIFY <Not Signed In> 10. A potwierdza odbiór powiadomienia 200 OK OK 11. i OK jest przekazywana zwrotnie do serwera obecności (Presence Server) B User Agent A User Agent B (nie dołączony do sieci) 68

69 SIP - Rejestracja Outbound Proxy Server DNS Server 2. Update database: B = B@ REGISTER Contact: B@ Location Server Outbound Proxy Server 1. B włącza swój telefon SIPowy który wysyła wiadomość REGISTER zwierającą identyfikator FQDN URI agenta użytkownika (UA) B 2. Wiadomość aktualizująca bazę danych jest wysyłana do Location Server User Agent A User Agent B 69

70 SIP - Rejestracja Outbound Proxy Server DNS Server 2. Update database: B = B@ Location Server 3. OK Outbound Proxy Server 3. Potwierdzenie aktualizacji bazy danych Location Server 4. Potwierdzenie rejestracji za pomocą odpowiedzi 200 OK 1. REGISTER Contact: B@ OK Contact: B@ User Agent A User Agent B 70

71 SIP - obecność DNS Server Presence Server Outbound Proxy Server 15. NOTIFY <Signed In> OK User Agent A 14. NOTIFY <Signed In> OK 13. NOTIFY <Signed In> OK User Agent B Inbound Proxy Server 13. Presence Server dowiaduje się o nowym statusie B od Location Server i wysyła wiadomośc NOTIFY zawierającą nowy status B (Signed In). 14. i 15. NOTIFY przekazywana zwrotnie do A 16. A potwierdza odbiór powiadomienia za pomocą 200 OK. 17. i OK jest przekazywana zwrotnie do Presence Server. 71

72 SIP Natychmiastowa komunikacja Outbound Proxy Server 1. MESSAGE <Czy możesz rozmawiać?> OK DNS Server 2. MESSAGE <Czy możesz rozmawiać?> OK Location Server 3. LS Query: B? 4. Response: 5. MESSAGE <Czy możesz rozmawiać?> Inbound Proxy Server 1. A wysyła natychmiastową wiadomośc do B czy możesz rozmawiać? w żądaniu MESSAGE 2., 3. i 4. Żądanie MESSAGE jest przekazywane, i zapytanie kierowane do Location Server 5. Inbound Proxy przekazuje wiadomość MESSAGE do B. 6. User Agent B odpowiada 200 OK. 7. i OK jest przekazywana zwrotnie do A OK User Agent A User Agent B 72

73 SIP Natychmiastowa komunikacja Inbound Proxy Server Location Server 5. LS Query: A? 6. Odpowiedź: 7. MESSAGE <Tak> OK 4. MESSAGE < Tak> OK 2. Zapytanie do DNS: mci.com? 1. MESSAGE < Tak> DNS Server 3. Odpowiedź: Outbound Proxy Server OK 1. B wysyła natychmiastową wiadomośc Tak w MESSAGE wysyłanej do AOR URI A 2. i 3. Zapytanie do DNS Server 4. Outbound Proxy przekazuje MESSAGE do Inbound Server. 5. i 6. Zapytanie do Location Server 7. Inbound Proxy przekazuje wiadomość do A. 8. User Agent A odpowiada 200 OK. 9. i OK jest przekazywana zwrotnie do B User Agent A User Agent B 73

74 SIP próba zgłoszenia Outbound Proxy Server 1. INVITE Contact: A SDP A Trying DNS Server Location Server 5. LS Query: B 6. Response: sip:b@ INVITE Contact: A SDP A Trying 7. INVITE Contact: A SDP A Inbound Proxy Server A ponawia żądanie INVITE do B które przechodzi przez 2 serwery Proxy 6. Location Server odpowiada identyfikatorem FQDN SIP URI telefonu SIPowego B 7. Inbound Proxy Server przekazuje INVITE do telefonu SIPowego B User Agent A User Agent B 74

75 SIP zestawienie połączenia DNS Server Location Server Outbound Proxy Server Ringing Inbound Proxy Server 8. User Agent B sygnalizuje połączenie B i wysyła odpowiedź 180 Ringing Ringing Ringing 9. i Ringing jest przekazywane zwrotnie do A User Agent A User Agent B 75

76 SIP zestawienie połączenia DNS Server Location Server Outbound Proxy Server Ringing Ringing OK Contact: B SDP B OK Contact: B Ringing SDP B Inbound Proxy Server OK Contact: B SDP B 11. B przyjmuje zgłoszenie UA B wysyła odpowiedź 200 OK 12. i OK jest przekazywana zwrotnie do A User Agent A User Agent B 76

77 SIP zestawienie połączenia DNS Server Location Server Outbound Proxy Server Ringing 14. ACK Ringing OK Contact: B SDP B OK Contact: B Ringing SDP B Media (RTP) Inbound Proxy Server OK Contact: B SDP B 14. ACK jest wysyłane przez A aby potwierdzić zestawienie połączenia omijającego serwery proxy Rozpoczęcie sesji medialnej między A i B User Agent A User Agent B 77

78 SIP - zawieszenie (re-invite) DNS Server Location Server 15. B zawiesza A wysyłając re-invite. 16. A potwierdza 200 OK. 17. B wysyła ACK to A. Outbound Proxy Server Inbound Proxy Server brak strumienia mediów między A i B. 15. INVITE SDP a=sendonly OK SDP A User Agent A 17. ACK User Agent B 78

79 SIP przekierowanie zgłoszenia DNS Server Location Server Outbound Proxy Server Inbound Proxy Server 18. B przekazuje A do C używając REFER. 19. Transfer jest akceptowany przez A za pomocą odpowiedzi 202 Accepted 18 REFER Refer-To: sip:c@wcom.com Accepted User Agent A User Agent B 79

80 SIP przekierowanie zgłoszenia Outbound Proxy Server 1. INVITE Contact: A Ref-By: B SDP A Trying DNS Server Location Server 5. Zapytanie do LS : C? 6. Odpowiedź: sip:c@ INVITE Contact: A Ref-By: B SDP A Inbound Proxy Server Trying 7. INVITE Contact: A Ref-By: B SDP A User Agent C 1. do 5. A wysyła nowe INVITE do C które przechodzi przez 2 serwery Proxy 6. Location Server odpowiada identyfikatorem FQDN SIP URI telefonu SIPowego C 7. Inbound Proxy Server przekazuje INVITE do telefonu SIPowego C User Agent A User Agent B 80

81 SIP przekierowanie zgłoszenia Outbound Proxy Server Ringing 14. ACK DNS Server Ringing OK Contact: C SDP C OK Contact: C Ringing SDP C Media (RTP) Location Server Inbound Proxy Server OK Contact: C SDP C User Agent C 8. UA C sygnalizuje C i wysyła odpowiedź 180 Ringing 9. i Ringing jest przekazywane zwrotnie do A. 11. C przyjmuje zgłoszenie call i wysyła odpowiedź 200 OK 12. i OK jest zwrotnie przekazywana do A. 14. A wysyła ACK aby potwierdzić zestawienie połączenia. Rozpoczęcie sesji między A i C User Agent A User Agent B 81

82 SIP przekierowanie zgłoszenia DNS Server Location Server Outbound Proxy Server 20. NOTIFY <200 OK> OK Inbound Proxy Server 20. Powiadomienie o udanym transferze wysyłane do B w wiadomości NOTIFY 21. B wysyła odpowiedź 200 OK na NOTIFY 22. B rozłącza się wysyłając BYE 23. Wysyłane jest 200 OK jako odpowiedź na BYE User Agent A 22. BYE OK User Agent B 82

83 SIP przykład szczegółowy Główny przykład RFC 3261

84 84

85 i. Żądanie REGISTER: od UA Boba do serwera Registrar biloxi.com 85

86 ii. Odpowiedź 200 OK: od serwera Registrar biloxi.com do UA Boba 86

87 1. Żądanie INVITE: od UA Alice do serwera Proxy atlanta.com 87

88 2. Żądanie INVITE: od serwera Proxy atlanta.com do serwera Proxy biloxi.com 88

89 3. Żądanie INVITE: od serwera Proxy biloxi.com do UA Boba 89

90 4. Odpowiedź 180 Ringing: od UA Boba do serwera Proxy biloxi.com 90

91 5. Odpowiedź 180 Ringing: od serwera Proxy biloxi.com do serwera Proxy atlanta.com 91

92 6. Odpowiedź 180 Ringing: od serwera Proxy atlanta.com do UA Alice 92

93 7. Odpowiedź 200 OK: od UA Boba do serwera Proxy biloxi.com 93

94 8. Odpowiedź 200 OK: od serwera Proxy biloxi.com do serwera Proxy atlanta.com 94

95 9. Odpowiedź 200 OK: od serwera Proxy atlanta.com UA Alice 95

96 10. Żądanie ACK: od UA Alice do UA Boba 96

97 11. Ustanowiona sesja medialna: między UA Alice i UA Boba 97

98 12. Żądanie BYE: od UA Boba do UA Alice 98

99 13. Odpowiedź 200 OK: od UA Alice do UA Boba (koniec sesji) 99

100 100

101 Usługi natychmiastowej komunikacji i obecności

102 Obecność Osoba - wola, zdolność i chęć do komunikacji z wykorzystaniem różnych urządzeń, form wymiany informacji i typów mediów Obiekt - zagregowany widok dynamicznie zmieniających się atrybutów obiektu Atrybuty: Informacja o użytkownikach określonej kategorii Informacja o statusie użytkownika Lokalizacja w sensie fizycznym lub logicznym Status komunikacyjny Wola i chęć komunikacji Preferowane środki komunikacji 102

103 Znaczenie obecności Główne aspekty: doprowadzenie do udanego połączenia innowacyjne kategorie usług Problem finalizowania połączeń relatywnie niewielka frakcja połączeń prowadzi do rozmowy z pożądaną osobą: Rozwiązanie: inicjowanie połączenia w sytuacji gdy wywoływana osoba jest dostępna z uwzględnieniem informacji o preferowanym trybie komunikacji 103

104 Obecność - perspektywy Gotowość do komunikacji: tylko gdy pilne najpierw telefon komórkowy, a w przypadku niepowodzenia telefon stacjonarny do pracy wyłącznie definicja okien czasowych Możliwości: głos, wideo, poczta głosowa, poczta elektroniczna sieć mobilna i stacjonarna wybór języka komunikacja w relacjach formalnych i nieformalnych 104

105 SIP model obecności 105

106 Model realizacji usługi obecności 106

107 Model CPIM usługa obecności Usługa Obecności Protokół usługi obecności Obserwowany Obserwator UA Obserwowanego UA Obserwatora Nadrzędni Użytkownicy 107

108 Model CPIM usługa IM Usługa Natychmiastowej Komunikacji Nadawca Protokół usługi natychmiastowej komunikacji Skrzynka UA Nadawcy UA Skrzynki Nadrzędni Użytkownicy Nadrzędni Użytkownicy 108

109 Model danych dla obecności Osoba (presentity) (perspektywy) kalendarz komórka ręcznie Usługi audio, video, text video Urządzenia 109

110 Dane dla obecności Źródła obecności PUBLISH tworzenie widok (łaczenie) Obecność surowe dane Filtrowanie związane z prywatnością XCAP Wybór najlepszych źródeł Zależna od obserwującego XCAP Rozstrzyganie sprzeczności Polityka kompozycji Polityka prywatności (nie zdefiniowane) draft-ietf-simple-presence-data-model 110

111 Dane dla obecności kandydat na dok.obecn. filtr obserwatora Dane surowa obecność post-processing łączenie Usuwanie zbędnych Danych SUBSCRIBE Różnica względem Poprzedniego powiadomienia Obserwator NOTIFY finalny dokument obecności 111

112 Normalizacja SIP 112

113 113

114 Telekomunikacja eksplozja normalizacji Same normy RFC bez wersji roboczych (I-D)! 114

115 SIP zasoby w Internecie

116