呼処理
呼処理
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

呼処理

この章の新規情報

呼処理アーキテクチャ

呼処理ハードウェア

UnifiedCM クラスタのサービス

クラスタ サーバ ノード

Enterprise License Manager

クラスタ内通信

クラスタ内セキュリティ

音声アクティビティ検出

クラスタリングに関する一般的なガイドライン

呼処理のハイ アベイラビリティ

ハードウェア プラットフォームのハイ アベイラビリティ

ネットワーク接続のハイ アベイラビリティ

UnifiedCM のハイ アベイラビリティ

呼処理の冗長性

呼処理サブスクライバの冗長性

TFTP の冗長性

CTIManager の冗長性

UCS 呼処理の冗長性

Cisco Business Edition のハイ アベイラビリティ

呼処理のキャパシティ プランニング

UnifiedCME のキャパシティ プランニング

UnifiedCM のキャパシティ プランニング

UCS プラットフォームでの Unified CM のキャパシティ プランニング

Unified CM のキャパシティ プランニング ガイドラインおよびエンドポイントの制限

メガクラスタ

Cisco Business Edition のキャパシティ プランニング

呼処理の設計上の考慮事項

コンピュータ テレフォニー インテグレーション(CTI)

CTI のアーキテクチャ

WAN を介した CTI アプリケーションおよびクラスタリング

CTI のキャパシティ プランニング

CTI のハイ アベイラビリティ

CTI Manager

冗長性、フェールオーバー、およびロード バランシング

実装

ゲートキーパーの設計上の考慮事項

ハードウェア プラットフォームの選択

ゲートキーパーの冗長性

ゲートキーパー クラスタリング(代替ゲートキーパー)

ディレクトリ ゲートキーパーの冗長性

UnifiedCM と UnifiedCM Express の相互運用性

UnifiedCM と UnifiedCME 間の相互運用性の概要

コール タイプとコール フロー

保留音(Music on Hold)

アドホックおよび Meet-Me のハードウェア会議

分散型呼処理を使用したマルチサイト配置における SIP 経由の UnifiedCM と UnifiedCME の相互運用性

ベスト プラクティス

設計上の考慮事項

分散型呼処理を使用したマルチサイト配置における H.323 経由の UnifiedCM と UnifiedCME の相互運用性

ベスト プラクティス

設計上の考慮事項

呼処理

音声コールとビデオ コールの処理は、IP テレフォニー システムによって提供される重要な機能です。この機能は、特定のタイプの呼処理エンティティまたは呼処理エージェントによって処理されます。呼処理の操作は重要であるため、ユニファイド コミュニケーションの配置を設計して、呼処理システムが、必要なユーザ数およびデバイス数を処理するのに十分なスケーラビリティと、ネットワークおよびアプリケーションのさまざまな異常または障害を処理するのに十分な復元性を持つようにすることが重要です。

この章では、シスコの呼処理製品によってスケーラブルで復元性のある呼処理システムを設計するためのガイドラインを示します。このような製品には、Cisco Unified Communications Manager(Unified CM)、Cisco Business Edition、および Cisco Unified Communications Manager Express(Unified CME)があります。また、この章ではゲートキーパー機能についても説明します。この機能は、複数の呼処理システムまたは呼処理エージェントが並行して配置されるシナリオにおいて、ユニファイド コミュニケーションの配置のもう 1 つの重要な機能です。すべての場合で、主に次の要素を中心に説明します。

規模:ユーザ、ロケーション、ゲートウェイ、アプリケーションなどの数

パフォーマンス:コールのレート

復元性:冗長性の規模

この章では、特に次のトピックについて説明します。

「呼処理アーキテクチャ」

ここでは、一般的な呼処理アーキテクチャおよびさまざまな呼処理ハードウェア オプションについて説明します。また、Unified CM クラスタリングについても説明します。

「呼処理のハイ アベイラビリティ」

ここでは、ネットワークの冗長性、サーバおよびプラットフォームの冗長性、ロード バランシングなど、呼処理のハイ アベイラビリティの考慮事項について説明します。

「呼処理のキャパシティ プランニング」

ここでは、呼処理配置のサイジングの概要を示し、Unified Communications Sizing Tool について説明します。このツールは、Unified Communications の展開のさまざまなコンポーネントのサイジングおよび必要なリソースに関するガイダンスを提供します。IP テレフォニー展開を計画するときは、このツールを使用する必要があります。

「呼処理の設計上の考慮事項」

ここでは、基本設計のガイドラインと呼処理を配置するためのベスト プラクティスの要約リストを示します。

「コンピュータ テレフォニー インテグレーション(CTI)」

ここでは、Cisco コンピュータ テレフォニー インテグレーション(CTI)アーキテクチャについて説明し、CTI のコンポーネントとインターフェイス、CTI 機能、CTI のプロビジョニングとキャパシティ プランニングについて説明します。

「ゲートキーパーの設計上の考慮事項」

ここでは、Cisco Unified Communications の配置でゲートキーパーをどのように使用できるかについて説明します。シスコのゲートキーパーは、もう 1 台のスタンバイ ゲートキーパーとペアにすることも、クラスタ化してさらに高いパフォーマンスと復元性を実現することもできます。ゲートキーパーは、コール ルーティングとコール アドミッション制御に使用することもできます。

「Unified CM と Unified CM Express の相互運用性」

ここでは、分散型呼処理配置における Cisco Unified CM と Cisco Unified Communications Manager Express(Unified CME)間での H.323 と SIP での統合について説明します。

この章の新規情報

表 8-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 8-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

Cisco Business Edition の小規模な更新

この章の各項で説明

2012 年 10 月 31 日

CTI リモート デバイス

「コンピュータ テレフォニー インテグレーション(CTI)」

2012 年 6 月 28 日

Enterprise License Manager

「Enterprise License Manager」

2012 年 6 月 28 日

呼処理アーキテクチャ

ユニファイド コミュニケーション システムの設計と配置を成功させるには、コール ルーティング機能を提供する基盤の呼処理アーキテクチャを理解することが重要です。この機能は、次のシスコの呼処理エージェントによって提供されます。

Cisco Unified Communications Manager Express(Unified CME)

Cisco Unified CME は、小規模な単一サイト配置、大規模な分散マルチサイト配置、および Cisco Unified CM の集中型呼処理配置でリモート サイトにおいてローカル呼処理をバックアップする機能を提供するために呼処理サービスを提供します。

Cisco Business Edition

Cisco Business Edition は、小規模な単一サイト配置または小規模な分散マルチサイト配置に、呼処理サービスを提供します。Cisco Business Edition には、Business Edition 3000、Business Edition 5000、および Business Edition 6000 の 3 つのバージョンがあります。この 3 つのバージョン間の違いを次に示します。

Cisco Business Edition が配置されるハードウェア、および共存して実行できるアプリケーションとサービスの数。Business Edition 3000 および 5000 では、共存する Cisco Unified CM 呼処理サービスおよび Cisco Unity Connection メッセージング サービスを提供します。Business Edition 6000 は、単一の UCS サーバの 5 つの共存アプリケーションをサポートします。サポートされるアプリケーションは、Cisco Unified CM、Cisco Unified Provisioning Manager、Cisco Unity Connection、Cisco IM and Presence、Cisco Unified Contact Center Express(Unified CCX)、Cisco Unified Attendant Console サービスと Cisco TelePresence Video Communication Server(VCS)です。

システムのキャパシティ。Cisco Business Edition は、バージョンに応じて、300 ~ 1,000 人のユーザと 400 ~ 1,200 のエンドポイントをサポートします。

インストールおよびアップグレードの手順。Business Edition 3000 および 5000 は、1 つのソフトウェア イメージを使用して、サポートされる Cisco MCS プラットフォーム上で Unified CM および Unity Connection のインストールやアップグレードをネイティブに実行します。Business Edition 6000 は、Cisco UCS C200 および C220 シリーズ プラットフォーム上の VMware に共存する各アプリケーションをそれぞれインストールやアップグレードするために個々のソフトウェア イメージを使用します。Unified CM 8.6 以降では、4 つの共存アプリケーションの 1 つとして Cisco Unified Provisioning Manager(Cisco Unified PM)を使用して、Business Edition 6000 を配置できます。Open Virtualization Archive(OVA)テンプレートは、Business Edition 6000 サーバへの、コピーベースの Cisco Unified PM のインストールに使用されます。

Cisco Unified Communications Manager(Unified CM)

Cisco Unified CM は、小規模~非常に大規模な単一サイト配置、マルチサイト集中型呼処理配置、およびマルチサイト分散呼処理配置に、呼処理サービスを提供します。

ここでは、さまざまな呼処理ハードウェア オプションについて説明し、Unified CM クラスタリングの概要を示します。

呼処理ハードウェア

さまざまなタイプのプラットフォームで、3 つのエンタープライズ呼処理タイプがサポートされています。

Cisco Unified CME は Cisco Integrated Services Routers(ISR)上で実行します。

Cisco Business Edition 3000 および Business Edition 5000 は、Cisco Media Convergence Servers(MCS)上でアプライアンスとして直接実行します。Cisco Business Edition 6000 は、Cisco Unified Computing System(UCS)の C シリーズ サーバ上で VMware Hypervisor を使用した仮想マシンとして実行します。

Cisco Unified CM は、MCS(または同等の)サーバ上でアプライアンスとして直接実行するか、または VMware Hypervisor を使用した仮想マシンとして実行します。Unified CM が仮想マシンとして配置されている場合、Tested Reference Configurations と仕様ベースのハードウェア サポートの 2 つのハードウェア オプションを使用できます。Tested Reference Configurations(TRC)は、Cisco UCS ハードウェアをベースに選択されたハードウェア構成です。テストされ、具体的に保証された性能、キャパシティ、Unified Communications 仮想マシンを満載して稼働するアプリケーションの組み合わせシナリオが文書化されています。TRC は、特定の配置シナリオ用に事前に作成されたシスコのパッケージ ソリューションをご希望のお客様、またはハードウェア仮想化の経験のないお客様(または両方)を対象としています。TRC の詳細については、次の Web サイトにあるマニュアルを参照してください。

http://docwiki.cisco.com/wiki/Tested_Reference_Configurations_(TRC)

