Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月30日
章のタイトル： IP テレフォニー配置モデル
IP テレフォニー配置モデル
各 Cisco IP テレフォニー ソリューションは、次に説明する主要配置モデルに基づいて実現されています。
•
「単一サイト」
単一サイトで IP テレフォニーを実現する場合のモデルは、その単一サイトに配置されるコール処理エージェント、およびそのサイト全体に音声トラフィックを伝送するための LAN または MAN（メトロポリタンエリア ネットワーク）から構成されています。コールが LAN または MAN を超えて発信される場合は、PSTN（公衆電話交換網）が使用されます。IP WAN が単一サイト モデルに組み込まれている場合、IP WAN はデータ トラフィック専用です。テレフォニー サービスは WAN を介して行われることはありません。
このモデルは、キャンパスが 1 個所の場合、または回線数が 30,000 未満のサイトの場合に適用されます。
集中型コール処理を使用するマルチサイト WAN モデルは、単一のコール処理エージェントから構成されています。このコール処理エージェントは、多数のサイトにサービスを行い、IP WAN を使用してサイト間で音声トラフィックを転送します。また、IP WAN は、中央サイトとリモート サイト間のコール制御信号も伝送します。
このモデルは、次のようなメイン サイトに適用されます。QoS 対応 WAN 経由で接続されている、小規模のリモート サイトが多数あり、WAN の故障中はそれらのリモート サイトにフル機能が要求されない場合です。
分散型コール処理を使用するマルチサイト WAN モデルは、複数の独立したサイトから構成されています。各サイトには独自のコール処理エージェントがあり、そのエージェントは、分散サイト間の音声トラフィックを伝送する IP WAN に接続されます。このモデルの IP WAN は、各サイトに独自のコール処理エージェントがあるので、サイト間のコール制御信号を伝送しません。
このモデルは、回線数が 30,000 を超える大規模の中央サイトの場合、または、6 個所以上に分散している大規模サイトの合計回線数が 30,000 を超えていて、そのサイト間が QoS 対応 WAN で相互接続されている場合に適用されます。
このモデルでは、単一の Cisco CallManager クラスタが配置されていて、複数のサイト間は QoS 機能に対応している IP WAN によって接続されています。
このモデルは、最大で 6 個所に分散している大規模サイトの合計回線数が 30,000 以内で、そのサイト間が QoS 対応 WAN で相互接続されている場合に適用されます。
（注） このマニュアルは、読者が前述の配置モデルの内容を理解していることを前提としています。したがって、配置モデルについて十分に理解した上で、読み進むことをお勧めします。
この章ではまた、前述の主要配置モデルに加えて、次の設計上の考慮事項、および変則事項について説明します。
この項では、Cisco IOS Multiprotocol Label Switching（MPLS）で使用されているフルメッシュ型ルーティング テクノロジーをサポートするために IP テレフォニー配置モデルを調整する方法についても説明します。
• 「U. S. Section 508 準拠についての設計上の考慮事項」
この項では、IP テレフォニー ネットワークを設計するときに、身体に障害のあるユーザに対して U.S. Section 508 に従ってアクセシビリティ機能を組み込む場合のガイドラインを示します。
単一サイト
単一サイトで IP テレフォニーを実現する場合のモデルは、その単一サイト（キャンパス）に配置される 1 つのコール処理エージェントから構成されています。テレフォニー サービスは、IP WAN を使用して行われることはありません。企業は、一般的に、LAN または MAN に対しては単一サイト モデルを配置して、サイト内の VoIP（Voice over IP）トラフィックを伝送しています。このモデルでは、コールが LAN または MAN を超えて発信される場合は、PSTN（公衆電話交換網）が使用されます。
• 単一の Cisco CallManager または Cisco CallManager クラスタ
• 会議、トランスコーディング、および MTP（メディア終端点）に対して DSP（デジタル信号プロセッサ）リソースで対応
• 音声メールとユニファイド メッセージング コンポーネント
• すべての IP フォン コールに対して G.711 コーデックのみで対応（コールごとに 80 kbps の IP 帯域幅、圧縮なし）
• レガシー PBX（構内交換機）システムおよび音声メール システムとの統合機能
図 1-1 では、単一キャンパスまたは単一サイト内の IP テレフォニー ネットワークのモデルを示しています。
単一サイト モデルのベスト プラクティス
単一サイト モデルを実装する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。
• 一般的なインフラストラクチャ 構想に基づいて可用性および耐障害性を高めます。IP テレフォニーへの迅速な移行、アプリケーションにビデオ ストリーミングやビデオ会議などを容易に統合、および IP テレフォニー配置を拡張し、WAN または複数の Cisco CallManager クラスタへのアクセスを可能にするには、インフラストラクチャを適切に構築する必要があります。
• 自社内のコール パターンを知っておく必要があります。単一サイト モデルは、大部分のコールが社内の同一サイトから発信されている場合、または社外の PSTN ユーザ宛てに発信されている場合に適用します。
• すべてのエンドポイントに G.711 コーデックを使用します。この方式を実施すると、トランスコーディングに対してデジタル信号プロセッサ（DSP）リソースを消費する必要がなくなり、その分のリソースは、会議やメディア終端点（MTP）などの他の機能に割り当てることができます。
• H.323 機能を必要としない場合、PSTN にメディア ゲートウェイ コントロール プロトコル（MGCP）ゲートウェイを使用します。この方式を実施すると、ダイヤル プランの設定が容易になります。H.323 は、MGCP で提供されていない特定の機能（たとえば、Signaling System 7（SS7）や Non-Facility Associated Signaling（NFAS））をサポートするために必要な場合があります。
• 高可用性、電話機用の接続オプション（インライン電源）、Quality of Service（QoS）メカニズム、およびセキュリティ用の推奨ネットワーク インフラストラクチャを実装しています（「ネットワーク インフラストラクチャ」を参照）。
• 「コール処理」の項にリストされているプロビジョニングの推奨事項を実行する必要があります。
集中型コール処理を使用するマルチサイト WAN
集中型コール処理を使用するマルチサイト WAN モデルは、単一のコール処理エージェントから構成されています。このコール処理エージェントは、多数のサイトにサービスを行い、IP WAN を使用してサイト間の IP テレフォニー トラフィックを転送します。また、この IP WAN は、中央サイトとリモート サイト間のコール制御信号も伝送します。図 1-2 では、一般的な集中型コール処理配置を示しています。この配置では、中央サイトのコール処理エージェントとして Cisco CallManager クラスタを使用し、すべてのサイトを接続するために、QoS 対応の IP WAN を使用します。リモート サイトでは、コール処理に集中型 Cisco CallManager クラスタを使用します。音声メール システムや IVR（Interactive Voice Response）システムなどのアプリケーションも、管理と保守にかかる全体的なコストを削減するために、一般に中央に配置されます。
（注） このマニュアルで説明する集中型コール処理モデルを適用した各ソリューションでは、さまざまなサイトは、QoS 対応の IP WAN に接続されています。
• ATM とフレーム リレーのサービス インターワーキング（SIW）
• マルチプロトコル ラベル スイッチング（MPLS）仮想プライベート ネットワーク（VPN）
• 音声およびビデオ対応 IP Security Protocol VPN（IPSec VPN（V3PN））
WAN エッジに置かれているルータには、優先キューイングやトラフィック シェーピングなどの QoS メカニズムが装備されていて、WAN の帯域幅が恒常的に不足している場合に、データ トラフィックから音声トラフィックを保護しています。さらに、コール アドミッション制御方式も導入されていて、音声トラフィックによる WAN リンクの過剰サブスクリプションを防いだり、確立済みのコール品質が低下するのを防いだりしています。集中型コール処理配置の場合、Cisco CallManager 内にコール アドミッション制御を行うロケーションが構築されます。（ロケーションの詳細は、「集中型コール処理に対するコール アドミッション制御」の項を参照してください）。
リモート サイトでは、さまざまな Cisco ゲートウェイにより、PSTN を介したアクセスが可能です。IP WAN に障害が起きた場合、または IP WAN 上で使用可能な帯域幅がすべて消費されてしまった場合でも、リモート サイトのユーザは、PSTN アクセス コードをダイヤルして、PSTN を利用してコールを発信できます。Cisco IOS ゲートウェイ上で Survivable Remote Site Telephony（SRST）機能を利用すると、WAN に障害が発生している事業所でのコール処理が可能になります。
（注） 集積された音声とデータのトラフィックを制御するには QoS 機能が必要ですが、QoS 機能をもたない WAN テクノロジーを使用することも可能です。こうしたテクノロジーを使用して WAN を設計する場合、このマニュアルで説明していない、特別な事項に考慮する必要があります。さらに、こうしたQoS 機能の一部が不足しているテクノロジーでは、通常、良好な音声品質を維持することができません。
集中型コール処理を使用するマルチ サイト モデルのベスト プラクティス
集中型コール処理を使用したマルチサイト WAN モデルを実装する場合は、次のガイドライン、およびベスト プラクティスを参考にしてください。
• 音声のカットスルー遅延（クリッピングとも呼ばれます）を減らすために、Cisco CallManager とリモート ロケーション間の遅延を最小限に抑えます。
• ハブアンドスポーク トポロジーの場合は、リモート事業所とのコール アドミッションを制御している Cisco CallManager 内のロケーション メカニズムを使用します。WAN で Cisco IOS MPLS（Multiprotocol Label Switching）が使用されている場合は、「マルチ サイト MPLS WAN に関する考慮事項」の項を参照してください。
• ロケーション メカニズムは、Cisco CallManager 3.1 およびそれ以降のリリースで実行される複数サーバに対して作動します。この設定では、Cisco CallManager がサポートされているサーバ上で実行されている場合、最大 30,000 台の IP フォン（または 20,000 台のデバイス ユニット）をサポートできます。
• 各リモート サイトでの Survivable Remote Site Telephony（SRST）モードでサポートされている IP フォンの台数および回線数は、その事業所内にあるルータのプラットフォーム、取り付け済みメモリ容量、および Cisco IOS リリースにより異なります（SRST プラットフォームおよびコード仕様に関する詳細は、Cisco.com から入手できる SRST 文書を参照してください）。一般的には、特定サイトに対して集中型コール処理か、分散コール処理かを決定するには、次に示す種々の要素によります。
カスタマのビジネス ニーズに分散型コール処理モデルがふさわしいと判断される場合は、2 つの選択肢があります。ローカルに Cisco CallManager サーバをインストールする方法と、事業所ルータ上に Cisco IOS Telephony Service（ITS）を稼働する方法です。
集中型コール処理に対するコール アドミッション制御
マルチ サイト配置では、コール アドミッション制御を取り入れ、帯域幅に余裕のないネットワーク リンクに伝送される音声品質を確保することが必要です。Cisco CallManager では、 ロケーション（location） と呼ばれている単純なメカニズムを取り入れており、集中型コール処理と連携して動作するマルチ サイト WAN 配置には、コール アドミッション制御を実装しています。コール アドミッション制御に対してロケーションを使用する場合は、次のガイドラインに従ってください。
• ロケーションには、ハブアンドスポーク ネットワーク トポロジーが必要。
• 各サイトのCisco CallManager に対しては、個別にロケーション設定が必要。
• 各サイトの帯域幅の上限を、そのサイトに使用されているコーデックのタイプに応じて、適切に設定（帯域幅の設定については、 表 1-1 を参照してください）。
• Cisco CallManager を使用して設定される各デバイスの、ロケーションへの割り当て。あるデバイスを別のロケーションに移した場合、ロケーションの設定も変更。
• Cisco CallManager は、ロケーションを 500 個所までサポート。
Cisco CallManager リリース 3.1 以前のリリースでは、コール アドミッション制御用にロケーションを使用する場合には、クラスタはプライマリ（アクティブ） Cisco CallManager サーバを 1 つのみサポートしていました。Cisco CallManager リリース 3.1 およびそれ以降では、ロケーションの帯域幅は、クラスタ内のすべての Cisco CallManager サブスクライバ サーバ間で共有されるので、ロケーション メカニズムには任意のサイズのクラスタを使用できるようになりました。
|
|
|
|
|---|---|---|
|
|
|
|
分散型コール処理を使用するマルチサイト WAN
分散型コール処理を使用するマルチサイト WAN モデルでは、複数の独立したサイトから構成されています。各サイトには独自のコール処理エージェントがあり、そのエージェントは、分散サイト間の音声トラフィックを伝送する IP WAN に接続されます。しかし、集中型コール処理モデルとは異なり、分散モデルの IP WAN は、各サイトに独自のコール処理エージェントがあるので、サイト間でコール制御信号を伝送しません。図 1-3 では、一般的な分散型コール処理配置を示しています。
分散型コール処理モデルの各サイトは、次のいずれかになります。
• 独自のコール処理エージェントを使用する単一サイト。コール処理エージェントは、Cisco
CallManager、Cisco ITS（IOS Telephony Services）、またはその他の IP PBX にすることができます。
• 集中型コール処理サイトと、それに関連したすべてのリモート サイト。
• Voice over IP（VoIP）ゲートウェイを備えたレガシー PBX。
IP WAN は、分散型コール処理のサイトをすべて相互接続します。一般に、PSTN は、IP WAN 接続に障害が起きたか、使用可能な帯域幅がすべて消費されてしまった場合に、サイト間のバックアップ接続の役目をはたします。PSTN のみで接続されているサイトは、独立サイトであり、分散型コール処理モデルには含まれません（「単一サイト」 を参照）。
• ATM とフレーム リレーのサービス インターワーキング（SIW）
• マルチプロトコル ラベル スイッチング（MPLS）仮想プライベート ネットワーク（VPN）
• 音声およびビデオ対応 IP Security Protocol VPN（IPSec VPN（V3PN））
分散型コール処理を使用するマルチ サイト モデルのベスト プラクティス
分散型コール処理を使用するマルチサイト WAN には、単一サイト、および集中型コール処理を使用するマルチサイト WAN と同じ要件が少なからずあります。分散型コール処理モデルについては、ここでリストされているベスト プラクティスに加えて、他のモデルのベスト プラクティスにも従ってください（「単一サイト」および 「集中型コール処理を使用するマルチサイト WAN」を参照）。
ゲートキーパーは、分散型コール処理を使用するマルチサイト WAN モデルの重要な要素の 1 つです。ゲートキーパーは、コール アドミッション制御と E.164 ダイヤル プラン解決を実行する H.323 デバイスです。ゲートキーパーの使用には、次のベスト プラクティスが適用できます。
• ゲートキーパーに論理ハブアンドスポーク トポロジーを使用します。ゲートキーパーは、サイトに出入りする帯域幅、またはサイト内のゾーン間の帯域幅を管理しますが、このトポロジーを認識できません。
• ゲートキーパーの有効性を高めるには、HSRP（ホットスタンバイ ルータ プロトコル）ゲートキーパー ペア、ゲートキーパーのクラスタ化、および代替ゲートキーパー サポートを使用します。さらに、ネットワーク内の冗長性を確実にするために複数のゲートキーパーを使用します。
• WAN 上のコーデックは １ つのタイプに限定して使用します。これは、H.323 仕様では、レイヤ 2、IP、UDP（User Data Protocol）、または RTP（Real-time Transport Protocol）ヘッダーのオーバーヘッドが、帯域幅要求で許可されないからです（ヘッダーのオーバーヘッドは、パケットのペイロードまたは符号化された音声部分のみで許可されます）。WAN 上で使用するコーデックを 1 つのタイプに限定すると、最悪のシナリオに備えて IP WAN を過剰にプロビジョニングする必要がなくなるので、キャパシティ プランニングが簡単になります。
• ゲートキーパー ネットワークは、数百単位のサイトにスケーラブルです。また、設計上の制限はハブアンドスポーク トポロジーからしか受けません。
ゲートキーパーの詳細は、「ゲートキーパーの考慮事項」 を参照してください。
分散型コール処理に対するコール アドミッション制御
マルチ サイト配置では、コール アドミッション制御について次の方式を組み入れて、帯域幅に余裕のないネットワーク リンクに伝送される音声品質を確保する必要があります。分散型コール処理を使用するマルチ サイト WAN 配置の場合は、サイトの要件に応じて、コール アドミッション制御方式から 1 つを使用します。
• 高速の LAN または MAN に対して Cisco CallManager クラスタを使用する場合は、「インタークラスタ トランク」を使用します。
• トール バイパスまたは既存の H.323 環境を統合する場合は、「H.225 ゲートキーパー制御トランク」を使用します。
• ハブアンドスポーク（スター）トポロジーを使用した WAN を使用する場合は、「インタークラスタ ゲートキーパー制御トランク」を使用します。
• 他のケースでハブアンドスポーク トポロジーに準拠しないネットワークを使用する場合は、「ロケーションを使用したインタークラスタ ゲートキーパー制御トランク」を使用します。
インタークラスタ トランク
Cisco CallManager は、インタークラスタおよび H.323 通信に対して、次の 3 種類のトランクをサポートしています。
インタークラスタ トランクは、Cisco CallManager クラスタ間相互の通信に使用されます。インタークラスタを使用するには、各 Cisco CallManager クラスタ上に接続されているインタークラスタを設定します。
（注） コール アドミッション制御は、 インタークラスタ トランクを使用しているクラスタ間では利用できません。したがって、インタークラスタ トランクは高速 LAN や MAN などの帯域幅に十分余裕のある場合に使用してください。
H.225 ゲートキーパー制御トランク
H.225 ゲートキーパー制御トランクは、Cisco CallManager が他のCisco CallManager クラスタおよび H.323 ゲートキーパーに登録済みの H.323 デバイスと通信を行います。H.225 ゲートキーパー制御トランクは、単純 Cisco CallManager 環境では使用しないようお勧めします。
コール アドミッション制御に H.225 ゲートキーパー制御トランクを使用する場合は、次に示すガイドラインに従ってください。
• 各 Cisco CallManager クラスタのゲートウェイは、同じ方法で設定します。
• Cisco CallManager クラスタに H.225 ゲートキーパー制御トランクを設定します。
• ゲートキーパーを使用して、クラスタ内の各 Cisco CallManager を、H.225 ゲートキーパー制御トランクに登録します。
• コールは、Cisco CallManager クラスタに登録済みのトランク間にロードバランスされます。
• Cisco CallManager は、複数のゲートキーパーおよびトランクをサポートします。
• Cisco CallManager またはボイス ゲートウェイをサポートしている各サイトに対するゲートキーパーのゾーンは、個別に設定します。
• bandwidth interzone コマンドをゲートキーパーに使用して、そのゲートキーパーに登録済みの Cisco CallManager クラスタおよび H.323 デバイス間の帯域幅の制御を直接行います（コーデック タイプ別の帯域幅の設定については、 表 1-1 を参照してください）。
• 単一 Cisco IOS ゲートウェイキーパーは、100 台までの Cisco CallManager クラスタをサポートします。
例1-1では、一般的なゲートキーパーの設定を示しています。
例1-1 H.225 ゲートキーパー制御トランクに対する一般的なゲートウェイ設定
ここでは、例1-1 について説明します。
• zone local コマンドを使用して、ゲートキーパー ゾーンを作成しています。設定済みのゾーンには、各 Cisco CallManager およびゲートウェイが登録されます。
• ゾーン間のコール ルーティングには、 zone prefix が使用されています。
• bandwidth interzone コマンドは、ゾーン間で利用できる帯域幅の量を割り当てます。
• gw-type-prefix 1# default technology コマンドは、ゾーン内で解決されないコールを登録済みテクノロジー プレフィックス 1# にルーティングします。この設定では、Cisco CallManager トランクが該当します。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
インタークラスタ ゲートキーパー制御トランク
インタークラスタ ゲートキーパー制御トランクは、Cisco CallManager が H.323 ゲートキーパーに登録済みの他の Cisco CallManager クラスタ間との通信を行うようにします。シスコは、分散コール処理環境ではインタークラスタ ゲートキーパー制御トランクを使用することをお勧めします。
インタークラスタ ゲートキーパー制御トランクを使用する場合は、次のガイドラインに従ってください。
• 各 Cisco CallManager クラスタのゲートウェイは、同じ方法で設定します。
• 各 Cisco CallManager クラスタへのインタークラスタ ゲートキーパー制御トランクの設定は、同じ方法で行います。
• クラスタ内の各 Cisco CallManager は、インタークラスタ ゲートキーパー制御 トランクをゲートキーパーに登録します。
• コールは、Cisco CallManager クラスタ内に登録済みのトランク間にロードバランスされます。
• Cisco CallManager は、複数のゲートキーパーおよびトランクをサポートします。
• 各 Cisco CallManager クラスタに対するゲートキーパーのゾーンは、個別に設定します。
• bandwidth interzone コマンドをゲートキーパーに使用して、そのゲートキーパーに登録済みの Cisco CallManager クラスタおよび H.323 デバイス間の帯域幅の制御を直接行います（コーデック タイプ別の帯域幅の設定については、 表 1-1 を参照してください）。
• 単一 Cisco IOS ゲートキーパーは、100 台までの Cisco CallManager クラスタをサポートします。
• ゲートキーパーの冗長性は、ゲートキーパー クラスタリング（代替ゲートキーパー）または Cisco HSRP（Hot Standby Router Protocol）を使用すると実装することができます。HSRP は、ソフトウェア フィーチャ セットにゲートキーパー クラスタリングが利用できない場合に限り使用します。
例1-2では、一般的なゲートキーパーの設定を示しています。
例1-2 インタークラスタ ゲートキーパー制御トランクに対する一般的なゲートキーパー設定
ここでは、例1-2 について説明します。
• zone local コマンドを使用して、ゲートキーパー ゾーンを作成しています。各 Cisco CallManager は、インタークラスタ ゲートキーパー制御トランクをその設定済みゾーンに登録しています。
• ゾーン間のコール ルーティングには、 zone prefix が使用されています。
• bandwidth interzone コマンドは、ゾーン間で利用できる帯域幅の量を割り当てます。
• gw-type-prefix 1# default technology コマンドは、ゾーン内で解決されないコールを登録済みテクノロジー プレフィックス 1# にルーティングします。この設定では、Cisco CallManager トランクが該当します。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
ロケーションを使用したインタークラスタ ゲートキーパー制御トランク
一般的に、集中型および分散型のコール処理環境で使用できるコール アドミッション制御メカニズムはハブアンドスポーク トポロジーに限定されます。ハブアンドスポーク トポロジーを使用していないコール アドミッション制御の配置には、図 1-4に示されているようにロケーションおよびゲートキーパー メカニズムを組み合せて対応します。
図 1-4 コール アドミッション制御にロケーションおよびゲートキーパーを組み合せる方式
コール アドミッション制御にインタークラスタ ゲートキーパー制御トランクとロケーションを組み合せる場合は、次に示すガイドラインに従ってください。
• ローカル Cisco CallManager を使用していないサイトには、ロケーション ベースのコール アドミッション制御を使用します。
• Cisco CallManager クラスタ間にはゲートキーパー ベースのコール アドミッション制御を使用します。
• ローカル Cisco CallManager を使用していない各サイトには、そのサイトをサポートしているCisco CallManager クラスタ内にロケーションを設定します。
• 各サイトの帯域幅の上限を、そのサイトに使用されているコーデックのタイプに応じて、適切に設定します（帯域幅の設定については、 表 1-1 を参照してください）。
• Cisco CallManager を使用して設定される各デバイスをロケーションに割り当てます。あるデバイスを別のロケーションに移した場合、ロケーションの設定も変更します。
• Cisco CallManager は、ロケーションを 500 個所までサポートします。
• 各 Cisco CallManager は、インタークラスタ ゲートキーパー制御トランクをゲートキーパーに登録します。
• 各 Cisco CallManager クラスタのゲートウェイは、同じ方法で設定します。
• 各 Cisco CallManager クラスタへのインタークラスタ ゲートキーパー制御トランクは、同じ方法で設定します。
• コールは、Cisco CallManager クラスタ内に登録済みのトランク間にロードバランスされます。
• Cisco CallManager は、複数のゲートキーパーおよびトランクをサポートします。
• 各 Cisco CallManager クラスタに対するゲートキーパーのゾーンは、個別に設定します。
• bandwidth interzone コマンドをゲートキーパーに使用して、そのゲートキーパーに登録済みの Cisco CallManager クラスタおよび H.323 デバイス間の帯域幅の制御を直接行います（コーデック タイプ別の帯域幅の設定については、 表 1-1 を参照してください）。
• 単一 Cisco IOS ゲートウェイキーパーは、100 台までの Cisco CallManager クラスタをサポートします。
• ゲートキーパーの冗長性は、ゲートキーパー クラスタリング（代替ゲートキーパー）または Cisco HSRP（Hot Standby Router Protocol）を使用すると実装することができます。HSRP は、ソフトウェア フィーチャ セットにゲートキーパー クラスタリングが利用可能ではない場合に限り使用します。
例1-3では、一般的なゲートキーパーの設定を示しています。
例1-3 ロケーションを使用するインタークラスタ ゲートキーパー制御トランクに対する一般的なゲートキーパー設定
ここでは、例1-3 について説明します。
• zone local コマンドを使用して、ゲートキーパー ゾーンを作成しています。各 Cisco CallManager は、インタークラスタ ゲートキーパー制御トランクをその設定済みゾーンに登録しています。
• ゾーン間のコール ルーティングには、 zone prefix が使用されています。必要な場合は、同一ゾーンに対して複数のゾーン プレフィックスを設定します。
• bandwidth interzone コマンドは、ゾーン間で利用できる帯域幅の量を割り当てます。
• gw-type-prefix 1# default technology コマンドは、ゾーン内で解決されないコールを登録済みテクノロジー プレフィックス 1# にルーティングします。この設定では、Cisco CallManager トランクが該当します。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
IP WAN を介したクラスタ化
QoS 機能に対応している IP WAN によって相互接続される複数サイト間で、単一の Cisco
CallManager クラスタを配置できます。ここでは、WAN を介したクラスタ化の概要を簡潔に説明します。詳細は、「コール処理」を参照してください。
WAN を介したクラスタ化では、次の 2 種類の配置方法がサポートされます。
ローカル フェールオーバーでは、Cisco CallManager サブスクライバ サーバとバックアップ サーバを同じサイトに配置し、これらのサーバ間に WAN を置かないことが必要です。この配置モデルは、Cisco CallManager サーバを備えた 2 つまたは 3 つのサイトがあり、サイトごとにそれぞれ最大 5,000 台または 2,500 台の IP フォンがある場合に理想的です。この配置モデルでは、2 サイト構成では最大 10,000 台の IP フォン、3 サイト構成では 7,500 台の IP フォンを収容することが可能です。
リモート フェールオーバーでは、WAN を介してバックアップ サーバを配置できます。この配置モデルを使用すると、Cisco CallManager サブスクライバ サーバを備えた最大 6 つのサイト、および Cisco CallManager バックアップ サーバを備えた 1 つまたは 2 つのサイトが可能です。この配置モデルでは、サイトの構成に合わせて最大 10,000 台の IP フォンを共有できます。
ローカル フェールオーバー配置モデル
ローカル フェールオーバー配置モデルは、WAN を介したクラスタ化に対する最大の復元力があります。このモデルの各サイトには、少なくとも 1 つのプライマリ Cisco CallManager サブスクライバと 1 つのバックアップ サブスクライバがあります。この設定では、サイトごとに 5,000 台の IP フォンを備えた 2 サイト構成の配置、またはサイトごとに 2,500 台の IP フォンを備えた 3 サイト構成の配置のどちらかが可能です（図 1-5 を参照）。
図 1-5 2 サイト構成のローカル フェールオーバー モデル
要約すると、リモート フェールオーバー モデルを実装する場合は、次のガイドラインに従ってください。
• 少なくとも 1 つのプライマリ Cisco CallManager サブスクライバと 1 つのバックアップ サブスクライバを含むように、各サイトを設定します。
• Cisco CallManager のグループとデバイス プールを設定して、サイト内のデバイスが、あらゆる状況でそのサイトのサーバだけに登録されるようにします。
• 各サイトで主要なサービス（TFTP、DNS、DHCP、LDAP、および IP フォン サービス）、すべてのメディア リソース（コンファレンス ブリッジと Music On Hold）、およびゲートウェイを複製します。複製を確実に行い、最大レベルの復元力を得るよう、シスコは強くお勧めします。また、この方法を拡張して、各サイトに音声メール システムを組み込むこともできます。WAN に障害が発生している場合、パブリッシャ データベースへのアクセスがないサイトでは、いくつかの機能が使用できないことがあります。
• クラスタ内の 10,000 回の Busy Hour Call Attempt（BHCA）ごとに、Intra-Cluster Communication Signaling（ICCS）に 900 kbps の帯域幅が必要です。これは、帯域幅の最小必要量であり、帯域幅は、900 kbps の倍数で割り当てられます。
• リアルタイム ICCS 帯域幅に加えて、SQL、CTI Manager、および LDAP トラフィックにはイントラクラスタ帯域幅も必要です。帯域幅を追加する量は、システムの使用方法に応じて異なります。たとえば、エクステンション モビリティを使用すると、サーバ間の SQL トラフィック量が増えます。
• Cisco CallManager クラスタ内の任意の 2 つのサーバ間では、最大ラウンドトリップ時間（RTT）として 40 ms が可能です。この時間は、単方向で最大 20 ms の遅延、または理想的な条件下での約 1860 マイル（3000 km）の伝送距離に相当します。
• ローカル フェールオーバー モデルには、Cisco CallManager リリース 3.1 またはそれ以降が必要です。
リモート フェールオーバー配置モデル
リモート フェールオーバー配置モデルでは、バックアップ サーバを柔軟に配置できます。各サイトには、少なくとも 1 つのプライマリ Cisco CallManager サブスクライバを含め、バックアップ サブスクライバを必要に応じて配置します。この配置モデルでは、3 ～ 6 つのサイト構成が可能になり、IP フォンやその他のデバイスは、通常、最大 4 つのサーバに登録されます（図 1-6 を参照）。
図 1-6 4 サイト構成のリモート フェールオーバー モデル
要約すると、リモート フェールオーバー モデルを実装する場合は、次のガイドラインに従ってください。
• 少なくとも 1 つのプライマリ Cisco CallManager サブスクライバと、必要に応じてオプションのバックアップ サブスクライバを含むように、各サイトを設定します。
• Cisco CallManager のグループとデバイス プールを設定して、WAN 上のサーバにデバイスを登録できるようにします。
• IP フォンを備えた各サイトで、主要なサービス（TFTP、DNS、DHCP、LDAP、および IP フォン サービス）、すべてのメディア リソース（コンファレンス ブリッジおよび Music On Hold）、およびゲートウェイを複製します。複製を確実に行い、最大レベルの復元力を得るよう、シスコは強くお勧めします。また、この方法を拡張して、各サイトに音声メール システムを組み込むこともできます。WAN に障害が発生している場合、パブリッシャ データベースへのアクセスがないサイトでは、いくつかの機能を使用できないことがあります。
• クラスタ内の 10,000 回の Busy Hour Call Attempt（BHCA）ごとに、Intra-Cluster Communication Signaling（ICCS）に 900 kbps の帯域幅が必要です。これは、帯域幅の最小必要量であり、帯域幅は、900 kbps の倍数で割り当てられます。
• リアルタイム ICCS 帯域幅に加えて、SQL、CTI Manager、および LDAP トラフィックにはイントラクラスタ帯域幅も必要です。帯域幅を追加する量は、システムの使用方法に応じて異なります。たとえば、エクステンション モビリティを使用すると、サーバ間の SQL トラフィック量が増えます。
• デバイスが、WAN を介して同じクラスタ内のリモート Cisco CallManager サーバに登録される場合、Signalling または Control Plane トラフィックには帯域幅を追加する必要があります。
• Cisco CallManager クラスタ内の任意の 2 つのサーバ間では、最大ラウンドトリップ時間（RTT）として 40 ms が可能です。この時間は、単方向で最大 20 ms の遅延、または理想的な条件下での約 1860 マイル（3000 km）の伝送距離に相当します。
• リモート フェールオーバー モデルには、Cisco CallManager リリース 3.1 またはそれ以降が必要です。
IP WAN を介するクラスタリングに対するコール アドミッション制御
サイト間を接続する WAN 全体にコールが許されている場合は、そのサイト間には、他のサイトに対するデフォルト ロケーションに加えて、Cisco CallManager ロケーションを設定し、コール アドミッション制御を配置する必要があります。デバイス数に対して帯域幅が余分にプロビジョニングされている場合でも、ロケーションに基づくコール アドミッション制御を設定するのが最良の方法です。
マルチ サイト MPLS WAN に関する考慮事項
この項では、MPLS（Multiprotocol Label Switching）WAN をマルチ サイトに配置するために、コール アドミッション制御メカニズムを調整する方法を説明します。
従来のレイヤ 2 WAN テクノロジーと MPLS のデザイン上の大きな違いは、MPLS WAN はハブアンドスポーク トポロジーに準拠していないということです。すべてのサイト間の接続にはフルメッシュ 接続方式を採用します。このトポロジー上の違いにより、コール アドミッション制御に適用すべきメカニズムに関して影響を与えます。
単純集中型配置
単一クラスタ集中コール処理配置では、コール アドミッション制御機能は Cisco CallManager 内のロケーション構成により実行されます。
ハブアンドスポーク WAN トポロジー（フレーム リレー、ATM など）では、事業所サイトとのリンクはすべて、中央サイトで終端します。フレーム リレーを例にすると、事業所ルータからのすべての PVC（Permanent Virtual Circuits; 相手先固定接続）は、中央サイトのヘッドエンド ルータに集約されています。この例では、帯域幅に対する課金は WAN リンクの事業所エンドで行われているので、中央サイドではデバイスにコール アドミッション制御を適用する必要はありません。したがって、Cisco CallManager Locations の設定では中央サイトのデバイスのロケーションは <None> のままにしておきます。一方、各事業所のデバイスは適切なコール アドミッション制御を受けるために各事業所のロケーションに指定される必要があります。
MPLS WAN ネットワークでは、すべての事業所はレイヤ 3 で隣接していると見なされるため、中央サイトに接続する必要はありません。図 1-7では、スポークツースポーク配置による 2 つの事業所間のコールを説明しています。
図 1-7 MPLS 配置におけるスポークツースポーク コール
また、MPLS WAN では、中央サイト WAN に接続しているリンクは事業所の WAN リンクに集約していません。中央サイトに存在するすべてのデバイスは、個々のデバイスに対応するコール アドミッション制御ロケーション（したがって、<None> ロケーションではありません）に指定されています。したがって、このスポークツースポーク設定では事業所のリンクとは無関係に、コール アドミッション制御は中央サイト リンク上で実行される必要があります（図 1-8 を参照）。
特定サイトに許されている帯域幅がすべて消費されてしまっている場合は、Cisco CallManager が備えている Automated Alternate Routing（AAR）機能を使用して、PSTN へ自動的にフェールオーバーさせることができます。
単純分散配置
各サイトに Cisco CallManager クラスタが設定されていて、どのサイト間も MPLS WAN でリンクされているマルチ サイト配置の場合は、ゲートキーパーがサイト間のコール アドミッション制御を行い、個々のサイトを異なるゲートキーパー ゾーンに格納します。この同様のメカニズムは、レイヤ 2 WAN テクノロジーをべースにしたハブアンドスポークトポロジーにも適用されています（図 1-9 を参照）。
図 1-9 MPLS を使用した分散配置におけるゲートキーパー コール アドミッション制御
特定サイトに許されている帯域幅がすべて消費されてしまっている場合は、各クラスタからゲートキーパーへ接続する際のルート パターンが指定されているルート リストおよびルート グループ コンストラクトを使用して、PSTN へ自動的にフェールオーバーさせることができます。
集中型および分散型複合配置
集中型および分散型コール処理を複合的に配置しているマルチ サイト モデルでは、MPLS WAN はインタークラスタ間のコールに対して新しい展開を意味します。
異なるクラスタに属している事業所間にコールが発生した場合は、音声パスはその事業所間で直接確立できるので、事業所のクラスタから中央サイトへメディアを転送する必要はありません。したがって、コール アドミッション制御は各事業所の WAN リンクに必要なだけです（図 1-10 を参照）。
図 1-10 インタークラスタ トランク（ICT）によるマルチ クラスタ接続
単純集中配置で見られるように、メディアを各サイトで終端するデバイス（各クラスタに対する中央サイトを含む）は、適切に設定されているロケーションに指定されている必要があります。
インタークラスタ トランクで重要なことは、これは単なるシグナリング デバイスであって、インタークラスタ トランク間のメディアを転送する役目をもたないということです。したがって、インタークラスタ トランクのロケーションの指定は、<None>のままにしておきます。
この方式の配置では、クラスタ間のダイヤル プランの解決にゲートキーパーを使用することもできますが、コール アドミッション制御にはゲートキーパーを使用しないことをお勧めします。
特定のサイトに許されている帯域幅を消費してしまっている場合は、異なる 2 つの方式を組み合せて、PSTN へ自動的にフェールオーバーすることができます。
• マルチ Cisco CallManager クラスタに対するコールには、ルート リストおよびルートグループ コンストラクトで対応
• Cisco CallManager クラスタ内のコールには、Automated Alternate Routing（AAR）機能で対応
U. S. Section 508 準拠についての設計上の考慮事項
どの配置モデルを選択するかにかかわらず、IP テレフォニー ネットワークを設計する場合は、障害者の方が利用しやすいテレフォニー機能になるように、Telecommunications Act Section 255 電気通信法および U.S. Section 508 に定める基準に準拠する必要があります。
IP テレフォニー ネットワークを構成する際は、次に説明する基本設計ガイドラインに従い、Section 508 を遵守してください。
• ネットワーク上の Quality of Service（QoS）を使用可能にします。
• ターミナル テレタイプ（TTY）デバイスまたは Telephone Device for the Deaf（TDD）に接続する電話には、G.711 コーデックのみを設定します。G.729 のような低ビット レートのコーデックを音声通信に適用している場合でも、Total Character Error Rate（TCER）が 1% を超えている場合は、TTY/TDD デバイスが適切に作動しないことがあります。
• 必要に応じて、TTY/TDD デバイスに G.711 を設定し、WAN に対応します。
• Echo Cancellation を使用可能（ON）にし、パフォーマンスを最適化します。
• Voice Activity Detection（VAD）は、TTY/TDD 接続に影響を与えるため使用されることはありません。したがって、設定は使用可能、使用不可のどちらであっても関係ありません。
• Cisco CallManager 内の regions および device pools を適切に設定して、TTY/TDD デバイスが常時 G.711 コードを使用するようにします。
• TTY/TDD の IP テレフォニー ネットワークへの接続は、次のいずれかの方法で行います。
RJ-11 アナログ回線用 TTY/TDD を直接 Cisco FXS ポートに接続します。FXS ポートはすべてのタイプで作動します。たとえば、Cisco VG 248 上の Cisco IP Phone 7900 Series、Catalyst 6000、Cisco ATA 186/188 モジュール、および FXS ポートを備えている他の Cisco ボイス ゲートウェイがあります。シスコは、この接続方式をお勧めします。
IP フォンのハンドセットをTTY/TDD に接続しているカップリング機器に置きます。アコースティック カップルは、RJ-11 接続に比較すると信頼性が劣ります。カップリング方式は部屋の周囲の雑音やその他の要素で、一般的に通信エラーを起こしやすい方式です。
• 途切れるようなダイヤル操作でもサポートする必要がある場合は、アナログ電話をCisco VG 248 および ATA 186/188 上に備えている FXS ポートに接続します。
フィードバック