Protokolle für das Streaming

Das Übertragen von Daten über das Internet bedient sich einer Vielzahl an Protokollen und Mechanismen. Während statische Inhalte wie Bilder, Texte und Dokumente unter zu Hilfenahme der Standard Internet-Protokolle HTTP (Hypertext Transfer Protocol) und FTP (File Transfer Protocol) zum Benutzer übertragen werden können, benötigen Audio- und Videodaten die in Echtzeit übertragen werden sollen, einen komplexeren Weg. Bei der Übertragung von solchen Echtzeit-Inhalten, ist man bemüht eine flüssige Wiedergabe beim Empfänger zu gewährleisten.

Während bei einer normalen Übertragung, zum Beispiel bei der Übertragung eines Bildes, erst alle Daten auf den eigenen Rechner übertragen werden müssen bevor diese genutzt werden können, ist genau dieser Effekt bei der Übertragung von Audio- und Videodaten in Echtzeit unerwünscht, da dieser Mechanismus bei grossen Datenmengen unter Umständen mehrere Minuten bis Stunden dauern kann.

Da solche Echtzeit-Inhalte innerhalb einer kurzen Zeitspanne verschickt und empfangen werden müssen, bedarf es verschiedener spezieller Mechanismen und Protokollen die diesen Datenverkehr gewährleisten können, sogenannten Streaming Protokollen.

Erreicht wird  eine flüssige Wiedergabe beim Empfänger durch eine zeitweilige Ersetzung der normalen HTTP-Protokollschicht durch die Streaming-Protokollschichten und eine Intelligente Zwischenpufferung während der Übertragung.

{Internet-Technologien der Zukunft, ADDISON-WESLEY Verlag, ISBN: 3-8273-1556-8}
{Diplomarbeit, Steffen Lötzsch, Technische Universität Chemnitz,28.Februar 2002, M:DA 60302}

Das Realtime Protokoll

Das RTP-Protokoll wurde speziell zur Unterstützung von Echtzeitübertragungen entworfen. Bei solchen Übertragungen reicht es in der Regel nicht aus, wie bei einer herkömmlichen Übertragung, eine Verbindung zwischen einem Client und einem Server aufzubauen, ggf. benötigte Ressourcen zu reservieren und die Daten zu verschicken.

Für einen Echtzeit-Transport muss der Datenstrom in Pakete aufgeteilt werden. Diese Pakete werden getrennt voneinander an einen oder an mehrere Empfänger verschickt. Der Empfänger muss diese Pakete empfangen und in der korrekten Reihenfolge wieder zusammensetzen und ggf. mit anderen Signalen synchronisieren.

Das RTP-Protokoll setzt im OSI-7-Schichtenmodell auf der Applikationsebene an, es ist also kein Teil der Transportschicht wie man vermuten könnte. Das Protokoll ist unabhängig von der zugrunde liegenden Transportplattform, wird aber meist zusammen mit den Protokollen IP und UDP verwendet.

Das RTP-Protokoll ist ein sogenanntes Kapselungsprotokoll. Das bedeutet, dass in dem Datenfeld des RTP-Packets die zu transportierenden Echzeitinformationen stehen und die Informationen über den Verkehrstyp, also welche Daten das Packet gerade transportiert, im RTP-Header hinterlegt sind.

~~~~

Das Grundprinzip des Protokolls wird in den beiden Standards RFC 1889 (RTP: A Transport Protocol for Real Time Applications) und 1890 (RTP Profile for Audio and Video Conferences with Minimal Control) spezifiziert. Darüber hinaus gibt es eine Reihe von weiteren Standards, die beschreiben, wie bestimmte Audio- und Videoformate (z. B. JPEG, MPEG-1, MPEG-2, H.261, H.263) für die RTP-Übertragung zu verarbeiten sind.

RTP hat sich als wichtige Technik beim “Streamen” von Audio und Videosignalen in Video-on-Demand Anwendungen etabliert und ist unter der Bezeichnung H.225.0 auch Bestandteil des ITU H.323 Standards für Videokonferenzen in IP-Netzen. RTP unterstützt die Übertragung vom Multimedia Daten, enthält aber keine Funktionen zur Flußsteuerung und Fehlerkontrolle (Retransmission) sowie keine Ressourcenreservierung und bietet keinen garantierten Quality of Service (QoS).

Das Grundprinzip von RTP beruht darauf, dass der Sender Audio- und Videodaten in RTP-Pakete verpackt und mit Zusatzinformationen versieht, die vom Empfänger zur Verbesserung der Audio- und Videodarstellung ausgenutzt werden können. Die Zusatzinformationen beinhalten dabei Sequenznummern, Zeitmarken (typ. Auflösung für Video: 65 536 Hz, für Audio: Sample rate) zur Kennzeichnung zusammengehörender Audio- und Videofragmente (Beispiel: Video-Pakete eines Frames), eindeutige Identifikationsnummern (verbindungsorientiert) und eine Kennzeichnung der verwendeten Quellencodierung (”Payload Type”). Beim Streamen eines Videoclips, der Audio und Videodaten enthält, werden beide Komponenten meist als getrennte Streams behandelt und an verschiedene Ports adressiert.

Das RTP-Protokoll im Empfänger nutzt die Sequenznummern zur Erkennung verlorener oder vertauschter Pakete (UDP ist ein unzuverlässiges Transportprotokoll!) und die Zeitmarken zur Resynchronisation eines (Intra-) oder mehrerer (Inter-) Streams (z.B. zur Lippensynchronisation von Audio und Video).

RTP unterstützt Multicast durch spezielle Netzknoten zwischen Sender und Empfänger - sogenannte “RTP-Mixers”, die Ströme verschiedener Quellen zu einem Strom zusammenfassen können. Außerdem gleichen die Mixer Laufzeitunterschiede durch unterschiedliche Wege aus. Eine solche Funktionalität wird z.B. für Mehrpunkt-Videokonferenzen mit der Weiterverteilung eines Multiplexstroms an alle Teilnehmer benötigt.

RTP wird durch das Real Time Transport Control Protocol (RTCP) ergänzt, dessen Aufgabe die Überwachung der Netzparameter und Verwaltung der Teilnehmer an einer RTP-Sitzung ist. Zur Überwachung der Netzparameter tauschen alle RTP-Sender und RTP-Empfänger periodisch Statusinformationen über den jeweiligen QoS aus. Diese Information kann genutzt werden, um die Datenrate des Senders anzupassen (”Media Scaling”). Der Senderbericht enthält dabei Daten wie die Zeitstempel der Ströme, Zählerstände zur Anzahl der gesendeten RTP-Pakete und Bytes. Der Empfängerbericht enthält Informationen über die höchste empfangene Sequenznummer, die Anzahl der verlorenen Pakete, die zeitliche Schwankung der eingegangenen Pakete.