7. RTCP-Überlegungen für Ströme mit unterschiedlichen Raten

Eine RTP-Sitzung hat einen einzigen Satz von Parametern, die die Sitzungsbandbreite konfigurieren. Dies sind die RTCP-Sender- und -Empfängeranteile (z. B. die SDP-Zeilen "b=RR:" und "b=RS:" [RFC3556]) und die Parameter des RTP/AVPF-Profils [RFC4585] (z. B. trr-int), wenn dieses Profil (oder seine sichere Erweiterung, RTP/SAVPF [RFC5124]) verwendet wird. Infolgedessen ist das Basis-RTCP-Berichtsintervall vor der Randomisierung für jede sendende SSRC in einer RTP-Sitzung dasselbe. In ähnlicher Weise hat jede empfangende SSRC in einer RTP-Sitzung dasselbe Basis-Berichtsintervall, obwohl dieses von dem von sendenden SSRCs gewählten Berichtsintervall abweichen kann. Dieses einheitliche RTCP-Berichtsintervall für alle SSRCs kann dazu führen, dass RTCP-Berichte häufiger oder zu selten gesendet werden, als es für einen RTP-Strom als wünschenswert erachtet wird.

Betrachten Sie beispielsweise ein Szenario, in dem ein Audiofluss, der mit einigen zehn Kilobit pro Sekunde sendet, mit einem mehrere Megabit hohen hochwertigen Videofluss in eine RTP-Sitzung gemultiplext wird. Wenn die Sitzungsbandbreite auf Basis der Video-Senderate konfiguriert wird und der Standard-RTCP-Bandbreitenanteil von 5 % der Sitzungsbandbreite verwendet wird, ist es wahrscheinlich, dass die RTCP-Bandbreite die Audio-Senderate übersteigt. Wenn dann das in Abschnitt 6.2 von [RFC3550] beschriebene reduzierte minimale RTCP-Intervall in der Sitzung verwendet wird, wie es für Video angemessen ist, bei dem ein schnelles Feedback zu beschädigten I-Frames gewünscht wird, könnte das einheitliche Berichtsintervall für alle Sender bedeuten, dass von Audioquellen erwartet wird, RTCP-Pakete häufiger zu senden, als sie Audiodatenpakete senden. Diese Bandbreiten-Fehlanpassung kann durch sorgfältige Abstimmung der RTCP-Parameter, insbesondere trr_int, wenn das RTP/AVPF-Profil verwendet wird, verringert, aber nicht vollständig vermieden werden, da sie dem Entwurf der RTCP-Zeitregeln inhärent ist und alle RTP-Sitzungen betrifft, die Flüsse mit stark voneinander abweichender Bandbreite enthalten.

Unterschiedliche Medienraten oder gewünschte RTCP-Verhaltensweisen können auch bei SSRCs auftreten, die denselben Medientyp übertragen. Ein häufiger Fall in Mehrparteien-Konferenzen ist, dass eine kleine Anzahl von Videoströmen in hoher Auflösung und die übrigen als Miniaturansichten mit niedriger Auflösung angezeigt werden, wobei die Auswahl dessen, was in hoher Auflösung angezeigt wird, durch Sprachaktivität gesteuert wird. Hier liegen die Unterschiede sowohl in der tatsächlichen Medienrate als auch in der Wahl der möglicherweise benötigten Feedback-Nachrichten. Weitere Beispiele für Unterschiede, die bestehen können, ergeben sich aus der beabsichtigten Verwendung einer Medienquelle. Eine Medienquelle, die das Video des Sprechers in einer Konferenz überträgt, unterscheidet sich von einer Dokumentenkamera. Grundlegende Parameter, die sich in diesem Fall unterscheiden können, sind die Bildrate, die akzeptable Ende-zu-Ende-Verzögerung und die Signal-Rausch-Verhältnis-(SNR-)Treue des Bildes. Diese Unterschiede wirken sich nicht nur auf die benötigten Bitraten aus, sondern auch auf mögliche Übertragungsverhaltensweisen, nutzbare Reparaturmechanismen, die von Steuerung und Reparatur benötigten Feedback-Nachrichten, die Übertragungsanforderungen an diese Feedback-Nachrichten und die Überwachung der RTP-Strom-Auslieferung. Andere ähnliche Szenarien können ebenfalls existieren.