また、仕様ベースのハードウェア サポートによって、より柔軟なハードウェア構成を使用することもできます。たとえば、VMware ハードウェア互換性リスト( http://www.vmware.com/resources/compatibility/search.php )に一覧されている Cisco UCS、Hewlett-Packard、および IBM プラットフォームのサポートや、iSCSI、FCoE、および NAS(NFS)ストレージ システムのサポートなどが追加されます。仕様ベースのハードウェア サポートは、仮想化およびサーバとストレージのサイジングに関する深い専門知識を持っており、独自のハードウェア標準の使用を希望するお客様を対象としています。仕様ベースのハードウェア サポートの詳細については、次の Web サイトにあるマニュアルを参照してください。

http://docwiki.cisco.com/wiki/Specification-Based_Hardware_Support

表 8-2 に、3 つのエンタープライズ呼処理タイプ、これらの呼処理アプリケーションが置かれるサーバまたはプラットフォームのタイプ、およびそれらのプラットフォームの全般的な特性の概要を示します。表には、Cisco UCS プラットフォーム用の Tested Reference Configurations が含まれていますが、仕様ベースのハードウェア サポートでサポートされるプラットフォームは含まれていません。

表 8-2 呼処理プラットフォームのタイプ

呼処理タイプ
プラットフォーム タイプ
シスコのプラットフォーム モデル
特性

Cisco Unified CME

Cisco IOS ルータ

2800、2900、3700、3800、および 3900 シリーズ1

単一プロセッサ

単一または複数の電源装置(モデルによって異なる)

Cisco Business Edition

Cisco Unified Computing System(UCS)C シリーズ ラックマウント サーバ(Business Edition 6000)

UCS C シリーズ:C200 M2 および C220 M3

複数のプロセッサ

RAID 10 搭載の複数の SAS ディスク ドライブのサポート(ESXi を実行し、ローカル ディスク ドライブ上に Cisco Unified Communications 仮想マシンを格納)

ベア メタル サポートなし5

標準 Cisco Media Convergence Server(MCS)(Business Edition 5000 用)

MCS 78282

単一プロセッサ

単一電源装置

RAID 0/1 搭載の SATA コントローラをサポート

2 つの IP インターフェイス

Business Edition 3000 バージョン 8.5(1) 以降の標準 MCS

MCS 7816-I5

単一プロセッサ

単一電源装置

非 RAID SATA ハード ディスク

2 つの IP インターフェイス

Business Edition 3000 バージョン 8.6(1) 以降用の専用アプライアンス

MCS 7890-C1

単一プロセッサ

単一電源装置

T1/E1 ポートを 2 個搭載した統合音声ゲートウェイ

メディア リソース用オンボード DSP

単一の IP インターフェイス

Cisco Unified CM

標準 MCS

MCS 7815、MCS 7816、または同等のサーバ

単一プロセッサ

単一電源装置

非 RAID SATA ハード ディスク

2 つの IP インターフェイス3

RAID 搭載の標準 MCS

MCS 7825 または同等のサーバ

単一プロセッサ

単一電源装置

RAID 0/1 搭載の SATA コントローラをサポート

2 つの IP インターフェイス

ハイ アベイラビリティ MCS

MCS 7835、MCS 7845、または同等のサーバ

1 つまたは複数のプロセッサ

複数の電源装置

RAID 1 搭載の複数の Serial Attached SCSI(SAS)ドライブ

2 つの IP インターフェイス

Unified Computing System(UCS)B シリーズ ブレード サーバ

UCS B シリーズ(B200、B230、B440 など)

ハーフ幅またはフル幅のブレード

複数のプロセッサ

複数の電源装置

複数の SAS ディスク ドライブ(ESXi を実行)4またはディスクレス ブレード

FC SAN ストレージ上に格納される Cisco Unified Communications 仮想マシン

ベア メタル サポートなし5

Unified Computing System(UCS)C シリーズ ラックマウント サーバ

ローエンド UCS C シリーズ(たとえば、C200、C220 TRC#2)

複数のプロセッサ

1 つまたは複数の電源装置

複数の SAS ローカル ディスク ドライブ

ベア メタル サポートなし5

ハイエンド UCS C シリーズ(たとえば、C210、C220 TRC#1、C240、C260)

複数のプロセッサ

複数の電源装置

複数の SAS ローカル ディスク ドライブ(ESXi のみを実行、ESXi および Unified Communications 仮想マシンを実行、またはディスクレス サーバ)6

ベア メタル サポートなし5

1.これは、サポートされる Cisco IOS プラットフォームの詳細なリストではありません。

2.Cisco MCS 7828 は Business Edition 5000 のみサポートします。

3.Cisco MCS 7815 プラットフォームの IP インターフェイスは 1 つだけです。

4.UCS B シリーズ ブレード サーバのディスクは、仮想マシン ソフトウェア(ESXi)専用です。Unified CM などのアプリケーションはインストールされず、ブレード上のドライブで実行されません。

5.UCS B シリーズおよび C シリーズ サーバは、Cisco Unified Communications アプリケーションにベア メタル サポートを提供しません。UCS B シリーズおよび C シリーズ サーバは、ESXi ハイパーバイザ ソフトウェアを実行する必要があります。

6.サポートされるオプションは、サーバ モデルによって異なります。詳細については、http://www.cisco.com/go/uc-virtualized を参照してください。

サポートされている MCS サーバまたは同等品の全リストについては、次の Web サイトで入手可能な資料を参照してください。

http://www.cisco.com/go/swonly

Tested Reference Configurations の完全なリストまたは仕様ベースのハードウェア サポートの詳細については、次の Web サイトで入手可能な資料を参照してください。

http://www.cisco.com/go/uc-virtualized

必要な規模、パフォーマンス、および冗長性に応じて、特定の配置に適した呼処理タイプとプラットフォームを決定します。一般に、Unified CM およびハイエンドな MCS サーバや UCS サーバではキャパシティと可用性は向上し、Cisco Unified CME と Cisco Business Edition ではキャパシティと冗長性のレベルは低下します。冗長性とスケーラビリティの詳細については、「呼処理のハイ アベイラビリティ」および「呼処理のキャパシティ プランニング」を参照してください。

Unified CM クラスタのサービス

MCS-7815 または MCS-7816 で実行される Cisco Unified CME、Business Edition 3000 および 5000、および Unified CM は、スタンドアロンの呼処理アプリケーションまたはエンティティです。ただし、それ以外のすべてのサーバ プラットフォームで実行される Unified CM には、クラスタリングの概念があります。Unified CM アーキテクチャでは、複数の物理サーバを 1 つの呼処理エンティティまたは IP PBX システムとして連携させることができます。このサーバ グループを クラスタ と呼びます。Unified CM サーバのクラスタは、設計上の制限事項を遵守している限り、IP ネットワークを介して分散していてもかまいません。クラスタを使用することで、空間的な冗長性、およびそれに伴う復元性を Unified Communications システムの設計にもたらすことができます。

Unified CM クラスタの内部には、それぞれ固有のサービスを提供する複数のサーバが存在します。これらの各サービスは、同じ物理サーバ上で他のサービスと共存できます。たとえば、小規模なシステムでは、データベース サービス、呼処理サービス、およびメディア リソース サービスを単一のサーバで提供できます。クラスタの規模とパフォーマンスを強化する必要が高まった場合は、これらのサービスの多くを専用物理サーバに移行する必要があります。


) クラスタ内のすべてのサーバに対して同じサーバ モデルを使用することを推奨しますが、個別のハードウェア バージョンがすべてサポートされており、すべてのサーバで同じバージョンの Unified CM が実行されている場合、クラスタ内にサーバ モデルを混在させることもサポートされます。ただし、クラスタ内のさまざまなサーバ モデル間でのキャパシティの相違を考慮する必要があります。クラスタの全体的なキャパシティは、最終的にはクラスタ内の最小のサーバのキャパシティによって決まる場合があるためです。クラスタ内のすべてのサーバが同じモデル タイプの場合、異なるベンダーのサーバをクラスタ内に混在させることもサポートされ、キャパシティに悪影響はありません。呼処理キャパシティの詳細については、「呼処理のキャパシティ プランニング」の項を参照してください。


次の項では、Unified CM クラスタを形成しているサーバが実行する各種の機能について説明し、必要な規模、パフォーマンス、および復元性を達成するようにサーバを配置する方法について、ガイドラインを示します。

クラスタ サーバ ノード

図 8-1 に、複数のサーバ ノードで構成された一般的な Unified CM クラスタを示します。

図 8-1 一般的な Unified CM クラスタ

 

パブリッシャ

パブリッシャはすべてのクラスタに必要なサーバであり、図 8-1 に示すように、クラスタごとに 1 つのパブリッシャだけを配置できます。このサーバは、最初にインストールする必要があります。クラスタ内の他のすべてのサブスクライバに対して、データベース サービスを提供します。パブリッシャ サーバは、コンフィギュレーション データベースに完全な読み取りと書き込みのアクセスができる唯一のサーバです。

1,250 ユーザを超える大規模なシステムの場合には、管理操作によるテレフォニー サービスへの影響を防止するために、専用パブリッシャを推奨します。専用パブリッシャのサーバ上で、呼処理または TFTP サービスが提供されることはありません。代わりに、これらのサービスはクラスタ内の他のサブスクライバ サーバによって提供されます。

パブリッシャ用のハードウェア プラットフォームは、クラスタで必要な規模とパフォーマンスを基準として選択する必要があります。パブリッシャは、呼処理サブスクライバと同等のサーバ パフォーマンスを持つものにすることを推奨します。可能な場合には、パブリッシャをハイ アベイラビリティサーバにして、ハードウェアの障害による影響を最小限に抑えるようにします。

サブスクライバ

Unified CM ソフトウェアのインストール時に、パブリッシャとサブスクライバという 2 つのタイプのサーバを定義できます。これらの用語は、データベース間の関係をインストール時に定義するために使用されています。ソフトウェアを初期インストールしたときに使用可能になるのは、データベース サービスとネットワーク サービスだけです。すべてのサブスクライバ ノードは、パブリッシャにサブスクライブして、データベース情報のコピーを取得します。ただし、Unified CM クラスタの初期化時間を短縮するために、クラスタ内のすべてのサブスクライバ サーバは、初期化時にデータベースのローカル コピーを使用しようとします。これにより、Unified CM クラスタの全体的な初期化時間は短縮されます。すべてのサブスクライバ ノードは、パブリッシャまたは他のサブスクライバ ノードからの変更通知によって、データベースのローカル コピーを更新された状態に保ちます。

図 8-1 に示すように、複数のサブスクライバ ノードが同じクラスタのメンバーになることができます。サブスクライバ ノードには、Unified CM 呼処理サブスクライバ ノード、TFTP サブスクライバ ノード、および会議や保留音(MoH)などの機能を提供するメディア リソース サブスクライバ ノードがあります。

呼処理サブスクライバ

呼処理サブスクライバは、Cisco CallManager サービスが使用可能になっているサーバです。このサービスが使用可能になった時点で、このサーバは呼処理機能を実行できるようになります。電話、ゲートウェイ、メディア リソースなどのデバイスが登録やコール発信を実行できるのは、このサービスが使用可能になっているサーバに対してのみです。図 8-1 に示すように、複数の呼処理サブスクライバが同じクラスタのメンバーになることができます。実際、Unified CM は、クラスタごとに最大 8 つの呼処理サブスクライバ ノードをサポートします。

TFTP サブスクライバ

TFTP サブスクライバまたはサーバ ノードは、Unified CM クラスタの一部として、次の 2 つの主要な機能を実行します。

サービスのためのファイルの提供。電話やゲートウェイなどのデバイスのコンフィギュレーション ファイル、電話および一部のゲートウェイのアップグレード用バイナリ ファイル、さまざまなセキュリティ ファイルなど。

コンフィギュレーション ファイルおよびセキュリティ ファイルの生成。通常は署名済みであり、ダウンロード用として提供する前に暗号化されることもあります。

この機能を提供する Cisco TFTP サービスは、クラスタ内の任意のサーバで使用可能にできます。ただし、何らかの設定を変更すると、TFTP サービスがコンフィギュレーション ファイルを再生成するため、1,250 ユーザを超えるクラスタでは、他のサービスが影響を受ける場合があります。このため、1,250 ユーザを超えるクラスタまたは頻繁な設定変更を伴う機能を備えたクラスタでは、図 8-1 に示すように、特定のサブスクライバ ノードを TFTP サービス専用にすることを推奨します。

TFTP サブスクライバのハードウェア プラットフォームには、呼処理サブスクライバと同じものを使用することを推奨します。

メディア リソース サブスクライバ

メディア リソース サブスクライバまたはサーバ ノードは、会議や保留音などのメディア サービスをエンドポイントとゲートウェイに提供します。これらのタイプのメディア リソース サービスは、Cisco IP Voice Media Streaming Application サービスによって提供されます。このサービスは、クラスタ内の任意のサーバ ノードで使用可能にできます。

メディア リソースには、次のものがあります。

保留音(MoH):保留状態になっているデバイス、会議に転送または追加されるデバイスに対して、マルチキャストまたはユニキャストの保留音を提供できます (「保留音(Music on Hold)」を参照)。

アナンシエータ サービス:電話番号を間違えていることや、コール ルーティングが使用不可になっていることを伝える場合に、トーンの代わりに音声アナウンスを流します (「アナンシエータ」を参照)。

会議ブリッジ:アドホック会議と Meet-Me 会議のための、ソフトウェア ベースの会議を提供します (「会議」を参照)。

メディア ターミネーション ポイント(MTP)サービス:H.323 クライアント、H.323 トランク、および Session Initiation Protocol(SIP)エンドポイントおよびトランク用の機能を提供します (「メディア ターミネーション ポイント(MTP)」を参照)。

クラスタ内でメディア リソースを実行する場合は、メディア リソース サービスの処理とネットワークに関する要件が追加される場合に備えて、すべてのガイドラインに準拠することが重要です。一般に、マルチキャスト MoH とアナンシエータ サービスには専用のメディア リソース サブスクライバを使用せず、ユニキャスト MoH およびソフトウェア ベースの大規模な会議と MTP に、図 8-1 に示すような専用のメディア リソース サブスクライバを使用することを推奨します(これらのサービスが、「メディア リソース」、の章で説明している設計ガイドラインの範囲内にない場合は除きます)。

その他のクラスタ サービス

Unified CM クラスタ内の特定のタイプのサブスクライバ ノード以外に、Unified CM 呼処理サブスクライバ ノードで実行できるその他のサービスもあり、追加機能を提供して使用可能にできます。

Computer Telephony Integration(CTI)Manager

CTI Manager サービスは、Cisco CallManager サービスと TAPI または JTAPI 統合アプリケーションの仲介者として機能します。このサービスは、CTI を利用するアプリケーションのクラスタで必要です。CTI Manager サービスは、CTI アプリケーションの認証を提供し、アプリケーションがエンドポイントの回線をモニタおよび制御できるようにします。CTI Manager は、呼処理サブスクライバ上だけで使用可能にできます。したがって、クラスタ内では最大で 8 つのノードで CTI Manager サービスを実行できます。

CTI Manager の詳細については、「コンピュータ テレフォニー インテグレーション(CTI)」を参照してください。

Unified CM のアプリケーション

Unified CM 上では、Cisco Unified CM Assistant、エクステンション モビリティ、Web Dialer などのさまざまなタイプのアプリケーション サービスを使用可能にできます。これらのアプリケーションに関する設計ガイドラインの詳細については、「Cisco Unified CM アプリケーション」の章を参照してください。

Enterprise License Manager

Cisco Unified Communications システム 9. x は、デバイスではなくユーザに基づいてソフトウェア ライセンスを管理する Enterprise License Manager(ELM)を採用しています。お客様は、ユーザ ライセンスを購入して ELM アプリケーションに追加します。ELM アプリケーションはすべてのアプリケーションから要件を収集して集約し、すべての使用可能なユーザ権限付与と比較します。

次の Unified Communications アプリケーションは ELM を使用します。

Cisco Unified Communications Manager(Unified CM)

Cisco Unified CM IM and Prexence サービス

Cisco Unity Connection

ライセンスは、シスコから購入し、電子メールによって提供され、次に ELM にロードされます。サブスクライビング アプリケーションにライセンスが必要なときはいつでも、ライセンスは ELM ライセンス プールから差し引かれます。ライセンスが不要になった場合は同様に、ELM ライセンス プールに将来使用するために戻ります。

ELM ライセンス プール内に十分なライセンスがない場合でも、60 日間の猶予期限内は、管理者がユーザを追加できます。もし十分なライセンスがないまま 60 日間の猶予期限が経過した場合、Unified Communications アプリケーションはそれ以降一切の変更を許可しなくなります。ただし、アプリケーションがサービスを失うことなく、機能し続けます。

Cisco Unified Communications ライセンシングに関する詳細については、次の URL を参照してください。

http://www.cisco.com/go/uclicensing

配置例

ELM は Unified Communications アプリケーションと一緒に自動的にインストールされるものを実行させることも、あるいは専用のサーバまたは仮想マシンに ELM だけをインストールすることも可能です。運用中、ELM は非常に少量のリソースだけを消費します。その結果、サーバまたは仮想マシンのサイジングに影響がないと見なされます。さらに、ELM は非冗長アプリケーションとして展開されます。ELM のアプリケーションが使用不能になる場合(たとえば、アプリケーションが存在するサーバに致命的なハードウェア障害が発生している場合)、お客様には、ライセンスの適用が発生する前にアプリケーションを復元するための猶予期間が 60 日間、付与されます。適用が呼び出されると、アプリケーションがサービスを停止せずに機能し続けることに留意してください。

配置の推奨事項

単一のサーバまたはクラスタで 1 つのアプリケーションだけをインストールする場合、ELM 共存を実行します。

非常に少数のアプリケーション インスタンスをインストールする場合、次を実行できます。

異なる仮想マシンまたはサーバで ELM を実行します。この方法を推奨します。

ライセンス プーリングを必要とせず、集中型ライセンス管理を望まない場合、各アプリケーション サーバに異なる ELM を実行します。

ライセンス プーリングと集中管理のいずれか一方、もしくは両方が必要な場合でも、ELM を実行するための仮想マシンまたはサーバを割り当てたくない場合は、単一の ELM を 1 つのアプリケーション サーバと共存させて実行します。

中規模から大規模な配置では、別のサーバまたは仮想マシン上で ELM を実行します。必要な仮想マシンまたはサーバの数の増分の影響は、この場合最小限であり、運用コストと設備投資間のトレード オフは好都合です。

ELM は次のいずれかの方法で配置される場合があります。

企業またはグローバル

説明が示すように、1 つの ELM インスタンスは、組織全体またはグローバルの配置をサポートできます。このモデルは 1 つのライセンス プールをすべての Unified Communications アプリケーションが共有して利用するために最高のシンプルさを提供します。

地域、または事業部

世界に複数の Unified Communicatios を配置する企業では、複数の ELM インスタンスを各地域ごとに設定することが可能です(たとえば、北米に 1 つ目、EMEA に 2 つ目、APAC に 3 つ目)。このモデルでは、企業はさまざまな会計境界を越えてライセンスのコストに、より容易に対応できます。

個々の Unified Communications アプリケーション

さらに細かさを必要としているお客様の場合、ELM のインスタンスは各 Unified Communications アプリケーション用に設定できます。たとえば、お客様に 3 つの Cisco Unified CM クラスタがある場合、3 つの ELM インスタンスを設定できます。このシナリオは、より細かい会計費目に沿って運用を行ったり、運用コストやその他の経費をより厳密に管理するために小さなライセンス プールに分割することを希望するお客様にとって役立ちます。

クラスタ内通信

クラスタ内通信(Unified CM クラスタ内の通信)には、2 種類あります(図 8-2 および図 8-3 を参照)。1 つは、すべてのデバイス設定情報を含んでいるデータベースを配布するためのメカニズムです(図 8-2 の「データベースのレプリケーション」を参照)。コンフィギュレーション データベースは、パブリッシャ サーバに保存され、コピーがクラスタのサブスクライバ ノードに複製されます。データベースの変更のほとんどはパブリッシャで加えられ、サブスクライバ データベースに伝達されます。そのため、クラスタのメンバー全体で設定の一貫性が確保され、データベースの空間的な冗長性が容易になります。

ユーザ方向の呼処理機能に対するデータベースの変更は、エンド ユーザ デバイスが登録されるサブスクライバ サーバで行われます。次にサブスクライバ サーバが、これらのデータベース変更をクラスタにある他のすべてのサーバに複製し、ユーザ方向機能に冗長性を提供します (図 8-2 の「呼処理のユーザ方向機能の複製」を参照)。これらの機能には、次のものがあります。

Call Forward All(CFA)

メッセージ待機インジケータ(MWI)

プライバシーの有効/無効

エクステンション モビリティのログイン/ログアウト

ハント グループのログイン/ログアウト

デバイス モビリティ

エンド ユーザおよびアプリケーション ユーザの Certificate Authority Proxy Function(CAPF)ステータス

クレデンシャルのハッキングと認証

図 8-2 データベースおよびユーザ方向機能の複製

 

Intra-Cluster Communication Signaling(ICCS)と呼ばれる、もう 1 つのクラスタ内通信は、デバイスの登録、ロケーションの帯域幅、共有メディア リソースなどのランタイム データの伝搬と複製です(図 8-3 を参照)。この情報は、Cisco CallManager サービス(呼処理サブスクライバ)を実行している、クラスタのすべてのメンバー全体で共有されます。クラスタのメンバーと関連ゲートウェイとの間で、コールの最適なルーティングが確保されます。

図 8-3 Intra-Cluster Communication Signaling(ICCS)

 

クラスタ内セキュリティ

Unified CM クラスタ内の各サーバが内部で動的ファイアウォールを実行します。Unified CM のアプリケーション ポートは、送信元 IP フィルタリングによって保護されます。動的ファイアウォールは、認証済みサーバまたは信頼できるサーバに対してだけ、これらのアプリケーション ポートを開きます (図 8-4を参照)。

図 8-4 クラスタ内セキュリティ

 

このセキュリティ メカニズムは、単一の Unified CM クラスタ内のサーバ ノード間だけに適用できます。Unified CM のサブスクライバは、パブリッシャのデータベースにアクセスする前に、クラスタ内で認証されます。クラスタ内通信およびデータベース複製は、認証済みサーバ間だけで発生します。インストール時にサブスクライバ ノードは、事前共有キー認証メカニズムでパブリッシャに対して認証されます。認証プロセスに必要な手順は次のとおりです。

1. セキュリティ パスワードを使用してパブリッシャ サーバをインストールします。

2. Unified CM Administration を使用することによって、パブリッシャ上にサブスクライバ サーバを設定します。

3. パブリッシャ サーバのインストール時に使用されたのと同じセキュリティ パスワードを使用して、サブスクライバ サーバをインストールします。

4. サブスクライバのインストール後、サーバは、UDP 8500 を使用する管理チャネル上でパブリッシャとの接続を確立しようとします。サブスクライバは、ホスト名、IP アドレスなどのすべてのクレデンシャルをパブリッシャに送信します。クレデンシャルは、インストール時に使用されたセキュリティ パスワードを使用して認証されます。

5. パブリッシャは、独自のセキュリティ パスワードを使用してサブスクライバのクレデンシャルを確認します。

6. その情報が有効な場合、パブリッシャは、自身の動的ファイアウォール テーブルに、信頼できる送信元としてサブスクライバを追加します。サブスクライバは、データベースへのアクセスを許可されます。

7. サブスクライバは、パブリッシャから他のサブスクライバ サーバのリストを取得します。すべてのサブスクライバが互いに管理チャネルを確立し、メッシュ トポロジが作成されます。

音声アクティビティ検出

Unified CM クラスタ内で音声アクティビティ検出(VAD)を使用不可にしておくことを推奨します。デフォルトでは、Unified CM サービス パラメータで VAD は使用不可になっています。Cisco IOS ゲートウェイで設定されている H.323 および SIP ダイヤル ピア上で使用不可にするには、 no vad コマンドを使用してください。

クラスタリングに関する一般的なガイドライン

すべての Unified CM クラスタに次のガイドラインが適用されます。


) 1 つのクラスタに複数のサーバ プラットフォームを組み合わせることができますが、クラスタ内のすべてのサーバでは、同じ Unified CM ソフトウェア リリースを実行する必要があります。


通常の環境では、同一 LAN または MAN 内にクラスタのすべてのメンバーを入れます。

クラスタが IP WAN にわたって構築されている場合、「IP WAN を介したクラスタリング」(P.26-10)の項を参照して、IP WAN を介したクラスタリングのガイドラインに従ってください。

Unified CM クラスタに、20 のサーバを組み込めるようになりました。20 のサーバのうち、呼処理サブスクライバ(Cisco CallManager サービスを実行するノード)は最大で 8 つです。クラスタ内の残りのサーバ ノードは、専用データベース パブリッシャ、専用 TFTP サブスクライバ、またはメディア リソース サブスクライバとして設定できます。

Cisco MCS 7815、MCS 7816、または同等のサーバで Unified CM を配置するときは、配置内には最大 2 台のサーバという制限があります。1 台をパブリッシャ、TFTP、およびバックアップ呼処理サブスクライバ ノードにし、もう 1 台をプライマリ呼処理サブスクライバにします。Cisco MCS 7816 または同等のサーバでは、この構成で最大 500 台の電話機がサポートされます。

キャパシティの大きいサーバを使用して 2 サーバ クラスタを配置する場合も、クラスタ内のユーザ数が 1,250 を超えないようにすることを推奨します。1,250 ユーザを超える場合は、専用パブリッシャと別個のサーバをプライマリおよびバックアップの呼処理サブスクライバ用に推奨します。

Business Edition 3000 8.5(1) は MCS 7816 サーバ プラットフォームで実行されますが、Business Edition 3000 8.6(1) 以降のバージョンは、MCS 7816 または MCS 7890-C1 専用アプライアンスで実行されます。いずれの場合も、Business Edition 3000 は Unified CM の単一のインスタンス(パブリッシャとシングル サブスクライバの複合インスタンス)を提供します。セカンダリ サブスクライバ インスタンスは設定できません。

Business Edition 5000 は、単一のハードウェア プラットフォーム(MCS 7828)上で動作し、Unified CM の単一のインスタンス(パブリッシャとシングル サブスクライバの複合インスタンス)を提供します。セカンダリ サブスクライバ インスタンスは設定できません。

Business Edition 6000 は、UCS C200 または C220 ラックマウント サーバ上で動作し、Unified CM の単一のインスタンス(パブリッシャとシングル サブスクライバの複合インスタンス)を提供します。増設の UCS C200 または C220 サーバは、アクティブ/スタンバイ方式またはロード バランシング方式で、Cisco Business Edition 呼処理やその他の共存するアプリケーションにサブスクライバの冗長性を提供するために配置できます。負荷を 2 つの UCS サーバ間で分散できるよう、ロード バランシングを使用する冗長サーバを配置することを推奨します。また、MCS サーバを使用して、アクティブ/スタンバイ方式またはロード バランシング方式で Unified CM サブスクライバの冗長性を提供できます。

Cisco UCS B シリーズまたは C シリーズ サーバで Unified CM を展開するときは、MCS サーバのクラスタの場合のように、各 Unified CM ノード インスタンスは、パブリッシャ ノード、呼処理サブスクライバ ノード、TFTP サブスクライバ ノード、またはメディア リソース サブスクライバ ノードのいずれかになります。Unified CM クラスタと同様に、クラスタごとに 1 つのパブリッシャ ノードだけがサポートされます。

Cisco UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバは、DB9 シリアル ポート、Video Graphics Array(VGA)モニタ ポート、および 2 つの Universal Serial Bus(USB)ポートを提供するローカルのキーボード、ビデオ、およびマウス(KVM)ケーブル接続をサポートしますが、Unified CM VMware 仮想アプリケーションはこれらの USB ポートおよびシリアル ポートにアクセスできません。そのため、オーディオ カード(MOH-USB-AUDIO=)、シリアル/USB コネクタ(USB-SERIAL-CA=)、またはフラッシュ ドライブなどの USB デバイスは、これらのサーバに接続できません。代わりに、次のオプションを利用できます。

MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用するか、または Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB MoH オーディオ カード(MOH-USB-AUDIO=)を接続できるようにすることを検討します。

SMDI シリアル接続の場合は、Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB シリアル接続に使用します。

システムのインストール ログの保存には、仮想フロッピー ソフトメディアを使用します。

呼処理のハイ アベイラビリティ

呼処理サービスは、可用性が高くなるように Unified Communications システム内に配置して、1 つの呼処理コンポーネントの障害によってすべての呼処理サービスが使用不可にならないようにする必要があります。

ハードウェア プラットフォームのハイ アベイラビリティ

呼処理のプラットフォームは、特定の配置のサイズとスケーラビリティだけでなく、プラットフォーム ハードウェアの冗長性にも基づいて選択する必要があります。

たとえば、可用性の高い配置のために、複数のプロセッサと複数のハードディスク ドライブを備えたプラットフォームを選択する必要があります。このことが重要なのは大規模な配置だけでなく、個別のコンポーネントの障害によって機能またはサービスが失われないようにするためにハイ アベイラビリティを必要とする配置にとっても重要です。

さらに、可能な場合は二重化電源を備えたプラットフォームを選択して、1 つの電源の障害によってプラットフォームが失われないようにします。二重化電源をサポートするプラットフォームを調べるには、 表 8-2 を参照してください。二重化電源を備えたプラットフォームを 2 つの異なる電力源に接続して、1 つの電源回路が故障しただけでプラットフォーム全体に障害が発生することを回避します。二重化電源の使用と無停電電源(UPS)の使用を組み合わせると、電力の可用性は最大になります。二重化電源プラットフォームを実現できない配置でも、建物の電力が必要なレベルの電力の可用性を備えていない状況では、UPS の使用を推奨します。

ネットワーク接続のハイ アベイラビリティ

IP ネットワークへの接続性も、最大限のパフォーマンスとハイ アベイラビリティにとって重要な考慮事項です。呼処理プラットフォームを可能な最高速度でネットワークに接続し、最大のスループットを確保します。通常は、プラットフォームに応じて 1000 Mbps または 100 Mbps 全二重です。小規模な配置で 1000 または 100 Mbps のネットワーク アクセスが使用可能でない場合、10 Mbps 全二重を使用してください。可能な場合は常に、全二重を使用してプラットフォームをネットワークに接続してください。全二重接続は、ネットワーク スイッチ ポートおよびプラットフォーム インターフェイス ポートの設定で 10 Mbps と 100 Mbps が可能です。1000 Mbps の場合は、プラットフォーム インターフェイス ポートおよびネットワーク スイッチ ポートの両方で、速度とデュプレックス モードの設定に Auto/Auto を使用することを推奨します。


) プラットフォーム インターフェイス ポートまたはネットワーク スイッチ ポートのいずれか一方が Auto モードのままであり、もう一方のポートが手動で設定される場合、ミスマッチが生じます。ベスト プラクティスは、プラットフォーム ポートとネットワーク スイッチ ポートの両方を手動で設定することです。ただし、ギガビット イーサネット ポートの場合は、Auto/Auto に設定する必要があります。


