Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）Release 8.0(x)

Unified ICM のネットワーク VRU の概要

この項では、Unified CVP アプリケーションで使用される Unified ICM VRU のタイプについて説明します。Unified ICM は、IVR 処理を必要とするコールには、スイッチ レッグと VRU レッグという 2 つの部分があると認識しています。スイッチは、ネットワークまたは発信者からのコールを最初に受信するエンティティです。VRU は、オーディオを再生し、プロンプト/コレクト機能を実行するエンティティです。Unified CVP は、Unified ICM の観点からは、スイッチ ロールまたは VRU ロール、あるいはその両方に参加できます。ネットワーク展開において、スイッチ部分と VRU 部分を独立して提供するために、複数の Unified CVP デバイスを展開することもできます。

VRU へのコール配信は、コール参照 ID を VRU に渡すネットワーク機能に応じて、相関 ID メカニズムまたはトランスレーション ルート メカニズムに基づいて行うことができます。Unified ICM はコールを完了する指示を出すために同じコールの 2 つのレッグを相関させる必要があるため、コール参照 ID が必要となります。Unified ICM アプリケーションでは、VRU は、スイッチから受信した着信コールの処理方法に関する指示を要求するときに、このコール参照 ID を Unified ICM に提供する必要があります。このメカニズムによって、Unified ICM はこの同じコールの適切なコール コンテキストを取得でき、この段階でコールの IVR 部分に進むことになります。これら 2 つの相関メカニズムは、次のように動作します。

• 相関 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 キャリアは、この目的で使用するためのトランスレーション ルート ラベルのセットをプロビジョニングします。

（注） 展開される VRU は、ネットワーク内（ネットワーク VRU）または顧客構内に展開できます。後者のシナリオでは、Network Applications Manager（NAM）がネットワーク内に展開され、Customer ICM（CICM; カスタマー ICM）が顧客構内に展開されます。前述したように、VRU の場所に応じて、対応する相関 ID またはトランスレーション ルート ID をそれぞれ使用する必要があります。

タイプ 10 VRU としての Unified CVP

タイプ 10 は、Unified CVP の包括モデル展開におけるコンフィギュレーション要件を簡略化するために設計されました。タイプ 10 VRU は、すべての新規インストールに対して優先される VRU タイプですが、Cisco Unified ICM 7.1 以降のリリースを必要とします。Unified ICM 7.0 の展開では、この章の以降の項で概説する VRU タイプを使用する必要があります。Unified ICM 7.5(3) よりも前は、タイプ 10 VRU は ICM Customers をサポートしていませんでした。ICM Customers は、複数のネットワーク VRU の使用を可能にし、通常はホスト型の展開で使用される Unified ICM 機能です。ICM Customers の使用が必要な展開では、以降で概説するその他の VRU タイプを使用できます。または、Unified ICM 7.5(3) 以降のリリースを使用できます。ICM Customers は現在サポートされていますが、Unified CVP VRU スイッチ レッグから完全に別の Unified CVP への 2 ステップ転送（たとえば、SendToVRU を使用した 2 ステップでの CVP から CVP への転送）は開始できません。そのような 2 ステップ転送を機能させるには、トランスレーション ルートを使用する必要があります。

タイプ 10 ネットワーク VRU の動作は、次のとおりです。

• Unified CVP スイッチ レッグへのルーティング クライアント責任のハンドオフがあります。

• Unified CVP VRU レッグへの自動転送があります。その結果、VRU、ACD、または Cisco Unified Communications Manager（Unified CM）により発生したコールの場合、別の転送が発生します。

• Unified CM により発生したコールの場合、相関 ID 転送メカニズムが使用されます。相関 ID は、タイプ 10 ネットワーク VRU コンフィギュレーションで定義された転送ラベルの最後に自動的に追加されます。

• Unified CVP VRU レッグへの最後の転送はタイプ 7 転送と同様であり、転送の前に RELEASE メッセージが VRU に送信されます。

ICM Customers 機能を使用しない Unified CVP 実装（つまり、単一のネットワーク VRU を使用する Unified CVP 実装）では、単一のタイプ 10 ネットワーク VRU を定義する必要があり、すべての Unified ICM 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 を使用します。

タイプ 5 VRU としての Unified CVP

（注） Cisco Unified ICM 7.1 は、タイプ 10 ネットワーク VRU を導入しています。Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には、この VRU を使用する必要があります。アップグレードした既存の顧客展開または Unified ICM 7.1 以降を実行していない展開には、タイプ 5 VRU を使用する必要があります。

VRU エンティティがスイッチ（呼制御）と VRU（IVR）の両方として機能するという点で、タイプ 5 とタイプ 6 は似ています。ただし、VRU への接続方法が異なります。

タイプ 6 では、スイッチと VRU は同じデバイスであるため、コールはすでに VRU にあります。Unified ICM の観点からは、接続および要求命令のメッセージ シーケンスは必要ありません。

一方、タイプ 5 では、スイッチと VRU は Unified ICM の観点からは、同じサービス ノード内にある（つまり、どちらも同じ PG インターフェイスを介して Unified ICM と対話する）場合でも、異なるデバイスです。そのため、Unified ICM は接続および要求命令のシーケンスを使用して IVR コールを完了します。

（注） Unified CVP アプリケーションには、Unified ICM によって認識されるコールの 2 つのレッグ（スイッチ レッグおよび VRU レッグ）があります。Unified CVP がサービス ノード アプリケーションとして機能する場合（つまり、Unified CVP がコールをプレルーティングを介してではなくネットワークから直接受信する場合）、呼制御（Unified CVP）と VRU デバイスが異なるため、Unified CVP は Unified ICM にとってタイプ 5 と見なされます。したがって、スイッチ レッグに対する Unified ICM および NAM のコンフィギュレーションにおいて、Unified CVP を VRU タイプ 5 として設定する必要があります。VRU レッグには、展開モデルに応じて異なるセットアップが必要です（たとえば、包括 Unified ICM 企業展開モデルでは、VRU レッグはタイプ 7 である場合があります）。Unified CVP をタイプ 5 として設定する例については、最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』を参照してください。このマニュアルは http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html から入手できます。

