Cisco Emergency Responder アドミニストレー ション ガイド 8.5

電話機が検出されない

Cisco Unified CM（Cisco Unified CM）にホーミングしている電話機が Cisco ER で検出されない場合、すべての Cisco Unified CM が SNMP で到達可能であること、および SNMP 設定が正しいことを確認してください。Cisco Unified CM が SNMP で到達不能であっても、Cisco ER のログには記録されます。

Cisco Unified CM の SNMP 設定を確認するには、次の手順を実行します。

手順

ステップ 1 Cisco ER Administration コマンド ライン インターフェイスにログインし、次のコマンドを使用して Cisco Unified CM サーバに ping を送信します。

ステップ 2 Cisco Unified CM への ping に成功する場合、次の手順で Cisco Unified CM の SNMP 設定が正しいことを確認します。

• Linux ベースのバージョンの Cisco Unified CM（バージョン 6.0 以降）を使用している場合、Cisco Unified CM Serviceability Web インターフェイスにログインし、SNMP Web ページを使用して SNMP コミュニティ ストリング設定を確認します。

• Windows ベースのバージョンの Cisco Unified CM を使用している場合、Cisco Unified CM でサービスを開き、次のように選択します。

[Start] > [Settings] > [Control Panel] > [Administrative Tools] >
[Services Properties] > [SNMP] > [Properties] > [Security] タブ

ステップ 3 Cisco ER サーバで次の CLI コマンドを実行して、Cisco Unified CM が SNMP で到達可能かどうかを確認します。

utils snmp get <ccm ip-address/host name> <snmp-read-community-string> 1.3.6.1.2.1.1.2.0

Cisco Unified CM が SNMP で到達可能な場合、上記のコマンドの出力は次のようになります。

Variable = 1.3.6.1.2.1.1.2.0

value = OBJECT IDENTIFIER <sys-oid-of-ccm>

位置未確認の電話機が多すぎる

Cisco ER は Cisco Unified CM から登録済み電話機のリストを取得し、すべての電話機について位置確認を試行します。スイッチ ポートの背後や任意の設定済み IP サブネット内にある電話機の位置を Cisco ER で確認できず、その電話機が設定済みの擬似電話機ではない場合、位置未確認の電話機のリストに表示されます。

位置未確認の電話機が多数ある場合、まずスイッチ ポートと電話機の更新プロセスを実行して、Cisco ER で問題の一部が自動解決されるかどうかを確認してみます。詳細については、「スイッチ ポートおよび電話機更新プロセスの実行（手動）」を参照してください。

Cisco ER で電話機の位置を確認できない原因はいくつかあります。

• 電話機が Cisco Discovery Protocol（CDP）ネイバーであるとレポートするスイッチ ポートが複数ある場合、その電話機は位置未確認の電話機リストに登録されます。電話機が Cisco Discovery Protocol（CDP）ネイバーであるとレポートするスイッチ ポートが 1 つのみの場合、この条件は次回の電話機トラッキング プロセスで修正されます。

• Cisco ER で定義されていないスイッチに電話機が接続されています。スイッチの定義については、「LAN スイッチの指定」を参照してください。

• 電話機がサポート対象外のデバイスに接続されています。ルータ ポート、ルータに接続されるハブ、サポート対象外のスイッチなどです。サポート対象外のスイッチのリストについては、「ネットワークのハードウェアおよびソフトウェアの要件」を参照してください。このような種類の電話機をサポート対象のデバイスに接続できない場合の電話機の設定方法については、「電話機の手動での定義」を参照してください。

• 電話機はハブに接続され、ハブはサポート対象のスイッチ ポートに接続されていますが、そのスイッチ ポートが CDP をサポートしていません。Cisco ER では、（サポート対象のスイッチ ポートに接続された）ハブに接続されている CDP 対応の電話機を常に検出できますが、この方法で接続されている非 CDP 電話機は追跡できません。非 CDP 電話機の場合、サポート対象のスイッチ ポートに電話機を直接接続するようにしてください。

• SNMP クエリーに応答しないなど、電話機が接続されているスイッチが現時点で到達不能です。この理由はいくつか考えられます。

– スイッチ上の SNMP の読み込みコミュニティ ストリングが、Cisco ER に設定されているストリングと一致しません。この場合、Cisco ER の設定を修正します。「SNMP 接続の設定」を参照してください。

– 電話機から CAM テーブルへのアクセスが必要ですが、Cisco ER のスイッチに対して CAM のトラッキングがイネーブルではありません。「LAN スイッチの指定」を参照してください。

– ネットワークが停止しているため、Cisco ER サーバとスイッチ間で通信できません。ネットワークの停止の問題を特定し、解決してください。

Cisco ER で次のスイッチ ポートと電話機全体の更新プロセスが実行されるまで、到達不能のスイッチは再試行されません。ただし、個々のスイッチに対して更新プロセスを実行すると再試行されます（後述を参照）。

• 電話機は、異なる Cisco ER グループで処理されているスイッチに移動しました。この場合、位置未確認の電話機リストで、その電話機について Cisco ER グループ名が表示されます。移動後の次の増分電話機トラッキング プロセスでも電話機の位置が確認されない場合、この電話機がどの Cisco ER グループに属していても、スイッチ ポートと電話機全体の更新プロセスが実行されるまで位置が確認されません。

• 電話機には CAM ベースのトラッキングが必要ですが、電話機が接続されているスイッチで CAM ベースのトラッキングがイネーブルではありません。Cisco IP SoftPhone とその他の一部の電話機モデルには、CAM ベースのトラッキングが必要です。CAM ベースのトラッキングについては、「LAN スイッチの指定」を参照してください。また、CAM ベースのトラッキングが必要な電話機のリストについては、「ネットワークのハードウェアおよびソフトウェアの要件」を参照してください。

Cisco ER で電話機の位置を確認できない問題を解決した後は、影響があるスイッチまたはすべてのスイッチで、スイッチ ポートと電話機の更新プロセスを実行します。

• 特定のスイッチで更新プロセスを実行するには、[Phone Tracking] > [LAN Switch Details] を選択し、左側の列のスイッチを選択し、[Locate Switch Ports] を選択します。

• すべてのスイッチで更新プロセスを実行するには、[Phone Tracking] > [Run Switch-Port & Phone Update] を選択します。

関連項目

• 「位置未確認の電話機の特定」

• 「IP Subnet Phones」

• 「Cisco Unified OS CLI コマンド」

Cisco Emergency Responder に電話機が表示されなくなることがある

Cisco ER が電話機トラッキング プロセス中で、電話機が異なる Cisco Unified CM クラスタに対するホーミング処理中の場合、電話機のレコードを保有する Cisco Unified CM クラスタはありません。そのため、Cisco ER は電話機の存在を認識していません。また、Cisco ER インターフェイスで電話機を検索できません。ただし、電話機が Cisco Unified CM クラスタへの接続に成功した場合、次回の増分電話機トラッキング プロセス時にその電話機が追跡されるため、電話機は Cisco ER インターフェイスに表示されます。

この問題は、Cisco ER の電話機トラッキング プロセス中にバックアップ サーバからプライマリ Cisco Unified CM サーバに電話機が再接続している場合にも発生する可能性があります。

共有回線で誤った ERL が使用される

シェアド ライン アピアランスを使用する複数の電話機が、1 つの Cisco ER グループに監視されるスイッチから、異なる Cisco ER グループに監視されるスイッチに移動すると、このような電話機には、緊急コール時に誤った ERL が割り当てられることがあります。異なる Cisco Unified CM クラスタがある異なるキャンパスに電話機が移動し、移動した電話機が元の Cisco Unified CM クラスタにまだ登録されている場合、この問題が発生することがあります。また、複数の Cisco Unified CM クラスタに処理されている 1 つの大規模なキャンパス内に電話機が移動した場合にも発生することがあります。

移動した電話機はまだ元の Cisco Unified CM クラスタに登録されているため、その電話機からの緊急コールは、元の Cisco ER グループにルーティングされます。この場合、異なる Cisco ER グループが監視しているスイッチに発信元の電話機が接続されていることを Cisco ER グループが検出し、コールは H.323 インタークラスタ トランクを介して適切な Cisco ER グループに転送されます。インタークラスタ トランクは発信元の電話機の MAC アドレスを渡さないため、受信側の Cisco ER グループは発信元の電話機の MAC アドレスを認識しません。したがって、発信者番号に基づいて電話機を ERL に関連付ける必要があります。

受信側の Cisco ER グループが監視しているスイッチに 1 台の電話機が接続されている場合、これは問題にはなりません。ただし、シェアド ライン アピアランスを使用する複数の電話機が、受信側の Cisco ER グループに監視されているスイッチに接続している場合、Cisco ER は緊急コールを発信した電話機を推測する必要があります。シェアド ライン アピアランスを使用するすべての電話機が同じ ERL 内にある場合、推測は成功します。電話機の ERL が複数の場合、推測に失敗する可能性があります。

関連項目

• 「2 つのメイン サイトでの Cisco Emergency Responder の配置」

• 「Cisco Emergency Responder グループ間の通信に対するルート パターンの作成」

不適切な ERL を使用した 802.11b エンドポイント

802.11b エンドポイント（802.11b で実行される Cisco Wireless IP 7920 Phone や Cisco IP SoftPhone など）は、設定済みのサブネットベースの ERL ではなく、スイッチ ポートベースの ERL を使用しています。

Cisco Emergency Responder（Cisco ER）では、コール ルーティングの際に、スイッチ ポートの接続を優先します。Cisco ER は、任意のエンドポイント（802.11b エンドポイントなど）のスイッチ ポート マッピングを検出すると、緊急コールのルーティングにスイッチ ポート マッピングを使用します。スイッチ ポート マッピングが検出されない場合、または対応するスイッチ ポートに ERL が設定されていない場合、Cisco ER 1.2 はサブネット ERL 設定を使用して緊急コールをルーティングします。

Cisco ER 8.5 では、次の両方の条件を満たす場合、スイッチ ポートの背後にある 802.11b エンドポイントの位置が確認されます。

• 接続しているアクセス ポイントまたはスイッチ ポートで、Cisco Discovery Protocol（CDP）がディセーブルです。

• そのスイッチの Cisco ER で、CAM のトラッキングがイネーブルです。

スイッチ ポート画面または ERL デバッグ ツール（「ERL Debug Tool を使用した Cisco Emergency Responder の設定の確認」を参照）で、802.11b エンドポイントがスイッチ ポートに関連付けられていることを確認してください。

サブネットベースの ERL を使用して 802.11b エンドポイントを追跡することをお勧めします。そのために、スイッチ ポートおよびアクセス ポイントで CDP をイネーブルにして、サブネットベースの ERL を使用して 802.11b エンドポイントからの緊急コールをルーティングします。

関連項目

• 「IP サブネットベースの ERL の設定」

緊急コールが Cisco Emergency Responder で代行受信されない

Cisco ER で緊急コールが代行受信されない場合、Cisco Unified CM 設定の誤りか、Cisco ER 設定での表現の誤りが原因の可能性があります。

• 緊急コール番号（911）は Phones パーティション内にあり、E911CSS コーリング サーチ スペースを使用します。Cisco ER のインストール時に、この番号が識別されるようにします（「新しいシステムへの Cisco Emergency Responder 8.5 のインストール」を参照）。その結果、ユーザは緊急番号にダイヤルできるようになります。Cisco Unified CM でこの番号を設定する方法については、「緊急コールのルート ポイントの作成」を参照してください。

• スタンバイ Cisco ER サーバのルート ポイント（912）は E911 パーティション内にあり、E911CSS コーリング サーチ スペースを使用します。Cisco Unified CM でこの番号を設定する方法については、「緊急コールのルート ポイントの作成」を参照してください。Cisco ER 設定で、この番号をスタンバイ サーバのルート ポイントとして定義します（「Cisco Emergency Responder サーバのグループ テレフォニー設定」を参照）。

• PSAP コールバック ルート ポイント パターン（913XXXXXXXXXX）は、E911 パーティション内にあり、E911CSS コーリング サーチ スペースを使用します。Cisco Unified CM でこの番号を設定する方法については、「緊急コールのルート ポイントの作成」を参照してください。Cisco ER 設定で、この番号を PSAP コールバック ルート ポイント パターンとして定義し、ストリップ プレフィクス（913）も識別されるようにします（「Cisco Emergency Responder サーバのグループ テレフォニー設定」を参照）。

• すべての ELIN ルート パターンは E911 パーティション内にあります。Cisco Unified CM でこれらの番号を設定する方法については、「ELIN のルート パターンの作成」を参照してください。

• すべての電話と CTI ポート（デバイスと回線の両方）は Phones パーティション内にあり、PhoneCSS コーリング サーチ スペースを使用します。追加のパーティションは使用できますが、Cisco ER パーティションおよびコーリング サーチ スペースとの関係について、「緊急コールを処理するための Cisco Emergency Responder の設定」に記載されている例のパーティションと同じ方法でパーティションを設定する必要があります。

• サービス プロバイダーのネットワークに対するすべてのゲートウェイは、E911CSS コーリング サーチ スペースを使用します。詳細については、「PSAP への接続に使用されるゲートウェイに対するコーリング サーチ スペースの設定」を参照してください。

• 設定されている Cisco Unified CM バージョン（JTAPI jar）が適切です。Cisco Unified CM バージョンを確認するには、次の手順を実行します。

1. Cisco ER Admin Utility Web サイトにログインします。

2. [Update] > [CCM Version] を選択します。

3. [Status] セクションで、[Current Version of CCM] を確認します。

ELIN が PSAP に伝送されない

ELIN が PSAP に伝送されず、PSAP に対する緊急コールのルーティングに PRI 接続を使用している場合、ゲートウェイの設定を確認します。本社の番号などの固定番号ではなく、実際の発信者番号（つまり ELIN）が送信されるように、PRI を設定する必要があります。「PSTN に対する CAMA トランクまたは PRI トランクの取得」を参照してください。

他の ERL からのコールにデフォルトの ERL の ELIN が使用される

発信元の ERL に割り当てられている ELIN ではなく、デフォルトの ERL に定義されている ELIN が緊急コールに割り当てられる場合、次の点を確認してください。

• Cisco Unified CM で、使用されるはずの ELIN のルート パターンについて確認します。「ELIN のルート パターンの作成」を参照してください。

• Cisco ER の ERL 定義で、その ERL について ELIN が正しく設定されていることを確認します。「ERL と ALI の設定」を参照してください。

ERL のルート パターンが失敗する場合、デフォルト ERL に定義されているルート パターンが使用されます。

緊急コールが正しい PSAP にルーティングされない

緊急コールがどの PSAP にもルーティングされない場合、発信元の ERL とデフォルト ERL に使用されているルート パターンが設定されていること、および正しいパーティションとコーリング サーチ スペースを使用していることを確認します（「ELIN のルート パターンの作成」を参照）。ゲートウェイのパーティションとコーリング サーチ スペースが正しいことを確認します（「PSAP への接続に使用されるゲートウェイに対するコーリング サーチ スペースの設定」を参照）。

緊急コールはローカル ネットワークから送出されますが、正しい PSAP にルーティングされない場合、問題の原因と考えられる次の点を確認してください。

• 電話に割り当てられた ERL に、正しい ELIN を割り当てるように Cisco ER を設定していますか。緊急コールは ELIN に基づいてルーティングされるため、誤った ELIN を割り当てると、コールは正しくルーティングされません。「ERL の作成」を参照してください。

• ELIN が正しい場合、ELIN のルート パターンには正しいゲートウェイを使用するように設定されていますか。誤ったゲートウェイを選択すると、目的の PSAP に接続できないサービス プロバイダーのネットワークの部分にコールがルーティングされる可能性があります。ゲートウェイの要件を判断するには、サービス プロバイダーにお問い合わせください。

次のトピックを参照してください。

– 「緊急コールのルーティングと PSAP コールバックの有効化を実現するための ELIN 番号の設定」

– 「2 つ以上の PSAP がある 1 つのメイン サイトでの Cisco Emergency Responder の配置」

• サービス プロバイダーの ALI データベースに、ELIN の正しい情報が格納されていますか。外部ネットワークでの緊急コールは、ローカル ネットワークの情報ではなく、サービス プロバイダーのデータベースの情報に基づいてルーティングされます。「ERL 情報のエクスポート」を参照してください。

• 緊急コールの電話は、元のスイッチ ポートをサポートする Cisco ER グループとは異なる Cisco ER グループがサポートする Cisco Unified CM クラスタに登録されていますか。この場合、Cisco ER クラスタの設定が正しくない可能性があります。次のトピックを参照してください。

– 「新しいシステムへの Cisco Emergency Responder 8.5 のインストール」

– 「Cisco Emergency Responder グループ間の通信に対するルート パターンの作成」

– 「Cisco Emergency Responder サーバのグループ テレフォニー設定」

（注） コールは PSAP に到達しますが、PSAP が発信者と通話できない場合、リモート Cisco ER グループの Cisco Unified CM が、ゲートウェイとしてローカル Cisco ER グループの Cisco Unified CM を定義していることを確認します。

緊急コールの発信者がビジー信号を受信することや、緊急コールがルーティングされないことがある

発信者が緊急コール番号に発信したときにビジー信号が聞こえる場合、または緊急コールがルーティングされないことがある場合、スタンバイ Cisco ER サーバの設定が原因の可能性があります。

• プライマリ Cisco ER サーバのみを設定している場合、スタンバイ Cisco ER サーバのインストールおよび設定を行います。プライマリ サーバの CPU 使用率が 100% に達すると、Cisco ER は緊急コールを処理できなくなります。この場合、スタンバイ サーバがあればコールを処理できます。

• スタンバイ サーバのルート ポイント設定を確認します。緊急コール ルート ポイントのコール転送設定で、この番号にコールが転送されるように指定します。Cisco Unified CM の設定については「緊急コールのルート ポイントの作成」、Cisco ER の設定については「Cisco Emergency Responder サーバのグループ テレフォニー設定」を参照してください。

PSAP コールバック エラー

PSAP オペレータが、発信者 ID に指定されている ELIN を使用して緊急コールの発信者にコールバックしようとしたときに、この問題が発生することがあります。

症状 PSAP は、元の緊急コール内線番号に到達できないことがあります。

推奨処置 Cisco ER は、発信者の実際の内線番号と、ERL に定義した ELIN とのマッピングを取得します。ERL に定義した ELIN の数よりもコール数が多いと、Cisco ER は番号を再利用するため、元の発信者の内線番号は上書きされます。元の発信者の内線番号を判断するには、コール履歴を確認します。「緊急コールの発信時に発生するプロセス」を参照してください。

これが問題ではない場合、Cisco Unified CM と Cisco ER で PSAP コールバック ルート ポイントの設定（「緊急コールのルート ポイントの作成」および「Cisco Emergency Responder サーバのグループ テレフォニー設定」を参照）を確認し、Cisco Unified CM で ELIN トランスレーション パターンを確認します（「ELIN のトランスレーション パターンの作成」を参照）。

症状 オンサイト アラート（セキュリティ）担当者は、PSAP からコールバックを受けます。

推奨処置 キャッシュにある緊急コールの ELIN から内線へのマッピングが期限切れになった場合、Cisco ER はデフォルトの ERL のオンサイト アラート担当者に PSAP コールバックをルーティングします。デフォルトの有効期限は 3 時間ですが、より長い時間または短い時間を設定することもできます。「Cisco ER Group Settings」を参照してください。

オンサイト アラート担当者が電話機のアラートを受信できない

ERL で緊急コールが発信されたときに、オンサイト アラート担当者が電話機のアラートを受信できない場合、すべての電話機と CTI ポート（デバイスと回線の両方）が Phones パーティション内にあり、PhoneCSS コーリング サーチ スペースを使用していることを確認します。追加のパーティションは使用できますが、Cisco ER パーティションおよびコーリング サーチ スペースとの関係について、「緊急コールを処理するための Cisco Emergency Responder の設定」に記載されている例のパーティションと同じ方法でパーティションを設定する必要があります。

また、Cisco Unified CM クラスタの Cisco ER 設定が正しいことを確認します。Cisco ER 設定には、Cisco Unified CM で CTI ポートとして定義した電話ポートの正しい開始アドレスが表示されること、および電話ポートの番号が正しいことを確認します。コールが発生した場合、この番号は常に 0 より大きな値になります。Cisco ER では、オンサイト アラート担当者への発信にこの CTI ポートを使用します。

Cisco ER Serviceability Web インターフェイスの Event Viewer に「No port to place call」というエラー メッセージが表示される場合、オンサイト アラート担当者に対するすべてのコールの開始に必要な数の CTI ポートが定義されていなかったことを示します。そのため、追加のポートを定義する必要があります。Event Viewer にアクセスするには、Cisco ER Serviceability Web インターフェイスにログインし、[Tools] > [Event Viewer] を選択します。

緊急コールの着信時にオンサイト アラート電話機の着信音が鳴らない

緊急コールの着信時にオンサイト アラート電話機の着信音が鳴らない場合、次の問題が発生している可能性があります。

症状 緊急コールの着信時にオンサイト アラート電話機の着信音が鳴らない。

考えられる原因 電話機の Do Not Disturb（DND）機能がイネーブルの場合、および Cisco Unified CM 6.x を使用して Cisco ER を設定している場合、オンサイト アラート電話機の着信音は鳴りません。

推奨処置 オンサイト アラート電話機では、DND をイネーブルにしないでください。

電話機のアラートのプロンプトが再生されない

電話機のアラートのプロンプトが再生されない場合、次の問題が発生している可能性があります。

症状 コールが CTI ポートから発信された場合、オンサイト アラート電話機ではプロンプトは再生されません。

説明 この問題は、複数の回線に単一の CTI ポートが設定されている場合に発生する可能性があります。オンサイト アラートの通知コールがこのような 1 つまたは複数の回線を介して発信された場合、その回線からのプロンプトは再生されない可能性があります。

推奨処置 この問題を回避するには、Cisco ER 用に設定する Cisco Unified CM の CTI ポート 1 つにつき、1 回線のみを設定します。

オンサイト アラート担当者に電子メール（または呼び出し）通知が送信されない

オンサイト アラート担当者の電子メール アドレスを設定（「Onsite Alert Settings」を参照）しても、電子メールまたは電子メールベースの呼び出しが送信されない場合、Cisco ER 設定で SMTP の設定を確認します。SMTP サーバ アドレスと発信元メール ID が正しいことを確認し（「Cisco ER Group Settings」を参照）、SMTP サーバにそのメール ID のアカウントがあることを確認します。

誤った位置情報がオンサイト アラート担当者に送信される

オンサイト アラート（セキュリティ）担当者に送信される緊急コールの位置情報に誤りがある場合、次の問題の可能性を検討してください。

• ERL の ALI データは正しいですか。「ERL の作成」を参照してください。

• スイッチ ポートの電話位置データは正しいですか。「スイッチ ポートの設定」を参照してください。

• 電話が接続されるスイッチ ポートには、正しい ERL が割り当てられていますか。これらの条件に該当しない場合、次の 2 つの問題が考えられます。

– 誰かがスイッチの配線を変更したため、以前は正しかった設定が無効になりました。配線を別のポートに移動すると、ERL の割り当てが無効になる可能性があります。「データの整合性および信頼性に関する考慮事項」を参照してください。

– ワイヤリング クローゼットは保護されており、単に ERL の割り当てが間違っています。「スイッチ ポートの設定」を参照してください。

• （任意の永続的 ERL にデフォルトの ERL を使用していないという前提で）コールの発信元はデフォルトの ERL でしたか。この場合、次の問題が発生している可能性があります。

– 電話機はサポート対象外のポートに接続され、手動電話機として定義されていません。「電話機の手動での定義」を参照してください。

– 電話機はサポート対象外であり、手動電話機として定義されていません。「電話機の手動での定義」を参照してください。

– 電話機はサポートされていますが、Cisco ER で位置を確認できませんでした。この問題を解決できない場合、状況によっては手動で電話機を ERL に割り当てる必要があります。「位置未確認の電話機が多すぎる」を参照してください。

• コールは手動で定義した電話機の内線番号から発信されましたか。その場合、おそらく電話が移動されたために、誤った ERL が割り当てられている可能性があります。「電話機の手動での定義」を参照してください。

緊急コールの履歴に関する問題

ここでは、緊急コールの履歴情報を表示するとき（「緊急コール履歴の表示」を参照）に発生する可能性があるいくつかの問題について説明します。

症状 緊急コール情報は、コール履歴にすぐには表示されません。

推奨処置 Cisco ER では、15 秒ごとにデータベースへコール履歴情報が書き込まれます。そのため、コール履歴情報を表示できるのは、15 秒後の可能性があります。

症状 コール履歴には、コールに使用された ELIN とルート パターンは表示されません。

推奨処置 コールを PSAP にルーティングできなかった場合、ELIN またはルート パターンは表示されません。コールをルーティングできなかった理由を確認して判断してください。「緊急コールが正しい PSAP にルーティングされない」を参照してください。

Emergency Call Alert（緊急コール アラート）

ユーザが 911（緊急）コールを発信すると、Cisco ER で電子メール アラートが生成されます。Cisco ER から、コールが発信された ERL に設定されている電子メール ID を持つオンサイト アラート（セキュリティ）担当者全員に電子メール アラートが送信されます （「Cisco Emergency Responder サーバ グループの設定」を参照してください）。

セキュリティ担当者はそのユーザに応答します。詳細なコール情報については、次の URL を参照してください。

http:// <<CERServer HostName>> /ceruserreports

911 コールが発信され、バックアップ Cisco ER サーバがコールを処理する場合、次のようなアラートが送信されます。

Transition Alert（移行アラート）

スタンバイ Cisco ER サーバがコールを制御し、アクティブ サーバになる場合、Transition Alert が Cisco ER 管理者に送信されます。この状況は、次の条件で発生します。

• プライマリ Cisco ER サーバが停止した場合。

• プライマリ Cisco ER サーバで Cisco ER サービスが停止した場合。

• プライマリおよびスタンバイの Cisco ER サーバ間の接続が切断された場合。

管理者は原因を診断し、できるだけ早く問題を解決する必要があります。

Cisco ER バックアップ サーバがコールを制御すると、次のようなアラートが送信されます。

マスター Cisco ER サーバがコールを制御すると、次のようなアラートが送信されます。

Tracking Failure（トラッキング エラー）

スイッチ ポートと電話のトラッキング プロセスが終了するときに、追跡できなかったデバイスがある場合、Cisco ER から Cisco ER 管理者に Tracking Failure の電子メールが送信されます。

管理者は Cisco ER サーバのイベント ログを確認し、追跡されなかったデバイスのリストを探す必要があります。次に、以下の点を確認し、必要な修正を行います。

1. 正しい SNMP コミュニティ ストリングが Cisco ER に設定されていることを確認します。

2. デバイスが接続されていることを確認します。

3. Cisco ER サーバのホスト名が解決可能であること（つまり、検出可能であること）を確認します。

4. そのデバイス（スイッチや Cisco Unified CM）で SNMP サービスがイネーブルであることを確認します。

次に、Tracking Failure アラートの例を示します。

Failed To Get Provider（プロバイダーの取得に失敗しました）

Cisco ER が、設定済みの Cisco Unified CM クラスタの 1 つに登録できない場合、Cisco ER から Cisco ER 管理者に Failed to Get Provider アラートが送信されます。Cisco ER は、登録が成功するまで登録の試行を続けます。数回の再試行後、Cisco ER からは Failed to Get Provider 電子メールが送信されます。

このメッセージでは、次の例のように、問題の解決方法に関する情報を提供します。

Failed to Establish Communication with Cisco Emergency Responder Phone Tracking Engine（Cisco Emergency Responder Phone Tracking Engine との通信の確立に失敗しました）

Cisco ER サーバが Phone Tracking Engine との通信の確立に一定の期間失敗した場合、Cisco ER から Cisco ER 管理者にこのメッセージが送信されます。Cisco ER Phone Tracking Engine サービスが停止した場合、この問題が発生する可能性があります。管理者は次の手順を実行する必要があります。

1. Cisco ER Phone Tracking Engine サービスが停止した場合、そのサービスを開始します。

2. Cisco ER サーバのホスト名にアンダースコア（_）文字が含まれないことを確認します。

次に、Tracking Failure アラートの例を示します。

Lost Communication with Cisco Emergency Responder Phone Tracking Engine（Cisco Emergency Responder Phone Tracking Engine との通信が失われました）

Cisco ER サーバと CER Phone Tracking Engine との通信が失われた場合、Cisco ER から Cisco ER 管理者にこの電子メール アラートが送信されます。この問題の最も可能性が高い原因は、Cisco ER サービスの実行中に Cisco ER Phone Tracking Engine サービスが停止した場合です。

管理者は Cisco ER Phone Tracking Engine サービスを再開する必要があります。

次に、Tracking Failure アラートの例を示します。

Failed to Send Unlocated Phone Details to Remote Cisco Emergency Responder Server Group（位置未確認の電話機の詳細をリモートの Cisco Emergency Responder サーバ グループに送信できませんでした）

サーバ グループに対してすでにエントリの送信プロセスが実行されているために、Cisco ER からそのサーバ グループに対して位置未確認エントリの送信に失敗した場合、このアラートが送信されます。

このアラートはほとんど発生しません。このアラートが発生するのは、1 つの Cisco ER サーバが複数の Cisco ER サーバ グループで検出される場合です。この問題を解決するには、古い設定のサーバ グループを確認し、そのサーバ グループを削除します。

Emergency Call Could Not be Routed（緊急コールをルーティングできませんでした）

ERL に設定されている一部のルート パターンに対する緊急コールのルーティングが失敗する場合、Cisco ER からシステム管理者に電子メールが送信されます。

件名 ：Emergency call could not be routed using some route patterns (CERServer: <server hostname> )

メッセージ本文： Emergency call from :<Caller Extn> could not be routed using some Route Patterns.Check Event Log.

Event Log には次のメッセージが表示されます。

ソリューション

1. Cisco Unified CM 4.2 または 4.3 を実行している場合、Cisco ER ユーザ ページの [Calling Party Number] チェックボックスがオンであることを確認します。

2. Cisco Unified CM 5.x または Cisco Unified CM 6.x を実行している場合、ルートが使用可能であることを確認します。

3. Cisco ER Application User を「Standard CTI Allow Calling Number Modification」ユーザ グループに追加します。

Calling Party Modification Failed（発信側の修正に失敗しました）

発信側の修正に失敗した場合、Cisco ER からシステム管理者に次の電子メールが送信されます。

件名： Emergency Calling Party Modification Failed (CERServer: <server> )

メッセージ本文： Emergency call from :<Caller Extn> cannot be routed with calling party modification.Check Event Log.

Event Log には次のメッセージが表示されます。

ソリューション Cisco Unified CM 4.2 または 4.3 Administration の場合、Cisco ER ユーザ ページの [Enable Calling Party Number Modification] チェックボックスをオンにします。このフラグをイネーブルにした後は、変更内容を反映するために Cisco ER サービスを再起動します。

パブリッシャを確認できない

インストール処理でパブリッシャを確認できない場合（「Cisco Emergency Responder Subscriber のインストール」 のステップ 5）、次の点を確認してください。

1. パブリッシャのホスト名が正しいこと、およびホスト名でパブリッシャに到達可能であることを確認します。

2. パブリッシャとサブスクライバ サーバが同じバージョンの Cisco ER を実行していることを確認します。

3. 入力したデータベースのパスワードが正しいことを確認します。これは、インストール時に [Database Access Security Configuration] ページで指定したパスワードです。

4. パブリッシャでサブスクライバが正しく設定されていることを確認します。

ログインに関する問題のトラブルシューティング

ここでは、Cisco ER にログインするときに発生する可能性があるいくつかの問題について説明します。

症状 Cisco ER Administration Web サイトにログインできません。

推奨処置 CLI にログインし、 utils service list コマンドを実行します。ステータス「Cisco IDS」が STARTED かどうかを確認します。STARTED ではない場合、 utils service start service name コマンドを使用してサービスを開始します。

症状 Netscape Navigator を使用して複数の Cisco ER セッションを開くことはできません。

推奨処置 Netscape/Mozilla Navigator では、複数のウィンドウに同じセッション ID を使用します。そのため、異なる ID を使用して Cisco ER にログインしようとすると問題が発生します。通常、システム管理者としてログインすると、複数のウィンドウを開くことができます。Internet Explorer を使用し、（既存のセッションから新しいウィンドウを開くのではなく）新しい IE インスタンスを開始して別の IE セッションを開いた場合、IE は異なるセッション ID を使用します。そのため、異なる ID を使用してログインできます（たとえば、ユーザと管理者として、LAN スイッチ管理者と ERL 管理者としてなど）。

関連項目

• 「ERL Debug Tool を使用した Cisco Emergency Responder の設定の確認」

Cisco Unified Operations Manager の使用

Cisco ER システムの動作状況を継続的に監視するには、Cisco Unified Operations Manager 2.01 を使用します。

Cisco Unified Operations Manager を使用するように Cisco ER を設定する方法については、「テスト ERL の設定」を参照してください。

Cisco Unified Operations Manager のインストール方法と使用方法については、次のマニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/cscowork/index.html

Cisco Emergency Responder スイッチとポートの設定に関する問題のトラブルシューティング

Cisco ER でスイッチまたはスイッチ ポートの設定時に発生する可能性があるいくつかの問題を次に示します。

症状 Cisco ER は Cisco Unified CM の情報を使用して設定されていますが、電話が検出されません。

推奨処置 ネットワークで Cisco Unified CM サーバに到達可能であることを確認します。次に、スイッチおよび Cisco Unified CM サーバの SNMP 読み取りコミュニティ ストリングが正しく設定されていることを確認します（「SNMP 接続の設定」を参照）。次に、スイッチ ポートと電話機の更新プロセスを手動で実行します（「スイッチ ポートおよび電話機更新プロセスの実行（手動）」を参照）。CLI ベースの utils snmp コマンドを使用して、Cisco Unified CM が SNMP で到達可能かどうかを確認します。

症状 Cisco ER で、Cisco ER に設定されているスイッチのポートが表示されません。

推奨処置 サポート対象のスイッチを Cisco ER に追加し、追加後にスイッチで電話機のトラッキングを実行すると、スイッチでイーサネット ポートのリストを表示できます。Cisco ER でポート リストが表示されない場合、スイッチの Cisco ER で SNMP 設定を確認します（「SNMP 接続の設定」を参照）。また、ネットワーク上でスイッチに到達可能であることを確認します。スイッチで特定の電話機のトラッキング プロセスを再試行します（スイッチの詳細情報を表示しているときに、[Locate Switch Ports] をクリックします。詳しくは「LAN Switch Details」を参照してください）。

問題が解決しない場合、スイッチがサポート対象であることを確認します（「ネットワークのハードウェアおよびソフトウェアの要件」を参照）。また、Event Viewer でエラー メッセージを確認します。

症状 一部の電話機がスイッチ ポート リストに表示されません。

推奨処置 設定済みの IP サブネットまたは擬似電話機内に電話機があるかどうかを確認します。いずれの場所でも見つからなかった場合、位置未確認の電話機に配置されます。電話機の位置を確認できなかった理由のリストについては、「位置未確認の電話機が多すぎる」を参照してください。

症状 Cisco ER の設定からスイッチを削除できません。

推奨処置 電話機のトラッキング プロセスが進行中の場合、スイッチは削除できません。プロセスの終了後に削除を再試行してください。これが問題ではない場合、Cisco ER サーバが実行されていない可能性があります。コントロール センターを確認し、サーバを再起動してください（「Cisco Emergency Responder サーバの起動と停止」を参照）。

症状 スイッチ ポートの詳細の読み込みまたは書き出しに失敗します。

推奨処置 スイッチ ポートの読み込みまたは書き込みの試行に失敗する場合、次の理由が考えられます。第 1 に、スイッチ ポートと電話機の更新プロセスがまだ終了していません（完了するまで待ってください）。第 2 に、Cisco ER サーバが実行されていません（コントロール センターを使用して再起動します。「Cisco Emergency Responder サーバの起動と停止」を参照してください）。第 3 に、Cisco ER サーバの初期化が完了していません（初期化されるまで待ってください）。

症状 一部のスイッチ ポート設定の読み込みに失敗します。

推奨処置 スイッチ ポート設定を読み込むには、スイッチで Cisco ER を設定済みであり、Cisco ER はスイッチ ポートと電話機の更新プロセスを使用して、まずスイッチ上のポートを検出する必要があります。Cisco ER でまだ検出されていないポートの設定を読み込もうとすると、設定の読み込みに失敗します。このプロセスについては、「スイッチ ポートおよび電話機更新プロセスの実行（手動）」を参照してください。ポート設定を読み込むことができないスイッチでこのプロセスを実行してから、読み込みを再試行してください。

症状 電話機が他の Cisco ER グループからこの Cisco ER グループに移動され、また元のグループに移動した場合、電話機は、この Cisco ER グループのスイッチ ポートの詳細に表示されます。

推奨処置 このような電話機は、次回のスイッチ ポートと電話機全体の更新プロセスが実行されるまで、スイッチ ポートの詳細から削除されません。これが問題の場合、そのスイッチ（またはすべてのスイッチ）でプロセスを手動実行できません。「スイッチ ポートおよび電話機更新プロセスの実行（手動）」を参照してください。

ERL Debug Tool を使用した Cisco Emergency Responder の設定の確認

ERL Debug Tool は検索条件として電話機の内線番号を使用し、電話機の緊急コールのルーティングに現在使用されている ERL を表示します。

この診断ツールを使用して、ERL の作成および ERL の割り当てフェーズ時の Cisco ER の設定を確認し、誤った ERL 宛てのコールの問題を解決します。

たとえば、手動設定した電話機として ERL_1 を設定したとします。ただし、設定を誤った IP サブネットがこの電話機の IP アドレスと一致し、ERL_2 と関連付けられています。この場合、Debug Tool を使用して設定の問題を検出し、修正できます。

ERL Debug Tool を使用するには、次の手順を実行します。

手順

ステップ 1 [Tools] > [ERL Debug Tool] を選択します。

Cisco ER の [ERL Debug Tool] ページが表示されます。

ステップ 2 特定の電話のリストを表示するには、[Find Phones] フィールドで検索条件を選択し、[Find] をクリックします。

その電話機で緊急コールのルーティングに現在使用されている ERL が表示されます。

ステップ 3 設定が正しくない場合、必要に応じて修正します。

（注） Cisco ER には最大 1,000 レコードが表示されます。

パブリッシャ サーバとサブスクライバ サーバの交換

問題のあるパブリッシャ サーバまたはサブスクライバ サーバを交換する必要がある場合、次のように適切な手順を実行します。

• 「問題のあるサブスクライバの交換」

• 「問題のあるパブリッシャの交換」

問題のあるサブスクライバの交換

問題のあるサブスクライバを交換するには、Cisco ER Administration を使用し、そのサブスクライバを削除します。パブリッシャの新しい Cisco ER サブスクライバをインストールします（「新しいシステムへの Cisco Emergency Responder 8.5 のインストール」を参照）。

（注） 新しい交換サブスクライバ サーバで同じホスト名を使用しない予定の場合、パブリッシャ サーバの Cisco ER Administration 画面を使用して問題のあるサブスクライバを削除する必要があります。

問題のあるパブリッシャの交換

パブリッシャを復元できるのは、Cisco ER の一部として使用できる Disaster Recovery System でパブリッシャをバックアップした場合のみです。「データのバックアップと復元」を参照してください。

問題のあるパブリッシャを交換するには、次の手順を実行します。

手順

ステップ 1 以前に使用していたものと同じホスト名を持つ同じバージョンの Cisco ER Publisher をインストールします。

ステップ 2 インストール時には同じ設定オプションを選択します（Cisco Unified CM のバージョンなど）。

ステップ 3 Disaster Recovery System を使用して、古い設定データを復元します。

Cisco Emergency Responder Admin Utility の使用

Cisco ER Admin Utility Tool を使用して、次のタスクを実行できます。

• Cisco ER クラスタ データベース ホストの詳細を更新する

• CCM バージョンをアップグレードする

ここでは、次のトピックについて取り上げます。

• 「Cisco ER Admin Utility Tool の使用方法」

Cisco ER Admin Utility Tool の使用方法

Cisco ER Admin Utility Tool を使用するには、次の手順を実行します。

手順

ステップ 1 Cisco ER Admin Utility Web インターフェイスにログインします。

ステップ 2 メニュー バーを使用して、実行するタスクを選択します。

a. サブスクライバ サーバが示すパブリッシャを変更するには、[Update] > [Publisher] を選択します。

b. Cisco Unified CM バージョンを更新するには、[Update] > [CCM Version] を選択します。

c. パブリッシャ サーバとサブスクライバ サーバの両方でクラスタ設定を更新するには、[Cluster] > [DBHost] を選択します。

（注） このアクションで、このサーバ グループの Cisco ER クラスタ DB の詳細のみが更新されます。この Cisco ER クラスタの他のサーバは自動更新されません。

ステップ 3 変更内容を保存するには、パブリッシャ サーバとサブスクライバ サーバの両方を再起動します。

サブスクライバ データベースの設定のトラブルシューティング

（DB レプリケーションとは別の）サブスクライバに関する問題がある場合、パブリッシャとサブスクライバを設定し直すには、次の手順を実行します。

手順

ステップ 1 サブスクライバ サーバの Cisco ER Admin Utility Web インターフェイスにログインします。

ステップ 2 [Update] > [Publisher] を選択します。

ステップ 3 同じパブリッシャのホスト名、IP アドレス（すでに指定済み）、およびデータベース アクセス セキュリティ パスワードを指定します。

ステップ 4 [Go] をクリックします。

この設定手順には時間がかかることがあります。

データベースおよびエンタープライズ レプリケーションのトラブルシューティング

Informix Dynamic Server（IDS）データベースのトラブルシューティングには、次の CLI コマンドを使用します。

• utils service list ：IDS サービスが実行中かどうかを確認するために使用されます。

• show tech dbstateinfo ：データベースに関する問題のデバッグに役立つ DB の状態情報を表示します。

• show tech dbinuse ：現在使用されているデータベースを表示します。

• show tech dbintegrity ：データベースの整合性情報を表示します。

• show tech database ：データベースのすべてのテーブルのコンテンツを含む 1 つの .csv ファイルを作成します。

エンタープライズ レプリケーションのトラブルシューティングには、次の CLI コマンドを使用します。

• utils dbreplication status ：データベース レプリケーションののステータスを表示するために使用されます。