IP ネットワーク接続の速度とデュプレックス モード以外に、このネットワーク接続の復元性も同じように重要です。ユニファイド コミュニケーションの配置は、実際の冗長性に関して、基盤となるネットワーク接続に大きく依存します。このため、復元性が高い方法で基盤となるネットワーク インフラストラクチャを配置および設定することが重要です。可用性の高いネットワーク インフラストラクチャの設計の詳細については、「ネットワーク インフラストラクチャ」の章を参照してください。すべての場合で、インフラストラクチャ内でスイッチまたはルータの障害が発生しても、ほとんどのユーザは配置内で提供されているほとんどのサービスにアクセスできるように、ネットワークを設計する必要があります。

呼処理の可用性を最大にするには、可能な場合は呼処理プラットフォームを別々の建物および別々のネットワーク スイッチに置いて接続し、建物またはネットワーク インフラストラクチャ スイッチの障害が発生したときの呼処理への影響を最小にします。Unified CM 呼処理では、このことは、可能な場合は常に、クラスタ サーバ ノードを LAN または MAN 配置内の複数の建物またはロケーション間で分散させることを意味します。最低限でも、同じロケーション内の異なる物理ネットワーク スイッチ間でネットワーク接続を物理的に分散させることを意味します。

さらに、Cisco Unified CME および Cisco Business Edition がスタンドアロンの呼処理エンティティであっても、これらの呼処理タイプに物理的な分散とそれによる冗長性を提供することは、複数の呼処理エンティティを配置する場合にやはり意味を持ちます。そのようなシナリオで可能な場合は常に、Unified CME または Business Edition の各インスタンスをネットワーク内の異なる物理ロケーションにインストールするか、または最低限でも異なるネットワーク スイッチに物理的に接続します。

可用性の高いネットワーク インフラストラクチャを配置し、呼処理プラットフォームをネットワーク コンポーネントおよびロケーション間で物理的に分散させる以外に、各呼処理エンティティからネットワークへの可用性の高い物理接続を設定することも推奨します。可能な場合は常に、1 つのアップストリーム ハードウェア ポートまたはスイッチの障害によってプラットフォームのネットワーク接続が失われないように、2 つのネットワーク接続を使用してプラットフォームを 2 つの物理的に別々のネットワーク スイッチ上の 2 つの異なるポートに接続します。Unified CME ルータ プラットフォームには複数の物理ネットワーク インターフェイスを設定でき、ネットワークに二重接続できます。同様に、Unified CM および Business Edition 5000 呼処理タイプの MCS サーバ プラットフォームも、ネットワーク カード(NIC)チーミングを使用して、ネットワークに二重接続できます。

ネットワークの耐障害性に対応する NIC チーミング

NIC チーミング機能は、Cisco MCS(あるいは HP または IBM の同等のサーバ)を 2 枚の NIC、つまり 2 本の物理ケーブルで IP ネットワークに接続できるようにするものです。NIC チーミングは、障害の発生したポートから正常なポートに作業負荷を転送することによって、ネットワークのダウンタイムを防止します。NIC チーミングは、ロード バランシングまたはインターフェイス速度向上用には使用できません。NIC チーミングは、デュアル NIC の Cisco MCS プラットフォーム(あるいは HP または IBM の同等のプラットフォーム)でサポートされます。


) MCS 7815 プラットフォーム(あるいは HP または IBM の同等のプラットフォーム)のネットワーク インターフェイス ポートは 1 つだけのため、NIC チーミングを実行できません。


UCS ネットワークの耐障害性

Cisco UCS B シリーズ ブレード サーバは、UCS ネットワーク接続インフラストラクチャおよび基盤となるネットワーク接続されたストレージ エリア ネットワーク(SAN)を利用します。このバックエンドの UCS ネットワーク インフラストラクチャ(冗長な並行スイッチング ファブリック エクステンダおよび相互接続と、ファイバ チャネルまたはギガビット イーサネット アップリンクを含む)は、可用性の高いネットワーク接続およびストレージをこれらのサーバに提供します。UCS ネットワークおよびストレージ インフラストラクチャの可用性の高い仮想データセンター配置の詳細については、『 Designing Secure Multi-Tenancy into Virtualized Data Centers 』ドキュメント( http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/Virtualization/securecldg.html )を参照してください。

Unified CM のハイ アベイラビリティ

基盤となる Unified CM クラスタリングメカニズムのため、Unified Communications システムには、ハードウェア プラットフォームのディスクおよび電力コンポーネントの冗長性、物理ネットワーク ロケーション、および接続の冗長性以外にも、ハイ アベイラビリティに関する考慮事項があります。ここでは、呼処理サブスクライバの冗長性の考慮事項、呼処理のロード バランシング、およびその他のクラスタ サービスの冗長性について説明します。

呼処理の冗長性

Unified CM には、次の呼処理の冗長性設定オプションまたは冗長性方式があります。

2:1 冗長性方式:プライマリ呼処理サブスクライバ 2 台ごとに、1 つの共用セカンダリまたはバックアップ呼処理サブスクライバを設置します。

1:1 冗長性方式:プライマリ呼処理サブスクライバごとに、1 つのセカンダリまたはバックアップ呼処理サブスクライバを設置します。

これらの冗長性方式は、Unified CM クラスタ アーキテクチャ内の組み込み登録フェールオーバー メカニズムによって実施され、エンドポイントのプライマリ呼処理サブスクライバ ノードに障害が発生したときに、エンドポイントはバックアップ呼処理サブスクライバ ノードに再登録されます。この登録フェールオーバー メカニズムは、Skinny Client Control Protocol(SCCP)IP Phone のフェールオーバー レート、毎秒約 125 台の登録を実現できます。Session Initiation Protocol(SIP)電話機の登録フェールオーバー レートでは、毎秒約 40 台の登録です。

選択した呼処理の冗長性方式によって、配置の耐障害性だけでなく、アップグレードの耐障害性も決まります。

1:1 冗長性方式では、プライマリ呼処理サブスクライバで複数の障害が発生しても、呼処理機能に影響はありません。それに対して 2:1 冗長性方式では、バックアップ呼処理サブスクライバを共用する 2 つのプライマリ呼処理サブスクライバのうちの 1 つだけで障害が発生した場合、呼処理に影響はありません。

同様に、1:1 冗長性方式では、クラスタのアップグレードは、1 つのエンドポイント登録フェールオーバー期間だけが呼処理サービスに影響するように実行できます。それに対して 2:1 冗長性方式では、クラスタのアップグレードには複数の登録フェールオーバー期間が必要です。

Unified CM クラスタは、サービスへの影響を最小限に抑えてアップグレードできます。2 つのバージョン(リリース)の Unified CM を同じサーバ上に置いて、一方をアクティブ パーティションに、もう一方を非アクティブ パーティションに入れることができます。すべてのサービスとデバイスで、すべての Unified CM 機能に対して、アクティブ パーティションの Unified CM バージョンが使用されます。アップグレード時に、クラスタ操作はアクティブ パーティションにある現在のリリースの Unified CM を使用して続行されながら、アップグレード バージョンが非アクティブ パーティションにインストールされます。アップグレード プロセスの完了後は、サーバをリブートし非アクティブ パーティションをアクティブ パーティションに切り替えて、新しいバージョンの Unified CM を実行できます。

1:1 冗長性方式では、次の手順を使用して、ダウンタイムを最小限に抑えてクラスタをアップグレードできます。


ステップ 1 新しいバージョンの Unified CM を非アクティブ パーティションにインストールします。最初にパブリッシャにインストールしてから、すべてのサブスクライバ(呼処理サブスクライバ、TFTP サブスクライバ、およびメディア リソース サブスクライバ)にインストールします。リブートはしないでください。

ステップ 2 パブリッシャをリブートして、新しいバージョンに切り替えます。

ステップ 3 TFTP サブスクライバ ノードを 1 つずつリブートして、新しいバージョンに切り替えます。

ステップ 4 専用メディア リソース サブスクライバ ノードを 1 つずつリブートして、新しいバージョンに切り替えます。

ステップ 5 バックアップ呼処理サブスクライバを 1 つずつリブートして、新しいバージョンに切り替えます。

ステップ 6 プライマリ呼処理サブスクライバを 1 つずつリブートして、新しいバージョンに切り替えます。デバイス登録は、前にアップグレードおよびリブートされたバックアップ呼処理サブスクライバにフェールオーバーします。各プライマリ呼処理サブスクライバがリブートされると、デバイスはプライマリ呼処理サブスクライバへの再登録を開始します。


 

このアップグレード方法では、異なるバージョンの Unified CM ソフトウェアを実行しているサブスクライバ サーバにデバイスが登録される期間(登録フェールオーバー期間を除く)がありません。

2:1 冗長性方式では、クラスタ内のサーバ数を少なくできますが、アップグレード時の登録フェールオーバーの発生頻度が多くなり、アップグレードの全体的な時間および特定のエンドポイントの呼処理サービスが使用不可になる時間が長くなります。プライマリ呼処理サブスクライバのペアごとにバックアップ呼処理サブスクライバは 1 つだけであるため、1 つのバックアップ呼処理サブスクライバのオーバーサブスクリプションを回避するために、一度にペアのうちの 1 つのプライマリ呼処理サブスクライバだけで新しいバージョンへリブートできます。その結果、各ペアの最初のプライマリ呼処理サブスクライバが新しいバージョンに切り替わった後、エンドポイント登録をバックアップ サブスクライバから新しくアップグレードされたプライマリ サブスクライバに移動するための時間が発生し、その後で 2 番めのプライマリ サブスクライバでのエンドポイント登録をバックアップ サブスクライバに移動して新しいバージョンへリブートできるようになります。この間、2 番めのプライマリ呼処理サブスクライバのエンドポイントは、バックアップ サブスクライバへの再登録中に使用不可になるだけでなく、新しいバージョンを実行するノードに再登録されるまでは、すでにアップグレード済みの他のサブスクライバ ノード上のエンドポイントに到達することもできません。


) アップグレードを行う前に、ディザスタ リカバリ フレームワークを使用して、Unified CM およびコール詳細レコード(CDR)データベースを外部ネットワーク ディレクトリにバックアップすることを推奨します。このようにしておくと、アップグレードが失敗した場合のデータ損失を防止できます。



) Unified CM クラスタのアップグレードでは、一部またはほとんどのデバイスから一時的に登録サービスおよび呼処理サービスが失われるため、アップグレードは前もって計画し、定期保守時に実装する必要があります。1:1 冗長性方式を選択すると、デバイスのダウンタイムおよびサービス停止を最小にできますが、それでも、一部またはすべてのユーザが呼処理サービスを使用できない時間が発生します。


Unified CM のアップグレードの詳細については、次の URL で入手可能なインストールおよびアップグレード ガイドを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_installation_guides_list.html

Survivable Remote Site Telephony(SRST)による Unified CM の冗長性

Cisco IOS SRST は、Unified CM クラスタから離れたロケーションにあるエンドポイントに、可用性の高い呼処理サービスを提供します。Unified CM クラスタリングの冗長性方式は確かに、LAN または MAN 環境内の呼処理などのアプリケーション サービスに高レベルの冗長性をもたらします。ただし、WAN などの低速リンクによって中央の Unified CM クラスタから分離されたリモート ロケーションの場合、冗長性方式として SRST を使用すると、リモート サイトと中央サイトの間でネットワーク接続が失われたときに、基本的な呼処理サービスをこれらのリモート ロケーションに提供できます。 呼処理サービスが重要であり、Unified CM クラスタへの接続が失われた場合にも呼処理サービスを維持する必要がある各リモート サイトには、SRST 対応の Cisco IOS ルータを配置することを推奨します。これらのリモート ロケーションのエンドポイントは、Unified CM 内の適切な SRST リファレンスとともに設定する必要があります。Unified CM サブスクライバへの接続を使用できない場合に、呼処理サービス用にどのアドレスを使用して SRST ルータに接続するかをエンドポイントが認識するようにするためです。

Cisco IOS ルータ上の Unified CME をリモート サイトで使用して、中央の Unified CM クラスタへの接続が失われたときに SRST 拡張機能を提供することもできます。Unified CME は、ルータの通常の SRST で使用できる機能よりも多くのバックアップ呼処理機能を IP Phone に提供します。ただし、Unified CME as SRST のエンドポイント キャパシティは、通常は基本的な SRST よりも低下します。

呼処理サブスクライバの冗長性

選択した冗長性方式に応じて(「呼処理の冗長性」を参照)、呼処理サブスクライバは、プライマリ(アクティブ)サブスクライバまたはバックアップ(スタンバイ)サブスクライバのどちらかになります。ロード バランシングを実装する場合は、サブスクライバがプライマリ サブスクライバとバックアップ サブスクライバの両方を兼ねることもあります。クラスタの設計を計画するときは、通常は呼処理サブスクライバにこの機能を割り当てます。大規模なクラスタや高性能クラスタでは、呼処理サービスをパブリッシャおよび TFTP サブスクライバ ノード上で使用可能にしないでください。1:1 冗長性方式は、プライマリ サブスクライバとバックアップ サブスクライバの専用ペアを使用します。2:1 冗長性方式は、1 つのバックアップ サブスクライバを共用するプライマリ サブスクライバのペアを使用します。

次の図では、Unified CM で呼処理の冗長性を実現するための一般的なクラスタ構成を示しています。

図 8-5 基本的な冗長性方式

 

