Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)Cisco Unified Customer Voice Portal(CVP)Release 8.5(x)
Cisco Unified ICM との対話
Cisco Unified ICM との対話
発行日;2012/03/14 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

Cisco Unified ICM との対話

この章の新規情報

ネットワーク VRU のタイプ

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

タイプ 10 VRU としての Unified CVP

タイプ 5 VRU としての Unified CVP

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

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

ネットワーク VRU タイプと Unified CVP 展開モデル

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

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

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

モデル #3b:UnifiedCVP VXML Server を使用する包括モデル

モデル #4:VRU のみ

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

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

ホスト型実装

ホスト型実装の概要

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

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

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

Cisco Unified Communications Manager および ACD により発生したコールの展開モデルおよびサイジングの意味

サードパーティ製の VRU の使用法

DS0 トランク情報

トランク使用状況ルーティングおよびレポーティング

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

展開上の考慮事項

拡張ユーザツーユーザ情報

UUS フィールドの操作

UUI の使用

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

設計上の考慮事項

カスタム SIP ヘッダー

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

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

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

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

サービス コールバック

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

コールバック基準

一般的な使用シナリオ

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

ポスト コール調査

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

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

Cisco Unified ICM との対話

この章では、Cisco Unified Intelligent Contact Management(ICM)について、Unified CVP との関係という観点から説明します。Unified ICM を考慮して展開モデルを選択する場合もあれば、Unified CVP の展開を考慮して Unified ICM のコンフィギュレーションを選択する場合もあります。

この章では、主に次のトピックについて取り上げます。

「ネットワーク VRU のタイプ」

「ネットワーク VRU タイプと Unified CVP 展開モデル」

「ホスト型実装」

「Cisco Unified Communications Manager および ACD により発生したコールの展開モデルおよびサイジングの意味」

「サードパーティ製の VRU の使用法」

「DS0 トランク情報」

「トランク使用状況ルーティングおよびレポーティング」

「拡張ユーザツーユーザ情報」

「カスタム SIP ヘッダー」

「サービス コールバック」

「ポスト コール調査」

この章の新規情報

表 5-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 5-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明

「DS0 トランク情報」

PSTN ゲートウェイ トランクおよび DS0 情報を着信 SIP コールから Unified ICM に渡します。

「トランク使用状況ルーティングおよびレポーティング」

メモリ、DS0、DSP、および CPU のステータスを、ルーティング、レポーティング、およびスクリプティングのために Unified CVP にプッシュします。

「拡張ユーザツーユーザ情報」

UUI を使用して情報を渡します。

「カスタム SIP ヘッダー」

選択された SIP ヘッダー情報を ICM スクリプト内の変更のために Unified ICM と受け渡しします。

「サービス コールバック」

エージェントを電話で待機するのではなくシステムによってコールバックを受けるオプションを、基準を満たす発信者に提供します。

「ポスト コール調査」

エージェントが切断した後で、発信者にポスト コール調査を要求する DNIS に発信者が転送されるように、コール フローを設定します。


) Generic PG は、Unified CM 用と VRU 用の別々のペリフェラルを必要とする統合された PG です。Generic PG は、Unified CVP でサポートされています。


ネットワーク VRU のタイプ

この項では、最初に Unified ICM のネットワーク VRU のタイプについて全般的に説明し、次にそれらのタイプと Unified CVP 展開との関連について特に説明します。

この項では、次のトピックについて取り上げます。

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

「タイプ 10 VRU としての Unified CVP」

「タイプ 5 VRU としての Unified CVP」

「タイプ 3 またはタイプ 7 VRU としての Unified CVP(相関 ID メカニズム)」

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

このマニュアルでは、 Voice Response Unit (VRU; 音声応答装置)と Interactive Voice Response (IVR; 音声自動応答装置)という用語は、同じように使用されています。

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

ネットワーク VRU タイプと Unified CVP 展開モデル

この項では、ネットワーク VRU タイプと「機能展開モデル」の章で説明した Unified CVP 展開モデルの関係について説明します。この項では、次のトピックについて取り上げます。

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

「モデル #2:コール ディレクタ」

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

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

「モデル #4:VRU のみ」

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

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

Unified ICM では、ネットワーク VRU はコンフィギュレーション データベース エンティティです。アクセスには Network VRU Explorer を使用します。ネットワーク VRU エントリには、次の情報が含まれています。

タイプ:2 ~ 10 の番号。前述したタイプのいずれかに対応しています。

