3.5. AVPF-RTCP-Scheduling-Algorithmus (AVPF RTCP Scheduling Algorithm)

Sei S0 ein aktiver Sender (von S Sendern) und N die Anzahl der Empfänger, wobei R einer dieser Empfänger ist.

Es wird angenommen, dass R verifiziert hat, dass der Einsatz von Feedback-Mechanismen in der aktuellen Konstellation sinnvoll ist (was stark anwendungsspezifisch ist und daher in diesem Dokument nicht spezifiziert wird).

Weiter wird angenommen, dass T_rr_interval gleich 0 ist, wenn kein Mindestintervall zwischen regulären RTCP-Paketen erzwungen werden soll, oder dass T_rr_interval auf einen sinnvollen Wert gesetzt ist, wie von der Anwendung vorgegeben. Dieser Wert bezeichnet dann das Mindestintervall zwischen regulären RTCP-Paketen.

Damit MUST ein Empfänger R die folgenden Regeln zur Übertragung einer oder mehrerer FB-Nachrichten als minimales oder vollständiges zusammengesetztes RTCP-Paket anwenden.

3.5.1. Initialisierung

Zunächst MUST R allow_early = TRUE und t_rr_last = NaN (Not-a-Number, d. h. ein ungültiger Wert, der sich von einer gültigen Zeit unterscheiden lässt) setzen.

Darüber hinaus gilt die Initialisierung der RTCP-Variablen gemäß [1], mit Ausnahme des Anfangswerts für Tmin. Für eine Punkt-zu-Punkt-Sitzung wird der anfängliche Tmin auf 0 gesetzt. Für eine Mehrteilnehmer-Sitzung wird Tmin mit 1,0 Sekunden initialisiert.

3.5.2. Übertragung von Early-Feedback

Es wird angenommen, dass R die letzte reguläre RTCP-RR-Übertragung für den Zeitpunkt tp geplant hat (und dieses Paket bei tp gesendet oder unterdrückt hat) und die nächste Übertragung (einschließlich möglicher Reconsideration gemäß [1]) für tn = tp + T_rr geplant hat. Es wird ferner angenommen, dass die letzte reguläre RTCP-Übertragung zu t_rr_last stattfand.

Der Early-Feedback-Algorithmus umfasst dann die folgenden Schritte:

1. Zum Zeitpunkt t0 erkennt R die Notwendigkeit, eine oder mehrere FB-Nachrichten zu übertragen, z. B. weil Medien-„Einheiten“ bestätigt oder negativ bestätigt werden müssen, und stellt fest, dass die Bereitstellung der Feedback-Informationen für den Sender potenziell nützlich ist.

2. R prüft zuerst, ob bereits ein zusammengesetztes RTCP-Paket mit einer oder mehreren FB-Nachrichten zur Übertragung geplant ist (entweder als Early- oder als reguläres RTCP-Paket).

   2a) Wenn ja, MUST die neue FB-Nachricht in das geplante Paket aufgenommen werden; die Planung des wartenden zusammengesetzten RTCP-Pakets MUST unverändert bleiben. Dabei SHOULD die verfügbaren Feedback-Informationen zusammengeführt werden, um möglichst wenige FB-Nachrichten zu erzeugen. Damit ist der Ablauf unmittelbarer Maßnahmen abgeschlossen.

   2b) Wenn kein zusammengesetztes RTCP-Paket bereits zur Übertragung geplant ist, MUST ein neues (minimales oder vollständiges) zusammengesetztes RTCP-Paket erstellt werden und das minimale Intervall für T_dither_max MUST wie folgt gewählt werden:

   i) Wenn die Sitzung eine Punkt-zu-Punkt-Sitzung ist, dann

   T_dither_max = 0.

   ii) Wenn die Sitzung eine Mehrteilnehmer-Sitzung ist, dann

   T_dither_max = l * T_rr

   mit l=0,5.

   Der Wert für T_dither_max MAY anders berechnet werden (z. B. basierend auf RTT), was MUST dann in einem zukünftigen Dokument spezifiziert werden. Eine solche spätere Spezifikation MUST sicherstellen, dass alle RTP-Empfänger dasselbe Verfahren zur Berechnung von T_dither_max verwenden.

   Die oben angegebenen Werte für T_dither_max sind Mindestwerte. Anwendungsspezifische Feedback-Überlegungen können es rechtfertigen, T_dither_max über diesen Wert hinaus zu erhöhen. Dies liegt im Ermessen des Implementierers.

3. Dann MUST R prüfen, ob sein nächstes reguläres RTCP-Paket innerhalb der Zeitgrenzen für das bei t0 ausgelöste Early-RTCP-Paket läge, d. h. ob t0 + T_dither_max > tn.

   3a) Wenn ja, MUST kein Early-RTCP-Paket geplant werden; stattdessen MUST die bzw. die FB-Nachrichten gespeichert werden, um sie in das für tn geplante reguläre RTCP-Paket aufzunehmen. Damit ist der Ablauf unmittelbarer Maßnahmen abgeschlossen.

   3b) Andernfalls werden die folgenden Schritte ausgeführt.

