Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

Public Safety Answering Point（PSAP）

PSAP は、911 コールに応答して、適切な緊急対応（警察、消防署、または救急チームの派遣など）を手配する機関です。911 コールを発信する電話機の物理的なロケーションは、そのコールに応答する適切な PSAP を決定する基本要素です。一般に、各建物を、1 つのローカル PSAP が担当します。

所定のロケーションを担当する PSAP を確認するには、地域の防火管理者または警察署などの地域の公衆安全情報サービス機関に問い合せてください。また、通常、地域通信事業者のディレクトリにも、所定地域内の 911 コールを処理する機関がリストされています。

標準的な状況

• 1 つの番地に対して、1 つの PSAP だけが指定されます。

• 1 つの番地の 911 コールはすべて、同じ PSAP にルーティングされます。

例外的な状況

• キャンパスの物理的な規模により、一部の建物が別の PSAP の管轄になります。

• 一部の 911 コールをオンネット ロケーション（キャンパスのセキュリティ、建物のセキュリティ）にルーティングする必要があります。

911 ネットワーク サービス プロバイダー

担当 PSAP を確認した後、各 PSAP が接続されている 911 ネットワーク サービス プロバイダーも特定する必要があります。通常、PSAP は公衆網から 911 電話コールを受信すると想定されますが、そうとは限りません。911 コールは、地域の重要な専用ネットワーク上で伝送され、各 PSAP は 1 つ以上のこうした地域ネットワークに接続されます。大部分の場合、既存 Local Exchange Carrier（LEC; 地域通信事業者）が PSAP の 911 ネットワーク サービス プロバイダーです。例外には、軍事施設、大学構内、国立または州立の公園、もしくは公衆安全の責任が地方自治体の管轄外であるロケーション、もしくは公共の地域通信事業者以外のエンティティによってプライベート ネットワークが運営されているロケーションがあります。

所定の PSAP の 911 ネットワーク サービス プロバイダーについて疑問がある場合は、その PSAP に直接連絡して、情報を確認してください。

標準的な状況

• 所定の番地の 911 ネットワーク サービス プロバイダーは、既存地域通信事業者（LEC）です。電話会社 X がサービスを提供するロケーションの場合、対応する PSAP も、電話会社 X からサービスを提供されます。

• すべての 911 コールは、オフネット ロケーションに直接ルーティングされるか、オンネット ロケーションに直接ルーティングされます。

例外的な状況

• MLTS インターフェイスから公衆網へ接続するために使用する地域通信事業者（LEC）と、PSAP に対して 911 ネットワーク サービス プロバイダーの役目をする LEC が異なる場合があります（たとえば、電話システムは電話会社 X からサービスを受け、PSAP は電話会社 Y に接続されている場合です）。この状況では、LEC 間の特別な調整、または電話システムと PSAP の 911 ネットワーク サービス プロバイダー間に特別な専用トランクが必要な場合があります。

• 一部の LEC は、ネットワーク上で 911 コールを受け入れることができません。この場合、LEC を変更するか、911 コールを適切な PSAP にルーティングできる LEC に接続されたトランク（911 コール ルーティング専用）を確立するかの 2 つのオプションしかありません。

• 一部（またはすべて）の 911 コールをオンネット ロケーション（キャンパスのセキュリティや建物のセキュリティ）にルーティングする必要があります。この状況は、設計および実装の段階で簡単に対応できますが、電話機ごとの 911 コールの宛先が、正しく計画され、文書化されている必要があります。

適切な 911 ネットワークへのインターフェイス ポイント

大規模なテレフォニー システムでは、911 接続に多数のインターフェイス ポイントが必要になる場合があります。一般に、複数の E911 選択ルータが LEC の管轄地区内で使用され、これらのルータは、通常、相互接続されません。

たとえば、大規模なキャンパスを備えた企業に、次の状況があるとします。

• 建物 A は San Francisco にある。

• 建物 B は San Jose にある。

• San Francisco 警察と San Jose 警察が、該当する PSAP である。

• San Francisco 警察と San Jose 警察は、同じ 911 ネットワーク サービス プロバイダーのサービスを利用している。

• しかし、San Francisco 警察と San Jose 警察は、同じ 911 ネットワーク サービス プロバイダーが運営する異なる E911 選択ルータのサービスを受けている。

このタイプの状況では、2 つの別々のインターフェイス ポイント（E911 選択ルータごとに 1 つずつ）が必要です。E911 選択ルータの管轄地区に関する情報は、一般に、担当 LEC が保持しており、その LEC の地域アカウント担当者が、企業カスタマーに関連情報を提供できます。多くの LEC は、911 問題の専門家のサービスも用意しています。この専門家は、911 アクセス サービスの適切なマッピングについてアカウント担当者と協議できます。

標準的な状況

• 単一サイト配置またはキャンパス配置では、通常、911 コール用に 1 つだけの PSAP があります。

• 1 つの PSAP のみへのアクセスが必要な場合は、1 つのインターフェイス ポイントだけが必要です。複数の PSAP へのアクセスが必要な場合でも、同じ集中インターフェイスを介して、同じ E911 選択ルータから到達可能です。企業の支店サイトが WAN を介してリンクされている場合（集中型コール処理）、Survivable Remote Site Telephony（SRST）操作がアクティブであるときに WAN 障害が発生した場合の 911 分離を防止するため、911 へのローカル（つまり、各支店内の）アクセスを各ロケーションに指定することをお勧めします。

例外的な状況

• キャンパスの物理的な規模により、一部の建物が別の PSAP 管轄になり、かつ

• 一部の 911 コールは、異なるインターフェイス ポイントを通じて、異なる E911 選択ルータにルーティングされる必要があります。

（注） PSAP と E911 選択ルータの地理的な管轄地区の設定に必要な情報は、オンライン、または各種の競合地域通信事業者（CLEC）の Web サイトから部分的に情報を入手できます。たとえば、https://clec.sbc.com/clec/hb/shell.cfm?section=782 では、SBC/Pacific Bell がカバーする管轄地区についての貴重なデータが提供されています。しかし、911 コール ルーティングを設計および実装する前に、該当するインターフェイス ポイントの適切な情報を LEC から入手しておくことを強くお勧めします。

インターフェイス タイプ

音声通信の提供に加えて、ネットワークへの 911 コールの発信に使用されるインターフェイスは、発信者についての識別データも提供する必要があります。

自動番号識別（ANI）は、ネットワークが適切な宛先へ 911 コールをルーティングするために使用する、発信者の E.164 番号を参照します。この番号は、PSAP がコールの ALI（Automatic Location Identification; 自動ロケーション識別）を検索するためにも使用されます。

911 コールは、ソースルートされます。つまり、911 コールは発信番号に応じてルーティングされます。別々のロケーションからすべて同じ番号（911）をダイヤルする場合でも、ANI によって表される起点ロケーションに基づいて、別々の PSAP に到達します。