ラベル:設定している特定のネットワーク VRU にコールを転送するために Unified ICM が使用できるラベルのリスト。これらのラベルは、タイプが 3、7、または 10(つまり、相関 ID メカニズムを使用してコールを転送する VRU タイプ)のネットワーク VRU だけに関係し、タイプ 5 の場合は必要ですが使用されません。各ラベルは次の 2 つの部分で構成されています。

番号ストリング。これは、ゲートキーパー(H.323 が使用される場合)、SIP プロキシ サーバまたはスタティック ルート テーブル(SIP が使用される場合)、またはゲートウェイ ダイヤル ピアによって理解可能な DNIS になります。

ルーティング クライアント、またはスイッチ レッグ ペリフェラル。つまり、すべての場合で番号ストリングが同じと考えられても、スイッチ レッグとして機能できる各ペリフェラルには独自のラベルが必要です。

アクティブ コールに関連付けられるまでは、ネットワーク VRU コンフィギュレーション エントリ自体には値はありません。Unified ICM でこの関連付けが行われる場所は、次の 3 つです。

PG エクスプローラ ツールの特定のペリフェラルの [Advanced] タブ

Unified ICM インスタンス エクスプローラ ツールのカスタマー インスタンス コンフィギュレーション

VRU スクリプト リスト ツールのすべての VRU スクリプト コンフィギュレーション

Protocol-Level コール フローに応じて、Unified ICM Enterprise はペリフェラルまたはカスタマー インスタンスを参照し、コールを VRU に転送する方法を決定します。一般的に、Unified ICM Enterprise は、コールが最初にスイッチ レッグに着信するときはスイッチ レッグ ペリフェラルに関連付けられたネットワーク VRU を調べ、トランスレーション ルート メカニズムを使用してコールが VRU に転送されているときは VRU レッグ ペリフェラルに関連付けられたネットワーク VRU を調べます。相関 ID メカニズムを使用してコールが VRU に転送されているときは、カスタマー インスタンスに関連付けられたネットワーク VRU を調べます。

Unified ICM Enterprise は、ルーティング スクリプト内に RunExternalScript ノードがあるたびに、VRU スクリプトに関連付けられたネットワーク VRU も調べます。Unified ICM は、指定されたネットワーク VRU にコールが現在接続されていると判断しない場合、VRU スクリプトを実行しません。

