Cisco Emergency Responder 8.6 アドミニストレーション ガイド
Cisco Emergency Responder のトラブルシューティング
Cisco Emergency Responder のトラブルシューティング
発行日;2012/05/07 | 英語版ドキュメント(2012/01/04 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 4MB) | フィードバック

目次

Cisco Emergency Responder のトラブルシューティング

電話機に関する問題のトラブルシューティング

電話機が検出されない

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

CiscoEmergencyResponder に電話機が表示されなくなることがある

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

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

緊急コールに関する問題のトラブルシューティング

緊急コールが CiscoEmergencyResponder で代行受信されない

ELIN が PSAP に伝送されない

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

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

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

PSAP コールバック エラー

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

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

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

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

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

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

電子メール アラートのトラブルシューティング

Emergency Call Alert(緊急コール アラート)

Transition Alert(移行アラート)

Tracking Failure(トラッキング エラー)

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

Failed to Establish Communication with CiscoEmergency Responder Phone Tracking Engine(CiscoEmergency Responder Phone Tracking Engine との通信の確立に失敗しました)

Lost Communication with CiscoEmergency Responder Phone Tracking Engine(CiscoEmergency Responder Phone Tracking Engine との通信が失われました)

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

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

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

Web アラートのトラブルシューティング

CiscoEmergencyResponder システムおよび管理に関する問題のトラブルシューティング

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

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

Cisco Unified Operations Manager の使用

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

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

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

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

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

CiscoEmergency Responder Admin Utility の使用

CiscoEmergency Responder Admin Utility Tool の使用方法

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

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

CiscoEmergencyResponder システムに関する問題のトラブルシューティング

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

CiscoEmergencyResponder Cluster での CiscoEmergencyResponder グループおよびサーバの特定

クラスタ間の電話機の移動

CiscoEmergencyResponder サーバの起動と停止

ALI データのアップロードのトラブルシューティング

ALI データ レコードの修正

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

NENA 3.0 ファイル形式

コール履歴ログの収集

トレースおよびデバッグ情報の収集

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

syslog のイネーブル化

イベント メッセージの表示

パフォーマンスの管理

ネットワーク管理システムとの統合

CDP サポートの概要

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

syslog からの情報収集

データのバックアップと復元

Data Migration Assistant のトラブルシューティング

Linux アップグレードのトラブルシューティング

Cisco Emergency Responder のトラブルシューティング

ここでは、Cisco Emergency Responder(Emergency Responder)で発生する可能性がある問題に対処し、解決方法を示します。また、問題の特定の解決に関連する他の作業についても説明します。

「電話機に関する問題のトラブルシューティング」

「緊急コールに関する問題のトラブルシューティング」

「Cisco Emergency Responder システムおよび管理に関する問題のトラブルシューティング」

「Cisco Emergency Responder Cluster での Cisco Emergency Responder グループおよびサーバの特定」

「Cisco Emergency Responder サーバの起動と停止」

「ALI データのアップロードのトラブルシューティング」

「コール履歴ログの収集」

「トレースおよびデバッグ情報の収集」

「イベント メッセージの表示」

「パフォーマンスの管理」

「ネットワーク管理システムとの統合」

「データのバックアップと復元」

「Data Migration Assistant のトラブルシューティング」

「Linux アップグレードのトラブルシューティング」

電話機に関する問題のトラブルシューティング

ここでは、ERL への電話機の割り当ておよび電話機の管理に関する問題の解決に役立つ情報について説明します。

「電話機が検出されない」

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

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

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

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

電話機が検出されない

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 を送信します。

utils network ping <ipaddress of CUCM>
 

ステップ 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 で代行受信されない」

「ELIN が PSAP に伝送されない」

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

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

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

「PSAP コールバック エラー」

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

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

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

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

緊急コールが 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 Responder で生成される電子メール アラートに関する問題の解決に役立つ情報について説明します。

「Emergency Call Alert(緊急コール アラート)」

「Transition Alert(移行アラート)」

「Tracking Failure(トラッキング エラー)」

「Failed To Get Provider(プロバイダーの取得に失敗しました)」

「Failed to Establish Communication with Cisco Emergency Responder Phone Tracking Engine(Cisco Emergency Responder Phone Tracking Engine との通信の確立に失敗しました)」

「Lost Communication with Cisco Emergency Responder Phone Tracking Engine(Cisco Emergency Responder Phone Tracking Engine との通信が失われました)」

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

「Emergency Call Could Not be Routed(緊急コールをルーティングできませんでした)」

「Calling Party Modification Failed(発信側の修正に失敗しました)」

Emergency Call Alert(緊急コール アラート)

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

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

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

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

Subject: Emergency Call Alert -- Extn # 332101 (Generated by Backup Cisco ER)
Message: EMERGENCY CALL DETAILS (Generated by Emergency Responder)
Caller Extension:332101
Zone/ERL :Z1
Location :ddd
Call Time :June 2, 2003 3:47:30 PM IST

Transition Alert(移行アラート)

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

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

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

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

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

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

Subject: Transition Alert: Cisco ER Backup is active
Message:
Backup Cisco ER <<CER HostName>> has taken control as Active Cisco ER.
Transition Time :June 2, 2003 3:57:12 PM IST
 

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

Subject: Transition Alert: Cisco ER Master is active
Message:
Master Cisco ER <<Emergency Responder Server HostName>> has taken control as Active Cisco ER.
Transition Time :June 2, 2003 3:57:12 PM IST

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 アラートの例を示します。

Subject: CER Phone Tracking failed to track some devices
Message:
CER Phone Tracking could not get information [using SNMP] from 2 Cisco Cisco Unified CM(s) and 1 Switch(es)
Check Event Viewer on CER Server for details.

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 電子メールが送信されます。

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

Subject: Failed to get JTAPI Provider for Cisco Unified CM <<CCM IP/Host Name>> (Generated by Backup Cisco ER)
Message:
Please check the following:
1) Check if the Cisco Unified CM is connected to the CER server.
2) Check if the configured Call Manager is running a version supported by the CER server.
3) Check if the given login credentials are correct:
CTI Manager Host Name:<<CCM IP/HostName>>

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 アラートの例を示します。

Subject: CER Server failed to establish communication with CER Phone Tracking Engine.
Message:
CER Server could not communicate with CER Phone Tracking Engine.

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 アラートの例を示します。

Subject: CER Server lost communication with CER Phone Tracking Engine
Message:
CER Server could not communicate with CER Phone Tracking Engine.

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

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

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

Subject: CER Server failed to send Unlocated Phones details to Remote CER Server Group.
Message:
CER Server failed to send Unlocated Phones to Remote CER Server Group. Please ensure that the CER servers are not found under more than one CER Server Group.
CER Servers in Remote Server Group:<< CERServer HostNames >>

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 には次のメッセージが表示されます。

Emergency call from <extn> could not be routed using the following route patterns
 
<RoutePattern1>
<RoutePattern2>
*****************
Call Routed to <RoutePattern-X>
 
Please check the availability of the above routes. Also, check for the following error conditions:
 
1. If FAC and/or CMC are configured on the route patterns used for Cisco ER, please disable them.
2. If the “Calling Party Number Modification” flag on the CER user page in the Cisco Unified CM is not enabled, please enable it.

 

ソリューション

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 には次のメッセージが表示されます。

Emergency Call from <Caller Extn> has been routed to default ERL because the calling party modification failed.
Please make sure that the checkbox “Enable Calling Party Number Modification: is checked on the Cisco Unified CM user page for the CER user. PSAP callbacks MAY NOT work correctly. The CER service will need to be restarted once the flag is checked on the Cisco Unified CM User page.

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

Web アラートのトラブルシューティング

Web アラートの受信時に次の問題が発生する可能性があります。

症状 Web アラートは 30 秒ごとに更新を続けます。この問題を確認するには、ブラウザでステータスを確認します。このモード中は、ステータスに更新までの残り時間(秒)が表示されます。

推奨処置 同じクライアント マシンで別の Web アラート画面が開いているかどうかを確認します。リアルタイム モードで 1 台のクライアント マシンから操作できるのは 1 つのブラウザのみです。余計なブラウザは削除します。

Cisco Emergency Responder システムおよび管理に関する問題のトラブルシューティング

ここでは、サーバと Web サーバの問題など、Emergency Responder システムとその管理に関する問題の解決に役立つ情報について説明します。

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

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

「Cisco Unified Operations Manager の使用」

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

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

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

「Cisco Emergency Responder Admin Utility の使用」

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

「Cisco Emergency Responder システムに関する問題のトラブルシューティング」

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

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

インストール処理でパブリッシャを確認できない場合(「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 Emergency Responder システムに関する問題のトラブルシューティング

ここでは、Emergency Responder システムの通常の操作で発生する可能性があるいくつかの問題と、Emergency Responder サーバ、グループ、およびクラスタに関連する設定画面について説明します。

症状 Emergency Responder クラスタ内のコール ルーティングが失敗するか、Emergency Responder が電話機を正しく検出しません。

推奨処置 Emergency Responder クラスタ内のすべての Emergency Responder サーバをホスト名で検出できること、およびそのすべてのサーバに他のすべての Emergency Responder サーバからネットワーク上で到達可能であることを確認します。

推奨処置 すべての Emergency Responder が Emergency Responder クラスタ DB ホストに到達可能であること、およびクラスタ DB パスワードがクラスタ内のすべてのサーバで同じであることを確認します。

症状 Emergency Responder の起動後に終了します。

考えられる原因 すでに使用中の TCP ポートを使用するように Emergency Responder を設定しました。

推奨処置 Windows Event Viewer で、「CER could not open socket at port peer-tcp-port , Exiting」というメッセージを確認します。このメッセージがある場合、異なる TCP ポートを使用するように Emergency Responder グループ設定を変更します。手順については、「Cisco Emergency Responder サーバ グループの設定」を参照してください。

症状 [Emergency Responder Groups in Cluster] 画面がロードされず、「Cannot connect to cluster DB host」というエラーが表示されます。

推奨処置 クラスタ DB ホストをホスト名で検出できることを確認します。

指定したクラスタの db ホスト パスワードが、クラスタ内のすべての Emergency Responder サーバ グループで同じであることを確認します。

詳細については、「8.6 Cisco Emergency Responder クラスタおよびクラスタ DB ホスト」 を参照してください。

関連項目

「Cisco Emergency Responder Cluster での Cisco Emergency Responder グループおよびサーバの特定」

「Cisco Emergency Responder サーバの起動と停止」

「イベント メッセージの表示」

「パフォーマンスの管理」

「データのバックアップと復元」

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 設定を更新します。

Cisco Emergency Responder Cluster での Cisco Emergency Responder グループおよびサーバの特定

Emergency Responder サーバの管理者のインターフェイスに接続している場合、サーバと Emergency Responder グループのスタンバイ サーバの詳細を表示するには、[System] > [Cisco ER Group Settings] を選択します。

また、Emergency Responder グループと、同じ Emergency Responder クラスタ内にある Emergency Responder サーバを特定することもできます。クラスタ内の他の Emergency Responder グループを表示するには、[System] > [Cisco ER Groups in Cluster] を選択します。[Emergency Responder Groups in Cluster] ページで、表示するグループを選択します。グループ内の Emergency Responder サーバが表示されます。これらのサーバの詳細を表示するには、サーバのいずれかで実行されている Emergency Responder Administration インターフェイスにログインし、[System] > [Cisco ER Groups in Cluster] を選択し、グループのリストから表示するグループを選択します。

Emergency Responder グループをアンインストールする必要がある場合、まずこのページを使用して Emergency Responder クラスタからグループを削除します。グループを削除するには、システム管理者としてログインする必要があります。クラスタからグループを削除すると、Emergency Responder Cluster DB からグループのエントリのみが削除されます。グループのサーバから Emergency Responder は削除されません。

関連項目

「Cisco Emergency Responder Server Groups in Cluster」

クラスタ間の電話機の移動

次のシナリオでは、Emergency Responder クラスタの動作と、クラスタ間で移動する電話機を Emergency Responder で扱う方法について説明します。

Server Group A(SGA)には、SGA 以外に移動する電話機(Phone_1)があります。

Emergency Responder は Server Group B(SGB)で Phone_1 を検出します。

SGA の [Unlocated Phones] ページに SGB の電話機が表示されます。

SGB の両方の Emergency Responder サーバ(パブリッシャとサブスクライバ)が停止しても、SGA には SGB の Phone_1 が表示されたままになります。

このときに Phone_1 から発信されたコールは SGB にリダイレクトされ、Emergency Responder サーバがその SGB 内に存在しない場合、Emergency Responder は同じ手順を実行してこの緊急コールをルーティングします。

また、両方の SGB Emergency Responder サーバが停止している場合、Phone_1 は、SGB 内の他の電話機と同様に扱われます。

Phone_1 が Server Group C(SGC)に移動した場合:

SGA、SGC の順で次回の増分電話機のトラッキングが実行されると検出されます。

[Unlocated Phones] ページでは、Phone_1 から SGC への関連付けが変更されます。

Phone_1 が元の SGA に移動すると、次回の増分電話機トラッキングで検出され、対応するスイッチ ポートの下に表示されます。

Cisco Emergency Responder サーバの起動と停止

Emergency Responder をインストールすると、コンピュータの電源投入またはリブート時に毎回自動的に Emergency Responder サーバが設定されます。ただし、コンピュータの電源オフやリブートを使用しなくても、Emergency Responder Serviceability Web インターフェイスを介して Emergency Responder サーバの停止と再起動を行うことができます。たとえば、問題のデバッグを試みる場合にこの操作が役立つことがあります。

Emergency Responder サーバを起動または停止するには、次の手順を実行します。

手順


ステップ 1 Emergency Responder Serviceability Web インターフェイスにログインし、[Tools] > [Control Center] を選択します。

[Control Center Services] ページが開き、すべての Emergency Responder サービスとそれぞれの現在のステータスが表示されます。

ステップ 2 サービス名の左側にあるオプション ボタンをクリックし、[Start]、[Stop]、または [Restart] をクリックして、サービスで目的のアクションを実行します。最新情報で画面を更新するには、[Refresh] をクリックします。


) ボタンは、そのアクションを実行可能な場合にのみ表示されます。たとえば、[Start] は、サービスが現在停止している場合にのみ表示されます。



 


) Cisco Tomcat および Cisco IDS サービスは、Control Center から開始または停止できません。これらのサービスを開始または停止するには、utils service コマンドを使用します。詳細については、「utils service」 を参照してください。


