1 Codecs C Internettelefonie Coder/Decoder dient der Quellcodierung von Medien hier erforderlich: Audio-Codec, hauptsächlich für Sprache keine vollständiges Frequenzspektrum nötig Frequenzen bis 3.500 Hz sind ausreichend für gute Sprachqualität 1.1 G.711 ITU-T Standard für Audiocodierung (1972) PCM 8 Bit Samples (USA: 7 Bit) Abtastfrequenz 8.000 Hz Übertragungsbereich 300 3.400 Hz C.1 C.2 1.1 G.711 (2) 1.1 G.711 (3) Logarithmische Quantisierung µ-law (Nordamerika und Japan) A-Law (Europa) Beispiel A-Law 12 Bit Samples aus der Datenquelle A/D-Wandler mit mindestens 12 Bit Codierung qx ( ) Ax 1 = --------------------- mit x < --- 1 + log A A qx ( ) sgn x 1 + loga x 1 = --------------------------- mit --- < x < 1 1 + loga A A = 87,7 (oder 87,6) log ist jeweils der natürliche Logarithmus x wird angenommen zwischen 1 und 1 C.3 Tabellarische Darstellung lineare Eingabe A-Law Ausgabe s0000000abcd s000abcd s0000001abcd s001abcd s000001abcde s010abcd s00001abcdef s011abcd s0001abcdefg s100abcd s001abcdefgh s101abcd s01abcdefghi s110abcd s1abcdefghij s111abcd s = Vorzeichenbit (Informationsbits ohne Komplement) entspricht einer Fließkommadarstellung mit 4 Bit Mantisse und 3 Bit Exponent C.4
1.1 G.711 (4) 1.2 G.722 Übertragung alle geraden Bits werden invertiert übertragen Achtung: ITU-T definiert Bit 0 als Wert 128, Bit 7 als Wert 1 MOS-Wert liegt bei 4,4 sehr gute Qualität Verwendung ursprünglich: ISDN heute auch: VoIP Datenrate 64 kbit/s (kontinuierlicher Datenstrom bei ISDN) ~80 kbit/s (paketierter Datenstrom bei VoIP) Datenrate für heute Verhältnisse relativ hoch (eigentlich unkomprimiert) C.5 ITU-T Standard zur Audiocodierung (1988) ADPCM (Adaptive Differential PCM) Datenrate 64 kbit/s Frequenzband bis 7 khz Abtastrate 16 khz DPCM Differential PCM Codierung der Differenz zwischen aktuellem und vorherigem Sample ADPCM wie DPCM zusätzlich adaptive Anpassung der Quantisierungsintervalle Qualität MOS-Faktor = 4,5 C.6 1.2 G.722 (2) 1.3 G.723.1 Standard G.722.1 optimierte Version von G.722 erreicht vergleichbare Sprachqualität mit Datenraten von 24 kbit/s und 32 kbit/s Standard G.722.2 AMR-WB (Adaptive Multi Rate Wide Band) Verfahren Datenraten zwischen 6,6 kbit/s und 23,85 kbit/s Einführung von VAD (Voice Activity Detection) Sprachpausen werden nicht übertragen interessant für paketorientierte Übertragung (z.b. Internet, Mobilfunk) Einführung von CNG (Comfort Noise Generation) Einfüllen von Hintergrundrauschen beim Empfänger zur Überbrückung von Sprachpausen hoher MOS-Wert bei den höheren Datenraten ausgewählter Standard für 3GPP (3rd Generation Partnership Project) in Mobilfunknetzen C.7 ITU-T Standard zur Audiocodierung (1996) Datenrate 6,3 kbit/s Frequenzband 300 Hz 3.400 Hz MPC-MLQ (Multipulse LPC with Maximum Likelihood Quantization) Verfahren LPC = Linear Prediction Coding Qualität MOS-Faktor = 3,9 DTMF (Dual Tone Multi Frequency) Töne nicht übertragbar entspricht MFV (Mehrfrequenzwahlverfahren) umgangssprachlich: Touch-Tone Fax nicht mehr übertragbar relativ hoher Rechenaufwand Verzögerungszeiten zw. 60 ms und 90 ms C.8
1.4 G.729 2 RTP ITU-T Standard zur Audiocodierung (1996) Datenrate 6,4 kbit/s, 8 kbit/s und 11,8 kbit/s Frequenzband 300 Hz 3.400 Hz CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Prediction) Qualität MOS-Faktor = 4,1 DTMF-Töne und Fax nicht mehr übertragbar geringe Verzögerung von etwa 15 ms Variante G.729a kompatibel zu G.729 aber weniger Rechenaufwand dafür etwas schlechtere Sprachqualität Einsatz hauptsächlich VoIP C.9 Real-Time Transport Protocol (RTP) IETF Standard RFC 1889 (1996): RTP Version 1 RFC 3550 und RFC 3551 (2003): RTP Version 2 Zielsetzung Transport von Medien mit Echtzeitanforderungen z.b. Audio, Video, Sensordaten Unabhängigkeit von der darunterliegenden Transportschicht z.b. UDP, ATM Unterstützung von Unicast und Multicast Flexibilität Bereitstellung von Basisfunktionen Ansatzpunkte für anwendungsspezifische Erweiterungen C.10 2 RTP (2) Zielsetzung (fortges.) Identifikation des Senders Möglichkeit von Application Level Framing (ALF) Anwendung bestimmt Kompressionsverfahren und Codierung Synchronisation und Ausspielzeitpunkte Fehlererkennung (Verlust, Duplizierung, falsche Reihenfolge) Fehlererholung separate Kontrolle Datenübertragung und Kontrollsignalisierung unabhängig Kontrollprotokoll: RTCP (Real-Time Transport Control Procotol) keine Dienstgüteimplementierung garantiert z.b. keine Ankunftszeit Dienstgüteimplementierung außerhalb im Netz bzw. in den Endgeräten 2.1 Übertragung per RTP Paketierung (ALF) kontinuierliches Medium muss geeignet in Pakete aufgeteilt werden Profile legen teilweise Paketierung fest, z.b. RTP/AVP (Audio Video Profile) aus RFC 3551 RTP fügt einen Header von mind. 12 Byte dazu dazu kommen Header der Transportschicht und tiefer z.b. Header von UDP, Header von IP, Header von Ethernet C.11 C.12
2.2 RTP-Paketformat 2.2 RTP-Paketformat (2) Formatkennzeichnung Payload-Type (7 Bit) festgelegte Bedeutungen Profile legen Werte fest, z.b. RTP/AVP z.b. 0x08 für G.711 mit A-Law (PCMA), 0x09 für G.722 freie Werte können durch Anwendungen beliebig vergeben werden erfordern Signalisierung Markierungsbit kann formatabhängig für irgendeine Signalisierung genutzt werden wird gegebenenfalls in einem Profil definiert z.b. Audio: erstes Paket nach einer Sprachpause wird markiert Profil definiert Größe des Payload-Typs und Menge der Markierungsbits C.13 Sequenznummer 16 Bit laufende Nummer des RTP-Pakets erlaubt Erkennung von Paketverlusten erlaubt Erkennung der Reihenfolge erster Wert ist zufällig Zeitstempel 32 Bit wird formatabhängig bestimmt wird gegebenenfalls in einem Profil definiert erster Wert ist zufällig z.b. Audio: Nummer des ersten Samples im Paket bei durchlaufender Samplenummerierung C.14 2.2 RTP-Paketformat (3) Identifikation der Datenquelle Synchronization Source Identifier (SSRC) 32 Bit typisch: zufällig gewählt durch Sender bleibt während der Übertragung gleich erlaubt Identifikation einer von mehreren Quellen Identifikation beitragender Datenquellen Contributing Source Identifier (CSRC) 15 Stück möglich Zusatzelemente im Header möglich Extension-Bit C.15 2.2 RTP-Paketformat (4) Aufbau eines RTP-Pakets 0 4 8 12 16 20 24 28 32 V=2 P X CC M PT Sequence Number Time Stamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier... Padding Data PadNr V=2: Versionsnummer P=1: Padding am Paketende; P=0: kein Padding CC: Anzahl der Contributing Source Identifier M: Markierungsbit PT: Payload-Typ C.16
2.3 RTP-Control-Protocol (RTCP) Kontrollpakete Kommunikationspartner senden sich Kontrolldaten Aufgaben Rückmeldungen zu Paketverlusten implizite Round-Trip-Time-Berechnung Übermittlung von persistenten Angaben zu RTP-Quellen minimale Sitzungskontrolle z.b. Abbau von Sitzungen 2.3 RTP-Control-Protocol (2) Aufbau von RTCP-Daten verschiedene RTCP-Pakettypen Sender-Report (SR): Informationen von Sendern Receiver-Report (RR): Informationen von reinen Empfängern Source-Description-Items (SDES): nähere Angaben zur Quelle Sitzungsende (BYE): beendet die Teilnahme eines Teilnehmers Anwendungsabhängige Information (APP) typisch: mehrere RTCP-Pakete in einem Paket des Transportprotokolls fixer Header in jedem RTCP-Paket Längenangabe im Header Paketlänge immer Vielfaches von 32 Bit Padding im letzten Paket möglich, ähnlich wie bei RTP C.17 C.18 2.4 Receiver-Report (RR) 2.4 Receiver-Report (2) Mitteilungen von Empfängern 0 4 8 12 16 20 24 28 32 V=2 P RC PT=201 (RR) Length SSRC of Sender SSRC of 1st Source Fraction Lost Cumulative Number of Lost Pakets Last Sequence Number Interarrival Jitter Last Sender Report Time Stamp (LSR) Delay Since Last Sender Report (DLSR) SSRC of 2nd Source Fraction Lost Cumulative Number of Lost Pakets Last Sequence Number RC: Anzahl der Sender, über die berichtet wird pro Sender SSRC ein RR-Eintrag von 24 Byte Payload-Type: PT=201 C.19 RR-Eintrag SSRC des Senders, über den berichtet wird Anzahl der verlorenen Pakete seit Sitzungsbeginn Bruchteil der verlorenen Pakete seit letztem RR Fixkomma-Darstellung: ersten 8 Bit nach dem Komma Letzte Sequenznummer des Senders erweitert durch Überlaufzählung Jitter-Berechnung der Paketankunftzeiten Varianz der mittleren Abweichung von gesendeten Paketabständen zu empfangenen Paketabständen gemessen in RTP-Timestamp-Einheiten Realzeit-Stempel des letzten Sender-Reports des Senders Verzögerung seit dem letzten Sender-Report in 1/65536 s dient zur Round-Trip-Time-Berechnung C.20
2.5 Sender-Reports (SR) 2.5 Sender-Report (2) Mitteilungen von Sendern enthalten auch Receiver-Reports 0 4 8 12 16 20 24 28 32 V=2 P RC PT=200 (SR) Length SSRC of Sender NTP Time Stamp RTP Time Stamp Sender s Paket Count Sender s Octet Count SSRC of 1st Source Fraction Lost Cumulative Number of Lost Pakets Last Sequence Number Interarrival Jitter RC: Anzahl der Sender, über die berichtet wird Payload-Type: PT=200 C.21 Sender-Information Realzeit-Stempel des gesendeten Berichts im NTP-Format (64 Bit) Hinweis: LSR im RR enthält nur mittleren 32 Bit (ungenauer) RTP-Zeistempel des gesendeten Berichts im profilabhängigen Format ordnet RTP-Zeitstempel der realen Zeit zu Anzahl aller RTP-Pakete des Senders zu seiner SSRC Anzahl aller Oktets/Bytes des Senders zu seiner SSRC Empfänger-Informationen im selben Format wie beim RR C.22 2.6 Auswertung der Reports 2.7 Source-Description (SDES) Ableitbare Qualitätsmaße der RTP-Übertragung Round-Trip-Time Paketverluste Jitter verfügbare Bandbreite notwendiger Zwischenpuffer Anzeigeverzögerung Zuordnung der RTP-Zeistempel an die Realzeit Synchronisation zwischen verschiedenen Strömen möglich z.b. Audio und Video Zusatzangaben zum Sender 0 4 8 12 16 20 24 28 32 V=2 P SC PT=202 (SDES) Length SSRC of Sender Type Length Value Type Length Value SC: Anzahl der SDES-Einträge SDES-Einträge können beliebige Länge haben Padding mit Null-Bytes am Ende des Pakets für 32-Bit-Alignment C.23 C.24
2.7 Source-Description (2) 2.8 Übertragung über UDP/IP Typen CNAME (Type=1) Canonical Name möglichst eindeutige und haltbare Identifikation des Teilnehmers z.b. Benutzername@Rechnername z.b. hauck@ygramul.informatik.uni-ulm.de NAME (Type=2) Benutzername im Klartext z.b. Franz J. Hauck Nutzung z.b. als Teilnehmername bei Videokonferenz EMAIL (Type=3) Mail-Adresse des Benutzers z.b. franz.hauck@uni-ulm.de weitere Typen definiert (Telefonnummer, Ortsangabe...) C.25 User Datagram Protocol paketorientiertes Protokoll ungesichert Paketverlust, Paketverdoppelung, Umordnung der Reihenfolge Portnummer pro Rechner identifiziert Anwendung Adressierung erfolgt über IP-Adresse und Port RTP Nutzung eines lokalen Ports als Absenderadresse im Sender Nutzung eines lokalen Ports als Empfangsadresse im Empfänger gemeinsame Nutzung möglich C.26 2.8 Übertragung per UDP/IP (2) RTCP eigener Port vorgesehen typisch: RTCP-Port ist RTP-Port + 1 typisch: RTP-Port hat gerade Nummer Default-Ports für RTP/AVP RTP: 5004 RTCP: 5005 Wechsel des RTP-Payload-Types möglich Wechsel zwischen verschiedenen Codierungen 2.9 Internettelefonie über RTP Zwei RTP-Ströme zwischen zwei Telefonen jeder verschickt Sender-Reports über RTCP Anpassung der Codierung anhand von Qualitätsmaßen möglich Voraussetzung IP-Adresse und Portnummer der Gegenstelle bekannt Probleme IP-Adresse und Portnummer können sich theoretisch ändern Telefonnummer sollte gleich bleiben konfigurierbare Zuordnung wünschenswert Anruf und Klingeln? Wählton, Besetztton? Welche Formate versteht die Gegenstelle? C.27 C.28
3 SIP Session-Initiation-Protocol, SIP IETF Standard definiert in RFC 2543, 2976, 3087, 3261 3263, 3265, 3311, 3312 und viele weitere Zielsetzung Initiierung interaktiver Kommunikationssitzungen zwischen Benutzern End-zu-End-Signalisierung z.b. Audio, Video, Chat, Spiele, Virtual-Reality-Anwendungen etc. Management solcher Sitzungen Veränderung, Weiterleitung, Abbruch von Sitzungen Trägerprotokoll für Verhandlung über Fähigkeiten der Endgeräte und Netzwerkbetreiber Ressourcenreservierung integrierbar in die SIP-Interaktion C.29 3 SIP (2) Aufbau textbasiert ähnlich wie HTTP oder SMTP lesbares Protokoll leichtgewichtig basiert typischereise auf UDP/IP auch TCP/IP möglich Peer-to-Peer-Protokoll basiert aber teilweise auf zentralen Servern C.30 3.1 SIP-URI URI-Schema beginnt mit sip: Aufbau wie E-mail-Adresse lokaler Benutzername @ Domänenname z.b. sip:hauck@vs.informatik.uni-ulm.de Zweck eindeutige Identifikation von Benutzern oder Diensten z.b. sip:vod-server@t-online.de z.b. Internettelefonie ersetzt Telefonnummern der Teilnehmer klickbare URI im Webbrowser führt zu Verbindungsaufbau 3.2 SIP-User-Agent User-Agent (UA) SIP-Software bei einem Teilnehmer Clientseitiger User-Agent (UAC) schickt Anfrage an einen UAS Serverseitiger User-Agent (UAS) schickt Antworten an einen UAC User-Agent enthält typischerweitse UAC- und UAS-Funktionen C.31 C.32
3.3 Einfacher Verbindungsaufbau 3.3 Einfacher Verbindungsaufbau (2) Signalisierung eines VoIP-Anrufs Benutzer alice@a.com, bob@b.com alice@a.com INVITE bob@b.com bob@b.com Annahme IP-Adresse und Portnummer von Bobs IP-Phone (SIP) ist bekannt IP-Adresse und Portnummer für RTP-Session ist bekannt Payload-Types sind bekannt z.b. Bezug auf RTP/AVP 180 Ringing Verbindungsabbau Klingelton 200 OK ACK RTP-Session Telefon klingelt Bob nimmt ab alice@a.com BYE 200 OK bob@b.com C.33 hier: Abbau geht von Bob aus mit dem Abbau der SIP-Sitzung wird auch RTP-Session beendet C.34 3.3 Einfacher Verbindungsaufbau (3) Anfrage- und Antwortnachricht Transaktion besteht aus einer Anfrage- und evtl. mehreren Antwortnachrichten Sicherung der Nachrichtenübertragung Wiederholung der Anfragenachricht, wenn Antwort ausbleibt ACK-Anfrage, bei 200 OK Antwort Erkennung von Wiederholungen eindeutige Sequenznummer für alle Nachrichten in einer Transaktion eindeutige Session-ID für alle Nachrichten zu einer Session (Dialog) BYE Anfrage hat gleiche Session-ID, wie zugehörige INVITE Transaktion eindeutige Kennung für Sender und Empfänger URIs werden in eindeutige Tags überführt 3.4 SIP-Nachrichtenaufbau Anfragenachricht (Request) Beispiel der INVITE-Nachricht INVITE sip:bob@b.com SIP/2.0 Via: SIP/2.0/UDP pc33.a.com;branch=z9hg4bknashds8 Max-Forwards: 70 To: Bob <sip:bob@b.com> From: Alice <sip:alice@a.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.a.com> Content-Length: 0 Anfragezeile Methodenname INVITE, angesprochene URI, SIP-Versionsnummer C.35 C.36
3.4 SIP-Nachrichtenaufbau (2) Kopfzeilen Via-Header: enthält Routinginformation Adressen aller Sender auf dem Weg werden in der Nachricht gesammelt hier: Adresse von Alice SIP-UA branch: eindeutiger Bezeichner für diese Transaktion für Nachrichten von pc33.a.com Max-Forwards: wie oft darf die Nachricht weitergeleitet werden From und To: von wem an wen ist die Transaktion gerichtet Alice lädt Bob zur Session ein From-Header mit Tag: eindeutiger Bezeichner von Alice UA für den Dialog zwischen Alice und Bob Call-ID: eindeutiger Bezeichner für den Dialog zwischen Alice und Bob CSeq: Sequenznummer Contact: (SIP) URI unter der Teilnehmer erreichbar ist C.37 3.4 SIP-Nachrichtenaufbau (3) Antwortnachricht (Reply) Beispiel der 180-Ringing-Nachricht SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.a.com;branch=z9hg4bknashds8 To: Bob <sip:bob@b.com>;tag=a6c85cf From: Alice <sip:alice@a.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 Statuszeile SIP-Versionsnummer, Status-Code, Statusmeldung Status-Codes ähnlich wie bei HTTP C.38 3.4 SIP-Nachrichtenaufbau (4) 3.4 SIP-Nachrichtenaufbau (5) Status-Codes (Auswahl) 1xx provisorische Antwort 100 Trying 180 Ringing 2xx erfolgreiche Bearbeitung 200 OK 3xx Umleitung 301 Moved Permanently 302 Moved Temporarily 4xx Fehler 400 Bad Request 401 Unauthorized 403 Forbidden 5xx Serverinterne Fehler 6xx Globale Fehler C.39 Kopfzeilen To-Header mit Tag: eindeutiger Bezeichner von Bobs UA für den Dialog zwischen Alice und Bob Tripel von (To-Header-Tag, From-Header-Tag, Call-ID) beschreibt Dialog eindeutig Warum nicht Call-ID alleine: mehrere To-Header möglich zum Aufbau von Dialogen mit mehreren Teilnehmern Sitzungsmigration erfordert gleichbleibende Call-ID aber wechselnde From- und To-Tags C.40
3.5 Internettelefonie (1) Signalisierung über SIP Anruf, Klingeln, Abnehmen, Auflegen kann signalisiert werden Signaltöne (Klingelzeichen, Besetztzeichen) können generiert werden Problem IP-Adresse und Portnummer können sich theoretisch ändern Telefonnummer sollte gleich bleiben konfigurierbare Zuordnung wünschenswert Problem verschärft: IP-Adresse und Portnummer des SIP UA muss zusätzlich bekannt sein Welche Formate versteht die Gegenstelle? 3.6 SIP-Proxies Administrative Domänen nutzen SIP-Proxies Proxy leitet SIP-Nachrichten weiter Klingelton alice@a.com proxy.a.com INVITE bob@b.com 100 Trying 100 Trying 180 Ringing 180 Ringing 200 OK 200 OK ACK RTP-Session proxy.b.com 180 Ringing 200 OK bob@b.com Telefon klingelt Bob nimmt ab C.41 C.42 3.6 SIP-Proxies (2) 3.6 SIP-Proxies (3) Zusätzliche Nachrichten Proxies antworten mit 100 Trying zur Sicherung der Nachricht Via-Header sammeln die Adressen der Proxies ein sichert die Routinginformation für den Rückweg der Antworten Beispiel: INVITE-Nachricht von proxy.b.com an Bob INVITE sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP proxy.b.com;branch=z9hg4bk4b43c2ff8.1 Via: SIP/2.0/UDP proxy.a.com;branch=z9hg4bk77ef4c2312983.1 Via: SIP/2.0/UDP pc33.a.com;branch=z9hg4bknashds8 Max-Forwards: 68 To: Bob <sip:bob@b.com> From: Alice <sip:alice@a.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.a.com> Content-Length: 0 C.43 Zustandsbehaftete Proxies speichern Informationen über Dialoge können mit 100 Trying antworten Zustandslose Proxies lediglich Nachrichtenweiterleitung Vorteil eines Proxies feste Konfiguration der Proxy-Adresse für das Endgerät kann auch dynamisch ermittelt werden, z.b. DHCP IP-Adresse von Bobs Endgerät muss nicht bekannt sein Authentisierung der SIP-Adresse von Endgeräten möglich Offene Fragen Woher wissen die Proxies die Endgeräteadresse? Wie kann authentisiert werden? C.44
3.7 Registrierung der Teilnehmer 3.7 Registrierung der Teilnehmer (2) Registrarknoten z.b. von einer administrativen Domäne verwaltet initiale SIP REGISTER-Transaktion zum Registrar der Domäne alice@a.com registrar.a.com REGISTER 401 Unauthorized REGISTER 200 OK Authentisierung ähnlich HTTP-Digest-Authentication 401-Nachricht signalisiert notwendige Authentisierung identifiziert Benutzer in Domäne a.com C.45 Registrar verwaltet Kontaktadresse identifizierter Benutzer hat eine geräteunabhängige, zugeteilte SIP-URI z.b. alice@a.com bei Registrierung wird aktuelle geräteabhängige SIP-URI übermittelt z.b. alice@pc33.a.com Beispiel: REGISTER-Nachricht REGISTER sip:registrar.a.com SIP/2.0 Via: SIP/2.0/UDP pc33.a.com:5060;branch=z9hg4bknashds7 Max-Forwards: 70 To: Alice <sip:alice@a.com> From: Alice <sip:alice@a.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:alice@pc33.a.com> Expires: 7200 Content-Length: 0 C.46 3.7 Registrierung der Teilnehmer (3) 3.7 Registrierung der Teilnehmer (4) Dauer der Registrierung Halten der Registrierung für bestimmte Zeit im Beispiel 2 h= 7200 s danach Re-Registrierung nötig neue REGISTER-Nachricht mit gleicher Call-ID aber höherer CSeq-Nummer Registrare und Proxies Registrare arbeiten mit Proxy in Domäne zusammen kann auch gleicher UA sein Beispiel: proxy.b.com kennt aktuelle Kontaktadresse von Bob durch Registrierung Weitergabe von Nachrichten an Bobs aktuellen UA oder Verweis auf anderen Proxy, der Bobs Aufenthaltsort kennt Zusammenarbeit mit einem Location-Server kennt Kontaktadressen Proxy befragt Location-Server, Registrar befüllt Location Server C.47 Sicherheitsüberlegungen Wie kann falsche Registrierung verhindert werden? Authentisierung (Benutzername- und Passwort-Eingabe) Verschlüsselung der Nachrichten (siehe spätere Kapitel) Wie kann falscher Absender verhindert werden? Signatur der Nachrichten Prüfung in den Proxies oder im Endgeräte-UA Konfiguration des Registrars feste Konfiguration pro Domäne Multicastadresse: sip:sip.mcast.net wird zum nächsten Registrar geroutet antwortet mit 301 Moved auf richtigen Registrar C.48
3.7 Registrierung der Teilnehmer (5) 3.8 Routing im Proxy Offene Frage Woher weiß ein Proxy die Adresse eines anderen Proxies? Beispiel: Woher weiß proxy.a.com die Adresse sip:proxy.b.com des Proxy aus Domäne b.com? Beispiel: proxy.a.com empfängt INVITE-Nachricht INVITE sip:bob@b.com SIP/2.0 To: Bob <sip:bob@b.com> From: Alice <sip:alice@a.com>;tag=1928301774 Contact: <sip:alice@pc33.a.com>... DNS-Suche für b.com nach SRV/NAPTR-Records ermitteln die IP-Adresse des zugehörigen Proxies hier: proxy.b.com DNS-Suche für b.com nach A-Records ermittelt die IP-Adresse des Hosts b.com Weiterleitung der Nachricht an entsprechende Adresse C.49 C.50 3.9 Telefonnummern ITU Nummernplan E.164 Abbildung auf SIP URIs über ENUM, RFC 3761 und 3764 DNS-basiertes Abfragen der Adressen ENUM Abbildung einer Telefonnumer auf DNS-Namen z.b. +49.731.50.24143 wird zu 3.4.1.4.2.0.5.1.3.7.9.4.e164.arpa Abfrage von DNS NAPTR-Records ermittelt SIP URI Vorteil SIP-Nutzer kann eine gewöhnliche Telefonnummer haben Gateways können Telefongespräche an SIP URI weiterleiten SIP-Teilnehmer können sich auch über ihre E.164-Telefonnummern erreichen 4 SDP Session Description Protocol, SDP IETF-Standard, definiert in RFC 2327 Zielsetzung ursprünglich: Ankündigung von Multicast-Sitzungen Beschreibung von multimedialen Sitzungen Unicast und Multicast beschreibt Codierung beschreibt Transport kann Alternativen beschreiben zur Beschreibung der Gerätefähigkeiten geeignet Einbettung der Beschreibungen in andere Protokolle Signalisierungsprotokolle wie SIP, RTSP, SAP etc. C.51 C.52
4.1 Aufbau von SDP-Paketen 4.1 Aufbau von SDP-Paketen (2) Textbasiertes Protokoll UTF-8 Codierung zeilenweise Codierung Typ=Wert Typ ist nur ein Buchstabe Sitzungsbeschreibung Reihenfolge der Felder wie dargestellt Protokollversion immer 0 z.b.: v=0 Sender besteht aus Benutzername, Session-ID, Version, Netzwerktyp, Adresstyp und Adresse z.b.: o=hauck 4711 5 IN IP4 134.60.77.100 IN=Internet, IP4=IPv4 C.53 Sitzungsbeschreibung (fortges.) Sitzungsname z.b. s=phone Call from Alice textuelle Sitzungsbeschreibung (optional) z.b. i=phone Call URI zur Sitzung (optional) z.b. u=http://www-vs.informatik.uni-ulm.de/teach/ws06/mmk E-mail-Adresse (optional) z.b. e=franz.hauck@uni-ulm.de Telefonnummer (optional) z.b. p=+49 731 50 24143 Zugangsadresse (optional) z.b. c=in IP4 134.60.77.100 kann alternativ bei der Medienbeschreibung stehen C.54 4.1 Aufbau von SDP-Paketen (3) 4.1 Aufbau von SDP-Paketen (4) Sitzungsbeschreibung (fortges.) Bandbreiteninformation (optional) z.b. b=as:2000 Bedeutung: 2000 kbit/s maximal Bandbreite für diese Unicast-Sitzung Zeitzonenanpassung (optional) z.b. z=2882844526-1h 2898848070 0 Zeitpunkte (NTP-Zeitstempel) und Anpassungswert Verschlüsselungsinformation (optional) z.b. k=prompt Bedeutung: Abfrage eines Passworts für Entschlüsselung Attributzeilen (optional) können Erweiterungen enthalten z.b. a=<flag> z.b. a=<name>:<value> C.55 Zeitangaben Sitzungsstart und -ende z.b. t=3034423619 3042462419 Ende kann 0 sein: ohne Endeangabe Wiederholungsangaben z.b. r=7d 1h 0 25h Bedeutung: jede Woche für eine Stunde zum angegebenen Zeitpunkt und um 25h versetzt C.56
4.1 Aufbau von SDP-Paketen (5) 4.1 Aufbau von SDP-Paketen (6) Medienbeschreibung kann mehrfach hintereinander gestellt werden Medienbezeichnung schließt Transportadresse ein Format: m=<medium> <port> <transport> <formate> Medium: audio, video, application, control, data Port: Nummer(n) des/der Ports Transport: z.b. RTP/AVP oder udp Formate, z.b. bei RTP/AVP: Payload-Typen d.h. Codierungen z.b. m=audio 30000 RTP/AVP 0 8 9 unterstützte Codecs: PCM µ-law, PCM A-Law, G.722 C.57 Medienbeschreibung (fortges.) Medientitel (optional) z.b. i=videokanal Überwachungskamera Zugangsinformation (optional, falls schon Teil der Sitzungsbeschreibung) wie bei Sitzungsbeschreibung Bandbreiteninformation (optional) wie bei Sitzungsbeschreibung Verschlüsselungsinformation (optional) wie bei Sitzungsbeschreibung Attributzeilen (optional, mehrere möglich) Angaben zu Payload-Mappings (dynamisch zugewiesenen Payload-Types) z.b. a=rtpmap:0 PCMU/8000 Angabe zur Verwendung z.b. a=sendonly C.58 4.2 Internettelefonie 4.2 Internettelefonie (2) Nutzlast für SIP-INVITE-Nachricht von Alice an Bob v=0 o=alice 4711 1 IN IP4 14.15.1.230 s=phone Call c=in IP4 14.15.1.1230 t=3034423619 0 m=audio 49170 RTP/AVP 0 8 9 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/16000 Zusätzliche(r) SIP-Header Content-Type: application/sdp Content-Length: 214 Angabe der RTP- und RTCP-Ports sowie der IP-Adresse von Alice Angabe der Fähigkeiten verwendbare Codecs C.59 Nutzlast für 200-OK-Nachricht von Bob an Alice v=0 o=bob 489239 11 IN IP4 30.1.221.20 s=phone Call c=in IP4 30.1.221.20 t=3034423700 0 m=audio 31202 RTP/AVP 8 9 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/16000 Angabe der RTP- und RTCP-Ports sowie der IP-Adresse von Bob Angabe der Fähigkeiten verwendbare Codecs typisch: nur solche verwendet, die Alice bereits vorgeschlagen hat Signalisierung enthält Transportadressen Fähigkeiten der Geräte zur Codierung C.60
5 Referenzen 5 Referenzen (2) Verwendete Ressourcen, weitere Informationen Wikipedia. <www.wikipedia.org> ITWissen, das Online-Lexikon für Informationstechnologie. <www.itwissen.info> S. W. Smith: The Scientist and Engineer s guide to Digital Signal Processing. <www.dspguide.com> ITU-T, International Telecommunication Union, Telecom Standaradization. <www.itu.int> H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: RTP: A transport protocol for real-time applications. RFC 3550. July, 2003. H. Schulzrinne, S. Casner: RTP profile for audio and video conferences with minimal control. RFC 3551. July 2003. J. Rosenberg et al.: SIP: Session Initiation Protocol. RFC 3261. June 2002. J. Rosenberg, H. Schulzrinne: SIP: Locating SIP Servers. RFC 3263, June 2002. P. Faltstrom, M. Mealling: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). RFC 3761, April 2004. C.61 Verwendete Ressourcen, weitere Informationen (fortges.) J. Peterson: Enum Service Registration for Session Initiation Protocol (SIP) Addresses-of-Record. RFC 3764, April 2004. M. Handley, V. Jacobson: SDP: Session Description Protocol. RFC 2327. April 1998. G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne: Grouping of Media Lines in the Session Description Protocol (SDP). RFC 3388, Dec. 2002. IANA: SDP Parameters. <http://www.iana.org/assignments/sdp-parameters> C.62