Das Senden mehrerer Medientypen in einer einzigen RTP-Sitzung führt dazu, dass diese Sitzung mehr SSRCs enthält, als wenn jeder Medientyp in einer separaten RTP-Sitzung gesendet würde. Wenn beispielsweise zwei Teilnehmer jeweils einen Audio- und einen Video-RTP-Strom in einer einzigen RTP-Sitzung senden, umfasst diese Sitzung vier SSRCs; wären jedoch separate RTP-Sitzungen für Audio und Video verwendet worden, würde jede dieser beiden RTP-Sitzungen nur zwei SSRCs umfassen. Daher erhöht das Senden mehrerer RTP-Ströme in einer RTP-Sitzung den Umfang der Querberichterstattung zwischen den SSRCs, da jede SSRC über alle anderen SSRCs in der Sitzung Bericht erstattet. Dies vergrößert die RTCP-Berichte, sodass sie bei gegebener RTCP-Bandbreite seltener gesendet werden, als es der Fall wäre, wenn separate RTP-Sitzungen verwendet würden.

Wenn eine RTP-Sitzung schließlich mehrere Medientypen enthält, ist es wichtig zu beachten, dass die verwendeten RTCP-Empfangsqualitätsberichte, Feedback-Nachrichten und erweiterten Berichtsblöcke möglicherweise nicht auf alle Medientypen anwendbar sind. Endpunkte müssen den Medientyp jeder SSRC berücksichtigen und nur Berichte und Feedback senden oder verarbeiten, die auf diese bestimmte SSRC und ihren Medientyp zutreffen. Signalisierungslösungen können Mängel aufweisen, wenn es darum geht, anzuzeigen, dass eine bestimmte Menge von RTCP-Berichten oder Feedback-Nachrichten nur für einen bestimmten Medientyp innerhalb einer RTP-Sitzung gilt.

Aus RTCP-Sicht ist daher zu erkennen, dass die Verwendung separater RTP-Sitzungen für jede Medienquelle Vorteile gegenüber dem Senden mehrerer Medienquellen in einer einzigen RTP-Sitzung bietet. Diese werden jedoch häufig durch die Notwendigkeit aufgewogen, die Portnutzung zu verringern und die NAT-/Firewall-Durchquerung zu erleichtern, was durch die Kombination von Medienquellen in einer einzigen RTP-Sitzung erreicht wird. Die folgenden Abschnitte betrachten einige der Probleme bei der Verwendung von RTCP in Sitzungen mit mehreren Medienquellen eingehender.

7.1. Timeouts von SSRCs

Bei der Zeitüberschreitung von SSRC-Werten beim Senden mehrerer RTP-Ströme in einer RTP-Sitzung wurden verschiedene Probleme festgestellt.

7.1.1. Probleme mit dem T_rr_interval-Parameter von RTP/AVPF

Das RTP/AVPF-Profil enthält ein Verfahren, um zu verhindern, dass reguläre RTCP-Berichte zu häufig gesendet werden. Dieser Mechanismus ist in Abschnitt 3.5.3 von [RFC4585] beschrieben; er wird durch den Parameter T_rr_interval gesteuert. Er funktioniert wie folgt. Wenn ein regulärer RTCP-Bericht gesendet wird, wird ein neuer Zufallswert, T_rr_current_interval, erzeugt, der gleichmäßig im Bereich vom 0,5- bis 1,5-Fachen von T_rr_interval gezogen wird. Wenn ein reguläres RTCP-Paket früher als T_rr_current_interval Sekunden nach dem vorherigen regulären RTCP-Paket gesendet werden soll und keine Feedback-Nachrichten zu senden sind, wird dieses reguläre RTCP-Paket unterdrückt und das nächste reguläre RTCP-Paket geplant. Das T_rr_current_interval wird jedes Mal neu berechnet, wenn ein reguläres RTCP-Paket gesendet wird. Der Vorteil der Unterdrückung besteht darin, dass sie eine Verschwendung von Bandbreite vermeidet, wenn nichts eine häufige RTCP-Übertragung erfordert, aber dennoch die Nutzung der konfigurierten Bandbreite ermöglicht, wenn Feedback benötigt wird.