4. R MUST prüfen, ob die Übertragung eines Early-RTCP-Pakets erlaubt ist, d. h. ob allow_early == TRUE oder nicht.

   4a) Wenn allow_early == FALSE, dann MUST R die Zeit für das nächste geplante reguläre RTCP-Paket prüfen:

   1. Wenn tn - t0 < T_max_fb_delay, dann könnte das Feedback für den Sender trotz verspäteter Meldung noch nützlich sein. Daher MAY R eine RTCP-FB-Nachricht erstellen, die in das für tn geplante reguläre RTCP-Paket aufgenommen wird.

   2. Andernfalls MUST R die RTCP-FB-Nachricht verwerfen.

   Damit ist der unmittelbare Maßnahmenablauf abgeschlossen.

   4b) Wenn allow_early == TRUE, dann MUST R ein Early-RTCP-Paket für te = t0 + RND * T_dither_max planen, wobei RND eine Pseudozufallsfunktion mit gleichmäßiger Verteilung zwischen 0 und 1 ist.

5. R MUST Überschneidungen zwischen FB-Nachrichten, die von anderen Mitgliedern der RTP-Sitzung empfangen wurden, und den FB-Nachrichten, die R senden will, erkennen. Daher MUST R während der Mitgliedschaft in der RTP-Sitzung kontinuierlich das Eintreffen (minimaler) zusammengesetzter RTCP-Pakete überwachen und jede in diesen RTCP-Paketen enthaltene FB-Nachricht mindestens für T_retention speichern. Bei der Planung der Übertragung der eigenen FB-Nachricht nach den Schritten 1 bis 4 oben MUST R jede der gespeicherten und neu empfangenen FB-Nachrichten aus den im Intervall [t0 - T_retention ; te] empfangenen RTCP-Paketen prüfen und wie folgt verfahren:

   5a) Wenn R die Semantik der empfangenen FB-Nachricht versteht und der Nachrichteninhalt eine Obermenge des Feedbacks ist, das R senden wollte, dann MUST R die eigene FB-Nachricht verwerfen und MUST die nächste reguläre RTCP-Übertragung für tn (wie zuvor berechnet) neu planen.

   5b) Wenn R die Semantik der empfangenen FB-Nachricht versteht und der Nachrichteninhalt keine Obermenge des gewünschten Feedbacks ist, SHOULD R die eigene FB-Nachricht wie geplant senden. Bei Überschneidung zwischen zu sendendem und empfangenem Feedback liegt die Menge des übertragenen Feedbacks bei R: R MAY sein zu sendendes Feedback unverändert lassen, R MAY ebenso Redundanz zwischen eigenem Feedback und dem bisher von anderen Sitzungsmitgliedern empfangenen Feedback beseitigen.

   5c) Wenn R die Semantik der empfangenen FB-Nachricht nicht versteht, MAY R die eigene FB-Nachricht als Early-RTCP-Paket geplant lassen, oder R MAY die nächste reguläre RTCP-Übertragung für tn (wie zuvor berechnet) neu planen und MAY die FB-Nachricht an die nun regulär geplante RTCP-Nachricht anhängen.

   Hinweis: Mit 5c) kann das Empfangen unbekannter FB-Nachrichten nicht zur Feedback-Unterdrückung bei einem bestimmten Empfänger führen. Folglich kann ein gegebenes Ereignis M verschiedene Arten von FB-Nachrichten (die alle passend, aber nicht gegenseitig verstanden werden) auslösen, sodass eine „große“ Empfängergruppe faktisch in höchstens M Gruppen zerlegt werden kann. Innerhalb jeder dieser M Gruppen tritt Feedback-Unterdrückung gemäß 5a und 5b auf, gruppenübergreifend jedoch nicht. In der Folge können O(M) RTCP-FB-Nachrichten beim Sender ankommen. Es besteht daher die Chance einer sehr begrenzten Feedback-Implosion. Da Sender und alle Empfänger dieselbe Anwendung mit denselben Codec(s) in derselben RTP-Sitzung nutzen, kann jedoch nur geringe Divergenz in der Semantik von FB-Nachrichten sicher angenommen werden, und M wird im Allgemeinen als klein angenommen.

   Unter der weiteren Annahme, dass die O(M) FB-Nachrichten zufällig über ein Zeitintervall von T_dither_max verteilt sind, ergibt sich, dass die dadurch entstehende begrenzte Zahl zusätzlicher zusammengesetzter RTCP-Pakete (a) den Sender voraussichtlich nicht überlastet und (b) übertragen werden sollten, da sie alle ergänzende Informationsteile enthalten.

6. Wenn Rs FB-Nachricht(en) nicht durch andere Empfänger-FB-Nachrichten gemäß 5 unterdrückt wurden, MUST R bei Erreichen von te das (minimale) zusammengesetzte RTCP-Paket mit seinen FB-Nachrichten senden. R MUST dann allow_early = FALSE setzen, MUST tn = tp + 2*T_rr neu berechnen und MUST tp auf den vorherigen tn setzen. Sobald der neu berechnete tn erreicht ist – unabhängig davon, ob R sein nächstes reguläres RTCP-Paket sendet oder es wegen T_rr_interval unterdrückt –, MUST allow_early wieder TRUE gesetzt werden.

3.5.3. Reguläre RTCP-Übertragung

Vollständige zusammengesetzte RTCP-Pakete MUST in regelmäßigen Abständen gesendet werden. Diese Pakete MAY auch eine oder mehrere FB-Nachrichten enthalten. Die Übertragung regulärer RTCP-Pakete wird wie folgt geplant:

Wenn T_rr_interval == 0, dann MUST die Übertragung den in den Abschnitten 3.2 und 3.4 dieses Dokuments spezifizierten Regeln folgen und MUST den Anpassungen von tn gemäß Abschnitt 3.5.2 entsprechen (d. h. eine reguläre Übertragung auslassen, wenn eine Early-RTCP-Übertragung stattgefunden hat). Die Timer-Reconsideration erfolgt bei Erreichen von tn gemäß [1]. Das reguläre RTCP-Paket wird nach der Timer-Reconsideration gesendet. Wann immer ein reguläres RTCP-Paket gesendet oder unterdrückt wird, MUST allow_early auf TRUE gesetzt und tp, tn gemäß [1] aktualisiert werden. Nach der ersten Übertragung eines regulären RTCP-Pakets MUST Tmin auf 0 gesetzt werden.

Wenn T_rr_interval != 0, dann MUST die Berechnung der Übertragungszeiten den in den Abschnitten 3.2 und 3.4 dieses Dokuments spezifizierten Regeln folgen und MUST den Anpassungen von tn gemäß Abschnitt 3.5.2 entsprechen (d. h. eine reguläre Übertragung auslassen, wenn eine Early-Übertragung stattgefunden hat). Die Timer-Reconsideration erfolgt bei Erreichen von tn gemäß [1]. Nach der Timer-Reconsideration werden folgende Aktionen ausgeführt:

1. Wenn zuvor kein reguläres RTCP-Paket gesendet wurde (d. h. wenn t_rr_last == NaN), dann MUST ein reguläres RTCP-Paket geplant werden. Gespeicherte FB-Nachrichten MAY in das reguläre RTCP-Paket aufgenommen werden. Nach dem Senden des geplanten Pakets MUST t_rr_last auf tn gesetzt werden. Tmin MUST auf 0 gesetzt werden.

2. Andernfalls wird ein temporärer Wert T_rr_current_interval wie folgt berechnet:

   T_rr_current_interval = RND*T_rr_interval

   wobei RND eine Pseudozufallsfunktion mit gleichmäßiger Verteilung zwischen 0,5 und 1,5 ist. Dieser geditherte Wert dient zur Wahl einer der folgenden Alternativen:

   2a) Wenn t_rr_last + T_rr_current_interval <= tn, dann MUST ein reguläres RTCP-Paket geplant werden. Gespeicherte RTCP-FB-Nachrichten MAY in das reguläre RTCP-Paket aufgenommen werden. Nach dem Senden des geplanten Pakets MUST t_rr_last auf tn gesetzt werden.

   2b) Wenn t_rr_last + T_rr_current_interval > tn und RTCP-FB-Nachrichten gespeichert sind und auf Übertragung warten, dann MUST ein RTCP-Paket zur Übertragung bei tn geplant werden. Dieses RTCP-Paket MAY ein minimales oder ein reguläres RTCP-Paket sein (nach Ermessen des Implementierers), und das zusammengesetzte RTCP-Paket MUST die gespeicherten RTCP-FB-Nachrichten enthalten. t_rr_last MUST unverändert bleiben.

   2c) Andernfalls (wenn t_rr_last + T_rr_current_interval > tn, aber keine gespeicherten RTCP-FB-Nachrichten auf Übertragung warten), MUST das zusammengesetzte RTCP-Paket unterdrückt werden (d. h. es MUST nicht geplant werden). t_rr_last MUST unverändert bleiben.

In allen vier Fällen oben (1, 2a, 2b und 2c) MUST allow_early auf TRUE gesetzt werden (möglicherweise nach dem Senden des regulären RTCP-Pakets), und tp sowie tn MUST nach den Regeln von [1] aktualisiert werden, mit Ausnahme der Fünf-Sekunden-Mindestgrenze.

3.5.4. Weitere Überlegungen

Wenn T_rr_interval != 0, dann MUST die Timeout-Berechnung für RTP/AVPF-Entitäten (Abschnitt 6.3.5 von [1]) so geändert werden, dass für die Berechnung von Td und damit M*Td zum Zeitablauf von RTP-Entitäten T_rr_interval anstelle von Tmin verwendet wird.

Wann immer ein zusammengesetztes RTCP-Paket gesendet oder empfangen wird – minimal oder vollständig zusammengesetzt, Early oder regulär –, MUST die Variable avg_rtcp_size entsprechend aktualisiert werden (siehe [1]), und nachfolgende Berechnungen von tn MUST die neue avg_rtcp_size verwenden.