音声 : 音声品質

show call active voice コマンドを使用した音声品質問題のトラブルシューティング

2003 年 6 月 25 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 7 月 31 日) | フィードバック

目次

概要
はじめに
     表記法
     前提条件
     使用するコンポーネント
show call active voice コマンドの出力
音声品質問題をトラブルシューティングするためのコマンド出力の使用
     ダイヤルピアのマッチングと帯域幅の使用量
     不明瞭な音声
     ヒス ノイズ、スタティック ノイズ、クリッピング ノイズ
     Echo
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

本書では、show call active voice登録ユーザ専用)コマンドの出力について説明し、 音声品質問題を解決する場合に、どのように役に立つかを解説します。

注:本書で参照されているコマンドは、IOS コマンド検索ツール登録ユーザ専用)にリンクされています。. このツールを使うと、特定のコマンドに関する詳細情報が入手できます。そのためには、登録ユーザであることが必要なのでご注意ください。

はじめに

表記法

文書表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。

前提条件

この文書に関する特別な前提条件はありません。

使用するコンポーネント

この文書は特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

show call active voice コマンドの出力

show call active voice コマンドを使用すると、アクティブ コール テーブルの内容が表示されます。表示される情報には、通話時間、ダイヤルピア、接続、サービス パラメータ品質、およびジッタのゲートウェイ処理などがあります。この情報はさまざまな音声品質問題をトラブルシューティングするために、特に役に立ちます。

次のテーブルには、サンプルの show call active voice コマンドによる出力と、各パラメータの簡単な説明が記載されています。

注:show call active voice コマンドは、Plain Old Telephone Service(POTS; 一般電話サービス)からのデータと、音声ゲートウェイ上の Voice over IP(VoIP)コール レッグを表示します。次のセクションでは、詳細を説明するために一部のパラメータは太字で強調されています。

show call active コマンドは、全てのアクティブ コールのテレフォニーと VoIP レッグの両方の値を表示します。各レッグに対して、同一の汎用パラメータが表示され、その後にコール レッグの種類によって異なるパラメータが表示されます。次のテーブルでは、これらのパラメータ セクションは、太字の見出しによって示されています。

show call active voice パラメータ

パラメータの説明

汎用:

後続の POTS コール レッグの一般的な状態

SetupTime=866793 ms

POTS レッグが開始された場合のクロック時間(100 ミリ秒単位で増分)。着信 ISDN POTS コールの場合、Q.931 SETUP メッセージを受信した時間になります。

Index=1

 

PeerAddress=100

対象となる POTS ピアと一致する着信先パターン。着信 POTS コール レッグの場合は、発信元番号、または Automatic Number Identification(ANI; 自動番号識別)です。

PeerSubAddress=

 

PeerId=100

対象となるコール レッグに対して使用されるダイヤル ピア ID。この場合は不要ですが、PeerID と PeerAddress は同じになります。

PeerIfIndex=9

対象となるピアの音声ポート インデックス番号。ISDN メディアの場合は、対象となるコールに対して使用される B チャネルのインデックス番号になります。

LogicalIfIndex=5

対象となるコールに対する論理インターフェイスを識別するために内部的に使用されるインデックス。

ConnectTime=867030

POTS レッグが接続された場合のクロック時間(100 ミリ秒単位で増分)。着信 ISDN POTS コールレッグの場合は、Q.931 CONNECT メッセージが送信された場合の時間になります。

CallDuration=00:12:26

コールが確立された時刻(hh:mm:ss 形式で表示)。

CallState=4

コールレッグのコールの状態(4 = アクティブ、3 = 接続済み、2 = 接続中) コールの状態はアクティブです。

CallOrigin=2

コール レッグの発信と応答(1 = 発信、2 = 応答)。このゲートウェイは、対象となる(POTS)コール レッグに応答しました。

ChargedUnits=0

システム起動時以降、対象となるピアに適用される課金単位の総数。このフィールドの測定単位は 100 分の 1 秒。

