要約

  • RFC 3558 は、EVRC または SMV の連続する音声フレームを複数の RTP パケットに振り分ける。一つのパケットが失われても、欠落は時間軸上で連続せず、受信済み音声の間に分散する。
  • NNN は群内の送信位置を示すが、復号器が必要とする時間順の完成証明ではない。群、フレーム位置、到着時刻、再生期限、消去挿入を別々に残さなければならない。

RFC 3558 は 2003 年 7 月に Proposed Standard として公表され、EVRC と SMV の RTP ペイロードを定めた。両コーデックは 20 ミリ秒ごとに一つのフレームを処理する。隣接フレームを同じパケットに束ねれば、パケット損失は連続区間を消す。異なるパケットへ交互に配置すれば、一回の損失は離れた位置の消去になる。

この違いは音声を復元する魔法ではない。損失の並び方を変え、受信側に時間軸を組み直す仕事を移す設計である。

パケット群は行列として読む

Interleaved/Bundled 形式の先頭オクテットには、三ビットの LLL と三ビットの NNN がある。LLL はインターリーブ長、NNN は群内パケットの番号を示す。次のオクテットには逆方向の Mode Request と、五ビットの Frame Count が入る。Count は実数から一を引いた値なので、一パケットは一から 32 フレームを表せる。

LLL がゼロなら単純なバンドルであり、正なら NNN は LLL 以下でなければならない。一パケット当たり B フレーム、長さ L とすると、一群は L+1 個の RTP パケットで B×(L+1) 個の時間位置を覆う。パケット N は N、N+(L+1)、さらに同じ間隔の位置を運ぶ。

横に読めば送信順、縦に読めば音声の時間順になる行列を想像するとよい。NNN の昇順送信は受信待ちを抑えるが、最後の列が遅れれば最初の再生位置も待たされる。順番どおり届いたという事実だけでは、締切内に行列が埋まったことにならない。

記録すべきなのは、RTP シーケンス、群 ID、LLL、NNN、各フレーム位置、到着時刻、再生期限、最終処理である。パケット単位の成功率では、時間順再構成の失敗を説明できない。

分散した消去は回復ではない

RFC 3558 は、ゼロビット長の null frame と erasure frame を区別する。null はコーデック出力がない状態で、通常は送信されない。erasure は失われた、または破損したフレームの代わりとして受信側が復号器へ渡す。

消去フレームは復号器の状態を 20 ミリ秒進める。しかし、失われた発話内容を再生成したとは言えない。インターリーブによって消去の間に正常フレームが残れば、長い連続欠落より扱いやすいことがある。それでも固有名詞や数字の一部が欠ける可能性は残る。

したがって「復号継続」は品質の受領書ではない。どの時間位置が消去となったか、その原因がネットワーク損失か、遅延か、無効ペイロードかを、後の品質評価やアプリケーション判断と結び付ける必要がある。

最初の位置に遅く、後の位置には間に合う

一つの交錯パケットには時間的に離れたフレームが入る。そのため到着時点で、最初のフレームだけが再生期限を過ぎ、後続位置はまだ有効という状態が起こり得る。

パケット全体を捨てれば実装は単純だが、利用可能な後続音声まで失う。全位置を待てば会話遅延が増える。期限内の位置だけを取り込むなら、フレーム単位の期限と部分利用の受領書が必要になる。

RFC は位置情報を与えるが、アプリケーションの待ち時間を決めない。ジッターバッファ、OS スケジューラ、復号 API、サービス目標がローカルに決める事項である。

「パケット P は時刻 T に到着、F1 は期限超過で消去、F2 と F3 は取り込み、方針 V で再生」という粒度なら、輸送の事実と音声結果を接続できる。

maxinterleave は上限であり、確保済み容量ではない

受信側は maxinterleave で受け入れ可能な最大 LLL を示す。省略時の既定値は五である。一対一セッションでは送信側はこの値を超えてはならない。受信側はセッション途中で値を下げることもできる。

上限が分かれば必要バッファの最大値を計算できる。しかし、メモリーを実際に確保したこと、競合負荷から守られたこと、送受信双方が同じ群から新値を適用したことは証明しない。

maxptime は一パケットのメディア時間を制限し、既定値は 200 ミリ秒である。これは束ねる量の境界であり、maxinterleave は分散距離の境界である。実遅延には B、L、ジッター、並べ替え深度、バッファ占有、復号スケジュールも関わる。

提案、応答、発効時刻、送信実装版、最初に新上限へ従った群、確保バイト、占有ピークを一緒に残して初めて、能力表示を運用証拠へ変えられる。

Header-Free は遅延を優先する選択肢

Header-Free 形式は ToC やインターリーブヘッダーを持たず、一つのコーデックフレームだけを運ぶ。群再構成を行わないためパケット化の待ち時間は短いが、同じ音声時間に対して RTP、UDP、IP ヘッダーが増える。

RFC 3558 は、対話性が重要なら LLL=0 または Header-Free を推奨し、遅延より耐損失性を重視する場合に四や五を候補とする。これは優劣表ではない。帯域、メモリー、会話時間、連続損失のうち、どれを希少資源と見るかの選択である。

RFC 2508 と RFC 3095 のヘッダー圧縮は、単一フレーム送信の費用を変え得る。ただし対応機能があることと、実際の経路で圧縮コンテキストが健全だったことは別の証拠である。

Mode Request の反復は応答ではない

Mode Request は逆方向の符号器にモードを求める。一対一では従うことが推奨され、多人数では無視すべきとされる。単一損失に耐えるため要求は繰り返される。

繰り返しは到達確率を上げるが、適用確認にはならない。要求、各送信、受信証拠、符号器判断、新モードを示す最初のフレームを分けて保存する必要がある。送信済みを変更済みと扱えば、制御意図が実行結果に化ける。

インターリーブも同様に、受信能力、送信側選択、観測されたパケット列を分離して扱う。

同じ消去でも原因は異なる

ToC は各フレームの種類とサイズを示す。LLL、NNN、フレーム数、実バイトの組み合わせが無効なら、受信側はパケットを破棄し、消去を渡すことがある。復号器から見ればネットワーク損失に近いが、修復すべき所有者は異なる。

未到着、遅着、形式不正、未対応フレーム、ローカルバッファ追放を別々に数えるべきである。すべてを「パケットロス」にまとめると、制御可能な面が見えなくなる。

RFC 4788 は後に EVRC-B、Compact Bundled、DTX、登録および offer/answer を更新した。これは後続文脈であり、個別の RFC 3558 実装がその機能を持つ証拠ではない。

証拠の境界

本稿は事業者、装置、通話、利用者、障害、実測損失率、確保メモリー、聴感結果を特定しない。例は標準の仕組みを説明するもので、実運用報告ではない。

RFC 3550 と RFC 3551 は RTP の枠組み、RFC 3264 は offer/answer、RFC 2327 は公開時の SDP、RFC 8866 は後続の位置付けを与える。RFC 2508 と RFC 3095 は圧縮、RFC 8174 は規範語を補う。RFC 4788 は後続更新である。

Heng Lu の Running-Code Primacy と Minimum Initial Specification は明示した編集上の視点である。宣言された能力と動作証拠を分け、共有仕様を小さく保って将来判断をローカルな責任者へ残すために用いた。RFC 著者の意図やネットワーク事象を証明する資料ではない。

限定できる結論は、RFC 3558 のインターリーブが一回のパケット損失を非連続のフレーム消去へ変え、その代わりに時間順再構成、バッファ、締切判断を受信側へ課すということである。NNN の順序は、その仕事の完了証明ではない。

Sources