Cisco Emergency Responder 8.7 アドミニストレーション ガイド
Cisco Emergency Responder の計画
Cisco Emergency Responder の計画
発行日;2012/11/20   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

目次

Cisco Emergency Responder の計画

Cisco Emergency Responder(Emergency Responder)は、緊急コールに効率的に応答したり、緊急コールの処理について地方自治体の規定を順守したりできるように、テレフォニー ネットワークで緊急コールを管理するのに役立ちます。 北米では、その法令は、「Enhanced 911(E911)」と呼ばれています。 同様の規定が他の国やロケールに存在します。

緊急コールの規定は、国、地域、州、あるいは都市圏においても場所によって異なることがあるため、Emergency Responder は、緊急コール設定を特定のローカル要件に適合させるための柔軟性を備えています。 ただし、規定が場所ごとに異なり、セキュリティ要件が企業ごとに異なるため、法的ニーズおよびセキュリティ ニーズに適合するように、Emergency Responder を配置する前に入念な計画と調査を行う必要があります。

この章の構成は、次のとおりです。

Enhanced 911(E911)について

Enhanced 911(E911)は、北米の標準的な緊急コールである基本型 911 の拡張版です。 次の各項では、E911 の要件および用語について説明します。

Enhanced 911 の要件の概要

Enhanced 911(E911)は、標準的な緊急コールである基本型 911 を拡張し、信頼性をさらに高めたものです。

北米で基本型 911 を使用している場合、発信者が 911 をダイヤルすると、コールが Public Safety Answering Point(PSAP)にルーティングされ、911 オペレータが呼び出されます。 PSAP は発信者と話をし、警察、消防署、または救急車チームの派遣などの、適切な緊急応答を手配します。

E911 では、次の要件に基づいてこの標準が拡張されています。

  • 発信者のロケーションに基づいて緊急コールをローカル PSAP にルーティングする必要がある。 (基本型の 911 では、コールは任意の PSAP にルーティングされる必要があるだけで、必ずしもローカル PSAP にルーティングされるわけではありません)。
  • 発信者のロケーション情報を緊急オペレータの端末に表示する必要がある。 この情報は、自動ロケーション情報(ALI)データベースを照会することによって取得されます。

E911 では、発信者のロケーションは緊急ロケーション識別番号(ELIN)によって特定されます。これは、緊急コールが切断された場合、または PSAP が発信者と再度話す必要がある場合に、PSAP が緊急発信者に再度連絡を取るためにダイヤルできる電話番号です。 緊急コールは、この番号に関連付けられたロケーション情報に基づいて PSAP にルーティングされます。 オフィス システムなどのマルチラインの電話システムの場合、電話機を緊急応答ロケーション(ERL)にグループ化することで、複数の電話機を ELIN と関連付けることができます。 この場合、PSAP が受信するロケーションはオフィス ビルの住所となります。 大規模なビルの場合は、このロケーションに、フロアやフロア上の領域などの追加情報が含まれます。 各 ERL には、一意の ELIN が必要です。

これらの一般的な E911 の要件に加え、地域ごとにこれらの要件をさらに広げたり、抑えたりすることができます。 たとえば、都市の規定において、ERL のサイズ(7,000 平方フィートを超えないなど)、ERL に設置できる電話機の台数(48 台を超えないなど)について特定の制限が含まれている場合があります。 サービス プロバイダーおよび地方自治体と連携して、エリアに適切な E911 の要件を決定します。

E911 と Cisco Emergency Responder の用語

次のリストには、このマニュアルに使用される重要な用語の一部が定義されています。

ALI
自動ロケーション情報。 これは ELIN をロケーションに結び付ける情報です。この情報を使用して、緊急コールをその ELIN から正しいローカル PSAP にルーティングされます。この情報は PSAP に表示され、PSAP で緊急の発信者を探すのに役立ちます。 Emergency Responder では、ERL ごとに ALI データを入力し、ALI データベースに含めるために ALI データをサービス プロバイダーに送信します。
ANI
自動番号識別。 ANI は、ELIN の別名です。 このマニュアルでは、ANI の代わりに ELIN を使用します。
CAMA
集中型自動メッセージ アカウンティング。 公衆電話機交換網(PSTN)を迂回して、E911 選択ルータに直接接続されるアナログ電話トランクです。
DID
直通社内通話。 電話ネットワークへのダイヤルインに使用できる、サービス プロバイダーから取得された電話番号です。 DID 番号は、ELIN に使用されます。
ELIN
Emergency Location Identification Number(緊急ロケーション識別番号)。 これは、緊急コールをローカル PSAP にルーティングする電話番号です。PSAP は、この電話番号を使用して緊急の発信者にコールバックできます。 緊急コールが切断された場合、または緊急コールを通常通り終了した後に PSAP が追加情報を必要とする場合、PSAP はこの番号が必要になることがあります。 ALI を参照してください。
緊急コール
911 などの現地の緊急番号に発信されるコール。 Emergency Responder によって、コールがサービス プロバイダーのネットワークにルーティングされ、そこからコールがローカル PSAP にルーティングされます。
緊急発信者
緊急コールを発信する人。 発信者は、個人的な緊急に助けを求めたり、一般的な緊急(火災、盗難、事故など)を報告したりします。
ERL
Emergency Response Location(緊急応答ロケーション)。 これは、緊急コールの発信元エリアです。 ERL は、必ずしも緊急のロケーションであるとは限りません。 緊急の発信者が一般的な緊急を報告した場合、実際の緊急が別のエリアであることがあります。 Emergency Responder では、スイッチ ポートおよび電話機を ERL に割り当てます。ERL 定義に ALI データが含まれています。
ESN
緊急サービス番号。
ESZ

緊急サービス ゾーン。 特定の PSAP によってカバーされるエリアです。 このエリアには通常、複数の警察署と消防署が含まれます。 たとえば、都市とその郊外は 1 つの PSAP によってカバーされる可能があります。

各 ESZ には、識別するために一意の ESN が割り当てられます。

MSAG
マスター住所録。 これは、緊急コールを正しい PSAP に正確にルーティングできる ALI のデータベースです。 Emergency Responder で、ALI 定義をエクスポートし、MSAG の更新を確認するサービス プロバイダーにその定義を送信します。 このサービスをサービス プロバイダーとネゴシエートする必要があります。このサービスは、Emergency Responder を介して直接提供されるサービスではありません。
NENA
National Emergency Number Association。 ALI 定義のデータ形式およびファイル形式、および米国におけるその他の緊急コール要件を推奨する組織です。 Emergency Responder では、ALI データのエクスポート ファイルに NENA 形式を使用します。 ご使用のサービス プロバイダーでデータ形式に制限が追加されている可能性があるため、それぞれのサービス プロバイダーの規定に ALI エントリが準拠していること確認します。
PSAP
Public Safety Answering Point。 PSAP は、緊急コールを受信する組織(たとえば、911 オペレータ)です。PSAP には、緊急コール処理の訓練を受けたスタッフが配置されます。 PSAP は緊急発信者と話をし、適切な公共サービス組織(警察、消防署、救急車など)に緊急事態とそのロケーションを通知します。

Cisco Emergency Responder について

次の各トピックでは、Emergency Responder の概要と、ネットワークで Emergency Responder を使用する方法について説明します。

機能

Emergency Responder の主な新機能および拡張機能を次に示します。

  • WAN を介した Unified CM クラスタリングのサポート
  • 40,000 個の Unified CM エンドポイントのサポート
  • オンサイト アラートにおける発信者表示名
  • 追加のエンドポイント、LAN アクセス スイッチおよび Unified Computing System (UCS) / VMware プラットフォームとの互換性

Emergency Responder でサポートされているハードウェアとソフトウェアの詳細なリストについては、『Release Notes for Cisco Emergency Responder』を参照してください。

ネットワークのハードウェアおよびソフトウェアの要件

Emergency Responder では、さまざまなハードウェアおよびソフトウェア コンポーネントがサポートされています。 サポートされているハードウェアとソフトウェアの完全なリストについては、『Release Notes for Cisco Emergency Responder』を参照してください。このマニュアルは、http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_release_notes_list.html にあります。

Cisco Emergency Responder 8.7 のライセンス

Emergency Responder 8.7 では、初回インストールまたはアップグレードの実行にライセンス キーは不要です。 Emergency Responder 8.0、8.5、または 8.6 からのアップグレードに新しいサーバ ライセンスは不要ですが、新規インストールまたは Emergency Responder リリース 7.1 以前からのアップグレード後 60 日以内に、新しいサーバ ライセンスをインストールする必要があります。 新しい Emergency Responder メジャー バージョンのサーバ ライセンスは、Emergency Responder ソフトウェアを注文することによってのみ入手できます。

ライセンス供与されていない Emergency Responder 8.7 ソフトウェアは、評価モードで、インストール後 60 日間、電話機 100 台のキャパシティで通常どおり使用することができます。 評価モードで 60 日が過ぎると、サーバは動作しなくなります。 追加のユーザ ライセンスは、サーバ ライセンスをインストールしてから有効になります。

