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.