Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン （SRND）

基本的な Unified CCE コールおよびメッセージのフロー

図 1-2 は Unified IP IVR を使用する基本的な Unified CCE コールのフローを示しています。このシナリオでは、コールが着信したときにすべてのエージェントが「受信不可」であると見なされているため、コールは ICM によって Unified IP IVR にルーティングされます。コールが Unified IP IVR に接続されると、コールのキューイング処理（応答メッセージ、音楽など）が提供されます。エージェントが受信可能になると、ICM が Unified IP IVR に対して、そのエージェントの電話にコールを転送するように指示します。コールの転送と同時に、ICM は Automatic Number Identification（ANI; 発信者番号）や Directory Number（DN; ディレクトリ番号）、CTI やコール データの変数などの発信者データをエージェント デスクトップ ソフトウェアに送信します。

図 1-2 Unified IP IVR を使用する基本的な Unified CCE コール フロー

図 1-2 のコール フローは、次のように処理されます。

1. PSTN から音声ゲートウェイへコールが配信される。

2. 音声ゲートウェイが Unified CM に宛先を問い合わせる。

3. ICM に JTAPI のルート要求が送信される。

4. ICM がルーティング スクリプトを実行。対応できるエージェントが見つからず、ルーティング スクリプトは Unified IP IVR のラベルを返す。

5. ICM が Unified CM にコールを Unified IP IVR に転送するよう指示する。

6. Unified IP IVR は ICM にコールが届いたことを通知する。

7. ICM は Unified IP IVR に、応答メッセージを再生するように指示する。

8. エージェントが対応可能になる（直前のコールが完了または業務に復帰した）。

9. ICM は選択したエージェントの画面にコールのデータを送信し、Unified IP IVR にはそのエージェントにコールを転送するよう指示する。

10. Unified IP IVR は指定されたエージェントの電話に VoIP 音声パスを転送する。

11. エージェントがコールに応答する。

図 1-3 は Unified CVP を使用する基本的な Unified CCE コールのフローを示しています。

図 1-3 Unified CVP を使用する基本的な Unified CCE コール フロー

図 1-3 のコール フローは、次のように処理されます。

1. PSTN から入力音声ゲートウェイへコールが配信される。

2. 音声ゲートウェイが着信コール用の SIP または H.225 要求を Unified CVP に送信する。

3. Unified CVP がルート要求を Unified ICM に送信して指示を要求する。

4. Unified ICM がルーティング スクリプトを実行して、Unified CVP にプロンプトとアナウンスを指示する。

5. エージェントが対応可能になる（直前のコールが完了または業務に復帰した）。

6. Unified CM 上の応答可能なエージェントにコールを送信するように、Unified ICM が Unified CVP に指示する。

7. 選択されたエージェントの画面に Unified ICM がコール データを送信する。

8. Unified CVP が Unified CM 上の指定されたエージェントの電話機に VoIP 音声パスを転送する。

9. エージェントがコールに応答する。

Unified ICM ソフトウェア モジュール

Cisco Unified ICM ソフトウェアは、複数のサーバ上で稼動可能なモジュールの集合です。1 台のサーバ上で稼動可能なソフトウェアの数は、主に、Busy Hour Call Attempt（BHCA; 最頻時発呼数）および使用されているサーバのサイズ（CPU がシングル、デュアル、クアッドのいずれであるか）によって異なります。ハードウェアのサイジングに影響を与える他の要因としては、エージェントの人数、各エージェントのスキルの数、Unified IP IVR ポートの数、ICM ルーティング スクリプト内の VRU スクリプト ノードの数、Extended Call Context（ECC; 拡張コール コンテキスト）の使用状況、およびエージェントがデスクトップで必要とする統計情報エージェントの種類があります。

Unified ICM ソフトウェアのコア モジュールは次のとおりです。

• Call Router

• Logger

• エージェント ペリフェラル ゲートウェイ（PG）

• Unified CM ペリフェラル インターフェイス マネージャ（PIM）

• IP IVR または CVP VRU PIM

• CTI サーバ

• CTI Object Server（CTI OS）

• アドミン ワークステーション（AW）またはリアルタイム ディストリビュータ

• Historical Data Server（HDS）

• WebView Reporting Server

Call Router は、コールまたは顧客からのコンタクトのルーティング方法に関するすべての決定を行うモジュールです。Logger は、コンタクト センターの設定およびレポート データを保存するデータベース サーバです。Unified CM PIM は、JTAPI プロトコルで Unified CM クラスタとのインターフェイスを処理するプロセスです。VRU PIM は、Service Control Interface（SCI）プロトコルで Unified IP IVR または Unified CVP とのインターフェイスを処理するプロセスです。CTI サーバは、CTI OS（エージェント デスクトップが接続する CTI Object Server）とのインターフェイスを処理するプロセスです。

ICM の各ソフトウェア モジュールは冗長構成で展開できます。モジュールを冗長構成で展開した場合、双方をサイド A およびサイド B と呼びます。たとえば、Call Router A および Call Router B は、2 つの異なるサーバ上で稼動する Call Router モジュール（プロセス）の冗長インスタンスです。この冗長設定はデュプレックス モードとも呼ばれ、非冗長設定はシンプレックス モードで稼動しているといいます。プロセスがデュプレックス モードで稼動している場合、ロード バランシングは行われていません。サイド A とサイド B は、両方とも同じメッセージ セットを実行しています。そのため、同じ結果が生成されます。この設定では、論理的には Call Router は 1 つだけに見えます。Call Router は 2 台のサーバで同期して実行されます。つまり、すべてのコールは、二重サーバの両サイドで処理されています。障害発生時には、リアルタイムかつユーザの介入なしで、障害が発生していない方の Call Router がコールを途中から引き継いで処理を続行します。

ペリフェラル ゲートウェイなどの ICM の他のコンポーネントはホットスタンバイ モードで実行されます。つまり、1 台のペリフェラル ゲートウェイだけが実際にアクティブになって、Unified CM または IVR を制御します。アクティブ側に障害が発生すると、障害が発生していない側が自動的にアプリケーションの処理を引き継ぎます。障害発生中、障害が発生していない側はシンプレックス モードで実行されているといい、冗長またはデュプレックス側のサービスが回復されるまで同じモードで動作し続けます。その後、デュプレックス動作に自動的に戻ります。

このアーキテクチャのもう 1 つの重要なコンポーネントは、Historical Data Server（HDS）です。HDS は、HDS オプションを使用してリアルタイム ディストリビュータをインストールすることによってインスタンス化されます。これにより、HDS で Logger から同期される履歴レポーティング データベースを維持することが可能となり、Logger で限られたレコード群を維持して最適な運用を実現できます。HDS は、HDS ごとに n+1 のスケーラビリティ アーキテクチャに従い、Logger 側（A または B）を優先的かつプライマリなデータ ソースとして選択します。HDS は、WebView または Unified Intelligence Suite による履歴レポーティングに必須のコンポーネントです。WebView は、HDS と共存させるか、またはスタンドアロン Web サーバ モードで展開して、リアルタイムおよび履歴レポーティングのためにアプリケーションにアクセスする必要があるレポーティング ユーザについての高いスケーラビリティを実現できます。詳細については、「Unified CCE のコンポーネントとサーバのサイジング」の章を参照してください。

Unified ICM ソフトウェアでは、1 つの Call Router と Logger またはセントラル コントローラのすべてのコンポーネントをグループ化するために顧客インスタンスという概念を使用します。このインスタンスの関連付けによって、同じシステムに関係するすべてのコンポーネントが 1 つの論理的な Unified CCE IP ACD に確実にまとめられます。この概念は、複数の顧客インスタンスを管理するマルチテナント サーバや共有サーバをサポートする Unified Contact Center Hosted（Unified CCH）で複数の顧客インスタンスをサポートするためだけに使用します。Unified CCE のすべてのシステムは、すべての Unified ICM コンポーネントの間で 1 つのインスタンスとして（同じインスタンス番号を ICM 設定で使用して）展開されます。

Router と Logger の組み合わせは、ICM セントラル コントローラとも呼ばれます。Router と Logger の各モジュールが同一サーバ上で稼動している場合、そのサーバは Rogger と呼ばれます。Call Router、Logger、ペリフェラル ゲートウェイの各モジュールが同一サーバ上で稼動している場合、そのサーバは Progger と呼ばれます。ラボ環境では、システムの Administrative Workstation（AW; アドミン ワークステーション）も Progger にロードして Sprawler 設定と呼ばれるサーバを作成できます（Unified System CCE のオールインワン設定とも呼ばれます）。ただし、この設定を使用できるのはラボ環境だけで、顧客の本稼動環境ではサポートされていません。

Unified CCE 環境内の Unified CM クラスタごとに、独立したペリフェラル ゲートウェイおよび物理サーバ上に Unified CM PIM が 1 つ必要です。同じ Unified CM クラスタに対して複数の PIM が必要な展開では、PIM ごとに独立した PG および物理サーバが必要です。Unified CCE 7.5 から、複数の Unified CM PIM と CTI OS を使用する展開では、独立した PG または独立した物理サーバは不要になります。

