Vorlesung Multimediakommunikation. 9. SIP-Erweiterungen. Dr.-Ing. Daniel Schuster Fakultät Informatik, Professur Rechnernetze

Transkript

1 Vorlesung Multimediakommunikation 9. SIP-Erweiterungen Dr.-Ing. Daniel Schuster Fakultät Informatik, Professur Rechnernetze

2 1. Einführung - Wiederholung: SIP-Endpunkt MESSAGE RFC 3428 Signaling / Conference Control NOTIFY RFC 3265 REFER RFC 3515 UPDATE RFC 3311 INFO RFC AV-Streaming Audio Codecs G.7xx Video Codecs H.26x modularer Aufbau von SIP Erweiterungen in separaten RFCs spezifiziert Buffering and Synchronisation SIP Core + SDP RFC 3261, RFC RTP / RTCP TCP UDP IP 9. 2

3 Working Groups der IETF im Umfeld von SIP Name erster RFC Agenda avt 1996 Echtzeitübertragung von Audio und Video über UDP/IP: RTP mmusic 1998 IP-basiertes Conferencing und Streaming: SIP 1.0, SDP, RTSP iptel 2000 Routing und Rufsignalisierung für Internettelefonie: TRIP, Tel URIs, CPL (Call Processing Language) sip, sipcore 2000 Weiterentwicklung des SIP-Protokolls: SIP-Methoden, Nachrichten, Events, URI enum 2000 Abbildung von Telefonnummern durch DNS: ENUM sipping 2002 Anwendungen und Erweiterungen von SIP simple 2004 Nutzung von SIP für Instant Messaging und Presence xcon 2005 eng gekoppelte Konferenzen (über MCU/Focus) behave 2007 Network Address Translation (NAT) für SIP und RTP ecrit 2008 Notrufe mit SIP p2psip (??) Peer-to-Peer SIP 9. 3

4 Erweiterbarkeit von SIP neue Methoden Requests mit unbekannten Methoden werden ignoriert unterstützte Methoden mit OPTIONS abfragen unterstützte Methoden mit Allow-Header bekannt geben neue Header / Features unbekannte Header werden ignoriert Features: neues Verhalten, z.b. 100rel - 1xx-Responses werden bestätigt 100rel = Option Tag; weitere: early-session, ice unterstützte Header/Features mit Supported-Header bekannt geben (Unsupported-Header, wenn nicht unterstützt) benötigte Header/Features mit Require oder Proxy-Require anfordern IANA-Registry neue Methoden, Header, etc. werden von IANA (Internet Assigned Numbers Authority) registriert

5 Registrierte SIP-Methoden (Stand 2013) Methode RFC Inhalt ACK RFC3261 Antwort auf Request bestätigen BYE RFC3261 Call beenden CANCEL RFC3261 Request abbrechen INFO RFC2976 Signalisierung während einer Session INVITE RFC3261 Session-Aufbau MESSAGE RFC3428 Instant Message senden NOTIFY RFC3265 Subscriber über ein Event benachrichtigen OPTIONS RFC3261 Unterstützte Features abfragen PRACK RFC3262 Bestätigung für vorläufige Responses (1xx) PUBLISH RFC3903 Event publizieren (über Event Server) REFER RFC3515 Empfänger soll einen Request ausführen REGISTER RFC3261 Bei Location Service registrieren SUBSCRIBE RFC3265 für bestimmte Event-Updates anmelden UPDATE RFC3311 Parameter während Rufaufbau ändern 9. 5

6 2. Offer/Answer-Modell (RFC 3264) Session Session Verhandlung beginnt mit initialem Offer (Angebot für RTP-Sessions) jede Offer wird mit Answer beantwortet ein neues Offer darf erst verschickt werden, wenn das letzte Offer beantwortet wurde mehrere Wiederholungen von Offer/ Answer vor Session-Aufbau möglich Nachverhandlung während der Session möglich Offer kann von beiden Seiten geschickt werden 9. 6

7 Beispiele für Offer und Answer Offer v=0 o=alice IN IP4 host.a.de s= c=in IP4 host.a.de 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 Answer v=0 o=bob IN IP4 host.b.de s= c=in IP4 host.b.de 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/90000 Alice schickt Offer für Audio-Stream und 2 Video-Streams (H.261 und MPEG) - Empfangs-Ports: Audio 49170, Video , Video Bob schickt Answer: möchte nur Audio und Video2 senden und empfangen - Empfangs- Ports: Audio 49920, Video