Emergency Responder を Emergency Responder リリース 7.1 以前からリリース 8.7 にアップグレードすると、以前のサーバ ライセンスは無効になります。 以前のユーザ ライセンスは引き続き有効ですが、新しいサーバ ライセンスがアップロードされた場合にのみ有効になります。


警告


インストールまたは Emergency Responder 7.1 からのアップグレード後 60 日以内に新しいサーバ ライセンスをインストールしないと、Emergency Responder 8.7 システムはシャットダウンされます。


Emergency Responder でサポートされるすべての Unified CM クラスタで制御されるすべてのエンドポイント(ハード IP Phone、IP Softphone、アナログ電話機など)について、ユーザ ライセンスを購入する必要があります。 Unified CM クラスタ内のエンドポイントの一部のみへのライセンス付与は、サポートされていません。


(注)  


Cisco Emergency Responder ですべての Unified CM エンドポイントに対してはユーザ ライセンスがない場合、アラートおよび警告が表示される場合がありますが、Emergency Responder は正しく機能します。


Emergency Responder 8.7 では、製品ライセンスの配布に Web ベースのシステムを使用します。 Emergency Responder 製品を Cisco.com Web サイトで登録すると、サーバ ライセンスを含むファイルが、電子メールにテキスト ファイル形式で添付されて送信されます。

ライセンス要件

サーバ ライセンスの場合:

  • Emergency Responder グループ内のサーバ(プライマリおよびセカンダリ)ごとにサーバ ライセンスを取得するには、サーバ ソフトウェアを注文します。 サーバ ソフトウェアの 2 つのコピーをまとめて注文すると、2 つのノードを備えたサーバ グループに対して 1 つのサーバ ライセンスを取得できます。 Emergency Responder ソフトウェアの追加のコピーを個別に注文することによって、既存の Emergency Responder グループにセカンダリ サーバを追加できます。
  • パブリッシャ サーバとサブスクライバ サーバ間では、サーバ ライセンスを共有できません。 既存の Emergency Responder グループにセカンダリ サーバを追加するには、Emergency Responder ソフトウェアのコピーを個別に注文する必要があります。

ユーザ ライセンスの場合:

  • Emergency Responder グループごとに 1 つ以上(必要に応じて)のユーザ ライセンスを注文します。
  • 各 Emergency Responder グループ内のパブリッシャ サーバとサブスクライバ サーバ間でユーザ ライセンスを共有できます。
  • Emergency Responder ユーザ ライセンスを Emergency Responder クラスタ内の異なる Emergency Responder グループ間で、または異なる Emergency Responder クラスタ間で共有することはできません(クラスタの詳細については、Emergency Responder のクラスタおよびグループを参照してください)。

Emergency Responder 設定で 500 ユーザをサポートする場合は、次のライセンスを購入する必要があります。

  • Emergency Responder パブリッシャ サーバのサーバ ライセンスを取得するための、Emergency Responder ソフトウェアのコピーを 1 つ。
  • 最大 500 人のユーザのユーザ ライセンス。
  • Emergency Responder ソフトウェアの 2 つのコピーをまとめて注文すると、2 つのノードを備えたサーバ グループに対して 1 つのサーバ ライセンスを取得できます。 Emergency Responder ソフトウェアの追加のコピーを個別に注文することによって、既存の Emergency Responder グループにセカンダリ サーバを追加できます。

サーバ ライセンス

サーバ ソフトウェアを注文して、サーバ グループにある Emergency Responder サーバごとにサーバ ライセンスを取得する必要があります。 1 つのライセンス ファイルに Emergency Responder パブリッシャとサブスクライバの両方のライセンスを含めることができます。または、Emergency Responder サブスクライバの別個のライセンス ファイルを後で Emergency Responder パブリッシャにインストールすることができます。 パブリッシャ サーバのハードウェアまたはラインセンス MAC アドレスを使用して、パブリッシャおよびサブスクライバのライセンスを生成する必要があります。 Emergency Responder サブスクライバの MAC アドレスは使用しないでください。


(注)  


ライセンス ファイルを開いて表示、変更、または保存しないでください。 ライセンスには認証文字列が含まれているため、ファイルを編集または保存すると、この認証文字列が無効になります。 認証文字列が無効な場合、Emergency Responder を機能させるには、新しいライセンス ファイルをインストールする必要があります。


Emergency Responder ソフトウェアを注文して新しいサーバ ライセンスを取得するには、次の手順を実行します。


(注)  


VMware をインストールする場合、HOSTNAME=<License MAC> を使用してライセンス ファイルを生成してください。


