Chapter 1. Cisco Unified Contact Center ソリューション

- Contact Center Enterprise ソリューション

- Contact Center Enterprise ソリューションの比較

Contact Center Enterprise ソリューション

Note

このドキュメントの最初の 4 章は、3 つの Contact Center Enterprise ソリューションの詳細を確認したいユーザ向けです。

- Packaged Contact Center Enterprise

- Cisco Hosted Collaboration Solution for Contact Center

- Unified Contact Center Enterprise

Unified CCE に特化した設計上の考慮事項およびガイドラインに関する情報は、残りの章を参照してください。

Cisco コンタクト センターのビジネス ソリューションは、さまざまなビジネス ニーズに対応するために複数の展開モデルをサポートしています。ニーズに合った導入モデルを選択します。

Cisco では以下の企業向けコンタクト センターのソリューションを提供しています。

- Cisco Packaged Contact Center Enterprise ソリューション: 最大で 12,000 人までのマルチチャネルエ ージェント向けの設計済ソリューション

- コンタクト センター向け Cisco Hosted Collaboration Solution: 最大 24,000 人までのマルチチャネル エージェント向けクラウドコンタクト センターソリューションを提供しているサービス プロバイダー向け

- Cisco ユニファイドコンタクト センターのエンタープライズ ソリューション: 最大 24000 のマルチチャンネルエージェントのスケールとフレキシビリティが必要な企業のお客様向け

すべてのコンタクト センターのエンタープライズ ソリューションは、高可用性とソリューションの保守性を実現するための冗長アーキテクチャを使用します。これらは、以下の包括的な機能セットを提供します。

- コール処理およびコール制御

- Web チャット、 E メール、およびコールバック

- ソーシャル メディアのモニタリング

- リッチ VRU およびルーティング スクリプト

- インタラクティブ音声およびビデオ対応ユニット

- 音声録音およびビデオとストリーミング録画

- エージェントの選択とキューイング

- Web ベースのエージェントおよびスーパーバイザ デスクトップ

- 包括的なレポート

- Packaged Contact Center Enterprise

- Hosted Collaboration Solution for Contact Center

- Unified Contact Center Enterprise

Packaged Contact Center Enterprise

Cisco Packaged Contact Center Enterprise（Packaged CCE）は事前定義された展開です。

要件がソリューションの境界に適合する場合は、Packaged CCE により展開の一部の主要機能がシンプルになります。シンプルな管理インターフェイス、ハードウェア設置面積の減少、インストール時間の短縮によるメリットが得られます。ソリューションは、同時に 12,000 のアクティブ エージェントをサポートします。

Related Concepts

Packaged CCE ソリューションのアーキテクチャ

Hosted Collaboration Solution for Contact Center

Contact Center 版 Cisco Hosted Collaboration Solution（Cisco HCS for Contact Center）は、エンド カスタマーにホステッド コンタクト センター サービスを提供するサービス プロバイダー向けに設計されています。Cisco HCS for Contact Center を展開すると、小規模から大規模のエンド カスタマーをサポートすることが可能です。サービス プロバイダーは、エンド カスタマーに対してソリューションを運用します。Contact Center Enterprise ソリューションにより、エンド カスタマーは Cisco Hosted Collaboration Solution のアプリケーションとサービスを利用することができます。Cisco HCS for Contact Centerを使用すると、テナント全体に渡る共有集約レイヤおよび管理レイヤによって、CUBE、ASA、Unified CCDM、UCDM、Prime Collaboration Assurance など、Contact Center Enterprise ソリューションの機能をクラウド サービスとして市場に提供できます。

Cisco HCS for Contact Center

Related Concepts

Cisco HCS for Contact Center ソリューションのアーキテクチャ

Unified Contact Center Enterprise

Cisco Unified Contact Center Enterprise（Unified CCE）は、業界トップクラスのルーティング機能と CTI 機能を備えています。Unified CCE には、シングルサイトまたはマルチサイト環境をサポートするためのオプションがあります。

Unified CCE は、複数の Unified CM クラスタをサポートします。複数の Unified CCE インスタンスをまとめてネットワーク接続することで、より大きなシステム容量を実現できます。

Related Concepts

Unified CCE ソリューションのアーキテクチャ

Contact Center Enterprise ソリューションの比較

この表では、Contact Center Enterprise ソリューション間の相違が強調されています。

Contact Center Enterprise ソリューションの比較

機能

Packaged CCE

Cisco HCS for Contact Center（単一インスタンスの場合）

Unified CCE（単一インスタンスの場合）

導入とスケーラビリティ

事前設定されたリファレンス設計 (2000、4000、および 12000 エージェント)

非リファレンス設計 (4000 および 12000 エージェント) としての Avaya PG 向けおよび ICM 間ゲートウェイ

事前設定済みレファレンス設計 (2000、4000、12000、および 24000 エージェント)[1]

リファレンス設計（2000、4000、12000、24000 エージェント、および Contact Director [3 インスタンスにわたる 24000 エージェント]）

非リファレンス設計の導入

ハードウェア

テスト済みリファレンス構成 (B シリーズ および C シリーズ)

仕様ベースの UCS サポート（B シリーズおよび C シリーズ）

仕様ベース（非 UCS）、サード パーティ製ハードウェアのサポート

テスト済みリファレンス構成 (B シリーズ および C シリーズ)

仕様ベースの UCS サポート（B シリーズおよび C シリーズ）

テスト済みリファレンス構成 (B シリーズ および C シリーズ)

仕様ベースの UCS サポート（B シリーズおよび C シリーズ）

仕様ベース（非 UCS）、サード パーティ製ハードウェアのサポート

アーキテクチャ

設定ツールと管理ツール

ガジェット ベースの CCE Administration とその他のツール

部分的ガジェット ベースの CCE Administration、Unified Contact Center Domain Manager、ICM Configuration Manager、その他のツール

部分的ガジェット ベースの CCE Administration、Unified Contact Center Management Portal、ICM Configuration Manager、その他のツール

[1] 2000 エージェントの 500 エージェントのバリエーションと 4000 エージェントの小規模コンタクト センターのバリエーションが含まれます。Cisco HCS for Contact Center がサポートする唯一の非リファレンス設計要素は Avaya PG です。

Related Concepts

リファレンス設計で利用可能な機能

リファレンス設計の構成上の制限

Chapter 2. Unified CCX リファレンス設計

- リファレンス設計の概要

- リファレンス設計ソリューションの利点

- リファレンス設計ソリューションの仕様

- Contact Center Enterprise リファレンス設計

- リファレンス設計のトポロジ

- 非リファレンス設計ソリューション

リファレンス設計の概要

Note

このドキュメントの最初の 4 章は、3 つの Contact Center Enterprise ソリューションの詳細を確認したいユーザ向けです。

- Packaged Contact Center Enterprise

- Cisco Hosted Collaboration Solution for Contact Center

- Unified Contact Center Enterprise

Unified CCE に特化した設計上の考慮事項およびガイドラインに関する情報は、残りの章を参照してください。

Contact Center Enterprise リファレンス設計 は、「コンタクト センター」エンタープライズ ソリューションに関する シスコ検証済みデザイン（CVD）のセットです。リファレンス設計には、ほとんどの展開のニーズに合ったテクノロジおよびトポロジが定義されています。このリファレンス設計では、コンタクト センターの企業ソリューション設計の簡略化に焦点を絞っています。これは、Cisco の戦略的なコンポーネントに基づいた完全なコンタクト  センター機能を提供します。

以下の表で、リファレンス設計を定義し、コンタクト センターのほとんどニーズをカバーしています。

Contact Center Enterprise リファレンス設計で使用されるリファレンス設計

リファレンス設計

Packaged CCE

Cisco HCS for Contact Center

Unified CCE

2000 エージェント

はい

はい

はい

4000 エージェント

はい

はい

はい

12000 エージェント

はい

はい

はい

24000 エージェント

なし

はい

はい

Contact Director

なし

いいえ

はい

非リファレンス設計

Avaya PG および ICM 間ゲートウェイ

Avaya PG のみ

Yes

設計しようとするソリューションが特定のリファレンス設計の制限を超える場合は、制限の多いリファレンス設計を使用してください。たとえば、2000 エージェント導入で 350 アクティブ レポート ユーザを必要とする場合は、ソリューションに対して 4000 エージェントのリファレンス設計を使用します。

Contact Center Enterprise リファレンス設計 に含まれていないものを含むコンタクト センターのソリューションは、非リファレンス設計と呼ばれます。 Cisco HCS for Contact Center が非リファレンス設計として Avaya PG をサポートします。

その他の非リファレンス設計の展開には Unified CCE が必要となります。

- リファレンス設計および展開タイプ

リファレンス設計および展開タイプ

Contact Center Enterprise リファレンス設計 は、展開タイプを使用して特定のコンタクト センター ソリューションにマップされます。展開タイプは、システムの制限を課すシステムコードであり、輻輳制御を適用します。

この表は、リファレンス設計および非リファレンス設計をそれぞれ使用する展開タイプにマップします。

リファレンス設計により使用される展開タイプ

リファレンス設計

Packaged CCE

Cisco HCS for Contact Center

Unified CCE

Label

Label

Label

2000 エージェント

Packaged CCE: 2000 エージェント

HCS-CC 2000 エージェント

UCCE: 2000 エージェント

4000 エージェント

Packaged CCE: 4000 エージェント

HCS-CC 4000 エージェント

UCCE: 4000 エージェント

12000 エージェント

Packaged CCE: 12000 エージェント

HCS-CC 12000 エージェント

UCCE: 12000 エージェント

24000 エージェント

NA

HCS-CC 24000 エージェント

UCCE 24000 エージェント ルータ / Logger

Contact Director

該当なし

該当なし

Contact Director

非リファレンス設計

Avaya PG および ICM 間ゲートウェイ

Packaged CCE: 4000 エージェント

Packaged CCE: 12000 エージェント

NA

ICM Rogger

ICM Router/Logger

UCCE 8000 エージェント ルータ / Logger

ラボのみの設計

Packaged CCE: ラボ モード

NA

UCCE: Progger (ラボのみ)

リファレンス設計ソリューションの利点

コンタクト センターは、新しい世代のソフトウェアおよびハードウェアを使用して、より多くの可能性を提供します。新しいテクノロジにより、現在のコンタクトセンターでは、以前は好まれていた方法が廃止される可能性があります。設計の選択を簡素化し、コンタクト センターの開発をスピードアップするために Contact Center Enterprise リファレンス設計 が作成されています。ほとんどの新しいコンタクト センターではレファレンス設計を使用して、各自のニーズを満たすことができると期待されます。

リファレンス設計に準拠することで、以下が可能となります。

- 明確なオプションを提示して、顧客の期待を導きます。

- 標準モデルを使用して設計プロセスを効率化します。

- ライフサイクルの終了間近のコンポーネントおよび機能は使用を控えてくてださい。

- 旧バージョンの機能には、パワフルかつ効率的な代理の機能が提供されています。

- 将来のコンタクト センター開発の Cisco のビジョンに合わて設計を行ってください。

- 時間をかけずに容易に承認プロセスを利用することができます。

リファレンス設計ソリューションの仕様

リファレンス設計には、ほとんどのコンタクト センターで使用されている機能のビジョンが定義されています。リファレンス設計は以下の要素で構成されています。

- コア コンポーネント: すべてのコンタクト センターを構成するコンポーネント。

- 入力、出力、および VXML ゲートウェイ

- Unified Customer Voice Portal（Unified CVP）

- Unified Contact Center Enterprise（Unified CCE）

- Cisco Virtualized Voice Browser（VVB）

- Unified Communications Manager (Unified CM)

- Cisco Finesse

- Cisco Unified Intelligence Center

- オプションの Cisco コンポーネント: 必ずしもすべてのコンタクト センターで必要とはされない機能を追加するコンポーネント。

- Customer Collaboration Platform

- Cisco Unified SIP Proxy

- ビジネス チャットおよび E メール

- Cisco IdS

- クラウド コネクト

- サードパーティ コンポーネント (オプション): サードパーティ コンポーネントを追加して、他の機能を提供することができます。

- ロード バランサ

- 録音

- 音声サーバ：ASR/TTS

- ウォールボード

- ワークフォース管理

- 統合機能: これらの機能を有効にするためにオプションのソリューション コンポーネントを追加する必要はありません。ただし、機能を有効化するには、複数のソリューション コンポーネントの構成が必要となります。ソリューションのサイジングに影響する可能性があります。また、特定の設計上の考慮事項もあります。

- コール フロー: 標準の連絡先処理およびルーティング制御方法。

- 着信コール:

- キャリアからの新たな着信

- 新たな内部通話

- 補足サービス

- 保留と復帰

- 転送および会議

- REFER 転送

- ネットワーク転送

- 再クエリおよび耐障害性

- トポロジ: コンタクト センターのコンポーネントの標準レイアウト:

- 集中型

- 分散型

- グローバル

この図は、ソリューションおよびこれらサービスを提供するコンポーネントの一部である上位レベルのサービスを示しています。また、レファレンス設計の範囲外にあるいくつかの機能とコンポーネントについても紹介しています。

Note

この図では、非レファレンス設計コンポーネントおよび非参照トポロジのいくつかが強調表示されています。非リファレンス設計セクションはこのリスト上で拡大されています。

Contact Center Enterprise リファレンス設計および非リファレンス設計

Note

通常、リファレンス設計では、ICM 間ゲートウェイは使用できません。このゲートウェイは、Contact Directorのリファレンス設計のみで使用可能です。

この図は、リファレンス設計に準拠した展開の基本的な要件をまとめたものです。

Contact Center Enterprise コンポーネントおよび機能

Contact Center Enterprise リファレンス設計

次の章では、Contact Center Enterprise リファレンス設計 について説明します。

リファレンス設計 は、Cisco UCS C240 M5SX および Cisco Hyperflex HX220c M5SX Tested Reference Configuration（TRC）サーバのコアコンポーネントのレイアウトを表示します。

Note

リファレンス設計がサポートされるサーバの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.htmlの シスコ コラボレーションの仮想化 のページ を参照してください。

すべてのレファレンス設計には、以下の記述が適用されます。

- Contact Center Enterprise ソリューションは、vCPU オーバーサブスクリプションを使用しています。 このポリシーは、レファレンス設計ソリューションおよび非リファレンス設計ソリューションの両方に適用されます。

- 標準の PG VM には、エージェント (Unified CM) PG、VRU PG、および MR PG が含まれています。Unified CCE および Cisco HCS for Contact Center を使用して、PG とその周辺機器をこのベース レイアウトに追加することができます。

- クラウドサービスを使用できるコンポーネントである Cloud Connect は、Cisco Webex Experience Management のみで利用できます。Cloud Connect は、Cisco HX220c M5SX サーバでオンボックス（次の項で記載されている通り）で展開することができる一方、Cisco UCS C240 M5SX サーバでは、Cloud Connect のオンボックスは必須となります。

- CVP コールサーバ、Cisco VVB、および Cloud Connect はオプションのコンポーネントです。

- CVP コールサーバと Cisco VVB はオプションのコンポーネントです。

- ビジネスと導入要件に基づいて、VVB VM を外部サーバに配布するか、この項で説明する方法で、追加のサーバまたはノード（M5-X クラスタの場合）に展開します。

レイアウトが Cisco Hyperflex HX220c M5SX サーバにある場合、HX ノードとして、追加の VVC サーバを既存の Hyperflex クラスタか外部 M5 サーバに展開できます。

- リファレンス設計上の考慮事項レイアウトにおけるコンポーネントのデータソース配分に関しては、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-guides-list.htmlCisco Unified Contact Center Enterprise のインストールおよびアップグレードガイド」、https://www.cisco.com/c/en/us/support/customer-collaboration/packaged-contact-center-enterprise/products-installation-guides-list.html の「コンタクトセンター版シスコ ホステッド コラボレーション ソリューションのインストールおよびアップグレードガイド」を参照してください。

- この項のリファレンス設計レイアウトは、Customer Collaboration Platform などのオフボックスコンポーネントは表示しません。

- 仮想マシンのリソース プロビジョニング ポリシー

- 2000 エージェントリファレンス設計

- 4000 エージェントリファレンス設計

- 12000 エージェントリファレンス設計

- 24000 エージェントリファレンス設計

- Contact Director

仮想マシンのリソース プロビジョニング ポリシー

Note

以前に使用されていたオーバーサブスクリプション ポリシーは、仮想マシン (VM) のリソース プロビジョニング ポリシーの一部となっています。

Unified CCE のリファレンス設計は、サーバ上の物理 CPU コアの仮想マシンへの vCPU オーバーサブスクリプションをサポートしています。オーバーサブスクリプションのために、ハイパースレッド コアは物理コアとしてカウントされません。オーバーサブスクリプションを使用するかどうかにかかわらず、VM リソース プロビジョニング ポリシーを使用します。このポリシーでは、ホスト常駐 VM が消費可能な CPU MHz の合計およびサーバのメモリが制限されます。

以下の場合に VM リソース プロビジョニング ポリシーを適用します。

- VM を追加または置き換えることによって、ドキュメント化されたリファレンス設計の VM レイアウトを変更します。これは、リファレンス設計ソリューションで、カスタム VM レイアウトまたは非リファレンス VM レイアウトを使用することになります。

- 非リファレンス設計サーバをプロビジョニングします。

- リファレンス VM レイアウトが指定されていないオプションおよびサードパーティ コンポーネントに対してリファレンス設計サーバをプロビジョニングします。

- UCS またはサードパーティ仕様ベースの サーバを使用します。

- 既存のソリューションをアップグレードします。レファレンス設計 VM レイアウトには移行しません。

Note

サーバ毎に VM リソース プロビジョニング ポリシーを適用します。このポリシーは、リファレンス設計の VM レイアウトには適用されません。ソリューションには、リファレンス設計の VM レイアウトと、VM リソース プロビジョニング ポリシー規則を使用する他の VM レイアウトを使用するサーバを含めることができます。

VM リソース プロビジョニング ポリシーを適用するには、以下の条件が満たされている必要があります。

- 各サーバ上のすべての物理コアに対して最大 2 つの vCPUs を使用することができます。

- 各サーバでは、使用可能な CPU MHz の合計の 65% を使用できます。

- 各サーバでは使用可能なメモリ合計の最大 80% を使用できます。

仮想化と仕様ベースのサーバポリシーの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.htmlにある Cisco コラボレーションの仮想化 を参照してください。

Note

仮想マシン配置ツールでは、現在、オーバーサブスクライブすることはできません。この制限は、このツールでのみの問題です。上記で提供される制限の範囲内でのオーバーサブスクライブは可能です。

2000 エージェントリファレンス設計

すべての Contact Center Enterprise ソリューションは、Cisco UCS C240 M5SX Large TRC サーバおよび Cisco Hyperflex C240 M5SX Large TRC サーバで、2000 エージェントリファレンス設計をサポートします。

- このリファレンス設計では、Cisco Unified Intelligence Center、ライブ データ、およびシングル サインオン用の ID サービスが単一の VM 上に展開します。大規模なレファレンス設計では、上記は別の VM に展開されます。

- オプションで、Unified Communications Manager パブリッシャおよびサブスクライバを、2000 エージェント リファレンス設計のレイアウトに示される通りに展開する代わりに、別々のサーバに展開することができます。2 つのサブスクライバを Unified CCE に割り当てる必要があります。これらのサブスクライバ上のデバイスはすべて SIP である必要があります。

2000 エージェント リファレンス設計では、同じマシン上の Unified CM は最大 2000 台の電話機をサポートすることができます。これには、連絡先のすべてのタイプのエージェント (コンタクト センター エージェントやバックオフィス要員等) の電話機が含まれます。設計するソリューションで 2000 以上の電話機が必要な場合は、別のサーバで Unified CM を使用してください。

- グローバル展開トポロジでは、各リモート サイトに独自の Unified CM クラスタを含めることができます。リモート サイトには、Cisco Unified Intelligence Center サーバを配置することはできません。

- 外部サーバには、各サイトにオプションの AW-HDS DDS を導入して、データ保存期間を延長することができます。

- 2000 エージェント リファレンス設計では、最大 400 ECE 人のエージェント向けにデータ サーバをオンボックスで導入することができます。最大ECE 1500 人のエージェント向けにオフボックス導入が可能です。

また、ECE データ サーバを別のサーバに配置することもできます。

- ECE Web サーバを外部サーバに展開します。その際サーバは、ECE データサーバ と同じデータ センターで配置することができます。また、顧客とのチャット処理が必要な場合は、DMZ に配置することも可能です。

- Cisco UCS C240 M5SX Large TRC サーバでのサポート

- HX データプラットフォーム M5 TRC サーバのサポート

Cisco UCS C240 M5SX Large TRC サーバでのサポート

Important

12.x on C240 M4 サーバにアップグレードする場合、外部サーバで Unified CM および ECE HA VM を展開します。

次の図は、Cisco UCS C240 M5SX Large TRC サーバ上の 2000 エージェントリファレンス設計におけるコンポーネントの基本レイアウトを表示しています。

以下の表では、VM 仕様を一覧にしています。

2000 エージェント リファレンス設計向けの VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

vDisk 3

Rogger

4

5000

6

80

150

Unified CM

4

[7200]

8

110

Unified CVP OAMP

2

400

4

80

Unified CVP Server

4

3000

12

250

Unified CVP レポートサーバ

4

1800

6

80

438

ECE Dataserver[1]

4

4000

20

80

50

300

CUIC-LD-IdS

4

5500

16

200

AW-HDS-DDS

4

5000

16

80

500

PG

2

4000

6

80

Finesse

4

5000

10

146

VVB

4

9,000

10

146

[1] 最新の VM 使用に関しては、https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-enterprise-chat-email.html の 企業のチャットおよび電子メールの仮想化ページの 400 エージェントの行を参照してください。

2000 エージェント リファレンス設計向け合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A

36

46300

106

2216

データセンターサイト B

34

40500

100

2544

サーバ 2

16

36000

40

584

HX データプラットフォーム M5 TRC サーバのサポート

以下の図は、Cisco HyperFlex HX220c M5 TRC サーバにおける 2000 エージェントリファレンス設計のコンポーネントの基本レイアウトを示しています。

以下の表では、VM 仕様を一覧にしています。

2000 エージェント リファレンス設計向けの VM 仕様

VM

vCPU

MHz

vRAM

vDisk1

vDisk2

vDisk 3

HX データコントローラ

16

10800

48

Rogger

4

5000

6

80

150

Unified CM

4

[7200]

8

110

Unified CVP OAMP

2

400

4

80

Unified CVP Server

4

3000

12

250

Unified CVP レポートサーバ

4

1800

6

80

438

ECE Dataserver[1]

4

4000

20

80

50

300

CUIC-LD-IdS

4

5500

16

200

AW-HDS-DDS

4

5000

16

80

750

PG

2

4000

6

80

Finesse

4

5000

10

146

VVB

4

9,000

10

146

クラウド コネクト

4

6000

10

146

[1] 最新の VM 使用に関しては、https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-enterprise-chat-email.html の 企業のチャットおよび電子メールの仮想化ページの 400 エージェントの行を参照してください。

2000 エージェント リファレンス設計向け合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト 1A

48

53100

134

1786

データセンターサイト 1B

46

47300

128

2114

データセンターサイト 2A

32

38800

98

868

データセンターサイト 2B

32

38800

98

868

4000 エージェントリファレンス設計

すべての Contact Center Enterprise ソリューションは、Cisco UCS C240 M5SX TRC および HX データプラットフォーム 220c M5 TRC サーバの 4000 エージェントリファレンス設計をサポートします。このモデルでは、2000 エージェントリファレンス設計からスケールアップするためのサーバが追加されています。

Note

4000 エージェントリファレンス設計では、データセンターサイトあたり 2 つの AW-HDS-DDS まで展開できます。大規模なソリューションでは、HDS-DDS と AW-HDS を組み合わせて使用します。

- Cisco UCS C240 M5SX TRC サーバでのサポート

- HX データプラットフォーム M5 TRC サーバのサポート

Cisco UCS C240 M5SX TRC サーバでのサポート

Important

C240 M4 サーバで 12.x にアップグレードする場合は、サーバと VM のレイアウトに次の変更を行います。

- 外部サーバに Unified CM および ECE HA VM を導入します。

- Unified CVP コールと VXML サーバをホストする各サーバに、16 GB の物理 RAM を追加します。

- Unified CVP VM のメモリ予約を 12 GB に増やします。

この図は、Cisco UCS C240 M5SX Large TRC サーバ上の 4000 エージェントリファレンス設計におけるコンポーネントの基本レイアウトを表示しています。

4000 エージェント リファレンス設計モデル

以下の表では、VM 仕様を一覧にしています。

4000 エージェント リファレンス設計向けの VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

Rogger

4

5000

6

80

150

ライブ データ

4

5500

24

146

IdS

4

1500

10

146

Unified CVP レポートサーバ

4

1800

6

80

438

Unified CVP OAMP

2

400

4

80

Unified CM

4

[7200]

8

110

PG

2

4000

6

80

Unified CVP Server

4

3000

12

250

Finesse

4

5000

10

146

Unified Intelligence Center

4

5500

16

200

AW-HDS-DDS

4

5000

16

80

500

VVB

4

9,000

10

146

4000 エージェント リファレンス設計向け合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A ー サーバ 1A

34

44800

84

1596

データセンターサイト B ー サーバ 1B

36

37200

72

1406

データセンターサイト A ー サーバ 2A

36

45000

120

2512

データセンターサイト B ー サーバ 2B

36

45000

120

2512

サーバ 3

24

54000

60

876

HX データプラットフォーム M5 TRC サーバのサポート

以下の図は、Cisco HyperFlex HX220c M5 TRC サーバにおける 4000 エージェントリファレンス設計のコンポーネントの基本レイアウトを示しています。

4000 エージェント リファレンス設計モデル

以下の表では、VM 仕様を一覧にしています。

4000 エージェント リファレンス設計向けの VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

HX データコントローラ

16

10800

48

Rogger

4

5000

6

80

150

ライブ データ

4

5500

24

146

IdS

4

1500

10

146

Unified CVP レポートサーバ

4

1800

6

80

438

Unified CVP OAMP

2

400

4

80

Unified CM

4

[7200]

8

110

PG

2

4000

6

80

Unified CVP Server

4

3000

12

250

Finesse

4

5000

10

146

Unified Intelligence Center

4

5500

16

200

AW-HDS-DDS

4

5000

16

80

500

VVB

4

9,000

10

146

クラウド コネクト

4

6000

10

146

4000 エージェント リファレンス設計向け合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A ー サーバ 1A

50

54400

134

1632

データセンターサイト B ー サーバ 1B

48

54000

130

1552

データセンターサイト A ー サーバ 2A

48

50800

152

1932

データセンターサイト B ー サーバ 2B

48

50800

152

1932

データセンターサイト A ー サーバ 3A

24

44200

70

1708

データセンターサイト A ー サーバ 3B

20

37000

62

1598

12000 エージェントリファレンス設計

Contact Center Enterprise ソリューション向けのリファレンス設計は、Cisco C240 M5SX Large TRC サーバおよび Cisco HyperFlex HX220c M5 TRC サーバで 12000 人のエージェントをサポートします。このモデルでは、4000 エージェントリファレンス設計からスケールアップするためのサーバが追加されています。

- Cisco UCS C240 M5SX Large TRC サーバでのサポート

- HX データプラットフォーム M5 TRC サーバのサポート

- 12000 エージェント リファレンス設計モデルのレポート ユーザ

Cisco UCS C240 M5SX Large TRC サーバでのサポート

次の図は、Cisco C240 M5SX Large TRC サーバ上の 12000 エージェントリファレンス設計におけるコンポーネントの基本レイアウトを表示しています。

12000 エージェント リファレンス設計モデル

以下の表では、VM 仕様を一覧にしています。

12000 エージェントリファレンス設計のための VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

ルータ

4

4000

8

80

Logger

4

6000

8

80

500

ライブ データ

8

16500

24

146

IdS

4

1500

10

146

Unified CVP レポートサーバ

4

1800

6

80

438

Unified CVP OAMP

2

400

4

80

HDS-DDS

8

17500

16

80

420

AW-HDS

8

17500

16

80

500

PG

2

4000

6

80

Unified CVP Server

4

3000

12

250

Finesse

4

5000

10

146

Unified CM

4

[7200]

8

110

Unified Intelligence Center

4

5500

16

200

VVB

4

9,000

10

146

12000 エージェント リファレンス設計向け合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A ー サーバ 1A

34

47700

76

2050

データセンターサイト B ー サーバ 1B

32

47300

72

1970

データセンターサイト A ー サーバ 2A

40

60100

106

1628

データセンターサイト B ー サーバ 2B

36

52900

98

1518

データセンターサイト A ー サーバ 3A

36

52900

98

1518

データセンターサイト B ー サーバ 3B

36

52900

98

1518

データセンターサイト A ー サーバ 4A

24

52500

48

1740

データセンターサイト B ー サーバ 4B

24

52500

48

1740

データセンターサイト A ー サーバ 5A

40

60100

106

1628

データセンターサイト B ー サーバ 5B

36

52900

98

1518

サーバ 6

24

54000

60

876

HX データプラットフォーム M5 TRC サーバのサポート

以下の図は、Cisco HyperFlex HX220c M5 TRC サーバにおける 12000 エージェントリファレンス設計のコンポーネントの基本レイアウトを示しています。

12000 エージェント リファレンス設計モデル

以下の表では、VM 仕様を一覧にしています。

12000 エージェントリファレンス設計のための VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

HX データコントローラ

16

10800

48

ルータ

4

4000

8

80

Logger

4

6000

8

80

500

ライブ データ

8

16500

24

146

IdS

4

1500

10

146

Unified CVP レポートサーバ

4

1800

6

80

438

Unified CVP OAMP

2

400

4

80

HDS-DDS

8

17500

16

80

500

AW-HDS

8

17500

16

80

500

PG

2

4000

6

80

Unified CVP Server

4

3000

12

250

Finesse

4

5000

10

146

Unified CM

4

[7200]

8

110

Unified Intelligence Center

4

5500

16

200

VVB

4

9,000

10

146

クラウド コネクト

4

6000

10

146

12000 エージェント リファレンス設計向け合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A ー サーバ 1A

50

54200

126

1806

データセンターサイト B ー サーバ 1B

48

53800

122

1726

データセンターサイト A ー サーバ 2A

48

54700

136

1372

データセンターサイト B ー サーバ 2B

48

54700

136

1372

データセンターサイト A ー サーバ 3A

48

54700

136

1372

データセンターサイト B ー サーバ 3B

48

54700

136

1372

データセンターサイト A ー サーバ 4A

32

45800

80

1160

データセンターサイト B ー サーバ 4B

32

45800

80

1160

データセンターサイト A ー サーバ 5A

48

54700

136

1372

データセンターサイト B ー サーバ 5B

48

54700

136

1372

データセンターサイト A ー サーバ 6A

32

45800

80

1080

データセンターサイト B ー サーバ 6B

32

45800

80

1080

データセンターサイト B ー サーバ 7A

36

55800

98

730

データセンターサイト B ー サーバ 7B

36

55800

98

730

サーバ 8

24

54000

60

876

12000 エージェント リファレンス設計モデルのレポート ユーザ

サーバ 4A および 4B の AW-HDS 3、AW-HDS 4、AW-HDS 5 および AW-HDSは、400 以上のレポートユーザをサポートするためのオプションです。サーバ 5A および 5B は、8000 人を超えるエージェントをサポートするためのオプションです。サーバ 6A および 6B は、400 以上のレポートユーザをサポートするためのオプションです。

このリファレンス設計は、最大 6 つの CUIC VM および 6 つの AW-HDS VMs、そして 3 つの VM を各サイトでサポートします。この制限では、最大 1200 人のレポートユーザに対応できます。1 つのサイトがシャットダウンした場合、残りのサイトは 3 つのノードで 600 人のレポートユーザのみがサポート可能です。

24000 エージェントリファレンス設計

Contact Center Enterprise ソリューション向けのリファレンス設計は、Cisco C240 M5SX Large TRC サーバおよび Cisco HyperFlex HX220c M5 TRC サーバで 24000 人のエージェントをサポートします。このモデルでは、12000 エージェントリファレンス設計からスケールアップするためのサーバが追加されています。

- Cisco UCS C240 M5SX Large TRC サーバでのサポート

- HX データプラットフォーム M5 TRC サーバのサポート

- 24000 エージェントリファレンス設計モデルのレポートユーザ

Cisco UCS C240 M5SX Large TRC サーバでのサポート

次の図は、Cisco UCS C240 M5SX Large TRC サーバ上の 24000 エージェントリファレンス設計におけるコンポーネントの基本レイアウトを表示しています。

24000 エージェント リファレンス設計モデル

以下の表では、VM 仕様を一覧にしています。

24000 エージェントリファレンス設計のための VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

ルータ

4

4000

8

80

Logger

4

6000

8

80

500

ライブ データ

12

24000

36

146

IdS

8

3000

10

146

Unified CVP レポートサーバ

4

1800

6

80

438

Unified CVP OAMP

2

400

4

80

HDS-DDS

8

17500

16

80

500

AW-HDS

8

17500

16

80

500

PG

2

4000

6

80

Unified CVP Server

4

3000

12

250

Finesse

4

5000

10

146

Unified CM

4

[7200]

8

110

Unified Intelligence Center

4

5500

16

200

VVB

4

9,000

10

146

24000 エージェントリファレンス設計のための合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A ー サーバ 1A

54

56700

88

2130

データセンターサイト B ー サーバ 1B

40

56300

84

2050

データセンターサイト A ー サーバ 2A

40

60100

106

1628

データセンターサイト B ー サーバ 2B

36

52900

98

1518

データセンターサイト A ー サーバ 3A

36

52900

96

1518

データセンターサイト B ー サーバ 3B

36

51400

96

1518

データセンターサイト A ー サーバ 4A

24

52500

48

1740

データセンターサイト B ー サーバ 4B

24

52500

48

1740

データセンターサイト A ー サーバ 5A

40

60100

106

1628

データセンターサイト B ー サーバ 5B

36

52900

98

1518

データセンターサイト A ー サーバ 6A

32

47400

82

1318

データセンターサイト B ー サーバ 6B

32

47400

82

1318

データセンターサイト A ー サーバ 7A

36

54600

90

1428

データセンターサイト B ー サーバ 7B

32

47400

82

1318

データセンターサイト A ー サーバ 8A

32

47400

80

1318

データセンターサイト B ー サーバ 8B

32

45900

80

1318

データセンターサイト A ー サーバ 9A

24

54000

60

876

データセンターサイト B ー サーバ 9B

24

54000

60

876

サーバ 10

24

54000

60

876

HX データプラットフォーム M5 TRC サーバのサポート

以下の図は、Cisco HyperFlex HX220c M5 TRC サーバにおける 24000 エージェントリファレンス設計のコンポーネントの基本レイアウトを示しています。

24000 エージェント リファレンス設計モデル

以下の表では、VM 仕様を一覧にしています。

24000 エージェントリファレンス設計のための VM 仕様

VM

vCPU

MHz

vRAM

vDisk 1

vDisk 2

HX データコントローラ

16

10800

48

ルータ

4

4000

8

80

Logger

4

6000

8

80

500

ライブ データ

8

16500

24

146

IdS

8

3000

10

146

Unified CVP レポートサーバ

4

1800

6

80

438

Unified CVP OAMP

2

400

4

80

HDS-DDS

8

17500

16

80

420

AW-HDS

8

17500

16

80

500

PG

2

4000

6

80

Unified CVP Server

4

3000

12

250

Finesse

4

5000

10

146

Unified CM

4

[7200]

8

110

Unified Intelligence Center

4

5500

16

200

VVB

4

9,000

10

146

クラウド コネクト

4

6000

10

146

24000 エージェントリファレンス設計のための合計 VM 要件

サーバ

vCPU

MHz

vRAM

vDisk

データセンターサイト A ー サーバ 1A

54

56900

124

1770

データセンターサイト B ー サーバ 1B

48

49300

112

1580

データセンターサイト A ー サーバ 2A

48

54700

136

1372

データセンターサイト B ー サーバ 2B

48

54700

136

1372

データセンターサイト A ー サーバ 3A

48

54700

136

1372

データセンターサイト B ー サーバ 3B

48

54700

136

1372

データセンターサイト A ー サーバ 4A

32

45800

80

1160

データセンターサイト B ー サーバ 4B

32

45800

80

1160

データセンターサイト A ー サーバ 5A

48

54700

136

1372

データセンターサイト B ー サーバ 5B

48

54700

136

1372

データセンターサイト A ー サーバ 6A

44

49200

120

1172

データセンターサイト B ー サーバ 6B

44

49200

120

1172

データセンターサイト A ー サーバ 7A

44

49200

120

1172

データセンターサイト B ー サーバ 7B

44

49200

120

1172

データセンターサイト A ー サーバ 8A

44

49200

120

1172

データセンターサイト B ー サーバ 8B

44

49200

120

1172

データセンターサイト A ー サーバ 9A

36

51800

90

1226

データセンターサイト B ー サーバ 9B

36

51800

90

1226

データセンターサイト A ー サーバ 10A

36

55800

98

730

データセンターサイト B ー サーバ 10B

36

55800

98

730

サーバ 11

24

54000

60

876

24000 エージェントリファレンス設計モデルのレポートユーザ

サーバ 4A および 4B の AW-HDS 3、AW-HDS 4、AW-HDS 5 および AW-HDSは、400 以上のレポートユーザをサポートするためのオプションです。サーバ 5A および 5B は、8000 人を超えるエージェントをサポートするためのオプションです。サーバ 6A および 6B は、400 以上のレポートユーザをサポートするためのオプションです。

このリファレンス設計は、最大 6 つの CUIC VM および 6 つの AW-HDS VMs、そして 3 つの VM を各サイトでサポートします。この制限では、最大 1200 人のレポートユーザに対応できます。1 つのサイトがシャットダウンした場合、残りのサイトは 3 つのノードで 600 人のレポートユーザのみがサポート可能です。

Contact Director

Unified CCE のみが Contact Director リファレンス設計をサポートします。Contact Directorは、着信コールを他のコンタクト センターインスタンスに配布します。ターゲットは、Unified CCE instances またはUnified ICM インスタンスにすることができます。これは、サードパーティのコンタクト センターに接続します。連絡先の共有機能は、Contact Director を使用して、着信した連絡先を 最高で 3 つの 12000 エージェント の Unified CCE インスタンスに配布します。3 つのインスタンスは、合計 24000 のアクティブ エージェントをサポートできます。

2 つの Unified CCE ターゲット インスタンスを使用した Contact Director ソリューション

連絡先の共有機能の詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.htmlの Cisco Unified Contact Center Enterprise 機能ガイド を参照してください。

リファレンス設計のトポロジ

Contact Center Enterprise リファレンス設計 では、展開で使用可能なトポロジも定義されています。展開トポロジは、データ センターの VM のインストール場所とデータ センターへのエージェントの接続方法から構成されます。次の図は、リファレンス設計で使用できると基本的なトポロジを示しています。

リファレンス設計のトポロジ

1. メイン サイト では、集中型もしくは分散型のトポロジを使用できます。

2. リモート サイトは、メイン サイト を使用して地理的にコロケートすることができます。

リファレンス設計では、以下のトポロジが使用可能です。

トポロジ

説明

集中型

同じ物理データセンターで両サイドの冗長コンポーネントをホストします。同じ LAN 上にある場合でも、2 サイド間の最大ラウンドトリップ時間は 80 ミリ秒 となりますデータ センターには、コア コンタクト センター コンポーネントと Unified CM が含まれます。

分散型

異なる地理的場所に冗長コンポーネントを片側ずつホストします。分散型 サイトのリストに追加します では、一方の サイト で障害が発生した場合にも、もう一方で稼動を継続できます。また、地理的に異なる地域に連絡先を サイト に送信せずに、ルーティングを処理することも可能です。2 サイド間の最大ラウンドトリップ時間は 80 ミリ秒です。

グローバル

集中型または分散型の メイン サイトが提供されています。また、通常、地理的に異なる場所に配置される リモート サイト も提供されています。リモート サイト では、該当する地理的地域でのローカル アクセス権が付与されます。リモート サイト を配置すると、別のコンタクト センター インスタンスを作成せずに、グローバル ワーク ロード処理が可能です。

データセンターの RTT が 80 秒以上の場合、リモート サイト には、個別の Unified CM クラスタおよび個別の Cisco Finesse クラスタが必要ですメイン サイト と リモート サイト 間の最大ラウンド トリップ時間は 400 秒です。

Note

リモート サイトには、Cisco Unified Intelligence Center サーバを配置することはできません。

このトポロジは、アウトソーシング委託者モデルに適しています。このモデルでは、アウトソーシング委託者が個別の周辺機器ゲートウェイとそれに応じた周辺機器を持っています。

Note

リリース 11.6 以降、Packaged CCE は、このトポロジをサポートしています。

リファレンス設計では、以下の方法で サイト にエージェントを接続することができます。

リモート オフィス トポロジ

説明

エージェント付きリモート オフィス

WANルータ経由の サイト への接続を行うエージェント ワークステーションを備えたコンタクト センター オフィス。音声終端は サイト にあります。すべての連絡は、まず サイト を通過し、その後、エージェントに向かいます。

エージェントとローカル トランク付きリモート オフィス

ローカル PSTN への接続を備えたコンタクト センター オフィス。コンタクトはローカル トランクで受信され、ルーティングためにローカル ゲートウェイからデータ センターに渡されます。

ブロードバンド付きホーム エージェント：Cisco Virtual Office（CVO）

サイト への VPN 接続を備えたリモート ロケーションのエージェント。エージェントには、Cisco IP Phone と Cisco Finesse デスクトップがあります。エージェントは、必要に応じて、固定 VPN 接続に Cisco Virtual Office（CVO）ルータを使用できます。

Unified Mobile Agent

PSTN 電話を使用するエージェント。

Note

リモート オフィスとデータ センター間の最大許容ラウンドトリップ時間は 200 ms です。

Related Concepts

リファレンス設計とトポロジ設計に関する考慮事項

トポロジ

非リファレンス設計ソリューション

Contact Center Enterprise リファレンス設計 には、コンタクト センター ソリューションで使用できる要素が定義されています。このリファレンス設計で明示的に許可されていない要素がソリューションに含まれている場合、そのソリューションは非リファレンス設計となります。大部分の非リファレンス設計ソリューションには Unified CCE が必要です。

非リファレンス設計

Cisco HCS for Contact Center は、非リファレンス設計ソリューションとして Avaya PG をサポートしています。

リファレンス設計で代替がある要素

新しいテクノロジーにより、リファレンス設計ソリューションでサポートされているコンポーネント、オプション、機能、設定の大部分が代替されます。以下に、このカテゴリに含まれる要素の一部を示します。

非リファレンス設計とリファレンス設計の代替

非リファレンス設計の要素

リファレンス設計の代替

Cisco ICM から ICM ゲートウェイ（Contact Director モデルを除く）

Contact Director

Unified IP IVR、またはサードパーティ製音声応答装置（VRU）アプリケーション

Unified CVP

Unified CCE サブコンポーネントのバージョンの不一致（これは、コンタクト センターを別のリリースにアップグレードする場合にのみ許可されます）。

アップグレード後にすべてのバージョンを一致

Unified CVP Call Director

Unified CVP 包括的コール フロー

汎用 PG

Agent PG、VRU PG、および MR PG の共存

トランスレーション ルート

Unified CVP 包括的コール フロー（サードパーティの PG を除く）

複数の Unified CM PIM による構成

個別の VM 上に複数 PG

Unified CM マルチキャスト保留音（MoH）

ゲートウェイ ベースの MoH またはユニキャスト MoH

Unified CVP のメディア サーバとしての Tomcat

Unified CVP のインストールに含まれているパッケージ化された IIS

MGCP プロトコル

SIP

G.722、iSAC、iLBC コーデック

混合コーデックのサポート

ダイヤル番号計画（DNP）

ダイヤル番号と CTI ルーティング ポイント

Note

これは詳細なリストではありません。

リファレンス設計で代替がない要素

一部の要素は代替が定義されていないため、リファレンス設計ソリューションで使用できません。このカテゴリ内の要素には、以下があります。

- 時分割多重（TDM）（サードパーティ製レガシーの自動着信呼分配統合）

- TDM NIC

- アウトソーシング展開用の親/子トポロジ

Note

これは詳細なリストではありません。

Related Information

非リファレンス設計

Chapter 3. Contact Center Enterprise ソリューションの概要

- コンタクト センター ソリューションのアーキテクチャ

- コア コンポーネント

- Cisco オプション コンポーネント

- サードパーティ コンポーネント

- 統合機能

- コール フロー

- トポロジ

- ソリューション管理

- ソリューションの保守およびモニタリング

- ローカリゼーション

コンタクト センター ソリューションのアーキテクチャ

Note

このドキュメントの最初の 4 章は、3 つの Contact Center Enterprise ソリューションの詳細を確認したいユーザ向けです。

- Packaged Contact Center Enterprise

- Cisco Hosted Collaboration Solution for Contact Center

- Unified Contact Center Enterprise

Unified CCE に特化した設計上の考慮事項およびガイドラインに関する情報は、残りの章を参照してください。

- Packaged CCE ソリューションのアーキテクチャ

- Cisco HCS for Contact Center ソリューションのアーキテクチャ

- Unified CCE ソリューションのアーキテクチャ

Packaged CCE ソリューションのアーキテクチャ

Packaged CCE は、Unified CCE の事前設計された限定的な展開モデルです。このコア コンポーネントは、https://www.cisco.com からダウンロードした OVA ファイルに記述されているオンボックスの仮想マシン（VM）として展開されます。

Packaged CCE VM は、コンタクト センターの機能に必要な一連の機能（コールと非音声タスクの処理、プロンプトと高機能な VXML スクリプティング、音声応答収集、エージェントの選択、キューイング、およびレポーティングなど）を提供します。その制御された環境、適切に定義された設定、および展開の境界によって、Packaged CCE は高可用性とソリューションのサービスアビリティを備えた強力なソリューションとなっています。さらに、順序付けと導入ロールアウトのシンプル化、操作とメンテナンスの簡易化、Unified CCE Administration（システムの設定およびシステム状態のモニタリング用の合理化されたブラウザベースの管理インターフェイス）などのメリットがあります。

Cisco HCS for Contact Center ソリューションのアーキテクチャ

Cisco HCS for Contact Center はホスト環境でほぼすべてのコンポーネントおよび機能を Unified CCE ソリューションとして提供します。Cisco HCS for Contact Center は Unified CCE モデルのサブセットをサポートしています。各自がサービス プロバイダーとして、ホスト環境のメンテナンスを管理してください。カスタマーにとってこれは、ハードウェア コストの低減と容易かつ迅速な導入を意味し、さらに、アップグレード、メンテナンス スタッフ、予測不能なコストについて心配する必要がないことを意味します。

Cisco HCS for Contact Center にはアグリゲーション レイヤと共有管理レイヤがあります。これにより、Cisco Hosted Collaboration Solution のコンポーネントが、専用のカスタマー インスタンスへの複数のネットワーク接続およびルート要求に結び付けられます。共有アグリゲーションは、PSTN とやり取りするための Hosted Collaboration Solution SBC から構成されます。共有管理は、UCDM、Unified CCDM、HCM-F、Cisco Prime Collaboration Assurance（PCA）、Cisco UCS Manager、VMware vCenter、および Cisco ASA（ファイアウォール/NAT）から構成されます。

Cisco HCS for Contact Center

Unified CCE ソリューションのアーキテクチャ

Cisco Unified Contact Center Enterprise（Unified CCE）は、インテリジェント コール ルーティング、ネットワーク対デスクトップのコンピュータ テレフォニー インテグレーション（CTI）、マルチチャネル コンタクト管理を、IP ネットワークを介してコンタクト センターのエージェントに提供するソリューションです。Unified CCE は、ソフトウェア IP 自動着信呼分配（ACD）機能を Cisco Unified Communications に統合して、企業が高度な分散型コンタクト センター インフラストラクチャを迅速に展開できるようにします。

この設計ガイドでは、スケーラビリティ、耐障害性、ソリューション コンポーネント間のインタラクションなどを含めて、展開モデルとそれらの影響について説明します。

Unified CCE 製品は、Cisco Unified Communications Manager、Cisco Unified Customer Voice Portal、Cisco VoIP Gateways、Cisco Unified IP Phones を統合します。これらの製品は連携して、インテリジェント コール ルーティング、マルチチャネル ACD 機能、音声応答装置（VRU）機能、ネットワーク コール キューイング、統合された企業全体のレポートを実現するコンタクト センター ソリューションを提供します。Unified CCE は、必要に応じて、Cisco Unified Intelligent Contact Manager と統合してレガシー ACD システムとネットワーク接続することができ、統合通信プラットフォームへの円滑な移行を実現します。

Unified CCE ソリューションは、シングルおよびマルチサイトの両方のコンタクト センターに実装できるように設計されています。Unified CCE は既存の IP ネットワークを使用して、管理コストを削減し、コンタクト センターにブランチ オフィス、ホーム エージェント、ナレッジ ワーカーを含めます。次の図は、一般的な Unified CCE のセットアップを示しています。

Unified CCE ソリューションの一般的展開

Unified CCE ソリューションは、基本的に次の 4 つのシスコ ソフトウェア製品から構成されます。

- Unified Communications インフラストラクチャ：Cisco Unified Communications Manager

- キューイングおよびセルフサービス：Cisco Unified Customer Voice Portal（Unified CVP）

Note

非リファレンス設計ではこの目的に Unified IP IVR も使用できます。

- コンタクト センターのルーティングおよびエージェント管理：Unified CCE。主なコンポーネントは、CallRouter、Logger、Peripheral Gateway、Administration & Data Server/Administration Client です。

- エージェント デスクトップ ソフトウェア：Cisco Finesse

Note

Avaya PG または親/子トポロジを使用する非リファレンス設計のみが CTI OS デスクトップを使用できます。Cisco Finesse は、他のすべての Contact Center Enterprise ソリューションで必要なデスクトップです。

このソリューションは、以下の Cisco IP Telephony インフラストラクチャ上に構築されます。

- Cisco Unified IP Phone

- Cisco 音声ゲートウェイ

- Cisco LAN/WAN インフラストラクチャ

コア コンポーネント

コンタクト センターのエンタープライズ ソリューションに着信する要求は、通常、以下の順序でコア コンポーネントとやり取りします。

1. Cisco イングレス、エグレス、および VXML ゲートウェイ

2. Cisco Unified Customer Voice Portal

3. Cisco Unified Contact Center Enterprise

4. Cisco Virtualized Voice Browser

5. Cisco Unified Communications Manager

6. Cisco Finesse

7. Cisco Unified Intelligence Center

- 入力、出力、および VXML ゲートウェイ

- Cisco Unified Customer Voice Portal

- Contact Center Enterprise

- Cisco Virtualized Voice Browser

- Cisco Unified Communications Manager

- Cisco Finesse

- Cisco Unified Intelligence Center

入力、出力、および VXML ゲートウェイ

上記のゲートウェイは、展開されたソリューションで使用できます。

- Cisco Voice TDM ゲートウェイ

- Cisco Unified Border Element

- Cisco VXML ゲートウェイ

入力、出力、および VXML ゲートウェイ

Note

音声ブラウザとは、VXML ゲートウェイまたは Cisco Virtualized Voice Browser（VVB）を指します。

TDM ゲートウェイおよび CUBE ゲートウェイは、特定の展開においてイングレス ゲートウェイ（着信コール用）およびエグレス ゲートウェイ（アウトバウンド コール用）の両方として動作します。

上記のタイプのゲートウェイは混在させることも、個別の物理ゲートウェイに配置することも可能です。

VXML ゲートウェイ機能は、Cisco IOS-XE ではサポートされません。

- Cisco TDM 音声ゲートウェイ

- Cisco Unified Border Element

- Cisco VXML ゲートウェイ

Related Concepts

入力/出力/VXML ゲートウェイの設計上の考慮事項

Cisco TDM 音声ゲートウェイ

Cisco イングレス音声ゲートウェイは、着信コールが Contact Center Enterprise ソリューションに入るポイントとなります。一方の側で時分割多重（TDM）コールを終了し、もう一方の側で VoIP を実装します。TDM 環境から VoIP エンドポイントへのコールを拡張する中心点として機能します。したがって、メディア ストリームのヘアピニングが発生しないため、WAN 帯域幅の節約につながります。また、Cisco イングレス音声ゲートウェイは、その他の Unified CVP ソリューション コンポーネントのコマンドでコール スイッチング機能も提供します。

PSTN 音声ゲートウェイでは、イングレス音声ゲートウェイを使用することができます。イングレス音声ゲートウェイでは、TDM 音声が IP に変換されて、DTMF 番号が認識され、RFC2833 イベントに変換されます。

Note

Unified CVP では、SIP-Notify または DTMF イベントの受け渡しがサポートされていません。

VXML機能はイングレス音声ゲートウェイから分離して、個別の PSTN イングレス レイヤを提供することができます。個別の PSTN レイヤと VXML により、多くの VXML セッションおよび PSTN インターフェイスをサポートする展開が可能です。多数の受信コールを処理するイングレス ゲートウェイは、さほど多くの VXML セッションをサポートすることはできません。この場合、VoiceXML セッションは、Cisco VVB といった VoiceXML ゲートウェイのみの別の形態でオフロードすることができます。

Note

使用する Cisco IOS ゲートウェイ、IOS バージョン、および Contact Center Enterprise コンポーネントがすべてサポートされている場合は、任意の TDM インターフェイスを使用することができます。

Cisco エグレス音声ゲートウェイは、コールが TDM ネットワークまたは機器に拡張される場合にのみ使用されます。たとえば、コールを PSTN または TDM 自動着信分配装置（ACD）に転送することが可能です。Real-time Transport Protocol（RTP）が音声ゲートウェイ ポート間で実行される場合、シグナリング ストリームは Unified CVP サーバと Cisco Unified Intelligent Contact Management（Unified ICM）を介した論理経路を辿ります。これにより、後続のコール制御（転送など）が可能になります。

TDM イングレス ゲートウェイおよびエグレス ゲートウェイはどちらも、Session Initiation Protocol (SIP) をサポートしています。

Cisco Unified Border Element

Cisco Unified Border Element (CUBE) は、セッション ボーダー コントローラ (SBC) として動作する Cisco のルータです。SBC は、データ、音声、およびビデオ転送用に、独立した Voice over IP（VoIP）および Video over IP エンタープライズ ネットワークを相互接続します。SBC は、単一の顧客ネットワーク内の VoIP アイランドからエンドツーエンドの IP コミュニティにネットワークを拡張するための重要なコンポーネントです。SBC は、企業内通信および、サービス プロバイダーのネットワークを越えて企業の外部との通信にも使用されます。

Note

このガイドで CUBE が論じられる場合は、サービス プロバイダーのバージョンではなく、常に Enterprise バージョンであることを意味します。

CUBE は Cisco サービス統合型ルータ（ISR）およびアグリゲーション サービス ルータ（ASR）上で動作します。Cisco クラウド サービス ルータ (CSR) は、仮想 CUBE 上で動作することが可能です。

CUBE によって、Cisco IOS および IOS XE ソフトウェア イメージに以下の機能が追加されます。

- 課金情報、セキュリティ、コール受付制御、QoS、および信号動作のためのネットワーク間インターフェイス ポイント

- SIP トランクへの移行をサポートするために必要な一連の機能

- 2 つのネットワーク間で、明確な境界ポイントとして動作する機能です。

- ネットワーク間のリアルタイム トラフィックをインテリジェントに許可または拒否する機能。

コンタクト センターのエンタープライズ ソリューションでのサードパーティ SIP トランクの使用は、CUBE を使用してサポートされています。CUBE は、SIP 正規化および相互運用性のためのセッション ボーダー コントローラ（SBC）として機能します。

- コンタクト センター ソリューション向け仮想 CUBE

Related Concepts

Cisco Unified Border Element 設計に関する考慮事項

Contact Center Enterprise ソリューション向けサイジング ゲートウェイ

コンタクト センター ソリューション向け仮想 CUBE

コンタクト センター ソリューション向け仮想 CUBE

互換性のある Cisco IOS XE のリリースでは、コンタクト センターのエンタープライズ ソリューションが、仮想化されたフォームファクターとしての CUBE をサポートしています。VMware ESXi ハイパーバイザに仮想 CUBE (vCUBE) をインストールすることができます。

仮想 CUBE は、CUBE のほとんどの機能をサポートします。メディア プレーンの管理機能は、Cisco クラウド サービス ルータ（CSR）では機能しません。仮想 CUBE には、以下の機能の制限があります。

- デジタル信号プロセッサ (DSP) 機能はサポートされません。

- 音声およびビデオ コーデックのトランス コーディングまたは変換

- DTMF インターワーキング

- コール プログレス分析（CPA）

- ノイズ リダクション（NR）、アコースティック ショックの防止（ASP）、および音声ゲイン

- IOS ベースのハードウェア MTP

- 会議中の G.729 と G.711 の混合

- DSP 高可用性

- 高可用性保護モード (同じホスト上のインスタンス)

Note

物理 CUBE で使用できる DSP の代わりに、Unified CM が制御するマルチ コーデック、ソフトウェア会議、およびMTPを使用することができます。ソリューションで CPA または混合コーデックが会議用に必要な場合は、専用の物理ゲートウェイを追加することができます。

- 音声クラス コーデック（VCC）の一部サポートピア レッグでサポートされるコーデックが提供されています。その他のコーデックは除外されます。

- アウトバウンド オプションはサポートされません。

vCUBE のサポートの詳細については、http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v-series/products-installation-and-configuration-guides-list.html の Cisco Unified Border Element コンフィギュレーション ガイド の vCUBE のセクション、および https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.htmlの 互換性マトリクス を参照してください。

Cisco VXML ゲートウェイ

集中型展開モデルには、多くの場合、VXML ゲートウェイが含まれます。VXML ゲートウェイは、VXML サーバの VXML ページを解釈します。

Note

音声ブラウザ とは、VXML ゲートウェイまたは Cisco Virtualized Voice Browser（Cisco VVB）を指します。

VXML ゲートウェイのサードパーティ メディア サーバからの音声プロンプトをキャッシュして、WAN 帯域幅を削減し、音声品質の低下を防止することができます。VXML ドキュメントは、再生する音声ファイルの場所へのポインタ、または音声をストリーミングする音声合成（TTS）サーバのアドレスを提供します。VXML ゲートウェイは、Media Resource Control Protocol（MRCP）を介して自動音声認識（ASR）および TTS サーバと対話します。

Unified CVP イングレス音声ゲートウェイの展開と同じルータに Cisco IOS VXML ゲートウェイを展開することができます。このモデルは、小規模なブランチ オフィスでの展開に適しています。Cisco IOS VoiceXML ゲートウェイは、個別のルータ プラットフォームでも実行することができます。このモデルは、大規模または複数の音声ゲートウェイでの展開で、Unified CVP のトラフィックの割合がごくわずかな場合に適しています。このモデルを使用して、組織は、オフィスのユーザ、コンタクト センター エージェント、および着信番号に基づくルート コール間で公衆スイッチ電話交換網（PSTN）トランクを共有することができます。VoiceXML ゲートウェイは、フラッシュ メモリまたはサードパーティのメディア サーバに音声ファイルを保存することができます。

Cisco IOS VoiceXML ゲートウェイとイングレス音声ゲートウェイを組み合わせない限り、Cisco IOS VoiceXML ゲートウェイに TDM ハードウェアは必要ありません。一方のサイドでは VoIP と対話し、もう一方のサイドでは HTTP（VXML または .wav ファイル伝送）および MRCP（ASR および TTS トラフィック伝送）と対話します。イングレス音声ゲートウェイの場合と同様、Cisco IOS VoiceXML ゲートウェイは多くの場合、集中型展開モデルの形態で展開されます。あるいは、ブランチ展開でオフィス毎に 1 つ展開されます。

Cisco VVB は別の仮想マシンに展開することができます。このモデルはスタンドアロンおよび包括展開の両方に最適です。Cisco VVB は MRCP を使用して ASR/TTS と通信します。

Note

Cisco IOS-XE には、音声ブラウザ機能が組み込まれていません。このため、Unified CVP で IOS-XE イングレス ゲートウェイを展開するには、個別の ISR G2 ゲートウェイまたは Cisco VVB を使用して音声ブラウザを提供する必要があります。

Cisco Unified Customer Voice Portal

Cisco Unified Customer Voice Portal は、インテリジェントなアプリケーション開発と業界有数のコール制御に、音声に対するオープン標準のサポートを結び付けます。

Unified Customer Voice Portal（Unified CVP）は、Cisco Unified Computing System（UCS）ハードウェアまたは仕様ベースの同等製品で実行されるソフトウェア アプリケーションです。Unified CVP は、標準の Web ベースのテクノロジーを使用して、入力要求、情報収集、キューイング、およびコール制御サービスを提供します。そのアーキテクチャは、耐障害性と高い拡張性を備えた分散型アーキテクチャです。CVP では音声は Cisco Voice Browser で終了します。Cisco Voice Browser は、HTTP/HTTPS（音声）と SIP（コール制御）を使用して Unified CVP アプリケーション サーバとやり取りします。Unified CVP には次のサブコンポーネントがあります。

- CVP コール サーバ

- CVP VXML サーバ

- CVP メディアサーバ

- CVP レポートサーバ

Contact Center Enterprise ソリューションにおける Unified CVP

Unified CVP ソフトウェアは、アプリケーション制御用の Unified CCE ソフトウェアと堅固に統合されています。Unified CVP は、音声応答装置（VRU）の周辺機器ゲートウェイ インターフェイスを使用して Unified CCE とやり取りします。Unified CCE スクリプト環境は、ビルディングブロック機能（メディアの再生、データの再生、メニュー、情報収集など）の実行を制御します。Unified CCE スクリプトは、CVP VXML サーバによる実行に対して外部 VXML アプリケーションを起動できます。

CVP Call Studio は、VRU アプリケーション開発用の Eclipse ベースの IDE です。VXML サーバは、それらの VRU アプリケーションをホストするアプリケーション サーバです。VXML サーバは、高度な大容量 VRU アプリケーションを処理します。カスタムまたはサード パーティの J2EE ベースのサービスとやり取りすることもできます。オプションの CUSP サーバまたは CVP に組み込まれている SIP サーバ グループを使用して、ロード バランシングを実現できます。

Unified CVP は、あらかじめ録音された複数の言語によるアナウンスメント用の複数の文法をサポートできます。CVP は、必要に応じて、自動音声認識機能と音声合成機能を提供できます。CVP は、Unified CCE ソフトウェアを介してカスタマーのデータベースやアプリケーションにアクセスすることも可能です。

また、Unified CVP は、Unified CCE ソリューションにキューイング プラットフォームを提供します。音声コールとビデオ コールは、コンタクト センターのエージェント（または外部システム）にルーティングされるまで CVP のキューに格納しておくことができます。システムでは、発信者が保留されている間に音楽またはビデオを再生できます。Unified CCE がエージェントにコールをルーティングすると、エージェントはエージェント デスクトップ アプリケーションから発信者にビデオを送信できます。

- CVP コール サーバ

- CVP VXML サーバ

- CVP メディアサーバ

- CVP レポートサーバ

- Unified CVP オペレーションコンソールサーバ

- Unified CVP Call Studio

- CVP インフラストラクチャ

Related Concepts

CVP 設計上の考慮事項

セキュアなシグナリングおよびメディアの設計と構成

CVP コール サーバ

コール サーバ コンポーネントは、次の独立サービスを提供します。これらのサービスはすべて同じ Windows サーバ上で実行されます。

- SIP サービス：このサービスは、Contact Center Enterprise ソリューションのコンポーネント（SIP プロキシ サーバ、イングレス ゲートウェイ、Unified CM SIP トランク、SIP フォンなど）と通信します。SIP サービスは、Back-to-Back User Agent（B2BUA）を実装します。この B2BUA は、イングレス音声ゲートウェイからの SIP invite を受け入れ、通常は、使用可能な音声ブラウザ ポートにこれらのコールを転送します。コールの設定が完了すると、Unified CVP B2BUA は、以降の呼制御のアクティブな中継点として機能します。Unified CVP SIP シグナリングはこのサービスを介してルーティングされますが、このサービスは RTP トラフィックには影響しません。このB2BUA への統合は、ICM サービスを介して Unified CCE と対話できることを意味します。この統合により、SIP サービスは、ルーティング指示およびサービス制御についてのクエリを Unified CCE に対して実行することができます。また、この統合により、Unified CCE は転送などの後続のコール制御を開始することもできます。

- ICM サービス：このサービスは、Unified CVP コンポーネントと Unified CCE との間のすべての通信を担当します。これは、SIP サービスおよび IVR サービスの代わりにメッセージを送受信します。

Note

IVRサービスは、VXML サーバの一部となります。

CVP VXML サーバ

VXML サーバは、音声ブラウザと VXML ページを交換することにより、高度な VRU アプリケーションを実行します。他のほぼすべての Unified CVP 製品のコンポーネントと同様、Java 2 Enterprise Edition（J2EE）アプリケーション サーバ環境内で動作します。独自のカスタム ビルド J2EE コンポーネントを追加して、バックエンド ホストおよびサービスと対話させるという導入方法が多くみられます。VXML サーバ アプリケーションは、Cisco Unified Call Studio を使用して構築され、VXML サーバに導入されて実行されます。これらのアプリケーションは、Unified CCE ルーティング スクリプト内で実行する必要がある特定のマイクロ アプリケーションによって必要なときに呼び出されます。

VXML サーバ は、Unified CCE コンポーネントを含まないスタンドアロン コンフィギュレーションで展開することもできます。アプリケーションは音声ブラウザに到達するコールの直接の結果として呼び出され、単一のポスト アプリケーション転送が許可されます。

Note

IVRサービスは、VXML サーバの一部となります。したがって、現在のところ、マイクロ アプリケーションの実行に VXML サーバ ポート ライセンスが使用されています。以前のリリースでは、IVR サービスはコール サーバに含まれていました。

IVR サービスは、Unified CCE から受信した外部スクリプトの実行指示に基づいて、Unified CVP マイクロ アプリケーションを実装するVXM Lページを作成します。IVR サービスは VRU レッグ（Unified ICM Enterprise 中の用語）として機能します。マイクロ アプリケーションを実行するために、コールを SIP サービスから IVR サービスに転送する必要があります。このモジュールが作成する VXML ページは、音声ブラウザに送信されて実行されます。IVR サービス：Unified CVP マイクロ アプリケーションから VoiceXML ページへ、そしてその逆方向の変換を行います。

CVP メディアサーバ

メディア サーバのコンポーネントは事前に録音された音声ファイル、外部 VXML ドキュメント、または外部の自動音声認識（ASR）の文法をゲートウェイに提供する Web サーバです。これらのファイルの一部はゲートウェイのローカル フラッシュ メモリに保存できます。ただし、実際には、ほとんどのインストールで集中型メディア サーバを使用して、録音済みプロンプト更新の配布を簡素化しています。メディア サーバ機能には、キャッシング エンジンも含まれています。ただし、ゲートウェイ自体も、キャッシング用に設定すれば、プロンプトのキャッシングを実行できます。

Note

Unified CVP のメディア サーバ コンポーネントは、Unified CVP コール サーバおよび Unified CVP VXML Server とともに、デフォルトでインストールされます。

メディア サーバは、シンプレックス オペレーションとして、冗長ペアとして、またはファームでサポートされるロード バランサで展開できます。音声ブラウザは、メディア サーバから取得した .wav ファイルをキャッシュします。ほとんどの展開では、メディア サーバが Unified CVP から受信するトラフィックは少なくなります。

CVP レポートサーバ

Unified CVP レポート サーバは、分散型セルフ サービス展開向けの統合履歴レポートを提供します。ソリューションでサービス コールバック、トランク グループ レポート、および VRU レポートが必要とされる場合を除き、CVP レポートサーバはオプションとなります。

CVP レポート サーバは、IBM Informix Dynamic Server（IDS）データベース管理システムをホストする Windows サーバ上で実行されます。データベース スキーマは事前設定されており、Unified Intelligence Center およびその他のレポート ソリューションを使用してカスタム レポートを開発することができます。

レポート サーバはコール サーバおよび VXML サーバに対してローカルである必要があります。CVP レポート サーバと VXML レポート トラフィックに使用する CVP コール サーバ間の遅延が80ミリ秒未満の場合、WANを介したリモート ロケーションでのレポート サーバの展開はサポートされます。これは、WAN 帯域幅が制約にならないことが前提となります。ローカルの CVP コール サーバを使用して リモート サイト を展開している場合は、ローカルの CVP レポート サーバを リモート サイトで使用する必要があります。ただし、リモート サイト 間の遅延が80ミリ秒 RTT 未満の場合、リモート サイト 間で、WAN を介して CVP レポート サーバを他方の リモート サイト のCVP コール サーバに提供させることができます。

レポート サーバは、SIP サービス（使用している場合）、およびVXML サーバの IVR サービスからレポート データを受信します。Reporting Server は、コール レコードの受信をコール サーバに依存しています。

レポート サーバは、データベースの管理アクティビティおよびメンテナンス アクティビティ（バックアップおよび消去等）は実行しません。 ただし、Unified CVP では、オペレーションコンソールサーバ を介して上記メンテナンス タスクを実行します。

Unified CVP オペレーションコンソールサーバ

Unified CVP オペレーションコンソールサーバ は、すべての Unified CVP 製品コンポーネントのブラウザ ベースの管理および構成のためのオペレーション コンソールを提供する Windows サーバです。他の Unified CVP ソリューション コンポーネントを管理および設定するインターフェイスへのショートカットがあります。Operations Console は、すべての Unified CVP 展開における必須コンポーネントです。

Operations Console は、他の Unified CVP デバイスとは別のサーバ上で実行する必要があります。Operations Console は、実際には Unified CVP の展開全体を管理できるダッシュボードです。Operations Console は、展開されたソリューション ネットワークのマップで設定されている必要があります。これにより、Operations Console は、展開されている各コンポーネントからコンフィギュレーション情報を収集し、保持できます。ネットワーク マップおよび構成情報は共にサーバにローカルに保存されます。Operations Console は、ネットワーク マップおよび保存されているコンフィギュレーション データを表示して変更するオプション、および影響を受けるソリューション コンポーネントに変更内容を配布するオプションを提供します。

Operations Console では、管理対象コンポーネントのコンフィギュレーション パラメータの 2 つのビューを表示できます。ランタイム ビューには、管理対象コンポーネントが使用するときのすべてのコンフィギュレーション パラメータのステータスが表示されます。設定済みまたはオフラインのビューでは、Operations Server データベースに保存されているすべてのコンフィギュレーション パラメータのステータスが表示され、保存と導入のオプションが実行されたときにデバイスに導入されます。

Operations Console を使用すると、ターゲット コンポーネントがオンラインでない場合や実行されていない場合でも、コンフィギュレーション パラメータを更新または事前設定できます。ターゲット サーバが（サービスは除いて）オンラインになると、設定済みの設定をそのサーバに適用できます。これらの設定は、サーバのサービスがオンラインになってもアクティブになり、ランタイム ビューにのみ反映されます。

オペレーションコンソールサーバ は、冗長なコンポーネントではありません。したがって、展開内の オペレーションコンソールサーバ を複製できません。定期的に、または変更を加えたときは必ず、コンフィギュレーション データベースをバックアップしてください。

Unified CVP Call Studio

Cisco Unified Call Studio は、Unified CVP VXML サーバ アプリケーション向けのサービス作成環境（スクリプト エディタ）です。オープン ソースの Eclipse フレームワークをベースにしており、高度なドラッグアンドドロップによるグラフィック編集機能が用意されています。Call Studio では、アプリケーションがネットワーク内の他のサービスとの連携できるようにするベンダー提供のプラグインおよびカスタマイズしたプラグインを挿入できます。Call Studio は基本的にオフライン ツールです。Unified CVP VXML サーバと通信する勇逸の理由は、コンパイルしたアプリケーションとプラグインされたコンポーネント配信して実行するためです。

Call Studio には、ビジネス ロジックに焦点を合わせた環境が用意されています。ツールは、ロジックを XML に変換する詳細を処理します。

Call Studio によってコードが生成されます。

Call Studio ライセンスは、Call Studio が動作するマシンの MAC アドレスと関連付けられます。通常、上記の目的で 1 つ以上のデータ センター サーバを指定します。Cisco Unified Call Studio は、仮想マシンまたは Windows PC 上で実行されます。

CVP インフラストラクチャ

Unified CVP インフラストラクチャには、診断ポータル API をサポートするサービス レイヤである Web Services Manager が含まれています。

Unified CVP インフラストラクチャは次の MIB をサポートします。

- Web Services Manager によってサポートされる診断ポータル API。

- Unified System コマンド ライン インターフェイス（CLI）はクライアント ツールで、診断データを収集するために、診断ポータル API およびその他の API をサポートします。

- ライセンス：

- FlexLM をサポートするすべての CVP コンポーネントの共通ライセンス。

- ライセンスは、ライセンス機能 CVP_SOFTWARE が追加されている場合にのみ有効です。この機能は、最新版の CVP を実行する権限が付与されているかを確認するために使用されます。

- ログおよびトレース メッセージが拡張された製品間のサービスアビリティ。

CVP WebServices Manager（WSM）は、Remote Operations Manager（ROM）のみのインストールを含む、すべての Unified CVP Server に自動的にインストールされるコンポーネントです。WSM は、さまざまなサブシステムおよびインフラストラクチャ ハンドラと対話し、応答を統合して XML 応答を発行します。WSM は、各インターフェイスでのセキュアな認証およびデータ暗号化をサポートしています。

次の図は、2 つのインターフェイスが Web サービス管理（WSM）と対話して、Unified CVP コンポーネントに関する情報を提供する方法を示しています。

Web サービス レイヤの一般的使用

Contact Center Enterprise

Unified Contact Center Enterprise（Unified CCE）は、以下のコンタクト センター機能を備えています。

- エージェントの状態管理

- エージェント選択

- コールとタスクのルーティングおよびキュー制御

- VRU インターフェイス

- CTI デスクトップのポップアップ画面

- コンタクト センターのレポート データ

Contact Center Enterprise ソリューションにおける Unified CCE

Unified CCE は、Cisco Unified Computing System サーバまたは完全な同等要素上の VM で動作します。次の表は、Unified CCE の主要コンポーネントを示しています。

Unified CCE コア コンポーネント

Unified CCE ソフトウェア コンポーネント

説明

コール ルータ（ルータ）

コールまたはカスタマー コンタクトのルーティング方法に関するすべての決定を行います。ルータはセントラル コントローラの一部です。

Logger

コンタクト センターの設定データを保存するデータベース サーバ。また、Logger は、ディストリビューションの履歴レポート データをデータ サーバに一時的に保存します。Logger はセントラル コントローラの一部です。

Peripheral ゲートウェイ（PG）

周辺機器へのインターフェイス（Unified Communications Manager、VRU（Unified CVP）など）、またはマルチチャネル製品（ビジネス チャットおよび E メール、または タスク ルーティング API を使用するサードパーティ製マルチチャネル アプリケーション）。

Contact Center Enterprise ソリューションの標準的な配置では、1 つの VM 上に Agent PG、VRU PG、MR PG が混在しています。各 PG には、特定のデバイス インターフェイス用のペリフェラル インターフェイス マネージャ（PIM）が 1 つ以上含まれています。

Important

Contact Center Enterprise ソリューションでは、標準の 3 つの共存画面レイアウトで、より高レベルの設定制限のみを使用することができます。

Administration & Data Server

設定インターフェイスとリアルタイム/履歴データ ストレージを提供します。複数の構成にこのコンポーネントを展開できます。

ライブデータサーバ

Unified CCE ライブ データ レポート用にルータと PG からのイベントを処理します。

- Unified CCE サブコンポーネンツの用語

- Unified CCE および Unified ICM

- ルータ

- Logger

- Peripheral Gateway

- Administration & Data Server

- ライブ データ

Related Concepts

Contact Center Enterprise 設計上の考慮事項

Unified CCE サブコンポーネンツの用語

上記の Unified CCE サブコンポーネントの組み合わせは、以下の名前で呼ばれることがあります。

名前

説明

CCE セントラル コントローラ

ルータおよび Logger

CCE Rogger

同じ VM 上で実行されるルータおよび Logger

CCE コール サーバ

ルータおよび PG

CCE データ サーバ

Logger および AW

Unified CCE および Unified ICM

コンタクト センターのコア コンポーネントには、Cisco Unified Contact Center Enterprise（Unified CCE）および Cisco Unified Intelligent Contact Management（Unified ICM）の 2 つの構成があります。

IP スイッチやエージェントへの転送などの高度なコール制御には Unified CCE または を使用します。両者ともに、コール センター エージェント管理機能およびコール スクリプト機能を提供します。いずれの環境で実行されるスクリプトも、Unified CVP アプリケーションにアクセスすることができます。

Unified CCE

Unified CCE は、ほとんどのソリューションで使用される標準バージョンです。これらのソリューションでは、Unified CCE がコールを処理するエージェントを選択します。Unified CM は ACD として機能します。

Unified ICM

United ICM は、サードパーティ ACD へのネットワーク ルーティングを含む非リファレンス設計ソリューションで使用します。これらのソリューションでは、Unified ICM はサードパーティ ACD にコールを送信し、サードパーティ ACD はコールを処理するエージェントを選択します。

ルータ

ルータは、Unified CCE の頭脳部です。コールまたはタスクが到着すると、その連絡先に何が起こるかを決定するルーティング スクリプトがトリガされます。ルータは、スクリプトの結果に基づき、連絡先をある場所から別の場所にリダイレクトし、その連絡先を処理するエージェントを選択します。ルータは、サイド A およびサイド B と呼ばれる冗長ペアで動作します。通常、両方のサイドが有効化されています。分散型のこの 2 つのインスタンスは、メッセージ配信サブシステム (MDS) を使用して、ロックステップを相互に保持します。両方のサイドがすべてのデータと制御メッセージを共有し、同じデータをルーティングの決定に使用します。冗長展開を使用すると、1 つのサイドに障害が発生した場合でもシステムを確実に動作させることができます。もう一つのサイドが、障害発生時でも継続的に連絡先をルーティングします。

Logger

Unified CCE は、コール センターに関する履歴データと設定データを保存するために Logger を使用します。Logger では履歴データが収集され、後に配布されます。Logger は、ルータと同様に、冗長ペアとして配置します。Logger の各サイドは、対応するルータからのメッセージのみを受信します。たとえば、サイド A のルータは、メッセージをサイド A Logger に送信します。ルータはロック ステップで動作するため、両サイドの Logger は、通常の操作中に同じメッセージを受信します。いずれかのサイドで障害が発生した後、Logger は上記データをルータ経由で再同期します。Logger は、履歴データを履歴データ サーバ (HDS) に配信します。また、Logger は、設定データとリアルタイム データをメッセージ区切りサブシステム (MDS) を使用して管理サーバおよびデータ サーバに配布します。

採用するソリューションに応じて、Logger はルータ (Rogger モデル) で同じ VM 上に配置するか、または別の VM (ルータ/ Logger モデル) 上に配置します。

Peripheral Gateway

周辺機器ゲートウェイ (PG) は、CTI インターフェイスを介して、電話機やマルチ メディア デバイスとの通信を処理します。PG は、ACD、VRU デバイス、または IP PBX と通信を行うことが可能です。PG は、各種デバイスのプロトコルを正規化します。PG は、各デバイス上のエージェントとコールの状態を追跡します。PG は、このステータスをルータに送信し、顧客ロジックを必要とする要求をルータに転送します。PG には、以下のプロセスを含めることができます。

- 周辺機器インターフェイス マネージャ (PIM)

- コンピュータ テレフォニー インテグレーション（CTI）[こんぴゅーたてれふぉにーいんてぐれーしょんCTI]

- Java テレフォニー API

Contact Center Enterprise リファレンス設計 の標準的なレイアウトでは、単一の VM 上にエージェント PG、VRU PG、MR PG が混在しています。PIM はプロトコルの正規化を処理します。PIM は周辺機器と通信し、Unified CCE が理解できるように周辺機器の専用言語を 1 つに変換します。CTI ゲートウェイ (CG - CTI サーバ コンポーネント) も、PG と共存します。

Important

Contact Center Enterprise ソリューションでは、標準の 3 つの共存画面レイアウトで、より高レベルの設定制限のみを使用することができます。

Unified CCE は、いくつかのタイプの PG をサポートしています。

- エージェント PG: Unified Communications Manager (Unified CM) への接続

- 音声応答ユニット (VRU)] PG: CVP への接続。

- メディアリソース（MR）PG — ビジネス チャットおよび E メール または のようなマルチメディア コンポーネントへの接続。Customer Collaboration Platform

- サードパーティ TDM の ICM Enterprise PG (非リファレンス設計のみ):

- Aspect Call Center PG

- Avaya CVLAN PG (CMS および CMS なし)

- Avaya TSAPI PG (CMS および CMS なし)

- Avaya Aura PG (AAS オプションなし)

他の Unified CCE コア コンポーネントと同様、PG を冗長ペアで導入します。

PG の 単一のクラスは、エージェントが存在する ACD または Unified CM と通信します。上記 PG は、スイッチに専用の CTI プロトコルを使用して、エージェントの状態とデバイス上のキューにあるコールを保持します。別の PG クラスが、クライアント中立のインターフェイスを公開します。VRU PG は、音声コールに合わせてカスタマイズされたインターフェイスを公開します。その他の一般的なタスクのルーティングは MR PG がインターフェイスを公開します。

Unified CCE では、VRU と Unified CM は別の周辺機器として扱われます。この分割によって柔軟性が提供されます。複数の VRU 間で負荷分散することができます。

Note

非リファレンス設計では、VRU の PG を Unified IP IVR 周辺機器に接続することができます。

TDM PG で非リファレンス設計を展開する場合は、変換ルートを使用して、周辺機器間でコールを移動させます。コールが接触する各周辺機器に個別にルーティング制御されます。システムは、コールが接触する各周辺機器の終了コール詳細 (TCD) 記録を作成します。

大規模なマルチサイト (multicluster) の展開では、多くのエージェント PG が含まれます。こういった展開では、Unified CCE がすべてのエージェントとコールを集中型で追跡します。Unified CCE は、使用するサイトまたはクラスタに関わらず、最適なエージェントにコールを転送することが可能です。この調整により、1 つの企業規模のキューを持つ企業規模の論理的なコンタクト センターが作成されます。

以下の図は、PG および他のソリューション コンポーネント間の通信を示しています。

PG およびその他のコンポーネント間の通信

- 周辺機器インターフェイス マネージャ

- CTI サーバ

- JTAPI コミュニケーション

周辺機器インターフェイス マネージャ

各 Unified CM クラスタに対して、1 つのエージェント PG に 1 つの Unified CM PIM が存在します。各冗長エージェント PG は、最大 2000 人のエージェントをサポートすることができます。拡張性のために、一部の展開では、同じクラスタに対して複数の PIM が必要となります。それぞれの PIM を別のエージェント PG に展開します。各 VM のエージェント PG は 1 つだけ導入します。

各 CVP サーバまたは Unified IP IVR には、1 つの VRU PIM が存在します。VRU PIM は、VRU PG、または非リファレンス設計で、汎用的な PG に展開させることができます。

CTI サーバ

各エージェントの PG には、CTI サーバが含まれています。CTI サーバは、エージェント デスクトップからのコールの制御およびエージェント要求を処理を行います。エージェント PG では、どのサイドがアクティブであるかに応じて、CTI サービスが一方のサイドまたは他方のサイドに接続されます。CTI サーバは、エージェントの状態要求を処理し、ルーティング決定を検討するために集中型コントローラを更新します。PG は、コール制御要求を Unified CM に転送します。これにより、電話機のエンドポイントが監視され、制御されます。CTI サーバは、エージェントのデスクトップおよびエージェントの IP フォンの状態との同期を維持します。

JTAPI コミュニケーション

Unified CM の PIM サインイン プロセスは、Unified CM クラスタとアプリケーション間で JTAPI 通信を確立します。CTI マネージャは、JTAPI 経由で Unified CCE に交信します。クラスタ内のすべてのサブスクライバは、CTI マネージャ インスタンスを実行します。ただし、PG 上の Unified CM PIM は、クラスタ内で 1 つの CTI マネージャ (つまり 1 つのノード) のみと通信します。この接続された CTI マネージャは、クラスタ内の他のノードに対して CTI メッセージを渡します。PG の各冗長ペアは、一意の JTAPI ユーザ ID を共有します。ユーザ ID は、CTI マネージャがさまざまなアプリケーションを追跡する方法として使用されます。

たとえば、サブスクライバ 1 が音声ゲートウェイ (VG) に接続し、サブスクライバ 2 は CTI マネージャを介して Unified CCE と通信します。また、コールが VG に到着すると、サブスクライバ 1 は、クラスタ メッセージをサブスクライバ 2 に送信します。サブスクライバ 2 は、コールのルーティング方法を決定するために、Unified CCE にルート要求を送信します。

クラスタと Unified CCE 間の JTAPI 通信には、以下の 3 つの異なるタイプのメッセージが含まれています。

- ルーティング制御: クラスタが Unified CCE からのルーティング命令の要求を可能にするメッセージ。

- デバイスおよびコールのモニタリング: クラスタが Unified CCE に、デバイス (電話機) またはコールの状態の変更について通知可能なメッセージ。

- デバイスおよびコール制御: クラスタが、デバイス (電話機) またはコールの制御方法について Unified CCE から指示を受信可能にするメッセージ。

ほとんどのコールでは、数秒間で 3 つのタイプの JTAPI 通信がすべて使用されます。新しい通話が到着すると、Unified CM が、Unified CCE からルーティング命令を要求します。サブスクライバが Unified CCE からのルーティング応答を受信すると、サブスクライバは、そのコールをエージェントの電話機に送信します。サブスクライバは、電話機が鳴っていることを Unified CCE に通知します。この通知によって、エージェント デスクトップの [応答] ボタンが有効化されます。エージェントが [応答] ボタンをクリックすると、Unified CCE は、電話機をオフフックにしてコールに応答するようにサブスクライバに指示します。

ルーティング制御通信を行うには、サブスクライバは CTI ルート ポイントを必要とします。CTI ルート ポイントは、特定の JTAPI ユーザ ID に関連付けられます。この関連付けによって、サブスクライバは、その CTI ルート ポイントに対してルーティング制御を提供するアプリケーションがどれかを知ることができます。次に、ダイヤル番号 (DN) が、CTI ルート ポイントに関連付けられます。これにより、サブスクライバは、その DN に対して新しいコールが到着すると、Unified CCE へのルート要求を生成することが可能です。

Note

別のパーティションの別の CTI ルート ポイントでの CTI ルート ポイントの DN は使用できません。DN がすべてのパーティション上のすべての CTI ルート ポイントで一意であることを確認します。

Administration & Data Server

管理サーバおよびデータ サーバは、Unified CCE 設定へのメインのインターフェイスです。管理サーバおよびデータ サーバには、Logger からの設定情報のコピーを含むデータベースが含まれています。管理サーバおよびデータ サーバは、中央コントローラから更新を受信して、データベースの同期を維持します。クライアントは、データベースから設定を読み取り、中央コントローラを経由して更新を送信することができます。Administration & Data サーバの主なクライアントは、GUI 構成ツールであり、構成 API（ConAPI）を提供する Configuration Management サーバ（CMS）です。

実稼働システムでは、各管理サーバおよびデータ サーバをルータおよび Logger から個別の VM にインストールして、リアルタイム コール処理が中断されないことを確認します。Contact Center Enterprise のラボシステムでは、管理サーバおよびデータ サーバをルータおよび Logger と同じ VM にインストールすることができます。

ストレージ仮想化展開の詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-unified-contact-center-enterprise.htmlの Unified Contact Center Enterprise 仮想化 を参照してください。

管理サーバおよびデータ サーバを役割の組み合わせによって導入すると、導入環境に適した拡張性を得ることができます。

- 管理およびリアルタイム データ サーバ（AW）

- 管理サーバおよび履歴データ サーバ（AW-HDS）

- 管理サーバ、履歴データ サーバ、および詳細データ サーバ（AW-HDS-DDS）

- 履歴データ サーバおよび詳細データ サーバ (HDS-DDS)

管理サーバおよびデータ サーバは、他のコア コンポーネントとは違い、冗長ペアでは導入しません。その代わりに、Logger 毎に 1 つの管理サーバおよびデータ サーバを導入します。1 つの管理サーバおよびデータ サーバが失敗した場合、クライアント AW は別のサーバにログインすることができます。

AW は、Cisco Finesse の認証サーバとして動作します。Cisco Finesse 導入では、AW は必須で、高可用性モード (プライマリ AW およびバックアップ AW) で実行する必要があります。

- 管理およびリアルタイム データ サーバ（AW）

- 履歴データ サーバおよび詳細データ サーバ (HDS-DDS)

- 管理サーバおよび履歴データ サーバ（AW-HDS）

- 管理サーバ、履歴データ サーバ、および詳細データ サーバ（AW-HDS-DDS）

管理およびリアルタイム データ サーバ（AW）

このサーバは、Cisco Unified Intelligent Center (レポート クライアント) で設定変更とリアルタイム レポートを処理します。AW のリアルタイム データ サーバ部分は、AW データベースを使用してリアルタイム データおよび設定データを保存します。リアルタイム レポートは、上記 2 種類のデータを結合して、現在の状態に近いシステムのスナップショットを提示します。この役割は履歴レポートをサポートしていません。通常、システム管理者は、設定ユーザが構成する情報へのアクセスを制御するために AW を使用します。

設定およびリアルタイム レポート AW

AW を導入して、以下の通りのモデルの拡張性に関する設定タスクのみを処理することができます。

- 設定のみの管理サーバ

- 管理クライアント（旧 クライアント AW）

こういった設定のみのモデルでは、リアルタイム レポートがオフになっています。

この展開の役割を使用すると、特定の Unified CCE 顧客インスタンスを設定する Unified CCMP を設定することができます。このような軽度の管理サーバおよびデータサーバでは、負荷は低いため、単一のサーバで十分です。

設定専用 AW

設定専用管理サーバは AW と同じサーバですが、リアルタイム データは含まれていません。そのため、管理クライアントはこういったサーバに接続できず、スクリプト エディタでリアルタイム データを表示することもできません。

管理クライアント（旧 クライアントAW ）は管理の役割を果たしますが、拡張性を持たせるため、管理サーバのクライアントとして展開されます。管理クライアントは、設定を表示および変更し、AW からリアルタイム レポート データを受信することができます。ただし、データ自体は保存されず、データベースも持ちません。

AW は、エージェントの作成、スキル グループ、プレシジョン キュー、ルーティング スクリプトなどのタスク用の設定ツールをサポートしています。

プライマリ AW は、設定データの中央コントローラーと直接通信します。セカンダリ AW を設定して、リアルタイム レポート向けにスケーリングを提供するようにすることができます。通常の操作中は、セカンダリ AW はデータのプライマリ AW に接続します。プライマリ AW で障害が発生すると、セカンダリ AW が中央コントローラに接続されます。

Note

Unified Contact Center 管理ポータル (Unified CCMP) および Unified CCE 管理 Web ツールは、プライマリ AW に接続する必要があります。セカンダリ AW に接続すると、設定変更の保存中にエラーが発生します。セカンダリ AW は、レポート ユーザの拡張性を向上するために使用される非リファレンス設計機能です。

AW は、中央コントローラと共存させることも、リモート展開することも可能です。プライマリおよびセカンダリの AW は一緒にまたは個別に導入することができます。

管理クライアントを使用している場合は、複数の管理クライアントをプライマリまたはセカンダリ AW に導入して、接続することができます。ただし、AW は地理的にはローカルで展開します。

Note

管理者クライアントおよび管理ワークステーションは、リモート デスクトップ アクセスをサポートしています。ただし、一度に 1 つのクライアントまたはワークステーションにアクセスできるエージェントは 1 人のみです。Unified CCE は、同じクライアントまたはワークステーション上の複数のユーザによる同時アクセスをサポートしていません。

履歴データ サーバおよび詳細データ サーバ (HDS-DDS)

このロールは、コールの詳細 (TCD および RCD) レコード用のデータ抽出およびカスタム レポートのみを処理します。このタイプのサーバは、冗長 Logger のペアの両サイドに 1 つのみ含めることができます。この役割は、以下の機能はサポートしていません。

- リアルタイム データ レポート

- コンフィギュレーションの変更

履歴データ サーバおよび詳細データ サーバ (HDS-DDS)

履歴データサーバ (HDS) および詳細データサーバ (DDS) は、長期的な履歴データのストレージを提供します。HDS には、レポート用に 15 分間隔または 30 分間隔で要約された履歴データが保存されます。DDS には、コール レース用に各コールまたはコール セグメントに関する詳細情報が保存されます。ウェアハウスおよびカスタム レポートには、いずれのソースからでもデータを抽出することができます。

通常、プライマリ AW を備えたデータ サーバは、3 つの役割すべてを提供する単一サーバとして導入します (AW-HDS-DDS)。大規模展開では、機能は AW の優れた拡張性によって分散させることができるため、HDS-DDS を使用します。

管理サーバおよび履歴データ サーバ（AW-HDS）

このロールは、設定の変更、リアルタイム レポート、および履歴レポートを処理します。このサーバは、リアルタイム レポートおよび履歴レポートに、Cisco Unified Intelligent Center レポート ユーザを使用します。この役割は、以下の機能はサポートしていません。

- コールの詳細、コール変数、およびエージェント状態トレース データ

- カスタム レポートのデータ抽出

管理サーバおよび履歴データ サーバ（AW-HDS）

リアルタイム データ サーバは、AW データベースを使用して、リアルタイムのデータと設定データを保存します。リアルタイム レポートは、上記 2 種類のデータを結合して、現在の状態に近いシステムのスナップショットを提示します。

履歴データサーバ (HDS) は、長期的な履歴データ ストレージを提供します。HDS には、レポート用に 15 分間隔または 30 分間隔で要約された履歴データが保存されます。ウェアハウスおよびカスタム レポートには、HDS からデータを抽出することができます。

中央コントローラと管理サーバおよびデータ サーバ間の通信

中央コントローラと複数の管理サーバおよびデータ サーバ間の通信

管理サーバ、履歴データ サーバ、および詳細データ サーバ（AW-HDS-DDS）

この役割は、AW-HDS-HDS-HDS の役割同様、設定の変更、リアルタイム レポート、および履歴レポートを処理します。このサーバは、リアルタイムおよび履歴レポートに Cisco Unified Intelligent Center（Unified Intelligence Centerレポート クライアント）を使用します。また、このサーバは、カスタム レポートのデータ抽出で履歴データをフィードするコールの詳細およびコール変数データも提供します。

管理サーバ、履歴データ サーバ、および詳細データ サーバ（AW-HDS-DDS）

リアルタイム データ サーバは、AW データベースを使用して、リアルタイムのデータと設定データを保存します。リアルタイム レポートは、上記 2 種類のデータを結合して、現在の状態に近いシステムのスナップショットを提示します。

履歴データサーバ (HDS) および詳細データサーバ (DDS) は、長期的な履歴データのストレージを提供します。HDS には、レポート用に 15 分間隔または 30 分間隔で要約された履歴データが保存されます。DDS には、コール レース用に各コールまたはコール セグメントに関する詳細情報が保存されます。ウェアハウスおよびカスタム レポートには、いずれのソースからでもデータを抽出することができます。

データの削除

設定された保持時間を超えるデータは、午前 12 時 30 分に自動的に削除されます。時刻はコア サーバのタイムゾーン設定を使用します。データベースが最大サイズの 80％ および 90％ に達した際も、パー削除がトリガされます。

Cisco がサポートするガイドラインに従い、削除はオフピーク時間またはメンテナンス時間帯に実行します。

コマンド ライン インターフェイスを使用して自動削除スケジュールを制御または変更することができます。オフピーク時に自動削除が実行されない場合は、この設定を変更することができます。

削除は、Logger のパフォーマンスに影響を与えます。

ライブ データ

ライブ データ は、ライブ データ レポートの高可用性を備えたリアルタイム イベントを処理するデータ フレームワークです。ライブ データは、周辺機器ゲートウェイおよびルータからのエージェントおよびコール イベントを継続して処理します。イベントが発生すると、ライブ データはリアルタイム更新を Unified Intelligence Centerレポート クライアントに継続してプッシュします。以下の表は、リファレンス設計におけるライブ データ サービスの配置を示しています。

2000 エージェント

4000 エージェント

12000 エージェント

24000 エージェント

Contact Director

ライブ データの配置

VM 上で Unified Intelligence Center および Cisco Identity Service と共存

スタンドアロン VM 上

スタンドアロン VM 上

スタンドアロン VM 上

Contact Directorには、ライブ データがインストールされていません。ライブ データは、ターゲットの Unified CCE インスタンス上にあります。

ライブ データ レポート

イベントが発生したときに、PG とルータ プッシュ エージェントが、ライブ データに発信されます。その後、ライブ データはインストリームでイベントを継続的に集約および処理し、情報を公開します。Unified Intelligence Center はリアルタイム イベントを受け取り、引き続きライブ データ レポートを更新するためにメッセージ ストリームをサブスクライブします。エージェントの状態など個々の状態の値は、状態が発生したときに更新されます。キュー内のコールなどの他の値は、約 3 秒ごとに更新されます。

ライブ データは Cisco Voice オペレーティング システム (VOS) VM 上の Unified CCE にあります。ライブ データ レポートは、Finesse エージェント デスクトップに組み込むこともできます。

Note

ライブ データでは、Cisco Unified Intelligence Centerおよび Cisco Finesse が同じ転送プロトコルを使用する必要があります。デフォルトでは、両者は HTTPS を使用しています。

Cisco Virtualized Voice Browser

Cisco Virtualized Voice Browser（Cisco VVB）は、VXML ドキュメントを解釈するためのプラットフォームを提供します。着信コールがコンタクト センターに到着すると、VVB は VoIP エンドポイントを表す VXML ポートを割り当てます。Cisco VVB は、Unified CVP VXML サーバに HTTP 要求を送信します。Unified CVP VXML サーバは要求を実行し、動的に生成された VXML ドキュメントを送り返します。

Related Concepts

Cisco Virtualized Voice Browser の設計上の考慮事項

Cisco Unified Communications Manager

Cisco Unified Communications Manager（Unified CM）は、Cisco Collaboration システムの主要なコール処理コンポーネントです。Unified CM は、IP フォン機間の VoIP コールを管理および切り替えます。Unified CVP は、PSTN で発信されたコールを Unified CCE エージェントに送信する手段として主に Unified CM と対話します。

以下の一般的なシナリオでは、Unified CVP に対するコールを Unified CM エンド ポイントから発信する必要があります。

- IP フォン上の（エージェントではない）のオフィス ワーカーが、内部ヘルプ デスク番号をダイヤルします。

- エージェントがコンサルタティブ転送を開始して、Unified CVP キュー ポイントにルーティングします。

Unified CM は、Java テレフォニー API（JTAPI）を介して Unified CCE と通信します。耐障害性設計では、Unified CM クラスタによって何千ものエージェントがサポートされます。クラスタ内でサポートされるエージェント数と最繁時呼数（BHCA）はさまざまであり、シスコのガイドラインに従ってサイジングする必要があります。

通常、Unified CCE ソリューションを設計する際は、最初に展開シナリオを定義します。音声トラフィックの到着ポイントとコンタクト センター エージェントのロケーションを決定します。次に、Unified CCE 設計内の個々のコンポーネントのサイズを決定します。この手順には、必要な Unified CM クラスタおよび各クラスタ内のサーバ数の決定が含まれます。

既存の Unified CM 展開に 2000 エージェントのリファレンス設計ソリューションを追加できます。その場合、既存の Unified CM クラスタは、標準のリファレンス設計レイアウトにおけるオンボックス クラスタのオフボックスの代替となります。この設定では、2 つのサブスクライバを CCE 専用にする必要があります。これらのサブスクライバ上のデバイスはすべて SIP である必要があります。グローバル トポロジでは、各リモート サイトに独自の Unified CM クラスタを含めることができます。

Note

- Cisco Unified Communications Manager は、オンボックスでもオフボックスでもサポートされます。Cisco Business Edition はオフボックスの場合のみサポートされます。

- CUCM VM をオフボックスに移動してから、リリース 12.5 にアップグレードします。

Unified CVP 環境では、Unified CM を入力またはエグレス ゲートウェイとして使用できます。Unified CM をエグレス ゲートウェイとして使用するのが一般的です。通常、コールは PSTN から発信され、Unified CVP によってキューに格納されて、エージェントによる処理のために Unified CM に切り替えられます。コールが PSTN からではなく IP フォンから発信された場合、Unified CVP の観点からは Unified CM がイングレス音声ゲートウェイになります。

- エグレス ゲートウェイとしての Unified CM

- Unified CM イングレス ゲートウェイ

- コール処理ノード

- 保留ノード上の TFTP および音楽

Related Concepts

Unified Communications Manager の設計上の考慮事項

エグレス ゲートウェイとしての Unified CM

Unified CVP と共に Unified CM を展開するには、イングレス音声ゲートウェイとエージェント IP フォン間のコールに Unified CM コール アドミッション制御を使用する必要があります。そのため、Unified CM は、コールの発信元をリモートのイングレス音声ゲートウェイではなく集中型の Unified CVP コール サーバであると見なします。

Unified CM イングレス ゲートウェイ

IP フォンが Unified CVP へのコールを開始すると、Unified CM は Unified CVP へのイングレス音声ゲートウェイとして機能します。Unified CVP にコールを送信するために SIP トランクが使用されます。

コール処理ノード

Cisco Unified Communications Manager は、Cisco Unified Communications 製品ファミリのソフトウェア ベースのコール処理コンポーネントとして機能します。

Cisco Unified CM システムは、企業のテレフォニー機能を、IP フォンなどのパケット テレフォニー ネットワーク デバイス、メディア処理デバイス、Voice-over-IP（VoIP）ゲートウェイ、マルチメディア アプリケーションに提供します。Cisco Unified CM では、シグナリング サービスとコール制御サービスが、Cisco 統合テレフォニー アプリケーションおよびサードパーティ アプリケーションの両方で提供されます。Cisco Unified CM は、主に以下の機能を実行します。

- 呼処理

- シグナリングとデバイス制御

- ダイヤル プランの管理

- 電話機能の管理

- ディレクトリ サービス

- Operations, Administration, Maintenance, and Provisioning（OAM&P）

- Cisco IP Communicator といった外部の音声処理アプリケーションからのプログラミング インターフェイス、Cisco Unified Customer Voice Portal (CVP)

Unified CM システムには、音声会議機能や手動アテンダント コンソール機能を実行する一連の統合型音声アプリケーションが含まれています。この一連の音声アプリケーションは、特定用途の音声処理ハードウェアが必要でないことを意味します。保留、転送、転送、会議、複数の回線の外観、自動ルート選択、短縮ダイヤル、その他の機能が IP フォンやゲートウェイにまで拡張された拡張サービスです。Unified CM はソフトウェア アプリケーションであり、実稼働環境で機能を拡張するには、サーバ プラットフォーム上のソフトウェアのアップグレードのみが必要とされます。これにより、コスト高となるハードウェアのアップグレード コストを回避することができます。

Unified CM および IP ネットワークを介したすべての Cisco IP フォン、ゲートウェイ、およびアプリケーションは、分散型の仮想テレフォニー ネットワークによって配布されます。このアーキテクチャでは、システムの可用性と拡張性が改善されています。コール受付制御は、ボイスのサービス品質 (QoS) が制限的に WAN リンク上で維持されることを実現します。WAN 帯域幅が利用できない場合、コールは代替の公衆交換電話網（PSTN）ルートに自動的に転送されます。

設定データベースへのブラウザ インターフェイスにより、リモートデバイスおよびシステム設定の機能が提供されます。このインターフェイスでは、ユーザや管理者が HTML ベースのオンライン ヘルプにアクセスすることもできます。

アプライアンスと同様に動作するように設計された Unified CM は、以下の機能を参照します。

- Unfied CM サーバをソフトウェアにプレインストールすると、顧客とパートナーの展開が容易になります。更新は自動的に検索され、主要なセキュリティ修正およびソフトウェア アップグレードがシステムで使用可能であることを管理者に通知します。このプロセスは、電子ソフトウェア アップグレードの通知で構成されます。

- Unified CM サーバのアップグレード中もコールの処理を継続して行うことが可能です。そのため、アップグレードの際は最小限のダウンタイムとなります。

- Unified CM は、より高い解像度の電話機で Unicode をサポートすることによって、アジアおよび中東地域の市場もサポートしています。

- Unified CM は、障害、設定、アカウント管理、パフォーマンス、およびセキュリティ（FCAPS）を提供します。

保留ノード上の TFTP および音楽

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

- 電話機やゲートウェイなどのデバイスにサービスを提供するためのファイル サービス。これには、設定ファイル、アップグレード用のバイナリ ファイル、さまざまなセキュリティ ファイルが含まれます。

- コンフィギュレーション ファイルおよびセキュリティ ファイルの生成。これらは、ダウンロード可能になる前に署名されます。場合によっては暗号化されます。

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

- TFTP サブスクライバには、コール処理サブスクライバと同じハードウェア プラットフォームを使用します。

- Unified Communications Manager MoH サーバは、音声ファイルと固定ソースの 2 種類のソースから MoH ストリームを生成することができます。また、いずれのタイプのソースも、ユニキャストまたはマルチキャスト送信が可能です。

Cisco Finesse

Cisco Finesse は、Cisco Unified Contact Center Enterprise 用の次世代のエージェントおよびスーパーバイザ デスクトップです。カスタマー サービス組織とやり取りする各種コミュニティにメリットをもたらします。カスタマーとカスタマー サービス担当者のエクスペリエンスを改善することによって、コラボレーションを向上させるように設計されています。

Cisco Unified Contact Center Enterprise の Cisco Finesse エージェントおよびスーパーバイザ デスクトップは、従来のコンタクト センターの機能をシンクライアント デスクトップに統合します。重要な特性は、すべてのデスクトップがブラウザベースであり、Web 2.0 インターフェイスを介して実装されることです。クライアント側のインストールは不要です。これにより、総所有コスト（TCO）が低減します。

Cisco Finesse は Web 2.0 ソフトウェア開発キット（SDK）とガジェットを備えているので、開発者は短時間でデスクトップを実装できます。

Cisco Finesse サーバは、シスコ音声オペレーティング システム（VOS）プラットフォームで稼動している専用の VMware 仮想マシン（VM）上に展開されます。Cisco Finesse サーバは、Cisco Finesse デスクトップ ソリューションに不可欠なコンポーネントです。Cisco Finesse ソフトウェアは耐障害性を備えており、冗長 VM 上に展開されます。両方の Cisco Finesse サーバが同時にアクティブになります。一方の Cisco Finesse サーバはパブリッシャとして動作し、冗長ペアのサブスクライバに設定データを複製します。

Cisco Finesse サーバは Agent PG 上の CTI サーバに接続します。Unified CCE による認証は、Administration & Data Server への接続を介して行われます。シングル サインオン（SSO）を有効にすると、Cisco Identity Service プロバイダーにより認証が行われます。

Contact Center Enterprise ソリューションにおける Cisco Finesse

Cisco Finesse では、Administration & Data Server をバックアップ用の Administration & Data Server と共に展開する必要があります。プライマリの Administration & Data Server がダウンすると、Cisco Finesse は認証用のバックアップ サーバに接続して、エージェントが引き続きサインインできるようにします。

Cisco Finesse サーバは、サポートしているクライアントの動作を Representational State Transfer（REST）API を介して示します。REST API によって、開発者は CTI サーバ ワイヤ プロトコルに関するさまざまな詳細を気にせずに済みます。

Cisco Finesse クライアントは、Cisco Finesse サーバの完全修飾ドメイン名（FQDN）を指し示す Web ブラウザを介して、Cisco Finesse サーバに接続します。

Cisco Finesse サーバはアクティブ/アクティブ配置で展開されます。この配置では、両方の Cisco Finesse サーバが Agent PG 上のアクティブな CTI サーバに接続します。標準の Cisco VOS レプリケーション機能により、Cisco Finesse サーバ上の永続的な設定データ向けの冗長性がもたらされます。

- Cisco Finesse サーバのサービス

- エージェントのモビリティ

Related Concepts

Cisco Finesse の設計上の考慮事項

Cisco Finesse サーバのサービス

CLI を使用して、以下の Cisco Finesse サービスにアクセスすることができます。

- Cisco Finesse 通知サービス：このサービスは、メッセージおよびイベントで使用されます。Cisco Finesse デスクトップは、このサービスを使用して、コール イベント、エージェントの状態変更、および統計情報を確認します。

- Cisco Finesse Tomcat サービス：このサービスには、導入されたすべての Finesse アプリケーションが含まれます。上記アプリケーションには以下が含まれます。

- Cisco Finesse デスクトップ アプリケーション：このアプリケーションは、エージェントおよびスーパーバイザ用のユーザ インターフェイスを提供します。

- Finesse IP フォン エージェント（IPPA）アプリケーション：このアプリケーションにより、エージェントとスーパーバイザは各自の Cisco IP フォンで Cisco Finesse 操作を実行することができます。

- Cisco Finesse REST API アプリケーション：Cisco Finesse は、クライアント アプリケーションがサポートされるサーバ機能へのアクセスを可能にする REST API を提供します。REST API は、HTTPS を使用してアプリケーションデータを転送します。REST API には、サードパーティ アプリケーションが Cisco Finesse とやり取りするために使用できるプログラミング インターフェイスも用意されています。REST API の詳細については、https://developer.cisco.com/site/finesse/ で Cisco Finesse のドキュメンテーションを参照してください。

- Finesse 管理アプリケーション：このアプリケーションは、Finesse の管理操作を提供します。

- Cisco Finesse 診断ポータル アプリケーション：このアプリケーションは、Cisco Finesse のパフォーマンス関連情報を提供します。

エージェントのモビリティ

Unified CCE の展開は、エージェント デスクトップを特定のエージェントまたは IP フォンの内線番号に静的に関連付けません。Unified CCE 内でエージェントと内線番号を設定して、特定の Unified Communications Manager クラスタに関連付けてください。

エージェントがデスクトップにサインインすると、セッションで使用するエージェント ID またはユーザ名、パスワード、内線番号の入力を求めるダイアログが表示されます。入力すると、エージェント ID、内線番号、エージェント デスクトップの IP アドレスが動的に関連付けられます。関連付けはエージェントがサインアウトすると解除されます。

この機能によって、エージェントは任意のワークステーションで作業（ホットデスク）することができます。また、この機能により、エージェントは自身のラップトップを適切に設定された Cisco Unified IP Phone に取り込み、そのデバイスからサインインすることもできます。

エージェントは、Cisco Extension Mobility 機能を使用して他の電話にサインインすることもできます。この機能の詳細については、『』（http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html）の「Extension Mobility」の項を参照してください。

Related Concepts

シングル サインオン（SSO）

Cisco Unified Intelligence Center

Cisco Unified Intelligence Center（Unified Intelligence Center）は Web ベースのレポート アプリケーションであり、消耗型のライブ データと、Unified CCE および Unified CVP の履歴レポートを提供します。スーパーバイザとビジネス ユーザは、ソリューション全体のマルチチャネル コンタクトの詳細について単一のインターフェイスから報告できます。従来のレポートの境界を情報ポータルに拡張し、組織全体のデータを統合して共有できます。

Unified Intelligence Center サーバは、シスコ音声オペレーティング システム（VOS）プラットフォームで稼動している専用の VM 上に展開されます。2000 エージェントのリファレンス設計では、Unified Intelligence Center はライブ データおよび Cisco Identity Service と共存します。

Unified Intelligence Center は、高い拡張性、パフォーマンス、高度な機能（他の Cisco Unified Communications 製品やサード パーティのデータ ソースとのデータ統合など）を提供します。Unified Intelligence Center には、特定のユーザ用に異なるアクセス権と機能を定義するセキュリティ モデルが組み込まれています。

Cisco Unified Intelligence Center は、Web ベースのレポート アプリケーションと管理インターフェイスの両方を提供します。Unified Intelligence Center のレポート機能には、以下が含まれています。

- ダッシュボードのマッシュアップ

- ソートとグループ化による、レポートの効果的なグリッド表示

- レポートのチャート表示とグラフ表示

- 同じレポート定義への複数のレポート表示の関連付け

- カスタム フィルタ

- データのアラートのためのカスタムしきい値

- Contact Center Enterprise データ用レポート テンプレートのストック

- MS SQL Server および Informix データベースのデータを報告する機能

管理者は Unified Intelligence Center を使用して、承認した個別のユーザおよびユーザ グループにのみ権限を付与することで、機能、レポート、およびデータへのアクセスを制御できます。たとえば、各スーパーバイザを最も関連性の高いエージェント グループ、スキル、コール タイプに割り当てることができます。これにより、各レポートでそれぞれの役割に適したデータに対して本質を見抜くための実用的な情報を重点的に提供できます。

この製品のいくつかの機能を使用すると、従来のレポートを超えて、企業全体の情報ポータルに Unified Intelligence Center プラットフォームを拡張することができます。ビジネスの効率性と有効性を向上させるために、従来とは異なるソースからのデータを使用できます。

Unified CCE レポート ソリューションは、コンタクト センターのライブ データ、リアルタイム データ、履歴データにアクセスするインターフェイスを提供します。

レポート ソリューションは次のコンポーネントから構成されています。

- Cisco Unified Intelligent Center：レポート用ユーザ インターフェイス

- 設定およびレポート データ：1 つ以上の Administration & Data Server に含まれています。

Unified Intelligence Center

Related Concepts

Cisco Unified Intelligence Center の設計上の考慮事項

Cisco オプション コンポーネント

Contact Center Enterprise ソリューションには、これらのオプションの Cisco コンポーネントを使用するものも含まれます。提供される機能を利用する場合は、ソリューションに追加します。通常、上記のオプション コンポーネントには、追加のサーバが必要となります。

- Cisco Customer Collaboration Platform

- Cisco Unified SIP Proxy

- ビジネス チャットおよび E メール

- クラウド コネクト

Cisco Customer Collaboration Platform

Cisco Customer Collaboration Platform は、デジタル メディア リクエストをコンタクトセンターのエージェントにルートする手段を提供します。ソリューションは、次に対して Customer Collaboration Platform を使用できます。

- カスタマーが Webサイトでエージェントからのコールを要求できるようにするエージェント要求機能。この機能の詳細については、『 Cisco Unified Contact Center Enterprise 機能ガイド』（http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html）を参照してください。

- サードパーティ製マルチチャネル アプリケーションを統合するときに使用できるタスク ルーティング API。

Contact Center Enterprise ソリューションにおける カスタマー コラボレーション プラットフォーム

- タスク ルーティング

Related Concepts

Customer Collaboration Platform 設計の考慮事項

タスク ルーティング

タスク ルーティング 異なるメディア チャネルからコンタクト センターのエージェントに要求をルーティングするシステムの機能です。

音声通話、 E メール、チャットなどの組み合わせを処理するようにエージェントを設定できます。たとえば、エージェントが音声、 E メール、およびチャットを処理する場合、3 種類のメディア ルーティング ドメイン（MRD）でスキル グループまたはプレシジョン キューのメンバーとしてエージェントを設定することができます。要求の送信元の MRD に関わらず、ビジネス ルールに基づき、エージェントに要求を送信するルーティング スクリプトを設計することができます。複数の MRD にログインするエージェントは、タスク単位でメディアを切り替えることができます。

オプションのコンポーネント ビジネス チャットおよび E メール では、すぐに タスク ルーティング を使用することができます。サードパーティ マルチチャネル アプリケーションは、タスク ルーティング API を使用して CCE と統合することによって、タスク ルーティング を使用することができます。

タスク ルーティング API は、CCE でのサードパーティのマルチチャネル タスクを要求、キューイング、ルーティング、および処理する標準的な方法を提供します

コンタクトセンターのカスタマーまたはパートナーは、タスク ルーティング を使うため、Customer Collaboration Platform および Finesse API を使用してアプリケーションを開発できます。Customer Collaboration Platform Task API は、アプリケーションを有効にして、CCE に非音声タスクリクエストを送信します。Finesse API は、エージェントがさまざまなタイプのメディアにサインインし、タスクを処理できるようにします。エージェントは各メディアにサインインし、独立してそれぞれの状態を管理できます。

Cisco のパートナーは、Cisco DevNet で入手できるサンプル コードを上記アプリケーションの構築ガイドとして利用することができます（https://developer.cisco.com/site/task-routing/）。

Cisco Unified SIP Proxy

Cisco Unified SIP Proxy（CUSP）は、集中的ルーティングと Session Initiation Protocol（SIP）信号正規化を行う、高パフォーマンス、高可用な SIP サーバです。CUSP を使用すると、コール制御ドメイン間で要求を転送することにより、企業ネットワークおよびサービス プロバイダー ネットワーク内でセッションをルーティングすることができます。アプリケーションは SIP 要素を集約し、高度に開発されたルーティング ルールを適用します。上記ルールは、SIP ネットワーク制御、管理、および柔軟性を強化します。

Unified CVP は、CUSP サーバのみをサポートします。

Unified CVP 展開では、CUSP サーバに、TDM ゲートウェイ、Unified CVP、および UCM SIP トランクからの着信コールが表示されます。CVP の SIP バックツーバック ユーザ エージェント（B2BUA）を使用すると、プロキシの初期コール セットアップに、着信コールのすぐ後にアウトバウンド コールが含まれます（VRU または ACD を問わず）。そのコールの後、CVP は発信レッグを含むエージェントにコールを転送し、着信レッグに再招待します。また、着信音サービス セットアップも利用可能で、さらに発信者への個別のアウトバウンド コールおよび再招待も含まれます。発信者レッグの再招待は、CVP 転送時または補足サービス中に発生します。

Contact Center Enterprise ソリューションにおける CUSP

SIP プロキシ サーバは、SIP エンドポイント間で SIP メッセージをルーティングします。CUSP サーバでは、ソリューション規模の SIP エンドポイントの高可用性とロード バランシングを実現します。CUSP サーバは、さまざまなタイプの複数の SIP エンドポイントをサポートし、これらのエンドポイント間にロード バランシングとフェールオーバーを実装するように設計されています。ソリューションに SIP プロキシを展開することで、より集中化されたダイヤル プラン ルーティング の設定が可能になります。

複数のスタティック ルートで SIP プロキシを設定すると、アウトバウンド コールでロード バランシングおよびフェールオーバーを実行することができます。スタティック ルートは、IP アドレスまたは DNS をポイントできます。

ドメイン ネーム システム (DNS) サービス レコード (DNS) サービス レコード (SRV) は、CUSP サーバ上で使用する権限がありません。ただし、Unified CVP、イングレス音声ゲートウェイ、Unified CM など、CUSP サーバに到達する必要があるデバイスに使用することができます。

Unified CVP は、ソリューションの設計または複雑さに応じて、CUSP プロキシ サーバなしで展開することができます。この場合、CUSP サーバが提供する機能には、Unified CVP サーバ SIP サービスによって提供されるものもあります。

CUSP サーバを使用する利点を以下に示します。

- ロード バランシングおよびフェールオーバー用にルートを使用して、プライオリティおよびウェイト ルーティングを使用できます。

- CUSP サーバが SIP ネットワーク内に存在する場合、Unified CVP は別の SIP エンドポイントとして機能します。Unified CVP は既存の SIP ネットワーク内に段階的に収まります。

CUSP サーバを使用しない場合は、イングレス音声ゲートウェイおよび Unified CM が Unified CVP を直接ポイントする必要があります。このような展開では、次のタスクを実行します。

- ゲートウェイから DNS サーバへの DNS SRV ルックアップを使用してロード バランシングを実行します。この手順を使用して、SIP コールのバランシングを行います。

- DNS SRV ルックアップを使用して、Unified CVP からのアウトバウンド コール（アウトバウンド コール レッグ）のロード バランシングを実行します。

ビジネス チャットおよび E メール

Contact Center Enterprise ソリューションは、ビジネス チャットおよび E メール（ECE）を使用してマルチチャネル コンタクト センターを提供します。

E メールの場合、ECE を使用することにより、組織は着信 E メール、Webフォームでの問い合わせ、ファクス、書簡を適切にルーティングして処理することができます。Webチャットの場合、ECE にはエージェントがリアルタイムでカスタマーにサービスを提供できる総合的なツール セットが用意されています。これにより、コール センターのエージェントはテキスト チャット メッセージやページプッシュ機能を使用して、カスタマイズされたサービスを迅速に顧客に提供できます。

ECE Web サーバを外部サーバに展開します。その際サーバは、ECE データサーバ と同じ サイト で配置することができます。また、顧客とのチャット処理が必要な場合は、DMZ に配置することも可能です。

Contact Center Enterprise ソリューションの ECE

- ビジネス チャットおよび E メール の機能

Related Concepts

Enterprise Chat and Email の設計上の考慮事項

ビジネス チャットおよび E メール の機能

ビジネス チャットおよび E メール (ECE) の機能は以下の通りです。

E メール

ECE では、顧客とエージェントの間の通信チャネルを作成する E メールをサポートしています。顧客からの E メールに効率的に対応するには、さまざまな処理が実行される必要があります。E メールは、まずシステムに取得され、適切なユーザまたはキューに送信されます。応答が作成されると、その応答はシステムによって処理され、顧客に送信されます。

チャット

これは、顧客とエージェント間のチャット セッション用に作成されたアクティビティです。チャットは、エージェントと顧客間のリアルタイムの対話であり、テキスト メッセージが交換されます。チャットの一環として、エージェントは、顧客に Web ページを転送することもできます。アクティビティがエージェントにルーティングされる方法に基づき、チャットはスタンドアロンのチャットと統合チャットに分類されます。統合チャットは統合キューにルーティングされ、メッセージは Unified CCE に送信されます。Unified CCE がアクティビティを処理し、そのチャットを利用可能なエージェントに割り当てます。

Web コールバックおよび遅延コールバック

Web コールバック機能を使用すると、Web サイト上でフォームを送信することによってコールバックを要求することができます。ECE は、送信された情報を処理し、ユーザをエージェントに接続します。コンタクト センターのエンタープライズ統合では、ECE が Unified CCE にメッセージを送信して、コールバック要求をエージェントに転送するように要求します。Unified CCE によって、ECE にメッセージが送信されます。エージェントが利用可能になると、コール ルータはエージェントに Web コールを開始するように通知します。

遅延コールバック機能は、Web コールバック機能と似ています。ECE が遅延コールバック要求を受信すると、遅延コールバック テーブルに要求が追加されます。ECE は HTML ページを発信者に送信し、コールの時間枠を指示します。指定された時間になると、ECE は Unified CCE キューに要求を移動して Unified CCE にルーティングします。コールは、Web コールの場合と同じ方法で処理されます。

クラウド コネクト

Cloud Connect は、Webex エクスペリエンス管理などのクラウドサービスをカスタマーに使用してもらう新しいコンポーネントです。管理者は、Unified CCE Administration の Cloud Connect サーバ設定を構成して、Cisco Cloud サービスに接続できます。

クラウド コネクトの構成方法については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.htmlCisco Unified Contact Center Enterprise のアドミニストレーション ガイド」、https://www.cisco.com/c/en/us/support/customer-collaboration/packaged-contact-center-enterprise/products-maintenance-guides-list.html の「Contact Center 版 Cisco Hosted Collaboration Solution」を参照してください。

サードパーティ コンポーネント

Contact Center Enterprise ソリューションの機能は、サードパーティ コンポーネントを使用して拡張することができます。

- ロード バランサ

- 録音

- 音声サーバ：ASR/TTS

- ウォールボード

- ワークフォース管理

ロード バランサ

Contact Center Enterprise リファレンス設計 では、ロード バランサはリダイレクト モードでのみ使用されます。Contact Center Enterprise ソリューションでは、次の目的のためにサード パーティのロード バランサを使用できます。

- Cisco Finesse サインイン ページにアクセスする場合

- Finesse REST API を直接使用する場合

- Unified CVP を併用する場合

- Unified CCE Administration ツールのサインイン ページにアクセスする場合

- Unified CCE Administration REST API を直接使用する場合

- Cisco Unified Intelligence Center の使用

- Cisco Unified Intelligence Center Administration 管理コンソールを併用する場合

ロード バランサの要件の詳細については、ご使用の Contact Center Enterprise ソリューションに応じた『Compatibility Matrix』を参照してください。

Related Concepts

ロード バランサの設計上の考慮事項

録音

録音オプションでは、オーディオやビデオなどのネットワーク ベースのメディアを、豊富な録音メタデータで保存することができます。メディアの録音、再生、およびライブストリームが可能です。このオプションは、コンプライアンス、品質管理、およびエージェントの指導に使用することができます。このプラットフォームは、ビジネス インテリジェンスの会話をキャプチャ、保存、およびマイニングする効率的で費用対効果の高い基盤を提供します。

Note

Unified CVP では、リアルタイム トランスポート プロトコル（RTP）ストリームのソフトウェア ベースの分岐をサポートするネットワークベースの録音（NBR）機能が提供されています。

Note

サードパーティの録音アプリケーションの UCS B シリーズでの ERSPAN サポートについては、ベンダーのアプリケーション要件を参照してください。

音声サーバ：ASR/TTS

自動音声認識（ASR）サーバと音声合成（TTS）サーバは、音声ブラウザに音声認識サービスと音声合成サービスを提供します。自動音声認識（ASR）を使用すると、発信者はメニューのオプションを音声で選択できます。たとえば、自動応答機能は呼び出し先を尋ね、その返答を使用してコールを接続できます。音声合成（TTS）は、プレーン テキスト（UNICODE）を音声に変換します。たとえば、音声ブラウザは音声合成（TTS）サーバからメディアをストリーミングできます。

ASR/TTS ライセンスの使用は、音声ブラウザで使用する機能に応じて異なります。VXML ゲートウェイは、コールの終了まで ASR/TTS ライセンスを解放しません。Cisco VVB は、スクリプトでライセンスが不要になるとライセンスを解放します。

Contact Center Enterprise ソリューションにおける音声サーバ

ASR/TTS サーバと音声ブラウザ間の通信では、Media Resource Control Protocol（MRCP）が使用されます。MRCP バージョンのサポートについては、『Compatability Matrix』参照してください。

World Wide Web コンソーシアム（W3C）では、ASR 文法をサポートするための高度な機能セットを提供しています。許可されたカスタマー応答を音声ブラウザに渡すインライン文法を実装してサポートできます。また、外部文法を使用することも可能です。その場合は、外部文法ソースへのポインタが Unified CCE によって渡されます。VXML サーバは、音声ブラウザに送信する VXML ドキュメントにこのポインタを追加します。音声ブラウザはその文法を使用して、発信者からの ASR 入力をチェックします。この場合、顧客は文法ファイルを作成します。3 つめのタイプの文法は、組み込み文法です。文法の形式の詳細については、http://www.w3.org/TR/speech-grammar/ で次の W3C Web サイトを参照してください。

VXML サーバが TTS 用のテキストをゲートウェイに直接渡す場合、そのアクションはインライン TTS と呼ばれます。MRCP を介して音声ブラウザと通信する個別のサーバが、音声認識と音声合成を実行します。また、ASR および TTS エンジンは、複数言語の音声認識および音声合成も（制限付きで）サポートしています。

サードパーティの ASR/TTS ソフトウェアおよびサーバについては、ご使用のソリューションの『Compatibility Matrix』を参照してください。

Related Concepts

音声認識と音声合成

ウォールボード

Wallboards を使用すると、顧客に提供するサービスをリアルタイムで監視することができます。Wallboards は、待機数、待機時間、サービス レベルなど、顧客サービス指標に関する情報を表示します。

ワークフォース管理

Workforce Management (WFM) を使用すると、複数のキューとサイトのスケジュールが可能です。単一の WFM 実装を世界規模で展開することができます。WFM では、主要業績評価指標とスケジュールのリアルタイム準拠を管理することもできます。

ユーザ (エージェント、スーパーバイザ、スケジューラ、および管理者) は、Web ブラウザを使用して WFM にアクセスすることができます。シック クライアントのインストールが回避できるため、WFM は高度に分散した人員環境に最適です。

統合機能

オプションのコンポーネントと統合機能の違いは、ソリューションへの追加が容易になる点です。通常、統合された機能は、サーバまたは VM をソリューションに追加する必要はありません。ソリューションで有効化する設定を行うのみです。ただし、上記機能によって規模その他の設計の影響が増大する可能性があります。

ソリューションのさまざまな統合機能の詳細については、機能ガイドを参照してください。

- エージェントのグリーティング

- アプリケーション ゲートウェイ

- 業務時間

- Cisco アウトバンド オプション

- サービス コールバック

- コール コンテキスト

- データベース統合

- データベース ルックアップ

- エクステンション モビリティ

- 混合コーデック

- モバイル エージェント

- 内線番号のサポート

- ポスト コール調査

- Cisco Webex のエクスペリエンス管理

- 精密なルーティング

- シングル サインオン（SSO）

- ウィスパー アナウンスメント

エージェントのグリーティング

エージェント グリーティングでは、設定可能な自動グリーティングを発信者に対して再生できます。発信者ごとに、クリアかつ適切なペースで、適切な言語による熱意のある導入部が再生されます。エージェント グリーティングは、オープニング スクリプトの読み上げからエージェントを解放します。代わりにエージェントは、グリーティングの再生中にデスクトップ画面のポップアップを確認することができます。

グリーティングの録音は、ボイス メールのメッセージの録音とまったく同じです。コール センターのセットアップ方法に応じて、エージェントは、発信者のタイプに合わせて再生するさまざまなグリーティングを録音します（たとえば、英語を話す人には英語のグリーティング、イタリア語を話す人にはイタリア語のグリーティングなど）。

エージェント グリーティングは、Unified CCE と Unified CM により制御される組み込み型ブリッジ（BiB）搭載の IP Phone を使用している、エージェントおよびスーパーバイザが利用できます。

エージェントのグリーティング

Related Concepts

エージェント グリーティングに関する考慮事項

アプリケーション ゲートウェイ

アプリケーション ゲートウェイは、CCE ルーティング エンジンが外部サービスを照会するためのインターフェイスを提供します。開発パートナー向けに公開されているアプリケーション ゲートウェイ プロトコル GED-145 を使用するカスタム アプリケーションを作成する必要があります。詳細については、https://developer.cisco.com/site/devnet/home/index.gspを参照してください。

アプリケーション ゲートウェイでは、スクリプトにアプリケーション ゲートウェイ ノードを挿入することができます。これらのノードは、変数を設定し、カスタム アプリケーションに要求を送信し、関連情報を取得するサポートを提供します。この情報を管理スクリプトで使用して、プログラムを開いたり閉じたりすることができます。また、エージェントに送信可能な、ルーティング スクリプト内の関連する顧客データを返すこともできます。

業務時間

業務時間機能を使用すると、通常の勤務時間と追加の勤務時間のスケジュールを作成して、休日または緊急事態に対応してコンタクト センターを閉鎖することができます。設定された業務時間スケジュール、休日、緊急時の閉鎖、あるいは追加の業務時間に基づいて、各連絡先を特定のサポート チームに転送するメカニズムが提供されています。さまざまなシナリオに対応するさまざまなコンタクト センターチーム向けに業務時間のスケジュールを作成することができます。この機能は、同じチームに複数の業務時間スケジュールを作成および適用するのに役立ちます。一方、同じ業務時間スケジュールを複数のサポート チームに適用することもできます。

顧客がコンタクト センターに連絡する場合、コンタクト センターによる対応はサポート チームの状態に基づいています。この状態は、チームに対して設定された業務時間を使用して評価されます。

Cisco アウトバンド オプション

Contact Center Enterprise ソリューションでは、エージェントはインバウンドとアウトバウンドの両方のコンタクトを処理できます。アウトバウンド キャンペーン ソリューションを必要とするコンタクト センターのマネージャは、Cisco Unified CCE が保持している、エージェント リソースに関するエンタープライズ ビューを利用できます。Cisco アウトバウンド オプションは、エージェント ベースと VRU ベースのキャンペーンをサポートしています。エージェント ベースのキャンペーンの場合は、留守番電話の VRU へのコールの転送や、放棄呼の規制上の要件を満たすためのコールの転送もサポートされます。VRU キャンペーンではエージェントは使用されません。代わりに、コールは、応答されたコールに対して録音メッセージを再生する VRU に送られます。

Cisco Outbound Option Dialer は、Cisco Unified Contact Center Enterprise の既存のインバウンド機能と共に、アウトバウンド ダイヤリング機能を提供します。このアプリケーションにより、コンタクト センターでは、カスタマー コンタクトにダイヤルして、連絡を受けたカスタマーをエージェントに転送することができます。Cisco Outbound Dialer を使用すると、自動アウトバウンド アクティビティ用にコンタクト センターを設定できます。

Outbound Option Dialer は、Unified CM PG 上に共存するソフトウェア専用プロセスです。SIP Dialer プロセスは、音声ゲートウェイまたは CUBE、Outbound Option Campaign Manager、CTI サーバ、MR PIM と通信します。ダイヤラはキャンペーン マネージャと通信して、アウトバウンド カスタマーのコンタクト レコードを取得したり、アウトバウンド コールの傾向（ライブ応答、留守番電話、RNA、通話中など）を報告したりします。ダイヤラは音声ゲートウェイと通信して、アウトバウンドの顧客コールを発信します。ダイヤラは CTI サーバと通信して、スキル グループのアクティビティをモニタしたり、エージェントの電話に対してサードパーティのコール制御を実行したりします。SIP ダイヤラは MR PIM と通信して、使用可能なエージェントを選択するためのルーティング要求を送信します。

Outbound Option Dialer は、その周辺機器上のすべてのエージェントに代わってカスタマーにダイヤルできます。ダイヤラには次のモードで動作可能なルーティング スクリプトが設定されます。

- フル混合モード：エージェントはインバウンドとアウトバウンドのコールを処理できます

- スケジュール モード：たとえば、8:00 AM ～ 12:00 PM をインバウンド モード、12:01 PM ～ 5:00 PM をアウトバウンド モードに設定します。

- 完全アウトバウンド モード

混合モードが有効な場合、ダイヤラはエージェントをめぐってインバウンド コールと競合します。ダイヤラは、管理スクリプトの Outbound Percent 変数に設定されている数よりも多くのエージェントを予約できません。すべてのエージェントが通話中の場合、ダイヤラは追加のエージェントの予約を試みません。

アウトバウンド オプションを展開するには、以下の通りに複数の方法を使用して、高可用性または低可用性を実現します。

- 単一のキャンペーン マネージャ、アウトバウンド オプション インポート、およびデータベース: これは、SIP ダイヤラの操作を直接実行するサブコンポーネントを非フォールト トレラントで構成する設定です。キャンペーン マネージャまたはアウトバウンド オプション インポートを停止すると、オンラインに戻るまで、送信コールは失われます。この設定では、複数のダイヤラを指示することができます。

- 冗長キャンペーン マネージャ、アウトバウンド オプション インポート、およびデータベース: このフォールト トレラント設定には、ウォーム スタンバイ モードで動作する冗長サブコンポーネントが含まれています。アクティブなキャンペーン マネージャまたはアウトバウンド オプション インポートに障害が発生すると、ソリューションはスタンバイ サブコンポーネントにフェールオーバーします。この設定では、サイドを同期するための帯域幅を増やす必要があります。また、重複する記録の維持のために、より多くのディスク容量が必要になります。

- 冗長 SIP ダイヤラ: このソリューションには、各エージェントの PG のペアに対して 1 組の冗長 SIP ダイヤラを含めることができます。各エージェントの PG ペアにダイヤラのペアを含める必要はありません。キャンペーン マネージャは、利用可能なダイヤラ間でロード バランスを取ることができます。

- 複数の音声ゲートウェイとUnified SIP プロキシ サーバ: 各ダイヤラに対して Unified SIP プロキシのペアを追加すると、高可用性を向上させることができます。その後、Unified SIP プロキシの各ペアに追加の音声ゲートウェイを追加することができます。これにより、各ダイヤラによって行われるコール数を、単一の音声ゲートウェイでサポート可能な数以上に増やすことができます。このソリューションでは、使用可能なインスタンス間で負荷のバランスがとられています。

Cisco アウトバウンド オプションは、Cisco キャンペーンでのコール プログレス分析（CPA）の設定をサポートしています。この機能を有効にすると、SIP ダイヤラは、メディア ストリームの分析を音声ゲートウェイまたは CUBE に指示します。ゲートウェイは、コールの特性を判断します (音声、留守番電話機、モデム、またはファックスの検出)。

Note

仮想 CUBE は、CPA をサポートしていません。ソリューションに CPA が必要な場合は、専用の物理ゲートウェイを使用します。

Related Concepts

Cisco アウトバンド オプションに関する考慮事項

サービス コールバック

サービス コールバックでは、発信者はエージェントによるかけ直しを選択できます。このオプションによって、エージェントが応答するまで発信者が保留状態で待つ時間が限定されます。

各コールごとに予想待機時間（EWT）が計算されます。発信者の EWT がゼロに近づくと、スクリプトによって発信者にコール バックが行われます。発信者が応答すると、スクリプトは発信者を元の順序でキューに戻します。発信者は、電話を切らずに待っている場合と同じ時間内にエージェントにつながります。

サービス コールバック

Related Concepts

サービス コールバックに関する考慮事項

コール コンテキスト

コール コンテキストとは、コールに関連付けられているデータおよび属性を指します。

- コール変数

- カスタム SIP ヘッダ

- 拡張コール コンテキスト変数

- ユーザ間情報

Related Concepts

コール コンテキストに関する考慮事項

コール変数

コール変数を使用して、Unified CVP からのビジネス関連データをエージェント デスクトップに渡します。コンタクト センターのエンタープライズ ソリューションには、10 通りのコール変数のセットがあります。各変数には、40 バイトのデータを含めることができます。

カスタム SIP ヘッダ

この機能により、Unified CVP は、選択された SIP ヘッダ情報をUnified CCE との間で受け渡し、ルーティング スクリプトで変更することができます。この機能により、サードパーティの SIP トランクおよびゲートウェイとの SIP 相互運用における柔軟性が大幅に高まります。Reinviteではなく、最初の SIP INVITE のヘッダでのみ情報を渡すことができます。

SIP ヘッダの変更には注意が必要です。SIP ヘッダを追加または変更しても、このツールはシンタックスをチェックしません。

拡張コール コンテキスト変数

拡張コールコンテキスト (ECC) 変数を使用すると、ビジネス関連データをエージェント デスクトップに転送するように設定することができます。通話の変数と異なり、各 ECC 変数のサイズ、形式、名前を設定することができます。

必要に応じて、ECC 変数はいくつでも定義することができます。ただし、特定のインターフェイスでは、一度に 2000 バイトの ECC 変数のみを渡すことができます。特定の目的のために ECC 変数を整理するサポートを提供するように、このソリューションには ECC ペイロード が含まれています。

ECC ペイロードは、最大サイズが 2000 バイトである定義された ECC 変数のセットです。ECC ペイロードを作成して、特定の操作に必要な情報を満たすことができます。特定の ECC 変数を複数の ECC ペイロードに含めることができます。特定の ECC ペイロード内の特定の ECC 変数は、その メンバーと呼ばれます。

同じコール フローで複数の ECC ペイロードを使用することはできますが、一定の時点で有効範囲を持つ ECC ペイロードは 1 つのみとなります。

このソリューションには、下位互換性のために「デフォルト」名を持つ ECC ペイロードが含まれています。ソリューションがより多くの ECC 変数スペースを必要としない場合は、デフォルトのペイロードのみが必要となります。ソリューションがデフォルトのペイロードのみを保持している場合、ソリューションは、2000 バイトの制限に達するまで、新しい ECC 変数をすべてデフォルトのペイロードに自動的に追加します。

Related Concepts

拡張コール コンテキスト変数の考慮事項

ユーザ間情報

ユーザ間情報（UUI）は、ISDN 補足サービスがユーザ間 サービスとして提供されるデータです。UUI は業界標準のフィールドであり、Contact Center Enterprise ソリューションとサードパーティ ソリューション間で情報を転送することができます。UUI 機能は、コールのセットアップ中およびコールの切断中に、発信側と着信側の ISDN 番号間で情報を転送します。

Unified CVP では、転送中および切断時に UUI 機能を使用して、PSTN から Unified CCE ルータに ISDN データを渡すことができます。また、UUI を Unified CCE からサードパーティ ACD に使用することもできます。

ゲートウェイは、CTI アプリケーションでアプリケーション固有の UUI データを使用して、サードパーティの ACD 統合を改善することができます。

たとえば、外部システムからのデータ（サードパーティの IVR からの発信者が入力した番号等）をキャプチャし、そのデータを新規コールで Unified ICM に渡すことができます。

Note

Unified CVP では、まだ IETF UUI ヘッダはサポートされていません。汎用 SIP ヘッダ機能を使用して、標準の UUI を解析することができます。

データベース統合

コンタクト センターは外部データベースと統合することができます。データベース統合は、外部データベース内のテーブルの作成、更新、および取得操作を提供します。データベース統合は、CVP Call Studio のデータベース要素を使用します。

データベース ルックアップ

データベース ルックアップはオプションの機能の 1 つであり、外部データベースからデータを読み取り、その情報をルーティング スクリプトまたは管理スクリプト内で使用できるようにします。

たとえば、外部 SQL データベースを使用して、発信者の ANI を検索し、発信者がシルバーまたはゴールドの顧客であるかどうかを確認するスクリプトを作成します。

1 つのキー列を SQL プライマリ キーとして指定する必要があります。DB ルックアップノードでアクセスするデータベース列を参照するには、If ノードを使用します。この例では、If ノードを使用して、発信者がシルバーの顧客であるか、またはゴールドであるかを確認します。

DB ルックアップ ノードが実行されると、外部データベースからのデータ行の照会が試行されます。ノードが管理者スクリプトの一部として実行される場合は、定期的に呼び出され、変更がスケジュールされているかどうかを確認します。ノードがルーティング スクリプトの一部として実行される場合、DB Worker スレッドからのデータベース クエリとなります。

スクリプトで使用するデータベースを作成して使用する方法の詳細については、以下を参照してください。 https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-enterprise/116215-configure-dblookup-00.html

Related Information

データベース ルックアップ設計に関する考慮事項

エクステンション モビリティ

電話機を監視および制御するために、コンタクト センターのソリューションは、各電話機を Unified CM の JTAPI ユーザ ID と関連付けます。Extension Mobility またはクラスタ間 Extension Mobility を使用する場合、Extension Mobility デバイス プロファイルを関連付けることもできます。Unified CCE 環境で、IP フォンまたは対応する Extension Mobility デバイス プロファイルを、Unified CCE JTAPI ユーザ ID に関連付けます。エージェント デスクトップがサインインすると、PIM はサブスクライバを要求し、PIM がその電話機のモニタリングと制御を開始できるようにします。エージェントがサインインするまで、サブスクライバは、Unified CCE にその電話機を監視または制御の許可を与えません。デバイスまたは対応する Extension Mobility デバイス プロファイルがUnified CCE JTAPI ユーザ ID に関連付けられていない場合、エージェントのサインイン要求は失敗します。

Extension Mobility クロス クラスタ (EMCC) を使用する場合、Extension Mobility のサインイン後に Unified CCE PIM 電話がローカルクラスタに登録されると、電話は WAN を介して配置されたエージェントのように見えます。Unified CCE 周辺機器は、クラスタ上のアプリケーション ユーザの電話機デバイスではなく、Extension Mobility プロファイルに基づいてエージェント デバイスを管理します。詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html で 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

Extension Mobility デバイスは、デバイスまたはユーザのプロファイル別の 2 つの方法を使用して関連付けることができます。Unified Communications Manager上の CCE アプリケーション ユーザにExtension Mobility プロファイルを関連付けます。

デバイスの代わりに EM プロファイルを設定すると、電話機のエージェントがコール センターで使用する際の柔軟性が向上します。電話機デバイスを設定すると、エージェントが使用することができるデバイスが制限されます。コンタクト センターで使用するオプションは、顧客のビジネス ケースによって異なります。

混合コーデック

デフォルトでは、Contact Center Enterprise ソリューションは、mu-law コーデックを使用して着信コールを受け入れます。代わりに、コンタクト センターで a-law コーデックを使用することができます。a-law を使用するには、CVP、Unified CM、および VXML またはイングレス ゲートウェイのデフォルト値を変更します。以下の表は、さまざまな機能の音声コーデックのサポートを示しています。

オーディオ コーデック サポート

機能

サポート

着信コール

G.711 (mu-law と a-law) および G.729 コーデック

アウトバウンド コール

G.711 (mu-law と a-law) のみ

VRU

G.711 (mu-law と a-law) のみ

エージェント

G.711 (mu-law と a-law) および G.729 コーデック

Note

トランスコーダおよび汎用トランスコーダを回避するために、着信コールとエージェントに対して G.711 および G.729 コーデックの両方を使用します。WAN の帯域幅を節約するには、G.729 を優先順位リストの最初のコーデックとして使用します。

Cisco アウトバウンド オプション ダイヤラ

CUBE を備えた SIP ダイヤラは、特定の設計上の考慮事項を鑑みた a-law および μ-law をサポートできます。

サイレント モニタのサポート

以下のサイレント モニタリング ソリューションは、mu-law の両方をサポートしています。

- Unified CM ベースのサイレント モニタリング

混在環境はサポートされません。

以下の要素のインスタンス間でコーデックを混在させることはできません。

- 周辺機器上のすべてのモバイル エージェントは、同じコーデックを使用する必要があります。

- すべての CVP プロンプトで、同じコーデックを使用する必要があります。

モバイル エージェント

モバイル エージェントを使用すると、エージェントは、エージェント デスクトップ通信用の PSTN 電話機とブロードバンド VPN 接続を使って、どこからでもサインインできるようになります。エージェントは、Cisco IP Phone を使用するコンタクト センター のエージェント設定とまったく同様に機能します。モバイル エージェントは、プロキシとして動作する CTI ポート ペアを使用して、エージェントと発信者を接続します。

Note

モバイル エージェントは IPv6 対応の CTI ポートを使用できません。

各 PG がサポート可能なモバイル エージェントの数は、通常のエージェントよりも少なくなります。ただし、さらに PG を追加することで、リファレンス設計 で許可されている通常のアクティブ エージェントの最大数までサポートできます。

Related Concepts

モバイル エージェントに関する考慮事項

内線番号のサポート

Contact Center Enterprise ソリューションは、通常の内線番号と ACD（コンタクト センター）の内線番号の両方をサポートできます。これらのタイプの組み合わせ方法によっては、コンタクト センターが影響を受ける可能性があります。

次のように電話回線を Unified CM クラスタに割り当てることができます。

- 同じクラスタに標準と ACD の内線番号を混在させることができます。

- 特定のクラスタに ACD 内線番号を設定し、他のクラスタに標準の内線番号を設定することもできます。

また、いくつかの方法で各エージェントの内線番号をエージェントのデバイスに割り当てることもできます。

Note

- Unified CCE は E.164 ダイヤル プランをサポートしており、部分的に「+」プレフィックスもサポートします。

- 2000 エージェント リファレンス設計では、同じマシン上の Unified CM は最大 2000 台の電話機をサポートすることができます。これには、連絡先のすべてのタイプのエージェント (コンタクト センター エージェントやバックオフィス要員等) の電話機が含まれます。設計するソリューションで 2000 以上の電話機が必要な場合は、オフボックスで Unified CM を使用してください。

- デュアル使用の Unified CM クラスタ

- さまざまなユーザ タイプ向けの内線番号

Related Concepts

内線番号のサポートに関する考慮事項

デュアル使用の Unified CM クラスタ

同じ Unified CM クラスタを使用して、通常の IP テレフォニー (オフィス) 内線番号と ACD (コンタクト センター) 内線番号をサポートすることができます。ただし、デュアル使用クラスタを選択する前に、以下の点に注意してください。

- コンタクト センターには厳格なメンテナンス期間が設けられています。メンテナンスがオフィスの拡張機能に都合の悪いときに影響を与える場合があります。

- エージェントは、他のオフィスの従業員よりもはるかに多くのコールを処理します。エージェントのデバイスは、平均的なオフィスワーカーよりも高い負荷をシステムにかけることになります。オフィスの拡張機能のみを処理するクラスタは、さらに多くの内線番号をサポートすることができます。

- すべてのデバイスは、コンタクト センターソリューションの互換性要件を満たさなければなりません。使用するソリューションの 互換性マトリックス を参照してください。

これらの点で、各タイプの拡張のクラスタを分割すると、パフォーマンスが向上します。

さまざまなユーザ タイプ向けの内線番号

必要に応じて、エージェントのデバイス毎に異なる拡張子を割り当てることができます。

Unified CCE では、IP フォンで 1 つのエージェント ACD 内線のみがサポートされます。Unified CCE を有効にして、その内線に関するすべてのコールを管理および制御するには、ボイスメールまたはコール転送を持つことができません。通常、エージェントの内線番号は、エージェントのオフィスの内線番号としては使用されません。この目的のために、エージェントの電話機に個別の内線番号を割り当てることができます。オフィスの拡張機能には、ボイスメールやその他の発信機能を含めることができます。

通常、この接続は、ハンドセットを取り上げる際に、IP フォンの最初の内線番号になります。最初の内線番号を、各ユーザが最も頻繁に使用する内線番号に割り当てます。ユーザの職務に応じて、以下の設定を検討します。

- コンタクト センターエージェント: エージェントの ACD 内線番号を最初の位置に割り当てて、オフィス内線番号を別の位置に割り当てます。このレイアウトは、着信 ACD コールへの応答が最も容易です。コンタクト センターでは、エージェントが ACD 内線に外部コールとして受け取るコールが追跡されます。エージェントがその内線に対してコールを発信すると、Unified CCE には、エージェントを非対応モードで配置し、そのエージェントへのコールはルーティングしません。

- ナレッジ ワーカー: このタイプのエージェントは多くの ACD コールを直接処理することはありません。オフィスの内線番号を 1 つ目の場所に、その ACD 内線番号を別の場所に割り当てます。このレイアウトでは、非 ACD コールがコンタクト センターによってトラッキングされることを回避されます。これらのエージェントは、ほとんどのコールがオフィスの内線に届くため、ほとんどのコールについて、その状態を手動で「応答不可」モードに設定する必要があります。このモードを呼び出すと、Unified CCE は、その時間内にそれらへの ACD コールを転送しません。

- 単一ライン ワーカー: これらのエージェントは、ACD および オフィス コールに同じ内線番号を使用します。このオプションを使用すると、エージェントのすべてのアクティビティを表示して、エージェントのすべての中断を回避することができます。ただし、このオプションでは、エージェント間コールによるユーザ コールの中断を回避するために、ルーティング スクリプトに特別な注意を払う必要があります。ルーティングでは、CTI ルート ポイントと一意の DN を使用して、各 CTI ルート ポイントを採用します。

- バックオフィス エージェント: このタイプのエージェントは、通常、オフィスの内線番号のみを使用します。オフィスの内線番号を最初の位置に割り当てます。バックオフィス エージェントが ACD コールを処理する可能性がある場合、その ACD 内線番号を IP フォンの最後の位置に割り当てます。

ポスト コール調査

ポスト コール調査は、通常のコール処理の後で行います。通常、この調査は、カスタマーが自身のエクスペリエンスに満足しているかどうかを判断するために使用します。エージェントが発信者からのコールを切断した後、必要に応じてポスト コール調査用の DNIS にコールを送信するコール フローを設定することができます。

VRU は、ポスト コール調査に参加するかどうかを発信者に尋ねます。参加する場合、発信者は、通常のコール フローが完了した後、自動的にポスト コール調査に転送されます。

Related Concepts

ポスト コール調査に関する考慮事項

Cisco Webex のエクスペリエンス管理

Cisco Webex のエクスペリエンス管理 は、Customer Experience Management（CEM）のためのプラットフォームであり、顧客の視点からビジネスを確認できる強力なツールと統合されています。エクスペリエンス管理には、カスタマー ジャーニー マッピングを含む高度な機能があります。

エクスペリエンス管理を Unified CCE と統合すると、次のような操作が可能になります。

- 管理者は、ポーリング間隔を構成して、顧客からフィードバックを直接収集できます。

- 管理者は、Finesse デスクトップ上で表示可能な分析ガジェットを構成できます。

- エージェントおよびスーパーバイザは、NPS、CSAT、CES、またはその他の KPI などの業界標準メトリックを使用して、顧客のパルスを表示できます。

Note

現在、着信 ICD コールについてのみ調査を実施できます。

エクスペリエンス管理の構成方法に関しては、の『Cisco Unified Contact Center Enterprise 機能ガイド』に記載されている「Webex エクスペリエンス管理」の章を参照してください。https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_12_0_1/Configuration/Guide/ucce_b_ucce-features-guide-12.html

Related Information

Webex エクスペリエンス管理に関する考慮事項

精密なルーティング

プレシジョン ルーティングは、Unified CCE のルーティング機能です。プレシジョン ルーティングは、従来のルーティングを拡張するものであり、これに置き換わるものです。

従来のルーティングでは、エージェントの全スキルがビジネス ニーズの階層にマッピングされます。ただし、従来のルーティングには 1 次元の性質による制限があります。プレシジョン ルーティングは、簡単な設定、スクリプティング、およびレポートを使用した多次元のルーティングを提供します。この機能は、スキルを持っていることだけではなく、スキルのさまざまな習熟度を記録します。習熟度を含むこれらの複数の属性によって、各エージェントの能力がより正確に示されます。ルーティングの精度が大幅に向上することにより、ビジネスにさらに多くの価値がもたらされます。

属性を組み合わせて使用することで、多次元のプレシジョン キューを作成できます。Unified CCE スクリプトはプレシジョン キューを動的にマッピングして、発信者のニーズとそれに最も適した利用可能なエージェントを合致させます。

プレシジョン ルーティングの詳細については、『 Cisco Unified Contact Center Enterprise 機能ガイド』（http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html）を参照してください。

Related Concepts

プレシジョン ルーティングに関する考慮事項

シングル サインオン（SSO）

シングル サインオン (SSO) 機能は、コンタクトセンター ソリューション アプリケーションおよびサービスへのエージェントおよびスーパーバイザ アクセスを認証および承認します。認証とは、ユーザの身元（「ユーザが主張どおりの本人であること」）を立証するプロセスです。承認とは、認証済みユーザに対してユーザが要求したアクションの実行を認めるプロセスです（つまり、「ユーザは要求したことを実行することができます」）。コンタクト センター ソリューションで SSO を有効にすると、ユーザは 1 回サインインするだけで、すべての Cisco ブラウザ ベースのアプリケーションおよびサービスにアクセスすることができます。SSO により Cisco Administrator アプリケーションにアクセスすることはできません。

SSO には以下が必要です。

- サードパーティのアイデンティティ プロバイダー（IdP）

- Cisco Identity Service (Cisco IdS) クラスタ

SSO を使用できるユーザがサインインすると、Cisco IdS は、最初に ID プロバイダー（IdP）とやり取りしてユーザを認証します。ユーザが認証されると、Cisco IdS はアクセスが試みられている Cisco サービスを確認して、ユーザが要求されたロールに対して承認されていることを確認します。ユーザが認証および承認されると、Cisco IdS は、アプリケーションへのユーザのアクセスを許可するアクセス トークンを発行します。アクセス トークンを使用すると、ユーザは資格情報を再度提示することなく、そのセッションの承認済みのコンタクト センター アプリケーションを切り替えることができます。

- SAML 2.0 認証

- SAML 2.0 で使用される要素

- Cisco Identity Service（IdS）

- 認証および承認のフロー

Related Concepts

シングル サインオン（SSO）に関する考慮事項

Cisco IdS の帯域幅に関する検討事項

SAML 2.0 認証

SSO はセキュリティ アサーション マークアップ言語（SAML）を使用して、ID プロバイダー（IdP）とサービス プロバイダイーとの間で認証の詳細情報を交換します。ID プロバイダーは、ユーザ クレデンシャルを認証して SAML アサーションを発行します。SAML アサーションは、ユーザ認証のために ID プロバイダーからサービス プロバイダーに転送されるセキュリティ情報です。各アサーションは、ユーザ名や権限などのサブジェクトに関する信頼されたステートメントを含む XML ドキュメントです。通常では、信頼性を確保するために、SAML アサーションはデジタル署名されます。

汎用 SAML 認証のフローは以下から構成されます。

- クライアント：サービスへのアクセスに使用されるブラウザ ベースのユーザ クライアント

- サービス プロバイダー：ユーザがアクセスを試みるアプリケーションまたはサービス

- ID プロバイダー：ユーザ認証を実行するエンティティ

ID プロバイダーは、実際のクレデンシャルと認証メカニズムを非公開にしておきます。ID プロバイダーは、認証プロセスの結果に基づいて、SAML アサーションを発行します。

SAML 2.0 で使用される要素

SSO SAML 2.0 認証で使用される要素の一覧を以下に示します。

- クライアント（ユーザのクライアント）：これは、ブラウザ ベースのクライアントまたは認証用にブラウザ インスタンスを活用できるクライアントです。システム管理者のブラウザはその一例です。

- Lightweight Directory Access Protocol (LDAP) ユーザ: ユーザはLDAP ディレクトリで統合されています。たとえば、Microsoft Active Directory または OpenLDAP があります。

- セキュリティ アサーション マークアップ言語（SAML）: アサーションは、サブジェクトに関する信頼できるステートメントを含む XML ドキュメントです。たとえば、ユーザ名があります。信頼性を確保するために、SAML アサーションはデジタル署名されます。これは、ユーザ認証のために ID プロバイダー（IdP）からサービス プロバイダーに転送されるセキュリティ情報で構成されています。

- サービス プロバイダー (SP): SAML アサーションを信頼し、IdP に依存してユーザを認証するアプリケーションまたはサービス。たとえば、Cisco Identity Service（IdS）があります。

- ID プロバイダー（IdP）サーバ：これは、ユーザ資格情報を認証し、SAML アサーションを発行するエンティティです。

- SAML リクエスト: Cisco Identity Service (IdS) によって生成される認証要求。LDAP ユーザを認証するために、IdS は認証要求を IdP に委任します。

- 信頼の輪（CoT）：共同で単一の IdP に対して共有と認証を行うさまざまなサービス プロバイダーで構成されます。

- メタデータ: Cisco IdS によって生成された XML ファイル (たとえば、Cisco Identity Service Management) および IdP。SAML メタデータの交換により、IdP とサービス プロバイダーの間に信頼関係が確立します。

- Assertion Consumer Service（ACS）URL：アサーションをポストする場所を IdP に指示します。

Cisco Identity Service（IdS）

コンタクト センター ソリューションに対する認証は、Cisco Identity Service（Cisco IdS）によって管理されます。SSO を使用できるユーザがサインインすると、Cisco IdS は、最初にカスタマーの ID プロバイダー（IdP）とやり取りしてユーザを認証します。IdP はユーザ プロファイルを保存して認証サービスを提供し、SSO サインオンをサポートします。ユーザが認証されると、Cisco IdS はユーザがアクセスを試みているシスコ サービスと情報を交換し、ユーザがその要求しているロールに対して承認されていることを確認します。ユーザが認証および承認されると、IdS は、アプリケーションへのユーザのアクセスを許可するアクセス トークンを発行します。特定のセッション中にアクセスが確立されると、ユーザは、クレデンシャルを再提示することなく、コンタクト センター ソリューションのアプリケーションを切り替えることができます。

認証および承認のフロー

認証と承認の全体的なフローが次のようにシンプルになりました。

- 保護されているリソースがあるアプリケーションにアクセスすると、認証のために Cisco Identity Service にリダイレクトされます。Cisco Identity Service は、SAML を使用して SAMLRequest を生成し、ブラウザを ID プロバイダーにリダイレクトします。

- ブラウザは、ID プロバイダーに対して直接認証されます。アプリケーションは認証プロセスには関与せず、ユーザ クレデンシャルへのアクセス権もありません。

- OAuth フローは、その後有効化されるトークンを持つリソースにアクセスします。

- Cisco Identity Service は、ブラウザを介して ID プロバイダーに認証要求を送信します。

- ユーザは、認証のために ID プロバイダーにログイン クレデンシャルを入力します。アサーションが成功してユーザ属性が読み込まれると、アクセスされた元のアプリケーションにリダイレクトします。認証の正常な処理を確認して、Web アプリケーションのユーザ情報およびアクセス権を含むアサーションを伴う Cisco Identity Service。

認証および承認のフロー

ウィスパー アナウンスメント

ウィスパー アナウンスメントは、エージェントが各発信者に接続する直前に、あらかじめ録音されている短いメッセージをエージェントに対して再生します。アナウンスメントはエージェントにのみ再生されます。アナウンスメントの再生中、発信者には呼び出し音が聞こえます。

アナウンスメントには発信者に関する情報を含めることができるので、エージェントがコールへの対応を準備する上で役立ちます。情報には、発信者の言語設定、発信者がメニューから選んだ内容（セールス、サービス）、顧客のステータス（プラチナ、ゴールド、標準）などを含めることができます。

ウィスパー アナウンスメント機能を有効にした後、コール ルーティング スクリプトで再生するアナウンスメントを指定します。スクリプトにより、さまざまな入力に基づいて再生するアナウンスメントを選択します。たとえば、さまざまなダイヤル番号、カスタマー データベースでのカスタマー ID の参照、発信者が VRU メニューから選択した項目などに応じて、異なるスクリプトが再生されます。

Related Concepts

ウィスパー アナウンスメントに関する考慮事項

コール フロー

リファレンス設計は、Unified CVP 包括的コール フローのみをサポートしています。包括的なコール フローには、VRU、キュー、および IP スイッチが含まれています。

論理コンポーネントの接続

- 包括

包括

この包括的なコール フローでは、VoIP ネットワークを介してコールをルーティングおよび転送することができます。たとえば、このモデルを使用して VRU サービスを提供したり、エージェントにルーティングするコールをキューに入れたりすることができます。発信者は、まず VRU に到達します。エージェントがサポートを必要とする場合、該当するコールはキュー処理を受信し、エージェントに転送されます。エージェント間のコールを転送することもできます。Unified CVP および Unified CCE はこれらのエンドポイント間でコール データを渡したり、すべてのコールに関してレポートを生成したりすることができます。

この包括的なコール フローには、以下の機能があります。

- 発信者は、イングレス音声ゲートウェイを終端とした市内局番、市外局番、またはフリーダイヤル番号経由で、また VoIP エンドポイントからコンタクト センターにアクセスすることができます。

- 統合セルフサービス アプリケーション、キューイング、最初のプロンプトおよび収集、IP スイッチ機能を含む VRU が提供されています。

- Unified CCE エージェントへのコールのルーティングおよびキューイングが可能です。

- SIP を使用する必要があります。

- ビデオ IVR、ビデオ キューイング、およびビデオ エージェントの機能を提供します。

- オプションの Unified CVP VXML Server を使用する。

- オプションの ASR および TTS サービスを使用してデータのプロンプトまたはコレクトを行う。

- 着信コール

- ICM マイクロ アプリまたは CVP Call Studio アプリを含む包括的

- ビデオ コール フロー

- 補足サービス

着信コール

外部通信業者 (SIP または TDM) または社内のヘルプ デスクから着信コールを受け取ることができます。輻輳制御では、CPS に対する着信コールがカウントされます。

Note

すべての新しい着信コールは常に Cisco IOS ゲートウェイ ( CUBE または TDM-IP gateway) を通り、提供される Unified CVP サービスに関連付けられます。

- キャリアからの着信コール

- 内部ヘルプ デスクからの着信コール

キャリアからの着信コール

以下の表は、基本的な SIP トランクまたは TDM-IP GW コール フローを示しています。

通話フロー

論理 コール ルーティング

キャリアからの着信コール

VRU:

発信者 --> キャリア --> CUBE または TDM-IP GW --> Unified CVP --> 音声ブラウザ

エージェント:

発信者--> キャリア--> CUBE または TDM-IP GW--> Unified CVP--> Unified Communications Manager -> エージェント 1

Note

サードパーティの SBC または UUnified CM Session Management Edition (Unified CM SME) を介して、キャリアにフロントエンドでコールを発信することができます。このソリューションの着信コール フローは以下の通りです。

発信者--> Unified CM SME (または SBC)--> CUBE--> Unified CVP

以下の図のコール フローは、コール フロー機能のユニットを表しています。コール発信時には、これらのコールのユニットを任意の順序で組み合わせることができます。

VRU とエージェントへのキューを使用した基本的なコール フロー

キャリアから TDM ゲートウェイへの着信コール、あるいは SBC から CUBE ゲートウェイへの着信コールのコール フローは以下の通りです。

1. CUBE または TDM ゲートウェイから CVP への新しい着信コール。

2. CVP から Unified CCE への新しい着信コール。

3. 「Hello World」プロンプトを再生します。

4. CVP は、音声ブラウザにコールを送信し、発信者は VRU を受信します。

5. エージェントが利用可能になると、Unified CCE にエージェント番号が CVP に送信されます。

6. CVP は、Unified CM を通じて、コールをエージェントの電話機に送信します。

内部ヘルプ デスクからの着信コール

IP フォンを使用する企業は、従業員にコールイン セルフサービス アプリケーション（たとえば、福利厚生プログラム加入用のアプリケーション等）を提供することができます。あるいは、従業員が IT ヘルプ デスクなどのエージェントに連絡しようとして、キューで待機することになる場合もあります。上記シナリオは、いずれも Unified CM で発生して Unified CVP に送信されるコールになります。

通話フロー

論理 コール ルーティング

Unified Communications Manager (社内ヘルプ デスク) からの着信コール

VRU:

発信者--> Unified CM--> CUBE (E)--> Unified CVP--> 音声ブラウザ

エージェント:

発信者--> Unified CM--> CUBE (E)--> Unified CVP--> Unified CM-> エージェント 1

内部ヘルプ デスク コール フロー

Unified CM クラスタに登録されている電話機からの着信コールのコール フローを以下に示します。

1. CUBE または TDM ゲートウェイから CVP への新しい着信コール。

2. CVP から Unified CCE への新しい着信コール。

3. 「Hello World」プロンプトを再生します。

4. CVP は、音声ブラウザにコールを送信し、発信者は VRU を受信します。

5. エージェントが利用可能になると、Unified CCE にエージェント番号が CVP に送信されます。

6. CVP は、Unified CM を通じて、コールをエージェントの電話機に送信します。

Note

必要があれば、以下のコア コンポーネント間に Cisco Unified SIP プロキシを挿入することができます。

- (CUBE または TDM-IP GW) から (CVP または Unified CM)

- CVP 発信 (音声ブラウザまたは Unified CM)

- Unified CM 発信 (CUBE または TDM-IP GW または CVP)

ICM マイクロ アプリまたは CVP Call Studio アプリを含む包括的

マイクロ アプリケーションまたは Call Studio アプリケーションを使用する場合、コール フローは以下の通りです。

新しい着信コールの詳細なコール フロー

1. 新しい着信コールが CUBE または TDM-IP ゲートウェイに届きます。

2. CVP から Unified CCE への新しい着信コールが送信されます。CVP コール サーバが、VRU によって Unified CCE にルート要求を送信します。DN に対するこのルート要求は、DN とコールタイプの関連付けに基づいてルーティング スクリプトを実行する Unified CCE を呼び出します。

3. Unified CCE ルーティング スクリプトは、暗黙的または明示的な VRU ノードへの送信 を使用して、ラベルを CVP コール サーバに返します。次にスクリプトの実行が一時停止します。

ラベルは、CVP に対して設定されたネットワーク VRU とランダムな相関 ID を組み合わせたものです。

4. CVP コール サーバは、ネットワークの VRU ラベルをブラウザの IP アドレスに変換することによって、SIP Invite メッセージを音声ブラウザに送信します。必要があれば、SIP プロキシ サーバをパス スルーすることも可能です。

5. 音声ブラウザは、ネットワークの VRU ラベルを使用して、[HTTP New Call] メッセージを VXML サーバに送信します。

6. 次に、VXML サーバが要求をコール サーバに送信します。

7. 次に、CVP コール サーバは、Unified CCE に要求指示メッセージを送信し、Unified CCE はルーティング スクリプトを再開します。

8. Unified ICM ルーティング スクリプトは、Run Script ノードを使用して、VRU 処理について CVP コール サーバに指示します。

Unified CCE は　Run Script Request メッセージを送信して、VRU 操作を実行することができます。この要求では、以下が呼び出し可能です。

- マイクロ アプリケーション: マイクロ アプリケーションを使用して単純な VRU 動作を行います。プロンプトの再生や数字の収集などの基本操作をサポートします。マイクロ アプリケーションは Unified CCE スクリプトで参照され、ネットワーク VRU スクリプトの一部として定義されます。

- Call Studio アプリケーション: Call Studio アプリケーションを使用して複雑な VRU コール フローを処理します。Call Studio Designer で設計して、VXML サーバに配置します。その後、Unified CCE スクリプトでアプリケーションを参照することができます。

9. コール サーバは、VXML サーバと通信して特定のアプリケーションを呼び出します。

マイクロ アプリケーションまたは Studio アプリケーションに基づき、VXML サーバによって適切な VXML ページが生成されます。音声ブラウザは、発信者にページをレンダリングします。VXML サーバおよび音声ブラウザは、アプリケーションが終了するまで相互にやり取りします。

10. 音声ブラウザは、VXML ページの実行中に以下のサービスのいずれかに接続されます。

- 音声プロンプトについては、HTTP 経由でメディア サーバに接続します。これは、CVP サーバ上で共存します。

- ASR/TTS では、外部音声サーバとの MRCP 接続を確立して、テキスト プロンプトの合成、ユーザ入力用のユーザ音声認識を行います。

- ビデオの場合、ビデオ プロンプトを再生するには、SIP を経由して外部の サーバに接続します。

Note

他に実行するアプリケーションがある場合、コール フローはステップ 8 ～ 10 を繰り返します。

11. エージェントが利用可能になると、Unified CCE にエージェント番号が CVP に送信されます。Unified CCE スクリプトがスクリプト内でキューノードまたはリリースノードを取得すると、VRU の実行が停止します。音声ブラウザを使用した SIP コール レグは終了します。

12. CVP は、Unified CM を通じて、コールをエージェントの電話機に送信します。

ビデオ コール フロー

このコール フローは、エージェントに接続する前に、ビデオ VRU を使用して実行されます。

ビデオ コール フロー

1. Unified CM から CVP に着信コールを送信します。

2. CVP から Unified CCE に着信コールを送信します。

3. CVP Studio ビデオ アプリケーションの再生。

4. CVP から VXML ゲートウェイにコールが送信されます。

5. CVP VXML サーバは、DN XXXX に接続するように VXML ゲートウェイに指示します。

6. CUBE が、DN XXXX でのビデオ メディア サーバにコールを送信します。発信者は静的なビデオを取得します。

7. この時点でエージェントが利用可能になります。

8. CVP がエージェントにコールを送信します。

補足サービス

補足サービスには下記があります。

サポートされるシステム コール フロー

システム コール フロー

サポートあり

保留と保留解除

Yes

転送および会議の打診

Yes

ブラインド転送および会議

Yes

ルータ再クエリ

Yes

Unified CVP を使用したポストルート

はい

- 保留と保留解除

- 転送および会議

- SIP Refer 転送

- ネットワーク転送

- 再クエリおよび耐障害性

保留と保留解除

エージェントは保留を使用して、コールを一時停止します。保留中の音楽のリソースがある場合、発信者には保留中の音楽が流れます。それ以外の場合、発信者にはトーン音が聞こえます。

- マルチキャスト保留音

マルチキャスト保留音

ユニキャスト Music-on-Hold（MOH）の代替として、Unified CM上の補足サービスを使用して MOH をマルチキャストすることが可能です。この機能を使用して MOH を展開する場合は、以下のオプションがあります。

- Unified CM を使用して、ローカル LAN でのパケットのマルチキャストを行います。

- ブランチ ゲートウェイを使用して、ローカル LAN でのマルチキャストを行います。

ゲートウェイで Survivable Remote Site Telephony (SRST) を設定している場合は、ブランチ ゲートウェイ マルチキャストを使用します。この方法を使用すると、展開で MOH をローカルに使用でき、WAN リンク上での MOH ストリーミングを避けることができます。

Note

Call Manager Enterprise（CME）で MOH を設定する方法については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/manual/cmeadm/cmemoh.html#wpmkr1022205 を参照してください。

転送および会議

ほとんどのコンタクト センター ソリューションでは、エージェントが他のエージェントとのコールを転送または会議を開始することができます。会議を転送または開始するには、以下の 2 つの方法があります。

- Blind

- Consult (ウォーム転送とも呼ばれます)

ブラインド転送および会議

ブラインド転送では、最初のエージェントが番号をダイヤルして通話を終了します。発信者は 2 人目のエージェントに接続されるか、必要に応じてキューに格納されます。このタイプの転送は Unified CM が発信するコールを必要としません。

VRU および 2 人目のエージェントへのブラインド転送のコール フロー

1. エージェント 1 は、Unified CM から Unified CCE への着信コールとして、ブラインド転送要求を開始します。

2. エージェント 2 は応答不可であるため、コールは VRU に送信されます。

3. Unified CM を介してコールが Unified CVP に送信されます。

4. Unified CCE は、CVP が音声ブラウザに接続し、VRU またはキューの音楽を再生するように指示します。

5. Unified CVP から音声ブラウザにコールが送信されます。発信者には、VRU またはキューの保留音楽が流れます。

6. エージェント 2 が応答可能になると、Unified CCE がエージェント番号を CVP に送信します。

7. Unified CVP が、SIP コールを Unified CM 経由でエージェント 2 に送信します。VRU またはキューの音楽は切断されます。

8. Unified CM はエージェント 2 にコールを送信して、コール データが Cisco Finesse デスクトップに表示されます。

9. 発信者はエージェント 2 と話をします。

コンサルタティブ転送および会議

ウォーム転送または会議では、発信者が保留状態の間にエージェントは番号をダイヤルして 2 番めのエージェントに接続されます。2 人のエージェントが会話することができ、発信者と会議形式で話し、その後、最初のエージェントが離脱します。2 人目のエージェントが応答不可の場合、キューに格納されるのは（発信者ではなく）最初のエージェントです。最初のエージェントをキューに入れる必要がなければ、この処理はすべて Unified CVP を介さずに実行することができます。最初のエージェントをキューに入れる必要がある場合は、最初のエージェントのコールを Unified CVP に転送し、Unified CM によるアウトバウンド コールを作成する必要があります。

SIP トランク コール フロー

通話フロー

論理 コール ルーティング

エージェント間ルーティング コールの通知

VRU:

エージェント 1 --> Unified CM--> Unified CVP--> 音声ブラウザ

エージェント:

エージェント 1--> Unified CM--> Unified CVP--> Unified CM--> エージェント 2

VRU および 2 人目のエージェントへのコンサルタティブ転送のコール フロー

1. エージェント 1 は、Unified CM から Unified CCE への着信コールとして、コンサルタティブ転送要求を開始します。

2. エージェント 2 は応答不可であるため、コールは VRU に送信されます。

3. Unified CM を介してコールが Unified CVP に送信されます。

4. Unified CCE は、CVP が音声ブラウザに接続し、VRU またはキューの音楽を再生するように指示します。

5. エージェント 1 の待機中は、VRU で処理されます。エージェントには VRU あるいはキューの待機中の音楽が流れ、発信者には保留音（MOH）が提供されます。

6. エージェント 2 が応答可能になると、Unified CCE がエージェント番号を Unified CM に送信します。

7. Unified CM が、エージェント 2 に SIP コールを送信します。VRU が切断されます。

8. エージェント 1 がエージェント 2 に打診

9. エージェント 1 が転送を完了します。発信者はエージェント 2 と対話し、エージェント 1 は通話を終了します。

Note

会議コール フローは、打診コール フローと同じです。会議コール フローとコール フローは共に、打診する際にコールは保留されず、エージェントが参加する会議の形態をとります。保留と再開、代替と再接続、打診と会議のコール フローは、Session Initiation Protocol (SIP) の ReINVITE プロシージャを呼び出して、メディア ストリームを移動させます。会議から VRU へのコール フローは、応対可能なエージェントが不在の場合のコール フローと似ています。

SIP Refer 転送

シナリオによっては、Unified CVP でコールを SIP 宛先に転送し、Unified ICM と Unified CVP で今後のコール制御が維持されないようにします。Unified CVP では SIP Refer 転送を実行できます。この転送では、Unified CVP がそれ自体をコールから削除して、認可された Unified CVP ポートを解放できます。イングレス音声ゲートウェイ ポートは、発信者または終端装置がコールを解放するまで、引き続き使用された状態のままです。SIP Refer 転送は、包括展開とコール ディレクタ展開のどちらにも使用できます。

次のいずれかの方法で SIP Refer 転送を実行します。

- Unified ICM が Unified CVP に rfXXXX という形式（rf5551000 など）のルーティング ラベルを送信します。

- アプリケーション制御の代替方法として、Unified ICM スクリプトの ECC 変数（user.sip.refertransfer）を値 y に設定し、その変数を Unified CVP に送信します。

Note

Refer の前に Send To VRU ノードを使用する場合のみ、ラベルを使用した直接の Refer 転送が機能します。

Unified CVP キュー処理が発信者に提供されたら、SIP Refer 転送を起動することができます。SIP Refer 転送は、Cisco Unified Communications Manager または他の SIP エンドポイント（SIP 対応 ACD など）に対して実行できます。

SIP を Unified CVP とともに使用している場合、Refer 転送に失敗してもルータ再クエリーがサポートされます。ただし、対象となるのは、存続可能性サービスが SIP Refer 要求を処理しないコールのみです。

ネットワーク転送

Unified CVP では、エージェントによる応答後に、別の宛先へコールを転送するネットワーク転送が可能です。

Unified ICM でネットワーク転送を制御する場合、次の 2 つのフラグを使用します。

- NetworkTransferEnabled：このフラグは Unified ICM スクリプトの一部です。有効にすると、Unified ICM によって最初のルーティング クライアント（NewCall ルート要求を送信したルーティング クライアント）に関する情報が保存されます。

- NetworkTransferPreferred：このフラグは Unified CVP の周辺機器ゲートウェイ設定で有効化されています。有効にすると、このルーティング クライアントからのルート要求では、ルート要求を送信したルーティング クライアントの代わりに、最初のルーティング クライアントにルート応答を送信します。

次に、ネットワーク転送の実行方法について説明します。

- ネットワーク転送を使用して、Unified CVP を介してエージェント 1 からエージェント 2 にのみブラインド転送を実行することができます。この場合、Unified CCE は、Unified CVP にエージェント 1 からコンタクトをルーティングし、音声ブラウザ（VRU処理用）または別の宛先（エージェント 2 等）にルーティングするよう指示します。

- Unified CVP でのウォーム転送または会議を実行するには、ネットワーク転送は使用できません。エージェント 1 がコンサルタティブ転送または会議を実行している間は、エージェント 1 へのコール レッグはアクティブでなければなりません。Unified CVP は、ウォーム転送または会議中にエージェント 1 からコールを戻すようにルーティングすることはできません。

ブラインド転送、ウォーム転送、または会議に関係なく、発信者が同じ番号をダイヤルする場合、は以下のタスクを実行します。

- Unified ICM スクリプトで NetworkTransferEnable フラグを有効にしないでください。

- 転送中にコール コンテキストを維持するには、転送要求または会議要求で同じ Unified CCE 周辺機器ゲートウェイの CTI ルート ポイントをダイヤルします。別の周辺機器ゲートウェイのルート パターンまたは CTI ルート ポイントをダイヤルすると、コール コンテキストが維持されません。

- SendToVru を Unified ICM ルーティング スクリプトの最初のノードとして使用してください。

Note

予備ポートがコンサルテーション、ブラインド転送、または電話会議中に使用されます。これらのポートは、発信側のコンサルテーションが終了したら解放されます。

再クエリおよび耐障害性

ルータの再クエリを使用すると、ネットワーク障害によるコールの再ルーティングを行うことができます。たとえば、[応答なし]、[通話中]、[ネットワーク到達不能] により、ルータの再クエリがトリガされます。Unified CCE スクリプトのキューノードとラベル ノードのみがルータの再クエリをサポートしています。上記ノードからのエラー パスに基づいて、スクリプト内の再ルーティング ロジックを定義します。

CVP のコール耐障害性は、イングレス ゲートウェイ上で実行されます。CVP がダウンストリームでの障害を検出すると、耐障害性アクションがトリガされます。耐障害性のルーティングパラメータに基づき、コールの再起動やローカル SRST フォンへのコールの送信などのアクションをトリガすることができます。

トポロジ

Cisco Unified Contact Center Enterprise（Unified CCE）は、インテリジェント コール ルーティング、ネットワーク対デスクトップの Computer Telephony Integration（CTI）、およびマルチチャネル コンタクト管理を、IP ネットワークを介してコンタクト センターのエージェントに提供するソリューションです。Unified CCE は、IP 自動着信呼分配（ACD）を作成するソフトウェアを Cisco Unified Communications フレームワークに追加します。この統合ソリューションにより、企業は高度な分散型コンタクト センター インフラストラクチャを迅速に展開できます。

カスタマー コンタクトをソートするように Unified CCE を設定できます。Unified CCE はリソースの可用性をモニタし、各コンタクトに企業内の最も適したリソースを配布します。システムは、関連するデータ（着信番号と発信側回線 ID、発信者入力番号、Web フォームに送信されたデータ、カスタマー データベースの検索で取得された情報など）を使用して、各カスタマー コンタクトをプロファイルします。同時に、カスタマーのニーズを満たすために、エージェントのスキルと可用性、音声応答装置（VRU）のステータス、キューの長さなどを含めて、コンタクト センターの使用可能なリソースをモニタします。

Unified CCE を使用すると、インバウンドとアウトバウンドの音声アプリケーションをインターネット アプリケーション（リアルタイム チャット、Web コラボレーション、 E メールなど）とスムーズに統合できます。この統合により、カスタマーが選択した通信チャネルに関係なく、単一のエージェントが同時に複数のインタラクションをサポートできます。

Unified CCE ベースのモデルには、サポートされている Unified CCE モデル全体に適用される一般的な機能セットが含まれています。

- Unified Contact Center Enterprise アーキテクチャ

- トポロジ タイプ

- 中央集中型の導入

- 分散型展開

- グローバル導入

- リモート オフィス オプション

Unified Contact Center Enterprise アーキテクチャ

以下の図は、コンタクト センターの企業トポロジの論理ビューを示しています。サイト のローカルにあるエージェントは表示されません。

Contact Center Enterprise ソリューションのトポロジおよびリモート オフィス オプション

トポロジ タイプ

Contact Center Enterprise 向けソリューションには、以下の 3 つのトポロジ モデルがあります。

- 集中型展開: サーバは単一の メイン サイトに共存可能

- 分散型展開し: 地域的に異なる サイトのリストに追加しますに分散されるサーバ

- グローバル展開: リモート周辺機器ゲートウェイ (PG) および周辺機器

トポロジ

Note

1. メイン サイト では、集中型もしくは分散型のトポロジを使用することができます。

2. リモート サイトは、データ センターを使用して地理的にコロケートすることができます。最大で 150 のリモート ロケーション サイト

中央集中型の導入

集中型 サイト には、すべての Unified CCE 基本モデルのコンポーネントを含めることができます。中央集中型のデータ センターでは、エージェント、スーパーバイザ、および管理者がデータ センターにローカルに配置されています。集中型 サイト には、複数のエージェントのロケーションを含めることもできます。

ローカル エージェント導入シナリオでは、エージェント、スーパーバイザ、および管理者は サイトのローカルにあります。

- ローカル エージェント アーキテクチャ

- ローカル エージェント コンポーネント

- ローカル エージェントの利点

- ローカル エージェント設計の要件

ローカル エージェント アーキテクチャ

以下の図は、ローカル エージェントの物理ビューを示しています。

ローカル エージェント: 物理ビュー

ローカル エージェント コンポーネント

ローカル エージェント導入シナリオでは、コア ソリューションのコンポーネントに加えて、以下のコンポーネントが含まれています。

- レポートへのローカル アクセスのための Unified Intelligence Center ブラウザ クライアント

- 管理ツール (たとえば、Unified CCE 設定ツール、Internet Script Editor、またはローカル管理ワークステーション)

- エージェントまたはカスタマー コールの VoIP キャプチャ用のサードパーティの録音サーバ (オプション)

- サイレント モニタリングなどの機能をサポートする組み込みブリッジ (BIB) を使用したエージェント電話機。

ローカル エージェントの利点

ローカル エージェントの展開シナリオには、以下の利点があります。

- ロケーション ベースのコール アドミッション制御は不必要

- 容易なコーデック セットアップ

ローカル エージェント設計の要件

以下の表に、ローカル エージェントのメディア リソースを示しています。

ローカル エージェント設計の要件

要件

注

インフラストラクチャ

ロケーション ベースのコール アドミッション制御は不必要

ローカル エージェントは、LAN 帯域幅を使用します。これは通常、すべての Unified CCE トラフィックでは十分です。

デスクトップ

Cisco Finesse

CTI OS [1]

顧客関係管理

Codec

トランス コーディングは不要です。

すべてのエージェントがデータ センターに対してローカルである場合 (WAN 接続は不必要)、729 またはその他の圧縮された RTP ストリームを使用する必要はありません。

録音

Unified CM ベースの BIB

Cisco Unified Border Element とレコーダーを使用した Unified CM ネットワークベースの録音。Unified CM NBR機能を使用すると、発信元の Cisco Unified Border Element または IP フォンの BIB で CM コントローラ メディア分岐の環境設定とフォールバックを構成することができます。

デフォルトでは、すべてのエージェントを常に録画できます。選択的録音には、追加の統合作業が必要です。

サイレント モニタリング

Unified CM ベースの BIB

[1] Avaya PG または親/子トポロジを使用する非リファレンス設計のみが CTI OS デスクトップを使用することができます。Cisco Finesse は、他のすべての Contact Center Enterprise ソリューションで必要なデスクトップです。

以下の表に、ローカル エージェントのメディア リソースを示しています。

ローカル エージェントのメディア リソース

リソース

方法

注記

保留音

ユニキャスト

Unified Communications Manager

カンファレンス ブリッジ

BIB を使用した IP フォン

ハードウェア ベース、音声ゲートウェイ上

メディア ターミネーション ポイント

サポート対象外

トランスコーダ

ハードウェア ベース、音声ゲートウェイ上

a-law を備えた SIP トランクに必要です。

分散型展開

グローバリゼーション、セキュリティ、および ディザスタ リカバリの考慮事項により、ビジネスは複数の地域にわたって場所を多様化しています。さらに、サーバ間でワークロードを分散し、ネットワーク リソースを効果的に共有し、重要なアプリケーションの可用性を向上させる必要があります。地理的に冗長な サイトのリストに追加します では、重要なアプリケーションを 2 ヵ所のデータ センターに分割します。企業は地理的に冗長 サイトのリストに追加します を展開して、計画的または計画外のダウンタイムを最小限に抑え、地域間でデータを共有します。

地理的に冗長な サイトのリストに追加します は、各データ センターにロード バランサを持ちます。

- WAN を介したクラスタリング

WAN を介したクラスタリング

以下の図は、WAN 上のクラスタによる地理的に冗長な サイトのリストに追加します を示しています。

WANを介したクラスタリングによる地理的に冗長な サイト

地理的に冗長な サイトのリストに追加します は、WAN上のクラスタリング、分散型 Unified Communications Manager クラスタ、および Unified CVP、SIP プロキシ、音声ゲートウェイ、および Cisco Unified Intelligence Center の1 対 1 の冗長性を提供します。

高可用性 (HA) WAN でのレーテンシー要件は、WAN 経由のクラスタに対する現在の Cisco Unified Communications の要件を満たす必要があります。Unified CM では、最大遅延が 40 ミリ秒 (往復で 80 ミリ秒) が許容されます。

パブリック トラフィックとプライベート トラフィックをネットワーク内の別々のルートに保持し、標準の遅延と帯域幅を配慮します。パブリック トラフィックとプライベート トラフィックに対して、独立した物理回線を使用します。

グローバル導入

グローバル展開により、サービスプロバイダーは、集中管理 メイン サイト およびグローバル アクセスにより、世界規模で利用可能な単一のコンタクト センターを展開することができます。複数の顧客インスタンスを排除することによって、導入コストの削減につながります。

Unified CM は、集中型、リモート サイト、または顧客のオンプレミスのいずれかの場所に配置することができます。以下のグローバル展開トポロジがサポートされています。

- リモート CVP 展開

- リモート Unified CM 展開

- リモート CVP および Unified CM 展開

- マルチチャンネル オプションを使用したリモート MR PG 展開

- リモート CVP 導入

- Unified CM リモート導入

- CVP および Unified CM のリモート導入

リモート CVP 導入

この図に示されているトポロジは、リモート CVP 展開の簡略例を示しています。Contact Center Enterprise ソリューションでは、このトポロジを分散型 サイトのリストに追加しますで採用する使用例もあります。このトポロジでは、中央集中型 メイン サイトへのグローバル アクセスが提供されます。この導入には、リモート サイトのリストに追加しますでの Unified CCE VRU PG サーバを含む追加の Unified CVP サーバが必要です。WAN を介した中央コントローラを使用した最大 RTT は 400 ミリ秒です。

リモート CVP 展開のトポロジ

Unified CM リモート導入

エージェント、ゲートウェイ、および Unified Communications Manager クラスタが配置されるリモート オフィスがある場合は、サイトのリストに追加します での Unified Communications クラスタは、通常、1 つの独立した展開となります。この分散コール処理モデルでは、各 サイト に固有のエージェントおよび PG ペアリングを備えた独自の統合された通信クラスタが用意されています。

以下の図は、3 つの Unified Communications Manager クラスタを示しています。リモート オフィスは、メイン サイトへの WAN 接続を備えています。各 Unified Communications Manager クラスタは、独自のエージェントおよび PG ペアリングを使用して独立しています。JTAPI は WANではサポートされていないため、各 サイト は サイト にローカルなサブスクライバを使用します。たとえば、サイト A は サイト B のサブスクライバを使用できません。Unified CCE 中央コントローラ、Unified Intelligence Center、ロード バランサ、SIP プロキシ サーバ、および Unified CVP は、メイン サイトに存在します。TDM および VXML 音声ゲートウェイは、リモート オフィスでローカル PSTN トランクに配置されています。

リモート Unified Communications Manager クラスタ トポロジ

CVP および Unified CM のリモート導入

この図に示されているトポロジは、リモート CVP 展開の簡略例を示しています。この導入には、リモート リモート サイトでの Unified CCE 汎用 PG サーバを含む追加の Unified CVP サーバおよび Unified CM サーバが必要です。WAN 上の中央コントローラでの 最大 RTT は、400 ミリ秒に制限されています。

グローバル展開のトポロジ

リモート オフィス オプション

リモート エージェント サポートは、ブロードバンド ネットワーク接続または自宅の電話回線を介して、ブランチ オフィスまたは自宅のリモート エージェントにコンピュータ テレフォニー インテグレーション（CTI）、連絡先配布、およびレポート機能を提供します。Unified CCE では、エージェントの場所に関わらず、同じユーザ インターフェイスおよび機能機能をエージェントに提供します。

Unified Mobile Agent 機能により、コンタクト センターは迅速に対応可能なモバイル ワーカーに適応した柔軟性を提供します。エージェントは、ログインイン時間中に宛先の電話番号を選択して、必要な回数の番号の変更を行うことができます。エージェントは、任意のサードパーティ スイッチ インフラストラクチャの任意の電話機デバイス上に展開することができます。

Unified CCE リモート オフィス機能を使用すると、企業は、既存のリソースとオンデマンド リソースを利用して、拡張された企業間での CTI 機能を完全に拡大することができます。

リモート オフィス オプション:

- Unified CCE エージェントを含むオフィス

- エージェントとローカル トランクを備えたリモート オフィス

- Cisco Virtual Office

- Mobile Agent

- エージェント付きリモート オフィス

- エージェントとローカル トランクを備えたリモート オフィス

- Cisco Virtual Office を備えたホーム エージェント

- Unified Mobile Agent

エージェント付きリモート オフィス

エージェントを備えたリモート オフィスは、本社または支社オフィスのいずれかに配置されます。

エージェント付きリモート オフィス

以下の図は、エージェントを使用したリモート オフィスの物理ビューを示しています。

エージェントが配備されたリモート オフィス: 物理ビュー

エージェントが配備されたリモート オフィスのコンポーネント

エージェントを使用するリモート オフィスには、以下のコンポーネントが含まれています。

- レポートへのローカル アクセスのための Unified Intelligence Center ブラウザ クライアント

- 管理ツール: Unified CCE 設定ツール、Internet Script Editor、またはローカル管理ワークステーション

- Unified CM ベースのサイレント モニタリングのサポートに関する BIB を含むエージェントの電話機

エージェントが配備されたリモート オフィスの利点

エージェントが配備されたリモート オフィスには、以下の利点があります。

- 少数エージェントの場合、リモート サイトにある小規模データ スイッチおよびルータ、IP フォン、およびエージェント デスクトップのみが必要です。

- リモート サイトでは、限定的なシステムおよびネットワーク管理スキルのみが必要です。

- 小規模リモート サイトおよびオフィスでは、PSTN トランクは必要ありません。

- 着信トラフィックの PSTN トランクは、効率を上げるために メイン サイト に接続します。

- Unified CCE のキュー ポイント (Unified CVP) は、効率を高めるために集約されています。

- コール キュー中は VoIP WAN 帯域幅を使用しません。コールが WAN を経由するのは、エージェントが発信者に応答可能な場合のみです。

エージェントが配備されたリモート オフィスの要件

以下の表に、エージェントを使用したリモート オフィスの設計要件を示します。

エージェントが配備されたリモート オフィスの要件

要件

注

インフラストラクチャ

Location-based コール アドミッション制御

Unified CM の場所に基づくコール受付制御に失敗すると、切断時ルーティング コールが生成されます。リモート サイトへの十分な帯域幅を確保し、QoS WAN を設計します。

帯域幅

以下のトラフィックの帯域幅キャパシティを計画します。

- RTP (発信者からエージェントへ)

- IP フォン への Unified CM のシグナリング

- クライアント デスクトップから PG へ (CTI データ)

- ISE クライアントから ISE サーバへ

- 管理クライアント

- Unified Intelligence Center クライアントから Unified Intelligence Center サーバへ

- サイレント モニタリング RTP

- 録音 RTP (リモート オフィスに録音サーバがない場合)

- Unified CM ユニキャスト保留音を使用する場合の保留中のコールの保留音トラフィック

- ライブ データ

Note

適切な帯域幅および QoS のプロビジョニングは、クライアント デスクトップから PG へのリンクに重要です。

顧客の連絡先番号

顧客が本社に電話する際、ローカルの PSTN 番号ではなく、長距離番号をダイヤルする必要がある場合があります。顧客にはフリー ダイヤル番号を提供できますが、コンタクト センターは、フリーダイヤルに関して課金されます。

デスクトップ

Cisco Finesse

顧客関係管理

Codec

G.711 または G.729a

G.711 では G.729a 以上の帯域幅が必要です。

録音

BIB

ネットワーク ベースの録音

音声フォークには、Unified Border Element が必要です。

サイレント モニタリング

Unified CM ベースの BIB

以下の表に、エージェントを使用したリモート オフィスのメディア リソースを示します。

エージェントのメディア リソースが配備されたリモート オフィス

リソース

方法

注記

保留音

Unified CM を使用したユニキャスト

カンファレンス ブリッジ

ハードウェア ベース、音声ゲートウェイ上

会議ブリッジは、ローカルの Unified Survivable Remote Site Telephony (SRST) を使用します。

メディア ターミネーション ポイント

ハードウェア ベース、音声ゲートウェイ上

ユニファイド モバイル エージェントの場合、MTP は メイン サイトでのみ必要です。

トランスコーダ

ハードウェア ベース、音声ゲートウェイ上

トランスコーダは、ローカル Unified SRST を使用します。

エージェントとローカル トランクを備えたリモート オフィス

リモート オフィスでエージェントを採用し、着信コールにそれぞれローカル PSTN トランクを必要とするサイトを持つコンタクト センターの音声ゲートウェイ展開を使用します。この展開では、ローカル PSTN 接続がローカル コール向けに提供され、ローカル緊急サービスにアクセスできるようになります。

エージェントおよびローカル トランクを配備したリモート オフィス

エージェントおよび音声ゲートウェイのアーキテクチャを配置したリモート オフィス

以下の図は、エージェントおよび音声ゲートウェイを使用したリモート オフィスの物理ビューを示しています。

エージェントおよび音声ゲートウェイが配備されたリモート オフィス: 物理ビュー

エージェントおよび音声ゲートウェイが配備されたリモート オフィスのコンポーネント

エージェントおよび音声ゲートウェイを使用するリモート オフィスには、以下のコンポーネントが含まれています。

- ローカル PSTN を使用した Unified CVP 制御下でのイングレス音声顧客コール向けの Integrated Services Router (ISR) 音声ゲートウェイ。Unified SRST のバックアップにはトランクが必要です。

- レポートへのローカル アクセスのための Unified Intelligence Centerブラウザ クライアント。

- 管理ツール: Unified CCMP ブラウザ クライアント、インターネット スクリプト エディタ、またはローカルの管理ワークステーション。

- エージェントまたはカスタマー コールの VoIP キャプチャ用の サードパーティの録音サーバ (オプション)

- Unified CM ベースのサイレント モニタリングのサポートに関する BIB を含むエージェントの電話機

エージェントおよび音声ゲートウェイが配備されたリモート オフィスの利点

エージェントおよび音声ゲートウェイ搭載のリモート オフィスには、以下の利点があります。

- ほとんどのサーバ、機器、およびシステム設定が 1 ヵ所で管理されるため、リモート サイトではシステム管理スキルが限られています。

- リモート サイトに着信する WAN RTP トラフィックを必要とせず、エージェントが処理します。

- Unified CVP では、音声ゲートウェイの Cisco IOS の VXML ブラウザを使用して、リモート サイトでコール処理およびキューイングを行います。このコール処理とキューイングにより、コールを VoIP WAN を介して中央のキューと処理ポイントに移動する必要がなくなります。VVB は、ローカルで同じ機能を提供することができます。

エージェントおよび音声ゲートウェイが配備されたリモート オフィスの要件

以下の表に、エージェントおよび音声ゲートウェイを使用したリモート オフィスの設計要件を示します。

エージェントおよび音声ゲートウェイが配備されたリモート オフィスの要件

要件

注

インフラストラクチャ

Location-based コール アドミッション制御

Unified CM の場所に基づくコール受付制御に失敗すると、切断時ルーティング コールが生成されます。リモート サイトへの十分な帯域幅を確保し、QoS WAN を設計します。

帯域幅

以下のトラフィックの帯域幅キャパシティを計画します。

- 他のリモート オフィスに転送されたコールの RTP、またはコールが到着したリモート オフィスにコールが制限されていない場合に使用します。

- IP フォン への Unified CM のシグナリング

- クライアント デスクトップから PG へ (CTI データ)

- Unified Intelligence Center クライアントから Unified Intelligence Center サーバへ

- サイレント モニタリング RTP

- 録音 RTP (リモート オフィスに録音サーバがない場合)

- 音声ブラウザ (VXML ドキュメントおよび VXML ファイルの取得)

- Unified CM ユニキャスト保留音を使用する場合の保留中のコールの保留音

- ISE クライアントからサーバへ

- 管理クライアントから管理サーバおよびリアルタイム データ サーバ

- ライブ データ

デスクトップ

Cisco Finesse

顧客関係管理

Codec

G.711 または G.729a

G.711 では G.729a 以上の帯域幅が必要です。

録音

BIB

音声フォークには、Unified Border Element が必要です。

サイレント モニタリング

Unified CM ベースの BIB

以下の表に、エージェントおよび音声ゲートウェイを使用したリモート オフィスのメディア リソースを示します。

エージェントおよび音声ゲートウェイのメディア リソースが配備されたリモート オフィス

リソース

方法

注記

保留音

Unified CM を使用したユニキャスト

カンファレンス ブリッジ

ハードウェア ベース、音声ゲートウェイ上

会議ブリッジでは、ローカルの Unified SRST を使用します。

メディア ターミネーション ポイント

ハードウェア ベース、音声ゲートウェイ上

ユニファイド モバイル エージェントの場合、MTP は メイン サイトでのみ必要です。

トランスコーダ

ハードウェア ベース、音声ゲートウェイ上

トランスコーダは、ローカル Unified SRST を使用します。

- コール アドミッション制御の考慮事項

- Unified CM コール 管理コントロール

- リソース予約プロトコル

- コール アドミッション コントロールの展開

- Queue-at-the-Edge ブランチ オフィス 展開

- 拡張位置のコール アドミッション制御機能

- 分散型ネットワーク オプション

コール アドミッション制御の考慮事項

Unified CVP コンポーネントだけでなく、ソリューションとして、コール アドミッション制御について考慮することができます。これらの考慮事項は、Unified CM などの他の音声サービスが Unified CVP と同じゲートウェイを共有し、サイト間で帯域幅の量が制限されるような分散型ブランチ オフィス モデルでは最も明白です。同じコール アドミッション制御方式が、そのサイトから WAN を通過するすべてのコールに使用されるように、コール アドミッション制御方式がネットワークに配置されていることを確認します。2 つのコール アドミッション制御方式がそれぞれ 4 つのコールを許可し、WAN リンクでは 4 つのコールしか処理できない場合、両方のコール アドミッション制御エンティティが WAN への 4 つのコールを同時に許可できます。この制御方式により、音声品質は低下します。単一のコール アドミッション方式を実装できない場合は、各コール アドミッション制御方式に帯域幅を割り当てる必要があります。このような状況は、非効率的な帯域幅のオーバープロビジョニングにつながるため、望ましくありません。

Unified CVP 環境では、2 つのコール アドミッション制御方式を使用できます。それは、Unified CM ロケーションおよび Unified CM RSVP エージェントの 2 つです。単一サイト展開では、コール アドミッション制御は不要です。

Unified CM では、デバイスを特定のロケーションに割り当てて、それらのロケーション間でアクティブなコールの数を追跡することによって、コール アドミッションを行います。Unified CM では、使用される帯域幅を追跡します。また、コーデックに応じて、コールの数を決定することができます。

Unified CM コール 管理コントロール

Unified CM が Unified CVP との間でコールを送受信していて、Unified CVP ゲートウェイと IP フォン エージェントがリモート サイトに共存している場合、コール フローを理解して、コール アドミッション制御を正しく設計および制御できるようにすることが重要です。

リソース予約プロトコル

リソース予約プロトコル（RSVP）は、コール アドミッション制御に使用され、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。CAC のソリューションでは、Unified CVP および Unified CM のロケーション設定を使用します。

コール アドミッション コントロールの展開

コール アドミッション制御は、RTP ストリームを伝送できる十分な帯域幅がネットワーク上にあるかどうかを識別する機能です。Unified CM では、独自のロケーション機能、または RSVP を使用して、イングレス ゲートウェイと宛先 IP フォンのロケーション間の帯域幅を追跡します。

ネットワーク内で、リソース予約プロトコル（RSVP）は、コール アドミッション制御に使用されるプロトコルであり、ネットワーク内のルータでコール用の帯域幅を予約するために使用されます。RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。別の方法として、コール アドミッション制御のソリューションは、Unified CVP および Unified CM でロケーション設定を使用することが可能です。

Queue-at-the-Edge ブランチ オフィス 展開

次の図は、典型的な拠点オフィスの展開を示しています。

一般的な拠点オフィスへの展開。

単一のクラスタ Unified CM 展開に Unified CVP を展開して、queue-at-the-edge 機能を提供できます。この展開では、ブランチに配置されたイングレス ゲートウェイを使用して、発信者が代表番号または地域的番号ではなくローカル電話番号でアクセスできるようにします。この考慮事項は、複数の国にまたがる国際展開で特に重要になります。この展開の目標は、可能であれば、ブランチ オフィスで配置可能なエージェントに最初にコールをローカルにルーティングすることです。これにより、メディア ストリームはローカルに維持されます。

ブランチにエグレス ゲートウェイを配置して、ローカライズされたPSTN ブレークアウトを提供するか、分散型 TDM プラットフォーム（ACD）をソリューションに統合します。ゲートウェイとは別に、他のすべての CVP サブコンポーネントは メイン サイトに配置されます。WAN links を使用すると、各ブランチ オフィスから メイン サイトにデータ接続が提供されます。（メディア サーバは中央に展開されますが、一般に使用される VRU メディアは、ローカル拠点でキャッシュされます）。

この展開では、ブランチ オフィスには、（オプションで音声ブラウザとしても機能する）イングレス ゲートウェイ、エージェント用のIP フォン、IPT フォン、およびエージェント デスクトップのみが配備されます。

各ブランチの着信コールが同じブランチのエージェントに優先的に接続するように、Unified CCE スキル グループ、ダイヤル プラン、およびルーティングの優先順位を設定することができます。次に、RTP トラフィックはイングレス ゲートウェイから IP フォンに直接送信されます。RTP トラフィックは WAN を通過する必要はありません (シグナリングおよびデータが WAN を通過する場合もあります)。

ローカル エージェントが応答できない場合、コールのみが WAN リンクを介してリモート エージェントにルーティングされます。発信元のコールと最初の VRU の処理は、ローカルで実行されます。

WAN リンクに障害が発生した場合、TDM が発行したコールの POTS ダイヤル ピアで実行される CVP 耐障害性 アプリケーションは、着信コールをローカルにルーティングすることができます。

拡張位置のコール アドミッション制御機能

ELCAC の概念

次の定義が、ELCAC 機能において重要となります。

- ファントム ロケーション：帯域幅が無制限のデフォルトのロケーション。SIP トランクを介してヘアピンされたコールを計算する際に使用します。また、ローカル ブランチで SIP コールをキューに格納するときにも、帯域幅を正確に計算するためにファントム ロケーションを使用します。ファントム ロケーションは、CVP のゲートウェイまたはトランクに割り当てます。

- siteID：siteID は、Unified CVP が Unified ICM から受信したラベルに追加する数字文字列です。siteID に応じて、コールを宛先（ブランチ音声ゲートウェイかエグレス ゲートウェイ、または Unified CM ノードなど）にルーティングするようにダイヤル プランを設定します。siteID は、ラベルの先頭または末尾に付加したり、付加しないこともできます。この設定は、Unified CM ロケーション設定とは別になっており、Unified CVP に固有のものです。siteID はコールの実際のロケーションを示しているので、正確なロケーションから帯域幅を推測できます。siteID は、複数の Unified CM クラスタにわたって一意です。一意の siteID をプロキシ ルートの同じブランチ ゲートウェイにマッピングすることで、複数の siteID を引き続き同じブランチ オフィスにルーティングできます（必要な場合）。

- シャドウ ロケーション：この新しい位置は 2 台の Cisco Unified Communications Manager クラスタ間のクラスタ間トランクに使用されます。このロケーションは、クラスタ間 ELCAC が Unified CVP でサポートされていないため、使用されません。

ロケーションは Unified CM で作成されます。Operations Console で Unified CM のロケーション情報を同期させると、Unified CVP はそれらのロケーションを取得します。Operations Console でこれらのロケーションに siteID を関連付け、ゲートウェイとこれらのロケーションを関連付けることができます。この設定に基づいて、CVP は 2 つのハッシュ オブジェクトを作成します。1 つ目のハッシュはロケーションを siteID にマッピングし、2 つ目のハッシュはロケーションと siteID へのゲートウェイ IP アドレスのマッピングを保存します。これらのハッシュ オブジェクトは、適切な GW にコールをルーティングして（siteID により）エッジ キューイングを提供できるようにします。また、Unified CM が CAC を適切に計算できるように、コール レッグ上のロケーション情報を渡します。

ブランチ オフィスに展開する場合は、次の事項を考慮してください。

- WAN リンクで使用可能な帯域幅に基づいて、WAN リンクを通過してブランチ オフィスに届くコール数を制御します。

- queue-at-the-edge 機能の場合は、プライオリティに基づいて、特定のブランチ オフィスから発信されたコールをローカル音声ゲートウェイにルーティングします。

Unified CVP クラスタ内の拡張位置 CAC の場合は、WAN リンクを介してブランチ オフィスに達するコールの数を制御します。コールを許可する決定は、コールに使用される帯域幅を表す CAC の計算に基づきます。これらの計算は、コールが Cisco Unified Communications Manager 内の 2 台の電話機間の IP コールか、SIP トランクを介したコールか、または TDM-IP ゲートウェイから発信されたコールかに関係なく有効です。

queue-at-the-edge機能の場合、特定のブランチ オフィスから発信されたコールは、優先順位に基づいてローカルの音声ブラウザにルーティングされる必要があります。つまり、可能な場合は必ずローカル ブランチ エージェントを選択してください。

Unified CVP では、クラスタ内の拡張位置のコール アドミッション制御（ELCAC）を使用したトポロジのモデリングがサポートされます。クラスタ間の拡張位置の CAC はサポートされません。Location Bandwidth Manager はクラスタ内の CAC でイネーブルですが、クラスタ間の CAC ではディセーブルです。ELCAC トポロジ モデリングの詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html から入手可能な『Cisco Unified Communications SRND based on Cisco Unified Communications Manager』を参照してください。

拡張位置のコール アドミッション制御機能の比較

拡張位置のコール アドミッション制御（ELCAC）機能は、以前の CAC 機能の 2 つの重要な問題に対処します。

1. IP からの発信者およびエージェントからのポスト転送に関して、CAC で帯域幅の計算を誤る。

2. ブランチ オフィスで VRU 処理用のローカル VXML GW を確定的に選択できない。これは、問い合わせで 2 つのコール間に相関関係がない場合に、エージェントからのウォーム転送時に発生します。

ELCAC では、ロケーション情報がコール レッグにあるため、エージェント転送時にコールがローカル ゲートウェイにルーティングされます。VRU レッグで、CVP はこのロケーションに基づいてコールにサイト ID を追加します。SIP プロキシは、そのサイト ID を使用してローカル ゲートウェイに到達できます。

ELCAC でのルータ再クエリー

十分な帯域幅がないためにコールが Unified CM によって拒否された場合は、「ここで受け入れできません（Not Acceptable Here）」という SIP メッセージ 488 が Unified CVP に返されます。このメッセージにより、GED-125 インターフェイスを介した VRU 周辺機器へのルータ再クエリーがトリガされます。再クエリーが適切に設定されている場合、Unified CCE ルータは別のエージェント ラベルを返すことができます。

設計上の考慮事項

ELCAC の使用時に、次の考慮事項が適用されます。

- Unified CVP と Unified CM 間の SIP トランクをファントム ロケーションに関連付けます。

Note

Unified CM には、クラスタ間の ELCAC 用のシャドウ ロケーションもあります。これは CVP ではサポートされません。

- マルチクラスタの Unified CM 展開では、予想されるピーク時のコール量に基づいて WAN リンクの帯域幅をオーバーサブスクライブすることを検討してください。また、クラスタ間の ELCAC は Unified CVP ではサポートされないため、集中型ブランチ オフィス展開を選択することもできます。

- シングルクラスタの Unified CM 展開では、ELCAC は Unified CVP のハブ アンド スポーク トポロジでのみサポートされます。

- ELCAC siteID 機能は、MTP が必須として設定されるトランクでは機能しません。MTP が挿入されると、メディアがデバイスと MTP リソース間で終了してしまい、2 つのデバイス間で終了しないからです。

- Unified CM メディア レイヤによって MTP/トランスコーダ/TRP メディア リソースが挿入される場合、着信ロケーション情報は使用されません。

- クラスタ間コールが同じクラスタにループバックされない場合は、ロケーション CAC ロジックの以前の動作が適用されます。

- 各サイトには、siteID。同じサイトのすべてのゲートウェイを同じ siteID に合わせます。2 つのクラスタが同じロケーション名を使用する場合は、2 つの siteIDs を同じ物理ブランチにマッピングすることができます。

- 別の Unified CM クラスタは、最初のクラスタと同じロケーションである場合がありますが、Unified CVP で一意の siteID を使用する必要があります。同じロケーションのすべてのコールを、両方のクラスタが使用している共通の音声ゲートウェイに送信するように、プロキシ サーバのルートを定義することができます。

- 各クラスタは、そのクラスタ内のデバイスの帯域幅を管理します。2 つのクラスタが同じ物理ロケーションを使用している場合、それらのクラスタはそれぞれが管理する電話の帯域幅を個別に管理します。

分散型ネットワーク オプション

ゲートウェイは、以下のオプションで分散展開することができます。

- 組み合わされたブランチ ゲートウェイ: エッジでのコール処理と、ローカルにダイヤルされた番号のエンタープライズ仮想コンタクトセンターへの統合を可能にします。イングレス ゲートウェイおよび音声ブラウザの両方がブランチで使用されています。Cisco IOS 音声ゲートウェイを使用する場合は、イングレス ゲートウェイとその音声ブラウザ機能を組み合わせることができます。

- 集中型 VoiceXML ゲートウェイによるブランチ イングレス ゲートウェイ: ローカルのダイヤル番号と音声ブラウザのリソース グループの統合を有効にします。このオプションは、中規模から大規模のブランチが多数存在し、各ブランチでのコンタクト センターへのコール数が少ない企業向けにサポートを提供します。集中型音声ブラウザの VRU 通知は WAN を通過してイングレス ゲートウェイに到達します。

- ブランチ エグレス ゲートウェイ：WAN を経由してリモート TDM ターミネーションにコールを転送することができます。

また、これらの分散型オプションの組み合わせも使用できます。

Cisco Virtual Office を備えたホーム エージェント

Cisco Virtual Office ソリューションでは、テレワーカーにセキュアで包括的な管理可能なネットワーク サービスを提供することにより、柔軟性と生産性が向上されています。暗号化された VPN 経由で完全な IP フォン、ワイヤレス、データ、およびビデオ サービスが提供されます。Cisco Virtual Office は、透明性のあるオフィス レベルのエクスペリエンスを提供します。ビデオの再生はスムーズで、音声が途切れることがなく、ワイヤレス接続は容易です。

Cisco Virtual Office では、VPN ルータはデスクトップの QoS 機能を必要とします。設計の際は、Unified Intelligence Center の帯域幅、エージェント デスクトップ、録音などの追加コール フローを含めることができます。

ブロードバンドは帯域幅を保証しないことに留意します。このため、ブロードバンド リンクは、コンタクト センターのトラフィックの最小要件よりも大容量を使用する必要があります。帯域幅を拡大すると、エージェントはピーク時にアクティブな状態を維持できます。

Unified Mobile Agent

Unified Mobile Agent は、Unified CCE が直接制御しない電話機を使用するコール センター エージェントをサポートします。モバイル エージェントは、物理的にはコンタクト センターの外部に配置することも、内部に配置することも可能です。

- コンタクト センター外: エージェントは、自宅または携帯電話でアナログ電話機を使用します。

- コンタクト センター内: エージェントは、Unified CCE または Unified Communications Manager が制御しない IP フォン接続を使用します。

また、モバイル エージェントは、異なる電話番号を使用することもできます。エージェントは、ログイン時に電話番号を入力します。エージェントは、Unified CM ダイヤル プランを使用して番号をダイヤルすることができる限り、任意の電話番号を使用して Unified Mobile Agent にアクセスすることができます。

システム管理者は、nailed (恒久) またはコールバイコール接続を使用するように、Unified Mobile Agent を設定します。モバイル エージェントは、アウトバウンド キャンペーンに参加することができますが、すべての発信ダイヤル モードに対して 固定接続モードのみを使用することができます。

Unified Mobile Agent のコンポーネント

Unified Mobile Agent の展開シナリオには、以下のコンポーネントが含まれます。

- サイトのリストに追加します (音声なし) へのセキュアな VPN データ接続のための Cisco Virtual Office ケーブル/DSL ルータ

- エージェントは、ローカル電話機を使用して、従来のローカル電話サービスで着信コールを受信します。

- Cisco Finesse デスクトップの Cisco Virtual Office ケーブル/DSL ルータへの接続

- 管理ツール: Unified 設定ツール、インターネット スクリプト エディタ、またはローカル管理ワークステーション

Unified Mobile Agent の利点

Unified Mobile Agent の展開シナリオには、以下の利点があります。

- Unified Mobile Agent は、任意の PSTN または携帯電話にコールを送信することができます。これは、集中型の IP コンタクト センターのリーチを拡張します。

- コンタクトセンターでは、リモート ワーカーを地理的に分散したチームに統合して、同等の企業アプリケーションにアクセスする熟練した従業員を雇用することができます。

- コンタクト センターでは、通話量が多い季節に一時的にエージェントをオンラインにすることで、スタートアップ コストを削減することができます。エージェントは、サインアップ時に通知先の電話番号を選択することができます。この番号は、必要に応じて何度でも変更することができます。コンタクト センターは、迅速に対応可能なモバイル ワーカーに適応した柔軟性を提供します。

- モバイル エージェントは、中央サイトのエージェントと同じようにアプリケーションとサービスにアクセスします。地理的に分散されたエージェントには、ビジネス プロセスを不測の場合に対応させるために、組み込みバックアップ計画を作成します。

Unified Mobile Agent の設計要件

以下の表に、Unified Mobile Agent 設計要件を示しています。

Unified Mobile Agent の設計要件

要件

注

設定（Configuration）

ダイヤル プラン

専用ゲートウェイ上のモバイル エージェントの場合、CTI ポートからのすべてのコールは、電話番号が呼び出されているかどうかにかかわらず、サイト の特定のゲートウェイを経由します。

エージェントが選択される際のローカル CTI ポートのディレクトリ番号 (DN) を定義します。

モバイル エージェントをログイン状態のままにするには、最大コール時間タイマーおよび最大コール保留タイマーの両方の値を 0 に設定します。

上記タイマーを設定するには、Unified Communications Service を使用してサービス パラメータ用の Unified CM 管理 Web ページを使用します。

Cisco Unified Mobile Agent の接続トーンは、コールが 固定接続のモバイル エージェントに配信される際に音声で通知します。接続時のトーンは、コールに応答する際に、固定接続のモバイル エージェントが応答し、2 つのビープ音を鳴らします。

この機能はデフォルトでオフになっています。PG レジストリ キーの PlayMAConnectTone を使用して、Cisco Unified Mobile Agent 接続トーンを有効にします。

SIP トランク (CUBE)

CUBE は、コール中にメディア ポートをダイナミックに変更します。モバイル エージェント機能を使用する場合、エージェントのエンドポイントに接続する SIP トランクには MTP リソースが必要です。

Codec

G.711 または G.729

イングレスおよびエグレス音声ゲートウェイは、G.711 または G.729 に設定することができますが、混在させることはできません。

PG のすべての CTI ポートは、同じコーデック タイプをアドバタイズする必要があります。すべてのモバイル エージェントは同じコーデックを使用する必要がありますが、スーパーバイザ チームのローカル エージェントはコーデックを混在させて使用することができます。

モバイルエージェントは G.729 を使用し、残りのコンポーネントはすべてのコーデックをサポートするため、ゲートウェイ MTP を設定してコーデック パス スルーを実行します。

インフラストラクチャ

DNS

モバイル エージェント デスクトップの DNS エントリが必要です。モバイル エージェント デスクトップの DNS エントリがない場合、エージェントは CTI サーバに接続できません。

Firewall

固定接続を備えたエージェントがファイアウォールのアイドル タイムアウト値を超えてアイドル状態となった場合、ファイアウォールはメディア ストリームを阻止する可能性があります。これを回避するには、ファイアウォールのアイドル タイムアウト値を増大させます。

帯域幅

サポートされる最小帯域幅の速度:

- 256 kbps (アップロード)

- 1.0 Mbps (ダウンロード)

帯域幅カルキュレータを使用して、十分な帯域幅を提供します。

QoS は、リモート エージェント ルータのエッジでのみ有効にされます。現時点では、サービス プロバイダーは QoS を提供していません。

遅延

Unified CCE サイト に対するモバイル エージェントの往復遅延は、200 ミリ秒を超えることはできません。

モバイル エージェントのジッタ遅延は 60 ミリ秒を超えることはできません。

音声ゲートウェイ

モバイル エージェントには、エグレス ゲートウェイを使用します。

コール制御

RONA は、モバイル エージェントがログインして応答可能の状態の場合に使用しますが、コールの応答のために使用することはできません。

単一の PG 上のモバイル エージェントは、同じ Unified CM クラスタ内の別の PG 上のモバイル エージェントに対しては、ブラインド転送および会議のみを発信することができます。

電話

コール待機、コール転送、ボイスメールなどのエージェントの電話コール機能を無効にします。

エージェントのワークステーション

モバイル エージェントのワークステーションは DHCP を使用するように設定します。

セキュリティ

リモート エージェント ルータのセキュリティ機能を有効にします。

デスクトップ

Cisco Finesse

Cisco Finesse では、スイッチ ポート アナライザー (SPAN) ポート サイレント モニタリングがサポートされていません。

録音

SPAN ポート

ネットワーク ベースの録音

サイト での録音サーバ

サイレント モニタリング

なし

以下の表は、Unified Mobile Agent のメディア リソースを示しています。

Unified Mobile Agent メディア リソース

リソース

方法

注記

保留音

Unified CM ユニキャスト

MoHサーバが G.729コーデックを使用してストリーミングしない場合は、トランス コーダを設定して、外部の発信者が保留音を受信できるようにします。

カンファレンス ブリッジ

音声ゲートウェイ サイト

エージェント グリーティングには、会議ブリッジが必要です。

メディア ターミネーション ポイント

音声ゲートウェイ サイト

各 Unified Mobile Agent に 2 つの MTP を割り当てます。

- リモート CTI ポートの MTP

- ローカル CTI ポートの MTP

CTI ポートは、インバンドのデュアルトーン マルチ周波数 (DTMF) の RFC 2833 をサポートしていません。MTP が変換を実行します。

MTP はエグレス ゲートウェイに配置することはできません。

SIP トランクを使用している場合は、メディア ターミネーション ポイント (MTP) を設定します。

トランクの使用を有効にすると、コンタクト センター以外のコールでも、そのトランクを通過するすべてのコールに影響が及びます。使用可能な MTP の数がトランクを通過するコールの数をサポートすることを確認します。

トランスコーダ

音声ゲートウェイ サイト

すべてのモバイル エージェントには、同じコーデック (G.711、または G.729) が含まれている必要があります。

ソリューション管理

コンタクト センターのエンタープライズ ソリューションには、ネイティブ管理ツールのセットがいくつか用意されています。

ネイティブ ツールに加え、Unified CCE ソリューションは、Unified Contact Center 管理ポータル（Unified CCMP）管理スイートをサポートしています。Unified CCMPは、簡単な操作の Webベースの UI を提供して、日々のプロビジョニングおよび設定操作を合理化します。Unified CCMP により、別のサーバがソリューションに追加されます。

- Unified Contact Center 管理ポータル

- サービス作成環境

Unified Contact Center 管理ポータル

Unified Contact Center の管理ポータル (Unified CCMP) では、簡単な操作のブラウザの UI を提供して、日々のプロビジョニングおよび設定操作を合理化します。コンタクト センターの管理者、チームのリーダー、および管理者が、このツールを使用することができます。管理ポータルには、以下の利点があります。

- 電話、エージェント、スキル グループ、およびチームの移動、追加、変更などの基本的な管理タスクを実行するシンプルなブラウザ インターフェイス

- コンタクト センターのコンポーネントおよび Unified CM コンポーネントのテナントのプロビジョニング用の統一された構成

- 完全な自立性を備えた複数のビジネス ユニットをサポートするパーティション システム

- スコープが制限された複数のビジネス ロールをサポートする階層型管理

- 詳細設定の変更および使用状況に関する監査証跡レポート

サービス作成環境

Contact Center Enterprise ソリューションには、以下の 2 つのサービス作成環境が含まれています。

- Unified CVP Call Studio: Call Studio は、洗練されたダイナミックな VXML セルフサービス アプリケーションの作成、管理、および展開を容易にするプラットフォームです。Call Studio アプリケーションは、Eclipse フレームワーク内で実行されます。Call Studio で作業するには Eclipse に関する知識は必要ありません。Call Studio には、音声アプリケーション開発、Java プログラミング、Eclipse で提供されるその他の多くの機能用のプラグインが含まれています。

- Unified CCE スクリプト エディタ: スクリプト エディタは、ルーティング スクリプトと管理スクリプトを作成、更新、スケジュール、および監視するためのツールです。

サービス作成環境

ソリューションの保守およびモニタリング

コンタクト センターのエンタープライズ ソリューションは、複数のソリューション保守ツールをサポートしています。これらのツールは、ソリューションの各コンポーネントの同様のインターフェース（SNMP、Syslog、診断 REST / SOAP API、telnet / SSH CLI インターフェース）を活用しますが、独自の機能が提供されます。

- Analysis Manager

- Prime Collaboration Assurance

- Unified System CLI

また、サードパーティ SNMP とネットワーク管理ツールを使用して、ソリューションの保守性を監視し、実行することもできます。

- Prime Collaboration Manager

- Analysis Manager

- Unified System CLI

- Analysis Manager vs. Unified System CLI

- サードパーティのネットワーク管理ツール

- システム パフォーマンスのモニタリング ガイドライン

- 個々のエンドツーエンド コールのトラッキング

Prime Collaboration Manager

Unified Communications の導入を管理するために、Cisco の主要なコラボレーション保証製品を使用することができます。Cisco Prime Collaboration Assurance は、Cisco Unified Communications 製品ファミリの一つであり、ネットワーク管理、プロビジョニング、および Cisco Unified Communications 展開の監視用の包括的かつ効率的なソリューションを提供します。

Cisco Prime Collaboration Assurance は、ネットワーク内の IP 通信インフラストラクチャと基盤となるトランスポート インフラストラクチャの両方の現在の状態を監視および評価します。Cisco Prime Collaboration Assurance は、SNMP や HTTP などのオープン インターフェイスを使用して、IP 通信環境内のさまざまなデバイスからデータをリモートでポーリングします。

Cisco Prime Collaboration Assurance は、エンド ユーザが一貫した高品質のビデオおよび音声コラボレーション エクスペリエンスを確実に受信できるようにするモニタリング、トラブルシューティング、およびレポート機能を備えた包括的なビデオおよび音声保証および管理システムです。Cisco Prime Collaboration Analytics は、Managed Service Provider（MSP）モードではサポートされません。Cisco Prime Collaboration の主要な機能は以下の通りです。

- 音声とビデオの Unified Dashboard

- デバイス インベントリ管理

- 音声およびビデオのエンドポイント モニタリング

- 診断

- 障害管理

- レポート

- リンクの状態、デバイスの状態、デバイスのパフォーマンス、デバイス 360を備えた Live Contact Centerトポロジ

- コンタクト センターに関する 基本的なディスカバリ

- コンタクト センター デバイスのリアルタイム パフォーマンスのモニタリング

- 根本原因の解析に伴うイベントおよびアラーム

- コンタクト センターのデバイス ダッシュボード: 作成済みおよびカスタム

- しきい値、Syslog、相互関係、およびシステム ルール: ビルド済みおよびカスタム

- マルチテナントおよびログイン エージェントのライセンス情報

Analysis Manager

Unified Communications Manager リアルタイム監視ツール（RTMT）および Unified Analysis Manager 機能は、この診断フレームワークから診断情報を収集するクライアント側ツールとして提供されています。

管理者は、Analysis Manager を使用して、1 つ以上の Unified Communications デバイスに接続し、トレース レベルの設定、トレース ファイルとログ ファイルの収集、プラットフォームとアプリケーションの構成データ、バージョンおよびライセンス情報の収集を行います。Analysis Manager は、管理者がすべての Cisco Unified Communications アプリケーションおよびデバイスから診断情報を収集できるようにするツールです。

Analysis Manager は、認証用のローカル ユーザーおよびドメイン セキュリティとセキュアな HTTP を提供して、それによって交換されるデータおよび診断フレームワークを保護します。

Web Service Manager は、Analysis Manager からのすべての診断（ヘルスおよびステータス）要求をサポートします。Analysis Manager は UCM RTMT ツールの一部です。ネットワーク トポロジ内のすべてのデバイスのヘルス情報とステータス情報を収集するためのインターフェイスをユーザに提供します。Unified CVP がソリューションの一部として設定されている場合、Analysis Manager を介して WSM を使用し、コンポーネントおよびサブコンポーネント レベルで各 CVP デバイスの診断詳細（サーバ マップ、バージョン情報、ライセンス、コンフィギュレーション、コンポーネント、ログ、トレース、パフォーマンス係数、プラットフォーム情報など）を収集できます。コンポーネントおよびサブコンポーネント レベルで Analysis Manager を使用して、デバッグ レベルを設定または再設定できます。

wsmadmin というユーザ名の新しいユーザが、インストール時に オペレーションコンソールサーバ の管理者ユーザと同じパスワードで作成されます。wsmadmin を使用して、診断ポータル サービスへのアクセスを制御します。

Unified System CLI

Analysis Manager に加えて、クライアントが任意の Unified Communications サーバ上の診断フレームワークにアクセスできるようにするコマンド ライン インターフェイス（Unified System CLIツール）を使用することができます。Unified System CLI には、リモート デスクトップを使用せずにアクセスできます。

ソリューションで問題が発生した場合は、システム CLI ツールを使用して、Cisco エンジニアによるレビュー用のデータを収集します。たとえば、コールが適切に処理されていないと考えられる場合に、System CLI を使用できます。この場合、show tech-support コマンドを使用してデータを収集し、そのデータをシスコのサポートに送信できます。

Unified System CLI には次の機能があります。

- インフラストラクチャの一部としてすべての Unified CVP サーバに自動的にインストールされます。Unified CVP サーバに追加インストールは必要ありません。

- ソリューション トポロジ全体が、システム モードを使用して任意の Unified CVP ボックスで Operations Console から取得されます。

- ソリューション全体で一貫したコマンドが使用されます。

- Windows でスケジュール設定したジョブとして実行できます。

次の図に、Unified System CLI の上位レベルのコマンド、およびデバイスと Unified Cisco 製品の連携について示します。

Unified System CLI の上位レベルのコマンド

Unified System CLI は低いプライオリティで実行され、システムの CPU アイドル時間を使用します。負荷の下でシステムが実行されている場合でも、コール処理には影響しません。

所定の CLI コマンドからの応答時間は、システムの負荷およびサーバの応答時間によって異なります。実行負荷がない場合、操作（show version、show license、show debug、show perf など）では、各サーバの応答時間は 5 秒未満となります。実行負荷がない場合、show platform 操作での応答時間は、各サーバで 10 秒未満となります。

ただし、show trace、show log、show sessions、show all、show tech-support などのコマンドの応答時間は特定できません。これらのコマンドの応答は、サーバが転送するデータによって異なります。

- Unified System CLI の操作モード

Unified System CLI の操作モード

Unified System CLI はインタラクティブなユーザ インターフェイスとして動作し、バッチ コマンドとしても使用できます。この機能により、スケジュールされたジョブで Unified System CLI を使用できます。

Unified System CLI は、以下の 2 つのモードで対話形式で操作することができます。

- ローカル モード:このモードでは、Unified System CLI は単一のデバイスとのみ対話します。たとえば、show version コマンドでは、単一デバイスのバージョンのみが表示されます。

- システム モード:

- このモードでは、Unified System CLI は CLI のシード デバイスとして機能する Operations Console を検出し、Operations Console のデバイス リスト内のすべてのデバイスと対話して、ソリューション トポロジを自動的に抽出します。

このモードでは、show version コマンドによって、デバイス リスト内のすべてのデバイスのバージョン情報が表示されます。

- ローカル モードで使用可能な、単一デバイスのすべてのコマンドは、システム モードでも使用できます。

- コマンド構文は、システム モードでも同じです。

- システム コマンド オプションを特定のデバイス グループ、デバイス タイプ、またはサーバ リストに制限するオプションがあります。

Analysis Manager vs. Unified System CLI

Analysis Manager および Unified System CLI は診断ポータル API にアクセスします。以下の表に示す相違点を除き、Analysis Manager と Unified System CLI の両方に類似した機能があります。

Analysis Manager と Unified System CLI の相違点

Analysis Manager[AnalysisManager]

Unified System CLI

Unified CM Real-Time Monitoring Tool（RTMT）の一部である GUI ベースのクライアントです。Analysis Manager は GUI ベースの設計であるため、ユーザ フレンドリなインターフェイスを提供します。

コマンドライン ベースのツールです。Unified System CLI は、バッチ ファイルで使用してより複雑なタスクを実行できるため、柔軟性がより高くなります。

CVP にバンドルされていない、または Unified CVP インストーラでインストールされません。

Unified CVP インストーラにバンドルされており、Unified CCE インストーラにもバンドルされています。

サードパーティのネットワーク管理ツール

Unified CCE は Simple Network Management Protocol（SNMP）を使用して管理されます。Unified CCE デバイスは、SNMP v1、v2c、および v3 をサポートする組み込み型の SNMP エージェント インフラストラクチャを持ち、CISCO-CONTACT-CENTER-APPS-MIB により定義される計測手段を公開します。この MIB により、標準の SNMP 管理ステーションでモニタ可能な構成、検出、および状態の計測手段が提供されます。Unified CCE は、管理者にシステムの障害があれば警告する豊富な SNMP 通知セットを提供します。また、Unified CCE は、より詳細なイベント セットを必要とする管理者に対して、（RFC 3164 に準拠する）標準的な syslog イベント フィードも提供します。

Unified CVP および Unified Intelligence Centerが、SNMP v2 と v3 をサポートしています。

Cisco Finesse と Customer Collaboration Platform は、VOS プラットフォームからの SNMP のみをサポートします。Cisco Finesse および Customer Collaboration Platform アプリケーションから直接 SNMP を使用することはできません。

簡易ネットワーク管理プロトコル（SNMP）ステーションを使用すると、ソリューション展開ステータスを監視できます。

Unified CCE には Web ベース (REST に類似の) 機能が組み込まれており、すべての Unified CCE サーバで提供される診断フレームワークと呼ばれる診断機能を備えています。

システム パフォーマンスのモニタリング ガイドライン

エンタープライズ ソリューションのサポートおよび保守には、多くのステップおよび手順が必要です。サポート手順は展開された環境に応じて異なります。システム パフォーマンスのモニタリングは、システムの保守に役立つ 1 つの手順です。ここでは、Unified CCE をモニタリングして、システムがシステム許容範囲内で実行されていることを確認するためのガイドを提供します。システム モニタリングは、システムを拡張またはアップグレードしている場合は、特に重要です。高アクティビティの時間帯にシステムを監視します。

以下のシステム コンポーネントには、監視が重要です。

- CPU

- メモリ

- ディスク

- ネットワーク

以下の表は、重要なシステム コンポーネントの重要なカウンタおよびしきい値の一部を示しています。

しきい値のモニタリング

モニタ対象リソース

しきい値

CPU

処理時間 (%): このカウンターのしきい値は 60% です。

ProcessorQueueLength: この値は (2 * [システムの CPU の合計数]) 以下である必要があります。

メモリ

コミットされたバイト数 (%): この値は (0.8 * [物理メモリの総容量]) 未満である必要があります。

メモリ、使用可能な 1M バイト: この値は 16 MB 未満である必要があります。

ページ ファイルの使用率 (%): このカウンターのしきい値は 80% です。

ディスク

AverageDiskQueueLength: この値は (1.5 * [アレイ内の合計ディスク数]) 未満のままにします。

% Disktime;この値は 60% 未満のままである必要があります。

ネットワーク

NIC\bytes total/sec: この値は (0.3 * [NIC の帯域幅)] よりも小さい値である必要があります。

NIC\Output キュー長: このカウンターのしきい値は 1 です。

Unified CCE

Cisco Call Router(_Total) \ ログイン中のエージェント数

Cisco Call Router(_Total) \ 通話中のコール数

着信ルータ (_Total) \ コール数/毎秒

通常、繁忙時間のトラフィックがしきい値の 95 パーセンタイル以上にならないようにします。

Note

CPU、メモリ、ディスク、およびネットワークのパフォーマンス カウンタは、展開内のすべての Windows ベースのアプリケーションに適用されます。サンプリング レートは 15 秒です。

展開した VM の監視の詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.htmlの Cisco Collaboration 仮想化を参照してください。

個々のエンドツーエンド コールのトラッキング

コールがイングレス ゲートウェイに到達すると、Cisco IOS は、コールを識別する 36 桁の 16 進数のグローバル固有識別子（GUID）をそのコールに割り当てます。コンタクト センターは、この GUID を、コールを受信するすべてのコンポーネントに以下の通り伝送します。

- イングレス ゲートウェイ: Cisco IOS ログ ファイルに示されます。

- 音声ブラウザ: Cisco IOS および Cisco VVB のログファイルに表示されます。

- Unified CVP コンポーネント：Unified CVP ログ ファイルに示されます。

- 拡張コール コンテキスト（ECC）変数 user.media.id に表示され、すべての終了コール詳細 (TCD) およびルートコール詳細 (RCD) レコードとともに保存されます。

- 音声自動認識（ASR）および音声合成（TTS）サーバ：ロギング タグとしてログに示されます。

- Cisco Unified Communications Manager (Unified CM): 詳細ログに表示されます。

適切なレベルのロギングが有効化されていると、上記のすべてのコンポーネントでコールを追跡できます。

ローカリゼーション

Contact Center Enterprise ソリューションは、エージェントおよびスーパーバイザ デスクトップのローカリゼーションの支援にフォーカスしています。ほとんどの管理ツールは、英語のみを使用します。上記のツールは、SQL 照合用の適切な Windows コード ページの文字を以下の値で使用します。

- エージェント名

- 周辺機器変数

- ECC 変数

- ICM テーブルの説明フィールド

- 後処理データ

- 理由コード

ただし、ツール内では常に左から右に文字を入力します。各 Unified CCE インスタンスは、データベース内で単一の Windows コード ページのみをサポートします。展開したContact Center Enterprise ソリューションの 互換性マトリクス では、ソリューションで使用可能な Microsoft Windows サーバおよび SQL サーバのサポートされるローカライズ済バージョンの一覧が提供されています。

たとえば、SQL 照合順序に Latin1_General が使用されている場合、エージェント名には、西ヨーロッパ言語の文字セット (Windows コードページ 1252) で記述される任意の言語を含めることができます。これらの方法には、アフリカーンス語、バスク カタロニア、グルジア語、インドネシア語、アイルランド語、およびマレー語が含まれています。SQL 照合の Cyrillic_general を使用する場合、エージェント名にはキリル言語 (Windows コード ページ 1251) で記述される任意の言語を含めることができます。これには、ブルガリア語、キルギス語、モンゴル語、ウズベク語、セルビア語、およびウクライナ語が含まれます。

Finesse デスクトップのローカライズの詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-user-guide-list.htmlの を参照してください。

多言語のサポート

音声ブラウザおよびメディア リソース制御プロトコル（MRCP）の仕様では、複数の言語のサポートには制限がありません。ただし、展開された自動音声認識（ASR）または TTS サーバには制限がある場合があります。複数言語アプリケーションを準備する前に、言語のサポートについて ASR または TTS ベンダーに問い合わせてください。

VXML スクリプトの cisco property com.cisco.asr-server コマンドを使用して、ASRサーバの値をダイナミックに変更することができます。このプロパティにより、VXML スクリプトで前に設定された値がオーバーライドされます。同様に、VXML スクリプトで TTS サーバを cisco property com.cisco.tts-server コマンドで変更することもできます。

Chapter 4. リファレンス設計の設定制限および機能の可用性

- リファレンス設計の構成上の制限

- リファレンス設計で利用可能な機能

リファレンス設計の構成上の制限

Note

このドキュメントの最初の 4 章は、3 つの Contact Center Enterprise ソリューションの詳細を確認したいユーザ向けです。

- Packaged Contact Center Enterprise

- Cisco Hosted Collaboration Solution for Contact Center

- Unified Contact Center Enterprise

Unified CCE に特化した設計上の考慮事項およびガイドラインに関する情報は、残りの章を参照してください。

次の表は、Contact Center Enterprise リファレンス設計 ソリューションの主要な構成に対する制限を示しています。

これらの制限の一部は相互に関連しており、ソリューションの要素に応じて動的に変化します。たとえば、エージェントごとのスキルの数はエージェントの最大数に影響します。

「PG ごと」と表示されている制限は、常に PG の冗長ペアを示しています。

Important

Contact Center Enterprise ソリューションでは、標準の 3 つの共存画面レイアウトで、より高レベルの設定制限のみを使用することができます。

- エージェントに関する制限

- スーパーバイザおよびレポート ユーザの制限

- アクセス コントロールの制限

- アウトバウンド キャンペーンの制限

- プレシジョン キューおよびスキル グループの制限

- タスク ルーティングの制限

- ダイヤル番号の制限

- システム負荷の制限

- コール変数の制限

- その他の制限

Related Information

リファレンス設計のサイズおよび動作の条件

エージェントに関する制限

Note

Contact Director 列のデータは、Contact Director に設定される内容を示しています。Contact Director の接続先のターゲット システムに設定される内容は含まれていません。

エージェントに関する制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

アクティブなエージェント[1]

2000

4000

12,000

24000

24,000 (3 ターゲット システム上の累積)

各 Unified CM クラスタ上のアクティブなエージェント

2000

4000

8000

8000

NA

設定済みエージェント

12,000

24000

72,000

72,000

NA

PG ごとに構成されたエージェント

12000

12000

12000

12000

NA

TraceON が有効になっているエージェント

100

100

400

400

NA

エージェント デスク設定

2000

4000

12,000

12,000

NA

エージェント PG ごとの有効なモバイルエージェント[2]

2000（固定接続）

または

800（コールバイコール接続）

2000（固定接続）

または

800（コールバイコール接続）

2000（固定接続）

または

800（コールバイコール接続）

2000（固定接続）

または

800（コールバイコール接続）

NA

アクティブな ECE マルチメディア エージェント

1500[3]

4000[4]

12,000[5]

24,000[6]

NA

チームごとのエージェント

50

50

50

50

NA

エージェントが所属できるチーム

1

1

1

1

該当なし

エージェントごとのスキル

15

詳細については、動的サイジングに関する項を参照してください。

15

詳細については、動的サイジングに関する項を参照してください。

15

詳細については、動的サイジングに関する項を参照してください。

10

詳細については、動的サイジングに関する項を参照してください。

NA

スキル グループ内のエージェントの数

12,000

24000

72,000

72,000

NA

エージェントごとの属性

50

50

50

50

該当なし

[1] アウトバウンド エージェントおよびマルチチャネル エージェントが含まれます。ただし、占有できるエージェントの数は、アウトバウンド オプション ダイヤラとCustomer Collaboration Platformの制限に基づきます。

[2] 平均処理時間が 3 分未満の場合、またはエージェントグリーティングまたはウィスパーアナウンスメント機能がモバイルエージェントと併用されている場合は、固定接続で1500。

[3] ECE が共存する場合、制限は 400 エージェントとなります。1500 の制限は、ECE が別のサーバにある場合に適用されます。

[4] この制限は、複数の ECE クラスタが必要です。各エージェント PG は、400 エージェントを共存させるクラスタまたは別のサーバ上の 1500 エージェント クラスタのいずれかをサポートすることができます。

[5] この制限は、複数の ECE クラスタが必要です。各エージェント PG は、400 エージェントを共存させるクラスタまたは別のサーバ上の 1500 エージェント クラスタのいずれかをサポートできます。

[6] この制限は、複数の ECE クラスタが必要です。各エージェント PG は、400 エージェントを共存させるクラスタまたは別のサーバ上の 1500 エージェント クラスタのいずれかをサポートできます。

スーパーバイザおよびレポート ユーザの制限

スーパーバイザおよびレポート ユーザの制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

Unified CCE 24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

アクティブなスーパーバイザ[1]

200

400

1200

2400[2]

NA

設定されたスーパバイザ数

1200

2400

7200

7200

NA

アクティブなチーム数

200

400

1200

2400

NA

設定されたチーム数

1200

2400

7200

7200

NA

チームごとのスーパーバイザ

20

20

20

20

該当なし

スーパーバイザ 1 人あたりのチーム数

20

20

20

20

該当なし

スーパーバイザ 1 人あたりのエージェント数

1000

1000

1000

1000

NA

Cisco Unified Intelligence Center のアクティブ レポーティング ユーザ数

200

400

1200[3]

1200[4]

NA

設定された Cisco Unified Intelligence Center レポーティング ユーザ数

1200

2400

7200

7200

NA

CUIC ノードごとのレポートユーザ

100

200

200

200

該当なし

[1] スーパーバイザのスーパーバイザは、エージェントの制限によってカウントされます。アクティブなエージェントの 10% をスーパーバイザにすることができます。

[2] アクティブ レポート ユーザは 1200人までとなるため、すべてのアクティブ スーパーバイザが Cisco Unified Intelligence Centerレポートを同時に使用することはできません。

[3] 中央コントローラのフェールオーバー中は、両サイドが再度アクティブになるまで、この制限が 600 に低下します。

[4] 中央コントローラのフェールオーバー中は、両サイドが再度アクティブになるまで、この制限が 600 に低下します。

アクセス コントロールの制限

アクセス コントロールの制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

ディストリビュータ毎のアクティブな管理者数[1]

50

50

50

50

50

設定された Web 管理者数

100

100

100

100

NA

役割: Packaged CCE のみ

30

30

30

該当なし

該当なし

部門: Packaged CCE のみ

200

200[2]

200

該当なし

該当なし

管理者あたりの部門数: Packaged CCE のみ

10

10

10

該当なし

該当なし

インベントリ内のマシン数

1000

1000

1000

1000

該当なし

[1] Packaged CCE、CCMP、および CCDM は Web 管理を使用するため、この制限は適用されません。

[2] 部門の制限は、Cisco HCS for Contact Center小規模なコンタクト センター ソリューションにも適用されます。

アウトバウンド キャンペーンの制限

アウトバウンド キャンペーンの制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

システムあたりのアウトバウンド ダイヤラ数

エージェントの PG 毎に 1 つの PG

エージェントの PG 毎に 1 つの PG

エージェントの PG 毎に 1 つの PG

エージェントの PG 毎に 1 つの PG

NA

アウトバウンド ダイヤラの最大コール数 / 秒

60

120

240

240

NA

ダイヤラ毎の 1 秒あたりのアウトバウンド ダイヤラの最大コール数[1]

60

60

60

60

NA

SIP ダイヤラ毎の発信ダイヤラ最大ポート数

3000

3000

3000

3000

NA

各システム上のアウトバウンド ダイヤラ最大ポート数 (合計)

3000

6000

12000

12000

NA

システムごとのプレビューキャンペーン数

1500 キャンペーン

プレビューおよびダイレクトプレビューモードは、中規模 PG VM には 750 のキャンペーンスキルグループまで、大規模 PG VM には 1500 までのキャンペーンスキルグループに対応しています。

1500 キャンペーン

プレビューおよびダイレクトプレビューモードは、中規模 PG VM には 750 のキャンペーンスキルグループまで、大規模 PG VM には 1500 までのキャンペーンスキルグループに対応しています。

1500 キャンペーン

プレビューおよびダイレクトプレビューモードは、中規模 PG VM には 750 のキャンペーンスキルグループまで、大規模 PG VM には 1500 までのキャンペーンスキルグループに対応しています。

1500 キャンペーン

プレビューおよびダイレクトプレビューモードは、中規模 PG VM には 750 のキャンペーンスキルグループまで、大規模 PG VM には 1500 までのキャンペーンスキルグループに対応しています。

NA

システムあたりの予測キャンペーン数（エージェントまたは VRU ベース）

375

750

1500

1500

キャンペーン毎のキャンペーン スキル グループ数

20

20

20

20

該当なし

周辺機器ごとの予想キャンペーンスキルグループ

375

375

375

375

NA

エージェントあたりの最大アウトバウンド スキル数

5

5

5

5

NA

インポートあたりの着信拒否レコード数

1,000,000

20,000,000

60,000,000 件

60,000,000 件

該当なし

[1] この値は、VRU またはエージェントへの 30％ の転送速度を想定しています。

プレシジョン キューおよびスキル グループの制限

Note

各プレシジョン キューにはスキル グループが関連付けられています。各プレシジョン キューには、2 つのスキル グループの重みが効果的に設定されます。

プレシジョン キューおよびスキル グループに関する制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

システムごとのスキル グループ

16,000 [1]

16,000

27,000

48,000

54,000

エンタープライズ スキル グループ

4000

4000

4000

4000

4000

周辺機器ごとの設定済みスキル グループとプレシジョン キューの組み合わせの最大数

4000

4000

4000

4000

該当なし

システムごとの設定済みプレシジョン キュー

4000

[2]

4000

[3]

以下の小さい方。

4000

または

27,000 をエージェント周辺機器数で割った値

以下の小さい方。

4000

または

48,000 をエージェント周辺機器数で割った値

最大 54000 キューの内 8,000

プレシジョン キュー手順

10,000

10,000

10,000

10,000

NA

プレシジョン キューごとのプレシジョン キュー期間

10

10

10

10

NA

プレシジョン キューごとのプレシジョン ステップ

10

10

10

10

NA

プレシジョン キューごとの一意の属性

10

10

10

10

NA

チームごとの独自スキルの最大数

50

50

50

50

NA

設定済みラベル

100,000

100,000

160,000

160,000

160,000

各システム上のプレシジョン ルーティング属性

10,000

10,000

10,000

10,000

NA

各エージェントのプレシジョン ルーティング属性

50

50

50

50

NA

スキル グループ統計情報の更新間隔

10 秒（デフォルト）

10 秒（デフォルト）

10 秒（デフォルト）

10 秒（デフォルト）

NA

PG ごとのスキル グループ

4000

4000

4000

4000

該当なし

キュー[4]、連絡先共有グループ毎のスキル グループとプレシジョン キューの両方が含まれます。

該当なし

該当なし

該当なし

該当なし

100

連絡先の共有ルール

該当なし

該当なし

該当なし

該当なし

100

連絡先の共有グループ

該当なし

該当なし

該当なし

該当なし

1000

[1] ほとんどの Packaged CCE 2000 エージェントトポロジでは、エージェント PGが 1 つであるため、保有できるスキル グループは4,000個までとなります。グローバル トポロジでは リモート サイトを使用して、Packaged CCE がシステム全体で 16,000 のスキル グループをサポートします。エージェント PG を配置する 各 リモート サイト は、4,000 のスキル グループを追加します。最大 16,000 には、 3 リモート サイトを必要とします。

[2] 非リファレンス設計の導入（CCE リファレンス 設計でサポートされているよりも多くのエージェント PG を使用する場合）では、この公式を使用してシステムごとのポスト コール調査の最大数（4000 または 27000 未満/エージェント PG の総数）を計算します。

[3] 非リファレンス設計の導入（CCE リファレンス 設計でサポートされているよりも多くのエージェント PG を使用する場合）では、この公式を使用してシステムごとのポスト コール調査の最大数（4000 または 27000 未満/エージェント PG の総数）を計算します。

[4] この用語には

タスク ルーティングの制限

タスク ルーティングの制限

リソース

2000 エージェント リファレンス設計

4000 エージェント リファレンス設計

12000 エージェント リファレンス設計

24000 エージェント リファレンス設計

Contact Director リファレンス設計

システムあたりのタスクに割り当てられるアクティブなエージェントの最大数

2000

2000

2000

2000

NA

エージェント毎の最大予約タスクおよびアクティブ タスク数[1]

15

15

15

15

NA

すべての MRD での最大着信タスク/秒は[2]

5

5

5

5

NA

1 時間あたりのタスクルーティング API リクエストCustomer Collaboration Platform

15,000

15,000

15,000

15,000

該当なし

[1] この数には、一時停止および中断されたタスクが含まれています。キュー内のタスク、またはエージェントによって転送されていないタスクは、この制限数には含まれません。

[2] Customer Collaboration Platform、UnifiedCCEへのタスク送信レートを 1 秒あたり 5 タスクに抑制します。Customer Collaboration Platform は、送信のキューで最大 10,000 タスクを保持します。キューが 1 万タスクを超えると、Customer Collaboration Platform は、廃棄コード NOTIFICATION_RATE_LIMITED で、追加タスクを破棄します。キューが再度対応可能になると、追加のタスクがキューに追加されます。

ダイヤル番号の制限

Note

グローバルトポロジでは、各 リモート サイト 機能は、表に記載されているダイヤル番号の制限をすべてサポートしています。

ダイヤル番号の制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

各 CVP 周辺機器のダイヤル番号 (外部音声および ) [1]

4000

12,000

12,000

12,000

各 Unified CM 周辺機器のダイヤル番号 (内部音声)

2000

2000

2000

2000

NA

各 MR 周辺機器 (マルチチャンネル) 上のダイヤル番号

1000

1000

1000

1000

NA

各 Unified CM 周辺機器のダイヤル番号 (アウトバウンド音声)

1000

1000

1000

1000

該当なし

[1] すべてのルーティング クライアント タイプで、システムの最大合計 240,000 件の DN レコード件数を超えることはできません。

システム負荷の制限

システム負荷の制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

リファレンス レイアウトの VRU ポート数[1]  [2]

3000

6000

18,000

36,000

36,000

PG が追加された最大 VRU ポート数[3]

6000

12,000

36,000

48,000

72,000

毎秒着信コールの最大数 (CPS)

15

30

90

90

300 のうち、連絡先共有は 120 が処理可能で、残りはセルフサービスおよび基幹業務の直接ルーティング用です。

輻輳制御のCPS[4]

18

35

105

105

300

エクスペリエンス管理調査 CPS

1.5

3.5

10

30

該当なし

VRU PG あたりの最大インバウンド CPS [5]

15

15

15

15

NA

VRU PG あたりの最大 VRU PIM

2

2

2

2

該当なし

ダイナミックな処理 (毎時操作数)

7200

7200

7200

7200

NA

最大キュー内コールおよびタスク数

15,000

15,000

15,000

15,000 [6]

15,000

システム毎メディア ルーティング ドメイン数

20

20

20

20

該当なし

Customer Collaboration Platform(requests/hr.）を介したエージェント コールバック リクエスト

1000

1000

1000

1000

NA

ECE 400 人のエージェントを展開の E メールまたはチャット毎時要求数

エージェントあたり 6

エージェントあたり 6

エージェントあたり 6

エージェントあたり 6

NA

ECE1500 エージェントを展開する場合の 1 時間あたりの電子メールまたはチャットリクエスト[7] の「企業チャットおよび電子メール設計上の考慮事項ガイド」を参照してください。

エージェントあたり 6

エージェントあたり 6

エージェントあたり 6

エージェントあたり 6

NA

CVP レポート サーバの 1 秒あたりの受信メッセージ数

420

420

420

420

420

ユーザ毎のレポート数

2 ライブ データ レポート

2 AW リアルタイム レポート

2 履歴レポート

2 ライブ データ レポート

2 AW リアルタイム レポート

2 履歴レポート

2 ライブ データ レポート

2 AW リアルタイム レポート

2 履歴レポート

2 ライブ データ レポート

2 AW リアルタイム レポート

2 履歴レポート

NA

レポートあたりの行数

リアル タイム レポートで 3000

履歴レポートで 8000

リアル タイム レポートで 3000

履歴レポートで 8000

リアル タイム レポートで 3000

履歴レポートで 8000

リアル タイム レポートで 3000

履歴レポートで 8000

NA

設定された業務時間オブジェクト[8]

1000

1000

1000

1000

1000

業務時間オブジェクト毎の設定スケジュールオブジェクト数[9]

50

50

50

50

50

[1] この値は、ソリューションに同数の冗長ポートがあることを前提としています。実際のポート数は、この数字の 2 倍です。

[2] 各リファレンス設計モデルの基本レイアウトのエージェントまたは VXML サーバでの合計コール数。グローバル展開に追加されたコンポーネントにより、これらの数は増大します。

[3] この値は、ソリューションに同数の冗長ポートがあることを前提としています。実際のポート数は、この数字の 2 倍です。

[4] 毎秒インバウンド コール数は、エージェントの 10％ がコールに直接応答しないスーパーバイザであると想定しています。この値は、10% の転送および 5% の会議コールの分布も仮定しています。

[5] CVP コールサーバの 1 つがダウンした場合、VRU PIM あたりの最大インバウンド CPS は、15 です。

[6] これは、ICM\<inst>\Router[A/B]\Router\CurrentVersion\Configuration\Queuing\MaxCalls のレジストリ 設定で変更を行うことで、27,000 まで増やすことが可能です。

[7] 電子メールおよびチャットサイジングの考慮事項に関しては、https://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/products-implementation-design-guides-list.html.

[8] Cisco HCS for Contact Center は、業務時間機能をサポートしません。

[9] これらのスケジュール オブジェクトのうち 7 つが日次スケジュールで使用されます。残りは休日および例外に使用することができます。

コール変数の制限

コール変数の制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

永続的に有効な拡張コール変数 (デフォルト)[1]

5

5

5

5

5

永続的に有効な拡張コール変数配列

0

0

0

0

0

ECC あたりの最大コンテンツ (拡張コール コンテキスト) 変数 (バイト数)

210

210

210

210

210

ECC ペイロード毎 の最大合計 ECC コンテンツ サイズ (バイト数)

2000

2000

2000

2000

2000

ECC 変数名の最大値 (null 文字を含まないバイト数)

32

32

32

32

32

ECC ペイロードあたり の ECC 変数の最大合計コンテンツおよび名前サイズ (バイト数)

2500

2500

2500

2500

2500

コール毎の ECC 変数の最大コンテンツ (バイト数)

6000

6000

6000

6000

6000

システム全体の最大 ECC 変数コンテンツ (バイト数)[2]

90,000,000

90,000,000

90,000,000

90,000,000

NA

周辺機器変数

10

10

10

10

10

周辺変数 1 ～ 10 のコール コンテキスト (バイト数)

40

40

40

40

40

[1] 詳細については、「コール コンテキスト」セクションを参照してください。

[2] この制限は、コール毎の最大制限に、システムの最大キュー内コール数およびタスク数を掛けたものです。

その他の制限

その他の制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

24000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

ライブデータ、ポスト コール調査またはシングルサインオンが有効な最大エージェント PG は、[1]

4[2]

4 [3]

12

24 (追加の大規模ライブ データ OVA を使用している場合)

24

50

最大 PG [4]

30

100

150

150

NA

各 VM の最大エージェント PG 数

1

1

1

1

該当なし

各 PG ペアの Cisco Finesse server の最大ペア数

1

1

1

1

該当なし

各 MR PIM 上の MR PG 数

4

4

4

4

NA

カスタム アプリケーション ゲートウェイ

20

20

20

20

エンタープライズ システムあたり 20

バケット間隔

2000

4000

12,000

12,000

NA

設定されたコール タイプ数

4000

8000

15,000

15,000

15,000

間隔毎のコール タイプ スキル グループ数[5]

70,000

70,000

70,000

70,000

NA

アクティブ ルーティング スクリプト数

1000

2,000

6000

6000

6000

設定されているルーティング スクリプト数

2000

4000

12,000

12,000

12,000

ネットワーク VRU スクリプト

2000

4000

12,000

12,000

12,000

システム全体で設定された理由コードおよびラベルの最大数

2800 および 21 のシステム定義

3800 および 21 のシステム定義

7800 および 21 のシステム定義

7800 および 21 のシステム定義

NA

待受停止理由コード

100 グローバル コード

100 の各チームの関連理由コード

100 グローバル コード

100 の各チームの関連理由コード

100 グローバル コード

100 の各チームの関連理由コード

100 グローバル コード

100 の各チームの関連理由コード

NA

ログアウト理由コード

100 グローバル コード

100 の各チームの関連理由コード

100 グローバル コード

100 の各チームの関連理由コード

100 グローバル コード

100 の各チームの関連理由コード

100 グローバル コード

100 の各チームの関連理由コード

NA

後処理理由ラベル[6]

100 グローバル ラベル

1500 チーム ラベル

100 グローバル ラベル

1500 チーム ラベル

100 グローバル ラベル

1500 チーム ラベル

100 グローバル ラベル

1500 チーム ラベル

NA

管理バルク ジョブ[7]

200

200

200

200

NA

Cti AllEventClients[8]

7 / 中規模 PG

20 / 大規模 PG[9]

7 / 中規模 PG

20 / 大規模 PG[10]

7 / 中規模 PG

20 / 大規模 PG[11]

7 / 中規模 PG

20 / 大規模 PG

NA

リアルタイムのみのディストリビューター (設定のみ)

4 (各サイドに 2 つ)

4 (各サイドに 2 つ)

10 (各サイドに 5 つ)

10 (各サイドに 5 つ)

10 (各サイドに 5 つ)

エージェント対象ルール（ATR）

1000

1000

1000

1000

NA

[1] 各 VM に 1 つのエージェント PG、1 つの VRU PG、および 1 つの MR PG のみを展開します。CTI すべてのイベントのクライアントの必要性に応じて、中規模 PG OVA または 大規模 PG OVA を使用します。

[2] Packaged CCE 2000 エージェントでは、1 つのエージェント PG、1 VRU PG、および 1 MR PG のみを使用することができます。 3 つの リモート サイトグローバル トポロジを使用している場合は、最大 4 つまで拡張可能です。

[3] 単一の Cisco HCS for Contact Center 小規模なコンタクト センターソリューションでは、SSO を有効にした 50 PG をサポートすることができます。ただし、プレシジョン キューおよびライブ データが有効化されている場合には、12 PG のみがサポートされます。

[4] PG の最大数には、最大エージェント PG 数（前の行で指定）が含まれます。

[5] この制限を超過すると、レポートでギャップが発生します。

[6] 各チームは、合計 100 個を超えるチーム後処理理由ラベルを使用することはできません。

[7] これには、SSO 移行ツールおよび Packaged CCE バルク ツールが含まれます。従来のバルク設定ツールに適用されます。

[8] CTI AllEventClients 制限には、Cisco Finesse、エンタープライズ チャットおよび E メール、およびアウトバウンド ダイヤラ接続が含まれます。この制限は、CTI OS デスクトップには適用されません。

[9] 大規模 PG OVA を使用しない Packaged CCE には適用されません。

[10] 大規模 PG OVA を使用しない Packaged CCE には適用されません。

[11] 大規模 PG OVA を使用しない Packaged CCE には適用されません。

リファレンス設計で利用可能な機能

以下の項では、Contact Center Enterprise リファレンス設計 に準拠するコンタクト センター ソリューションで利用可能な機能について概要を説明します。

- エージェントおよびスーパーバイザ

- 音声およびインフラストラクチャ

- IP フォン サポート

- 管理インターフェイス

- VRU およびキューイング

- レポート

- サードパーティ統合

エージェントおよびスーパーバイザ

機能

対応

注記

コール フロー

CVP 毎のポストルート

包括コール フロー:

- インバウンドおよびアウトバウンドコール

- 補足サービス

- 保留と復帰

- ブラインド、打診、およびリファレンス転送と会議

- ルータ再クエリ

上記その他のコール フローは、非リファレンス設計ソリューションでのみ使用することができます。

- コール フローの事前ルーティング

- 変換ルート

- Unified CVP VXML サーバ (スタンドアロン): Unified ICM を伴わないセルフサービス

- Call Director: IP スイッチング

- VRU のみ: VRU、PSTNエンドポイントの切り替え

アウトバウンド キャンペーン

Cisco アウトバウンド オプションでは、以下のダイヤル モードがサポートされています。

- プレディクティブ

- Preview

- ダイレクト プレビュー

- プログレッシブ

SIP ダイヤラは、SIP の UDP 転送プロトコルを使用します。

Mobile Agent

Nailed およびコールバイコール モード

サイレント モニタリング

Unified CM ベース (BIB)

Unified CM ベースのサイレント モニタリングを使用してモバイル エージェントを監視することはできません。

録音

Unified CM-based

ネットワーク ベースの録音

CUBE (E) ベース

TDM ゲートウェイ ベース

CRM の統合

CRM 統合は、Cisco Finesse Web API、Finesse ガジェット、および既存の CRM コネクタを介して利用することができます。

以下の方法を使用して CRM と統合することができます。

- Finesse コンテナの CRM iFrame。この方法はシンプルかつ簡単ですが、詳細 CRM との詳細な統合は実現しません。

- Finesse コンテナのサードパーティ ガジェット。この方法は完全な CRM 統合を実現しますが、サードパーティおよび Finesse API を使用したカスタム開発が必要になります。

- CRM ブラウザ ベースのデスクトップの Finesse ガジェット。この方法は CRM アプリケーションに軽量の統合を実現します。

- CRM アプリケーションに統合する Finesse Web API またはCTI サーバ プロトコル。この方法は CRM 統合を実現しますが、カスタム開発が必要になります。

デスクトップ

Cisco Finesse

Finesse IP フォンエージェント

FIPPA では、Finesse の機能のサブセットのみがサポートされます。

デスクトップのカスタマイズ

Cisco Finesse API

Avaya PG または親/子トポロジを使用する非リファレンス設計のみが CTI OS デスクトップを使用できます。Cisco Finesse は、他のすべての Contact Center Enterprise ソリューションで必要なデスクトップです。

音声およびインフラストラクチャ

機能

対応

注記

保留音

Unified CM サブスクライバまたは音声ゲートウェイを使用したユニキャスト

音声ゲートウェイを使用したマルチキャスト

「Unified CM サブスクライバ ソースを使用したマルチキャストのみ」は、非リファレンス設計でのみサポートされます。

プロキシまたは Cisco Unified SIP プロキシ（CUSP）

SIP プロキシはオプションのコンポーネントです。

CUSP を使用する代わりに、以下のソリューション コンポーネントを使用して高可用性（HA）および負荷分散を実現する展開も可能です。

- 高可用性を実現するための時分割多重（TDM）ゲートウェイおよび Unified Communications Manager。

- 高可用性とロード バランシングを実行するために SIP サーバ グループおよび SIP オプションのハート ビート メカニズムを使用する Unified CVP サーバ。

- アウトバウンド オプション。SIP プロキシが使用されていない場合、アウトバウンド ダイヤラは 1 つの物理ゲートウェイにしか接続できません。

イングレス ゲートウェイ

使用するソリューションの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html の 互換性マトリクス を参照してください。

プロトコル

伝送制御プロトコル（TCP）を介した SIP（Session Initiation Protocol; セッション開始プロトコル）

出力音声ゲートウェイへのアウトバウンド オプション SIP ダイヤラの User Datagram Protocol（UDP）を介した Session Initiation Protocol（SIP）それ以降のエンド ポイントへの転送では必ず SIP TCP を使用する必要があります。

SIP シグナリングへの SIP の固定

Contact Center Enterprise ソリューションでは、H.323 はサポートされません。

SIP over Media Gateway Control Protocol（MGCP）が使用できるのは、非レファレンス設計でのみです。SIP over UDP は、発信ダイヤラに対してのみ使用できます。

アウトバウンド オプション SIP ダイヤラからエグレス ゲートウェイまでは、UDP を使用する必要があります。

Codec

VRU 用：G.711 mu-law および G.711 A-law

音声エージェント用：G.711 mu-law、G.711 A-law、G.729、および G.729a

音声用：

- ビデオ トラック: H.264

Contact Center Enterprise ソリューションは iSAC または iLBC をサポートしていません。

モバイル エージェント用の混在コーデックリモート ポートおよびローカル ポートは同じコーデックを使用する必要があります。

CVP プロンプト用の混在コーデック。CVP プロンプトはすべて同じコーデックを使用する必要があります。

メディア リソース

ゲートウェイまたは Unified CM ベース:

- カンファレンス ブリッジ

- トランスコーダおよびユニバーサル トランスコーダ

- ハードウェアおよび IOS ソフトウェアのメディア ターミネーション ポイント

Unified CM ベースのリソースの場合、この負荷に合わせて Unified CM を適切にサイズ設定します。

IP フォン サポート

サポートされる電話機の一覧の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.htmlの 互換性マトリクス を参照してください。サポートされる電話機では、SIP 回線側で、組み込み型ブリッジ (BIB) のコントロール機能が必要です。

SCCP ベースの回線側プロトコルは、新型の電話機ではサポートされていません。

管理インターフェイス

機能

対応

注記

コア コンポーネントのプロビジョニング

- ゲートウェイ: CLI

- Unified CVP: Web ベースの操作コンソール

- Unified CCE: Web ベースの管理およびシック クライアント設定ツール

- Unified CCE ソリューション向け Unified CCMP、Contact Center 版 Cisco Hosted Collaboration Solution ソリューション向け Unified CCDM。

- Cisco VVB: Web ベースの操作コンソール

- Unified CM: Web ベースの管理

- Cisco Finesse: Web ベースの管理

- Unified Intelligence Center: Webベースの管理

Packaged CCE では、プロビジョニングに CCMP または CCDM をサポートされません。

サービス作成環境

Unified CCE インターネット スクリプト エディタ

Unified CCE スクリプト エディタ

CVP Call Studio

サービスアビリティ

Cisco Prime Collaboration Assurance

Unified System コマンド ライン インターフェイス（CLI）

RTMT 分析マネージャの診断

SNMP

syslog

Contact Center Enterprise ソリューションは、RTMT 分析マネージャによるコール パス分析をサポートしていません。

Finesse は、ログ収集のみを目的に RTMT をサポートしています。

VRU およびキューイング

以下の表は、インバウンド コール管理を最適化する VRU 機能およびコール キュー機能を示しています。

機能

対応

注記

音声応答装置（VRU）

Unified CVP 包括的なモデル タイプ 10

以下は、非レファレンス設計でのみサポートされます。

- 他のすべての Unified CVP の VRU タイプ

- Cisco Unified IP IVR

- サードパーティ製 VRU

発信者入力

DTMF：RFC2833

自動音声認識および音声合成（ASR/TTS）

ビデオ

CVP およびビデオの基本

キュー内の CVP ビデオ

CVP メディアサーバ

CVP メディア サーバは、サードパーティの Microsoft インターネット インフォメーション サービス (IIS) を使用しています。CVP インストーラは、Unified CVP サーバ上に共存する CVP メディアサーバ を追加します。

レポート

機能

対応

注記

レポート ツール

Cisco Unified Intelligence Center

サードパーティのレポーティング アプリケーション

カスタム レポート

データベース ソース

Unified CCE AW-HDS-DDS

Unified CCE ライブ データ

Unified CVP レポーティング

平均レートが 1 秒あたり 8 コールの一般的な 1000 エージェントの展開の場合、保持期間は約 24 か月です。保持期間を延長する場合は、外部 HDS をインストールします。

導入のニーズのサイズを変更するには、ICMDBA ツールで DB 推定ツールを使用します。

データベース統合

CVP データベース要素

Unified CVP VXML サーバ では、サードパーティの Microsoft SQL サーバ データベースへの接続がサポートされています。

保留

すべての Contact Center Enterprise ソリューションは、AW-HDS-DDS の保持サイズが固定されています。保持サイズを増やすには、外部 HDS-DDS ノードが必要です。ICMDBA ツールの DB 推定ツールを使用して、ソリューションのサイジングおよび顧客維持の要件に基づいて vDisk サイズを計算します。OVA の展開時に AW-HDS-DDS の DB vDisk をカスタムサイズにすることができます。

2000 エージェントのリファレンス設計は最大 4 つまでの外部 HDS を持つことができます。

HDS サイズの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.htmlの使用するソリューションの Cisco Collaboration Virtualization ページを参照してください。

レポートの容量

200 名の Unified Intelligence Center ユーザが、同時に実行します。

- 1 レポートあたり、10 列、100 行の 2 つの リアルタイムレポート。

- それぞれ 10 列、2000 行の 2 つの2 つの 履歴レポート。

- それぞれ 10 列、100 行の 2 つのライブデータレポート。（LD を実行するかどうかは、導入タイプに基づいて調整します）。

これは、Unified CCE と Packageed CCE の両方のソリューションに適用されます。

Note

- クライアント マシンでは 10 以上の同時レポートを実行しないでください。これは、クライアント マシンの Unified Intelligence Center ユーザ インターフェイス、パーマリンク、およびダッシュボードで実行されるレポートの総合的な制限です。

- ただし、各ノードの最大レポート ユーザ 200 人に対して 10 件の同時レポートを実行することはできません。

- ノード上のレポートユーザが少ない場合、相対的にさらに多くのレポートを実行できます。しかし、クライアント マシンは、10 件のレポートの制限を超えることはできません。

また、1 つのリアルタイム XML Permalink と 1 つの履歴 XML Permalink を実行している 30 人のユーザをサポートします。（この結果、1 時間あたり約 7200 件のリアルタイム XML Permalink 実行と 1 時間あたり 60 件の履歴 XML が実行されます）。

リアルタイムレポートのキャパシティは 1 レポートあたり 100 行で、それぞれ 10 列、履歴レポートは 2000 行で、それぞれ 10 列のキャパシティを備えています。

サードパーティ統合

オプション

注

録音

録音方法:

- CUCM ベース (BiB)

- ネットワーク ベースの録音

- CUBE フォーキング

必要に応じて、サードパーティの録音サーバと 統合して利用することができます。

ウォールボード

Wallboard を使用すると、リアルタイムで顧客へのサービスを監視することができます。Wallboard では、待機中のコール数、待機時間、サービスレベル数など、カスタマー サービス指標に関する情報を確認することができます。

ワークフォース管理

WFM では、複数のコンタクト サービス キュー (CSQ) およびサイトのスケジュール設定が可能です。

単一の WFM 実装を世界規模で展開することができます。

Cisco Solution Plus

サポートされるオプションについては、Cisco Solution Plus プログラムを参照してください。

自動着信呼分配装置（ACD）

リファレンス設計では、サードパーティの ACD を使用することはできません。

Chapter 5. Unified Contact Center Enterprise ソリューション設計上の考慮事項

- コアコンポーネント設計上の考慮事項

- リファレンス設計とトポロジ設計に関する考慮事項

- オプションのシスココンポーネント設計上の考慮事項

- サードパーティ コンポーネント設計上の考慮事項

コアコンポーネント設計上の考慮事項

- 一般的なソリューション要件

- 入力/出力/VXML ゲートウェイの設計上の考慮事項

- CVP 設計上の考慮事項

- Contact Center Enterprise 設計上の考慮事項

- Cisco Virtualized Voice Browser の設計上の考慮事項

- Unified Communications Manager の設計上の考慮事項

- Cisco Finesse の設計上の考慮事項

- Cisco Unified Intelligence Center の設計上の考慮事項

一般的なソリューション要件

- ソリューションのデータバックアップ

- NTP および時刻同期

- Contact Center Enterprise リファレンス設計トポロジの詳細

ソリューションのデータバックアップ

データバックアップツールは、スケジュールされたメンテナンスウィンドウでのみ実行します。ローカル SQL バックアップを使用する場合は、ローカルマシンに十分なキャパシティがあることを確認します。そうでない場合は、ネットワーク上のリモートストレージにバックアップします。

NTP および時刻同期

Contact Center Enterprise ソリューションには、ソリューションのすべての部分に同じ時間が必要です。時間のずれは自然に発生しますが、ソリューション コンポーネントの同期を維持するために NTP を設定することは重要です。ライブデータレポートで時間の差異を回避するため、これら VM での NTP 設定は同期されなければなりません。

- ルータ

- Logger

- Administration & Data Server

- Unified Intelligence Center のパブリッシャとサブスクライバ

Note

Finesse Desktop クライアントマシンは、ライブデータレポート内の [期間（Duration）] フィールドへの正確な更新のため、有効な NTP サーバを使用して、時間を同期する必要があります。

Contact Center Enterprise リファレンス設計トポロジの詳細

- 詳細な 2000 エージェントリファレンス設計

- 詳細な 4000 エージェントリファレンス設計

- 詳細な 12000 エージェントリファレンス設計

- 詳細な 24000 エージェントリファレンス設計

詳細な 2000 エージェントリファレンス設計

次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。

詳細な 2000 エージェントリファレンス設計

詳細な 4000 エージェントリファレンス設計

次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。

詳細な 4000 エージェントリファレンス設計

詳細な 12000 エージェントリファレンス設計

次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。

詳細な 12000 エージェントリファレンス設計

詳細な 24000 エージェントリファレンス設計

24000 エージェントリファレンス設計では、通常の動作条件での論理的な接続は 12000 エージェントリファレンス設計のパターンに従います。ただし、最小 12 台の CVP、PG、および Finesse サーバがあります。

入力/出力/VXML ゲートウェイの設計上の考慮事項

- IOS ゲートウェイの役割

- TDM-IP ゲートウェイ設計に関する検討事項

- Cisco Unified Border Element 設計に関する考慮事項

- VXML ゲートウェイ設計上の考慮事項

- 分散型ゲートウェイ

- Contact Center Enterprise ソリューションのローカルトランク

IOS ゲートウェイの役割

Contact Center Enterprise ソリューションでは、TDM 入力および VXML レンダリングに IOS ゲートウェイが使用されます。通常は、いずれかまたは両方の目的に対して、ソリューションでサポートされている任意の Cisco ゲートウェイを使用できます。次の表は、各機能を使用するコール フローを示しています。

コール フロー別の IOS ゲートウェイ機能の使用

コール フロー

TDM 入力

VXML レンダリング

リファレンス設計

Unified ICM Micro-Apps を使用する包括的コール フロー

可

一部

Unified CVP VXML Server を使用する包括的コール フロー

可

一部

非リファレンス設計

スタンドアロン セルフ サービス

はい

はい

コール ディレクタ

はい

なし

NIC 制御ルーティングのみを使用する VRU

はい

はい

Note

VXML ゲートウェイの代替として Cisco Virtualized Voice Browser を使用できます。

入力および VXML の両方が必要な場合は、同じゲートウェイで両方の機能を実行するか、一部のゲートウェイを入力用に指定し、他のゲートウェイを VXML 用に指定できます。次のガイドラインに従って、機能を結合するか分割するかを判断してください。

- 到着したブランチでコールがキューに格納されるブランチ オフィス展開では、入力機能と VXML 機能を常に結合します。

- 多数の非 CVP PSTN 接続でゲートウェイを共有している場合は、各機能ごとに個別のゲートウェイを使用します。

- VXML のみのゲートウェイは、DSP ファームや TDM カードが不要なためコストが低くなります。

- コール量が少ない場合は、通常、冗長性のために機能を結合します。結合されたゲートウェイのいずれかで障害が発生した場合は、容量を低減して、他のゲートウェイで引き続きコールを処理できます。

次に、Cisco サービス統合型ルータ（ISR）または ISR-G2 ゲートウェイのどちらを使用するかを決定します。

ISR ゲートウェイを使用する従来のブランチ オフィスには以下が含まれます。

- TDM コールが PSTN から到着する複数サイトの 1 つ

- ソリューションの大部分の機器が存在する メイン サイト から分離されたサイト

- 各サイトが 1 つのゲートウェイを使用

Related Concepts

Cisco Virtualized Voice Browser の設計上の考慮事項

TDM-IP ゲートウェイ設計に関する検討事項

さまざまな音声ゲートウェイでサポートされる各種デジタル（T1/E1）およびアナログインターフェイスの最新情報については、次のサイトから入手可能な最新の製品マニュアルを参照してください。

- ルータ—http://www.cisco.com/cisco/web/psa/default.html?mode=prod&level0=268437899

- Unified Communications ゲートウェイ—http://www.cisco.com/cisco/web/psa/default.html?mode=prod&level0=278875240

Cisco Unified Border Element 設計に関する考慮事項

Cisco Unified Border Element（CUBE）は、SIP を使用した IP 音声ネットワーク間の接続を提供する Session Border Controller（SBC）です。ソリューションでは、物理 CUBE または仮想 CUBE を使用することができます。ソリューションは、すべてのコールが CUBE を介してルーティングされるフロースルー モードでのみ CUBE を使用できます。

Note

フロースルー モードとは異なり、フロー アラウンド モードでは、DTMF インターワーキング、トランスコーディング、および電話機やメディア機能などのその他の主要機能を使用することはできません。

TDM 音声回線を電話会社の IP 音声トランクに置き換える場合、ソリューションには CUBE が必要となります。CUBE は、IP 音声トランク上で企業をサービス プロバイダーに接続するための機能境界ポイントとして機能します。

Note

アウトバウンド コールの場合、物理 CUBE はコール進行状況分析（CPA）をサポートします。仮想 CUBE は、CPA をサポートしていません。

テストでは、以下のシナリオで CUBE を使用できることが示されています。

- シスコによって認定済みの SIP トランクを介したサードパーティ製 SIP デバイスと Unified CVP 間の SIP-to-SIP 接続

- Unified CM と Unified CVP 間の SIP-to-SIP 接続

トポロジや設定など、Unified CVP での CUBE の使用に関する詳細については、http://cisco.com/en/US/docs/voice_ip_comm/unified_communications/cubecc.htmlの コール センター ソリューション向けCisco Unified Border Element を参照してください。

Note

各 CUBE がサポートする最大セッション数の一覧については、http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v-series/products-installation-and-configuration-guides-list.htmlの Cisco Unified Border Element コンフィギュレーションガイド を参照してください。

Note

Cisco IOS の制限により、CUBE では、音声からビデオ、およびビデオから音声への通話中のエスカレーションまたはデスカレーションはサポートされません。

Note

現在、CVP は SIP メッセージの Allowed-Methods を確認しません。その結果、アウトバウンドは UPDATE メソッドをサポートしていませんが、UPDATE メッセージをイングレスからアウトバウンド レッグに渡します。

回避策: UPDATE メッセージをイングレス レッグの SBC で無効にします。

CUBE 展開の制限

SIP トランクで CUBE を展開する場合は、以下の制限を遵守してください。

- Unified CVP 展開で、ダイヤル ピアのデフォルト モードであるメディア パススルー モードで CUBE を設定します。メディア フロー アラウンド モードは、Webex エクスペリエンス管理のみでサポートされています。

- CUBE は、REFER コール フローの開始時に CVP からの Refer-To ヘッダー URI 宛先の受け渡しをサポートしていません。CUBE によって、ダイヤル ピア コンフィギュレーションに基づいて宛先アドレスが書き換えられます。そのため、ダイヤル プランは CVP および CUBE で設定する必要があります。

- REFER パススルーを耐障害性で使用することはできません。スクリプトは、他の CUBE の設定に関係なく、REFER メッセージが SIP サービス プロバイダーにリレー送信されないようにします。

- 耐障害性およびルータ再クエリでは REFER 消費を使用できません。存続可能性は、転送が完了していない場合でも、常に REFER を受け入れます。Unified CCE は、転送が成功したと見なし、再クエリーしようとしません。

- サービス プロバイダーの代替宛先ルーティング（ADR）で耐障害性を使用することはできません。スクリプトの処理では、エラー メッセージ（Ring-No-Answer またはビジー）がサービス プロバイダーに到達しないようにします。代わりに、Remote-Party-ID ヘッダの処理が必要となります。

- GTD が着信コール中であるか、または Unified CCE が UUI 変数の値を設定する場合、Unified CVP は DTMF 転送でディジットをアウトパルスした直後に BYE を送信します。数字の間に遅延が必要な場合は、ラベルの最後にコンマを使用します。

- 着信コールに GTD が存在しない場合、Unified CCE は UUI 変数の値を設定しません。次に、サービス プロバイダーは、DTMF 転送で数字を受信した後、コールを切断しません。Unified CVP は SIP.ExternalTransferWait タイマーの期限が切れた後、BYE 要求を送信します。

- サービス コールバックを使用したソリューションには、耐障害性が必要です。

Note

コール耐障害性はCUBE HAモードでサポートされますが、以下の制限があります。

- CVP に登録されたサービス コールバック（CCB）がある場合、ポスト スイッチ オーバー CCB はサポートされません。

- コール存続可能性 TCL スクリプトのみ CUBE 高可用性でサポートされます。他の TCL ベースのサービスはサポートされません。

- アクティブ コールのみがチェック ポイントされます。（接続しているコール：200OK/ACK トランザクション完了）。遷移状態のコールはチェック ポイントされません。

- Unified Border Element としての Cisco ASR 1000 シリーズ

- Unified Border Element としての Cisco ISR

Related Concepts

Cisco Unified Border Element

コンタクト センター ソリューション向け仮想 CUBE

Unified Border Element としての Cisco ASR 1000 シリーズ

Unified CVP は、次の制限がある Cisco IOS XE ソフトウェアをサポートします。

- ASR 1000 シリーズゲートウェイは VXML をサポートしません。そのため、コールの VRU レグを別の VXML ゲートウェイにルートします。コールバックの VRU レグを 発信元の ASR CUBE ゲートウェイにルートするために [発信者に送信（Send To Originator）] 設定を CVP コールサーバに使用しないでください。スタンドアロン CVP コールを別の VXML ゲートウェイにルートします。

- Unified CVP は 、ASR 1000 シリーズ ゲートウェイ上のグローバル Pass Thru SDP 設定をサポートしません。

- メディアフロースルーではなく、メディア フロー アラウンドの CUBE として ASR を構成する場合、サービス コールバック コール フローは機能しません。

- 通常、セッション ボーダー コントローラの背後にプロキシサーバを配置します。プロキシが ASR セッション ボーダー コントローラの正面にある場合は、プロキシサーバを使用して、大きなパケット SIP メッセージを受信するときに UDP から TCP アップ変換を実行します。この場合は、プロキシサーバの電源をオフにし、着信コールの接続に UDP トランスポートを使用することを確実にします。

- ASR では、次の Survivability.tcl オプションを使用することはできません。これらのオプションは、従来 POTS ダイヤルピア向けです。

- ani-dnis-split.

- takeback-method.

- -- *8.

- -- hf.

- icm-tbct.

- digital-fxo.

- 次の Survivability.tcl オプションは、サポートされていません。

- aa-name — ASR が、CME 自動アテンドサービスをサポートしていないため、このオプションもサポートされていません。

- standalone — ASR が VXML をサポートしていないため、このオプションもサポートされていません。

- standalone-isntime — ASR が VXML をサポートしていないため、このオプションもサポートされていません。

- ASR の制限のため、次の機能はサポートされません。

- 再クエリで参照

- DTMF *8 ラベルを使用したレガシー転送接続

- ASR 1000 は、TDM トランクを終端しません。したがって、次の TDM ゲートウェイ機能は ASR 1000 に適用されません。

- SIP コールから Unified CCE に関するPSTN ゲートウェイトランクおよび DS0 情報

- SIP OPTIONS メッセージから Unified CCE を介した DS0 トランクリソースのリソースの可用性インジケータ（RAI）

Note

ソリューションが ASR 1000 シリーズゲートウェイを使用している場合は、品質評価（A2Q）レビューが必要です。このレビューは、Contact Center Enterprise ソリューション、ASR 1000 にアップグレードする既存のソリューションが対象です。

Unified Border Element としての Cisco ISR

Unified CVP が ISR をサポートするには次の制限があります。

- CUBE がメディアル フローアラウンド用に構成されているため、サービス コールバック コール フローは ISR では機能しません。代わりに、メディア フロースルー用に構成します。

VXML ゲートウェイ設計上の考慮事項

Note

VXML ゲートウェイの代替として Cisco Virtualized Voice Browser を使用できます。

- DTMF または ASR/TTS を使用する VXML ゲートウェイ

- VXML Over HTTP

DTMF または ASR/TTS を使用する VXML ゲートウェイ

VXML ゲートウェイを使用すると、カスタマーは DTMF トーンまたは ASR/TTS を介して VXML ブラウザと対話できます。ゲートウェイには PSTN インターフェイスが存在しないので、音声トラフィックは、Real-time Transport Protocol（RTP）を使用して VXML ゲートウェイに送信されます。RFC 2833 は、RTP パケット内でインバンドシグナリングを使用し、DTMF トーンを送信します。DTMF または ASR および TTS を使用する VXML を使用すると、展開の規模を拡大し、数百の VXML セッションをサポートできます。

ブランチオフィストポロジでは、別の PSTN ゲートウェイと VXML ゲートウェイを展開して、冗長性の追加レイヤーを提供し、さらにブランチフィスに Survivable Remote Site Telephony（SRST）のサポートを提供します。

VXML Over HTTP

VXML サーバと音声ブラウザは、VXML over HTTP を使用した要求―応答周期で通信します。Uniform Resource 識別子（URI）は、VXML ドキュメントをリンクします。ユーザは HTML に似た Web フォームで情報を入力します。フォームには、ユーザが編集してサーバに送り返した入力フィールドが含まれています。

音声ブラウザのリソースは VXML サーバ上にあります。これらのリソースは、VXML ファイル、デジタルオーディオ、音声認識用の命令（文法）、およびスクリプトです。VXML ブラウザは、音声アプリケーションとの通信プロセスごとに、VXML サーバへの要求として開始します。VXML ファイルには、予測される単語やフレーズを指定する文法が含まれています。リンクには、音声アプリケーションの URL が含まれています。ブラウザは、音声入力と文法の 1 つとの一致が復活するとその URL に接続されます。

Note

CVP インストーラは、CVP コールサーバ、CVP VXML サーバ、メディアサーバをまとめてインストールします。

VXML サーバのパフォーマンスを決定するには、次の点が重要です。

- Web アプリケーション サーバと音声ゲートウェイ間の QoS およびネットワーク帯域幅

- VXML サーバのパフォーマンス

- 録音済み音声と音声合成（TTS）の使用

音声ユーザ インターフェイス アプリケーションは、可能であれば録音済みオーディオ ファイルを使用する傾向があります。TTS よりも優れている録音済みオーディオサウンド。ダウンロード時間やブラウザの解釈に影響しない事前録音済みのオーディオファイルの品質を選択します。録音は 8 ビットの μ-law 8 kHz フォーマットで行います。

- オーディオ ファイルのキャッシング

音声ゲートウェイが音声コンテンツをキャッシュするように構成します。キャッシングによって、メディアソースからファイルをダウンロードする際の遅延を回避できます。

- 文法の使用

音声アプリケーションで問題は、正式なユーザビリティテスト、または使用中のアプリケーションの観察によってのみ検知できます。音声認識の精度が低いのは、音声アプリケーションでは一般的です。主な原因としては不十分な文法実装が挙げられます。ユーザが単語の発音を間違えるか、文法の設計者が予想しなかったことを話すと、認識プログラムは入力と文法を照合できません。文法に関するもう 1 つの一般的な問題は、エントリの識別が難しいことが挙げられます。これらのエントリがあると、間違って認識された入力そして、VXML サーバのパフォーマンスの低下の原因となります。認識の精度を向上させるには、そのパフォーマンスを分析し、文法の精度を調整します。

分散型ゲートウェイ

以下の項では、各種音声ゲートウェイと分散型展開におけるそれらの影響について説明します。

- ブランチでのイングレスまたはエグレス音声ゲートウェイ

- ブランチでのイングレスまたは VXML ゲートウェイ

- 併置された VXML サーバと VXML ゲートウェイ

- Centralized VXML サーバを使用したブランチにあるゲートウェイ

Related Concepts

拡張位置のコール アドミッション制御機能

ブランチでのイングレスまたはエグレス音声ゲートウェイ

ソリューションは、ブランチオフィのイングレス音声ゲートウェイを使用して、集中型または非地理的な番号ではなく、ローカルのディレクトリ番号によってアクセスを発信者に提供します。この機能は、複数国にまたがったソリューションにとって重要です。

ソリューションは、ローカライズされた PSTN ブレークアウトのために、またはソリューションに統合された 分散化 TDM プラットフォームのために、ブランチでイグレスゲートウェイを使用できます。

ソリューションの別のコンポーネントは中央に位置しています。WAN リンクは、各ブランチオフィスから メイン サイト にデータ接続を提供します。

ブランチでのイングレスまたは VXML ゲートウェイ

ブランチで実行される他の音声サービスは、イングレスゲートウェイまたは VXML ゲートウェイに影響を与える可能性があります。たとえば、ブランチがリモートの Unified CM サイトの場合、Unified CM は ACD エージェント回線と非エージェント回線の両方をサポートできます。この展開では、非エージェント回線からの新しい連絡先およびトラフィックに PSTN ゲートウェイを使用します。ブランチで VXML と音声ゲートウェイが別々のデバイス上で機能する場合は、ダイヤルプランがローカル VXML リソースに VRU レグを送信することを確実にします。これは、Unified CVP コールサーバ settransferlabel ラベルが併置されている VXML および音声ゲートウェイ構成のみに適用されるからです。

併置された VXML サーバと VXML ゲートウェイ

ソリューションでは、すべてのゲートウェイとサーバを中央集中型にするか、各サイトに一連の Unified CVP VXML サーバと VXML ゲートウェイを同じ場所に分散できます。

併置には以下の利点があります。

- WAN の機能停止がセルフサービス アプリケーションに影響を与える可能性はありません。

- VXML は WAN 帯域幅を使用します。

併置には以下の欠点があります。

- 複製されたブランチオフィスには、追加の Unified CVP VXML サーバが必要です。

- 複数の Unified CVP VXML サーバにアプリケーションを展開すると、オーバーヘッドが大きくなります。

Centralized VXML サーバを使用したブランチにあるゲートウェイ

中央集中型 VXML の利点は次のとおりです。

- 管理とレポート生成が一元化されます。

- ブランチオフィスは、Unified CVP VXML サーバのキャパシティを共有できます。

中央集中型 VXML の欠点は次のとおりです。

- 拠点の存続可能性が制限されます。

- XML over HTTP トラフィックに対してより多くの WAN 帯域幅が必要です。

Contact Center Enterprise ソリューションのローカルトランク

Contact Center Enterprise ソリューションには、カスタマーオンプレミスのローカルトランクに 2 つのオプションがあります。

- Cisco Unified Border Element — カスタマーオンプレミスの企業

- カスタマーオンプレミスの TDM ゲートウェイ

Note

トランスコーディング リソースは、ローカルのカスタマー オンプレミス ゲートウェイから確定的に選ばれるわけではありません。

CVP 設計上の考慮事項

- CVP コールサーバ設計上の考慮事項

- CVP VXML サーバ設計上の考慮事項

- CVP メディアサーバ設計に関する検討事項

- CVP コールサーバの設計に関する考慮事項

- CVP コールスタジオの設計に関する検討事項

- Unified CVP の併置

CVP コールサーバ設計上の考慮事項

- ルーティングの Unified CVP アルゴリズム

ルーティングの Unified CVP アルゴリズム

ダイヤルプランとコールルーティングを設定する場合、Unified CVP 機能を組み合わせて必要なエフェクトを実現できます。たとえば、Location Based CAC、SigDigits、SendToOriginator、LocalSRV および Use Outbound Proxy を使用できます。

CVP はこのプロセスを使用して、Unified CVP からのアウトバウンドコールに対して接続先 SIP URI を作成します。ここでは、Unified CCE からのラベルを含む CONNECT メッセージ（VXML ゲートウェイ、Unified CM など）について説明します。また、呼び出し音サービス、録音サーバ、エラー メッセージ再生サービスにも適用されます。

Note

このプロセスでは、SIP サブシステムを使用した通話についてのみ説明します。これには、音声のみと基本的なビデオ SIP 通話が含まれます。

CVP は、併置する IOS VXML ゲートウェイとイングレス音声ゲートウェイ専用の SendToOriginator アルゴリズムをサポートします。シスコ仮想化音声ブラウザ（VVB）は、アルゴリズムをサポートしません。これは、シスコ VVB を使用する際にゲートウェイを併置できないからです。

Unified CCE ラベルを含むアウトバウンドコール用の接続先 SIP URI ホスト部を作成するプロセスは、次のとおりです。

1. プロセスは、Unified CCE ラベルで開始します。Unified CCE サブシステムはすでに、Location siteID を挿入済みの場合があります。SigDigits を使用している場合は、先頭に追加されます。ネットワーク VRU ラベルの場合、Unified CCE サブシステムは、接頭辞および相関 IDにラベルとして渡されます。

2. SendtoOriginator が Unified CCE ラベルと一致する場合、Unified CVP アルゴリズムは、発信者の IP またはホスト名（イングレス音声ゲートウェイ）を使用します。ゲートウェイは、SIP URI を返します。

SendtoOriginator の設定は、Cisco イングレス音声ゲートウェイの発信者のみに適用されます（SIP UserAgent ヘッダーが選択されています）。Cisco IOS 以外のゲートウェイには、Cisco IOS VXML ゲートウェイが使用する CVP ブートストラップサービスがありません。

3. [アウトバウンドプロキシを使用（use outbound proxy）] が設定されている場合、プロキシのホストを使用して SIP URI を返します。

4. ローカルの静的ルートがラベルで検出された場合、SIP URI を返します。

Note

ローカルの静的ルートが見つからない場合、アルゴリズムは RouteNotFoundException の例外をスローします。

SIP サブシステムを使用したコールについては、次の点を検討してください。

- 複雑なダイヤル番号の文字列を回避するためには、Locations CAC siteID で SigDigits 機能を使用しないでください。

- サーバグループ FQDN（ローカル SRV FQDN）としてアウトバウンドプロキシ FQDN を指定できます。また、サーバグループ FQDN としてローカルの静的ルート接続先を構成できます。

- 着信音 DN（91919191）、録音サーバ（93939393）、およびエラーメッセージサービス（92929292）は、同じプロセスに従います。

- SendtoOriginator は、REFER ラベルで機能します。

- REFER ラベルは、SigDigits 設定で動作します。

CVP VXML サーバ設計上の考慮事項

VXML アプリケーションが複雑化すると、VXML サーバのパフォーマンスに影響を与えます。許容範囲の VXML サーバのパフォーマンスを維持するために、メモリリークとアプリケーションのデッドロックについてアプリケーションの負荷テストを行います。

CVP メディアサーバ設計に関する検討事項

- 音声プロンプトの展開と管理

- 多数のメディアファイル設計に関する検討事項

- メディアファイルの展開の設計に関する検討事項

音声プロンプトの展開と管理

次の方法で音声プロンプトを導入できます。

- ローカル ファイル システム

音声プロンプトファイルをローカルシステムに保存します。オーディオによる指示の取得は帯域幅を使用しません。このメソッドでは、音声ブラウザは、プロンプト再生のために音声ファイルを取得する必要が無いので WAN 帯域幅に影響はありません。ただし、プロンプトを変更するには、すべての音声ブラウザで変更します。

- IOS VXML ゲートウェイ — プロンプトは、フラッシュメモリで導入されます。

IOS VXML ゲートウェイは、VXML ゲートウェイまたは PSTN ゲートウェイのどちらかであり、同じ場所にあるイングレス音声ゲートウェイと VXML ゲートウェイを持ちます。WAN がダウンした場合のエラーメッセージやメッセージなど、重要なプロンプトだけをここに保存します。

G.711 μ-law フォーマットで録音した場合、一般的なプロンプトのサイズは 10 ～ 15 KB です。これらのゲートウェイの場合、プロンプトの数とそのサイズを分解して、フラッシュメモリのサイズを調整します。Cisco IOS イメージを保存するためのスペースも残します。

- Cisco VVB — ローカルファイルシステムにプロンプトをアップロードします。

Cisco VVB には、組み込みの CVP プロンプトが含まれています。エラー トーン デフォルト プロンプトは、Cisco VVB 管理者コンソール で変更できます。

- メディア サーバ

ローカルの各音声ブラウザが適切に設定されている場合、プロンプトのサイズに応じて、多くのプロンプトをキャッシュできます。Cisco VVB は最大 512 MB、Cisco IOS は最大 100 MB キャッシュできます。メディアサーバがメディア ファイルに適切に配信されているかどうかをテストするには、ブラウザのメディアサーバでプロンプトの URL を指定します。お使いの Web ブラウザは、認証なしで .wav ファイルをダウンロードし、再生します。

メディアサーバ導入の設計は、次の要因によって異なります。

- 各ゲートウェイが再生するメディアファイルの数

- ゲートウェイとメディアサーバ間のネットワーク接続

- メディアファイルを変更する頻度

多数のメディアファイル設計に関する検討事項

ゲートウェイが顧客に対してさまざまなメディアファイルを再生する場合、ゲートウェイに、すべてのメディアファイルをキャッシュできるスペースがない場合があります。

たとえば、エージェントが多い企業があるとします。各エージェントには、それぞれエージェント グリーティング ファイルがあります。ゲートウェイのフラッシュメモリでは、それらのファイルをキャッシュすることはできません。

- 音声ブラウザを使用してメディアサーバを同じ場所に配置

- WAN 上に分散されたメディアサーバと音声ブラウザ

- メディアストリーミングの設計に関する検討事項

音声ブラウザを使用してメディアサーバを同じ場所に配置

この問題の 1 つの方法は、音声ブラウザを使用してメディアサーバを場所に配置する方法です。メディアサーバと音声ブラウザを十分な帯域幅がある LAN 上で共存させる場合、プロンプトをダウンロードしても大きな遅延は発生しません。

WAN 上に分散されたメディアサーバと音声ブラウザ

ソリューションでは、WAN 全体の音声ブラウザから分離されたメディアサーバを使用できます。

次の図は、WAN 上での分散型展開を示しています。

WAN 経由の分散型展開

高遅延 WAN 全体のメディアファイルを音声ブラウザにダウンロードすると、大幅な遅延が起こる場合があります。この遅延は、ユーザエクスペリエンスに大きく影響します。この遅延は、WAN 全体で転送されるメディアファイルのサイズと数に大きく影響します。Wide Area Application Services（WAAS）を使用すると、遅延を最適化できます。

メディアストリーミングの設計に関する検討事項

LAN 展開と WAN アクセラレータ展開の両方では次の要因を検討します。

- 最大ネットワーク ラウンドトリップ時間（RTT）の遅延は、200 ミリ秒です。

たとえば、一括管理ファイル転送（BAFT）を使用した CVP オペレーションコンソールからイングレスまたは VXML ゲートウェイへのファイル転送など。

- メディアフォークを使用したビデオの追加オーバーヘッドなしの各ゲートウェイでサポートされているストリーミングセッションの最大数。

次の表は、さまざまな展開で使用する優先メディアストリーミング方法を示します。

シナリオ

変更の頻度

LAN 上

WAN 上

少数のファイル

稀

Cached

Cached

少数のファイル

よく利用する

ストリーミング済みまたはキャッシュ済み

WAAS でストリーミング

多数のファイル

稀

ストリーミング済み

WAAS でストリーミング

多数のファイル

よく利用する

ストリーミング済み

WAAS でストリーミング

Note

Cisco VVB では、メディアストリーミング機能はサポートされていません。

メディアファイルの展開の設計に関する検討事項

- TCP ソケットの保持はサポートされていません

- WAN 高速化サポート

- IOS ゲートウェイ上のメディアファイルの展開

- Cisco VVB でのメディアファイルの展開

- キャッシュ エージング

TCP ソケットの保持はサポートされていません

Unified CVP は TCP ソケットの永続性をサポートしません。

WAN 高速化サポート

Wide Area Application Services（WAAS）システムは、Wide Area Application Engine（WAEs）と呼ばれるデバイスの一式です。ネットワーク上の TCP トラフィックを最適化するために、WAEs が協働します。Cisco WANAS は、TCP の最適化技術とアプリケーション アクセラレーション機能を使用して、WAN を経由したトラフィックの転送に関する最も一般的な課題を解決します。VXM ゲートウェイ側のネットワークの周辺に展開すると、Cisco WAAS が次の機能を実行します。

- トラフィックを最適化するために TCP ヘッダーを変更します。

- ローカルに配置された大規模な HTTP キャッシュとして機能します。

- 圧縮アルゴリズムを使用してトラフィックをさらに減らします。

- データ冗長性排除（DRE）技術によりトラフィックを削減します。

Cisco WAAS は、すべてのデータが強制的に Cisco WAAS にパススルーするインラインモードで展開されます。

IOS ゲートウェイ上のメディアファイルの展開

- 非ストリーミングおよびストリーミングモード

- メディア ファイル キャッシュ タイプ

- クエリ URL のキャッシング

非ストリーミングおよびストリーミングモード

非ストリーミングモードでは、Media Player がプロンプトの再生を開始する前に、VXML ゲートウェイは、HTTP サーバから音声ファイル全体をダウンロードします。これにより、発信者の遅延が発生します。小規模ファイルの場合、遅延は数ミリ秒です。キャッシングまたはストリーミングモードのいずれかを使用すると、サイズの大きいファイルの遅延を回避できます。

ストリーミングモードでは、Media Player は HTTP サーバから発信者にオーディオをメディアチャンクでストリーミングします。Media Player は、最初のチャンクを受信するとプロンプトの再生を開始します。ストリーミングモードでは、オーディオによる指示のサイズによって、発信者に遅延が追加されることはありません。だたし、チャンクのメディアファイルをフェッチするための前後の対話によりパフォーマンスが低下する場合があります。

メモリ内の音声ファイルをキャッシュすると、HTTP サーバから直接ストリーミングする大きなファイルの利点が少なくなります。

メディア ファイル キャッシュ タイプ

メディアファイルを保存するキャッシュは、2 種類あります。

HTTP Client キャッシュ

非ストリーミングモードでは、HTTP Client キャッシュにメディアファイル全体が保存されます。ストリーミングモードでは、HTTP Client キャッシュに、最初のチャンクのメディアファイルが保存されます。HTTP Client キャッシュには、どちらのモードでも 100 MB のプロンプトが保存されます。構成されている HTTP Client のメモリファイルサイズよりも大きいファイルはキャッシュされません。

VRU メディア プレーヤー キャッシュ

非ストリーミングモードでは、VRU メディア プレーヤー キャッシュは使用しません。ストリーミングの役割では、VRU メディア プレーヤー キャッシュには、ファイルのすべてのサイズが格納されます。非ストリーミングモードでは、VRU メディア プレーヤー キャッシュに 16 MB が保存されます。ストリーミングモードでは、32 MB を保存できます。

クエリ URL のキャッシング

クエリは、疑問符（?）の後に 1 つ以上の name=value 属性ペアが続く URL です。Unified CVP VXML サーバは、動的 VXML ページの生成時にクエリ URL を使用します。各コールは一意なので、クエリ URL から取得したデータは、キャッシュメモリを使い古す場合があります。クエリ URL にアカウント番号や PIN などの情報を含め得る場合があるので、データはセキュリティリスクに該当する場合が考えられます。

Cisco IOS は、デフォルトでクエリ URL キャッシングを無効にします。無効になっていることを確認するには、Cisco IOS で show run コマンドを入力し、次の Cisco IOS コマンドが表示されていないことを確認します。

Gateway configuration: http client cache query

Cisco VVB でのメディアファイルの展開

Cisco VVB には HTTP クライアントが含まれています。クライアントは、VXML ドキュメント、オーディオファイル、その他のファイルリソースをフェッチし、フラッシュメモリに格納します。

キャッシングプロパティは、VXML リソース、オーディオによる指示、文法ファイル、およびスクリプトファイルに関連付けられます。

デフォルトでは、クエリ URL はキャッシュされません。クエリは、疑問符（?）の後に 1 つ以上の name=value 属性ペアが続く URL です。

キャッシュ エージング

HTTP Client は、キャッシュされた各エントリの鮮度によってそのキャッシュを管理します。キャッシュされたエントリが新しいのか古いのかは、[経過期間（Age）] および [FreshTime] によって異なります。[経過期間（Age）] は、サーバから最後にファイルがダウンロードされてからの経過時間です。[FreshTime] は、ファイルが最後にダウンロードされてから HTTP Client キャッシュにファイルがとどまると想定される時間です。

いくつかの変数は、サーバからの HTTP メッセージヘッダーやキャッシュ更新値などのファイルの [FreshTime] に影響します。

ファイルの [FreshTime] は、次のシーケンスで決定されます。

1. ダウンロード時に、ファイルに Cache Control: max-age ヘッダーがある HTTP メッセージヘッダーがある場合、[FreshTime] は、max-age となります。

2. ステップ 1 を適用しない場合 、[FreshTime] は、Expires ヘッダーから Date ヘッダーを引き算した値になります。

Note

HTTP/1.1 仕様である、RFC 2616（ハイパーテキスト トランスポートプロトコル）は、Cache Control: max-age ヘッダーまたは Expires ヘッダーのどちらかを使用することを推奨しています。

3. 前述のヘッダーが既存しない場合、FreshTime は、Date ヘッダーの 10% 分の値から、最終更新日 ヘッダーを差し引いた値になります。

Cisco IOS VXML ゲートウェイの場合、FreshTime の値を、http client cache refresh コマンドと一緒にファイルに割り当てることができます。ただし、その値が適用されるのは、前のシーケンスで値の設定に失敗した場合のみです。

古いファイルは、必要な場合にのみ更新されます。古くキャッシュされたエントリは、次の条件に基づいて新しいファイルのスペースが削除されるまでキャッシュ内に残ります。

- キャッシュされたエントリが古くなった。

- 更新カウントがゼロ（0）である。つまり、キャッシュされたエントリが使用されていない。

- キャッシュには、別のエントリのスペースを創るためのメモリスペースが必要です。

[経過時間（Age）] が、[FreshTime] を超過し、ファイルを再生する必要がある場合、HTTP Client は、メディアサーバを使用してファイルを更新するか否かを判断します。HTTP Client は、GET リクエストをサーバに送信し、上限付き GET を使用してネットワークトラフィックへの影響を最小限に抑えます。GET 要求では、サーバに送信されるヘッダーに If-Modified-Since が含まれます。このヘッダーがあると、サーバは 304 応答コード（未修正）を返すか、ファイルが最近更新された場合は、ファイル全体を返します。[経過時間（Age）] が、[FreshTime] を超過し、ファイルを再生する必要がある場合、HTTP Client は、メディアサーバを使用してファイルを更新するか否かを判断します。HTTP Client は、GET リクエストをサーバに送信し、上限付き GET を使用してネットワークトラフィックへの影響を最小限に抑えます。GET 要求では、サーバに送信されるヘッダーに If-Modified-Since が含まれます。このヘッダーがあると、サーバは 304 応答コード（未修正）を返すか、ファイルが最近更新された場合は、ファイル全体を返します。

この条件付き GET は非ストリーミングモードにのみ適用されます。ストリーミングモードでは、HTTP Client は常に条件なしの GET を発行します。ストリーミングモードで各 GET が条件なしでリロードされる GET リクエストには、If-Modified-Since ヘッダーは含まれていません。

CVP コールサーバの設計に関する考慮事項

CVP コールサーバはレポーティングサービスを提供し、IBM Informix Dynamic サーバ（IDS）データベース管理システムをホスティングします。データベースのスキーマを使用すると、データベースに対してカスタムのレポートを作成できます。レポーティングサービス自体は、データベースの管理アクティビティおよびメンテナンスアクティビティ（バックアップや消去など）を実行しません。ただし、Unified CVP では、こうしたメンテナンス タスクに Operations Console を介してアクセスできます。

レポーティングサービス：

- コンタクトセンター内のセルフサービス アクティビティの 履歴レポートを提供します。サービスは、コンタクトセンター マネージャーのコールアクティビティをまとめたものです。

- さまざまな VRU アプリケーション運用分析も提供できます。

- VXML サーバの IVR サービスと SIP サービスからレポートデータを受信します。Reporting サービスは、このデータを Informix データベースに変換して書き込みます。

ソリューションは、単一の複数の CVP コールサーバのいずれかを使用できます。単一の コールサーバが、必ずしもシングルポイント障害であるわけではありません。データベース管理システムは、データの安全性とセキュリティを提供します。ソリューションは、ソースコンポーネントに関する情報が永続的にバッファリングされたことが原因の一時的な機能停止に耐えることができます。

ソリューションが複数の コールサーバを使用している場合は、各 CVP コールサーバを 1 つの コールサーバにのみ関連付けできます。また、レポートは、複数の Informix データベース間で作成できません。

Note

Unified CVP のサブコンポーネントは、マシン時間そのものを同期できません。ロギングとレポートに対して正確なタイムスタンプを保証するために、NTP などのコンポーネント間の時刻同期機能を提供します。

- CVP コールサーバの機能

- CVP バックアップおよびリストア

CVP コールサーバの機能

CVP コールサーバを使用してソリューションを設計する際は、次の点を検討してください。

- Informix データベースのサイズは最大 100 GB です。実稼働環境では、2 GB 以下のデータベースを使用することはできません。

- コールサーバは、Analysis Manager ツールをサポートしています。Analysis Manager は、認証済みのユーザのログイン情報を使用して コールサーバを照会できます。

- コールサーバは、Unified CVP データを 15 分単位で集約します。Cisco Unified Intelligence Center は、15 分間、毎日、および毎週の間隔で、コールデータと優先パス情報を表示するテンプレートを提供しています。

- 管理プロセスのすべてのメタデータは 、Ciscoadmin データベースに含まれています。このロケーションは、レポートユーザの通常ビューからテーブルを削除します。

- すべてのデータベース バックアップ ファイルは、圧縮され、Reporting Server に保存されます。バックアップファイルは、cvp_backup_data.gz と呼ばれ、cvp_db_backup フォルダの%INFORMIXBACKUP% ドライブで保存されます。

- システム CLI を使用して、コールサーバ上のログファイルを一覧するリクエスト（show log）を作成できます。この要求には、Informix データベース サーバ エンジンのログが含まれています。show tech-support コマンドは、これらファイルにも含まれます。

- システム CLI 内でデバッグ レベル 3（または 0）コマンドを使用すると、デバッグのオンとオフを切り替えられます。オンにすると、このコマンドは、すべての管理手順、消去、統計、およびアグリゲータに関するトレースファイルを生成します。

Note

コマンドをオンにしたら、トレースファイルはデータベースにより大きな不可をかけます。

- 管理手順のログデータは、毎晩 %CVP_HOME%\logs フォルダに書き込まれます。

- StartDateTime、EndDateTime および EventDateTime のすべての値は、コールサーバテーブルで UTC で保存されます。

- SIP コールイベントの転送タイプデータおよび転送ラベルは、コールイベントテーブルに保存されます。

- 要約の消去結果が、ログテーブルに記録されます。

- 3 つの新しいスケジュール済みタスクが、コールサーバのスケジューラに追加されました。

- CVPSummary は、要約テーブルを構築します。

- CVPCallArchive は、コールバックデータをアーカイブしてコールバックデータベースのパフォーマンスを維持します。

- CVPLogDump は、毎晩管理ログを抽出します。

CVP バックアップおよびリストア

Operations Console を使用すると、データベースバックアップの日次スケジュールを設定したり、オンデマンドでデータベースバックアップを実行できます。大きな障害が発生した場合は、前回のバックアップ時間まで手動でデータベースを復元できます。これにより、データの損失は 24 時間までになります。

CVP コールスタジオの設計に関する検討事項

CVP Call Studio でアプリケーションを設計する場合は、アプリケーションを小規模で、ビジネスフローに近い状態でマッピングしてください。大きなアプリケーションでは、保守と作業が難しくなります。サブフローと独立したアプリケーションのバランスを維持します。

Unified CVP の併置

SIP 呼制御に必要なサーバの数を計算するには、次の式を使用します。

(Self Service + Queue and Collect + Talking) / 3000, rounded up

ここで、

セルフサービスは、SIP 呼制御を要求し、VXML サーバ上でアプリケーションを実行するコールの数です。

キューと収集は、SIP 呼制御を必要とするコールの数であり、コールサーバ上でのみ Microapps を使用してアプリケーションを実行します。

通話中は、エージェントのコール数です。

次の例は、VXML セッションおよび HTTP セッションだけに適用されます。

((3000) + (500) + 3700) / 3000 = 3 servers

VXML 要件を処理するフロースルーコールにセッション ボーダー コントローラ（SBC）として CUBE を使用する場合は、例で示すサイジング情報を使用します。

フロースルーコールのみ（VXMLなし）を処理するためにセッション ボーダー コントローラ（SBC）として CUBE を使用する場合、音声アクティビティ検出（VAD）を考慮し、http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/order_guide_c07_462222.html の『Cisco Unified Border Element Ordering Guide』に記載されているサイジング情報を参照してください。

Contact Center Enterprise 設計上の考慮事項

Contact Center Enterprise ソフトウェアは、企業全体へのマルチチャネル コンタクトのディストリビューションを実現します。このソフトウェアは、インバウンドおよびアウトバウンドの電話、Web コラボレーション要求、 E メール メッセージ、チャット要求をサポートできます。また、地理的に離れているコンタクト センターもサポートできます。Contact Center Enterprise ソフトウェアはオープンな標準ベースのソリューションであり、ルーティング、キューイング、モニタリング、耐障害性などの機能を備えています。

Note

Unified CCE は、Contact Center Enterprise ソリューションのいずれかと、すべてのソリューションのコア コンポーネントのいずれかの両方を示す名前です。

- ルータの設計上の考慮事項

- Logger の設計上の考慮事項

- 周辺機器ゲートウェイ設計上の考慮事項

- Administration & Data サーバ設計上の考慮事項

- Live Data サーバ設計上の考慮事項

ルータの設計上の考慮事項

冗長 Unified CCE サーバを地理的に分散したり、同じ物理サイトで配置できます。実稼働の展開では、ルータと Logger は、パブリックネットワークとは分離されたプライベートネットワーク経由で接続する必要があります。

セントラルコントローラの高可用性の設計

Note

セントラルコントローラと PG には同じプライベート ネットワーク パスを使用できます。

Logger の設計上の考慮事項

Logger データベースの設計は、通常 2 週間分のデータが保持されています。この期間は、データが AW-HDS-DDS に複製されるのに十分な時間を与えます。

この Logger は、ルータとして同じプライベートネットワーク パスを使用します。

周辺機器ゲートウェイ設計上の考慮事項

- エージェント周辺機器ゲートウェイ設計上の考慮事項

- 音声応答設備の周辺機器ゲートウェイ設計上の考慮事項

- メディアリソース周辺機器ゲートウェイ設計上の考慮事項

エージェント周辺機器ゲートウェイ設計上の考慮事項

エージェント PG は、CTI Manager を介して Unified CM クラスタと通信します。エージェント PG は、クラスタ内の任意の場所でエージェントの電話機と CTI ルートポイントを制御できます。エージェント PG は、クラスタ内の Unified CM サブスクライバ上で CTI Manager に登録します。CTI Manager は、クラスタに対して PG からのすべての JTAPI リクエストを受け入れます。PG が別のサブスクライバの電話機またはルートポイントをリクエストすると、CTI Manager はそのリクエストを別のサブスクライバに転送します。

Note

エージェント PG は、Unified CM PIM を含む PG です。これは、Unified CM PG と呼ばれる場合があります。非リファレンス設計でのみ、エージェント PG は汎用 PG である場合があります。

フォールトトレランス設計は、冗長構成でのエージェント PG 展開します。これは、PG のみが単一 CTI Manager を介してクラスタに接続するからです。その CTI Manager に障害は発生すると、PG は、クラスタと通信できなくなります。冗長 PG は、クラスタの異なるサブスクライバ上の異なる CTI Manager を介して二次的な経路を提供します。

高可用性クラスタの最小設計は、1 つのパブリッシャと 2 つのサブスクライバです。プライマリサブスクライバに障害が発生した場合、デバイスはクラスタのパブリッシャではなく、セカンダリサブスクライバにリホームされます。

Unified CM クラスタの高可用性の設計

冗長 PG は、パブリックネットワークとは分離されたプライベートネットワークを介して同期を維持します。2 台の PG サーバが地理的に分散されている場合は、プライベートネットワーク用に別個の WAN 接続を使用します。ネットワーク内でのシングルポイント障害を回避するために、パブリックネットワークに対して同じ回路またはネットワークギアを使用しないでください。

エージェント PG 内では、JTAPI ゲートウェイおよび Unified CM PIM が、クラスタへの接続を管理します。JTAPI ゲートウェイは、Jabber ソケット接続プロトコルおよび PIM および CTI Manager 間のメッセージを処理します。PIM は、Unified CCE、JTAPI ゲートウェイおよびクラスタ間のインターフェイスを管理します。クラスタからのルートリクエストを監視および処理する特定のオブジェクトをリクエストします。PG は、ノード管理プロセスとして JTAPI ゲートウェイと PIM を自動的に開始します。PG が監視および処理をして、障害が発生した場合は、自動的に再起動します。

両方の冗長エージェント PG からの JTAPI サービスは、初期化後に CTI Manager にサインインします。エージェント PG-A がプライマリ CTI Manager にサインインし、エージェント PG B がセカンダリ CTI Manager にサインインします。ペアになっている 1 つの PG のみが、電話機とCTI ルートポイントを積極的に登録し、監視します。冗長 PG は、ホットスタンバイモードのみで実行されます。冗長 PG はセカンダリ CTI Manager にサインインし、インターフェイスを初期化して、フェールオーバーで使用できるようにします。この取り決めにより、フェールオーバーの時間が大幅に短縮されます。

システムが起動すると、最初に Router サーバに接続された PG とリクエスト構成情報が、アクティブな PG になります。ルータは、接続が最適な PG がアクティブになることを確認します。「サイド A」と「サイド B」の名目上の指定することで、どの PG がアクティブになるかへの影響はありません。プライベートリンクの障害による PG のフェールオーバー中、重みづけメカニズムは、どの PG をアクティブにするかを選択し、コンタクトセンターへの影響を最小に抑えます。

PIM が運用可能になる前に、コールが CTI ルートポイントに到着した場合、リカバリ回数を設定しない限りそのコールは失敗し続けます。ルートポイントの [未登録時のコール転送（Call Forward on Unregistered）] または [障害時のコール転送（Call Forward on Failure）] 設定にリカバリ回数を指定します。たとえば、[自動応答（Auto Attendant）] の Cisco Unity 音声メールシステムに対してリカバリ回数を設定できます。

Note

別のパーティションの別の CTI ルート ポイントでの CTI ルート ポイントの DN は使用できません。DN がすべてのパーティション上のすべての CTI ルート ポイントで一意であることを確認します。

アクティブ PG シャットダウン

実稼働環境でアクティブな周辺機器ゲートウェイがシャットダウンしないようにします。これにより、反対側に接続してアクティブになる間、1 分以上のサービスの中断が発生します。中断の長さは、構成のサイズと周辺機器の種類によって異なります。たとえば、VRU 周辺機器は、通常より短い時間しかかかりません。VRU の別のサイドでは、再アクティブ化まで 30 秒以下を要する場合があります。

音声応答設備の周辺機器ゲートウェイ設計上の考慮事項

標準規格の 3 つの PG モデルでは、VRU PG にはサイド A とサイド B にある CVP サーバに 1:1 ペアリングをする 2 台の PIM が含まれています。

メディアリソース周辺機器ゲートウェイ設計上の考慮事項

標準規格 3 台の PG モデルでは、MR PG に次の機能をサポートする PIM が含まれます。

- アウトバウンド オプション

- ビジネス チャットおよび E メール

- Customer Collaboration Platform— この PIM は、タスクルーティングとエージェントリクエストを処理します。

- サードパーティ製品との統合

Administration & Data サーバ設計上の考慮事項

- リファレンス設計ごとの Administration & Data サーバ制限

リファレンス設計ごとの Administration & Data サーバ制限

各 Logger に対してたくさんの Administration & Data サーバを展開できます。

Logger ごとの Administration & Data サーバ展開制限

各 Logger 側のコンポーネント

2000 エージェント

4000 エージェント

12,000 エージェント

AW-HDS-DDS

各サイドに 1 つ、コアコンポーネントと同じサーバにインストールされます。

サイドごとに 2 つ

NA

HDS-DDS

該当なし

該当なし

サイドごとに 1 つ

AW-HDS

オプションで、コアコンポーネントとは別のサーバにインストールされた、各サイドごとに 1 つの AW-HDS または AW-HDS-DDS のいずれか

NA

各サイドごとに 3 つ

リアルタイム ディストリビュータのみ [1]

サイドごとに 2 つ

サイドごとに 2 つ

各サイドごとに 5 つ

[1] この AW は構成専用です。リファレンス設計レイアウトに表示されているサーバからインストールします。

Note

各リアルタイム ディストリビュータは 64 人のユーザをサポートできます。

Live Data サーバ設計上の考慮事項

- ライブデータ構成によるクライアントのレポート

ライブデータ構成によるクライアントのレポート

2000 エージェントリファレンス設計にはライブデータの併置構成を使用します。スタンドアロン Live Data サーバを使用するソリューションの場合、Unified CCE Rogger 展開に対して通常、小規模の Live Data 展開構成を使用します。通常は、個別のルータおよび Logger を使用して大規模の Live Data 展開構成を使用します。

Note

標準規格の Cisco Finess エージェントデスクトップには、ライブデータガジェットが含まれます。

Cisco Virtualized Voice Browser の設計上の考慮事項

ソリューションで必要な仮想化音声ブラウザは、ソリューションが VXML ゲートウェイで必要とする VRU ポートに応じて異なります。ソリューションに必要な SIP セッションの数に応じた Cisco VVB をインストールしてください。以下の表に、Cisco VVB による機能サポートを示します。

プラットフォームまたは機能

Cisco Virtualized Voice Browser に関する考慮事項

音声コーデック

G711

コール フロー

スタンドアロン コール フロー、およびコール存続可能性を備えた包括的コール フローがサポートされます。

ASR/TTS

サポート対象

サービス コールバック

サポート対象

HTTP

サポート対象

HTTPS

サポート対象

ローカル プロンプト

サポート対象

ローカル ホスト名の解決

サポート対象

MRCP v1 および v2

サポート対象

VXML 2.0 および 2.1

サポート対象

RTSP ストリーミング

未サポート

ビデオ

未サポート

Unified Communications Manager の設計上の考慮事項

Note

リファレンス設計のレイアウトでは 7500 ユーザの Unified CM OVA を使用しており、サブスクライバの冗長ペアごとに 2000 の Contact Center Enterprise エージェントがサポートされます。別の Unified CM OVA を使用する場合は、リファレンス設計のレイアウト内のサーバからクラスタを移動させるか、仕様ベースのハードウェア ポリシーに従ってください。仕様ベースのポリシーの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.html でソリューションに応じた Cisco Collaboration Virtualization のページを参照してください。

Cisco Unified Communications Manager（Unified CM）は、Unified CVP から渡されたコールを Unified CCE で選択されたエージェントに接続します。Unified CVP は、SIP を使用する Unified CCE エージェント電話またはデスクトップに発信者を転送します。Unified CVP コール サーバは、Unified CCE からエージェント ラベルを受信し、そのコールを SIP プロキシを使用してルーティングします。コールはクラスタ内の適切な Unified CM サブスクライバに送信され、発信者がエージェントに接続されます。コール サーバがコール シグナリングの代わりになり、転送完了後、コール シグナリング パスに留まります。ただし、RTP ストリームは、発信元ゲートウェイから電話に直接流れます。

すべての Contact Center Enterprise ソリューションは、冗長 Unified CM、Unified CCE、Unified CVP のコンポーネントを使用します。冗長性のために、ソリューションでコア システムの半分が失われることがありますが、ソリューションは引き続き機能します。そのような場合、ソリューションは、まだ動作可能なコンポーネント上の VRU セッションまたはエージェントに、Unified CVP を介してコールを再ルーティングすることによりコールを処理します。可能な場合は、Unified CM パブリッシャでデバイス、コール処理、CTI Manager サービスが実行されないように、Unified CCE を展開してください。

自動フェールオーバーとリカバリを有効にするには、冗長コンポーネント ペアをプライベート ネットワーク パスを介して相互接続します。コンポーネントは、障害検出に TCP ハートビート メッセージを使用します。Unified CM は、フェールオーバーとリカバリにクラスタ設計を使用します。各クラスタには Unified CM パブリッシャと複数の UM サブスクライバが含まれています。エージェントの電話とコンピュータはプライマリ ターゲットに登録されますが、プライマリで障害が発生した場合は、バックアップ ターゲットに自動的に再登録されます。

Contact Center Enterprise ソリューションの Unified CM クラスタを設定するには、以下の手順を実行します。

- Unified CM で SIP トランクを設定します。

- エージェント ラベルを設定するときは、どのデバイスがルーティング クライアントかを考慮します。ラベルが Unified CM に直接返される場合は、Unified CM がルーティング クライアントになります。ラベルが Unified CVP に送信される場合は、Unified CVP スイッチ レッグ コール サーバのそれぞれにラベルを関連付けます。

- エージェント PG への Unified CM 接続

- 単一回線および複数回線機能のサポート

- Unified CM トランクでの MTP の使用

- モバイル & リモート アクセス

エージェント PG への Unified CM 接続

次の方法で、Agent PG を展開すると Unified Communications Manager クラスタに接続できます。

- サブスクライバの各ペアにエージェント PG を導入します。各サブスクライバは、CTI Manager サービスを実行します。各エージェント PG は、対応するサブスクライバペア上で実行されている CTI Manager に接続します。次の図は、4 つのプライマリサブスクライバが必要で、4 つのバックアップサブスクライバが導入され、1:1 の冗長性を提供する例を示しています。

クラスタ内のサブスクライバの各ペアのエージェント PG の導入

次の図は、2 つのエージェント PG ペアを含むソリューションのコンポーネントと 4 つのサブスクライバを持つクラスタ間の接続を示しています。

Unified CM クラスタ用の 2 つのエージェント PG ペア

- クラスタ全体に対して 1 つのエージェント PG を導入します。このタイプの導入では、CTI Manager を実行している 1 ペアのサブスクライバが必要です。CTI Manager サービスを実行しているサブスクライバを含む、すべてのサブスクライバ間でエージェントの電話機の登録を分散します。次の図は、4 つのプライマリサブスクライバが必要で、4 つのバックアップサブスクライバを導入して 1:1 の冗長性を提供する例を示しています。

クラスタ全体に対する単一エージェント PG の導入

Note

クラスタがバックオフィス電話機とエージェント電話機の両方をサポートしている場合は、このオプションを使用します。

次の図は、2 つのエージェント PG ペアを含むソリューションのコンポーネントと 4 つのサブスクライバを持つクラスタ間の接続を示しています。

Unified CM クラスタ全体に対する単一エージェント PG ペア

このモデルでは、PG のサーバ数が減ります。もう 1 つの利点は、クラスタ全体に対して単一の PIM が使用できることです。そのため、多くのサブスクライバにまたがり、チームを作成できます。これにより、たとえば、スーパーバイザは、クラスタ内のサブスクライバに登録されたエージェント電話機をモニタできます。ただし、この導入では、クラスタ上のリソース使用率が若干高くなる可能性があります。Cisco Unified Communications Manager Capacity ツール を使うと、ソリューションの Unified CM サーバのサイズを変更できます。

単一回線および複数回線機能のサポート

単一回線および複数回線のサポート

Unified CCE は、単一回線と複数のエージェント回線の Unified CM ベースのモニタリングをサポートします。複数回線がサポートする機能は次のとおりです。

- 全回線のコールのモニタリングとレポート。

- コール開始以外では、ACD 以外の内線上のすべての呼制御は、複数回線に対応したデスクトップでサポートされています。初期コール設定後、デスクフォンから開始されたコールを制御できます。

- 最大 2 つのコールアピアランスが必要です。

- 1 台の電話機あたり最大 4 回線、1 ACD 回線、および最大 3 つの非 ACD 回線をサポートします。

- ACD および非 ACD 回線の共有電話をサポートします。相違点については、以下の表を参照してください。

- ACD 以外の回線を共有している複数のデバイスを構成できますが、エージェントにログインできるのは 1 つのデバイスのみです。Unified CCE は、共有電話をサポートしているので、自宅やオフィス両方で音声設備を備えているエージェントが音声メール回線を共有できるようにします。

Note

共有 ACD 以外の回線は、PG Explorer で非 ACD 回線影響の構成をサポートしません。

- マルチライン エージェント モードが有効な場合、Unified CCE にサードパーティの CTI アプリケーションとの下位互換性がない場合があります。サードパーティベンダーとのマルチラインサポートを検証します。

単一回線の対複数回線の動作

操作

単一回線の動作

複数回線の動作

通話が 2 番目の回線にあるときに、ルーティングされた通話を受けることはできますか。

あり

はい。展開に影響がないことを確認するために非 ACD 回線影響が設定されている場合。

Unified CM ベースのサイレントモニタを使用したスーパーバイザモニタ

はい

はい

Note

ACD 以外の回線では、Unified CM ベースのサイレントモニタリングはサポートされていません。

コール パーク

監視されていない 2 つ目の回線でサポート

すべての回線がモニタ対象のため、サポートされていません。

通話待機/ビジートリガー > 1

サポートあり

サポートは終了しました。69xx シリーズの電話機では 1 にハードコードされています（複数回線を有効にする前に構成する必要があります）。

2 番目の回線コールに関するレポート

Unified CM での CDR の使用

監視されていないデバイスを使用したエージェントの非 ACD 回線、または別のエージェントの非 ACD 回線との間の通話に対する終了通話詳細レコードは、非 ACD 周辺機器通話タイプで報告されます。ACD 以外の回線上のすべてのコールに対するレポートは、そのエージェントの [エージェント間隔（Agent Interval）] テーブルでキャプチャされます。

電話機で構成済みの回線数

制限に関する説明はなし（1 回線の監視のみ）

4 回線を超える構成は行わないでください。構成すると、エージェントが任意の回線にサインインできなくなります。これにより、構成アラートが生成されます。

ACD 共有回線

共有電話は、最大 2 台のデバイスに対し ACD 回線でサポートされています。デバイス制御は、オフフックにするか、通話を発信または受信することで、デバイスそのものを介して選択されます。

共有電話は、最大 2 台のデバイスに対し ACD 回線でサポートされています。デバイス制御は、オフフックにするか、通話を発信または受信することで、デバイスそのものを介して選択されます。

ACD 以外の共有回線

ACD 以外の回線を共有している複数のデバイスを構成できますが、エージェントにログインできるのは 1 つのデバイスのみです。Unified CCE は、共有電話をサポートしているので、自宅やオフィス両方で音声設備を備えているエージェントが音声メール回線を共有できるようにします。

Note

共有 ACD 以外の回線は、PG Explorer で非 ACD 回線影響の構成をサポートしません。

監視されていない回線でのサポート、構成制限無し

非 ACD 回線のサポートは、共通の 2 番目の回線を持つデバイスに 1 人のエージェントがログインする場合に限られています。

エージェントは両方の電話機に同時にサインインできません。

別のエージェントは、同じ共通回線を持つ別のデバイスにサインインできません。

Unified CM トランクでの MTP の使用

ソリューションで Unified CM SIP トランク を使用する場合は、Cisco Unity Voice Mail や Mobile Agent などの特定のコールフローに、MTP リソースが必要な場合があります。

これは、DTMF のインバンド対アウトオブバンド機能など、エンドポイントの交渉済みメディア機能が一致しない場合の必要です。この場合、Unified CM は、DTMF メディア機能の不一致により、MTP を動的に配置します。

サードパーティ製のデバイスで相互運用する場合、ソリューションに MTP が必要になる場合があります。

モバイル & リモート アクセス

シスコ コラボレーション エッジ アーキテクチャには、エンタープライズ ネットワークにはないデバイスによるアクセスを可能にする Unified Communications Mobile and Remote Access（MRA）が含まれています。MRA は Expressway を使用して、安全なファイアウォール トラバーサルを提供し、Unified CM 登録をサポートします。Unified CM は、サポートされているデバイスに呼制御、プロビジョニング、メッセージング、およびプレゼンスサービスを提供できます。

コラボレーションエッジの詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/tsd-products-support-series-home.html 次のドキュメントを参照してください。Expressway の展開と構成の詳細については、http://www.cisco.com/c/en/us/support/unified-communications/expressway-series/tsd-products-support-series-home.html のドキュメントを参照してください。MRA のデバイスサポートの詳細については、ソリューションの 互換性マトリックス を参照してください。

ソリューションで MRA を使用する場合は、次の点を検討してください。

- Cisco Finesse クライアントとサーバ間の接続は、MRA 接続ではなく、VPN を使用しています。

- 一部の電話機は、MRA でのエクステンションモビリティをサポートしていません。

- Contact Center Enterprise ビデオ展開は、MRA に対応していません。

- 電話機の BiBに依存する Agent Greeting、Unified CMベースのサイレントモニタリングなどのコンタクトセンターの特定機能は MRA を介してはサポートされていません。

- VPN のスプリットトンネリングが構成されている場合は、同じクライアントマシン上で、MRA を備えた Jabber と Finesse デスクトップを使用できます。Cisco AnyConnect モビリティ クライアント スプリット トンネリングの構成に関しては、https://www.cisco.com/c/en/us/support/security/anyconnect-secure-mobility-client/products-installation-and-configuration-guides-list.html を参照してください。

- VPN スプリットトンネリングを利用できない場合は、2 つのクライアントに分割した後に実行できます。

- 1 台のクライアントマシンで MRA を備えた Jabber と 2台目のクライアントマシンで VPN 接続経由の Finesse デスクトップを実行するリモートエージェント。

- MRA 経由で接続されているラップトップで Jabber ソフトフォンを実行し、Xenapp シンクライアントとして Finesse デスクトップを実行するリモートエージェント。

Cisco Finesse の設計上の考慮事項

Cisco Finesse は、Contact Center Enterprise ソリューションで使用するスーパーバイザおよびエージェントのデスクトップです。Cisco Finesse サーバは VM 上にインストールします。クライアントは Cisco Finesse サーバを指し示す Web ブラウザを使用します。Cisco Finesse ソフトウェアはクライアントにインストールされません。これにより、インストールとアップグレードが簡素化され、その所要時間も短縮されます。

Cisco Finesse クライアント（管理コンソール、エージェント デスクトップ、スーパーバイザ デスクトップ）でサポートされるブラウザとオペレーティング システムについては、Contact Center Enterprise 互換性マトリクス を参照してください。

Cisco Finesse デスクトップ アプリケーションは、クライアントコンポーネントとサーバ コンポーネントから構成されています。クライアントは、OpenSocial 1.0 仕様に準拠するガジェットとして分散される標準の Web プログラミング要素（HTML、JavaScript）を使用します。シスコやサードパーティのガジェットを使用するように、レイアウト管理機能を使ってエージェント デスクトップを設定できます。

Cisco Finesse は Enterprise Mashup と呼ばれるアプリケーション クラスの一部です。Enterprise Mashup は、クライアント側のアプリケーションを結合する Web 中心のメソッドです。Cisco Finesse ガジェット ベースのアーキテクチャによって、クライアント側のマッシュアップが可能になり、より簡単に統合できるようになります。ガジェットのアップグレードは個別に処理されるので、バージョンの互換性の依存関係はわずかです。

Cisco Finesse 管理コンソールを使って、エージェントとスーパーバイザのデスクトップをカスタマイズすることができます。管理者は、デスクトップに表示するタブの名前を定義して、各タブに表示するガジェットを設定できます。

次の表は、Cisco Finesse の機能の要約です。

デスクトップの機能

デスクトップ機能

Cisco Finesse

デスクトップ チャット

可

チーム メッセージ

可

ブラウザ ベースのデスクトップ

可

カスタム開発

可（HTML や JavaScript などの標準の Web コンポーネントを使用）

デスクトップのセキュリティ

可

Note

Cisco Finesse は、各 PG ペアの最大 2000 エージェントに対して HTTPS をサポートします。

ワークフローの自動化

可

モバイル（リモート）エージェント

可

通話モニタリング

可

モニタ モードのアプリケーション

NA

アウトバウンド コール

可

Microsoft ターミナル サービスのサポート

NA

Citrix Presentation Server のサポート

NA

エージェントのモビリティ

可

エージェントのグリーティング

可

- Cisco Finesse REST API

- Cisco Finess エージェントデスクトップ

- Cisco Finesse スーパーバイザデスクトップ

- Cisco Finesse IP 電話エージェント

- Cisco Finesse 管理コンソール

- Cisco Finesse 展開に関する検討事項

Cisco Finesse REST API

Cisco Finesse は、クライアント アプリケーション向けの REST API を提供して、サポートされているサーバ機能にアクセスします。REST API は、HTTPS 経由で XML ペイロードをトランスポートします。

Cisco Finesse は、サードパーティの統合を支援する JavaScript ライブラリおよびサンプル ガジェット コードも提供しています。REST API、JavaScript ライブラリ、およびサンプル ガジェットの開発マニュアルは、https://developer.cisco.com/site/finesse/ のシスコ開発者ネットワークで確認できます。

Cisco Finess エージェントデスクトップ

エージェントデスクトップには次の追加設定なしの機能が備わります。

- 基本呼制御（通話への応答、保留、取得、終話、発信）

- 高度な呼制御（コンサルテーション、コンサルト後の転送、コンサルト後の会議）

- シングルステップ転送（エージェントは、最初にコンサルテーションコールを開始せずにコールを転送できます）

- キュー統計ガジェット（エージェントが割り当てられているキューに関する情報を表示）

- エージェントのコール履歴と状態履歴の表示

- 準備中およびサインアウトの理由コード

- 連絡先リスト

- ワークフロー

- モバイルエージェントのサポート

- Progressive、Predictive、Preview Outbound、Direct Preview Outbound

- デスクトップ チャット

- チーム メッセージ

Cisco Finesse スーパーバイザデスクトップ

Cisco Finesse スーパーバイザ機能により、エージェントデスクトップが拡張し、より多くのスーパーバイザ専用ガジェットが追加されます。たとえば、次のような機能があります。

- エージェントのステータスを表示するシステム アドミニストレーション ガイド ガジェット

- スーパーバイザのキューのキュー（スキルグループ）統計を表示するキュー統計ガジェット

- スーパーバイザコール履歴と状態履歴の表示

- スーパーバイザチーム内のエージェントのコール履歴と状態履歴を表示

- システム アドミニストレーション ガイド ガジェット（TPG）からのエージェントコール情報

- Unified CM のサイレント モニタリング

- 割り込み

- 代行受信

- エージェントの状態変更（スーパーバイザはエージェントをサインアウトでき、強制的に [準備中（Not Ready）] ステータスまたは [準備完了（Ready）] ステータスに変更できます）

Cisco Finesse IP 電話エージェント

Cisco Finesse IP Phone Agent（IPPA）を使用すると、エージェントは、ブラウザを介してではなく、Cisco IP 電話から Cisco Finesse 機能にアクセスできます。Cisco Finesse IPPA は、ブラウザで使用可能な Cisco Finesse 機能のサブセットのみを提供します。これにより、エージェントとスーパーバイザは、PC にアクセスせずに Cisco Finesse コールを受信および管理できます。

Note

スーパーバイザは、IP Phone 上でのみエージェントタスクを実行できます。Cisco Finesse IPPA は、モニタ、割り込み、代行受信などのスーパーバイザタスクをサポートしていません。

Cisco Finesse IPPA は次の機能をサポートしています。

- ログインおよびログアウト

- コール変数の表示

- 保留ステータス

- ラップアップの理由

- オプションの要約

- 準備中の理由

- 理由コードを使用したステータス変更

- ワンボタンサインイン

Cisco Finesse 管理コンソール

Cisco Finesse には、管理者が次を構成できる管理アプリケーションが含まれています。

- CTI サーバおよび Administration & Data サーバデータベースへの接続

- VOS 複製用のクラスタ設定

- 準備中およびサインアウトの理由コード

- ラップアップの理由

- 連絡先リスト

- ワークフローとワークフローアクション

- コール変数および ECC 変数レイアウト

- デスクトップのレイアウト

- Desktop Chat サーバの設定

- チームリソース

- Cisco Finesse IP 電話エージェント（IPPA）

理由コード、ラップアップの理由、連絡先リスト、ワークフロー、およびデスクトップレイアウトは、グローバルか（すべてのエージェントに適用）、特定のチームにすることができます。

Cisco Finesse 展開に関する検討事項

- Cisco Finesse とマルチライン機能

- Cisco Finesse と Citrix

- NAT およびファイアウォールを使用した Cisco Finesse

- IP Phone および IP Communicator のサポート

- Cisco Finesse と Cisco Jabber

- デスクトップ チャット

Cisco Finesse とマルチライン機能

Unified CCE がマルチライン用に構成されている場合、Cisco Finesse は、エージェント電話機での複数回線の構成をサポートします。エージェント電話機で複数の二次回線を構成できます。ただし、Cisco Finesse サーバは、二次回線での操作の応答で CTI サーバが送信するイベントをブロックします。Cisco Finesse サーバは、これらのイベントを Cisco Finesse クライアントに発行しません。二次回線上のコールに関する情報は、Cisco Finesse デスクトップには表示されません。

エージェントが 8900 シリーズまたは 9900 シリーズの電話機を使用している場合は、Unified CM 周辺機器でマルチラインを有効にします。この構成オプションは、周辺機器全体に適用されるオプションです。8900 シリーズまたは 9900 シリーズの電話機を使用する 1 つのエージェントに対してマルチラインを有効にする場合は、すべてのエージェントに対しても有効にします。

マルチラインをサポートするには、すべての電話機を次の設定で構成します。

- [Maximum number of calls] を 2 に設定します。

- 1.へのセットの使用中のきっかけ。

Cisco Finesse と Citrix

Contact Center Enterprise ソリューションは、Citrix 環境内での Cisco Finesse デスクトップの実行をサポートします。Cisco Finesse は、Citrix XenApp および XenDesktop をサポートします。

Note

AW、構成専用管理サーバ、および管理クライアントは、特定の VM 上で単一のリモートインスタンスとしてのみ動作できます。

サポートされるバージョンの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html の「互換性マトリックス」を参照してください。

NAT およびファイアウォールを使用した Cisco Finesse

一部のソリューションには、ネットワークアドレス変換（NAT）をインターコネクトする 2 つ以上の切り離されたネットワークがあります。

Cisco Finesse は、NAT に対するサポートが限定されています。Cisco Finesse は、Cisco Finesse サーバとクライアント間の基本的な NAT（1 対 1 の IP アドレスマッピング）をサポートします。

次の注意事項は、Cisco Finesse と NAT に適用されます。

- Cisco Finesse サーバとクライアントの間では、PAT/NPAT（ポートを使用する 1 対多アドレスマッピング）を使用できません。

- Cisco Finesse サーバおよび接続されている任意のサーバ間では、NAT は使用できません。

- Cisco Finesse IP Phone Agent（IPPA）は NAT をサポートしません。

Note

NAT とファイアウォールに関しては、ソリューションセキュリティの章を参照してください。

IP Phone および IP Communicator のサポート

Cisco Finesse は、Cisco IP ハードウェア電話機および Cisco IP Communicator ソフトウェア電話機の使用をサポートしています。

サポートされる電話機モデルおよび IP Communicator のバージョンの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html のソリューション向け「互換性マトリックス」を参照してください。

IP Phone およびサイレントモニタリング

サイレントモニタリングは、IP ハードウェア電話機と Cisco IP Communicator の両方をサポートします。

IP Phone およびモバイルエージェント

モバイルエージェント機能では、特定のタイプの電話機は不要です。この機能ではアナログ電話でも使用できます。

IP Phones および Citrix または MTS

Cisco Finesse は、Citrix または MTSの使用時に、IP ハードウェア電話機および Cisco IP Communicator の両方をサポートします。

このような環境では、エージェントデスクトップ PC に Cisco IP Communicator をインストールします。Citrix または MTS サーバに Cisco IP Communicator を展開することはできません。

Cisco Finesse と Cisco Jabber

Cisco Finesse は Contact Center Enterprise の音声エンドポイントとして Windows 版 Cisco Jabber をサポートしています。Cisco Finesse は次の Jabber 機能をサポートしています。

- 音声とビデオ

- サイレントモニタリングの組み込みブリッジ（BIB）

- IM and Presence

Note

エージェントは、Jabber を使用して通話を転送、または電話会議することはできません。エージェントは、転送や会議に Cisco Finesse デスクトップを使用する必要があります。

Cisco Finesse で Jabber を使用するには、デフォルトの Jabber 構成を次のように変更します。

- コールの最大数を 6 から 2 に変更します。

- ビジートリガーを 2 から 1 に変更します。

Jabber サポートの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html のソリューションに対する「互換性マトリックス」を参照してください。

デスクトップ チャット

デスクトップチャットは XMPP ブラウザベースのチャットであり、これは Cisco Instant Messaging and Presence（IM & P）サービスによって提供されます。デスクトップチャットを使用すると、エージェント、スーパーバイザは、組織内の各分野の専門家（SME）とチャットを行うことができます。

詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.htmlを参照してください。

インスタントメッセージングおよびプレゼンス（IM&P）は、Unified CM プラットフォーム内でプレゼンスおよびチャット機能を提供します。デスクトップ チャット インターフェイスは、Finess エージェントデスクトップにホストされ、個別に IM&P サービスにログインする必要があります。

Note

Release 12.5 (1) からの HCS 展開では、デスクトップチャットユーザ検索に、デフォルトでは LDAP のすべてのユーザが表示されます。この検索を調整して、エージェントまたはスーパーバイザが検索を開始した対応するカスタマーのユーザを、Cisco Unified Communications Manager IM and Presence Service で定義されている組織ユニット（OU）に基づいて表示できます。これは Cisco Unified Communications Manager IM and Presence Service、リリース 12.5(1)SU2 ES ビルドバージョン 12.5.1.12900-26 以降でサポートされています。詳細については、Cisco TAC にお問い合わせください。

デスクトップチャットでは、Cisco Mobile Remote Agent /VPN ベースの IM&P サーバへのアクセスはサポートされていません。デスクトップチャットでは、チャットサーバに接続する IM&P サーバへのダイレクトアクセスが必要となります。

詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html にある『Cisco Finesse アドミニストレーション ガイド』の「Desktop Chat サーバの設定」の項を参照してください。

- シスコ インスタント メッセージングおよびプレゼンス（IM&P）

シスコ インスタント メッセージングおよびプレゼンス（IM&P）

IM&P は Jabber プラットフォームを組み込み、XMPP プロトコルをサポートし、複数のデバイスを介してユーザのプレゼンスを追跡できます。IM&P は、チャット機能が有効になっているユーザそして、Unified CM（LDAP 統合が有効である場合は、LDAP から）からユーザリストをプルします。チャット機能が有効になっている Unified CM ユーザのみ IM&P にログインできます。

Cisco IM&P は、高可用性を実現するためにクラスタ化された展開の複数の形式をサポートします。Finesse は、特定のエージェント PG で構成されます。このエージェント PG は、特定の IM&P クラスタに関連付けられた Unified CM に接続されます。Finesse を IM&P クラスタに接続するよう構成します。

アイデンティティ、プレゼンス、Jabber

ユーザは、IM&P で識別され、これは、username@FQDN.com 形式の固有のアイデンティティです。

Unified CCE では、アイデンティティが Unified CCE で設定されたユーザ名または peripheralID と同じではありません。

ユーザは、ユーザ ID、プレゼンスステータス（使用可能、使用不可、またはビジー）、およびユーザのプレゼンス機能の観点から説明されます。

ユーザのプレゼンスステータスは、エージェントステータスとは関係なく、ユーザのポストログインによって個別に管理される必要があります。

Cisco IM&P サービスは、複数のデバイスでユーザのプレゼンスステータスを組み合わせ、連絡先リストに連絡先を追加したサブスクライバに公開します。

IM&P は、エージェントがログインしているすべてのデバイスの状態マトリックスから導出される、ユーザの構成されたプレゼンスをサポートします。Cisco IM&P は、ユーザに対する XMPP クライアントからのプレセンスの送信元を、CUCM からオンホック、およびオフホックステータスを、Microsoft Exchange から会議中ステータスを取得し、ユーザの全体的な構成されたプレゼンスを生成します。デスクトップチャットでは、構成されているユーザのプレゼンスが表示されます。構成されたプレゼンスの到達方法に関しては、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-user-guide-list.html の『Cisco IM&P ユーザガイド』を参照してください。

展開ガイドに関係なく、デスクトップチャットは、Finesse デスクトップにログイン後、ユーザの IM&P アイデンティティを使用して明示的なログインをする必要があります。

SSO はデスクトップチャットではサポートされていないため、SSO モードでは明示的なログインが必要です。

デスクトップチャットのプレゼンスは、設定されているデバイス間で通信できるユーザの存在を示しています。

デスクトップチャットの可用性は、ユーザの統合された IM&P プレゼンスにも反映します。

デスクトップチャットにログインすると、デフォルトで、ユーザのステータスは利用可能に設定されます。

デスクトップチャットにログインするエージェントは、Jabber または IM&P に接続されている XMPP プラットフォームでは利用可能として見られ、該当ユーザと連絡を取り合うことができます。

Note

ファイル転送は、デスクトップチャットを使用したユーザ間の通信でのみサポートされています。サポートされているファイルタイプおよび添付ファイルの最大サイズに関する詳細は、『Cisco Unified Contact Center Express Administration and Operations Guide』の「デスクトッププロパティ CLI」項を参照してください。

デスクトップチャットの可用性の例

デスクトップチャットユーザは、デスクトップチャットと Jabber に同時にログインできます。着信チャットは、デスクトップチャットを含む、ログインしているすべてのクライアントにリレーされます。ただし、デスクトップチャットではマルチデバイス メッセージングがサポートされていません。そのため、Jabber などの他の XMPP クライアントから送信されたメッセージはデスクトップチャット内に表示されません。代替クライアントが着信チャットへの応答に使用されると、ユーザがデスクトップチャットを使用して応答を開始するまで、後続メッセージはデスクトップチャットに表示されません。

ネットワーク設計に関する詳細は、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の『ソリューション リファレンス ネットワーク設計 ガイド』を参照してください。

- Cisco IM&P 設計上の考慮事項

- Cisco IM&P 展開に関する考慮事項

- Desktop Chat サーバの設定

Cisco IM&P 設計上の考慮事項

Finesse サーバからのチャットサーバ URI を取得すると、Finesse ブラウザによって HTTP を介して Cisco IM&P に個別に接続することができるようになります。HTTPS 導入で自己署名証明書を使用する場合は、別個の証明書を受け入れる必要があります。

チャットの相互作用は、XMPP プロトコルを介して、長期ポーリングを使用した HTTP 接続、または、Cisco IM&P で確立された BOSH で発生します。

Cisco IM&P サーバ構成の取得以外では、チャット関連の機能に対する Finesse サーバおよびブラウザ間の通信はありません。

チャットログの持続は、デスクトップセッション中にブラウザで利用できます。

ユーザ検索機能には、Unified CM LDAP 統合が必要です。それがない場合、リモートの連絡先はユーザが手動で追加する必要があります。

ユーザが、既存の Jabber ユーザの場合、デスクトップチャットおよびセッションで維持される Jabber 間で同じ連絡先が共有されます。

Cisco IM&P で推奨さ入れている制限やガイドライン以外で、デスクトップチャットでの進行中のチャットや連絡先の数には制限はありません。進行中のチャットや連絡先の数に対する制限、およびチャット向けの Cisco IM&P サーバの構成方法に関しては、『IM&P ソリューション リファレンス ネットワーク ガイド』を参照してください。

Note

デスクトップチャットでは、信頼する Cisco IM and Presence の証明書が必要です。証明書の受け入れ方法の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-user-guide-list.html の『Cisco Unified Contact Center Express 向け Cisco Finesse エージェントおよびスーパーバイザユーザガイド』の「一般的なタスク」章にある「セキュリティ証明書の承認」項を参照してください。

Cisco IM&P 展開に関する考慮事項

Finesse は、Cisco Finesse Administration インターフェイスを介してプライマリおよびセカンダリ IM&P チャットサーバを構成します。

デスクトップチャットは、構成済みサーバの接続し、ユーザに対して構成された適切な IM&P ノードを自動的に検出し、IM&P 内の適切なノードに接続します。この解決は、ユーザがブラウザのキャッシュをクリアするまで、チャットが初めてロードされ、その後同じノードを使用するときにのみ実行されます。

Note

デスクトップチャットは、Jabber とは異なり DNS_SRV* レコードを使用しません。また、ネットワーク構成に基づいて自動的に構成されません。チャットサーバの検出には、管理ページからの明示的なチャット URI 構成が必要です。

Cisco IM&P 展開の詳細については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/presence.html の『Unified CM ソリューション リファレンス ネットワーク設計ガイド』を参照してください。

次の詳細に関しては、『Cisco Unified Communications Manager 上の IM および Presence サービスの構成および管理ガイド』を参照してください。

- IM&P サービスのインストールおよび構成方法。

- IM&P を構成し、エンドユーザに対してチャットサービスを有効にする方法。

- クラスタと高可用性展開の構成方法。

- IM&P フェデレーションの構成方法。

Desktop Chat サーバの設定

デスクトップ チャットは XMPP ブラウザ ベースのチャットであり、これは Cisco Instant Messaging and Presence（IM & P）サービスによって提供されます。Unified CM プラットフォーム内にプレゼンスおよびチャット機能を提供します。詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html の「IM and Presence Service の構成と管理」を参照してください。

デスクトップチャットは、エージェントデスクトップをホストしているブラウザからポート 5280 経由で Cisco IM&P サーバに接続します。クライアントがこの機能を使用する場合は、IM&P サーバの可視性およびポートへのアクセス性を確保する必要があります。デスクトップ チャット ガジェットは、BOSH HTTP を介して IM&P サーバと通信するためにデスクトップが使用する IM&P ホスト BOSH URL を構成します。

IM＆amp; P はクラスタ化された設計であり、ユーザはクラスター内の複数のノードに分散されます。デスクトップチャットはまず、ユーザが構成した IM&P ノードを検出し、この情報をキャッシュし、ブラウザのキャッシュがクリアされるまで、後続のログインの実際のサーバと通信します。最初の検出負荷を分散するには、展開に 1 つ以上の Finesse クラスタがある場合、ラウンドロビンでノードを構成することをお勧めします。たとえば、IM&P ノードが 5 つある場合は、ノード 1 と 2 で Finesse クラスタ A を構成し、ノード 3 と 4 で Finesse クラスタ B を構成します。

IM&P URL を構成する一方で、ノードを利用できるよう考慮する必要があります。セカンダリノードは、最初のノードが到達不可能なシナリオで利用できます。セカンダリノードは、プライマリノードが到達不能な場合にのみ、検出のために接続されます。

構成する URL については、『システム、サービスパラメータ』の「Cisco Unified Presence」を参照してください。必要な IM&P サーバを選択し、Cisco XCP Web 接続マネージャーを選択します。[HTTPバインドパス（HTTP Binding Path）] フィードバックに、URL バインドパスが一覧されます。Finesse で構成する完全な URL は https://<hostname>:5280/URL-binding-path です。

Desktop Chat サーバの設定を使用して、Finesse デスクトップのチャットを構成します。次の表に、Desktop Chat サーバ設定ガジェットのフィールドを示します。

フィールド

説明

プライマリチャットサーバ

デスクトップチャットの IM&P プライマリサーバ の URLを入力します。

セカンダリチャットサーバ

デスクトップチャットの IM&P セカンダリサーバ の URLを入力します。

デスクトップ チャット サーバ ガジェットでのアクション

- [保存（save）]：構成変更を保存します

- 元に戻す： 直近に保存されたサーバ設定を取得します

Important

デスクトップチャットが問題なく動作する場合は、次のサービスが IM&P 上で実行されている事を確認してください。

- Cisco Presence Engine

- Cisco XCP Text Conference Manager

- Cisco XCP Web Connection Manager

- Cisco XCP Connection Manager

- Cisco XCP Directory Service

- Cisco XCP Authentication Service

- Cisco XCP File Transfer Manager

Note

ブラウザによって自動的に信頼されない証明書で Cisco IM and Presence が構成されている場合、Finesse デスクトップへのサインイン中にセキュリティ証明書を受け入れるプロンプトがユーザに表示されます。証明書を受け入れるプロンプトが必ず表示されるのを避けるために、ユーザは、証明書をブラウザの信頼ストアに追加するか、CA で署名された証明書を使用して IM and Presence を構成するか、サポートされているブラウザのグループポリシーを通じて自己署名証明書をプッシュする必要があります。

Note

デスクトップチャットは、IM&P の無制限バージョンではサポートされません。

デスクトップ チャット検索

Note

Cisco Finesse でこの機能を有効にするには、Finesse 12.0(1) ES4 COP 以降をインストールします。

デフォルトでは、デスクトップチャットユーザ検索には LDAP のすべてのユーザが表示されます。この検索を調整して、エージェントまたはスーパーバイザが検索を開始した対応するカスタマーのユーザを、Cisco Unified Communications Manager IM and Presence Service で定義されている組織ユニット（OU）に基づいて表示できます。これは Cisco Unified Communications Manager IM and Presence Service、リリース 12.5(1)SU2 ES ビルドバージョン 12.5.1.12900-26 以降でサポートされています。詳細については、Cisco TAC にお問い合わせください。

Cisco Unified Communications Manager IM and Presence Service では、管理者が [クライアントユーザ（Client User）] フィールドを [検索可能なLDAP属性（Searchable LDAP Attributes）] テーブルの [適切なLDAPユーザ（Appropriate LDAP User）] フィールドにマップする必要があります。

検索可能な LDAP 属性（[クライアント（Client）] フィールドと [LDAP] フィールド間の属性マッピング）

設定は、選択した LDAP サーバのタイプによって異なり、LDAP サーバの各論理的なエンティティと完全に一致する必要があります（たとえば、姓、名、氏名など）。XMPP ユーザ検索を行うには、次のようにして各クライアントユーザを [LDAP] フィールド属性にマッピングします。

- Active Directory は、[クライアントユーザ（Client User）] フィールドと [LDAPユーザ（LDAP user）] フィールドのデフォルト値を提供します。使用している構成に合わせて、必要に応じて各フィールドを編集できます。

- 汎用ディレクトリサーバは、デフォルト値を提供しません。XMPP ユーザ検索を行うには、各 [クライアントユーザ（Client User）] フィールドにマッピングする LDAP 属性を指定する必要があります。

クライアントから LDAP へのフィールド属性マッピングのサンプル

クライアントユーザフィールド

LDAPユーザフィールド

OU

ou

ラストネーム（姓）

sn

fullname

cn

uid

sAMAccountName

サードパーティの XMPP クライアントの LDAP 検索設定の詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html の『IM and Presence Service の構成及び管理』に記載されている「LDAP ディレクトリ統合」章を参照し、検索可能な LDAP 属性に関しては、『IM and Presence Service オンラインヘルプ』を参照してください。

CLI コマンドを使用して、Cisco Finesse でのデスクトップチャット OU 検索を構成します。CLI コマンドの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html の「Cisco Finesse アドミニストレーション ガイド」に記載されている『デスクトップのプロパティ』項を参照してください。

Cisco Unified Intelligence Center の設計上の考慮事項

- Unified Intelligence Center の展開

- Unified Intelligence Center Reporting ノード

- Unified Intelligence Center データソース

- WAN 展開での Unified Intelligence Center

- Unified Intelligence Center Administration

- 履歴レポートおよび リアルタイムレポートのスロットリング

Unified Intelligence Center の展開

Unified Intelligence Center の展開は、次の要素で構成されています。

- クラスタ内の 1 つ以上の Unified Intelligence Center レポート（メンバー）ノード

- リアルタイムおよび履歴データソース

- ライブデータソース

- その他オプションのデータソース

Note

Unified Intelligence Center とデータソースサーバが同じ NTP サーバと同期中であることを確認してください。

Unified Intelligence Center ノードは、Contact Center Enterprise ソリューションのスタンドアロン VM に展開されます。Unified Intelligence Center は、履歴レポート、リアルタイムレポート、ライブデータレポートをサポートしています。

履歴レポートまたは リアルタイムレポートのデータフローは、次のように実行されます。

1. Web クライアントは、Unified Intelligence Center の 履歴レポートまたは リアルタイムレポートに対して HTTPS 要求を行います。

2. Unified Intelligence Center レポートノード上の Web サーバが要求を受信します。

3. レポートノードは、データソースサーバからレポートデータをプルします。

4. レポートノードは、Web サーバを介してレポートを Web クライアントに送信します。

Unified Intelligence Center の展開

クライアントは、Live Data サービスの Live Data イベントストリームから ライブデータレポートを更新します。ライブデータ制御とデータフローの詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の Cisco Unified ICM/Contact Center Enterprise サービスアビリティ ベスト プラクティス ガイド を参照してください。

Unified Intelligence Center Reporting ノード

レポートノードは Unified Intelligence Center の中核であり、レポート用のすべての機能が備わっています。レポートノードは、以下の構成で展開できます。

- コントローラノード上のスタンドアロン レポート ノード

- クラスタ内に最大 7 つのレポートメンバーノードを含むコントローラノード

レポートノードには、次のアプリケーションが含まれます。

- ファイアウォール

- Unified Intelligence Center アプリケーションを実行する Web サーバ

- Web リクエストを HTML に変換する JAVA サービスおよび JSP ページ

- クラスタ内での複製をサポートする Unified Intelligence Center Database（Informix）

- 管理（OAMP）アプリケーション（発行元ノード上）

Unified Intelligence Center Database（Informix）

各レポートノードには、Unified Intelligence Center アプリケーションデータベースが含まれます。Unified Intelligence Center データベースは、Unified Intelligence Center レポート Web アプリケーションの主要データストアです。クラスタ内の各ノードのユーザ、レポート、およびユーザアクセス権関連の構成情報が保持されています。

Unified Intelligence Center クラスタでは、各データベースサーバは他のすべてのデータベース サーバに接続します。データは、任意のサーバから他のすべてのサーバにすぐに複製されます。

日次自動削除は、午前 0 時に実行され、データベースのメンテナンスアクティビティを処理します。必要に応じて、削除スケジュールを変更できます。削除とバックアップは、ローカルの Unified Intelligence Center データベースの唯一のローカル データベースメンテナンス タスクです。

Unified Intelligence Center データソース

Unified Intelligence Center は、次のデータソースをサポートしています。

- リアルタイムレポートおよび 履歴レポート用の Microsoft SQL ベースまたは Informix データソース。SQL ベースのデータソースは、有効な JDBC 対応データベースであり、レポートデータを格納するスキーマです。

- ライブデータレポートに対するストリーミングデータソース

これらデータソースサーバは、以下のレポートをサポートします。

- Cisco Finesse ガジェットに表示されるレポートを含む、Contact Center Enterprise レポート。

- インポート可能な Unified CVP レポート

- Customer Collaboration Platform レポート

- ビジネス チャットおよび E メール reports

Unified Intelligence Center アーキテクチャ

- Unified Intelligence Center のライブデータ

- データソースとしての Administration & Data サーバ

- データソースとしての Unified CVP

Unified Intelligence Center のライブデータ

Unified CCE は、WebSockets を介してエージェント、スキルグループ、およびコールタイプステータスでリアルタイムの更新を公開します。Unified Intelligence Center レポートは、これらのメッセージをライブデータサービスから直接消費し、リアルタイムで更新を表示します。

Unified CCE では、ライブデータサービスは独自の VM 上に存在します。

ライブデータレポートは、Unified Intelligence Center レポートビューアで実行できます。Cisco Finesse デスクトップでは、ガジェットに ライブデータレポートを表示できます。Cisco Finesse デスクトップの親コンテナからライブデータサービスの 1 つまで WebSocket トンネルを使用します。ガジェットは、ロード中にトンネルを作成します。

WebSocket 接続に障害が発生すると、ライブデータレポートは、現在接続されている Live Data ノードに自動的にフェールオーバーします。

次の図は、Contact Center Enterprise 展開における ライブデータレポートのアーキテクチャを示しています。

Contact Center Enterprise の ライブデータレポート

データソースとしての Administration & Data サーバ

Unified Intelligence Center の株価レポートでは、データソースとして Administration & Data サーバを使用します。Contact Center Enterprise 展開では、複数の Administration & Data サーバを使用できます。Unified Intelligence Center は、データベースとそのビューをデータソースクエリのテーブルとして使用します。

Unified Intelligence Center をインストールすると、レポート（メンバー）ノードに 2 つのデータソースが追加されます。

- 履歴データソースは、履歴レポートとユーザ統合にデータを提供します。

- リアルタイムデータソースは、リアルタイムレポートにデータを提供します。

展開では、両方のデータソースに同じ AW-HDS を使用できます。また、データソースごとに異なるサーバを構成することもできます。Unified Intelligence Center では、標準規格の 履歴レポートのデータソースとして AW-HDS が必要です。ただし、標準規格の リアルタイムレポートにはデータソースとして AW を使用できます。Unified Intelligence Center では、TCD レコードに関するカスタムレポートのデータソースとして AW-HDS-DDS または HDS-DDS が必要です。

履歴レポートと リアルタイムレポート用の Unified CCE を使用した Unified Intelligence Center の展開

データソースとしての Unified CVP

Unified CVP からレポートをインポートする展開の場合、Unified Intelligence Center は、データソースとして CVP コールサーバを使用します。

CVP コールサーバはレポーティングサービスを提供し、IBM Informix Dynamic サーバ（IDS）データベース管理システムをホスティングします。データベースのスキーマを使用すると、データベースに対してカスタムのレポートを作成できます。ソリューションには、複数の CVP コールサーバを含めることができます。

Unified Intelligence Center は、CVP コールサーバにのみ接続します。CVP コールサーバは、他の Unified CVP サブコンポーネントと Unified Intelligence Center 間を仲介します。

WAN 展開での Unified Intelligence Center

Unified Intelligence Center クラスタは、WAN 上で分散できます。クラスタ内の各ノードには、他のすべてのノードへの接続が必要です。クラスタ内では、LAN または WAN を使用して、一方のノード上に作成された構成定オブジェクトは、他のノードに自動的に複製されます。複製では、WAN 全体の帯域幅が使用されます。ただし、構成オブジェクトを作成する頻度は低いため、レポートを実行するよりも WAN 帯域幅に影響を与える頻度が低くなります。

オブジェクトは、ローカルノード上で即座に利用可能なユーザになります。オブジェクトが他のノードに複製されるまで数秒かかる場合があります。複製用の WAN 帯域幅は、クラスタの構成によって異なります。

サイト組織

Unified Intelligence Center クラスタは、最大で 8 つのノードを保持できます。完全な冗長クラスタリングを保持するには、ノードの数は最大 4 つです。資格がある場合、各Unified Intelligence Center は、標準規格のレポートプロファイルで、最大 200人のレポートユーザをサポートします。クラスタ内では、最大 8 つのノードを持つこともできますが、レポートユーザの最大数に関するリファレンス設計上の考慮事項制限を超えることはできません。

プライマリ（コントローラ）ノードはプライマリサイトにあります。プライマリノードは、次のサービスをホストします。

- 管理アプリケーション

- スケジューラ

WAN 障害

各 Unified Intelligence Center ノードは、複製データをバッファし、クラスタ内の他のノードに送信します。切断中、別のノードへの接続が復元されるまでノードは、データをキューに入れます。各ノードは、接続障害が発生した場合でも、個別に動作し続きます。キューは最大 1600 MB を保持します。バッファ消費の前に接続が復元された場合、ノードはキューに入っているデータの量と接続帯域幅に比例した速度で同期します。

ノードがバッファ消費に近い場合、アラームが送信されます。バッファが使い果たされる前に接続が復元されなかった場合、複製がリセットされます。復元をリセットすることで、ノードは、引き続きレポートを実行し、個別に動作します。複製をリセットするセカンダリノードでは、プライマリノードとの再接続後、プライマリノードとの完全同期（プライマリデータベースのバックアップとセカンダリノードでの復元）が必要です。複製がリセットされると、セカンダリノード上に作成または変更されたすべてのオブジェクトがプライマリデータベースの状態にロールバックされます。

プライマリノードに障害が発生した場合は、再インストールして保存済みバックアップに戻します。データ損失を回避するために、プライマリノードを定期的にバックアップします。

データ複製の詳細については、『Cisco Unified Intelligence Center 向け管理コンソールユーザガイド』を参照してください。

Unified Intelligence Center Administration

Unified Intelligence Center Administration サーバは、運用、管理、メンテナンス、プロビジョニング（OAMP）機能を提供します。Administration サーバは、Unified Intelligence Center クラスタでデバイスを構成およびプロビジョニングするためのプライマリインターフェイスです。クラスタ内のプライマリ（コントローラ）ノードで管理機能を展開しアクセスします。

Cisco Unified Intelligence Center は、アプリケーション クラスタリングに Hazelcast を使用します。Hazelcast は、Unified Intelligence Center アプリケーション層にセカンドレベルのキャッシュを提供します。Hazelcast がキャッシュしたエンティティ（例：レポート、レポート定義など）を、Unified Intelligence Center ノードで更新する際は、クラスタ内の別のすべての Unified Intelligence Center ノードで、エンティティを無効にし、再ロードする必要があります。Hazelcast クラスタは、該当する無効なエンティティなどの識別子を含むクラスタ全体の通知を発行することで、自動的に該当するクラスタをケアします。

Unified Intelligence Center では、Hazelcast クラスタの検出または情報に対するデフォルトメカニズムは、UDP マルチキャストです。Unified Intelligence Center は、マルチキャストグループの IP アドレス 224.2.2.3 および ポート 54327 を使用します。これら設定は、Unified Intelligence Center では変更できません。

次のシナリオでは、UDP マルチキャストベースの検出メカニズムはカスタマーには機能しません。

- ネットワークでマルチキャストが無効化されている場合。

- Unified Intelligence Center クラスタ内のノードが異なるサブネット内にある場合。

このようなシナリオでは、検出メカニズムを TCP/IP に変更できます。デフォルトの UDP マルチキャストベースの検出メカニズムではなく、TCP/IP を使用して CUIC アプリケーションクラスタを形成できます。

管理機能および Hazelcast を使用したクラスタ構成の詳細に関しては、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-intelligence-center/products-maintenance-guides-list.html の Cisco Unified Intelligence Center 管理コンソール ユーザ ガイド を参照してください。

Note

管理アプリケーションは、ネットワーク オプション、証明書、アップグレード、SNMP およびアラート設定などのシステムレベルの機能には使用しないでください。

履歴レポートおよび リアルタイムレポートのスロットリング

Unified Intelligence Center のスロットリングメカニズムにより、サーバが極端な負荷の下でメモリ切れ状況で凍結したり、その状況に直面するのを防ぎます。

Note

サイジングの目的でスロットリングメカニズムを使用しないでください。スロットリングメカニズムは、メモリ切れ状況を回避するのみ使用します。スロットリングは、高品質のサービスを保証するものではありません。導入が過剰に使用されている場合、スロットリングメカニズムがアクティブ化される前に、サービスレベルが大幅に低下する可能性があります。

ソリューションに適したレポートリソースを判断するには、常にサイジングツールを使用します。

レポートデータの処理は、Unified Intelligence Center で最もメモリを消費します。スロットリングメカニズムは、レポートアクティビティによるメモリ消費を制御します。

Unified Intelligence Center は、レポート行を通じてレポートアクティビティを測定します。レポートアクティビティのこの測定により、柔軟性が得されます。いくつかの大規模レポートまたはたくさんのの小規模レポートを実行できます。スロットリングメカニズムも調整なしで効果を発揮します。

Unified Intelligence Center は、レポート行を通じてレポートアクティビティを測定します。レポートアクティビティのこの測定により、柔軟性が得されます。いくつかの大規模レポートまたはたくさんのの小規模レポートを実行できます。スロットリングメカニズムも調整なしで効果を発揮します。

ストックレポートを使用したテストでは、2 KB がレポート行のサイズに対する保守的な推定値であるという結果が示されています。その推定値に基づいて、Unified Intelligence Center サーバは、サーバがメモリを使い切る前に、最大 250,000 レポート行をメモリにロードできます。

この制限を適用するために、各 Unified Intelligence Center は、現在メモリにロードされているレポート行の数を保持します。すべてのレポート操作は、その数を確認して、メモリにさらにレポート行がロードできるかを判断します。制限に達すると、レポート操作は失敗し、次のようにエラーが表示されます。

- データソースからデータをフェッチする際の侵害 — レポート実行のキャンセルまたは失敗としてレポートをマークします。Unified Intelligence Center では、部分的な結果を取得しません。システムは、要求に関するすべてのデータを読み取るか、レポートに失敗のマークを付けるか、すべてのデータを保存しません。

- ブラウザ の HTTPS 応答準備中の侵害 — Unified Intelligence Center はディスプレイリクエストを拒否します。サーバのリソースが低く、レポートをレンダリングできない旨が記載されたエラーメッセージが表示されます。

リファレンス設計とトポロジ設計に関する考慮事項

- Unified CM SME の展開

- グローバル展開に関する検討事項

Unified CM SME の展開

Cisco Unified Communications Manager Session Management Edition（Unified CM SME）は、ダイヤルピア設定機能またはアグリゲータとして Unified CVP と統合し、Contact Center Enterprise ソリューション内の複数の Unified CM クラスタに接続します。

Unified CM SME をバック ツー バック ユーザ エージェントとして構成します。複数の Unified CM クラスタのアグリゲータとして、ダイヤルプランに基づいてコールを適切なクラスタにルートします。

次の図は、Unified CM SME の導入を示しています。

Unified CM SME の展開

Unified CM SME は高可用性をサポートしていないので、シングルポイント障害です。Unified CM SME でのネットワーク接続またはコンポーネントの障害の影響を最小限に抑えるために、これらの設計ポイントを検討してください。

- Unified CVP の出力側で Unified CM SME を冗長クラスタ モードで展開します（少なくとも 1+1 のパブリッシャ サブスクライバ）。

- ゲートウェイと CUBE でセッション更新およびセッションタイマーを構成します。この構成では、ゲートウェイからのコールセッションがクリアされ、Unified CM SME に障害が発生した場合に Unified CVP コールサーバポートがリリースされます。

- Unified CM SME に障害が発生した場合、顧客がコールをドロップした後、すべての コールサーバポートがクリアされます。

Note

Unified CM SME に障害が発生した場合、コール補足サービスはすでに確立されているコールでは機能しません。

Unified CM SME へのネットワーク接続に瞬間的な障害が発生すると、次の制限が適用されます。

- 瞬間的な接続障害が発生しエージェントが終話した場合、Unified CM SME はコールをクリアしません。このため、キャッシュされた古いエントリとポートが Unified CVP アプリケーションで切断します。この場合、発信者はコールを破棄して、古いキャッシュされたエントリをクリアする必要があります。

- コールはエージェントデスクトップからクリアされません。また、エージェントは着信コールを受信できません。エージェントは通話状態のままで、デスクトップからコールをクリアすることはできません。このような場合は、電話機から手動でコールをクリアします。

- コールのクリアが遅れると、コールレポートデータには、通話時間と理由コードに関する不適切な詳細が反映される場合があります。

Unified CM SME の構成については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.html のサイトにある『Cisco Unified カスタマー音声ポータル用構成ガイド』を参照してください。

グローバル展開に関する検討事項

- メイン サイト および リモート サイト 間の最長ラウンドトリップタイム（RTT）は、400 ミリ秒に制限されています。

- サイド A コンポーネントと サイド B サイト 間の最長 RTT は、80 ミリ秒に制限されています。

Note

ポスト コール調査を使用する場合、セントラルサイトとリモートサイト間で、最大 12 台の Unified CM PIM を組み合わせることができます。

- CVP メディアサーバのホスト名を使用して、ローカル CVP サーバをポイントする IOS ゲートウェイを構成します。

- グローバル展開のための UCS ネットワーク設計

- 分散型展開でのコール存続可能性

グローバル展開のための UCS ネットワーク設計

この図は、パブリックネットワークとプライベートネットワーク通信の要件を満たすようにグローバル展開ス地裁のデフォルト設計を示しています。メイン サイト は USB B シリーズブレードを、リモート サイト は UCS C シリーズサーバを使用します。

グローバル展開用の UCS ネットワークリファレンスの設計

分散型展開でのコール存続可能性

分散型の導入では、ブランチの他の音声サービスの設計ガイドラインが必要です。たとえば、ACD エージェントと非エージェント電話の両方をサポートするリモート Unified CM サイトであるブランチがあるとします。この導入では、PSTN ゲートウェイが処理するのは、Unified CVP のイングレスコールだけではありません。また、通常の非 ACD 電話に対してイングレスコールとイーグレスコールも処理されます。

WAN のブランチの信頼性は、通常 LAN リンクよりも信頼性が低いため、中央集中型の Unified CVP モデルでは問題になる可能性があります。Unified CVP コールと非 CVP コールのどちらの場合も、コール存続可能性機能を考慮する必要があります。Unified CM エンドポイントの電話の場合、存続可能性は Survivable Remote Site Telephony（SRST）という Cisco IOS 機能を使用して実現されます。

Unified CVP コールの場合、TCL スクリプト（survivability.tcl）からのサービスと SRST 関数の組み合わせがコール存続可能性を処理します。存続可能性 TCL スクリプトは、リモートゲートウェイからのすべての入力コールの SIP 接続をモニタします。シグナリング障害が発生した場合、TCL スクリプトはコールを制御し、設定可能な宛先にリダイレクトします。TCL スクリプトの接続先の選択肢は、Cisco IOS ゲートウェイ構成でパラメータとして構成定します。

Note

着信番号が「E164」フォーマットの場合、存続可能性スクリプトは Unified CVP に着信番号を転送する前に着信番号から「+」記号を削除します。Unified CVP または ICM は、DNIS の先頭にある「+」サインインをサポートしません。

この転送の代替接続先には、別の IP 接続先（リモートサイトの SRST コールエージェントを含む）、コールの再起動、新しい接続先でのコールの再起動、*8 TNT、またはフックフラッシュが含まれます。リモートサイトの SRST コールエージェントに転送する場合、最も一般的なターゲットは SRST エイリアスまたは 基本 ACD ハントグループです。

音声メールおよび録音サーバは、Real-Time Control Protocol（RTCP）パケットを、発信者（TDM 音声ゲートウェイ）に逆方向に送信しません。これにより、存続可能性スクリプトのメディア非アクティブタイマーが誤ってトリガーされる可能性があります。survivability.tcl スクリプトは慎重にダイヤルピアに適用することが重要です。音声メールまたは録音要素にコールが送信された場合、コールはドロップする場合があります。1 つの方法は、音声メールまたは録音コールに別個のダイヤルピアを使用し、これらのダイヤルピアには Unified CVP 存続可能性スクリプトを関連付けないことです。もう 1 つは、音声メールまたは録音ダイヤルピアに関連付けられている存続可能性スクリプトでメディア非アクティビティを無効にする方法です。

これら転送方法の構成と適用に関しては、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.html の Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

Note

シグナリング障害で代替ルーティングを活用するには、Unified CVP をポイントしているすべてのゲートウェイで存続可能性サービスを使用します。このサービスの使用を妨げる特定の実装を利用しない限り、必ずこのサービスを使用してください。

存続可能性サービスが Unified CVP からの REFER メッセージを処理し、Unified CVP 包括コールフローで SIP REFER を使用する場合、ルータ再クエリーはサポートされません。Cisco IOS が存続可能性サービスなしで REFER を処理する場合、または Unified CM が REFER を処理する場合、他のコールフローは REFER を使用したルータの再クエリをサポートできます。サードパーティ製の SIP トランクの場合、REFER を使用したルータ再クエリーのサポートは、SIP REFER 自体の実装とサポートによって異なります。

オプションのシスココンポーネント設計上の考慮事項

- Customer Collaboration Platform 設計の考慮事項

- Unified SIP プロキシ設計上の考慮事項

- Enterprise Chat and Email の設計上の考慮事項

- サイレント モニタリングの設計上の考慮事項

Customer Collaboration Platform 設計の考慮事項

大規模なシングルサーバとしてCustomer Collaboration Platform を展開します。Customer Collaboration Platform は、高可用性の目的で冗長トポロジをサポートしません。

「イントラネット」および「インターネット」のトポロジの企業ファイアウォールの内外にサーバを展開できます。

- イントラネット トポロジは、ネットワーク ファイアウォールのセキュリティを強化して、外部パーティによりシステムがアクセスされるリスクを軽減します。Customer Collaboration Platform が、内部フォーミュラサイトなどの内部フォーミュラにアクセスする際に、このトポロジを使用します。

イントラネット トポロジを使用するとプロキシ構成が複雑になりますが、ディレクトリの統合はシンプルになります。

- インターネットトポロジは、ネットワーク ファイアウォール外に Customer Collaboration Platform を配置します。これは、Customer Collaboration Platform アプライアンスのビルトインされたセキュリティキャパシティに依存しています。

このトポロジのセキュリティを許容するかどうかは、システムの使用方法および会社のポリシーによって決ます。

インターネット トポロジでは、ディレクトリの統合が複雑になる可能性があります。

Customer Collaboration Platform を展開すると、ユーザの一部は、ファイアウォールまたはプロキシを介してサーバにアクセスできます。

Customer Collaboration Platform 管理 UI アクセス

デフォルトでは、Customer Collaboration Platform 管理ユーザインターフェースへのアクセスは制限されています。管理者は、クライアントの IP アドレスをホワイトリストに登録してアクセスを提供し、ホワイトリストからクライアントの IP を削除してアクセスを取り消すことができます。

クライアントの IP アドレスをホワイトリストに登録するには、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html の Cisco Unified Contact Center Enterprise 機能ガイド の タスク ルーティング セクションにあるホワイトリスト コマンドを参照してください。

Customer Collaboration Platform MR PG 暗号化

Unified CCE 管理システムインベントリで Customer Collaboration Platform を外部マシンとして構成する場合、MR PG サーバを構成し、Customer Collaboration Platform UI で マルチチャネルルーティングの CCE 構成ドロワーを開きます。

メディア ルーティング インターフェイスのセキュアなトランスポート モードを有効にするには、セキュリティ保護（TLS） チェックボックスを使用します。

- オンにすると、MR 通信が TLSv1.2 チャネルを介して保護されます。

- MR通信はプレーンな TCP チャネル経由となります。

- タスクルーティングに関する考慮事項

タスクルーティングに関する考慮事項

- タスク ルーティング

- タスクルーティングの使用例

- タスク ルーティング タスク フロー

- タスクルーティング設計への影響

タスク ルーティング

タスク ルーティングは、異なるメディア チャネルからコンタクト センターのエージェントに要求をルーティングするシステムの機能です。

音声通話、 E メール、チャットなどの組み合わせを処理するようにエージェントを設定できます。たとえば、エージェントが音声、 E メール、およびチャットを処理する場合、3 種類のメディア ルーティング ドメイン（MRD）でスキル グループまたはプレシジョン キューのメンバーとしてエージェントを設定することができます。メディアを問わず、ビジネス ルールに基づいてこれらのエージェントに要求を送信するようにルーティング スクリプトを設計できます。複数の MRD にサインインしたエージェントは、タスク単位でメディアを切り替えることができます。

ビジネス チャットおよび E メール 追加設定なしで、ユニバーサル キューを提供します。サードパーティ マルチチャネル アプリケーションは、タスク ルーティング API を使用して CCE と統合することによって、ユニバーサル キューを使用することができます。

タスク ルーティング API は、CCE でのサードパーティのマルチチャネル タスクを要求、キューイング、ルーティング、および処理する標準的な方法を提供します

コンタクトセンターのカスタマーまたはパートナーは、タスク ルーティング を使うため、Customer Collaboration Platform および Finesse API を使用してアプリケーションを開発できます。Customer Collaboration Platform Task API は、アプリケーションを有効にして、CCE に非音声タスクリクエストを送信します。Finesse API は、エージェントがさまざまなタイプのメディアにサインインし、タスクを処理できるようにします。エージェントは各メディアにサインインし、独立してそれぞれの状態を管理できます。

Cisco のパートナーは、Cisco DevNet で入手できるサンプル コードを上記アプリケーションの構築ガイドとして利用することができます（https://developer.cisco.com/site/task-routing/）。

サードパーティのマルチチャネル アプリケーション ソリューション コンポーネント用のユニバーサル キュー

Customer Collaboration Platform と タスク ルーティング

サードパーティのマルチチャネル アプリケーションは、Customer Collaboration Platform Task API を使用して、音声以外のタスクを CCE に送信します。

この API は、Customer Collaboration Platform タスクフィード、キャンペーン、および通知と連携し、コンタクトセンターにタスクの要求を渡してルーティングさせます。

Task API は、タスクの要求でのコール変数および ECC 変数の使用をサポートします。これらの変数は、チャット ルームの URL や E メールの処理といったメディアの属性など、顧客固有の情報を要求で送信するために使用されます。

Note

CCE ソリューションでは、Finesse および Customer Collaboration Platform で使用される拡張コールコンテキスト変数およびコール変数について、Latin 1 文字セットのみがサポートされています。アレイはサポートされていません。

CCE および タスク ルーティング

Cisco Unified CCE は、タスク ルーティングの一部として以下の機能を提供します。

- タスクの要求を処理します。

- タスクの要求の待機時間を予測します。

- エージェントが選択されている場合に Customer Collaboration Platform を通知します。

- スキル グループまたはプレシジョン キュー ベースのルーティングを使用して、エージェントにタスクの要求をルーティングします。

- メディア全体のコンタクト センター アクティビティについて報告します。

Finesse および タスク ルーティング

Finesse は、Media API および Dialog API 経由で タスク ルーティング 機能を提供します。

Media API の場合、サードパーティのマルチチャネル アプリケーションを使用するエージェントは、以下の処理が可能です。

- 別の MRD にログインします。

- 別の MRD で状態を変更します。

Dialog API を使用すると、サードパーティのマルチチャネル アプリケーションを使用するエージェントは、別の MRD からのタスクを処理することができます。

タスクルーティングの使用例

タスク ルーティング API を使用して、CCE でサードパーティ製マルチチャネルタスクを要求、キュー、ルーティング、および処理します。

次の使用例がサポートされています。

- 1 つの Media Routing Domain（MRD）の複数の同時タスクを MRD 内で処理するエージェント。

- 割り込み可能 MRD これら MRD のタスクを処理するエージェントは、別の MRD のタスクによって中断される場合があります。たとえば、電子メール MRD を中断可能にセットすると、電子メールのタスクを処理しているエージェントは、音声通話やチャットなどの別の MRD からのタスクによって中断される場合があります。

- 指定されたスクリプトセレクタへのブラインド転送。直接転送はサポートされていません。

- 割り当てられたタスクを使用してエージェントがサインアウトします。これらのタスクは、Finesse Media API のエージェントの dialogLogoutAction 設定に応じて、閉じたり転送されます。

- RONA. エージェントが、MRD のタイムアウト開始しきい値以内にオファーされたタスクを受け入れない場合、Finesse はルーティング用にタスクをサイド提出し、そのエージェントをルーティング可能にします。

タスク ルーティング タスク フロー

このタスクフローでは、エージェントが電子メールとチャットタスクを処理するように構成されている一般的なマルチチャネルシナリオについて説明します。

電子メール メディア ルーティング ドメイン（MRD）は割り込み可能であり、エージェントは、その MRD で割り込みを許可するよう構成されます。電子メール MRD は、割り込み可能なので、別の MRD からのタスクが電子メールタスクを処理するエージェントに割り込むことができます。エージェントが割り込みを受け入れるように構成されているため、別の MRD からのタスクがエージェントに割り当てられると、電子メール MRD でのエージェントの状態、電子メールタスク、Finesse ダイアログは、[割り込み中（INTERRUPTED）] に変わります。割り込み中、エージェントは、電子メールタスクの作業を行うことはできません。

チャット MRD は中断できません。

MRD の中断および中断の許可、却下に関しては、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html の Cisco Unified Contact Center Enterprise 機能ガイド を参照してください。

パートナーは、Finesse および Customer Collaboration Platform API に統合された電子メールおよびチャットアプリケーションを開発しました。

1. カスタマーが会社の電子メールを送信します。電子メールアプリケーションは、新規電子メールタスクリクエストを CCE に送信します。タスクリクエストには、スクリプトセレクタ、電子メールへの処理を含むカスタマー固有の情報が入った Call および ECC 変数が含まれます。

2. CCE が、スクリプトセレクタを通話タイプにマッピングすると、どのルーティングスクリプトが実行されるか決まります。ルーティングスクリプトは、電子メールタスクを電子メール MRD の適切なスキルグループまたはポスト コール調査にキューします。

3. 電子メールアプリケーションは、ステータスと推定待機時間（EWT）をポーリングします。

4. エージェントが、電子メール MRD にサインインすると、ステータスが [準備完了（Ready）] に変わります。

5. CCE は、電子メールをエージェントに割り当てます。タスクを作成するために使用する Call および ECC 変数は、ダイアログ メディア プロパティに含まれます。アプリケーションはこれらの変数を使用して、エージェントが電子メールに返信できるようにします。エージェントは Finesse の電子メールダイアログで作業を開始します。

6. 別のカスタマーがチャットリクエストを会社に送信します。チャットアプリケーションは、CCE に新しいチャットタスクリクエストを送信します。コール変数と ECC 変数には、チャットルームの URL が含まれます。

7. CCE が、チャットリクエストで送信されたスクリプトセレクタをコールタイプにマッピングすると、どのルーティングスクリプトを実行するかが決まります。ルーティングスクリプトは、チャットタスクをチャット MRD の適切なスキルグループまたはポスト コール調査にキューします。

8. チャットアプリケーションは、ステータスと推定待機時間（EWT）をポーリングします。

9. 電子メールタスクの作業中に、同じエージェントがチャット MRD にサインインすると ステータスが [準備完了（Ready）] に変わります。

10. CCE は、チャットタスクをエージェントに割り当てます。アプリケーションは、Call および ECC 変数を使用して、エージェントをカスタマーとのチャット ルームに追加します。エージェントは Finesse のチャットメールダイアログで作業を開始します。

11. 電子メール MRD のエージェントのステータスは [割り込み中（Interrupted）] に変わり、電子メールダイアログのステータスが [割り込み中（Interrupted）] に変わります。アプリケーションは、電子メールダイアログのアクションを無効にします。

12. エージェントは、チャットタスクを別のスクリプトセレクタに転送します。Finesse はチャットダイアログを閉じ、タスクを Customer Collaboration Platform に再送信します。アプリケーションはチャットルームを閉じます。

13. エージェントは他の非割り込みダイアログを処理せず、電子メールダイアログはアクティブになります。

14. エージェントは、電子メールダイアログの作業を続行します。エージェントは、ダイアログを一時停止して、短い休憩を取り、ダイアログを再開します。

15. 電子メールの返信が完了すると、エージェントはそのダイアログのまとめ作業を実行します。エージェントはダイアログを閉じます。Finesse は 、電子メールタスクのために Customer Collaboration Platform にハンドルイベントを送信します。アプリケーションは、カスタマーに対して電子メールの返信を送信します。

タスクルーティング設計への影響

- 企業リファレンス設計タスク ルーティング サポート

- タスクルーティングの導入要件

- タスクルーティングのサイジングとキャパシティの制限

- タスク ルーティングの帯域幅、遅延、QoS に関する考慮事項

企業リファレンス設計タスク ルーティング サポート

すべてのソリューションは、タスクルーティングをサポートしますが、コンタクトセンター用の HCS の小規模コンタクトセンター ソリューションは例外です。

タスクルーティングの導入要件

タスク ルーティング サードパーティ製マルチチャネル アプリケーションの導入要件

- Finesse および Customer Collaboration Platform が必要です。タスク ルーティング に対してシステムを構成する前に Finesse および Customer Collaboration Platform をインストールし、構成してください。

https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/tsd-products-support-series-home.html にある Finesse のマニュアルを参照してください。

https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/tsd-products-support-series-home.html のCustomer Collaboration Platform ドキュメントを参照してください。

[ホワイトリスティング機能（Whitelisting Feature）] 項で記載されている Customer Collaboration Platform サーバのホワイトリスティング手順を完了してください。

- 展開環境にインストールできる Customer Collaboration Platform マシンは 1 つのみです。

- Customer Collaboration Platform は、Media Routing Peripheral Gateway（MR PG）の一方の側と地理的に同じ場所である必要があります。

- CCE、Finesse およびサードパーティ製マルチチャネル Customer Collaboration Platform タスク ルーティング アプリケーションがネットワーク上でアクセスできる場所にCustomer Collaboration Platform をインストールします。

DMZ に Customer Collaboration Platform をインストールする場合は、CCE と Finesse のポートを開いて接続します。Customer Collaboration Platform に接続する CCE のデフォルトポートは 38001 です。Finesse は Customer Collaboration Platform over HTTPS、ポート 443 経由で接続されます。

Customer Collaboration Platform を使いローカルにサードパーティ製マルチチャネル アプリケーションをインストールするか、アプリケーションを接続するために、Customer Collaboration Platform サーバでポートを開きます。

タスクルーティングのサイジングとキャパシティの制限

サードパーティ製マルチチャネル アプリケーションの タスク ルーティング のサイジングとキャパシティ制限は次のとおりです。

- システムごとのマルチメディアエージェントの最大数：2,000 エージェント

- 1 時間あたりの最大タスク数：15,000 タスク

- 同時タスクの最大数：20,000 タスク

- すべてのエージェントの MDS にわたるエージェントごとの最大タスク：5 タスク

- 単一 MRD に置けるエージェントごとの最大タスク数：5 タスク

- タスク送信率：毎秒 5 タスク

Customer Collaboration Platform は、CCE に対するタスク送信率を 毎秒 5 タスクに調整します。Customer Collaboration Platform は、送信の目的でキューに 最大 10,000 タスクを保持します。キューが 1 万タスクを超えると、Customer Collaboration Platform は、廃棄コード NOTIFICATION_RATE_LIMITED で、追加タスクを破棄します。キューが再度対応可能になると、追加のタスクがキューに追加されます。

タスク ルーティングの帯域幅、遅延、QoS に関する考慮事項

Customer Collaboration Platform に関して、HTTP を確実にサポートするためにネットワークに十分な帯域幅が必要です。タスク ルーティング REST API 要求はメタデータのみを伝送します。メディアは伝送しません。カスタマーアプリケーションが、タスクステータス通知を受け取るために XMPP を介して Customer Collaboration Platform に接続されている場合、ネットワークは、Customer Collaboration Platform XMPP サーバとの永続的な TCP 接続を確実にサポートする必要があります。XMPP を介した Customer Collaboration Platform への接続は、ネットワーク帯域幅に大きな影響を及ぼしません。

Finesse デスクトップのタスク ルーティング タスクに必要な帯域幅を計算するには、Finesse Bandwidth Calculator（https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html）を使用します。

CCE では、タスク ルーティング タスクの帯域幅、遅延、QoS に関する考慮事項は、音声コールに対する考慮事項と同様です。タスク ルーティング タスクは、音声コールと同じ帯域幅を使用します。

Related Concepts

Unified CCE の帯域幅、遅延、および QoS

Unified SIP プロキシ設計上の考慮事項

ソリューションに Cisco Unified SIP Proxy（CUSP）を追加する際は、次の点を検討してください。

- CUSP は、UCS B、C、および E シリーズのサーバに配置できる VM です。

- 標準規格の CUSP トポロジは、地理的に分離された 2 つの冗長ゲートウェイで構成されています。ゲートウェイには、それぞれ 1 つのプロキシモジュールがあります。プロキシの冗長性には SRV 優先順位が使用されます。HSRP は使用しません。

- CUSP は、VXML または TDM ゲートウェイとコアサイドに接続できます。

- SRV またはダイヤルピア設定を使用して TDM ゲートウェイを構成すると、プライマリおよびセカンダリ CUSP プロキシが使用できます。

- プライマリとバックアップの Unified CVP、Unified CM、および VCM ゲートウェイを検索するには、サーバグループを使用して CUSP を設定します。

- Unified CVP は、サーバグループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

- Unified CM は、複数の SIP トランクを持つルート グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

- CUSP 展開のパフォーマンス マトリクス

- CUSP によるコール廃棄

CUSP 展開のパフォーマンス マトリクス

プロキシ上での分離での CUSP の基準値テストでは、毎秒最大キャパシティで 450 TCP トランザクションになります。これを最高ベンチマークとして使用し、最も重視する条件の許容値として使用します。プロキシサーバの観点からすると、CVP コールによって、平均で 4 つの個別の SIP コールが生成されます。

- 発信者の着信レッグ

- VXML 発信レッグ

- 着信音の発信レッグ

- エージェントの発信レッグ

CVP キューイングとのコンサルトが発生すると、セッションでさらに 4 つの SIP トランザクションが発生し、実質的にコール数が 2 倍になります。

レコードルート は、CUSP でデフォルトでオフになります。

Note

プロキシサーバでは、レコードルート 設定は常にオフにしておきます。これにより、シングルポイント障害が回避され、フォールト トレラント ルーティングが許可され、プロキシサーバのパフォーマンスが向上します。プロキシサーバの設定を使用すると、パフォーマンスへの影響が倍増します。また、高可用性モデルが壊れます。プロキシがダウンした場合、プロキシは、コールに対してシングルポイント障害となります。

CUSP によるコール廃棄

ここでは、SIP を使用した Cisco IOS ゲートウェイ構成について説明します。以下の例では、特定の構成概念を強調表示しています。

- Cisco IOS ゲートウェイの構成

- SIP プロキシのダイヤルプラン構成

Cisco IOS ゲートウェイの構成

Cisco IOS ゲートウェイでは、ダイヤルピアを使用して、ディレクトリ番号を照会します。接続先は SIP Proxy サーバ、DNS、SRV または IP アドレスに指定できます。次の例に、SIP プロキシの IP アドレスを使用して、コールを SIP Proxy サーバに送信する Cisco IOS ゲートウェイ構成を示します。

sip-ua
sip-server ipv4:10.4.1.100:5060

dial-peer voice 1000 voip
session target sip-server
...

ダイヤルピアの sip-server コマンドは、Cisco IOS ゲートウェイに sip-ua 設定で構成した全体的に定義された SIP サーバを使うように指示します。冗長性のために複数の SIP プロキシを設定するためには、次の例に示すように、IP アドレスを DNS SRV レコードに変更できます。DNS SRV レコードでは、単一の DNS 名を複数の コールサーバにマップできます。

sip-ua
sip-server dns:cvp.cisco.com

dial-peer voice 1000 voip
session target sip-server
...

代わりに、次の例に示すように、複数の SIP Proxy サーバを直接指すように複数のダイヤルピアを構成できます。このコンフィギュレーションでは、DNS を使用する代わりに IP アドレスを指定できます。

dial-peer voice 1000 voip
session target ipv4:10.4.1.100
preference 1
...
dial-peer voice 1000 voip
session target ipv4:10.4.1.101
preference 1
...

前の例では、ダイヤルプランの解決およびコールルーティングのためにコールが SIP Proxy サーバに送信されます。Unified CVP コールサーバが複数ある場合、SIP Proxy サーバは、負荷分散および冗長性のために複数のルートを使用して構成されます。Cisco IOS ゲートウェイでは、SIP Proxy サーバを使用せずに、負荷分散および冗長性を実現できます。次の例では、3 つの Unified CVP コールサーバ間でコールを負荷分散するように、複数のダイヤルピアを使用した Cisco IOS ゲートウェイ構成を示します。

dial-peer voice 1001 voip
session target ipv4:10.4.33.131
preference 1
...
dial-peer voice 1002 voip
session target ipv4:10.4.33.132
preference 1
...
dial-peer voice 1003 voip
session target ipv4:10.4.33.133
preference 1
...

DNS SRV レコードによって、管理者は、DNS ラウンドロビン冗長性およびロード バランシングを使用した場合よりも詳細に冗長性およびロード バランシングを設定できます。DNS SRV レコードを使用すると、特定のサービス（この場合のサービスは SIP）に対して使用しなければならないホストを定義できます。また、これらのホスト間での負荷分散の特性を定義できます。次の例では、上記のように構成された 3 つのダイヤルピアによって提供される冗長性が、DNS SRV レコードを使用して、単一ダイヤルピアに置き換えられるケースを示しています。DNS ルックアップを行うためには、DNS サーバが必要であることに注意してください。

ip name-server 10.4.33.200
dial-peer voice 1000 voip
session target dns:cvp.cisco.com

Cisco IOS ゲートウェイでは、静的ホストレコードと同様に、DNS SRV レコードを静的に定義できます。この機能を使用すると、DNS SRV 負荷分散および冗長性を実現しながら、ダイヤルピア構成を簡素化できます。この方法には、SRV レコードの変更が必要な場合、集中型 DNS サーバではなく各ゲートウェイで設定を変更する必要があるという欠点があります。次の例は、cvp.cisco.com で処理された SIP サービスの静的 SRV レコードの構成を示します。cvp.cisco.com の SIP SRV レコードは、3 台のサーバ間で負荷分散を行うよう構成されます。

ip host cvp4cc2.cisco.com 10.4.33.132
ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131

（SIP/TCP の SRV レコード）

ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com

（SIP/UDP の SRV レコード）

ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com

SIP プロキシのダイヤルプラン構成

SIP プロキシがある場合は、Unified CM ルーティングクライアントと CVP ルーティングクライアントに異なる VRU ラベルを使用します。Unified CM ルーティングクライアントは、VRU ラベルを使用して、CVP コールサーバにコールを送信して、最初に呼制御を受け渡します。CVP ルーティングクライアントは、VRU ラベルを使用して、処理のために VXML ゲートウェイにコールを送信します。コールが CVP になると、CVP は CVP ルーティングクライアントの VRU ラベルに転送します。その後、VXML ゲートウェイにコールを送信し、キュー処理を行います。

SIP プロキシでダイヤルプランを次のように構成します。

[Unified CM routing client VRU label + correlation-id]: pointing to CVP servers
[CVP routing client VRU label + correlation-id]: pointing to VXML Gateways

Enterprise Chat and Email の設計上の考慮事項

ビジネス チャットおよび E メール によって、エージェントと管理者は共通の Web サーバとページを通じて、Web と E メールのインタラクションを管理できます。この機能は Contact Center Enterprise ソリューションと統合され、さまざまなメディア チャネルからエージェントへのコンタクトのユニバーサル キューイングを提供します。

アーキテクチャおよび設計の詳細については、『Enterprise チャットおよび E メール設計ガイド』（http://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/products-implementation-design-guides-list.html）を参照してください。

Enterprise Chat and Email の設計上の考慮事項

- ビジネス チャットおよび E メール 展開オプション

ビジネス チャットおよび E メール 展開オプション

モジュラーおよびコンポーネントベースのアーキテクチャが原因で、ビジネス チャットおよび E メール（ECE）同時ユーザ負荷に対する増幅した需要に対応します。さまざまなサイズの導入に適した柔軟性を提供するために、ECE ソリューションは、ソリューション内のさまざまなサーバに分散できるさまざまなコンポーネントをサポートしています。

併置展開

同じ場所に配置された展開では、Web サーバを 1 つのサーバにインストールし、他のすべてのコンポーネントを別のサーバにインストールします。必要に応じて、ファイアウォールの外部に Web サーバをインストールできます。

併置展開

分散型サーバの展開

分散型サーバの展開では、各コンポーネントをファイアウォールの外部にWeb サーバを持つ別のサーバにインストールします。他のサーバを再起動しなくても、この構成では、アプリケーション、メッセージ、サービスそして Web サーバは個別に再起動できます。

分散型サーバの展開

サイレント モニタリングの設計上の考慮事項

チームを管理しているスーパーバイザの場合は、Unified CM ベースのサイレント モニタリングの非干渉メカニズムを利用して、エージェントの音声コールをモニタできます。

従来の SPAN ベースのサイレント モニタリングは、非リファレンス設計に対してのみサポートされます。

- Unified CM ベースのサイレントモニタリング設計上の考慮事項

Unified CM ベースのサイレントモニタリング設計上の考慮事項

- Unified CM ベースのサイレント モニタリング コール フロー

- Unified CM ベースのサイレントモニタリングの影響

Unified CM ベースのサイレント モニタリング コール フロー

Cisco Finesse は、Unified CM のサイレントモニタリングを介してサイレントモニタリング機能を提供します。Cisco Finesse は、Unified CM サイレントモニタリング機能時に、以下のように動作します。

1. サイレントモニタリングを開始するため、スーパーバイザ アプリケーションは、Cisco Finesse サーバに REST 要求を送信します。

2. サイレント モニタリング セッションを開始するため、Cisco Finesse サーバは、AgentSuperviseCall(）メッセージを Unified CCE に送信します。

3. Unified CCE は、Unified CM に CallStartMonitor(）メッセージを送信します。

4. Unified CM はスーパーバイザの電話機に対し、エージェント電話機の組み込みブリッジ（BIB）にコールするよう指示します。

5. スーパーバイザの電話機は、エージェント電話機で BIB をコールします。

6. エージェントの電話機は、エージェントの音声ストリームと顧客の音声ストリームの組み合わせを転送します。

7. Unified CM は、サイレント モニタリング コールのコールイベントを Unified CCE に送信します。

8. Unified CCE は、Cisco Finesse サーバに更新イベントを送信します。

9. Cisco Finesse サーバは、Cisco Finesse スーパーバイザ アプリケーションに XMPP アップデートを送信します。

Cisco Finesse では、モバイルエージェントのサイレントモニタリングはサポートされません。スーパーバイザは、モバイルエージェントをサイレントモニタリングできず、モバイルスーパーバイザは、サイレントモニタリングを実行できません。

スーパーバイザは、Cisco Finesse IP Phone からサイレントモニタリングを実行できません。スーパーバイザは、Cisco Finesse デスクトップからのサイレントモニタリングのみ実行できます。

Unified CM ベースのサイレントモニタリングの影響

Unified CM は、スーパーバイザ（監視）デバイスとエージェント（監視対象）デバイスの間のコールを使用してサイレントモニタリングを行います。エージェントの電話機はエージェントの会話をミックスしてスーパーバイザの電話機に送信し、スーパーバイザに再生します。

Unified CCE は、Unified CM で利用可能なサイレント モニタリング機能をサポートしています。Unified CM のサイレント モニタリングでは、同じエージェント電話に対して 1 つのサイレント モニタリング セッションおよび 1 つの録音セッションのみがサポートされます。

Note

Unified CM サイレント モニタリングは、モバイル エージェントはサポートしていません。

以下の条件に該当する場合、Unified CM サイレントモニタリングは、任意の Unified CCE エージェントデスクトップを監視できます。

- 監視対象のエージェントは、互換性のある Cisco Unified IP Phone または Cisco IP Communicator を使用します。ソリューションの詳細に関しては、「互換性マトリックス」を参照してください。

- コンタクト センターでは、互換性のあるバージョンの Cisco Unified CM が使用されています。使用するソリューションの詳細については、 互換性マトリクス を参照してください。

スーパーバイザは、Cisco IP Communicator を含む任意の Cisco IP 電話を使用してエージェントをサイレントモニタできます。

Unified CM サイレント モニタリングは、Unified CM で提供されるその他のコール制御機能 (会議や転送など) と同様に動作します。サイレントモニタリングのセッションが開始されると、デスクトップは Unified CCE を介してメッセージを送信し、サイレントモニタが実行されている電話機に送信します。

Unified CCE および Unified CM を介したメッセージングは、Unified CCE のパフォーマンスに影響を及ぼします。

サードパーティ コンポーネント設計上の考慮事項

サードパーティ製コンポーネントが CTI サーバを介して Unified CCE に接続する場合は、次の設計上の考慮事項に注意してください。

- All-Event クライアントの制限

- DNSサーバ導入に関する考慮事項

- ロード バランサの設計上の考慮事項

- 録音設計に関する検討事項

- セッションボーダーコントローラ

- 音声認識と音声合成

All-Event クライアントの制限

CTI サーバは、All-Event クライアントを使用します。

最大 2 台の vCPU 小規模エージェント PG OVA

各エージェント PG では、CTI サーバ上に最大 7 つの All-Event クライアントを作成できます。Cisco Finesse は、次の 2 つのクライアントを使用します。

vCPU 大規模エージェント PG OVA を最大 4 個まで

vCPU を 4 つ使用する大規模 OVA から作成された VM は、より多くの All-Event クライアントとモニタモード接続をサポートできます。各エージェント PG では、CTI サーバ上に最大 20 つの All-Event クライアントを作成できます。Cisco Finesse は、次の 2 つのクライアントを使用します。

All-Event クライアント

Cisco Finesse デスクトップ ソリューションは、2 つの利用可能な All-Event クライアントを使用します。他に考えられるクライアントの消費者の一部を次に示します。

- Outbound Dialer

- リアルタイム遵守（2）

- 一部のサードパーティ製録音ベンダー（2）

- ビジネス チャットおよび E メール (2)

- B+S CRM コネクタ

DNSサーバ導入に関する考慮事項

ソリューション用の DNS サーバを設定する際は、以下を考慮してください。

- DNS サーバを逆引き参照用に設定する。

- NAT ネットワーク境界を超えて DNS サーバを設定しない。

- 検索を実行するサーバとの接続に低遅延の冗長 DNS サーバを配置する。

ロード バランサの設計上の考慮事項

- Cisco Finesse サインイン向けロードバランサ

- Cisco Unified Intelligence Center 向けロードバランサ

- CVP 向けロードバランサ

- Unified CCE 管理ツール向けロードバランサ

- とロードバランサビジネス チャットおよび E メール

Cisco Finesse サインイン向けロードバランサ

エージェントが Cisco Finesse デスクトップにサインインすると、Cisco Finesse デスクトップクライアントは両方の Cisco Finesse サーバの IP アドレスをキャッシュします。Cisco Finesse サーバがサービス停止中の場合、Cisco Finesse クライアントは、自動的にエージェントをリダイレクトし、別の Cisco Finesse サーバにサインインさせます。このクライアント側のロジックを考えると、フェールオーバーの目的でロードバランサを使用することはできません。

ただし、次の 2 つのシナリオでは、Cisco Finesse でロードバランサを使用できます。

Note

これらのシナリオは、Cisco Finesse デスクトップにのみ適用されます。これらのシナリオは、Cisco Finesse IP Phone エージェントには適用されません。

Cisco Finesse サインインページにアクセスする方法

エージェントが停止しているまたは到達不可能な Cisco Finesse サーバに移動すると、エージェントは サインインページにアクセスできません。エージェントがエラーを受け取ると、他の Cisco Finesse サーバに手動でサインインする必要があります。この手動による手順を回避するために、URL リダイレクト モードのロードバランサを使用してエージェントをアクティブな Cisco Finesse サーバに送信できます。Cisco Finesse SystemInfo REST API には、Cisco Finesse サーバのステータスが表示されます。この API の詳細については、『Cisco Finesse Web サービス開発者ガイド』を参照してください。

Cisco Finesse サーバのステータスを決定するためにロードバランサを設定する場合は、次のコールフローを使用します。

1. エージェントは、ロードバランサにブラウザを向けます。

2. ロードバランサは、エージェントブラウザを適切な Cisco Finesse サーバにリダイレクトします。

3. エージェントは、直接 Cisco Finesse サーバにサインインします。この段階で、ロードバランサは、コールフローの一部ではなくなります。

Cisco Finesse API の直接使用

Cisco Finesse REST API を直接使用している場合、コールフローは、Cisco Finesse クライアント側のフェールオーバーロジックを使用できません。高可用性を管理するためのロードバランサの使用を選択できます。ロードバランサはカスタムアプリケーションの一部で、すべてのカスタムアプリケーション同様、シスコではサポートされません。カスタマーまたはシスコパートナーがロードバランサに必要なサポートを提供します。

Cisco Finesse クライアントと Cisco Finesse サーバとの間には次の 2 つの接続があります。

- 要求と応答用の REST チャネル

- サーバからクライアントに通知を送信する XMPP チャネル

該当のクライアントに対する両方のチャネルは、同じ Cisco Finesse サーバに接続する必要があります。ロードバランサを一方の Cisco Finesse サーバの REST 接続、およびもう一方の Cisco Finesse サーバの XMPP チャネル接続に接続することはできません。このような設定は予期しない結果を招くだけでなく、サポートされてもいません。

Cisco Unified Intelligence Center 向けロードバランサ

Unified Intelligence Center には、ロードバランサを使用してアクセスできます。次の条件が適用されます。

- ロードバランサでのセッションスティッキ性は、Unified Intelligence Center へのアクセスに必須です。

- ライブデータレポートは、ロードバランサを介してアクセスできません。

- CUIC ノードとブラウザクライアントが WAN で分割されている場合、ロードバランサはサポートされません。

CVP 向けロードバランサ

Unified CVP ソリューション コンポーネントがあるロードバランサを使うと、HTTP、HTTPS、および MRCP トラフィックのロードバランサと高可用性を実現できます。ロードバランサは、VXML ゲートウェイと VXML サーバ間の VXML ページのレンダリングを分散できます。また、ロードバランサは、メディアサーバの VRU スクリプト実行用のメディアファイルのフェッチを展開することもできます。

Note

ソリューションが、MRCPv2 の場合、負荷分散に CUSP を使用します。

CVP は現在、次の要件を満たすサードパーティ製のロードバランサをサポートしています。

- SSL オフローディングと SSL パススルーの両方のサポート

- ロードバランサ高可用性のサポート

- 必須セッションのスティッキ性は保持しない

- 永続性のため cookie を挿入

- 流通アルゴリズムはラウンドロビン

Unified CCE 管理ツール向けロードバランサ

これらのシナリオでは、Unified CCE Administration ツールでロードバランサを使用できます。

Unified CCE 管理サインインページに移動

管理者またはスーパーバイザが、ダウンしているか到達不可能なサーバの Unified CCE Administration ツールに移動すると、サインインページにアクセスできません。管理者またはスーパーバイザには、エラーが表示され、別のサーバの Unified CCE Administration に手動でサインインしなければなりません。この手動による手順を回避するために、URL リダイレクトモードのロードバランサを使用して、セッションをアクティブサーバにダイレクトします。

使用シナリオ

1. ユーザはブラウザをロードバランサに向けます。

2. ロードバランサは、ブラウザセッションを適切な Unified CCE Administration サーバにリダイレクトします。

3. ユーザは、Unified CCE Administration サーバに直接サインインします。

Unified CCE 管理 API の直接使用

Unified CCE Administration REST API を直接使用する場合は、ロードバランサを使用して高可用性を管理できます。ロードバランサはカスタムアプリケーションの一部で、すべてのカスタムアプリケーション同様、シスコではサポートされません。カスタマーまたはシスコパートナーがロードバランサに必要なサポートを提供します。

とロードバランサビジネス チャットおよび E メール

でロードバランサのリダイレクトモードを使用しないでください。ビジネス チャットおよび E メール

録音設計に関する検討事項

- ネットワークベースの録音設計に関する検討事項

ネットワークベースの録音設計に関する検討事項

ネットワークベースの録音（NBR）機能は、Real-time Transport Protocol（RTP）ストリームに対するソフトウェアベースのフォーキングをサポートします。メディアフォーキングを使用すると、1 回の通話でオーディオとビデオのミッドコール複数ストリーム（またはブランチ）を作成できます。その後、データのストリームを別の通知先に送信できます。CUBE を使用してネットワークベースの録音を有効にするには、録音に関する構成ガイドを参照してください。特定のコマンドを構成するか、コールエージェントを使用できます。CUBE はレコーディングクライアント

Note

ネットワークベースの録音は、コール存続可能性機能と連携して機能します。

次の図は、ネットワークベースの録音のコールフローを示しています。

ネットワークベースの録音コールフロー

ネットワークベースの録音コールフロー

ネットワークベースの録音に関する一般的なコールフローは次のとおりです。

1. 着信コールが CUBE に到達します。

2. イングレスゲートウェイはそのコールを Unified CVP に送信します。

3. Unified CVP は、着信コールリクエストを Unified CCE に送信し、VRU ラベルを取得します。

4. Unified CVP から VXML ゲートウェイにコールが送信されます。発信者に VRU が再生されます。ただし、コールは記録されません。

5. エージェントが利用可能になると、Unified CVP は発信者とエージェントを接続します。

6. この会話に対してネットワークベースの録音が開始します。

- ネットワークベースの録音の制限

ネットワークベースの録音の制限

- エージェント間の通話転送では、ネットワークベースの録音は機能しませんが、電話ベースの録音は機能します。ネットワークベースの録音を使用する場合は、Unified CVP と Unified CM 間で ISR ゲートウェイを使用できます。

- NBR 機能は IOS イメージトレインでのみサポートされます。サポートされている IOS イメージトレインの詳細については、ご使用のソリューション向けの「互換性マトリックス」を参照してください。

セッションボーダーコントローラ

サードパーティ製のセッション ボーダー コントローラ（SBC）を、PSTN とコンタクトセンター間の入力境界または出力境界要素として使用できます。ほとんどのソリューションは、すべての Contact Center Enterprise 機能をサポートするためサードパーティ製 SBC および Unified CVP 間の CUBE を要求します。導入環境では、他のほとんどの通信レグにある SBC を使用することはできません。

次の図は、SBC を使用できる場所と使用できない場所を示しています。

SBC の実装

Note

CUBE には SBC 機能と Contact Center Enterprise 向けの機能の両方が含まれます。CUBE を、SBC 機能のみを提供するサードパーティ製 SBC に置き換えることができます。ソリューションには、Contact Center Enterprise 機能の CUBE が必要です。

サードパーティ製 SPC のテストは積極的にテストしていません。

展開に SBC を追加検討する場合、次の一般設計ガイドラインと制限事項を考慮してください。

サポートポリシー

相互運用性の問題がある場合、シスコは、コールフローから SBC を一時的に削除するよう要求する場合があります。SBC なしで問題が見つからない場合は、Cisco TAC がケースをその SBC のメーカーに引き渡します。

- CUBE なしのサードパーティ SBC の使用

CUBE なしのサードパーティ SBC の使用

SIP PSTN サービスプロバイダーを含むサードパーティの SIP デバイスに接続する場合は、CUBE を使用します。Unified CVP と SIP デバイスの間に CUBE を配置しない場合は、双方が完全な統合テストと互換性を持ち合っている必要があります。

CUBE なしで PSTN SIP トランキングサービスに接続する場合は、コンタクトセンターとサービスプロバイダー間の接続を保護する方法を慎重に検討してください。NAT を実行してアドレスを非表示化する方法も検討してください。それ以外の場合、サービス プロバイダー ネットワークは、コンタクトセンター ネットワークにフルアクセスできます。シスコが提供するサービスプロバイダーのインターコネクト インターフェイスとして、CUBE アドレスでは、これらの両方の懸念事項を処理します。

特定の CVP 機能を使用しないソリューションについては、サードパーティの SBC を CVP に直接接続できます。このような解決策には、相互運用性を確認するための慎重なテストが必要です。

Important

サードパーティの SBC を Unified CVP に直接接続する設計では、シスコからの特別な例外をもって展開する必要があります。

Supported Features

特定のテストを実施しない場合、どの機能のサポートも保証されません。過去のテストでは、一般に次の機能がサポートされています。

- G.711ulaw、G711alaw、および G.729（Annex B なし）コーデック

- DNIS および ANI プレゼンテーション

- SBC の内部インターフェイスの SIP/TCP、外部インターフェイスの SIP/UDP

- CVP ベースのキュー

- DTMF を使用する CVP アプリケーション

- re-INVITE を使用した CVP ベースのイントラサイト転送

- Unified CM ベースのイントラサイト転送および会議

- SBC ベースの通話中コーデックのネゴシエーション基本的なコールフローは一般に機能しますが、複雑なコールフローは機能するのが難しい場合があります。

- Cisco Unified Communications Manager（Unified CM）通話中コーデックのネゴシエーション（必要な場合は、トランスコーダ挿入を使用）。基本的なコールフローは一般に機能しますが、複雑なコールフローは機能するのが難しい場合があります。

- SBC の SIP INFO メッセージを CVP から RFC2833 トーンに変換（DTMF ベースの転送の場）

Note

CVP と SBC 間のタイミングの問題により、SBC が転送を完了する前に CVP がコールを切断する場合があります。

- REFER での SBC による REFER 転送

Note

CVP は、転送が完了すると SBC からサブスクリプションを終了する BYE または最終的な NOTIFY を必要とします。SBC がこれらの 1 つも送信しない場合、コールはサブスクリプション期間中に停止し、CVP ライセンスはリリースされません。

- 消費モードの SBC を使用した SIP 302 リダイレクト応答

- 応答なしでの CVP ベースのリダイレクト

- コール保留

サポートされない機能

特定のテストを実施しない場合、どの機能のサポートも保証されません。過去のテストでは、一般に、これらの機能がサポートされていないことが示されています。

- SIP コール プログレス分析によるアウトバウンドオプション

- サービス コールバック

- コールの存続可能性と関連機能（survivability.tcl スクリプト、ローカルブランチ SRST および TOD ルーティング、フックフラッシュ、TBCT）

- VRU PG 障害の処理および存続可能性によるダウンストリーム障害処理

- エッジでのキュー（CVP SendToOriginator 機能を使用）

- ビデオコールフロー

- SIP over TLS および SRTP

- ロケーションベースの CAC

- REFER と置換

- シスココンポーネント間のメッセージに対して（CUSP ではなく）SIP プロキシとして構成された SBC

- ネットワーク トランク グループの使用率とレポート

- トランクグループの使用率

- SIP リソースの可用性インジケータ（RAI）動的コールルーティング

- SIP ダイヤルピアベースの録音

一般に、さまざまな Unified CCE 機能と CVP 機能が、サードパーティの SBC に存在しない特定の CUBE 機能に依存しているので、機能は、サポートされません。

その他の注意点

サードパーティの SBC を導入環境に追加する場合は、次の注意事項を検討してください。

- ほとんどのサードパーティの SBC は、Unified CCE がエンドツーエンドのコール トラッキングに使用する Cisco-Guid ヘッダーを生成しません。

- SBC と CVP の間で SIP over TCP を使用する場合、SBC が高可用性機能を介して切り替わる場合、一部のコールがドロップする場合があります。使用される CVP サーバごとに、スイッチオーバーが発生した後に 1 つのコールがドロップする場合があります。特定の CVP サーバで進行中の他のすべてのコールは、処理状態を把握するシグナリングとメディアを使用してアクティブな状態をとります。ドロップされたコールは、スイッチオーバー後に SBC に SIP メッセージを送信する最初のコールです。SIP over UDP ではこの動作は表示されません。

- サードパーティの SBC を使用するソリューションでは、ネットワークが SBC とサブネット間にコンタクトセンター ソリューション コンポーネントがあるファイアウォールを備える場合があります。ファイアウォールの構成定では、SBC と CVP 間の SIP 関連の通信を許可します。

TCP を通した SIP トラフィックの場合、CVP は SBC 用の SIP ポートとの発信接続を作成します。CVP では、SBC と CVP の間にコールがない場合でも、アイドル状態の TCP 接続は 4 時間確立された状態のままです。

ファイアウォールの構成では、CVP で検出されなくても、このようなアイドル状態の接続が解放される可能性があります。次に CVP が着信コールを受信すると、CVP が発信 TCP 接続上の SIP リクエストを SBC に送信できないため、一部のコールが失敗します。CVP が SBC への新しい接続を確立するまで、コールは失敗する可能性があります。

- シナリオによっては、CVP が通話中および無応答時の通知を SBC に送信する必要があります。このような場合は、Remote-Party-ID ヘッダーを使用してヘッダーを操作して、表示名の最後に「--CVP」を含める必要があります。

- すべての SIP サービスプロバイダーが、REFER、302 リダイレクトメッセージ、DTMF ベースの取り消しと転送、またはデータ転送（UUI、GTD、NSS 等）の拡張機能をサポートするわけではありません。

- Unified CM は、CVP へのシグナリングパス上のセッション更新に UPDATE メソッドを使用できます。この使用例はテストされていないため、CVP がサードパーティの SBC に直接接続されている場合はサポートされません。

- CVP は、IPv6 SDP と IPv4 SDP の両方をサポートします。SBC がセッションの説明で IPv4 と IPv6 の両方を使用する場合は、代替ネットワーク アドレス フォーマット（ANAT）を使用します。

Cisco Virtualized Voice Browser

シスコでは、サードパーティ製 SBC を使用して Cisco VVB をテストしていません。

音声認識と音声合成

自動音声認識（ASR）または音声合成（TTS）サーバは、無音圧縮を使用できないため、G.711 コーデックを使用する必要があります。

Chapter 6. 高可用性とネットワーク設計

- 高可用性の設計

- 高可用性と仮想化

- リファレンス設計に準拠したソリューション用のネットワーク設計

- イングレス、エグレスおよび VXML ゲートウェイの高可用性に関する考慮事項

- CVP 高可用性の考慮事項

- Unified CCE の高可用性に関する検討事項

- 仮想化音声ブラウザの高可用性に関する検討事項

- Unified CM の高可用性に関する検討事項

- Cisco Finesse 高可用性の考慮事項

- Unified Intelligence Center の高可用性に関する検討事項

- Unified CM ベースのサイレントモニタリングの高可用性に関する検討事項

- Customer Collaboration Platformハイ アベイラビリティの考慮事項

- Unified SIP プロキシの高可用性に関する検討事項

- ビジネス チャットおよび E メールハイ アベイラビリティの考慮事項

- ASR TTS 高可用性に関する考慮事項

- アウトバウンドオプションの高可用性に関する検討事項

- シングルサインオンの高可用性に関する考慮事項

高可用性の設計

Cisco Contact Center Enterprise ソリューションは、設計により高可用性の機能を備えています。ソリューション設計には、コアコンポーネントの冗長性を含める必要があります。冗長コンポーネントは自動的にフェールオーバーし、手動操作なしで復元します。設計にも基本以上の高可用性機能を含めることができます。導入を成功させるには、データや音声インターネットワーキング、システム管理および Contact Center Enterprise ソリューション設計および構成に関する経験があるチームが必要です。

高可用性を促す各変更には、コストがかかります。このコストには、より多くのハードウェア、より多くのソフトウェアコンポーネント、およびより多くのネットワーク帯域幅が含まれる場合があります。コストと変更による結果のバランスを取ってください。フェールオーバーシナリオ中に切断を防止することはどれくらい重要でしょうか。システムの一部が復旧するまで、カスタマーに数分待ってもらうことは許容範囲でしょうか。障害中、一部の通話のコンテキストがなくなってしまうことをカスタマーは許してくれるでしょうか。初期設計中により優れたフォールトトレランスに投資し、将来的な拡張性のためにコンタクトセンターを配置するでしょうか。

導入サイクルにおける再設計や今後のメンテナンスの問題を避けるために慎重に計画しましょう。すべての導入サイトの将来的な拡張性を念頭に置いて常に、最悪の障害シナリオを想定して設計します。

Note

このガイドでは、Contact Center Enterprise ソリューションそのものの設計に焦点を当ててください。ソリューションは、他のシステムのフレームワークで動作します。このガイドでは、コンタクトセンターをサポートする各システムに関する完全な情報は記載されていません。このガイドは、Cisco Contact Center Enterprise 製品に焦点をおいています。このガイドで別のシステムについて説明する場合は、包括的なビューは提供されません。完全な Cisco Unified Communications 製品一式に関する情報は、http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html に記載されているシスコソリューション設計書を参照してください。

次の図は、フォールトトレランス Unified CCE 単一サイト展開を示しています。

Unified CCE コンポーネントの冗長性

Note

Contact Center Enterprise ソリューションは、実稼働環境で非冗長性（シンプレックス）導入をサポートしません。テスト環境のみで非冗長展開を使用できます。

この設計は、冗長性に対して、コンポーネントがどう重複するかを示しています。すべての Contact Center Enterprise 導入は、冗長 Unified CM、Unified CCE、Unified CVP のコンポーネントを使用します。冗長性のために、導入でコア システムの半分が失われることがありますが、ソリューションは引き続き機能します。この状態の場合、導入では、Unified CVP を介してコールを VRU セッションまたは引き続き接続されているエージェントに再ルーティングできます。可能な場合は、コンタクトセンターを導入して、Unified CM Publisher でデバイス、コール処理、または CTI Manager サービスが実行されていないことを確認します。

自動フェールオーバーとリカバリを有効にするには、冗長コンポーネントをプライベート ネットワーク パスでインターコネクトします。コンポーネントは、障害検出にハートビートメッセージを使用します。Unified CM は、フェールオーバーとリカバリにクラスタ設計を使用します。各クラスタには、発行元と複数のサブスクライバが含まれます。エージェントの電話とデスクトップはプライマリ ターゲットに登録されますが、プライマリで障害が発生した場合は、バックアップターゲットに自動的に再登録されます。

高可用性と仮想化

仮想化された導入では、高可用性を維持するためにコンポーネントを慎重に配置します。高可用性をサポートするメカニズムは同じです。ただし、1 回の障害から複数のフェールオーバーを最小限に抑えるためのコンポーネントを分散します。ダイレクト アタッチド ストレージ（DAS）のみシステムを展開する場合は、次の点を検討してください。

- VM が失敗すると、VM にインストールされているコンポーネントすべてがダウンします。

- 物理サーバが失敗すると、その VMware vSphere Host にインストールされている VM すべてがダウンします。

共有ストレージを備えるシステムへの導入では、VMware 高可用性機能の一部を使用して、復元力を向上できます。サポートされる VMware 機能の詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.html の「シスコ コラボレーション仮想化」を参照してください。

ハードウェア障害の影響を最小限に抑えるために、次のガイドラインに従います。

- プライマリ VM とバックアップ VM を同じ物理サーバ、シャーシ、またはサイトに配置しないようにします。

- すべてのアクティブコンポーネントを同じ物理サーバ、シャーシ、またはサイト上のフェールオーバーグループに配置しないようにします。

- 同じ物理サーバ、シャーシ、またはサイト上に同じ役割を持つすべての VM を配置しないようにします。

サーバのフェールオーバー

サーバまたはブレードに障害が発生すると、アクティブコールが非アクティブになり、着信通話が中断されます。バックアップコンポーネントがアクティブになると、処理が再開されます。プライマリサーバがリカバリすると、アクティブコールと着信コールの処理はプライマリサーバに返されます。

仮想化の心得

仮想化を計画する際は、次の点に注意してください。

- どのコンポーネントが共存でき、どのコンポーネントが同じ VM で共存させなければならないのかに気を付けます。仮想環境に置けるコンポーネントの配置に関する詳細は、ソリューションの仮想化 Web ページを参照してください。

- Contact Center Enterprise ソリューションは、ゲスト OS（Windows または VOS）の NIC チーミングをサポートしません。

- NIC カードとイーサネットスイッチをオートネゴシエーションに設定します。

- VMware 高可用性の考慮事項

VMware 高可用性の考慮事項

高可用性（HA）により、仮想化された Contact Center Enterprise 環境では、ハードウェアおよびオペレーティングシステムの障害に対してフェールオーバー保護が提供されます。VMware の HA 設定をコンタクトセンター アプリケーション VM に使用できるのは、ソリューションで SAN ストレージを使用している場合のみです。

VMware HA が有効なソリューションを展開する場合は、次の点を検討してください。

- シスコは、VMware Distributed Resource Scheduler（DRS）をサポートしていません。

- vCenter で、[アドミッションコントロールポリシー（Admission Control Policy）] > [フェールオーバーホストの指定（Specify a failover host）] の順に選択します。ESXi ホストに障害が発生すると、このホスト上のすべての VM が予約済みの HA バックアップ ホストにフェールオーバーします。フェールオーバーホストのアドミッションコントロール ポリシーにより、リソースのフラグメント化が回避されます。Contact Center Enterprise リファレンス設計モデルは、ソリューション内の特定の VM の同じ場所を想定します。この VM の同一ロケーション要件は、Contact Center Enterprise キャパシティ要件に基づいてシステムのパフォーマンスを保証します。

- HA バックアップホストは、プライマリサーバと同じデータセンター内に配置する必要がありますが、コンタクト センター ブレードと同じ物理シャーシに配置はできません。vSphere 管理には 10 GB のネットワーキング接続を使用します。

- vCenter で[VM監視ステータス（VM monitoring status）] > [（VM監視のみ）] の順に選択します。

- vCenter で、ホストの分離応答として、すべての仮想マシンをシャットダウンする適切なオプションを選択します。

- 一覧されているとおり、VM の再起動の優先順位を使用して VM を構成します。

VM 設定

VM

VM の再起動の優先順位

Cisco Unified Intelligence Center

低

コンタクトセンター管理ポータルまたはコンタクト センター ドメイン マネージャ

低

Unified CVP レポートサーバ

低

Unified CCE PGs

中

Cisco Finesse

中

Unified CVP サーバ

高

Unified CCE ルータおよび Logger

高

Cisco IdS

中

Cisco Unified CallManager

高

Cisco Live データ

低い

Cisco Customer Collaboration Platform

低い

リファレンス設計に準拠したソリューション用のネットワーク設計

- テスト済みリファレンス構成

- PSTN ネットワーク設計の考慮事項

- Active Directory と高可用性

- Contact Center Enterprise ネットワークアーキテクチャ

- ネットワーク障害時の Unified CCE フェールオーバー

テスト済みリファレンス構成

この項では、UCS 導入のネットワーク構成に関するガイダンスを提供します。また、フォールトトレランスと冗長性の情報が含まれます。

- Cisco UCS B-Series サーバのネットワーク要件

- C シリーズ

Cisco UCS B-Series サーバのネットワーク要件

次の図は、アプリケーションローカル OS NIC からデータセンター ネットワーク スイッチング インフラストラクチャへの仮想から物理への通信パスを示しています。

この設計では、アクティブ/アクティブモードで 2 つの VMNIC を使用する 1 つの仮想スイッチを使用します。この設計では、VMware vSwitch のポートグループ VMNIC オーバーライドメカニズムを使用するファブリック インターコネクトを介して、パブリックネットワークとプライベートネットワークのパスの多様性を調整します。この設計では、ファブリック インターコネクトを介する単一パスの損失による両方のネットワークの障害を回避するため、パブリックネットワークとプラットフォームのパスの多様性が必要です。

Cisco UCS B-Series サーバのネットワーク要件

UCS B ファブリック インターコネクトを備えたコンタクトセンターは次をサポートします。

- エンドホストモードでのファブリック

- イーサネット インターフェイスは 1/10 GB で、ギガビット イーサネット スイッチに接続されている必要があります。

- UCS Manager の vNIC に有効なファブリック フェールオーバー

（注）

アップデート 1 以降、Nexus 1000v および Nexus 1000v を基に下その他シスコ分散仮想スイッチは、ESXi 6.5 との互換性はありません。詳細については、サードパーティ vSwitch の中止に関する VMware の項目を参照してください。

- データセンタースイッチの構成

データセンタースイッチの構成

Contact Center Enterprise は、UCS B シリーズ ファブリック インターコネクトからデータベーススイッチまでイーサネットアップリンク構成用の設計をいくつもサポートしています。設計上、仮想スイッチの VLAN タグ付けが必要です。データセンタースイッチ機能に応じて、EtherChannel/Link Aggregation Control Protocol（LACP）または Virtual PortEther（vPC）のいずれかを使用できます。

UCS ファブリック インターコネクトのパブリック ネットワーク アップリンクとプライベート ネットワーク アップリンクに必要な設計は、Common-L2 設計を使用します。この設計では、両方の VLAN がデータセンタースイッチの 1 つのペアにトランクされます。サービスプロバイダーは、同じリンク上の（VMwareを含む）別の管理およびエンタープライズ ネットワークをトランクすることを選ぶか、これらネットワークを分離するための Disjoint-L2 を使用する場合があります。ここでは Common-L2 モデルのみを使用しますが、どちらの設計もサポートされています。

C シリーズ

次の図は、UCS C-Series サーバのすべてのソリューション向けリファレンス設計と vSphere vSwitch 設計のネットワーク実装を示しています。

Cisco UCS C-Series サーバのネットワーク要件

この設計では、アクティブ/スタンバイ構成の仮想マシン ネットワーク インターフェイス コントローラ（VMNIC）インターフェイスの VMware NIC Teaming（負荷分散なし）を使用します。このデバイスは、ネットワークへの代替および冗長ハードウェアパスを使用します。

ネットワーク側の実装は、この設計と異なる場合があります。ただし、冗長性が必要であり、パブリックネットワークとプライベートネットワーク通信の両方に影響を与えるシングル ポイント障害を持つことはできません。

イーサネット インターフェイスは 1/10 GB で、ギガビット イーサネット スイッチに接続されている必要があります。

UCS C シリーズのネットワーキングの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.html のソリューション向けのシスコ コラボレーション仮想化ページを参照してください。

PSTN ネットワーク設計の考慮事項

高可用性のコンタクトセンター設計は、データ、マルチメディア、音声トラフィック用のネットワーク インフラストラクチャから開始します。ネットワーク インフラストラクチャの「シングルポイント障害」は、コンタクトセンターに設計したその他高可用性機能を低く評価します。PSTNから開始し、着信コールに、初期処理とキューイングのために Unified CVP に到達するための複数のパスがあることを確認します。

それぞれ別個の Cisco Unified Border Element（CUBE）に接続する、少なくとも 2 つの SIP トランクを備えた設計が理想です。CUBE トランクまたは SIP トランクに障害が発生した場合、PSTN は残りの SIP トランクを経由してすべてのトラフィックをルーティングできます。すべての SIP トランクを大規模トランクグループとして構成定するか、他の SIP トランクへの再ルーティングまたはオーバーフロー ルーティングを構成することで、PSTN ルートを設定します。Cisco UBE に障害が発生した場合でも SIP トランクが起動している場合、また、冗長 CUBE を各 SIP トランクに接続して、キャパシティを維持できます。

一部のエリアでは、PSTN は、複数の SIP トランクを単一サイトに提供しない場合があります。その場合は、SIP トランクを Cisco Unified SIP Proxy（CUSP）に接続できます。その後、複数の CUBEs を CUSP に接続して、冗長性を提供できます。

CUBE は、初回処理とキューリングのために Unified CVP にコールを渡します。各 CUBE を、負荷分散用の個別の Unified CVP で登録します。さらにフォールトトレランスを高くするには、バックアップとして別の Unified CVP と一緒に各 CUBE を登録するか、CUBE で SIP サーバグループを構成します。CUBE を Unified CVP に接続できない場合は、TCL スクリプトを使用していくつかのコール処理を実行することもできます。TCL スクリプトでは、コールを別のサイトまたはダイヤル番号に再ルーティングできます。スクリプトは、ローカルに保存されている .wav ファイルを発信者に再生して通話を終了することもできます。

高可用性の入力点

CUBE、Unified CVP、および音声ネットワークの詳細については、https://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html の「『Cisco Collaboration System Solution Reference Network Designs』」を参照してください。

Cisco Unified Survivable Remote Site Telephony（SRST）

Unified CM に対して Cisco Unified Survivable Remote Site Telephony（SRST）オプションを使用する音声ゲートウェイは、同様のフェールオーバープロセスに従います。ゲートウェイが制御サブスクライバから切断されている場合、ゲートウェイは SRST モードにフェールオーバーします。フェールオーバーによってすべての音声コールがドロップされ、ゲートウェイが SRST モードにリセットされます。電話機をローカル呼制御のためにローカル SRST ゲートウェイにリホームします。

SRST モードで実行されている間、Unified CCE は、エージェントがデスクトップから CTI 接続を持っているかのように動作します。ルーティング アプリケーションは、エージェントの準備が完了しておらず、これらエージェントに通話が送信されていないことを検出します。ゲートウェイとサブスクライバが接続を再確立すると、サブスクライバはゲートウェイと電話機を再度制御することで、エージェントが再接続できます。

Active Directory と高可用性

Contact Center Enterprise 設定と Active Directory 間のネットワークリンクに障害が発生した場合、高可用性に影響する次の点を考慮してください。

- リンク障害中、コールトラフィックへの影響はありません。

- ドメイン内の VM はドメイン コントローラ ログイン情報を使用してサインインを制限します。キャッシュされたログイン情報を使用してサインインできます。

- リンクの障害前に Unified CCE サービスを停止する場合、Unified CCE サブコンポーネントを開始する前にリンクを復元する必要があります。

- ローカルの PG 設定にアクセスしたり、Unified CCE Web 設定にサインインすることはできません。

- Unified CCE サービスがアクティブである一方でリンクに障害がある場合、Unified CCE Web 設定、構成ツールそしてスクリプトエディタへのアクセスはできません。

- Unified CCMP によってポータルへのサインインが許可されていても、レポートページへのアクセスはできません。

- 管理者およびスーパーユーザは、Cisco Unified Intelligence Center OAMP ポータルで、Reporting Configuration 以外の任意の属性にアクセスまたはそれを構成できます。

- スーパーバイザは、Cisco Unified Intelligence Center Reporting ポータルにサインインできません。ただし、すでにログインしているスーパーバイザはレポートにアクセスできます。

Contact Center Enterprise ネットワークアーキテクチャ

Cisco Contact Center Enterprise ソリューションは、リアルタイムのデータ転送要件を満たすネットワークインフラストラクチャに依存する分散型、強い、または障害性のネットワーク アプリケーションです。適切に設計されたコンタクトセンター エンタープライズ ネットワークには、適切な帯域幅、低遅延、および特定の UDP および TCP トラフィックを優先する優先順位付けスキームが必要です。設計要件により、冗長サブコンポーネント間でフォールト トレラント メッセージが確実に同期されます。これらの要件により、時間に依存するステータスデータ（ルーティングメッセージ、エージェントの状態、コール統計、トランク情報など）のシステム全体に配信が確保されます。

ソリューションでは、WAN と LAN のトラフィックは次のカテゴリに分類されます。

音声およびビデオトラフィック

音声コール（音声キャリアストリーム）は、PSTN ゲートウェイ ポート、Unified CVP ポート、IP Phone などのさまざまなエンドポイント間で実際の音声サンプルを処理する Real-time Transport Protocol（RTP）パケットで構成されています。このトラフィックには、サイレントモニタまたは録音されたエージェントコール用の音声ストリームが含まれます。

呼制御トラフィック

呼制御トラフィックには、コールのエンドポイントに応じて、いくつかのプロトコル（MGCP または TAPI/JTAPI）のデータパケットが含まれます。呼制御には、コールの設定、保守、ティアダウン、またはリダイレクトを行う機能が含まれています。呼制御トラフィックには、音声コールを周辺機器（エージェントやサービスなど）や他のメディア ターミネーション リソース（Unified CVP ポートなど）にルートするルーティングおよびサービス制御メッセージが含まれます。制御トラフィックには、周辺機器リソースステータスのリアルタイム更新も含まれます。

データ トラフィック

データトラフィックには、エージェントデスクトップ用の電子メール、Web アクティビティ、SIP シグナリング、および CTI データベース アプリケーション トラフィックが含まれます。優先データには、レポートや構成の更新イベントなど、非リアルタイムシステム状態のデータが含まれます。

この項では、次の間のデータフローについて説明します。

- リモート周辺機器ゲートウェイ（PG）および Unified CCE Central Controller（CC）

- PG または CC 冗長ペアの側面

- デスクトップ アプリケーションと Finesse サーバ

メディア（音声およびビデオ）のプロビジョニングの詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html の Cisco Unified Contact Center Enterprise アドミニストレーション ガイド を参照してください。

- ネットワークリンクの高可用性に関する検討事項

- IP ベースの優先順位とサービス品質

- UDP ハートビートおよび TCP キープアライブ

- HSRP が有効なネットワーク

ネットワークリンクの高可用性に関する検討事項

Unified CCE で採用されているフォールト トレラント アーキテクチャには、2 つの独立した通信ネットワークが必要です。これらのネットワークは、個別の物理ネットワークです。プライベートネットワークでは、コンポーネント間の同期の維持と復元に必要なトラフィックを処理します。また、メッセージ配信システム（MDS）を介したクライアント通信も処理します。（別のパスを使用する）パブリックネットワークは、セントラルコントローラと PG 間のトラフィックを処理します。パブリックネットワークは、フォールトトレランス ソフトウェア向けの代替ネットワークとしても機能し、コンポーネントの障害とネットワークの障害を区別します。高可用性を実現するには、パブリックネットワークに冗長接続を含める必要があります。各接続が異なるキャリアを使用するのが理想です。

Note

パブリックネットワークは、目に見えるネットワークと呼ばれることもあります。

次の図は、Contact Center Enterprise ソリューション向けのネットワークセグメントを示しています。PG とセントラルコントローラの冗長ペアは、地理的に分かれています。

Unified CCE システムのパブリックおよびプライベート ネットワーク セグメントの例

この場合、パブリックネットワークは、セントラルコントローラ、PG、および Administration & Data サーバ間のトラフィックを処理します。パブリックネットワークは、同期制御トラフィックは処理しません。パブリックネットワーク WAN リンクには、PG、Administration & Data サーバをサポートするための適切な帯域幅が必要です。IP ベースのプライオリティキューイングまたは QoS のどちらかをかならず使用して、コンタクトセンター トラフィックが、遅延およびジッターの両方に対して許容可能な許容度内で処理されているかを確認します。

プライベートネットワークは、セントラルコントローラまたは PG の冗長サイド間でトラフィックを処理します。このトラフィックは、主に同期されたデータと制御メッセージによって構成されています。また、トラフィックは、分離された状態から復旧する際に、冗長サイドの再同期に必要な状態転送も伝達します。WAN を使用して展開する場合、プライベートネットワークは、Contact Center Enterprise ソリューションの全体的な応答で重要となります。ネットワークには、厳しい遅延要件があります。したがって、IP ベースのプライオリティキューイングまたは プライベートネットワーク リンク上の QoS のどちらかを使用する必要があります。

必要なフォールトトレランスを実現するには、プライベート WAN リンクがパブリック WAN リンクから完全に独立している必要があります（別々の IP ルータ、ネットワーク セグメントまたはパスなど）。独立した WAN リンクによって、シングルポイント障害が、パブリックネットワークとプライベートネットワーク間で完全に分離されます。ルート済みネットワークを通過するパブリックネットワーク WAN セグメントを展開すると、ネットワーク全体の PG とセントラルコントローラ間のルートの多様性を維持できます。複数のセッションで共通のパス選択肢と共通の障害ポイントが発生するルートは避けてください。

セントラルコントローラの 1 つのサイドにローカルな PG および Administration & Data サーバは、公共のイーサネットを介してローカルのセントラルコントローラに接続し、公共の WAN リンクを介してリモートのセントラルコントローラに接続します。オプションで、セントラルコントローラ LAN セグメントから分離された PG および Administration & Data サーバにブリッジを展開して、LAN の機能停止に対する保護を強化できます。

- パブリック ネットワーク トラフィック フロー

- プライベート ネットワーク トラフィック フロー

- マージされたネットワーク接続

パブリック ネットワーク トラフィック フロー

アクティブな PG は、エージェント、コール、キューなどについて状態情報を使用して、セントラル コントローラ コール ルータを連続的に更新します。このトラフィックはリアルタイムトラフィックです。PG は、構成に基づいた間隔で履歴データを送信します。履歴データの優先順位は低いですが、次の間隔が始まる前にセントラルサイトにリーチする必要があります。

PG が開始されると、セントラルサイトはその構成データを提供することで監視するリソースを把握します。この構成をダウンロードすることで、ネットワーク帯域幅の使用量が大幅に増加する可能性があります。

パブリックトラフィックの概要を次に示します。

- 高優先順位トラフィック：ルーティングおよびデバイス管理プロトコル（DMP）制御トラフィックが含まれます。パブリック高優先順位 IP アドレスを使用して TCP で送信されます。

- ハートビートトラフィック：パブリック高優先順位の IP アドレスを使用したポート範囲が 39500 ～ 39999 の UDP メッセージ。ハートビートは、PG とセントラルコントローラ間の両方向で、400ミリ秒の間隔で送信されます。

- 中優先順位トラフィック：PG からセントラルコントローラへのリアルタイムトラフィックおよび構成要求が含まれます。中優先順位トラフィックは、パブリック高優先順位 IP アドレスを使用して TCP で送信されます。

- 低優先順位トラフィック：履歴データトラフィック、セントラルコントローラからの構成トラフィック、およびコールクローズ通知が含まれます。低優先順位トラフィックは、非パブリック高優先順位 IP アドレスを使用して TCP で送信されます。

プライベート ネットワーク トラフィック フロー

プライベートネットワークは、重要なメッセージ配信サービス（MDS）トラフィックを処理します。

次に、プライベートトラフィックの要約を示します。

- 高優先順位トラフィック — ルーティング、MDSコントロールトラフィック、および PIM CTI サーバ、露がなどの MDS クライアントプロセスからの別のトラフィックを含みます。プライベート高優先順位 IP アドレスを使用して TCP で送信されます。

- ハートビートトラフィック：プライベート高優先順位の IP アドレスを使用したポート範囲が 39500 ～ 39999 の UDP メッセージ。ハートビートは、デュプレックスサイド間を隔週 100 ミリ秒間隔で送信されます。

- 中優先順位および低優先順位トラフィック — セントラル コントローラの場合、このトラフィックには、ルーティング クライアントから供給される共有データに加え、Call Router 状態転送（独立したセッション）などの（ルート制御以外の）Call Router メッセージが含まれます。OPC（PG）の場合、このトラフィックには、ルート制御以外の共有周辺機器トラフィックおよびレポーティングトラフィックが含まれます。このクラスのトラフィックは、中優先順位および低優先順位として指定されている TCP セッション内で、それぞれプライベート高優先順位以外の IP アドレスを使用して送信されます。

- 状態転送トラフィック：Router、OPC、およびその他の同期プロセスの状態同期メッセージ。プライベート高優先順位以外の IP アドレスを使用して TCP で送信されます。

マージされたネットワーク接続

Unified CCE コンポーネントは、パブリックネットワークとプライベートネットワークを使用して通信します。これらのネットワークは、個別の物理ネットワークである必要があります。高可用性を実現するには、パブリックネットワークに冗長接続を含める必要があります。各接続が異なるキャリアを使用するのが理想です。

QoS と帯域幅が正しく設定されている場合、設計でパブリック WAN またはプライベート WAN リンクを他の企業トラフィックとマージできます。非コンタクト センター トラフィックをマージするリンクを使用する場合は、パブリックトラフィックとプライベートトラフィックを別のネットワーク上に保持します。ただし、プライベート ネットワーク トラフィックを低優先順位および高優先順位のデータパスに分割してはいけません。同じリンクが、特定のコンポーネントのすべてのプライベート ネットワーク トラフィックを実行する必要があります。優先順位の低いトラフィックと優先順位の高いトラフィックを異なるリンクに送信すると、コンポーネントのフェールオーバー動作が無効になります。同様に、各周辺機器ゲートウェイからコールルータの低優先順位および高優先順位のアドレスまで、すべての低優先順位および高優先順位のトラフィックが同じパスをとおる必要があります。

パブリックネットワークに障害が発生した場合は、パブリック Unified CM トラフィックをプライベートネットワークに一時的にフェールオーバーできます。追加のトラフィックに対応するために、プライベートネットワークのサイズを設定します。パブリック トラフィックがプライベートネットワークにフェールオーバーした場合は、パブリックネットワークを可能な限り迅速に復元して通常動作に戻します。プライベートネットワークにも障害が発生した場合は、コンタクトセンター内で、1 つの Logger データベースの障害など、不安定性やデータの損失が発生します。

IP ベースの優先順位とサービス品質

Contact Center Enterprise ソリューションでは、すべてのプライベートネットワークで QoS が必要です。パブリックリンクでは、2000 エージェントおよび 4000 エージェントリファレンス設計で QoS を使用できます。12,000 エージェントリファレンス設計のパブリックリンクでは、QoS によってサーバ障害の検出が遅れる可能性があります。

大量の低優先順位のトラフィックが高優先順位のトラフィックの前に来ると、遅延によってフォールトトレランス動作がトリガーされる可能性があります。これらの遅延を回避するには、パブリックネットワークとプライベートネットワーク内の各 WAN リンクに対する優先順位付けスキームが必要です。Contact Center Enterprise ソリューションは、IP ベースの優先順位付けと QoS をサポートします。

低速のネットワークフローでは、単一の大きな（たとえば、1500バイト）パケットが、ネットワーク上で消費する時間は 100 ミリ秒を超える場合があります。この遅延は、1 つ以上のハートビートの明らかな損失の原因となる場合があります。この状況を回避するために、コンタクトセンターは優先順位の低いトラフィックに対して小さい最大伝送ユニット（MTU）を使用します。これにより、より早く優先順位の高いパケットをネットワークに接続できます。（回路の MTU サイズは、PG 設定で構成した回路帯域幅に基づいて計算されます）。

ネットワークに対して間違った優先順位付けをすると、一般的にコールタイムアウトやハートビートの損失の原因となる場合があります。アプリケーションの負荷が増加したり、ネットワーク上に共有トラフィックが配置される時に、問題が増加します。また、遅延条件が極端な場合、送信側でアプリケーション バッファ プールを使い果たすこともあります。

Contact Center Enterprise は、高、中、低の 3 つの優先順位を使用します。QoS を指定しない場合、ネットワークは、送信元および接続先 IP アドレス（別の IP 接続先アドレスに送信される優先順位の高いトラフィック）が特定した 2 つの優先順位のみ認識します。UDP ハートビートに関しては、特定の UDP ポート範囲が特定した 2 つの優先順位のみ認識します。IP ベースの優先順位付けでは、プライオリティキューイングを使用して IP ルータを構成し、優先順位の高い IP アドレスを持つ TCP パケットと他のトラフィックよりも UDP ハートビートを優先します。この優先順位付けスキームを使用する場合、使用可能な帯域幅の合計の 90% が優先順位の高いキューに付与されます。

QoS に対応したネットワークでは、IP アドレスではなく QoS のマーキングに基づいて、パケットに優先順位が付けられた処理（キューイング、スケジューリング、およびポリシー設定）が適用されます。コンタクトセンターは、プライベートおよびパブリック ネットワーク トラフィックに対してレイヤ 3 DSCP のマーキング機能を提供します。トラフィックマーキングは、ネットワークが QoS 認識のため、各ネットワーク インターフェイス コントローラ（NIC）にデュアル IP アドレスを設定する必要がなくなることを意味します。ただし、代わりにネットワークエッジでトラフィックにマークを付けすると、IP アドレスに基づいたアクセス制御リストを使用してパケットを識別するために、デュアル IP 構成が依然として必要です。

Note

Microsoft Windows Packet Scheduler が（PG、セントラルコントローラ トラフィックのみに）有効な場合、レイヤ-2 802.1p のマーキングも可能です。ただし、これはサポートされていません。Microsoft Windows Packet Scheduler は、Unified CCE には適していません。802.1p マーキングは広く使用されておらず、DSCP マーキングが使用可能な場合は、必要ありません。

データトラフィックの適切なネットワーク設計に関しては、http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-borderless-networks/index.html のネットワーク インフラストラクチャおよび Quality of Service（QoS）ドキュメントを参照してください。

UDP ハートビートおよび TCP キープアライブ

UDP ハートビート設計は、パブリックネットワークリンクに障害が発生したかどうかを検出します。ハートビート損失の方向に基づいて、接続の両端から検出を行うことができます。接続の両端は、定期的な間隔（ 400 ミリ秒ごと）でハートビートを反対側に送信します。各端は、他の端から類似したハートビートを探します。どちらかの端がハートビート期間の5倍の期間後にハートビートを受信しない場合、その端に問題が発生したとみなされ、アプリケーションはソケット接続を閉じます。この時点で、閉じられた側から通常、TCP Reset メッセージが生成されます。さまざまな要因によって以下のようなハートビート損失の原因となります。

- ネットワーク障害。

- ハートビート障害を送信するプロセス。

- 送信プロセスを実行している VM のシャットダウン。

- UDP パケットの不適切な優先順位付け。

ハートビートには、複数のパラメータが関連付けられています。一般に、これらのパラメータはシステムのデフォルト値のままにします。これらの値の一部は、接続が確立されると指定されます。その他のパラメータは、Windows レジストリで設定できます。最も重要な値は、次の 2 つです。

- ハートビート間の時間の長さ

- 障害を示す既存しないハートビートの数（現在は、5 にハードコード済み）

冗長コンポーネント間のプライベートハートビート間隔のデフォルト値は、100 ミリ秒です。片側は、回路の障害を検出し、もう一方は、500 ミリ秒後に障害を検出します。セントラルサイトと周辺機器ゲートウェイ間のデフォルトのハートビート間隔は、400 ミリ秒です。この場合、回路障害のしきい値に到達するまでに 2 秒かかります。

Contact Center Enterprise QoSの実装では、TCP キープアライブメッセージ を使用して UDP ハートビートを置き換えます。パブリック ネットワーク インターフェイスは、ハートビートまたはキープアライブメカニズムの一貫性を実行します。ただしプライベート ネットワーク インターフェイスは、キープアライブを実行します。QoS がパブリック ネットワーク インターフェイスで使用可能状態になっている場合は TCP キープアライブメッセージが送信され、使用不可状態の場合は UDP ハートビートが保持されます。

TCP スタックで提供される TCP キープアライブは、非アクティブ状態を検出すると、サーバまたはクライアント側を終了する原因となります。TCP キープアライブ機能は、接続が一定の期間アイドル状態が続いた後、接続を通してプローブパケットを送信します。別側からのキープアライブ応答が聞こえない場合、接続がダウンしたとみなされます。Windows サーバでは、接続ごとにキープアライブパラメータを指定できます。Contact Center Enterprise パブリック接続の場合、キープアライブタイムアウトは、（5 * 400）ミリ秒に設定され、2 秒の障害検出時間と UDP ハートビートが一致します。

QoS が有効になっている状態で TCP キープアライブに移行する理由は次のとおりです。

- コンバージド ネットワークでは、ネットワークの輻輳状態を処理するルータアルゴリズムが、TCP と UDP に異なる影響を与える場合があります。その結果、UDP ハートビートトラフィックで発生する遅延と輻輳により、タイムアウトによる接続障害が発生する可能性があります。

- UDP ハートビートを使用すると、ファイアウォール環境での展開が複雑になります。ハートビート通信への動的ポート配分では、幅広いポート番号を開くことができるので、ファイアウォールのセキュリティが低下します。

Note

コンタクトセンター トラフィックを処理する WAN では、WAN アクセラレータを使用できません。WAN アクセラレータは、障害検出機能を効果的に無効にする信号を送信できます。

HSRP が有効なネットワーク

ソリューションネットワークがデフォルトゲートウェイの Hot Standby Router Protocol（HSRP）を使用する場合は、次の要件に従います。

- HSRP ホールド時間と関連する処理遅延を、間隔の 5 倍未満（プライベートネットワークでは 100 ミリ秒、パブリックネットワークは 400 ミリ秒）に設定します。このレベルでは、HSRP アクティブルータのスイッチオーバー中にプライベートネットワーク通信が停止しないようにします。

プライベートまたはパブリックネットワークの停止通知を超えるコンバージェンス遅延があると、HSRP フェールオーバー時間が検出しきい値を超えて、フェールオーバーが発生する可能性があります。HSRP 構成にプライマリおよびセカンダリの指定があり、プライマリパスルータに障害が発生した場合、HSRP は、可能な場合に限り、プライマリパスを復元します。この復元は、2 回目の停止検出につながる場合があります。

プライベートネットワークの場合は 500 ミリ秒近く、パブリックネットワークの場合は 2 秒に近い HSRP コンバージェンス遅延のあるプライマリおよびセカンダリ指定を使用しないでください。ただし、検出されたしきい値（透過的な HSRP フェールオーバーが発生する結果となります）を下回るコンバージェンス遅延では、優先パス構成は必須ではありません。次のアプローチが理想的です。パスの値とコストが同じ場合は、ルータを対照的に有効化し続けます。ただし、使用可能な帯域幅とコストが 1 つのパスを好む場合は（パスの移行が透過的である）、プライマリパスとルータの指定を推奨します。

- フォールトトレラント設計では、プライベートネットワークは物理的にパブリックネットワークから分離している必要があります。したがって、一方のタイプのネットワークトラフィックを他のネットワーク リンクに対してフェールオーバーするように HSRP を構成しないでください。

- コンタクトセンターの帯域幅の要件は、常に HSRP で保証する必要があります。それ以外の場合、システムの動作は不安定となります。たとえば、ロード共有用に HSRP を構成する場合は、最悪の場合の障害が発生した場合に、存続するリンクに十分な帯域幅が残すようにしなければなりません。

ネットワーク障害時の Unified CCE フェールオーバー

ネットワークの障害は、影響を受けるネットワーク全体にトラフィックを送信するコンポーネントに同時に影響します。Unified CCE のサブコンポーネントは、プライベートネットワークとパブリックネットワークの両方のリンクを使用して通信します。

プライベートネットワーク上のトラフィックは、次の機能を実行します。

- コンポーネント起動時の状態転送

- ルータの冗長ペアの同期

- 冗長 Logger データベースの同期

- PG の冗長ペアの同期

パブリックネットワークは、音声データ、コールコンテキストデータ、レポートデータなどのサブコンポーネント間の残りのトラフィックを処理します。パブリックネットワークには、Unified CCE サブコンポーネント間のすべてのパブリック ネットワーク リンクが含まれています。

Note

仮想化されたコンタクトセンターでは、仮想 NIC などの仮想環境での障害からネットワーク障害が発生するか、物理的なリソースの障害によってネットワーク障害が発生します。

- プライベートネットワークの障害対応

- パブリックネットワークの障害対応

- 両方のネットワークの障害への応答

プライベートネットワークの障害対応

プライベートネットワークの障害時、コンタクトセンターはすぐに 各サイドまたは両側が分離対応の運用に移行する状態になります。分けられた運用は、ルータがプライベートネットワークの回復を検出するまで継続されます。ルータと PG の冗長ペアは再同期し、通常運用を再開します。

ルータ A がペア対応側、ルータ B がペア無効側とします。プライベートネットワークに障害が発生すると、ルータ A は次のように動作します。

- ルータ A に多数のデバイスがある場合、デバイスは分離対応運用に移行し、トラフィックの処理を続けます。

- ルータ A にデバイスが多数存在しない場合、デバイスは分非離対応運用に移行し、トラフィックの処理を停止します。

プライベートネットワークに障害が発生すると、ルータ B は次のように動作します。

- ルータ B にデバイスが多数存在しない場合、デバイスは分非離対応運用に移行し、トラフィックは処理されません。

- ルータ B にデバイスが多数存在する場合は、テスト状態になります。ルータ B は、パブリックネットワークを介してルータ A に接続するために、PG が有効になっていると指示します。次に、ルータ B は次のように応答します。

- PG がルータ A に接続して状態を確認できる場合、ルータ B は分離対応状態に移行し、トラフィックの処理を開始します。このケースでは、ルータ A とルータ B の両方が分離対応状態で実行される可能性があります。

- PG がルータ A に接続して、ルータ A が非分離無効状態である場合、ルータ B は分離対応状態に移行し、トラフィックの処理を開始します。

- PG がルータ A に接続して、ルータ A が分離無効状態である場合、ルータ B は非分離対応状態に移行し、トラフィックの処理を停止します。

ルータのフェールオーバー処理中は、存続するルータが分離状態になるまで、ルータのルート要求がキューに入ります。ルータの障害が、VRU またはエージェントにすでの到達している進行中のコールには影響しません。

ルータがアイドル状態になっている場合、対応する Logger がシャットダウンされます。各 Logger は、割り当てられているルータのみと通信します。プライベートネットワーク接続が復元され、分離状態のルータの Logger は、そのデータを使用して、別の Logger を再同期します。プライベートネットワーク接続が、Config_Message_Log テーブルの 14 日の保持期間前にバックアップされた場合、システムは自動で Logger 構成データベースを再同期します。また、プライベートネットワーク接続が 14 日の保持期間以上ダウンしたままの場合、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-maintenance-guides-list.html の「 アドミニストレーション ガイド」で説明のある Unified ICMDBA アプリケーションを使用して Logger 上で構成データを再同期する必要があります。

PG の各冗長ペアでは、有効な PG と無効な PG があります。システムの開始時点で、最初に接続された PG が有効な PG になります。ただし、プライベートネットワークでの障害発生後、冗長ペアの中で最大の重みを持つ PG が有効な PG になります。もう 1 つの PG が無効な PG になります。

パブリックネットワークの障害対応

一般的に、高可用性ネットワークには、パブリックネットワーク用の冗長なチャネルが含まれます。一方のチャネルに障害が発生すると、もう一方のチャネルにシームレスに引き継がれます。2 つのサブコンポーネント間のすべてのチャネルに障害が発生した場合、コンタクトセンターはパブリックネットワークの障害を検知します。

Note

冗長的なパブリックネットワーク無しのコンタクトセンターでは、1 つのチャネルで障害が発生した場合に、コンタクトセンターで障害を検出します。

コンタクトセンターによるパブリックネットワーク障害への対応は、サイト数、機能数、サイトのリンク方法によって異なります。次の項では、より一般的または重要なシナリオについて説明します。

- Unified Communication Managers 間の障害

- WAN を介したクラスタリングの障害

Unified Communication Managers 間の障害

最も大きな問題を引き起こすシナリオには、Unified CM のサブスクライバがパブリックリンクを失うことが挙げられます。機能しているプライベートネットワークでは、ルータとエージェント PG が同期し続けるため、ルータは依然としてすべてのエージェントデバイスを検出できます。このような状況で、ルータは、パブリックネットワーク障害のもう一方の側にあるサブスクライバに登録されているエージェントデバイスにコールを割り当てる場合があります。ただし、ローカル CVP は、パブリックネットワーク障害のもう一方の側にあるエージェントデバイスに接続情報を渡すわけではありません。コールは失敗しますが、ルーティングクライアントは、リモートサブスクライバのエージェントデバイスにルートされたコールとしてマークします。

WAN を介したクラスタリングの障害

間の障害サイト

WAN トポロジを使用したクラスタリングでは、低遅延で十分な帯域幅を備え、高可用性で高い信頼性のある WAN が必要です。パブリックネットワークは、コンタクトセンターのフォールトトレランスには重要です。高可用性の WAN は完全に冗長化されており、通常は別々のキャリア間でシングル ポイント障害はありません。WAN に部分的な障害が発生した場合、冗長リンクでは、サイトのリストに追加しますQoS パラメータ内のフル ロードを処理する機能が必要です。冗長 WAN の代替として、Metro Area Networks（MAN）、高密度波長分割多重（DWDM）またはイーサネット WAN を採用できます。高可用性かつ高い復元力を備えた WANの設計に関しては、Cisco Design Zone の https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-branch-wan/index.html に記載されている「ブランチ WAN の Design Zone」を参照してください。

Note

WiMAX、Munincipal Wi-Fi または VSAT などのワイヤレス WAN は、Contact Center Enterprise ソリューションには使用できません。

サイトのリストに追加します 間のパブリックネットワークに障害が起こった場合、システムは、次の方法で応答します。

1. Unified CM のサブスクライバが障害を検出。サブスクライバは、引き続きローカルで機能し、ローカルのコール処理や呼制御に影響しません。ただし、パブリックネットワーク上で設定されたコールには障害が起こります。

2. ルータおよび PG が、障害を検出。PG は自動的に、データ通信ストリームをローカルルータに再調整します。その後、ローカルルータは、プライベートネットワークの別サイドのルータにデータを渡し、コール処理を続けます。データパスが変更されても PG やルータのフェールオーバーの原因にはなりません。

パブリックネットワークの障害がエージェントに与える影響は、電話機とデスクトップの登録場所によって異なります。

- 最も一般的なケースは、エージェントデスクトップとエージェントの電話機の両方が同じサイド（たとえばサイド A）の PG と サブスクライバに登録されている場合です。サイトのリストに追加します 間のパブリックネットワークに障害が発生した場合、エージェントは、引き続き通常通りコールを処理できます。

- 場合によっては、エージェントデスクトップ（この例ではサイド A）とエージェント電話機（この例ではサイド B）が異なるサイドに登録されることがあります。このような場合、CTI Manager は、パブリックネットワーク上の電話イベントを、別サイドの PG にダイレクトします。サイトのリストに追加します 間のネットワークに障害が発生した場合、電話機はクラスタのサイド A にはリホームされません。電話機はサイド B で操作可能状態のままですが、サイド A のPG はこの電話機を検出できません。Unified CCE サブコンポーネントがエージェントの電話機にコールを送信できなくなったため、Unified CCE は自動的にエージェントをサインアウトします。

- 通常、冗長 Desktop サーバペアは、エージェントデスクトップ接続の負荷分散を行います。そのため、デスクトップの半分は、パブリックネットワークを介してアクティブな CTI サーバを備えた PG に接続する Desktop サーバに登録されます。パブリックネットワークに障害が発生すると、Desktop サーバからリモート CTI サーバへの接続は切断されます。Desktop サーバは、アクティブなエージェントデスクトップを切断して、リモート側にある冗長 Desktop サーバに強制的にリホームします。エージェントデスクトップは自動的に冗長 Desktop サーバを使用します。エージェントデスクトップは、冗長 Desktop サーバへの接続が確立されるまで無効の状態のままとなります。

エージェントサイトの障害

WAN を介したクラスタリングの Contact Center Enterprise トポロジは、エージェントが複数のサイトにリモートで配置されていることを前提としています。各エージェントサイトでは冗長性を確保するためにパブリックネットワーク経由で、両方の サイトのリストに追加します にアクセスする必要があります。完全なネットワーク障害が発生した場合、これらの接続は SRST の基本的な機能も提供します。そのため、エージェントサイトは緊急コールである 911 に電話をかけることができます。

エージェントサイトでサイトのリストに追加します に接続するパブリックネットワークの接続が切断された場合、システムは次の方法で応答します。

1. 切断されたサイトで Unified CM サブスクライバにホーム接続されている IP 電話は、他のサイトのサブスクライバに自動的にリホームされます。リホーミング動作を使用するには、冗長グループを構成します。

2. その切断されたサイトの Desktop サーバに接続されているエージェントデスクトップは、他のサイトの冗長サーバに自動的に再調整されます。（エージェントデスクトップは、再調整プロセス中に無効になります。）

エージェントサイトでサイトのリストに追加します の両方に接続するパブリックネットワークの接続が切断された場合、システムは次の方法で応答します。

1. ローカルの音声ゲートウェイ（VG）は、クラスタへの通信パスの障害を検出します。その後、VG は SRST モードに切り替わり、ローカルダイヤル トーン機能を提供します。

2. Unified CVP を使用すると、VG が Unified CVP サーバへの切断を検出します。その後、VG はローカルの存続可能性 TCL スクリプトを実行して、IME 除外グループを再ルートします。

3. ローカルの PSTN 接続上で、アクティブなコールが切断されたエージェントサイトに入電した場合、そのコールはアクティブなままです。ただし、PG はコールへのアクセスを失い、TCD レコードを作成します。

4. Finesse サーバは、エージェントデスクトップへの接続が失われたことを検出し、エージェントをシステムから自動的にサインアウトします。IP 電話機が SRST モードになっている間は、Contact Center Enterprise エージェントとして機能できません。

両方のネットワークの障害への応答

パブリックネットワークとプライベートネットワークの一部に別々に障害が発生した場合、エージェントとコールへの影響が限定される場合があります。ただし、両方のネットワークに同時に障害が発生した場合、システムの機能は制限されます。この障害は、壊滅的です。このような障害は、組み込みバックアップと復元力を備えた慎重な WAN 設計によって回避できます。

サイト内の両方のネットワークで同時に障害は発生すると、サイトはシャットダウンされます。

2 つのサイト間のパブリックネットワークとプライベートネットワークで同時に障害が発生した場合、システムは次の方法で応答します。

1. 両方のルータが過半数のデバイスをチェックします。各ルータは、ルータに過半数のデバイスがある場合は分離有効モードになり、ルータに過半数のデバイスがない場合は分離無効モードになります。

2. PG は、必要に応じて自動的にデータ通信をローカルルータに再調整します。アクティブルータに接続できない PG は非アクティブになります。

3. Unified CM のサブスクライバは、障害を検出し、ローカルのコール処理と呼制御に影響を与えずに、ローカルで機能し続けます。

4. パブリック WAN リンクを介するアクティブな音声パスメディアを送信する進行中のコールは、リンクで障害が発生します。コールで障害が発生すると、PG は、そのコールに対して TCD レコードを作成します。

5. WAN トポロジを介したクラスタリングでは、各側の Unified CM サブスクライバはローカルコンポーネントのみにアクセスし動作します。

6. コール ルーティング スクリプトは、周辺機器オンライン ステータス チェックを使用してオフラインのデバイス周辺をルートします。

7. ローカル Unified CM サブスクライバに登録されている電話機とデスクトップを備えたエージェントには影響はありません。電話機とデスクトップの再ホーム中、他のすべてのエージェントは、一部またはすべての機能を失います。正確なシステム設定に応じて、このようなエージェントは、自信がサインアウトされていることを認識できる場合があります。

8. Unified CCE は、無効になったサイドに新規コールをルートしません。ただし、CTI ルートポイントの障害時に標準規格の Unified CM リダイレクトを使用するか、入力音声ゲートウェイの Unified CVP 存続可能性 TCL スクリプトを使用すると、これらのコールをリダイレクトまたは処理できます。

イングレス、エグレスおよび VXML ゲートウェイの高可用性に関する考慮事項

高可用性のコンタクトセンター設計は、データ、マルチメディア、音声トラフィック用のネットワーク インフラストラクチャから開始します。ネットワーク インフラストラクチャの「シングルポイント障害」は、コンタクトセンターに設計したその他高可用性機能を低く評価します。PSTNから開始し、着信コールに、初期処理とキューイングのために Unified CVP に到達するための複数のパスがあることを確認します。

それぞれ別個の Cisco Unified Border Element（CUBE）に接続する、少なくとも 2 つの SIP トランクを備えた設計が理想です。CUBE トランクまたは SIP トランクに障害が発生した場合、PSTN は残りの SIP トランクを経由してすべてのトラフィックをルーティングできます。すべての SIP トランクを大規模トランクグループとして構成定するか、他の SIP トランクへの再ルーティングまたはオーバーフロー ルーティングを構成することで、PSTN ルートを設定します。Cisco UBE に障害が発生した場合でも SIP トランクが起動している場合、また、冗長 CUBE を各 SIP トランクに接続して、キャパシティを維持できます。

一部のエリアでは、PSTN は、複数の SIP トランクを単一サイトに提供しない場合があります。その場合は、SIP トランクを Cisco Unified SIP Proxy（CUSP）に接続できます。その後、複数の CUBEs を CUSP に接続して、冗長性を提供できます。

CUBE は、初回処理とキューリングのために Unified CVP にコールを渡します。各 CUBE を、負荷分散用の個別の Unified CVP で登録します。フォールトトレランスをさらに高めるには、バックアップとして各 CUBE を異なる Unified CVP に登録します。CUBE を Unified CVP に接続できない場合は、TCL スクリプトを使用していくつかのコール処理を実行することもできます。TCL スクリプトでは、コールを別のサイトまたはダイヤル番号に再ルーティングできます。スクリプトは、ローカルに保存されている .wav ファイルを発信者に再生して通話を終了することもできます。

高可用性の入力点

CUBE、Unified CVP および一般的な音声ネットワークに関しては、http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html の 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

Cisco Unified Survivable Remote Site Telephony（SRST）

Unified CM に対して Cisco Unified Survivable Remote Site Telephony（SRST）オプションを使用する音声ゲートウェイは、同様のフェールオーバープロセスに従います。ゲートウェイが制御サブスクライバから切断されている場合、ゲートウェイは SRST モードにフェールオーバーします。フェールオーバーによってすべての音声コールがドロップされ、ゲートウェイが SRST モードにリセットされます。電話機をローカル呼制御のためにローカル SRST ゲートウェイにリホームします。

SRST モードで実行されている間、Unified CCE は、エージェントがデスクトップから CTI 接続を持っているかのように動作します。ルーティング アプリケーションは、エージェントの準備が完了しておらず、これらエージェントに通話が送信されていないことを検出します。ゲートウェイとサブスクライバが接続を再確立すると、サブスクライバはゲートウェイと電話機を再度制御することで、エージェントが再接続できます。

- イングレスおよびエグレスゲートウェイの高可用性

- VXML ゲートウェイの高可用性

イングレスおよびエグレスゲートウェイの高可用性

イングレスゲートウェイは、PSTN からの通話を受け入れ、その通話を VRU 処理およびコールルーティングのために Unified CVP にリダイレクトします。同じゲートウェイは、特定のコールフロー内のエグレスゲートウェイとして機能できます。

Note

イングレスゲートウェイは、発信ゲートウェイと呼ばれる場合があります。

Contact Center Enterprise リファレンス設計では、イングレスゲートウェイは、SIP を使用して、Unified CVP と通信します。SIP プロトコルには冗長性機能が組み込まれていません。SIP は、冗長性をゲートウェイとコール処理コンポーネントに依存します。次のテクニックを使用すると、コールシグナリングを物理インターフェイスから独立させることができます。一方のインターフェイスに障害が発生した場合、もう一方のインターフェイスがトラフィックを処理します。

ダイヤルピアバインド

ダイヤルピアレベルバインドでは、各ダイヤルピアに対して異なるバインドを設定します。すべてのサブネットから到達可能な 1 つのインターフェイスを保持する必要はありません。ダイヤルピアは、さまざまなネットワークからのトラフィックを分離するのに役立ちます（たとえば、サービスプロバイダーの SIP トランクおよび SIP トランクから Unified CM または CVP へ）。次の例は、ダイヤルピアレベルのバインドを示しています。

Using voice-class sip bind
dial-peer voice 1 voip
voice-class sip bind control source-interface GigabitEthernet0/0

グローバルバインド

他のゲートウェイでは、グローバルバインドを使用できます。各ゲートウェイインターフェイスを別の物理スイッチに接続して冗長性を提供します。各ゲートウェイインターフェイスは、異なるサブネット上に IP アドレスを持っています。IP ルータは、静的ルートまたはルーティング プロトコルのいずれかによって、ループバックアドレスへの冗長ルートを使用します。

ルーティングプロトコルを使用すると、ゲートウェイと交換されるルートの数を確認できます。その場合は、フィルタを使用してルーティングの更新を制限します。ゲートウェイにループバックアドレスのみをアドバタイズさせ、受信ルートをアドバタイズしないようにします。次の例に示すように、SIP シグナリングを仮想ループバック インターフェイスにバインドします。

voice service voip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0

- フェールオーバー中のコール存続可能性

フェールオーバー中のコール存続可能性

ゲートウェイに障害が発生した場合、コール廃棄には次の条件が適用されます。

- 進行中のコール — PSTN スイッチは、このゲートウェイのすべての T1/E1 トランクへの D-チャネルを失います。アクティブ コールは保存されません。

- 着信通話 — PSTN キャリアは、代替ゲートウェイの T1/E1 に通話を転送します。PSTN スイッチのトランクを保持する必要があり、ダイヤルプランは正しく構成されている必要があります。

VXML ゲートウェイの高可用性

VXML ゲートウェイは、Unified CVP VXML サーバまたは外部 VXML ソースから VXML ドキュメントを解析およびレンダリングします。VXML ドキュメントのレンダリングには、次を含めます。

- 事前録音されたオーディオファイルの取得と再生

- ユーザ入力の収集と処理

- 音声認識および動的音声合成変換のために ASR/TTS サーバに接続

VXML ゲートウェイと Unified CVP コールサーバ間のパスではロードバランサは使用できません。

Unified CVP コールサーバからイングレスゲートウェイを区別するトポロジでは、コールサーバサイトで VXML ゲートウェイを同一場所に配置します。この配置により、メディアストリームが WAN 全体の帯域幅を使用するのを防ぎます。

VXML ゲートウェイが失敗すると、コールは次のように影響を受けます。

- 進行中のコール：イングレスゲートウェイの存続可能性機能は、デフォルトで進行中のコールを代替のロケーションにルートします。

- 着信コール：着信コールは、代替 VXML ゲートウェイを検索します。

CVP 高可用性の考慮事項

Contact Center Enterprise リファレンス設計 は、コールの扱いとキューに対して Unified CVP を使用します。CVP は、JTAPI 呼制御向けの Unified CM ではなく、呼制御向けの SIP を使用します。

Unified CVP 高可用性の展開

Unified CVP は、次のシステムコンポーネントを使用できます。

- Cisco Unified Border Element（CUBE）は、SIP トランキングへの移行をサポートします。CUBE は、PSTN とコンタクトセンター間でインターワーキング、責任分界、セキュリティサービスを提供します。

- Cisco Voice Gateway（VG）は、DM PSTN トランクを終了して、IP ネットワーク上の IP ベースのコールに変換します。Unified CVP は、SIP をサポートする特定の Cisco IOS 音声ゲートウェイを使用して、より柔軟な呼制御を実現します。Unified CVP によって制御される VG は、Cisco IOS の組み込み Voice Extensible Markup Language（VoiceXML）ブラウザを使用して、発信者やコールキューを処理します。CVP は、Cisco IOS VG の Media Resource Control Protocol（MRCP）インターフェイスを利用して、自動音声認識（ASR）と音声合成（TTS）機能を追加することもできます。

- コールがイングレスゲートウェイと別のエンドポイントゲートウェイまたは Unified CCE エージェント間で切り替わった際、CVP サーバは、呼制御シグナリングを提供します。CVP サーバは、Unified CCE VRU 周辺機器ゲートウェイ（PG）にもインターフェイスを提供します。CVP サーバは、特定の Unified CCE VRU コマンドを VXML コードに変換して、VG 上でレンダリングします。ソリューションの一部として CVP サーバは、SIP を使用してゲートウェイと通信できます。高可用性の議論については、次のサブコンポーネントとして CVP サーバを表示できます。

- SIP サービス：すべての着信 SIP メッセージングと SIP ルーティングを担当します。

Note

コールサーバを構成し、アウトバウンド ダイヤル プランの解決に対する SIP プロキシサーバを使用します。SIP プロキシサーバは、構成オーバーヘッドを最小限に抑えます。

IP アドレスまたは DNS SRV に基づいて静的ルートを使用するためにも構成します。コールサーバは、静的ルートの構成情報を共有しません。静的ルートを変更する場合は、各コールサーバの SIP サービスで変更する必要があります。

- ICM サービス：ICM へのインターフェイスを担当します。ICM サービスは、GED-125 を使用して VRU PG と通信し、ICM で IVR 制御が可能になります。

- CVP メディアサーバ は、VXML 処理の一部として、事前に定義された音声ファイルを音声ブラウザに提供する Web サーバとして機能します。Cisco コンテンツサービススイッチ（CSS）製品を使用して メディアサーバをクラスタ化できます。クラスタリングすることで、すべての音声ブラウザからアクセスできるように 1 つのURLの背後に複数の メディアサーバをプールできます。

- CVP サーバは、Unified CVP VXML ランライム環境をホストします。VXML サービス作成環境では、CVP Call Studio アプリケーションで Eclipse Toolkit ブラウザを使用します。ランタイム環境は、動的 VXML アプリケーションを実行し、外部システムおよびデータベースアクセスに対する Java サービスおよび Web サービス呼び出しを処理します。

- CVP で使用される Cisco Unified SIP Proxy（CUSP）サーバは、音声ブラウザを選択して、特定のダイヤル番号に関連付けます。ネットワークに入電すると、VG は Unified SIP プロキシにクエリして、ダイヤルされた番号に基づいてコールを送信する場所を特定します。

Important

Contact Center Enterprise ソリューションは、Unified CM のクラスタ間 Enhanced Location Call Admission Control（ELCAC）機能をサポートしません。

次の方法により、CVP の高可用性が向上します。

- CVP サーバ全体で自動コール バランスを提供するには、Unified CCE PG の制御下に冗長の CVP サーバを追加します。

- ゲートウェイが CVP サーバに接続できない条件を処理するには、存続可能性 TCL スクリプトをゲートウェイに追加します。たとえば、別の CVP が制御するゲートウェイ上の別の CVP サーバにコールをリダイレクトできます。

- 複数の CVP メディアサーバ間で音声ファイル要求と複数のサーバにわたる VXML URL アクセスを負荷分散するには、Cisco Content サーバを追加します。

この図は、フォールトトレラント Unified CVP システムのハイレベルなレイアウトを示しています。Unified CVP サイトの各コンポーネントは、冗長性を実現するために複製されています。これらのコンポーネントそれぞれの数は、特定の展開に対して予想される最繁時呼数（BHCA）に応じて異なります。

冗長性のある Unified CVP システム

図にある 2 つのスイッチは、Unified CVP サーバのネットワーク冗長性を提供します。一方のスイッチに障害が発生しても、アクセスできなくなるのは、コンポーネントの 1 つのサブセットだけです。残りのスイッチに接続されているコンポーネントは、引き続きコール処理でアクセスできます。

- バランスを取る高可用性の要因

- フェールオーバー中のコール存続可能性

- CVP を使用する SIP Proxy サーバ

- サーバグループと CVP 高可用性

バランスを取る高可用性の要因

CVP に次のコンポーネントとサブコンポーネントを追加することで、Contact Center Enterprise ソリューションの高可用性を実現できます。

- 複数ゲートウェイ、Unified CVP サーバ、Unified CVP VXML サーバ、および VRU PG — インバウンドとアウトバウンドコールの処理および VRU サービスが個々のコンポーネント障害時に継続できます。

- Unified CVP メディアサーバ — プライマリメディアサーバが到達不可の場合、VVoice ブラウザが、リクエストをバックアップメディアサーバに送信します。適切なフェールオーバーを発生させるため、すべてのメディアサーバで、ウィスパーアナウンスメントとエージェントグリーティング音声ファイルが重複しているかを確認します。

- 複数のコール処理ロケーション — コール処理ロケーションが暗くなっている場合に、コール処理を引き続きできるようにします。

- 冗長 WAN リンク — 各 WAN リンクに障害があった場合、Unified CVP コール処理をできるようにします。

フェールオーバー中のコール存続可能性

次の項では、コール存続可能性に対する Contact Center Enterprise コンポーネントと CVP サブコンポーネントの障害の影響度を説明します。

音声ブラウザ

音声ブラウザは、1 つまたは複数のソースから取得した VXML ドキュメントを解析してレンダリングします。VXML ゲートウェイで障害が発生すると、次の処理が行われます。

- 進行中のコール：イングレスゲートウェイの存続可能性機能は、デフォルトで進行中のコールを代替のロケーションにルートします。

- 着信コール：着信コールは、代替 VXML ゲートウェイを検索します。

Unified CVP IVR サービス — CVP IVR サービスは、Unified CVP Micro アプリケーションを実装する VXML ページを作成します。マイクロアプリケーションは、Unified CCE から受信した RunExternalScript 指示に基づいています。IVR サービスで障害が発生すると、次の処理が行われます。

- 進行中のコール — 発信ゲートウェイの存続可能性によって、進行中のコールはデフォルトで、代替ロケーションにルートされます。

- 着信コール — 着信コールは、アクティブな IVR サービスにダイレクトされます。

Unified CM

CVP コールサーバは、Unified CM の障害を認識すると、次を実行します。

- 進行中のコール — サーバは、アクティブコールを保持する必要があると想定し、発信ゲートウェイへのシグナリングチャネルを維持します。発信ゲートウェイは、Unified CM の障害を認識しません。アクティブコールでそれ以上のアクティビティ（保留、転送、会議など）を行うことはできません。終話後、電話機は別の Unified CM サーバにルーティングされます。

- 着信コール — 着信コールは、クラスタ内の代替 Unified CM サーバにダイレクトされます。

CVP コール サーバ

CVP コールサーバには、フェールオーバー中にコールの存続可能性を処理する次のサービスが含まれます。

- Unified CVP SIP サービス — CVP SIP サービスは、すべての着信および発信 SIP メッセージおよび SIP ルーティングを処理します。SIP サービスで障害が発生すると、次の処理が行われます。

- 進行中のコール — 発信者の転送後に、CVP SIP サービスに障害が発生すると（IP 電話または音声ブラウザへの転送を含む）、コールは引き続き通常通り動作します。ただし、CVP SIP サービスは、そのコールを再度転送できません。発信者が転送される前に障害が発生した場合、デフォルトの存続可能ルーティングは、コールを別の場所に転送します。

- 着信コール — Unified SIP Proxy は、着信コールを代替 Unified CVP コールサーバにダイレクトします。使用可能なコール サーバがない場合、コールは、存続可能性によって代替場所のデフォルトのルートにルーティングされます

CVP メディアサーバ

オーディオファイルは、VXML ゲートウェイにあるフラッシュメモリか、HTTP または TFTP File サーバにローカルで保存されます。ローカルに保存されたオーディオファイルは高可用性です。ただし、HTTP または TFTP File サーバには、音声ファイルの集中管理という利点があります。

メディアサーバに障害が発生すると、次の処理が行われます。

- 進行中のコール — 進行中のコールは自動的に復元します。高可用性構成手法により、発信者に対して障害が透過的になります。メディアリクエストに失敗した場合は、スクリプト手法を使いエラーを回避します。

- 着信コール — 着信コールは、バックアップのメディアサーバに透過的にダイレクトされ、サービスは影響されません。

Note

メディアサーバは、VXML ゲートウェイから WAN を介して見つけることができます。WAN 接続に障害が発生している場合、ゲートウェイは、リクエスト済みのプロンプトの期限が切れるまで、引き続きゲートウェイキャッシュからのプロンプトを使用します。その後、ゲートウェイは、メディアの再取得を試行し、存続可能が有効でない場合、コールは失敗します。存続可能性が有効になっている場合、コールはデフォルトのルートにルーティングされます。

CVP VXML サーバ

Unified CVP VXML サーバは、音声ブラウザと VXML ページを交換することにより、高度な VRU アプリケーションを実行します。CVP VXML サーバに障害が発生すると、次の処理が行われます。

- 進行中のコール — 進行中のコールは、スクリプト技術を使用して、Unified CCE が統合された展開で復元できます。たとえば、最初に Unified CVP VXML サーバ A に接続するようにスクリプトを構成します。Unified CVP VXML Server ICM スクリプトノードの X パスでアプリケーションに障害が発生した場合、Unified CVP VXML サーバ B が試されます。

- 着信コール — 着信コールは、透過的に代替 CVP VXML サーバにダイレクトされます。

CVP レポートサーバ

CVP コールサーバの障害は、コールの存続可能性に影響を与えません。

コールサーバは、バックアップおよび消去などのデータベースの管理アクティビティおよびメンテナンス アクティビティを実行しません。ただし、Unified CVP では、こうしたメンテナンスタスクに Operations Console を介してアクセスできます。単一の CVP コールサーバが、必ずしもシングルポイント障害であるわけではありません。データの安全とセキュリティは、データベース管理システムによって提供されます。ソースコンポーネント上の情報の永続的なバッファリングにより、一時的な停止が許容されます。

- より多くのコール存続可能性ポイント

より多くのコール存続可能性ポイント

ソリューションでコールの存続可能性を計画する場合は、次の点を検討してください。

- 障害時にコールリカバリができないシナリオがあります。

- 進行中のコールを含むプロセスが停止された場合。たとえば、システム管理者が、コールサーバをシャットダウンし忘れたとします。この場合、CVP サーバは、ライセンスをリリースするためにすべてのアクティブコールを終了します。

- コール サーバが推奨コール レートを超えた場合。コールサーバで許可されるコールの数には制限があります。ただし、通話料金に強制的な制限はありません。一般に、推奨される毎秒の通話（CPS）を長時間超える場合、一貫性がなく、予測不能な通話の動作が発生します。ソリューションのサイズを正しく設定し、各コール処理コンポーネント全体でコールの負荷を適切に分散します。

- http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.html の Configuration Guide for Cisco Unified Customer Voice Portal に説明のあるコール存続可能性の発信ゲートウェイを構成します。survivability.tcl スクリプトには指示と有用な情報も含まれています。

- Unified CVP の知識がなくてもクリアされた通話を検出できます。

- Unified CVP は、設定時間（デフォルトでは 120 分）を超える長さの着信コールを 2 分ごとにチェックします。

- これらのコールについて、Unified CVP は UPDATE メッセージを送信します。メッセージが拒否または送信不能を受信すると、コールがクリアされ、ライセンスがリリースされます。

- CVP SIP サービスが、コールにセッションの期限切れヘッダーを追加することで、エンドポイントは、独自にセッションを更新できます。RFC 4028（セッション ボーダー コントローラのセッションタイマー）には、SIP コールでのセッション切れの使用方法に関する詳細が含まれています。

- フェールオーバー中に、Unified CVP 制御下のコールは、イングレス音声ゲートウェイ存続可能性 TCL スクリプトから処理を行います。このような場合、Unified CCE セントラルコントローラのルーティング ダイアログが停止します。存続可能性スクリプトが通話を別のアクティブ Unified CCE コンポーネントにリダイレクトした場合、通話はレポートや追跡目的で、元の通話とは関係がない状態で、「新規通話」としてシステムに表示されます。

CVP を使用する SIP Proxy サーバ

SIP Proxy サーバは、SIP エンドポイントのダイヤルプラン解決を提供します。ダイヤルプラン情報は、各 SIP デバイスで静的に構成する代わりに、中央で設定できます。ソリューションに SIP Proxy サーバは不要です。中央集中型の構成とメンテナンスの利点を検討してください。複数の SIP Proxy サーバを展開することで、負荷分散、冗長性、地域の SIP コール ルーティング サービスを実現できます。ソリューションには、SIP コールルーティングに関して次の選択肢があります。

SIP Proxy サーバ

SIP Proxy サーバには、次の利点があります。

- 加重ロード バランシングおよび冗長性。

- 集中型ダイヤル プラン コンフィギュレーション。

- すでに SIP プロキシを使用している場合、または他のアプリケーションでダイヤルプランの解決やクラスタ間コールルーティングに使用されている場合は、既存の資産を活用できます。

ただし、SIP Proxy サーバには別のサーバが必要な場合があります。

DNS サーバ上でサーバグループ（DNS SRV レコード）を使用する静的ルート

この種の静的ルーティングにより、重み付けされた負荷分散と冗長性を実現できます。

ただし、この方法では次の欠点があります。

- 既存のサーバを使用する機能は、DNS サーバの場所によって異なります。

- 組織によっては、DNS サーバの管理権限を共有または代理する機能が制限されています。

- ダイヤルプランは、各デバイスで個別に構成する必要があります（Unified CM、Unified CVP、およびゲートウェイ）。

- Unified CVP は、すべてのコールに対して DNS SRV ルックアップを実行します。DNS サーバの応答が遅い、利用できない、または WAN をまたがった場合、パフォーマンスに問題が発生します。

ローカル DNS SRV レコードを使用した静的ルート

次の利点は、次のタイプの静的ルーティングで実現できます。

- 加重ロード バランシングおよび冗長性。

- 外部 DNS サーバに依存しない遅延、DNS サーバパフォーマンス、および障害のポイントに関する懸念を排除します。

しかし、ダイヤルプランは、各デバイスで個別に構成する必要があります（Unified CM、Unified CVP、およびゲートウェイ）。

Note

DNS サーバを使用する SRV を使用する静的ルート、またはサーバグループを使用すると、フェールオーバーと負荷分散中に予想外の遅延が長く発生する可能性があります。これは、プライマリ接続先がシャットダウンされている、またはネットワークがオフの場合に、Unified CVP コールサーバ上の TCP または UDP トランスポートで発生します。UDP では、ホスト名にサーバグループ（srv.xml）の優先順位の異なる要素がある場合、Unified CVP は要素ごとに 2 回試行し、遅延は 500 ミリ秒となります。遅延は、負荷分散に応じて、障害発生中に各コールに発生し、T1 タイマーに関する RFC 3261 の 17.1.1.1 項に準拠します。サーバ グループのハートビートがオンになっている場合、要素のステータスに応じて、遅延は 1 回だけ発生するか、まったく発生しない可能性があります。

- Cisco Unified SIP プロキシサポート

- CUSP 展開オプション

- 高可用性に向けた CUSP 設計

Cisco Unified SIP プロキシサポート

Cisco Unified SIP Proxy（CUSP）は SIP Proxy サーバの実装です。CUSP は、ゲートウェイまたは仮想マシン上で実行される専用の SIP Proxy サーバです。

CUSP 展開オプション

以下の項では、Contact Center Enterprise ソリューションで CUSP を展開するためのオプションについて説明します。

冗長 SIP Proxy サーバ

このオプションでは、2 つのゲートウェイを使用し、それぞれに 1 つのプロキシ VM を設定します。ゲートウェイは冗長性のため地理的に分離されています。プロキシの冗長性には SRV 優先順位が使用され、HSRP は使用しません。

このオプションを選択する場合は、次の点に注意してください。

- CUSP は、VXML または TDM ゲートウェイとコアサイドに接続できます。

- SRV またはダイヤルピア設定を使用して TDM ゲートウェイを構成すると、プライマリおよびセカンダリ CUSP プロキシが使用できます。

- CUSP はサーバグループと一緒に設定され、プライマリおよびバックアップの Unified CVP、Unified CM、および音声ブラウザを検索します。

- Unified CVP は、サーバグループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

- Unified CM は、複数の SIP トランクを持つルート グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

この例では、ISR1 が東海岸にあり、ISR2 が西海岸にあります。TDM ゲートウェイは、最も近い ISR を使用し、セカンダリ 優先順位ブレードに失敗した場合にのみ WAN を交差します。

SRV レコードは、次のようになります。

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)

二重キャパシティの冗長 SIP Proxy サーバ

このオプションでは、2 つのゲートウェイを使用し、それぞれに 2 つのプロキシ VM を用意します。4 つのプロキシサーバすべてがアクティブモードで、コールはプロキシサーバ間でバランスが保たれます。ゲートウェイは冗長性のため地理的に分離されています。これらは、SRV 優先順位を使用して、優先順位を持つプロキシ全体の負荷分散を行います。

このオプションを選択する場合は、次の点に注意してください。

- CUSP のプラットフォーム検証制限により、ISR はプロキシブレード機能専用です。ISR は、音声ブラウザとして、また TDM ゲートウェイとして併置されません。

- SRV またはダイヤルピア設定を使用して TDM ゲートウェイを構成すると、プライマリおよびセカンダリ CUSP プロキシが使用できます。

- CUSP はサーバグループと一緒に設定され、プライマリおよびバックアップの Unified CVP、Unified CM、および音声ブラウザを検索します。

- Unified CVP は、サーバグループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

- Unified CM は、複数の SIP トランクを持つルート グループを使用して設定され、プライマリ CUSP プロキシおよびセカンダリ CUSP プロキシを使用します。

この例では、ISR1 が東海岸にあり、ISR2 が西海岸にあります。TDM ゲートウェイは、最も近い ISR を使用し、セカンダリ 優先順位ブレードに失敗した場合にのみ WAN を交差します。

SRV レコードは、次のようになります。

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.30 priority 2 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.30 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR1 on east coast)

高可用性に向けた CUSP 設計

次の点は、CUSP の高可用性に影響します。

- プロキシ サーバ レコード ルートを使用しない— このオプションは、プロキシサーバのパフォーマンスに影響し、「シングルポイント障害」を発生させます。このオプションはオンにしないでください。

RecordRoute ヘッダーが入力されていない場合、着信コールが Unified CVP コールサーバに到達すると、シグナリングが CUSP をバイパスします。ルーティングのその時点から、シグナリングは発信元デバイスから CVP コールサーバに直接実行されます。

- SIP ハートビートがあるアップストリーム要素ルーティング — CUSPは、INVITE または OPTIONS への応答を良い応答として扱います。したがって、CUSP は、応答を受信したときに要素をダウンとしてマークしません。サーバグループのフェールオーバー応答コードリストで応答が構成されている場合、CUSP はグループ内の次の要素にフェールオーバーします。それ以外の場合、CUSP は、最終応答として応答をダウンストリームに送信します。

サーバグループと CVP 高可用性

サーバグループは、ダイナミックルーティング機能です。送信元のエンドポイントは、サーバグループを介して、SIP INVITE を送信する前に接続先アドレスのステータスを確認できます。ハートビートメソッドは、送信元 SIP ユーザに関する宛て先のステータスを伝えます。この機能を使用すると、障害のあるエンドポイントが原因の遅延をなくすことによって、呼制御のフェールオーバーを高速化できます。

サーバグループは、1 つ以上の接続先アドレス（エンドポイント）で構成されています。サーバグループには、SRV クラスタドメインとして知られるドメイン名または FQDN があります。サーバグループは、ローカル SRV 実装（srv.xml）のように機能しますが、サーバグループは、オプションとして SRV に追加のハートビートメソッドを追加します。この機能が対象としているのは、Unified CVP からの発信コールだけです。Unified CVP への着信コールを対象に含めるために、SIP Proxy サーバは、類似のハートビートを Unified CVP に送信できます。Unified CVP は、ステータス応答で応答できます。

Note

- Unified CVP および SIP Proxy サーバのサーバグループは、同じように機能します。

- サーバグループは、その中で定義されたエンドポイントに対して、ハートビートだけを送信します。

- 録音ルートが OFF に設定されている場合、mid-dialog SIP メッセージは、サーバグループで定義された要素をバイパスします。これらメッセージには、REFERs または REINVITES が含まれます。これらのメッセージは、ダイアログで他のエンドポイントに直接配信されます。

Unified CCE の高可用性に関する検討事項

Unified CCE のサブコンポーネントは、手動による操作を行わずにほとんどの障害シナリオから復旧できます。冗長アーキテクチャにより、ソリューションは単一のサブコンポーネント障害シナリオでのコールの処理を継続できます。複数のサブコンポーネントが同時に障害を起こすことはまれですが、ビジネス運用が中断されます。

- 冗長性とフォールトトレランス

- ルータの高可用性に関する考慮事項

- Logger の高可用性に関する考慮事項

- 周辺機器ゲートウェイ高可用性に関する検討事項

- Administration & Data サーバの高可用性に関する検討事項

- ライブデータの高可用性に関する検討事項

冗長性とフォールトトレランス

ペア化された冗長方法でルータと Logger を展開します。冗長化された導入の 2 つのサイドは、サイド A とサイド B と呼ばれます。たとえば、ルータ A とルータ Bが、2 つの異なる VM で実行しているルータの冗長インスタンスです。通常動作では、両サイドが実行されています。一方のサイドがダウンしている場合は、構成がスタンドアロンモードで実行されています。これらのモードは、デュプレックスモードおよびシンプレックスモードと呼ばれる場合があります。

Note

ルータと Logger のスタンドアロン（シンプレックス）展開は、実稼働環境ではサポートされていません。これらのコンポーネントは、冗長ペアで展開しなければなりません。

この 2 つのサイドは冗長性を備え、負荷分散用ではありません。いずれのサイドも、ソリューションの完全な負荷を実行できます。サイド A と B はどちらも同じメッセージ一式を実行し、同じ結果を生成します。論理的には、ルータは 1 つのみです。同期された実行とは、両サイドがすべてのコールを処理するという意味です。障害が発生すると、存続しているルータが通話の途中で引き継ぎ、ユーザの介入なしに続行します。

周辺機器ゲートウェイ（PG）コンポーネントは、ホットスタンバイモードで実行されます。1 つの PG だけがアクティブで、Unified CM または適切な周辺機器を制御します。アクティブな方で障害が発生すると、存続している方は、自動で引継ぎ処理を行います。障害中、存続している方は、冗長側が復元されるまでスタンドアロンモードで実行されます。その後、PG は自動的に冗長運用に戻ります。

Administration & Data サーバは、構成とリアルタイムデータを処理し、フォールトトレランスのためにペアで展開されます。拡張性の目的で複数のペアを展開できます。履歴データ向けの Administration & Data サーバは、冗長性および拡張性向けの N+1 アーキテクチャに従います。各 Administration & Data サーバには、推奨およびプライマリデータソースとして、Logger（サイド A または B）があります。

ルータの高可用性に関する考慮事項

- 多数のデバイスとフェールオーバー

- ルータフェールオーバーのシナリオ

多数のデバイスとフェールオーバー

デバイスの大半は、ルータが無効な状態にするかどうかを決定します。ルータは、冗長ルータとの接続を失ったデバイスの大半を確認します。各ルータは、ルータ自体のデバイスの過半数を決定します。なし、1 つ、または両方のルータが同時にデバイスの過半数を持つことができます。

デバイスの過半数を持つには、ルータが次のいずれかの条件を満たす必要があります。

- ルータはサイド A ルータであり、有効な PG 全体の少なくとも半分と通信できる。

- ルータはサイド B ルータであり、有効な PG 全体の半分以上と通信できる。

ルータフェールオーバーのシナリオ

- エージェント PG リンクに障害が発生した CTI Manager

- CTI Manager からエージェント PG へのリンクが正常なサブスクライバ

- 何度か失敗したシナリオ

エージェント PG リンクに障害が発生した CTI Manager

各 エージェント PG は1つの CTI Manager 接続のみをサポートします。各サブスクライバには CTI Manager がありますが、通常は 2 つのサブスクライバのみが エージェント PG に接続します。4 サブスクライバ クラスタ 内のすべてのサブスクライバがエージェント PG に直接接続できるようにするには、エージェント PG の別のペアを追加する必要があります。

以下の図は、エージェント PGへの接続がある CTI Manager の障害を示しています。サブスクライバ C および D のみが、エージェント PG に接続するように構成されています。

以下の条件がシナリオに適用されます。

- 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

- サブスクライバ C および D の CTI Manager は、エージェント PGに JTAPI サービスを提供します。

エージェント PG 接続を使用する CTI Manager に障害が発生します

障害復旧は次のように発生します。

1. サブスクライバ C の CTI Manager に障害が発生すると、エージェント PG サイド A は障害を検出し、PG サイド B にフェールオーバーします。

2. エージェント PG サイド B は、サブスクライバ D の CTI Manager を使用してすべてのダイヤル番号と電話機を登録し、コール処理を続行します。

3. 進行中のコールはアクティブな状態が続きますが、エージェントがサインインするまで、エージェントは転送などの電話サービスを使用できません。

4. サブスクライバ C の CTI Manager が復旧すると、エージェント PG サイド B はアクティブであり続け、サブスクライバ D の CTI Manager を使用します。このモデルではエージェント PG は、フェールバックしません。

CTI Manager からエージェント PG へのリンクが正常なサブスクライバ

各 エージェント PG は1つの CTI Manager 接続のみをサポートします。各サブスクライバには CTI Manager がありますが、通常は 2 つのサブスクライバのみが エージェント PG に接続します。4 サブスクライバ クラスタ 内のすべてのサブスクライバがエージェント PG に直接接続できるようにするには、エージェント PG の別のペアを追加する必要があります。

次の図は、エージェント PG に直接接続できないサブスクライバ A の障害を示しています。

以下の条件がシナリオに適用されます。

- 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

- サブスクライバ C と D はエージェント PG に接続し、CTI Manager のローカルインスタンスは、PG に JTAPI サービスを提供します。

エージェント PG へのリンクのない Unified Communications Manager の障害

障害復旧は次のように発生します。

1. サブスクライバ A に障害が発生した場合、登録された電話機とゲートウェイがバックアップサブスクライバ B に対して再設定されます。

2. エージェント PG サイド A はアクティブな状態が維持され、サブスクライバ C の CTI Manager に接続されます。JTAPI と CTI Manager 間の接続に障害が発生していないため、PG はフェールオーバーしません。ただし、PG は電話機とデバイスの登録が自動的にサブスクライバ A からサブスクライバ B に切り替わるのを検出します。

3. コール処理は、サブスクライバ A に登録されていないデバイスで続行されます。

4. エージェントの電話機が登録されていない場合、エージェント PG はエージェントデスクトップを無効にします。この応答は、エージェントがサブスクライバ接続なしでシステムを使用するのを防ぎます。エージェント PG は、コールをエージェントにルートしないように、この移行中にエージェントをサインアウトします。

5. 電話機がバックアップサブスクライバを再登録した後、コール処理が再開されます。

6. 進行中のコールは、サブスクライバ A に登録された電話機で継続されますが、エージェントが再度サインインするまで、転送のような電話サービスを使用することはできません。

7. 進行中のコールが終了すると、その電話機はバックアップサブスクライバに再登録されます。エージェント PG は、コールをエージェントにルートしないように、この移行中にエージェントをサインアウトします。

8. サブスクライバ A が復元すると、電話機とゲートウェイは、復元したサブスクライバ A にリホームされます。サブスクライバにリホームを設定すると、電話とデバイスグループを時間の経過とともに正常に戻すことができます。そうでない場合は、電話機を再配布してコールセンターへの影響を最小限に抑えるために、メンテナンス期間中に手動による介入を要求できます。このリホームプロセス中、CTI Manager は、サブスクライバ B から元のサブスクライバ A に切り替える登録のエージェント PG を通知します。

9. コール処理は、電話機とデバイスが元のサブスクライバに戻った後も通常通り継続されます。

何度か失敗したシナリオ

複数のコンポーネントに障害が発生した場合、Unified CCE は、単一コンポーネントの障害時ほどシームレスに失敗しません。次の項では、Unified CCE がマルチコンポーネント障害に対してどのように応答するのかについて説明します。

- CTI Manager とエージェント PGの障害

- Unified CM サブスクライバと CTI Managerの両方の障害

CTI Manager とエージェント PGの障害

CTI Manager は、ローカルサブスクライバと 1 つのエージェント PG にのみ接続します。クラスタ内の他の CTI Manager と直接通信することはできません。CTI Manager は、他のコンポーネントのデータによって同期されます。

各サイドのエージェント PG ともう一方の側の CTI Manager が両方に障害が発生した場合、Unified CCE はクラスタと通信できません。このシナリオでは、システムがこのクラスタ上のエージェントに接続できなくなります。エージェント PG またはバックアップ CTI Manager がオンラインに戻るまで、クラスタは切断された状態のままです。

エージェント PG がバックアップの CTI Manager に接続できない

Unified CM サブスクライバと CTI Managerの両方の障害

シナリオは、Unified CM サブスクライバ A サーバの完全な障害からのリカバリを示しています。

以下の条件がシナリオに適用されます。

- サブスクライバ A にはプライマリ CTI Manager があります。

- 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

Unified Communications Manager と CTI Manager の障害

障害復旧は次のように発生します。

1. サブスクライバ A に障害が発生すると、すべての非アクティブな登録済み電話機およびゲートウェイがサブスクライバ B に再登録されます。

2. 進行中のコールはアクティブなままですが、エージェントは転送などの電話サービスを使用できません。

3. エージェント PG サイド A が障害を検出し、エージェント PG サイド B へのフェールオーバーを引き起こします。

4. エージェント PG サイド B がアクティブになり、すべてのダイヤル番号と電話機を登録します。コール処理が続行されます。

5. 進行中のコールが終了すると、そのエージェントの電話機とデスクトップがバックアップサブスクライバに再登録されます。エージェントデスクトップの正確な状態は、構成とデスクトップによって異なります。

6. サブスクライバ A が復元すると、すべてのアイドル状態の電話機とゲートウェイが再登録されます。アクティブデバイスは、プライマリサブスクライバに再登録する前にアイドルになるまで待機します。

7. エージェント PG サイド B は、サブスクライバ B の CTI Manager を使用してアクティブな状態のままです。

8. 障害からの復旧語、エージェント PG は、冗長ペアのサイド A にフェールバックしません。すべての CTI メッセージングは、サブスクライバ A と通信するサブスクライバ B の CTI Manager を使用して電話機の状態とコール情報を取得するために処理されます。

Logger の高可用性に関する考慮事項

- Logger の障害

- レポーティングの考慮事項

Logger の障害

Unified CCE Logger および Database サーバは、構成（エージェント ID、スキルグループ、通話の種類）およびスクリプト（コールフロースクリプト）のためにシステムデータベースを維持します。サーバは、通話処理から最近の履歴データも保持します。Logger はローカルルータからデータを受信します。ルータは同期されているので、Logger データも同期されています。

Logger の障害により、コール処理にすぐ影響を与えることはありません。冗長 Logger は、ローカルのルータからの一連の通話データを受信します。システムが Logger の障害を復元した場合は、Logger は自動で、バックアップ Logger からいつオフラインになったのかのすべてのトランザクションを要求します。Logger は、データベースで記録されたエントリの順番をトラックするリカバリキーを維持します。冗長 Logger は、これらキーを使用して欠落しているデータを特定します。

Logger が、Config_Message_Log テーブルの 14 日の保持期間を超えてオフラインになったままの場合、システムは、自動で Logger 構成データベースを再同期しません。システム管理者は、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-maintenance-guides-list.html の『アドミニストレーション ガイド』に説明されている Unified ICMDBA アプリケーションを使用して Logger を手動で再同期できます。手動のプロセスにより、構成データをプライベートネットワーク全体に転送する便利な時間を選択できます。

Logger の複製プロセスは、そのデータを Logger データベースからから Administration および Data サーバ の HDS データベースに送信します。また、複製プロセスでは、Logger が同期された後、Logger データベースが記録する新しい行が自動的に複製されます。

単一のキャンペーン マネージャを使用した Cisco アウトバウンドオプションを使用する展開では、キャンペーン マネージャは、プライマリ Logger だけにロードされます。そのプラットフォームが停止され、Logger がダウンしている場合、任意の発信通話が停止します。

レポーティングの考慮事項

Unified CCE レポート機能は、リアルタイム、5 分間、およびレポート間隔（15 分または 30 分間）のデータを使用して、レポートデータベースを構築します。各 5 分間のレポート間隔の最後に、各 PG はローカルデータを収集し、ルータに送信します。ルータはデータを処理し、データを履歴データストレージ用のローカル Logger に送信します。この Logger は、履歴データを HDS/DDS データベースに複製します。

PG は、5 分間のデータおよびレポート間隔データのバッファリング（メモリおよびディスク上）を提供します。PG は、このバッファされたデータを使用して、ネットワーク応答の低下と、ネットワークサービス復元後のデータの自動再送信を処理します。冗長ペアの両方の PG に障害が発生した場合は、セントラルコントローラに送信されない 5 分間のデータとレポート間隔のデータを失う可能性があります。

エージェントがサインアウトすると、すべてのレポート統計が停止します。エージェントが次にサインインすると、エージェントのリアルタイム統計は 0 から開始します。エージェントデスクトップと、障害が発生した時にエージェントが行っている処理に応じて、一部のフェールオーバーは、エージェントがコンタクトセンターからサインアウトされる原因となります。詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-user-guide-list.html の「 Cisco Unified ICM/Contact Center Enterprise レポートの概念」を参照してください。

周辺機器ゲートウェイ高可用性に関する検討事項

- PG ウェイト

- フェールオーバー中の記録管理

- エージェント PG 障害

- CTI サーバ障害

- VRU PG 障害

PG ウェイト

プライベートリンクに障害が発生した場合のフェールオーバー中に、重み付け値によって、有効な PG になる PG が決定します。各側のアクティブコンポーネントの数とタイプによって、PG の加重値が決定されます。各コンポーネントに割り当てられた重み付けは、そのコンポーネントの復元時間と、コンポーネントがダウンした場合のコンタクトセンターの中断を反映します。エージェント PIM は、VRU PIM および CTI サーバよりも重みがあります。コンポーネントの重み付けは構成できません。

フェールオーバー中の記録管理

フェールオーバー中に記録されるコールデータは、どのコンポーネントに障害が発生するかによって異なります。障害の状況に応じて、同じコールデータが失われます。ルータは、障害が原因で、アクティブコールへのアクセスを失う場合があります。アクティブコールは依然としてアクティブ状態ですが、ルータは、コールがドロップしたかのように応答します。通常、エージェント PG は、終話コール詳細（TCD）レコードを Unified CCE データベースに作成します。

エージェントにすでに接続されているコールは、フェールオーバー中に続行できます。エージェント PG は、これらのコールが終了すると、そのコールに対して別の TCD レコードを作成します。

エージェント PG 障害

このシナリオは、PG サイド A の障害の復元を示しています。

以下の条件がシナリオに適用されます。

- Unified CM サブスクライバ A にはプライマリ CTI Manager があります。

- 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

次の図は、PG サイド A での障害と PG サイド B へのフェールオーバーを示しています。すべての CTI Manager サービスと Unified Communications Manager サービスは、引き続き通常通り実行されます。

エージェント PG のサイド A の障害

障害復旧は次のように発生します。

1. PG サイド B が PG サイド A の障害を検出します。

2. PG サイド B は、すべてのダイヤル番号と電話機を登録します。コール処理は PG サイド B を通じて続行されます。

3. 電話機とゲートウェイは登録され、サブスクライバ A で運用可能な状態が続き、フェールオーバーしません。

4. 進行中のコールはエージェントの電話機でアクティブな状態のままですが、エージェントがサインインし直すまで、エージェントは転送のような電話サービスを使用できません。

5. PG サイド B へのフェールオーバー中は、構成に応じて占有されていないエージェントの状態とデスクトップが変化する場合があります。3 者通話のオプションが影響を受ける可能性があります。場合によっては、エージェントはフェールオーバーの完了後にサインインまたは手動で状態を変更する必要があります。

6. 障害からの復旧後、PG サイド B は、アクティブ状態のまま、サブスクライバ B の CTI Manager を使用します。PG がサイド A にフェイルバックしない場合、コールは、PG サイド B で引き続き処理されます。

CTI サーバ障害

CTI サーバは、特定の CTI メッセージ（通話の呼び出し中やオフフックイベントなど）について、エージェント PG トラフィックをモニタします。CTI サーバは、これらのメッセージを Cisco Finesse サーバなどの CTI クライアントで利用できるようにします。CTI サーバは、CTI クライアントからのサードパーティ呼制御メッセージ（コールの送信や応答コールなど）も処理します。CTI サーバは、処理のためにエージェント PG を介して Unified CM にこれらのメッセージを送信します。

冗長ペアで CTI OS サーバを展開します。冗長ペアの各半分は、冗長エージェント PG ペアの半分を持つ VM の同身です。アクティブな CTI サーバの障害発生時には、冗長 CTI サーバがアクティブになり、コールイベントの処理を開始します。

CTI サーバ障害

Finesse サーバは、CTI サーバのクライアントです。Desktop サーバは、CTI サーバではなく、フェールオーバー中にエージェントの状態を維持します。CTI サーバに障害が発生すると、Finesse はエージェントデスクトップを一部無効にします。場合によっては、フェールオーバーが完了した後にエージェントは再サインインする必要があります。

Note

アクティブな CTI サーバにクライアントが接続されていない場合、事前設定された期間後、メカニズムが強制的にフェールオーバーを実行します。このフェールオーバーは、CTI クライアントがアクティブな CTI サーバに接続するのを妨げる偽の誤った理由を分離します。

VRU PG 障害

音声応答装置（VRU）PG に障害が発生した場合、進行中のコールや Unified CVP にキューに入ったコールはドロップされません。音声ゲートウェイの存続可能性 TCL スクリプトは、使用可能な場合、コールをセカンダリ Unified CVP または SIP ダイヤルプラン内の番号にリダイレクトします。

フェールオーバー後、冗長 VRU PG は、Unified CVP に接続され、新しい通話の処理を開始します。障害が発生した VRU PG サイドが復旧すると、現在実行中の VRU PG がアクティブ VRU PG として稼働し続けます。冗長 VRU PG を使用すると、Unified CVP がアクティブキューポイントとして機能したり、コール処理を提供したりできます。

VRU PG 障害

Administration & Data サーバの高可用性に関する検討事項

- Administration and Data サーバ障害

Administration and Data サーバ障害

Administration および Data サーバは、構成およびスクリプト変更を行うシステムにユーザインターフェイスを提供します。サーバは、Web ベースのレポートツールとインターネット スクリプト エディタをホストすることもできます。他の Unified CCE コンポーネントとは異なり、Administration および Data サーバは冗長ペアで動作しません。このサーバの機能に冗長性を提供する場合は、設計にさらに Administration および Data サーバを含めます。ただし、自動フェールオーバーの動作はありません。

Administration および Data サーバは、リアルタイム ディストリビュータを介したルータからの Unified CCE 全体からリアルタイムでデータのフィードを受けます。同じサイトに Administration および Data サーバがいくつかある場合、1 つの管理者サイトにリアルタイム ディストリビュータを構成できます。管理者サイトには、プライマリ ディストリビュータと 1 つ以上のセカンダリ ディストリビュータがあります。プライマリ ディストリビュータはルータに登録し、ルータからのネットワーク全体でリアルタイムにフィードを受信します。セカンダリ ディストリビュータは、リアルタイム フィードのソースとしてプライマリ ディストリビュータを使用します。この調整により、ルータがサポートするリアルタムフィードの数を軽減し、帯域幅をご存します。

プライマリ リアルタイム デスクトップに障害が発生した場合、次の図で示すとおり、セカンダリ リアルタイム ディストリビュータは、リアルタイムフィードのルータに登録します。プライマリまたはセカンダリ Administration および Data サーバに登録できない管理クライアントは、ディストリビュータがリストアされるまで、タスクを実行できません。

プライマリ リアルタイム ディストリビュータの障害

電解によっては、Administration および Data サーバは、 Unified CCMP のインターフェイスもホストします。このような展開では、Administration および Data サーバがダウンした場合、どちらのツールを使用して行われた構成編網もインターフェイスに渡されません。

ライブデータの高可用性に関する検討事項

ライブデータは、1 つが サイド Aに、もう 1 つがサイド B に導入された 2 つのライブデータシステムとして導入された高可用性システムです。設計上、ライブデータの導入は、シングルポイント障害に耐えることができます。フェールオーバーには次の 3 つの層があります。

- サーバ

- ヒント

- Socket.IO ストリーム

Note

Live Data サーバのフェールオーバーは、Live Data クラスタフェールオーバーとも呼ばれます。このドキュメントでは、Live Data サーバ フェールオーバーという用語を使用します。

ライブデータレポートトポロジ

- Live Data サーバのフェールオーバー

Live Data サーバのフェールオーバー

Live Data サーバは、コールドアクティブまたはスタンバイ モードで動作します。いつでもアクティブにできるのは、1 つの Live Data サーバのみです。もう 1 つの Live Data サーバはスタンバイ状態です。スタンバイの Live Data サーバは、アクティブなサーバのステータスを絶えずモニタしています。アクティブなサーバに障害が発生すると、スタンバイのサーバが引き継ぎ、アクティブになります。障害のあるサーバは、サービスを提供する準備ができたらスタンバイサーバになります。

重み付けアルゴリズムにより、次の 2 つのシナリオでアクティブな Live Data サーバを決定します。

シナリオ 1：両方の Live Data サーバが同時に起動すると、サーバは、ルータと同じデバイスの過半数の計算を使用します。

シナリオ 2：アクティブな Live Data サーバは、一部の PG に対する接続を失う場合があります。スタンバイサーバはその切断を検出します。2 分間アクティブサーバよりも 130% PG多い場合、アクティブステータスを想定するように要求します。スタンバイサーバがアクティブサーバになり、以前アクティブだったサーバがスタンバイサーバになります。

- TIP フェールオーバー

- Socket.IO フェールオーバー

TIP フェールオーバー

Live Data は、TIP トランスポートプロトコルを使用してルータおよび PG サーバと通信します。アクティブな Live Data サーバは、ルータと PG の両サイドに TIP 接続を確立します。スタンバイの Live Data サーバは、TIP 接続を確立しません。サイド A かサイド B のどちらか一方でのみ TIP 接続がアクティブになります。アクティブな TIP 接続に障害が発生した場合、アクティブな Live Data サーバがアイドル状態の TIP 接続を復元します。

Socket.IO フェールオーバー

Socket.IO クライアントは、Live Data サーバのどちらかのサイドに接続して、ライブデータレポートイベントストリーム（Socket.IO ストリーム）を受信します。Unified Intelligence Center クライアントは、Socket.IO クライアントの例です。スタンバイ中の Live Data サーバも、アクティブサーバのプロキシごとの Socket.IO ストリームを生成します。Socket.IO クライアントハートビートの損失は、Socket.IO の切断の原因となります。その後、Socket.IO クライアントは、別の Live Data サーバにフェールオーバーします。

仮想化音声ブラウザの高可用性に関する検討事項

シスコ仮想化音声ブラウザ（VVB）は、アクティブの冗長性に対する組み込み式高可用性のない単一ノードです。可用性のレベルを向上し、シングルポイント障害を排除するために、追加の VVB を導入します。CVP SIP サーバグループに追加の VV を含めると、パッシブ冗長性を構築できます。さらに VVB を展開することで、1 つの VVB のスケジュールされていないダウンタイムとスケジュールいるダウンタイムを管理できます。

VVB に障害が発生した場合、障害が発生した VVB 切断時のすべてのアクティブコールとすべてのコールデータが失われます。CVP が SIP サーバグループ内の VVB の障害を検出すると、CVP は残りのアクティブ VVB に着信コールをルートします。CVP ハートビートメカニズムによって、障害が発生した VVB のリカバリをが検出されると、CVP はリカバリ済みの VVB にコールバックをルートします。

Unified CM の高可用性に関する検討事項

データネットワークを設計した後、Cisco Unified Communications インフラストラクチャを設計します。ダイヤルしたり、通話を受信するためには、任意のテレフォニー アプリケーションを展開する前に Unified CM クラスタおよび CTI Manager を設置する必要があります。

各 Unified CM サーバ上でソリューションを実行するためのいくつかの重要なサービス

- Unified CM

- CTI Manager

- CallManager サービス

- TFTP

これらすべてのサービスのアーキテクチャの詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html の 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

クラスタの高可用性の設計では、Unified CM、CTI Manager、CallManager サービスがどのように相互対話をするか理解する必要があります。Unified CM は、CTI Manager サービスを使用して CTI リソースを処理します。CTI Manager は、特定の Unified CM サーバへのアプリケーションの物理的なバインドを制限するアプリケーションブローカーとして機能します。CallManager サービスは、すべての Cisco Unified Communications デバイスを登録および監視します。

CTI Manager は、CTI アプリケーションであるエージェント PG からメッセージを受け入れ、クラスタ内の適切なリソースに送信します。CTI Manager は、Cisco JTAPI を使用する JTAPI メッセージルータのように動作し、エージェント PG に通信します。Unified CM の JTAPI クライアントライブラリは、CallManager サービスに直接接続する代わりに CTI Manager に接続します。

CallManager サービスは、システム内のすべての Cisco Unified Communications リソースとデバイスのスイッチとして機能します。各 Unified CM サーバ上の CallManager は、パブリックネットワークを介して単一ディストリビューション レイヤ（SDL）とリンクしています。このリンクにより、クラスタの同期が維持されます。各 CTI Manager は、サーバ上の Unified CM および CallManager サービスに接続します。CTI Manager は、クラスタ内の他の CTI Manager に直接接続できません。

エージェント PG は、通常、「JTAPI ユーザ」または「PG ユーザ」と呼ばれる、Unified CM で CTI 対応のユーザアカウントを使用します。エージェント PG は CTI Manager にサインインして、そのユーザのデバイスに接続します。適切なデバイスがローカルの CallManager にある場合、CTI Manager は、そのデバイスの要求を処理します。デバイスがローカルのサブスクライバにない場合、CallManager サービスは、他の CallManager サービスへのプライベートリンクを通じて、リクエストを適切なサブスクライバに転送します。

次の図は、クラスタ内の接続を示します。

Unified Communications Manager クラスタ内の接続

高可用性の場合は、クラスタ内のすべてのサブスクライバにデバイス登録を分散します。登録を単一のサブスクライバに集中させると、トラフィックは、そのサブスクライバに大きな負荷を与えます。エージェント PG が登録済みデバイスの監視に使用するメモリオブジェクトは、サブスクライバのデバイスの重み付けにも追加されます。

サブスクライバに接続されている PG に障害が発生した場合、冗長 PG は、すべての要求を引き継いで、別のサブスクライバに送信します。次に、ローカルの CallManager サービスは、クラスタ全体でこれらのリクエストに対する CTI Manager メッセージングを元のサブスクライバにルートする必要があります。このフェールオーバー条件化でメッセージを追加すると、クラスタに大きな負荷がかかります。

- Unified CM の冗長性

- Unified CM 負荷分散

Unified CM の冗長性

Unified CM の展開環境の中には、2:1 の冗長性スキームを使用する場合があります。プライマリサブスクライバの各ペアは、1 つのバックアップサブスクライバを共有します。しかし、コンタクトセンターでのより高い電話機の使用率、そしてアップグレード処理の簡易化により、Contact Center Enterprise ソリューションは、サブスクライバに対して 1:1 冗長性スキームを使用します。各プライマリサブスクライバには、それぞれ独自のバックアップサブスクライバが必要です。

次の図は、異なるサイズのクラスタを示しています。Unified CVP を使用する Contact Center Enterprise ソリューションの場合、N は、この図の 2000/ペアのサブスクライバと同じになります。

冗長構成のオプション

Unified CM 負荷分散

Unified CM サブスクライバ用の 1:1 冗長性スキームでは、プライマリサブスクライバとバックアップサブスクライバのペアでデバイスのバランスを調整できます。通常、プライマリサブスクライバが利用できない限り、バックアップサブスクライバにはデバイスが登録されません。

Unified CM の冗長性グループとデバイスプールの設定により、負荷分散を有効にできます。プライマリサブスクライバからセカンダリサブスクライバにデバイスの負荷の半分まで移動できます。この方法により、サーバが使用できなくなることによる影響を半分に減らすことができます。停止の影響を最小限に抑えるために、すべてのデバイスと通話ボリュームをアクティブなサブスクライバ全体に均等に分散します。

Cisco Finesse 高可用性の考慮事項

Cisco Finesse サーバは、Contact Center Enterprise ソリューションの冗長ペアで展開します。両方の Cisco Finesse サーバが常にアクティブになります。Cisco Finesse サーバが動作しない場合、そのサーバ上のエージェントは [準備中（NOT READY）] または [準備の保留（pending NOT READY）] のステータスになります。別のサーバのサインインページにリダイレクトされます。このような状況は、次の状況が発生した場合に発生します。

- Cisco Finesse Tomcat サービスの停止。

- シスコ通知サービスの停止。

- Cisco Finesse から両方の CTI サーバへの接続が切断された。

クライアントが切断されると、2 つの内の利用可能な Cisco Finesse サーバの 1 つに再接続を試行します。再接続に 2 分以上かかる場合、Cisco Finesse はエージェントをサインアウトします。クライアントが再接続されると、エージェントはサインインする必要があります。

1 つのエージェント PG は、2 台のサーバ、発行元、サブスクライバで構成される Cisco Finesse クラスタの 1 つのインスタンスをサポートします。複数の Finesse クラスタは、同じエージェント PG/CTI サーバには通信できません。各 Cisco Finesse サーバは、CTI サーバがサポートする最大 2,000 ユーザをサポートできます。このキャパシティにより、他のサーバに障害が発生した場合、一方の Cisco Finesse サーバが全負荷を処理できます。2 台の Cisco Finesse サーバ間のユーザの総数は 2,000 名を超えることはできません。次の図に示すように、各 Cisco Finesse サーバには 1 つの CTI 接続が必要です。

複数の Cisco Finesse サーバ

Cisco Finesse を展開する場合は、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.html の「シスコ コラボレーション仮想化」で説明されている併置ポリシーに従います。

- Cisco Finesse IP Phone エージェントの障害時動作

- Cisco Finesse サーバ障害

Cisco Finesse IP Phone エージェントの障害時動作

デスクトップとは異なり、Cisco Finesse IP Phone Agent（Cisco Finesse IPPA）は、代替の Cisco Finesse サーバに自動的にフェールオーバーしません。適切なフェールオーバー動作が発生する場合は、Unified CM で最低 2 つの Cisco Finesse IP Phone サービスを構成します。各サービスは、異なる Cisco Finesse サーバを使用する必要があります。

Cisco Finesse サーバに障害が発生すると、Cisco Finesse IPPA は 5 秒ごとに再接続を試行します。3 回試行が失敗すると、Cisco Finesse IPPA はエージェントに対してサーバが使用できない旨のメッセージを表示します。サービス停止までの合計時間は約 15 秒です。

障害のシナリオでは、エージェントはサインアウトしてから、代替の Cisco Finesse サーバにサインインする必要があります。すると、エージェントは通常動作を再開できます。

Cisco Finesse サーバ障害

専用の仮想マシンでは、Cisco Finesse サーバを冗長ペアで展開します。Cisco Finesse サーバはどちらも、アクティブモードで実行されます。

Cisco Finesse サーバ障害

Cisco Finesse サーバに障害が発生すると、次のように障害回復が発生します。

1. サーバにサインインしているエージェントデスクトップは、切断を検出し、冗長サーバにフェールオーバーします。

2. エージェントは、フェールオーバー後、新しいサーバに自動的にログインします。

Note

Cisco Finesse サーバに障害が発生した場合、デスクトップ チャット ステータスは、保持され、すべてのアクティブセッションが失われます。

3. Cisco Finesse REST API を使用するサードパーティ製アプリケーションは、アプリケーション ロジック内でフェールオーバーを実行して、冗長サーバに移動する必要があります。

4. Cisco Finesse サーバは自動的に再起動しません。障害が発生したサーバを再起動すると、新しいエージェント デスクトップ セッションがそのサーバにサインインできます。冗長サーバにサインインしているエージェントデスクトップは、そのサーバに残ります。

Note

別のサイドの Cisco Finesse Tomcat に障害が発生した場合は、Cisco Finesse サーバがフェールオーバーします。

- 他のコンポーネントに障害が発生した場合の Cisco Finesse の動作

他のコンポーネントに障害が発生した場合の Cisco Finesse の動作

次の項では、他の Unified CCE コンポーネントに障害が発生した場合の Cisco Finesse の動作について説明します。

エージェント PG または CTI サーバの障害

Cisco Finesse サーバは、CTI サーバが併置され、接続されているアクティブエージェント PG に接続します。アクティブなエージェント PG または、CTI サーバに障害が発生した場合、Cisco Finesse は冗長の CTI サーバへの接続を試行します。冗長サーバが利用できない場合、Finesseは、接続するまでどちらかのサーバへの接続を試行します。その後、Finesse は、すべてのエージェント、スキルグループ、およびコールデータをクリアします。Cisco Finesse は、エージェントとコールの状態を含む冗長 CTI サーバから現在のすべての構成を受信するまでは使用できません。切断された場合、エージェントはデスクトップに赤いバナーを表示し、再接続されたら緑のバナーを表示します。

ベンチマークパラメータ

Cisco Finesse、Release 12.5 (1) CTI フェールオーバーとデスクトップ フェールオーバーのパフォーマンスを最適化します。

- CTI フェールオーバー — エージェント PG 12.5(1) を展開する際の CTI サーバまたはエージェント PG フェールオーバーの最長時間は、35 秒から 75 秒です。

- デスクトップ フェールオーバー — エージェント PG 12.5(1) を展開する際におけるデフォルト デスクトップ レイアウトのデスクトップ フェールオーバーの最長時間は、50 秒から 110 秒です。

フェールオーバーの時間は、WAN 帯域幅、サインインしているユーザの数、遅延、CPU の数および Finesse デスクトップに設定されているガジェットの数によって異なります。

最適なフェールオーバー パフォーマンスを確保するための展開方法とガイドラインの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html にある『Cisco Finesse アドミニストレーション ガイド』の「デスクトップ フェールオーバー最適化のガイドライン」および「フェールオーバー計画」の項を参照してください。

カスタムガジェットによるフェールオーバー パフォーマンスの改善方法の詳細については、https://developer.cisco.com/docs/finesse/#!rest-api-dev-guide にある『Cisco Finesse Web サービスデベロッパーガイド』の「ガジェット開発のベストプラクティス」の項を参照してください。

帯域幅の計測の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html にある『Unified Contact Center Enterprise Finesse 帯域幅計算ツール』を参照してください。

Administration & Data サーバの障害

Cisco Finesse は、Administration & Data サーバを使用してエージェントを認証します。Cisco Finesse 管理者は、Cisco Finesse 管理ユーザインターフェイスで、Administration & Data サーバの設定（また必要に応じて、Administration & Data サーバのバックアップ）を構成します。プライマリ Administration & Data サーバの障害とバックアップの Administration & Data サーバが設定されていない場合、Cisco Finesse エージェントはデスクトップにサインインできません。フェールオーバーが発生するとログインしているエージェントは、デスクトップ上で操作を実行できなくなります。

バックアップの Administration & Data サーバが構成された場合、Cisco Finesse は、バックアップサーバへの接続を試行します。Cisco Finesse をバックアップの Administration & Data サーバに接続後、エージェントはサインインでき、デスクトップで操作を実行できます。

Cisco IM&P サーバの障害

Cisco Finesse は、デスクトップチャット機能用のインスタントメッセージングおよびプレゼンス（IM&P）サーバを使用します。IM&P は、チャット機能が有効になっているユーザそして、Unified CM（LDAP 統合が有効である場合は、LDAP から）からユーザリストをプルします。

フェールオーバーは、デスクトップチャットをサポートしており、IM&P ノード障害は、構成されたユーザとしてノードペアピアへ自動的に接続します。

Note

Cisco Finesse サーバに障害が発生した場合、デスクトップ チャット ステータスは、保持され、すべてのアクティブセッションが失われます。

Unified Intelligence Center の高可用性に関する検討事項

Cisco Unified Intelligence Center は、高可用性のために、発行元と最大 7 のサブスクライバを含むクラスタモデルを使用します。構成がクラスタ内で複製されます。プロセスは自動で、失敗したノードをバイパスしてアクティブノード間で広がります。

Unified CM ベースのサイレントモニタリングの高可用性に関する検討事項

既存のコールでは、高可用性はありません。着信コールの場合、コール処理とサイレントモニタリングがバックアップの Unified CM サブスクライバに移動します。

Customer Collaboration Platformハイ アベイラビリティの考慮事項

Cisco Customer Collaboration Platform は、高可用性をサポートしていません。冗長の Customer Collaboration Platform サーバを展開しないでください。 Customer Collaboration Platform は Contact Center Enterprise ソリューションの別のコンポーネントと直接統合はしません。

Customer Collaboration Platform は、小規模または大規模な単一サーバ、オールインワン展開を使用します。負荷分散、分割サイトの展開は使用できません。

Unified SIP プロキシの高可用性に関する検討事項

RecordRoute が無効な場合、Unified SIP Proxy は、アクティブコールのフェールオーバーを処理できます。フェールオーバー中のアクティブコールでは、バックアップ SIP Proxy サーバが新しいトランザクションを処理します。

ビジネス チャットおよび E メールハイ アベイラビリティの考慮事項

ビジネス チャットおよび E メール （ECE）は高可用性を提供します。同じ場所に配置された ECE 導入および 1500 エージェントクラスタは、次の技術を使用して地理的冗長性をサポートします。

- ロードバランサを使用すると、複数の Web サーバに着信要件を分散できます。サーバがダウンした場合、ロードバランサは、障害を検出し、別のアプリケーションサーバにリクエストをリダイレクトします。この機能は、最大 5 台の Web サーバで、各 Web サーバ上で 300 人のエージェントをサポートします。最大キャパシティには冗長性は提供されません。

- ネットワーク ラウンド トリップ時間内に、ECE のすべてのサブコンポーネントを保持します。詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/products-implementation-design-guides-list.html の「企業チャットおよび電子メール設計ガイド」を参照してください。

- Unified CCE コンポーネントに障害が発生した場合に ECE フェールオーバーをサポートするには、高可用性要件にしたばってエージェントと MR PG が実装されていることを確認します。この技法により、単一のサブコンポーネント障害が、すべてのセッションの処理をブロックしないようにします。

- Microsoft SQL サーバの可用性グループのクラスタリング構成を使用してデータベースをインストールします。詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/products-installation-guides-list.html の『企業チャットと電子メールインストレーションおよび構成ガイド』を参照してください。

- ロードバランシングの考慮事項ビジネス チャットおよび E メール

- ECE 他のコンポーネントに障害が発生した場合の動作

ロードバランシングの考慮事項ビジネス チャットおよび E メール

ECE デプロイメントの Web サービスコンポーネントの負荷を分散すると、多くのエージェントにサービスを提供できます。ロードバランサの裏に Web（または Web およびアプリケーション）サーバを仮想 IP アドレスで設定できます。エージェントが、仮想 IP アドレスで ECE にアクセスする場合、ロードバランサは、アドレスの裏にあるサーバのいずれかにリクエストを送信します。その後、ロードバランサは、エージェントに応答を返します。このように、セキュリティの観点から、ロードバランサはリバースプロキシサーバとしても機能します。

ロードバランサは、Cookie ベースの永続性を持つスティッキセッションをサポートする必要があります。メンテナンスタスク後は、すべての Web サーバおよびアプリケーションサーバで負荷を共有できることを確認します。すべてのサーバを使用せずにエージェントのアクセスを許可すると、スティッキ接続機能により、最初の Web サーバとアプリケーションサーバで過負荷が発生する可能性があります。

他のパラメータを使用すると、次の目的を満たす負荷分散アルゴリズムを定義できます。

- 均等な負荷分散

- プライマリ Web サーバとアプリケーションサーバの分離

- 低電力の Web サーバおよびアプリケーションサーバに送信するリクエスト数を減らします。

ロードバランサは、Web サーバとアプリケーションサーバの正常性をクラスタで監視します。障害発生時に、ロードバランサは、使用可能なサーバプールからそのサーバを削除します。

ECE 他のコンポーネントに障害が発生した場合の動作

一般に、他のソリューション コンポーネントに障害が発生した場合、アクティブセッションには影響しません。すべてのアクティブセッションが機能したままとなります。

この項では、別のソリューション コンポーネントに障害が起こった場合の、着信セッションに対する ECE 動作に関して説明します。

エージェント PG フェールオーバー

ECE サーバが接続されているエージェント PG がに障害が発生した場合、着信セッションへの影響は次のようになります。

- Web コールバックセッション — フェールオーバー期間中、カスタマーは、障害のある PG のエージェントに対して Web コールバックセッションをスケジュールすることはできません。他にエージェント PG が存在する場合、ECE は、それらの PG 上のエージェントに Web コールバックセッションを割り当てる必要があります。使用可能なエージェントが無い場合、Web コールバックセッションでリソースが利用可能になるまでキューに入れることができます。冗長 PG へのフェールオーバーが完了すると、すべての着信セッションが、その PG で利用可能なエージェントを使用できます。

- 遅延コールバックセッション — コールバック処理が冗長 PG に切り替わります。指定された遅延が経過すると、コールバックが実行されます。

- チャットセッション — 冗長 PG へのフェールオーバーが完了すると、着信チャットセッションがエージェントに到達します。

- 電子メール — 冗長 PG へのフェールオーバーが完了すると、受信電子メール処理が再開されます。

MR PG フェールオーバー

ECE サーバが接続されている MR PG がに障害が発生した場合、着信セッションへの影響は次のようになります。

- キューに入っているセッション — すでにキューに入っているセッションはキューに残ります。冗長 PG へのフェールオーバーが完了すると、ECE は、以前にキューに入ったセッションを PG に再発行します。

- Web コールバックセッション — 冗長 PG へのフェールオーバーが完了すると、新しいセッションがカスタマーとエージェント間で確立されます。

- 遅延コールバックセッション — コールバック処理が冗長 PG に切り替わります。指定された遅延が経過すると、コールバックが実行されます。

- チャットセッション — 冗長 PG へのフェールオーバーが完了すると、着信チャットセッションがエージェントに到達します。

- 電子メール — 冗長 PG へのフェールオーバーが完了すると、受信電子メール処理が再開されます。

CTI Manager のフェールオーバー

ECE サーバが接続されている CTI Manager に障害が発生した場合 、着信セッションへの影響は次のようになります。

- Web コールバックセッション — 新規セッションは置き換えることができず、カスタマーは、「システムは、エージェントをリクエストに割り当てることができません」というメッセージを受信します。

- 遅延コールバックセッション — コールバック処理が冗長 CTI Manager に切り替わります。指定された遅延が経過すると、コールバックが実行されます。

- チャットセッション — 冗長 CTI Manager へのフェールオーバーが完了すると、着信チャットセッションがエージェントに到達します。

- 電子メール — 冗長 CTI Manager へのフェールオーバーが完了すると、受信電子メール処理が再開されます。

ルータのフェールオーバー

アクティブなルータに障害が発生すると、冗長ルータがすべての着信セッションをシームレスに処理します。

ASR TTS 高可用性に関する考慮事項

Unified CCE ソリューションは、冗長 ASR/TTS サーバをサポートします。基本設定では、VXML ゲートウェイは最初に、すべての着信要求をプライマリ ASR/TTS サーバに渡します。プライマリサーバに到達できない場合、ゲートウェイはバックアップサーバに要求を渡します。バックアップサーバに到達した要求は、その要求機関までサーバにとどまります。

ロードバランサを追加して、着信要求を ASR/TTS サーバ全体に分散させることができます。

Cisco VVB は、冗長性に対してアクティブおよびバックアップの ASR/TTS サーバを使用しません。VVB には、ラウンドロビン方式でサーバのリストから選択するロードバランシング機能が組み込まれています。

選択した音声サーバが MRCP セッション設定要求を拒否した場合、VVB はもう一度、別のサーバで MRCP セッション設定を試みます。

アウトバウンドオプションの高可用性に関する検討事項

Cisco アウトバウンドオプションには、次のサブコンポーネントが含まれています。

サブコンポーネント

所在地

冗長性

説明

Campaign Manager

Logger A および B

冗長

コールに関連付けられているダイヤリングリストとルールを管理します。

アウトバウンド オプションのインポート

Logger A および B

冗長

キャンペーンレコードをインポートします。

アウトバウンド オプション データベース

Logger A および B

冗長

コール中のキャンペーンレコードを保留します。

SIP ダイヤラ

エージェント PG A または B

MR PG A または B

冗長

キャンペーンに応じて、キャンペーン マネージャが割り当てるダイヤリングタスクを実行します。SIP ダイヤラは、割り当てられたエージェントに接続するコールを転送します。

Cisco アウトバウンドオプションの高可用性を向上させるには、冗長 CUSP ペアを使用して複数の音声ゲートウェイに接続します。冗長ゲートウェイは、ゲートウェイに障害が発生した場合に、ダイヤラが発信に利用できる十分なトランクを確保できるようにします。発信コールがプライマリアプリケーションの場合、これらのゲートウェイを発信コールにのみルーティングできます。

アウトバウンドオプションの高可用性は、Logger サイド A のアウトバウンドオプションと Logger サイド B のアウトバウンドオプション間の双方向複製をサポートします。双方向複製は、Logger 間のパブリックネットワークで実行されます。

ソリューションは、ウォームスタンバイモードで複数のダイヤラと、ダイヤラを制御するキャンペーン マネージャの冗長ペアをサポートします。SIP ダイヤラの冗長ペアは、PG フォールトトレランスモデルと同様のウォームスタンバイモードで動作します。

- SIP ダイアラ 設計の留意事項

- キャンペーン マネージャ高可用性に関する考慮事項

SIP ダイアラ 設計の留意事項

SIP ダイヤラはウォームスタンバイモードで実行されます。キャンペーン マネージャは、登録されている SIP ダイヤラプールから SIP ダイヤラ を準備完了ステータスで有効化します。アクティブ化された SIP ダイヤラが、準備完了から準備中にステータスを変更した場合、または接続を失った場合、キャンペーン マネージャは、スタンバイの SIP ダイヤラを有効化します。タイムアウト期間経過後、キャンペーン マネージャは、すべての未解決レコードを保留ステータスに戻します。

CTI サーバ、エージェント PG または SIP サーバが切断した場合、アクティブ SIP ダイヤラに障害が発生します。SIP サーバは、音声ゲートウェイまたは CUSP を使用できます。冗長ペアの各ダイヤラを異なる SIP サーバに接続します。

法規制に準拠している場合、SIP Dialer はフェールオーバー中に進行中のコールを自動的に再試行しません。代わりに、ダイヤラは、アクティブなすべての顧客レコードと保留中の顧客レコードを、キャンペーン マネージャに送信します。キャンペーン マネージャが利用できない場合、ダイヤラは内部で閉じます。

CUSP サーバは、各ゲートウェイをサーバグループ構成の一環として、各ゲートウェイを構成することで複数ゲートウェイの展開で重み付けされた負荷分散と冗長性を提供します。ゲートウェイが過負荷状態または PSTN ネットワークへの WAN リンクを失った場合、CUSP はアウトバウンドコールを次に利用可能なゲートウェイに再送できます。

キャンペーン マネージャと SIP ダイヤラには、すでにウォームスタンバイ機能が含まれています。このため、アウトバウンドオプション専用の CUSP サーバには Hot Swappable Router Protocol（HSRP）機能は使用しないでください。

- 障害時のアウトバウンド オプション レコード処理

障害時のアウトバウンド オプション レコード処理

ダイヤラは、カスタマーのレコードの中間ステータスで、キャンペーン マネージャを更新します。これにより、ダイヤラが失敗した場合に、キャンペーン マネージャは次のアクションを追跡できます。

ダイヤラが SIP Invite を送信してカスタマーにコールすると、キャンペーン マネージャにカスタマーレコードの状態更新メッセージが送信されます。その後、キャンペーン マネージャは、[ダイヤリングリスト（DL）（DialingList (DL)] テーブルで、レコードの CallStatus を [ダイヤル済み（Dialed）] 状態に更新します。

また、キャンペーン マネージャは、次のイベントでカスタマーレコードの状態を更新します。

- 通話に成功: キャンペーン マネージャは、カスタマーレコードを [終了（Closed）] 状態に更新します。

- ダイヤラとキャンペーン マネージャ間の接続に失敗：すべての [ダイヤル済み（Dialed）] 状態のレコードは、[ダイヤル済み（Dialed）] 状態のままになります。アクティブ状態レコードが [不明（Unknown）] 状態に変わります。

- ダイヤラと CTI サーバ間の接続に失敗：キャンペーン マネージャは、カスタマーレコードを [終了（Closed）] 状態に更新します。次に、キャンペーン マネージャは、ダイヤラ切断状態を送信すると、すべてのアクティブ状態のレコードは、[不明（Unknown）] 状態となります。[ダイヤル済み（Dialed）] 状態のレコードは、[ダイヤル済み（Dialed）] 状態のままになります。

- ダイヤラと SIP ゲートウェイ（GW）間の接続に失敗：エージェントデスクトップからコールがリリースされると、キャンペーン マネージャは、[終了（Close）] 状態のカスタマー レコード メッセージを受信します。この状況の場合、エージェントデスクトップからコールがリリースされると、すべての [ダイヤル済み（Dialed）] 状態レコードが [終了（Closed）] 状態に変化します。アクティブ状態レコードが [不明（Unknown）] 状態に変わります。

- ダイヤラと MR PIM 間の接続に失敗：キャンペーン マネージャは、接続状態のダイヤラ ステータス メッセージのみを受信します。[終了（Closed）] のカスタマー レコード メッセージを受信したら、レコードが [終了（Closed）] 状態に更新されます。

- キャンペーン マネージャが失敗した場合：すべての [ダイヤル済み（Dialed）] 状態のレコードが、[終了（Closed）] 状態に変わります。アクティブ状態レコードが [不明（Unknown）] 状態に変わります。

キャンペーン マネージャ高可用性に関する考慮事項

キャンペーン マネージャは、冗長ペアであるサイド A およびサイド B としてウォーム スタンバイモードで実行します。デフォルトでは、サイド A のキャンペーン マネージャ（キャンペーン マネージャ A）は、アクティブなキャンペーン マネージャとして設定されます。キャンペーン マネージャ B はスタンバイのキャンペーン マネージャとして設定されます。Logger の各冗長ペアには、独自のキャンペーン マネージャおよびアウトバウンド オプション インポートがあります。

アウトバウンド オプション高可用性を有効にする際は、プロセスは、連絡テーブル、ダイヤリング リスト、通話禁止テーブルおよび、個人的コールバック（PCB）に対する双方向データベースの複製を開始します。

システムのスタートアップ時に、アウトバウンド オプション インポートおよびダイヤラは、キャンペーン マネージャへの接続を開始します。スタンバイ キャンペーン マネージャは、スタンバイサイドからのアウトバウンド オプション インポート接続を受け入れ、アウトバウンド オプション インポートをスタンバイ状態に設定します。ただし、スタンバイ キャンペーン マネージャは、常駐側からのダイヤラ接続を含むダイヤラ接続を拒否します。アクティブなキャンペーン マネージャは、スタンバイ側からのダイヤラを含む、アウトバウンド オプション インポートおよびダイヤラ接続を受け入れます。

Logger 側のアウトバウンド オプション（ブレンドエージェント）インポート プロセスは、同じ Logger 側のキャンペーン マネージャのみと通信します。したがって、各サイドにあるキャンペーン マネージャとブレンド エージェント インポートのプロセスのステータスは、お互い同期しています。

ダイヤラまたはブレンド エージェント インポート プロセスのいずれかが、EMTClientTimeoutToFailover 間隔内でキャンペーン マネージャに接続できない場合、キャンペーン マネージャは切り替わります。

次の障害が発生した場合、キャンペーン マネージャはフェールオーバーします。

- アウトバウンド オプション インポートへの接続に失敗した場合。

- すべてのダイヤラへの接続に失敗した場合。

Note

キャンペーン マネージャが 1 つのダイヤラに接続されている場合は、アクティブなキャンペーン マネージャはフェールオーバーしません。

- すべてのダイヤラが、アクティブなキャンペーン マネージャに [準備中（Not Ready）] のステータスをレポートする場合。

- ルータへの接続が失敗する場合。

障害が発生したキャンペーン マネージャがオンラインに戻ると、スタンバイ状態に設定されます。アクティブなキャンペーン マネージャはアクティブな状態を継続します。

冗長ペア内の 1 つの キャンペーン マネージャに障害が発生した場合、別側が、複製フォルダ内のファイルシリーズの複製トランザクションを保管します。Logger でディスク容量を調整する際は、これを考慮してください。

Note

アウトバウンド オプションの高可用性が有効になっていない場合、ルータは、展開入タイプを必要に応じて認識し、フェールオーバー メッセージを破棄します。

- キャンペーン マネージャ障害発生時のダイヤラの動作

キャンペーン マネージャ障害発生時のダイヤラの動作

ダイヤラは、アクティブなキャンペーン マネージャに接続します。ダイヤラは、アクティブなキャンペーン マネージャに接続されるまで、サイド A とサイド B の間でキャンペーン マネージャに接続試行します。アクティブなキャンペーン マネージャがダウンすると、構成可能な間隔（デフォルト値は、60 秒）の後、スタンバイ中のキャンペーン マネージャがアクティブになります。

ダイヤラのフェールオーバーの動作は次のとおりです。

- システム起動時：サイド A キャンペーン マネージャがアクティブになります。ダイヤラは最初に サイド Ａ のキャンペーン マネージャに接続リクエストを送信します。このキャンペーン マネージャに接続できない場合、設定可能な間隔後、ダイヤラは、サイド B のキャンペーン マネージャにリクエストを送信します。アクティブなキャンペーン マネージャの接続が受領され、確立されます。

- ダイヤラかアクティブなキャンペーン マネージャへの切断を検出した場合：ダイヤラは、スタンバイ中のキャンペーン マネージャに接続リクエストを送信します。そのキャンペーン マネージャのフェールオーバーが完了すると、スタンバイ中のキャンペーン マネージャはアクティブなキャンペーン マネージャとなり、ダイヤラに接続します。

キャンペーン マネージャのフェールオーバーが発生していない場合は、スタンバイ中のキャンペーン マネージャは接続リクエストを拒否します。その後、ダイヤラは、どちらかのキャンペーン マネージャがアクティブになり、接続リクエストを承認するまで、キャンペーン マネージャ間で接続リクエストを交互に送信します。

Microsoft Windows イベントビューア、SYSLOG および SNMP は、ダイヤラの切断および接続試行をキャプチャします。

シングルサインオンの高可用性に関する考慮事項

クラスタとして、Cisco Identity Service（Cisco IdS）を導入します。クラスタには、発行者とサブスクライバが含まれます。クラスタノードは、クラスタ全体で自動的に構成データと承認コードを複製します。ノードが再接続されると、クラスタは最新の構成および承認コードデータを決定し、クラスタ全体の構成を再現します。

コンタクトセンター アプリケーションは、任意のノードに到達できる場合、エージェントまたはスーパーバイザを認証または承認します。コンタクトセンター アプリケーションは、ローカルの Cisco IdS ノードをデフォルトで照会します。そのノードが利用できない場合、アプリケーションは、構成済みのリモートノードを照会します。ローカルノードがクラスタに再接続されると、アプリケーションはローカルノードのクエリに戻ります。

ネットワークでパケット損失が 5% を超えると、他のノードが発行した承認コードを使用してノードがアクセストークンを取得しない可能性があります。この場合、ユーザは再度サインインする必要があります。パケット損失が大き過ぎたか、接続が失われた場合、Cisco IdS は、単独ノードとして機能します。クラスタは、ネットワーク接続が向上すると自動的にリフォームします。

Chapter 7. ソリューションのセキュリティ

- セキュリティの概要

- ネットワーク ファイアウォール

- ホスト ベース ファイアウォール

- Active Directory の展開

- IPSec の展開

- サーバセキュリティ設定

- エンドポイント セキュリティ

- 転送中の安全な PII

セキュリティの概要

Contact Center Enterprise ソリューションのセキュリティを実現するには、アクセス、接続、要件そしてシステム管理を正確に定義するセキュリティポリシーが必要です。優れたセキュリティポリシーにより、使用可能なシスコの技術を使用して、データセンターのリソースを内部および外部の攻撃から保護できます。セキュリティ対策により、データプライバシー、整合性、およびシステムの可用性が確保されます。

Contact Center Enterprise ソリューションのセキュリティに関する考慮事項は、Cisco Unified Communications ソリューションの別のアプリケーションの考慮事項と類似しています。Contact Center Enterprise ソリューションは、非常にさまざまで、複雑なネットワーク設計を必要とすることがよくあります。これらの展開では、レイヤ 2 およびレイヤ 3 ネットワーキングまた、音声、VPN、QoS、Microsoft Windows Active Directory、その他のネットワーキングの問題への適性が必要です。この章では、これらのエリアについてのガイダンスの一部を説明します。ただし、これは安全なコンタクトセンターの展開に関してすべてが記載されたガイダンスではありません。

Unified Communications Security Solution ポータルと一緒に、http://www.cisco.com/c/en/us/solutions/enterprise/design-zone/index.html に記載されている「設計ゾーン」 の設計ドキュメントを使用します。これらのドキュメントは、Cisco Unified Communications 用のネットワーク インフラストラクチャの適切な構築に関する情報を提供します。特に、セキュリティおよび Cisco Unified Communications に関する関連ドキュメントを参照してください。

- Cisco Unified Communications Manager に基づいた Cisco Unified Communications SRND

- データセンターネットワーク：サーバファームセキュリティ SRNDv2

- サイト間 IPSec VPN SRND

- 音声およびビデオに対応した IPSec VPN（V3PN）SRND

- Business Ready Teleworker SRND

これらのドキュメントの更新や追加は定期的に行われるので, 頻繁に「設計ゾーン」を参照してください。

この章では、Windows Active Directory の設計および展開における複雑さについては限定して説明します。詳細については、Microsoft の次のトピックを参照してください。

- 新しい Active Directory 論理構造の設計

- Active Directory の初回展開

- 既存の Windows 環境から Microsoft Windows サーバ 2012 R2 Active Directory へのアップグレード

- 現在の環境を Windows Active Directory 環境に強化

特に 、「Microsoft Windows サーバ 2012 R2」の「ディレクトリおよびセキュリティサービスの設計と展開」項を参照してください。この項は、組織のすべての Active Directory の設計と導入の目標を達成するために役立ちます。https://technet.microsoft.com/library/hh801901.aspx で Microsoft TechNet の項目を参照してください。

- セキュリティレイヤ

- セキュアなシグナリングおよびメディアの設計と構成

- プラットフォームの違い

- セキュリティ設計要素

セキュリティレイヤ

適切に安全なソリューションを提供するには、さまざまな脅威から保護する多層化されたアプローチが必要です。

次のセキュリティ層を実装し、セキュリティ層のポリシーを確立します。

- 物理セキュリティ —コンタクトセンターのアプリケーションをホストするサーバが物理的に安全であることを確認します。権限を持つ担当者のみがアクセスできるデータセンター内のサーバを見つけ出します。また、ケーブル接続用のプランタ、ルータ、スイッチへのアクセスも制御します。強力な物理層ネットワーク セキュリティ プランの実装には、データスイッチでのポートセキュリティのような技術も含まれます。

- 境界セキュリティ — 安全なデータネットワークの設計や展開は複雑な情報カテゴリです。このガイドでは、Contact Center Enterprise ソリューションに対して効果な境界セキュリティを確立するリソースへの参照を提供します。

- データセキュリティ — カスタマーの個人情報の盗聴を保護するレベルを向上させるため、Contact Center Enterprise ソリューションは、エージェントデスクトップで Transport Layer Security（TLS）をサポートします。また、サーバ間の通信チャネルを保護するための IPSec もサポートしています。

Note

Contact Center Enterprise ソリューションは、デフォルトで TLS 1.2 を使用します。ほとんどのコンポーネントでは、必要に応じて以前のバージョンの TLS を有効にすることができます。

- ホスト べース ファイアウォール — Windows ファイアウォールを使い、一方的な着信トラフィックでサーバを攻撃する悪意のあるユーザやプログラムから保護します。VM の Windows ファイアウォール構成ユーティリティを使用して、Windows サーバ 2012 R2 のファイアウォール コンポーネントと統合します。

- ウイルス保護 — 最新のウイルス定義ファイル（日次更新がスケジュールされている）を備えたウイルス対策アプリケーションをすべての VM で実行します。テスト済みおよびサポートされているすべてのウイルス対策アプリケーションの一覧については、ソリューションの「互換性マトリックス」を参照してください。

- パッチ管理 — すべてのセキュリティ更新を適用せずにソリューションをライブネットワークに接続しないでください。Microsoft（Windows、SQL サーバ、Internet Explorer など）およびその他のサードパーティ製のセキュリティパッチを使用して、すべてのホストを最新の状態に保ちます。http://www.cisco.com/c/en/us/products/collateral/customer-collaboration/unified-contact-center-enterprise/product_bulletin_c25-455396.htmlで、サードパーティ製のパッチ管理ポリシーを参照してください。

これらのセキュリティ層の大半については、Contact Center Enterprise ソリューションが複数の機能をサポートしています。ただしシスコは、企業ポリシー、安全なソリューションの展開や維持の手順に関して、管理または強制はできません。

セキュアなシグナリングおよびメディアの設計と構成

TLS-SRTP は、CallServer で SIP 信号と RTP の暗号化をサポートします。この図は、包括的な展開モデルを説明しています。

導入モデル

1. Unsecured

この展開モデルは、CVP および VVB の以前のリリースのモデルです。操作は以前と同じようにレンダリングされます。これは、既存のソリューションに対して影響のない展開です。

2. セキュア シグナリングのみ

この展開モデルでは、セキュリティで保護されていないモデルにシグナリング セキュリティが導入されます。操作が強化され、コール セットアップ用の SIP が保護されます。これにより、音声が聞こえる前のすべてのデータ交換がセキュアな方法で行われます。

3. エージェント コールのメディア セキュリティを使用したセキュア シグナリング

この展開モデルは、シグナリング セキュリティをサポートし、発信者とエージェント間のメディアとオーディオのセキュリティをさらに追加します。発信者と企業内の IP ネットワークを介して伝送されるエージェント間の音声コンテンツは、ハッキングやスヌーピングに対して耐性があります。

4. IVR およびエージェント コールのエンドツーエンド メディア セキュリティを使用したシグナリング

この展開モードは、コールに対する完全なセキュリティ保護を提供します。これにより、シグナリングが保護されるだけでなく、発信者から IVR へのメディアと音声、およびエージェントも保護されます。

Note

- TLS / SRTP展開の場合：

- CVP と VVB が G711 mu-law であり、すべてのエージェントが G729 である場合、Unified CM は、ウィスパー アナウンス レッグでのセキュアなトランスコーディングをサポートしません。セキュアなトランスコーディングをサポートする回避策として、G729 の VVB を使用してアナウンスを再生します。

通話フロー

- メディア暗号化（SRTP）の考慮事項

メディア暗号化（SRTP）の考慮事項

展開で SRTP を有効にする前に以下を考慮してください。

- エージェントレグで安全なメディアを使用するには、インストール済みの IP 電話が SRTP と互換性があることを確認してください。

- 仮想化音声ブラウザは、VRU レグの SRTP をサポートします。

- IOS VXML ゲートウェイは SRTP をサポートしません。

- モバイルエージェントは SRTP を使用できません。

- Cisco アウトバウンドオプション ダイヤラは SRTP をサポートしません。コールがダイヤラに接続されている間、コールは SRTP を使用できません。ただし、コールがダイヤラに接続されなくなると SRTP とネゴシエートできます。

プラットフォームの違い

Contact Center Enterprise ソリューションは、管理方法が異なる複数のアプリケーションサーバで構成されています。プライマリサーバは、中核的なコンポーネント向けです。これらサーバは、標準規格の（デフォルト）オペレーティングシステムのインストレーションのみにインストールします。Windows サーバ 2012 R2 にインストールしたコンポーネントには、Windows サーバソフトウェアのデフォルト リテール バージョンのみを使用します。最新のデバイスドライバ、セキュリティアップデートなどによって、オペレーティングシステムを最新の状態に保ちます。

Unified Communications Manager（Unified CM）などの一部のサーバは、Cisco Voice Operating System（VOS）で実行されます。シスコから該当するすべてのパッチオペレーティングシステムの更新を入手します。このオペレーティングシステムのセキュリティ強化仕様に関しては、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/tsd-products-support-series-home.html の「『Cisco Collaboration System Solution Reference Network Designs』」および別の Unified CM 製品ドキュメントを参照してください。

適切なセキュリティはサーバによって異なります。これらのサーバを環境内で設計、導入、および保守する場合は、次の点に留意します。シスコの Unified Communications 製品は、同じカスタマイズ済みオペレーティングシステム、ウイルス対策アプリケーション、およびセキュリティ パス管理技術をサポートするという最終目標に向けて、常に機能強化されています。

セキュリティ設計要素

Unified CCE には http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html で Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド があります。そのガイドでは、この章の情報について説明されています。このガイドでは、セキュリティの実装の詳細と、Unified CCE 展開のセキュリティ確保に関する一般的なガイダンスについて説明します。セキュリティ機能には、次のトピックが含まれています。

- 暗号化のサポート

- IPSec および NAT のサポート

- Windows ファイアウォールの構成

- 自動セキュリティ強化

- Microsoft Windows のアップデート

- SQL サーバの強化

- SSL 暗号化

- Microsoft Baseline Security Analysis

- 監査

- ウイルス対策ガイドライン

- セキュアなリモート管理

- シングル サインオン

ガイドラインは、Microsoft や他のサードパーティベンダーによって発表された強化ガイドラインの一部に基づいています。このガイドは、製品内のほとんどのセキュリティ機能の基準点として機能します。このガイドでは、さまざまな Contact Center Enterprise ツールにバンドルされている Automated OS および SQL Security Hardening のインストレーションに関して説明します。

- その他のセキュリティ機能

その他のセキュリティ機能

その他のセキュリティドキュメント

セキュリティに関するトピック

ドキュメントおよび URL

サーバのステージングおよび Active Directory の展開

Cisco Unified ICM/Contact Center Enterprise ステージング ガイド at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-guides-list.html

SNMPv3 の認証および暗号化

Cisco Unified ICM/Contact Center Enterprise SNMP ガイド at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html

機能制御（ソフトウェアアクセス制御）

Cisco Unified ICM/Contact Center Enterprise コンフィギュレーション ガイド at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html

リアルタイムクライアントの検証

Cisco Unified ICM セットアップおよびコンフィグレーション ガイド at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-guides-list.html

ネットワーク ファイアウォール

ソリューション用のファイアウォールを展開する際は、いくつかの検討すべき要素があります。Demilitarized Zone（DMZ; 緩衝地帯）ではコアコンポーネントに対してアプリケーションサーバをインストールしないでください。外部から見えるネットワークや企業のネットワークからサーバをセグメント化します。VM をデータセンターに配置し、適切なファイアウォールまたはルータをアクセス制御リスト（ACL）で設定して、トラフィックを制御します。

ファイアウォールを適切に使用するには、どの TCP/UDP IP ポートが使用されるのか、ファイアウォールの導入とトポロジを検討し、ネットワークアドレス変換（NAT）の影響を知るネットワーク管理者が必要です。

- TCP/IP ポート

- ネットワーク ファイアウォール トポロジ

- ネットワーク アドレス変換

- ASA NAT とファイアウォール

TCP/IP ポート

Contact Center Enterprise ソリューションで使用するポートのインベントリについては、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html の「 Cisco Unified Contact Center Enterprise Solutions ポート使用状況ガイド」を参照してください。

Unified CM が使用するポートについては、の『 Cisco Unified Communications Manager の TCP および UDP ポートの使用ガイド』を参照してください。http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html

ファイアウォールの構成を支援するため、このガイドにはエージェントデスクトップとサーバ間の通信、アプリケーション管理、およびレポート生成に使用されるプロトコルとポートが記載されています。また、イントラサーバ通信に使用されるポートのリストも記載されています。

ネットワーク ファイアウォール トポロジ

AD 管理者が OU を作成する Active Directory モデルでは、次を実行します。

- 企業境界ファイアウォールで次のポートをブロック

- UDP ポート 135、137、138、および 445

- TCP ポート 135、139、445 および 593

- 適切に設定されたレイヤ 3 およびレイヤ 4 ACL を展開します。

- 専用の Historical Data サーバをインストールすることで、データベースと Web サービスを分離します。

- Administration & Data サーバ（ADS）の数を最小限にし、管理クライアント（データベース不要）とインターネット スクリプト エディタ クライアントを使用します。

- イントラサーバ通信を暗号化するために、Windows IPSec（ESP）を展開します。

- 地理的に分散したサイト、リモートブランチサイト、またはアウトソースサイトの間におけるサイト間 VPN には Cisco IOS IPSec を使用します。

ネットワーク アドレス変換

ネットワークアドレス変換（NAT）は、ネットワーク ルータ上に常駐する機能で、プライベート IP アドレス割り当ての使用を可能にします。プライベート IP アドレスとは、インターネット上にはルーティングできない IP アドレスのことです。NAT が有効になっているときには、プライベート IP ネットワーク上のユーザは NAT ルータ経由でパブリックネットワーク上のデバイスにアクセスできます。

NAT が有効になっているルータに IP パケットが到達すると、ルータがプライベート IP アドレスをパブリック IP アドレスで置き換えます。HTTP や Telnet などのアプリケーションの場合は、NAT で問題が発生することはありません。ただし、IP パケットペイロード内で IP アドレスを交換するアプリケーションでは、IP パケットペイロード内の IP アドレスが置き換えられない問題が発生します。IP ヘッダー内の IP アドレスだけが置き換えられます。

この問題を解決するため、Cisco IOS ベースのルータおよび PIX/JT ファイアウォールでは、CT-JTBE（TAPI/JTAPI）を含むさまざまなプロトコルおよびアプリケーションに対する fix-ups を実装します。このフィックスアップを使用すれば、NAT の処理を実行するときに、ルータがパケット全体を参照して必要なアドレスを置き換えるようになります。このプロセスが動作するには、Cisco IOS または PIX/ASA のバージョンと Unified CM バージョンとの互換性が必要です。

Unified CCE は、NAT を介した接続をサポートしています。詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-configuration-examples-list.html の「 Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド」に記載されている『"IPSec および NAT サポート"』の項を参照してください。

ASA NAT とファイアウォール

Cisco 適応型セキュリティアプライアンス（ASA）ファイアウォールは、単一のセキュリティアプライアンスを、セキュリティコンテキストと呼ばれる複数の仮想デバイスに分割します。各コンテキストは、独自のセキュリティ ポリシー、インターフェイス、および管理者を持つ独立したデバイスです。マルチ コンテキストは、複数のスタンドアロン デバイスを使用することに似ています。各コンテキストにより、カスタマートラフィックは分離され、安全になり、構成が容易になります。すべてのカスタマートラフィックが最初にファイアウォールに送信された後、コンピュータリソースに転送されます。

ホスト ベース ファイアウォール

ネットワークの最も内側のレイヤでホスト ファイアウォールを保護することで、Windows ファイアウォールは、多層防御セキュリティ戦略の一部として効果的に機能します。Contact Center Enterprise ソリューションは、VM の Windows ファイアウォールの展開をサポートします。 Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド には、本機能の実装および構成に関する章が記載されています。

Windows ファイアウォール構成ユーティリティを使用して例外を構成すると、アプリケーションに必要なポートを開くことができます。

Windows ファイアウォールは、Unified CCE のインストール中に設定され、必要なポートが開きます。

Windows ファイアウォールの詳細については、Microsoft のマニュアルを参照してください。

Active Directory の展開

この項では、Active Directory の展開トポロジについて説明します。Active Directory（AD）展開ガイダンスの詳細は、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-guides-list.html の Cisco Unified ICM/Contact Center Enterprise ステージング ガイド を参照してください。

専用の Windows Active Directory ドメインにソリューションを展開できますが、要件ではありません。代わりに、組織単位を使用してセキュリティの基本理念を展開できます。これは AD と密接に統合し、セキュリティ委任の権限を行使することで、企業の AD ディレクトリは、アプリケーションサーバ（ドメインメンバーシップ用）、ユーザおよびサービスのアカウント、およびグループを収容するのに使用できます。

グローバル カタログの要件

Contact Center Enterprise ソリューションは、Active Directory のグローバルカタログを使用します。Unified CCE Hosts が格納されている AD フォレスト内のすべてのドメインは、そのドメインのグローバルカタログを公開する必要があります。これには、ソリューションが通信を行う認証、ユーザルックアップ、グループ検索などのすべてのドメインが含まれます。

Note

これは、フォレスト間の操作を意味するものではありません。フォレスト間操作はサポートされていません。

- Active Directory サイトトポロジ

- 組織

- Active Directory から CCE 認証を分離する

- Active Directory と Customer Collaboration Platform ユーザアカウント

Active Directory サイトトポロジ

地理的に分散された Contact Center Enterprise ソリューションでは、各サイトで冗長ドメインコントローラを配置します。各サイトでグローバルカタログを確立し、サイト間複製接続を適切に構成します。Contact Center Enterprise ソリューションは、サイト内の Active Directory サーバと通信します。これには、Microsoft のガイドラインに従って適切に実装されたサイトトポロジが必要です。

組織

- アプリケーションによって作成された OU

- Active Directory 管理者が作成した OU

アプリケーションによって作成された OU

ソリューションソフトウェアをインストールする場合、VM がメンバーである AD ドメインはネイティブモードである必要があります。インストールすると、ソリューションに複数の OU オブジェクト、コンテナ、ユーザ、およびグループが追加されます。これらのオブジェクトをインストールするには、AD の組織単位に対する代理制御が必要です。ドメイン階層の任意の場所に OU を配置します。AD 管理者は、Contact Center Enterprise ソリューション OU 階層をどの程度深くネストして作成し、データを入力するかを決定します。

Note

作成されるグループはすべてドメイン ローカル セキュリティ グループとなり、ユーザアカウントはすべてドメインアカウントとなります。サービス ログオン ドメイン アカウントは、アプリケーションサーバのローカル管理者のグループに追加されます。

Contact Center Enterprise のインストールによって、Domain Manager ツールと統合されます。このツールは OU 階層およびソフトウェアが必要とするオブジェクトを事前インストールする際にスタンドアロンで使用できます。また、設定プログラムが呼び出され、AD で同じオブジェクトを作成するときにも使用できます。AD/OU は、実行中の VM がメンバであるドメイン、または信頼できるドメイン上に作成できます。

Active Directory 管理者が作成した OU

管理者は、特定の AD オブジェクトを作成できます。主な例は、Unified CCE サーバの OU コンテナです。この OU コンテナは、特定のドメインのメンバーである VM を含めるよう手動で追加されます。ドメインに参加したら、この OU にこれら VM を移動します。この分離は、サーバを管理できる人とできない人（制御の分離）を制御します。最も重要なのは、分離が、OU 内のアプリケーションサーバが継承できる、または継承できない AD ドメイン セキュリティ ポリシーを制御する点です。

Active Directory から CCE 認証を分離する

リリース 12.0(1) 以前は、Unified CCE は、Microsoft Active Directory Security Groups を使用して、設定や構成タスクを実行するユーザのアクセス権を制御していました。Microsoft AD は、システムコンポーネントが対話する権限も付与します。たとえば、このデータベースは、Logger データベースを読み取る権限をディストリビュータに付与します。Microsoft AD は、セキュリティグループ - 設定、構成、およびサービスに関連付けられているユーザ権限を管理します。したがって、Microsoft AD は、認証と承認の両方を処理しました。このような場合、Microsoft AD はセキュリティグループにユーザ権限を割り当てる必要があります。これを実現するには、Unified CCE ソリューション管理で、承認のために Microsoft AD に対する書き込み権限が必要です。

デフォルトでは 、Unified CCE により 、現在、認証および承認機能が切り離されています。

認証と認可を切り離すと、Microsoft AD を使用して、Unified CCE コンポーネントの許可を管理する必要がなくなります。Unified CCE ソリューションでは、承認のために、各ローカルマシン上のローカルユーザグループにユーザ ID を追加する必要があります。ユーザ権限は、ローカル マシンのローカル ユーザ グループへのメンバーシップによって提供されます。Microsoft AD は認証にのみ使用されます。

Microsoft AD にすでに存在するユーザ ID を承認するには、ユーザ ID を関連付けるか、ローカルユーザグループに追加します。

- ユーザ ID をローカルの UcceService セキュリティグループに関連付け、SQL データベースでの読み取り/書き込み操作用の SQL サーバの承認をユーザ ID に提供します。Service Account Manager ツールを使用して、ドメインユーザをサービス アカウント ユーザとして割り当てます。

- Unified CCE 設定操作用のローカル管理者グループにユーザ ID を追加します。Unified CCE 構成操作用のローカル UcceService セキュリティグループにユーザ ID を追加します。ユーザ ID がローカル管理者グループに追加されている場合は、User List ツールで、[設定（Setup）] チェックボックスをオンにします。ユーザ ID がローカル UcceService グループに追加されている場合、[構成（Config）] をオンにしすると、ユーザのセキュリティ グループ メンバーシップ（管理者グループまたは構成グループ）が、データベーススキーマにあるユーザグループテーブル内の User_Role コラムに表示されます。

ADSecurityGroupUpdate レジストリ キー

このレジストリキーは、インスタンスの組織単位（OU）の下で、ドメイン内の設定および設定セキュリティ グループの更新を許可または拒否します。

キーは、次の 2 つの値があります。

- 0 — User List ツールが、インスタンス OU のドメイン内の構成および設定セキュリティグループ更新していないことを示します。

- 1 — User List ツールが、インスタンス OU のドメイン内の構成および設定セキュリティグループ更新していることを示します。

デフォルト値は 0 です。

サービス アカウント マネージャのユーザ ヘルス

アップグレード後、Service Account Manager は UcceService ローカルグループ内のユーザを確認します。ユーザが、UcceService ローカルグループに存在しない場合、Service Account Manager は、[動作不良（Unhealthy）] というステータスを表示します。このような場合は、Fix Group Membership を実行してステータスを正常にします。または、Service Account Manager（SAM）ツールまたは、Websetup に新規ドメインユーザを提供します。

機能拡張の詳細については、次のガイドを参照してください。

- Cisco Unified ICM/Contact Center Enterprise ステージング ガイド の Service Account Manager に関する章。

- Unified CCE インスタンスへのコンポーネントの追加、ローカルマシンでの権限構成、および Cisco Unified Contact Center Enterprise インストールおよびアップグレード ガイド にデータベースを移行の項。

Active Directory と Customer Collaboration Platform ユーザアカウント

Customer Collaboration Platform は、侵害を受けたシステムのリスクを軽減するためにエージェントのログイン情報の保管を最小限に抑えます。Customer Collaboration Platform は、システム設定の管理アカウントのみを保持しています。Customer Collaboration Platform は、Active Directory（AD）認証をすべてのエージェントアクセスに使用します。Customer Collaboration Platform サーバは、エージェントのログイン情報を保存しません。

Customer Collaboration Platform でエージェントアカウントを作成することはできません。AD が認証するすべてのアカウントで Customer Collaboration Platform を使用できます。アプリケーションを使用できるユーザを制限するには、AD グループを設定したら、Customer Collaboration Platform を構成して、そのグループへのアクセスのみを許可します。

一般に、AD が認証するエージェントは、すべての Customer Collaboration Platform 機能にアクセスできます。特定の URL をブロックすることで、パネルへのアクセスをブロックできます。

IPSec の展開

Contact Center Enterprise ソリューションは、VM とサイト間の重要なリンクを保護するために、Microsoft Windows ISec と Cisco IOS ISec の 1 つまたは両方に依存しています。次の方法でソリューションを保護できます。

- VM とサイト間にピアツーピア ISec トンネルを展開する方法

- より制限が厳しく、事前設定済みのネットワーク分離 ISec ポリシーを展開する方法

- 併用する場合

ピアツーピア ISec の導入では、Microsoft によって提供されるツールを使用して、セキュリティで保護されている各通信パスを手動で構成する必要があります。ただし、ネットワーク分離 IPSec ユーティリティを使用すると、各 VM にネットワーク分離 IPSec ポリシーを自動で展開できます。このユーティリティは、例外が発生しない限り、その VM との間のすべての通信パスを保護します。ネットワーク分離 IPSec ユーティリティは、すべての Contact Center Enterprise サーバにデフォルトでインストールされます。

Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド は、適切な設定などを含む Windows IPSec の展開に役立つサポートされているパスと情報を一覧します。

Note

IPSec を有効にすると、いくつかの重要なエリアで、拡張性に影響を与えます。

Contact Center Enterprise ソリューションでの接続パスの一部は IPSec をサポートします。次の図は、Windows IPSec または Cisco IOS IPSec で保護する必要があるさまざまなサーバ相互接続を示しています。この図は、TLS をサポートする複数のパスも示しています。

IPSec の展開例

サーバセキュリティ設定

- ユニファイド コンタクト センター セキュリティ ウィザード

- ウイルス対策

- 侵入防御

- パッチ管理

ユニファイド コンタクト センター セキュリティ ウィザード

ユニファイド コンタクト センター セキュリティウィザードにより、SQL サーバ の強化、Windows ファイアウォールの構成、ネットワークの分離 ISec ポリシーの導入など、これらのセキュリティ機能を簡単に構成できます。セキュリティウィザードは、これらユーティリティの機能を使いやすいインターフェイスでカプセル化し、セキュリティ機能の構成に関連する手順でユーザを導きます。（これは、ネットワーク分離 IPSec ポリシーの展開時に役立ちます）。Unified CCE のインストールには、デフォルトでセキュリティウィザードが含まれます。

ウイルス対策

- ウイルス対策アプリケーション

- 設定のガイドライン

ウイルス対策アプリケーション

Contact Center Enterprise ソリューションは、いくつかのサードパーティ製のウイルス対策アプリケーションをサポートしています。ソリューションとソリューションで対応するバージョンの一覧に関しては、ソリューション向けの「互換性マトリックス」を、サポート済みのアプリケーションに関しては、Unified Communications Manager 製品関連のドキュメントを参照してください。

ソフトウェアの競合を避けるため、お使いの環境にはサポートされているアプリケーションだけを展開してください。

設定のガイドライン

ウイルス対策アプリケーションには、スキャンするデータとそのスキャン方法を詳細に制御できる多数の構成オプションがあります。

どのウイルス対策製品を使用する場合でも、スキャンと VM パフォーマンスのバランスを取るために構成を行います。スキャンを選択するほど、パフォーマンスのオーバーヘッドが大きくなります。システム管理者は、ウイルス対策アプリケーションをインストールするために最適な構成要件を決定します。より詳細な Contact Center Enterprise ソリューションに関する構成情報は、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド および、特定のウイルス対策製品に関する書類を参照してください。

次のリストでは、一般的なルールについて説明します。

- サポートされている最新バージョンのウイルス対策アプリケーションにアップグレードします。バージョンが新しいと、以前のバージョンよりもスキャン速度が向上し、VM のオーバーヘッドが軽減されます。

- リモートドライブ（ネットワークマッピングまたは UNC 接続など）からアクセスされているファイルのスキャンを回避します。すべてのスキャンをローカルに保持するために、すべてのマシンにウイルス対策ソフトウェアがインストールされているのが理想です。多層構成のウイルス対策戦略では、ネットワーク全体のスキャンやネットワーク負荷の追加は必要ありません。

- ヒューリスティックスキャンは、従来のウイルス対策スキャンよりもオーバーヘッドが大きくなります。この高度なスキャンオプションは、信頼できないネットワーク（電子メールやインターネットゲートウェイなど）からのデータエントリの重要なポイントでのみ使用します。

- リアルタイムまたはアクセス時のスキャンを有効にすることは可能ですが、その対象を着信ファイルだけにします（ディスクへの書き込み時）。これは、ほとんどのウイルス対策アプリケーションにとってのデフォルト設定です。ファイルと読み取りのオンアクセススキャンは、高性能アプリケーション環境におけるシステムリソースに必要以上の影響を与えます。

- すべてのファイルを必要時にリアルタイムでスキャンすることで最適に保護できます。ただし、この構成により、悪意のあるコード（ASCII テキストファイルなど）をサポートできないファイルをスキャンする不必要なオーバーヘッドが発生します。システムにリスクを与えないと分かっているすべてのスキャンモードのファイルまたはファイルのディレクトリを除外します。また、ソリューションで除外する特定の Contact Center Enterprise ファイルのガイドラインに従います。これに関しては、 Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド を参照してください。

- 使用時間が低い、またはアプリケーションアクティビティが最も低い際は、定期的なディスク スキャンをスケジュールします。アプリケーションの削除アクティビティをいつスケジュールするかを決定するには、 Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド を参照してください。

侵入防御

シスコには、Sygate や McAfee などのベンダーによる、侵入防止製品のテストやサポートはありません。このような製品は、そのアプリケーションをセキュリティ脅威として誤って識別した場合、正当なアプリケーション機能をブロックする可能性があります。これらの製品を慎重に構成して、正当な操作を実行できるようにします。

パッチ管理

- セキュリティパッチ

- 自動パッチ管理

セキュリティパッチ

Contact Center Enterprise 製品へののセキュリティ更新資格認定プロセスについては、http://www.cisco.com/c/en/us/products/collateral/customer-collaboration/unified-contact-center-enterprise/product_bulletin_c25-455396.html に記載されています。このプロセスは、標準規格の Windows オペレーティングシステムを実行している VM に適用されます。

更新プログラムを適用するタイミングと方法に関する Microsoft のガイドラインに従ってください。Microsoft がリリースしたすべてのセキュリティパッチを評価し、環境に適していると判断したパッチをインストールします。

自動パッチ管理

Contact Center Enterprise サーバ（VOS にインストールされているアプリケーションは除く）は、Microsoft の Windows Server Update Services との統合をサポートしています。このサービスを使用すると、更新が選択的に承認され、実稼働 VM への展開時期が決定されます。Windows Automatic Update Client（デフォルトですべての Windows ホストにインストールされる）は、デフォルトの Windows アップデート Web サイトの代わりに、Microsoft Window アップデートサービスが稼働するサーバとポーリングすることによって、アップデートを取得するように設定できます。承認されたメンテナンス期間中に更新が実行されるようスケジュールします。

構成と展開の詳細については、Microsoft のマニュアルを参照してください。

Cisco Unified Communications VOS の構成およびパッチプロセスでは、現在、自動パッチ管理プロセスは許可されません。

エンドポイント セキュリティ

- Unified IP Phone デバイスの認証

- IP Phone の強化

Unified IP Phone デバイスの認証

Contact Center Enterprise ソリューションを設計する際、Cisco Unified IP Phone 向けにデバイス認証を実装できます。Contact Center Enterprise ソリューションは、以下を保証する Unified Communications Manager の 認証済みデバイスセキュリティモードをサポートしています。

- デバイス ID — X.509 証明書を使用した相互認証

- シグナリングインテグリティ — HMAC-SHA-1 を使用して認証された SIP メッセージ

- シグナリングプライバシー — AES-128-CBC を使用して暗号化された SIP メッセージコンテンツ

IP Phone の強化

Unified CM の IP Phone デバイス構成では、特定の電話機の機能を無効にすることで電話機を強化できます。たとえば、電話機の PC ポートを無効にしたり、PC による音声 VLAN へのアクセスを制限できます。これら設定の一部を変更すると、Contact Center Enterprise ソリューションの監視機能や録音機能が無効になります。設定は次のように定義されています。

- PC 音声 VLAN アクセス — PC ポートに接続されているデバイスを音声 VLAN にアクセスさせるかどうかを電話機が許可しているかを示します。ボイス VLAN アクセスを無効にすると、接続されている PC でボイス VLAN 上のデータを送受信できなくなります。また、電話によって送受信されたデータを PC で受信することもできなくなります。この機能を無効にすると、デスクトップベースの監視と録音が無効されます。

この設定は有効（デフォルト）です。

- PC ポートへのスパン — 電話機が電話機ポートから PC ポートへ送受信されたパケットを転送するかどうかを示します。この機能を使用するには、PC 音声 VLAN アクセスを有効にします。この機能を無効にすると、デスクトップベースの監視と録音が無効されます。

この設定は有効です。

次の設定を無効にすることで、中間者攻撃（MITM）を防ぎます。一部のサードパーティ製のモニタリングおよび録音アプリケーションでは、このメカニズムを音声ストリームのキャプチャに使用します。

- 無償 ARP — 無償 ARP 応答から、電話機が MAC アドレスを学習するかどうかを示します。

この設定は無効です。

転送中の安全な PII

Contact Center Enterprise ソリューションは、内部および外部からの攻撃を受けやすい個人情報（PII）などのカスタマーの機密情報を処理します。

GED 188、GED 125、GED 145、および MR carry PII などのトランスポートチャネルは、攻撃を受けやすいです。CCE ソリューションは、TLS プロトコルを使用して、PII を転送するトランスポートチャネルを保護します。

これらのトランスポートチャネルの保護に使用される設計上の理念を次に示します。

- 自己署名証明書またはサードパーティ CA 署名付き証明書のいずれかを使用して、クライアントとサーバコンポーネント間のセキュアな通信チャネルを有効にします。

- 接続に失敗した場合、非セキュアモードにフォールバックするオプションはありません。

- VM ごとに 1 つのセキュリティ証明書を使用する。

セキュリティで保護された接続と証明書管理に関しては、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の「 Cisco Unified ICM/Contact Center Enterprise セキュリティ ガイド」を参照してください。

セキュリティで保護された接続の例

Note

セントラルコントローラと PG 間の通信チャネルは安全ではありません。エンドツーエンドのソリューションのセキュリティについては、IPSec ネットワーク分離ゾーンを使用します。

Chapter 8. 統合機能の設計上の考慮事項

- エージェント グリーティングに関する考慮事項

- アプリケーション ゲートウェイに関する考慮事項

- 業務時間に関する考慮事項

- カスタマー仮想アシスタントに関する考慮事項

- Cisco アウトバンド オプションに関する考慮事項

- サービス コールバックに関する考慮事項

- コール コンテキストに関する考慮事項

- データベース ルックアップ設計に関する考慮事項

- コーデックに関する考慮事項

- モバイル エージェントに関する考慮事項

- 内線番号のサポートに関する考慮事項

- ポスト コール調査に関する考慮事項

- Webex エクスペリエンス管理に関する考慮事項

- Webex エクスペリエンス管理デジタルチャネル調査に関する検討事項

- Customer Journey Analyzer

- Customer Journey Analyzer 向けデータセキュリティ

- プレシジョン ルーティングに関する考慮事項

- シングル サインオン（SSO）に関する考慮事項

- ウィスパー アナウンスメントに関する考慮事項

エージェント グリーティングに関する考慮事項

ソリューションにエージェント グリーティングを追加する際は、以下の点を考慮してください。

- エージェント グリーティングは、エージェントによって発信されたアウトバウンド コールをサポートしません。アナウンスメントはインバウンド コールに対してのみ再生されます。

- コールごとに 1 つのエージェント グリーティング ファイルだけが再生されます。

- スーパーバイザはエージェントによって録音されたグリーティングを聞くことはできません。

- ルータがラベル ノードを介してエージェントを選択するときに、エージェント グリーティングは再生されません。

- エージェント グリーティングは、Unified CM ベースのサイレント モニタリングをサポートしています。ただし、スーパーバイザはグリーティング自体を聞くことはできません。グリーティングの再生中にスーパーバイザがサイレント モニタリング セッションを開始すると、「グリーティングを再生中です。しばらくしてからもう一度試してください（a greeting is playing and to try again shortly）」というメッセージが表示されます。

- VXML ゲートウェイ ダイヤル ピアの VRU レッグには、G.711 a-law または mu-law を使用してください。音声クラスのコーデックは使用しないでください。

- 一般に、エージェント グリーティング機能はシステム全体において低遅延を必要とします。たとえば、エージェント グリーティング機能を設計どおりにサポートするために、パブリック ネットワークでは最大ラウンドトリップ遅延が 100 ms になります。

エージェント グリーティングには、以下が必要です。

- 電話機では、BIB 機能が提供されます。

- 電話機は、Unified Communications Manager によって提供される最新のファームウェア バージョンを実行する必要があります。

- 電話機では、Unified Communications Manager で BIB が有効になっている必要があります。

エージェント グリーティングとウィスパー アナウンスメント

エージェント グリーティングはウィスパー アナウンスメント機能と併用できます。これらを併用する場合は、以下の点を考慮してください。

- ウィスパー アナウンスメントは常に最初に再生されます。

- コールの処理時間を短縮するには、それぞれを単独で使用する場合よりも短いウィスパー アナウンスメントとエージェント グリーティングを使用します。長いウィスパー アナウンスメントの後に長いエージェント グリーティングが続く場合は、エージェントがアクティブにコールを処理するまでの待機時間が長くなります。

- ウィスパー アナウンスメントを使用すると、多くの場合、エージェントはさまざまなタイプのコールを処理することになります。例："English-Gold Member-Activate Card、""English-Gold Member-Report Lost Card、""English-Platinum Member-Account Inquiry" エージェントが録音しているグリーティングがさまざまなコール タイプに十分対応できることを確認してください。

- ローカル エージェント向けグリーティング フォンの要件

- エージェント グリーティングのコール フロー

- エージェント グリーティング 設計への影響

ローカル エージェント向けグリーティング フォンの要件

組み込みブリッジ（BIB）を備えたIP フォンを使用するエージェントおよびスーパーバイザがエージェント グリーティングを利用することができます。上記エージェントは、通常、コンタクト センター内に位置します。エージェント グリーティングで使用される電話機は、以下の要件を満たす必要があります。

- 電話機には、BIB 機能が必要です。

Note

BIBを無効にすると、システムはエージェント グリーティングのコール フローに会議ブリッジを使用しようとして、警告イベントが発生します。

- 電話機のファームウェアが最新であることを確認します。(通常、Unified CM のインストールをアップグレードすると、電話機のファームウェアは自動的にアップグレードされます)。

- Contact Center Enterprise でサポートされる電話機の一覧の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.htmlの 互換性マトリクス を参照してください。

エージェント グリーティングのコール フロー

エージェント グリーティングのコール フロー

1. 着信コールは、 CUBE または CVP の TDM ゲートウェイから受信します。

2. CVP は着信コールを Unified CCE に送信します。

3. Unified CCE は、CVP にコールのキューに入るよう指定します。

4. CVP は コールを VRU 処理のために音声ブラウザに送信します。

5. エージェントが使用可能な場合、Unified CCE は、エージェント番号を CVP に送信します。

6. CVP は、着信コールを Unified CCE に送信します。

7. Unified CM によって、エージェント電話への接続が確立されます。

8. 発信者は、エージェントの電話機に接続し、ringback の可聴応答が停止します。

9. Unified CCE が、どの CVP が呼び出されるか決定し、Unified CM に指示をして、電話機 BIB が CVP へのストリームを開くように伝えます。

10. Unified CCE また、CVP は握手して、CVP のトリガーを設定し、どのグリーティングを再生するかを知らせます。

11. CVP では、音声のブラウザに対して、Media Server がグリーティングを再生するように指示します。

12. 電話機の BIB がグリーティングを合成します。グリーティングが再生されると、CVP が切断され、エージェントが発信者と話しをします。

エージェント グリーティング 設計への影響

- エージェント グリーティングのサイジングに関する考慮事項

エージェント グリーティングのサイジングに関する考慮事項

エージェント グリーティングは、コールにグリーティングを取り込むために会議リソースを呼び出します。ほとんどの電話機では、電話機に内蔵のブリッジ機能を使用します。モバイル エージェントでは、会議リソースを使用します。これにより、すべてのコールに短い余分なコール レッグが追加されるため、いくつかのコンポーネントに影響を与えます。

音声ブラウザおよび CVP

エージェント グリーティングは CVP および音声ブラウザ リソースを使用します。エージェント グリーティングには、短いコールのプロファイルがあり、コールレートは高くなっています。使用するソリューションのサイジング時の上記コールのアカウント。

ルータおよび Logger

エージェント グリーティングは、ルータおよび Logger で最大で 1.5 の通常のコールに影響します。これにより、ソリューションの最大コールレートが 3 分の 1 にまで低減されます。各エージェント グリーティングには、追加のルート要求が含まれます。ルータの PerfMonカウンターでは、この追加の要求がより高いコールレートとして反映されます。

Peripheral Gateway

エージェント グリーティングが PG リソース使用率に与える影響によって、サポートされる各 PG のエージェント能力が低下することはありません。

Unified CM

エージェントの応答がある場合は、Unified CM のサブスクライバがサポートするエージェント数に影響を与える可能性があります。

Mobile Agent

Mobile Agent を使用してエージェントのグリーティングを有効にすると、追加の会議ブリッジおよび MTP リソースが使用されます。会議ブリッジおよび Unified CM リソースを適切にサイジングするには、エージェント グリーティングの代わりに着信コール毎に会議を追加します。

- エージェント グリーティング プロンプト キャッシュのサイジング

- コール サーバに対するエージェント グリーティングの影響

- 音声ブラウザへのエージェント グリーティングの影響

エージェント グリーティング プロンプト キャッシュのサイジング

エージェント グリーティングを有効にする場合は、プロンプト キャッシュのサイズを適切に設定します。

G.711 mu-lawコーデックの 1 分の長さのファイルに関して、以下の例を検討してください。

以下の計算は、プロンプトが約 1/2 MBを使用することを示しています。

プロンプト サイズ = 8 kb / 秒 (g711uLaw ビット レート) * 60 秒 - 480 kb

Cisco IOS ルータでは、プロンプト キャッシュの最大値は 100 MB です。各ファイルの最大サイズは 600 KB とします。

以下の表は、IOS ルータにおけるプロンプト キャッシュのサイズ変更の例を示しています。

エージェント グリーティング プロンプト キャッシュのサイジング

グリーティング継続時間

グリーティング サイズ

グリーティング合計数

5 秒

40 KB

80％ のスペースがエージェント グリーティング用に予約される 2000 件のエージェント グリーティング

60 秒

480 KB

50％ のスペースがエージェント グリーティング用に予約される 100 件のエージェント グリーティング

Note

Cisco VVB では、最大キャッシュ サイズは 512 MB であり、さらに多くのグリーティングをキャッシュすることができます。

コール サーバに対するエージェント グリーティングの影響

Contact Center Enterprise ソリューション用の CPS の最大数は、エージェント グリーティングを使用することを前提としています。この機能の影響については、CPS の制限で既に考慮されています。

エージェントのグリーティングを有効にすると、ポートの使用状況にも影響が及びます。必要なポートは、CPS およびエージェント グリーティングの期間に基づいて計算されます。

音声ブラウザへのエージェント グリーティングの影響

エージェント グリーティングを使用すると、ソリューションに必要な音声ブラウザ セッションを増やすことができます。CPS に基づいて音声ブラウザ セッションを計算する場合は、CPS とエージェント グリーティングの時間を使用します。エージェント グリーティングは、音声ブラウザに対する 1 件の追加コールとしてカウントされます。

以下の式を使用して、エージェント グリーティング機能に必要な追加セッションを含む合計セッションを決定します。

Total sessions = Inbound sessions + ((Greeting Duration / Total call duration) * Inbound sessions)

たとえば、60 秒の長さの 120 件のコールは、2 つの CPS のレートであり、120 件の受信セッションを必要とします。エージェントのグリーティングの長さが 5 秒の場合、全体のレートは 4 CPSとなります。必要なセッション数は 130 です。

Total sessions = 120 inbound sessions + [(5-second agent greeting duration / 60-second total call duration) *
120 inbound sessions] = 130 total sessions.

アプリケーション ゲートウェイに関する考慮事項

カスタム アプリケーションは、アプリケーション ゲートウェイ プロトコル仕様の GED-145に記載される仕様に準拠するように作成する必要があります。

アプリケーション ゲートウェイには、アプリケーションの設計および展開中に考慮するべきフォールト トレランス モデル用にいくつかのオプションが提供されています。

- アプリケーション ゲートウェイ コール フロー

- アプリケーション ゲートウェイの設計の影響

- アプリケーション ゲートウェイのサイジングの考慮事項

アプリケーション ゲートウェイ コール フロー

基本的な連絡先共有コール フローは、以下の図の通りに実行されます。

アプリケーション ゲートウェイ コール フロー

アプリケーション ゲートウェイの設計の影響

アプリケーション ゲートウェイのターゲット サーバは、別の仮想マシンで実行する必要があります。

アプリケーション ゲートウェイのサイジングの考慮事項

アプリケーション ゲートウェイの最大コール レートは、システムの最大コール レートに対応しています。

業務時間に関する考慮事項

管理者は、Agent Explorer ツール、アナウンス ツールなどの通常の CCE 構成ツールではなく、CCE 管理 Web インターフェイスから業務時間を容易に構成することができます。この API を使用して、パートナーはツールにこの機能を組み込むことができます。

- 業務時間ユース ケース

- 業務時間の設計への影響

業務時間ユース ケース

業務時間機能を使用して、設定した業務時間に基づいてこれらの連絡先をルーティングすることにより、チームの への着信顧客通話またはデジタル チャネルの連絡先を管理します。

スクリプト内の IF ノードで業務時間ステータスを使用し、E メールやチャットなどの通話およびデジタル チャネルの連絡先を制御して、それに応じて顧客に通知を行います。

業務時間のスクリプトでは、以下の処置を行うことができます。

- 業務が開始されている場合は、コールとデジタル連絡先を該当するスキル グループおよびプレシジョン キューに転送します。

- 業務が終了したら、該当するステータスの [終了] ステータスでメッセージを再生し、コールを終了します。デジタル連絡先を適切なキューにルーティングします。

- 業務が年中無休でない場合は、コールを複数時間のサポート用にスキル グループとプレシジョン キューにルーティングして、業務時間外メッセージを再生します。

- 365 日 24 時間の業務の場合は、各シフトの終了前にあらかじめ定義された時間で、コールとデジタル連絡先を次のシフトの適切なキューにルーティングします。

- 通常の稼働日に緊急事態で業務を終了する場合は、緊急時のクローズについてコンタクト センターに連絡する顧客に適切な通知を行います。

理由コードとステータスに基づき、顧客は通話中に適切なプロンプトを聞くことができます。

業務時間の設計への影響

Unified CCE は、次のリファレンス設計の営業時間をサポートします。

- 2000 エージェント

- 4000 エージェント

- 12000 エージェント

- 24,000 人のエージェント

カスタマー仮想アシスタントに関する考慮事項

CVA 機能を使用すると、IVR プラットフォームをクラウドベースの音声サービスと統合できます。この機能は、人のようなやりとりをサポートすることで、カスタマーが IVR 内で問題を迅速かつ効率的に解決し、実際のエージェントに向けられたコールを減らします。

- CVA の概念

- CVA コールフローとアーキテクチャ

CVA の概念

CVA アプリケーションで取り扱う概念を次に示します。これらの概念の詳細については、https://cloud.google.com/dialogflow/docs/ に記載されている Google の Dialogflow のマニュアルを参照してください。

概念

説明

音声操作

- TTS：テキスト形式のプロンプトをオーディオ形式に合成。詳細については、「https://cloud.google.com/text-to-speech/」を参照してください。

- ASR：ユーザの声を認識し、音声をテキスト変換。詳細については、https://cloud.google.com/speech-to-text/を参照してください。

コンテキスト管理

どの Dialogflow Intent パラメータを入力するかを決定し、インテントの複数のパラメータを入力するための複数のダイアログ間の相関関係を決定します。

セッション管理

IVR セッション内で、ある意図と別の意図の関係を管理します。

ビジネスロジック

どのイベントがどのイベントにフローするかなど、イベントのシーケンシャルフローを定義します。

履行

REST API、データベース操作、または顧客アクションを呼び出すという点で、ユーザの意図に対してアクションを実行します。

自然言語の理解（NLU）

発信者のスピーチをテキスト形式で処理し、発信者が口頭で発した単語を使用して意図を理解し、パラメータを特定します。

NLU 設計/トレーニング

NLU を設計し、トレーニングをします。これには、意図、エンティティ、スロットの特定、およびトレーニングデータを使用したさまざまなシナリオでの NLU エンジンのトレーニングが含まれます。

Note

CVA 機能は、VVB のみでサポートされます。VXML ゲートウェイではサポートされていません。

CVA コールフローとアーキテクチャ

- Dialogflow 要素フロー

- DialogflowIntent/DialogflowParam 要素フロー

Dialogflow 要素フロー

このコールフローは、Call Studio アプリケーションを最速最短の方法で統合します。

このコールフローでは、次のことが実行されます。

- xCVP はプラットフォームとして機能し、ブートストラップ、ライセンス、ループ、および終了ロジックを制御します。

- Dialogflow エージェントは、音声操作、コンテキスト管理、ビジネスロジック、フルフィルメント、および NLU 操作を実行します。

Architecture

1. コールサーバが SIP コールを受信したら、UCCE から IVR 処理手順を取得します。

2. コールサーバは、IVR 処理のために VVB を呼び出します。

3. VVB は、VXML サーバから VXML ページをフェッチし（Call Studio アプリケーションに基づき）、CVA/非 CVA 要素の VXML ページを作成します。

4. VVB は、TTS/ASR サービスとの対話を要求された場合、音声サーバにメディアをストリーミングします。

5. Speech サーバは Dialogflow プラグインを使用して、メディアを Dialogflow にリレーします。

6. Dialogflow フローは次の処理を行います。

- 音声をテキストに変換し、内部でテキストに変換します。

- テキストを処理し、意図を識別します。

- ウェブフックベースの API によって CRM を実行します。

- 後続のプロンプト/処理結果（Call Studio アプリケーションの AudioOutput プロパティ構成に基づく）を音声またはテキストフォーマットで VVB に返します。

出力が音声の場合、Dialogflow は API 応答で音声ペイロードを返します。VVB は、この音声を直接再生します。Call Studio でのアクションは不要です。出力がテキスト形式の場合、Dialogflow は、コールフロー内の別の Audio 要素の TTS サービスを利用して、合成する必要がある、応答でテキストプロンプトを返します。

DialogflowIntent/DialogflowParam 要素フロー

このコールフローにより、フローでより正確な制御ができます。

このコールフローでは、次のことが実行されます。

- Call Studio アプリケーションは、コンテキスト管理、セッション管理、ビジネスロジック、およびフルフィルメントを実行します。

- 別々の音声サービスが、異なる音声操作を実行します。

- Dialogflow は、すべての NLU 操作を実行します。

Note

Dialogflow で意図が作成される場合は、[必須（Required）] チェックボックスをオフにすることで、Call Studio アプリケーションで意図を制御できます。

このコールフローは、次の場合に使用できます。

- 既存の Call Studio アプリケーションでは、データベース/API との異なるカスタム統合が実装され、CVA 機能に対応するために拡張されます。

- プロンプトは、メディアサーバに動的に生成またはホストされ、Call Studio アプリケーションから制御されます。

- パラメータシーケンシングと処理は、Call Studio アプリケーションから制御されます。

Architecture

1. コールサーバが SIP コールを受信したら、UCCE から IVR 処理手順を取得します。

2. コールサーバは、IVR 処理のために VVB を呼び出します。

3. VVB は、VXML サーバから VXML ページをフェッチし（Call Studio アプリケーションに基づき）、CVA/非 CVA 要素の VXML ページを作成します。

4. Call Studio スクリプトに基づき、VVB は DTMF を収集するか、TTS/ASR サービスと対話するか決定し、メディアを Speech サーバにストリーミングします。

5. Speech サーバは ASR サービスを利用し、メディアを Dialogflow にリレーします。

1. ASR は認識されたテキストを VVB に返します。

2. VVB は認識されたテキストを VXML サーバに返します。

6. VXML サーバは Dialogflow API を呼び出し、処理をするためにユーザの口語テキストをその API に送信します。

VXML サーバは、次の 2 つの方法で Dialogflow と対話します。

- DialogflowIntent：ユーザの発話を使用して意図を特定します。

- DialogflowParam：ユーザの発話を使用して、意図に対するパラム（スロット）を入力します。

7. VXML サーバは、意図のすべてのパラメータが入力されるまでステップ 3 ～ 6 を繰り返します。その後、VXML サーバは API/カスタムコード/DB 操作を通じて意図を遂行します。

8. カスタマーにプロンプトを送信する各操作の後、VXML サーバはカスタマーに対して合成されるテキストを生成します。このテキストは、VVB および Speech サーバを介して TTS サービスに送信され、プロンプトが顧客に対して合成されます。VVB は、静的プロンプトをキャッシュして、詳細な使用方法を示します。

Note

帯域幅の検討：CVA ベースのコールフローの帯域幅の計算は、従来の DTMF ベースのコールフローとは全く異なります。そのため、CVA ベースのコールの実際の帯域幅使用量を計算するには、コール帯域幅あたり 20 kbps の消費を想定します。

CVA を使用した VVB スケール：CVA 機能付き仮想化音声ブラウザのコールキャパシティは、ASR/TTSサービスを備えた従来の IVR のすでに公開されているスケール番号にインラインのままです。

Cisco アウトバンド オプションに関する考慮事項

Unified CCE の Cisco アウトバンド オプションは、音声ゲートウェイを介してアウトバウンド コールを発信します。Outbound Option Dialer には、トーンを生成したりトーンや音声を検出するためのテレフォニー カードは必要ありません。

Cisco アウトバンド オプションには、次のプロセスが関連しています。

- キャンペーン マネージャとインポート プロセスは、キャンペーンを制御します。

- フォールト トレランスの方法に応じて、1 つのキャンペーンマネージャまたは冗長ペアを設定することができます。

- ダイヤラ プロセスは、カスタマーにダイヤルして、カスタマーを適切なスキルを持つエージェントまたは使用可能な VRU に接続します。ダイヤラは、試みたすべてのコンタクトの結果をキャンペーン マネージャに報告します。アクティブなキャンペーン マネージャがすべてのダイヤラ プロセスを管理します。ダイヤラは Agent PG と同じプラットフォーム上にインストールされます。

- アウトバウンド用のエージェントを予約するために、ダイヤラにはメディアをルーティングする周辺機器が必要です。これは、Unified CCE 展開内の他のサーバ上に共存させることができます。

- モバイル エージェントは、アウトバウンド キャンペーンの固定接続でのみサポートされます。

Note

プレシジョン ルーティングは、Cisco アウトバウンド オプションをサポートしていません。アウトバウンド キャンペーンはスキル グループを使用します。ただし、(アウトバウンド スキル グループを介して) アウトバウンド キャンペーンに関与するエージェントは、プレシジョン キューにログインして、プレシジョン ルーティングのインバウンド コールを処理することができます。

Cisco アウトバウンド オプションには次のような利点があります。

- 企業全体にわたるダイヤル接続（複数のコール センター サイトに IP ダイヤラを配置）。キャンペーン マネージャ サーバを中央サイトに配置。

- Unified CCE Administration & Data Server による一元化された管理と設定。

- インバウンド コールとアウトバウンド コールのコールバイコール混在。

- 柔軟なアウトバウンド モード制御。Unified CCE スクリプト エディタを使用して、アウトバウンド アクティビティに使用されるアウトバウンド モードのタイプおよびスキル内のエージェントの割合を制御します。

- アウトバウンド固有のレポート テンプレートとの統合レポート。

エージェントへのカスタマー コールの転送を完了に必要な時間は、テレフォニー環境に応じて異なります。次の要因は転送時間を増加させる可能性があります。

- 不適切に設定された Cisco Unified Communications インフラストラクチャ：サーバ間のポート速度の不一致、または不十分な帯域幅。

- WAN：信頼できない WAN または適切に設定されていない WAN。

- IP Communicator: デスクトップで実行されるメディア ターミネーションには、デスク フォンと同じシステム優先順位はありません。送信オプションには、IP Communicator の代わりにデスクフォンを使用します。

- コール進行状態分析：コール進行状態分析（CPA）は、音声品質が良好な場合には、音声と留守番電話を区別するのに 0.5秒 かかります。携帯電話への尊信の際は、多くの場合、音声品質が最適ではなく、そのため、ダイヤラまたは音声ゲートウェイで区別が行われる際にさらに少し時間がかかる可能性があります。

仮想 CUBE を CPA と共に使用することはできません。

- アウトバウンド オプション ダイヤリング モード

- Cisco アウトバウンド オプション コール フロー

- Cisco アウトバウンド オプション設計の影響

- アウトバウンド オプションの帯域幅、遅延、および QoS に関する考慮事項

アウトバウンド オプション ダイヤリング モード

アウトバウンド オプションには、いくつかのダイヤル モードがあります。

Note

すべてのダイヤル モードは、エージェントに予約コールを送信することにより、すべてのアウトバウンド コール サイクルの開始時にエージェントを予約します。

プレディクティブ ダイヤリング

予測ダイヤルの場合、ダイヤラは、放棄レートに基づいて、エージェント毎にダイヤルする顧客の数を決定します。エージェントがキャンペーン スキル グループにログインしている場合は、エージェントがそのコールを取得する必要があります。

予測ダイヤラは、コンタクト センターの IVR ポート使用率を向上させる設計となっています。エージェント毎に複数の顧客がダイヤルされます。連絡先に電話が接続されると、予測ダイヤラは、顧客を応答可能なエージェントに転送し、エージェントのデスクでポップアップ画面が表示されます。予測ダイヤラは、ターゲットの放棄率に基づき、使用可能なエージェント毎にダイヤルする回線数を決定します。

アウトバウンド オプションの予測ダイヤルは、放棄率が最大許容放棄率を下回るレベルでアウトバウンド ダイヤルを維持することにより機能します。たとえば、各キャンペーンには最大許容放棄率が設定されています。予測モードでは、ダイヤラは、放棄率が事前に構成された最大放棄率に近づくまで、エージェント毎にダイヤルする回線の数を連続的に増やします。ダイヤラは、放棄率が事前に設定された最大値を下回るまで、エージェント毎の回線数の減少を開始します。この方法で、ダイヤラは事前設定された最大放棄率をわずかに下回る状態を維持します。理想的な条件下では、ダイヤラは、設定済みの最大放棄率の 85 % を内部的な目標とします。アウトバウンド ダイヤリングのランダム性により、ある時点での実際に達成可能な放棄レートは、ダイヤラのものと異なることがあります。

プレビュー ダイヤリング

プレビュー ダイヤルは、アウトバウンド コールを開始する前にエージェントを予約し、エージェントにポップアップ ウィンドウを表示します。エージェントは、以下の結果を使用して、コールの受け入れ、スキップ、または拒否を行うことができます。

- 受け入れ: 顧客にダイヤルし、エージェントに転送します。

- スキップ : エージェントに別のカスタマー コールが提供されます。

- スキップして終了 : 顧客は再度呼び出されることはなく、エージェントに別の顧客のコールが表示されます。

- 拒否 : エージェントはリリースされます。システムは別のコール (別のプレビュー アウトバウンド コール、または新しいインバウンド コール) をエージェントに配信します。

- 拒否:エージェントはリリースされ、レコードはクローズされるため、再度呼び出されることはありません。システムは別のコール (別のプレビュー アウトバウンド コール、または新しいインバウンド コール) をエージェントに配信します。

ダイレクト プレビュー ダイヤリング

ダイレクト プレビュー モードはプレビュー モードと似ています。エージェントが承諾した後にダイヤラがエージェントの電話から自動的に呼び出す点が異なります。このコールはエージェントの電話機から開始されるため、エージェントが呼び出しを待機し、顧客が応答しても遅延は発生しません。ただし、エージェントは応答マシンおよびその他の結果を処理する必要があります。その他のモードでは、ダイヤラ コール進行状況分析 (CPA) が処理されます。

Note

- ダイレクト プレビュー ダイヤリング モードを使用している場合、CPA および IVR 機能に転送することはできません

- Zip トーンは、着信コールを通知するトーンです。ダイレクト プレビュー モードには Zip トーンはありません

プログレッシブ ダイヤリング

プログレッシブ ダイヤリングは、予測ダイヤルに似ています。ただし、プログレッシブ ダイヤル モードでは、アウトバウンド オプションは、各エージェントにダイヤルする回線数を計算しません。固定数の回線を設定して、常に利用可能なエージェント毎にダイヤルするようにすることができます。

パーソナル コールバック モード

呼び出された人が後でコールバックするように要求した場合、エージェントはコールバックが同じエージェントが担当するように指定することができます。次に、システムが、要求されたエージェントと顧客の間で交わされたに確立された予定時間に顧客にコールバックします。

Cisco アウトバウンド オプション コール フロー

エージェント モードのコール フロー

以下の図は、SIP ダイヤラを含むアウトバウンド オプション導入のエージェント コール フローへの転送を示しています。

SIP ダイヤラ エージェントのキャンペーン コール フロー

以下のステップで、このコール フローを説明します。

1. インポートがスケジュールされ、キャンペーンが開始されます。この記録がダイヤラに配信されます。

2. ダイヤラは、メディア ルーティング インターフェイスを介して応答可能なエージェントを検索します。

3. メディア ルーティング周辺機器ゲートウェイ (MR PG) がルータに要求を転送します。

4. ルーティング スクリプトがエージェントを識別して、MR PG に応答します。

5. メディア ルーティング  PIM が、エージェントが応答可能であることをダイヤラに通知します。

6. ダイヤラは、ゲートウェイに対して顧客を呼び出すように通知します。

7. ゲートウェイが顧客にコールを発信し、ダイヤラにコールが発信されたことが通知されます。

8. コールの進行状況の分析 (CPA) は、ゲートウェイで実行されます。

9. 音声が検出されると、ダイヤラは通知を受け取ります。

10. ダイヤラは、SIP REFERを使用して音声ゲートウェイに、エージェントの内線番号によって予約されたエージェントにコールを転送するように要求します。

11. ゲートウェイは、Unified CM を介してエージェントにコールを転送します（ダイヤル ピア設定を使用して、Unified CM を検出します）。

12. メディアはゲートウェイとエージェントの電話機の間で設定します。

VRU キャンペーンのコール フロー図

以下の図は、SIP ダイヤラを使用したアウトバウンド オプション展開での VRU への転送コール フローを示しています。

SIP ダイヤラの無人 VRU キャンペーン コール フロー

以下のステップで、このコール フローを説明します。

1. 無人 VRU キャンペーンが開始され、インポートがスケジュールされます。顧客のレコードがダイヤラに送信されます。

2. ダイヤラは、音声ゲートウェイに SIP INVITE を送信して、顧客のコールを開始します。

3. ゲートウェイが、カスタマー コールを実行します。

4. 音声ゲートウェイが、コール進行状況の分析 (CPA) を呼び出し、留守番電話 (AMD) を検出します。ダイヤラに通知されます。

5. ダイヤラは、MR PG に VRU ルート要求を送信します。

6. MR PG がルート要求をルータに転送し、ルーティング スクリプトが呼び出されます。

7. ルータは、ネットワーク VRU ラベルを使用して、ルートの応答を MR PG に送信します。

8. MR 画面によって、ルート応答がダイヤラに転送されます。

9. ダイヤラは、該当ラベル向けの SIP REFER 要求を音声ゲートウェイに送信します。

10. 音声ゲートウェイが、このコールを Unified CVP に転送します。CVPはコールを制御して、Unified CCE とハンドシェイクし、コールコンテキストを取得して、音声ブラウザを呼び出します。

11. メディアは、CUBE または TDM-IP ゲートウェイと音声ブラウザの間に設定します。

Cisco アウトバウンド オプション設計の影響

以下の要件に従って、Cisco アウトバウンド オプションを実装します。

- エージェント ベースのキャンペーンで VRU への破棄を設定します。テレマーケティング法では、こういった行為が必要になる場合があります。

- キャンペーン マネージャは Logger と同じシステム上で実行されているため、連絡先リストの大規模なインポートおよび着信拒否リストのスケジュールは業務時間外にスケジュールします。

- Cisco アウトバウンド オプション用に設定されたエージェントにCisco IP Communicator ソフト フォンは使用させないでください。IP Communicator は、エージェントへの顧客のコールの転送に不要の遅延をもたらす可能性があります。

- IPv6 クライアントは、アウトバウンド オプションにインポートすることはできません。

- Finesse IP フォン エージェント (IPPA) は、Cisco アウトバウンド オプションをサポートしていません。

- 冗長キャンペーンマネージャ、アウトバウンド オプションインポーター、およびデータベースを使用すると、データベースのサイズが大きくなります。

- 受信不可レコードには、より多くのスペースが必要になります。比較のために、6 千万 DNC レコードには、約 1 GB のディスク容量が必要です。

- SIP ダイアラ 設計の留意事項

- アウトバウンド オプションの導入

- アウトバウンド オプションのサイジング

- SIP ダイヤラのスロットリング

- SIP ダイヤラの録音

SIP ダイアラ 設計の留意事項

Cisco アウトバウンド オプションを使用すると、エージェントはアウトバウンド キャンペーンに参加し、SIP ソフトウェア ダイヤラを介してインバウンド コールを受けることができます。

SIP ダイヤラを実装するには、以下の要件に従います。

- PSTN に対する T1 PRI、E1 PRI、および CUBE インターフェイスは、アウトバウンドオプション SIP ダイヤラをサポートしています。BRI、FXO、E1R2 は、ダイヤラとは機能しません。

- Cisco Finesse では、プログレッシブ、予測、プレビュー、およびダイレクト プレビュー モードがサポートされています。

- 冗長 SIP ダイヤラについては、各冗長 MR PG のメディア ルーティング PIM を使用します。片方の SIP ダイヤラはがアクティブで、別の SIP ダイヤラはウォーム スタンバイ モードとなります。各 SIP ダイヤラに対して 1 つの MR PIM を配置します。冗長 MR PG 環境では、ダイヤラがアクティブになったときに各 PG 側にローカル ダイヤラに接続する PIM が 1 つだけあります。

- キャンペーン設定により SIP ダイヤラの録音が有効になっている場合は、G.711 コーデックをゲートウェイのダイヤラ ピア設定で使用します。

- SIP ダイヤラのコール スロットルを有効にして、音声ゲートウェイが過負荷にならないようにします。

- 音声ゲートウェイのダイヤル ピアと CUSP ルーティング ポリシーは、SIP ダイヤラがアウトバウンド コールを配置するために使用されます。これにより、展開されたゲートウェイを使用してコールを配置することが可能になり、フリー ダイヤル レートとローカル コール レートが低減します。

- ネットワーク DSP リソースの使用量を削減し、メディア転送を改善するために、送信元のゲートウェイに CVP を設定します。これは、SIP ダイヤラと CVP が、VRU 処置にアウトバウンド コールを配置する音声ブラウザを共有している場合に重要です。

- アウトバウンド オプション ダイヤラは、IPv4 を使用して発信します。IPv6 NAT を音声ゲートウェイで使用して、IPv6 へのコールを変換します。

- SIP ダイヤラは A-law コーデックをアドバタイズしませんが、CUBE を使用する SIP ダイヤラは A-law をサポートします（ただし、設計上の特定の考慮事項があります）。この展開では、SIP ダイヤラと SIP サービス プロバイダー間の最初のネゴシエーション（メディアなし）で CUBE の DSP リソースを使用します。ダイヤラからエージェントへの REFER を実行中に、CUBE はエージェントのエンドポイントとコーデックを再ネゴシエイトして、A-law を使用します。次に、 CUBE は、Transcoder を解放します。

Note

この CUBE は、CPA が有効になっているかどうかにかかわらず、発信する各ダイヤラ コールに対して DSP を割り当てます。

アウトバウンド オプションの導入

SIP ダイヤラは、コール プロセス リソースをオフロードして、コール進行状況の分析をゲートウェイに提供することによって、高いスケーラビリティを提供します。さらに、SIP ダイヤラには、Unified CM またはゲートウェイ間の距離要件はありません。

MR PG を使用して、SIP ダイヤラを VM に展開することができます。複数の冗長 MR PG およびエージェント PG が必要です。仮想化 Wikiで指定されているソリューションの最小要件を満たす VM で、アウトバウンド オプションを実行します。

冗長エージェント PG では、冗長 SIP ダイヤラのみがサポートされています。片方のダイヤラがアクティブになっていて、別のダイヤラはウォーム スタンバイ モードとなります。冗長化された SIP ダイヤラ インストールでは、各 SIP ダイヤラが同じ MR PG (サイド A またはサイド B) 上の MR PIM に接続します。

- SIP ダイヤラ単一ゲートウェイ展開

- 複数のゲートウェイを導入した SIP ダイヤラ

- アウトバウンド オプションおよび WAN クラスタリング

- アウトバウンド オプションの分散型展開

SIP ダイヤラ単一ゲートウェイ展開

この図は、単一のゲートウェイを使用した冗長 SIP ダイヤラのインストールを示しています。予備の PG のサイド A とサイド B に、ダイヤラが設置されていることが示されています。ポート容量は、導入されている Cisco 音声ゲートウェイのタイプによって異なります。この導入モデルは、スケーリングと高可用性が要因ではない場合に使用されます。

SIP ダイヤラのシングル ゲートウェイ展開

Note

この図には、オプションの冗長キャンペーン マネージャは表示されていません。

SIP ダイヤラ アーキテクチャでサポートされる SIP ダイヤラは 1 つのみです。SIP ダイヤラは 1 つのみを設定します。2 台のダイヤラを別々の PG プラットフォームに展開しますが、同じダイヤラ名を使用しています。

Unified CCE の展開の場合、SIP ダイヤラとメディア ルーティング PG プロセスは、エージェント PG とは別の VM 上または同じ VM 上で実行することができます。冗長 SIP ダイヤラとエージェント PG の展開の場合、各 MR 画面には、共存する SIP ダイヤラに接続する 単一の MR PIM が配備されています。

SIP ダイヤラは、ダイヤラ設定ダイアログの SIP サーバ タイプ が 音声ゲートウェイ に設定されている場合、ローカルの静的ルート ファイルを使用してアウトプット コールを発信および転送します。上記のアウトバウンド コールは、CVP またはアウトバウンド エージェントに転送されます。SIP ダイヤラでは、単一のゲートウェイの展開にローカルの静的ルート ファイルを使用します。

SIP ダイヤラは、ダイヤラ設定ダイアログの SIP サーバ タイプ が CUSP サーバ に設定されている場合、Unified SIP プロキシ サーバを使用してアウトプット コールを発信および転送します。上記コールは、CVP またはアウトバウンド エージェントに発信または転送されます。

Note

コーデック設定 (G.729 または G.711) は、ポート容量とゲートウェイの CPU 使用率に影響を及ぼします。G.729 を設定するには、ゲートウェイ用の DSP および CPU リソースが追加で必要となります。

複数のゲートウェイを導入した SIP ダイヤラ

以下の図は、Unified SIP プロキシと 8 つの音声ゲートウェイの導入モデルを示しています。アクティブなダイヤラが Unified SIP プロキシ サーバを指しています。プロキシは、ロード バランシングとフェールオーバーを処理します。SIP ダイヤラは、 Cisco 1841 サービス統合型ルータ上の Unified SIP プロキシをサポートしています。

SIP ダイヤラ用の複数ゲートウェイの導入

Note

この図には、オプションの冗長キャンペーン マネージャは表示されていません。

複数ゲートウェイの展開では、SIP ダイヤラはゲートウェイを識別するために、Unified SIP プロキシ サーバ上のサーバ グループおよびルート テーブルの構成を必要とします。また、ゲートウェイが顧客の通話をダイヤラの CVP またはエージェントに転送できる番号も必要です。複数ゲートウェイの導入には、ダイヤラ設定ダイアログの SIP サーバ タイプ オプション ボタンを SIP プロキシ に設定します。

アウトバウンド オプションおよび WAN クラスタリング

WAN を介した Unified CCE のクラスタリングの展開モデルでは、WAN のもう一方の端に冗長コンポーネントを展開することにより、高可用性を改善することができます。「シングル キャンペーン マネージャ、インポータ、およびデータベース」の高可用性モデルは、WAN を介したクラスタリングのモデルとは異なります。WAN を介してクラスタリングを使用してアウトバウンド オプションを展開する場合、冗長なアウトバウンド オプション コンポーネントによってのみメリットが得られることに注意してください。

アウトバウンド オプションの分散型展開

分散展開モデルには、中央集中型 CCE システムと Unified Communications Manager クラスタが 1 つのサイトに配置されており、このサイトの Logger にインストールされたキャンペーン マネージャー、ダイヤラ、PG、 Cisco アウトバウンド オプションを備えた2番目のクラスタが配備されています。

SIP ダイヤラの導入では、各 PG 側の 1 つの SIP ダイヤラに対して Unified SIP プロキシ サーバがインストールされています。また、サイド A またはサイド B ダイヤラは、それぞれの Unified SIP プロキシ サーバからの同じ音声ゲートウェイのセットをターゲットとしています。複数の音声ゲートウェイを顧客の電話にローカルにインストールするか、各音声ゲートウェイをエリアにローカルにインストールして、専用回線または IP MPLS WAN 回線が利用可能な場合に料金が発生しないようにすることができます。

キャンペーン マネージャは WAN を介してダイヤラのレコードを送信し、ダイヤラはローカルの顧客にコールを配置します。また、2 つ目のサイトは着信エージェントもサポートします。

顧客環境では、以下の帯域のオプションをインドと米国の間で使用することができます。

1. 地上 P2P は 2 Mbps 専用回線

2. 地上 P2P DS3 (44 Mbps) 専用回線

3. IP MPLS WAN 回路。サービス プロバイダーは、顧客のニーズに応じてさまざまな速度を提供しています。通常、44 Mbps が使用されます。

4. サービス プロバイダーは、PRI (E1) トランクをインドに渡します。WAN クラウドは、通常、サービス プロバイダーによって SIP に作成されます。サービス プロバイダーは、米国のイングレスおよびエグレス ポイントで TDM を IP に変換して、IP をインドの TDM に変換します。

上記のオプションでは、1 と 2 が最も一般的です。アウトーソーシングを採用する場合は、MPLS クラウドが複数の顧客に接続することができるため、オプション 3 は一般に普及し始めています。たとえば、以下のセクションの図は、さまざまなエージェント ベースのキャンペーンまたは VRU キャンペーンへの転送のために、アウトバウンド コンタクト センターのシステムが米国およびインドの複数のサイトに展開されていることを示しています。顧客は 1 つの国に位置するとします。たとえば、米国です。

- エージェント ベース キャンペーンの分散型展開

エージェント ベース キャンペーンの分散型展開

この図は、エージェント ベースのキャンペーンの分散配置の例を示しています。

エージェントベースのキャンペーンの分散導入例

この分散展開のエージェント ベースのキャンペーンの例は以下の通りです。

- 音声ゲートウェイとルータおよび Logger A サーバは、米国の 2 ヵ所のサイト（サイト 1 とサイト 3）に分散されています。

- Unified Communications Manager クラスタは、サイト 2 のインドのエージェント PG と共に配置されています。

- 冗長化 MRPG/ダイヤラおよび冗長エージェント PG は、インドのサイト 2 で同じ VM 上にインストールされます。

- サイト 2 の SIP ダイヤラは、米国のサイト 3 に配置されている音声ゲートウェイを使用します。

- 音声ゲートウェイは、米国のサイト 3 で CT3 インターフェイスを含む図に含まれています。ルータは、ダイヤラ コールに 1:1 の冗長性を提供します。

- Unified SIP プロキシ サーバは、サイト 2 でローカルに冗長化され、ライブ アウトバウンド コールを転送するために WAN SIP シグナリング トラフィックを回避します。

- 各 SIP ダイヤラは、サイト 2 で独自の統合 SIP プロキシ サーバに接続します。

- 各 Unified SIP プロキシ サーバは、米国のサイト 3 で音声ゲートウェイのセットを制御します。

- 各統一 SIP プロキシ サーバは、米国のサイト 3 で音声ゲートウェイのセットを制御します。

SIP ダイヤラで録音が有効になっている場合、帯域幅要件は以下の通りです。

- 応答したアウトバウンド コールには、エージェント コール毎に以下の帯域幅が必要です。

- G.711 コーデックのコールには、80 kbps の WAN 帯域幅が必要です。

- G.729 コーデックのコールには、26 kbps の WAN 帯域幅が必要です

- アウトバウンド コールの警告通知では、エージェント コール毎に以下の帯域幅が必要です。

- G.711 コーデックのコールには、80 kbps の WAN 帯域幅が必要です。

- G.729 コーデックのコールには、26 kbps の WAN 帯域幅が必要です

アウトバウンド オプションのサイジング

Cisco アウトバウンド オプションでは、エージェントが着信およびアウトバウンド コールを処理することができる完全ブレンド キャンペーンを実行します。

Note

サイジングに影響を与えるその他の制限については、設定制限および機能の可用性に関する章を参照してください。

導入のサイジングを行う際は、PG 上の最大のアウトバウンド エージェントを使用せず、予想されるヒット率、1 人のエージェントへのダイヤル回線数、および平均処理時間も使用しません。

SIP ダイヤラは、1 つの PG につき 1 つの PIM の 1000 アウトバウンド エージェントをサポートします。モバイル エージェントを導入する場合、サポートされるエージェントの数は低下します。この人数のエージェントをサポートするには、アウトバウンド ダイヤルに対して、少なくとも 5 台の専用のハイエンド ゲートウェイである展開にしなければなりません。

SIP ダイヤラは、毎秒 3000 ポート、60 コール (CPS) をサポートすることができます。

コール試行毎に平均 30 秒と仮定すると、各ポートは 1 分間に 2 コールをダイヤルできるため、ダイヤラは 1 秒あたり 1 コールを 30 ポートで処理することができます。使用中のすべてのポートを取得する時間が、ポートのビジー時間の平均値を超える場合は、一部のポートが常にアイドル状態になっています。

ダイヤラ ポートの計算

目標のコール レートを達成するために必要なダイヤラ ポートの数を計算するには、以下の数式を使用します。

Number of Ports = [target call rate * average call duration * (1 + hit rate %)]

以下の表に、アウトバウンド コール レート目標を達成するために必要なポートを示します。これらの数字は、アウトバウンド コールで平均 30 秒、ヒット レート 20% を想定しています。

アウトバウンドコールの目標レートを達成するために必要なポート

目標アウトバウンド コール / 秒

必要なポート インデックス数

10

360

20

720

30

1080

音声ゲートウェイに関する考慮事項

最も強力な音声ゲートウェイは、最も好ましくない条件下であっても毎秒 約 12 件のコールをサポートします。5 台のゲートウェイでは、均等に分散した場合、毎秒最大 60 コールの集約スパイクをサポートすることができます。ただし、転送後に、ポートがエージェントまたは VRU コールに関連付けられている場合は、配布されることはありません。したがって、50% 転送レートを想定して控えめな見積もりを採用する場合、最大 6 0コール / 秒のスパイクをサポートするには、8 つの音声ゲートウェイが必要となります。

SIP ダイヤラでサポートされる音声ゲートウェイのモデルとリリースの最新情報については、使用しているソリューションの 互換性マトリクス を参照してください。

ゲートウェイのサイズ設定に関する考慮事項については、公開されている『Cisco ゲートウェイのパフォーマンス データ』を参照してください。

エージェント PG に関する考慮事項

Unified Communications Manager の PIM は、毎秒 最大 15 コールをサポートすることができます。

キャンペーンの音声のヒット レートが 15% の場合、PG では毎秒 100 コールのダイヤルを維持することができます。

Unified CM に関する考慮事項

Unified CM サブスクライバは、毎秒一定のアウトバウンド コールレートをサポートします。エージェント PG でより多くの CPS をサポートするには、Unified SIP プロキシ サーバを使用して、複数のサブスクライバ間でダイヤラを分散配置します。

CUSP に関する考慮事項

アウトバウンド コールがエージェントまたは VRU に転送された場合、通常のアウトバウンド コールには 2 つのトランザクションが必要です。コールがエージェントまたは VRU に転送されない場合、通常のアウトバウンド コールには 1 つのトランザクションが必要です。

CVP に関する考慮事項

コールは、変換ルートを使用して、Unified CVP に配布することができます。すべての Unified CVP 間の負荷分散は、ルーティング スクリプトで行われます。

Unified CVP を使用したアウトバウンド コール シナリオには4つの SIP プロキシ トランザクションが必要であるため、大規模な展開では Unified CVP に独自の Unified SIP プロキシ サーバを配置します。

モバイル エージェントに関する考慮事項

SIP ダイヤラでは、各エージェントの PG につき 500 の Unified Mobile エージェントがサポートされています。SIP ダイヤラ ソリューションでは、アウトバウンド コールは、着信コールと同様に、Unified Communications Manager にも同じ影響を与えます。着信エージェントとアウトバウンドエージェントの数については、2:1 の比率を維持します。SIP ダイヤラ ソリューションは、エージェント PG 毎に標準の送信エージェント 1000 をサポートしているため、SIP ダイヤラは、エージェント PG 毎に 500 アウトバウンド モバイル エージェントをサポートします。

Related Information

リファレンス設計の設定制限および機能の可用性

SIP ダイヤラのスロットリング

1 台または複数のゲートウェイの導入では、いずれかのゲートウェイが過負荷になると、SIP ダイヤラがアラームを発します。自動スロットル機能を有効にすると、ダイヤラは、過負荷のゲートウェイのダイヤル レートを、顧客に対する 5000 回の試行毎に設定されたポート スロットル値の 10％ まで、50％ の修正が完了するまで自動的に調整します。修正分の 50％ とは、SIP ダイヤラが設定されたポート スロットル値の 50% に到達すると、自動調整を停止することを意味します。

Note

自動スロットルのメカニズムはデフォルトで無効となっています。過負荷になっているゲートウェイを自動的にスロットルするには、レジストリキー EnableThrottleDownの値を 1 に設定して、自動スロットルのメカニズムを有効にします。

スロットル機能が無効になっている場合でも、ゲートウェイが過負荷になると、SIP ダイヤラは常にアラームを発します。

ダイヤラの設定で、ポート スロットル フィールドを使用して SIP ダイヤラの制限を制御することができます。ポート スロットルは、1 秒あたりにスロットルするポートの数を示します。値を [ポート スロットル = 5] に設定すると、SIP ダイヤラは、毎秒 5 回のコール レートでアウトバウンド コールをダイヤルします。

SIP ダイヤラが音声ゲートウェイに直接接続している展開の場合、ダイヤラのポート スロットルをゲートウェイ サイジング テーブルに記載されている最大ダイヤラ コールのセットアップ レートに従って制限します。

SIP ダイヤラが導入環境内の CUSP 経由で接続している場合、ダイヤラのポート スロットル設定は、この前提の下でゲートウェイの許容量の合計を超えることはできません。コールは、CUSP によって負荷分散され、各ゲートウェイは最大利用可能容量まで稼働します。CUSP の最大トランザクション数でポート スロットルを制限します。現時点では、ダイヤラの最大スロットル設定は、毎秒 60 コールに設定されています。通常の転送レートでは、CUSP がアウトバウンド展開でのみ使用されるため、CUSP を介したコールは最大 CUSPトランザクションレートを超過しません。

Cisco 2800シリーズのサービス統合型ルータのポート スロットル値は 5 に設定し、Cisco 3800シリーズの統合サービスルータのポート スロットル値は 15 に設定し、Cisco アクセス サーバおよび汎用ゲートウェイのポート スロットル値は 20 に設定します。

単一ゲートウェイ展開

ゲートウェイがアウトバウンド キャンペーン専用である場合、以下の数式を使用してポート スロットルを計算します。

Port Throttle = (Value for Gateway)

アウトバウンド キャンペーンのゲートウェイが複数の SIP ダイヤラで共有されている場合、以下の数式を使用してポート スロットルを計算します。

Port Throttle = (Value for Gateway) / (Number of SIP Dialers)

ゲートウェイがインバウンドおよびアウトバウンド コールの複数のコンポーネント（Unified CM、Unified CVP、SIP ダイヤラ）で共有されている場合、以下の数式を使用してポート スロットルを計算します。

Port Throttle = (Value for Gateway) * (Percentage of outbound calls) * (1 – Hit Rate)

複数ゲートウェイ展開

ゲートウェイがアウトバウンド キャンペーン専用である場合、以下の数式を使用してポート スロットルを計算します。

Port Throttle = Total Values for Gateways

アウトバウンド キャンペーンのゲートウェイが複数の SIP ダイヤラで共有されている場合、以下の数式を使用してポート スロットルを計算します。

Port Throttle = (Total Values for Gateways) / (Number of SIP Dialers)

ゲートウェイがインバウンドおよびアウトバウンド コールの複数のコンポーネント（Unified CM、Unified CVP、SIP ダイヤラ）で共有されている場合、以下の数式を使用してポート スロットルを計算します。

Port Throttle = (Total Values for Gateways) * (Percentage of outbound calls) * (1 – Hit Rate)

SIPダイヤラ プロセスのスロットル メカニズムは、Unified SIP プロキシ サーバがアウトバウンド コールの発信に選択するゲートウェイを認識しません。負荷分散のために、Unified SIP プロキシ サーバのサーバ グループ設定の各ゲートウェイの適切な負荷を計算します。

Weight = (Value for Gateway) / (Port Throttle) * 100

たとえば、Cisco 3800 シリーズのゲートウェイ（192.168.10.3）とCisco 2800 シリーズのゲートウェイ（192.168.10.4）が複数のゲートウェイ展開で使用されていると仮定します。以下の構成では、cucm.example.com サーバ グループの 3800 シリーズのゲートウェイが 75 ％ のトラフィックを受信し、2800 シリーズのゲートウェイが 25 ％ を受信します。

netmod(cusp-config)> server-group sip group cucm.example.com enterprise
netmod(cusp-config-sg)> element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 75
netmod(cusp-config-sg)> element ip-address 192.168.10.4 5060 tls q-value 1.0 weight 25
netmod(cusp-config-sg)> lbtype weight
netmod(cusp-config-sg)> end server-group

SIP ダイヤラの録音

SIP ダイヤラは、CPA のトラブルシューティングに使用するサードパーティ アプリケーション（「Media Termination」）によるコール進行状況分析の記録（「録音」）または有効化を行うことができます。会話全体が録音されることはありません。

通常、SIP ダイヤラと音声ゲートウェイ間にはメディア ストリームはありません。ただし、キャンペーン設定で録音またはメディアの終了を有効にすると、SIP ダイヤラは、音声ゲートウェイにメディア ストリームを SIP ダイヤラに送信するように要求します。メディア ストリームは、音声ゲートウェイのダイヤル ピア設定に応じて、G.711 または G.729 コーデックとなります。SIP ダイヤラは G.711 コーデックでのみメディア ストリームを記録できます。SIP ダイヤラは G.711 コーデックと G.729 コーデックの両方のメディア ストリームを受信して、3 番目の録音サーバが発信コールの SPAN ベースの録音を実行できるようにします。

キャンペーン設定で "録音" が有効になっている場合、SIP ダイヤラは、メディア ストリームを受信して、G. 711 コーデックの RTP パケットをデコードし、録音ファイルに書き込みます。メディア ストリームが G.729 コーデックの場合、SIP ダイヤラはアラームを送信します。SIP ダイヤラは、CPU リソースとディスク I / O の制限により、ダイヤラ サーバ毎に最大 100 の録音セッションをサポートできることがテストで証明されています。

キャンペーン設定で "メディア ターミネーション" が有効になっている場合、SIP ダイヤラはメディア ストリームのみを受信して、サードパーティの録音サーバが SPAN ベースの録音を実行できるようにします。

プロセス毎のスレッド リソース制限のため、メディア ターミネーション セッションには制限があります。SIP ダイヤラでは、メディア ストリームをリッスンするスレッドを作成することができます。メディア ターミネーションのセッションの現在の制限は、200 です。

SIP ダイヤラは、以下のレジストリ キーを使用して、ユーザが録音セッションとディスク スペースを管理できるようにします。

SIP ダイヤラのレジストリ キー

名前

データ タイプ

説明

デフォルト値

MaxRecordingSessions

DWORD

キャンペーン設定で録音が有効になっている場合は、SIP ダイヤラあたりの最大録音セッションを示します。

100

MaxMediaTerminationSessions

DWORD

キャンペーン設定で録音が有効になっている場合は、SIP ダイヤラ毎のメディア ターミネーションのセッションの最大数。

200

MaxAllRecordFiles

DWORD

SIP ダイヤラ毎の録音ファイルの最大サイズ (バイト数) 。

500,000,000

MaxPurgeRecordFiles

DWORD

合計録音ファイル サイズの MaxAllRecordFiles に達した際に SIP ダイヤラが削除する最大録音ファイル サイズ（バイト数）。

100,000,000

アウトバウンド オプションの帯域幅、遅延、および QoS に関する考慮事項

多くのアウトバウンド オプション展開では、すべてのコンポーネントが集中化されているため、考慮すべき WAN ネットワーク トラフィックはありません。

アウトバウンド コール センターが 1 つの国（たとえばインド）にあり、顧客が別の国（たとえば米国）にある場合、以下の条件で WAN ネットワーク構造を検討すべき展開もあります。

- 分散型アウトバウンド オプション展開で、WAN によって音声ゲートウェイがアウトバウンド オプション ダイヤラ サーバから分離されている場合。

- VRU キャンペーンへの転送に Unified CVP 展開を使用して、Unified CVP サーバが WAN によってアウトバウンド オプション ダイヤラ サーバから分離されている場合。WAN トラフィックを減少するため、独自の Cisco Unified SIP プロキシ サーバをローカル クラスタに含む Unified CVP を提供します。

- VRU キャンペーンへの転送用に SIP ダイヤラ ソリューションを展開する場合、SIP ダイヤラ向け Cisco Unified SIP プロキシ サーバは WAN によってアウトバウンド オプション ダイヤラ サーバから分離されます。

- サードパーティの録音サーバが WAN でアウトバウンド オプションダイヤラ サーバから分離されている場合は、録音サーバを音声ゲートウェイに対してローカルに設定します。

アウトバウンド オプション展開を適切に行うには、適切な帯域幅プロビジョニングを行うことが重要です。

重複するキャンペーンマネージャ、アウトバウンド オプションインポーター、およびデータベースの影響

上記冗長コンポーネントを使用する場合は、以下の点を考慮します。

- WAN ネットワーク トラフィックが増大する可能性がある展開もあります。

- メッセージングおよび録音複製により、サイド A とサイド B の間で使用される帯域幅が増加します。

- SIP ダイヤラ分散型展開

SIP ダイヤラ分散型展開

SIP はテキストベースのプロトコルであるため、使用されるパケットはいくつかのプロトコルよりも多くなります。一般的な SIP アウトバウンド コール フローでは、アウトバウンド エージェントに転送されるコールごとに平均 12,500 バイトを使用します。平均ヒット コール シグナリング帯域幅使用率は以下の通りです。

ヒット コールのシグナリング帯域幅 = (12,500 バイト / コール) (8 ビット / バイト) = コール毎 100,000 Kb

典型的な SIP アウトバウンド コール フローでは、アウトバウンド ダイヤラによって切断されるコール毎に約 6,200 バイトを使用します。上記アウトバウンド コールは、ビジー、無応答、番号が無効などが原因である可能性があります。平均非ヒット コール シグナリング帯域幅使用率は以下の通りです。

非ヒット シグナリング帯域幅 = (6,200 バイト/コール) (8 ビット/バイト) = 49,600 ビット/コール = 49.6 Kb (コールあたり)

コーデック帯域幅 = G.711 コーデックの場合、コールあたり 80 Kbps、G.729 コーデックの場合、コールあたり 26 Kbps

- エージェント ベースのキャンペーン: SIP ダイヤラ録音なし

- エージェント ベースのキャンペーン: SIP ダイヤラ録音あり

- VRU への転送キャンペーン: SIP ダイヤラ録音なし

- VRU への転送キャンペーン: SIP ダイヤラ録音あり

エージェント ベースのキャンペーン: SIP ダイヤラ録音なし

この図は、エージェント ベースのキャンペーンの分散型アウトバウンド SIP ダイヤラ展開の例を示しています。

エージェント ベースのキャンペーン向けの分散アウトバウンド SIP ダイヤラ展開

この場合の平均 WAN 帯域幅の使用量は以下の通りです。

WAN Bandwidth = Calls Per Second * (Hit Rate * (Codec Bandwidth * Average Call Duration
+ Hit Call Signaling Bandwidth) + (1 – Hit Rate) * Non-Hit Call Signaling Bandwidth) = Kbps

例 1

SIP ダイヤラでの 60 cps のコールスロット リング、エージェント ベースのキャンペーンの 20％ のヒット率、および G.711 コーデックと平均コール期間 40 秒の WAN リンクを使用すると、帯域幅の使用量は以下の通りになります。

60 * (20% * (80 * 40 + 100) + (1 – 20%)*49.6) = 41980.8 kbps = 41.98 Mbps

例 2

SIP ダイヤラでの 60 cps のコールスロット リング、エージェント ベースのキャンペーンの 20％ のヒット率、および G.729 コーデックと平均コール期間 40 秒の WAN リンクを使用すると、帯域幅の使用量は以下の通りになります。

60 * (20% * (26 * 40 + 100) + (1 – 20%)*49.6) = 16060.8 kbps = 16.06 Mbps

エージェント ベースのキャンペーン: SIP ダイヤラ録音あり

この場合の平均 WAN 帯域幅の使用量は以下の通りです。

WAN Bandwidth = Calls Per Second * (Codec Bandwidth * Average Call Duration + Hit Rate
* Hit Call Signaling Bandwidth + (1 - Hit Rate) * Non-Hit Call Signaling Bandwidth) = Kbps

例 3

SIP ダイヤラでの 60 cps のコールスロット リング、エージェント  キャンペーンの 20％ のヒット率、および平均 G.711 コーデックおよび平均コール期間 40 秒の WAN リンクを使用すると、帯域幅の使用量は以下の通りになります。

60 * (80 * 40 + 20% *100 + (1 – 20%)*49.6) = 199180.8 kbps = 199.18 Mbps

例 4

SIP ダイヤラでの 60 cps のコールスロット リング、エージェント キャンペーンの 20％ のヒット率、および平均 G.729 コーデックおよび平均コール期間 40 秒の WAN リンクを使用すると、帯域幅の使用量は以下の通りになります。

60 * (26 * 40 + 20% *100 + (1 – 20%)*49.6) = 67660.8 kbps = 67.66 Mbps

VRU への転送キャンペーン: SIP ダイヤラ録音なし

以下の図は、VRU キャンペーンに転送するために配布されたアウトバウンド SIP ダイヤラの導入例を示しています。

CVPを使用した VRU キャンペーンへの転送のための分散型アウトバウンド SIP ダイヤラ展開

この場合の平均 WAN 帯域幅の使用量は以下の通りです。

WAN Bandwidth = Calls Per Second * Hit Rate * Hit Call Signaling Bandwidth + Calls Per Second
* (1 - Hit Rate) * Non-Hit Call Signaling Bandwidth = Kbps

例 5

SIP ダイヤラでのコール スロットリング 60 cps、IVRへの転送キャンペーンのヒット レート 20％、および G.711 コーデックを使用した WAN リンクでは、帯域幅の使用量は以下の通りです。

60 * 20% * 100 + 60 *(1 – 20%)*49.6= 3600 kbps = 3.6 Mbps

VRU への転送キャンペーン: SIP ダイヤラ録音あり

この場合の平均 WAN 帯域幅の使用量は以下の通りです。

WAN Bandwidth = Calls Per Second * (Codec Bandwidth * Average Call Duration + Hit Rate
* Hit Call Signaling Bandwidth + (1 - Hit Rate) * Non-Hit Call Signaling Bandwidth) = Kbps

例 6

SIP ダイヤラでの 60 cps のコールスロット リング、エージェント  キャンペーンの 20％ のヒット率、および G.711 コーデックおよび平均コール期間 40 秒の WAN リンクを使用すると、帯域幅の使用量は以下の通りになります。

60 * (80 * 40 + 20% *100 + (1 – 20%)*49.6) = 199180.8 kbps = 199.18 Mbps

例 7

SIP ダイヤラでの 60 cps のコールスロット リング、VRU への転送キャンペーンの 20％ のヒット率、および G.729 コーデックと平均コール期間 40 秒の WAN リンクを使用すると、帯域幅の使用量は以下の通りになります。

60 * (26 * 40 + 20% *100 + (1 – 20%)*49.6) = 67660.8 kbps = 67.66 Mbps

サービス コールバックに関する考慮事項

サービス コールバックによって、発信者が保留状態またはキューで待機する時間が短縮されます。ソリューションでは、エージェントが応答するまで発信者を保留状態で待たせる代わりに、基準を満たす発信者にコールバックできます。Unified CVP によってキューに格納された発信者は電話を切ることができます。このソリューションでは、エージェントが対応可能になる少し前に発信者にコールバックします（プリエンプティブ コールバック）。

プリエンプティブ コールバックによって、発信者がエージェントを待つ時間の長さが変化することはありません。これにより発信者は電話を切ることができるので、音楽を聞きながらキューに留まらずにすみます。キューに残っている発信者とコールバックによる対応を選択した発信者は、コールに応答するエージェントには同じように見えます。

Note

コールバックが指定の時間に行われるようにスケジュールすることは、この機能の一部ではありません。

サービス コールバックのコンポーネント

Note

VXML サーバ上の同じコールに対して、発信者が何回もサービス コールバックアプリケーションを呼び出すことができないようにしてください。

サービス コールバックは、IOS 音声ゲートウェイの TCL サービスと Cisco VVB の組み込み機能を使用します。

- サービス コールバック ユース ケース

- サービス コールバック コール フロー

- サービス コール設計の影響

サービス コールバック ユース ケース

コールバック スクリプトでは、発信者にサービス コールバックを提供する基準を確立することができます。確立できるコールバック基準の例は以下の通りです。

- 顧客ごとの平均コール処理時間に基づくと、キュー内の顧客の予想待機時間が最大数分を超過しています。

Note

含まれているサンプル スクリプトは、この方式を使用してコールバックの適格性を判断しています。

- 顧客に割り当てられた状態。ゴールドの顧客に電話をかける代わりにコールバックする機会を提供することができます。

- 顧客が要求する特定のサービス。コールバックの基準として、セールス コールまたはシステム アップグレードを確立することができます。

サービス コールバック コール フロー

発信者がコールバックを選択した場合、名前と電話番号を残します。顧客の要求はシステムで保持されます。予測される待機時間 (EWT) の値に達すると、システムは発信者にコールバックを発信します。発信者がコールに応答して元の発信者であることを確認すると、発信者は短時間待機した後にエージェントに接続されます。

Note

サービス コールバックは IP から発信されたコールでもサポートされます。

この機能の通常のコール フローは、以下のパターンをとります。

1. 発信者が Unified CVP に着信して、コールが通常の VRU 環境で処理されます。

2. Call Studio および Unified CCE サービス コールバック スクリプトは、発信者がルールに基づいてコールバックに相応しいかを判断します。

3. 発信者が資格がある場合、システムは EWT をアナウンスして、エージェントが応答可能になると、発信者にコールバックします。

4. 発信者は、以下の操作を選択します。

1. 発信者がコールバック機能を使用しない場合は、通常どおりキューイングが継続されます。

2. 発信者がコールバックを受ける場合、名前の記録と電話番号のキー入力が発信者に要求されます。

5. コールバック情報をログに記録するデータベース レコードが書き込まれます。

Note

データベースにアクセスできない場合には、システムは発信者にコールバックしません。

6. 発信者の通話が TDM サイドから切断されます。ただし、Unified CVP および Unified CCE のコールの IP 側は依然としてアクティブ状態です。このことにより、コールは同じキュー位置で保持されます。キュー音楽は再生されないため、この間に使用される音声ブラウザのリソースは、実際にキュー内にある発信者のリソースよりも少なくなります。

7. 適切なエージェントが対応可能に近づくと (コールバック スクリプトで判断)、システムが該当顧客にコールバックします。コールバックの際には、正しいユーザがコールを受け入れるようにするために、記録された名前が通知されます。

8. VRU セッションは、発信者に正しい相手であること、また、コールバックの準備ができていることを確認するように依頼します。

システムがコールバック番号に到達できない場合（ビジー回線、RNA、ネットワークの問題等）、コールはエージェントに送信されません。また、発信者が正しいユーザであるかどうかが確認されない場合も、コールはエージェントに送信されません。エージェントが電話にでるのは必ず相手が待機している時です。システムでは、エージェントが電話に出るまでに発信者がすでに電話に出ていることを想定しています。

この機能はプリエンプティブ コールバックと呼ばれます。これは、システムが、エージェントが応答する際に発信者は回線上におり、発信者の待機時間が最小限であることを想定するためです。

9. 通常どおり、コール コンテキストがエージェント画面ポップに表示されます。

構成可能な再試行回数および頻度の後もシステムが発信者に到達できない場合、コールバックはキャンセルされ、データベース上の状態は適切に更新されます。ビジネス ルールに基づいて手動でのコールバックが必要かどうかを判断するために、レポートを実行できます。

サービス コールバック機能を提供するスクリプトの関数のコール フローの詳細については、https://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html の Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

サービス コール設計の影響

サービス コールバック機能の設計に関しては、以下の影響を考慮します。

- サービス コールバック中に、コールバックは、コールが着信したのと同じイングレス ゲートウェイを使用して行われます。サービス コールバックでは、アウトバウンド コールは他のエグレス ゲートウェイを使用して行うことができません。

- Unified CVP VXML サーバでのコールバックを許可するキュー呼び出し。

- サービス コールバックには Unified CVP レポート サーバを必要とします。

- この機能では応答マシン検出は使用できません。コールバック中に、発信者には短い VRU セッション メッセージでプロンプトが提示され、DTMF を使用して、コールを受ける準備ができたことを確認します。

- DTMF * 8、TBCT、またはフック フラッシュを使用してエージェントに転送されるコールは、サービス コールバックを使用できません。

- サービス コールバックは、コンピュータ テレフォニー インテグレーション（CTI）ルート ポイント経由の CCB キューへのエージェント コール転送をサポートしていません。

- コールバックはベストエフォート型の機能です。コールバック中に発信者への到達試行を制限された数だけ行った後、コールバックは終了し、失敗としてマークされます。

- Unified CVP Operations Console で、サービス コールバックが発信に使用する許可番号またはブロック番号を設定します。

- 音声ブラウザのメディアの非アクティブ検出機能は、コールバックのコール待機に影響する可能性があります。詳細については、Configuration Guide for Cisco Unified Customer Voice Portalを参照してください。

- サービス コールバックは、最適に動作するために正確な EWT 計算が必要です。

サービス コールバックのプレシジョン キューを使用する場合、EWT を最適化するには以下の推奨事項を考慮します。

- 単一のプレシジョン キューにコールを格納します。

- 手順を設定するときに Consider If 式を追加しないでください。

- 手順の間に待機時間を追加しない、またはプレシジョン キューに手順を 1 つだけ使用しないでください。

Note

シンプルなプレシジョン キュー定義を使用します（たとえば、1 ステップおよび1 対 1 のエージェント マッピング）。プレシジョン キューは複雑なため、正確な EWT を計算することは困難です。

- コールバック時間の計算

コールバック時間の計算

以下のセクションでは、コールバック時間の決定方法の概要について説明します。

次に使用される主な用語の定義を示します。

- 待機時間：コールがキューに入ってから コールがキューから出るまでの間の時間間隔。

- 再接続時間：コールバック開始から発信者がコールバックを受諾してエージェントを待つ時間。

- コールバックのキュー内時間：発信者が再接続してからコールがキューを離れるまでの間隔。

- サービス レベル契約 (SLA)：コールバックの平均キュー内時間。平均は、コールの約 50 パーセントがサービス レベル内にあり、50 パーセントがサービス レベル外にあることを意味します。

- 平均キュー解除時間：コールがキューを出るまでにかかる平均秒数。

- 残り時間：発信者にコール バックするまでカウントダウンされる残り秒数。

- キュー時間内のコールバック

- プロセスの詳細および計算方式

- サンプル スクリプトとオーディオ ファイル

キュー時間内のコールバック

合意されたサービスレベルに基づくコールバック後の平均コールバック キュー内時間。サービス コールバックでは、早すぎるまたは遅すぎるコールバックも望ましくないシナリオであるため、回避されます。発信者のコールバックが早すぎる場合、キュー内の待機時間が長くなる可能性が高まります。コールバックがあまりに遅延する場合は、エージェントがアイドル状態になり、コールを待機する可能性が高まります。

コールセンターのダイナミクスが変化した場合は、残り時間を変更します。上記の変更は、使用可能なエージェント数が増減した場合や、平均ハンドル時間が変化した場合に行います。サービス コールバックでは、キュー内コール数、平均処理時間、応答可能状態および通話状態のエージェント数などのさまざまな要因に基づいて、平均キュー解除時間が計算されます。

平均キュー解除時間は、コールがキューに入ったとき、およびキューから出たときに更新されます。この情報を使用して、キュー時間のコールバックを削減し、エージェントがコールを待機する時間を最小化するように計算されます。

プロセスの詳細および計算方式

サービス コールバックでは、平均キュー解除時間を判断し、キュー内のすべてのサービス コールバック コールの残り時間を更新する以下の数式が使用されます。

Note

サービス コールバックのデフォルトの待機時間は 30 分で、例外として最大 90 分までサポートされています。

平均キュー解除時間の計算

平均キュー解除時間は、以下の数式を使用して計算されます。

D = (EWT + F)/N

それぞれの説明は以下の通りです。

- EWT は新しいサービス コールバック コールの推定待機時間です。

- F は、最初のコールがすでにキュー内にあった秒数です。

- N は、キュー内のコール数です。

Note

解除時間は、サービス コールバック機能が最適に動作する上で重要な役割を果たします。平均解除時間は、コール数、エージェントのアベイラビリティ、特定のスキル グループの平均処理時間などの要因に基づいて計算されます。

推定待機時間 (EWT) は、近似値を使用します。特定のスキル グループの平均処理時間とエージェントの可用性の均一性により、精度が高まります。上記要因が均一でない場合、通知された待機時間と実際のコールバック時間に誤差が生じます。また、マイクロ アプリケーションを使用すると、EWT の計算に含まれないコールがキューに挿入される場合があります。サービス コールバックを含む呼び出しのスクリプトを作成するには、マイクロ アプリの代わりに VxmlScripting を使用して VRU のすべてのコールをキューに入れます。

残り時間の計算

キュー内のコールバックの残り時間は、以下の数式を使用して計算されます。

R(p) = p*D - F - C

それぞれの説明は以下の通りです。

- p は、1 から N までのコールの現在のキュー位置です。

- R(p) はサービス コールバックの P 番目のキュー位置の残り時間です。

- Cはコールバック後のサービス コールバックの発信者が電話に出る時間と SLA 時間の合計です。

サンプル スクリプトとオーディオ ファイル

この機能では、Unified CCE スクリプトを使用します。変更可能なサンプル スクリプトが、Unified CVP インストール メディアの \CVP\Downloads and Samples\で提供されています。以下のスクリプトが発信者にコールバックを提供するかどうかを決定します。提供されているファイルは以下の通りです。

- CourtesyCallback.ICMS (Unified ICM スクリプト)

- CourtesyCallbackStudioScripts.zip (Call Studio スクリプト コレクション)

これらのスクリプトのサンプル音声ファイルは <CVP_HOME>\OPSConsoleServer\CCBDownloads\CCBAudioFiles.zip にインストールされ、メディア ファイル インストール オプションの一部としてもインストールされます。

CCBAudioFiles.zip を使用する場合は、コンテンツをメディア サーバで解凍する必要があります。CCBAudioFiles.zip には、en-us\app の下にサービス コールバック独自のアプリケーション音声ファイルがあり、en-us\sysの下に SAY IT SMART があります。Say It Smart 用のメディア ファイルがすでにメディア サーバ上にある場合は、en-us\app にあるメディア ファイルのみが必要です。

Note

デフォルトのプロンプトは Call Studio のデフォルトのほとんどのスクリプトに対応します。デフォルトのプロンプトでは対応できない特定のケースについて Say It Smart プラグイン プロンプトを確認してプロビジョニングします。

サンプル スクリプトは、デフォルトの場所の http://<server>:<port>/en-us/app を使用するように設定されています。サンプルの音声ファイルのデフォルトの場所を、使用している環境のサンプル スクリプトで変更します。(つまり、<server> と <port> をメディア サーバの IP アドレスとポートで置き換えます。

次のサンプル スクリプトがあります。

- BillingQueue: このスクリプトは、コールバックを受けないことを選択するか、コールバックを受信した後にキューに再び入る発信者に対してキュー音楽を再生します。このスクリプトは、ビジネス ニーズに合わせてカスタマイズできます。

- CallbackEngine: このスクリプトは、発信者がコールバックを選択してから発信者がコールバックを受信するまでの間、コールバックの VoIP レッグを存続させます。

Important

このスクリプトはカスタマイズしないでください。

- Callback Entry: このスクリプトは、発信者がシステムに入ったときに初期 VRU を処理して、発信者にコールバックを受信する機会を提供します。このスクリプトは、ビジネス ニーズに合わせてカスタマイズできます。

- CallbackQueue: このスクリプトは、発信者がキュー内で音楽を聴いている間に、通話のキープアライブ機能を処理します。

Important

このスクリプトはカスタマイズしないでください。

- CallbackWait: このスクリプトは、顧客にコールバックする際に、コールの VRU 部分を処理します。このスクリプトは、ビジネス ニーズに合わせてカスタマイズできます。

Note

サービス コールバックのサンプルファイルとスクリプトは、https://developer.cisco.com/site/customer-voice-portal/downloads/courtesy-callback-scripts/の DevNet (Customer Voice Portal (CVP) > ダウンロード > サービス コールバック サンプル スクリプト) で提供されています。

コール コンテキストに関する考慮事項

- 拡張コール コンテキスト変数の考慮事項

- Contact Center Enterprise ソリューションでの UUI の使用

拡張コール コンテキスト変数の考慮事項

拡張コールコンテキスト (ECC) 変数を使用すると、ビジネス関連データをエージェント デスクトップに転送するように設定することができます。通話の変数と異なり、各 ECC 変数のサイズ、形式、名前を設定することができます。ECC ペイロード を使用して、ECC ペイロードの メンバー であるECC 変数の設定を渡すことができます。ECC ペイロードは 2,000 バイトを保持します。ルータは、各コールに対して約 6,000 バイトの ECC 変数を保存することができます。ECC 変数のコンテンツに関するシステム全体の制限を超えると、ソリューションは警告イベントを生成します。

このソリューションには、下位互換性のために「デフォルト」名を持つ ECC ペイロードが含まれています。ソリューションがより多くの ECC 変数スペースを必要としない場合は、デフォルトのペイロードのみが必要となります。ソリューションがデフォルトのペイロードのみを保持している場合、ソリューションは、2000 バイトの制限に達するまで、新しい ECC 変数をすべてデフォルトのペイロードに自動的に追加します。

Note

デフォルトのペイロードを削除することはできません。ただし、そのメンバーを変更することはできます。CVP、アウトバウンドオプション、マルチチャネル、および ECC 変数は、デフォルトペイロードのスペースの一部を消費します。

特定のインターフェイスの ECC 変数を保持するためには、ECC ペイロードを作成します。

Note

CTI クライアントへの ECC ペイロードの場合、サイズ制限は 2,000 バイトに ECC 変数名のための追加の 500 バイトを加えたものです。他のインターフェイスとは異なり、CTI メッセージには、ECC の変数名が含まれています。

コール中に有効範囲を持つことができる ECC ペイロードは 1 つのみです。有効範囲がスクリプト環境内にある ECC ペイロードを設定します。このソリューションは、上書きされない限り、デフォルトのペイロードを使用します。

会議と転送の場合は、通常、コール フローを介して同じ ECC ペイロードを使用します。異なる ECC ペイロードを使用して 2 つのコールをマージする場合は、変数のマージ動作がより複雑になります。詳細については、isco Unified ICM/Contact Center Enterprise スクリプティングおよびメディア ルーティング ガイを参照してください。

- インターフェイスの ECC ペイロード使用

インターフェイスの ECC ペイロード使用

以下の表は、さまざまなオペレーションでの ECC ペイロードの使用方法をまとめたものです。

条件

使用される ECC ペイロード

VRU へのルーティング

デフォルトのペイロード

VRUの構成で ECC ペイロードが指定されている場合、デフォルト ペイロードは上書きされます。

アプリケーション ゲートウェイへのルーティング

現在スクリプトにスコープを持つ ECC ペイロード

エージェント PG へのルーティング (Unified CM PG および Avaya PG を含む)

現在スクリプトにスコープを持つ ECC ペイロード

Media Routing PG へのルーティング

デフォルトのペイロード

MR PGのVRU の構成で ECC ペイロードが指定されている場合、デフォルト ペイロードが上書きされます。

12.0 以前の PG へのルーティング

常にデフォルトのペイロード

System PG (エージェントまたは VRU) へのルーティング

常にデフォルトのペイロード

Avaya Aura Symposium PG へのルーティング

常にデフォルトのペイロード

Aspect PG へのルーティング

常にデフォルトのペイロード

送信先 Unified CCE への Contact Director

現在スクリプトにスコープを持つ ECC ペイロード

INCRP NIC へのルーティング

現在スクリプトにスコープを持つ ECC ペイロード

親/子の親の Gateway PG への事前ルーティング

常にデフォルトのペイロード

Note

別の ECC ペイロードを作成しない場合、ソリューションはすべての対象に対してデフォルトのペイロードを使用します。

Contact Center Enterprise ソリューションでの UUI の使用

Unified CCE スクリプトで UUI を設定して、SIP メッセージで再送信するために Unified CVP で UUI を抽出することができます。

UUI 処理のシナリオ：

- GTD の MIME ボディ形式の SIP INVITE メッセージの着信コール レッグには GTD (汎用タイプ記述子) データを含めることができます。この場合、Unified CVP によって、GTD データが着信 GTD として保存され、UUI 部分 (存在する場合) が Unified CCE に渡されます。

Cisco IOS ゲートウェイは、SIPトランスポートを使用した発信 VoIP ダイヤル ピアでこの GTD 形式をサポートしています。

Unified ICM がデータを変更する場合、変更した UUI を Unified CVP に返信します。Unified CVP は、Unified ICM から受信した UUI データを 16 進数に変換し、UUS（存在する場合）を変更して着信 GTD の値を上書きします。以下の形式を使用して、UUS 部分のみを変更します。

UUS,3,<converted Hex value of data from Unified CCE>

GTD パラメータ値の残りの部分は維持され、発信者 GTD から着信した値が保存されます。

- 着信コール レッグに GTD がない場合、Unified CVP はトレースに「GTD ボディが発信者ボディに存在しません」というメッセージを出力します。その後、そのコールは通常のコールとして処理されます。

Note

- Unified CCE は変更された UUI を user.microapp.uui ECC 変数または Call.UsertoUserInfo 変数で渡します。

- 両方の変数を使用する場合、Call.UsertoUserInfo 変数が優先されます。

変更された GTD は、CVP SIP B2BUA からの発信 INVITE MIME ボディで設定され、ここには IP 発信者と TDM 発信者が含まれます。接続されたコールでアウトパルス転送用の DTMF ラベルが受信された場合、Unified CCE が UUI を通過させた場合にのみ BYE メッセージが GTD と共に送信されます。BYE メッセージは SIP INFO 直後に DTMF で送信されます。

Note

フックフラッシュまたは Two B Channel Transfer（TBCT）を使用すると、UUI データ転送機能を使用できません。

Unified CCE スクリプト内の UUI

Unified CCEスクリプトでUUIを抽出するには、user.microapp.uui ECC 変数および Call.UserToUserInfo 変数を確認します。上記変数のいずれかで SET ノードを使用すると、コールの発信方向の変数を設定することができます。

Call.UserToUserInfo 変数の設定が ECC 変数の使用よりも優先されます。

Note

Unified CVP は、Unified CCE が UUI に合格した場合にのみ、DTMF ラベルで BYE メッセージを送信します。

BYE メッセージが受信された場合、受信された BYE の GTD が使用され、他のレッグで送信されます。

UUI および UUS を使用した GTD が VoIP 側で転送されるように、無条件の信号転送でイングレス ゲートウェイを構成します。次に例を示します。

voice service voip
signaling forward unconditional

REFER の UUI および 302 リダイレクト応答

REFER コール フローを使用する場合、Unified CCE スクリプトで UUI を設定することができます。UUI は MIME ボディであり、ATT IP Toll Free NSS 形式に従って 16 進エンコードされます。また、この UUI の展開は 302 リダイレクト応答にも適用されます。

VER,1.00
PRN,t1113,*,att**,1993
FAC,
UUS,0,(hex encoded UUI string here)

データベース ルックアップ設計に関する考慮事項

- アプリケーション ゲートウェイでは、GED 145 インターフェイスとの統合を設定する際のオーバーヘッドが拡大しますが、データへのアクセス方法の柔軟性は向上します。

- CVP API は、ソリューションのプライマリ ルーティング エンジンの処理をオフロードする REST API またはデータベースまたはカスタム統合オプションを提供します。この欠点は、複数のノードにわたる CVP 処理により、調整と保守が複雑になることです。また、ルーティング スクリプトで実行中は、すべてのコンテキストが利用可能であるとは限りません。

- データベース ルックアップは、アプリケーション ゲートウェイよりもセットアップのコストが低く、レポート オブジェクトがアクセス可能なスクリプト内で情報を利用できるようにしますが、データのインデックス方法および利用可能なデータにいくつかの制限があります。データベース ルックアップは、アプリケーション ゲートウェイまたは CVP 統合で通常ルータへのデータのプッシュに使用される ECC 変数を利用せずに、スクリプトに取り込まれた外部データにアクセスする方法も提供します。

- データベース ルックアップ コール フロー

- データベース ルックアップ サイジングに関する考慮事項

- データベース ルックアップ設計の影響

データベース ルックアップ コール フロー

データベース ルックアップの基本コール フローは、この図のように実行されます。

データベース ルックアップ コール フロー

データベース ルックアップ サイジングに関する考慮事項

サポートされるデータベースのルックアップ レートは、システムの最大コール レートと同じです。

データベース ルックアップ設計の影響

- この外部データベースは、 Unified CCE ソリューションがホストされる仮想マシンとは別の仮想マシンでホストされる必要があります。

- 外部データベースは、Microsoft SQL Server の互換性のあるバージョンを実行している必要があります。

- データベース ルックアップ用に設定されたタイムアウトは、整合性があり、他の要求のタイムアウトと一致している必要があります。ターゲット インスタンスへの Contact Director のルートで使用されている場合、データベース ルックアップはルート要求のタイムアウトの 25% である必要があります。

- データベースのルックアップノードは、単一のプライマリ キーに基づいています。複雑なクエリはサポートされていません。

- すべての列のデータの合計サイズは 3500 バイトを超えてはなりません。

コーデックに関する考慮事項

Contact Center Enterprise ソリューションは  VRUに対してのみ G.711 コーデックをサポートしています。SIP キャリアまたは TDM-IP ゲートウェイは G.711 および G.729 として機能を送信します。その際、G.729 の優先度が高くなります。音声ブラウザでのプロンプトは、「G.711」とします。エージェントは G.711 と G.729 の両方をサポートします。その際、G.729 の優先度が高くなります。この設定では、VRU にトランスコーダの使用およびエージェントへのコール接続が回避されます。イングレス ゲートウェイと Unified CM にデュアル コーデックを定義することにより、ウィスパー アナウンスメントにユニバーサル トランスコーダを使用しない構成にすることができます。

VRU は、G.711 としてネゴシエイトされます。このソリューションは、発信者とエージェントの会話を G.729 として自動的に再ネゴシエイトして、WANリンク上の帯域幅を節約します。

G.711 mu-law または a-law プロンプトのいずれかを使用できます。その際、ソリューション全体で同じ形式に構成します。

G.711 a-law では、以下の機能がサポートされています。

- エージェントのグリーティング

- ウィスパー アナウンスメント

- Unified CM ベースのサイレント モニタリング

- アウトバウンド SIP ダイヤラ

- サービス コールバック

- ポスト コール調査

- モバイル エージェント

Note

CUBE を備えた SIP ダイヤラは、特定の設計上の考慮事項を鑑みた a-law をサポートできます。SIP ダイヤラでは、a-law はアドバタイズされません。このソリューションでは、SIP ダイヤラおよび SIP サービス プロバイダー間の最初のネゴシエーション (メディアなし) で CUBE の DSP リソース (トランスコーダ) を使用します。ダイヤラからエージェントへの REFER を実行中に、CUBE はエージェントとコードを再ネゴシエイトします。CUBE はその後、DSP リソース（トランスコーダ）を解放します。

- 混合コーデック ユース ケース

- 混合コーデック コール フロー

- 混合コーデック設計の影響

混合コーデック ユース ケース

トランスコーダおよび DSP リソースを回避するには、混合コーデックを使用します。イングレスおよびエグレス ゲートウェイと Unified CM でデュアル コーデックを定義します。VRU は、コールを G.711 として自動的にネゴシエイトします。次に、そのコールを G.729 または G.711 として、発信者とエージェントの対話用に再接続します。

混合コーデック コール フロー

VRU 中の論理フロー

1. コールがイングレス ゲートウェイに着信します。ゲートウェイは SIP インバイト メッセージを SIP プロキシ サーバに送信し、SIP プロキシ サーバは要求を Unified CVP SIP サービスに転送します。

2. CVP は、音声ブラウザにコールを送信します。

3. コールが、トランスコーダを使用しない G.711 コーデックを使用して確立されます。

発信者とエージェントの会話中の論理フロー

1. コールがイングレス ゲートウェイに着信します。ゲートウェイは SIP インバイト メッセージを SIP プロキシ サーバに送信し、SIP プロキシ サーバは要求を Unified CVP SIP サービスに転送します。

2. CVP は、Unified CM にコールを送信して、Unified CCE エージェントにルーティングします。

3. コールは、トランスコーダを使用せずに G.729 として再ネゴシエートおよび確立されます。

混合コーデック設計の影響

混合コーデックの設計上の影響は以下の通りです。

- G.729 のみをサポートする SIP トランクは、トランスコーダの使用を強制します。

- ウィスパー アナウンスメントなどの一部の機能では、G.729 から G.729 へのインターワーキングに汎用トランスコーダが必要となります。

- 単一の 729 コーデックによってトランスコーダが必要な場合は、Unified CM 制御トランスコーディング リソースを使用します。上記リソースは、コーデックが一致しない場合に自動的にトリガされます。

- コール フロー、補足サービス、および特定の統合機能に基づき、適切なトランスコーディング リソースおよび汎用トランスコーディング リソースのサイジングが必要です。

モバイル エージェントに関する考慮事項

Unified Mobile Agent を使用すると、PSTN 電話とブロードバンド VPN 接続を備えたエージェントは、正式なコンタクト センターのローカル エージェントと同様に機能できるようになります。

Unified Mobile Agent では、モバイル エージェントの電話（またはエンドポイント）と発信者の電話（またはエンドポイント）のプロキシとして機能する CTI ポート ペアが使用されます。サインインしているモバイル エージェントごとに、2 つの CTI ポート（ローカルとリモート）が必要です。CTI ポートは、Unified CM JTAPI によって制御される Cisco IP Phone に代わるものです。エージェントがローカル CTI ポートの DN にサインインすると、Unified CM はモバイル エージェントのコールをその DN にルーティングします。固定接続用にサインインするか、または Unified CM がコールバイコール接続のエージェントにコールをルーティングするときに、リモート CTI ポートはエージェントを呼び出します。CTI ポートは、メディア リダイレクションを使用して、2 つの VoIP エンドポイントに信号を送り、RTP パケットを直接ストリーミングします。さらにコール制御（転送、会議、保留、または解放）が必要になるまで、CTI ポートによる関与はありません。エージェントは、エージェント デスクトップから後続のコール制御を実行します。CTI ポートでコールのメディアを制御するために、PG は必要な後続のコール制御を JTAPI によって Unified CM に転送します。

Cisco Unified Mobile Agent アーキテクチャ

2 つの CTI ポート（ローカルとリモート）は、PG ソフトウェア内で論理的かつ静的にリンクされています。PG は PG の初期化時に CTI ポートを登録します。モバイル エージェントがサインインすると、それらの 2 つの CTI ポートにコール オブザーバーが追加されます。PG は CTI ポートとコールに対してコール制御を行います。音声パスは 2 つの音声ゲートウェイの間にあります。

Note

モバイル エージェントは IPv6 対応の CTI ポートを使用できません。

コンタクト センターで、モバイル エージェントは JTAPI によって制御される電話から、同じエージェント ID を使用してローカル エージェントとしてサインインできます。履歴コール レポートでは、モバイル エージェントとして処理されたコールとローカル エージェントとして処理されたコールは区別されません。

接続モード

Unified Mobile Agent を使用すると、コールバイコール ダイヤル接続または固定接続のいずれかを使用するようにエージェントを設定できます。または、サインイン時にエージェントに選択させることもできます。

コールバイコール接続を使用する場合は、以下を考慮してください。

- エージェントの電話にボイスメールが設定されている場合は、ボイスメールを無効にして、RONA コール処理の実行を許可します。

- コールバイコール接続の場合、エージェントはオフフックにすることで電話に応答し、電話機を切って通話を終了します。エージェント デスクトップの [応答（Answer）] ボタンは無効になります。

- コールバイコール接続の場合、エージェントは相手側が終了していないうちは、転送の一方のレグを終了できません。転送は、完全に完了するか、両方のレグが完全にドロップする必要があります。

- コールバイコール接続では自動応答は使用できません。モバイル エージェントの電話をオフフックにするコール制御メカニズムはありません。

固定接続を使用する場合は、以下を考慮してください。

- 固定接続のモバイル エージェントは、デスクトップを使用するか電話を切ることによってログオフできます。

- 固定接続では自動応答を使用できます。

- 次の Unified CM タイマーによって、モバイル エージェントの固定接続コールを終了させることができます。

- 最大コール時間タイマー（デフォルト値は 720 分）

- 最大コール保留タイマー（デフォルト値は 360 分）

この終了機能によって、固定接続のモバイル エージェントをサインアウトできます。モバイル エージェントをサインインしたままにしておくには、両方のタイマーの値を 0 に設定すると、タイマーが期限切れになりません。

- ファイアウォールは、固定接続上のメディア ストリームをブロックできます。これは、固定接続モードのエージェントが、ファイアウォールのアイドル タイムアウト値よりも長い時間アイドル状態になると発生します。ファイアウォールは、ファイアウォール アイドル タイムアウトが期限切れになるとメディア ストリームをブロックします。これを回避するには、ファイアウォールのアイドル タイムアウト値を増大させます。

- モバイル エージェント コール フロー

- モバイル エージェントの設計の影響

モバイル エージェント コール フロー

コールバイコール接続コール フロー

コールバイコールでは、エージェントのリモート電話が各着信コールに対してダイヤルされます。コールが終了すると、エージェントの電話は切断され、次のコールに応答できる状態になります。

このタイプのダイヤルの基本的なコール フローは以下の通りです。

1. ログイン時には、モバイル エージェントはエージェント ID、パスワード、ローカル CTI ポート DN を内線番号として指定して、電話番号をコールします。管理者は、エージェントの場所に基づいて CTI ポートの DN を事前に選択します。

2. キューのプロセスは、モバイル エージェントでもローカル エージェントの場合と同じように動作します。

3. コールに対してモバイル エージェントが選択されると、モバイル エージェントの新しい処理が開始します。ルータは、エージェントのローカル CTI ポートのディレクトリ番号をルーティング ラベルとして使用します。

4. エージェントのローカル CTI ポートで着信コールが鳴ります。エージェント PG には、ローカル CTI ポートが鳴っていることが通知されますが、コールはすぐには応答されません。発信者には呼び出し音が聞こえます。

5. 同時に、選択したエージェントのリモート CTI ポートからエージェントへのコールが開始されます。このプロセスは、接続時間に応じて完了するまでに時間がかかる場合があります。設定された時間内にエージェントが応答しない場合、RONA の処理が開始されます。

6. エージェントが電話を取って応答すると、この 2 番目のコールは一時的に保留になります。次に、元のカスタマー コールが応答され、エージェント コール メディアのアドレスに転送されます。次に、エージェントコールは保留解除され、カスタマー コールのメディア アドレスに送信されます。その結果、2 つの VoIP エンドポイント間で RTP ストリームが直接生成されます。

7. 通話が終了すると、両方の接続が切断し、エージェントは状況に応じて「応答可能」、「応答不可」、もしくは「後処理」の状態となります。

固定接続のコール フロー

固定接続モードでは、ログイン時にエージェントが 1 度呼び出され、回線は複数のカスタマー コールを経て接続されたままになります。

この接続タイプの基本的なコール フローは以下の通りです。

1. ログイン時には、モバイル エージェントはエージェント ID、パスワード、ローカル CTI ポート DN を内線番号として指定して、電話番号をコールします。管理者は、エージェントの場所に基づいて CTI ポートの DN を事前に選択します。リモート CTI ポートは、ローカルの CTI ポートに静的に関連付けられています。

2. リモート CTI ポートは、モバイル エージェントが指定した電話番号へのコールを開始します。エージェントが応答すると、そのコールはすぐに保留状態になります。エージェントはログインしておらず、このプロセスが完了するまで応答できません。

3. キューのプロセスは、モバイル エージェントでもローカル エージェントの場合と同じように動作します。

4. コールに対してモバイル エージェントが選択されると、モバイル エージェントの新しい処理が開始します。

5. 着信コールがモバイル エージェントのローカル CTI ポートで鳴ります。JTAPI ゲートウェイは、CTI ポートが鳴っていることを検出しますが、すぐには呼び出しに応答しません。発信者には呼び出し音が聞こえます。

6. エージェントのデスクトップが、コールが鳴っていることを示します。エージェントの電話機は、すでにオフフックになっているため、着信音を鳴らすことはありません。設定された時間内にエージェントが応答しない場合、RONA の処理が開始します。

7. エージェントがコールを受け入れるために応答ボタンを押すと、カスタマー コールが応答し、エージェント コール メディア アドレスに転送されます。次に、エージェントコールは保留解除され、カスタマー コールのメディア アドレスに送信されます。

8. 通話が終了すると、カスタマー接続は切断され、エージェント接続は保留状態に戻ります。エージェント構成およびエージェント デスクトップ入力に応じて、エージェントの状態は「応答可能」、「応答不可」、または「後処理」となります。

モバイル エージェントのアウトバウンド コール フロー

モバイル エージェントは、固定接続でのみ、アウトバウンド キャンペーンに参加することができます。

予測ダイヤルまたはプログレッシブ ダイヤルのコール フローは以下の通りです。

1. モバイル エージェントは、エージェントの電話番号としてローカル CTI ポートの DN を使用してサインインします。

2. アウトバウンド オプションの標準コール フローが発生します。

3. ルータがモバイル エージェントを選択すると、MR 画面が、応答可能なエージェントのダイヤラへのラベル (ローカル CTI ポート DN) を返します。

4. ダイヤラは、予約された電話をローカル CTI ポート DN に配置して、自動的に保留状態にします。

5. ダイヤラがライブ コールを処理するモバイル エージェントを選択すると、そのコールをローカル CTI ポートに転送します。

6. ダイヤラは、CTI サーバ経由でエージェント用に転送されたコールに自動応答します。これにより、顧客とエージェント間の音声パスがすぐに確立されます。次に、ダイヤラは、モバイル エージェントへの予約コールを切断します。

モバイル エージェントの設計の影響

Unified Mobile Agent は、Cisco 音声ゲートウェイに転送される PSTN 電話機にログインして、Unified CCE にログインすることができます。モバイル エージェントには、エージェント デスクトップも必要となります。

Unified CCE がモバイル エージェント向けにサポートする任意の音声ゲートウェイを使用することができます。エージェント PG または別のクラスタと同じ Unified CM クラスタと共に音声ゲートウェイを登録することができます。発信者 (イングレス) およびモバイル エージェント (エグレス) 音声ゲートウェイは MGCP または SIP を使用することができます。

Note

サイレント モニタリングを有効にした場合は、イングレスとエグレスに異なる音声ゲートウェイを使用します。

Unified Mobile Agent では、SIP 用に設定されている Cisco IP フォンを使用することができます。モバイル エージェントへのコールは、SIP IP フォンから発信される場合もあります。

Unified CM のパフォーマンスを向上させるために、エージェント PG と同じクラスタの IP フォンを持つモバイル エージェントに対しては、Unified Mobile Agent ではなく Extension Mobility を使用します。IP フォン デバイスは JTAPI ユーザに関連付けられているため、Unified CM でこの関連付けを行うと、パフォーマンスがわずかに低下します。

Unified Mobile Agent ソリューションを設計する際は、以下の点を考慮します。

- SIP トランクを使用している場合は、メディア ターミネーション ポイント (MTP) を設定します。この要件は、TDM トランクを使用してサービス プロバイダーとインターフェイスする場合にも適用されます。詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.htmlの Cisco Unified Contact Center Enterprise 機能ガイド を参照してください。

- トランクの使用を有効にすると、そのトランクを通過するすべてのコールに影響します。コンタクト センター以外のコールにも影響を与えます。使用可能な MTP の数がトランクを通過するコールの数をサポートすることを確認します。

- エージェントのロケーションおよびコール アドミッション コントロール設計

- モバイル エージェントのダイヤル プラン

- モバイル エージェントのコーデック設計

- モバイル エージェント 保留中の音楽

- モバイル エージェントが存在する Cisco Finesse

- モバイル エージェントが存在する DTMF の考慮事項

- モバイル エージェントが存在するセッション ボーダー コントローラ

- モバイル エージェントの耐障害性

- モバイル エージェントのサイジングに関する考慮事項

エージェントのロケーションおよびコール アドミッション コントロール設計

CTI ポートはエンドポイントの仮想タイプであるため、任意の場所に配置することができます。ただし、エージェントの VoIP エンドポイントと同じ場所で、モバイル エージェントの CTI ポートを設定することが推奨されます。モバイル エージェントの CTI ポート ペアは、エージェントを呼び出す音声ゲートウェイ (または VoIP エンドポイント) と共存させる必要もあります。この両方の条件があてはまらない場合、コール受付は正しく考慮されません。

コール受付制御は、モバイル エージェントのコールを 2 つの別個のコールとして認識します。最初のコール レッグは、発信者によってエージェントのローカル CTI ポートに送信されます。2 番目のコール区間は、リモート CTI ポートからエージェントに接続しています。CTI ポートはエージェントのエンドポイントと共存するため、コール受付制御は、発信者からエージェントの場所へのコールのみをカウントします。このため、エージェントが現在の場所で CTI ポートを使用することが重要です。

モバイル エージェント CTI ポートのコール受付制御のロケーションの観点から、3 つの展開シナリオがあります。

- モバイル エージェントを呼び出す CTI ポートはエグレス音声ゲートウェイと共存させることができます。

- イングレス音声ゲートウェイと同じ場所に配置された CTI ポートを使用します。

- Unified CM クラスタ間で、クラスタ間のトランクと共存する CTI ポートを使用します。

CTI ポートのすべてのプールは、エージェントの VoIP エンドポイント タイプ（音声ゲートウェイまたは IP 電話）と同じ場所に配置されます。

また、発信者とエージェントは、別の Unified CM クラスタの VoIP エンドポイントを使用することもできます。この設定により、リモート ロケーションのエージェントを、異なる Unified CM クラスタのローカル音声ゲートウェイから呼び出すことができます。

Note

この場合にサイレント モニタリングを使用する場合、ソリューションには、エージェント（エグレス）音声ゲートウェイを備えたリモート サイトのモニタリング サーバが必要です。

コール受付制御の設計の詳細については、『Cisco Collaboration System Solution Reference Network Designs』の http://www.cisco.com/go/ucsrnd に掲載されたコール受付制御の情報を参照してください。

モバイル エージェントのダイヤル プラン

コールをリモート CTI ポートからモバイル エージェント CTI ポートと同じ場所にある音声ゲートウェイにルーティングするように Unified CM ダイヤルプランを設定します。それ以外の場合、コール受付制御アカウンティングは正常に機能しません。

また、着信番号に関わらず、CTI ポートからのすべてのコールが特定のゲートウェイを通過するように、Unified CM ダイヤル プランを設定することもできます。この設定では、すべてのモバイル エージェントが使用する専用のゲートウェイが用意されています。管理はより容易になるとはいえ、PSTN トランク使用の観点からは効率的な設定ではない場合があります。

ダイヤル プラン設計の詳細については、『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

モバイル エージェントのコーデック設計

イングレスとエグレスの音声ゲートウェイ間のメディア ストリームは、G.711 または G.729 にすることができます。PG のすべての CTI ポートは同じコーデック タイプをアドバタイズする必要があるため、コーデックを混在させることはできません。この要件により、WAN を介して（G.729 ではなく）G.711 コールが送信される場合があります。イングレス音声ゲートウェイと同じ場所に配置されたエージェントにほとんどのコールをルーティングする場合、WAN を介していくつかの G.711 コールを送信することが問題とならない場合があります。別の方法として、G.729 をすべてのモバイル エージェント コールに使用することができます。ほとんどの Unified CCE コールが WAN セグメントを通過する場合、すべての CTI ポートを G.729 用に設定することは恐らく理にかなっています。ただし、一部のモバイル エージェント コールに G.711 を使用して、他のモバイル エージェント コールには G.729 を使用するということはできません。使用するソリューションには、CTI ポート専用の領域が必要で、この領域との間のすべての呼び出しで同じエンコード形式が使用されるようにします。

コーデック設計の考慮事項の詳細については、『Cisco Collaboration System Solution Reference Network Designs』を参照してください。

モバイル エージェント 保留中の音楽

通常のエージェントと同じように、モバイル エージェントに対して保留音（MoH）は使用することができます。発信者に音楽が聞こえるようにするには、MoH リソースをイングレス音声ゲートウェイに割り当てます。ローカル CTI ポート設定で、ユーザまたはネットワークの音声ソースを指定します。保留中にエージェントが音楽が聞こえるようにするには、MoH リソースをエグレス音声ゲートウェイに割り当てます。リモート CTI ポート設定で、ユーザまたはネットワークの音声ソースを指定します。

Note

MoH リソースは常にゲートウェイに割り当てます。MoH リソースをローカルまたはリモートの CTI ポートに割り当てません。不必要であるだけでなく、システムのパフォーマンスに影響を与える可能性があります。

固定接続経由のモバイル エージェント リモートコールは、エージェントに対するアクティブ コールが存在しないと保留状態になります。通常、固定接続コールには、モバイル エージェントの電話機に対して MoH を有効にします。MoH リソースが問題となる場合は、マルチキャスト サービスを検討してください。

固定接続では、リモートフォンの [MoH」を無効にすると、保留トーンが再生される場合があります。これは、リモート電話機を制御するコール処理エージェントによって異なります。Unified CM では、保留トーンはデフォルトで有効になっており、モバイル エージェントの接続トーンと類似しています。Unified CM の保留音が有効になっていると、モバイル エージェント接続トーンが聞こえた際にエージェントが着信したかどうかを判別するのが困難となります。したがって、Unified CM の Tone on Hold Timer サービス パラメータの設定を変更して、Unified CM の 保留音 を無効にします。

MoH 設定上の詳細については、『Cisco Collaboration System Solution Reference Network Designs』を参照してください。

モバイル エージェントが存在する Cisco Finesse

Cisco Finesse では、モバイル エージェントがサポートされます。Cisco Finesse サーバでは、モバイル エージェント機能を有効にするための設定は必要ありません。モバイル エージェント機能を使用するには、 Cisco Unified Contact Center Enterprise 機能ガイドで説明されるすべての設定に従います。

Note

Cisco Finesse IP Phone Agent はモバイル エージェントをサポートしていません。

[Cisco Finesseログイン] ページで、[モバイル エージェント] チェックボックスをオンにすると、エージェントにモバイル エージェント オプションが表示されます。モバイル エージェントは、ローカル CTI ポートの内線番号、モード（コール バイ コールまたは固定接続）、およびエージェントの電話のダイヤル番号を提供します。

エージェントの電話番号は、コール受付制御が正常に機能するために、CTI ポート ペアと同じ場所にある VoIP エンドポイント（音声ゲートウェイ、IP フォン、またはクラスタ間トランク）にルーティングする必要があります。

Cisco Finesse モバイル スーパーバイザは、サイレント モニタリングを除き、非モバイル スーパーバイザが実行可能なすべての機能を実行することができます。Cisco Finesse では、モバイル エージェントのサイレント モニタリングはサポートされません。

モバイル エージェントが存在する DTMF の考慮事項

モバイル エージェントが DTMF を使用してナビゲートする VRU またはその他のネットワーク コンポーネントを参照する場合、ソリューションに MTP リソースが必要になる場合があります。モバイル エージェント機能は、インバンド  DTMF (RFC 2833) をサポートしない CTI ポートに依存します。エージェントのエンドポイントがインバンド DTMF のみをサポートしている場合（または RFC 2833 に従ってインバンド DTMF 用に構成されている場合）、Unified CM は不一致を処理するために MTP リソースを自動的に挿入します。この場合、MTP リソースが十分に利用可能であることを確認してください。

モバイル エージェントが存在するセッション ボーダー コントローラ

Cisco Unified Border Element およびその他の Session Border Controller 等の一部の SIP デバイスは、通話中にメディア ポートをダイナミックに変更することができます。モバイル エージェント コールで上記が発生する場合、ソリューションには、エージェント エンドポイントに接続する SIP トランク上の MTP リソースが必要となります。

モバイル エージェントの耐障害性

モバイル エージェント コールの RTP ストリームは、イングレスおよびエグレス音声ゲートウェイの間となります。このため、Unified CM または Unified CCE に障害が発生しても、コール 耐障害性 への影響はありません。ただし、フェールオーバー後は、後続のコール制御 (転送、会議、または保留) を実行できない場合があります。モバイル エージェントのデスクトップがフェールオーバーを通知し、エージェントは再度ログインする必要があります。

モバイル エージェントのサイジングに関する考慮事項

モバイル エージェント コールの処理では、より多くのサーバ リソースが使用されます。これにより、以下の通り Unified CM サブスクライバとエージェント PG の両方で最大サポートエージェント数が少なくなります。

- 2000（固定接続 1:1）

- 平均処理時間が 3 分未満の場合、またはエージェントグリーティングまたはウィスパーアナウンスメント機能が モバイルエージェント（1.3:1）と一緒に使用された場合、1500 固定接続

- 800（コールバイコール接続 2.5:1）

Unified Mobile Agent は、エージェントグ リーティングに会議ブリッジ リソースを使用します。エージェント グリーティングを使用して、グリーティングではなく、会議であるのように各コールのサイズは調整されます。

Unified Mobile Agent では、コンタクト センターのコール毎に 2 つの CTI ポートを使用する必要があります。片方の CTI ポートが発信者のエンドポイントを制御して、別の CTI ポートは選択されたエージェントのエンドポイントを制御します。実際の RTP ストリームは 2 つのエンドポイント間にあり、2 つの CTI ポート経由ではブリッジされます。ただし、Unified CM には、この 2 つの CTI ポート経由でモバイル エージェントへのコールを設定するための追加のコール処理が提供されています。

モバイル エージェントは、高画質のブロードバンド接続と PSTN 電話機を備えた任意の場所 (エージェント デスクトップを含む) からログインすることができます。ただし、モバイル エージェントは、音声ゲートウェイが別のクラスタに登録されている場合でも、論理的には特定のエージェント PG および Unified CM クラスタに関連付けられます。エージェントは特定の周辺機器に関連付けられており、カスタムの変更を行わない限り、自由に別の周辺機器に移行することはできません。

サブスクライバとクラスタの特定のサイズ変更については、Cisco Unified Communications Manager 許容量ツールを使用します。クラスタのサイズを変更する場合は、同時にログインするモバイル エージェントの最大数を入力します。最大同時ログイン モバイル エージェント数を超える構成済みモバイル エージェントを処理するには、ツールで BHCA および BHT を 0 に設定してタイプ 1 CTI ポートを入力します。これは、ツールで CTI サードパーティ制御回線を使用してログインしていないローカル エージェントの電話のアカウント方法に似ています。別の方法として、すべての（ログインおよび未ログイン）モバイル  エージェントをツールに入力し、これに応じてモバイル エージェント毎に BHCA および BHT を調整することができます。同時ログインするモバイル エージェント数を実際の BHCA と BHCA と比較する場合は、合計 BHCA と BHCA には変更を加えません。

内線番号のサポートに関する考慮事項

ソリューションで電話機の拡張機能を使用する場合は、以下の点を考慮します。

コンタクト センターでは、以下のコール タイプが処理可能であり、それぞれの検討事項には、以下があります。

- ルーティングされた ACD コール: スキルまたは属性に基づく中央キューを介してエージェントにルーティングされるコール。

- ルーティングされたエージェント コール: 顧客がこのエージェントと特定のビジネス関係にある特定のエージェントにルーティングされるコール。

- ルーティングされないコール: 直接内線ダイヤル内線を介して、または企業内の監視されていない電話からの直接ダイヤルコール。

- エージェント間コール: 転送されるあるいは転送されないエージェント間のコール。

電話内線は、以下のいずれかになります。

- ACD 内線番号: コールがルーティングされるエージェントがログインする内線番号。

- セカンダリ拡張: 非 ACD 拡張と呼ばれることもあります。これは、通常、コールがルーティングされない場合の内線です。エージェントは、これをビジネス アクティビティまたはパーソナル アクティビティで使用することができます。このソリューションでは、設定に応じてこの拡張のアクティビティを監視して、利用可能な機能に影響を与えることができます。

- モニタリング対象セカンダリ内線

- モニタリング対象外のセカンダリ内線

- 内線番号のコール タイプに関する考慮事項

- E. 164 ダイヤル プラン設計

モニタリング対象セカンダリ内線

マルチライン エージェント制御 (MLAC) は Cisco CCE エージェントの周辺機器設定であり、セカンダリ拡張でのコールについてレポート作成およびコール制御を可能にします。MLAC を使用すると、以下の通りの制限が課されることがあります。

- コール待機なし

- 各エージェントの電話機には 4 つの内線番号の制限があります

- エージェント間の共有回線はありません

- 有効にすると、特定の周辺機器のすべての電話機に適用されます

モニタリング対象外のセカンダリ内線

このソリューションは、監視されていないセカンダリ内線番号でのコール アクティビティは追跡されません。セカンダリ内線番号には、共有回線の使用など、通常はコンタクト センター アクションに関連付けられていない PBX 機能を含めることができます。

内線番号のコール タイプに関する考慮事項

ルーティングされていないダイレクト エージェント ダイヤル

ACD回線がルーティングされないコール、または状態に関係なくルーティングされるコールを受信すると、エージェントのエクスペリエンスおよびレポートに影響を与える可能性があります。別のエージェントからの直接コールは、エージェントがコール中または後処理状態にあるときに実行できます。

ビジネス モデルで許可されている場合、エージェント間コールを含め、すべてのコールがエージェントにルーティングされると、コール フローがさらにクリーンになります。ルーティング スクリプトは、エージェントの状態を考慮に入れて作成します。そうでない場合は、競合状態が発生し、レポートとエージェントのエクスペリエンスに影響を与える可能性があります。

エージェント直通ダイヤル

エージェントが顧客との関係を保持し、直通番号を提供する場合、導入の方法にはいくつかの選択肢があります。

直通ダイヤルのコールこれらの直接ダイヤル コールにエージェントのプライマリ内線番号を使用する場合は、次のオプションを検討してください。

- ルーティングされない場合、コールはルーティングをバイパスしてエージェントの ACD 内線番号に直接渡されます。電話機のコール待機は常に有効にします。ルーティング スクリプトの VRU は、コール コンテキストを追加することはできません。ただし、発信者番号がブロックされていない場合は、エージェントがログインしている場合に外部データベースのディップを実行するように Finesse をカスタマイズすることができます。

- ルーティング: コールをエージェントの ACD 内線にルーティングすると、より充実したレポートが得られ、より多くのコールコンテキストを含めることができ、エージェントの状態に基づいてルーティングを決定することができます

- エージェントが、エージェント ノードへのキューを使用して応答可能になるまで、そのコールをキュー内に保持することができます。

- エージェント間ノードを使用して、エージェントの状態に関わらず、ログインしたエージェントにコールを送信することができます。

- コールをエージェントの内線に送信したり、ラベル ノードを使用してボイスメールに送信したりすることができます。

- エージェントが応答しない場合や、ビジー状態になっていない場合は、これらのノードの再クエリ オプションを使用することができます。

共有 ACD 回線サポート

Contact Center Enterprise ソリューションには、最大 2 台のデバイスに対する共有 ACD 回線のサポートが含まれます。このサポートによって、複数の場所にあるデバイスを含むエージェントが同じ内線番号を使用できるようになります。共有内線にログインする場合、エージェントはオフフックにするか、コールを送受信して、デバイスそのものを介してアクティブにするデバイスを選択します。アクティブなデバイスは、エージェントがコールに応答したり、Finesse デスクトップからコールを行った場合に使用されるデバイスです。ただし、その内線にコールが送信された場合、すべてのデバイスで呼出音が鳴るので注意してください。

Note

ACD 共有回線を使用する場合、UCM 自動応答はサポートされません。エージェントデスク設定の自動応答はサポートされていません。

E. 164 ダイヤル プラン設計

Unified CCE は E.164 ダイヤル プランをサポートしており、以下の通り「+」プレフィックスに部分的なサポートを提供します。

- エージェントの内線番号に「+」の文字を含めることはできません。

- エージェント周辺機器で「すべての行」エージェント制御が有効になっている場合、エージェントのセカンダリ回線に「+」文字を含めることはできません。

- VRU には、DN を CTI ルート ポイント経由で転送しない限り「+」プレフィックスを含めることはできません。

- ダイヤラがインポートした連絡先番号とキャンペーン プレフィックスに「+」プレフィックスを含めることはできません。

- エージェントは、Cisco Finesse デスクトップから E.164 番号を使用して「+」プレフィックスをダイヤルすることができます。

- エージェントは、電話から E.164 番号の「+」プレフィックスをダイヤルすることができます。

コンタクト センター外のエージェントの内線番号を通知するコンタクト センターでは、以下の事項が適用されます。

- 変換パターンを使用して、アウトバウンド コールのコール番号に「+」プリフィックスを追加します。電話機の設定には、発信者側の変換 CSS を使用することができます。

- 「+」プレフィックスを使用して着信コールを E メールで送信するには、変換パターンの「当事者変換」を使用して、コール先番号から 「+」プレフィックスを取り除きます。

- アテンダント コンソールに電話機のステータスを表示することはできません。

ポスト コール調査に関する考慮事項

コンタクト センターは通常、ポスト コール調査を使用してカスタマー エクスペリエンスに対する顧客満足度を測定します。たとえば、カスタマーがセルフサービスを使用して必要な情報を受け取ったか、あるいはエージェントによって快適なエクスペリエンスを得られたかなど。

ポスト コール調査（PCS）機能を使用すると、ポスト コール調査に関する入力を求める DNIS に発信者を転送するコール フローが有効になります。

VRU 処理は、発信者にポスト コール調査への参加について尋ねます。ポスト コール調査の要求に対して、発信者は次の 2 つの応答から選択できます。

1. 発信者が参加することを選択すると、エージェントが会話を終了した後に、発信者はコール フローによって自動的に調査コールに転送されます。

2. 発信者が参加を拒否した場合、Unified CCE スクリプトは ECC 変数を使用して、コール単位でポスト コール調査をオフにします。ECC 変数を n に設定することによって、コールが PCS DNIS に転送されなくなります。

レポートのために、ポスト コール調査コールは元の着信コールと同じ Call-ID およびコール コンテキストを持ちます。

- ポスト コール調査ユース ケース

- ポスト コール調査設計の影響

ポスト コール調査ユース ケース

通常、発信者に対してコール中に調査に参加するかどうかの確認が行われます。使用するソリューションは、ダイヤルされた番号に基いて決定し、コール終了時にポスト コール調査を呼び出すことができます。顧客がエージェントとの会話を完了すると、顧客は自動的に調査にリダイレクトされます。ポスト コール調査は、最後のエージェントの切断イベントによってトリガされます。

顧客は、プッシュホン電話機のキーパッドと ASR/TTS で音声を使用して、調査中の質問に応答できます。ソリューションの観点からは、ポスト コール調査コールは通常のコールと同じです。ポスト コール調査中に、元の顧客コールからコール コンテキスト情報が取得されます。

ポスト コール調査設計の影響

ポスト コール調査機能を設計する際は、以下の条件に準拠します。

- ポスト コール調査は、最後のエージェントの切断イベントによってトリガされます。エージェントが電話を切ると、コール ルーティング スクリプトは、調査スクリプトを起動します。

- ポスト コール調査番号への着信番号パターンのマッピングによって、コールのポスト コール調査機能がイネーブルなります。

- 拡張コール変数 user.microapp.isPostCallSurvey の値は、コールがポスト コール調査番号に転送されるかどうかを制御します。

- f user.microapp.isPostCallSurvey を y (暗黙のデフォルト) に設定した場合、コールはマッピングされたポスト コール調査番号に転送されます。

- user.microapp.isPostCallSurvey を n に設定すると、コールは終了します。

- 調査への着信番号パターンのすべてのコールをルーティングするには、スクリプトで user.microapp.isPostCallSurvey 変数を設定する必要はありません。変数は y にデフォルトで設定されます。

- ポスト コール調査では、REFER コール フローを使用できません。REFER コール フローは、コールから Unified CVP を削除します。ただし、そのエージェントはすでに切断されているため、コールによるアンケートには統合 CVP が必要です。

- Unified CCE レポートの目的で、ポーリング間隔コールは、初回コールのコールコンテキストを継承します。調査が開始されると、エージェントに転送されたカスタマー コールのコール コンテキストは、ポスト コール調査コールのコール コンテキストに複製されます。

Webex エクスペリエンス管理に関する考慮事項

Webex エクスペリエンス管理調査では、ポーリング間隔と同じスクリプトと通話フローを使用しています。ただし、クラウドベースのエクスペリエンス管理サービスによってアンケートが提供されていることを例外とします。呼び出される Call Studio 調査アプリケーションは、コールの調査区間で実行するルータ スクリプトで設定され、ECC 変数を使用して CVP に渡されます。Call Studio 調査アプリケーションは、エクスペリエンス管理サービスから質問を取り出し、発信者からの回答を収集して、REST API を介してそれらをエクスペリエンス管理サービスに送信します。

エクスペリエンス管理を構成し、次のチャネルをとおして調査を呼び出します。

- 音声

- 電子メール

- SMS

Note

音声調査は、既存のポーリング間隔およびエクスペリエンス管理を使用してトリガーできます。

次の図は、エクスペリエンス管理の調査機能を提供するソリューション コンポーネント間のプロトコルインターフェイスを示しています。

調査データの収集に加え、エクスペリエンス管理は、調査データの豊富なコンテキスト依存分析を提供します。分析ダッシュボードは、エージェントとスーパーバイザのデスクトップで表示できます。調査の各インスタンスを適切な顧客およびコールコンテキストに関連付けるため、CVP は、Cloud Connect を介してプロキシされる API を介してエクスペリエンス管理に対するコールの調査レグに、ANI のようなコールコンテキストおよび使用可能な顧客コンテキストを送信します。CVP は、コールの元のレグ間、GED-125 接続メッセージの CCE からコールとカスタマーコンテキスト情報を受信します。Cloud Connect は、エクスペリエンス管理 API を呼び出す際に必要な、安全なストレージをテナントログイン情報に提供し、エクスペリエンス管理サービスのステータスや遅延を監視する機能を提供します。

- エクスペリエンス管理コールフロー

- ネットワークに関する考慮事項

エクスペリエンス管理コールフロー

- エクスペリエンス管理音声調査

- エクスペリエンス管理電子メール/SMS による調査

エクスペリエンス管理音声調査

音声調査コールフロー

1. 着信通話中に、ICM ルーティングスクリプトがエージェントを割り当てると、ICM は関連付け先コールコンテキスト（エージェント ID、スキルグループ ID、チーム ID、チーム ID、および QuestionnaireId）を接続メッセージの CVP に送り返します。接続メッセージは、関連付けられた調査コールのコールコンテキストとして使用されます（ステップ 4）。

2. エージェントコールの終了時、CVP 構成された調査 DN に対して調査コールがトリガーされます。

3. 調査 DN は、関連付けられたルーティングスクリプトを実行する ICM のコールタイプに関連付けられます。

4. 関連付けられたルーティングスクリプトは、コールコンテキスト（エージェント ID、スキルグループ ID、チーム ID および DispatchId）と一緒に実行されるVXML アプリケーション（wxm）を含むスクリプトリクエストを返します。

5. VXML サーバは、Cloud Connect に getAuthToken() API コールを呼び出します。

6. Cloud Connect は、エクスペリエンス管理の組織のログイン情報（管理者のログイン情報と API キー）を使用して、getAuthToken() API を呼び出し、CVP VXML サーバに AuthToken を返します。

7. 次に、VCM サーバは、Cloud Connect から AuthToken を使用して getQuestionnaire() および getSettings() API コールを呼び出し（ステップ 6 で受信）、エクスペリエンス管理に ICM の調査名を呼び出します。

8. エクスペリエンス管理は、CVP VXML サーバに質問のリストを返します。

9. VXML サーバは、引き続き発信者に質問を求めます。

10. 発信者は、質問の入力を VXML サーバに送信します。

11. VXML サーバは、ステップ 4 で受信したユーザの回答とエージェントの詳細をエクスペリエンス管理に送信します。

Note

エクスペリエンス管理の音声調査を機能させるには

- VXML サーバをインターネットに接続する必要があります。インターネットへのダイレクトアクセスを有効にするか、VXML サーバで HTTP プロキシ設定を構成します。詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.html の「Cisco Unified Customer Voice Portal 向け構成ガイド」に記載されている『VXML サーバでの HTTP プロキシ設定の構成』の項を参照してください。

- VVB で TTS を構成するか、適切なオーディオによる指示をエクスペリエンス管理 PCS の調査設定にアップロードします。

エクスペリエンス管理電子メール/SMS による調査

電子メール/SMS 調査コールフロー

1. 着信通話中に、ICM ルーティングスクリプトがエージェントを割り当てると、ICM は関連付け先コールコンテキスト（エージェント ID、スキルグループ ID、チーム ID、チーム ID、および DispatchId）を接続メッセージの CVP に送り返します。接続メッセージは、関連付けられた調査コールのコールコンテキストとして使用されます（ステップ 3）。

Note

DispatchId は CVP コールサーバに対し、コールの終了後、電子メール/SMS を発信者に送り返す必要があるというメッセージを送信します。

2. エージェントコールの終了は、コールサーバ内の延期するポーリング間隔（電子メール/SMS の送信）ロジックをトリガーします。

3. CVP コールサーバは、リクエストを一括作成し、リクエストを DispatchId、CustomerId、電子メール、モバイル（ICM のステップ 1 で受信）を含む、Cloud Connect に送信し、Cloud Connect で、DispatchRequest() API を呼び出します。

4. Cloud Connect はエクスペリエンス管理で DispacthRequest() API コールを呼び出します。

エクスペリエンス管理の構成方法の詳細については、次の場所にある『Cisco Unified Contact Center Enterprise 機能ガイド』の「Webex のエクスペリエンス管理」の章を参照してください。https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html

ネットワークに関する考慮事項

エクスペリエンス管理音声調査：Cloud Connect、CVP VXML、Finesse Client はエクスペリエンス管理クラウドサービスにアクセスできる必要があります。

エクスペリエンス管理電子メール/SMS調査：Cloud Connect、Finesse Client はエクスペリエンス管理クラウドサービスにアクセスできる必要があります。

すべての Finesse クラスタは、エクスペリエンス管理ポータルで https://<finesse FQDN>:8445 にような形式の URL 許可リストに含まれなければなりません。

Webex エクスペリエンス管理デジタルチャネル調査に関する検討事項

Enterprise Chat and Email（ECE）は、ICM から ECC 変数を使用してデジタル調査構成と顧客による事前入力データを受信します。Cloud Connect 経由でプロキシされた REST API コールを使用して、エクスペリエンス管理からデジタルチャネル調査の調査データを取得します。これは、インライン電子メール応答またはチャットの最後にあるチャットウィンドウに調査 URL を埋め込みます。

次の図は、デジタルチャネル調査機能を提供するソリューション コンポーネント間のプロトコルインターフェイスを示しています。

デジタルチャネル調査アーキテクチャ

調査実行の各インスタンスを適切なカスタマーおよびエージェントに関連付けるため（転送の場合、調査はカスタマーとのやり取りでサイトの関与したエージェントに関連付けられます）、ECE は調査開始時に、カスタマー ID、電子メールおよびディレクトリ番号などの利用可能なカスタマーコンテキストをエクスペリエンス管理に送信します。

ECE は ECC 変数で CCE からカスタマーコンテキスト情報を受け取り、UCCE にあるインベントリ情報を使用して Cloud Connect への接続を確立します。Cloud Connect は、エクスペリエンス管理 API を呼び出す際に必要な、安全なストレージをテナントログイン情報に提供し、エクスペリエンス管理サービスのステータスや遅延を監視する機能を提供します。

- デジタルチャネル調査コールフロー

- ネットワークに関する考慮事項

デジタルチャネル調査コールフロー

この項では、デジタルチャネル調査のコールフロー情報を提供します。

- デジタルチャネル調査（電子メール/チャット）

デジタルチャネル調査（電子メール/チャット）

電子メール/チャットの調査コールフロー

1. ECE は、ICM に対して新しいタスク要求を開始します。

2. ICM ルーティングスクリプトは、エージェントにタスクを配分します。ICM は、関連付けられた電子メール/チャットコンテキスト（エージェント ID、テクニカル グループ ID、Cisco Webex Teams ID、質問者名、顧客 ID など）を送信し、エージェントにタスクを割り当します。

3. ECE が調査を開始すると 、getWXMSurveyURL() API が呼び出され、Cloud Connect から調査名と一緒に調査 URL が取得されます。

ECE は、getWXMSurveyURL() を呼び出す一方で、POD.ID の ICM から受け取ったカスタマーおよびエージェントコンテキストおよび user.CxSurveyInfo 変数を送信します。ICM が POD.ID でモバイルおよび電子メールアドレスを送信しない場合、ECE は、getWXMSurveyURL() を呼び出す一方で、モバイルおよび電子メールアドレスのデータベースを参照して、既存する場合は追加します。

4. Cloud Connect は、エクスペリエンス管理 getWXMSurveyURL () API を呼び出し、調査の質問を取得します。

5. ECE は、質問に関する調査の URL を受け取ります。

6. ECE は、次の調査 URL を使用して調査を開始します。

- 電子メール ー 調査 URL は、電子メール署名に埋め込まれています。

- チャット ー 調査は、チャット終了後にカスタマーに表示されます。

エンタープライズ チャットおよび電子メールの構成方法に関しては、https://www.cisco.com/c/en/us/support/contact-center/enterprise-chat-email-12-5-1/model.html を参照してください。

エクスペリエンス管理 の構成方法に関しては、の『Cisco Unified Contact Center Enterprise 機能ガイド』に記載されている「Webex エクスペリエンス管理デジタルチャネル調査」の章を参照してください。https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html

エージェントとスーパーバイザ用の Finesse デスクトップレイアウトにエクスペリエンス管理ガジェットを追加する方法の詳細については 、「Cisco Webex エクスペリエンス管理ガジェット」を参照してください。

ネットワークに関する考慮事項

- Cloud Connect および Finesse デスクトップブラウザは、エクスペリエンス管理クラウドサービスにアクセスできる必要があります。

- すべてのFinesseVMは、次の URL で（https://<finesse FQDN>:8445）でエクスペリエンス管理ポータルで許可されなければなりません。

Customer Journey Analyzer

Customer Journey Analyzer は、オンプレミス展開からコンタクトセンターの履歴データを処理し、特定のビジネスメトリックを生成します。トレンドが表示されることでパターンを特定し、継続的な改善に向けたインサイトを得るのに役立ちます。Customer Journey Analyzer で [放棄された連絡先（Abandoned Contacts）] ダッシュボードを表示すると、連絡先が放棄されている場所をスーパーバイザやビジネスアナリストが特定し、適切なアクションを実行できるようになります。顧客アクティビティレコードと顧客セッションレコードを使用して可視性を作成するために Customer Journey Analyzer を使用できます。

次のレポートは、[破棄された連絡先（Abandoned Contacts）] ダッシュボードの一部です。

レポートの詳細については、ダッシュボードの「オンラインヘルプ 」を参照してください。

- 放棄済み連絡先の合計

- 主な放棄理由

- コールバック / 更新されたチャット率

- カスタマージャーニー

- コンタクトの傾向

- ステージ別に放棄済みコンタクト

- 放棄済みコンタクトの詳細

Note

詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.htmlを参照してください。

この機能は、次の導入モデルでサポートされています。

1. Unified CCE 2000 エージェントの導入モデル。

2. Packaged CCE 2000 エージェント導入モデル。

3. Packaged CCE Lab 導入モデル。

- Customer Journey Analyzer のデータフロー

Customer Journey Analyzer のデータフロー

カスタマー ジャーニー アナライザのコールフロー

Cloud Connect により Cisco Unified CCE カスタマーは、Customer Journey Analyzer の Business Metrics などのクラウド機能を使用できます。Customer Journey Analyzer により、複数のデータソースおよびシステムから履歴データが採掘され、データの特定のビジネスビューが生成されます。トレンドが表示されることでパターンを特定し、継続的な改善に向けたインサイトを得るのに役立ちます。これらのビジネスメトリックを生成するために、エージェントアクティビティと連絡先（電話、チャット、電子メール）アクティビティレコードは Customer Journey Analyzer に公開されます。Cloud Connect コンポーネントは、Customer Journey Analyzer にデータを公開します。

Customer Journey Analyzer 向けデータセキュリティ

この機能のカスタマー ジャーニー アナライザは、次のデータが保護されています。

1. システム設定データ：

1. すべての構成情報は、安全な HTTPS 接続経由 Unified CCE Administration から REST APIs に転送されます。

2. Cloud Connect で使用されるユーザログイン情報は、マシンにキャッシュする前に暗号化されます。

2. カスタマー連絡先データ：安全な HTTPS 経由で、Call および Agent アクティビティレコードが、Analyzer に発行されます。

プレシジョン ルーティングに関する考慮事項

プレシジョン ルーティングは、スキル グループのルーティングに多次元の選択肢をもたらします。プレシジョン キューはプレシジョン ルーティングの主要コンポーネントです。Unified CCE のスクリプティングを使用すると、プレシジョン キューを動的にマッピングして、発信者の詳細なニーズに最も適したエージェントにコールを転送できます。プレシジョン キューは、式が設定されている 1 つ以上の手順から構成されており、これによってカスタマーは発信者の詳細なニーズを検出できます。

エージェントをプレシジョン キューに追加する必要はありません。エージェントはそれぞれの属性に基づいて自動的にプレシジョン キューのメンバーになります。ボストンのエージェントを必要とするプレシジョン キューを想定してください。そのエージェントは流ちょうなスペイン語を話し、特定の機器のトラブルシューティングに習熟している必要があります。属性として Boston = True、Spanish = True、Repair = 10 を持つエージェントが、プレシジョン キューに自動的に加わります。周辺機器についてサポートを必要としている、ボストン在住のスペイン語を話す発信者は、そのエージェントにルーティングされます。

プレシジョン ルーティングは、従来のルーティングを拡張するものであり、これに置き換わるものです。従来のルーティングでは、エージェントが属するすべてのスキル グループを調べ、ビジネス ニーズに対応するスキルの階層を定義します。ただし、従来のルーティングには 1 次元の性質による制限があります。

プレシジョン ルーティングは、簡単な設定、スクリプティング、およびレポートを使用した多次元のルーティングを提供します。各エージェントの能力が的確に示されるように、エージェントには習熟を示す複数の属性があります。これは、ビジネスにさらなる価値をもたらします。

ルーティング ニーズがあまり複雑でない場合、1 つまたは 2 つのスキル グループを使用することを検討してください。ただし、管理の容易な 1 つのキューに 10 もの能力レベルを含む検索を実施する場合は、プレシジョン キューを使用してください。

- プレシジョン ルーティング ユース ケース

- プレシジョン ルーティング

- プレシジョン ルーティング設計の影響

プレシジョン ルーティング ユース ケース

スキル グループとは異なり、プレシジョン キューは属性定義を分解し、属性レベルでエージェントのコレクションを形成します。プレシジョン キューの属性レベルに一致するエージェントは、そのプレシジョン キューに関連付けられます。

プレシジョン キューの場合、「English Sales」キューでは、「English」と「Sales」セールスの属性を定義し、これらの特徴を持つエージェントをこの属性に関連付けます。プレシジョン キュー「English Sales」は、この特徴を持つすべてのエージェントをプレシジョン キューにダイナミックにマップします。より複雑なスキル属性を定義して、エージェントに関連付けることもできます。これにより、英語の習熟度 = 10、営業の習熟度Sales Proficiency = 5など、複数の習熟度検索を単一のプレシジョン キューで作成することができます。

英語の販売キューをスキル グループと一致させるには、各属性に 1 つずつ、2 つの別々のスキル グループを設定します。プレシジョン キューを使用すると、エージェントを属性別に振り分けることができます。スキル グループでは、スキル グループを定義し、それにエージェントを割り当てます。

プレシジョン ルーティング

高レベルで、発信者がプレミアム メンバーであるかどうかを最初にチェックする 5 ステップの有効桁数のキューを想定してみましょう。

1. 属性：Skill > 8 - Consider If: Caller is Premium Member

2. 属性：Skill > 6

3. 属性：Skill > 4

4. 属性：Skill > 3

5. 属性：Skill > 1

プレミアム カスタマーではない発信者 John が、1-800-repairs にコールしたとします。システムは、このプレシジョン キューに John のコールを送信します。プレシジョン キューの動作は以下の通りです。

1. John はプレミアム カスタマーではないので、（手順 1 の Consider If により）ただちに手順 1 から手順 2 にルーティングされ、そこで応答を待ちます。

2. コールはステップ 2 に移動し、6 を超えるスキルを持つエージェントが、自分のコールに応答するまで John は待機します。

3. 手順 2 の待機時間が過ぎると、John のコールは手順 3 に移行してスキルが 4 以上のエージェントを待ちます。

4. 手順 3 の待機時間が過ぎると、John のコールは手順 4 に移行してスキルが 3 以上のエージェントを待ちます。

5. 手順 5 に到達すると、John のコールは対応可能なエージェントを無期限に待ちます。この手順以降のルーティング ロジックは存在しないため、この手順がすべてのコールに適用されます。

コールは、使用可能なエージェントのプールを拡張するために、後続の各ステップを実行します。最終的に、最後のステップに達すると、コールは潜在的なエージェントの最大プールを待ちます。追加の各手順では、コールに応答可能なエージェントが存在する可能性が高くなります。また、これにより、最も価値があり、スキルの高いエージェントを早めにプレシジョン キューの手順に入れることができます。後の手順でさほど適切でないエージェントに移動する前に、まずこういったエージェントにコールが届きます。

プレシジョン ルーティング設計の影響

- プレシジョン ルーティングの属性

- プレシジョン ルーティングの制限

- プレシジョン キュー変更時のスロットリング

プレシジョン ルーティングの属性

属性とは、言語や場所、エージェントの技能など、コール ルーティングの要件を識別するものです。各プレシジョン キューには 5 つまでの一意の属性があり、これらの属性は複数の項で使用することができます。ブール値および能力の 2 つのタイプの属性を作成することができます。ブール値属性を使用して、エージェントの属性値を true または false として識別します。習熟度属性を使用して、最低から最高まで 1 から 10 までのレベル技能レベルを指定します。

プレシジョン キューを作成する際は、そのキューの一部となる属性を識別して、そのキューをスクリプトに実装します。新しい属性をエージェントに割り当てると、属性値により、一致する条件を持つプレシジョン キューにエージェントが自動的に関連付けられます。

プレシジョン ルーティングの制限

有効桁数ルーティングは、CCE のエージェント PG でのみ使用することができます。

Cisco アウトバウンド オプションはプレシジョン ルーティングをサポートしていません。ただし、（キャンペーンを使用して）アウトバウンド キャンペーンまたは非音声アクティビティに参加するエージェントは、プレシジョン キューからのインバウンド コールも処理することができます。

プレシジョン キュー変更時のスロットリング

プレシジョン キューの設定更新 (API または Unified CCE 管理ツールからの) は、多くのエージェントによって、プレシジョン キューの関連付けが変更される可能性があります。これらの更新は、一度にすべての処理を実行すると、システムを過負荷にする可能性があります。したがって、システムは、利用可能なシステム リソースに基づいて、エージェントを プレシジョン キュー間で徐々に移動します。

前の更新が完了する前に、別の プレシジョン キュー設定の更新を送信することができます。更新の送信が速すぎると、新しい更新により保留中の構成の更新がシステムのキューに入れられる可能性があります。バックログ回避のために、5 つの保留中の更新が同時に実行された後に新しいプレシジョン キュー設定の更新をシステムは拒否します。保留中のプレシジョン キューの更新がしきい値を下回ると、システムは新しい設定の更新を受け入れます。

この操作中にエージェント周辺機器で発生する可能性のある過負荷状態を緩和するために、システムは過負荷状態中に周辺機器への呼び出しの数を制限します。過負荷が発生すると、システムはその周辺機器へのプレシジョン ルーティング呼び出しの送信を短時間停止します。

シングル サインオン（SSO）に関する考慮事項

シングル サインオン (SSO) 機能は、コンタクトセンター ソリューション アプリケーションおよびサービスへのエージェントおよびスーパーバイザ アクセスを認証および承認します。認証とは、ユーザの身元（「ユーザが主張どおりの本人であること」）を立証するプロセスです。承認とは、認証済みユーザに対してユーザが要求したアクションの実行を認めるプロセスです（つまり、「ユーザは要求したことを実行することができます」）。コンタクト センター ソリューションで SSO を有効にすると、ユーザは 1 回サインインするだけで、すべての Cisco ブラウザ ベースのアプリケーションおよびサービスにアクセスすることができます。SSO により Cisco Administrator アプリケーションにアクセスすることはできません。

SSO には以下が必要です。

- サードパーティのアイデンティティ プロバイダー（IdP）

- Cisco Identity Service (Cisco IdS) クラスタ

Note

SSO が有効に機能するように、Cisco IdS と IdP の時間を同期します。Cisco IdS と IdP の時間は、NTP サーバを使用して同期することを推奨します。

SSO 機能には、Security Assertion Markup Language 2.0（SAML v2）Oasis 標準に準拠した IdP が必要です。IdP はユーザ プロファイルを保存して認証サービスを提供し、SSO サインオンをサポートします。現在サポートされている ID プロバイダ製品のリストおよびバージョンについては、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.htmlで、ご使用のソリューションに応じた 互換性マトリクス を参照してください。

クラスタ Cisco IdS は、コンタクト センターソリューションの認証を管理します。個々の SSO 対応アプリケーションとサービスが承認を管理します。Cisco IdS クラスタは、パブリッシャとサブスクライバの冗長ペアです。パブリッシャではほとんどの管理タスクしか実行できませんが、いずれかのノードはアクセス トークンを発行または更新することができます。クラスタは、すべてのノード間で設定コードと承認コードの複製を行います。

SSO を使用できるユーザがサインインすると、Cisco IdS は、最初に ID プロバイダー（IdP）とやり取りしてユーザを認証します。ユーザが認証されると、Cisco IdS はアクセスが試みられている Cisco サービスを確認して、ユーザが要求されたロールに対して承認されていることを確認します。ユーザが認証および承認されると、Cisco IdS は、アプリケーションへのユーザのアクセスを許可するアクセス トークンを発行します。アクセス トークンを使用すると、ユーザは資格情報を再度提示することなく、そのセッションの承認済みのコンタクト センター アプリケーションを切り替えることができます。

Note

ユーザ クレデンシャルは IdP にのみ提示されます。コンタクト センター ソリューションのアプリケーションとサービスはトークンのみを交換します。ユーザの情報は確認しません。

SSO の詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html で提供される Cisco Unified Contact Center Enterprise 機能ガイドの SSO に関する章を参照してください。

- SSO コンポーネントのサポート

- SSO メッセージ フロー

- SSO の設計への影響

SSO コンポーネントのサポート

SSO をサポートするコンタクト センターのソリューション コンポーネントは以下の通りです。

- Unified CCE: エージェントおよびスーパーバイザのインターフェイス

- Cisco Finesse: エージェントおよびスーパーバイザのインターフェイス

- Cisco Unified Intelligence Center: エージェントおよびスーパーバイザのインターフェイス

- Customer Collaboration Platform— タスク ルーティング インターフェイス

- ビジネス チャットおよび E メール: Cisco Finesse の ECE ガジェットを使用したエージェントおよびスーパーバイザのインターフェイス

- Unified Contact Center Management Portal（Unified CCMP）

SSO メッセージ フロー

SSO では、セキュリティ アサーション マークアップ言語（SAML）を使用して、エンタープライズ ID プロバイダー（IdP）と Cisco IdSとの間で認証および許可の詳細を交換します。

ユーザーが SSO 対応サービスの Web ページを参照すると、認証要求はCisco IdSにリダイレクトされます。 Cisco IdS は、SAML認証要求を生成し、それをアイデンティティ プロバイダーに向けます。IdP は、ユーザに対してブラウザにサインイン ページを表示し、ユーザのクレデンシャルを収集します。IdP はユーザを認証すると、Cisco IdS に SAML アサーションを発行します。アサーションには、ユーザに関する信頼できるステートメントが含まれています。

SAML アサーションを受信すると、Cisco IdS は Open Authorization (OAuth) プロトコルを使用して、要求されたサービスとの認証を完了します。サービスは、特定のリソースを有効にするために承認ページをユーザに提示することができます。

認証プロバイダーにユーザ クレデンシャルを提示している間にだけ、SAML と OAuth によるユーザの認証が可能になります。ユーザ名とパスワードは IdP にのみ提示されます。コンタクト センター ソリューションのアプリケーションとサービスはユーザ情報を確認しません。SAML アサーションと OAuth トークンのみが交換されます。

SSO の設計への影響

- シングル サインオン サポートおよび制限

- シングル サインオン向け Contact Center Enterprise リファレンス設計サポート

- レファレンス設計による Cisco Identity Service の共存

- SSO 向けリファレンス設計トポロジー サポート

- SSO 向けユーザ管理

- 修飾 ID プロバイダー

シングル サインオン サポートおよび制限

SSO のサポートに関連する以下の点を考慮に入れます。

- SSO をサポートするために、企業のソリューション全体で HTTPS プロトコルを有効にします。

- SSO は、エージェントとスーパーバイザのみをサポートします。このリリースでは、管理者は SSO サポートを利用できません。

- SSO は、フェデレーション信頼を備えた複数のドメインをサポートします。

- SSO では、コンタクト センターのエンタープライズ周辺機器のみがサポートされています。

- SSO サポートは、グローバル展開のリモートまたはメインサイト PG に登録されているエージェントとスーパーバイザが利用することができます。

SSO のサポートに関連する以下の制限事項を考慮します。

- SSO サポートは、サード パーティ 自動着信分配装置（ACD）は利用できません。

- SSO 機能は Cisco Finesse IP Phone Agent (FIPPA) をサポートしていません。

- SSO 機能は、Cisco Finesse デスクトップ チャット をサポートしていません。

- ハイブリッドモード、

- SSO モードのエージェントが CUIC にログインを試み、そのエージェントが CUIC に存在しない場合、エージェントは CUIC にログインできません。

- SSO モードのスーパーバイザが CUIC にログインを試み、スーパーバイザユーザが CUIC に存在しない場合、スーパーバイザは CUIC にログインできません。スーパーバイザが CUIC にログインするには、Unified CCE ユーザ統合を実行します。Unified CCE ユーザ統合の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-intelligence-center/products-maintenance-guides-list.html の『Cisco Unified Intelligence Center 向け管理コンソールユーザガイド』を参照してください。

シングル サインオン向け Contact Center Enterprise リファレンス設計サポート

Unified CCE では、以下のレファレンス設計に対するシングル サインオンがサポートされています。

- 2000 エージェント

- 4000 エージェント

- 12000 エージェント

- 24,000 人のエージェント

- コンタクトディレクター（最大 24000 エージェント、各対象システムには、専用のCisco IdS 展開を含める必要があります）。

レファレンス設計による Cisco Identity Service の共存

リファレンス設計

Unified CCE

2000 エージェント

Cisco IdS は、1 つの VM に対して、Unified Intelligence Centerとライブ データを使用して、corin ident とします。

4000 エージェント

スタンドアロン Cisco IdS VM

12000 エージェント

スタンドアロン Cisco IdS VM

24000 エージェント

スタンドアロン Cisco IdS VM

SSO 向けリファレンス設計トポロジー サポート

展開トポロジは、データ センター VM のインストール場所と サイトのリストに追加します へのエージェントの接続方法で構成されます。SSO は、以下のリファレンス設計トポロジのコンポーネントでサポートされています。

- 集中型: 同じ サイトで両側の冗長コンポーネントをホストします。

同じ LAN 上にある場合でも、両側のコンポーネント間の最大ラウンドトリップ時間は 80 ms となります

- 分散型: 異なる地理的 サイトのリストに追加しますに冗長コンポーネントを片側ずつホストします。

両側のコンポーネント間の最大ラウンドトリップ時間は 80 ms です。

- グローバル: メイン サイト と単一または複数のリモート サイトに展開されています。

メイン サイト と リモート サイト 間の最大ラウンド トリップ時間は 400 秒です。

リモート エージェントでシングル サインオンを使用するには、サポートされるリモート オフィス オプションのいずれかを使用します。

- エージェントを配備したオフィス

- エージェントとローカル トランクを備えたリモート オフィス

- Cisco Virtual Office を備えたホーム エージェント

- Unified Mobile Agent

リモート オフィスと メイン サイト 間の最大許容ラウンドトリップ時間は 200 ミリ秒 です。

SSO 向けユーザ管理

Unified CCE の管理では、システムに対して以下の 3 つの異なる SSO モードを選択することができます。

- SSO：このモードでは、すべてのエージェントとスーパーバイザに対して SSO が有効になります。

すべてのユーザは、認証と承認に ID を使用してログインします。

- 非 SSO：このモードでは、すべてのエージェントとスーパーバイザの SSO が無効になります。

すべてのユーザは、既存の Unified CCE ローカル認証と Active Directory を使用してログインします。

- ハイブリッド: SSO 対応と非 SSO の両方のユーザをサポートしています。ハイブリッド モードでは、Unified CCE Configuration Manager ツールを使用して個々のユーザの SSO モードを設定します。各ユーザは、設定された方法を使用してサインインします。

既存の展開で SSO を有効にする場合、ハイブリッド モードを使用して、他のエージェントがローカル認証を継続して使用してエージェントを SSO に段階的に移行します。

Contact Center Enterprise ユーザのログイン名は、IdP で設定した Cisco IdS の SAML 要求ルールと一致しなければなりません。

- 単一のドメイン展開の場合、ログイン名はシンプルなユーザ ID またはメール形式 (user@cisco.com) のサインイン名である場合があります。

- 複数のドメイン展開の場合、ログイン名は E メール形式である必要があります。ユーザのログイン名が単純なユーザ IdS の場合、Unified CCE データベースのエージェントの LoginName は E メール形式で設定します。

Unified CCE Administration バルク設定ツールには、SSO 移行ツールが提供されています。エージェントとスーパーバイザのグループを SSO アカウントに移行して、必要があればこのツールでユーザ名を変更することができます。このツールは、SSO アカウントに移行されていないエージェントおよびスーパーバイザのレコードを含むコンテンツ ファイルをダウンロードします。コンテンツ ファイルで、既存のエージェントとスーパーバイザの SSO ユーザー名を指定して、ファイルを送信します。ユーザー名を更新すると、データベース内のログイン名も更新され、ユーザは自動的に SSO を有効にします。

修飾 ID プロバイダー

以下の表に一覧されている IdP 以外の ID プロバイダー（IdP）を使用する場合、IdP が SAML 2.0 に準拠しており、後続の SAML 要求および応答セクションで説明される以下の要件を満たす限り、Cisco IdS は IdP をサポートします：

- SAML 要求の属性

- SAML レスポンスからの期待

- IdP メタデータ スキーマ

- SAML 要求の属性

- SAML レスポンスからの期待

IdP メタデータ スキーマ

IdS を設定して、Cisco Identity Service（IdS）と ID プロバイダー（IdP）の間でメタデータを交換する場合、IdP メタデータ ファイルが以下の場所で SAML メタデータ スキーマを確認する必要があります。

https://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd

SAML 要求の属性

- SAML 要求は、以下の SAML 2.0 バインドをサポートしています。 HTTP-POST バインド

- SAML 要求での NameIDFormat は urn:oasis:names:tc:SAML:2.0:nameid-format:transientでなければなりません

- SAML 要求は、システムで構成された値に従って SHA-128 あるいは SHA-256 を使用して署名することができます。

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="s25f4fb66688cf429e430034f4cceac00b6124570d" Version="2.0"
IssueInstant="2018-10-29T10:01:39Z" Destination="https://win-adfs30-151.uccxteam.com/adfs/ls/"
ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://ccxssodemo1.cisco.com:8553/ids/saml/response">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ccxssodemo1.cisco.com</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
SPNameQualifier="ccxssodemo1.cisco.com" AllowCreate="true"></samlp:NameIDPolicy>
</samlp:AuthnRequest>

SAML レスポンスからの期待

SAML レスポンスからの期待:

- SAML 応答全体（メッセージおよびアサーション）が署名されるか、メッセージのみが署名されます。SAML アサーションは単独では署名されません。

- SAML アサーションは暗号化してはなりません。

- SAML 要求は、システムで構成された値に従って SHA-128 あるいは SHA-256 を使用して署名しなければなりません。

- SAML 返答での NameIDFormat は urn:oasis:names:tc:SAML:2.0:named-format:transientでなければなりません

- uid および user_principal 属性は、AttributeStatement セクションの SAML アサーションに存在する必要があります。

「uid」属性値は、SSO が有効な Cisco コンタクト センター アプリケーションにログインするユーザー ID を使用する必要があり、「user_principal」属性値は uid @ domain 形式である必要があります。

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://ids-ssp-node.cisco.com:8553/ids/saml/response"
ID="_6a309495-d3c2-4a28-b8e3-289f8f5355bd" InResponseTo="s21c84ba20862f573f5daec121c305ba6aac877843"
IssueInstant="2017-08-10T13:20:26.556Z" Version="2.0">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://ADFSServer.cisco.com/adfs/services/trust
</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_6a309495-d3c2-4a28-b8e3-289f8f5355bd">
..........
</ds:Reference>
</ds:SignedInfo>
..........
..........
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_df3bdbcf-a225-4e97-b00a-a199bdda3d2c"
IssueInstant="2017-08-10T13:20:26.556Z" Version="2.0">
<Issuer>http://ADFSServer.cisco.com/adfs/services/trust</Issuer>
.............

.............
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="http://ADFSSserver.cisco.com/adfs/services/trust"
SPNameQualifier="ids-ssp-node.cisco.com">CISCO\Admin121</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData
InResponseTo="s21c84ba20862f573f5daec121c305ba6aac877843"
NotOnOrAfter="2017-08-10T13:25:26.556Z"
Recipient="https://ids-ssp-node.cisco.com:8553/ids/saml/response" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2017-08-10T13:20:26.556Z"
NotOnOrAfter="2017-08-10T14:20:26.556Z">
<AudienceRestriction>
<Audience>ids-ssp-node.cisco.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="user_principal">
<AttributeValue>Admin121@cisco.com</AttributeValue>
</Attribute>
<Attribute Name="uid">
<AttributeValue>Admin121</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2017-08-10T13:18:12.086Z"
SessionIndex="_df3bdbcf-a225-4e97-b00a-a199bdda3d2c">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

ウィスパー アナウンスメントに関する考慮事項

ウィスパー アナウンスメントは、エージェントが各発信者に接続する直前に、あらかじめ録音されている短いメッセージをエージェントに対して再生します。アナウンスメントを使用することにより、エージェントをコールのタイプにただちに順応させます。アナウンスメントはエージェントにのみ再生されます。アナウンスメントの再生中、発信者には呼び出し音が聞こえます。

- ウィスパー アナウンスメント コール フロー

- ウィスパー アナウンスメント設計の影響

ウィスパー アナウンスメント コール フロー

ウィスパー アナウンスメント コール フロー

ウィスパー アナウンスメントの標準コール フローは以下の通りです。

1. 着信コールがキャリアから CVP に到着します。

2. CVP は、Unified CCE にコールを送信します。

3. Unified CCE は、CVP にコールのキューに入るよう指定します。

4. CVP は、音声ブラウザにコールを送信します。

5. Unified CCE は、ウィスパーアナウンスメント プロンプトと一緒にエージェントラベルを送信します。

6. CVP は、着信コールを Unified CCE に送信します。

7. Unified CM は、エージェントの電話にコールを送信します。

8. 発信者には呼び出し音が継続して聞こえます。エージェントはウィスパー アナウンスメントを聞きます。

9. ウィスパー アナウンスメントが終了すると、 発信者はエージェントにつながれます。

ウィスパー アナウンスメント設計の影響

ウィスパー アナウンスメントには以下の制限があります。

- エージェントが行ったアウトバウンド コールのアナウンスは再生されません。アナウンスメントはインバウンド コールに対してのみ再生されます。

- ウィスパー アナウンスメントがエージェント間コールで機能するには、コールをエージェントに転送する前に SendToVRU ノードを使用します。別のエージェントにコールを転送する前に、Unified CVP にコールを転送します。次に、Unified CVP は、コールを Unified CVP に転送するノードに関わらず、コールを制御して、アナウンスを再生することができます。

- ルータがラベル ノードを介してエージェントを選択する際は、アナウンスは再生されません。

- CVP Refer 転送は、ウィスパー アナウンスメントをサポートしていません。

- ウィスパー アナウンスメントではサイレント モニタリングがサポートされます。ただし、Unified Communications Manager ベースのサイレント モニタリングの場合、スーパーバイザはアナウンス自体は聞くことができません。スーパーバイザのデスクトップは、アナウンスが再生される間、サイレント モニタ ボタンをグレー表示します。

- コール毎に再生できるアナウンスは 1 つだけです。アナウンスが再生されている間、コールを保留、転送、または会議、コールのリリース、または監督者の支援要求はできません。アナウンス終了後に上記の機能が利用できるようになります。

- ウィスパー アナウンスメントの録音とエージェントの電話機のコーデック設定は一致していなければなりません。たとえば、ウィスパー アナウンスメント が G.711 ALAW で録音されている場合、電話機も G.711 ALAW でなければなりません。ウィスパー アナウンスメントが G.729 で録音されている場合、電話機は、G.729 をサポートするか、使用していなければなりません。

- IPv6 対応の環境では、ウィスパー アナウンスメントには追加のメディア ターミネーション ポイント（MTP）が必要です。

- ウィスパー アナウンスメント メディア ファイル

- 転送および会議でのウィスパー アナウンスメント

- ウィスパー アナウンスメントのサイジングに関する考慮事項

ウィスパー アナウンスメント メディア ファイル

Unified Contact Center Enterprise（Unified CCE）メディアサーバのウィスパーアナウンスメント音声ファイルを保存し提供します。この機能では、wave (.wav) ファイル タイプがサポートされています。ウィスパー アナウンスメントの最大再生時間は、タイムアウトに依存します。実際の音声ファイルの長さに関わらず、タイムアウトになると再生は終了します。タイムアウトは 15 秒です。実際には、コール処理時間を短縮するために、メッセージをそれよりもはるかに短くする必要があります（5 秒以下）。

転送および会議でのウィスパー アナウンスメント

エージェントが別のエージェントに電話会議を転送または開始する際、2 人目のエージェントの番号がウィスパー アナウンスメントをサポートしている場合、2 人目のエージェントはアナウンスを聞きます。コンサルタティブ転送または会議の場合、アナウンスが再生されている間、発信者には通常保留中に再生される音声が聞こえます。1 人目のエージェントが着信音を聞きます。ブラインド転送の場合、発信者にはアナウンスの再生中に呼び出し音が聞こえます。

ウィスパー アナウンスメントのサイジングに関する考慮事項

ウィスパー アナウンスメントのソリューション コンポーネントのサイズ設定への影響は、エージェント グリーティングによる影響ほど重大ではありません。

Chapter 9. 帯域幅、遅延、および QoS に関する考慮事項

- コア コンポーネントの帯域幅、遅延、および QoS

- オプションのシスココンポーネントの帯域幅、遅延、および QoS

- オプションのサードパーティ コンポーネントの帯域幅、遅延、および QoS

コア コンポーネントの帯域幅、遅延、および QoS

- コアコンポーネントによる帯域幅の使用例

- イングレス、イーグレス、および VXML ゲートウェイの帯域幅、遅延、および QoS

- Unified CVP の帯域幅、遅延、および QoS

- Unified CCE の帯域幅、遅延、および QoS

- 仮想化音声ブラウザの QoS

- Unified CM の帯域幅、遅延、および QoS

- Cisco Finesse の帯域幅、遅延、および QoS

- Unified Intelligence Center の帯域幅、遅延、および QoS

- シスコライブデータの帯域幅、遅延、および QoS

- Cisco IdS の帯域幅に関する検討事項

コアコンポーネントによる帯域幅の使用例

この表は、テスト環境のコアコンポーネントによる帯域幅の使用例を示しています。

帯域幅使用の例

Unified CCE Components

パブリックネットワークの帯域幅（KBps）

プライベートネットワークの帯域幅（KBps）

動作条件

ピーク

平均

第 95 パーセンタイル

ピーク

平均

第 95 パーセンタイル

特大規模ライブデータ

44875

12546

21134

該当なし

該当なし

該当なし

24000 SSO エージェント 105 CPS（転送 10%、会議 5% を含む）、ECC: 5 スカラー @ 各 40 バイト、最大クエリ負荷時 200 人のレポートユーザ。

ルータ

2307

1189

1173

1908

1048

1024

12,000 エージェント、105 CPS（転送 10%、会議 5% を含む）、ECC：5 スカラー @ 各 40 バイト、最大クエリ負荷時 200 人のレポートユーザ

Logger

14624

2696

8718

12351

2184

7795

AW-HDS

4113

1522

3215

該当なし

該当なし

該当なし

HDS-DDS

3323

512

1627

該当なし

該当なし

該当なし

Cisco Identity サーバ（IdS）

35

26

33

該当なし

該当なし

該当なし

大規模ライブデータ

47073

6018

8079

該当なし

該当なし

該当なし

Rogger

6410

2314

3498

5875

1987

3185

4,000 エージェント、30 CPS、ECC、5 スカラー @ 各 40 バイト、最大クエリ負荷時 200 レポートユーザ

AW-HDS-DDS

4891

2476

3651

該当なし

該当なし

該当なし

Cisco Identity サーバ（IdS）

112

88

105

該当なし

該当なし

該当なし

小規模ライブデータ

25086

3998

5487

該当なし

該当なし

該当なし

Rogger

2561

1040

1338

2141

789

1443

2,000 エージェント、15 CPS、ECC、5 スカラー @ @ 各 40 バイト、最大クエリ負荷時 200 レポートユーザ。

AW-HDS-DDS

4014

2881

3174

該当なし

該当なし

該当なし

CUIC-LD-Ids

105544

8496

10236

該当なし

該当なし

該当なし

中規模 PG

12012

7702

10486

8795

6478

7846

CUIC

10620

4351

7947

該当なし

該当なし

該当なし

Finesse

18449

16125

17381

該当なし

該当なし

該当なし

CVP Call/VXML

2198

2141

2196

該当なし

該当なし

該当なし

CVP レポート

2008

1980

2004

該当なし

該当なし

該当なし

イングレス、イーグレス、および VXML ゲートウェイの帯域幅、遅延、および QoS

音声ブラウザと CVP VXML サーバ間のネットワーク遅延は、200 ミリ秒 RTT を超すことはできません。グローバル展開を使用すると、必要な遅延を維持できます。

Unified CVP の帯域幅、遅延、および QoS

- Unified CVP および VVB の帯域幅に関する考慮事項

- Unified CVP に関するネットワークリンクに関する考慮事項

- 帯域幅のサイジング

- ネットワーク遅延

- Unified CVP のポート使用量と QoS 構成

- WAN の帯域幅のプロビジョニングと QoS に関する考慮事項

Unified CVP および VVB の帯域幅に関する考慮事項

イングレスゲートウェイおよび音声ブラウザは、メディアファイル、VXML ドキュメントおよび呼制御シグナリングを提供するサーバとは別に分離されています。これらの要因により、Unified CVP 帯域幅の要件が発生します。

たとえば、すべてのコールに 1 分間の VRU 処理があり、エージェントへの 1 回の転送が 1 分間あるとします。各ブランチには 20 人のエージェントがいます。各エージェントが 1 時間に 30 コールを処理する場合、ブランチでは 1 時間あたり 600 コール処理することになります。コール平均レートは、ブランチあたり 0.166 コール/秒（CPS）です。

これら変数で小さな変更があったとしてもサイジングには大きな影響となる場合があります。1 秒当たり 0.166 コールが 1 時間の平均となります。通常、コールは 1 時間全体で均一に到着するわけではなく、ビジーな時間帯で山と谷があります。外部要因は、コールの量にも影響します。たとえば、エアラインなどの事業では、悪天候が原因でコールの量が増加しますし、プロモーションがあれば、小売業者でのコールの量が増加します。ビジネスで最も多いトラフィック期間を見つけ、最悪のシナリオに基づいてコール到着率を計算します。

VXML ドキュメント

発信者に再生されるプロンプトごとの VXML ドキュメントが生成されます。このドキュメントは、Unified ICM スクリプトと Cisco Unified Call Studio のいずれかまたは両方を使用して記述した音声アプリケーションスクリプトに基づいて生成されます。VXML ドキュメントのサイズは、使用するプロンプトのタイプに応じて異なります。たとえば、複数選択があるメニュープロンプトは、アナウンスメントのみを再生するプロンプトよりもサイズは大きくなります。

Note

コールサーバまたは VXML サーバ用の VXML ドキュメントおよびゲートウェイの概算サイズは、7 KBです。

帯域幅は次の方法で計算できます。

プロンプトによって推定される帯域幅

ブランチオフィスの帯域幅は次のように推定できます。

CPS * Bits per Prompt * Prompts per call = Bandwidth in bps

前に挙げた、7 KBの VXML ドキュメントの例について考えてみましょう。

7,000 bytes * 8 bits/byte = 56,000 bits per prompt
(0.166 calls/second) * (56,000 bits/prompt) * (Number of prompts / call) = bps per branch

VXML ドキュメントによって推定される帯域幅

次の表にリストされている VXML ドキュメントのサイズを使用して、必要な帯域幅を計算します。次の表のドキュメントのサイズは、VXML サーバから音声ブラウザに対して測定されます。

VXML ドキュメント タイプの概算サイズ

VXML ドキュメント タイプ

推定サイズ（バイト単位）

ルートドキュメント（コールの開始時に必要なもの）

19,000

Subdialog_start（コールの開始時、少なくともコールごとに 1 つ必要）

700

Call-ID および GUID のゲートウェイのクエリー（コールごとに必要）

1300

メニュー（メニューの選択肢の数によってサイズが増大）

メニューの選択肢ごとに 1000 + 2000

通知の再生（単純な .wav ファイル）

1100

クリーンアップ（コール終話に必要なもの）

4000

Note

より複雑な解決策については、プロンプトによる必要な帯域幅の推定値よりも、この 2 番目のメソッドの方がより正確な推定値を出すことができます。

メディア ファイルの取得

メディアファイルまたは プロンプトは、ローカルでIOS 音声ゲートウェイ向けのフラッシュメモリや Cisco VVB 向けファイルシステムに保存できます。メディアファイルをローカルに保存すると、帯域幅の考慮事項がなくなります。ただし、すべてのルータまたは VVB で変更を要求するプロンプトを置き換える必要があるため、これらのプロンプトを維持することは難しいです。HTTP メディアサーバ（または HTTP キャッシュエンジン）上でこれらのプロンプトをローカルに保存すると、ゲートウェイは取得後に音声プロンプトをローカルにキャッシュできます。HTTP メディアサーバは、プロンプトの数とサイズに応じて複数のプロンプトをキャッシュできます。プロンプトの更新期間は HTTP メディア サーバで定義されます。帯域幅の使用量は、各ゲートウェイでのプロンプトの初期ロードに制限されます。これには、更新間隔の有効期限後の定期的な更新も含まれます。

Note

VVB では HTTP キャッシュを無効にすることはできません。

VXML ゲートウェイでプロンプトをキャッシュしない場合、次に大きな影響が出る場合があります。

- Cisco IOS のパフォーマンスが 35 ～ 45% 低下。

- 追加の帯域幅が必要。たとえば、平均サイズが 50 KB で、更新間隔が 15 分の 50 のプロンプトがある場合、平均帯域幅の使用率は次のようになります。

(50 prompts) * (50,000 bytes/prompt) * (8 bits/byte) = 20,000,000 bits
(20,000,000 bits) / (900 second) = 22.2 kbps per branch

Note

VVB の帯域幅に関する検討事項には、G.711 および G.729 音声トラフィックに関する VXML ドキュメント、メディアファイル取得、RTP ストリームの帯域幅が含まれます。

Unified CVP に関するネットワークリンクに関する考慮事項

Unified CVP の場合、WAN および LAN トラフィックを音声トラフィック、呼制御トラフィック、およびデータトラフィックにグループ化できます。

音声トラフィック

音声コールは Real-time Transport Protocol（RTP）パケットで構成されます。これらのパケットには次に送信される音声サンプルが含まれます。

- PSTN イングレスゲートウェイまたは WAN または LAN 接続を介した発信 IP 電話と、次のいずれかとの間では…

- 別の IP 電話がイングレスゲートウェイまたはコール IP 電話と併置されているかどうか（同じ LAN 上にあるかどうか）。

- TDM ACD 用のフロントエンドのエグレスゲートウェイ（レガシー ACD または VRU 用）。エグレスゲートウェイは、イングレスゲートウェイと併置されていない場合と、併置されている場合があります。

- プロンプト/コレクト処理を実行する音声ブラウザ。音声ブラウザは、同じまたは異なるイングレスゲートウェイにすることができます。いずれの場合も、イングレスゲートウェイと音声ブラウザは併置します。

- 音声ブラウザと ASR または TTS サーバ間。音声ブラウザと ASR/TTS サーバ間の RTP ストリームは G.711 である必要があります。

SIP を使用した呼制御トラフィック

Unified CVP は、Cisco IOS 音声ゲートウェイと Unified Communications Manager の 3 種類の VoIP エンドポイントで呼制御モードまたはシグナリングモードで動作します。呼制御トラフィックは、次のエンドポイント間で WAN または LAN を通してフローします。

- コールサーバおよび IME 除外グループ — 着信通話は、Unified CM、Cisco IOS 音声ゲートウェイまたは別の SIP デバイスから着信します。

- コールサーバおよび発信電話 — 発信電話は、Unified CM、Cisco IOS 音声ゲートウェイから発信されます。エグレスゲートウェイは、プロンプト/コレクト処理を発信者に提供する VXML ゲートウェイです。また、エージェント（Unified CCE または TDM）またはレガシー TDM VRU への転送の対象にもなっています。

VRU PG を使用した呼制御トラフィック

コールサーバと Unified CCE VRU PG は、GED-125 プロトコルを使用して通信します。GED-125 プロトコルには、次の機能があります。

- コールが到着したときに発信者エクスペリエンスを制御する通知メッセージ。

- 発信者を転送または切断する指示。

- 発信者エクスペリエンスに対する VRU 処理を制御する指示。

VRU PG は、LAN 接続を介して Unified CVP に接続します。ただし、WAN を介したクラスタリングを使用する展開では、Unified CVP を WAN 全体で冗長の VRU PG に接続できます。

セントラルコントローラと VRU PG 間の帯域幅は、VRU PG と Unified CVP 間の帯域幅と同様です。

冗長 VRU PG ペアが WAN で分割されている場合、合計帯域幅は 2 倍になります。セントラルコントローラから VRU-PG への接続では、報告された帯域幅が必要です。VRU-PG から Unified-CVP への接続には同量の帯域幅が必要です。

メディアリソース制御プロトコルトラフィック

VXML ゲートウェイとシスコ仮想化音声ブラウザは、メディアリソース制御プロトコル（MRCP）v1.0 および v2 の両方を使用して ASR/TTS サーバと通信します。このプロトコルにより、Nuance などの ASR/TTS サーバへの接続が確立されます。接続は、LAN または WAN 経由で確立できます。

Note

シスコは、WAN 環境の音声アプリケーションをテストまたは適格確認していません。設計のガイドライン、WAN でのサポートおよび関連する警告については、各ベンダー専用マニュアルを参照してください。TAC は、音声アプリケーションに関連した問題について（サードパーティの相互運用性認定製品の場合と同様に）限定されたサポートを提供しています。

セントラルコントローラから VRU PG トラフィック

セントラルコントローラと VRU PG 間の通信用のサイジングツールはありません。ただしセントラルコントローラと IP IVR PG 間の帯域幅を見積るツールを使うと、1 つの値を置き換えた場合、Unified CVP の正確な測定値が生成されます。

[RUN VRU SCRIPTノードの平均数（Average number of RUN VRU SCRIPT nodes）] フィールドでは、Unified CVP と対話する Unified CCE スクリプトノードの数を代入します。Unified CVP と対話できるノードは次のとおりです。

- 外部スクリプト実行

- ラベル

- 戻り可能ラベル

- スキルグループへのキューイング

- エージェント キューイング

- エージェント

- リリース

- VRU 転送

- VRU トランスレーション ルート

接続は、WAN または LAN を介して確立できます。

データ トラフィック

データトラフィックには、HTTP リクエストの結果として返される VXML ドキュメントと事前録音されたメディアファイルが含まれます。音声ブラウザは、次のリクエストを実行します。

- Media File サーバに対する HTTP リクエスト内のメディアファイル — Media File サーバ応答は、HTTP メッセージの本文でメディアファイルを返します。音声ブラウザは、メディアファイルを Real-time Transport Protocol（RTP）パケットに変換し、それを発信者に再生します。接続は、WAN または LAN を介して確立できます。

- CVP サーバからの VXML ドキュメント — この場合、接続は WAN または LAN 経由で確立できます。

帯域幅のサイジング

一般的に、分散型トポロジは、Unified CVP に対して最も帯域幅を集中的に消費します。イングレスゲートウェイおよび音声ブラウザは、メディアファイル、VXML ドキュメントおよび呼制御シグナリングを提供するサーバとは別に分離されています。

Note

すべての呼び出しの前の例に、1 分間の VRU 処理と、1 分間のエージェントへの 1 回の転送があるという例を思い出してください。各拠点には 20 のエージェントが存在し、各エージェントは 1 時間当たり 30 コールを処理するため、拠点ごとに 1 時間当たり合計 600 のコールが処理されます。コール平均レートは、ブランチあたり 0.166 コール/秒（CPS）です。

SIP シグナリング

SIP とは、VoIP ネットワークなどのマルチメディア通信セッションを制御するためのテキストベースおよびシグナリング通信プロトコルです。また、SIP を使用して、メディアストリームからなるセッションを作成、変更、終了できます。SIP セッションには、インターネット電話の通話、マルチメディアの流通、マルチメディア会議などがあります。SIP は、ツーパーティ（ユニキャスト）またはマルチパーティ（マルチキャスト）セッションに使用できます。

通常の SIP コールフローでは、コールごとに約 17,000 バイトが使用されます。1 秒ごとのコールに基づいた前述の帯域幅の数式を使用すると、平均の帯域幅使用量は次のようになります。

(17,000 bytes/call) * (8 bits/byte) = 136,000 bits per call
(0.166 calls/second) * (136 kilobits/call) = 22.5 average kbps per branch

G.711 および G.729 音声トラフィック

Unified CVP は、G.711 と G.729 の両方のコーデックをサポートします。ただし、所定のコールでのコール レッグおよびすべての VRU は、同じ音声コーデックを使用する必要があります。音声認識では、ASR/TTS サーバが G.711 のみをサポートします。音声 RTP ストリームの詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の「シスコ コラボレーション システム ソリューション リファレンス ネットワーク 設計（SRND）」を参照してください。

ネットワーク遅延

適切なアプリケーション帯域幅と QoS ポリシーが展開されたら、分散型 CVP 展開のネットワーク遅延を検討します。十分なネットワーク帯域幅がある場合、遅延の主な要因は、音声ブラウザと コールサーバまたは VXML サーバ間の距離となります。分散型 CVP 展開では、遅延を最小限に抑え、ソリューションのパフォーマンスに効果を発揮します。

ネットワーク遅延は、次の方法で分散 CVP 導入に影響します。

- これは、ネットワーク遅延が、CVP コンポーネント間である場合、エンドユーザの通話エクスペリエンスに影響します。コールサーバと音声ゲートウェイ間の SIP によるコールシグナリングの遅延は、コールの設定時間に影響します。遅延は、この設定中に無音の期間を追加する可能性があります。これには、最初のコール設定、最終的なコールフローの一部である後続の転送や会議などがあります。

- VXML アプリケーション ドキュメントのダウンロード時間に大きく影響し、発信者の最終的なエクスペリエンスに著しく影響します。

次のシステム設定の変更により、VXML サーバから音声ブラウザが地理的に分離されるなど、WAN の遅延が軽減されます。

1. 無音期間中に音声を発信者に提供します。

次の設定は、発信者が切断しないように、通話中断時に折り返し電話と音声を提供します。

- VRU での通常の通話設定時間よりも長い折り返し電話音を追加するには、存続可能性サービスで wan-delay-ringback を 1 に設定します。

- VRU サブシステム設定を IVR.FetchAudioDelay と IVR.FetchAudioMinimum に追加します。これらの WAN 遅延設定は、ルートドキュメントの取得が WAN リンクを介して遅延している場合に必要です。

- IVR.FetchAudio の値を IVR.Fetchaudio= flash:holdmusic.wav のように指定します。デフォルトを空のままにして、通常のシナリオでは何も再生されないようにします。

- 通常のネットワークシナリオでピッという音を回避するには、デフォルト設定を 2 にします。

- WAN 遅延を 0 に設定すると、最低 5 秒間、すぐに holdmusic.wav が再生されます。

- user.microapp.fetchdelay、user.microapp.fetchminimum および user.microapp.fetchaudioなどの ECC 変数を使用して、getSpeechExternal マイクロアプリの起動間の ECC 変数をオーバーライドします。

Note

仮想化音声ブラウザにコールがある場合は、ECC 変数を使用できません。

2. IOS 音声ゲートウェイでパス MTU ディスカバリを有効にします。

IOS 音声ゲートウェイで ip tcp path-mtu-discovery コマンドを追加します。

パス MTU メソッドは、TCP 接続のエンドポイント間におけるネットワークの利用可能な帯域幅の使用率を最大化します。

3. VXML サーバと ICM スクリプト間のラウンドトリップを最小化する。

実行中の VXML サーバアプリケーションから渡された制御が、ICM スクリプトに戻されると、大幅な WAN 遅延が発生します。

VXML サーバアプリケーションの実行を開始したら、Unified CCE スクリプトへのトリップ数を最小限に抑える必要があります。VXML サーバと Unified CCE スクリプト間の各ラウンドトリップでは、遅延が発生します。2 つの新しい TCP 接続と、VHTTP サーバルートドキュメントを含む複数の VXML ドキュメントの HTTP 取得が確立されます。

4. VXML サーバのルートドキュメントのサイズを縮小する。

VXML サーバで、ゲートウェイアダプタの plugin.xml ファイルの内容を次のように変更します。

<setting name="vxml_error_handling">default</setting>

次へ：

<setting name="vxml_error_handling">minimal</setting>

たとえば、CISCO DTMF 1 GW アダプターに対する plugin.xml ファイルの場所は、Cisco\CVP\VXMLServer\gateways\cisco_dtmf_01\6.0.1\plugin.xml です。

Note

HTTP は、発信者に再生される VXML ドキュメントおよび他のメディアファイルを転送します。エンドユーザのコーリングエクスペリエンスを最適なものとするために、HTTP トラフィックは、エンタープライズ ネットワークでの標準規格 HTTP トラフィックの優先順位よりも高い優先順位で処理します。可能な場合は、この HTTP トラフィックを CVP コール シグナリング トラフィックと同じように処理します。この問題を回避するには、VXML サーバを音声ブラウザと同じローカルエリアに移動するか、ワイド エリア アプリケーション サービス（WAAS）を使用します。

Unified CVP のポート使用量と QoS 構成

コールサーバは、SIP メッセージの QoS DSCP のみにマーキングします。WAN 全体の CVP トラフィックに QoS が必要な場合は、IP アドレスとポートを使用して QoS に対してネットワークルータを構成し、トラフィックを分類、マークします。次の表に、必要な構成の概要を示します。

CVP-Data キューとシグナリング キューは、Cisco IOS ルータに関する用語では優先順位のキューではありません。音声または他のリアルタイムトラフィックに優先順位キューを使用します。コールシグナリングおよび CVP トラフィックの通話量に基づいて、いくつかの帯域幅を予約します。

コンポーネント

ポート

キュー

PHB

DSCP

最大遅延（ラウンドトリップ）

メディア サーバ

TCP 80

CVP- データ

AF11

10

1 秒

Unified CVP コール サーバ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ms

Unified CVP IVR サービス

TCP 8000

CVP- データ

AF11

10

1 秒

Unified CVP VXML サーバ

TCP 7000

CVP- データ

AF11

10

1 秒

イングレス音声ゲートウェイ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ms

音声ブラウザ、SIP

TCP または UDP 5060

コール シグナリング

CS3

24

200 ms

SIP Proxy サーバ

TCP または UDP 5060

コール シグナリング

CS3

24

200 ms

MRCP

TCP 554

コール シグナリング

CS3

24

200 ms

WAN の帯域幅のプロビジョニングと QoS に関する考慮事項

一部の CVP 導入では、すべてのコンポーネントが中央に集中しています。これらの展開では LAN 構造を使用するため、WAN ネットワークトラフィックは問題になりません。次のようなシナリオでは、WAN が CVP の帯域幅と QoS に影響を与える可能性があります。

- イングレスゲートウェイと Unified CVP サーバの間の WAN を使用する分散 CVP 導入

- イングレスゲートウェイとエージェントの間に WAN を使用する CVP 導入。

CVP は次の方法で QoS を考慮します。

- CVP にはプライベート WAN ネットワーク構造がありません。必要な場合、すべての WAN アクティビティはコンバージされた WAN ネットワーク構造で実行されます。

- CVP では、高優先順位または低優先順位トラフィック用に個別の IP アドレスを使用しません。

Note

Resource Reservation Protocol（RSVP）はコール アドミッション コントロールに使用されます。ルータは、コールの帯域幅を予約するためにも使用します。RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。コール アドミッション コントロールの場合、ソリューションは CVP と Unified CM のロケーション構成を使用する方法です。

Unified CCE の帯域幅、遅延、および QoS

- Unified CCE の帯域幅と遅延の要件

- Unified CCE 帯域幅に関する考慮事項

- Unified CCE の QoS に関する考慮事項

Unified CCE の帯域幅と遅延の要件

セントラルコントローラ（ルータ）と PG 間で送信されるトラフィックの量は、そのサイトの負荷通話に大きく基づきます。構成の負荷や特定の構成サイズなど、一時的な境界条件もトラフィック量に影響します。帯域幅の調整機能やサイジングフォーミュラを使用すると、帯域幅の要件をより正確にプロジェクトできます。

ACD と VRU を使用するサイトの帯域幅の調整機能では、両方の周辺機器を考慮する必要があります。1 コールあたり 1000 バイトをルールとして使用しますが、十分な帯域幅が存在することを確認するために、システムが運用可能な状態にし、実際の動作をモニタします。このルールに基づいて、4 つの周辺機器があるサイトでは、それぞれ毎秒 10 コールで、320 kbps の帯域幅が必要です。（Unified CCE は、各パスのセントラル コントローラ サイドと PG サイドの両方でデータ送信統計情報を測定します）。

帯域幅と同様に、Unified CCE では、設計通り機能するようにネットワークリンクに固有の遅延が必要です。冗長のセントラルコントローラと PG ノード間のプライベートネットワークの双方向における最大遅延は、80 ミリ秒です。設計通りの実行するために必要な PG から CC へのパブリックネットワークの双方向における最大遅延は、400 ミリ秒です。これらの遅延要件を満たすか超えるのは、Unified CCE のルーティング後および変換ルートにとって重要です。

Note

一般に、エージェント グリーティング機能はシステム全体において低遅延を必要とします。たとえば、エージェント グリーティング機能を設計どおりにサポートするために、パブリック ネットワークでは最大ラウンドトリップ遅延が 100 ms になります。

Unified CCE の帯域幅と遅延の設計は、基になる IP の優先スキームによって異なります。適切な優先設定を行わないと、WAN 接続は失敗します。

最終的なネットワーク設計に応じて、共有ネットワークの IP キューイング戦略は、Unified CCE トラフィックの優先設定を他の非 DNP トラフィック フローと同時に達成する必要があります。このキューイング戦略は、トラフィックプロファイルと帯域幅の可用性によって異なります。ソリューションの厳しい帯域幅、遅延、および優先要件を満たしない限り、共有ネットワークでの成功は保証できません。

Unified CCE 帯域幅に関する考慮事項

- エージェントデスクトップから コールサーバおよびエージェント PG へ

- セントラル コントローラ コンポーネント

- Unified CCE のプライベートネットワーク帯域幅の要件

- WAN を使用したクラスタ化の帯域幅要件

- Unified CM Intra-Cluster Communication Signalling（ICCS; クラスタ内通信シグナリング）

エージェントデスクトップから コールサーバおよびエージェント PG へ

デスクトップ、Unified CCE コールサーバ、エージェント PG 間のトラフィックと帯域幅要件には考慮すべき要素が多数あります。VoIP パケットストリームの帯域幅は、帯域幅の使用に役立つ主な要素です。ただし、呼制御、エージェントの状態シグナリング、サイレントモニタリング、録音、統計などの要因は他にもう 1 つがあります。

Cisco Finesse デスクトップに必要な帯域幅を計算するには、http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html の「Finesse 帯域幅調整機能」を参照してください。

Cisco Finesse では、サーバとエージェントデスクトップ間の遅延を 400 ミリ秒のラウンドトリップ時間に制限します。

セントラル コントローラ コンポーネント

Unified CCE Central Controllers（ルータと Logger）では、冗長ペア間に個別のプライベート ネットワーク リンクが必要です。プライベートネットワーク全体の遅延は、往復で 80 ミリ秒を超えてはなりません。

Unified CCE のプライベートネットワーク帯域幅の要件

プライベートネットワークのリンクとキューのサイズを計算するには、このワークシートを使用します。

Note

どの場合でも、リンクの最小サイズは 1.5Mbps（T1）です。

コンポーネント

実効 BHCA（bps）

乗数

推奨リンク（bps）

乗数

推奨されるキュー（bps）

セントラル コントローラ

* 30

* 0.8

セントラルコントローラの高優先順位キュー帯域幅の合計

Unified CM PG

* 100

* 0.9

これらの番号をまとめて追加し、PG 高優先順位キュー帯域幅の合計を取得します。

Unified VRU PG

* 120

* 0.9

Unified CVP 変数

* ((編集の数 * 平均可変長)/40)

* 0.9

合計リンクサイズ

PG 高優先順位キュー帯域幅の合計

サイト間の 1 つのプライベート ネットワーク リンクの場合は、すべてのリンクサイズをまとめて、表の下部にある [合計リンクサイズ（Total Link Size）] を使用します。それ以外の場合は、セントラル コントローラ プライベート ネットワークの最初の行と、PG プライベートネットワークの他の行の合計を使用します。

WAN 全体に分割されているすべての同様のコンポーネントの実効 BHCA（実効負荷）は、次のように定義されます。

- セントラルコントローラ — この値は、クレジットカードの BHCA の合計で、会議や転送が含まれています。たとえば、10% の会議または転送がある 10,000 BHCA イングレスは、有効な 11,000 BHCA です。

- Unified CM PG — この値は、Unified CM が制御し、エージェントに転送される Unified CCE Route Points を介したすべての通話が含まれます。これは、各コールがルートポイントに着信し、最終的にエージェントに送信されることを前提としています。ルートポイントへの 10,000 BHCA着信コールとエージェントへの転送（10% の会議または転送）は、有効な 11,000 BHCA です。

- Unified VRU PG — この値は、CVP を介した通話処理とキューに対する合計 BHCA です。この計算では、100% の処理が想定されます。たとえば、すべての人が処理を受け、40% がキューに入っている 10,000 BHCA の着信コールは、有効な 14,000 BHCA です。

- Unified CVP Variables — CVP を介してルートされたすべての通話の Call および ECC 変数の数および可変長。

プライベート帯域幅の計算例

次の表に専用プライベートリンクを次の特性に組み合わせた例を示します。

- コンタクトセンターに着信する BHCA の数は、10,000 です。

- CVP は、すべてのコールを処理し、40% がキューに入ります。

- コールは放棄されない限り、すべてエージェントに送信されます。エージェントへのコールのうち、10% は転送または会議です。

- 通話の処理およびキューに使用される Unified CVP は 4 つで、1 つの PG ペアがそれをサポートします。

- 合計 900 エージェントに対して 1 つの Unified CM PG ペアがあります。

- コールには、10 つの 40 バイトのコール変数と 10 つの 40 バイトの ECC 変数があります。

コンポーネント

実効 BHCA（bps）

乗数

推奨リンク（bps）

乗数

推奨されるキュー（bps）

セントラル コントローラ

11,000

* 30

330,000

* 0.8

264,000

セントラルコントローラの高優先順位キュー帯域幅の合計

Unified CM PG

11,000

* 100

1,100,000

* 0.9

990,000

これらの番号をまとめて追加し、PG 高優先順位キュー帯域幅の合計を取得します。

Unified VRU PG

0

* 120

0

* 0.9

0

Unified CVP 変数

14,000

* ((編集の数 * 平均可変長)/40)

280,000

* 0.9

252,000

合計リンクサイズ

1,710,000

1,242,000

PG 高優先順位キュー帯域幅の合計

この例にある組み合わせた専用プライベートリンクの計算結果は次のとおりです。

- 合計リンクサイズ = 1,710,000 bps

- 264,000 bps のセントラルコントローラの高優先順位帯域幅キュー

- 1,242,000 bps の PG の高優先順位キュー帯域幅

この例が、セントラル コントローラ プライベートと PG プライベートの 2 つの別個のリンクを持つソリューションの場合、リンクサイズとキューは次のようになります。

- 264,000 bps の優先順位の高い帯域幅キュー付きの 330,000 bps のセントラル コントローラ リンク（事前定義した実際の最小リンクは 1.5 Mb）

- 1,242,000 bps の高優先順位帯域幅キュー付きの 1,380,000 bps のPG リンク

プライベートネットワークに Multilink Point-to-Point Protocol（MLPPP）を使用する場合、MLPPP リンクの次の属性を設定します。

- パケットごとのロードバランサではなく、接続先ごとにロードバランサを使用します。

- Point-to-Point Protocol（PPP）フラグメントを有効にして、シリアル化された遅延を軽減します。

Note

2 つの個別のマルチリンクが必要で、各リンクは、接続先ごとロードバランサ用です。

WAN を使用したクラスタ化の帯域幅要件

すべての Unified CCE プライベート、パブリック、CTI、および Unified Communications Manager のクラスタ間通信シグナリング（ICCS）に対して、高可用性（HA）WAN 全体で帯域幅を保証する必要があります。さらに、高可用性 WAN を通過するすべての通話に対して帯域幅を保証する必要があります。高可用性 WAN ですべての Unified CCE シグナリングを扱うために最低限必要な帯域幅は、2 Mbps です。

- Unified CVP から VRU PG

- CTI サーバから Cisco Finesse

Unified CVP から VRU PG

現在、VRU PG と Unified CVP 間の通信に特化したツールは存在しません。ただし、前の項で説明したツールでは、必要な帯域幅をかなり正確に測定できます。Unified CCE セントラルコントローラ と VRU PG 間で消費される帯域幅は、VRU PG と CVP 間で消費される帯域幅と似ています。

VRU PG が WAN 全体に分割されている場合、必要な帯域幅の合計はツールがレポートする量の 2 倍になります。セントラルコントローラから PG リンクおよび PG から Unifie CVP リンクに対してレポート済みの帯域幅が必要です。

CTI サーバから Cisco Finesse

Cisco Finesse が WAN リンクを使って CTI サーバに接続する際に必要な帯域幅を確認するには、http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html の「Finesse 帯域幅計算機」を参照してください。

Unified CM Intra-Cluster Communication Signalling（ICCS; クラスタ内通信シグナリング）

Contact Center Enterprise ソリューションでは、Communications Manager のみの導入より、サブスクライバ間の Intracluster Communication Signaling（ICCS）に対してより多くの帯域幅が必要です。Unified CCE では、より多くのコールリダイレクトとクラスタ間通信への追加 CTI/JTAPI 通信が必要です。次の公式を使用して、ICCS と Unified CCE サブスクライバ間のデータベーストラフィックに必要な帯域幅を計算します。

- Intracluster Communications Signaling（ICCS）

Total Bandwidth (Mbps) = (Total BHCA) / 10,000) * [1 + (0.006 * Delay)]

Where Delay = ラウンドトリップ時間のミリ秒単位の遅延

この値は、音声ゲートウェイ、エージェント電話機、およびエージェント PG に接続されている各 Unified CM サブスクライバ間で必要な帯域幅です。このリンクの最小値は 1.544 Mbps です。

Note

この式は、10,000 以上の BHCA を想定しています。BHCA が 10,000 未満の場合は、最低 1.544 Mbps を使用します。

- データベースおよび他の通信

パブリッシャからリモートのサブスクライバごとに 1.544 Mbps

この ICCS 公式に使用する BHCA 値は、コンタクトセンターに着信するすべてのコールの合計 BHCA です。

- CTI ICCS

帯域幅（Mbps）=（合計 BHCA/10,000）* 0.53

これらの帯域幅の要件は、適切な設計と導入を想定しています。非効率的な設計（たとえば、サイト 1 への着信コールをサイト 2 で処理する場合）、クラスタ間の通信が多く、定義されている帯域幅の要件を超える可能性があります。

Unified CCE の QoS に関する考慮事項

この項では、Unified CCE パブリック ネットワーク トラフィックとプライベート ネットワーク トラフィックの両方に関する QoS マーキング、マキューイング、およびガイドラインについて説明します。WAN トラフィックフローに適切な Quality of Service（QoS）の適用など、WAN 上のネットワーク トラフィック フローのプロビジョニング ガイドラインを示します。十分な帯域幅のプロビジョニングと QoS の実装は、Contact Center Enterprise ソリューションを成功にするための重要なコンポーネントです。

一般的に、Contact Center Enterprise WAN ネットワーク構造では、プライベートネットワークとパブリックネットワークの両方に対して個別のリンクを使用します。最適なネットワーク パフォーマンス特性（およびフォールトトレラント フェールオーバーのルートの多様性）のために、Unified CCE には専用のプライベート設備、冗長な IP ルータ、および適切なプライオリティキューイングが必要です。

複数のトラフィッククラスを共有するネットワークを展開している企業は、増分、専用ネットワークへの後戻りではなく、既存インフラストラクチャを維持することを望んでいます。ネットワークの集約がコストと運用の運用効率性を両立させ、そのサポートこそが、Cisco Powered Networks の主要な側面となります。

QoS に対応したパブリックネットワークと、QoS に対応したプライベートネットワーク環境で Unified CCE を導入できます。ただし、ソリューションは厳しい遅延と帯域幅の要件を満たしている必要があります。

Unified CCE は、QoS に差別化されたサービス（DiffServ）モデルを使用します。DiffServ は、トラフィックを異なるクラスに分類し、各ネットワークノードのトラフィッククラスに特定の転送処理を適用します。

- トラフィックをマーキングする場所

- トラフィックのマーキング方法

- Unified CCE での QoS 有効化

- QoS パフォーマンスモニタリング

トラフィックをマーキングする場所

QoS の計画では、Unified CCE またはネットワークエッジのいずれかでトラフィックにマーキングするかについて不明であることがよくあります。各オプションには賛否両論があります。Unified CCE でトラフィックをマークすることで、IP ルータやスイッチでトラフィックを分類するためのアクセスリストを保存します。

Unified CCE でのトラフィックのマーキングにはいくつかの短所があります。まず、各 PG を個別に変更して、パブリック ネットワーク トラフィックのマーキング値を変更します。次に、QoS 信頼をアクセスレイヤのルータとスイッチを有効化します。これによってマーキング レベルが不正に設定された悪意のあるパケットによる攻撃にネットワークがさらされる危険性があります。

Note

Windows では、グループポリシーエディタを使用して QoS ポリシーを適用し、DSCP レベル 3 のマーキングをパケットに適用できます。これらのポリシーは、Active Directory ドメインコントローラを介して管理できます。これにより、管理の問題が簡易化される場合があります。詳細については、該当する Microsoft 社の資料を参照してください。

一方、ネットワークエッジでトラフィックをマーキングすると、中央集中型およびセキュアなマーキングポリシー管理が可能です。アクセスレイヤデバイスで信頼を有効にする必要はありません。Unified CCE パケットを認識するアクセスリストを定義するには、少しのオーバーヘッドがあります。これらは参考用に表で提供されています。Unified CCE トラフィックの認識にはアクセスリストのポート番号を使用しません。ポート番号によって、アクセスリストが複雑になります。新しい顧客インスタンスをシステムに追加するごとに、アクセスリストを変更する必要があります。

トラフィックのマーキング方法

必要に応じて、デフォルトの Unified CCE QoS マーキングを上書きできます。次の表に、各優先順位フローのデフォルトのマーキング、遅延要件、IP アドレス、およびポートを示します。次の表にある i# は、カスタマーインスタンス番号です。パブリックネットワークでは、中優先順位のトラフィックは、高優先順位のパブリック IP アドレスで送信され、高優先順位のトラフィックと同じようにマークされます。ただし、プライベートネットワークでは、低優先順位のプライベート IP アドレスで中優先順位のトラフィックが送信され、低優先順位のトラフィックと同じようにマークされます。

Cisco Unified Communications のパケット分類の詳細については、http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html の『シスコ コラボレーション システム ソリューション リファレンス ネットワーク設計』を参照してください。

Note

シスコでは、音声制御プロトコルのマーキングを DSCP 26（PHB AF31）から DSCP 24（PHB CS3）に変更し始めています。ただし、多くの製品は依然として、シグナリングトラフィックを DSCP 26（PHB AF31）としてマークしています。したがって、暫定的に、AF31 と CS3 の両方をコールシグナリング用にとっておきます。

パブリック ネットワーク トラフィック マーキング（デフォルト）および遅延要件

優先度

サーバ側の IP アドレスとポート

一方向の遅延要件

DSCP / 802.1p マーキング

高

IP アドレス：ルータの優先順位が高いパブリック IP アドレス TCP ポート：

- A における DMP 高優先接続用 40003 + (i# * 40)

- B における DMP 高優先接続用 41003 + (i# * 40)

UDP ポート：UDP ハートビートには 39500 ～ 39999。

200 ms

AF31 / 3

中

IP アドレス：ルータの優先順位が高いパブリック IP アドレス TCP ポート：

- A における DMP 高優先接続用 40017 + (i# * 40)

- B における DMP 高優先接続用 41017 + (i# * 40)

UDP ポート：UDP ハートビートには 39500 ～ 39999。

1000 ミリ秒

AF31 / 3

低

IP アドレス：ルータの優先順位が低いパブリック IP アドレス TCP ポート：

- A における DMP 高優先接続用 40002 + (i# * 40)

- B における DMP 高優先接続用 41002 + (i# * 40)

UDP ポート：UDP ハートビートには 39500 ～ 39999。

5 秒

AF11 / 1

ルータ プライベート ネットワーク トラフィック マーキング（デフォルト）および遅延要件

優先度

サーバ側の IP アドレスとポート

一方向の遅延要件

DSCP / 802.1p マーキング

高

IP アドレス：ルータの高優先プライベート IP アドレス

TCP ポート：MDS 高優先接続用 41005 + (i# * 40)

UDP ポート：UDP ハートビートには 39500 ～ 39999

40 ミリ秒

AF31 / 3

中

IP アドレス：ルータの低優先順位プライベート IP アドレス

TCP ポート：MDS 中優先接続用 41016 + (i# * 40)

1000 ミリ秒

AF11/1

低

IP アドレス：ルータの低優先順位プライベート IP アドレス

TCP ポート：

- MDS 低優先順位接続用 41004 + (i# * 40)

- CIC StateXfer 接続用 41022 + (i# * 40)

- CLGR StateXfer 接続用 41021 + (i# * 40)

- HLGR StateXfer 接続用 41023 + (i# * 40)

- RTR StateXfer 接続用 41020 + (i# * 40)

1000 ミリ秒

AF11/1

PG プライベート ネットワーク トラフィック マーキング（デフォルト）および遅延要件

優先度

サーバ側の IP アドレスとポート

一方向の遅延要件

DSCP / 802.1p マーキング

高

IP アドレス：PG 高優先順位プライベート IP アドレス TCP ポート：

- PG no.1 の MDS 高優先接続用 43005 + (i# * 40)

- PG no.2 の MDS 高優先接続用 45005 + (i# * 40)

UDP ポート：UDP ハートビートには 39500 ～ 39999

40 ミリ秒

AF31/3

中

IP アドレス：PG 低優先順位プライベート IP アドレス TCP ポート：

- PG no.1 の MDS 中優先接続用 43016 + (i# * 40)

- PG no.2 の MDS 中優先接続用 45016 + (i# * 40)

1000 ミリ秒

AF11/1

低

IP アドレス：PG 低優先順位プライベート IP アドレス TCP ポート：

- PG no.1 の MDS 低優先接続用 43004 + (i# * 40)

- PG no.2 の MDS 低優先接続用 45004 + (i# * 40)

- PG no.1 の OPC StateXfer 用 3023 + (i# * 40)

- PG no.2 の OPC StateXfer 用 45023 + (i# * 40)

1000 ミリ秒

AF11/1

Unified CCE での QoS 有効化

QoS は、プライベート ネットワーク トラフィックでデフォルトで有効になっています。

パブリック ネットワーク トラフィックの QoS を無効にします。ほとんどの導入では、パブリック ネットワーク トラフィックの QoS を無効にすると、フェールオーバー処理がタイムリーになります。

Windows グループポリシーを使用して、または IP エッジルータでマーキングを有効にすることで、コンタクトセンター アプリケーション外で、QoS マーキングを追加できます。

インストール中にルータの QoS を有効にする方法については、ソリューションの「インストールマニュアル」を参照してください。

QoS パフォーマンスモニタリング

QoS 対応のプロセスが起動、実行されると、Microsoft Windows Performance Monitor（PerfMon）を使用して、基礎となるリンクに関連付けられているパフォーマンスカウンタを追跡できます。PerfMon の使用の詳細については、Microsoft のマニュアルを参照してください。QoS のパフォーマンスカウンタの詳細についてはhttp://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の Cisco Unified ICM/Contact Center Enterprise サービスアビリティ ベスト プラクティス ガイド を参照してください。

仮想化音声ブラウザの QoS

次の表に、Cisco VVB の RTP と SIP のデフォルトの QoS の概要を示します。必要に応じて、図のようにデフォルトを変更できます」。

コンポーネント

DSCP

ポート

Cisco VVB RTP

[CS0（FTP）]（デフォルト）

- Expedited Forwarding（EF; 完全優先転送）の設定にプラットフォーム CLI を使用する

- set dscp marking ipvms EF および set dscp enable ipvms を設定して RTP の DSCP を有効にする

RTP 24576:32767

Cisco VVB SIP

[CS0（FTP）]（デフォルト）

- CS3 に設定するためにプラットフォーム CLI を使用する

- set dscp marking UnifiedSIPSSTCP CS3 および set dscp enable UnifiedSIPSSTCP を設定し、SIP over TCP の DSCP を有効にする

- set dscp marking UnifiedSIPSSUDP CS3 および set dscp enable UnifiedSIPSSUDP を設定し、SIP over UDP の DSCP を有効にする

TCP/UDP 5060

Cisco VVB TCP/UDP から VXML サーバ、コールサーバ、メディアサーバ、ASR、TTS などのサーバへ

[CS0（FTP）]（デフォルト）

- tcp_ephemeral を CS3 に設定するには、次のプラットフォーム CLI コマンドを使用します。

set dscp marking tcp_ephemeral CS3

set dscp enable tcp_ephemeral

- tudp_ephemeral を CS3 に設定するには、次のプラットフォーム CLI コマンドを使用します。

set dscp marking udp_ephemeral CS3

set dscp enable udp_ephemeral

TCP/UDP 32768:61000

Unified CM の帯域幅、遅延、および QoS

- Unified CM クラスタへのエージェント電話機の帯域幅

Unified CM クラスタへのエージェント電話機の帯域幅

電話機から Unified CM のシグナリングに必要な帯域幅は、電話機ごとに 150 bps です。

たとえば、1000 エージェントソリューションでは、各コンタクト センター サイトで約 150 kbps が必要です。

Cisco Finesse の帯域幅、遅延、および QoS

Cisco Finesse では、エージェントまたはスーパーバイザのサインイン中が最大の帯域幅使用率になります。この操作には、Web ページのロード、CTI サインイン、および初期エージェントの状態の表示が含まれます。デスクトップの Web ページを読み込むと、必要な帯域幅は小さくなります。

スーパーバイザデスクトップは、追加のガジェットのため、サインイン時により多くの帯域幅を消費します。サインイン操作に最小帯域幅を義務付ける必要はありません。サインインに必要な時間に基づいてソリューションに必要な帯域幅を決定します。Cisco Finesse には、特定のクライアントサインイン時間に必要な帯域幅を想定する帯域幅調整機能（http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html）が用意されています。

フェールオーバー中は、エージェントは代替 Cisco Finesse サーバにリダイレクトされ、自動的にログインすると、デスクトップが再ロードされます。予想される帯域幅の使用率は、最大で 90 秒間（ピーク時）で 250 Mbps まで達し、2000 人のエージェントすべてが一方のサイドから別のサイドに正常にフェールオーバーされることを確認します。帯域幅の要件は、チームに構成されたガジェットの種類と数に応じて増加します。

詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html の「Unified Contact Center Enterprise の Finesse 帯域幅調整機能」を参照してください。

Note

Cisco Finesse 帯域幅の調整機能には、Cisco Finesse コンテナ内のサードパーティ製ガジェットに必要な帯域幅は含まれません。また、帯域幅が競合するエージェント デスクトップ クライアントで実行する別のアプリケーションは考慮されません。

Cisco Finesse は Web アプリケーションであるため、キャッシングを行うと必要な帯域幅に大きな影響を及ぼす可能性があります。エージェントの初回サインイン後に、キャッシュによって以降のサインインに必要な帯域幅が大幅に減少します。サインインに必要な帯域幅を最小限に抑えるために、ブラウザのキャッシュを有効します。

サインインが完了すると、エージェントとスーパーバイザの両方が最も集中した操作で、ルートポイントへの発信コールを行います。スーパーバイザの場合は、[チームパフォーマンス（Team Performance）] と [キュー統計（Queue Statistics）] ガジェットの更新が同時に発生する場合があります。Cisco Finesse 帯域幅調整機能を使用すると、すべての Cisco Finesse クライアントと Cisco Finesse サーバ間の接続に必要な合計帯域幅を計算できます。

この帯域幅を共有する音声トラフィックを含む他のアプリケーションのニーズを処理した後で、ソリューションに必要な帯域幅を確保します。十分な帯域幅を連続的に利用できない場合は、Cisco Finesse インターフェイスのパフォーマンスとコールの音声品質が低下する可能性があります。

- Cisco Finesse デスクトップの遅延

- Cisco Finesse の QoS

- Cisco IM&P の帯域幅と遅延に関する考慮事項

Cisco Finesse デスクトップの遅延

エージェント PG からリモートでエージェントとスーパーバイザのデスクトップを見つけることができます。設計が不十分な導入では、タイムアウト値が大きくなると、デスクトップサーバとデスクトップクライアント間で極端な遅延が発生する可能性があります。遅延が大きいと、ユーザエクスペリエンスが影響を受け、エージェントが複雑で受け入れられない結果を招きます。たとえば、デスクトップを更新する前に電話機が鳴り始める場合があります。Cisco Finesse では、サーバとエージェントデスクトップ間の遅延を 400 ミリ秒のラウンドトリップ時間に制限します。

Cisco Finesse では、Cisco Finesse サーバと PG 間の遅延を 200 ミリ秒のラウンドトリップ時間に制限する必要があります。Cisco Finesse サーバ間の遅延を 80 ミリ秒のラウンドトリップ時間に制限します。

Cisco Finesse の QoS

Cisco Finesse は、ネットワークトラフィックでの QoS の設定をサポートしていません。通常、トラフィックの QoS 分類とマーキングはスイッチまたはルータレベルで行われます。特に WAN を介するエージェントの場合は、シグナリングトラフィックを優先順位付けできます。

Cisco IM&P の帯域幅と遅延に関する考慮事項

Cisco IM&P サービスは Unified CM と密接に統合されており、ユーザ管理、サービスの有効化と認証を Unified CM に依存しています。

Cisco IM&P は、可用性を保証するためクラスタとして展開できます。ユーザは、クラスタなしで特定のノードのペアを事前構成する必要があります。Cisco IM&P のインストールおよびクラスタ展開の詳細に関しては、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-guides-list.html を参照してください。

IM&P サーバの遅延要件の詳細に関しては、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の Unified CM SRND を参照してください。

Cisco IM&P を使用するデスクトップチャット機能は、より高いクライアント帯域幅が必要です。次で Finesse 帯域幅計算ツールを参照してください。https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html

Finesse および IM&P ノード間のサポートされている最大遅延は、200 ミリ秒です。

Unified Intelligence Center の帯域幅、遅延、および QoS

- 帯域幅のレポートに関するパラメータ

- ネットワーク帯域幅要件

- Unified Intelligence Center の帯域幅要件の例

帯域幅のレポートに関するパラメータ

次のパラメータは、デスクトップ上の Cisco Unified Intelligence Center の反応とパフォーマンスに複合的な影響を与えます。

- リアルタイムレポート — 1 人のユーザが同時に実行できる リアルタイムレポート。

- リアルタイムレポートの更新レート — プレミアムライセンスを所持している場合、レポート定義を編集すると更新レートを変更できます。Unified Intelligence Center のデフォルトの更新レートは 15 秒です。ライブデータのデフォルトの更新レートは、3 秒です。

- レポートあたりセル数 — レポートで取得、表示する列の数。

- 履歴レポート — 1 人のユーザが 1 時間あたりに実行する 履歴レポートの数。

- 履歴レポートの更新レート — レポートデータが更新される頻度。

- レポートごとの行 — 1 つのレポート内の行数。

- ダッシュボードごとのチャート — 1 つのダッシュボードで同時に使用するチャート数（円グラフ、棒グラフ、線グラフ）。

- ダッシュボードごとのゲージ — 1 つのダッシュボードで同時に使用するゲージ数（スピードメータ）。

ネットワーク帯域幅要件

必要な帯域幅は、更新頻度、各レポートの行と列の数、その他の要因によって異なります。WAN 全体で、Unified Intelligence Center の遅延は 200 ミリ秒以下である必要があります。

Cisco Unified Intelligence Center Bandwidth Calculator（http://www.cisco.com/c/en/us/support/customer-collaboration/unified-intelligence-center/products-technical-reference-list.html）を使用して、Unified Intelligence Center の実装に対する帯域幅要件を計算します。

Unified Intelligence Center の帯域幅要件の例

このサンプルデータは、ローカルの AWDB データベースとレポートを実行するクライアントマシンを使用する LAN でのテストから取得されたデータです。

このテストの負荷では、以下を実行している1人の Unified Intelligence Center ユーザを使用しました。

200 名の Unified Intelligence Center ユーザが、それぞれ同時に実行しています。

- 1 レポートあたり、10 列、100 行の 2 つの リアルタイムレポート。

- それぞれ 10 列、2000 行の 2 つの2 つの 履歴レポート。

- それぞれ 10 列、100 行の 2 つの ライブデータレポート。（LD を実行するかどうかは、導入タイプに基づいて調整します）。

この表は、テストで観察された帯域幅の使用状況を示しています。

テストで観察された帯域幅の使用状況

接続

帯域幅

Unified Intelligence Center <– –> AWDB

3.4 mbps

Unified Intelligence Center <– –> ブラウザベースのレポートクライアント

5.5 mbps

必要な帯域幅は、各レポートの行数、同時レポート実行数などのパラメータによって異なります。

仮想環境のディスク帯域幅の要件

Unified Intelligence Center が CPU とメモリの予約に加え、C シリーズのサーバ上の VM で実行されている場合は、毎秒 25 KB I/O のサブシステムをプロビジョニングします。平均して、Unified Intelligence Center はフルロードでこの帯域幅を毎秒 10 KB 消費します。I/O スループットのピーク要件は毎秒 25 KB に達します。

シスコライブデータの帯域幅、遅延、および QoS

ライブデータの帯域幅に関する考慮事項

トラフィックの量、したがって、セントラルコントローラ、PG、およびライブデータ間の帯域幅の使用量は、サイトのコール負荷に大きく基づいています。

ライブデータとデスクトップクライアント間の帯域幅の使用量は、レポートに対するコール率とアクティブ サブスクリプションによって異なります。アクティブ サブスクリプションの数は、次に基づいています。

- CUIC で表示されている ライブデータレポートの数。

- ログインしているエージェントの数。

- 各エージェントがメンバーであるスキルグループおよび PQ の数。

Cisco IdS の帯域幅に関する検討事項

したがって、トラフィックの量、Cisco IdS と次のコンポーネント間の帯域幅の使用量は、サインインしたエージェントの数にのみ依存します。

- Cisco Finesse

- Cisco Unified Intelligence Center

Finesse 帯域幅計算機と Unified Intelligence Center 帯域幅計算機は、エージェントシフト開始時に API コールがわずかに増加することを考慮に入れています。

Finesse と Unified Latenc Center の帯域幅、遅延、および QoS に関する検討事項の詳細については、Cisco Finesse の帯域幅、遅延、および QoS および Unified Intelligence Center の帯域幅、遅延、および QoS を参照してください。

オプションのシスココンポーネントの帯域幅、遅延、および QoS

- 帯域幅、遅延、向け QoSビジネス チャットおよび E メール

- サイレントモニタリング用の帯域幅、遅延、および QoS

- Customer Journey Analyzer の帯域幅、遅延、および QoS

帯域幅、遅延、向け QoSビジネス チャットおよび E メール

エージェントが ビジネス チャットおよび E メール サーバにサインインするために必要な最小帯域幅は、384 kbs です。サインイン後、必要な帯域幅は 40 kbs 以上です。

この必要な帯域幅内で 5050-KB の接続がサポートされます。大きな添付ファイルをダウンロードする再、エージェントユーザインターフェイスで一時的な速度低下が見られる場合があります。

ビジネス チャットおよび E メール の帯域幅、遅延、QoS 要件に関する詳細は、http://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/products-implementation-design-guides-list.html の「Enterprise チャットおよび E メール設計ガイド」を参照してください。

サイレントモニタリング用の帯域幅、遅延、および QoS

- Unified CM ベースのサイレントモニタリング用の帯域幅、遅延、および QoS

Unified CM ベースのサイレントモニタリング用の帯域幅、遅延、および QoS

サイレントモニタリングを使用すると、スーパーバイザは Unified CCE コールセンターでエージェントコールをリッスンできます。監視されているエージェントの IP ハードウェアフォンで送受信された音声パケットがネットワークからキャプチャされ、スーパーバイザデスクトップに送信されます。この音声パケットはスーパーバイザデスクトップで復号化され、スーパーバイザシステムのサウンドカードで再生されます。エージェントのサイレントモニタリングは、追加の音声コールとほぼ同じネットワーク帯域幅を使用します。あるエージェントが 1 つの音声コールの帯域幅を必要とする場合に、そのエージェントがサイレントモニタリングの対象であると、同時に 2 つの音声コール用の帯域幅が必要になります。コールロードに必要な合計帯域幅を計算するには、コーデックとネットワークプロトコルのコールごとの帯域幅でコールの数を掛け算します。

Customer Journey Analyzer の帯域幅、遅延、および QoS

Cloud Connect コンポーネントは、カスタマー ジャーニー アナライザおよび Unified CCE 履歴 データベースに接続します。Unified CCE-HDS データベースからデータを迅速に読み取る場合は、Cloud Connect を HDS と同じネットワークにインストールする必要があります。

Cloud Connect とカスタマー ジャーニー アナライザ間のネットワーク帯域幅の要件は、展開のコール量によって異なります。各コールについて、4000 バイトのデータがアナライザに送信されます。

2000 エージェント導入モデルの場合、帯域幅は次のように示されます。

1 秒あたりのコール

コールのバイト数

帯域幅（KBps）

15

4000

60000

転送と会議コールのシナリオを考慮するため、これらコールに追加の通話レグを検討してください。たとえば、転送コールまたは会議コールは、帯域幅の計算用の 2 つのコールと見なす必要があります。

Cloud Connect とアナライザ間の遅延要件は、400 ミリ秒のラウンドトリップ時間を超えるべきではありません。

オプションのサードパーティ コンポーネントの帯域幅、遅延、および QoS

- 帯域幅、遅延、ASR/TTS 向け QoS

帯域幅、遅延、ASR/TTS 向け QoS

自動音声認識（ASR）または音声合成（TTS）サーバは、無音圧縮を使用できないため、G.711 コーデックを使用する必要があります。

WAN 構成における ASR および TTS

ASR または TTS は帯域幅を多用します。ASR または TTS RTP および MRCP トラフィックには QoS DSCP マーキングがタグ付けされません。アクセス制御リスト（ACL）を使用して、リモートサイトとセントラルサイトのトラフィックを分類し、再マークします。

Note

シスコは、WAN 環境の音声アプリケーションをテストまたは適格確認していません。設計のガイドライン、WAN でのサポートおよび関連する警告については、各ベンダー専用マニュアルを参照してください。

Cisco Technical Assistance Center では、音声アプリケーションに関連する問題のサポート（サードパーティ製の相互運用性認定製品の場合と同様）は限られています。

音声ブラウザと ASR または TTS サーバ間の RTP メディアトラフィックの分類

音声ブラウザは、通常の Cisco IOS RTP UDP ポート範囲である 16384 ～ 32767 を使用します。ただし、ASR または TTS サーバの RTP UDP ポート範囲は、オペレーティングシステムとベンダーによって異なる場合があります。音声ブラウザ UDP ポート範囲に基づいて、ASR または TTS サーバからのトラフィックと一致する ACL を作成できます。ただし、可能な場合は、ASR ポートまたは TTS サーバも使用します。RTP トラフィックに DSCP EF を設定して、他の音声トラフィックを含む優先順位キューに配置します。

想定される ASR または TTS セッションの最大数をサポートするために、QoS 優先順位キューを構成します。Unified CM の場所や Resource Reservation Protocol（RSVP）などのコール アドミッション コントロール方式では、QoS 優先順位のキューの帯域幅を帯域幅とは別に保つ必要があります。2 つの ASR または TTS G.711 セッション（それぞれ 80 kbps）と、G.729（それぞれ 24 kbps）を使用する 4 つの IP フォンコールをサポートするための優先のキューの帯域幅は、256 kbps です。ロケーション コール アドミッション コントロールまたは RSVP 帯域幅を IP テレフォニー 帯域幅（この例では 96 kbps）のみに制限します。256 kbps 全体にわたってその帯域幅を設定する場合、IP コールは、すべての帯域幅を使用し、ASR または TTS セッションと競合する場合があります。

音声ブラウザと ASR または TTS サーバ間の MRCP トラフィックの分類

MRCP トラフィックは簡単に分類できます。ASR または TTS サーバは、ベンダーに基づいて構成できる TCP ポートで MRCP リクエストをリッスンします。そのため、ACL のこのポートを使用してトラフィックを分類します。MRCP の帯域幅は、ASR または TTS リソースを使用するアプリケーションの周波数によって異なります。MRCP では、対話ごとに約 2000 バイトが使用されます。コール単位で 3 秒ごとに ASR または TTS 対話がある場合、平均帯域幅は次のように計算できます。

(2000 bytes/interaction) * (20 interactions/minute) * (8 bits/byte) = 320,000 bits per minute per call
(320,000 bits per minute) / (60 seconds/minute) = 5.3 average kbps per branch

一度に最大 6 つの ASR または TTS セッションを構成する場合は、ブランチあたり平均 32 kbps を使用します。

ASR または TTS 対応のコールの最大数を制限する

ASR または TTS に対して有効になっているコールの数を制限します。制限に達した場合は、コールを拒否する代わりに通常の DTMF プロンプト/コレクトを使用します。次の例では、5559000 が ASR または TTS DNIS および 5559001 が DTMF DNIS であると仮定します。ASR の負荷制限を実行するために、イングレスゲートウェイ を構成できます。ASR または TTS VoIP ダイヤルピアで許可されている最大接続数を超えた場合は、DNIS を変更します。

voice translation-rule 3 rule 3 /5559000/ /5559001/
!
voice translation-profile change
translate called 3
!
!Primary dial-peer is ASR or TTS enabled DNIS in ICM script
dial-peer voice 9000 voip
max-conn 6
preference 1
destination-pattern 55590..
...
!
!As soon as 'max-conn' is exceeded, next preferred dial-peer will change
the DNIS to a DTMF prompt & collect ICM script
dial-peer voice 9001 voip
translation-profile outgoing change
preference 2
destination-pattern 55590..
...
!

Note

80 kbps は、IP/RTP ヘッダーや圧縮なしなど、音声アクティビティ検出を使用しない G.711 全二重でのレートです。VAD を使用しない G.729 全二重でのレートは、IP/RTP ヘッダーや圧縮なしで 24 kbps です。VoIP 帯域幅の使用法については、「Voice Codec Bandwidth Calculator」を参照してください。

Note

Cisco VVB には ASR とのダイヤルピアは存在しないので、Cisco VVB ではこの技法を使用できません。

Chapter 10. リファレンス設計のサイズおよび動作の条件

- リファレンス設計ソリューションのサイジング

- リファレンス設計準拠ソリューションの動作に関する考慮事項

リファレンス設計ソリューションのサイジング

Contact Center Enterprise ソリューションでは、リソースの適切なサイジングが必要となります。この章では、こういったリソースのサイジング用ツールおよびメソッドを説明します。サイジング対象には以下のリソースが含まれます。

- 必要なコンタクト センター エージェント数（希望通話量およびサービス レベルなどの顧客の要件に基づく）

- さまざまなコール シナリオ（コール処理、プロンプトおよび収集、キューイング、セルフサービス アプリケーションなど）に必要な VRU ポートの数

- 着信および発信トラフィック ボリュームを伝送するために必要な音声ゲートウェイ ポート数

適切なサイジングでは、アーラン-B モデルと アーラン-C モデルにカプセル化されたトラフィック エンジニアリングの原則が使用されます。

- 連絡先でのリソース使用

- コンタクト センターのトラフィック用語

- 設計ツールとしての アーラン計算機

- Unified CCE 向けダイナミック設定の制限

- リファレンス設計ソリューションの設定制限

- Cisco Virtualized Voice Browser

- Cisco Finesse のサイジング

- 輻輳制御のサイジング

連絡先でのリソース使用

Contact Center Enterprise ソリューションのサイズを決定する際の主なリソースは以下の通りです。

- エージェント

- ゲートウェイ ポート (PSTN トランク)

- VRU ポート

必要なリソースを決定するには、まず、典型的なインバウンド コールのこのタイム ラインおよび各ステップで必要とされるリソースを調べます。この図は、主なリソースとそのリソースの占有率（保持および処理時間）を示しています。

インバウンド コールのタイムライン

通話がすぐに応答されない場合は、通話タイムラインに呼び出し遅延時間（ネットワーク呼び出し音）を含めます。平均呼び出し遅延時間は数秒です。計算にはトランクの平均処理時間に追加します。

コンタクト センターのトラフィック用語

これらは、コンタクトセンター リソースのサイジングに関する最も一般的な業界用語です。

最繁時または最繁期間

ビジー間隔は1時間以下です。最繁期間は、1 日のうちでトラフィックが最も集中する時間帯に発生します。繁忙時間や間隔は、週末や季節の影響などの状況により異なります。最繁時の平均値（1 年で最も混雑する時間の上位 10 の平均値）を使用して設計します。ただし、マーケティング キャンペーンや季節の最繁時（祝日のピークなど）に対応するために人員配置が必要な状況では、必ずしもこの平均値を適用できるわけではありません。コンタクト センターでは、ピーク期間に基づいて最大数のエージェントを配置します。ただし、一定期間毎に（通常は 1 時間毎）その日の残りの要件を計算します。これにより、トレーニングやコーチングなどのオフライン アクティビティのエージェントはスケジュールせずに、コールに応答するエージェントを適切にスケジュールすることができます。トランクあるいは VRU ポートについては、多くの場合、トランクやポートを毎日追加または削除することは現実的ではないため、こういったリソースはピーク期間に合わせてサイジングします。小売業界の環境によっては、ピーク シーズン中に増設用トランクを追加して、その後、切断することもあります。

最繁時呼数（BHCA）

BHCA とは、トラフィックのピーク時（または期間）にコンタクト センターで受信または受信を試みたコールの総数です。便宜上、音声ゲートウェイに渡されるすべてのコールがコールセンター リソースによって受信され、処理されると想定します。コールは通常、PSTN から発信されますが、コンタクト センターへのコールは、ヘルプ デスク アプリケーションなどによって内部的に生成されることもあります。

コール ルータから報告される毎秒のコール数（CPS）

これは、Unified CCE ルータがコール ルーティング要求を受信するレートです。すべてのコールは、イングレス ゲートウェイから VRU 処理、エージェントへのルーティングまでの単純なコール フローで単一のコール ルーティング要求を生成します。ただし、最終的に適切なエージェントに到達するために、ルータに対して複数のルーティング要求を行う必要があるコールもあります。

この例は、コールを受信した最初のエージェントが、ポスト ルーティングを使用して別のエージェントに転送または会議を行うケースです。これにより、追加のルーティング要求が生成され、同じコールがルーターへの 2 つのルーティング要求を生成します。リソースがコールまたはタスクに必要な場合は、常にルーターに対してルーティング要求が行われます。これらのリクエストには、E メール、チャット、コールバック、特定のアウトバウンド コールのマルチメディア リクエストも含まれます。コールセンターの管理者は、コンタクト センターの規模を決める際に、これらの追加のコール ルーティング要求を考慮する必要があります。

サポートされる最大コール レートは、イングレス ゲートウェイの BHCA ではなく、ルータによって報告されるコール レートです。これらの追加のルーティング要求をイングレス ゲートウェイでの BHCA の計算に含めます。通常、イングレス ゲートウェイの BHCA は、ルータによって報告される対応する CPS レート以下となります。

たとえば、以下の状況が考えられます。イングレス ゲートウェイの BHCA が 36,000 の場合、イングレス ゲートウェイのコール レートは 10 CPS です。コールの 10％ がルータを介して転送されると仮定した場合、ルータによって報告される CPS は 11 CPS と同等となります。この場合、ソリューションには 11 CPS の容量が必要です。

サーバ

サーバは、トラフィック負荷またはコールを処理するリソースです。コンタクト センターには多くの種類のサーバがあります。タイプ毎に異なるリソースが必要になる場合があります。

通話時間

通話時間は、エージェントが発信者との通話に費やす時間です。これには、エージェントが発信者を保留にしたり、コンサルテーションの会議中に費やした時間が含まれます。

ラップアップ時間（コール後の作業時間）

コールが終了すると (発信者が電話を切ると)、エージェントは特定のタスクを完了してコールの「後処理」を行います。後処理時間には、データベースの更新、コールのメモの記録、またはエージェントが別のコールに応答できるようになるまで実行されるその他のアクティビティなどのタスクが含まれます。Unified Contact Center Enterprise ソリューションでは、この期間を コール後の業務時間と呼ぶことがあります。

平均処理時間（AHT）

AHT とは、指定された期間内でのコールの平均継続時間のことです。これは、セルフサービス コールのコール処理時間や、エージェントへのコールの通話時間など、いくつかのタイプの処理時間の合計を指します。最も一般的な定義では、AHT はエージェントの通話時間とエージェントのラップアップ時間の合計となります。

アーラン

アーラン（アーラン）は最繁時のトラフィック負荷を測定する単位です。アーランは、同一の回線、トランク、またはポート上にコールが 3,600 秒（60 分、つまり 1 時間）存在していることに基づきます。（コールの数や平均継続時間に関係なく、1 つの回線が 1 時間にわたって話中になる状態です）。アーラン値の計算には以下の数式を使用します。

Traffic in Erlangs = (Number of calls in the busy hour * AHT in sec) / 3600 sec

コンタクト センターが最繁時に 6 分間のコールを 30 回受信した場合、これは最繁時に 180 分のトラフィック、つまり 3 アーランに相当します。最繁時にコンタクト センターが平均 36 秒のコールを 100 回受信した場合、受信した総トラフィックは 3600 秒、つまり 1 アーラン（3600 秒/3600 秒）になります。

最繁時トラフィック（BHT）（アーラン単位）

BHT は最繁時のトラフィック負荷です。BHCA と AHT の積として計算され、1 時間で正規化されます。

BHT = (BHCA * AHT seconds) / 3600

たとえば、最繁時にコンタクト センターが平均 2 分間のコールを 600 回受信した場合、最繁時のトラフィック負荷は（600 X 2/60）= 20 アーランとなります。

BHT は通常、PSTN トランクなどのリソースを計算するためにアーラン B モデルで使用されます。

サービス グレード（ブロック率）

この測定は、最繁時にリソースまたはサーバが話中になる確率を示します。そのような場合、そのコールは失われるかブロックされます。このブロック率は通常、音声ゲートウェイ ポート、VRU ポート、PBX 回線、トランクなどのリソースに適用されます。音声ゲートウェイの場合、サービス グレードは、総 BHCA に対するブロックされたコールの割合またはビジー トーン（使用可能なトランクなし）を受信したコールの割合となります。たとえば、サービス グレード 0.01 は、最頻時にコールの 1 % がブロックされることを意味します。1 % のブロック率は PSTN トランクを使用する場合の標準値ですが、別のアプリケーションでは異なるサービス グレードが必要になることもあります。

ブロックされたコール

ブロックされたコールとは、即時に対応されないコールのことです。発信者が別のルートまたはトランク グループに再ルーティングされた場合や、先延ばしにされキューに格納された場合、またはトーン（ビジー トーンなど）や応答メッセージで対応された場合、その発信者はブロックされます。ブロックされたコールの性質に応じて、特定のリソースのサイジングに適用されるモデルが決定されます。

サービス レベル

X 秒以内に応答される、提供されたコール ボリューム（音声ゲートウェイおよびその他のソースから受信）の割合の業界標準用語。販売系のコンタクト センターの標準値では、全コールの 90 % が 10 秒未満で応答されます（一部のコールはキューに格納され、待機させられます）。サポート系のコンタクト センターでは、最繁時には全コールの 80 % に 30 秒以内に応答するなど、販売系とは異なるサービス レベルを目標にしていることもあります。サービス レベルの目標に基づき、必要なエージェント数、キューに入れられたコールの割合、コールがキューで費やす平均時間、および必要な PSTN トランクおよび VRU ポートが決定されます。

キューイング

エージェントが他の発信者と通話中である場合や対応できない場合（コール後のラップアップ中）は、エージェントが応答可能になるまで後続の発信者をキューに格納しておく必要があります。希望するサービス レベルとエージェントのスタッフ配置により、キューに入れられたコールの割合とキューで費やされた平均時間が決まります。Contact Center Enterprise ソリューションは、VRU を使用して発信者をキューに配置して、アナウンスを再生します。最初は VRU がすべてのコールを処理します。コール処理を提供し、必要な情報を要求します。VRU は、発信者がエージェントと話す必要なくサービスを受けるセルフサービス アプリケーションを処理します。各シナリオで、それぞれの平均処理時間やコール負荷が異なるため、さまざまなアプリケーションを処理するために必要な IVR ポートの数は異なります。これらの各アプリケーションに必要なトランクまたはゲートウェイポートの数は、それに応じて異なります。

設計ツールとしての アーラン計算機

テレフォニー システムとリソースのサイジングには、多くのトラフィック モデルを使用することができます。適切なモデルの選択は、3 つの主な要因に依存します。

- トラフィック ソースの特性（有限または無限）

- 損失コールの処理方法（クリア、保留、遅延）

- 着信パターン (ランダム、スムース、ピーク時)

Contact Center Enterprise ソリューションでは、通常リソースのサイジングにアーラン-B およびアーラン-C トラフィック モデルを使用します。

アーラン計算機は、以下の質問に答える上で役立ちます。

- 必要なトランク数は?

- 必要なエージェント数は?

- 必要な VRU ポート数は?

アーラン計算機に入力が必要な数字は以下の通りです。

- 繁時呼数（BHCA）

- 各リソースの平均処理時間 (AHT)

- サービス レベル (x 秒以内に応答されるコールの割合)

- トランクおよび VRU ポートに必要なサービス グレード、またはブロック率

次のセクションでは、一般的な Erlang モデルを簡潔に説明します。また、アーラン モデルの入力と出力、および特定のリソースのサイジングに使用するモデルについても説明します。さまざまなコンタクト センターのサイジング ツールが利用できます。これらはすべて 2 つの基本トラフィック モデルのアーラン-B および アーラン-Cを使用します。

- アーラン-B の使用

- アーラン-C の使用

アーラン-B の使用

アーラン-B モデルは、PSTN トランク、ゲートウェイ ポート、または VRU ポートのサイジングに使用します。以下が前提となります。

- コールはランダムに着信する。

- すべてのトランクまたはポートが使用中の場合、新しいコールは損失するかブロックされ（ビジートーンを受信し）、キューには入りません。

アーラン B モデルの入力と出力は、以下の 3 つの要素で構成されています。要因のうち、いずれかの 2 つがある場合、モデルが 3 番目を計算します。

- 最繁時トラフィック（BHT）BHT とは、最繁時のコール数（BHCA）と平均処理時間（AHT）の積です。

- サービス グレード

- ポート (回線)

アーラン-C の使用

コールをエージェントに提示する前にキューに入れるコンタクト センターのエージェントのサイジングを決定するには、アーラン-C モデルを使用します。このモデルは以下を想定しています。

- コールはランダムに着信する。

- すべてのエージェントがビジーの場合、着信コールはキューに入れられ、ブロックされません。

このモデルに必要な入力パラメータは以下の通りです。

- 最繁時にエージェントが応答するコール数（BHCA）

- 平均通話時間および後処理時間

- 希望する遅延またはサービス レベル。これは指定した秒数内に応答したコールの割合として表されます。

このモデルの出力は、必要なエージェント数、エージェントが利用できない場合に遅延するコールの割合、および平均キュー時間を提供します。

Unified CCE 向けダイナミック設定の制限

場合によっては、別のリソースの使用を大幅に減らすことにより、あるリソースの標準制限は超過させることもできます。ソリューションに組み込む前に、計画する特定のトレードオフを一覧にします。以降のセクションでは、特定のリソースのバランスの仕方についてのガイダンスを説明します。

- エージェントあたりのスキル グループとプレシジョン キューに対する動的制限

- その他の動的サイジング要因

- モバイル エージェントと PG エージェントの容量

エージェントあたりのスキル グループとプレシジョン キューに対する動的制限

エージェントあたりのスキルグループ数とポスト コール調査数は、Unified CCE のサブコンポーネントに大きな影響を与えます。

- Cisco Finesse サーバ

- Agent PG

- ルータ

- Logger

Note

スキル グループとプレシジョン キューに対する共通の用語としてキューを使用しています。

ソリューションのパフォーマンスを維持するには、定期的に未使用のキューを削除します。

リファレンス設計では、各 PG のエージェントあたりの平均キュー数に対して標準の上限が設定されています。特定の PG において、一部のエージェントに他のエージェントよりも多くのキューを設定できます。PG のエージェント全体の平均値が制限内である限り、PG に最大数のアクティブ エージェントを設定できます。

たとえば、4000 エージェントのリファレンス設計で PG に 3 つのエージェント グループがある場合を想定してください。

- グループ A には、5 つのキューを持つ 500 のエージェントが含まれています。

- グループ B には、15 のキューを持つ 1000 のエージェントが含まれています。

- グループ C には、25 のキューを持つ 500 のエージェントが含まれています。

これらの 3 つのグループを平均すると、エージェントあたり 15 キューとなるため、標準の上限で単一の PG にそれらすべてを設定できます。

また、各 PG とシステム全体のエージェント数を減らすと、標準の上限を超えることができます。

Note

標準制限については、構成制限の章の構成表を参照してください。

Cisco Finesse サーバでは、未使用キューの統計情報は表示されません。つまり、設定されているキューの総数よりも、アクティブなキューの数のほうが Cisco Finesse サーバのパフォーマンスに影響します。

Cisco Finesse デスクトップは、10 秒間隔でキュー（スキル グループ）の統計情報を更新します。Cisco Finesse デスクトップは、一定数のキュー統計情報フィールドをサポートしています。これらのフィールドは変更できません。

次の表は、エージェントあたりのキューの増加と、それに伴うソリューションでサポート可能なエージェント数の減少について概算を示しています。

エージェントとキューの動的制限

エージェントあたりのキュー平均数

PG あたりの最大エージェント数

2000 エージェントのリファレンス設計の最高エージェント数

4000 エージェントのリファレンス設計の最大エージェント数[1]

12000 エージェントのリファレンス設計の最高エージェント数

24000 エージェントのリファレンス設計の最高エージェント数

10

2000

2000

4000

12000

24000

15

2000

2000

4000

12000

16000

20

1500

1500

3000

9000

12000

30

1000

1000

2,000

6000

8000

40

750

750

1500

4500

6000

50

600

600

1200

3600

4800

[1] Rogger 展開では 4000 よりも多いエージェントを設定できません。

Unified CCE は、スーパーバイザチームのエージェント全体で最大 50 の一意のスキルグループをサポートします。これにはスーパーバイザ自身のスキルグループも含まれます。この数値を超えても、スーパーバイザによってモニタされるすべてのスキル グループは、引き続きスーパーバイザ デスクトップに表示されます。ただし、この数値を超えるとパフォーマンス上の問題が引き起こされる可能性があり、数値の超過はサポートされません。

Note

設定されたプレシジョン キューは、各 Agent PG に対してスキル グループを作成し、PG あたりのサポートされるスキル グループ数までカウントしていきます。スキル グループは、プレシジョン キューと同じメディア ルーティング ドメインに作成されます。

その他の動的サイジング要因

さまざまな要因によってソリューションのサーバ要件や容量が影響を受ける可能性があります。以下の項では、主要なサイジング変数とそれらがソリューションに影響を及ぼすしくみについて説明します。

最繁時呼数（BHCA）

BHCA が増加すると、すべてのソリューション コンポーネントの負荷が増加し、特に Unified CM、Unified CVP、Agent PG の負荷が増加します。エージェントに対する推定許容数は、1 時間にエージェントあたり最大 30 コールです。ソリューションでさらに高い BHCA が必要な場合は、Agent PG の最大エージェント数を削減します。

Unified CM のサイレント モニタリング

サイレント モニタリングされるコールごとに、PG と Unified CM の処理が増します。サイレント モニタリングされる各コールは、2 つのモニタされないエージェント コールに匹敵します。モニタリングされるコールの割合を受容できる余裕を PG に残してください。

スクリプトの複雑さ

Unified CCE スクリプトの複雑さと数が増加すると、コール ルータと VRU PG のプロセッサおよびメモリのオーバーヘッドが大幅に増加します。データベース クエリなどの機能を使用すると VRU スクリプトの複雑さが増加するので、CVP とルータに対する負荷も増加します。RunExternalScript の再生間での遅延時間も影響を及ぼします。

複雑なスクリプトおよびデータベース クエリのパフォーマンスは、特徴付けることが困難です。ラボで複雑なスクリプトをテストして、さまざまな BHCA でのデータベース クエリの応答時間を調べてください。音声ブラウザ、Unified CVP、PG、ルータのプロセッサやメモリに対する影響を受容できるように、サイジングを調整してください。

サードパーティのデータベースと Cisco Resource Manager の接続

外部デバイスとソフトウェアに対する Unified CCE ソリューション コンポーネントの接続を詳しく調べ、ソリューションに対する全体的な影響を確認してください。Contact Center Enterprise ソリューションは柔軟でカスタマイズ可能ですが、複雑でもあります。一般的に、コンタクト センターは、収益を創出する非常に重要なカスタマー応対業務です。ソリューションの設計に役立つように、適切なエクスペリエンスと認定を備えたシスコ パートナー（またはシスコ アドバンスド サービス）を関与させてください。

拡張コール コンテキスト（ECC）（Expanded Call Context (ECC)）

ソリューションでの ECC 変数の使用は、PG、ルータ、Logger、ネットワーク帯域幅に影響を及ぼします。さまざまな方法で ECC 変数を設定して使用できます。容量への影響は ECC の設定に応じて異なります。

モバイル エージェントと PG エージェントの容量

中規模の PG OVA でのモバイルエージェントのサポートキャパシティは次のとおりです。

- 2000（固定接続 1:1）

- 平均処理時間が 3 分未満の場合、またはエージェントグリーティングまたはウィスパーアナウンスメント機能が モバイルエージェント（1.3:1）と一緒に使用された場合、1500 固定接続

- 800（コールバイコール接続 2.5:1）

同じ PG 上にモバイルエージェントとその他のエージェントを混在させることができます。エージェントの各タイプの重みに注意してください。たとえば、200 名のモバイルエージェントに固定接続がある場合、PG は 1800 人の他のエージェントをサポートできます。

Additional Agents Allowed = (2000 – (200 * 1)) = 1800 Agents

代わりに、コールバイコール接続による 200 のアクティブなモバイルエージェントを計画している場合、PG は他のエージェントを 1500 サポートできます。

Additional Agents Allowed = (2000 – (200 * 2.5)) = 1500 Agents

リファレンス設計ソリューションの設定制限

- Unified CVP 向けサイジング

- Unified CM クラスタのサイジング

- コンポーネントおよび機能の拡張性に関する影響

- レポート向けリソース要件

- Unified Contact Center 管理ポータル向けサイジング

Unified CVP 向けサイジング

コンタクトセンターをサイジングする際、各状態にあるコールの数の最悪の場合のプロファイルを決定します。たとえば、最頻時に最もビジーなインスタントでコンタクト センターを確認する場合は、以下の状態にあるコール数を確認します。

- セルフ サービス：VXML サーバを使用してアプリケーションを実行するコール。

- キューとコレクト：エージェントのキューに入っているコール、またはプロンプトおよびコレクト タイプのセルフ サービス アプリケーションを実行するコール。

- 通話中：エージェント、またはサードパーティの TDM VRU アプリケーションに接続されるコール。

Note

これらのコールの状態の定義は、ポート ライセンシングの目的で使用される定義とは若干異なります。サイジング目的で、どのコールがどの状態にあるかをカウントする際、ASR および TTS 処理は無視できます。ただし、ASR および TTS 処理は、ライセンスの呼び出し状態のカウントに含まれます。

ソリューションは、通話状態のコールをエージェントに転送するために使用するポート数に応じてサイジングします。Unified CCE エージェントを使用する場合、これらのポートのライセンスは必要ありませんが、TDM エージェントには Call Director ライセンスが必要です。

通話中の状態のコールの場合、Unified CVP またはゲートウェイのリソースを使用しているコールのみをカウントします。転送で VoIP が使用されている場合、コールは音声ブラウザのポートと Unified CVP リソースを使用します。Unified CVP は呼び出しを監視し続け、後で取得して再配信できるようにします。Unified CVP はまた、TDMターゲットへの呼び出しを監視し続けます。これらのコールは、同じゲートウェイまたは異なるゲートウェイ（つまり、トール バイパス）で着信と発信の両方の TDM ポートを使用します。こういったコール タイプは両方とも通話中のコールとしてカウントされます。

ただし、転送で * 8 TNT、フックフラッシュ、2 B チャネル転送（TBCT）、または ICM NIC が使用される場合、ゲートウェイと Unified CVP は何らの役割を果たしません。両方のコンポーネントがリソースを再利用します。上記の通話はコール数にカウントされません。

キューイングまたはセルフサービスのために Unified CVP に戻されるコールを全体のコール カウントに含めます。たとえば、ウォーム転送では、Unified CVP はルーティング後の段階でエージェントをキューに入れます。コールは、Unified CVP の2つの個別のコール制御セッションに2つのポートを使用します。通常、転送は全体の通話量のごく一部であり、見落してしまう可能性があります。

全体的なスナップショット プロファイルに加え、最繁期間の CPS も考慮します。正確な最大到達率を特定するのが困難であるため、Contact Center Enterprise ソリューション全体でのこの情報が必要となります。この値は、統計的手段を使用して求めることもできます。

処理されるコールの数と最大コール着信レートに合わせて、Unified CVP サーバのサイジングを行います。

コール フローの CVP サーバ コール レート

通話フロー

サポートされる同時コール

1 秒あたりのコール

セキュア/非セキュアな SIP を使用した包括的なコールフロー

3000

15

セキュア/非セキュアな SIP、セキュア HTTP を使用した包括的なコールフロー

2500

15

リクエスト ICM ラベルあり/なしスタンドアロン

3000

15

リクエスト ICM ラベルおよびセキュアな HTTP あり/なしのスタンドアロン

2000

15

Note

秒あたりのコールについては、ソリューション内のすべてのイングレス ゲートウェイから CVP コールサーバで受信される最大コールレートであり、WAAG が有効になっている最悪のシナリオを想定しています。

- CVP コール サーバのサイジング

- CVP VXML サーバのサイジング

- Contact Center Enterprise ソリューション向けサイジング ゲートウェイ

- 基本ビデオサービスのサイジング

- CVP Reporting Server のサイジング

CVP コール サーバのサイジング

ソリューションには、以下の数式で与えられるより多くのコール サーバが必要です。

(Self Service) + (Queue and Collect) + (Talking) / Simultaneous Calls Supported, rounded up
OR
(Average call arrival rate) / Calls Per Second, rounded up.

また、クラスタ内のサブスクライバ間で Unified CM クラスタへのコールを分散します。サブスクライバあたり 2 CPS を超過しないでください。

詳細に関しては、Unified CVP のサイジング の コール フローの CVP サーバ コール レート の表を参照してください。

- ログ ディレクトリのサイズ概算

ログ ディレクトリのサイズ概算

次の式を使用して、コール サーバのディレクトリ ログ ファイルの 1 日当たりの概算領域（ギガバイト単位）を計算します。

3.5 GB * R

R は、毎秒のコール数です。

適切なサービスアビリティのために、5 ～ 7 日分のログ メッセージを保持するのに十分な領域を確保します。

CVP VXML サーバのサイジング

単一の VXML サーバは「Unified CVP のサイジング」セクションの「コール フローの CVP サーバ コール レート」の表のとおりのコール数を処理することができます。VXML サーバ を使用している場合、次の公式に従ってサイジングします。

Calls / Simultaneous Calls Supported, rounded up

コール数 とは、時間内にスナップショットで VXML サーバ セルフサービス アプリケーションに存在するコール数を示します。

Note

UCS パフォーマンスの値については、 Cisco Unified Customer Voice Portal の仮想化 ページを参照してください。

適切な Cisco IOS リリースを使用すると、Unified CVP を設定して、VXML サーバおよび Unified CVP IVRサービスで HTTPS を使用することができます。

Note

メインラインの Cisco IOS はサポートされていません。

CVP VXMLサーバのパフォーマンスは、VXMLアプリケーションの複雑性によって異なります。

- CUSP パフォーマンス ベンチマーク

CUSP パフォーマンス ベンチマーク

ソリューションで CUSP を使用する場合、以下の点に注意します。

- CUSP 基準テストはプロキシ上で隔離して行われています。上記テストのキャパシティ数は、450 TCP または 500 UDP トランザクション / 秒です。この数値は、許容できる最もストレスのかかる状態であるとみなします。

- プロキシ サーバからの CVP コールには、平均で 4 つの個別の SIP コールが必要です。発信者のインバウンド レッグ、VXML アウトバウンド レッグ、着信音アウトバウンド レッグ、およびエージェント アウトバウンド レッグです。

- CVP キューイングとのコンサルテーションが発生すると、セッションにはさらに 4 つの SIP トランザクションが発生し、コール数が事実上 2 倍になります。

Contact Center Enterprise ソリューション向けサイジング ゲートウェイ

Cisco ゲートウェイのコールのキャパシティは、イングレスのみを行うか、VXML のみを行うか、この 2 つの組み合わせを行うかによって異なります。音声ブラウザの容量も、ASR / TTSサービスや VXML アプリケーションの種類などの要因によって変化します。たとえば、JavaScript を多用するアプリケーションではコール容量が少なくなります。

通常、イングレスを実行するゲートウェイのサイズは、TDM ケーブル接続ポイントの最大数に制限することができます。

音声ゲートウェイをサイジングする前に、Unified CCE Resource Calculator を使用して、ソリューション全体をサポートするために必要な最大トランク数（DS0）と、VXML VR ポート数を判断してください。

次の表に、各 Cisco IOS バージョンのサイジング情報を示します。サイジング情報は次の要素に基づきます。

- 合計 CPU 使用率が 75％ を超えることはありません。

- サイジングは、ゲートウェイ上の最大同時 VXML セッション数および VoIP コール数を表します。

- サイジングは、Unified CVP VXML のマニュアルに基づいています。

- サイジングには、アクティブな会議とアクティブな転送が含まれます。

- 「VXML のみ」欄のサイジングには、ゲートウェイで実行される基本的なルーティングおよび IP 接続のみが含まれます。Fax など、コンタクト センター外トラフィックを必要とするアプリケーションを追加で実行する場合は、そのトラフィックも展開の容量に含める必要があります。「VXML + PTSN」欄に示される VXML セッションと音声コールの数は、同じゲートウェイ上で同時にサポートされる数です。

- サイジングは、Cisco コール サーバまたは Cisco Unified CVP VXMLサーバを使用することを前提としています。

- 各ゲートウェイは、通常の動作時に、冗長ペアと負荷を共有するよう設定します。通常の動作では、各ゲートウェイは、容量の半分近くのロードを処理します。フェールオーバー シナリオでは、各ゲートウェイは、サポートされている最大負荷で動作します。

- 各ポートは ASR/TTS を含む TDM および VXML 機能を提供します。

Cisco Voice Gateway（Cisco IOS リリース 15.1.4.M7 以降）でサポートされる VXML セッションの最大数

Cisco IOS リリース 15.1.4.M7 以降の VXML ゲートウェイ CPU 容量

プラットフォーム

VXML のみ

VXML + PSTN

メモリ

DTMF

ASR

DTMF

ASR

推奨

5000XM

200

135

155

104

512 MB

2901

12

8

9

6

2 GB

2911

60

40

47

31

2 GB

2921

90

60

71

48

2 GB

2951

120

80

95

64

2 GB

3925

240

160

190

127

2 GB

3945

340

228

270

180

2 GB

3925E

475

450

380

375

2 GB

3945E

580

550

460

450

2 GB

ISO 15.1.4.M7、G.711、基本コール、Ethernet 出力、CPU NTE 75%（5000XM 80%）に基づく

Note

単一の組み合わせゲートウェイが、VXML セッションおよび VoIP コールの同時発生数を上回ることはできません。

JavaScript を多用するアプリケーションを実行する Cisco Voice Gateways（Cisco IOS リリース 15.1.4.M7 以降）でサポートされる VXML セッションの最大数

Cisco Voice Gateway プラットフォーム

専用 VXML ゲートウェイ

音声ゲートウェイおよび VXML

VXML および DTMF

VoiceXML および ASR/TTS

VXML および DTMF

VoiceXML および ASR/TTS

推奨されるメモリ

AS5350XM

105

85

110

70

512 MB（デフォルト）

AS5400XM

105

85

110

70

512 MB（デフォルト）

HTTPS を使用する Cisco Voice Gateway（Cisco IOS リリース 15.1.4.M7 以降）でサポートされる VXML セッションの最大数

Cisco Voice Gateway プラットフォーム

専用 VXML ゲートウェイ

音声ゲートウェイおよび VXML

VXML および DTMF

VoiceXML および ASR/TTS

VXML および DTMF

VoiceXML および ASR/TTS

推奨されるメモリ

3945E

510

342

408

270

2 GB

AS5350XM

155

120

138

95

512 MB（デフォルト）

AS5400XM

155

120

138

95

512 MB（デフォルト）

Note

上記の表 に示されるパフォーマンスの数値は、HTTPS を使用する Cisco 音声ゲートウェイの記載モデルのみに該当する数値です。表 11 に示していないルータ モデルのパフォーマンスの数値を見積もる場合は、3945E ルータの HTTPS パフォーマンス数値を使用してください。

着呼率が表に示す容量を超えないようにするには、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の 『Cisco Collaboration System Solution Reference Network Designs』 に記載の「コンタクト センター トラフィックのゲートウェイのサイジング」を参照してください。

CPU 使用率

すべてのゲートウェイで、合計 CPU 使用率が平均で 75 パーセント未満であることを確認してください。次の要因が CPU 使用率に影響します。

- コール数/秒（CPS）

- 最大同時コール

- 最大同時 VXML セッション数

- JavaScript を多用するアプリケーション

メモリの考慮事項

注文する DRAM とフラッシュ メモリの量を検討してください。マシンにデフォルトで付属している容量は、ほとんどの目的に十分です。ただし、アプリケーションで以下が必要な場合は、フラッシュ メモリを拡張するために DRAM の量を増やすことを検討してください。

- 多数の個別の .wav ファイル（複雑なセルフサービス アプリケーションと同様）

- 異常に大きな .wav ファイル（拡張ボイス メッセージまたは音楽ファイルの場合など）

Note

現在の Cisco IOS リリースでは、HTTP キャッシュを 100 MB までしか拡張できません。

サードパーティの VXML アプリケーションに関する考慮事項

Cisco 以外の VXML アプリケーションを使用する場合は、展開において CPU 使用率の要件に従う必要があります。外部 VXML アプリケーションを実行している場合は、完全負荷状態の Cisco ゲートウェイで十分なメモリ量が使用可能であることを確認してください。

パフォーマンスと可用性の情報については、該当アプリケーションのプロバイダーに問い合わせてください。Cisco は、Cisco 環境で相互運用する場合、サードパーティの VXML アプリケーションのパフォーマンス、安定性、または機能の能力に関して、いかなる請求も保証も行いません。

CUBE および仮想 CUBE に関する考慮事項

Cisco UBE の物理あるいは仮想サイジングの詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-border-element/products-installation-and-configuration-guides-list.htmlの Cisco Unified Border Element コンフィギュレーション ガイド を参照してください。

CUBE のセッション キャパシティ情報については、https://www.cisco.com/c/en/us/products/unified-communications/unified-border-element/datasheet-listing.htmlの Cisco Unified Border Element データ シート を参照してください。

Note

CVP の包括的なコール フローは、Unified CM を使用した VoIP コール フローで、コール レッグ毎に標準の 7 件を超えるメッセージを使用します。このため、Contact Center Enterprise ソリューションの CUBE セッションのサイズは以下の通りです。

- ISR G2 の拡張性は、標準 CUBE セッションのキャパシティの 40% です。ASR1K および ISR4K シリーズの拡張性は、約 75％ 少なくなります。

- プラットフォームの DSP の量により、CPA の数値が制限されます。CPA は高複雑度として扱います。

- CUBE は、コール録音サーバへのメディア分岐用の SIP セッションを確立します。CUBE 制御の録音または Unified CM 制御の録音を使用する場合、全体のサイジングに各録音の追加セッションを追加します。

- 同じ CUBE で CVP セッションと録音セッションを混在させることができます。CUBE を適切にサイジングするには、セッションを共に追加します。たとえば、コール録音のために 1,000 件の CVP セッションと 1,000 件の分岐セッションがある場合、ISR G2 の CUBE 予想負荷はおおよそ以下の通りです。

(1000 CVP * 1.66 for performance impact) + 1000 Recording = 2660 total sessions

ASR 1K/ISR 4K 上、予想される負荷はおおよそ以下の通りです。

(1000 CVP * 4 for performance impact) + 1000 Recording = 5000 total sessions

合計セッションを使用して、CUBE モデルがサポートする標準 SIP セッションに対するサイズを決定します。

Important

トランスコーダや MTP リソースなどの複数のサービスを CUBE でアクティブ化する際の CUBE のサイズ設定は、さらに複雑になります。Cisco アカウント チームに相談して、CUBE チームにお問合わせください。複雑な CUBE 展開の適切なサイジングをサポートします。

基本ビデオサービスのサイジング

Contact Center Enterprise ソリューションにビデオ対応エージェントを含めることができます。

包括的なコール フローで、ビデオ コールと従来の音声コールの両方に同じ Unified CVP コール サーバを使用できます。非レファレンス コール フローの場合は、ビデオ コールと音声コールに別々のコール サーバを使用します。

基本的なビデオ サービスは、包括的なコール フローを使用します。コール サーバ、VXML サーバ、および IOS VXML ゲートウェイが必要です。これらのコンポーネントのサイズは、音声コールの場合と同じ方法で決定します。

Cisco Unified Videoconferencing ハードウェア、Radvision IVP、および Radvision iContact は、基本ビデオサービスには必要ありません。

Note

Video コールは Cisco VVB ではサポートされません。

CVP Reporting Server のサイジング

CVP Reporting Server のサイジングには多数の変数が関係します。それぞれの VXML アプリケーションは、レポーティング データの量に影響する異なる特性を備えています。こうした特性の一部を次に示します。

- アプリケーションの要素のタイプ

- 必要なデータの粒度

- アプリケーション内のコール フロー

- コールの長さ

- コールの数

CVP Reporting Server をサイジングするには、最初に、VXML アプリケーションで生成されるレポート データの量を概算します。

使用しているアプリケーションで生成されるレポーティング メッセージの数を確認した後、各 VXML アプリケーションに対して次の手順を実行します。

1. アプリケーションが受信する CPS を概算します。

2. アプリケーションで生成されるレポーティング メッセージの数を見積もります。

次の等式を使って、VXML アプリケーションで毎秒生成されるレポート メッセージの数を判断します。

A# = %VXML * CPS * MSG

ここで、

- A# は、アプリケーションで生成される 1 秒あたりのレポーティング メッセージの推定数です。

- CPS は、1 秒あたりのコールの数です。

- %VXML は、VXML アプリケーションを使用するコールの割合です。

- MSG は、このアプリケーションが生成するレポート メッセージの数です。

ソリューションの各 VXML アプリケーションの値を合計して、ソリューションに対する 1 秒あたりのレポート メッセージの推定数を割り出します。

各 CVP Reporting Server は、1 秒あたり 420 のメッセージを処理できます。ソリューションで複数の CVP Reporting Server が必要な場合は、VXML アプリケーションを分割して、特定の Reporting Server を使用するようにします。

- 複数の CVP レポート サーバを含むソリューション

- CVP Reporting Server のメッセージの詳細

Related Concepts

CVP Reporting Server のメッセージの詳細

複数の CVP レポート サーバを含むソリューション

複数の CVP レポート サーバを必要とするソリューションでは、展開を垂直方向に分割します。

レポート データの負荷を分散するために垂直分割する場合は、以下の要件とガイドラインを考慮します。

- 各コール サーバと VXML サーバを単一の CVP レポート サーバのみに関連付けます。

- 複数の Informix データベースにまたがったレポートを作成することはできない。

- コール処理メッセージとアプリケーション メッセージを合計した場合に、単一のレポート サーバがサポートするよりも多くのメッセージを生成する複数のアプリケーションを分割します。

- VXML をフィルタすることができます。不要なデータをフィルタで除外すると、より多くのメッセージ量をサポートする使い勝手の良いデータ リポジトリが作成されます。

- ダイヤル プランやその他の使用可能な方法を設定して、着信コールを適切なコール サーバおよび VXML サーバに転送します。

要件の詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.htmlの 『Cisco Unified Customer Voice Portal レポーティング ガイド』 を参照してください。

複数のデータベースからデータを組み合わせる場合は、以下のオプションを使用することができます。

- レポート データをスプレッドシートなどの別の形式にエクスポートして、データベース外のデータを結合します。

- レポーティング データを CSV ファイルにエクスポートし、それをユーザ指定のデータベースにインポートします。

- ユーザ指定のデータ ウェアハウスにデータを抽出し、そのデータに対するレポートを実行します。

CVP Reporting Server のメッセージの詳細

次の表は、さまざまな要素またはアクティビティによって生成されるレポート メッセージの数を示しています。

要素またはアクティビティ毎のレポーティング メッセージ数

要素またはアクティビティ

レポーティング メッセージの数（フィルタリングなし）

開始

2

終了

2

Subflow Call

2

Subflow Start

2

Subflow Return

2

Throw

2

アラート

2

Subdialog_start

2

Subdialog_return

2

ホットリンク

2

HotEvent

2

オーディオなしの転送

2

オーディオなしの流通

2

フラグ

2

アクション

2

決定

2

アプリケーション転送

2

VXML エラー

2

CallICMInfo（コールごと）

2

Session Variable（変更ごと）

2

Custom Log（アイテムごと）

2

Play（音声ファイルまたは TTS）

2

LeaveQueue

2

Callback_Disconnect_Caller

3

Callback_Add

4

Callback_Get_Status

4

Callback_Set_Queue_Defaults

4

Callback_Update_Status

4

Callback_Enter_Queue

5

Callback_Reconnect

5

Get Input（DTMF）

5

Callback_Validate

6

Get Input（ASR）

9

フォーム

10

Digit_with_confirm

20

Currency_with_confirm

20

ReqICMLabel

30

Note

アプリケーションごとにこれらの要素が必要です。これらはフィルタリングできません。

Unified CM クラスタのサイジング

Unified CM クラスタは、統合 IP ネットワーク インフラストラクチャ全体にコール処理を分散するメカニズムを提供します。また、クラスタは冗長性を促進し、機能の透過性とスケーラビリティを提供します。

Unified CM クラスタのビューの詳細については、http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

- クラスタ サイジングの概念

- クラスタのガイドライン

クラスタ サイジングの概念

ソリューションの Unified CM クラスタのサイズを決定する前に、以下の設計タスクを実行します。

- さまざまな種類のコール フローを決定します。

- 必要な展開モデル (単一サイト、集中型、分散型、WAN 経由のクラスタリング、または集中型または分散型展開内のリモート ブランチ) を決定します。

- 使用するプロトコルを決定します。

- 冗長性の要件を決定します。

- クラスタを Unified CCE 展開と共有する、Cisco Unified Communications の他のすべての顧客要件を決定します。たとえば、Cisco Unified IP フォン、Unified CCE の一部ではないアプリケーション、ルート パターンなどを検討します。

上記タスクを完了したら、必要なクラスタの正確なサイジングを開始することができます。クラスタのサイジングには多くの要因が影響を与えます。以下の一覧では、これらの要因の一部について説明しています。

- オフィスの電話機の数と電話毎の最繁時通話試行（BHCA）レート

- 着信エージェント電話の数と電話毎の BHCA レート

- 上記 VoIP エンドポイントの CTI ポート数および BHCA レート。(Unified CVP をコール処理、セルフサービス、およびキューイングに使用する場合、上記要因が適用されない場合があります。)

- 上記 VoIP エンドポイントの音声ゲートウェイのポート数および BHCA レート。

- 発信エージェントの電話機の数、発信ダイヤル モード、および電話機毎の BHCA レート

- アウトバウンド ダイヤラ ポートの数、アウトバウンド キャンペーンの VRU ポート数、および両方のポート毎の BHCA レート

- モバイル エージェントの数とモバイル エージェントあたりの BHCA レート

- 上記 VoIP エンドポイントへのボイスメールのポート数および BHCA レート。

- VoIP エンドポイントで使用されるシグナリング プロトコル

- エージェントのコール転送と会議の割合（％）

- ダイヤル番号、回線、パーティション、コーリング サーチ スペース、ロケーション、地域、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート一覧数など、ダイヤル プランのサイズと複雑度

- トランス コーディング、会議、暗号化などの機能に必要なメディア リソースの量

- CTI Manager、E-911、保留音楽などの共存アプリケーションおよびサービス

- Unified CM リリース (リリースによりサイジングは異なります)

- Unified CM OVA のタイプ

他の要因がクラスタのサイジングに影響を与える可能性があるとはいえ、上記がリソース消費の観点から最も重要な要因となります。

通常、これらの各要因のリソース消費（CPU、メモリ、および I / O）を推定して、Unified CM クラスタのサイジングを行います。次に、リソース要件を満たす VM を選択します。クラスタを正確にサイジングする前に、上記要因に関する情報を収集します。

クラスタのガイドライン

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

- すべてのプライマリおよびバックアップ サブスクライバは、同じOVFテンプレートを使用する必要があります。クラスタ内のすべてのサブスクライバは、同じ Unified CM ソフトウェア リリースとサービス パックを実行する必要があります。

- クラスタ内では、Cisco Call Manager サービスで最大 8 つのサブスクライバ（4 つのプライマリ サブスクライバおよび 4 つのバックアップ サブスクライバ）を有効にすることができます。TFTP、パブリッシャ、保留音などの専用機能に、より多くの VM を使用することができます。

- 4000 エージェントのリファレンス設計では、単一の Unified CM クラスタで約 4,000 人のエージェントをサポートすることができます。12,000 エージェントのリファレンス設計では、4 つのプライマリおよび 4 つのバックアップ サブスクライバを持つ Unified CM クラスタで約 8,000 人のエージェントをサポートすることができます。上記の制限は、BHCA コールの負荷および設定されたすべてのデバイスが、1 対 1 の冗長性を備えた 8 つのコール処理サブスクライバに均等に分散されることを前提としています。これらのキャパシティは、特定の展開に応じて異なります。ソリューションのサイジングを Cisco Unified Communications Manager キャパシティ ツールで行います。

サブスクライバは最大 1,000 人のエージェントをサポートすることができます。フェールオーバー シナリオでは、プライマリ サブスクライバは最大 2,000 人のエージェントをサポートします。

Note

4000 エージェント リファレンス設計では、4 つのサブスクライバ（2 つのプライマリおよび 2 つのバックアップ）を持つクラスタが最大負荷をサポートできます。さらに多くのサブスクライバのクラスタを作成する場合、クラスタの最大エージェント数の 4,000 人を超過させないようにします。

適切な数の CTI リソースのコンタクト センター ソリューションをサポートするようにクラスタのサイジングを行う場合は、以下を考慮します。

- ログインしていないエージェントの設定済電話数

- 通話録音、アテンダント コンソール、PC クライアントなど、デバイスをリモートで制御するアプリケーション

- CTI リソースを消費するその他のサードパーティ アプリケーション

たとえば、Unified CMは、複数の回線、コンタクト センター、および録音が同時に使用される場合など、複数の同時 CTI リソースをサポートすることができます。これらのCTIリソースは、『Cisco Collaboration System Solution Reference Network Designs』で説明されている通りの CTI ルールに従います。

- デバイス（電話、保留音、ルート ポイント、ゲートウェイ ポート、CTI ポート、JTAPI ユーザ、および CTI Manager を含む）は、パブリッシャに常駐させたり、登録してはなりません。パブリッシャに登録されているデバイスがある場合、Unified CM の管理作業は、コール処理と CTI Manager アクティビティに影響を与えます。

- 実稼働環境では、パブリッシャをフェールオーバーまたはバックアップのコール処理サブスクライバとして使用しないでください。逸脱する場合は、Cisco Bid Assurance による個別のレビューが必要となります。

- 150 台以上のエージェント電話を使用する展開では、少なくとも 2 つのサブスクライバ、TFTPおよびパブリッシャの組み合わせが必要です。ロード バランシングは、パブリッシャがバックアップ コール処理サブスクライバである場合には実装できません。

- 構成をサポートするために複数のプライマリ サブスクライバが必要な場合は、すべてのエージェントをサブスクライバ ノード間に均等に分散します。この構成では、BHCA レートがすべてのエージェントで均一であると想定しています。

- 同様に、すべてのゲートウェイ ポートと CTI ポートをクラスタ ノード間で均等に分散します。

- 一部の展開では、複数の Unified CCE JTAPI ユーザ（CTI Manager）と複数のプライマリ サブスクライバが必要です。これらの展開では、可能であれば、同じ VM 上で、Unified CCE ルート ポイントやエージェント デバイスなど、同じ Unified CCE JTAPI ユーザ（サードパーティ アプリケーション プロバイダー）によって監視されるすべてのデバイスをグループ化して構成します。

- CTI Manager は呼処理サブスクライバでのみ有効にします。これにより、クラスタ内で最大 8 つの CTI Manager が利用できます。最大の復元力、パフォーマンス、および冗長性を提供するには、クラスタ内のさまざまな CTI Manager 全体で CTI アプリケーションの負荷を分散します。CTI Manager に関する考慮事項の詳細は、 http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

- Unified CCE と一般的なオフィスの IP フォンが混在するクラスタがある場合は、可能ならば、各タイプを個別の VM でグループ化および構成します（単体サブスクライバのみが必要な場合を除く）。たとえば、すべての Unified CCE エージェントおよびそれらに関連付けられたデバイスとリソースを、1 つ以上の Unified CM サーバ上に配置します。その後、クラスタのキャパシティが許す限り、すべての一般的なオフィスの IP フォンおよびそれらに関連付けられたデバイス（ゲートウェイ ポートなど）は他の Unified CM サーバ上に配置します。Cisco Unified Communications Manager キャパシティ ツールを使用する場合、各プライマリ Unified CM サーバの特定のデバイス設定でツールを個別に実行します。このツールは、クラスタ内のすべてのデバイスのバランスが均等であると想定しているため、複数回実行する必要があります。Unified CCE では、1：1 の冗長性スキームを使用する必要があることに注意してください。

- 可能な限り、ハードウェア ベースの会議リソースを使用します。ハードウェアの会議リソースは、より費用対効果の高いソリューションを提供し、クラスタ内のスケーラビリティを向上させます。

- Unified CCE 周辺機器ゲートウェイ (PG) JTAPI ユーザのすべての CTI ルート ポイントを、その Unified CCE PG と通信する CTI Manager インスタンスを実行するサブスクライバ ノードに登録します。

- Cisco Unified Communications Manager キャパシティ ツールでは、現在、各 VM に対する CTI Manager の影響を個別に測定しません。ただし、CTI Manager はそのプロセスを実行しているサブスクライバに追加の負荷をかけます。このツールは、これらのサブスクライバに基づき、リソースの消費を報告します。その他の Unified CM サブスクライバの実際のリソース消費は、わずかに少ない可能性があります。

- コンタクトセンター エージェントが使用しない場合でも、Unified CCE PG JTAPI ユーザのすべてのデバイスは、エージェント デバイスとしてカウントします。エージェントが電話を使用していない場合でも、PG にはその電話のすべてのデバイス状態の変更が通知されます。エージェントがデバイスを定期的に使用しない場合、クラスタの拡張性を向上させるために、デバイスは Unified CCE PG JTAPI ユーザーに関連付けないでください。

- トレーシング レベル：Cisco Unified CM の CPU リソース消費は、有効なトレース レベルによって変化します。Unified CM でトレース レベルをデフォルトからフルに変更すると、高負荷時に CPU 消費が大幅に増加する可能性があります。Cisco Technical Assistance Center は、トレース レベルのデフォルトからトレースなしへの変更をサポートしていません。

- 通常の環境では、同一 LAN または MAN 内にクラスタのすべてのサブスクライバを配置します。クラスタのすべてのメンバーを同一の VLAN またはスイッチに配置することは推奨されません。

- クラスタが IP WAN にまたがる場合、このガイドおよび 『Cisco Collaboration System Solution Reference Network Designs』の WAN を介したクラスタリングに関するセクションの特定のガイドラインに従ってください。

サポートされるリリースの最新情報については、使用するソリューションの最新バージョンの 互換性マトリクスを参照してください。

Unified CM クラスタのガイドラインの詳細については、http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

コンポーネントおよび機能の拡張性に関する影響

一部のオプションのコンポーネントと機能は、ソリューションのスケーラビリティとキャパシティに影響を与えます。この表では、いくつかの影響を一覧にしています。

コンポーネントまたは機能

影響

IPSec

IPsec を有効化した場合:

- エージェント、VRU ポート、SIP ダイヤラ ポート、およびコール レートの PG 容量は 25％ 減少します。

- 最大通話率（毎秒通話数）は 25％ 減少します。

モバイル エージェント

Unified CCE はモバイル エージェントの電話機を直接制御しません。コールバイコールと固定接続の2つの配信モードでは、リソースの使用方法が異なります。

Cisco アウトバウンド オプション

アウトバウンド リソースは、キャンペーンのヒット レート、放棄制限、および通話時間に基づいて変化します。すぐに求められ、正確性には欠ける推定値では、アウトバウンド エージェント毎に 2 つのポートが必要というものです。技術的には、アウトバウンド コールに割り当てられた PG 毎に 2,000 人のエージェントを持つことができますが、ダイヤラはおそらくすべてのエージェントが完全に従事した状態を維持することはできません。サイジング ツールを使用して、キャンペーンに必要なアウトバウンド リソースを決定します。

エージェントのグリーティング

エージェント グリーティング機能は、ルータ、Logger、および Unified CM に影響します。

ルータおよび Loggerでは、この機能によりルート要求が増加します。これにより、最大通話レートが約 3 分の 1 に減少します。

拡張コール コンテキスト（ECC）

拡張コール コンテキスト (ECC) の使用の増加は、Unified CCE の重要なコンポーネントのパフォーマンスおよび拡張性に影響を与えます。キャパシティへの影響は、ECC 構成に基づいて異なるため、ケースバイケースの専門的なガイダンスが必要となります。

レポート向けリソース要件

クライアント マシンでは 10 以上の同時レポートを実行しないでください。これは、クライアント マシンの Unified Intelligence Center ユーザ インターフェイス、パーマリンク、およびダッシュボードで実行されるレポートの総合的な制限です。

ただし、各ノードの最大レポート ユーザ 200 人に対して 10 件の同時レポートを実行することはできません。キャパシティ テストでは、200人のレポート ユーザはそれぞれ以下のレポートを実行できることが示されています。

- 10 つのフィールドと 100 行から構成される 2 つの ライブデータレポート。

- 100 行ある 10 つのフィールドを含む 2 つの リアルタイムレポートは、15 秒ごとに更新できます。

- 8,000 行ある 10 つのフィールドを含む 2 つの 履歴レポートは、30 分ごとに更新できます。

ノード上のレポート ユーザが上記より少ない場合、さらに多くのレポートを実行することができます。しかし、クライアント マシンは、10 件のレポートの制限を超えることはできません。

Note

インターネット スクリプト エディタまたは管理クライアントを使用する各スクリプト エディタ監視ユーザは、1 人のレポート ユーザに相当します。

Unified Contact Center 管理ポータル向けサイジング

Unified CCMP では、いくつかの展開を提供しています。すべての展開では、サイト間でデータを複製する n 台のサーバ構成を想定しています。

Unified CCMP フォルダ構造をソリューションの組織構造にマップして、リソース管理を促進します。

仮想マシンのキャパシティ

配置

VM キャパシティ

CCMP の展開

エージェント (同時 / 設定済み)

設定済み CCMP ユーザ

フォルダ

フォルダ深度

4000 エージェント導入モデル

CCMP 小規模

4000 / 24000

400

400

5

12000 エージェント導入モデル

CCMP 大規模

12000 / 72000

1200

[1000]

6

24000 エージェント導入モデル

CCMP 大規模

24000 / 72000

1200

[1000]

6

Network Connections（ネットワーク接続）

Unified CCMP のネットワーク接続を設計する際は、以下の要因を考慮します。

- LAN: Unified CCMP システムを Unified CCE およびその他のサーバにギガビット（1000BASE-T）接続で接続します。

- WAN: Unified CCMP システムを Unified CCE に接続するため、または WAN を介した分散 CCMP 展開のために、少なくとも 1.5 MB /秒のキャパシティの専用リンクを割り当てます。

- ロード バランシング: 分散型 Unified CCMP システムは、ロード バランサを使用して、サイト全体に負荷を分散することができます。Windows の組み込み機能を使用せずに、専用のロード バランサを使用します。負荷分散ソリューションは、要求間の Web セッション情報を維持するためにスティッキ接続をサポートする必要があります。

Unified CCMP サーバのソフトウェア要件

Unified CCMP サーバのソフトウェア要件の詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-management-portal/tsd-products-support-series-home.htmlのUnified CCMP のドキュメンテーションを参照してください。

Note

単一サーバ システムの場合は、Web アプリケーション サーバとデータベース サーバの両方のソフトウェア要件および Unified CCMP コンポーネントを単一サーバにインストールします。単一サーバのシステムは、最小の展開のみをサポートします。

Cisco Virtualized Voice Browser

Cisco VVB のコール キャパシティは、ASR または TTS アクティビティのコール サポートと VXML アプリケーションのタイプに基づいています。たとえば、JavaScript を多用するアプリケーションでは、コール キャパシティが減少し、HTTPS を使用する VVB は HTTP を使用する場合よりもコール キャパシティが減少します。

全体の CPU 使用率が平均で 65％ 未満であることを確認してください。次の要因が CPU 使用率に影響します。

- コール数/秒（CPS）

- 最大同時 VXML セッション数

- VXML アプリケーションの複雑性

音声ゲートウェイをサイジングする前に、Unified CCE Resource Calculator を使用して、ソリューション全体をサポートするために必要な最大トランク数（DS0）と、VXML VR ポート数を判断します。

ほとんどすべての Unified CVP 展開モデルについて、サイジングは以下の要因に基づいています。

- 最大同時 VXML セッション数

- Cisco VVB が処理する CPS

Note

ASR および TTS 列にリストされているパフォーマンスの数値は、MRCPv1 および v2 にのみ適用されます。

システムの仕様

CPS

DTMF (非セキュア)

TTS / ASR (非セキュア)

DTMF / TTS / ASR (セキュア)

中規模 OVA (4 CPU, 8-GB RAM)

20

600

480

480

小規模 OVA (4 CPU, 6-GB RAM)

20

480

380

380

KVM [4451 (2 CPU - Gladen), 6-GB RAM]

6

120

96

96

KVM [4431 (6 CPU - Gladen), 6-GB RAM]

3

80

70

70

KVM [4351 (6 CPU - Rangley), 6-GB RAM]

3

60

50

50

KVM [4331 (6 CPU - Rangley), 6-GB RAM]

2

40

30

30

Note

- TLS / SRTPは、小規模または中規模のプロファイルで CPS を最大25％削減します。

- ASR / TTS を使用する TLS / SRTP は現在サポートされていません。

- セキュア: HTTPS / TLS / SRTPを介したセキュアなトランスポート

- これらの値は、Unified CVP VXML サーバで実行される Unified CVP Call Studio アプリケーションの VXML ページのパフォーマンスを示します。その他の VoiceXML アプリケーションではパフォーマンスが異なる場合があります。これらの数値は、CPU 使用率が 65％ 未満の VXML v2.0 および MRCPv1 または v2 を実行しているシステムの場合です。

これらの値は、Cisco Unified CVP VXML サーバ上の適度に複雑な VXML アプリケーションのテストを反映しています。多異なるアプリケーションではパフォーマンスが異なります。外部 VXML アプリケーション（Nuance OSDM など）のパフォーマンスは、Cisco 以外のアプリケーションと相互運用する際に典型的なパフォーマンスにはなりません。外部 VXML アプリケーションを実行している場合は、完全負荷状態の Cisco VVB で十分なメモリ量が使用可能であることを確認してください。パフォーマンスと可用性の情報については、該当アプリケーションのプロバイダーに問い合わせてください。

- Contact Center Enterprise ソリューションに追加された外部 VXM Lアプリケーションのパフォーマンス、安定性、または機能の能力に関して、Cisco はいかなる請求も保証も行いません。

- Cisco VVB では、HTTP キャッシュを 512 MB に拡張することができます。

- Cisco VVB で CPS を計算する際、受信するすべてのコール（VRU、リングバック、および WAAG ）を考慮してください。ソリューションの Cisco VVB への CPS を計算する際は、まず、CVP の各着信コールが使用するサービスを決定します。

たとえば、すべてのエージェントに対して WAAG を無効にした場合、Cisco VVB の合計 CPS は CVP で（2 x 着信レート）となります。これは、VRU の単一の呼び出しと単一のリングバックです。すべてのエージェントに対して WAAG を有効にする場合、WAV はさらに 2 つのコールを追加するため、Cisco VVB での CPS の合計は（4 x 着信レート）となります。

Cisco Finesse のサイジング

Cisco Finesse は、Cisco Finesse サーバペアごとに、HTTPS のどちらかを介して、最大 1800 エージェントそして 200 スーパーバイザまでサポートします。

輻輳制御のサイジング

輻輳制御は、高い通話率に起因する過負荷状態からルータ保護を行います。極端な過負荷が発生した場合、輻輳制御はシステムを定格キャパシティ付近で実行を続行します。

輻輳制御は過負荷状態時に、すべての通話に対するサービスの大幅な低下をもたらさずに、少ない割合のコールで満足のいくサービスを提供します。この機能は、コールのエントリ ポイントでコールを拒否することにより、システムをキャパシティ内に維持します。キャパシティ調整を行うことで、ルーティングされるコールがタイムアウトなしで許容可能なサービスを受けることが保証されます。

輻輳制御には、「呼び出し」には、ユニバーサル キュー API と音声呼び出しを使用するサードパーティのマルチチャネル アプリケーションからの非音声タスクが含まれます。輻輳制御は、上記呼び出しとタスクを同様に処理します。着信コールおよびタスクを監視および調整して、コールまたはタスクがシステムに入った後にドロップが発生しないようにします。つまり、転送と RONA は輻輳制御にカウントされ、スロットリングや拒否が発生しません。

別の例外として、音声通話でのマルチタスクの過程で、E メールなどのタスクを選択することがあります。輻輳制御は、上記のピック タスク要求を拒否しません。

Note

タスクが Unified CCE キューで待機中の場合を除き、システムの輻輳状態は、プル タスク要求は拒否されます。輻輳中であっても、Unified CCE システムの混雑解消に役立つため、Unified CCE キューからのプル タスク要求は許可されます。

Note

ビジネス チャットおよび E メールでは、転送されるメール タスクは新しいタスクと見なされ、調整の対象となります。

ルータで測定される CPS は、輻輳を識別するためのトリガです。展開タイプにより、ソリューションでサポートされる CPS キャパシティが設定されます。ルータは、すべてのルーティング クライアントからの新しい着信呼び出し要求を測定して、可変加重平均を計算します。平均 CPS がしきい値を超えると、輻輳レベルが変化し、削減率が増加します。輻輳制御アルゴリズムには、3 段階の輻輳レベルがあります。そのレベルの値により、着信コールを拒否または処理します。システムは、輻輳レベルの変化をルーティング クライアントに通知します。

Contact Director リファレンス設計では、輻輳制御は各インスタンスで測定されるコール レートに基づいています。Contact Director は、各ターゲットの輻輳レベルに関する情報を受け取ります。ルーティングの決定に必要な削減を適用します。また、INCRP ルーティング クライアントは、コールをターゲット インスタンスに送信する前に輻輳制御を適用します。

- 導入タイプの説明

- 輻輳処置モード

- 輻輳制御レベルおよびしきい値

- 輻輳制御 CPS の制限

導入タイプの説明

システムをアップグレードまたはインストールした後、システムを有効な展開タイプに設定します。次の表に、サポートされる展開タイプと、有効な展開タイプを選択するためのガイドラインを示します。

この表に記載の要件の詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.htmlの Cisco Collaboration の仮想化 サイトの使用するソリューション ページを参照してください。

導入タイプ

展開タイプ コード

展開名

選択に関するガイドライン

0

未指定

これはシステムのデフォルトの展開タイプです。このオプションは選択できません。 新規インストールまたはアップグレード後のデフォルト設定です。

1

NAM (廃止)

Contact Director 展開の NAM インスタンスにこの展開タイプを選択します。システムは、指定された要件を満たす異なる VM にインストールされたルータおよび Logger を使用して分散展開しなければなりません。この展開タイプではエージェントは許可されません。エージェントが設定済みでログインしている場合、キャパシティは Unified CCE 12000 エージェント ソリューションの最大容量に調整されます。

2

Contact Director

Unified CVP またはサードパーティ VRU システムを使用するセルフサービス コール フロー専用の ICM インスタンスに対して、この展開タイプを選択します。システムは、指定された要件を満たす異なる VM にインストールされたルータおよび Logger を使用して分散展開しなければなりません。この展開タイプではエージェントは許可されません。エージェントが設定済みでログインしている場合、キャパシティは Enterprise Contact Center (Unified CCE 12000 エージェントのルータ / Logger)の最大容量に調整されます。

3

NAM Rogger (廃止)

Contact Director 展開の NAM インスタンスにこの展開タイプを選択します。単一の VM に共存するルータおよび Logger は、指定された要件を満たしています。この展開タイプではエージェントは許可されません。エージェントが設定済みでログインしている場合、キャパシティは Enterprise Contact Center (Unified CCE 12000 エージェントのルータ / Logger)の最大容量に調整されます。

4

ICM Router/Logger

従来の TDM ACD PG および CCE PG の両方が展開されている ICM エンタープライズ システムのタイプには、この展開を選択します。システムは、指定された要件を満たす異なる VM にインストールされたルータおよび Logger を使用して分散展開しなければなりません。

5

UCCE 8000 エージェント ルータ / Logger

CCE PG のみが展開されている CCE エンタープライズ システムのタイプには、この展開を選択します。システムは、8000 CCE エージェントの指定された要件を満たす異なる VM にインストールされたルータおよび Logger を使用して分散展開しなければなりません。

6

UCCE 12000 エージェント ルータ / Logger

CCE PG のみが展開されている CCE エンタープライズ システムのタイプには、この展開を選択します。システムは、12000 CCE エージェントの指定された要件を満たす異なる VM にインストールされたルータおよび Logger を使用して分散展開しなければなりません。

7

Packaged CCE: 2000 エージェント

実稼働環境での Packaged CCE 展開の場合、この展開タイプを選択します。

8

ICM Rogger

従来の TDM ACD PG および CCE PG の両方が展開されている ICM エンタープライズ システムのタイプには、この展開を選択します。単一の VM に共存するルータおよび Logger は、指定された要件を満たしています。

9

UCCE 4000 Agents Rogger

CCE PG のみが展開されている CCE エンタープライズ システムのタイプには、この展開を選択します。単一の VM に共存するルータおよび Logger は、指定された要件を満たしています。

10

Packaged CCE: ラボ モード

実稼働環境での Packaged CCE ラボ展開の場合、この展開タイプを選択します。

11

HCS-CC 2000 エージェント

Cisco HCS for Contact Center ソリューションの 2000 エージェントのリファレンス設計にこの展開タイプを選択します。2000 エージェントのリファレンス設計のバリエーションである Cisco HCS for Contact Center 500 エージェント設計が含まれています。

13

UCCE: Progger (ラボのみ)

ルータ、Logger、および PG が同じ VM 上にない場合でも、すべてのラボ展開では、このタイプを選択します。

Note

この展開タイプは、実稼働システムではサポートされていません。

14

HCS-CC 4000 エージェント

Unified CCE PG のみが展開されている Unified CCE システムのタイプには、この展開を選択します。この展開は、4000 Unified CCE エージェントの要件を満たすその他のサーバ上のルータおよび Logger を備えた分散システム用です。

15

HCS-CC 12000 エージェント

Cisco HCS for Contact Center ソリューションの 12000 エージェントのリファレンス設計にこの展開タイプを選択します。

16

UCCE: 2000 エージェント

Unified CCE ソリューションの 2000 エージェントのリファレンス設計にこの展開タイプを選択します。

17

Packaged CCE: 4000 エージェント

Packaged CCE ソリューションの 4000 エージェントのリファレンス設計にこの展開タイプを選択します。

18

Packaged CCE: 12000 エージェント

Packaged CCE ソリューションの 12000 エージェントのリファレンス設計にこの展開タイプを選択します。

19

UCCE 24000 エージェント ルータ / Logger

Unified CCE ソリューションの 24000 エージェントのリファレンス設計にこの展開タイプを選択します。

20

HCS-CC 24000 エージェント

HCS-CC ソリューションの 24000 エージェントのリファレンス設計にこの展開タイプを選択します。

Note

構成中にソリューションの適切な展開タイプを設定することが肝心です。誤った展開タイプを選択すると、ソリューションでは過負荷保護されないか、不適切な容量設定に基づいてコールを拒否して処理します。

Note

Packaged CCE 展開タイプを選択して構成したら、別の Packaged CCE 展開タイプにのみ切り替えることができます。

輻輳処置モード

システムには、輻輳が原因で拒否または処理されたコールを処理する 5 つのオプションが提供されています。以下のオプションのいずれかを選択して、コール処理することができます。

- ダイヤル番号のデフォルト ラベルを使用するコール処理: 拒否されたコールは、着信コールが着信したダイヤル番号のデフォルト ラベルで処理されます。

- ルーティング クライアントのデフォルト ラベルを使用するコール処理する: 拒否されたコールは、着信コールが到着したルーティング クライアントのデフォルト ラベルで処理されます。

- システム デフォルト ラベルを使用するコール処理: 拒否されたコールは、輻輳制御設定で設定されたシステム デフォルト ラベルで処理されます。

- Dialog Fail または RouteEnd を使用したコールの終了: ダイアログ障害を使用して着信ダイアログを終了します。

- ルーティング クライアントへのリリース メッセージを使用したコール処理: リリース メッセージで着信ダイアログを終了します。

ルーティング クライアントまたはグローバル レベルのいずれかの輻輳設定で処理オプションを設定します。ルーティング クライアントで処理モードを選択すると、システムの輻輳設定よりも優先されます。

Note

ラベルを返してアナウンス付きのコールを処理する場合は、Unified CCE インスタンス外部のアナウンス システムを使用します。Unified CCE インスタンスに処理済みのコールを返してさらに処理しないでください。

アウトバウンド オプションのコール処理

アウトバウンド オプションは、輻輳制御を使用したコール処理の特殊なケースです。アウトバウンド オプションのメディア ルーティング周辺機器ゲートウェイ（MR PG）を統合する場合、PG のルーティング クライアントを構成して、常にダイアログの失敗が送信されるようにします。ダイヤラは、指定された時間が経過した後に拒否された予約コールを再試行します。

輻輳制御レベルおよびしきい値

輻輳制御アルゴリズムには、3 段階のレベルで動作します。各レベルには、開始値と軽減値があります。平均 CPS が開始値より 1 レベルを超えると、システムはより高い輻輳レベルに移行します。たとえば、システムがレベル 0 で、CPS がレベル 2 の開始容量を超える場合、システムはレベル 2 に直接移動します。平均 CPS が現在のレベルの削減値を下回ると、輻輳レベルが低下します。混雑レベルは一度に複数のレベルに上昇する可能性があります。ただし、減少する際は、輻輳レベルは一度に 1 レベルのみの低減となります。

輻輳レベル

輻輳レベル

しきい値 (キャパシティの％)

説明

レベル1 開始値

110

平均 CPS がこの値を超えると、輻輳レベルはレベル 1 に移行します。

レベル 1 軽減値

90 %

平均 CPS がこの値を下回ると、輻輳レベルはレベル 0（通常の動作レベル）に戻ります。

レベル 1 減少

10 %

レベル 1 の輻輳で拒否された着信コールの割合。

レベル 2 開始値

130%

平均 CPS がこの値を超えると、輻輳レベルはレベル 2 に移行します。

レベル 2 軽減値

100 %

平均 CPS がこの値を下回ると、輻輳レベルはレベル 1 に戻ります。

レベル 2 減少

30 %

レベル 2 の輻輳で拒否された着信コールの割合。

レベル 3 開始値

150%

平均 CPS がこの値を超えると、輻輳レベルはレベル 3 に移行します。

レベル 3 軽減値

100 %

平均 CPS がこの値を下回ると、輻輳レベルはレベル 2 に戻ります。

レベル 3 減少

100％ から 30％ への可変削減率

レベル 3 の輻輳で拒否された着信コールの割合。輻輳レベルがレベル 3 になると、着信率に応じて削減率は 30％ から 100％ に変化します。

Note

開始値、軽減値、および減少の設定を構成することはできません。これらの値は、システムの標準 CPS 容量の割合として定義されます。

輻輳制御 CPS の制限

以下の表に、サポートされる展開タイプの最大サポート コール / 秒（CPS）を示します。

導入タイプ

展開タイプ

毎秒の最大コール数

注

NAM (廃止)

300

11.5 で廃止済です。

Contact Director

300

リファレンス設計

NAM Rogger (廃止)

150

11.5 で廃止済です。

ICM Router/Logger

115

非リファレンス設計

UCCE 8000 エージェント ルータ / Logger

69

非リファレンス設計

UCCE: 12000 エージェント

105

リファレンス設計

Packaged CCE: 2000 エージェント

18

リファレンス設計

ICM Rogger

58

非リファレンス設計

UCCE: 4000 エージェント

35

リファレンス設計

Packaged CCE: ラボ モード

1

実稼働環境ではサポートされません。

HCS-CC 2000 エージェント

18

リファレンス設計

UCCE: Progger (ラボのみ)

4

実稼働環境ではサポートされません。

HCS-CC 4000 エージェント

35

リファレンス設計

HCS-CC 12000 エージェント

105

リファレンス設計

UCCE: 2000 エージェント

18

リファレンス設計

Packaged CCE: 4000 エージェント

35

リファレンス設計

Packaged CCE: 12000 エージェント

105

リファレンス設計

UCCE 24000 エージェント ルータ / Logger

105

リファレンス設計

HCS-CC 24000 エージェント

105

リファレンス設計

リファレンス設計準拠ソリューションの動作に関する考慮事項

- トランスポート層のセキュリティのためのソリューション全体にわたるサポート

- 導入したソリューションでの時刻の同期

- IPv6 向け Contact Center Enterprise ソリューション サポート

トランスポート層のセキュリティのためのソリューション全体にわたるサポート

Contact Center Enterprise ソリューションは、デフォルトで TLS 1.2 を使用します。ほとんどのコンポーネントでは、必要に応じて以前のバージョンの TLS を有効にすることができます。

導入したソリューションでの時刻の同期

運用および報告が正確に行われるようにするには、コンタクト センター ソリューションのすべてのコンポーネントで、時刻に対して同じ値を使用する必要があります。Simple Network Time Protocol（SNTP）サーバを使用すると、ソリューション全体で時刻を同期させることできます。次の表は、ソリューションにおけるさまざまなコンポーネント タイプのニーズの概要を示しています。

Important

ソリューション全体で同じ NTP ソースを使用してください。

コンポーネントのタイプ

注記

ドメイン コントローラ

ドメイン コントローラはすべて同じ NTP サーバを指す必要があります。

ESXi ホスト

すべての ESXi ホストが同じ NTP サーバをプライマリ ドメイン コントローラとして指している必要があります。

コンタクト センター ドメインの Windows コンポーネント

ドメイン内の Windows マシンは、NTP のプライマリ ドメイン コントローラを指し、自動的に同期します。NTPのための設定は必要ありません。

コンタクト センター ドメイン外の Windows コンポーネント

NTP サーバと直接同期させるには、Microsoft のマニュアルに従ってください。

非 Windows コンポーネント

Unified Intelligence Center、Cisco Finesse、Customer Collaboration Platform、Unified Communications などのコンポーネントは、ドメインコントローラとして同じ NTP サーバを指している必要があります。

Cisco サービス統合型ルータ

ログインとデバッグの正確な時間を提供するには、Cisco IOS 音声ゲートウェイに対してソリューションと同じ NTP ソースを使用します。

IPv6 向け Contact Center Enterprise ソリューション サポート

Unified Contact Center ソリューションは、エージェントおよびスーパーバイザの Finesse デスクトップと電話機の IPv6 接続をサポートできます。このサポートとは、展開内のほとんどのエンドポイントで、IPv6 アドレスを使用できるということです。

IPv6 が有効な展開では、IPv6 専用のエンドポイントを使用するか、IPv4 と IPv6 のエンドポイントを組み合わせて使用します。これらのエンドポイントと通信するサーバは、IPv4 接続に加えて IPv6 接続も受け入れることができます。サーバ間の通信では引き続き、IPv4 接続を使用します。

次の図は、IPv6 デスクトップと電話機のみの展開の論理図です。

IPv6 エージェントのみを配置する Unified CCE の展開

これらの IPv6 のみの展開では、エージェントとスーパーバイザが、サーバ上のデュアル スタック インターフェイスに接続されている Finesse およびブラウザ ベース ツールを使用します。また、イングレス ゲートウェイおよび Unified CM は、デュアル スタック インターフェイスを使用して、音声トラフィックも処理します。これらの展開では、IPv4 ベースの管理ワークステーションが、ブラウザからアクセスしないコンフィギュレーション ツールを実行する必要があります。

次の図は、IPv6 と IPv4 の両方のエンドポイントを使用する混合展開の論理図です。

IPv4 および IPv6 の両方を使用するエージェントを配置する Unified CCE の展開

Finesse デスクトップは、IPv4 または IPv6 接続をサポートできます。CTI OS デスクトップを使用するエージェントとスーパーバイザは、IPv4 接続を使用する必要があります。 ビジネス チャットおよび E メール エージェントは IPv4 接続を使用する必要があります。

Note

Avaya PG または親/子トポロジを使用する非リファレンス設計のみが CTI OS デスクトップを使用できます。Cisco Finesse は、他のすべての Contact Center Enterprise ソリューションで必要なデスクトップです。

IPv6 をサポートするエンドポイントの一覧については、使用するソリューションの 互換性マトリクスを参照してください。

Cisco Unified Communications Manager で IPv6 を有効にする方法については、「Deploying IPv6 in Unified Communications Networks with Cisco Unified Communications Manager」（http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html）を参照してください。

- 一般的な IPv6 設計上の考慮事項

一般的な IPv6 設計上の考慮事項

コンタクト センターのすべてのコンポーネント サーバで IPv6 を有効にすることはできません。たとえば、展開で IPv6 電話機を使用する場合は、IPv4 デスクトップのみを使用します。この展開では、デスクトップに接続するコンポーネント サーバで IPv6 を有効にします。

IPv4 エンドポイントが IPv6 エンドポイントと通信する場合、Unified Communication Manager はメディア ターミネーション ポイント（MTP）を呼び出して、不一致をネゴシエイトします。その結果、VXML ブラウザなどの IPv4 専用エンドポイントには、追加の MTP デバイスが必要です。CVP 機能を使用する際は、ほとんどの場合、IPv4 と IPv6 間のネゴシエーションに MTP が必要となります。

インストール時に IPv6 を設定する必要はありません。IPv6 はいつでも有効にすることができます。必要に応じて、IPv6 から IPv4 に戻すこともできます。

IPv6 アドレスを、デュアル IP スタックがあるホストに割り当てます。ソリューションのユーザ インターフェイスでは、IPv6 アドレスではなく、完全修飾ドメイン名（FQDN）を使用します。

IPv6 を使用する CVP の機能

ソリューションで IPv6 を有効にすると、CVP は機能をサポートするために以下の条件を必要とします。

- コール耐障害性: ゲートウェイへの着信トランクには IPv4 のみを使用します。

- サービス コールバックおよび REFER: トランクが着信および発信の両方のダイヤル トラフィックを伝送する場合、イングレス ゲートウェイのダイヤル ピアのセッション ターゲットは、着信トランクと同じプロトコルを使用します。

- デスクトップとツールのサポート

- その他のコンポーネントおよび機能のサポート

デスクトップとツールのサポート

次の表に、各接続タイプをサポートするデスクトップを示します。

デスクトップ

IPv6 接続

IPv4 接続

Finesse

はい

はい

CTI OS [1]

なし

はい

[1] Avaya PG または親/子トポロジを使用する非リファレンス設計のみが CTI OS デスクトップを使用することができます。Cisco Finesse は、他のすべての Contact Center Enterprise ソリューションで必要なデスクトップです。

スーパーバイザのチームは、Finesse デスクトップを IPv4 または IPv6 接続で使用し、CTI OS デスクトップを IPv4 接続で使用することによって、エージェントを組み合わせて使用することができます。

IPv6 を使用して、Citrix XenApp 経由で Finesse デスクトップに接続することはできません。

Unified CCE Administration を使用したスーパーバイザの再スキル化には、NAT64 の展開が必要です。

IPv4 または IPv6 接続を使用するデスクトップは、次のツールにアクセスできます。

- Unified CCE Administration Web ツール（NAT64 を使用）。

- Finesse コンフィギュレーション ツール

- Cisco Unified Intelligence Center（Cisco Unified IC）コンフィギュレーション ツールおよびレポート

- Unified Contact Center Management Portal（Unified CCMP）

次のツールにアクセスするには、IPv4 接続が必要です。

- ビジネス チャットおよび E メール

- Web Setup

- Script Editor

- Internet Script Editor

- Administration Client（Client AW とも呼ばれる）

- Diagnostic Portico

- Unified CVP 操作コンソール

- Configuration Manager および関連ツール

- ビデオ エンドポイント向け IPv6 設計に関する考慮事項

ビデオ エンドポイント向け IPv6 設計に関する考慮事項

ビデオ エンドポイントを使用する場合は、IPv6 を有効にする際に以下の点を考慮します。

- ゲートウェイに着信トランクを IPv4 モードのみで設定します。

- イングレス ゲートウェイで ANAT を無効にします。

- エージェント デバイスは、IPv4 またはデュアル IP モードを使用することができます。

その他のコンポーネントおよび機能のサポート

次の表に、IPv6 対応環境の各コンポーネントまたは機能がサポートする接続タイプを示します。

コンポーネントまたは機能

IPv6 対応環境でサポートされる接続

注記

IPv6

IPv4

Cisco Remote Silent Monitoring

はい

はい

ビジネス チャットおよび E メール

なし

はい

モバイル エージェント

なし

はい

モバイル エージェントの CTI ポートでは、[IPアドレッシングモード（IP Addressing Mode）] を [IPv4のみ（IPv4 Only）] にしか設定できません。

アウトバウンド オプション

なし

はい

アウトバウンド オプション ダイヤラは、IPv4 を使用して発信します。IPv4 と IPv6 の両方をサポートする音声ゲートウェイは、IPv6 エージェントの参照中に IPv6 へのコール シグナリングとメディアを再ネゴシエイトします。アウトバウンド オプションが存在しない IPv6 のみの音声ゲートウェイを使用することはできません。

IPv6 クライアントは、アウトバウンド オプションにインポートすることはできません。

Customer Collaboration Platform

なし

はい

Unified CM のサイレント モニタリング

はい

はい

Virtualized Voice Browser

なし

はい

IPv6 対応環境では Cisco VVB を使用できません。

非リファレンス設計

親/子または System PG

なし

なし

IPv6 対応環境では System PG を使用できません。

Unified IP IVR

なし

はい

Contact Center Enterprise ソリューションで IPv6 を有効にする方法の詳細については、展開するソリューションの インストールおよびアップグレード ガイドを参照してください。上記ドキュメントには、特定の製品の詳細が記載されています。

コンポーネント

ドキュメント

Unified CVP

Configuration Guide for Cisco Unified Customer Voice Portal

Cisco Finesse

Cisco Unified Intelligence Center

Cisco Unified Intelligence Center 管理コンソール ユーザ ガイド

Chapter 11. 非リファレンス設計

- 非リファレンス設計の設定制限および拡張性の制限

- 非準拠トポロジ

- 非リファレンス設計 コア コンポーネントおよび導入

非リファレンス設計の設定制限および拡張性の制限

以下の表は、Unified ICM / CCE 製品設定の制限および拡張性の制約を示しています。これらの構成上の制限は、Unified ICM / CCE 製品の設計制約の一部であり、Cisco によるテスト済みシステムのサイジング特性で利用されています。これらのシステム パラメータのほとんど（またはこれらのシステム パラメータの組み合わせ）は、システム容量に影響を与える要因を形成します。

これらの制限は、非リファレンス設計でのみ適用されます。これらの制限を使用してリファレンス設計ソリューションのサイジングを行ってはなりません。単一 Agent PG、単一 VRU PG、および単一 MR PG の標準的な 3 つの共存 PG レイアウトを使用しない場合、設計は非リファレンス設計となります。リファレンス設計に一覧されている高度な構成制限は、標準の PG レイアウトがない場合は適用されません。

コンタクト センターの設計の際は、これらの制限内で展開する設計にします。(詳細については、以下の表のコメント欄を参照してください。) 特定のパラメータを超える可能性のある特別な構成要件がある場合は、Cisco にご相談ください。

Important

この情報はクイック リファレンスとして機能します。システムの制約の詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-unified-contact-center-enterprise.html の Unified Contact Center Enterprise 仮想化、および https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html の Contact Center Enterprise 互換性マトリクス を確認してください。

Cisco Unified Contact Center Enterprise リリース 10.0 の互換性マトリクスがサポートされるすべての設定およびバージョンを指定しています。互換性マトリクスの情報は、その他の Cisco Unified Contact Center Enterprise ドキュメンテーションの互換性に関する情報よりも優先されます。互換性マトリクスで設定またはバージョンが指定されていない場合、その設定またはバージョンはサポートされていません。

表のチェック マークは、指定されたパラメータが、指定された Unified ICM / CCE 製品のエディションに適用可能であることを示しています。表の最後の中を参照してください。

設定制限および拡張性の制限

最大制限

制限値

適用対象

注

<=450 エージェント (Unified CCE のみ)

>450 - <=12,000 エージェント

Unified CCE

Unified ICM

管理者 (ユーザ)

100

1000

セットアップ、構成、およびスクリプト ユーザが含まれます。

ECC（拡張コンテキスト コール）およびユーザ変数サイズ（バイト数）

2000

2000

Unified CVP およびアウトバウンド オプションは、Unified ICM との統合にこの最大制限のサブセットに依存しています。

表示される最大値は、使用される ECC およびユーザ変数の値に依存せず、それぞれがレコード毎に約 50 バイトの追加ストレージを示します。最大には、固定変数と非固定変数の両方が含まれます。

周辺機器変数の数 (コール変数)

10

10

周辺機器変数の長さ (文字)

40

40

40 文字 (終端 NULL を除く)。

各 VRU PG 上の VRU PIM

該当なし

10

各 CVP は最大 3000 ポートと 15 CPS をサポートし、各 VRU PG は最大 12000 ポートをサポートできます。

VRU PG の総ポート数が、12000 未満で、すべての VRU PIM 全体の総 CPS 数が、60 CPS 未満である限り、VRU PG あたり最大 10 VRU PIM をサポートできます。

VRU PIM ごとの最大 CPS

該当なし

15

VRU PG あたりの最大 CPS は 60 です。

各汎用 PG 上の VRU PIM

2

4

Unified CM (CUCM) PIMを使用する汎用 PGは、合計 1,000 ポートのみをサポートします。

各システム PG 上の VRU PIM

該当なし

5

—

IP-IVR PIM のみ。

各 PG 上の TDM PIM

該当なし

5

—

PG 上に複数の PIM を配置すると、パフォーマンスに影響します。各 PG の単一の PIM と比較して、複数の PIM はエージェント、VRU ポート、およびサポートされるコール量の総数を減少させます。CTI OS が共存する各 TDM PG には、最大 1 つの PIM が存在します。

各 MR PIM 上の MR PG 数

1

2

UCM PIM

1

12

各 CUCM クラスタの PG の最大数

4

4

各 ICM インスタンスのデュプレックス PG

1

150

450 人あるいはそれ以下の Cisco アウトバウンド オプションのエージェント展開の場合、もう 1 つの MR PG が存在します。上記の UCM 制限を参照してください。

各システム上の PIM (合計)

4

150

単一のエージェント PIM、2 つの VRU PIM、および 1 つの MR PIM (450 人以上のエージェントにのみ適用)。

各システム上の設定済みエージェント (合計)

該当なし

65,000

—

各システム上の設定済みエージェント (合計)

3000

76,000

—

各周辺機器上の設定済みエージェント

3000

12,000

各周辺機器ゲートウェイ上のスキル グループ

1500

4000

プレシジョン キューの設定により、エージェント PG 毎にスキル グループが作成され、各 PG でサポートされるスキル グループの数にカウントされます。

システム毎のスキル グループ

1500

27,000

プレシジョン キューの設定により、エージェント PG 毎にスキル グループが作成され、各システムでサポートされるスキル グループの数にカウントされます。

各エージェント PIM 上の CTI OS

1

1

毎時プロビジョニング操作

30

120

Configuration Manager の場合、CCM Pまたは AAS: ソリューション内のすべての ADS にわたる保存操作の毎時最大数。プロビジョニング操作毎に 200 の変更。

エージェント状態トレースで追跡される最大エージェント数

100

エージェント状態トレースの詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の Cisco Unified ICM/Contact Center Enterprise コンフィギュレーション ガイド を参照してください。

各ダイヤラの SIP ダイヤラ ポート

該当なし

1500

—

この制限は、モデルが配布されることを想定しており、数値は展開によって異なります。

各 PG ペアの SIP ダイヤラ (サイド A + サイド B)

該当なし

1

—

PG 毎に 1 つのダイヤラ タイプのみをインストールすることができます。

各サーバ上の SIP ダイヤラ ポート (合計)

該当なし

1500

—

—

複数インスタンス展開の場合：

各システム上のダイヤラ ポート (合計)

該当なし

4000

—

各システム上の ダイヤラ (合計)

該当なし

32

—

各システムのキャンペーン

該当なし

600

—

サイジングが必要です。小規模な展開では、600 のキャンペーン全体はサポートできません。

各システムのキャンペーン スキル グループ

該当なし

100

—

すべてのキャンペーンのスキル グループ合計

キャンペーン毎のキャンペーン スキル グループ数

該当なし

20

—

特定のキャンペーンのスキル グループの制限（システム毎に最大 100 のキャンペーン スキル グループを超過しない限り）。

各システムのダイヤル番号

1500

240,000

各システムの設定済みラベル

500

最大 4,000 人のエージェントで 100,000

最大 12,000 人のエージェントで 160,000

間隔毎のコール タイプ スキル グループ

1000

30,000

合計コール タイプ スキル グループの記録。

設定済みコール タイプ数

500

10,000

設定済コール タイプ合計。

アクティブ コール タイプ

250

8000

各システム上のプレシジョン ルーティング (PR) 属性

該当なし

10,000

—

各エージェントの PR 属性

該当なし

50

—

各システム上の PR プレシジョン キュー (PQ)

該当なし

4000

—

各システム上の PR PQ 逓減

該当なし

10,000

—

各 PQ PR 逓減の PR 条件

N/A

10

—

各 PR 逓減の PR 条件

N/A

10

—

各 PQ の PR 固有の属性

N/A

10

—

スーパーバイザ チーム固有のスキル グループおよび PQ

50

50

Note

システム上の構成済みエージェントの最大数に近い展開の場合、特に競合するキャパシティ制限も最大しきい値に近づくと、パフォーマンスの低下およびコール ルーティング障害が発生する可能性があります。キャパシティに関するシステム計画には、パートナーまたは専門サービスを提供する専門家のサポートが必要となりです。多数の設定済みのエージェントにパフォーマンス面で最も影響するパラメータには、システム周辺機器の合計数、ルート、アクティブ エージェント数、および全体的なコール負荷が含まれます。低減のリスクが最も高いポイントは、PG が中央コントローラにレポート データを送信する繁忙時および 30 分の更新期間です。システム管理者は稼働していない設定済みエージェントを削除し、非アクティブな周辺機器を廃止し、現在のメンテナンス リリース レベルでシステムを維持することにより、上記の問題の影響を軽減することができます。

Unified CCE ソリューション

- その他のサイジング要因

Related Concepts

リファレンス設計の構成上の制限

その他のサイジング要因

Unified CCE の構成および展開オプションの多くの変数は、サーバの要件とキャパシティに影響を与える可能性があります。このセクションでは、主要なサイジングに関する変数と、さまざまな Unified CCE コンポーネントがキャパシティに与える影響について説明します。

最繁時呼数（BHCA）

繁忙時に試行されるコールの数は重要な指標です。BHCA が増加すると、すべての Unified CCE コンポーネント、特にUnified CM、Unified IP IVR 、および Unified CM PG の負荷が増加します。エージェントに対する推定許容数は、1 時間にエージェントあたり最大 30 コールです。展開でエージェント毎に毎時 30 以上のコールが必要な場合、エージェント PG でサポートされるエージェントの最大数は減少します。こういった場合はケースバイケースで処理します。

エージェント

エージェント数は、Unified CM クラスタを含むほとんどの Unified CCE サーバ コンポーネントのパフォーマンスに影響を与えるもう 1 つの重要な指標です。

エージェント毎の平均スキル グループまたはプレシジョン キュー数

エージェント毎のスキル グループまたはプレシジョン キューの数（システム毎の合計スキル数とは関係ありません）は、以下に多大な影響を与えます。

- CTI OS サーバ

- Finesse サーバ

- エージェント PG

- Call Router

- Logger

可能ならば、エージェント毎のスキル グループとプレシジョン キューの数を 5 以下に制限します。システムのパフォーマンスに影響を与えないように、未使用のスキル グループまたはプレシジョン キューは定期的に削除します。統計更新頻度の値を増やすことで、CTI OS サーバへの影響を管理することもできます。

Finesse サーバでは、未使用スキル グループの統計情報は表示されません。そのため、エージェントに割り当てられるスキル グループの数は、設定済みのスキル グループの総数よりも Finesse サーバのパフォーマンスに影響します。

キュー (スキル グループ) 統計は、Finesse デスクトップで 10 秒間隔で更新されます。Finesse デスクトップは、一定数のキュー統計情報フィールドをサポートしています。このフィールドは変更できません。

最初の表は、Unified CCE システムのキャパシティに影響を与えるエージェント毎のスキル グループまたはプレシジョン キュー（PQ）の数の例を示しています。この表は、各 CTI OS インスタンスのキャパシティを示しています。Finesse サーバは、CTI OSと同じ数のエージェントとスキルグループをサポートします。

Unified CCE は、スーパーバイザ チームのエージェント全体で最大 50 の一意のスキル グループをサポートします。これにはスーパーバイザ自身のスキル グループも含まれます。この数値を超えても、スーパーバイザによってモニタされるすべてのスキル グループは、引き続きスーパーバイザ デスクトップに表示されます。ただし、この数値を超えるとパフォーマンス上の問題が引き起こされる可能性があり、数値の超過はサポートされません。

Note

設定されたプレシジョン キューは、各 Agent PG に対してスキル グループを作成し、PG あたりのサポートされるスキル グループ数までカウントしていきます。スキル グループは、プレシジョン キューと同じメディア ルーティング ドメインに作成されます。

この表の数値は、特定のハードウェアおよびソフトウェアの要件に従います。

各エージェントのスキル グループまたはプレシジョン キューのサイジング効果 (12,000 人のエージェント)

エージェント毎の平均設定済み PQ または SG

システム

汎用 PG の制限

各システムの最高同時エージェント

各 PG の最高同時エージェント

PG 毎の最大設定済み PQ または SG

PG 毎の最大設定済み VRU ポート

PG 毎の最大設定済み VRU PIM

5

12000

2000

4000

[1000]

4

10

11038

1832

4000

[1000]

4

15

10078

1663

4000

[1000]

4

20

9116

1495

4000

[1000]

4

25

8156

1326

4000

[1000]

4

30

7194

1158

4000

[1000]

4

35

6234

989

4000

[1000]

4

40

5272

820

4000

[1000]

4

45

4312

652

4000

[1000]

4

50

3350

484

4000

[1000]

4

Note

CTI OS モニタ モード アプリケーションは、エージェント毎に 20 以下のスキル グループのみをサポートします。

スーパーバイザおよびチーム

スーパーバイザとチーム メンバーの数も、CTI OS サーバのパフォーマンスに影響する要因になる可能性があります。エージェントとスーパーバイザを複数のチームに分散して、各スーパーバイザが少数のエージェントのみを監視するようにします。

Note

スーパーバイザは自分のチーム内のエージェントのみを監視することができ、すべてのエージェントは同じ周辺機器で構成する必要があります。

Note

チーム毎に最大 50 人のエージェントを追加することができます。チーム毎に最大 50 人のスーパバイザを追加することができます。

Unified CCE システムは、以下の前提条件で、スーパーバイザ毎に最大 50 人のエージェントをサポートすることができます。特定の環境でスーパーバイザ毎に 50 人以上のエージェントの配置が必要な場合は、以下の数式を使用して、CTI OS サーバおよびスーパーバイザ デスクトップに影響がないことを確認してください。この計算で最も重要な要素は、毎秒更新数です。

X = (Y * (N + 1) / R) + ((Z * N * A) / 3600)、小数は整数に切り上げます

それぞれの説明は以下の通りです。

X = CTI OS スーパバイザ デスクトップが受信する毎秒更新数。

Y = エージェント毎のスキル グループまたはプレシジョン キューの数の加重平均。たとえば、合計 10 人のエージェントが以下のスキル グループ分布を持つ場合：9 人が あるスキル グループで、1 人のエージェントが 12のスキル グループである場合。エージェント毎のスキル数 ([Y]) は、Y = 90% * 1 + 10% * 12 = 2.1。(CTI OS サーバで設定される統計数は 17 です。)

Z = エージェント毎毎時コール数。

A = エージェントの状態の数。(コール フローに依存、平均 = 10。)

N = スーパーバイザ毎のエージェント数

R = CTI OS サーバで設定されたスキル グループまたはプレシジョン キューの更新レート。(デフォルトは 10 秒です。)

(Y * (N + 1) / R) = スキル グループに基づく、毎秒更新数。

(Z * N * A) / 3600 = コールに基づく、毎秒更新数。

CTI OS スーパーバイザ デスクトップは、毎秒 31 未満の更新である限り影響を受けません。このしきい値は、以下の通り、スーパーバイザ毎に 50 人のエージェントの更新レートを計算するために上記の数式を使用して導出されます（N = 50）。

X = (5 * (50 + 1) / 10) + ((30 * 50 * 10) / 3600) = 25.5 + 5 = 毎秒 31 更新

スーパーバイザあたりのエージェントの最大数は、特定の構成で 200 人以上であってはならず、上記の数式で毎秒更新数は最大 31 までにします。

CTI OS モニタ モード アプリケーション

CTI OS モニタ モード アプリケーションは、CTI OS サーバのパフォーマンスに影響を与える可能性があります。CTI OS サーバ ペア毎にこのようなアプリケーションが 2 つのみサポートされます。指定されたフィルタによっては、CPU 使用率への影響によりエージェント PG のパフォーマンスが低下する場合があります。

Unified CM のサイレント モニタリング

サイレント モニタリングされるコールごとに、PG と Unified CM の処理が増します。サイレント モニタリングされる各コールは、2 つのモニタされないエージェント コールに匹敵します。監視されるコールの割合が PG スケーラビリティの許容量の範囲内であることを確認してください。

CTI OS スキル グループ統計情報の更新間隔

スキル グループ統計情報の更新レートは、CTI OS サーバのパフォーマンスにも影響を与える可能性があります。Cisco では更新レートをデフォルト値の 10 秒未満に下げることを推奨しません。

コール タイプ

コール タイプは、ほとんどの Unified CCE サーバ コンポーネントのパフォーマンスに影響する重要なメトリックでもあります。転送および会議の数が増加すると、システムの負荷が増加し、総容量が減少します。

キューイング

Unified IP IVR および Unified Customer Voice Portal（CVP）は、エージェントがコールに応答するまでキューにコールを入れて、アナウンスを再生します。サイジングのために、以下のいずれかを把握しておくことが重要となります。

- VRU はまず、すべてのコールを処理して（コール処理）、短いキューイング期間後に発信者をエージェントに転送します。

- エージェントはすぐにコールを処理します。すべてのエージェントがビジー状態の場合、VRU は未応答のコールのみをキューに入れます。

この問題に対する答えは、非常に異なる VRU サイジング要件を決定し、コール ルータ / Logger および Voice Response Unit（VRU）PG のパフォーマンスに影響します。

変換ルート プール

変換ルート プールのサイジングは、予想される着信率に依存します。以下の数式で変換ルート プールをサイジングします。

変換ルート プール = 20 * (毎秒コール数)

この数式は、Unified CCE 固有です。一般的な Unified ICM 展開の場合は、Cisco アカウント チームまたはパートナーにご相談ください。

UCCEスクリプトの複雑性

UCCE スクリプトの複雑さおよび / または数が増加すると、コール ルータと VRU PG のプロセッサおよびメモリのオーバーヘッドが大幅に増加します。RunExternalScript の再生間での遅延時間も影響を及ぼします。

レポート

リアルタイム レポートは、データベース アクセスのため、Logger および Rogger の処理に大きな影響を与える可能性があります。Logger および Rogger からのレポート オーバーヘッドをオフロードするために、管理サーバおよびデータ サーバには別の VM が必要です。

VRU スクリプトの複雑性

データベース クエリなどの機能を使用すると VRU スクリプトの複雑さが増加するので、IP IVR サーバとルータに対する負荷も増加します。複雑なスクリプト、複雑なデータベース クエリ、またはトランザクション ベースの使用に使用する場合、Unified IP IVR のパフォーマンスを特徴付ける適切なルールやベンチマークはありません。ラボまたはパイロット展開で複雑な VRU 構成をテストして、さまざまな BHCA の下でのデータベース クエリの応答時間および VRU サーバ、PG、およびルータのプロセッサとメモリに与える影響を判断します。

Unified IP IVR セルフサービス アプリケーション

Unified IP IVR がセルフサービス アプリケーションにも使用される展開では、セルフサービス アプリケーションは Unified CCE の負荷に追加されます。上記のサイジング表に記載される通り、セルフサービス アプリケーションをサイジング要件に組み込みます。

サードパーティのデータベースと Cisco Resource Manager の接続

外部デバイスおよび / またはソフトウェアに対する Unified CCE ソリューション コンポーネントの接続を詳しく調べ、ソリューションに対する全体的な影響を確認してください。Cisco Unified CCE ソリューションは柔軟でカスタマイズ可能ですが、複雑になる場合もあります。一般的に、コンタクト センターは、収益を創出する非常に重要なカスタマー応対業務です。そのため、Unified CCE ソリューションの設計に役立つように、適切なエクスペリエンスと認定を備えた Cisco パートナー（または Cisco  アドバンスド サービス）を関与させてください。

拡張コール コンテキスト（ECC）

ECC の使用は、PG、ルータ、Logger、およびネットワーク帯域幅に影響を及ぼします。ECC を構成して使用する方法は多数あります。キャパシティへの影響は、ECC 構成に基づいて、ケースバイケースで処理します。

非準拠トポロジ

- 親/子アーキテクチャ

親/子アーキテクチャ

Unified CCE Gateway PGにより、Unified CCE は、Unified ICM システムに接続された従来の ACD として表示されます。Unified CCE ゲートウェイ PG は、Unified CCE システム PG の CTI インターフェイスと通信する PG を Unified ICM システムに提供します。

親/子モデルでは、子の Unified CCE が単独で機能するように設定します。Unified CCE ではコールをエージェントにルーティングするために親への接続を必要としません。この独立性により、子供と親の間の接続障害が発生しても、ミッション クリティカルなコンタクト センターのローカルな耐障害性が提供されます。

子システムは、Unified ICM 設定に挿入するために、設定オブジェクトを親 Unified ICM に自動的に送信することができます。このプロセスにより、オブジェクトを（ローカル ACD 上と Unified ICM 上とで） 2 回設定する必要がなくなります。また、顧客が自動構成更新を必要としない状況では、この機能をオフにすることもできます。たとえば、別の顧客のエージェントもサポートするアウトソーサーの子システムからの自動更新は望ましくありません。

Note

スマートライセンシングの場合は、製品インスタンスを Cisco Smart Software Manager に登録する際、すべての親子ノードに同じバーチャル アカウントを使用します。これにより、顧客はライセンス使用状況の集約されたビューを取得し、ライセンスのプールメカニズムを利用できます。

Unified CCE ゲートウェイ PGは、Unified CCE システム PGを使用する Unified CCE の子に接続できます。子に複数の Unified CCE システム PG および周辺機器がある場合、各子 PG の親システムに個別の Unified CCE ゲートウェイ PGをインストールして設定します。別の VM に展開すると、Unified CCE ゲートウェイ PGは複数の子Unified CCE 周辺機器を管理することができます。

子 Unified CCE では、コール処理とキューイングのために Unified IP IVR または Unified CVP を展開することができます。Unified CVP を展開する場合は、VRU PG をもう 1 つ追加します。このモデルは、Unified IP IVR の展開時に使用される単一の周辺機器モデルには従いません。このため、子でキューに入れられたコールに関する情報（およびコールのキュー時間）は、親では利用できません。親によるキュー時間を含む計算は不正確であり、親のルーティングに悪影響を及ぼす可能性があります。

- 親/子コンポーネント

- Unified CCE システム周辺機器

- 親/子の制限事項

- 親/子の Active Directory への導入

- 親/子の展開向け Unified CCMP

- 複数サイトへの親/子展開

- 地理的冗長性を持つ子 サイト データ センター (Unified IP IVR使用)

- Unified ICM を使用した Unified CCE の高可用性

- 従来の ACD 統合

- 従来の VRU 統合

親/子コンポーネント

次のセクションでは、Unified ICM（親）および Unified CCE（子）の展開で使用されるコンポーネントについて説明します。

- Unified ICME (親) メイン サイト

- Unified CCE コール センター (子) サイト

- Unified CCE ゲートウェイ PG メイン サイト

Unified ICME (親) メイン サイト

Unified ICM メイン サイト には Unified ICM 集中型コントローラが含まれています。メイン サイト は集中型コントローラの冗長ペアです。集中型コントローラには、コール ルータおよび Logger サーバがあります。サーバを個別のコール ルータおよび Logger として展開し、サーバを地理的に分散した 2 つの サイトのリストに追加します に展開して、耐障害性を高めることができます。

Unified ICM 集中型コントローラは、メイン サイトで周辺機器ゲートウェイ (PG) を制御します。VRU PG の冗長ペアは、アーキテクチャ全体で Unified CVP を制御します。このレイヤにさらに PG を挿入して、TDM または従来の ACD および VRU を制御することができます。このアプローチでは、Unified CCE への移行のサポート、TDM または従来の ACD を使用する場所のアウトソースが可能です。

このモデルでは、親 Unified ICM は直接制御されるエージェントをサポートしていません。そのため、親/子展開では、Unified ICM は、この Unified ICM 親にインストールされた Unified Communications Manager PG を使用する従来の nified CCE をサポートしません。この Unified ICM 親システムの外部ですべてのエージェントを制御します。

Unified CVP VRU PG ペアが Unified CVP サーバを制御します。CVP サーバは、Unified ICM からの VRU PG コマンドを VXML に変換し、VXML を子サイトの音声ゲートウェイ（VG）に転送します。メイン サイト からのコールは、親ロケーションの Unified CVP の制御下でリモート コール センターに着信することができます。その後、親は全サイトにわたるコールのネットワーク キュー全体を制御できます。親は、エージェントが応対可能になるまで、サイトの VG のキューにコールを保持します。

Unified CCE コール センター (子) サイト

Unified CCE コール センターには、ローカル IP-PBX 機能と IP フォンのコール制御のための Unified Communications Manager クラスタが含まれています。ローカル Unified IP IVR は、Unified CCE サイトのローカル コール キューイングも提供します。Unified CCE ゲートウェイ PG の冗長ペアは、WAN を介してこのサイトを親 Unified ICM の集中型コントローラに接続します。Unified CCE ゲートウェイ PG は、個別の VM に展開するか、CCE システム PG と共存可能です。ただし、以下の点に注意します。

- Unified CCE ゲートウェイ PG と Unified CCE システム PG のインスタンス番号が同じ場合、それらの PG には異なる PG 番号を使用します。

- Unified CCE ゲートウェイ PG と Unified CCE システム PG のインスタンス番号が異なる場合、それらの PG に同じ PG 番号を使用することができます。

- 他の PG（VRU PG や MR PG など）をこの VM に追加しないでください。

- 共存する Unified CCE ゲートウェイ PG と Unified CCE システム PG のスケーラビリティの制限に従います。

Unified CCE ゲートウェイ PGは、子 Unified CCE から親にリアルタイム イベント データとエージェント状態を提供します。また、Unified CCE ゲートウェイ PGは、すべてではないものの一部の設定データをキャプチャして、それを親の Unified ICM 設定データベースに送信します。

子サイトの Unified IP IVR は、ローカルの Unified CVP インスタンスに置き換えることができます。Unified CVP は、Agent Controller のシステム PGの一部として統合されません。Unified CVP を使用した Unified CCE のインストールでは、Unified CVP 専用の個別の VRU PG が定義されます。Unified CVP はシステム PG の一部ではないため、Unified CCE ゲートウェイ PG はキューまたは処理中のコールを親 Unified ICM に報告しません。親ルーティングでキューイングまたは処置情報が必要な場合、Unified CVP を使用した展開ではニーズが満たされない場合があります。

ローカルの子 Unified CCE システムは、ACD 機能を提供します。子 Unified CCE システムは、別個の Unified CCE エージェント PG サーバを持つ Rogger としてサイジングできます。Rogger には コール ルータ と　Rogger が含まれます。冗長 エージェント PG サーバのセットには、Unified Communications Manager と Unified IP IVRのシステム PG、CTIサーバと CTI OS サーバ、および Unified CVP のオプションの VRU PG が含まれます。

いずれの構成でも、システムの構成およびスクリプト ツールをホストするための個別の管理サーバおよびデータ サーバ、オプションの履歴データベース サーバ、および Web ベースの Unified Intelligence Center レポート ツールが必要です。

Unified CCE ゲートウェイ PG メイン サイト

下の図に示すように、Unified CCE ゲートウェイ PG を Unified ICM メイン サイト に展開することができます。この展開モデルにより、Unified CCE ゲートウェイ PGを一元的に管理および制御することができます。さまざまな企業が子サイトと親サイトを所有および管理している場合は、条件により、Unified ICM メイン サイトに Unified CCE ゲートウェイ PG を展開せざるを得ない場合があります。たとえば、アウトソーサー / サービス ビューローが子サイトを管理し、親サイトの Unified CCE ゲートウェイ PG に接続します。

Unified CCE ゲートウェイ PGを 使用した親/子展開 メイン サイト

Unified CCE ゲートウェイ PG を メイン サイトに移動する場合、何点かのデメリットがあります。1 点目は、ネットワーク障害後のレポート データの復元です。親サイトと子の Unified CCE システム PG 間のネットワーク接続が切断されると、親サイトでのすべてのレポートはその期間中失われます。

Note

Unified CCE ゲートウェイ PG は Unified CCE システム PG にローカルに展開することができます。親サイトと子サイト間の接続が切断された場合、ネットワーク接続が復帰すると、親サイトの履歴データが更新されます。

Unified CCE Gateway PG の集中化のもう1つのデメリットは、PG 間の接続のネットワーク帯域幅要件が高くなることです。

- Unified CCE ゲートウェイ PG から集中型コントローラへの帯域幅

- Unified CCE ゲートウェイ PG からシステム PG への帯域幅

Unified CCE ゲートウェイ PG から集中型コントローラへの帯域幅

他の TDM PG を介した PG から CC への接続には、特別な考慮事項は必要ありません。

エージェント レポートを使用しない場合は、設定は無効のままにして、リンクで不要なデータを送信しないようにします。

Unified CCE ゲートウェイ PG からシステム PG への帯域幅

以下の図は、親 PG / PIMと子システム PG 間の接続を示しています。

ゲートウェイ PG とシステム PG 間の接続

Note

通常、ゲートウェイ PGは、監視するシステム PGと同じ VM に展開します。アウトソース モデルの場合、ゲートウェイ PG を システム PG からリモートで展開することができます。

以下の要因が、初期化されたリンクを介して送信されるデータの量に影響を与えます。

- メッセージのサイズは、コンテンツ（内線のサイズ、エージェントIdS、コール データなど）によって異なる場合があります。たとえば、データのないルート要求のメッセージサイズは小規模です。すべてのコール変数と ECC 変数に大きな値が設定されている場合、データはメッセージのサイズに大きく影響します。

- コール シナリオでは、回線を介して送信される通話あたりのメッセージ数に大きなばらつきが生じる場合があります。単純なコール シナリオでは、回線を介して 21 のメッセージを送信することができます。キューイング、保留取得、会議、または転送を含むより複雑なコール シナリオでは、各コールの回線を介してさらに多くのメッセージが送信されます。

- エージェントが属するスキル グループが多いほど、より多くのメッセージが回線を介して送信されることになります。単純なコール シナリオでは、追加のスキル グループ毎に、各コールに 2 つのメッセージが追加されます。これらのメッセージは、フィールドのサイズに応じ、それぞれ約 110 バイトです。

基本的なコール フローの帯域幅計算

単一のスキル グループを使用した基本的なコール フロー（他のステップを使用しない単純な ACD コール）は、通常 21 のメッセージを生成します。2,700 バイト / 秒の最小必要帯域幅を計画します。

基本的なコール フローには、コール変数と ECC データを送信できる場所が 4 つあります。コール データと ECC 変数を使用する場合、コール フロー中に 4 回送信されます。多くの変数を使用すると、コールあたりの推定帯域幅の 2,700 バイト / 秒が 2 倍以上になりやすくなります。

Note

子 PG で使用されるコール変数は、使用または MAPVAR パラメータ設定に関わらず、親 PG に送信されます。たとえば、子 PG はコール変数 1 〜 8 を使用しますが、親 PG はこれらの変数を使用しないと仮定します。MAPVAR = EEEEEEEEEE、つまり何もインポートせずにすべてをエクスポートする場合、変数は PG に送信され、そこでフィルタリングが行われます。ここでも帯域幅は必要です。ただし、マップ設定が MAPVAR = IIIIIIIIII の場合、何もエクスポートせずにすべてインポートすると、帯域幅は節約されます。コール変数データは、ROUTE_SELECT 応答では子 PG に送信されません。

基本のコール フロー例

毎分 300 のシンプルなコール（毎秒 5 コール）のコール レートを想定します。エージェントはすべて、コール変数または ECC データを渡さない単一のスキル グループに属します。この場合に必要な帯域幅は以下のとおりです。

5 * 2700 bps = 13,500 bps = 108 kbps の帯域幅が必要

Note

より複雑なコール フローまたはコール データを含むコール フローは、この帯域幅要件を軽く上回る可能性があります。

Unified CCE システム周辺機器

Unified CCE システムの周辺機器は、VRU 周辺機器と Unified Communications Manager 周辺機器の機能を組み合わせた単一の論理Unified ICM 周辺機器として機能します。Unified CCE は、Unified IP IVR と Unified Communications Manager 周辺機器を単一のペリフェラルとして扱い、処理とキューイングのためにコールを Unified IP IVR に変換ルートする必要がなくなります。複数の Unified IP IVRが設定されている場合、Unified CCE システム周辺機器は、使用可能な容量がある Unified IP IVR間のコールを自動的にロード バランシングします。

単一の周辺機器として、Termination Call Detail（TCD）レコードおよびその他のレポート データには、コールが周辺機器で使用される全期間のコールの情報が含まれます。Unified CCE システム PG は、コールごとに最大 3 つの TCD（元のルート用、VRU 用、およびエージェント処理時間用）を取得する代わりに、単一のレコードのみを生成します。

Unified CCE システム PGは、Unified CVP をサポートしていません。Unified CCE システム PG のすべてのキューイングと処理は、Unified IP IVRを使用します。Unified CCE システム周辺機器を使用して、独自の PG で別の Unified CVP を使用することができます。

親/子の制限事項

精密なルーティング

精密ルーティングは、親/子展開ではサポートされていません。周辺機器ルーティングは、Unified CCE システム周辺機器をサポートしていません。

マルチチャネル ルーティング

親/子構成では、親 Unified ICM を介したマルチチャネ ルルーティングおよび統合はありません。メディア ルーティング PG は、子 Unified CCE に接続する必要があります。子毎に個別の Cisco Interaction Manager またはパーティションが必要となります。

Enterprise Unified CCE 周辺機器の展開

Unified CCE が Unified ICM の子である Enterprise Unified CCE（別個の周辺機器として展開された CallManagerと VRU）展開は使用できません。そのソリューションには、Unified CCE システム周辺機器展開を使用します。

ウィスパー アナウンスメント

ウィスパー アナウンスメントは特定の親/子構成のみをサポートします。この設定は、子システム PG 上の Unified IP IVR でコールをキューに入れ、ウィスパー アナウンスメントを発信します。エージェント グリーティングも使用する場合、構成では、エージェント グリーティングを提供するために、専用 VRU PG の子の専用 CVP も必要です。シスコは、親/子構成でのウィスパー アナウンスメントの使用を承認する必要があります。Cisco は、そのような設計を分析して承認する必要があります。

親/子での Unified IP IVR によるウィスパーアナウンスメントは、Child System PGのエージェントのサイジングには影響しませんが、 Unified IP IVRに大きな影響を与えます。

エージェントのグリーティング

エージェント グリーティングは特定の親/子構成のみをサポートします。その設定は、子システム PG 上の Unified IP IVR でコールをキューに入れます。この構成では、エージェントの挨拶を提供するために、専用の VRU PG の子に専用の CVP が必要です。Cisco は、親/子構成でのエージェント グリーティングの使用を承認する必要があります。Cisco は、そのような設計を分析して承認する必要があります。

構成は以下の条件を満たす必要があります。

- 子で Unified IP IVR を使用して、コール処理、キューイング、およびウィスパー アナウンスメントを行います。

- 子で CVP を使用するのは、エージェント グリーティングのみです。コール キューイングに CVP を使用してはなりません。CVP には別の VRU PG を使用します。

ネットワーク コンサルタティブ転送

親/子の展開では、親のルーティング クライアントを介してネットワーク コンサルタティブ転送（NCT）によって子システムで終端するコールは転送できません。NCT は TDM ACD で機能し、親/子展開アーキテクチャは似ていますが、親/子展開は同じようには機能しません。

TDM PG の場合、CTI サーバは親システムの一部である ACD PG に接続されます。この配置は、Gateway PG に接続された CTI サーバと同じです。親/子展開では、CTI は子 PG に接続します。子 PG に CTI を接続しても、ネットワークの打診転送を許可するために必要なネットワークコール ID およびその他の情報は提供されません。

Note

子から親システムへのポスト ルーティングが開始されると、親システム上の任意のクライアント（Unified CVP 等）を使用してネットワーク ブラインド転送が可能になります。

親/子の Active Directory への導入

同じ AD ドメインまたはフォレスト、および異なる AD 環境に親/子システムを展開することができます。この展開の通常のシナリオは、アウトソースされたコンタクト センター サイトに子 Unified CCE システムが収容される場合に発生します。この場合、親 AD ドメインには、親ノードであるゲートウェイ PG が含まれます。(管理上の制限のため、ワークグループ メンバーシップは使用しないでください。) この展開は、ルータ、Logger、およびディストリビューターを含む集中型サイト ドメインのメンバーである PG を備えたリモート ブランチ オフィスをサポートします。

下の図に示すトポロジは、この展開の 2 つの AD ドメインの AD 境界を表しています。この図には、アプリケーション サーバが参加するドメインも示されています。親 AD ドメイン境界は メイン サイトを超えて拡張されます。親AD境界には、Unified ICM 集中型コントローラと、ACD PG（従来サイト）および子 Unified CCE サイトのゲートウェイ PG を備えた付属サーバが含まれます。子の Unified CCE サイトとその AD 境界には、Unified CCE サーバがメンバーとして含まれます。AD 境界は、アウトソーシング企業の AD 環境の一部にすることも、AD 境界を Unified CCE 専用の AD ドメインにすることもできます。

Active Directory とファイアウォールの展開

親/子の展開向け Unified CCMP

親/子展開では、単一の Unified CCMP インスタンスが各子 Unified CCE 管理サーバおよびデータ サーバに接続します。これらのサーバは、物理的に独立したプライマリ管理サーバとデータ サーバとして構成します。各子インスタンスは、Unified CCMP 内の テナント として表示されます。Unified CCMP を介して追加されたリソースは、テナントにリンクされます。標準プロセスは、追加されたリソースを Unified CCE の子からその親に複製します。

複数サイトへの親/子展開

親/子展開は、各サイト（子）でローカルの Unified Communications Managerと Unified CCE を使用したローカルの分散型呼処理を提供します。集中型の親 Unified ICM Enterpriseは、企業全体のルーティング、レポート、およびコール制御のために子サイトを制御します。この展開は WAN の停止に関してより耐性があり、各サイトは停止中も継続して動作します。以下の図は導入例を示しています。

分散型呼処理および親/子を使用するマルチサイト配置

この設計では、Unified CVP と独自の管理およびデータ サーバと共に展開される親 Unified ICM Enterprise システムが存在します。各分散型子サイトは、1 つ以上の VM 上のセントラル コントローラで構成される完全な Unified CCE 展開です。Unified CCE のローカル管理およびデータ サーバは、その特定のサイトの構成、スクリプト作成、およびレポート タスクを実行します。Unified CCE ゲートウェイ PGは、Unified CCE を親 Unified ICM に接続し、親 Unified ICMに展開された周辺機器ゲートウェイの一部となります。

Unified CCE ゲートウェイ PGのオプションの展開では、以下のガイドラインに基づき、Unified CCE システム PGと同じ場所に配置します。

- Unified CCE ゲートウェイ PG と Unified CCE システム PG のインスタンス番号が同じ場合、それらの PG には異なる PG 番号を使用します。

- Unified CCE ゲートウェイ PG と Unified CCE システム PG のインスタンス番号が異なる場合、それらの PG に同じ PG 番号を使用することができます。

- 他の PG（VRU PG や MR PG など）をこの VM に追加しないでください。

この設計では、ローカルの Unified CCE 展開は独自のローカル IP ACD として機能し、システム内の他のサイトの可視性はありません。サイト 1 のエージェントは、この展開のサイト2からのコールまたはレポートを表示することはできません。親 Unified ICM Enterprise システムのみが、Unified ICM Enterprise システムに接続されるすべてのサイトのすべてのアクティビティを表示することができます。

Unified ICM 親サイトの Unified CVP は、分散サイトに着信するコールを制御します。Unified CVP は、音声ゲートウェイ（VG）の VXML ブラウザでコールキューイングと処理を提供します。親の Unified CVP を設定して、Unified CVP ルータ ゲートウェイを使用して、障害または応答タイムアウト中にコールを制御します。子 Unified CCE は、子 Unified CVP または子 Unified IP IVRへのイングレス コールを終了することはできません。ローカル Unified IP IVR サーバは、これらの VG から親 Unified CVP コール制御サーバへの接続のローカル バックアップのみを提供します。また、ローカル Unified IP IVR は、ローカル エージェントが応答しない（RONA）コールを、再キューされる Unified CVP に送信せずに、ローカル キュー処理を提供します。

子 Unified CCE 展開は、Unified CCE ゲートウェイ PGによる Unified ICM ポスト ルーティングを使用して、複数サイトのシステム間でコールを転送することもできます。Unified CCE ゲートウェイ PGを使用すると、子 Unified CCE が Unified ICM に、別のサイトの最適なエージェントにコールを転送するか、次に利用可能なエージェントのために集中的にキューに入れるように要求することができます。

分散型 Unified Communications Manager 周辺機器ゲートウェイを使用した従来の Unified CCE 展開とは異なり、親/子展開は、コンタクト センター サイトで完全なローカル冗長性を提供します。ローカル Unified CCE は、Unified CVP ゲートウェイからの着信コールのコール処理を引き継ぎ、ローカル Unified IP IVRでローカル コール キューイングと処理を提供します。この構成は、WAN 障害でシステム ダウンすることができないコンタクト センターの完全な冗長性と 100％ の稼働時間を提供します。

TDM ACD プラットフォームと共に Unified ICM がすでにインストールされている場合、このアプローチでは以下を行う場合に役立ちます。

- Unified CCE での新しいサイトの追加

- 既存のサイトの Unified CCE の転換

このアプローチにより、Unified ICM は、サイト毎に新しい Unified CC Eテクノロジーを導入しつつ、すべてのサイトにわたって企業全体のルーティングとレポートを継続的に実行することができます。

Note

Unified CVP は親と子のどちらでも使用することができます。コール フローは、親の Unified CVPと子の IP IVR で類似しています。大きな違いの 1 つは、子の Unified CVPでキューに入れられたコールに関する情報が、親では（Unified CCE ゲートウェイ PG を介して）利用できないことです。この違いは、親のサービスまたは CallsQNow の最小予想遅延（MED）などのルーティング要素を使用できないことを意味します。

利点

- Unified CVP では、親 Unified ICM によって制御されるすべての分散サイトにわたって仮想ネットワーク キューを提供されます。親 Unified ICM は、すべての分散サイトを表示し、仮想キューから次に応答可能なエージェントにコールを送信します。

- 各分散サイトは、単一の Unified CCE 展開でサポートされるエージェントの最大数まで拡張できます。複数の Unified CCE 集中型コントローラを単一のクラスタに接続して、クラスタ毎にサポートされるエージェントの最大数にスケールアップすることができます。親の Unified CCE ゲートウェイ PG は、Unified CCE システムを親 Unified ICM に接続します。Unified CCE ゲートウェイ PGは、親の Unified ICM Enterpriseシステム毎にサポートされるエージェントの最大数まで拡張することができます。

- 必要に応じて、すべてまたはほとんどの VoIP トラフィックを各サイトの LAN 内に含めることができます。QoS WAN は、サイト間で音声通話を転送するために必要となります。PSTN 転送サービス（Take Back and TransferまたはTransfer Connect棟）を使用すると、この必要がなくなります。必要に応じて、特定のサイトに到着するコールのごく一部を他のサイトのエージェント リソースのキューに入れて、カスタマー サービスのレベルを向上させることができます。

- Unified ICM 事前ルーティングは、エージェントまたは Unified CVP セッションの可用性に基づいてコールの負荷を分散することができます。Unified ICM は、コールを最適なサイトにルーティングして、VoIP トラフィックの WAN 使用量を削減することもできます。

- あるサイトで障害が発生しても、別のサイトでの運用に影響はありません。

- 各サイトは、そのサイトの要件に応じてサイジング可能です。

- 親の Unified ICM 集中型コントローラは、企業内のすべてのコールのルーティング設定を集中管理します。

- 親の Unified ICM 集中型コントローラは、企業全体の単一のキューを作成する機能を提供します。

- 親の Unified ICM 集中型コントローラは、すべてのサイトの統合レポートを提供します。

欠点

通常、親/子の展開には、より多くの VM が必要となります。ソフトウェア コンポーネントの数を増やすには、追加の VM が必要です（Unified CCE システム PGとのコロケーションがオプションではない場合、追加の Unified CCE ゲートウェイ PG、各子の追加集中型コントローラ等）。

要件

- コンタクト センター サイトで、Unified CCE ゲートウェイ PG、Unified Communications Manager クラスタ、Unified IP IVR、およびUnified CCE（可能な場合）をコロケートします。

- 親の Unified ICM セントラル コントローラから Unified CCE ゲートウェイ PG への通信リンクのサイズを適切に設定し、帯域幅と QoS 用にプロビジョニングする必要があります。

- WAN 帯域幅が使用できない場合、ゲートキーパー ベースまたは RSVP エージェント ベースのコール受入れ制御を使用して、PSTN 経由でサイト間でコールを再ルーティングします。発生する可能性のある呼び出しの最大量に対して、サイト間に適切な WAN 帯域幅が存在することを確認するのが最善策です。

- Unified CCE ゲートウェイ PG と親 Unified ICM 集中型コントローラ間の通信リンクが失われた場合、そのサイトでのコールのすべてのコンタクト センター ルーティングはローカル Unified CCE の制御下に置かれます。Unified CVP 制御のイングレス音声ゲートウェイには、着信コールをローカル Unified Communications Manager CTI ルート ポイントにリダイレクトする耐障害性 TCL スクリプトがあり、ローカル Unified IP IVRが WAN 停止中のローカル キューイングおよび処理を処理するために使用されます。親/子展開のこの機能は、コールセンターに完全なローカル耐障害性を提供します。

- 同じコールの 2 つのクラスタ間コール レッグは不必要な RTP ストリームは引き起こしません。ただし、2 つのクラスタ間で 2 つの個別のコール シグナリング制御パスはそのまま残ります（論理ヘアピニングを生成し、クラスタ間トランクの数を 2 つ減らします）。クラスタ間トランクの容量を決定する際は、サイト間転送の割合を考慮します。

- 親 Unified ICM 集中型コントローラとリモート Unified CCE ゲートウェイ PG 間の遅延は、片道で 200 ミリ秒（往復で 400 ミリ秒）を超過するべきではありません。

地理的冗長性を持つ子 サイト データ センター (Unified IP IVR使用)

グローバリゼーション、セキュリティ、およびディザスタ リカバリの考慮事項により、ビジネスは複数の地域にわたってロケーションを多様化しています。さらに、コンピュータ間でワークロードを分散し、ネットワーク リソースを効果的に共有し、重要なアプリケーションの可用性を向上させる必要があります。地理的に冗長な サイトのリストに追加します では、重要なアプリケーションを 2 ヵ所の サイトのリストに追加しますに分割します。企業は地理的に冗長 サイトのリストに追加します を展開して、計画的または計画外のダウンタイムを最小限に抑え、地域間でデータを共有します。

地理的に冗長な サイトのリストに追加します は、各 サイトに少なくとも 2 つのロード バランサを持ちます。ローカル冗長性のために、サイト毎に 2 つのロード バランサを使用することができます。

- 地理的冗長性を持つ子 サイト (CoW使用)

- Unified IP IVRベースの子 サイト (分散型ユニファイド コミュニケーション マネージャ)

地理的冗長性を持つ子 サイト (CoW使用)

以下の図は、Unified IP IVRを使用したWAN (CoW) 上のクラスタによる地理的に冗長な子 サイトのリストに追加します を示しています。

WAN経由のクラスタリングを利用した地理的冗長性を持つ子 サイト データ センター (Unified IP IVR使用)

地理的に冗長な サイトのリストに追加します では、WAN上のクラスタリング、Unified Communications Managerクラスタ、および IP IVR、SIP プロキシ、音声ゲートウェイ、および Cisco Unified Intelligence Center の 1 対 1 の冗長性を提供します。

高可用性 (HA) WAN でのレーテンシー要件は、WAN 経由のクラスタに対する現在の Cisco Unified Communications の要件を満たす必要があります。UnifiedCommunications Manager では、最大遅延が 40 ミリ秒 (往復で 80 ミリ秒) が許容されます。

特定の耐障害性ネットワークは、マルチプロトコル ラベル スイッチング（MPLS）や SONET など、すべてのトラフィックを単一のネットワークで伝送することができます。このようなネットワークでは、パブリック トラフィックとプライベート トラフィックをネットワーク内の別々のルートに保持し、標準の遅延と帯域幅を配慮します。

音声、制御、および CTI 用の帯域幅を使用して、エージェント サイトへの WAN 接続をプロビジョニングします。ローカル サイトおよび 911 コール用に、リモート サイト にローカル音声ゲートウェイを設定することができます。詳細については、以下で『Cisco Collaboration ソリューション設計ガイダンス』を参照してください。 http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html

バランスのとれた展開では、中央サイトが停止すると、イングレス ゲートウェイの半分が失われることになります。1 つのサイトで障害が発生した場合、両方のサイトで全負荷を処理するようにゲートウェイを拡張します。

キャリア コール ルーティングは、障害発生時にコールを代替サイトにルーティング可能である必要があります。

単一の Unified CCE システム周辺機器が、すべての Unified IP IVR と Unified Communications Manager を制御します。Unified IP IVR は、コールを最も負荷の少ない Unified IP IVRに配信します。サイト B の Unified IP IVR は、サイト Aに着信するコールを処理することができます。Unified CCE の A サイドと B サイドの両方で、すべての Unified IP IVRが識別されます。 各 Unified IP IVRのプロセスは、サイト A の PG が サイト B の Unified IP IVR に接続できることを意味します。WAN のサイズを適切に設定してください。

帯域幅のオーバーヘッドを回避するには、WAN 展開経由のクラスタリングに Unified CVP を使用することを検討します。Unified CVPを使用すると、Unified IP IVRよりもクラスタ毎の拡張性が高くなります。

Unified IP IVRベースの子 サイト (分散型ユニファイド コミュニケーション マネージャ)

エージェント、ゲートウェイ、および Unified Communications Manager クラスタが配置されるリモート オフィスがある場合は、サイトのリストに追加します のクラスタは、通常、1 つの独立した展開となります。

リモート オフィスは、メイン サイトへの WAN 接続を備えています。各クラスタは、独自のエージェントおよび PG ペアリングを使用して独立しています。JTAPI は WANではサポートされていないため、各 サイト は サイト にローカルなサブスクライバを使用します。たとえば、サイト A は サイト B のサブスクライバを使用できません。Unified CCE 中央コントローラ、Unified Intelligence Center、ロード バランサ、SIP プロキシ サーバ、および  Unified IP IVR はデータ センターに存在します。TDM および VXML 音声ゲートウェイは、リモート オフィスでローカル PSTN トランクに配置されています。

Unified ICM を使用した Unified CCE の高可用性

親/子展開では、Unified ICM は 1 つ以上の Unified CCE 子 ACD を制御する親として機能します。Unified ICM システムは、コンタクト センターのネットワーク コールルーティング エンジンです。ネットワーク キューイングは、Unified CVP および Unified CCE ゲートウェイ PG を使用して、子 Unified CCE システムを接続します。子 Unified CCE システムは、親システムへの WAN 接続が失われた場合にローカル コール処理で完全に機能する個々の ACD システムです。この構成は、Unified CCE ソリューションに高レベルの冗長性および可用性を提供します。この品質により、サイトは集中型コール処理リソースから切断されていても、Unified CCE サイトとして継続して機能することができます。

親/子展開

- 親/子コール フロー

- 親/子の耐障害性

- その他の高可用性に関する考慮事項

親/子コール フロー

以下のセクションでは、親と子の間のコール フローについて説明します。

- インバウンド PSTN コールのイベント フローの典型

- ポスト ルーティング コール フロー

インバウンド PSTN コールのイベント フローの典型

通常の PSTN からの着信コール フローでは、キャリア ネットワークは事前定義された割合 (%) 割り当てまたは自動ルーティング方法を使用して、コールをコンタクト センター サイトに転送します。これらのコールは、親 Unified ICM の Unified CVP の制御下にあるコンタクト センター ロケーションの Unified CVP VG（音声ゲートウェイ）で終端します。

着信コール フローは以下の通りです。

1. コールが親 ICM サイトの Unified CVP VG に到着します。

2. Unified CVP VG は、ダイヤル番号によってコールを親サイトの特定の Unified CVP サーバにマッピングします。次に、VG が新しいコール イベントを Unified CVP サーバに送信します。

3. Unified CVP サーバは、新しいコール イベント メッセージを、Unified ICM 親サイトの Unified CVP VRU PG に送信します。

4. Unified CVP PG は、親 Unified ICMに新しいコール メッセージを送信します。Unified ICM は、着信ダイヤル番号を使用してルーティング スクリプトを修飾し、コールについて考慮する適切なコール処理（メッセージング）またはエージェント グループを決定します。

5. Unified ICM は、 Unified CVP にサイトの VG でコールを保留するように指示します。Unified CVP は、保留音楽用の .wav ファイルを再生する特定の指示を発信者に発し、応答可能なエージェントを待機します。

6. エージェントが応答可能になると、Unified ICM は、変換ルートを使用してコールを応対可能なエージェントに転送するように Unified CVP に指示します。(エージェントは同じ物理サイトではなく、WAN 上に配置されています。) Unified ICM の親 Unified CVP でコールに関して収集されたデータはすべて、リモート PG（TDM、従来の PG、または Unified CCE の Unified CCE ゲートウェイ PG のいずれか）に転送されます。

7. コールが、親 Unified ICM が選択した特定の変換ルート DNIS 上のターゲット サイトに到着します。子サイトの PG では、コールがこの DNIS に到着してコールに関連付けられた事前コール CTI データと一致することを期待しています。ローカル ACD または Unified CCE は、PG へのポスト ルーティング要求（ターゲット ACD に応じて TDM PG またはゲートウェイ PGのいずれか）を実行して、CTI データとコールの最終宛先（通常は応答可能なエージェントのグループのスキルのリード番号）を要求します ）。

8. エージェントが応答可能でなくなった場合、親サイトの Unified CVP は、ICM コール ルーティング スクリプトのルータ再クエリ機能を使用して、別のターゲットを自動的に選択します。

ポスト ルーティング コール フロー

別のエージェントまたは場所にインテリジェントにルーティングする周辺機器 ACD または VRU にすでに存在するコールに対してポスト ルーティングを使用します。エージェントが ACD または Unified CCE で別のスキル グループまたはロケーションに移動する必要があるコールを受信した場合、エージェントはポスト ルーティング機能を使用してコールを再ルーティングすることができます。

ポスト ルーティング コール フローは以下の通りです。

1. エージェントは、CTI エージェント デスクトップを使用して、再ルーティング処理のためにローカル CTI ルート ポイントにコールを転送します。

2. 再ルーティング アプリケーションまたはスクリプトは、ローカルの Unified CCE ゲートウェイ PG 接続を使用して、親 Unified ICM にポスト ルーティング要求を行います。

3. 親 Unified ICM は、Unified CCE からの CTI ルート ポイントを着信番号としてマップし、その番号を使用してルーティング スクリプトを選択します。このスクリプトは、コールを別のサイト、同じサイトの別のスキル グループ、またはキューイング用の Unified CVP ノードに移動可能なラベルまたはルーティング命令を返します。

4. Unified CCE は、親 Unified ICM システムからポスト ルーティング応答を受信します。次に、Unified CCE は返されたルーティング ラベルを転送番号として使用して、次の宛先にコールを送信します。

親/子の耐障害性

親/子モデルは、ローカル IP-PBX およびコール処理とキューイング機能により、サイトに展開される Unified CCE で完全な ACD を維持する耐障害性を提供します。

- Unified CCE の Unified ICM への接続の損失

- Unified CCE ゲートウェイ PG が Unified ICM に接続できない

- レポートおよび設定の影響

Unified CCE の Unified ICM への接続の損失

子と親の間の WAN 障害により、ローカルの Unified CCE システムが親と Unified CVP VG から分離されます。サイトに着信するコールは、親 Unified ICM の制御下で Unified CVP の処理が行われなくなります。子サイトの構成に応じて、以下の機能をローカルに複製します。

- キューおよび処理にローカル IP IVR リソースを使用する子 Unified CCE 設定の場合:

- ローカル VG には、親 Unified CVP サーバに到達できない場合に、ローカル Unified CM クラスタにコールの制御を渡すためのダイヤル ピア ステートメントが必要です。ローカル Unified CM クラスタには、親の Unified CVP サーバに到達しない場合にローカル VG が提示する着信 DNIS またはダイヤル番号にマップされる CTI ルートポイントが必要です。

- 適切な音声ファイルとアプリケーションを使用してローカル IP IVR を構成し、子システムがローカルで呼び出しを行い、基本的なコール処理を提供できるようにします。

- 子 CCE ルーティング スクリプトは、ローカル スキル グループのエージェントのコールのキューイングを処理する必要があります。スクリプトは、IP IVR にエージェントを待つ間にキュー内で再生を実行するように指示する必要があります。

- エージェントがルーティングおよびスクリーン ポップのために顧客データにフル アクセスできるようにするには、親システムが通常提供するデータ ルックアップまたは外部 CTI アクセスをローカルでプロビジョニングします。

- 障害時には、ルーティング後の転送スクリプトが失敗するため、障害時処理を行うように Unified CCE を設定するか、ルーティング後のスクリプトがアクセスされないようにします。

- キューおよび処理にローカル Unified CVP リソースを使用する子 Unified CCE 設定の場合:

- ローカル VG には、コールの制御を子サイトのローカル Unified CVP サーバに渡すためのダイヤル ピア ステートメントが必要となります。コールを子サイトでローカルに処理するには、子 Unified CCE で、ローカル VG が子 Unified CVP に提示する着信 DNIS またはダイヤル番号を設定します。

- 適切な .wav ファイルとアプリケーションを使用してローカル VXML ゲートウェイと Unified CVP サーバを構成し、子システムがローカルで呼び出しを行い、基本的なコール処理を提供できるようにします。

- 親の Unified ICM が通常提供するセルフサービスまたは Unified CVP Studio VXML アプリケーションをコピーします。子サイトで Unified CVP サーバ（Webアプリケーション サーバ）を使用して、これらのアプリケーションのダイナミック VXML を生成します。

- 子 Unified CCE ルーティング スクリプトは、ローカル スキル グループのエージェントのコールのキューイングを処理する必要があります。スクリプトは、子サイトのローカル Unified CVP に、エージェントを待機している間にキュー内で処理を行うように指示する必要があります。

- エージェントがルーティングおよびスクリーン ポップのために顧客データにフル アクセスできるようにするには、親システムが通常提供するデータ ルックアップまたは外部 CTI アクセスをローカルでプロビジョニングします。

- 障害時には、ルーティング後の転送スクリプトが失敗するため、障害時処理を行うように Unified CCE を設定するか、ルーティング後のスクリプトがアクセスされないようにします。

Unified CCE ゲートウェイ PG が Unified ICM に接続できない

Unified CCE ゲートウェイ PG で障害が発生するか、Unified ICM 親と通信できない場合、Unified ICM 親は子のエージェントの状態を検出できません。ただし、場合によっては、Unified ICM の親 Unified CVP が引き続き着信コールを制御することができます。この場合、親 Unified ICMは、リモート Unified CCE ゲートウェイ PGが失敗したか、実際の Unified CCE ACD がローカルで失敗したかを判断できません。

親ロケーションの Unified ICM は、PG が再びオンラインとなり、エージェントの状態を再度報告するまで、このサイトがダウンしているものと想定して、自動的にこのサイトを避けてルーティングすることができます。あるいは、Unified ICM は、Unified CM のローカル インバウンド CTIルート ポイントを使用して、コールの割合 (%) をブラインド転送としてサイト Unified CCE に転送することも可能です。この方法では、Unified CVP からの CTI データがないコールが提示されますが、サイトのエージェントは、Unified CCE システムでローカルに継続してコールを取得することができます。

ローカルの子 Unified CCE システムに障害が発生すると、Unified CCE ゲートウェイ PG は接続することができません。この際、親 Unified ICM は、すべてのエージェントがオフラインであり、利用できないと見なします。子の Unified CCE システムがダウンしているときにローカル クラスタがコールを受信すると、障害時の自動転送処理が CTI ルート ポイントのコールを引き継ぎます。このメソッドは、呼び出しを別のサイトまたは応答リソースにリダイレクトして、問題があることを発信者に伝えるメッセージを再生し、後で再度呼び出しを行います。

レポートおよび設定の影響

子 Unified CCEが親 Unified ICM との接続を損失した場合でも、ローカル ACD がレポート データを収集し、ローカル管理者は子のルーティング スクリプトと構成を変更できるようにします。子サイトの Unified CCE ゲートウェイ PG は、これらのオブジェクトをキャッシュし、親 Unified ICM が利用可能になったときに送信されるオブジェクトを保存します。この機能は、Unified CCE ゲートウェイ PG が子 Unified CCE サイトに配置されている場合にのみ提供されます。

その他の高可用性に関する考慮事項

Cisco Unified Web and E-mail Interaction Manager や Cisco アウトバウンド オプションなどのマルチチャネル コンポーネントは、親ではなく子の Unified CCE レベルでのみインストールすることができます。上記は、サイト毎にノード導入として扱われます。

従来の ACD 統合

従来の ACD を Unified CCEと統合する企業は、親/子展開を使用します。この展開では、Unified ICM および Unified CCE にはそれぞれ、集中型コントローラ、または TDM ACD PG を備えた Unified Communications Manager PG、ゲートウェイ PG、またはその両方が同じ集中型コントローラを使用するハイブリッド展開があります。これらのカテゴリには、展開内でのコールのルーティング方法に応じて、いくつかのオプションがあります。

- 固定 PSTN 配信によるハイブリッド導入

- Unified CVP を使用したハイブリッド導入

- ACD 統合および親/子の展開

固定 PSTN 配信によるハイブリッド導入

PSTNは、PSTNからのコールを事前ルーティングする代わりに、PSTNでプロビジョニングされた静的ルールのセットに従い、1 ヵ所のサイトのみにコールを配信したり、2 つのサイトにコールを分割したりすることができます。コールがいずれかのサイトに到着すると、従来の ACD または Unified Communications Manager がハイブリッド Unified ICM / CCE へのルート要求を生成して、このコールに最適なサイトを決定します。コールが最初にルーティングされた場所の反対側のサイトのエージェント向けである場合、サイト間に TDM 回線が必要となります。コールがルーティングされる場所の決定（およびサイト間で転送されるかどうか、およびいつ転送されるか）は、企業のビジネス環境、目標、およびコスト コンポーネントによって異なります。

Unified CVP を使用したハイブリッド導入

Unified CVP を使用してすべてのコールをフロント エンドとし、TDM ACD エージェントと Unified CCE エージェントの両方で初期コール処理とキューイングをする展開を選択することもできます。

この設計では、すべてのコールはまず Unified CVP によって制御される音声ゲートウェイ（VG）に着信します。次に、Unified ICM / CCE コール ルータがコールを転送します。Unified ICM/CCEは、TDM ACDおよび Unified CCE PG への PG 接続を使用して、使用可能なエージェントを監視します。エージェントがいずれかの環境で使用可能になるまで、コールは Unified CVP のキューに入れられます。コールが TDM ACD に転送されると、コールは PSTN キャリア ネットワークから T1 インターフェイスの VG に着信し、2 番目の物理 T1 インターフェイスに向かい、TDM ACD のトランクとして表示されます（これは「コールのヘアピン」と呼ばれます） ）。ほとんどの TDM ACD は、VG からの IP での着信コールを受け入れることができないため、この物理 T1 インターフェイス接続が必要となります。Unified CCE エージェントは、IP 音声ネットワークを介して直接コールを受信します。

ACD 統合および親/子の展開

以下の図で親/子の例を説明します。

従来の ACD と Unified CCE の親/子統合

このモデルでは、親 Unified ICM Enterprise には、1 ヵ所のサイトでUnified CCE システム PG に接続された PG があり、2 ヵ所目のサイトで Unified ICM TDM ACD PG が接続されます。このモデルでは、Unified ICM は引き続きサイトに分散された Unified CVP 音声ゲートウェイを使用して、エンタープライズ規模の仮想ルーティング、コール処理、およびキューイングを提供します。また、Unified ICM は、進行中のエージェントおよびコールのすべてのサイトを完全に可視化します。このモデルの違いは、Unified CCE がローカル耐障害性を提供する点ことです。親 Unified ICM への接続が失われた場合でも、コールは TDM ACD サイトと同様にローカルで処理されます。

従来の VRU 統合

従来の VRU を Unified CCE 展開に統合する方法は多数あります。次のセクションでは、最適な方法を決定することができる要因について説明します。主な考慮事項は、VRU からコールを転送する際に VRU の重複トランキングを削除または削減する方法を決定することです。

- PBX 転送を使用した統合

- PSTN 転送を使用した統合

- VRU ダブルトランクを使用した統合

- ユニファイド コミュニケーション マネージャ転送および VRU ダブル トランキング

PBX 転送を使用した統合

多くのコール センターには、再プログラミングの準備ができていない既存の従来の VRU アプリケーションがあります。これらの VRU アプリケーションを保持して Unified CCE 環境に統合するには、VRU に Unified CCE へのインターフェイスが必要となります。Unified CCE への VRU インターフェイスは、Service Control Interface（SCI）です。SCI により、VRU は Unified CCE からキューイング命令を受信することができます。PBX モデルでは、SCI は必要ありません。

VRU に SCI インターフェイスがある場合でも、すべてのコールキューイングで Unified CVP または  Unified IP IVR を展開します。この方法は、従来の VRU ポートの不必要な使用の防止となります。また、キューイングに Unified IP IVR を使用すると、後続の転送または RONA 処理でコールを再キューイングする方法が提供されます。

PBX 転送を使用した従来の VRU 統合

この設計では、標準 T1 トランク インターフェイス上の PSTN キャリア ネットワークから PBX に最初にコールが着信します。PBX は通常、ハント グループを使用してコールを VRU に転送し、すべてのVRUポートを auto モードのエージェントとしてハント グループに入れます。PBX は、PG が PBX に接続されていないため、Unified CCE からは PSTN であるかのように見えます。Unified CCE は、元の配信から VRU へのコールを追跡することはできません。Unified CCE には、コールが VRU に到着した時点からのコール データのみが含まれ、VRU はコールについて Unified CCE に通知されます。

発信者が VRU アプリケーションからオプトアウトすると、VRU はポストルーティングを Unified CCE に送信します。Unified CCE は、システム全体のエージェントの状態を調べます。Unified CCE は、コールを送信するエージェントを選択するか、キューイングのためにコールを Unified IP IVR に変換ルーティングします。

コールがエージェントまたはキューに送信されると、コールは T1 トランクポートの PSTN から PBX に着信し、PBX の 2 番目の T1 トランクポートの VG に発信されます。この接続は、コールの存続期間中に使用されます。

PBX のエントリからコールを追跡する場合、または発信者の ANI または元のダイヤル番号をキャプチャする場合は、PBX に PG をインストールすることができます。PBX は（Unified CCE へのポスト ルートを介して）PBX の背後にコールを送信する VRU ポートを要求することができます。PBX は、ハント グループを使用して、PBX から VRU にコールを配信することはできません。Unified CCE では、変換ルートが PBX で収集されたコール データを維持し、VRU で利用できるようにするために、DNIS を直接終端する必要があります。

PSTN 転送を使用した統合

このモデルは、PBX 転送モデルと類似しています。このモデルでは、VRU は（PBX 転送でなく）PSTN 転送を呼び出して、従来の VRU ポートを解放します。再び Unified IP IVR はすべてのキューイングを実行し、従来の VRU ポートの重複トランキングや VRU の重複トランキングを回避します。Unified CCE は、従来の VRU アプリケーションによって収集されるコール データをエージェント デスクトップまたは Unified IP IVRに渡します。

このモデルでは、TDM VRU は、着信コール用の直接 PSTN 接続を持つ VRU プラットフォームのファームとして設定されます。VRU では、システム内のすべてのコールを追跡する Unified CCE への PG 接続が提供されます。発信者が VRU 処理をオプトアウトすると、VRU はルート後要求を Unified CCE に送信します。Unified CCE は、キューに入れるためにエージェントまたは Unified IP IVR にコールを誘導するラベルを返します。

TDM VRU に返されるラベルは、転送トーンを使用して帯域内転送コマンドを送信するように指示します（* 8、キャリア ネットワーク内の宛先ラベル付き）。VRU は、トーン生成を使用してこれらのトーンをサービス プロバイダーに出力するか、記録されたファイルを使用してトーンを再生します。

VRU ダブルトランクを使用した統合

一部の従来の VRU アプリケーションは成功率が高く、ほとんどの発信者は従来の VRU で完全にセルフサービスを行い、発信者のごく一部のみがエージェントに転送されます。このような場合、従来の VRU のコールをその少数の割合で重複トランキングすることができます。

前のモデルとは異なり、従来の VRU にサービス コントロール インターフェイス（SCI）がある場合、初期コール キューイングは従来の VRU で行われます。この場合、VRU ダ承服トランキングは、コールを Unified IP IVRに転送するために 2 番目の従来の VRU ポートを使用しません。従来の VRU が初期キューイングを行う場合、1 つの従来の VRU ポートのみがコールに使用されます。ただし、転送またはRONA処理のための後続のキューイングは、重複トランキングを回避するために Unified IP IVR で実行する必要があります。

従来の VRUにSCI インターフェイスがない場合、VRU は、Unified CCE へのポスト ルート要求を生成して、コールの転送先を決定します。そのシナリオでのすべてのキューイングは、Unified IP IVRで発生します。

VRU 重複トランキングを使用した従来の VRU 統合

このモデルでは、TDM VRU は、着信コール用の直接 PSTN 接続を持つ VRU プラットフォームのファームとして設定されます。VRU では、システム内のすべてのコールを追跡する Unified CCE への PG 接続が提供されます。発信者が VRU 処理をオプトアウトすると、VRU はルート後要求を Unified CCE に送信します。Unified CCE は、サービス コントロール インターフェイス（SCI）を使用して、コールをエージェントに転送するか、TDM VRU でローカルにコールをキューイングするラベルを返します。TDM VRU は、音声ゲートウェイと Unified CCE エージェントへのコールをヘアピンする2番目のポートを選択することにより、エージェントへの転送を行います。ヘアピン接続では、コールがエージェント側にある間、2 つのポートを占有します。

ユニファイド コミュニケーション マネージャ転送および VRU ダブル トランキング

時間が経つにつれて、従来の VRU アプリケーションを Unified CVP または Unified IP IVRに移行できます。特定のシナリオで従来の VRU アプリケーションがまだいくつか存在する場合、VRU は2番目の音声ゲートウェイ（VG）に接続することができます。Unified Communications Managerが、PSTN から VG に到着するコールをルーティングします。Unified Communications Manager は、特定の DN を従来の VRU にルーティングしたり、Unified CCE、Unified CVP、または Unified IP IVR に従来の VRU にいつ通話を転送するかを決定させることができます。従来の VRU のコールを Unified CCE エージェントに転送するには、コール中に 2 番目の VRU ポート、トランク、および VG ポートを使用します。複数のループが発生したり、音声品質が低下しない転送シナリオであることを確認します。

ユニファイド コミュニケーション マネージャ転送および VRU ダブル トランキング

このモデルでは、Unified CVP は VG を使用して TDM VRU をフロントエンドとし、コール処理を提供する場所を決定できます。または、上記目的のために、 Unified IP IVR および Unified Communications Manager や Unified CCE を使用することができます。

Unified CVP を使用すると、VG に着信するコールは、Service Control Interface（SCI）を使用して Unified CCE とのルーティング ダイアログをすぐに開始します。Unified CVP は、最初のダイヤル番号または Unified CVP のプロンプトに基づいて、特定のセルフサービス アプリケーションの TDM VRU または Unified CVP へのコールの送信を決定します。コールが TDM VRU に送信された場合、発信者がオプトアウトすると、TDM VRU はルート要求を Unified CCE に送信します。応答は TDM VRU に返されず、元のルーティング クライアントとして Unified CVP に返されます。次に、Unified CV Pはコールレッグを TDM VRU から取り除きます。次に、Unified CVP は、VoIP ネットワークを介してコールを Unified CCE エージェントに転送するか、VG のローカルでキューにコールを保持します。

Unified Communications Manager を使用すると、VG 内のコールはサブスクライバ CTI ルート ポイントを使用して、適切なコール処理デバイスのルート要求を Unified CCE に送信します。CTI ルート ポイントが、まだ TDM VRU 上にあるアプリケーションを示している場合、Unified CCE は、VG の 2 番目の T1 ポートを使用してコールをヘアピンすることにより、TDM VRU にコールを転送するようにサブスクライバに指示します。Unified CCE は、コール処理またはプロンプトのためにコールを Unified IP IVR に変換ルーティングするようにサブスクライバに指示することもできます。その後、Unified CCE は、その後の処理を行うために、TDM VRU への後続の転送を行うことができます。発信者が TDM VRU からオプトアウトすると、TDM VRU にラベルのポストルート要求を Unified CCE に送信します。このラベルは、VRU の 2 番目の T1 ポートを使用して VG にコールを転送するように TDM VRU に指示します。VGは、Unified Communications Manager ダイヤル プランの下で Unified CCE エージェントにコールを転送します。

Unified Communications Manager によって制御されるモデルでは、VG は最初にコールを受信し、2 番目の T1 ポートの TDM VRU に送信します。VRU が Unified CCE エージェントにコールを返す際、VG の 2 番目の TDM VRU ポートと 3 番目のポートを使用します。エージェントが発信者と会話している限り、3 つの VG ポートはすべて使用中となります。TDM VRU ポートは両方とも、残りのコールに使用されます。

非リファレンス設計 コア コンポーネントおよび導入

- MGCP ゲートウェイの使用

- ネットワーク VRU のタイプ

- ネットワーク VRU タイプと Unified CVP の展開

- Unified ICM ホスト型の導入

- Unified CM、ACD コールの展開、サイジングの影響

- サードパーティ VRU

- 解放トランク転送

- VXML 転送

- 非リファレンス コール フロー

- Unified CM の非リファレンス設計の導入

- Unified CCE エージェント デスクトップ オプション

- Cisco Unified IP IVR

- Unified Intelligent Contact Manager

- 汎用周辺機器ゲートウェイ

- 周辺機器ゲートウェイおよびサーバ オプション

MGCP ゲートウェイの使用

Cisco Unified CVP では、SIP ゲートウェイを導入する必要があります。ただし、オーバーラップ送信、NSF、および Q.SIG サポートの目的で、Unified CM を使用する MGCP 0.1 ゲートウェイの導入を使用する必要がある場合があります。次の設計上の考慮事項は、この環境での Cisco Unified CVP の展開に適用されます。

- 各 MGCP 音声ゲートウェイから SIP への段階的な移行を設計および計画します。

- MGCP 0.1 と SIP の両方を実装します。

MGCP の動作により、MGCP を使用した PSTN インターフェイスは MGCP にのみ使用できます。標準の Unified CM コールに MGCP、Unified CVP コールに SIP を使用する場合は、2 つの PSTN 回線が必要となります。

- Unified CVP の各場所に別の SIP 音声ゲートウェイを導入します。

- Unified CVP に Unified CM を介してコールを送信します。

Unified CM を介してコールを Unified CVP に送信する場合は、次のガイドラインが適用されます。

- Unified CVP 耐障害性.tcl スクリプトは、このソリューションでは使用できません。リモート サイトが中央サイトから切断されている場合は、コールがドロップされます。

- Unified CM のパフォーマンスに対しては追加の影響があります。通常の Unified CVP 導入では、コールがエージェントに送信されるまで Unified CM リソースが使用されないためです。このモデルでは、コールがセルフサービスで終了する場合でも、Unified CM リソースが Unified CVP へのすべてのコールに使用されます。これは、エージェントに到達するコールに対する追加になります。すべてのコールが最終的にエージェントに到達する場合、Unified CM のパフォーマンスへの影響は、通常の Unified CVP 導入の約 2 倍になります。この要因だけでも、通常、このシナリオは小規模なコール センターに限定されます。

- エッジでコールをキューに入れるには、適切なサイトまたは 音声ブラウザでコールがキューに入れられるように、Unified CVP の sigdigits 機能を使用する必要があります。

Note

Cisco Unified CVP には、多くのシナリオで Unified CVP を追加、変更、削除、または展開する柔軟性があり、サードパーティ製のデバイスとの相互運用を促進できます。すべての SIP サービス プロバイダーが、REFER、302 リダイレクト メッセージ、DTMF ベースの取り消しと転送、またはデータ転送（UUI、GTD、NSS 等）の拡張機能をサポートするわけではありません。Cisco CUBE の代わりに展開したときの SBC の相互運用性サポートに関する詳細については、次の URL から入手可能な相互運用性の注意事項を参照してください。 http://www.cisco.com/en/US/solutions/ns340/ns414/ns728/voice_portal.html

ネットワーク VRU のタイプ

ここでは、Unified ICM のネットワーク VRU タイプ、Unified ICM と Unified CVP 展開の関係性について説明します。説明する項目は以下の通りです。

- Unified ICM のネットワーク VRU

- Unified CVP タイプ 10 VRU

- Unified CVP タイプ 7 VRU（相関 ID メカニズム）。

- Unified CVP タイプ 8 VRU（トランスレーション ルート ID メカニズム）。

Note

音声応答装置（VRU）と自動音声応答（IVR）という用語は同じ意味で使用されます。

- Unified ICM ネットワーク VRU

- Unified CVP タイプ 10 VRU

- Unified CVP タイプ 7 VRU（相関 ID 機能）

- Unified CVP タイプ 8 VRU（トランスレーション ルート ID 機能）

Unified ICM ネットワーク VRU

Unified ICM は、IVR 処理を必要とするコールには、スイッチ レッグと VRU レッグという 2 つの部分があると認識しています。スイッチは、ネットワークまたは発信者からのコールを最初に受信するエンティティです。VRU は、オーディオを再生し、プロンプト/コレクト機能を実行するエンティティです。Unified ICM を使用する場合、Unified CVP はスイッチ ロールまたは VRU ロール、あるいはその両方に参加できます。ネットワーク展開では、複数の Unified CVP デバイスはスイッチと VRU 部分を個別に提供します。

VRU へのコール配信は、コール参照 ID を VRU に渡すネットワーク機能に応じて、相関 ID 機能またはトランスレーション ルート ID 機能に基づいて行うことができます。Unified ICM はコールを完了する指示を出すために同じコールの 2 つのレッグを相関させる必要があるため、コール参照 ID が必要となります。Unified ICM アプリケーションでは、VRU は、スイッチから受信した着信コールの処理方法に関する指示を要求する際、このコール参照 ID を Unified ICM に提供します。この方式で、Unified ICM は同じコールの適切なコール コンテキストを取得することができ、この段階でコールの IVR 部分に進むことになります。

- 相関 ID：この方式は、ネットワークがコール参照 ID を VRU に渡せる場合に使用されます。スイッチがあるネットワーク内に VRU がある場合、コール シグナリングがこの情報を保持できます（たとえば、 Unified ICM が使用されるときに 相関 ID 情報がダイヤルされた番号に付加されます）。この機能は、通常は、VoIP ネットワーク内で転送されるコールに適用されます。

- トランスレーション ルート ID：この方式は、VRU が PSTN を介して到達可能であり（たとえば、VRU が顧客構内にある場合）、ネットワークが VRU へのコールの配信においてコール参照 ID 情報を保持できない場合に使用されます。VRU に到達するために Unified ICM で一時的な電話番号（トランスレーション ルート ラベルと呼ばれます）が設定される必要があり、ネットワークは通常はコールを PSTN での他の電話番号ルーティングと同様に VRU へルーティングします。VRU が Unified ICM からの指示を要求する際、VRU はこのラベル（受信される番号のサブセットの場合もあります）を提供し、Unified ICM は同じコールの 2 つの部分を相関させることができます。通常、PSTN キャリアは、この目的で使用するためのトランスレーション ルート ラベルのセットを含んでいます。

Note

展開される VRU は、ネットワーク内（ネットワーク VRU）または顧客構内に展開できます。顧客構内で、Network Applications Manager（NAM）がネットワーク内に展開され、カスタマー ICM（CICM）が顧客構内に展開されます。VRU の位置によって、対応する相関 ID またはトランスレーション ルート ID が使用されます。

Unified CVP タイプ 10 VRU

Unified CVP タイプ 10 VRU は、Unified CVP の包括モデル展開におけるコンフィギュレーション要件を簡略化します。VRU 専用展開を除く新規インストールにタイプ 10 VRU を使用します。ICM Customers を使用する必要がある展開では、Unified CVP VRU スイッチ レッグから完全に別の Unified CVP への 2 ステップ転送（たとえば、SendToVRU を使用した 2 ステップでの CVP から CVP への転送）は開始できません。これらの 2 ステップ転送を動作させるには、トランスレーション ルートを使用する必要があります。

タイプ 10 ネットワーク VRU は次のように動作します。

- 転送されたルーティング クライアントの責任は、Unified CVP スイッチ レッグにハンドオフされます。

- VRU、ACD、または Cisco Unified Communications Manager（Unified CM）により発生したコールの場合、Unified CVP VRU レッグへの自動転送が発生し、その結果、別の転送が発生します。

- Unified CM により発生したコールの場合、相関 ID 転送メカニズムが使用されます。相関 ID は、タイプ 10 ネットワーク VRU コンフィギュレーションで定義された転送ラベルの最後に自動的に追加されます。

- Unified CVP VRU レッグへの最後の転送はタイプ 7 転送と同様であり、転送の前に VRU に送信される RELEASE メッセージが含まれます。

ICM Customers 機能を使用しない Unified CVP 実装で（つまり、単一ネットワーク VRU を使用する Unified CVP 実装で）単一のタイプ 10 ネットワーク VRU を定義する必要があります。Unified CVP スイッチ レッグ ルーティング クライアント用にラベルが 1 つあり、コールを Unified CVP VRU レッグに転送します。コールが Unified CM から Unified CVP に転送される場合、Unified CM ルーティング クライアント用にも別のラベルがあり、このラベルは CVP ルーティング クライアント用に使用されるラベルとは異なるラベルである必要があります。このラベルによって、コールは Unified CVP スイッチ レッグに転送されます。Unified ICM ルータは、このラベルに相関 ID を連結して Unified CM に送信します。この任意の追加の桁を処理するには、Unified CM を設定する必要があります。

同じタイプ 10 ネットワーク VRU を指すように、Unified CVP スイッチ レッグ ペリフェラルを設定してください。また、Unified CVP に転送されるコールのすべての着信番号を、同じタイプ 10 ネットワーク VRU を指すカスタマー インスタンスに関連付けてください。

コール ルーティング インターフェイス VRU または TDM ACD で発生するコールの場合、TranslationRouteToVRU ノードを使用してコールを Unified CVP のスイッチ レッグ ペリフェラルに転送する必要があります。その他のすべてのコールの場合は、SendToVRU ノード（自動の SendToVRU 機能を含むノード（キューイング ノードなど））または RunExternalScript を使用します。

Note

タイプ 5 およびタイプ 2 VRU タイプはサポートされません。これらの VRU タイプの代わりに、タイプ 10 VRU を使用します。

相関 ID

トランスレーション ルート DNIS または相関 ID が付加された VRU ラベル用の適切なルート パターンを設定します。タイプ 10 VIRUで相関 ID メソッドを使用します。Unified CM でルート パターンを設定し、感嘆符（!）などの追加の数字をパターンの最後に追加できるようにします。

Unified CVP タイプ 7 VRU（相関 ID 機能）

VRU が相関 ID 機能を備えた IVR として機能する場合、Unified ICM はタイプ 3 およびタイプ 7 を使用し、相関 ID スキームの周辺機器ゲートウェイを使用して VRU のサブ動作を指定します。タイプ 3 およびタイプ 7 VRU はどちらも相関 ID 機能を使用して到達可能であり、VRU を制御するために周辺機器ゲートウェイが必要です。ただし、これら 2 つのタイプでは、VRU レッグの解放方法およびコールを最終宛先に接続する方法が異なっています。

タイプ 3 では、コールを VRU に配信するスイッチは、コールを VRU から取得して宛先（またはエージェント）に接続できます。

タイプ 7 では、スイッチはコールを VRU から取得できません。IVR 処理が完了すると、Unified ICM は切断するか VRU レッグを解放する必要があり、その後で最終接続メッセージをスイッチ レッグに送信して、コールを宛先に接続するようにスイッチに命令できます。

インテリジェント ペリフェラル IVR として使用される場合、Unified CVP は、VRU レッグが不要になったときに Unified ICM から明確な指示を取得するため、タイプ 7 のみをサポートします（コールが引き出されたことを 音声ブラウザから通知されるのを待機するのではなく）。タイプ 3 は廃止されました。

コールにはスイッチ レッグと VRU レッグの 2 つのレッグがあります。異なる Unified CVP ハードウェアを各レッグに使用できます。VRU タイプ 7 として機能する周辺機器ゲートウェイで VRU レッグの Unified CVP とともにサービス ノードを使用すると、IVR アプリケーションを完了します（セルフサービスとキューイングなど）。

Note

VRU 専用を除き、Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には、タイプ 10 VRU を使用してください。

VRU タイプ 7 を使用した Unified CVP アプリケーションの設定例については、http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.htmlの Configuration Guide for Cisco Unified Customer Voice Portalを参照してください。

Unified CVP タイプ 8 VRU（トランスレーション ルート ID 機能）

VRU がトランスレーション ルート ID 機能を備えた IVR として機能する場合、Unified ICM はタイプ 8 またはタイプ 10 を使用し、トランスレーション ルート ID スキームの周辺機器ゲートウェイを介して VRU のサブ動作を指定します。タイプ 8 およびタイプ 10 VRU はどちらもトランスレーション ルート ID メカニズムによって到達可能であり、VRU を制御するために周辺機器ゲートウェイが必要です。ただし、コールを最終宛先に接続する方法が異なります。

タイプ 8 では、コールを VRU に配信するスイッチは、コールを VRU から取得して宛先またはエージェントに接続できます。

スイッチが VRU から離れたコールを取得してエージェントに配信できない場合は、タイプ 10 を使用します。その場合、IVR 処理が完了すると、Unified ICM は最終接続メッセージを（元のスイッチではなく）VRU に送信して、コールを宛先に接続します。VRU はコールを受信すると、スイッチングの制御責任を負います。このプロセスをハンドオフといいます。

相関 ID と同じように、コールにはスイッチ レッグと VRU レッグという 2 つのレッグがあります。Unified CVP はスイッチ レッグまたは VRU レッグのいずれかに使用します。たとえば、ネットワーク インターフェイス コントローラ（NIC）、NAM、または CICM が含まれる場合、Unified CVP を VRU レッグでタイプ 8 またはタイプ 10 に設定します。

Note

VRU 専用を除き、Unified ICM 7.1 以降を使用する Unified CVP の新規実装には、タイプ 10 VRU を使用してください。

VRU タイプ 8 またはタイプ 10 を使用した Unified CVP アプリケーションの設定例については、http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.htmlの Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

ネットワーク VRU タイプと Unified CVP の展開

Unified ICM で、ネットワーク VRU はネットワーク VRU エクスプローラを使用してアクセスすることができる設定データベースのエンティティです。ネットワーク VRU エントリには、次の情報が含まれています。

- タイプ：VRU タイプのいずれかに対応する7、8、および 10 の数。

- ラベル：特定のネットワーク VRU にコールを転送するために Unified ICM で使用するラベルのリスト。これらのラベルはタイプ 7 または 10 のネットワーク VRU にのみ関連します（つまり、コールの転送に相関 ID 機能を使用するこれらの VRU タイプ）。各ラベルは次の 2 つの部分で構成されています。

- 着信番号識別サービス（DNIS）になるディジット ストリング。SIP プロキシ サーバやスタティック ルーティング テーブル（SIP 使用時）、またはゲートウェイ ダイヤル ピアは DNIS を理解します。

- ルーティング クライアント、またはスイッチ レッグ ペリフェラル。いずれの場合もディジット ストリングは同じですが、スイッチ レッグとして機能する各ペリフェラル デバイスにはラベルが必要です。

アクティブ コールに関連付けられるまでは、ネットワーク VRU コンフィギュレーション エントリには値はありません。Unified ICM の関連付け は以下の場所で行われます。

- PG エクスプローラ ツールの特定のペリフェラルの [詳細設定（Advanced）] タブ

- Unified ICM インスタンス エクスプローラ ツールのカスタマー インスタンス コンフィギュレーション

- VRU スクリプト リスト ツールのすべての VRU スクリプト コンフィギュレーション

Protocol-Level コール フローに応じて、現在使用している Unified ICM Enterprise はペリフェラルまたはカスタマー インスタンスを参照し、コールを VRU に転送する方法を決定します。Unified ICM Enterprise は、コールが最初にスイッチ レッグに着信するときはスイッチ レッグ ペリフェラルに関連付けられたネットワーク VRU を調べ、トランスレーション ルート メカニズムを使用してコールが VRU に転送されているときは VRU レッグ ペリフェラルに関連付けられたネットワーク VRU を調べます。Unified ICM Enterprise は、相関 ID メカニズムを使用してコールが VRU に転送されているときは、カスタマー インスタンスに関連付けられたネットワーク VRU を調べます。

Unified ICM Enterprise は、ルーティング スクリプト内に RunExternalScript ノードがあるたびに、VRU スクリプトに関連付けられたネットワーク VRU も確認します。Unified ICM が、指定されたネットワーク VRU にコールが現在接続されていないと判断すると、VRU スクリプトは実行されません。

Unified ICM Enterprise Release 7.1 では、ネットワーク VRU タイプ 10 が導入されました。これにより、Unified CVP のネットワーク VRU のコンフィギュレーションが容易になります。ほとんどのコール フロー モデルでは、カスタマー インスタンス、スイッチ、および VRU レッグ ペリフェラルに関連付けられていたタイプ 2、3、7、または 8 ネットワーク VRU から、単一のタイプ 10 ネットワーク VRU に置き換えられます。VRU 専用モデル（モデル #4a）にはまだタイプ 7 または 8 が必要です。

Note

既存の展開では、以前に推奨された VRU タイプは同じように動作し、新規のインストールにはタイプ 10 を使用する必要があります。既存の展開では、アップグレード時にタイプ 10 に切り替える必要があります。

- スタンドアロン セルフ サービス

- コール ディレクタ

- VRU 専用

スタンドアロン セルフ サービス

スタンドアロン セルフサービスは、通常は Unified ICM VRU スクリプトと通信しないため、ネットワーク VRU 設定は必要ありません。Unified ICM ラベル ルックアップを備えたスタンドアロン セルフサービスは、Unified ICM で VRU スクリプトを使用しません。VRU ペリフェラル ゲートウェイ（PG）のルーティング クライアントにルート要求を発行します。このネットワーク VRU は必要ありません。

- スタンドアロン セルフサービス展開 ASR-TTS

スタンドアロン セルフサービス展開 ASR-TTS

ASR/TTS MRCP サーバに障害が発生すると、次の状態がコール処理に適用されます。

- スタンドアロン展開の進行中のコールは、接続解除されます。ICM 統合展開の進行中のコールは、スクリプティング技術を使用して回復し、エラーを回避できます。たとえば、要求の再試行、エージェントまたはラベルへの転送、残りのコールの事前に記録されたプロンプトおよび DTMF のみの入力への切り替えにより、END スクリプト ノードでエラーが発生し、発信元ゲートウェイの存続可能性が呼び出されます。

Note

Cisco VVB には、ラウンドロビン方式を使用する組み込みのロード バランシング機能があります。現在の ASR/TTS MRCP サーバに障害が発生すると、MRCP リソースに対する次の要求は、サーバ グループ内の次のサーバに転送されます。

通話中に、選択した ASR/TTS MRCP サーバがセットアップ要求に対して失敗で応答すると、VVB は別のサーバでのセットアップを一度試行します。VXML アプリケーションが ASR ダイアログまたは TTS に優先サーバを定義している場合、再試行は行われません。

設定手順については、『CVP Configuration Guide』の「"Configure Speech Server"」を参照してください。

- バックアップ ASR/TTS サーバがゲートウェイに設定されている場合、ICM 統合展開の新しいコールは代替の ASR/TTS サーバに透過的に転送されます。

コール ディレクタ

Unified CCE と Unified CVP は、コール スイッチングのみを担当します。キューイングまたはセルフサービスは提供しないため、VRU レッグはありません。ネットワーク VRU 設定は必要ありません。

VRU 専用

VRU 専用では、コールは ICM-NIC インターフェイスを介して Unified ICM に着信します。最初は、Unified CVP はスイッチ レッグに関与しません。唯一の目的は VRU として機能することです。ただし、使用される NIC の種類によっては、コールを受信した後にスイッチ レッグを引き継ぐ必要がある場合があります。

次のセクションでは、VRU 専用タイプについて説明します。

- NIC 制御ルーティングのみを使用する VRU

- NIC 制御プレルーティングのみを使用する VRU

NIC 制御ルーティングのみを使用する VRU

Note

NIC制御ルーティングを使用する VRU 専用には、以下の前提があります。

- 完全に機能する NIC は、コールを一時的にネットワーク VRU（つまり、Unified CVP の VRU レッグ）に配信し、後でエージェントが使用可能になったときにコールを取得してそのエージェントに配信できます。

- コールを別のエージェント、あるいはキューやセルフサービスに再転送することをエージェントが要求できる場合に、NIC がエージェントからコールを取得して要求されたtoori に再配信surukotogaできます。

このサブモデルには、VRU へのコールの転送に相関 ID 機能が使用されるかトランスレーション ルート 機能が使用されるかに応じて、2 つの種類があります。ほとんどの NIC（ほとんどの PSTN ネットワーク）は、特定の宛先電話番号にコールを転送したり、宛先電話番号と任意の相関 ID を一緒に保持したりできません。宛先デバイスは、相関 ID 転送機能を正しく機能させるために Unified ICM に転送できます。ほとんどの NIC では、トランスレーション ルート機能を使用する必要があります。

ただし、このルールにはいくつかの例外があり、その場合には相関 ID 機能を使用できます。NIC が転送する相関 ID には、Call Routing Service Protocol（CRSP）および Telecom Italia Mobile（TIM）が含まれます。ただし、この機能は NIC の背後で接続される PSTN デバイスにも依存するため、PSTN キャリアを確認し、相関 ID が宛先に渡されるかどうかを判別してください。

NIC が相関 ID を送信できる場合、着信番号はすべて、タイプ 7 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。タイプ 7 ネットワーク VRU には NIC ルーティング クライアントに関連付けられたラベルが含まれている必要があり、すべての VRU スクリプトもその同じタイプ 7 ネットワーク VRU に関連付けられている必要があります。ペリフェラルはネットワーク VRU に関連付けられている必要はありません。最初の RunExternalScript ノードの前に Unified ICM ルーティング スクリプト SendToVRU ノードを実行することをお勧めします。

NIC が相関 ID を送信できない場合、着信番号はすべてネットワーク VRU に関連付けられていないカスタマー インスタンスに関連付ける必要があります。ただし、Unified CVP ペリフェラルはタイプ 8 のネットワーク VRU に関連付けられている必要があり、すべての VRU スクリプトもその同じタイプ 8 ネットワーク VRU に関連付けられている必要があります。この場合は、最初の RunExternalScript ノードの前に、TranslationRouteToVRU ノードをルーティング スクリプトに挿入する必要があります。コールがキューに格納されているために VRU レッグに向かう場合は、通常、TranslationRouteToVRU ノードは Queue ノードの後にあります。このようにして、要求されたエージェントがすでに使用可能である場合は、Unified CVP への不要な転送と削除を回避できます。

NIC 制御プレルーティングのみを使用する VRU

Note

NIC 制御の VRU専用事前ルーティングでは、VRU またはエージェントのいずれかに 1 回のみコールを配信できる能力の低い NIC が想定されています。コールを取得するためにコールが配信され、どこかで再配信されると、Unified CVP はこのコールのスイッチング機能を制御します。Unified ICM は、このプロセスをハンドオフと考えます。

NIC制御プリルーティングで VRU 専用に適合するコールは、変換ルーティングを使用してコールを VRU に転送する必要があります。ハンドオフは相関 ID 機能を使用して実装することができます。

Unified ICM 7.1 以降で NIC 制御事前ルーティングを使用して VRU 専用を実装するには、着信ダイヤル番号をすべて、タイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。VRU ラベルは、NIC ではなく Unified CVP ルーティング クライアントに関連付けられます。Unified CVP ペリフェラルおよび VRU スクリプトは、タイプ 10 ネットワーク VRU に関連付けられる必要があります。ルーティング スクリプトで、最初の RunExternalScript ノードの前に TranslationRouteToVRU ノードを挿入し、次に SendToVRU ノードを挿入する必要があります。コールがキューに格納されているために VRU レッグに向かう場合は、これらの 2 つのノードは Queue ノードの後にあります。要求されたエージェントがすでに使用可能な場合に、Unified CVP からの不要な配信および削除を回避できます。

Note

2 つの異なる VRU 転送ノードが必要です。最初のノードの転送では、ハンドオフによってコールを NIC から転送し、Unified CVP をこのコールのスイッチ レッグ デバイスとして確立します。物理的にはコールはイングレス ゲートウェイに配信されます。2 番めの転送では、コールを音声ブラウザに配信し、Unified CVP をコールの VRU デバイスとしても確立します。

Unified ICM ホスト型の導入

Unified ICM ホスト型実装では、Unified ICM システムの 2 レベルの階層が組み込まれます。Network Applications Manager（NAM）が上位レベルに、1 つ以上の Customer ICM（CICM）がその下に展開されます。NAM と CICM はどちらも完全な ICM であり、それらの間の通信リンクは Intelligent Network Call Routing Protocol（INCRP）と呼ばれます。各 CICM は独立した方法で機能します。 他の CICM は認識されず、NAM は別の ICM であることは認識されていません。CICM には他の CICM への接続はありませんが、NAM への接続は INCRP NIC を介して行われます。

Unified ICM Hosted は、複数の顧客にコンタクト センター サービスを提供するサービス プロバイダー向けです。NAM は、顧客毎に適切な CICM にコールをルーティングします。個々の顧客は、それぞれの自社構内にある PG に接続された独自の自動着信呼分配（ACD）を使用して、独自のコンタクト センターを運営しています。PG は メイン サイトで割り当てられた CICM に接続します。自社は、サービス プロバイダーとして、NAM およびすべての CICM を所有およびホストし、顧客はすべての ACD を所有およびホストします。自社はこれらの ACD の PG を所有していますが、PG は ACD の隣の顧客サイト内にあります。これらの PG は、割り当てられた CICM または NAM に接続します。

ICM スクリプトの場合、すべての着信コールは最初に適切な NAM ルーティング スクリプトを呼び出します。このスクリプトには、適切なターゲット顧客を識別するという主要な責務があります。NAM の後、次のアクションで適切なターゲット顧客を特定します。

- 次に、スクリプトによって、その顧客の CICM 上で実行されるルーティング スクリプトに制御が委任されます。

- CICM ベースのルーティング スクリプトは、適切な ACD を選択してコールを受信します。そのスクリプトは、必要な変換ルート ラベルを NAM に返すことができます。

- NAM は、指定されたターゲット ACD にコールを配信するようにルーティング クライアントに命令します。次のいずれかが発生すると、NAM はサービス コントロール VRU のキューにコールを入れます。

- CICM ルーティングスクリプトは、ACD が現在コールに応答できないと判断します。

- CICM ルーティングスクリプトは、どの ACD がコールを受信する必要があるかをまだ識別できません。

- CICM ルーティング スクリプトは、ルーティング決定が行われるまで、NAM 経由でその VRU にネットワーク VRU スクリプト要求を発行します。

ホスト型を利用する場合、単純に多くのコールまたは PG を ICM セットアップで取得するための方法として、このトポロジを使用するケースがあります。カスタマー コンタクトセンターではなく外部顧客のために CICM を使用するお客様もあります。このような場合、おそらく NAM は CICM と同じ数のコールを処理し、CICM マシンは NAM から離れて展開されます。

Note

NAM および CICM アーキテクチャは、すべてのコンタクト センターが TDM ベースの ACD で実行されることを前提とする従来の設計です。VoIP ルーティングと Unified CCE の直接エージェント ルーティングの追加により、このアーキテクチャはより複雑になりました。

- ホスト型環境での Unified CVP

- ホスト型環境での Unified CVP 展開およびコール ルーティング

- ホスト型環境でのネットワーク VRU タイプ

ホスト型環境での Unified CVP

Unified ICM ホスト型環境の Unified CVP は、サービス プロバイダーの メイン サイトにある NAM 上のセルフサービスまたはキュー プラットフォームです。CVP を使用すると、サービス プロバイダーは以下を実行することができます。

- 適切な顧客所有の ACD へのコール ルーティング。

- ACD キューに入れられたコールの制御の保持。

- 基本的なプロンプト アンド コレクト機能またはフル機能のセルフサービス アプリケーションの顧客への提供。

最後のケースは、通常、VXML サーバ がネットワークに組み込まれます。VXML サーバをホストすることも、顧客がホストすることも可能です。社内あるいは顧客が、セルフサービス アプリケーションを作成および所有することができます。顧客が VXML サーバを所有またはホスト可能であることは、セルフサービス アプリケーションでバックエンド サービスを参照する必要がある場合に便利なソリューションです。このソリューションにより、顧客は自社の企業ネットワーク内で通話の制御を保持することができます。顧客は VXML over HTTP のみを VXML ゲートウェイに送信します。

多くの ICM ホスト型環境では、サービス プロバイダーが PSTN キャリアである場合、実際のコール ルーティングはすべて ICM NIC 経由で行われます。PG が（通常）ICM NIC を使用してコールをルーティングする場合、同じ状況が適用されます。ただし、サービス プロバイダーには NIC インターフェイスが存在しない場合があります。その場合、すべてのコールが T3 や E3 などの TDM インターフェイス経由で配信されます。この場合、CVP がスイッチと VRU レッグを処理します。

ホスト型環境での Unified CVP 展開およびコール ルーティング

Unified ICM ホスト型環境では、CVP は有効なネットワーク VRU の NAM で接続します。NAM レベルの代わりに、または NAM レベルに加えて、CICM レベルで CVP が必要になる場合がある展開も可能です。Unified CVP コンポーネントの配置場所に関しては、以下のガイドラインを考慮します。

- NAM の CVP がスイッチと VRU レッグの両方を処理する場合、相関 ID 転送機能を使用します。NAM または CICM ルーティング スクリプトのいずれかが SendToVRU ノードを実行することができます。(SendToVRU を実行する同じスクリプトに RunExternalScript ノードを配置します。)

- NAM の CVP が VRU レッグを処理し、NIC がスイッチ レッグを処理する場合、相関 ID または変換ルート転送機能を使用することができます。これは、NIC の機能に依存します。以下のガイドラインも適用されます。

- 相関 ID 転送を使用する場合、SendToVRU ノードを NAM または CICM ルーティング スクリプトに配置します。(SendToVRU を実行する同じスクリプトに RunExternalScript ノードを配置します。)

- Translation Route 転送を使用する場合は、TranslationRouteToVRU ノードとすべての RunExternalScript ノードを NAM ルーティング スクリプトに配置します。コールは、特定の CICM を選択する前にキューに入れられます（またはプロンプトアンドコレクトで処理されます）。この設定では、キューイングは容易ではありません。ただし、この構成により、サービス プロバイダーは CICM に制御を委任する前に初期プロンプトおよび収集を提供することができます。

- CICM の CVP が VRU レッグを処理し、NIC がスイッチ レッグを処理する場合、変換ルート転送方法のみが使用できます。TranslationRouteToVRU ノードとすべての RunExternalScript ノードを CICM ルーティング スクリプトに配置します。

Unified CM または ACD によって開始されたコールを追加すると、別の制約が作成されます。これらのデバイスはどちらも ICM の観点からは ACD と見なされ、CICM レベルで接続します。転送ではなく新しいコールの場合、ルート要求は ACD から送信され、結果のラベルが ACD に返されます。Unified CM または ACD は、転送時に相関 ID を送信することはできません。使用できるのはトランスレーション ルート転送方式のみです。この制限は、転送先が NAM レベルではなく CICM レベルで接続することを意味します。

転送の場合、顧客はブラインド ネットワーク転送またはウォーム コンサルタティブ転送のいずれかを必要とする場合があります。これらの転送には、次のガイドラインが適用されます。

- ブラインド ネットワーク転送: 元のコールが NIC または CVP スイッチ レッグを介して NAM に着信した場合、CICM は NAM の転送ラベルを元のスイッチ レッグ デバイスに渡します。ブラインド転送ネットワークに 2 つの状況があります。

- スイッチ レッグ デバイスが CVP または相関 ID の処理可能な NIC である場合、相関 ID 転送機能を使用します。SendToVRU ノードとすべての RunExternalScript ノードを CICM ルーティング スクリプトに配置します。CVP VRU レッグを NAM に接続します。ブラインド転送と相関 ID 転送の組み合わせは CVP に適しています。

- スイッチ レッグ デバイスが相関 ID を処理できない NIC である場合、変換ルート転送方式を使用します。CVP VRU レッグ デバイスを CICM に接続します。

Note

この状況では、NAM レベルの CVP コール サーバを使用できないため、CICM レベルで追加の専用 CVP コールサーバが必要となります。

- ウォーム コンサルタティブ転送: CVPは、コールを他の Unified CCE エージェントに転送する Unified CCE エージェントに対してのみ、ウォーム コンサルタティブ転送をサポートします。このようなコールの場合、CVP は着信コールの最初のスイッチ レッグを保持します。Unified CM は相関 ID 転送を処理できないため、変換ルート転送方法を使用します。CVP VRU レッグ デバイスを CICM に接続します。

TDM エージェントの場合、CVP の代わりに ACD 機能を使用します。Unified CCE エージェントへの着信コールが NIC を介して到着する場合、CVP ではなく、Unified ICM ネットワーク コンサルタティブ転送機能を使用します。

Note

この状況では、NAM レベルの CVP コール サーバを使用できないため、CICM レベルで追加の専用 CVP コールサーバが必要となります。

ホスト型環境でのネットワーク VRU タイプ

ICM ホスト型環境には、NAM と CICM の 2 種類の ICM システムがあります。NAM と CICM でネットワーク VRU タイプを別々に構成します。

NAM は着信コールを NIC または Unified CVP から取得し、Unified CVP VRU レッグ デバイスを認識します。NAM ネットワーク VRU タイプを独立した ICM として正確に設定して、それらのデバイスを使用して操作します。ネットワーク VRU タイプを設定するときに、一部の転送ラベルが CICM から着信することを無視できます。CICM は、インテリジェント ネットワーク コール ルーティング プロトコル（INCRP）NIC から到着する着信コールを確認します。

NAM から到着したダイヤル番号を、CICM 上の対応するネットワーク VRU のカスタマー インスタンスに関連付けます。そのネットワーク VRU をすべての VRU スクリプトに関連付けます。NAM ネットワーク VRU 定義で必要な同じラベルを提供しますが、ルーティング クライアントとして INCRP NIC を使用します。ネットワーク VRU が設定されたペリフェラルはありません。

ネットワーク VRU タイプの詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.htmlの Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

Unified CM、ACD コールの展開、サイジングの影響

この章での情報は、キューイング用 Cisco IP IVR の代わりにUnified CVPを使用する ACDおよび Cisco Unified Communications Manager (Unified CM) の統合にも適応されます。Unified CVP を考慮する場合、これらのデバイスは以下の特性を共有します。

- エージェントを管理し、転送の宛先になることができます。

- ルート要求を発行でき、スイッチ レッグ デバイスになります。

- スイッチ レッグ デバイスになることができますが、複数の転送を処理できず、相関 ID を処理できない場合があります。

- エージェントを管理し、コールを宛先に転送します。

- ルート要求を発行でき、スイッチ レッグ デバイスになります。ただし、デバイスは相関 ID とは複数の転送を処理できません。

Unified CM または ACD ユーザは、以下の理由でルート要求を発行します。

- 特定のスキル グループの別のエージェントへの接続

- セルフサービス アプリケーションへのリーチ

- 以前に受信したコールの前述のエンティティのいずれかへのブラインド転送

また、Unified CM ユーザは、次の理由のいずれかでルート要求を発行します。

- Unified ICM アウトバウンド ダイヤラからの正常な発信コールの Unified CVP に基づくセルフサービス アプリケーションへの配信

- ユーザが前に受信したコールの特定のスキル グループまたはセルフサービス アプリケーションへのウォーム転送

前述の各コールによって、Unified ICM ルーティング スクリプトが起動されます。スクリプトは、使用可能な宛先エージェントまたはサービスを検索し、適切な宛先がある場合は、対応するラベルを ACD に返信します。または、既存のコールをブラインド転送する場合は、元の発信者のスイッチ レッグ デバイスに返信します。コールをキューに格納する必要がある場合、または最終の宛先がエージェントまたはサービスではなくセルフサービス アプリケーションである場合、スクリプトは VRU トランスレーション ルート ラベルを ACD に返信するか、または既存のコールをブラインド転送で転送する場合は元の発信者のスイッチ レッグ デバイスに送信します。

前述のシーケンスでコールが Unified CVP の VRU レッグ デバイスに転送された場合、コールを音声ブラウザに配信するために別の転送が行われます。これらのイベントが発生するには、以下の Unified ICM コンフィギュレーション要素が必要です。

- ACD からの新規コールまたは既存のコールのウォーム転送の場合：

- タイプ 10 ネットワーク VRU と関連付ける Unified CVP ペリフェラルを設定します。

- ACD がダイヤルする着信番号とタイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスを関連付けます。

- ACD が Unified CM 以外の場合、ACD 着信番号によって起動されたルーティング スクリプトに、コールを Unified CVP のスイッチ レッグに送るための TranslationRouteToVRU ノードと、それに続いて、コールを音声ブラウザおよび Unified CVP の VRU レッグに送るための SendToVRU ノードが含まれている必要があります。

- Unified CM によって起動されるルーティング スクリプトは、相関 ID を使用してコールを Unified CVP に送信するための SendToVRU ノードを使用する必要があります。タイプ 10 VRU は、音声ブラウザの VRU レッグへの 2 番目の転送を自動的に実行します。

- このルーティング スクリプトで実行されるすべての VRU スクリプトとタイプ 10 ネットワーク VRU 関連付けます。

- 既存のコールのブラインド転送の場合：

- Unified CVP ペリフェラルはネットワーク VRU と関連付けることができます。

- ACD がダイヤルする着信番号は、タイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスを関連付ける必要があります。

- ACD 着信番号によって起動されるルーティング スクリプトに、コールを音声ブラウザおよび Unified CVP の VRU レッグに送信するための SendToVRU ノードが含まれている必要があります。

- このコールによって実行されるすべての VRU スクリプトは、タイプ 10 ネットワーク VRU と関連付けられる必要があります。

Unified ICM は、コールのエージェントまたは ACD 宛先ラベルを選択するときに、そのラベルを受け入れることができるルーティング クライアントをリストしているものを見つけようとします。ACD または Unified CM から発生し、既存のコールのブラインド転送ではないコールの場合、ルーティング クライアントは ACD または Unified CMのみです。コールが Unified CVP に転送されると、ハンドオフ処理により、ルーティング クライアントは Unified CVP スイッチ レッグのみになります。ただし、既存のブラインド転送の場合、ルーティング クライアントを 2 つ設定することができます。

- 元のコールを送信したコール サーバ スイッチ レグ。

- ACD または Unified CM。Unified CVPを介して発信されるコールの場合、Unified CVP周辺機器の Unified ICM セットアップ 画面の ネットワーク転送を優先する チェック ボックスをオンにすることで、ACD または Unified CM ラベルよりも Unified CVP ラベルに優先順位を付けることができます。

CTI Agent Desktop に加えて、システムは転送をインターセプトするために設定されたルーティング ダイヤル番号を認識し、JTAPI を介して Unified CM に転送コマンドを送信せずに Unified CCE ルーティング スクリプトを実行します。

サードパーティ VRU

サードパーティ製の TDM VRU は、次の方法のいずれかで使用できます。

- 初期ルーティング クライアントとして（GED-125 コール ルーティング インターフェイスを使用）

- VRU として（GED-125 コール ルーティング インターフェイスを使用）

- サービス制御 VRU として（GED-125 サービス制御インターフェイスを使用）

最初と 2 番目の操作では、VRU は ACD として機能します。ACD と同じように、VRU は別の送信元から着信するコールの宛先になることができます。コール コンテキスト情報を保持するために、コールをそのようなデバイスにトランスレーション ルーティングすることもできます（この動作は、TranslationRouteToVRU ではなく、従来のトランスレーション ルートと呼ばれます）。また、ACD のように、VRU は独自のルート要求を発行し、ルーティング スクリプトを起動してコールを後続の宛先やセルフサービス処理用の Unified CVP にも転送できます。このような転送では、ほとんど常にトランスレーション ルート転送機能が使用されます。

3 回目の動作で、VRU は、Unified CVP の スイッチ レッグまたは Unified CVP の VRU レッグのいずれかを置き換えるか、または Unified CVP 置き換えることもできます。

解放トランク転送

解放トランク転送は入力トランクを解放し、コール制御ループから Unified CVP とゲートウェイを削除します。これらの転送の特徴は以下の通りです。

- VXML Server（スタンドアロン コール フロー モデル）または Unified ICM を使用して起動できます。

- Unified ICM ネットワーク転送で Unified CVP をルーティング クライアントとして使用した場合、Unified CVP で呼制御を実行できなくなり、転送は機能しません。

- これらはブラインドです。何らかの理由で転送に失敗した場合、Unified ICM は呼制御を回復しません。ルータ再クエリーはサポートされていません。

- これらによりスイッチ レッグは終了するため、発信者がエージェントとまだ通話中だとしても、Telephony Call Dispatcher（TCD）レコードがコールのデータベースに書き込まれます。この動作は他のタイプの転送とは異なります。他のタイプの転送では、発信者が電話を切るまで、TCD レコードはファイナライズされません。

- 入力トランクは解放されるため、解放トランク転送を使用して転送されたコールを対象に含めるようにゲートウェイのサイズを調整する必要はありません。この動作は他のタイプの転送とは異なります。他のタイプの転送では、発信者が電話を切るまで、ゲートウェイ リソースは占有され続けます。

- Unified CVP はコールをモニタしなくなるため、解放トランク転送を使用して転送されたコールを対象に含めるようにコール サーバのサイズを調整する必要はありません。また、Unified CVP コール ディレクタ ポート ライセンスは不要です。

以下のシグナリング方式を使用して、解放トランク転送をトリガすることができます。

- Take Back and Transfer

- フックフラッシュとウィンク

- Two B Channel Transfer

- 取り消しと転送

- Two B Channel Transfer

取り消しと転送

転送接続としても知られている取り消しと転送（TNT）は、デュアルトーン多重周波数（DTMF）トーンが Unified CVP によって PSTN にアウトパルスされる場合の転送方式です。TNT は DTMF トーンを PSTN にアウトパルスします。一般的な DTMF シーケンスは *8xxxx です。xxxx は PSTN の新しいルーティング ラベルを表します。TNT DTMF シーケンスを検出すると、PSTN はイングレス ゲートウェイ ポートへのコール レッグをドロップし、TDM ACD ロケーションなどの新しい PSTN ロケーションに発信者を再ルーティングします。この方式を提供できるのは、わずかな PSTN サービス プロバイダーです。

IVR のない既存の ACD サイトで IVR として Unified CVP を使用する場合、TNT を使用できます。その後必要であれば、TDM ACD から Unified CCE にエージェントを移行し、IVR、キューイング ポイント、および転送ピボット ポイントとして Unified CVP を使用する場合があります。単なる IVR として以上に Unified CVP を使用すると、TNT サービスの必要性がなくなります。

Unified CVP 展開で Unified ICM を使用した場合、TDM ACD などの別の Unified ICM ペリフェラルへのコール データの引き渡しを可能にするために、アウトパルスされた DTMF ルーティング ラベルが Unified ICM トランスレーション ルーティング ラベルになる場合があります。このシナリオでは、Unified CVP はコールを完了と見なし、Unified CVP コール制御は終了します。TNT の場合、ターミネーション ポイントまでの転送に失敗すると、Unified CVP はコールの再ルーティング処理をも行うことができません。一部の TNT サービスを使用して、Unified CVP にコールバックを再ルーティングできます。ただし、Unified CVP はこのコールを新しいコールとして処理します。

Two B Channel Transfer

Two B Channel Transfer（TBCT）は統合サービス デジタル網（ISDN）ベースの解放トランク機能で、一部の公衆電話交換網（PSTN）サービス プロバイダーによって提供されます。TBCT が呼び出されると、イングレス ゲートウェイは、別のコール レッグ（ISDN B チャネル）を使用してターミネーション ポイントに対するコールを行っている間、一時的に最初の着信コールを保留にします。ターミネーション ポイントがコールに応答すると、ゲートウェイは PSTN スイッチに ISDN シグナルを送信し、転送の完了、PSTN スイッチを介したコールのブリッジ、およびイングレス ゲートウェイからのコールの削除を要求します。TNT 転送では、ターミネーション ポイントは、PSTN に接続されている TDM PBX または ACD です。

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、このプロセスが必要になることがあります。その後必要であれば、エージェントを TDM ACD から Cisco Unified CCE に移行し、Unified CVP を IVR、キューイング ポイント、および転送ピボット ポイントとして使用できます（これにより、TBCT サービスが不要になり、転送失敗時に Unified CVP を使用して再ルーティングを実行できるようになります）。

VXML 転送

VXML コール制御は、VXML サーバによってコール制御が提供されるスタンドアロン展開でのみサポートされます。Unified ICM が組み込まれた展開では、ICM がすべてのコールを制御します。

VXML サーバは以下のタイプの転送を呼び出すことができます。

VXML 転送のタイプ

解放トランク転送

VXML ブラインド転送

VXML ブリッジ転送

着信コールが入力音声ゲートウェイから送信されます。

コールが出力音声ゲートウェイまたは VoIP エンドポイントにブリッジされます。ただし、VXML Server は後続のすべてのコール制御を解放します。

コールが出力音声ゲートウェイまたは VoIP エンドポイントにブリッジされます。ただし、VXML Server は、IVR アプリケーションに発信者を返したり、別のターミネーション ポイントに発信者を転送したりできるようにコール制御を維持します。

subdialog_return 要素を使用して呼び出されます。

VXML Server では、TNT 転送、Two B Channel Transfer、フックフラッシュ/ウィンク転送、および SIP Refer 転送を呼び出すことができます。TDM 解放トランク転送（TNT、TBCT、およびフックフラッシュ/ウィンク）の場合、VXML ゲートウェイとイングレス ゲートウェイを組み合わせて、解放トランク転送が機能するようにする必要があります。

Cisco Unified Call Studio の転送要素を使用して呼び出されます。これらの転送では、ゲートウェイに設定されているダイヤル ピアにコールが転送されます。

ブリッジド転送では、スクリプトを終了しません。VXML Server は、入力コールまたは宛先コールが終了するまで待機します。スクリプトが終了するのは、入力コール レッグが切断された場合のみです。宛先コール レッグが最初に切断されると、スクリプトは制御を回復し、追加のセルフサービス アクティビティを続行します。スクリプトが実際に処理を実行していない場合でも、ブリッジド転送の期間中は、VXML Server ポート ライセンスは引き続き使用された状態のままになることに注意してください。

VXML ブラインド転送は、以下の点で VXML ブリッジ転送と異なります。

- VXML ブラインド転送ではコール進捗の監視はサポートされていません。ブリッジド転送ではサポートされています。つまり、ブラインド転送に失敗した場合、VXML サーバ スクリプトは制御を回復せず、別の宛先を試すことも、是正措置を取ることもできません。

- VXML ブラインド転送を使用した場合、VXML サーバ スクリプトが終了します。常にブラインド転送ノードの "done exit" 分岐を subdialog_return ノードと hang-up ノードに接続してください。

Note

Cisco VVB は VXML の転送でのみブラインド転送をサポートします。

非リファレンス コール フロー

Unified CVP では、さまざまなニーズに応える複数コール フローが提供されます。コンタクト センターの適切な展開は、ニーズに最適なコール フロー、地理的分布、およびサーバ構成によって異なります。包括的コール フローは、リファレンス設計で使用可能な唯一のフローです。非リファレンス設計では、以下のその他のコール フローを使用することができます。

- Unified CVP VXML サーバ（スタンドアロン）：キューイング制御または後続の呼制御用の Unified CCE と統合されていない、スタンドアロンの VRU を提供します。セルフサービス VXML アプリケーションを展開するために使用します。

- コール ディレクタ：IP スイッチ サービスのみを提供します。以下のコール フローを使用することもできます。

- Unified CVP のみを使用して、Unified CCE に VoIP コール スイッチングを提供します。

- サードパーティ製の VRU および ACD を使用してデータのプロンプトとコレクトを行います。

- Unified CVP VXML サーバの使用は避けます。

- VRU のみ：PSTN エンドポイントに VRU サービス、キューイング処理、およびスイッチングを提供します。このモデルでは、PSTN を使用して、コール ターミネーション エンドポイント間でコールを転送します。以下のコール フローを使用することもできます。

- Unified CCE を使用して、VRU サービス（統合されたセルフサービス アプリケーション、最初のプロンプトとコレクトなど）を含む Unified ICM を提供します。

- コール スイッチには Unified CVP の使用は避けます。

- オプションの Unified CVP VXML Server を使用する。

- オプションの ASR および TTS サービスを使用してデータのプロンプトまたはコレクトを行う。

- スタンドアロン セルフ サービス

- コール ディレクタ

- VXML サーバ（スタンドアロン）

- コール ディレクタ

- VRU 専用

スタンドアロン セルフ サービス

スタンドアロン セルフサービスには、Unified ICM は含まれません。このモデルは、Unified CM ユーザが VXML ゲートウェイに接続する電話番号をダイヤルし、Unified CVP VXML サーバ アプリケーションを起動する際に実装されます。VXML ゲートウェイは、Unified CM で SIP トランクとして設定されます。コール フローは以下の通りです。

1. 発信者がルート パターンをダイヤルします。

2. Unified CM がコールを VXML ゲートウェイに送信します。

3. VXML ゲートウェイは、設定済みの Unified CVP セルフサービス アプリケーションに基づいて音声ブラウザ セッションを起動します。

4. Unified CVP セルフサービス アプリケーションが、Unified CVP VXML Server に対して HTTP 要求を行います。

5. Unified CVP VXML Server は、セルフサービス アプリケーションを開始します。

6. Unified CVP VXML サーバと VXML ゲートウェイは、HTTP 要求と VXML 応答を交換します。

7. 発信者が切断します。

コール ディレクタ

Call Director にはスイッチングのみで、VRU レッグはありません。Unified CM により発生したコールは、常にターゲットに直接配信されるか、拒否されます。キューイングまたはセルフサービスは関係しません。

Call Director は、コールが実際に Unified CM から発信されていると想定します。元々イングレス VXMLゲートウェイを介して到着し、Unified CMに転送されたコールは除外され、再び転送されます。通常は Unified CM 自体がこれらの転送を処理できるため、このような状況はまれです。ただし、ターゲットが Unified CM 以外の ACD である場合などは例外です。

Call Director では、以下の項目が構成されている必要があります。

- Unified CCE スクリプトを起動する Unified CM ルート ポイント

- タイプ 10 ネットワーク VRU として設定された Unified CVP。

- Unified CVP への VRU トランスレーション ルート

- Unified CVP コール サーバで設定されたトランスレーション ルート着信番号識別サービス（DNIS）番号

- SIP トランクで設定された Unified CM。

- トランスレーション ルート DNIS の Unified CM ルート パターン

コール フローは以下の通りです。

1. 発信者がルート ポイントをダイヤルします。

2. Unified ICM がルーティング スクリプトを起動します。

3. ルーティング スクリプトは、TranslationRouteToVRU ノードを検出し、コールを Unified CVP に転送します（Unified CVP はタイプ 10 ネットワーク VRU として設定されています）。

4. Unified ICM は、トランスレーション ルート ラベルを Unified CM に返します。

5. Unified CM は、SIP プロキシに問い合わせて、Unified CVP コール サーバを見つけます。

6. Unified CM は、コールを Unified CVP コール サーバに接続します。

7. ルーティング スクリプトは Select または Label ノードを検出し、ターゲット ラベルを選択します。

8. Unified ICM は、ターゲット ラベルを（ルート要求を発行したデバイスではなく）Unified CVP コール サーバに返します。

9. Unified CVP コール サーバは、SIP プロキシに問い合わせて、宛先デバイスを見つけます。

10. Unified CVP コール サーバは、SIP を介してターゲット デバイスと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

ターゲット デバイスが別のルート要求を Unified ICM に発行する場合。コール フローのこの部分は、ステップ 3 で説明した通り、最初の TranslationRouteToVRU が存在しない場合は実行できません。

11. Unified ICM が新しいルーティング スクリプトを起動します。

12. ルーティング スクリプトは Select または Label ノードを検出し、ターゲット ラベルを選択します。

13. Unified ICM は、ターゲット ラベルを（ルート要求を発行したデバイスではなく）Unified CVP コール サーバに返します。

14. Unified CVP コール サーバは、SIP プロキシに問い合わせて、宛先デバイスを見つけます。

15. Unified CVP コール サーバは、SIP を使用してターゲット デバイスと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

VXML サーバ（スタンドアロン）

VXML サーバ（スタンドアロン）機能展開では、自動セルフサービスにスタンドアロン IVR ソリューションを提供します。発信者は、Unified CVP イングレス音声ゲートウェイを終端として、市内局番、市外局番、またはフリーダイヤル番号のいずれかから Unified CVP にアクセスできます。また、発信者は、Unified CVP イングレス音声ゲートウェイを終端として、VoIP エンドポイントから Unified CVP にもアクセスできます。また、発信者は、VoIP エンドポイントから Unified CVP にアクセスすることもできます。以下の図は、この展開を説明しています。

VXML Server（スタンドアロン）機能展開モデル

この展開では、以下のコンポーネントが服されます。

- イングレス音声ゲートウェイ

- 仮想化音声ブラウザ / VXML ゲートウェイ

- VXML サーバ

- Unified Call Studio

- オペレーションコンソールサーバ

以下はこの展開でのオプションのコンポーネントです。

- 自動音声認識/音声合成（ASR/TTS）サーバ

- サードパーティ製のメディア サーバ

- 出力音声ゲートウェイ

- Reporting Server

- CVP コール サーバ

- ICMicm

- Cisco Unified Communications Manager

- Protocol-Level コール フロー

- 転送とそれに続くコール制御

Protocol-Level コール フロー

1. コールは、TDM または SIP からイングレス VXML ゲートウェイに到達します。ゲートウェイが、着信の単純な旧式の電話サービス（POTS）または VoIP ダイヤル ピアを照合します。

Note

入力音声ゲートウェイまたは VXML ゲートウェイの展開は、個別のエンティティまたは共存（IOS VXML ゲートウェイを使用）のいずれかです。セルフサービス アプリケーションは VXML ゲートウェイで呼び出されます。

2. 選択された VXML ゲートウェイ ポートは、Unified CVP セルフサービス スクリプトを呼び出します。

3. セルフサービス スクリプトは、Unified CVP スタンドアロン ブートストラップ VXML ドキュメントを呼び出します。この VoiceXML ドキュメントは、VXML サーバの設定済み IP アドレスに HTTP 要求を送信します。

4. CVP サーバ 内にある VXML サービス機能は、HTTP URL で指定されたアプリケーションを実行し、動的に生成された VXML ドキュメントを VXML ゲートウェイに返します。Unified CVP VXML サービスは、バックエンド システムにアクセスして、VXML ゲートウェイに送信される VXML ドキュメントにパーソナライズ データを組み込むことができます。

5. VXML ゲートウェイは、VXML ドキュメントを解析およびレンダリングします。音声出力の場合、VXML ゲートウェイは、VXML ドキュメントで参照されている録音済みの音声ファイルを取得して再生するか、または音声合成（TTS）サーバからのメディアのストリーミングを行います。DTMF は VXML ゲートウェイで検出されます。

6. VXML ゲートウェイは、発信者の入力結果を含む HTTP 要求を VXML サーバに送信します。このサーバは HTTP URL で指定されたアプリケーションを再び実行し、ダイナミックに生成された VXML ドキュメントを VXML ゲートウェイに返します。ダイアログが続行され、ステップ 5 と 6 が繰り返されます。

7. VRU ダイアログは、発信者が電話を切るか、アプリケーションが解放するか、またはアプリケーションが転送を開始したときに終了します。

転送とそれに続くコール制御

VXML サーバ（スタンドアロン）の機能展開を使用すると、別のエンドポイントに発信者を転送できます。VoIP（Cisco Unified Communications Manager など）または TDM（出力音声ゲートウェイから PSTN や TDM ACD へなど）のいずれかに転送します。IVR アプリケーション データは、この展開での新しいエンドポイントに渡すことができません。エンドポイントが TDM ACD の場合、エージェントの画面ポップアップ ウィンドウは表示されません。

この展開では、以下のコール転送がサポートされています。

- VXML ブリッジ転送

- VXML ブラインド転送

- 解放トランク転送（TNT、フックフラッシュ、TBCT、および SIP Refer）

Note

Cisco VVB はブラインド転送機能のみをサポートします。

コール ディレクタ

コール ディレクタの展開では、組織に VoIP ネットワーク上でのコールのルーティング方法および転送方法を提供します。たとえば、企業が ACD または IVR ペリフェラル ゲートウェイ経由で Unified ICM に統合された複数の TDM ACD と TDM IVR ロケーションでこの展開を使用することができます。組織は、Cisco Unified Intelligent Contact Management（Unified ICM）を使用して、PSTN プレルーティングまたは解放トランク転送サービスを使用することなく、これらのロケーション間でコールをインテリジェントにルーティングおよび転送することを望んでいます。この展開では、Unified CVP および Unified ICM はこれらの ACD および IVR ロケーション間でコール データを渡すこともできます。また、Unified ICM はすべてのコールに関して全コール期間のレポートを生成することができます。

多くの場合、コール ディレクタは、TDM ベースのコンタクトセンターから VoIP ベースのコンタクトセンターに移行する場合の最初のステップになります。組織で CVP ベースの IVR サービスと Cisco Unified Contact Center Enterprise（Unified CCE）を実装する場合、組織は現在の Unified CVP 展開を包括機能展開に移行することができます。

発信者は、Unified CVP イングレス音声ゲートウェイを終端として、市内局番、市外局番、またはフリーダイヤル番号のいずれかから Unified CVP にアクセスできます。また、発信者は、VoIP エンドポイントから Unified CVP にアクセスすることもできます。

以下はこの Call Director 展開での必須コンポーネントです。

- イングレス音声ゲートウェイ

- 出力音声ゲートウェイ

- CVP サーバ

- オペレーションコンソールサーバ

- Cisco Unified ICM Enterprise

- SIP プロキシ サーバ（SIP 展開の場合）

Unified CVP レポート データベースに格納されているコール情報ほとんどないため、レポート サーバはこのモデルのオプション コンポーネントです。

- SIP レベル コール フロー

- 転送とそれに続くコール制御

SIP レベル コール フロー

VoIP ベースのプレルーティング

1. コールはイングレス音声ゲートウェイに到達し、SIP INVITE/SIP/SIP メッセージを SIP プロキシ サーバに送信します。SIP プロキシ サーバは、要求を CVP Server SIP サービスに転送します。

2. SIP サービスは、CVP Server ICM サービスおよび VRU 周辺機器ゲートウェイを使用してルート要求を Unified ICM に送信します。このルート要求は Unified ICM を起動し、着信番号および他の基準に基づいてルーティング スクリプトを実行します。

3. Unified ICM ルーティング スクリプトは、ターゲットを選択して、CVP Server SIP サービスにトランスレーション ルート ラベルを返します。サーバの SIP サービスは、SIP プロキシ サーバを介して出力音声ゲートウェイ（TDM ターミネーション ポイントに接続します）とイングレス音声ゲートウェイに信号を送信し、コールを入力と出力音声ゲートウェイ間で設定できるようにします。RTP ストリーム フローはイングレス音声ゲートウェイと出力音声ゲートウェイ間を直接流れますが、コール制御のシグナリング フローは Unified CVP を経由します。これにより、それ以降のコール制御が可能になります。

4. 選択されたターミネーションにコールが到達すると、終端装置は要求をその周辺機器ゲートウェイに送信して、ルーティング命令を出します。このステップにより、トランスレーション ルートが解決され、以前の Unified ICM スクリプトからのコール データを選択されたターミネーションに渡せるようになります。選択されたターミネーションが TDM IVR プラットフォームである場合は、セルフサービスが提供され、発信者は解放するか、またはライブ エージェントに転送するように要求できます。選択されたターミネーションが TDM ACD プラットフォームである場合は、使用可能なエージェントが TDM ACD によって選択されるまで、発信者がキューイングされます。その後、コール データをエージェントの画面に表示できます。ライブ アシスタンスを受け取った後、発信者は解放するか、または別のエージェントに転送するように要求できます。

VoIP ベースの転送

1. コールが最初に TDM IVR と ACD のどちらのロケーションにルーティングされたかにかかわらず、発信者は別のロケーションにコールを転送するように要求できます。転送する場合、TDM IVR または ACD はコール データとともにポストルート要求を（その周辺機器ゲートウェイによって）Unified ICM に送信します。

2. このポストルート要求を受信した Unified ICM は、転送着信番号および他の基準に基づいてルーティング スクリプトを実行します。Unified ICM ルーティング スクリプトは、コールの新しいターゲットを選択し、CVP Server SIP サービスにシグナリングすることによって、最初に選択されていたターミネーションへのコール レッグを解放したり、コールを新しいターミネーションに拡張したりします。

3. 新しいターミネーションにコールが到達すると、終端装置は要求をその PG に送信して、ルーティング命令を出します。このステップにより、このコールに配分されるトランスレーション ルートがこの新しいターミネーション ロケーションに解決され、以前のロケーション（IVR ポートまたはエージェント）からのコール データを新しいターミネーションに渡せるようになります。同じ VoIP ベースの転送コール フローを使用して、ロケーション間でコールを引き続き転送できます。

転送とそれに続くコール制御

Unified ICM で管理される転送に加え、コール ディレクタ展開では、ICM 以外のターミネーションにコールを転送したり、PSTN で解放トランク転送を呼び出したりすることもできます。コールが ICM 以外のターミネーションに転送された場合、コール データをターミネーションに渡すことができなくなります。また、そのコールに対するそれ以降のコール制御が不可能になり、Unified ICM が取得する全コール期間のコール レポート生成が完了します。解放トランク転送の場合、イングレス音声ゲートウェイ ポートが解放され、コール データをターミネーションに渡すことができなくなります。また、そのコールに対するそれ以降のコール制御が不可能になります。解放トランク転送が別の ICM ペリフェラルにトランスレーション ルーティングされる場合は、コール データと全コール期間のレポート生成を維持できます。

コール サーバは転送要求をキャンセルし、転送失敗インジケータを Unified ICM に送信します。理由は以下の通りです。

- 選択されたターミネーション（新しいコール用または転送コール用）から接続失敗またはビジー ステータスが返されます。

- 宛先の電話が、コール サーバの Ring-No-Answer（RNA）タイムアウト設定を超えるまで鳴ります。

これらのシナリオでは、ルータ再クエリー操作が実行されます。次に Unified ICM ルーティング スクリプトは制御を回復し、別のターゲットを選択するか、または是正措置を取ることができます。

VRU 専用

VRU 専用では、Cisco Unified ICM PSTN ネットワーク インターフェイス コントローラ（NIC）を使用して制御される高度な PSTN スイッチング サービスを利用している組織に、セルフサービス アプリケーションとキュー処理を提供します。NIC と Carrier Routing Service Protocol（CRSP）NIC の 2 つの Unified ICM PSTN NIC により、PSTN でコールの後続のコール制御が可能になります。これらの NIC を使用すると、Unified ICM で ACD や IVR などの Unified ICM ペリフェラルにコールをインテリジェントにルーティングできます。また、Unified ICM が PSTN で通話転送を呼び出すこともできます。次の図は、このモデルを示しています。

VRU 専用機能展開

VRU 専用機能展開：

- Unified ICM は、コールの処理とキューイングのためにイングレス音声ゲートウェイに別のコールをルーティングする前にコールをルーティングします。エージェントが使用可能になると、Unified ICM はそのエージェントにコールを転送するように PSTN に命令します。エージェントは、Cisco Unified Contact Center Enterprise エージェント、Cisco Unified Contact Center Express エージェント、または ACD エージェントです。必要に応じて、Unified ICM は（NIC を使用して）コールを転送するように PSTN に要求します。これは、Unified ICM がコールを転送するように Unified CVP に要求する場合と同様です。

- イングレス音声ゲートウェイは Unified ICM で管理する PSTN ターミネーション ポイントで、VXML ゲートウェイ、VXM サーバ、ICM サービス、および Unified ICM を使用して VRU サービスを提供します。

- SIP サービスはコール制御に使用されません。すべてのコール制御およびスイッチングが Unified ICM と PSTN によって制御されます。

- Unified ICM はこれらのターミネーション ポイント間でコール データを渡したり（ポップ ウィンドウまたは他のインテリジェント処理用）、すべてのコールに関してレポートを生成したりできます。

以下はこの展開での必須コンポーネントです。

- イングレス音声ゲートウェイ

- VXML ゲートウェイ

- CVP サーバ

- Unified Call Studio

- Cisco Unified ICM Enterprise および NIC（CRSP）

以下はこの展開でのオプションのコンポーネントです。

- ASR/TTS サーバ

- サードパーティ製のメディア サーバ

- SIP プロキシ サーバ（SIP 展開の場合）

- Reporting サーバ

Unified CM の非リファレンス設計の導入

単一の Unified CM は SIP からコールを発信したり受信したりできます。Unified CM に登録されている MGCP 音声ゲートウェイに到達した PSTN コールは、SIP を介した（Cisco Unified Border Element を通過しない）Unified CVP にだけルーティングまたは転送できます。

Note

SCCP ベースの回線側プロトコルは、新型の電話機ではサポートされていません。SCCP ベースの回線側プロトコルは、以前のリリースの旧型の電話機でサポートされています。ただし、廃止された電話機の新規インストールまたは有効化はサポートされていません。

Cisco Unified Call Manager (CUCM) リリースでサポートされる電話機の詳細については、以下の URL で関連リリースの 廃止済電話機のモデル のCUCM互換性情報のセクションを参照してください。https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-device-support-tables-list.html。

Unified CM は、Unified CVP ソリューションにおける任意のコンポーネントです。ソリューションでの Unified CM の使用方法は、展開されるコール センターのタイプによって異なります。たとえば、ACD を使用する TDM ベースのコール センターは、通常、Unified CM を使用しません (Cisco Unified CCE に移行する場合を除く)。Unified CVP スタンドアロンのセルフサービス展開モデルを使用するセルフサービス アプリケーションについても同様です。Unified CM は Unified CCE ソリューションの一部として使用されます。コール センター エージェントは、Cisco IP フォンを使用する、またはTDM ACD から移行される IP ソリューションの一部を構成します。

Cisco Unified Communications Manager は、音声ゲートウェイと IP フォンを制御するソフトウェア アプリケーションであり、VoIP ソリューションの基盤を提供します。Unified Communications Managerは、Cisco Unified Computing System（UCS）ハードウェアまたは仕様ベースの同等製品で実行されます。VM で実行されるソフトウェアは、Unified Communications Manager サーバと呼ばれます。複数の Unified Communications Manager サーバをクラスタにグループ化して、拡張性および耐障害性を提供することができます。Unified Communications Manager は、Media Gateway Control Protocol（MGCP）や Session Initiation Protocol（SIP）などの標準プロトコルを使用してゲートウェイと通信します。Unified Communications Manager は、SIP または Skinny Call Control Protocol（SCCP）を使用して IP フォンと通信します。Unified Communications Manager のコール処理能力およびクラスタ オプションの詳細については、http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 の最新バージョンを参照してください。

Unified CCE エージェント デスクトップ オプション

Cisco では、Unified CCE エージェント用に以下のインターフェイスを提供しています。

- Cisco Finesse デスクトップ: Cisco Finesse は、標準化された Web コンポーネントを通じてデスクトップを拡張することができる Web ベースのデスクトップ ソリューションです。Cisco Finesse は以下を提供します。

- ブラウザ ベースのソリューション

- Cisco IP フォン ベース ソリューションの限定的な機能

- 標準の OpenSocial ガジェットを使用した拡張可能なデスクトップ インターフェイス

- 文書化された REST API を使用するアプリケーションで利用可能なサーバ機能

- Cisco CTI OS デスクトップ Toolkit: CTI OS デスクトップ Toolkit は、カスタム デスクトップ、サードパーティ アプリケーションへのデスクトップ統合、またはサードパーティ アプリケーションへのサーバ間統合を構築するためのソフトウェア Toolkit を提供します。 CTI OS をセキュア モードで使用することはできますが、各 PG のエージェント キャパシティは 25％ 減少します。

Note

Avaya PG または親/子トポロジ を使用する非リファレンス設計のみが CTI OS デスクトップを使用することができます。Cisco Finesse は、他のすべての Contact Center Enterprise ソリューションで必要なデスクトップです。

これらの統合ソリューションにより、コール制御（応答、ドロップ、保留、保留解除、ブラインド転送またはウォーム転送、および会議）、アウトバウンド コール、コンサルティング コール、およびコール コンテキスト データの配信および操作（CTIスクリーン ポップ）が実現します。

Unified CCE のさまざまなエージェント インターフェイス

CRM コネクタを介して接続されたサードパーティ CRM ユーザーインターフェイスを使用するエージェントは、CTI OS デスクトップ Toolkit ベースのスーパーバイザ デスクトップを使用して監視することができます。

- デスクトップ アーキテクチャ

- SAP 向け Cisco Unified CRM Connector

デスクトップ アーキテクチャ

デスクトップ アプリケーションは通常、エージェント またはスーパバイザ デスクトップ、管理およびデータ サーバ、または管理クライアントで実行されます。デスクトップ アプリケーションをサポートするサービスは、Unified CCE 周辺機器ゲートウェイ（PG）サーバまたは独自のサーバで実行することができます。各 PG では、アクティブなデスクトップ サービスのセットが 1 つあります。

- CTI オブジェクト サーバ

- エージェントデスクトップ

- スーパーバイザ デスクトップ

CTI オブジェクト サーバ

CTI オブジェクト サーバ (CTI OS) は、CTI アプリケーションを展開するための、高性能でスケーラブルな障害対応性が高いサーバ ベースのソリューションです。CTI OS は CTI Toolkit Desktopに必要なコンポーネントです。CTI OS サーバは、Agent PG をホストする各 VM に1つずつ、冗長ペアとして実行されます。

デスクトップ アプリケーションは、エージェントの状態変更要求やコール制御などの通信を CTI OS サーバに渡します。CTI OS は、CTI Toolkit デスクトップと、カスタマー リレーションシップ マネジメント（CRM）システム、データ マイニング、ワークフロー ソリューションなどのサードパーティ アプリケーションとの単一の統合ポイントです。

CTI オブジェクト サーバは、TCP / IP 経由で CTI サーバに接続し、コール制御およびエージェント要求を CTI サーバに転送します。

CTI OS デスクトップ アーキテクチャ

CTI OS サーバは、CTI Toolkit のデスクトップ構成と動作情報も管理し、カスタマイズ、更新、およびメンテナンスを簡素化し、リモート管理をサポートします。

CTI オブジェクト サーバのサービス

- デスクトップ セキュリティ: PG の CTI オブジェクト サーバとエージェント、スーパーバイザ、または管理者デスクトップ PC 間のセキュア ソケット接続をサポートします。CTI OS デスクトップ Toolkit（CTI Toolkit）C ++ / COM CIL SDK を使用して構築される CTI アプリケーションはすべて、デスクトップ セキュリティ機能を使用することができます。

Note

現在、デスクトップ セキュリティは .NET および Java CIL では使用できません。

- Quality of Service（QoS）: デスクトップ コール制御メッセージのネットワークでのパケットの優先順位付けをサポートします。

Note

現在、QoS は .NET および Java CIL では使用できません。

- フェールオーバー リカバリ: フェールオーバー時の自動エージェント ログインをサポートします。

- チャット: エージェントとスーパーバイザ間のメッセージ伝送とテキスト チャット機能をサポートします。

- サイレント モニタリング: アクティブ コールの VoIP モニタリングをサポートします。CTI Object サーバは、サイレント モニタサービス（SMS）と通信して、VoIP パケット ストリーム転送を開始または停止します。

CTI オブジェクト サーバを冗長ペアで展開します。1 つは エージェント PG A に、もう 1 つはエージェント PG B に配置します。両方の CTI OS サーバが同時にアクティブになります。CTI Toolkit デスクトップ アプリケーションは、2 台のサーバのいずれかにランダムに接続します。元のサーバへの接続に失敗すると、デスクトップは代替サーバに自動的にフェールオーバーします。

Note

CTI OS サーバは、CTI Toolkit SDK を使用して構築されるデスクトップ アプリケーションとインターフェイスを持ちます。

エージェントデスクトップ

Unified CCE 展開では、エージェント デスクトップ アプリケーションが必要です。エージェントは、このデスクトップをエージェントの状態制御と通話制御に使用します。これらの必須機能に加え、デスクトップは他の便利な機能を提供します。

Cisco は、以下の主要なタイプの Unified CCE エージェント デスクトップ アプリケーションを提供しています。

- Cisco Finesse: 基本エージェント機能を拡張するガジェット ベースのアーキテクチャを提供するブラウザ ベースのエージェント デスクトップ ソリューション。

- CTI Toolkit デスクトップ: CTI Toolkitで構築されたエージェント デスクトップ アプリケーション。デスクトップは、他のアプリケーション、顧客データベース、および顧客関係管理（CRM）アプリケーションとの完全なカスタマイズおよび統合をサポートしています。

Note

CTI Toolkit デスクトップは、Unified CCE リリース 11.0(1) で廃止されました。新しい展開では、CTI Toolkit デスクトップを含めないでください。これらのデスクトップは、今後のリリースでサポート対象外となります。

- Siebel 向け Cisco Unified CRM Connector: Siebel Communication Server 向けの CTI ドライバ

Cisco のパートナーは、以下のタイプのエージェント デスクトップ アプリケーションのを提供しています。

- パートナー エージェント デスクトップ：カスタム エージェント デスクトップ アプリケーションは、Cisco テクノロジーパートナーから入手できます。これらのアプリケーションは CTI Toolkit に基づいており、このドキュメントでは個別に説明していません。Finesse REST API は、パートナーのデスクトップ統合を実現します。

- パッケージ済 CRM 統合: CRM 統合は、Cisco Unified CRM テクノロジー パートナーを通じて利用できます。これらの統合は CTI Toolkit に基づいており、このドキュメントでは個別に説明していません。

スーパーバイザ デスクトップ

エージェント デスクトップ アプリケーションに加えて、Cisco はスーパーバイザ デスクトップ アプリケーションを提供しています。コンタクト センターのスーパーバイザは、このアプリケーションを使用して、チームのメンバーのエージェントの状態を監視します。スーパーバイザ デスクトップでは、通話中のエージェントのサイレント モニタリングも可能です。

Cisco は、以下のタイプの Unified CCE スーパバイザ デスクトップ アプリケーションを提供しています。

- Cisco Finesse：スーパーバイザ機能を備えた基本 Finesse エージェント デスクトップを拡張する、完全にブラウザ ベースのスーパーバイザ アプリケーション。

- CTI Toolkit スーパバイザ デスクトップ: CTI Toolkitで構築されたスーパバイザ デスクトップ アプリケーション。デスクトップは、他のアプリケーション、顧客データベース、および CRM アプリケーションとのカスタマイズと統合をサポートしています。

- Cisco パートナーを通じて提供されるスーパーバイザ デスクトップ アプリケーション。

- パッケージ済 CRM 統合: CRM 統合は、Cisco Unified CRM テクノロジー パートナーを通じて利用できます。これらの統合は CTI Toolkit に基づいており、このドキュメントでは個別に説明していません。

Note

スーパバイザ デスクトップには CAD も提供されています。詳細については、CAD のドキュメンテーションを参照してください。

SAP 向け Cisco Unified CRM Connector

Siebel l 向け Cisco Unified CRM Connectorは、Unified CCE と Siebel CRM 環境の統合の実現のためにインストールするコンポーネントです。このソリューションでは、Siebel エージェント デスクトップがエージェントの状態とコール制御インターフェイスを提供します。コネクタは、CTI OS Desktop Toolkit C ++ CIL で構築されています。Siebel デスクトップは、コネクタを使用して CTI OS サーバと通信します。

Siebel 向け Cisco Unified CRM Connectorは以下はサポートしません。

- エージェント グリーティングの有効化 / 無効化

- 新しいエージェント グリーティングの録音

Siebel 向け Cisco Unified CRM Connector の詳細については、http://www.cisco.com/en/US/products/ps9117/tsd_products_support_series_home.html の製品ドキュメンテーションを参照してください。Siebel eBusiness ソリューションの詳細については、Siebel の ウェブサイトを参照してください。

Cisco Unified IP IVR

Unified IP IVR は Unified CCE ソリューションのプロンプト、収集、およびキュー機能を提供します。Unified IP IVR は Unified Communications Manager のバックにあり、Service Control Interface（SCI）を介して Unified CCE ソフトウェアの制御下にあるため、Unified CVP のようにはコール制御を提供しません。エージェントが応答可能になると、Unified CCE ソフトウェアは、選択したエージェントの電話にコールを転送するように Unified IP IVR に指示します。Unified IP IVR は次に、選択したエージェントの電話にコールを転送するように Unified Communications Manager に要求します。

Unified IVR は、Cisco Unified Computing System（UCS）ハードウェアまたは仕様ベースの同等製品で実行されるソフトウェア アプリケーションです。Unified CCEの制御下で、単一の Unified Communications Manager クラスタで複数の Unified IP IVR サーバを展開することができます。

Unified IP IVR には従来の VRU のような物理的なテレフォニー トランクやインターフェイスはありません。テレフォニー トランクは、音声ゲートウェイで終端します。Unified Communications Manager は、音声ゲートウェイから Unified IP IVRへの G.711 または G.729 Real-Time Transport Protocol（RTP）ストリームをセットアップするためのコール処理およびスイッチ機能を提供します。Unified IP IVR は、Java Telephony Application Programming Interface（JTAPI）を介して Unified Communications Manager と通信します。Unified IP IVR は、Service Control Interface（SCI）経由で VRU 周辺機器ゲートウェイまたはシステム周辺機器ゲートウェイおよび Unified CCE と通信します。

完全な耐障害性を必要とする展開では、少なくとも 2 つの Unified IP IVRが必要です。

Unified IP IVRのみを使用する Unified CCE 展開では、Unified CM クラスタは約 2,000 人の Unified CCE エージェントをサポートすることができます。上記の制限は、BHCA コールの負荷および設定されたすべてのデバイスが、1 対 1 の冗長性を備えた 8 つのコール処理サブスクライバに均等に分散されることを前提としています。これらのキャパシティは、特定の展開に応じて異なります。ソリューションのサイジングを Cisco Unified Communications Manager キャパシティ ツールで行います。

サブスクライバは最大 500 人のエージェントをサポートすることができます。フェールオーバー シナリオでは、プライマリ サブスクライバは最大 1000 人のエージェントをサポートします。

多数の VRU ポートを必要とする展開では、Unified IP IVRではなく Unified CVP を使用します。Unified IP IVR ポートは Unified CM に多大な呼処理負荷をかけますが、Unified CVP 負荷をかけません。そのため、Unified CVP 使用した Unified CC E展開では、クラスタ毎により多くのエージェントおよびより高い BHCA レートが実現されます。

- Unified IP IVR 向け JTAPI コミュニケーション

- Unified IP IVR を使用した CTI Manager のフェールオーバー

- Unified IP IVR 設計に関する考慮事項

- Unified IP IVR によるアウトバウンド オプション

Unified IP IVR 向け JTAPI コミュニケーション

Unified IP IVR の PIM ログインイン プロセスは、Unified CM クラスタとアプリケーション間で JTAPI 通信を確立します。CTI マネージャは、JTAPI 経由で Unified IP IVRと交信します。クラスタ内のすべてのサブスクライバは、CTI マネージャ インスタンスを実行します。ただし、PG 上の Unified CM PIM は、クラスタ内で 1 つの CTI マネージャ (つまり 1 つのノード) のみと通信します。この接続された CTI マネージャは、クラスタ内の他のノードに対して CTI メッセージを渡します。PG の各冗長ペアは、一意の JTAPI ユーザ ID を共有します。

各 Unified IP IVR クラスタ内の単一の CTI Manager とのみ通信します。ユーザ ID は、CTI マネージャがさまざまなプロセスを追跡する方法として使用されます。

Unified IP IVR は冗長ペアでは展開されません。ただし、プライマリ CTI Manager が動作していない場合、 Unified IP IVR はクラスタ内の別の CTI Manager にフェールオーバーすることができます。

Unified IP IVR は Agent PG と同じタイプの JTAPI メッセージを使用します。Agent PGとは異なり、Unified IP IVR は、監視および制御されるアプリケーションおよびデバイスの両方を提供します。

Unified CCE が監視および制御するデバイスは、物理的な電話機です。Unified IP IVR には従来の VRU のような物理ポートはありません。Unified IP IVR のポートは CTI ポートと呼ばれる論理ポートです。Unified IP IVRの各 CTI ポートには、Unified Communications Manager で定義された CTI ポート デバイスが必要です。

従来の PBX またはテレフォニー スイッチとは異なり、Unified Communications Managerは、コールの送信先である Unified IP IVR ポートを選択しません。CTI ルート ポイントを介して Unified IP IVR JTAPI ユーザに関連付けられている DN にコールが発信されると、サブスクライバはどの CTI ポートがコールを処理するかを Unified IP IVR に尋ねます。Unified IP IVR に利用可能な CTI ポートがある場合、Unified IP IVR そのコールを処理するために、CTI ポートのデバイス識別子を使用してルーティング制御要求に応答します。

SIP は、Dual Tone Multi-Frequency（DTMF）数字を送信します。ただし、Unified IP IVR および Unified Communications Manager は帯域外 DTMF 数字のみをサポートします。クラスタからの JTAPI メッセージが、発信者が入力した DTMF 数字を Unified IP IVR に通知します。クラスタは、MTP リソースを使用して、帯域内シグナリングを帯域外シグナリングに変換します。CTI ポートは、帯域外 DTMF 数字のみをサポートします。展開に SIP 電話またはゲートウェイが含まれる場合、変換をサポートするのに十分な MTP リソースをプロビジョニングします。モバイル エージェント機能では、この変換のために追加の MTP リソースも必要となります。

以下のシナリオは、Unified IP IVR デバイスおよびコール制御のい例です。使用可能な CTI ポートがコールに割り当てられると、Unified IP IVR ワークフローが Unified IP IVR内で開始します。ワークフローが受入れステップを実行すると、JTAPI メッセージがサブスクライバに送信され、その CTI ポートの呼び出しに応答します。Unified IP IVR ワークフローが転送されたコールまたは開放されたコールを取得する際には、ワークフローは再びそのコールの処理方法についてサブスクライバに指示します。

発信者が Unified IP IVRとの対話中にコールをリリースすると、VG は発信者のリリースを検出します。VG は、Media Gateway Control Protocol（MGCP）を使用してサブスクライバに通知します。MGCPは、JTAPI を使用して Unified IP IVR に通知します。VG が DTMF トーンを検出すると、VG は H.245 または MGCP を介して加入者に通知し、JTAPI を介して Unified IP IVR に通知します。

CTI ポート デバイスの制御と監視を行うには、Unified Communications Manager の CTI ポート デバイスを適切な Unified IP IVR JTAPI ユーザ ID に関連付けます。2 つの 150 ポートの Unified IP IVRがある場合、300 の CTI ポートがあることになります。CTI ポートの半分を JTAPI ユーザ Unified IP IVR 1に関連付け、CTI ポートの残りの半分を JTAPI ユーザ Unified IP IVR 2に関連付けます。

コールを独自に Unified IP IVRにルーティングするように Unified Communications Manager を設定することはできますが、Unified CCEは、Unified CCE 環境で Unified IP IVRにコールをルーティングします（Unified IP IVR が 1 つのみで、すべてのコールに初期 VRU 処理が必要な場合でも ）。これにより、Unified CCE の適切なレポートが保証されます。複数の Unified IP IVRを使用した展開の場合、このルーティング方法により、Unified CCE は複数の Unified IP IVRでコールの負荷を分散することができます。

Unified IP IVR を使用した CTI Manager のフェールオーバー

各 エージェント PG は1つの CTI Manager 接続のみをサポートします。各サブスクライバには CTI Manager がありますが、通常は 2 つのサブスクライバのみが エージェント PG に接続します。4 サブスクライバ クラスタ 内のすべてのサブスクライバがエージェント PG に直接接続できるようにするには、エージェント PG の別のペアを追加する必要があります。

以下の図は、エージェント PGへの接続がある CTI Manager の障害を示しています。サブスクライバ C および D のみが、エージェント PG に接続するように構成されています。

以下の条件がシナリオに適用されます。

- 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

- サブスクライバ C および D の CTI Manager は、エージェント PGに JTAPI サービスを提供します。

エージェント PG 接続を使用する CTI Manager に障害が発生します

Unified CVPとは異なり、Unified IP IVR はコール制御を CTI Manager に依存しています。Unified IP IVR 展開では、Agent PG接続での CTI Manager の障害により、Unified IP IVR JTAPI サブシステムがシャットダウンします。このシャットダウンにより、Unified IP IVR サーバは、サーバが処理しているすべての音声コールをドロップします。

次に、JTAPI サブシステムが再起動し、バックアップ サブスクライバ上の CTI Manager に接続します。Unified IP IVR は、Unified IP IVR JTAPI ユーザに関連付けられているすべての CTI ポートを再登録します。すべての Unified CM デバイスが正常に登録されると、サーバは VRU 機能を再開し、新しいコールを処理します。

Unified IP IVR 設計に関する考慮事項

Cisco Unified IP IVR は、Unified Communications Manager クラスタ内の異なるサブスクライバ上の 2 つの CTI Manager と JTAPI 接続を確立できます。この機能により、CTI Manager レベルでUnified IP IVR の冗長性が有効になります。複数の Unified IP IVRサーバを展開することにより、冗長性を高めることができます。複数の Unified IP IVR サーバにより、コール ルーティング スクリプトは、使用可能な IP IVR リソース間でコールの負荷を分散することができます。

次の図は、クラスタで冗長にセットアップされた 2 つの Unified IP IVR サーバを示しています。異なる Unified Communications Manager サブスクライバ上の CTI Manager に接続されている各サーバで、Unified IP IVR グループを設定します。次に、2 番目の CTI Manager を各 Unified IP IVR サーバのバックアップとして追加します。プライマリ CTI Manager に障害が発生すると、Unified IP IVR サーバはバックアップ CTI Manager にフェールオーバーします。

IP IVR ハイ アベイラビリティ展開

- コール転送による高可用性

- コール フロー ルーティング スクリプトによる高可用性

コール転送による高可用性

Unified Communications Manager の以下のコール転送機能を使用して、Unified IP IVR ポートの使用を管理することができます。

- 転送中（ビジー）: Unified Communications Manager がポートがビジーであることを検出すると、コールを別のポートまたはルート ポイントに転送します。

- 転送（応答なし）: タイムアウト期間内にポートがコールをピックアップしなかったことを Unified Communications Manager が検出すると、コールを別のポートまたはルート ポイントに転送します。

- 転送（失敗）: Unified Communications Manager がアプリケーション エラーに起因するポート障害を検出した場合、コールを別のポートまたはルート ポイントに転送します。

コール転送機能を使用する場合、コール転送を開始した CTI ポートへのパスは確立しません。このようなパスは、すべての Unified IP IVR サーバが利用できない場合にループを発生させます。

コール フロー ルーティング スクリプトによる高可用性

Unified CCE コール フロー ルーティング スクリプトを使用して、高可用性をサポートすることができます。Unified IP IVR にコールを送信する前に、コールフロー ルーティング スクリプトで Unified IP IVR周辺機器ステータスを確認します。このチェックにより、コールが非アクティブな Unified IP IVRにキューイングされなくなります。たとえば、音声応答ユニット（VRU）への変換ルートを作成して、アイドルポートが最も多い Unified IP IVR を選択します。このメソッドは、コールをコール毎に均等に分散します。この方法を変更して、複数の Unified IP IVRでポートの負荷を分散できます。 この方法では、同じ変換ルートまたは VRU ノードに送信するクラスタ上のすべての Unified IP IVRをアドレス指定することができます。

Note

Unified IP IVR サーバに障害が発生すると、Unified IP IVR でのすべてのコールがドロップされます。複数の Unified IP IVR サーバにコールを分散することにより、このような障害の影響を最小限に抑えます。Unified IP IVRでは、デフォルト スクリプトは、Unified IP IVR が VRU PG へのリンクを失った場合のコールの損失を防ぎます。

Unified IP IVR によるアウトバウンド オプション

アウトバウンドオプションで Unified IP IVR を使用する場合、すべてのコールを Unified CM でフロントエンドとします。この展開により、サブスクライバのコール負荷が高くなります。サブスクライバは毎秒 5 コールのみをサポートするため、エージェントと VRU に転送されるコールを、Unified SIP プロキシ サーバを使用して複数のサブスクライバに分散します。

アウトバウンド コール センターが 1 つの国（たとえばインド）にあり、顧客が別の国（たとえば米国）にある場合、WAN ネットワーク構造を検討すべき展開もあります。VRU キャンペーンへの転送に Unified IP IVR 展開を使用して、Unified IP IVR が WAN によってアウトバウンド オプション ダイヤラ サーバから分離されている場合。WAN トラフィックを減少するため、独自の Cisco Unified CMをクラスタに含む Unified IP IVR を提供します。

VRU キャンペーンへの転送のためのアウトバウンド オプションの分散展開

この図は、Unified IP IVRを使用した VRU 転送キャンペーンの分散展開を示しています。

Unified IP IVR を使用した VRU 転送キャンペーンの分散展開例

この図のソリューションでは、以下の点に注意します。

- 音声ゲートウェイとルータまたは Logger A サーバは、米国の 2 ヵ所のサイト（サイト 1 とサイト 3）に分散されています。

- Unified CM クラスタは、VRU PG と共にサイト 3（米国）にあります。

- 冗長 VRU PG はサイト 3（米国）にあります。

- IP IVR はサイト 3（米国）にあります。

- 冗長化 MRPGまたはダイヤラおよび冗長エージェント PG は、サイト 2 で同じ VM 上にインストールされます。

- SIP ダイヤラは、サイト 3（米国）にある音声ゲートウェイを使用します。

- 音声ゲートウェイは、サイト 3 （米国）で CT3 インターフェイスを含む図に含まれています。ルータは、ダイヤラ コールに 1:1 の冗長性を提供します。

- WAN SIP シグナリング トラフィックがライブ アウトバウンド コールを転送するのを避けるため、冗長 Unified SIP プロキシ サーバはサイト 2 に配置されています。

- 各 SIP ダイヤラは、サイト 2 で独自の統合 SIP プロキシ サーバに接続します。各統一 SIP プロキシ サーバは、サイト 3 で（米国）音声ゲートウェイのセットを制御します。

- Unified SIP プロキシ サーバは、（N + 1）冗長性を提供します。

SIP ダイヤラで録音を有効にする場合、WAN 帯域幅の要件は以下の通りです。

- 応答した各発信コールの帯域幅：

- G.711 コーデック コールでは、コール プログレス分析の期間に 80 kbps の WAN 帯域幅が必要です。

- G.729 コーデック コールでは、コール プログレス分析の期間に 26 kbps の WAN 帯域幅が必要です。

- 発信コールのアラート毎の帯域幅：

- G.711 コーデックのコールには、80 kbps の WAN 帯域幅が必要です。

- G.729 コーデックのコールには、26 kbps の WAN 帯域幅が必要です

- Unified IP IVR ではセルフサービスのキュー内の発信コールは、WAN 帯域幅を必要としません。

Unified Intelligent Contact Manager

Unified CCE を Unified ICM と共に展開して、完全なエンタープライズ コール管理システムを形成することができます。Unified ICM は、さまざまなベンダー（Cisco Unified CCE を含む）、VRU（Cisco Unified IP IVR および Unified CVP を含む）、およびテレフォニー ネットワーク システムの ACD とインターフェイスし、リソースが企業内の場所にあるかどうかに関わらず、コールや E メールなどの顧客連絡先を効率的かつ効果的に処理します。

Unified CCE は、CallRouter、Logger、管理サーバおよびデータ サーバ、およびその他のコンポーネントが Unified ICM と Unified CCE の間で共有される、Unified ICM との ハイブリッド モデルで展開することができます。

または、Unified ICM が親であり、Unified CCE が子である親/子モデルで Unified CCE を展開することもできます。これは、他のベンダーの ACD を使用した Unified ICM の展開モデルに非常に似ています。各製品に CallRouters、データ サーバ等が提供されるため、非常に拡張性が高い展開で使用されます。 ただし、管理および保守するコンポーネントは他にもあります。また、外部委託運用など、Unified ICM と Unified CCE の間で分離が必要な分散モデルにも使用されます。

- Unified ICM の設定

Unified ICM の設定

- Cisco Unified ICM 7.0 で Unified CVP を介して後続のコール制御を実行するには、常にトランスレーション ルートを使用し、次の宛先にコールを配信する前にタイプ 2 ネットワーク VRU として Unified CVP にコールをルーティングします。この方法では、Unified CM がこれ以上のラベルを受信できないため、後続のコール転送を管理するために Unified CVP に制御が渡されます。

- キューイング処理、プロンプトとコレクト、またはセルフサービス アプリケーションを実行するには、常にトランスレーション ルートと SendToVRU ノードに従います。SendToVRU は Queue ノードまたは RunExternalScript ノードによって暗黙的に起動できますが、この方法に頼らないことをお勧めします。実際の SendToVRU ノードを常に含めるようにします。

- Cisco Unified ICM 7.1 で Unified CVP を介して後続のコール制御を実行するには、タイプ 10 ネットワーク VRU を使用すれば、トランスレーション ルートは必要ありません。タイプ 10 VRU は、相関 ID 方式を使用し、SendToVRU ノードを使用して Unified CM から Unified CVP への転送を実行します。タイプ 10 VRU で SendToVRU ノードが使用されると、Unified CVP への最初の転送によって呼制御は Unified CVP にハンドオフされ、VRU レッグへの 2 番めの転送が自動的に実行されて、コールは VRU 処理のために音声ブラウザに配信されます。

Note

このコール フローおよびこのマニュアルのその他のすべてのコール フローは、Cisco Unified ICM 7.0(0) 以降の使用を想定しています。

- タイプ 10 VRU で SendToVRU ノードが使用されると、Unified CVP への最初の転送によって呼制御は Unified CVP にハンドオフされ、VRU レッグへの 2 番めの転送が自動的に実行されて、コールは VRU 処理のために音声ブラウザに配信されます。

汎用周辺機器ゲートウェイ

汎用 PG: エージェント PG と VRU PG を組み合わせます

PG の最後のクラスは汎用 PG です。この PG では、異なるタイプの PIC を組み合わせることはできません。そのため、エージェント PGと VRU PG は個別に展開することができます。これらの機能を単一の汎用 PGに組み合わせることもできます。

周辺機器ゲートウェイおよびサーバ オプション

Unified CCE 周辺機器ゲートウェイ (PG) Unified Communications Manager サーバ、Unified IP IVR、Unified CVP、または音声応答ユニット (VRUs) からのメッセージを Unified CCE に送信され、理解される共通の内部形式のメッセージに変換します。逆に、 Unified CCE メッセージを変換して、周辺機器に送信して理解できるようにします。

以下の図は、CTI OS を搭載した Agent PG のさまざまな構成オプションを示しています。

CTI OS を使用したエージェント PG 構成オプション

次の表に、PG および PIM のサイジング ガイドラインを示します。

PG および PIM のサイジングのガイドライン

サイジング変数

Unified CCE リリース10 に基づくガイドライン

Unified CCE 毎の最大 PG 数

150

VM 毎の最大 PG タイプ数

VM 毎に最大 2 つの PG タイプが許可されますが、各 VM は最大エージェントおよび VRU ポートの制限を満たす必要があります。

VM 毎の最大 Unified Communications Manager PG 数

VM 毎に許可される Unified Communications Manager PG、汎用 PG、またはシステムk PGは 1 つのみです。

PG 毎の最大 Unified Communications Manager PIM 数

1

PG は Unified CCEから分離できるのか?

可

PG は Unified Communications Manager から分離できるのか?

不可

1 つの Unified Communications Manager によって制御される VRU の最大数。

http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。

PG あたりの最大 CTI サーバ数

1

PG は Cisco Unified Communications Manager と共存できるか?

不可

はじめに

- 変更履歴

- このガイドについて

- 対象読者

- 関連資料

- 通信、サービス、およびその他の情報

- フィールド通知

- マニュアルに関するフィードバック

- 表記法

変更履歴

以下の表に、このガイドで行われた変更のリストを示します。最新の変更から提示されています。

変更内容

セクション

日付

マニュアル初回リリース

2020 年 2 月

次の展開タイプに向けた Cisco UCS C240 M5SX および Cisco Hyperflex HX220c M5SX TRC サーバでリファレンス設計レイアウトおよび VM 使用を追加。

- 2000 エージェント展開

- 4000 エージェント展開

- 12000 エージェント展開

- 24000 エージェント展開

Contact Center Enterprise Reference Designs

新規 Cisco Webex エクスペリエンス管理機能機能に情報を追加。

Contact Center Enterprise ソリューションの概要

統合機能の設計上の考慮事項

新規 顧客向け仮想アシスタンス機能 機能に情報を追加。

統合機能の設計上の考慮事項

2 つの共有 ACD 回線上の自宅と仕事用電話機の両方の共有 ACD 回線サポートが追加。

統合機能の設計上の考慮事項

次の構成制限が増加しました。

- ダイヤラごとの 1 秒あたりのアウトバウンドダイヤラ最大コール数

- SIP ダイヤラごとのアウトバウンドダイヤラ最大ポート

- システムごとのプレビューキャンペーン数

- システムあたりの予測キャンペーン数（エージェントまたは VRU ベース）

- 周辺機器ごとの予想キャンペーンスキルグループ

アウトバウンド キャンペーンの制限

メンテナンスサポートが終了した Cisco MediaSense、Cisco Remote Expert、Context Service に関する情報を削除。

デスクトップチャット検索を追加

Desktop Chat サーバの設定

このガイドについて

このガイドには、Cisco Unified Contact Center Enterprise（Unified CCE）の展開に関する設計上の考慮事項およびガイドラインが記載されています。このガイドは、導入されたソリューションに含まれる可能性があるすべてのコンポーネントの情報をまとめたものです。このガイドは、読者が基本的なコンタクト センターの用語および概念をよく理解していることを前提としています。Unified CCX を適切に展開するには、『Cisco Collaboration System Solution Reference Network Designs』Cisco Collaboration System ソリューション リファレンス ネットワーク設計 (SRND)『Cisco Collaboration System Solution Reference Network Designs』 記載の情報にも精通している必要があります。

このガイドでは、設計プロセスに焦点を当てています。最初のコンセプト設計から、最終的な設計提示までの過程において必要な情報を提供することが目的です。コンタクト センターのエンタープライズ ソリューションのインストール、設定、および管理の詳細については、他のガイドで説明しています。

本書の 4 章まででは、3 種類の Contact Center Enterprise ソリューションを幅広くカバーしています。

- Packaged Contact Center Enterprise

- Contact Center 版 Cisco Hosted Collaboration Solution

- Unified Contact Center Enterprise

Unified CCE に特化した設計上の考慮事項およびガイドラインに関する情報は、残りの章を参照してください。

対象読者

このガイドの最初の 3 章は、コンタクト センターのエンタープライズ ソリューションの全体的な概要が必要なユーザを対象としています。

このガイドの主な対象者は、コンタクト センターを設計するユーザです。このガイドは、コンタクト センターの企業向けのコンポーネントの連携および動作方法について、詳しい知識を必要とするシステム管理者にも役立ちます。

関連資料

上記の本ガイドで説明されない情報の詳細については、以下のドキュメントを参照してください。

詳細

リンク

どの製品のどのバージョンのがコンタクト センターのエンタープライズ ソリューションに対応しているかについては、互換性マトリクス を参照してください。

https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html

https://www.cisco.com/c/en/us/support/customer-collaboration/packaged-contact-center-enterprise/products-device-support-tables-list.html

https://www.cisco.com/c/en/us/support/unified-communications/hosted-collaboration-solution-contact-center/products-device-support-tables-list.html

Cisco Unified Contact Center Enterprise 機能ガイド ソリューションの統合された機能の設定と管理の詳細を参照してください。

http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html

現在のソリューション構築の基盤となる ユニファイド コミュニケーションのインフラストラクチャの詳細については、Cisco Collaboration Systems ソリューション リファレンス ネットワーク設計 を参照してください。

http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html

各コンポーネントの完全なドキュメントについては、以下のサイトに掲載されたコンタクト センターの企業向けソリューションを参照してください。

コンポーネント

リンク

Cisco Unified Contact Center Enterprise

http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/tsd-products-support-series-home.html

Cisco Finesse

http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/tsd-products-support-series-home.html

Cisco Customer Collaboration Platform

https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/tsd-products-support-series-home.html

Cisco Unified Customer Voice Portal

http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/tsd-products-support-series-home.html

Cisco Unified Intelligence Center

http://www.cisco.com/c/en/us/support/customer-collaboration/unified-intelligence-center/tsd-products-support-series-home.html

Cisco Virtualized Voice Browser

http://www.cisco.com/c/en/us/support/customer-collaboration/virtualized-voice-browser/tsd-products-support-series-home.html

Unified Contact Center 管理ポータル

http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-management-portal/tsd-products-support-series-home.html

通信、サービス、およびその他の情報

- シスコからタイムリーな関連情報を受け取るには、Cisco Profile Manager でサインアップしてください。

- 重要な技術によりビジネスに必要な影響を与えるには、Cisco Services にアクセスしてください。

- サービス リクエストを送信するには、Cisco Support にアクセスしてください。

- 安全で検証済みのエンタープライズクラスのアプリケーション、製品、ソリューション、およびサービスを探して参照するには、Cisco Marketplace にアクセスしてください。

- 一般的なネットワーキング、トレーニング、認定関連の出版物を入手するには、Cisco Press にアクセスしてください。

- 特定の製品または製品ファミリの保証情報を探すには、Cisco Warranty Finder にアクセスしてください。

Cisco バグ検索ツール

Cisco Bug Search Tool（BST）は、シスコ製品とソフトウェアの障害と脆弱性の包括的なリストを管理する Cisco バグ追跡システムへのゲートウェイとして機能する、Web ベースのツールです。BST は、製品とソフトウェアに関する詳細な障害情報を提供します。

フィールド通知

シスコでは、シスコ製品に関する重要な問題についてカスタマーとパートナーに通知するために、Field Notice を発行しています。通常それらの問題については、アップグレード、回避策、またはその他のユーザ アクションが必要になります。詳細については、https://www.cisco.com/c/en/us/support/web/tsd-products-field-notice-summary.html の「製品フィールド通知の概要」を参照してください。

次の通知で新しいアナウンスがリリースされた場合、シスコ製品、シリーズ、またはソフトウェアのカスタムサブスクリプションを作成して、電子メールアラートを受信したり、RSS フィードを利用できます。

- Cisco セキュリティ アドバイザリ

- Field Notice

- 販売終了またはサポートに関するアナウンス

- ソフトウェアアップデート

- 既知のバグの更新

カスタムサブスクリプションの作成の詳細については、https://cway.cisco.com/mynotifications の「マイ通知（My Notifications）」を参照してください。

マニュアルに関するフィードバック

このドキュメントに関するご意見は、contactcenterproducts_docfeedback@cisco.com まで電子メールでご共有ください。

ご意見をお待ちしています。

表記法

このマニュアルでは、以下の表記法を使用しています。

表記法

説明

▽太字△

太字は、ユーザエントリ、キー、ボタン、フォルダ名およびサブメニュー名などのコマンドを表すときに使用されます。

次に例を示します。

- [編集（Edit）] > [検索（Find）] を選択します。

- [完了（Finish）] をクリックします。

イタリック体

イタリック体は、次の内容を表すときに使用されます。

- 新しい用語の紹介。例：スキル グループとは、類似したスキルを持つエージェントの集合です。

- ユーザが置き換える必要のある構文値。例：IF (condition, true-value, false-value)

- ドキュメントのタイトル。例： Cisco Unified Contact Center Enterprise インストールおよびアップグレード ガイドを参照してください。

ウィンドウ フォント

Courier などのウィンドウ フォントは、次の場合に使用されます。

- コード中のテキストや、ウィンドウに表示されるテキスト。例： <html><title>Cisco Systems, Inc. </title></html>

< >

山カッコは、次の場合に使用されます。

- コンテキストでイタリックが許可されない引数（ASCII 出力など）。

- ユーザが入力する文字列で、ウィンドウには表示されないもの（パスワードなど）。

Full Cisco Trademarks with Software License

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)

エージェントに関する制限

Note

Contact Director 列のデータは、Contact Director に設定される内容を示しています。Contact Director の接続先のターゲット システムに設定される内容は含まれていません。

エージェントに関する制限

リソース

2000 エージェント リファレンス設計モデル

4000 エージェント リファレンス設計モデル

12000 エージェント リファレンス設計モデル

Contact Director リファレンス設計モデル

アクティブなエージェント[1]

2000

4000

12000

24000（2 つのターゲット システムにそれぞれ 12000 エージェント）

各 Unified CM クラスタ上のアクティブなエージェント

2000

4000

8000

NA

設定済みエージェント

12000

24000

72000

NA

PG ごとに構成されたエージェント

12000

12000

12000

NA

TraceON が有効になっているエージェント

100

100

400

NA

エージェント デスク設定

2000

4000

12000

NA

エージェント PG ごとの有効なモバイルエージェント[2]

2000（固定接続）

または

800（コールバイコール接続）

2000（固定接続）

または

800（コールバイコール接続）

2000（固定接続）

または

800（コールバイコール接続）

2000（固定接続）

または

800（コールバイコール接続）

NA

アクティブな ECE マルチメディア エージェント

1500[3]

4000[4]

12000[5]

NA

チームごとのエージェント

50

50

50

NA

エージェントが所属できるチーム

1

1

1

該当なし

エージェントごとのスキル

15

詳細については、動的サイジングに関する項を参照してください。

15

詳細については、動的サイジングに関する項を参照してください。

15

詳細については、動的サイジングに関する項を参照してください。

NA

スキル グループ内のエージェントの数

12000

24000

72000

NA

エージェントごとの属性

50

50

50

該当なし

[1] アウトバウンド エージェントおよびマルチチャネル エージェントが含まれます。ただし、占有できるエージェントの数は、アウトバウンド オプション ダイヤラと SocialMiner の制限に基づきます。

[2] 平均処理時間が 3 分未満の場合、またはエージェントグリーティングまたはウィスパーアナウンスメント機能がモバイルエージェントと併用されている場合は、固定接続で1500。

[3] ECE が共存する場合、制限は 400 エージェントとなります。1500 の制限は、ECE が別のサーバにある場合に適用されます。

[4] この制限は、複数の ECE クラスタが必要です。各エージェント PG は、400 エージェントを共存させるクラスタまたは別のサーバ上の 1500 エージェント クラスタのいずれかをサポートすることができます。

[5] この制限は、複数の ECE クラスタが必要です。各エージェント PG は、400 エージェントを共存させるクラスタまたは別のサーバ上の 1500 エージェント クラスタのいずれかをサポートできます。

Related Concepts

エージェントあたりのスキル グループとプレシジョン キューに対する動的制限

その他の動的サイジング要因

モバイル エージェントと PG エージェントの容量

モバイル エージェントと PG エージェントの容量

モバイル エージェントは PG と Unified CM の負荷を増加させます。モバイル エージェントを使用すると、PG 上のエージェント容量が次のように縮小します。

- 1000（固定接続、2:1）

- 500（コールバイコール接続、4:1）

同じ PG 上にモバイル エージェントとその他のエージェントを混在させることができます。エージェントの各タイプの重みに注意してください。たとえば、PG 上に固定接続による 200 のアクティブなモバイル エージェントを計画していると仮定します。PG は他のエージェントを 1600 サポートできます。

Additional Agents Allowed = (2000 – (200 * 2)) = 1600 Agents

代わりに、コールバイコール接続による 200 のアクティブなモバイル エージェントを計画している場合、PG は他のエージェントを 1200 サポートできます。

Additional Agents Allowed = (2000 – (200 * 4)) = 1200 Agents

DNS サーバ

ドメイン ネーム システム（DNS）サーバはネットワーク内のどこにでも設置できます。このサーバはホスト名を IP アドレスに解決します。Contact Center Enterprise ソリューションでは、タイプ A と SRV タイプの両方のレコード ルックアップを行うことができます。DNS サーバの応答が遅い、DNS サーバを使用できない、または DNS サーバが WAN を介している場合は、ソリューションに対するパフォーマンスの影響を確認してください。

コンタクト センターは、次のような状況で SIP インタラクション中に DNS サーバを使用できます。

- コールがイングレス音声ゲートウェイに到達すると、ダイヤル ピアは DNS を使用して、2 つの SIP プロキシ サーバ間でコールを交互に処理できます。SIP プロキシ サーバは、DNS を使用して、着信コールを複数の SIP サービスに分散することもできます。コンタクト センターで SIP プロキシ サーバを使用しない場合は、イングレス音声ゲートウェイで DNS を直接使用して、インバウンド コールを複数の SIP サービスに分配できます。

- Unified CCE は SIP サービスを指示して VRU レッグにコールを転送し、DNS を使用して 2 つの SIP プロキシ サーバ間でこのような要求を交互に処理できます。コンタクト センターで SIP プロキシ サーバを使用しない場合は、SIP サービスで DNS を直接使用して、VRU レッグを複数の音声ブラウザに分配することができます。

- SIP プロキシは、DNS SRV を使用して SIP プロキシ サーバ経由でエージェントにアウトバウンド コールを転送することはできません。ロード バランシングやフェールオーバーを実行するには、複数のスタティック ルートを SIP プロキシに設定します。スタティック ルートは、IP アドレスまたは標準の DNS A ホスト レコードをポイントできます。コンタクト センターで SIP プロキシ サーバを使用しない場合は、SIP サービスで DNS を使用してターゲット エージェントの IP アドレスを検出できます。

- Cisco Finesse は、ホスト名の解決と逆引き参照のために、インストール時に DNS サーバを使用します。

- Unified CCE は、ホスト名の解決とサーバ インベントリの逆引き参照のために、Unified CCE Administration ツールで DNS サーバを使用します。

Unified CVP では、SIP ルーティングに対して DNS サーバを使用するかどうかは任意です。既存の DNS サーバが Unified CVP による追加の負荷を処理するため、専用の DNS サーバを持つ必要はありません。ネットワークに入った、Unified CVP を宛先とするすべてのコールに対して、DNS ルックアップが約 3 ～ 4 回発生します。1 秒あたりの DNS クエリー数を判断するには、ソリューションの 1 秒あたりのコール数を特定し、その数値に 4 を掛けます。

コンタクト センターでは DNS SRV クエリーの DNS ルックアップが必要ですが、A レコード クエリーのルックアップは必ずしも必要ではありません。A レコード ルックアップをシステム ファイルにローカルに設定することもできます。DNS SRV ルックアップを回避するために Unified CVP サーバ グループを使用できます。

Related Concepts

DNSサーバ導入に関する考慮事項

プレシジョン キューおよびスキル グループに関する制限

Note

各プレシジョン キューにはスキル グループが関連付けられています。各プレシジョン キューには、2 つのスキル グループの重みが効果的に設定されます。

プレシジョン キューおよびスキル グループに関する制限

リソース

Unified CCE 2000 エージェント リファレンス設計モデル

Unified CCE 4000 エージェント リファレンス設計モデル

Unified CCE 12000 エージェント リファレンス設計モデル

Unified CCE Contact Director リファレンス設計モデル

システムごとのスキル グループ

16,000[1]

16,000

27,000

54,000

エンタープライズ スキル グループ

4000

4000

4000

4000

周辺機器ごとの設定済みスキル グループとプレシジョン キューの組み合わせの最大数

4000

4000

4000

該当なし

システムごとの設定済みプレシジョン キュー

4000

4000

4000

最大 54000 キューの内 8,000

プレシジョン キュー手順

10,000

10,000

10,000

NA

プレシジョン キューごとのプレシジョン キュー期間

10

10

10

NA

プレシジョン キューごとのプレシジョン ステップ

10

10

10

NA

プレシジョン キューごとの一意の属性

10

10

10

NA

チームごとの独自スキルの最大数

50

50

50

NA

設定済みラベル

100,000

100,000

160,000

160,000

各システム上のプレシジョン ルーティング属性

10,000

10,000

10,000

NA

各エージェントのプレシジョン ルーティング属性

50

50

50

NA

スキル グループ統計情報の更新間隔

10 秒（デフォルト）

10 秒（デフォルト）

10 秒（デフォルト）

NA

PG ごとのスキル グループ

4000

4000

4000

該当なし

キュー[2]、連絡先共有グループ毎のスキル グループとプレシジョン キューの両方が含まれます。

該当なし

該当なし

該当なし

100

連絡先の共有ルール

該当なし

該当なし

該当なし

100

連絡先の共有グループ

該当なし

該当なし

該当なし

1000

[1] ほとんどの Packaged CCE トポロジでは、エージェント PG が 1 つしかないため、4000 のスキルグループしか持てません。グローバル トポロジでは リモート サイトを使用して、Packaged CCE がシステム全体で 16000 のスキル グループをサポートします。エージェント PG を配置する 各 リモート サイト は、4,000 のスキル グループを追加します。最大 16,000 には、 3 リモート サイトを必要とします。

[2] これは

Related Concepts

エージェントあたりのスキル グループとプレシジョン キューに対する動的制限

サイレント モニタリング

サイレント モニタリングを使用すると、スーパーバイザはチーム内のエージェントの会話をモニタできます。スーパーバイザは会話に積極的に参加できず、エージェントと発信者はモニタされていることに気づきません。Cisco Finesse は、サイレント モニタリングのためのソリューション サポートを提供します。

Cisco Finesse は、Unified Communications Silent Monitoring のみをサポートしています。サイレント モニタリングは Unified Communications Manager で設定します。Cisco Finesse サーバでの追加設定は不要です。

Note

G.711 を使用するように設定されている地域でも、Unified CCE は、G.722 をサポートするデバイス向けのデフォルトコーデックとして、G.722 を使用します。ただし G.722 は、Unified Communications Manager に基づくサイレント モニタリングとコール録音ではサポートされません。このデフォルトを無効にするには、Unified Communications Manager Administration で [エンタープライズ パラメータ（Enterprise Parameters）] に移動し、[G.722 コーデックのアドバタイズ（Advertise G.722 Codec）] を無効に設定します。

Note

音声ストリームが暗号化されている場合、サイレント モニタリングは正しく機能しません。音声ストリームのキャプチャは可能ですが、サイレント モニタリング サービスはそれらを正しくデコードできません。

Related Concepts

サイレント モニタリングの設計上の考慮事項