Leider verzerrt dieser Unterdrückungsmechanismus die Verteilung der RTCP-Sendeintervalle im Vergleich zu den regulären RTCP-Berichtsintervallen. Die Standard-RTCP-Zeitregeln, einschließlich Neubewertung und Kompensationsfaktor, führen dazu, dass die Intervalle zwischen dem Senden von RTCP-Paketen eine Verteilung aufweisen, die zum oberen Ende des Bereichs [0,5/1,21828, 1,5/1,21828]*Td hin verzerrt ist, wobei Td das deterministisch berechnete RTCP-Berichtsintervall ist. Mit Td = 5 s deckt diese Verteilung den Bereich [2,052 s, 6,156 s] ab. Im Vergleich dazu wirken die RTP/AVPF-Unterdrückungsregeln in einem Intervall vom 0,5- bis 1,5-Fachen von T_rr_interval; für T_rr_interval = 5 s ist dies [2,5 s, 7,5 s].

Die Auswirkung davon ist, dass die Zeit zwischen aufeinanderfolgenden RTCP-Paketen bei Verwendung der T_rr_interval-Unterdrückung groß werden kann. Das maximale Zeitintervall zwischen dem Senden eines regulären RTCP-Pakets und dem nächsten, wenn T_rr_interval verwendet wird, tritt auf, wenn T_rr_current_interval seinen Maximalwert annimmt und ein reguläres RTCP-Paket am Ende des Unterdrückungszeitraums unterdrückt wird, woraufhin das nächste reguläre RTCP-Paket nach seinem größtmöglichen Berichtsintervall geplant wird. Nimmt man den schlimmsten Fall der beiden Intervalle, ergibt sich eine maximale Zeit zwischen zwei RTCP-Berichten von 1,5T_rr_interval + 1,5/1,21828Td.

Dieses Verhalten kann überraschen, wenn Td und T_rr_interval denselben Wert haben. Das heißt, wenn T_rr_interval so konfiguriert ist, dass es dem regulären RTCP-Berichtsintervall entspricht. In diesem Fall könnte man erwarten, dass reguläre RTCP-Pakete nach ihrem üblichen Zeitplan gesendet werden, Feedback-Pakete aber früh gesendet werden können. Das oben erwähnte Problem führt jedoch dazu, dass die RTCP-Pakete tatsächlich im Bereich [0,5Td, 2,731Td] mit einer stark uneinheitlichen Verteilung gesendet werden, statt im Bereich [0,41Td, 1,23Td]. Dies ist vielleicht unerwartet, aber an sich kein Problem. In Verbindung mit Paketverlust wirft es jedoch das Problem vorzeitiger Timeouts auf.

7.1.2. Vermeidung vorzeitiger Timeouts

In RTP/AVP [RFC3550] ist das Timeout-Verhalten einfach; es beträgt das Fünffache von Td, wobei Td mit einem Tmin-Wert von 5 Sekunden berechnet wird. Mit anderen Worten: Wenn die konfigurierte RTCP-Bandbreite ein durchschnittliches RTCP-Berichtsintervall von weniger als 5 Sekunden zulässt, beträgt der Timeout 25 Sekunden ohne Aktivität der SSRC (RTP oder RTCP); andernfalls beträgt der Timeout fünf durchschnittliche Berichtsintervalle.

RTP/AVPF [RFC4585] führt je nach Wert von T_rr_interval unterschiedliche Timeout-Verhaltensweisen ein. Wenn T_rr_interval 0 ist, wird dieselbe Timeout-Berechnung wie bei RTP/AVP verwendet. Wenn T_rr_interval jedoch ungleich null ist, ersetzt es Tmin in der Timeout-Berechnung, höchstwahrscheinlich um die Erkennung von zeitlich überschrittenen SSRCs zu beschleunigen. Die Verwendung eines von null verschiedenen T_rr_interval hat jedoch zwei Konsequenzen für das RTP-Verhalten.

Erstens kann aufgrund der Unterdrückung die Anzahl der von einer SSRC, die kein aktiver RTP-Sender ist, gesendeten RTP- und RTCP-Pakete sehr niedrig werden, und zwar wegen des in Abschnitt 7.1.1 erörterten Problems. Da das RTCP-Paketintervall bis zu 2,73Td betragen kann, überträgt ein Endpunkt während eines Zeitraums von 5Td möglicherweise tatsächlich nur ein einziges RTCP-Paket. Die langen Intervalle führen zu weniger RTCP-Paketen, bis zu einem Punkt, an dem ein einzelner RTCP-Paketverlust manchmal zum Timeout einer SSRC führen kann.

