1. Einführung

Das Real-time Transport Protocol (RTP) [1] besteht aus zwei Komponenten: einem Datentransferprotokoll und einem zugehörigen Kontrollprotokoll (RTCP). Historisch gesehen wurden RTP und RTCP auf separaten UDP-Ports betrieben. Mit der zunehmenden Nutzung von Network Address Port Translation (NAPT) [14] ist dies problematisch geworden, da die Aufrechterhaltung mehrerer NAT-Bindungen kostspielig sein kann. Zudem erschwert es die Firewall-Administration, da mehrere Ports geöffnet werden müssen, um RTP-Verkehr zuzulassen. Dieses Memorandum erörtert, wie die RTP- und RTCP-Ströme für einen einzelnen Medientyp auf einem einzigen Port betrieben werden können, um das NAT-Traversal zu erleichtern und die Firewall-Administration zu vereinfachen, und prüft, wann ein solches Multiplexing angemessen ist. Das Multiplexing mehrerer Medientypen (z. B. Audio und Video) auf einen einzigen Port wird hier nicht betrachtet (siehe jedoch Abschnitt 5.2 von [1]).

Dieses Memorandum ist wie folgt gegliedert: In Abschnitt 2 erörtern wir die Designentscheidungen, die zur Verwendung separater Ports geführt haben, und kommentieren die Anwendbarkeit dieser Entscheidungen auf aktuelle Netzwerkumgebungen. Wir erörtern die Terminologie in Abschnitt 3 und wie multiplexierte Pakete in Abschnitt 4 unterschieden werden können; anschließend legen wir in Abschnitt 5 fest, wann und wie RTP und RTCP multiplexiert werden sollten und wie multiplexierte Sitzungen signalisiert werden. Fragen der Dienstgüte (QoS) und der Bandbreite werden in Abschnitt 6 erörtert. Wir schließen mit Sicherheitshinweisen in Abschnitt 7 und IANA-Überlegungen in Abschnitt 8 ab.

Dieses Memorandum aktualisiert Abschnitt 11 von [1].

2. Hintergrund

Eine RTP-Sitzung besteht aus Datenpaketen und periodischen Kontroll- (RTCP) Paketen. Es wird davon ausgegangen, dass RTCP-Pakete "denselben Verteilungsmechanismus wie die Datenpakete" verwenden und das "zugrunde liegende Protokoll Multiplexing der Daten- und Kontrollpakete bereitstellen MUSS, beispielsweise durch Verwendung separater Portnummern mit UDP" [1]. Das Multiplexing wurde dem zugrunde liegenden Transportprotokoll überlassen, anstatt innerhalb von RTP bereitgestellt zu werden, und zwar aus folgenden Gründen:

1. Einfachheit: Eine RTP-Implementierung wird vereinfacht, indem das RTP- und RTCP-Demultiplexing in die Transportschicht verlagert wird, da sie sich nicht um die Trennung von Daten- und Kontrollpaketen kümmern muss. Dies ermöglicht es, die Implementierung auf eine sehr natürliche Weise zu strukturieren, mit einer sauberen Trennung von Daten- und Kontrollebene.

2. Effizienz: Nach dem Prinzip der integrierten Schichtverarbeitung [15] wird eine Implementierung effizienter sein, wenn das Demultiplexing an einer einzigen Stelle stattfindet (z. B. nach UDP-Port), als wenn es über mehrere Schichten des Stacks verteilt ist (z. B. nach UDP-Port und dann nach Pakettyp).

3. Um Drittanbieter-Monitore zu ermöglichen: Während Unicast Voice-over-IP schon immer in Betracht gezogen wurde, wurde RTP auch zur Unterstützung lose gekoppelter Multicast-Konferenzen [16] und sehr groß angelegter Multicast-Streaming-Media-Anwendungen (wie dem sogenannten "Triple-Play" IP-Fernsehdienst (IPTV)) entwickelt. Dementsprechend erlaubt der Entwurf von RTP, dass RTCP-Pakete über eine separate IP-Multicast-Gruppe und einen separaten UDP-Port als die Datenpakete per Multicast übertragen werden. Dies ermöglicht es nicht nur den Teilnehmern einer Sitzung, Rückmeldungen zur Empfangsqualität zu erhalten, sondern ermöglicht auch den Einsatz von Drittanbieter-Monitoren, die die Empfangsqualität abhören, ohne Zugriff auf die Datenpakete zu haben. Dies sollte die Verwaltbarkeit von Multicast-Sitzungen gewährleisten, ohne die Privatsphäre zu beeinträchtigen.

Obwohl diese Designentscheidungen für viele Anwendungen von RTP angemessen sind, sind sie in einigen Fällen problematisch. Es gibt viele RTP-Bereitstellungen, die keinen IP-Multicast verwenden, und mit der zunehmenden Nutzung von Network Address Translation (NAT) ist die Einfachheit des Multiplexing auf der Transportschicht zu einer Belastung geworden, da sie eine komplexe Signalisierung erfordert, um mehrere NAT-Pinholes zu öffnen. In Umgebungen wie diesen ist es wünschenswert, eine Alternative zum Demultiplexing von RTP und RTCP über separate UDP-Ports bereitzustellen und stattdessen nur einen einzigen UDP-Port und Demultiplexing innerhalb der Anwendung zu verwenden.

