要約

  • RFC 5215 の 24 ビット Ident は、Vorbis データを復号用 Configuration に結び付ける索引である。Ident を受信した事実は、受信側が設定本体を取得・解析・導入したことの証明にはならない。
  • Ident が変わったのに対応する Configuration がなければ、クライアントは関連する生データを復号してはならない。RTP の連続性が完全でも、正しい出力が沈黙になる場合がある。

「ネットワーク正常」の先にあった停止

障害時のパケット列は美しいほど連続していた。番組が切り替わった後もシーケンス番号に穴はなく、到着間隔も許容範囲に収まっていた。転送だけを見れば、異常なしという判定は正しい。

しかし、その境界で Vorbis ペイロードの Ident が変わっていた。新しい Ident が参照する Configuration は複数の断片に分かれ、その一部が届かなかった。後続の音声パケットはすべて受信されたが、デコーダーが使うべきコードブックは完成しなかった。

RFC 5215 は、この状況で推測による復号を認めない。Ident の変更を検出しながら正しい Configuration を持たないクライアントは、それを取得するまで関連データを復号してはならない。無音は転送失敗の同義語ではなく、不正な解釈を防いだ結果でもある。

24 ビットの値が持たないもの

Vorbis には、どのストリームにも共通する静的な確率モデルがない。エントロピー復号、ベクトル量子化、Huffman モデルなどの情報をストリーム固有のブロックとして運ぶ。チャンネル数など、デコーダーを準備する情報も必要になる。

Identification と Setup の各ヘッダーは、音声フレームを解釈する前に受信されなければならない。Comment ヘッダーは構造上存在するものの、フレーム復号には不要であり、Packed Configuration ではダミーに置き換えられる。この違いは、目につきやすいメタデータと、動作を支配する設定を分けて考える助けになる。

Ident は設定を効率よく参照するための番号だ。同じ設定を各パケットに繰り返さずに済み、途中でコードブックを変えることもできる。だが番号は中身ではない。受信ログに Ident が残っていても、全断片の収集、ヘッダーの検証、ローカル表への登録までは保証しない。

監視画面が payload type、クロックレート、チャンネル、Ident、受信率を一つの状態に丸めると、この欠落が見えなくなる。そこに並ぶ値はデータの扱い方を宣言しているだけで、デコーダーの現在状態を読み出したものではない。

SDP は入口を示すが、実行を証明しない

SDP の rtpmap には Vorbis、クロックレート、チャンネル数を記述できる。ただし RFC 5215 は、それらをヒントとして扱う。正確な情報を届けるのは Configuration であり、fmtp の configuration パラメーターは必須である。非連結ストリームでは、初期 SDP 内の Packed Configuration が推奨される。

セッション中に設定が変わることもある。更新は RTP 内、再度の SDP、あるいは帯域外の取得先から届く。実装は帯域内更新に対応し、帯域外更新にも対応することが望ましい。Configuration の RTP タイムスタンプは、その設定を使う最初のデータパケットを示す。

これは適用開始点の宣言であって、受領印ではない。送信側で新設定を発行した記録があっても、各受信機が期限までに導入したかは別に確認しなければならない。

一つの設定断片が全体を止める

設定は通常の音声パケットより大きく、分割されることがある。クライアントには、断片化と定期的な再送を扱う能力が求められる。音声パケット一つの欠落は信号の一部を失わせる。Configuration 断片の欠落は、その Ident に属する以後のストリーム全体を復号不能にし得る。

パケット数だけの成功率は、この非対称性を逆さに評価する。大量の小さな音声パケットが到着すれば、設定断片一つの欠落は統計上ほとんど消える。だが利用者から見れば、その一つが残りすべての価値を決めている。

受信側は再送要求、帯域外取得、バッファリング、リセット、セッション終了などを選べる。設定を後から入手できても、再生期限を過ぎればリアルタイムサービスは戻らない。リセットで音が戻っても、原因となった対応表を消してしまえば検証はできない。

復号権限のレシートを作る

運用記録には、offer/answer の世代、payload type、SSRC、Packed Configuration のハッシュを残すべきだ。Ident と Identification/Setup ヘッダーのハッシュ、最初に適用される RTP タイムスタンプも結び付ける。

さらに、信号経路、帯域内、帯域外、再送のどこから届いたか、断片がすべてそろったか、解析と導入が成功したかを受信側で記録する。設定待ちの間にどの生パケットを保持・破棄したか、最初の復号フレームがいつ得られたか、再生系にサンプルが渡ったかまで確認して初めて、サービスの連鎖が閉じる。

この「復号権限レシート」は BTW の編集上の提案であり、RFC への追加要件ではない。目的は証拠の射程を守ることにある。RTP は到着を、SDP は提示内容を、Ident は選択を、導入ログは受信側の準備を、デコーダーと出力イベントは実行を証言する。

Lu Heng の running code の考え方を当てはめれば、宣言は消費する実装に届いて初めて動作上の意味を持つ。見える番号が、存在しない設定を代行することはできない。パケットが何千回同じ Ident を掲げても、欠けたコードブックは生成されない。

経営判断に必要なのは「転送率は何％か」だけではない。「その瞬間、その受信機がそのパケットを解釈できる状態だったと、どの証拠が示すのか」である。

出典

  1. RFC 5215
  2. IETF Datatracker — RFC 5215
  3. RFC 5215 情報
  4. RFC 5215 履歴
  5. RFC 3550 — RTP
  6. RFC 4566 — SDP
  7. RFC 3264 — Offer/Answer
  8. RFC 4588 — RTP 再送
  9. RFC 3611 — RTCP XR
  10. RFC 3533 — Ogg カプセル化
  11. RFC 4648 — Base 符号化
  12. RFC 3986 — URI
  13. RFC 3551 — RTP プロファイル
  14. RFC 1191 — Path MTU
  15. RFC 1981 — IPv6 Path MTU
  16. Xiph — Vorbis I 仕様
  17. RFC 8088 — RTP サーキットブレーカー
  18. RFC 8866 — SDP
  19. Lu Heng — running-code primacy