Cisco テクニカル ソリューション シリーズ:IP テレフォニー ソリューション ガイド
IP テレフォニー ネットワークの実装
IP テレフォニー ネットワークの実装
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

IP テレフォニー ネットワークの実装

この章の構成

関連情報

実装の準備

一般的なサイト情報

チームの情報

プロジェクト管理

実装の考慮事項

サイト調査の実行

サイト調査表

サイト情報の収集

サイト要件の判別

LAN 要件

WAN 要件

WAN ハードウェア要件

WAN 帯域幅要件

QoS の要件

ゲートウェイの要件

IP テレフォニーの要件

電源と環境の要件

実装準備度の確認

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

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

音声ネットワーク分析

データ ネットワーク分析

LAN 要件の分析

WAN 要件の分析

WAN 帯域幅要件の分析

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

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

WAN 接続テンプレート

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

CallManager 設定テンプレート

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

カスタマー発注機器

顧客宅内機器(CPE)インターフェイス

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

ソリューションの実装

機器の開梱

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

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

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

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

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

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

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

シスコ機器の電源オン

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

機器の設定

ダイヤル プランの実装

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

ダイヤル プランの設定

E-911 の設定

ダイヤル プラン

ゲートウェイの選択

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

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

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

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

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

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

フォールバック手順

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

移行方法の実装

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

Cisco CallManager のアップグレード

移行段階

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

検証プロセス

受け入れ基準

実装後の文書作成

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

Customer Acceptance Certification

実装レポートの作成

ケース スタディ

IP テレフォニー ネットワークの実装

この章の構成

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

実装の準備

サイト調査の実行

サイト要件の判別

実装準備度の確認

ソリューションの実装

移行方法の実装

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

実装後の文書作成

ケース スタディ

関連情報

この章に密接に関連した情報については、次のサイトを参照してください。

Cisco Traffic Engineering Technical Tip

http://www.cisco.com/warp/public/788/pkt-voice-general/9.html

Westbay Engineers Limited のホーム ページ

http://www.erlang.com/

Cisco White Paper: Designing High-Performance Campus Intranets with Multilayer Switching

http://www.cisco.com/warp/public/cc/so/cuso/epso/entdes/highd_wp.htm

Cisco IP テレフォニー ネットワーク デザイン ガイド

http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/citndg/index.html

CallManager 3.0(1) Troubleshooting Guide

http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec1.htm

E-911 Fact Sheets

http://www.fcc.gov/e911

National Emergency Number Association の Web サイト

http://www.nena9-1-1.org/

実装の準備

実装の方法はカスタマーごとに固有であるので、各実装の適切な準備を行うと、各配置の成功につながります。

一般的なサイト情報

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

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

 

表 5-1 一般的なサイト情報

出荷と受領

特定の配送先住所、配送時間、および配送方法を指定してください。

番地:

都道府県と市町村名:

郵便番号と国名:

特別な指示:

このロケーションの発送と荷受け部門の営業時間を指定してください。

Cisco IP テレフォニー機器、通信機器、およびケーブルを設置する前に、サイト上で保管する安全な保険付きの場所を指定してください。

このロケーションには、乗り入れデッキがありますか。ある/ない

このロケーションは、パレット ジャッキがありますか。ある/ない

IP テレフォニー機器のすべての設置場所までにエレベータがありますか。ある/ない

荷受け部門と貨物用エレベータは、営業時間後や週末に利用できますか。できる/できない

機器キャビネット(おおよその最大サイズ 7 ft. x 2 ft. x 3 ft.)が必要である場合、狭い階段、エレベータ、出入り口、および機器用の傾斜路がないなどの障害物がありますか。ある場合は、詳しく記述してください。

建物/サイトのアクセス

IP テレフォニー機器が設置される建物の住所と部屋番号を指定してください。

番地:

部屋番号:

都道府県と市町村名:

郵便番号と国名:

通常の営業日と営業時間を指定してください。

通常の営業時間中に建物にアクセスする特別な手順を指定してください。

営業時間後に建物にアクセスする特別な手順を指定してください。

遵守しなければならない必要なセキュリティ手順とポリシーを指定してください。

Cisco IP テレフォニー機器用の部屋へアクセスするための特別な手順(鍵、バッジ、または護衛など)を指定してください。

Cisco IP テレフォニー機器用の部屋にアクセスするのに必要な、部屋および建物への許可証、バッジ、および護衛(必要な場合)をリストしてください。

部屋や建物への許可証、バッジ、または護衛を手配する担当者はだれですか。この担当者にはどのようにして連絡できますか。

担当者名:

