Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月31日
章のタイトル： コール処理
コール処理
この章では、Cisco CallManager クラスタのコール処理機能に関連した、次の設計上の考慮事項について説明しています。
•
「Cisco CallManager リリース 3.1 および 3.2 を使用したコール処理」
• 「Cisco CallManager リリース 3.3 を使用したコール処理」
また、この章では、ゲートキーパーについても説明しています。ゲートキーパーは、IP テレフォニー ネットワークの機能を拡張するために、Cisco CallManager と組み合せて追加のコール処理エージェントとして使用できます。
クラスタリングのガイドライン
すべての Cisco CallManager クラスタに次のガイドラインが適用されます。
（注） 1 つのクラスタに複数のサーバ プラットフォームを組み合せることができますが、クラスタ内のすべてのサーバでは、同じ Cisco CallManager ソフトウェア リリースを実行する必要があります。
• 通常の環境では、同一 LAN または MAN 内にクラスタのすべてのメンバーを入れます。
• クラスタが IP WAN にわたって構築されている場合、IP WAN を介したクラスタリング固有のガイドラインに従ってください（「IP WAN を介したクラスタ化」 を参照）。
• クラスタ内の各サーバは、最大 500 台の H.323（ゲートウェイとクライアント）デバイス、およびデジタル MGCP デバイスをサポートできます。
• すべての Cisco CallManager サーバが 100 Mbps 全二重でイーサネットに接続していることを確認してください。小規模な配置で 100 Mbps が使用可能でない場合、10 Mbps 全二重を使用してください。この設定を行うには、NIC カードを 100 Mbps または 10 Mbps のデュプレックス モードに設定し、イーサネット スイッチ ポートも手作業で調整します。
（注） サーバ ポートまたはイーサネット スイッチ ポートのどちらか一方が AUTO モードのままであり、もう一方のポートが手作業で設定される場合、ミスマッチが生じます。最善の方法は、サーバ ポートとイーサネット スイッチ ポートの両方を手作業で設定することです。
• クラスタ内で Voice Activity Detection（VAD）を使用不可にしておくことをお勧めします。デフォルトでは、Cisco CallManager サービス パラメータで VAD は使用不可になっています。H.323 ダイヤルピア上で使用不可にするには、 no vad コマンドを使用してください。
表 6-1 では、クラスタ内で使用できる一般的なサーバのタイプとその主な特性を一緒にリストしています。
|
|
|
|---|---|
Cisco CallManager リリース 3.1 および 3.2 を使用したコール処理
Cisco CallManager リリース 3.1 および 3.2 には、次のガイドラインが適用されます。
• クラスタ内では、Cisco CallManager Service を使用して最大 6 台のサーバ（4 台のプライマリ サーバと 2 台のバックアップ サーバ）を使用可能にすることができます。それ以外のサーバは、TFTP（Trivial File Transfer Protocol）、データベース パブリッシャ、Music on Hold などの専用機能に使用できます。
• サーバごとに CTI（Computer Telephony Integration）接続またはアソシエーションを最大 800 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 3200 を設定できます。詳細は、「CTI（Computer Telephony Integration）」を参照してください。
• 各 H.323 デバイスは、Cisco CallManager リリース 3.1 では H.323 コールを最大 500 件、Cisco
CallManager リリース 3.2 では H.323 コールを最大 1000 件までサポートできます。
Cisco CallManager リリース 3.3 を使用したコール処理
Cisco CallManager リリース 3.3 には、次のガイドラインが適用されます。
• クラスタ内では、Cisco CallManager Service を使用して最大 8 台のサーバを使用可能にすることができます。それ以外のサーバは、TFTP、パブリッシャ、Music on Hold などの専用機能に使用できます。
• 標準サーバごとに CTI 接続またはアソシエーションを最大 800 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 3200 設定できます。
• MCS 7845 または同等サーバごとに CTI 接続またはアソシエーションを最大 2500 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 10,000 設定できます。
• H.323 コールの最大数は、デバイスの重みによって制限されます（「デバイスの重み」 を参照）。
デバイスの重み
表 6-2 では、デバイス タイプごとの基本のデバイスの重みを示しています。この値は、メモリと CPU（中央演算処理装置）リソースの消費量に基づいています。
|
|
|
または DS0 |
|
|---|---|---|---|
変動1 |
|||
CTI サードパーティ制御2 |
|||
CTI エージェント電話機2 |
|||
2003 |
|||
724 |
|||
724 |
| 1.CTI ルート ポイントの累積重みは、アプリケーションが使用する、関連した CTI ポートによって異なります。 3.MoH が Cisco CallManager と同じサーバにインストールされる場合、最大ストリーム数は 20 です。 |
BHCA 乗数
各デバイスの基本の重みは、6 以下の BHCA（Busy Hour Call Attempts）を使用して計算されます。BHCA の数が増えるにつれて、サーバが処理する必要があるトランザクション数も増え、したがって、そのプラットフォーム上のデバイスの重みが増えます。7 以上の BHCA が必要な各デバイスでは、基本の重みに乗数が適用されます。乗数を計算するには、BHCA を 6 で割って、最も近い整数に切り上げます。たとえば、15 BHCA を行う IP フォンの乗数は、3（15/6 = 2.5、3 に切り上げ）になります。15 BHCA を行う IP フォンの合計のデバイスの重みは、基本の重みに 3 を乗算した数と等しくなります。 表 6-3 では、BHCA 乗数の影響を示しています。
（注） 乗数が適用されるのは、端末デバイスまたはクライアント デバイスのみです。メディア リソースまたはゲートウェイであるデバイスには適用されません。
|
BHCA |
BHCA |
BHCA |
BHCA |
BHCA |
|
|---|---|---|---|---|---|
サーバ プラットフォーム
1 つの Cisco CallManager がサポートできるデバイスの重みユニットの合計数は、サーバ プラットフォームによって異なります（ 表 6-4 を参照）。
|
|
|
|
|
|
|---|---|---|---|---|
| 5.高可用性サーバでないプラットフォームは、非冗長インストレーションで IP フォンを最大 500 台サポートできます。 |
サポートされるプラットフォームと個々のハードウェア設定の最新情報については、次の Web サイトにあるオンライン資料を参照してください。
http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure_list.html
ダイヤル プランの重み
Cisco CallManager は、デバイスの重みを使用して、任意のサブスクライバ サーバに登録できる物理デバイスの数を制御します。BHCA 乗数は、混雑時の発信または受信コール数が増えるにつれて、サブスクライバに対する影響が大きくなるデバイスのデバイスの重みを調整します。
ダイヤル プランの重みは、Cisco CallManager サーバで設定できるダイヤル プラン パラメータの数を制御します。サブスクライバ ダイヤル プランの重みは、個々のデバイス設定パラメータ（特に、ライン アピアランス）に関連します。グローバル ダイヤル プランの重みは、特定のデバイスに関連付けられていないグローバル設定パラメータ（たとえば、ルート パターンや変換パターン）に関連します。
サブスクライバ ダイヤル プランの重みは、次の主なタイプで構成されます。
• IP フォンの重みは、フォン（またはその他のダイヤル可能デバイス）が通常登録される先のサブスクライバ サーバに関連付けられます。IP フォンのダイヤル プランの重みは、そのフォンのデバイスの重みとは無関係です（「デバイスの重み」 を参照）。
• 回線の重み（固有または共用アピアランス）は、Cisco CallManager 冗長性グループによって定義される通りに、デバイスが通常登録されるサブスクライバ サーバに関連付けられます。
• 到達可能性の重みは、所定の回線に到達する（呼び出す）ことができなければならない、クラスタ内の他のすべてのサブスクライバに関連付けられます。
グローバル ダイヤル プランの重みは、ルート パターンと変換パターンの重みで構成されます。
ライン アピアランスは、ディレクトリ番号（DN）が割り当てられている任意のデバイス（IP フォン、CTI ポート、CTI ルート ポイント、または H.323 クライアント）として定義されます。同じデバイス上に追加される、すべてのライン アピアランスまたは DN には、関連したダイヤル プランの重みがあります。
要約すれば、ダイヤル プランのコンポーネントの重みは次のとおりです。
–IP フォンまたはその他のダイヤル可能デバイス（ライン アピアランスを除く）= 5
たとえば、固有ライン アピアランス（たとえば、内線番号 1000）をもつ IP フォンが、サブスクライバ A に登録される場合、サブスクライバ A のダイヤル プランの重みは 10 です（IP フォンの 5 と、固有ライン アピアランスの 5）。サブスクライバ A の内線 1000 に到達できるように、クラスタ内の他のすべてのサブスクライバも情報が必要です。これらのサブスクライバには、ダイヤル プランの到達可能性の重みがそれぞれ 3 あります。同じフォン上に追加される各固有ライン アピアランスは、サブスクライバ A にダイヤル プランの重み 5 ユニットを追加し、クラスタ内の他の各サブスクライバに 3 ユニットを追加します。一方、同じフォン上の各共用ライン アピアランスは、サブスクライバ A にダイヤル プランの重み 4 ユニットを追加し、クラスタ内の他の各サブスクライバに 3 ユニットを追加します。
グローバル ダイヤル プランの重みは、クラスタ内のすべてのサブスクライバ サーバに適用されます。たとえば、ルート パターン 9.911 は、クラスタ内の各サブスクライバ サーバにダイヤル プランの重み 2 を追加します。
表 6-5 では、フォン数、ライン アピアランス数、およびサブスクライバ サーバ上で設定されるダイヤル プランの複雑度に基づいて、そのサーバに搭載する物理メモリ量のガイドラインをリストしています。
|
ダイヤル プラン重みユニット数 |
|
|---|---|
通常の配置では、各サブスクライバ サーバで、140,000 を超えるダイヤル プラン重みユニットを設定しないでください。
（注） ダイヤル プランの重みの計算は、デバイスの重みの計算とは別です。サブスクライバ サーバおよびクラスタは、デバイスの重みとダイヤル プランの重みの両方の制限に準拠する必要があります。どちらかの制限を超える場合は、デバイスやライン アピアランスなどの数を減らして、制限に準拠するようにしてください。
多数のゲートウェイ、ルート パターン、変換パターン、およびパーティションを含む非常に大きなダイヤル プランをもつ Cisco CallManager クラスタでは、Cisco CallManager Service の初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、サービス パラメータを変更して、設定の初期化時間を延長してください。サービス パラメータの詳細は、Cisco.com で入手可能な Cisco CallManager 『アドミニストレーション ガイド』と『システム ガイド』を参照してください。
コール処理の冗長性
すべてのバージョンの Cisco CallManager で、次の冗長性設定の中から選択できます。
• 2：1 冗長性方式：プライマリ サブスクライバ 2 台ごとに、1 つの共用バックアップ サブスクライバを設置します。
• 1：1 冗長性方式：プライマリ サブスクライバごとに、1 つのバックアップ サブスクライバを設置します。
1：1 冗長性方式では、フェールオーバー期間だけがクラスタに影響を与えるアップグレードが可能です。このフェールオーバー メカニズムは、IP フォンのフェールオーバー レート、毎秒約 100 台の登録を実現できるように拡張されました。
Cisco CallManager リリース 3.3 は、最大 8 台のサブスクライバ（Cisco CallManager サービスが使用可能になっているサーバ）をサポートできるので、クラスタ内で 4 つのプライマリ サブスクライバと 4 つのバックアップ サブスクライバを備えることができます。
1：1 冗長性方式で、クラスタをアップグレードする手順は、次のとおりです。
ステップ 2 専用 TFTP サーバと MoH（Music on Hold）サーバをアップグレードします。
ステップ 3 すべてのバックアップ サブスクライバをアップグレードします。50/50 ロード バランシングが設定されている場合、このステップは一部のユーザに影響を与えます。
ステップ 4 プライマリ サブスクライバをバックアップ サブスクライバにフェールオーバーし、プライマリ サブスクライバ上の Cisco CallManager サービスを停止します。
ステップ 5 プライマリ サブスクライバをアップグレードしてから、Cisco CallManager サービスを再び使用可能にします。
このアップグレード方法では、異なるバージョンの Cisco CallManager ソフトウェアを実行しているサブスクライバ サーバにデバイスが登録される期間（フェールオーバー期間を除く）がありません。サブスクライバ間で通信する ICCS（Intra-Cluster Communication Signaling）プロトコルは、異なるソフトウェア バージョンを検出し、そのサブスクライバとの通信をシャットダウンする可能性があるので注意が必要です。このアクションにより、コール処理用にクラスタが分割される可能性がありますが、SQL と LDAP 複製には影響を与えません。
2:1 冗長性方式では、クラスタ内のサーバ数を減らすことができますが、その結果、アップグレード時に障害が発生する可能性があります。
（注） 10,000 台以上の IP フォンが 2 つのプライマリ サブスクライバに登録される場合は、1:1 冗長性を使用する必要があります。これは、1 つのバックアップ サブスクライバで 10,000 台以上のバックアップ登録はできないからです。
クラスタの冗長性設定
次の図では、Cisco CallManager でコール処理の冗長性を実現するための一般的なクラスタ構成を示しています。
図 6-2 標準サーバ上で Cisco CallManager リリース 3.x を使用した 2:1 冗長性
図 6-3 標準サーバ上で Cisco CallManager リリース 3.3 を使用した 1:1 冗長性（50/50 ロード バランシング）
図 6-4 MCS-7845 高性能サーバ上で Cisco CallManager リリース 3.3 を使用した冗長性（50/50 ロード バランシング）
ロード バランシング
1:1 冗長性方式を使用するもう 1 つの利点は、プライマリ サーバとバックアップ サーバのペア上でデバイスのバランスを取ることができる点です。通常、プライマリが使用可能な場合、バックアップ サーバに登録されたデバイスはありません。
ロード バランシングを使用すると、Cisco CallManager の冗長性グループとデバイス プールの設定値を使用して、デバイスにかかる負荷の半分までをプライマリ サブスクライバからセカンダリ サブスクライバに移すことができます。この方法で、サーバが使用不能になる影響を 50% 減らすことができます。
50/50 ロード バランシングを計画するには、フェールオーバー シナリオを可能にする単一サーバのデバイスの重み制限内にとどめてください。たとえば、MCS 7835 サーバには、デバイス重みユニット数が最大 5000、IP フォンが最大 2500 という制限があります。1：1 冗長性ペアでは、2 つのサブスクライバ間で負荷を分割し、デバイス重みユニットを 2500、IP フォンを 1250 もつサブスクライバをそれぞれ設定できます（図 6-3 の 2500 台の IP フォンの設定を参照）。
1 つのサーバだけがアクティブであるときのフェールオーバー条件に備えるには、冗長ペアの合計のデバイス重みユニット数、IP フォン数、CTI 制限などが、単一サーバに許可される制限を超えないようにしてください。
セカンダリ TFTP サーバ
さらにロード バランシングと冗長性を確保するには、クラスタ内に 2 番目の TFTP（Trivial File Transfer Protocol）サーバをインストールします。TFTP サーバは、コンフィギュレーション ファイル、デバイス ロード（オペレーション コード）、およびリング タイプのダウンロードを実行します。セカンダリ サーバに電話機を登録できないように Cisco CallManager サービスをオフにして、セカンダリ サーバを TFTP 専用に設定する必要があります。Cisco CallManager サービスがクラスタ内の別のサーバで実行中になった後、クラスタ内通信により、データベースにデータが取り込まれ、すべての電話機設定が作成され、TFTP サーバ上のメモリに入ります。
クラスタ内の特定タイプの電話機の電話機負荷を変更する必要があるときに、同時に Cisco
CallManager ソフトウェアをアップグレードしない場合は、セカンダリ TFTP サーバに特に注意してください。その場合は、新しい電話機の負荷を手作業で各 TFTP サーバにコピーしてください。
Cisco CallManager リリース 3.3 以降では、電話機のコンフィギュレーション ファイルは、旧バージョンの Cisco CallManager のように、TFTP サーバのハード ドライブにデフォルトで保存されることはありません。デフォルトでは、電話機のすべてのコンフィギュレーション ファイルは作成されると、TFTP サーバ上の RAM に置かれます。このデフォルト設定を変更して、電話機のコンフィギュレーション ファイルを TFTP サーバのハード ドライブに入れることができますが、これを行うと、TFTP のパフォーマンスに影響があります。したがって、このデフォルト設定を変更しないことをお勧めします。
ゲートキーパーの考慮事項
Cisco IOS ゲートキーパーは、分散型コール処理環境で最大 100 の Cisco CallManager クラスタに対してコール ルーティングとコール アドミッション制御をサポートできます。Cisco IOS ゲートキーパーを使用して、H.323 ゲートウェイと Cisco CallManager 間の通信とコール アドミッション制御をサポートすることによって、ハイブリッド Cisco CallManager とトール バイパス ネットワークを実装することもできます。
ゲートキーパーのコール アドミッション制御は、ポリシーベースの方式であり、使用可能なリソースの静的設定を必要とします。ゲートキーパーは、ネットワーク トポロジーを認識しないので、ハブアンドスポーク トポロジーに制限されます。
Cisco 2600、3600、3700、および 7200 シリーズのルータはすべて、ゲートキーパー機能をサポートします。Cisco IOS ゲートキーパー機能は、IP/H323 と MCM（Enterprise Multimedia Conference Manager）の両方のフィーチャ セットで使用可能です。 表 6-6 にリストされているように、配置要件に基づいて、適切なフィーチャ セットを選択してください。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
冗長性、ロード バランシング、および階層コール ルーティング用に、さまざまな方法で Cisco IOS ゲートキーパーを設定できます。これらの目標を実現するために、ゲートキーパーの解析ロジックの理解が役立ちます。図 6-5 では、アドミッション要求（ARQ）の解析ロジックを示し、図 6-6 では、ロケーション要求（LRQ）の解析ロジックを示しています。
エンドポイントは、コールを初期化するために、ARQ（Admission Request ; アドミッション要求）をゲートキーパーに送信します。ARQ には、宛先すなわち着信側の H.323 ID または E.164 アドレスのどちらか、および送信元すなわち発信側の E.164 アドレスまたは H.323 ID が含まれています。
ARQ には、要求されるコール帯域幅も入っています。この帯域幅は、ビデオと音声のすべてのチャネルの送受信ビット レートの上限でなければなりません。この帯域幅は、転送、IP、または RTP のオーバーヘッドを考慮していません。
ARQ に E.164 アドレスが入っている（Cisco CallManager では、ARQ には常に E.164 アドレスが入っています）場合、ARQ にはテクノロジー プレフィックスが含まれている場合と、含まれていない場合があります。ARQ にテクノロジー プレフィックスが含まれていない場合、ゲートキーパーは、デフォルトのテクノロジー プレフィックス（設定されている場合）を使用します。「集中型ゲートキーパー設定」の項の gw-type-prefix コマンドを参照してください。
要求された帯域幅が使用可能であり、着信側エンドポイントがゲートキーパーに登録される場合、ゲートキーパーは、ARQ に応答して ACF（Admission Confirm; アドミッション確認）を送信します。ACF には、宛先エンドポイントの IP アドレスが入っています。帯域幅が使用不能であるか、着信側エンドポイントが登録されない場合、ゲートキーパーは、発信側エンドポイントに ARJ（Admission Reject; アドミッション拒否）を戻します。
送信元エンドポイントは、ゲートキーパーから ACF を受信した後、ACF で戻された IP アドレスを使用して、直接セットアップ メッセージを宛先エンドポイントに送信できます。
集中型ゲートキーパー設定
単一のゲートキーパーは、クラスタ間のコール ルーティング、および最大 100 の Cisco CallManager クラスタに対するコール アドミッション制御をサポートできます。図 6-7 では、2 つの Cisco CallManager クラスタと単一の集中型ゲートキーパーを備えた分散型コール処理環境を示しています。
図 6-7 2 つのクラスタをサポートする集中型ゲートキーパー
例6-1 では、図 6-7 のゲートキーパー設定を示しています。
ここでは、例6-1 について説明します。
• Cisco CallManager トランク登録をサポートするために、各 Cisco CallManager クラスタにはローカル ゾーンが設定されます。
• ゾーン間とクラスタ間のコール ルーティングを可能にするために、ゾーンごとにゾーン プレフィックスが設定されます。
• 「.」（ドット）は、1 桁の数字がワイルドカードとして一致することを示します。この例では、E.l64 アドレスは、408 か 212 のどちらかで始まる 10 桁でなければなりません。*（アスタリスク）も、任意の桁数の数字を示すワイルドカードとして使用できます。例6-1 のゾーン プレフィックスが 408* と 212* である場合、408 または 212 で始まる任意の長さの数字が、正しくルーティングされます。
• サイトごとに帯域幅ステートメントが設定されます。 bandwidth interzone コマンドの使用をお勧めします。 bandwidth total コマンドを使用すると、一部の設定で問題が発生する可能性があります。帯域幅はキロビット/秒（kbps）単位で測定されます。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
テクノロジー プレフィックスは、発信されるコールのタイプを示します。テクノロジー プレフィックスとして使用される個々の値は、任意であり、ネットワーク管理者によって指定されます。配置全体で常に同じ値を使用する必要があります。
テクノロジー プレフィックスは、E.164 アドレス（電話番号）のプレフィックスとして送信され、コールが音声であるか、ビデオであるか、その他のタイプであるかを示します。# シンボルは、一般に、プレフィックスと E.164 番号を区別するために使用します。プレフィックスが含まれていない場合、コールのルーティングにはデフォルトのテクノロジー プレフィックスが使用されます。配置用に 1 つのデフォルト テクノロジー プレフィックスだけが使用される場合があります。
Cisco IOS ゲートウェイは、プレフィックスが設定されていれば、自動的に発信コールにテクノロジー プレフィックスを追加します。ゲートウェイは、自動的に着信 H.323 コールからプレフィックスを除去します。トランク上でテクノロジー プレフィックスが設定されていても、Cisco CallManager が自動的にテクノロジー プレフィックスを送信することはありません。しかし、Cisco CallManager H.323 Trunk Gateway コンフィギュレーション ページでプレフィックスを設定することができます。また、H.323 トランク上で変換パターンか有効数字のどちらかを使用して、Cisco CallManager への着信コールからテクノロジー プレフィックスを除去することも必要です。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
分散型ゲートキーパー設定
帯域幅を節約するため、または WAN 障害時に H.323 ゲートウェイにローカル コール ルーティングをサポートするために、ゲートキーパーを分散させることができます。図 6-8 では、2 つのクラスタと 2 つのゲートキーパーを備えた分散型コール処理環境を示しています。
図 6-8 2 つのクラスタをサポートする分散型ゲートキーパー
例6-2 では、図 6-8 のサイト 1 に対するゲートキーパー設定を示しています。
ここでは、例6-2 について説明します。
• ローカル Cisco CallManager クラスタ トランクの登録用に、ローカル ゾーンが設定されます。
• サイト 2 のゲートキーパーへのコール ルーティング用に、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のゾーンにゾーン プレフィックスが設定されます。
• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、
bandwidth remote コマンドを使用します。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
例6-3 では、図 6-8 のサイト 2 に対するゲートキーパー設定を示しています。
ここでは、例6-3 について説明します。
• ローカル Cisco CallManager クラスタ トランクの登録用に、ローカル ゾーンが設定されます。
• サイト 1 のゲートキーパーへのコール ルーティング用に、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のゾーンにゾーン プレフィックスが設定されます。
• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、
bandwidth remote コマンドを使用します。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
ディレクトリ ゲートキーパーを使用した分散型ゲートキーパー設定
ゲートキーパー ルーティング テーブルを更新するために使用できるゲートキーパー プロトコルがないので、ディレクトリ ゲートキーパーを使用すると、分散型ゲートキーパー設定のスケーラビリティとマネージャビリティの向上に役立ちます。ディレクトリ ゲートキーパーを実装すると、各サイトのゲートキーパー設定が簡単になり、ゾーン間通信の大部分の設定をディレクトリ ゲートキーパーでできるようになります。
ディレクトリ ゲートキーパーがない場合、ゲートキーパーに新しいゾーンを追加するたびに、ネットワーク上のすべてのゲートキーパーに項目を追加する必要があります。しかし、ディレクトリ ゲートキーパーを使用すると、ローカル ゲートキーパーとディレクトリ ゲートキーパーのみで新しいゾーンを追加できます。ローカル ゲートキーパーは、コール要求をローカル側で解決できない場合、ゾーン プレフィックスが一致するディレクトリ ゲートキーパーにその要求を転送します。
図 6-9 では、ローカル コール ルーティング用の分散型ゲートキーパー、およびゲートキーパー間のコール ルーティングをサポートするディレクトリ ゲートキーパーを備えた、Cisco CallManager 分散型コール処理環境を示しています。
図 6-9 ディレクトリ ゲートキーパーを備えた分散ゲートキーパー
例6-4 では、図 6-9 のサイト 1 に対するゲートキーパー設定を示しています。この例では、サイト 1 とサイト 2 のゲートキーパー設定がほぼ同じなので、ここでは、サイト 1 だけについて説明します。
例6-4 ディレクトリ ゲートキーパーを使用したサイト 1 のゲートキーパー設定
ここでは、例6-4 について説明します。
• ローカル Cisco CallManager クラスタ トランクの登録用に、ローカル ゾーンが設定されます。
• ディレクトリ ゲートキーパー用にリモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のゾーンにゾーン プレフィックスが設定されます。
• ディレクトリ ゲートキーパーのゾーン プレフィックスは、10 個のドットを使用して設定されます。このパターンは、未解決の任意の 10 桁のダイヤル ストリングと一致します。1 つのゾーンに複数のゾーン プレフィックスを設定して、異なる長さのダイヤル ストリングを一致させることができます。ディレクトリ ゲートキーパーのゾーン プレフィックスにもワイルドカード（*）を使用できますが、この方法はコール ルーティングの問題が発生する場合があります。
• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、
bandwidth remote コマンドを使用します。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
例6-5 では、図 6-9 の例のディレクトリ ゲートキーパー設定を示しています。
ここでは、例6-5 について説明します。
• ディレクトリ ゲートキーパー用にローカル ゾーンが設定されます。
• リモート ゲートキーパーごとに、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のリモート ゾーンにゾーン プレフィックスが設定されます。設定を簡単にするために、ゾーン プレフィックスでワイルドカード（*）が使用されます。コールは DGK ゾーンにルーティングされないので、DGK ゾーンにはプレフィックスが必要ありません。
• lrq forward-queries コマンドは、ディレクトリ ゲートキーパーが、別のゲートキーパーから受信した LRQ を転送できるようにします。
ゲートキーパーの冗長性
ゲートキーパーが、クラスタ間通信にすべてのコール ルーティングとアドミッション制御機能をサポートする場合は、冗長性が必要です。Cisco CallManager リリース 3.3 より前では、ゲートキーパーの冗長性をサポートする方法は、ホットスタンバイ ルータ プロトコル（HSRP）だけでした。Cisco CallManager リリース 3.3 以降、ゲートキーパーの冗長性をサポートする方法として、ゲートキーパー クラスタリングと冗長ゲートキーパー トランクも使用できるようになりました。次の項では、これらの方法について説明します。
（注） 可能な場合、ゲートキーパーの冗長性をサポートするには、ゲートキーパー クラスタリングを使用することをお勧めします。冗長性に HSRP を使用するのは、ソフトウェア フィーチャ セットでゲートキーパー クラスタリングが利用できない場合だけにしてください（ゲートキーパー クラスタリングの可用性については、表 6-6 を参照）。
ホットスタンバイ ルータ プロトコル（HSRP）
リリース 3.3 より前の Cisco CallManager では、ゲートキーパーの冗長性には、ホットスタンバイ ルータ プロトコル（HSRP）しか選択できませんでした。HSRP は、冗長かつスケーラブルなゲートキーパー ネットワークの構築に必要な機能をサポートしないので、リリース 3.3 より前の Cisco CallManager 環境でのみ使用してください。
• 一度に 1 つのゲートキーパーしかアクティブになりません。
–スタンバイ ゲートキーパーは、プライマリに障害が発生した場合でなければ、コールを処理しません。
• すべてのゲートキーパーが同じサブネットまたはロケーションに存在しなければなりません。
• フェールオーバー後、スタンバイ ゲートキーパーは、すでにアクティブになっているコールを認識しないので、帯域幅のオーバーサブスクリプションが発生する可能性があります。
• コールの発信前に、HSRP スタンバイ ゲートキーパーにエンドポイントを再登録する必要があるので、フェールオーバーには相応の時間がかかります。フェールオーバー時間は、登録タイマーの設定に依存します。
図 6-10 では、ゲートキーパーの冗長性に HSRP を使用するネットワーク設定を示しています。
例6-6 では、図 6-10 のゲートキーパー 1 の設定を示しています。例6-7 では、ゲートキーパー 2 の設定を示しています。イーサネット インターフェイス上の HSRP 設定を除いて、両方の設定は同一です。
• 各ルータには、それぞれが使用する仮想 IP アドレスを識別するために、HSRP 用に standby コマンドが設定されます。ゲートキーパー 2 は、 standby 10 ip 10.1.10.110 secondary を使用してバックアップとして設定されます。ここで、キーワード secondary がこのルータをバックアップとして指定します。
• Cisco CallManager トランク登録をサポートするために、各 Cisco CallManager クラスタには、各ルータ上でローカル ゾーンが設定されます。
• ゾーン間とクラスタ間のコール ルーティングを可能にするために、両方のルータでゾーンごとにゾーン プレフィックスが設定されます。
• 各ルータで、両方のサイトの帯域幅ステートメントが設定されます。 bandwidth interzone コマンドの使用をお勧めします。 bandwidth total コマンドを使用すると、一部の設定で問題が発生する可能性があります。
• ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できるように、 gw-type-prefix 1# default-technology コマンドが両方のルータで設定されます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• 冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避するために、 arq reject-unknown-prefix コマンドが両方のルータで設定されます。
ゲートキーパー クラスタリング（代替ゲートキーパー）
ゲートキーパー クラスタリング（代替ゲートキーパー）により、「ローカル」ゲートキーパー クラスタの設定が可能になります。各ゲートキーパーは、一部の Cisco CallManager トランクのプライマリ、およびその他のトランクの代替として機能します。GUP（Gatekeeper Update Protocol）は、ローカル クラスタ内のゲートキーパー間で状態情報を交換するために使用されます。GUP は、クラスタ内のゲートキーパーごとに CPU 使用率、メモリ使用率、アクティブ コール数、および登録されたエンドポイント数を追跡し、報告します。GUP メッセージングで次のパラメータにしきい値を設定すると、ロード バランシングがサポートされます。
ゲートキーパー クラスタリング（代替ゲートキーパー）と Cisco CallManager リリース 3.3 のサポートにより、ステートフル冗長性とロード バランシングが使用可能になります。ゲートキーパー クラスタリングにより、次の機能がサポートされます。
• ローカル クラスタ内のゲートキーパーを、別々のサブネットまたはロケーションに配置可能
• フェールオーバーの遅延なし（代替ゲートキーパーはすでにエンドポイントを認識しているので、完全な登録プロセスを実行する必要はありません）
• クラスタ内のゲートキーパーは、状態情報を渡し、次の項目のロード バランシングを行う
図 6-11 では、Cisco CallManager 分散型コール処理を行う 3 つのサイト、およびローカル クラスタで設定された 3 つの分散型ゲートキーパーを示しています。
図 6-11 では、ゲートキーパー 2 はゲートキーパー 1 のバックアップであり、ゲートキーパー 3 はゲートキーパー 2 のバックアップであり、ゲートキーパー 1 はゲートキーパー 3 のバックアップです。
例6-8 では、ゲートキーパー 1（SJC）の設定を示し、例6-9 は、ゲートキーパー 2（CHC）の設定を示しています。ゲートキーパー 3（NYC）の設定は、他の 2 つの例を参照してください。
例6-8 ゲートキーパー 1 のゲートキーパー クラスタリング設定
例6-9 ゲートキーパー 2 のゲートキーパー クラスタリング設定
• Cisco CallManager トランク登録をサポートするために、各 Cisco CallManager クラスタにはローカル ゾーンが設定されます。
• ローカル ゾーンごとにクラスタが定義され、他のゲートキーパー上のバックアップ ゾーンはエレメントとしてリストされます。エレメントは、バックアップが使用される順にリストされます。
• ゾーン間とクラスタ間のコール ルーティングを可能にするために、ゾーンごとにゾーン プレフィックスが設定されます。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• load-balance cpu 80 memory 80 コマンドは、CPU とメモリの使用率を制限します。ルータがどちらかの制限に達すると、新しい要求はすべて拒否され、使用率がしきい値以下に下がるまで、リスト内の最初のバックアップが使用されます。
• サイトごとに帯域幅ステートメントが設定されます。 bandwidth interzone コマンドの使用をお勧めします。 bandwidth total コマンドを使用すると、一部の設定で問題が発生する可能性があります。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
クラスタ内のすべてのゲートキーパーは、すべての Cisco CallManager トランク登録を表示します。ゲートキーパーをプライマリ リソースとして使用するトランクの場合、フラグ フィールドはブランクです。クラスタ内の別のゲートキーパーをプライマリ ゲートキーパーとして使用するトランクの場合、フラグ フィールドは A（代替）に設定されます。すべてのエンドポイントをプライマリまたは代替として登録すると、すべてのコールをローカル側で解決できるようになり、別のゲートキーパーにロケーション要求（LRQ）を送信する必要はありません。
例6-10 では、ゲートキーパー 1（SJC）での show gatekeeper endpoints コマンドからの出力を示しています。
ディレクトリ ゲートキーパーの冗長性
HSRP を使用するか、2 つの同じディレクトリ ゲートキーパーを設定すると、ディレクトリ ゲートキーパーの冗長性を実装できます。同じゾーン プレフィックスを使用して、複数のリモート ゾーンをもつゲートキーパーを設定するとき、このゲートキーパーには、次のいずれかの方法が使用できます。
冗長リモート ゾーン（ゾーン プレフィックスが一致）にコストが割り当てられ、LRQ は、コスト値に基づいた順序で、一致するゾーンに送信されます。順次 LRQ を使用すると、一致するすべてのゲートキーパーに LRQ を送信しないので、WAN 帯域幅の節約になります。
LRQ は、冗長ゾーン（ゾーン プレフィックスが一致）に同時に送信されます。ロケーション確認（LCF）で応答する最初のゲートキーパーが、使用されます。
順次 LRQ を使用して 2 つのアクティブ ディレクトリ ゲートキーパーを使用することをお勧めします。これによって、ディレクトリ ゲートキーパーを別々のロケーションに配置することができます。HSRP を使用するには、両方のディレクトリ ゲートキーパーを同じサブネットに置く必要があります。この場合常に 1 つのゲートキーパーしかアクティブにすることができません。
図 6-12 では、2 つのアクティブ ディレクトリ ゲートキーパーを備えた Cisco CallManager 分散型コール処理環境を示しています。
例6-11 および例6-12 では、図 6-12 の 2 つのディレクトリ ゲートキーパーの設定を示しています。
• 両方のディレクトリ ゲートキーパーはまったく同じように設定されます。
• ディレクトリ ゲートキーパー用にローカル ゾーンが設定されます。
• リモート ゲートキーパーごとに、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のリモート ゾーンにゾーン プレフィックスが設定されます。設定を簡単にするために、ゾーン プレフィックスでワイルドカード（*）が使用されます。コールは DGK ゾーンにルーティングされないので、DGK ゾーンにはプレフィックスは必要ありません。
• lrq forward-queries コマンドは、ディレクトリ ゲートキーパーが、別のゲートキーパーから受信した LRQ を転送できるようにします。
（注） ディレクトリ ゲートキーパーは、アクティブ エンドポイント登録を含まず、いかなる帯域幅管理も行いません。
例6-13、例6-14 および例6-15 では、図 6-12 のゲートキーパー 1 ～ 3 の設定を示しています。
ここでは、例6-13、例6-14、および例6-15 について説明します。
• Cisco CallManager トランク登録をサポートするために、各 Cisco CallManager クラスタにはローカル ゾーンが設定されます。
• ディレクトリ ゲートキーパーごとに、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、ローカル ゾーンと両方のリモート ゾーンにゾーン プレフィックスが設定されます。両方のディレクトリ ゲートキーパー プレフィックスは、10 個のドットです。一致するゾーン プレフィックスが設定されるとき、デフォルトで順次 LRQ が使用されます。ゲートキーパーは、コストが最低のディレクトリ ゲートキーパーに LRQ を送信します。応答がない場合、ゲートキーパーは、2 番目のディレクトリ ゲートキーパーに LRQ の送信を試みます。
• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、
bandwidth remote コマンドを使用します。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
フィードバック