Unified ICM Enterprise Release 7.1 では、ネットワーク VRU タイプ 10 が導入されました。これにより、Unified CVP のネットワーク VRU のコンフィギュレーションが容易になります。ほとんどのコール フロー モデルでは、単一のタイプ 10 ネットワーク VRU が、カスタマー インスタンス、スイッチ、および VRU レッグ ペリフェラルに関連付けられていたタイプ 2、3、7、または 8 ネットワーク VRU の代わりになることができます。タイプ 7 または 8 をまだ必要とする唯一の主要なコール フロー モデルは、VRU のみ(後述するモデル #4a)です。

以前に推奨されていた VRU タイプは、Unified ICM Enterprise 7.1 でも、これまでどおり機能します。新規インストールでは可能であればタイプ 10 を使用する必要があり、既存のインストールではオプションでタイプ 10 に切り替えることができます。

モデル #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 CVP の使用」

「ホスト型環境での 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 を設定しません。

Cisco Unified Communications Manager および ACD により発生したコールの展開モデルおよびサイジングの意味

この項の説明は、キューイングに Cisco IP IVR ではなく Unified CVP を使用するすべての ACD およびすべての Cisco Unified Communications Manager(Unified CM)統合に適用されます。Unified CVP に関して、これらのデバイスは次の特性を共有します。

エージェントを管理するため、転送の宛先になることができます。

ルート要求を発行できるため、スイッチ レッグ デバイスになることができます。

スイッチ レッグ デバイスになることができますが、複数の転送を処理できず、相関 ID を処理できない場合があります。

Unified CM ユーザまたは ACD ユーザは、通常、次の理由のいずれかでルート要求を発行します。

特定のスキル グループの別のエージェントに接続する。

セルフサービス アプリケーションに到達する。

前に受信したコールを前述のエンティティのいずれかにブラインド転送する。

また、Unified CM ユーザは、特に、次の理由のいずれかでルート要求を発行する場合があります。

Unified ICM Outbound Dialer からの正常な発信コールを Unified CVP に基づくセルフサービス アプリケーションに配信する。

ユーザが前に受信したコールを特定のスキル グループまたはセルフサービス アプリケーションにウォーム転送する。

前述の各コールによって、Unified ICM ルーティング スクリプトが起動されます。スクリプトは、使用可能な宛先エージェントまたはサービスを検索する場合もしない場合もあります。適切な宛先が見つかると、対応するラベルを ACD に返信するか、または既存のコールをブラインド転送する場合は元の発信者のスイッチ レッグ デバイスに送信します。コールをキューに格納する必要がある場合、または最終の宛先がエージェントまたはサービスではなくセルフサービス アプリケーションである場合、スクリプトは VRU トランスレーション ルート ラベルを ACD に返信するか、または既存のコールをブラインド転送する場合は元の発信者のスイッチ レッグ デバイスに送信します。

前述のシーケンスでコールが Unified CVP の VRU レッグ デバイスに転送された場合、コールを VoiceXML ゲートウェイに配信するために別の転送が行われます。これらのイベントが発生するには、次の Unified ICM コンフィギュレーション要素が必要です。

ACD からの新規コールまたは既存のコールのウォーム転送の場合:

タイプ 10 ネットワーク VRU(Unified ICM 7.0 を使用する場合はタイプ 2)に関連付けられるように Unified CVP ペリフェラルを設定する必要があります。

ACD がダイヤルした着信番号は、タイプ 10 ネットワーク VRU(Unified ICM 7.0 を使用する場合はタイプ 7)に関連付けられたカスタマー インスタンスに関連付ける必要があります。

Unified ICM 7.0、または Unified ICM 7.1 と Unified CM 以外の ACD では、ACD 着信番号によって起動されたルーティング スクリプトに、コールを Unified CVP のスイッチ レッグに送るための TranslationRouteToVRU ノードと、それに続いて、コールを VoiceXML ゲートウェイおよび Unified CVP の VRU レッグに送るための SendToVRU ノードが含まれている必要があります。

Unified ICM 7.1 と Unified CM では、Unified CM によって起動されたルーティング スクリプトは、相関 ID を使用してコールを Unified CVP に送信するための SendToVRU ノードを使用する必要があります。タイプ 10 VRU は、VoiceXML ゲートウェイ VRU レッグへの 2 番めの転送を自動的に実行します。

そのルーティング スクリプトによって実行されるすべての VRU スクリプトは、タイプ 10 ネットワーク VRU(Unified ICM 7.0 を使用する場合はタイプ 7)に関連付ける必要があります。

既存のコールのブラインド転送の場合:

Unified CVP ペリフェラルがどのネットワーク VRU に関連付けられているかは関係ありません。

ACD がダイヤルした着信番号は、タイプ 10 ネットワーク VRU(Unified ICM 7.0 を使用する場合はタイプ 7)に関連付けられたカスタマー インスタンスに関連付ける必要があります。

ACD 着信番号によって起動されたルーティング スクリプトに、コールを VoiceXML ゲートウェイおよび Unified CVP の VRU レッグに送るための SendToVRU ノードが含まれている必要があります。

そのルーティング スクリプトによって実行されるすべての VRU スクリプトは、タイプ 10 ネットワーク VRU(Unified ICM 7.0 を使用する場合はタイプ 7)に関連付ける必要があります。

Unified ICM は、コールのエージェントまたは ACD 宛先ラベルを選択するときに、そのラベルを受け入れることができるルーティング クライアントをリストしているものを見つけようとします。既存のコールのブラインド転送ではない ACD または Unified CM により発生したコールの場合、使用可能な唯一のルーティング クライアントは ACD または Unified CM です。コールが Unified CVP に転送されると、ハンドオフ動作のために、使用可能な唯一のルーティング クライアントは Unified CVP スイッチ レッグになります。ただし、既存のコールのブラインド転送の場合、(1)元のコールを配信した Unified CVP コール サーバ スイッチ レッグまたは(2)ACD または Unified CM という 2 つのルーティング クライアントが使用可能です。Unified CVP により発生するコールの場合、Unified CVP ペリフェラルの [Unified ICM Setup] 画面で [Network Transfer Preferred] ボックスをオンにすることによって、Unified CVP ラベルを ACD または Unified CM ラベルよりも優先させることができます。

Unified CVP を使用してネットワーク転送を行う場合、エージェントが発信者を新しい宛先へブラインド転送し、[Network Transfer Preferred] オプションが使用されます。このシナリオでは、エージェントは CTI エージェント デスクトップ(電話自体ではない)を使用して転送を起動する必要があります。CTI エージェント デスクトップに加えて、Unified ICM ダイヤル番号計画を使用する必要があります。CTI ルート ポイントと同じ DN で設定された場合、Unified ICM ダイヤル番号計画によって Unified ICM は転送を代行受信し、転送コマンドを JTAPI を介して Unified CM に送信しないで Unified ICM ルーティング スクリプトを実行します。Unified ICM スクリプトがラベルを返すと、そのラベルはネットワーク ルーティング クライアント(Unified CVP)に返され、発信者は新しい宛先に直接送信されます。このコンフィギュレーションにより、エージェントが Unified CM CTI ルート ポイントを使用してネットワーク転送を開始する場合に発生する可能性があるタイミングの問題が回避されます。

サードパーティ製の VRU の使用法

サードパーティ製の TDM VRU は、次の方法のいずれかで使用できます。

初期ルーティング クライアントとして(GED-125 コール ルーティング インターフェイスを使用)

従来の VRU として(GED-125 コール ルーティング インターフェイスを使用)

サービス制御 VRU として(GED-125 サービス制御インターフェイスを使用)

最初の場合と 2 番めの場合、「Cisco Unified Communications Manager および ACD により発生したコールの展開モデルおよびサイジングの意味」の項で説明されているように、VRU は ACD と同様に機能します。ACD のように、VRU は別の送信元から着信するコールの宛先になることができます。コール コンテキスト情報を保持するために、コールをそのようなデバイスにトランスレーション ルーティングすることもできます(この動作は、TranslationRouteToVRU ではなく 従来のトランスレーション ルート と呼ばれます)。また、ACD のように、VRU は独自のルート要求を発行し、ルーティング スクリプトを起動してコールを後続の宛先やセルフサービス処理用の Unified CVP にも転送できます。このような転送では、ほとんど常にトランスレーション ルート転送メカニズムが使用されます。

3 番めの場合、VRU は Unified CVP のスイッチ レッグまたは Unified CVP の VRU レッグの代わりとなるか、完全に Unified CVP の代わりとなることもできます。そのような展開は、このマニュアルの対象範囲外です。

DS0 トランク情報

Unified CVP の Release 8.0(1) では、PSTN ゲートウェイ トランクおよび DS0 情報を着信 SIP コールから Unified ICM に渡す機能が追加されています。

ICM で受信された PSTN ゲートウェイ トランクおよび DS0 情報は、次の 2 つの目的に使用できます。

レポーティング

TrunkGroupID および TrunkGroupChannelNum 情報をルーティング決定のために使用できる Unified CCE スクリプト エディタでのルーティング

この後のロジックの例では、次のメッセージが使用されます。

PSTN トランク グループ データは、次に示すように PSTN ゲートウェイから SIP INVITE メッセージで着信します。

Via: SIP/2.0/UDP 192.168.1.79:5060;x-route-tag="tgrp:2811-b-000";x-ds0num="ISDN 0/0/0:15 0/0/0:DS1 1:DS0";branch

Unified CVP では、PSTN トランク グループ情報を解析して Unified ICM に渡すために、次のロジックが使用されます。

TrunkGroupID の場合、tgrp: を x-route-tag フィールドで探します。

tgrp: が見つかった場合、TrunkGroupID = <tgrp: の後の値> + <ISDN タグと :DS1 タグの間のデータ>

前述の例では、TrunkGroupID = 2811-b-000<スペース>0/0/0:15 0/0/0

見つからなかった場合、TrunkGroupID = <Via ヘッダー内の発信元デバイスの IP アドレス> + <ISDN タグと :DS1 タグの間のデータ>

前述の例では、TrunkGroupID = 192.168.1.79<スペース>0/0/0:15 0/0/0

TrunkGroupChannelNum の場合、:DS0 を x-ds0num フィールドで探します。

見つかった場合、TrunkGroupChannelNum = <:DS0 の前の値>

前述の例では、TrunkGroupChannelNum = 1

見つからなかった場合、TrunkGroupChannelNum = DS0 が見つからなかったことを示す <最大整数値>

前述の例では、TrunkGroupChannelNum = Integer.MAX_VALUE (2^31 - 1)

トランク使用状況ルーティングおよびレポーティング

トランク使用状況機能では、ゲートウェイは、リアルタイム ルーティングのためだけでなく、Unified ICM レポーティングおよびスクリプティングと Unified CVP レポーティングのために、メモリ、DS0、DSP、および CPU のステータスを Unified CVP にプッシュできます。

この機能では、リソース データを Unified CVP に送信するためにプッシュ方式が使用されるため、リソースはより詳細にモニタされ、デバイスのダウンやリソース不足の際にフェールオーバーがより迅速に行われます。

この機能には次のような特性があります。

各ゲートウェイは、そのゲートウェイで動作状況が正常である場合に、CPU、メモリ、DS0、および DSP 情報の SIP OPTIONS メッセージを Unified CVP に 3 分ごとにパブリッシュできます。

プッシュ間隔はゲートウェイで IOS CLI を介して設定されます。

最高水準値レベルに達すると、ゲートウェイは即座に Out-Of-Service = true を示す SIP OPTIONS メッセージを送信し、最低水準値レベルに達するまで Out-Of-Service = false を示す別の OPTIONS メッセージを送信しません。

最大 5 つの Resource Availability Indication(RAI)ターゲットをゲートウェイで設定できます。

トランク使用状況ルーティングは、Unified CCE ルータのトランク グループ ステータスを更新するために使用することもできます。その後、(ICM スクリプトによる)PSTN コールは、SS7 NIC からのプレルートを使用してルータをクエリーして、Unified CVP へのポスト ルートに使用できる最適な入力ゲートウェイを確認できます。


) DS0 は、ゲートウェイ上の空きトランク数に関する使用状況情報を提供するデータ回線です。


