Motivation: Wozu RTP?

Wie wir gerade gesehen haben, ist RSVP nicht für den Transport von Nutzdaten zuständig. Dies leistet das Realtime Transport Protocol (RTP).

Um Multimedia-Anwendungen wie Videokonferenzen über das Netz betreiben zu können, genügt es in der Regel nicht, eine Netzverbindung aufzubauen, ggf. benötigte Ressourcen zu reservieren und die Nutzdaten ohne weitere Maßnahmen darüber zu verschicken.

Zum Transport muss der Datenstrom in Pakete aufgeteilt werden, die getrennt verschickt werden - je nach Anwendung an einen oder mehrere Empfänger (Multicast). An den Empfängern müssen diese Pakete in der richtigen Reihenfolge zusammengesetzt (Resequencing) und unter Umständen mit anderen eintreffenden Strömen synchronisiert werden. Zudem müssen Empfänger sich während der Übertragung an variable Dienstqualitäten (QoS) anpassen können und benötigen Informationen über die an der Übertragung teilnehmenden Stationen (Meta-Daten).

Da das Nutzdatenprotokoll dies nicht selbst leisten kann, werden die Nutzdaten in das Realtime Transport Protocol (RTP) "eingepackt".

Aufgaben von RTP

RTP stellt Dienste zur Verfügung, um Echtzeitdaten zwischen den Endpunkten einer Unicast- oder Multicast-Umgebung zu übertragen. Zu diesen Diensten gehören die Kennzeichnung der übertragenen Nutzdaten und ihrer Quellen, die Vergabe von Sequenznummern und Zeitstempeln an Datenpakete, die Kontrolle der zur Verfügung stehenden Dienstqualität (QoS) sowie die Übertragung von Informationen über die Teilnehmer.

Die letzten beiden Dienste werden dabei nicht vom Datentransferprotokoll RTP selbst, sondern von dem zugehörigen Kontrollprotokoll RTCP (RTP Control Protocol) bereitgestellt.

Dabei ist zu beachten, dass RTP nicht für die Durchsetzung einer bestimmten Quality of Service verantwortlich ist und auch nicht garantiert, dass Pakete in der richtigen Reihenfolge, synchron oder überhaupt am Empfänger eintreffen. Ersteres kann z.B. durch Einsatz von RSVP erreicht werden, letzteres muss die Anwendung anhand der von RTP bereitgestellten Daten (Sequenznummern und Zeitstempel) selbst handhaben.

Protokoll-Architektur

Um ein Protokoll erweiterbar zu halten, wird es üblicherweise sehr allgemein spezifiziert, enthält Möglichkeiten zur Definition optionaler Felder oder ähnliche Mechanismen. Diese Flexibilität erfordert jedoch aufwändiges Parsen der Protokollheader - ein Overhead, der bei Echtzeitdaten unerwünscht ist.

Die Architektur des RTP-Protokolls unterscheidet sich darum von der anderer Protokolle: Die Veränderung oder Erweiterung der RTP-Header zur Anpassung an bestimmte Anwendungsklassen ist ausdrücklich erlaubt. Solche Änderungen des RTP-Kerns werden in Profile Specifications definiert, die für eine bestimmte Klasse von Anwendungen gelten (z.B. Audio- und Videokonferenzen [RFC 1890]). Eine Profile Specification bildet zugleich das Bindeglied zwischen dem RTP-Kern und den Payload Format Specifications, die definieren, wie konkrete Nutzdatenformate (z.B. H.263-Videoströme [RFC 2190]) zum Transport in RTP "verpackt" werden.

Beispiel: Kapselung von H.263

Als Beispiel betrachten wir, wie H.263-Videodaten in RTP-Paketen gekapselt werden:

Nach dem RTP-Header mit den bereits besprochenen Feldern folgt ein Header, der die übertragenen Nutzdaten (hier den H.263-Videostrom) beschreibt. Die Felder dieses Headers werden in der entsprechenden Payload Format Specification [RFC 2190] definiert.

Der Videostrom selbst folgt dann nach dem H.263-Nutzdatenheader. Auch sein Format ist in der Payload Format Specification beschrieben. Im Fall von H.263 kann der Ausgabestrom des Encoders z.B. direkt in Pakete aufgeteilt werden. Für jedes Einzelbild wird der H.263-Bitstrom selbst inclusive seines Bildheaders etc. im RTP-Nutzdatenbereich gespeichert.

< Fazit: RSVP | Anwendungsfälle >