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

エージェントのペリフェラル オプション

Cisco Unified CCE 7.0 以降では、Unified CCE エージェント用に 2 つのタイプのペリフェラルをインストールできます。この項では、それら 2 つのタイプのペリフェラルとそれぞれの長所と短所について説明します。

Enterprise Unified CCE ペリフェラル

次の説明は、Cisco Unified Communications Manager（Unified CM）PG が単独で展開されている場合または Unified CM と VRU のペリフェラルが両方とも Generic PG に展開されている場合のどちらかに当てはまります。Cisco Intelligent Contact Management（Unified ICM）ソフトウェアは、これら 2 つのエンティティ（VRU と Unified CM）を別々のペリフェラルとして扱います。このように扱うため、各ペリフェラルで 1 回ルーティングを行う必要があります。そのため、コールがペリフェラルを通過するごとに、各ペリフェラルで Termination Call Detail（TCD）レコードが作成されます。Unified CCE 7.0 までは、Unified CCE を展開する方法はこれだけでした。

独立した VRU と Unified CM のペリフェラルを使用する場合は、トランスレーション ルートを作成して、VRU と Unified CM の間でコールを送信する必要があります。

Enterprise Unified CCE ペリフェラルと別の VRU ペリフェラルを展開すれば、非常に柔軟に設定できるようになります。たとえば、このように展開すれば、VRU ペリフェラルに接続された Unified CVP または Unified IP IVR の使用が可能で、複数の IVR 間のロード バランシングの設定や、トランスレーション ルートを使用したスクリプティングなどが可能になります。

Unified CM のペリフェラルを使用して Unified CCE を設定するときは、Unified CCE は Gateway PG 経由での Unified ICM に対する子としては動作できません。このオプションを利用できるのは、Unified CCE システムのペリフェラルを使用しているときだけです。子と親に関する詳細は、「親/子」を参照してください。

Unified CCE システム ペリフェラル

Unified CCE システム ペリフェラルとは、VRU ペリフェラル（最大 5 個の Unified IP IVR ペリフェラル）と 1 つの Unified CM ペリフェラルの両方を組み合わせて、1 つの論理 Unified ICM ペリフェラルにしたものです。Unified CCE では、これらの Unified IP IVR と Unified CM のペリフェラルが 1 つのペリフェラルとして扱われるので、Unified IP IVR で処理とキューイングを行うためにトランスレーション ルート コールを使用する必要がなくなります。複数の Unified IP IVR が設定されている場合は、使用可能なキャパシティがある Unified IP IVR の間でコールのロード バランシングが Unified CCE システム ペリフェラルで自動的に行われます。

さらに、Unified CCE System PG は単一のペリフェラルなので、Termination Call Detail（TCD; 終端コール詳細）レコードと他のレポート データには、コールがペリフェラル上にあった時間全体の情報が格納されます。最大 3 つの TCD レコード（元のルート用、IVR 用、エージェントの処理時間用）が作成される代わりに、Unified CCE System PG で作成されるレコードは 1 つだけです。

Unified CCE System PG では Unified CVP がサポートされていないので、Unified CCE System PG 内のすべてのキューイングと処理は Unified IP IVR を使用して行われます。独自の PG 上にある独立した Unified CVP を Unified CCE システム ペリフェラルとともに使用することはできます。

Unified System CCE

Unified CCE リリース 7.0 以降では、次の 2 つの方法で Unified CCE をインストールできます。

• 従来の Unified ICM セットアップによるインストール（以前から使用可能）

• Unified System CCE

Unified System CCE（Unified System CCE）は、一部の Unified CCE の展開モデルで使用可能で、システムのインストールと設定を大幅に簡素化できます。簡素化された DVD ベースのインストールが可能で、アドミン ワークステーション上の従来の Unified ICM コンフィギュレーション マネージャの代わりに Unified CCE Web 管理ツールを使用して設定します。

Unified System CCE では、次の 2 つのまったく異なる方法でインストールと展開を行うことができます。

• VRU PIM と Unified CM PIM を組み合わせた既存のペリフェラル モデル。このモデルは変更されていません。このモデルを使用すると、単一のペリフェラル コール管理キューイングやその他の機能を使用できます。

• Unified CCE System PG と独立した VRU PG（どちらもエージェント/IVR コントローラ上に配置）を使用する新しい Unified CVP 展開モデル。Unified CVP が展開されている場合は、System PG 上の CallManager ペリフェラルだけが使用されます。独立した VRU PG には 1 つ以上の VRU PIM が含まれています。これらは、Unified CVP 接続に使用されます。VRU PIM は、Unified CVP コール サーバに接続して、キューに入れられたコールを管理します。この設定の動作は Unified CCE の動作とよく似ていますが、Unified System CCE の簡素化されたインストールと設定という利点があります。

新しい Unified CVP 展開モデルの利点を以下に示します。

• ブランチ オフィス モデル（エッジでのキューイング）：このモデルは IP-IVR では使用できません。

• Unified CVP では、パルス出力転送やフックフラッシュ転送などで PSTN への転送を行うことができます。これにより、コールが回収されて別の場所に転送されます。

• Unified CVP は VXML（オープン スタンダード）に基づいています。

Unified CVP を含む展開では、以下の点を考慮する必要もあります。

• すべての着信コールは、VRU PG に関連付けられている Unified CVP コール サーバによって制御されます（コールの最初のレッグのコール制御は、カスタマー セッションが終了するまで Unified CVP によって管理されます）。

• コールが Unified CM から発信されている場合は、Unified CVP をコール制御（転送や Take Back and Transfer）に使用できません。IVR 処理やキューイング中の保留音に使用することはできます。Unified CM から発信される必要があるコールは、エージェント転送、アウトバウンド、および親のコールだけです。他のすべてのコールは、Unified CVP から発信される必要があります。Unified CVP では、インテリジェントなルーティング決定を行ってコールをサイト内に保持することができます。

• コールのロード バランシングは、Cisco Unified Presence および基本 SIP サービス（または H.323 を使用するゲートキーパー）と、障害リカバリのメカニズムによって管理されます。これは、IP-IVR が使用されている場合のメカニズムとは異なります。IP-IVR が使用されている場合は、ルータによってロード バランシングが行われます。

• 転送および会議のすべてのシナリオで、CTI 統合デバイス（デスクトップと IP Phone のエージェント）を使用することを強くお勧めします。これらのシナリオでコール コンテキストを保持するには、着信番号を Unified System CCE で制御する必要があります（Unified System CCE によって制御される Unified System CCE ダイヤル番号計画か CTI ルート ポイントに着信番号を関連付ける必要があります）。

Unified System CCE は、2 つの特定の本稼動モデルと 1 つのデモ/ラボ展開モデルで提供されています。これらの展開モデルは、1 つのエージェント ペリフェラルで Unified CCE System PG を展開する形態、つまり、1 組の Unified CM クラスタと、1 台から 5 台の Unified IP IVR か、キューイングに使用される 1 台から 10 台の Unified CVP コール サーバに接続する形態になっています。

Unified System CCE は、Unified CCE とはインストール方法と設定方法が異なるので、Unified CCE で従来サポートされていた多くのオプションがサポートされていません。Unified System CCE でサポートされるのは次の展開形態だけです。

• 大規模展開：3 サーバ構成の Unified CCE

サーバ 1：セントラル コントローラ：Call Router、Logger

サーバ 2：エージェント/IVR コントローラ：Unified CCE System PG（CTI サーバと CTI OS を含む）Unified CVP が IVR として展開されている場合は、Unified CVP の VRU ペリフェラル ゲートウェイも有効になります。展開時には、エージェント/IVR コントローラにアウトバウンド コントローラも配置できます。

サーバ 3：管理と WebView レポーティング：AW、HDS、Web 管理サーバ

• 中/小規模展開：2 サーバ構成の Unified CCE

サーバ 1：セントラル コントローラ + エージェント/IVR コントローラ

サーバ 2：管理と WebView レポーティング

• デモ/ラボ展開：1 サーバ構成の Unified CCE（本稼動ではサポートされません）

サーバ 1：セントラル コントローラ + エージェント/IVR コントローラ + 管理と WebView レポーティング

Unified CVP のオプションを選択すると、1 つのボックスで 3 つの PG を同時に実行できます。従来は、実行できる PG はボックスあたり 2 つまでに制限されていました。3 つの PG を同時に実行できるのは Unified System CCE だけです。Unified CCE やその他の展開では実行できません。

大規模展開では、通常 1,000 人以上のエージェントが同時にサポートされ、中/小規模展開では、通常最大 300 人のエージェントが同時にサポートされます。各構成でサポートできるエージェントの具体的な数は、使用するデスクトップ（CTI OS、Cisco Agent Desktop（CAD）、Customer Relationship Management（CRM; カスタマー リレーションシップ マネジメント）統合）、選択するマルチチャネル オプション、Unified Outbound Option の（アウトバウンド コンローラでの）使用など、いくつかのサイジング要因によって異なります。具体的なサイジング要件については、「Unified CCE のコンポーネントとサーバのサイジング」の章を参照してください。

Unified System CCE のインストール ソフトウェアは、Cisco MCS サーバで使用するように最適化とテストが行われており、Cisco MCS サーバまたは同等のサーバでだけ使用できます。この要件は、次に説明するオプションのサーバにも当てはまります。サポートされるサーバの仕様の詳細については、次の URL にある最新版の『 Hardware & System Software Specification (Bill of Materials) for Cisco ICM/IPCC Enterprise & Hosted Editions 』を参照してください。

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

3 つの展開モデルはそれぞれ冗長化できます。つまり、セントラル コントローラとエージェント コントローラのいずれかまたは両方のサーバを二重化して、最大 2 台の管理と WebView レポーティング マシンをサポートできます。二重化したサーバを WAN 経由で分割することもできます。さらに、次のオプションもインストールできます。

• Web コラボレーション オプション用のマルチチャネル コントローラ（Cisco Collaboration Server）と E メール オプション用のマルチチャネル コントローラ（Cisco eMail Manger）

このオプションは、Unified CCE 7.5.1 ではサポートされなくなりました。

• アウトバウンド コントローラ

このオプションは、Unified System CCE DVD からインストールします。このオプションでは、Outbound Option 用に事前設定された Media Routing Peripheral Gateway（MR PG; メディア ルーティング ペリフェラル ゲートウェイ）がインストールされます。エージェント/IVR コントローラ上に共存させる場合は二重化することもできます。専用サーバにインストールする場合は二重化できません。

• Unified Contact Center Management Portal（Unified CCMP）

Unified CCMP ソフトウェアは Unified System CCE DVD に含まれています。前述の各展開モデルで、Unified CCMP を管理と WebView レポーティング マシンに共存インストールできます。Unified CCMP は、使いやすい Web ベースのユーザ インターフェイスを提供して、コンタクト センターのマネージャ、チーム リーダー、または管理者が実行する日常のプロビジョニング作業と構成作業を合理化します。

（注） Unified System CCE にシスコのセキュリティ強化が適用されている場合は、Unified CCMP を共存展開できません。Unified System CCE のセキュリティ強化によって有効になる FIPS 準拠の設定は、Management Portal 内で使用される MD5 ハッシュ アルゴリズムと互換性がないためです。

• Unified CCE ゲートウェイのペリフェラル ゲートウェイ

このペリフェラル ゲートウェイは、（Unified System CCE DVD ではなく）Unified ICM Setup CD からインストールします。このゲートウェイは Unified System CCE System PG を親の Unified ICM Enterprise システムに接続するために使用されます。このペリフェラル ゲートウェイにより、親の Unified ICM からは、Unified System CCE はペリフェラル ゲートウェイに制御された他の ACD と同じように見えるようになります。このペリフェラル ゲートウェイは、Unified System CCE のサーバにはインストールしないでください。このペリフェラル ゲートウェイは、デュプレックス（A/B）のペリフェラル ゲートウェイ ペアを使用する冗長モードで展開できます。このペリフェラル ゲートウェイは、親の Unified ICM 上にだけ設定されており、サポートされる PG の数（上限があります）の一部として数えられることに注意してください。

Unified System CCE を利用できるのは次の展開形態だけです。System IPCC では特定のツール セットを使用してインストールと設定を行います。これらのツールでは他のオプションは処理できません。例：

• Unified System CCE では、PG と同じサーバにアウトバウンド コントローラをインストールできます。この構成は、アウトバウンド コントローラを専用サーバにインストールする構成よりも推奨されます。アウトバウンド コントローラと PG を同じサーバにインストールした場合、その構成は二重化できます。アウトバウンド コントローラをスタンドアロン サーバにインストールした場合は、二重化できません。

• Unified System CCE では、2 つ目の Unified CCE System PG ペリフェラルの追加はできません。1 つのペリフェラルのモデルだけがサポートされています。

• Unified System CCE では、VRU PG の設定および Unified CVP への接続が可能です。Unified CVP は Unified System CCE でサポートされますが、スクリプティングおよびルーティングにいくつかの相違点があります。

