Internet Protokolle für Multimedia - Anwendungen

Transkript

1 Internet Protokolle für Multimedia - Anwendungen Kapitel 5.6 RTP / RTCP 1

2 Gliederung RTP / RTCP Überblick Grundbegriffe RTP Nachrichtenformate RTCP Nachrichtenformate Wertung 2

3 RTP/RTCP Überblick (1) RTP (Real Time Transport Protocol, RFC1889) dient dem Transport von Echtzeitdaten in IP-Netzen. Vergibt Zeitstempel und Sequenznummern an A/V-Ströme, erlaubt Unterstützung unterschiedlicher Profile (RFC3550) RTCP (Real Time Control Protocol) ist Steuer- und Meldeprotokoll zu RTP (RFC3550) 3

4 RTP/RTCP Überblick (2) Aufgaben Übermittlung von Echtzeitmedien in RTP-Paketen über RTP-Sessions Garantie der Reihenfolge von RTP-Paketen mittels Sequenznummern Garantie der Isochronität mittels geeigneten Zeitstempeln (RTP) Transport unterschiedlicher Formate von Echtzeitmedien. Formate als Profile in RFC 3551 definiert. Einsatz von Translator und Mixer zur Formatkonvertierung bzw. Strom- Mischung Überwachung der Übertragungsqualität (RTCP) Identifikation einer Quelle (RTCP) Unterstützung von Mehrpunkt-Kommunikation (RTCP) 4

5 RTP / RTCP Überblick (3) Grundbegriffe RTP-Sitzung: Verbindung zwischen Tln-Gruppen, die über RTP kommunizieren. Sitzung ist für jeden Tln gegeben durch (Netzadresse, RTP-Port, RTCP-Port). Erlaubt Unicast/Multicast. Synchronisationsquelle, Synchronization Source, SSRC: Quelle eines RTP- Paketstroms (ursprüngliche Quelle) Teilnehmende Quelle, Contributing Source, CSRC: Quelle eines Stroms, der von einem RTP-Mischer erzeugt wurde, enthält Liste von SSRC- Kennungen Mischer, Mixer: vereinigt Ströme unterschiedl. Quellen, führt Zeitkorrekturen durch, wirkt als SSRC Übersetzer, Translator: Zwischensystem, das Formatkonvertierungen macht, ohne die Synchronisationsquelle zu ändern Monitor: überwacht RTCP-Pakete und wertet sie aus 5

6 RTP / RTCP Überblick (4) Mixer-Funktion 6

7 RTP / RTCP Überblick (5) Translator-Funktion 7

8 RTP / RTCP Überblick (6) RTP wird üblicherweise über UDP betrieben RTP kann auch über STII (Stream Protocol Version 2, RFC 1819) betrieben werden. STII unterstützt gerichtete Multicastströme und setzt nicht auf IP auf, sondern direkt auf ATM oder auf ATM AAL-Typ5. RTP ist ein Ende-zu-Ende-Protokoll. Voreinstellung Port 5004 Falls mehrere Ströme in Konferenz (z.b. A/V), dann für jeden Strom eigene RTP-Session 8

9 RTP PDU (1) 9

10 RTP PDU (2) Voice over IP: Overhead bei RTP. Bei Codierung G.711 mit 64 kbps (PCM) werden i.a. 256 Byte/Paket versendet, d.h. brutto 74 kbps und Paketisierungszeit 32 ms 10

11 RTP PDU (3) RTP-PDU-Format 11

12 RTP PDU (4) PDU-Felder V (Version) P (Padding): wird gesetzt, falls Nachricht mit Bytes aufgefüllt ist X (Extension): nicht benutzt CC (Contributor Count): Anzahl der beteiligten Quellkennungen M (Marker): anwendungsspezifisch, z.b. um Grenzen in einem Strom anzuzeigen PT (Payload Type): verweist auf Art der Nutzlast ( Tabelle) Zeitstempel: Abtastzeitpunkt des 1. Oktetts im RTP-Paket, erlaubt Berechnung über Synchronisierungs- und Signalschwankungen (Zeitstempel ist Zähler oder Uhrzeit) SSCR: Synchronisierungsquelle (zufälliger Wert) CSCR-List: Beitragende Quellen, deren Nr. in CC stehen. Kennungen werden von Mischern eingefügt 12

13 RTP PDU (5) Payload Types (RFC 3551) 13

14 RTCP Überblick Real Time Control Protocol (RTCP) unterstützt das Funktionieren von RTP (analog ICMP/IP oder ISDN-B/D-Kanäle) RTP-Daten fließen von Sender zu Empfänger, RTCP in beide Richtungen. RTCP ermöglicht loosely controlled session 14

15 RTCP PDU (1) 15

