11. RTP over Network and Transport Protocols (RTP über Netzwerk- und Transportprotokolle)

Dieser Abschnitt beschreibt Probleme, die spezifisch für den Transport von RTP-Paketen innerhalb bestimmter Netzwerk- und Transportprotokolle sind. Die folgenden Regeln gelten, sofern sie nicht durch protokollspezifische Definitionen außerhalb dieser Spezifikation ersetzt werden.

RTP stützt sich auf die(s) zugrunde liegende(n) Protokoll(e), um das Demultiplexen von RTP-Daten- und RTCP-Steuerströmen bereitzustellen. Für UDP und ähnliche Protokolle SOLLTE RTP eine gerade Zielportnummer und der entsprechende RTCP-Strom SOLLTE die nächsthöhere (ungerade) Zielportnummer verwenden. Für Anwendungen, die eine einzelne Portnummer als Parameter nehmen und das RTP- und RTCP-Portpaar daraus ableiten, SOLLTE die Anwendung, falls eine ungerade Zahl geliefert wird, diese durch die nächstniedrige (gerade) Zahl ersetzen, um sie als Basis des Portpaars zu verwenden. Für Anwendungen, in denen die RTP- und RTCP-Zielportnummern über explizite, separate Parameter (unter Verwendung eines Signalisierungsprotokolls oder anderer Mittel) spezifiziert sind, KANN die Anwendung die Einschränkung, dass die Portnummern gerade/ungerade und aufeinanderfolgend sein müssen, ignorieren, obwohl die Verwendung eines gerade/ungeraden Portpaars weiterhin empfohlen wird. Die RTP- und RTCP-Portnummern DÜRFEN NICHT identisch sein, da RTP sich auf die Portnummern zum Demultiplexen der RTP-Daten- und RTCP-Steuerströme stützt.

In einer Unicast-Sitzung müssen beide Teilnehmer ein Portpaar zum Empfang von RTP- und RTCP-Paketen identifizieren. Beide Teilnehmer DÜRFEN dasselbe Portpaar verwenden. Ein Teilnehmer DARF NICHT annehmen, dass die Quellportnummer des eingehenden RTP- oder RTCP-Pakets als Zielport für ausgehende RTP- oder RTCP-Pakete verwendet werden kann. Wenn RTP-Datenpakete in beiden Richtungen gesendet werden, MÜSSEN die RTCP-SR-Pakete jedes Teilnehmers an den Port gesendet werden, den der andere Teilnehmer für den Empfang von RTCP spezifiziert hat. Die RTCP-SR-Pakete kombinieren Senderinformationen für die ausgehenden Daten plus Empfangsberichtsinformationen für die eingehenden Daten. Wenn eine Seite keine aktiv sendenden Daten hat (siehe Abschnitt 6.4), wird stattdessen ein RTCP-RR-Paket gesendet.

Es wird EMPFOHLEN, dass Anwendungen mit geschichteter Kodierung (siehe Abschnitt 2.4) einen Satz aufeinanderfolgender Portnummern verwenden. Die Portnummern MÜSSEN unterschiedlich sein wegen eines weit verbreiteten Mangels in bestehenden Betriebssystemen, der die Verwendung desselben Ports mit mehreren Multicast-Adressen verhindert, und für Unicast gibt es nur eine zulässige Adresse. Daher ist für Schicht n der Datenport P + 2n und der Steuerport P + 2n + 1. Bei Verwendung von IP-Multicast MÜSSEN auch die Adressen unterschiedlich sein, da Multicast-Routing und Gruppenmitgliedschaft mit Adressgranularität verwaltet werden. Die Zuweisung aufeinanderfolgender IP-Multicast-Adressen kann jedoch nicht angenommen werden, da einige Gruppen unterschiedliche Gültigkeitsbereiche benötigen und daher aus verschiedenen Adressbereichen zugewiesen werden können.

Der vorherige Absatz steht im Konflikt mit der SDP-Spezifikation RFC 2327 [15], die besagt, dass es illegal ist, sowohl mehrere Adressen als auch mehrere Ports in derselben Sitzungsbeschreibung anzugeben, da die Zuordnung von Adressen zu Ports mehrdeutig sein könnte. Es ist beabsichtigt, diese Einschränkung in einer Überarbeitung von RFC 2327 zu lockern, um die Angabe einer gleichen Anzahl von Adressen und Ports mit implizierter Eins-zu-Eins-Zuordnung zu erlauben.

RTP-Datenpakete enthalten kein Längenfeld oder eine andere Abgrenzung, daher stützt sich RTP auf die zugrunde liegenden Protokolle zur Angabe der Länge. Die maximale Länge von RTP-Paketen ist nur durch die zugrunde liegenden Protokolle begrenzt.

Wenn RTP-Pakete in einem zugrunde liegenden Protokoll transportiert werden sollen, das die Abstraktion eines kontinuierlichen Oktettstroms statt von Nachrichten (Paketen) bietet, MUSS eine Kapselung der RTP-Pakete definiert werden, um einen Rahmenmechanismus (Framing) bereitzustellen. Framing wird auch benötigt, falls das zugrunde liegende Protokoll Füllung enthalten kann, sodass der Umfang der RTP-Nutzlast nicht bestimmt werden kann. Der Rahmenmechanismus ist hier nicht definiert.

Ein Profil KANN eine Rahmenmethode spezifizieren, die selbst dann verwendet werden soll, wenn RTP in Protokollen transportiert wird, die Framing bieten, um mehrere RTP-Pakete in einer einzigen Dateneinheit der unteren Protokollebene, wie einem UDP-Paket, zu tragen. Der Transport mehrerer RTP-Pakete in einem Netz- oder Transportpaket reduziert den Header-Overhead und kann die Synchronisation zwischen verschiedenen Strömen vereinfachen.