InfoType=2

対象となるコールの情報タイプ(1 = FAX、2 = 音声)。この場合は、音声コールです。

TransmitPackets=37291

Digital Signal Processor(DSP; デジタル信号プロセッサ)から電話インターフェイスへ送信されるパケット数。

TransmitBytes=725552

POTS TransmitPackets と同じ値のバイト数。

ReceivePackets=1689

DSP が電話インターフェイスから受信したパケット数。

ReceiveBytes=54048

POTS ReceivePacketsPackets と同じ値のバイト数。

TELE:

POTS コール レッグ

ConnectionId=[0xC59FE183 0xB1700D7 0x0 0x84431C]

対象となるコールを一意に表現するためにゲートウェイにより指定された接続識別番号。該当するゲートウェイ上のコールの全コール レッグで一致します。

TxDuration=746070 ms

コールの継続時間(ミリ秒) = 12 分 26 秒 = 746 秒 = 746070 ミリ秒

VoiceTxDuration=33780 ms

DSP により音声パケットが電話インターフェイスに送信された累積時間(ミリ秒)。VoiceTxDuration の値を TxDuration の値で除算することによって、音声使用率が取得できます。

FaxTxDuration=0 ms

ルータが FAX モードになっている累積時間(ミリ秒)。

CoderTypeRate=g729r8

コールに使用されるコーデック。

NoiseLevel=-59

対象となるコールのアクティブ ノイズ レベル。この値は comfort-noise 生成モジュールで計算され、Voice Activitiy Detection(VAD; 音声アクティビティ検出)が有効な場合に、 comfort-noise を生成するために使用されます。

ACOMLevel=20

対象となるコールの現在の ACOM レベル。ACOM は、エコー キャンセラによって実現される複合損失です。この値は、コールの Echo Return Loss(ERL; エコー リターン ロス)、Echo Return Loss Enhancement(ERLE; エコー リターン ロス拡張)、および Non-Linear Processing(NLP; 非線形処理)損失の合計です。

OutSignalLevel=-64

Decibels Per Milliwatt(dBm)で表された出力信号レベル。

InSignalLevel=-58

入力信号レベル(dBm)。

InfoActivity=2

対象となるコールのアクティブ情報転送アクティビティ状態。

ERLLevel=20

対象となるコールの ERL。

SessionTarget=

この値は VoIP コール レッグに適用されます。この値は、VoIP ダイヤルピアで指定されます。POTS コール レッグに対するセッション ターゲットはありません。

ImgPages=0

 
   

汎用:

後続の VoIP コール レッグに対する汎用統計:

SetupTime=866928 ms

VoIP コール レッグが開始された場合のクロック時間(100 ミリ秒単位で増分)。発信 H.323 VoIP コールの場合、H.323 SETUP メッセージを送信した時間になります。

Index=1

 

PeerAddress=200

ピアの宛先パターン。発信 VoIP コール レッグの場合、これがコール番号、または Dialed Number Identification Service(DNIS; 着信番号情報サービス)になります。

PeerSubAddress=

 

PeerId=200

DNIS と一致する PeerID。この場合は不要ですが、PeerID と DNIS は同じになります。

PeerIfIndex=11

 

LogicalIfIndex=0

 

ConnectTime=867029

VoIP レッグが接続された場合のクロック時間(100 ミリ秒単位で増分)。発信 H.323 VoIP コール レッグの場合、H.323 CONNECT メッセージを受信した時間になります。

CallDuration=00:12:27

コールの継続時間(hh:mm:ss 形式で表示)。

CallState=4

コール レッグのコールの状態(4 = アクティブ、3 = 接続済み、2 = 接続中) コールの状態はアクティブです。

CallOrigin=1

コール レッグの発信と応答(1 = 発信、2 = 応答)。このゲートウェイは、対象となる(VoIP)コール レッグを発信しました。

ChargedUnits=0

 

InfoType=2

 

TransmitPackets=1689