電話番号:

ポケットベル:

電子メール アドレス:

指示事項:

サイトの準備

サイトの準備を担当するサイト責任者はだれですか。この人物にはどのようにして連絡できますか。

責任者名:

電話番号:

ポケットベル:

電子メール アドレス:

必要に応じて設置機器に使用できる、Cisco IP テレフォニー機器に最も近い電話番号をリストしてください。

CallManager #1:

CallManager #2:

CallManager #3:

CallManager #4:

CallManager #5:

Catalyst スイッチ #1:

Catalyst スイッチ #2:

ゲートウェイ #1:

ゲートウェイ #2:

ゲートウェイ #3:

組合労働者が、Cisco IP テレフォニー機器の設置、保守、またはサポートを行う必要がありますか。
ある/ない

作業を実行する特別な日付、時間、およびロケーションを指定してください(四半期末、営業時間外、週末)。

Cisco IP テレフォニーの設置前に、設置場所から移動させる必要がある機器がありますか。
ある/ない

ある場合は、この機器の移動の担当者と移動日を指定してください。

担当者名:

電話番号:

ポケットベル:

電子メール アドレス:

移動日:

設置作業員は、機器の梱包材をどこに廃棄できますか。

機器のすべての設置場所に、作動可能で室温調整された空調設備がありますか。ある/ない

チームの情報

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

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

 

表 5-2 実装チームの連絡先情報

シスコシステムズまたはシスコ代理店の
プロジェクト チームのメンバー
カスタマーのプロジェクト チームのメンバー

プロジェクト管理者:

電話番号:

電子メール アドレス:

プロジェクト所有者:

電話番号:

電子メール アドレス:

プロジェクト エンジニア:

電話番号:

電子メール アドレス:

プロジェクト管理者:

電話番号:

電子メール アドレス:

ソリューション設計エンジニア:

電話番号:

電子メール アドレス:

システム エンジニア:

電話番号:

電子メール アドレス:

アカウント管理者:

電話番号:

電子メール アドレス:

システム エンジニア:

電話番号:

電子メール アドレス:

プロジェクト管理

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

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

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

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

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

 

表 5-3 実装スケジュールの例

実装タスク
日数
開始予定日
完了予定日

実装の準備

5

サイトの調査

5

実装前のチェック

10

実装

10

受け入れテスト

2

実装後の文書作成

5

カスタマーによる受領

2

実装の考慮事項

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

前提事項

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

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

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

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

実装時に、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 では、正常なサイト調査用に記入する必要がある表をリストしています。

 

表 5-4 サイトの表

基本情報の表
参照情報の表
注文とは無関係の情報の表

アクセス

デバイス

注記

連絡先

機器の発注

IP アドレス範囲

機能

サイト間の回線とサイト間の仮想回線

文書化

手順

保守サポート

サービス組織

サイト

部屋

サイト グループ

ユーザ

サイト情報の収集

ここでは、サイト調査用に収集する情報を簡単に説明します。下記に記述されている各サイト調査表は、次のロケーションにあります。
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 テレフォニー ソリューションで保持する、既存のすべての機能をリストし、記述します。この情報は、初期調査とサイト調査時に収集する必要があります。

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

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

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

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

サイト要件の判別

ここでは、ネットワーク インフラストラクチャ、テレフォニー インフラストラクチャ、IP テレフォニー、電源、および環境の要件についての情報を記述します。

LAN 要件

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

 

表 5-5 LAN スイッチの要件

役割
必要な機能
参照プラットフォーム

キャンパス アクセス スイッチ

インライン パワー
複数キュー サポート
802.1p および 802.1q
高速リンク コンバージェンス

Catalyst 3500

Catalyst 4000

Catalyst 6000

キャンパス ディストリビューション/コア スイッチ

複数キュー サポート
802.1p および 802.1q
トラフィック分類
トラフィック再分類

Catalyst 6500

支社のスイッチ

インライン パワー
複数キュー サポート
802.1p および 802.1q

Catalyst 3500

Catalyst 4000

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

 

表 5-6 スイッチの機能

機能
Catalyst 3500
Catalyst 4000
Catalyst 6000/6500

信頼機能

あり

なし

あり

CoS の再分類

あり

あり

あり

ToS の再分類

なし

なし

あり

輻輳回避(WRED)

なし

なし

あり

優先キュー

なし

なし

あり

複数キュー

あり

なし

あり

輻輳管理(WRR)

なし

なし

あり

ポリシング

なし

なし

あり

インライン パワーを使用する 10/100MB スイッチ

24 ポート

WS-X4148-RJ45V(48 ポート モジュール)

