Cisco テクニカル ソリューション シリーズ：IP テレフォニー ソリューション ガイド

一般的なサイト情報

ここでは、カスタマー サイトについての一般的な情報を記述します。出荷情報は、いつでもカスタマー ファシリティ管理から収集されます。組合労働者がサイトの配送サービスを行っている場合は、ファシリティ管理者と連携するように配慮してください。

ソリューションの実装前に、 表 5-1 に記入しておく必要があります。

チームの情報

ここでは、実装チームのメンバーについて連絡先情報を記述します。実装サイクルが終わると、カスタマーが操作を管理するので、この情報が必要です。シスコシステムズまたはシスコ代理店のプロジェクト チームは、カスタマーのプロジェクト チームと緊密に協力して、ソリューションについての情報を伝える必要があります。情報が伝われば、カスタマーの満足度が上がり、将来必要なサポート量が減ります。

表 5-2 では、実装チームのメンバーについて連絡先情報をリストします。

プロジェクト管理

シスコ代理店のプロジェクト管理では、実装時にカスタマー用に 1 つの連絡先を設定する必要があります。プロジェクト管理者の責務には、次のものがあります。

• ファシリティ エンジニア、統合コンサルタント、およびその他の専門家と協力する。

• 複数のロケーションからの配送品の到着を、エンジニアや設置担当者と調整する。

• スケジュール通りに、仕様に従って実装を行うために、すべての関係者間のコミュニケーションを監督する。

プロジェクト管理者は、実装タスクのスケジュールを提示する必要があります。 表 5-3 は、IP テレフォニー実装の 1 つのコア サイトと 1 つのリモート サイト用の実装スケジュールの例です。各タスクに必要な日数は、プロジェクトの規模によって異なる場合があります。

実装の考慮事項

ここでは、実装チームが、下記の実装の考慮事項が満たされていることを確認するための情報を記述します。

前提事項

この実装を行うには、次の項目を前提とする必要があります。

• すべてのサイトで、機器が設置できる状態であり、カスタマーは、設置チームの到着前に、電源、空調、回線の設置、またはその他の作業が完了していることを確認している。

• カスタマーは、機器に接続する予定のすべてのライブ回線が、完全なテスト済みであり、ネットワーク トラフィックの伝送に適していることが証明済みであることを保証している。

• カスタマーは、すべての機器を受け取り、必要に応じてキャビネット内に電源レールと回路ブレーカーを設置し、電源を接続し、機器に供給できることを確認するために電源をテストしている。

• 実装時に、1 人以上のシスコ代理店の担当者または実装エンジニアがサイトに立ち会い、カスタマーの担当者が常に立ち会うことを前提とする。

安全についての情報

最新の安全に関する推奨事項があるかどうか、各 Cisco 製品に付属の製品資料を調べてください。次のリンクは、IP テレフォニー実装についての安全情報を提供します。

• Catalyst 3500

http://www.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/index.htm

• Catalyst 4000

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/index.htm

• Catalyst 6000

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/index.htm

• Cisco CallManager

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

実装ツールの要件

シスコの実装エンジニアには次のツールが必要です。

• VT100 エミュレータ、10BASE-T インターフェイス、FTP サーバ、TFTP クライアント アプリケーションを備えた PC

• コンソール ポート ケーブル DB9-RJ45/DB25

• イーサネット トランシーバ

• 10BASE-T イーサネット ケーブル

サイト調査表

サイト調査を行う最初のステップは、基本情報の表に記入した後、その基本情報を参照する表に記入することです。実際には、サイト調査の進行中に、これらの表を使用する必要があります。

表 5-4 では、正常なサイト調査用に記入する必要がある表をリストしています。

サイト情報の収集

ここでは、サイト調査用に収集する情報を簡単に説明します。下記に記述されている各サイト調査表は、次のロケーションにあります。
http://www.cisco.com/warp/public/788/solution_guide/forms/index.html#ss

• 一般的なサイト：初期調査時に次の一般的なサイト情報を記録します。

–サイト グループ：サイトのランダム グループをサイト グループ名に関連付けます。これにより、サイトのグループを 1 つの名前で指すことができます。これらのサイト グループ名は、連絡先の人物などのその他のエンティティに（表内で）関連付けることができます。必要に応じて、この表を使用して、独自のサイト グループを作成してください。

–プロジェクトの連絡先：プロジェクトの進行中に、支援を求める場合に連絡する先の人物についての情報を収集します。

–部屋：オフィス、会議室、または機器スペースの部屋を記録します。電話機の情報は、プロジェクトの会議スペース内、またはプロジェクト中に使用する機器の近くにある、IP Phoneで置き換えられる電話機についての情報を記録するためのものです。

–電話機：既存の電話機の情報を記録します。

–IP アドレス：サイトで使用中の IP アドレス、またはサイトに割り当てられている IP アドレスの範囲を記録します。

–文書：カスタマーから、またはサイトの調査時に収集される文書を記録します。

• 個々の機器： Cisco IP テレフォニー ソリューションの配置に関連した通信デバイスについての情報を記録します。この情報は、サイトの調査時に収集する必要があります。必ず、次のコンポーネント タイプについての情報を収集してください。ルータ、LAN スイッチ、WAN スイッチ、PBX、音声メール システム、ACD、IVR、CSU/DSU、マルチプレクサなどです。

• 販売注文と保守サポート：初期調査とサイト調査時に販売注文と保守サポートについての情報を記録します。

• サイト アクセスと手順の要件：特別なサイトへのアクセス方法と手順の要件についての情報を含みます。たとえば、警備員、X 線ゲート、安全検査、機器のサインインまたはサインアウトなどを使用してチェックインするための要件があります。この情報は、初期調査とサイト調査時に収集する必要があります。

• ユーザ サービスと機能：Cisco IP テレフォニー ソリューションで保持する、既存のすべての機能をリストし、記述します。この情報は、初期調査とサイト調査時に収集する必要があります。

• サイト間通信：回線（物理通信パス）とリンク（物理回線上で伝送される仮想回線）についての情報を収集します。大部分の場合、専用回線には仮想回線がありません。この情報の大部分は、サイト調査時に収集する必要があります。

• サービス機関：サイトまたはサイト グループ単位でカスタマーにサービスを提供する外部機関についての情報を保存します。この情報は、初期調査時に収集する必要があります。

• サイト調査の注記：サイト調査のあいまいな情報を明らかにする注記、または必要な情報を記録する注記の内、上記の表でリストされていないものを記入します。

• 文書：サイトに関連したあらゆるタイプの文書（平面図など）をリストします。

LAN 要件

表 5-5 では、IP テレフォニー ソリューションに必要な LAN スイッチのタイプをリストしています。

表 5-6 では、各タイプのスイッチの機能をリストしています。

WAN 要件

集中型コール処理配置モデルを使用する IP テレフォニーのインストレーションは、ハブアンドスポーク トポロジに限定されます。これは、ロケーション ベースのコール アドミッション制御（CAC）メカニズムだけが、各ロケーションに出入りできる帯域幅を記録するからです。

WAN ハードウェア要件

表 5-7 では、WAN ハードウェア要件をリストしています。

WAN 接続オプションには、次のものがあります。

• 専用回線

• フレームリレー

• ATM

• ATM とフレームリレーのサービス インターワーキング（SIW）

WAN 帯域幅要件

IP テレフォニーの実装に使用可能な帯域幅を計算するには、 表 5-8 を使用してください。

QoS の要件

優先キューイングやトラフィック シェーピングなどの QoS メカニズムは、WAN エッジに置かれているルータで必要です。QoS メカニズムは、一般に帯域幅が少ない WAN 上で、音声トラフィックをデータ トラフィックから保護します。さらに、コール アドミッション制御方式も音声トラフィックによる WAN リンクの過剰サブスクリプション（それによる、確立されたコールの品質低下）を避けるために必要です。IP テレフォニー配置モデルの場合、コール アドミッション制御方式は、Cisco CallManager 内のロケーション ベースのものを使用して行われます。

トラフィック シェーピングは、主に次の 2 つの主な理由で必要です。

• ポリシングと、パケットのドロップを回避するために、ATM ネットワークまたはフレームリレー ネットワークとのトラフィック契約内にとどめる。

