Zusammenfassung

  • Die IESG billigte am 10. September Temporal-Spatial Resolution Request und Notification als Proposed Standard. Zum Stichtag war Revision 17 weiterhin ein Internet-Draft ohne endgültige RFC-Nummer; die IANA-Arbeit lief noch.
  • Der Empfänger fordert Bildrate, Breite und Höhe an, der Sender meldet seine vorgesehenen Werte zurück. Technik, Aufzeichnung, mehrere Teilnehmer, lokale Regeln und Überlaststeuerung können zu einem anderen Ergebnis führen.
  • TSRR und TSRN belegen einen Steuerungsdialog. Sie messen weder das ausgelieferte Bild noch Empfängerenergie, Akkulaufzeit oder Erlebnisqualität. Eine Einsparungsbehauptung braucht eine separate Kette bis zur beobachteten Wirkung.

Der Standard gibt dem Wunsch eine Form

Die IESG-Mitteilung vom 10. September billigt RTP Control Protocol Messages for Temporal-Spatial Resolution als Proposed Standard. Im aktuellen Datatracker-Eintrag war die Genehmigungsmitteilung vermerkt, zugleich blieb das Dokument Revision 17 eines Internet-Drafts und die IANA-Aktion in Bearbeitung. Der Beschluss darf berichtet werden; eine noch nicht veröffentlichte RFC-Nummer oder abgeschlossene Registrierung nicht.

Auch der Weg zum Konsens ist dokumentiert. Laut Approval Write-up erhielt der erste Working Group Last Call 2024 nicht genügend Rückmeldungen, um Konsens festzustellen. Weitere Reviews gingen einem zweiten Durchgang und der späteren Feststellung guten Konsenses voraus. Das ist kein Makel, sondern die nachprüfbare Herkunft institutioneller Autorität.

Der technische Anlass liegt zwischen zwei Endpunkten. Der Decoder kennt Batteriestand und Rechenlast; der Encoder auf der anderen Seite steuert Bildrate und Auflösung. Die neue Spezifikation ergänzt das Feedback-Modell aus RFC 4585 und die Codec-Control Messages aus RFC 5104 um eine konkrete Anfrage und Rückmeldung.

Der Empfänger schlägt vor

Im Text der Revision 17 trägt TSRR Zielquelle, Sequenznummer, Bilder pro Sekunde, Breite und Höhe. Die Werte müssen innerhalb der über SDP ausgehandelten Grenzen liegen. Nullwerte und Anforderungen oberhalb dieser Grenzen werden ignoriert.

Die Rollen sind bewusst verschieden. Der Decoder kann eine zeitlich-räumliche Auflösung vorschlagen. Ein dazu fähiger Encoder kann den Wunsch für künftige Bilder berücksichtigen. Anschließend muss der Sender mit TSRN melden, welche Werte er infolge der Anfrage verwenden wird. Die Rückmeldung muss nicht die Wunschwerte wiederholen.

Dafür gibt es normale Gründe. Vorproduziertes Material lässt sich womöglich nicht anpassen. Ein Encoder unterstützt die Kombination nicht. Ein Mixer muss gegensätzliche Bedürfnisse mehrerer Teilnehmer verbinden. Eine Dienstregel setzt eine Mindestqualität, und die Überlaststeuerung kann die tatsächlich lieferbare Rate weiter begrenzen.

tsrr muss außerdem im SDP-Offer/Answer gemeinsam akzeptiert werden. Nimmt die Antwort die Funktion nicht auf, gilt sie in der Sitzung nicht als ausgehandelt. Die Betriebssektion sagt ausdrücklich: Eine Implementierung nur an einem Endpunkt verändert den RTP-Dienst nicht. Produktmerkmal, ausgehandelte Fähigkeit, empfangene Anfrage und geänderter Stream sind unterschiedliche Zustände.

Die Benachrichtigung beobachtet den Stream nicht

TSRN ist ein nützlicher Empfangs- und Auswahlbeleg. Die Sequenznummer verbindet es mit TSRR; jeder Anfragende erfährt, dass seine Nachricht angekommen ist, und welche Bildrate und Abmessungen der Sender künftig vorsieht. Auch für Wiederholungen und mehrere Anfragende gibt es Regeln.

Doch die Angabe „künftig verwendet“ ist keine Messung des beim Empfänger angekommenen Videos. Ein Mixer, Übersetzer, Stau oder eine spätere Konfiguration kann den Stream verändern. Das Paket enthält ebenso wenig Watt, Joule, verbleibende Akkudauer oder Emissionsdaten. Derselbe Stream kann je nach Codec, Hardwarebeschleunigung, Display und Nebenlast ganz verschieden viel Energie benötigen.

Der Energiekontext stammt aus ISO/IEC 23001-11:2023, Energy Efficient Media Consumption. Das IETF-Dokument transportiert einen begrenzten Teil des Decoder-Feedbacks in diesem Kontext. Es ist kein vollständiger Messstandard für Energie und Erlebnisqualität.

Darum muss die Nachweiskette getrennte Übergänge haben:

TSRR-Anfrage → TSRN-Auswahl → beobachteter Stream → gemessene Empfängerenergie → Qualitätsbilanz.

