要約

  • RFC 5577は従来のRTPペイロード仕様を置き換え、G.722.1 Annex Cの14 kHz音声、32 kHzサンプリングクロック、48 kbit/sの設定を扱えるようにした。
  • ただし旧設定を一斉に切り捨てたわけではない。RFCは相互運用のために16 kHz設定も提示するよう勧め、使用予定の各クロックレートとビットレートの組み合わせをSDPで宣言するよう求めた。

後継仕様は、旧仕様を知る端末を消さない

2009年7月に公開されたRFC 5577の表紙には「Obsoletes: 3047」とある。旧仕様が退き、新仕様へ一斉に切り替わったようにも読める。しかし、相互運用の節が描く移行はもっと現実的だ。RFC 3047はG.722.1を16 kHzのサンプリングクロックで記述していた。改訂されたITU-T勧告のAnnex Cに対応したRFC 5577は、超広帯域音声を加え、帯域を14 kHzまで広げ、32 kHzクロックと48 kbit/sの設定を導入した。

これらの数字は別々のものを測る。14 kHzは符号化音声の帯域幅、16または32 kHzはRTPタイムスタンプのサンプリングクロック、24・32・48 kbit/sはコーデックのビットレートだ。RFC 5577はそれらをひとつの「音質」つまみにまとめない。セッションのシグナリングで、使える組み合わせを特定する。

コーデックのビットストリームには、ビットレートが変わったことを帯域内で知らせる仕組みがない。そのためRFC 5577は別のシグナリングを必須とし、同じRTPペイロードタイプのビットレートを一定に保つよう定めた。アプリケーションはパケットごとに設定を切り替えられるが、その場合は異なるペイロードタイプを割り当てる。SDPのa=rtpmapが符号化方式とクロックレートを、a=fmtpがビットレートを示す。両者で、受信側に提示する設定が決まる。

Offer/Answerの手順では、その宣言が重要になる。RFC 5577は、送信側が使う意図のある設定をすべてofferに含めるよう求めた。さらに互換性の境界を明記する。RFC 3047が支えていたのは16 kHzだけなので、旧端末との相互運用を望むシステムは16 kHzのペイロードタイプも提示すべきだ。例では16 kHz/24 kbit/sと32 kHz/48 kbit/sを別々のペイロードタイプに割り当てている。

これは、どの旧端末も問題なく交渉できたという意味ではないし、新設定が自動的に旧設定へ戻るわけでもない。offerは対応可能な選択肢を示すだけで、相手の応答や、音声が聴き手まで届いたことの証明ではない。受信端末は自らが扱える設定を選び、その後のセッションも合意したプロファイルに沿わなければならない。RFC 5577は互換性経路を残したが、誰が実際に使ったかまでは示さない。

パケット構成にも別の境界が残る。フレーム長は引き続き20ミリ秒だ。標準レートでは1フレームは60、80、120オクテットとなる。連続する複数フレームを1パケットにまとめてもよいが、同じビットレートとクロックレートでなければならず、フレームをパケット間で分割してはならない。ペイロード自体にフレーム数の欄はなく、受信側は総オクテット数をフレーム当たりの期待値で割って数を求める。遅延が重要な電話用途には少ないフレーム数を、遅延に敏感でないストリーミングやメッセージングには多い数を勧める。万能の遅延値は規定しなかった。

移行の記録として読むと、RFC 5577の主題は「新しいコーデックが旧版を追い出した」ではない。選択肢を明示したままにすることだ。Obsoletesの行が置き換えたのは仕様文書であり、16 kHzのofferは旧来の互換性境界を選択肢に残す。どちらの記述からも、各設定を実装した端末の数は分からない。

参考資料