次のインターフェイス タイプのどちらかを使用して、911 コール機能を実装できます。

• 動的 ANI 割り当て

• 静的 ANI 割り当て

動的 ANI 割り当ては、（複数の ANI をサポートするので）スケーラビリティに優れていますが、小規模のシステム配置には適していません。静的 ANI 割り込みは、最小のシステムから最大のシステムまで、より広範囲にわたる環境で使用できます。

動的 ANI（トランク接続）

動的 ANI では、システムの 1 つのインターフェイスを、911 ネットワークにアクセスする多数の電話機が共用します。また、ネットワークに送信される ANI がコールごとに異なっていることが必要な場合があります。

動的 ANI インターフェイスには、次の 2 つの主なタイプがあります。

• ISDN-PRI（Integrated Services Digital Network-Primary Rate Interface）または単に PRI

• CAMA（Centralized Automatic Message Accounting）

PRI

このタイプのインターフェイスは、通常、テレフォニー システムを公衆網 Class 5 スイッチに接続します。発番号（CPN）は、発信者の E.164 番号を識別するためにコールのセットアップ時に使用されます。

911 にコールする場合、LEC によって CPN を扱う方法が異なります。Class 5 スイッチ機能の制限、または LEC もしくは地方自治体の方針によっては、CPN が 911 コール ルーティング用の ANI として使用されない場合があります。この場合、CPN の代わりに LDN（Listed Directory Number）、または請求先番号（BTN）を ANI の目的で使用するように、ネットワークをプログラムすることができます。

CPN が ANI に使用されない場合、PRI インターフェイスから発信する 911 コールはすべて、911 ネットワークには同じように見えます。これらの 911 コールはすべて、同じ ANI をもち、同じ宛先（適切な宛先でない場合があります）にルーティングされるからです。

一部の LEC は、911 コールの CPN が PRI インターフェイスを通過するようにする機能を備えています。この機能を使用すると、コールのセットアップ時に Class 5 スイッチに提示された CPN は、コールをルーティングするために ANI として使用されます。この機能の名称は、LEC によって異なります（たとえば、SBC はカリフォルニアでこの機能を Inform 911 と呼びます）。

（注） CPN は、ルーティング可能な E.164 番号でなければなりません。つまり、CPN は、関連した E911 選択ルータのルーティング データベースに入力されている必要があります。

（注） ダイヤルイン方式（DID）の電話機の場合、DID 番号は、911 の目的で ANI として使用できますが、これは、911 サービス プロバイダーのネットワーク内で、緊急サービス番号に適切に関連付けられている場合だけです。DID 以外の電話機の場合は、別の番号を使用してください（詳細については、「緊急ロケーション識別番号のマッピング」を参照してください）。

多くの Class 5 スイッチは、複数のエリア コードをサポートしないトランクを通じて、E911 選択ルータに接続されています。このような場合、PRI が 911 コールの伝送に使用される場合、適切にルーティングされる 911 コールだけが、Class 5 スイッチと同じ Numbering Plan Area（NPA）のある CPN（または ANI）を持ちます。

例

MLTS は、エリア コード 514（NPA = 514）の Class 5 スイッチに接続されるとします。MLTS が PRI トランク上で 911 コールを送信し、CPN が 450 .555.1212 である場合、Class 5 スイッチは、（正しい 450 .555.1212 ではなく）ANI 514 .555.1212 として E911 選択ルータにそのコールを送信するので、不適切なルーティングが実行され、ALI を取り出すための検索が発生します。

PRI を 911 インターフェイスとして適切に使用するには、システム計画者は、CPN が ANI に使用されることを確認し、リンク上で受け入れ可能な番号の範囲（NPA NXX TNTN の形式）を適切に識別する必要があります。たとえば、PRI リンクが、範囲 514 XXX XXXX 内の ANI 番号を受け入れるように指定されている場合、NPA = 514 の発番号を持つコールだけが適切にルーティングされます。

CAMA

CAMA（Centralized Automatic Message Accounting）トランクも、MLTS がコールを 911 ネットワークに送信することを可能にします。ただし、PRI 方式とは次の相違点があります。

• CAMA トランクは、E911 選択ルータに直接接続されます。E911 選択ルータと MLTS ゲートウェイ ポイント間の距離をカバーするために、マイレージ追加料金が適用される場合があります。

• CAMA トランクは、911 コールのみをサポートします。CAMA トランクの設置と操作に関連した資産コストと運営コストは、911 トラフィックのサポートのみに使用されます。

• MLTS 業界の CAMA トランクは、固定エリア コードに制限され、このエリア コードは、一般に、リンク プロトコルで黙示されます（つまり、明示的に送信されません）。接続には、すべてのコールが同じ固定エリア コードを共用するので、7 桁または 8 桁のみが ANI として送信されます。

（注） シスコは、VIC-2CAMA、VIC-2FXO、および VIC-4FXO トランク カードを介した CAMA ベースの 911 機能をサポートしています。

静的 ANI（回線接続）

静的 ANI は、公衆網との回線（トランクではなく）接続をサポートし、発信側の電話機の CPN に関係なく、回線の ANI が、その回線で発信されるすべての 911 コールに関連付けられます。一般電話サービス（POTS）が、この目的に使用されます。

POTS 回線は、最も単純かつ、最も広くサポートされている公衆網インターフェイスの 1 つです。POTS 回線は、通常、911 コールを受け入れるように設定されています。さらに、既存の E911 インフラストラクチャは、POTS 回線からの 911 コールを非常によくサポートします。

POTS には、次のような特徴があります。

• POTS 回線に関連した運用コストを低減できます。

• POTS 回線に、電源障害に備えたバックアップ回線の役割をもたせることができます。

• POTS 回線番号を、ALI データベースに入力されるコールバック番号として使用できます。

• POTS 回線は、公衆網へのローカル PRI、または CAMA アクセスに見合うユーザ密度をもたないロケーションに対して、最低コストで最適な 911 サポートを実現します。

• 公衆網の敷設に伴い、POTS 回線は広く普及しています。

このタイプのインターフェイスを介した発信 911 コールはすべて、E911 ネットワークによって同じものとして扱われます。ANI は POTS 回線番号に過ぎないので、E911 ネットワークに提示される ANI を Cisco Unified CallManager が制御できるようにするツール（たとえば、発信者番号変換マスク）は、無意味です。

緊急応答ロケーションのマッピング

National Emergency Number Association（NENA）は、最近、企業テレフォニー システムで 911 を規定する規則を制定する際に、州および国の機関が使用する法律モデルを提案しました。NENA 提案の概念の 1 つは、次のように定義される緊急応答ロケーション（ERL）です。

911 緊急応答チームの派遣先ロケーション：このロケーションは、緊急応答チームがそのロケーション内で発信者の位置をすばやく確認するための妥当な機会を提供できる、明確なものでなければならない。