Wer von TSRN direkt zur Energieeinsparung springt, macht aus einer Absichtserklärung ein Ergebnis.

Qualität ist keine Nebenwirkung ohne Eigentümer

Die Spezifikation warnt selbst, dass unangemessene Vorschläge das Nutzungserlebnis beeinträchtigen und Beschwerden auslösen können. Betreiber sollen akzeptable Bereiche kalibrieren und den Mechanismus in die SLA-Sicherung einbeziehen. Weniger Pixel können eine Sitzung retten, aber auch Schrift unlesbar machen, Barrierefreiheit verschlechtern oder einen erneuten Anruf erzwingen.

In Konferenzen kann der Teilnehmer mit knappem Akku ein anderer sein als derjenige, der hohe Detailtreue benötigt. Der Mixer muss gemeinsame Bedürfnisse berücksichtigen. Seine drei Rückgabewerte zeigen jedoch nicht automatisch, wessen Bedürfnis Vorrang hatte, welche Regel galt und ob eine Ausnahme möglich war.

Die IETF muss diese Dienstpolitik nicht zentral festlegen. Ein schmales gemeinsames Protokoll lässt lokale Entscheidungen zu. Gerade deshalb muss der Betreiber die eigene Entscheidung samt Folgen und Korrektur sichtbar halten.

Authentizität ist nicht Zweckmäßigkeit

Gefälschte Rückmeldungen könnten Bildrate oder Abmessungen stark senken, unzulässige Erhöhungen anfordern oder durch hohe Frequenz Last erzeugen. Der Entwurf verlangt, Authentisierung und Integritätsschutz einzusetzen, verweist auf das sichere Feedback-Profil in RFC 5124 und fordert vorsichtiges Verhalten bei ungewöhnlichen Meldungen.

Damit lässt sich die Herkunft im geschützten Sitzungskontext und die Unverändertheit prüfen. Es folgt daraus nicht, dass die Schätzung des Empfängers stimmt, seine Dienstrolle den Eingriff erlaubt oder Energie gespart wurde. Ein authentisierter schlechter Hinweis bleibt schlecht.

Zur Einführung gehört auch die Rechteprüfung. Die Qualcomm-IPR-Offenlegung 5764 bezieht sich auf den Vorgängerentwurf und nennt eine angemessene, nicht diskriminierende Lizenz mit möglicher Gebühr. Die InterDigital-Offenlegung 6159 betrifft frühe WG-Fassungen und erklärt unter den beschriebenen Voraussetzungen Verhandlungsbereitschaft zu angemessenen, gegenseitigen und nicht diskriminierenden Bedingungen. Das sind Hinweise, keine IETF-Urteile zu Gültigkeit, Erforderlichkeit, Verletzung, Preis oder tatsächlicher Lizenzpflicht.

Eine Beweiskette bis zur Wirkung

Ein Dienst, der Energieeinsparung behauptet, sollte eine datensparsame Beweiskette der Auflösungsänderung führen. Zuerst kommen Implementierungsversionen, ausgehandeltes tsrr und Sicherheitskontext. Danach folgen Rollen, Zielquelle, Sequenz, Zeitpunkt und angeforderte Werte.

Der Entscheidungsabschnitt nennt Sender oder Mixer, die geltende Richtlinienversion, akzeptable Bandbreite und Aggregationsregel. TSRN wird als angekündigte Auswahl gespeichert. Eine getrennte Beobachtung misst anschließend über ein festes Fenster die wirklich gelieferte Bildrate, Abmessungen und Bitrate.

Für eine Energieaussage werden Gerät, Decoderpfad, Hardwareunterstützung, Displayzustand, Grundlinie, Einheit, Zeitraum und Unsicherheit ergänzt. Daneben stehen Einfrieren, Lesbarkeit, Barrierefreiheit, Beschwerden, Übersteuerung, Rücknahme und Korrektur. Öffentlich werden Teilnehmerkennungen, Geheimnisse und ausnutzbare Schwellen entfernt; geschützte Belege bleiben für Betrieb und Streitfälle.

Diese Kette ist mein redaktioneller Vorschlag, keine Forderung von IETF, ISO, IANA oder den Offenlegenden. Sie folgt Heng Lus Policy Mirror: Für jeden Zustand muss erkennbar sein, wer entscheiden darf und welcher Beleg ihn trägt. Minimum Initial Specification erklärt, warum ein enger gemeinsamer Baustein mit freiwilliger lokaler Einführung vereinbar ist. Why BTW Media Exists fordert, beobachteten Betrieb nicht durch institutionelle Absicht zu ersetzen.

TSRR macht den Bedarf des Empfängers lesbar. TSRN macht die Auswahl des Senders lesbar. Die Energiebehauptung muss danach ihren eigenen Beleg liefern.

Sources

  1. IETF-Protokollmitteilung
  2. IETF-Datatracker-Eintrag
  3. Internet-Draft Revision 17
  4. IETF Approval Write-up
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. IETF-IPR-Offenlegung 5764
  9. IETF-IPR-Offenlegung 6159
  10. ISO/IEC 23001-11:2023
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists