5. Verwendung von RTCP durch Endpunkte, die mehrere Medienströme senden

RTCP ist in Abschnitt 6 von [RFC3550] definiert. Die Beschreibung des Protokolls ist auf das Verhalten von "Teilnehmern" in einer RTP-Sitzung zugeschnitten, unter der Annahme, dass jeder Endpunkt ein Teilnehmer mit einer einzigen SSRC ist. Für den korrekten Betrieb in Fällen, in denen Endpunkte mehrere SSRC-Werte haben, MUST Implementierungen jedoch jede SSRC als einen separaten Teilnehmer in der RTP-Sitzung behandeln, sodass ein Endpunkt mit mehreren SSRCs als mehrere Teilnehmer zählt.

5.1. RTCP-Berichtspflicht

Ein RTP-Endpunkt, der mehrere SSRCs hat, MUST jede SSRC als einen separaten Teilnehmer in der RTP-Sitzung behandeln. Jede SSRC führt ihre eigenen RTCP-bezogenen Zustandsinformationen und hat daher ihr eigenes RTCP-Berichtsintervall, das bestimmt, wann sie RTCP-Berichte sendet. Wenn der Mechanismus in [MULTI-STREAM-OPT] nicht verwendet wird, sendet jede SSRC RTCP-Berichte für alle anderen SSRCs, einschließlich derer, die sich am selben Endpunkt befinden.

Wenn der Endpunkt einige SSRCs hat, die Daten senden, und einige, die nur Empfänger sind, erhalten sie unterschiedliche Anteile der RTCP-Bandbreite und berechnen unterschiedliche Basis-RTCP-Berichtsintervalle. Andernfalls berechnen alle SSRCs an einem Endpunkt dasselbe Basis-RTCP-Berichtsintervall. Die tatsächlichen Berichtsintervalle für jede SSRC werden in der üblichen Weise randomisiert, aber Berichte können wie in Abschnitt 5.3 beschrieben aggregiert werden.

5.2. Anfängliches Berichtsintervall

Wenn ein Teilnehmer einer Unicast-Sitzung beitritt, ist der folgende Text aus Abschnitt 6.2 von [RFC3550] relevant: "For unicast sessions... the delay before sending the initial compound RTCP packet MAY be zero." Die grundlegende Annahme ist, dass dies auch im Falle mehrerer SSRCs gelten sollte. Vorsicht ist jedoch geboten, wenn ein Endpunkt (oder eine Middlebox) mit einer großen Anzahl von SSRCs einer Unicast-Sitzung beitritt, da die sofortige Übertragung vieler RTCP-Berichte einen erheblichen Verkehrsausbruch erzeugen kann, der zu vorübergehender Überlastung und Paketverlust aufgrund von Warteschlangenüberläufen führt.

Um sicherzustellen, dass der von einem RTP-Endpunkt erzeugte anfängliche Verkehrsausbruch nicht größer ist als der, den eine TCP-Verbindung erzeugen würde, MUST NOT ein RTP-Endpunkt mehr als vier zusammengesetzte RTCP-Pakete ohne anfängliche Verzögerung senden, wenn er einer RTP-Sitzung beitritt, unabhängig von der Anzahl der vom Endpunkt verwendeten SSRCs. Jedes dieser anfänglichen zusammengesetzten RTCP-Pakete MAY aggregierte Berichte von mehreren SSRCs enthalten, sofern die Gesamtgröße des zusammengesetzten RTCP-Pakets die MTU nicht überschreitet und avg_rtcp_size wie in Abschnitt 5.3.1 gepflegt wird. Die Aggregation von Berichten aus mehreren SSRCs in den anfänglichen zusammengesetzten RTCP-Paketen ermöglicht es einer beträchtlichen Anzahl von SSRCs, sofort Bericht zu erstatten. Endpunkte SHOULD Berichte über SSRCs priorisieren, die wahrscheinlich am unmittelbarsten nützlich sind, z. B. für SSRCs, die anfangs Sender sind.