この要件は、各電話機のロケーションを個々に識別するのではなく、電話機を「ゾーン」（ERL）にグループ化することを見込んでいます。ERL の最大サイズは、この法律の地域ごとの実施に応じて異なる可能性がありますが、ここでは説明の基準として 7000 平方フィートを使用します（ここで説明する概念は、任意の州または地域で許可される最大 ERL サイズとは無関係です）。

緊急ロケーション識別番号（ELIN）が各 ERL に関連付けられます。ELIN は、E911 ネットワーク内でコールのルーティングに使用される完全修飾 E.164 番号です。関連した ERL から発信するすべての 911 コールで、ELIN が E911 ネットワークに送信されます。このプロセスは、911 の目的で、複数の電話機を同じ完全修飾 E.164 番号に関連付けることを可能にし、DID 電話機と非 DID 電話機にも同様に適用できます。

（注） このマニュアルは、法律の実際の要件を提示しようとするものではありません。ここで提示する情報や例は、説明のためだけのものです。システム計画者の責任において、適用されるローカル要件を確認してください。

たとえば、ある建物の床面積が 70,000 平方フィートであり、100 台の電話機があるとします。911 機能を計画する際に、この建物を 7000 平方フィートごとの 10 個のゾーン（ERL）に分割し、各電話機を、それが置かれている ERL に関連付けることができます。911 コールが発信されると、関連した ELIN を PSAP に送信することによって、ERL（複数の電話機に対して同一）が識別されます。この例のように、電話機が均等に分散されている場合、10 台の電話機を持つ各グループには、同じ ERL があり、したがって同じ ELIN をもちます。

各種法律により、最小台数の電話機（たとえば 49）と最低床面積（たとえば、40,000 平方フィート）が定義されます。この数を下回ると、MLTS 911 の要件は適用されません。しかし、法律が企業の 911 機能を要求しない場合であっても、911 機能をプロビジョニングすることが常に最善の方法です。

緊急ロケーション識別番号のマッピング

一般に、緊急ロケーション識別番号（ELIN）と呼ばれる 1 つの完全修飾 E.164 番号を、各 ERL に関連付ける必要があります（ただし、Cisco Emergency Responder を使用する場合は、ERL ごとに複数の ELIN を設定できます）。ELIN は、E911 インフラストラクチャ全体でコールをルーティングするために使用され、ALI データベースへのインデックスとして PSAP が使用します。

ELIN は次の要件を満たす必要があります。

• ELIN は、E911 インフラストラクチャ全体でルーティング可能でなければなりません（「インターフェイス タイプ」の項の例を参照してください）。ELIN がルーティング不能である場合、関連した ERL からの 911 コールは、E911 選択ルータでプログラムされたデフォルト ルーティングに応じて処理されます。

• 企業の ERL-to-ELIN マッピングが定義された後、LEC を使用して、対応する ALI レコードを設定する必要があります。その結果、PSAP にサービスを提供する ANI と ALI データベース レコードを正確に更新することができます。

ELIN マッピング プロセスは、所定の ERL に対する E911 インフラストラクチャとのインターフェイスのタイプに応じて、次のどちらかを選択できます。

• 動的 ANI インターフェイス

このタイプのインターフェイスを使用すると、ネットワークに渡される発番号識別は MLTS によって制御されます。MLTS のテレフォニー ルーティング テーブルは、発信側電話機の ERL に基づいて、正しい ELIN をコールに関連付けます。Cisco Unified CallManager では、変換マスクを使用して、911 へのコールの発番号を変更できます。たとえば、所定の ERL 内にあるすべての電話機が、トランスレーション パターン（911）を含み、かつ電話機の CPN をそのロケーションの ELIN に置き換える発信者番号変換マスクも含むパーティションをリストする同じコーリング サーチ スペースを共有できます。

• 静的 ANI インターフェイス

このタイプのインターフェイスを使用すると、ネットワークに渡される発番号識別は公衆網によって制御されます。これは、インターフェイスが POTS 回線である場合に該当します。ELIN は POTS 回線の電話番号であり、電話機の発信者識別番号に追加操作はできません。

PSAP コールバック

PSAP は、最初の会話の完了後、発信者に到達できることが必要な場合があります。PSAP がコールバックできるかどうかは、PSAP が最初の着信コールと共に受信する情報によって決まります。

この情報は、次の 2 つの部分から成るプロセスによって、PSAP に送信されます。

1. まず、自動番号識別（ANI）が PSAP に送信されます。ANI は、コールをルーティングするために使用される E.164 番号です。この説明では、PSAP で受信された ANI は、MLTS が送信した ELIN を指しています。

2. PSAP は ANI を使用して、データベースを照会し、自動ロケーション識別（ALI）を抽出します。ALI は、次のような情報を PSAP 係員に知らせます。

–発信者の名前

–住所

–該当する公衆安全機関

–コールバック情報を組み込むことができる、その他のオプション情報。たとえば、救援活動の調整に役立てるために、企業のセキュリティ サービスの電話番号がリストされています。

標準的な状況

• ANI 情報が PSAP コールバックに使用されます。ここでは、ELIN がダイヤル可能番号であると想定します。

• ELIN は、MLTS に関連した公衆網番号です。公衆網から ELIN にコールすると、そのコールは、MLTS によって制御されるインターフェイス上で終端します。

• システム内の任意の ELIN に発信されたコールが、関連した ERL のすぐ近くにある電話機（または複数の電話機）を鳴らすように、コール ルーティングをプログラムするのは、MLTS システム管理者の責任です。

• ERL-to-ELIN マッピングが設定された後、修正が必要なのは、企業の物理的な状況に変更があった場合だけです。電話機が単に追加、移動、またはシステムから削除された場合、ERL-to-ELIN マッピングと、それに関連した ANI/ALI データベース レコードは変更する必要はありません。

例外的な状況

• 発信 ERL のすぐ近くへのコールバックを、オンサイト緊急デスクへのコールバックのルーティングと組み合せる（もしくは、置き換える）ことができます。これは、PSAP が最初の発信者を呼び出し、緊急事態に対してただちに支援を要請するときに役立ちます。

• たとえば、エリア コードの分割、公衆安全業務の新しい配分を必要とする地方自治体業務の変更、新しい建物の追加、または 911 の目的でコールの望ましいルーティングに影響を与えるその他の変更により、企業の状況が変わる場合があります。こうした状況では、企業の ERL-to-ELIN マッピングおよび ANI/ALI データベース レコードの変更が必要です。

非固定電話機の考慮事項

この章のここまでの説明はすべて、電話機のロケーションが静的（固定）であることを前提としていました。しかし、電話機が ERL 境界を越えて移動する場合、新しい場所に移動した電話機からの 911 コールは、正しくルーティングされません。別の ERL に物理的に配置されるので、電話機は現在の ERL の ELIN を使用する必要があります。Cisco Unified CallManager データベースで設定が変更されない場合、次のイベントが発生します。

• 旧 ERL の ELIN が、E911 インフラストラクチャ上のコールのルーティングに使用されます。