対象となるコール レッグ上のゲートウェイから送信された VoIP パケット数。

TransmitBytes=33780

VoIP TransmitPackets と同じ値のバイト数。この値は、G.729 以降のテレフォニー コール レッグからの VoiceTxDuration と一致します。1 ミリ秒ごと に 1 バイトが送信されます。

ReceivePackets=37343

対象となるコール レッグ上のゲートウェイで受信された VoIP パケット数。

ReceiveBytes=746860

VoIP ReceivePackets と同じ値のバイト数。

VoIP:

VoIP コール レッグ

ConnectionId[0xC59FE183 0xB1700D7 0x0 0x84431C]

対象となるコールを一意に表現するためにゲートウェイにより指定された接続識別番号。該当するゲートウェイ上のコールの全コール レッグにおいて一致します。

RemoteIPAddress=10.1.1.2

該当するコールのリモート IP アドレス。

RemoteUDPPort=18280

コールのリモート User Datagram Protocol(UDP; ユーザ データグラム プロトコル)ポート。

RoundTripDelay=53 ms

ゲートウェイによって測定されたラウンドトリップ 遅延。

SelectedQoS=best-effort

対象となるコールに対して、ダイヤルピアで Resource Reservation Protocol(RSVP; リソース予約プロトコル)が選択されていません。

tx_DtmfRelay=cisco-rtp

コールに対して使用される DTMF RELAY 形式(存在する場合)。

SessionProtocol=cisco

コールのセッション プロトコル。デフォルトは、プロトコル "cisco" で、音声トラフィックに対して H.323 シグナリングと RTP パケットが使用されます。Session Intitiation Protocol(SIP; セッション開始プロトコル)は、セッション プロトコル登録ユーザ専用)ダイアル ピア コマンドを使って指定可能なもう 1 つの VoIP 信号プロトコルです。VoATM 用の AAL2、Cisco 独自の Voice over Frame Relay(VoFR)プロトコルや FRFll for VoFR などの非 VoIP プロトコルも指定可能です。

SessionTarget=ipv4:10.1.1.2

ダイヤルピアからのセッション ターゲット。ゲートキーパーを使用した場合、セッション ターゲットは RAS です。

OnTimeRvPlayout=742740

対象となるコールに対して、時間通りに受信したデータからの音声再生の持続時間(ミリ秒)。この場合、コールの持続時間(TxDuration=746070 ms)と比較すると、ほとんどのバイトが時間通りに再生されていることに注意してください。アクティブな音声に対する音声再生総時間は、OnTimeRvPlayout の値を GapFill の値に加算することで得られます。

GapFillWithSilence=0 ms

ゲートウェイ(GW)が無音を再生している時間(ミリ秒)。無音は、次の状況で再生されます。

  • パケットの損失が発生し、再生できるオーディオ サンプルが存在しない場合。たとえば、複数のパケットが連続して失われた場合などです。このような状況により、雑音や音声のとぎれをユーザが耳にすることがあります。

  • バッファに蓄積された音声パケット間に無音を挿入することによって、再生バッファをより大きな値に適用させている場合。この状況では、感知できる音声の損失は発生しません。

GapFillWithPrediction=0 ms

パラメータ、または音声信号に先立って受信されたデータ サンプルから合成された信号を使って再生された音声信号の持続時間(ミリ秒)。音声データが失われた場合、または対象となるコールに対する音声ゲートウェイからのデータ受信が間に合わなかったために、このようなとぎれが発生します。こうしたプルアウトの例が、G.729 および G.723.1 圧縮アルゴリズムにおけるフレーム消去方式やフレーム隠蔽方式です。

GapFillWithInterpolation=0 ms

GapFillWithPrediction と同様ですが、損失した音声トラフィック後に受信したサンプル、およびデジッタ バッファに保存されているサンプルを考慮します。現在は非サポート.。

GapFillWithRedundancy=0 ms