Ein Endpunkt, der über mehr SSRCs Bericht erstatten muss, als in die vier sofort sendbaren zusammengesetzten RTCP-Berichte passen, MUST die übrigen Berichte später senden, wobei er den üblichen RTCP-Zeitregeln einschließlich der Timer-Neubewertung (Timer Reconsideration) folgt. Diese Berichte MAY wie in Abschnitt 5.3 beschrieben aggregiert werden.

Hinweis: Das Obige wurde gewählt, um dem maximalen anfänglichen TCP-Fenster von vier Paketen [RFC3390] zu entsprechen, nicht den größeren anfänglichen TCP-Fenstern, für die ein laufendes Experiment existiert [RFC6928]. Der Grund dafür ist das Bestreben, konservativ zu sein, da ein RTP-Endpunkt in vielen Fällen auch damit beginnt, RTP-Datenpakete gleichzeitig mit dem Senden dieser anfänglichen RTCP-Pakete zu senden.

5.3. Aggregation von Berichten in zusammengesetzten RTCP-Paketen

Wie in Abschnitt 5.1 dargelegt, muss ein Endpunkt mit mehreren SSRCs jede SSRC als einen separaten Teilnehmer behandeln, wenn es um das Senden von RTCP-Berichten geht. Dies führt dazu, dass jede SSRC in jedem Berichtsintervall ein zusammengesetztes RTCP-Paket sendet. Da diese Pakete vom selben Endpunkt stammen, könnte man vernünftigerweise erwarten, dass sie aggregiert werden können, um Overhead zu reduzieren. Tatsächlich erlaubt Abschnitt 6.1 von [RFC3550] RTP-Translatoren und -Mixern, Pakete unter ähnlichen Umständen zu aggregieren:

It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.

Dies ermöglicht es RTP-Translatoren und -Mixern, zusammengesetzte RTCP-Pakete zu erzeugen, die mehrere Sender-Report-(SR-) oder Receiver-Report-(RR-)Pakete von verschiedenen SSRCs sowie beliebige der anderen Pakettypen enthalten. Es gibt keine Einschränkungen hinsichtlich der Reihenfolge, in der die RTCP-Pakete innerhalb des zusammengesetzten Pakets auftreten können, abgesehen von der regulären Regel, dass das zusammengesetzte RTCP-Paket mit einem SR- oder RR-Paket beginnt. Aufgrund dieser Regel werden korrekt implementierte RTP-Endpunkte in der Lage sein, zusammengesetzte RTCP-Pakete zu verarbeiten, die RTCP-Pakete in Bezug auf mehrere SSRCs enthalten.

Dementsprechend können Endpunkte, die mehrere SSRCs verwenden, die von ihren verschiedenen SSRCs gesendeten RTCP-Pakete zu zusammengesetzten RTCP-Paketen aggregieren, sofern 1) die resultierenden zusammengesetzten RTCP-Pakete mit einem SR- oder RR-Paket beginnen, 2) sie die durchschnittliche RTCP-Paketgröße wie in Abschnitt 5.3.1 beschrieben beibehalten und 3) sie die Paketübertragung wie in Abschnitt 5.3.2 beschrieben planen und die Aggregation verwalten.

5.3.1. Pflege von AVG_RTCP_SIZE

Der RTCP-Planungsalgorithmus in [RFC3550] arbeitet auf Basis einzelner SSRCs. Jede SSRC sendet in jedem RTCP-Berichtsintervall ein einzelnes zusammengesetztes RTCP-Paket. Wenn ein Endpunkt mehrere SSRCs verwendet, ist es wünschenswert, die von seinen SSRCs gesendeten zusammengesetzten RTCP-Pakete zu aggregieren und so den Overhead durch Bildung eines größeren zusammengesetzten RTCP-Pakets zu reduzieren. Diese Aggregation kann wie in Abschnitt 5.3.2 beschrieben erfolgen, sofern die Berechnung der durchschnittlichen RTCP-Paketgröße wie folgt aktualisiert wird.