• IP ネットワークから E911 インフラストラクチャへの出口点が正しくない可能性があります。

• PSAP に提供されるコールバック機能により、誤った宛先に到達する可能性があります。

• ALI 情報が PSAP に提供されると、緊急応答担当者を誤ったロケーションに派遣する可能性があります。

• 電話機に対するロケーション ベースのコール アドミッション制御は、電話機の WAN 帯域幅使用量を正しく把握できず、WAN 帯域幅リソースのオーバーサブスクリプションやアンダーサブスクリプションが発生する可能性があります。

この状況を修復する方法は、Cisco Unified CallManager における電話機の設定（コーリング サーチ スペースやロケーション情報など）を手動で更新して、新しい物理ロケーションを反映することだけです。

Cisco Emergency Responder

移動、追加、および変更の管理が容易であることが、IP テレフォニー テクノロジーの主な利点の 1 つです。ユーザが介入することなく自動的に 911 情報を更新する移動、追加、および変更をサポートするために、シスコは、Cisco Emergency Responder（Cisco ER）と呼ばれる製品を開発しました。

Cisco ER は、次の主な機能を備えています。

• 検出された電話機の物理ロケーションに基づいて、電話機を ERL に動的に関連付けます。

• コールバックのために、ELIN を発信側電話機に動的に関連付けます。上記の項で説明されている ER 以外のシナリオと異なり、Cisco ER は、911 コールを発信した電話機にコールバックできるようにします。

• 緊急コールが進行中であることを知らせるために、指定された通話者へのオンサイト通知が可能です（ポケットベル、Web ページ、または電話による）。ポケットベルと Web ページによる通知には、発信者の名前と電話番号、ERL、およびそのコールに関連した日付と時刻の詳細が含まれます。電話による通知では、緊急コールの発信番号に関する情報が提供されます。

Cisco ER の詳細は、「Cisco Emergency Responder の考慮事項」の項、および次の Web サイトで入手可能な Cisco ER 製品資料を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/respond/index.htm

Cisco ER の主な機能は、電話機が 911 コールを発信したネットワーク ポート（ファースト イーサネット スイッチ ポートなどのレイヤ 2 ポート）の検出による、電話機のロケーションの検出に依存します。この検出メカニズムは、主に次の 2 つの前提事項に依存します。

• 企業のワイヤード インフラストラクチャが十分に確立され、散発的な変更が行われないこと。

• Cisco ER が、このインフラストラクチャをブラウズできること。つまり、Cisco ER は、敷設されたネットワーク インフラストラクチャとの簡易ネットワーク管理プロトコル（SNMP）セッションを確立することができ、接続された電話機を検出するためにネットワーク ポートをスキャンできること。

Cisco ER はコールの発信ポートを検出した後、そのコールを、そのポートのロケーション用にあらかじめ設定された ERL に関連付けます。このプロセスは、ロケーションにあらかじめ設定された ELIN との関連付け、および発信 ERL に基づく、E911 インフラストラクチャとの適切な出口点の選択も行います。

Cisco ER では、上記の項で説明されている ERL-to-ELIN マッピング プロセスが適用されますが、相違点が 1 つあります。それは、Cisco ER を使用しない場合、各 ERL は 1 つの ELIN だけに関連付けられますが、Cisco ER を使用すると、ERL ごとに複数の ELIN を使用できることです。この機能拡張の目的は、次の例に示されているように、同じ期間内に 1 つの ERL から複数の 911 コールが発信される特定のケースに対応するためです。

例 1

• 電話機 A と電話機 B はどちらも、ERL X 内に置かれ、ERL X は ELIN X に関連付けられています。

• 電話機 A は 13:00 に 911 にコールします。ELIN X は、そのコールを PSAP X にルーティングするために使用され、PSAP X はそのコールに応答し、解除します。その後、13:15 に電話機 B が 911 にコールします。再び ELIN X が、コールを PSAP X にルーティングするために使用されます。

• PSAP X は、電話機 B からコールを解除した後、電話機 A の最初のコールに関連した詳細情報を取得するために、電話機 A にコールバックすることを決定します。PSAP は ELIN X にダイヤルしますが、（目的の電話機 A ではなく）電話機 B につながります。

この状況を回避するために、Cisco ER では、ERL ごとに ELIN のプールを定義できます。このプールにより、後続のコールごとに別個の ELIN をラウンドロビン方式で使用できます。この例で ERL X に対して 2 つの ELIN を定義すると、例 2 で説明する状況になります。

例 2

• 電話機 A と電話機 B はどちらも、ERL X 内に置かれ、ERL X は ELIN X1 と ELIN X2 の両方に関連付けられます。

• 電話機 A は 13:00 に 911 にコールします。ELIN X1 は、そのコールを PSAP X にルーティングするために使用され、PSAP X はそのコールに応答し、解除します。その後、13:15 に電話機 B が 911 にコールし、このコールを PSAP X にルーティングするのに ELIN X2 が使用されます。

• PSAP X は、電話機 B からコールを解除した後、電話機 A の最初のコールに関連した詳細情報を取得するために、電話機 A にコールバックすることを決定します。PSAP は ELIN X1 にダイヤルし、電話機 A につながります。

もちろん、3 番目の 911 コールが発信されたが ERL に 2 つの ELIN しかない場合、コールバック機能では、最後の 2 人の発信者にしか正しく到達できません。

緊急コール ストリング

アクセス コード（たとえば、9）を使用するかどうかにかかわらず、システムが緊急コールを認識しやすいように、ダイヤル プランを設定することが望まれます。北米の緊急ストリングは、通常、911 です。ストリング 911 と 9911 の両方を認識するように、システムを設定することを強くお勧めします。

緊急ルート パターンに Urgent Priority のマークを明示的に付けて、Cisco Unified CallManager が、コールのルーティング前に、桁間タイムアウト（Timer T.302）を待機しないようにすることも強くお勧めします。

これ以外の緊急コール ストリングを、システム上で並行してサポートすることができます。選択した緊急コール ストリング使用を想定した訓練をテレフォニー システム ユーザに行うことをお勧めします。

また、ユーザが誤って緊急ストリングをダイヤルした場合に適切な対応ができるように訓練することも望まれます。北米では、アクセス コード 9 を使用して長距離番号にアクセスしようとするユーザが、誤って 911 をダイヤルする可能性があります。このような場合、ユーザは、緊急事態ではないので、緊急隊員を派遣する必要がないことを確認するために、回線を保持する必要があります。Cisco ER のオンサイト通知機能では、誤って発信されたコールを含め、911 に発信されたすべてのコールの詳細なアカウントを提供することによって、そのような疑わしい 911 コールの起点にある電話機を識別できます。

ゲートウェイの配置

地域通信事業者（LEC）ネットワーク内で、911 コールは、コールの起点に基づいて、ローカル側で有効なインフラストラクチャ上でルーティングされます。サービスを提供する Class 5 スイッチは、ロケーションに関連した PSAP に直接接続されるか、E911 選択ルータに接続されます。この選択ルータ自体は、その地域に有効な PSAP 群に接続されます。