表 11-1 では、[Control Center Services] ページに表示されるアイコンの意味について説明します。

 

表 11-1 Cisco Emergency Responder の Control Center のアイコン

アイコン
意味

 

Emergency Responder サーバまたは Emergency Responder Phone Tracking Engine が起動し、正常に機能しています。

 

管理者が Emergency Responder サーバの Emergency Responder Phone Tracking Engine を停止しました。

関連項目

「Control Center」

ALI データのアップロードのトラブルシューティング

定期的に、ALI データを書き出し、サービス プロバイダーに送信する必要があります。ALI データは、ローカル ネットワークから正しい PSAP に緊急コールをルーティングし、緊急コールの位置に関する情報を PSAP に提供するために使用されます。

Emergency Responder では、多様な NENA 形式で ALI データを書き出すことができます。使用すべき形式については、サービス プロバイダーにお問い合わせください。

アップロード プロセス時に、一部の ALI データ レコードが正しくアップロードされないことがあります。この場合、お使いのサービス プロバイダーはエラーのリストを提供できるはずです。また、サービス プロバイダーのデータ アップロード ソフトウェアの使用時にエラーが表示される可能性もあります。誤りのあるレコードを修正し、ALI データの書き出しファイルを再送信する必要があります。レコードを修正するには、場合によってはエラーのレコードを手動で編集する必要があります。

ここでは、ALI データ レコードを修正するための一般的な手順と、多様な NENE 形式ファイルの編集方法について説明します。

「ALI データ レコードの修正」

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

「NENA 3.0 ファイル形式」

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 インターフェイスを使用する必要があります。

 

表 11-2 NENA 2.0 および 2.1 の一般的なフィールド

フィールド
説明

Function Code

位置: バイト 1。

長さ: 1 文字。

説明: レコードのデータベース関数。次のいずれかになります。

I :新しい ALI レコードを挿入します

C :既存のレコードを変更します。C を使用するには、レコードのアップロードに 1 回は成功している必要があります。アップロードに成功したことがないレコードを修正する場合、C を I に変更します。

D :レコードを削除します。Emergency Responder は、Emergency Responder 設定から ALI を削除した後に作成される書き出しファイルに、削除レコードを 1 回だけ生成します。レコードを再生成する必要がある場合、以前の書き出しファイルからカット アンド ペーストする(そしてレコード カウントを調整する)か、Emergency Responder で ALI を再作成し、保存してデータを書き出してから、ALI を削除し、もう一度データを書き出します。

Cycle Counter

位置: バイト 62 ~ 67。

長さ: 6 文字。

説明: サービス プロバイダーに送信するファイルのシーケンス番号(1、2 など)。番号は右寄せにし、先頭にスペースを付加します。サービス プロバイダーによっては、このフィールドを無視することがあります。

Record count

位置: トレーラー レコードのバイト 62 ~ 70。

長さ: 9 文字。

説明: サービス プロバイダーに送信するファイルに含まれるレコードの合計数(1、2 など)。数は右寄せにし、先頭にスペースを付加します。

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 インターフェイスを使用する必要があります。

 

