5. Multiplexing von RTP und RTCP auf einem einzigen Port

Die Verfahren für das Multiplexing von RTP und RTCP auf einem einzigen Port hängen davon ab, ob es sich bei der Sitzung um eine Unicast-Sitzung oder eine Multicast-Sitzung handelt. Bei Multicast-Sitzungen hängen die Verfahren zudem davon ab, ob Any Source Multicast (ASM) oder Source-Specific Multicast (SSM) verwendet werden soll.

5.1. Unicast-Sitzungen

Es ist akzeptabel, RTP- und RTCP-Pakete auf einem einzigen UDP-Port zu multiplexen, um das NAT-Traversal für Unicast-Sitzungen zu erleichtern, vorausgesetzt, die in der Sitzung verwendeten RTP-Payload-Typen werden gemäß den Regeln in Abschnitt 4 ausgewählt und das Multiplexing wird im Voraus signalisiert. Die folgenden Abschnitte beschreiben, wie solche multiplexierten Sitzungen mit dem Session Initiation Protocol (SIP) und dem Offer/Answer-Modell signalisiert werden können.

5.1.1. SDP-Signalisierung

Wenn das Session Description Protocol (SDP) [8] verwendet wird, um RTP-Sitzungen gemäß dem Offer/Answer-Modell [9] auszuhandeln, zeigt das Attribut "a=rtcp-mux" (siehe Abschnitt 8) den Wunsch an, RTP und RTCP auf einem einzigen Port zu multiplexen. Das ursprüngliche SDP-Angebot MUSS dieses Attribut auf der Medienebene enthalten, um das Multiplexing von RTP und RTCP auf einem einzigen Port anzufordern. Zum Beispiel:

v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux

Dieses Angebot kennzeichnet eine Unicast-Voice-over-IP-Sitzung, die das RTP/AVP-Profil mit iLBC-Kodierung verwendet. Der Antwortende wird gebeten, sowohl RTP als auch RTCP an Port 49170 auf der IPv6-Adresse 2001:DB8::211:24ff:fea3:7a2e zu senden.

Wenn der Antwortende RTP und RTCP auf einem einzigen Port multiplexen möchte, MUSS er ein "a=rtcp-mux"-Attribut auf Medienebene in die Antwort aufnehmen. Die in der Antwort verwendeten RTP-Payload-Typen MÜSSEN den Regeln in Abschnitt 4 entsprechen.

Wenn die Antwort kein "a=rtcp-mux"-Attribut enthält, DARF der Anbieter RTP- und RTCP-Pakete NICHT auf einem einzigen Port multiplexieren. Stattdessen sollte er RTCP auf einem Port senden und empfangen, der nach den üblichen Port-Auswahlregeln zugewiesen wurde (entweder das Port-Paar oder ein signalisierter Port, wenn das Attribut "a=rtcp:" [10] ebenfalls enthalten ist). Dies tritt auf, wenn mit einem Peer kommuniziert wird, der das Attribut "a=rtcp-mux" nicht versteht.

Wenn SDP deklarativ verwendet wird, signalisiert das Vorhandensein eines "a=rtcp-mux"-Attributs, dass der Absender RTP und RTCP auf demselben Port multiplexiert. Der Empfänger MUSS darauf vorbereitet sein, RTCP-Pakete auf dem RTP-Port zu empfangen, und jede Ressourcenreservierung muss unter Einbeziehung der RTCP-Bandbreite vorgenommen werden.

5.1.2. Interaktionen mit SIP-Forking

Bei Verwendung von SIP mit einem Forking-Proxy ist es möglich, dass eine INVITE-Anfrage zu mehreren 200 (OK) Antworten führt. Wenn in diesem INVITE RTP- und RTCP-Multiplexing angeboten wird, ist es wichtig zu wissen, dass einige Antwortende multiplexiertes RTP und RTCP unterstützen können, andere hingegen nicht. Dies erfordert, dass der Anbieter sowohl auf dem RTP-Port als auch auf dem üblichen RTCP-Port auf RTCP lauscht und RTCP auf beiden Ports sendet, es sei denn, Zweige des Rufs, die Multiplexing unterstützen, werden neu ausgehandelt, um separate RTP- und RTCP-Ports zu verwenden.

5.1.3. Interaktionen mit ICE

