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

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

図1-2 は Unified IP IVR を使用する基本的な Unified CC コールのフローを示しています。 このシナリオでは、コールが着信したときにすべてのエージェントが「受信不可」であるとみなされているため、コールは 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 CC コール フロー

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

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

2. Cisco Unified CallManager に MGCP または H.323 のルート要求が送信される。

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

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

5. ICM が Cisco Unified CallManager に対してコールを Unified IP IVR に転送するように指示し、Cisco Unified CallManager はその指示に従う。

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 CC コールのフローを示しています。

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

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

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

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

3. Unified CVP が GED-125 要求を ICM に送信して指示を要求する。

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

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

6. Cisco Unified CallManager 上の応答可能なエージェントにコールを送信するように、GED-125 を使用して ICM が Unified CVP に指示する。

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

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

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

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

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

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

• Call Router

• Logger

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

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

• VRU PIM

• CTI サーバ

• CTI Object Server（CTI OS）

• アドミン ワークステーション（AW）

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

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

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

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

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

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

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

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

Unified CC のエージェント インターフェイス

Unified CCE のエージェント用のインターフェイスとして、シスコでは次のインターフェイスを提供しています。

• Cisco Agent Desktop

• Cisco Toolkit Desktop

• 組み込み CRM デスクトップ

• Cisco Unified IP Phone Agent

Cisco Agent Desktop

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

図1-5 Cisco Agent Desktop

Cisco Toolkit Desktop

Cisco Toolkit Desktop は、Cisco CTI ツールキットで作成されるカスタム ビルドのエージェント デスクトップ アプリケーションです。 Cisco CTI ツールキットは、CTI Object Server（CTI OS）と対話するエージェント デスクトップ アプリケーションを開発するためのソフトウェア開発ツールキットです。 Cisco Toolkit Desktop でも、CAD と同様のエージェント状態制御およびコール制御を実行できます。 Cisco CTI ツールキットを使用して、既存のデスクトップ アプリケーションにエージェント状態制御機能やコール制御機能を追加できます。 Cisco Toolkit Desktop では Cisco Unified IP Phone または Cisco IP Communicator（ソフトフォン）の使用が必須になります。

組み込み CRM デスクトップ

組み込み Customer Relationship Management（CRM; 顧客関係管理）デスクトップは、エージェント状態制御機能とコール制御機能が CRM アプリケーション内に組み込まれている CRM アプリケーションです。 Cisco Siebel Desktop は、この組み込み CRM デスクトップの 1 つです。 その他の組み込み CRM デスクトップはシスコのパートナーから入手できます。 組み込み CRM デスクトップでは Cisco Unified IP Phone または Cisco IP Communicator（ソフトフォン）の使用が必須になります。

Cisco Unified IP Phone Agent

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

Unified CC のスーパーバイザ インターフェイス

Unified CCE のスーパーバイザ用のインターフェイスとして、シスコでは次のインターフェイスを提供しています。

• Cisco Supervisor Desktop

• Cisco Toolkit Desktop

Cisco Supervisor Desktop

Cisco Supervisor Desktop（CSD）はすぐに使用できる Windows ベースのデスクトップ アプリケーションです。スーパーバイザはこのアプリケーションを使用して、エージェント状態のモニタリングと制御、コール センター統計情報のモニタリング、エージェントのサイレント モニタリング、介入、代行受信、エージェントの通話録音などを実行できます。 CSD でこのような機能を実行できるのは、CAD または IPPA を使用するエージェントに対してだけです。 CSD は CAD とは完全に別のデスクトップ アプリケーションです。介入や代行受信の機能を実行するためには、スーパーバイザは CAD にログインする必要があります。

Cisco Toolkit Desktop

エージェント機能用の Cisco Toolkit Desktop アプリケーションに、スーパーバイザ向けの制御機能も組み込むことができます。 スーパーバイザはスーパーバイザ向けの機能を使用して、エージェント状態のモニタリングと制御、一部のコール センター統計情報のモニタリング、エージェントのサイレント モニタリング、介入、代行受信、エージェントの通話録音などを実行できます。 ただし、スーパーバイザが Toolkit Desktop でこのような機能を実行できるのは、Toolkit 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 で、開発用のアプリケーションレベル インターフェイスを提供しています。

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

• 3 番目の層は Cisco CTI サーバで、イベント ソースの提供とテレフォニー要求のバックエンド処理を行っています。

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

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

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

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

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

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

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

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

http://www.cisco.com/univercd/cc/td/doc/product/icm/ipccente/index.htm

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

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

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

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

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

• Historical Data Server（HDS）

• WebView サーバ

• Internet Script Editor Server

• WebConfig Server（Unified CC 7.0 システムを展開する場合のみ）

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

WebView サーバ オプションでは、ブラウザ ベースのレポートを作成できます。 このオプションを選択すると、ブラウザ機能のあるすべてのコンピュータからレポートを作成できます。 Internet Script Editor Server をインストールできるのはディストリビュータ AW だけです。Script Editor のクライアントはこのサーバに HTTPS（デフォルト プロトコル）で接続できます。 WebConfig Server には、Unified CC 7.0 システム（子 Unified CC）を展開するためのブラウザベースの設定ツールが提供されています。このサーバをインストールできるのはディストリビュータ AW だけです。

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

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

Unified CC のレポーティング

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

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

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

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

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

WebView

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

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm70doc/report7/index.htm

WebView では、レポートの出力が 3,000 行に制限されており、返せる以上のデータが要求された場合はレポートの超過部分が切り捨てられます。

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

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm70doc/report7/index.htm

レポーティング データ

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

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm70doc/report7/index.htm

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

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

Historical Data Server（HDS）

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

JTAPI 通信

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

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

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

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

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

• ルーティング制御

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

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

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

• デバイスとコール制御

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

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

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

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

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

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

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

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

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

CTI ポート デバイスの制御および監視を行わせるためには、Cisco Unified CallManager の 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 に関連付けます。

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

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

ICM には、電子メールと Web コラボレーションを含むマルチチャネル コンタクト センターを実現する機能があります。 この機能は、Cisco E-Mail Manager と Cisco Collaboration Server と協調動作することによって実現されています （図1-8を参照してください）。 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-8 マルチチャネル サブシステム

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 Unified Outbound Dialer（Unified OUTD）

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

System Unified CC

System Unified CC は、Unified ICM および Unified ICM 以外の不必要な展開オプションを排除し、Unified CC 用に事前定義された 3 つの設定を使用してインストールと設定を簡素化した新しい展開モデルです。 System Unified CC では、新しい単一のインストーラを使用してインストールと設定を簡素化しており、Web ベースの管理も可能になっています。 サービス、トランスレーション ルート、デバイス ターゲット、ラベル、サブ スキル グループ、およびエージェント ID が省略され、System Unified CC の設定は、より簡単になっています。 System Unified CC のインストールでは、ルーティング クライアントは 1 つだけです。 どれほど多くのペリフェラルを設定する場合でも、個々のペリフェラルの内部的な詳細情報とルーティング クライアントの詳細情報はシステムで処理されます。

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

System Unified CC は、図1-9に示されている次の内部コンポーネントで構成されています。

• セントラル コントローラ：Call Router、Logger、および SQL Server が含まれます。

• エージェント/IVR コントローラ：Unified CC System PG、CTI サーバ、CTI OS サーバ。

• 管理と WebView レポーティング：AW、HDS、SQL Server、Microsoft Internet Information Service（IIS）。

• Cisco Unified CallManager：System Unified CC は 1 組の Cisco Unified CallManager クラスタに接続します。

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

• オプション コンポーネント：アウトバウンド コントローラ、Cisco E-Mail Manager と Cisco Collaboration Server 用のマルチチャネル コントローラ、Unified ICM に対する Unified CC ゲートウェイ、Cisco Agent Desktop Server。

図1-9 System Unified CC

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

デバイス ターゲット

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

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

ラベル

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

多くの場合、コールがどのように宛先にルーティングされるかは、コールの発信元や終端先によって異なります。 そのため Unified CC ではラベルを使用します。 たとえば、2 つの Cisco Unified CallManager クラスタ（サイト 1 とサイト 2）が別の場所に配置された環境があると仮定します。サイト 1 の Unified IP Phone ユーザがサイト 1 の他の Unified IP Phone ユーザに電話をかける場合は、通常、4 桁の内線番号をダイヤルします。サイト 1 からサイト 2 の Unified IP Phone ユーザに電話をかけるには、ユーザは 7 桁の番号をダイヤルする必要があります。 公衆電話交換網の電話からどちらかのサイトの Unified IP Phone ユーザに電話をかけるには、ユーザは 10 桁の番号をダイヤルする必要があります。 この例から、コールの発信元と終端先に応じて、どのように異なるラベルが必要になるかがわかります。

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

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

エージェント デスク設定

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

エージェント

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

スキル グループ

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

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

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

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

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

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

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

Cisco Unified CallManager と 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（VRU トランスレーションルート）］ノードから正常に出たパスです（図1-11を参照してください）。 この時点で、ルーティング クライアントは Cisco Unified CallManager クラスタから IPIVR1 に変更されています。

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

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

Cisco Unified CallManager クラスタと Unified IP IVR の各組み合せには、トランスレーション ルートとラベルのセットが必要です。 たとえば、Cisco Unified CallManager クラスタが 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）

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

ダイヤル番号計画

その後、Cisco Unified CallManager 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/univercd/cc/td/doc/product/icm/ipccente/index.htm

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

ダイヤル プラン タイプ

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

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

ポストルート

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

ルート要求

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

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

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

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

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

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

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

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

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

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

コンサルテイティブ会議

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

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

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

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

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

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

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

再接続

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

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

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

切替

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

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

Unified ICM 以外の会議

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

エージェント間の会議

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

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

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

ターゲット エージェントが受信可能状態でない場合、エージェント間のスクリプト エディタ ノードによって、そのコールの代替ルーティングが可能になります。

会議コールの転送

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

会議のレポーティング

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

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

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

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

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

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

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