Vorlesung Multimediakommunikation 8. Session Initiation Protocol
Werbung
Vorlesung Multimediakommunikation 8. Session Initiation Protocol (SIP) Dr.-Ing. Daniel Schuster Fakultät Informatik, Professur Rechnernetze 1. Einführung - Die Vision hinter SIP § § § Problem der „Walled Gardens“ • einzelne Provider grenzen ihre Netze gegeneinander ab • viele Teilnetze mit begrenzter Anzahl Teilnehmern Metcalfe‘s Law: • Wert eines Telekommunikations- netzes wächst quadratisch mit der Anzahl der erreichbaren Knoten • Wert = Anzahl möglicher Verbindungen SIP-Vision: jegliche Form von MMK über IP ermöglichen • eine gemeinsame Basis für IP-basierte Telekommunikation • modulares, erweiterbares Konzept • offener Standardisierungsprozess (IETF) • Gateways in andere Netze (z.B. PSTN, H.323) Professur Rechnernetze Multimediakommunikation 8. 2 Was ist SIP? SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established. (Quelle: RFC 3261) § „Session Initiation“ • Session = Datenaustausch in einem Verbund von Teilnehmern • Probleme: Teilnehmermobilität; unter mehreren Namen erreichbar; kommunizieren mit verschiedenen Medien § Funktionen von SIP • Lokalisierung von Teilnehmern, bzw. des Endgerätes, das sie zur Kommunikation benutzen wollen • Anzeige der Verfügbarkeit (Presence) von Teilnehmern • Aushandlung von Parametern, z.B. welche Audio-/Videocodecs für die Kommunikation verwendet werden sollen • Aufbau einer Session • Management einer Session, z.B. Rufweiterleitung und Abbau von Sessions Professur Rechnernetze Multimediakommunikation 8. 3 Aufbau des User Agents AV-Streaming ... INFO RFC 2976 UPDATE RFC 3311 REFER RFC 3515 NOTIFY RFC 3265 MESSAGE RFC 3428 Signaling / Conference Control Audio Video Codecs Codecs G.7xx H.26x Buffering and Synchronisation SIP Core + SDP RTP / RTCP RFC 3261, RFC RFC 2327 4566 TCP UDP IP Professur Rechnernetze Multimediakommunikation 8. 4 Grundprinzip der SIP-Kommunikation User Agent User Agent User Agent Client (UAC) User Agent Client (UAC) User Agent Server (UAS) User Agent Server (UAS) User Agent Client (UAC) Status Status User Agent Server (UAS) fertig Professur Rechnernetze Multimediakommunikation 8. 5 Requests im SIP Core § REGISTER • Nutzer-ID und aktuelle IP-Adresse registrieren à § Lokalisierung INVITE • wichtigster Request à Aufbau einer Session • Aushandlung der Session-Parameter § ACK • Session-Aufbau bestätigen (2-Wege-Handshake) • wird als einziger Request nicht beantwortet § BYE • Session beenden § CANCEL • einen Request abbrechen § OPTIONS • unterstützte Features abfragen (à Professur Rechnernetze Multimediakommunikation Erweiterbarkeit) 8. 6 Status Antworten / Responses § 1xx Status-Antwort • • § 2xx erfolgreiche Bearbeitung • § fertig 400 Bad Request – Fehler im Request 401 Unauthorized – Nutzer muss sich authentisieren 403 Forbidden – Request nicht erlaubt 5xx Server-Fehler • • § 301 Moved Permanently – Nutzer hat jetzt andere Adresse 302 Moved Temporarily – neue Adresse nur vorübergehend 4xx Client-Fehler • • • § 200 OK – Request wurde erfolgreich bearbeitet 3xx Umleitung • • § 100 Trying – Request wurde empfangen und wird bearbeitet 180 Ringing – INVITE empfangen, Nutzer wird benachrichtigt 501 Not Implemented – Funktion nicht unterstützt 503 Service Unavailable – Server gerade nicht verfügbar 6xx Globale Fehler Professur Rechnernetze Multimediakommunikation 8. 7 Komponenten PSTN / ISDN H.323 UA UA UA Gateway UA UA UA Redirect Server UA Registrar and Presence Server MCU Proxy and PBX Proxy Registrar MCU UA – User Agent (Terminal) PBX – Telefonanlage/Private Branch Exchange (z.B. Asterisk) Proxy – Weiterleitung von SIP-Nachrichten in andere Teilnetze Registrar – Verzeichnis für Abbildung von Namen auf Adressen Redirect Server – Umleitung von Requests Presence Server – zeigt Verfügbarkeit von Teilnehmern an Gateway - Übergang in andere Netze (z.B. H.323) MCU – Multipoint Control Unit (Medienserver) Professur Rechnernetze Multimediakommunikation 8. 8 Komponenten im Detail User Agent Proxy Server INVITE 180 Ringing Proxy 200 OK UA ACK UA ACK UA UA Redirect Server Registrar Registrar Redirect Server INVITE Location Service UA Professur Rechnernetze UA UA Multimediakommunikation 8. 9 Zusammenspiel mit anderen Protokollen TeilnehmerAdressen LDAP TRIP GatewayAdressen DNS Proxy-Adressen Signalisierung Signalisierung SIP SIP SDP Medientransport Medientransport RTP RTP Transportschicht TCP UDP SDP Transportschicht TCP UDP LDAP..Lighweight Directory Access Protocol – Abfrage von Verzeichnisdiensten (hier: Location Server) TRIP..Telephony Routing over IP – Austausch von Routing-Informationen (hier: Gateway-Adressen) SDP..Session Description Protocol – Beschreibung der Medienformate der RTP-Session Professur Rechnernetze Multimediakommunikation 8. 10 2. Adressierung und Lokalisierung – angestrebte Formen der Mobilität § persönliche Mobilität • Nutzer ist immer unter der gleichen Adresse erreichbar, egal wo er sich befindet • durch Registrar Server realisiert § Endgerätemobilität • SIP-Endgeräte sollen frei beweglich sein (z.B. Handys) • Wechsel der IP-Adresse und kurzzeitiger Ausfall der IPVerbindung werden toleriert § Session-Mobilität • laufende Session kann auf ein anderes Endgerät transferiert werden § Dienstemobilität • Nutzer kann jederzeit und überall die auf ihn zugeschnittenen Dienste in Anspruch nehmen Professur Rechnernetze Multimediakommunikation 8. 11 SIP-URI sip:user@domain URI-Schema sips: sichere Verbindung § § Lokaler Benutzername, z.B. alice Domain-Name, z.B. a.de Zweck: eindeutige Identifikation von Benutzern oder Diensten • Nutzer: sip:[email protected] o kann E-Mail-Adresse entsprechen • Dienst: sip:[email protected] Telefonnummern können als Tel-URIs (RFC 2806) auch als Zieladresse in SIP verwendet werden • tel:+49-351-1234567 Professur Rechnernetze Multimediakommunikation 8. 12 Lokalisierung von Nutzern mit SIP-URI Domain b.de DNS 4. sip:b.de? SRV-Record sip:b.de proxy.b.de A-Record proxy.b.de 24.2.2.3 Registrar 1. proxy.b.de 24.2.2.3 User Agent A@ B@ C@ 2. REGISTER [email protected] [email protected] 200 OK User Agent LDAP, SQL,... Proxy Location Server 7. INVITE [email protected] [email protected] 22.2.3.4 Professur Rechnernetze proxy.b.de 24.2.2.3 Multimediakommunikation [email protected] 24.2.2.7 8. 13 DNS-Registrierung (Schritt 1) § DNS (Domain Name System) SRV (Service) Resource Records • welche Dienste werden in einer Domain angeboten? • Service = Dienst + Protokoll + Domain § Nutzung in SIP • Adressen von SIP Proxies à können auf andere Domain zeigen • mehrere „physische“ SIP Proxies für einen logischen Proxy möglich o sip:a.de à sip1.a.de, sip2.a.de • ein physischer SIP Proxy für mehrere logische Proxies möglich o sip:a.de, sip:b.de à sip.iptel.org _sip._tcp.b.de. SRV SRV _sip._udp.b.de. SRV SRV Professur Rechnernetze 0 1 0 1 0 0 0 0 5060 5060 5060 5060 proxy.b.de. backup-proxy.b.de. proxy.b.de. backup-proxy.b.de. Multimediakommunikation 8. 14 SIP-Registrierung (Schritte 2 und 3) § mit REGISTER-Request • • • • • erfordert meist Authentisierung Registrar verwaltet Kontaktadresse arbeitet mit Proxy in gleicher Domäne zusammen nach Ablauf der Zeitspanne neu registrieren Beispiel: REGISTER sip:registrar.b.de SIP/2.0 Via: SIP/2.0/UDP 24.2.2.7:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob <sip:[email protected]> From: Bob <sip:[email protected]>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:[email protected]> Expires: 7200 Content-Length: 0 Professur Rechnernetze Multimediakommunikation Adresse des Registrars für die Domain b.de Adresseintrag, der erzeugt werden soll Adresse der verantwortlichen Person gemeinsame ID für alle Registrierungen des Clients Adress Binding – momentan IP 24.2.2.7 8. 15 Adressauflösung mit DNS (Schritte 4-7) [email protected] DNS proxy.b.de [email protected] SIP-Proxy für b.de mit SRV-Query ermitteln IP-Adresse des Proxies mit AQuery ermitteln Proxy B ermittelt IP von Bob über Location Service (nicht DNS) Professur Rechnernetze Multimediakommunikation 8. 16 3. Arbeitsweise des Protokolls – Szenario 1: Peer-to-Peer Redirect Server § § § § § beide UAs in je einem Subnetz über Internet per IP-Adresse erreichbar direkter Verbindungsaufbau zwischen SIP-UAs Ermittlung der IP-Adresse über Redirect Server direkte RTP-Session zur Medienübertragung Internet User Agent User Agent 24.2.2.3 243.45.3.80 Professur Rechnernetze Multimediakommunikation 8. 17 Ablauf Peer-to-Peer-Szenario [email protected] [email protected] § § Klingelton klingeln § § § RTP Session Professur Rechnernetze Multimediakommunikation [email protected] kontaktiert [email protected] IP-Adressen und Portnummern sind bekannt kein „Verhandlungsbedarf“ für RTPSession Bob beendet die Session (legt auf) mit der SIP-Session wird auch die RTPSession beendet 8. 18 Transaktionen und Dialoge [email protected] § [email protected] Transaktion 1 § Dialog 1 RTP Session Transaktion 2 Professur Rechnernetze § Multimediakommunikation § Transaktion = SIPRequest und zugehörige Antworten (Responses) Abschluss mit Antwort >=200 (meist 200 OK) ACK ist keine Transaktion à erfordert keine Antwort Dialog = Kommunikationsbeziehung zwischen zwei User Agents 8. 19 Szenario 2: Proxy a.de b.de Proxy Internet Proxy Registrar User Agent A@ B@ REGISTER [email protected] User Agent RTP Session 243.45.3.80 § § § § § 24.2.2.3 wie Szenario 1, jedoch je ein Proxy in beiden Domänen (SIP-Trapez) Bob registriert sich nur bei seinem zuständigen Registrar Alice kann direkt SIP-Adresse von Bob verwenden IP-Adresse von Bob wird erst in der Zieldomäne ermittelt direkte RTP-Session (IP und Port in Antwort auf INVITE) Professur Rechnernetze Multimediakommunikation 8. 20 Ablauf Proxy-Szenario [email protected] proxy.a.de proxy.b.de [email protected] Klingelton klingeln RTP Session Professur Rechnernetze Multimediakommunikation 8. 21 Proxy Routing Aufzeichnung von Routen – Response auf gleichem Weg UA1 Proxy1 INVITE Via:UA1 200 OK Via:UA1 Proxy2 INVITE Via:Proxy1,UA1 INVITE Via:Proxy2,Proxy1,UA1 200 OK Via:Proxy1,UA1 Folge-Request direkt: UA1 Professur Rechnernetze Proxy UA2 oder mit Record Routing (optional): UA2 UA1 Multimediakommunikation Proxy UA2 8. 22 Bearbeitung von Transaktionen mit Proxies User Agent User Agent Client (UAC) User Agent Stateless Proxy CT CT Forwarder User Agent ST Server (UAS) User Agent CT User Agent Client (UAC) User Agent Server (UAS) User Agent Client (UAC) ST User Agent Server (UAS) ST Stateful Proxy CT ST User Agent User Agent Client (UAC) CT CT ST User Agent Server (UAS) CT – Client Transaction ST – Server Transaction Professur Rechnernetze Multimediakommunikation 8. 23 Dialoge über Proxies • • • • • Call - Einladung eines Clients (INVITE) Dialog - Austausch von SIP-Nachrichten zwischen zwei User Agents Session - Austausch von Medien Dialog 1 zwischen zwei Endpunkten Call kann mehrere Dialoge enthalten aus Dialog entsteht meist eine Session Request Call-ID=1 User Agent User Agent Client (UAC) User Agent User Agent Client (UAC) Stateful Proxy CT ST CT CT Response tag=3456 User Agent User Agent Client (UAC) User Agent Server (UAS) Dialog 2 Professur Rechnernetze ST User Agent Server (UAS) Multimediakommunikation ST User Agent Server (UAS) 8. 24 Dialog: Struktur § Dialog-ID • Call-ID, Local Tag, Remote Tag à § eindeutige Identifikation Zustand • early – bislang nur 1xx-Responses verschickt/empfangen • final – mindestens eine Transaktion hat schon 2xx-Nachricht verschickt/empfangen § Sequenznummern • aktuelle CSeq lokal à nächste erwartete Antwort • aktuelle CSeq remote à nächster erwarteter Request § Route Set • Liste der Hops, über die die Requests und Responses im Dialog geroutet werden sollen Professur Rechnernetze Multimediakommunikation 8. 25 Szenario 3: SIP à Telefonnetz TRIP Location Server User Agent Location Server Proxy SIP INVITE sip:[email protected] H.248 MG § § § Anruf eines Telefons von einem SIP UA aus Telefonnummer wird als tel-URI angegeben SIP Proxy ermittelt über Location Server die SIP URI des zuständigen Gateways • § § IP Abgleich über TRIP – Telephony Routing over IP SIP-Gateway steuert Media Gateway über H.248 RTP Session wird zu Media Gateway aufgebaut – dort Umwandlung in Telefonverbindung Professur Rechnernetze Multimediakommunikation 8. 26 Szenario 4: Telefonnetz à Service Control Point (SCP) 5.4.3.2.1.3.6.4.1.5.3.9.4.e164.arpa sip:[email protected] ENUM-Datenbank (DNS) User Agent Vermittlungsstelle H.248 SIP § § § § SIP INVITE sip:[email protected] herkömmliches Festnetz-Telefon möchte SIP UA anrufen SIP UA hat seine Telefonnummer per ENUM einer SIP-URI zugeordnet (siehe Kapitel Internettelefonie) • alternativ: ganzer Telefonnummernbereich wird Gateway zugeordnet über Service Control Point wird die SIP-Adresse (und damit das zuständige Gateway) ermittelt Gateway baut Verbindung zu Ziel-UA auf Professur Rechnernetze Multimediakommunikation 8. 27 4. Nachrichtenaufbau § § Textformat - an HTTP 1.1 angelehnt Requests • Kopfzeile: SIP-Methode (INVITE, ACK, …), URI und SIP-Version • Header-Zeilen (z.B. To, From, Via, …) • Body (z.B. SDP-Inhalt) § Responses • Kopfzeile: SIPVersionsnummer, Statuscode, Statusmeldung • Header-Zeilen und Body wie bei Request Professur Rechnernetze INVITE sip:[email protected] SIP/2.0 To: sip:[email protected] From: sip:[email protected] Call-ID: 12345 c=IN IP4 192.168.3.250 t=0 0 m=audio 6006 RTP/AVP 8 3 0 SIP/2.0 200 OK To: sip:[email protected] From: sip:[email protected] Call-ID: 12345 c=IN IP4 192.168.3.250 t=0 0 m=audio 6006 RTP/AVP 8 3 0 Multimediakommunikation 8. 28 INVITE - Request Methode, URI, Protokollversion in erster Zeile RoutingInformationen Empfänger Absender (Tag für Identifikation des Dialogs) Sequenznummer des Requests im SIP-Dialog INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP sip.b.de;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP sip.a.de;branch=z9hG4bK77ef4c2 Via: SIP/2.0/UDP pc3.a.de;branch=z9hG4bK776asdh Max-Forwards: 70 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=101 Call-ID: [email protected] weltweit CSeq: 314159 INVITE eindeutiger Contact: <sip:[email protected]> Identifier für den Call Content-Type: application/sdp Content-Length: 142 <SDP-Inhalt> Body enthält Beschreibung im SDP-Format Professur Rechnernetze Multimediakommunikation direkte Adresse des Initiators – häufig IP-Adresse 8. 29 Wichtigste Header (1) § From From: Alice <sip:[email protected]>;tag=101 • „Auftraggeber“ (Initiator) des Requests • logische SIP-Adresse à wird für Verarbeitung benötigt • tag identifiziert den SIP-Dialog § To: Bob <sip:[email protected]> To • Empfänger des Request (z.B. INVITE) oder Ressource, die geändert werden soll (z.B. REGISTER) • enthält optional Display Name („Bob“) • Empfänger muss Tag anhängen o To: Bob <sip:[email protected]>;tag=322 à § Call-ID für Dialog-ID Call-ID: [email protected] • Identifikator für den Call à beginnt mit INVITE, enthält ein oder mehrere Dialoge • auch für REGISTER genutzt Professur Rechnernetze Multimediakommunikation 8. 30 Wichtigste Header (2) § CSeq: 314159 INVITE CSeq • Requests innerhalb des Dialogs identifizieren und ordnen • bei Wiederholung wegen Fehler gleiche CSeq verwenden § Max-Forwards • • • • § Via Max-Forwards: 70 unbeabsichtigte Schleifen bei Weiterleitung entdecken initial auf 70 gesetzt jeder Hop zieht 1 ab bei 0 à Nachricht verwerfen Via: SIP/2.0/UDP sip.b.de;branch=z9hG4bKnashds8 • • • • wie wurde die Nachricht transportiert? auf dem gleichen Weg soll die Response transportiert werden Request: jeder Hop fügt sich selbst oben an Response: jeder Hop entfernt sich selbst aus der Liste und sendet an nächsten Empfänger • branch-Tag kennzeichnet Transaktion (seit SIP 2.0) Professur Rechnernetze Multimediakommunikation 8. 31 Beispiel: INVITE proxy.b.de à Bob INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP proxy.b.de;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP proxy.a.de;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.a.de;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Professur Rechnernetze Multimediakommunikation 8. 32 Beispiel: 200 OK Bob à proxy.b.de SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.b.de;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP proxy.a.de;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.a.de;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:[email protected]>;tag=a6c85cf From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Professur Rechnernetze Multimediakommunikation 8. 33 SDP – Session Description Protocol § SDP – Session Description Protocol (RFC 4566) • kein „Protokoll“, sondern Beschreibungsformat • neben SIP auch von RTSP und anderen Protokollen genutzt • Text-basierte Codierung – Zeilen mit key=value § Informationen zu Medien und Transport • Medientyp (Audio, Video) • Transportprotokoll (RTP/UDP/IP, …), IP-Adresse und Port • Medienformat (H.261, G.711, …) § § § v= (Protokoll-Version) o= (Initiator der Session) c=* (Informationen zur Verbindung) SessionBereich (einmal) § § § m= (Medienname) c=* (Informationen zur Verbindung) a=* (weitere Medien-Attribute) Medienbereich (mehrfach) Professur Rechnernetze Multimediakommunikation 8. 34 SDP - Beispiel Alice macht ein Angebot für Session 1234 (mit Zeitstempel), ihre Internet (IN) IPv4Adresse ist angegeben Art der Verbindung: Internet, IPv4 v=0 o=Alice 1234 238989823 IN IP4 121.34.65.33 c=IN IP4 121.34.65.33 m=audio 20000 RTP/AVP 97 a=rtpmap:97 iLBC/16000 m=video 20001 RTP/AVP 31 RTP-Audiostrom auf Port 20000 mit RTPPayload-Typ 97 (dynamisch) RTP-Typ 97 wird für diese Session mit iLBC-Codec bei 16 kHz belegt RTP-Videostrom auf Port 20001 mit RTPPayload-Typ 31 (statisch) entspricht H.261 Professur Rechnernetze Multimediakommunikation 8. 35 Aushandlung der Medienparameter - Beispiel INVITE sip:[email protected] SIP/2.0 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]> Call-ID: [email protected] CSeq: 3 INVITE Content-Type: application/sdp SIP/2.0 200 OK To: Bob <sip:[email protected]> From: Alice <sip:[email protected]> Call-ID: [email protected] CSeq: 3 INVITE Content-Type: application/sdp v=0 o=user1 536 2337 IN IP4 r3.a.de c=IN IP4 r3.a.de m=audio 3456 RTP/AVP 0 1 m=video 4000 RTP/AVP 38 39 v=0 o=user1 535 2338 IN IP4 r1.b.de c=IN IP4 r1.b.de m=audio 1200 RTP/AVP 1 m=video 0 RTP/AVP § § § § Alice sendet INVITE-Request an Bob enthält SDP-Beschreibung mit RTP-Kanälen für Audio und Video Bob akzeptiert die Audioübertragung, lehnt Video aber ab nur Audioverbindung kommt zustande à mehr dazu in Kapitel SIP-Erweiterungen (Offer/Answer-Modell) Professur Rechnernetze Multimediakommunikation 8. 36 Mehrere Medien über eine RTP-Session v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= § basiert auf SIP c=IN IP4 biloxi.example.com t=0 0 Media Grouping a=group:BUNDLE foo bar (RFC 3388) m=audio 20000 RTP/AVP 0 § über BUNDLEb=AS:200 Attribut werden a=mid:foo Medien-Gruppen a=rtpmap:0 PCMU/8000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid definiert m=video 20000 RTP/AVP 32 § teilen sich b=AS:1000 Bandbreite (b=) a=mid:bar a=rtpmap:32 MPV/90000 § erfordert RTPa=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid Header- Erweiterung (extmap) Professur Rechnernetze Multimediakommunikation 8. 37 5. Programmierung mit SIP - JAIN SIP API § JAIN SIP ist eine Java-Spezifikation für SIP • JSR 32 - http://jcp.org/en/jsr/detail?id=32 § unterstützte RFCs: • • • • • • § RFC RFC RFC RFC RFC RFC 3261 3265 3262 3903 2806 3515 (SIP Core) – dieses Kapitel (SUBSCRIBE NOTIFY) (PRACK) (PUBLISH) (Tel URL) (REFER) kommt zum Einsatz in: • SIP User Agents • SIP Proxies • Applets und Servlets • … Professur Rechnernetze Multimediakommunikation 8. 38 JAIN SIP - Struktur SIP Stack Req Res Req Encoder Transaction Dialog Transaction Transaction SIPAnwendung SIP Provider Dialog Res Req Res Parser Transportschicht Professur Rechnernetze Multimediakommunikation 8. 39 JAIN SIP API - Beispiel SipURI requestURI = addressFactory.createSipURI(toUser, toSipAddress); // … Create other headers Request request = messageFactory.createRequest(requestURI, Request.INVITE, callIdHeader, cSeqHeader, fromHeader, toHeader, viaHeaders, maxForwards); // Create the client transaction ClientTransaction inviteTid = sipProvider.getNewClientTransaction(request); // send the request inviteTid.sendRequest(); Professur Rechnernetze Multimediakommunikation 8. 40 Zusammenfassung AV-Streaming ... INFO RFC 2976 UPDATE RFC 3311 REFER RFC 3515 NOTIFY RFC 3265 MESSAGE RFC 3428 Signaling / Conference Control Audio Video Codecs Codecs G.7xx H.26x Buffering and Synchronisation SIP Core + SDP RTP / RTCP RFC 3261, RFC RFC 2327 4566 TCP UDP IP Professur Rechnernetze Multimediakommunikation 8. 41 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 Professur Rechnernetze Multimediakommunikation 8. 42 Literatur § § § § § § § J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, SIP: Session Initiation Protocol, RFC 3261, IETF Network Working Group, 2002. Henry Sinnreich, Alan B. Johnston: Internet Communications Using SIP, Wiley Publishing, 2006. Scott Firestone, Thiya Ramalingam, Steve Fry, Voice and Video Conferencing Fundamentals (Kapitel 5 – Conferencing Using SIP), Cisco Press, 2007. Stephan Rupp, Gerd Siegmund, Wolfgang Lautenschlager: SIP – Multimediale Dienste im Internet, dpunkt.verlag, 2002. J. Rosenberg, A Hitchhiker's Guide to the Session Initiation Protocol (SIP), draft-ietf-sip-hitchhikers-guide-06, IETF SIP Working Group, 2008. Jiri Kuthan, Dorgham Sisalem, SIP: More Than You Ever Wanted to Know About, http://www.iptel.org/files/sip_tutorial.pdf, 2007. Henning Schulzrinne, Informationsseiten zu SIP - http://www.cs.columbia.edu/ sip/ Professur Rechnernetze Multimediakommunikation 8. 43