ただし、インストールしようとしている展開形態が、Unified System CCE の要件に合致している場合は、次のような利点があります。

• インストールの簡素化：Unified System CCE を 1 つのユニットとしてインストールして設定できるので、個々のコンポーネントを別々にインストールして設定する必要がありません。

• レジストリ設定とデータベース設定の両方に対する Web ベースの管理：Web インターフェイスを使用してすべての設定を行えるので、レジストリ設定を変更するためにローカル セットアップを実行する必要がなくなりました。

• 共存して動作することがテストで確認されている設定

Unified System CCE は Unified CCE を使用する多くのお客様の要件を満たし、インストールと管理の簡素化を実現します。要件がさらに複雑なお客様には、Unified ICM セットアップと Unified ICM コンフィギュレーション マネージャを使用して手動でインストールと管理ができる従来の Unified CCE がサポートされています。Unified System CCE を適用できる構成の場合には、展開時間の削減と管理の簡素化による大きな利点があります。Unified System CCE から Unified CCE への移行、およびその逆の移行は、実行できないことに注意してください。

親/子

Unified CCE Gateway PG を使用すれば、Unified CCE または Unified CCX が Unified ICM システムに接続された従来の ACD のように見えるようになります。Unified CCE Gateway PG は、Unified CCE の System PG または Unified CCX の CTI インターフェイスと通信する Unified ICM システムに PG を提供することによってこの機能を実現します。

Unified CCE Gateway PG を使用して展開するときには、Unified ICM は 親 、Unified CCE は 子 と呼ばれます。

• 親

ネットワークまたはエンタープライズのルーティング ポイントとしての役割を果たす Unified ICM システム。子は親からは ACD のように見えます。親は適切な Unified CCE Gateway PG（Enterprise または Express）を使用して、子 Unified CCE の CTI インターフェイスと通信します。トランスレーション ルートを使用したプレルーティング、ポストルーティング、エンドツーエンドのコール トラッキングなど、Unified ICM が通常実行できるすべての機能を親は実行できます。ただし、子システムで Unified CVP を使用してコールをキューに入れる場合は、親システムはキューに入れられたそれらのコールを見ることができないので、平均待ち時間も、キューイング時間に基づくその他の統計情報も計算できません。

• 子

Unified CCE の System PG、または ACD として機能するようにセットアップされた Unified CCX システム。子は、親からトランスレーション ルーティングされたコールを受信できますが、親に接続された他のペリフェラルは認識できません。また、子は、Unified CCE からのコールを親にポストルーティングできます。この場合のコールは他の Unified ICM コールと同様に処理できます。たとえば、Unified ICM に制御された任意の（TDM または IP）ACD にコールをトランスレーション ルーティングしたり、Unified CVP を使用する Unified ICM ネットワーク キュー ポイントにコールをキューイングできます。

親/子モデルでは、子 Unified CCE は完全に独立して機能するように設定されるので、エージェントにコールをルーティングするのに親に接続する必要はありません。このような独立性によって、子と親の間のネットワークがダウンした場合や、親または Unified CCE Gateway PG との接続に問題が生じた場合でも、ミッションクリティカルなコンタクト センターの運用を完全にローカルで続けることができます。子システムに入力された設定オブジェクトは、自動的に親 Unified ICM に送られて Unified ICM 設定に挿入されます。そのため、ローカル ACD でルーティングとレポーティングを設定した後、Unified ICM 自身の設定を一致させるためにオブジェクトを再び設定する必要がありません。Unified CCE の子システムを使用してアウトソーシングしているために、子システムのすべてのエージェント、スキル グループ、コール タイプが顧客の Unified ICM システムに適用されるわけではない場合など、設定を自動更新する必要がない顧客の場合には、この機能をオフにすることもできます。

Unified CCE Gateway PG を接続できるのは、Unified CCE System PG を使用する Unified CCE の子または Unified CCX 4.0 x 以降のリリースだけです。子の Unified CCE に複数の Unified CCE System PG とペリフェラルがある場合は、それぞれに別途 1 つの Unified CCE Gateway PG ペリフェラルを親の Unified ICM システムにインストールして設定する必要があります。Unified CCE Gateway PG は、複数の子 Unified CCE ペリフェラルを管理できます。最大 5 個の子システムまで可能です。

子 Unified CCE では、コール処理およびキューイング用に IP IVR または Unified CVP を展開できます。Unified CVP を展開する場合、追加の VRU PG を設定する必要があり、このモデルは、IP IVR を展開する場合に使用される単一ペリフェラル モデルには従いません。このため、子でキューに入れられたコールについての情報（およびコールのキューイング時間）を親では利用できないので、キューイング時間に関連する計算はすべて不正確になります（Minimum Expected Delay（MED; 最小予測遅延）や平均応答待ち時間など）。

親/子システムのネットワーク コンサルテイティブ転送（NCT）に関する特記事項

親/子の制約の 1 つは、親の NIC またはその他のルーティング クライアント経由の Network Consultative Transfer（NCT; ネットワーク コンサルテイティブ転送）では子システムで終了するコールを転送できない点です。NCT は TDM ACD に対して機能し、一見するとアーキテクチャにおいて親と子は実質的に同一のように思われますが、親と子は同一ではありません。TDM PG では、CTI サーバは親システムの一部である PG ACD に接続されます。これは、CTI サーバがゲートウェイ PG に接続されることと同じです。別の考え方として、これは CTI サーバではなく ACD に対して CTI を直接使用するようなものであり、この場合、ネットワーク コンサルテイティブ転送はやはり実行できません。親/子の展開では、CTI は子 PG に接続されます。CTI が子 PG に接続される場合、必要なネットワーク コール ID や、ネットワーク コンサルテイティブ転送の実現に必要なその他の情報は提供されません。

ただし、ポスト ルートが子から親システムに対して開始される場合は、親システムの任意のクライアント（Unified CVP や NIC など）を使用してネットワーク ブラインド転送を実行することはできます。

SIP のサポート

Unified CCE 7.0 エージェントは、Unified CM 5.0 SIP 電話モデル 7941、7961、7970、および 7971 を使用できます。モデル 7940 および 7960 の電話も Unified CM 5.0 との SIP をサポートしていますが、Unified CCE エージェントでは使用できません。ローエンド向けモデルの Cisco IP Phone やサードパーティ製の電話も、Unified CCE エージェント用の SIP 電話としては使用できません。

Unified IP IVR は、発信者が入力した番号（DTMF 入力）を JTAPI メッセージとして Unified CM から受け取ります。Unified IP IVR および Unified QM では、インバンド DTMF 番号の検出メカニズムはサポートされていません。インバンド DTMF だけをサポートする（または、RFC 2833 に従ってインバンド DTMF を使用するように設定された）SIP 音声ゲートウェイや SIP 電話を使用する展開では、Unified CM が MTP リソースを呼び出してインバンド DTMF シグナリングをアウトオブバンド シグナリングに変換し、発信者が入力した番号が Unified IP IVR に通知されるようにする必要があります。したがって、このような SIP 電話またはゲートウェイが含まれる環境では、十分な MTP リソースが必要になります。Unified IP IVR または Unified QM アプリケーションと電話間の対話が必要な環境では、この点に注意してください。同様に、CTI ポートではインバンド DTMF（RFC 2833）がサポートされていません。モバイル エージェント機能は CTI ポートに依存しているため、インバンド DTMF（RFC 2833）とニゴシエートする場合は MTP リソースが必要です。

Q.SIG のサポート

Cisco Unified CCE では、Unified CM の展開で Q.SIG トランクの使用はサポートされていません。

Cisco Unified Mobile Agent

Cisco Unified Mobile Agent を使用する展開では、エージェントの呼び出しに使用される音声ゲートウェイの場所について考慮する必要があります。これは、音声ゲートウェイの場所には、サイレント モニタリング、コール アドミッション コントロール、およびその他の領域に関する設計上の考慮事項があるためです。Cisco Unified Mobile Agent の実装に関する設計ガイドおよび考慮事項については、「Cisco Unified Mobile Agent」の章を参照してください。

CTI-OS の複数サーバのサポート

Cisco Unified CCE 7.5.1 では、1 つの PG 上で CTI OS の複数のインスタンスがサポートされるようになりました。Release 7.5 よりも前のリリースでは、ペリフェラル ゲートウェイ上に構成されているペリフェラルの数にかかわらず、ペリフェラル ゲートウェイ/CTI ゲートウェイの構成に存在できる CTI OS のインスタンスは 1 つだけでした Release 7.5.1 では、複数の CTI OS サーバを 1 つの CTI サーバに接続できるようになりました。PG あたり最大 10 台の CTI OS サーバを使用できます。

この展開には次の利点があります。

• 同じ CTI サーバを使用するように複数の CTI OS サーバを構成できるので、簡単。

• この展開モデルでは、多数の小規模のサイトは、それぞれ独自の PG を必要とするのではなく、複数の PIM を持つ 1 つの PG を使用できる。

• このソリューションでは、PIM プロセスや CTI OS サーバ プロセスを含むすべての PG プロセスが同じボックスで実行されるので、ボックス数を減らすことができる。

• このソリューションでは、1 つの PG 下の複数の PIM を使用して異なる Unified CM クラスタに接続できるので、1 つの Unified CCE PG の拡張性も向上できる。これは、Unified System CCE PG には当てはまりません。

この新しい展開モデルの目的はボックス数を減らすことなので、複数の CTI OS サーバは、その他の PG プロセスがある同一のサーバに存在する必要があります。

この展開には次の制約があります。

• 各 PG は、1 つのペリフェラル タイプに対してしか構成できません。

• この展開モデルでは、ARS ペリフェラル タイプおよび ERS ペリフェラル タイプがサポートされます。

• 複数インスタンスの展開では、インスタンスごとに複数の CTI OS サーバの追加はできません。

• この展開モデルは、Unified System CCE ペリフェラルでは使用できませんが、Unified CCE ペリフェラルでは使用できます。

（注） PG は、通常、ペリフェラルと同じ場所に配置されます。PG ごとに複数のペリフェラルを使用すると、一部のペリフェラルが PG から離れた場所に位置することになる場合があります。このような構成は、一部のペリフェラルではサポートされておらず、その場合はサポート対象外のままになります。たとえば、Unified CM（Enterprise および System の展開）は、すべての ACD および Unified CM ペリフェラルが PG とともにローカル LAN に共存していない限り、1 つの PG には集約されません。一般に、PG での ACD との統合に関連する展開ルールはそのまま適用されます。リモートの PG をサポートする展開では、すべてのネットワーク要件（帯域幅、遅延、およびアベイラビリティの要件を含む）を満たす必要があります。

この展開モデルを実装する場合、拡張性は、1 つの CTI OS の拡張能力の 75 % に減少します。たとえば、特定の構成で、1 つの CTI OS サーバによって 1,000 のエージェントをサポートしている場合、複数の CTI OS サーバによって 750 のエージェントをサポートすることになります。これは、CTI OS プロセスの増加によってオーバーヘッドが増加するため、また、クライアントの増加によって CTI サーバで発生する処理の負荷が増加するためです。この例外となるのは、Unified CCE で 2,000 を超えるエージェント（CTI Manager の上限）をサポートするためにこの機能を使用する場合です（例については、図 2-1 を参照してください）。この展開がサポートされるのは Unified CCE PG を使用する場合だけであり、同じ PG 下の VRU はサポートされない（Generic タイプはサポートされない）ことに注意してください。

図 2-1 複数の CTI OS サーバ

バーチャライゼーション サポート

Cisco Unified ICM/Unified Contact Center Enterprise および Hosted Editions Release 7.5(3) から、クライアント アドミン ワークステーション（AW）および特定のペリフェラル ゲートウェイ（PG）のバーチャライゼーション ソリューションを VMware プラットフォームに展開してサーバを統合できます。サポートされる PG およびクライアント AW の Virtual Machine（VM; 仮想マシン）のそれぞれに対するバーチャライゼーション要件、各サーバとのマッピング、CPU プロセッサとメモリの要件については、次の URL にある『 Hardware & System Software Specification (Bill of Materials) for Cisco ICM/IPCC Enterprise & Hosted Editions 』の最新バージョンを参照してください。

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

コンタクト センターの設計と展開に仮想マシンを組み込む前に、次の URL にある『 Virtualization Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted 』に記載されているガイドラインおよび制限を一読し、それに従う必要があります。

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

現時点では、Call Router、Logger、AW ディストリビュータ、HDS、WebView サーバ、CAD サーバなどのその他の Unified ICM および Unified CCE コンポーネント、さらに Cisco Unified Contact Center Management Portal（Unified CCMP）、Cisco Unified Intelligence Suite、Unified Web Interaction Manager（WIM）、Unified E-mail Interaction Manager（EIM）はいずれも仮想化環境でサポートされません。

Unified CCE：Unified CCE System PG