16 RTCP PDU (2) PDU-Felder (1) V (Version) P (Padding) RC (Receiver Block Count): gibt an, wieviel Empfängerblöcke in Nachricht enthalten PT (Packet Type): 200 (Absenderbericht): Aktive Sender senden und erhalten Statistiken 201 (Empfängerbericht): Empfänger erhalten nur Statistiken 202 (Quellbeschreibung): Quellbeschreibungskriterien einschl. CNAME 203 (Bye): Ende der Teilnahme 204 (Anwendungsspezifisch) Länge: des Absenderberichts SSRC: Synchronisierungsquell-ID (verbindet RTP- und RTCP-PDUs einer Quelle NTP: NTP-Zeit eines Berichts, gestattet Berechnung RTD und Sitzungszeiten, ferner Abschätzung der Frequenz der RTP-Uhr und damit der Synchronisation (RFC 1305) 16

17 RTCP PDU (3) PDU-Felder (2): im Senderbericht RTP-Timestamp: für Intra- und Intermediasynchronisation z.b. Interarrival Jitter gemäß H.225 ist Differenz der relativen Ü-Zeiten für 2 Pakete = Differenz zwischen RTP-Zeitstempeln der Pakete und der Empfängeruhrzeit zum Zeitpunkt der Paketankunft D i = R i S i Verzögerung des i-ten RTP-Paketes im Netz J(j,i) = D j D i = (R j R i ) (S j S i ), R Ankunftszeit, S Zeitstempel Jitterwerte lassen sich rekursiv berechnen: J 1 = 0, J 2 = J(2,1), J i = J i-1 + ( J(i,i-1) -J i-1 )/16 für i 3 J i ist Schätzer für Jitter nach Empfang des i-ten RTP-Pakets J i wird im Sender- und Empfänger-Report mittels RTCP geschickt Verzögerung gemessen in Timeticks = 1/65536s Paket- und Bytezählung des Senders 17

18 RTCP PDU (4) PDU-Felder (3) : im Empfängerbericht SSCR_n: Quellkennung, zu der dieser Empfangsbericht gehört % Verlust: Verlustrate = Verlustanzahl / erwartete RTP-Pakete Kumulierter Paketverlust: Gesamtzahl verlorener Pakete dieser Quelle = Anzahl erwartet Anzahl eingetroffen (inkl. verspätet oder Duplikat) erweiterte, höchste empfangene Sequenznr. Interarrival-Jitter (s.o.) Zeitpunkt letzter Senderbericht: mittlerer NTP-Zeitstempel des letzten Berichts Verzögerung seit dem letzten Senderbericht in Timeticks 18

19 RTCP PDU (5) Source Description Packet SDES (im PT = 202) enthält CNAME: NAME: PHONE: LOC: TOOL: NOTE: PRIV: BYE: APP: einmaliger, eindeutiger Name für Quelle Name des realen Nutzers der Quelle -Adresse Telefon-Nr Geographischer Ort Name der Anwendung, die den Datenstrom generiert Bemerkung über die Quelle (private Erweiterung) Good Bye - RTP - Paket Application-specific RTCP-Packet weiteres im RFC 1889/

20 RTCP: Abschätzung von RTD RTD-Berechnung aufgrund Angaben in Reports SR und RR RTD = DSR + DRR = A LSR DLSR, wobei A: Zeit, zu der das RTCP-Paket RR empfangen wurde LSR: Zeitstempel aus letztem empfangenen SR-Paket DLSR: Zeitabstand zwischen letzten SR-Empfang und Absenden RR 20

21 RTP- / RTCP Wertung keine Auslieferungsgarantie oder Verhinderung Auslieferung in falscher Reihenfolge. Sequenznr helfen bei der Rekonstruktion keine Mechanismen, um pünktliche Auslieferung oder andere QoS zu garantieren. Rückgriff auf untere Schichten RTCP-Receiver Reports helfen QoS-Monitoren, Infos über Verluste und Jitter zu sammeln. Sender Reports informieren Empfänger über Session-Dauer und helfen bei der Uhrensynchronisation für zeitgerechte Präsentation der MM- Ströme Mittels Reports kann in den Routern ein Soft State gehalten werden RTP unterstützt Multicast RTP oft in der Anwendung direkt integriert RTCP skaliert schlecht bei RTP-Multicast 21

22 RTP- / RTCP Erweiterungen: SRTP, CRTP SRTP (Secure RTP in RFC 3711) Vertraulichkeit durch Verschlüsselung der RTP-Pakete Authentifizierung des Absenders gegen Identitäts-Spoofing Überprüfung der Integrität über Hashoperation HMAC-SHA1 (RFC 2104) Anti-Replay-Schutz SRTP setzt ein Key Management Protocol voraus, z.b. MIKEY (RFC 3830). Ferner muss für jede RTP-Session ein kryptographischer Kontext erzeugt werden. Entsprechende Absicherung von RTP durch SRTP Kompression des RTP / UDP / IP-Headers mittels der Protokolle CRTP (Compressed RTP, RFC 2508) und ROHC (Robust Header Compression, RFC 3095) 22