シスコの IP ベースの企業テレフォニー アーキテクチャでは、リモート側に置かれているゲートウェイに、オンネットでコールをルーティングすることが可能です。たとえば、San Francisco に置かれている電話機は、IP ネットワークを介して、San Jose にあるゲートウェイにコールを伝送してから、LEC のネットワークに送信することができます。

911 コールの場合、緊急コールが適切なローカル PSAP にルーティングされるように、LEC ネットワークへの出口点を選択することが重要です。上記の例では、San Francisco の電話機からの 911 コールが、San Jose のゲートウェイにルーティングされてしまうと、San Francisco の PSAP に到達できません。これは、そのコールを受信する San Jose の LEC スイッチには、San Francisco PSAP にサービスを提供する E911 選択ルータへのリンクがないからです。さらに、San Jose 地域の 911 インフラストラクチャは、San Francisco の発番号に基づいてコールをルーティングすることができません。

大まかに言えば、発信側電話機と物理的に同じ場所にあるゲートウェイに、911 コールをルーティングしてください。共通ゲートウェイを使用して、複数のロケーションからの 911 コールを集約できるかどうかは、LEC に問い合せてください。所定の地域の 911 ネットワークが、911 コールに中央ゲートウェイを使用しやすい場合でも、911 コール ルーティングが WAN 障害中の影響を受けないように、発信側電話機と同じ場所にあるゲートウェイを使用することが望ましいことに注意してください。

ゲートウェイのブロック

911 コールが「全トランク使用中」状況にならないようにすることが望まれます。911 コールを接続する必要がある場合、トランキング リソースの不足により他のタイプのコールがブロックされる場合でも、911 コールは処理可能にしておく必要があります。このような状況に備えて、明示トランク グループを 911 コール専用にすることができます。

緊急コールを独占的に緊急トランク グループにルーティングするのが、好ましい方法です。もう 1 つの方法は、通常の公衆網コールと同じトランク グループに緊急コールを送信し（インターフェイスが許可する場合）、専用緊急トランク グループへの代替パスを用意するものです。後者の方法では、最大限の柔軟性が得られます。

たとえば、緊急コールを PRI トランク グループに向け、オーバーフロー状態になったときに備えて POTS 回線への代替パス（緊急コール専用に予約済み）を指定することができます。代替トランク グループに 2 つの POTS 回線を入れる場合、メインのトランク グループで許可されたすべてのコールの他に、少なくとも 2 つの 911 コールを同時にルーティングできることを保証します。

優先ゲートウェイが使用不能になる場合、緊急コールを代替番号にオーバーフローさせて、代替ゲートウェイが使用されるようにすることができます。たとえば、北米で 911 にダイヤルされたコールは、E.164（911 以外）ローカル緊急番号にオーバーフローすることができます。この方法は、北米の 911 ネットワーク インフラストラクチャを利用しません（つまり、選択ルーティング、ANI、または ALI サービスを使用しません）。この方法は、該当する公衆安全機関によって受け入れられる場合に限り、ネットワーク リソースの不足による緊急コールのブロックを回避する最後の手段としてのみ使用してください。

応答監視

通常の状態では、緊急番号に発信されたコールは、PSAP との接続後、応答監視を戻します。応答監視は、他のコールと同じように、オンネット発信者と、LEC ネットワークへの出口インターフェイスとの間の全二重音声接続をトリガできます。

一部の北米 LEC では、「無料」コールを行う場合、応答監視は戻されません。これは、一部のフリーダイヤル番号（たとえば、800 番）にも該当します。例外的な状況では、緊急コールは「無料」コールと見なされるので、PSAP との接続後、応答監視は戻されません。この状況は、911 テスト コールを発信するだけで検出できます。PSAP との接続後、音声が存在する場合、コール タイマーが発信コールの所要時間を記録します。コール タイマーがない場合は、応答監視が戻されなかった可能性があります。応答監視が戻されない場合、LEC に連絡して、この状況を報告することをお勧めします。おそらく、望ましい機能ではありません。

この状況が地域通信事業者によって修正できない場合、LEC ネットワークにコールが発信されるときに応答監視を必要としないように出口ゲートウェイを設定することをお勧めします。また、応答監視が戻されない場合でも、進行標識音、代行受信メッセージ、および PSAP との通信が可能であるように、両方向で音声をカットスルーすることもお勧めします。

デフォルトでは、Cisco IOS ベースの H.323 ゲートウェイは、両方向で音声を接続するために、応答監視を受信する必要があります。これらのゲートウェイ上で応答監視の必要をなくすには、次のコマンドを使用してください。

• progress_ind alert enable 8

このコマンドは、アラートの受信時に経過識別子 8（インバンド情報が使用可能）を受信することに相当します。このコマンドを使用すると、ゲートウェイの POTS 側が、コールの起点方向の音声を接続できます。

• voice rtp send-recv

このコマンドは、宛先スイッチから Connect メッセージを受信する前に、逆方向と順方向の両方の音声カットスルーを可能にします。このコマンドは、すべての Voice over IP（VoIP）コール（使用可能である場合）に影響を与えます。

応答監視が提供されない場合は、Call Detail Record（CDR; コール詳細レコード）が 911 コールの接続時間または期間を正確に反映しません。その結果、コール レポーティング システムが、911 コール関連の統計情報を正しく表すことができない場合があります。

いかなる場合でも、すべてのコール パスからの 911 コール機能をテストし、PSAP との接続後、応答監視が戻されることを確認することをお勧めします。

Cisco Unified CallManager と Emergency Responder とのバージョンの互換性

Cisco Unified CallManager 5.0 との互換性を維持するには、Emergency Responder 1.3(1) が必要です。Emergency Responder と Cisco Unified CallManager のソフトウェア バージョン間の互換性の詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 1.3(1) 』を参照してください。

http://www.cisco.com

コール アドミッション制御ロケーションを超えたデバイス モビリティ

集中型コール処理配置では、Cisco ER は、複数のコール アドミッション制御ロケーションにわたるデバイスの移動を完全にサポートすることはできません。これは、Cisco Unified CallManager が、デバイスの移動を認識しないからです。たとえば、電話機を支店 A から支店 B に物理的に移動したにもかかわらず、電話機のコール アドミッション制御ロケーションが同じままである（たとえば、Location_A）場合、Location_A に使用可能な帯域幅がすべて、他のコールで使用中であれば、その電話機から 911 に発信するコールは、コール アドミッション制御拒否によりブロックされる可能性があります。現在、ロケーション B にある電話機が、ロケーション B の PSAP との接続に使用されるゲートウェイと物理的に同じ場所にある場合でも、このコール ブロックは発生します。

同じ理由で、Cisco ER は、ゲートキーパーによって制御されるコール アドミッション制御ゾーン間のデバイス移動をサポートできません。ただし、Cisco ER は、コール アドミッション制御ロケーション内でのデバイスの移動を完全にサポートできます。