この展開モデルで展開される Agent PG は Unified CCE System PG です。Unified CM と Unified IP IVR（存在する場合）の両方を処理するために必要なペリフェラルは 1 つだけです。このペリフェラルによって、複数の PIM の表示が統合され、複数の Unified IP IVR 間のコールのロード バランシングも行われます。別の方法として、Unified CVP を使用するようにこのモデルを設定することもできます。Unified CVP を使用する場合、Cisco Unified Presence への接続では、Unified CVP コール サーバ間で着信コールを分散することでロード バランシングが行われます。この展開では、Unified CVP コール サーバと通信する VRU PIM（最大 10 個）はそれぞれの PG 上に存在し、Unified CCE System PG 下には存在しません。図 2-3 は、Unified System CCE システムで IP-IVR の代わりに Unified CVP を使用する単一サイト展開を示しています。このモデルでは、1 つのペリフェラル下にすべてのコールが存在するわけではありません。Unified CVP は独自のペリフェラルになります。

図 2-3 Unified CVP を使用する単一サイト展開

この構成を使用する場合、VRU PG は、必要なエージェント数やコールの量に応じて、1 ～ 10 台の Unified CVP コール サーバによって冗長化して展開する必要があります。実用的には、セットアップと設定が非常に簡単である点を除いて、この展開は単一 PG Unified CCE システムと似ています。

IVR：Unified IP IVR による処理とキューイング

この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified IP IVR で実行されます。このモデル（Unified CCE System PG を使用）では最大 5 つの Unified IP IVR を展開できます。Unified CM のダイヤル プランと Unified CCE に制御されたコール スイッチングを使用して、Unified CM の背後に Unified IP IVR が配置されます。すべてのコールは、Unified CM の CTI ルート ポイントに入り、Unified CCE によって制御され、次に Unified CCE System PG によって Unified IP IVR に自動的にトランスレーション ルーティングされます。Unified CCE が Unified IP IVR の使用可能なポート間のロード バランシングを行うので、Unified IP IVR と Unified CM の間のトランスレーション ルートを設定する必要はありません。

ほとんどの場合、このモデルを使用する展開は Unified System CCE でも処理できます。

IVR：Unified CVP による処理とキューイング

通常は単一サイト モデルでは展開されませんが、このモデルでも Unified CVP を使用してコールの処理とキューイングを行えます。Unified System CCE では、最大 10 個の Unified CVP ペリフェラルを備えた Unified CVP に対して 1 つの VRU PG をサポートします。複数の Unified CVP PG が必要な場合は、Unified System CCE ではなく従来の Unified CCE を展開する必要があり、Web 設定ツールが使用できないので、Unified ICM アドミン ワークステーションの ConfigManager アプリケーションを使用してすべての設定を行う必要があります。Unified CVP は Unified CCE System PG ペリフェラルの一部ではないので、コールをコール データとともにペリフェラル間で転送するためのトランスレーション ルートを設定する必要があります。

この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified CVP を使用して実行されます。すべての Unified CVP プロセスを同一のサーバ上で実行すれば、サーバが 1 台で済む可能性もあります。一方、サーバを複数台使用すれば、スケーリングが可能となり冗長性も得られるようになります。冗長性の詳細については、「アベイラビリティを高めるための設計上の注意点」の章を参照してください。

Unified CVP の詳細については、次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/designzone

Unified CCE：Enterprise Unified CCE PG

これらの展開モデルでは、Enterprise Unified CCE のペリフェラルを使用して Unified CM とのやり取りが処理され、別に設定された VRU ペリフェラルを使用して Unified IP IVR または Unified CVP とのやり取りが処理されます。Unified System CCE では Enterprise Unified CCE の PG の使用はサポートされていません。そのため、従来の Unified CCE のセットアップ CD を使用してシステムをインストールする必要があります。つまり、これらのシナリオでは Web 設定ツールは使用できません。

IVR：Unified IP IVR による処理とキューイング

この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified IP IVR で実行されます。複数の Unified IP IVR が配置されている場合は、Unified ICM を使用してこれらの Unified IP IVR 間でコールのロード バランシングを行う必要があります。Unified CM ペリフェラルと Unified IP IVR ペリフェラルの間のトランスレーション ルートは手動で設定する必要があります。Unified CM と Unified IP IVR の間のコールとデータの移動はこのルートを使用して行われます。ロード バランシングは、手動で Unified CCE コール ルーティング スクリプト内の [Translation Route To VRU] ノードで行います。

IVR：Unified CVP による処理とキューイング

通常は単一サイト モデルでは展開されませんが、このモデルでも Unified CVP を使用してコールの処理とキューイングを行えます。Unified CVP には専用の VRU PG があり、Cisco Unified CM PG と同じサーバにロードされているか、Generic PG の組み合せの一部になっています。

この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified CVP を使用して実行されます。すべての Unified CVP プロセスを同一のサーバ上で実行すれば、サーバが 1 台で済む可能性もあります。一方、サーバを複数台使用すれば、スケーリングが可能となり冗長性も得られるようになります。冗長性の詳細については、「アベイラビリティを高めるための設計上の注意点」の章を参照してください。

Unified CVP の詳細については、次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/designzone

Unified CCE：転送

この展開モデルでは、（複数のサイトに対する集中型コール処理モデルの場合も同様ですが）転送元エージェントとターゲット エージェントが同一のペリフェラル上に存在しています。これは、ルーティング クライアントとペリフェラル ターゲットが同一のペリフェラルであることを意味しています。転送元エージェントは、Unified CM 内の CTI ルート ポイントとして設定された特定の着信番号宛てに転送を生成します（たとえば、スキル グループに属する専門家を探します）。

エージェント ペリフェラル（Unified CCE システム ペリフェラルか Enterprise Unified CCE ペリフェラルのいずれか）は、Unified ICM ルータ宛てにルーティング要求を生成します。Unified ICM Router では、着信番号とコール タイプが照合され、適切なルーティング スクリプトが実行されます。このルーティング スクリプトでは、応答可能な専門家が検索されます。

転送されたコールを受信するターゲット エージェント（専門家）が存在すれば、Unified ICM Router から要求元のルーティング クライアント（エージェント ペリフェラル）に適切なラベルが返送されます。このシナリオの場合、ターゲット エージェントが現在ログインしている電話の内線番号がラベルとして使用されるのが普通です。このルーティング応答（ラベル）を受信した Unified CM PIM から Unified CM に JTAPI 転送要求が送信されることで、転送処理が始まります。

ルーティング クライアントにラベルが返送されると同時に、目的のコールから収集されたあらゆるコール データを含むプレコール データが、ペリフェラル ターゲットに送信されます。このシナリオの場合、ルーティング クライアントとペリフェラル ターゲットは同一エージェントのペリフェラルです。これは、転送元エージェントとターゲット エージェントが同一のペリフェラルに関連付けられているためです。ルーティング クライアントとペリフェラル ターゲットが異なるような、より複雑なシナリオは、後半の項で紹介します。

転送されたコールを受信するターゲット エージェントが存在しない場合、そのコールはキュー処理を行う IVR に転送されるように Unified ICM ルーティング スクリプトを設定するのが普通です。このシナリオでは、IP-IVR バリアントが使用されている場合、Unified CCE System PG のロジックは、Unified CCE PG のロジックと異なります。

どちらの場合も、Unified CM に対して IVR へのコール転送を指示する着信番号がラベルとして使用されます。トランスレーション ルーティングまたは correlationID は、Unified CCE System ペリフェラルを使用するときは必要ありませんが、Unified CVP を展開するときは必要です。

IPT：集中型音声ゲートウェイ

大都市圏に小規模なリモート サイト群やオフィス群を持っているために、コール処理サーバや音声ゲートウェイを複数設置することが効率的ではない企業には、このモデルが最適です。サイトの規模が大きくなったり地理的に離れた場所に設置されるようになると、音声ゲートウェイを分散して配置する方が好結果につながることもあります。

図 2-4 に、Unified System CCE による展開を使用したこのモデルを示します。図では IP-IVR を使用する展開が示されていますが、IP-IVR の代わりに Unified CVP を使用することもできます。

図 2-4 複数のサイトに対して集中型コール処理と集中型音声ゲートウェイを展開した場合

利点

• エージェントが数人だけのリモート サイトで必要となるのは小規模なデータ スイッチ、ルータ、IP 電話、エージェント デスクトップだけであり、そこで必要となるシステム管理とネットワーク管理のスキルもごく限られたものになります。

• このような小規模なサイトとオフィスでは、WAN リンクの障害に備えた緊急連絡用の POTS 回線を除き、PSTN と直接接続するトランクが不要です。

• PSTN トランクでは小規模なリモート サイト用のトランクを集約できるため、より効率的な運用が可能になります。

• Unified CCE キュー ポイント（Unified IP IVR または Unified CVP）にはすべてのキュー ポイントが集約されているので、効率的な運用を図ることができます。

• コールのキューイング（最初のキューイングとそれに続くキューイング）中は、VoIP の WAN 帯域幅が消費されません。コールが WAN 経由で拡張されるのは、発信者に応答できるエージェントがいる場合だけです。

単一サイト展開モデルに関するように、従来の Unified CCE の設定を使用するときには、同じオプションがすべて存在します。たとえばマルチサイト展開でも、Unified ICM ソフトウェアをすべて同一のサーバで実行する場合や複数のサーバで実行する場合があり得ます。Unified ICM ソフトウェアは、冗長系を構成してインストールする場合と冗長系を構成せずにインストールする場合があり得ます。Unified ICM ソフトウェアは、Unified CCE System PG または Unified CCE PG のどちらかとともに展開できます。このシステムは Unified System CCE を使用して展開できます。この展開モデルでは、Unified CM および Unified IP IVR サーバまたは Unified CVP サーバの数は指定されていません。同様に、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN 接続についても指定はありません。他のバリエーションについては、「IPT：単一サイト」を参照してください。

ベスト プラクティス

• リモート サイトのエージェントの電話への RTP トラフィックには VoIP WAN の接続が必要です。

• VoIP WAN の帯域幅消費を抑えるために、リモートサイトのエージェントの電話までの RTP トラフィックを圧縮する必要がある場合もあります。サイト内のコールは非圧縮とすることが望ましいので、シスコ ユニファイド コミュニケーションの展開デザインによっては、トランスコーディングが必要となります。

• IP 電話から Unified CM クラスタへの Skinny Client Control Protocol（SCCP）または SIP コール制御トラフィックは、WAN を経由して流れます。

• Unified CCE Agent Desktop で送受信される CTI データは、WAN を経由して流れます。これらのリンクでは、十分な帯域幅と QoS のプロビジョニングが不可欠です。

• リモート サイトには音声ゲートウェイがありません。したがって、もしもトランクと組み合わせた音声ゲートウェイがリモート サイトにあれば公衆電話交換網の電話による市内通話が可能な番号に対しても、顧客は市外電話番号をダイヤルする必要があります。中央サイトにおけるフリー ダイヤルで受け付けることが可能な業務であれば、この問題を回避することも可能です。その場合、顧客にフリー ダイヤル番号を提供し、その番号へのコールはすべて集中型の音声ゲートウェイのある場所にルーティングさせます。ただしこの方法では、コール センターがフリー ダイヤル料金を負担する必要があります。この事態は顧客が PSTN の市内局番でダイヤルできるようにすれば避けられます。

• PSTN トランクと組み合わせたローカル音声ゲートウェイがないため、緊急電話（119、110）へのアクセスに問題があります。この問題は、Unified CM のダイヤル プランで管理する必要があります。ほとんどの場合、ローカル トランクでは緊急電話（119、110）は地元の緊急連絡先に接続されます。

• Unified CM による Location に基づくコール アドミッション コントロールが失敗すると、ルーティングされたコールが接続解除されます。したがって、リモート サイトと接続する帯域幅は十分余裕を持ってプロビジョニングすることが重要です。また、WAN の QoS を適切に設計することは欠かせません。

IVR：Unified IP IVR による処理とキューイング

中央サイトが一箇所だけの展開では、単一サイト展開の場合と同様にすべてのコールに対するキューイングが Unified IP IVR で行われます。コールがキューイングされている間は、WAN 上に RTP トラフィックが流れません。無応答時の転送や再ルーティングで再キューイングが必要になっても、キュー処理で RTP トラフィック フローが WAN 上を流れることはありません。これにより、リモート サイトとの接続に必要な WAN 帯域幅を抑えることができます。

IVR：Unified CVP による処理とキューイング

このモデルでは、Unified IP IVR と同様に Unified CVP が使用されます。

Unified CCE：転送

このシナリオでの転送は、コンタクト センターの観点から見れば、単一サイトのシナリオと同じです。したがって、転送元エージェントがターゲット エージェントと同じ LAN にいるか、別の LAN にいるかに関係なく、単一サイト モデルの場合と同じコールとメッセージのフローが発生します。違うのは、QoS を確保する必要があることと、適切な LAN/WAN ルーティングを設定する必要があることだけです。QoS に配慮した WAN のプロビジョニングについての詳細は、次の URL にある最新版の『 Cisco Network Infrastructure Quality of Service Design 』を参照してください。

http://www.cisco.com/go/designzone

（発信者ではなく）エージェントがコンサルテイティブ転送を行なった結果が Unified IP IVR ポートにルーティングされてキューイング処理の対象となる場合はトランスコーディングが必要になります。これは、Unified IP IVR で生成できるのが G.711 メディア ストリームだけであるためです。

IPT：分散型音声ゲートウェイ

集中型コール処理モデルでは、複数の入力音声ゲートウェイを別々の場所に設置するバリエーションも可能です。この分散型音声ゲートウェイのモデルが適するのは、小規模なサイトを数多く持ち、それぞれのサイトで市内からの電話に対応するローカルな PSTN トランクを必要とする企業です。このモデルは、市内電話用のローカルな PSTN 接続とローカルな緊急電話へのアクセスを提供します。図 2-5 はこのモデルを示したものです。

図 2-5 複数のサイトに対して集中型コール処理と分散型音声ゲートウェイを展開した場合

キューイングと処理に使用する Unified IP IVR を持つこの展開モデルでは、各サイトにインバウンドしたコールをそのサイトにいるエージェントだけで処理するように制限することが望ましいとも言えますが、必ずしもそれが必要というわけではありません。インバウンド コールを同一サイト内で処理するよう制限すると、次の状況が適用されます。

• 入力音声ゲートウェイからエージェント向けのコールで消費される VoIP WAN 帯域幅を節約できます。

• コールは、キューにある間または集中型 Unified IP IVR で処理されている間は、引き続き VoIP WAN を通過します。

• コールのキューイング時間と処理時間が長くなるため、サイトに着信するコールに対して顧客サービス レベルが低下する可能性があります。

• キューイング時間が長くなる可能性があります。これは、この Unified CCE の設定では、他のサイトのエージェントが利用可能であっても、現在のローカル サイトのエージェントに空きが出るまで待つためです。

• 処理時間が長くなる可能性があります。これは、より適したエージェントが他のサイトに存在しても、WAN 帯域幅の消費を抑えるためにコールはローカル エージェントにルーティングされるためです。

この展開モデルで、コールが到達したサイトへのコールを制限するには、エージェント用の別個のスキル グループを場所ごとに作成する必要があります。場所に関係なく特定のスキルのエージェントにコールをルーティングするには、エンタープライズ スキル グループを使用して、場所ごとのスキル グループを結合できます。

展開を担当するチームにとっては、運用コストと顧客の満足度との妥協点を慎重に評価し、各顧客の事情に合った適切なバランスを確立することが重要になります。たとえば、特定の重要顧客からのコールは他のサイトにルーティングしてキューイング時間を短縮したうえで経験豊かな担当者の手に委ねられるようにし、それ以外の顧客からのコールは着信したサイトのエージェントによる扱いに限定するという方法も可能です。

Unified CCE の実際の展開で集中型の音声ゲートウェイと分散型の音声ゲートウェイを組み合わせることも可能です。フリー ダイヤル サービスを提供する 1 つの PSTN キャリアに集中型の音声ゲートウェイを接続し、市内電話サービスを提供するそれ以外の PSTN キャリアに分散型の音声ゲートウェイを接続するという方法もあります。

市内 PSTN からのインバウンド コールには、ダイヤルイン方式（DID; Direct Inward Dial）とコンタクト センター コールの両方が可能です。すべてのインバウンド コールとアウトバウンド コールに対する要件を把握し、音声ゲートウェイの最も効率的な設置場所を決めることが重要です。どのような人たちが、何の目的で、どこから、どのような方法で電話しているのかを特定します。

複数サイトの展開と分散型音声ゲートウェイを使用する従来の Unified CCE モデルでは、Unified ICM のプレルーティング機能を利用して、複数のサイト間でコールを動的にロード バランシングできます。Unified ICM プレルーティング サービスを提供している PSTN キャリアのリストについては、次の URL にある『 Pre-installation Planning Guide for Cisco ICM Enterprise & Hosted Editions 』を参照してください。

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

ローカルな PSTN トランクと、それとは独立したフリー ダイヤル トランクの両方を備える音声ゲートウェイでコンタクト センターへのコールを受ける複数サイト環境では、Unified ICM プレルーティング ソフトウェアを使用してフリー ダイヤル コンタクト センターへのコールとローカル コンタクト センターへのコールとの間でのロード バランシングが可能です。たとえば、サイト 1 とサイト 2 の 2 つのサイトによる展開を考えます。サイト 1 では現在すべてのエージェントでコールを処理中であり、数多くのコールがキューにあるとします。一方、サイト 2 ではキューにあるコールがわずかであるか、あるいは一部のエージェントが空いている状況であるとします。このシナリオでは、Unified ICM を通じてフリー ダイヤル プロバイダーが抱えているフリー ダイヤル コールのほとんどまたはすべてをサイト 2 にルーティングできます。Unified ICM が提供するこのタイプの複数サイト間ロード バランシングは動的で、すべてのサイトの呼量変動に伴って自動的に調整されます。Unified System CCE の展開モデルでは Unified ICM プレルーティングがサポートされていないことに注意してください。Unified ICM プレルーティングが使用できるのは、従来の Unified CCE または PSTN に対するプレルーティング インターフェイスが親の Unified ICM にある親/子モデルの場合だけです。

前述の 2 つの展開モデル同様、数多くのバリエーションが存在します。これらのバリエーションでは、Unified ICM、Unified CM、Unified IP IVR サーバまたは Unified CVP サーバの数とタイプ、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN 接続などがそれぞれ異なります。

分散型音声ゲートウェイを使用する複数サイト環境で Unified CVP を使用すれば、リモート サイトにある入力音声ゲートウェイを従来型の Unified CCE システムの一部として利用できるので、Cisco IOS 音声ゲートウェイに組み込まれている VoiceXML ブラウザをローカルに使用してコール処理とキューイングをリモート サイトで実現できます。分散型ゲートウェイで Unified CVP を使用すれば、集中型のキューイング プラットフォームへ VoIP WAN 経由でコールをキューイングしなくても、入力音声ゲートウェイでローカルにコールをキューイングできます。リモート サイトの音声ゲートウェイに WAN 経由で渡されるのは、コールの処理方法、キューイング方法、およびエージェントへの転送方法を指示するコール シグナリング（H.323 と VoiceXML）だけです。これらのモデルでは、コールがサイトに到着するとすぐに Unified ICM がコールを制御するので、サイトへのプレルーティングが不要な場合もあります。ローカル障害に対処するためにサイトとフェールオーバー（ロールオーバー）トランクにコールを割り当てる場合には、必要に応じて基本的なキャリア割り当て率を使用できます。

利点

• リモート サイトで必要となるシステム管理スキルがごく限られたもので済みます。これは、サーバ、各種機器、およびシステムのほとんどの設定が 1 か所から集中管理されるためです。

• Unified ICM プレルーティング オプションにより、サイト間でコールのロード バランシングが可能です。ローカル PSTN トランクを使用しているサイトのほか、フリー ダイヤル PSTN トランクを使用しているサイトもロード バランシングに参加できます。

• 各リモート サイトに着信してそのサイトのエージェントにより処理されるコールに関しては、WAN RTP トラフィックが不要です。

• Unified CVP は、音声ゲートウェイ自身の Cisco IOS にある VoiceXML ブラウザを使用して、リモートサイトでコール処理とキューイングを行います。そのため、中央のキューと処理ポイントに VoIP WAN 経由でコールを移動する必要がありません。

ベスト プラクティス

• Unified IP IVR または Unified CVP、Unified CM、および PG（Unified CM と IVR または Unified CVP の両方）は、同じ場所に設置します。このモデルで WAN を介して分離できる Unified CCE 通信は次の項目に限られます。

– Unified ICM セントラル コントローラと Unified ICM PG 間の通信

– Unified ICM PG と Unified CCE Agent Desktop 間の通信

– Unified CM と音声ゲートウェイ間の通信

– Unified CM と電話間の通信

– Unified CVP コール制御サーバとリモート音声ゲートウェイ間の通信（コール制御）

• コールの処理がインバウンド先サイトだけに制限されない場合や、サイト間でコールが取り交わされる場合は、WAN を通じて流れる RTP トラフィックが増加します。この場合はサイトの間や場所の間を流れるコールの最大量を見極めることが重要です。Location に基づいて Unified CM で実行されるコール アドミッション コントロールが失敗すると、ルーティングされたコールが接続解除されます（Unified CM 内での再ルーティングは現在サポートされていません）。このため、リモート サイトとの接続帯域幅には十分な余裕を持ってプロビジョニングし、WAN の QoS を適切に設計することが重要です。中央サイトで IP IVR によって処理されるコールも考慮する必要があります。

• 分散した音声ゲートウェイと集中化 Unified CM サーバとの間では、WAN を経由して H.323、SIP、または MGCP のシグナリング トラフィックが流れます。WAN の QoS を適切に実現することが不可欠です。また、シグナリングの遅延は次の URL にある最新版の『 Cisco Unified Communications Solution Reference Network Design (SRND) 』に示されている許容値の範囲内に収める必要があります。

http://www.cisco.com/go/designzone

Unified CCE：Unified CCE System PG

コンタクト センターのコンポーネントの展開は他の複数サイトの集中型コール処理の展開と基本的に同じなので、同じ利点と制限が Unified CCE System PG を使用した Unified CCE の展開にも当てはまります。

さらに、Unified ICM プレルーティングを使用してキャリアとやり取りして音声ゲートウェイにコールを配信する場合は、NIC ルーティング クライアントから Unified CCE System PG へのトランスレーション ルートを Unified ICM アドミン ワークステーションの ConfigManager アプリケーションを使用して手動で設定する必要があります。プレルーティングは Unified System CCE の展開の一部としてはサポートされていません。

Unified CCE と IVR：Unified IP IVR による処理とキューイング

中央サイトで処理およびキューイングされるすべてのコールをサポートできるように、WAN の帯域幅をプロビジョニングする必要があります。

Unified IP IVR を集中配置することで、Unified IP IVR を小規模な複数サイトに分散展開する場合と比べて、Unified IP IVR のポート利用効率を高めることができます。

IVR：Unified CVP による処理とキューイング

Unified CCE System PG では Unified CVP はサポートされません。VRU ペリフェラルを別途設定して展開する必要があります。つまり、コールをコール データとともにペリフェラル間で転送するためにトランスレーション ルートを設定する必要があります。ただし、このモデルで Unified CVP を使用すれば VoIP WAN を介して集中型 Unified IP IVR でコールを処理する必要がなくなるので、リモートの分散型入力音声ゲートウェイで発信者のキューイングと処理が行えるという利点があります。

コールの処理とキューイングに Unified CVP を使用することで、WAN を経由して流れる音声トラフィックの量を削減できます。コールはリモート ゲートウェイで Unified CVP によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終端させる必要がありません。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。

Unified CCE：Unified CCE PG

コンタクト センターのコンポーネントの展開は他の複数サイトの集中型コール処理の展開と基本的に同じなので、Unified CCE PG を使用した Unified CCE の展開にも同じ利点と制限が当てはまります。

さらに、Unified ICM プレルーティングを使用してキャリアとやり取りして音声ゲートウェイにコールを配信する場合は、別個の Unified CVP と Unified CM のペリフェラルを Unified ICM に設定した従来型の Unified CCE を使用して NIC ルーティング クライアントのトランスレーション ルートを設定する必要があります。

IVR：Unified IP IVR による処理とキューイング

中央サイトで処理およびキューイングされるすべてのコールをサポートできるように、WAN の帯域幅をプロビジョニングする必要があります。

Unified IP IVR を集中配置することで、Unified IP IVR を小規模な複数サイトに分散展開する場合と比べて、Unified IP IVR のポート利用効率を高めることができます。

IVR：Unified CVP による処理とキューイング

コールの処理とキューイングに Unified CVP を使用することで、WAN を経由して流れる音声トラフィックの量を削減できます。コールはリモート ゲートウェイで Unified CVP によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終端させる必要がありません。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。

Unified CCE：転送

VoIP WAN を使用してサイト間で RTP ストリームを送信するサイト内転送やサイト間転送は、単一サイトでの転送や集中型の音声ゲートウェイを持つ展開での転送と基本的に同じ方法で実行されます。

サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、キャリアが提供する PSTN 転送サービスを利用することもできます。このサービスを利用すると、Unified CCE 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。各サイトは、独立したエージェント ペリフェラルとして Unified ICM 内で設定可能です。転送がサイト内であるかサイト間であるかは、Take Back and Transfer（*8）または転送接続を使用してラベルに示されます。これらの転送トーンは音声パス経由でインバンドで再生されますが、Unified IP IVR で録音ファイルが再生されるか、Unified CVP から数値でアウトパルスされる必要があります。

Unified CCE：Unified IP IVR を使用した処理とキューイングの機能を持つ分散型音声ゲートウェイ

この展開モデルは、中規模から大規模のサイトを複数持つ企業において望ましい選択肢となり得ます。このモデルでは、PSTN トランクを組み合わせた音声ゲートウェイにより、処理が各サイト内で終了します。分散型音声ゲートウェイを備えた集中型コール処理モデルの場合と同様に、コールのルーティング先を着信サイトのエージェントに限定すれば、WAN の帯域幅消費を抑えられる利点があります。コールをサイト内に制限するかどうかは、顧客サービス レベルの向上から得られる利点と WAN のコスト低減から得られる利益を比較分析して判断する必要があります。図 2-6 に、Unified CCE System PG を使用した従来型の Unified CCE による展開を使用したこのモデルを示します。

図 2-6 複数のサイトに対して分散型コール処理と Unified IP IVR を備えた分散型音声ゲートウェイを展開した場合

前述のモデル同様、数多くのオプションが使用可能です。Unified ICM サーバ、Unified CM サーバ、Unified IP IVR サーバの台数と型番が変更可能です。さらにこの展開モデルでは、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN トランク、冗長性なども変更可能な要素です。セルフサービス、フリー ダイヤル コール、小規模サイトのサポートなどのために、集中処理とゲートウェイを追加できます。そのほか、プレルーティング PSTN ネットワーク インターフェイス コントローラ（NIC）も選択可能です。

利点

• スケーラビリティ：各独立サイトは、Unified CM クラスタごとにサポートされている最大数のエージェントを置ける規模まで拡張できます。また、同時エージェント数の合計が Unified CCE システムでサポートされているエージェント数より少なければ、企業全体の単一コンタクト センターを形成するために Unified ICM セントラル コントローラで組み合わせ可能なサイトの数に、ソフトウェア上の制限はありません。スケーラビリティとサイジングの情報については、「Unified CCE のコンポーネントとサーバのサイジング」を参照してください。

• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。サイト間で音声コールを転送するには、図 2-6 に示す QoS WAN が必要です。しかし、Take Back and Transfer や転送接続のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。

• Unified ICM プレルーティングを使用して、使用可能なエージェントまたは Unified IP IVR ポートの状況に基づいて、需要が多いサイトへのコールをロード バランシングし、VoIP トラフィックによる WAN の使用率を下げることができます。

• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。

• 各サイトの要件に応じて、サイトの規模を決定できます。

• Unified ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。

• Unified ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。

• Unified ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。

ベスト プラクティス

• PG、Unified CM クラスタ、Unified IP IVR は同じコンタクト センター サイトに置く必要があります。

• Unified ICM セントラル コントローラから PG への通信リンクは適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります（詳細については、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください）。

• WAN の帯域幅が利用できない場合は、ゲートキーパーに基づく、または RSVP エージェントに基づくコール アドミッション コントロールを使用し、PSTN を経由してサイト間でコールを再ルーティングできます。発生が見込まれるコールの最大量に見合った WAN 帯域幅をサイト間で確保するのが最善です。

• PG と Unified ICM セントラル コントローラ間の通信リンクが失われると、そのサイトではコールに対するコンタクト センターのルーティング機能も失われます。したがって、耐障害性を備えた WAN の実装が重要になります。耐障害性を備えた WAN を実装していても、Unified ICM セントラル コントローラと PG 間の通信が失われた場合に備え、コール処理とルーティングについて緊急時計画を策定しておくことが重要です。たとえば、Unified ICM セントラル コントローラとの接続が失われると、Unified CM CTI ルーティング拠点ではコールが Unified IP IVR ポートに送信され、基本的なアナウンスメント処理ができるようにしたり、他のサイトへの PSTN 転送を呼び出したりできるようになっています。また、接続が失われた Unified CM クラスタから、Unified ICM セントラル コントローラとの接続が有効な PG を持つ他の Unified CM クラスタにコールをルーティングする方法もあります。これらのオプションの詳細については、「アベイラビリティを高めるための設計上の注意点」を参照してください。

• 同一のコールに対してクラスタ間コール レッグが 2 つ存在しても、不要な RTP ストリームが発生することはありません。ただし、その場合は 2 つの独立したコール シグナリング制御パスが、2 つのクラスタ間にそのまま維持されます（これによってヘアピン ルーティングが生成され、クラスタ間トランクの数が 2 つ減少します）。

• Unified ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）であることが必要です。

処理とキューイング

コールに対する最初のキューイングは、音声ゲートウェイと同じ場所にある Unified IP IVR で実行されるので、トランスコーディングは不要です。コールが転送された後、引き続いてキューイングが要求されると、そのキューイングは、元のコールが現在処理されているサイトの Unified IP IVR で実行される必要があります。たとえば、サイト 1 に着信したコールがサイト 2 のエージェントにルーティングされたものの、このエージェントは受け取ったコールを存在場所が不明な他のエージェントに転送する必要があるとします。この場合、クラスタ間で余分なコールが発生しないように、このコールはサイト 2 の Unified IP IVR でキューイングされる必要があります。2 回目のクラスタ間コールが発生するのは、コールの転送先としてサイト 1 のエージェントが選択された場合だけです。この場合の RTP フローは、サイト 1 の音声ゲートウェイからサイト 1 のエージェントが使用している電話に直接流れます。ただし、2 つの Unified CM クラスタでは、それらの間で進行中の 2 つのコールが論理的に認識されています。

転送

サイト内の転送は、単一サイトでの転送と同様に機能します。Unified CM クラスタ間の転送では、VoIP WAN または PSTN サービスを利用します。

VoIP WAN を使用する場合は、クラスタ間トランクを十分に設定する必要があります。サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、PSTN 転送サービスを利用することもできます。このサービスを利用すると、Unified CCE 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。もう 1 つの方法として、サイト 1 の Unified CM クラスタから逆に PSTN にアウトバウンド コールを送信する方法があります。そのコールは PSTN からサイト 2 にルーティングされます。ただし、サイト 1 ではコールの残りを処理するために 2 つの音声ゲートウェイ ポートが使用されます。

Unified CCE：Unified CCE System PG

複数のリモート サイトを使用して設計されたこのモデルは、Unified System CCE の展開モデルではサポートされていません。ただし、Unified CCE 7.0 では、インストール、設定、およびルーティングを簡素化するために、それよりも前のバージョンの Unified CM と Unified IP IVR のペリフェラルに Unified CCE System PG が 1 つのペリフェラルとして導入されています。このモデルでは、リモート サイトにある PG を Unified CCE System PG としてインストールして、1 つの論理 PG のインスタンスとペリフェラルに Unified IP IVR と Unified CM のペリフェラルを統合できます。

ただし、このモデルでは、Web 設定ツールは使用できません。システムの中心部分は、Unified ICM アドミン ワークステーションの ConfigManager アプリケーションを使用して手動で設定する必要がある従来型の Unified CCE モデルのままです。このモデルは、Unified System CCE の展開モデルそのものを実際に使用しなくても、共通コンポーネント（Unified CCE System PG）を 2 つの展開モデルで共有できる独自の設計になっています。このモデルは、通常次のような場合に使用します。委託を受けた企業が 1 社の顧客用に独自のコールセンターをセットアップして Unified CCE System PG として展開します。その Unified CCE System PG に Unified CCE Gateway PG を装備して、顧客企業が自分の Unified ICM Enterprise システムを接続できるようにします。このようにすれば、ACD を外部に委託する場合と同じような運用が可能になります。

Unified CCE：Unified CCE PG

複数のリモート サイトを使用するように設計されたこのモデルは、複数の分散型ペリフェラル ゲートウェイを使用する従来型の Unified CCE の設計に一層適しています。このシステムは、Generic PG または Unified CM と Unified IP IVR PG の両方をサイトに装備すれば展開できます。ただし、このソリューションを新しく展開する場合は、新しい Unified CCE System PG を使用してこれらのペリフェラルを両方とも 1 つのペリフェラルに統合して従来型のモデルのルーティングとレポーティングを実現する方が簡単な場合があります。既存のお客様で Unified CCE 7.0 にアップグレードする場合は、既存の Generic PG または複数 PG モデルを使用し続けることもできます。

代替手段：親/子

この展開モデルの代替手段として、各分散サイトに子の Unified CCE を配置する親/子の展開モデルを使用することもできます。このモデルには、WAN での耐障害性が向上するという利点があり、障害時にも各サイトで完全に独立した運用を続けることができます。図 2-7 に、親子モデルを使用して同じモデルを展開した例を示します。

図 2-7 分散型コール処理と親/子モデルを使用した複数サイトの展開

この設計では、Unified CVP とそのシステム自身のアドミン ワークステーションと HDS サーバが装備された親の Unified ICM Enterprise システムがあります。各分散サイトには、セントラル コントローラとエージェント/IVR コントローラの両方をシステム サーバで運用する小/中規模モデルを使用した完全な Unified System CCE が展開されます。その特定のサイトの設定、スクリプティング、レポーティングを Unified System CCE で行うためのローカル管理および WebView レポーティング マシンも展開されます。Unified System CCE を親の Unified ICM に接続するための Unified CCE Gateway PG は、親の Unified ICM に展開されたペリフェラル ゲートウェイの一部になっています。

この設計で展開されているローカルの Unified System CCE は、自分自身のローカル IP ACD の役割を果たしており、システム内の他のサイトからは見えません。このモデルでは、サイト 2 のコールやレポートはサイト 1 のユーザには見えません。Unified ICM Enterprise システムに接続されたすべてのサイトのすべてのアクティビティを見ることができるのは、親の Unified ICM Enterprise システムだけです。

親の Unified ICM サイトにある Unified CVP は、分散サイトに着信するコールを制御するために使用され、音声ゲートウェイの VoiceXML ブラウザでローカル コールのキューイングと処理を行います。ローカルの Unified IP IVR サーバは、これらの音声ゲートウェイから親の Unified CVP コール制御サーバへの接続が失われた場合のローカル バックアップとしてだけ使用されます。また、ローカル Unified IP IVR は、ローカル エージェントが応答しなかったコール（RONA）を再キューイングのために Unified CVP に送り返すことをせずに、ローカルでキューイング処理します。

子の Unified System CCE を展開すると、Unified ICM ポストルーティングを使用するサイト間で Unified CCE Gateway PG によるシステム間コール転送も行えます。Unified CCE Gateway PG を使用すれば、別のサイトにいる最適のエージェントにコールへの転送や、次の応答可能エージェントを待つ中央でのキューイングを行うように、子の Unified System CCE から Unified ICM に依頼できます。

分散型の Unified CM ペリフェラル ゲートウェイを備えた従来型の Unified CCE モデルとは異なり、親/子モデルを使用すれば、コンタクト センター サイトで完全な冗長性をローカルに実現できます。ローカルの Unified System CCE が Unified CVP ゲートウェイからのインバウンド コールの処理を引き継ぎ、ローカルの Unified IP IVR でコールのキューイングと処理がローカルに行われます。この設計は、完全な冗長性や 100 % の稼動が求められるコール センターに最適で、WAN に障害が発生してもダウンしません。

この設計は、TDM ACD プラットフォームにすでに Unified ICM がインストールされているお客様で Unified CCE を使用する新しいサイトを追加したり、既存のサイトを Unified CCE に変更したりするのに適した方法です。この方法では、企業全体のルーティングとすべてのサイトのレポーティングを引き続き Unified ICM で行いながら、新しい Unified CCE テクノロジーをサイト単位で導入できます。

Unified System CCE では展開に Unified CVP が含まれていてもよいので、Unified CVP が親と子の両方に存在できることにも注意してください。これは、コール フローの観点からは、親に Unified CVP があり子に IP-IVR があるのと実質的に同じことです。ただし、IP-IVR を使用する場合との重要な違いは、子の Unified CVP のキューに入っているコールの情報を、親から（Gateway PG を通して）使用できないことです。つまり、サービスに対する最小予測遅延（MED）は使用できません。

利点

• 親の Unified ICM が制御するすべての分散サイトを対象にした仮想ネットワーク キューを Unified CVP で実現できます。親の Unified ICM からすべての分散サイトを見ることができ、次の応答可能なエージェントに仮想キューからコールを送信でききます。

• 各分散サイトは、1 つの Unified System CCE 展開でサポートできるエージェントの最大数まで拡張できます。複数の Unified System CCE セントラル コントローラを 1 組の Unified CM クラスタに接続すれば、クラスタでサポートされるエージェントの最大数まで拡張できます。Unified System CCE は、親の Unified ICM の Unified CCE Gateway PG を使用して親の Unified ICM に接続されるので、親の Unified ICM Enterprise システムでサポートされるエージェントの最大数まで拡張できます。

• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。サイト間で音声コールを転送するには、図 2-7 に示す QoS WAN が必要です。しかし、Take Back and Transfer や転送接続のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。

• Unified ICM プレルーティングを使用して、使用可能なエージェントまたは Unified CVP セッションの状況に基づいて、需要が多いサイトへのコールをロード バランシングし、VoIP トラフィックによる WAN の使用率を下げるように、最適のサイトにコールをルーティングできます。

• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。

• 各サイトの要件に応じて、サイトの規模を決定できます。

• 親の Unified ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。

• 親の Unified ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。

• 親の Unified ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。

欠点