各 Unified CM ペリフェラル ゲートウェイには、その Unified CM クラスタの電話と関連付けられたデスクトップと通信するための CTI サーバと CTI OS が 1 つずつ必要です。各 Unified IP IVR または CVP コール サーバには、対応する VRU PIM が 1 つずつ必要です。Unified CM PIM、CTI サーバ、および CTI OS を稼動させているサーバは、Agent Peripheral Gateway（APG; エージェント ペリフェラル ゲートウェイ）と呼ばれます。Generic PG または System PG の場合、VRU PIM を Agent PG の一部にすることもできます。多くの場合、Unified CM PIM、CTI サーバ、CTI OS、および複数の VRU PIM は、同一サーバ上で稼動します。PG 内部は PG エージェントと呼ばれるプロセスで、セントラル コントローラへの通信を行います。PG の内部プロセスとしては、この他に Open Peripheral Controller（OPC; オープン ペリフェラル コントローラ）があります。これは他のプロセスの相互通信を可能にするとともに、冗長な PG 展開における各 PG の同期化にも関係しています。図 1-4 に、さまざまな PG ソフトウェア プロセス間の通信を示します。

図 1-4 ペリフェラル ゲートウェイ ソフトウェア プロセス間の通信

より大きな複数サイト（複数クラスタ）の環境では、通常は複数の PG が展開されます。各 PG には Unified CM のローカル ノードが必要です。ICM ソフトウェアの機能により、複数の Unified CM クラスタを展開している場合でもすべてのクラスタが統合された単一のエンタープライズ コンタクト センターとして取り扱うことができ、キューもエンタープライズ全体で 1 つと見なして処理できます。

Unified CCE エージェント オプション

Unified CCE エージェント用のインターフェイスとして、シスコでは次のインターフェイスを提供しています（図 1-5 を参照）。

• Cisco Agent Desktop

Cisco Agent Desktop は、Unified CCE 用のすぐに使用できる多機能なデスクトップ ソリューションを提供します。このデスクトップ アプリケーションは、さまざまな方法で展開できます。

– Windows アプリケーション

– ブラウザベースのアプリケーション

– Cisco Unified IP Phone Agent。デスクトップ アプリケーションは存在せず、XML アプリケーションだけが IP 電話上に存在します。

• Cisco Toolkit

CTI Toolkit は、カスタム デスクトップ、サードパーティ アプリケーションへのデスクトップ統合、またはサードパーティ アプリケーションへのサーバ間統合を構築するためのソフトウェア ツールキットを提供します。

• CRM Connector

CRM Connector は、SAP、Siebel、Salesforce、Microsoft CRM、Peoplesoft などの主要な CRM アプリケーションへのビルド済みの統合を提供します。

図 1-5 Unified CCE のさまざまなエージェント インターフェイス

Cisco Agent Desktop

Cisco Agent Desktop（CAD）はすぐに使用できるデスクトップ アプリケーションです。エージェントはこのアプリケーションを使用して、エージェントの状態の制御（ログイン、ログアウト、受信可、受信不可、ラップアップなど）およびコール制御（応答、リリース、保留、復帰、転送、会議、発信など）を行います。CAD では Cisco Unified IP Phone または Cisco IP Communicator（ソフトフォン）の使用が必須になります。Mobile Agent オプションを使用することで、他の電話も使用できます（詳細については、「Cisco Unified Mobile Agent」を参照してください）。統合チャット アプリケーション、通話録音、ワークフローの自動化など、他の機能が含まれている場合もあります（図 1-6 を参照）。

図 1-6 Cisco Agent Desktop

CAD を使用するコンタクト センターのエージェントおよびスーパーバイザは、Cisco Unified Presence との統合を通じて、Cisco Unified Presence Communicator を使用する Subject Matter Expert（SME; 専門分野のエキスパート）を確認できます。SME とのチャット セッションを開始してお客様のさまざまな質問や問題に関する助言を求めたり、必要に応じて、転送や会議を開始して、最初のコールでの解決率を高めたりすることができます。エージェントまたはスーパーバイザは、インスタント メッセージングを使用して受信したコール データを拡張する機能も有します。

CAD には、シン クライアント アプリケーションとしてのブラウザベース版もあります。このブラウザベース版は、より柔軟な展開を可能にし、前述したものと同じ豊富な機能セットを使用して機能します。

CAD はまた、デスクトップ アプリケーションを必要としないエージェント インターフェイスとして、IP Phone Agent を提供します。IP Phone Agent は、IP 電話の画面に表示される XML アプリケーションとして実装されており、IP 電話のボタンとソフトキーで操作します。この XML アプリケーションがエージェントの状態制御を担当し、コール制御は通常の IP 電話のボタンとソフトキーによって処理されます。サイレント モニタリング、通話録音、スクリーン ポップ、コール センター統計情報などの拡張機能も、このインターフェイスで利用できます。

Cisco Agent Desktop、Cisco Agent Desktop ブラウザ版、または IP Phone Agent を使用するエージェントは、Cisco Supervisor Desktop を使用するスーパーバイザによる管理が可能です。スーパーバイザは Cisco Supervisor Desktop を使用して、エージェント状態のモニタリングと制御、コール センター統計情報のモニタリング、エージェントのサイレント モニタリング、介入、代行受信、エージェントの通話録音などを実行できます。

Cisco Toolkit

Cisco Toolkit は、カスタマイズされたエージェント デスクトップの構築、付属のカスタム デスクトップ サンプルのカスタマイズ、またはサードパーティ アプリケーションへのツールバーの統合のための機能を提供する、ソフトウェア開発キットです。CTI Toolkit を使用して構築されたデスクトップ アプリケーションは、CTI Object Server（CTI OS）と対話します。CTI Toolkit で使用可能な API には、COM/C++、Java、および .NET が含まれます。Cisco Toolkit Desktop でも、CAD と同様のエージェント状態制御およびコール制御を実行できます。Cisco Toolkit Desktop では Cisco Unified IP Phone または Cisco IP Communicator（ソフトウェア電話）の使用が必須になります。Mobile Agent オプションを使用することで、他の電話も使用できます（詳細については、「Cisco Unified Mobile Agent」を参照してください）。

Cisco Toolkit はまた、カスタム スーパーバイザ デスクトップを開発する機能も提供します。スーパーバイザはスーパーバイザ向けの機能を使用して、エージェント状態のモニタリングと制御、一部のコール センター統計情報のモニタリング、エージェントのサイレント モニタリング、介入、代行受信、エージェントの通話録音などを実行できます。なお、CTI Toolkit に基づくスーパーバイザ デスクトップを使用するスーパーバイザは、Cisco Agent Desktop を使用するエージェントに対して、これらの機能を実行できません。

「CTI Object Server（CTI OS）」に関する項で、CTI Toolkit のコンポーネントとインターフェイスについてさらに詳しく説明します。

CRM Connector

シスコでは、SAP、Siebel（CTI OS ドライバを使用）、Salesforce.com、Microsoft Dynamics CRM、Peoplesoft などの多数の主要な CRM パッケージ用に、ビルド済みの認定 CRM Connerctor を提供しています。これらの統合されたソリューションにより、CRM ユーザ インターフェイスからのコール制御（応答、ドロップ、保留、保留解除、ブラインド転送またはウォーム転送、および会議）、CRM デスクトップからのアウトバウンドのコンサルテイティブ コール、ならびにコール コンテキスト データ（CTI スクリーン ポップ）の配信および操作が可能になります。

CRM Connector を通じて接続されたサードパーティ CRM ユーザ インターフェイスを使用するエージェントは、CTI Toolkit ベースのスーパーバイザ デスクトップを使用して管理できます。

デスクトップの選択および設計上の注意点の詳細については、「Unified Contact Center Enterprise Desktop」を参照してください。

CTI Object Server（CTI OS）

Computer Telephony Integration Object Server（CTI OS）は、シスコの次世代カスタマー コンタクト統合プラットフォームです。CTI OS には、強力な多機能サーバと複雑な CTI アプリケーションの迅速な開発と展開を可能にするオブジェクト指向のソフトウェア開発ツールが統合されています。Cisco CTI サーバ インターフェイス、CTI OS サーバ、CTI OS Client Interface Library（CIL）が、高性能でスケーラブルで耐障害性にすぐれた CTI アーキテクチャを実現しています。

CTI OS アプリケーション アーキテクチャは、次に示す 3 つの層で構成されています。

• 最初の層は CIL で、開発用のアプリケーションレベル インターフェイスを提供しています。CLI は、前述した CTI Toolkit に含まれています。

• 2 番目の層は CTI OS サーバで、イベントと要求の大半を処理して CTI OS システムのオブジェクト サービスを可能にしています。

• 3 番目の層は Cisco CTI サーバで、イベント ソースの提供とテレフォニー要求のバックエンド処理を行っています。CTI OS サーバは、CTI サーバに接続してイベントと要求を処理します。CTI サーバはまた、CTI 統合用のオープンな公開済みプロトコルを提供します。これは、サーバ間統合に便利な場合があります。Cisco CTI サーバも CTI Toolkit に含まれています。

同時に稼動して互いにバックアップする 1 対のサーバを使用して耐障害性が実現されています。アクティブやパッシブまたはプライマリやセカンダリという概念はこれらのサーバにはありません。両方のサーバが常にアクティブになっています。クライアントはどちらのサーバにも接続できます。いずれかのサーバに障害が発生した場合、クライアントは自動的に代替サーバに再接続できます。