集中型コール処理配置では、Cisco ER は、支店内のデバイス移動を自動的にサポートします。ただし、デバイスが支店間を移動する場合、Cisco ER が 911 コールを完全にサポートできるようにするには、デバイスのロケーションとリージョンのパラメータを手動で調整する必要があります。

デフォルトの緊急応答ロケーション

Cisco ER が、電話機の物理的なロケーションを直接判別できない場合、コールにデフォルトの緊急応答ロケーション（ERL）を割り当てます。デフォルトの ERL は、こうしたすべてのコールを、特定の PSAP に導きます。この状態が発生した場合、コールの送信先について共通の推奨事項はありませんが、通常、中央に置かれ、最大の公衆安全管轄権を提示する PSAP を選択するのが望ましい方法です。また、デフォルト ERL の緊急ロケーション識別番号（ELIN）の ALI レコードに、企業の緊急番号の連絡先情報を取り込み、発信者のロケーションの不確実さについての情報を提供することも、お勧めします。さらに、緊急コールのデフォルト ルーティングが発生したという注記を、ALI レコードに付けることもお勧めします。

ソフト クライアント

Cisco IP Communicator などのソフト クライアントが企業内で使用される場合、Cisco ER は、デバイス モビリティをサポートできます。しかし、企業の境界外でソフト クライアントが使用される場合（たとえば、ホーム オフィスやホテルからの VPN アクセス）、Cisco ER は、発信者のロケーションを判別できません。さらに、Cisco のシステムで、発信者のロケーションに該当する PSAP にコールを送信できるように、適切な位置にゲートウェイが配置されている可能性はほとんどありません。

ソフト クライアントに 911 コールの使用を許可するか、許可しないかは、企業ポリシーの問題です。インターネット上でローミングする可能性があるソフト クライアントに対して、企業のポリシーとして 911 コールを許可しないことをお勧めします。それにもかかわらず、このようなユーザが 911 をコールした場合、ベスト エフォート型のシステム応答では、オンサイト保安部隊、またはシステムのメイン サイトに近い大規模 PSAP のどちらかに、コールをルーティングします。

次のパラグラフは、ソフト クライアント ユーザに対して緊急コール機能が保証されていないことを警告するために、ユーザに発行される通知の例を示しています。

緊急コールは、設定されているサイト（たとえば、オフィス）に設置されている電話機から発信してください。地域保安当局は、設定されたサイトから移動された電話機からの緊急コールに応答しない可能性があります。設定済みのサイトから離れているときに、この電話機を緊急コールに使用する必要がある場合は、公共安全応答機関に、ロケーションについての特定情報を伝えてください。旅行または在宅勤務時の緊急コールには、サイトに対してローカル側で設定されている電話機（たとえば、ホテルの電話機や自宅の電話機）を使用してください。

テスト コール

企業テレフォニー システムの場合、911 コール機能のテストは、初期インストール後だけでなく、予防手段として定期的に実施することをお勧めします。

テストの実行には、次の項目を参考にしてください。

• PSAP に連絡して、テスト前に許可を要請し、テストを実施する人物の連絡先情報を伝えます。

• 各コール発信時に、実際の緊急事態ではなく、単なるテストであることを伝えます。

• 通話者の画面上に表示される ANI と ALI を確認します。

• コールがルーティングされた先の PSAP を確認します。

• IP Phone 上のコール所要時間タイマーを調べることによって、応答監視が受信されたことを確認します。アクティブ コール タイマーは、応答監視が正しく機能していることを示します。

共用ディレクトリ番号への PSAP コールバック

Cisco ER は、緊急ロケーション識別番号（ELIN）に対する着信コールのルーティングを処理します。911 コールの発信元の回線が、共用ディレクトリ番号である場合、PSAP コールバックにより、すべての共用ディレクトリ番号アピアランスが鳴ります。その後、共用アピアランスのいずれかがコールに応答します。これは、911 コールが発信された電話機ではない可能性があります。

マルチクラスタの考慮事項

複数の Cisco Unified CallManager クラスタに基づく企業テレフォニー システムは、Cisco Emergency Responder（Cisco ER）の機能から利点を得ることができます。

ここで使用する用語の詳細、および次の説明を理解するために必要な背景情報については、『 Cisco Emergency Responder Administration Guide 』を参照してください。「Planning for Cisco Emergency Responder」の章は特に重要です。このマニュアルは、次の Web サイトで入手できます。

http://www.cisco.com

単一の Cisco ER グループ

単一の Emergency Responder グループを配置して、複数の Cisco Unified CallManager クラスタからの緊急コールを処理できます。この設計の目的は、どの電話機の緊急コールも、その Cisco ER グループにルーティングされることを保証することです。その Cisco ER グループが、ELIN を割り当て、電話機のロケーションに基づいてコールを適切なゲートウェイにルーティングします。

単一の Cisco ER グループを使用する 1 つの利点は、すべての ERL と ELIN が単一のシステムに設定されることです。単一の Cisco ER グループがシステムのすべてのアクセス スイッチのポーリングを担当しているため、どのクラスタに登録されている電話機でも、そのグループによって位置が確認されます。図11-1 では、2 つの Cisco Unified CallManager クラスタとインターフェイスする単一の Cisco ER グループを示しています。

図11-1 2 つの Cisco Unified CallManager クラスタに接続されている単一の Cisco ER グループ

図11-1 の単一の Cisco ER グループは、次のコンポーネントとインターフェイスします。

• SNMP を介して各 Cisco Unified CallManager クラスタとインターフェイスし、それぞれに設定されている電話機に関する情報を収集する。

• SNMP を介して企業のすべてのスイッチとインターフェイスし、どのスイッチに接続されているどのクラスタの電話機でも、その位置を確認できるようにする。電話機のロケーションが IP サブネットに基づいて識別される場合、この接続は不要です。IP サブネットベースの ERL を設定する方法の詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 』の「Configuring Cisco Emergency Responder」の章を参照してください。

http://www.cisco.com

• JTAPI を介して各 Cisco Unified CallManager クラスタとインターフェイスし、911 をダイヤルするどの電話機にも必要なコール処理を可能にする。そのコール処理とは、発信側電話機の ERL の識別、ELIN の割り当て、（発信側電話機のロケーションに基づく）適切なゲートウェイへのコール リダイレクション、PSAP コールバック機能の処理などです。

Cisco Emergency Responder によって使用される JTAPI インターフェイスのバージョンは、Cisco Emergency Responder が接続される Cisco Unified CallManager ソフトウェアのバージョンによって決まります。システムの初期化時に、Cisco ER は Cisco Unified CallManager クラスタに問い合せ、適切な JTAPI Telephony Service Provider（TSP）をロードします。Cisco ER サーバ上には 1 つのバージョンの JTAPI TSP しか存在できないため、単一の Cisco ER グループがインターフェイスするすべての Cisco Unified CallManager クラスタが、同じバージョンの Cisco Unified CallManager ソフトウェアを実行する必要があります。

