音声の損失または歪み
症状
発生する可能性のある最も一般的な問題の 1 つに、音声信号の途切れがあります(これは、「音声が聞き取りにくい」、「単語や文の中の音節が脱落する」などとよく言われる問題です)。この問題の一般的な原因は、パケット損失とジッタの 2 つです。どちらか 1 つまたは両方が原因になる場合があります。パケット損失とは、音声パケットがドロップされたため、または到達が遅すぎて無効になったために、音声パケットが宛先に到達しないことを意味します。ジッタは、パケットの到達時間のばらつきを示します。最適的な状況では、すべての Voice over IP(VoIP)パケットが正確に 20 ミリ秒(ms)に 1 個の割合で到達します。ジッタは、パケットがポイント A からポイント B に到達する所要時間ではなく、単に、パケット到達時間のばらつきであることに注意してください。
考えられる原因
ネットワークには、遅延のばらつきの原因が数多く存在します。それらの原因の中は、制御できるものとできないものがあります。パケット音声ネットワークにおける遅延のばらつきを完全になくすことはできません。電話機などの音声対応デバイス上の Digital Signal Processors(DSP; デジタル信号プロセッサ)は、遅延のばらつきを想定して音声の一部を計画的にバッファリングします。このデジッタリングは、音声パケットが宛先に到達し、通常の音声ストリームに使用される準備が整った場合に限り実行されます。
Cisco IP Phone 7960 は、1 秒間の音声サンプルをバッファリングできます。ジッタ バッファは状況に応じて使用されます。つまり、一度に大量のパケットが受信された場合、Cisco IP Phone 7960 はジッタを制御するためにそれらのパケットを再生することができます。ネットワーク管理者は、quality of service(QoS; サービス品質)などの手段をあらかじめ適用することで、パケット到達時間のばらつきを最小化する必要があります(この作業は、コールが WAN を経由する場合は特に重要です)。
ビデオ エンドポイントの中には、G.728 をサポートしていないものもあります。そのため、G.728 を使用するとノイズが発生することがあります。そのような場合には、G.729 など、別のコーデックを使用してください。
推奨処置
1. 音声の損失または歪みの問題が発生した場合は、最初に、その音声のパスを割り出す必要があります。そのコールの音声ストリームのパスにある各ネットワーク デバイス(スイッチおよびルータ)を特定します。音声は、2 台の電話機間、電話機とゲートウェイ間、または複数の区間(電話機からトランスコーディング デバイスまでの区間、およびそのトランスコーディング デバイスから別の電話機までの区間)に存在する場合があることに留意してください。問題が発生しているのは、2 つのサイト間だけか、特定のゲートウェイを介した場合だけか、特定のサブネット上か、などを特定します。このような作業によって、さらに詳しく調べる必要があるデバイスの範囲を絞り込むことができます。
2. 次に、無音抑止(Voice Activation Detection または VAD とも呼ばれます)を無効にします。このメカニズムは、無音がある場合に音声を送信しないようにすることで帯域幅を節約しますが、単語の最初の部分で顕著な(容認できない)音飛びが発生する原因となる場合があります。
Cisco CallManager Administration でこのサービスを無効にし、 Service > Service Parameters を選択します。表示されたメニューで、サーバと Cisco CallManager サービスを選択します。
3. Cisco CallManager クラスタ内のすべてのデバイスに対して無音抑止を無効にするには、SilenceSuppression を False に設定します。または、SilenceSuppressionForGateways を False に設定する方法もあります。判断に迷う場合は、それぞれ False を選択して、両方ともオフにします。
4. ネットワーク アナライザが使用可能な場合には、ネットワーク アナライザを使用して、無音抑止が無効の状態で 2 台の電話機間の監視対象コールに 1 秒あたり 50 パケット(20 ミリ秒あたり 1 パケット)が存在するかどうかを確認します。適切なフィルタリングを行うことで、極端に多くのパケットが失われていないか、または遅延していないかを確認できます。
音飛びの原因となるのは遅延そのものではなく、遅延のばらつきだけです。下記の表に注目してください。この表は、20 ミリ秒の音声パケット(RTP ヘッダーを含む)間の到達時間に関する完全なトレースを表しています。低品質のコール(多くのジッタが含まれるコールなど)の場合、到達時間は大きく変動します。
次の表は、完全なトレースを示しています。
|
|
|
1 |
0 |
|
2 |
0.02 |
20 |
3 |
0.04 |
20 |
4 |
0.06 |
20 |
5 |
0.08 |
20 |
パケット アナライザをネットワーク内のさまざまなポイントに配置すると、遅延が発生する場所の数を絞り込むのに役立ちます。使用可能なアナライザがない場合は、他の方法を使用する必要があります。音声のパスにある各デバイスのインターフェイス統計情報を調べてください。
診断に使用する Call Detail Record(CDR)には、低音質のコールの追跡に役立つ別のツールが指定されています。CDR の詳細については、『 Cisco CallManager Serviceability アドミニストレーション ガイド 』を参照してください。
Cisco IP Phone による音声問題の解決
症状
音声問題はコールの進行中に発生します。
考えられる原因
デバイスでは高速インターフェイスが低速インターフェイスに送り込まれるため、デバイスが遅延とパケット損失の最も一般的な原因になります。たとえば、ルータによっては、LAN に接続された 100 メガバイト(MB)のファースト イーサネット インターフェイスと WAN に接続された低速フレームリレー インターフェイスを持っている場合があります。リモート サイトに通信しているときにだけ音声品質が低下する場合は、その問題の最も可能性の高い原因としては、次のようなことが挙げられます。
–データ トラフィックより音声トラフィックが優先されるようにルータが正しく設定されていない。
–アクティブ コールの数が多すぎて WAN がサポートできない(つまり、発信可能なコール数を制限するコール アドミッション制御がない)。
–物理ポートのエラーが発生している。
–WAN 自体で輻輳が発生している。
LAN 上の最も一般的な問題は、物理レベルのエラー(CRC エラーなど)です。これらのエラーは、ケーブルやインターフェイスの障害、またはデバイスの誤った設定(ポートの速度やデュプレックスの不一致など)が原因で発生します。トラフィックがハブなどのシェアドメディア デバイスを通過していないことを確認してください。
推奨処置
Cisco IP Phone 7960 には、発生する可能性のある音声問題を診断するためのツールが別途用意されています。
1. アクティブ コールに対して、 i ボタンをすばやく 2 回押すと、電話機の情報画面に、パケットの送受信に関する統計情報、平均ジッタ カウンタ、および最大ジッタ カウンタが表示されます。
(注) この画面で、ジッタは最後に到達した 5 パケットの平均値を表し、最大ジッタは平均ジッタの最大値を表します。
2. トラフィックが予想よりも遅いパスでネットワークを通過するという状況が発生することもあります。QoS が正しく設定されているのであれば、コール アドミッション制御が実行されていない可能性があります。アドミッション制御を実行するには、トポロジに応じて、Cisco CallManager Administration 設定の Locations を使用するか、または Cisco IOS ルータをゲートキーパーとして使用します。いずれの場合も、WAN 全体でサポートされる最大コール数を常に認識しておく必要があります。
クラックル ノイズの診断
3. クラックル ノイズ(パチパチという音)も音声品質の低下を示す症状の 1 つです。これは、電源装置の欠陥や電話機周辺の何らかの強い電気的干渉が原因になる場合があります。電源装置を交換し、電話機を移動してください。
ロードの確認
4. ゲートウェイと電話機のロードを確認します。www.cisco.com の Cisco Connection Online(CCO)で、最新のソフトウェアのロード、新しいパッチ、または問題に関連するリリース ノートがあるかどうかを確認します。
確認
1. 音声の損失または歪みの説明に従って無音抑止を無効にしてテストを行います。次に、2 つのサイト間で通話します。パケットが送信されなくなるので、コールを保留または消音にしないでください。
2. WAN を経由するコールの最大数が設定されていれば、すべてのコールは許容できる品質になります。
3. コールをもう 1 件発信しようとしたときに、速いビジー音が返ってくることを確認するテストを行います。
エコー
症状
エコーが発生するのは、生成された音声エネルギーがプライマリ信号パスに伝送され、遠端の受信パスに連結されたときです。このとき、送話者には、エコー パスの合計遅延時間の分だけ遅れて自分の声が聞こえます。
音声は反響することがあります。従来の音声ネットワークでは、反響しても遅延が小さいので認識されません。ユーザにとっては、エコーというよりも側音のように聞こえます。VoIP ネットワークでは、パケット化と圧縮により遅延が大きくなるため、常にエコーは明確に認識されます。
考えられる原因
エコーの原因は必ずアナログ コンポーネントと配線にあります。たとえば、IP パケットは、低い音声レベルのソースまたはデジタル T1/E1 回線上のソースに方向を変えて戻ることができません。例外となる可能性があるのは、一方がスピーカフォンを使用して音量を極端に高く設定している場合など、音声ループが生成されるような状況が発生している場合だけです。
推奨処置
1. 問題の電話機でスピーカフォンが使用されていないこと、およびヘッドセットの音量が適切なレベル(最大音声レベルの 50 パーセントから開始する)に設定されていることを確認します。ほとんどの場合、この問題は、デジタル ゲートウェイまたはアナログ ゲートウェイを経由して PSTN に接続しているときに発生します。
ゲートウェイのテスト
2. 使用されているゲートウェイを判別します。デジタル ゲートウェイが使用されている場合、送信方向に(PSTN に向かって)パディングを追加できます。信号の強度を低下させると反響するエネルギーが減少するので、この方法で問題を解決できます。
これに加えて、受信レベルを調整することで、反響音をさらに小さくすることもできます。1 回の調整は微量にすることが重要です。信号の減衰量が大きすぎると、コールの両側で音声が聞こえなくなります。
3. 通信事業者に連絡して、回線の確認を依頼する方法もあります。北米で一般的な T1/PRI 回線の場合、入力信号は -15 dB である必要があります。信号レベルがそれよりも大幅に高い(たとえば -5 dB)場合は、エコーが発生する可能性があります。
エコー ログの記録
4. エコーが発生したすべてのコールのログを記録する必要があります。
問題が発生した時刻、発信側の電話番号、および着信側の電話番号を記録します。ゲートウェイのエコー キャンセレーションは固定で 16 ミリ秒に設定されています。
反響音の遅延がこれよりも大きい場合、エコー キャンセラは正常に動作できません。正常に動作できなくても、市内電話については問題ありませんが、長距離電話の場合は、セントラル オフィスでネットワークに組み込まれた外部エコー キャンセラを使用する必要があります。この事実は、エコーが発生するコールの外部電話番号を記録することが重要である理由の 1 つです。
ロードの確認
5. ゲートウェイと電話機のロードを確認します。www.cisco.com の Cisco Connection Online で、最新のソフトウェアのロード、新しいパッチ、または問題に関連するリリース ノートがあるかどうかを確認します。
単方向音声または無音声
症状
IP ステーションから Cisco IOS 音声ゲートウェイまたはルータを介してコールを確立すると、一方の側しか音声を受信しません(単方向通信)。
2 つの Cisco ゲートウェイ間でトールバイパス コールを確立すると、一方の側しか音声を受信しません(単方向通信)。
考えられる原因
この問題が発生する可能性があるのは、特に、Cisco IOS Gateway、ファイアウォール、またはルーティングの設定が正しくない場合、またはデフォルト ゲートウェイに問題がある場合です。
推奨処置
Cisco IOS ゲートウェイまたはルータで IP ルーティングが有効になっていることを確認する
VG200 など、Cisco IOS ゲートウェイの中には、IP ルーティングがデフォルトで無効になっているものがあります。これが原因で単方向音声の問題が発生します。
(注) 作業を進める前に、ルータの IP ルーティングが有効になっている(つまり、ルータにグローバル設定コマンド no ip routing が設定されていない)ことを確認してください。
IP ルーティングを有効にするには、Cisco IOS ゲートウェイで次のグローバル設定コマンドを入力するだけです。
voice-ios-gwy(config)#ip routing
基本 IP ルーティングの確認
基本 IP の到達可能性は、必ず最初に確認する必要があります。RTP ストリームは UDP で転送されるコネクションレス型なので、トラフィックは一方向には正常に進みますが、反対方向には正常に進みません。
次の点を確認してください。
–エンド ステーションにデフォルト ゲートウェイが設定されている。
–そのデフォルト ゲートウェイの IP ルートが宛先ネットワークに通じている。
(注) 各種 Cisco IP Phone のデフォルト ルータまたはゲートウェイの設定を検証する方法を次に示します。
–Cisco IP Phone 7910: Settings を押し、オプション 6 を選択してから、Default Router フィールドが表示されるまで下向きの音量キーを押します。
–Cisco IP Phone 7960/40: Settings を押し、オプション 3 を選択してから、Default Router フィールドが表示されるまで下方向にスクロールします。
–Cisco IP Phone 2sp+/30vip: **# を押してから、gtwy= が表示されるまで # を押します。
(注) Cisco IP SoftPhone アプリケーションを使用していて、複数の Network Interface Card(NIC; ネットワーク インターフェイス カード)がボックスにインストールされている場合は、ボックスに正しい NIC が設定されていることを確認してください。この問題は、Cisco IP SoftPhone ソフトウェア バージョン 1.1.x に共通する問題です(バージョン 1.2 では解決します)。
(注) Cisco DT24+ Gateway の場合は、DHCP Scope を確認し、スコープ内に Default Gateway (003 router) オプションがあることを確認してください。003 router パラメータは、デバイスと PC の Default Gateway フィールドに読み込まれるものです。スコープ オプション 3 には、ゲートウェイ用のルーティングを実行するルータ インターフェイスの IP アドレスが指定されている必要があります。
H.323 シグナリングを Cisco IOS ゲートウェイまたはルータ上の特定の IP アドレスにバインドする
Cisco IOS ゲートウェイにアクティブな IP インターフェイスが複数ある場合、H.323 シグナリングの一部は 1 つの IP アドレスから調達され、その他の部分は別の送信元アドレスを参照することがあります。この結果、さまざまな問題が発生します。その 1 つが単方向音声です。
この問題を回避するには、H.323 シグナリングを特定の送信元アドレスにバインドします。この送信元アドレスは、物理インターフェイスまたは仮想インターフェイスに属すことができます(ループバック)。インターフェイス設定モードで使用するコマンド構文は、
h323-gateway voip bind srcaddr<ip address> です。Cisco CallManager が指す IP アドレスを持つインターフェイスでこのコマンドを設定します。
このコマンドは Cisco IOS Release 12.1.2T で導入され、『Configuring H.323 Support for Virtual Interfaces』で文書化されています。
(注) バージョン 12.2(6) にはバグが存在するため、このソリューションでは単方向音声の問題が発生する可能性があります。詳細については、Cisco Software Bug Toolkit(登録済みのお客様専用)でバグ ID CSCdw69681(登録済みのお客様専用)を参照してください。
Telco または交換機から応答監視が正しく送受信されていることを確認する
Telco または交換機に接続された Cisco IOS ゲートウェイが含まれる実装では、Telco または交換機の内側にある着信側デバイスがコールに応答するときに、応答監視が正しく送信されていることを確認します。応答監視の受信に失敗すると、Cisco IOS ゲートウェイは順方向の音声パスをカットスルー(オープン)できず、単方向音声となります。回避方法は、 voice rtp send-recv on を設定することです。
Cisco IOS ゲートウェイまたはルータで voice rtp send-recv を使用し、双方向音声を早期にカットスルーする
RTP ストリームが開始されるとすぐに、逆方向の音声パスが確立されます。順方向の音声パスは、Cisco IOS ゲートウェイが Connect メッセージをリモート エンドから受信するまでカットスルーされません。
場合によっては、RTP チャネルが開いたらすぐに(Connect メッセージが受信される前に)双方向の音声パスを確立する必要があります。これを実現するには、 voice rtp send-recv グローバル設定コマンドを使用します。
Cisco IOS ゲートウェイまたはルータのリンクバイリンク ベースの cRTP 設定を確認する
この問題は、複数の Cisco IOS ルータまたはゲートウェイが音声パスに関与していて、Compressed RTP(cRTP; 圧縮 RTP)が使用されている、トールバイパスなどのシナリオに該当します。cRTP、つまり RTP ヘッダー圧縮機能は、VoIP パケットのヘッダーを小さくして帯域幅を取り戻すための方法です。cRTP では、VoIP パケット上に 40 バイトの IP/UDP/RTP ヘッダーを設定し、それを 1 パケットにつき 2 ~ 4 バイトに圧縮するので、G.729 で符号化されたコールの場合、cRTP 使用時に約 12 KB の帯域幅が得られます。
cRTP はホップバイホップ ベースで実行され、すべてのホップで圧縮解除と再圧縮が行われます。ルーティングするには各パケット ヘッダーを検査する必要があるので、IP リンクの両端で cRTP を有効にする必要があります。
リンクの両端で cRTP が期待どおりに機能していることを確認することも重要です。各 Cisco IOS レベルは、スイッチング パスと同時 cRTP サポートによって異なります。
履歴の要約を次に示します。
–Cisco IOS Software Release 12.0.5T まで、cRTP はプロセス交換されます。
–Cisco IOS Software Release 12.0.7T では、cRTP に対するファースト スイッチングと Cisco Express Forwarding(CEF; Cisco エクスプレス転送)スイッチングのサポートが導入され、12.1.1T でも引き続きサポートされています。
–Cisco IOS Software Release 12.1.2T では、アルゴリズムのパフォーマンスが向上しています。
Cisco IOS プラットフォーム(IOS Release 12.1)上で cRTP を実行している場合は、バグ CSCds08210(登録済みのお客様専用)(VoIP and FAX not working with RTP header compression ON)がご使用の IOS バージョンに影響しないことを確認します。
Cisco IOS ゲートウェイまたはルータ上の NAT に必要な最低限のソフトウェア レベルを確認する
Network Address Translation(NAT; ネットワーク アドレス変換)を使用している場合は、最低限のソフトウェア レベルを満たす必要があります。以前のバージョンの NAT は Skinny プロトコル変換をサポートしないので、単方向音声の問題が発生します。
NAT と Skinny を同時に使用するために必要な最低限のソフトウェア レベルは、Cisco IOS® Software 12.1(5)T です。IOS ゲートウェイが NAT を使用して Skinny と H.323v2 をサポートするには、このレベルのソフトウェアが必要です。
(注) Cisco CallManager が Skinny シグナリング用にデフォルトの 2000 と異なる TCP ポートを使用している場合は、ip nat service skinny tcp port<number> グローバル設定コマンドを使用して NAT ルータを調整する必要があります。
PIX ファイアウォール上で NAT と Skinny を同時に使用するために必要な最低限のソフトウェア レベルは 6.0 です。
(注) これらのレベルのソフトウェアが、ゲートキーパーのフル サポートに必要なすべての RAS メッセージをサポートするわけではありません。ゲートキーパーのサポートについては、この文書では取り上げません。
AS5350 および AS5400 の voice-fastpath を無効にする
Cisco IOS コマンド voice-fastpath enable は、AS5350 および AS5400 用の非表示のグローバル設定コマンドを取得します。これは、デフォルトで有効になっています。これを無効にするには、 no voice-fastpath enable グローバル設定コマンドを使用します。
有効になっていると、このコマンドは特定のコール用に開いている論理チャネルの IP アドレスと UDP ポート番号の情報をキャッシュします。それによって RTP ストリームはアプリケーション層に到達できなくなり、それより下位の層にパケットが転送されます。そのため、大量のコールがあるシナリオでは CPU 使用率がわずかに抑えられます。
保留や転送などの補助的なサービスを使用している場合、voice-fastpath コマンドを使用すると、ルータは保留されたコールの再開後または転送の完了後に収集された新しい論理チャネルの情報を無視して、キャッシュされている IP アドレスと UDP ポートに音声を送信します。この問題を回避するには、論理チャネルの再定義を考慮して、音声が新しい IP アドレスと UDP ポートのペアに送信されるように、トラフィックを常にアプリケーション層に到達させる必要があります。そのため、補助的なサービスをサポートするには voice-fastpath を無効にする必要があります。
VPN IP アドレスを SoftPhone に設定する
Cisco IP SoftPhone を使用すると、PC を Cisco IP Phone 7900 シリーズの電話機のように使用できます。リモート ユーザが VPN を経由して自社のネットワークに接続し直す場合は、単方向音声の問題を回避するために、いくつかの追加設定を行う必要があります。
解決策は、Network Audio Settings でネットワーク アダプタの IP アドレスの代わりに VPN IP アドレスを設定することです。
確認
パケット フローを確認するには、コマンド debug cch323 rtp が便利です。このコマンドは、ルータが送信したパケット(X)と受信したパケット(R)を表示します。大文字は正常な送信または受信を示し、小文字はドロップされたパケットを示します。次の例を参照してください。
voice-ios-gwy#debug cch323 rtp
RTP packet tracing is enabled
!--- This is an unanswered outgoing call.
!--- Notice that voice path only cuts through in forward
!--- direction and that packets are dropped. Indeed,
!--- received packets are traffic from the IP phone to the PSTN
!--- phone. These will be dropped until the call is answered.
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
!--- This is an example of an answered call:
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
!-- At this point the remote end picks up the phone.
*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR