Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3

PSAP（Public Safety Answering Point）

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

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

標準的な状況

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

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

例外的な状況

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

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

AnyCo の例

AnyCo は、本部（AlphaVille）、および 3 つの事業所（AlphaGulch、BetaTown、および CharlieVale）のそれぞれに、IP テレフォニーを配置するものとします。

ロケーションに対応する PSAP は次のとおりです。

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

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

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

標準的な状況

• 所定の番地の 911 ネットワーク サービス プロバイダーは、ローカル RBOC（もっと一般的に言えば、地域の電話会社）です。電話会社 X がサービスを提供するロケーションの場合、対応する PSAP も、電話会社 X からサービスを提供されます。

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

例外的な状況

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

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

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

AnyCo の例

AnyCo の場合、ロケーションには独自の常駐保安部隊がありません。したがって、911 コールはすべて、該当する PSAP に発信する必要があります。ロケーションごとに、次の地域電話会社が、PSAP の 911 サービス プロバイダーです。

該当する 911 ネットワークへのインターフェイス ポイント

所定の LEC との接続には、複数のインターフェイス ポイントが必要になる場合があります。一般に、複数の E911 選択ルータが LEC の管轄地区内で使用され、これらのルータは、通常、相互接続されません。

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

• 建物 A は San Francisco にある

• 建物 B は San Jose にある

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

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

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

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

標準的な状況

• 集中型企業（つまり、互いに地理的に近い場所にロケーションがある）の場合、通常、911 コール用に 1 つだけ（またはごくまれに、2 つまたは 3 つ）の PSAP があります。

• 1 つの PSAP のみへのアクセスが必要な場合は、1 つのインターフェイス ポイントだけが必要です。複数の PSAP へのアクセスが必要な場合でも、同じ集中インターフェイスを介して、同じ E911 選択ルータから到達可能です。911 コールの処理に必要なインターフェイス数を減らすことになるので、この状況は望ましいものです。SRST（Survivable Remote Site Telephony）操作時に 911 分離を防止するために、911 へのローカル（つまり、各事業所内の）アクセスを各ロケーションに指定することも、望ましいことに注意してください。SRST 操作が実行されるのは、リモート側の電話機と集中型コール処理ロケーションとの間の IP 接続が失われた場合です。

例外的な状況

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

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

（注） PSAP と E911 選択ルータの地理的な管轄地区の設定に必要な情報は、オンライン、または各種の競合地域電話会社（CLEC）の Web サイトから部分的に情報を入手できます。しかし、911 コール ルーティングを設計および実装する前に、該当するインターフェイス ポイントの書面による適切な情報を LEC から入手しておくことを強くお勧めします。

インターフェイス タイプ

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

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

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

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

• 動的 ANI 割り当て

• 静的 ANI 割り当て

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

動的 ANI（トランク接続）

動的 ANI では、MLTS の 1 つのインターフェイスを、911 ネットワークへアクセスする多数の回線が共用します。また、個々の電話機の ANI は、各コールと共にネットワークに送信される必要があります。

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

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

• CAMA（Centralized Automatic Message Accounting）

PRI

このタイプのインターフェイスは、通常、MLTS を PSTN Class 5 スイッチに接続します。発番号（CPN）は、発信者の E.164 番号を識別するためにコールのセットアップ時に使用されます。たとえば、発信者 ID 対応の電話機にコールする場合、コールのセットアップ時に MLTS が提供する発番号は、電話ネットワークによって転送され、受信側に表示されます。

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 コールを PRI インターフェイスに対して適切に通過させる機能を備えています。この機能を使用すると、コールのセットアップ時に Class 5 スイッチに提示された CPN は、コールをルーティングするために ANI として使用されます。この機能の名称は、LEC によって異なります（たとえば、Pacific Bell はこの機能を 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 内の番号を受け入れるように指定されている場合、NPA = 514 の発番号を持つコールだけが適切にルーティングされます。

CAMA

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

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

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

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

（注） 現在、Cisco MLTS は、サードパーティ ベンダーのソリューションを使用した CAMA ベースの 911 機能をサポートしています。シスコは、独自のネイティブ CAMA 音声インタフェース カード（VIC）をまもなく発売する予定です。

静的 ANI（回線接続）

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