Teilnehmer einer RTP-Sitzung aktualisieren ihre Schätzung der durchschnittlichen RTCP-Paketgröße (avg_rtcp_size) jedes Mal, wenn sie ein RTCP-Paket senden oder empfangen (siehe Abschnitt 6.3.3 von [RFC3550]). Wenn ein zusammengesetztes RTCP-Paket, das RTCP-Pakete von mehreren SSRCs enthält, gesendet oder empfangen wird, wird die avg_rtcp_size-Schätzung für jede SSRC, über die Bericht erstattet wird, unter Verwendung von div_packet_size anstelle der tatsächlichen Paketgröße aktualisiert:

avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size

wobei div_packet_size die Paketgröße dividiert durch die Anzahl der in diesem zusammengesetzten Paket berichtenden SSRCs ist. Die Anzahl der in einem zusammengesetzten Paket berichtenden SSRCs wird bestimmt, indem die Anzahl der verschiedenen SSRCs gezählt wird, die Quelle von SR- oder RR-RTCP-Paketen innerhalb des zusammengesetzten RTCP-Pakets sind. Nicht zusammengesetzte RTCP-Pakete (d. h. RTCP-Pakete, die kein SR- oder RR-Paket enthalten [RFC5506]) gelten als über eine einzelne SSRC berichtend.

Ein Teilnehmer, der die obige Regel nicht befolgt und stattdessen die vollständige Größe des zusammengesetzten RTCP-Pakets zur Berechnung von avg_rtcp_size verwendet, leitet ein RTCP-Berichtsintervall ab, das um einen Faktor zu groß ist, der proportional zur Anzahl der in zusammengesetzte RTCP-Pakete aggregierten SSRCs und zur Größe der Menge der aggregierten SSRCs im Verhältnis zur Gesamtzahl der Teilnehmer ist. Dieses erhöhte RTCP-Berichtsintervall kann vorzeitige Timeouts verursachen, wenn es mehr als das Fünffache des Intervalls beträgt, das von den SSRCs gewählt wird, die zusammengesetztes RTCP verstehen und Berichte von vielen SSRCs aggregieren. Eine MTU von 1500 Oktett kann fünf Berichte typischer Größe in einem zusammengesetzten RTCP-Paket aufnehmen, sodass dies ein reales Problem darstellt, wenn Endpunkte RTCP-Berichte von mehreren SSRCs aggregieren.

Das im vorstehenden Absatz angesprochene Problem wird durch die in Abschnitt 7.1.2 dieses Memorandums angegebene Änderung des Timeout-Verhaltens abgemildert. Diese Abmilderung greift in den Fällen, in denen die RTCP-Bandbreite ausreichend hoch ist, sodass ein Endpunkt unter Verwendung eines avg_rtcp_size, das ohne Berücksichtigung der Anzahl der berichtenden SSRCs berechnet wurde, häufiger als etwa alle 5 Sekunden senden kann. Beachten Sie jedoch, dass die RTCP-Berichterstattung des nicht aktualisierten Endpunkts dennoch negativ beeinträchtigt wird, selbst wenn die vorzeitigen Timeouts seiner SSRCs vermieden werden. Wenn die Kompatibilität mit nicht aktualisierten Endpunkten von Bedeutung ist, SHOULD die Anzahl der von verschiedenen SSRCs in einem einzigen zusammengesetzten RTCP-Paket aggregierten Berichte entweder auf zwei Berichte begrenzt werden, oder die Aggregation sollte überhaupt nicht verwendet werden. Dies begrenzt das RTCP-Berichtsintervall des nicht aktualisierten Endpunkts auf höchstens das Doppelte des RTCP-Berichtsintervalls, das ein Endpunkt wählen würde, der dieser Spezifikation folgt.