Zweitens verringern die Änderungen der Timeout-Regeln in RTP/AVPF die Robustheit gegenüber Fehlkonfigurationen. Es ist üblich, RTP/AVPF so zu konfigurieren, dass RTCP-Pakete häufig gesendet werden können, um schnelles Feedback zu ermöglichen; dies macht die Timeouts jedoch sehr empfindlich gegenüber T_rr_interval. Wenn beispielsweise zwei SSRCs konfiguriert sind, eine mit T_rr_interval = 0,1 s und die andere mit T_rr_interval = 0,6 s, dann führt dieser kleine Unterschied dazu, dass die SSRC mit dem kürzeren T_rr_interval die andere zeitlich überschreitet, wenn diese aufhört, RTP-Pakete zu senden, da das andere RTCP-Berichtsintervall mehr als das Fünffache des eigenen beträgt. Wenn RTP/AVP verwendet wird oder RTP/AVPF mit T_rr_interval = 0, ist dies kein Problem, da der Timeout-Zeitraum 25 s beträgt und Unterschiede zwischen der konfigurierten RTCP-Bandbreite nur dann vorzeitige Timeouts verursachen können, wenn die Berichtsintervalle größer als 5 s sind und sich um den Faktor fünf unterscheiden. Um den Spielraum für solche problematischen Fehlkonfigurationen zu begrenzen, definieren wir in Abschnitt 7.1.4 eine Aktualisierung der RTP/AVPF-Timeout-Regeln.

7.1.3. Interoperabilität zwischen RTP/AVP und RTP/AVPF

Wenn Endpunkte, die die Profile RTP/AVP und RTP/AVPF implementieren (oder ihre sicheren Varianten), innerhalb einer einzigen RTP-Sitzung kombiniert werden und die RTP/AVPF-Endpunkte ein von null verschiedenes T_rr_interval verwenden, das deutlich unter 5 Sekunden liegt, besteht das Risiko, dass die RTP/AVPF-Endpunkte aufgrund ihrer unterschiedlichen RTCP-Timeout-Regeln vorzeitig einen Timeout für die SSRCs der RTP/AVP-Endpunkte feststellen. Umgekehrt besteht, wenn die RTP/AVPF-Endpunkte ein T_rr_interval verwenden, das deutlich größer als 5 Sekunden ist, das Risiko, dass die RTP/AVP-Endpunkte einen Timeout für die SSRCs der RTP/AVPF-Endpunkte feststellen.

Das Mischen von Endpunkten, die zwei verschiedene RTP-Profile verwenden, innerhalb einer einzigen RTP-Sitzung ist NOT RECOMMENDED. Wenn jedoch gemischte RTP-Profile verwendet werden und die RTP/AVPF-Endpunkte nicht aktualisiert werden, um Abschnitt 7.1.4 dieses Memorandums zu folgen, dann SHOULD die RTP/AVPF-Sitzung so konfiguriert werden, dass T_rr_interval = 4 Sekunden verwendet wird, um vorzeitige Timeouts zu vermeiden.

Die Wahl von T_rr_interval = 4 Sekunden für die Interoperabilität mag seltsam erscheinen. Intuitiv sollte dieser Wert 5 Sekunden betragen, damit sowohl RTP/AVP als auch RTP/AVPF denselben Timeout-Zeitraum verwenden. Das in Abschnitt 7.1.1 dargelegte Verhalten zeigt jedoch, dass tatsächliche RTP/AVPF-Berichtsintervalle länger als erwartet sein können. Die Einstellung T_rr_interval = 4 Sekunden ergibt tatsächliche RTCP-Intervalle nahe denen, die von RTP/AVP erwartet werden, und gewährleistet so die Interoperabilität.

7.1.4. Aktualisierte SSRC-Timeout-Regeln

Um die Interoperabilität sicherzustellen und vorzeitige Timeouts zu vermeiden, MUST alle SSRCs in einer RTP-Sitzung dasselbe Timeout-Verhalten verwenden. Frühere Spezifikationen sind diesbezüglich jedoch inkonsistent. Um Interoperabilitätsprobleme zu vermeiden, aktualisiert dieses Memorandum die Timeout-Regeln wie folgt:

• Für die Profile RTP/AVP, RTP/SAVP, RTP/AVPF und RTP/SAVPF SHALL das Timeout-Intervall unter Verwendung eines Multiplikators vom Fünffachen des deterministischen RTCP-Berichtsintervalls berechnet werden. Das heißt, das Timeout-Intervall SHALL 5*Td betragen.
• Für die Profile RTP/AVP, RTP/SAVP, RTP/AVPF und RTP/SAVPF SHALL die Berechnung von Td, und zwar allein zum Zweck der Berechnung des Teilnehmer-Timeouts, unter Verwendung eines Tmin-Werts von 5 Sekunden und nicht des reduzierten minimalen Intervalls erfolgen, selbst wenn das reduzierte minimale Intervall zur Berechnung der RTCP-Paketübertragungsintervalle verwendet wird.

Dies ändert das Verhalten für die Profile RTP/AVPF oder RTP/SAVPF, wenn T_rr_interval != 0 gilt. Insbesondere wird der erste Absatz von Abschnitt 3.5.4 von [RFC4585] dahingehend aktualisiert, dass Tmin anstelle von T_rr_interval in der Timeout-Berechnung für RTP/AVPF-Entitäten verwendet wird.

7.2. Feinabstimmung der RTCP-Übertragungen

Dieser Unterabschnitt erörtert, welche Feinabstimmung vorgenommen werden kann, um die Nachteile der gemeinsam genutzten RTCP-Paketintervalle zu verringern. Zunächst werden die Möglichkeiten für das RTP/AVP-Profil [RFC3551] aufgeführt, gefolgt von den zusätzlichen Werkzeugen, die RTP/AVPF [RFC4585] bietet.

7.2.1. RTP/AVP und RTP/SAVP

Bei Verwendung der Profile RTP/AVP oder RTP/SAVP sind die Möglichkeiten zur Feinabstimmung der RTCP-Berichtsintervalle auf die RTCP-Sender- und -Empfängerbandbreite und darauf beschränkt, ob das minimale RTCP-Intervall entsprechend der Bandbreite skaliert wird. Da der Planungsalgorithmus sowohl Randomisierung als auch Neubewertung umfasst, kann man das erwartete durchschnittliche Übertragungsintervall nicht einfach mit der in Abschnitt 6.3.1 von [RFC3550] angegebenen Formel für Td berechnen. Indem wir jedoch die Eingaben in diesen Ausdruck sowie die Randomisierungs- und Neubewertungsregeln betrachten, können wir beginnen, das Verhalten des RTCP-Übertragungsintervalls zu verstehen.

Beginnen wir mit einigen grundlegenden Beobachtungen:

1. Sofern nicht das skalierte minimale RTCP-Intervall verwendet wird, kann Td vor Randomisierung und Neubewertung niemals kleiner als Tmin sein. Der Standardwert von Tmin beträgt 5 Sekunden.
2. Wenn das skalierte minimale RTCP-Intervall verwendet wird, kann Td bis auf 360 geteilt durch die RTP-Sitzungsbandbreite in Kilobit pro Sekunde sinken. In SDP wird die RTP-Sitzungsbandbreite mit einer Zeile "b=AS" signalisiert. Eine RTP-Sitzungsbandbreite von 72 kbps ergibt ein Tmin von 5 Sekunden. Eine RTP-Sitzungsbandbreite von 360 kbps ergibt natürlich ein Tmin von 1 Sekunde, und um ein Tmin gleich einmal pro Frame für einen Videostrom mit 25 Frames pro Sekunde zu erreichen, ist eine RTP-Sitzungsbandbreite von 9 Mbps erforderlich. Die Verwendung des RTP/AVPF- oder RTP/SAVPF-Profils ermöglicht bei gleicher Bandbreite häufigere RTCP-Berichte, wie unten erörtert.
3. Der Wert von Td skaliert mit der Anzahl der SSRCs und der durchschnittlichen Größe der RTCP-Berichte, um die gesamte RTCP-Bandbreite konstant zu halten.
4. Das tatsächliche Übertragungsintervall für einen Td-Wert liegt im Bereich [0,5Td/1,21828, 1,5Td/1,21828], und die Verteilung ist aufgrund der Neubewertung verzerrt, wobei der Großteil der Wahrscheinlichkeitsmasse oberhalb von Td liegt. Das bedeutet zum Beispiel, dass für Td = 5 s das tatsächliche Übertragungsintervall im Bereich [2,052 s, 6,156 s] verteilt ist und zur oberen Hälfte des Intervalls tendiert. Beachten Sie, dass der Parameter Tmin den Wert von Td begrenzt, bevor Randomisierung und Neubewertung angewendet werden, sodass das tatsächliche Übertragungsintervall einen Bereich abdeckt, der unter Tmin reicht.