表 11-3 NENA 3.0 の一般的なフィールド

フィールド
説明

Function Code

タグ: FOC。

説明: レコードのデータベース関数。次のいずれかになります。

I :新しい ALI レコードを挿入します(FOCI)。

C :既存のレコードを変更します(FOCC)。C を使用するには、レコードのアップロードに 1 回は成功している必要があります。アップロードに成功したことがないレコードを修正する場合、C を I に変更します。

D :レコードを削除します(FOCD)。Emergency Responder は、Emergency Responder 設定から ALI を削除した後に作成される書き出しファイルに、削除レコードを 1 回だけ生成します。レコードを再生成する必要がある場合、以前の書き出しファイルからカット アンド ペーストする(そしてレコード カウントを調整する)か、Emergency Responder で ALI を再作成し、保存してデータを書き出してから、ALI を削除し、もう一度データを書き出します。

Cycle Counter

タグ: CYC。

説明: サービス プロバイダーに送信するファイルのシーケンス番号(CYC1、CYC2 など)。サービス プロバイダーによっては、このフィールドを無視することがあります。

Record count

タグ: ヘッダー レコードとトレーラー レコードの REC。

説明: サービス プロバイダーに送信するファイルに含まれるレコードの合計数(REC1、REC2 など)。

コール履歴ログの収集

Emergency Responder では大量のコール履歴ログが保守されます。ログには処理された各緊急コールのエントリが含まれます。コール履歴情報は、管理インターフェイスとユーザ インターフェイスから表示できます。

Emergency Responder では、発信された緊急コールの履歴がデータベースに保存されます。プライマリ Emergency Responder サーバ(パブリッシャ)がアクティブではない場合、緊急コールはバックアップ Emergency Responder サーバ(サブスクライバ)によって処理されます。これら両方のサーバがアクティブになると、レプリケーションによって両方のコール履歴レコードは同期されます。そのため、コール履歴はどちらの Emergency Responder サーバでも表示できます。

コール履歴レコードをダウンロードするには、コール履歴を表示するテーブルの上部にある[Download] ボタンをクリックします。これらのレコードは Excel(.xls)形式でダウンロードできます。

トレースおよびデバッグ情報の収集

Emergency Responder で発生した問題についてシスコ テクニカル サポートに問い合わせると、トレースおよびデバッグ情報の収集が求められることがあります。

トレースおよびデバッグ情報を収集すると Emergency Responder のパフォーマンスに影響があるため、シスコから求められた場合にのみ、トレースとデバッグを有効にしてください。生成される情報は、シスコが製品の問題を解決するために使用されます。

詳細については、次の項を参照してください。

「トレースおよびデバッグ情報の収集」

「syslog のイネーブル化」

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 からの情報収集」を参照してください。

イベント メッセージの表示

Emergency Responder Serviceability Web インターフェイスを使用して Emergency Responder イベント メッセージを確認すると、ソフトウェアの問題の診断に役立ちます。

Emergency Responder イベントの表示については、「Event Viewer の使用」を参照してください。

[Find and List Events] ページの詳細については、「Event Viewer」を参照してください。

パフォーマンスの管理

サポートされる Cisco MCS Unified CM Appliance プラットフォームとその Emergency Responder のスケーラビリティについては、『 Release Notes for Cisco Emergency Responder 8.6 』を参照してください。

Emergency Responder が WAN リンクのスイッチを管理している場合、Emergency Responder パフォーマンスに影響が出ることがあります。Emergency Responder は必ず管理対象のスイッチに SNMP 要求を送信するため、WAN の遅延が SNMP タイムアウトの原因になり、電話機とスイッチの変更を追跡するために必要な時間が増える可能性があります。場合によっては、SNMP パラメータの調整が必要です。詳細については、「SNMP 接続の設定」を参照してください。

ネットワーク管理システムとの統合

CiscoWorks2000 または他の SNMP ベースのネットワーク管理システムを使用して、Emergency Responder サーバのステータスをリモート管理できます。CiscoWorks2000 は標準のシスコ ネットワーク管理システムですが、Emergency Responder には付属していません。CiscoWorks2000、Campus Manager、および Topology Service の詳細については、次の URL にあるマニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/netmgtsw/tsd_products_support_category_home.html

次のトピックでは、Emergency Responder をネットワーク管理システムと統合するときに役立つ情報について説明します。

「CDP サポートの概要」

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

「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 を示します。

 

表 11-4 Cisco Emergency Responder ハードウェア プラットフォームの OID

