show call active voice コマンドを使用した音声品質問題のトラブルシューティング
内容
概要
このドキュメントでは、show call active voice（登録ユーザ専用）コマンド出力を説明し、音声品質の問題がコマンド出力で解決されるしくみを示しています。
注：このドキュメントで参照されているコマンドは、Command Lookup Tool(登録ユーザ専用)にリンクされています。 このツールを使用して、特定のコマンドの情報を検索します。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
表記法
ドキュメント表記の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
show call active voice コマンドの出力
show call active voice コマンドを使用すると、アクティブ コール テーブルの内容が表示されます。表示される情報には、通話時間、ダイヤルピア、接続、サービス パラメータ品質、およびジッタのゲートウェイ処理などがあります。この情報は、さまざまな音声品質の問題のトラブルシューティングに役立つ可能性があります。
このドキュメントにある表には、show call active voice コマンドの出力と各パラメータの簡単な説明が含まれます。
注：show call active voiceコマンドは、音声ゲートウェイ上のPlain Old Telephone Service（POTS；一般電話サービス）およびVoIPコールレッグからのデータを表示します。一部のパラメータは太字で強調表示されており、ドキュメントの後半で詳しく説明されています。
show call active コマンドは、すべてのアクティブ コールのテレフォニーと VoIP レッグの両方の値を表示します。各レッグに対して、同一の汎用パラメータが表示され、その後にコール レッグの種類によって異なるパラメータが表示されます。次の表では、これらのパラメータのセクションがグレーのヘッダーによって示されています。
進行中の音声コールのコール情報を表示するには、ユーザ EXEC モードまたは特権 EXEC モードで show call active voice コマンドを使用します。
show call active voice [brief [id identifier] | compact [duration {less time | more time}] | echo-canceller call-id | id identifier | redirect {rtpvt | tbct}]
このコマンドには、多くの引数のオプションがあります。次のリストでは、より便利な引数をいくつか説明します。
-
brief：（オプション）末尾を切り捨てたバージョンを表示します。
-
compact：（オプション）指定した時間より長い、または短いアクティブ コールを表示します。
-
duration：（オプション）指定した時間より長い、または短いアクティブ コールを表示します。
-
echo-canceller call-id：（オプション）拡張エコー キャンセラ（EC）の状態に関する情報を表示します。 エコーの状態を照会するには、16 進数の ID を事前に知っている必要があります。16 進数の ID を調べるには、show call active voice brief コマンドを入力するか、show voice call status コマンドを使用します。範囲は 0 ～ FFFFFFFF です。
| 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 コール レッグの場合は、Q931 コールの 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 = ファクス、2 = 音声）。 この場合は、音声コールです。 |
| TransmitPackets=37291 | デジタル信号プロセッサ（DSP）からテレフォニー インターフェイスに送信されるパケットの数。 |
| TransmitBytes=725552 | POTS TransmitPackets の値に相当するバイト数。 |
| ReceivePackets=1689 | DSP がテレフォニー インターフェイスから受信したパケットの数。 |
| ReceiveBytes=33780 | POTS ReceivePackets の値に相当するバイト数。 |
| TELE: | POTS コール レッグ |
| ConnectionId=[0xC59FE183 0xB1700D7 0x0 0x84431C] | これは、一意にこのコールを表すためにゲートウェイが与える接続識別番号です。該当するゲートウェイ上のコールの全コール レッグにおいて一致します。 |
| TxDuration=746070 ms | コールの継続時間（ミリ秒）= 12 分 26 秒 = 746 秒 = 746070 ミリ秒 |
| VoiceTxDuration=33780 ms | 音声パケットがテレフォニー POTS ピアから VoIP ゲートウェイに送信される際の累積時間（ミリ秒）。 |
| FaxTxDuration=0 ms | ルータがファクス モードのときの累積時間（ミリ秒）。 |
| CoderTypeRate=g729r8 | コールに使用されるコーデック。 |
| NoiseLevel=-59 | 対象となるコールのアクティブなノイズ レベル。この値はコンフォート ノイズ生成モジュールで計算され、Voice Activitiy Detection（VAD; 音声アクティビティ検出）が有効な場合にコンフォート ノイズを生成するために使用されます。 |
| ACOMLevel=20 | 対象となるコールの現在の ACOM レベル。ACOM は、エコー キャンセラによって実現される複合損失です。この値は、コールの Echo Return Loss（ERL; エコー リターン ロス）、Echo Return Loss Enhancement（ERLE; エコー リターン ロス拡張）、および Non-Linear Processing（NLP; 非線形処理）損失の合計です。 |
| OutSignalLevel=-64 | デシベル/ミリワット（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 SET UP メッセージを送信した時間になります。 |
| 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 の値に相当するバイト数。これは、テレフォニー コール レッグからの VoiceTxDuration に一致する必要があります。G.729 では、1 バイトが 1 ミリ秒ごとに送信されるためです。 |
| ReceivePackets=37343 | 対象となるコール レッグ上のゲートウェイで受信された VoIP パケットの数。 |
| ReceiveBytes=746860 | VoIP ReceivePackets の値に相当するバイト数。 |
| VoIP： | VoIP コール レッグ |
| ConnectionId[0xC59FE183 0xB1700D7 0x0 0x84431C] | これは、一意にこのコールを表すためにゲートウェイが与える接続識別番号です。該当するゲートウェイ上のコールの全コール レッグにおいて一致します。 |
| RemoteIPAddress=10.1.1.2 | コールのリモート IP アドレス。 |
| RemoteUDPPort=18280 | コールのリモート ユーザ データグラム プロトコル（UDP）ポート。 |
| RoundTripDelay=53 ms | ゲートウェイで測定されたラウンドトリップ遅延。 |
| SelectedQoS=best-effort | 対象となるコールに対して、ダイヤルピアでリソース予約プロトコル（RSVP）が選択されません。 |
| tx_DtmfRelay=cisco-rtp | コールに対して使用される DTMF RELAY 形式（存在する場合）。 |
| SessionProtocol=cisco | コールのセッション プロトコル。デフォルトは、プロトコル「cisco」で、音声トラフィックに対して H.323 シグナリングと RTP パケットが使用されます。Session Initiation Protocol(SIP)は、session protocol (登録ユーザ専用)ダイヤルピアコマンドを使用して指定できる、もう1つのVoIPシグナリングプロトコルです。VoATM 向け AAL2、シスコ独自の Voice over Frame Relay（VoFR）プロトコル、VoFR 向け FRFll などの非 VoIP プロトコルも指定できます。 |
| SessionTarget=ipv4:10.1.1.2 | ダイヤル ピアからのセッション ターゲット。ゲートキーパーを使用した場合、セッション ターゲットは RAS です。 |
| OnTimeRvPlayout=742740 | 対象となるコールに対して、時間通りに受信したデータからの音声再生の持続時間（ミリ秒）。音声再生の合計時間は、OnTimeRvPlayout の長さに、音声のとぎれの時間を加算すると得られます。 |
| GapFillWithSilence=0 ms | ゲートウェイ（GW）が無音を再生している時間（ミリ秒）。次の状況では、無音で再生されます。
|
| GapFillWithPrediction=0 ms | パラメータから、またはそれより前のデータのサンプルから合成された信号で再生された音声信号の持続時間（ミリ秒単位）。音声データが失われた場合、または対象となるコールに対する音声ゲートウェイからのデータ受信が間に合わなかったために、このようなとぎれが発生します。こうしたプルアウトの例が、G.729 および G.723.1 圧縮アルゴリズムにおけるフレーム消去方式やフレーム隠蔽方式です。 |
| GapFillWithInterpolation=0 ms | GapFillWithPrediction と同様ですが、損失した音声トラフィック後に受信し、デジッター バッファに保存されているサンプルを考慮します。現在は非サポート.。 |
| GapFillWithRedundancy=0 ms | トランスミッタにより冗長エンコーディング スキームが使用されている場合、損失したペイロードや受信が間に合わなかったパケットの一部または全部を復旧し、音声品質に対する影響を軽減した上で再生することができます。この技法は、現在ではサポートされていません。 |
| HiWaterPlayoutDelay=70 ms | 対象となるコールに合わせてデジッター バッファが調整する最大長を示す先入れ先出し（FIFO）ジッター バッファの上限マーク。 |
| LoWaterPlayoutDelay=69 ms | 対象となるコールに合わせてデジッター バッファが調整する最小長を示す FIFO ジッター バッファの下限マーク。 |
| ReceiveDelay=69 ms | 現在の再生 FIFO 遅延と、コールに対するデコーダの遅延を加算した時間。 |
| LostPackets=0 ms | ミリ秒で表現された、失われた RTP パケット。シーケンス番号での正のジャンプはすべて、LostPackets カウンタに追加されます。たとえば、ゲートウェイが、N-1、N、N+1、N+3、N+2、N+4 という順序で連番のパケットを受信すると、LostPackets のカウンタが増分されます。デジッター バッファのサイズ。「失われた」パケットを着信すると、それが再生可能かどうかを判断します。 |
| EarlyPackets=1 ms | ミリ秒単位で表される早期RTPパケットの数。RTP パケットは送信時にタイムスタンプが付加され、パケットに RTP タイムスタンプ値が組み込まれます。パケットを受信した時間は、ゲートウェイのローカル クロックによっても記録されます。2 個の隣接パケットのローカル クロック時間の差（受信時刻）が、RTP タイムスタンプの差（送信時刻）より小さい場合は、2 番目のパケットが早いと見なされます。早期パケットは、ネットワーク使用率が突然低下すると、発生する可能性があります。これにより、特定のパケットのネットワーク遅延が小さくなります。 |
| LatePackets=0 ms | 遅延 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 転送などのネットワーク設定に関する情報と組み合わせ、必要に応じて圧縮 RTP 使用すると、このダイヤル ピアに一致するコールのコール単位の帯域幅要件を特定できます。詳細については、『VoIP - コール単位の帯域幅の使用量』を参照してください。
プロビジョニングされた帯域幅が足りないためにコール数をサポートできない場合は、音声がとぎれたり、合成された音声に聞こえたりすることがあります。
注：コマンドcall thresholdは、コールアドミッション制御の方法の1つとして使用できますが、このコマンドはISDNインターフェイスからH323ネットワークへの発信コールでは機能しません。
コール レッグの特性が適正でないように思われる場合は、ご使用のダイヤルピア設定とマッチングを見直してください。詳細については、コール ルーティング/ダイヤル プランのテクニカル サポート ページにリストされているダイヤル ピアの関連資料を参照してください。
不明瞭な音声
不明瞭な音声の一般的な例は、音声のとぎれや合成された音声ですが、数多くの条件の下で発生します。これは、通常、WAN リンクが正しくプロビジョニングされていないことに関連しています。これは、適切な接続アドミッション制御（CAC）がない、または音声の優先順位が正しく設定されていないことが原因である可能性があります。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 コマンドは、音声再生の合計時間と比較した場合のコールの状態の概要を示します。音声再生の合計時間は、OnTimeRvPlayout の長さに、音声のとぎれの時間を加算すると得られます。オン タイムの音声再生時間の比率が高い場合、そのコールは健全な状態である可能性が高くなります。
パケット ネットワーク内でパケットのドロップや大幅な遅延が発生すると、音声品質の問題が発生することがあります。
大幅に遅延したために使用できなくなったパケットを受信した場合や、パケットがネットワーク内でドロップされたために受信されなかった場合、IP Phone または音声ゲートウェイは、音声信号を予測して、音声ストリームを可能な限り再構築しようとします。
次の問題について調べるには、IOS ゲートウェイで show call active voice コマンドを繰り返し実行します。
-
LatePackets：デジッター バッファの再生遅延時間外に着信したパケットの数。こうしたパケットは破棄されます。
-
LostPackets：受信 IP Phone またはゲートウェイに着信しなかったパケットの数。
-
GapFillWithPrediction：コールでのパケット予測の量。この数字をパケット サンプル時間で除算すると、影響されるパケットの数が分かります。
-
GapFillWithSilence：コール内に挿入された無音の量。
注：Catalystゲートウェイでshow port voice activeコマンドを使用すると、コールのジッタ(Hi/Low water playout delay)が表示されます。ただし、プレディクティブと無音挿入は区別されません。
-
挿入される予測量が小さい場合は、人間の耳で聞き分けることはできません。ただし、量が多いと、合成された音声やロボットのような音声に聞こえる不明瞭な音声になります。
-
パケットがドロップしたり、遅れて着信したりすると、受信側のコーデック デコーダで、音声信号を予測することができません。この場合、信号の代わりに、音声に無音が挿入されます。
さらに、遅延が可変（ジッター）の場合、遅延していても、受信側のデジッター バッファの再生可能な遅延期間内に着信したパケットは再生されます。ただし、デジッター バッファでアンダーランが発生する可能性があります。アンダーランは、保持されているパケットがなくなり、バッファが次のパケットの着信を待っているために音声が遅延している場合に発生します。その結果、音声がとぎれる可能性があります。
挿入される無音が少量の場合、もしくはジッタは、人間の耳で聞き分けることはできません。ただし、量が多いと、とぎれとぎれや不明瞭に聞こえるなど、低品質の音声になります。
注：ネットワーク遅延が十分に変動する場合は、音声の結果として生じる音が合成され、途切れる可能性があります。
不明瞭な音声の問題の解決
遅延の原因を特定し、（可能であれば）その原因を排除します。
パケット テレフォニー ネットワーク内のパケットのドロップや遅延の原因は、多数かつ多様である場合があります。一般的な例には、次のものがあります。
-
低速リンクに対して不適切に設定されたフラグメンテーション
-
不適切に設定されたトラフィック シェーピング、フレーム リレー CIR（登録ユーザ専用）超過、またはその両方
-
コールのパス内で、帯域幅の使用量が大きいリンク。音声コールに関して低品質な CAC など。その一例は、64 Kbps リンクで、cRTP も VAD もない G.711 コールです。
-
イーサネット環境におけるデュプレックスのミスマッチ
-
コールのパス内のルータで CPU に負担がかかる操作。たとえば、コンソールのデバッグやルータ設定の保存を実行すると、CPU の使用率が高くなり、CPU を通過する転送パケットの遅延が発生する場合があります。
最適とはいえないデータ ネットワークで音声性能を向上させるため、ゲートウェイのデジッタ バッファを調整することも可能です。ただし、結果は、データが正しく動作する程度に限定されます。詳細については、「QoS 音声とぎれの問題のトラブルシューティング」、または音声品質テクニカル サポートのページに掲載されているさまざまな文書を参照してください。
ヒス ノイズ、スタティック ノイズ、クリッピング ノイズ
次のパラメータは、対象となるコールに VAD が使用されているかどうかと、どのダイヤル ピアが使用されているかを特定します。
-
VAD = enabled
-
PeerId=200
-
NoiseLevel=-59
ヒス ノイズとクリッピング ノイズの問題の解決
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
次のパラメータは、エコーのトラブルシューティングの場合に重要です。
-
ACOMLevel=20
-
OutSignalLevel=-64
-
InSignalLevel=-58
-
ERLLevel=20
テスト トーンの出力は -15 で、0 dB の損失でループバックされます。したがって、-15 dB で戻ります。この時点では、ERL の値は重要性を持ちません。これは、エコー キャンセラでは入力信号がエコーと見なされないためです。
注：OutSignalLevelは、出力減衰が信号に適用された後のレベルの値を示します。InSignalLevel は、入力ゲインが適用された後のレベルの値を示します。
ERL 値が低すぎると、ゲートウェイに返されるエコー信号の音が大きくなりすぎる場合があります（送話者信号で 6 dB 以内）。 この場合、エコー キャンセラは、この信号をエコーではなく音声（ダブルトーク）と見なします。したがって、エコー キャンセラはエコーをキャンセルしません。エコー キャンセラが機能するには、ERL が 6 ～ 20 dB であることが必要です。
エコーの問題のトラブルシューティングに関する情報については、「IP Phone と Cisco IOS ゲートウェイの間のエコーの問題のトラブルシューティング」と「IP テレフォニー ネットワーク（オーディオ オン デマンド）のエコーのトラブルシューティング」を参照してください。
ジッタおよび一般的な音声品質の症状
このセクションでは、show call active voice コマンドを使用して、ジッターおよび標準的な音声品質の症状を特定する方法について説明します。
ネットワークでのジッターの一般的な考え方は、コールの進行中に show call active voice コマンドを繰り返し実行することによって決定されます。理想的には、これらのパラメータは比較的安定している必要があります。これが安定していることは、スムーズなパケットの流れを示しています。ところがジッタがあると、次の 2 つのサンプル出力に示すように、これらのパラメータの値に短時間での急上昇が確認されます。
GapFillWithSilence=950 ms GapFillWithPrediction=1980 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms HiWaterPlayoutDelay=350 ms LoWaterPlayoutDelay=25 ms ReceiveDelay=29 ms LostPackets=0 EarlyPackets=0 LatePackets=83
. . GapFillWithSilence=1040 ms GapFillWithPrediction=2350 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms HiWaterPlayoutDelay=40 ms LoWaterPlayoutDelay=28 ms ReceiveDelay=35 ms LostPackets=0 EarlyPackets=0 LatePackets=99
これらのサンプル出力での遅延パケット数の上昇は、ジッタの程度を表しています。GapFillWithSilence 値の増加によって示される無音の挿入は、音声のとぎれとして現れます。GapFillWithPrediction 値の増加によって示される予測の挿入は、合成されたような音声として現れます。
ジッター バッファのアンダーランまたはオーバーランを回避するためにバッファされる音声信号の量を変更するには、playout-delay コマンドを実行します。
再生遅延の設定の 2 つのモードは adaptive と fixed です。
-
adaptive では、コールの継続中に playout-delay {nominal value |最大値 | minimum {default | low | high}}コマンド。
-
fixed は、playout-delay mode {adaptive | fixed [no-timestamps]}コマンド。
VoIP の詳細については、「再生遅延の機能拡張」を参照してください。
関連情報
- 音声品質問題の症例の認識と分類
- TAC Case Collection：音声品質のトラブルシューティングのサポート（登録ユーザ専用）
- Voice over IP：コールあたりの帯域幅使用量
- ヒス ノイズとスタティック ノイズのトラブルシューティング
- IP Phone と Cisco IOS ゲートウェイ間のエコー障害のトラブルシューティング
- IP テレフォニー ネットワーク（オーディオ オン デマンド）における echo 問題のトラブルシューティング
- 音声に関する技術サポート
- 音声とユニファイド コミュニケーションに関する製品サポート
- Cisco IP Telephony のトラブルシューティング
- テクニカル サポートとドキュメント – Cisco Systems
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
31-Jul-2006 |
初版 |
フィードバック