Real-Time Transport Protocol

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
RTP (Real-Time Transport Protocol)
Familie: Netzwerkprotokoll
Einsatzgebiet: Transport von Medien-Streams
Port: beliebiger freier, gerader Port ab 1024
RTP im TCP/IP-Protokollstapel:
Anwendung RTP
Transport UDP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI
Standard: RFC 3550 (RTP: A Transport Protocol
for Real-Time Applications), 2003[1]

Das Real-Time Transport Protocol (RTP) ist ein Protokoll zur kontinuierlichen Übertragung von audiovisuellen Daten (Streams) über IP-basierte Netzwerke. Das Protokoll wurde erstmals 1996 im RFC 1889[2] standardisiert. 2003 wurde es durch RFC 3550 abgelöst.

Es dient dazu, Multimedia-Datenströme (Audio, Video, Text etc.) über Netzwerke zu transportieren, d. h. die Daten zu kodieren, zu paketieren und zu versenden. RTP ist ein Paket-basiertes Protokoll und wird normalerweise über UDP betrieben. RTP kann sowohl für Unicast-Verbindungen als auch für Multicast-Kommunikation im Internet eingesetzt werden. Das RealTime Control Protocol (RTCP) arbeitet mit RTP zusammen und dient der Aushandlung und Einhaltung von Quality-of-Service-Parametern (QoS).

Es findet Anwendung in vielen Bereichen, u. a. wird es bei den IP-Telefonie-Standards H.323 und SIP dazu verwendet, die Audio- und Videoströme des Gespräches zu übertragen.

Die Funktion von RTP besteht hauptsächlich in der Übertragung von Datenströmen, die Echtzeit benötigen, während das Real-Time Streaming Protocol (RTSP) der Steuerung und Kontrolle der Datenübertragung dient.

Das Datagram Congestion Control Protocol (DCCP) ist ein aktueller Ansatz, um auch für Medienströme auf RTP/UDP-Basis Staukontrolle zu ermöglichen.