Es ist üblich, die Methodik des Interactive Connectivity Establishment (ICE) [19] zu verwenden, um RTP-Sitzungen in Gegenwart von Network Address Translation (NAT)-Geräten oder anderen Middleboxes zu etablieren. Wenn RTP und RTCP auf separaten Ports gesendet werden, besteht der RTP-Medienstrom in ICE aus zwei Komponenten (eine für RTP und eine für RTCP), wobei für jede Komponente Konnektivitätsprüfungen durchgeführt werden. Wenn RTP und RTCP auf demselben Port multiplexiert werden sollen, können einige dieser Konnektivitätsprüfungen vermieden werden, was den Overhead von ICE reduziert.

Wenn sowohl ICE als auch multiplexiertes RTP und RTCP verwendet werden sollen, MUSS das ursprüngliche Angebot ein "a=rtcp-mux"-Attribut enthalten, um anzuzeigen, dass RTP- und RTCP-Multiplexing gewünscht ist, und es MUSS "a=candidate:"-Zeilen sowohl für RTP als auch für RTCP zusammen mit einer "a=rtcp:"-Zeile enthalten, die einen Fallback-Port für RTCP angibt, falls der Antwortende kein RTP- und RTCP-Multiplexing unterstützt. Dies MUSS für jedes Medium erfolgen, für das RTP- und RTCP-Multiplexing gewünscht wird.

Wenn der Antwortende RTP und RTCP auf einem einzigen Port multiplexen möchte, MUSS er eine Antwort generieren, die ein "a=rtcp-mux"-Attribut und eine einzelne "a=candidate:"-Zeile enthält, die dem RTP-Port entspricht (d. h. es gibt keinen Kandidaten für RTCP), und zwar für jedes Medium, für das die Verwendung von RTP- und RTCP-Multiplexing gewünscht wird. Der Antwortende führt dann Konnektivitätsprüfungen für dieses Medium durch, als ob das Angebot nur einen einzigen Kandidaten für RTP enthalten hätte. Wenn der Antwortende RTP und RTCP nicht auf einem einzigen Port multiplexen möchte, DARF er das Attribut "a=rtcp-mux" NICHT in seine Antwort aufnehmen und MUSS Konnektivitätsprüfungen für alle angebotenen Kandidaten in der üblichen Weise durchführen.

Nach Erhalt der Antwort sucht der Anbieter nach dem Vorhandensein der Zeile "a=rtcp-mux" für jedes Medium, für das Multiplexing angeboten wurde. Wenn diese vorhanden ist, werden die Konnektivitätsprüfungen so fortgesetzt, als ob nur ein einziger Kandidat (für RTP) angeboten worden wäre, und das Multiplexing wird verwendet, sobald die Sitzung etabliert ist. Wenn die Zeile "a=rtcp-mux" nicht vorhanden ist, wird die Sitzung mit Konnektivitätsprüfungen unter Verwendung von RTP- und RTCP-Kandidaten fortgesetzt, was schließlich dazu führt, dass eine Sitzung mit RTP und RTCP auf separaten Ports etabliert wird (wie durch das Attribut "a=rtcp:" signalisiert).

5.1.4. Interaktionen mit Header-Komprimierung

Das Multiplexing von RTP- und RTCP-Paketen auf einem einzigen Port kann negative Auswirkungen auf Header-Komprimierungsschemata haben, zum Beispiel Compressed RTP (CRTP) [20] und RObust Header Compression (ROHC) [21] [22]. Die Header-Komprimierung nutzt Änderungsmuster in den RTP-Headern aufeinanderfolgender Pakete aus, um einen Hinweis zu senden, dass sich das Paket in der erwarteten Weise geändert hat, anstatt jedes Mal den vollständigen Header zu senden. Dies kann zu erheblichen Bandbreiteneinsparungen führen, wenn die Ströme ein einheitliches Verhalten aufweisen.

