Real-Time Transport Protocol

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

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 standardisiert. 2003 wurde ein überarbeiteter RFC veröffentlicht. Der RFC 3550 löst damit den RFC 1889 ab.

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. Das RealTime Control Protocol arbeitet mit RTP zusammen und dient der Aushandlung und Einhaltung von Quality of Service (QoS) Parametern.

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

Während das Real-Time Streaming Protocol (RTSP) der Steuerung und Kontrolle der Datenübertragung dient, besteht die Funktion von RTP hauptsächlich in der Übertragung echtzeitsensitiver Datenströme.

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

[Bearbeiten] Architektur

Synchronisation Source

Die Datenquelle wird als Synchronisation Source bezeichnet und durch einen Identifikator (32 Bit) im Header gekennzeichnet.

Mixer

Als Mixer werden Vermittlungsstellen bezeichnet, die die RTP- Pakete von einer oder mehreren Quellen empfangen und diese weiterleiten. Der Begriff "Mixer" erklärt sich dadurch, dass die Vermittlungsstellen die Pakete mischen (und zeitlich synchronisieren) bzw. Formatumwandlungen durchführen können.

Translator

Solche Vermittlungsstellen, die die Pakete ohne Änderung weiterleiten, beispielsweise um sie durch eine Firewall zu befördern, nennt man Translator.

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.

RTP garantiert noch keine wirkliche Übertragung in Echtzeit, bietet jedoch passende Mechanismen.

[Bearbeiten] RTP-Header

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)
sychronization 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-Oktets am Ende des Pakets angehängt sind, die nicht zum eigentlichen Dateninhalt (Payload) gehören. Das letzte Füll-Oktet gibt die Anzahl der hinzugefügten Füll-Oktets an. Füll-Oktets 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.

CRSC 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.
Payload Type (PT), 7 bit: Dieses Feld beschreibt das Format des zu transportierenden RTP-Inhalts (payload).
Sequence Number: 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 Pakete erkennen.
Timestamp, 32 bit: Der Zeitstempel gibt den Zeitpunkt des ersten Oktets des RTP-Datenpakets an. Der Zeitpunkt muss sich an einem Takt orientieren, der kontinuierlich und linear zur Verfügung steht, damit die Synchronität des Streams sichergestellt und die Laufzeitunterschiede der Übertragungsstrecke (Jitter) ermittelt werden können.
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 Indentifikation der Quellen, die im RTP-Payload 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.