4. RTCP Receiver Report-Erweiterungen

Diese Spezifikation definiert sechs neue Feedback-Nachrichten. Full Intra Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Trade-off Notification (TSTN) und Video Back Channel Message (VBCM) sind "Payload Specific Feedback Messages" gemäß Abschnitt 6.3 von AVPF [RFC4585]. Temporary Maximum Media Stream Bit Rate Request (TMMBR) und Temporary Maximum Media Stream Bit Rate Notification (TMMBN) sind "Transport Layer Feedback Messages" gemäß Abschnitt 6.2 von AVPF.

Die neuen Feedback-Nachrichten werden in den folgenden Unterabschnitten definiert und folgen einer ähnlichen Struktur wie in den Abschnitten 6.2 und 6.3 der AVPF-Spezifikation [RFC4585].

4.1. Entwurfsprinzipien des Erweiterungsmechanismus

RTCP wurde ursprünglich als Kanal zur Übermittlung von Präsenz, Empfangsqualitätsstatistiken und Hinweisen zur gewünschten Mediencodierung eingeführt. Eine begrenzte Anzahl von Mediensteuerungsmechanismen wurde in frühen RTP-Payload-Formaten für Videoformate eingeführt, beispielsweise in RFC 2032 [RFC2032] (das durch RFC 4587 [RFC4587] ersetzt wurde). Diese Spezifikation schlägt jedoch erstmals einen bidirektionalen Handshake für einige ihrer Nachrichten vor. Es besteht die Gefahr, dass diese Einführung als Präzedenzfall für die Verwendung von RTCP als RTP-Sitzungssteuerungsprotokoll missverstanden werden könnte. Um ein solches Missverständnis zu vermeiden, versucht dieser Unterabschnitt, den Geltungsbereich der in dieser Spezifikation festgelegten Erweiterungen zu klären, und es wird nachdrücklich empfohlen, dass zukünftige Erweiterungen der hier dargelegten Begründung folgen oder überzeugend erklären, warum sie von der Begründung abweichen.

In dieser Spezifikation und in AVPF [RFC4585] wurden nur solche Nachrichten aufgenommen, die:

a) vergleichsweise strenge Echtzeit-Einschränkungen haben, die die Verwendung von Mechanismen wie einem SIP-Re-Invite in den meisten Anwendungsszenarien verhindern (die Echtzeit-Einschränkungen werden bei Bedarf für jede Nachricht separat erläutert);

b) multicast-sicher sind, indem die Reaktion auf potenziell widersprüchliche Feedback-Nachrichten bei Bedarf für jede Nachricht spezifiziert wird; und

c) direkt mit Aktivitäten eines bestimmten Medien-Codecs, einer Klasse von Medien-Codecs (z. B. Video-Codecs) oder eines gegebenen RTP-Paketstroms zusammenhängen.

In dieser Spezifikation wird ein bidirektionaler Handshake nur für Nachrichten eingeführt, für die:

a) aufgrund ihrer Natur eine Benachrichtigung oder Bestätigung erforderlich ist. Eine Analyse zur Feststellung, ob diese Anforderung besteht, wurde für jede Nachricht separat durchgeführt.

b) die Benachrichtigung oder Bestätigung nicht einfach aus dem Medienbitstrom abgeleitet werden kann.

Alle Nachrichten in AVPF [RFC4585] und in dieser Spezifikation präsentieren ihren Inhalt in einem einfachen, festen Binärformat. Dies kommt Medienempfängern entgegen, die keine höheren Steuerungsprotokoll-Funktionalitäten (SDP, XML-Parser usw.) in ihrem Medienpfad implementiert haben.

Nachrichten, die nicht den gerade beschriebenen Designprinzipien entsprechen, sind keine angemessene Verwendung von RTCP oder des in diesem Dokument definierten Codec Control Framework.

4.2. Feedback-Nachrichten auf der Transportschicht

Wie in Abschnitt 6.1 von RFC 4585 [RFC4585] spezifiziert, werden Transport Layer Feedback-Nachrichten durch den RTCP-Pakettyp-Wert RTPFB (205) identifiziert.

In AVPF wurde eine Nachricht dieser Kategorie definiert. Diese Spezifikation definiert zwei weitere solche Nachrichten. Sie werden mittels des Feedback Message Type (FMT)-Parameters wie folgt identifiziert:

Zugewiesen in AVPF [RFC4585]:

• 1: Generic NACK
• 31: reserviert für zukünftige Erweiterung des Identifikationsnummernraums

Zugewiesen in dieser Spezifikation:

• 2: reserviert (siehe Hinweis unten)

• 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)

• 4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

  Hinweis: Frühe Versionen von AVPF [RFC4585] reservierten FMT=2 für einen Code-Punkt, der später entfernt wurde. Es wurde darauf hingewiesen, dass es möglicherweise Implementierungen im Feld gibt, die diesen Wert gemäß dem abgelaufenen Dokument verwenden. Da ausreichend Nummerierungsraum verfügbar ist, markieren wir FMT=2 als reserviert, um mögliche Interoperabilitätsprobleme mit solchen frühen Implementierungen zu vermeiden.

Verfügbar zur Zuweisung:

• 0: nicht zugewiesen
• 5-30: nicht zugewiesen

Der folgende Unterabschnitt definiert die Formate der Feedback Control Information (FCI)-Einträge für die TMMBR- und TMMBN-Nachrichten und spezifiziert das zugehörige Verhalten beim Mediensender und Empfänger.

4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)

Die Temporary Maximum Media Stream Bit Rate Request wird durch RTCP-Pakettyp-Wert PT=RTPFB und FMT=3 identifiziert.

Das FCI-Feld einer Temporary Maximum Media Stream Bit Rate Request (TMMBR)-Nachricht MUSS einen oder mehrere FCI-Einträge enthalten.

4.2.1.1. Nachrichtenformat

Die Feedback Control Information (FCI) besteht aus einem oder mehreren TMMBR-FCI-Einträgen mit der folgenden Syntax:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 2 - Syntax eines FCI-Eintrags in der TMMBR-Nachricht

• SSRC (32 Bits): Der SSRC-Wert des Mediensenders, der aufgefordert wird, die neue maximale Bitrate einzuhalten.

• MxTBR Exp (6 Bits): Die exponentielle Skalierung der Mantisse für den maximalen Gesamtmedienbitraten-Wert. Der Wert ist eine vorzeichenlose Ganzzahl [0..63].

• MxTBR Mantissa (17 Bits): Die Mantisse des maximalen Gesamtmedienbitraten-Werts als vorzeichenlose Ganzzahl.

• Measured Overhead (9 Bits): Der gemessene durchschnittliche Paket-Overhead-Wert in Bytes. Die Messung MUSS gemäß der Beschreibung in Abschnitt 4.2.1.2 durchgeführt werden. Der Wert ist eine vorzeichenlose Ganzzahl [0..511].