Unified CVP が Unified ICM および NAM に対してタイプ 5 VRU として機能する場合は、相関 ID もトランスレーション ルート ID も必要ありません。ただし、ダミー ラベルが必要となる場合があります。

タイプ 3 またはタイプ 7 VRU としての Unified CVP（相関 ID メカニズム）

（注） Cisco Unified ICM 7.1 は、タイプ 10 ネットワーク VRU を導入しています。Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には（VRU のみ（後述するモデル #4a）は除く）、この VRU を使用する必要があります。アップグレードした既存の顧客展開または Unified ICM 7.1 以降を実行していない展開には、タイプ 3 またはタイプ 7 VRU を使用する必要があります。

VRU が相関 ID メカニズムを備えた IVR として機能する場合、Unified ICM はタイプ 3 およびタイプ 7 を使用し、相関 ID スキームの PG を介して VRU のサブ動作を指定します。タイプ 3 およびタイプ 7 VRU はどちらも相関 ID メカニズムによって到達可能であり、VRU を制御するために PG が必要です。ただし、これら 2 つのタイプでは、VRU レッグの解放方法およびコールを最終宛先に接続する方法が異なっています。

タイプ 3 では、コールを VRU に配信するスイッチは、コールを VRU から取得して宛先（またはエージェント）に接続できます。

タイプ 7 では、スイッチはコールを VRU から取得できません。IVR 処理が完了すると、Unified ICM は切断するか VRU レッグを解放する必要があり、その後で最終接続メッセージをスイッチ レッグに送信して、コールを宛先に接続するようにスイッチに命令できます。

インテリジェント ペリフェラル IVR として使用される場合、Unified CVP はタイプ 3 またはタイプ 7 で機能できますが、タイプ 7 のほうが多少効率的です。これは、VRU レッグが不要になったときに、（コールが引き出されたことを VoiceXML ゲートウェイから通知されるのを待機するのではなく）Unified ICM から明確な指示を取得するためです。

前述したように、コールにはスイッチ レッグと VRU レッグという 2 つのレッグがあります。各レッグに対して異なる Unified CVP ハードウェアを使用できますが、Unified ICM 機能の観点からは、VRU タイプ 5 として機能する PG を介した Unified CVP（サービス ノード）と、VRU タイプ 7 として機能する別の PG を介した潜在的に異なる Unified CVP があり、IVR アプリケーション（セルフサービス、キューイングなど）を完了します。

VRU タイプ 3 またはタイプ 7 を使用する Unified CVP アプリケーションの設定例については、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

タイプ 8 またはタイプ 2 VRU としての Unified CVP（トランスレーション ルート ID メカニズム）

（注） Cisco Unified ICM 7.1 は、タイプ 10 ネットワーク VRU を導入しています。Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には（VRU のみ（後述するモデル #4a）は除く）、この VRU を使用する必要があります。アップグレードした既存の顧客展開または Unified ICM 7.1 以降を実行していない展開には、タイプ 8 またはタイプ 2 VRU を使用する必要があります。

VRU がトランスレーション ルート ID メカニズムを備えた IVR として機能する場合、Unified ICM はタイプ 8 またはタイプ 2 を使用し、トランスレーション ルート ID スキームの PG を介して VRU のサブ動作を指定します。タイプ 2 およびタイプ 8 VRU はどちらもトランスレーション ルート メカニズムによって到達可能であり、VRU を制御するために PG が必要です。ただし、コールを最終宛先に接続する方法が異なります。

タイプ 8 では、コールを VRU に配信するスイッチは、コールを VRU から取得して宛先またはエージェントに接続できます。

タイプ 2 は、コールを VRU から取得してエージェントに配信する機能がスイッチにない場合に使用されます。その場合、IVR 処理が完了すると、Unified ICM は最終接続メッセージを（元のスイッチではなく）VRU に送信して、コールを宛先に接続します。VRU はコールを受信すると、スイッチングの制御責任を負います。このプロセスは、 ハンドオフ と呼ばれます。

相関 ID の場合と同様に、コールにはスイッチ レッグと VRU レッグという 2 つのレッグがあります。Unified CVP はスイッチ レッグと VRU レッグのどちらにも使用できます。たとえば、Network Interface Controller（NIC; ネットワーク インターフェイス コントローラ）、NAM、または CICM が含まれる場合、Unified CVP は VRU レッグでタイプ 2 またはタイプ 8 として設定する必要があります。

VRU タイプ 8 またはタイプ 2 を使用する Unified CVP アプリケーションの設定例については、次の URL から入手可能な最新バージョンの『 Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP) 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

モデル #1：スタンドアロン セルフサービス

スタンドアロン セルフサービス モデルは、通常は Unified ICM VRU スクリプトとインターフェイスしないため、ネットワーク VRU 設定は関係ありません。Unified ICM ラベル ルックアップを使用するスタンドアロン セルフサービス モデルは、Unified ICM の VRU スクリプトを使用しません。単純にルート要求を VRU PG ルーティング クライアントに発行するため、ネットワーク VRU は必要ありません。

モデル #2：コール ディレクタ

このモデルでは、Unified ICM（したがって Unified CVP）は、コール スイッチングだけに責任を負います。キューイングまたはセルフサービスは提供しないため、VRU レッグはありません。したがって、この場合にはネットワーク VRU 設定は必要ありません。

モデル #3a：ICM Micro-Apps を使用する包括モデル

このモデルでは、Unified CVP デバイスはスイッチと VRU レッグの両方として機能しますが、コール処理（.wav ファイルの再生またはユーザ入力の受け入れ）の発生前に、コールをスイッチ レッグから VRU レッグに転送する必要があります。この場合は、すべての Unified CVP ペリフェラルをタイプ 10 ネットワーク VRU に関連付けます。

（注） タイプ 10 は Unified ICM 7.1 以降だけで使用可能であり、新規実装ではこのコンフィギュレーションを使用する必要があります。Unified ICM 7.0 では、この場合はタイプ 2 ネットワーク VRU を使用する必要があります。

すべての着信番号を、タイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付けます。このコールによって実行されるすべての VRU スクリプトは、同じタイプ 10 ネットワーク VRU に関連付けられる必要があります。必ずしも必要というわけではありませんが、ベスト プラクティスは、最初の RunExternalScript ノードの前に Unified ICM ルーティング スクリプトで SendToVRU ノードを実行することです。

（注） タイプ 10 は Unified ICM 7.1 以降だけで使用可能であり、新規実装ではこのコンフィギュレーションを使用する必要があります。Unified ICM 7.0 では、この場合はタイプ 7 を使用する必要があります。

モデル #3b：Unified CVP VXML Server を使用する包括モデル

コール ルーティングおよびネットワーク VRU の観点からは、このモデルは前述したモデル #3a と同じです。

モデル #4：VRU のみ

このモデルでは、コールは最初に Unified CVP ではなく ICM-NIC インターフェイスを介して Unified ICM に着信します。少なくとも最初は、Unified CVP はスイッチ レッグに関与しません。唯一の目的は VRU として機能することです。ただし、使用される NIC の種類によっては、コールを受信した後にスイッチ レッグを引き継ぐ必要がある場合があります。このモデルには実際には 2 つのサブモデルがあり、次の項でそれぞれについて説明します。

モデル #4a：NIC 制御ルーティングのみを使用する VRU

このサブモデルは、コールを一時的にネットワーク VRU（つまり、Unified CVP の VRU レッグ）に配信し、後でエージェントが使用可能になったときにコールを取得してそのエージェントに配信できる、完全に機能する NIC を想定しています。さらに、コールを別のエージェント、あるいはキューやセルフサービスに再転送することをエージェントが要求できる場合に、NIC がエージェントからコールを取得して要求されたとおりに再配信できることを想定しています。

このモデルには、VRU へのコールの転送に相関 ID メカニズムが使用されるかトランスレーション ルート メカニズムが使用されるかに応じて、2 つの種類があります。ほとんどの NIC（実際には、ほとんどの PSTN ネットワーク）は、コールを特定の宛先電話番号に転送できず、任意の相関 ID を一緒に転送できません（相関 ID 転送メカニズムを正しく機能させるために、宛先デバイスは相関 ID を Unified ICM に戻すことができます）。したがって、ほとんどの NIC では、トランスレーション ルート メカニズムを使用する必要があります。

ただし、このルールにはいくつかの例外があり、その場合には相関 ID メカニズムを使用できます。相関 ID を送信できる NIC には、Call Routing Service Protocol（CRSP）、SS7 Intelligent Network（SS7IN）、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 からの不要な配信および削除を回避できます。

モデル #4b：NIC 制御プレルーティングのみを使用する VRU

このサブモデルは、VRU またはエージェントにコールを 1 回だけ配信できる、機能の低い NIC を想定しています。コールが配信された後は、コールを取得して別の場所に再配信するように NIC に命令することはできません。そのような場合は、Unified CVP がコールのスイッチングの制御責任を引き受けることができます。Unified ICM の観点からは、このプロセスは ハンドオフ と呼ばれます。

この特定のサブモデルに該当するコールは、トランスレーション ルート メカニズムを使用してコールを VRU に転送する必要があります。相関 ID メカニズムを使用してハンドオフを実装する方法はありません。

Unified ICM 7.1 でこのモデルを実装するには、着信番号はすべて、タイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。VRU ラベルは、NIC ではなく Unified CVP ルーティング クライアントに関連付けられます。Unified CVP ペリフェラルおよび VRU スクリプトは、タイプ 10 ネットワーク VRU に関連付けられる必要があります。この場合は常に、最初の RunExternalScript ノードの前に、TranslationRouteToVRU ノードとそれに続く SendToVRU ノードをルーティング スクリプトに挿入する必要があります。コールがキューに格納されているために VRU レッグに向かう場合は、通常、これらの 2 つのノードは Queue ノードの後にあります。このようにして、要求されたエージェントがすでに使用可能な場合に、Unified CVP からの不要な配信および削除を回避できます。

Unified ICM 7.0 でこのモデルを実装するには、着信番号はすべて、タイプ 7 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。VRU ラベルは、NIC ではなく Unified CVP ルーティング クライアントに関連付けられます。Unified CVP ペリフェラルはタイプ 2 のネットワーク VRU に関連付けられている必要がありますが、すべての VRU スクリプトはタイプ 7 ネットワーク VRU に関連付けられている必要があります。この場合は常に、最初の RunExternalScript ノードの前に、TranslationRouteToVRU ノードとそれに続く SendToVRU ノードをルーティング スクリプトに挿入する必要があります。コールがキューに格納されているために VRU レッグに向かう場合は、通常、これらの 2 つのノードは Queue ノードの後にあります。このようにして、要求されたエージェントがすでに使用可能な場合に、Unified CVP からの不要な配信および削除を回避できます。

（注） 2 つの異なる VRU 転送ノードが必要です。最初の転送では、ハンドオフによってコールを NIC から転送し、Unified CVP をこのコールのスイッチ レッグ デバイスとして確立します。物理的にはコールは入力ゲートウェイに配信されます。2 番めの転送では、コールを VoiceXML ゲートウェイに配信し、Unified CVP をコールの VRU デバイスとしても確立します。

ホスト型実装の概要

ホスト型実装では、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 への接続はありませんが、NAM への接続は NIC（特に INCRP NIC）を介して行われます。

従来から、シスコのお客様はサービス プロバイダーであるため、ホスト型の設定を実装しています。お客様は ICM コンタクトセンター サービスを複数の顧客に提供する必要があります。顧客はそれぞれ独自の CICM 上でホストされ、NAM がコールをルーティングする責任を負います。コールはサービス プロバイダーに配信され、適切な顧客の CICM に配信されます。個々の顧客は、それぞれの自社の構内にある PG に接続された独自の ACD を使用して、独自のコンタクトセンターを運営します。一方で PG は、サービス プロバイダーにある、割り当てられた CICM に接続されます。このようにして、サービス プロバイダーは NAM とすべての CICM を所有してホストしますが、すべての ACD は個々の顧客が所有してホストします。それらの ACD の PG は、所有者はサービス プロバイダーですが、顧客の構内の ACD の横に展開されます。サービス プロバイダー自身は独自の ACD を稼動する必要はありませんが、稼動することは可能です。その PG は、サービス プロバイダーに割り当てられた CICM に接続するか、実際に NAM 自体に接続できます。

ICM スクリプティングに関しては、すべての着信コールによって、最初に、適切なターゲット顧客を識別する主要な責任を負う適切な NAM ルーティング スクリプトが起動されます。次に、スクリプトによって、その顧客の CICM 上で実行されているルーティング スクリプトに制御が委任されます。CICM ベースのルーティング スクリプトは、コールの配信先の適切な ACD を選択でき、必要なトランスレーション ルート ラベルを NAM に返すことができます。NAM は、指定されたターゲット ACD にコールを配信するようにルーティング クライアントに命令できます。CICM ルーティング スクリプトは、現在はコールを取得できる ACD がないか、コールを取得する ACD をまだ識別できないと判断した場合、コールをサービス制御 VRU のキューに展開するように NAM に要求できます。CICM ルーティング スクリプトは、ルーティング決定が行われるまで、NAM 経由でその VRU にネットワーク VRU スクリプト要求を発行できます。

実際には NAM と CICM のアーキテクチャは柔軟であるため、その他にもさまざまな方法で使用できます。ホスト型をご利用の多くのお客様は、単純に多くのコールまたは PG を ICM セットアップで取得するための方法として、このトポロジを使用しています。カスタマー コンタクトセンターではなくアウトソーサーのために CICM を使用するお客様もあります。そのような場合、おそらく NAM は CICM と同じ数のコールを処理し、CICM マシン自体は NAM から遠く離れて展開されます。また、NAM と CICM のアーキテクチャは、すべてのコンタクトセンターが TDM ベースの ACD で実行されていたときに設計されました。ダイレクト エージェント ルーティングを備えた Unified CM（つまり Unified CCE）に基づく VoIP ルーティングおよび ACD の追加により、状況は非常に複雑になりました。

ホスト型環境での Unified CVP の使用

Unified CVP が関係する場合、通常は、NAM に接続されてサービス プロバイダーのデータセンター内に物理的に展開された、セルフサービスまたはキューイング プラットフォームとして使用されます。したがって、従来のサービス プロバイダーは、コールを適切な顧客所有の ACD にルーティングするだけでなく、それらの ACD に対してキューに格納されたコールの制御を保持し、基本的なプロンプト/コレクト機能または完全なセルフサービス アプリケーションを顧客に提供できます。後者の場合は、通常、Unified CVP VXML Server がネットワークに組み込まれます。顧客のニーズに応じて、Unified CVP VXML Server は、サービス プロバイダーがホストする場合もあれば、顧客がホストする場合もあります。また、サービス プロバイダーがセルフサービス アプリケーションを作成して所有する場合もあれば、顧客が作成して所有する場合もあります。顧客が Unified CVP VXML Server を所有またはホストできるようにすることは、セルフサービス アプリケーションでバックエンド サービスを参照する必要がある場合に便利なソリューションです。顧客はその対話を自社ネットワーク内で制御しながら、VoiceXML over HTTP だけをサービス プロバイダーの VoiceXML ゲートウェイに送信できます。

多くのホスト型環境では、特にサービス プロバイダー自身が PSTN キャリアである場合、実際のコール ルーティングはすべて ICM NIC 経由で行われます。その意味では、これらの展開は「モデル #4b：NIC 制御プレルーティングのみを使用する VRU」と非常に似ています。同じ状況は、（通常は）ICM SS7 NIC を使用してコールをルーティングするために PGW が使用されている場合にも該当します。ただし、サービス プロバイダーが NIC インターフェイスをまったく持たず、すべてのコールが T3 や E3 などの TDM インターフェイス経由で着信することが多くあります。そのような場合、Unified CVP はスイッチ レッグおよび VRU レッグとして使用されます。この状況は、「モデル #3a：ICM Micro-Apps を使用する包括モデル」または「モデル #3b：Unified CVP VXML Server を使用する包括モデル」と同様です。

ホスト型環境での Unified CVP 展開とコール ルーティング

前述したように、Unified CVP が従来の方法で純粋にネットワーク VRU として使用される場合は、NAM で接続されます。ただし、さまざまな要件によって Unified CVP が、代わりに、または追加で、CICM レベルで展開される場合があります。Unified CVP コンポーネントの展開場所を考慮する際には、次のガイドラインが適用されます。

• Unified CVP が NAM で展開され、Unified CVP がスイッチ レッグと VRU レッグの両方を処理する場合は、相関 ID 転送メカニズムを使用します。SendToVRU ノードは、NAM ルーティング スクリプトまたは CICM ルーティング スクリプトによって実行できます（RunExternalScript ノードも SendToVRU を実行した同じスクリプト内にある必要があります）。

• Unified CVP が NAM で展開され、NIC がスイッチ レッグを処理し Unified CVP が VRU レッグを処理する場合は、NIC の機能に応じて、相関 ID 転送メカニズムまたはトランスレーション ルート転送メカニズムを使用できます（「モデル #4a：NIC 制御ルーティングのみを使用する VRU」を参照）。この場合、次のガイドラインも適用されます。

– 相関 ID 転送が使用される場合、SendToVRU ノードは NAM ルーティング スクリプトまたは CICM ルーティング スクリプトに含めることができます（RunExternalScript ノードも SendToVRU を実行した同じスクリプト内にある必要があります）。

– トランスレーション ルート転送が使用される場合、TranslationRouteToVRU ノードはすべての RunExternalScript ノードとともに NAM ルーティング スクリプトに含める必要があります。つまり、特定の CICM が選択される前に、コールはキューに格納されます（またはプロンプト/コレクトによって処理されます）。このコンフィギュレーションはキューイングにとってあまり意味はありませんが、CICM に制御を委任する前に初期のプロンプト/コレクトを提供するサービス プロバイダーにとって有用な場合があります。

• Unified CVP が CICM で展開され、NIC がスイッチ レッグを処理し Unified CVP が VRU レッグを処理する場合は、トランスレーション ルート転送方式だけを使用できます。TranslationRouteToVRU ノードは、すべての RunExternalScript ノードとともに CICM ルーティング スクリプトに含める必要があります。

Unified CM または ACD によって開始されたコールを追加すると、制約が追加されます。これらのデバイスはどちらも ICM の観点からは ACD と見なされ、ほとんどの場合 CICM レベルで接続されます。これらを（既存のコールの継続ではなく）新規コールと想定して、ルート要求が ACD から発生し、結果のラベルが ACD に返されます。Unified CM も ACD も転送において相関 ID を送信できないため、トランスレーション ルート転送方式だけを使用できます。この制限は、転送先（Unified CVP など）も NAM レベルではなく CICM レベルで接続する必要があることも意味します。

コールが新規ではなく既存のコールの継続である場合、コールはエージェントからエージェントへの既存の着信発信者の転送試行です。お客様は、これらの転送をブラインド ネットワーク転送（つまり、最初のエージェントはドロップされ、発信者は別のエージェントに配信されるか別のエージェントのキューに格納される）またはウォーム コンサルタティブ転送（つまり、発信者が保留状態になっている間に、最初のエージェントは別のエージェントと会話するか別のエージェントのキューで待機し、最終的には 2 番めのエージェントと会話している発信者を残したまま切断する）にする場合があります。これらの転送には、次のガイドラインが適用されます。

• ブラインド ネットワーク転送

元のコールが NIC または Unified CVP スイッチ レッグ経由で NAM に挿入されたかどうかに関係なく、転送ラベルは CICM から NAM、元のスイッチ レッグ デバイスに渡されます。ブラインド ネットワーク転送には、さらに次の 2 つの場合があります。

– スイッチ レッグ デバイスが、相関 ID を処理できる Unified CVP または NIC である場合、相関 ID 転送メカニズムを使用できます。SendToVRU ノードおよびすべての RunExternalScript ノードは、CICM ルーティング スクリプトに組み込まれる必要があります。Unified CVP VRU レッグは NAM に接続できます。ブラインド転送と相関 ID 転送のこの組み合わせは Unified CVP にとって理想的であり、可能な限り使用する必要があります。

– スイッチ レッグ デバイスが、相関 ID を処理できない NIC である場合、トランスレーション ルート転送方式を使用する必要があります。このことは、Unified CVP VRU レッグ デバイスを CICM に接続する必要があることも意味します。

（注） この場合には、NAM レベルの Unified CVP コール サーバを使用できないため、顧客は追加の専用 Unified CVP コール サーバを CICM レベルで展開する必要がある場合があります。

• ウォーム コンサルタティブ転送

Unified CVP は、コールを他の Unified CCE エージェントに転送する Unified CCE エージェントの場合にのみ、ウォーム コンサルタティブ転送を提供します。この場合、Unified CVP は着信コールの初期スイッチ レッグを所有します。TDM エージェントの場合は、ACD 独自のメカニズムが使用され、Unified CVP は関係しません。Unified CCE エージェントへの着信コールが NIC を介して到達する場合は、Unified ICM ネットワーク コンサルタティブ転送機能を使用でき、この場合も Unified CVP は関係しません。

Unified CVP が初期スイッチ レッグを所有し、転送が Unified CCE エージェント間である場合（サポート対象）、Unified CM が相関 ID 転送を処理できないため、トランスレーション ルート転送方式を使用する必要があります。このことも、Unified CVP VRU レッグ デバイスを CICM に接続する必要があることを意味しています。

（注） この場合には、NAM レベルの Unified CVP コール サーバを使用できないため、顧客は追加の専用 Unified CVP コール サーバを CICM レベルで展開する必要がある場合があります。

ホスト型環境でのネットワーク VRU タイプ

ホスト型環境では、対象となる NAM と CICM という 2 つの ICM システムを常に考慮する必要があります。ネットワーク VRU タイプは、NAM と CICM で別々に設定されます。

NAM は、前述したように、新規コールが NIC または Unified CVP から着信するのを検出します。また、Unified CVP VRU レッグ デバイスを認識します。NAM ネットワーク VRU タイプは、それらのデバイスとともに動作する独立した ICM であるかのように設定する必要があります。ネットワーク VRU タイプを設定する場合、転送ラベルが CICM から発信されることがある点は無視できます。

一方、CICM は、新規コールが NIC（具体的には、Intelligent Network Call Routing Protocol（INCRP）NIC）から着信するのを検出します。NAM から着信できるすべての着信番号は、タイプ 7 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。そのネットワーク VRU をすべての VRU スクリプトに関連付け、NAM ネットワーク VRU 定義で必要となるラベルと同じラベルを指定しますが、INCRP NIC をそのルーティング クライアントとします。それ以外は、ペリフェラルにはネットワーク VRU を設定しません。

ゲートウェイ トランク使用状況とサーバ グループ ping の組み合わせ

サーバ グループ要素ポーリング機能を IOS ゲートウェイ トランク使用状況機能と組み合わせると、ハイアベイラビリティ コール シグナリングのための、より迅速なフェールオーバーがソリューションに備わります。この組み合わせを推奨します。

展開上の考慮事項

コンフィギュレーションおよび展開上の考慮事項

• CUSP を使用したプロキシ サーバ展開の場合：

RAI ターゲットの TDM 発信元ゲートウェイを設定し、OPTIONS メッセージ内のステータスをプライマリおよびセカンダリ Unified CVP コール サーバに提供します（レポーティング目的のみ）。データは、ルーティングではなくレポーティングだけに使用されるため、レポーティングがオンになったコール サーバだけに送信する必要があります。

Unified CVP、VXML ゲートウェイ、および CUCM 要素へのサーバ グループ ping で、プライマリおよびセカンダリ CUSP プロキシ サーバを設定します。

発信コール用のプライマリおよびセカンダリ CUSP プロキシへのサーバ グループ ping で、Unified CVP を設定します。

• プロキシ以外の展開の場合：

RAI ターゲットの TDM 発信元ゲートウェイを設定し、OPTIONS メッセージ内のステータスをプライマリおよびセカンダリ コール サーバに提供します。Unified CVP は、レポーティングとルーティング両方の目的でメッセージを処理できます。ルーティングのために使用される場合、ゲートウェイは Unified CVP で単独でサーバ グループ内にある必要があります。

発信コール用の Unified CVP、VXML ゲートウェイ、および CUCM 要素へのサーバ グループ ping で、Unified CVP を設定します。

RAI ターゲットの VXML ゲートウェイを設定し、OPTIONS メッセージ内のステータスをプライマリおよびセカンダリ コール サーバに提供します。

• 最高水準値および最低水準値の設定の推奨事項については、IOS のマニュアルを参照してください。

• Unified CVP コール サーバは、OPTIONS 要求の連絡先ヘッダー内の同じホスト名をゲートウェイに送信するように設定できます。これにより、すべてのコール サーバに対して 1 つの RAI ターゲットを設定できます。5 つのターゲットのみという制限があるため、このことは重要です。設定するパラメータは、オプション ヘッダー オーバーライドと呼ばれます。

制限：

• RAI は現在はプロキシ サーバでサポートされていません。

CUP Server および CUSP Server は現在は OPTIONS メッセージの RAI ヘッダーを処理しないため、その情報によって要素のステータスをマークしません。VXML ゲートウェイがダウンしている場合でも、プロキシは OPTIONS 内の着信 RAI ヘッダーを処理しないため、Unified CVP はコールをプロキシ経由で送信できます。VXML ゲートウェイのサーバ グループを作成し、ルーティング用に RAI 更新を利用するために、Unified CVP でローカル スタティック ルート スキームを使用して、VXML ゲートウェイ コールを除くすべてのコールをプロキシに送信できます。

UUS フィールドの操作

UUI は、ICM スクリプトによって設定でき、Unified CVP によって抽出して SIP メッセージ内で再送信できます。

UUI 処理のシナリオ：

• Generic Type Descriptor（GTD）データが SIP INVITE メッセージの着信コール レッグ内に GTD の MIME 本文形式で存在する場合、Unified CVP は GTD データを着信 GTD として保存し、UUI 部分（存在する場合）が Unified ICM に渡されます。

この GTD 形式は、SIP トランスポートを使用する発信 VoIP ダイヤル ピアで IOS ゲートウェイによってサポートされています。

Unified ICM がデータを変更する場合、変更した UUI を Unified CVP に返信します。Unified CVP は、Unified ICM から受信した UUI データを 16 進数に変換し、UUS（存在する場合）を変更して着信 GTD 値を上書きします。次の形式を使用して、UUS 部分だけが変更されます。

GTD パラメータ値の残りの部分は維持され、発信者 GTD から着信した値が保持されます。

• 着信コール レッグに GTD が存在しない場合、Unified CVP は No GTD Body present in Caller Body という情報メッセージをトレースに出力し、コールは通常のコールとして続行されます。

（注） Unified ICM からの変更された UUI は user.microapp.uui ECC 変数または Call.UsertoUserInfo 変数を使用して渡されます。

両方の変数が使用されている場合は、Call.UsertoUserInfo が優先されます。

変更された GTD は、IP からの発信者および TDM 発信者を含む CVP SIP B2BUA から発信 INVITE MIME 本文に設定されます。接続済みのコールでアウトパルス転送の DTMF ラベルが受信された場合、UUI が Unified ICM によって渡される場合にのみ GTD とともに BYE が送信されます。BYE は SIP INFO の直後に DTMF で送信されます。

UUI の使用

IF ノードなどでコール ECC 変数 user.microapp.uui および Call.UserToUserInfo 変数を調べることにより、Unified ICM スクリプトで UUI を抽出します。これらの変数のいずれかで SET ノードを使用することによって、コールの発信方向で変数を設定できます。

Call.UserToUserInfo の設定が ECC 変数の使用よりも優先されます。

（注） Unified ICM から UUI が受信されない場合、Unified CVP は DTMF ラベルで BYE メッセージを送信しません。

BYE メッセージが受信された場合、受信された BYE の GTD が使用され、他のレッグで送信されます。

次の例に示すように、入力ゲートウェイは、UUI/UUS を持つ GTD が VoIP 側で転送されるように、signaling forward unconditional を使用して設定する必要があります。

例：

REFER および 302 リダイレクトと UUI

Unified CCE スクリプトで UUI が設定され、REFER コール フローが使用されている場合、UUI は MIME 本文に展開され、ATT IP フリーダイヤル NSS 形式に従って 16 進数にエンコードされます。これは、302 リダイレクト応答にも適用されます。

REFER/302 メッセージ内の UUI の NSS MIME 本文形式の例

設計上の考慮事項

UUI データ転送機能は、フックフラッシュ転送または TBCT 転送では使用できません。

SIP ヘッダーの情報を Unified ICM に渡す

Unified CVP では、ICM スクリプト内の操作のために 1 つ以上の SIP ヘッダーを Unified ICM に渡すことができます。Unified CVP 管理者は、Unified CVP Operations Console Server のユーザ インターフェイス（Operations Console）を使用して、特定のヘッダーを選択するか、ヘッダーとそのヘッダー内の特定のパラメータを選択できます。これらの SIP ヘッダーは、CVP ICM サブシステムから Unified ICM に送信される新規コールおよび要求命令メッセージの SIPHeader フィールドで Unified ICM に渡すことができます。

ICM スクリプト内の変数にアクセスするには、Call.SIPHeader フィールドにアクセスします。このフィールドを設定すると、Unified CVP はそのデータを、IVR またはエージェント、あるいは REFER または 302 リダイレクト メッセージへの発信 SIP コール内で使用するようになります。

ヘッダー データを Unified ICM に送信するために使用できる容量は限られており、255 バイトで切り捨てられます。SIP プロトコルの RFC によって、共通ヘッダー フィールド名を省略形で表すメカニズムが提供されています。したがって、ヘッダーを Unified ICM に渡す前に、RFC 3261（および新しく定義されるヘッダー用のその他の RFC）で定義されている簡潔なヘッダー形式がヘッダー タイトルに対して使用されます。

（注） すべてのヘッダーに簡潔な形式があるわけではありません。たとえば、P ヘッダーつまりプライベート ヘッダー（P-Asserted-Identity など）には簡潔な形式がない場合があり、そのため完全なヘッダー名が ICM に渡されます。
簡潔なヘッダー省略形を定義している RFC3261 の表を参照してください。

