3. Motivation

Dieser Abschnitt diskutiert die Motivation und Verwendung der verschiedenen Video- und Medienkontrollnachrichten. Die Videokontrollnachrichten wurden lange diskutiert, und ein Anforderungsdokument wurde erstellt [Basso]. Dieses Dokument ist abgelaufen, jedoch zitieren wir relevante Abschnitte davon, um Motivation und Anforderungen zu liefern.

3.1. Anwendungsfälle

Es gibt eine Reihe möglicher Verwendungen für die vorgeschlagenen Feedback-Nachrichten. Beginnen wir mit einem Blick auf die Anwendungsfälle, die Basso et al. [Basso] vorgeschlagen haben. Einige der Anwendungsfälle wurden umformuliert und Kommentare wurden hinzugefügt.

1. Ein RTP-Videomixer komponiert mehrere kodierte Videoquellen in einen einzigen kodierten Videostream. Jedes Mal, wenn eine Videoquelle hinzugefügt wird, muss der RTP-Mixer einen Decoder Refresh Point von der Videoquelle anfordern, um eine unverfälschte Vorhersagekette auf dem räumlichen Bereich des gemischten Bildes zu starten, der von den Daten der neuen Videoquelle belegt wird.

2. Ein RTP-Videomixer empfängt mehrere kodierte RTP-Videostreams von Konferenzteilnehmern und wählt dynamisch einen der Streams aus, der in seinen Ausgabe-RTP-Stream aufgenommen werden soll. Zum Zeitpunkt einer Bitstrom-Änderung (bestimmt durch Mittel wie Sprachaktivierung oder die Benutzeroberfläche) fordert der Mixer einen Decoder Refresh Point von der entfernten Quelle an, um zu vermeiden, dass unabhängiger Inhalt als Referenzdaten für die Inter-Bildvorhersage verwendet wird. Nach der Anforderung des Decoder Refresh Points stoppt der Videomixer die Übertragung des aktuellen RTP-Streams und überwacht den RTP-Stream von der neuen Quelle, bis er Daten erkennt, die zum Decoder Refresh Point gehören. Zu diesem Zeitpunkt beginnt der RTP-Mixer, den neu ausgewählten Stream an den/die Empfänger weiterzuleiten.

3. Eine Anwendung muss dem entfernten Encoder signalisieren, dass sich der gewünschte Kompromiss zwischen zeitlicher und räumlicher Auflösung geändert hat. Zum Beispiel kann ein Benutzer eine höhere Bildrate und eine niedrigere räumliche Qualität bevorzugen, und ein anderer Benutzer kann das Gegenteil bevorzugen. Diese Wahl ist auch stark inhaltsabhängig. Viele aktuelle Videokonferenzsysteme bieten in der Benutzeroberfläche einen Mechanismus, um diese Auswahl zu treffen, normalerweise in Form eines Schiebereglers. Der Mechanismus ist hilfreich bei Punkt-zu-Punkt-, zentralisiertem Mehrpunkt- und nicht-zentralisiertem Mehrpunktbetrieb.

4. Anwendungsfall 4 des Basso-Dokuments gilt nur für Picture Loss Indication (PLI), wie in AVPF [RFC4585] definiert, und wird hier nicht reproduziert.

5. Anwendungsfall 5 des Basso-Dokuments bezieht sich auf einen Mechanismus, der als "freeze picture request" bekannt ist. Das Senden von Freeze Picture Requests über einen nicht zuverlässigen vorwärtsgerichteten RTCP-Kanal wurde als problematisch identifiziert. Daher wurde keine Freeze Picture Request in dieses Memo aufgenommen, und die Diskussion des Anwendungsfalls wird hier nicht reproduziert.