Die maximale Gesamtmedienbitrate (MxTBR) in Bits pro Sekunde wird aus dem MxTBR-Exponenten (exp) und der Mantisse wie folgt berechnet:

MxTBR = mantissa * 2^exp

Dies ermöglicht eine 17-Bit-Auflösung im Bereich von 0 bis 1310722^63 (ungefähr 1,210^24).

Die Länge der TMMBR-Feedback-Nachricht MUSS auf 2+2*N gesetzt werden, wobei N die Anzahl der TMMBR-FCI-Einträge ist.

4.2.1.2. Semantik

Verhalten beim Medienempfänger (Sender der TMMBR)

TMMBR wird verwendet, um eine transportbezogene Einschränkung bei der berichtenden Entität anzuzeigen, die als Medienempfänger fungiert. TMMBR hat die Form eines Tupels mit zwei Komponenten. Der erste Wert ist die höchste Bitrate pro Sender eines Medienstroms, die auf einer vom Empfänger gewählten Protokollebene verfügbar ist, die der Empfänger derzeit in dieser RTP-Sitzung unterstützt. Der zweite Wert ist der gemessene Header-Overhead in Bytes, wie in Abschnitt 2.2 definiert und auf der gewählten Protokollebene in den für den Stream empfangenen Paketen gemessen. Die Messung des Overheads ist ein gleitender Durchschnitt, der für jedes für diese bestimmte Medienquelle (SSRC) empfangene Paket aktualisiert wird, unter Verwendung der folgenden Formel:

avg_OH (neu) = 15/16*avg_OH (alt) + 1/16*pckt_OH,

wobei avg_OH der gleitende (exponentiell geglättete) Durchschnitt und pckt_OH der im letzten Paket beobachtete Overhead ist.

Wenn eine maximale Bitrate durch Signalisierung ausgehandelt wurde, DARF die maximale Gesamtmedienbitrate, die der Empfänger in einer TMMBR-Nachricht meldet, den ausgehandelten Wert NICHT überschreiten, der auf eine gemeinsame Basis umgerechnet wurde (d. h. mit angepassten Overheads, um ihn auf dieselbe Referenzprotokollebene zu bringen).

Innerhalb des allgemeinen Paketheaders für Feedback-Nachrichten (wie in Abschnitt 6.1 von [RFC4585] definiert) gibt das Feld "SSRC of packet sender" die Quelle der Anfrage an, und die "SSRC of media source" wird nicht verwendet und MUSS auf 0 gesetzt werden. Innerhalb eines bestimmten TMMBR-FCI-Eintrags bezeichnet die "SSRC of media source" im FCI-Feld den Mediensender, für den das Tupel gilt. Dies ist nützlich in Multicast- oder Translator-Topologien, bei denen die berichtende Entität alle Mediensender in einer einzigen TMMBR-Nachricht unter Verwendung mehrerer FCI-Einträge adressieren kann.

Der Medienempfänger MUSS den Inhalt der letzten von jedem Mediensender empfangenen TMMBN-Nachricht speichern.

Der Medienempfänger DARF unter den folgenden Umständen einen TMMBR-FCI-Eintrag an einen bestimmten Mediensender senden:

• bevor eine TMMBN-Nachricht von diesem Mediensender empfangen wurde;

• wenn der Medienempfänger als Quelle eines begrenzenden Tupels innerhalb der letzten von diesem Mediensender empfangenen TMMBN-Nachricht identifiziert wurde und sich der Wert der maximalen Gesamtmedienbitrate oder des Overheads in Bezug auf diesen Mediensender geändert hat;

• wenn der Medienempfänger nicht als Quelle eines begrenzenden Tupels innerhalb der letzten von diesem Mediensender empfangenen TMMBN-Nachricht identifiziert wurde und nach Anwendung des inkrementellen Algorithmus aus Abschnitt 3.5.4.2 oder eines strengeren Äquivalents festgestellt wird, dass das Tupel des Medienempfängers in Bezug auf diesen Mediensender zur begrenzenden Menge gehört.

Ein TMMBR-FCI-Eintrag DARF in nachfolgenden TMMBR-Nachrichten wiederholt werden, wenn zum Zeitpunkt der Übertragung des nächsten RTCP-Pakets keine Temporary Maximum Media Stream Bit Rate Notification (TMMBN) FCI vom Mediensender empfangen wurde. Der Bitraten-Wert eines TMMBR-FCI-Eintrags DARF von einer TMMBR-Nachricht zur nächsten geändert werden. Die Overhead-Messung MUSS bei jedem Senden des Eintrags auf den aktuellen Wert von avg_OH aktualisiert werden.

Wenn erwartet wird, dass der durch eine TMMBR-Nachricht festgelegte Wert dauerhaft ist, SOLLTE die TMMBR-setzende Partei die Sitzungsparameter neu aushandeln, um dies mittels Sitzungsaufbau-Signalisierung widerzuspiegeln, z. B. einem SIP-Re-Invite.

Verhalten beim Mediensender (Empfänger der TMMBR)

Wenn er eine TMMBR-Nachricht mit einem FCI-Eintrag erhält, der sich auf ihn bezieht, MUSS der Mediensender einen initialen oder inkrementellen Algorithmus verwenden, wie anwendbar, um die begrenzende Menge von Tupeln basierend auf den neuen Informationen zu bestimmen. Der verwendete Algorithmus MUSS mindestens so streng sein wie der entsprechende in Abschnitt 3.5.4.2 definierte Algorithmus. Der Mediensender DARF TMMBRs über ein kleines Intervall (relativ zum RTCP-Sendeintervall) akkumulieren, bevor er diese Berechnung durchführt.

Nachdem er die begrenzende Menge von Tupeln bestimmt hat, DARF der Mediensender jede Kombination von Paketrate und Netto-Medienbitrate innerhalb der durchführbaren Region verwenden, die diese Tupel beschreiben, um eine niedrigere Gesamtmedienstream-Bitrate zu erzeugen, da er möglicherweise eine Überlastungssituation oder andere begrenzende Faktoren adressieren muss. Siehe Abschnitt 5 (Congestion Control) für weitere Diskussion.

Wenn der Mediensender zu dem Schluss kommt, dass er den maximalen Gesamtmedienbitraten-Wert erhöhen kann, MUSS er warten, bevor er dies tatsächlich tut, für einen Zeitraum, der lang genug ist, um einem Medienempfänger zu ermöglichen, auf die TMMBN zu antworten, wenn er feststellt, dass sein Tupel zur begrenzenden Menge gehört. Dieser Verzögerungszeitraum wird durch die Formel geschätzt:

2 * RTT + T_Dither_Max,

wobei RTT die längste dem Mediensender bekannte Roundtrip-Zeit und T_Dither_Max in Abschnitt 3.4 von [RFC4585] definiert ist. Selbst in Punkt-zu-Punkt-Sitzungen MUSS ein Mediensender die oben genannte Regel einhalten, da nicht garantiert ist, dass ein Teilnehmer korrekt feststellen kann, ob alle Quellen in einem einzigen Knoten co-lokalisiert und koordiniert sind.