8 Auswahl eines Codecs Offer v=0 o=alice IN IP4 host.a.de s= c=in IP4 host.a.de t=0 0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=inactive Answer v=0 o=bob IN IP4 host.b.de s= c=in IP4 host.b.de t=0 0 m=audio RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=inactive Alice schickt Offer für einen Audio-Stream und kann die Codecs PCMU, G.723 und G.729 unterstützen a=inactive - noch keine RTP-Session aufbauen Bob schickt Answer: kann nur PCMU und G.723 anschließend entscheidet sich Alice für einen Codec und schickt ein neues Offer mit a=sendrecv 9. 8

9 Wie wird das Offer/Answer-Modell mit SIP realisiert? Fall 1: einfacher Ablauf Offer mit INVITE schicken Answer mit 200 OK à Session steht Fall 2: Änderung der Parameter in einer Session re-invite erneutes INVITE mit neuem Offer schicken Answer wieder in 200 OK 9. 9

10 Offer/Answer mit INVITE (Fall 1 und Fall 2) alice@a.de bob@b.de INVITE mit Offer von Alice an Bob wird durch Bobs User Agent akzeptiert, das Telefon klingelt Bob hebt den Hörer ab und sendet Answer mit 200 OK Alice bestätigt mit ACK Session steht RTP-Session Alice ändert Parameter mit erneutem INVITE - enthält neues Offer Bob akzeptiert mit 200 OK und Answer geänderte RTP-Session Nach Bestätigung gelten die neuen Parameter in der Session (z.b. anderer Audio-Codec) 9. 10

11 3. PRACK und UPDATE Fall 1: einfacher Ablauf Offer mit INVITE schicken Answer mit 200 OK à Session steht Fall 2: Änderung der Parameter in einer Session re-invite erneutes INVITE mit neuem Offer schicken Answer wieder in 200 OK Fall 3: Änderung der Parameter beim Session-Aufbau 3a) PRACK-Erweiterung Modifikation des 1. Offers möglich 3b) weitere Aushandlungen vor der Session mit UPDATE möglich 9. 11

12 PRACK-Methode (RFC 3262) PRACK Provisional Acknowledgement Hintergrund 200 OK wird bestätigt (ACK) vorläufige (provisional) Responses (1xx) werden in SIP nicht bestätigt à können verloren gehen (bei Nutzung von UDP) für bestimmte Szenarien Zuverlässigkeit benötigt (z.b. Interoperabilität mit PSTN) Bestätigung von 1xx-Responses Request enthält Supported: 100rel 1xx-Response wird mit Require: 100rel verschickt Empfänger der 1xx-Response bestätigt mit PRACK, sonst Response wiederholt PRACK wird als normaler SIP-Request behandelt o darf Offer beinhalten o läuft über Proxies o Empfang durch 200 OK bestätigt (ggf. mit Answer) SIP/ Session Progressing. Via: SIP/2.0/UDP proxy.a.de: 5060;branch=z9hG4bK74bf9;received=3ffe: 501:ffff:5::X From: Alice <sip:alice@a.de>;tag=9fxced76sl To: Bob <sip:bob@b.de>;tag= Call-ID: @a.de Contact: <sip:alice@client.a.de> Require: 100rel RSeq: 10 CSeq: 2 INVITE Content-Type: application/sdp Content-Length: 147 [SDP Offer] PRACK sip:bob@b.de SIP/2.0 Via: SIP/2.0/UDP client1.a.de: 5060;branch=z9hG4bK a Max-Forwards: 70 From: Alice <sip:alice@a.de>;tag=9fxced76sl To: Bob <sip:bob@b.de>;tag= Call-ID: @a.de CSeq: 3 PRACK RAck: 10 2 INVITE Content-Length:

13 Offer/Answer-Modell mit PRACK (Fall 3a) Initiale Offer wird mit INVITE geschickt Answer kann in 200 OK oder 1xx-Nachricht geschickt werden Bob möchte Verbindung aufbauen, aber unterstützt nicht die angebotenen Medien 1xx-Nachricht wird von Alice mit PRACK bestätigt (Require: 100rel) Alice sendet mit PRACK neues Offer, wird von Bob akzeptiert Bobs Telefon klingelt 180 Ringing Bob hebt ab 200 OK Bestätigung durch Alice INVITE-Transaktion abgeschlossen RTP-Session RTP-Session ist aufgebaut 9. 13

14 Early Media mit PRACK (RFC 3959) Gateway Content-Type: multipart/mixed; boundary="boundary1" Content-Length: boundary1 Content-Type: application/sdp Content-Disposition: session Answer 1 RTP-Session RTP-Session Gateway übermittelt Ansage Telefon klingelt (spezieller Klingelton über RTP übertragen) Bob hat abgehoben Early Media wird durch richtige RTP-Session ersetzt v=0 o=bob IN IP4 x.b.de s= c=in IP t=0 0 m=audio RTP/AVP 0 --boundary1 Content-Type: application/sdp Content-Disposition: early-session v=0 o=bob IN IP4 x.b.de s= c=in IP t=0 0 m=audio RTP/AVP 0 --boundary1-- Offer

15 UPDATE-Methode (RFC 3311) Erweiterung aktivieren: Allow: UPDATE im INVITE-Request nochmaliges Verhandeln mit Offer/ Answer erlaubt innerhalb des Session-Aufbaus möglich wird sofort beantwortet (kein Ringing, etc.) UPDATE-Request enthält neue Offer kann auch von Angerufenem geschickt werden UPDATE-Response (200 OK) enthält Answer auf diese Offer UPDATE SIP/2.0 Via: SIP/2.0/UDP client1.a.de:5060;branch=z9hg4bk74bf9 Max-Forwards: 70 From: Alice To: Bob Call-ID: CSeq: 2 UPDATE Content-Length: 147 v=0 o=alice IN IP4 client1.a.de s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly 9. 15

16 Offer/Answer-Modell mit UPDATE (Fall 3b) Ablauf wie bisher (PRACK) Telefon klingelt Änderung der Parameter mit UPDATE, während es noch bei Bob klingelt (z.b. auf Halten setzen) wird von Bob mit 200 OK bestätigt Bob hebt ab RTP-Session RTP-Session ist aufgebaut 9. 16

17 4. Telefoniedienste - Übersicht Ziel: klassische Telefoniedienste durch SIP-Erweiterungen für Internettelefonie nutzbar machen für Interoperabilität mit Telefonnetz wichtig wichtige Telefoniedienste 1. Anruferidentifikation durch SIP URI in From-Header 2. Rufumleitung 3. Klingeln an mehreren Apparaten (Call Forking - CANCEL) 4. Zwei Anrufe gleichzeitig - Halten, Rückfrage, Makeln re-invite 5. Rufweitergabe (REFER) 6. Notrufe 9. 17

18 Rufumleitung proxy.b.de proxy.c.de RTP Session 9. 18

19 Klingeln an mehreren Apparaten proxy.b.de INVITE-Request wird abgebrochen Telefon hört auf zu klingeln wird von Bob bestätigt Bob sendet 400- Response auf INVITE wird von Proxy bestätigt 9. 19

20 Zwei Anrufe gleichzeitig Halten, Rückfrage, Makeln Halten Verbindung wird in Wartezustand gebracht Anrufer hört Ansage oder Wartemusik re-invite mit a=sendonly Übertragung von Musik, Verbindung bleibt aktiv Fortsetzung des Gesprächs durch neues re-invite Rückfrage während ein Gespräch gehalten wird, ein zweites Gespräch führen Halten wie oben neuer SIP-Dialog und Session mit zweitem Partner Makeln Hin- und Herschalten zwischen zwei Anrufern Kombination von Rückfrage und Halten 9. 20

21 Ablauf Halten RTP-Session aktives Telefongespräch INVITE mit a=sendonly für die RTP-Session RTP-Session (Wartemusik) Wartemusik wird von Alice an Bob übertragen für Fortsetzung des Gesprächs neuer INVITE-Request mit neuem Offer (a=sendrecv) RTP-Session Gespräch wird fortgesetzt 9. 21