5.3.2. Planung von RTCP bei der Aggregation mehrerer SSRCs

Dieser Abschnitt überarbeitet und erweitert das in Abschnitt 6.3 von [RFC3550] und, wenn das RTP/AVPF-Profil oder das RTP/SAVPF-Profil verwendet wird, in Abschnitt 3.5.3 von [RFC4585] definierte Verhalten hinsichtlich der Maßnahmen, die beim Planen und Senden von RTCP-Paketen zu ergreifen sind, wenn mehrere berichtende SSRCs ihre RTCP-Pakete in dasselbe zusammengesetzte RTCP-Paket aggregieren. Diese Änderungen der RTCP-Planungsregeln sind erforderlich, um wichtige RTCP-Zeiteigenschaften zu erhalten, einschließlich der Verteilung zwischen den Paketen sowie des Verhaltens bei Flash-Joins und anderen Änderungen der Sitzungsteilnehmerschaft.

Die im Folgenden verwendeten Variablen tn, tp, tc, T und Td sind in Abschnitt 6.3 von [RFC3550] definiert. Die Variablen T_rr_interval und T_rr_last sind in [RFC4585] definiert.

Jeder Endpunkt MUST die RTCP-Übertragung für jede seiner SSRCs unabhängig planen, wobei er die reguläre Berechnung von tn für das verwendete RTP-Profil zugrunde legt. Jedes Mal, wenn der Timer tn für eine SSRC abläuft, MUST der Endpunkt eine RTCP-Timer-Neubewertung und, falls zutreffend, eine Unterdrückung auf Basis von T_rr_interval durchführen. Wenn das Ergebnis anzeigt, dass von dieser SSRC ein zusammengesetztes RTCP-Paket gesendet werden soll und die Übertragung kein frühes RTCP-Paket [RFC4585] ist, SHOULD der Endpunkt versuchen, RTCP-Pakete weiterer SSRCs, deren Planung in der Zukunft liegt, vor dem Senden in das zusammengesetzte RTCP-Paket zu aggregieren. Der Grund, aus Gründen der Abwärtskompatibilität zu begrenzen oder nicht zu aggregieren, wird in Abschnitt 5.3.1 erörtert.

Die Aggregation verläuft wie folgt. Der Endpunkt wählt die SSRC mit dem kleinsten tn-Wert nach der aktuellen Zeit tc aus und bereitet die RTCP-Pakete vor, die diese SSRC senden würde, wenn ihr Timer tn zum Zeitpunkt tc ablaufen würde. Wenn diese RTCP-Pakete unter Berücksichtigung der Pfad-MTU und der bereits hinzugefügten RTCP-Pakete in das zusammengesetzte RTCP-Paket passen, das gerade erzeugt wird, werden sie dem zusammengesetzten RTCP-Paket hinzugefügt; andernfalls werden sie verworfen. Dieser Vorgang wird für jede SSRC in der Reihenfolge zunehmenden tn wiederholt, bis das zusammengesetzte RTCP-Paket voll ist oder alle SSRCs aggregiert wurden. Zu diesem Zeitpunkt wird das zusammengesetzte RTCP-Paket gesendet.

Wenn das zusammengesetzte RTCP-Paket gesendet wird, MUST der Endpunkt tp, tn und T_rr_last (falls zutreffend) für jede einbezogene SSRC aktualisieren. Diese Variablen werden wie folgt aktualisiert:

1. Für die erste SSRC, die in dem zusammengesetzten RTCP-Paket berichtet hat, wird die effektive Übertragungszeit tt dieser SSRC auf tc gesetzt.
2. Für jede weitere SSRC, die in dem zusammengesetzten RTCP-Paket berichtet hat, wird die Übertragungszeit berechnet, die diese SSRC gehabt hätte, wenn sie nicht in das zusammengesetzte RTCP-Paket aggregiert worden wäre. Dies wird abgeleitet, indem tn für diese SSRC genommen und dann eine Neubewertung durchgeführt und tn aktualisiert wird, bis tp + T <= tn gilt. Sobald dies geschehen ist, wird die effektive Übertragungszeit tt für diese SSRC auf den berechneten Wert von tn gesetzt. Wenn das RTP/AVPF-Profil oder das RTP/SAVPF-Profil verwendet wird, MUST NOT eine Unterdrückung auf Basis von T_rr_interval in dieser Berechnung verwendet werden.
3. Die durchschnittliche effektive Übertragungszeit tt_avg für das zusammengesetzte RTCP-Paket wird auf Basis der tt-Werte für alle in dem zusammengesetzten RTCP-Paket gesendeten SSRCs berechnet. tp wird für jede der in dem zusammengesetzten RTCP-Paket gesendeten SSRCs auf tt_avg gesetzt. Wenn das RTP/AVPF-Profil oder das RTP/SAVPF-Profil verwendet wird, wird T_tt_last für jede in dem zusammengesetzten RTCP-Paket gesendete SSRC auf tt_avg gesetzt.
4. Für jede der in dem zusammengesetzten RTCP-Paket gesendeten SSRCs werden neue tn-Werte auf Basis der aktualisierten Parameter und der üblichen RTCP-Zeitregeln berechnet und die Timer neu geplant.

Bei Verwendung des RTP/AVPF-Profils oder des RTP/SAVPF-Profils versucht der obige Mechanismus nur dann, RTCP-Pakete zu aggregieren, wenn das zu sendende zusammengesetzte RTCP-Paket kein frühes RTCP-Paket ist, und daher steuert der Algorithmus in Abschnitt 3.5.3 von [RFC4585] die RTCP-Planung. Wenn T_rr_interval == 0 gilt oder wenn T_rr_interval != 0 gilt und Option 1, 2a oder 2b des Algorithmus gewählt wird, dann aktualisiert der obige Mechanismus die erforderlichen Variablen. Wenn jedoch die Übertragung gemäß Option 2c des Algorithmus unterdrückt wird, dann wird tp auf tc aktualisiert, da keine Aggregation stattgefunden hat.

Eine umgekehrte Neubewertung (Reverse Reconsideration) MUST gemäß Abschnitt 6.3.4 von [RFC3550] durchgeführt werden. In einigen Fällen kann dies dazu führen, dass der Wert von tp nach der umgekehrten Neubewertung größer als tc ist. Dies ist kein Problem und hat den gewünschten Effekt, den tp-Wert (sowie tn) proportional in Richtung tc zu ziehen, während das Berichtsintervall in direktem Verhältnis zur verringerten Gruppengröße schrumpft.

Der obige Algorithmus hat in Simulationen [Sim88] [Sim92] gezeigt, dass er die Verteilung der Übertragungszeiten zwischen RTCP-Paketen für jede SSRC beibehält und dieselbe Bandbreitenmenge verbraucht wie nicht aggregierte RTCP-Pakete. Mit diesem Algorithmus folgt das tatsächliche Übertragungsintervall für eine SSRC, die eine Übertragung eines zusammengesetzten RTCP-Pakets auslöst, den regulären Übertragungsregeln. Der Wert tp wird irgendwo im Intervall [0, 1,5/1,21828*Td] vor tc gesetzt. Der tatsächliche Wert ist der Durchschnitt aus einer Instanz von tc und den randomisierten Übertragungszeiten der zusätzlichen SSRCs; daher ist der untere Bereich des Intervalls wahrscheinlicher. Dies kompensiert die Verzerrung, die andernfalls durch die Auswahl des kürzesten tn-Werts aus den N in die Aggregation einbezogenen SSRCs entsteht.