トランスミッタにより冗長エンコーディング スキームが使用されている場合、損失したペイロードや受信が間に合わなかったパケットの一部または全部を復旧し、音声品質に対する影響を軽減した上で再生することができます。この技法は、現在ではサポートされていません。

HiWaterPlayoutDelay=70 ms

対象となるコールに対して適用されるデジッタ バッファの最大長を示す、First-In, First-Out(FIFO; 先入れ先出し)ジッタ バッファの上限マーク。

LoWaterPlayoutDelay=69 ms

対象となるコールに対して適用されるデジッタ バッファの最短長を示す、FIFO ジッタ バッファの下限マーク。

ReceiveDelay=69 ms

現在の再生 FIFO ディレイに、コールに対するデコーダ 遅延を加えたもの。

LostPackets=0 ms

損失した RTP パケットを「ミリ秒」で表したもの。予測された RTP シーケンス番号が付いたパケットを受信しなかった場合、この値は増分されます。

EarlyPackets=1 ms

早期 RTP パケット数を「ミリ秒」で表したもの。RTP パケットは送信時にタイムスタンプが付加され、パケットに RTP タイムスタンプ値が組み込まれます。パケット受信時刻もゲートウェイのローカル クロックによって記録されます。

2 個の隣接するパケット間のローカル クロックの時差(受信時刻)が、RTP タイムスタンプ(送信時刻)の時差より小さい場合、2 番目のパケットは早期パケットと見なされます。

早期パケットは、ネットワークの使用率が突然下がった場合に発生することがあり、特定のパケットに対するネットワーク 遅延が小さくなります。

LatePackets=0 ms

遅延 RTP パケット数を「ミリ秒」で表したもの。次のいずれかの状況で、RTP シーケンス番号が付いたパケットを受信すると、この値は増分されます。

  • RTP シーケンス番号が、現在再生中のパケットの RTP シーケンス番号よりも早期のものである場合。

  • RTP シーケンス番号が、現在再生中のパケットよりも後のものであっても、使用可能な再生バッファ内にない場合。

VAD = enabled

対象となるコール レッグに対して、VAD が有効。

CoderTypeRate=g729r8

対象となるコールに対して使用されるコーデック タイプ。

CodecBytes=20

使用コーデックのペイロード サイズ(バイト)。

SignalingType=cas

コールのシグナリング タイプ。相手先固定のコール専用。

音声品質問題をトラブルシューティングするためのコマンド出力の使用

このセクションでは、前掲のテーブルで強調表示したパラメータの音声品質に対する影響について説明します。

ダイヤルピアのマッチングと帯域幅の使用量

次のパラメータにより、コールの特定の VoIP レッグに関連する情報が提供されます。この特定のコール レッグの例では、コールはダイヤルピア 200 と一致しています。使用コーデックは、ペイロード サイズが 20 バイトの G.729 で、VAD が有効です。

  • PeerId=200

  • CoderTypeRate=g729r8

  • CodecBytes=20

  • VAD = enabled

この情報をレイヤ 2 のプロトコル、および cRTP登録ユーザ専用)の使用有無など、ネットワーク設定に関する情報と組み合わせることで、対象となるダイヤルピアのコール単位に必要な帯域幅を知ることができます。 詳細は、「Voice over IP - コール単位の帯域幅の使用量」を参照してください。

以前の帯域幅がコール数をサポートするために不十分であった場合、音声が途切れたり合成されたような音声になることがあります。

コール レッグの特性が適正でないように思われる場合は、ご使用のダイヤルピア設定とマッチングを見直してください。詳細は、コール ルーティング/ダイヤル プラン テクニカル サポート ページに掲載されている、ダイヤルピアの関連ドキュメントを参照してください。

不明瞭な音声

