要約

  • RFC 3555 は、媒体型の一つの表現を SDP の複数の欄へ写像し、名前、時計、チャネル、パケット時間、形式固有値を別々の証拠として扱った。
  • ptime は推奨値、maxptime は上限の記述であり、送信側が実際にその長さで封入したことや、受信・再生に成功したことを証明しない。

出発点は audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15 という一行である。RFC 3555 の写像を通ると、一行は四つの役割に分かれる。媒体種別の audio は m= 行へ移る。L16、48000、2 は a=rtpmap:97 L16/48000/2 になる。強調特性は a=fmtp:97 emphasis=50-15 に渡される。そして ptime=5 は a=ptime:5 として独立する。

分割後も情報量が同じに見える。しかし、各値を評価する主体は同じではない。SDP はセッションを記述し、fmtp の内容を媒体ツールへ渡せるが、そのコーデックの意味を自ら実装する必要はない。登録簿は名前と参照仕様を管理するが、送信器の封入や受信器の復号を行わない。

五ミリ秒という助言

ptime は一包に含める媒体時間の推奨値として定義された。従って a=ptime:5 を保存した監査記録が証明するのは、記述が五ミリ秒を提案したことまでである。実際の RTP パケットが常に五ミリ秒分だったか、ネットワークで欠落しなかったか、ジッタバッファが期限内に取り出したか、利用者が音を聞けたかは別の観測が要る。

maxptime も同じである。上限の宣言は、送信器の全出力を自動的に検査する装置ではない。規格上の値を運用結果へ直結させると、設計文書がテレメトリーの代用品になってしまう。

この境界は時計にも及ぶ。rate=48000 は RTP タイムスタンプ時計を指定する文脈の値である。表示機器の品質、ファイルの保存方式、実際の再生速度を単独で保証しない。欄の名前だけで、隣接する現実まで推定してはならない。

fmtp は拡張用の空白ではない

形式固有パラメータは fmtp に入る。ところが RFC 3555 は、その集合を媒体型登録だけで増やしてはならないとした。許される値はペイロード形式を定義する RFC が所有し、追加には対応する仕様改訂が必要だった。

この仕切りがなければ、登録作業だけでワイヤ上の意味を変えられる。ある実装が私的なキーを理解しても、別の実装が同じ名前から同じ意味を得るとは限らない。構文が通ること、登録が存在すること、実装が理解すること、パケットが正しいことは、連続した別々の受領書である。

動的ペイロード番号 97 も局所的な受領書にすぎない。別のセッションでは別形式を指せる。意味を復元するには、そのセッションの m= 行と rtpmap が必要であり、番号だけをログに残しても世界共通のコーデック名にはならない。

文書の分割が示した保守単位

RFC 4855 と RFC 4856 は 2007 年に RFC 3555 を廃止した。RFC 4855 は登録手順と SDP への写像を更新し、RFC 4856 は具体的なプロファイル登録を分離した。後者は、抽出によって技術的変更を加えていないと明記している。

さらに RFC 4855 は、RTP と非 RTP のファイル転送で同じサブタイプを共有する条件を厳密にした。データ形式が定義された意味で同等であり、必須パラメータ集合も同じでなければならない。違うなら別名が必要である。名前の共有が先にあり、形式の同一性を後から仮定するのではない。

2026 年 10 月 6 日更新の凍結 IANA XML では、音声に 165、映像に 97 の登録があり、20 件が RFC 4856 を直接参照していた。これは管理記録の継続を示す。audio/L16 の行があるからといって、手元の端末が L16 を実装し、今回の 48000/2 の組を受け入れ、五ミリ秒で再生できるとは言えない。

現在の SDP を定義する RFC 8866 も、rtpmap と fmtp を別の役割として残している。RFC 3555 の歴史的な核心は、同じ語を広げたことではない。語が文脈を渡るたびに、意味の移動を検査できる形で分解したことにある。

出典