Synchronization Source
Die Datenquelle wird als Synchronization Source (SSRC) bezeichnet und durch einen Identifikator (32 Bit) im Header gekennzeichnet.
Translator
Ein Translator leitet eingehende RTP-Pakete weiter und lässt dabei den SSRC-Identifikator intakt. Translator können die Daten unverändert lassen und dienen zum Beispiel zum Überwinden von Firewalls. Sie können jedoch auch die Kodierung der übertragenen Daten verändern, dabei müssen im Header die Felder Payload Type und Timestamp angepasst werden. Die Umkodierung geschieht für den Empfänger transparent.
Mixer
Mixer kombinieren die Datenströme mehrerer Quellen zu einem neuen Datenstrom und leiten diesen weiter. Dabei kann auch die Kodierung verändert werden. Da die Datenströme der zu kombinierenden Quellen nicht zwangsweise synchronisiert sind, muss der Mixer ein eigenes Timing für den kombinierten Stream erzeugen. Aus diesem Grund trägt der Mixer bei allen ausgehenden Paketen seine eigene SSRC-ID in das entsprechende Feld ein. Um die Identität der ursprünglichen Quellen zu bewahren, werden deren SSRC-Identifikatoren in die Liste der CSRC-Identifikatoren eingetragen.
Empfänger
Der Empfänger der RTP-Pakete sortiert diese anhand der Sequenznummern und stellt sie der jeweiligen Anwendung zur Verfügung.
RTP-Paket
Ein RTP-Paket besteht aus einem Header mit Versions- und Sequenznummer, Datenformat, Sender-ID und Zeitstempel und dem Nutzdatenteil.
Byte 0 Byte 1 Byte 2 Byte 3
Bit 0 1 2 3 4 5 6 7 Bit 0 1 2 3 4 5 6 7 Bit 0 1 2 3 4 5 6 7 Bit 0 1 2 3 4 5 6 7
V=2 P X CC M PT Sequence Number
Timestamp (in sample rate units)
Synchronization Source (SSRC) identifier
Contributing Source (CSRC) identifiers (optional)
Header Extension (optional)
Version (V), 2 bit
Versionsstand des RTP-Protokolls
Padding (P), 1 bit
Das Füll-Bit ist gesetzt, wenn ein oder mehrere Füll-Bytes am Ende des Pakets angehängt sind, die nicht zum eigentlichen Dateninhalt (Payload) gehören. Das letzte Füll-Byte gibt die Anzahl der hinzugefügten Füll-Byte an. Füll-Byte werden nur dann benötigt, wenn nachfolgende Protokolle eine vorgegebene Blockgröße benötigen, z. B. Verschlüsselungsalgorithmen.
Extension (X), 1 bit
Das Erweiterungs-Bit ist gesetzt, wenn der Header um genau einen Erweiterungs-Header ergänzt wird.
CSRC Count (CC), 4 bit
Der CSRC-Zähler gibt die Anzahl der CSRC-Identifier an.
Marker (M), 1 bit
Das Marker-Bit ist für anwendungsspezifische Verwendungen reserviert. Es wird genutzt zur Kennzeichnung von Ereignissen, z. B. dem Auftreten des Endes eines Einzelbildes einer Videosequenz.
Payload Type (PT), 7 bit
Dieses Feld beschreibt das Format des zu transportierenden RTP-Inhalts, also der Nutzdaten (Payload).
Payloadnr. Codec Audio/Video Abtastrate Audiokanäle RFC
0 PCMU A 8 kHz 1 3551
3 GSM A 8 kHz 1 3551
4 G723 A 8 kHz 1 3551
5 DVI4 A 8 kHz 1 3551
6 DVI4 A 16 kHz 1 3551
7 LPC A 8 kHz 1 3551
8 PCMA A 8 kHz 1 3551
9 G.722 A 8 kHz 1 3551
10 L16 A 44,1 kHz 2 3551
11 L16 A 44,1 kHz 1 3551
12 QCELP A 8 kHz 1 3551
13 CN A 8 kHz 1 3389
14 MPA A 90 kHz 1 3551, 2250
15 G.728 A 8 kHz 1 3551
16 DVI4 A 11,025 kHz 1
17 DVI4 A 22,05 kHz 1
18 G.729 A 8 kHz 1 3551
25 CelB V 90 kHz 3551, 2029
26 JPEG V 90 kHz 3551, 2435
28 nv V 90 kHz 3551
31 H.261 V 90 kHz 3551, 2032
32 MPV V 90 kHz 3551, 2250
33 MP2T AV 90 kHz 3551, 2250
34 H.263 V 90 kHz 3551, 2250
96-127 dynamisch 3551
Sequence Number, 16 bit
Die Sequenznummer wird für jedes weitere RTP-Datenpaket erhöht. Die Startnummer wird zufällig ausgewählt und ist nicht vorherbestimmbar. Der Empfänger kann mit Hilfe der Sequenznummer die Paketreihenfolge wiederherstellen und den Verlust von Paketen erkennen.
Timestamp, 32 bit
Der Zeitstempel gibt den Zeitpunkt des ersten Bytes des RTP-Datenpakets an. Der Zeitpunkt muss sich an einem Takt orientieren, der kontinuierlich und linear ist, damit die Synchronität des Streams sichergestellt und Laufzeitunterschiede der Übertragungsstrecke (Jitter) ermittelt werden können. Der Startwert sollte wie die Sequenznummer ein zufälliger Wert sein. Aufeinanderfolgende Pakete können den gleichen Zeitstempel haben, wenn die transportierten Daten z. B. zum selben Einzelbild ("video frame") gehören. Pakete mit aufeinanderfolgenden Sequenznummern können aber auch nicht aufeinanderfolgende Zeitstempel enthalten, wenn wie z. B. bei komprimiertem Video Übertragungs- und Wiedergabereihenfolge nicht übereinstimmen.
SSRC, 32 bit
Dieses Feld dient zur Identifikation der Synchronisationsquelle. Der Wert wird zufällig ermittelt, damit nicht zwei Quellen innerhalb der RTP-Session die gleiche Identifikationsnummer besitzen.
CSRC List, 0 bis 15 Felder je 32 bit
Die CSRC-Liste dient zur Identifikation der Quellen, die in den RTP-Nutzdaten enthalten sind. Die Anzahl der Listenfelder wird im CC-Feld angegeben. Falls mehr als 15 Quellen vorkommen, werden nur 15 identifiziert. Die Liste wird von Mixern eingefügt, die dazu den Inhalt des SSRC-Feldes der beteiligten Quellen einsetzen.
  • Ulrich Trick, Frank Weber: SIP, TCP/IP und Telekommunikationsnetze. 2. Auflage. Oldenbourg, 2005, ISBN 3-486-57796-4.

Normen und Standards

[Bearbeiten | Quelltext bearbeiten]

Hauptlinie:

  • RFC 1889 – RTP: A Transport Protocol for Real-Time Applications. 1996 (veraltet, englisch).
  • RFC 3550 – RTP: A Transport Protocol for Real-Time Applications. 2003 (aktuell, englisch).
    • RFC 5506 – Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences. 2009 (Ergänzung, aktuell, englisch).
    • RFC 5761 – Multiplexing RTP Data and Control Packets on a Single Port. 2010 (Ergänzung, aktuell, englisch).
    • RFC 6051 – Rapid Synchronisation of RTP Flows. 2010 (Ergänzung, aktuell, englisch).
    • RFC 7022 – Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). 2013 (Ergänzung, aktuell, englisch).
    • RFC 7160 – Support for Multiple Clock Rates in an RTP Session. 2014 (Ergänzung, aktuell, englisch).
    • RFC 7164 – RTP and Leap Seconds. 2014 (Ergänzung, aktuell, englisch).
    • RFC 8083 – Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions. 2017 (Ergänzung, aktuell, englisch).

Nebenlinie:

    • RFC 1890 – RTP Profile for Audio and Video Conferences with Minimal Control. 1996 (veraltet, englisch).
    • RFC 3551 – RTP Profile for Audio and Video Conferences with Minimal Control. 2003 (aktuell, englisch).
    • RFC 7007 – Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP). 2013 (Ergänzung, aktuell, englisch).

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. RFC 3550 – RTP: A Transport Protocol for Real-Time Applications. 2003 (englisch).
  2. RFC 1889 – RTP: A Transport Protocol for Real-Time Applications. 1996 (englisch).
  3. Finley Breese: Serial Communication over RTP/CDP. Books on Demand, 2010, ISBN 978-3-8391-8460-8 (google.de).