Der Algorithmus behandelt auch die Fälle, in denen die Anzahl der SSRCs, die in ein aggregiertes Paket aufgenommen werden können, variiert. Eine SSRC, die zuvor aggregiert wurde und nicht in ein Paket passt, hat dennoch ihre eigene Übertragung gemäß den normalen Regeln geplant. Somit wird sie rechtzeitig eine Übertragung auslösen, oder die SSRC wird in eine andere Aggregation aufgenommen. Das Verhalten des Algorithmus bei Änderungen der SSRC-Gruppengröße ist wie folgt:

RTP-Sitzungen, in denen die Anzahl der SSRCs wächst: Wenn die Gruppengröße wächst, wächst Td proportional zur Anzahl der neuen SSRCs in der Gruppe. Wenn aufgrund des Ablaufs des tn-Timers eine Neubewertung durchgeführt wird, wird diese SSRC die Übertragung neu bewerten und mit einer gewissen Wahrscheinlichkeit den tn-Timer neu planen. Dieser Teil des Neubewertungsalgorithmus wird nur dadurch beeinflusst, dass der obige Algorithmus tp-Werte hat, die in der Zukunft lagen, anstatt auf den Zeitpunkt der tatsächlichen letzten Übertragung zum Zeitpunkt der Aktualisierung von tp gesetzt zu sein.

RTP-Sitzungen, in denen die Anzahl der SSRCs schrumpft: Wenn die Gruppe schrumpft, verschiebt die umgekehrte Neubewertung die Werte tp und tn proportional zur Anzahl der SSRCs, die die Sitzung verlassen, im Verhältnis zur Gesamtzahl der Teilnehmer beim Austritt, in Richtung tc. Es könnte angenommen werden, dass das Vorwärtssetzen des tp-Werts in Bezug auf tc eine negative Auswirkung hat. Der Grund für diese Einstellung ist jedoch, die Verzerrung zu kompensieren, die durch die Auswahl des kürzesten tn aus den N aggregierten entsteht. Diese Verzerrung bleibt auch bei einer Verringerung der Anzahl der SSRCs bestehen. Die umgekehrte Neubewertung kompensiert die Verringerung unabhängig davon, ob eine Aggregation verwendet wird oder nicht. Der negative Effekt, der beim Entfernen einer SSRC auftreten kann, besteht darin, dass der günstigste tn zu der entfernten SSRC gehörte. Dessen Auswirkung beschränkt sich im schlimmsten Fall auf eine Verzögerung der Übertragung um ein Berichtsintervall.

Abschließend ist festzustellen, dass die durchgeführten Untersuchungen keine signifikanten negativen Auswirkungen auf den Planungsalgorithmus festgestellt haben.

5.4. Verwendung von RTP/AVPF- oder RTP/SAVPF-Feedback

Dieser Abschnitt erörtert die Übertragung von RTP/AVPF-Feedback-Paketen, wenn der sendende Endpunkt mehrere SSRCs hat. Die Richtlinien in diesem Abschnitt gelten auch für Endpunkte, die das RTP/SAVPF-Profil verwenden.

5.4.1. Wahl der SSRC für Feedback-Pakete

Wenn ein RTP/AVPF-Endpunkt mehrere SSRCs hat, kann er wählen, welche SSRC als Quelle für die von ihm gesendeten RTCP-Feedback-Pakete verwendet wird. Mehrere Faktoren können diese Wahl beeinflussen:

• RTCP-Feedback-Pakete in Bezug auf einen bestimmten Medientyp SHOULD von einer SSRC gesendet werden, die diesen Medientyp empfängt. Wenn beispielsweise Audio und Video auf eine einzige RTP-Sitzung gemultiplext werden, verwenden Endpunkte ihre Audio-SSRC, um Feedback zu dem von anderen Teilnehmern empfangenen Audio zu senden.
• RTCP-Feedback-Pakete und RTCP-Codec-Steuernachrichten, die Benachrichtigungen oder Hinweise bezüglich der von einem Endpunkt verarbeiteten RTP-Daten sind, MUST von der für diese RTP-Daten verwendeten SSRC gesendet werden. Dies schließt Benachrichtigungen ein, die sich auf eine zuvor empfangene Anforderung oder einen zuvor empfangenen Befehl beziehen [RFC4585][RFC5104].
• Wenn separate SSRCs zum Senden und Empfangen von Medien verwendet werden, SHOULD die entsprechende SSRC für Feedback verwendet werden, da sie unterschiedliche RTCP-Bandbreitenanteile haben. Dies kann auch die Überlegung beeinflussen, ob die SSRC im Sofortmodus (Immediate Mode) verwendet werden kann oder nicht.
• Einige RTCP-Feedback-Pakettypen erfordern Konsistenz bei der verwendeten SSRC. Wenn beispielsweise eine Begrenzung durch eine Temporary Maximum Media Stream Bit Rate Request (TMMBR) [RFC5104] von einer SSRC gesetzt wird, muss dieselbe SSRC verwendet werden, um die Begrenzung aufzuheben.
• Wenn mehrere SSRCs für das Senden von Feedback geeignet sind, kann es wünschenswert sein, eine SSRC zu verwenden, die das Senden von Feedback als frühes RTCP-Paket ermöglicht.

Wenn ein RTCP-Feedback-Paket als Teil eines zusammengesetzten RTCP-Pakets gesendet wird, das Berichte von mehreren SSRCs aggregiert, besteht keine Anforderung, dass das zusammengesetzte Paket ein SR- oder RR-Paket enthält, das vom Sender des RTCP-Feedback-Pakets erzeugt wurde. Bei RTCP-Paketen reduzierter Größe ist die Aggregation von RTCP-Feedback-Paketen aus mehreren Quellen nicht über Abschnitt 4.2.2 von [RFC5506] hinaus eingeschränkt.

5.4.2. Planung eines RTCP-Feedback-Pakets

Wenn eine SSRC ein Feedback-Paket im frühen Modus (Early Mode) übertragen muss, MUST sie dieses Paket gemäß dem Algorithmus in Abschnitt 3.5 von [RFC4585] planen, der wie folgt geändert wird:

• Um zu bestimmen, ob eine RTP-Sitzung als Punkt-zu-Punkt-Sitzung oder als Mehrparteien-Sitzung gilt, MUST ein Endpunkt die Anzahl der verschiedenen RTCP-SDES-CNAME-Werte zählen, die von den SSRCs verwendet werden, die im SSRC-Feld der von ihm empfangenen RTP-Datenpakete und im Feld "SSRC of sender" der von ihm empfangenen RTCP-SR-, RR-, RTPFB- oder PSFB-Pakete aufgeführt sind. Eine RTP-Sitzung gilt als Mehrparteien-Sitzung, wenn von diesen SSRCs mehr als ein CNAME verwendet wird, es sei denn, die Signalisierung zeigt an, dass die Sitzung als Punkt-zu-Punkt behandelt werden soll, oder es werden RTCP-Berichtsgruppen [MULTI-STREAM-OPT] verwendet. Wenn RTCP-Berichtsgruppen verwendet werden, gilt eine RTP-Sitzung als Punkt-zu-Punkt-Sitzung, wenn der Endpunkt nur eine einzige Berichtsgruppe empfängt, und als Mehrparteien-Sitzung, wenn mehrere Berichtsgruppen empfangen werden oder eine Kombination aus Berichtsgruppen und SSRCs, die nicht Teil einer Berichtsgruppe sind, empfangen wird. Endpunkte MUST NOT anhand des verwendeten Verbindungstyps (Unicast oder Multicast) oder anhand der Anzahl der empfangenen SSRCs bestimmen, ob eine RTP-Sitzung eine Mehrparteien- oder eine Punkt-zu-Punkt-Sitzung ist.
• Bei der Prüfung, ob bereits ein geplantes zusammengesetztes RTCP-Paket mit Feedback-Nachrichten existiert (Schritt 2 in Abschnitt 3.5.2 von [RFC4585]), MUST diese Prüfung unter Berücksichtigung aller lokalen SSRCs durchgeführt werden.
• Wenn es einer SSRC nicht gestattet ist, ein frühes RTCP-Paket zu senden, dann MAY die Feedback-Nachricht zur Übertragung als Teil einer beliebigen frühen oder regulär geplanten Übertragung in eine Warteschlange eingereiht werden, die innerhalb der maximalen Nutzungsdauer der Feedback-Nachricht (T_max_fb_delay) erfolgen kann. Dies ändert das Verhalten in Punkt 4a in Abschnitt 3.5.2 von [RFC4585].

