Cisco Collaboration システム 10.x ソリューション リファレンス ネットワーク デザイン(SRND)
緊急サービス
緊急サービス
発行日;2014/04/25 | 英語版ドキュメント(2013/11/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 27MB) | フィードバック

目次

緊急サービス

この章の新規情報

911 緊急サービスのアーキテクチャ

Public Safety Answering Point(PSAP)

選択ルータ

自動ロケーション識別データベース

Private Switch ALI

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

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

インターフェイス タイプ

動的 ANI(トランク接続)

静的 ANI(回線接続)

Cisco Emergency Responder

緊急サービスのハイ アベイラビリティ

Cisco Emergency Responder クラスタリングのキャパシティ プランニング

911 緊急サービスの設計に関する考慮事項

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

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

ダイヤル プランに関する考慮事項

ゲートウェイに関する考慮事項

ゲートウェイの配置

ゲートウェイのブロック

応答監視

Cisco Emergency Responder の設計に関する考慮事項

コール アドミッション制御ロケーション間のデバイス モビリティ

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

Cisco Emergency Responder および Extension Mobility

Cisco Emergency Responder およびビデオ

ソフト クライアント

オフプレミスまたはコラボレーション エッジのエンドポイント

テスト コール

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

Cisco Emergency Responder の配置モデル

単一の Cisco Emergency Responder グループ

複数の Cisco Emergency Responder グループ

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

Cisco Emergency Responder の WAN 配置

ALI フォーマット

緊急サービス

通信システムを適切に導入するには、緊急サービスが非常に重要です。この章では、緊急コールの計画に不可欠な次の主要な設計上の考慮事項について説明します。

「911 緊急サービスのアーキテクチャ」

「Cisco Emergency Responder」

「緊急サービスのハイ アベイラビリティ」

「Cisco Emergency Responder クラスタリングのキャパシティ プランニング」

「911 緊急サービスの設計に関する考慮事項」

「Cisco Emergency Responder の配置モデル」

「ALI フォーマット」

この章では、カナダおよび米国で配置されている 911 緊急ネットワークに固有の情報について説明します。ここで説明する概念の多くは、他の地域にも適応できます。緊急コール機能の適切な実装については、ローカル テレフォニー ネットワーク プロバイダーにご相談ください。

米国の一部の州では、Multi-Line Telephone System(MLTS)のユーザに必要な 911 機能を対象にした法律がすでに制定されています。また、National Emergency Number Association(NENA)が『 NENA Technical Requirements Document on Model Legislation E9-1-1 for Multi-Line Telephone Systems 』を制作しています。これは、次のサイトからオンラインで入手できます。

http://www.nena.org/

この章は、北米在住の PSTN ユーザに使用可能な汎用 911 機能について十分に理解している読者を対象にしています。


) この章で説明する内容は、Cisco Emergency Responder が Cisco Unified Communications Manager(Unified CM)と共に使用される場合のみ適用されます。Cisco TelePresence Video Communication Server(VCS)は現在、緊急サービスをサポートしていません。


この章の新規情報

表 15-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

 

表 15-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

コラボレーション エッジとオフプレミスのエンドポイント

「オフプレミスまたはコラボレーション エッジのエンドポイント」

2013 年 11 月 19 日

911 緊急サービスのアーキテクチャ

この項では、Multi-Line Telephone Systems(MLTS)における緊急コールの機能要件の一部について説明します。ここでの緊急コールとは、北米の公衆電話交換網(PSTN)によって提供される 911 コールのことです。

緊急サービスのアーキテクチャは、通常次の要素から構成されます。

緊急事態にある発信者は、固定回線、携帯電話機、または音声コールを行うことができる任意のデバイスから緊急サービスをダイヤルできる必要があります。

緊急サービス コール ハンドラが緊急要求に応答し、警察、消防、医療などの必要なサービスを派遣できる必要があります。

援助を提供するには、コール ハンドラは、緊急事態にある発信者のロケーションをできるだけ正確に特定できる必要があります。

発信者のロケーションに最も近い緊急サービス コール ハンドラにコールをルーティングするには、緊急サービス ネットワークが必要です。