配置によっては、このソフトウェア バージョン要件によって問題が生じる場合があります。たとえば、Cisco Unified CallManager のアップグレード中は、クラスタが異なると、実行されているソフトウェアのバージョンが異なり、一部のクラスタが、Cisco ER サーバ上で実行されているバージョンと互換性のないバージョンの JTAPI を実行していることがあります。このような場合、Cisco ER グループの JTAPI バージョンとは異なるバージョンを実行しているクラスタからの緊急コールは、緊急番号の CTI ルート ポイントの Call Forward Busy 設定によって提供されるコール処理を受けることができます。

複数の Cisco Unified CallManager クラスタに対して単一の Cisco ER グループが適切であるかどうかを検討する場合は、次のガイドラインを適用してください。

• 緊急コールの数ができるだけ少ない許容可能なメンテナンス時間帯に（たとえば、営業時間後や、システムの使用量が最小限のとき）、Cisco Unified CallManager をアップグレードする。

• クラスタの数とサイズから判断して、ソフトウェアのアップグレード中に異なるバージョンの JTAPI が使用される時間を最小限に抑えることができると思われる場合にだけ、単一の Cisco ER グループを使用する。

たとえば、8 台のサーバで構成される 1 つの大規模なクラスタと、2 台のサーバで構成される 1 つの小規模なクラスタを同時に配置し、単一の Cisco ER グループと共に使用するとします。この場合、大規模なクラスタを最初にアップグレードすることをお勧めします。これにより、アップグレードのメンテナンス時間帯に Cisco ER サービスを使用できないユーザ（小規模なクラスタからサービスを受けるユーザ）の数を最小限に抑えることができます。さらに、小規模なクラスタのユーザは、Cisco ER に到達できない間、実際には、緊急コールの一時スタティック ルーティングによって適切にサービスを受けることができます。これは、そのユーザが、その時間中に発信されるすべての非 ER コールに割り当てられている単一の ERL/ELIN によって識別されることが可能なためです。

（注） Cisco Unified CallManager クラスタのいずれかが Cisco Unified CallManager Release 4.2 または 5.0 を実行する場合は、Emergency Responder バージョン 1.3(1) が必要です。

複数の Cisco ER グループ

マルチクラスタ システムをサポートするために、複数の Cisco ER グループを配置することもできます。この場合は、各 ER グループが次のコンポーネントとインターフェイスします。

• Cisco Unified CallManager クラスタ。次の方式を使用します。

–SNMP：クラスタに設定されている電話機に関する情報を収集します。

–JTAPI：適切なゲートウェイへの、またはローミング電話機の場合は適切な Cisco Unified CallManager クラスタへの、コール リダイレクションに関連するコール処理を可能にします。

• その Cisco ER グループの Cisco Unified CallManager に関連付けられているほとんどの電話機の接続先となるアクセス スイッチ（SNMP を使用）。

この方法を使用すると、Cisco Unified CallManager クラスタが、異なるバージョンのソフトウェアを実行できます。これは、各クラスタが、別の Cisco ER グループとインターフェイスするためです。

電話機がネットワーク上のさまざまな場所をローミングし、Cisco ER がその電話機をトラッキングできるようにするには、Cisco ER グループを 1 つの Cisco ER クラスタに設定する必要があります。Cisco ER のクラスタとグループの詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 』の「Planning for Cisco Emergency Responder」の章を参照してください。

http://www.cisco.com

図11-2 では、Cisco ER クラスタリングの背後にある基本的な概念を表すトポロジの例を示しています。

図11-2 複数の Cisco ER グループ

図11-2 では、次のトポロジを示しています。

• Cisco ER グループ A は、Cisco Unified CallManager クラスタ A とインターフェイスして、スイッチ A1 および A2 にアクセスする。このグループは、Cisco Unified CallManager クラスタ A に登録されているすべての電話機のホーム Cisco ER グループであると見なされます。

• 同様に、Cisco ER グループ B は、Cisco Unified CallManager クラスタ B とインターフェイスして、スイッチ B1 および B2 にアクセスする。このグループは、Cisco Unified CallManager クラスタ B に登録されているすべての電話機のホーム Cisco ER グループであると見なされます。

（注） Emergency Responder 1.3(1) を使用する場合は、ER クラスタのすべての ER グループが同じバージョンのソフトウェアを実行する必要があります。したがって、Cisco Unified CallManager クラスタのいずれかが Cisco Unified CallManager Release 4.2 または 5.0 を使用する場合は、すべての ER グループが Emergency Responder 1.3(1) を使用する必要があります。

Cisco ER グループのトラッキング ドメイン内の電話機移動

電話機が、同じホーム Cisco ER グループによって制御されるアクセス スイッチ間を移動する場合、その電話機の緊急コール処理は、単一の Cisco Unified CallManager クラスタを使用する配置で行われる処理と同じです。たとえば、アクセス スイッチ A1 と A2 の間を移動する電話機は、Cisco Unified CallManager クラスタ A に登録されたままで、移動前も移動後もその電話機のロケーションは Cisco ER グループ A によって特定されます。Cisco Unified CallManager クラスタ A による電話機検出と、スイッチ A2 による電話機のロケーション特定の両方で、電話機は引き続き Cisco ER グループ A の完全な制御下にあります。したがって、電話機は位置未確認の電話機と見なされません。

Cisco ER クラスタのさまざまなトラッキング ドメイン間の電話機移動

Cisco ER クラスタは、基本的に、Lightweight Directory Access Protocol（LDAP）データベースを介してロケーション情報を共有する Cisco ER グループの集まりです。各グループは、アクセス スイッチ上または IP サブネット内で検出するすべての電話機のロケーションを共有します。ただし、Cisco ER グループ独自の Cisco Unified CallManager クラスタ内で検出される電話機は 不明 であると見なされ、その情報は共有されません。

Cisco ER グループは、Cisco ER グループのトラッキング ドメイン内（スイッチまたは IP サブネット内）で位置を確認できないが、そのグループに関連付けられている Cisco Unified CallManager クラスタに登録されていることがわかっている電話機に関する情報も共有します。このような電話機は、 位置未確認 と見なされます。

異なる Cisco ER グループによって監視されるアクセス スイッチ間を電話機がローミングする場合、それらのグループは、電話機のロケーションに関する情報を交換できるように、1 つの Cisco ER クラスタに設定される必要があります。たとえば、Cisco Unified CallManager クラスタ A に登録されている電話機 A3 が、Cisco ER グループ B によって制御されるアクセス スイッチに接続されているとします。Cisco ER グループ A は、電話機 A3 が Cisco Unified CallManager クラスタ A に登録されていることを認識しますが、サイト A のどのスイッチでも電話機 A3 の位置を確認できません。したがって、電話機 A3 は Cisco ER グループ A によって 位置未確認 と見なされます。