不明瞭な音声(代表的な例は、音声の途切れや合成されたような音声など)は、通常、適切な Connection Admission Control(CAC; 接続アドミッション管理)の欠如や不適切に設定された音声の優先順位付けに起因する可能性が高いなどの WAN リンクの提供が不適切であることに関連するさまざまな状況下で発生します。show call active voice コマンドでは、次のパラメータを使って、こうした問題に関する情報を提供します。

  • OnTimeRvPlayout=742740

  • GapFillWithSilence=0 ms

  • GapFillWithPrediction=0 ms

  • HiWaterPlayoutDelay=70 ms

  • LoWaterPlayoutDelay=69 ms

  • ReceiveDelay=69 ms

  • LostPackets=0 ms

  • EarlyPackets=1 ms

  • LatePackets=0 ms

OnTimeRvPlayout コマンドは、TxDuration と比較した場合のコールの健全性に関する概要を提供します。オン タイムの音声再生時間の比率が高い場合、そのコールは健全な状態である可能性が高くなります。

パケット ネットワーク内でパケットのドロップや大幅なパケットの遅延が発生すると、音声品質問題が発生することがあります。

大幅に遅れたため使用できないパケットを受信したり、ネットワークでパケットのドロップが発生し、パケットをまったく受信できなかった場合、IP 電話や音声ゲートウェイでは、音声信号を予測して、最大限音声ストリームの再構築が図られます。

IOS ゲートウェイ 上で繰り返し show call active voice コマンドを発行すると、この問題が明らかになります。

  • LatePackets - デジッタ バッファ再生遅延期間を過ぎてから着信したパケット数。こうしたパケットは破棄されます。

  • LostPackets - 着信 IP 電話またはゲートウェイに着信しなかったパケット数。

  • GapFillWithPrediction - コール内のパケット予測量。この値をパケット サンプル時間で除算すると、影響を受けたパケット数が得られます。

  • GapFillWithSilence - コール内に挿入された無音の量。

注:Catalyst ゲートウェイ上で show port voice active コマンドを実行すると、パケット予測量と無音の挿入の違いは区別しませんが、コールに対するジッタ(Hi/Low water playout delay)を表示できます。

  • Synthetic Voice(合成音のような音声)

    挿入される予測量が小さい場合は、人間の耳で聞き分けることはできません。しかし予測量が増加すると、音声品質が不明瞭になる可能性が高くなり、合成音やロボットのような音声と言われるようになりかねません。

  • Choppy Voice(途切れる音声)

    パケットがドロップしたり、遅れて着信したりすると、受信側のコーデック デコーダで、音声信号を予測することができません。この場合、信号の代わりに、音声に無音が挿入されます。

    さらに遅延が可変(ジッタ)の場合、遅延は発生しても、受信側のデジッタ バッファの再生可能な遅延期間内に着信したパケットは再生はされますが、デジッタ バッファでアンダーランが発生する可能性があります。バッファに保持されているパケットがなく、次のパケットが着信するまで音声が待機状態となり遅延が発生すると、アンダーランが発生します。その結果、音声の音飛びが発生します。

    挿入される無音が少量の場合、もしくはジッタは、人間の耳で聞き分けることはできません。しかし無音の量が増加すると、音声品質が不明瞭になる可能性が高くなり、音声が途切れるとか、音声が中断すると言われかねません。

    注:ネットワーク遅延の変動が大きい場合、生成される音声は、途切れている上に、合成音のような音声になる可能性が高くなります。

不明瞭な音声問題の解決

遅延の原因を特定し、(可能であれば)その原因を排除します。

パケット電話ネットワーク内のパケットのドロップや遅延の原因が、複数存在し、多岐にわたる場合があります。一般的な例には、次のものがあります。

  • 低遅延キューイング(LLQ) の誤設定

  • 低速リンク用フラグメンテーション登録ユーザ専用)の誤設定

  • トラフィック シェーピング登録ユーザ専用)の誤設定およびフレーム リレー CIR登録ユーザ専用)の超過、もしはどちらか一方。

  • コールのパス内で、帯域幅の使用量が大きいリンク。音声コールに関して低品質な CAC など。簡単な例としては、64 Kbps リンクでの cRTP や VAD を使用しない G.711 コールがあります。

  • イーサネット環境におけるデュプレックスのミスマッチ。

  • コールのパス内のルータで CPU に負担がかかる操作。例えば、コンソールのデバッグやルータ設定の保存を実行すると、CPU の使用率が高くなり、転送パケットの遅延が発生します。