POTS 回線は、最も単純かつ、最も広くサポートされている PSTN インターフェイスの 1 つです。POTS 回線には、通常、E911 タンデムに接続された Class 5 スイッチ、独自の E.164 電話番号、ESN 割り当て、および ALI データベース項目が用意されています。

既存の E911 インフラストラクチャは、POTS 回線からの 911 コールを非常によくサポートします。911 コールのサポートは、E911 の設計の基になるテクノロジーです。E911 のワイヤレスおよび企業テレフォニー サポートをめぐる最近の努力の大部分は、こうした新しいテクノロジーを POTS 911 機能と同等なものにすることを目的としています。

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

• Cisco の音声、ビデオ、データの統合アーキテクチャ（AVVID）に、必要なインターフェイス（FXO VIC）をサポートします。

• POTS 回線を 911 コール専用にすることができます。

• システム構成の残りの部分が、FXO 対応シャーシに対応している場合は、POTS 回線インターフェイスに関連した資産コストを低減できます。

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

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

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

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

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

もちろん、この方法は、DID 電話機と非 DID 電話機を区別しません。911 への発信コールはすべて、E911 ネットワークによって同じものとして扱われます。ANI は POTS 回線番号に過ぎないので、E911 ネットワークに提示される ANI を Cisco CallManager が制御できるようにするツール（たとえば、発信者番号変換マスク）は、無意味です。

AnyCo の例

AnyCo の状況は、次のように混在しています。

• 3 つのロケーション（AlphaVille、AlphaGulch、および BetaTown）は、同じ LEC（Alpha Bell）によってサービスが提供されます。

• 2 つのロケーション（AlphaVille および AlphaGulch）は、同じ E911 選択ルータによってサービスが提供されます。これにより、911 コールに同一インターフェイスを使用する可能性があります。

AlphaVille の場合

PRI トランクが、汎用 PSTN ニーズによって AlphaVille セントラル オフィス（CO）にすでに接続されているので、911 サービスに対応できます。LEC は、911 コールを受け入れ、適切な PSAP にコールをルーティングするために発番号を ANI として転送し、その ALI フィールドを検索することが確認されています。

AlphaGulch の場合

911 コールは、WAN を介して、AlphaVille の AnyCo メイン サイトに戻すようにルーティングされ、Alpha Bell（CO）PRI ポートから E911 選択ルータに発信されます。しかし、この方法では、WAN の障害時に、911 コールを AlphaVille から発信するためのパスがありません。さらに、AlphaVille CO のエリアコードは、現在、AlphaGulch と同じですが、エリア コード分割の対象になっています。分割が行われた後、AlphaVille CO を選択ルータに接続するトランクは、AlphaGulch CO で使用中の新しいエリア コードをサポートしない場合があります。

したがって、AlphaGulch は、911 コールの伝送だけのために、複数の POTS 回線をプロビジョニングすることを選択します。

BetaTown の場合

PSAP にサービスを提供する LEC も Alpha Bell ですが、選択ルータが異なります。したがって、BetaTown CO を通じて BetaTown 選択ルータに接続するために、BetaTown では別のインターフェイスが必要です。BetaTown は十分に大きな規模をもつため、PRI トランクがすでに計画され、LEC は 911 対応であることを確認します。

CharlieVale の場合

LEC は、911 対応 PRI トランクをサポートできません。また、POTS 回線ソリューション用の緊急ロケーション識別番号（ELIN）が多すぎます。したがって、CharlieVale は、選択ルータに直接接続される専用 911 トランク（CAMA）をプロビジョニングする必要があります。

要約

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

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

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

この要件は、各 MLTS 電話機のロケーションを個々に識別するのではなく、電話機を「ゾーン」（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 に関連付けることができます。911 コールが発信されると、関連した ELIN を PSAP に送信することによって、ERL（複数の電話機に対して同一）が識別されます。この例のように、電話機が均等に分散されている場合、10 台の電話機を持つ各グループには、同じ ERL があり、したがって同じ ELIN をもちます。

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

AnyCo の例

最大 ERL サイズとして 7000 平方フィートを使用すると、AnyCo には次の数の ERL が必要です。

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

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

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

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

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

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

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

