要約

  • RFC 8285 に置き換えられた RFC 5285 は、RTP 拡張要素の数値をローカル ID とする。形式と意味を定義するのは URI であり、extmap が交渉範囲内で両者を結ぶ。
  • パケット受信、形式解析、マッピング、意味の復号、処置、結果確認は別々の受領証である。録画・監視系は SDP の時代区分と BUNDLE の範囲をパケットと共に残す必要がある。

会議録画の映像は欠けていなかった。RTP の連番も時刻もそろい、拡張 ID 3 も保存されていた。それでも後日の分析は誤った。解析器が「3 は音声レベル」という以前の会議の対応表を再利用したからだ。対象の会議では 3 は送信時刻のずれを表す URI に割り当てられていた。

失われたのはパケットではない。パケットを読むための交渉だった。

RFC 5285 は、RTP の一つの拡張領域に複数の小さな要素を効率よく収める仕組みを定めた。長い URI を毎回送る代わりに、要素には短い ID を付ける。URI が拡張の形式と意味を正確に名付け、SDP の a=extmap:<値> <URI> が短い数値との対応を示す。

後継の RFC 8285 は、一バイト形式と二バイト形式の混在能力などを更新した。しかし、短い ID の権限を広げたわけではない。ID はあくまでローカルであり、静的な世界共通割当は存在しない。

レジストリにあるのは URI である

IANA の RTP Compact Header Extensions レジストリには、送信時刻オフセット、同期時刻、音声レベル、MID、RID、フレームマーキングなどの URI が並ぶ。各 URI には仕様と参照先がある。一方、実際のストリームで 1 や 3 や 7 のどれを使うかはセッション側が決める。

一バイト形式で利用できる ID は 1 から 14 までである。二バイト形式はより広い範囲と長い値を扱う。この小ささが帯域効率を生む。同時に、同じ 3 が別の会議では別の URI を指せる理由にもなる。

したがって、保存すべき証拠は ID=3 だけではない。そのパケットに適用された offer/answer、メディア記述、BUNDLE グループ、方向、URI、拡張属性を結び付ける必要がある。対応表が見つからないなら「未知の形式」や「破損」と決めつけず、「意味のマッピング未解決」と記録する。

未解決でも、パケットは無価値ではない。到着時刻、欠落、順序、SSRC、元のバイト列を証明できる。ただし拡張値を音声レベルや MID と呼ぶ根拠はまだない。この限定を表示できることが、証拠系の強さである。

形式を読めたことと、値を理解したこと

RTP 拡張の profile フィールドを見れば、そのパケットが一バイト形式か二バイト形式かを判別できる。長さを検査し、各要素を切り出し、パディングを飛ばすこともできる。ここまでが構文の受領証だ。

次に、当時有効だった extmap から ID に対応する URI を探す。その URI の仕様に従うデコーダーが値を受理して初めて、意味の受領証が生まれる。構文解析成功を「処理済み」と表示すると、この二段階が見えなくなる。

一バイトと二バイトの扱いにも同じ注意が要る。RFC 5285 では同一ストリーム内の混在は禁止だった。RFC 8285 は extmap-allow-mixed を定義し、offer/answer または帯域外の合意で全受信者の能力が分かる場合に限り、ストリームの異なるパケットで両形式を使えるようにした。一つのパケット内部で両形式の要素を混ぜる規則ではない。

二バイト形式のパケットが存在することは送信の証拠だが、受信者が同意した証拠ではない。offer に属性があることは提案の証拠だが、answer や実際の送信を証明しない。観測と許可を一つの緑色ランプにしてはいけない。

対応表はセッション中に勝手に意味を変えない

適用範囲内では、有効 ID を複数の拡張に重複利用できない。セッション更新で拡張を追加・削除し、方向を変更することはできるが、有効 ID を別の URI に付け替えることはできない。飛行中のパケットを二冊の辞書で読む事態を防ぐためだ。

この安定性は、アーカイブにも時系列を要求する。最後の SDP だけを保存すると、更新以前のパケットを後の状態で解釈する危険がある。交渉が変わるたびに時代区分を作り、どの時点から有効かを記録しなければならない。

4096 から 4351 の値は、相互排他的な候補や有効範囲に収まりきらない候補を offer で示すために使える。answer 側は選んだ候補を空いている有効 ID に割り当てる。大きな候補値そのものはパケットに載せられない。候補を実行済みの拡張として数えるのは、計画と現実の混同である。

方向指定も同様だ。inactive は現在送らないことを表せる。recvonly の宣言は実パケットの存在を証明しない。SDP は合意された可能性を、RTP は起きた送信を示す。

BUNDLE では辞書の境界も束ねられる

BUNDLE は複数の m= セクションに一つのトランスポートを共有させる。MID は受信した RTP を正しいメディア記述へ結び付ける。RFC 9143 は、束ねた RTP メディアの offer と answer で MID 拡張を有効にすることを求める。

RFC 8285 では、同じ BUNDLE グループの m= セクションは一つのローカル ID 空間に属する。同じ URI と設定を複数のメンバーで使うなら同じ ID が必要だ。ただし各メンバーの拡張集合は異なり得る。

つまり、ホスト全体で一枚の表を使うのも、各 m= を完全に孤立させるのも誤りになる。グループ、メンバー、URI、設定、有効時期の関係を保存する必要がある。SFU や録画装置が拡張を書き換えるなら、入力マップと出力マップも別々の証拠にしなければならない。

RFC 8852 の RtpStreamId は、さらに別のスコープを持つ。値は送信元とメディアセッションにより区切られ、BUNDLE では MID にも区切られる。拡張 ID が URI を選び、その拡張の値である RID がストリームを選ぶ。同じ「ID」という語でも、支配する名前空間は異なる。

暗号化で見えなくなったものを、消えたものと呼ばない

拡張メタデータは機微情報になり得る。RFC 6904 は選択した拡張値の暗号化を定めた。RFC 9335 は、ID と長さの並び自体もアプリケーションや端末の指紋になり得ると指摘し、Cryptex でより広い範囲を保護する。

暗号化後、中間監視点が拡張を読めなくなっても、送信元が情報を生成しなくなったとは言えない。「観測権限が変わった」と記録すべきだ。復号権限のある終端でも、正しい交渉時期を持たなければ意味を誤る。

受領証は少なくとも、パケット到着、形式解析、対応表特定、URI 固有の復号、認可された利用、独立した結果観測に分ける。正しく読んだ音声レベルを使って話者を選んでも、別の遅延原因で体験が悪化することはある。入力の正しさが結果を保証するわけではない。

RFC 5285 の節度は、短い番号に大きすぎる権限を与えなかった点にある。線上では効率を優先し、意味は交渉へ置いた。運用側も同じ節度で、観測した層と推論した層を分ける必要がある。