• サーバ数：ソフトウェア コンポーネント（追加の Gateway PG、子ごとに追加するセントラル コントローラなど）の数が増えるので、親/子モデルを管理するために必要なサーバ数は通常は多くなります。

ベスト プラクティス

• Unified CCE Gateway PG、Unified CM クラスタ、Unified IP IVR、Unified System CCE は、（可能であれば）同じコンタクト センター サイトに置く必要があります。

• 親の Unified ICM セントラル コントローラから Unified CCE Gateway PG への通信リンクには適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります（詳細については、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください）。

• WAN の帯域幅が利用できない場合は、ゲートキーパーに基づく、または RSVP エージェントに基づくコール アドミッション コントロールを使用し、PSTN を経由してサイト間でコールを再ルーティングできます。発生が見込まれるコールの最大量に見合った WAN 帯域幅をサイト間で確保するのが最善です。

• Unified CCE Gateway PG と親の Unified ICM セントラル コントローラ間の通信リンクが失われると、そのサイトでは、コールに対するコンタクト センターのルーティング機能がローカルの Unified System CCE によって制御されます。Unified CVP によって制御される入力音声ゲートウェイにサバイバビリティ TCL スクリプトを設定してローカルの Unified CM CTI ルート ポイントにインバウンド コールをリダイレクトし、WAN の障害時にはローカルの Unified IP IVR を使用してローカル キューイングとローカル処理を行います。これは親/子モデルの主要な機能で、コール センターが完全にローカルで運用できるようになります。詳細は、「アベイラビリティを高めるための設計上の注意点」を参照してください。

• 同一のコールに対してクラスタ間コール レッグが 2 つ存在しても、不要な RTP ストリームが発生することはありません。ただし、その場合は 2 つの独立したコール シグナリング制御パスが、2 つのクラスタ間にそのまま維持されます（これによってヘアピン ルーティングが生成され、クラスタ間トランクの数が 2 つ減少します）。

• 親の Unified ICM セントラル コントローラとリモート Unified CCE Gateway PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）にする必要があります。

IVR：Unified CVP を使用した処理とキューイングの機能を持つ分散型音声ゲートウェイ

この展開モデルは、コール処理とキューイングで Unified IP IVR の代わりに Unified CVP が使用されている点を除けば、前述のモデルと同じです。このモデルでは、PSTN トランクを組み合わせた音声ゲートウェイにより、処理が各サイト内で終了します。分散型音声ゲートウェイを備えた集中型コール処理モデルの場合と同様に、コールのルーティング先を着信サイトのエージェントに限定すれば、WAN の帯域幅消費を抑えられる利点があります。コールの処理とキューイングも着信したサイトで完了できるようにすれば、WAN 帯域幅をさらに節約できます。図 2-8 は、従来型の Unified CCE の展開を使用するこのモデルを示しています。

図 2-8 複数のサイトに対して分散型コール処理と Unified CVP を備えた分散型音声ゲートウェイを展開した場合

前述のモデル同様、数多くのオプションが使用可能です。Unified ICM サーバ、Unified CM サーバ、Unified CVP サーバの台数と型番が変更可能です。さらにこの展開モデルでは、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN トランク、冗長性なども変更可能な要素です。セルフサービス、フリー ダイヤル コール、小規模サイトのサポートなどのために、集中処理とゲートウェイを追加できます。そのほか、プレルーティング PSTN ネットワーク インターフェイス コントローラ（NIC）も選択可能です。

利点

• Unified CVP サーバの設置場所は、中央でもリモートでもかまいません。Unified CVP サーバの位置に関係なく、コール処理とキューイングは分散され、ローカルのゲートウェイで実行されます。図 2-8 では Unified CVP を中央に配置しています。

• PG ごとにサポートされるエージェントの数とシステム全体でサポートされるエージェントの数については、「Unified CCE のコンポーネントとサーバのサイジング」を参照してください。

• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。サイト間で音声コールを転送するには QoS WAN が必要です。しかし、Takeback N Transfer のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。

• Unified ICM プレルーティングを使用してコールをロード バランシングし、最適のサイトへルーティングすることによって、VoIP トラフィックによる WAN の使用率を下げることができます。

• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。

• 各サイトの要件に応じて、サイトの規模を決定できます。

• Unified ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。

• Unified ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。

• Unified ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。

ベスト プラクティス

• Unified CM PG と Unified CM クラスタを同じ場所におく必要があります。また、Unified CVP PG と Unified CVP サーバを同じ場所におく必要があります。

• Unified ICM セントラル コントローラから PG への通信リンクは適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります。シスコでは、VRU PG と Unified ICM 間に必要な帯域幅を計算するためのパートナー ツールとして、VRU Peripheral Gateway to Unified ICM Central Controller Bandwidth Calculator を用意しています。このツールは、次の URL で入手できます（シスコのパートナーとしての有効なログイン認証が必要です）。

http://www.cisco.com/web/partners/tools/steps-to-success/index.html

• PG と Unified ICM セントラル コントローラ間の通信リンクが失われると、そのサイトではコールに対するコンタクト センターのルーティング機能も失われます。したがって、耐障害性を備えた WAN の実装が重要になります。耐障害性を備えた WAN を実装していても、Unified ICM セントラル コントローラと PG 間の通信が失われた場合に備え、コール処理とルーティングについて緊急時計画を策定しておくことが重要です。

• Unified ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）にする必要があります。

IVR：処理とキューイング

コールはリモート ゲートウェイで Unified CVP によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終端させる必要がありません。Unified CVP サーバは、中央サイトに配置できるほか、リモート サイトに分散配置することもできます。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。

Unified IP IVR と異なり、Unified CVP ではコール レッグはいったん切断された後、接続し直されます。これにより、ヘアピン ルーティングを避けることができます。Unified IP IVR では、2 つの独立したコール シグナリング制御パスが、2 つのクラスタ間でそのまま維持されます（これによりヘアピン ルーティングが生成され、クラスタ間トランクの数が 2 つ減少します）。

転送

サイト内の転送は、単一サイトでの転送と同様に機能します。Unified CM クラスタ間の転送では、VoIP WAN または PSTN サービスを利用します。

VoIP WAN を使用する場合は、クラスタ間トランクを十分に設定する必要があります。サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、PSTN 転送サービスを利用することもできます。このサービスを利用すると、Unified CCE 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。もう 1 つの方法として、サイト 1 の Unified CM クラスタから逆に PSTN にアウトバウンド コールを送信する方法があります。そのコールは PSTN からサイト 2 にルーティングされます。ただし、サイト 1 ではコールの残りを処理するために 2 つの音声ゲートウェイ ポートが使用されます。

Unified CCE：Unified CCE System PG

Unified CCE System PG では、キューイング用に Unified CVP がサポートされず、Unified CCE System PG の IVR PIM が使用されないままになるので、このモデルには Unified CCE System PG は適していません。

Unified CCE：Unified CCE PG

この展開モデルには、Unified CCE PG を使用することをお勧めします。

Unified CCE：分散型コール処理モデルでの分散型 Unified ICM オプション

図 2-9 に、この展開モデルを示します。

図 2-9 Unified IP IVR を使用した場合の分散型 Unified ICM オプション

利点

分散型 Unified ICM オプションの主な利点は、Unified ICM セントラル コントローラを 2 箇所のサイトに配置することで得られる冗長性です。

ベスト プラクティス

• Unified ICM セントラル コントローラ（Router と Logger）は、2 つの冗長サイト間でプライベート通信を行うための分離されたネットワーク パスまたはリンクを備えている必要があります。非分散型 Unified ICM モデルの場合、プライベート トラフィックは通常、Unified ICM セントラル コントローラのサイド A コンポーネントとサイド B コンポーネントを直接接続するイーサネット クロスケーブル、つまり LAN 上を流れます。一方、分散型 Unified ICM モデルでは、サイド A の Unified ICM コンポーネントとサイド B の Unified ICM コンポーネント間のプライベート通信には、T1 回線と同等かそれ以上の帯域幅の専用リンクを使用する必要があります。

• 独立したプライベート リンクの遅延は片道で 100 ミリ秒以下（往復で 200 ミリ秒以下）にする必要があります（50 ミリ秒（往復で 100 ミリ秒）を推奨）。

• Unified ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）であることが必要です。

• プライベート リンクは、パブリックなトラフィックとパスを共用できません。プライベート リンクは、パス ダイバーシティを必要とするので、Unified ICM のパブリックなトラフィックから完全に独立したパスを持つリンクに存在する必要があります。このリンクは、システムの耐障害性設計の一部として使用されます。詳細は、「アベイラビリティを高めるための設計上の注意点」を参照してください。

• 集中型モデルの冗長化については、次の「IPT：WAN 経由のクラスタリング」の項で扱います。

Unified IP IVR を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ

このモデルでは、音声ゲートウェイが中央サイトに配置されています。それぞれのサイトに Unified IP IVR が集中配置され、コールの処理とキューイングに使用されます。図 2-15 はこのモデルを示したものです。

図 2-15 Unified IP IVR を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ

利点

• コンポーネントを 1 か所に置き、集中管理できます。

• コールはローカルで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。

ベスト プラクティス

• 音声、制御、CTI に合わせ、エージェント サイトへの WAN 接続の帯域幅をプロビジョニングする必要があります。詳細は、「WAN 経由の Unified CCE クラスタリングに対する帯域幅の要件」を参照してください。

• リモート サイトでは、ローカル コールの発信と緊急連絡（119、110）利用のために、ローカルの音声ゲートウェイが必要になることがあります。詳細については、次の URL にある『 Cisco Unified Communications Solution Reference Network Design (SRND) 』を参照してください。

http://www.cisco.com/go/designzone

• ロード バランシングされた展開の場合、中央サイトが停止すると着信ゲートウェイの機能の半分が失われることになります。一方のサイトに障害が発生した場合に備え、ゲートウェイと IVR は単独のサイトですべての負荷を処理できる規模にしておくことが必要です。

• サイトやゲートウェイの機能が失われた場合は、キャリアのコール ルーティングにより、コールが代替のサイトにルーティングされる必要があります。プレルーティングはロード バランシングに有効ですが、障害が発生している中央サイトにもコールがルーティングされる可能性があります。したがって、プレルーティングはお勧めできません。

Unified CCE System PG を使用した WAN 経由のクラスタリング

Unified CCE System PG を使用した WAN 経由のクラスタリングがサポートされるようになりました。ただし、1 つの Unified CCE システム ペリフェラルがすべての Unified IP IVR と Unified CM を制御するため、Unified IP IVR 間のコールのロード バランシングでは、どちらのサイトからコールが来たかは考慮されません。単に負荷の最も低い Unified IP IVR にコールが配分されるだけです。つまり、サイト A に到着したコールがサイト B の Unified IP IVR で処理される場合もあります。さらに、A サイドと B サイド両方の Unified CCE System PG ではすべての Unified IP IVR が認識されています。PIM アクティベーション ロジックによって、A サイドか B サイドのどちらの PIM が各 Unified IP IVR に接続されるかが決定されます。つまり、サイト A の PG がサイト B の Unified IP IVR に接続される場合もあります。したがって、WAN 経由ではトラフィックが最適に送信されるとは限りません。そのため、このモデルで適切な動作を確保するためには WAN のサイジングに注意する必要があります。

Unified CVP を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ

このモデルでは、中央サイトに配置されている VoiceXML ゲートウェイが音声ゲートウェイです。Unified CVP が集中配置され、コールの処理とキューイングに使用されます。図 2-16 はこのモデルを示したものです。

図 2-16 Unified CVP を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ

利点

• コンポーネントを 1 か所に置き、集中管理できます。

• コールはローカルで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。

• プライマリ ルート ポイントは Unified CVP なので、Unified CM にかかる負荷が軽減されます。これにより、Unified IP IVR による実装に比べてクラスタ当たりのスケーラビリティを高めることができます。詳細は、「Unified CCE のコンポーネントとサーバのサイジング」を参照してください。

ベスト プラクティス

• 音声、制御、CTI に合わせ、エージェント サイトへの WAN 接続の帯域幅をプロビジョニングする必要があります。詳細は、「WAN 経由の Unified CCE クラスタリングに対する帯域幅の要件」を参照してください。

• リモート サイトでは、ローカル コールの発信と緊急連絡（119、110）利用のために、ローカルの音声ゲートウェイが必要になることがあります。

Unified CVP を含む Unified System CCE を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ

Unified CVP コール サーバ間のコールのロード バランシングは、SIP と Cisco Unified Presence プロキシ サービスによって管理されます。このロード バランシングでは、どちらのサイトからコールが来たかは考慮されません。コールは、Cisco Unified Presence で定義された単純なロード バランシング ルール（設定済みの Unified CVP コール サーバに順番にコールを配分する、特定のコール サーバが優先されるように重み付けするなど）に基づいて配分されます。