図 8-5 では、利用できる 2 つの基本的な冗長性方式を示しています。どちらの場合でも、バックアップ サーバは、障害の発生するプライマリ呼処理サーバ 1 台分以上の処理能力を備えている必要があります。2:1 冗長性方式の場合、バックアップ サーバは、個々の配置の要件に応じて、障害の発生する呼処理サーバ 1 台分、または両方のプライマリ呼処理サーバに相当する処理能力を備えている必要があります。サーバのキャパシティの選定およびハードウェア プラットフォームの選択については、「呼処理のキャパシティ プランニング」の項を参照してください。


) Cisco MCS 7845-I3 または同等の Open Virtualization Archive(OVA)10K サーバでは 2:1 冗長性方式はサポートされません。7,500 台以上の IP Phone が 2 つのプライマリ サブスクライバに登録される場合は、1:1 冗長性を使用する必要があります。これは、1 つのバックアップ サブスクライバで 7,500 台以上のバックアップ登録はできないからです。


図 8-6 1:1 冗長構成のオプション

 

図 8-7 2:1 冗長構成のオプション

 

図 8-6 に示した 5 つは、すべて 1:1 冗長性のオプションを示しています。図 8-7 に示した 5 つは、すべて 2:1 冗長性のオプションを示しています。どちらの場合も、オプション 1 は 1,250 人未満のユーザをサポートするクラスタに使用します。オプション 2 ~ 5 は、それぞれの冗長性方式でクラスタを徐々に拡張した様子を示しています。正確な規模は、選択したハードウェア プラットフォームや必要なハードウェア プラットフォームによって異なります。

これらの図では、パブリッシャと呼処理サブスクライバだけを示していることに注意してください。TFTP やメディア リソースなどの他のサブスクライバ ノードは示していません。


) Unified CM グループあたり最大 3 つの呼処理サブスクライバを定義できます。追加のバックアップ用に 3 次サブスクライバを追加すると、上記の冗長性方式は 2:1:1 または 1:1:1 冗長性に拡張されます。ただし、WAN を介したクラスタリングの展開(「リモート フェールオーバー配置モデル」を参照)で 3 次サブスクライバ サーバを使用する場合を除き、リモート サイトに設置するエンドポイント デバイスには 3 次サブスクライバの冗長性は推奨しません。エンドポイントが 3 次サブスクライバへの接続性をチェックする必要があると、SRST へのフェールオーバーがさらに遅延するためです。


図 8-6 または図 8-7 では示していませんが、MCS 7825 以上のサーバを備えたシングル サーバ クラスタを配置することもできます。MCS 7825 または同等のサーバでは、シングル サーバ クラスタのエンドポイント設定および登録の制限は 500 です。これより可用性の高いサーバを使用する場合も、シングル サーバ クラスタのエンドポイント設定および登録が 1,000 を超えないようにする必要があります。シングル サーバ構成では、バックアップ呼処理サブスクライバがないため、クラスタの冗長性メカニズムはありません。このようなタイプの配置では、冗長性メカニズムとして Survivable Remote Site Telephony(SRST)を使用して、Unified CM が使用できない際に最低限の呼処理サービスを提供する必要があります。ただし、シスコでは、実稼働環境でシングル サーバ配置を採用することは推奨しません。

ロード バランシング

1:1 冗長性方式の Unified CM クラスタでは、プライマリ呼処理サブスクライバとバックアップ呼処理サブスクライバ間で、デバイス登録および呼処理サービスのロード バランシングを行うことができます。

通常、プライマリが使用可能な場合、バックアップ サーバに登録されたデバイスはありません。このことにより、所定の時間に呼処理の負荷を処理するプライマリ呼処理サブスクライバ ノードは最大で 4 つであるため、配置のトラブルシューティングは容易になります。 さらに、Unified CM の冗長性グループとデバイス プールの数を減らすことにより、構成が簡素化される可能性もあります。

ロードバランスされた配置では、Unified CM の冗長性グループとデバイス プールの設定値を使用して、デバイス登録と呼処理にかかる負荷の半分までをプライマリ サブスクライバからセカンダリ サブスクライバに移すことができます。この方法で、各プライマリおよびバックアップ呼処理サブスクライバ ペアは、この呼処理サブスクライバ ペアによってサービスを提供される全デバイスの半数に、デバイス登録および呼処理サービスを提供します。これは、50/50 ロード バランシングと呼ばれます。50/50 ロード バランシング モデルには、次の利点があります。

ロード シェアリング:登録呼処理の負荷が複数のサーバ上に分散され、応答時間をより速くできます。

フェールオーバーとフェールバックが高速:すべてのデバイス(IP Phone、CTI ポート、ゲートウェイ、トランク、ボイスメール ポートなど)がすべてのアクティブ サブスクライバにわたって分散されるため、プライマリ サブスクライバに障害が発生した場合に、セカンダリ サブスクライバにフェールオーバーするデバイスは一部だけです。この方法で、サーバが使用不能になる影響を 50% 減らすことができます。

50/50 ロード バランシングを計画するには、ロード バランシングを使用しない場合のクラスタのキャパシティを計算し、次に、デバイスおよびコールの量に基づいて、負荷をプライマリ サブスクライバとバックアップ サブスクライバに分散します。プライマリ サーバやバックアップ サーバの障害に対処できるようにするには、プライマリとバックアップのサブスクライバの合計負荷が、サブスクライバ サーバ 1 台分の負荷を超えないようにします。


) 50/50 ロード バランシングが設定された Unified CM クラスタのアップグレード中、バックアップ呼処理サブスクライバのアップグレードによって、そのサーバに登録されているデバイス(プライマリ サブスクライバとバックアップ サブスクライバのペアによってサービスを提供される全デバイスの半数まで)は、プライマリ呼処理サブスクライバにフェールオーバーします。


TFTP の冗長性

大規模な Unified CM クラスタには複数の専用 TFTP サブスクライバ ノードを配置して、TFTP サービスの冗長性を提供することを推奨します。通常は 2 つの TFTP サブスクライバで十分ですが、クラスタ内に 3 台以上の TFTP サーバを配置できます。ただし、そのような構成ではすべての TFTP サブスクライバ上ですべての TFTP ファイルを再構築するために時間がかかります。

1 つ以上の冗長 TFTP サブスクライバを提供する以外に、これらの冗長 TFTP ノードを利用するためのエンドポイントを設定する必要があります。DHCP を使用するかまたは静的に TFTP オプションを設定する場合、クラスタ内の両方の TFTP サブスクライバ ノードの IP アドレスを含む TFTP サブスクライバ ノード IP アドレス アレイを定義します。この方法では、2 つの異なる IP アドレス アレイで 2 つの DHCP スコープを作成することによって(または、2 つの異なる TFTP サブスクライバ ノード IP アドレスでエンドポイントを手動で設定することによって)、TFTP サブスクライバ A をプライマリ、TFTP サブスクライバ B をバックアップとして使用する半分のエンドポイント デバイスと、TFTP サブスクライバ B をプライマリ、TFTP サブスクライバ A をバックアップとして使用するもう半分のエンドポイント デバイスを割り当てることができます。1 つの TFTP サブスクライバの障害時の冗長性を提供する以外に、複数の TFTP サブスクライバにわたってエンドポイントを分散させるこの方法はロード バランシングをもたらし、1 つの TFTP サブスクライバですべての TFTP サービス負荷を処理しないようにします。


) 電話やゲートウェイの個々のバイナリまたはファームウェア ロードを追加する場合は、ファイルをクラスタ内の各 TFTP サブスクライバ ノードに追加する必要があります。


CTI Manager の冗長性

すべての CTI 統合アプリケーションは、CTI Manager サービスを実行している呼処理サブスクライバ ノードと通信します。さらに、ほとんどの CTI アプリケーションには、冗長 CTI Manager サービス ノードを指定する機能があります。そのため、クラスタ内の少なくとも 2 つの呼処理サブスクライバで CTI Manager サービスをアクティブにすることを推奨します。プライマリとバックアップ両方の CTI Manager が設定されている場合、障害が発生すると、アプリケーションはバックアップ CTI Manager に切り替えて CTI サービスを受けます。

すでに説明したように、CTI Manager サービスは呼処理サブスクライバ上だけで使用可能にできます。したがって、クラスタごとに最大で 8 つの CTI Manager があります。復元性、パフォーマンス、および冗長性を最大限まで高めるには、CTI アプリケーションの負荷をクラスタ内で使用可能な CTI Manager に分散することを推奨します。

一般に、CTI アプリケーションによって制御またはモニタされるデバイスは、CTI Manager サービスに使用するものと同じサーバ ペアに関連付けることを推奨します。たとえば、音声自動応答装置(IVR)アプリケーションでは 4 つの CTI ポートが必要になります。1:1 冗長性と 50/50 ロード バランシングを使用する場合は、これらを次のように設定します。

2 つの CTI ポートは、サーバ A をプライマリ呼処理サブスクライバ、サーバ B をバックアップ サブスクライバとする Unified CM 冗長性グループを持つようにします。残りの 2 つの CTI ポートは、サーバ B をプライマリ サブスクライバ、サーバ A をバックアップ サブスクライバとする Unified CM 冗長性グループを持つようにします。

IVR アプリケーションは、サブスクライバ A 上の CTI Manager をプライマリ、サブスクライバ B をバックアップとして使用するように設定します。

上の例は、サブスクライバ A 上の CTI Manager で障害が発生した場合の冗長性を備えており、IVR コールの負荷を 2 台のサーバに分散することもできています。この方法では、Unified CM サブスクライバ ノードの障害による影響も最小限に抑えることができます。

CTI および CTI Manager の詳細については、「コンピュータ テレフォニー インテグレーション(CTI)」を参照してください。

UCS 呼処理の冗長性

Cisco UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバへの Unified CM の配置の場合も、これまでの呼処理、TFTP、および CTI Manager の冗長性方式がすべて適用されます。C シリーズ ラックマウント サーバは MCS サーバと同じ冗長性方式で配置されますが、UCS B シリーズ ブレード サーバには、サーバ ノードの仮想性により、冗長性に関するその他の考慮事項があります。それは、複数のサーバ ブレードにわたる Unified CM サーバ ノード インスタンスのインストールと常駐です。

図 8-8 に示すように、UCS B シリーズ ブレード サーバに Unified CM を配置して最大レベルの呼処理の冗長性を確保する場合は、次のガイドラインに従ってください。

各プライマリ呼処理サブスクライバ ノード インスタンスは、バックアップ呼処理サブスクライバ ノード インスタンスとは異なる物理 UCS B シリーズ ブレード上に存在する必要があります。このことにより、プライマリ呼処理ノード インスタンスを含むブレードで障害が発生しても、バックアップ呼処理サブスクライバ ノードへのアクセスをエンドポイントに提供するシステムの機能には影響しません。

サービスの冗長性のために複数の TFTP またはメディア リソース サブスクライバ ノード インスタンスを配置する場合は、冗長サブスクライバ ノードを常に複数の UCS ブレードに分散させて、1 つのブレードの障害によってそれらのサービスが排除されないようにします。 このことにより、TFTP またはメディア リソース サブスクライバを含むブレードで障害が発生しても、エンドポイントは別のブレード上に存在するサブスクライバ ノードで TFTP およびメディア リソース サービスにアクセスできます。障害のないシナリオでは、エンドポイントも冗長 TFTP およびメディア リソース サブスクライバ ノード インスタンス間で分散させて、システムをロードバランスできます。

CTI アプリケーションを配置する場合は、CTI Manager サービスを実行する呼処理サブスクライバ ノード インスタンスを常に複数の UCS ブレードに分散させて、1 つのブレードの障害によって CTI サービスが排除されないようにします。さらに、CTI アプリケーションは、1 つのブレード上のサブスクライバ ノード インスタンスで実行されている CTI Manager サービスをプライマリ CTI Manager として使用し、別のブレード上のサブスクライバ ノードで実行されている CTI Manager サービスをバックアップ CTI Manager として使用するように設定する必要があります。

図 8-8 UCS での Unified CM サーバ ノードの分散

 

サーバ ノード インスタンスを複数のブレードに分散させる以外に、サブスクライバ ノード インスタンスを複数の Cisco UCS 5100 ブレード シャーシに分散させて、冗長性と拡張性を追加できます。

仮想マシンのホスト リソースの冗長性とプロビジョニングの詳細については、 http://www.cisco.com/go/uc-virtualized にあるドキュメントを参照してください。

Cisco Business Edition のハイ アベイラビリティ

Cisco Business Edition のハイ アベイラビリティに関する主な考慮事項は、ネットワーク接続、電源、および呼処理と登録の冗長性です。

表 8-2 に示すように、Business Edition 3000 に使用される MCS 7816 プラットフォームも、Business Edition 5000 に使用される MCS 7828 プラットフォームも、冗長なネットワーク接続のために 2 つの IP インターフェイスまたは NIC を搭載しています。ただし、Business Edition 5000 のみが、ネットワーク接続の冗長性に対応する NIC チーミングをサポートしています。MCS 7816 サーバにインストールされた Business Edition 3000 は、NIC チーミングをサポートしていません。Business Edition 3000 用の MCS 7980-C1 専用アプライアンスの IP インターフェイスは 1 つだけのため、冗長なネットワーク接続または NIC チーミングのサポートは提供していません。

Business Edition 3000 および Business Edition 5000 はそれぞれ、それ自体の単一のスタンドアロン プラットフォーム(セカンダリ サブスクライバ インスタンスを設定できない、パブリッシャとシングル サブスクライバの複合インスタンス)に配置します。これらはノード クラスタリングをサポートしていないため、Unified CM で使用可能な呼処理の冗長性方式を利用できません。したがって、これらの配置タイプのエンドポイントで、呼処理および登録の冗長性を提供する唯一の方法は、SRST または Unified CME as SRST を使用することです。ただし、Business Edition 5000 のみが SRST をサポートしています。Business Edition 3000 では、可用性の高い呼処理および登録を提供できません。

一方、Business Edition 6000 は、追加の Cisco Unified CM ノードのクラスタ化によって、呼処理サービスおよび登録サービスに冗長性を提供します。2 つ目の Business Edition 6000 サーバ(UCS C200 または C220 ラックマウント サーバまたは MCS サーバ)は、呼処理とその他のアプリケーションおよびサービスにハイ アベイラビリティを提供するために配置できます。


) WAN を介したクラスタリングの展開と同様に、追加の冗長性と地理的な分散、あるいはそのいずれかを提供するために、Business Edition 6000 の配置では 2 台を超える UCS C200 または C220 ラックマウント サーバをクラスタリングできます。ただし、クラスタ全体でユーザの合計数が 1,000 を超えることはできず、クラスタ全体で設定されたデバイスの合計数が 1,200 を超えることはできません。ユーザ数が 1,000、設定済みデバイス数が 1,200 を超えるクラスタでの UCS C200 または C220 ラックマウント サーバの配置は、通常の Unified CM クラスタと見なされます。このため、配置は、通常の Unified CM クラスタのハイ アベイラビリティ設計ガイダンスに従う必要があります。(「Unified CM のハイ アベイラビリティ」を参照)。


呼処理のキャパシティ プランニング

呼処理のキャパシティ プランニングは、ユニファイド コミュニケーションの配置を成功させるために重要です。呼処理サービスによって多くの機能が提供され、呼処理エンティティによって多くのタイプのデバイスに登録およびトランザクション サービスを提供できるため、特定の配置のキャパシティ要件を満たすように呼処理インフラストラクチャとその個別のコンポーネントをサイジングすることが重要です。

IP Phone、ソフトウェア クライアント、ボイスメール ポート、CTI(TAPI または JTAPI)デバイス、ゲートウェイ、およびメディア サービスの DSP リソース(トランスコーディングや会議)は、すべて呼処理エンティティに登録されます。これらのデバイスには、登録先の呼処理プラットフォームのリソースが必要です。必要なリソースには、メモリ、プロセッサ使用、およびディスク I/O が含まれます。

呼処理プラットフォームに登録の負荷を追加する以外に、登録後、各デバイスはトランザクション(通常はコールの形態)中に追加のプラットフォーム リソースを消費します。たとえば、1 時間あたり 6 回のコールだけを行うデバイスが消費するリソースは、1 時間あたり 12 回のコールを行うデバイスより少なくなります。

呼処理サイジングの詳細や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

Unified CME のキャパシティ プランニング

Unified CME を配置する場合、必要となるサポート対象エンドポイント数という観点で、目的に合ったキャパシティを提供する Cisco IOS ルータ プラットフォームを選択することが重要です。また、Unified CME ルータが、呼処理以外のサービス(IP ルーティング、DNS ルックアップ、Dynamic Host Configuration Protocol(DHCP)アドレス サービス、VXML スクリプトなど)を提供する場合は、プラットフォームのメモリ キャパシティも考慮する必要があります。

Unified CME は、単一の Cisco IOS プラットフォーム上で最大 450 エンドポイントをサポートできます。ただし、各ルータ プラットフォームのエンドポイントのキャパシティは、システムのサイズによって異なります。Unified CME は Cisco Unified Communications Sizing Tool ではサポートされないため、次の Web サイトで入手可能な製品データ シートに記載されているキャパシティ情報に従う必要があります。

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_data_sheets_list.html

Unified CM のキャパシティ プランニング

ここでは、Unified CM のキャパシティ プランニングについて説明します。この項で示す推奨事項は、Unified Communications Sizing Tool を、デフォルトのトレース レベルとコール詳細レコード(CDR)を有効にして使用し、その結果として得た計算に基づいています。呼処理に直接関係しない他の機能を使用不可にしたり、縮小したり、再設定したりすると、より高いレベルのパフォーマンスとキャパシティが得られる場合があります。こうした機能の利用を可能にしたり増やしたりすると、システムの呼処理機能に影響を与える可能性があり、全体的なキャパシティを低下させる場合もあります。これらの機能には、トレース、コール詳細レコード、複雑なダイヤル プラン、および Unified CM プラットフォーム上に共存するその他のサービスが含まれます。 複雑なダイヤル プランには、複数のライン アピアランス、多くのパーティション、コーリング サーチ スペース、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、自動転送、共存サービス、およびその他の共存アプリケーションが含まれています。こうした機能はすべて、Unified CM システム内の追加リソースを消費します。

次の手法を使用して、システム パフォーマンスを向上させることができます。