WS-X6348-RJ45V(48 ポート モジュール)

アナログ トランク ゲートウェイ

WS-X4604-GWY 1

WS-X6624-FXS
(24 ポート モジュール/RJ21)

デジタル トランク ゲートウェイ

WS-X4604-GWY 1

WS-X6608-T1 または E1(8 ポート モジュール/RJ48)

1.Cisco IOS ベース。ルータ、音声ゲートウェイ、および DSP Farm として機能します。Cisco 2600/3600 との VIC/WIC インターフェイス、音声、および FAX サポートを共用します。

WAN 要件

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

WAN ハードウェア要件

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

 

表 5-7 WAN ハードウェア要件

役割
必要な機能
参照プラットフォーム

WAN 集約ルータ

複数キュー サポート
トラフィック シェーピング
LFI
リンク効率ツール
トラフィック分類
トラフィック再分類
802.1p および 802.1q

7200

7500

ブランチ ルータ

複数キュー サポート
LFI
リンク効率ツール
トラフィック分類
トラフィック再分類
802.1p および 802.1q

2600

3600

ICS 7750 MRP(将来、802.1p および 802.1q)802.1p または 802.1q は、まだサポートされていません。

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

専用回線

フレームリレー

ATM

ATM とフレームリレーのサービス インターワーキング(SIW)

WAN 帯域幅要件

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

 

表 5-8 WAN 帯域幅要件

帯域幅
最大トランク数
最大
ユーザ数
使用可能な帯域幅
音声
帯域幅
Skinny
帯域幅
予約済み
帯域幅
CallManager の帯域幅

64

1

6

48

22

3

23

24

128

3

12

96

66

6

24

72

192

5

19

144

110

9

25

120

256

7

25

192

154

12

26

168

320

9

32

240

198

16

26

216

384

10

38

288

220

19

49

240

448

12

44

336

264

22

50

288

512

14

51

384

308

25

51

336

576

16

57

432

352

28

52

384

640

18

64

480

396

32

52

432

704

19

70

528

418

35

75

456

768

21

76

576

462

38

76

504

832

23

83

624

506

41

77

552

896

25

89

672

550

44

78

600

960

27

96

720

594

48

78

648

1024

28

102

768

616

51

101

672

1088

30

108

816

660

54

102

720

1152

32

115

864

704

57

103

768

1216

34

121

912

748

60

104

816

1280

36

128

960

792

64

104

864

1344

37

134

1008

814

67

127

888

1408

39

140

1056

858

70

128

936

1472

41

147

1104

902

73

129

984

1536

43

153

1152

946

76

130

1032

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 を設計する場合に、注意が必要な最も重要な技法をいくつか説明しています。

 

表 5-9 機能とツールの要件

WAN テクノロジー
リンク速度
56kbps ~ 768kbps
リンク速度
> 768kbps

専用回線

LFI(マルチリンク PPP)
LLQ
cRTP

LLQ

フレームリレー

トラフィック シェーピング
LFI(FRF.12)
LLQ
cRTP

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

ATM

トラフィック シェーピング
TX-ring バッファ変更
LFI(マルチリンク PPP)
LLQ

トラフィック シェーピング
TX-ring バッファ変更
LLQ

フレームリレー/ATM SIW

トラフィック シェーピング
TX-ring バッファ変更
LFI(マルチリンク PPP)
LLQ

トラフィック シェーピング
TX-ring バッファ変更
LLQ

ゲートウェイの要件

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

 

表 5-10 ゲートウェイ プロトコル

ゲートウェイ
MGCP
H.323v2
Skinny Station Protocol
プラットフォーム

VG-200

あり

あり

なし

スタンドアロン

Cisco 1750

なし

あり

なし

IOS:ルータ

Cisco 3810 V3

あり

あり

なし

IOS:ルータ

Cisco 2600

あり

あり

なし

IOS:ルータ

Cisco 3600

あり

あり

なし

IOS:ルータ

Cisco 7200

なし

あり

なし

IOS:ルータ

Cisco 7500

なし

将来

なし

IOS:ルータ

Cisco 5300

なし

あり

なし

IOS:ルータ

Catalyst 4000 WS-X4604-GWY

将来

PSTN インターフェイスの場合、あり

会議と MTP トランスコーディングの場合、あり

スイッチ

Catalyst 6000 WS-X6608-T1 または E1

あり

なし

あり

スイッチ

ICS 7750 MRP

将来

あり

MTP トランスコーディングの場合、あり

IOS:ルータ

 

表 5-11 ゲートウェイ アナログ インターフェイス