Eine TMMBN-Nachricht MUSS vom Mediensender zum frühestmöglichen Zeitpunkt als Antwort auf alle seit der letzten Sendung von TMMBN empfangenen TMMBR-Nachrichten gesendet werden. Die TMMBN-Nachricht zeigt die berechnete Menge begrenzender Tupel und die Eigentümer dieser Tupel zum Zeitpunkt der Übertragung der Nachricht an.

Eine SSRC kann gemäß den Standardregeln für RTP-Sitzungsteilnehmer ablaufen, d. h., der Mediensender hat in den letzten fünf regulären Berichtsintervallen keine RTP- oder RTCP-Pakete vom Eigentümer erhalten. Eine SSRC kann auch explizit die Sitzung verlassen, wobei der Teilnehmer dies durch die Übertragung eines RTCP-BYE-Pakets oder über einen externen Signalisierungskanal anzeigt. Wenn der Mediensender feststellt, dass der Eigentümer eines Tupels in der begrenzenden Menge die Sitzung verlassen hat, MUSS der Mediensender eine neue TMMBN übertragen, die die zuvor bestimmte Menge begrenzender Tupel enthält, jedoch mit entferntem Tupel des ausgeschiedenen Eigentümers.

Ein Mediensender DARF proaktiv das Äquivalent einer TMMBR-Nachricht an sich selbst initiieren, wenn er sich bewusst ist, dass sein Übertragungspfad restriktiver ist als die aktuellen Einschränkungen. Als Ergebnis wird eine TMMBN gesendet, die die Medienquelle selbst als Eigentümer eines Tupels anzeigt, wodurch unnötige TMMBR-Nachrichten von anderen Teilnehmern vermieden werden. Wie jeder andere Teilnehmer ist der Mediensender jedoch verpflichtet, das Tupel zu ändern und eine entsprechende TMMBN zu senden, wenn er sich geänderter Einschränkungen bewusst wird.

Diskussion

Aufgrund der unzuverlässigen Natur der Übertragung von TMMBR und TMMBN können die obigen Regeln zum Senden von TMMBR-Nachrichten führen, die diese Regeln scheinbar verletzen. Darüber hinaus kann es in Multicast-Szenarien vorkommen, dass mehr als ein "nicht-besitzender" Sitzungsteilnehmer richtig oder falsch feststellt, dass sein Tupel zur begrenzenden Menge gehört. Dies ist aus mehreren Gründen nicht kritisch:

a) Wenn eine TMMBR-Nachricht bei der Übertragung verloren geht, sendet der Mediensender entweder eine neue TMMBN-Nachricht als Antwort auf einen anderen Medienempfänger oder er sendet überhaupt keine neue TMMBN-Nachricht. Im ersten Fall wendet der Medienempfänger den inkrementellen Algorithmus an und sendet, wenn er feststellt, dass sein Tupel Teil der begrenzenden Menge sein sollte, eine weitere TMMBR aus. Im zweiten Fall wiederholt er bedingungslos das Senden einer TMMBR. In beiden Fällen erhält der Mediensender schließlich die benötigten Informationen.

b) Wenn eine TMMBN-Nachricht verloren geht, empfängt der Medienempfänger, der die entsprechende TMMBR gesendet hat, die Benachrichtigung nicht und wird voraussichtlich die Anfrage erneut senden und die Übertragung einer weiteren TMMBN auslösen.

c) Wenn mehrere konkurrierende TMMBR-Nachrichten von verschiedenen Sitzungsteilnehmern gesendet werden, kann der Algorithmus unter Berücksichtigung all dieser Nachrichten angewendet werden, und die resultierende TMMBN bietet den Teilnehmern eine aktualisierte Ansicht darüber, wie ihre Tupel mit der begrenzten Menge verglichen werden.

d) Wenn mehr als ein Sitzungsteilnehmer zufällig gleichzeitig TMMBR-Nachrichten mit denselben Tupel-Komponentenwerten sendet, spielt es keine Rolle, welches dieser Tupel in die begrenzende Menge aufgenommen wird. Der verlierende Sitzungsteilnehmer wird nach Anwendung des Algorithmus feststellen, dass sein Tupel nicht in die begrenzende Menge eintritt, und wird daher aufhören, seine TMMBR zu senden.

Es ist wichtig, die mit gefälschten TMMBRs verbundenen Sicherheitsrisiken zu berücksichtigen. Siehe die Sicherheitsüberlegungen in Abschnitt 6.

Wie bereits erwähnt, können die Feedback-Nachrichten sowohl in Multicast- als auch in Unicast-Sitzungen in jeder der spezifizierten Topologien verwendet werden. Für Sitzungen mit einer großen Anzahl von Teilnehmern ist die Verwendung des kleinsten gemeinsamen Nenners, wie von diesem Mechanismus gefordert, jedoch möglicherweise nicht die am besten geeignete Vorgehensweise. Große Sitzungen müssen möglicherweise andere Wege in Betracht ziehen, um die Bitrate an die Fähigkeiten der Teilnehmer anzupassen, wie z. B. die Aufteilung der Sitzung in verschiedene Qualitätsstufen oder die Verwendung einer anderen Methode zur Erzielung von Bitratenskalierbarkeit.

4.2.1.3. Zeitsteuerungsregeln

Die erste Übertragung der TMMBR-Nachricht DARF in Fällen, in denen Rechtzeitigkeit wünschenswert ist, frühes oder sofortiges Feedback verwenden. Jede Wiederholung einer Anforderungsnachricht SOLLTE für das Übertragungstiming den regulären RTCP-Modus verwenden.

4.2.1.4. Behandlung in Translatoren und Mixern

Mediatranslatoren und Mixer müssen TMMBR-Nachrichten empfangen und darauf reagieren, da sie Teil der Kette sind, die einem Empfänger einen bestimmten Medienstrom bereitstellt. Der Mixer oder Translator kann lokal auf die TMMBR reagieren und somit eine TMMBN generieren, um anzuzeigen, dass er dies getan hat. Alternativ kann er im Fall eines Mediatranslators die Anfrage weiterleiten oder im Fall eines Mixers eine eigene generieren und weiterleiten. Im letzteren Fall muss der Mixer eine TMMBN an den ursprünglichen Anforderer zurücksenden, um anzuzeigen, dass er die Anfrage bearbeitet.

4.2.2. Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

Die Temporary Maximum Media Stream Bit Rate Notification wird durch RTCP-Pakettyp-Wert PT=RTPFB und FMT=4 identifiziert.

Das FCI-Feld der TMMBN-Feedback-Nachricht kann null, einen oder mehrere TMMBN-FCI-Einträge enthalten.

4.2.2.1. Nachrichtenformat

Die Feedback Control Information (FCI) besteht aus null, einem oder mehreren TMMBN-FCI-Einträgen mit der folgenden Syntax:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 3 - Syntax eines FCI-Eintrags in der TMMBN-Nachricht