次の項では、911 緊急サービス アーキテクチャの重要なアーキテクチャ コンポーネントのいくつかについて説明します。

Public Safety Answering Point(PSAP)

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

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

標準的な状況

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

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

例外的な状況

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

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

選択ルータ

選択ルータは、発信者の地理的な場所と自動番号識別(ANI)に基づいたコール送信のために適切な PSAP を決定する緊急サービス ネットワークのノードです。通常、地域通信事業者(LEC)が選択ルータを稼働します。したがって、発信者がそのロケーションに基づいて適切な選択ルータにルーティングされるようエンタープライズ IP 通信ネットワークが設計されている必要があります。

自動ロケーション識別データベース

発信者のロケーション情報は、911 サービス インフラストラクチャの重要な部分です。自動ロケーション識別(ALI)データベースには LEC により提供された特定の地理的なロケーションに関する情報が保持されます。各 911 コールに対して、PSAP は ALI データベースを検索し、発信番号の ANI に基づいて発信者のロケーションを取得します。ALI データベースでは、アドレスが Master Street Address Guide(MSAG)形式で保存されます。ALI データベースは、ローカル緊急サービス管理側の代わりに、契約を締結したサード パーティ(通常は現在の地域通信事業者(LEC))によって保守されます。

Private Switch ALI

Private Switch ALI(PS/ALI)は、MLTS オペレータが各エンドポイントに詳細なアドレスとロケーション情報を提供できるようにする 911 緊急応答システムの拡張機能です。このサービスにより、顧客が生成したアドレス テーブルを ALI データベースにロードできるようになります。この結果、MLTS システムの各ステーションの電話番号から 911 にコールされた場合に、MLTS システムの各ステーションを一意に識別できるようになります。通信システムにより生成されたステーション固有またはロケーション固有の自動番号識別(ANI)は、発信者の正確なロケーションを特定するために直接 E911 システムに渡すことができます。次に、PSAP オペレータは、正確な住所、建物、階、部屋、またはパーティションに緊急対応人員を派遣できます。この結果、作業が簡略化され、精度が高まります。

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

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

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

標準的な状況

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

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

例外的な状況

MLTS インターフェイスから PSTN へ接続するために使用する地域通信事業(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.att.com/clec/hb/shell.cfm?section=782 には、California および Nevada の AT&T がカバーする管轄地区についての貴重なデータが提供されています)。しかし、911 コール ルーティングを設計および実装する前に、該当するインターフェイス ポイントの適切な情報を LEC から入手しておくことを強く推奨します。


インターフェイス タイプ

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

自動番号識別(ANI)は、ネットワークが適切な宛先へ 911 コールをルーティングするために使用する、発信側の北米番号計画の番号を参照します。この番号は、PSAP がコールの自動ロケーション識別(ALI)を検索するためにも使用されます。

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

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

動的 ANI 割り当て

静的 ANI 割り当て

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

動的 ANI(トランク接続)

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

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

Integrated Services Digital Network Primary Rate Interface(ISDN-PRI、または単に PRI)

Centralized Automatic Message Accounting(CAMA)。

PRI

このタイプのインターフェイスは、通常、通信システムを PSTN Class 5 スイッチに接続します。発呼側番号(CPN)は、発信側の E.164 番号を識別するためにコールのセットアップ時に使用されます。

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

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

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


) CPN は、ルーティング可能な北米番号計画の番号である必要があります。つまり、CPN は、関連した E911 選択ルータのルーティング データベースに入力されている必要があります。



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


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

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

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

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

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

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

静的 ANI(回線接続)

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

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

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

POTS 回線に関連する運用コストが低くなります。

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

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

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

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

このタイプのインターフェイスを介した 911 発信コールはすべて、E911 ネットワークによって同じものとして扱われます。ANI は単なる POTS 回線番号の可能性があるため、E911 ネットワークに提示される ANI 操作を制御できるようにするツール(トランスレーションまたはトランスフォーメーションなど)は、無関係です。

Cisco Emergency Responder

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

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

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

コールバックのために緊急ロケーション識別番号(ELIN)を発信側電話機に動的に関連付けます。上記の項で説明されている一般的な緊急サービスのシナリオと異なり、Cisco Emergency Responder は、911 コールを発信した電話機にコールバックできるようにします。

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