手順
    ステップ 1   ご希望の注文方法で Emergency Responder ソフトウェアを注文します。 Emergency Responder ソフトウェアと一緒に製品認証キー(PAK)を受け取ります。
    ステップ 2   https:/​/​tools.cisco.com/​SWIFT/​Licensing/​PrivateRegistrationServlet に進み、PAK とパブリッシャの Emergency Responder サーバのハードウェアまたはライセンス メディア アクセス コントロール(MAC)アドレスを入力して Emergency Responder を登録します。 Emergency Responder サブスクライバのライセンス MAC アドレスは使用しないでください。

    パブリッシャの Emergency Responder サーバの MAC アドレスを取得するには、次の手順を実行します。

    1. Cisco Unified OS Administration の Web サイトにログインします。
    2. [Show] > [Network] の順に進みます。
    3. [Ethernet Details] セクションにハードウェアまたはライセンス MAC アドレスが表示されます。

      処理後、電子メールにテキスト ファイル形式で添付されたサーバ ライセンス ファイルを受信します。

    ステップ 3   サーバ ライセンス ファイルをローカル サーバに保存して、そのファイルを Emergency Responder サーバにアップロードできるようにします。
    ステップ 4   Emergency Responder Administration Web インターフェイスを使用して、サーバ ライセンス ファイルをアップロードします。 サーバ ライセンス ファイルをアップロードする方法の手順については、ライセンス ファイルのアップロードを参照してください。

    ユーザ ライセンス

    ユーザ ライセンスは通常、プライマリ Emergency Responder サーバにインストールされますが、ユーザ ライセンスのインストール先に関係なく、プライマリとセカンダリの両方の Emergency Responder サーバでユーザ ライセンスが共有されます。

    サーバ グループで常に使用できるユーザ ライセンス総数は、サーバ グループの両方のサーバで使用できるユーザ ライセンスの合計です。

    追加の Emergency Responder ユーザ ライセンスを取得するには、次の手順を実行します。

    手順
      ステップ 1   新規または追加のユーザ ライセンスを注文します。 新規または追加のユーザ ライセンスごとに製品認証キー(PAK)を受け取ります。
      ステップ 2   https:/​/​tools.cisco.com/​SWIFT/​Licensing/​PrivateRegistrationServlet に進み、PAK とプライマリ Emergency Responder サーバのハードウェアまたはライセンス メディア アクセス コントロール(MAC)アドレスを入力して Emergency Responder を登録します。 ユーザ ライセンスがプライマリ Emergency Responder サーバにインストールされます。 Emergency Responder サブスクライバの MAC アドレスは使用しないでください。 処理後、電子メールにテキスト ファイル形式で添付されたユーザ ライセンスを受信します。
      (注)     

      VMware をインストールする場合、HOSTNAME=<License MAC> を使用してライセンス ファイルを注文してください。

      ステップ 3   ユーザ ライセンス ファイルをローカル サーバに保存して、そのファイルをプライマリ Emergency Responder サーバにアップロードできるようにします。
      ステップ 4   ユーザ ライセンス ファイルをアップロードします。 ユーザ ライセンスのアップロード方法の手順については、ライセンス ファイルのアップロードを参照してください。
      (注)     

      Emergency Responder ライセンス ファイルは、プライマリ サーバでのみアップロードできます。

      (注)     

      Emergency Responder サーバ ライセンスには、暗黙的なユーザ ライセンスは含まれません。 ユーザ ライセンスは、明示的に購入する必要があります。

      (注)     

      ライセンス ファイルを開いて表示、変更、または保存しないでください。 ライセンスには認証文字列が含まれているため、ファイルを編集または保存すると、この認証文字列が無効になります。 認証文字列が無効な場合、Emergency Responder を機能させるには、新しいライセンス ファイルを取得する必要があります。


      ライセンス ファイルのアップロード

      Emergency Responder Administration Web インターフェイスを使用して、ライセンス ファイルを Emergency Responder サーバにアップロードできます。 パブリッシャ サーバを起動して実行している場合、パブリッシャ サーバからのみすべてのライセンス ファイルをアップロードする必要があります。


      (注)  


      Emergency Responder ライセンス ファイルは、プライマリ Emergency Responder サーバからのみアップロードできます。


      ライセンス ファイルをアップロードするには、次の手順を実行します。

      手順
        ステップ 1   Emergency Responder Administration Web サイトにログインします。
        ステップ 2   [System] > [License Manager] の順に選択します。 [License Manager] ページが表示されます。
        ステップ 3   [Upload license] をクリックします。 [Upload File] ページが表示されます。
        ステップ 4   [Browse...] ボタンを使用して、ローカル システムからアップロードするライセンス ファイルを選択します。
        ステップ 5   [Upload] をクリックします。 選択したライセンス ファイルが Emergency Responder サーバにアップロードされます。

        関連資料

        Emergency Responder とネットワーク

        次の図に、Cisco Emergency Responder(Emergency Responder)をご使用のネットワークに適合させる方法を示します。

        図 1. Cisco Emergency Responder をご使用のネットワークに適合させる方法



        Emergency Responder は、会社のダイヤル プランについて Cisco Unified Communications Manager に依存しています。緊急コールを Emergency Responder グループに送信するには、このダイヤル プランを変更する必要があります。 必要な Cisco Unified Communications Manager の設定の詳細については、Cisco Unified Communications Manager の設定を参照してください。

        電話機を追跡するために、Emergency Responder では、クラスタに登録されている電話機のリストについて Cisco Unified Communications Manager に照会します。 その後、Emergency Responder では、電話機が接続されているポートを判断するためにネットワーク上のスイッチ(Emergency Responder で指定したスイッチ)に照会します。 移動された電話機を識別できるように、Emergency Responder では、日中に定期的にこの追跡を行います。 Emergency Responder のスイッチのセットアップの詳細については、Emergency Responder スイッチの設定を参照してください。 Emergency Responder で、ポートおよび電話の設置場所に基づいて正しい PSAP に緊急コールを送信できるようにするためのスイッチ ポートの設定については、電話機の管理を参照してください。


        (注)  


        Cisco レイヤ 2 プロトコルを使用している Cisco IP Phone の場所を、接続しているスイッチ ポートの検出を使用して特定する場合は、配線プランのマッピングと制御が必要です。 ドキュメントの変更を誤ると、Emergency Responder はネットワーク内の電話機の場所を特定できなくなる可能性があります。 配線を変更する場合は、配線プランを更新し、Emergency Responder 設定を更新する必要があります。


        オプションとして、ご使用のネットワークまたはサービス プロバイダーに SMTP 電子メール サーバを設定することもできます。 電子メールをオンサイトのアラート(セキュリティ)担当者に送信するように Emergency Responder を設定し、それらの担当者に緊急コールを通知することができます。 サーバを電子メールベースのページング サービスとして設定するとそれらの担当者がページングされます。

        最後に、Emergency Responder で緊急コールを現地の Public Safety Answering Point(PSAP)にルーティングできるように、サービス プロバイダーのネットワークへの PRI または CAMA リンクを備えたゲートウェイが必要です。

        上の図 1 は、1 つの Cisco Unified Communications Manager クラスタをサポートしている 1 つの Emergency Responder グループを示しています。 Unified CM で同一バージョンのソフトウェアを実行している限り、1 つの Emergency Responder グループで複数の Cisco Unified Communications Manager クラスタをサポートできます。 大規模なネットワークでは、複数の Emergency Responder グループを設置して Emergency Responder クラスタを作成できます。 この設置の詳細については、Emergency Responder のクラスタおよびグループを参照してください。

        緊急コールが Emergency Responder で管理される場合の緊急コールの処理手順の説明については、緊急コール処理を参照してください。

        緊急コール処理

        ここでは、緊急コールを処理するために Cisco Emergency Responder(Emergency Responder)で使用するプロセスについて説明します。 このプロセスを理解すると、Emergency Responder を正しくセットアップし、発生した問題のトラブルシューティングを実行することができます。

        次の図は、Emergency Responder で緊急コールをルーティングする方法を示しています。

        図 2. Cisco Emergency Responder で緊急コールをルーティングする方法



        誰かが内線 3003 を使用して緊急コールを発信した場合:

        1. Cisco Unified Communications Manager によって、そのコールが Emergency Responder にルーティングされます。
        2. Emergency Responder では、発信者の緊急応答ロケーション(ERL)に設定されているルート パターンを取得します。 コール ルーティングの順序については、コール ルーティングの順序を参照してください。
        3. Emergency Responder によって、発信者番号が発信者の ERL に設定されているルート パターンに変換されます。 このルート パターンは、適切な緊急ロケーション識別番号(ELIN)を Public Safety Answering Point(PSAP)に渡すために設定されます。 ELIN は、緊急の発信者にコールバックするために PSAP で使用できる電話番号です。
        4. デフォルトでは、Emergency Responder によって、発信者の内線と ELIN 間のマッピングが最大 3 時間保存されます。 エントリのタイムアウト前にマッピングが後続のコールで上書きされる場合があります。 タイムアウトの設定を 3 時間よりも長くしたり、短くしたりすることもできます(Group Settingsを参照)。
        5. Emergency Responder では、発信者の ERL に設定されているルート パターンを使用してコールがルーティングされます。 次に、このルート パターンでは、設定されたルート リストを使用して、緊急コールを適切なサービス プロバイダーのネットワークに送信します。 サービス プロバイダーは、自動ロケーション情報(ALI)で ELIN を検索し、コールを適切なローカル PSAP にルーティングします。 PSAP では、電話コールを受信し、ALI データベースで ALI を検索します。
        6. 同時に、Emergency Responder によって、Web アラートが Emergency Responder ユーザに送信されます。 さらに、Emergency Responder では、ERL に割り当てられているオンサイトのアラート(セキュリティ)担当者にコールします。 その担当者の電子メール アドレスを設定している場合、Emergency Responder によって、電子メールも送信されます。 そのアドレスが電子メールベースのページング サービス用である場合には、その担当者に電子メールではなく、ページが送信されます。
        7. 緊急コールが突然切断された場合、PSAP は ELIN を使用して緊急の発信者にコールバックできます。 ELIN のコールは Emergency Responder にルーティングされ、Emergency Responder によって、ELIN が ELIN と関連付けられているキャッシュされた最後の内線に変換されます。 その後、コールがその内線にルーティングされます。

        適切なパフォーマンスを確保し、障害点をなくすには、次の内容を確認します。

        • 緊急コールが正しくルーティングされるようにするためには、発信者の電話機を正しい ERL に割り当てる必要があります。 電話機に関連付けられている ERL が正しいかを確認するには、ERL デバッグ ツールを使用します。
        • コールの正確なルーティングについて他に考えられる問題としては、ELIN 定義があります。 ELIN ルート パターンを誤ったゲートウェイに割り当てた場合、緊急コールが誤ったネットワークにルーティングされる可能性があります。 これにより、緊急コールが間違った PSAP に送信される可能性があります。 サービス プロバイダーと連携して、必要なゲートウェイ数とゲートウェイを接続する場所を決定します。 これらの要件は、ご使用のネットワーク トポロジよりもサービス プロバイダーのネットワーク トポロジに基づきます。 米国では、緊急コール ネットワークは PSTN に直列に接続するため、PSTN に接続しただけでは、緊急コールは正しくルーティングされません。
        • ALI データベースの情報が正しくないと、サービス プロバイダーのネットワークでコールが正しくルーティングされない可能性があります。 ALI データをエクスポートしてそのデータをサービス プロバイダーに送信し、ELIN またはロケーションの情報を変更した場合には必ず ALI データを再送信します。
        • ERL から多数の緊急コールが発信されると、PSAP では、緊急の発信者に正常にコールバックできない可能性があります。 Emergency Responder では、ELIN から内線へのマッピングが最大 3 時間キャッシュされます。 ERL に 2 つの ELIN を定義し、3 時間の間に 3 つの緊急コールが発信された場合、最初の ELIN が 2 回使用されます。つまり、1 回目は最初の発信者に、2 回目は 3 番目の発信者に使用されます。 PSAP で最初の ELIN をコールした場合、PSAP は最初の発信者ではなく、3 番目の発信者に到達します。 この問題が発生する可能性は、ELIN に定義する ELIN の数と ERL における標準的な緊急コール率で決まります。

        コール ルーティングの順序

        Emergency Responder では、緊急コールが発信された電話機のロケーションに基づいて緊急コールを転送します。 電話機のロケーションは、優先順位に従って次の方法によって判断されます。

        • 疑似電話:電話の MAC アドレスは、疑似電話の MAC アドレスと一致し、テスト用の緊急応答ロケーション(ERL)に割り当てられます。 模擬電話機テスト ERL のセットアップ を参照してください。
        • スイッチ ポートの背後で追跡される IP 電話:IP 電話の MAC アドレスは、ERL に割り当てられているスイッチ ポートの背後で追跡されます。 スイッチ ポートの設定を参照してください。
        • IP サブネットを使用して追跡される IP 電話:IP 電話の IP アドレスは、ERL に割り当てられている IP サブネットワークに属します。 IP サブネットベースの ERL のセットアップを参照してください。
        • 同じ Emergency Responder クラスタにある別(リモート)の Emergency Responder サーバ グループによって追跡される IP 電話:リモートのサーバ グループでは、スイッチ ポートの背後で、または IP サブネットで IP 電話を追跡します。 緊急コールを受信すると、リモートの Emergency Responder サーバ グループで構成される Cisco Unified Communications Manager クラスタに緊急コールが転送されます。 クラスタ間の電話機の移動を参照してください。
        • 手動で設定された電話:電話の回線番号は、手動で ERL に割り当てられます。 電話機の手動定義を参照してください。
        • 位置未確認の電話:IP 電話の MAC アドレスは、ERL に割り当てられます。 位置未確認の電話機の特定を参照してください。
        • デフォルト ERL:上記の基準に当てはまらない場合、デフォルト ERL を使用して電話機のロケーションを判断します。 コールは、デフォルト ERL にルーティングされます。 デフォルト ERL のセットアップを参照してください。

        (注)  


        Cisco Unified IP Phone には、MAC または IP アドレスの追跡が推奨されます。 IP 電話が手動の回線番号設定によってロケーションに割り当てられた場合でも、MAC アドレスまたは IP アドレスによって追跡されない IP 電話は位置未確認の電話として表示されます。



        (注)  


        手動設定電話機は、先頭に + が付く回線番号に基づき Emergency Responder によってロケーションに割り当てることができません。 Emergency Responder で回線番号に基づきロケーションをアナログ電話機に割り当てる場合は、Unified CM で先頭に + を付けて回線番号を設定しないでください。


        お客様は、[Unlocated Phones] ページから IP 電話が削除されることがないように、IP 電話が MAC または IP アドレスによって追跡されない問題を解決するようにしてください(Unlocated Phonesを参照)。 [Unlocated Phones] ページで ERL を IP 電話に直接割り当てることはできますが、その電話機に手動の回線番号設定でロケーションが割り当てられていると、この割り当ては有効になりません。 ERL デバッグ ツールを使用して、[Unlocated Phones] ページに表示される IP 電話に有効な ERL 割り当てを決定します。

        位置未確認の電話の識別

        Emergency Responder では、位置未確認の電話機が次のすべての基準を満たす Cisco Unified IP Phone として定義されます。

        • IP 電話が、Emergency Responder グループに認識される Cisco Unified Communications Manager に登録されていること。
        • IP 電話の MAC アドレスがスイッチ ポートの背後で追跡されていないこと。
        • IP 電話の IP アドレスが IP サブネットを使用して追跡されていないこと。
        • IP 電話の MAC アドレスが Emergency Responder で疑似電話として定義されていないこと。

        (注)  


        リモートの Emergency Responder サーバ グループによって追跡される Cisco Unified IP Phone と ERL に手動で回線番号が割り当てられている IP 電話機も [Unlocated Phones] 画面に表示されます。


        位置未確認の電話への ERL の割り当て

        Emergency Responder では、ERL を [Unlocated Phones] 画面に表示される IP 電話に割り当てる手順を提供します。 この割り当てによって、位置未確認の電話の MAC アドレスが管理者によって選択される ERL に関連付けられます。 この関連付けには、次の規則が適用されます。

        • [Unlocated Phones] ページでの ERL の IP 電話への関連付けによって、IP 電話のステータスは変更されません。つまり、IP 電話が上記に説明されているように位置未確認の電話の基準と一致しているため、IP 電話は [Unlocated Phones] ページに表示されたままです。
        • ERL の関連付けが使用されるのは、上記の規則を使用して Emergency Responder で決定されるように IP 電話が検出されない場合だけです。

        たとえば、電話 A は現在検出されず、[Unlocated Phones] ページに表示されます。 位置未確認の電話に ERL 割り当て機能を使用して、この電話の ERL としてロケーション A が割り当てられます。 後続の電話の追跡サイクルによって、スイッチ ポートの背後で電話 A が検出されると、[Unlocated Phones] ページに電話 A が表示されなくなります。 電話 A のロケーション A への割り当ては無効になります。 関連付けは不変であるため、その後も IP 電話の位置が不明である場合でも、その割り当ては有効です。

        CTI アプリケーションのコール転送

        Cisco Unity などのコンピュータテレフォニーインテグレーション(CTI)アプリケーションによって、緊急コールが 911 に転送される場合、コール ルーティングおよび PSAP レポートで使用されるロケーションは、元の発信者のロケーションではなく、アプリケーション サーバのロケーションとなります。 これについては、Unified CM 4.2(3) および 4.3、Unified CM 5.1、6.0、および 6.1 で可能であるように、アプリケーションによって元の発信側回線が保持される場合でも引き続き適用されます。 このため、911 を直接ダイヤルする必要があります。

        Emergency Responder のクラスタおよびグループ

        ご使用のネットワークに Cisco Emergency Responder(Emergency Responder)を一対の冗長サーバとして配置します。 1 つのサーバはパブリッシャ サーバとして指定し、もう 1 つのサーバはサブスクライバ サーバとして指定します。 Emergency Responder のパブリッシャ サーバとサブスクライバ サーバの組み合わせは、それぞれ 1 つの Emergency Responder サーバ グループを構成します。 サーバ グループの設定データは、パブリッシャのデータベースに保存されます。 このデータは、サブスクライバに複製されます。

        Emergency Responder クラスタは、正しい緊急コール処理機能を提供するためにデータを共有する一連の Emergency Responder サーバ グループです。 Emergency Responder クラスタ情報は、クラスタ内のクラスタ データベースと呼ばれる場所に一元的に保存されます。 Emergency Responder サーバ グループは、そのグループがクラスタ内の他のサーバ グループと同じクラスタ データベースを指定している場合、そのクラスタの一部であると見なされます。

        Emergency Responder では、次の 2 つの個別のデータベースを使用します。

        • 1 つのデータベースには、Emergency Responder の設定情報が保存されます。
        • 2 つ目のデータベースには、Emergency Responder のクラスタ情報が保存されます。

        インストール時に、両方のデータベースが各 Emergency Responder サーバに作成されます。 ただし、クラスタ データは、1 つの Emergency Responder サーバにのみ含まれます。


        (注)  


        同一の Emergency Responder グループには、バージョンが異なる Emergency Responder を配置できません。 最新バージョンの Emergency Responder にアップグレードする場合、両方の Emergency Responder サーバを同じバージョンにアップグレードするようにしてください。 Unified CM に登録されている電話機が EnergyWise Power Save Plus モードで設定されている場合は、EnergyWise が以前のバージョンの Emergency Responder でサポートされていないため、クラスタ内のすべての Emergency Responder サーバ グループが Emergency Responder 8.6 以降になっている必要があります。 Emergency Responder 8.6 以降の大規模検出では、EnergyWise Power Save Plus モードの電話機は削除されません。


        次の図は、Cisco Emergency Responder(Emergency Responder)グループを 1 つの Emergency Responder クラスタに結合する方法を示しています。

        図 3. Cisco Emergency Responder グループと Cisco Emergency Responder クラスタ間の関係の概要



        この例では、次のようになります。

        • 2 つの Cisco Unified Communications Manager クラスタ、Unified CM クラスタ A および Unified CM クラスタ B があります。
        • Emergency Responder サーバ グループ 1 と Emergency Responder サーバ グループ 2 で 1 つの Emergency Responder クラスタが形成されています。
        • Emergency Responder サーバ グループ 1 は Unified CM クラスタ  A をサポートし、Emergency Responder サーバ グループ 2 は Unified CM クラスタ B をサポートしています。
        • Cisco ER1 パブリッシャのクラスタ データベースに、両方の Emergency Responder サーバ グループの Emergency Responder クラスタ情報が保存されます。 点線は、Emergency Responder サーバとクラスタ データベース ホストとの通信を示します。
        • 各 Emergency Responder サーバには、Emergency Responder の設定情報が含まれたデータベースがあります。

        (注)  


        Emergency Responder クラスタ内の電話の追跡が正確に動作するように、クラスタ内の Emergency Responder サーバがそのホスト名で検出され、その他すべての Emergency Responder サーバからネットワーク上のクラスタ内の Emergency Responder サーバに到達できるようにする必要があります。



        (注)  


        Emergency Responder サーバ グループの設定を設定するときに、[System Administrator Mail ID] フィールドにシステム管理者の電子メール アカウントを入力した場合、スタンバイ サーバによってコールが処理されるときに、またはスタンバイ サーバがプライマリ サーバを継承するときに、システム管理者は電子メール通知を受信します。 (サーバ グループのセットアップを参照)。


        Emergency Responder クラスタの作成を完了するには、クラスタ内トランクとルート パターンを作成することにより、Emergency Responder グループがグループ間で緊急コールを渡したり(Cisco Emergency Responder グループ間の通信に対するルート パターンの作成を参照)、Emergency Responder でこれらのルート パターンを設定したり(サーバのグループ テレフォニー設定のセットアップを参照)できるようにする必要があります。


        注意    


        Emergency Responder クラスタの作成前に、Emergency Responder クラスタによってサポートされるすべての Cisco Unified Communications Manager クラスタのダイヤル プランを一意にする必要があります。 たとえば、1 つの Cisco Unified Communications Manager クラスタには、内線 2002 のみを設定できます。 ダイヤル プランが重複している場合は、Emergency Responder クラスタを分離しておく必要があります。その場合、これらの Cisco Unified Communications Manager クラスタ間の電話機の動的な移動をサポートできません。



        注意    


        E.164 ダイヤル プランのユーザは、Cisco 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 に移動すると、次回の増分電話機トラッキングで検出され、対応するスイッチ ポートの下に表示されます。

        Emergency Responder システムを計画する際には、次のことに留意してください。

        • 1 つの Emergency Responder グループで、Cisco Unified Communications Manager バージョンが混在しているクラスタをサポートすることはできません。 たとえば、Emergency Responder は、すべての Cisco Unified Call Manager 4.2 クラスタまたはすべての Cisco Unified Call Manager 5.1 をサポートできます。 ただし、Emergency Responder クラスタには、異なるバージョンの Cisco Unified Communications Manager をサポートする Emergency Responder グループを含めることができます。 この方法により、Emergency Responder で、テレフォニー ネットワーク内の Cisco Unified Communications Manager バージョンの混在をサポートできます。
        • Emergency Responder サーバ グループは、バージョン 1.3 以降の Emergency Responder サーバ グループとともに Emergency Responder クラスタを形成できます。

        (注)  


        共用回線を使用して Cisco Unified IP Phone から緊急コールを発信すると、コールがクラスタを介して間違った ERL に終端する可能性があります。



        (注)  


        検出されて ERL に関連付けられている電話機を、同じ Emergency Responder クラスタに属する別の Emergency Responder サーバ グループによって追跡される別の Unified CM クラスタに移動するには、現在の Emergency Responder サーバ グループから ERL の関連付けを削除する必要があります。 現在の Emergency Responder サーバ グループから ERL の割り当てを解除するには、位置未確認の電話機の特定のステップ 7 を参照してください。


        必要な Cisco Emergency Responder グループの決定

        Emergency Responder の効率的なパフォーマンスを実現するには、Emergency Responder の配置を計画する際に各 Emergency Responder グループでサポートできる制限を考慮する必要があります。 1 つの Emergency Responder グループでは、複数の Cisco Unified Communications Manager クラスタをサポートできますが、1 つの Emergency Responder グループでサポートできるのは、1 つの Cisco Unified Communications Manager クラスタだけであることに留意してください。

        設定を含む 1 つの Emergency Responder グループのキャパシティについては、『Release Notes for Cisco Emergency Responder』を参照してください。 別の数値に達していなくても、1 つの制限に関して最大数値を満たすことができることに留意してください。 たとえば、1,000 個のスイッチを定義できますが、スイッチ ポートは 30,000 個未満です。

        追加のグループをインストールすることにより、さらに大規模なネットワークを管理できます。 各 Emergency Responder グループは、1 つ以上の Cisco Unified Communications Manager クラスタと連携できます。

        これらのグループごとの制限に加えて、サービス プロバイダーの ALI データベース プロバイダーの管轄区域も考慮する必要があります。 ネットワークが複数の ALI データベース プロバイダーの管轄区域に拡張されている場合は、ALI フォーマット ツール(AFT)を使用して、ALI レコードを複数の ALI データベース形式でエクスポートする必要があります。

        1 つの Emergency Responder グループで複数の LEC をサポートするには、次の手順を実行します。

        手順
          ステップ 1   Emergency Responder からの ALI レコード ファイル出力を標準の NENA 形式で入手します。 このファイルには、複数の LEC に宛てられたレコードが含まれています。
          ステップ 2   必要な ALI 形式ごとに元のファイルの 1 つのコピーを作成します(LEC ごとに 1 つのコピー)。
          ステップ 3   最初の LEC(たとえば、LEC-A)の AFT を使用して、NENA 形式のファイルのコピーをロードし、他の LEC に関連付けられているすべての ELIN のレコードを削除します。 (AFT の使用方法については、ALI Formatting Toolを参照してください)。削除する情報は、通常、NPA(またはエリア コード)によって識別できます。
          ステップ 4   結果として生成されたファイルを、LEC-A に必要な ALI 形式で保存し、適宜ファイル名を付けます。
          ステップ 5   各 LEC に対してステップ 3 と 4 を繰り返します。

          各 LEC に AFT を使用できない場合、テキスト エディタで NENA 形式のファイルを編集することで、同じ結果をアーカイブできます。


          関連資料

          データの整合性および信頼性

          ローカル PSAP への緊急コールの正しいルーティングは、ERL 設定に基づきます。 ご使用のネットワーク内では、正しい電話機の識別によって、サービス プロバイダーのネットワークへの接続に使用するゲートウェイが決定されます。 サービス プロバイダーのネットワークでは、ルーティングは ELIN に基づきます。ELIN は、発信者の ALI の検索にも使用されます。 そのため、正確な ELIN が緊急コールに割り当てられるように、ERL 設定の信頼性を確保する必要があります。

          ERL 設定の信頼性を維持するために考慮する事項を次に示します。

          • ERL は、ポート自体のロケーションではなく、ポートに接続されているデバイスのロケーションに基づいてスイッチ ポートに割り当てられます。 したがって、ポートに接続されているワイヤを変更すると(たとえば、2 つ以上のポート間でワイヤを切り替えることによって)、ポートに現在接続されているデバイスが実際には別の ERL に配置されている可能性があります。 ポートに割り当てられている ERL を変更しない場合、誤った ELIN がポートに使用され、間違った ALI が PSAP に送信されてしまいます。 1 つの LAN スイッチが別の PSAP によってカバーされる ERL に接続される可能性は低いため、通常、この種の変更によって、コールが誤ってルーティングされることはありません。 ただし、送信された ALI は間違っているため、発信者が実際に 4 階にいる場合の緊急に対してセキュリティ スタッフは 3 階を調べる可能性があります。 この問題を防止するには、ワイヤリング クローゼットが安全に配置されていることを確認し、スイッチ ポート間のワイヤを交換しないようにネットワーキング スタッフに指導します。
          • 電話機が Emergency Responder によって自動的に追跡されない場合、電話機を移動、追加、または変更した結果、Emergency Responder 設定も更新していることを確認します、 このようなタイプの電話機の定義については、電話機の手動定義を参照してください。

            (注)  


            スイッチ ポートのマッピングが変更された場合、電子メール アラートが送信されます。


          • Emergency Responder 1.2 よりも前は、登録された電話機がスイッチ ポートの背後で検出されなかった場合、Emergency Responder によって、[Unlocated Phones] ページに電話機のリストが表示されます。 Emergency Responder 1.2 以降では、これらの電話機は次のように検索されます。
            • 登録された電話がスイッチ ポートの背後で検出されない場合、設定された IP サブネットの 1 つで見つけることができます。
            • 登録された電話がスイッチ ポートの背後で検出されない場合、電話機の IP サブネットが設定されていない場合、あるいは電話機が疑似電話として設定されていない場合、Emergency Responder によって、[Unlocated Phones] ページに電話機のリストが表示されます。 Emergency Responder でコール ルーティングに使用する ERL を決定するには、ERL デバッグ ツールを使用して電話機を検索します。 検索によって、この電話機からの緊急コールのルーティングで使用される現在の ERL と Emergency Responder によってその ERL が選択された理由がわかります。 詳細については、Emergency Responder Admin Utilityを参照してください。
          • Emergency Responder をインストールする際に、パブリッシャ サーバ(プライマリ)とパブリッシャを指定するサブスクライバ サーバ(バックアップ)を設置します。 パブリッシャ サーバおよびサブスクライバ サーバは、それぞれ 1 つの Cisco Emergency Responder サーバ グループを構成します。 この冗長性は、1 つのサーバの障害が緊急コールの発信機能に影響しないようにするのに役立ちます。 別のサブネット上にある、プライマリ サーバと物理的に離れた場所にスタンバイ サーバを設置することを検討してください。 この分離は、プライマリ サーバを設置しているビルの火災、プライマリ サーバのホストとなるサブネットとの接続切断などのような中断から保護することができます。
          • スイッチの(たとえば、モジュールの追加や変更による)追加、削除、または更新時に Emergency Responder の設定が定期的に更新されることを確認します。 スイッチを変更したら、Emergency Responder でスイッチを表示し、[Locate Switch Ports] をクリックして、スイッチ上でスイッチ ポートおよび電話機更新プロセスを実行します。 詳細については、LAN スイッチの指定を参照してください。 未定義のスイッチに接続されている電話機は、Emergency Responder に位置未確認の電話機としてリストに表示されます。 定義されたスイッチを変更した場合、新しいポート、または変更されたポートは、ERL の関連付けのないポートになります。 新しいスイッチ ポート、または追加されたスイッチ ポートに対して ERL を割り当てる必要があります。 ネットワーク変更に関係する反復的な作業については、Emergency Responder ネットワーク管理者のロールおよびEmergency Responder ERL 管理者のロールを参照してください。
          • ERL/ALI 設定を変更する際には、その情報をエクスポートし、ALI データベースに含めるためにサービス プロバイダーにその情報を送信する必要があります。 これにより、緊急コールが正しい PSAP にルーティングされ、PSAP に正しい ALI が提示されるようになります。 詳細については、ERL 情報のエクスポートおよびサービス プロバイダー向け ALI 情報のエクスポートを参照してください。

          ネットワークの準備

          次のトピックでは、Cisco Emergency Responder を配置する前の、ネットワークの準備に必要な手順について説明します。

          CAMA トランクおよび PRI トランク

          緊急コールを処理するには、PRI トランクまたは CAMA トランクを取得してサービス プロバイダーに接続する必要があります。 ご使用のサービス プロバイダーでサポートされているトランクのタイプが 1 つだけである可能性があります。 サービス プロバイダーに問い合わせて、最適に機能する接続のタイプを決定します。

          次の問題について検討してください。

          • PRI:緊急コールに PRI 接続を使用する場合、標準電話トラフィックで接続を共有できます。 標準トラフィックにトランクを使用する場合、トランク使用率を監視して、緊急コールの処理に利用可能な帯域幅が十分にあることを確認します。 キャパシティが不十分である場合、緊急の発信者はコールを発信したときにビジー信号を受け取る可能性があります。 キャパシティ プランニングが緊急コールの要件に基づいていることを確認します。 PRI トランクを設定する際に、汎用番号(サイトのメイン番号など)ではなく、実際の発信者番号が送信されるように設定する必要があります。 そのように設定しないと、PSAP では、予測される ELIN が受信されず、緊急コールが正しい PSAP にルーティングされない可能性があります。
          • CAMA:CAMA トランクは、緊急コール専用であり、ほとんどのエリアで使用できます。 CAMA トランクは、標準音声トラフィックによって使用されることはないため、CAMA トランクにキャパシティを計画する必要はありません。

          サービス プロバイダーと連携して、ご使用のネットワークに必要なトランク数を決定します。 たとえば、一部のサービス プロバイダーでは、10,000 台の電話機に対して 2 つの CAMA トランクを使用するガイドラインを採用しています。

          また、トランク数は、ローカル PSAP に対するオフィスの分配に応じて異なる可能性があります。 たとえば、ニューヨークとシカゴにオフィスがある場合は、電話機の総数に必要なトランク数がニューヨークにだけオフィスがあったとした場合より少なくても、両方の都市にトランクが必要です。 PSAP のアクセシビリティに基づいたトランクの要件について、緊急コール ネットワークのレイアウトを把握するサービス プロバイダーによる指示を受けることができます。

          DID サービス プロバイダー番号

          緊急応答ロケーション(ERL)の緊急ロケーション識別番号(ELIN)として使用するために、サービス プロバイダーからダイヤルイン(DID)番号を入手する必要があります。

          一般に、ERL ごとに少なくとも 1 つの一意な番号が必要です。 緊急コールは ERL の ELIN に基づいてローカル PSAP にルーティングされるため、一意の ELIN がないと、コールが正しくルーティングされません。 また、ALI データベース プロバイダーによって、重複する ELIN が含まれている ALI が受け入れられない可能性があります。

          ERL ごとに複数の ELIN が必要になることがあります。 ERL に複数の電話機がある場合、短時間(3 時間未満)の間に ERL から複数の緊急コールが発信される可能性があります。 ERL に ELIN を 1 つだけ割り当てると、各緊急コールにその ELIN が再利用されます。 したがって、1 時間の間に 4 人が緊急コールを発信した場合、PSAP で ELIN をコールすると、最後の発信者に接続されます。 PSAP でそれよりも前の発信者の 1 人に接続しようとする場合に、これが問題となることがあります。

          ERL ごとに複数の ELIN を定義した場合、Emergency Responder では、すべての ELIN が使用されるまで順にそれらの ELIN を使用します。その後、それらの ELIN を順に再利用します。 Emergency Responder では、ELIN 間のリンクと実際の緊急発信者の内線番号が最大 3 時間まで保持されます。

          サービス プロバイダーからそれらの DID を購入する必要があるため、予算の必要性と正しい発信者に到達するために PSAP の機能を維持する必要性のバランスを取る必要があります。


          (注)  


          取得する DID 数は、Emergency Responder で処理できる緊急コール数とは関係しません。 Emergency Responder では定義した ELIN が再利用されるため、すべての緊急コールが処理され、適切な PSAP にルーティングされます。 ELIN の数が影響するのは、PSAP が目的の緊急の発信者にコールバックする成功率に対してだけです。


          ALI 送信およびサービス プロバイダーの要件

          緊急コールは、緊急の発信者の緊急ロケーション識別番号(ELIN)に基づいて適切な PSAP にルーティングされます。 緊急コールをルーティングするには、テレフォニー ネットワークで、それらの ELIN をロケーションにマップする自動ロケーション情報(ALI)が必要です。 緊急コールの適切なルーティングに加え、ALI データベースによって、PSAP 画面に表示されるロケーション情報も提供され、発信者の特定に役立ちます。

          Emergency Responder には、ALI を作成する機能と、サービス プロバイダーに受け入れ可能な各種形式で ALI をエクスポートする機能が含まれています。 ERL/ALI 設定を作成した後、ALI データをエクスポートし、そのデータを ALI データベース プロバイダーに送信する必要があります。

          データの送信方法は、ロケーション間またはサービス プロバイダー間で異なる場合があります。 サービス プロバイダーと連携して、ALI データの提出に選択できるサービスを決定する必要があります。 最低限でも、予測されるデータ形式と必要な転送方法を把握する必要があります。

          Emergency Responder には、ALI を自動的に送信する機能はありません。


          ヒント


          ご使用のネットワーク全体に Emergency Responder を配置する前に、サービス プロバイダーと一緒に ALI 提出プロセスをテストしてください。 サービス プロバイダーと協力して、PSAP で ALI データを使用してご使用のネットワークに正常にコールバックできることをテストします。 各サービス プロバイダーや ALI データベース プロバイダーの ALI 情報に関する規則は少し異なります。 Emergency Responder では、一般的な NENA 標準に従って ALI データを作成できますが、ご使用のサービス プロバイダーまたはデータベース プロバイダーにはより厳しい規則があります。


          スイッチおよび電話機のアップグレード

          Emergency Responder の最も強力な機能は、ご使用のネットワークで電話機の追加および移動を自動的に追跡できることです。 ユーザが都市間で電話機を移動しても、この動的な機能により、緊急コールがローカル PSAP に確実にルーティングされます。 これによって、移動、追加、または変更が簡素化され、電話ネットワークの維持コストを削減することができます。

          ただし、Emergency Responder で電話機の移動を自動的に追跡できるのは、特定のタイプの電話機、および特定のタイプのスイッチ ポートに接続された電話機の場合だけです。 これらの電話機およびスイッチのリストについては、ネットワークのハードウェアおよびソフトウェアの要件を参照してください。

          完全な自動化を実現するには、ご使用のスイッチをサポートされているモデルまたはソフトウェア バージョンにアップグレードするか、ご使用の電話機をサポートされているモデルと交換してください。

          Emergency Responder 用のスタッフの準備

          Emergency Responder は、既存の緊急手順に置き換わるものではありません。 それよりむしろ、Emergency Responder はそれらの手順の強化に使用できるツールです。 Emergency Responder を配置する前に、Emergency Responder をどのように手順に適合させるか、および Emergency Responder システムの機能をどのように使用するかを検討してください。

          Emergency Responder をどのように使用するかを決定する際に検討する主な内容を次に示します。

          • 誰かが緊急コールを発信すると、Emergency Responder によって、割り当てられたオンサイトのアラート(セキュリティ)担当者(緊急応答チーム)に発信者のロケーションが通知されます。 この情報の大部分は ERL 名です。 緊急応答チームと協力して、緊急応答チームが緊急に対して迅速に応答するのに役立つ ERL 命名方法を策定することを検討してください。 検討する内容の種類は、ビルの名前、階数、およびその名前に含まれている理解しやすいその他のロケーション情報です。
          • Emergency Responder で 3 つのタイプの管理ユーザを定義すると、Emergency Responder システム管理、ネットワーク管理、および ERL 管理全体の責任を分割できます。 1 人でこれらの作業に必要なスキルおよび知識を持っていることはめったにありません。 それらのスキルに従って Emergency Responder 設定の責任を分割することを検討してください。
          • 緊急コールのルーティングと正確な ALI の送信は、まさにサービス プロバイダーに提出する ALI 定義の信頼性とネットワーク トポロジの安定性を意味します。 ERL 管理者が ALI データを最新の状態にしておく重要性を理解し、ネットワーク管理者が安定したネットワークを維持する重要性を理解していることを確認してください。 データの整合性に関する詳細については、データの整合性および信頼性を参照してください。

          Emergency Responder の配置

          次の各項では、さまざまなネットワークのタイプに応じた配置モデルについて説明します。 さらに大規模で複雑なネットワークを形成するために、次の例を組み合わせ、それらの例をモジュールとして使用できます。

          メイン サイトと PSAP での配置

          1 つの Cisco Unified Communications Manager クラスタで構成される簡易テレフォニー ネットワークをサポートするには、2 つの Emergency Responder サーバを設置し、1 つのサーバをパブリッシャとして、もう 1 つのサーバをパブリッシャを指定するサブスクライバとして設定します。

          ローカル PSAP が 1 つだけであるため、テレフォニー ネットワークのキャパシティ プランニングで複数のゲートウェイが必要になる可能性がある場合でも、サービス プロバイダーのネットワークへの必要なゲートウェイは 1 つだけです。 このゲートウェイを使用するために、すべてのルート パターンを設定します。

          次の図に、1 つの Cisco Unified Communications Manager クラスタを含む単純なテレフォニー ネットワークに Emergency Responder を適合させる方法を示します。

          図 4. 1 つの PSAP がある 1 つのメイン サイトでの Cisco Emergency Responder の配置



          これらの例をより複雑なネットワークに拡張するには、次の例を参照してください。

          メイン サイトと 2 つ以上の PSAP での配置

          次の図は、2 つ以上の PSAP でカバーされている 1 つのメイン サイトを含む Emergency Responder の設定を示します。 この例では、1 つの Cisco Unified Communications Manager クラスタがあることを前提とします。 複数のクラスタがある場合、設定は論理的に2 つのメイン サイトの配置で説明されている設定と同じです。

          図 5. 2 つ以上の PSAP がある 1 つのメイン サイトでの Cisco Emergency Responder の配置



          このタイプのネットワークをサポートするには、2 つの Emergency Responder サーバを設置し、1 つのサーバをパブリッシャとして設定して、もう 1 つのサーバを、パブリッシャを指定するサブスクライバとして設定します。

          ロケーションをカバーする PSAP が 2 つあるため、サービス プロバイダーのネットワークの別の部分に接続している複数のゲートウェイが必要になる場合があります。 ただし、これは、サービス プロバイダーのネットワークのレイアウトによって決まります。つまり、PSAP が、緊急コールをインテリジェントに複数の PSAP にルーティングできる選択ルータに接続される場合、必要なゲートウェイが 1 つだけである可能性があります。 サービス プロバイダーと話し合い、ビルの要件を決定します。 この例では、2 つのゲートウェイが必要であることが前提です。 当然ながら、ご使用のテレフォニー ネットワークのキャパシティ プランニングでは、各リンクに複数のゲートウェイが必要な場合があります。

          ゲートウェイを設定してサービス プロバイダーのネットワークに正しく接続した後、ゲートウェイ A を使用するためにビル A の ERL で使用されるすべてのルート パターンを設定し、ゲートウェイ B を使用するためにビル B の ERL で使用されるすべてのルート パターンを設定します。 建物間で電話機を移動すると、Emergency Responder によって、それらの ERL が動的に更新され、緊急コールが目的のゲートウェイからルーティングされるようになります。

          これらの例を他のネットワークに拡張するには、次の例を参照してください。

          サテライト オフィスがあるメイン サイトでの配置

          次の図は、1 つのメイン サイトに 1 つ以上のサテライト オフィスがある場合、つまり、メイン サイト上の Cisco Unified Communications Manager クラスタからサテライト オフィスの電話機を稼働する Emergency Responder 設定を示します。 サテライト オフィスに独自の Cisco Unified Communications Manager クラスタがある場合には、2 つのメイン サイトの配置を参照してください。

          図 6. サテライト オフィスがある 1 つのメイン サイトでの Cisco Emergency Responder の配置




          注意    


          この設定では、オフィス間の WAN リンクが故障した場合、サテライト オフィスにいる人々は Emergency Responder のサポートを使用して緊急コールを発信できません。 WAN が故障した場合には、サテライト オフィスの SRST によって、緊急コールの基本的なサポートが提供されます。


          このタイプのネットワークをサポートするには、2 つの Emergency Responder サーバを設置し、1 つのサーバをパブリッシャとして設定して、もう 1 つのサーバを、パブリッシャを指定するサブスクライバとして設定します。 両方のサーバをメイン オフィスに設置します。

          ほとんどの場合、メイン オフィス(コロンバス)とサテライト オフィス(チリコシー)をカバーする個別の PSAP があります。 したがって、サービス プロバイダーのネットワークの別の部分(サービス プロバイダーが異なることもあります)に接続している複数のゲートウェイが必要になる場合があります。 ただし、これは、サービス プロバイダーのネットワークのレイアウトによって決まります。つまり、PSAP に共有スイッチを使用する場合、必要なゲートウェイが 1 つだけである可能性があります。 サービス プロバイダーと話し合い、ビルの要件を決定します。 この例では、2 つのゲートウェイが必要であることが前提です。 当然ながら、ご使用のテレフォニー ネットワークのキャパシティ プランニングでは、各リンクに複数のゲートウェイが必要な場合があります。

          ゲートウェイを設定してサービス プロバイダーのネットワークに正しく接続した後、ゲートウェイ COL を使用するためにコロンバスの ERL で使用されるすべてのルート パターンを設定し、ゲートウェイ CHIL を使用するためにチリコシーの ERL で使用されるすべてのルート パターンを設定します。 サイト間で電話機を移動すると、Emergency Responder によって、それらの ERL が動的に更新され、緊急コールが目的のゲートウェイからルーティングされるようになります。

          また、SNMP のパフォーマンスを WAN リンクのアカウントに合わせなければならない場合があります。 Emergency Responder では、そこで電話機の移動を追跡するためにリモート サイトのスイッチの SNMP クエリーを実行する必要があります。SNMP クエリーを正常に実行するために十分な時間がない、または再試行できない場合には、SNMP タイムアウトの問題が発生する可能性があります。 詳細については、SNMP 接続のセットアップを参照してください。

          これらの例を他のネットワークに拡張するには、次の例を参照してください。


          ヒント


          サテライト オフィスの規模が小さく(電話機 50 台未満)、Survivable Remote Site Telephony(SRST)を使用している場合、メイン オフィスの Emergency Responder ではなく、ローカル PSAP に対して CAMA トランクが設定されている FXO ポートに 911 コールを送信するようにリモート オフィスにゲートウェイを設定することで、緊急コールの直接サポートが容易になる可能性があります。


          複数のサイトをカバーするメイン サイトでの配置

          次の図に、2 つ以上のメイン サイトに 2 つ以上の PSAP があり、さらにサイトごとに 1 つの Unified CM クラスタがある Emergency Responder の設定を示します。

          図 7. 2 つ以上のサイトをカバーする 1 つのメイン サイトでの Emergency Responder の配置



          このタイプのネットワークをサポートするには、2 つの Emergency Responder サーバを設置し、1 つのサーバをパブリッシャとして設定して、もう 1 つのサーバを、パブリッシャを指定するサブスクライバとして設定します。

          ロケーションをカバーする PSAP が 2 つあるため、サービス プロバイダーのネットワークの別の部分に接続している複数のゲートウェイが必要になる場合があります。 ただし、これは、サービス プロバイダーのネットワークのレイアウトによって決まります。つまり、PSAP が、緊急コールをインテリジェントに複数の PSAP にルーティングできる選択ルータに接続される場合、必要なゲートウェイが 1 つだけである可能性があります。 サービス プロバイダーと話し合い、ビルの要件を決定します。 この例では、サイトごとに 1 つのゲートウェイが必要であることが前提です。 当然ながら、ご使用のテレフォニー ネットワークのキャパシティ プランニングでは、各リンクに複数のゲートウェイが必要な場合があります。

          ゲートウェイを設定してサービス プロバイダーのネットワークに正しく接続した後、ローカル サイトのゲートウェイを使用するために、サイト A の ERL で使用されるすべてのルート パターンとサイト B の ERL で使用されるすべてのルート パターンを設定します。 建物間で電話機を移動すると、Emergency Responder によって、それらの ERL が動的に更新され、緊急コールが目的のゲートウェイからルーティングされるようになります。

          この例では、Emergency Responder が 2 つの Unified CM クラスタに接続され、サイト間の電話機の移動が容易になります。サイト A およびサイト B の Unified CM クラスタで、サイト A の ERL のルート パターンとサイト B の ERL のルート パターンを設定する必要があります。

          EMCC を使用する複数のサイトをカバーする 1 つのサイト

          2 つの Unified CM クラスタ間で Extension Mobility Cross Cluster(EMCC)を使用すると、Emergency Responder で 911 コールの拡張サポートを提供できるようになります。

          図 1 は、1 つのサイトで Emergency Responder がどのように配置され、各サイトにある Unified CM を使用して 2 つ以上の各サイトをどのようにカバーするかを示しています。

          このシナリオでは、Emergency Responder サーバは EMCC ユーザのホーム クラスタと Unified CM の Visiting クラスタの両方で共有されます。 Emergency Responder で処理する場合、911 コールが EMCC にログインしたユーザによって発信されても、Unified CM ホーム クラスタでは、911 コールをユーザの Visiting クラスタに転送するために付属コーリング サーチ スペース(CSS)を使用できません。

          その代わりに、両方のクラスタをサポートしている共有 Emergency Responder サーバによって、ユーザのホーム クラスタにある 911 コールが処理されます。

          これらの例を他のネットワークに拡張するには、次の例を参照してください。

          2 つのメイン サイトの配置

          次の図は、それぞれが個別の PSAP でカバーされている 2 つ(以上)のメイン サイトで構成されている Emergency Responder を示します。

          図 8. 2 つのメイン サイト内の Cisco Emergency Responder の配置



          この例の説明と次の例を組み合わせることで、この例をより複雑な設定に適用させることができます。

          1 つのメイン サイトが複数の PSAP でカバーされている場合のそのサイトでの Emergency Responder の配置については、メイン サイトと 2 つ以上の PSAP での配置を参照してください。 このタイプのネットワークをサポートするには、次のことを行います。

          • シカゴに 2 つの Emergency Responder サーバを設置し、1 つのサーバをパブリッシャとして、もう 1 つのサーバをパブリッシャを指定するサブスクライバとして設定します。 設置後、シカゴの Emergency Responder グループにある Emergency Responder パブリッシャ サーバを、クラスタ データベースとして使用するために選択します。 Emergency Responder クラスタおよびクラスタ DB ホストのセットアップを参照してください。
          • ニューヨークに 2 つの Emergency Responder サーバを設置し、1 つのサーバをパブリッシャとして、もう 1 つのサーバをそのパブリッシャを指定するサブスクライバとして設定します。 設置後、シカゴの Emergency Responder グループにある Emergency Responder パブリッシャ サーバを、クラスタ データベースとして使用するために選択します。 Emergency Responder クラスタおよびクラスタ DB ホストのセットアップを参照してください。

          ほとんどの場合、メイン オフィスをカバーする個別の PSAP があります。 この例では、シカゴとニューヨークで異なる PSAP を使用します。 サービス プロバイダーのネットワークの別の部分(別のサービス プロバイダーを使用している場合があります)に接続するには、シカゴとニューヨークにそれぞれ、少なくとも 1 つのゲートウェイが必要です。 サービス プロバイダーと話し合い、ビルの要件を決定します。 当然ながら、ご使用のテレフォニー ネットワークのキャパシティ プランニングでは、各サイトに複数のゲートウェイが必要な場合があります。

          ゲートウェイを設定してサービス プロバイダーのネットワークに正しく接続した後、シカゴの ERL で使用されるすべてのルート パターンをゲートウェイ CHI を使用するように設定し、ニューヨークの ERL で使用されるすべてのルート パターンをゲートウェイ NYC を使用するように設定します。

          シカゴとニューヨーク間で電話機の移動を可能にするには、クラスタ間トランクを設定して、Cisco Unified Communications Manager クラスタをリンクし、Emergency Responder グループ間のルート パターンを作成して、Emergency Responder で個別の Emergency Responder グループでカバーされる Cisco Unified Communications Manager クラスタ間のコール転送ができるようにする必要もあります。 この状況において Emergency Responder で電話機の移動を処理する方法の詳細については、Cisco Emergency Responder グループ間の通信に対するルート パターンの作成を参照してください。

          サイト間で電話機を移動すると、Emergency Responder によって、それらの ERL が動的に更新され、緊急コールが目的のゲートウェイからルーティングされるようになります。 ただし、WAN リンクが使用不能になった場合、Emergency Responder でサイト間の電話機の移動を追跡できません。

          WAN を介したクラスタリングによる 2 つのメイン サイトへの配置

          次の図は、WAN を介したクラスタリング(CoW)による 2 つのメイン サイトを含む Emergency Responder 構成を示しています。

          図 9. WAN を介したクラスタリングによる 2 つのメイン サイトへの Cisco Emergency Responder の配置

          このタイプのネットワークをサポートするには、各サイトに Emergency Responder サーバを 1 つずつインストールし、一方のサーバをパブリッシャとして、もう一方のサーバをサブスクライバとして設定します。 ER パブリッシャはプライマリ Unified CM CTI Manager とともに配置し、ER サブスクライバはセカンダリ Unified CM CTI Manager とともに配置する必要があります。

          次の制約事項に注意してください。
          • ER パブリッシャと ER サブスクライバ間で(データ レプリケーション用に)少なくとも 1.544 Mbps の帯域幅が利用可能であること
          • Unified CM サーバとどちらか一方の ER サーバ間で RTT が 80 ミリ秒を超えないこと

          WAN を介した CTI および JTAPI のサポート

          「通常の動作での WAN を介した JTAPI」の図に、日常または通常の動作での WAN を介した JTAPI を示します。

          このトポロジでは、プライマリ CTI Manager はサイト 1 の Unified CM サブスクライバ上で動作しています。 サイト 2 の Unified CM サブスクライバからの緊急コールは、WAN を介した CTI を使用し、サイト 1 のプライマリ CTI Manager を経由してサイト 1 の ER パブリッシャに到達します。

          図 10. 通常の動作での WAN を介した JTAPI

          「フェールオーバー動作での WAN を介した JTAPI」の図に、フェールオーバー動作での WAN を介した JTAPI を示します。

          Emergency Responder のフェールオーバー動作では、サイト 1 の Unified CM サブスクライバからの緊急コールは、WAN を介した JTAPI を使用し、サイト 1 の Unified CM サブスクライバで動作しているプライマリ CTI Manager を経由して、サイト 2 の Emergency Responder サブスクライバに到達します。

          図 11. フェールオーバー動作での WAN を介した JTAPI

          Emergency Responder のフェールオーバーでは、ER サブスクライバがプライマリ CTI Manager に登録します。 Emergency Responder のフォールバックでは、Emergency Responder パブリッシャがプライマリ CTI Manager に再登録します。 Emergency Responder のフェールオーバーおよびフォールバックには、4 ~ 5 分かかります。 この時間は、設定されている CTI ポートの数によって異なる場合があります。

          WAN を介した CTI と WAN を介した JTAPI の両方で、最大 80 ミリ秒のラウンドトリップのネットワーク遅延がサポートされます。

          EMCC を使用する 2 つのメイン サイトでのクラスタ配置

          2 つの Unified CM クラスタ間に Extension Mobility Cross Cluster(EMCC)を使用すると、Emergency Responder によって、911 の拡張サポートが提供されます。

          図 1は、2 つ(またはそれ以上)のメイン サイトがあり、各サイトに個別の PSAP がある Emergency Responder の設定を示します。

          このシナリオでは、EMCC に 2 つのクラスタを設定する必要があります。 EMCC にログインしたユーザが 911 コールを発信すると、コールはそのユーザのホーム クラスタにある Emergency Responder グループに転送されます。

          ユーザのホーム クラスタおよび Visiting クラスタにある Emergency Responder グループは、Emergency Responder クラスタを形成します。 ホーム クラスタにある Emergency Responder グループによって、コールが 2 つの Unified CM クラスタ間のクラスタ内トランク(ICT)を経由して Visiting の Emergency Responder グループにリダイレクトされ、Visiting の Emergency Responder によって、コールが適切な PSAP にルーティングされます。


          (注)  


          このシナリオでは、Unified CM に付属 CSS は設定されません。


          これらの例を他のネットワークに拡張するには、次の例を参照してください。

          ワイドエリア ネットワークでのローカル ルート グループの設定

          ワイドエリア ネットワーク(WAN)上で複数のロケーションにまたがって Emergency Responder と Cisco Unified Communications Manager を配置した場合、Emergency Responder と Cisco Unified Communications Manager 間の接続が故障した状況でもユーザが緊急コールを発信できるようにローカル ルート グループ(LRG)を設定することを推奨します。

          Emergency Responder と Cisco Unified Communications Manager の間に通信障害が発生している間、次の Emergency Responder 機能はサポートされません。

          • オンサイト アラート
          • Web アラート
          • 電子メール アラート
          • PSAP コールバック
          • デバイス モビリティ デバイス モビリティをサポートするには、あるロケーションから別のロケーションに電話機を移動する際に 911 コールが新しい LRG ロケーションにルーティングされるように Cisco Unified Communications Manager でデバイス モビリティを設定する必要があります。

          LRG を設定するには、次の手順を実行します。

          手順
            ステップ 1   Cisco Unified Communications Manager Administration で、911 緊急コール ルーティング用に LRG のルート パターンおよびルート ポイントを設定します。
            ステップ 2   Cisco Unified Communications Manager Administration で、LRG のルート パターンを使用して緊急コールのルート ポイントで転送されている接続先のルート ポイントを設定します。
            ステップ 3   Emergency Responder Administration で、LRG のルート パターンをデフォルト ERL として設定します。