現在 Unified CVP では、システムがそのように設計されていれば、コールを着信ゲートウェイでキューイングすることができます。そのためには、[settransferlabel]（H.323 の場合）または [Send To Originator]（SIP の場合）を使用して Unified CVP を設定して、NetworkVRU ラベルを照合する必要があります。これにより、その NetworkVRU ラベルに一致するラベルが Unified ICM から返された場合に、Unified CVP がそのコールをキューイングのために着信ゲートウェイに戻すようになります。現在 Unified ICM では最初のゲートウェイの場所が認識されないため、Unified ICM でコールの元の着信場所に基づいてラベルを選択できません。

WAN 経由のクラスタリングに関する考慮事項

図 2-17 は、WAN 経由のクラスタリングを含む展開を示しています。

図 2-17 WAN 経由のクラスタリング

次に示すのは、WAN 経由のクラスタリングを含む展開に関するガイドラインと考慮事項です。

• このネットワーク展開では、統合されたハイ アベイラビリティ ビジブル ネットワークおよびプライベート ネットワークがサポートされます。ICM セントラル コントローラのプライベート トラフィックとビジブル（パブリック）トラフィックは分離され、別々のエッジ デバイスにまとめられます。

• 2 つのデータ センター間の通信の WAN に関する考慮事項には、VPN routing/forwarding table（VRF; VPN ルーティング/フォワーディング テーブル）を持つ Multiprotocol Label Switching（MPLS; マルチプロトコル ラベル スイッチング）バックボーンが含まれる場合があります。

• ネットワーク設計にシングル ポイント障害が含まれないようにする必要があります。ビジブル ネットワークとプライベート ネットワークを WAN に接続する前に別々のスイッチおよびルータにまとめる必要があります。

• プライベート ネットワークを分離する必要はありません。セントラル コントローラと Unified CCE System PG は共通のプライベート ネットワーク パスを共有できます。

• 複数のプライベート ネットワーク パスをプロビジョニングできます（セントラル コントローラと Unified CCE System PG のプライベート ネットワークを分離できます）。

• トラフィックの優先順位付けを適切に行って、プライベート ネットワーク パス トラフィックとビジブル（パブリック）ネットワーク トラフィックの WAN における帯域幅を確保する必要があります。詳細については、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください。

• 現在、Gateway PG と System PG の間のプライベート ネットワーク帯域幅の帯域幅カルキュレータは保証されていないため、存在しません。ガイダンスについては、「帯域幅のプロビジョニング」を参照してください。

• セントラル コントローラと PG に二重化されたサイドツーサイドのプライベート ネットワークにおける一方向の最大遅延は 100 ミリ秒です（推奨値は 50 ミリ秒です）。

LAN および WAN のプロビジョニングの基礎となるネットワーク インフラストラクチャで上記の要件がすべて満たされている必要があります。重要なのは、ビジブル パスとプライベート パスを分離することと、（特にプライベート パスで）遅延および帯域幅の要件を満たすことです。PG とセントラル コントローラのプライベート ネットワークを分離すると、互いのプライベート リンクの障害の影響をある程度回避できます。パスとルートが多様であるほど耐障害性が高くなります。たとえばデュプレックス モードでは、親セントラル コントローラ間のプライベート ネットワークがダウンしても子セントラル コントローラが引き続き機能します。

MPLS に関する考慮事項

MPLS ネットワークで、ルートの多様性、遅延、および帯域幅が保証されていて、上述の要件を満たすために独立したトポロジおよびハードウェア要素でルーティング（およびフェールオーバー）されるラベル スイッチ パスをサポートする設定が行われていれば、アプリケーションが設計どおりに機能します。状況に応じた変更によって時間の経過とともにルートの独立性が損なわれないようにすることが重要です。

ベスト プラクティスとハイ アベイラビリティ展開の詳細については、「IPT：WAN 経由のクラスタリング」を参照してください。

分散型音声ゲートウェイにおける分散型のコール処理とキューイングを Unified CVP で行う場合

このモデルの音声ゲートウェイは、エージェントの場所に分散配置された VoiceXML ゲートウェイです。リモート ゲートウェイに Unified CVP が集中配置され、コールの処理とキューイングに使用されます。図 2-18 はこのモデルを示したものです。

図 2-18 分散型音声ゲートウェイにおける分散型のコール処理とキューイングを Unified CVP で行う場合

利点

• 着信コールと着信ゲートウェイが、そのローカル エージェントを重点的にサポートするようにプロビジョニングされていれば、WAN リンク上の音声 RTP トラフィックはゼロあるいは最小限になります。他のサイトへの転送と会議は、WAN 上を流れます。

• コールはエージェント サイトで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。

• 市内電話の着信と発信は、緊急連絡（119、110）も含め、ローカル VoiceXML ゲートウェイを共有できます。

• プライマリ ルート ポイントは Unified CVP なので、Unified CM にかかる負荷が軽減されます。これにより、Unified IP IVR による実装に比べてクラスタ当たりのスケーラビリティを高めることができます。詳細は、「Unified CCE のコンポーネントとサーバのサイジング」を参照してください。

ベスト プラクティス

• 分散型ゲートウェイでは、集中型ゲートウェイの場合に加え、最小限のメンテナンスと管理を追加で実行する必要があります。

• Unified CVP のメディア サーバは、中央に配置してもエージェント サイトに配置しても、どちらでもかまいません。ゲートウェイのフラッシュからメディアを実行することもできます。メディア サーバをエージェント サイトに配置することで、帯域幅の要件を軽減できますが、サーバが追加されるためにサーバの数が増え、メンテナンス コストが増加します。

サイト間 Unified ICM プライベート通信のオプション

Unified ICM プライベート通信は、Unified ICM コンポーネント間のパブリック通信から分離されたパスを流れる必要があります。このパス分離のために、デュアル リンクとシングル リンクという 2 種類のオプションがあります。

デュアル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Unified CM PG のプライベート トラフィック

図 2-19 に示すデュアル リンクでは、Unified ICM セントラル コントローラのプライベート トラフィックが、VRU/CM PG のプライベート トラフィックから分離されています。

図 2-19 デュアル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Unified CM PG のプライベート トラフィック

利点

• 1 つのリンクに障害が発生しても、Unified ICM セントラル コントローラと PG の両方がシンプレックス モードになることはありません。これにより、システムが停止する可能性が二重故障の水準程度にまで低くなります。

• QoS の設定がリンクごとに 2 種類に制限されるので、リンクの設定とメンテナンスが簡素化されます。

• 展開モデルとコール フローのサイズ再設定や変更があっても、その影響が及ぶのは 1 つのリンクだけです。これにより、正常な機能を確保するために必要な QoS とサイズの変更が少なくなります。

• コール フローや設定に対して予期しない変更（誤設定など）が発生しても、独立したプライベート リンクで問題が発生する可能性が低くなっています。

ベスト プラクティス

• 独立した専用回線でリンクを分離することをお勧めします。ただし、これらのリンクに冗長性は不要です。また、お互いに一方のリンクに対してフェールオーバーの関係にならないようにします。

• コールの負荷、コール フロー、展開の設定を大幅に変更する場合は、事前にリンクのサイズと設定の妥当性を確認しておく必要があります。

• リンクはできるだけ専用回線にしてください。ハイ アベイラビリティ（HA）WAN に設定したトンネル回線は使用しないでください。パス ダイバーシティの詳細は、「ベスト プラクティス」の冒頭にある「IPT：WAN 経由のクラスタリング」を参照してください。

シングル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Unified CM PG のプライベート トラフィック

図 2-20 に示すシングル リンクでは、Unified ICM セントラル コントローラのプライベート トラフィックと VRU/CM PG のプライベート トラフィックの両方が流れます。デュアル リンク実装に比べると、シングル リンク実装は普及しており、低い費用で実現できます。

図 2-20 シングル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Unified CM PG のプライベート トラフィック

利点

• 独立リンク モデルより安価です。

• メンテナンスするリンク数が少なくて済みます。ただし、複雑さは増加します。

ベスト プラクティス

• リンクを冗長化する必要はありません。冗長リンクを使用する場合は、フェールオーバー時の遅延を 500 ミリ秒以下に抑える必要があります。

• セントラル コントローラおよび PG で発生する高優先順位通信に対しては、QoS 分類と予約された帯域幅が別途必要になります。詳細は、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください。

• コールの負荷、コール フロー、展開の設定を大幅に変更する場合は、事前にリンクのサイズと設定の妥当性を確認しておく必要があります。これは、シングル リンク モデルでは特に重要です。

• リンクはできるだけ、ハイ アベイラビリティ（HA）WAN から完全に分離された専用回線にしてください。ハイ アベイラビリティ（HA）WAN に設定したトンネル回線は使用しないでください。パス ダイバーシティの詳細は、「ベスト プラクティス」の冒頭にある「IPT：WAN 経由のクラスタリング」を参照してください。

WAN 経由の Unified CCE クラスタリングの障害分析

この項では、Unified CCE で実行している WAN 経由のクラスタリングで特定の障害が発生したときの動作について説明します。この展開モデルでは、ハイ アベイラビリティ（HA）WAN の安定性がきわめて重要です。ハイ アベイラビリティ WAN で発生する障害は、通常発生する障害と同列には扱えないと考えられています。

この項で扱う展開モデルの概要については、「IPT：WAN 経由のクラスタリング」で示した図を参照してください。

中央サイト全体の喪失

中央サイト全体の喪失とは、サイトの電源が切断された場合のように中央サイトとの通信がすべて失われた状態をいいます。この障害の主な原因として考えられるのは、自然災害、電源の問題、重要な接続に発生した問題、人為的なミスなどです。中央サイトとの接続が部分的に失われている場合は、サイトの喪失ではなく、接続の部分的な喪失です。このシナリオについては、この次の項で扱います。

WAN 経由の Unified CCE クラスタリングが中央サイト全体で完全に失われると、リモート エージェントは冗長サイトに適切にフェールオーバーされます。フェールオーバーに要する時間は、エージェントから見て 1 ～ 60 秒の範囲で変わります。この時間の違いは、エージェントの人数、電話の登録場所、エージェントが使用しているデスクトップ サーバの違いによるものです。

分散 VoiceXML ゲートウェイと Unified CVP を使用している場合に、このゲートウェイのプライマリ サイトが失われたとき、ゲートウェイはあるサイトから別のサイトにフェールオーバーする必要があります。このフェールオーバーには約 30 秒の時間がかかります。したがって、この 30 秒の間にリモート ゲートウェイに着信したコールは失われます。

サイト 1 とサイト 2 の間のプライベート接続

Unified ICM セントラル コントローラのサイド A とサイド B の間のプライベート接続に障害が発生すると、どちらかの Unified ICM Router はサービスを停止し、残った Unified ICM Router はリンクが復旧するまでシンプレックス モードで動作します。この状況が原因でコールの損失や障害が発生することはありません。

PG のサイド A とサイド B の間のプライベート接続に障害が発生すると、非アクティブな PG はサービスを停止し、アクティブな PG はリンクが復旧するまでシンプレックス モードで動作します。この状況が原因でコールの損失や障害が発生することはありません。

組み合わせたプライベート リンクを使用している場合、このリンクが失われると、Unified ICM セントラル コントローラと PG のプライベート接続が失われます。その結果、両方のコンポーネントの動作は、前述のシンプレックス モードに切り替わります。この状況が原因でコールの損失や障害が発生することはありません。

リモート エージェント サイトから中央サイトへの接続

いずれかの中央サイトへの接続がリモート エージェント サイトから失われると、すべての電話とエージェント デスクトップはただちに別の中央サイトに接続され、コールの処理が再開されます。通常、フェールオーバーには 1 ～ 60 秒の時間がかかります。

ハイ アベイラビリティ WAN の障害

名前の定義上は、通常の状況でハイ アベイラビリティ（HA）WAN に障害は発生しません。本来のとおりに HA WAN がデュアル パス構成を持ち、完全冗長であれば、このタイプの障害の発生はきわめてまれです。この項では、このようにきわめてまれなシナリオで発生する現象について説明します。

その原因に関係なく、HA WAN が失われると、Unified CM クラスタは分割されます。この障害によって重点的に発生する問題は、エージェントの電話の半分と Unified ICM との接続が失われるということです。Unified ICM から通信できるのはクラスタの半分だけとなり、残りの半分に登録されている電話とは通信できないか、場合によっては認識もできなくなります。その結果、Unified ICM から認識できなくなっている電話を使用しているすべてのエージェントは、ただちにログアウトされます。これらのエージェントは、ハイ アベイラビリティ WAN が復元されるか、使用している電話の接続先クラスタ サイドを切り替えない限り、ログインして復帰できません。

Unified CCE Gateway PG の分割

Unified System CCE 展開の分散アーキテクチャを拡張するには、地理的に分散された Cisco Unified CCE Gateway PG のサポートが必要です。Unified CCE Gateway PG は、System PG と同じロケーションに展開され、サイトの障害があった場合は最大のリカバリ機能を追加します。図 2-21 に、分散された各 Unified System CCE と Unified CCE Gateway PG が共存する 2 つのリモート データ センターをサポートする分散型の Unified System の展開を示します。子が Unified CCE System PG を利用する Unified CCE であった場合は同じ内容が適用されます。