ERL と ELIN の詳細については、「緊急応答ロケーションのマッピング」「緊急ロケーション識別番号のマッピング」を参照してください。Cisco Emergency Responder の詳細については、「Cisco Emergency Responder の設計に関する考慮事項」と、次の Web サイトで入手可能な Cisco Emergency Responder 製品のマニュアルを参照してください。

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

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

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

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

Cisco Emergency Responder はコールの発信ポートを検出すると、そのコールを、そのポートのロケーション用として事前に確立された ERL に関連付けます。このプロセスは、ロケーションに事前に確立された ELIN との関連付けと、発信 ERL に基づく、E911 インフラストラクチャの適切な出口点の選択も行います。

また、Cisco Emergency Responder は、IP サブネットに対して ERL を設定し、IP アドレス別に IP エンドポイントのロケーションを割り当てる機能を提供します。この機能は、接続されたスイッチ ポートで Cisco Emergency Responder が見つけることができない、Cisco Unified CM に登録されたワイヤレス IP フォン、IP ソフトフォン、Cisco Discovery Protocol(CDP)をサポートしていないコラボレーション エンドポイント、およびサードパーティの SIP エンドポイントを見つけるために使用できます。また、この機能は、有線の Cisco Collaboration エンドポイントに対して接続されたスイッチ ポート ロケーションの代わりに使用したり、これらのスイッチ ポート ロケーションに追加して使用したりできます。Cisco Collaboration エンドポイントに対して接続されたスイッチ ポートと IP サブネット ロケーションの両方が利用可能である場合、Cisco Emergency Responder は接続されたスイッチ ポートを優先して利用します。これは、接続されたスイッチ ポートは通常 IP サブネット ロケーションよりも具体的であるためです。接続されたスイッチ ポートの検出で遅延やエラーが発生した場合であっても適切な ERL が割り当てられるように、接続されたスイッチ ポートと IP サブネット ロケーションの両方を使用することを推奨します。

Cisco Emergency Responder では、1 つの ERL に対して 2 つ以上の 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 Emergency Responder では、各 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 人の発信者にしか正しく到達できません。

緊急サービスのハイ アベイラビリティ

最も危機的な状況であってもユーザが緊急サービスを利用できることは非常に重要です。したがって、企業で緊急サービスを配置する場合は、ハイ アベイラビリティの計画を慎重に行う必要があります。

Cisco Emergency Responder は、アクティブ/スタンバイ モードで最大 2 台のサーバを使用するクラスタリングをサポートします。データは、プライマリ Cisco Emergency Responder サーバとセカンダリ Cisco Emergency Responder サーバ間で同期されます。プライマリ サーバが利用できない場合にコールがセカンダリ サーバにルーティングされるようにするために、システム管理者は特定のプロビジョニング ガイドラインに従って、CTI ルート ポイントと、Cisco Unified CM でこれらの CTI ルートポイントに関連付けられた電話番号(DN)を設定する必要があります。設定の詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 』を参照してください。

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

両方の Cisco Emergency Responder サーバが利用できない場合は、ローカル ルート グループ(LRG)を使用して適切な ELIN/ERL(Cisco Emergency Responder が提供したものよりも具体的でない可能性があります)を持つ適切な PSAP にコールをルーティングできます。また、別の方法として、コールを内部セキュリティ オフィスにルーティングして発信者のロケーションを決定できます。いずれの場合であっても、このプロビジョニングは Cisco Unified CM で実行する必要があります。

Cisco Emergency Responder の冗長性以外に、911 緊急コールをルーティングし、単一障害点を回避できるように Cisco Unified CM の冗長性とゲートウェイ/トランクの冗長性も考慮する必要があります。

Cisco Emergency Responder クラスタリングのキャパシティ プランニング

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

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

Emergency Responder の最大ローミング キャパシティ制限を超える必要のある配置(たとえば、複数の Unified CM クラスタを含む大規模なキャンパス配置)では、IP サブネットによって電話機の移動をトラッキングできます。各 Cisco Emergency Responder グループで IP サブネットを定義し、Cisco Emergency Responder グループごとに各 ERL を 1 つの ELIN に割り当てることによって、実質的にローミング電話機をなくすことができます。これは、キャンパス内のすべての電話機が、それぞれの Cisco Emergency Responder グループのトラッキング ドメインに含まれるためです。