このタイプのインターフェイスを使用すると、ネットワークに渡される発番号識別は MLTS によって制御されます。MLTS のテレフォニー ルーティング テーブルは、発信側電話機の ERL に基づいて、正しい ELIN をコールに関連付けます。Cisco CallManager は、911 コールの処理に指定されたルート リスト内で発信者番号変換マスクを制御することによって、電話機を ERL に関連付けます。電話機の「固有」発信者識別情報を使用するのではなく、電話機の ERL には ELIN を使用します。E911 ルート リストで ELIN を制御すると、Cisco CallManager は、911 コールのみに ELIN を使用することができ、電話機固有の番号を、PSTN コールと内部コール用の発信者番号識別（CLID）として使用できます。

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

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

PSAP コールバック

911 コールは通常、PSAP に発信されますが、PSAP は、初期会話の完了後、発信者の呼び出しを必要とする場合があります。PSAP がコールバックできるかどうかは、PSAP が最初の着信コールと共に受信する情報によって決まります。

E911 ネットワークから PSAP へのコール関連情報は、次の 2 つの部分から成るプロセスによって送信されます。

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

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

–発信者の名前

–住所

–該当する公衆安全機関

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

標準的な状況

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

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

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

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

例外的な状況

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

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

電話機のロケーション

この章の説明はすべて、電話機のロケーションが静的（固定）であることを前提としています。Cisco AVVID アーキテクチャ内で使用可能なすべてのツールは、電話機の静的ロケーションに基づいて 911 コールを処理すると共に、Cisco CallManager を使用して MLTS を適切に設定できるようにします。特に、Cisco CallManager の 911 コール検索スペース、パーティション、ルート リスト、発信者番号変換マスク、およびロケーション構成は、デバイスの物理的なロケーションに対して設定されます。

非固定電話機の考慮事項

Cisco CallManager のコール検索スペース、パーティション、ルート リスト、発信者番号変換マスク、およびロケーション構成は、同じ ERL 内のすべての電話機で共有されます。したがって、電話機が ERL 境界内で移動する場合は、これ以上、再設定は必要ありません。

しかし、電話機が ERL 境界を超えて移動する場合、新たな場所に設置された電話機からの 911 コールのルーティングは、元の設定のままでは正しく行われません。別の ERL に物理的に配置されるので、電話機は現在の ERL の ELIN を使用する必要があります。Cisco CallManager データベースで設定が変更されない場合、次のイベントが発生します。

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

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

• PSAP に提供されるコールバック機能により、誤ったエリアが発生する可能性があります。

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

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

この状況を修復する方法は、Cisco CallManager における電話機の設定（コール検索スペース、パーティション、ルート リスト、発信者番号変換マスク、およびロケーション情報を含む）を手作業で更新して、新しい物理ロケーションを反映することだけです。

Cisco Emergency Responder

Voice over IP（VoIP）テクノロジーの主な利点の 1 つは、電話機を移動、追加、および変更（MAC）した場合、その管理が簡単になることです。ユーザが介入することなく自動的に 911 情報を更新する MAC をサポートするために、シスコは、Cisco ER（Cisco Emergency Responder）と呼ばれる製品を開発しました。

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

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

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

• 緊急コールが進行中であることを知らせるために、指定された通話者へのオンサイト通知が可能です（ポケットベル、電子メール、または電話による）。この通知には、発信者の名前と電話番号、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 は、敷設されたネットワーク インフラストラクチャとの Telnet、または簡易ネットワーク管理プロトコル（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 にルーティングするために使用されます。

• コールを電話機 B から解除した後、PSAP X は、電話機 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 しかない場合、状況は例 1 とほぼ同じになります。

緊急コール ストリング

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

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

また、ユーザが誤って緊急ストリングをダイヤルした場合に適切な対応ができるように訓練することも望まれます。北米では、アクセス コード 9 を使用して長距離番号にアクセスしようとするユーザが、誤って 911 をダイヤルする可能性があります。このような場合、ユーザは、緊急事態ではないので、緊急隊員を派遣する必要がないことを確認するために、回線を保持する必要があります。

ヨーロッパでは、欧州連合の共通緊急番号として 112 を指定するために、統一した努力が行われています。

緊急コールの応答ポイント

緊急コールの宛先は企業のポリシーの問題です。任意のロケーションの標準的な選択肢は次のとおりです。

• 企業の保安部隊へのオンネット

• ローカル PSAP へのオフネット

コールをオフネットでルーティングするための法律上の要件については、地方の条例を調べてください。

PSAP 管轄境界