• SSRC (32 Bits): Der SSRC-Wert des "Eigentümers" dieses Tupels.

• MxTBR Exp (6 Bits): Die exponentielle Skalierung der Mantisse für den maximalen Gesamtmedienbitraten-Wert. Der Wert ist eine vorzeichenlose Ganzzahl [0..63].

• MxTBR Mantissa (17 Bits): Die Mantisse des maximalen Gesamtmedienbitraten-Werts als vorzeichenlose Ganzzahl.

• Measured Overhead (9 Bits): Der gemessene durchschnittliche Paket-Overhead-Wert in Bytes, dargestellt als vorzeichenlose Ganzzahl [0..511].

Somit enthält die FCI innerhalb der TMMBN-Nachricht Einträge, die die begrenzenden Tupel anzeigen. Für jedes Tupel gibt der Eintrag den Eigentümer durch die SSRC an, gefolgt von der anwendbaren maximalen Gesamtmedienbitrate und dem Overhead-Wert.

Die Länge der TMMBN-Nachricht MUSS auf 2+2*N gesetzt werden, wobei N die Anzahl der TMMBN-FCI-Einträge ist.

4.2.2.2. Semantik

Diese Feedback-Nachricht wird verwendet, um die Absender jeder TMMBR-Nachricht zu benachrichtigen, dass eine oder mehrere TMMBR-Nachrichten empfangen wurden oder dass ein Eigentümer die Sitzung verlassen hat. Sie zeigt allen Teilnehmern die aktuelle Menge begrenzender Tupel und die "Eigentümer" dieser Tupel an.

Innerhalb des allgemeinen Paketheaders für Feedback-Nachrichten (wie in Abschnitt 6.1 von [RFC4585] definiert) gibt das Feld "SSRC of packet sender" die Quelle der Benachrichtigung an. Die "SSRC of media source" wird nicht verwendet und MUSS auf 0 gesetzt werden.

Eine TMMBN-Nachricht MUSS zur Übertragung geplant werden, nachdem eine TMMBR-Nachricht mit einem FCI-Eintrag empfangen wurde, der diesen Mediensender identifiziert. Nur eine einzige TMMBN MUSS gesendet werden, auch wenn zwischen der Planung der Übertragung und der tatsächlichen Übertragung der TMMBN-Nachricht mehr als eine TMMBR-Nachricht empfangen wird. Die TMMBN-Nachricht zeigt die begrenzenden Tupel und ihre Eigentümer zum Zeitpunkt der Übertragung der Nachricht an. Die enthaltenen begrenzenden Tupel MÜSSEN die Menge sein, die durch Anwendung des anwendbaren Algorithmus aus Abschnitt 3.5.4.2 oder eines Äquivalents auf die vorherige begrenzende Menge, falls vorhanden, und auf Tupel, die seit der letzten Übertragung von TMMBN in TMMBR-Nachrichten empfangen wurden, erreicht wurde.

Der Empfang einer TMMBR-Nachricht MUSS immer noch zur Übertragung einer TMMBN-Nachricht führen, selbst wenn nach Anwendung des Algorithmus das neu gemeldete TMMBR-Tupel nicht in die begrenzende Menge aufgenommen wird. In einem solchen Fall werden die begrenzenden Tupel und ihre Eigentümer nicht geändert, es sei denn, die TMMBR stammte von einem Eigentümer eines Tupels innerhalb der zuvor berechneten begrenzenden Menge. Dieses Verfahren ermöglicht es Sitzungsteilnehmern, die die letzte TMMBN-Nachricht nicht gesehen haben, eine korrekte Ansicht des Zustands dieses Mediensenders zu erhalten.

Wie in Abschnitt 4.2.1.2 angegeben, wenn ein Mediensender feststellt, dass ein "Eigentümer" eines begrenzenden Tupels die Sitzung verlassen hat, wird dieses Tupel aus der begrenzenden Menge entfernt, und der Mediensender MUSS eine TMMBN-Nachricht senden, die die verbleibenden begrenzenden Tupel anzeigt. Wenn keine verbleibenden begrenzenden Tupel vorhanden sind, MUSS eine TMMBN ohne FCI gesendet werden, um dies anzuzeigen. Ohne verbleibendes begrenzendes Tupel gelten die in der Sitzungssignalisierung ausgehandelten maximale Medienbitrate und maximale Paketrate, falls vorhanden.

Hinweis: Wenn noch Medienempfänger in der Sitzung verbleiben, wird dies eine vorübergehende Situation sein. Die leere TMMBN wird dazu führen, dass jeder verbleibende Medienempfänger feststellt, dass seine Einschränkung zur begrenzenden Menge gehört, und folglich eine TMMBR sendet.

In Unicast-Szenarien (d. h., wenn ein einzelner Sender mit einem einzelnen Empfänger spricht) degeneriert der oben genannte Algorithmus zur Bestimmung des Eigentums dahin, dass der Medienempfänger zum "Eigentümer" des einen begrenzenden Tupels wird, sobald der Medienempfänger die erste TMMBR-Nachricht ausgegeben hat.

4.2.2.3. Zeitsteuerungsregeln

Die TMMBN-Bestätigung SOLLTE so bald wie möglich gemäß den für die Sitzung angewendeten Timing-Regeln gesendet werden. Für diese Nachrichten SOLLTE der sofortige oder frühe Feedback-Modus verwendet werden.

4.2.2.4. Behandlung durch Translatoren und Mixer

Wie in Abschnitt 4.2.1.4 diskutiert, müssen Mixer oder Translatoren möglicherweise TMMBN-Nachrichten als Antworten auf TMMBR-Nachrichten für von ihnen behandelte SSRCs ausgeben.

4.3. Payload-spezifische Feedback-Nachrichten

Wie in Abschnitt 6.1 von RFC 4585 [RFC4585] spezifiziert, werden Payload-Specific FB-Nachrichten durch den RTCP-Pakettyp-Wert PSFB (206) identifiziert. AVPF [RFC4585] definiert drei payload-spezifische Feedback-Nachrichten und eine Anwendungsschicht-Feedback-Nachricht. Diese Spezifikation definiert vier zusätzliche payload-spezifische Feedback-Nachrichten. Alle werden mittels des FMT-Parameters wie folgt identifiziert:

Zugewiesen in [RFC4585]:

• 1: Picture Loss Indication (PLI)
• 2: Slice Lost Indication (SLI)
• 3: Reference Picture Selection Indication (RPSI)
• 15: Application layer FB message
• 31: reserviert für zukünftige Erweiterung des Nummernraums

Zugewiesen in dieser Spezifikation:

• 4: Full Intra Request (FIR) Command
• 5: Temporal-Spatial Trade-off Request (TSTR)
• 6: Temporal-Spatial Trade-off Notification (TSTN)
• 7: Video Back Channel Message (VBCM)

Nicht zugewiesen:

• 0: nicht zugewiesen
• 8-14: nicht zugewiesen
• 16-30: nicht zugewiesen