Angesichts des oben Gesagten können wir die Anzahl der SSRCs, n, berechnen, die eine RTP-Sitzung mit 5 % der Sitzungsbandbreite, die RTCP zugewiesen sind, unterstützen kann, während Td gleich Tmin bleibt. Dies sagt uns, über wie viele RTP-Ströme wir Bericht erstatten können, wobei der RTCP-Overhead in akzeptablen Grenzen bleibt. Wir treffen zwei Annahmen, die die Berechnung vereinfachen: dass alle SSRCs Sender sind und dass sie alle zusammengesetzte RTCP-Pakete senden, die aus einem SR-Paket mit n-1 Berichtsblöcken bestehen, gefolgt von einem SDES-Paket mit einem 16 Oktett großen CNAME-Wert [RFC7022] (solche RTCP-Pakete variieren in ihrer Größe zwischen 54 und 798 Oktett je nach n, bis zum Maximum von 31 Berichtsblöcken, die in ein SR-Paket aufgenommen werden können). Wenn wir diese Paketgröße und einen RTCP-Bandbreitenanteil von 5 % in die RTCP-Intervallberechnung in Abschnitt 6.3.1 von [RFC3550] einsetzen und den Wert von n berechnen, der für das skalierte minimale Intervall Td = Tmin ergibt, stellen wir fest, dass n=9 SSRCs unterstützt werden können (unabhängig vom Intervall, aufgrund der Art und Weise, wie das Berichtsintervall mit der Sitzungsbandbreite skaliert). Wir sehen, dass wir, um mehr SSRCs ohne Änderung des skalierten minimalen Intervalls zu unterstützen, den RTCP-Bandbreitenanteil von 5 % erhöhen müssen; eine Änderung der Sitzungsbandbreite auf einen höheren Wert würde das Tmin verringern. Wenn jedoch die Standardzuweisung von 5 % der RTCP-Bandbreite verwendet wird, führt eine Erhöhung bei einem festen Td-Ziel dazu, dass mehr SSRCs unterstützt werden.

Auf der Grundlage des oben Gesagten wird bei Verwendung des RTP/AVP-Profils oder des RTP/SAVP-Profils die wichtigste Einschränkung für eine schnelle RTCP-Berichterstattung in kleinen Unicast-Sitzungen der Tmin-Wert sein. Die in RTCP konfigurierte RTP-Sitzungsbandbreite muss ausreichend hoch sein, um die Berichtsziele zu erreichen, die die Anwendung gemäß den Regeln für das skalierte minimale RTCP-Intervall verfolgt.

7.2.2. RTP/AVPF und RTP/SAVPF

Bei Verwendung von RTP/AVPF oder RTP/SAVPF steht uns ein leistungsfähiges zusätzliches Werkzeug zur Feinabstimmung der RTCP-Übertragungen zur Verfügung: der Parameter T_rr_interval. Die Verwendung dieses Parameters ermöglicht kurze RTCP-Berichtsintervalle; alternativ bietet er die Möglichkeit, häufiges RTCP-Feedback zu senden, ohne häufige reguläre RTCP-Berichte zu senden.