CTI OS は、クライアント アプリケーションが動作している CTI サーバなどのカスタマー コンタクト サーバに接続します（図 1-7 を参照）。コンタクト サーバに対する接続は CTI サーバ ドライバ ライブラリを使用して確立されます。このライブラリはエージェントの状態変更イベントとコールを受信します。これらのイベントは Service Broker に送られて、どのオブジェクトを更新するかを Service Broker が決定します。これらのオブジェクトでは Event Notification Engine に対する更新イベントが生成されて、次に Event Notification Engine によって、サブスクライブしているすべてのクライアントに通知されます。

図 1-7 CTI OS の情報フローの概要

クライアント アプリケーションが受信するメッセージのタイプは接続モードによって異なります。クライアントはエージェント モードかモニタ モードのどちらかで接続できます。エージェント モードでは、そのエージェント特有のイベント（エージェントの機器で受信または発信されたコール、エージェントの状態変更、およびスキル グループの統計情報）をクライアントが受信します。モニタ モードでは、メッセージ フィルタの式をクライアントが設定し、その式に従ってクライアントが受信するメッセージのタイプが選択されます。

クライアントはコールの応答や廃棄などを要求できます。この要求はクライアント接続インターフェイス経由で CTI OS が受信します。要求を正しいオブジェクトに転送する要求サービスによって要求がブローカ処理され、次にそのオブジェクトが要求を CTI サーバに転送します。

アドミン ワークステーション

アドミン ワークステーション（AW）は、ICM ソフトウェアの設定を管理する管理ツールの集合を提供します。AW の 2 つの主要な設定ツールは、コンフィギュレーション マネージャとスクリプト エディタです。コンフィギュレーション マネージャ ツールは、ICM データベースを設定して、エージェントの追加、スキル グループの追加、エージェントのスキル グループへの割り当て、着信番号の追加、コール タイプの追加、着信番号のコール タイプへの割り当て、コール タイプの ICM ルーティング スクリプトへの割り当てなどを行うために使用します。スクリプト エディタ ツールは、ICM ルーティング スクリプトの作成に使用します。ICM ルーティング スクリプトは、コンタクトのルーティングおよびキューイングの方法を指定します（スクリプトによって、特定のコンタクトを処理するエージェントを指定します）。

これらのツールの使用方法の詳細については、次の URL で入手できる『 Cisco Unified Contact Center Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_maintenance_guides_list.html

AW は、他のすべての Unified CCE ソフトウェア モジュールとは別のサーバで稼動させる必要のある唯一のソフトウェア モジュールです。AW は、ICM セントラル コントローラと同じ場所または別の場所に展開できます。各 AW はそれぞれ独立しており、複数の AW を展開することで冗長性を実現できます。

ICM セントラル コントローラと直接通信する AW もあり、これらはディストリビュータ AW と呼ばれます（図 1-8 を参照）。ICM 環境には、ディストリビュータ AW が 1 つ以上必要です。AW（ディストリビュータまたはクライアント）を追加すると、冗長性（プライマリおよびセカンダリ ディストリビュータ）の実現や、サイトの AW クライアントによるアクセス増加も可能になります。他のサイトでも、1 つ以上のディストリビュータと複数のクライアント AW を展開できます。ただし、クライアント AW は常に AW ディストリビュータと同一システム上に配置する必要があります。

図 1-8 ICM セントラル コントローラとディストリビュータ AW 間の通信

クライアント AW はディストリビュータ AW と通信して、ICM セントラル コントローラ データベースの表示と変更、およびリアルタイム レポート データの受信を行います。セントラル コントローラ（リアルタイムのコール処理エンジン）は、ディストリビュータ AW によって、リアルタイムのコンタクト センター データをクライアント AW に常に配布するというタスクから解放されます。

AW は次のソフトウェア オプションとともにインストールできます。

• Historical Data Server（HDS）

• WebView サーバ

• Internet Script Editor Server

• Web Administration Tool Server（Unified System CCE 展開だけ）

Historical Data Server（HDS）は、長期間のデータの保存とレポーティングに使用するデータベースです。WebView サーバは、レポーティング サーバで、HDS サーバかスタンドアロン サーバのどちらかにインストールできます。レポーティングの展開オプションの詳細については、「Unified CCE のコンポーネントとサーバのサイジング」と「Unified CCE のセキュリティ管理」を参照してください。

WebView サーバ オプションでは、ブラウザ ベースのレポートを作成できます。このオプションを選択すると、ブラウザ機能のあるすべてのコンピュータからレポートを作成できます。Internet Script Editor Server をインストールできるのはディストリビュータ AW だけです。Script Editor のクライアントはこのサーバに HTTPS（デフォルト プロトコル）で接続できます。Web Administration Tool Server は、Unified System CCE 用のブラウザベースの設定ツールを提供し、ディストリビュータ AW（Unified System CCE では、管理と WebView レポーティング サーバと呼ばれます）でだけインストール可能です。

AW を本稼動システムと別のサーバで稼動させるのは、複雑なレポーティング クエリーによって、Call Router や Logger のプロセスのリアルタイム コール処理が中断されないようにするためです。ラボやプロトタイプのシステムの場合は、（WebView サーバ オプションが設定された）AW を Call Router や Logger と同一のサーバにインストールできます。AW を Logger と同一のサーバにインストールすると、Logger データベースの完全コピーがすでにサーバ上に存在するため、HDS は不要になります。

AW の設計および設定の詳細については、www.cisco.com/jp/ で入手できる ICM 製品オンライン マニュアルを参照してください。

Unified CCE のレポーティング

Unified CCE レポーティング ソリューションは、システムの履歴状態とリアルタイム状態を示すデータにアクセスするためのインターフェイスを提供します。このレポーティング ソリューションは、次のコンポーネントで構成されています。

• WebView：レポーティングのユーザ インターフェイス

• レポーティング データ：ディストリビュータ AW に格納

– アドミン ワークステーション データベース（AWDB）：リアルタイム データと設定データを格納

– Historical Data Server（HDS）：履歴データを格納

WebView

レポーティングのユーザ インターフェイスは、WebView と呼ばれる Web ベースのアプリケーションです。WebView は、ユーザ入力の収集、データベースの照会、および要求されたデータの表示を行います。さらに、WebView は、認証、ユーザのお気に入りレポートの保存、スケジュールされたレポートの起動などを行う、フル機能のレポーティング サーバでもあります。WebView は AW にインストールすることも、スタンドアロン サーバにインストールしてスケーラビリティを高めることもできます。WebView のアーキテクチャについては、次の URL で入手できる『 WebView Installation and Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_installation_guides_list.html

WebView には、多くのカテゴリのレポート テンプレートが提供されています。各カテゴリには、コール センターのアクティビティで生成されたデータがさまざまなビューで表示されます。どのテンプレートがレポーティング要件を満たすのに最適かを判断するには、次の URL にある『 WebView Template Reference Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/products_user_guide_list.html

Cisco Unified Intelligence Suite

Cisco Unified Intelligence Suite は、WebView の代わりに、または WebView と組み合わせて使用できる高度なレポーティング オプションです。このプラットフォームは、Web ベースのアプリケーションであり、多数の Web 2.0 機能、高いスケーラビリティ、優れたパフォーマンス、および他の Cisco Unified Communications 製品またはサードパーティ データ ソースからのデータを統合する機能などの高度な機能を提供します。

Cisco Unified Intelligence Suite は、Intelligence Server および Archiver の 2 つのコンポーネントで構成されます。これらのコンポーネントには、いずれも独立した専用のサーバが必要です。

Intelligence Server は、Web ベースのレポーティング アプリケーションであり、リアルタイム レポートおよび履歴レポートとダッシュボードに加えて、プラットフォームの拡張とユーザ エクスペリエンスのカスタマイズのためのいくつかの開発者向けツールを提供します。

Archiver は、正規化されたデータ スキーマとテーブルおよびプロセスのインフラストラクチャを含む MSSQL データ リポジトリであり、お客様が任意のデータ ソースからのデータの Extract, Transform, and Load（ETL; 抽出、変換、書き出し）を行うことを可能にします。

データ ソースごとに固有の ETL プロセスが作成され、それらの ETL プロセスはデータ コネクタと呼ばれます。データ コネクタの詳細については、Archiver のインストールおよびコンフィギュレーション ガイドを参照してください。

レポーティング データ

WebView レポートのデータ ソースはディストリビュータ AW にあります。レポーティングのデータ フローとここで説明した概念の詳細については、次の URL で入手できる『 WebView Installation and Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/prod_installation_guides_list.html

アドミン ワークステーション データベース（AWDB）

AWDB にはリアルタイム データと設定データが格納されます。リアルタイム レポートには、これら 2 種類のデータが統合されて、現在の状況に近いシステムの一時的なスナップショットが表示されます。リアルタイム レポートは定期的に更新されるので最新のデータが常に表示されます。

Historical Data Server（HDS）

HDS には履歴データが保存されます。履歴レポートでは、AWDB にクエリーを実行して設定データが集められ、そのデータと HDS 内のデータが統合されます。履歴レポートには、一般的に 30 分ごとに生成されるレポートと 1 日 1 回生成されるレポートの 2 つの形式があります。30 分ごとのレポートは 1 日より短い期間のレポートに使用します。

Unified Contact Center Management Portal

Unified Contact Center Management Portal は、使いやすい Web ベースのユーザ インターフェイスを提供して、コンタクト センターのマネージャ、チーム リーダー、または管理者が実行する日常のプロビジョニング作業と構成作業を合理化します。この管理ポータルは、次の主要な利点を提供します。