22 Rufweitergabe - REFER alice@a.de bob@b.de carol@c.de RTP-Session Gespräch mit Bob Bob wird auf Halten gesetzt RTP-Session RTP-Session Bob wird von Alice mit REFER beauftragt, ein Gespräch zu Carol aufzubauen Aufbau der Verbindung mit INVITE Alice wird per NOTIFY über den erfolgreichen Rufaufbau (200 OK) benachrichtigt Alice baut darauf die gehaltene Verbindung zu Bob ab 9. 22

23 REFER (RFC 3515) Empfänger soll die angegebene URI kontaktieren Header: Refer-To kann auch nicht-sip-uri sein, z.b. HTTP REFER-Request kann innerhalb oder außerhalb eines bestehenden SIP-Dialogs gesendet werden REFER SIP/2.0 To: From: Call-ID: CSeq: REFER Max-Forwards: 70 Refer-To: Contact: Content-Length: 0 SIP/ Accepted To: <sip:bob@b.de> From: <sip:alice@a.de>;tag= Call-ID: @a.de CSeq: REFER Contact: sip:bob@b.de Content-Length:

24 NOTIFY für REFER Sender des REFER-Requests wird über Fortschritt der Weiterleitung informiert Subscription für refer-event Alice erhält NOTIFY-Nachrichten mit den Responses, die Bob von Carol erhält Body: 100 Trying, 200 OK, NOTIFY SIP/2.0 To: From: Call-ID: CSeq: NOTIFY Max-Forwards: 70 Event: refer Subscription-State: active Contact: Content-Type: message/sipfrag;version=2.0 Content-Length: 20 SIP/ OK SIP/ OK To: From: Call-ID: CSeq: NOTIFY Contact: Content-Length:

25 Notrufe mit SIP Notrufe mit SIP Ziel: Notrufe von jedem SIP-Gerät weltweit ermöglichen Ort des Nutzers und ggf. weitere Informationen übertragen Service URN (RFC 5031) einheitliche URN (Uniform Resource Name) urn:service:sos für Notrufe kann auch genauer spezifiziert werden: urn:service:sos.ambulance, urn:service:sos.fire SIP Proxy übersetzt in SIP-URI einer Notrufzentrale Lokalisierung GPS/Netzwerk-Lokalisierung bzw. manuelle Eingabe des Standorts am SIP UA bevorzugt Mapping auf geeigneten Dienst mit Location-to- Service Translation Protocol (LoST) - RFC 5222 <?xml version="1.0" encoding="utf-8"?> <findservice xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2=" serviceboundary="value" recursive="true"> <location id=" f1ce1896d"profile="geodetic-2d"> <p2:point id="point1" srsname="urn:ogc:def:crs:epsg::4326"> <p2:pos> </p2:pos> </p2:point> </location> <service>urn:service:sos.police</service> </findservice> <?xml version="1.0" encoding="utf-8"?> <findserviceresponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2=" <mapping expires=" t01:44:33z"> <displayname xml:lang="en"> New York City Police Department </displayname> <service>urn:service:sos.police</service>... <uri>sip:nypd@example.com</uri> </mapping>... </findserviceresponse> 9. 25

26 5. SIP Event Framework SIP-spezifischer Mechanismus für Event Notification (RFC 3265) Nutzer können sich mit SUBSCRIBE für ein Event einschreiben werden dann für gewissen Zeitraum per NOTIFY über aktuellen Status informiert SUBSCRIBE und NOTIFY mit 200 OK bestätigt implizite Subscriptions möglich (z.b. bei REFER) Events werden in Event Packages definiert Abfrage des Zustands (Polling) durch SUBSCRIBE mit Laufzeit 0 möglich 9. 26

27 SUBSCRIBE Beispiel (Presence) URI + Event Type für Identifikation URI muss richtiges Routing ermöglichen SUBSCRIBE sip:bob@b.de SIP/2.0 Via: SIP/2.0/TCP pc3.a.de;branch=z9hg4bknashds7 To: <sip:bob@b.de> From: <sip:alice@a.de>;tag=xfg9 Call-ID: 2010@pc3.a.de CSeq: SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: <sip:alice@pc3.a.de> Expires: 600 Content-Length: 0 Referenz auf presence Event Package ich möchte über die Presence von bob@b.de benachrichtigt werden Akzeptiertes Format hier Presence Information Data Format Subscription für 600 Sekunden (10 Minuten) 9. 27