ストリング形式および解析

次の例は、Operations Console SIP コンフィギュレーション画面の設定に基づいて Unified ICM に送信されるストリングの形式を示しています。

デリミタはパイプ文字です。

データは、この例のようなスクリプトのストリング操作構文で解析できます。

ICM スクリプトからヘッダーを渡す

この機能の目的は、発信 Unified CVP 転送の SIP ヘッダーを変更するためのスクリプト可能オプションを提供することです。発信 SIP INVITES だけで SIP ヘッダー値を指定できます。指定には、ヘッダー値の追加、変更、または削除を含めることができます。

（注） SIP ヘッダー変更機能は、必要に応じて SIP ヘッダーを調整できる強力なツールです。SIP プロファイルを適用するときは注意して、問題の解決とは逆にプロファイルによって相互運用の問題を発生させないようにする必要があります。Unified CVP には、INVITE メッセージだけの発信 SIP ヘッダーを追加/変更/削除する柔軟性があります。この柔軟性により、Unified CVP を数多くのシナリオで展開して、サードパーティ製のデバイスとの相互運用を促進できます。

発信 SIP ヘッダー機能では、必須 SIP ヘッダーは削除または追加できません。基本的な必須ヘッダーに対しては、変更オプションだけが使用可能です。このような SIP ヘッダーには、To、From、Via、CSeq、Call-Id、Max-Forwards などがあります。ICM スクリプト エディタに変更のチェックはありません。変更のチェックは、実際は java SIP スタック レイヤにより DsSipParserException をスローすることによって実施されます。

通常、Unified ICM では、フィールドが 255 文字を超えた場合は切り捨てられます。SIP サブシステムで、Unified ICM スクリプトから与えられたストリングを持つヘッダーの更新または追加に問題がある場合は、Unified CVP ログに WARN タイプのメッセージが表示されるか（DsSipParserException がある場合）、INVITE がそのまま送信されて受信者側で予期しない結果となります。

この機能は、発信 SIP INVITES だけ（再 INVITE ではなく初期の INVITE だけ）に適用できます。INVITE に対する変更は、送信される直前に適用されます。適用できる変更に制限はありません。

変更後のヘッダー長（ヘッダー名を含む）が 255 を超えないようにします。

カスタム SIP ヘッダーの Unified ICM スクリプティングの例

スクリプト エディタでは、次の例にあるように、SIPHeaderInfo のコール変数ストリングを設定するために Set ノードが使用されます。

Unified ICM スクリプトでは、ヘッダー、操作、および値をチルダ文字で区切り、パイプ文字を使用して操作を連結します。

発信ヘッダー操作のスクリプティング例

CVP 8.0(1) のトラブルシューティング情報は、CVP 8.0 Doc-Wiki Troubleshooting ページ（http://docwiki-dev.cisco.com/wiki/Troubleshooting_Tips_for_Unified_CVP_8.0%281%29）にあります。

サンプル スクリプトとオーディオ ファイル

サービス コールバック機能は Unified ICM スクリプトを使用して実装されます。変更可能なサンプル スクリプトが、Unified CVP 8.0(1) インストール メディアの ¥CVP¥Downloads and Samples¥ フォルダで提供されています。これらのスクリプトでは、前述した基準に応じて、発信者にコールバックを提供するかどうかを決定します。提供されているファイルは次のとおりです。

• CourtesyCallback.ICMS（ICM スクリプト）

• CourtesyCallbackStudioScripts.zip（Call Studio スクリプトの集合）

サンプル Studio スクリプトに付随するサンプル オーディオ ファイルが、<CVP_HOME>¥OPSConsoleServer¥CCBDownloads¥CCBAudioFiles.zip に、メディア ファイル インストール オプションの一部としてインストールされます。

• CCBAudioFiles.zip を使用する場合は、そのコンテンツをメディア サーバに展開する必要があります。CCBAudioFiles.zip には、サービス コールバック固有のアプリケーション メディア ファイルが en-us¥app に、Say It Smart 用のメディア ファイルが en-us¥sys にあります。Say It Smart 用のメディア ファイルがすでにメディア サーバ上にある場合は、en-us¥app にあるメディア ファイルだけが必要です。

サンプル スクリプトは、デフォルトの場所である "http://<サーバ>:<ポート>/en-us/app" を使用するように設定されています。サンプル オーディオ ファイルのデフォルトの場所を、ニーズに合わせてサンプル スクリプト内で変更する必要があります（つまり、<サーバ> および <ポート> で、メディア サーバの IP アドレスとポートを代わりに使用します）。

次のサンプル スクリプトがあります。

• BillingQueue

このスクリプトは、コールバックを選択しない発信者またはコールバックを受けた後にキューに短時間再度入る必要がある発信者に対して、キューの音楽を再生します。

このスクリプトは、ビジネス ニーズに合わせてカスタマイズできます。

• CallbackEngine

このスクリプトは、発信者がコールバックを選択したときからコールバックを受けるときまでの間、コールバックの VoIP レッグを保持します。

このスクリプトはカスタマイズしないでください。

• Callback Entry

このスクリプトは、発信者がシステムに入ったとき、および発信者にコールバックを受ける機会が提供されたときに、初期の IVR を処理します。

このスクリプトは、ビジネス ニーズに合わせてカスタマイズできます。

• CallbackQueue

このスクリプトは、発信者がキュー内におり、BillingQueue スクリプトで再生されている音楽を聴いている間、コールのキープアライブ メカニズムを処理します。

このスクリプトはカスタマイズしないでください。

• CallbackWait

このスクリプトは、顧客がコールバックを受けるときに、コールの IVR 部分を処理します。

このスクリプトは、ビジネス ニーズに合わせてカスタマイズできます。

コールバック基準

確立できるコールバック基準の例は次のとおりです。

• 顧客がキューで待機すると予期される時間（分）が（顧客あたりの平均コール処理時間に基づく）一定の最大時間（分）を超えている。

（注） 含まれているサンプル スクリプトは、この方式を使用してコールバックの適格性を判断しています。

• 顧客に割り当てられているステータス（最上位の顧客には、回線上に残らずにコールバックを受ける機会が提供される）

