要約

  • RFC 9626 は、フレーム境界、時間的独立性、廃棄可能性、スケーラブルな層を暗号化ペイロードの外に小さく表現し、RTPスイッチが映像を復号せずに転送を選べるようにする。
  • SRTPによる認証は印の送信元と完全性を示す。しかし、その印が暗号化された内容と一致すること、受信側の参照状態がそろうこと、画面に正しく表示されたことまでは証明しない。
  • 運用上の証明には、ネゴシエーション、送信側での抽出、可視性方針、スイッチの判断、配送、デコーダ状態、実際の表示を結ぶ記録が必要である。

話者が変わる。RTPスイッチは全空間層に I が立った地点を見つけ、新しいストリームを転送する。中央のログでは切り替えは成功だ。だが一台の端末では、新しい顔が次の更新点まで現れない。

ここで問題なのは、スイッチが規則を破ったかどうかだけではない。規則が参照した印を誰が作り、誰がその正しさを調べ、最後の結果を誰が受領したかである。

2025年3月にExperimentalとして公開された RFC 9626 は、プライベートな映像をエンドツーエンドで暗号化する会議の実務的な難題を扱う。中央のRTPスイッチは、アクティブな話者を選び、輻輳時には上位層を止め、別ストリームへ移る必要がある。しかし、そのために画素へアクセスさせれば、暗号化の権限分離が崩れる。

そこで規格は、映像そのものではなく、判断に必要な構造だけをRTPヘッダ拡張に載せる。これは「見えないのに働ける」仕組みであり、同時に「見えないから検証できない」境界でもある。

同じ一ビットでも、知識の種類は違う

短形式には S、E、I、D がある。S と E は、ある層におけるフレームの最初と最後のパケットを示す。I は時間的に前のフレームへ依存しないという宣言である。D は、そのフレームを捨てても残りが復号可能だと送信側が把握していることを示す。

長形式は B、TID、LID、TL0PICIDX を加える。TID は時間層、LID は空間層または品質層を相対的に示す。TL0PICIDX は基底時間層の画像、あるいは上位層が依存する基底画像を識別する。B は非基底時間層が基底層へ同期できる地点を表す。

圧縮された語彙を拡大解釈してはならない。I が保証するのは時間方向の独立であり、高い空間層は同時刻の低い層を必要とし得る。TID や LID は絶対的なフレームレート、解像度、ビットレートではない。これらの番号だけで依存関係の全体図も得られない。

特に B は、知識がどこから来るかを露わにする。RFCは、H.264やH.265では単純なペイロード・ヘッダ検査だけで確実に導けない場合があるとする。実装はコーデック内部のインターフェースに頼るかもしれない。スイッチが見る一ビットは、スイッチから見えない内部状態を投影したものなのである。

MUST は検証装置ではない

RFC 9626 は、拡張の値がRTPペイロードの内容を表さなければならないと定める。VP8、VP9、H.264、H.265には対応規則があり、将来のペイロード形式も TID と LID の写像を規定することが期待される。

この要件は送信側の責任を明確にする。暗号化されたパケットを受け取るスイッチに、新しい観測能力を与えるものではない。

暗号化前なら、試験装置はペイロード記述子やコーデック内部イベントと、出力された各印を照合できる。暗号化後のスイッチは、I が本当に独立画像か、D が参照を壊さず廃棄できるかを一般には開封して確認できない。写像のバグ、古い内部状態、コーデック更新の回帰があれば、間違った記述も真正な送信元から改ざんなしに届く。

SRTP認証が答えるのは、「許可されたピアがこの値を出し、途中で検知されずに変更されていないか」である。「この値はコーデック上の事実と一致するか」ではない。発言者の身元と発言内容の真偽は、別の証明である。

したがってリリース試験は、拡張の存在確認で終われない。予測フレームに I、参照フレームに D、タイムスタンプやRTPマーカと食い違う境界、説明不能なインデックス飛び、必要な空間層を欠く切り替え点、内部情報を得られない時の B を意図的に試す必要がある。

切り替え判断と表示結果の間

輻輳時、RFCは D のフレーム、または最上位の時間層・空間／品質層から落とす運用を示す。新しいストリームを開始するときは、全空間層で I が成立する地点を用いる。

これは合理的な転送規則だが、D は送信側の判断であって、受信側が現時点で保持する参照バッファではない。過去のパケット損失により状態が弱っていることもある。全層の I は入り口の候補を示すが、必要なパケットが再生期限までに届くことを保証しない。

RFC 9627 のLayer Refresh RequestやFIRは、回復を求める制御信号を提供する。要求を送った事実は、エンコーダが応じた事実でも、更新データが届いた事実でも、デコーダが採用した事実でもない。

完全な受領記録は連鎖で作る。スイッチが見た認証済み印、その時点の輻輳入力、転送・廃棄・切り替え理由、受信したパケット、欠けた依存、デコーダの回復、最初に表示された画像を時系列で結ぶ。「SFUは印どおり動いた」は判断監査の終点であって、映像配送の終点ではない。

画素を隠しても、動きの時系列は残る

SRTPではヘッダ拡張が認証され、選択により暗号化もできる。RTPスイッチがSRTPピアなら、プライベート映像そのものを見ずに暗号化済みの印を利用できる。経路上の他の中間装置には見せない設計が可能だ。

一方、より多くの中間装置に廃棄最適化をさせるため、印を平文にする選択もある。その場合、フレーム境界、独立画像の周期、層の変化を信頼できる信号として公開する。暗号化パケットの大きさからキーフレームを統計的に推測することは以前から可能だったが、明示的な印は推測を確定的な観測へ変える。

したがって「映像は暗号化されている」は「映像行動は観測できない」と同義ではない。RFC 9335 はRTPヘッダ拡張を完全に暗号化する仕組みを示し、RFC 8871 はプライベート・メディア会議の文脈を示す。しかし誰に可視化し、何日保持し、どの最適化だけに使うかは、サービスの決定として残る。

セッション内の番号に永続的意味はない

urn:ietf:params:rtp-hdrext:framemarking は RFC 8285 の extmap でネゴシエートされ、ローカル識別子を得る。同じ数字は別のセッションで別の拡張を意味し得る。オファー／アンサーの更新で方向も変わり得る。

そのため、パケットだけを保存しても監査には足りない。URI、識別子、方向、暗号化方針、有効期間を一緒に保存しなければ、後で同じ数字を正しく読めない。見慣れたビット列があることと、RFC 9626が合意され有効だったことは別である。

RFC 9628 はVP9のスケーラブル構造をこの語彙に接続する。将来のコーデックも独自の写像を持つ。エンコーダ更新は印の生成を、SFU更新は印の消費を変え得るため、両者を一つの版管理された変更面として検証し直さなければならない。

Sources