6. Ein Videomixer wählt dynamisch einen der empfangenen Videostreams aus, der an die Teilnehmer gesendet werden soll, und versucht, die höchstmögliche Bitrate an alle Teilnehmer zu liefern, während die Stream-Trans-Rating minimiert wird. Eine Möglichkeit, dies zu erreichen, besteht darin, Sitzungen mit Endpunkten unter Verwendung der von jedem Endpunkt akzeptierten maximalen Bitrate und der vom Mixer verwendeten Call-Admission-Methode einzurichten. Durch Befehle, die die maximale Medienstrom-Bitrate unter das reduzieren, was während der Sitzungseinrichtung ausgehandelt wurde, kann der Mixer die maximale Bitrate reduzieren, die von Endpunkten gesendet wird, auf die niedrigste aller akzeptierten Bitraten. Wenn sich die niedrigste akzeptierte Bitrate aufgrund von Endpunkten, die beitreten und verlassen, oder aufgrund von Netzwerküberlastung ändert, kann der Mixer die Grenzen anpassen, bei denen Endpunkte ihre Streams senden können, um dem neuen Wert zu entsprechen. Der Mixer fordert dann eine neue maximale Bitrate an, die gleich oder kleiner als die maximale Bitrate ist, die bei der Sitzungseinrichtung für einen bestimmten Medienstrom ausgehandelt wurde, und der entfernte Endpunkt kann mit der tatsächlichen Bitrate antworten, die er unterstützen kann.

Das Bild, das Basso et al. zeichnen, deckt die meisten Anwendungen ab, die wir vorhersehen. Wir möchten die Liste jedoch um zwei zusätzliche Anwendungsfälle erweitern:

7. Derzeit eingesetzte Überlastungskontrollalgorithmen (AIMD und TCP Friendly Rate Control (TFRC) [RFC3448]) sondieren nach zusätzlicher verfügbarer Kapazität, solange es etwas zu senden gibt. Bei Überlastungskontrollalgorithmen, die Paketverlust als Indikation für Überlastung verwenden, führt diese Sondierung im Allgemeinen zu reduzierter Medienqualität (oft bis zu einem Punkt, an dem die Verzerrung groß genug ist, um die Medien unbrauchbar zu machen), aufgrund von Paketverlust und erhöhter Verzögerung.

   In einer Reihe von Einsatzszenarien, insbesondere bei zellulären, ist der Engpasslink oft der Last-Hop-Link. Dieser zelluläre Link hat üblicherweise auch eine Art QoS-Verhandlung, die es dem zellulären Gerät ermöglicht, die über diesen Last Hop verfügbare maximale Bitrate zu erfahren. Ein Medienempfänger hinter diesem Link kann in den meisten (wenn nicht allen) Fällen zumindest eine Obergrenze für die für jeden Medienstrom verfügbare Bitrate berechnen, den er derzeit empfängt. Wie dies geschieht, ist ein Implementierungsdetail und wird hier nicht diskutiert. Die Angabe der maximal verfügbaren Bitrate an die sendende Partei für die verschiedenen Medienströme kann vorteilhaft sein, um zu verhindern, dass diese Partei nach Bandbreite für diesen Stream über eine bekannte harte Grenze hinaus sondiert. Für zelluläre oder andere mobile Geräte kann sich die bekannte verfügbare Bitrate für jeden Stream (abgeleitet von der Link-Bitrate) schnell ändern, aufgrund von Handover zu einer anderen Übertragungstechnologie, QoS-Neuverhandlung aufgrund von Überlastung usw. Um eine minimale Dienstunterbrechung zu ermöglichen, ist eine schnelle Konvergenz notwendig, und daher ist die Signalisierung über den Medienpfad wünschenswert.

8. Normalerweise ist es in einer Punkt-zu-Punkt-Sitzung die Verantwortung des Mediensenders, den Medienstrom so zu konfigurieren, dass er innerhalb der Grenzen der verfügbaren Pfadbandbreite bleibt. In bestimmten Punkt-zu-Punkt-Videoszenarien ist es jedoch vorteilhaft, den Empfänger die maximale Medienbitrate noch weiter einschränken zu lassen. Ein Beispiel ist die Verschlechterung der Rendering-Fähigkeit des Empfängers (z. B. aufgrund von CPU-Ressourcenmangel). In diesem Fall möchte der Empfänger dem Sender möglicherweise signalisieren, die Medienbitrate auf ein Niveau zu reduzieren, das bewältigt werden kann. Ein weiteres Beispiel ist ein Empfänger, der die Sitzung aufzeichnen möchte. In diesem Fall möchte der Empfänger möglicherweise die Medienrate begrenzen, um zuverlässige Schreibgeschwindigkeiten zum Speichergerät nicht zu überschreiten.