特定プラットフォーム用にサポートされている最大量まで、サーバに追加の保証メモリを取り付ける。MCS 7825 および MCS 7835、または同等のサーバ クラスの大規模構成では、これらのサーバの RAM を倍に増やすことを推奨します。このメモリ アップグレードが必要かどうかは、Cisco Real Time Monitoring Tool(RTMT)を使用して検証することでわかります。サーバが物理メモリを最大量近くまで使用すると、オペレーティング システムは、ディスクへのスワップを開始します。このスワッピングが発生した場合は、追加の物理メモリを取り付ける必要があることを示しています。

多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大きなダイヤル プランを持つ Unified CM クラスタでは、Cisco CallManager サービスの初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、システム初期化タイマー(Unified CM サービス パラメータ)を変更して、設定を初期化するための時間を追加できます。システム初期化時間の詳細については、Unified CM Administration オンライン ヘルプのサービス パラメータに関する説明を参照してください。

UCS プラットフォームでの Unified CM のキャパシティ プランニング

仮想配置では、Unified CM などの Unified Communications のアプリケーションの大部分は、仮想マシンの仮想ハードウェアの設定を指定する定義済みテンプレートを使用してインストールする必要があります。これらのテンプレートは、仮想マシン テンプレートをパッケージおよび配布するオープン スタンダード ベースの方式である Open Virtualization Archive(OVA)を使用して配布されます。

これらの OVA テンプレートは、仮想 CPU の数、仮想メモリ量、ハード ドライブの数とサイズなどを定義して、アプリケーションのキャパシティを決定します。Unified CM の場合、複数の OVA テンプレートがあり、ほとんどすべてのサーバ クラスに対して、それぞれ 1 つずつ用意されています(ただし MCS 7815 または MCS 7816 に対応するテンプレートはありません)。対応する OVA テンプレートを使用した場合、VMware または Cisco UCS サーバで実行される Unified CM 仮想マシン インスタンスのキャパシティは、Cisco MCS サーバで直接実行される Unified CM ノードのキャパシティと同じになります。たとえば、7,500 のユーザまたはデバイス(または両方)をサポートする Unified CM 用の OVA テンプレートのキャパシティは、MCS 7845-H2/I2 サーバのキャパシティと同じです。

Unified CM のキャパシティ プランニング ガイドラインおよびエンドポイントの制限

Cisco Unified CM には、次のキャパシティ ガイドラインが適用されます。

クラスタ内では、Cisco CallManager サービスを使用して最大 8 つの呼処理サブスクライバ ノードを使用可能にできます。それ以外のサーバは、パブリッシャ、TFTP サブスクライバ、メディア リソース サブスクライバなどの専用機能に使用できます。

クラスタごとに、次の値を最大値とする設定および登録をサポートできます。

Unified CM 8.6(1) 以降のリリースでは、40,000 のセキュアまたは非セキュア SCCP または SIP エンドポイント

Unified CM 8.5 以前のリリースでは、30,000 のセキュアまたは非セキュア SCCP または SIP エンドポイント

VMware で実行されるサーバ ノード インスタンスで構成されているクラスタは、選択された OVA テンプレートに応じて、さまざまなキャパシティをサポートできます。ほとんどの Cisco MCS サーバ クラスには、MCS サーバ クラスと同じキャパシティ(電話機、ゲートウェイ、ロケーション、リージョン、CTI 接続などの数)を持つ Unified CM インスタンスを提供する、対応した OVA テンプレートが用意されています。同一のブレードまたはサーバで複数の仮想マシン インスタンスを実行できるため、ブレードまたはサーバの合計キャパシティは MCS サーバよりも大きくなる場合があります。

Unified CM の推奨される最大トレース設定は、System Diagnostic Interface(SDI)および Signaling Distribution Layer(SDL)の両方のトレースに対して 2 MB のファイルを 2,000 本、合計でファイル 4,000 本です。プロセスごとにファイルの最大数が設定され、各プロセスに許容されるファイル数は SDL に対して 2,000 本、SDI に対して 2,000 本となります。その他すべてのコンポーネントのトレース設定は、126 MB の限度内(たとえば、それぞれ 2 MB のファイルが 63 本)で設定する必要があります。これらの値が上限として推奨されます。コール レートの高い環境での特定のトラブルシューティングでファイルの最大数を増やす必要がある場合を除き、ほとんどの環境ではデフォルト設定で十分なトレースを収集できます。

サイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、Unified CM キャパシティ プランニングの考慮事項の詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

メガクラスタ

メガクラスタ という用語は、拡張性をさらに増大させることが可能な特定の Unified CM 配置を定義および識別します。メガクラスタでは、追加の Unified CM サブスクライバ ノードのサポートにより、さらに多くのデバイス キャパシティが提供されます。メガクラスタごとに最大 8 つの Unified CM サブスクライバ ペア(1:1 冗長性)を設定でき、これにより Cisco Unified CM 8.6 以降のリリースでは最大で 80,000 台のデバイスを使用できます。

メガクラスタは、Survivable Remote Site Telephony(SRST)を使用するのではなくメガクラスタごとの標準のクラスタ配置および最大 16 の Unified CM サブスクライバ ノードで許可される最大 8 サイトを超えてスケーリングするためにお客様が非ローカルで冗長な呼処理機能だけを必要とする場合にも配置できます。たとえば、12 のロケーションがある大きな病院で、各ロケーションに 1,000 個のデバイスしかないとします。この合計 12,000 個のデバイスは、標準クラスタ内で提供でき、標準クラスタの最大デバイス キャパシティは 40,000 デバイスです。ただし、この場合、メガクラスタの配置を必要とする追加のデバイス キャパシティではなく、追加の Unified CM サブスクライバが必要です。この例では、Unified CM サブスクライバ ノードは、各ロケーションに配置され、各 Unified CM サブスクライバは、ローカル エンドポイントのプライマリ サブスクライバとして、また、別の場所でエンドポイントのバックアップ サブスクライバとして動作できます。

メガクラスタ配置を検討する場合、キャパシティに影響を与える主な領域は次のとおりです。

メガクラスタには、16 台のサブスクライバ、2 台の TFTP サーバ、2 台の保留音(MoH)サーバ、および 1 台のパブリッシャで構成される合計 21 台のサーバが含まれることがあります。

サーバ タイプは、Cisco MCS 7845-I3/H3 クラス、または 10K Open Virtualization Archive(OVA)テンプレートを使用した Cisco Unified Computing System(UCS)C シリーズまたは B シリーズのいずれかである必要があります。

冗長性モデルは 1:1 である必要があります。

標準クラスタに関連する他のすべてのキャパシティがメガクラスタにも適用されます。メガクラスタ配置のサポートは、Cisco Unified Communications Sizing Tool の結果の送信など、詳細設計の確認が成功した後でのみ与えられることに注意してください。Cisco Unified Communications Sizing Tool および Unified CM 標準クラスタとメガクラスタのサイジングの詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

メガクラスタ配置の周りに存在する多数の潜在的な複雑さが原因で、このような配置の実現を望むお客様は、シスコのアカウント チームまたは認定された Cisco Unified Communications パートナーに関与してもらうことが必要になります。


) 特に明記されていない限り、この SRND 内に含まれる呼処理配置に関連するすべての情報(キャパシティ、ハイ アベイラビリティ、一般的な設計上の考慮事項など)は、標準クラスタにのみ適用されます。


Cisco Business Edition のキャパシティ プランニング

Unified CM と同様に、多くのタイプのデバイスを Cisco Business Edition に登録でき、これらの各デバイスには登録先のプラットフォームからの登録とトランザクション リソースが必要です。また、ユーザおよびユーザの最繁時呼数(BHCA)は、システム リソースをさらに消費します。それぞれの Cisco Business Edition システムには、プラットフォームの利用可能システム リソースに基づく、固有のユーザ、エンドポイント、および BHCA キャパシティのしきい値があります。Cisco Business Edition によってサポートされるユーザおよびエンドポイントの最大数は、それぞれ 1,000 と 1,200 です。Cisco Business Edition でサポートされる BHCA の最大数は 5,000 です。

サイジングの例およびプラットフォームごとのサイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、Cisco Business Edition キャパシティ プランニングの考慮事項の詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

Cisco Business Edition のキャパシティと、他のすべての Cisco Business Edition 製品情報の詳細については、次の製品マニュアルを参照してください。

Cisco Business Edition 3000

http://www.cisco.com/en/US/products/ps11370/tsd_products_support_series_home.html

Cisco Business Edition 5000

http://www.cisco.com/en/US/products/ps7273/tsd_products_support_series_home.html

Cisco Business Edition 6000

http://docwiki.cisco.com/wiki/Cisco_Unified_Communications_Manager_Business_Edition_6000

呼処理の設計上の考慮事項

シスコの呼処理を配置する際は、次の設計上の推奨事項およびガイドラインに従ってください。

Cisco Unified CME

Unified CME は、最大で 450 のエンドポイントをサポートします。ただし、Cisco IOS ルータ モデルによっては、エンドポイント キャパシティは大幅に低下する場合があります。Unified CME のプラットフォームおよびキャパシティの詳細については、次の Web サイトにある Cisco Unified Communications Manager Express の互換性情報を参照してください。 http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_device_support_tables_list.html

可能な場合は、複数の IP インターフェイスを使用して Unified CME ルータをネットワークに二重接続し、ネットワークの可用性を最大限まで高めます。 同様に、同じ配置で Unified CME の複数のインスタンスが必要な場合は、複数の物理スイッチまたはロケーションに分散します。

可能な場合は、二重化電源および無停電電源(UPS)を備えた Unified CME ルータを配置し、プラットフォームの可用性を最大限まで高めます。

Cisco Business Edition

Business Edition 3000 は、MCS 7816 または MCS 7890-C1(バージョン 8.6(1) 以降)で実行され、パブリッシャとシングル サブスクライバの複合インスタンスとして動作します。セカンダリ サブスクライバ インスタンスは設定できません。

Business Edition 5000 は、単一ハードウェア プラットフォーム(MCS 7828)上で、パブリッシャとシングル サブスクライバの複合インスタンスとして動作します。セカンダリ サブスクライバ インスタンスは設定できません。

Business Edition 6000 は、UCS C200 または C220 ラックマウント サーバ上で、パブリッシャとシングル サブスクライバの複合インスタンスとして動作します。セカンダリ サブスクライバによって呼処理の冗長性を提供するために、2 台目の UCS C200 または C220 サーバを配置できます。また、MCS サーバを冗長性を提供するために使用できます。


) さらなる冗長性と地理的な分散、あるいはそのいずれかを提供するために、Business Edition 6000 の配置では 2 台を超える UCS C200 または C220 ラックマウント サーバをクラスタリングできます。ただし、クラスタ全体でユーザの合計数が 1,000 を超えることはできず、クラスタ全体で設定されたデバイスの合計数が 1,200 を超えることはできません。


Business Edition 6000 は、最大で 1,200 のエンドポイントをサポートします。ただし、実際のエンドポイント キャパシティは総システム BHCA によって異なりますが、最大で 5,000 を超えることはできません。サイジングの例やプラットフォームごとのサイジングの制限など、Cisco Business Edition のキャパシティの詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

NIC チーミングを使用して Business Edition 5000 の MCS 7828 サーバをネットワークに二重接続し、ハイ アベイラビリティを最大限まで高めます。Business Edition 3000 は NIC チーミングをサポートしていません。

同じ配置で Business Edition 5000 または Business Edition 6000 の複数のインスタンスが必要な場合は、複数の物理スイッチに分散します。

Cisco Business Edition プラットフォームの一部(MCS 7816、MCS 7828、MCS 7890-C1、および UCS C200)は、二重化電源を備えていない、あるいはサポートしていないため、無停電電源(UPS)を使用してプラットフォームの可用性を最大限まで高めます。

ハイ アベイラビリティのために 2 台のサーバで Business Edition 6000 を配置する場合(2 台の UCS C200/C220 ラックマウント サーバ、または 1 台の UCS C200/C220 ラックマウント サーバと 1 台の MCS サーバ)、システム負荷を分散するために、2 台のサーバ間でデバイス登録のロード バランシングを行う必要があります。スタンバイ冗長性のために 2 台めのサーバを使用することを推奨します。

Business Edition 3000 は、次に示すエンドポイントおよびゲートウェイの特定のタイプのみのサポートを提供します。

Business Edition 3000 がサポートするエンドポイントのセットには、制限があります。サポートされているエンドポイントのリストについては、次の Web サイトから入手可能な『 Administration Guide for Cisco Business Edition 3000 』を参照してください。

http://www.cisco.com/en/US/products/ps11370/prod_maintenance_guides_list.html

Business Edition 3000 PSTN 接続は、Cisco 2901 Integrated Services Router(ISR)を通じてのみ、また MGCP バックホール T1/E1 PRI トランクを使用する場合のみサポートされています。

Business Edition 3000 はクラスタ間トランキングをサポートしていないため、分散型呼処理配置もサポートしていません。

Cisco Unified CM

Cisco Unified CM クラスタ内で最大 8 つの呼処理サブスクライバ ノード(Cisco CallManager サービスを実行するノード)を使用可能にできます。その他のサーバは、パブリッシャ、TFTP、およびメディア リソース サービス専用で使用できます。承認されたメガクラスタ配置は、最大で 16 個の呼処理サブスクライバ ノードをサポートします。

各 Unified CM クラスタは、最大で 40,000 個のセキュアまたは非セキュア エンドポイント(Unified CM 8.6(1) 以降のリリースを使用)の設定および登録をサポートできます。Unified CM 8.5 以前のリリースの場合、最大で 30,000 個のセキュアまたは非セキュア エンドポイントがサポートされます。プラットフォームごとのサイジングの制限など、Unified CM のキャパシティ プランニングの詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

キャパシティの大きいサーバを使用して 2 サーバ クラスタを配置する場合も、クラスタ内のユーザ数が 1,250 を超えないようにすることを推奨します。1,250 ユーザを超える場合は、専用パブリッシャと別個のサーバをプライマリおよびバックアップの呼処理サブスクライバ用に推奨します。

クラスタ内のすべてのサーバに対して同じサーバ モデルを使用することを推奨します。ただし、個別のハードウェア バージョンがすべてサポートされており、すべてのサーバで同じバージョンの Unified CM が実行されている場合、クラスタ内にサーバ モデルおよび異なるサーバ ベンダーのモデルを混在させることもサポートされます。

Cisco MCS 7845-I3 または同等の Open Virtualization Archive(OVA)10K サーバでは 2:1 冗長性方式はサポートされません。7,500 台を超える IP Phone が 2 つのプライマリ サブスクライバに登録される場合は、1:1 呼処理冗長性方式を使用する必要があります。これは、1 つのバックアップ サブスクライバで 7,500 台を超えるバックアップ登録はできないからです。

NIC チーミングを使用して MCS サーバをネットワークに二重接続し、ハイ アベイラビリティを最大限まで高めます。 MCS 7815 のネットワーク インターフェイス ポートは 1 つだけのため、NIC チーミングを実行できません。

可能な場合は常に、Unified CM サーバをネットワーク内の複数の物理スイッチおよび同じネットワーク内の複数の物理ロケーションに分散させて、スイッチの障害または特定のネットワーク ロケーションの損失による影響を最小限に抑えます。

SRST または Unified CME as SRST をリモート ロケーションの Cisco IOS ルータに配置して、これらのロケーションで Unified CM クラスタへの接続が失われた場合にフォールバック呼処理サービスを提供します。

Unified CM クラスタ内で音声アクティビティ検出(VAD)を使用不可にしておくことを推奨します。Cisco IOS H.323 および SIP ダイヤル ピアでも、 no vad コマンドを使用して VAD を使用不可にする必要があります。

Unified CM を Cisco UCS B シリーズ ブレード サーバに配置する場合は、バックアップまたは冗長サブスクライバ ノードがプライマリ サブスクライバ ノードとは異なる物理ブレード上に存在するように、サーバ ノード インスタンスが UCS シャーシ内のブレード サーバ間で分散されるようにします。