28 NOTIFY Beispiel (Presence) NOTIFY SIP/2.0 From: To: Call-ID: Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: Content-Type: application/pidf+xml Content-Length:... Schon eine Sekunde der Subscription abgelaufen [PIDF Document] Presence-Information von Bob im PIDF-Format 9. 28

29 PUBLISH PUBLISH: Event Server beauftragen, Notifications zu verschicken Event Server kann Events sammeln und filtern z.b. Presence: Presence-Zustand von ganzer Kontaktliste verwalten server.x.de 9. 29

30 Beispiel PUBLISH URI + Event Type für Identifikation Alice modifiziert ihre eigene Presence-Information PUBLISH sip:alice@a.de SIP/2.0 To: <sip:alice@a.de> From: <sip:alice@a.de>;tag=1234wxyz Call-ID: @pc3.a.de CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length:... [Published PIDF document] nach einer Stunde ungültig presence Event package 9. 30

31 6. Instant Messaging und Presence - SIMPLE SIMPLE = Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions alice@a.de SIP Proxy a.de bob@a.de Ziel: Instant Messaging und Presence auf der Basis von SIP Presence: mit Event Framework (Events vom Typ presence ) Messaging: MESSAGE- Request oder Text-Session 9. 31

32 SIMPLE Instant Messaging 1. Page Mode SIP-Methode MESSAGE für das Senden von Instant Messages setzt keine bestehende Client-Server-Session voraus (funktioniert auch mit UDP) Erweiterung zum Senden von MESSAGE an eine Liste von Empfängern 2. Session Mode Message Session Relay Protocol (MSRP) Aufbau einer IM-Session mit SIP Zerteilen großer Nachrichten in Chunks möglich Transfer von Attachments möglich 9. 32

33 SIMPLE IM Beispiel Page Mode MESSAGE SIP/2.0 Via: SIP/2.0/TCP bob.domain.com;branch=a87lunojasd Max-Forwards: 70 From: To: Call-ID: CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Hello Alice. SIP/ OK Via: SIP/2.0/TCP bob.domain.com;branch=a87lunojasd From: sip:bob@domain.com;;tag=42294 To: sip:alice@domain.com;tag=i33r1uthc Call-ID: z4752sdda@ CSeq: 1 MESSAGE Content-Length:

34 SIMPLE IM Beispiel Session Mode MSRP d93kswow SEND To-Path: msrp://bob.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7777/iau39;tcp Message-ID: 12339sdqwer Success-Report: yes Content-Type: text/plain Hi, I'm Alice! d93kswow$ MSRP d93kswow 200 OK To-Path: msrp://alicepc.example.com:7777/iau39;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp d93kswow$ 9. 34

35 7. SIP Conferencing Mehrpunktkonferenzen Telefonkonferenzen (weit verbreitet) Videokonferenzen auf Basis von H.323 oder proprietär WebConferencing (proprietär) Mehrpunkt-Konferenzen mit SIP SIP-Erweiterung der Centralized Conferencing Working Group (XCON) 9. 35

36 XCON-Architektur Notification Service: Verteilung von Informationen, z.b. Teilnehmerliste Floor Control: Zugriffskontrolle Conference Control: Modifikation des Conference Object Conference Object: Beschreibung, Rollen, Signalisierung, Mixer, etc. jeder Teilnehmer unterhält SIP-Dialog mit Focus Focus kontrolliert einen oder mehrere Media Mixer, über die die Teilnehmer Medienströme austauschen User Agent User Agent Conferencing Server Notification Service Floor Control Conference Control Focus Conference Object Media Mixer User Agent User Agent 9. 36

37 XCON-Abläufe Konferenz erstellen Focus, Conference Object und Conference-URI werden erstellt Teilnehmer hinzufügen INVITE-Request an Conference-URI (Call-In) INVITE-Request von Focus an Teilnehmer (Call-Out) durch Dritte mittels REFER an Conference-URI Teilnehmer entfernen BYE an Teilnehmer oder Focus Focus muss mit Mixer kommunizieren Konferenz beenden kann in Policy festgelegt werden à kann auch persistente Konferenzen geben üblicherweise, wenn letzter Teilnehmer geht (BYE) Informationen über Teilnehmer über Notification Service Teilnehmerliste beziehen und Updates bekommen <?xml version="1.0" encoding="utf-8"?> <conference-info-diff xmlns="urn:ietf:params:xml:ns:xconconference-info" <add sel="*/users/allowed-users-list"> <target method="refer"/> </add> <replace sel="*/conference-state/user-count/ text()">5</replace> </conference-info-diff> 9. 37