3.2. Verwendung des Medienpfads

Um die oben genannten Anwendungsfälle zu unterstützen, kann man den Signalisierungskanal (z. B. SIP) verwenden und die Definition der Medienströme neu verhandeln. Dies hat jedoch mehrere Nachteile.

Zum einen kann die Neuverhandlung von Parametern über den Signalisierungskanal langsam sein. Bei einigen Kontrollprotokollen (wie H.323) sind die Phasen des Abbaus eines bestehenden Kanals und der Einrichtung eines neuen Kanals unterschiedlich, und es kann eine "Lücke" in der Medienwiedergabe auftreten.

Zweitens verwendet der Kontrollkanal andere Protokolle (oft TCP) als der Medienpfad (oft UDP/RTP). In vielen Topologien unterscheidet sich der "Pfad" des Signalisierungskanals vom Pfad der Medien. Wenn eine Middlebox wie eine NAT-Firewall vorhanden ist, kann der Kontrollkanal möglicherweise nicht auf die Änderungen in den Medienpfadmerkmalen reagieren oder ist sich des Medienpfads möglicherweise nicht einmal bewusst.

Drittens ist die Verwendung des Signalisierungskanals zur Neuverhandlung der Medienparameter oft schwergewichtig.

Dementsprechend ist es vorteilhaft, die Kontrolle der Medien im Medienpfad und auf eine Weise durchzuführen, die leichtgewichtig und somit schnell ist.

3.3. Verwendung von AVPF

Für die Feedback-Nachrichten verwenden wir das AVPF-Profil [RFC4585]. (Siehe [RFC4585] für die Begründung der Verwendung von RTCP für Feedback-Nachrichten.) AVPF bietet gültige RTCP-Pakettypen und Betriebsmodi zum Übertragen der Feedback-Nachrichten.

3.3.1. Zuverlässigkeit

AVPF bietet keine eingebaute Zuverlässigkeit. Bestätigungspakete, Neuübertragung und andere Zuverlässigkeitsmechanismen sind schwierig zu implementieren und mit Multicast zu verwenden.

Für die in diesem Dokument definierten Nachrichten haben wir ein Design gewählt, das darauf beruht, dass der Sender der Feedback-Nachricht den Stream überwacht, den er empfängt. Wenn die Feedback-Nachricht verloren ging oder der Mediensender noch nicht darauf reagiert hat, sieht der Sender der Feedback-Nachricht (z. B. der Medienempfänger) nicht die erwartete Reaktion in Form eines modifizierten RTP-Streams. In diesem Fall sollte der Sender der Feedback-Nachricht die Nachricht erneut senden. Das Intervall für solche Neuübertragungen sollte die AVPF-Timing-Regeln respektieren. Es gibt jedoch einige Nachrichten, die einfach keine Zuverlässigkeit erfordern (Benachrichtigungen), und für andere wird die Zuverlässigkeit durch Wiederholung der Nachricht gelöst.

3.4. Multicast

Die in diesem Dokument definierten Feedback-Nachrichten sind hauptsächlich für Punkt-zu-Punkt- und zentralisierte Mehrpunktszenarien gedacht. Ihre Verwendung in nicht-zentralisierten Multicast-Szenarien ist jedoch nicht verboten. Bei der Verwendung der Nachrichten in solchen Szenarien müssen ihre Auswirkungen jedoch gut verstanden werden.

Bei Multicast sendet der Mediensender denselben Bitstrom an alle Empfänger. Wenn ein Empfänger eine Anfrage für eine niedrigere Bitrate oder für ein Intra-Bild sendet, wirkt sich die Erfüllung dieser Anfrage auf alle anderen Empfänger in der Sitzung aus. Dies ist möglicherweise nicht wünschenswert.

