- このマニュアルについて
- 概要
- IP テレフォニー配置モデル
- ネットワーク インフラストラクチャ
- ゲートウェイ
- Cisco Unified CallManager トランク
- メディア リソース
- Music on Hold
- コール処理
- コール アドミッション制御
- ダイヤル プラン
- 緊急サービス
- サードパーティ製のボイスメール設計
- Cisco Unity
- Cisco Unified MeetingPlace の統合
- IP ビデオ テレフォニー
- LDAP ディレクトリ統合
- IPテレフォニー移行オプション
- 音声セキュリティ
- IP テレフォニー エンドポイント
- Cisco Unified CallManager アプリケーション
- 推奨されるハードウェアと ソフトウェアの組み合せ
- 用語集
- 索引
Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： コール処理
コール処理
この章では、Cisco Unified CallManager 5.0 におけるスケーラブルで復元性のあるコール処理システムの設計ガイドラインを示します。ここでは、次に示す個々の要件に基づいて、Cisco Unified CallManager に適切なハードウェアおよび配置シナリオを選択する方法についても説明します。
•
「Cisco Unified CallManager クラスタのガイドライン」
ここでは、Cisco Unified CallManager の最小ハードウェア要件について説明します。また、Cisco Unified CallManager サーバで有効にすることができる各種の機能サービス、およびそれぞれの目的についても説明します。
• 「Cisco Unified CallManager プラットフォームのキャパシティ プランニング」
ここでは、Cisco CallManager キャパシティ ツールの使用に関するガイドラインを示します。このツールは、IP テレフォニー配置のプランニング時に使用する必要があります。Cisco CallManager キャパシティ ツールは、特定の配置要件に基づいて、Cisco Unified CallManager サーバ上で使用されるリソースについてのガイダンスを提供します。
ここでは、IP テレフォニー配置でゲートキーパーをどのように使用できるかについて説明します。シスコのゲートキーパーは、もう 1 台のスタンバイ ゲートキーパーとペアにすることも、クラスタ化してさらに高いパフォーマンスと復元性を実現することもできます。ゲートキーパーは、コール ルーティングとコール アドミッション制御に使用することもできます。
• 「Cisco Unified CallManager と CallManager Express の相互運用性」
ここでは、分散型コール処理配置における Cisco Unified CallManager と Cisco Unified CallManager Express 間での H.323 と SIP の統合について説明します。
Cisco Unified CallManager クラスタのガイドライン
Cisco Unified CallManager アーキテクチャでは、複数の物理サーバを 1 つの IP PBX システムとして連携させることができます。このサーバ グループを「クラスタ」と呼びます。Cisco Unified CallManager サーバのクラスタは、設計上の制限事項を遵守している限り、IP ネットワークを介して分散していてもかまいません。クラスタを使用することで、空間的な冗長性、およびそれに伴う復元性を IP Communications システムの設計にもたらすことができます。
ここでは、Cisco Unified CallManager クラスタを形成しているサーバが実行する各種の機能について説明し、必要な規模、パフォーマンス、および復元性を達成するようにサーバを配置する方法について、ガイドラインを示します。
ハードウェア プラットフォーム
Cisco Unified CallManager クラスタでは、必要となる規模、パフォーマンス、および冗長性に応じて、さまざまなタイプのサーバを利用します。利用するサーバの範囲は、冗長性のないシングル プロセッサのサーバから、冗長性の高いマルチプロセッサ ユニットにまで及びます。
表8-1 では、クラスタ内で使用できる一般的なサーバのタイプとその主な特性を一緒にリストしています。
|
|
|
|
|---|---|---|
Cisco Unified CallManager 5.0 は、特定の Cisco MCS 7815、MCS 7825、MCS 7835、および MCS 7845 の各サーバでサポートされます。あるいは、シスコですでに確認されている、次の最小要件を満たすサーバであれば、お客様が用意した HP サーバおよび IBM サーバでもサポートされます。
現在サポートされているハードウェア コンフィギュレーションの全リストについては、次の Web サイトにあるドキュメントを参照してください。
http://www.cisco.com/go/swonly
サーバは、IP ネットワークに加えて電源と冷却についても可用性の高い環境に配置する必要があります。建物の電力が必要な可用性を備えていない場合は、サーバの電力を無停電電源装置（UPS）から供給する必要があります。二重化電源を備えたサーバについても、それぞれの電源を 2 つの異なる電力源に接続しておくと、1 つの電源回路が故障しただけでサーバに障害が発生することを回避できます。
IP ネットワークへの接続性によっても、最大限のパフォーマンスと可用性が保証されます。Cisco Unified CallManager サーバは、イーサネットに 100 Mbps 全二重で接続する必要があります。小規模な配置で 100 Mbps が使用可能でない場合、10 Mbps 全二重を使用してください。多くのサーバはオプションとして、ギガビット イーサネットを使用する機能も備えています。サーバが全二重を使用してネットワークに接続していることを確認してください。全二重接続は、スイッチ ポートおよびサーバ NIC の設定で 10 Mbps と 100 Mbps が可能です。1000 Mbps の場合は、NIC およびスイッチ ポートの両方で速度とデュプレックス モードの設定に Auto/Auto を使用することをお勧めします。Cisco Unified CallManager 5.0 のデフォルトは Auto/Auto で、この設定は以前の Cisco Unified CallManager リリースからアップグレード後のデフォルトでもあります。
（注） サーバ ポートまたはイーサネット スイッチ ポートのどちらか一方が Auto モードのままであり、もう一方のポートが手動で設定される場合、ミスマッチが生じます。ベスト プラクティスは、サーバ ポートとイーサネット スイッチ ポートの両方を手動で設定することです。ただし、ギガビット イーサネット ポートの場合は、Auto/Auto に設定する必要があります。
2 枚のイーサネット ネットワーク インターフェイス カード（NIC）を備えた Hewlett-Packard（HP）サーバ プラットフォームは、Cisco Unified CallManager 5.0 でのネットワークの耐障害性に対応する NIC チーミングをサポートできます。この機能は、サーバを 2 枚の NIC、つまり 2 本のケーブルでイーサネットに接続できるようにするものです。NIC チーミングは、障害の発生したポートから正常なポートに作業負荷を転送することによって、ネットワークのダウンタイムを防止します。NIC チーミングは、ロード バランシングまたはインターフェイス速度向上用には使用できません。
すべての Cisco Unified CallManager クラスタに次のガイドラインが適用されます。
（注） 1 つのクラスタに複数のサーバ プラットフォームを組み合せることができますが、クラスタ内のすべてのサーバでは、同じ Cisco Unified CallManager ソフトウェア リリースを実行する必要があります。
• 通常の環境では、同一 LAN または MAN 内にクラスタのすべてのメンバーを入れます。クラスタのすべてのメンバーを同一の VLAN またはスイッチに配置することは、お勧めしません。
• 冗長性を持たせるには、クラスタのメンバーを次のように配置して、インフラストラクチャや建物で発生した障害によって受ける影響を最小限に抑える必要があります。
–同じディストリビューション スイッチまたはコア スイッチに、複数のアクセス スイッチが接続されている
–複数のディストリビューション スイッチまたはコア スイッチに、複数のアクセス スイッチが接続されている
• クラスタが IP WAN にわたって構築されている場合、「IP WAN を介したクラスタ化」の項を参照して、IP WAN を介したクラスタリングのガイドラインに従ってください。
Cisco Unified CallManager クラスタのサービス
Cisco Unified CallManager クラスタの内部には、それぞれ固有のサービスを提供する複数のサーバが存在します。これらの各サービスは、同じ物理サーバ上で他のサービスと共存できます。たとえば、小規模なシステムでは、1 台のサーバがデータベース パブリッシャ、バックアップ サブスクライバ、Music On Hold（MoH）サーバ、TFTP サーバ、CTI Manager、およびコンファレンス ブリッジを兼ねることができます。クラスタの規模とパフォーマンスを強化する必要が高まった場合は、これらのサービスの多くを 1 台の専用物理サーバに移行する必要があります。
Cisco Unified CallManager 5.0 からは、1 つのクラスタに、20 のサーバを組み込めるようになりました。20 のサーバのうち、最大 8 つのサーバが、コール処理を提供する Cisco CallManager サービスを実行できます。残りのサーバは、専用データベース パブリッシャ、トリビアル ファイル転送プロトコル（TFTP）専用サーバ、または Music On Hold（MoH）サーバとして設定できます。メディア ストリーミング アプリケーション（コンファレンス ブリッジやメディア ターミネーション ポイント）も、クラスタに登録される別個のサーバにインストールできます。
Cisco MCS 7815 または同等のサーバを含んだクラスタを配置するときは、クラスタ内に最小限 2 台のサーバが必要です。1 台をパブリッシャ、TFTP サーバ、バックアップ コール処理サーバにし、もう 1 台をプライマリ コール処理サーバにします。Cisco MCS 7815 上では、この構成で最大 300 台の電話機がサポートされます。これよりキャパシティの大きいサーバを使用して 2 サーバ クラスタを配置する場合も、クラスタ内のユーザ数が 1,250 を超えないようにすることをお勧めします。1,250 ユーザを超える場合は、専用パブリッシャと別個のサーバをプライマリおよびセカンダリのコール処理サービス用にお勧めします。そのため、クラスタ内のサーバ数が増えます。
MCS 7825 以上のサーバを備えたシングル サーバ クラスタを配置することもできます。MCS 7825 または同等のサーバでは、上限は 500 ユーザです。これより可用性の高いサーバを使用する場合も、シングル サーバ クラスタのユーザ数が 1,000 を超えないようにする必要があります。シングル サーバ構成では、Survivable Remote Site Telephony（SRST）も配置して、Cisco Unified CallManager が使用不可になっている間にサービスが提供されるようにしない限り、冗長性はありません。シスコでは、実稼働環境でシングル サーバ配置を採用することはお勧めしません。ロード バランシングは、パブリッシャがバックアップ コール処理サブスクライバである場合には実装できません。
図8-1 では、一般的な Cisco Unified CallManager クラスタを示しています。
図8-1 一般的な Cisco Unified CallManager クラスタ
クラスタ内通信
Cisco Unified CallManager クラスタ内の通信（クラスタ内通信）には、2 種類あります（図8-2 を参照）。1 つは、すべてのデバイス設定情報を含んでいるデータベースを配布するためのメカニズムです（図8-2 の「データベース複製」を参照）。コンフィギュレーション データベースは、パブリッシャ サーバに保存され、読み取り専用のコピーがクラスタのサブスクライバ メンバーに複製されます。パブリッシャで加えられた変更は、サブスクライバ データベースに伝達され、クラスタのメンバー全体で設定を一貫させると共に、データベースの空間的な冗長性を実行します。
もう 1 つのクラスタ内通信は、デバイスの登録、ロケーションの帯域幅、共有メディア リソースなどのランタイム データの伝搬と複製です（図8-2 の「ICCS」を参照）。この情報は、Cisco Unified CallManager Service を実行している、クラスタのすべてのメンバー全体で共有されます。クラスタのメンバーと関連ゲートウェイとの間で、コールの最適なルーティングが確保されます。
クラスタ内セキュリティ
Cisco Unified CallManager 5.0 からは、Cisco Unified CallManager アプリケーションおよび通信リンクの保護のために、異なるアーキテクチャとメカニズムが実装されています。クラスタ内の各サーバが内部で動的ファイアウォールを実行します。Cisco Unified CallManager のアプリケーション ポートは、送信元 IP フィルタリングを使用して保護されます。動的ファイアウォールは、認証済みサーバまたは信頼できるサーバに対してだけ、これらのアプリケーション ポートを開きます（図8-3 を参照）。
このセキュリティ メカニズムは、単一の Cisco Unified CallManager クラスタ内のサーバ間にのみ適用できます。Cisco Unified CallManager のサブスクライバは、パブリッシャのデータベースにアクセスする前に、クラスタ内で認証されます。クラスタ内通信およびデータベース複製は、認証済みサーバ間でのみ発生します。インストール時にサブスクライバは、事前共有キー認証メカニズムでパブリッシャに対して認証されます。認証プロセスに必要な手順は次のとおりです。
1. セキュリティ パスワードを使用してパブリッシャ サーバをインストールします。
2. Cisco Unified CallManager Administration を使用することによって、パブリッシャ上にサブスクライバ サーバを設定します。
3. パブリッシャ サーバのインストール時に使用されたのと同じセキュリティ パスワードを使用して、サブスクライバ サーバをインストールします。
4. サブスクライバのインストール後、サーバは、UDP 8500 を使用する管理チャネル上でパブリッシャとの接続を確立しようとします。サブスクライバは、たとえば、ホスト名、IP アドレスなどのすべてのクレデンシャルをパブリッシャに送信します。クレデンシャルは、インストール時に使用されたセキュリティ パスワードを使用して認証されます。
5. パブリッシャは、独自のセキュリティ パスワードを使用してサブスクライバのクレデンシャルを確認します。
6. その情報が有効な場合、パブリッシャは、自身の動的ファイアウォール テーブルに、信頼できる送信元としてサブスクライバを追加します。サブスクライバは、データベースへのアクセスを許可されます。
7. サブスクライバは、パブリッシャから他のサブスクライバ サーバのリストを取得します。すべてのサブスクライバが互いに管理チャネルを確立し、メッシュ トポロジが作成されます。
パブリッシャ
パブリッシャはすべてのクラスタに必要なサーバで、現在はクラスタごとに 1 つのみ配置できます。このサーバは、最初にインストールする必要があります。クラスタ内の他のすべてのメンバーに対して、データベース サービスを提供します。パブリッシャ サーバは、コンフィギュレーション データベースに読み取りと書き込みのアクセスができる唯一のサーバです。設定が変更されたとき、クラスタの他のメンバーは、データベースの読み取り専用コピーを保持します。1,250 ユーザを超える大規模なシステムの場合には、管理操作によるテレフォニー ユーザへの影響を防止するために、専用パブリッシャをお勧めします。専用パブリッシャのサーバ上で、コール処理サービスまたは TFTP サービスが実行されることはありません。それ以外のサーバは、TFTP および Cisco Unified CallManager サービスを実行します。
クラスタ内のサーバは、初期化時にパブリッシャのデータベースを使用しようとします。パブリッシャが使用不可になっている場合は、自身のハード ドライブにあるローカルの読み取り専用コピーを使用します。
システムが動作していても、パブリッシャが使用不可になっている場合は、次の操作を実行できません。
• エクステンション モビリティのログイン操作およびログアウト操作
エクステンション モビリティは、データベースに読み取りと書き込みのアクセスを行う必要があるため、パブリッシャなしでは機能しません。したがって、このサービスはパブリッシャ上でのみ実行することをお勧めします。
パブリッシャ用のハードウェア プラットフォームは、クラスタの規模とパフォーマンスを基準として選択します。パブリッシャは、コール処理サブスクライバと同等のパフォーマンスを持つものにすることをお勧めします。可能な場合には、パブリッシャを高可用性サーバにして、ハードウェアの障害による影響を最小限に抑えるようにします。
コール処理サブスクライバ
Cisco Unified CallManager ソフトウェアをインストールするときに、パブリッシャとサブスクライバという 2 タイプのサーバを定義できます。これらの用語は、データベース間の関係をインストール時に定義するために使用されています。ソフトウェアをインストールしたときに使用可能になるのは、データベース サービスとネットワーク サービスだけです。すべてのサブスクライバは、パブリッシャをサブスクライブして、データベース情報の読み取り専用コピーを取得します。
コール処理サブスクライバは、Cisco CallManager Service が使用可能になっているサーバです。このサービスをサブスクライバ上で使用可能にするには、シングル サーバ ライセンスが必要です。パブリッシャが使用不可になっていると、サーバ上で Cisco CallManager Service を使用可能にできません。パブリッシャはライセンス サーバとして機能し、Cisco CallManager Service をアクティブにするために必要なライセンスを配布するからです。このサービスが使用可能になった時点で、このサーバはコール処理機能を実行できるようになります。電話、ゲートウェイ、メディア リソースなどのデバイスが登録やコール発信を実行できるのは、このサービスが使用可能になっているサーバに対してのみです。Cisco Unified CallManager 5.0 では、クラスタ内の 8 つまでのサーバで Cisco CallManager Service を使用可能にできます。
選択した冗長性方式に応じて（「コール処理の冗長性」を参照）、コール処理サブスクライバは、プライマリ（アクティブ）サブスクライバまたはバックアップ（スタンバイ）サブスクライバのどちらかになります。ロード バランシングを実装する場合は、サブスクライバがプライマリ サブスクライバとバックアップ サブスクライバの両方を兼ねることもあります。クラスタの設計を計画するときは、通常はコール処理サブスクライバにこの機能を割り当てます。大規模なクラスタや高性能クラスタでは、コール処理サービスをパブリッシャおよび TFTP サーバ上で使用可能にしないでください。コール処理サブスクライバは、採用する冗長性方式に応じて、通常は専用ペアまたは共有ペアのどちらかで運用します。1：1 冗長性では、専用ペアを使用します。2：1 冗長性では、各ペアに含まれるサーバ 1 台（バックアップ サーバ）を共有する、2 組のサーバを使用します。
ハードウェア プラットフォームは、サーバの規模、パフォーマンス、冗長性、およびコストに応じて選択します。規模とパフォーマンスについては、「Cisco Unified CallManager プラットフォームのキャパシティ プランニング」の項で説明しています。冗長性については、「コール処理の冗長性」の項で説明しています。
コール処理の冗長性
Cisco Unified CallManager 5.0 では、次の冗長性設定の中から選択できます。
• 2:1 冗長性方式：プライマリ サブスクライバ 2 台ごとに、1 つの共用バックアップ サブスクライバを設置します。
• 1:1 冗長性方式：プライマリ サブスクライバごとに、1 つのバックアップ サブスクライバを設置します。
1:1 冗長性方式では、フェールオーバー期間だけがクラスタに影響を与えるアップグレードが可能です。このフェールオーバー メカニズムは、Skinny Client Control Protocol（SCCP）IP Phone のフェールオーバー レート、毎秒約 125 台の登録を実現できるように拡張されました。Session Initiation Protocol（SIP）電話機のフェールオーバー メカニズムでは、毎秒約 40 台の登録です。
Cisco Unified CallManager 5.0 からは、サービスへの影響なしにクラスタをアップグレードできます。Cisco Unified CallManager 5.0 では、2 つのバージョンの Cisco Unified CallManager を同じサーバ上に置いて、一方をアクティブ パーティションに、もう一方を非アクティブ パーティションに入れることができます。すべてのサービスとデバイスで、すべての Cisco Unified CallManager 機能に対して、アクティブ パーティションの Cisco Unified CallManager バージョンが使用されます。アップグレード時に、クラスタ操作はアクティブ パーティションにある現在のリリースの Cisco Unified CallManager を使用して続行されながら、アップグレード バージョンが非アクティブ パーティションにインストールされます。アップグレード プロセスの完了後は、サーバをリブートし非アクティブ パーティションをアクティブ パーティションに切り替えて、新しいバージョンの Cisco Unified CallManager を実行できます。
Cisco Unified CallManager 5.0. x から Cisco Unified CallManager 5.0. x へのアップグレード
1:1 冗長性方式で、クラスタをアップグレードする手順は、次のとおりです。
ステップ 1 新しいバージョンの Cisco Unified CallManager をパブリッシャにインストールします。リブートはしないでください。
ステップ 2 新しいバージョンの Cisco Unified CallManager をすべてのサブスクライバに同時にインストールします。リブートはしないでください。
ステップ 3 パブリッシャのみをリブートします。新しいバージョンの Cisco Unified CallManager に切り替え、データベースが初期化されるまでしばらく待ちます。
ステップ 4 TFTP サーバを 1 台ずつリブートします。新しいバージョンの Cisco Unified CallManager に切り替え、コンフィギュレーション ファイルが再作成されるまで待ってから、クラスタ内の他のサーバをアップグレードします。
ステップ 5 Music On Hold（MoH）専用サーバを 1 台ずつリブートします。新しいバージョンの Cisco Unified CallManager に切り替えます。
ステップ 6 バックアップ サブスクライバを 1 台ずつリブートします。新しいバージョンの Cisco Unified CallManager に切り替えます。50/50 ロード バランシングが設定されている場合、このステップは一部のユーザに影響を与えることがあります。
ステップ 7 プライマリ サブスクライバからバックアップ サブスクライバに、デバイスをフェールオーバーします。
ステップ 8 プライマリ サブスクライバを 1 台ずつリブートします。新しいバージョンの Cisco Unified CallManager に切り替えます。
このアップグレード方法では、異なるバージョンの Cisco Unified CallManager ソフトウェアを実行しているサブスクライバ サーバにデバイスが登録される期間（フェールオーバー期間を除く）がありません。
（注） アップグレード プロセスが非アクティブ パーティションで開始された後は、パブリッシャのデータベースがアクティブ パーティションで変更されても、新しいバージョンのデータベースには移行されません。
2:1 冗長性方式では、クラスタ内のサーバ数を減らすことができますが、その結果、アップグレード時に障害が発生する可能性があります。
（注） 10,000 台以上の IP Phone が 2 つのプライマリ サブスクライバに登録される場合は、1:1 冗長性を使用する必要があります。これは、1 つのバックアップ サブスクライバで 10,000 台以上のバックアップ登録はできないからです。
（注） アップグレードを行う前に、障害回復フレームワークを使用して、Cisco Unified CallManager および Call Detail Record（CDR; コール詳細レコード）データベースを外部ネットワーク ディレクトリにバックアップすることをお勧めします。このようにしておくと、アップグレードが失敗した場合のデータ損失を防止できます。
コール処理サブスクライバの冗長性
次の図では、Cisco Unified CallManager でコール処理の冗長性を実現するための一般的なクラスタ構成を示しています。
図8-4 では、利用できる 2 つの基本的な冗長性方式を示しています。どちらの場合でも、バックアップ サーバは、障害の発生するプライマリコール処理サーバ 1 台分以上の処理能力を備えている必要があります。2：1 冗長性方式の場合、バックアップ サーバは、個々の配置の要件に応じて、障害の発生するコール処理サーバ 1 台分、または両方のプライマリ コール処理サーバに相当する処理能力を備えている必要があります。サーバのキャパシティの選定およびハードウェア プラットフォームの選択については、「Cisco Unified CallManager プラットフォームのキャパシティ プランニング」の項で説明しています。
図8-5 に示した 5 つは、すべて 1：1 冗長性のオプションを示しています。オプション 1 は、1,250 人未満のユーザをサポートするクラスタに使用します。オプション 2 ～ 5 は、クラスタを徐々に拡張した様子を示しています。正確な規模は、選択したハードウェア プラットフォームや必要なハードウェア プラットフォームによって異なります。
この図では、パブリッシャとコール処理サブスクライバのみ示していることに注意してください。
ロード バランシング
通常、プライマリが使用可能な場合、バックアップ サーバに登録されたデバイスはありません。このモデルには、次のような特長があります。
• トラブルシューティングが容易：すべてのコール処理がプライマリ サーバで行われるため、トレースおよび警告通知の取得が簡単になります。
• 設定が少ない：すべてのデバイスがプライマリ サーバに登録されるため、追加で Cisco Unified CallManager の冗長性グループまたはデバイス プールを各種のデバイス用に定義する必要性を 50% 減らすことができます。
1:1 冗長性方式を使用すると、プライマリ サーバとバックアップ サーバのペア上でデバイスを分散することができます。ロード バランシングを使用すると、Cisco Unified CallManager の冗長性グループとデバイス プールの設定値を使用して、デバイスにかかる負荷の半分までをプライマリ サブスクライバからセカンダリ サブスクライバに移すことができます。このモデルには、次のような特長があります。
• ロード シェアリング：コール処理の負荷が複数のサーバ上に分散され、応答時間をより速くすることができます。
• フェールオーバーとフェールバックが高速：すべてのデバイス（たとえば、IP Phone、CTI ポート、ゲートウェイ、トランク、ボイスメール ポートなど）がすべてのアクティブ サブスクライバにわたって分散されるため、プライマリ サブスクライバに障害が発生した場合に、セカンダリ サブスクライバにフェールオーバーするデバイスは一部のみです。この方法で、サーバが使用不能になる影響を 50% 減らすことができます。
50/50 ロード バランシングを計画するには、ロード バランシングを使用しない場合のクラスタのキャパシティを計算し、次に、デバイスおよびコールの量に基づいて、負荷をプライマリ サブスクライバとバックアップ サブスクライバに分散します。プライマリ サーバやバックアップ サーバの障害に対処できるようにするには、プライマリとバックアップのサブスクライバの合計負荷が、サブスクライバ サーバ 1 台分の負荷を超えないようにします。
TFTP サーバ
TFTP サーバ プラットフォームには、主に次の 2 つの機能があります。
• MoH などのサービスのためのファイル、電話やゲートウェイなどのデバイスのコンフィギュレーション ファイル、電話および一部のゲートウェイのアップグレード用バイナリ ファイル、およびさまざまなセキュリティ ファイルの提供。
• コンフィギュレーション ファイルおよびセキュリティ ファイルの生成。シスコの TFTP サービスが生成するファイルのほとんどは、署名済みであり、ダウンロード用として提供する前に暗号化されることもあります。
TFTP サービスは、クラスタ内の任意のサーバで使用可能にすることができます。ただし、何らかの設定を変更すると、TFTP サービスがコンフィギュレーション ファイルを再生成するため、1,250 ユーザを超えるクラスタでは、他のサービスが影響を受ける場合があります。このため、1,250 ユーザを超えるクラスタ、エクステンション モビリティを使用するクラスタ、または設定の変更を伴うその他の機能を備えたクラスタでは、特定のサーバを TFTP サービス専用にすることをお勧めします。
TFTP サーバは、設定情報を取得するために電話および MGCP ゲートウェイが使用します。TFTP サービスを使用可能にできるサーバの数に制限はありませんが、より大規模なクラスタのために TFTP サーバを 2 台配置して、TFTP サービスのための冗長性を確保しておくことをお勧めします。クラスタ内に 3 台以上の TFTP サーバを配置できますが、そのような構成ではすべての TFTP サーバ上ですべての TFTP ファイルを再構築するために時間がかかります。DHCP を使用して TFTP オプションを設定する場合、または静的に TFTP オプションを設定する場合は、TFTP サーバの IP アドレス アレイ（複数の IP アドレス）を定義します。このように定義すると、半数のデバイスでは TFTP サーバ A をプライマリとして使用し、TFTP サーバ B をバックアップとして使用するように割り当てて、他の半数のデバイスでは、TFTP サーバ B をプライマリとして使用し、TFTP サーバ A をバックアップとして使用するように割り当てることができます。TFTP 専用サーバのパフォーマンスを向上させるには、サービス パラメータを設定して、サーバ上で許容する同時 TFTP セッションの数を増やします。
Cisco Unified CallManager クラスタをアップグレードするときは、パブリッシャの後に TFTP サーバをアップグレードし、次にその他のサーバをアップグレードすることを強くお勧めします。また、TFTP サーバをアップグレードした後は、すべてのコンフィギュレーション ファイルが再作成されるように十分な間隔を空けます。一般的な Cisco TFTP の BuildDuration 時間を使用するか、リアルタイム モニタリング ツールを使用して Cisco TFTP の DeviceBuildCount を監視して、これらの増加が止まるまで監視します。このアップグレード順序に従うと、新しいバイナリと設定変更が、クラスタ内の他のサービスをアップグレードする前に有効になります。電話やゲートウェイの個々のバイナリまたはファームウェア ロードを手動で追加する場合は、ファイルを必ずクラスタ内の各 TFTP サーバにコピーしてください。
Cisco Unified CallManager Release 5.0 では、デフォルトでコンフィギュレーション ファイルがメモリにキャッシュされ、TFTP サーバのハード ドライブには保存されません。このデフォルト設定を変更して、コンフィギュレーション ファイルを TFTP サーバのハード ドライブに入れることができますが、これを行うと、TFTP のパフォーマンスに影響があります。したがって、このデフォルト設定を変更しないことをお勧めします。
CTI Manager
CTI Manager は、クラスタ内で TAPI または JTAPI コンピュータ/テレフォニー インテグレーション（CTI）を使用するアプリケーションに必要となるものです。CTI Manager は、CTI アプリケーションと Cisco Unified CallManager サービスの仲介者として機能します。アプリケーションの認証機能を提供し、許可済みのデバイスを制御および監視できるようにします。CTI アプリケーションはプライマリ CTI Manager と通信し、障害発生時にはバックアップ CTI Manager に切り替えます。CTI Manager は、コール処理サブスクライバ上でのみ使用可能にする必要があります。したがって、クラスタ内では最大で 8 つの CTI Manager を使用できます。復元性、パフォーマンス、および冗長性を最大限まで高めるには、CTI アプリケーションの負荷をクラスタ内の複数の CTI Manager に分散することをお勧めします。
一般に、アプリケーションによって制御または監視されるデバイスは、CTI Manager に使用するものと同じサーバ ペアに関連付けることをお勧めします。たとえば、IVR（interactive voice response; 音声自動応答装置）アプリケーションでは 4 つの CTI ポートが必要になります。1：1 冗長性と 50/50 ロード バランシングを使用する場合は、これらを次のように設定します。
• 2 つの CTI ポートは、サーバ A をプライマリ、サーバ B をバックアップ（セカンダリ）とする Cisco Unified CallManager 冗長性グループを持つようにします。残りの 2 つの CTI ポートは、サーバ B をプライマリ、サーバ A をバックアップとする Cisco Unified CallManager 冗長性グループを持つようにします。
• IVR アプリケーションは、サーバ A 上の CTI Manager をプライマリ、サーバ B をバックアップとして使用するように設定します。
上の例は、サーバ A 上の CTI Manager で障害が発生した場合の冗長性を備えており、IVR コールの負荷を 2 つのサーバに分散することもできています。この方法では、Cisco Unified CallManager サーバの障害による影響も最小限に抑えることができます。
IP Voice Media Streaming Application
会議や Music On Hold などのメディア リソースは、Cisco Unified CallManager サービスと同じ物理サーバ上で動作している IP Voice Media Streaming Application サービスによって提供されます。
• 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 および SIP ダイヤルピア上で使用不可にするには、 no vad コマンドを使用してください。
Cisco Unified CallManager のアプリケーション
さまざまなタイプのアプリケーションを Cisco Unified CallManager 上で使用可能にすることができます。ここでは、Cisco Unified CallManager アプリケーションのスケーラビリティの面についてのみ取り上げます。設計ガイドラインの詳細については、「Cisco Unified CallManager アプリケーション」の章を参照してください。
Cisco Unified CallManager のアプリケーションには次のものがあります。
Cisco Unified CallManager Assistant
Cisco Unified CM Assistant アプリケーションは CTI Manager Service と連携して動作します。クラスタ内で Cisco Unified CM Assistant を使用する場合は、必要となるキャパシティおよびパフォーマンスに応じて、Cisco Unified CallManager と CTI サブスクライバに選択するハードウェア プラットフォームが異なってきます。クラスタ内で他の CTI アプリケーションを使用する場合には、クラスタ内でサポートされる CTI 接続の数によって、Unified CM Assistant の最大設定が制限されることがあります。
Cisco Unified CallManager Release 5.0 での Unified CM Assistant 用に現在サポートされている上限は次のとおりです。
• クラスタ内に最大 2 台の Unified CM Assistant サーバ
• Unified CM Assistant サービス パラメータで最大 4 台の CTI サーバ
• Cisco MCS 7845 サーバでクラスタごとに 1,250 の Assistant と 1,250 の Manager
Unified CM Assistant のキャパシティの詳細については、次の Web サイトにある Cisco Unified CallManager と Unified CM Assistant のデータ シート、マニュアル、およびリリース ノートを参照してください。
クラスタ内でエクステンション モビリティを使用する場合は、必要となるキャパシティおよびパフォーマンスに応じて、選択するパブリッシャ ハードウェア プラットフォームが異なってきます。ユーザが電話でログインまたはログアウトしたときに、コンフィギュレーション データベースに含まれているコンフィギュレーションをアップデートし、TFTP サービスでコンフィギュレーション ファイルを再生成し、次にデバイスをリセットして、変更内容を有効にする必要があります。これらの処理のほとんどは、パブリッシャ上で発生します。
Cisco Unified CallManager Release 5.0 でのエクステンション モビリティ用に現在サポートされている上限は次のとおりです。
• Cisco MCS-7845 パブリッシャ サーバは、1 分あたり 50 回の順次ログイン、ログアウトをサポートできます。
• Cisco MCS-7835 パブリッシャ サーバは、1 分あたり 30 回の順次ログイン、ログアウトをサポートできます。
EM のキャパシティの詳細については、次の Web サイトにある Cisco Unified CallManager のデータ シート、マニュアル、およびリリース ノートを参照してください。
Cisco AC アプリケーションは、回線監視および電話制御のために CTI Manager Service と対話します。クラスタ内で Cisco AC を使用する場合は、必要となるキャパシティおよびパフォーマンスに応じて、Cisco Unified CallManager と CTI サブスクライバに選択するハードウェア プラットフォームが異なってきます。クラスタ内で他の CTI アプリケーションを使用する場合には、クラスタ内でサポートされる CTI 接続の数によって、AC の最大設定が制限されることがあります。
Cisco Unified CallManager Release 5.0 での AC 用に現在サポートされている上限は次のとおりです。
• MCS 7845 は、最大で 1,250 の AC デバイスをサポートできます。Attendant Console アプリケーションは、最高 1,250 台のアテンダント コンソール デバイスと任意に組み合せて使用することができます。たとえば、125 のハント パイロットを用意して各ハント パイロットに 10 メンバーを含めたり、50 のハント パイロットを用意して各ハント パイロットに 25 メンバーを含めたりするように Cisco Unified CallManager を設定できます。
• MCS 7835 は最大で 1,000 の AC デバイスをサポートし、MCS 7825 は最大で 750 の AC デバイスをサポートします。
Cisco Unified CallManager プラットフォームのキャパシティ プランニング
Cisco Unified CallManager には、タイプの異なるデバイスを登録できます。たとえば、IP Phone、ボイスメール ポート、CTI（TAPI または JTAPI）デバイス、ゲートウェイ、および DSP リソース（トランスコーディングや会議）などです。これらの各デバイスは、登録先となるサーバ プラットフォームのリソースを必要とします。必要なリソースには、メモリ、プロセッサ使用、およびディスク I/O が含まれます。各デバイスは、トランザクション（通常、コールの形式）中に、追加のサーバ リソースを消費します。たとえば、1 時間当たり 6 回のコールだけを行うデバイスが消費するリソースは、1 時間当たり 12 回のコールを行うデバイスより少なくなります。
この項で示す推奨事項は、Cisco Unified CallManager Capacity Calculator を、デフォルトのトレース レベルと CDR を有効にして使用し、その結果として得た計算に基づいています。コール処理に直接関係しない他の機能を使用不可にしたり、縮小したり、再設定したりすると、より高いレベルのパフォーマンスが得られます。こうした機能の一部を増やすと、システムのコール処理機能に影響を与える可能性があります。これらの機能には、トレース、コール詳細レコード、複雑なダイヤル プラン、およびサーバ上に共存するその他のサービスが含まれます。複雑なダイヤル プランには、複数のライン アピアランス、多くのパーティション、コーリング サーチ スペース、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、自動転送の拡張使用、共存サービス、およびその他の共存アプリケーションが含まれています。こうした機能はすべて、Cisco Unified CallManager サーバ内の追加リソースを消費します。
システム パフォーマンスを向上させるために、次のテクニックを活用すると便利なオプションが提供されます。
• 特定プラットフォーム用にサポートされている最大量まで、サーバに追加の保証メモリを取り付ける。MCS 7825 および MCS 7835、または同等のサーバ クラスの大規模構成では、これらのサーバの RAM を倍に増やすことをお勧めします。このメモリ アップグレードが必要かどうかは、パフォーマンス モニタを使用して検証することでわかります。サーバが物理メモリを最大量近くまで使用すると、オペレーティング システムは、ディスクへのスワップを開始します。このスワッピングが発生した場合は、追加の物理メモリを取り付ける必要があることを示しています。
• 多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大きなダイヤル プランをもつ Cisco Unified CallManager クラスタでは、Cisco CallManager Service の初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、サービス パラメータを変更して、設定の初期化時間を延長してください。サービス パラメータの詳細については、Cisco Unified CallManager Administration オンライン ヘルプの「Service Parameters」を参照してください。
Cisco Unified CallManager Release 5.0 には、次のガイドラインが適用されます。
• クラスタ内では、Cisco Unified CallManager Service を使用して最大 8 台のサーバを使用可能にすることができます。それ以外のサーバは、TFTP、パブリッシャ、Music on Hold などの専用機能に使用できます。
• 標準サーバごとに CTI 接続またはアソシエーションを最大 800 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 3200 設定できます。
• 高性能サーバごとに CTI 接続またはアソシエーションを最大 2,500 設定できます。サーバ間で均等にバランスが取られる場合は、クラスタごとに最大 10,000 設定できます。
• 各クラスタは、最大 30,000 台の SCCP または SIP 電話機をサポートできます。
• 各クラスタは、最大 600 台の H.323 デバイス（ゲートウェイ、トランク、クライアント）、デジタル MGCP デバイス、および SIP トランクをサポートできます。
キャパシティの計算
Cisco Unified CallManager Release 5.0 の Cisco CallManager キャパシティ ツールを使用すると、システムのキャパシティを各種の設定について計算することができます。キャパシティ プランニング ツールを使用できるのは、現時点ではログイン アカウントを持つすべての www.cisco.com ユーザです。システムが次のガイドラインを満たしていない場合や、システムをさらに複雑にするためにキャパシティを確認する必要があるのに Cisco CallManager キャパシティ ツールにアクセスできない場合は、シスコのシステム エンジニア（SE）または Cisco Technical Assistance Center（TAC）にお問い合せください。
Cisco CallManager キャパシティ ツールは次の Web サイトで入手可能です。
http://www.cisco.com/partner/WWChannels/technologies/resources/CallManager/
システムが次の要件を満たしている場合は、コンフィギュレーションを Cisco CallManager キャパシティ ツールで確認する必要はありません。
• システムに含まれているユーザ数が、サーバ プラットフォームの最大ユーザ数の 25% 未満である。
• ユーザごとの平均の Busy Hour Call Attempt（BHCA）が、1 時間あたり 4 コール未満である。
• ゲートウェイまたはトランクのどちらかを経由するトランキングが、20%（1 トランクあたり 5 ユーザ）以下である。
• ボイスメール ポートが 5%（1 ボイスメール ポートあたり 20 ユーザ）以下である。
• サーバ 1 台あたりの MoH ストリームが 20 以下である。
• CTI、JTAPI、および TAPI のデバイスがない。
• コンファレンス ブリッジが 5%（ブリッジ上の 1 ポートあたり 20 ユーザ）以下である。
• トランキングに必要な最大コールをサポートする目的では、MTP のみ使用する。
• システムには、上に定義されていないもの以外は、IP Phone、IP Communicator、ゲートウェイ、メディア リソース、ボイスメール ポート、トランクしか含まれていない。
Cisco Unified CallManager がサポートできるユーザの最大数は、サーバ プラットフォームによって異なります（ 表8-2 を参照）。
|
|
|
|
|
|---|---|---|---|
Cisco MCS-7815（すべてのサポート モデル） 3 |
| 1.高可用性サーバでないプラットフォームは、非冗長インストレーションで最大 500 の IP Phone をサポートできます。 |
サポートされるプラットフォーム、サードパーティ プラットフォーム、個々のハードウェア設定の最新情報については、次の 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 係数、コール タイプ係数、ダイヤル プランの重みと呼ばれていたメカニズムを置き換えるものです。
Cisco CallManager キャパシティ ツールを使用した場合の結果は、設定について計算された各種リソースの最高キャパシティを示します。リソースには絶対的な上限、メモリ、プロセッサの使用率、およびディスク I/O アクティビティが含まれます。さらにデバイスを追加したとき、追加の設定では、示されている現在の最高キャパシティを下回るリソースを使用しているため、見た目ではそれ以上のキャパシティが使用されていないことになります。
たとえば、サードパーティ制御の 2,500 台の SCCP IP Phone を Cisco CallManager キャパシティ ツールに追加した場合、必要な MCS 7845 サブスクライバは 1 つであり、そのキャパシティ使用率は 100% であることが示されます。さらに 1,000 台の電話機を追加した場合でも、必要な MCS 7845 サブスクライバは 1 つであり、そのキャパシティ使用率は 100% であるという結果が示されます。このような結果になる理由は、このサーバの CTI キャパシティが 100% 状態にあるためで、IP Phone を追加しても CTI 要件が追加されることはありません。他のデバイスの数が残りのいずれか 1 つの上限を超えるまで、追加のキャパシティは使用されていないように見えます。これは通常の状態であり、Cisco CallManager キャパシティ ツールに予想される動作です。
電話機に関する計算
キャパシティ ツールのメインの Telephony セクションに（Contact Center セクションではなく）、次の電話機タイプがリストされます。
電話機タイプごとに、数、BHCA、使用率、ライン アピアランスの値を入力することができます。これらについては、続く各項で詳しく説明します。
この値は、クラスタ内に設定するタイプごとの IP Phone の合計数です。この数には、Cisco7900 シリーズのすべての IP Phone、VG248 ポート、VG224、IP Communicator、およびその他のサードパーティ SCCP エンドポイント デバイスを含めます。この数には、アクティブになっていないものも含めて、設定済みのすべての電話を含める必要があります。
この値は、タイプごとのすべての電話の平均 BHCA です。複数の電話で共用している回線がある場合、BHCA には、回線を共用しているそれぞれの電話のコールを 1 つとして含める必要があります。複数の電話機タイプにわたるシェアドラインは、タイプごとの BHCA に影響します。つまり、シェアドラインへの 1 つのコールは、複数のコール（呼び出される電話機に 1 つずつ）として計算します。それぞれ別の BHCA を生成する複数の電話グループがある場合、Cisco CallManager キャパシティ ツールで使用する BHCA 値は、次の方法で指定します。
たとえば、次の特性を持つ 2 クラスのユーザがいるとします。
• 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 と使用率の計算には影響します。たとえば、通常の状態として電話機に 2 コールあり、一方がアクティブでもう一方がさまざまな時間で保留になる場合、2 コールが実際に接続しているため、そのデバイスについての使用率は、より高くなります。
ゲートウェイ
ゲートウェイの数は、ゲートウェイのタイプに応じて異なるため、次のいくつかのエントリに分けられています。
この値は、Cisco Unified CallManager データベース内に設定する必要のあるゲートウェイの合計数です。たとえば、Cisco IOS MGCP ゲートウェイは複数の T1 または E1 を保持できますが、単一のゲートウェイとして追加します。Cisco WS-6608 モジュールは、T1 または E1 ゲートウェイとして設定されているポートごとに、1 モジュールあたり最大で 8 つまで、ゲートウェイとして追加します。
この値は、Cisco Unified CallManager データベースに追加するアナログ ゲートウェイの合計数です。通常は、モジュール全体（WS-6624 または Cisco Unified CallManager）またはハードウェア プラットフォーム（Cisco IOS ルータ プラットフォーム）を 1 つのゲートウェイとして追加します。
モジュール全体またはハードウェア プラットフォームを、1 つのゲートウェイとして追加します。この数には、Cisco Unified CallManager に定義されていないものの、H.323 トランク経由で使用される H.323 ゲートウェイは含みません。
この値は、各タイプのゲートウェイがサポートする DS0 またはアナログ ポートの合計数です。DS0 の数は、次のように、ゲートウェイのタイプによって分かれています。
（DS0 の合計数） /（すべてのデジタル、アナログ、IP インターフェイス上でサポートされるコールの数）
この BHCA は、最も混雑している時間における、ゲートウェイ上のすべての DS0 またはアナログ ポートの平均値です。この平均値を計算する方法は、電話の BHCA に使用する方法と同じです。
この値は、最も混雑している時間における、すべての DS0 またはアナログ ポートの平均使用率です。
エクステンション モビリティ（EM）プロファイルには、電話の計算でも含めている、ライン アピアランスを含めます。エクステンション モビリティは、デバイスの数には影響しませんが、電話ごとのライン アピアランスの平均数が増加します。EM ユーザの BHCA および使用率は、ユーザのログイン先となる電話について、すでに計算したものです。
H.323 と SIP のトランク
この値は、Cisco Unified CallManager データベース内に設定されるトランクの合計数です。ゲートキーパーが制御するトランクは、宛先の数の影響を受けません。このため、設定済みのゲートキーパー制御トランクごとに 1 つとしてカウントします。これは、Session Initiation Protocol（SIP）プロキシを使用する SIP トランクにも当てはまります。SIP プロキシ経由で接続されない SIP ゲートウェイごとに、SIP トランクを Cisco Unified CallManager で定義する必要があります。
この値は、すべてのトランク上で許容できる同時発生コールの合計数です。許容されるコールの数は、通常はロケーションまたはゲートキーパーのコール アドミッション制御によって制御されます。許容されるコールの数には、リージョンとコーデックも影響することに注意してください。
この値は、すべてのトランクにわたる、すべてのコールの平均使用率です。これは、最も混雑している時間における百分率（%）です。使用率が 75% の場合は、コールが 1 時間あたり 45 分アクティブであることを意味します。
MTP の要件についても、カルキュレータで別個に検討する必要があります。H.323 または SIP トランク上で MTP が必要となる場合、そのトランク上でのすべての同時発生コールで MTP リソースが必要になります。RSVP エージェントは数に含める必要があり、また、サポートされる最大セッション数に基づいています。
CTI ルート ポイント、ポート、およびサードパーティ制御の回線
CTI ルート ポイントの計算には、合計数、平均 BHCA、および使用率の値が含まれます。割り当て済みのディレクトリ番号は、いずれもツールの Dial Plan セクションに追加する必要があります。
CTI ポートは、制御元のアプリケーションがさまざまな方法で使用することができます。説明を単純にするため、次の 2 つのグループに分けて考えます。
単純コールとは、補足サービスの呼び出しが伴わない、ポートへのコールあるいはポートから別のデバイスへのコールのことです。一般的なコール シナリオとなり、発信者からコールがあって着信側が応答し、コールが進行して両者が電話を切る場合です。
リダイレクト コールとは、実際には応答されない CTI ポートへのコールのことです。代わりに、別の宛先に転送されるか、リダイレクトされます。コールの接続がなく、そのためメディアが CTI ポートに接続されないため、このコールは単純コールよりもさらに単純です。
これらのコール タイプは、IVR アプリケーションまたは自動応答アプリケーションに一般的です。
転送タイプのコールは、CTI ポートに接続されるコールとしての特徴を備え、ある時点で、CTI ポートは、発信者を別の宛先に打診なしで転送（ブラインド転送）します。
会議は転送のバリエーションの 1 つで、CTI ポートに接続したコールは、打診転送されるか（三者コール）、あるいはコール期間中に別の相手と会議を行います。
デバイスまたは回線に対するサードパーティ制御または監視が要求されるアプリケーションごとに、カルキュレータのこのフィールドでのカウントおよび入力が必要になります。複数のアプリケーションが同じデバイスを監視または制御している場合には、それを複数回としてカウントする必要があります。
ゲートキーパーの設計上の考慮事項
1 台の Cisco IOS ゲートキーパーで、分散型コール処理環境で最大 100 の Cisco Unified CallManager クラスタに対してコール ルーティングとコール アドミッション制御をサポートできます。複数のゲートキーパーを設定すると、数千の Cisco Unified CallManager クラスタをサポートできます。Cisco IOS ゲートキーパーを使用して、H.323 ゲートウェイと Cisco Unified CallManager 間の通信とコール アドミッション制御をサポートすることによって、ハイブリッド Cisco Unified 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 Unified CallManager Release 3.3 より前では、ゲートキーパーの冗長性をサポートする方法は、ホットスタンバイ ルータ プロトコル（HSRP）だけでした。Cisco Unified CallManager Release 3.3 以降は、ゲートキーパーの冗長性をサポートする方法として、ゲートキーパー クラスタリングと冗長ゲートキーパー トランクも使用できるようになりました。次の項では、これらの方法について説明します。
（注） 可能な場合、ゲートキーパーの冗長性をサポートするには、ゲートキーパー クラスタリングを使用することをお勧めします。冗長性に HSRP を使用するのは、ソフトウェア機能セットでゲートキーパー クラスタリングが利用できない場合だけにしてください
ホットスタンバイ ルータ プロトコル（HSRP）
Release 3.3 より前の Cisco Unified CallManager では、ゲートキーパーの冗長性には、ホットスタンバイ ルータ プロトコル（HSRP）しか選択できませんでした。HSRP は、冗長かつスケーラブルなゲートキーパー ネットワークの構築に必要な機能をサポートしないので、Release 3.3 より前の Cisco Unified CallManager 環境でのみ使用してください。
• 一度に 1 つのゲートキーパーしかアクティブになりません。
–スタンバイ ゲートキーパーは、プライマリに障害が発生した場合でなければ、コールを処理しません。
• すべてのゲートキーパーが同じサブネットまたはロケーションに存在しなければなりません。
• フェールオーバー後、スタンバイ ゲートキーパーは、すでにアクティブになっているコールを認識しないので、帯域幅のオーバーサブスクリプションが発生する可能性があります。
• コールの発信前に、HSRP スタンバイ ゲートキーパーにエンドポイントを再登録する必要があるので、フェールオーバーには相応の時間がかかることがあります。フェールオーバー時間は、登録タイマーの設定に依存します。
図8-7 では、ゲートキーパーの冗長性に HSRP を使用するネットワーク設定を示しています。
例8-1 では、図8-7 のゲートキーパー 1 の設定を示しています。例8-2 では、ゲートキーパー 2 の設定を示しています。イーサネット インターフェイス上の HSRP 設定を除いて、両方の設定は同一です。
• 各ルータには、それぞれが共有する仮想 IP アドレスを識別するために、HSRP 用に standby コマンドが設定されます。ゲートキーパー 1 は、コマンド standby priority 110 を使用して、プライマリとして設定されています。
• Cisco Unified CallManager トランク登録をサポートするために、各 Cisco Unified CallManager クラスタには、各ルータ上でローカル ゾーンが設定されます。最初のゾーンに定義されている IP アドレスは、HSRP の使用する仮想 IP アドレスと一致する必要があることに注意してください。
• ゾーン間とクラスタ間のコール ルーティングを可能にするために、両方のルータでゾーンごとにゾーン プレフィックスが設定されます。
• 各ルータで、両方のサイトの帯域幅ステートメントが設定されます。シスコでは、 bandwidth interzone コマンドを使用することをお勧めします。 bandwidth total コマンドは、設定内容によっては機能しないことがあるためです。
• ローカルで解決されないすべてのコールを、ローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できるように、 gw-type-prefix 1# default-technology コマンドが両方のルータで設定されます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• 冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避するために、 arq reject-unknown-prefix コマンドが両方のルータで設定されます。
HSRP に関するこの他の高度な情報については、次の Web サイトにあるオンライン ドキュメントを参照してください。
• http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm
ゲートキーパー クラスタリング（代替ゲートキーパー）
ゲートキーパー クラスタリング（代替ゲートキーパー）により、「ローカル」ゲートキーパー クラスタの設定が可能になります。各ゲートキーパーは、一部の Cisco Unified CallManager トランクのプライマリ、およびその他のトランクの代替として機能します。GUP（Gatekeeper Update Protocol）は、ローカル クラスタ内のゲートキーパー間で状態情報を交換するために使用されます。GUP は、クラスタ内のゲートキーパーごとに CPU 使用率、メモリ使用率、アクティブ コール数、および登録されたエンドポイント数をトラッキングし、報告します。GUP メッセージングで次のパラメータにしきい値を設定すると、ロード バランシングがサポートされます。
ゲートキーパー クラスタリング（代替ゲートキーパー）と Cisco Unified CallManager Release 3.3 以降のサポートにより、ステートフル冗長性とロード バランシングが使用可能になります。ゲートキーパー クラスタリングは、次の機能を提供します。
• ローカル クラスタ内のゲートキーパーを、別々のサブネットまたはロケーションに配置可能
• フェールオーバーの遅延なし（代替ゲートキーパーはすでにエンドポイントを認識しているので、完全な登録プロセスを実行する必要はありません）
• クラスタ内のゲートキーパーは、状態情報を渡し、ロード バランシングを行う
図8-8 では、Cisco Unified CallManager 分散型コール処理を行う 3 つのサイト、およびローカル クラスタで設定された 3 つの分散型ゲートキーパーを示しています。
図8-8 では、ゲートキーパー 2 はゲートキーパー 1 のバックアップ、ゲートキーパー 3 はゲートキーパー 2 のバックアップ、ゲートキーパー 1 はゲートキーパー 3 のバックアップです。
例8-3 では、ゲートキーパー 1（SJC）の設定を示し、例8-4 は、ゲートキーパー 2（CHC）の設定を示しています。ゲートキーパー 3（NYC）の設定は、他の 2 つの例を参照してください。
例8-3 ゲートキーパー 1 のゲートキーパー クラスタリング設定
例8-4 ゲートキーパー 2 のゲートキーパー クラスタリング設定
• Cisco Unified CallManager トランク登録をサポートするために、各 Cisco Unified CallManager クラスタにはローカル ゾーンが設定されます。
• ローカル ゾーンごとにクラスタが定義され、他のゲートキーパー上のバックアップ ゾーンはエレメントとしてリストされます。エレメントは、バックアップが使用される順にリストされます。
• ゾーン間とクラスタ間のコール ルーティングを可能にするために、ゾーンごとにゾーン プレフィックスが設定されます。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• load-balance cpu 80 memory 80 コマンドは、CPU とメモリの使用率を制限します。ルータがどちらかの制限に達すると、新しい要求はすべて拒否され、使用率がしきい値以下に下がるまで、リスト内の最初のバックアップが使用されます。
• サイトごとに帯域幅ステートメントが設定されます。シスコでは、 bandwidth interzone コマンドを使用することをお勧めします。 bandwidth total コマンドは、設定内容によっては機能しないことがあるためです。
• arq reject-unknown-prefix コマンドは、冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避します。
クラスタ内のすべてのゲートキーパーは、すべての Cisco Unified CallManager トランク登録を表示しています。ゲートキーパーをプライマリ リソースとして使用するトランクの場合、フラグ フィールドはブランクです。クラスタ内の別のゲートキーパーをプライマリ ゲートキーパーとして使用するトランクの場合、フラグ フィールドは A（代替）に設定されます。すべてのエンドポイントをプライマリまたは代替として登録すると、すべてのコールをローカル側で解決できるようになり、別のゲートキーパーにロケーション要求（LRQ）を送信する必要はありません。
例8-5 では、ゲートキーパー 1（SJC）での show gatekeeper endpoints コマンドからの出力を示します。
ディレクトリ ゲートキーパーの冗長性
HSRP を使用するか、複数の同じディレクトリ ゲートキーパーを設定すると、ディレクトリ ゲートキーパーの冗長性を実装できます。同じゾーン プレフィックスを使用して、複数のリモート ゾーンをもつゲートキーパーを設定するとき、このゲートキーパーには、次のいずれかの方法が使用できます。
冗長リモート ゾーン（ゾーン プレフィックスが一致）にコストが割り当てられ、LRQ は、コスト値に基づいた順序で、一致するゾーンに送信されます。順次 LRQ を使用すると、一致するすべてのゲートキーパーに LRQ を送信しないので、WAN 帯域幅の節約になります。
LRQ は、冗長ゾーン（ゾーン プレフィックスが一致）に同時に送信されます。ロケーション確認（LCF）で応答する最初のゲートキーパーが、使用されます。
順次 LRQ を使用して複数のアクティブ ディレクトリ ゲートキーパーを使用することをお勧めします。これによって、ディレクトリ ゲートキーパーを別々のロケーションに配置することができます。HSRP を使用するには、両方のディレクトリ ゲートキーパーを同じサブネットに置く必要があります。この場合常に 1 つのゲートキーパーしかアクティブにすることができません。
図8-9 では、2 つのアクティブ ディレクトリ ゲートキーパーを備えた Cisco Unified CallManager 分散型コール処理環境を示しています。
例8-6 および例8-7 では、図8-9 の 2 つのディレクトリ ゲートキーパーの設定を示しています。
• 両方のディレクトリ ゲートキーパーはまったく同じように設定されます。
• ディレクトリ ゲートキーパー用にローカル ゾーンが設定されます。
• リモート ゲートキーパーごとに、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、両方のリモート ゾーンにゾーン プレフィックスが設定されます。ワイルドカード（*）をゾーン プレフィックスに使用すると設定を簡潔化できますが、ドット（.）を使用する方がきめ細かく設定できます。コールは DGK ゾーンにルーティングされないので、DGK ゾーンにはプレフィックスは必要ありません。
• lrq forward-queries コマンドは、ディレクトリ ゲートキーパーが、別のゲートキーパーから受信した LRQ を転送できるようにします。
（注） ディレクトリ ゲートキーパーは、アクティブ エンドポイント登録を含まず、いかなる帯域幅管理も行いません。
例8-8、例8-9、および例8-10 では、図8-9 のゲートキーパー 1 ～ 3 の設定を示しています。
ここでは、例8-8、例8-9、および例8-10 について説明します。
• Cisco Unified CallManager トランク登録をサポートするために、各 Cisco Unified CallManager クラスタにはローカル ゾーンが設定されます。
• ディレクトリ ゲートキーパーごとに、リモート ゾーンが設定されます。
• ゾーン間コール ルーティング用に、ローカル ゾーンと両方のリモート ゾーンにゾーン プレフィックスが設定されます。両方のディレクトリ ゲートキーパー プレフィックスは、10 個のドットです。一致するゾーン プレフィックスが設定されるとき、デフォルトで順次 LRQ が使用されます。ゲートキーパーは、コストが最低のディレクトリ ゲートキーパーに LRQ を送信します。応答がない場合、ゲートキーパーは、2 番目のディレクトリ ゲートキーパーに LRQ の送信を試みます。
• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、 bandwidth remote コマンドを使用します。
• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。
• arq reject-unknown-prefix コマンドは、冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避します。
Cisco Unified CallManager と CallManager Express の相互運用性
この項では、H.323 または SIP プロトコルを使用している Cisco Unified CallManager と Cisco Unified CallManager Express（CME。以前に Cisco IOS Telephony Services（ITS）と呼ばれていた製品）に関して、マルチサイト IP テレフォニー配置における相互運用性およびインターネットワーキングの要件について説明します。ここでは、Cisco Unified CallManager の制御する電話機と CME の制御する電話機との間での推奨する配置を中心に説明します。
Cisco CME 3.4 では、現時点でサポートされている Cisco IP SCCP Phone 7902、7905、7910、7912、7920、7935、7936、7940、7960、7970、7971、および Cisco IP Communicator に加えて、Cisco IP SIP Phone 7905、7912、7940、および 7960 を設定する機能が追加されています。CME を SIP 電話機で使用する場合は、WAN インターフェイスを SIP にする必要があります。CME SCCP 電話機は、H.323 または SIP の WAN インターフェイスでサポートされます。
すべてのコール シグナリングは、使用されるエンドポイントに関係なく、CME を通して送信されます。ただし、SCCP エンドポイントが同じ CME 上にある場合は、メディアが CME の周囲を流れることができるのに対して、SIP エンドポイントが同じ CME 上にある場合には、メディアは必ず CME を通って流れます。
次の各項では、Cisco Unified CallManager と Cisco Unified CallManager Express の相互運用を実現するためのガイドラインを示します。
• 「Cisco Unified CallManager および CME を SIP トランクで接続したマルチサイト IP テレフォニー配置」
• 「Cisco Unified CallManager と CME を H.323 トランクと IP-to-IP ゲートウェイで接続したマルチサイト IP テレフォニー配置」
CME の詳細については、次の Web サイトで入手可能な Cisco Unified CallManager Express 製品マニュアルを参照してください。
Cisco Unified CallManager および CME を SIP トランクで接続したマルチサイト IP テレフォニー配置
Cisco Unified CallManager は、SIP インターフェイスを使用する Cisco Unified CallManager Express と直接通信することができます。図8-10 では、SIP トランク WAN インターフェイスを使用して Cisco Unified CallManager が Cisco CME と直接にネットワーク接続されている IP テレフォニー配置を示しています。
図8-10 Cisco Unified CallManager および CME を SIP トランクで接続したマルチサイト IP テレフォニー配置
図8-10 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。
• Replaces ヘッダーを受け入れるように SIP トランク セキュリティ プロファイルを設定する。
• 作成した SIP トランク セキュリティ プロファイルを使用して SIP トランクを Cisco Unified CallManager 上に設定し、再ルーティング CSS も指定する。再ルーティング CSS は、どこで SIP ユーザ（転送者）が別のユーザ（被転送者）を第三者ユーザ（転送先）に振り向けることができるか、および SIP 3XX Redirection Response と Replaces を持つ INVITE を使用して SIP ユーザがどの機能を呼び出せるかを決定するために使用します。
• SIP トランクの場合、CME 上で SCCP エンドポイントを使用しているときに、メディア ターミネーション ポイント（MTP）を使用可能にする必要はない。ただし、CME 上に SIP エンドポイントがある場合は、メディア ターミネーション ポイントを Cisco Unified CallManager 上で使用して、SIP プロトコルで遅延オファー/アンサー交換の処理（Session Description Protocol なしの INVITE 受信）ができるようにする必要があります。
• Cisco Unified CallManager ダイヤル プランの設定（ルート パターン、ルート リスト、およびルート グループ）を使用して、CME に接続している SIP トランクにコールを送信する。
• Cisco Unified CallManager のデバイス プールとリージョンを使用して、サイト内では G.711 コーデックを設定し、リモートの CME サイトに対しては G.729 コーデックを設定する。
• CME の voice services voip で allow-connections sip to sip コマンドを設定して、SIP-to-SIP コール接続を許可する。
• SIP エンドポイントの場合は、 voice register global で mode cme コマンドを設定し、CME の SIP 電話機ごとに voice register pool コマンドで dtmf-relay rtp-nte を設定する。
• SCCP エンドポイントの場合は、CME の telephony-service で transfer-system full-consult コマンドと transfer-pattern .T コマンドを設定する。
• CME の session protocol sipv2 および dtmf-relay sip-notify rtp-nte により、SIP WAN インターフェイスの voip ダイヤル ピアを設定し、Cisco Unified CallManager を宛先としてコールを転送します。
（注） 複数の公衆網接続（Cisco Unified CallManager に 1 つと CME に 1 つ）が存在する場合、公衆網エンドポイントに対する Cisco Unified CallManager エンドポイントと CME エンドポイント間の完全在席転送は失敗します。複数の公衆網接続を使用する場合にはブラインド転送の使用を推奨し、この設定は telephony-service で transfer-system full-blind として行います。
例8-11 に、この SIP 配置モデルを使用した CME の設定例を示します。
例8-11 SIP での Cisco CME 3.4 の設定
ここで示したガイドラインに従うと、Cisco Unified CallManager 電話および CME 電話間で基本的なコールを使用できるようになります。H323 の代わりに SIP トランク インターフェイスを使用することで、CME 上で SCCP エンドポイントのみを使用するときに、MTP は必要なくなります。SIP エンドポイントが CME 上で使用されている場合は、Cisco Unified CallManager 上に MTP を設定する必要があります。
Cisco Unified CallManager と CME を H.323 トランクと IP-to-IP ゲートウェイで接続したマルチサイト IP テレフォニー配置
IP-to-IP ゲートウェイは、Cisco Unified CallManager など、H.450 をサポートしないシステムのためにプロキシ（フロントエンド）を提供する独立ルータです。IP-to-IP ゲートウェイは、Cisco Unified CallManager と CME ルータの中間に配置できます。H.450 をサポートしないエンドポイントに転送または自動転送するコールを終端し、再発信するための H.323-to-H.323 コール接続を提供します。
Cisco Unified CallManager Express は、IP-to-IP ゲートウェイなしで H.323 インターフェイスを使用して、Cisco Unified CallManager と直接統合することができます。ただし、Cisco Unified CallManager は H.450 仕様をサポートしていないため、Cisco Unified CallManager 電話から開始されたコール転送や自動転送などの補足サービスでは、Cisco Unified CallManager 電話がコールに関係しないときであっても、Cisco Unified CallManager を通した（場合によっては WAN 経由による）メディアのヘアピンが必要になります。IP-to-IP ゲートウェイは、このメディア ヘアピンが WAN 上で発生することを防止します。
また、IP-to-IP ゲートウェイは、Cisco Unified CallManager やリモート Cisco CME システム用の公衆網ゲートウェイとしても動作できます。この場合は、公衆網ゲートウェイを別に用意する必要がありません。
IP-to-IP ゲートウェイは、Cisco CME 3.4 と互換性があり、かつ H.450 をサポートしている Cisco IOS リリースを実行している必要があります。たとえば、IP VOICE 機能セットを備えた Cisco IOS Release 12.4(6)T 以降などです。
図8-11 では、IP-to-IP ゲートウェイを通じて Cisco CME に接続されている Cisco Unified CallManager を使用した、IP テレフォニー配置を示しています。
図8-11 Cisco Unified CallManager、CME、および IP-to-IP ゲートウェイで接続したマルチサイト IP テレフォニー配置
図8-11 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。
• Media Termination Point Required をオンにし、 Wait For Far End H.245 Terminal Capability Set をオフにして、ゲートキーパーが制御する H.225 トランクを Cisco Unified CallManager と IP-to-IP ゲートウェイ間に設定する。
• Cisco Unified CallManager で、サービス パラメータ Send H225 user info message を H225 info for Call Progress Tone に設定する。
• Cisco Unified CallManager ダイヤル プランの設定（ルート パターン、ルート リスト、およびルート グループ）を使用して、IP-to-IP ゲートウェイに接続している H.225 トランクにコールを送信する。
• ゲートキーパー上に、Cisco CME と IP-to-IP ゲートウェイを H.323 ゲートウェイとして登録する。
• H.450 が Empty Capability Set（ECS）シグナリング変換を実行するには、メディア ターミネーション ポイント（MTP）が必要である。MTP は、IP-to-IP ゲートウェイ上に設定して Cisco Unified CallManager に登録する必要があります。MTP によって、特にまれなケースとして、WAN 経由でメディアのヘアピンが起きることがあります。メディア ターミネーション ポイントの詳細については、「メディア リソース」の章を参照してください。
• IP-to-IP ゲートウェイ上で allow-connection h323 to h323 コマンドを設定して、H.323-to-H.323 コール接続を許可する。リモート CME ルータについては、このコマンドを有効にする必要はありません。
（注） CME と Cisco Unified CallManager の間に H.323 トランクを使用する場合は、CME 上で allow-connection h323 to h323 コマンドを設定して、H.323-to-H.323 ヘアピン コール接続を許可します。CME 3.1 からの Cisco Unified CallManager 自動検出機能を使用すると、Cisco Unified CallManager に接続されているインターフェイス上での H.450 ベースの通信が、すべて無効になります。Cisco Unified CallManager 電話と CME 電話間でコール転送または自動転送を確立するには、H.323-to-H.323 接続が必要です。
• IP-to-IP ゲートウェイ上で VoIP ダイヤル ピアを定義して、コールを Cisco Unified CallManager および CME のエンドポイントにルーティングする。
• CME 上で VoIP ダイヤル ピアを定義して、Cisco Unified CallManager エンドポイントを宛先とするコールを IP-to-IP ゲートウェイに転送する。
• コール転送や自動転送などの補足サービスでは、2 つのエンドポイントが同じ CME 支店ロケーションに存在する場合に、コールのメディア ヘアピンが発生する。
（注） 複数の公衆網接続（Cisco Unified CallManager に 1 つと CME に 1 つ）が存在する場合、公衆網エンドポイントに対する Cisco Unified CallManager エンドポイントと CME エンドポイント間の完全在席転送は失敗します。複数の公衆網接続を使用する場合にはブラインド転送の使用を推奨し、この設定は telephony-service で transfer-system full-blind として行います。
例8-12 に、IP-to-IP ゲートウェイの設定例を示します。
例8-13 に、この H.323 配置モデルでの CME の設定例を示します。
例8-13 H.323 での Cisco CME 3.4 の設定
フィードバック