UCS B シリーズ ブレード サーバとハイエンド C シリーズ ラックマウント サーバの両方(たとえば、C210、C220 TRC#1、および C260)は、複数の Open Virtualization Archive(OVA)テンプレートで設定できます。最も大きい OVA テンプレートは、10,000 のデバイスをサポートし、MCS 7845-I3 サーバと同じキャパシティ(エンドポイント、ゲートウェイ、ロケーション、リージョンなどの数)を提供します。適切な OVA のサイジングと、Cisco Unified Communications Sizing Tool の使い方の詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバは、KVM ケーブルを介して USB およびシリアル ポートをサポートしますが、Unified CM VMware 仮想アプリケーションはこれらのポートにアクセスできません。そのため、Unified CM を UCS に配置する場合、MoH 用の固定ライブ オーディオ ソースを接続すること、レガシー ボイスメール システムへのシリアル SMDI 接続を行うこと、またはログ ファイルの書き込みのために USB フラッシュ ドライブを接続することはできません。代わりに、次のオプションを利用できます。

MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用するか、または Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB MoH オーディオ カード(MOH-USB-AUDIO=)を接続できるようにすることを検討します。

SMDI シリアル接続の場合は、Unified CM クラスタの一部として 1 台の MCS サーバに Unified CM サブスクライバ ノードを配置して、USB シリアル接続に使用します。

システムのインストール ログの保存には、仮想フロッピー ソフトメディアを使用します。

シスコは、一部のサブスクライバ サーバ ノード インスタンスを UCS B シリーズ ブレード サーバで実行し、別の一部を C シリーズ ラックマウント サーバで実行して、その他の残りのサブスクライバ サーバ ノード インスタンスを MCS サーバ プラットフォームで実行する Unified CM クラスタをサポートしています。

コンピュータ テレフォニー インテグレーション(CTI)

Cisco コンピュータ テレフォニー インテグレーション(CTI)を利用すると、Cisco Unified CM で使用可能な豊富なフィーチャ セットだけでなく、サードパーティ製のアプリケーションも使用できるようになります。これらの Cisco CTI 対応アプリケーションによって、ユーザの生産性が向上し、コミュニケーションが活発になるとともに、高品質のカスタマー サービスを提供できるようになります。Cisco CTI を使用すると、サードパーティ製デスクトップ アプリケーションで Microsoft Outlook 内から通話を行ったり、着信コールの発信者 ID に基づいてウィンドウを開いたり、アプリケーションを起動したりできます。また、課金のためにコールと連絡先をリモートで追跡することもできます。Cisco CTI 対応のサーバ アプリケーションでは、企業ネットワーク全体での適切な対応先のルーティングや、自動応答や音声自動応答装置(IVR)などの自動発信者サービスの提供に加えて、対応先の記録および分析に役立つメディアの取り込みも行えます。

CTI アプリケーションは一般に、次の 2 つの主なカテゴリに分類できます。

ファーストパーティ製のアプリケーション:モニタ、制御、メディア ターミネーション

ファーストパーティ製の CTI アプリケーションは、コールのセットアップ、終了、およびメディア ターミネーション用の CTI ポートおよびルート ポイントなどのデバイスを登録するように設計されています。これらのアプリケーションはメディア パスに直接配置されているので、インバンド DTMF などのメディア レイヤのイベントに応答できます。ファーストパーティ製の CTI アプリケーションには音声自動応答装置や Cisco Attendant Console などがあり、これらのアプリケーションはコールをモニタおよび制御しながら、コール メディアとも対話します。

サードパーティ製のアプリケーション:モニタおよび制御

サードパーティ製の CTI アプリケーションもコールをモニタおよび制御しますが、メディア ターミネーションは直接制御しません。

モニタリング アプリケーション

Cisco IP デバイスの状態をモニタする CTI アプリケーションは、モニタリング アプリケーションと呼ばれます。オンフックまたはオフフックのステータスを表示する、またはその情報を使用してユーザの可用性をプレゼンスの形式で示すビジーランプフィールド アプリケーションは、どちらもサードパーティ製の CTI モニタリング アプリケーションの例です。

呼制御アプリケーション

Cisco CTI を使用して、アウトオブバンド シグナリングを使用する Cisco IP デバイスをリモート制御するアプリケーションは、呼制御アプリケーションです。Cisco Jabber は、Cisco IP デバイスをリモート制御するように設定された場合に、呼制御アプリケーションのよい例です。

モニタリング + 呼制御アプリケーション

これらは、Cisco IP デバイスをモニタおよび制御するすべての CTI アプリケーションです。Cisco Unified Contact Center Enterprise は、エージェントのステータスをモニタして、エージェント デスクトップを介してエージェント電話機を制御するため、モニタと制御を兼ね備えたアプリケーションのよい例です。


) ここでモニタリング アプリケーション、呼制御アプリケーション、モニタリング + 呼制御アプリケーションの違いを列挙しましたが、この細かな違いはアプリケーション開発者には見えないようになっています。Cisco CTI を使用するすべての CTI アプリケーションは、モニタリングおよび制御の両方に有効です。


次のデバイスは CTI 経由でモニタまたは制御できます。

CTI Route Point

CTI ポート

CTI をサポートする Cisco Unified IP Phone

CTI リモート デバイス

CTI のリモート デバイスは Cisco Unified CM 9.0 で導入された新しい電話タイプです。これは、従来の PSTN 電話機、携帯電話、サードパーティ電話、またはサードパーティ PBX に接続されている電話機などの、CTI をサポートしない電話機上のモニタリング機能および制限された呼制御機能を CTI アプリケーションが持つ能力を提供します。

CTI のアーキテクチャ

Cisco CTI は、次のコンポーネントで構成されます(図 8-9 を参照)。これらは互いに対話し、Cisco Unified CM で使用可能なテレフォニーフィーチャ セットを各アプリケーションで利用できるようにします。

CTI 対応アプリケーション:特定のテレフォニー機能を提供するために作成されたシスコ製またはサードパーティ製のアプリケーション。

JTAPI および TAPI:Cisco CTI でサポートされる 2 つの標準インターフェイス。開発者は、好みの方式のライブラリを使用してアプリケーションを作成できます。

Unified JTAPI および Unified TSP クライアント:外部メッセージを Cisco Unified CM で使用される内部の Quick Buffer Encoding(QBE)メッセージに変換します。

Quick Buffer Encoding(QBE):Unified CM の内部通信メッセージ。

プロバイダー:アプリケーションと CTI Manager との接続の論理的な表現であり、通信を容易にするために使用されます。プロバイダーは、アプリケーションにデバイス イベントおよびコール イベントを送付しながら、アプリケーションによるデバイスのリモート制御を可能にする制御命令を受け付けます。

Signaling Distribution Layer(SDL):Unified CM の内部通信メッセージ。

パブリッシャおよびサブスクライバ:Cisco Unified Communications Manager(Unified CM)サーバ。

CCM:Cisco CallManager サービス(ccm.exe)。テレフォニー処理エンジンです。

CTI Manager(CTIM):プライマリまたはセカンダリ モードで動作する 1 つ以上の Unified CM サブスクライバで実行され、Cisco IP デバイスを制御およびモニタできるようにテレフォニー アプリケーションを認証および許可するサービス。

図 8-9 Cisco CTI のアーキテクチャ

 

アプリケーションを認証および許可すると、CTIM は、テレフォニー アプリケーションと Cisco CallManager サービスの仲介者として機能します (このサービスは呼制御エージェントです。全体の製品名である Cisco Unified Communications Manager と混同しないでください)。CTIM はテレフォニー アプリケーションから送信される要求に応答し、その要求を Unified CM システムで内部的に使用される Signaling Distribution Layer(SDL)メッセージに変換します。Cisco CallManager サービスからのメッセージも CTIM によって受信され、処理のために適切なテレフォニー アプリケーションに転送されます。

CTIM は、Cisco CallManager サービスがアクティブになっているクラスタの Unified CM サブスクライバ サーバでアクティブにできます。これによって、Unified CM クラスタ内で 8 つまでの CTIM をアクティブにできます。スタンドアロンの CTIM は現在サポートされていません。

WAN を介した CTI アプリケーションおよびクラスタリング

WAN を介したクラスタリングを採用した展開では、次の 2 つのシナリオがサポートされます。

WAN を介した CTI Manager(図 8-10 を参照)

このシナリオでは、CTI アプリケーションとそれに関連付けられた CTI Manager が WAN の一方の側(サイト 1)に配置され、Unified CM サブスクライバに登録されるモニタおよび制御対象のデバイスが他方の側(サイト 2)に配置されます。WAN を介したクラスタリングのラウンドトリップ時間(RTT)は、現在サポートされている限度値 80 ms を超えることはできません。CTI トラフィックに必要な帯域幅を計算するには、「ローカル フェールオーバー配置モデル」 にある公式を使用します。この帯域幅は、「ローカル フェールオーバー配置モデル」の説明に従って計算した Intra-Cluster Communication Signaling(ICCS)帯域幅や、音声に必要な帯域幅(RTP トラフィック)とは別に必要であることに注意してください。

図 8-10 WAN を介した CTI

 

WAN を介した TAPI および JTAPI アプリケーション(WAN を介した CTI アプリケーション)(図 8-11 を参照)

このシナリオでは、CTI アプリケーションが WAN の一方の側(サイト 1)に配置され、関連付けられた CTI Manager が他方の側(サイト 2)に配置されます。このシナリオでは、CTI アプリケーション開発者またはプロバイダーの責任において、アプリケーションが実装された RTT に適応できるかどうかを確認します。場合によっては、アプリケーションが CTI Manager と同じ場所にある場合よりも、フェールオーバー時間およびフェールバック時間が長くなることがあります。このような場合、アプリケーション開発者またはプロバイダーは、そのような状況におけるアプリケーションの動作に関するガイダンスを示す必要があります。

図 8-11 WAN を介した JTAPI

 


) WAN を介した TAPI および JTAPI のサポートは、アプリケーションに依存します。ユーザとアプリケーション開発者またはプロバイダーの両者が、使用するアプリケーションに WAN を介したクラスタリングが含まれる展開との互換性があることを確認する必要があります。


CTI のキャパシティ プランニング

サポートされている CTI 制御デバイスの最大数は、クラスタごとに 40,000 です。プラットフォームごとのノードおよびクラスタの CTI キャパシティや、CTI リソースの計算式および例など、CTI のキャパシティ プランニングの詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

CTI のハイ アベイラビリティ

ここでは、ハイ アベイラビリティのための CTI プロビジョニングについて、いくつかのガイドラインを提供します。

CTI Manager

CTI Manager は、Unified CM クラスタ内の少なくとも 1 つ(おそらくすべて)の呼処理サブスクライバで有効にする必要があります。クライアント側のインターフェイス(TAPI TSP または JTAPI クライアント)では IP アドレスを 2 つずつ使用できます。これらの IP アドレスは、CTIM サービスを実行している Unified CM サーバを指します。CTI アプリケーションの冗長性を確保するため、図 8-12 のとおり、クラスタの少なくとも 2 つの Unified CM サーバで、CTIM サービスをアクティブにすることを推奨します。

冗長性、フェールオーバー、およびロード バランシング

冗長性が必要な CTI アプリケーションでは、TAPI TSP または JTAPI クライアントは 2 つの IP アドレスで設定できるため、障害発生時には代替の CTI Manager を使用できます。ここで注意すべきは、2 つの CTI Manager 間で情報が共有されていないため、この冗長性はステートフルではありません。そのため、フェールオーバーの際に、再初期化が必要になることがあります。

CTI Manager がフェールオーバーした場合、必要な処理は、現在アクティブになっている CTI Manager で CTI アプリケーションのログイン プロセスをやり直すことだけです。ただし、Unified CM サーバ自体に障害が発生した場合は、障害が発生した Unified CM や現在アクティブになっている Unified CM などのすべてのデバイスを再登録し、その後で CTI アプリケーションのログイン プロセスを実行する必要があるため、再初期化プロセスは時間がかかります。

ロード バランシングが必要な CTI アプリケーションや、この設定を利用できる CTI アプリケーションは、図 8-12 に示すように、2 つの CTI Manager に同時に接続できます。

図 8-12 冗長性とロード バランシング

 

図 8-13 は、このタイプの Cisco Unified Contact Center Enterprise(Unified CCE)の設定例を示しています。このタイプの設定には、次の特性があります。

Unified CCE は冗長性のために 2 つの Peripheral Gateway(PG)を使用します。

各 PG は異なる CTI Manager にログインします。

一度に 1 つの PG しかアクティブになりません。

図 8-13 Cisco Unified Contact Center Enterprise での CTI の冗長性

 

図 8-14 は、このタイプの Cisco Unified Contact Center Express(Unified CCX)の設定例を示しています。このタイプの設定には、次の特性があります。

Unified CCX では、各 CTI Manager 用に 1 つずつ、合計で 2 つの IP アドレスを設定できます。

プライマリ CTI Manager への接続が失われた場合、Unified CCX はセカンダリ CTI Manager にフェールオーバーします。

図 8-14 Cisco Unified Contact Center Express での CTI の冗長性

 

実装

アプリケーションの作成に関するガイダンスとサポートについて、アプリケーション開発者は次の Web サイトの Cisco Developer Connection で相談してください。

http://developer.cisco.com/web/cdc/community

ゲートキーパーの設計上の考慮事項

1 台の Cisco IOS ゲートキーパーで、分散型呼処理環境で最大 100 の Unified CM クラスタに対してコール ルーティングとコール アドミッション制御をサポートできます。複数のゲートキーパーを設定すると、数千の Unified CM クラスタをサポートできます。Cisco IOS ゲートキーパーを使用して、H.323 ゲートウェイと Unified CM 間の通信とコール アドミッション制御をサポートすることによって、ハイブリッド Unified CM とトール バイパス ネットワークを実装することもできます。

ゲートキーパーのコール アドミッション制御は、ポリシーベースの方式であり、使用可能なリソースの静的設定を必要とします。ゲートキーパーは、ネットワーク トポロジを認識しないので、ハブアンドスポーク トポロジに制限されます。

ほとんどの Cisco IOS ルータは、ゲートキーパー機能をサポートします。ゲートキーパー機能の特定のプラットフォーム サポートについては、次の Web サイトで入手可能な『 Cisco IOS H323 Gatekeeper Data Sheet 』を参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps4139/data_sheet_c78_561921.html

冗長性、ロード バランシング、および階層コール ルーティング用に、さまざまな方法で Cisco IOS ゲートキーパーを設定できます。この項では、ゲートキーパー ネットワークを構築するための設計要件について検討します。ただし、コール アドミッション制御やダイヤル プラン解決については扱いません。これらについては、「コール アドミッション制御」「ダイヤル プラン」の章でそれぞれ説明しています。

ゲートキーパーの詳細については、次の Web サイトで入手可能な『 Cisco IOS H.323 Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10591/products_installation_and_configuration_guides_list.html

ハードウェア プラットフォームの選択

ゲートキーパーのプラットフォームは、1 秒間あたりのコール数、および同時発生コール数に基づいて選択します。1 秒間あたりのコール数が多いほど、高性能な CPU が必要になります。同時発生コールの数が大きいほど、より多くのメモリが必要になります。設計要件に大量のコールと大量の同時コールが含まれている場合には、大量のメモリ キャパシティがある Cisco IOS ルータとパフォーマンスの高い CPU を選択します。

ゲートキーパーのプラットフォームの詳細については、次の Web サイトで入手できる『 Cisco IOS H323 Gatekeeper Data Sheet 』を参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps4139/data_sheet_c78_561921.html

ゲートキーパーの冗長性

ゲートキーパーが、クラスタ間通信にすべてのコール ルーティングとアドミッション制御機能をサポートする場合は、冗長性が必要です。ゲートキーパーの冗長性をサポートするには、ゲートキーパー クラスタリングとディレクトリ ゲートキーパーという 2 つの方法があります。


) 可能な場合、ゲートキーパーの冗長性をサポートするには、ゲートキーパー クラスタリングを使用することを推奨します。ソフトウェア フィーチャ セットでゲートキーパー クラスタリングが利用できない場合以外は、ゲートキーパーの冗長性にホットスタンバイ ルータ プロトコル(HSRP)を使用しないでください。


ゲートキーパー クラスタリング(代替ゲートキーパー)

ゲートキーパー クラスタリング(代替ゲートキーパー)により、「ローカル」ゲートキーパー クラスタの設定が可能になります。各ゲートキーパーは、一部の Unified CM トランクのプライマリ、およびその他のトランクの代替として機能します。 Gatekeeper Update Protocol(GUP)は、ローカル クラスタ内のゲートキーパー間で状態情報を交換するために使用されます。GUP は、クラスタ内のゲートキーパーごとに CPU 使用率、メモリ使用率、アクティブ コール数、および登録されたエンドポイント数をトラッキングし、報告します。GUP メッセージングで次のパラメータにしきい値を設定すると、ロード バランシングがサポートされます。

CPU 使用率

メモリ使用率

アクティブ コール数

登録されたエンドポイント数

ゲートキーパー クラスタリング(代替ゲートキーパー)のサポートにより、ステートフル冗長性とロード バランシングが使用可能になります。ゲートキーパー クラスタリングは、次の機能を提供します。

ローカルとリモートのクラスタ

ローカル クラスタ内の最大 5 つのゲートキーパー

ローカル クラスタ内のゲートキーパーを、別々のサブネットまたはロケーションに配置可能

フェールオーバーの遅延なし(代替ゲートキーパーはすでにエンドポイントを認識しているので、完全な登録プロセスを実行する必要はありません)

クラスタ内のゲートキーパーは、状態情報を渡し、ロード バランシングを行う

図 8-15 では、Unified CM 分散型呼処理を行う 3 つのサイト、およびローカル クラスタで設定された 3 つの分散型ゲートキーパーを示しています。

図 8-15 ゲートキーパー クラスタリング

 

図 8-15 では、各サイトの Unified CM クラスタはローカル ゲートキーパーに登録されます。ローカル ゲートキーパー サービスは、各ローカル ゲートキーパーが別のサイトにあるゲートキーパーでバックアップされるように、ゲートキーパー クラスタリングを使用して冗長にします。

ゲートキーパー クラスタリングを配置する場合は、次のガイドラインを考慮してください。

Unified CM トランク登録をサポートするために、各 Unified CM クラスタにはローカル ゾーンが設定されます。このローカル ゾーンは、Unified CM 内と、Unified CM クラスタと一緒に配置されたゲートキーパーに設定されます。図 8-15 に示す例では、San Jose サイトにある Unified CM クラスタに、San Jose のゲートキーパー(Gatekeeper 1)に設定されたローカル ゾーン名と一致するゾーン名でゲートキーパー制御トランクが設定されます。同様に、Chicago および New York の Unified CM クラスタに、それぞれのロケーション(Chicago の場合は Gatekeeper 2、New York の場合は Gatekeeper 3)に配置されたゲートキーパーのローカル ゾーン名と一致するゾーン名が設定されます。

ローカル ゾーンごとにゲートキーパーが定義され、 element コマンドを使用して他のゲートキーパー上にバックアップ ゾーンが設定されます。図 8-15 に示す例では、San Jose のゲートキーパー(Gatekeeper 1)に、Chicago のゲートキーパー(Gatekeeper 2)と New York のゲートキーパー(Gatekeeper 3)の両方のエレメントでローカル ゾーンが設定されます。同様に、Chicago および New York のゲートキーパーに、San Jose のゲートキーパーと互い(それぞれ)の両方のエレメントでローカル ゾーンが設定されます。

gw-type-prefix コマンドを使用して、ローカルで解決されないすべてのコールをローカル ゾーン内で設定されたテクノロジー プレフィックスに登録されたデバイスに転送できます。図 8-15 に示す例では、各 Unified CM ゲートキーパー制御トランクは 1#* のテクノロジー プレフィックスで設定され、各サイトのゲートキーパーは 1#* の default-technology gw-type-prefix で設定されます。

クラスタリング ゲートキーパー間のロード バランシングは、 load-balance コマンドを使用して設定されます。図 8-15 に示す例では、各サイトのゲートキーパーを設定して、CPU 使用率、メモリ使用率、エンドポイント数、およびコール数のしきい値に基づいてロード バランスしたり、エンドポイント/ゲートウェイ登録をローカルのゲートキーパーからクラスタ内の代替ゲートキーパーへ移したりできます。たとえば San Jose のゲートキーパー(Gatekeeper 1)を、上限が 80% に設定された CPU およびメモリしきい値に基づいてエンドポイントまたはゲートウェイ登録が Chicago のゲートキーパーに移るように設定できます。この場合、San Jose のゲートキーパーのメモリおよび CPU の使用率が 80% に達すると、トランク登録状態を維持するために、そのゲートキーパーは San Jose の Unified CM クラスタに送信する Registration, Admission, and Status(RAS)メッセージへの Chicago のゲートキーパー情報の送信を開始します。同様に、Chicago および New York の他のゲートキーパーも設定し、それらのサイトのローカル Unified CM トランク登録の負荷を他のサイトにあるゲートキーパーにロードバランスできます。