Die folgenden Unterabschnitte definieren die neuen FCI-Formate für die payload-spezifischen Feedback-Nachrichten.

4.3.1. Full Intra Request (FIR)

Die FIR-Nachricht wird durch RTCP-Pakettyp-Wert PT=PSFB und FMT=4 identifiziert.

Das FCI-Feld MUSS einen oder mehrere FIR-Einträge enthalten. Jeder Eintrag gilt für einen anderen Mediensender, der durch seine SSRC identifiziert wird.

4.3.1.1. Nachrichtenformat

Die Feedback Control Information (FCI) für die Full Intra Request besteht aus einem oder mehreren FCI-Einträgen, deren Inhalt in Abbildung 4 dargestellt ist. Die Länge der FIR-Feedback-Nachricht MUSS auf 2+2*N gesetzt werden, wobei N die Anzahl der FCI-Einträge ist.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |    Reserved                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 4 - Syntax eines FCI-Eintrags in der FIR-Nachricht

• SSRC (32 Bits): Der SSRC-Wert des Mediensenders, der aufgefordert wird, einen Decoder-Refresh-Punkt zu senden.

• Seq nr. (8 Bits): Befehlssequenznummer. Der Sequenznummernraum ist für jede Paarung der SSRC der Befehlsquelle und der SSRC des Befehlsziels eindeutig. Die Sequenznummer MUSS für jeden neuen Befehl um 1 modulo 256 erhöht werden. Eine Wiederholung DARF die Sequenznummer NICHT erhöhen. Der Anfangswert ist beliebig.

• Reserved (24 Bits): Alle Bits MÜSSEN vom Sender auf 0 gesetzt werden und MÜSSEN beim Empfang ignoriert werden.

Die Semantik dieser Feedback-Nachricht ist unabhängig vom RTP-Payload-Typ.

4.3.1.2. Semantik

Innerhalb des allgemeinen Paketheaders für Feedback-Nachrichten (wie in Abschnitt 6.1 von [RFC4585] definiert) gibt das Feld "SSRC of packet sender" die Quelle der Anfrage an, und die "SSRC of media source" wird nicht verwendet und MUSS auf 0 gesetzt werden. Die SSRCs der Mediensender, für die der FIR-Befehl gilt, befinden sich in den entsprechenden FCI-Einträgen. Eine FIR-Nachricht DARF Anfragen an mehrere Mediensender enthalten, wobei ein FCI-Eintrag pro Ziel-Mediensender verwendet wird.

Nach Erhalt von FIR MUSS der Encoder so schnell wie möglich einen Decoder-Refresh-Punkt senden (siehe Abschnitt 2.2).

Der Sender MUSS die Überlastungskontrolle gemäß Abschnitt 5 berücksichtigen, was seine Fähigkeit einschränken KANN, schnell einen Decoder-Refresh-Punkt zu senden.

FIR DARF NICHT als Reaktion auf Bildverluste gesendet werden -- es wird EMPFOHLEN, stattdessen PLI [RFC4585] zu verwenden. FIR SOLLTE nur in Situationen verwendet werden, in denen das Nicht-Senden eines Decoder-Refresh-Punkts das Video für die Benutzer unbrauchbar machen würde.

Ein typisches Beispiel, bei dem das Senden von FIR angemessen ist, ist, wenn in einer Mehrpunktkonferenz ein neuer Benutzer der Sitzung beitritt und kein reguläres Decoder-Refresh-Punkt-Intervall festgelegt ist. Ein weiteres Beispiel wäre eine Video-Switching-MCU, die Streams wechselt. Hier gibt die MCU normalerweise eine FIR an den neuen Sender aus, um ihn zu zwingen, einen Decoder-Refresh-Punkt auszusenden. Der Decoder-Refresh-Punkt enthält normalerweise eine Freeze Picture Release (außerhalb dieser Spezifikation definiert), die den Rendering-Prozess der Empfänger neu startet. Beide erwähnten Techniken werden häufig in MCU-basierten Mehrpunktkonferenzen verwendet.

Andere RTP-Payload-Spezifikationen wie RFC 2032 [RFC2032] definieren bereits einen Feedback-Mechanismus für bestimmte Codecs. Eine Anwendung, die beide Schemata unterstützt, MUSS beim Senden von Feedback den in dieser Spezifikation definierten Feedback-Mechanismus verwenden. Aus Gründen der Abwärtskompatibilität SOLLTE eine solche Anwendung auch in der Lage sein, das im jeweiligen RTP-Payload-Format definierte Feedback-Schema zu empfangen und darauf zu reagieren, wenn dies von diesem Payload-Format gefordert wird.

4.3.1.3. Zeitsteuerungsregeln

Das Timing folgt den in Abschnitt 3 von [RFC4585] beschriebenen Regeln. FIR-Befehle DÜRFEN mit frühem oder sofortigem Feedback verwendet werden. Die FIR-Feedback-Nachricht DARF wiederholt werden. Bei Verwendung des sofortigen Feedback-Modus SOLLTE die Wiederholung mindestens eine RTT warten, bevor sie gesendet wird. Im frühen oder regulären RTCP-Modus wird die Wiederholung im nächsten regulären RTCP-Paket gesendet.

4.3.1.4. Behandlung von FIR-Nachrichten in Mixern und Translatoren

Ein Mediatranslator oder ein Mixer, der die Mediencodierung des Inhalts durchführt, für den der Sitzungsteilnehmer eine FIR ausgegeben hat, ist dafür verantwortlich, darauf zu reagieren. Ein Mixer, der auf eine FIR reagiert, SOLLTE die Nachricht NICHT unverändert weiterleiten; stattdessen SOLLTE er selbst eine FIR ausgeben.

4.3.1.5. Anmerkungen

Derzeit scheint Video die einzige nützliche Anwendung für FIR zu sein, da es die einzige weit verbreitete RTP-Payload zu sein scheint, die stark auf Medienvorhersage über RTP-Paketgrenzen hinweg angewiesen ist. Die Verwendung von FIR könnte jedoch auch vernünftigerweise für andere Medientypen in Betracht gezogen werden, die wesentliche Eigenschaften mit komprimiertem Video teilen, nämlich Frame-übergreifende Vorhersage (was auch immer ein Frame für diesen Medientyp sein mag). Ein mögliches Beispiel könnten die dynamischen Updates von MPEG-4-Szenenbeschreibungen sein. Es wird vorgeschlagen, dass Payload-Formate für solche Medientypen auf FIR und andere in dieser Spezifikation und in AVPF [RFC4585] definierte Nachrichtentypen verweisen, anstatt ähnliche Mechanismen in den Payload-Spezifikationen zu erstellen. Die Payload-Spezifikationen müssen möglicherweise erklären, wie die payload-spezifischen Terminologien auf die hier verwendete videozentrische Terminologie abgebildet werden.