図 2-21 共存する Gateway PG

Business Ready Teleworker Solution を介して展開された Unified IP Phone を使用するリモート エージェント

このモデルでは、リモート エージェントの IP Phone とワークステーションが、VPN トンネルを介してメインの Unified CCE キャンパスに接続されています。リモート エージェントにルーティングされた顧客からのコールは、キャンパス エージェントにルーティングされた場合と同じように扱われます（図 2-22 を参照）。

図 2-22 Business Ready Teleworker Solution を介して展開された IP Phone を使用するリモート エージェント

利点

• 高速なブロードバンドにより、コスト効果の高いオフィス アプリケーションが実現します。

• サイト間の常時接続 VPN 接続を採用しています。

• 高度なセキュリティ機能により、企業 LAN をホーム オフィスまで拡張できます。

• CTI データ、高品質音声など、音声・データ統合デスクトップ アプリケーションを幅広くサポートしています。

ベスト プラクティス

• ケーブルでサポートされているブロードバンド接続速度は、アップロードで 256 kbps 以上、ダウンロードで 1.0 Mbps 以上です。

• ADSL では、アップロードで 256 kbps 以上、ダウンロードで 1.4 Mbps 以上のブロードバンド接続速度がサポートされています。

• エージェントのワークステーションは、動作クロックが 500 MHz 以上で、512 MB 以上の RAM を搭載している必要があります。

• IP Phone は、最低のブロードバンド接続速度でも G.711 を使用するように設定する必要があります。

• QoS は、リモート エージェント ルータのエッジだけで有効になります。現在のところ、サービス プロバイダーは QoS を提供していません。

• リモート エージェント ルータでセキュリティ機能を有効にします。

• Cisco 7200 VXR および Catalyst 6500 IPSec VPN Services Module（VPNSM）を使用することで、エージェントは優れた LAN 間パフォーマンスを得られます。

• リモート エージェントの自宅にある電話は、緊急連絡（911）へ接続可能である必要があります。

• リモート エージェントがログインしていて業務できる状態でも、電話に出られない場合は、Redirect-On-No-Answer（RONA）機能が使用されるようにします。

PBX 転送の使用

多くのコール センターには、書き直されることが考慮されていない、従来からの既存 IVR アプリケーションが配置されています。これらの IVR アプリケーションを温存した上で Unified CCE 環境に統合するには、IVR に Unified ICM へのインターフェイスを備える必要があります（図 2-26 を参照）。

Unified ICM への IVR インターフェイスには 2 種類のバージョンがあります。1 つは単なるポストルーティング インターフェイス（コール ルーティング インターフェイス（CRI））です。このインターフェイスでは、IVR から Unified ICM にコール データ付きでポストルート要求を送信できます。Unified ICM から IVR に、コールの転送を指示するルート応答が送信されます。このシナリオでは、従来の IVR は PBX 転送を呼び出し、そのポートをリリースしてコールを Unified CCE に転送します。IVR から渡されたあらゆるコール データは、Unified ICM によってエージェントのデスクトップまたは Unified IP IVR に渡されます。

Unified ICM へのもう 1 つの IVR インターフェイスは、Service Control Interface（SCI; サービス制御インターフェイス）です。SCI を使用すると、Unified ICM からのキューイング指示を IVR で受け取ることができます。PBX モデルでは、SCI が不要です。

IVR が SCI インターフェイスを備えていても、すべてのコールのキューイングには Unified CVP または Unified IP IVR を展開することをお勧めします。これにより、従来の IVR ポートを余分に使用せずに済むためです。さらに、キューイングに Unified IP IVR を使用すれば、続いて実行する転送や RONA 処理でコールを再キューイングできるようになります。

図 2-26 PBX 転送を使用した、従来の IVR の統合

この設計では、標準 T1 トランク インターフェイスで PSTN キャリア ネットワークから、まず PBX にコールが着信します。通常、PBX ではコールはハント グループを使用して IVR に転送されるので、ハント グループでは、すべての IVR ポートが「auto available（自動応答可能）」モードのエージェントとされます。この PBX には PBX に接続された PG がないので、Unified ICM からは PSTN のように見えます。IVR に配信されるコールを配信元の段階から Unified ICM で追跡することはできません。レポーティングできるのは、IVR にコールが到達して、IVR から Unified ICM にコールの通知があった時点からだけです。

発信者が IVR アプリケーションから出ることを選択すると、IVR はコール ルーティング インターフェイス（CRI）を使用して Unified ICM にポストルートを送信します。このアプリケーションではコールを IVR でキューイングする必要がないので、CRI が適切なインターフェイス オプションとなります。Unified ICM はシステム全体のエージェントの状態を見て、（エージェントの電話番号またはデバイス ターゲット経由で）コールを送信するエージェントを選択するか、Unified IP IVR にコールをトランスレーション ルーティングしてキューイングします。

コールがエージェントまたはキューに送られると PBX でヘアピン処理されます。ヘアピン処理とは、コールが T1 トランク ポート上の PSTN から入って、PBX 内の別の T1 トランク ポートの音声ゲートウェイに出て行く処理のことです。コールのライフ中は、この接続が使用されます。

別の方法として、PBX に入った時点からコールを追跡する必要がある場合、または発信者の ANI や最初の着信番号を取得する必要がある場合は、PBX に PG をインストールできます。PBX は、どの IVR ポートで PBX の背後にコールを送信するかを（Unified ICM へのポストルーティングで）要求できます。PBX では、PBX から IVR へのコールの配信にハント グループを使用できません。PBX で収集されたコール データがトランスレーション ルートで維持されて IVR で確実に使用できるようにするには、DNIS が Unified ICM で直接終端する必要があります。

PSTN 転送の使用

このモデルは、直前の項のモデルにきわめて似ています。違う点は、従来の IVR のポートをリリースするために IVR から呼び出されるものが PBX 転送ではなく、PSTN 転送であるという点です（図 2-27 を参照）。この場合も、従来の IVR ポートを余分に使用する必要がないように、また IVR でトランキングの重複が発生しないように、すべてのキューイングで Unified IP IVR が使用されます。従来の IVR アプリケーションで収集されたあらゆるコール データは、Unified ICM によってエージェントのデスクトップまたは Unified IP IVR に渡されます。

図 2-27 PSTN 転送を使用した、従来の IVR の統合

このモデルでは、インバウンド コール用に PSTN が直接接続されている IVR プラットフォームのファームとして TDM IVR がセットアップされています。この IVR では、システム内のすべてのコールを追跡する Unified ICM に PG が接続されています。発信者が IVR 処理から出ることを選択すると、IVR は Unified ICM にポストルーティング要求を送信します。Unified ICM は、エージェントまたはキューイング用の Unified IP IVR にそのコールを振り向けるためのラベルを返します。

TDM IVR に返されたラベルは、転送トーン（キャリア ネットワーク内の宛先ラベルが設定された *8）を使用してインバンド転送コマンドを送信するように TDM IVR に指示します。IVR はトーンを生成するか録音済みのファイルから再生するかして、これらのトーンをサービス プロバイダーにアウトパルスする必要があります。

IVR でのトランキングの重複の使用

従来から使用している IVR アプリケーションの完成度が高く、ほとんどの発信者は従来の IVR によるセルフサービスで全面的にサポートされている場合を考えます。このような場合、エージェントに転送することが必要な発信者は限られた比率にとどまっているので、そのわずかな比率のコールを処理するためだけであれば、従来の IVR でトランク処理の重複が発生しても問題にならないことがあります（図 2-28 を参照）。前の項のモデルと異なり、従来の IVR に サービス制御インターフェイス（SCI）があれば、最初のコールのキューイングはその IVR で実行できます。これが有利なのは、Unified IP IVR でコールをキューイングするために、別の従来の IVR ポートが Unified IP IVR にコールを転送するために使用されるからです。最初のキューイングを従来の IVR で実行することにより、そのコールの最初のキューイングで使用されるポートは、従来の IVR ポート 1 つだけで済みます。ただし、転送または RONA 処理の結果、続けて発生するキューイングは、トランキングの重複を避けるために Unified IP IVR で実行する必要があります。従来の IVR が SCI インターフェイスを備えていない場合、その IVR では、コールの転送先を判断するため、Unified ICM 宛てに単なるポストルーティング要求が生成されます。このシナリオでのキューイングはすべて、Unified IP IVR で実行する必要があります。

図 2-28 IVR でのトランキングの重複を使用した従来の IVR の統合

このモデルでは、インバウンド コール用に PSTN が直接接続されている IVR プラットフォームのファームとして TDM IVR がセットアップされています。この IVR では、システム内のすべてのコールを追跡する Unified ICM に PG が接続されています。発信者が IVR アプリケーションから出ることを選択すると、IVR は Unified ICM にポストルーティング要求を送信します。Unified ICM は、コールをエージェントに振り向けるか、Service Control Interface（SCI; サービス制御インターフェイス）を使用して TDM IVR にコールをローカルにキューイングためのラベルを返します。音声ゲートウェイに、さらに Unified CCE エージェントにコールをヘアピン処理する別のポートを TDM IVR が選択することによって、エージェントへの転送が行われます。コールがエージェントに接続されている間は、この処理によって 2 ポートが占有されます。

Unified CM による転送と IVR でのトランキングの重複の使用

運用していく中で、従来の IVR アプリケーションから Unified CVP または Unified IP IVR への移行が必要になることがあります。ただし、きわめて限定されたシナリオで従来の IVR アプリケーションを使用する必要性がわずかに残っている場合は、その IVR を追加の音声ゲートウェイに接続します（図 2-29 を参照）。PSTN から音声ゲートウェイに着信したコールは、Unified CM によってルーティングされます。Unified CM では、特定の DN を従来の IVR にルーティングできるほか、コールを従来の IVR に転送するタイミングを Unified ICM、Unified CVP または Unified IP IVR で決定することもできます。従来の IVR にあるコールを Unified CCE エージェントに転送することが必要な場合、そのコールの接続中は、別の IVR ポート、トランク、および音声ゲートウェイ ポートが使用されます。複数のループが発生しない転送シナリオとなるように注意する必要があります。複数のループが発生すると、音声の品質が低下することがあります。

図 2-29 Unified CM による転送と IVR でのトランキングの重複を使用した従来の IVR の統合

このモデルでは、音声ゲートウェイを使用する Unified CVP、または Unified CCE を使用する Unified IP IVR および Unified CM のどちらかを TDM IVR の「フロントエンド」として使用して、コール処理を行う場所を決定します。

Unified CVP を使用する場合、音声ゲートウェイに着信するコールは、サービス制御インターフェイス（SCI）を使用して、Unified ICM とのルーティング ダイアログをすぐに開始します。Unified ICM は最初の着信番号または Unified CVP のプロンプトに基づいて、特定のセルフサービス アプリケーション用にコールを TDM IVR に送信する必要があるか、または発信者が使用できるアプリケーションが Unified CVP にあるかどうかを判断します。コールが TDM IVR に送信された場合は、発信者が選択した時点で、TDM IVR がルーティング要求を Unified ICM に送信します。応答は TDM IVR にではなく、最初のルーティング クライアントである Unified CVP に返されます。次に Unified CVP がコール レッグを TDM IVR から取得して、VoIP ネットワーク経由で Unified CCE エージェントに転送するか、音声ゲートウェイ内のローカル キューに保持します。

Unified CM を使用する場合は、音声ゲートウェイに着信するコールが Unified CM のための CTI ルート ポイントに到達すると、ルーティング要求が Unified ICM に送信され、発信者に適切なコール処理デバイスが判別されます。CTI ルート ポイントに TDM IVR にあるアプリケーションが示されている場合は、コールを TDM IVR に転送するように Unified CM に Unified ICM が指示します。この転送は、音声ゲートウェイ上の別 T1 ポートを使用して、コールをヘアピン処理して TDM IVR に接続することによって行われます。また、コールを Unified IP IVR にトランスレーション ルーティングしてコール処理あるいはプロンプトの再生を行い、次に TDM IVR に転送してさらに処理するように、Unified CM に Unified ICM が指示することもあります。発信者が TDM IVR を出ることを選択すると、TDM IVR はポストルート要求を Unified ICM に送信し、Unified ICM はラベルを TDM IVR に返します。このラベルは、IVR の別の T1 ポートを使用してコールを転送してコールバックを音声ゲートウェイに渡し、さらに Unified CM のダイヤル プランにある Unified CCE エージェントに渡すように TDM IVR に指示します。

Unified CM によって制御されるモデルでは、音声ゲートウェイで最初にコールが受信され、別の T1 ポートで TDM IVR にヘアピン処理されます。IVR が Unified CCE エージェントにコール バックを送信するときには、IVR は TDM IVR の別のポートと音声ゲートウェイの別のポートを使用します。エージェントが発信者と話している間は、これら 3 つのポートすべてが音声ゲートウェイ上で占有されます。また、このコールが存在する間は、TDM IVR の両方のポートが占有されます。