• 異なる回線速度でフレームリレー ネットワークまたは ATM ネットワークにリンクされるサイト間で、同等のトラフィック速度を維持する。たとえば、本社サイトに DS-3 があり、それ以外のサイトに DS-1 がある場合があります。トラフィック シェーピングは、ネットワーク内でパケット ロスにつながるバッファ オーバランを防ぐのに役立ちます。

リモート ブランチには、種々の Cisco ゲートウェイによる PSTN アクセスが提供されます。IP WAN に障害が起きた場合、または IP WAN 上で使用可能なすべての帯域幅が使い果たされた場合でも、リモート ブランチのユーザは、PSTN アクセス コードをダイヤルして、PSTN を介してコールを発信できます。

QoS ツールは、WAN にある低速リンク上で音声とトラフィックを正常に実行するのに不可欠です。WAN QoS 技法は、リンクの速度によって決まります。高速（768 Kbps 以上）では、音声の low latency queuing（LLQ）が、バッファを過剰サブスクリプションする可能性があるトラフィックのバースト時に、ジッタと損失を削減するのに必要です。これは、LAN インフラストラクチャのシナリオとほぼ同じです。

これより低いリンク速度では、シリアル化遅延の影響を最小限に抑えるために、リンク効率技法と呼ばれるその他の技法が必要です。

表 5-9 では、WAN テクノロジーとリンク速度に従って、IP テレフォニーをサポートするために使用可能にする必要がある、すべての機能とツールをまとめています。この項の残りの部分では、音声トラフィックとデータ トラフィックをサポートする WAN を設計する場合に、注意が必要な最も重要な技法をいくつか説明しています。

ゲートウェイの要件

IP テレフォニー ソリューションの実装では、ゲートウェイは、中央オフィスとリモート オフィス間の IP 接続を相互接続します。次の 3 つの表では、ゲートウェイ プロトコル、ゲートウェイ アナログ インターフェイス、およびゲートウェイ デジタル インターフェイス別に編成されたゲートウェイ情報をリストしています。

IP テレフォニーの要件

IP テレフォニー インフラストラクチャは、既存のソリッド ネットワーク インフラストラクチャの上に構築できます。IP テレフォニー インフラストラクチャには、次のデバイスと機能が組み込まれています。

• コール処理エージェント

• WAN を通過するコールに対するコール アドミッション制御メカニズム

• 音声および FAX/モデム ゲートウェイ

• トランスコーディングおよび ad-hoc 会議リソース

• エンド ユーザ デバイス

表 5-13 では、デバイスまたは機能ごとにシスコがサポートしているプラットフォームをリストしています。

表 5-14 では、Media Convergence Server の技術仕様をリストしています。

表 5-15 では、ICS7750の技術仕様をリストしています。

表 5-16 では、IP テレフォニー ソリューション デバイスに一般的なハードウェアとソフトウェアの要件をリストします。

電源と環境の要件

表 5-17 では、Cisco IP テレフォニー デバイスの消費電力と熱放散の要件をリストしています。

ソリューション設計のリビュー

設計のリビューにより、設計と設定がカスタマーの期待に応えるものであるかどうかを確認します。設計の変更が必要な場合は、ネットワークのロールアウトに影響を与える前に、変更を加える必要があります。

ソリューション設計のリビューには、次の項目が含まれます。

• ネットワーク トポロジ分析

• 音声ネットワーク分析

• データ ネットワーク分析

–LAN 要件分析

–WAN 要件分析

–WAN 帯域幅要件の分析

–IP テレフォニー要件の分析

ネットワーク トポロジ分析

ソリューション設計のリビューの最初のステップは、音声とデータのネットワーク ダイアグラムに必要な情報を収集することです。音声ネットワーク ダイアグラムには、次のコンポーネント（両側で）を含めてください。

• IP Phoneの終端ポイント（PBX/Centrex/Key システム）

• 終端ポイントと PSTN ネットワーク間のトランク数

• 他のサイトとのトランク（プライベートまたは VPN）の数

• 該当する場合、ローカル音声メール システムとのトランク数

• セット（ユーザ）数

データ ネットワーク ダイアグラムには、次のコンポーネント（両側で）を含めてください。

• ルータおよび遠隔サイトへのリンク（帯域幅付き）

• サイトのイーサネット スイッチ

• サイトのイーサネット ハブ

• 接続されているデバイスの数

音声ネットワーク分析

音声トランクは、デジタルとアナログのゲートウェイ製品に使用されます。音声ネットワーク分析により、特定の機能をサポートするのに必要な音声トランクの最適数が決まります。トランク タイプには、双方向トランク、着信コール専用のダイヤルイン方式（DID）トランク、および発信ダイヤル トランク用のダイヤルアウト方式（DOD）トランクが含まれます。評価により、3 つの別々のアプリケーションで 3 つのトランク タイプのキャパシティは、次のように決定されます。

• PSTN トランク：PSTN とのゲートウェイで使用される

• 音声メール トランク：音声メール サーバとの接続に使用される

• サイト間トランク：WAN 接続を表し、始めは別のゲートウェイを使用した後、後で WAN VoIP を使用する場合がある

表 5-19 では、現在のトランクの使用状況を明らかにするために、サイトごとに記入する表のサンプルを示しています。この表の一部のフィールドには、ゼロ値が指定されることがあります。

トランキング要件を判別するには、トラフィックを調査します。3 つの適用可能な方式を、望ましい順に下にリストしています。

1. トランク タイプ、ロケーション、およびアプリケーションごとに、混雑時トラフィック（BHT）値を示すトラフィック分析を行う。大部分の電話会社や PBX ベンダーは、指定された期間のトランク グループのレポートを容易に作成できます。たとえば、サイト A の双方向音声メール トランクが BHT 値 2 を示す場合、これは、双方向音声メール トランクで、混雑時のコール ボリュームが 120 分であることを示しています。トラフィック分析は、ピークの電話使用期間に行われるのが理想的ですが、テレフォニー トラフィック ボリュームが周期的に大きく変動しないと思われる場合は、ランダムな間隔で実行できます。この方式は、データの収集に適した方式です。

2. おおよその BHT 値を判別するために調べることができる、call data record（CDR; コール データ レコード）を収集する。この方式は、コール レコードで使用可能な詳細レベルに基づいて変動し、かなり時間がかかる場合があります。精度が劣り、簡単ではないので、この技法は、最後の手段として以外は、通常お勧めしません。コール試行の失敗とコール オーバーヘッド（呼び出し、話中、ダイヤル）の見積もりを考慮する必要があります。

3. 既存のトランキングを調べ、満足度のレベルについてカスタマーにたずねる。カスタマーが現在、トランクの数量に満足している場合は、Cisco IP テレフォニー ソリューション用にほぼ同じ量のゲートウェイ トランクを割り当てることができます。必要に応じて、トランクを追加できます。トラフィックの調査が行われていない既存のトランク グループによって生成される負荷を見積もる場合、トランク数とブロック係数 .01 を取って、（アーラン B を使用して）アーランで負荷を見積もります。この数値は、ゲートウェイがトランクを処理する場合にデータ ネットワークに持ち込まれる負荷について「最善の推測値」を提供する場合に使用できます。

BHT 値を取得する場合、査定者は、 http://www.erlang.com でのアーラン B カルキュレータを使用して、もしくは任意の数のコマーシャル パッケージまたはアーラン B テーブルを通じて、トランキング要件を理解できます。通常、ブロック係数 .01、すなわち 1 パーセントをお勧めしますが、カスタマーは、評価用にこの係数を変更できます。1 パーセントを推奨することを前提として、カスタマーが必要とするブロック係数を決定してください。推奨値とカスタマーの希望値は、トランク分析用の評価表に記入できます。

これらの表をレポートに取り込むために、カスタマーが提供する負荷係数、および希望のブロック係数（.01 を推奨）を、アーラン B 公式に挿入して、必要なトランク数を求めることができます。この数を、カスタマーの現在のトランキングと比較できます。

データ ネットワーク分析

データ ネットワーク分析には次のものが含まれます。

• LAN 要件の分析

• WAN 要件の分析

• WAN 帯域幅要件の分析

LAN 要件の分析

• 個別の 1 つの交換ポート上に、IP Phoneと、最大 1 つのデイジーチェーン PC が必要です。これにより、メディアの衝突ドメインが最小限に抑えられ、パフォーマンスの低下による遅延を防止できます。

• サーバとゲートウェイは、個々の交換ポート上に存在しなければなりません。それは、メディアの衝突ドメインを最小限に抑え、パフォーマンスの低下による遅延を防止するためです。

• 可能な場合は、全二重を使用する必要があります。

• LAN の通常のベスト プラクティスが適用されます。それには、ブロードキャスト ドメインのサイズ、トラフィック、イーサネット上の使用率、衝突率、低速デバイス接続などが含まれます。キャンパス LAN 設計については、『Designing High Performance Campus Intranets with Multilayer Switching』 White Paper を参照することをお勧めします。この資料は、次のロケーションにあります。
http://www.cisco.com/warp/public/cc/so/cuso/epso/entdes/highd_wp.htm

• LAN トポロジ内のリンクは、コアに近づくにつれて高速になります（障害がない）。

• LAN スイッチを接続するリンクは、共用メディア（ハブ）上に存在してはなりません。

• ファイアウォールは、データ ネットワーク上の提案音声パスに存在することはできません。ただし、この監査の範囲を超えた複雑な問題を解決する、音声プロトコル処理の特殊な設定がある場合を除きます。

• Network Address Translation（NAT; ネットワーク アドレス変換）システムも Port Address Translation（PAT; ポート アドレス変換）システムも、音声プロトコルを処理する特定の設定がなければ、データ ネットワーク上の提案音声パスに存在することはできません。

• IP Phone付きの各スイッチ ポートで提供される集約合計負荷は、5 秒間隔でそのポート上のメディア キャパシティの 80 パーセント未満でなければなりません。この概数は、音声の低下を防止するためのガイドラインです。

• 各スイッチ ポートで提供される集約マルチキャスト合計負荷は、メディア キャパシティの 20 パーセント未満でなければなりません。このタイプの負荷は、複数のビデオ マルチキャスト ストリームを使用するネットワークでのみ一般的です。次のようなマルチキャスト制御方式を使用して、個々のスイッチ ポート上で負荷を軽減できます。

–Cisco Group Management Protocol（CGMP）

–GARP Multicast Registration Protocol（GMRP）

–インターネット グループ管理プロトコル（IGMP）スヌーピング

WAN 要件の分析

コール アドミッション制御は、WAN 配置の帯域幅を割り当てるのに必要です。まれに、アドミッション制御がまだ実装されていない場合にも WAN を使用できることがあります。この場合、キューイング、トラフィック シェーピング、分割などの機能が、最適化に必要な場合があります。さらに、次の機能が必要になる場合があります。

• IP RTP 優先：12.0(5)T

• IP Precedence：11.2

• Differentiated services：12.0(6)T

優先順位付け

• IP RTP 優先：12.0(5)T

• WFQ：11.0

• CBWFQ：12.0(6)T

トラフィック シェーピング

• フレームリレー トラフィック シェーピング：11.2

• ATM トラフィック シェーピング：11.2

分割

• FRF.12 フレームリレー：12.0(4)T

• MLPPP - シリアル回線：12.0(6)T ファースト スイッチング

効率性

• 低速コーデック：コーデックによって異なる

• Compressed RTP：12.(1)T ファースト スイッチング

WAN 帯域幅要件の分析

見積もりのために、コールによって使用される帯域幅は、次の値とします。

• G.711：80 kbps

• G.729：30 kbps

• G.723：18 kbps

Voice Activity Detection（VAD）が使用される場合、消費される帯域幅数は、約 10 ～ 40 パーセント減る場合があります。VAD は、CallManager の設定でオンにしたり、オフにしたりすることができます。

帯域幅の見積もりは、中間リンクのカプセル化タイプ（たとえば、ATM 対 PPP）に応じて異なります。Real Time Protocol（RTP）ヘッダー圧縮を使用すると、CPU 時間を犠牲にした低速リンク上の帯域幅ニーズ、および圧縮を実行するデバイス上の遅延が、さらに減ります。さまざまな帯域幅削減方式に対する特定の長所と短所は、ここでの分析の範囲を超えています。これらの設定は、CallManager や IP Phone上ではなく、WAN 上の中間ルータで行う必要があるからです。さらに、音声を確実に伝送できる十分な QoS 機能を得るために、これらの中間ルータ上でソフトウェア、メモリ、またはハードウェアの更新が必要になる場合があります。

Note WAN ルータの QoS 機能が分からない場合は、これらの機能の監査が必要です。ただし、このような監査は、ここでの分析には含まれません。ネットワーク監査が必要な場合は、シスコ代理店のプロジェクト管理者またはアカウント管理者にお問い合せください。

データ ネットワークの推奨帯域幅の公式は次のとおりです。コール ロードを伝送するのに必要なトランク数（「音声ネットワーク分析」を参照）に、コールごとに必要な予想帯域幅を掛けます。

トランク数 × コールごとに必要な予想帯域幅 = 推奨帯域幅

たとえば、サイト間で 6 つのトランクが必要であることが決定され、エンコーディング技法が G.729 である場合、混雑時の負荷を処理するために必要な帯域幅は、約 30 kbps × 6 = 180 kbps になります。

IP テレフォニー要件の分析

IP テレフォニー ソリューションには、次の特性があります。

• WAN を介した圧縮音声

• 低ビット レート FAX リレー要件

• 拡張 QoS ツールの使用

• 音声メディア ストリーム用の Compressed RTP

Media Convergence Server（MCS）は、IP Phoneをサポートするテレフォニー アプリケーションを実行する、コンピューティング プラットフォームです。このアプリケーションには、次のものがあります。

• Cisco CallManager

• コンファレンス ブリッジ

• メディア転送点

• 音声/ユニファイド メッセージング

これらのアプリケーションがすべて、1 つの MCS 上に共存できる範囲は、アプリケーションの組み合せに提示される負荷によって異なります。MCS は、これらのアプリケーションのすべて、またはサブセットを実行できます。

MCS の技術上のガイドラインと考慮事項は、次のとおりです。

• CallManager ごとの最大 IP Phone数：2500

• クラスタごとの最大 CallManager 数：3

• フェールオーバーの制限：2 つの Cisco CallManager がサイトにある場合、フェールオーバーは約 90 秒であり、バックアップ Cisco CallManager 上に手作業でプログラミングを複製する必要があります。

• Cisco IP Phone 7960 の電源：2 つのソース、すなわちインライン パワー 10/100 BASE-T イーサネット スイッチング モジュール HYDRA、または外部変圧器のどちらかから得られます。

• IP Phoneのネットワーク接続：IP Phoneは、10 Mbps 交換、または 10/100 Mbps 交換のイーサネット接続のみに接続します。

• デイジーチェーン接続 PC 用の DHCP アドレッシング：DHCP がアドレッシングに使用される場合、IP Phoneに接続される PC またはワークステーションは、そのフォンと同じアドレス プール（サブネット）から、IP アドレスを取得します。

• デイジーチェーン接続 IP Phoneの音声品質の低下：PC またはワークステーションが IP Phoneに接続され、これらがネットワーク接続を共用する場合、両方のデバイスが、高いトラフィック負荷または IP Multicast アプリケーション（たとえば、IPTV）と一緒に同時に使用される場合、PC が原因で、音声品質が低下する可能性があります。しかし、実際には、通常の PC アプリケーションでこの低下を実現することは困難です。

• IP テレフォニー デバイス間のファイアウォールなし：IP Phone、ゲートウェイ、または CallManager コンポーネント間にファイアウォールまたは NAT は存在できません。

• ネットワークは、平均以上の使用状況に合わせて設定されなければならない：LAN/MAN ネットワークは、予想データ トラフィック帯域幅を処理し、受け入れ可能な音声 QoS を提供し、通常予想される過剰サブスクリプションに対処するように、適切に設計される必要があります。このガイドラインにより、LAN/MAN ハードウェアまたは Cisco IOS のアップグレードが指示される場合があります。

CallManager と MCS は、上記にリストされているガイドラインの制限を強制しない場合があります。しかし、コールの数が推奨数の限界を超えると、MCS を通過するコールの音声品質が徐々に低下します。したがって、サービス品質を確保するために、数値を推奨数の限界以下に保つことは有効な施策です。

Media Convergence Server と Catalyst スイッチのラックマウント要件は、次のとおりです。

• 2 つの正面マウント ストリップまたはレール間のラック幅は、45.09 cm（17.75 インチ）でなければならない。

• 正面と背面のマウント ストリップ間のラックの奥行きは、48.9 cm（19.25 インチ）以上、81.3 cm（32 インチ）以下でなければならない。

さまざまなシステムのシャーシを挿入するために、ラックには十分な垂直方向の空間が必要です。たとえば、6509 スイッチのシャーシの高さは 64.8 cm（25.5 インチ）であり、MCS-7835 の高さは 13 cm（5.1 インチ）です。

（注） ICS 7750 IP テレフォニー要件の分析については、付録 A を参照してください。

ソリューション実装テンプレート

プロジェクト エンジニアは、実装の前に、設計に基づいてソリューション実装テンプレートに記入する必要があります。ここでは、次のソリューション実装テンプレートを提示します。

• WAN 接続

• アドレス計画

• CallManager 設定

• ダイヤル プラン

WAN 接続テンプレート

次のテンプレートは、実装のために WAN 設定を準備するためのものです。

リモート サイト情報テンプレート

リモート サイト キャリア回線テンプレート

ルータのグローバル設定テンプレート

ルータのイーサネット設定テンプレート

ルータの ATM/FR 設定テンプレート

アドレス計画テンプレート

次のテンプレートは、アドレス計画を準備するためのものです。

コア サイトの IP アドレスと VLAN 割り当てテンプレート

リモート サイトの IP アドレス割り当てテンプレート

CallManager 設定テンプレート

次のテンプレートは、CallManager 設定を準備するためのものです。

CallManager 設定属性テンプレート

CallManager ポート テンプレート

CallManager グループ テンプレート

CallManager ロケーション テンプレート

CallManager デバイス プール テンプレート

CallManager パーティション テンプレート

CallManager ルート プラン テンプレート

CallManager ルート グループ テンプレート

CallManager ルート リスト テンプレート

CallManager ゲートウェイ テンプレート

CallManager ピックアップ グループ テンプレート

CallManager コール パーク範囲テンプレート

IP Phone テンプレート

IP Phone ボタン テンプレート

ダイヤル プラン テンプレート

次のテンプレートは、CallManager ダイヤル プラン設定のためのものです。

IP Phoneの内線番号範囲テンプレート

DID 番号割り当てテンプレート

カスタマー発注機器

シスコ提供の機器の部品番号と数量を提供することが重要です。これを行うには、 表 5-20 と 表 5-21 を使用するか、カスタマー注文明細から直接、情報を取得します。

顧客宅内機器（CPE）インターフェイス

表 5-22 を使用して、サイト固有のケーブル情報を文書化してください。

カスタマー サイトの準備度

サイト調査を実行した後、サイト準備度チェックにより、各カスタマー サイトの設置準備が整います。このカスタマー サイトの準備度は、サイト調査の結果のまとめです。

機器の開梱

カスタマーは、機器が設置ロケーションに配送されることを確認する責任があります。実装チームは、輸送中に梱包が損傷していないかどうかを確認します（外見上損傷がないかを調べる）。実装チームは、機器が梱包から取り出されるときに、良好な状態であるかどうかを確認します。シスコの担当者が、設置位置の近くで機器をアセンブルします。

キャビネットの電源供給、レール、およびアースの確認

カスタマーは、適切な電源装置を提供する責任があります。AC 電源装置の場合、ラックの設置位置の近くに、適切なソケットが必要です。DC 電源の場合、カスタマーは、適切な圧着コネクタを使用して、機器にケーブル配線する必要があります。適切な圧着ツールは、 http://rswww.com の RS Components から入手してください（製品コード 445-611）。シスコ代理店の担当者は、カスタマーの立ち会いの下で機器に接続し、電源が絶縁されていることを確認する責任があります。すべての電源線にはラベルを付ける必要があります。

カスタマーは、適切な圧着コネクタを使用して、絶縁されたアース ケーブルを機器に接続し、アース要件の詳細を文書化する責任があります。ラックと機器に接続するのは、シスコ代理店の担当者が行います。

実装チームは、カスタマーによるキャビネットの電源レール、給電、およびアースの取り付けを確認し、すべての装置が絶縁されていることを確認します。電源装置のケーブルにラベルを付けるのは、シスコ代理店の担当者が行います。

キャビネット内への機器の物理的インストール

シスコ代理店の担当者は、新しいネットワーク デバイス間のケーブルを含め、物理的にキャビネット内に機器を設置する方法を指定します。ラックまたは機器の配置と特定の実装方法を詳しく記述してあるサイト調査からの情報を組み込んでください。各機器に付属されている取り付け資料を参照し、特定のシスコ製品資料の Web アドレスを提示してください。特定の実装に関連したポイントを強調し、標準の取り付け資料が十分な情報を提供していない個所に詳細情報を組み込みます。

機器のシリアル番号の記録

シリアル番号は、実装中に機器のロケーションを追跡するのに必要です。シスコ代理店のプロジェクト管理者は、実装時にこのマニュアルに記録されるシリアル番号が、シスコ代理店のカスタマー サービス チームに伝えられることを確認する必要があります。シスコ代理店のカスタマー サービス チームは、サポートの目的に使用される記録が、必要に応じて更新されることを確認します。フィールド交換可能な品目のシリアル番号だけが記録されます。

機器スロット割り当ての確認

シスコ代理店の担当者は、シスコ機器内のカードの配置を指定します。これは、ルータ、スイッチ、およびゲートウェイに重要です。カードのスロット割り当てを記録するためのマトリックスとして、 表 5-23 を使用してください。

キャビネット内の電源ケーブルの取り付け

シスコ代理店の担当者は、キャビネットの電源レールと機器の電源取り込みモジュールとの間に、カスタマーが用意した電源ケーブルを取り付けます。シスコ代理店の担当者は、アース ケーブルをキャビネットのアース点に接続します。カスタマーは、用意したケーブルをキャビネット位置に提示する必要があります。シスコ代理店の担当者は、キーフォブ形式のホルダーを使用して、ケーブルをしっかり結び付け、ラベルを付けます。

キャビネット内およびキャビネット間の通信ケーブルの取り付け

シスコ代理店のエンジニアが取り付ける、キャビネット内電源ケーブルを確認します。シスコ代理店提供のイントラネット ケーブルは、注文に含まれています。カスタマーは、キャビネット間ケーブルを用意します。シスコ代理店の担当者は、同じラック内で使用される機器間に、用意されたすべてのケーブルを取り付けます。シスコ代理店の担当者は、キーフォブ形式のホルダーを使用して、ケーブルをしっかり結び付け、ラベルを付けます。

カスタマーのパッチパネル内の回線終端の確認

キャリア回線とケーブルまたはパッチをシスコ製キャビネットに提供する際に、カスタマーの責務を確認してください。カスタマーは、パッチパネルと IP テレフォニー機器間の回線の指定が正しいかどうかを確認します。カスタマーは、IP テレフォニー機器とパッチパネル間のすべてのケーブル配線が正しく、テスト済みであることを確認します。カスタマーは、すべての回線が正常にテスト済みであることを確認します。

シスコ機器の電源オン

シスコ代理店の担当者は、電源オン手順の詳細を説明します。サイト調査レポートを参照して、機器の電源オンの制限を確認してください。

シスコ代理店の担当者は、次のタスクを担当します。

• 機器のすべての電源装置でスイッチをオンにする（段階的に電源をオンにするためのローカル要件を参照）。

• すべての機器が電源オン サイクルを開始することを確認する。

• VT100 互換ラップトップがコンソール、またはそれに相当するポートに接続されている場合、すべての機器がユーザ プロンプトを出すことを確認する。

• 各デバイスに順にログインし、電源オン後に、未解決または不明のアラーム、または不明の機器障害がないことを確認する。

システム ソフトウェアとファームウェアの検証とロード

シスコ代理店の担当者は、ソフトウェアとファームウェアのリビジョン要件、およびアップグレードの際に、オンサイト エンジニアが実行する必要がある場合のアップグレード手順を提供します。シスコ代理店のエンジニアは、VT100 互換端末を使用して各 Cisco WAN デバイスに接続し、スイッチ ソフトウェア、ブート コード、およびファームウェアのバージョンを確認します。シスコ代理店の担当者は、各 Cisco ルータに接続し、Cisco IOS ソフトウェアのバージョンを確認します。シスコ代理店のエンジニアは、相違したバージョンを、指定のリリースに訂正します。

機器の設定

シスコ代理店のエンジニアは、ソリューション テンプレートに基づいて IP テレフォニー機器を設定します。これには、CallManager サーバ、ゲートウェイ、ルータ、スイッチ、およびその他の関連したデバイスの設定と共に、次のものが含まれます。

• コール アドミッション制御

• CallManager クラスタ

• DSP リソース プロビジョニング（トランスコーディング）

• 音声メッセージング システム

ダイヤル プランの実装

シスコ代理店のエンジニアは、設計に基づいてダイヤル プランを実装します。

ダイヤル プラン アーキテクチャ

次のリストでは、ダイヤル プランの機能を指定します。

• ルート パターン： E.164 アドレス範囲または特定のアドレス ポイントと、単一ルート リストとの突き合わせ。CallManager ソフトウェアは、最も明確なワイルドカード パターンと範囲を、次のように組み合わせます。

• ルート リスト：宛先（私設ネットワークまたは PSTN）に到達する「ために」優先順位が付けられた、ルート グループのリスト

• ルート グループ：特定の宛先（私設ネットワークまたは PSTN）に到達するために、デバイスおよびゲートウェイのリストから構成される、優先順位順のトランク グループ

• デバイス/ゲートウェイ：リモート私設ネットワークまたは PSTN とのインターフェイスを取るデバイスおよびゲートウェイ。デバイスには次のものがあります。

–H.323 ベースまたは MGCP ベースのルータ

–Skinny ベースの Catalyst スイッチ

–スタンドアロン Skinny デバイス（たとえば、DT24-T1 または E1）

ダイヤル プランの設定

ダイヤル プランの設定は、音声コールのルート指定方法、および特定の宛先に到達するためにコールが送信されるパスの数によって異なります。コールは、オンネット（つまり、サイト間またはサイト内コール）、およびオフネット（つまり、私設ネットワーク外で PSTN に送信されるコール）で、ルート指定できます。

コールは、CallManager で設定されるルート パターンを使用して、IP テレフォニー ネットワーク内および外でルート指定されます。次の小項目では、コールをルート指定するように CallManager を正常に設定するのに必要な、基本ステップを概説しています。

CallManager ルート パターンの設定

CallManager ルート パターンを設定する手順は、次のとおりです。

ステップ 1 CallManager にデバイスまたはゲートウェイを追加します。一般的なデバイス タイプは、Skinny ベース、MGCP ベース、または H.323 ベースです。

ステップ 2 CallManager でルート グループを作成し、コールをルート指定するために使用可能なデバイスをCallManager に追加します。

ステップ 3 ルート リストを作成して、コールのルート指定に優先順位を付けます。

ステップ 4 ルート パターンを作成または追加して、E.164 アドレス範囲、または特定のアドレス ポイントを、1 つのルート リストと一致させます。

ダイヤル プラン グループとコール制限の設定

ダイヤル プラン グループおよびコール制限を設定すると、同じコール制限と同じダイヤル プランを持つ、同じ CallManager 上の対象のコミュニティに、ユーザをグループ分けすることができます。さまざまなコミュニティが、同じゲートウェイを共用し、重複したダイヤル プランを持つことができます。これらの機能は、コール パーティションとコール探索スペースを使用して、CallManager 3.0 で実現されます。

• コール パーティション：ほぼ同じ到達可能性の特性を持つデバイスのグループ。IP Phoneなどのデバイス、ディレクトリ番号（DN）、およびルート パターン。

• コール探索スペース：ユーザまたは電話加入者が、コールの発信を許可される前に調べる、優先順位順のパーティションのリスト。コール探索スペースは、コールを開始するデバイスに割り当てられます。これらのデバイスには、IP Phone、IP SoftPhone、およびゲートウェイが含まれます。

コール パーティションとコール探索スペースの設定方法の詳細については、『Cisco CallManager アドミニストレーション ガイド』を参照してください。この資料は、次のロケーションにあります。 http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/admin_gd/

数字変換テーブルの設定

数字変換テーブルは、ダイヤルされた番号を別の番号に変換したり、宛先への転送前に桁数を変更します。これは、着信か発信かにかかわらず、PSTN への内部コールと外部コールに対して行われます。この変換テーブルは、ユーザが電話番号（たとえば、オペレータ用の「0」）をダイヤルするときに、コールが、ユーザ ディレクトリ番号に対応するディレクトリ番号に変換されるように設定できます。

変換パターンのワイルドカードや変換の使用方法は、ルート パターンとほぼ同じです。変換パターンは、内線番号のマッピングとして主に使用されています。

数字変換の詳細については、『CallManager アドミニストレーション ガイド』を参照してください。この資料は、次のロケーションにあります。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/admin_gd/

E-911 の設定

システム構築者は、システムが緊急コールを処理する方法について、明示的な専用ルーティング プランを提供する必要があります。ユーザが 911 または 9911 をダイヤルする場合、このコールの取り扱い方法は、システムに着信するいかなる他のコールとも異なります。

IP テレフォニー システムの一般的な役目は、次のとおりです。

• 適切なポイントに（オンネットまたはオフネットで）コールをルート指定する。

• 一般に発信者の電話番号（内線番号、PSTN 番号、またはこの 2 つの組み合せ）の形式で、発信者 ID を送信する。

IP テレフォニー VoIP 音声ソリューションは、次の必須機能をもたらすように設定できます。

• オンネットとオフネットのコール ルーティングの割り当て：オンネット ルーティングは、CallManager が行います。

オフネット選択的ルーティングは、常に、コールの開始時に E-911 ルータに提示される E.164 番号を使用します。IP テレフォニー ソリューションは、適切な public safety answering point（PSAP）にコールをルート指定するための番号を、公衆ネットワークに提示する必要があります。

• PSAP へのコールバック番号情報の転送：PSAP に提示されるコールバック番号は、IP Phoneの E.164 自動番号識別（ANI）です。

DID と非 DID の内線番号に使用可能な 911 サービスのレベルには、明確な違いがあります（つまり、電話機が、IP テレフォニー システムの外部から直接到達可能であるかどうか）。

• PSAP へのロケーション ID の転送。

この機能は、automatic location identification（ALI; 自動ロケーション識別）データベース内に関連した有効なエントリがある、有効な ANI を PSAP が受信すると、PSAP で使用可能になります。

IP テレフォニー アーキテクチャは、次の 4 つの一般的な配置モデルのいずれかに従って設計できます。

• 個別のキャンパス配置

• 分離されたマルチサイト配置

• 分散型コール処理を使用するマルチサイト IP WAN 配置（各サイトに Cisco CallManager がある）

• 集中型コール処理を使用するマルチサイト IP WAN 配置（中央サイトに 1 つのCisco CallManager がある）

上記にリストされている 4 つの配置モデルには、911 コールを処理するための設定方法に多くの類似点があります。したがって、この項では、一般的な方法を調べ、4 つのモデルのそれぞれの詳細と注意事項を項目に分けて記述します。

この項では、ライフラインのコール処理機能の実装を説明します。この実装によって、ユーザが 911（または 9911）ストリングをダイヤルすると、ゲートウェイを通じて PSTN にオフネットでルート指定されます。次に、PSTN は、E-911 ネットワークを通じてそのコールを公的な保安機関に切り換えるか、ルート指定します。このタイプの実装は、北米市場に固有のものです。

この機能はすべて、適切なルート パターン（911、または 5111 などその他のセキュリティ番号）を使用して、オンネット宛先（たとえば、キャンパス セキュリティ）に緊急コールをルート指定するのに使用できます。また、緊急コールをオンネットでルート指定するか、オフネットでルート指定するかは、ブランチ オフィスごとに独立して決定できます。

911 コールの処理は、次のコンポーネントに分類できます。

• ダイヤル プラン

• ゲートウェイの選択

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

ダイヤル プラン

ダイヤルされる 911 ストリングは、North American Numbering Plan を意味する「 @ 」ワイルドカードを使用して識別できます。911 コール以外のすべてのコールをフィルタに掛けて除去するには、「911」のラベルが付いた特別なサービスを使用できます。

次のパターンは、911 または 9911 のユーザ ダイヤルを処理します。 @ ワイルドカードは、North American Numbering Plan を記述するパターン（E.164 番号）を表します。「WHERE」ステートメントは、ルート フィルタ基準の前にあります。最初の 2 つのパターンの組み合せは、最後の 2 つのパターンの組み合せと等しく、ユーザが 911 をダイヤルする 2 通りの方法を示します。

ゲートウェイの選択

North American E-911 システムは、別個の地域ネットワークの集合です。これらのネットワークは、通常、管轄区域間のコールの再ルーティングを許可するための接続が行われないので、911 コールは、該当する PSAP の地理的な管轄区域内の E-911 ネットワークに入る必要があります。

WAN 配置をサポートするために、システムの設定時に評価する地理的な考慮事項があります。図 5-1 では、ブランチ X のユーザが、同じ地理ロケーションに置かれているゲートウェイ（ゲートウェイ X）を通じて、コミュニティ内の E-911 ネットワークに接続される様子を示しています。ブランチ Y のユーザは、ゲートウェイ Y を使用する必要があります。

図 5-1 ゲートウェイの選択

911 コールの場合、E-911 ネットワークはローカル側でしか有効でないので、ユーザは、地理に従って特定のゲートウェイに関連付けられなければなりません。図 5-1 では、「PSTN - E-911 地域」のラベルが付けられているクラウドは、E-911 について PSTN の地域特性を表しています。たとえば、911 コールを、ゲートウェイ X を使用して Y 警察に送信することはできません。

また、アクセス権を持つユーザの地理的なロケーション（E-911 管轄区域）に合わせて調整されるパーティションに、ルート パターンを関連付けることも大切です。

パーティションとコール探索スペースの定義

図 5-2 から始まる次の例は、Users_X_911 パーティションを、Branch X のユーザの 911 コール処理専用にする方法を指定します。

図 5-2 パーティション設定ウィンドウ

図 5-3 では、このパーティションが、Branch X のユーザ用のコール探索スペースに組み込まれる方法を示しています。

図 5-3 コール探索スペース設定ウィンドウ

ルート パターン

ルート パターンは、Users_X_911 パーティションに属するものとして定義する必要があります（図 5-4 を参照）。

図 5-4 ルート パターン設定ウィンドウ

Gateway/Route List フィールドの値は、Branch X の E-911 ネットワークにアクセスするゲートウェイを表す必要があります。上記の例では、Branch X のゲートウェイは、X 警察に到達する PSTN スイッチに接続されるので、Gateway_X 値が選択されました。これは、Branch X からの 911 コールが送信される先の、受け入れ可能なポイントです。同じタイプの設定が、Branch Y にも設定できます。

（注） 特定のクラスタに対して、ルート パターンとパーティションの組み合せはすべて、固有です。図 5-4 の例では、911 コールに 1 つのインスタンスが存在し、9.911 コールに 1 つのインスタンスが存在します。一部の設定では、ルート パターンの 2 つのインスタンスが存在する場合がありますが、これらのインスタンスは別々のパーティションにあります。たとえば、パーティション X には 9.911 ルート パターンのエントリが存在し、パーティション Y には 9.911 ルート パターンのルート パターンが存在する場合があります。

図 5-5 では、911 コールの 2 つのインスタンスの CallManager 決定フローを強調して示しています。つまり、Branch X のユーザが 911 をダイヤルし、Branch Y のユーザが 9911 をダイヤルしています。

図 5-5 CallManager 決定フロー

ゲートウェイ選択プロセスは、所定のIP Phoneがアクセスするパーティションの機能です。パーティションは、IP Phoneに割り当てられるコール探索スペースによって制御されます。次に、最近接一致ルーティング プロセスが、ルート パターンを選択し、そのルート パターンが（直接またはルート リストを介して）ゲートウェイを指します。

ルート フィルタ

生成されるルート フィルタは、ルート パターンを使用するルート リストを介して、アクセスを許可または制限します。ルート パターンが @ ワイルドカードに基づく場合、ルート フィルタが必要です。@ ワイルドカードは、North American Numbering Plan を構成するパターンの集合を表します。

図 5-6 では、SERVICE= 911 の場合を除いて、 @ によって表されるすべてのパターンの組み合わせを排除するように設定されるルート フィルタを示しています。9.@ および @ ルート パターンに同じルート フィルタを適用できます。

図 5-6 ルート フィルタ設定ウィンドウ

発信側変換マスク

E-911 機能全体は、E-911 ネットワークに提示される有効な完全修飾 E.164 番号（ANI）を持つ発信側に依存します。ANI に基づいて、911 コールは、次のことを許可するように拡張できます。

• 適切な PSAP にルート指定する

• 公的な安全機関がユーザへのコールバックに使用する、ダイヤル可能な番号の送達

• 無言の通話者の位置を正確に示すのに使用される、ロケーション情報の自動検索

911 機能の場合、DID フォンと非 DID フォンとの間には根本的な違いがあります。これらの違いは、Cisco CallManager や IP テレフォニー アーキテクチャに固有のものではありません。

DID フォン

IP Phoneに DID 番号が割り当てられる場合、E-911 ネットワークによって ANI として使用される Calling Party Number（CPN; 発信者番号）として、その番号を転送するのが最善の方法です。この場合、発信者の内部省略ダイヤル番号を、完全修飾 E.164 番号に変換するために、発信側変換マスクを使用する必要があります。たとえば、番号にエリア コード、オフィス コード、および 4 桁の番号が含まれる場合、内線 2003 は、408.555.2003 に変換されます。

CallManager ソフトウェアは、発信者番号が変換される 2 つの主なロケーション（デバイス レベルとルート パターン レベル）を提供します。

ルート パターン レベルは、内部コールが、着信側の IP Phoneまたはゲートウェイに提示される方法に変更を課すことなく、CPN が E-911 ネットワークに進むときに、CPN を変換するのに使用できます。つまり、内線番号 2003 が内線番号 2004 をコールする場合、着信側は、2003 番からの着信コールと認識します。内線番号 2003 が 911 をダイヤルする場合、ゲートウェイを通じて地域の電話会社（LEC）に渡される CPN は、変換され、着信側に 408.555.2003（例）の ANI を提示します。

非 DID フォン

IP Phoneに DID 番号が割り当てられない場合、複数の選択肢があります。

• CPN なしに、ゲートウェイを通じてコールを送る。これにより、E-911 ネットワークの拡張機能は使用できなくなり、一部の地域では違法になります。これにより、E-911 ネットワークは、デフォルトで、リストされているディレクトリ番号（LDN）、または PSTN 入力点のトランク グループのどちらかに基づいて、コールをルート指定します。これは、最も望ましくないオプションです。

• 固定 CPN を使用してコールを送る。この固定 CPN は、キャンパスの保安部門の CPN、発信側ロケーションの近くの DID フォン、またはトランク グループの LDN（たとえば、PSTN トランクのメイン番号）である場合があります。この固定番号を使用するのが最善であるのは、ローカル LEC の E-911 選択ルーティングと ANI/ALI データベースにエントリがある場合です。このオプションは、少なくとも、なんらかの管理者制御要素に従って 911 コールのルーティングを許可するので、より望ましいオプションです。また、コールの一般的な起点を知っている方が、何も知らないより便利です。

• サードパーティ製の発信者番号識別 - 自動番号識別（CLID-ANI）変換ボックスを使用する。これは、一部の地域で必要な場合があります。

非 DID フォンの使用により課せられる E-911 機能の制限は、IP ベースまたは非 IP ベースのすべてのエンタープライズ テレフォニー システムに適用されます。

代替番号へのルーティング オーバーフロー

優先 911 ゲートウェイが使用できない場合、代替方法は、通常の PSTN ゲートウェイを介してコールを再ルート指定し、着信側番号を完全修飾 E.164 番号に変換することです。たとえば、San Francisco にある優先ゲートウェイが使用不能である場合は、コールを Oakland のゲートウェイにオーバーフローさせ、PSTN 上でダイヤルされる着信側番号として（415）553-8090 を使用することが可能です。この番号は、San Francisco の市と郡の公開 7 桁緊急番号です。明らかに、この方式を使用してルート指定されるコールは、911 コールの利点を利用しませんが、コールを完全にブロックするより望ましいオプションです。

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

IP テレフォニー システムに使用可能な 911 機能のレベルは、内部設定だけでなく、コールを LEC に送るのに使用されるインターフェイスのタイプによっても異なります。

PRI インターフェイス

現在の IP テレフォニー ゲートウェイ ポートフォリオでは、PRI インターフェイスは、動的な 911 インターフェイス（たとえば、コールごとに別々の CPN を提示できるインターフェイス）に固有の唯一の選択肢を提供します。この方法により、CallManager は、PRI ベアラ チャネルの 1 つで 911 をダイヤルし、発信者電話番号を CPN ID として提示できます。これは、CallManager に、PSTN に送信する完全修飾 E.164 番号があることを前提としています。 発信側変換マスク を参照してください。

一部の LEC は、コール セットアップ時に提示される CPN を ANI として使用することを許可しません。代わりに、トランクの LDN を使用します。これは、LEC の Class 5 スイッチの技術上の制限よりも、LEC ポリシーの問題のように見えます。

POTS インターフェイス

最も単純で、最も広くサポートされている PSTN インターフェイスに、アナログ電話（POTS）回線があります。任意の POTS 回線は、Class 5 スイッチを処理する用意ができています。POTS 回線は、独自の E.164 電話番号、emergency service number（ESN; 緊急サービス番号）割り当て、および ALI データベース エントリを持つ E-911 タンデムに接続されます。既存の E-911 インフラストラクチャは、POTS 回線からの 911 コールを非常によくサポートします。これは、E-911 が設計されたオリジナル テクノロジーです。E-911 のワイヤレスおよびエンタープライズ テレフォニー サポート関連の現在の取り組みの大部分は、こうした新しいテクノロジーの機能を、POTS 911 機能と等しくすることです。

たとえば、次のとおりです。

• foreign exchange office 音声インタフェース カード（FXO VIC）は、IP テレフォニー ソリューションによってすでにサポートされている。

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

• POTS 回線インターフェイスに関連した資本コストは、システムのその他の構成で、すでに FXO 対応シャーシが必要である場合は、低くなる場合がある。1 つの POTS 回線にシャーシ全体が必要な場合、この方法はコストが高くなることが分かっています。

• POTS 回線に関連した OPEX（稼働費用）コストが低い。

• POTS 回線は、電源障害の場合のバックアップ回線の役目をすることができる。

• POTS 回線の番号は、ALI データベースに取り込まれるコールバック番号として使用できる。

• ユーザ密度が PSTN へのローカル PRI アクセスを正当化しないロケーションに対して、POTS 回線は、最低コストの 911 サポートを表す。

• POTS 回線は、どこにでもある PSTN インストレーションである。

• 国際ライフライン方式は、この方法によってサポートされる。

もちろん、この方法は、DID フォンと非 DID フォンを区別しません。すべての発信 911 コールは、E-911 ネットワークによって同じものとして扱われ、発信側変換マスクは関係ありません。

Centralized Automated Message Accounting インターフェイス

エンタープライズ テレフォニー システムが E-911 ネットワークとのインターフェイスを直接取ることを要求する、法的な努力が続けられています。すべての 911 ネットワークは、アナログまたはデジタル（CAS over T1）のどちらかの形式で、Centralized Automated Message Accounting（CAMA）トランクを使用します。次の 2 つの可能性があります。

• CLID-CAMA コンバータ：シスコには、固有の CAMA ソリューションはありません。IP テレフォニー ソリューションを直接、E-911 ネットワークに接続する必要がある場合、サードパーティ ソリューションを使用する必要があります。

• CAMA VIC：IP テレフォニー ソリューションに CAMA 機能を追加する内部プロジェクトが進行中です。

すべての IP テレフォニー配置モデルに対する重要な E-911 考慮事項

この項では、すべての配置モデルの E-911 機能を実装する場合に考慮すべき、重要な情報を記述しています。

ユーザ モビリティ

ユーザ モビリティは、IP ベースのテレフォニー ソリューションの主な利点の 1 つです。ユーザ モビリティは、再配置が組織、地理、またはテクノロジーの境界を超えるものであっても、物理的なデバイスをフォローする、物理的な電話機および電話番号の自動再配置を可能にします。ユーザは、職場の電話番号を持ち、デジタル加入者線を通じて自宅からテレコミュートすることができます。他のユーザからは、「オフィス」にいるものと見なされます。自宅から 911 をダイヤルすると、事実上、そのユーザは、数百マイル離れている可能性がある PSAP に接続されてしまいます。

このマニュアルで説明されている現在の E-911 機能は、完全な手動管理プロセスを使用します。IP Phoneが特定のコール探索スペースを指すものとして設定された後、ユーザが別の物理ロケーションに移動してもその設定が維持されるので、ユーザ モビリティは問題を提起しています。IP テレフォニー ソリューション内の E-911 機能は、現在、ユーザのモビリティに適応しません。

ユーザ データ管理

Public Safety Automatic Location Identification データベースにおけるユーザ名、ロケーション、番号情報の維持は、完全な手動プロセスです。このモデルは明らかにスケーラブルではありません。小規模な IP テレフォニー配置であっても、Add/Drop/Moves の追跡に手間がかかります。

Always-on

緊急テレフォニー デバイスの最も重要な属性の 1 つは、商用電源の喪失を克服する機能です。一般的な LEC POTS 回線は、電力停止でも機能を失うことなく存続できます。これには、IP Phoneのインライン パワーと UPS または一般のインフラストラクチャのバックアップ、ゲートウェイ、およびコール処理機器を使用して遂行されます。

また、システム内で複数の LEC ループスタート回線を設定することもできます。これにより、電力停止時の「外界」との汎用通信が可能になり、いつでも FAX とモデムの交換アクセスを提供するのに使用できます。回線を、緊急用の専用 POTS 電話機に接続することもできます。

この方法を使用する場合、この回線の E.164 番号は、非 DID フォンから発信される 911 コールの CPN として使用できます。詳細については、 非 DID フォン を参照してください。

ローカル コール処理の復元力

リモート サイトが CallManager から切り離されると、IP Phoneは使用不能になります。この状況に対処するためのプロジェクトが、現在進行中です。

TDD 機能

TDD（Telecommunications Device for the Deaf）は、通常の電話回線を通じて、文字ベースの会話を交換するのに使用される、モデム ベースの通信デバイスです。米国障害者法の下で、911 コミュニティは、通常の電話コールと同じレベルのサービスを使用して TDD コールを取り扱う必要があります。2000 年 12 月の時点で、Cisco VoIP システムは、TDD デバイスを処理するためのテストが行われました。

TDD マシンは、次の 2 つの変調方式のどちらかを使用します。

• ボー（大多数用）：米国障害者法（ADA）に準拠するために正式に規定された唯一のテクノロジー

• ASCII（周波数変位方式（FSK）の誤称、キャリア ベースの変調）：めったに使用されない

次の 2 つのタイプの TDD マシンが使用可能です。

• 専用：モジュラ コネクタを通じて回線に直接接続される

• 音響結合：TDD マシンに対して電話機の受話器を使用する

どちらの方式の場合も、G.711 の方が結果が優れています。通信を行うには、Voice activity detection（VAD）をオフにする必要があります。

聴覚障害者用の通信の詳細については、次のロケーションを参照してください。 http://www.zak.co.il/deaf-info/old/tty_faq.html

LEC インターフェイス

現在開発中の必須 LEC テレフォニー インターフェイスについては、 Centralized Automated Message Accounting インターフェイス を参照してください。

911 コール通知とアカウンティング

ユーザが 911 をコールしていることを知らせるための通知システムを設置することは、多くのキャンパス インストレーションの要件です。たとえば、キャンパスの保安部門が 911 コールをモニタし、発信者の内線番号が提示される教育機関の場合です。実際に音声の会話をモニタし、「割り込む」方法が必要な場合があります。IP テレフォニー アーキテクチャは、現在、これらの機能を実行する固有の方法を備えていません。

911 コールの報告専用のコール詳細レコード（CDR）も、多くの場合、カスタマー要件で指定されます。IP テレフォニーの観点から見ると、他のタイプのコールと比べて、911 コールに特殊な調整はありません。着信側番号に基づくレコードの解析を可能にする CDR パッケージが、サードパーティによって開発される場合がありますが、すぐには使用できません。

単一サイト配置モデルの重要な E-911 考慮事項

この項には、すべての単一サイト配置モデルの E-911 機能を実装する場合に考慮すべき、重要な情報を記述しています。

個別のキャンパス配置

小規模な配置を設定する場合、ユーザは単一の建物内に集中するので、非常に簡単です。すべてのユーザは、911 コールに同じゲートウェイ アソシエーションを共用できます。非常に小規模な実装の場合、LEC POTS 回線が、911 コール要件を満たすのに必要な唯一のインターフェイス タイプである場合があります。

分離されたマルチサイト配置の場合、各サイトは、別個のエンティティであり、911 コールの処理用に個別に設定する必要があります。

マルチサイト配置モデル

マルチサイト IP WAN 配置（分散型または集中型コール処理を使用する）は、分散型コール処理、集中型コール処理の双方に関して適切に IP Phoneをゲートウェイに関連付けるという同じ課題を共有しています。この関連付けは、IP Phoneの実際の地理的なロケーション、およびゲートウェイがアクセスする E-911 ドメインに基づく必要があります。

マルチサイト配置は、前述のいくつかの項で説明されている機能を使用できます。システム設計者は、E-911 ネットワークの管轄境界を認識し、IP Phoneが物理的に設置されているすべてのロケーションに E-911 ネットワーク入力点が提供されるように、システムを設定する必要があります。つまり、1 台の IP Phoneが置かれている場所であればどこでも、E-911 機能を提供するために適切なローカル ゲートウェイが提供されなければなりません。着信側番号変換が使用できる場合（たとえば、もともと「911」とダイヤルされたコールを、対応する 7 桁の緊急番号がダイヤルされた場合と同じように、ルート指定することが可能な場合）、別の方法も検討できます。しかし、このプロセスは、E-911 の拡張機能をすべて提供するわけではないので、合法と見なされない場合があります。

インストレーション テストの実行

シスコ代理店の担当者は、実行するインストレーション テストの表を提供します。各テストには、カスタマーが立ち会う必要があります。個々のテスト シートに記入する必要があります。個々のテスト シートは、「ソリューション実装受け入れテスト」にあります。また、System Handover Certificate に障害を記入する必要もあります。

カスタマー ネットワークへの機器の追加

シスコ代理店の担当者は、機器をカスタマー ネットワークに追加する方法について、明確な説明を行います。カスタマーによる変更制御プロセスへの参照が必要な場合があります。

ソリューション受け入れテストの実行

実行する稼動テストの表を提供してください。各テストには、カスタマーが立ち会う必要があります。個々のテスト シートに記入する必要があります。このテストは、 「ソリューション実装受け入れテスト」 にあります。

フォールバック手順

ここでは、IP テレフォニー実装のフォールバック手順を説明します。

IP テレフォニーから TDM へのフォールバック

IP テレフォニー ソリューションから、カスタマーの以前の TDM（時分割多重）設定にフォールバックする手順は、次のとおりです。

ステップ 1 CallManager 3.0 サーバの電源をオフにします。

ステップ 2 TDM PBX スイッチを再始動します。

TDM 設定への今後の変更が必要ないように、元の設定値が保存されます。

ステップ 3 回帰テストを実行して、移行前の設定を確認します。

TDM ネットワークから Cisco IP テレフォニー ソリューションへの移行

TDM 音声ネットワーク環境から Cisco IP テレフォニー ソリューションにカスタマー サイトをアップグレードするには、移行前および移行中に、一連のアクションを計画し、実行する必要があります。シスコ代理店の担当者は、順調な移行を確保するために、次のステップに忠実に従う必要があります。

1. サイト要件をカスタマーに伝えます。

2. サイト調査を実行して、カスタマー サイトに関連した情報を収集します。

3. 詳細なカスタマー データ ネットワーク アーキテクチャ ダイアグラムを作成して、適切な Cisco IP テレフォニー ソリューション バックボーンの計画の開始点として使用します。

4. カスタマー サイトに固有の詳細な設計と技術プランを文書化し、これらのプランをカスタマーに伝えます。

5. カスタマーからのフィードバックを使用して、完全な配置プランを完成させ、実行します。

カスタマーによるソリューションの確認と受け入れ計画について別の文書を、契約の一部としてカスタマーに提示することができます。シスコ代理店の Professional Services および技術アシスタントは、Cisco IP テレフォニー ソリューションの配置に参加して、Cisco IP テレフォニー ソリューションが正常であること、十分なネットワーク パフォーマンス、およびネットワーク管理を保証します。

Cisco CallManager のアップグレード

アップグレード方法の詳細については、次の資料を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/install/305upgra.htm

移行段階

カスタマーのデータ ネットワークの規模、複数ロケーション、および複雑度に応じて、段階的な移行が必要な場合があります。この場合、シスコ代理店の担当者は、種々の移行段階についてのガイドラインを計画する必要があります。これらのガイドラインは、カスタマーと相談して取り決める必要があります。移行の段階数および各段階の範囲をカスタマーと合意した後、移行を開始する前に、各段階の手順、エントリ基準、および終了基準を含む詳細な計画を文書化し、移行の進行中に更新する必要があります。

検証プロセス

IP テレフォニー ソリューションが実装された後、稼働のためにカスタマーに引き渡される前に、SIA テスト を実行して、実装の正確さと完全性を確認する必要があります。 表 5-24 では、IP テレフォニー ソリューションを検証するために設計された SIA をリストしています。

SIA テストは、MCS と ICS 7750 プラットフォームでほぼ同じです。しかし、CallManager 点検テストを続行する前に、ICS 7750 には追加のステップが必要です。

（注） Solution Implementation Acceptance テストは、次のロケーションで入手可能です。
http://www.cisco.com/warp/public/788/solution_guide/forms/index.html#iat

IP テレフォニー ソリューションに ICS 7750 システムが組み込まれている場合、900 シリーズのテストから、実装受け入れテストを開始してください。これらのテストでは、System Manager が正しく設定されていること、およびシステムが CallManager 用に作動可能になっていることを確認します。

受け入れ基準

ネットワークが、ライブ カスタマー トラフィックの伝送、およびシスコ代理店によるサポート（適切な保守契約があることが前提）に適切であると見なされる場合、ソリューション実装受け入れテストの結果が、正常に完了したと判断されます。たとえば、このテスト手順の結果、ソフトウェアまたはハードウェアの不良が見つかり、この不良がネットワークの作動にあまり大きな影響を与えない場合、Professional Services 契約の完了後、この不良の調査と訂正が、シスコ サポート プロセスで引き続き管理されます。Cisco Professional Services は、契約終了プロセスの一環として、未解決の技術的な問題の推移を管理します。

資産タグとケーブルのラベル付け

資産タグとケーブルのラベル付けのサービスは、オプションですが、稼働の管理とトラブルシューティングには非常に重要です。このサービスには、次の利点があります。

• カスタマーが、新しい機器の到着を都合良く管理し、既存のデータベースに情報を入力できるようになる

• 継続的なネットワーク機器追跡を改善する

• 全体的なインストレーション コストとオンサイト時間を短縮する

Customer Acceptance Certification

カスタマーは、Customer Acceptance Certification に記入し、署名して、シスコ代理店のプロジェクト管理者に戻します。Customer Acceptance Certificate の例は次のとおりです。