Dieses Memorandum bietet eine solche Alternative durch Multiplexing von RTP- und RTCP-Paketen auf einem einzigen UDP-Port, unterschieden durch den RTP-Payload-Typ und die RTCP-Pakettyp-Werte. Dies verlagert einige zusätzliche Arbeit auf die RTP-Implementierung, im Austausch für ein vereinfachtes NAT-Traversal.

3. Terminologie

Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "SOLL NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "KANN" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [2] beschrieben zu interpretieren.

4. Unterscheidbare RTP- und RTCP-Pakete

Wenn RTP- und RTCP-Pakete auf einem einzigen Port multiplexiert werden, belegt das Feld für den RTCP-Pakettyp dieselbe Position im Paket wie die Kombination aus dem RTP-Marker- (M) Bit und dem RTP-Payload-Typ (PT). Dieses Feld kann verwendet werden, um RTP- und RTCP-Pakete zu unterscheiden, wenn zwei Einschränkungen beachtet werden: 1) Die verwendeten RTP-Payload-Typ-Werte unterscheiden sich von den verwendeten RTCP-Pakettypen; und 2) für jeden RTP-Payload-Typ (PT) unterscheidet sich PT+128 von den verwendeten RTCP-Pakettypen. Die erste Einschränkung schließt einen direkten Konflikt zwischen dem RTP-Payload-Typ und dem RTCP-Pakettyp aus; die zweite Einschränkung schließt einen Konflikt zwischen einem RTP-Datenpaket mit gesetztem Marker-Bit und einem RTCP-Paket aus.

Folgende Konflikte zwischen RTP- und RTCP-Pakettypen sind bekannt:

• Die RTP-Payload-Typen 64-65 stehen im Konflikt mit den (veralteten) RTCP FIR- und NACK-Paketen, die im ursprünglichen "RTP Payload Format for H.261 Video Streams" [3] definiert wurden (das durch [17] veraltet ist).

• Die RTP-Payload-Typen 72-76 stehen im Konflikt mit den RTCP SR-, RR-, SDES-, BYE- und APP-Paketen, die in der RTP-Spezifikation [1] definiert sind.

• Die RTP-Payload-Typen 77-78 stehen im Konflikt mit den RTCP RTPFB- und PSFB-Paketen, die im RTP/AVPF-Profil [4] definiert sind.

• Der RTP-Payload-Typ 79 steht im Konflikt mit RTCP Extended Report (XR) [5] Paketen.

• Der RTP-Payload-Typ 80 steht im Konflikt mit Receiver Summary Information (RSI) Paketen, die in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6] definiert sind.

Neue RTCP-Pakettypen könnten in Zukunft registriert werden und werden die verfügbaren RTP-Payload-Typen weiter reduzieren, wenn RTP und RTCP auf einem einzigen Port multiplexiert werden. Um dieses Multiplexing zu ermöglichen, SOLLTEN zukünftige Zuweisungen von RTCP-Pakettypen nach den aktuellen Zuweisungen im Bereich 209-223 und dann im Bereich 194-199 vorgenommen werden, so dass nur die RTP-Payload-Typen im Bereich 64-95 blockiert werden. RTCP-Pakettypen in den Bereichen 1-191 und 224-254 SOLLTEN nur verwendet werden, wenn andere Werte erschöpft sind.

Angesichts dieser Einschränkungen wird EMPFOHLEN, den Richtlinien im RTP/AVP-Profil [7] für die Wahl der RTP-Payload-Typ-Werte zu folgen, mit der zusätzlichen Einschränkung, dass Payload-Typ-Werte im Bereich 64-95 NICHT verwendet werden DÜRFEN. Insbesondere SOLLTEN dynamische RTP-Payload-Typen nach Möglichkeit im Bereich 96-127 gewählt werden. Werte unter 64 KÖNNEN verwendet werden, wenn dies nicht ausreicht; in diesem Fall wird EMPFOHLEN, zuerst Payload-Typ-Nummern zu verwenden, die nicht statisch durch [7] zugewiesen sind.

Hinweis: Da Abschnitt 6.1 von [1] festlegt, dass alle RTCP-Pakete als zusammengesetzte Pakete gesendet werden MÜSSEN, die mit einem Sender Report (SR) oder einem Receiver Report (RR) Paket beginnen, könnte man sich fragen, warum andere RTP-Payload-Typen als 72 und 73 beim Multiplexing von RTP und RTCP verboten sind. Dies geschieht, um [18] zu unterstützen, das die Verwendung von nicht zusammengesetzten RTCP-Paketen unter bestimmten Umständen erlaubt.