次のセクションでは、Unified ICM（親）および Unified CCE（子）の展開で使用されるコンポーネントについて説明します。

Unified CCE システムの周辺機器は、VRU 周辺機器と Unified Communications Manager 周辺機器の機能を組み合わせた単一の論理Unified ICM 周辺機器として機能します。Unified CCE は、Unified IP IVR と Unified Communications Manager 周辺機器を単一のペリフェラルとして扱い、処理とキューイングのためにコールを Unified IP IVR に変換ルートする必要がなくなります。複数の Unified IP IVRが設定されている場合、Unified CCE システム周辺機器は、使用可能な容量がある Unified IP IVR間のコールを自動的にロード バランシングします。

単一の周辺機器として、Termination Call Detail（TCD）レコードおよびその他のレポート データには、コールが周辺機器で使用される全期間のコールの情報が含まれます。Unified CCE システム PG は、コールごとに最大 3 つの TCD（元のルート用、VRU 用、およびエージェント処理時間用）を取得する代わりに、単一のレコードのみを生成します。

Unified CCE システム PGは、Unified CVP をサポートしていません。Unified CCE システム PG のすべてのキューイングと処理は、Unified IP IVRを使用します。Unified CCE システム周辺機器を使用して、独自の PG で別の Unified CVP を使用することができます。

同じ AD ドメインまたはフォレスト、および異なる AD 環境に親/子システムを展開することができます。この展開の通常のシナリオは、アウトソースされたコンタクト センター サイトに子 Unified CCE システムが収容される場合に発生します。この場合、親 AD ドメインには、親ノードであるゲートウェイ PG が含まれます。(管理上の制限のため、ワークグループ メンバーシップは使用しないでください。) この展開は、ルータ、Logger、およびディストリビューターを含む集中型サイト ドメインのメンバーである PG を備えたリモート ブランチ オフィスをサポートします。

下の図に示すトポロジは、この展開の 2 つの AD ドメインの AD 境界を表しています。この図には、アプリケーション サーバが参加するドメインも示されています。親 AD ドメイン境界は メイン サイトを超えて拡張されます。親AD境界には、Unified ICM 集中型コントローラと、ACD PG（従来サイト）および子 Unified CCE サイトのゲートウェイ PG を備えた付属サーバが含まれます。子の Unified CCE サイトとその AD 境界には、Unified CCE サーバがメンバーとして含まれます。AD 境界は、アウトソーシング企業の AD 環境の一部にすることも、AD 境界を Unified CCE 専用の AD ドメインにすることもできます。

親/子展開では、単一の Unified CCMP インスタンスが各子 Unified CCE 管理サーバおよびデータ サーバに接続します。これらのサーバは、物理的に独立したプライマリ管理サーバとデータ サーバとして構成します。各子インスタンスは、Unified CCMP 内の テナント として表示されます。Unified CCMP を介して追加されたリソースは、テナントにリンクされます。標準プロセスは、追加されたリソースを Unified CCE の子からその親に複製します。

親/子展開は、各サイト（子）でローカルの Unified Communications Managerと Unified CCE を使用したローカルの分散型呼処理を提供します。集中型の親 Unified ICM Enterpriseは、企業全体のルーティング、レポート、およびコール制御のために子サイトを制御します。この展開は WAN の停止に関してより耐性があり、各サイトは停止中も継続して動作します。以下の図は導入例を示しています。

この設計では、Unified CVP と独自の管理およびデータ サーバと共に展開される親 Unified ICM Enterprise システムが存在します。各分散型子サイトは、1 つ以上の VM 上のセントラル コントローラで構成される完全な Unified CCE 展開です。Unified CCE のローカル管理およびデータ サーバは、その特定のサイトの構成、スクリプト作成、およびレポート タスクを実行します。Unified CCE ゲートウェイ PGは、Unified CCE を親 Unified ICM に接続し、親 Unified ICMに展開された周辺機器ゲートウェイの一部となります。

Unified CCE ゲートウェイ PGのオプションの展開では、以下のガイドラインに基づき、Unified CCE システム PGと同じ場所に配置します。

• Unified CCE ゲートウェイ PG と Unified CCE システム PG のインスタンス番号が同じ場合、それらの PG には異なる PG 番号を使用します。

• Unified CCE ゲートウェイ PG と Unified CCE システム PG のインスタンス番号が異なる場合、それらの PG に同じ PG 番号を使用することができます。

• 他の PG（VRU PG や MR PG など）をこの VM に追加しないでください。

この設計では、ローカルの Unified CCE 展開は独自のローカル IP ACD として機能し、システム内の他のサイトの可視性はありません。サイト 1 のエージェントは、この展開のサイト2からのコールまたはレポートを表示することはできません。親 Unified ICM Enterprise システムのみが、Unified ICM Enterprise システムに接続されるすべてのサイトのすべてのアクティビティを表示することができます。

Unified ICM 親サイトの Unified CVP は、分散サイトに着信するコールを制御します。Unified CVP は、音声ゲートウェイ（VG）の VXML ブラウザでコールキューイングと処理を提供します。親の Unified CVP を設定して、Unified CVP ルータ ゲートウェイを使用して、障害または応答タイムアウト中にコールを制御します。子 Unified CCE は、子 Unified CVP または子 Unified IP IVRへのイングレス コールを終了することはできません。ローカル Unified IP IVR サーバは、これらの VG から親 Unified CVP コール制御サーバへの接続のローカル バックアップのみを提供します。また、ローカル Unified IP IVR は、ローカル エージェントが応答しない（RONA）コールを、再キューされる Unified CVP に送信せずに、ローカル キュー処理を提供します。

子 Unified CCE 展開は、Unified CCE ゲートウェイ PGによる Unified ICM ポスト ルーティングを使用して、複数サイトのシステム間でコールを転送することもできます。Unified CCE ゲートウェイ PGを使用すると、子 Unified CCE が Unified ICM に、別のサイトの最適なエージェントにコールを転送するか、次に利用可能なエージェントのために集中的にキューに入れるように要求することができます。

分散型 Unified Communications Manager 周辺機器ゲートウェイを使用した従来の Unified CCE 展開とは異なり、親/子展開は、コンタクト センター サイトで完全なローカル冗長性を提供します。ローカル Unified CCE は、Unified CVP ゲートウェイからの着信コールのコール処理を引き継ぎ、ローカル Unified IP IVRでローカル コール キューイングと処理を提供します。この構成は、WAN 障害でシステム ダウンすることができないコンタクト センターの完全な冗長性と 100％ の稼働時間を提供します。

TDM ACD プラットフォームと共に Unified ICM がすでにインストールされている場合、このアプローチでは以下を行う場合に役立ちます。

• Unified CCE での新しいサイトの追加

• 既存のサイトの Unified CCE の転換

このアプローチにより、Unified ICM は、サイト毎に新しい Unified CC Eテクノロジーを導入しつつ、すべてのサイトにわたって企業全体のルーティングとレポートを継続的に実行することができます。

Note	Unified CVP は親と子のどちらでも使用することができます。コール フローは、親の Unified CVPと子の IP IVR で類似しています。大きな違いの 1 つは、子の Unified CVPでキューに入れられたコールに関する情報が、親では（Unified CCE ゲートウェイ PG を介して）利用できないことです。この違いは、親のサービスまたは CallsQNow の最小予想遅延（MED）などのルーティング要素を使用できないことを意味します。

グローバリゼーション、セキュリティ、およびディザスタ リカバリの考慮事項により、ビジネスは複数の地域にわたってロケーションを多様化しています。さらに、コンピュータ間でワークロードを分散し、ネットワーク リソースを効果的に共有し、重要なアプリケーションの可用性を向上させる必要があります。地理的に冗長な サイトのリストに追加します では、重要なアプリケーションを 2 ヵ所の サイトのリストに追加しますに分割します。企業は地理的に冗長 サイトのリストに追加します を展開して、計画的または計画外のダウンタイムを最小限に抑え、地域間でデータを共有します。

地理的に冗長な サイトのリストに追加します は、各 サイトに少なくとも 2 つのロード バランサを持ちます。ローカル冗長性のために、サイト毎に 2 つのロード バランサを使用することができます。

親/子展開では、Unified ICM は 1 つ以上の Unified CCE 子 ACD を制御する親として機能します。Unified ICM システムは、コンタクト センターのネットワーク コールルーティング エンジンです。ネットワーク キューイングは、Unified CVP および Unified CCE ゲートウェイ PG を使用して、子 Unified CCE システムを接続します。子 Unified CCE システムは、親システムへの WAN 接続が失われた場合にローカル コール処理で完全に機能する個々の ACD システムです。この構成は、Unified CCE ソリューションに高レベルの冗長性および可用性を提供します。この品質により、サイトは集中型コール処理リソースから切断されていても、Unified CCE サイトとして継続して機能することができます。

従来の ACD を Unified CCEと統合する企業は、親/子展開を使用します。この展開では、Unified ICM および Unified CCE にはそれぞれ、集中型コントローラ、または TDM ACD PG を備えた Unified Communications Manager PG、ゲートウェイ PG、またはその両方が同じ集中型コントローラを使用するハイブリッド展開があります。これらのカテゴリには、展開内でのコールのルーティング方法に応じて、いくつかのオプションがあります。

従来の VRU を Unified CCE 展開に統合する方法は多数あります。次のセクションでは、最適な方法を決定することができる要因について説明します。主な考慮事項は、VRU からコールを転送する際に VRU の重複トランキングを削除または削減する方法を決定することです。

Unified ICM は、IVR 処理を必要とするコールには、スイッチ レッグと VRU レッグという 2 つの部分があると認識しています。スイッチは、ネットワークまたは発信者からのコールを最初に受信するエンティティです。VRU は、オーディオを再生し、プロンプト/コレクト機能を実行するエンティティです。Unified ICM を使用する場合、Unified CVP はスイッチ ロールまたは VRU ロール、あるいはその両方に参加できます。ネットワーク展開では、複数の Unified CVP デバイスはスイッチと VRU 部分を個別に提供します。

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

• 相関 ID：この方式は、ネットワークがコール参照 ID を VRU に渡せる場合に使用されます。スイッチがあるネットワーク内に VRU がある場合、コール シグナリングがこの情報を保持できます（たとえば、 Unified ICM が使用されるときに 相関 ID 情報がダイヤルされた番号に付加されます）。この機能は、通常は、VoIP ネットワーク内で転送されるコールに適用されます。

• トランスレーション ルート ID：この方式は、VRU が PSTN を介して到達可能であり（たとえば、VRU が顧客構内にある場合）、ネットワークが VRU へのコールの配信においてコール参照 ID 情報を保持できない場合に使用されます。VRU に到達するために Unified ICM で一時的な電話番号（トランスレーション ルート ラベルと呼ばれます）が設定される必要があり、ネットワークは通常はコールを PSTN での他の電話番号ルーティングと同様に VRU へルーティングします。VRU が Unified ICM からの指示を要求する際、VRU はこのラベル（受信される番号のサブセットの場合もあります）を提供し、Unified ICM は同じコールの 2 つの部分を相関させることができます。通常、PSTN キャリアは、この目的で使用するためのトランスレーション ルート ラベルのセットを含んでいます。

Note	展開される VRU は、ネットワーク内（ネットワーク VRU）または顧客構内に展開できます。顧客構内で、Network Applications Manager（NAM）がネットワーク内に展開され、カスタマー ICM（CICM）が顧客構内に展開されます。VRU の位置によって、対応する相関 ID またはトランスレーション ルート ID が使用されます。

Unified CVP タイプ 10 VRU は、Unified CVP の包括モデル展開におけるコンフィギュレーション要件を簡略化します。VRU 専用展開を除く新規インストールにタイプ 10 VRU を使用します。ICM Customers を使用する必要がある展開では、Unified CVP VRU スイッチ レッグから完全に別の Unified CVP への 2 ステップ転送（たとえば、SendToVRU を使用した 2 ステップでの CVP から CVP への転送）は開始できません。これらの 2 ステップ転送を動作させるには、トランスレーション ルートを使用する必要があります。

タイプ 10 ネットワーク VRU は次のように動作します。

• 転送されたルーティング クライアントの責任は、Unified CVP スイッチ レッグにハンドオフされます。

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

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

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

ICM Customers 機能を使用しない Unified CVP 実装で（つまり、単一ネットワーク VRU を使用する Unified CVP 実装で）単一のタイプ 10 ネットワーク VRU を定義する必要があります。Unified CVP スイッチ レッグ ルーティング クライアント用にラベルが 1 つあり、コールを Unified CVP VRU レッグに転送します。コールが Unified CM から Unified CVP に転送される場合、Unified CM ルーティング クライアント用にも別のラベルがあり、このラベルは CVP ルーティング クライアント用に使用されるラベルとは異なるラベルである必要があります。このラベルによって、コールは Unified CVP スイッチ レッグに転送されます。Unified ICM ルータは、このラベルに相関 ID を連結して Unified CM に送信します。この任意の追加の桁を処理するには、Unified CM を設定する必要があります。

同じタイプ 10 ネットワーク VRU を指すように、Unified CVP スイッチ レッグ ペリフェラルを設定してください。また、Unified CVP に転送されるコールのすべての着信番号を、同じタイプ 10 ネットワーク VRU を指すカスタマー インスタンスに関連付けてください。

コール ルーティング インターフェイス VRU または TDM ACD で発生するコールの場合、TranslationRouteToVRU ノードを使用してコールを Unified CVP のスイッチ レッグ ペリフェラルに転送する必要があります。その他のすべてのコールの場合は、SendToVRU ノード（自動の SendToVRU 機能を含むノード（キューイング ノードなど））または RunExternalScript を使用します。

Note	タイプ 5 およびタイプ 2 VRU タイプはサポートされません。これらの VRU タイプの代わりに、タイプ 10 VRU を使用します。

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

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

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

インテリジェント ペリフェラル IVR として使用される場合、Unified CVP は、VRU レッグが不要になったときに Unified ICM から明確な指示を取得するため、タイプ 7 のみをサポートします（コールが引き出されたことを 音声ブラウザから通知されるのを待機するのではなく）。タイプ 3 は廃止されました。

コールにはスイッチ レッグと VRU レッグの 2 つのレッグがあります。異なる Unified CVP ハードウェアを各レッグに使用できます。VRU タイプ 7 として機能する周辺機器ゲートウェイで VRU レッグの Unified CVP とともにサービス ノードを使用すると、IVR アプリケーションを完了します（セルフサービスとキューイングなど）。

Note	VRU 専用を除き、Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には、タイプ 10 VRU を使用してください。

VRU タイプ 7 を使用した Unified CVP アプリケーションの設定例については、http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.htmlの Configuration Guide for Cisco Unified Customer Voice Portalを参照してください。

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

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

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

相関 ID と同じように、コールにはスイッチ レッグと VRU レッグという 2 つのレッグがあります。Unified CVP はスイッチ レッグまたは VRU レッグのいずれかに使用します。たとえば、ネットワーク インターフェイス コントローラ（NIC）、NAM、または CICM が含まれる場合、Unified CVP を VRU レッグでタイプ 8 またはタイプ 10 に設定します。

Note	VRU 専用を除き、Unified ICM 7.1 以降を使用する Unified CVP の新規実装には、タイプ 10 VRU を使用してください。

VRU タイプ 8 またはタイプ 10 を使用した Unified CVP アプリケーションの設定例については、http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.htmlの Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

スタンドアロン セルフサービスは、通常は Unified ICM VRU スクリプトと通信しないため、ネットワーク VRU 設定は必要ありません。Unified ICM ラベル ルックアップを備えたスタンドアロン セルフサービスは、Unified ICM で VRU スクリプトを使用しません。VRU ペリフェラル ゲートウェイ（PG）のルーティング クライアントにルート要求を発行します。このネットワーク VRU は必要ありません。

Unified CCE と Unified CVP は、コール スイッチングのみを担当します。キューイングまたはセルフサービスは提供しないため、VRU レッグはありません。ネットワーク VRU 設定は必要ありません。

VRU 専用では、コールは ICM-NIC インターフェイスを介して Unified ICM に着信します。最初は、Unified CVP はスイッチ レッグに関与しません。唯一の目的は VRU として機能することです。ただし、使用される NIC の種類によっては、コールを受信した後にスイッチ レッグを引き継ぐ必要がある場合があります。

次のセクションでは、VRU 専用タイプについて説明します。

Unified ICM ホスト型環境の Unified CVP は、サービス プロバイダーの メイン サイトにある NAM 上のセルフサービスまたはキュー プラットフォームです。CVP を使用すると、サービス プロバイダーは以下を実行することができます。

• 適切な顧客所有の ACD へのコール ルーティング。

• ACD キューに入れられたコールの制御の保持。

• 基本的なプロンプト アンド コレクト機能またはフル機能のセルフサービス アプリケーションの顧客への提供。

最後のケースは、通常、VXML サーバ がネットワークに組み込まれます。VXML サーバをホストすることも、顧客がホストすることも可能です。社内あるいは顧客が、セルフサービス アプリケーションを作成および所有することができます。顧客が VXML サーバを所有またはホスト可能であることは、セルフサービス アプリケーションでバックエンド サービスを参照する必要がある場合に便利なソリューションです。このソリューションにより、顧客は自社の企業ネットワーク内で通話の制御を保持することができます。顧客は VXML over HTTP のみを VXML ゲートウェイに送信します。

多くの ICM ホスト型環境では、サービス プロバイダーが PSTN キャリアである場合、実際のコール ルーティングはすべて ICM NIC 経由で行われます。PG が（通常）ICM NIC を使用してコールをルーティングする場合、同じ状況が適用されます。ただし、サービス プロバイダーには NIC インターフェイスが存在しない場合があります。その場合、すべてのコールが T3 や E3 などの TDM インターフェイス経由で配信されます。この場合、CVP がスイッチと VRU レッグを処理します。

Unified ICM ホスト型環境では、CVP は有効なネットワーク VRU の NAM で接続します。NAM レベルの代わりに、または NAM レベルに加えて、CICM レベルで CVP が必要になる場合がある展開も可能です。Unified CVP コンポーネントの配置場所に関しては、以下のガイドラインを考慮します。

• NAM の CVP がスイッチと VRU レッグの両方を処理する場合、相関 ID 転送機能を使用します。NAM または CICM ルーティング スクリプトのいずれかが SendToVRU ノードを実行することができます。(SendToVRU を実行する同じスクリプトに RunExternalScript ノードを配置します。)

• NAM の CVP が VRU レッグを処理し、NIC がスイッチ レッグを処理する場合、相関 ID または変換ルート転送機能を使用することができます。これは、NIC の機能に依存します。以下のガイドラインも適用されます。

  • 相関 ID 転送を使用する場合、SendToVRU ノードを NAM または CICM ルーティング スクリプトに配置します。(SendToVRU を実行する同じスクリプトに RunExternalScript ノードを配置します。)

  • Translation Route 転送を使用する場合は、TranslationRouteToVRU ノードとすべての RunExternalScript ノードを NAM ルーティング スクリプトに配置します。コールは、特定の CICM を選択する前にキューに入れられます（またはプロンプトアンドコレクトで処理されます）。この設定では、キューイングは容易ではありません。ただし、この構成により、サービス プロバイダーは CICM に制御を委任する前に初期プロンプトおよび収集を提供することができます。

• CICM の CVP が VRU レッグを処理し、NIC がスイッチ レッグを処理する場合、変換ルート転送方法のみが使用できます。TranslationRouteToVRU ノードとすべての RunExternalScript ノードを CICM ルーティング スクリプトに配置します。

Unified CM または ACD によって開始されたコールを追加すると、別の制約が作成されます。これらのデバイスはどちらも ICM の観点からは ACD と見なされ、CICM レベルで接続します。転送ではなく新しいコールの場合、ルート要求は ACD から送信され、結果のラベルが ACD に返されます。Unified CM または ACD は、転送時に相関 ID を送信することはできません。使用できるのはトランスレーション ルート転送方式のみです。この制限は、転送先が NAM レベルではなく CICM レベルで接続することを意味します。

転送の場合、顧客はブラインド ネットワーク転送またはウォーム コンサルタティブ転送のいずれかを必要とする場合があります。これらの転送には、次のガイドラインが適用されます。

• ブラインド ネットワーク転送: 元のコールが NIC または CVP スイッチ レッグを介して NAM に着信した場合、CICM は NAM の転送ラベルを元のスイッチ レッグ デバイスに渡します。ブラインド転送ネットワークに 2 つの状況があります。

  • スイッチ レッグ デバイスが CVP または相関 ID の処理可能な NIC である場合、相関 ID 転送機能を使用します。SendToVRU ノードとすべての RunExternalScript ノードを CICM ルーティング スクリプトに配置します。CVP VRU レッグを NAM に接続します。ブラインド転送と相関 ID 転送の組み合わせは CVP に適しています。

  • スイッチ レッグ デバイスが相関 ID を処理できない NIC である場合、変換ルート転送方式を使用します。CVP VRU レッグ デバイスを CICM に接続します。

    Note	この状況では、NAM レベルの CVP コール サーバを使用できないため、CICM レベルで追加の専用 CVP コールサーバが必要となります。

• ウォーム コンサルタティブ転送: CVPは、コールを他の Unified CCE エージェントに転送する Unified CCE エージェントに対してのみ、ウォーム コンサルタティブ転送をサポートします。このようなコールの場合、CVP は着信コールの最初のスイッチ レッグを保持します。Unified CM は相関 ID 転送を処理できないため、変換ルート転送方法を使用します。CVP VRU レッグ デバイスを CICM に接続します。

  TDM エージェントの場合、CVP の代わりに ACD 機能を使用します。Unified CCE エージェントへの着信コールが NIC を介して到着する場合、CVP ではなく、Unified ICM ネットワーク コンサルタティブ転送機能を使用します。

  Note	この状況では、NAM レベルの CVP コール サーバを使用できないため、CICM レベルで追加の専用 CVP コールサーバが必要となります。

ICM ホスト型環境には、NAM と CICM の 2 種類の ICM システムがあります。NAM と CICM でネットワーク VRU タイプを別々に構成します。

NAM は着信コールを NIC または Unified CVP から取得し、Unified CVP VRU レッグ デバイスを認識します。NAM ネットワーク VRU タイプを独立した ICM として正確に設定して、それらのデバイスを使用して操作します。ネットワーク VRU タイプを設定するときに、一部の転送ラベルが CICM から着信することを無視できます。CICM は、インテリジェント ネットワーク コール ルーティング プロトコル（INCRP）NIC から到着する着信コールを確認します。

NAM から到着したダイヤル番号を、CICM 上の対応するネットワーク VRU のカスタマー インスタンスに関連付けます。そのネットワーク VRU をすべての VRU スクリプトに関連付けます。NAM ネットワーク VRU 定義で必要な同じラベルを提供しますが、ルーティング クライアントとして INCRP NIC を使用します。ネットワーク VRU が設定されたペリフェラルはありません。

ネットワーク VRU タイプの詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.htmlの Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

転送接続としても知られている取り消しと転送（TNT）は、デュアルトーン多重周波数（DTMF）トーンが Unified CVP によって PSTN にアウトパルスされる場合の転送方式です。TNT は DTMF トーンを PSTN にアウトパルスします。一般的な DTMF シーケンスは *8xxxx です。xxxx は PSTN の新しいルーティング ラベルを表します。TNT DTMF シーケンスを検出すると、PSTN はイングレス ゲートウェイ ポートへのコール レッグをドロップし、TDM ACD ロケーションなどの新しい PSTN ロケーションに発信者を再ルーティングします。この方式を提供できるのは、わずかな PSTN サービス プロバイダーです。

IVR のない既存の ACD サイトで IVR として Unified CVP を使用する場合、TNT を使用できます。その後必要であれば、TDM ACD から Unified CCE にエージェントを移行し、IVR、キューイング ポイント、および転送ピボット ポイントとして Unified CVP を使用する場合があります。単なる IVR として以上に Unified CVP を使用すると、TNT サービスの必要性がなくなります。

Unified CVP 展開で Unified ICM を使用した場合、TDM ACD などの別の Unified ICM ペリフェラルへのコール データの引き渡しを可能にするために、アウトパルスされた DTMF ルーティング ラベルが Unified ICM トランスレーション ルーティング ラベルになる場合があります。このシナリオでは、Unified CVP はコールを完了と見なし、Unified CVP コール制御は終了します。TNT の場合、ターミネーション ポイントまでの転送に失敗すると、Unified CVP はコールの再ルーティング処理をも行うことができません。一部の TNT サービスを使用して、Unified CVP にコールバックを再ルーティングできます。ただし、Unified CVP はこのコールを新しいコールとして処理します。

Two B Channel Transfer（TBCT）は統合サービス デジタル網（ISDN）ベースの解放トランク機能で、一部の公衆電話交換網（PSTN）サービス プロバイダーによって提供されます。TBCT が呼び出されると、イングレス ゲートウェイは、別のコール レッグ（ISDN B チャネル）を使用してターミネーション ポイントに対するコールを行っている間、一時的に最初の着信コールを保留にします。ターミネーション ポイントがコールに応答すると、ゲートウェイは PSTN スイッチに ISDN シグナルを送信し、転送の完了、PSTN スイッチを介したコールのブリッジ、およびイングレス ゲートウェイからのコールの削除を要求します。TNT 転送では、ターミネーション ポイントは、PSTN に接続されている TDM PBX または ACD です。

IVR のない既存の ACD サイトで、Unified CVP を最初は単に IVR として使用する場合は、このプロセスが必要になることがあります。その後必要であれば、エージェントを TDM ACD から Cisco Unified CCE に移行し、Unified CVP を IVR、キューイング ポイント、および転送ピボット ポイントとして使用できます（これにより、TBCT サービスが不要になり、転送失敗時に Unified CVP を使用して再ルーティングを実行できるようになります）。

スタンドアロン セルフサービスには、Unified ICM は含まれません。このモデルは、Unified CM ユーザが VXML ゲートウェイに接続する電話番号をダイヤルし、Unified CVP VXML サーバ アプリケーションを起動する際に実装されます。VXML ゲートウェイは、Unified CM で SIP トランクとして設定されます。コール フローは以下の通りです。

1. 発信者がルート パターンをダイヤルします。

2. Unified CM がコールを VXML ゲートウェイに送信します。

3. VXML ゲートウェイは、設定済みの Unified CVP セルフサービス アプリケーションに基づいて音声ブラウザ セッションを起動します。

4. Unified CVP セルフサービス アプリケーションが、Unified CVP VXML Server に対して HTTP 要求を行います。

5. Unified CVP VXML Server は、セルフサービス アプリケーションを開始します。

6. Unified CVP VXML サーバと VXML ゲートウェイは、HTTP 要求と VXML 応答を交換します。

7. 発信者が切断します。

Call Director にはスイッチングのみで、VRU レッグはありません。Unified CM により発生したコールは、常にターゲットに直接配信されるか、拒否されます。キューイングまたはセルフサービスは関係しません。

Call Director は、コールが実際に Unified CM から発信されていると想定します。元々イングレス VXMLゲートウェイを介して到着し、Unified CMに転送されたコールは除外され、再び転送されます。通常は Unified CM 自体がこれらの転送を処理できるため、このような状況はまれです。ただし、ターゲットが Unified CM 以外の ACD である場合などは例外です。

Call Director では、以下の項目が構成されている必要があります。

• Unified CCE スクリプトを起動する Unified CM ルート ポイント

• タイプ 10 ネットワーク VRU として設定された Unified CVP。

• Unified CVP への VRU トランスレーション ルート

• Unified CVP コール サーバで設定されたトランスレーション ルート着信番号識別サービス（DNIS）番号

• SIP トランクで設定された Unified CM。

• トランスレーション ルート DNIS の Unified CM ルート パターン

コール フローは以下の通りです。

1. 発信者がルート ポイントをダイヤルします。

2. Unified ICM がルーティング スクリプトを起動します。

3. ルーティング スクリプトは、TranslationRouteToVRU ノードを検出し、コールを Unified CVP に転送します（Unified CVP はタイプ 10 ネットワーク VRU として設定されています）。

4. Unified ICM は、トランスレーション ルート ラベルを Unified CM に返します。

5. Unified CM は、SIP プロキシに問い合わせて、Unified CVP コール サーバを見つけます。

6. Unified CM は、コールを Unified CVP コール サーバに接続します。

7. ルーティング スクリプトは Select または Label ノードを検出し、ターゲット ラベルを選択します。

8. Unified ICM は、ターゲット ラベルを（ルート要求を発行したデバイスではなく）Unified CVP コール サーバに返します。

9. Unified CVP コール サーバは、SIP プロキシに問い合わせて、宛先デバイスを見つけます。

10. Unified CVP コール サーバは、SIP を介してターゲット デバイスと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

    ターゲット デバイスが別のルート要求を Unified ICM に発行する場合。コール フローのこの部分は、ステップ 3 で説明した通り、最初の TranslationRouteToVRU が存在しない場合は実行できません。

11. Unified ICM が新しいルーティング スクリプトを起動します。

12. ルーティング スクリプトは Select または Label ノードを検出し、ターゲット ラベルを選択します。

13. Unified ICM は、ターゲット ラベルを（ルート要求を発行したデバイスではなく）Unified CVP コール サーバに返します。

14. Unified CVP コール サーバは、SIP プロキシに問い合わせて、宛先デバイスを見つけます。

15. Unified CVP コール サーバは、SIP を使用してターゲット デバイスと通信し、そのデバイスへのメディア ストリームを確立するよう Unified CM に命令します。

VXML サーバ（スタンドアロン）機能展開では、自動セルフサービスにスタンドアロン IVR ソリューションを提供します。発信者は、Unified CVP イングレス音声ゲートウェイを終端として、市内局番、市外局番、またはフリーダイヤル番号のいずれかから Unified CVP にアクセスできます。また、発信者は、Unified CVP イングレス音声ゲートウェイを終端として、VoIP エンドポイントから Unified CVP にもアクセスできます。また、発信者は、VoIP エンドポイントから Unified CVP にアクセスすることもできます。以下の図は、この展開を説明しています。

この展開では、以下のコンポーネントが服されます。

• イングレス音声ゲートウェイ

• 仮想化音声ブラウザ / VXML ゲートウェイ

• VXML サーバ

• Unified Call Studio

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

以下はこの展開でのオプションのコンポーネントです。

• 自動音声認識/音声合成（ASR/TTS）サーバ

• サードパーティ製のメディア サーバ

• 出力音声ゲートウェイ

• Reporting Server

• CVP コール サーバ

• ICMicm

• Cisco Unified Communications Manager

コール ディレクタの展開では、組織に VoIP ネットワーク上でのコールのルーティング方法および転送方法を提供します。たとえば、企業が ACD または IVR ペリフェラル ゲートウェイ経由で Unified ICM に統合された複数の TDM ACD と TDM IVR ロケーションでこの展開を使用することができます。組織は、Cisco Unified Intelligent Contact Management（Unified ICM）を使用して、PSTN プレルーティングまたは解放トランク転送サービスを使用することなく、これらのロケーション間でコールをインテリジェントにルーティングおよび転送することを望んでいます。この展開では、Unified CVP および Unified ICM はこれらの ACD および IVR ロケーション間でコール データを渡すこともできます。また、Unified ICM はすべてのコールに関して全コール期間のレポートを生成することができます。

多くの場合、コール ディレクタは、TDM ベースのコンタクトセンターから VoIP ベースのコンタクトセンターに移行する場合の最初のステップになります。組織で CVP ベースの IVR サービスと Cisco Unified Contact Center Enterprise（Unified CCE）を実装する場合、組織は現在の Unified CVP 展開を包括機能展開に移行することができます。

発信者は、Unified CVP イングレス音声ゲートウェイを終端として、市内局番、市外局番、またはフリーダイヤル番号のいずれかから Unified CVP にアクセスできます。また、発信者は、VoIP エンドポイントから Unified CVP にアクセスすることもできます。

以下はこの Call Director 展開での必須コンポーネントです。

• イングレス音声ゲートウェイ

• 出力音声ゲートウェイ

• CVP サーバ

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

• Cisco Unified ICM Enterprise

• SIP プロキシ サーバ（SIP 展開の場合）

Unified CVP レポート データベースに格納されているコール情報ほとんどないため、レポート サーバはこのモデルのオプション コンポーネントです。

VRU 専用では、Cisco Unified ICM PSTN ネットワーク インターフェイス コントローラ（NIC）を使用して制御される高度な PSTN スイッチング サービスを利用している組織に、セルフサービス アプリケーションとキュー処理を提供します。NIC と Carrier Routing Service Protocol（CRSP）NIC の 2 つの Unified ICM PSTN NIC により、PSTN でコールの後続のコール制御が可能になります。これらの NIC を使用すると、Unified ICM で ACD や IVR などの Unified ICM ペリフェラルにコールをインテリジェントにルーティングできます。また、Unified ICM が PSTN で通話転送を呼び出すこともできます。次の図は、このモデルを示しています。

VRU 専用機能展開：

• Unified ICM は、コールの処理とキューイングのためにイングレス音声ゲートウェイに別のコールをルーティングする前にコールをルーティングします。エージェントが使用可能になると、Unified ICM はそのエージェントにコールを転送するように PSTN に命令します。エージェントは、Cisco Unified Contact Center Enterprise エージェント、Cisco Unified Contact Center Express エージェント、または ACD エージェントです。必要に応じて、Unified ICM は（NIC を使用して）コールを転送するように PSTN に要求します。これは、Unified ICM がコールを転送するように Unified CVP に要求する場合と同様です。

• イングレス音声ゲートウェイは Unified ICM で管理する PSTN ターミネーション ポイントで、VXML ゲートウェイ、VXM サーバ、ICM サービス、および Unified ICM を使用して VRU サービスを提供します。

• SIP サービスはコール制御に使用されません。すべてのコール制御およびスイッチングが Unified ICM と PSTN によって制御されます。

• Unified ICM はこれらのターミネーション ポイント間でコール データを渡したり（ポップ ウィンドウまたは他のインテリジェント処理用）、すべてのコールに関してレポートを生成したりできます。

以下はこの展開での必須コンポーネントです。

• イングレス音声ゲートウェイ

• VXML ゲートウェイ

• CVP サーバ

• Unified Call Studio

• Cisco Unified ICM Enterprise および NIC（CRSP）

以下はこの展開でのオプションのコンポーネントです。

• ASR/TTS サーバ

• サードパーティ製のメディア サーバ

• SIP プロキシ サーバ（SIP 展開の場合）

• Reporting サーバ

各 エージェント PG は1つの CTI Manager 接続のみをサポートします。各サブスクライバには CTI Manager がありますが、通常は 2 つのサブスクライバのみが エージェント PG に接続します。4 サブスクライバ クラスタ 内のすべてのサブスクライバがエージェント PG に直接接続できるようにするには、エージェント PG の別のペアを追加する必要があります。

以下の図は、エージェント PGへの接続がある CTI Manager の障害を示しています。サブスクライバ C および D のみが、エージェント PG に接続するように構成されています。

以下の条件がシナリオに適用されます。

• 冗長性のために、サブスクライバ A に登録されているすべての電話とゲートウェイは、サブスクライバ B をバックアップ サーバとして使用します。

• サブスクライバ C および D の CTI Manager は、エージェント PGに JTAPI サービスを提供します。

Unified CVPとは異なり、Unified IP IVR はコール制御を CTI Manager に依存しています。Unified IP IVR 展開では、Agent PG接続での CTI Manager の障害により、Unified IP IVR JTAPI サブシステムがシャットダウンします。このシャットダウンにより、Unified IP IVR サーバは、サーバが処理しているすべての音声コールをドロップします。

次に、JTAPI サブシステムが再起動し、バックアップ サブスクライバ上の CTI Manager に接続します。Unified IP IVR は、Unified IP IVR JTAPI ユーザに関連付けられているすべての CTI ポートを再登録します。すべての Unified CM デバイスが正常に登録されると、サーバは VRU 機能を再開し、新しいコールを処理します。

Cisco Unified IP IVR は、Unified Communications Manager クラスタ内の異なるサブスクライバ上の 2 つの CTI Manager と JTAPI 接続を確立できます。この機能により、CTI Manager レベルでUnified IP IVR の冗長性が有効になります。複数の Unified IP IVRサーバを展開することにより、冗長性を高めることができます。複数の Unified IP IVR サーバにより、コール ルーティング スクリプトは、使用可能な IP IVR リソース間でコールの負荷を分散することができます。

次の図は、クラスタで冗長にセットアップされた 2 つの Unified IP IVR サーバを示しています。異なる Unified Communications Manager サブスクライバ上の CTI Manager に接続されている各サーバで、Unified IP IVR グループを設定します。次に、2 番目の CTI Manager を各 Unified IP IVR サーバのバックアップとして追加します。プライマリ CTI Manager に障害が発生すると、Unified IP IVR サーバはバックアップ CTI Manager にフェールオーバーします。

アウトバウンドオプションで Unified IP IVR を使用する場合、すべてのコールを Unified CM でフロントエンドとします。この展開により、サブスクライバのコール負荷が高くなります。サブスクライバは毎秒 5 コールのみをサポートするため、エージェントと VRU に転送されるコールを、Unified SIP プロキシ サーバを使用して複数のサブスクライバに分散します。

アウトバウンド コール センターが 1 つの国（たとえばインド）にあり、顧客が別の国（たとえば米国）にある場合、WAN ネットワーク構造を検討すべき展開もあります。VRU キャンペーンへの転送に Unified IP IVR 展開を使用して、Unified IP IVR が WAN によってアウトバウンド オプション ダイヤラ サーバから分離されている場合。WAN トラフィックを減少するため、独自の Cisco Unified CMをクラスタに含む Unified IP IVR を提供します。

VRU キャンペーンへの転送のためのアウトバウンド オプションの分散展開

この図は、Unified IP IVRを使用した VRU 転送キャンペーンの分散展開を示しています。

この図のソリューションでは、以下の点に注意します。

• 音声ゲートウェイとルータまたは Logger A サーバは、米国の 2 ヵ所のサイト（サイト 1 とサイト 3）に分散されています。

• Unified CM クラスタは、VRU PG と共にサイト 3（米国）にあります。

• 冗長 VRU PG はサイト 3（米国）にあります。

• IP IVR はサイト 3（米国）にあります。

• 冗長化 MRPGまたはダイヤラおよび冗長エージェント PG は、サイト 2 で同じ VM 上にインストールされます。

• SIP ダイヤラは、サイト 3（米国）にある音声ゲートウェイを使用します。

• 音声ゲートウェイは、サイト 3 （米国）で CT3 インターフェイスを含む図に含まれています。ルータは、ダイヤラ コールに 1:1 の冗長性を提供します。

• WAN SIP シグナリング トラフィックがライブ アウトバウンド コールを転送するのを避けるため、冗長 Unified SIP プロキシ サーバはサイト 2 に配置されています。

• 各 SIP ダイヤラは、サイト 2 で独自の統合 SIP プロキシ サーバに接続します。各統一 SIP プロキシ サーバは、サイト 3 で（米国）音声ゲートウェイのセットを制御します。

• Unified SIP プロキシ サーバは、（N + 1）冗長性を提供します。

SIP ダイヤラで録音を有効にする場合、WAN 帯域幅の要件は以下の通りです。

• 応答した各発信コールの帯域幅：

  • G.711 コーデック コールでは、コール プログレス分析の期間に 80 kbps の WAN 帯域幅が必要です。

  • G.729 コーデック コールでは、コール プログレス分析の期間に 26 kbps の WAN 帯域幅が必要です。

• 発信コールのアラート毎の帯域幅：

  • G.711 コーデックのコールには、80 kbps の WAN 帯域幅が必要です。

  • G.729 コーデックのコールには、26 kbps の WAN 帯域幅が必要です

• Unified IP IVR ではセルフサービスのキュー内の発信コールは、WAN 帯域幅を必要としません。

• Cisco Unified ICM 7.0 で Unified CVP を介して後続のコール制御を実行するには、常にトランスレーション ルートを使用し、次の宛先にコールを配信する前にタイプ 2 ネットワーク VRU として Unified CVP にコールをルーティングします。この方法では、Unified CM がこれ以上のラベルを受信できないため、後続のコール転送を管理するために Unified CVP に制御が渡されます。

• キューイング処理、プロンプトとコレクト、またはセルフサービス アプリケーションを実行するには、常にトランスレーション ルートと SendToVRU ノードに従います。SendToVRU は Queue ノードまたは RunExternalScript ノードによって暗黙的に起動できますが、この方法に頼らないことをお勧めします。実際の SendToVRU ノードを常に含めるようにします。

• Cisco Unified ICM 7.1 で Unified CVP を介して後続のコール制御を実行するには、タイプ 10 ネットワーク VRU を使用すれば、トランスレーション ルートは必要ありません。タイプ 10 VRU は、相関 ID 方式を使用し、SendToVRU ノードを使用して Unified CM から Unified CVP への転送を実行します。タイプ 10 VRU で SendToVRU ノードが使用されると、Unified CVP への最初の転送によって呼制御は Unified CVP にハンドオフされ、VRU レッグへの 2 番めの転送が自動的に実行されて、コールは VRU 処理のために音声ブラウザに配信されます。

  Note	このコール フローおよびこのマニュアルのその他のすべてのコール フローは、Cisco Unified ICM 7.0(0) 以降の使用を想定しています。

• タイプ 10 VRU で SendToVRU ノードが使用されると、Unified CVP への最初の転送によって呼制御は Unified CVP にハンドオフされ、VRU レッグへの 2 番めの転送が自動的に実行されて、コールは VRU 処理のために音声ブラウザに配信されます。