Zum Hauptinhalt springen

1. Introduction (Einführung)

Dieses Memorandum spezifiziert das Echtzeit-Transportprotokoll (RTP, Real-time Transport Protocol), das Ende-zu-Ende-Dienste für Daten mit Echtzeiteigenschaften wie interaktivem Audio und Video bereitstellt. Zu diesen Diensten gehören die Identifikation des Nutzlasttyps (Payload Type), die Sequenznummerierung, die Zeitstempelung (Timestamping) und die Überwachung der Zustellung. Anwendungen führen RTP im Allgemeinen über UDP aus, um dessen Multiplexing- und Prüfsummenfunktionen zu nutzen; beide Protokolle tragen jeweils einen Teil der Funktionalität des Transportprotokolls bei. RTP kann jedoch auch mit anderen geeigneten Netzwerk- oder Transportebenenprotokollen verwendet werden (siehe Abschnitt 11). RTP unterstützt die Übertragung von Daten an mehrere Ziele mittels Multicast-Verteilung, sofern das zugrunde liegende Netzwerk dies bereitstellt.

Es ist zu beachten, dass RTP selbst keinen Mechanismus für eine zeitgerechte Zustellung garantiert und auch keine anderen Zusicherungen bezüglich der Dienstgüte (QoS, Quality of Service) bietet; hierfür stützt es sich auf die Dienste der unteren Schichten. Es garantiert weder die Zustellung noch verhindert es eine Zustellung in falscher Reihenfolge, und es setzt nicht voraus, dass das zugrunde liegende Netzwerk zuverlässig ist und Pakete in der Reihenfolge liefert. Die in RTP enthaltenen Sequenznummern ermöglichen es dem Empfänger, die Paketsequenz des Senders zu rekonstruieren; die Sequenznummern können jedoch auch verwendet werden, um die korrekte Position eines Pakets zu bestimmen, beispielsweise bei der Videodecodierung, ohne zwingend die Pakete in Reihenfolge decodieren zu müssen.

Obwohl RTP in erster Linie dafür konzipiert ist, den Anforderungen von Mehrparteien-Multimediakonferenzen zu genügen, ist es nicht auf diese spezielle Anwendung beschränkt. Auch die Speicherung kontinuierlicher Daten, verteilte interaktive Simulationen, Aktiv-Marker (Active Badge) sowie Steuerungs- und Messanwendungen können RTP als geeignet erachten.

Dieses Dokument definiert RTP, das aus zwei eng miteinander verbundenen Teilen besteht:

  • das Echtzeit-Transportprotokoll (RTP), das der Übertragung von Daten mit Echtzeiteigenschaften dient;

  • das RTP-Steuerprotokoll (RTCP, RTP Control Protocol), das zur Überwachung der Dienstgüte und zur Übertragung von Informationen über die Teilnehmer einer laufenden Sitzung dient. Dieser Aspekt von RTCP kann für „schwach gesteuerte" (loosely controlled) Sitzungen ausreichen, bei denen keine Mitglieds- oder explizite Konfigurationssteuerung vorgesehen ist, ist jedoch nicht notwendigerweise dafür gedacht, den gesamten Kommunikationsbedarf einer Anwendung zur Steuerung abzudecken. Diese Funktionalität kann vollständig oder teilweise von einem separaten Sitzungssteuerungsprotokoll übernommen werden, das den Rahmen dieses Dokuments überschreitet.

RTP stellt einen neuen Protokollstil dar, der den von Clark und Tennenhouse [10] vorgeschlagenen Prinzipien des Application-Level Framing und der Integrierten Schichtverarbeitung (Integrated Layer Processing) folgt. Das heißt, RTP ist so gestaltet, dass es anpassbar ist, um die für eine bestimmte Anwendung erforderlichen Informationen bereitzustellen, und wird häufig in die Anwendungsverarbeitung integriert, anstatt als separate Schicht implementiert zu werden. RTP ist bewusst ein unvollständiges Protokollgerüst. Dieses Dokument spezifiziert die Funktionen, die als allen Anwendungen gemeinsam erwartet werden, für die RTP geeignet wäre. Im Gegensatz zu herkömmlichen Protokollen, bei denen zusätzliche Funktionen durch eine Verallgemeinerung des Protokolls oder durch einen Optionsmechanismus mit erforderlichem Syntaxparser untergebracht werden könnten, ist RTP so konzipiert, dass es durch Änderungen und/oder Ergänzungen der Header je nach Bedarf angepasst wird. Beispiele finden sich in den Abschnitten 5.3 und 6.4.3.

Daher erfordert eine vollständige Spezifikation von RTP für eine bestimmte Anwendung zusätzlich zu diesem Dokument ein oder mehrere Begleitdokumente (siehe Abschnitt 13):

  • ein Profil-Spezifikationsdokument (Profile Specification), das einen Satz von Nutzlasttypcodes und deren Zuordnung zu Nutzlastformaten (beispielsweise Medienkodierungen) definiert. Ein Profil kann auch RTP-spezifische Erweiterungen oder Änderungen für eine bestimmte Klasse von Anwendungen festlegen. Eine Anwendung arbeitet typischerweise unter einem einzigen Profil. Ein Profil für Audio- und Videodaten findet sich im Begleitdokument RFC 3551 [1];

  • Nutzlastformat-Spezifikationsdokumente (Payload Format Specification), die definieren, wie eine bestimmte Nutzlast, wie beispielsweise eine Audio- oder Videokodierung, in RTP transportiert werden soll.

Eine Diskussion der Echtzeitdienste und der Algorithmen zu deren Implementierung sowie Hintergrundinformationen zu einigen Entwurfsentscheidungen von RTP finden sich in [11].

1.1 Terminology (Terminologie)​

Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind, wie in BCP 14, RFC 2119 [2], beschrieben, zu interpretieren und geben die Anforderungsstufen für konforme RTP-Implementierungen an.