• 電話、エージェント、スキル グループ、チーム、および IP コンタクト センターの他の一般的なコンタクト センター管理機能の移動、追加、変更などの基本的なタスクを実行するための、使いやすい Web ユーザ インターフェイス。

• 統一された構成。つまり、1 つのタスク ベースの Web インターフェイスによる、該当する IP コンタクト センター要素と Unified Communications Manager コンポーネントの両方のテナント プロビジョニング。

• 完全な自主性を備えた複数のビジネスユニットをサポートするパーティション システム。

• 複数のビジネスレベル ユーザをサポートする階層型管理。各ユーザは、特定の役割および責任により定義されます。

• 管理ポータルのすべてのユーザによる構成変更および使用方法を詳細に示す監査証跡レポート。

Support Tools

Cisco Support Tools は、幅広い Cisco Unified 製品ソフトウェア コンポーネントを実行するサーバの管理およびトラブルシューティングを行うための一連のユーティリティを含むアプリケーションです。Support Tools を通じて、これらのシステムの構成およびパフォーマンスの問題を、Support Tools Server にアクセスできるネットワーク上のサポート対象の Windows および Internet Explorer のバージョンを実行する任意のマシンからトラブルシューティングすることが可能です。

Support Tools スイート内のユーティリティには、Support Tools Server にインストールされるブラウザベース インターフェイスである、Support Tools Dashboard を通じてアクセスします。セキュリティのレベルにより、Dashboard へのアクセスと、ログイン後に特定のツールを使用する能力が制御されます。帯域幅が低い場合（たとえば、ダイヤルアップ アクセスを使用する場合）や、その他の理由で Web ブラウジングが現実的ではない場合は、コマンド ライン インターフェイスを通じて多数の Support Tools ユーティリティにアクセスし実行することもできます。

JTAPI 通信

Cisco Unified CM と、Unified CCE や Unified IP IVR などの外部アプリケーションの間で JTAPI 通信を行うには、JTAPI のユーザ ID とパスワードを Unified CM 内で設定する必要があります。Unified CM PIM または Unified IP IVR の始動時に、JTAPI のユーザ ID とパスワードを使用して Unified CM にログインします。アプリケーション（Unified CM PIM または Unified IP IVR）によるログイン プロセスによって、Unified CM クラスタとそのアプリケーションとの JTAPI 通信が確立されます。Unified CM クラスタ全体と ICM の間のすべての通信で、1 つの JTAPI ユーザ ID を使用します。各 Unified IP IVR サーバ用には別の JTAPI ユーザ ID も必要です。1 つの Unified CM クラスタと 2 つの Unified IP IVR を含む Unified CCE 展開では、3 つの JTAPI ユーザ ID（ICM アプリケーション用に 1 つの JTAPI ユーザ ID、2 つの Unified IP IVR 用に 2 つの JTAPI ユーザ ID）が必要です。

Unified CM ソフトウェアには、CTI Manager と呼ばれるモジュールが含まれています。これは、JTAPI 経由で ICM や Unified IP IVR などのアプリケーションと通信するソフトウェアのレイヤです。クラスタ内の各ノードは、CTI Manager のプロセスのインスタンスを実行できますが、PG 上の Unified CM PIM は、Unified CM クラスタの 1 つの CTI Manager（つまり 1 つのノード）とだけ通信します。CTI Manager のプロセスは、クラスタ内の他のノードと CTI メッセージの受け渡しを行います。たとえば、クラスタのノード 1 に音声ゲートウェイがあり、ノード 2 が CTI Manager のプロセスを実行して ICM と通信すると仮定します。新しいコールがこの音声ゲートウェイに届き、ICM によってルーティングされる必要があると、ノード 1 はクラスタ内メッセージをノード 2 に送信します。これによってルート要求が ICM に送信され、ICM がコールのルーティング方法を決定します。

各 Unified IP IVR も、クラスタ内の 1 つの CTI Manager（またはノード）とだけ通信します。前述の例の Unified CM PIM と 2 つの Unified IP IVR は、それぞれ別の CTI Manager（ノード）と通信することも、すべてが同一の CTI Manager（ノード）と通信することも可能です。ただし、各通信では異なるユーザ ID を使用します。このユーザ ID により、CTI Manager は異なるアプリケーションを追跡します。

Unified CM PIM が冗長構成の場合、1 つのサイドだけがアクティブになり、Unified CM クラスタと通信します。Unified CM PIM のサイド A とサイド B は、それぞれ異なる Unified CM ノードの CTI Manager と通信します。Unified IP IVR には冗長なサイドはありませんが、Unified IP IVR には、プライマリ CTI Manager がアウト オブ サービスのときにクラスタ内の別の CTI Manager（ノード）にフェールオーバーする機能があります。フェールオーバーの詳細については、「アベイラビリティを高めるための設計上の注意点」の章を参照してください。

Unified CM と Unified CCE の間の JTAPI 通信には、次の 3 種類のメッセージ タイプが含まれます。

• ルーティング制御

ルーティング制御メッセージは Unified CM に、Unified CCE からルーティング方法を要求する手段を提供します。

• デバイスとコールの監視

デバイス監視メッセージは Unified CM に、デバイス（電話）またはコールの状態の変更を Unified CCE に通知する手段を提供します。

• デバイスとコール制御

デバイス制御メッセージは Unified CM に、デバイス（電話）またはコールの制御方法に関する指示を Unified CCE から受け取る手段を提供します。

一般的な Unified CCE コールは、数秒間でこの 3 種類すべての JTAPI 通信を含みます。新しいコールが届くと、Unified CM は ICM に対してルーティング方法を要求します。たとえば、Unified CM が ICM からルーティング応答を受け取ると、Unified CM はエージェントの電話を呼び出してコールをエージェントの電話に配信しようとします。この時点で Cisco Unified CM は ICM に、デバイス（電話）が呼び出しを始めたことと、それにともないデスクトップ アプリケーションのエージェントの [Answer] ボタンが使用可能になったことを通知します。エージェントが [Answer] ボタンをクリックすると、ICM が Unified CM にデバイス（電話）をオフ フックにしてコールに応答するよう指示します。

ルーティング制御の通信を行わせるために、Unified CM は CTI ルート ポイントの設定を要求します。CTI ルート ポイントは特定の JTAPI ユーザ ID と関連付けられ、この関連付けによって、Unified CM はどのアプリケーションがその CTI ルート ポイントにルーティング制御を提供しているかを認識できます。その後で Directory (Dialed) Number（DN; ディレクトリ番号）が CTI ルート ポイントに関連付けられます。DN が、ICM JTAPI ユーザ ID と関連付けられた CTI ルート ポイントに関連付けられ、これによって Unified CM は、その DN にコールが届いたときに ICM にルート要求を送信できます。

電話の監視および制御を可能にするには、それらの電話を Unified CM で JTAPI ユーザ ID と関連付ける必要もあります。Unified CCE 環境では、IP 電話は ICM JTAPI ユーザ ID と関連付けられます。エージェントがデスクトップからログインすると、Unified CM PIM は Unified CM に対し、PIM がその電話の監視および制御を開始することを許可するよう要求します。ログインが行われるまで、Unified CM は ICM にその電話の監視または制御を許可しません。デバイスが ICM JTAPI ユーザ ID に関連付けられていないと、エージェントのログイン要求は失敗します。

Unified IP IVR も同じ JTAPI プロトコルを使用して Unified CM と通信するため、この 3 種類の通信タイプは Unified IP IVR でも発生します。ICM とは異なり、Unified IP IVR はアプリケーションそのものと、監視および制御されるデバイスの両方を提供します。

ICM が監視および制御するデバイスは、物理的な電話です。Unified IP IVR には従来の IVR のような実際の物理ポートはありません。Unified IP IVR のポートは論理ポート（Unified IP IVR アプリケーション サーバ上で稼動する独立したソフトウェア タスクまたはスレッド）で、CTI ポートと呼ばれます。Unified IP IVR 上の各 CTI ポートごとに、Unified CM で CTI ポート デバイスを定義する必要があります。

従来の PBX やテレフォニーのスイッチとは異なり、Unified CM はコールの送信先となる Unified IP IVR ポートを選択しません。その代わり、Unified IP IVR JTAPI ユーザに関連付けられた CTI ルート ポイントに関連付けられた DN にコールを行う必要がある場合、Unified CM は Unified IP IVR に（JTAPI ルーティング制御経由で）、どの CTI ポート（デバイス）でコールを処理するかを確認します。Unified IP IVR に使用可能な CTI ポートがあれば、Unified IP IVR は Unified CM のルーティング制御要求に対して、そのコールを処理する CTI ポートの Unified CM のデバイス識別子で応答します。

使用可能な CTI ポートがコールに割り当てられたら、Unified IP IVR ワークフローが Unified IP IVR 内で開始されます。Unified IP IVR ワークフローが承認手順を実行すると、CTI ポート（デバイス）に代わってコールに応答する JTAPI メッセージが Unified CM に送信されます。Unified IP IVR ワークフローでコールの転送またはリリースが必要になった場合、JTAPI メッセージが再度 Unified CM に、コールに対する処理の内容を指示します。これらのシナリオは、Unified IP IVR が実行するデバイスとコール制御の例です。

発信者が Unified IP IVR と対話しながらコールをリリースすると、音声ゲートウェイは発信者がリリースしたことを検出します。続いて H.323 または Media Gateway Control Protocol（MGCP）で Unified CM に通知し、JTAPI 経由で Unified IP IVR に通知します。音声ゲートウェイが DTMF トーンを検出すると H.245 または MGCP で Unified CM に通知し、Unified CM はこれを JTAPI 経由で Unified IP IVR に通知します。これらのシナリオは、Unified IP IVR が実行するデバイスとコールの監視の例です。

CTI ポート デバイスの制御および監視を行わせるためには、Unified CM の CTI ポート デバイスを適切な Unified IP IVR JTAPI ユーザ ID に関連付ける必要があります。150 ポートの Unified IP IVR を 2 つ所有している場合、CTI ポートは 300 あります。CTI ポートの半分（150）を JTAPI ユーザ Unified IP IVR #1 に関連付け、残りの 150 の CTI ポートを JTAPI ユーザ Unified IP IVR #2 に関連付けます。

Unified CM の設定によって、それ自体の Unified IP IVR にコールをルーティングさせることは可能ですが、Unified CCE 環境での Unified IP IVR へのコールのルーティングは、Unified IP IVR が 1 つだけで、すべてのコール要求に IVR の初期処理が必要な場合でも、ICM で行う必要があります。これによって、適切な Unified CCE レポートが保証されます。複数の Unified IP IVR を展開している場合、このルーティング手法によって、ICM は複数の Unified IP IVR 全体にコールの負荷を分散させることが可能です。

マルチチャネル サブシステム

ICM には、電子メールと Web コラボレーションを含むマルチチャネル コンタクト センターを実現する機能があります。この機能は、Cisco E-Mail Manager（CeM）および Cisco Collaboration Server（CCS）と協調動作することによって実現されています（図 1-9 を参照）。Cisco Unified CCE 7.2 から、マルチチャネル機能を提供するには、E-mail Interaction Manager（EIM）および Web Interaction Manager（WIM）を含む Cisco Interaction Manager（CIM）を新規インストールで展開する必要があります。詳細については、 http://www.cisco.com にある Unified CCE の『 Software Compatibility Guide 』を参照してください。

CeM および CCS により、ICM はマルチメディア サブシステムに使用される統合ポイントを 3 つ持つことになります。

• メディア ルーティング（MR）インターフェイス：MR インターフェイスは MR ペリフェラル ゲートウェイ（PG）経由で動作します。Cisco E-Mail Manager と Cisco Collaboration Server はこのインターフェイスを使用して、サービスが必要な新しいタスクがあり、エージェントの割り当てが必要であることを ICM に通知します。

• Agent Reporting and Management（ARM）インターフェイス：ARM インターフェイスは特定のエージェントが割り当てられている PG 上の CTI サーバ経由で動作します。Cisco E-Mail Manager と Cisco Collaboration Server は ARM インターフェイスを使用して、自分のサブシステム内のタスクをエージェントが処理していることを ICM に通知したり、ICM 内のエージェントの状態をモニタしたりします。

• Configuration Application Programming Interface（ConAPI）：ConAPI はアドミン ワークステーション（AW）経由で動作します。Cisco E-Mail Manager と Cisco Collaboration Server はこのインターフェイスを使用して、自分の設定と ICM の設定の同期が取れていることを確認します。ConAPI は、スキル グループの作成、エージェントの設定、ルーティング用の ICM サービスの作成に使用します。

図 1-9 マルチチャネル サブシステム

Cisco E-Mail Manager

Cisco E-Mail Manager は、インバウンドとアウトバウンドの電子メール サービスをエージェントに提供します。Cisco E-Mail Manager を使用すれば、着信メールをルール エンジンで処理し、処理用のフォルダに分類してエージェントにキューイングできます。エージェントに電子メールが割り当てられると、エージェントが応答できます。その際には、Cisco E-Mail Manager を使用してやりとりを保存したり、複数回の応答をトラッキングしたりできます。

Cisco E-Mail Manager には、期限が過ぎたメールの優先度を上げて、すぐに気づくように ICM ルータ経由で同期をとってルーティングする機能があります。また、一部の電子メールを自分でルーティングする機能もあります。

Cisco Collaboration Server

Cisco Collaboration Server は、Web ベースのコラボレーションとチャット機能をエージェントに提供します。これらの機能は、独立して使用することも、音声コールを補足するために使用することもできます。Cisco Collaboration Server は Media Blender コンポーネントを使用して ICM と接続します。このコンポーネントが必要になるのは、顧客からの着信接続を可能にするために Cisco Collaboration Server 自身を企業のファイアウォールの外に設置する必要があるためです。

IP ベースのエージェントに対して音声セッションとコラボレーション セッションを融合するときには、Media Blender がメディア ルーティング PG とやり取りをしながらコールをルーティングします。TDM ベースのエージェントに対して音声セッションとコラボレーション セッションを融合するときには、Media Blender が TDM スイッチと直接やり取りをして、見せかけのコールをエージェントにキューイングします。

Cisco Collaboration Server は、発信者とエージェントの両方にデスクトップ ユーザ インターフェイスを提供します。これらのコンポーネントを使用すれば、チャット、Web ページの共有、（Dynamic Content Adapter を使用した）高度な Web ページの共有、アプリケーションの共有、ホワイト ボード機能などのさまざまなメディアを使用して、発信者とエージェントがコラボレーションできます。Cisco Collaboration Server には、カスタム メディア開発用の API も提供されています。

Cisco Collaboration Server では、自分の内部ルーティング エンジンを使用することも、ICM のルーティング エンジンを使用して着信コールをエージェントに割り当てることもできます。Cisco Collaboration Server のマルチセッション チャット デスクトップを使用すれば、エージェントが複数の発信者に同時に応答することもできます。

Cisco Interaction Manager

Cisco Interaction Manager は、Cisco Unified E-mail Interaction Manager（Unified EIM）および Cisco Unified Web Interaction Manager（Unified WIM）を含む、一連の統合された対話チャネルを提供します。

Cisco Interaction Manager プラットフォーム専用の設計ガイドである『 Cisco Unified Web and E-Mail Interaction Manager Solution Reference Network Design (SRND) Guide For Unified Contact Center Enterprise, Hosted, and ICM 』を、以下で参照できます。

http://www.cisco.com/en/US/products/ps7236/products_implementation_design_guides_list.html

Cisco Unified Outbound Option

エージェントがインバウンドとアウトバウンドの両方のコンタクトを処理できれば、コンタクト センターのリソースの最適化を図ることができます。多機能コンタクト センターで Cisco Unified Outbound Option を使用すると、Cisco Unified CCE による企業管理の利点を生かすことができます。アウトバウンド キャンペーン ソリューションを必要とするコンタクト センターの管理者は、エージェント リソースの全体を管理対象にできるという Cisco Unified CCE の特長を活用できます。

Cisco Unified Mobile Agent

Cisco Unified CCE は、エージェントがエージェント デスクトップと CTI OS サーバの間で、任意の PSTN 電話と高品質な高速データ接続を利用できるようにする機能を提供します。Cisco Unified Mobile Agent の実装に関する設計ガイドおよび考慮事項については、「Cisco Unified Mobile Agent」の章を参照してください。

Unified System CCE

Cisco Unified System Contact Center Enterprise（Unified System CCE）は、Unified ICM および Unified ICM 以外の不必要な展開オプションを排除し、Unified CCE 用に事前定義された 3 つの設定を使用してインストールと設定を簡素化した展開モデルです。System Unified CCE では、新しい単一のインストーラを使用してインストールと設定を簡素化しており、Web ベースの管理も可能になっています。サービス、トランスレーション ルート、デバイス ターゲット、ラベル、サブ スキル グループ、およびエージェント ID が省略され、System Unified CCE の設定は、より簡単になっています。Unified System CCE 7.2（2）以降のリリースでは、必要に応じてエージェント ID を構成できます。

Unified System CCE は、新規インストールと、以前の System CCE リリースからのアップグレードをサポートします。セントラル コントローラとエージェント/IVR コントローラのデュプレックス運用によって、耐障害性は引き続き実現されます。Unified System CCE は親の Unified ICM に接続できます。この接続は、子の Unified CCE System PG と親の Gateway PG の間で行われます。

System Unified CCE は、図 1-10 および図 1-11 に示されている次の内部コンポーネントで構成されています。

• セントラル コントローラ：Call Router および Logger が含まれます（SQL Server が事前にインストールされている必要があります）。

• エージェント/IVR コントローラ：Agent Peripheral Gateway（Unified CCE System PG）、CTI サーバ、および CTI Object Server。Unified System CCE 7.5（1）より、オプションで Unified CVP 用の VRU ペリフェラル ゲートウェイ。

• 管理と WebView レポーティング：ディストリビュータ アドミン ワークステーション（AW）、WebView、Historical Data Server（HDS）、および Internet Script Editor Server（Microsoft Internet Information Service（IIS）および SQL Server が事前にインストールされている必要があります）。

• Unified CM：Unified System CCE は 1 組の Unified CM クラスタに接続します。

• Unified IP IVR または Unified CVP：Unified System CCE のキューイングとプロンプト処理のプラットフォーム。

• オプション コンポーネント：

– アウトバウンド コントローラ：アウトバウンド オプション用のダイヤラおよびメディア ルーティング ペリフェラル ゲートウェイ（Unified System CCE 7.5（1）では、アウトバウンド コントローラをエージェント/IVR コントローラ上に共存させることができます）。

– マルチチャネル コントローラ：Cisco Interaction Manager（CIM）用のメディア ルーティング ペリフェラル ゲートウェイ。

– Unified ICM への Unified CCE ゲートウェイ。

– Cisco Agent Desktop サービス（エージェント ペリフェラル ゲートウェイと共存）。

– Unified Contact Center Management Portal（Unified CCMP）：管理と WebView レポーティングのマシンと共存させるか、スタンドアロン サーバ上に個別にインストール。

図 1-10 Unified System CCE と IP IVR

図 1-11 Unified System CCE と Unified CVP

Unified System CCE の詳細については、「展開モデル」の章を参照してください。

デバイス ターゲット

各 IP 電話は、Unified ICM セントラル コントローラ データベースでデバイス ターゲットとして設定する必要があります。電話で Unified ICM デバイス ターゲットとして設定できる内線番号は 1 つだけです。電話で複数の内線を設定することもできますが、2 本目以降の内線は Unified ICM ソフトウェアに認識されないため、監視または制御を行うことはできません。Unified ICM はコール処理で Reroute On No Answer（RONA）を実行するため、Unified CM の電話の設定で、無応答時の自動転送を設定する必要はありません。コール センターのポリシーでウォーム（エージェントからエージェント）転送が許可されていない限り、Unified CCE 内線番号が直接発行またはダイヤルされることはなく、この Unified CCE 内線番号にコールをルーティングするのは Unified ICM ソフトウェアだけです。

エージェントがログインすると、エージェント ID と電話の内線番号が関連付けられ、この関連付けはエージェントがログアウトすると解放されます。この機能を使用すれば、エージェントが任意のエージェントの電話機にログインできます。エージェントがログインすると、Unified CM PIM が Unified CM に対し、そのエージェントの電話の監視を開始し、その電話のデバイス制御とコール制御を行うように要求します。前述のように、エージェントがログインできるようにするには、各電話を Unified ICM JTAPI ユーザ ID に対応させる必要があります。

ラベル

ラベルは、ルーティング クライアントからのルート要求に対する応答です。ラベルは、コールのルーティング先を示すポインタです（基本的に、ルーティング クライアントがダイヤルする番号）。Unified CCE 環境の多くのラベルが Unified CCE 内線番号に対応しているため、Unified CM および Unified IP IVR は、コール用に選択されたエージェントの電話に、すぐにコールをルーティングまたは転送できます。

多くの場合、コールがどのように宛先にルーティングされるかは、コールの発信元や終端先によって異なります。そのため Unified CCE ではラベルを使用します。たとえば、サイト 1 およびサイト 2 という地理的に分散した 2 つの Unified CM クラスタを含む環境があるとします。サイト 1 の電話ユーザがサイト 1 の別のユーザに電話するには、通常は 4 桁の内線番号をダイヤルするだけで済みます。サイト 1 のユーザがサイト 2 の電話ユーザに電話するには、7 桁の番号をダイヤルする必要があります。公衆電話交換網の電話からどちらかのサイトの電話ユーザに電話するには、10 桁の番号をダイヤルする必要があります。この例から、コールの発信元と終端先に応じて、どのように異なるラベルが必要になるかがわかります。

デバイス ターゲットとルーティング クライアントのそれぞれの組み合せに、ラベルを付ける必要があります。たとえば、2 ノードの Unified CM クラスタと 2 つの Unified IP IVR がある Unified CCE 環境のデバイス ターゲットには、3 つのラベルが必要です。デバイス ターゲット（電話）が 100 台ある場合は、300 のラベルが必要になります。地理的に分散した 2 つの Unified CM クラスタがあり、それぞれのサイトに 2 つの Unified IP IVR と 100 のデバイス ターゲットがある場合、6 つのルーティング クライアントと 200 のデバイス ターゲット用に 1,200 のラベルが必要です（すべてのルーティング クライアントからすべてのデバイス ターゲットにコールをルーティングできるようにすると仮定した場合）。コールをルーティング クライアントと同じサイトのデバイス ターゲットにだけルーティングする場合は、必要なラベルは 600 です（100 のデバイス ターゲットに対して 3 つのルーティング クライアントで、これをサイト 2 用に 2 倍にした数）。

ラベルは Unified IP IVR CTI ポートにコールをルーティングする際にも使用されます。ラベルの設定の詳細事項は、Cisco.com で入手できる『 Unified CCE Installation Guide 』に記載されています。ラベルの設定を容易にする一括設定ツールも利用できます。

エージェント デスク設定

エージェント デスク設定は、自動応答を有効にするかどうか、コールの無応答（RNA）時に再ルーティングするまでの待機時間、再ルーティングで使用する DN、ログアウト時や受信不可になる際に理由コードが必要かどうかなどのパラメータを指定するプロファイルを提供します。各エージェントは、Unified ICM の設定でエージェント デスク設定プロファイルと関連付ける必要があります。1 つのエージェント デスク設定プロファイルは、複数のエージェントで共有できます。エージェントのログイン中に、そのエージェントのデスク設定プロファイルを変更しても、その変更内容は、エージェントがログアウトして再度ログインするまで有効になりません。

エージェント

エージェントは Unified ICM 内で設定され、1 つの特定の Unified CM PIM（つまり 1 つの Unified CM クラスタ）と関連付けられます。Unified ICM の設定で、エージェントがログインに使用するパスワードも設定します。これらのパスワードは Unified CCE アプリケーションだけにローカルなパスワードで、Active Directory や他の暗号化や認証用のシステムとのやり取りは行われません。

スキル グループ

Unified ICM 内でスキル グループを設定すると、同様のスキルを持ったエージェントをグループ化できます。エージェントは 1 つまたは複数のスキル グループに割り当てることが可能です。スキル グループは特定の Unified CM PIM と関連付けられます。複数の PIM のスキル グループをエンタープライズ スキル グループにグループ化できます。エンタープライズ スキル グループを作成して使用すると、一部のシナリオではルーティングとレポーティングが容易になります。

ディレクトリ（ダイヤル）番号とルーティング スクリプト

Unified CM から Unified ICM にルート要求を送信するには、Unified CM は、Unified ICM JTAPI ユーザに関連付けられた CTI ルート ポイントに DN を関連付ける必要があります。DN は Unified ICM でも設定が必要です。Unified ICM が DN を持つルート要求を受け取ると、その DN は Unified ICM コール タイプに対応付けられ、次に Unified ICM ルーティング スクリプトに対応付けられます。

エージェントのログインと状態の制御

エージェントは、自分の Unified CCE エージェント デスクトップ アプリケーションから Unified CCE にログインします。ログインすると、このログイン セッションで使用するエージェント ID またはログイン名、パスワード、および Unified CCE 内線番号の入力を要求するダイアログ ボックスがエージェントに表示されます。エージェント ID、内線番号（デバイス ターゲット）、エージェント デスク設定プロファイル、スキル、およびデスクトップ IP アドレスは、ログイン時に動的に関連付けられます。この関連付けは、エージェントがログアウトすると解放されます。

トランスレーション ルーティングとキューイング

受信可能なエージェントがない場合は、Router は [Select] ノードを終了してコールを Unified IP IVR に転送し、キューイング処理を開始します。転送は、[Translation Route To VRU] ノードを使用することで完了します。[Translation Route To VRU] ノードは、最初のルーティング クライアントである Unified CM クラスタに一意のトランスレーション ルート ラベルを戻します。このトランスレーション ルート ラベルは、Unified CM で設定された DN と同じになります。Unified CM では、その DN は、コールの転送先である Unified IP IVR の JTAPI ユーザに関連付けられた CTI ルート ポイントに対応付けられています。

Unified CM と Unified IP IVR が JTAPI ルーティング制御メッセージ機能を実行して、使用できる CTI ポートを選択します。

コールが Unified IP IVR に転送されると、Unified IP IVR トランスレーション ルーティング アプリケーションはまず、SCI 経由で Unified IP IVR から Unified ICM に要求指示メッセージを送信します。Unified ICM は、その DN がトランスレーション ルート ラベルと同一であることを確認し、このコールを、以前にルーティングされたコールと再度関連付けできるようになります。その後、Unified ICM は以前このコールに対して実行されたルーティング スクリプトを再度指定します。再指定するポイントは、[Translation Route To VRU] ノードから正常に出たパスです（図 1-13 を参照）。この時点で、ルーティング クライアントは Unified CM クラスタから IPIVR1 に変更されています。

コールが転送されている間、ルーティング スクリプトが一時的に停止されます。Unified IP IVR への転送が完了すると、Unified IP IVR がこのルーティング スクリプトのルーティング クライアントになります。次にルーティング スクリプトが BoatSales スキル グループにコールをキューイングし、[Run VRU Script] ノード経由で特定のキューイング処理を実行するように Unified IP IVR に指示します。エージェント 111 が受信可能になると、前述の例で説明したように、ルーティング クライアントに戻されるラベルは、デバイス ターゲットとルーティング クライアントの組み合わせに基づいて特定されます。これで Unified IP IVR がルーティング クライアントになりました。エージェント 111 が受信可能になったときに戻されたラベル（1234）によって、Unified IP IVR はコールをエージェント 111（内線番号は 1234）に転送します。

図 1-13 トランスレーション ルーティングとキューイング

Unified CM クラスタと Unified IP IVR の各組み合せには、トランスレーション ルートとラベルのセットが必要です。たとえば、Unified CM クラスタが 1 つと Unified IP IVR が 4 つある展開の場合、4 つのトランスレーション ルートと数セットのラベルが必要です。

Unified IP IVR が複数ある展開の場合、Unified ICM ルーティング スクリプトでアイドル状態の Unified IP IVR ポートの数が最も多い Unified IP IVR を選択して、その Unified IP IVR にコールをトランスレーション ルーティングする必要があります。使用可能な Unified IP IVR ポートがない場合は、スクリプトは [Busy] ノードを実行します。[Busy] ノードを実行しているコールの数が多い場合は、Unified IP IVR ポートのキャパシティのサイズを変更する必要があります。

Reroute On No Answer（RONA）

コールがエージェントにルーティングされた後、指定した時間内にそのエージェントがコールに応答しなかった場合、応答しなかったエージェントの Unified CM PIM はそのエージェントの状態を受信不可に変更して（このエージェントがこれ以上コールを受け取らないように）、他のエージェントを見つけるためにルート要求を送信します。コール データはすべて保存され、次のエージェントのデスクトップに表示されます。受信可能なエージェントがいない場合、コールは Unified IP IVR に戻され、再度キューイング処理が実行されます。ここでもコール データはすべて保存されます。この RONA 処理のルーティング スクリプトは、呼優先度を「高」に設定して、次に受信可能になったエージェントがこの発信者に割り当てられるようにする必要があります。エージェント デスク設定では、RONA タイマーと、RONA 処理のための一意のコール タイプとルーティング スクリプトの指定に使用される DN を設定できます。

ダイヤル番号計画

その後、Unified CM PIM は着信番号とダイヤル番号計画のエントリとの照合を試みます。Unified ICM Dialed Number Plan（DNP; ダイヤル番号計画）は現在、Unified ICM アドミン ワークステーション（AW）の Bulk Configuration ツールによって管理されています。DNP のエントリはペリフェラル（PIM）ごとに入力されており、特定の PIM のすべての DNP エントリは PIM の始動時に PIM にダウンロードされます。DNP への変更や追加も PIM に動的に転送されます。これらの設定はただちに有効になり、次の会議コールにも使用されます。Unified ICM が会議をルーティングし、すべてのコール データを会議とともに移動させて、コールが発生してから完了するまでの全体のレポート用に保存するためには、着信番号に一致するエントリが、エージェントが現在ログインしている PIM の DNP で見つかる必要があります。

DNP 内では、着信番号文字列のファジー（ワイルドカード）マッチングが可能です。DNP は、Unified ICM Router が使用する、AW コンフィギュレーション マネージャ ツールで管理されている着信番号表とは異なります。Unified ICM Router は着信番号をコール タイプに対応させます。コール タイプは Unified ICM ルーティング スクリプトに対応しています。このようにして、特定の着信番号が Unified ICM Router のルーティング スクリプトに対応付けられます。着信番号、コール タイプ、およびルーティング スクリプトの編集の管理に関する詳細については、次の URL で入手できる『 Cisco Unified Contact Center Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_maintenance_guides_list.html

特定の Unified CCE 展開のダイヤル プランの設計については、シスコシステムズのエンジニア（SE）に問い合わせてください。

ダイヤル プラン タイプ

ダイヤル番号計画のエントリは、ダイヤル プラン タイプとともに設定する必要があります。リスト ボックスから事前定義された DNP タイプは 6 種類あり、これらはエージェント デスク設定プロファイルで指定されたタイプに対応します。コールまたは会議を先に進めるには、そのコールの DNP タイプが、会議元のエージェントが使用しているエージェント デスク設定プロファイルで許可されている必要があります。Unified CM のコーリング サーチ スペースはデスクの設定に優先されるため、エージェント デスク設定ですべてのダイヤル プラン タイプを許可しておくことをお勧めします。

（注） エージェント デスク設定プロファイルに対する変更は、エージェントがログアウトして再度ログインするまで有効になりません。

ポストルート

ダイヤル番号計画のエントリは、ポスト ルートが必要かどうかも示すように設定する必要があります。シスコでは、会議のシナリオで着信番号を使用する場合は、会議のポスト ルート オプションを [Yes] に設定することをお勧めします。このフィールドを [Yes] に設定する場合、ルート要求に使用される着信番号を、Dialed Number Plan Editor の [Dialed Number] カラムに入力する必要があります。

ルート要求

会議の DNP で一致するエントリが見つかり、その DNP タイプが会議元のエージェントで許可されている場合、ポスト ルート オプションが [Yes] に設定されていれば、PIM のロジックは、この同一 DNP エントリに指定されている着信番号を使用して、Unified ICM セントラル コントローラにルート要求を送信します。

ルート要求を受け取ると、Unified ICM Router は着信番号をコール タイプに対応させ、適切なルーティング スクリプトを実行して、そのコールに適したターゲット エージェントを見つけます。ルーティング スクリプト内では、それまでに収集したすべてのコール データを、コールのインテリジェント ルーティングに使用できます。Unified ICM Router は、エージェントがログインしているデバイス ターゲット（内線電話およびデスクトップ）を判別し、そのデバイス ターゲットを示すラベルを Unified CM PIM に返します。

この時点では、実行している会議のタイプに応じて、次の項で説明するようなさまざまなシナリオが考えられます。

• 「シングル ステップ（ブラインド）会議」

• 「コンサルテイティブ会議」

シングル ステップ（ブラインド）会議

ブラインド会議は、会議元のエージェントがターゲット エージェントと会話する必要がない場合に使用します。エージェント デスクトップの [Conference] ダイアログ ボックスでブラインド会議を指定した後、会議元のエージェントは DN を入力して、[Initiate Conference] ボタンをクリックします。デスクトップから Unified CM PIM に会議要求が送信されます。DNP で一致するエントリが見つかり、DNP タイプが有効で、ポスト ルートが選択されていれば、Unified CM PIM はルート要求を送信してルーティング ラベルを取得し、その後で Unified CM に、シングル ステップ会議を実行するように（会議元のエージェントのこれ以上のアクションを必要とせずに）指示します。会議元のエージェントのデスクトップからコールが消え、会議元のエージェントのエージェント デスク設定に応じて、各エージェントは次のエージェントの状態（ラップアップ、受信可能、または受信不可）に移行します。コールがターゲット エージェントに発信されている間、最初の発信者は一時的に保留状態になります。ターゲット エージェントの電話が呼び出しを始めると、最初の発信者には呼び出し音が聞こえます（自動応答が有効になっていない場合）。ターゲット エージェントのデスクトップには、すべてのコール データを含んだスクリーン ポップが表示され、電話が呼び出しを始めると、エージェント デスクトップの [Answer] ボタンが有効になります。ターゲット エージェントはコールに応答して最初の発信者と会話し、これで会議の設定は完了します。ターゲット エージェントが応答しない場合は、RONA（Reroute On No Answer）コールの再ルーティング ロジックが後の処理を引き継ぎます。

自動応答が有効になっている場合は、最初の発信者とターゲット エージェントには呼び出し音は聞こえません。そのまま最初の発信者とターゲット エージェントの間でコールが接続されます。

エージェントがコールをスキル グループに割り当てられた番号で会議を開始して、特定のスキルを持つ受信可能なエージェントを探しますが、現在適切なエージェントが受信可能でない場合、Unified ICM ルーティング スクリプトを設定して、キューイング処理を行う Unified IP IVR にコールをトランスレーション ルーティングする必要があります。コールはほぼ瞬時に会議元のエージェントのデスクトップからリリースされます。会議元のエージェントが収集したすべてのデータが、自動的に IVR に渡されます。Unified IP IVR CTI ポートがすぐに応答するため、発信者にリングバック トーンは聞こえません。ターゲット エージェントが受信可能になると、Unified ICM は IVR にコールを会議にするように指示し、Unified ICM はエージェント デスクトップにすべてのコール データを表示させます。

エージェントが、Unified ICM ダイヤル番号計画に存在しない番号でコールを会議にした場合でも、発信者は会議状態になります。会議にされたコールの宛先は、ダイヤルされた番号と、Unified CM ダイヤル プランでの設定によって異なります。エージェントのローミングの制約事項や、コール データがコールに付随しないこと、レポーティングの制約などの理由から、ダイヤル番号計画を使用しない会議は推奨されていません。

コンサルテイティブ会議

Unified CM PIM が、コールの会議先を示すラベルを Unified ICM Router から受け取ると、Unified CM PIM は Unified CM に、コンサルテイティブ会議をラベルに指定された番号に発信するように指示します。Unified CM は最初の発信者（または複数の通話者）を保留にして、ラベルに指定された番号にコンサルテイティブ コールを発信します。多くの場合、会議の設定が完了するまで、発信者には保留音が聞こえます。ただし、コールがすでに会議コールになっている場合は例外で、会議を制御しているエージェント以外の通話者は互いの声を聞いて話し合うことができます。Unified CM には、保留音楽用の設定パラメータがあり、それがオンになっている場合は参加者に音楽が再生されます。

ターゲット エージェントの電話が呼び出しを始めると、Unified CM は Consult Call Confirmation メッセージと Device Ringing メッセージを送信します。

Consult Call Confirmation メッセージを受け取ると、Unified CM PIM は会議元のエージェントのデスクトップにコールが会議用に設定中であることを通知し、これによって [Conference Complete] ボタンが有効になります。会議元のエージェントにターゲット エージェントの電話の呼び出し音が聞こえます（ターゲット エージェントの自動応答が有効になっていない場合）。この後、エージェントが [Conference Complete] ボタンをクリックすると、会議の設定が完了します（ターゲットが電話に応答する前でも後でも可）。

Device Ringing メッセージを受け取ると、Unified CM PIM はターゲット エージェントのデスクトップにコール データを表示し、これによって [Answer] ボタンが有効になります（自動応答が有効になっていない場合）。ターゲット エージェントが [Answer] ボタンをクリックする（または自動応答が起動する）と、会議元のエージェントとターゲット エージェントの間に音声パスが確立されます（会議元のエージェントが [Conference Complete] ボタンをクリックしなかった場合）。

通常、ターゲット エージェントが応答する前に、会議元のエージェントが [Conference Complete] ボタンをクリックすることはありません。エージェントがコンサルテイティブ会議を使用したのは、会議の設定が完了する前にターゲット エージェントと会話をする必要があるためだと考えられるからです。ただし会議元のエージェントは、[Conference Complete] ボタンが有効になれば、いつでもこのボタンをクリックできます。

エージェントがスキル グループに割り当てられた番号にコールの会議を設定して、特定のスキルを持つ受信可能なエージェントを探しますが、現在適切なエージェントが受信可能でない場合、Unified ICM ルーティング スクリプトを設定して、キューイングを行う IVR にコールをルーティングする必要があります。このシナリオでは、会議元のエージェントに Unified IP IVR の応答メッセージが流れます。会議元のエージェントは、いつでも [Conference Complete] ボタンを押して、会議の設定を完了させることが可能です。このシナリオは、ウォーム転送と呼ばれています。そのとき、発信者とエージェントには Unified IP IVR の応答メッセージが再生され始めます。その間、エージェントは引き続き発信者を案内したり、待っている間に処理を続行したりします。適切なスキルを持つエージェントが受信可能になると、Unified IP IVR はこのターゲット エージェントに会議コールを設定し、そのエージェントの画面にすべてのコール データを表示します。

エージェントが、Unified ICM ダイヤル番号計画に存在しない番号や、Unified CM で有効でない番号に会議コールを設定した場合、会議元のエージェントにコンサルテイティブ コールが失敗した音が聞こえ、「再接続」の項で説明するように、最初の発信者に再接続できるようになります。

再接続

コンサルテイティブ会議の consultation leg の間、会議元のエージェントは発信者と再接続して、consultation call leg をリリースできます。この操作は、エージェントが [Reconnect] ボタンをクリックするだけで行えます。この操作でエージェント デスクトップから Unified CM PIM に対して指示が出され、その指示を受けて Unified CM PIM が Unified CM に、consultation call leg をリリースして、エージェントを最初の発信者に再接続するように指示します。

コンサルテイティブ コールを発信しても予期できる理由や予期できない理由で会議の設定を完了しないことにした場合、エージェントは基本的にこのプロセスを使用します。コールの再接続が成功すると、会議元のエージェントのデスクトップの機能は、この会議を要求する前とまったく同じになります。そのため、会議元のエージェントはその後で他の会議を要求することが可能で、1 人のエージェントが発信できるコンサルテイティブ コールの数に上限はありません。

コンサルテイティブ会議と再接続は、すべてのエージェント デスクトップから行われ、Unified CCE と関連付けられている 1 つの Unified CM 内線を使用します。Unified CCE システムは、会議元のエージェントが最初の発信者を保留状態にして、ハードウェアの電話の 2 つ目の内線を使用してコンサルテイティブ コールを発信する機能はサポートしません。ハードウェアの電話には、こうした会議を可能にするボタンがありますが、Unified CCE 環境ではサポートされません。エージェントがこの方法で会議コールを設定すると、Unified ICM によるコールのルーティングは行われないため、すべてのコール データは失われます。

切替

切替は、エージェントが consultation call leg を保留状態にして、コンサルテイティブ会議の最中に最初（または会議）の call leg に復帰できる機能です。その後、エージェントは、最初の発信者を再度保留状態に戻して、consultation call leg に復帰できます。エージェントは何度でもコールを切り替えられます。

会議元のエージェントが最初の発信者に戻った場合、有効になるコール コントロール（ボタン）は、[Release] と [Alternate] だけです。[Conference]（完了）コントロールと [Reconnect] コントロールは使用できません。[Alternate] コントロールを押すと、会議元のエージェントはコンサルト会議の通話に戻ります。エージェントが consultation leg に戻った場合、[Release]、[Alternate]、[Conference]、および [Reconnect] のコール コントロールが有効になります。[Alternate] コントロールを押すと、会議元のエージェントは最初の発信者との通話に戻ります。[Conference] コントロールを押すと会議の設定が完了し、[Reconnect] ボタンを押すとコンサルト会議が終了して、エージェントは最初の発信者に再接続されます。

DNP 以外の会議

DNP に存在しない番号や、ポスト ルートを [No] に設定している DNP で設定されている番号への会議の設定は可能ですが、そのコールは Unified ICM によってルーティングされていることにはなりません。これらのシナリオでは、PIM はただコールの会議要求を直接 Unified CM に送信して、エージェント デスクトップの [Conference] ダイアログボックスにある着信番号を使用します。Unified ICM がコールをルーティングしないと、コール データは失われます。シスコでは、会議のすべての着信番号を DNP のエントリと一致させ、ポスト ルートを可能にし、この着信番号の DNP タイプを会議元のエージェントで（エージェント デスクの設定に基づいて）許可しておくことをお勧めします。

エージェント間の会議

会議が特定のエージェント宛ての場合、その会議を要求するエージェントは、[Conference] ダイアログ ボックスにエージェント ID を入力する必要があります。着信番号（エージェント ID）に一致する DNP エントリの DNP タイプは、PBX と一致することが必要です。これによって PIM は、Unified ICM Router にルート要求を送信する前に、着信番号（エージェント ID）を [CED] フィールドに入力します。スクリプト エディタで、エージェント間ルーティング ノードを使用して、エージェント ID の場所として [CED] フィールドを指定します。これによって Unified ICM Router はこのコールを正しくルーティングします。

エージェント ID は、Unified CM クラスタのいずれの内線にも一致しません。すべてのエージェント ID が同じ番号で始まり、長さもすべて同じ場合、すべてのエージェント ID に一致する一般的なワイルドカード文字列を設定できるため、エージェント間のルーティングに必要な DNP のエントリは 1 つだけです。

環境に複数の PIM が存在する場合は、エージェント ID 番号プランを使用して、このエージェントを含む PIM を見つける必要があります。エージェント ID はそれだけでは一意ではありません。エージェント ID は特定の PIM と関連付けられ、他の PIM での再利用が可能です。企業全体でエージェント ID を重複させず、一貫性のあるエージェント ID の割り当てプラン（PIM 1 のエージェント ID はすべて 1 で始まり、PIM 2 のエージェント ID はすべて 2 で始まるなど）を設定することで、スクリプト エディタの [CED] フィールドを解析して、そのエージェントを含む PIM を見つけることが可能になります。解析は、スクリプト エディタの一連の [IF] ノードや、[route-select] ノードで行えます。[agent-to-agent] ノードでは、PIM を指定する必要があります。

ターゲット エージェントが受信可能状態でない場合、エージェント転送の [Script Editor] ノードによって、そのコールの代替ルーティングが可能になります。

会議コールの転送

会議コールの転送は、「Unified CCE 環境での転送」に説明されているのと同じ条件で許可されています。

会議のレポーティング

会議コールの設定が完了すると、最初の call leg の呼詳細レコードが存在し、さらに新しい call leg 用に新しいコールの詳細レコードが開かれます。この 2 つのコール レコードは、Unified ICM が割り当てた共通のコール ID によって、互いに関連付けられます。会議の設定が完了する前の、consultation call leg の継続時間は、会議元のエージェントの通話時間と見なされます。

詳細については、Cisco.com で入手できるオンライン マニュアル『 Unified CCE Reporting Guide 』を参照してください。

会議の組み合せまたは複数の会議

会議中に（ソフトフォンを使用して）他の参加者を会議に参加させられるのは会議関係者だけです。ハードウェアの電話ではこの機能を使用できる場合がありますが、Unified CCE ではサポートされません。

会議コールが正常に設定されると、会議関係者が別の通話者を会議に参加させることができます。参加者の人数制限は、ブリッジとして使用しているハードウェア、Unified CM の設定などによって異なります。

PSTN 転送（Takeback N Transfer、または転送接続）

多くの PSTN サービス プロバイダーは、ネットワーク ベースの転送サービスを提供します。これらのサービスは通常、一連の DTMF トーンを発信する Customer Premises Equipment（CPE; 顧客宅内機器）によって呼び出されます。PSTN は、これらのトーンを検出して、検出したトーンに基づく特定のロジックを実行するようにプロビジョニングされています。一般的な発信シーケンスは、*827500 のようになります。この DTMF 文字列は、「このコールをサイト 2 に転送して、コールをサイト 2 に送信する際の DNIS 値として 7500 を使用する」という内容を意味します。Unified CCE には、これらのタイプの転送を呼び出す機能があります。