Der erste Aufzählungspunkt oben legt eine Regel fest, um zu bestimmen, ob eine RTP-Sitzung als Punkt-zu-Punkt-Sitzung oder als Mehrparteien-Sitzung zu betrachten ist. Diese Regel ist unkompliziert zu implementieren, klassifiziert jedoch bekanntermaßen einige Sitzungen fälschlicherweise als Mehrparteien-Sitzungen. Die bekannten Probleme sind wie folgt:

Endpunkt mit mehreren Synchronisationskontexten: Ein Endpunkt, der Teil einer Punkt-zu-Punkt-Sitzung ist, kann mehrere Synchronisationskontexte haben, beispielsweise aufgrund der Weiterleitung einer externen Medienquelle in eine interaktive Echtzeit-Konversation. In diesem Fall betrachtet die Klassifizierung die Gegenseite als zwei Endpunkte, während die tatsächliche RTP/RTCP-Übertragung unter der Kontrolle eines Endpunkts steht.

Selektiv weiterleitende Middlebox: Die selektiv weiterleitende Middlebox (Selective Forwarding Middlebox, SFM) gemäß der Definition in Abschnitt 3.7 von [RFC7667] hat die Kontrolle über die Übertragung und die Konfigurationen zwischen sich und jedem Peer-Endpunkt individuell. Sie kontrolliert außerdem vollständig die RTCP-Pakete, die zwischen den einzelnen Abschnitten (Legs) weitergeleitet werden. Somit kann diese Art von Middlebox mit dem RTP-Mixer verglichen werden, der seine eigenen SSRCs verwendet, um die von ihm weitergeleiteten Medien zu mischen oder auszuwählen und der durch die obige Regel als Punkt-zu-Punkt-RTP-Sitzung klassifiziert wird.

In den obigen Fällen ist es sehr sinnvoll, RTCP-Berichtsgruppen [MULTI-STREAM-OPT] zu verwenden. Wenn diese Erweiterung verwendet wird, kann ein Endpunkt durch Verwendung nur einer einzigen Berichtsgruppe anzeigen, dass die Vielzahl von CNAMEs tatsächlich unter der Kontrolle eines einzigen Endpunkts oder einer einzigen Middlebox steht.

Die obigen Regeln werden außerdem einige Sitzungen, in denen der Endpunkt mit einem RTP-Mixer verbunden ist, als Punkt-zu-Punkt klassifizieren. Beispielsweise könnte der Mixer für den betrachteten Endpunkt als Gateway zu einer auf Any Source Multicast basierenden RTP-Sitzung fungieren. In den meisten Fällen ist dies jedoch in Ordnung, da der RTP-Mixer eine Trennung zwischen den beiden Teilen der Sitzung bietet. Die Verantwortung liegt beim Mixer, in jeder Domäne entsprechend zu handeln.

Abschließend merken wir an, dass Signalisierungsmechanismen definiert werden könnten, um die Regeln außer Kraft zu setzen, wenn sie zu einer falschen Klassifizierung führen würden.