ゲートウェイ
FXS
FXO
E&M
アナログ DID/CLID

VG-200

あり

あり

あり

あり

Cisco 1750

あり

あり

あり

将来

Cisco 3810 V3

あり

あり

あり

あり

Cisco 2600

あり

あり

あり

あり

Cisco 3600

あり

あり

あり

あり

Cisco 7200

なし

なし

なし

Cisco 7500

なし

なし

なし

Cisco 5300

なし

なし

なし

Catalyst 4000 WS-X4604-GWY

あり

あり

あり

あり

Catalyst 6000 WS-X6608-x1

あり

なし

なし

なし/あり

ICS 7750 MRP/ASI

あり

あり

あり

あり/将来

 

表 5-12 ゲートウェイ デジタル インターフェイス

ゲートウェイ
T1 CAS
E1/R2
E1 CAS
ユーザ側 PRI
ネットワーク側 PRI
ユーザ側 BRI
ネットワーク側 BRI
デジタル DID/CLID

VG-200

あり

あり

あり

あり

あり

あり

あり

Cisco 1750

なし

なし

なし

なし

なし

将来

将来

Cisco 3810 V3

あり

なし

あり

なし

なし

あり

なし

あり

Cisco 2600

あり

あり

あり

あり

あり

あり

将来

あり/あり

Cisco 3600

あり

あり

あり

あり

あり

あり

将来

あり/あり

Cisco 7200

あり

あり

あり

あり

あり

なし

なし

あり/あり

Cisco 7500

あり

あり

あり

あり

あり

なし

なし

あり/あり

Cisco 5300

あり

あり

あり

あり

あり

なし

なし

あり/あり

Catalyst 4000 WS-X4604-GWY

あり

あり

あり

あり

あり

将来

将来

あり/あり

Catalyst 6000 WS-X6608-x1

将来

なし

なし

あり

あり

なし

なし

あり/あり

ICS 7750 MRP/ASI

あり

なし

なし

あり

あり

あり

あり

あり

IP テレフォニーの要件

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

コール処理エージェント

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

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

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

エンド ユーザ デバイス

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

 

表 5-13 Cisco プラットフォーム

デバイス/機能
使用可能なプラットフォーム

コール処理エージェント

ソフトウェア:Cisco CallManager
ハードウェア: MCS-7825-800、MCS-7835-1000、ICS-7750
IOS ベースの survivable remote: Vespa(IOS 12.1(5)-YD)

コール アドミッション制御メカニズム

集中型コール処理モデル: CallManager
分散型コール処理モデル:ゲートキーパ

音声ゲートウェイ

H.323: 1750、2600、3600、AS5300、7200、7500、ICS 7750 MRP/ASI
Skinny: DT-24+、DE-30+、Catalyst T1 および E1 モジュール
MGCP: VG-200、2600、3600、IAD2400、ICS 7750 MRP/ASI(将来)

FAX/モデム ゲートウェイ

H.323: 2600、3600、AS5300、ICS 7750 MRP/ASI
MGCP: 2600、3600、AS5300、IAD2400、ICS 7750 MRP/ASI(将来)
Skinny: Catalyst T1/E1 および FXS/FXO モジュール

トランスコーディング/会議リソース

Catalyst T1/E1 および FXS/FXO モジュール、ICS 7750 MRP/ASI(トランスコーディングのみ)

エンド ユーザ デバイス

Cisco IP Phone 7905
Cisco IP Phone 7910
Cisco IP Phone 7940
Cisco IP Phone 7960
Cisco SoftPhone
Cisco IP Conference Station 7935

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

 

表 5-14 Media Convergence Server の技術仕様

技術仕様
MCS 7825-800
MCS 7835-1000

Intel PIII プロセッサ

800 MHz

1 GHz

メモリ(SDRAM)

512 MB

1 GB

SCSI ハード ドライブ(HD)

Single 20GB Fast ATA(7200 RPM)

Dual 18.2GB Ultra3 SCSI(10,000 RPM)

3.5” フロッピ ドライブ

1.44MB フロッピ ドライブ

1.44MB フロッピ ドライブ

CD-ROM ドライブ

24x IDE CD-ROM ドライブ

24x IDE CD-ROM ドライブ

ビデオ コントローラ

ATI Rage XL : 4MB

ATI Rage IIC : 4MB

RAID コントローラ

なし

内蔵 Smart Array RAID コントローラ:RAID 0/1 ディスク ミラーリング

ホットプラグ ハード ドライブ

なし

あり

ホットスワップ冗長 PS

なし(180W)

あり(275W)

ラックマウント サイズ(1U=1.75”)