In Verbindung mit Video-Codecs lösen FIR-Nachrichten typischerweise das Senden vollständiger Intra- oder IDR-Bilder aus. Beide sind mehrere Male größer als vorhergesagte (Inter-)Bilder. Ihre Größe ist unabhängig vom Zeitpunkt ihrer Generierung. In den meisten Umgebungen, insbesondere bei Verwendung bandbreitenbegrenzter Verbindungen, impliziert die Verwendung eines Intra-Bildes eine zulässige Verzögerung, die ein signifikantes Vielfaches der typischen Frame-Dauer beträgt. Ein Beispiel: Wenn die Sende-Frame-Rate 10 fps beträgt und angenommen wird, dass ein Intra-Bild 10-mal so groß ist wie ein Inter-Bild, muss eine volle Sekunde Latenz akzeptiert werden. In einer solchen Umgebung besteht keine Notwendigkeit für eine besonders kurze Verzögerung beim Senden der FIR-Nachricht. Daher sollte das Warten auf den nächstmöglichen Zeitpunkt, der durch RTCP-Timing-Regeln gemäß [RFC4585] zugelassen wird, keine übermäßig negativen Auswirkungen auf die Systemleistung haben.

Das Vorschreiben einer maximalen Verzögerung für den Abschluss des Sendens eines Decoder-Refresh-Punkts wäre aus Anwendungssicht wünschenswert, ist jedoch aus Sicht der Überlastungskontrolle problematisch. "So schnell wie möglich", wie oben erwähnt, scheint ein vernünftiger Kompromiss zu sein.

In Umgebungen, in denen der Sender keine Kontrolle über den Codec hat (z. B. beim Streaming vorab aufgezeichneter und vorab codierter Inhalte), kann die Reaktion auf diesen Befehl nicht spezifiziert werden. Eine geeignete Reaktion eines Senders wäre, im Videobitstream zum nächsten Decoder-Refresh-Punkt vorzuspringen. In anderen Szenarien kann es vorzuziehen sein, überhaupt nicht auf den Befehl zu reagieren, z. B. beim Streaming an eine große Multicast-Gruppe. Andere Reaktionen können ebenfalls möglich sein. Bei der Entscheidung über eine Strategie könnte ein Sender Faktoren wie die Größe der Empfängergruppe, die "Wichtigkeit" des Senders der FIR-Nachricht (wie auch immer "Wichtigkeit" in dieser spezifischen Anwendung definiert sein mag), die Häufigkeit von Decoder-Refresh-Punkten im Inhalt usw. berücksichtigen. Es wird jedoch nicht erwartet, dass eine Sitzung, die überwiegend vorab codierte Inhalte behandelt, FIR überhaupt verwendet.

Die Beziehung zwischen Picture Loss Indication und FIR ist wie folgt. Wie in Abschnitt 6.3.1 von AVPF [RFC4585] diskutiert, informiert eine Picture Loss Indication den Decoder über den Verlust eines Bildes und somit die Wahrscheinlichkeit einer Fehlanpassung der Referenzbilder zwischen Encoder und Decoder. Ein solches Szenario ist normalerweise mit Verlusten in einer laufenden Verbindung verbunden. In Punkt-zu-Punkt-Szenarien und ohne das Vorhandensein fortgeschrittener Fehlerresilienz-Tools besteht eine mögliche Option für einen Encoder darin, einen Decoder-Refresh-Punkt zu senden. Es gibt jedoch andere Optionen. Ein Beispiel ist, dass der Mediensender die PLI ignoriert, weil die eingebettete Stream-Redundanz wahrscheinlich das wiedergegebene Bild innerhalb einer angemessenen Zeit bereinigt. Die FIR hingegen lässt einem (Echtzeit-)Encoder keine andere Wahl, als einen Decoder-Refresh-Punkt zu senden. Sie ermöglicht es dem Encoder nicht, Überlegungen wie die oben erwähnten zu berücksichtigen.

4.3.2. Temporal-Spatial Trade-off Request (TSTR)

Die TSTR-Feedback-Nachricht wird durch RTCP-Pakettyp-Wert PT=PSFB und FMT=5 identifiziert.

Das FCI-Feld MUSS einen oder mehrere TSTR-FCI-Einträge enthalten.

4.3.2.1. Nachrichtenformat

Der Inhalt des FCI-Eintrags für die Temporal-Spatial Trade-off Request ist in Abbildung 5 dargestellt. Die Länge der Feedback-Nachricht MUSS auf 2+2*N gesetzt werden, wobei N die Anzahl der enthaltenen FCI-Einträge ist.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 5 - Syntax eines FCI-Eintrags in der TSTR-Nachricht

• SSRC (32 Bits): Die SSRC des Mediensenders, der aufgefordert wird, den in Index angegebenen Trade-off-Wert anzuwenden.

• Seq nr. (8 Bits): Anforderungssequenznummer. Der Sequenznummernraum ist für die Paarung der SSRC der Anforderungsquelle und der SSRC des Anforderungsziels eindeutig. Die Sequenznummer MUSS für jeden neuen Befehl um 1 modulo 256 erhöht werden. Eine Wiederholung DARF die Sequenznummer NICHT erhöhen. Der Anfangswert ist beliebig.

• Reserved (19 Bits): Alle Bits MÜSSEN vom Sender auf 0 gesetzt werden und MÜSSEN beim Empfang ignoriert werden.

• Index (5 Bits): Ein ganzzahliger Wert zwischen 0 und 31, der den relativen Trade-off angibt, der angefordert wird. Ein Indexwert von 0 gibt die höchstmögliche räumliche Qualität an, während 31 die höchstmögliche zeitliche Auflösung angibt.

4.3.2.2. Semantik

Ein Decoder kann ein temporales-räumliches Trade-off-Level vorschlagen, indem er eine TSTR-Nachricht an einen Encoder sendet. Wenn der Encoder in der Lage ist, seinen temporalen-räumlichen Trade-off anzupassen, SOLLTE er die empfangene TSTR-Nachricht für die zukünftige Codierung von Bildern berücksichtigen. Ein Wert von 0 legt eine hohe räumliche Qualität nahe, und ein Wert von 31 legt eine hohe Bildrate nahe. Der Fortschritt der Werte von 0 bis 31 zeigt monoton den Wunsch nach einer höheren Bildrate an. Die Indexwerte entsprechen nicht präzisen Werten für räumliche Qualität oder Bildrate.

Die Reaktion auf den Empfang von mehr als einer TSTR-Nachricht durch einen Mediensender von verschiedenen Medienempfängern bleibt der Implementierung überlassen. Der ausgewählte Trade-off MUSS den Medienempfängern mittels der TSTN-Nachricht mitgeteilt werden.

Innerhalb des allgemeinen Paketheaders für Feedback-Nachrichten (wie in Abschnitt 6.1 von [RFC4585] definiert) gibt das Feld "SSRC of packet sender" die Quelle der Anfrage an, und die "SSRC of media source" wird nicht verwendet und MUSS auf 0 gesetzt werden. Die SSRCs der Mediensender, für die die TSTR gilt, befinden sich in den entsprechenden FCI-Einträgen.