これに反して、Cisco ER グループ B は、監視対象のスイッチの 1 つで、電話機 A3 の存在を検出します。電話機 A3 は、Cisco Unified CallManager クラスタ B に登録されていないため、 不明 な電話機として Cisco ER LDAP データベースを介してアドバタイズされます。

2 つの Cisco ER グループは、LDAP データベースを介して通信しているため、Cisco ER グループ B の 不明 な電話機 A3 が Cisco ER グループ A の 位置未確認 の電話機 A3 と同じであることがわかります。

Cisco ER グループ A の Unlocated Phone ページには、この電話機のホスト名が、リモート Cisco ER グループ（この場合は Cisco ER グループ B）と共に表示されます。

Cisco ER クラスタ内の緊急コール ルーティング

Cisco ER クラスタリングは、1 つの Cisco Unified CallManager クラスタと 1 つの Cisco ER で構成されるペア間で緊急コールをリダイレクトできるようにするルート パターンにも依存します。詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 』の「Creating Route Patterns for Inter-Cisco Emergency Responder-Group Communications」の項を参照してください。

http://www.cisco.com

電話機 A3 が緊急コールを発信した場合、コール シグナリング フローは次のようになります。

1. 電話機 A3 が、処理のために緊急コール ストリングを Cisco Unified CallManager クラスタ A に送信する。

2. Cisco Unified CallManager クラスタ A が、リダイレクションのためにコールを Cisco ER グループ A に送信する。

3. Cisco ER グループ A が、電話機 A3 の位置を Cisco ER グループ B のトラッキング ドメイン内であると確認し、Cisco Unified CallManager クラスタ B を指すルート パターンにコールをリダイレクトする。

4. Cisco Unified CallManager クラスタ A がコールを Cisco Unified CallManager クラスタ B に送信する。

5. Cisco Unified CallManager クラスタ B が、リダイレクションのためにコールを Cisco ER グループ B に送信する。

6. Cisco ER グループ B が、電話機 A3 のロケーションに関連付けられている ERL と ELIN を識別し、コールを Cisco Unified CallManager クラスタ B にリダイレクトする。発信番号は、電話機 A3 の ERL に関連付けられている ELIN に変換されます。着信番号は、コールを適切なゲートウェイにルーティングするように変更されます。

7. Cisco Unified CallManager クラスタ B が、Cisco ER グループ B から入手した新しい着信番号情報に従ってコールをルーティングする。

8. Cisco Unified CallManager クラスタ B が、ゲートウェイを通じてコールを緊急公衆網ネットワークに送信する。

Cisco ER クラスタリングのスケーラビリティの考慮事項

Cisco ER クラスタでは、ホーム Cisco ER グループのトラッキング ドメイン外をローミングする電話機の数が、スケーラビリティ ファクタとなります。このような電話機の数は、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 1.2(3) 』の「Network Hardware and Software Requirements」の項に記載されている制限内に収める必要があります。

http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_maintenance_guides_list.html

Cisco MCS 7845 サーバ プラットフォームおよび Cisco ER ソフトウェアのバージョン 1.2(3) では、Cisco ER クラスタは最大 3000 台のローミング電話機をサポートできます。この制限を超える必要のある配置（たとえば、複数の Cisco Unified CallManager クラスタを含む大規模なキャンパス配置）では、IP サブネットによって電話機の移動をトラッキングできます。各 Cisco ER グループに IP サブネットを定義し、Cisco ER グループごとに各 ERL を 1 つの ELIN に割り当てることによって、事実上、ローミング電話機をなくすことができます。これは、キャンパス内のすべての電話機が、それぞれの Cisco ER グループのトラッキング ドメインに含まれるためです。

ALI フォーマット

マルチクラスタ構成では、単一の Cisco ER グループに定義されている ERL と ELIN の物理ロケーションが、複数の電話会社の管轄地区にまたがることがあります。これにより、複数の LEC 用のレコードを含む共通ファイルから、さまざまな電話会社用のレコードを抽出する必要が生じることがあります。

Cisco ER は、この情報を、National Emergency Number Association（NENA）2.0、2.1、および 3.0 フォーマットに準拠する ALI レコードとしてエクスポートします。ただし、数多くのサービス プロバイダーが NENA 規格を使用しません。そのような場合は、Cisco ER によって生成された ALI レコードが、サービス プロバイダーによって指定されたフォーマットに準拠するように、ALI Formatting Tool（AFT）を使用してそのレコードを変更できます。これにより、サービス プロバイダーは、フォーマットし直されたファイルを使用して、ALI データベースを更新できます。

ALI Formatting Tool（AFT）では、次の機能を実行できます。

• レコードを選択し、ALI フィールドの値を更新する。AFT では、ALI フィールドを編集し、さまざまなサービス プロバイダーの要件を満たすようにカスタマイズできます。これにより、サービス プロバイダーは、フォーマットし直された ALI ファイルを読み取り、そのファイルを使用して ELIN レコードを更新できます。

• 複数の ALI レコードに対するバルク更新を実行する。バルク更新機能を使用すると、選択したすべてのレコード、1 つのエリア コード、または 1 つのエリア コードと 1 つのシティ コードに対して共通の変更を適用できます。

• エリア コード、シティ コード、または 4 桁のディレクトリ番号に基づいて ALI レコードを選択してエクスポートする。たとえば、あるエリア コードのすべての ALI レコードを選択してエクスポートすることにより、各サービス プロバイダーのすべての ELIN レコードに素早くアクセスできるため、複数のサービス プロバイダーを簡単にサポートできます。

AFT の柔軟性を利用して、単一の Cisco ER グループが、複数の ALI データベース フォーマットで ALI レコードをエクスポートできます。Cisco ER グループがサービスを提供する Cisco Unified CallManager クラスタが 2 つの LEC の管轄地区内にあるサイトを持つ場合、基本的な方法は次のとおりです。

1. Cisco Emergency Responder からの ALI レコード ファイル出力を標準の NENA フォーマットで入手します。このファイルには、複数の LEC 用のレコードが含まれています。

2. 必要な ALI フォーマットごとに元のファイルの 1 つのコピーを作成します（LEC ごとに 1 つのコピー）。

3. 最初の LEC（たとえば、LEC-A）の AFT を使用して、NENA フォーマットのファイルのコピーをロードし、他の LEC に関連付けられているすべての ELIN のレコードを削除します。削除する情報は、通常、NPA（またはエリア コード）によって識別できます。

4. 結果として生成されたファイルを、LEC-A に必要な ALI フォーマットで保存し、適宜ファイル名を付けます。

5. LEC ごとにステップ 3 ～ 4 を繰り返します。

ALI Formatting Tool は、次の Web サイトで入手できます。

http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_maintenance_guides_list.html

この URL にリストされていない LEC の場合、スプレッドシート プログラムや標準のテキスト エディタなど、標準のテキスト ファイル編集ツールを使用して Cisco Unified CallManager からの出力をフォーマットできます。