2.4. RTP - Real-Time Transport Protocol

2.4.1 Warum ein weiteres Transportprotokoll?

Die im Internet hauptsächlich verwendeten Transportprotokolle sind UDP und TCP. Betrachten wir zunächst deren Eignung für den Transport von multimedialen Daten (Sound, Video,  ...) in Echtzeit:

UDP leistet allerdings keine Erhaltung der Reihenfolge und liefert auch keinen zeitlichen Bezug der Pakete untereinander ("Echtzeit"). Das war der Anlaß zur Entwicklung eines weiteren Transportprotokolls.

RTP (Real-Time Transport Protocol) ist ein Protokoll für den Transport von Echtzeitdaten. Es wurde als Transportprotokoll für multimediale Konferenzsysteme entwickelt, kann aber natürlich auch zum Transport anderer Daten mit Echtzeit-Forderungen verwendet werden.

RTP ist für den Transport von Nutzdaten verantwortlich. Für die Steuerung und Überwachung des RTP-Datenflusses gibt es das Hilfsprotokoll RTCP (Real-Time Transport Control Protocol). Bei RTP handelt es sich um ein unidirektionales Protokoll (in eine Richtung), während RTCP ein bidirektionales Protokoll ist.

Die folgende Abbildung zeigt eine typische Konstellation bei der Anwendung von RTP:

Dabei fällt auf, daß RTP auch "oberhalb" von UDP eingesetzt werden kann; das ist sogar die dominierende Betriebsweise.

Bei der Nutzung von RTP über UDP kann RTP auf folgenden Eigenschaften von UDP aufbauen:

Bisherige Implementierungen von RTP/RTCP sind nicht Bestandteil der Betriebssystem-Kerne. Vielmehr kommt eine Technik zur Anwendung, die als Application Level Framing (ALF) bezeichnet wird. Dabei implementiert man die Funktionalität eines Protokolls in der jeweiligen Anwendung, die die Dienste des Protokolls nutzen will.

Der dabei zu erzielende Performancegewinn resultiert aus der Tatsache, daß jede Anwendung selbst die Erstellung und Verarbeitung von RTP-Datenpaketen (Nutzdaten und Köpfe) übernimmt. Somit ergibt sich die Möglichkeit, daß eine Anwendung den Paketaufbau und die Paketverarbeitung nach ihren spezifischen Bedürfnissen durchführen kann. Die Anpassungen an die Anforderungen der Anwendung wird durch sogenannte Profile erreicht, die erst die konkrete Bedeutung von bestimmten Feldern im RTP-Kopf definieren. Profile für den Transport von Audio- und Videodaten sind in RFC 1890 spezifiziert.

Der Name Real-Time Transport Protocol verleitet zu der Annahme, daß das Protokoll eine garantierte Dienstqualität (QoS - Quality of Service) für den Datentransport bieten kann. Das ist aber nicht der Fall. Für die Einhaltung von Dienstqualitäten müssen andere Protokolle, wie zum Beispiel RSVP (Resource ReSerVation Protocol) [http://www.isi.edu/div7/rsvp/rsvp.html], sorgen. Geschieht dies nicht, steht einer Anwendung nur ein Dienst unbekannter und möglicherweise stark schwankender Güte zur Verfügung.

Verwendet man RTP über UDP, dann erfolgt selbst der Transport der RTP-Pakete nicht zuverlässig. RTP bietet Möglichkeiten an, um Übertragungsfehler zu bemerken. Die Anwendungen müssen dann die auftretenden Fehler behandeln.

Durch RTP werden folgende Dienste erbracht:

Konferenzsysteme werden wohl am häufigsten von RTP Gebrauch machen. Innerhalb einer Konferenz werden meist verschiedene Medien (Nutzdatentypen) für die Kommunikation verwendet ("Multimedia-Konferenz"). So ist die gleichzeitige Nutzung von Audio, Video und einer gemeinsamen Arbeitsfläche (Shared Whiteboard) keine Seltenheit. Für jedes dieser Medien wird eine eigene Multicast-Adresse verwendet und eine eigene RTP-Session gebildet.

Gemäß RFC 1889 versteht man unter einer RTP-Session eine Verbindung zwischen verschiedenen Teilnehmern, die unter Verwendung von RTP miteinander kommunizieren. Jeder Teilnehmer identifiziert die Session durch ein eigenes Paar Transportadressen (eine Netzwerk-Adresse und ein Port-Paar für RTP und RTCP). Dieses Transportadressen-Paar kann, z.B. bei der Verwendung von IP-Multicast, für alle Teilnehmer identisch sein oder sich für jeden Teilnehmer unterscheiden, wie dies für Unicast-Kommunikationsbeziehungen typisch ist, wobei dort in der Regel jeder Teilnehmer seine individuelle Unicast-Adresse zusammen mit einem für alle Teilnehmer einheitlichen Port-Paar verwendet.

Die Aufteilung der Medien auf verschiedene Multicast-Gruppen (bzw. Sessions) erlaubt jedem Konferenzteilnehmer, selbst zu entscheiden, welche Sessions er empfangen möchte. Bei knapper Bandbreite begnügt er sich vielleicht mit dem Shared Whiteboard und dem Ton.


Frage 2.4.1.1:

Welches Transportprotokoll wäre am besten geeignet, wenn ein Web-Server Videos zum Abspielen liefern möchte (begründen Sie bitte Ihre Aussage)?


Vertiefung:

Die RFCs 1889 (RTP: A Transport Protocol for Real-Time Applications) und 1890 (RTP Profile for Audio and Video Conferences with Minimal Control) enthalten eine Spezifikation des RTP, bei dem es sich laut RFC 2400 (INTERNET OFFICIAL PROTOCOL STANDARDS) um ein Proposed Standard Protocol handelt.

Die Audio/Video Transport Working Group der IETF veröffentlicht auf ihrer WWW-Seite [http://www.ietf.org/html.charters/avt-charter.html] aktuelle Informationen zum RTP. Hier finden Sie Verweise auf eine Vielzahl von Dokumenten, z.B. auf RFCs, die unterschiedliche Payload-Formate (JPEG, H.261, H.263, MPEG1/MPEG2, ...) dokumentieren, auf Internet Drafts, die Weiterentwicklungen des Protokolls beschreiben, sowie die von Henning Schulzrinne, Mitautor der RFCs 1889/1890, zusammengestellte FAQ-Liste [http://www.cs.columbia.edu/~hgs/rtp/faq.html].


© Patrick Voigt, Uwe Hübner, Holger Trapp, 8.2.1999