Darüber hinaus erfordert AVPF, dass alle RTCP-Pakete in einer Multicast-Sitzung an alle Teilnehmer gesendet werden. Dies bedeutet, dass eine von einem Empfänger gesendete Feedback-Nachricht von allen anderen Empfängern gesehen wird. Dies kann eine Flut von Feedback-Nachrichten verursachen, wenn viele Empfänger alle zur gleichen Zeit dieselbe Nachricht senden. Die AVPF-Timing-Regeln sind darauf ausgelegt, solche Fluten zu verhindern, aber sie sind nicht perfekt.

3.5. Feedback-Nachrichten

Dieser Abschnitt bietet eine allgemeine Beschreibung der in dieser Spezifikation definierten Feedback-Nachrichten. Die formale Definition der Nachrichten befindet sich in Abschnitt 4.

3.5.1. Full Intra Request Command

Ein Full Intra Request (FIR) Befehl zeigt dem Mediensender an, dass er so schnell wie möglich einen Decoder Refresh Point (für Video ein Intra-Bild) senden muss. Die Anwendungsfälle 1 und 2 in Abschnitt 3.1 sind die Haupttreiber für diese Nachricht.

Die FIR-Nachricht ähnelt der Picture Loss Indication (PLI) Nachricht, die in [RFC4585] definiert ist. Es gibt jedoch einen subtilen Unterschied. PLI wird verwendet, wenn der Empfänger einige Daten verloren hat und das Bild wiederherstellen möchte. Der Sender kann sich dafür entscheiden, ein Intra-Bild zu senden, oder er kann andere Mittel verwenden, um das Bild wiederherzustellen (z. B. wenn er weiß, welche Daten der Empfänger hat, kann er Differenzdaten senden). FIR hingegen ist ein Befehl, der den Sender zwingt, einen Decoder Refresh Point zu senden. Dies ist notwendig, wenn der Empfänger kein gültiges Referenzbild hat, zum Beispiel beim Umschalten von Streams in einem Mixer.

3.5.1.1. Zuverlässigkeit

Die FIR-Nachricht ist ein Befehl. Wenn sie verloren geht, bleibt das Video beschädigt (oder leer). Daher wiederholt der Sender der FIR-Nachricht die Nachricht typischerweise, bis er einen Decoder Refresh Point im empfangenen Stream sieht. Die AVPF-Timing-Regeln gelten für diese Wiederholungen.

3.5.2. Temporal-Spatial Trade-off Request and Notification

Die Temporal-Spatial Trade-off Request (TSTR) und Notification (TSTN) Nachrichten ermöglichen es einem Medienempfänger, seine Präferenz für den Kompromiss zwischen zeitlicher Auflösung (Bildrate) und räumlicher Auflösung (Bildqualität) zu signalisieren. Dies adressiert Anwendungsfall 3.

Der Kompromiss wird als ganzzahliger Wert von 0 bis 31 ausgedrückt, wobei 0 die höchste räumliche Qualität (und potenziell die niedrigste Bildrate) darstellt und 31 die höchste Bildrate (und potenziell die niedrigste räumliche Qualität) darstellt.

Die TSTR-Nachricht wird von einem Empfänger gesendet, um einen bestimmten Kompromiss anzufordern. Die TSTN-Nachricht wird vom Sender gesendet, um die Empfänger über die aktuelle Kompromisseinstellung zu benachrichtigen oder eine TSTR zu bestätigen.

3.5.2.1. Punkt-zu-Punkt

In einem Punkt-zu-Punkt-Szenario sendet der Empfänger eine TSTR. Der Sender passt vermutlich seine Kodierung an und sendet eine TSTN zur Bestätigung.

3.5.2.2. Punkt-zu-Mehrpunkt mit Multicast oder Translatoren

In diesen Szenarien können mehrere Empfänger widersprüchliche TSTR-Nachrichten senden. Der Sender muss entscheiden, wie er reagiert. Er könnte zum Beispiel die Anfrage für die höchste Bildrate oder die höchste räumliche Qualität oder einen Durchschnitt berücksichtigen. Der Sender sendet dann eine TSTN, um alle Empfänger über die tatsächliche Einstellung zu informieren.

3.5.2.3. Punkt-zu-Mehrpunkt mit RTP Mixer

