Zum Hauptinhalt springen

13. RTP Profiles and Payload Format Specifications (RTP-Profile und Nutzlastformatspezifikationen)

Eine vollständige Spezifikation von RTP für eine bestimmte Anwendung erfordert ein oder mehr Begleitdokumente der beiden hier beschriebenen Typen: Profile und Nutzlastformatspezifikationen.

RTP kann für eine Vielzahl von Anwendungen mit etwas unterschiedlichen Anforderungen verwendet werden. Die Flexibilität, sich an diese Anforderungen anzupassen, wird dadurch bereitgestellt, dass mehrere Wahlmöglichkeiten in der Hauptprotokollspezifikation zugelassen werden, dann die geeigneten Wahlen ausgewählt oder Erweiterungen für eine bestimmte Umgebung und Anwendungsklasse in einem separaten Profildokument definiert werden. Typischerweise arbeitet eine Anwendung in einer bestimmten RTP-Sitzung nur unter einem einzigen Profil, daher gibt es innerhalb des RTP-Protokolls selbst keine explizite Angabe, welches Profil verwendet wird. Ein Profil für Audio- und Videoanwendungen findet sich im Begleitdokument RFC 3551. Profile werden typischerweise „RTP Profile for ..." betitelt.

Der zweite Typ des Begleitdokuments ist eine Nutzlastformatspezifikation, die definiert, wie eine bestimmte Art von Nutzlastdaten, wie H.261-kodiertes Video, in RTP transportiert werden soll. Diese Dokumente werden typischerweise „RTP Payload Format for XYZ Audio/Video Encoding" betitelt. Nutzlastformate können unter mehreren Profilen nützlich sein und können daher unabhängig von einem bestimmten Profil definiert werden. Die Profildokumente sind dann dafür verantwortlich, eine Standardzuordnung dieses Formats zu einem Nutzlasttypwert zuzuweisen, falls nötig.

Innerhalb dieser Spezifikation wurden die folgenden Punkte für eine mögliche Definition innerhalb eines Profils identifiziert, wobei diese Liste nicht erschöpfend ist:

  • RTP-Datenheader : Das Oktett im RTP-Datenheader, das das Marker-Bit und das Nutzlasttypfeld enthält, KANN durch ein Profil neu definiert werden, um unterschiedlichen Anforderungen zu entsprechen, beispielsweise mit mehr oder weniger Marker-Bits (Abschnitt 5.3, S. 18).

  • Nutzlasttypen : Unter der Annahme, dass ein Nutzlasttypfeld enthalten ist, wird das Profil normalerweise einen Satz von Nutzlastformaten (z. B. Medienkodierungen) und eine statische Standardzuordnung dieser Formate zu Nutzlasttypwerten definieren. Einige der Nutzlastformate können durch Bezugnahme auf separate Nutzlastformatspezifikationen definiert sein. Für jeden definierten Nutzlasttyp MUSS das Profil die zu verwendende RTP-Zeitstempel-Taktfrequenz angeben (Abschnitt 5.1, S. 14).

  • RTP-Datenheader-Ergänzungen : Zusätzliche Felder DÜRFEN an den festen RTP-Datenheader angehängt werden, falls zusätzliche Funktionalität über die Anwendungsklasse des Profils unabhängig vom Nutzlasttyp hinweg benötigt wird (Abschnitt 5.3, S. 18).

  • RTP-Datenheader-Erweiterungen : Der Inhalt der ersten 16 Bits der RTP-Datenheader-Erweiterungsstruktur MUSS definiert werden, falls die Verwendung dieses Mechanismus unter dem Profil für implementierungsspezifische Erweiterungen erlaubt sein soll (Abschnitt 5.3.1, S. 18).

  • RTCP-Pakettypen : Neue anwendungsklassenspezifische RTCP-Pakettypen DÜRFEN definiert und bei der IANA registriert werden.

  • RTCP-Berichtsintervall : Ein Profil SOLLTE angeben, dass die in Abschnitt 6.2 für die Konstanten bei der Berechnung des RTCP-Berichtsintervalls vorgeschlagenen Werte verwendet werden. Dies sind der RTCP-Anteil der Sitzungsbandbreite, das minimale Berichtsintervall und die Bandbreitenaufteilung zwischen Sendern und Empfängern. Ein Profil KANN abweichende Werte angeben, falls gezeigt wurde, dass sie skalierbar funktionieren.

  • SR/RR-Erweiterung : Ein Erweiterungsabschnitt KANN für die RTCP-SR- und RR-Pakete definiert werden, falls zusätzliche Informationen regelmäßig über den Sender oder die Empfänger berichtet werden sollten (Abschnitt 6.4.3, S. 42 und 43).

  • SDES-Verwendung : Das Profil KANN die relativen Prioritäten für zu übertragende oder ganz auszuschließende RTCP-SDES-Elemente angeben (Abschnitt 6.3.9); eine alternative Syntax oder Semantik für das CNAME-Element (Abschnitt 6.5.1); das Format des LOC-Elements (Abschnitt 6.5.5); die Semantik und Verwendung des NOTE-Elements (Abschnitt 6.5.7); oder neue bei der IANA zu registrierende SDES-Elementtypen.

  • Sicherheit : Ein Profil KANN angeben, welche Sicherheitsdienste und Algorithmen von Anwendungen angeboten werden sollten, und KANN Hinweise zu deren angemessener Verwendung geben (Abschnitt 9, S. 65).

  • Zeichenkette-zu-Schlüssel-Zuordnung : Ein Profil KANN angeben, wie ein vom Benutzer bereitgestelltes Passwort oder eine Passphrase in einen Verschlüsselungsschlüssel abgebildet wird.

  • Überlastung : Ein Profil SOLLTE das für dieses Profil angemessene Überlaststeuerungsverhalten angeben.

  • Zugrunde liegendes Protokoll : Die Verwendung eines bestimmten zugrunde liegenden Netzwerk- oder Transportebenenprotokolls zum Tragen von RTP-Paketen KANN erforderlich sein.

  • Transportabbildung : Eine Abbildung von RTP und RTCP auf Transport-Ebene-Adressen, z. B. UDP-Ports, andere als die in Abschnitt 11, S. 68 definierte Standardabbildung, KANN spezifiziert werden.

  • Kapselung : Eine Kapselung von RTP-Paketen KANN definiert werden, um mehrere RTP-Datenpakete in einem Paket der unteren Ebene zu tragen oder Framing über zugrunde liegende Protokolle bereitzustellen, die dies nicht bereits tun (Abschnitt 11, S. 69).

Es wird nicht erwartet, dass für jede Anwendung ein neues Profil erforderlich ist. Innerhalb einer Anwendungsklasse wäre es besser, ein bestehendes Profil zu erweitern, statt ein neues zu erstellen, um die Interoperabilität zwischen den Anwendungen zu erleichtern, da jede typischerweise nur unter einem Profil läuft. Einfache Erweiterungen wie die Definition zusätzlicher Nutzlasttypwerte oder RTCP-Pakettypen können durch deren Registrierung bei der IANA und Veröffentlichung ihrer Beschreibungen in einem Anhang zum Profil oder in einer Nutzlastformatspezifikation erreicht werden.