北米の緊急コールは、通常、PSAP にルーティングされます。各 PSAP には、所定の地域に対する管轄権があるので、緊急コールが、所定の PSAP 管轄区域外へルーティングされないことを確認する必要があります。特に、電話デバイスが置かれている物理的な各ロケーションを、該当するローカル PSAP に関連付ける必要があります。

地域の公衆安全情報サービスに問い合わせると、必要な PSAP 情報を入手できます。所定の地区を担当する PSAP を決定するには、一般に、地域の消防署や警察に問い合わせるのが最善です。地域電話会社の電話番号帳には、通常、所定地域の担当機関がリストされています。

標準的な状況

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

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

例外的な状況

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

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

緊急コール用のダイヤル プラン設定

受け付ける緊急コール ダイヤル ストリングを定義するには、明示的なルート パターンを使用することをお勧めします（たとえば、911 用に 1 つのルート パターンと、9.911 用にもう 1 つのルート パターン）。北米では、911 コールの認識に、@ ワイルドカードをルート フィルタと組み合せて使用することができますが、その設定を保持するのが難しくなるので、この方法はお勧めしません。

9 がオフネット アクセス コードとして使用されるシステムでは、911 および 9911 が、他の有効なストリングと重複する可能性があります。このような場合、コールがルーティングされる前に、番号間のタイムアウトを発信者が待たなければならない状態が発生することがあります。このため、緊急ルート パターンに Urgent Priority のマークを明示的に付けて、Cisco CallManager が、コールのルーティング前に、番号間タイムアウト（Timer T.302）を待機しないようにすることを強くお勧めします。

北米以外の地域では、Urgent Priority フラグをお勧めします。重複するダイヤル プラン項目をシステムに追加する場合、Urgent Priority フラグにより、緊急ストリング（たとえば、112）の認識がその他の可能な一致によって遅延しないことが確実になります。

ゲートウェイの配置

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

Cisco AVVID などの 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 コールは処理可能にしておく必要があります。このような状況に備えて、明示トランク グループを 911 コール専用にすることができます。

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

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

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

ゲートウェイ インターフェイス

リストされるゲートウェイ インターフェイスには、次のガイドラインと考慮事項が適用されます。

• Primary Rate Interface（PRI）

PRI インターフェイスは、常に 911 コールを受け入れることができるとは限りません。一部の地域電話会社（LEC）は、着番号が 911 である場合、コールのセットアップ時に提示される発番号情報をオーバーライトします。PRI インターフェイスを使用する計画の場合は、LEC が PRI 上で 911 コールを受け入れることを確認してください。このサービスをオプションとして提供する LEC もあれば、Class 5 スイッチ機能の制限により、PRI トランク上で 911 コールを受け入れることができない LEC もあります。このサービスが利用可能である場合は、発番号の範囲が LEC の仕様内であることを確認してください。たとえば、PRI トランクが Numbering Plan Area（NPA）408 内の Class 5 スイッチに接続される場合、NPA が 415 の発番号で 911 コールを正しくルーティングできない場合があります。

• アナログ電話回線（POTS）

POTS 回線は、ロケーションの規模が小さい多くの状況に適しています。Foreign Exchange Office（FXO）インターフェイスから POTS 回線に送信されるすべての 911 コールは、PSAP からは同じように見えることに注意してください。つまり、同じ自動番号識別（ANI）と自動ロケーション情報（ALI）として扱われます。

• Centralized Automatic Message Accounting（CAMA）

CAMA トランクは、一般に、企業テレフォニー システムを直接、LEC の E911 インフラストラクチャに接続するために使用されます。911 以外の宛先へのコールの処理には使用できません。CAMA トランクでは、コールごとに、ANI の完全な制御が可能です。

応答監視

通常の状態では、緊急番号に発信されたコールは、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）コール（使用可能である場合）に影響を与えます。

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

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

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

ゲートキーパー制御のコール アドミッション制御ゾーンを超えたデバイスの移動は、同じ理由から、Cisco ER ではサポートできません。ただし、Cisco ER は、コール アドミッション制御を必要としないロケーション内でのデバイスの移動は、完全にサポートできます。

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

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

ソフト クライアント

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

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

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

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

テスト コール

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

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

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

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

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

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

• IP フォン上のコール所要時間タイマーを調べることによって、応答監視が受信されたことを確認します。

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

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