ゲートウェイ トランク使用状況とサーバ グループ 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 ゲートウェイ コールを除くすべてのコールをプロキシに送信できます。

拡張ユーザツーユーザ情報

UUI は、ISDN 補足サービスを介してユーザツーユーザ サービスとして提供されるデータです。ユーザツーユーザ情報機能により、メッセージごとに最大 128 オクテットのデータを使用して、コール セットアップおよびコール切断中の発信 ISDN 番号と着信 ISDN 番号間の情報転送が可能になります。

Unified CVP 転送および切断を伴うコールの場合、ユーザツーユーザ情報機能を使用して、PSTN から GTD で提供された ISDN データを Unified ICM ルータに渡し、Unified ICM からサードパーティ製の ACD に渡すことができます。

入力/出力ゲートウェイは、CTI アプリケーションで使用するために、およびサードパーティ製の ACD 統合の向上のために、UUI フィールド内のアプリケーション固有のデータを使用できます。

たとえば、外部システムからのデータ(サードパーティ製の IVR からの発信者が入力した番号など)をキャプチャし、そのデータを新規コールで Unified ICM に渡すのが望ましい場合があります。

Unified CVP は、Unified CVP の発信方向でエージェントや IVR などに、UUI を 16 進数にエンコードした形式で送信できます。