Ein Mixer kann TSTR-Nachrichten von mehreren Empfängern verarbeiten und möglicherweise verschiedene Streams für verschiedene Empfänger generieren oder die Anfragen aggregieren und eine einzelne TSTR an den ursprünglichen Sender senden.

3.5.2.4. Zuverlässigkeit

TSTR und TSTN sind Anfragen und Benachrichtigungen. Wenn eine TSTR verloren geht, ändert der Sender den Kompromiss nicht. Der Empfänger kann dies erkennen (indem er keine TSTN erhält oder eine Änderung im Stream sieht) und die TSTR erneut senden.

3.5.3. H.271 Video Back Channel Message

Diese Nachricht ermöglicht das Tragen von ITU-T H.271 Video Back Channel Nachrichten innerhalb von RTCP. Dies ist nützlich für etablierte Video-Codecs, die H.271 für Feedback verwenden.

3.5.3.1. Zuverlässigkeit

Die Zuverlässigkeit für VBCM hängt von der Anwendung ab. Einige H.271-Nachrichten erfordern möglicherweise Zuverlässigkeit, während andere dies nicht tun. Der in diesem Dokument beschriebene Mechanismus bietet keine Zuverlässigkeit auf RTCP-Ebene; es liegt an der Anwendung, Neuübertragungen zu handhaben, falls erforderlich.

3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification

Die Temporary Maximum Media Stream Bit Rate Request (TMMBR, ausgesprochen "timber") und Notification (TMMBN, ausgesprochen "tim-ben") Nachrichten werden verwendet, um die Bitrate des Medienstroms zu steuern. Dies adressiert die Anwendungsfälle 6, 7 und 8.

TMMBR ist eine Anfrage von einem Empfänger an einen Sender, die Bitrate des Medienstroms auf einen bestimmten Wert zu begrenzen. TMMBN ist eine Benachrichtigung vom Sender an den/die Empfänger, die die maximale Bitrate angibt, die der Sender derzeit einhält.

3.5.4.1. Verhalten für Medienempfänger mit TMMBR

Ein Empfänger schätzt die maximale Bitrate, die er handhaben kann (z. B. basierend auf der Link-Kapazität) und sendet eine TMMBR-Nachricht, die diesen Wert enthält.

3.5.4.2. Algorithmus zur Festlegung aktueller Einschränkungen

Ein Sender kann TMMBR-Nachrichten von mehreren Empfängern erhalten. Er muss das "Bounding Set" dieser Anfragen berechnen. Grundsätzlich muss er die minimal angeforderte Bitrate über alle Empfänger (oder zumindest die Menge der Empfänger, die ihm wichtig sind) finden und seine Senderate auf diesen Wert begrenzen. Der Algorithmus beschreibt, wie der Zustand der empfangenen TMMBR-Nachrichten aufrechterhalten und die aktuelle Grenze berechnet wird.

3.5.4.3. Verwendung von TMMBR in einem Mixer-basierten Mehrpunktbetrieb

Ein Mixer fungiert als Empfänger für die Endpunkte, die an ihn senden, und als Sender für die Endpunkte, die von ihm empfangen. Er kann TMMBR verwenden, um die Rate eingehender Streams zu begrenzen, und er muss TMMBR-Nachrichten respektieren, die von Endpunkten empfangen werden, an die er sendet.

3.5.4.4. Verwendung von TMMBR in Punkt-zu-Mehrpunkt mit Multicast oder Translatoren

Bei Multicast muss der Sender die niedrigste angeforderte Bitrate aus der Gruppe der Empfänger respektieren (oder eine andere Richtlinie verwenden).

3.5.4.5. Verwendung von TMMBR im Punkt-zu-Punkt-Betrieb

Einfacher Fall: Empfänger fordert eine Grenze an, Sender respektiert sie.

3.5.4.6. Zuverlässigkeit

TMMBR ist eine Anfrage. TMMBN ist eine Benachrichtigung, die als Bestätigung dient. Wenn ein Empfänger TMMBR sendet und keine entsprechende TMMBN erhält (oder eine Ratenreduzierung sieht), sendet er die TMMBR erneut.