図 8-15 の 3 つの Unified CM クラスタ間でコールをルーティングするときに、そのロケーションとコールがルーティングされているロケーション間のネットワークで適切な帯域幅を使用できることを確認するために、各サイトのゲートキーパーを設定する必要があります。十分な帯域幅がないと、コールがルーティングされません。分散型 Unified CM のロケーション間のゾーン間コール帯域幅を指定するには、 bandwidth interzone コマンドを推奨します。

arq reject-unknown-prefix コマンドを使用して、クラスタ内の冗長 Unified CM トランク上にできるコール ルーティングを回避します。このコマンドを使用すると、ダイヤルされたプレフィックスが定義されたプレフィックスと一致しないときに、ゲートキーパーからコール ルーティング要求がローカル ゲートウェイまたは Unified CM トランクに転送されるのを防止します。

ゲートキーパーの配置および設定の詳細については、次の Web サイトで入手可能な『 Cisco IOS H.323 Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10591/products_installation_and_configuration_guides_list.html

ディレクトリ ゲートキーパーの冗長性

HSRP を使用するか、複数の同じディレクトリ ゲートキーパーを設定すると、ディレクトリ ゲートキーパーの冗長性を実装できます。同じゾーン プレフィックスを使用して、複数のリモート ゾーンを持つゲートキーパーを設定するとき、このゲートキーパーには、次のいずれかの方法が使用できます。

シーケンシャル LRQ(デフォルト)

冗長リモート ゾーン(ゾーン プレフィックスが一致)にコストが割り当てられ、LRQ は、コスト値に基づいた順序で、一致するゾーンに送信されます。順次 LRQ を使用すると、一致するすべてのゲートキーパーに LRQ を送信しないので、WAN 帯域幅の節約になります。

LRQ ブラスト

LRQ は、冗長ゾーン(ゾーン プレフィックスが一致)に同時に送信されます。ロケーション確認(LCF)で応答する最初のゲートキーパーが、使用されます。

順次 LRQ を使用して複数のアクティブ ディレクトリ ゲートキーパーを使用することを推奨します。これによって、ディレクトリ ゲートキーパーを別々のロケーションに配置できます。HSRP を使用するには、両方のディレクトリ ゲートキーパーを同じサブネットに置く必要があります。この場合常に 1 つのゲートキーパーしかアクティブにすることができません。

図 8-16 では、図 8-15 に示すように 3 つの分散型ローカル ゲートキーパーを備えた、3 つのサイトの同じ Unified CM 分散型呼処理配置を示しています。ただし、図 8-15 に示した配置とは異なり、図 8-16 の配置は、冗長サイト間コール ルーティングの 2 つのアクティブ ディレクトリ ゲートキーパーに依存する 3 つの分散型ローカル ゲートキーパー(代替ゲートキーパーまたはクラスタリング ゲートキーパーに依存するのではなく)を示します。

図 8-16 冗長ディレクトリ ゲートキーパー

 

冗長ディレクトリ ゲートキーパーを配置する場合は、次のガイドラインを考慮してください。

ディレクトリ ゲートキーパーの冗長性を設定するときは、各ディレクトリ ゲートキーパーをローカル ゾーンで設定します。図 8-16 に示す例では、San Jose(West DGK)にあるディレクトリ ゲートキーパーは 1 つのローカル ゾーン名と IP アドレスで設定されますが、New York(East DGK)にあるディレクトリ ゲートキーパーはもう 1 つのローカル ゾーン名と IP アドレスで設定されます。

ディレクトリ ゲートキーパーは、ネットワーク上の各ゲートキーパーに対応するリモート ゾーンで設定する必要があります。図 8-16 に示す例では、San Jose(West DGK)にあるディレクトリ ゲートキーパーと New York(East DGK)にあるゲートキーパーの両方は、San Jose サイト(Gatekeeper 1)のゲートキーパーに対応するリモート ゾーン、Chicago サイト(Gatekeeper 2)のゲートキーパーに対応するリモート ゾーン、および New York サイト(Gatekeeper 3)のゲートキーパーに対応するリモート ゾーンで設定されます。これらのリモート サイトの設定は、両方のディレクトリ ゲートキーパー上で同一です。

各ディレクトリ ゲートキーパーは、ゾーン間コール ルーティングの各リモート ゾーンに対応する着信番号のプレフィックスで設定されます。図 8-16 に示す例では、両方のディレクトリ ゲートキーパーは、各サイトのゲートキーパーによってサービスが提供されるローカル エリア コードに対応するプレフィックスで設定されます。たとえば、San Jose のゲートキーパー(Gatekeeper 1)のリモート ゾーンには、プレフィックス 408 が設定され、Chicago のゲートキーパー(Gatekeeper 2)のリモート ゾーンには、プレフィックス 720 が設定され、New York のゲートキーパー(Gatekeeper 3)のリモート ゾーンには、プレフィックス 212 が設定されます。他の着信番号のプレフィックスに対応する必要に応じて各リモート ゾーンに対して、追加のプレフィックスを設定できます。コールはローカル ディレクトリ ゲートキーパー ゾーンにルーティングされないので、これらのゾーンにはプレフィックスは必要ありません。特定のプレフィックスの設定に加え、ワイルドカード文字 ∗ を使用して、明示的に定義されていないすべてのプレフィックスに対応付けることができます。

各ディレクトリ ゲートキーパーで lrq forward-queries コマンドを設定し、1 つのゲートキーパーから受信したコール セットアップ ロケーション要求(LRQ)がダイヤルされたプレフィックスに基づいたサービスに応じて他のゲートキーパーの 1 つに転送されるようにします。図 8-16 に示す例では、LRQ 照会を転送するために、San Jose(West DGK)にあるディレクトリ ゲートキーパーと New York(East DGK)にあるディレクトリ ゲートキーパーの両方を設定する必要があります。


) ディレクトリ ゲートキーパーは、アクティブ エンドポイント登録を含まず、いかなる帯域幅管理も行いません。


前の例(図 8-15)と同様に、図 8-16 の各サイトに示されているローカル サイト ゲートキーパーが、各サイトにある Unified CM クラスタ トランクにサービスおよび登録を提供します。

各ローカル サイトのゲートキーパーは、各ディレクトリ ゲートキーパーのリモート ゾーンで設定されます。図 8-16 に示す例では、San Jose サイト(Gatekeeper 1)にあるローカル ゲートキーパーに、San Jose(West DGK)にあるディレクトリ ゲートキーパーと New York(East DGK)にあるディレクトリ ゲートキーパーの両方に設定されたリモート ゾーンがあります。 Chicago(Gatekeeper 2)および New York(Gatekeeper 3)にあるローカル ゲートキーパーは同じように設定されます。

ローカル ゲートキーパーと設定されたリモート ゾーンとの間の帯域幅を制限するために、各ローカル サイトのゲートキーパーを設定する必要があります。図 8-16 に示す例では、各ローカル ゲートキーパーは、リモート ゾーンのディレクトリ ゲートキーパーへのコールのルーティングに使用できる帯域幅の量を決定する bandwidth remote コマンドを使用して設定されます。たとえば、 bandwidth remote コマンドは、San Jose(West DGK)にあるディレクトリ ゲートキーパーに定義されたリモート ゾーンおよび New York(East DGK)にあるディレクトリ ゲートキーパーに定義されたリモート ゾーンへのコールのルーティングに使用できる帯域幅を制限するために、San Jose のゲートキーパー(Gatekeeper 1)に設定されます。これにより、San Jose サイトのゲートキーパー(Gatekeeper 1)と他のサイトのゲートキーパーのいずれか(Gatekeeper 2 または Gatekeeper 3)との間のコール ルーティングに使用できる帯域幅が制限されます。この同じ設定は、他のローカル サイトのゲートキーパーに複製されます。

各ローカル サイトのゲートキーパーは、ローカル ゲートキーパーに対応するローカル ゾーンのゾーン プレフィックスと 2 つのディレクトリ ゲートキーパーの両方のリモート ゾーンのゾーン プレフィックスで設定されます。前者のローカル ゾーン プレフィックスはローカル Unified CM クラスタへのコール ルーティングを処理するのに対し、後者のリモート ゾーン プレフィックスは他のゲートキーパー サイトへのゾーン間コール ルーティングを処理します。図 8-16 に示す例では、San Jose サイトにあるローカル ゲートキーパー(Gatekeeper 1)はローカル ゾーン プレフィックス 408 およびリモート ゾーン プレフィックスである 10 個のドット(.)で設定されていて、 2 つのディレクトリ ゲートキーパー(East DGK および West DGK)に対応しています。これらの 10 個のドット(.)のプレフィックスは、ローカル ゾーン プレフィックス 408 で始まらない正規化された 10 桁の E.164 着信番号すべてと一致します。したがって、Gatekeeper 1 によってルーティングされた、408 で始まらないすべてのコールは、ディレクトリ ゲートキーパーの 1 つを経由して他のゲートキーパー サイトの 1 つにルーティングされます。Chicago(Gatekeeper 2)および New York(Gatekeeper 3)のサイトにあるローカル ゲートキーパーは、同一の一般的なリモート ゾーンの 10 個のドット プレフィックスと同時に、それぞれローカル ゾーン プレフィックス 720、212 で設定されます。

一致するゾーン プレフィックスが設定されるとき、デフォルトで順次ロケーション要求(LRQ)が使用されます。図 8-16 に示す例では、408 で始まらない着信番号にルーティングされるすべてのコールでは、San Jose サイトのローカル ゲートキーパー(Gatekeeper 1)は、West DGK に対応するリモート ゾーンに設定された一般的な 10 個のドット(.)のプレフィックスに基づいて、San Jose にあるディレクトリ ゲートキーパー(West DGK)に LRQ を最初に送信します。West DGK から応答を受け取らなかった場合、Gatekeeper 1 が、LRQ を New York にあるディレクトリ ゲートキーパー(East DGK)に、East DGK に対応するリモート ゾーンに設定された一般的な 10 個のドット(.)のプレフィックスに基づいて送信します。同様に、Chicago(Gatekeeper 2)および New York サイト(Gatekeeper 3)のローカル ゲートキーパーがリモート ゾーンと 10 個のドット(.)に基づいて、最初にディレクトリ ゲートキーパーの 1 つに LRQ を送信し、最初から応答を受け取らなかった場合は、2 つ目のディレクトリ キーパーに送信します。

前のゲートキーパー クラスタリングの例(図 8-15)と同様に、 gw-type-prefix コマンドを使用して、ローカルで解決されないすべてのコールをローカル ゾーン内に設定されたテクノロジー プレフィックスに登録されたデバイスに転送できます。 arq reject-unknown-prefix コマンドは、クラスタ内の冗長 Unified CM トランク上にできるコール ルーティング ループを回避します。

ディレクトリ ゲートキーパーの配置の詳細については、次の Web サイトで入手可能な『 Cisco IOS H.323 Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10591/products_installation_and_configuration_guides_list.html

Unified CM と Unified CM Express の相互運用性

この項では、H.323 または SIP トランキング プロトコルを使用している Cisco Unified CM と Cisco Unified Communications Manager Express(Unified CME)に関して、マルチサイト IP テレフォニー配置における相互運用性およびインターネットワーキングの要件について説明します。ここでは、Unified CM の制御する電話機と Unified CME の制御する電話機との間での推奨する配置を中心に説明します。

この項では、次の項目について説明します。

「Unified CM と Unified CME 間の相互運用性の概要」

「分散型呼処理を使用したマルチサイト配置における SIP 経由の Unified CM と Unified CME の相互運用性」

「分散型呼処理を使用したマルチサイト配置における H.323 経由の Unified CM と Unified CME の相互運用性」

Unified CM と Unified CME 間の相互運用性の概要

H.323 または SIP をトランキング プロトコルとして使用して、Unified CM と Unified CME を相互接続できます。本社または中央サイトに Unified CM を配置して、支店の Unified CME システムと連携させる場合、ネットワーク管理者は、プロトコルの仕様と WAN トランク全体でサポートされる機能を慎重に検討して、SIP または H.323 のいずれかのプロトコルを選択する必要があります。以前は、H.323 トランクを使用して Unified CM と Unified CME を接続する方法が主流でしたが、SIP 電話機と SIP トランクのより高度な機能が Unified CM と Unified CME に追加されたことで、この状況は変わりました。この項ではまず、Unified CM と Unified CME の相互運用性のトランキング プロトコルとは無関係のいくつかの機能について説明し、次に SIP トランクと H.323 トランクを使用するための最も一般的な設計シナリオとベスト プラクティスを紹介します。

コール タイプとコール フロー

一般に、Unified CM と Unified CME のインターワーキングを使用すると、SIP トランクまたは H.323 トランク全体で、SCCP IP Phone から SIP IP Phone へのコール、またはその逆のコールをすべて組み合わせることができます。コールは、Unified CM と Unified CME SIP 間、または SCCP IP Phone との間で、転送(ブラインドまたは打診)または自動転送できます。

H.323 トランク経由で Unified CM に接続していると、Unified CME は Unified CM のコールを自動検出できます。Unified CME を終端とするコールが転送または自動転送されると、Unified CME はコールを再生成し、ヘアピン コールによって他の Unified CME または Unified CM に適切にコールをルーティングします。Unified CME は必要に応じて、SIP トランクまたは H.323 トランク全体の VoIP コールについて、Unified CM からのコール レッグをヘアピンします。H.450 以外でサポートされる Unified CM ネットワークで自動検出を可能にする方法と、H450.2、H450.3、または SIP の付加サービスを有効または無効にする方法の詳細については、次の Web サイトで入手可能な Unified CME の製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

SIP トランク経由で Unified CM に接続すると、Unified CME は Unified CM のコールを自動検出しません。デフォルトでは、Unified CME は常に、コール転送の SIP Refer メッセージまたは自動転送の SIP 302 Moved Temporarily メッセージを使用して、コールをリダイレクトしようとします。リダイレクトが失敗すると、Unified CME はヘアピン コールを試みます。

保留音(Music on Hold)

Unified CM では G.711 形式と G.729 形式の両方で MoH ストリームを有効にできますが、Unified CME で MoH をストリームできるのは G.711 形式のみです。そのため、保留になったコールの MoH オーディオを Unified CME で制御する場合は、G.711 MoH ストリームと G.729 コール レッグの間でトランスコーディングするためのトランスコーダが必要です。

アドホックおよび Meet-Me のハードウェア会議

アドホック会議と Meet-Me 会議の両方に、ハードウェアの DSP リソースが必要です。SIP、H.323、PSTN のいずれを経由して接続している場合でも、Unified CM 電話機と Unified CME 電話機は、ネットワークから到達できる限り、アドホック会議に招待または追加されて、会議の参加者になることができます。アクティブな会議のセッション中にコールを保留にしても、その会議のセッションの参加者には音楽は聞こえません。

アドホック会議と Meet-Me 会議に必要でサポートされる DSP リソースと、会議に参加できる最大人数については、次の Web サイトで入手可能な Unified CME の製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

分散型呼処理を使用したマルチサイト配置における SIP 経由の Unified CM と Unified CME の相互運用性

Unified CM は、SIP インターフェイスを使用する Unified CME と直接通信できます。図 8-17 に、SIP トランクを使用して Unified CM が Cisco Unified CME と直接ネットワーク接続されている Cisco Unified Communications マルチサイト配置を示します。

図 8-17 SIP トランクを使用して Unified CM と Unified CME を接続したマルチサイト配置

 

ベスト プラクティス

図 8-17 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。

[Accept Replaces Header] を選択した SIP トランク セキュリティ プロファイルを設定します。

作成した SIP トランク セキュリティ プロファイルを使用して SIP トランクを Unified CM 上に設定し、再ルーティング CSS も指定します。再ルーティング CSS は、どこで SIP ユーザ(転送者)が別のユーザ(被転送者)を第三者ユーザ(転送先)に振り向けることができるか、および SIP 302 Redirection Response と Replaces を持つ INVITE を使用して SIP ユーザがどの機能を呼び出せるかを決定するために使用します。

SIP トランクの場合、Unified CME 上で SCCP エンドポイントを使用しているときに、メディア ターミネーション ポイント(MTP)を使用可能にする必要はありません。ただし、Unified CME 上に SIP エンドポイントがある場合は、メディア ターミネーション ポイントを Unified CM 上で使用して、SIP プロトコルでディレイド オファー/アンサー交換の処理(セッション記述プロトコルなしの INVITE 受信)ができるようにする必要があります。

Unified CM ダイヤル プラン設定(ルート パターン、ルート リスト、ルート グループ)を使用して、SIP トランク経由で Unified CME にコールをルーティングします。

Unified CM のデバイス プールとリージョンを使用して、サイト内では G.711 コーデックを設定し、リモートの Unified CME サイトに対しては G.729 コーデックを設定します。

Unified CME の voice services voip allow-connections sip to sip コマンドを設定して、SIP-to-SIP コール接続を許可します。

SIP エンドポイントの場合は、 voice register global mode cme コマンドを設定し、Unified CME の SIP 電話機ごとに voice register pool コマンドで dtmf-relay rtp-nte を設定します。

SCCP エンドポイントの場合は、Unified CME の telephony-service transfer-system full-consult コマンドと transfer-pattern .T コマンドを設定します。

Unified CME の session protocol sipv2 および dtmf-relay [sip-notify | rtp-nte ] により、SIP WAN インターフェイスの voip ダイヤル ピアを設定し、Unified CM を宛先としてコールを転送またはリダイレクトします。

設計上の考慮事項

この項ではまず、一部の主要な領域における SIP 経由での Unified CM と Unified CME の相互運用性に関するいくつかの特徴と設計上の考慮事項について説明します。主要な領域には、コール転送や自動転送のための付加サービス、スピード ダイヤル ボタンや電話帳のコール リストの Busy Lamp Field(BLF)通知のためのプレゼンス サービス、パートナー アプリケーションとの統合や、Unified CM 電話機と Unified CME 電話機間のクリックツーダイヤルに対するサードパーティ製電話による制御のための Out-Of-Dialog Refer(OOD-Refer)などが含まれます。この項では、SIP 経由での Unified CM と Unified CME の相互運用性に関する設計上の一般的な考慮事項についても説明します。