UUI は ISDN データですが、Unified CVP およびゲートウェイは、VoIP 側での SIP メッセージ内の ISDN データのトンネリングをサポートしています。データは、Generic Type Descriptor(GTD)コンテンツ タイプで SIP メッセージのコンテンツ本文にカプセル化できます。

RTP メディア ポートおよびコーデック情報は SDP 本文タイプとして定義されますが、ISDN データは IOS ゲートウェイによって Generic Type Descriptor 本文タイプにカプセル化されます。RTP データと ISDN データの両方が TDM ゲートウェイを介して Unified CVP に送信される場合、両方の本文タイプが SDP 部分と GTD 部分の両方を含む multipart/mixed MIME タイプで送信されます。

拡張 UUI 機能をオンにするには、ゲートウェイで次の設定が必要です。

voice service voip
signaling forward unconditional

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 部分だけが変更されます。

UUS,3,<converted Hex value of data from ICM>

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 を使用して設定する必要があります。

例:

voice service voip
signaling forward unconditional

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

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

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

VER,1.00
PRN,t1113,*,att**,1993
FAC,
UUS,0,(hex encoded UUI string here)

設計上の考慮事項

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

カスタム SIP ヘッダー

カスタム SIP ヘッダー機能により、ICM スクリプト内の変更のために、Unified CVP は選択された SIP ヘッダー情報を Unified ICM と受け渡しできます。この機能により、サードパーティ製の SIP トランクおよびゲートウェイとの SIP 相互運用における柔軟性が大幅に高まります。

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 に送信されるストリングの形式を示しています。

"User-to-User: 123456789"
"f:Name <sip:from@127.0.0.1:6666>;param1;param2|v:SIP/2.0/UDP viaHost"
 

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

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