38 8. Peer-to-Peer SIP warum P2P-SIP? Server-loser Betrieb bei gleichzeitig hoher Sprachqualität sind wesentliche Erfolgsfaktoren von VoIP im privaten Bereich P2P SIP seit ca Forschungsthema Session-Aufbau P2P möglich (ohne Proxies) Probleme: Lokalisierung und andere Services ersetzen; Security seit 2009 Standardisierungsbestrebungen p2psip Working Group der IETF - RELOAD protocol (REsource LOcation And Discovery) ICE obligatorisch (NAT-Problematik) erste RFCs für 2013 erwartet 9. 38

39 Overlay-Netze / P2P-Netze Netz auf dem Netz Discovery und Routing auf Anwendungsebene verschiedene Topologien möglich (z.b. Ring, Stern, Baum,...) P2P-Netze teilen Bandbreite und weitere Ressourcen der Peers Peers können jederzeit dazukommen bzw. das Netz verlassen nicht alle Peers übernehmen gleiche Aufgaben (z.b. Supernodes) Router physisches Netz Peer Overlay- Netz 9. 39

40 Distributed Hash Tables - DHT Anforderung an P2P-Netz: Informationen verteilt speichern und darauf zugreifen DHT: skalierbare, schnelle Suche nach Informationen in einem P2P-Netz Kern: mathematische Hash-Funktion Abbildung: beliebig langer String à Zahlenwert minimale Kollisionswahrscheinlichkeit Hash-Table Abbildung: Hash-Werte à Knoten-ID verwaltet bestimmten Bereich der Informationen Beispiel Chord: logischer DHT-basierter Ring neuer Knoten fügt sich selbst zwischen 2 Nachbarknoten ein weiterführende Informationen zu P2P: Vorlesung Internet and Web Applications Quelle:

41 P2P SIP - Prinzip 7 INVITE alice@a.de peer2 peer3 peer4 bob@b.de 2 DHT DHT 4 DHT 5 DHT 1 DHT 6 1: Bob registriert seine aktuelle IP-Adresse bei einem Nachbarknoten 2: Alice befragt DHT-Layer, um die IP-Adresse von bob@b.de zu ermitteln à Hash-Wert aus bob@b.de 2-5: Request wird im Overlay-Netz weitergeleitet 6: peer4 gibt die IP-Adresse für bob@b.de zurück 7: Alice baut zu Bob direkt einen SIP-Dialog auf (INVITE) 9. 41

42 Zusammenfassung: Modell für MMK-System MMK-Anwendung Presence, Instant Messaging Signalisierung Audio/Video ecollaboration XMPP, SIMPLE DNS, ENUM, SIP, H.323, SDP, SIP Extensions, RTSP Audio Codecs G.7xx Video Codecs H.26x Pufferung, Synchronisierung Group Com. Service PubSub Service Consistency Service XMPP, SIP MSRP Collab. Procotols (RFB, ) TCP/UDP RTP / RTCP UDP TCP IP 9. 42

43 Navigator 1. Einführung 2. XMPP 3. XMPP-Erweiterungen 4. Codierung und Transport 5. Internettelefonie 6. Videokonferenzen 7. Streaming 8. SIP 9. SIP-Erweiterungen 10.Data Sharing 11.Shared Editing 12.WebRTC 9. 43

44 Literatur Henry Sinnreich, Alan Johnston: Internet Communications Using SIP, Wiley, RFC Reliability of Provisional Responses in the Session Initiation Protocol (SIP) RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP) RFC 3265 Session Initiation Protocol (SIP) Specific Event Notification RFC The Session Initiation Protocol (SIP) UPDATE Method RFC The Session Initiation Protocol (SIP) REFER Method RFC 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP) RFC A Uniform Resource Name (URN) for Emergency and Other Well-Known Services RFC LoST: A Location-to-Service Translation Protocol RFC 5239 A Framework for Centralized Conferencing REsource LOcation And Discovery (RELOAD) Base Protocol - draft-ietf-p2psip-base 9. 44