Eine TSTR-Nachricht DARF Anfragen an mehrere Mediensender enthalten, wobei ein FCI-Eintrag pro Ziel-Mediensender verwendet wird.

4.3.2.3. Zeitsteuerungsregeln

Das Timing folgt den in Abschnitt 3 von [RFC4585] beschriebenen Regeln. Diese Anforderungsnachricht ist nicht zeitkritisch und SOLLTE mit regulärem RTCP-Timing gesendet werden. Nur wenn bekannt ist, dass die Benutzeroberfläche schnelles Feedback erfordert, DARF die Nachricht mit frühem oder sofortigem Feedback-Timing gesendet werden.

4.3.2.4. Behandlung der Nachricht in Mixern und Translatoren

Ein Mixer oder Mediatranslator, der Inhalte codiert, die an den Sitzungsteilnehmer gesendet werden, der die TSTR ausgibt, MUSS die Anfrage berücksichtigen, um zu bestimmen, ob er sie durch Änderung seiner eigenen Codierungsparameter erfüllen kann. Ein Mediatranslator, der die Anfrage nicht erfüllen kann, DARF die Anfrage unverändert zum Mediensender weiterleiten. Ein Mixer, der für mehrere Sitzungsteilnehmer codiert, muss die gemeinsamen Bedürfnisse dieser Teilnehmer berücksichtigen, bevor er in eigenem Namen eine TSTR zum Mediensender generiert. Siehe auch die Diskussion in Abschnitt 3.5.2.

4.3.2.5. Anmerkungen

Der Begriff "räumliche Qualität" bezieht sich nicht notwendigerweise auf die Auflösung, gemessen an der Anzahl der Pixel, die das rekonstruierte Video verwendet. Tatsächlich bleibt in den meisten Szenarien die Videoauflösung während der Lebensdauer einer Sitzung konstant. Alle Videokompressionsstandards haben jedoch Mittel, um die räumliche Qualität bei einer gegebenen Auflösung anzupassen, oft beeinflusst durch den Quantizer Parameter oder QP. Ein numerisch niedriger QP führt zu einer guten rekonstruierten Bildqualität, während ein numerisch hoher QP ein grobes Bild ergibt. Die typische Reaktion eines Encoders auf diese Anfrage besteht darin, seine Ratensteuerungsparameter zu ändern, um eine niedrigere Bildrate und einen numerisch niedrigeren (im Durchschnitt) QP zu verwenden, oder umgekehrt. Die präzise Zuordnung des Indexwerts zu Bildrate und QP wird hier absichtlich offen gelassen, da sie von Faktoren wie dem verwendeten Kompressionsstandard, der räumlichen Auflösung, dem Inhalt, der Bitrate usw. abhängt.

4.3.3. Temporal-Spatial Trade-off Notification (TSTN)

Die TSTN-Nachricht wird durch RTCP-Pakettyp-Wert PT=PSFB und FMT=6 identifiziert.

Das FCI-Feld MUSS einen oder mehrere TSTN-FCI-Einträge enthalten.

4.3.3.1. Nachrichtenformat

Der Inhalt eines FCI-Eintrags für die Temporal-Spatial Trade-off Notification ist in Abbildung 6 dargestellt. Die Länge der TSTN-Nachricht MUSS auf 2+2*N gesetzt werden, wobei N die Anzahl der FCI-Einträge ist.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 6 - Syntax der TSTN

• SSRC (32 Bits): Die SSRC der Quelle der TSTR, die zu dieser Benachrichtigung führte.

• Seq nr. (8 Bits): Der Sequenznummernwert aus der TSTR, die bestätigt wird.

• Reserved (19 Bits): Alle Bits MÜSSEN vom Sender auf 0 gesetzt werden und MÜSSEN beim Empfang ignoriert werden.

• Index (5 Bits): Der Trade-off-Wert, den der Mediensender fortan verwendet.

Informativer Hinweis: Der zurückgegebene Trade-off-Wert (Index) kann vom angeforderten abweichen, beispielsweise in Fällen, in denen ein Medienencoder seinen Trade-off nicht anpassen kann oder wenn vorab aufgezeichnete Inhalte verwendet werden.

4.3.3.2. Semantik

Diese Feedback-Nachricht wird verwendet, um den Empfang einer TSTR zu bestätigen. Für jede empfangene TSTR, die an den Sitzungsteilnehmer gerichtet ist, MUSS ein TSTN-FCI-Eintrag in einer TSTN-Feedback-Nachricht gesendet werden. Eine einzelne TSTN-Nachricht DARF mehrere Anfragen unter Verwendung mehrerer FCI-Einträge bestätigen. Der enthaltene Indexwert MUSS in allen FCI-Einträgen der TSTN-Nachricht derselbe sein. Das Einbeziehen einer FCI für jeden Anforderer ermöglicht es jeder anfordernden Entität festzustellen, dass der Mediensender die Anfrage empfangen hat. Die Benachrichtigung MUSS auch als Antwort auf empfangene TSTR-Wiederholungen gesendet werden. Wenn der Anforderungsempfänger TSTR mit mehreren verschiedenen Sequenznummern von einem einzelnen Anforderer empfangen hat, MUSS er nur auf die Anfrage mit der höchsten (modulo 256) Sequenznummer antworten. Beachten Sie, dass die höchste Sequenznummer aufgrund des Umbruchs des Feldes ein kleinerer ganzzahliger Wert sein kann. Anhang A.1 von [RFC3550] enthält einen Algorithmus zur Verfolgung der höchsten empfangenen Sequenznummer für RTP-Pakete; er könnte für diese Verwendung angepasst werden.

Die TSTN MUSS den Temporal-Spatial Trade-off-Index enthalten, der als Ergebnis der Anfrage verwendet wird. Dies ist nicht notwendigerweise derselbe Index wie angefordert, da der Mediensender möglicherweise Anfragen von mehreren anfordernden Sitzungsteilnehmern aggregieren muss. Er kann auch einige andere Richtlinien oder Regeln haben, die die Auswahl einschränken.

Innerhalb des allgemeinen Paketheaders für Feedback-Nachrichten (wie in Abschnitt 6.1 von [RFC4585] definiert) gibt das Feld "SSRC of packet sender" die Quelle der Benachrichtigung an, und die "SSRC of media source" wird nicht verwendet und MUSS auf 0 gesetzt werden. Die SSRCs der anfordernden Entitäten, für die die Benachrichtigung gilt, befinden sich in den entsprechenden FCI-Einträgen.

4.3.3.3. Zeitsteuerungsregeln

Das Timing folgt den in Abschnitt 3 von [RFC4585] beschriebenen Regeln. Diese Bestätigungsnachricht ist nicht extrem zeitkritisch und SOLLTE mit regulärem RTCP-Timing gesendet werden.

4.3.3.4. Behandlung von TSTN in Mixern und Translatoren

Ein Mixer oder Translator, der auf eine TSTR reagiert, MUSS auch die entsprechende TSTN senden. In Fällen, in denen er selbst eine TSTR weiterleiten muss, DARF die Benachrichtigungsnachricht verzögert werden, bis auf die TSTR geantwortet wurde.

