Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月18日
章のタイトル： コール処理
コール処理
この章では、スケーラブルで復元性のあるコール処理システムの設計ガイドラインを示し、Cisco CallManager と H.323 ゲートキーパーの設計を中心に説明します。
Cisco CallManager アーキテクチャでは、複数の物理サーバを 1 つの IP PBX システムとして連携させることができます。このサーバ グループを「クラスタ」と呼びます。Cisco CallManager サーバのクラスタは、設計上の制限事項を遵守している限り、IP ネットワークを介して分散していてもかまいません。クラスタを使用することで、空間的な冗長性、およびそれに伴う復元性を IP Communications システムの設計にもたらすことができます。
シスコのゲートキーパーは、もう 1 台のスタンバイ ゲートキーパーとペアにすることも、クラスタ化してさらに高いパフォーマンスと復元性を実現することもできます。
Cisco CallManager クラスタのガイドライン
ここでは、Cisco CallManager クラスタを形成しているサーバが実行する各種の機能について説明し、必要な規模、パフォーマンス、および復元性を達成するようにサーバを配置する方法について、ガイドラインを示します。
ハードウェア プラットフォーム
Cisco CallManager クラスタでは、必要となる規模、パフォーマンス、および冗長性に応じて、さまざまなタイプのサーバを利用します。利用するサーバの範囲は、冗長性のないシングル プロセッサのサーバから、冗長性の高いマルチプロセッサ ユニットにまで及びます。
Cisco CallManager は、特定のハードウェア プラットフォーム上でのみサポートされます。現在サポートされているハードウェア コンフィギュレーションのリストについては、次の Web サイトにあるドキュメントを参照してください。
http://www.cisco.com/go/swonly
サーバ プラットフォームには、それぞれ固有のメモリ要件があります。この要件については、次の Web サイトにある製品情報 2864『 Physical Memory Recommendations For Cisco CallManager Version 4.0 and Later 』で説明しています。
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletin0900aecd80284099.html
表8-1 では、クラスタ内で使用できる一般的なサーバのタイプとその主な特性を一緒にリストしています。
|
|
|
|---|---|
サーバは、IP ネットワークに加えて電源と冷却についても可用性の高い環境に配置する必要があります。建物の電力が必要な可用性を備えていない場合は、サーバの電力を無停電電源装置（UPS）から供給する必要があります。二重化電源を備えたサーバについても、それぞれの電源を 2 つの異なる電力源に接続しておくと、1 つの電源回路が故障しただけでサーバに障害が発生することを回避できます。
IP ネットワークへの接続性によっても、最大限のパフォーマンスと可用性が保証されます。Cisco CallManager サーバは、イーサネットに 100 Mbps 全二重で接続する必要があります。小規模な配置で 100 Mbps が使用可能でない場合、10 Mbps 全二重を使用してください。比較的新しいサーバでは、多くの場合 1000 Mbps 全二重も選択肢の 1 つになります。この設定を行うには、ネットワーク インターフェイス カード（NIC）を 100 Mbps または 10 Mbps のデュプレックス モードに設定し、イーサネット スイッチ ポートも手動で調整します。
（注） サーバ ポートまたはイーサネット スイッチ ポートのどちらか一方が AUTO モードのままであり、もう一方のポートが手動で設定される場合、ミスマッチが生じます。最善の方法は、サーバ ポートとイーサネット スイッチ ポートの両方を手動で設定することです。
2 枚のイーサネット NIC を備えたサーバ プラットフォームでは、NIC チーミングをサポートできます。この機能は、使用できるかどうかは製造業者によって異なりますが、サーバを 2 枚の NIC、つまり 2 本のケーブルでイーサネットに接続できるようにするものです。この機能を利用すると冗長性が向上するため、特定の状況下では有益です。ただし、正しく配置するには、事前に IP インフラストラクチャを慎重に設計する必要があります。シスコおよび Hewlett-Packard（HP）のサーバ プラットフォームにチーミング ドライバをインストールする方法の詳細については、次の Web サイトにあるドキュメントを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/iptel_os/driver/hp_team7.htm
すべての Cisco CallManager クラスタに次のガイドラインが適用されます。
（注） 1 つのクラスタに複数のサーバ プラットフォームを組み合せることができますが、クラスタ内のすべてのサーバでは、同じ Cisco CallManager ソフトウェア リリースを実行する必要があります。
•
通常の環境では、同一 LAN または MAN 内にクラスタのすべてのメンバーを入れます。クラスタのすべてのメンバーを同一の VLAN またはスイッチに配置することは、お勧めしません。
• 冗長性を持たせるには、クラスタのメンバーを次のように配置して、インフラストラクチャや建物で発生した障害によって受ける影響を最小限に抑える必要があります。
–同じディストリビューション スイッチまたはコア スイッチに、複数のアクセス スイッチが接続されている
–複数のディストリビューション スイッチまたはコア スイッチに、複数のアクセス スイッチが接続されている
• クラスタが IP WAN にわたって構築されている場合、「IP WAN を介したクラスタ化」の項を参照して、IP WAN を介したクラスタリングのガイドラインに従ってください。
Cisco CallManager クラスタのサービス
Cisco CallManager クラスタの内部には、それぞれ固有のサービスを提供する複数のサーバが存在します。これらの各サービスは、同じ物理サーバ上で他のサービスと共存できます。たとえば、小規模なシステムでは、1 台のサーバがパブリッシャ、バックアップ サブスクライバ、Music On Hold（MOH）サーバ、TFTP サーバ、CTI Manager、およびコンファレンス ブリッジを兼ねることができます。クラスタの規模とパフォーマンスを強化する必要が高まった場合は、これらのサービスの多くを 1 台の専用物理サーバに移行する必要があります。
Cisco CallManager 3.3 および 4. x からは、1 つのクラスタに、20 のサーバを組み込めるようになりました。20 のサーバのうち、最大 8 つのサーバが、コール処理を提供する Cisco CallManager サービスを実行できます。残りのサーバは、専用データベース パブリッシャ、トリビアル ファイル転送プロトコル（TFTP）専用サーバ、または Music On Hold（MOH）サーバとして設定できます。メディア ストリーミング アプリケーション（コンファレンス ブリッジやメディア ターミネーション ポイント）も、クラスタに登録される別個のサーバにインストールできます。
Cisco MCS 7815 または同等のサーバを含んだクラスタを配置するときは、クラスタ内の 2 つのサーバに関して制限事項があります。1 台をパブリッシャ、TFTP サーバ、バックアップ コール処理サーバにし、もう 1 台をプライマリ コール処理サーバにします。この構成では、サポートされるユーザの最大数は 300 です。これよりキャパシティの大きいサーバを使用して 2 サーバ クラスタを配置する場合も、クラスタ内のユーザ数が 1,250 を超えないようにすることをお勧めします。1,250 ユーザを超える場合は、専用のパブリッシャを配置することをお勧めします。
シングル サーバ クラスタを配置することもできます。MCS 7825 または同等のサーバでは、上限は 500 ユーザです。これより可用性の高いサーバを使用する場合も、クラスタのユーザ数が 1,000 を超えないようにする必要があります。シングル サーバ構成では、Survivable Remote Site Telephony（SRST）も配置して、Cisco CallManager が使用不可になっている間にサービスが提供されるようにしない限り、冗長性はありません。シスコでは、実稼働環境でシングル サーバ配置を採用することはお勧めしません。ロード バランシングは、パブリッシャがバックアップ コール処理サブスクライバである場合には実装できません。
図8-1 では、一般的な Cisco CallManager クラスタを示しています。
図8-1 一般的な Cisco CallManager クラスタ
Cisco CallManager クラスタ内の通信（クラスタ内通信）には、2 種類あります（図8-2を参照）。1 つは、すべてのデバイス設定情報を含んでいるデータベースを配布するためのメカニズムです。コンフィギュレーション データベースは、パブリッシャ サーバに保存され、読み取り専用のコピーがクラスタのサブスクライバ メンバーに複製されます。パブリッシャで加えられた変更は、サブスクライバ データベースに伝達され、クラスタのメンバー全体で設定を一貫させると共に、データベースの空間的な冗長性を実行します。
2 タイプ目のクラスタ内通信は、デバイスの登録、ロケーションの帯域幅、共有メディア リソースなどのランタイム データの伝搬と複製です。この情報は、Cisco CallManager Service を実行している、クラスタのすべてのメンバー全体で共有されます。クラスタのメンバーと関連ゲートウェイとの間で、コールの最適なルーティングが確保されます。
Lightweight Directory Access Protocol（LDAP） ディレクトリ情報も、クラスタ内のすべてのサーバ間で複製されます。LDAP ディレクトリは、パブリッシャによって他のすべてのサーバに複製されます。Cisco CallManager は、Microsoft の Active Directory や Netscape Directory などの、企業の LDAP ディレクトリに統合できます。この複製は、配置される統合方式によって異なり、このマニュアルでは説明していません。ディレクトリ統合の詳細については、「ディレクトリ アクセスとディレクトリ統合」を参照してください。
パブリッシャ
「パブリッシャ」はすべてのクラスタに必要で、現在はクラスタごとに 1 つのみ配置できます。このサーバは、最初にインストールする必要があります。クラスタ内の他のすべてのメンバーに対して、データベース サービスとディレクトリ サービスを提供します。パブリッシャ サーバは、コンフィギュレーション データベースに読み取りと書き込みのアクセスができる唯一のサーバです。設定が変更されたとき、クラスタの他のメンバーは、データベースの読み取り専用コピーを保持します。1,250 ユーザを超える大規模なシステムの場合、パブリッシャ サーバ上ではコール処理を実行しないことをお勧めします。実行しないことで、管理操作がテレフォニー ユーザからの影響を受けなくなります。
クラスタ内のサーバは、初期化時にパブリッシャのデータベースを使用しようとします。パブリッシャが使用不可になっている場合は、自身のハード ドライブにあるローカルの読み取り専用コピーを使用します。
システムが動作していても、パブリッシャが使用不可になっている場合は、次の操作を実行できません。
• エクステンション モビリティのログイン操作およびログアウト操作
エクステンション モビリティは、データベースに読み取りと書き込みのアクセスを行う必要があるため、パブリッシャなしでは機能しません。したがって、このサービスはパブリッシャ上でのみ実行することをお勧めします。
パブリッシャ用のハードウェア プラットフォームは、クラスタの規模とパフォーマンスを基準として選択します。パブリッシャは、コール処理サブスクライバと同等のパフォーマンスを持つものにすることをお勧めします。可能な場合には、パブリッシャを高可用性サーバにして、ハードウェアの障害による影響を最小限に抑えるようにします。
コール処理サブスクライバ
Cisco CallManager ソフトウェアをインストールするときに、パブリッシャとサブスクライバという 2 タイプのサーバを定義できます。これらの用語は、データベース間の関係をインストール時に定義するために使用されています。ソフトウェアをインストールしたときに使用可能になる唯一のサービスが、データベース サービスです。すべてのサブスクライバは、パブリッシャをサブスクライブして、データベースとディレクトリの情報の読み取り専用コピーを取得します。
コール処理サブスクライバは、Cisco CallManager サービスが使用可能になっているサーバです。このサービスが使用可能になった時点で、このサーバはコール処理機能を実行できるようになります。電話、ゲートウェイ、メディア リソースなどのデバイスが登録やコール発信を実行できるのは、このサービスが使用可能になっているサーバに対してのみです。Cisco CallManager Release 3.3 より前では、このサービスを使用可能にできるのはクラスタ内の 6 つのサーバのみでした。これ以降のリリースでは、クラスタ内の 8 つまでのサーバで Cisco CallManager サービスを使用可能にできます。
選択した冗長性方式に応じて（「コール処理の冗長性」を参照）、コール処理サブスクライバは、プライマリ（アクティブ）サブスクライバまたはバックアップ（スタンバイ）サブスクライバのどちらかになります。ロード バランシングを実装する場合は、サブスクライバがプライマリ サブスクライバとバックアップ サブスクライバの両方を兼ねることもあります。クラスタの設計を計画するときは、通常はコール処理サブスクライバにこの機能を割り当てます。大規模なクラスタや高性能クラスタでは、パブリッシャおよび TFTP の機能をコール処理サーバ上で使用可能にしないでください。コール処理サブスクライバは、採用する冗長性方式に応じて、通常は専用ペアまたは共有ペアのどちらかで運用します。1：1 冗長性では、専用ペアを使用します。2：1 冗長性では、各ペアに含まれるサーバ 1 台（バックアップ サーバ）を共有する、2 組のサーバを使用します。
ハードウェア プラットフォームは、サーバの規模、パフォーマンス、冗長性、およびコストに応じて選択します。規模とパフォーマンスについては、「Cisco CallManager プラットフォームのキャパシティ プランニング」の項で説明しています。冗長性については、「コール処理の冗長性」の項で説明しています。
コール処理の冗長性
すべてのバージョンの Cisco CallManager で、次の冗長性設定の中から選択できます。
• 2:1 冗長性方式：プライマリ サブスクライバ 2 台ごとに、1 つの共用バックアップ サブスクライバを設置します。
• 1:1 冗長性方式：プライマリ サブスクライバごとに、1 つのバックアップ サブスクライバを設置します。
1:1 冗長性方式では、フェールオーバー期間だけがクラスタに影響を与えるアップグレードが可能です。このフェールオーバー メカニズムは、IP Phone のフェールオーバー レート、毎秒約 100 台の登録を実現できるように拡張されました。
1:1 冗長性方式で、クラスタをアップグレードする手順は、次のとおりです。
ステップ 2 TFTP 専用サーバを 1 台ずつアップグレードします。クラスタ内の他のサーバをアップグレードする前に、このサーバをリブートし、コンフィギュレーション ファイルが再作成されるまで待機します。
ステップ 3 Music On Hold（MOH）専用サーバおよびその他のメディア リソース サーバを 1 台ずつアップグレードします。
ステップ 4 バックアップ サブスクライバを 1 台ずつアップグレードします。50/50 ロード バランシングが設定されている場合、このステップは一部のユーザに影響を与えます。
ステップ 5 プライマリ サブスクライバをバックアップ サブスクライバにフェールオーバーし、プライマリ サブスクライバ上の Cisco CallManager サービスを停止します。
ステップ 6 プライマリ サブスクライバを 1 台ずつアップグレードしてから、Cisco CallManager サービスを再び使用可能にします。
このアップグレード方法では、異なるバージョンの Cisco CallManager ソフトウェアを実行しているサブスクライバ サーバにデバイスが登録される期間（フェールオーバー期間を除く）がありません。サブスクライバ間で通信する ICCS（Intra-Cluster Communication Signaling）プロトコルは、異なるソフトウェア バージョンを検出し、そのサブスクライバとの通信をシャットダウンする可能性があるので注意が必要です。
2:1 冗長性方式では、クラスタ内のサーバ数を減らすことができますが、その結果、アップグレード時に障害が発生する可能性があります。
（注） 10,000 台以上の IP Phone が 2 つのプライマリ サブスクライバに登録される場合は、1:1 冗長性を使用する必要があります。これは、1 つのバックアップ サブスクライバで 10,000 台以上のバックアップ登録はできないからです。
コール処理サブスクライバの冗長性
次の図では、Cisco CallManager でコール処理の冗長性を実現するための一般的なクラスタ構成を示しています。
図8-3 では、利用できる 2 つの基本的な冗長性方式を示しています。どちらの場合でも、バックアップ サーバは、障害の発生するプライマリコール処理サーバ 1 台分以上の処理能力を備えている必要があります。2：1 冗長性方式の場合、バックアップ サーバは、個々の配置の要件に応じて、障害の発生するコール処理サーバ 1 台分、または両方のプライマリ コール処理サーバに相当する処理能力を備えている必要があります。サーバのキャパシティの選定およびハードウェア プラットフォームの選択については、「Cisco CallManager プラットフォームのキャパシティ プランニング」の項で説明しています。
図8-4 に示した 5 つは、すべて 1：1 冗長性のオプションを示しています。オプション 1 は、1,250 人未満のユーザをサポートするクラスタに使用します。オプション 2 ～ 5 は、クラスタを徐々に拡張した様子を示しています。正確な規模は、選択したハードウェア プラットフォームや必要なハードウェア プラットフォームによって異なります。
この図では、パブリッシャとコール処理サブスクライバのみ示していることに注意してください。
ロード バランシング
1:1 冗長性方式を使用するもう 1 つの利点は、プライマリ サーバとバックアップ サーバのペア上でデバイスのバランスを取ることができる点です。通常、プライマリが使用可能な場合、バックアップ サーバに登録されたデバイスはありません。
ロード バランシングを使用すると、Cisco CallManager の冗長性グループとデバイス プールの設定値を使用して、デバイスにかかる負荷の半分までをプライマリ サブスクライバからセカンダリ サブスクライバに移すことができます。この方法で、サーバが使用不能になる影響を 50% 減らすことができます。
50/50 ロード バランシングを計画するには、ロード バランシングを使用しない場合のクラスタのキャパシティを計算し、次に、デバイスおよびコールの量に基づいて、負荷をプライマリ サブスクライバとバックアップ サブスクライバに分散します。プライマリ サブスクライバやバックアップ サブスクライバの障害に対処できるようにするには、プライマリとバックアップのサブスクライバの合計負荷が、サブスクライバ 1 台分の負荷を超えないようにします。
すべてのアクティブ サブスクライバにわたって、デバイスとコールの量をできる限り等しく分散することをお勧めします。たとえば、ゲートウェイ、トランク、ボイスメール ポート、ユーザをすべてのサブスクライバに等しく分散すると、障害による影響が最も小さくなります。
TFTP サーバ
TFTP サーバ プラットフォームには、主に次の 2 つの機能があります。
• MOH などのサービスのためのファイル、電話やゲートウェイなどのデバイスのコンフィギュレーション ファイル、電話および一部のゲートウェイのアップグレード用バイナリ ファイル、およびさまざまなセキュリティ ファイルの提供。
• コンフィギュレーション ファイルおよびセキュリティ ファイルの生成。シスコの TFTP サービスが生成するファイルのほとんどは、署名済みであり、ダウンロード用として提供する前に暗号化されることもあります。
TFTP サービスは、クラスタ内の任意のサーバで使用可能にすることができます。ただし、何らかの設定を変更すると、TFTP サービスがコンフィギュレーション ファイルを再生成するため、1,250 ユーザを超えるクラスタでは、他のサービスが影響を受ける場合があります。このため、1,250 ユーザを超えるクラスタ、エクステンション モビリティを使用するクラスタ、または設定の変更を伴うその他の機能を備えたクラスタでは、特定のサーバを TFTP サービス専用にすることをお勧めします。
TFTP サーバは、設定情報を取得するために電話および MGCP ゲートウェイが使用します。クラスタのサイズが大きくなった場合や、冗長性を強化する必要がある場合は、ロード バランシングおよび冗長性のために TFTP サーバを 2 台配置することをお勧めします。DHCP を使用して、または静的に TFTP オプションを設定するときは、TFTP サーバの IP アドレス アレイを定義するようにします。つまり、TFTP サーバのアドレスを複数定義します。このように定義すると、半数のデバイスでは TFTP サーバ A をプライマリとして使用し、TFTP サーバ B をバックアップとして使用するように割り当てて、他の半数のデバイスでは、TFTP サーバ B をプライマリとして使用し、TFTP サーバ A をバックアップとして使用するように割り当てることができます。TFTP 専用サーバのパフォーマンスを向上させるには、サービス パラメータを設定して、サーバ上で許容する同時 TFTP セッションの数を増やします。
Cisco CallManager クラスタをアップグレードするときは、パブリッシャの後に TFTP サーバをアップグレードし、次にその他のサーバをアップグレードすることを強くお勧めします。また、TFTP サーバをアップグレードした後は、すべてのコンフィギュレーション ファイルが再作成されるように十分な間隔を空けます。一般的な Cisco TFTP の BuildDuration 時間を使用するか、パフォーマンス モニタを使用して Cisco TFTP の DeviceBuildCount を監視して、これらの増加が止まるまで監視します。このアップグレード順序に従うと、新しいバイナリと設定変更が、クラスタ内の他のサービスをアップグレードする前に有効になります。電話やゲートウェイの個々のバイナリまたはファームウェア ロードを手動で追加する場合は、ファイルを必ずクラスタ内の各 TFTP サーバにコピーしてください。
Cisco CallManager Release 3.3 以降では、電話機のコンフィギュレーション ファイルは、旧バージョンの Cisco CallManager のように、TFTP サーバのハード ドライブにデフォルトで保存されることはありません。デフォルトでは、電話機のすべてのコンフィギュレーション ファイルは作成されると、TFTP サーバ上の RAM に置かれます。このデフォルト設定を変更して、電話機のコンフィギュレーション ファイルを TFTP サーバのハード ドライブに入れることができますが、これを行うと、TFTP のパフォーマンスに影響があります。したがって、このデフォルト設定を変更しないことをお勧めします。
CTI Manager
CTI Manager は、クラスタ上で TAPI または JTAPI コンピュータ/テレフォニー インテグレーション（CTI）を使用するアプリケーションに必要となるものです。CTI Manager は、CTI アプリケーションと Cisco CallManager サービスの仲介者として機能します。アプリケーションの認証機能を提供し、許可済みのデバイスを制御および監視できるようにします。CTI アプリケーションはプライマリ CTI Manager と通信し、障害発生時にはバックアップ CTI Manager に切り替えます。CTI Manager は、コール処理サブスクライバ上でのみ使用可能にする必要があります。したがって、クラスタ内では最大で 8 つの CTI Manager を使用できます（Cisco CallManager Release 3.3 より前のリリースでは 6 つ）。復元性、パフォーマンス、および冗長性を最大限まで高めるには、CTI アプリケーションの負荷をクラスタ内の複数の CTI Manager に分散することをお勧めします。
一般に、アプリケーションによって制御または監視されるデバイスは、CTI Manager に使用するものと同じサーバ ペアに関連付けることをお勧めします。たとえば、IVR（interactive voice response; 音声自動応答装置）アプリケーションでは 4 つの CTI ポートが必要になります。1：1 冗長性と 50/50 ロード バランシングを使用する場合は、これらを次のように設定します。
• 2 つの CTI ポートは、サーバ A をプライマリ、サーバ B をバックアップ（セカンダリ）とする Cisco CallManager 冗長性グループを持っています。他の 2 つの CTI ポートは、サーバ B をプライマリ、サーバ A をバックアップとする Cisco CallManager 冗長性グループを持っています。
• IVR アプリケーションは、サーバ A 上の CTI Manager をプライマリ、サーバ B をバックアップとして使用するように設定します。
上の例は、サーバ A 上の CTI Manager で障害が発生した場合の冗長性を備えており、IVR コールの負荷を 2 つのサーバに分散することもできています。この方法では、CTI Manager サーバの障害による影響も最小限に抑えることができます。
メディア リソース
会議や Music On Hold などのメディア リソースは、Cisco CallManager サービスと同じ物理サーバ上で動作している、ソフトウェア サービスによって提供されます。
• Music On Hold（MOH）：保留状態になっているデバイス、会議に転送または追加されるデバイスに対して、マルチキャストまたはユニキャストの保留音を提供できます（「Music on Hold」を参照）。
• Annunciator サービス：電話番号を間違えていることや、コール ルーティングが使用不可になっていることを伝える場合に、トーンの代わりに音声アナウンスを流します（「Annunciator」を参照）。
• コンファレンス ブリッジ：Ad Hoc 会議と Meet-Me 会議のための、ソフトウェア ベースの会議を提供します（「会議」を参照）。
• メディア ターミネーション ポイント（MTP）サービス：H.323 クライアント、H.323 トランク、および Session Initiation Protocol（SIP）トランク用の機能を提供します（「メディア ターミネーション ポイント（MTP）」を参照）。
クラスタ内でメディア リソースを実行する場合は、メディアの処理とネットワークに関する要件が追加される場合に備えて、すべてのガイドラインに準拠することが重要です。一般に、マルチキャスト MOH と Annunciator には専用サーバを使用せず、ソフトウェア ベースの大規模な会議と MTP に専用サーバを使用することをお勧めします（これらのサービスが、「メディア リソース」、「Music on Hold」で説明している設計ガイドラインの範囲内にない場合は除きます）。
音声アクティビティ検出
クラスタ内で音声アクティビティ検出（VAD）も使用不可にしておくことをお勧めします。デフォルトでは、Cisco CallManager サービス パラメータで VAD は使用不可になっています。H.323 ダイヤルピア上で使用不可にするには、 no vad コマンドを使用してください。
エクステンション モビリティ
クラスタ内でエクステンション モビリティを使用する場合は、必要となるキャパシティおよびパフォーマンスに応じて、選択するパブリッシャ ハードウェア プラットフォームが異なってきます。ユーザが電話でログインまたはログアウトしたときに、コンフィギュレーション データベースに含まれているコンフィギュレーションをアップデートし、TFTP サービスでコンフィギュレーション ファイルを再生成し、次にデバイスをリセットして、変更内容を有効にする必要があります。これらの処理のほとんどは、パブリッシャ上で発生します。
エクステンション モビリティでサポートサポートされている、現時点での上限は次のとおりです。
• Cisco CallManager Release 3.3
–1 時間あたりの順次ログインまたはログアウト：2,000 回
• Cisco CallManager Release 4.0
–1 時間あたりの順次ログインまたはログアウト：2,000 回
• Cisco CallManager Release 4.1
Cisco CallManager プラットフォームのキャパシティ プランニング
Cisco CallManager には、タイプの異なるデバイスを登録できます。たとえば、IP Phone、ボイスメール ポート、CTI（TAPI または JTAPI）デバイス、ゲートウェイ、および DSP リソース（トランスコーディングや会議）などです。これらの各デバイスは、登録先となるサーバ プラットフォームのリソースを必要とします。必要なリソースには、メモリ、プロセッサ使用、およびディスク I/O が含まれます。各デバイスは、トランザクション（通常、コールの形式）中に、追加のサーバ リソースを消費します。たとえば、1 時間当たり 6 回のコールだけを行うデバイスが消費するリソースは、1 時間当たり 12 回のコールを行うデバイスより少なくなります。
この項で示す推奨事項は、Cisco CallManager Capacity Calculator を、デフォルトのトレース レベルと CDR を有効にして使用し、その結果として得た計算に基づいています。コール処理に直接関係しない他の機能を使用不可にしたり、縮小したり、再設定したりすると、より高いレベルのパフォーマンスが得られます。こうした機能の一部を増やすと、システムのコール処理機能に影響を与える可能性があります。これらの機能には、トレース、コール詳細レコード、複雑なダイヤル プラン、およびサーバ上に共存するその他のサービスが含まれます。複雑なダイヤル プランには、複数のライン アピアランス、多くのパーティション、コーリング サーチ スペース、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、自動転送の拡張使用、共存サービス、およびその他の共存アプリケーションが含まれています。こうした機能はすべて、Cisco CallManager サーバ内の追加リソースを消費します。
パフォーマンスを向上させるために、次のテクニックを活用すると便利なオプションが提供されます。
• 特定プラットフォームにサポートされている最大量まで、サーバに追加の保証メモリを取り付ける。MCS 7825 および MCS 7835、または同等のサーバ クラスの大規模構成では、これらのサーバの RAM を倍に増やすことをお勧めします。このメモリ アップグレードが必要かどうかは、パフォーマンス モニタを使用して検証することでわかります。サーバが物理メモリを最大量近くまで使用すると、オペレーティング システムは、ディスクへのスワップを開始します。このスワッピングが発生した場合は、追加の物理メモリを取り付ける必要があることを示しています。個々のサーバのメモリに関する推奨事項については、次の Web サイトにある製品情報 2864『 Physical Memory Recommendations For Cisco CallManager Version 4.0 and Later 』を参照してください。
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletin0900aecd80284099.html
• サポートされているハードウェア上で、書き込みキャパシティ 50% のバッテリ バックアップ付き書き込みキャッシュ（BBWC）を使用可能にする。この機能を使用する場合は、Small Computer System Interface（SCSI）コントローラ カードにバッテリを追加する必要が生じることがあります。
• MCS 7845 または同等のサーバ上で、トレース ファイルの位置を F: ドライブに設定する。この設定は、Cisco CallManager のサービス パラメータです。
• トレース ファイルのパーティションを再フォーマットして、小さなブロック サイズを使用するようにする（インストール済みオペレーティング システムのリリース ノートを参照）。この目的のためのユーティリティが提供されています。
多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大きなダイヤル プランをもつ Cisco CallManager クラスタでは、Cisco CallManager Service の初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、サービス パラメータを変更して、設定の初期化時間を延長してください。サービス パラメータの詳細については、Cisco CallManager Administration オンライン ヘルプの「 Service Parameters 」を参照してください。
Cisco CallManager Release 3.1 および 3.2 を使用したコール処理
Cisco CallManager Release 3.1 および 3.2 には、次のガイドラインが適用されます。
• クラスタ内では、Cisco CallManager Service を使用して最大 6 台のサーバ（4 台のプライマリ サーバと 2 台のバックアップ サーバ）を使用可能にすることができます。それ以外のサーバは、TFTP（Trivial File Transfer Protocol）、データベース パブリッシャ、Music on Hold などの専用機能に使用できます。
• サーバごとにコンピュータ/テレフォニー インテグレーション（CTI）接続またはアソシエーションを最大 800 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 3,200 を設定できます。
• 各 H.323 デバイスは、Cisco CallManager Release 3.1 では H.323 コールを最大 500 件、Cisco CallManager Release 3.2 では H.323 コールを最大 1,000 件までサポートできます。
• 各クラスタは、最大 600 台の H.323（ゲートウェイとクライアント）デバイス、およびデジタル MGCP デバイスをサポートできます。
Cisco CallManager Release 3.3 以降を使用したコール処理
Cisco CallManager Release 3.3 以降には、次のガイドラインが適用されます。
• クラスタ内では、Cisco CallManager Service を使用して最大 8 台のサーバを使用可能にすることができます。それ以外のサーバは、TFTP、パブリッシャ、Music on Hold などの専用機能に使用できます。
• 標準サーバごとに CTI 接続またはアソシエーションを最大 800 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 3200 設定できます。
• 高性能サーバごとに CTI 接続またはアソシエーションを最大 2,500 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 10,000 設定できます。
• 各クラスタは、最大 30,000 台の IP Phone をサポートできます。
• 各クラスタは、最大 600 台の H.323（ゲートウェイとクライアント）デバイス、およびデジタル MGCP デバイスをサポートできます。
キャパシティの計算
以前のソフトウェア リリースでは、システムのキャパシティを計算するために、デバイスの重み、BHCA 係数、ダイヤル プランの重みを使用した、各種の方式を使用していました。Cisco CallManager Release 4. x では、この単純な方式がキャパシティ ツールで置き換えられ、より正確なシステム プランニングを実現しました（「Cisco CallManager キャパシティ ツール」を参照）。キャパシティ プランニング ツールを使用できるのは、現時点ではシスコの従業員とシスコ代理店のみです。システムが次のガイドラインを満たしていない場合や、システムをさらに複雑にするためにキャパシティを確認する必要がある場合は、シスコのシステム エンジニアまたは Cisco Technical Assistance Center（TAC）にお問い合せください。
システムが次の要件を満たしている場合は、コンフィギュレーションを Cisco CallManager キャパシティ ツールで確認する必要はありません。
• システムに含まれているユーザ数が、サーバ プラットフォームの最大ユーザ数の 25% 未満である。
• ユーザごとの平均の Busy Hour Call Attempt（BHCA）が、1 時間あたり 6 コール未満である。
• ゲートウェイまたはトランクのどちらかを経由するトランキングが、20%（1 トランクあたり 5 ユーザ）以下である。
• ボイスメール ポートが 5%（1 ボイスメール ポートあたり 20 ユーザ）以下である。
• サーバ 1 台あたりの MOH ストリームが 20 以下である。
• CTI、JTAPI、および TAPI のデバイスがない。
• コンファレンス ブリッジが 5%（ブリッジ上の 1 ポートあたり 20 ユーザ）以下である。
• トランキングに必要な最大コールをサポートする目的では、MTP のみ使用する。
• システムには、上に定義されていないもの以外は、IP Phone、IP Communicator、ゲートウェイ、メディア リソース、ボイスメール ポート、トランクしか含まれていない。
Cisco CallManager がサポートできるユーザの最大数は、サーバ プラットフォームによって異なります（ 表8-2 を参照）。
|
|
|
|
|
|---|---|---|---|
Cisco MCS-7845（全モデル）3 |
|||
Cisco MCS-7815（全モデル）4 |
サポートされるプラットフォーム、サードパーティ プラットフォーム、個々のハードウェア設定の最新情報については、次の Web サイトにあるオンライン資料を参照してください。
http://www.cisco.com/go/swonly
（注） 高可用性に対応していないプラットフォームの場合は、非冗長インストレーションとして、サポートされる IP Phone の最大数は、500 台になります。
Cisco CallManager キャパシティ ツール
Cisco CallManager キャパシティ ツールは、さまざまな情報を要求して、システムに必要となるサーバの最小限のサイズとタイプについて、見積もりを提示します。要求される情報には、IP Phone、ゲートウェイ、メディア リソースなどのデバイスの、タイプと数が含まれています。キャパシティ ツールは、デバイス タイプごとに 平均 BHCA と平均利用時間も要求します。たとえば、IP Phone で 1 時間あたり平均 5 件のコールが発生し、コールの平均持続時間が 3 分である場合、BHCA は 5 で、利用時間は 0.25 です（電話機上で 3 分間のコールが 5 件発生しているため、1 時間あたり 15 分、つまり 0.25 時間に相当します）。
デバイス情報に加えて、ルート パターンやトランスレーション パターンなどの、ダイヤル プランに関する情報も要求します。詳細をすべて入力すると、目的のサーバ タイプのプライマリ サーバがいくつ必要になるかについて、キャパシティ ツールが計算します。必要なキャパシティがクラスタ 1 つ分のキャパシティを超える場合は、クラスタの数も計算します。
キャパシティ ツールは、以前にデバイスの重み、BHCA 係数、コール タイプ係数、ダイヤル プランの重みと呼ばれていたメカニズムを置き換えるものです。
電話機に関する計算
この値は、クラスタ内に設定する Skinny Client Control Protocol（SCCP）電話の合計数です。この数には、Cisco 7900 シリーズのすべての IP Phone、VG248 ポート、IP Communicator、およびその他のサードパーティ SCCP エンドポイント デバイスを含めます。この数には、アクティブになっていないものも含めて、設定済みのすべての電話を含める必要があります。
この値は、すべての電話の平均 BHCA です。複数の電話で共用している回線がある場合、BHCA には、回線を共用しているそれぞれの電話のコールを 1 つとして含める必要があります。つまり、共用回線への 1 つのコールは、複数のコールとして計算します。それぞれ別の BHCA を生成する複数の電話グループがある場合、Cisco CallManager キャパシティ ツールで使用する BHCA 値は、次の方法で指定します。
• 20 BHCA の電話 100 台 = 合計 2,000 BHCA
• 4 BHCA の電話 5,000 台 = 合計 20,000 BHCA
すべての電話デバイスの合計 BHCA は、この場合 22,000 です。
この合計 BHCA を電話デバイスの合計数で除算して、次の値を算出します。
電話デバイス 1 台あたりの平均 BHCA = 22,000/5,100 = 4.31 BHCA
この値は、電話ごとの平均コール使用率です。コールが電話上に存在した、すべての時間を含めます。電話の実際の使用率は、100% を超えることがあります。これは、電話が 1 回線あたり複数のコールを許可しているか、頻繁に使用される複数のライン アピアランスを備えている場合です。使用率は、1 時間における百分率で測定します。たとえば、最も混雑している時間に 3 分間のコールが発生した電話は、5% 使用されたものと見なします。BHCA の計算と同じ方法を、複数の電話グループがある場合の平均使用率の計算にも使用することができます。電話に共用回線がある場合は、その電話の予想使用率のみ計算し、共用されている回線の実際の使用率は計算しません。Cisco CallManager キャパシティ ツールで使用できるのは、現時点では、すべての電話の平均使用率です。
この値は、すべての電話の平均回線数です。同じ DN を持つ電話が複数のパーティション内に出現している場合は、複数のライン アピアランスと見なします。共用回線は 1 つの回線としてカウントしますが、BHCA と使用率が正しく計算されていることを確認してください。回線ごとに複数のコールが発生した場合、ライン アピアランスの数は増加しませんが、BHCA と使用率の計算には影響します。
ゲートウェイ
ゲートウェイの数は、ゲートウェイのタイプに応じて異なるため、次のいくつかのエントリに分けられています。
この値は、Cisco CallManager データベース内に設定する必要のあるゲートウェイの合計数です。たとえば、Cisco IOS MGCP ゲートウェイは複数の T1 または E1 を保持できますが、単一のゲートウェイとして追加します。Cisco WS-6608 モジュールは、T1 または E1 ゲートウェイとして設定されているポートごとに、1 モジュールあたり最大で 8 つまで、ゲートウェイとして追加します。
この値は、Cisco CallManager データベースに追加するアナログ ゲートウェイの合計数です。通常は、モジュール全体（WS-6624 または Cisco CallManager）またはハードウェア プラットフォーム（Cisco IOS ルータ プラットフォーム）を 1 つのゲートウェイとして追加します。
モジュール全体またはハードウェア プラットフォームを、1 つのゲートウェイとして追加します。この数には、Cisco CallManager に定義されていないものの、H.323 トランク経由で使用される H.323 ゲートウェイは含みません。
この値は、各タイプのゲートウェイがサポートする DS0 またはアナログ ポートの合計数です。DS0 の数は、次のように、ゲートウェイのタイプによって分かれています。
（DS0 の合計数） /（すべてのデジタル、アナログ、IP インターフェイス上でサポートされるコールの数）
この BHCA は、最も混雑している時間における、ゲートウェイ上のすべての DS0 またはアナログ ポートの平均値です。この平均値を計算する方法は、電話の BHCA に使用する方法と同じです。
この値は、最も混雑している時間における、すべての DS0 またはアナログ ポートの平均使用率です。
エクステンション モビリティ（EM）プロファイルには、電話の計算でも含めている、ライン アピアランスを含めます。エクステンション モビリティは、デバイスの数には影響しませんが、電話ごとのライン アピアランスの平均数が増加します。EM ユーザの BHCA および使用率は、ユーザのログイン先となる電話について、すでに計算したものです。
H.323 と SIP のトランク
この値は、Cisco CallManager データベース内に設定されるトランクの合計数です。ゲートキーパーが制御するトランクは、宛先の数の影響を受けません。このため、設定済みのゲートキーパー制御トランクごとに 1 つとしてカウントします。これは、Session Initiation Protocol（SIP）プロキシを使用する SIP トランクにも当てはまります。
この値は、すべてのトランク上で許容できる同時発生コールの合計数です。許容されるコールの数は、通常はロケーションまたはゲートキーパーのコール アドミッション制御によって制御されます。許容されるコールの数には、リージョンとコーデックも影響することに注意してください。
この値は、すべてのトランクにわたる、すべてのコールの平均使用率です。これは、最も混雑している時間における百分率（%）です。使用率が 75% の場合は、コールが 1 時間あたり 45 分アクティブであることを意味します。
MTP の要件についても、カルキュレータで別個に検討する必要があります。H.323 トランク上で MTP が必要となる場合（SIP トランクでは必須）、そのトランク上でのすべての同時発生コールで、MTP リソースが必要になります。
ゲートキーパーの考慮事項
1 台の Cisco IOS ゲートキーパーで、分散型コール処理環境で最大 100 の Cisco CallManager クラスタに対してコール ルーティングとコール アドミッション制御をサポートできます。複数のゲートキーパーを設定すると、数千の Cisco CallManager クラスタをサポートできます。Cisco IOS ゲートキーパーを使用して、H.323 ゲートウェイと Cisco CallManager 間の通信とコール アドミッション制御をサポートすることによって、ハイブリッド Cisco CallManager とトール バイパス ネットワークを実装することもできます。
ゲートキーパーのコール アドミッション制御は、ポリシーベースの方式であり、使用可能なリソースの静的設定を必要とします。ゲートキーパーは、ネットワーク トポロジを認識しないので、ハブアンドスポーク トポロジに制限されます。
Cisco 2600、2800、3600、3700、3800、および 7200 シリーズのルータはすべて、ゲートキーパー機能をサポートします。冗長性、ロード バランシング、および階層コール ルーティング用に、さまざまな方法で Cisco IOS ゲートキーパーを設定できます。この項では、ゲートキーパー ネットワークを構築するための設計要件について検討します。ただし、コール アドミッション制御やダイヤル プラン解決については扱いません。これらについては、「コール アドミッション制御」と 「ダイヤル プラン」でそれぞれ説明しています。
ゲートキーパーの詳細については、次の Web サイトで入手可能な『 Cisco IOS H.323 Configuration Guide 』を参照してください。
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configuration_guide_book09186a00801fcee1.html
ハードウェア プラットフォームの選択
ゲートキーパーのプラットフォームは、1 秒間あたりのコール数、および同時発生コール数に基づいて選択します。1 秒間あたりのコール数が多いほど、Cisco 3700、3800、7200 シリーズ ルータなどの高性能な CPU が必要になります。同時発生コールの数が大きいほど、より多くのメモリが必要になります。プラットフォームの選択に関する最新情報については、シスコ代理店またはシスコのシステム エンジニア（SE）にお問い合せください。
ゲートキーパーの冗長性
ゲートキーパーが、クラスタ間通信にすべてのコール ルーティングとアドミッション制御機能をサポートする場合は、冗長性が必要です。Cisco CallManager Release 3.3 より前では、ゲートキーパーの冗長性をサポートする方法は、ホットスタンバイ ルータ プロトコル（HSRP） だけでした。Cisco CallManager Release 3.3 以降、ゲートキーパーの冗長性をサポートする方法として、ゲートキーパー クラスタリングと冗長ゲートキーパー トランクも使用できるようになりました。次の項では、これらの方法について説明します。
（注） 可能な場合、ゲートキーパーの冗長性をサポートするには、ゲートキーパー クラスタリングを使用することをお勧めします。冗長性に HSRP を使用するのは、ソフトウェア機能セットでゲートキーパー クラスタリングが利用できない場合だけにしてください。
ホットスタンバイ ルータ プロトコル（HSRP）
Release 3.3 より前の Cisco CallManager では、ゲートキーパーの冗長性には、ホットスタンバイ ルータ プロトコル（HSRP） しか選択できませんでした。HSRP は、冗長かつスケーラブルなゲートキーパー ネットワークの構築に必要な機能をサポートしないので、Release 3.3 より前の Cisco CallManager 環境でのみ使用してください。
• 一度に 1 つのゲートキーパーしかアクティブになりません。
–スタンバイ ゲートキーパーは、プライマリに障害が発生した場合でなければ、コールを処理しません。
• すべてのゲートキーパーが同じサブネットまたはロケーションに存在しなければなりません。
• フェールオーバー後、スタンバイ ゲートキーパーは、すでにアクティブになっているコールを認識しないので、帯域幅のオーバーサブスクリプションが発生する可能性があります。
• コールの発信前に、HSRP スタンバイ ゲートキーパーにエンドポイントを再登録する必要があるので、フェールオーバーには相応の時間がかかることがあります。フェールオーバー時間は、登録タイマーの設定に依存します。
図8-6 では、ゲートキーパーの冗長性に HSRP を使用するネットワーク設定を示しています。
例8-1 では、図8-6 のゲートキーパー 1 の設定を示しています。例8-2 では、ゲートキーパー 2 の設定を示しています。イーサネット インターフェイス上の HSRP 設定を除いて、両方の設定は同一です。
• 各ルータには、それぞれが共有する仮想 IP アドレスを識別するために、HSRP 用に standby コマンドが設定されます。ゲートキーパー 1 は、コマンド standby priority 110 を使用して、プライマリとして設定されています。
• Cisco CallManager トランク登録をサポートするために、各 Cisco CallManager クラスタには、各ルータ上でローカル ゾーンが設定されます。最初のゾーンに定義されている IP アドレスは、HSRP の使用する仮想 IP アドレスと一致する必要があることに注意してください。
• ゾーン間とクラスタ間のコール ルーティングを可能にするために、両方のルータでゾーンごとにゾーン プレフィックスが設定されます。
• 各ルータで、両方のサイトの帯域幅ステートメントが設定されます。シスコでは、 bandwidth interzone コマンドを使用することをお勧めします。 bandwidth total コマンドは、設定内容によっては機能しないことがあるためです。
• ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できるように、 gw-type-prefix 1# default-technology コマンドが両方のルータで設定されます。この例では、すべての Cisco CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• 冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避するために、 arq reject-unknown-prefix コマンドが両方のルータで設定されます。
HSRP に関するこの他の高度な情報については、次の Web サイトにあるオンライン ドキュメントを参照してください。
• http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm
ゲートキーパー クラスタリング（代替ゲートキーパー）
ゲートキーパー クラスタリング（代替ゲートキーパー）により、「ローカル」ゲートキーパー クラスタの設定が可能になります。各ゲートキーパーは、一部の Cisco CallManager トランクのプライマリ、およびその他のトランクの代替として機能します。GUP（Gatekeeper Update Protocol）は、ローカル クラスタ内のゲートキーパー間で状態情報を交換するために使用されます。GUP は、クラスタ内のゲートキーパーごとに CPU 使用率、メモリ使用率、アクティブ コール数、および登録されたエンドポイント数をトラッキングし、報告します。GUP メッセージングで次のパラメータにしきい値を設定すると、ロード バランシングがサポートされます。
ゲートキーパー クラスタリング（代替ゲートキーパー）と Cisco CallManager Release 3.3 以降のサポートにより、ステートフル冗長性とロード バランシングが使用可能になります。ゲートキーパー クラスタリングは、次の機能を提供します。
• ローカル クラスタ内のゲートキーパーを、別々のサブネットまたはロケーションに配置可能
• フェールオーバーの遅延なし（代替ゲートキーパーはすでにエンドポイントを認識しているので、完全な登録プロセスを実行する必要はありません）
• クラスタ内のゲートキーパーは、状態情報を渡し、ロード バランシングを行う
図8-7 では、Cisco CallManager 分散型コール処理を行う 3 つのサイト、およびローカル クラスタで設定された 3 つの分散型ゲートキーパーを示しています。
図8-7 では、ゲートキーパー 2 はゲートキーパー 1 のバックアップ、ゲートキーパー 3 はゲートキーパー 2 のバックアップ、ゲートキーパー 1 はゲートキーパー 3 のバックアップです。
例8-3 では、ゲートキーパー 1（SJC）の設定を示し、例8-4 は、ゲートキーパー 2（CHC）の設定を示しています。ゲートキーパー 3（NYC） の設定は、他の 2 つの例を参照してください。
例8-3 ゲートキーパー 1 のゲートキーパー クラスタリング設定
例8-4 ゲートキーパー 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） を送信する必要はありません。
例8-5 では、ゲートキーパー 1（SJC）での show gatekeeper endpoints コマンドからの出力を示します。
ディレクトリ ゲートキーパーの冗長性
HSRP を使用するか、複数の同じディレクトリ ゲートキーパーを設定すると、ディレクトリ ゲートキーパーの冗長性を実装できます。同じゾーン プレフィックスを使用して、複数のリモート ゾーンをもつゲートキーパーを設定するとき、このゲートキーパーには、次のいずれかの方法が使用できます。
冗長リモート ゾーン（ゾーン プレフィックスが一致）にコストが割り当てられ、LRQ は、コスト値に基づいた順序で、一致するゾーンに送信されます。順次 LRQ を使用すると、一致するすべてのゲートキーパーに LRQ を送信しないので、WAN 帯域幅の節約になります。
LRQ は、冗長ゾーン（ゾーン プレフィックスが一致）に同時に送信されます。ロケーション確認（LCF） で応答する最初のゲートキーパーが、使用されます。
順次 LRQ を使用して複数のアクティブ ディレクトリ ゲートキーパーを使用することをお勧めします。これによって、ディレクトリ ゲートキーパーを別々のロケーションに配置することができます。HSRP を使用するには、両方のディレクトリ ゲートキーパーを同じサブネットに置く必要があります。この場合常に 1 つのゲートキーパーしかアクティブにすることができません。
図8-8 では、2 つのアクティブ ディレクトリ ゲートキーパーを備えた Cisco CallManager 分散型コール処理環境を示しています。
例8-6 および例8-7 では、図8-8 の 2 つのディレクトリ ゲートキーパーの設定を示しています。
• 両方のディレクトリ ゲートキーパーはまったく同じように設定されます。
• ディレクトリ ゲートキーパー用にローカル ゾーンが設定されます。
• リモート ゲートキーパーごとに、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のリモート ゾーンにゾーン プレフィックスが設定されます。ワイルドカード（*）をゾーン プレフィックスに使用すると設定を簡潔化できますが、ドット（.）を使用する方がきめ細かく設定できます。コールは DGK ゾーンにルーティングされないので、DGK ゾーンにはプレフィックスは必要ありません。
• lrq forward-queries コマンドは、ディレクトリ ゲートキーパーが、別のゲートキーパーから受信した LRQ を転送できるようにします。
（注） ディレクトリ ゲートキーパーは、アクティブ エンドポイント登録を含まず、いかなる帯域幅管理も行いません。
例8-8、例8-9、および例8-10 では、図8-8 のゲートキーパー 1 ～ 3 の設定を示しています。
ここでは、例8-8、例8-9、および例8-10 について説明します。
• 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 トランク上にできるコール ルーティング ループを回避します。
Cisco CallManager と CallManager Express の相互運用性
この項では、H.323 プロトコルを使用している Cisco CallManager と Cisco CallManager Express（CME。以前に Cisco IOS Telephony Services（ITS）と呼ばれていた製品）に関して、マルチサイト IP テレフォニー配置における相互運用性、およびインターネットワーキングの要件について説明します。ここでは、Cisco CallManager の制御する電話と CME の制御する電話間でのコール転送や自動転送など、補足サービスを中心に説明します。
Cisco CallManager と CME を相互運用するには、少なくとも次のソフトウェア リリースが必要です。
• Cisco CallManager Express Release 3.1 以降、Cisco IOS Release 12.3(7)T 以降、および IP VOICE 機能セット
• Cisco CallManager Release 3.3(3) 以降
Cisco CME 3.1 には、次の 2 つの機能が追加されています。
この機能は、リモートの Cisco CallManager エンドポイントを自動的に検出し、Cisco CallManager エンドポイントが宛先または発信元となって転送または自動転送されるコールに対して、H.323-to-H.323 ヘアピンを確立します。また、この自動検出機能は、 Cisco CallManager および CME の制御する IP Phone 間でのリングバックの生成など、シグナリングの決定を処理します。
• H.323-to-H.323 コール ヘアピンのサポート
Cisco CallManager は H.450 仕様をサポートしていないため、H.323-to-H.323 ヘアピンが必要になります。
（注） Cisco CME 3.0、および ITS の以前のバージョンは、H.323 コール ヘアピンを使用する Cisco CallManager との相互運用をサポートしていません。これらの旧バージョンでは、ループバック DN ポートを使用して Cisco CallManager との相互運用を実現していました。
次の各項では、Cisco CallManager と CME の相互運用を実現するためのガイドラインを示します。
• 「Cisco CallManager および CME を使用したマルチサイト IP テレフォニー配置」
• 「Cisco CallManager、CME、および H.450 タンデム ゲートウェイを使用したマルチサイト IP テレフォニー配置」
CME の詳細については、次の Web サイトで入手可能な Cisco CallManager Express 製品マニュアルを参照してください。
Cisco CallManager および CME を使用したマルチサイト IP テレフォニー配置
Cisco CallManager は、H.323 インターフェイスを使用する CME と直接通信することができます。図8-9 では、Cisco CME と直接にネットワーク接続された Cisco CallManager を使用する IP テレフォニー配置を示しています。
図8-9 Cisco CallManager および CME を使用したマルチサイト IP テレフォニー配置
図8-9 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。
• Cisco CallManager 上に、ゲートキーパー制御のクラスタ間トランク（ICT）を設定する。Cisco CallManager は、ICT を通じてゲートキーパーに登録し、CME は H.323 ゲートウェイとしてゲートキーパーに登録します。
• クラスタ間トランクを使用する場合は、メディア ターミネーション ポイント（MTP）を使用可能にする。Cisco CME が、端末機能セット（TCS）シグナリングを開始することはありません。また、MTP を使用すると、Cisco CallManager と CME の間で TCS 交換ができなくなります。
• Cisco CallManager で、サービス パラメータ Send H225 user info message を H225 info for Ringback に設定する。
• Cisco CallManager ダイヤル プランの設定（ルート パターン、ルート リスト、およびルート グループ）を使用して、CME に接続しているクラスタ間トランクにコールを送信する。
• Cisco CallManager のデバイス プールとリージョンを使用して、サイト内では G.711 コーデックを設定し、リモートの CME サイトに対しては G.729 コーデックを設定する。
• CME 上で allow-connection h323 to h323 コマンドを設定して、H.323-to-H.323 コール ヘアピン接続を許可する。CME 3.1 の Cisco CallManager 自動検出機能を使用すると、Cisco CallManager に接続されているインターフェイス上での H.450 ベースの通信が、すべて無効になります。Cisco CallManager 電話と CME 電話間でコール転送または自動転送を確立するには、H.323-to-H.323 接続が必要です。
• VoIP ダイヤル ピアを定義して、Cisco CallManager エンドポイントを宛先とするコールをゲートキーパーに転送する。
• コールをリモート サイトにルーティングする VoIP ダイヤル ピアに対しては、G.729 コーデックを設定する。
例8-11 に、この配置モデルでの CME の設定例を示します。
ここで示したガイドラインに従うと、Cisco CallManager 電話および CME 電話間で基本的なコールを使用できるようになります。ただし、この配置モデルでは、Cisco CallManager 電話が宛先または発信元となって転送または自動転送されるすべてのコールが、ヘアピンされます。ヘアピンでは、コール フローに関係するすべてのデバイス間で、エンドツーエンドのシグナリングが必要です。したがって、コールがジッタ、遅延、ネットワーク障害の影響を受けやすくなります。また、コールが WAN を経由する場合には、不要な帯域幅を消費します。これらの問題が発生することを避けるために、次の項の説明に従って、Cisco CallManager クラスタのフロントエンドに H.450 タンデム ゲートウェイを配置することをお勧めします。
Cisco CallManager、CME、および H.450 タンデム ゲートウェイを使用したマルチサイト IP テレフォニー配置
タンデム ゲートウェイは、Cisco CallManager など、H.450 をサポートしないシステムのためにプロキシ（フロントエンド）を提供する独立ルータです。タンデム ゲートウェイは、Cisco CallManager と CME ルータの中間に配置できます。H.450 をサポートしないエンドポイントに転送または自動転送するコールを終端し、再発信するための H.323-to-H.323 コール接続を提供します。
また、H.450 タンデム ゲートウェイは、Cisco CallManager やリモート Cisco CME システム用の公衆網ゲートウェイとしても動作できます。この場合は、公衆網ゲートウェイを別に用意する必要がありません。
H.450 タンデム ゲートウェイは、Cisco CME 3.1 と互換性があり、かつ H.450 をサポートしている Cisco IOS リリースを実行している必要があります。たとえば、IP VOICE 機能セットを備えた Cisco IOS Release 12.3(7)T 以降などです。
図8-10 では、H.450 タンデム ゲートウェイを通じて Cisco CME に接続されている Cisco CallManager を使用した、IP テレフォニー配置を示しています。
図8-10 Cisco CallManager、CME、および H.450 タンデム ゲートウェイを使用したマルチサイト IP テレフォニー配置
図8-10 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。
• Cisco CallManager と H.450 タンデム ゲートウェイの間に、ゲートキーパーの制御しないクラスタ間トランク（ICT）を設定する。
• クラスタ間トランクを使用する場合は、メディア ターミネーション ポイント（MTP）を使用可能にする。Cisco CME が、端末機能セット（TCS）シグナリングを開始することはありません。また、MTP を使用すると、Cisco CallManager と CME の間で TCS 交換ができなくなります。
• Cisco CallManager で、サービス パラメータ Send H225 user info message を H225 info for Ringback に設定する。
• Cisco CallManager ダイヤル プランの設定（ルート パターン、ルート リスト、およびルート グループ）を使用して、H.450 タンデム ゲートウェイに接続しているクラスタ間トランクにコールを送信する。
• ゲートキーパー上に、Cisco CME と H.450 タンデム ゲートウェイを H.323 ゲートウェイとして登録する。
• H.450 タンデム ゲートウェイ上で allow-connection h323 to h323 コマンドを設定して、H.323-to-H.323 コール ヘアピン接続を許可する。リモート CME ルータについては、このコマンドを有効にする必要はありません。
• H.450 タンデム ゲートウェイ上で VoIP ダイヤル ピアを定義して、コールを Cisco CallManager および CME のエンドポイントにルーティングする。
• CME 上で VoIP ダイヤル ピアを定義して、Cisco CallManager エンドポイントを宛先とするコールを H.450 タンデム ゲートウェイに転送する。
• コールを Cisco CallManager および CME との間でルーティングする H.450 タンデム ゲートウェイ上で、すべてのダイヤル ピアに同じ音声コーデックを使用する。コーデックの再ネゴシエーションはサポートされません。このため、WAN 経由で G.729 を使用する場合は、コールをリモート サイトにルーティングするすべての VoIP ダイヤル ピアで、G.729 コーデックを設定します。また、Cisco CallManager のデバイス プールとリージョンを使用して、Cisco CallManager IP Phone と H.450 タンデム ゲートウェイ間に G.729 コーデックを設定します。
• H.450 タンデム ゲートウェイを公衆網接続用の MGCP ゲートウェイとして使用できる。公衆網接続で H.323 ゲートウェイが必要な場合は、別個のゲートウェイを使用する必要があります。
例8-12 に、H.450 タンデム ゲートウェイの設定例を示します。
フィードバック