Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン（SRND）Releases 7.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月14日
章のタイトル： 展開モデル
展開モデル
Unified CC の展開方法は数多く存在しますが、一般的には次のモデルに分類できます。
これらの展開モデルを基本として、多様なバリエーションや組み合わせが可能です。 それぞれのモデルにおいて、以下に示す要因に基づく複数のバリエーションが生じます。
•
長距離通信会社（IXC）と地域通信会社（LEC）のいずれのトランクを使用するかの選択
この章では、これらのうちサイジング以外の要因が、ネットワーク デザイン上の意思決定に及ぼす影響について説明します。 また、展開モデルごとに、費用便益分析を使用して評価する必要のある検討事項とリスクについても述べます。 さらに、各展開モデルに合致するベスト プラクティスのシナリオを紹介します。
この章では、そのセクションで説明される要因のタイプがセクション名の前に示されています。 それらの要因は次のように分類されています。
• IPT：シスコ ユニファイド コミュニケーション展開要因（Cisco Unified CallManager と音声ゲートウェイの展開方法）
• Unified CC：Unified CC と Unified ICM の展開要因（どの PG を使用するかなど）
• IVR：IVR とキューイングの展開要因（Unified CVP または Unified IP IVR を使用する場合）
これらの展開モデルを組み合わせたモデルも考えられます。 たとえば、マルチサイトの展開では、小規模なサイトのように集中コール処理を採用しているサイトと、大規模なサイトのように分散型コール処理を採用しているサイトを混在させることが可能です。 このようにモデルを複合的に組み合わせたシナリオの例については、対応する各セクションで紹介します。
さらにこの章では、PBX/ACD のハイブリッド展開を含む、従来型の ACD システムと IVR システムを Unified CC 展開に統合する手法についても説明します。 サイジングと冗長性については、この Unified CC 設計ガイドの後半の章で取り上げます。 Unified CC ソリューションのサポートに必要なネットワーク インフラストラクチャについての詳細は、次の URL にある最新版の『 Cisco Network Infrastructure Quality of Service Design 』のガイドを参照してください。
Unified CC およびシスコ ユニファイド コミュニケーションの展開モデルについての詳細は、次の URL にある最新版の『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。
一般的な展開オプション
このセクションでは、このドキュメントで後述する具体的な展開モデルの多くに適用できるオプションについて説明します。 また、Unified CC ソフトウェアをインストールするときのトレードオフについても概要を説明します。
エージェントのペリフェラル オプション
Cisco Unified CCE 7.0 以降では、Unified CC エージェント用に 2 つのタイプのペリフェラルをインストールできます。 このセクションでは、それら 2 つのタイプのペリフェラルとそれぞれの長所と短所について説明します。
Enterprise Unified CC ペリフェラル
次の説明は、Cisco Unified CallManager PG が単独で展開されている場合または Cisco Unified CallManager と VRU のペリフェラルが両方とも Generic PG に展開されている場合のどちらかに当てはまります。 Cisco Intelligent Contact Management（Unified ICM）ソフトウェアは、これら 2 つのエンティティ（VRU と Cisco Unified CallManager）を別々のペリフェラルとして扱います。 このように扱うため、各ペリフェラルで 1 回ルーティングを行う必要があります。そのため、コールがペリフェラルを通過するごとに、各ペリフェラルで Termination Call Detail（TCD）レコードが作成されます。 Unified CC 7.0 までは、Unified CC を展開する方法はこれだけでした。
独立した VRU と Cisco Unified CallManager のペリフェラルを使用する場合は、トランスレーション ルートを作成して、VRU と Cisco Unified CallManager の間でコールを送信する必要があります。
Enterprise Unified CC ペリフェラルと別の VRU ペリフェラルを展開すれば、非常に柔軟に設定できるようになります。 たとえば、このように展開すれば、VRU ペリフェラルに接続された Unified CVP または Unified IP IVR の使用が可能で、複数の IVR 間のロード バランシングの設定や、トランスレーション ルートを使用したスクリプティングなどが可能になります。
Cisco Unified CallManager のペリフェラルを使用して Unified CC を設定するときは、Unified CC は Gateway PG 経由での Unified ICM に対する子としては動作できません。このオプションを利用できるのは、Unified CC システムのペリフェラルを使用しているときだけです。 子と親に関する詳細は、「親/子」を参照してください。
Unified CC システム ペリフェラル
Unified CC システム ペリフェラルとは、VRU ペリフェラル（最大 5 個の Unified IP IVR ペリフェラル）と 1 つの Cisco Unified CallManager ペリフェラルの両方を組み合わせて、1 つの論理 Unified ICM ペリフェラルにしたものです。 Unified CC では、これらの Unified IP IVR と Cisco Unified CallManager のペリフェラルが 1 つのペリフェラルとして扱われるので、Unified IP IVR で処理とキューイングを行うためにトランスレーション ルート コールを使用する必要がなくなります。 複数の Unified IP IVR が設定されている場合は、使用可能なキャパシティがある Unified IP IVR の間でコールのロード バランシングが Unified CC システム ペリフェラルで自動的に行われます。
さらに、Unified CC System PG は単一のペリフェラルなので、Termination Call Detail（TCD; 終端コール詳細）レコードと他のレポート データには、コールがペリフェラル上にあった時間全体の情報が格納されます。 最大 3 つの TCD レコード（元のルート用、IVR 用、エージェントの処理時間用）が作成される代わりに、Unified CC System PG で作成されるレコードは 1 つだけです。
Unified CC System PG では Unified CVP がサポートされていないので、Unified CC System PG 内のすべてのキューイングと処理は Unified IP IVR を使用して行われます。
System Unified CC
Unified CCE リリース 7.0 以降では、次の 2 つの方法で Unified CC をインストールできます。
• 従来の Unified ICM セットアップによるインストール（以前から使用可能）
• System Unified CC（リリース 7.0 の新機能）
System Unified CC は、一部の Unified CCE の展開モデルで使用可能で、システムのインストールと設定を大幅に簡素化できます。 新しく簡素化された DVD ベースのインストールが可能で、アドミン ワークステーション上の従来の Unified ICM コンフィギュレーション マネージャの代わりに Unified CC Web 管理ツールを使用して設定します。
System Unified CC は、2 つの特定の本稼働モデルと 1 つのデモ/ラボ展開モデルで提供されています。 これらの展開モデルは、1 つのペリフェラルで Unified CC System PG を展開する形態、つまり、1 組の Cisco Unified CallManager クラスタと 1 台から 5 台の Unified IP IVR に接続する形態になっています。
System Unified CC は、Unified CCE とはインストール方法と設定方法が異なるので、Unified CCE で従来サポートされていた多くのオプションがサポートされていません。 System Unified CC でサポートされるのは次の展開形態だけです。
サーバ 1： セントラル コントローラ： Call Router、Logger
サーバ 2： エージェント/IVR コントローラ： Unified CC System PG（CTI サーバと CTI OS を含む）
サーバ 3： 管理とレポーティング： AW、HDS、Web 管理サーバ
• 中/小規模展開： 2 サーバ構成の Unified CC
サーバ 1： セントラル コントローラとエージェント/IVR コントローラ： Call Router、Logger、Unified CC System PG
サーバ 2： 管理とレポーティング： AW、HDS、Web 管理サーバ
• デモ/ラボ展開： 1 サーバ構成の Unified CC（本稼働ではサポートされません）
サーバ 1： オールインワン： Call Router、Logger、Unified CC System PG、AW、Web 管理サーバ
大規模展開では、通常最大 1,000 人のエージェントが同時にサポートされ、中/小規模展開では、通常最大 300 人のエージェントが同時にサポートされます。 各構成でサポートできるエージェントの具体的な数は、使用するデスクトップ（CTI OS、CAD、CRM 統合）、選択するマルチチャネル オプション、Unified OUTD の使用など、いくつかのサイジング要因によって異なります。 具体的なサイジング要件については、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
System Unified CC のインストール ソフトウェアは、Cisco MCS Unified CallManager アプライアンスで使用するように最適化とテストが行われており、使用できる機種は、「Unified CC のコンポーネントとサーバのサイジング」で指定されているシスコ製サーバ モデルだけです。 この要件は、次に説明するオプションのサーバにも当てはまります。
3 つの展開モデルはそれぞれ冗長化できます。つまり、セントラル コントローラとエージェント コントローラのいずれかまたは両方のサーバを二重化して、最大 2 台の管理コントローラまたは AW をサポートできます。 さらに、次のオプションもインストールできます。
• Web コラボレーション オプション用のマルチチャネル コントローラ（Cisco Collaboration Server）
このオプションは System Unified CC DVD からインストールします。このオプションでは、Web コラボレーション オプション用に事前設定された Media Routing Peripheral Gateway（MR PG; メディア ルーティング ペリフェラル ゲートウェイ）がインストールされます。 Web コラボレーション用のマルチチャネル コントローラは、Web コラボレーション オプションのインストールの一部としてインストールされた Cisco Media Blender コンポーネントと同じサーバにインストールする必要があります。 このコントローラを冗長化したり、デュプレックス サーバを使用したりするオプションはありません。
• E メール オプション用のマルチチャネル コントローラ（Cisco eMail Manger）
このオプションは System Unified CC DVD からインストールします。このオプションでは、E メール オプション用に事前設定された Media Routing Peripheral Gateway（MR PG; メディア ルーティング ペリフェラル ゲートウェイ）がインストールされます。 E メール用のマルチチャネル コントローラは、E メール オプションのインストールの一部としてインストールされた eMail TServer と同じサーバにインストールする必要があります。 このコントローラを冗長化したり、デュプレックス サーバを使用したりするオプションはありません。
このオプションは、System Unified CC DVD からインストールします。 このオプションでは、Unified OUTD 用に事前設定された Media Routing Peripheral Gateway（MR PG; メ ディア ルーティング ペリフェラル ゲートウェイ）がインストールされます。 アウトバウンド コントローラは、専用サーバにインストールする必要があります。 このコントローラを冗長化したり、デュプレックス サーバを追加したり、複数のアウトバウンド コントローラを System Unified CC に追加することはできません。
• Unified CC ゲートウェイのペリフェラル ゲートウェイ
このペリフェラル ゲートウェイは、（System Unified CC DVD ではなく）Unified ICM Setup CD からインストールします。このゲートウェイは System Unified CC の Unified CC System PG を親の Unified ICM Enterprise システムに接続するために使用されます。 このペリフェラル ゲートウェイにより、親の Unified ICM からは、System Unified CC はペリフェラル ゲートウェイに制御された他の ACD と同じように見えるようになります。 このペリフェラル ゲートウェイは、System Unified CC のサーバにはインストールしないでください。 このペリフェラル ゲートウェイは、デュプレックス（A/B）のペリフェラル ゲートウェイ ペアを使用する冗長モードで展開できます。 このペリフェラル ゲートウェイは、親の Unified ICM 上にだけ設定されており、Unified ICM Enterprise システムでサポートされる 80 個の PG の一部として数えられることに注意してください。
System Unified CC を利用できるのは次の展開形態だけです。 System IPCC では特定のツール セットを使用してインストールと設定を行います。これらのツールでは他のオプションは処理できません。 例：
• System Unified CC では、PG と同じサーバへのアウトバウンド コントローラのインストールはサポートされていません。これは専用のサーバにインストールする必要があります。
• System Unified CC では、2 つ目の Unified CC System PG ペリフェラルの追加はできません。 1 つのペリフェラルのモデルだけがサポートされています。
• System Unified CC では、VRU PG の設定および Unified CVP への接続はできません。 System Unified CC では Unified CVP はサポートされません。
ただし、インストールしようとしている展開形態が、System Unified CC の要件に合致している場合は、次のような利点があります。
• インストールの簡素化：System Unified CC を 1 つのユニットとしてインストールして設定できるので、個々のコンポーネントを別々にインストールして設定する必要がありません。
• レジストリ設定とデータベース設定の両方に対する Web ベースの管理：Web インターフェイスを使用してすべての設定を行えるので、レジストリ設定を変更するためにローカル セットアップを実行する必要がなくなりました。
System Unified CC は Unified CCE を使用する多くのお客様の要件を満たし、インストールと管理の簡素化を実現します。 要件がさらに複雑なお客様には、Unified ICM セットアップと Unified ICM コンフィギュレーション マネージャを使用して手動でインストールと管理ができる従来の Unified CCE がサポートされています。 System Unified CC を適用できる構成の場合には、展開時間の削減と管理の簡素化による大きな利点があります。
親/子
Unified CC Gateway PG を使用すれば、Unified CCE または Unified CCX が Unified ICM システムに接続された従来の ACD のように見えるようになります。 Unified CC Gateway PG は、Unified CCE の System PG または Unified CCX/CRS の CTI インターフェイスと通信する Unified ICM システムに PG を提供することによってこの機能を実現します。
Unified CC Gateway PG を使用して展開するときには、Unified ICM は 親 、Unified CC は 子 と呼ばれます。
ネットワークまたはエンタープライズのルーティング ポイントとしての役割を果たす Unified ICM システム。 子は親からは ACD のように見えます。親は適切な Unified CC Gateway PG（Enterprise または Express）を使用して、子 Unified CC の CTI インターフェイスと通信します。 トランスレーション ルートを使用したプレルーティング、ポストルーティング、エンドツーエンドのコール トラッキングなど、Unified ICM が通常実行できるすべての機能を親は実行できます。
Unified CC の System PG、または ACD として機能するようにセットアップされた Unified CCX システム。 子は、親からトランスレーション ルーティングされたコールを受信できますが、親に接続されたほかのペリフェラルは認識できません。 また、子は、Unified CC からのコールを親にポストルーティングできます。この場合のコールは他の Unified ICM コールと同様に処理できます。 たとえば、Unified ICM に制御された任意の（TDM または IP）ACD にコールをトランスレーション ルーティングしたり、Unified CVP を使用する Unified ICM ネットワーク キュー ポイントにコールをキューイングできます。
親/子モデルでは、子 Unified CC は完全に独立して機能するように設定されるので、エージェントにコールをルーティングするのに親に接続する必要はありません。 このような独立性によって、子と親の間のネットワークがダウンした場合や、親または Unified CC Gateway PG との接続に問題が生じた場合でも、ミッションクリティカルなコンタクト センターの運用を完全にローカルで続けることができます。 子システムに入力された設定オブジェクトは、自動的に親 Unified ICM に送られて Unified ICM 設定に挿入されます。そのため、ローカル ACD でルーティングとレポーティングを設定した後、Unified ICM 自身の設定を一致させるためにオブジェクトを再び設定する必要がありません。 Unified CC の子システムを使用してアウトソーシングしているために、子システムのすべてのエージェント、スキルグループ、コールタイプが顧客の Unified ICM システムに適用されるわけではない場合など、設定を自動更新する必要がない顧客の場合には、この機能をオフにすることもできます。
Unified CC Gateway PG を接続できるのは、Unified CC System PG を使用する Unified CCE の子または Unified CCX 4.0 x 以降のリリースだけです。 子の Unified CCE に複数の Unified CC System PG とペリフェラルがある場合は、それぞれに別途 1 つの Unified CC Gateway PG ペリフェラルを親の Unified ICM システムにインストールして設定する必要があります。 Unified CC Gateway PG は、複数の子 Unified CC ペリフェラルを管理できます。最大 5 個の子システムまで可能です。
SIP のサポート
Unified CCE 7.0 エージェントは、Cisco Unified CallManager 5.0 SIP 電話モデル 7941、7961、7970、および 7971 を使用できます。モデル 7940 および 7960 の電話も Cisco Unified CallManager 5.0 との SIP 通信をサポートしていますが、Unified CC エージェントでは使用できません。 ローエンド向けモデルの Cisco IP Phone やサードパーティ製の電話も、Unified CC エージェント用の SIP 電話としては使用できません。
Unified IP IVR および Cisco Unified Queue Manager は、発信者が入力した番号（DTMF 入力）を JTAPI メッセージとして CallManager から受け取ります。 Unified IP IVR および Unified QM では、インバンド DTMF 番号の検出メカニズムはサポートされていません。 インバンド DTMF だけをサポートする（または、RFC 2833 に従ってインバンド DTMF を使用するように設定された）SIP 音声ゲートウェイや SIP 電話を使用する展開では、CallManager が MTP リソースを呼び出してインバンド DTMF シグナリングをアウトオブバンド シグナリングに変換し、発信者が入力した番号が Unified IP IVR または Unified QM に通知されるようにする必要があります。 したがって、このような SIP 電話またはゲートウェイが含まれる環境では、十分な MTP リソースが必要になります。 Unified IP IVR または Unified QM アプリケーションと電話間の対話が必要な環境では、この点に注意してください。
IPT： 単一サイト
単一サイト展開とは、音声ゲートウェイ、エージェント、デスクトップ、Unified IP Phone、およびコール処理の各サーバ（Cisco Unified CallManager、Unified ICM/Unified CC、および Unified IP IVR または Cisco Unified Customer Voice Portal（Unified CVP））がすべて同一のサイトに存在し、Unified CC ソフトウェア モジュール相互間で WAN 接続が使用されていないシナリオを指します。図2-1 は、System Unified CC モデルを使用するこのタイプの展開を示しています。
図2-1 の例では、Unified IP IVR、Cisco Unified CallManager クラスタ、冗長 System Unified CC サーバ、管理コントローラ（アドミン ワークステーション）およびヒストリカル データ サーバ（HDS）で構成され、音声ゲートウェイは PSTN に直接接続されています。 このシナリオの System Unified CC サーバで処理されている主なソフトウェア プロセスは、次のとおりです。
• Cisco Unified CallManager ペリフェラル インターフェイス マネージャ（PIM）と Unified IP IVR PIM を装備した Unified CC System PG
• Cisco Agent Desktop（CAD）サーバを System Unified CC サーバと共存させることも可能
セントラル コントローラとエージェント コントローラ（Unified CC System PG）を、別々のサーバに分離する方法もあります。 どのような状況で Unified ICM セントラル コントローラと PG を別々のサーバにインストールするかについては、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
このシステムは、（System Unified CC ではなく）従来の Unified CCE モデルを使用してインストールできるので、いくつかの異なるオプションを使用できます。 たとえば、コールのキューイングと処理に Unified IP IVR ではなく Unified CVP を使用できます。
System Unified CC や従来の Unified CCE は、冗長化せず、シンプレックスな形態で展開することも可能です。 Unified CC の冗長化で得られる利点とその設計方法については、「アベイラビリティを高めるための設計上の注意点」を参照してください。
Cisco Unified CallManager のノード数や使用するハードウェアの型番は、Unified IP IVR のサーバ数を決めただけでは決定されません。 必要なサーバの台数と型番を決定するための情報については、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
また、このモデルでは LAN に必要なデータ スイッチング インフラストラクチャ、音声ゲートウェイの種類、音声ゲートウェイとトランクの数も特定していません。 これらのコンポーネントを設計する際の手引きとしてシスコでは、キャンパス向けの各種デザイン ガイドおよびシスコ ユニファイド コミュニケーションに関するデザイン ガイドを提供しています。 「コール センターのリソース サイジング」では、ゲートウェイのポート数を決定する方法を説明しています。
このモデルのバリエーションとして、音声ゲートウェイを PSTN に接続する代わりに PBX のライン側に接続するシナリオも考えられます。 一箇所の単一サイトから複数の PSTN と PBX に接続する展開も可能です。 たとえば、ローカルな PSTN、フリーダイヤルの PSTN、従来型の PBX/ACD からのトランクをすべて備えた展開も可能です。 詳細は、「従来の ACD の統合」および「従来の IVR の統合」を参照してください。
この展開モデルでは、PSTN と音声ゲートウェイとの間で使用するシグナリングの種類（ISDN、MF、R1 など）や、音声ゲートウェイと Cisco Unified CallManager との間で使用するシグナリングの種類（H.323 と MGCP のいずれか）を特定していません。
また、このモデルでは、コールの保留、別窓口への転送、および電話会議に必要なデジタル信号プロセッサ（DSP）リソースの規模についても、指定はありません。 これらのリソースのサイジングについては、次の URL にある最新版の『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。
単一サイト展開モデルの大きな長所は、WAN 接続が不要な点です。 WAN が存在しないので、この展開モデルでは一般的に G.729 などの圧縮した Real-Time Transport Protocol（RTP）ストリームを使用する必要がなく、その結果、トランスコーディングが不要になります。
Unified CC：Unified CC System PG
この展開モデルで展開される Agent PG は Unified CC System PG です。 Cisco Unified CallManager と Unified IP IVR（存在する場合）の両方を処理するために必要なペリフェラルは 1 つだけです。 このペリフェラルによって、複数の PIM の表示が統合され、複数の Unified IP IVR 間のコールのロード バランシングも行われます。
IVR： Unified IP IVR による処理とキューイング
この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified IP IVR で実行されます。 このモデル（Unified CC System PG を使用）では最大 5 つの Unified IP IVR を展開できます。 Cisco Unified CallManager のダイヤルプランと Unified CC に制御されたコール スイッチングを使用して、Cisco Unified CallManager の背後に Unified IP IVR が配置されます。 すべてのコールは、Cisco Unified CallManager の CTI ルート ポイントに入り、Unified CC によって制御され、次に Unified CC System PG によって Unified IP IVR に自動的にトランスレーション ルーティングされます。 Unified CC が Unified IP IVR の使用可能なポート間のロード バランシングを行うので、Unified IP IVR と Cisco Unified CallManager の間のトランスレーション ルートを設定する必要はありません。
IVR： Unified CVP による処理とキューイング
通常は単一サイト モデルでは展開されませんが、このモデルでも Unified CVP を使用してコールの処理とキューイングを行えます。 System Unified CC では Unified CVP の使用はサポートされていません。そのため、従来の Unified CCE のセットアップ CD を使用してシステムをインストールする必要があります。 Unified CVP には専用の VRU PG があり、Cisco Unified CallManager PG と同じサーバにロードされているか、Generic PG の組み合せの一部になっています。 このモデルでは Web 設定ツールが使用できないので、Unified ICM アドミン ワークステーションのコンフィギュレーション マネージャ アプリケーションを使用してすべての設定を直接行う必要があります。 さらに、Unified CVP は Unified CC System PG ペリフェラルの一部ではないので、コールをコール データとともにペリフェラル間で転送するためのトランスレーション ルートを設定する必要があります。
この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified CVP を使用して実行されます。 すべての Unified CVP プロセスを同一のサーバ上で実行すれば、サーバが 1 台で済む可能性もあります。一方、サーバを複数台使用すれば、スケーリングが可能となり冗長性も得られるようになります。冗長性の詳細については、「アベイラビリティを高めるための設計上の注意点」を参照してください。
Unified CVP の詳細については、次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。
Unified CC：Enterprise Unified CC PG
これらの展開モデルでは、Enterprise Unified CC のペリフェラルを使用して Cisco Unified CallManager とのやり取りが処理され、別に設定された VRU ペリフェラルを使用して Unified IP IVR または Unified CVP とのやり取りが処理されます。 System Unified CC では Enterprise Unified CC の PG の使用はサポートされていません。そのため、従来の Unified CCE のセットアップ CD を使用してシステムをインストールする必要があります。 つまり、これらのシナリオでは Web 設定ツールは使用できません。
IVR： Unified IP IVR による処理とキューイング
この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified IP IVR で実行されます。 複数の Unified IP IVR が配置されている場合は、Unified ICM を使用してこれらの Unified IP IVR 間でコールのロード バランシングを行う必要があります。 Cisco Unified CallManager ペリフェラルと Unified IP IVR ペリフェラルの間のトランスレーション ルートは手動で設定する必要があります。Cisco Unified CallManager と Unified IP IVR の間のコールとデータの移動はこのルートを使用して行われます。 ロード バランシングは、Unified CC コール ルーティング スクリプト内の「Translation Route To VRU（VRU トランスレーション ルート）」ノードで手動で行います。
IVR： Unified CVP による処理とキューイング
通常は単一サイト モデルでは展開されませんが、このモデルでも Unified CVP を使用してコールの処理とキューイングを行えます。 Unified CVP には専用の VRU PG があり、Cisco Unified CallManager PG と同じサーバにロードされているか、Generic PG の組み合せの一部になっています。
この展開モデルでは、最初のキューイングとそれに続くキューイングはすべて Unified CVP を使用して実行されます。 すべての Unified CVP プロセスを同一のサーバ上で実行すれば、サーバが 1 台で済む可能性もあります。一方、サーバを複数台使用すれば、スケーリングが可能となり冗長性も得られるようになります。冗長性の詳細については、「アベイラビリティを高めるための設計上の注意点」を参照してください。
Unified CVP の詳細については、次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。
Unified CC：転送
この展開モデルでは、（複数のサイトに対する集中型コール処理モデルの場合も同様ですが）転送元エージェントとターゲット エージェントが同一のペリフェラル上に存在しています。 これは、ルーティング クライアントとペリフェラル ターゲットが同一のペリフェラルであることを意味しています。 転送元エージェントは、Cisco Unified CallManager 内の CTI ルート ポイントとして設定された特定の着信番号宛てに転送を生成します（たとえば、スキルグループに属する専門家を探します）。
エージェント ペリフェラル（Unified CC システム ペリフェラルか Enterprise Unified CC ペリフェラルのいずれか）は、Unified ICM ルータ宛てにルーティング要求を生成します。 Unified ICM Router では、着信番号とコール タイプが照合され、適切なルーティング スクリプトが実行されます。 このルーティング スクリプトでは、応答可能な専門家が検索されます。
転送されたコールを受信するターゲット エージェント（専門家）が存在すれば、Unified ICM Router から要求元のルーティング クライアント（エージェント ペリフェラル）に適切なラベルが返送されます。 このシナリオの場合、ターゲット エージェントが現在ログインしている電話の内線番号がラベルとして使用されるのが普通です。このルーティング応答（ラベル）を受信した Cisco Unified CallManager PIM から Cisco Unified CallManager に JTAPI 転送要求が送信されることで、転送処理が始まります。
ルーティング クライアントにラベルが返送されると同時に、目的のコールから収集されたあらゆるコール データを含むプレコール データが、ペリフェラル ターゲットに送信されます。 このシナリオの場合、ルーティング クライアントとペリフェラル ターゲットは同一エージェントのペリフェラルです。 これは、転送元エージェントとターゲット エージェントが同一のペリフェラルに関連付けられているためです。 ルーティング クライアントとペリフェラル ターゲットが異なるような、より複雑なシナリオは、後半のセクションで紹介します。
転送されたコールを受信するターゲット エージェントが存在しない場合、そのコールはキュー処理を行う IVR に転送されるように Unified ICM ルーティング スクリプトを設定するのが普通です。 このシナリオでは、Unified CC System PG のロジックは、Unified CCE PG のロジックとは異なります。
どちらの場合も、Cisco Unified CallManager に対して IVR へのコール転送を指示する着信番号がラベルとして使用されます。 Unified CC System PG の場合は、ペリフェラル ターゲットとルーティング クライアントが両方とも Unified CC システムのペリフェラルです。 トランスレーション ルーティングは、明示的なトランスレーション ルートを Unified ICM に設定しなくても行われます。
Unified CCE ペリフェラルの場合は、ルーティング クライアントとペリフェラル ターゲットが異なります。 ルーティング クライアントは Unified CCE ペリフェラルですが、ペリフェラル ターゲットはコールの転送先として指定された IVR PIM です。 そのため、トランスレーション ルートを明示的に設定する必要があります。
IPT： 複数のサイトに対する集中型コール処理
複数のサイトに対する集中型コール処理とは、コール処理サーバ（Cisco Unified CallManager、Unified ICM、および Unified IP IVR または Unified CVP）が同一のサイトに存在し、音声ゲートウェイ、エージェント、デスクトップ、および Unified IP Phone が任意の組み合せで、WAN リンクを介した別の場所、または集中管理された別の場所にあるようなあらゆるシナリオを指します。図2-2 は、このタイプの展開を示しています。
この IPT モデルには次の 2 種類のバリエーションがあります。
IPT： 音声ゲートウェイを集中させる場合
大都市圏に小規模なリモート サイト群やオフィス群を持っているために、コール処理サーバや音声ゲートウェイを複数設置することが効率的ではない企業には、このモデルが最適です。 サイトの規模が大きくなったり地理的に離れた場所に設置されるようになると、音声ゲートウェイを分散して配置する方が好結果につながることもあります。
図2-2 に、System Unified CC による展開を使用したこのモデルを示します。
図2-2 複数のサイトに対して集中型コール処理と集中型音声ゲートウェイを展開した場合
• エージェントが数人だけのリモート サイトで必要となるのは小規模なデータ スイッチ、ルータ、Unified IP Phone、エージェント デスクトップだけであり、そこで必要となるシステム管理とネットワーク管理のスキルもごく限られたものになります。
• このような小規模なサイトとオフィスでは、WAN リンクの障害に備えた緊急連絡用の POTS 回線を除き、PSTN と直接接続するトランクが不要です。
• PSTN トランクでは小規模なリモート サイト用のトランクを集約できるため、より効率的な運用が可能になります。
• Unified CC キュー ポイント（Unified IP IVR または Unified CVP）にはすべてのキュー ポイントが集約されているので、効率的な運用を図ることができます。
• コールのキューイング（最初のキューイングとそれに続くキューイング）中は、VoIP の WAN 帯域幅が消費されません。 コールが WAN 経由で拡張されるのは、発信者に応答できるエージェントがいる場合だけです。
単一サイト展開モデルに関するように、従来の Unified CCE の設定を使用するときには、同じオプションがすべて存在します。 たとえばマルチサイト展開でも、Unified ICM ソフトウェアをすべて同一のサーバで実行する場合や複数のサーバで実行する場合があり得ます。 Unified ICM ソフトウェアは、冗長系を構成してインストールする場合と冗長系を構成せずにインストールする場合があり得ます。 Unified ICM ソフトウェアは、Unified CC System PG または Unified CCE PG のどちらかとともに展開できます。 このシステムは System Unified CC を使用して展開できます。 この展開モデルでは、Cisco Unified CallManager および Unified IP IVR サーバまたは Unified CVP サーバの数は指定されていません。同様に、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN 接続についても指定はありません。 他のバリエーションについては、「IPT： 単一サイト」を参照してください。
• リモート サイトのエージェントの電話への RTP トラフィックには VoIP WAN の接続が必要です。
• VoIP WAN の帯域幅消費を抑えるために、リモートサイトのエージェントの電話までの RTP トラフィックを圧縮する必要があるかもしれません。 サイト内のコールは非圧縮とすることが望ましいので、シスコ ユニファイド コミュニケーションの展開デザインによっては、トランスコーディングが必要となります。
• Unified IP Phone から Cisco Unified CallManager クラスタへの Skinny Client Control Protocol（SCCP）コール制御トラフィックは、WAN を経由して流れます。
• Unified CC Agent Desktop で送受信される CTI データは、WAN を経由して流れます。 これらのリンクでは、十分な帯域幅と QoS のプロビジョニングが不可欠です。
• リモート サイトには音声ゲートウェイがありません。したがって、もしもトランクと組み合わせた音声ゲートウェイがリモート サイトにあれば公衆電話交換網の電話による市内通話が可能な番号に対しても、顧客は市外電話番号をダイヤルする必要があります。 中央サイトにおけるフリー ダイヤルで受け付けることが可能な業務であれば、この問題を回避することも可能です。 その場合、顧客にフリー ダイヤル番号を提供し、その番号へのコールはすべて集中型の音声ゲートウェイのある場所にルーティングさせます。 ただしこの方法では、コール センターがフリー ダイヤル料金を負担する必要があります。この事態は顧客が PSTN の市内局番でダイヤルできるようにすれば避けられます。
• PSTN トランクと組み合わせたローカル音声ゲートウェイがないため、緊急電話（119、110）へのアクセスに問題があります。この問題は、Cisco Unified CallManager のダイヤル プランで管理する必要があります。 ほとんどの場合、ローカル トランクでは緊急電話（119、110）は地元の緊急連絡先に接続されます。
• Cisco Unified CallManager による Location に基づくコール アドミッション コントロールが失敗すると、ルーティングされたコールが接続解除されます。 したがって、リモート サイトと接続する帯域幅は十分余裕を持ってプロビジョニングすることが重要です。 また、WAN の QoS を適切に設計することは欠かせません。
IVR： Unified IP IVR による処理とキューイング
中央サイトが一箇所だけの展開では、単一サイト展開の場合と同様にすべてのコールに対するキューイングが Unified IP IVR で行われます。 コールがキューイングされている間は、WAN 上に RTP トラフィックが流れません。 無応答時の転送や再ルーティングで再キューイングが必要になっても、キュー処理で RTP トラフィック フローが WAN 上を流れることはありません。 これにより、リモート サイトとの接続に必要な WAN 帯域幅を抑えることができます。
IVR： Unified CVP による処理とキューイング
Unified CC：転送
このシナリオでの転送は、コンタクト センターの観点から見れば、単一サイトのシナリオと同じです。 したがって、転送元エージェントがターゲット エージェントと同じ LAN にいるか、別の LAN にいるかに関係なく、単一サイト モデルの場合と同じコールとメッセージのフローが発生します。 違うのは、QoS を確保する必要があることと、適切な LAN/WAN ルーティングを設定する必要があることだけです。 QoS に配慮した WAN のプロビジョニングについての詳細は、次の URL にある最新版の『 Cisco Network Infrastructure Quality of Service Design 』を参照してください。
（発信者ではなく）エージェントがコンサルテイティブ転送を行なった結果が Unified IP IVR ポートにルーティングされてキューイング処理の対象となる場合はトランスコーディングが必要になります。これは、Unified IP IVR で生成できるのが G.711 メディア ストリームのみであるためです。
IPT： 音声ゲートウェイを分散させる場合
集中型コール処理モデルでは、複数の入力音声ゲートウェイを別々の場所に設置するバリエーションも可能です。 この分散型音声ゲートウェイのモデルが適するのは、小規模なサイトを数多く持ち、それぞれのサイトで市内からの電話に対応するローカルな PSTN トランクを必要とする企業です。 このモデルは、市内電話用のローカルな PSTN 接続とローカルな緊急電話へのアクセスを提供します。図2-3 にこのモデルを示します。
図2-3 複数のサイトに対して集中型コール処理と分散型音声ゲートウェイを展開した場合
キューイングと処理に使用する Unified IP IVR を持つこの展開モデルでは、各サイトにインバウンドしたコールをそのサイトにいるエージェントだけで処理するように制限することが望ましいとも言えますが、必ずしもそれが必要というわけではありません。 インバウンド コールを同一サイト内で処理するよう制限すると、次の状況が適用されます。
• 入力音声ゲートウェイからエージェント向けのコールで消費される VoIP WAN 帯域幅を節約できます。
• コールは、キューにある間または集中型 Unified IP IVR で処理されている間は、引き続き VoIP WAN を通過します。
• コールのキュー時間と処理時間が長くなるため、サイトに着信するコールに対して顧客サービス レベルが低下する可能性があります。
• キュー時間が長くなる可能性があります。これは、この Unified CC の設定では、他のサイトのエージェントが利用可能であっても、現在のローカル サイトのエージェントに空きが出るまで待つためです。
• 処理時間が長くなる可能性があります。これは、より適したエージェントが他のサイトに存在しても、WAN 帯域幅の消費を抑えるためにコールはローカル エージェントにルーティングされるためです。
この展開モデルで、コールが到達したサイトへのコールを制限するには、エージェント用の別個のスキル グループを場所ごとに作成する必要があります。 場所に関係なく特定のスキルのエージェントにコールをルーティングするには、エンタープライズ スキル グループを使用して、場所ごとのスキル グループを結合できます。
展開を担当するチームにとっては、運用コストと顧客の満足度との妥協点を慎重に評価し、各顧客の事情に合った適切なバランスを確立することが重要になります。 たとえば、特定の重要顧客からのコールは他のサイトにルーティングしてキュー時間を短縮したうえで経験豊かな担当者の手に委ねられるようにし、それ以外の顧客からのコールは着信したサイトのエージェントによる扱いに限定するという方法も可能です。
Unified CC の実際の展開で集中型の音声ゲートウェイと分散型の音声ゲートウェイを組み合わせることも可能です。 フリー ダイヤル サービスを提供する 1 つの PSTN キャリアに集中型の音声ゲートウェイを接続し、市内電話サービスを提供するそれ以外の PSTN キャリアに分散型の音声ゲートウェイを接続するという方法もあります。
市内 PSTN からのインバウンド コールには、ダイヤルイン方式（DID; Direct Inward Dial）とコンタクト センター コールの両方が可能です。 すべてのインバウンド コールとアウトバウンド コールに対する要件を把握し、音声ゲートウェイの最も効率的な設置場所を決めることが重要です。 どのような人たちが、何の目的で、どこから、どのような方法で電話しているのかを特定します。
複数サイトの展開と分散型音声ゲートウェイを使用する従来の Unified CCE モデルでは、Unified ICM のプレルーティング機能を利用して、複数のサイト間でコールを動的にロード バランシングできます。 Unified ICM のプレルーティング機能を提供している PSTN キャリアのリストは、次の URL にある Unified ICM の関連ドキュメントに掲載されています。
http://www.cisco.com/univercd/cc/td/doc/product/icm/
ローカルな PSTN トランクと、それとは独立したフリー ダイヤル トランクの両方を備える音声ゲートウェイでコンタクト センターへのコールを受ける複数サイト環境では、Unified ICM プレルーティング ソフトウェアを使用してフリー ダイヤル コンタクト センターへのコールとローカル コンタクト センターへのコールとの間でのロード バランシングが可能です。 たとえば、サイト 1 とサイト 2 の 2 つのサイトによる展開を考えます。サイト 1 では現在すべてのエージェントでコールを処理中であり、数多くのコールがキューにあるとします。一方、サイト 2 ではキューにあるコールがわずかであるか、あるいは一部のエージェントが空いている状況であるとします。 このシナリオでは、Unified ICM を通じてフリー ダイヤル プロバイダーが抱えているフリー ダイヤル コールのほとんどまたはすべてをサイト 2 にルーティングできます。Unified ICM が提供するこのタイプの複数サイト間ロード バランシングは動的で、すべてのサイトの呼量変動に伴って自動的に調整されます。 System Unified CC の展開モデルでは Unified ICM プレルーティングがサポートされていないことに注意してください。Unified ICM プレルーティングが使用できるのは、従来の Unified CCE または PSTN に対するプレルーティング インターフェイスが親の Unified ICM にある親/子モデルの場合だけです。
前述の 2 つの展開モデル同様、数多くのバリエーションが存在します。これらのバリエーションでは、Unified ICM、Cisco Unified CallManager、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、Cisco Unified CallManager、および PG（Cisco Unified CallManager および IVR/Unified CVP の双方で使用）は、同じ場所に設置します。 このモデルで WAN を介して分離できる Unified CC 通信は次の項目に限られます。
–Unified ICM セントラル コントローラと Unified ICM PG 間の通信
–Unified ICM PG と Unified CC Agent Desktop 間の通信
–Cisco Unified CallManager と音声ゲートウェイ間の通信
–Cisco Unified CallManager と Unified IP Phone 間の通信
–Unified CVP コール制御サーバとリモート音声ゲートウェイ間の通信（コール制御）
• コールの処理がインバウンド先サイトだけに制限されない場合や、サイト間でコールが取り交わされる場合は、WAN を通じて流れる RTP トラフィックが増加します。 この場合はサイトの間や場所の間を流れるコールの最大量を見極めることが重要です。 Location に基づいて Cisco Unified CallManager で実行されるコール アドミッション コントロールが失敗すると、ルーティングされたコールが接続解除されます（Cisco Unified CallManager 内での再ルーティングは現在サポートされていません）。 このため、リモート サイトとの接続帯域幅には十分な余裕を持ってプロビジョニングし、WAN の QoS を適切に設計することが重要です。
• 分散した音声ゲートウェイと集中化 Cisco Unified CallManager サーバとの間では、WAN を経由して H.323 シグナリング トラフィックまたは MGCP シグナリング トラフィックが流れます。 WAN の QoS を適切に実現することが不可欠です。また、シグナリングの遅延は次の URL にある最新版の『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』に示されている許容値の範囲内に収める必要があります。
Unified CC：Unified CC System PG
コンタクト センターのコンポーネントの展開は他の複数サイトの集中型コール処理の展開と基本的に同じなので、同じ利点と制限が Unified CC System PG を使用した Unified CC の展開にも当てはまります。
さらに、Unified ICM プレルーティングを使用してキャリアとやり取りして音声ゲートウェイにコールを配信する場合は、NIC ルーティング クライアントから Unified CC System PG へのトランスレーション ルートを Unified ICM アドミン ワークステーションの ConfigManager アプリケーションを使用して手動で設定する必要があります。 プレルーティングは System Unified CC の展開の一部としてはサポートされていません。
Unified CC と IVR： Unified IP IVR による処理とキューイング
中央サイトで処理およびキューイングされるすべてのコールをサポートできるように、WAN の帯域幅をプロビジョニングする必要があります。
Unified IP IVR を集中配置することで、Unified IP IVR を小規模な複数サイトに分散展開する場合と比べて、Unified IP IVR のポート利用効率を高めることができます。
System Unified CC では Unified CVP はサポートされません。 VRU ペリフェラルを別途設定して展開する必要があります。 つまり、コールをコール データとともにペリフェラル間で転送するためにトランスレーション ルートを設定する必要があります。 ただし、このモデルで Unified CVP を使用すれば VoIP WAN を介して集中型 Unified IP IVR でコールを処理する必要がなくなるので、リモートの分散型入力音声ゲートウェイで発信者のキューイングと処理が行えるという利点があります。 Unified CVP をキューイングと処理に使用する場合、展開で選択できるのは Unified CCE PG だけです。
コールの処理とキューイングに Unified CVP を使用することで、WAN を経由して流れる音声トラフィックの量を削減できます。 コールはリモート ゲートウェイで Unified CVP によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終端させる必要がありません。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。
Unified CC：Unified CCE PG
コンタクト センターのコンポーネントの展開は他の複数サイトの集中型コール処理の展開と基本的に同じなので、Unified CCE PG を使用した Unified CC の展開にも同じ利点と制限が当てはまります。
さらに、Unified ICM プレルーティングを使用してキャリアとやり取りして音声ゲートウェイにコールを配信する場合は、別個の Unified CVP と Cisco Unified CallManager のペリフェラルを Unified ICM に設定した従来型の Unified CCE を使用して NIC ルーティング クライアントのトランスレーション ルートを設定する必要があります。
IVR： Unified IP IVR による処理とキューイング
中央サイトで処理およびキューイングされるすべてのコールをサポートできるように、WAN の帯域幅をプロビジョニングする必要があります。
Unified IP IVR を集中配置することで、Unified IP IVR を小規模な複数サイトに分散展開する場合と比べて、Unified IP IVR のポート利用効率を高めることができます。
コールの処理とキューイングに Unified CVP を使用することで、WAN を経由して流れる音声トラフィックの量を削減できます。 コールはリモート ゲートウェイで Unified CVP によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終端させる必要がありません。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。
Unified CC：転送
VoIP WAN を使用してサイト間で RTP ストリームを送信するサイト内転送やサイト間転送は、単一サイトでの転送や集中型の音声ゲートウェイを持つ展開での転送と基本的に同じ方法で実行されます。
サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、キャリアが提供する PSTN 転送サービスを利用することもできます。 このサービスを利用すると、Unified CC 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。 各サイトは、独立したエージェント ペリフェラルとして Unified ICM 内で設定可能です。 転送がサイト内であるかサイト間であるかは、Take Back and Transfer（*8）または転送接続を使用してラベルに示されます。 これらの転送トーンは音声パス経由でインバンドで再生されますが、Unified IP IVR で録音ファイルが再生されるか、Unified CVP から数値でアウトパルスされる必要があります。
IPT： 複数のサイトに対する分散型コール処理
互いに遠隔地に存在する中規模から大規模のサイトを複数持つ企業では、分散型コール処理モデルが採用される傾向にあります。 このモデルでは、Cisco Unified CallManager クラスタ、コールの処理とキューを行う装置、PG、CTI サーバが各サイトに配置されます。 ただし音声ゲートウェイについては、集中型コール処理モデルと同様、各サイトに展開するか一箇所に集中して展開するかを選択できます。 分散型の音声ゲートウェイと集中型の音声ゲートウェイを組み合わせて、たとえば前者で市内局番向けのローカル コール、後者でフリー ダイヤル宛てのコールを処理したり、同様にコールの処理とキューにおいても集中型と分散型のポイントを組み合わせることが可能です。
System Unified CC の展開モデルは 1 組の Cisco Unified CallManager クラスタに限定されているので、この場合は適切ではありません。 代わりに、ローカルの Cisco Unified CallManager と Unified CC を各サイトで使用してローカルに分散型のコール処理を行い、集中型の Unified ICM Enterprise を親として企業全体のルーティング、レポーティング、およびコール制御を行う Unified ICM Enterprise（親）と Unified CC（子）のモデルを使用するのが適切です。
このモデルで展開するサイトの数に関係なく、この場合も論理的な Unified ICM セントラル コントローラは 1 つだけです。 Unified ICM セントラル コントローラにも冗長性を適用して展開する場合、サイド A とサイド B を隣接して展開することも可能ですが、地理的に離れたサイトに展開してリモートの冗長性を実現することも可能です。 リモートの冗長性の詳細は、次の URL で Unified ICM の関連ドキュメントを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/icm/
Unified CC： 分散型音声ゲートウェイにおける処理とキューイングを Unified IP IVR で行う場合
この展開モデルは、中規模から大規模のサイトを複数持つ企業において望ましい選択肢となり得ます。 このモデルでは、PSTN トランクを組み合わせた音声ゲートウェイにより、処理が各サイト内で終了します。 分散型音声ゲートウェイを備えた集中型コール処理モデルの場合と同様に、コールのルーティング先を着信サイトのエージェントに限定すれば、WAN の帯域幅消費を抑えられる利点があります。 コールをサイト内に制限するかどうかは、顧客サービス レベルの向上から得られる利点と WAN のコスト低減から得られる利益を比較分析して判断する必要があります。図2-4 に、Unified CC System PG を使用した従来型の Unified CCE による展開を使用したこのモデルを示します。
図2-4 複数のサイトに対して分散型コール処理と Unified IP IVR を備えた分散型音声ゲートウェイを展開した場合
前述のモデル同様、数多くのオプションが使用可能です。 Unified ICM サーバ、Cisco Unified CallManager サーバ、Unified IP IVR サーバの台数と型番が変更可能です。 さらにこの展開モデルでは、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN トランク、冗長性なども変更可能な要素です。 セルフサービス、フリー ダイヤル コール、小規模サイトのサポートなどのために、集中処理とゲートウェイを追加できます。そのほか、プレルーティング PSTN ネットワーク インターフェイス コントローラ（NIC）も選択可能です。
• スケーラビリティ：各独立サイトは、Cisco Unified CallManager クラスタごとにサポートされている最大数のエージェントを置ける規模まで拡張できます。また、同時エージェント数の合計が Unified CCE システムでサポートされているエージェント数より少なければ、企業全体の単一コンタクト センターを形成するために Unified ICM セントラル コントローラで組み合わせ可能なサイトの数に、ソフトウェア上の制限はありません。 スケーラビリティとサイジングの情報については、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。 サイト間で音声コールを転送するには、図2-4 に示す QoS WAN が必要です。 しかし、Take Back and Transfer や転送接続のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。
• Unified ICM プレルーティングを使用して、使用可能なエージェントまたは Unified IP IVR ポートの状況に基づいて、需要が多いサイトへのコールをロード バランシングし、VoIP トラフィックによる WAN の使用率を下げることができます。
• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。
• Unified ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。
• Unified ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。
• Unified ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。
• PG、Cisco Unified CallManager クラスタ、Unified IP IVR は同じコンタクト センター サイトに置く必要があります。
• Unified ICM セントラル コントローラから PG への通信リンクは適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります（詳細は、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください）。
• WAN の帯域幅が利用できない場合は、ゲートキーパーに基づくコール アドミッション コントロールを使用し、PSTN を経由してサイト間でコールを再ルーティングできます。発生が見込まれるコールの最大量に見合った WAN 帯域幅をサイト間で確保するのが最善です。
• PG と Unified ICM セントラル コントローラ間の通信リンクが失われると、そのサイトではコールに対するコンタクト センターのルーティング機能も失われます。 したがって、耐障害性を備えた WAN の実装が重要になります。 耐障害性を備えた WAN を実装していても、Unified ICM セントラル コントローラと PG 間の通信が失われた場合に備え、コール処理とルーティングについて緊急時計画を策定しておくことが重要です。 たとえば、Unified ICM セントラル コントローラとの接続が失われると、Cisco Unified CallManager CTI ルーティング拠点ではコールが Unified IP IVR ポートに送信され、基本的なアナウンスメント処理ができるようにしたり、他のサイトへの PSTN 転送を呼び出したりできるようになっています。 また、接続が失われた Cisco Unified CallManager クラスタから、Unified ICM セントラル コントローラとの接続が有効な PG を持つ他の Cisco Unified CallManager クラスタにコールをルーティングする方法もあります。 これらのオプションの詳細については、「アベイラビリティを高めるための設計上の注意点」を参照してください。
• 同一のコールに対してクラスタ間コール レッグが 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 のエージェントが使用している Unified IP Phone に直接流れます。ただし、2 つの Cisco Unified CallManager クラスタでは、それらの間で進行中の 2 つのコールが論理的に認識されています。
転送
サイト内の転送は、単一サイトでの転送と同様に機能します。 Cisco Unified CallManager クラスタ間の転送では、VoIP WAN または PSTN サービスを利用します。
VoIP WAN を使用する場合は、クラスタ間トランクを十分に設定する必要があります。 サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、PSTN 転送サービスを利用することもできます。 このサービスを利用すると、Unified CC 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。 もう 1 つの方法として、サイト 1 の Cisco Unified CallManager クラスタから逆に PSTN にアウトバウンド コールを送信する方法があります。そのコールは PSTN からサイト 2 にルーティングされます。ただし、サイト 1 ではコールの残りを処理するために 2 つの音声ゲートウェイ ポートが使用されます。
Unified CC： Unified CC System PG
複数のリモート サイトを使用して設計されたこのモデルは、System Unified CC の展開モデルではサポートされていません。 ただし、Unified CCE 7.0 では、インストール、設定、およびルーティングを簡素化するために、それより前のバージョンの Cisco Unified CallManager と Unified IP IVR のペリフェラルに Unified CC System PG が 1 つのペリフェラルとして導入されています。 このモデルでは、リモート サイトにある PG を Unified CC System PG としてインストールして、1 つの論理 PG のインスタンスとペリフェラルに Unified IP IVR と Cisco Unified CallManager のペリフェラルを統合できます。
ただし、このモデルでは、Web 設定ツールは使用できません。 システムの中心部分は、Unified ICM アドミン ワークステーションの ConfigManager アプリケーションを使用して手動で設定する必要がある従来型の Unified CCE モデルのままです。 このモデルは、System Unified CC の展開モデルそのものを実際に使用しなくても、共通コンポーネント（Unified CC System PG）を 2 つの展開モデルで共有できる独自の設計になっています。 このモデルは、通常次のような場合に使用します。委託を受けた企業が 1 社の顧客用に独自のコールセンターをセットアップして Unified CC System PG として展開します。その Unified CC System PG に Unified CC Gateway PG を装備して、顧客企業が自分の Unified ICM Enterprise システムを接続できるようにします。このようにすれば、ACD を外部に委託する場合と同じような運用が可能になります。
Unified CC： Unified CCE PG
複数のリモート サイトを使用するように設計されたこのモデルは、複数の分散型ペリフェラル ゲートウェイを使用する従来型の Unified CCE の設計に一層適しています。 このシステムは、Generic PG または Cisco Unified CallManager と Unified IP IVR PG の両方をサイトに装備すれば展開できます。ただし、このソリューションを新しく展開する場合は、新しい Unified CC System PG を使用してこれらのペリフェラルを両方とも 1 つのペリフェラルに統合して従来型のモデルのルーティングとレポーティングを実現する方が簡単な場合があります。 既存のお客様で Unified CCE 7.0 にアップグレードする場合は、既存の Generic PG または複数 PG モデルを使用し続けることもできます。
代替手段： 親/子
この展開モデルの代替手段として、各分散サイトに子の Unified CC を配置する親/子の展開モデルを使用することもできます。 このモデルには、WAN での耐障害性が向上するという利点があり、障害時にも各サイトで完全に独立した運用を続けることができます。図2-5 に、親子モデルを使用して同じモデルを展開した例を示します。
図2-5 分散型コール処理と親/子モデルを使用した複数サイトの展開
この設計では、Unified CVP とそのシステム自身のアドミン ワークステーションと HDS サーバが装備された親の Unified ICM Enterprise システムがあります。 各分散サイトには、セントラル コントローラとエージェント コントローラの両方をシステム サーバで運用する小/中規模モデルを使用した完全な System Unified CC が展開されます。 その特定のサイトの設定、スクリプティング、レポーティングを System Unified CC で行うためのローカル管理サーバ（アドミン ワークステーション）も展開されます。 System Unified CC を親の Unified ICM に接続するための Unified CC Gateway PG は、親の Unified ICM に展開されたペリフェラル ゲートウェイの一部になっています。
この設計で展開されているローカルの System Unified CC は、自分自身のローカル 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 に送り返すことをせずに、ローカルでキューイング処理します。
子の System Unified CC を展開すると、Unified ICM ポストルーティングを使用するサイト間で Unified CC Gateway PG によるシステム間コール転送も行えます。 Unified CC Gateway PG を使用すれば、別のサイトにいる最適のエージェントにコールへの転送や、次の応答可能エージェントを待つ中央でのキューイングを行うように、子の System Unified CC から Unified ICM に依頼できます。
分散型の Cisco Unified CallManager ペリフェラル ゲートウェイを備えた従来型の Unified CCE モデルとは異なり、親/子モデルを使用すれば、コンタクト センター サイトで完全な冗長性をローカルに実現できます。 ローカルの System Unified CC が Unified CVP ゲートウェイからのインバウンド コールの処理を引き継ぎ、ローカルの Unified IP IVR でコールのキューイングと処理がローカルに行われます。 この設計は、完全な冗長性や 100 % の稼働が求められるコール センターに最適で、WAN に障害が発生してもダウンしません。
この設計は、TDM ACD プラットフォームにすでに Unified ICM がインストールされているお客様で Unified CC を使用する新しいサイトを追加したり、既存のサイトを Unified CC に変更したりするのに適した方法です。 この方法では、企業全体のルーティングとすべてのサイトのレポーティングを引き続き Unified ICM で行いながら、新しい Unified CC テクノロジーをサイト単位で導入できます。
• 親の Unified ICM が制御するすべての分散サイトを対象にした仮想ネットワーク キューを Unified CVP で実現できます。 親の Unified ICM からすべての分散サイトを見ることができ、次の応答可能なエージェントに仮想キューからコールを送信でききます。
• 各分散サイトは、1 つの System Unified CC 展開でサポートできるエージェントの最大数まで拡張できます。 複数の System Unified CC を 1 組の Cisco Unified CallManager クラスタに接続すれば、クラスタでサポートされるエージェントの最大数まで拡張できます。 System Unified CC は、親の Unified ICM の Unified CC Gateway PG を使用して親の Unified ICM に接続されるので、親の Unified ICM Enterprise システムでサポートされるエージェントの最大数まで拡張できます。
• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。 サイト間で音声コールを転送するには、図2-5 に示す QoS WAN が必要です。 しかし、Take Back and Transfer や転送接続のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。
• Unified ICM プレルーティングを使用して、使用可能なエージェントまたは Unified CVP セッションの状況に基づいて、需要が多いサイトへのコールをロード バランシングし、VoIP トラフィックによる WAN の使用率を下げるように、最適のサイトにコールをルーティングできます。
• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。
• 親の Unified ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。
• 親の Unified ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。
• 親の Unified ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。
• サーバ数：ソフトウェア コンポーネント（追加の Gateway PG、子ごとに追加するセントラル コントローラなど）の数が増えるので、親/子モデルを管理するために必要なサーバ数は通常は多くなります。
• Unified CC Gateway PG、Cisco Unified CallManager クラスタ、Unified IP IVR、System Unified CC は同じコンタクト センター サイトに置く必要があります。
• 親の Unified ICM セントラル コントローラから Unified CC Gateway PG への通信リンクには適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります（詳細は、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください）。
• WAN の帯域幅が利用できない場合は、ゲートキーパーに基づくコール アドミッション コントロールを使用し、PSTN を経由してサイト間でコールを再ルーティングできます。発生が見込まれるコールの最大量に見合った WAN 帯域幅をサイト間で確保するのが最善です。
• Unified CC Gateway PG と親の Unified ICM セントラル コントローラ間の通信リンクが失われると、そのサイトでは、コールに対するコンタクト センターのルーティング機能がローカルの System Unified CC によって制御されます。 Unified CVP によって制御される入力音声ゲートウェイに「サバイバビリティ（存続可能性）」TCL スクリプトを設定してローカルの Cisco Unified CallManager CTI ルート ポイントにインバウンド コールをリダイレクトし、WAN の障害時にはローカルの Unified IP IVR を使用してローカル キューイングとローカル処理を行います。 これは親/子モデルの主要な機能で、コール センターが完全にローカルで運用できるようになります。詳細は、「アベイラビリティを高めるための設計上の注意点」を参照してください。
• 同一のコールに対してクラスタ間コール レッグが 2 つ存在しても、不要な RTP ストリームが発生することはありません。ただし、その場合は 2 つの独立したコール シグナリング制御パスが、2 つのクラスタ間にそのまま維持されます（これによってヘアピン ルーティングが生成され、クラスタ間トランクの数が 2 つ減少します）。
• 親の Unified ICM セントラル コントローラとリモート Unified CC Gateway PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）にする必要があります。
IVR： 分散型音声ゲートウェイにおける処理とキューイングを Unified CVP で行う場合
この展開モデルは、コール処理とキューイングで Unified IP IVR の代わりに Unified CVP が使用されている点を除けば、前述のモデルと同じです。 このモデルでは、PSTN トランクを組み合わせた音声ゲートウェイにより、処理が各サイト内で終了します。 分散型音声ゲートウェイを備えた集中型コール処理モデルの場合と同様に、コールのルーティング先を着信サイトのエージェントに限定すれば、WAN の帯域幅消費を抑えられる利点があります。 コールの処理とキューイングも着信したサイトで完了できるようにすれば、WAN 帯域幅をさらに節約できます。図2-6 は、従来型の Unified CCE の展開を使用するこのモデルを示しています。
図2-6 複数のサイトに対して分散型コール処理と Unified CVP を備えた分散型音声ゲートウェイを展開した場合
前述のモデル同様、数多くのオプションが使用可能です。 Unified ICM サーバ、Cisco Unified CallManager サーバ、Unified CVP サーバの台数と型番が変更可能です。 さらにこの展開モデルでは、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN トランク、冗長性なども変更可能な要素です。 セルフサービス、フリー ダイヤル コール、小規模サイトのサポートなどのために、集中処理とゲートウェイを追加できます。そのほか、プレルーティング PSTN ネットワーク インターフェイス コントローラ（NIC）も選択可能です。
• Unified CVP サーバの設置場所は、中央でもリモートでもかまいません。 Unified CVP サーバの位置に関係なく、コール処理とキューイングは分散され、ローカルのゲートウェイで実行されます。 図2-6 では Unified CVP を中央に配置しています。
• 各独立サイトは、Cisco Unified CallManager クラスタごとに最大 2,000 人のエージェントを同時に置ける規模まで拡張できます。また、システム全体で最大 6,000 人のエージェントを同時に置ける単一コンタクト センターを企業全体で形成するために Unified ICM セントラル コントローラで組み合わせ可能なサイトの数に、ソフトウェア上の制限はありません。
• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。 サイト間で音声コールを転送するには QoS WAN が必要です。 しかし、Takeback N Transfer のような PSTN 転送サービスを利用すればそれも必要ありません。 それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。
• Unified ICM プレルーティングを使用してコールをロード バランシングし、最適のサイトへルーティングすることによって、VoIP トラフィックによる WAN の使用率を下げることができます。
• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。
• Unified ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。
• Unified ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。
• Unified ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。
• Cisco Unified CallManager PG と Cisco Unified CallManager クラスタを同じ場所におく必要があります。 また、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/partner/WWChannels/technologies/resources/Unified CC_resources.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 つ減少します）。
転送
サイト内の転送は、単一サイトでの転送と同様に機能します。 Cisco Unified CallManager クラスタ間の転送では、VoIP WAN または PSTN サービスを利用します。
VoIP WAN を使用する場合は、クラスタ間トランクを十分に設定する必要があります。 サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、PSTN 転送サービスを利用することもできます。 このサービスを利用すると、Unified CC 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。 もう 1 つの方法として、サイト 1 の Cisco Unified CallManager クラスタから逆に PSTN にアウトバウンド コールを送信する方法があります。そのコールは PSTN からサイト 2 にルーティングされます。ただし、サイト 1 ではコールの残りを処理するために 2 つの音声ゲートウェイ ポートが使用されます。
Unified CC： Unified CC System PG
Unified CC System PG では、キューイング用に Unified CVP がサポートされず、Unified CC System PG の IVR PIM が使用されないままになるので、このモデルには Unified CC System PG は適していません。
Unified CC： Unified CCE PG
Unified CC： 分散型コール処理モデルでの分散型 Unified ICM オプション
図2-7 に、この展開モデルを示します。
図2-7 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 ミリ秒以下）にする必要があります。
• Unified ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）にする必要があります。
• プライベート リンクは、パブリックなトラフィックとパスを共用できません。 プライベート リンクは、パス ダイバーシティを必要とするので、Unified ICM のパブリックなトラフィックから完全に独立したパスを持つリンクに存在する必要があります。 このリンクは、システムの耐障害性設計の一部として使用されます。 詳細は、「アベイラビリティを高めるための設計上の注意点」を参照してください。
• 集中型モデルの冗長化については、次の「IPT： WAN 経由のクラスタリング」のセクションで扱います。
IPT： WAN 経由のクラスタリング
コール処理の中央集中化の一環として、Cisco Unified CallManager の分散型コール処理モデルによる冗長化を単一の Cisco Unified CallManager クラスタと組み合わせて、管理対象を 1 つのダイヤル プランと音声システムに簡素化する場合が多くなっています。 このようにモデルを組み合せれば、サブスクライバ サーバを複数のデータ センターに分散した単一の Cisco Unified CallManager クラスタを実現できます。複数の分散型コール処理サーバを備えた単一のクラスタで高いアベイラビリティと冗長性を実現するこの設計方法は WAN 経由のクラスタリングと呼ばれています。
Cisco Unified CallManager の WAN 経由のクラスタリングをコンタクト センター用の Unified CCE とともに使用すれば、データ センター（中央サイト）に障害が発生した場合でもエージェントを完全に冗長化できます。 Unified CC に対する WAN 経由のクラスタリングの実装には、他のモデルの場合とは異なる厳格な要件がいくつかあります。 Unified ICM のパブリック トラフィックとプライベート トラフィック、Cisco Unified CallManager のイントラクラスタ コミュニケーション（ICC）、および他の音声関連のメディアとシグナリングすべてを処理できるように、QoS を有効にして中央サイト間の帯域幅を適切にプロビジョニングする必要があります。 独立した Unified ICM（PG およびセントラル コントローラ）のプライベート リンクを使用して、中央サイト間の WAN にハイアベイラビリティ（HA; 高可用性）を確保するようにします。
• 中央サイト全体の停止につながるようなシングル ポイント障害が発生しません。
• サイトやリンクが停止した場合でも、業務を維持するために Cisco Unified Mobile Agent（Unified MA）で再設定が必要になることはありません。 サイトやリンクが停止すると、エージェントとそのデバイスは自動的に冗長サイトに接続されます。
• Unified ICM と Cisco Unified CallManager の両方に対するセンター集中管理が可能です。
• 中央サイト間に設置するハイアベイラビリティ（HA）WAN は、シングル ポイント障害がなく、完全冗長であることが必要です。（サイト間の冗長性オプションの詳細は、
http://cisco.com/go/srnd で入手できる、WAN インフラストラクチャと QoS の設計ガイドを参照してください。） ハイアベイラビリティ WAN で部分的な障害が発生した場合に備え、冗長リンクには、すべての QoS パラメータを満足させた状態で、中央サイトが受け持つすべての負荷を処理できる能力が必要です。 詳細は、「WAN 経由の Unified CC クラスタリングに対する帯域幅の要件」を参照してください。
• ポイントツーポイント テクノロジーを採用したハイアベイラビリティ（HA）WAN は、2 つの独立したキャリアにわたる実装に最適です。ただし、リング テクノロジーを採用する場合、これは必ずしも必要ではありません。
• ハイアベイラビリティ（HA）WAN で発生する遅延に対する要件は、WAN 経由のクラスタリングに対する現在のシスコ ユニファイド コミュニケーションの要件を満たす必要があります。 現在許容されている遅延は、片道 20 ミリ秒以下（往復で 40 ミリ秒以下）です。 この遅延は、理想的な条件下での送信距離で約 3000 km に相当します。 この送信距離は、遅延の原因となる別のネットワーク条件が発生することで短くなります。 仕様の詳細は、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。
• シスコ ユニファイド コミュニケーションの要件に適合することで、Unified CC の遅延に対する要件が満たされます。 ただし、Cisco Unified CallManager のイントラクラスタ コミュニケーションで必要な帯域幅は、Unified CC の場合とシスコ ユニファイド コミュニケーションの場合では異なります。 詳細は、「WAN 経由の Unified CC クラスタリングに対する帯域幅の要件」を参照してください。
• ハイアベイラビリティ（HA）WAN での帯域幅要件には、以下に示す通信に対する帯域幅と QoS のプロビジョニングが含まれます（「WAN 経由の Unified CC クラスタリングに対する帯域幅の要件」を参照）。
–Cisco Unified CallManager のイントラクラスタ コミュニケーション（ICC）
–Unified ICM セントラル コントローラと PG 間の通信
–CTI オブジェクト サーバ（CTI OS）を使用している場合は、CTI OS と CTI サーバ間の通信
• パス ダイバーシティを実現するには、Unified ICM セントラル コントローラのサイド A とサイド B の間、および PG のサイド A とサイド B の間に、Unified ICM プライベート通信専用の独立したリンクが必要です。 Unified ICM のアーキテクチャ上、パス ダイバーシティが必要になります。 パス ダイバーシティがないと、パブリック通信とプライベート通信が重複する障害が発生する可能性があります。 一時的にではあっても障害の重複が発生すると、Unified ICM が不安定となり、データが失われることがあります。Logger データベースが破損する場合もあります。
• 専用プライベート リンクは、2 つの独立した専用リンク（セントラル コントローラのプライベート通信用と Cisco Unified CallManager PG のプライベート通信用）で構成できます。また、セントラル コントローラと PG のプライベート通信を 1 つのリンクにまとめて、専用プライベート リンクとすることも可能です。 詳細は、「サイト間 Unified ICM プライベート通信のオプション」を参照してください。
• エージェントのサイトから各中央サイトの間には、独立したパスが存在している必要があります。 どちらのパスにも、一方のパスに障害が発生した場合に備え、シグナリング、メディアなどのすべてのトラフィックの全負荷を処理できる能力が必要です。 これらのパスは、複数の相手先固定接続（PVC）を使用したフレーム リレーなどの WAN テクノロジーによって、エージェント サイト側と同一の物理リンク上に置くことができます。
• 処理とキューイングのプラットフォームとして Unified IP IVR を使用するクラスタの最小サイズは、5 ノードです（パブリッシャが 1 ノード、サブスクライバが 4 ノード）。 各サイトの Unified IP IVR が、WAN を経由せずにローカルでクラスタへの冗長接続を実現するためには、この最小サイズが必要です。 このモデルでは、Cisco Unified CallManager と Unified IP IVR 間の WAN を経由した JTAPI 接続はサポートされていません。 ローカル ゲートウェイでも、Cisco Unified CallManager へのローカル冗長接続が必要です。
• 処理とキューイングのプラットフォームとして Unified CVP を使用するクラスタの最小サイズは、3 ノードです（パブリッシャが 1 ノード、サブスクライバが 2 ノード）。 ただし、特に、ローカルへのフェールオーバー機能を必要とする中央サイト、中央集中ゲートウェイ、または中央集中メディア リソースにローカル接続された Unified IP Phone（コンタクト センターのものであるかどうかに関係なく）が存在する場合は、最小ノード数を 5 とすることをお勧めします。
Unified IP IVR を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ
このモデルでは、音声ゲートウェイが中央サイトに配置されています。 それぞれのサイトに Unified IP IVR が集中配置され、コールの処理とキューイングに使用されます。図2-8 は、このモデルを示しています。
図2-8 Unified IP IVR を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ
• コールはローカルで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。
• 音声、制御、CTI に合わせ、エージェント サイトへの WAN 接続の帯域幅をプロビジョニングする必要があります。 詳細は、「WAN 経由の Unified CC クラスタリングに対する帯域幅の要件」を参照してください。
• リモート サイトでは、ローカルでのコール発信と緊急連絡（119、110）利用のためにローカルの音声ゲートウェイが必要になることがあります。詳細は、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。
• ロード バランシングされた展開の場合、中央サイトが停止すると着信ゲートウェイの機能の半分が失われることになります。 一方のサイトに障害が発生した場合に備え、ゲートウェイと IVR は単独のサイトですべての負荷を処理できる規模にしておくことが必要です。
• サイトやゲートウェイの機能が失われた場合は、キャリアのコール ルーティングにより、コールが代替のサイトにルーティングされる必要があります。 プレルーティングはロード バランシングに有効ですが、障害が発生している中央サイトにもコールがルーティングされる可能性があります。 したがって、プレルーティングはお勧めできません。
Unified CVP を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ
このモデルでは、中央サイトに配置されている VoiceXML ゲートウェイが音声ゲートウェイです。 Unified CVP が集中配置され、コールの処理とキューイングに使用されます。図2-9 にこのモデルを示します。
図2-9 Unified CVP を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ
• コールはローカルで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。
• プライマリ ルート ポイントは Unified CVP なので、Cisco Unified CallManager にかかる負荷が軽減されます。 これにより、Unified IP IVR による実装に比べてクラスタ当たりのスケーラビリティを高めることができます。 詳細は、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
• 音声、制御、CTI に合わせ、エージェント サイトへの WAN 接続の帯域幅をプロビジョニングする必要があります。 詳細は、「WAN 経由の Unified CC クラスタリングに対する帯域幅の要件」を参照してください。
• リモート サイトでは、ローカル コールの発信と緊急連絡（119、110）利用のために、ローカルの音声ゲートウェイが必要になることがあります。
分散型音声ゲートウェイにおける分散型のコール処理とキューイングを Unified CVP で行う場合
このモデルの音声ゲートウェイは、エージェントの場所に分散配置された VoiceXML ゲートウェイです。 リモート ゲートウェイに Unified CVP が集中配置され、コールの処理とキューイングに使用されます。図2-10 にこのモデルを示します。
図2-10 分散型音声ゲートウェイにおける分散型のコール処理とキューイングを Unified CVP で行う場合
• 着信コールと着信ゲートウェイが、そのローカル エージェントを重点的にサポートするようにプロビジョニングされていれば、WAN リンク上の音声 RTP トラフィックはゼロあるいは最小限になります。 他のサイトへの転送と会議は、WAN 上を流れます。
• コールはエージェント サイトで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。
• 市内電話の着信と発信は、緊急連絡（119、110）も含め、ローカル VoiceXML ゲートウェイを共有できます。
• プライマリ ルート ポイントは Unified CVP なので、Cisco Unified CallManager にかかる負荷が軽減されます。 これにより、Unified IP IVR による実装に比べてクラスタ当たりのスケーラビリティを高めることができます。 詳細は、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
• 分散型ゲートウェイでは、集中型ゲートウェイの場合に加え、最小限のメンテナンスと管理を追加で実行する必要があります。
• Unified CVP のメディア サーバは、中央に配置してもエージェント サイトに配置しても、どちらでもかまいません。 ゲートウェイのフラッシュからメディアを実行することもできます。 メディア サーバをエージェント サイトに配置することで、帯域幅の要件を軽減できますが、非集中型モデルに対する要件は増加します。
サイト間 Unified ICM プライベート通信のオプション
Unified ICM プライベート通信は、Unified ICM コンポーネント間のパブリック通信から分離されたパスを流れる必要があります。 このパス分離のために、デュアル リンクとシングル リンクという 2 種類のオプションがあります。
デュアル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Cisco Unified CallManager PG のプライベート トラフィック
図2-11 に示すデュアル リンクでは、Unified ICM セントラル コントローラのプライベート トラフィックが、VRU/CM PG のプライベート トラフィックから分離されています。
図2-11 デュアル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Cisco Unified CallManager PG のプライベート トラフィック
• 1 つのリンクに障害が発生しても、Unified ICM セントラル コントローラと PG の両方がシンプレックス モードになることはありません。これにより、システムが停止する可能性が二重故障の水準程度にまで低くなります。
• QoS の設定がリンクごとに 2 種類に制限されるので、リンクの設定とメンテナンスが簡素化されます。
• 展開モデルとコール フローのサイズ再設定や変更があっても、その影響が及ぶのは 1 つのリンクだけです。これにより、正常な機能を確保するために必要な QoS とサイズの変更が少なくなります。
• コール フローや設定に対して予期しない変更（誤設定など）が発生しても、独立したプライベート リンクで問題が発生する可能性が低くなっています。
• リンクは、独立した専用回線を利用する必要があります。 ただし、これらのリンクに冗長性は不要です。また、お互いに一方のリンクに対してフェールオーバーの関係にならないようにします。
• コールの負荷、コール フロー、展開の設定を大幅に変更する場合は、事前にリンクのサイズと設定の妥当性を確認しておく必要があります。
• リンクは専用回線であることが必要です。ハイアベイラビリティ（HA）WAN に設定したトンネル回線は使用しないでください。 パス ダイバーシティの詳細は、「IPT： WAN 経由のクラスタリング」の冒頭にある「ベスト プラクティス」を参照してください。
シングル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Cisco Unified CallManager PG のプライベート トラフィック
図2-12 に示すシングル リンクでは、Unified ICM セントラル コントローラのプライベート トラフィックと VRU/CM PG のプライベート トラフィックの両方が流れます。 デュアル リンク実装に比べると、シングル リンク実装は普及しており、低い費用で実現できます。
図2-12 シングル リンクを経由する Unified ICM セントラル コントローラのプライベート トラフィックと Cisco Unified CallManager PG のプライベート トラフィック
• メンテナンスするリンク数が少なくて済みます。ただし、複雑さは増加します。
• リンクを冗長化する必要はありません。 冗長リンクを使用する場合は、フェールオーバー時の遅延を 500 ミリ秒以下に抑える必要があります。
• セントラル コントローラおよび PG で発生する高優先順位通信に対しては、QoS 分類と予約された帯域幅が別途必要になります。 詳細は、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください。
• コールの負荷、コール フロー、展開の設定を大幅に変更する場合は、事前にリンクのサイズと設定の妥当性を確認しておく必要があります。 これは、シングル リンク モデルでは特に重要です。
• リンクは、ハイアベイラビリティ（HA）WAN から完全に分離された専用回線であることが必要です。ハイアベイラビリティ（HA）WAN に設定したトンネル回線は使用しないでください。 パス ダイバーシティの詳細は、「IPT： WAN 経由のクラスタリング」の冒頭にある「ベスト プラクティス」を参照してください。
Unified CC System PG を使用した WAN 経由のクラスタリング
Unified CC System PG を使用した WAN 経由のクラスタリングは、Unified IP IVR を使用した WAN 経由のクラスタリングに似ていますが、さらにいくつかの課題があります。 Unified IP IVR ごとに別のペリフェラルを使用する代わりに、1 つの Unified CC システム ペリフェラルがすべての Unified IP IVR と Cisco Unified CallManager を制御します。
Unified IP IVR 間のコールのロード バランシングでは、どちらのサイトからコールが来たかは考慮されません。単に負荷の最も低い Unified IP IVR にコールが配分されるだけです。 つまり、サイト A に到着したコールがサイト B の Unified IP IVR で処理される場合もあります。さらに、A サイドと B サイド両方の Unified CC System PG ではすべての Unified IP IVR が認識されています。 標準 PIM アクティベーション ロジックによって、A サイドか B サイドのどちらの PIM が各 Unified IP IVR に接続されるかが決定されます。 つまり、サイト A の PG がサイト B の Unified IP IVR に接続される場合もあります。
この動作は WAN 経由のクラスタリング環境に展開された System Unified CC にも当てはまります。
Unified CC System PG や System Unified CC の展開モデルには、WAN 経由のクラスタリングの使用はお勧めしません。 お勧めできるのは従来型の Unified CCE モデルだけです。ただし、従来のモデルでは最大同時エージェント数が 6,000 に制限されています。エージェントを 6,000 人以上に拡張するには、親/子モデルを使用することをお勧めします。
WAN 経由の Unified CC クラスタリングの障害分析
このセクションでは、Unified CC で実行している WAN 経由のクラスタリングで特定の障害が発生したときの動作について説明します。 この展開モデルでは、ハイアベイラビリティ（HA）WAN の安定性がきわめて重要です。ハイアベイラビリティ WAN で発生する障害は、通常発生する障害と同列には扱えないと考えられています。
このセクションで扱う展開モデルの概要については、「IPT： WAN 経由のクラスタリング」で示した図を参照してください。
中央サイト全体の喪失
中央サイト全体の喪失とは、サイトの電源が切断された場合のように中央サイトとの通信がすべて失われた状態をいいます。 この障害の主な原因として考えられるのは、自然災害、電源の問題、重要な接続に発生した問題、人為的なミスなどです。 中央サイトとの接続が部分的に失われている場合は、サイトの喪失ではなく、接続の部分的な喪失です。このシナリオについては、この次のセクションで扱います。
WAN 経由の Unified CC クラスタリングが中央サイト全体で完全に失われると、Unified MA は冗長サイトに適切にフェールオーバーされます。 フェールオーバーに要する時間は、エージェントから見て 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 のプライベート接続が失われます。 その結果、両方のコンポーネントの動作は、前述のシンプレックス モードに切り替わります。 この状況が原因でコールの損失や障害が発生することはありません。
Unified MA サイトから中央サイトへの接続
いずれかの中央サイトへの接続が Unified MA サイトから失われると、すべての電話とエージェント デスクトップはただちに別の中央サイトに接続され、コールの処理が再開されます。 通常、フェールオーバーには 1 ～ 60 秒の時間がかかります。
ハイアベイラビリティ WAN の障害
名前の定義上は、通常の状況でハイアベイラビリティ（HA）WAN に障害は発生しません。 本来のとおりに HA WAN がデュアル パス構成を持ち、完全冗長であれば、このタイプの障害の発生はきわめてまれです。 このセクションでは、このようにきわめてまれなシナリオで発生する現象について説明します。
その原因に関係なく、HA WAN が失われると、Cisco Unified CallManager クラスタは分割されます。 この障害によって重点的に発生する問題は、エージェントの電話の半分と Unified ICM との接続が失われるということです。 Unified ICM から通信できるのはクラスタの半分だけとなり、残りの半分に登録されている電話とは通信できないか、場合によっては認識もできなくなります。 その結果、Unified ICM から認識できなくなっている電話を使用しているすべてのエージェントは、ただちにログアウトされます。 これらのエージェントは、ハイアベイラビリティ WAN が復元されるか、使用している電話の接続先クラスタ サイドを切り替えない限り、ログインして復帰することはできません。
ブロードバンド経由の Unified MA
Unified CCE を採用している企業では、そのネットワークで、Cisco Unified IP Phone を使用しているリモート在宅エージェントをサポートすることが必要になる場合があります。 このセクションでは、デスクトップ ブロードバンドによる Asymmetric Digital Subscriber Line（ADSL; 非対称デジタル加入者線）またはケーブル接続をリモート ネットワークとして使用して展開できる Unified MA ソリューションについて説明します。
Cisco Voice and Video Enabled IPSec VPN（V3PN）の ADSL 接続またはケーブル接続では、Cisco 830 シリーズのルータをブロードバンド ネットワークのエッジ ルータとして使用します。 Cisco 830 シリーズのルータは、V3PN、暗号化、Network Address Translation（NAT）、ファイアウォール、Cisco IOS Intrusion Detection System（IDS; 侵入検知システム）、および QoS を、Unified CC キャンパスとのブロードバンド ネットワーク リンク上で Unified MA に提供します。 キャンパスでの Unified MA の V3PN 集約は、LAN 間 VPN ルータを介して提供されます。
• コンタクト センター企業では、Unified MA の展開により経費節減を図ることができ、その結果、Return On Investment（ROI; 投資回収率）が向上します。
• Unified MA は、標準的な Unified CC のエージェント デスクトップ アプリケーションを使用して展開できます。このアプリケーションとしては、Cisco CTI OS、Cisco Agent Desktop、Customer Relationship Management（CRM; 顧客関係管理）デスクトップなどがあります。
• このモデルは、ADSL またはケーブルのブロードバンド ネットワークで機能します。
• エージェントのデスクトップをブロードバンドで常時接続することにより、ホーム オフィスで企業 LAN を使用するための安全な拡張機能が得られます。
• 在宅エージェントはそのホーム オフィスで、Unified CCE 企業のコンタクト センターで作業する場合に使用しているものと同じ Unified CC アプリケーションにアクセスでき、Unified CC 機能のほとんどを利用できます。これらの機能には、コンタクト センターでの作業とまったく同じ方法でアクセスできます。
• このモデルは、IP Phone を使用して高品質な音声を実現し、既存のブロードバンド サービスを通じて音声と同時にエージェントのデスクトップにデータを提供します。
• Unified CC 企業ユーザには VPN トンネルへのアクセスを提供して、認証機能を実現します。これにより、Unified CC 在宅エージェントとその家族は、ブロードバンドによるケーブル接続や DSL 接続を安全に共有できます。
• 在宅エージェント ソリューションでは、低価格な Cisco 831 シリーズ ルータを使用します。
• このモデルは、Dynamic Host Configuration Protocol（DHCP; ダイナミック ホスト コンフィギュレーション プロトコル）または Point-to-Point Protocol over Ethernet（PPPoE）を介して、動的な IP アドレス割り当てをサポートしています。
• Cisco 831 シリーズのルータを使用することで、VPN トンネル機能、エッジでの Quality of Service（QoS）、およびファイアウォールなどのセキュリティ機能が得られるので、管理するデバイス数を削減できます。
• 企業側では、Cisco Unified Operations Manager のような高いスケーラビリティと柔軟性を備えた管理製品を使用することで、Unified MA のルータを集中管理できます。
• この Unified MA ソリューションは、復元力、高いアベイラビリティ、および高いスケーラビリティのためのビルディングブロック手法のサイドで、Cisco IOS VPN ルータを基本にしています。このルータは、数千人もの在宅エージェントをサポートできます。
• データや音声を初めとするすべてのトラフィックは、Triple Data Encryption Standard（3DES）を使用して暗号化されます。
• このモデルは、既存の Cisco Unified CallManager インストール環境の中で展開できます。
• 在宅エージェントでも、キャンパス エージェントと同じタイプの拡張機能を利用できます。
• 次の URL にあるドキュメンテーションに示されている、V3PN および Business Ready Teleworker の設計ガイドラインに従います。
http://www.cisco.com/go/teleworker
• 最小限の帯域幅限度を設定した G.729 を使用するように Unified MA の IP Phone を設定します。 G.711 コーデックを使用すれば、より高い音声品質を得ることができます。 G.711 をサポートするために必要な最小帯域幅は、アップロード側で 512 kbps です。
• NetFlow、サービス保証エージェント（SAA）、Internetwork Performance Monitor（IPM）など、障害マネジメント ツールとパフォーマンス マネジメント ツールを実装します。
• ワイヤレス アクセス ポイントがサポートされていますが、Unified MA による利用の可否は、企業のセキュリティ ポリシーによって判断します。
• 1 世帯あたりでサポートされる Unified MA は 1 人だけです。
• DSP ハードウェア デバイスに会議ブリッジを設定することをお勧めします。 DSP 会議ブリッジを使用すれば、会議の音声品質が損なわれることはありません。 シスコ ユニファイド コミュニケーションだけの展開であっても、これは推奨される解決策です。
• ブロードバンド ソリューションを介した Unified MA は、中央集中型の Unified CC および Cisco Unified CallManager クラスタだけでサポートされています。
• ADSL リンクやケーブル リンクでは障害が発生することがあります。 バック アップ リンクがある場合は、ADSL モデムまたはケーブル モデム、Cisco 831 シリーズ ルータ、および IP Phone をリセットすることが必要な場合があります。 Unified MA がこの作業を実行するには、トレーニングが必要です。
• ユニキャストの Music on Hold（MoH）ストリームだけがサポートされています。
• Unified MA のデスクトップ用に Domain Name System（DNS; ドメイン ネーム システム）のエントリを作成する必要があります。このエントリがないと、リモート エージェントは CTI サーバに接続できません。 DNS のエントリは動的に更新できます。または、静的更新の際に入力できます。
• Unified MA のワークステーションと IP Phone は、Dynamic Host Configuration Protocol（DHCP; ダイナミック ホスト コンフィギュレーション プロトコル）を使用するように設定する必要があります。
• Unified MA のコンピュータに使用するオペレーティング システムには Windows XP Pro が必要です。 さらに、XP リモート デスクトップ コントロールをインストールする必要があります。
• Cisco Unified IP Phone 7960 には電源が必要です。 Cisco 831 シリーズ ルータから、この Unified IP Phone に電源は供給されません。
• 在宅エージェントが使用するブロードバンドの帯域幅として、アップロード側では 256 kbps 以上、ダウンロード側では ADSL で 1.4 Mbps 以上、ケーブルで 1 Mbps 以上が必要です。 実際の展開では、帯域幅が適切であることを確認してください。 ケーブルで展開する場合は、回線が混雑する時間帯を考慮します。 リンク速度が上記で指定された帯域幅以下に低下すると、クリッピングなどの音声品質上の問題が在宅エージェントに発生します。
• Unified MA と Unified CC キャンパス間の往復遅延は、ADSL で 180 ミリ秒以下、ケーブルで 60 ミリ秒以下とする必要があります。 この遅延が長くなると、音声ジッタ、会議ブリッジの問題、エージェントのデスクトップへの画面表示遅れなどが発生することがあります。
• Music on Hold（MoH; 保留音楽）サーバに G.729 コーデックのストリーミングが設定されていない場合は、外部の発信者が MoH を受信できるようにトランスコーダを設定する必要があります。
• Cisco Supervisor Desktop の場合、在宅エージェントの IP Phone を対象としたサイレント モニタリング、介入、代行受信、および音声録音では、スーパーバイザに対する制限があります。 Cisco Agent Desktop（Enterprise および Express）の在宅およびキャンパスのスーパーバイザは、在宅エージェントを音声モニタできません。 スーパーバイザが送受信できるのはテキスト メッセージだけです。また、どの在宅エージェントがオンラインになっているかを確認でき、それらエージェントをログ アウトできます。
• Cisco Agent Desktop を使用した Unified CCX ではデスクトップ ベースのモニタリングはサポートされていません。 デスクトップ ベースのモニタリングは、Unified CCE でのみ適用できます。
• CTI OS Supervisor を使用する在宅とキャンパスのスーパーバイザは、在宅エージェントに対するサイレント モニタ、介入、および代行受信が可能ですが、音声録音はできません。 CTI OS を使用する在宅とキャンパスのスーパーバイザは、テキスト メッセージの送受信、エージェントの準備、および在宅エージェントのログアウトが可能です。
• エージェントのデスクトップは、IP Phone の背面にある RJ45 ポートに接続します。 この接続がないと、CTI OS Supervisor でエージェントの電話を音声モニタできません。
• Cisco Unified CC と互換性のある IP Phone だけがサポートされています。 互換性の詳細は、次のドキュメンテーションを参照してください。
–『 Cisco ICM/IPCC Enterprise and Hosted Editions ハードウェア及びシステムソフトウェア スペック (製品構成表-BOM) Release 7.0(0) 』が、次のリンクから入手できます。
http://www.cisco.com/univercd/cc/td/doc/product/icm/ccbubom/index.htm
–『 Cisco Unified Contact Center Enterprise Edition Software Compatibility Guide 』は、次のリンクから入手できます。
http://cisco.com/application/pdf/en/us/guest/products/ps1844/c1609/ccmigration_09186a008031a0a7.pdf
–Unified CCX のリリース ノート（Cisco Customer Response Applications）は、次のリンクから入手できます。
http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_4_0/english/relnotes/index.htm
• http://www.Broadbandreports.com には、ブロードバンドの回線速度のテスト方法が示されています。 この Web サイトでは、アップロードとダウンロードの両方について、在宅エージェントの回線速度をテスト サーバから測定できます。
Business Ready Teleworker Solution を介して展開された Unified IP Phone を使用する Unified MA
このモデルでは、Unified MA の IP Phone とワークステーションが、VPN トンネルを介してメインの Unified CC キャンパスに接続されています。 Unified MA にルーティングされた顧客からのコールは、キャンパス エージェントにルーティングされた場合と同じように扱われます（図2-13を参照してください）。
図2-13 Business Ready Teleworker Solution を介して展開された Unified IP Phone を使用する Unified MA
• 高速なブロードバンドにより、コスト効果の高いオフィス アプリケーションが実現します。
• 高度なセキュリティ機能により、企業 LAN をホーム オフィスまで拡張できます。
• CTI データ、高品質音声など、音声・データ統合デスクトップ アプリケーションを幅広くサポートしています。
• ケーブルでサポートされているブロードバンド接続速度は、アップロードで 256 kbps 以上、ダウンロードで 1.0 Mbps 以上です。
• ADSL では、アップロードで 256 kbps 以上、ダウンロードで 1.4 Mbps 以上のブロードバンド接続速度がサポートされています。
• エージェントのワークステーションは、動作クロックが 500 MHz 以上で、512 MB 以上の RAM を搭載している必要があります。
• IP Phone は、最低のブロードバンド接続速度でも G.711 を使用するように設定する必要があります。
• QoS は、Cisco 831 ルータのエッジだけで有効になります。 現在のところ、サービス プロバイダーは QoS を提供していません。
• Cisco 831 シリーズのルータで、セキュリティ機能を有効にします。
• Cisco 7200 VXR および Catalyst 6500 IPSec VPN Services Module（VPNSM）を使用することで、エージェントは優れた LAN 間パフォーマンスを得られます。
• Unified MA の自宅にある電話は、緊急連絡（119、110）へ接続可能である必要があります。
• Unified MA がログインしていて業務できる状態でも、電話に出られない場合は、Redirect-On-No-Answer（RONA）機能が使用されるようにします。
従来の ACD の統合
従来の ACD を Unified CC 展開に統合することが必要な企業には、次のような選択肢があります。 従来の ACD サイトと Unified CC サイトの間でコールをロード バランシングするには、プレルーティングのネットワーク インターフェイス コントローラ（NIC）を追加します （図2-14を参照してください）。 この場合、Unified ICM には PSTN サービス プロバイダーをサポートしている NIC が必要です。 このシナリオでは、PSTN から NIC 経由で Unified ICM セントラル コントローラに対し、最適なサイトを決定するための問い合せが行われます。Unified ICM から PSTN への返答により、PSTN からどのサイトにコールを送信するかが指定されます。 PSTN から Unified ICM に提供されたあらゆるコール データが、エージェントのデスクトップ（従来の ACD または Unified CC）に渡されます。
2 つのサイト（ACD サイトと Unified CC サイト）間でコールを転送するために、PSTN 転送サービスを利用できます。 PSTN 転送サービスを利用することにより、どちらのサイトでもコールのトランキングの重複がなくなります。 PSTN 転送サービスを利用する代わりに、従来の ACD と Unified CC 音声ゲートウェイの間に TDM 音声回線を展開する方法もあります。 この環境では、コール発信元のサイトにコールバックが転送されると、2 つのサイト間にトランキングの重複が発生します。 サイト間で追加の転送が行われるたびに、TDM 音声回線が追加で利用されます。
図2-14 従来の ACD の Unified CC サイトへの統合
コールを PSTN からプレルーティングする代わりに、PSTN から 1 つのサイトだけにコールを送信する方法や、PSTN でプロビジョニングされたいくつかの静的ルールに基づいて、2 つのサイト間でコールを分割する方法があります。 どちらかのサイトにコールが着信すると、そのコールを扱う最適なサイトを決定するために、従来の ACD または Cisco Unified CallManager から Unified ICM 宛てにルート要求が生成されます。 コールのルーティング元である他方のサイトにいるエージェントにそのコールを送信する必要がある場合は、サイト間に TDM 回線が必要になります。 コールをどこにルーティングするか、コールを転送するかどうか、およびコールをいつ転送するかは、企業のビジネス環境、目的、および原価構成で決定します。
さらに、Unified CVP をすべてのコールのフロントエンドとして選択して、TDM ACD と Unified CC エージェントの両方に対して最初のコール処理とキューイングを行うこともできます（図2-15を参照してください）。
図2-15 従来の ACD と Unified CC サイトへの Unified CVP の統合
この設計では、Unified CVP によって制御された音声ゲートウェイにすべてのコールがまず着信した後、すぐに Unified ICM によってコールが制御されます。 Unified ICM は TDM ACD と Unified CC PG に対する PG 接続を使用して、応答可能なエージェントをモニタします。 どちらかの環境のエージェントが応答可能になるまで、コールは Unified CVP でキューイングされます。 TDM ACD にコールを転送する必要があるときは、音声ゲートウェイでヘアピン処理されます。つまり、PSTN キャリア ネットワークからの T1 インターフェイスのゲートウェイにコールが入って別の物理 T1 インターフェイスから出ることによって、TDM ACD のトランクのように見せます。 ほとんどの TDM ACD では、音声ゲートウェイから IP でインバウンド コールを受けられないので、この物理的な T1 インターフェイスまたは接続が必要です。 Unified CC エージェントは、IP 音声ネットワークからコールを直接受信します。
この設計は、図2-16 に示すように親/子モデルを使用して展開することもできます。
図2-16 従来の ACD を Unified CC サイトと統合するための親/子モデル
このモデルには、System Unified CC に接続された PG が親の Unified ICM にあります。1 つのサイトでは、この System Unified CC が完全にインストールされており、別のサイトでは Unified ICM TDM ACD PG を使用する TDM ACD とともにインストールされています。 このモデルでは、企業全体の実質的なルーティング、コール処理、およびキューイングが引き続き Unified ICM で実現されており、サイトには分散型の Unified CVP 音声ゲートウェイが設置されています。 Unified ICM では、すべてのサイトでエージェントと進行中のコールも表示できます。 このモデルの違いは、System Unified CC でローカル サバイバビリティが実現されていることです。 親の Unified ICM への接続が失われた場合、コールは TDM ACD サイトで処理されるのと同様に引き続きローカルで処理されます。
いずれのモードでも、既存の TDM ACD から Unified CC に移行するため、または IP と TDM の両方を包含する単一の仮想コンタクト センターとして運用するためにこの展開形態を使用できます。
従来の IVR の統合
従来の IVR を Unified CC 展開に統合するには、いくつかの方法があります。 以降のセクションで説明する数多くの要因を考慮してどの方法が最適かを決定します。 重要な検討事項として、IVR からコールを転送するときに発生するトランキングの重複をどのように排除または低減するかという点があります。
PBX 転送の使用
多くのコール センターには、書き直されることが考慮されていない、従来からの既存 IVR アプリケーションが配置されています。 これらの IVR アプリケーションを温存した上で Unified CC 環境に統合するには、IVR に Unified ICM へのインターフェイスを備える必要があります （図2-17を参照してください）。
Unified ICM への IVR インターフェイスには 2 種類のバージョンがあります。 1 つは単なるポストルーティング インターフェイス（コール ルーティング インターフェイス（CRI））です。このインターフェイスでは、IVR から Unified ICM にコール データ付きでポストルート要求を送信できます。 Unified ICM から IVR に、コールの転送を指示するルート応答が送信されます。 このシナリオでは、従来の IVR は PBX 転送を呼び出し、そのポートをリリースしてコールを Unified CC に転送します。 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 処理でコールを再キューイングできるようになります。
この設計では、標準 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-18を参照してください）。 この場合も、従来の IVR ポートを余分に使用する必要がないように、また IVR でトランキングの重複が発生しないように、すべてのキューイングで Unified IP IVR が使用されます。 従来の IVR アプリケーションで収集されたあらゆるコール データは、Unified ICM によってエージェントのデスクトップまたは Unified IP IVR に渡されます。
図2-18 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-19を参照してください）。 前のセクションのモデルと異なり、従来の IVR に Service Control Interface（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-19 IVR でのトランキングの重複を使用した従来の IVR の統合
このモデルでは、インバウンド コール用に PSTN が直接接続されている IVR プラットフォームのファームとして TDM IVR がセットアップされています。 この IVR では、システム内のすべてのコールを追跡する Unified ICM に PG が接続されています。 発信者が IVR アプリケーションから出ることを選択すると、IVR は Unified ICM にポストルーティング要求を送信します。Unified ICM は、コールをエージェントに振り向けるか、Service Control Interface（SCI; サービス制御インターフェイス）を使用して TDM IVR にコールをローカルにキューイングためのラベルを返します。 音声ゲートウェイに、さらに Unified CC エージェントにコールをヘアピン処理する別のポートを TDM IVR が選択することによって、エージェントへの転送が行われます。 コールがエージェントに接続されている間は、この処理によって 2 ポートが占有されます。
Cisco Unified CallManager による転送と IVR でのトランキングの重複の使用
運用していく中で、従来の IVR アプリケーションから Unified CVP または Unified IP IVR への移行が必要になることがあります。 ただし、きわめて限定されたシナリオで従来の IVR アプリケーションを使用する必要性がわずかに残っている場合は、その IVR を追加の音声ゲートウェイに接続します（図2-20を参照してください）。 PSTN から音声ゲートウェイに着信したコールは、Cisco Unified CallManager によってルーティングされます。 Cisco Unified CallManager では、特定の DN を従来の IVR にルーティングできるほか、コールを従来の IVR に転送するタイミングを Unified ICM、Unified CVP または Unified IP IVR で決定することもできます。 従来の IVR にあるコールを Unified CC エージェントに転送することが必要な場合、そのコールの接続中は、別の IVR ポート、トランク、および音声ゲートウェイ ポートが使用されます。 複数のループが発生しない転送シナリオとなるように注意する必要があります。複数のループが発生すると、音声の品質が低下することがあります。
図2-20 Cisco Unified CallManager による転送と IVR でのトランキングの重複を使用した従来の IVR の統合
このモデルでは、音声ゲートウェイを使用する Unified CVP か Unified CC を使用する Unified IP IVR や Cisco Unified CallManager のどちらかを 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 CC エージェントに転送するか、音声ゲートウェイ内のローカル キューに保持します。
Cisco Unified CallManager を使用する場合は、音声ゲートウェイに着信するコールが Cisco Unified CallManager のための CTI ルート ポイントに到達すると、ルーティング要求が Unified ICM に送信され、発信者に適切なコール処理デバイスが判別されます。 CTI ルート ポイントに TDM IVR にあるアプリケーションが示されている場合は、コールを TDM IVR に転送するように Cisco Unified CallManager に Unified ICM が指示します。この転送は、音声ゲートウェイ上の別 T1 ポートを使用して、コールをヘアピン処理して TDM IVR に接続することによって行われます。 また、コールを Unified IP IVR にトランスレーション ルーティングしてコール処理あるいはプロンプトの再生を行い、次に TDM IVR に転送してさらに処理するように、Cisco Unified CallManager に Unified ICM が指示することもあります。 発信者が TDM IVR を出ることを選択すると、TDM IVR はポストルート要求を Unified ICM に送信し、Unified ICM はラベルを TDM IVR に返します。 このラベルは、IVR の別の T1 ポートを使用してコールを転送してコールバックを音声ゲートウェイに渡し、さらに Cisco Unified CallManager のダイヤル プランにある Unified CC エージェントに渡すように TDM IVR に指示します。
Cisco Unified CallManager に制御されるモデルでは、音声ゲートウェイで最初にコールが受信され、別の T1 ポートで TDM IVR にヘアピン処理されます。 IVR が Unified CC エージェントにコール バックを送信するときには、IVR は TDM IVR の別のポートと音声ゲートウェイの別のポートを使用します。 エージェントが発信者と話している間は、これら 3 つのポートすべてが音声ゲートウェイ上で占有されます。また、このコールが存在する間は、TDM IVR の両方のポートが占有されます。
フィードバック