• 顧客が要求したサービス（販売コール、システム更新などをコールバック基準として確立できる）

一般的な使用シナリオ

発信者は、システムによるコールバックを受けることを決定した場合、名前と電話番号を残します。要求はシステム内に残り、エージェントが間もなく使用可能になる（または使用可能である）と判断されると、発信者へのコールバックが行われます。発信者がコールに応答して元の発信者であることを確認すると、発信者は短時間待機した後にエージェントに接続されます。

サービス コールバック機能の一般的な使用は、次のパターンに従います。

1. 発信者は Unified CVP に着信し、コールは通常の IVR 環境で処理されます。

2. Call Studio および Unified ICM サービス コールバック スクリプトが、組織のルール（条件の優先リストなど）に基づいて、発信者がコールバックに適格かどうかを判別します。

3. サービス コールバックを提供可能な場合は、概算待機時間と、エージェントが使用可能になったときに顧客へのコールバックを提供することが、発信者に告げられます。

4. 発信者がコールバック機能を使用しない場合は、通常どおりキューイングが継続されます。

それ以外の場合、コールは残りの手順で示されているように続行されます。

5. 発信者がコールバックを受ける場合、名前の記録と電話番号のキー入力が発信者に要求されます。

6. コールバック情報をログに記録するデータベース レコードが書き込まれます。

（注） データベースがアクセス不可の場合は、発信者にコールバックは提供されず、発信者はキューに入れられます。

7. 発信者はコールの TDM 側から切断されます。ただし、Unified CVP および Unified ICM でのコールの IP 側はアクティブなままです。このことにより、コールは同じキュー位置で保持されます。キューの音楽は再生されないため、この間に使用される VXML ゲートウェイのリソースは、発信者が実際にキュー内にいる場合よりも少なくなります。

8. 発信者が待機しているサービス/スキル カテゴリのエージェントが使用可能に近づくと（コールバック スクリプトが判別）、ユーザはコールバックを受けます。コールバックの際には、正しいユーザがコールを受け入れるようにするために、記録された名前が通知されます。

9. 発信者は、IVR セッションを介して、コールを待機していたユーザであり、コールバックを受ける準備ができていることを確認するよう求められます。

発信者から提供されたコールバック番号に到達できないか（回線がビジーである、RNA、ネットワークの問題など）、ユーザが発信者であることを確認しない場合、コールはエージェントに送信されません。このようにして、エージェントが電話に出るときには、そこに待機している人がいることが常に保証されます。システムでは、エージェントが電話に出るまでに発信者がすでに電話に出ていることを想定しています。

このため、この機能はプリエンプティブ コールバックと呼ばれています。システムでは、エージェントが電話に出るまでに発信者がすでに電話に出ていることを想定しており、発信者は、エージェントと会話する前にキューで最低限の時間待機する必要があります。

10. 通常どおり、コール コンテキストがエージェント画面ポップに表示されます。

発信者への到達試行を設定可能な最大回数および頻度だけ実行した後も発信者に到達できない場合、コールバックが中止され、それに応じてデータベース ステータスが更新されます。ビジネス ルールに基づいて手動でのコールバックが必要かどうかを判断するために、レポートを実行できます。

その他の概念情報

『Configuration and Administration Guide for Cisco Unified Customer Voice Portal』ガイドに、サービス コールバック機能を提供するスクリプトの機能に関するコール フローの説明があります。

サービス コールバックの前提条件と設計上の考慮事項

サービス コールバック機能には、次の前提条件と注意事項が適用されます。

• コールバックを許可するコールは、Unified CVP VXML Server を使用してキューに格納する必要があります。

• Unified CVP Reporting Server をインストールしてライセンスする必要があります。

• 展開のコール フローでは SIP を使用する必要があります。サービス コールバックでは H.323 プロトコルはサポートされていません。

• コールバック機能は、入力ゲートウェイで実行される POTS survivability.tcl スクリプトに依存します。そのため、PSTN で発生したコールだけがサービス コールバックに適格です。IP からの発信者にはコールバックのオプションは提供されません。

• この機能では応答マシン検出は使用できません。コールバック中に実行できる最適な方法は、発信者に短い IVR セッションを要求し、発信者が電話に出る準備ができていることを DTMF で確認応答することです。

• DTMF *8、TBCT、またはフックフラッシュを使用してエージェントに転送されるコールは、サービス コールバック機能を使用できません。

• コールバックはベストエフォート メカニズムです。コールバック中に発信者への到達試行を制限された数だけ行った後、コールバックは終了し、失敗としてマークされます。

• 顧客は、Operations Management Console を使用して、コールバックでコールできる許可番号/ブロック番号を設定する必要があります。

ポスト コール調査の通常の使用方法

通常は、コール中に発信者に対して調査に参加するかどうかの確認が行われます。着信番号に基づくシステム コンフィギュレーションによって、エージェントとの会話の終了時にポスト コール調査が起動されるかどうかが決定される場合もあります。顧客がエージェントとの会話を完了すると、顧客は自動的に調査にリダイレクトされます。ポスト コール調査は、最後のエージェントからの切断イベントによって起動されます。

顧客は、プッシュホン電話機のキーパッドまたは ASR/TTS で音声を使用して、調査中の質問に応答できます。Unified CCE の観点からは、ポスト コール調査コールは別の通常のコールと同じです。ポスト コール調査中に、元の顧客コールからコール コンテキスト情報が取得されます。

ポスト コール調査の設計上の考慮事項

ポスト コール調査機能を使用する際は、次の条件に従ってください。

• PCS が開始されるときに、Unified CM レポーティングのために、エージェントに転送された顧客コールのコール コンテキストが、ポスト コール調査コールのコール コンテキストに複製されます。ただし、コールの転送後にエージェントによって入力されたコール コンテキストは、PCS のコール コンテキストには複製されません。したがって、ポスト コール調査コールのコール コンテキストは、コールがエージェントに転送される時点まで使用可能であったデータに限定されます。

• 調査コールはエージェントの切断時に行う必要があるため、REFER コール フローはポスト コール調査ではサポートされません。REFER では、Unified CVP はコールから削除されます。