要約

  • RFC 3952 の RTP ペイロードには iLBC のフレーム数がなく、受信側は SDP で合意したモードに従い、全長を 38 または 50 オクテットで割った。
  • 2026 年の Reported 状態の Errata は 32/50 を 38/50 に直す提案であり、パケット長、交渉状態、復号、再生は別々の証拠だと示している。

余りがゼロでも、合意までは見えない

100 オクテットのペイロードを 50 で割れば二つのフレームになる。76 を 38 で割っても二つになる。計算は簡単だが、どちらの計算を選ぶかはパケットの中に書かれていない。RFC 3952 は iLBC の 20 ms モードを 38 オクテット、30 ms モードを 50 オクテットの固定長として、明示的な個数を省いた。

固定長だから個数は冗長だ、という判断には合理性がある。ただし冗長性を削ると、意味を決める状態が別の場所へ移る。RTP が与えるのは到着した長さであり、SDP が与えるのは現在の除数である。送信側が単一モード規則を守ったという前提までそろって、初めて境界が確定する。

同じパケット内に 20 ms と 30 ms のフレームを混在させてはならず、一つのフレームを複数パケットへ分割してもならない。MTU を越えるほど集約しないことも求められた。少数集約は遅延を抑える一方でヘッダー比率が上がり、多数集約は効率を上げる一方で一回の損失が奪う音声時間を増やす。ここには単純な「多い方がよい」はない。

モードは通話の外枠で決まった

iLBC は SDP 上で iLBC/8000 とされ、a=fmtp の mode が 20 か 30 を運ぶ。省略時は 30 が既定値である。双方向セッションでは両端が同じ結果を使わなければならない。

Offer の希望と Answer の選択が異なる場合、RFC 3952 は低帯域側を共通結果とする。数字だけを見ると 20 が小さいが、20 ms ごとに 38 オクテットを送る方が、30 ms ごとに 50 を送るより単位時間のペイロードが大きい。このため、規格の交差例はどちらも mode 30 に落ち着く。

RFC 2327 の SDP と RFC 3264 の Offer/Answer は、媒体の意味をパケット外から供給した。RFC 3550 の RTP タイムスタンプとシーケンス番号は順序や時刻を支えるが、iLBC の除数を宣言しない。交渉成功、パケット到達、分割成功は一つの出来事ではない。

六オクテットの食い違い

RFC 3952 の第 2 節と第 3.1 節は、20 ms フレームを 38 オクテットとしている。RFC 3951 の符号化定義とも整合する。ところが第 3.2 節の個数計算だけは、除数を 32/50 と記した。

Errata 一覧の ID 8866 は、2026 年 4 月 3 日に 38/50 への訂正を提案した。現在の状態は Reported であり、Verified ではない。38 を意図値と読む根拠は強い。それでも「提案された訂正」と「手続き上確認された訂正」を混同しないことが、出典に対する最低限の礼儀である。

この矛盾は実装事故の証明ではない。特定製品の障害、攻撃、通話失敗率を示す資料もここにはない。わかるのは、局所的な一文だけを抜き出せば 32 を採用できてしまう一方、文書全体では 38 が一貫していることだ。データ面のバイト列ではなく、仕様知識の切り取り方が誤る余地だった。

フレーミングの次にも判定が続く

mode 20 で 114 オクテットなら三フレーム、余りはゼロである。それは長さ整合性の記録にすぎない。各ブロックが妥当な iLBC か、送信者が期待した主体か、保護が検証できたか、ジッターバッファが採用したか、デコーダが音声を作れたか、実際に再生されたかは別に判定される。

RFC 3711 の SRTP が認証したペイロードでも、古い SDP モードで解釈すれば利用不能になり得る。逆に、38 で割り切れる平文から送信者の身元は得られない。割り切れない長さはモードずれ、壊れた媒体、誤ったペイロード型、キャプチャ欠損を疑う強い信号だが、原因そのものではない。

RFC Editor の記録では RFC 3952 は 2004 年 12 月の Experimental 文書である。その歴史的価値は、カウント欄の有無を論争することより、状態を削除したときの行き先を見せた点にある。数バイトを節約しても、解釈に必要な契約まで保存しなければ、後日の証拠は軽くなるどころか欠ける。

出典