Zum Hauptinhalt springen

1. Einführung (Introduction)

Dieses Memorandum spezifiziert das Echtzeit-Transportprotokoll (Real-time Transport Protocol, RTP), das Ende-zu-Ende-Übertragungsdienste für Daten mit Echtzeiteigenschaften wie interaktives Audio und Video bereitstellt. Diese Dienste umfassen Nutzdatentyp-Identifikation, Sequenznummerierung, Zeitstempel und Übertragungsüberwachung. Anwendungen führen RTP typischerweise über UDP aus, um dessen Multiplexing- und Prüfsummendienste zu nutzen; beide Protokolle tragen Teile zur Transportprotokollfunktionalität bei. RTP kann jedoch auch mit anderen geeigneten zugrunde liegenden Netzwerk- oder Transportprotokollen verwendet werden (siehe Abschnitt 11). RTP unterstützt die Datenübertragung an mehrere Ziele unter Verwendung von Multicast-Verteilung, wenn diese vom zugrunde liegenden Netzwerk bereitgestellt wird.

Beachten Sie, dass RTP selbst keinen Mechanismus zur Gewährleistung rechtzeitiger Zustellung oder zur Bereitstellung anderer Dienstqualitätsgarantien bietet, sondern sich auf Dienste niedrigerer Schichten verlässt. Es garantiert weder die Zustellung noch verhindert es die Zustellung außerhalb der Reihenfolge, noch geht es davon aus, dass das zugrunde liegende Netzwerk zuverlässig ist und Pakete in der richtigen Reihenfolge zustellt. Die in RTP enthaltenen Sequenznummern ermöglichen es dem Empfänger, die Paketsequenz des Senders zu rekonstruieren, aber Sequenznummern können auch verwendet werden, um die richtige Position eines Pakets zu bestimmen, beispielsweise beim Videodekodieren, ohne notwendigerweise Pakete in der Reihenfolge zu dekodieren.

Obwohl RTP hauptsächlich entwickelt wurde, um die Bedürfnisse von Multimedia-Konferenzen mit mehreren Teilnehmern zu erfüllen, ist es nicht auf diese spezielle Anwendung beschränkt. Speicherung kontinuierlicher Daten, interaktive verteilte Simulation, aktive Badges sowie Steuerungs- und Messanwendungen können RTP ebenfalls als anwendbar erachten.

Dieses Dokument definiert RTP, bestehend aus zwei eng verbundenen Teilen:

  • das Echtzeit-Transportprotokoll (Real-time Transport Protocol, RTP), um Daten mit Echtzeiteigenschaften zu übertragen.

  • das RTP-Steuerprotokoll (RTP Control Protocol, RTCP), um die Dienstqualität zu überwachen und Informationen über die Teilnehmer einer laufenden Sitzung zu übermitteln. Dieser letztere Aspekt von RTCP kann für „lose kontrollierte" Sitzungen ausreichend sein, d.h. wenn es keine explizite Mitgliedschaftskontrolle und Einrichtung gibt, aber es ist nicht unbedingt dazu gedacht, alle Steuerungskommunikationsanforderungen einer Anwendung zu unterstützen. Diese Funktionalität kann vollständig oder teilweise von einem separaten Sitzungssteuerprotokoll übernommen werden, das außerhalb des Geltungsbereichs dieses Dokuments liegt.

RTP repräsentiert einen neuen Protokollstil, der den Prinzipien des Application-Level-Framing und der integrierten Schichtverarbeitung folgt, wie von Clark und Tennenhouse vorgeschlagen [10]. Das heißt, RTP soll formbar sein, um die von einer bestimmten Anwendung benötigten Informationen bereitzustellen, und wird oft in die Anwendungsverarbeitung integriert, anstatt als separate Schicht implementiert zu werden. RTP ist ein Protokoll-Framework, das absichtlich nicht vollständig ist. Dieses Dokument spezifiziert die Funktionen, die voraussichtlich für alle Anwendungen gemeinsam sind, für die RTP geeignet wäre. Im Gegensatz zu herkömmlichen Protokollen, bei denen zusätzliche Funktionen durch eine allgemeinere Gestaltung des Protokolls oder durch Hinzufügen eines Optionsmechanismus, der eine Analyse erfordern würde, untergebracht werden könnten, soll RTP durch Modifikationen und/oder Ergänzungen der Header nach Bedarf angepasst werden. Beispiele finden sich in den Abschnitten 5.3 und 6.4.3.

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

  • ein Profil-Spezifikationsdokument, das einen Satz von Nutzdatentyp-Codes und deren Zuordnung zu Nutzdatenformaten (z.B. Mediencodierungen) definiert. Ein Profil kann auch Erweiterungen oder Modifikationen an RTP definieren, die für eine bestimmte Klasse von Anwendungen spezifisch sind. Typischerweise wird eine Anwendung nur unter einem Profil arbeiten. Ein Profil für Audio- und Videodaten findet sich im begleitenden RFC 3551 [1].

  • Nutzdatenformat-Spezifikationsdokumente, die definieren, wie eine bestimmte Nutzdaten, wie eine Audio- oder Videocodierung, in RTP übertragen werden soll.

Eine Diskussion über Echtzeit-Dienste und Algorithmen für deren Implementierung sowie Hintergrunddiskussionen über einige der RTP-Designentscheidungen finden sich in [11].

1.1 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 Anforderungsstufen für konforme RTP-Implementierungen an.

Letztes Update am