要約

  • IESGは9月10日、時間・空間解像度の要求／通知メッセージをProposed Standardとして承認した。調査時点では第17版Internet-Draftのままで、最終RFC番号はなく、IANA作業も進行中だった。
  • 受信側はフレームレート、幅、高さを求める。送信側は採用予定値を返すが、能力、事前収録、複数参加者、運用ポリシー、輻輳制御によって要求とは異なり得る。
  • TSRRとTSRNが立証するのは制御上の往復である。到着した映像、端末の電力、電池寿命、排出量、体験品質を立証するには、別の観測記録が要る。

「応答した」と「効果が出た」の間

9月10日のIESG公告は、RTP Control Protocol Messages for Temporal-Spatial Resolution をProposed Standardとして承認した。Datatrackerの現行ページには、承認公告送付済みと記録される一方、対象は依然として第17版Internet-Draftで、IANAの処理も進行中と表示されていた。したがって、決定済みの承認と、まだ確認できない最終RFC番号やレジストリ完了を混ぜてはならない。

手続の履歴も公開されている。承認用write-upによると、2024年の最初のWorking Group Last Callでは、コンセンサスを宣言するのに十分な反応が得られなかった。その後にレビューが追加され、2回目を経て良好なコンセンサスに達したと判断された。この記録は承認を疑う材料ではなく、「IETFの意思」がいつ、どの手続で成立したかを示す材料である。

承認された機能は、映像を受ける側の事情を送る側へ伝える細い経路だ。RFC 4585のRTCPフィードバックとRFC 5104のコーデック制御メッセージの上に、フレーム数と画面寸法について専用の要求と通知を加える。相互運用性の進歩である。ただし、メッセージ形式は測定器ではない。

要求側には事情があり、送信側には裁量がある

第17版本文では、受信側が送るTemporal-Spatial Resolution RequestをTSRRと呼ぶ。対象となるメディア送信元、要求系列を区別する番号、フレームレート、画面の幅と高さを含む。値はSDPで合意した上限以下でなければならず、ゼロ値や合意範囲を超える要求は無視される。

受信側ができるのは提案である。符号化器が対応できれば、送信側は今後の映像に要求を考慮できる。そしてTSRNで、要求を受け取ったことと、結果として今後使う値を知らせなければならない。通知値が要求値と同じである義務はない。

相違には正当な理由がある。事前収録映像は変更できないかもしれない。符号化器に該当モードがない場合もある。会議の複数参加者が逆方向の希望を出せば、ミキサーは共同の必要を調整する。サービスの最低品質ルールや輻輳制御も最終値に影響する。

利用可能性はSDP offer/answerでも確定する。offerにtsrrがあってもanswerが採用しなければ、そのセッションでは使わない。運用上の注意は、両端に実装が必要で、片側だけではRTPサービスに変化がないと明記する。「製品が対応」「セッションで合意」「要求を送信」「映像が変化」は同じ事実ではない。

TSRNは意図の記録であって、受信映像の採寸ではない

TSRNは弱い情報ではない。系列番号で元の要求と結び付き、各要求者に受領を返し、送信側が採るフレームレートと寸法を明示する。再送や複数要求にも処理規則がある。沈黙よりはるかに検証しやすい。

それでも、通知の文脈は「今後使う」値である。受信端末に届いたフレームを観測したものではない。通知後にミキサー、トランスレータ、輻輳、再設定が介在し得る。さらに、同じ画素数でもコーデック、専用回路、画面、同時処理によって端末の消費電力は異なる。

エネルギーという目的は、ISO/IEC 23001-11:2023のEnergy Efficient Media Consumptionに由来する。IETF文書は、その文脈にあるデコーダーからエンコーダーへの情報の一部をRTCPで運ぶ。電力測定、電池寿命評価、炭素換算、品質評価を一式で定めるものではない。

だから、次の等号は成立しない。

TSRR受信 ＝ TSRN送信 ＝ 低解像度で到着 ＝ 消費電力低下 ＝ 環境便益。

正しい記録では、これらを別々の状態としてつなぐ。

品質低下を帳簿の外に置かない

文書自身が、不適切な提案を受け入れると体験品質が損なわれ、利用者から苦情が出る可能性を挙げている。運用者は受け入れ可能な範囲を調整し、SLAの保証手順にも織り込む必要がある。画素を減らすことは無料の改善ではない。

電池を守って会議を完了できる場合もあれば、細かい資料が読めず再接続や別手段が必要になる場合もある。多人数通話では、電池制約を持つ人と、高精細映像を必要とする人が別人かもしれない。ミキサーが返す最終値だけでは、誰の必要を優先したか、どのポリシーを使ったかが分からない。

標準が優先順位まで中央決定しないのは妥当だ。ローカルな選択を残しつつ、選択者、影響を受けた人、例外と復旧を追跡可能にすることが運用者の役割になる。

完全性保護は目的の正当性まで保証しない

偽造された要求は、極端に低い解像度やフレームレートを強制しようとしたり、頻繁な要求で負荷を生んだりできる。草案は認証と完全性保護の必要を示し、RFC 5124の安全なフィードバックプロファイルを参照する。異常な報告には保守的に対応することも求める。

保護によって、セッション内の誰が送ったか、途中で改変されていないかは確認できる。だが、その参加者の推定が正しいこと、他人の品質を下げる権限があること、通知後に省エネが起きたことは別問題だ。認証済みの不適切な要求も存在し得る。

実装判断には権利情報も含まれる。QualcommのIPR開示5764は前身草案に関係し、ロイヤルティーまたは料金の可能性を伴う合理的・非差別的ライセンス方針を記載する。InterDigitalのIPR開示6159はWG草案の初期版に関係し、条件付きで合理的・相互的・非差別的な交渉意思を述べる。いずれも、IETFが特許の有効性、必須性、侵害、価格を判断した記録ではない。

解像度変更の証拠鎖を別に持つ

省エネを公に主張するサービスには、プライバシーを絞った解像度変更の証拠鎖が必要だ。最初に、両端の実装版、tsrrの合意、安全コンテキストを記録する。次に、要求者と対象の役割、系列番号、時刻、要求したフレームレート、幅、高さを置く。

判断部分では、送信側またはミキサーのどちらが、どの版のポリシー、許容範囲、集約規則で値を選んだかを示す。TSRNは「採用予定値」として保存する。その後の別の観測で、一定期間に届いたフレームレート、寸法、ビットレートを測る。

エネルギーを語る場合だけ、端末、デコード経路、ハードウェア支援、画面状態、基準条件、測定時間、単位、不確かさを追加する。フリーズ、可読性、アクセシビリティー、苦情、上書き、ロールバック、訂正も並べる。公開版では参加者識別子、秘密、攻撃に使える閾値を除き、運用・紛争・安全調査用の保護記録を残す。

これは私の編集上の提案であり、IETF、ISO、IANA、開示者が要求する新フィールドではない。Heng LuのThe Policy Mirrorが示すように、誰が決め、何が状態を裏付けるかを分けるためのものだ。Minimum Initial Specificationは、狭い共通信号と自発的なローカル実装が両立する理由を与える。Why BTW Media Existsに従えば、名称が想起させる善意より、観測済みの動作を先に報じるべきである。

TSRRは受信側の事情を伝える。TSRNは送信側の返答を残す。省エネの事実は、その次にしか置けない。

Sources

  1. IETFプロトコル承認公告
  2. IETF Datatracker文書情報
  3. Internet-Draft第17版
  4. IETF承認write-up
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. IETF IPR開示5764
  9. IETF IPR開示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