• utils dbreplication reset ：パブリッシャとサブスクライバ間のデータベース レプリケーションをリセットし、再起動します。

• utils dbreplication repair ：レプリケーション サーバ（パブリッシャとサブスクライバ）上のデータを比較し、データの不統一を列挙したレポートを作成し、データの不統一を修復します。また、何らかの理由で .rhosts ファイルが破損した場合、このコマンドは、そのファイルを再構築してレプリケーションの修復も試行します。

ログを使用してデータベースに関する問題を解決するには、Cisco ER Serviceability Web サイトまたは CLI を介してログをダウンロードします。

次のログは、データベースに関連する問題をデバッグするための情報を提供します。

• Install/Upgrade ログ：/var/log/install/

• Install DB ログ：/var/log/active/er/trace/dbl/sdi/

• CERDbMon ログ：/var/log/active/er/trace/dbl/sdi/cerdbmon/

• CLI ログ：/var/log/active/platform/log/

症状 DNS を使用してサブスクライバをインストールした後にレプリケーションの起動に失敗し、CLI コマンド utils dbreplication status でレプリケーションが動作していないと表示されます。

考えられる原因 .rhosts は、サブスクライバの Fully Qualified Domain Name（FQDN; 完全修飾ドメイン名）ではなく、サブスクライバのホスト名になります。

推奨処置 レプリケーションの問題を修復するには、CLI コマンド utils dbreplication repair を使用します。このコマンドは、破損した .rhosts ファイルを再構築して、レプリケーションの修復を試行します。

Cisco Unified Communications Manager の設定に関する問題のトラブルシューティング

ここでは、Cisco ER と Cisco Unified CM との通信で発生する可能性があるいくつかの問題について説明します。緊急コールの失敗に伴うその他の問題と現象については、「緊急コールに関する問題のトラブルシューティング」を参照してください。

症状 Cisco ER が、使用するために選択したルート ポイントと CTI ポートを使用して登録されません。

推奨処置 ルート ポイントと CTI ポートが Cisco Unified CM Cisco ER ユーザと関連付けられていることを確認します（「Cisco Emergency Responder Cisco Unified CallManager ユーザの作成」を参照）。また、Cisco Unified CM サーバ上の CTI Manager（または Windows ベースの Cisco Unified CM サーバ上の DC Directory）が適切に実行されていることを確認します。

症状 Cisco ER 設定から Cisco Unified CM を削除しようとしても削除できず、「Phone tracking in progress」というメッセージが表示されます。

推奨処置 電話機のトラッキング プロセスの進行中は、Cisco ER 設定から Cisco Unified CM サーバを削除できません。プロセスの終了後に削除を再試行してください。

デバイスの追加後の Cisco Emergency Responder の更新

Cisco ER で Cisco ER クラスタを使用してプロバイダーを作成する前に、ユーザに割り当てる必要がある Cisco ER の使用と CTI ポートおよびルート ポイントについて、Cisco Unified CM ユーザを作成する必要があります。Cisco ER は、プロバイダーの作成時にユーザに関連付けられている CTI ポートとルート ポイントのみを登録します。したがって、Cisco ER の起動後にユーザに追加したデバイスは、Cisco ER によって登録されません。

Cisco Unified CM で Cisco ER ユーザにデバイスを追加する場合、Cisco ER で次のいずれかの技術を使用して、プロバイダーの再作成を強制的に行うことができます。

• Cisco ER サーバを再起動します。

• Cisco ER の設定から Cisco Unified CM サーバを削除し、再入力します。

• Cisco ER 設定で Cisco Unified CM サーバのバックアップ CTI Manager 設定を変更し、[Update] をクリックします。この操作で、強制的にプロバイダーからログオフされ、プロバイダーが再作成されます。

• Cisco Unified CM でユーザ名を変更するか、新しいユーザを作成して、すべてのデバイスをそのユーザに関連付けます。次に、新しいユーザを使用する Cisco ER 設定を更新します。

ALI データ レコードの修正

ALI レコードをサービス プロバイダーにアップロードするときに表示されることがあるデータ エラーを修正するには、次の手順を実行します。

始める前に

NENA またはサービス プロバイダーから、NENA Doc 02-010『 Recommended Formats and Protocols for Data Exchange 』を入手してください。この文書で、さまざまな NENA 形式が詳細に説明されています。

手順

ステップ 1 エラー レポートをよく読み、発生した問題について判断します。

ステップ 2 Cisco ER Web インターフェイスで、失敗した ERL/ALI レコードのエラーになったフィールドを変更します。たとえば、[Street Suffix] の短縮表記が受け入れられなかった場合、受け入れられる表記に変更します。すべての変更を保存します。

ステップ 3 もう一度 ALI データを書き出します（オンライン ヘルプを参照）。

ステップ 4 エラー状態にあるすべてのレコードが新規だった場合、レコードのデータベース関数を変更する必要があります。Cisco ER ではこれらのレコードを書き出し済みなので、新規の挿入ではなく更新というラベルが付けられます。ただし、これらのレコードはアップロード時に失敗したため、サービス プロバイダーのデータベースは新規と見なします。

テキスト エディタで ALI 書き出しファイルを開き、修正するレコードの関数コードを変更します。書式設定や他の余計な文字を追加しないエディタを使用してください。ファイルの編集の詳細については、次の項を参照してください。

• 「NENA 2.0 および 2.1 ファイル形式の編集」

• 「NENA 3.0 ファイル形式」

ステップ 5 編集したファイルをサービス プロバイダーに送信します。

NENA 2.0 および 2.1 ファイル形式の編集

NENA 2.0 および 2.1 ファイル形式には次の特徴があります。

• レコードは固定長です。

• フィールドは特定の順序です。

• 使用しないフィールドはスペースを入力して埋めます。

• レコードの末尾にはアスタリスク（*）が示されます。

NENA Doc 02-010『 Recommended Formats and Protocols for Data Exchange 』を使用して、各フィールドのバイト位置と長さを決定します。ファイルを編集する場合、レコード長を長くしないでください。追加した余計なスペースは削除します。アイテムの長さがフィールドの長さ未満の場合、フィールドにスペースをパディングします。フィールドに応じて、右側または左側にパディングします。

ファイルには 1 つのヘッダーと 1 つのトレーラー レコードが含まれます。これらのレコードの間に ALI データ レコードが含まれます。

表 11-2 に、編集することが多いフィールドについて説明します。他のフィールドを変更するには、Cisco ER Web インターフェイスを使用する必要があります。

NENA 3.0 ファイル形式

NENA 3.0 ファイル形式には次の特徴があります。

• レコードは可変長です。

• フィールドはタグとデータの組み合わせであり、任意の順序にすることができます。

• 使用しないフィールドは含まれません。タグの有無は次の影響があります。

– タグを含めない場合、その要素の前の値が何であっても、その値は未変更のままです。

– タグの値が空の場合、その要素の前の値は削除されます。

– タグに空ではない値が含まれる場合、要素の値はその新しい値に変更されます。

• タグはバーティカル バー（|）で区切られます。

• レコードの末尾は事前に定義した文字で示されます。

各フィールドのタグ名と値を決定するには、NENA Doc 02-010『 Recommended Formats and Protocols for Data Exchange 』を参照してください。値がフィールドの最大長を超えないようにしてください。余計なスペースをパディングする必要はありません。