最適とはいえないデータ ネットワークで音声性能を向上させるため、ゲートウェイのデジッタ バッファを調整することも可能です。ただし最大限調整しても、データ ネット ワークの動作を適切にすることまでしかできません。詳細は、「QoS 途切れる音声問題のトラブルシューティング」、または「音声品質」テクニカル サポートのページに掲載されているさまざまな文書を参照してください。

ヒス ノイズ、スタティック ノイズ、クリッピング ノイズ

次のパラメータにより、対象のコールに対して VAD が使用されているかどうか、およびどのダイヤルピアが使用されているかが指定されます。

  • VAD = enabled

  • PeerId=200

  • NoiseLevel=-59

ヒス ノイズおよびクリッピング ノイズ問題の解決

ヒス ノイズおよびフロンエンドのクリッピング ノイズ問題を解決するには、他の潜在的な問題をトラブルシューティングする前に、music-threshold や vad-time の値を調整する(または VAD を無効にする)必要があります。

comfort-noise登録ユーザ専用)を無効にするか、VAD を完全に無効にしてみてください。症状が直った場合は、 comfort-noise の生成が問題の原因である可能性が高いと考えられます。音声を検知するレベルを決めるmusic-threshold登録ユーザ専用)の緩和や、vad-time登録ユーザ専用)の値を大きくゲートウェイ上で設定すると、VAD を常時に無効にしなくても、ヒス ノイズやクリッピング ノイズが目立たなくなります。これらの解決策では、基本的にはそれぞれ、低ボリューム レベル時、または音飛びが小さいうちに、VAD を無効にします。単に comfort-noise を無効するだけでは実際的ではありません。このような処置により、クリック ノイズやセンテンス間の完全無音ギャップなど、他の音声品質問題が引き起こされるためです。

詳細は、「ヒス ノイズとスタティック ノイズのトラブルシューティング」を参照してください。上記の調整技法によっても問題が解決しない場合は、VAD を無効にしてください。これにより、帯域幅節約の損失が発生します。

一方向で発生するヒス ノイズおよびクリッピング ノイズ問題の解決

VAD は、ほとんどのヒス ノイズの原因であるため、VAD が有効かどうかを確認することが重要です。ヒス ノイズ、またはセンテンスのフロントエンド クリッピング ノイズをトラブルシューティングするための最初の手順は、VAD を無効にすることです。したがって、VAD が実際に無効になっているかどうかを確実に確認することが重要です。

ヒス ノイズまたはクリッピングノイズが発信の方向の一方向でしか発生しない場合、VoIP ダイヤルピアで VAD を無効にしようとしたとしても、障害が発生する方向に対して VAD が有効になっているため、問題が発生する可能性が高いと考えられます。この場合、show call active voice コマンドにより、VAD が有効であり、使用中の PeerID が 0 であることが示されます。この問題を解決するには、VoIP ダイヤルピア上で incoming called-number<number_dialed>登録ユーザ専用コマンドを設定して、PSTN へのコールがゲートウェイでピアに一致するようにします。コマンドを設定しない場合、この方向のコールは、デフォルトで VAD が有効となるデフォルトのダイヤルピアに一致します。

Echo

次のパラメータは、echo をトラブルシューティングする場合に重要です。

  • ACOMLevel=20

  • OutSignalLevel=-64

  • InSignalLevel=-58

  • ERLLevel=20

echo 問題のトラブルシューティングについては、「echo 問題の理解とトラブルシューティング」、および「IP テレフォニー ネットワーク(オーディオ オン デマンド)における echo 問題のトラブルシューティング」を参照してください。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 40309