この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
音声コールとビデオ コールの処理は、IP テレフォニー システムによって提供される重要な機能です。この機能は、特定のタイプの呼処理エンティティまたは呼処理エージェントによって処理されます。呼処理の操作は重要であるため、ユニファイド コミュニケーションの配置を設計して、呼処理システムが、必要なユーザ数およびデバイス数を処理するのに十分なスケーラビリティと、ネットワークおよびアプリケーションのさまざまな異常または障害を処理するのに十分な復元性を持つようにすることが重要です。
この章では、シスコの呼処理製品によってスケーラブルで復元性のある呼処理システムを設計するためのガイドラインを示します。このような製品には、Cisco Unified Communications Manager(Unified CM)、および Cisco Unified Communications Manager Express(Unified CME)があります。主に次の要素を中心に説明します。
ここでは、一般的な呼処理アーキテクチャおよびさまざまな呼処理ハードウェア オプションについて説明します。また、Unified CM クラスタリングについても説明します。
ここでは、ネットワークの冗長性、サーバの冗長性、ロード バランシングなど、呼処理のハイ アベイラビリティに関する考慮事項について説明します。
ここでは、基本設計のガイドラインと呼処理を配置するためのベスト プラクティスの要約リストを示します。
ここでは、Cisco コンピュータ テレフォニー インテグレーション(CTI)アーキテクチャについて説明し、CTI のコンポーネントとインターフェイス、CTI 機能、CTI のプロビジョニングとキャパシティ プランニングについて説明します。
ここでは、Cisco Unified CM Session Management Edition(SME)で通常実行される、複数の呼処理エージェントの統合について説明します。また、Cisco Unified Communications Manager Express(Unified CME)との Cisco Unified CM の直接的統合についても扱います。
表 9-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
ユニファイド コミュニケーション システムの設計と配置を成功させるには、コール ルーティング機能を提供する基盤の呼処理アーキテクチャを理解することが重要です。この機能は、次のシスコの呼処理エージェントによって提供されます。
Cisco Unified CM は、小規模~非常に大規模な単一サイト配置、マルチサイト集中型呼処理配置、およびマルチサイト分散呼処理配置に、呼処理サービスを提供します。Unified CM はシスコ コラボレーション ソリューションの中核をなし、音声、ビデオ、TelePresence、IM and Presence、メッセージング、モビリティ、Web 会議、セキュリティを提供する基盤として機能します。
VPN や Cisco Expressway などのコラボレーションに関する様々な先端ソリューションを使えば、インターネットからエンタープライズ コラボレーション ネットワークおよび Unified CM にアクセスして、リモート アクセスおよび Business-to-Business のセキュアなテレプレゼンスとビデオ コミュニケーションが可能になります。
Cisco TelePresence VCS は、ビデオ エンドポイントの登録、呼処理、および SIP および H.323 エンドポイントの帯域幅管理を行うことができるビデオ アプリケーションです。VCS は SIP レジストラ、SIP プロキシ サーバ、H.323 ゲートキーパー、および SIP から H.323 へのゲートウェイ サーバとして機能し、SIP と H.323 デバイスの間にインターワーキングを提供します。また Cisco TelePresence VCS は、VCS Expressway と組み合わせることによって、NAT/ファイアウォール トラバーサルを使用した外部通信を提供します。
SIP をサポートする TelePresence エンドポイントおよびルーム ベースの TelePresence 会議システムなどの、すべてのエンドポイントのメイン呼処理エージェントとして Unified CM を配置し、十分な機能を有する H.323 Telepresence エンドポイントとの相互運用性またはサードパーティ製ビデオ エンドポイントとの統合のためにのみ VCS を使用することを推奨します。これは、二重呼制御によりダイヤル プランおよびコール アドミッション制御が複雑になることを避けるためです。そのため、この章では VCS の詳細については説明しません。VCS の詳細については、『 Cisco Collaboration System 10.x SRND 』または Cisco VCS 製品のドキュメントを参照してください。
Cisco Business Edition 4000(BE4K)は、中小企業向けに最適化された、新しいオンプレミスの完全クラウドマネージ型オーディオ テレフォニー プラットフォームです。Cisco Unified Communications Manager Express(Unified CME)と Cisco Unity Express Virtual(vCUE)を備えた Business Edition 4000 は、最大 200 台のデバイスの手頃な価格の統合 IP テレフォニーおよびボイスメール ソリューションを提供します。Cisco Business Edition 6000 および 7000 と同様に、Business Edition 4000 は、構成済みのハードウェア、インストール済みのライセンス、プリロードされたシスコ コラボレーション アプリケーションの提供により、見積もりと発注のプロセスを簡素化し、迅速な導入を実現します。
Cisco Business Edition 4000 および Cisco Unified CME は、小規模な単一サイト導入と大規模な分散マルチサイト導入向けに呼処理サービスを提供します。Cisco Unified CME は、Cisco Unified CM の集中型呼処理導入でリモート サイトにおいてローカル呼処理をバックアップする機能を提供するための呼処理サービスも提供します。
Cisco Unified Communications Manager(Unified CM)および Cisco TelePresence Video Communication Server(VCS)は、標準のシスコ コラボレーション製品として、または、呼処理サービスおよび管理、会議、コンタクト センターなどのその他のサービスを含むパッケージ化されたコラボレーション ソリューションである Cisco Business Edition 6000 および Cisco Business Edition 7000 から使用可能です。
Cisco Business Edition 6000 および 7000 ソリューションにより、見積もり/発注のプロセスが簡素化され、事前に設定されたハードウェア、事前にインストールされた認可を受けたハイパーバイザ、事前にロードまたはインストールされたシスコ コラボレーション アプリケーションが用意されているため、導入が高速化されます。Cisco Business Edition 6000M および Cisco Business Edition 6000H は、最大で 1,000 人のユーザ向けの導入を対象としています。Cisco Business Edition 7000 は、1,000 人を超えるユーザ向けの導入を対象としています。シスコ コラボレーション アプリケーションの設計およびサイジングは、Cisco Business Edition 6000 では簡素化されています。ただし、Cisco Business Edition 7000 では、通常の Unified CM の設計およびサイジングのガイドラインが適用されます。
仮想化により、複数のシスコ コラボレーションの「サーバ」または「仮想マシン」を 1 つの物理サーバで実行できます。シスコ コラボレーションのサーバまたは仮想マシンは、このドキュメントで VM、ノード、またはインスタンスとも呼ばれています。
このアーキテクチャには、アプリケーションがハードウェア プラットフォーム上で直接動作している従来の導入と比べて、明らかなメリットがあります。たとえば、コスト(サーバ、電力、冷却、ラック スペースのコストなど)を大幅に削減できます。そして、ハードウェア プラットフォームの運用および保守を簡素化できます。仮想化は、物理サーバに直接インストールされ、仮想マシンを管理するハイパーバイザにより実現されます。シスコ コラボレーションに必要なハイパーバイザは、VMware ESXi Hypervisor です。
各仮想マシンには、仮想 CPU、仮想メモリ、仮想ディスクなどの仮想ハードウェア リソースが関連付けられています。これらのリソースは、仮想マシン テンプレートをパッケージおよび配布するオープン スタンダード ベースの方式である Open Virtualization Archive(OVA)を介して配布される事前定義されたテンプレートの各コラボレーション アプリケーションに定義されます。多くのシスコ コラボレーション アプリケーションでは、さまざまなキャパシティ オプションを提供するために、OVA の導入時に複数の VM 設定オプションが使用可能です。シスコ コラボレーション アプリケーションをインストールするときは、正しい仮想ハードウェア リソースを定義するためだけでなく、ホストの物理ディスクによって仮想ディスクに不整合が生じないようにするために(ストレージのパフォーマンスに影響します)、OVA を使用する必要があります。
シスコ コラボレーション呼処理エージェントの仮想化サポートは、次のとおりです。
Cisco Unified Communications アプリケーションの仮想化の設計上および配置上の考慮事項については、次の URL で入手可能な情報を参照してください。
Cisco Unified CM のハードウェア オプションには、3 種類があります。Tested Reference Configuration、Cisco Business Edition 6000 および 7000、仕様ベースのハードウェアです。
TRC は、Cisco Unified Computing System(UCS)サーバに基づいて選択されたハードウェア構成です。固定されたハードウェア構成を持ち、特定のアドバタイズされたパフォーマンス、キャパシティ、アプリケーションが混在するシナリオのためにシスコ コラボレーション アプリケーションでテストおよび検証されています。明確に検証されたインフラストラクチャを必要とする顧客や、必ずしも仮想化の経験があるわけではない顧客を対象としています。
各 TRC のハードウェア構成が明確に定義され、このハードウェア構成から逸脱することは非常に限られています。たとえば、CPU モデルやコア数を変更したり、TRC の RAID 設定を変更すると、サーバ資格が変更されてサーバが TRC として見なされなくなり、仕様ベースのハードウェアとして見なされます。
Cisco Business Edition 6000 および 7000 は、ハードウェア プラットフォーム、仮想化ソフトウェア、シスコ アプリケーションを含むパッケージ化されたコラボレーション ソリューションです。ハードウェア プラットフォームは事前に構成されています(たとえば、ファームウェア、ドライバ、RAID コントローラは工場で構成済みです)。TRC と同様に、ハードウェア プラットフォームは特定のキャパシティとパフォーマンス向けにシスコ コラボレーション アプリケーションでテストおよび検証されています。
Cisco Business Edition 6000 では、BE6000M および BE6000H の 2 つのハードウェア プラットフォーム オプションが使用可能です。Cisco Business Edition 7000 でも、BE7000M および BE7000H の 2 つのハードウェア プラットフォーム オプションが使用可能です。
TRC および Cisco Business Edition 6000 および 7000 ハードウェア プラットフォームの詳細については、 https://www.cisco.com/go/virtualized-collaboration のドキュメントを参照してください。
仕様ベースのハードウェア(単純に「仕様ベース」とも呼ばれます)は、より柔軟なハードウェア構成を提供します。たとえば、Cisco UCS TRC に基づいてプラットフォームを選択したり、CPU モデル、コア数、および RAID 構成を変更したり、iSCSI または NAS ストレージを使用することができます。必要に応じて、シスコ以外のサーバ ベンダーも使用できます。シスコ製品かどうかに関係なく、仕様ベースのハードウェア サーバが、次の『 VMware Compatibility Guide 』に記載されている必要があります。
https://www.vmware.com/resources/compatibility/search.php
仕様ベースのハードウェアはより柔軟なハードウェア構成を提供しますが、一部の要件も満たす必要があります。たとえば、CPU のモデルおよび最小 CPU 速度に関して要件があり、ログおよび統計情報を収集するために vCenter が必要となります。仕様ベースのハードウェアでは、シスコによってシスコ コラボレーション アプリケーションのハードウェア構成が明示的に検証されていない点に注意してください。したがって、コラボレーション アプリケーションはハードウェアの互換性に関する規範的なガイダンスを提供することができず、保証はされません。また、シスコ コラボレーション アプリケーションのパフォーマンスはガイダンスの目的に限定されています( https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-system/115955-uc-specs-tshoot-00.html でトラブルシューティングのテクニカル ノートを参照してください)。
仕様ベースのハードウェアを使用したシスコ コラボレーション アプリケーションのパフォーマンスに関するガイドラインを入手するには、TRC または Cisco Business Edition 6000 および 7000 ハードウェア プラットフォームを参照用に使用します。詳細については、 https://www.cisco.com/go/virtualized-collaboration のドキュメントを参照してください。
Cisco Unified CME は、Cisco 2900、3900、4000 シリーズ ISR などの Cisco サービス統合型ルータ(ISR)で実行されます。Cisco Unified CME は、仮想アプリケーション、またはクラウド サービス ルータ 1000V の一部としては実行されません。Cisco Business Edition 4000 は Cisco 4321 サービス統合型ルータ(ISR)上でのみ実行されます。Cisco Unity Express Virtual(vCUE)を利用するボイスメールは Cisco ISR 4321 のサービス コンテナ内でのみ実行可能で、UCS-E モジュール上では実行できません。
必要な規模、パフォーマンス、および冗長性に応じて、特定の配置に適した呼処理タイプとプラットフォームを決定します。一般に、Unified CM は非常に幅広いキャパシティ オプションと高い可用性を提供し、Cisco Unified CME は低いレベルのキャパシティと冗長性を提供します。冗長性とスケーラビリティの詳細については、呼処理のハイ アベイラビリティおよび呼処理のキャパシティ プランニングを参照してください。
Cisco Unified CME はスタンドアロン呼処理アプリケーションですが、Unified CM はクラスタリングの概念をサポートしています。Unified CM アーキテクチャでは、サーバ ノードのグループを 1 つの呼処理エンティティまたは IP PBX システムとして連携させることができます。このサーバ ノード グループを クラスタ と呼びます。Unified CM サーバ ノードのクラスタは、設計上の制限事項を遵守している限り、IP ネットワークを介して分散していてもかまわず、空間的な冗長性、およびそれに伴う復元性をユニファイド コミュニケーション システムの設計にもたらすことができます。
Unified CM クラスタの内部には、それぞれ固有のサービスを提供するサーバ ノードが存在します。これらの各サービスは、同じサーバ ノード上で他のサービスと共存できます。たとえば、小規模なシステムでは、データベース サービス、呼処理サービス、およびメディア リソース サービスを単一のサーバ ノードで提供できます。クラスタの規模とパフォーマンスを強化する必要が高まった場合は、これらのサービスの多くを専用サーバ ノードに移行する必要があります。
次の項では、Unified CM クラスタを形成しているサーバ ノードが実行する各種の機能について説明し、必要な規模、パフォーマンス、および復元性を達成するようにサーバ ノードを配置する方法について、ガイドラインを示します。
図 9-1 に、複数のサーバ ノードで構成された一般的な Unified CM クラスタを示します。パブリッシャとサブスクライバという、2 つのタイプの Unified CM サーバ ノードがあります。これらの用語は、データベース間の関係をインストール時に定義するために使用されています。
パブリッシャはすべてのクラスタに必要なサーバ ノードであり、図 9-1 に示すように、クラスタごとに 1 つのパブリッシャだけを配置できます。このサーバ ノードは、最初にインストールする必要があります。クラスタ内の他のすべてのサブスクライバに対して、データベース サービスを提供します。パブリッシャ ノードは、コンフィギュレーション データベースに完全な読み取りと書き込みのアクセスができる唯一のサーバ ノードです。
1,250 ユーザを超える大規模なシステムの場合には、管理操作によるテレフォニー サービスへの影響を防止するために、専用パブリッシャを推奨します。専用パブリッシャのノード上で、呼処理または TFTP サービスが提供されることはありません。代わりに、これらのサービスはクラスタ内の他のサブスクライバ ノードによって提供されます。
パブリッシャ用の VM 設定は、クラスタで必要な規模とパフォーマンスを基準として選択する必要があります。パブリッシャは、呼処理サブスクライバと同等のサーバ ノード パフォーマンスを持つものにすることを推奨します。
ソフトウェアを初期インストールしたときに使用可能になるのは、データベース サービスとネットワーク サービスだけです。すべてのサブスクライバ ノードは、パブリッシャにサブスクライブして、データベース情報のコピーを取得します。ただし、Unified CM クラスタの初期化時間を短縮するために、クラスタ内のすべてのサブスクライバ ノードは、初期化時にデータベースのローカル コピーの使用を試みます。これにより、Unified CM クラスタの全体的な初期化時間は短縮されます。すべてのサブスクライバ ノードは、パブリッシャまたは他のサブスクライバ ノードからの変更通知によって、データベースのローカル コピーを更新された状態に保ちます。
図 9-1 に示すように、複数のサブスクライバ ノードが同じクラスタのメンバーになることができます。サブスクライバ ノードには、Unified CM 呼処理サブスクライバ ノード、TFTP サブスクライバ ノード、および会議や保留音(MoH)などの機能を提供するメディア リソース サブスクライバ ノードがあります。
呼処理サブスクライバは、Cisco CallManager サービスが有効になっているサーバ ノードです。このサービスが有効になった時点で、このノードは呼処理機能を実行できるようになります。電話、ゲートウェイ、メディア リソースなどのデバイスが登録やコール発信を実行できるのは、このサービスが使用可能になっているサーバに対してのみです。図 9-1 に示すように、複数の呼処理サブスクライバが同じクラスタのメンバーになることができます。実際、Unified CM は、クラスタごとに最大 8 つの呼処理サブスクライバ ノードをサポートします。
TFTP サブスクライバまたはサーバ ノードは、Unified CM クラスタの一部として、次の 2 つの主要な機能を実行します。
この機能を提供する Cisco TFTP サービスは、クラスタ内の任意のサーバ ノードで有効にできます。ただし、何らかの設定を変更すると、TFTP サービスがコンフィギュレーション ファイルを再生成するため、1,250 ユーザを超えるクラスタでは、他のサービスが影響を受ける場合があります。このため、1,250 ユーザを超えるクラスタまたは頻繁な設定変更を伴う機能を備えたクラスタでは、図 9-1 に示すように、特定のサブスクライバ ノードを TFTP サービス専用にすることを推奨します。
メディア リソース サブスクライバまたはサーバ ノードは、会議や保留音などのメディア サービスをエンドポイントとゲートウェイに提供します。これらのタイプのメディア リソース サービスは、Cisco IP Voice Media Streaming Application サービスによって提供されます。このサービスは、クラスタ内の任意のサーバ ノードで使用可能にできます。
クラスタ内でメディア リソースを実行する場合は、メディア リソース サービスの処理とネットワークに関する要件が追加される場合に備えて、すべてのガイドラインに準拠することが重要です。一般に、マルチキャスト MoH とアナンシエータ サービスには専用のメディア リソース サブスクライバを使用せず、ユニキャスト MoH およびソフトウェア ベースの大規模な会議と MTP に、図 9-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 上では、Cisco Unified CM Assistant、エクステンション モビリティ、Web Dialer などのさまざまなタイプのアプリケーション サービスを使用可能にできます。これらのアプリケーションに関する設計ガイドラインの詳細については、Cisco Unified CM アプリケーションの章を参照してください。Cisco IM and Presence サービスを追加することもできます(コラボレーションのインスタント メッセージングとプレゼンスの章を参照)。
Unified CM クラスタ内に VM 設定を混在させることはできますが、クラスタ内のすべての Unified CM ノードに同じ VM 設定を使用することを推奨します。また、Unified CM パブリッシャに使用する VM 設定が同じクラスタ内で使用されている他の Unified CM VM 設定を下回ることや、バックアップ サブスクライバに使用する VM 設定がプライマリ サブスクライバに使用する VM 設定を下回ることがないように設定することを推奨します。
クラスタ内の VM 設定を混在させる場合は、サポートされる全体のクラスタ キャパシティはクラスタ内の最小の VM 設定に対応するクラスタ キャパシティによって制限されるため、各 VM 設定間のキャパシティの違いを考慮する必要があります。
たとえば、7.5k VM 設定を使用する 1 つの Unified CM 呼処理ペアと、10k VM 設定を使用する 2 つの Unified CM 呼処理ペアを混在させる場合、サポートされる全体のクラスタ キャパシティは、7.5k VM 設定を使用したすべてのノードのクラスタ キャパシティに対応します。この例の 3 つの呼処理ペアについては、クラスタ キャパシティは 22.5k エンドポイント(3 ∗ 7,500)に制限されます。このクラスタ キャパシティの制限をなくすための 1 つのオプションは、別のクラスタを展開し、そのクラスタを SIP トランクと接続することです。
Unified CM クラスタ内にさまざまなタイプのハードウェア プラットフォームを混在させることも許可されていますが、すべての VM 設定がすべてのサーバ ハードウェアでサポートされていないため、VM 設定が混在することにより、クラスタ キャパシティ全体に影響する場合があります(詳細については、Unified CM の VM 設定の混在を参照してください)。また、混在するプラットフォームの一部が Business Edition 6000 の場合には、Business Edition 6000 ソリューション固有のルールを考慮する必要があります。
BE6000M の一部として展開された Unified CM は、クラスタ ノードの数に関係なく 1,000 人のユーザと 1,200 台のデバイスに制限されます。ノードが BE7000 の一部かどうか、および追加ノードがより大きい VM 設定を使用するかどうかにかかわらず、他のノードを追加することができます。これにより冗長性や地理的な分散が提供されますが、BE6000 のサイジング ルールにより、クラスタ キャパシティは増加しません。BE6000M の Unified CM クラスタ キャパシティは、ノードが追加されても 1,000 人のユーザと 1,200 台のデバイスに制限されたままです。BE6000H にも同様の制限が適用され、ノード数に関係なく、最大 1,000 人のユーザと 2,500 台のデバイスに制限されます。
Cisco Business Edition 6000M または 6000H ソリューションの一部でない Small Tested Reference Configuration(TRC)の場合、ノードのキャパシティは 1,000 ユーザまたはデバイスに制限されますが、Unified CM クラスタのキャパシティは 1,000 ユーザまたはデバイスに制限されません。クラスタに複数のノードを追加すると、1,000 を超えるユーザとデバイスをサポートできます。ただし、小規模 TRC ハードウェア プラットフォームでは、1,000 人のユーザ用の VM 構成のみがサポートされています。そのため、小規模 TRC で一部の Unified CM ノードが実行されていて、(Unified CM の VM 設定の混在の項に記載されているように)同じクラスタ内に混在する BE7000 で一部が実行されている場合、サポートされる全体のクラスタ キャパシティは、最小の VM 設定を使用するノード(この場合は 1,000 人のユーザ用の VM 構成)に対応するクラスタ キャパシティによって制限されます。たとえば、1 つの Unified CM 呼処理ペアが小規模 TRC(1,000 人のユーザ用の VM 構成)で実行されていて、別の Unified CM 呼処理ペアが BE7000 で実行されている場合は、1k より大きい Unified CM VM 設定が BE7000 で展開されている場合でも、サポートされる Unified CM クラスタ キャパシティは 2,000 のユーザおよびデバイスに制限されます(2∗1,000)。
別のベンダーからのサーバを混在させることはできますが、これは仕様ベースのハードウェアのポリシーである可能性があり、Unified CM パフォーマンスは、このタイプのプラットフォームの組み合わせでは保証されません。
2 種類の主要なクラスタ内通信(Unified CM クラスタ内の通信)があります(図 9-2 および図 9-3 を参照)。1 つ目は、すべてのデバイス構成情報を含むデータベースを配布するためのメカニズムです(図 9-2 の「データベース レプリケーション」を参照)。コンフィギュレーション データベースは、パブリッシャ ノードに保存され、コピーがクラスタのサブスクライバ ノードに複製されます。データベースの変更のほとんどはパブリッシャで加えられ、サブスクライバ データベースに伝達されます。そのため、クラスタのメンバー全体で設定の一貫性が確保され、データベースの空間的な冗長性が容易になります。
ユーザ方向の呼処理機能に対するデータベースの変更は、エンド ユーザ デバイスが登録されるサブスクライバ ノードで行われます。次にサブスクライバ ノードが、これらのデータベース変更をクラスタにある他のすべてのノードに複製し、ユーザ方向機能に冗長性を提供します(図 9-2 の「呼処理のユーザ方向機能の複製」を参照)。これらの機能には、次のものがあります。
Intra-Cluster Communication Signaling(ICCS)と呼ばれる、もう 1 つのクラスタ内通信は、デバイスの登録、ロケーションの帯域幅、共有メディア リソースなどのランタイム データの伝搬と複製です(図 9-3 を参照)。この情報は、Cisco CallManager サービス(呼処理サブスクライバ)を実行している、クラスタのすべてのメンバー全体で共有されます。クラスタのメンバーと関連ゲートウェイとの間で、コールの最適なルーティングが確保されます。
図 9-3 Intra-Cluster Communication Signaling(ICCS)
Unified CM クラスタ内の各サーバ ノードが内部で動的ファイアウォールを実行します。Unified CM のアプリケーション ポートは、送信元 IP フィルタリングによって保護されます。動的ファイアウォールは、認証済みサーバまたは信頼できるサーバ ノードに対してだけ、これらのアプリケーション ポートを開きます(図 9-4 を参照)。
このセキュリティ メカニズムは、単一の Unified CM クラスタ内のサーバ ノード間だけに適用できます。Unified CM のサブスクライバは、パブリッシャのデータベースにアクセスする前に、クラスタ内で認証されます。クラスタ内通信およびデータベース レプリケーションは、認証済みサーバ ノード間だけで発生します。インストール時にサブスクライバ ノードは、事前共有キー認証メカニズムでパブリッシャに対して認証されます。認証プロセスに必要な手順は次のとおりです。
1. セキュリティ パスワードを使用してパブリッシャ ノードをインストールします。
2. Unified CM Administration を使用することによって、パブリッシャ上にサブスクライバ ノードを設定します。
3. パブリッシャ サーバのインストール時に使用されたのと同じセキュリティ パスワードを使用して、サブスクライバ ノードをインストールします。
4. サブスクライバのインストール後、サーバ ノードは、UDP 8500 を使用する管理チャネル上でパブリッシャとの接続を確立しようとします。サブスクライバは、ホスト名、IP アドレスなどのすべてのクレデンシャルをパブリッシャに送信します。クレデンシャルは、インストール時に使用されたセキュリティ パスワードを使用して認証されます。
5. パブリッシャは、独自のセキュリティ パスワードを使用してサブスクライバのクレデンシャルを確認します。
6. その情報が有効な場合、パブリッシャは、自身の動的ファイアウォール テーブルに、信頼できる送信元としてサブスクライバを追加します。サブスクライバは、データベースへのアクセスを許可されます。
7. サブスクライバは、パブリッシャから他のサブスクライバ ノードのリストを取得します。すべてのサブスクライバが互いに管理チャネルを確立し、メッシュ トポロジが作成されます。
すべての Unified CM クラスタに次のガイドラインが適用されます。
– MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用することを検討してください。
– システムのインストール ログの保存には、仮想フロッピー ソフトメディアを使用します。
– Simplified Message Desk Interface(SMDI)の統合に対する Cisco Messaging Interface(CMI)サービスの代替オプションはありません。
呼処理サービスは、可用性が高くなるように Unified Communications システム内に配置して、1 つの呼処理コンポーネントの障害によってすべての呼処理サービスが使用不可にならないようにする必要があります。
呼処理のプラットフォームは、特定の配置のサイズとスケーラビリティだけでなく、プラットフォーム ハードウェアの冗長性にも基づいて選択する必要があります。
可能な場合は二重化電源を備えたプラットフォームを選択して、1 つの電源の障害によってプラットフォームが失われないようにします。二重化電源を備えたプラットフォームを 2 つの異なる電力源に接続して、1 つの電源回路が故障しただけでプラットフォーム全体に障害が発生することを回避します。二重化電源の使用と無停電電源(UPS)の使用を組み合わせると、電力の可用性は最大になります。二重化電源プラットフォームを実現できない配置でも、建物の電力が必要なレベルの電力の可用性を備えていない状況では、UPS の使用を推奨します。
プラットフォームで障害が発生すると、そのハードウェア プラットフォームで実行しているすべての仮想マシンで障害が発生する可能性があるため、仮想化を導入するときは、ハードウェア プラットフォームのハイ アベイラビリティを提供することがさらに重要になります。可能であれば、同じ物理サーバ上で同様の機能を持つ同じアプリケーションのインスタンスを複数実行することは避けます。代わりに、Cisco UCS B-Series Blade Server を使用している場合は、それらの仮想マシンを複数のサーバに割り振り、可能であれば複数のシャーシにも割り振ります。
IP ネットワークへの接続性も、最大限のパフォーマンスとハイ アベイラビリティにとって重要な考慮事項です。Cisco Unified CME では、ネットワーク接続に最低 2 つ以上のポートを使用します。Unified CM では、ネットワーク接続のハイ アベイラビリティは、複数のアップリンクを介してハイパーバイザ仮想スイッチを設定し、ハードウェア プラットフォーム上で複数の物理ポートを使用することにより実現されます。そのため、OVA 設定に定義された 1 つの仮想 NIC で十分です。たとえば VMware vSphere 仮想スイッチを使用している場合は、スイッチ アップリンクに対して NIC チーミングを設定します。また、複数のこれらのポートを最低 2 台のアップストリーム スイッチに接続して、アップストリーム スイッチで障害が発生したときに復元力を提供します。
最高速度でプラットフォームをネットワークに接続し、最大スループット(UCS B シリーズ プラットフォームを使用する場合は、通常 1 Gbps または 10 Gbps)を確保します。プラットフォームが全二重でネットワークに接続されていることを確認します。
IP ネットワーク接続の速度とデュプレックス モード以外に、このネットワーク接続の復元性も同じように重要です。ユニファイド コミュニケーションの配置は、実際の冗長性に関して、基盤となるネットワーク接続に大きく依存します。このため、復元性が高い方法で基盤となるネットワーク インフラストラクチャを配置および設定することが重要です。可用性の高いネットワーク インフラストラクチャの設計の詳細については、ネットワーク インフラストラクチャの章を参照してください。すべての場合で、インフラストラクチャ内でスイッチまたはルータの障害が発生しても、ほとんどのユーザは配置内で提供されているほとんどのサービスにアクセスできるように、ネットワークを設計する必要があります。
呼処理の可用性を最大にするには、可能な場合は呼処理プラットフォームを別々の建物および別々のネットワーク スイッチに置いて接続し、建物またはネットワーク インフラストラクチャ スイッチの障害が発生したときの呼処理への影響を最小にします。Unified CM 呼処理では、このことは、可能な場合は常に、クラスタ サーバ ノードを LAN または MAN 配置内の複数の建物またはロケーション間で分散させることを意味します。最低限でも、同じロケーション内の異なる物理ネットワーク スイッチ間でネットワーク接続を物理的に分散させることを意味します。
さらに、Cisco Unified CME がスタンドアロンの呼処理エンティティであっても、物理的な分散とこの呼処理エンティティによる冗長性を提供することは、複数の呼処理エンティティを配置する場合にやはり意味を持ちます。そのようなシナリオで可能な場合は常に、Unified CME の各インスタンスをネットワーク内の異なる物理ロケーションにインストールするか、または最低限でも異なるネットワーク スイッチに物理的に接続します。
基盤となる Unified CM クラスタリングメカニズムのため、Unified Communications システムには、ハードウェア プラットフォームのディスクおよび電力コンポーネントの冗長性、物理ネットワーク ロケーション、および接続の冗長性以外にも、ハイ アベイラビリティに関する考慮事項があります。ここでは、呼処理サブスクライバの冗長性の考慮事項、呼処理のロード バランシング、およびその他のクラスタ サービスの冗長性について説明します。
Unified CM には、次の呼処理の冗長性設定オプションまたは冗長性方式があります。
これらの冗長性方式は、Unified CM クラスタ アーキテクチャ内の組み込み登録フェールオーバー メカニズムによって実施され、エンドポイントのプライマリ呼処理サブスクライバ ノードに障害が発生したときに、エンドポイントはバックアップ呼処理サブスクライバ ノードに再登録されます。この登録フェールオーバー メカニズムは、Skinny Client Control Protocol(SCCP)IP Phone のフェールオーバー レート、毎秒約 125 台の登録を実現できます。Session Initiation Protocol(SIP)電話機の登録フェールオーバー レートでは、毎秒約 40 台の登録です。
選択した呼処理の冗長性方式によって、配置の耐障害性だけでなく、アップグレードの耐障害性も決まります。
1:1 冗長性方式では、プライマリ呼処理サブスクライバで複数の障害が発生しても、呼処理機能に影響はありません。それに対して 2:1 冗長性方式では、バックアップ呼処理サブスクライバを共用する 2 つのプライマリ呼処理サブスクライバのうちの 1 つだけで障害が発生した場合、呼処理に影響はありません。ただし、両方のプライマリ サブスクライバに登録されているエンドポイントの合計数と、それら 2 つのプライマリ サブスクライバが処理するトラフィック量が、バックアップ サブスクライバのキャパシティ制限以内である場合、バックアップ サブスクライバで両方のプライマリ サブスクライバの障害を処理できます。
(注) 2 つのプライマリ サブスクライバの合計キャパシティ使用率がバックアップ サブスクライバのキャパシティを超える場合は、2:1 冗長性を導入しないでください。たとえば、呼処理キャパシティまたはエンドポイント キャパシティ使用率が両方のプライマリ サブスクライバで 50 % を超えると、両方のプライマリ サブスクライバに障害が発生した場合、バックアップ サブスクライバは呼処理サービスを適切に処理できなくなります。これらのシナリオでは、バックアップ サブスクライバ システムのキャパシティが超過したことが原因で、一部のエンドポイントが登録できない、一部の新しいコールを処理できない、一部のサービスおよび機能が適切に機能しないなどの状況が生じる可能性があります。
同様に、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 ソフトウェアを実行しているサブスクライバ ノードにデバイスが登録される期間(登録フェールオーバー期間を除く)がありません。これらの手順はすべて Cisco Prime Collaboration を使用して自動化することができます。
2:1 冗長性方式では、クラスタ内のサーバ ノード数を少なくできますが、アップグレード時の登録フェールオーバーの発生頻度が多くなり、アップグレードの全体的な時間および特定のエンドポイントの呼処理サービスが使用不可になる時間が長くなります。プライマリ呼処理サブスクライバのペアごとにバックアップ呼処理サブスクライバは 1 つだけであるため、1 つのバックアップ呼処理サブスクライバのオーバーサブスクリプションを回避するために、一度にペアのうちの 1 つのプライマリ呼処理サブスクライバだけで新しいバージョンへリブートできます。その結果、各ペアの最初のプライマリ呼処理サブスクライバが新しいバージョンに切り替わった後、エンドポイント登録をバックアップ サブスクライバから新しくアップグレードされたプライマリ サブスクライバに移動するための時間が発生し、その後で 2 番めのプライマリ サブスクライバでのエンドポイント登録をバックアップ サブスクライバに移動して新しいバージョンへリブートできるようになります。この間、2 番めのプライマリ呼処理サブスクライバのエンドポイントは、バックアップ サブスクライバへの再登録中に使用不可になるだけでなく、新しいバージョンを実行するノードに再登録されるまでは、すでにアップグレード済みの他のサブスクライバ ノード上のエンドポイントに到達することもできません。
(注) アップグレードを行う前に、ディザスタ リカバリ フレームワークを使用して、Unified CM およびコール詳細レコード(CDR)データベースを外部ネットワーク ディレクトリにバックアップすることを推奨します。このようにしておくと、アップグレードが失敗した場合のデータ損失を防止できます。
(注) Unified CM クラスタのアップグレードでは、一部またはほとんどのデバイスから一時的に登録サービスおよび呼処理サービスが失われるため、アップグレードは前もって計画し、定期保守時に実装する必要があります。1:1 冗長性方式を選択すると、デバイスのダウンタイムおよびサービス停止を最小にできますが、それでも、一部またはすべてのユーザが呼処理サービスを使用できない時間が発生します。
Unified CM のアップグレードの詳細については、次の URL で入手可能なインストールおよびアップグレード ガイドを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-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 ルータの Cisco Unified 拡張 SRST(E-SRST)は、中央の Unified CM クラスタへの接続が失われると、バックアップ呼処理機能を提供するためにリモート サイトで使用することもできます。E-SRST は、ルータの通常の SRST で使用できる機能よりも多くのテレフォニー機能を IP Phone に提供します。ただし、Unified E-SRST のエンドポイント キャパシティは、通常は基本的な SRST よりも低下します。SRST および E-SRST の両方が Cisco Unified SRST Manager でサポートされています。これは、SRST および E-SRST で Unified CM から設定を同期するので、ブランチの SRST または E-SRST ルータに必要な手動の設定が減り、ユーザが SRST および通常モードでも同様のコール操作を行えるようにします。
選択した冗長性方式に応じて(呼処理の冗長性を参照)、呼処理サブスクライバは、プライマリ(アクティブ)サブスクライバまたはバックアップ(スタンバイ)サブスクライバのどちらかになります。ロード バランシングを実装する場合は、サブスクライバがプライマリ サブスクライバとバックアップ サブスクライバの両方を兼ねることもあります。クラスタの設計を計画するときは、通常は呼処理サブスクライバにこの機能を割り当てます。大規模なクラスタや高性能クラスタでは、呼処理サービスをパブリッシャおよび TFTP サブスクライバ ノード上で使用可能にしないでください。1:1 冗長性方式は、プライマリ サブスクライバとバックアップ サブスクライバの専用ペアを使用します。2:1 冗長性方式は、1 つのバックアップ サブスクライバを共用するプライマリ サブスクライバのペアを使用します。
次の図では、Unified CM で呼処理の冗長性を実現するための一般的なクラスタ構成を示しています。
図 9-5 では、利用できる 2 つの基本的な冗長性方式を示しています。どちらの場合でも、バックアップ サーバ ノードは、障害の発生するプライマリ呼処理サーバ ノード 1 台分以上の処理能力を備えている必要があります。2:1 冗長性方式の場合、バックアップ サーバは、個々の配置の要件に応じて、障害の発生する呼処理サーバ ノード 1 台分、または両方のプライマリ呼処理サーバ ノードに相当する処理能力を備えている必要があります。キャパシティ サイジングと VM 設定の選択の詳細については、呼処理のキャパシティ プランニングの項を参照してください。
(注) 2:1 冗長性では、バックアップ サブスクライバが過負荷の状態になることがあるので、10,000 人のユーザ用の VM 構成でサポートされません。
図 9-6 に示した 5 つは、すべて 1:1 冗長性のオプションを示しています。図 9-7 に示した 5 つは、すべて 2:1 冗長性のオプションを示しています。どちらの場合も、1,250 よりも少ないユーザをサポートし、Cisco Business Edition 6000 の Unified CM の展開を含むクラスタでは、オプション 1 を使用します。オプション 2 ~ 5 は、それぞれの冗長性方式でクラスタを徐々に拡張した様子を示しています。正確な規模は、選択したハードウェア プラットフォームや必要なハードウェア プラットフォームによって異なります。
これらの図では、パブリッシャと呼処理サブスクライバだけを示していることに注意してください。TFTP やメディア リソースなどの他のサブスクライバ ノードは示していません。
(注) Unified CM グループあたり最大 3 つの呼処理サブスクライバを定義できます。追加のバックアップ用に 3 次サブスクライバを追加すると、上記の冗長性方式は 2:1:1 または 1:1:1 冗長性に拡張されます。ただし、WAN を介したクラスタリングの展開(リモート フェールオーバー配置モデルを参照)で 3 次サブスクライバ ノードを使用する場合を除き、リモート サイトに設置するエンドポイント デバイスには 3 次サブスクライバの冗長性は推奨しません。エンドポイントが 3 次サブスクライバへの接続性をチェックする必要があると、SRST へのフェールオーバーがさらに遅延するためです。3 次サブスクライバは、クラスタ内の呼処理サブスクライバの最大数に対してもカウントされます(8 つの呼処理サブスクライバ ノード)。
図 9-6 または図 9-7 では示していませんが、シングルノード クラスタを配置することもできます。シングルノード クラスタのエンドポイント設定および登録が 1,000 を超えないようにする必要があります。シングル ノード構成では、バックアップ呼処理サブスクライバがないため、クラスタの冗長性メカニズムはありません。このようなタイプの配置では、冗長性メカニズムとして Survivable Remote Site Telephony(SRST)を使用して、Unified CM が使用できない際に最低限の呼処理サービスを提供する必要があります。
1:1 冗長性方式の Unified CM クラスタでは、プライマリ呼処理サブスクライバとバックアップ呼処理サブスクライバ間で、デバイス登録および呼処理サービスのロード バランシングを行うことができます。
通常、プライマリが使用可能な場合、バックアップ サーバ ノードに登録されたデバイスはありません。このことにより、所定の時間に呼処理の負荷を処理するプライマリ呼処理サブスクライバ ノードは最大で 4 つであるため、配置のトラブルシューティングは容易になります。さらに、Unified CM の冗長性グループとデバイス プールの数を減らすことにより、構成が簡素化される可能性もあります。
ロードバランスされた配置では、Unified CM の冗長性グループとデバイス プールの設定値を使用して、デバイス登録と呼処理にかかる負荷の半分までをプライマリ サブスクライバからセカンダリ サブスクライバに移すことができます。この方法で、各プライマリおよびバックアップ呼処理サブスクライバ ペアは、この呼処理サブスクライバ ペアによってサービスを提供される全デバイスの半数に、デバイス登録および呼処理サービスを提供します。これは、50/50 ロード バランシングと呼ばれます。50/50 ロード バランシング モデルには、次の利点があります。
50/50 ロード バランシングを計画するには、ロード バランシングを使用しない場合のクラスタのキャパシティを計算し、次に、デバイスおよびコールの量に基づいて、負荷をプライマリ サブスクライバとバックアップ サブスクライバに分散します。プライマリ サーバ ノードやバックアップ サーバ ノードの障害に対処できるようにするには、プライマリとセカンダリのサブスクライバの合計負荷が、サブスクライバ ノード 1 台分の負荷を超えないようにします。
(注) 50/50 ロード バランシングが設定された Unified CM クラスタのアップグレード中、バックアップ呼処理サブスクライバのアップグレードによって、そのサブスクライバに登録されているデバイス(プライマリ サブスクライバとバックアップ サブスクライバのペアによってサービスを提供される全デバイスの半数)は、プライマリ呼処理サブスクライバにフェールオーバーします。
大規模な Unified CM クラスタには複数の専用 TFTP サブスクライバ ノードを配置して、TFTP サービスの冗長性を提供することを推奨します。通常は 2 つの TFTP サブスクライバで十分ですが、クラスタに 3 つ以上の 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 統合アプリケーションは、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 ロード バランシングを使用する場合は、これらを次のように設定します。
上の例は、サブスクライバ A 上の CTI Manager で障害が発生した場合の冗長性を備えており、IVR コールの負荷を 2 台のサーバ ノードに分散することもできています。この方法では、Unified CM サブスクライバ ノードの障害による影響も最小限に抑えることができます。
CTI および CTI Manager の詳細については、コンピュータ テレフォニー インテグレーション(CTI)を参照してください。
仮想化を使用する場合、物理サーバ間にわたる Unified CM サーバ ノードのインストールと常駐というサーバ ノードの仮想的特徴があるため、冗長性に関する考慮事項があります。
図 9-8 に示すように、たとえば、Unified CM を配置して最大レベルの呼処理の冗長性を確保する場合は、次のガイドラインに従ってください。
図 9-8 UCS での Unified CM サーバ ノードの分散
シャーシでブレード サーバを使用する場合(たとえば、Cisco UCS 5100 ブレード シャーシでは B シリーズ ブレード サーバ)、サブスクライバ ノード インスタンスを複数のブレードに分散させる以外に、複数のブレード シャーシにサブスクライバ ノード インスタンスを分散させて、冗長性と拡張性を追加できます。
仮想マシンのホスト リソースの冗長性とプロビジョニングの詳細については、 https://www.cisco.com/go/virtualized-collaboration にあるドキュメントを参照してください。
Cisco Business Edition 6000M、Cisco Business Edition 6000H、Cisco Business Edition 7000 では、追加の Cisco Unified CM ノードのクラスタリングによりハイ アベイラビリティが提供されます。追加の Business Edition サーバは、呼処理のほか、その他のアプリケーションおよびサービスに対するハイ アベイラビリティを提供するために配置できます。
(注) WAN 配置でのクラスタリングと同様に、追加の冗長性と地理的な分散、あるいはそのいずれかを提供するために、2 台を超える物理サーバをクラスタリングできます。ただし、Cisco Business Edition 6000 では、サーバの追加により冗長性のみが提供され、キャパシティは増加しません。たとえば、BE6000M と BE6000H では、クラスタ全体でユーザの合計数は 1,000 を超えることができません。この制限値を超える配置は、標準の Unified CM クラスタと見なされます。このため、展開は標準の Unified CM のハイ アベイラビリティ設計ガイダンスに従う必要があります(Unified CM のハイ アベイラビリティを参照)。Cisco Business Edition 7000 では、キャパシティは 1,000 ユーザに制限されていません。正確には、標準アプリケーションのキャパシティ プランニングおよび設計ルールが適用されます。
呼処理のキャパシティ プランニングは、ユニファイド コミュニケーションの配置を成功させるために重要です。このセクションでは、Cisco Business Edition 6000 または 7000 の一部であるかどうかに関係なく、Cisco Unified CM のキャパシティ プランニングについて説明します。また、Cisco Business Edition 4000 および Unified CME も扱います。
Unified CM のキャパシティは、ハードウェア プラットフォーム、VM 設定、展開要件によって異なります。また、Unified CM が Cisco Business Edition 6000 の一部として展開されているかどうかによっても異なります。 表 9-2 に、一般的な Unified CM のキャパシティ制限を示します。
|
|
|
|
---|---|---|---|
ノードごとに最大 10,000、クラスタごとに最大 40,0001 |
|||
ノードごとに最大 10,000、クラスタごとに最大 40,000 1 |
|||
製品マニュアルのキャパシティ情報2 |
製品マニュアルのキャパシティ情報 2 |
製品マニュアル、SRND ガイドライン、Cisco Collaboration Sizing Tool3 |
Cisco Business Edition 6000 では、Unified CM は特定の VM 設定で展開され、Unified CM キャパシティは固定されます。Cisco Unified CM キャパシティ プランニングはシンプルで、Cisco Collaboration Sizing Tool には依存しません。
Cisco Business Edition 6000M で展開された Unified CM では、最大 1,000 のユーザ、1,200 のデバイス、5,000 の BHCA がサポートされます。Business Edition 6000H では、最大 1,000 のユーザ、2,500 のデバイス、5,000 の BHCA がサポートされます。
BE6000 では、ハイ アベイラビリティを提供するためのノードまたはハードウェア プラットフォームの追加がサポートされていますが、これによりキャパシティは増加しません。Business Edition 6000 に固有の VM 設定を使用する必要があります。2,500、7,500、または 10,000 ユーザのためのより大きな VM 設定は、Business Edition 6000 では使用できません。
Business Edition 6000 の一部として展開された Unified CM には、いくつかの追加の制限事項があります。たとえば、Cisco Business Edition 6000M/H では、最大 50 のサイトと最大 100 のコンタクト センター エージェントがサポートされています(詳細については、 https://www.cisco.com/go/be6000 で利用可能な Cisco Business Edition 6000 の製品マニュアルを参照してください)。これらの要件を満たすことができず、ユーザ数が 1,000 を下回る場合には、Cisco Business Edition 6000M/H のキャパシティ プランニングに対して別のアプローチを取ることができます。Business Edition 6000 に固有の固定されたキャパシティに依存する代わりに、製品マニュアルのサイジングのガイドライン、この SRND、Cisco Collaboration Sizing Tool に基づいて、Business Edition 7000 および企業 Unified CM と同じ方法でサイジングを行うことができます。サイジング ツールを使用するときは、1,000 人のユーザ用の VM 構成を選択する必要があります。
Cisco Business Edition 7000 または(Business Edition 以外の)企業バージョンの Cisco Unified CM では、さまざまな VM 設定を、さまざまな対応するキャパシティとともに使用することができ、ノードを追加するとキャパシティが増加します。キャパシティ プランニングは、このドキュメントのガイドラインと Cisco Collaboration Sizing Tool に基づいて行います。ただし、 Cisco Preferred Architecture for Enterprise Collaboration CVD ( https://www.cisco.com/go/pa で利用可能)に簡素化されたキャパシティ プランニング方法が説明されています。Unified CM 展開のユーザまたはデバイスの数が 10,000 未満で(いずれかの制限に先に到達)、特定のサイジングの前提条件が満たされている場合に、この簡素化されたサイジング方法を使用することができます。サイジングの前提条件を満たすことができない場合は、簡素化されたキャパシティ プランニングを使用することはできず、製品マニュアルのガイドライン、この SRND、Cisco Collaboration Sizing Tool に基づく通常のキャパシティ プランニングを代わりに行う必要があります。サイジング ツールではさらに多くのパラメータが考慮されます。たとえば、電話のタイプ(SCCP、SIP、またはモバイル)や電話のセキュリティ モードが考慮されます。これはより複雑なサイジング プロセスですが、特定の展開に対してカスタマイズできます。
一部の Unified CM 機能の利用を可能にしたり増やしたりすると、システムの呼処理機能に影響を与える可能性があり、全体的なキャパシティを低下させる場合もあります。これらの機能には、トレース、コール詳細レコード、複雑なダイヤル プラン、および Unified CM プラットフォーム上に共存するその他のサービスが含まれます。複雑なダイヤル プランには、複数のライン アピアランス、多くのパーティション、コーリング サーチ スペース、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート リスト、自動転送、共存サービス、およびその他の共存アプリケーションが含まれています。こうした機能はすべて、Unified CM システム内の追加リソースを消費します。
次の手法を使用して、システム パフォーマンスを向上させることができます。
多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大きなダイヤル プランを持つ Unified CM クラスタでは、Cisco CallManager サービスの初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、システム初期化タイマー(Unified CM サービス パラメータ)を変更して、設定を初期化するための時間を追加できます。システム初期化時間の詳細については、Unified CM Administration の サービス パラメータ に関するオンライン ヘルプを参照してください。
次のキャパシティのガイドラインは、Cisco Business Edition 7000 の一部である Cisco Unified CM、または Business Edition 以外の Cisco Unified CM に適用されます。
サイジングの制限や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明など、Unified CM キャパシティ プランニングの考慮事項の詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。
メガクラスタ という用語は、拡張性をさらに増大させることが可能な特定の Unified CM 配置を定義および識別します。メガクラスタでは、追加の Unified CM サブスクライバ ノードのサポートにより、さらに多くのデバイス キャパシティが提供されます。メガクラスタごとに最大 8 つの Unified CM サブスクライバ ペア(1:1 冗長性)を設定でき、これにより、最大で 80,000 台のデバイスを使用できます。
また、顧客が単純に非ローカルの冗長性を備えた呼処理機能を必要としている場合に、Survivable Remote Site Telephony(SRST)を使用せずにメガクラスタを展開し、標準クラスタ展開で可能な最大 8 サイトを超えて、メガクラスタあたり最大 16 の Unified CM サブスクライバ ノードまで拡張できます。たとえば、12 のロケーションがある大きな病院で、各ロケーションに 1,000 台のデバイスしかないとします。この合計 12,000 というデバイス数だけでいうと、標準クラスタの最大デバイス キャパシティが 40,000 であるため、標準クラスタで提供できます。しかし、この場合で必要なのは、デバイス キャパシティの追加ではなく、Unified CM サブスクライバの追加です。これにはメガクラスタ配置が必要です。この例では、Unified CM サブスクライバ ノードは各ロケーションに配置され、各 Unified CM サブスクライバは、ローカル エンドポイントのプライマリ サブスクライバとして、また、別のロケーションのリモート エンドポイントのバックアップ サブスクライバとして動作できます。
メガクラスタ配置を検討する場合、キャパシティに影響を与える主な領域は次のとおりです。
標準クラスタに関連する他のすべてのキャパシティがメガクラスタにも適用されます。メガクラスタ導入のサポートは、Cisco Collaboration Sizing Tool の結果の送信など、詳細設計の確認が成功した後でのみ与えられることに注意してください。Cisco Collaboration Sizing Tool および Unified CM 標準クラスタとメガクラスタのサイジングの詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。
メガクラスタ配置に関しては複雑な考慮事項が多数あるので、このような配置の実現を望むお客様は、シスコのアカウント チーム、シスコ アドバンスド サービス、または認定された Cisco Unified Communications パートナーに関与してもらう必要があります。
(注) 特に明記されていない限り、この SRND 内に含まれる呼処理配置に関連するすべての情報(キャパシティ、ハイ アベイラビリティ、一般的な設計上の考慮事項など)は、標準クラスタにのみ適用されます。
呼処理サイジングの詳細や、システム サイジング、キャパシティ プランニング、および配置の考慮事項に関する詳しい説明については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。
Cisco Business Edition 4000 は、最大で 200 のエンドポイントをサポートします。詳細については、コラボレーション ソリューション サイジング ガイダンスの章および次の Web サイトにある Business Edition 4000 のドキュメントを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/business-edition-4000/index.html
Unified CME を配置する場合、必要となるサポート対象エンドポイント数という観点で、目的に合ったキャパシティを提供する Cisco IOS ルータ プラットフォームを選択することが重要です。また、Unified CME ルータが、呼処理以外のサービス(IP ルーティング、DNS ルックアップ、Dynamic Host Configuration Protocol(DHCP)アドレス サービス、VXML スクリプトなど)を提供する場合は、プラットフォームのメモリ キャパシティも考慮する必要があります。
Unified CME は、単一の Cisco IOS プラットフォーム上で最大 450 エンドポイントをサポートできます。ただし、各ルータ プラットフォームのエンドポイントのキャパシティは、システムのサイズによって異なります。Unified CME は Cisco Collaboration Sizing Tool ではサポートされないため、次の Web サイトで入手可能な Unified CME の製品データ シートに記載されているキャパシティ情報に従う必要があります。
https://www.cisco.com/c/en/us/products/unified-communications/unified-communications-manager-express/datasheet-listing.html
シスコの呼処理を配置する際は、次の設計上の推奨事項およびガイドラインに従ってください。
– MoH ライブ オーディオ ソース フィードの場合は、ライブ オーディオ ソース接続に Cisco IOS ベースのマルチキャスト MoH を使用することを検討してください。
– システムのインストール ログの保存には、仮想フロッピー ソフトメディアを使用します。
(注) BE6000 展開のために 2 台を超えるサーバをクラスタ化して、追加の冗長性や地理的な分散を提供することができます。ただし、キャパシティ制限は増加しません。たとえば、クラスタ全体のユーザの総数は、BE6000M または BE6000H では 1,000 を超えることはできません。
Cisco コンピュータ テレフォニー インテグレーション(CTI)を利用すると、Cisco Unified CM で使用可能な豊富なフィーチャ セットだけでなく、サードパーティ製のアプリケーションも使用できるようになります。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 IP デバイスをリモート制御するように設定された Cisco Jabber は、呼制御アプリケーションのよい例です。
これらは、Cisco IP デバイスをモニタおよび制御するすべての CTI アプリケーションです。Cisco Unified Contact Center Enterprise は、エージェントのステータスをモニタして、エージェント デスクトップを介してエージェント電話機を制御するため、モニタと制御を兼ね備えたアプリケーションのよい例です。
(注) ここでモニタリング アプリケーション、呼制御アプリケーション、モニタリング + 呼制御アプリケーションの違いを列挙しましたが、この細かな違いはアプリケーション開発者には見えないようになっています。Cisco CTI を使用するすべての CTI アプリケーションは、モニタリングおよび制御の両方に有効です。
CTI リモート デバイスにより、従来の PSTN 電話機、携帯電話、サードパーティ電話、またはサードパーティ PBX に接続されている電話機などの、CTI をサポートしない電話機上のモニタリング機能および制限された呼制御機能を CTI アプリケーションが持つことができるようになります。
Cisco CTI は、次のコンポーネントで構成されます(図 9-9 を参照)。これらは互いに対話し、Cisco Unified CM で使用可能なテレフォニーフィーチャ セットを各アプリケーションで利用できるようにします。
アプリケーションを認証および許可すると、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 を介したクラスタリングを採用した配置では、次の 2 つのシナリオがサポートされます。
このシナリオでは、CTI アプリケーションとそれに関連付けられた CTI Manager が WAN の一方の側(サイト 1)に配置され、Unified CM サブスクライバに登録されるモニタおよび制御対象のデバイスが他方の側(サイト 2)に配置されます。WAN を介したクラスタリングのラウンドトリップ時間(RTT)は、現在サポートされている限度値 80 ms を超えることはできません。CTI トラフィックに必要な帯域幅を計算するには、ローカル フェールオーバー配置モデルにある公式を使用します。この帯域幅は、ローカル フェールオーバー配置モデルの説明に従って計算した Intra-Cluster Communication Signaling(ICCS)帯域幅や、音声に必要な帯域幅(RTP トラフィック)とは別に必要であることに注意してください。
このシナリオでは、CTI アプリケーションが WAN の一方の側(サイト 1)に配置され、関連付けられた CTI Manager が他方の側(サイト 2)に配置されます。このシナリオでは、CTI アプリケーション開発者またはプロバイダーの責任において、アプリケーションが実装された RTT に適応できるかどうかを確認します。場合によっては、アプリケーションが CTI Manager と同じ場所にある場合よりも、フェールオーバー時間およびフェールバック時間が長くなることがあります。このような場合、アプリケーション開発者またはプロバイダーは、そのような状況におけるアプリケーションの動作に関するガイダンスを示す必要があります。
(注) WAN を介した TAPI および JTAPI のサポートは、アプリケーションに依存します。ユーザとアプリケーション開発者またはプロバイダーの両者が、使用するアプリケーションに WAN を介したクラスタリングが含まれる配置との互換性があることを確認する必要があります。
サポートされている CTI 制御デバイスの最大数は、クラスタごとに 40,000 です。プラットフォームごとのノードおよびクラスタの CTI キャパシティや、CTI リソースの計算式および例など、CTI のキャパシティ プランニングの詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。
CTI Manager は、Unified CM クラスタ内の少なくとも 1 つ(おそらくすべて)の呼処理サブスクライバで有効にする必要があります。クライアント側のインターフェイス(TAPI TSP または JTAPI クライアント)では IP アドレスを 2 つずつ使用できます。これらの IP アドレスは、CTIM サービスを実行している Unified CM サーバ ノードを指します。CTI アプリケーションの冗長性を確保するため、図 9-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 アプリケーションは、図 9-12 に示すように、2 つの CTI Manager に同時に接続できます。
図 9-13 は、このタイプの Cisco Unified Contact Center Enterprise(Unified CCE)の設定例を示しています。このタイプの設定には、次の特性があります。
図 9-13 Cisco Unified Contact Center Enterprise での CTI の冗長性
図 9-14 は、このタイプの Cisco Unified Contact Center Express(Unified CCX)の設定例を示しています。このタイプの設定には、次の特性があります。
図 9-14 Cisco Unified Contact Center Express での CTI の冗長性
アプリケーションの作成に関するガイダンスとサポートについて、アプリケーション開発者は次の Web サイトの Cisco Developer Network(DevNet)で相談してください。
複数の Unified CM クラスタを 1 つに統合するか、Cisco TelePresence Video Communication Server(VCS)と Unified CM クラスタを統合するには、Cisco Unified CM Session Management Edition(SME)を使用します。SME は、マルチサイト分散型呼処理配置で推奨されるトランクとダイヤル プランの集約プラットフォームです。SME は基本的に、トランク インターフェイスだけを使用し、IP エンドポイントを使用しない Unified CM クラスタです。このクラスタには、 リーフ システムと呼ばれる、複数のユニファイド コミュニケーション システムを集約できます。
また、Unified CM Session Management Edition を使用して、PSTN 接続、PBX、集中型のユニファイド コミュニケーション アプリケーションなど、サードパーティのユニファイド コミュニケーション システムに接続できます。
SME の詳細については、Unified CM Session Management Editionの項を参照してください。
複数の呼処理エージェントの直接的統合も可能です。この項では、SIP トランキング プロトコルを使用している Cisco Unified CM と Cisco Unified Communications Manager Express(Unified CME)に関して、マルチサイト IP テレフォニー配置における相互運用性およびインターネットワーキングの要件について説明します。ここでは、Unified CM の制御する電話機と Unified CME の制御する電話機との間での推奨する配置を中心に説明します。
Cisco Unified CM および Cisco Unified Communications Manager Express(Unified CME)は、H.323 を使用して統合することもできますが、ここではこの統合について詳しく説明しません。H.323 統合の詳細については、次の Web サイトで入手可能な『 Cisco Collaboration 9.x SRND 』を参照してください。
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 トランクを使用するための最も一般的な設計シナリオとベスト プラクティスを紹介します。
一般に、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 の製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-express/tsd-products-support-series-home.html
SIP トランク経由で Unified CM に接続すると、Unified CME は Unified CM のコールを自動検出しません。デフォルトでは、Unified CME は常に、コール転送の SIP Refer メッセージまたは自動転送の SIP 302 Moved Temporarily メッセージを使用して、コールをリダイレクトしようとします。リダイレクトが失敗すると、Unified CME はヘアピン コールを試みます。
Unified CM では G.711 形式と G.729 形式の両方で MoH ストリームを有効にできますが、Unified CME で MoH をストリームできるのは G.711 形式のみです。そのため、保留になったコールの MoH オーディオを Unified CME で制御する場合は、G.711 MoH ストリームと G.729 コール レッグの間でトランスコーディングするためのトランスコーダが必要です。
インスタント会議とパーマネント会議の両方に、ハードウェアの DSP リソースが必要です。SIP、H.323、PSTN のいずれを経由して接続している場合でも、Unified CM 電話機と Unified CME 電話機は、ネットワークから到達できる限り、インスタント会議に招待または追加されて、会議の参加者になることができます。アクティブな会議のセッション中にコールを保留にしても、その会議のセッションの参加者には音楽は聞こえません。
インスタント会議とパーマネント会議に必要でサポートされる DSP リソースと、会議に参加できる最大人数については、次の Web サイトで入手可能な Unified CME の製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-express/tsd-products-support-series-home.html
Unified CM は、SIP インターフェイスを使用する Unified CME と直接通信できます。図 9-15 に、SIP トランクを使用して Unified CM が Cisco Unified CME と直接ネットワーク接続されている Cisco Unified Communications マルチサイト配置を示します。
図 9-15 SIP トランクを使用して Unified CM と Unified CME を接続したマルチサイト配置
図 9-15 に示した配置モデルを使用する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。
この項ではまず、一部の主要な領域における 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 voip で no supplementary-service sip moved-temporarily コマンドか no supplementary-service sip refer コマンドを実行します。
次の例は、付加サービスが無効になっているときのコール フローを示しています。
Unified CME は Unified CM に SIP 302 Moved Temporarily メッセージを送信しませんが、Unified CM 電話機 B と電話機 C の間でコールをヘアピンします。
Unified CME は Unified CM に SIP Refer メッセージを送信しませんが、Unified CM 電話機 B と電話機 C の間でコールをヘアピンします。
– Unified CM と Unified CME はどちらも、OOD-Refer 機能が有効になるよう設定する必要があります。
– 保留、転送、および会議は、OOD-Refer トランザクション中はサポートされませんが、Unified CME によってブロックされることもありません。
– コール転送がサポートされるのは、OOD-Refer コールが接続状態になった後のみで、コールの接続前はサポートされません。そのため、接続前はコールの transfer-at-alert はサポートされません。
(注) 複数の PSTN 接続(Unified CM に 1 つと Unified CME に 1 つ)が存在する場合、PSTN エンドポイントに対する Unified CM エンドポイントと Unified CME エンドポイント間の完全在席転送は失敗します。複数の PSTN 接続を使用する場合にはブラインド転送の使用を推奨し、この設定は telephony-service で transfer-system full-blind として行います。