注意 構文チェックはありません。
Operations Console でのヘッダーの追加または変更中に構文チェックはありません。ヘッダーが正しい SIP 構文となるように注意する必要があります。Operations Console 入力で許可されない文字は、セミコロンとカンマだけです。これらはコンフィギュレーションを格納するために内部的に使用されるためです。この機能によってコール失敗が発生する可能性がありますが、これは「専門家用」の拡張機能であるため、それは障害ではなく機能を誤って使用した結果です。通常、ヘッダー構文に問題がある場合、SIP スタック解析例外のために INVITE を送信できなかったことが CVP ログに示され、コールは中止されます。それ以外には、必須の SIP ヘッダーが誤って変更された場合にコール自体が予期しない宛先に送信されることや、メッセージが RFC に準拠していない場合に受信者がコールを処理できないことがあります。

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 スクリプトでは、ヘッダー、操作、および値をチルダ文字で区切り、パイプ文字を使用して操作を連結します。

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

注意事項

"Call-Info~add~<sip:x@y>;parm1=value1"

RFC3261 に従って、正しいコール情報構文を使用して Call-Info ヘッダーを追加します。

"Via~add~SIP/2.0/UDP viaHost

Via ヘッダーをメッセージに追加します。

"v~add~SIP/2.0/UDP viaHost|f~mod~<sip:123@host>;parm1=value1"

短縮形表記と動作の連結。Via ヘッダーを追加し、From ヘッダーを変更します。

"Call-Info~add~parm1=value1

誤り:
RFC3261 に従い、Call-Info ヘッダーの誤った構文のために失敗します。CVP ログに WARN メッセージが表示されます。これはスタック内で実施されます。

"From~add~<sip:x@y>;parm1=value1"

RFC 3261 に従い、メッセージ内で許可される From ヘッダーは 1 つだけであるため、From ヘッダーの追加と変更は同じことです。これはスタック内で実施されます。

"Call-ID~add~12345@xyz"

From ヘッダーと同様に、許可されるのは 1 つだけです。

"Call-ID~mod~12345@abc"

From ヘッダーと同様に、許可されるのは 1 つだけです。

"User-To-User~mod~this is a test|P-Localization-Info~mod~1234567890"

1 つの ICM 変数 Set ノードで動作を連結するために使用できます。

"Call-ID~rem"

メッセージ内の最初の Call-ID というヘッダーを削除します。

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 CVP によってキューに格納されている発信者は、切断し、後でエージェントが使用可能になる少し前にコールバックを受けることができます(プリエンプティブ コールバック)。この機能は、発信者が電話でエージェントを待機しなくても済むように、発信者へのサービスとして提供されています。

プリエンプティブ コールバックでは、顧客がエージェントへの接続を待機する時間は変わりませんが、発信者は切断でき、音楽を聴きながらキューに残っている必要がなくなります。キューに残っている発信者とコールバック処理を受けている発信者は、コールに応答するエージェントには同じように表示されます。


) コールバックが指定の時間に行われるようにスケジュールすることは、この機能の一部ではありません。


次の図に、サービス コールバック機能に必要なコンポーネントを示します。

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

サービス コールバック機能は Unified ICM スクリプトを使用して実装されます。変更可能なサンプル スクリプトが、Unified CVP 8.5(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 プロトコルはサポートされていません。

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

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

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

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

ポスト コール調査

ポスト コール調査は、通常はコンタクトセンターによって、顧客がコール センター利用経験に満足したかどうかを判別するために使用されます(探していた回答をセルフサービスを使用して見つけたか、コール センター エージェントの対応はよかったか、など)。

Post Call Survey(PCS; ポスト コール調査)機能を使用すると、エージェントが切断した後で、発信者がポスト コール調査を要求する DNIS に転送されるように、コール フローを設定できます。

ポスト コール調査の要求に対して、発信者は次の 2 つの応答から選択できます。

1. IVR 処理中にポスト コール調査に参加するかどうかについて発信者に確認が行われます。参加すると、エージェントが会話を終了した後、調査コールに自動的に転送されます。

2. 発信者は参加するよう求められますが、ポスト コール調査を拒否します。 Unified ICM スクリプトの作成者は、ECC 変数を使用して、コールごとにポスト コール調査機能をオフにできます。ECC 変数を「n」に設定することによって、コールは PCS DNIS に転送されなくなります。

レポートのために、ポスト コール調査コールは元の着信コールと同じ Call-ID およびコール コンテキストを持ちます。

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

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

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

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

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

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

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