要約

  • César Díazが2026年8月26日にLACNICのブログで公表した解説は、音声の符号化量とは別にヘッダーと制御データが必要だと明記している。新たな運用規則の発表ではない。
  • 連続する片方向のモノラル音声を20 msずつ送るモデルでは、8 kbit/sのG.729は基本IPv4/UDP/RTPヘッダー込みで24 kbit/s、IPv6では32 kbit/sになる。
  • 同じ間隔なら、符号化量が減っても毎秒50パケットの処理は残る。送信間隔を長くする節約には、遅延と損失時の影響という代償がある。

回線が受け取るのは音声だけではない

20ミリ秒ごとに一つ送れば、1秒で50個になる。この時計は、各パケットに多くの音声データを詰めても、少なく詰めても変わらない。IP電話の帯域を考えるとき、コーデックの数字と並べておくべき数字である。

LACNICの8月26日の記事で、César Díazは回線交換からIPへの移行を説明している。G.711の64 kbit/sに対し、より少ないデータで音声を表す方式を紹介し、共通のネットワークを使う利点を示した。ただし、ヘッダーと制御データを加える必要があるとも述べている。この注意書きを誤りとして扱う必要はない。設計の見積もりまで持ち運ぶことが重要だ。

G.729を例に取る。RFC 3551では、10ミリ秒の音声が10バイトのフレームになり、標準のパケット化間隔では二つをまとめる。したがって20 ms分の音声は20バイト、連続送信なら毎秒50パケットになる。これは条件を置いた計算であり、LACNIC会員の装置や採用方式を調べた結果ではない。

基本のRTPヘッダーは12バイト、UDPは8バイト、IPv4の最小ヘッダーは20バイトある。音声20バイトに40バイトが加わり、IPパケットは60バイトになる。毎秒50個、1バイト8ビットなので、合計は24 kbit/sだ。

8 kbit/sという音声の値と矛盾しない。どこまでを数えたかが違う。

削減率をそのまま設備の余裕にしない

次の表は連続した片方向モノラル音声について、20 ms間隔、非圧縮の基本RTP/UDP/IPヘッダー、オプションや拡張なしで計算したものだ。IPv6の基本ヘッダーは40バイトなので、その場合も分けて示す。実測値ではない。

方式 音声のみ 毎秒のパケット数 IPv4パケット全体 IPv6パケット全体
G.711 64 kbit/s 50 80 kbit/s 88 kbit/s
G.729 8 kbit/s 50 24 kbit/s 32 kbit/s

音声の符号化量は8分の1になった。一方、このIPv4モデルの全体量は80から24、約3.33分の1である。パケット数は毎秒50個のままだ。バイト数の減少だけで、パケットごとの処理負担も同じ割合で減ったとは判断できない。特定装置の性能を示す表でもない。

IPv6との違いは、この条件では20バイトを毎秒50回送る分、8 kbit/sになる。IPv6の導入全体の費用や価値を、この一項目から評価することはできない。

また、表に含めていないものがある。シグナリング、RTCP、セキュリティ上の追加部分、トンネル、リンク層のフレーム、冗長化、設計余裕などだ。無音区間の送信抑制を使えば、実際の送信パターンも変わる。通話は双方向であり、片方向の計算を通話全体の帯域と呼ぶのも不適切である。

アプリケーションが数える音声量と、ネットワーク側が数えるIPパケット量は一致しなくてよい。差を障害と判断する前に、観測する層と方向をそろえたい。

長くまとめると、待つ時間も生まれる

ヘッダーの回数を減らす方法はある。同じG.729と基本IPv4ヘッダーの条件なら、10 msごとの送信は40 kbit/s、20 msなら24、40 msなら16になる。符号化レートを変更しなくても、まとめ方で総量は変わる。

ただし、送る前により長い音声をためる必要がある。パケットを失えば、そこに含まれた長い区間も一度に失われる。RFC 3551は、長いパケット化間隔がヘッダー負担を減らす一方、遅延と損失の知覚への影響を増すと説明している。安くなる条件だけで適切な値は選べない。

RTPの時刻や順序の情報も、定刻どおりの配送を保証しない。仕様を満たすこと、計算上の帯域が収まること、利用者が十分な品質で話せることは別々に確かめる必要がある。

LACNICの記事は、この検討の出発点として読める。地域全体の混雑を示した記事でも、特定コーデックの推奨でもない。そこで示された効率化を具体的な契約や装置設定に移す際、何を数え、何を除いた数字なのかを残すことが実務上の要点になる。