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

電話機が検出されない

Cisco Emergency Responder（Emergency Responder）が Cisco Unified Communications Manager（Cisco Unified CM）に対するホーミング処理中の電話機を検出していない場合、すべての Cisco Unified CM が SNMP で到達可能であり、NMP 設定が正しいことを確認します。Cisco Unified CM が SNMP で到達不能であっても Emergency Responder のログにはイベントが記録されます。

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

手順

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

ステップ 2 Cisco Unified CM を正常に ping することができる場合、Cisco Unified CM 上で SNMP 設定が正しいことを次のように確認します。

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

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

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

ステップ 3 Emergency Responder サーバで次の 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 特定のスイッチで更新プロセスを実行するには、[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 に電話機が表示されなくなることがある

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

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

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

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

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

受信側の Emergency Responder グループがモニタしているスイッチに 1 台の電話機が接続されている場合、これは問題にはなりません。ただし、シェアド ライン アピアランスを使用する複数の電話機が、受信側の Emergency Responder グループにモニタされているスイッチに接続している場合、Emergency Responder は緊急コールを発信した電話機を推測する必要があります。シェアド ライン アピアランスを使用するすべての電話機が同じ 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（Emergency Responder）では、コール ルーティングのスイッチ ポートの関連付けにより高いプライオリティが付与されます。Emergency Responder によって任意のエンドポイント（802.11b エンドポイントを含む）のスイッチ ポート マッピングが検出された場合、緊急コールのルーティングにスイッチ ポートが使用されます。スイッチ ポート マッピングが検出されない場合、または対応するスイッチ ポートに ERL が設定されていない場合、Emergency Responder 1.2 はサブネット ERL 設定を使用して緊急コールをルーティングします。

Emergency Responder 8.6 は次のような状況下ではスイッチ ポートの背後で 802.11b エンドポイントを検出することに注意してください。

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

• 特定のスイッチの CAM トラッキングが Emergency Responder でイネーブルです。

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

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

関連項目

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

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

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

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

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

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

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

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

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

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

1. Emergency Responder 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 のルート パターンについて確認します。「ERL のルート パターンの作成」 を参照してください。

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

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

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

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

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

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

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

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

– 「「ERL の作成」（P.4-33）」

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

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

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

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

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

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

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

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

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

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

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

PSAP コールバック エラー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

推奨処置 この問題を回避するには、Emergency Responder に設定されている Cisco Unified CM で、CTI ポートにつき 1 行のみ設定します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Transition Alert（移行アラート）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

件名 ：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 を実行している場合、Emergency Responder ユーザ ページの [Calling Party Number] チェックボックスがオンであることを確認します。

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

3. Emergency Responder アプリケーション ユーザが「Standard CTI Allow Calling Number Modification」ユーザ グループに追加されます。

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

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

件名： Emergency Calling Party Modification Failed (Emergency ResponderServer: <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 の場合、Emergency Responder ユーザ ページの [Enable Calling Party Number Modification] チェックボックスをオンにします。このフラグをイネーブルにした後は、変更内容を反映するために Emergency Responder サービスを再起動します。

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

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

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

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

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

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

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

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

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

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

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

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

関連項目

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

Cisco Unified Operations Manager の使用

Emergency Responder システムの動作状況を継続的にモニタするには、Cisco Unified Operations Manager 2.01 を使用します。

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

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

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

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

Emergency Responder でスイッチまたはスイッチ ポートの設定するとき、次の問題が発生する可能性があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手順

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

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

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

Cisco Emergency Responder Admin Utility の使用

Emergency Responder Admin Utility Tool を使用して、次の作業を実行できます。

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

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

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

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

Cisco Emergency Responder Admin Utility Tool の使用方法

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

手順

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

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

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

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

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

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

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

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

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

手順

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

ステップ 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 ファイルが破損した場合、このコマンドは、そのファイルを再構築してレプリケーションの修復も試行します。

ログを使用してデータベースに関する問題を解決するには、Emergency Responder 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 は、サブスクライバの FQDN（完全修飾ドメイン名）ではなく、サブスクライバのホスト名になります。

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

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

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

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

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

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

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

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

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

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

• Emergency Responder サーバを再起動します。

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

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

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

ALI データ レコードの修正

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

はじめる前に

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

手順

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

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

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

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

テキスト エディタで 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 に、編集することが多いフィールドについて説明します。他のフィールドを変更するには、Emergency Responder Web インターフェイスを使用する必要があります。

NENA 3.0 ファイル形式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手順

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

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

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

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

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

（注） Emergency Responder のトレースは、Emergency Responder Serviceability Web インターフェイスまたは CLI を使用して収集できます。

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

関連項目

• 「Server Settings for Emergency ResponderServerGroup」

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

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

syslog のイネーブル化

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

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

CDP サポートの概要

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

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

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

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

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

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

• Cisco Emergency Responder Server

– CERServer.exe

• Cisco PhoneTrackingEngine

– CERPhoneTracking.exe

• MSQL Server 関連のサービス

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

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

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

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

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

syslog からの情報収集

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

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

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

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

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

手順

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

[Emergency Responder Group Settings] ページが開きます。

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

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

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

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

関連項目

• 「Cisco Emergency Responder Group Settings」