4.3.3.5. Anmerkungen

Keine.

4.3.4. H.271 Video Back Channel Message (VBCM)

Die VBCM wird durch RTCP-Pakettyp-Wert PT=PSFB und FMT=7 identifiziert.

Das FCI-Feld MUSS einen oder mehrere VBCM-FCI-Einträge enthalten.

4.3.4.1. Nachrichtenformat

Die Syntax eines FCI-Eintrags innerhalb der VBCM-Anzeige ist in Abbildung 7 dargestellt.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |0| Payload Type| Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    VBCM Octet String....      |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 7 - Syntax eines FCI-Eintrags in der VBCM

• SSRC (32 Bits): Der SSRC-Wert des Mediensenders, der aufgefordert wird, seinen Encoder anzuweisen, auf die VBCM zu reagieren.

• Seq nr. (8 Bits): Befehlssequenznummer. Der Sequenznummernraum ist für die Paarung der SSRC der Befehlsquelle und der SSRC des Befehlsziels eindeutig. Die Sequenznummer MUSS für jeden neuen Befehl um 1 modulo 256 erhöht werden. Eine Wiederholung DARF die Sequenznummer NICHT erhöhen. Der Anfangswert ist beliebig.

• 0: Muss vom Sender auf 0 gesetzt werden und sollte vom Nachrichtenempfänger nicht beachtet werden.

• Payload Type (7 Bits): Der RTP-Payload-Typ, für den der VBCM-Bitstrom interpretiert werden muss.

• Length (16 Bits): Die Länge der VBCM-Oktetzeichenfolge in Oktetten ohne Padding-Oktette.

• VBCM Octet String (variable Länge): Dies ist die vom Decoder generierte Oktetzeichenfolge, die eine spezifische Feedback-Unternachricht trägt.

• Padding (variable Länge): Auf 0 gesetzte Bits, um eine 32-Bit-Grenze zu bilden.

4.3.4.2. Semantik

Die "Payload" der VBCM-Anzeige trägt verschiedene Arten von codec-spezifischen Feedback-Informationen. Die Art der Feedback-Informationen kann als 'Statusbericht' (wie eine Anzeige, dass ein Bitstrom ohne Fehler empfangen wurde oder dass ein teilweises oder vollständiges Bild oder Block verloren ging) oder 'Update-Anfragen' (wie vollständige Aktualisierung des Bitstroms) klassifiziert werden.

Hinweis: Es gibt mögliche Überschneidungen zwischen den VBCM-Unternachrichten und CCM/AVPF-Feedback-Nachrichten wie FIR. Bitte siehe Abschnitt 3.5.3 für weitere Diskussion.

Die verschiedenen Arten von Feedback-Unternachrichten, die in der VBCM übertragen werden, werden durch den "payloadType" wie in [H.271] definiert angezeigt. Diese Unternachrichtentypen werden unten zur Vereinfachung wiedergegeben. "payloadType" bezieht sich in der Terminologie von ITU-T Rec. H.271 auf den Untertyp der H.271-Nachricht und sollte nicht mit einem RTP-Payload-Typ verwechselt werden.

Tabelle 2: H.271-Nachrichtentypen ("payloadTypes")

Payload Type	Message Content
0	Ein oder mehrere Bilder ohne erkannten Bitstream-Fehler oder Nichtübereinstimmung
1	Ein oder mehrere Bilder, die ganz oder teilweise verloren sind
2	Eine Menge von Blöcken eines Bildes, die ganz oder teilweise verloren sind
3	CRC für einen Parametersatz
4	CRC für alle Parametersätze eines bestimmten Typs
5	Eine "Reset"-Anfrage, die anzeigt, dass der Sender den Video-Bitstrom vollständig aktualisieren sollte, als ob keine vorherigen Bitstrom-Daten empfangen worden wären
> 5	Reserviert für zukünftige Verwendung durch ITU-T

Die Bitzeichenfolge oder die "Payload" einer VBCM ist von variabler Länge und ist eigenständig und in einem binären Format variabler Länge codiert. Der Mediensender muss notwendigerweise in der Lage sein, dieses optimierte Binärformat zu parsen, um VBCMs zu nutzen.

Jeder der verschiedenen Typen von Unternachrichten (angezeigt durch payloadType) kann je nach verwendetem Codec unterschiedliche Semantiken haben.

Innerhalb des allgemeinen Paketheaders für Feedback-Nachrichten (wie in Abschnitt 6.1 von [RFC4585] definiert) gibt das Feld "SSRC of packet sender" die Quelle der Anfrage an, und die "SSRC of media source" wird nicht verwendet und MUSS auf 0 gesetzt werden. Die SSRCs der Mediensender, für die die VBCM gilt, befinden sich in den entsprechenden FCI-Einträgen. Der Sender der VBCM DARF H.271-Nachrichten an mehrere Mediensender senden und DARF mehr als eine H.271-Nachricht an denselben Mediensender innerhalb derselben VBCM senden.

4.3.4.3. Zeitsteuerungsregeln

Das Timing folgt den in Abschnitt 3 von [RFC4585] beschriebenen Regeln. Die verschiedenen Unternachrichtentypen können unterschiedliche Eigenschaften in Bezug auf das Timing von Nachrichten haben, das verwendet werden sollte. Wenn mehrere verschiedene Typen in dasselbe Feedback-Paket aufgenommen werden, sollten die Anforderungen für den Unternachrichtentyp mit den strengsten Anforderungen befolgt werden.

4.3.4.4. Behandlung der Nachricht in Mixern oder Translatoren

Die Behandlung einer VBCM in einem Mixer oder Translator ist unternachrichtentypabhängig.

4.3.4.5. Anmerkungen

Bitte siehe Abschnitt 3.5.3 für eine Diskussion der Verwendung von H.271-Nachrichten und Nachrichten, die in AVPF [RFC4585] und dieser Spezifikation definiert sind, mit ähnlicher Funktionalität.

Hinweis: Es gab einige Diskussionen darüber, ob das RTP-Payload-Typ-Feld in dieser Nachricht benötigt wird. Es wird benötigt, wenn potenziell mehr als ein VBCM-fähiger RTP-Payload-Typ in derselben Sitzung vorhanden ist und sich die Semantik einer gegebenen VBCM zwischen Payload-Typen ändert. Beispielsweise ist der Bildidentifikationsmechanismus in Nachrichten vom H.271-Typ 0 grundlegend unterschiedlich zwischen H.263 und H.264 (obwohl beide dieselbe Syntax verwenden). Daher ist das Payload-Feld hier gerechtfertigt. Es gab einen weiteren Kommentar, dass für TSTR und FIR ein solcher Bedarf nicht besteht, da die Semantik von TSTR und FIR entweder locker genug definiert oder generisch genug ist, um auf alle derzeit existierenden/vorstellbaren Video-Payloads zu passen.