Das Vorhandensein von RTCP-Paketen, die mit RTP-Datenpaketen multiplexiert sind, kann die Änderungsmuster zwischen den Headern stören und hat das Potenzial, die Effizienz der Header-Komprimierung erheblich zu verringern. Das Ausmaß dieser Störung hängt vom verwendeten Header-Komprimierungsalgorithmus und von der Art der Klassifizierung der Ströme ab. Ein gut gestalteter Klassifikator sollte in der Lage sein, auf demselben Port multiplexiertes RTP und RTCP unter Verwendung des Payload-Typ-Feldes in verschiedene Komprimierungskontexte zu trennen, so dass der Effekt auf das Komprimierungsverhältnis gering ist. Ein Klassifikator, der Komprimierungskontexte nur auf Basis der IP-Adressen und UDP-Ports zuweist, wird keine gute Leistung erbringen. Es wird erwartet, dass Implementierungen der Header-Komprimierung aktualisiert werden müssen, um auf demselben Port multiplexiertes RTP und RTCP effizient zu unterstützen.

Dieser Effekt des Multiplexing von RTP und RTCP auf die Header-Komprimierung kann besonders in jenen Umgebungen von Bedeutung sein, wie etwa in einigen drahtlosen Telefoniesystemen, die auf die Effizienz der Header-Komprimierung angewiesen sind, um die Medien an einen Kanal mit begrenzter Kapazität anzupassen. Die Auswirkungen des Multiplexings von RTP und RTCP sollten vor der Verwendung in solchen Umgebungen sorgfältig abgewogen werden.

5.2. Any Source Multicast-Sitzungen

Das Problem des NAT-Traversals ist bei Any Source Multicast (ASM) RTP-Sitzungen weniger schwerwiegend als bei Unicast-RTP-Sitzungen, und der Vorteil der Verwendung separater Ports für RTP und RTCP ist aufgrund der Möglichkeit, Drittanbieter-RTCP-only-Monitore zu unterstützen, größer. Dementsprechend SOLLTEN RTP- und RTCP-Pakete bei der Verwendung von ASM-RTP-Sitzungen NICHT auf einem einzigen Port multiplexiert werden und SOLLTEN stattdessen separate Ports und Multicast-Gruppen verwenden.

5.3. Source-Specific Multicast-Sitzungen

RTP-Sitzungen, die über Source-Specific Multicast (SSM) laufen, senden RTCP-Pakete vom Sender zu den Empfängern über den Multicast-Kanal, verwenden jedoch einen separaten Unicast-Feedback-Mechanismus [6], um RTCP von den Empfängern zurück zum Sender zu senden, wobei der Sender die RTCP-Pakete entweder an die Gruppe weiterleitet oder aggregierte Zusammenfassungsberichte sendet.

Gemäß der Terminologie von [6] identifizieren wir drei RTP/RTCP-Ströme in einer SSM-Sitzung:

1. RTP- und RTCP-Ströme zwischen Mediensender und Verteilungsquelle. In vielen Szenarien sind der Mediensender und die Verteilungsquelle am selben Ort untergebracht, so dass Multiplexing kein Problem darstellt. Wenn der Mediensender und die Verteilungsquelle über eine Unicast-Verbindung verbunden sind, gelten die Regeln in Abschnitt 5.1 dieses Memorandums für diese Verbindung. Wenn der Mediensender und die Verteilungsquelle über eine Any Source Multicast-Verbindung verbunden sind, gelten die Regeln in Abschnitt 5.2 für diese Verbindung. Wenn der Mediensender und die Verteilungsquelle über eine Source-Specific Multicast-Verbindung verbunden sind, KÖNNEN die RTP- und RTCP-Pakete auf einem einzigen Port multiplexiert werden, sofern dies signalisiert wird (unter Verwendung von "a=rtcp-mux", wenn SDP verwendet wird).

2. RTP und RTCP, die von der Verteilungsquelle an die Empfänger gesendet werden. Die Verteilungsquelle KANN RTP und RTCP auf einem einzigen Port multiplexen, um NAT-Traversal-Probleme auf dem Vorwärts-SSM-Pfad zu erleichtern, obwohl dies Überwachungsgeräte von Drittanbietern behindern kann, wenn die Sitzung das einfache Feedback-Modell verwendet. Bei Verwendung von SDP SOLLTE das Multiplexing mit dem Attribut "a=rtcp-mux" signalisiert werden.

3. RTCP, das von den Empfängern an die Verteilungsquelle gesendet wird. Dies ist ein reiner RTCP-Pfad, so dass Multiplexing kein Problem darstellt.

Das Multiplexing von RTP- und RTCP-Paketen auf einem einzigen Port in einer SSM-Sitzung hat das Potenzial für Interaktionen mit der Header-Komprimierung, wie in Abschnitt 5.1.4 beschrieben.