音声技術の基礎｜第4回
IP電話では、声を一続きの信号として回線に流し続けるのではなく、小さなデータのまとまりに分けて送ります。このまとまりがパケットです。音声のデジタル化から一歩進めて、RTPとUDPが何を担当し、受信側でどう再生するかを見ていきます。
1. 音声を短い時間ごとにまとめる
まずコーデックで符号化した音声を、一定の時間分まとめます。例えば20 ms分を1パケットに格納するなら、連続送信時は1秒間に50パケットです。20 msは説明例であり、すべての通話で固定された値ではありません。
G.711の音声データは64,000 bit/sなので、20 ms分は64,000 × 0.02 ÷ 8＝160バイトです。この160バイトに、順序や送信先などを扱う情報が付加されます。
2. RTP・UDP・IPは別の役割を持つ
| 層・形式 | 主な役割 |
|---|---|
| 音声ペイロード | コーデックで符号化した音声そのもの |
| RTP | 順序や音声の時間関係を扱う情報 |
| UDP | ポートを使ってデータグラムを受け渡す |
| IP | IPアドレスに基づく配送 |
一般的なVoIPではRTPをUDP上で運びます。RTPにはシーケンス番号やタイムスタンプがあり、受信側が欠落や時間関係を判断する助けになります。ただしRTP自体が、パケットの到着や遅延上限を保証するわけではありません。
UDPは、失われたデータを自動的に再送して順番どおりにそろえる機能を持ちません。音声では再生時刻を過ぎたデータを待ち続けるより、欠落を補いながら会話を続ける判断が必要になります。
3. パケット番号と音声の時刻を分ける
シーケンス番号はパケットの順序を表します。一方、RTPタイムスタンプは音声の時間関係を表し、その単位はコーデックのRTPクロックに従います。パケット数と標本数は同じものではありません。
G.711・20 msの連続送信例では、パケットの番号が1つ進む間に、タイムスタンプは160進みます。これは8,000 × 0.02＝160によります。番号の初期値は固定ではなく、無音抑圧や方式の違いもあるため、この例をすべてのRTPへ当てはめないでください。
4. 受信側では、到着した順にすぐ再生するわけではない
ネットワークではパケットの間隔が揺れたり、順番が入れ替わったりします。受信側はジッターバッファに一時的にため、音声の時間関係に沿って再生します。間に合わない部分にはPLCなどの欠落補償を使う場合があります。
ここには遅延との交換関係があります。長く待てば遅れて届くパケットを使える可能性は高まりますが、相手への応答も遅くなります。受信処理を含めて観察しないと、「パケットは届いているのに音が途切れる」状況を見落とします。
5. パケット化間隔を変えると何が変わるか
間隔を短くすると1パケットの音声量は減りますが、毎秒のパケット数とヘッダーの合計は増えます。長くするとその逆になり、1パケットを失ったときに欠ける音声時間も長くなります。音声をためる時間も変わるため、帯域だけで設定を決めないことが大切です。
例えば20 ms分をまとめたパケットが3個連続で失われれば、60 ms分の音声データが欠けます。これはデータ上の時間で、実際にどう聞こえるかは発話内容や補償処理によって変わります。
6. ログで確認する項目
- 使用コーデックとRTPクロックを特定する。
- シーケンス番号、タイムスタンプ、到着時刻を区別して見る。
- 送受信の方向別に欠落・並べ替え・再生の統計を確認する。
- 取得装置自身の取りこぼしがないか確かめる。
暗号化された音声では内容をそのまま聞けない場合があります。端末やサービスが提供する統計を組み合わせ、通信の観測結果と実際の聞こえ方を照合します。
参考規格・資料
CCアーキテクトでは、コンタクトセンターの音声品質評価や試験項目の整理についてご相談いただけます。音声品質・試験に関するお問い合わせ