付加サービス

SIP Refer メッセージや SIP 302 Moved Temporarily メッセージを Unified CME または Unified CM でのコール転送や自動転送などの付加サービスに使用して、転送先または自動転送先に対して新しいコールを開始するよう、被転送者または自動転送される電話機(被転送者)に指示できます。SIP Refer メッセージまたは SIP 302 Moved Temporarily メッセージがサポートされている場合、コール転送や自動転送のシナリオにはヘアピンは不要です。

ただし、DID マッピングがない内線が存在する場合や、Unified CM または Unified CME に、SIP 302 Moved Temporarily メッセージの DID にコールをルーティングするダイヤル プランがない場合は、 supplementary-service を無効にする必要があります。 supplementary-service が無効になっていると、Unified CME はコールをヘアピンするか、re-INVITE の SIP メッセージを Unified CM に送信して、新しい着信者 ID へメディア パスを置き換えます。それ以降のコール転送に複数の Unified CME が関係する場合でも、シグナリングとメディアの両方がヘアピンされます。転送されたコールでも、 supplementary-service は無効にできます。この場合、SIP Refer メッセージは Unified CM に送信されませんが、被転送者と転送先がヘアピンされます。


) 付加サービスを無効にするには、voice service voip または dial-peer voice xxxx voipno supplementary-service sip moved-temporarily コマンドか no supplementary-service sip refer コマンドを実行します。


次の例は、付加サービスが無効になっているときのコール フローを示しています。

Unified CM の電話機 B が Unified CME の電話機 A にコールします。電話機 A は電話機 C(Unified CM 電話機、同一または異なる Unified CME 上にある Unified CME 電話機、PSTN 電話機のいずれか)に自動転送([Forward All]、[Forward Busy]、[Forward No Answer])するように設定されています。

Unified CME は Unified CM に SIP 302 Moved Temporarily メッセージを送信しませんが、Unified CM 電話機 B と電話機 C の間でコールをヘアピンします。

Unified CM の電話機 B が Unified CME の電話機 A にコールします。電話機 A はコールを電話機 C(Unified CM 電話機、Unified CME 電話機、PSTN 電話機のいずれか)に転送します。

Unified CME は Unified CM に SIP Refer メッセージを送信しませんが、Unified CM 電話機 B と電話機 C の間でコールをヘアピンします。

SIP 経由での Unified CM と Unified CME の相互運用性に関する設計上の一般的な考慮事項

SIP 302 Moved Temporarily メッセージまたは SIP Refer メッセージが Unified CM でサポートされていない場合は、 supplementary-service を無効にします。無効にしないと、Unified CM はコールを転送先または自動転送先にルーティングできません。

SIP-to-SIP コール シナリオでは、Refer メッセージがデフォルトで転送者から被転送者に送信され、被転送者は転送先への新しいコールをセットアップします。コールが転送先につながるまで、転送者にはデフォルトでリングバック トーンが聞こえます。Unified CME の supplementary-service が無効になっている場合、Unified CME は、被転送者と転送先の間でコールが接続されるとすぐにインバンドのリングバック トーンを提供します。

プレゼンス サービスは、SIP トランク経由の Unified CM と Unified CME でのみサポートされます。

OOD-Refer 機能を使用すると、サードパーティ製アプリケーションで SIP REFER メソッドを使用して、Unified CM または Unified CME の 2 つのエンドポイントを接続できます。OOD-Refer を使用する場合は、次の点を考慮してください。

Unified CM と Unified CME はどちらも、OOD-Refer 機能が有効になるよう設定する必要があります。

保留、転送、および会議は、OOD-Refer トランザクション中はサポートされませんが、Unified CME によってブロックされることもありません。

コール転送がサポートされるのは、OOD-Refer コールが接続状態になった後のみで、コールの接続前はサポートされません。そのため、接続前はコールの transfer-at-alert はサポートされません。

TLS のシグナリング制御はサポートされますが、SRTP は SIP トランク経由ではサポートされません。

ビデオは、SIP 電話機でも SIP トランク経由でもサポートされません。

SIP トランク経由の SRTP は、Unified CM 用 Cisco IOS のゲートウェイ機能です。SRTP サポートは、SIP トランク経由での Unified CM と Unified CME のインターワーキングでは使用できません。


) 複数の PSTN 接続(Unified CM に 1 つと Unified CME に 1 つ)が存在する場合、PSTN エンドポイントに対する Unified CM エンドポイントと Unified CME エンドポイント間の完全在席転送は失敗します。複数の PSTN 接続を使用する場合にはブラインド転送の使用を推奨し、この設定は telephony-servicetransfer-system full-blind として行います。



) Cisco Unified CME は、SIP トランクを介した複数の Unified CME 間のビデオ コールをサポートします。この機能は、Unified CME だけを使用する分散型呼処理配置で適用されます。SIP トランクを介した Unified CM と Unified CME との間のビデオ コールはサポートされていません。設定の詳細については、http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_installation_and_configuration_guides_list.html で入手可能な『Cisco Unified Communications Manager Express System Administrator Guide』を参照してください。


分散型呼処理を使用したマルチサイト配置における H.323 経由の Unified CM と Unified CME の相互運用性

分散型呼処理を使用したマルチサイト WAN 配置で、H.323 接続経由の Unified CM と Unified CME の相互運用性を実現する配置オプションは 2 つあります。1 番めのオプションは、Cisco Unified Border Element を Unified CM のフロントエンド デバイスとして配置する方法で、リモートの Unified CME システムとはピアツーピア H.323 で接続します。Cisco Unified Border Element が Unified CM と Unified CME との間のダイヤル プラン解決を実行し、同時に両者間のコール シグナリング メッセージを終端し、再発信します。Cisco Unified Border Element は、Unified CM など、付加サービスの H.450 をサポートしないシステムのためにプロキシ デバイスとして機能し、Empty Capability Set(ECS)を使用して付加サービスを呼び出します。また、Cisco Unified Border Element は、Unified CM クラスタ用の PSTN ゲートウェイとしても動作できるため、PSTN ゲートウェイを別に用意する必要がありません。

2 番めのオプションは、中継ゾーン ゲートキーパー経由で配置する方法です。Unified CM、Unified CME、および Cisco Unified Border Element はすべて、VoIP ゲートウェイ デバイスとして中継ゾーン ゲートキーパーに登録されます。中継ゾーン ゲートキーパーが Unified CM と Unified CME 間のダイヤル プラン解決と帯域幅制限を実行します。また、中継ゾーン ゲートキーパーは、ECS と H.450 との間で相互作用するコール パスに Cisco Unified Border Element を挿入し、付加サービスを呼び出します。中継ゾーン ゲートキーパーと Cisco Unified Border Element の詳細については、「コール アドミッション制御」の章を参照してください。

これらの 2 つの配置オプションには、次の相違点があります。

1 番めのオプションでは、Cisco Unified Border Element は H.323 ゲートウェイ デバイスとして Unified CM に登録され、2 番めのオプションでは、VoIP ゲートウェイ デバイスとして中継ゾーン ゲートキーパーに登録されます。

1 番めのオプションでは、Cisco Unified Border Element が Cisco Unified Border Element の VoIP ダイヤル ピア設定に基づくダイヤル プラン解決を実行し、2 番めのオプションでは、中継ゾーン ゲートキーパーがゲートキーパーのダイヤル プラン設定に基づくダイヤル プラン解決を実行します。

1 番めのオプションでは、両方のコール レッグを監視するコール アドミッション制御メカニズムがなく、2 番めのオプションでは、中継ゾーン ゲートキーパーがゲートキーパー ゾーンベースのコール アドミッション制御を実行します。

2 番めのオプションでは、中継ゾーン ゲートキーパーは Unified CM のインフラストラクチャ ゲートキーパーとして機能し、Unified CM クラスタ間、Unified CM クラスタと H.323 VoIP ゲートウェイのネットワーク間、および Unified CM クラスタとサービス プロバイダーの H.323 VoIP 転送ネットワーク間のすべてのダイヤル プラン解決および帯域幅制限を管理することもできます。

図 8-18 は、中継ゾーン ゲートキーパーと Cisco Unified Border Element を使用する Unified CM と Unified CME 間の H.323 統合を示しています。

図 8-18 Cisco Unified Border Element または中継ゾーン ゲートキーパーを使用して Unified CM と Unified CME を接続するマルチサイト配置

 

ベスト プラクティス

この項では、2 番めの配置オプション(中継ゾーン ゲートキーパー)で、図 8-18 に示した配置モデルを使用する場合のガイドラインとベスト プラクティスについて説明します。

Unified CM と中継ゾーン ゲートキーパーとの間にゲートキーパー制御の H.225 トランクを設定します。Media Termination Point(MTP; メディア ターミネーション ポイント)のリソースがトランクに必要になるのは、Unified CME が発信 H.323 fast-start コールを開始しようとしたときのみです。

トランクの両端の H.323 デバイスが、遠端デバイスによって先に TCS が送信されるのを待っていて、H.245 接続が数秒後にタイムアウトになる場合、デッドロック状態が発生しないようにするため、[Wait For Far End H.245 Terminal Capability Set] (TCS)オプションをオフにする必要があります。

Unified CM サービス パラメータ [Send H225 user info message] [H225 info for Call Progress Tone] に設定し、Unified CM から Unified CME に H.225 Info message を送信して、リングバック トーンまたは保留トーンを再生できるようにします。

Unified CM ダイヤル プランの設定(ルート パターン、ルート リスト、およびルート グループ)を使用して、Unified CME を宛先とするコールをゲートキーパー制御の H.225 トランクに送信します。

Unified CME と Cisco Unified Border Element を H.323 ゲートウェイとして中継ゾーン ゲートキーパーに登録します。

Cisco Unified Border Element 上で allow-connection h323 to h323 コマンドを設定して、H.323-to-H.323 コール接続を許可します。このコマンドは、Unified CME に対して設定するためのオプションです。Cisco Unity Connection を Unified CME で使用する場合は、 allow-connection h323 to sip を設定します。

コール転送や自動転送などの付加サービスでは、2 つのエンドポイントが同じ Unified CME 支店ロケーションに存在する場合に、コールのメディア ヘアピンが発生します。


) 2 つの配置オプションにおける設定の違いは、1 番めのオプションでは、Unified CM で Cisco Unified Border Element を H.323 ゲートウェイ デバイスとして設定する必要があることだけです。上記のその他の設定ガイドラインは、どちらのオプションも同じです。



) 複数の PSTN 接続(Unified CM に 1 つと Unified CME に 1 つ)が存在する場合、PSTN エンドポイントに対する Unified CM エンドポイントと Unified CME エンドポイント間の完全在席転送は失敗します。複数の PSTN 接続を使用する場合にはブラインド転送の使用を推奨し、この設定は telephony-servicetransfer-system full-blind として行います。


設計上の考慮事項

H.323 配置では、Unified CME はコール転送、H.450.2、および H.450 標準の一部としての H.450.3 を使用した自動転送をサポートします。ただし、Unified CM は H.450 をサポートしません。また、コール転送、自動転送、保留または保留解除などの付加サービスは、Empty Capabilities Set(ECS)を使用して行われます。そのため、コールが Unified CM と Unified CME との間で転送または自動転送されると、Cisco Unified Border Element を使用して、コールはヘアピンされ、ルーティングされます。前の項の 2 つの配置モデルとして説明したように、ゲートキーパーは使用される場合と使用されない場合があります。この項では、H.323 経由の Unified CM と Unified CME の相互運用性の設計上の考慮事項とベスト プラクティスを示します。

コール転送および自動転送などの付加サービス

Unified CME は、H.450.12 プロトコルを使用して H.450. x 機能を自動的に検出することで、H.450 をサポートしない Unified CM を自動検出します。Unified CME は、Unified CM と Unified CME 間のコールに VoIP ヘアピン ルーティングを使用します。コールが終端すると、Unified CME は必要に応じてコールを再発信およびルーティングして、Unified CM 電話機からのコールをヘアピンします。


) Unified CME は、Unified CM が H.450 をサポートしないことを検出すると、Unified CME でシグナリングとメディアの両方をヘアピンして、コールをヘアピンします。そのため、コールを WAN を介して転送または自動転送すると、消費される帯域幅の量は 2 倍になります (たとえば、Unified CM 電話機が Unified CME 電話機にコールして、Unified CME 電話機がコールを別の Unified CM 電話機に転送すると、Unified CME は、2 台の Unified CM 電話機間のコールでも、シグナリングとメディアの両方をヘアピンします)。この WAN での 2 倍の帯域幅消費を避けるために、Cisco Unified Border Element を使用して H.450 タンデム ゲートウェイとして機能させ、コール転送または自動転送などの付加サービスで H.450-to-ECS マッピングを可能にすることを推奨します。


サポートされるコール フロー

Unified CME はバックツーバック ユーザ エージェント(B2BUA)なので、コール フローは SCCP 電話機から SCCP 電話機へ、および SCCP 電話機から SIP 電話機へと機能します。SIP 電話機のコールは H.323 トランク経由で機能しますが、付加機能はサポートされません。

セキュリティ

Unified CME は、TLS を使用するセキュア シグナリングと SRTP を使用するメディア暗号化を提供します。Unified CM はまた、TLS 経由でセキュア シグナリング、および SRTP 経由でセキュア メディアをサポートします。ただし、セキュア Unified CM とセキュア Unified CME との間のインターワーキングはサポートされていません。

ビデオ

Unified CME を使用してビデオ機能を実装する場合は、次の設計上の考慮事項に従ってください。

Unified CM と Unified CME のすべてのエンドポイントは、ビデオ対応エンドポイントとして設定する必要があります。ビデオ コーデックとビデオ形式は、すべてのビデオ対応エンドポイントで一致する必要があります。

Unified CM と Unified CME は基本的なビデオ コールをサポートしますが、コール転送や自動転送などの付加サービスは、Unified CM と Unified CME 間のビデオ コールではサポートされません。Unified CME で付加サービスをサポートするには、すべての Unified CME と音声ゲートウェイで H.450 を有効にする必要があります。Unified CM は H.450 をサポートしないため、Unified CM 電話機と Unified CME 電話機間で付加サービスが必要な場合、ビデオ コールは音声のみのコールに戻ります。

電話会議は音声専用に戻ります。

ビデオ トラフィックが WAN を通過するには、WAN 帯域幅は 384 kbps の最小ビデオ ビットレートを満たす必要があります。

ビデオの基本的なコールは SCCP 電話機でのみサポートされ、SIP 電話機ではサポートされません。

ISDN 経由の H.320 ビデオ

ISDN 経由で H.320 ビデオ機能を実装する場合は、次の設計上の考慮事項に従ってください。

PRI または BRI インターフェイス経由で H.320 エンドポイントに直接接続する場合、Unified CME および Cisco IOS ルータは現在、128 kbps のビデオ コールのみをサポートしています。

Unified CME および PSTN ゲートウェイで H.320 を有効にして、Unified CM と相互作用するようにするには、音声のみのコールと区別するために、ビデオ コールには別個のダイヤル ピアを使用します。Unified CME の voice-port 設定で bear-cap speech を設定します。

H.320 は付加サービスをサポートしません。

H.323 経由での Unified CM と Unified CME の相互運用性に関する設計上の一般的な考慮事項

H.450.12 を使用して Unified CM を自動検出するように Unified CME を設定し、Unified CM 電話機と Unified CME 電話機間のコールをヘアピンします。

SCCP-to-SCCP コールまたは SCCP-to-SIP コールの場合は、H.323 トランクを Unified CM と Unified CME との間に配置できます。

Unified CME は、TLS を使用するセキュア シグナリングと SRTP を使用するセキュア メディアをサポートしますが、会議コール フローは保護できません。さらに、Unified CM 電話機と Unified CME 電話機間のセキュリティの相互運用性もサポートされていません。

ビデオを配置するのは SCCP 電話機用(基本的なコールのサポートを使用)で、SIP 電話機用ではありません。

MTP 機能はビデオと互換性がありません。ビデオ コールを機能させるには、MTP 機能を無効(オフ)にする必要があります。

Unified CM と Unified CME 間の IP 接続が正常に機能することを確認します。

Unified CME の各ローカル ゾーンと Unified CM のロケーション(ローカル SCCP)で、ローカル ビデオのセットアップが正常に機能することを確認します。

既存の音声ダイヤル プランのインフラストラクチャを使用します。

ビデオ トラフィック シェーピングの場合は、次のガイドラインに従ってください。

CoS 4 を使用するビデオ コールのビデオ チャネルと音声チャネルが、リップシンクを維持し、ビデオと音声のみのコールを区別するようにします。

音声トラフィックとビデオ トラフィックを異なるキューに配置します。

音声トラフィックとビデオ トラフィックにプライオリティ キューイング(PQ)を使用します。音声のみのコールとビデオ(音声ストリーム + ビデオ ストリーム)コールには、分類に基づいて 2 つの異なるポリシーが必要です。ビデオ コールの音声ストリームには、ビデオ コールのビデオ ストリームと同じマークが付けられているため、ビデオ コールの音声コールは保護されています。

ビデオは、帯域幅が 768 kbps 未満のリンクには配置しないでください。

リンク速度が 768 kbps 以上で、オーバーサブスクリプションを防止する適切なコール アドミッション制御を使用している場合は、PQ にビデオ トラフィックを配置しても、音声パケットの遅延が大幅に改善されることはありません。

スピードが 768 kbps 以上の場合はフラグメンテーションを設定する必要はありません。

ビデオ パケットには cRTP は推奨しません (ビデオ パケットは大きいため、cRTP はビデオには役立ちません)。

音声トラフィックとビデオ トラフィックがリンク容量に占める割合が 33% を超えないようにします。

ビデオ帯域幅を計算する場合、オーバーヘッドを考慮して、コールの合計ビデオ データ レートに 20% を加算します。

H.323 を使用して Unified CME を Unified CM に統合する方法の詳細については、次の Web サイトで入手可能な『 Cisco Unified CME Solution Reference Network Design Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_implementation_design_guides_list.html