適切なサイジングを確実に行うには、Cisco Unified Communications Sizing Tool(Unified CST)を使用してください。このツールは、シスコのパートナーと従業員だけが利用できます( http://tools.cisco.com/cucst で適切なログインが必要)。このサイジング ツールにアクセスできない場合は、シスコ アカウント チームまたはパートナー インテグレータと協力してシステムのサイジングを適切に行ってください。

911 緊急サービスの設計に関する考慮事項

Multi-Line Telephone System(MLTS)配置の 911 緊急サービスを計画している場合は、最初に電話サービスが必要なすべての物理ロケーションを確立します。これらのロケーションは、次のように分類できます。

単一ビル配置:すべてのユーザは同じ建物に存在しています。

単一キャンパス配置:ユーザは近距離にある建物のグループに存在しています。

マルチサイト配置:ユーザは地理的に広い範囲に分散しており、WAN 接続を介して呼処理サイトにリンクされています。

これらのロケーション(つまり、配置のタイプ)は、911 サービスの設計と実装に使用される基準に影響を与えます。次の各項で、主要な基準を、それぞれの一般的な状況および例外的な状況とともに説明します。これらの基準を分析し、適用する際には、ネットワーク内の電話機ロケーションによって受ける影響を考慮してください。

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

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 データベース レコードを正確に更新できます。

これらはコールバック用に PSAP から到達可能である必要があります。

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

動的 ANI インターフェイス

このタイプのインターフェイスを使用すると、ネットワークに渡される発呼側番号識別は MLTS によって制御されます。MLTS のテレフォニー ルーティング テーブルは、発信側エンドポイントの ERL に基づいて、正しい ELIN をコールに関連付けます。Cisco Emergency Responder が配置されていないシナリオの場合、Unified CM によりトランスフォーメーション マスクを使用して、911 へのコールの発呼側番号を変更できます。たとえば、所定の ERL 内にあるすべてのエンドポイントが、トランスレーション パターン(911)を含み、かつエンドポイントの CPN をそのロケーションの ELIN に置き換える発信者番号トランスフォーメーション マスクも含むパーティションをリストする同じコーリング サーチ スペースを共有できます。一方、Cisco Emergency Responder が配置されている場合、発呼側番号の変更は Emergency Responder システムで実行する必要があります。

静的 ANI インターフェイス

このタイプのインターフェイスを使用すると、ネットワークに渡される発呼側番号識別は PSTN によって制御されます。これは、インターフェイスが 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 に関連した PSTN 番号です。PSTN から ELIN にコールすると、そのコールは、MLTS によって制御されるインターフェイス上で終端します。

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

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

例外的な状況

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

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

ダイヤル プランに関する考慮事項

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

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

これ以外の緊急コール ストリングを、システム上で並行してサポートできます。システム ユーザには、選択した緊急コール ストリングを想定した訓練を行うことを強く推奨します。

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

マルチサイト配置では、ダイヤル プラン設定により、緊急コールがサイトに対してローカルな PSTN ゲートウェイを介して常にルーティングされ、緊急コールが該当する地域で最も近い PSAP にルーティングされるようにする必要があります。これを実現するメカニズムの 1 つとして、Cisco Unified CM のローカル ルート グループ機能を使用することがあります。集中型 PSTN アクセスによるマルチサイト配置の場合、市内電話による PSAP へのルーティングはできません。集中型 PSTN アクセスによる配置では、一元化された接続に対する PSTN プロバイダーは ANI または ELIN に基づいて適切な PSAP に緊急コールをルーティングします。

また、マルチサイト配置では、緊急番号が、常に到達可能であり、実装されたサービス クラス(CoS)に関係なくモビリティ ユーザ(拡張モビリティおよびデバイス モビリティ)のためにローカル PSTN ゲートウェイを介してルーティングされることが非常に重要です。サイト/デバイス方法が使用される場合は、緊急コールをルーティングするためにデバイスのコーリング サーチ スペース(CSS)を使用できます。

シスコは、Cisco Emergency Responder で発信側変更を有効にすることを推奨しています。この機能が有効な場合は、発呼側番号が Cisco Emergency Responder によって緊急コールを表す ELIN で置き換えられます。発信側変更が有効でない場合は、DID が PSAP に送信されます。または、発信側が ELIN で置き換えられるように Cisco Unified CM を設定する必要があります。

ゲートウェイに関する考慮事項

システムの緊急コールを処理するゲートウェイを選択する際には、次の要素を考慮してください。

「ゲートウェイの配置」

「ゲートウェイのブロック」

「応答監視」

ゲートウェイの配置

地域通信事業者(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 つの方法は、通常の PSTN コールと同じトランク グループに緊急コールを送信し(インターフェイスが許可する場合)、専用緊急トランク グループへの代替パスを用意するものです。後者の方法では、最大限の柔軟性が得られます。

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

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

応答監視

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

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

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

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

progress_ind alert enable 8

このコマンドは、アラートの受信時にプログレス インジケータ 8(インバンド情報が使用可能)を受信することに相当します。このコマンドを使用すると、ゲートウェイの POTS 側が、コールの起点方向の音声を接続できます。

voice rtp send-recv

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

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

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

Cisco Emergency Responder の設計に関する考慮事項

デバイス モビリティにより、緊急コールに特別な設計上の考慮事項が生じます。Cisco Emergency Responder(Emergency Responder)は、デバイスの動的な物理ロケーションに基づいて、デバイス モビリティをトラッキングし、システムによる緊急コールのルーティングを適合させるために使用できます。

コール アドミッション制御ロケーション間のデバイス モビリティ

集中型呼処理配置では、Cisco Emergency Responder は Cisco エンドポイントの移動を検出し、移動したエンドポイントを適切な ERL に自動的に再び割り当てることができます。ただし、移動したエンドポイントに対する Cisco Unified CM のロケーションベースのコール アドミッション制御は、新しいロケーションの電話機の WAN 帯域幅使用量を正しく把握できず、WAN 帯域幅リソースのオーバーサブスクリプションやアンダーサブスクリプションが発生する可能性があります。たとえば、電話機を支社 A から支社 B に物理的に移動したにもかかわらず、エンドポイントのコール アドミッション制御ロケーションが同じままである(たとえば、Location_A など)場合、Location_A に使用可能な帯域幅がすべて他のコールで使用中であれば、そのエンドポイントから 911 に発信するコールは、コール アドミッション制御拒否によりブロックされる可能性があります。このようなコールのブロックを回避するために、デバイスのロケーションとリージョン パラメータを使用するよう手動で設定する必要がある場合があります。

Cisco Unified CM デバイス モビリティを使用すると、新しい物理ロケーションを反映するよう Unified CM でエンドポイントの設定(コーリング サーチ スペースとロケーション情報を含む)を自動的に更新できます。デバイス モビリティを使用しない場合は、Cisco Unified CM で手動で設定を変更する必要があることがあります。

デバイス モビリティの詳細については、次の URL で入手可能な『 Cisco Collaboration 9.x Solution Reference Network Designs (SRND) 』のデバイス モビリティの情報を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/clb09.html

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

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

Cisco Emergency Responder および Extension Mobility

Cisco Emergency Responder は、Cisco Unified CM クラスタ内で Extension Mobility をサポートします。また、両方の Cisco Unified CM クラスタが、共通の Cisco Emergency Responder サーバまたはグループによってサポートされるか、Cisco Emergency Responder クラスタとして設定された 2 つの Cisco Emergency Responder サーバまたはグループによってサポートされる場合、Cisco Emergency Responder は、Extension Mobility Cross-Cluster(EMCC)もサポートします。いずれの場合でも、Cisco Unified CM クラスタが、911 コールに対する EMCC に関連付けられた付加コーリング サーチ スペース(CSS)を使用するよう設定せず、両方の Cisco Unified CM クラスタですべての 911 コールに対して Cisco Emergency Responder を使用するよう設定する必要があります。

Cisco Emergency Responder およびビデオ

Cisco Emergency Responder は、Cisco Video Collaboration エンドポイントを、その機能に応じて次の方法で検出できます。

「CDP をサポートするビデオ コラボレーション エンドポイント」

「CDP をサポートしないビデオ コラボレーション エンドポイント」

ビデオ エンドポイントが検出された方法にかかわらず、ビデオは、PSAP への緊急コールのメディアとしてサポートされていないことに注意することが重要です。


) この章で説明する内容は、Cisco Emergency Responder が Cisco Unified Communications Manager(Unified CM)と共に使用される場合のみ適用されます。Cisco TelePresence Video Communication Server(VCS)は現在、緊急サービスをサポートしていません。


CDP をサポートするビデオ コラボレーション エンドポイント

Cisco Discovery Protocol(CDP)をサポートしている社内にあるビデオ コラボレーション エンドポイントについて、シスコは、次の URL で入手可能な『 Cisco Emergency Responder Administration Guide 』の最新バージョンにある Emergency Responder のスイッチ設定情報に示されているように、それらのエンドポイントを、CDP を通して Cisco Emergency Responder によって追跡される他のコラボレーション エンドポイントと同様に扱うことを推奨します。

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

社外にある CDP をサポートするビデオ コラボレーション エンドポイントについて、シスコは、次の URL で入手可能な『 Off-Premise Location Management User Guide for Cisco Emergency Responder 』の最新バージョンにある IP Phone の構外サポートに関する情報に示されているように、それらのビデオ コラボレーション エンドポイントを音声コラボレーション エンドポイントと同様に扱うことを推奨します。

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

CDP をサポートしないビデオ コラボレーション エンドポイント

Cisco Discovery Protocol(CDP)をサポートしないビデオ コラボレーション エンドポイントについて、シスコは、音声コラボレーション エンドポイントに専用回線を使用することを推奨します。ビデオ コラボレーション エンドポイントを追跡する必要がある場合、シスコは、次の URL で入手可能な『 Cisco Emergency Responder Administration Guide 』の最新バージョンにある IP サブネットベースの ERL の設定に関する情報に示されているように、IP サブネット ERL を設定することを推奨します。

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

ソフト クライアント

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

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

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

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

また、Cisco Emergency Responder は Intrado V9-1-1(米国でほとんどすべての PSAP に到達できる緊急コール配信サービス)との統合をサポートします。Cisco Emergency Responder と Intrado V9-1-1 の組み合わせにより、企業の外部の IP フォンとソフトフォンは Cisco Emergency Responder で提供された Web ページを介してロケーションを提供および更新できます。オフプレミス ロケーションからの緊急コールは、発信者のロケーションのために Intrado によって適切な PSAP に配信されます。

オフプレミスまたはコラボレーション エッジのエンドポイント

エンドポイントが企業の境界外に配置されている場合(たとえば、ホーム オフィスやホテルからの VPN アクセスなど)、または Cisco Unified Border Element Phone Proxy や Cisco Expressway モバイル アンド リモート アクセスなどの機能を使用したコラボレーション エッジを介して配置される場合、Cisco Emergency Responder は発信者のロケーションを特定できません。さらに、システムで、発信者のロケーションに該当する PSAP にコールを送信できるように、適切な位置にゲートウェイが配置されている可能性はほとんどありません。

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

リモート エンドポイントと緊急コールに関する追加情報については、「ソフト クライアント」についての前の項を参照してください。

テスト コール

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

テストを実施する際は、次の推奨事項を参考にしてください。

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

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

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

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

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

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

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

Cisco Emergency Responder の配置モデル

複数の Unified CM クラスタに基づく企業通信システムは、Cisco Emergency Responder(Emergency Responder)の機能のメリットを受けられます。

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

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


) Cisco Emergency Responder は、Cisco Unified Communications Manager Express(Unified CME)または Survivable Remote Mode Telephony(SRST)をサポートしません。SRST 配置の場合は、サイト公開番号を使用して 911 コールを PSTN にルーティングするよう適切なダイヤルピアを設定してください。Unified CME は、E911 をネイティブにサポートします。