1U

3U

コントローラ モジュール

内蔵 Ultra ATA/100 コントローラ

内蔵シングル チャネル wide-ultra SCSI-3 アダプタ

10/100 PCI UTP コントローラ(組み込み)

デュアル ポート

シングル ポート

磁気テープ ドライブ

12/24 GB DAT 磁気テープ ドライブ(オプション)

ソフトウェアの両立性

CallManager 3.0.x

あり

あり

IP IVR/Auto Attendant

あり

あり

Unity 音声メール

なし

あり

IPCC/ICM サーバ

なし

あり

IPT Personal Assistant サーバ

なし

あり

柔軟性

IP IVR/Auto attendants ポート

30

48

CCM 3.0 フォン サポート

500 台

2500 台

IP IVR/Auto attendants ポート

30

48

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

 

表 5-15 Integrated Communications System(ICS)7750 の技術仕様

技術仕様
ICS 7750

一般

ホットスワップ冗長 PS

200 ワット

ラックマウント サイズ

9RU

システム カード

システム スイッチ プロセッサ

10/100BaseT 自動検知データ スイッチ

2 ポート RJ-45 コネクタ

システム アラーム プロセッサ

シリアル ポート 2 つ、コンソール ポート 1 つ

リソース カード

システム処理エンジン

SPE 310

Intel PIII プロセッサ 700 MHz

412 MB メモリ(SDRAM)オンボード、拡張スロット 2 つ、最大 1.5 G

シングル 20 GB IDE ハード ドライブ

USB ポート 2 つ(CD-ROM/Floppy ドライブ)

VGA ポート

キーボード/マウス ポート(Y 字型ケーブルが必要)

マルチサービス ルート プロセッサ

標準メモリ: 64 MB DRAM(最大 96 MB)

メモリ アップグレード(オプション): 16、32 MB DRAM

カードごとに 2 つのモジュラ音声/WAN インターフェイス(VWIC)カード スロット

WIC: Serial、BRI、T1 FT1

VIC: FXO、FXS、E&M、T1-CAS

T1-PRI、E1-PRI、BRI(U&S/T)、FXO-M2/3、2DID に対する VIC および WIC サポート

2 つの T1 549 DSP スロット、最大 10 個の DSP

DSP トランスコーディング サポート(G.711、G.729a、G.723、G.726)

FAX リレー/パススルー サポート

Analog Station Interface 160 - 16 ポート FXS カード

Analog Station Interface 81 - 8 ポート FXS カード、および VIC/WIC スロット

VoIP、IP WAN/MAN ルーティング サポート

内蔵ハードウェア支援暗号化(オプション)

ソフトウェアの両立性

CallManager 3.1

あり

System Manager

あり

Unity 音声メール

内蔵

柔軟性

CallManager 3.1 フォン
サポート

1000 回線

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

 

表 5-16 ハードウェアとソフトウェアの要件

製品
推奨リリース

Catalyst スイッチ(4000、6x00)

Catalyst OS 5.5 以上

Catalyst スイッチ(35xxXL)

Cisco IOS 12.0(5)XU 以上

Cisco ルータ(17xx、26xx、36xx、72xx、75xx、ICS 7750 MRP)

Cisco IOS 12.1(5)T 以上

Media Convergence Server

CallManager 3.0(5) 以上

ICS 7750

CallManager 3.1

電源と環境の要件

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

 

表 5-17 消費電力と熱放散の要件

項目
定格入力 VA
熱(BTU)

Cisco 7204

370

Catalyst 5509

1000

Cisco 7206

370

1262

MCS-7835

432

1475

Catalyst 6006

1800

6140

ICS 7750

324

1105

実装準備度の確認

実装を設定する前に、高度な技術と専門知識を持つシスコ代理店の技術員が、設計をリビューして、高水準と低水準の設計がカスタマーの要件を満たしていることを確認します。設計をリビューした結果、改善をお勧めする場合があります。

設計リビューの結果を、カスタマー準備度チェック情報と一緒に文書化します。ソリューションの実装前に、実装前のチェックリスト( 表 5-18 )に記入してください。

 

表 5-18 実装前のチェックリスト

コンポーネント
準備度

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



音声ネットワーク分析



データ ネットワーク分析

LAN 要件



データ ネットワーク分析

WAN 要件

WAN 帯域幅要件



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



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



カスタマー発注機器



顧客宅内機器(CPE)インターフェイス



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



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

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

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

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

音声ネットワーク分析

データ ネットワーク分析

LAN 要件分析

WAN 要件分析

WAN 帯域幅要件の分析

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

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

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

IP Phoneの終端ポイント(PBX/Centrex/Key システム)

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

他のサイトとのトランク(プライベートまたは VPN)の数

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

セット(ユーザ)数

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

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

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

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

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

音声ネットワーク分析

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

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

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

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

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

 

表 5-19 現在のトランク使用状況

トランク タイプ
双方向コール
DID トランク
DOD トランク

音声メール トランク

PSTN トランク

サイト X へのトランク

サイト Y へのトランク

サイト Z へのトランク

トランキング要件を判別するには、トラフィックを調査します。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 設定を準備するためのものです。

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

 

番号
DID
リモート サイト
ルート
サイト名

1

2

3

4

5

6

7

8

9

10

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

 

地域
サイト コード
回線 #
FRY/ATM
速度
VPI
VCI
DLCI

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

 

名前
機能
機器タイプ
IP アドレス
ゲートウェイ

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

 

インターフェイス
IP アドレス
サブネット マスク
接続先
帯域幅
VLAN
ポート

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

 

インターフェイス
IP アドレス
サブネット
接続先
帯域幅
DLCI
VBR
VPI
VCI

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

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

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

 

ノード名
IP VLAN 1
IP VLAN 2
IP VLAN 3
IP VLAN 4
サブネット マスク
デバイス タイプ

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

 

地域
サイト
コード
開始 IP
終了 IP
LAN
サブネット
マスク
WAN
LOOP

CallManager 設定テンプレート

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

CallManager 設定属性テンプレート

 

パラメータ

プライマリ CallManager のホスト名

セカンダリ CallManager のホスト名

プライマリ CallManager の IP アドレス

セカンダリ CallManager の IP アドレス

サイトの Win NT ワークグループ名

NTP サーバ アドレス

SNMP read コミュニティ

SNMP write コミュニティ

CallManager ポート テンプレート

 

CallManager
説明
IP アドレス
イーサネット ポート
デジタル
アクセス
アナログ
アクセス

CallManager グループ テンプレート

 

CallManager グループ
CallManager
優先順位

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

 

DID
リモート サイト
サイト名
帯域幅(Kbits)
ルート ID

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

 

デバイス プール
CallManager グループ
日付/時刻
地域

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

 

パーティション
説明

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

 

DN/ルート パターン
数字破棄
プレフィックス
パーティション
ルート リスト

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

 

ゲートウェイ名
ルート グループ
選択順序

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

 

ルート リスト
ルート グループ

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

 

ゲートウェイ
デバイス
プロトコル
説明
デバイス プール
コール探索
スペース

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

 

ディレクトリ番号
パーティション

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

 

コール パーク番号/範囲
パーティション
Cisco CallManager

IP Phone テンプレート

 

テンプレート名
ボタン数
ユーザ変更可能

IP Phone ボタン テンプレート

 

テンプレート名
ボタン番号
機能
インデックス
ラベル

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

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

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

 

クラスタ
エリア コード
内線番号の範囲

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

 

サイト
IP Phone
構成
DID ブロック
DID 範囲

カスタマー発注機器

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

 

表 5-20 シスコ提供の機器

部品番号
説明
数量

 

表 5-21 カスタマー提供の機器

説明
数量

顧客宅内機器(CPE)インターフェイス

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

 

表 5-22 CPE インターフェイス チェックリスト

接続元
接続先
インター
フェイス
ケーブル タイプ(複数可)
提供元
設置者

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

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

ソリューションの実装

シスコ代理店のプロジェクト管理者は、オンサイト サービス インストレーションを管理し、フィールド エンジニアに情報を提供します。この情報は、フィールド エンジニアが物理的なインストレーションを実行するのに必要です。

ソリューションのステージングには、カスタマー ネットワークの接続前に、単一ロケーションでのソフトウェアのロード、および全ハードウェアの電源オンが含まれます。すべてのデバイスが接続され、完全な設定、テスト、および稼動が行われる必要があります。カスタマーは、技術スタッフをネットワーク ステージングに参加させ、技術スタッフが IP テレフォニー ソリューションに習熟するようにする必要があります。その結果、迅速でシームレスなインストレーションとカットオーバーが行われます。


) ICS 7750 システムを使用する場合、まず、ICSconfig を実行してから、システムをネットワークに接続する必要があります。


実装エンジニアは、次のタスクを、表示されている順に実行する必要があります。

1. 機器を開梱する。

2. キャビネットの電源供給、レール、およびアースの取り付けを確認する。

3. 新しいネットワーク デバイス間のケーブルを含めて、キャビネット内に機器を物理的にインストールする。

4. 機器のシリアル番号を記録し、配送資料に照らして確認する。

5. 機器のスロット割り当てを確認する。

6. キャビネット内の電源ケーブルとアース ケーブルを機器に取り付ける。

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

8. カスタマーのパッチパネル内の回線終端を確認する。

9. シスコ機器の電源をオンにする。

10. システム ソフトウェアとファームウェアを検証し、ロードする。

11. 機器を設定する。

12. ダイヤル プランを実装する。

13. E-911 を設定する。

14. インストレーション テストを行う。

15. カスタマー ネットワークに機器を追加する。

16. ソリューション受け入れテストを実行する。

各アクティビティの詳細は、次の小項目で記述されています。

機器の開梱

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

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

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

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

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

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

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

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

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

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

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

 

表 5-23 機器スロットの割り当て

機器番号
スロット番号
カード名
カードの機能

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

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

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

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

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

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

シスコ機器の電源オン

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

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

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

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

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

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

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

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

機器の設定

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

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

CallManager クラスタ

DSP リソース プロビジョニング(トランスコーディング)

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

ダイヤル プランの実装

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

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

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

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

ワイルドカード
範囲

X

1 桁の数字(0~9)

N

1 桁の数字(2~9)

@

North American Numbering Plan

!

1 桁以上(0~9)

[x-y]

総称範囲の表記

[^x-y]

除外範囲の表記

.

アクセス コードを終了する

#

数字間タイムアウトを終了する

ルート リスト:宛先(私設ネットワークまたは 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 通りの方法を示します。

 

パターン

911

9.911

@ WHERE SERVICE=911

9.@ WHERE SERVICE=911

ゲートウェイの選択

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 回帰テストを実行して、移行前の設定を確認します。


 

移行方法の実装

この項では、新しい Cisco CallManager 3.0 ソリューションのインストールまたはアップグレードの前に、Cisco CallManager 3.0 の配置とアップグレードを行い、シスコ代理店の Professional Services 担当者にチェックリストを提供するために、全体的な順調な移行プロセスを確保する情報を記述しています。

模擬稼働と実稼働の 2 つの段階で、アップグレードを計画することをお勧めします。模擬稼働段階では、追加の準備または変更が必要になった場合に、以前のソフトウェア リリースにロールバックできます。

1. 模擬稼働

模擬稼働時には、計画されたアップグレード手順を実行します。指定された時間内の模擬稼働中に問題が発生する場合、アップグレード前の設定にロールバックすることができます。模擬稼働で発生したすべての問題を記録してください。これらの問題は、実際の移行を実行する前に調査し、特定し、修正する必要があります。必要に応じて、手順の変更を移行計画で修正する必要があります。

2. 実稼働

実際のアップグレードは、模擬稼働で特定されたすべての問題が処理された後に行います。この段階では、模擬稼働の手順を実行してください。模擬稼働時に問題が起きた場合、変更されている手順を使用してください。実稼働が正常に完了した後、Cisco IP テレフォニー ソリューション用のシステム アーキテクチャで定義された設定に、サイトをアップグレードする必要があります。

各アップグレード段階は、営業時間外にスケジュールする必要があります。最初の模擬稼働が成功した場合は、その模擬稼働を実稼働として受け入れ、2 番目のステップをスキップします。

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

移行段階

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

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

この項では、Solution Implementation Acceptance(SIA; ソリューション実装受け入れ)テストのプロセス、および SIA テストの基準について説明します。すべてのソリューション実装テストは、シスコ システムズ プロフェッショナル サービス エンジニアまたはシスコ代理店のプロフェッショナル サービスの責任で行います。ソリューション実装テストは、カスタマーの担当者の立ち会いの下で実行する必要があります。SIA テスト プログラムにより発生する問題は、すべてプロジェクトの Issues Log に入力されます。SIA テスト プログラムの予想所要時間は、7 営業日です。

検証プロセス

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 用に作動可能になっていることを確認します。


 

表 5-24 実装ソリューション受け入れテストのマスター リスト

テスト番号
テストの名称
CallManager 点検テスト

1001

CallManager サービス状況

1002

CallManager 設定

1003

CallManager デバイス デフォルト設定

1004

CallManager ゲートウェイ

1005

CallManager 音声メール ポート(ユニファイド メッセージ ポート)

汎用 IP Phone テスト

1101

基本 IP Phone

1102

コールの保留と再開

1103

コール パーク

1104

グループ ピックアップ

1105

コール ウェイティング

1106

共用ライン アピアランス

1107

オフネット IP Phoneへのコール転送

1108

オフネット IP Phoneへの自動転送

キャンパス コール処理

1201

LAN 上の IP Phone ツー IP Phone ダイヤルアップ

1202

オンネット IP Phoneへのコール転送

1203

オンネット IP Phoneへの自動転送

1204

Ad-hoc 会議

1205

Meet-me 会議

集中型呼処理

1301

リモート サイトへの IP Phone ツー IP Phone ダイヤルアップ

1302

リモート サイトの IP Phoneへのコール転送

1303

リモート サイトの IP Phoneへの自動転送

1304

WAN リンクを介した Ad-hoc 会議

1305

WAN リンクを介した Meet-me 会議

分散型コール処理

1401

異なるクラスタ内の IP Phone ツー IP Phone ダイヤルアップ

1402

別のクラスタ内の IP Phoneへのコール転送

1403

別のクラスタ内の IP Phoneへの自動転送

1404

2 つのクラスタ間の Ad-hoc 会議

1405

2 つのクラスタ間の Meet-me 会議

拡張 IP テレフォニー

1501

(オプション)4 者会議

1502

(オプション)6 者 Ad-hoc 会議

1503

(オプション)モデム間

1504

(オプション)FAX 間

1505

(オプション)CallManager フェールオーバー

受け入れ基準

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

実装後の文書作成

IP テレフォニー ソリューションの実装段階が完了した後、プロジェクト チームは、資産の追跡のため、および機器の所有権を確認するために、すべての機器を文書化します。シスコ貸与のすべての機器は、カスタマーの構内から取り外す必要があります。特に、カスタマーが SmartNet サポートを購入した場合はこのことはより重要です。プロジェクト チームは、すべての機器のシリアル番号を記録することが重要です。

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

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

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

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

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

Customer Acceptance Certification

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

 

受け入れ証明書

お客様のお名前とご住所:

契約番号:

実装の完了

1. お客様に満足いただけるように、機器の取り付けが完了しました。

2. 取り付けと稼動のテストがすべて完了し、記録されました。

3. 機器は、お客様のネットワークに正常に追加されました。

4. Solution Test Plan に記述されているすべてのテストが完了し、結果が記録されました。

5. すべての障害が調査され、お客様が満足できるように説明され、解決されました。そうでない場合、明確に了解されたプロセス(TAC ケースまたは DDT ケース)の下でさらに調査されます。

6. お客様のネットワークは、お客様のライブ トラフィックを伝送し、シスコ代理店によりサポートされる準備ができているものと見なされます。

署名者(「カスタマー」)は、シスコシステムズとのインストレーション契約に基づくカスタマーです。カスタマーは、IP テレフォニー ソリューションの実装が、下記の受け入れ日にカスタマーによって受け入れられ、受け入れられた機器の各項目にラベル(提供される場合)が貼付されていることを表示し、証明します。

カスタマーは、上記にリストされている項目が、下記の受け入れ日にカスタマーによって受け入れられたことを証明します。

ファクシミリまたはその他の信頼できる手段による本受け入れ証明書のコピーの引き渡しは、手作業で作成されたコピーの引き渡しとして有効であると見なされます。カスタマーは、シスコシステムズが本証明書のコピーを電子形式で保持することを了解し、電子形式またはその他の信頼できる手段(たとえば、フォトコピー、画像、またはファクシミリ)により作成されるコピーが、あらゆる点で本証明書の原本と同等と見なされることに同意します。

受領者:

______________________________

受領者:

___________________________

(正当な権限を有するシスコの署名)

(正当な権限を有するカスタマーの署名)

______________________________

___________________________

(名前 ñ タイプまたは活字体)

(名前 ñ タイプまたは活字体)

受け入れ日:

___________________________

___________________________

(記入が必要)

(記入が必要)

シスコシステムズのプロジェクト管理者に返送してください。

実装レポートの作成

ソリューションの実装終了後、プロジェクト管理者は、アカウント チーム用に実装レポートを作成する必要があります。実装レポートは、すべての実装文書、およびソリューション受け入れテスト結果を要約すると、簡単に作成できます。

完了とカスタマーの受け入れ証明書の日付は、公式の記録用に文書化されなければなりません。

ケース スタディ

IP テレフォニーのケース スタディは、次のロケーションで入手できます。

http://www.cisco.com/warp/public/788/AVVID/hdppcasestudy.html

http://www.cisco.com/warp/public/788/AVVID/ACU_casestudy.html

http://www.cisco.com/warp/public/788/AVVID/NB_Singapore.html

これらのケース スタディ内の名称は架空のものですが、実際の IP テレフォニーの実装に基づいたものです。