ハードウェア プラットフォーム
SNMP OID

Cisco MCS-7815-I

1.3.6.1.4.1.9.1.582

Cisco MCS-7825-H

1.3.6.1.4.1.9.1.583

Cisco MCS-7825-I

1.3.6.1.4.1.9.1.746

Cisco MCS-7835-H

1.3.6.1.4.1.9.1.584

Cisco MCS-7835-I

1.3.6.1.4.1.9.1.585

Cisco MCS-7845-H

1.3.6.1.4.1.9.1.586

Cisco MCS-7845-I

1.3.6.1.4.1.9.1.587

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」

データのバックアップと復元

Emergency Responder 8.6 は、システム データのバックアップと復元に Disaster Recovery System を使用します。

Disaster Recovery System の使用方法については、「Cisco Emergency Responder 8.6 Disaster Recovery System の設定」を参照してください。

関連項目

「コール履歴ログの収集」

Data Migration Assistant のトラブルシューティング

Data Migration Assistant(DMA)は 2 つのフェーズで動作します。第 1 フェーズの Database では、次のフォルダが tar ファイルにバックアップされます。

export

import

etc

nena_msag_records

第 2 フェーズでは、バックアップ Emergency Responder データベースのコンテンツが、Emergency Responder 8.6 データベース スキーマに対して検証されます。

症状 DMA のバックアップと検証に失敗しました。

推奨処置 次のチェック リストを確認します。

MSDE が実行されているかどうかを確認します。データベースが実行されていない場合、バックアップは成功しません。

バックアップ対象のノードが Sbscriber ノードではなく Publisher ノードであることを確認します。Subscriber ノードでは DMA バックアップを実行できません。

CSA が実行されていないことを確認します。CSA が実行されている場合、停止してからバックアップを開始します。

症状 DMA のバックアップは成功しますが、検証に失敗します。

推奨処置 次のチェック リストを確認します。

CSA が実行されていないことを確認します。CSA が実行されている場合、停止してからバックアップを開始します。CSA が DMA 操作に干渉します。

以降の分析ついて、データ検証ログを収集します。この場合、Emergency Responder 8.6 へのマイグレートが成功するには、場合によってはデータベースに含まれるデータを事前に変更する必要があります。

DMA ログは次の場所にあります。

exportdb.log および migratecCERCSV.log は C:¥CiscoWebs¥DMA¥Bin にあります

installdbw1.log、installdbw1.log.err、installdbccm.log、installdbccm.log.err、および dbl_INSTALLDBxxxxxx.txt は C:¥Program Files¥Cisco¥Trace¥DBL にあります

ログ ファイルは C:¥Program Files¥Cisco¥Trace¥DMA にあります

検証ログ ファイルは次のとおりです。

exportdb.log

installdbw1.log

installdbw1.log.err

dbl_INSTALLEDBxxxxxx.txt

Linux アップグレードのトラブルシューティング

Emergency Responder 8.6 の今後のバージョンにアップグレードする場合、特定の問題が発生することがあります。ここでは、このような問題の原因と推奨されるアクションについて説明します。

症状 [Install / Upgrade] メニューの最初のページでアップグレード パッチの詳細を入力した後に、「No valid upgrade options found」というエラー メッセージが表示されます。

推奨処置 パブリッシャのアップグレード前に、サブスクライバはアップグレードしないでください。Emergency Responder サーバ グループのアップグレード時には、必ずパブリッシャからアップグレードします。

推奨処置 実際に指定したローカルまたはリモート パスに、有効で署名付きの ISO イメージが含まれ、拡張子が .sgn.iso であることを確認します。

症状 [Install / Upgrade] メニューの最初のページでリモートの場所にあるアップグレード パッチの詳細を入力すると、「Incorrect user name/password」というエラー メッセージが表示されます。

推奨処置 リモートの SFTP/FTP の場所について入力したユーザ名とパスワードが正しいことを確認します。

症状 ISO イメージを Emergency Responder サーバにダウンロードしましたが、チェックサム値が一致しません。

推奨処置 Cisco.com から新しく ISO イメージをダウンロードし、もう一度アップグレードを試行します。

症状 アップグレードはキャンセルされましたが、システムをリブートするように求める警告メッセージが表示されます。

推奨処置 アップグレード時に、Emergency Responder サーバ上の特定のサービス(アップグレードがキャンセルされたタイミングによって決まります)が停止した可能性があります。この場合、サーバをリブートすることが強く推奨されます。