単一の Cisco Emergency Responder グループ

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

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

図 15-1 2 つの Unified CM クラスタに接続されている単一の Cisco Emergency Responder グループ

 

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

SNMP を介して各 Unified CM クラスタとインターフェイスし、それぞれに設定されているエンドポイントに関する情報を収集します。

IP テレフォニー エンドポイントが接続されている SNMP を介した企業のアクセス スイッチ。エンドポイントのロケーションが IP サブネットに基づいて識別される場合、この接続は不要です。IP サブネットベースの ERL を設定する方法の詳細については、次の Web サイトで入手可能な『 Cisco Emergency Responder Administration Guide 』の「 Cisco Emergency Responder Configuration 」の章を参照してください。

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

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

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

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

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

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

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

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

複数の Cisco Emergency Responder グループ

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

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

SNMP:クラスタに設定されているエンドポイントに関する情報を収集します。

JTAPI:適切なゲートウェイへの、またはローミング エンドポイントの場合は適切な Unified CM クラスタへの、コール リダイレクションに関連する呼処理を可能にします。

その Cisco Emergency Responder グループの Unified CM に関連付けられているほとんどのエンドポイントの接続先となるアクセス スイッチ(SNMP を使用)。

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

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

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

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

図 15-2 複数の Cisco Emergency Responder グループ

 

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

Cisco Emergency Responder グループ A は、Unified CM クラスタ A とインターフェイスして、スイッチ A1 および A2 にアクセスする。このグループは、Unified CM クラスタ A に登録されているすべてのエンドポイントのホーム Cisco Emergency Responder グループであると見なされます。

同様に、Cisco Emergency Responder グループ B は、Unified CM クラスタ B とインターフェイスして、スイッチ B1 および B2 にアクセスする。このグループは、Unified CM クラスタ B に登録されているすべてのエンドポイントのホーム Cisco Emergency Responder グループであると見なされます。

Cisco Emergency Responder グループのトラッキング ドメイン内のエンドポイント移動

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

Cisco Emergency Responder クラスタのさまざまなトラッキング ドメイン間のエンドポイント移動

Cisco Emergency Responder クラスタは、実質的に、ロケーション情報を共有する Cisco Emergency Responder グループの集まりです。各グループは、アクセス スイッチ上または IP サブネット内で検出するすべてのエンドポイントのロケーションを共有します。

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

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

これに対し、Cisco Emergency Responder グループ B は、モニタ対象のスイッチの 1 つで、エンドポイント A3 の存在を検出します。エンドポイント A3 は、Unified CM クラスタ B に登録されていないため、 不明 なエンドポイントとして Cisco Emergency Responder LDAP データベースを介してアドバタイズされます。

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

Cisco Emergency Responder グループ A の [Unlocated Phone] ページには、このエンドポイントの MAC アドレスが、リモート Cisco Emergency Responder グループ(この場合は Cisco Emergency Responder グループ B)とともに表示されます。

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

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

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

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

1. エンドポイント A3 が、処理のために緊急コール ストリングを Unified CM クラスタ A に送信します。

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

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

4. Unified CM クラスタ A がコールを Unified CM クラスタ B に送信します。

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

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

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

8. Unified CM クラスタ B が、ゲートウェイを通じてコールを緊急 PSTN ネットワークに送信します。

Cisco Emergency Responder の WAN 配置

Cisco Emergency Responder Group は Cisco Unified CM クラスタからリモートで(つまり、WAN を介して)見つけることができます。また、プライマリ Cisco Emergency Responder サーバおよびセカンダリ Cisco Emergency Responder サーバを WAN を介して地理的に離れたサイトに配置することもできます。このような配置の場合、推奨されるラウンド トリップ時間(RTT)は 40 ms 以下であり、Cisco Emergency Responder サーバ間で必要な最小帯域幅は 1.544 Mbps です。いずれの場合も、各 Cisco Emergency Responder サーバと Unified CM クラスタ間の RTT が 80 ミリ秒を超えてはいけません。

ALI フォーマット

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

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

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

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

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

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

AFT の柔軟性を利用して、単一の Cisco Emergency Responder グループが、複数の ALI データベース フォーマットで ALI レコードをエクスポートできます。Cisco Emergency Responder グループがサービスを提供する Unified CM クラスタが 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 Tools の詳細については、次の Web サイトで入手可能なオンライン マニュアルを参照してください。

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

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