- このマニュアルについて
- トラブルシューティングの概要
- トラブルシューティング ツール
- インストール、バックアップ、 および復元の問題
- Cisco CallManager システムの 問題
- ディレクトリの問題
- デバイスの問題
- ダイヤル プランとルーティン グの問題
- Cisco CallManager サービスの 問題
- ボイス メッセージの問題
- TAC への問い合せ
- ケース スタディ：クラスタ内 コール のトラブルシューティング
- ケース スタディ：Cisco IP Phone と Cisco IOS Gateway 間の コールのトラブルシューティング
- ケース スタディ：クラスタ間 コールのトラブルシューティング
- 索引
Cisco CallManager トラブルシューティング ガイド Release 4.2(1)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： デバイスの問題
デバイスの問題
この章では、Cisco IP Phone、ゲートウェイ、および関連デバイスで発生する可能性のある、次のような一般的な問題について説明します。
•
音声品質
• 電話機の問題
音声品質
通話中に、音声信号の損失や歪みなど、音声品質の問題が発生することがあります。
一般的な問題としては、音声が途切れる（言葉が聞き取れないなど）、異常なノイズが入る、音声が歪む（エコーが聞こえるなど）、音声がこもったり合成音のようになったりする、といった問題があります。単方向音声（二者間でどちらか一方だけに音声が聞こえる会話）は、本来は音声品質の問題ではありませんが、この問題についてもこの章で取り上げます。
音声問題は、次のアイテムのいずれか 1 つまたは複数で発生する可能性があります。
• エコー
音声の損失または歪み
発生する可能性のある最も一般的な問題の 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 サービスを選択します（図 6-1 を参照）。
図 6-1 Cisco CallManager Administration の Service メニュー
3. Cisco CallManager クラスタ内のすべてのデバイスに対して無音抑止を無効にするには、 SilenceSuppression を False に設定します。または、SilenceSuppressionForGateways を False に設定する方法もあります。判断に迷う場合は、それぞれ False を選択して、両方ともオフにします。
4. ネットワーク アナライザが使用可能な場合には、ネットワーク アナライザを使用して、無音抑止が無効の状態で 2 台の電話機間の監視対象コールに 1 秒あたり 50 パケット（20 ミリ秒あたり 1 パケット）が存在するかどうかを確認します。適切なフィルタリングを行うことで、極端に多くのパケットが失われていないか、または遅延していないかを確認できます。
音飛びの原因となるのは遅延そのものではなく、遅延のばらつきだけです。下記の表に注目してください。この表は、20 ミリ秒の音声パケット（RTP ヘッダーを含む）間の到達時間に関する完全なトレースを表しています。低品質のコール（多くのジッタが含まれるコールなど）の場合、到達時間は大きく変動します。
|
|
|
|
|---|---|---|
パケット アナライザをネットワーク内のさまざまなポイントに配置すると、遅延が発生する場所の数を絞り込むのに役立ちます。使用可能なアナライザがない場合は、他の方法を使用する必要があります。音声のパスにある各デバイスのインターフェイス統計情報を調べてください。
診断に使用する Call Detail Record（CDR）には、低音質のコールの追跡に役立つ別のツールが指定されています。CDR の詳細については、『 Cisco CallManager Serviceability アドミニストレーション ガイド 』を参照してください。
Cisco IP Phone による音声問題の解決
デバイスでは高速インターフェイスが低速インターフェイスに送り込まれるため、デバイスが遅延とパケット損失の最も一般的な原因になります。たとえば、ルータによっては、LAN に接続された 100 メガバイト（MB）のファースト イーサネット インターフェイスと 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 の到達可能性は、必ず最初に確認する必要があります。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 を無効にする必要があります。
Cisco IP SoftPhone を使用すると、PC を Cisco IP Phone 7900 シリーズの電話機のように使用できます。リモート ユーザが VPN を経由して自社のネットワークに接続し直す場合は、単方向音声の問題を回避するために、いくつかの追加設定を行う必要があります。
解決策は、Network Audio Settings でネットワーク アダプタの IP アドレスの代わりに VPN IP アドレスを設定することです。
パケット フローを確認するには、コマンド debug cch323 rtp が便利です。このコマンドは、ルータが送信したパケット（X）と受信したパケット（R）を表示します。大文字は正常な送信または受信を示し、小文字はドロップされたパケットを示します。次の例を参照してください。
コーデックとリージョンの不一致
オフフックしたときにリオーダー音（話し中の音）が聞こえる場合は、リージョン間でコーデックが一致していないことが原因である可能性があります。コールの両端で少なくとも 1 つの共通のコーデック（たとえば、G.711）がサポートされていることを確認してください。共通のコーデックがサポートされていない場合は、トランスコーダーを使用する必要があります。
リージョンには、他の各リージョンとともに使用できる、サポートされているコーデックの種類が特定されています。すべてのデバイスはリージョンに属します。
（注） Cisco IOS ルータとのコーデック ネゴシエーションはサポートされていません。
たとえば、Region1<->Region2 = G.711 は、Region1 のデバイスと Region2 のデバイス間のコールで G.711 またはその他のサポートされている任意のコーデック（G.711、G.729、G.723 など、G.711 と同じかそれより小さい帯域幅を必要とするコーデック）を使用できることを意味しています。
（注） 各デバイス用にサポートされているコーデックを次に示します。
Cisco IP Phone 7960：G.711A-law/μ-law、 G.729、G729A、G.729Annex-B
Cisco IP Phone SP12 シリーズおよび VIP 30：G.711a-law/mu-law、G.723.1
Cisco Access Gateway DE30 および DT-24+：G.711a-law/mu-law、G.723.1
ロケーションと帯域幅
番号をダイヤルした後にリオーダー音が聞こえる場合は、いずれかのコール終端デバイスのロケーションに対する Cisco CallManager の帯域割り当てが超過していることが原因である可能性があります。Cisco CallManager は、コールを発信する前に、各デバイスで使用できる帯域幅があるかどうかを確認します。使用可能な帯域幅がない場合、Cisco CallManager はコールを発信しないので、ユーザにはリオーダー音が聞こえます。
12:42:09.017 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x4f1ad98
12:42:09.017 Cisco CallManager|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=, CalledParty=5005, tcpHandle=0x4f1ad98
12:42:09.017 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98
コールが確立されると、Cisco CallManager は、そのコールで使用されるコーデックに応じてロケーションから帯域幅を差し引きます。
• コールで G.711 が使用されている場合、Cisco CallManager は 80k を差し引きます。
電話機の問題
• 電話機のリセット
電話機のリセット
電話機の電源が切れて再投入されたり、電話機がリセットされたりする理由には、次の 2 つがあります。
–Cisco CallManager に接続する際に TCP エラーが発生した。
–電話機の KeepAlive メッセージに対する確認応答を受信する際にエラーが発生した。
1. 電話機とゲートウェイを調べて、最新のソフトウェア ロードを使用していることを確認します。
2. www.cisco.com の Cisco Connection Online で、最新のソフトウェアのロード、新しいパッチ、または問題に関連するリリース ノートがあるかどうかを確認します。
3. 電話機のリセットに関するインスタンスがあるかどうかを Event Viewer で確認します。電話機のリセットは Information イベントに相当します。
4. 電話機がリセットされた時刻の前後に発生した可能性のあるエラーを探します。
5. SDI トレースを開始し、リセットが発生している電話機に共通する特徴を見極めて、問題を特定します。たとえば、それらの電話機がすべて同じサブネットに配置されているかどうか、あるいは、同じ VLAN に配置されているかどうかなどを確認します。トレースを調べて次の点を確認します。
–リセットは通話中に発生するか、それとも断続的に発生するか。
–電話機モデル（Cisco IP Phone 7960 または Cisco IP Phone 30VIP など）に類似性があるかどうか。
6. 頻繁にリセットが発生する電話機上で Sniffer トレースを開始します。電話機がリセットされた後にトレースを調べて、TCP リトライが行われているかどうかを確認します。行われている場合は、ネットワークに問題があることを示しています。トレースを実行すると、たとえば、電話機のリセットが 7 日に 1 回発生しているなど、リセットの規則性が見いだされる場合があります。このことから、DHCP リースの有効期限が 7 日に 1 回の周期に設定されている可能性があります（この値はユーザが設定できます。たとえば、2 分に 1 回にすることもできます）。
ドロップされたコール
ドロップされたコールが早期異常終了する場合は、電話機またはゲートウェイのリセットが原因である可能性があります（「電話機のリセット」を参照）。または、PRI 設定の誤りなど、回線の問題が原因である可能性もあります。
1. この問題を 1 台の電話機または 1 つの電話機グループに特定できるかどうかを確認します。影響を受けている電話機はすべて特定のサブネットまたはロケーションに配置されていることもあります。
2. 電話機またはゲートウェイのリセットを Event Viewer で確認します。
リセットが発生する電話機ごとに、Warning メッセージと Error メッセージが 1 つずつ表示されます。これは、その電話機が Cisco CallManager への TCP 接続を維持できないために、Cisco CallManager が接続をリセットすることを示しています。このリセットは、電話機の電源をオフにしたため、またはネットワークに問題があるために発生することがあります。この問題が断続的に発生しているときは、Microsoft Performance を使用して電話機登録を記録すると役立つ場合があります。
3. 特定のゲートウェイ（Cisco Access DT-24+ など）を経由した場合にだけ問題が発生していると考えられる場合は、トレースを有効にするか、Call Detail Record（CDR）を確認するか、あるいはその両方を行います。CDR ファイルには、問題の原因を判別するのに役立つ Cause of Termination（CoT）が含まれています。CDR の詳細については、『 Cisco CallManager Serviceability アドミニストレーション ガイド 』を参照してください。
4. 接続解除の理由種別（コールを接続解除した側に応じて origCause_value および destCause_value）を見つけます。接続解除の理由種別は、次の場所にある Q.931 接続解除理由コード（10 進表記）に対応しています。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/dbook/disdn.htm
5. コールがゲートウェイから出て PSTN に向かう場合は、CDR を使用して、どちらの側がコールを切断したかを判別できます。Cisco CallManager でトレースを有効にすることにより、ほぼ同じ情報を入手できます。トレース ツールは Cisco CallManager のパフォーマンスに影響を与える可能性があるので、最後の手段として使用するか、またはネットワークが稼働していないときに使用してください。
ゲートウェイの問題
ゲートウェイのリオーダー音
ゲートウェイを経由するコールを発信する場合、制限されているコールを発信したり、ブロックされている番号にダイヤルしたりすると、リオーダー音が聞こえることがあります。リオーダー音は、ダイヤルした番号が使用不可になっている場合、または PSTN の機器やサービスに問題がある場合に発生することがあります。
リオーダー音を発しているデバイスが登録されていることを確認してください。また、ダイヤル プラン設定を調べて、コールが正常にルーティングされることも確認してください。
ゲートウェイを経由する場合のリオーダー音のトラブルシューティングを行う手順を次に示します。
1. ゲートウェイを調べて、最新のソフトウェア ロードを使用していることを確認します。
2. www.cisco.com の Cisco Connection Online で、最新のソフトウェアのロード、新しいパッチ、または問題に関連するリリース ノートがあるかどうかを確認します。
3. SDI トレースを開始し、問題を再現します。リオーダー音は、
Cisco CallManager が許容可能なコール数を制限する、ロケーション ベースのアドミッション制御またはゲートキーパー ベースのアドミッション制御に関する設定の問題が原因である可能性があります。SDI トレースでコールを特定して、ルート パターンやコーリング サーチ スペースなどの構成設定によってそのコールが意図的にブロックされたかどうかを判別します。
4. PSTN を経由する場合もリオーダー音が発生することがあります。SDI トレースで Q.931 メッセージがないかどうか確認します。特に接続解除メッセージに注意します。Q.931 の接続解除メッセージがある場合、接続解除の原因は相手側にあり、こちら側でそれを解決することはできません。
ゲートウェイの登録障害
この項では、ゲートウェイの 2 つのカテゴリについて説明します。これらのカテゴリは類似していますが、同一ではありません。Cisco Access AS-X、AT-X、Cisco Access DT-24+、および DE-30+ は同じカテゴリに属します。これらのゲートウェイは、Network Management Processor（NMP; ネットワーク管理プロセッサ）に直接接続されていないスタンドアロン ユニットです。もう 1 つのカテゴリには、Analog Access WS-X6624 および Digital Access WS-X6608 が含まれます。これらのゲートウェイは、Catalyst 6000 のシャーシに取り付けられたブレードとして、制御とステータス管理のために NMP に直接接続できます。
登録の問題は、Cisco CallManager に設定されたゲートウェイで発生する最も一般的な問題の 1 つです。
1. まず、ゲートウェイが稼働していることを確認します。すべてのゲートウェイにはハートビート LED が付属しており、ゲートウェイ ソフトウェアが正常に稼働している場合は 1 秒間隔で点滅します。
この LED がまったく点滅しない場合、または非常に速く点滅する場合、ゲートウェイ ソフトウェアは稼働していません。その結果、通常、ゲートウェイは自動的にリセットされます。また、約 2 ～ 3 分経過して登録プロセスを完了できない場合にも、通常、ゲートウェイは自動的にリセットされます。したがって、確認したときデバイスがたまたまリセット中である場合もありますが、10 ～ 15 秒後に通常の点滅パターンが示されない場合は、ゲートウェイに重大な障害があります。
Cisco Access Analog ゲートウェイでは、前面パネルの右端に緑色ハートビート LED があります。Cisco Access Digital ゲートウェイでは、カード上部の左端に赤色 LED があります。Cisco Analog Access WS-X6624 では、前面に近いカード右端にあるブレードの内部に緑色 LED があります（前面パネルからは見えません）。Digital Access WS-X6608 では、ブレード上の 8 スパンそれぞれに別個のハートビート LED があります。8 個の赤色 LED はカード上に並んでいます（前面パネルからは見えません）。これらの LED は、背面に向かって約 3 分の 2 進んだ位置にあります。
2. ゲートウェイが自分の IP アドレスを受信したことを確認します。スタンドアロン ゲートウェイは、自分の IP アドレスを DHCP または BOOTP を介して受信する必要があります。Catalyst ゲートウェイは、DHCP または BOOTP によって、あるいは NMP を介した手動設定によって自分の IP アドレスを受信できます。
3. DHCP サーバに対するアクセス権を持っている場合、スタンドアロン ゲートウェイを調べる最善の方法は、デバイスに未解決の IP アドレス リースがあるかどうかを確認することです。ゲートウェイがサーバ上に表示される場合、そのことは良い目安になりますが、決定的ではありません。DHCP サーバで、そのリースを削除します。
5. 数分以内にゲートウェイがリースとともにサーバ上に再び表示される場合、この領域の動作はすべて正常です。表示されない場合は、ゲートウェイが DHCP サーバに接続できない（ルータの設定が誤っていないか、そのために DHCP ブロードキャストが転送されていないか、また、サーバが稼働しているかを確認してください）か、または、肯定応答を取得できない（IP アドレス プールがいっぱいになっていないかを確認してください）かのいずれかです。
6. これらのことを確認しても答えが得られない場合は、Sniffer トレースを使用して問題点を特定します。
7. Catalyst 6000 ゲートウェイの場合、NMP がゲートウェイと通信できることを確認する必要があります。これは、NMP からゲートウェイの内部 IP アドレスに対して ping を実行することで確認できます。
8. ping が正常に実行された場合、 show port コマンドを使用すると IP アドレス情報が表示されます。IP アドレス情報と TFTP IP アドレスが正しいことも確認してください。
9. ゲートウェイが有効な DHCP 情報の取得に失敗する場合は、Cisco TAC によって提供される tracy ユーティリティを使用して問題を特定します。
10. このユーティリティを TAC から入手したら、Cat6000 Command Line Interface（CLI; コマンドライン インターフェイス）から次のコマンドを発行します。
この例では、WS-X6624 はモジュール 7 に相当し、1 個の 860 プロセッサしか持っていないのでポート 1 です。コマンド tracy_start 7 1 を発行します。
ゲートウェイ ボード自体の 860 コンソール ポートから実際に出力される結果を次に示します。ただし、tracy コマンドの出力は、860 コンソール ポートの単なるリモート コピーです。
| | | | | | |:.:| | | | | | |:..
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
このタイムアウト メッセージがスクロールし続ける場合は、DHCP サーバへの接続に問題があります。
11. まず、Catalyst 6000 ゲートウェイ ポートが正しい VLAN 上にあることを確認します。
この情報は、 show port コマンドを使用して取得した情報に含まれています。
12. DHCP サーバが Catalyst 6000 ゲートウェイと同じ VLAN 上にない場合は、DHCP 要求を DHCP サーバに転送するように適切な IP ヘルパー アドレスが設定されていることを確認します。VLAN 番号が変わった後に、ゲートウェイは、リセットされるまで INIT 状態のままになっていることがあります。
13. INIT 状態になっている場合は、ゲートウェイをリセットします。860 をリセットするたびに tracy セッションは失われるので、次のコマンドを発行して既存のセッションを閉じ、新しいセッションを再度確立する必要があります。
14. それでも DHCPState = INIT メッセージが表示される場合は、DHCP サーバが正常に機能しているかどうかを確認します。
15. 正常に機能している場合は、Sniffer トレースを開始して、要求が送信されているかどうか、およびサーバが応答しているかどうかを確認します。
DHCP が正常に機能している場合、tracy デバッグ ユーティリティの使用を可能にする IP アドレスがゲートウェイに設定されています。このユーティリティには、Catalyst ゲートウェイ用の NMP コマンド セットの組み込み機能が含まれており、Windows 98/NT/2000 上でスタンドアロン ゲートウェイ用のヘルパー アプリケーションとして使用可能です。
16. ヘルパー アプリケーションとして tracy ユーティリティを使用するには、割り当てられている IP アドレスを使用してゲートウェイに接続します。この tracy アプリケーションはすべてのゲートウェイ上で動作し、ゲートウェイごとに別個のトレース ウィンドウを表示します（一度にトレースできるのは最大 8 個）。トレースは指定したファイルに直接記録できます。
17. TFTP サーバの IP アドレスがゲートウェイに正しく指定されたことを確認します。DHCP は通常、Option 66（名前または IP アドレス）、Option 150（IP アドレスのみ）、または si_addr（IP アドレスのみ）で DHCP を提供します。サーバに複数の Option が設定されている場合、si_addr が Option 150 より優先され、Option 150 は Option 66 より優先されます。
Option 66 が TFTP サーバの DNS_NAME を提供する場合、DNS サーバの IP アドレスは DHCP によって指定されている必要があります。また、Option 66 に入力された名前は正しい TFTP サーバの IP アドレスに解決される必要があります。NMP を使用して DHCP が無効になるように Catalyst ゲートウェイを設定できます。その場合、NMP オペレータは、TFTP サーバのアドレスを含むすべての設定パラメータをコンソールから手動で入力する必要があります。
また、ゲートウェイは、常に DNS を介して名前 CiscoCM1 の解決を試行します。解決に成功すると、CiscoCM1 の IP アドレスは、DHCP サーバまたは NMP が TFTP サーバのアドレスとして示すどの情報よりも優先されます。これは、NMP が DHCP を無効にしている場合も同じです。
18. ゲートウェイにある現在の TFTP サーバの IP アドレスは、tracy ユーティリティを使用して確認できます。次のコマンドを入力して、設定タスク番号を取得します。
config または CFG が含まれる行を探し、対応する番号を次の行（Cisco Access Digital gateway など）の taskID として使用します。この後の例では、説明対象のメッセージを判別しやすいように太字のテキスト行で示しています。実際の画面出力では、テキストは太字で表示されません。これらの例は WS-X6624 モデルの出力です。DHCP 情報をダンプするコマンドは次のとおりです。
19. このコマンドによって、TFTP サーバの IP アドレスが表示されます。その IP アドレスが正しくない場合は、DHCP オプションと表示されたその他の情報が正しいことを確認します。
20. TFTP アドレスが正しい場合は、ゲートウェイが自分の設定ファイルを TFTP サーバから取得していることを確認します。tracy 出力で次の情報が表示される場合は、TFTP サービスが正常に機能していないか、ゲートウェイが Cisco CallManager に設定されていない可能性があります。
ゲートウェイは設定ファイルを取得しない場合、TFTP サーバと同じ IP アドレスに対する接続を試行します。クラスタ化された環境でなければ、これで接続できます。クラスタ化された環境では、ゲートウェイは冗長 Cisco CallManager のリストを受信する必要があります。
21. カードが自分の TFTP 情報を正常に取得していない場合は、Cisco CallManager の TFTP サービスを調べて、サービスが動作していることを確認してください。
22. Cisco CallManager の TFTP トレースを確認します。
ゲートウェイが Cisco CallManager に正しく設定されていない場合は、別の一般的な問題が発生します。典型的なエラーは、ゲートウェイ用に誤った MAC アドレスを入力したことで発生します。その場合、Catalyst 6000 ゲートウェイでは、次のメッセージが 2 分間隔で NMP コンソールに表示されることがあります。
2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
The following example shows what the tracy output would look like if the gateway is not in the Cisco CallManager database:
00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
登録に関する別の問題としては、ロード情報が正しくないこと、またはロード ファイルが破損していることが考えられます。この問題は、TFTP サーバが稼働していない場合にも発生する可能性があります。この場合、ファイルが見つからないという TFTP サーバからの報告が tracy によって次のように表示されます。
00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse
この場合、正しいアプリケーション ロード名が A0020300 であるにもかかわらず、ゲートウェイはアプリケーション ロード A0021300 を要求しています。Catalyst 6000 ゲートウェイでは、新しいアプリケーション ロードがそれに対応する DSP ロードも取得する必要がある場合、同じ問題が発生する可能性があります。新しい DSP ロードが見つからない場合、類似のメッセージが表示されます。
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
ここでの相違点は、ゲートウェイが LoadResponse の段階に留まっているために、最終的にはタイム アウトすることです。この問題は、Cisco CallManager Administration の Device Defaults エリアでロード ファイル名を修正することで解決できます。
ゲートキーパーの問題
ゲートキーパーのトラブルシューティングを開始する前に、ネットワーク内に IP 接続が存在することを確認してください。IP 接続が存在する場合は、この項にある次の情報を参照してゲートキーパー コールのトラブルシューティングを行ってください。
• 登録拒否
クラスタ間トランクまたは H.225 トランク
次の場所で、『 Cisco CallManager アドミニストレーション ガイド 』および『 Cisco CallManager システム ガイド 』を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/4_1/index.htm
アドミッション拒否
Admission Reject（ARJ; アドミッション拒否）が発行されるのは、Cisco CallManager がゲートキーパーに登録されていてもコールを送信できない場合です。
ゲートキーパーが ARJ を発行している場合は、特にゲートキーパーの設定の問題に注目する必要があります。
1. Cisco CallManager からゲートキーパーへの IP 接続を確認します。
2. ゲートキーパのステータスを表示し、ゲートキーパーが動作していることを確認します。
3. ゲートキーパにゾーン サブネットが定義されていることを確認します。定義されている場合は、許可されたサブネットに Cisco CallManager のサブネットが含まれていることを確認します。
4. Cisco CallManager とゲートキーパー設定との間でテクノロジー プレフィックスが一致していることを確認します。
登録拒否
Registration Reject（RRJ; 登録拒否）が発行されるのは、Cisco CallManager がゲートキーパーに登録できない場合です。
ゲートキーパーが RRJ を発行している場合は、特にゲートキーパーの設定の問題に注目する必要があります。
1. Cisco CallManager からゲートキーパーへの IP 接続を確認します。
2. ゲートキーパのステータスを表示し、ゲートキーパーが動作していることを確認します。
3. ゲートキーパにゾーン サブネットが定義されていることを確認します。定義されている場合は、許可されたサブネットにゲートウェイのサブネットが含まれていることを確認します。
Cisco CallManager が B チャネルをロックして Restart を送信する
• チャネルの再起動
• Restart_Ack に Channel IE が含まれていない場合に B チャネルがロックされたままになる
チャネルの再起動
Cisco CallManager が特に理由もなく B チャネルをロックし、そのチャネルに対して再起動を指示します。関連情報については、「Restart_Ack に Channel IE が含まれていない場合に B チャネルがロックされたままになる」を参照してください。
（注） Release 3.1(2c) Engineer Special 21 でこの問題は解決されています。
ISDN チャネルの選択順序が原因でグレア状態が発生します。これは、大量のコールがある場合に発生することがあります。
また、発信コール用の B チャネルの選択は排他的です（Cisco CallManager は他の B チャネルを受け入れません）。チャネルが使用不可の場合、PABX または CO は Release Complete を送信します。
1. Cisco CallManager Administration から、 Device > Gateway を選択します（図 6-2 を参照）。
図 6-2 Cisco CallManager Administration の Device メニュー
Find and List Gateways ウィンドウが表示されます。
2. 検索基準を入力して特定のゲートウェイを見つけます（図 6-3 を参照）。
図 6-3 Find and List Gateways ウィンドウ
4. アップデートするゲートウェイの デバイス名 をクリックします。
Gateway Configuration ウィンドウが表示されます。
5. ゲートウェイ ポートにアクセスするには、そのゲートウェイ ポートのアイコンクリックするか、または選択したゲートウェイの設定ウィンドウの左側にある MGCP エンドポイント リンクをクリックします。
6. Inhibit Restarts at PRI initialization チェックボックスをオンにします（図 6-4 を参照）。
図 6-4 Interface Information ウィンドウ
9. Cisco CallManager サーバを再起動します。
（注） 再起動の問題を解決するには、Inhibit Restarts at PRI Initialization チェックボックスをオンにした後、Cisco CallManager サーバを再起動する必要があります。
E1/T1 PRI 設定の詳細については、『 Cisco CallManager アドミニストレーション ガイド 』を参照してください。
Restart_Ack に Channel IE が含まれていない場合に B チャネルがロックされたままになる
この問題は、前述の問題「Cisco CallManager が B チャネルをロックして Restart を送信する」に関連しています。
Cisco CallManager システムは、ie=channel not available という理由付きの Release Complete を受信すると、Restart を送信してこのチャネルをアイドル状態に戻します。
Restart 内で、Channel IE を使用して、再起動する必要のあるチャネルを指定しています。ネットワークが Channel IE を含めずに Restart_Ack で応答した場合、システムはこのチャネルがロックされた状態を維持します。ネットワーク側では、この同じチャネルがアイドル状態に戻ります。
その結果、ネットワークは着信コール用にこのチャネルを要求することになります。
チャネルは Cisco CallManager サーバ上でロックされているので、Cisco CallManager はこのチャネルに対するコール要求をすべて解放します。
この動作は、ゲートウェイが E1 ブレードの場合、イギリスの多数のサイトで発生します（MGCP バックホールを 2600/3600 上で使用している場合も同じ動作が発生する可能性があります）。
グレア状態は、Release Complete が送信される理由であると考えられます。
ネットワークでの B チャネルの選択がトップダウンまたはボトムアップの場合、すべての着信コールは、上位または下位の B チャネルが解放されるまで成功しません（アクティブ コールがクリアされた場合）。
B チャネルの選択が一定時間のラウンドロビンの場合、E1 ブレードのすべての B チャネルがロックされる結果になります。
フィードバック