Cisco IP テレフォニー ネットワーク デザイン ガイド
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月2日
章のタイトル： 分散型コール処理を行う複数サ イト WAN
分散型コール処理を行う複数サイト WAN
この章では、Cisco CallManager を分散型コール処理に使用する、複数サイト WAN システムを設計するためのガイドラインを記述します。ここでは、分散型コール処理モデルに固有の問題について、このマニュアルの他のセクションに記載されている関係資料を参照して、詳しく説明します。
•
「Cisco CallManager クラスタ の考慮事項」
分散型コール処理モデル
分散型コール処理システム（図 6-1を参照）では、各サイトに、独自の
Cisco CallManager、音声メッセージ処理、およびデジタル信号プロセッサ（DSP）のリソースがあります。
Cisco CallManager Release 3.0(1) では、最初の分散型コール処理モデルは、IP WAN を介してネットワーク接続された 10 までのサイトをサポートしました。
Cisco CallManager Release 3.0(5) では、分散型コール処理のサポートは、100 サイトまで拡大されました。サイトの音声コールは、IP WAN をプライマリ パスとして使用できます。また、IP WAN が停止した場合、あるいは IP WAN に追加コールを処理するための十分なリソースがない場合、PSTN をセカンダリ パスとして使用できます。コールが、IP WAN あるいは PSTN のいずれを使用するかは、コールの発信側とコールの着信側のいずれに対しても透過です。
この配備モデルの主要な利点は、ローカル コール処理により、IP WAN を使用できるかどうかにかかわらず、同じレベルの機能と能力を提供することです。各サイトは、ユーザ数に応じて、1 台から 8 台までの Cisco CallManager サーバを 1 つのクラスタにもてます。これは、ユーザ数が 50 人以上いるサイトには優れた配備モデルであり、各サイトは、10,000 人のユーザまでサポートできます。さらに、IP WAN が停止しても、サービスの停止はありません。
コール アドミッション制御
コール アドミッション制御は、新しいコールに QoS を保証するとともに、確立したコールへの QoS を提供し続けるメカニズムです。確立したコールへの QoS は、新しいコールが確立される前に、コールごとにネットワーク リソースが使用できることを確認することによって、保証されます。
コンバージされたネットワークのパラダイムでは、すべてのトラフィック（音声、ビデオ、およびデータ）が、共通の IP 対応のインフラストラクチャ上を移動します。このようにトラフィック タイプが混じり合っているため、ネットワークは、パケットの欠落、遅延、およびジッタに関するトラフィック タイプごとの要件を処理できる必要があります。このような環境では、次の 2 つの主要なタスクが重要性を増します。
• 1 つのトラフィック タイプに他のトラフィック タイプより高い優先順位を付与
• 音声あるいはビデオのようなリアルタイムのトラフィックを、ネットワーク帯域幅の過剰な使用予約から保護
最初のタスクは、第 8 章「QoS」で説明する QoS により効果的に処理されます。
2 番目のタスクは、コール アドミッション制御メカニズムで実現されます。IP テレフォニー ネットワークでのコール アドミッション制御の必要性は、すべての IP 電話が WAN へのオープン IP パスをもつ一方で、それとは反対に、トール バイパス ネットワークは、WAN を通過するコールを開始できる物理的トランクの数を制限できるという事情によって、大幅に拡大しています。図 6-2は、コール アドミッション制御の必要性を示しています。
分散型コール処理システムに対しては、H.323 ゲートキーパーを使用してコール アドミッション制御を実装できます。この設計では、Cisco CallManager を、Multimedia Conference Manager（MCM）、または Voice over IP（VoIP）ゲートウェイと呼ばれている Cisco IOS ゲートキーパーに登録して、IP WAN コールを実行するたびに、そのゲートキーパーに問い合わせを行います。Cisco IOS ゲートキーパーは、特定の帯域幅制限をもつゾーンに、おのおのの Cico CallManager を関連付けます。このようにして、Cisco IOS ゲートキーパーは、ゾーン内あるいはゾーン外の IP WAN 音声コールが消費する帯域幅の最大量を制限できます。
簡潔に述べると、Cisco CallManager は、IP WAN コールを開始する場合、最初にゲートキーパーからの許可を要求するということです。ゲートキーパーが許可を与えると、そのコールは IP WAN を介して開始されます。ゲートキーパーが要求を拒否したときは、Cisco CallManager は、セカンダリ パスの PSTN を経由してコールを開始します。
これは、事実上、アドミッション制御を行うコール アカウンティングの方法であり、この方法では、ゲートキーパーは、IP WAN コールが消費する帯域幅を追跡し続けるだけです。ゾーンに対して帯域幅の最大値を設定する場合は、音声トラフィックが WAN リンクの 75% 以上を消費しないようにする制限を考慮する必要があります。図 6-3は、このコール アドミッション制御メカニズムが使用するプロセスを示しています。
（注） この方式では、IP 電話をサイト間で移動させることはできません。IP 電話を WAN 上に登録しても、コール アドミッション制御は指示どおりに動作しません。
図 6-3 ゲートキーパーを使用したコール アドミッション制御
複数サイト WAN の配備では、サイト間の音声トラフィックを可能にするダイナミック コール ルーティングを設定し、IP WAN をプライマリ パスとして使用し、IP WAN が停止するか、あるいは追加音声コールを処理する十分なリソースが IP WAN にない場合は、PSTN をセカンダリ パスとして使用することが目標です。図 6-4は、このタイプのダイナミック コール ルーティングを示しています。
このモデルでは、IP WAN が停止している、あるいは IP WAN に追加コールを処理できる十分なリソースがないことを検出できることが重要で、検出できれば、必要なときだけ PSTN を介してコールが送信されます。このタイプのダイナミック ルーティングは、コールに掛かるコストを削減するとともに、コール アドミッション制御がこのソリューションにもたらす利点になります。IP WAN 上でのコールの開始時期、およびゲートキーパーがそのコールを拒否した時の対応を最終的に決定するのは、ダイヤル プランです。そのため、この場合は、ダイヤル プランをゲートキーパーのコール アドミッション制御メカニズムに緊密に連携させます。ダイヤル プランについては、「ダイヤル プランの考慮事項」で説明します。
前述したように、H.323 ゲートキーパーを使用して、指定したゾーン内あるいはゾーン外で許可されるコール数を制限し、コール アドミッション制御を実現できます。つまり、各サイトを特定のゾーンに関連付けできるため、サイト別に帯域幅の量を効果的に制限できます。これが、Cisco CallManager がゲートキーパーを使用して、コール アドミッション制御をハブアンドスポーク トポロジで実行するモデルです。
コール アドミッション制御に加え、ゲートキーパーが実行する 2 番目に重要な機能が、アドレス解決です。Cisco CallManager は、どのサイトにおいても自身が制御する内線範囲を認識し、コールをこれらの内線にルーティングできます。その範囲外のいずれかに対しては、Cisco CallManager はゲートキーパーに進むことができます。このゲートキーパーは、この Cisco CallManager がコールを送信すべき別の Cisco CallManager の IP アドレスを戻します。このことが可能となるのは、各 Cisco CallManager（あるいは、クラスタ内の 1 つの Cisco CallManager）が、その特定のクラスタによって維持されているアドレス範囲で静的に設定されている、ゲートキーパーに登録されているからです。
このアドレス解決機能は、複数サイトの分散型コール処理環境でのダイヤル プランを大幅に簡素化します。「ダイヤル プランの考慮事項」で、アドレス解決について詳しく説明します。
要約すると、コール アドミッション制御、および E.164 アドレス 解決で使用する Cisco CallManager の機能は、次のとおりです。
• 複数サイトの分散型コール処理環境で 100 サイトまでのサポート
• クラスタ間コールのアドレス解決に対するゲートキーパーの機能であり、結果として、ダイヤル プランを簡素化する機能
• G.711 コールに対して 128 Kbps の帯域幅、および G.729 コールに対して 20 Kbps の帯域幅の、Cisco CallManager による要求
• 圧縮リアルタイム転送プロトコル（cRTP）は、コール アドミッション要求（ARQ）の帯域幅計算に組み入れない。
運用モデル
コール アドミッション制御のゲートキーパー方式は、次の 2 つを設定します。
• ゲートキーパーの設定。これは、ネットワーク管理者が、ゲートキーパーとして作動する Cisco IOS の Multimedia Conference Manager を設定するものです。推奨プラットフォームとして、Cisco IOS Release 12.1(3)T、あるいはそれ以上が稼働する Cisco 2600、3600、あるいは 7200 のルータがあります。
ゲートキーパーとして選択するプラットフォームの基準は、登録数および 1 秒当りのコール数に応じて異なります。おおよそのガイドとして、表 6-1に記載されているプラットフォームの性能値を使用できます。
• Cisco CallManager 設定。各 Cisco Callmanager、あるいは Cisco CallManager クラスタを単一の VoIP ゲートウェイとしてのゲートキーパに登録する必要があります。
|
|
|
1 秒当りの最大コール数 |
|---|---|---|
ゲートキーパーの設定
次のゲートキーパーの設定では、4 つのゾーンを定義します。それぞれのゾーンには、ゲートウェイとして登録可能な 2 つの Cisco CallManager（3 つの
Cisco CallManager を含むゾーン SJC1 を除く）を持つ、1 つのクラスタが含まれます。
Cisco CallManager の設定
図 6-5は、Cisco CallManager を VoIP ゲートウェイとしてゲートキーパーに関連付けできる、Cisco CallManager の設定画面を示しています。
図 6-5 ゲートキーパーと通信するための Cisco CallManager の設定
Cisco CallManager とゲートキーパー間の対話
Cisco CallManager は、登録要求（RRQ）を送信して、自身を単一の VoIP ゲートウェイとして登録します。現在、Cisco IOS Mutimedia Conference Manager（MCM）は、RRQ 内の E.164 アドレス範囲を受容できませんが、「ゲートキーパーの設定」で示したように、ユーザは、ゲートキーパー上でアドレス範囲を静的に設定できます。図 6-6は、Cisco CallManager とゲートキーパー間の通信ストリームを示しています。
図 6-6 ゲートキーパーと通信する Cisco CallManager
フェールオーバーとバックアップのために、クラスタ内の複数の
Cisco CallManager をゲートキーパーに登録できます。ゲートキーパーを
Cisco CallManager グループに割り当てて、そのグループ内でプライマリ、およびバックアップとして使用する Cisco CallManager を定義できます。プライマリの Cisco CallManager が、ゲートキーパーとの通信に失敗すると、ゲートキーパーは、その登録を削除し、グループ内のセカンダリ Cisco CallManager との通信を確立します。
ゲートキーパーは、Cisco CallManager から RRQ を受信すると、登録確認（RSC）を発行して、その Cisco CallManager を自身の登録デバイス リストに追加します。ゲートキーパーは、自身に登録されたすべての Cisco CallManager を認識しています。また、Cisco IOS 設定により、ゲートキーパーは、Cisco CallManager が属するゾーン、および各ゾーンに関連付けられた帯域幅の量を認識しています。
特定の Cisco CallManager がゲートキーパーに登録されていることを確認するには、次の Cisco IOS show コマンドを使用します。
MS-2621-3A#show gatekeeper endpoint
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type F
--------------- ----- --------------- - ---- --------- ---- --
10.122.1.17 1720 10.122.1.17 1710 zone1 VOIP-GW
10.122.1.19 1720 10.122.1.19 1710 zone2 VOIP-GW
10.122.1.20 1720 10.122.1.20 1710 zone3 VOIP-GW
Total number of active registrations = 3
Cisco CallManager は一度登録されると、発信コールを行う前に、あるいは受信コールを受け取る前に、常にゲートキーパーとの間で照合を行います。Cisco CallManager は、図 6-7で示したように、許可要求（ARQ）をゲートキーパーに対して発行して、この照合を実行します。Cisco CallManager は、ARQ の一部として、コールに使用されるコーデックのタイプに応じて、専用の帯域幅も要求します。Cisco CallManager は、コールが G.711 コーデックを使用している場合は 128 Kbps、G.729 コーデックを使用している場合は、20 Kbps を要求します。
ゲートキーパーは、Cisco CallManager からの要求を受けると自身の設定をチェックして、その Cisco CallManager が割り当てられているゾーン内で使用できる帯域幅の量を判断します。また、現在すでにそのゾーンに送信されつつある、あるいはゾーンから発信されつつあるコール数もチェックします。帯域幅が使用できる場合、ゲートウェイは許可確認（ACF）を発行して、Cisco CallManager がコールを完了できるようにします。帯域幅が使用できない場合、ゲートキーパーは、許可拒否（ARJ）を発行して、コールの実行を阻止し、発信者が使用中のトーンを受けるようにします。
図 6-8で示したように、ローカル Cisco CallManager は、ゲートキーパーを介してリモート Cisco CallManager から着信コールを受けると、次のような作業を実行します。
• ローカル Cisco CallManager は、着信コールの H.225 設定情報にある E.164 アドレスを使用して、そのルート パターンが一致するか否かを探索します。ルート パターンが一致すると、ローカル Cisco CallManager は、着信コールが正当なデバイスからのものかどうか、そして、着信コールに必要な帯域幅の量（コーデックのタイプ）を判断でるようになります。
• 着信コールを受信する前に、ARQ をゲートキーパーに送信して、必要な帯域幅を要求します。
ゲートキーパーの使用に関する考慮事項
ゲートキーパー ベースのコール アドミッション制御を使用するときは、次の事項が適用されます。
• ゲートキーパーは、Cisco IOS MCM となります。推奨プラットフォームは、Cisco IOS Release 12.1(3)T、あるいはそれ以上が稼働する Cisco 2600、3600、あるいは 7200 です。
• 2 つのゲートキーパーを冗長性をもたせるように使用して、プライマリが故障した場合、セカンダリのゲートキーパーが、既存コールを認識することなく、プライマリとなります。この場合、新しいプライマリ ゲートキーパーが、認識しない既存コールに加えて過多の新しいコールを許可すると、その結果、品質の低下を引き起こす可能性があります。この状況は短期間であり、既存のコールが終了すれば解決します。
• サイト間でデバイスを移動することは、新しい番号をそのデバイスに割り当て、デバイスがコール処理にローカル Cisco CallManager を使用するようにしない限り、できません。
ダイヤル プランの考慮事項
Cisco CallManager Release 3.0(5) の新しい機能は、ゲートキーパーが、
Cisco CallManager クラスタ間のダイヤル プランを解決する能力をもつことです。前のリリースでは、Cisco CallManager だけがクラスタ間のダイヤル プランを解決できました。Cisco CallManager Release 3.0(5) では、現在、クラスタ間コールの宛先を解決するために、次の 3 つの配備モデルがあります。
• Cisco CallManager ダイヤル プラン モデル（図 6-9を参照）
• ゲートキーパー ダイヤル プラン モデル（図 6-10を参照）
Cisco CallManager ダイヤル プラン モデルでは、すべての Cisco CallManager クラスタが、クラスタ間トランク、および他の各クラスタに対するルート パターンをもつ必要があります。管理オーバーヘッドは、クラスタ数の増加に伴い指数関数的に増えます。このモデルでは、ゲートキーパーはコール アドミッション制御だけを提供し、ダイヤル プラン解決を提供しません。このモデルは、今日、従来の PBX で使用されている標準モデルに非常によく似ています。
ゲートキーパー ダイヤル プランのモデルは、ハイブリッド形式であっても、設定と管理のオーバーヘッドを大幅に削減します。このモデルでは、
各 Cisco CallManager には、番号非通知デバイスと呼ばれる、クラスタ間トランクが 1 つだけあります。
このデバイスを、ポイントツーマルチポイント トランクとして考えることができます。このトランクは、Cisco CallManager ダイヤル プラン モデルにおいて、ポイントツーポイントのトランクをメッシュ化する必要性をなくします。番号非通知デバイスは、ゲートキーパーを使用して、コールを正しい Cisco CallManager クラスタにルーティングします。PSTN に対する自動オーバーフロー、あるいはフェールオーバーの要求がない場合、各クラスタのダイヤル プランを簡素化して、次の 2 つのルート パターンだけにすることができます。1 つがクラスタ間コール用、そしてもう 1 つが、PSTN アクセス用のルート パターンです。このモデルでは、ゲートキーパーにダイヤル プランを設定し、その結果、管理の中央ポイントを設けます。新しいクラスタを追加したときは、すべての
Cisco CallManager の代わりにゲートキーパーだけをアップデートします。
要約すると、3 つのダイヤル プランのモデルは、次の機能と能力を提供します。
• Cisco CallManager ダイヤル プラン モデル（「Cisco CallManager を使用したコールのルーティング」を参照）
–コール アドミッション制御専用ゲートキーパーを使用した、PSTN への自動オーバーフローとフェールオーバー
–2 つの Cisco CallManager クラスの組み合わせごとに、個別のクラスタ間トランクが必要
–Cisco CallManager の宛先ごとに、IP WAN 用と PSTN 用の 2 つのルートが必要
–新しいクラスタを追加、あるいはダイヤル プランを変更した場合、すべての Cisco CallManager の再設定が必要
–コール アドミッション制御用ゲートキーパー、およびクラスタ間ダイヤル プランを使用した、PSTN への自動オーバーフローとフェールオーバー
–各 Cisco CallManager クラスタには、1 つの番号非通知デバイスだけが必要
–Cisco CallManager の宛先ごとに、IP WAN 用と PSTN 用の 2 つのルートが必要
–ゲートキーパーと Cisco CallManager の両方にクラスタ間ダイヤル プランを設定
• ゲートキーパー ダイヤル プラン モデル（「ゲートキーパーを使用したコールのルーティング」を参照）
–コール アドミッション制御用ゲートキーパー、およびクラスタ間ダイヤルを使用した、PSTN へのマニュアル オーバーフローとフェールオーバー
–各 Cisco CallManager クラスタには、1 つの番号非通知デバイスだけが必要
–すべてのロケーションに対するクラスタ間コール用、および PSTN アクセス用の 2 つのルート プランが必要
–ダイヤル プランをゲートキーパー（すべての Cisco CallManager にはない）に設定して、クラスタ間コールをルーティング
–IP WAN が停止中、あるいは使用中の場合、ユーザが正しい PSTN 番号をダイヤルして、リモート サイトへアクセスする必要あり
Cisco CallManager を使用したコールのルーティング
図 6-9で示した例では、ユーザは、内部コールに 5 桁、そして IP WAN を介したサイト間コールに 7 桁をダイヤルします。IP WAN が停止している場合、あるいはリソースが不足している場合、サイト間コールに対して PSTN が透過的に使用されます。PSTN へ送信される長距離コールでは、ユーザが、アクセス コード 9 に続けて 1+ エリア コード、そして 7 桁の番号をダイヤルします。 ユーザがローカル PSTN コールをダイヤルする場合は、9 の次に 7 桁の番号をダイヤルします。このモデルでは、PSTN に対するゲートウェイ障害、あるいはトランク障害のときに、ゲートウェイの冗長性も提供します。PSTN ゲートウェイは、H.323 を使用する Cisco IOS ゲートウェイです。
（注） このセクションでは、最初の選択肢として IP WAN の通過を意図し、2 番目の選択肢として PSTN を使用するサイト間 IP WAN コールだけについて説明します。POTS 専用コールについては、「PSTN を介した送信コール」を参照してください。
コールが IP WAN を最初の選択肢として、PSTN を 2 番目の選択肢として使用する、このダイヤル プランの目標は、San Jose のロケーションに、7 桁だけを使用してダイヤルすることです。したがって、Philadelphia のユーザは、（408）
526-XXXX にいる San Jose のユーザに、単に 526XXXX とダイヤル操作するだけで通話できます。
この設定は、ルート パターンから始まります。ルート パターンは、SJ として割り当てられたルート リストを使用して、52.6XXXX と入力されます。ドット（.）の位置は、左側にあるすべてのディジットに、このルート パターンのアクセス コードが含まれていることを意味しています。また、各ルート グループはその独自の処理を起動する必要があるため、ディジット処理が選択されたり、それが要求されることはありません。
図 6-9は、52.6XXXX に対するルート パターンの設定を示しています。
図 6-9 Cisco CallManager を使用したクラスタ間コールのルーティング
図 6-9で示したように、ルート リストには 2 つのグループ、SJ-IPWAN と PHL-PSTN が、優先順位に従って記載されています。SJ-IPWAN ルート グループが最初（最高優先順位）に記載されており、San Jose の Cisco CallManager を指しています。ルート パターン SJ-WAN で指定されているディジット処理は、アクセス コード（52）を廃棄します。このことにより、コールが IP WAN を通過して送信されるとき、リモート Cisco CallManager が内部ダイヤルの長さとして必要とする 5 桁が、このリモート Cisco CallManager に確実に配信されるようになります。 リモート Cisco CallManager に関連付けられた H.323 デバイスは、ゲートキーパーが制御できるように設定され、コールが IP WAN を通過しようとする前に、必ずゲートキーパーに対するコンサルト コールが行われるようにする必要があります。
ゲートキーパーがコールを拒否すると、ルート リストは次のルート グループ PHL-PSTN を使用します。このルート グループは、ダイヤルされた番号の前に 1408 を付加して、コールが目的地に透過的に達成するように設定されています。
ゲートキーパーを使用したコールのルーティング
図 6-9の例は、ダイヤル プランを実施する 1 つの方策を示しています。このダイヤル プランは、サイト間のコールに IP WAN を優先パスとして選択する特定のルート パターンを使用します。Cisco CallManager Release 3.0(5)、およびそれ以降のリリースは、ゲートキーパーを使用してサイト間のコールにアドレス解決を実行する、2 つ目の方策を提供します。この結果、個別サイトでのダイヤル プランが簡素化されます。
Cisco CallManager Release 3.0(5) 以前は、ダイヤル プランの中で、
各 Cisco CallManager は、他の Cisco CallManager のそれぞれに対して、自身を一度ゲートキーパーに登録する必要がありました。たとえば、10 の
Cisco CallManager を使用するネットワークでは、10x9 あるいは 90 のゲートキーパー登録が必要でした。さらに、各 Cisco CallManager には、他の Cisco CallManager のそれぞれに対して、1つのクラスタ間トランク、および少なくとも 1 つのルート パターンが必要でした（この例では、9 のクラスタ間トランク、少なくとも 9 のルート パターンが必要）。Cisco CallManager Release 3.0(5) では、ゲートキーパー登録のプロセスが簡素化および拡張され、新たに番号非通知デバイス ゲートウェイが追加されました。
ゲートキーパー登録のプロセスは、多くの領域で拡張されました。現在では、最初に Cisco CallManager クラスタは、ゲートキーパーに一度だけ登録されます。このようにして、単一のゲートキーパーに 100 までの Cisco CallManager クラスタを登録できます。さらに、登録プロセスは、作業負担の少ない登録をサポートし、ゲートキーパーに掛かる処理のオーバーヘッドを削減します。最後に、各 Cisco CallManager は、その E.164 アドレスを許可要求（ARQ）メッセージ内で送信し、ゲートキーパーは、他のすべての Cisco CallManager の IP アドレスを許可確認（ACF）メッセージの中で戻します。この結果、ゲートキーパーとのコール アドミッション トランザクションは、次の 2 つの成果を実現します。それは、前述したコール アドミッション制御と、E.164 アドレス解決です。
この拡張されたゲートキーパー登録プロセスを使用して、必要最少限の設定で、図 6-10で示した Cisco AVVID ソリューションを配備できます。
図 6-10 ゲートキーパーを使用したクラスタ間コールのルーティング
次の表は、図 6-10で示した配備の設定パラメータです。
|
|
IP アドレス |
|
|
|---|---|---|---|
Cisco CallManager 設定
各 Cisco CallManager クラスタの中で、使用しているクラスタ間コーデックを使ってゲートキーパーを設定し、番号非通知デバイスを使用可能にする必要があります。さらに、ルート プランを設定してクラスタ間のコールを許可する必要があります。
クラスタ間コールに使用するコーデックを選択するには、図 6-11に示されているように、地域を定義し、許容可能速度（圧縮のタイプ）を選択してください。
図 6-11 Cisco CallManager での地域の設定
次のステップは、図 6-12で示されているように、デバイス プールを定義して新しい地域にそのデバイス プールを関連付けることです。
図 6-12 Cisco CallManager でのデバイス プールの設定
次に、図 6-13に示すように、ゲートキーパーを定義し、そのゲートキーパーに正しいデバイス プールを確実に関連付け、番号非通知デバイスを使用可能にする必要があります。
図 6-13 Cisco CallManager でのゲートキーパーの設定
ゲートキーパーへの登録時、Cisco CallManager は、VoIP ゲートウェイとしてそれ自体を音声用テクノロジー プレフィックスに登録します。Cisco CallManager サーバに音声用テクノロジー プレフィックスを設定するには、 Service > Service Parameters の順に選択して、図 6-14で示されているように、Cisco CallManager サービス パラメータ、GateKeeperSupportedPrefix をアップデートします。
（注） デフォルトでは、GateKeeperSupportedPrefix パラメータは非表示です。表示するには、図 6-14で示されたように、パラメータ名とその他の値を正確に入力し、次に Update をクリックします。
図 6-14 Cisco CallManager でのゲートキーパー サービス パラメータの設定
クラスタ間コールに必要なルート パターンは 1 つだけで、そのパターンは、図 6-15で示したように設定できます。
（注） この例の簡素化したダイヤル プランは、PSTN に対する自動フォールバック、あるいはオーバーフローを提供しません。この機能は、Cisco CallManager の以前のリリースのように、各宛先に対するルート グループを必要とします。標準の方法で、マニュアル アクセスを PSTN に追加できます。この例は、新しいクラスタを追加する場合、既存 Cisco CallManager 上での設定は不要ですが、ゲートキーパー、および新しい Cisco CallManager 上での設定だけは、必要になることを示しています。
ゲートキーパーの設定
ゲートキーパーの設定では、ゾーン、そのゾーンに登録する各 Cisco CallManager、ゾーン プレフィックス（ディレクトリ番号範囲）、コール アドミッションに割り当てる帯域幅、および音声用テクノロジー プレフィックスの入力が必要です。
Cisco CallManager は、自身を登録するゲートキーパーのゾーンを指示しないので、ユーザが、Cisco CallManager の IP アドレスを単一のゾーンに明示的に指定し、その他のすべての IP アドレス範囲の登録ができないようにする必要があります。次の指定がその例です。
Cisco CallManager は、その IP アドレスを H.323 ID のように使用して、ゲートキーパーに登録されます。
Cisco CallManager クラスタのディレクトリ番号範囲を指定するには、現在、登録時にこの情報を追加できないので、ゲートキーパー上で静的に設定する必要があります。次の指定がその例です。
1 つのゾーン内あるいはゾーン外に配置できるコールの最大数は、各コールが使用するコーデックに依存します。Cisco CallManager Release 3.0(5) では、G.711 と G.729 は、それぞれ 128 Kbps と 20 Kbps を必要としています。このメカニズムによって、QoS を維持するコール アドミッション制御の実施が許されます。次がその例です。
最後に、Cisco CallManager に使用するテクノロジー プレフィックスは、ユーザが指定する必要があります。ゲートキーパー内では、テクノロジー プレフィックスのないすべての E.164 アドレスに対して、デフォルトのテクノロジーとして、テクノロジー プレフィックスを指定する必要もあります。クラスタは、テクノロジー プレフィックスを登録し、それが VoIP ゲートウェイであるという事実により、各 Cisco CallManager を静的に指定する必要はありません。次の指定がその例です。
ゲートキーパーの選択と冗長性
ゲートキーパーに対するフォールト トレランスは、Cisco AVVID ネットワークで非常に重要です。ホット スタンバイ ルータ プロトコル（HSRP）を使用することにより、ゲートキーパーに対する冗長性を実現できます。HSRP を使用してゲートキーパーの 1 つのペアを設定することにより、アクティブのゲートキーパーが要求を処理し、故障した場合、スタンバイ ゲートキーパーが、処理を引き継げるようになります。
フェールオーバー後、現在のコール状態は失われます。スタンバイ（現在アクティブな）ゲートキーパーは、すべての既存帯域幅、および現在進行中のコールを認識することなく起動します。故障したゲートキーパーが許可していたコールが完了し、新しいコールが新しいゲートキーパーを経由して許可されると、コール状態の情報が回復します。
HSRP のフェールオーバー期間中、ゲートキーパーの機能は喪失します。この期間は、 standby timers コマンドで設定でき、デフォルトでは、Hello インターバルが 3 秒に、そしてホールド時間が 10 秒に設定されます。
ディレクトリ ゲートキーパーを階層配置で使用することにより、非常に多くのクラスタをもつ Cisco CallManager ネットワークをサポートできます。ディレクトリ ゲートキーパーについては、現在、このマニュアルで説明していません。
ダイヤル操作の制約条件の設定
分散型コール処理の環境では、パーティションとコール検索スペースを使用して、ダイヤル操作の制約条件を設定します。この設定は、「ダイヤル プラン グループとコール制約条件の設定」で説明した、キャンパス、あるいは個別のサイトでのダイヤル操作の制約条件の設定と、非常によく似ています。
ダイヤルした番号の帯域幅消費
デバイス間（IP 電話とゲートウェイ間）のコールが消費する帯域幅は、コーデックの使用を指示する地域を設定することで制御できます。すべての地域内コールに指定された特定のコーデックをもち、地域間コールに指定された他のコーデックをもつ、1 つの地域にデバイスを配置することができます。地域はデバイス プールを使用してデバイスに割り当てます。地域に定義してサポートされるコーデックは、G.711、G.729、および G.723 です。（G.723 は、Cisco IOS IP Phone 12 SP+、および Cisco IP Phone 30 VIP だけでサポートされています。）
図 6-16は、分散型コール処理環境での地域の使用について示しています。この環境では、多くの場合割り当てる必要がある地域は、2 つだけです。
（注） 単一のコーデックという制約状況のため、IP WAN 上のすべての
H.323 デバイスに関連付けられる WAN 地域は、1 つだけです。Cisco CallManager の今後のリリースでは、複数の WAN 地域をサポートする可能性があります。
Cisco CallManager クラスタ の考慮事項
Cisco CallManager Release 3.0 を使用する分散型コール処理環境では、次の設計上の考慮事項が、Cisco CallManager クラスタに適用されます。
• 各 Cisco CallManager クラスタがサポートできるユーザ数は、10,000 ユーザである。
• 所定のいずれかの Cisco CallManager 上に登録できるのは、故障状況であっても、2500 ユーザまでである。
• Cisco IOS ゲートキーパーに一度に登録できるクラスタ内の Cisco CallManager は、1 つだけである。
トランスコーディングと電話会議のための、DSP リソースのプロビジョニング
このセクションでは、分散型コール処理環境での DSP について、簡潔に説明します。分散型コール処理を行う複数サイト WAN では、IP WAN 上の電話会議、およびトランスコーディングに必要な DSP リソースを、各サイトに割り当てる必要があります。電話会議とトランスコーディングのサービスは、メディア終端点（MTP）アプリケーションにより使用可能となります。
トランスコーディング リソースの主な目的は、コーデックのミスマッチが発生した場合、リアルタイム転送プロトコル（RTP）ストリーム中の異なるコーデック タイプ間で変換を実行することです。たとえば、IP WAN 上の圧縮 G.729 メディア RTP ストリームが、G.711 だけをサポートするデバイス上に到達する必要があるとします。トランスコーディング DSP リソースは、G.729 メディア ストリームを終端し、それを G.711 に変換することになります。このことは、メディア ストリームが、WAN 上では圧縮されたままの状態を維持できることになります。図 6-17は、次のステップで記載したように、IP WAN 上の DSP リソースの機能を示しています。
ステップ 1 地域 B の発信者 555-1212 は、地域 A に音声メールをダイヤルする。
ステップ 2 Cisco CallManager B は、宛先が 地域 A、LBR コーデックであると理解する。
ステップ 3 Cisco CallManager A は、G.711 専用デバイスに対して LBR 着信コールがあることを理解する。
ステップ 4 メディア ストリームは、終端側 DSP ファームへ送信される。
割り当てるリソースの数は、電話会議のような他のアプリケーション用の G.711 へのトランスコーディングだけではなく、音声メールへのトランスコーディングの要件に基づきます。これらの数量は、音声メール ポート数、および実行される電話会議コールの量と使用するユーザとの比率に基づいて計算されます。
すべてのデバイスがすべてのコーデック タイプをサポートできない環境では、専用のトランスコーディングをクラスタ間に設定する必要があります。この設定を実行するには、Cisco CallManager Administration で、 Device > Gatekeeper の順に選択して、Media Termination Point Rquired チェックボックスにチェックを付けて使用可能にします。この設定ステップを実行しないと、Cisco CallManager は、適正なトランスコーダーを自動的に選択できず、コーデックにミスマッチが発生した場合、RTP ストリームの転送は、完了しなくなります。
音声メッセージ処理の考慮事項
分散型コール処理を行う複数サイト IP WAN では、サイトごとに独自の音声メッセージ処理コンポーネントを必要とします。Cisco uOne を使用するか、あるいはレガシー音声メッセージ処理システムへインターフェイスするかを問わず、このことが必要となります。図 6-18を参照してください。
フィードバック