音声技術の基礎｜第18回
管理画面の「損失」「ジッター」「遅延」は、同じ単位に見えても定義が異なることがあります。この記事では、RTP・RTCPとWebRTCの統計を読む際に、方向、単位、測定期間をそろえる方法を説明します。数値だけで原因を断定せず、音声と照合することが前提です。
1. RTPはデータ、RTCPは受信状況などの報告
RTPは音声データの伝送を担い、RTCPは受信状況などの情報を交換します。RTCPの報告を読むときは、誰がどのストリームの受信状態を報告しているかを確認します。
Aの管理画面に表示されていても、その値がAの受信状態なのか、相手Bから報告されたA→B方向の状態なのかは項目によります。送信・受信というラベルの基準点を固定してください。
2. 累積値は差分で区間を切り出す
累積カウンターは通話の開始から増える値です。障害が起きた10秒間を調べるなら、その前後の値の差を使います。ただし、カウンターのリセットやストリームの切り替えをまたがないことが条件です。
例えば同一区間で期待されたパケットが500個増え、損失が5個増えたなら、単純化した区間損失率は5÷500＝1％です。実装上の損失計算には遅着・重複などの扱いがあるため、異なる統計を無条件にこの式へ代入しないでください。
損失の増加を解釈する際は、パケットロスと連続損失の読み方で、平均率と発生パターンを分けて確認してください。
3. ジッターは単位を確認して変換する
RTCPのinterarrival jitterはRTPタイムスタンプの単位で表されます。仮に値が80、RTPクロックが8,000 Hzなら、80÷8,000＝0.01秒、すなわち10 msです。これは換算例で、良否の基準ではありません。
WebRTCのjitterは秒で表されます。同じ「80」という数字でも単位によって意味は全く異なります。またG.722のようにRTPクロックと標本化周波数が異なる方式もあるため、変換にはRTPのクロックを使います。
4. バッファの待ち時間と補償を合わせて見る
WebRTCの受信音声統計には、jitterBufferDelayやjitterBufferEmittedCountなどがあります。同じ受信ストリームの2時点の差から、区間平均のバッファ待ち時間を求められます。
平均待ち時間＝jitterBufferDelayの増分÷jitterBufferEmittedCountの増分
音声では、前者は各サンプルの滞留時間を合計した秒数、後者は出力したサンプル数です。例えば増分が9,600秒と480,000サンプルなら平均は0.02秒＝20 msです。9,600秒をそのまま通話遅延と読まないでください。分母が0の区間では計算しません。
concealedSamplesは、欠落や遅着などに対して補ったサンプル数を見る手掛かりです。ネットワーク損失率と補償の比率は同じ指標ではありません。ブラウザーによる項目の対応状況も確認します。
受信後の処理については、ジッターバッファの待ち時間と補償も併せて確認します。
5. 変化を時系列で関連づける
損失が増えた後に補償が増えたのか、ネットワーク統計は変わらず音量だけ落ちたのかを見ます。別々の時間範囲の最大値を並べるだけでは、同時に起きたことは証明できません。
通話開始からの平均が良くても、数秒だけ大きく悪化している場合があります。短い区間の推移と、聞き取りにくかった時刻を照合します。統計の取得間隔自体も記録してください。
6. 報告書に残す最小項目
- 通話とストリームの識別子、方向、観測位置。
- コーデック、RTPクロック、統計の単位。
- 開始・終了時刻、累積値か区間値か。
- 音声の症状と、同じ時刻の統計の変化。
異なる製品の表示を比較するときは、同じ名前という理由で数値を横並びにせず、定義を合わせます。測れない項目はゼロとせず、未取得として区別してください。
観測した指標を運用上の調査へつなぐには、ResolveAXの品質指標を調査に生かす方法も参考になります。
参考規格・資料
端末・接続環境・通話時刻と症状から観測範囲を整理する際は、ResolveAXによるエージェント環境の品質分析をご覧ください。担当者環境の通話品質調査を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。