ファイルには 1 つのヘッダーと 1 つのトレーラー レコードが含まれます。これらのレコードの間に ALI データ レコードが含まれます。

表 11-3 に、編集することが多いフィールドについて説明します。他のフィールドを変更するには、Cisco ER Web インターフェイスを使用する必要があります。

Cisco Emergency Responder の詳細なトレースおよびデバッグ情報のイネーブル化

Cisco ER の詳細なトレースおよびデバッグ情報をイネーブルにするには、次の手順を実行します。

手順

ステップ 1 Cisco ER Web インターフェイスから、[Cisco ER Group] > [Server Settings] を選択します。

[Server Settings] ページが開きます。

ステップ 2 左側の列から、デバッグまたはトレース情報を収集する必要があるサーバを選択します。

サーバの設定が表示されます。

ステップ 3 デバッグ パッケージとトレース パッケージのセクションまでスクロールし、シスコ テクニカル サポートから求められたパッケージを選択します。

各セクションのリストは同様です。シスコから求められたリストのパッケージを選択するようにしてください。[Debug] リストで選択したパッケージでは、トレース情報と追加のデバッグ データが生成されます。シスコからすべてのパッケージを選択するように求められた場合、適切なリストで [Select All] をクリックします。

使用できるパッケージには次が含まれます。

• CER_DATABASE：データベース サブシステム。データベース アクセス コードで生成されるログ情報を含みます。

• CER_REMOTEUPDATE：リモート更新サブシステム。サーバ間の更新を管理します。

• CER_PHONETRACKINGENGINE：電話機のトラッキング サブシステム。電話機のトラッキングとスイッチ ポートおよび電話機の更新プロセスを実行します。

• CER_ONSITEALERT：オンサイト アラート担当者に通知するためのオンサイト アラート サブシステム。

• CER_CALLENGINE：コール エンジン サブシステム。コールのルーティングとプロセスを行います。

• CER_SYSADMIN：システム管理者 Web インターフェイス サブシステム。

• CER_TELEPHONY：電話機サブシステム。Cisco Unified CM とのインタラクションに使用されます。

• CER_AGGREGATOR：アグリケータ モジュールは、電話機のトラッキング エンジンを使用したすべての Cisco ER サーバ通信とデータ処理を対象にします。このモジュールには、クラスタ、Administration、Cisco IP SoftPhone、コール ルーティングなど、サブシステムの追跡したデータの検索とルックアップが含まれます。

• CER_GROUP：Cisco ER サーバ グループ サブシステム。グループ内のサーバ間の通信に使用されます。

• CER_CLUSTER：サーバ クラスタ サブシステム。クラスタ内の Cisco ER グループ間の通信に使用されます。

ステップ 4 [Update] をクリックして、変更内容の保存とアクティブ化を行います。

要求したトレースおよびデバッグ情報の生成が開始されます。

（注） Cisco ER のトレースは、Cisco ER Serviceability Web インターフェイスまたはコマンド ライン インターフェイスを使用して収集できます。

ステップ 5 デバッグおよびトレース情報の収集を完了したら、デバッグとトレースを無効にする選択を行ったセクションごとに、[Clear All] をクリックします。次に [Update] をクリックして変更を完了します。

関連項目

• 「Server Settings for CERServerGroup」

• 付録 B「Cisco Emergency Responder のサービスアビリティ Web インターフェイス」

• 付録 F「コマンド ライン インターフェイス（CLI）」

syslog のイネーブル化

トレースおよびデバッグ情報を収集するには、Cisco ER の syslog をイネーブルにする必要があります。

Cisco ER の syslog をイネーブルにするには、「syslog からの情報収集」を参照してください。

CDP サポートの概要

Cisco ER では、アクティブなインターフェイスで、指定したマルチキャスト アドレス宛てに、Cisco Discovery Protocol（CDP）を使用して、CDP メッセージを定期的に送信します。これらのメッセージには、デバイスの識別、インターフェイス名、システム機能、SNMP エージェント アドレス、存続可能時間などの情報が含まれます。CDP をサポートするすべてのシスコ デバイスは、この定期的なメッセージをリッスンして、Cisco ER サーバの位置を確認できます。

CiscoWorks2000 Server は、CDP を介して提供された情報を使用して、Cisco ER サーバ、Campus Manager アプリケーション、および Topology Service を検出し、Cisco ER サーバを表示するトポロジ マップを構築できます。

Cisco ER サーバは、CDP メッセージの送出に加え、CDP をサポートする電話機の位置確認に CDP を使用します。Cisco ER で、スイッチに対する SNMP クエリーを介してこの情報を入手できるように、スイッチで CDP をイネーブルにする必要があります。

表 11-4 に、Cisco ER ハードウェア プラットフォームの SNMP OID を示します。

Cisco Emergency Responder サブシステムのステータスの監視

Cisco ER は SYSAPPL-MIB をサポートします。SYSAPPL-MIB を使用すると、CiscoWorks2000 またはサードパーティの SNMP ブラウザから次の Cisco ER コンポーネントに関する情報にリモート アクセスできます。

• Cisco ER サーバ

– CERServer.exe

• Cisco PhoneTrackingEngine

– CERPhoneTracking.exe

• MSQL Server 関連のサービス

SYSAPPL-MIB は SNMP を使用します。Cisco ER は次の SYSAPPL-MIB テーブルをサポートします。

• SysApplInstallPkgTable：メーカー、製品名、インストールされているバージョン、インストールした日付、位置などのアプリケーション情報を提供します。これは、関連する [Application Administration Web] ページ（適用される場合）にアクセスする部分 URL です。

• SysApplRunTable：アプリケーションの起動時間と実行時のステータスが記述されます。

• SysApplInstallElmtTable：個々のアプリケーション要素、または関連する実行可能要素が記述されます。これは SysApplInstallPkgTable に定義されているアプリケーションから構成されます。

• SysApplElmtRunTable：ホスト システムで現在実行されているプロセス、または実行可能要素が記述されます。

syslog からの情報収集

Cisco Syslog Collector を使用するように Cisco ER を設定できます。Cisco Syslog Collector と Cisco Syslog Analyzer は、Resource Management Essentials パッケージの一部として、CiscoWorks2000 と共に提供されます。また、Cisco ER からの syslog の出力を採用して、他のネットワーク管理システムに使用することもできます。

Cisco Syslog Collector は、Cisco ER にレポートされるメッセージの共通システム ログを保守します。

Cisco Syslog Analyzer は、すべてのイベントを効率的に制御および表示するため、読み取りや解釈が容易で、システム メンテナンスと問題解決にも簡単に利用できます。

Cisco Syslog Collector のインストールと設定については、CiscoWorks2000 のマニュアルを参照してください。

syslog をイネーブルにするには、次の手順を実行します。

手順

ステップ 1 [System] > [Cisco ER Group Settings] を選択します。

[Cisco ER Group Settings] ページが表示されます。

ステップ 2 [Enable Syslog] で [enable] を選択します。

ステップ 3 [Syslog Server] フィールドにサーバの完全修飾 DNS 名を入力します（server.domain.com など）。

ステップ 4 [Update Settings] をクリックして、変更を保存します。

直後に syslog へのメッセージの書き込みが開始されます。

関連項目

• 「Cisco ER Group Settings」