Die Verwendung des RTP/AVPF- oder RTP/SAVPF-Profils mit einem T_rr_interval, das auf einen Wert größer als null, aber kleiner als Tmin gesetzt ist, ermöglicht bei gegebener RTCP-Bandbreite häufigeres RTCP-Feedback als die Profile RTP/AVP oder RTP/SAVP. Dies geschieht, weil Tmin nach der Übertragung des anfänglichen RTCP-Berichts auf null gesetzt wird, wodurch das Berichtsintervall für spätere Pakete durch die übliche bandbreitenbasierte RTCP-Berechnung mit Tmin=0 und durch das T_rr_interval bestimmt wird. Dies hat zur Folge, dass wir nicht mehr durch das minimale Intervall eingeschränkt sind (sei es die standardmäßige 5-Sekunden-Mindestgrenze oder das reduzierte minimale Intervall). Vielmehr sind die RTCP-Bandbreite und das T_rr_interval die maßgeblichen Faktoren, was ein schnelleres Feedback ermöglicht. Anwendungen, denen ein schnelles reguläres RTCP-Feedback wichtig ist, sollten die Verwendung des RTP/AVPF- oder RTP/SAVPF-Profils in Betracht ziehen, selbst wenn sie die Feedback-Funktionen dieses Profils nicht nutzen.

Die Verwendung des RTP/AVPF- oder RTP/SAVPF-Profils ermöglicht es, RTCP-Feedback-Pakete häufig zu senden, ohne dass auch reguläre RTCP-Berichte häufig gesendet werden müssen, da T_rr_interval die Rate begrenzt, mit der reguläre RTCP-Pakete gesendet werden können, während RTCP-Feedback-Pakete weiterhin gesendet werden dürfen. Anwendungen, die Feedback-Pakete für einige RTP-Ströme, z. B. Videoströme, nutzen können, aber für andere RTP-Ströme keine häufige reguläre Berichterstattung wünschen, können das T_rr_interval auf einen Wert konfigurieren, sodass die reguläre Berichterstattung sowohl für Audio als auch für Video auf einem für das Audio als akzeptabel erachteten Niveau liegt. Sie könnten dann Feedback-Pakete, die RTCP-SR/RR-Pakete einschließen, sofern keine RTCP-Feedback-Pakete reduzierter Größe [RFC5506] verwendet werden, für die Videoberichterstattung nutzen. Dadurch kann die verfügbare RTCP-Bandbreite auf das Feedback konzentriert werden, das für die Anwendung den größten Nutzen bringt.

Die Verwendung von T_rr_interval erfordert weiterhin, dass man geeignete Werte für den RTCP-Bandbreitenwert bestimmt. Tatsächlich kann dies diese Wahl sogar noch wichtiger machen, da sie das RTCP-Verhalten und die RTCP-Leistung wahrscheinlicher beeinflusst als bei Verwendung des RTP/AVP- oder RTP/SAVP-Profils, da es weniger Einschränkungen gibt, die die RTCP-Übertragung betreffen.

Wenn T_rr_interval ungleich null ist, gibt es Konfigurationen, die vermieden werden müssen. Wenn die gewählte RTCP-Bandbreite so beschaffen ist, dass der Td-Wert kleiner als, aber nahe bei T_rr_interval liegt, dann kann das tatsächliche reguläre RTCP-Paketübertragungsintervall sehr groß werden, wie in Abschnitt 7.1.1 erörtert. Daher ist für eine Konfiguration, bei der beabsichtigt ist, dass Td kleiner als T_rr_interval ist, RECOMMENDED, Td auf Werte unter einem Viertel von T_rr_interval abzuzielen, was dazu führt, dass der Bereich [0,5T_rr_interval, 1,81T_rr_interval] wird.

Bei den Profilen RTP/AVPF oder RTP/SAVPF hat die Verwendung von T_rr_interval = 0 einen Nutzen und führt zu einem Verhalten, bei dem die RTCP-Übertragung nur durch die Bandbreite begrenzt wird, d. h. ohne jegliche Tmin-Einschränkungen. Dies ermöglicht eine häufigere reguläre RTCP-Berichterstattung als mit dem RTP/AVP-Profil erreicht werden kann. Viele RTCP-Konfigurationen werden nicht die gesamte Bandbreite verbrauchen, für deren Nutzung sie konfiguriert wurden, aber diese Konfiguration wird das verbrauchen, was ihr zugewiesen wurde. Beachten Sie, dass dasselbe Verhalten erreicht wird, solange T_rr_interval kleiner als ein Drittel von Td ist, da dies verhindert, dass T_rr_interval die Übertragung beeinflusst.

Es existiert keine Methode, um je nach Medientyp oder individuellem RTP-Strom unterschiedliche reguläre RTCP-Berichtsintervalle zu verwenden, außer für jeden Typ oder Strom eine separate RTP-Sitzung zu nutzen.