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

CTI Manager を冗長化するための Unified ICM ペリフェラル ゲートウェイの設定

二重 Unified ICM ペリフェラル ゲートウェイ モデルで Unified CM が CTI Manager のフェールオーバーをサポートするようにするには、次の手順を実行します。

ステップ 1 Unified CM の冗長性グループを作成し、このグループにサブスクライバを追加します（コール処理、デバイス登録、または CTI Manager の使用には、パブリッシャおよび TFTP サーバを使用しないでください）。

ステップ 2 二重 ペリフェラル ゲートウェイ（PG）の各サイド（PG サイド A と PG サイド B）に使用する、2 つの CTI Manager を異なるサブスクライバ上で指定します。

ステップ 3 一方の CTI Manager を Unified CM PG のサイド A の JTAPI サービスに割り当てます（図 3-7 を参照）。左側のセットアップ パネルがペリフェラル ゲートウェイのサイド A であることに注意してください。この CTI Manager は、CCM1 サブスクライバを参照し、Unified CM クラスタで PGUser CTI が有効なユーザ アカウントを使用します。

ステップ 4 もう一方の CTI Manager を、Unified CM PG のサイド B の JTAPI サービスに割り当てます（図 3-7 を参照）。右側のセットアップ パネルがペリフェラル ゲートウェイのサイド B であることに注意してください。この CTI Manager は、CCM2 サブスクライバを参照し、Unified CM クラスタで同じ PGUser CTI が有効なユーザ アカウントを使用します。PG ペアのどちらのサイドからも同じデバイスを監視するには、二重化した PG ペアの両方のサイドで同じ JTAPI ユーザを使用する必要があります。

図 3-7 PG のサイド A およびサイド B への CTI Manager の割り当て

Unified CM を使用した Unified IP IVR のハイ アベイラビリティ

Unified IP IVR ポートのハイ アベイラビリティは、Unified CM に含まれる次のいずれかの自動転送機能を使用して実装できます。

• Forward Busy：ポートがビジーであることが Unified CM に検出されると、コールが別のポートまたはルート ポイントに転送されます。この機能を使用すると、Unified IP IVR アプリケーションの問題（利用可能な CTI ポートがないなど）により Unified IP IVR CTI ポートがビジーのときに、コールを別のリソースに転送できます。

• Forward No Answer：Unified CM で設定されたタイムアウト期間内に、コールがポートに到達しなかったことが Unified CM に検出されると、コールが別のポートまたはルート ポイントに転送されます。この機能を使用すると、Unified IP IVR アプリケーションの問題により Unified IP IVR CTI ポートが応答しないときに、コールを別のリソースに転送できます。

• Forward on Failure：アプリケーション エラーによるポート障害が Unified CM に検出されると、コールが別のポートまたはルート ポイントに転送されます。この機能を使用すると、Unified CM アプリケーションのエラーにより Unified IP IVR CTI ポートがビジーのときに、コールを別のリソースに転送できます。

（注） 自動転送機能を使用して Unified IP IVR ポートのハイ アベイラビリティを実装するときは、すべての Unified IP IVR サーバが利用不可能になったときにループが発生しないようにしてください。基本的に、自動転送を開始した最初の CTI ポートに戻るパスを確立しないでください。

Unified ICM コール フロー ルーティング スクリプトを使用した Unified IP IVR のハイ アベイラビリティ

Unified ICM のコール フロー ルーティング スクリプトを使用して、Unified IP IVR のハイ アベイラビリティを実装できます。Unified IP IVR にコールを送る前に Unified ICM スクリプトを使用して Unified IP IVR ペリフェラル ステータスをチェックすることにより、コールが非アクティブ Unified IP IVR にキューイングされるのを防止できます。たとえば、Unified IP IVR がアクティブかどうかをチェックする Unified ICM スクリプトをプログラムできます。これには、[IF] ノードを使用するか、（[consider if] フィールドを使用して）[VRU]（Voice Response Unit（VRU; 音声応答装置））ノードへのトランスレーション ルートを構成して、アイドル ポートが最も多い Unified IP IVR を選択し、コールがコールベースで均等に分散されるようにします。この方式は、複数の Unified IP IVR 間でポートのロード バランスが調整されるように修正でき、同じ [Translation Route To VRU] ノードまたは [Send to VRU] ノードのクラスタ上のすべての Unified IP IVR に対応できます。

Unified System CCE では、ルーティング スクリプトでコールのキューイングまたは発信者に対するメッセージの再生が要求されると、System PG は VRU トランスレーション ルート機能を自動的に実行します。System PG は、Unified System CCE 内に設定された使用可能なすべての IP IVR にコールをロード バランシングします。

（注） Unified IP IVR サーバ自体に障害が発生した場合は、Unified IP IVR 上のコールがすべてドロップされます。このような障害の影響を最小化するために、コールを複数の Unified IP IVR サーバに分散することが重要です。Unified IP IVR リリース 4.0（x）には、Unified IP IVR が IVR ペリフェラル ゲートウェイへのリンクを失った場合の処理に使用されるデフォルト スクリプトが用意されているため、コールが失われることはありません。

Cisco Interaction Manager のアーキテクチャの概要

図 3-14 に示すように、Cisco Interaction Manager には複数の主要コンポーネントがあります。

図 3-14 Cisco Interaction Manager のアーキテクチャ

アーキテクチャはマルチティア モデルで定義されており、以下に示す設計の各レベルにさまざまなコンポーネントが配置されています。

外部クライアント

Cisco Interaction Manager はすべて Web ベースの製品であり、エージェントとエンドカスタマーはそれぞれのデスクトップから Web ブラウザを使用してアクセスできます。

エージェントは Microsoft Internet Explorer 6.0 または組み込みの CAD ブラウザを使用してアプリケーションにアクセスでき、カスタマーは特定のバージョンの Microsoft IE、Mozilla、Firefox、または Netscape を使用してチャット カスタマー コンソールにアクセスできます。Cisco Interaction Manager は、Citrix ターミナル サービス環境で実行するエージェント デスクトップではサポートされません。

ティア 0：ファイアウォールおよびロード バランサ

エージェントとカスタマーは、アプリケーションがそのように設定されている場合は、それぞれのブラウザからファイアウォールを通してアプリケーションに接続します。

分散インストールされたアプリケーションの場合はロード バランサを使用することもでき、エージェントとカスタマーからの要求は最も負荷の小さい Web サーバにルーティングされます。

ティア 1：Web サーバ

Web サーバは、静的コンテンツをブラウザに提供するために使用されます。Cisco Interaction Manager は使用されている Web サーバの種類には依存しないように設計されており、唯一の要件は、アプリケーション サーバのベンダーが対応するアプリケーション サーバ用の Web サーバ プラグインを提供する必要があることです。

ティア 2：アプリケーションおよびファイル サーバ

アプリケーション サーバは、Web コンテナ（JSP/Servlet エンジンとも呼ばれます）および EJB コンテナとして使用されます。コア ビジネス ロジックはビジネス オブジェクト レイヤに存在し、ストアド プロシージャはデータベース サーバに存在します。JAVA クラスに存在するビジネス ロジックは、アプリケーション サーバに展開されます。JSP/Servlet はビジネス クライアント レイヤを通してビジネス オブジェクトと対話し、ビジネス オブジェクトはデータベースと対話して、データベース サーバに存在するデータに対して何らかのビジネス ロジックを実行します。

例：アウトバウンド タスクの作成

• ユーザはアプリケーションにログインしてアウトバウンド タスクを作成します。

• JSP レイヤはビジネス クライアント レイヤを呼び出し、ビジネス クライアント レイヤは JSP/Servlet が展開されている同じアプリケーション サーバに存在するビジネス オブジェクトと対話します。

• ビジネス オブジェクトは、データベース サーバに存在するクエリー/ストアド プロシージャを実行します。

• アクティビティが作成されて、データベース テーブルに保存されます。

• 電子メールおよび記事のすべての添付ファイル、レポート テンプレート、およびアプリケーションで使用されるすべてのロケール固有文字列を保存するには、ファイル サーバが使用されます。

ティア 3：サービス サーバ

Cisco Interaction Manager には、POP サーバからの電子メールの取得、SMTP サーバへの電子メールの送信、ワークフローの処理、エージェントへのチャットの割り当てなどの、特定のビジネス機能を実行するプロセスがあります。すべてのサービスはサービス サーバで実行され、Distributed Service Manager（DSM）によって管理されます。

Cisco Interaction Manager を使用すると、サービスの複数のインスタンスを簡単に作成し、さまざまなインスタンスに処理を分散させることができます。たとえば、電子メールの取得に使用するサービスの場合、複数のインスタンスを持つように設定し、異なる電子メール アドレスから電子メールを取得できます。この機能を使用すると、コンタクト センターで受信するカスタマーとの対話の量の増加に対応できます。

データ ティア：データベース サーバ

データ ティアには、SQL に準拠するデータベース、HTML/XML のデータソース、および最終的には SOAP メッセージの使用や生成を行う Web サービスが含まれます。ビジネス オブジェクトとデータ アダプタはこのレイヤを使用して、さまざまなサードパーティ アプリケーションとデータ ソースからデータを抽出します。また、このレイヤは、関連する J2EE 準拠パッケージを使用して HTML および XML の解析を行い、他の形式のデータを処理します。

Unified CCE の統合

Unified CCE とのシステム統合の一部として、サービス サーバは EAAS および Listener Service という 2 つの追加サービスで構成されます。これらのサービスは、メディア ルーティング（MR）インターフェイスおよび Agent Resource Management（ARM）インターフェイスを介し、それぞれ Unified CCE のメディア ルーティング（MR）PG および Agent PG コンポーネントと対話します。

さらに、Cisco Interaction Manager のアプリケーション サーバは Unified CCE アドミン ワークステーション（AW）データベース サーバとの接続を確立して、関連する設定データをインポートし、Cisco Interaction Manager データベース内の Cisco Interaction Manager オブジェクトに設定をマッピングします。Cisco Interaction Manager は Configuration API（ConAPI）インターフェイスを利用しないことに注意してください。

Cisco Interaction Manager を Unified System CCE と統合すると、Unified System CCE のマルチチャネル コントローラがサービス サーバにインストールされます。さらに、Unified CCE の特定の展開では、Unified CCE のメディア ルーティング（MR）PG もサービス サーバに存在できます。

親/子の設定では、親 ICM を介したマルチチャネル ルーティングおよび統合はありません。メディア ルーティング PG は、子または Unified System CCE に接続する必要があります。子ごとに、個別の Cisco Interaction Manager またはパーティションが必要です。

同様に、ホストされた ICM/CCH 環境では、Network Application Manager（NAM）レイヤ経由でのマルチチャネル ルーティングはなく、統合は個別の Customer ICM（CICM）レベルでだけ行われます。メディア ルーティング（MR）PG は CICM に接続する必要があります。

Cisco Interaction Manager のハイ アベイラビリティに関する注意点

Cisco Interaction Manager には、追加の Web サーバとアプリケーション サーバの使用、およびエージェントとコンタクトの作業をプラットフォーム全体に均等に分散させると共に冗長性モデルでのフェールオーバーを提供するためのロード バランシング機器の使用による、ハイ アベイラビリティ オプションが用意されています。

ロード バランシングに関する注意点

Cisco Interaction Manager の展開の Web サービス コンポーネントは、多数のエージェントによるアプリケーションへの同時アクセスに対応するようロード バランシングできます。仮想 IP を設定したロード バランサの背後に Web（または Web/アプリケーション）サーバを設定することができ、エージェントは仮想 IP を使用して Cisco Interaction Manager にアクセスできます。選択されているロード バランシング アルゴリズムに基づいて、ロード バランサは背後にある Web/アプリケーション サーバの 1 つに要求を送信し、応答をエージェントに返送します。このように、セキュリティの観点からは、ロード バランサはリバース プロキシ サーバとしても機能します。

ロード バランサを設定するための最も基本的なパラメータの 1 つは、クッキーベースの永続性によるスティッキ セッションをサポートするように設定するためのパラメータです。スケジュールされたメンテナンス作業が終了したら、ユーザ アクセスを可能にする前に、すべての Web/アプリケーション サーバが負荷の分散に使用できることを確認することをお勧めします。これを行わないと、最初の Web/アプリケーション サーバがスティッキ接続機能のために過負荷状態になる可能性があります。他の設定可能なパラメータを使用すると、均等なロード バランシング、プライマリ Web/アプリケーション サーバの分離、低性能の Web/アプリケーション サーバに送信される要求の削減など、さまざまな目的に合わせてロード バランシング アルゴリズムを定義できます。

ロード バランサは、クラスタ内のすべての Web/アプリケーション サーバの動作状態を監視します。問題が検出された場合、ロード バランサは該当する Web/アプリケーション サーバを使用可能なサーバのプールから削除し、問題のある Web/アプリケーション サーバに新しい Web 要求が送られないようにします。

フェールオーバーの管理

Cisco Interaction Manager はクラスタ化された展開をサポートします。これにより、透過的なレプリケーション、ロード バランシング、およびフェールオーバーによるハイ アベイラビリティとパフォーマンスが実現されます。Cisco Interaction Manager と Unified CCE の統合展開では、次の主要な方法を使用して障害状態に対処できます。

• 複数の Web/App サーバを実装する。プライマリ サーバに障害が発生した場合、ロード バランサを使用して要求を代替 Web/App サーバにルーティングすることで障害に対処できます。ロード バランサは、アプリケーション サーバの障害を検出すると、要求を別のアプリケーション サーバにリダイレクトします。その後、新しいユーザ セッションが作成され、ユーザは Cisco Interaction Manager に再びログインする必要があります。

• 外部的な需要の変化や内部的なインフラストラクチャの変化に対応して、オンライン状態のクラスタのサーバを動的に追加または削除できるようにする。

• Unified CCE コンポーネント（たとえば、MR PG および Agent PG の MR PIM および Agent PIM）を二重化して Cisco Interaction Manager がフェールオーバーできるようにし、障害時にアプリケーションのダウンタイムが発生しないようにする。

Cisco Interaction Manager のシングル ポイント障害には次のようなものがあります。

• Cisco Interaction Manager のプライマリ Web/App サーバがダウンする（これは JMS メッセージの交換を集中的に処理するサーバです）

• サービス サーバがダウンする

• データベース サーバがダウンする

1 つの Unified CM クラスタに対する複数の PIM 接続

このマニュアルでは、多くの場合、Agent PG には Unified CM クラスタに接続する PIM プロセスが 1 つしかないものとして説明されていますが、Agent PG では、同一の Unified CM クラスタへの PIM インターフェイスを複数管理できます。これは、次の 2 つの目的で、Unified CCE 内に追加のペリフェラルを作成する場合に使用できます。

• 「多数の CTI ルート ポイントを使用する場合のフェールオーバー リカバリの強化」

• 「Unified CCE PG の拡張（サーバあたり 2,000 人以上のエージェント）」

多数の CTI ルート ポイントを使用する場合のフェールオーバー リカバリの強化

Unified CCE PG がフェールオーバーする場合、前に Unified CM クラスタを制御していた PIM 接続は CTI Manager から接続解除され、PG の二重または冗長のサイドが、別の CTI Manager およびサブスクライバを使用して、その PIM をクラスタに接続しようとします。このプロセスでは、クラスタの Unified CCE によって制御されるすべてのデバイス（電話、CTI ルート ポイント、CTI ポートなど）に新しい PIM 接続を登録する必要があります。PIM がこれらの登録要求を行ったときに、PIM がアクティブな状態になり、コールを処理するためには、すべての登録要求が Unified CM によって承認される必要があります。

より迅速に復旧するために、Unified CCE PG では、お客様の CTI ルート ポイント専用の PIM を作成できます。これにより、この PIM では、1 秒あたり約 5 件の割合でこれらのデバイスに登録できるようになり、すべてのルート ポイント、すべてのエージェント電話、およびすべての CTI ポートについて PIM が待機する必要がある場合よりも、PIM がアクティブになり、これらの CTI ルート ポイントに着信したコールに応答するのに要する時間が短縮されます。この専用 CTI ルート ポイント PIM は数分早くアクティブになり、新しいインバウンド コールに応答できます。電話を制御する Agent PIM と CTI ポートが登録処理を完了してアクティブになるのを待機する間、インバウンド コールはキューイングまたは処理リソースに送られます。

これには、さらなる拡張性や、設計上のその他の利点はありません。唯一の目的は、この専用 PIM によってより迅速に提供される CTI ルート ポイントで、Unified CM がコールに対応できるようにすることです。ルート ポイントが 250 個以下の場合は復旧時間は大きく改善しないので、250 個を超えるルート ポイントを使用するお客様にだけ適しています。また、Unified CCE によって提供される CTI ルート ポイントだけをこの PIM に関連付ける必要があり、専用の CTI 対応 JTAPI または CTI ルート ポイント PIM 固有の PGUser が必要です。

（注） Unified System CCE モデルでは、この構成はサポートされていません。

Unified CCE PG の拡張（サーバあたり 2,000 人以上のエージェント）

Unified CCE 7.5（ x ）に用意されている新機能では、同一の物理 PG サーバで複数の PIM を使用して、同一の Unified CM クラスタまたはもう 1 つの Unified CM クラスタに接続できます。この設計では、Unified CCE の設計に必要な PG サーバの物理的な数が少なくなります。この設計は複数 PIM の復旧戦略とは異なります。この設計の PIM は、どちらも最大 2,000 人のエージェントを同時に配置し、エージェントをサポートするために必要に応じて関連する CTI ルート ポイントと CTI ポートを使用するように構成されます。ICM の視点からは、PIM を追加するとペリフェラルがもう 1 つ作られるので、ルーティングやレポーティングに影響を与える可能性があります。また、エージェント チームやスーパーバイザはペリフェラルを横断できないので、このような設計では、十分に考慮したうえでエージェント グループを各 PIM/ペリフェラルに割り当てる必要があります。

Unified CCE を Unified CVP とともに展開する設計では、Cisco Unified Communications Sizing Tool によって、1 つの Unified CM クラスタで合計 2,000 人を超えるエージェントをサポートすることもできます。ただし、CTI Manager および JTAPI インターフェイスでテストおよびサポートされているのは、最大 2,000 人までのエージェントです。1 つの Unified CM クラスタで 2,000 人を超えるエージェントをサポートできる設計を実現するために、もう 1 つの Agent PIM を構成して、さらに多くのエージェントをサポートできます（PG あたり最大で合計 4,000 人のエージェント）。

（注） Unified System CCE モデルでは、この構成はサポートされていません。

図 3-16 は、同一の Unified CM クラスタに接続する 2 つの異なる PIM が配置された 1 つの Unified CCE PG を示しています。

図 3-16 同一の Unified CM クラスタに対して構成された 2 つの PIM

（注） Unified CCE で Unified CM クラスタを適切にサイジングするためには、Cisco Unified Communications Sizing Tool（Unified CST）を使用する必要があります。

冗長（二重）Unified CCE ペリフェラル ゲートウェイに関する考慮事項

Unified CCE Agent PG は冗長（二重）構成で展開します。これは、PG には 1 つの CTI Manager を使用した Unified CM クラスタへの 1 つの接続しかないためです。CTI Manager に障害が発生した場合、PG は Unified CM クラスタと通信できなくなります。冗長または二重 PG を追加することにより、Unified ICM では、クラスタ内の別の Unified CM サーバで動作するセカンド CTI Manager プロセスを使用した、Unified CM クラスタへのセカンド経路または接続を確保できます。

CTI Manager と Unified IP IVR で Unified ICM のハイ アベイラビリティをサポートするための最小要件は、複数のサブスクライバを含む 1 つの Unified CM クラスタを持つ、二重（冗長）Agent PG 環境です。したがって、このケースにおける Unified CM クラスタの最小構成は、1 つのパブリッシャと 2 つのサブスクライバです。この最小構成では、プライマリ サブスクライバに障害が発生した場合、デバイスはクラスタのパブリッシャではなく、セカンダリ サブスクライバに確実に登録し直されます。（図 3-17 を参照）。小規模なシステムやラボ環境の場合、パブリッシャとサブスクライバが 1 つずつの構成も許可されます。この構成では、サブスクライバに障害が発生すると、すべてのデバイスがパブリッシャでアクティブになります。推奨される Unified CM サーバの台数の詳細については、「Cisco Unified Communications Manager サーバのサイジング」を参照してください。

図 3-17 1 つの Unified CM クラスタでの Unified ICM のハイ アベイラビリティ

図 3-17 では内容を簡潔にするため、ICM サーバまたは ICM セントラル コントローラは 1 つのサーバとして表されていますが、実際には、Unified CCE のエージェント数およびコールの量に応じて規模が変化する 1 組のサーバです。ICM セントラル コントローラには、次の冗長（二重）サーバが含まれます。

• Call Router：ICM 複合体の「頭脳」。A サイドと B サイドの Call Router プロセス間でメモリに保持される、リアルタイムの状況に応じたインテリジェント コール ルーティング方法を提供します。

• Logger/Database Server：すべての設定とスクリプティングに関する情報、およびシステムで収集された履歴データのリポジトリ。Call Router サイド A は Logger A に対してだけデータを読み書きし、Call Router B は Logger B に対してだけデータを読み書きするというように、Logger はそれぞれの Call Router と「ペア」になります。Call Router プロセスの両サイドは同期されるので、両方の Logger に書き込まれるデータは同一です。

特定の展開モデルでは、これらの 2 つのコンポーネントは同じ物理サーバにインストールでき、Rogger（つまり、Router と Logger の組み合わせ）と呼ばれます。特定の構成の詳細については、「Unified CCE のコンポーネントとサーバのサイジング」を参照してください。

Unified CM JTAPI およびペリフェラル ゲートウェイの障害検出

Unified CM JTAPI リンクとペリフェラル ゲートウェイの間の障害を検出するために使用されるハートビート メカニズムがあります。ただし、オープン ソケット ポートで TCP キープアライブ メッセージを使用する ICM ハートビート方式とは異なり、この方式では、システム間の JTAPI メッセージング プロトコルで特定のハートビート メッセージを使用します。デフォルトでは、ハートビート メッセージは 30 秒ごとに送信され、ハートビート メッセージが 2 回連続して検出されないと、Unified CM またはペリフェラル ゲートウェイによって通信経路がリセットされます。

この障害検出を強化するには、次の手順を使用して、ペリフェラル ゲートウェイ上で実行される JTAPI Gateway クライアントでのハードビートの間隔を変更します。

ステップ 1 ペリフェラル ゲートウェイのスタート メニューから、[Program] -> [Cisco JTAPI] -> [JTAPI Preferences] を選択します。

ステップ 2 [Advanced] -> [Server Heartbeat Interval (sec)] フィールドを 5 秒に設定します。

この値は 5 秒未満には設定しないことを推奨します。5 秒未満に設定すると、システム パフォーマンスに影響を及ぼし、不適切なフェールオーバーが発生する場合があります。この設定は、ハートビートが生成される頻度を決定します。ハートビートが 2 回連続して検出されなかった場合にフェールオーバーが行われるので、5 秒に設定すると、この接続は、ネットワーク接続が失われたときに 10 秒以内にフェールオーバーされます。デフォルトの 30 秒では、ネットワーク接続の障害に対してアクションが実行されるのに最大 1 分（60 秒）かかります。

ペリフェラル ゲートウェイと Unified CM の間のこの JTAPI 接続は同じ LAN セグメントでだけローカルにサポートされるので、このハートビート値に関する遅延は問題になりません。ただし、ネットワーク ホップ、ファイアウォール、またはこれらの 2 つのコンポーネント間で遅延を発生させるその他のデバイスを追加する場合は、考えられる状況を考慮したうえで、ハートビート間隔の値を適切に設定する必要があります。

Unified ICM の冗長化オプション

二重（冗長）Unified ICM サーバは、同一の物理サイトに置くことも、地理的に分散することもできます。これは、セントラル コントローラ（Call Router/Logger）とペリフェラル ゲートウェイに特に当てはまります。

通常の運用では、Unified ICM Call Router および Logger/データベース サーバのプロセスは、ビジブル/パブリック ネットワーク セグメントから分離されたプライベート ネットワーク接続を経由して相互接続されます。これらのサーバは、プライベート ネットワーク接続用にもう 1 つの NIC カードを使用して構成する必要があり、サーバが同一の物理サイトに置かれる場合は、プライベート接続を、独自の Cisco Catalyst スイッチでその他のビジブル/パブリック ネットワークから分離する必要があります。セントラル コントローラが地理的に離れている場合（2 つの異なる物理サイトにある場合）、同一のプライベート ネットワーク接続は、通常の運用で引き続き分離する必要があり、分離された WAN 接続を使用して 2 つの物理サイト間で接続する必要があります。通常の運用では、このプライベート ネットワーク接続は、ビジブル/パブリック ネットワーク WAN 接続とは別の回線またはネットワーク機器で提供する必要があります。これは、同一の回線またはネットワーク機器で提供すると、同時に両方の WAN セグメントが使用できなくなるシングル ポイント障害が発生する可能性があるためです。

通常の運用では、Unified ICM ペリフェラル ゲートウェイの二重化されたサーバのペアも、ビジブル/パブリック ネットワーク セグメントから分離されたプライベート ネットワーク接続を経由して相互接続されます。二重化されたペアの 2 つのサイド（サイド A とサイド B）が両方とも同一の物理サイトにある場合、プライベート ネットワークは、2 つのサーバ間でイーサネット クロスケーブルを使用してプライベート ネットワーク NIC カードを相互接続することで作成できます。二重化されたペアの 2 つのサーバが地理的に分散している場合（2 つの異なる物理サイトにある場合）、プライベート ネットワーク接続は、2 つの物理サイト間で、個別の WAN 接続を使用して接続する必要があります。このプライベート ネットワーク接続は、ビジブル/パブリック ネットワーク WAN 接続とは別の回線またはネットワーク機器で提供する必要があります。これは、同一の回線またはネットワーク機器で提供すると、同時に両方の WAN セグメントが使用できなくなるシングル ポイント障害が発生する可能性があるためです。

この接続の ICM ネットワーク要件に関するその他の詳細については、次の URL から入手できる『 Unified ICM Installation Guide 』を参照してください。

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

WAN 経由のクラスタ化の Unified ICM ネットワーク要件に関するその他の詳細については、「IPT：WAN 経由のクラスタリング」を参照してください。

Agent PG 内では、Unified CM クラスタへの接続を管理するため、次の 2 つのソフトウェア プロセスが実行されます。

• JTAPI Gateway

JTAPI Gateway は、PG のインストール時に Unified CM クラスタからダウンロードすることで PG にインストールします。これにより、システムの JTAPI および CTI Manager のバージョンとの互換性が確保されます。PG または Unified CM をアップグレードする場合は、この JTAPI Gateway コンポーネントを削除し、PG に再インストールする必要があることに注意してください。

JTAPI Gateway は PG によって自動的に始動され、ノード管理プロセスとして実行されます。これは、PG がこのプロセスを監視し、何らかの理由で障害が発生したときは自動的に再始動することを意味します。JTAPI Gateway は、低レベルの JTAPI ソケット接続プロトコル、および PIM と Unified CM CTI Manager の間のメッセージングを処理します。

• Agent PG Peripheral Interface Manager（PIM）

PIM もノード管理プロセスであり、予期しない障害が監視され、自動的に再始動されます。このプロセスは、Unified ICM と JTAPI Gateway および Unified CM クラスタとの間の高レベル インターフェイスを管理します。このプロセスでは、特定の監視対象オブジェクトを要求し、Unified CM クラスタからのルート要求を処理します。

二重 Agent PG 環境では、Agent PG の両サイドからの JTAPI サービスが、初期化時に CTI Manager にログインします。Unified CM PG のサイド A がプライマリ CTI Manager にログインし、PG のサイド B がセカンダリ CTI Manager にログインします。ただし、電話および CTI ルート ポイント用モニタを登録するのは、Cisco Unified CM PG のアクティブ サイドだけです。二重化した Agent PG のペアは、ホットスタンバイ モードで機能し、アクティブな PG サイドの PIM だけが Unified CM クラスタと通信します。スタンバイ側は、セカンダリ CTI Manager にログインしてインターフェイスの初期化だけを行い、フェールオーバー時の使用に備えます。Unified CM デバイスの登録および初期化サービスは、長い時間を要します。CTI Manager を使用できるようにしておくと、フェールオーバーに要する時間が大幅に短縮されます。

二重 PG オペレーションでは、アクティブになるサイドは、Unified ICM Call Router Server に最初に接続して構成情報を要求した PG サイドです。これは、PG デバイスにおけるサイド A またはサイド B の指定によって決定されるのではなく、PG が Call Router に接続できるかどうかによって決定されます。このため、Call Router への最善の接続を確立できるサイド PG がアクティブになります。

PIM の始動プロセスでは、すべての CTI ルート ポイントが登録済みであることが要求されます。1 秒につき 5 つのルート ポイントが登録されます。多数の CTI ルート ポイント（たとえば、1,000 個）があるシステムでは、このプロセスが完了するまで 3 分かかることがあり、この間エージェントはシステムにログインできません。前述のように、Unified CM クラスタへの複数の PIM インターフェイスにデバイスを分散すると、この時間を短縮できます。

Unified CM の CTI ルート ポイントにコールが着信したが PIM がまだ完全には動作していない場合、「未登録のコール転送」または「障害時のコール転送」の設定でリカバリ番号を使用してルート ポイントが設定されていない限り、これらのコールは失敗します。これらのリカバリ番号には、着信コールに確実に応答できるように、Auto Attendant に対応した Cisco Unity ボイスメール システム、または企業のオペレータのいる電話番号を指定できます。

Unified CM の障害シナリオ

完全冗長 Unified CCE システムでは、シングル ポイント障害は発生しません。ただし、複数の障害が組み合わさって、Unified CCE システムの機能性やアベイラビリティが低下するシナリオは存在します。また、Unified CCE ソリューションのコンポーネント自体が冗長性とフェールオーバーをサポートしない場合、このコンポーネント上にある既存のコールがドロップされます。ハイ アベイラビリティに最も影響があるのは、次の障害シナリオです。次の障害シナリオのいずれかが発生した場合、Unified CM Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）は始動できません（図 3-18 を参照）。

• Agent PG/PIM のサイド A と、サイド B の PG/PIM にサービスを提供するセカンダリ CTI Manager の両方に障害が発生する。

• Agent PG/PIM のサイド B と、サイド A の PG/PIM にサービスを提供するプライマリ CTI Manager の両方に障害が発生する。

これらのいずれのケースでも、Unified ICM は Unified CM クラスタと通信できなくなります。

図 3-18 Unified CM PG はバックアップ CTI Manager と相互接続できない

Unified ICM フェールオーバー シナリオ

この節では、次の障害シナリオで冗長性がどのように機能するかについて説明します。

• 「シナリオ 1：Unified CM と CTI Manager に障害が発生する」

• 「シナリオ 2：Agent PG のサイド A に障害が発生する」

• 「シナリオ 3：Unified CM のアクティブ コール処理サブスクライバに障害が発生する」

• 「シナリオ 4：Unified CCE PG に JTAPI サービスを提供する Unified CM CTI Manager に障害が発生する」

シナリオ 1：Unified CM と CTI Manager に障害が発生する

図 3-19 は、Cisco Unified CM サブスクライバ A 上における、完全なシステム障害またはネットワーク切断を示しています。当初、この同一サーバ上で CTI Manager と Cisco CallManager サービスが両方ともアクティブでした。このケースでは Unified CM サブスクライバ A がプライマリ CTI Manager です。このシナリオには次の状況が当てはまります。

• プライマリ サーバとしての Unified CM サブスクライバ A に、すべての電話とゲートウェイが登録されている。

• すべての電話およびゲートウェイが Unified CM サブスクライバ B に登録し直すように設定されている（つまり、B が、Unified CM の冗長性グループに含まれるバックアップ サーバです）。

• Unified CM サブスクライバ A および B が、同一の Unified CM クラスタ内で、CTI Manager の別個のインスタンスを実行している。

• Unified CM サブスクライバ A またはその CCM.exe プロセスに障害が発生した場合、登録されているすべての電話およびゲートウェイが Unified CM サブスクライバ B に登録し直される。エージェントの電話で接続中のコールはアクティブのままですが、コールを切断し、バックアップのサブスクライバに電話が登録し直されるまでは、エージェントは会議や転送などの電話サービスを使用できません。コールはアクティブのままでも、Unified CCE でコールを認識できなくなり、障害発生時のコールに関する Termination Call Detail（TCD; 終端コール詳細）レコードが Unified ICM データベースに書き込まれます。それ以降、ラップアップ コードなどのコール データは追記されません。アクティブなコールがない電話は、自動的に登録し直されます。

• PG のサイド A で障害が検出され、PG のサイド B へのフェールオーバーが開始される。

• Unified ICM のペリフェラルの構成によっては、CTI OS または CAD サーバ上でエージェントのログイン状態が維持されるが、PG のフェールオーバー処理が完了するまではデスクトップ コントロールが「グレー表示」される。エージェントは、再度ログインする必要がない場合でも、コール処理機能が復旧したことを確実に認識するように、手動で「受信可」または「使用可能」にする必要が生じることもあります。

• PG のサイド B がアクティブになり、すべての着信番号と電話が登録されて、コール処理が継続される。

• 前述のように、PG のフェールオーバー時には、ICM Call Router によって、アクティブ コールの TCD レコードが ICM データベースに書き込まれる。PG が別サイドにフェールオーバーしたときに、そのコールがまだアクティブだった場合、データベースに記録済みの前のコールとは関連のない「新しい」コールとしてシステムで扱われ、2 番目のTCD レコードが書き込まれます。

• Unified CM サブスクライバ A が復旧すると、すべてのアイドルの電話およびゲートウェイが Unified CM サブスクライバ A に登録し直される。アクティブのデバイスはアイドルになってから、プライマリ サブスクライバに登録し直されます。

• PG のサイド B はアクティブなままで、Unified CM サブスクライバ B 上の CTI Manager を使用している。

• 障害が復旧しても、PG が二重化ペアのサイド A にフェール バックされることはありません。すべての CTI メッセージングは、Unified CM サブスクライバ B 上の CTI Manager を使用して処理されます。Unified CM サブスクライバ B は、電話の状態とコール情報を取得するため Unified CM サブスクライバ A と通信します。

図 3-19 シナリオ 1：Unified CM と CTI Manager に障害が発生する

シナリオ 2：Agent PG のサイド A に障害が発生する

図 3-20 は、PG のサイド A の障害と PG のサイド B へのフェールオーバーを示しています。すべての CTI Manager および Unified CM サービスが正常に動作を続けます。このシナリオには次の状況が当てはまります。

• すべての電話およびゲートウェイが Unified CM サブスクライバ A に登録されている。

• すべての電話およびゲートウェイが Unified CM サブスクライバ B に登録し直すように設定されている（つまり、B がバックアップ サーバです）が、プライマリ サブスクライバが機能し続けるため、登録し直す必要がない。

• Unified CM サブスクライバ A および B は、ローカル インスタンスの CTI Manager をそれぞれ実行している。

• PG のサイド A に障害が発生すると、PG のサイド B がアクティブになる。

• PG サイド B ですべての着信番号と電話が登録されて、コール処理が継続される。電話とゲートウェイは Unified CM サブスクライバ A に登録されたまま動作し続け、フェールオーバーしない。

• 接続中のコールのあるエージェントではそのまま継続されるが、エージェント デスクトップ ソフトフォンでサードパーティ コール制御（会議、転送など）は使用できない。B サイド PG へのフェールオーバー時には、コール中でないエージェントの CTI デスクトップで、エージェント状態やサードパーティ コール制御ボタンを使用できなくなる場合があります。フェールオーバーが完了すると、エージェント デスクトップのボタンは復元されます。

• PG のフェールオーバー時には、ICM Call Router によって、アクティブ コールの TCD レコードが ICM データベースに書き込まれる。PG が別サイドにフェールオーバーしたときに、そのコールがまだアクティブだった場合、データベースに記録済みの前のコールとは関連のない「新しい」コールとしてシステムで扱われ、2 番目のTCD レコードが書き込まれます。

• PG のサイド A が復旧しても、PG のサイド B がアクティブなままで、Unified CM サブスクライバ B 上の CTI Manager が使用される。PG は A サイドにフェールバックせず、コール処理は PG のサイド B で続行されます。

図 3-20 シナリオ 2： Agent PG のサイド A に障害が発生する

シナリオ 3：Unified CM のアクティブ コール処理サブスクライバに障害が発生する

図 3-21 は、Unified CM のアクティブ コール処理サブスクライバ A 上の障害を示しています。このモデルでは、サブスクライバがコール処理とデバイス制御をアクティブに実行していますが、Unified CCE PG への CTI Manager 接続は提供していません。CTI Manager サービスはクラスタ内のすべての Unified CM サブスクライバ上で実行されていますが、サブスクライバ C とサブスクライバ D だけが Unified CCE ペリフェラル ゲートウェイと通信するように構成されています。

このシナリオには次の状況が当てはまります。

• すべての電話およびゲートウェイが Unified CM サブスクライバ A に登録されている。

• すべての電話およびゲートウェイが Unified CM サブスクライバ B に登録し直すように設定されている（つまり、B がバックアップ サーバです）。

• Unified CM サブスクライバ C および D は、ローカル インスタンスの CTI Manager をそれぞれ実行して、Unified CCE PG に JTAPI サービスを提供している。

• Unified CM サブスクライバ A に障害が発生すると、電話とゲートウェイはバックアップ Unified CM サブスクライバ B に登録し直される。

• PG のサイド A は、Unified CM サブスクライバ C 上の CTI Manager 接続によって接続が維持され、アクティブなままである。JTAPI と CTI Manager の間の接続に障害が発生していないため、フェールオーバーしません。ただし PG のサイド A では、電話とデバイスが（登録されていた）Unified CM サブスクライバ A に登録されていないことが検出され、続いてこれらのデバイスが Unified CM サブスクライバ B に自動的に再登録されたことが通知されます。エージェント電話が登録されていない間は、この PG がエージェント CTI デスクトップを無効にします。これにより、このエージェントの電話が Unified CM サブスクライバにアクティブに登録されていないにもかかわらず、このエージェントがシステムの使用を試みることを防ぎます。また、移行中は、このエージェントにコールがルーティングされないように、エージェントの状態が「受信不可」になります。

• Unified CM サブスクライバ A に登録されていないデバイスに関するコール処理は継続される。サブスクライバ A 上のこれらのデバイスに関するコール処理は、これらがバックアップ サブスクライバに再登録されたときも継続されます。

• Unified CM サブスクライバ A に登録されている電話で接続中のコールは継続される。ただし、フェールオーバー中の会議、転送、またはその他のサードパーティ コール制御を防ぐため、エージェント デスクトップは使用できなくなります。エージェントがアクティブ コールを接続解除すると、このエージェントの電話がバックアップ サブスクライバに再登録されます。

• 前述のように、Unified CM サブスクライバ A に障害が発生した場合、接続中のコールはアクティブのままだが、電話がクラスタ内のバックアップ サブスクライバに登録し直されていないため、ICM によるコール制御やトラッキングは失われる。実際、現在のコールが完了するまで、電話は登録し直されません。ICM Call Router によって、サブスクライバ障害発生時にアクティブだったコールの TCD レコードが、ICM データベースに書き込まれます。このレコードには、障害が発生し制御が失われた時点までのコールの統計情報が含まれます。それ以降、コール情報（統計情報、コールのラップアップ データなど）は ICM データベースに追記されません。

• Unified CM サブスクライバ A が復旧すると、電話およびゲートウェイが Unified CM サブスクライバ A に登録し直される。この登録し直しは、時間をかけて電話およびデバイスのグループを徐々に戻すように設定するか、またはコール センターへの影響を最小化するため、メンテナンス期間中に手動介入を必要とするように設定します。設定は Unified CM で行います。登録のし直し処理中に、CTI Manager サービスは、電話がバックアップ Unified CM サブスクライバ B から登録解除され、元の Unified CM サブスクライバ A に再登録されることを Unified CCE ペリフェラル ゲートウェイに通知します。

• 電話とデバイスが元のサブスクライバに戻った後も、コール処理は正常に継続される。

図 3-21 シナリオ 3：プライマリ Unified CM サブスクライバだけに障害が発生する

シナリオ 4：Unified CCE PG に JTAPI サービスを提供する Unified CM CTI Manager に障害が発生する

図 3-22 は、Unified CM サブスクライバ C 上における CTI Manager サービスの障害を示しています。Unified CM サブスクライバ C は、Unified CCE PG との通信に使用されています。CTI Manager サービスはクラスタ内のすべての Unified CM サブスクライバ上で実行されていますが、サブスクライバ C とサブスクライバ D だけが Unified CCE PG に接続するように構成されています。この障害時には、PG が JTAPI 接続の消失を検出し、冗長（二重）PG サイドにフェールオーバーします。

このシナリオには次の状況が当てはまります。

• すべての電話およびゲートウェイが Unified CM サブスクライバ A に登録されている。

• すべての電話およびゲートウェイが Unified CM サブスクライバ B に登録し直すように設定されている（つまり、B がバックアップ サーバです）。この場合、サブスクライバ A が機能し続けているため、登録し直されません。

• Unified CM サブスクライバ C および D は、ローカル インスタンスの CTI Manager をそれぞれ実行しており、Unified CCE PG に接続するよう設計されている。

• サブスクライバ C 上の Unified CM CTI Manager サービスに障害が発生すると、PG のサイド A が CTI Manager サービスの障害を検出し、PG のサイド B へのフェールオーバーを開始する。

• PG のサイド B が、サブスクライバ D 上の Unified CM CTI Manager サービスですべての着信番号と電話を登録して、コール処理が継続される。

• 接続中のコールのあるエージェントではそのまま継続されるが、エージェント デスクトップ ソフトフォンでサードパーティ コール制御（会議、転送など）は使用できない。エージェントがすべてのコールから接続解除されると、このエージェントのデスクトップ機能が復元されます。コールはアクティブのままでも、Unified CCE でコールを認識できなくなり、障害発生時のコールに関する TCD レコードが ICM データベースに書き込まれます。それ以降、ラップアップ コードなどのコール データは追記されません。

• サブスクライバ C 上の Unified CM CTI Manager サービスが復旧しても、PG のサイド B がアクティブであり続け、Unified CM サブスクライバ D 上の CTI Manager サービスが使用される。このモデルでは、PG はフェールバックしません。

図 3-22 シナリオ 4：Unified CM CTI Manager サービスだけに障害が発生する

WAN 経由のクラスタリングに関する Unified CCE のシナリオ

Unified CCE は、WAN 経由のクラスタリングのための Unified CM 設計モデルに重ねることもできます。これにより、Unified CM リソースのハイ アベイラビリティを、複数の場所およびデータ センター ロケーションにまたがって実現できます。この展開モデルをサポートするには、Unified CM に関する多数の設計要件を満たす必要があります。また、Unified CCE についても、固有の要件とフェールオーバーに関する新しい考慮事項が加わります。

設計要件とフェールオーバー シナリオを特定するためのテストは実施済みです。この設計モデルが成功するかどうかは、各ネットワークの構成および設定に依存しており、ネットワークの監視とメンテナンスが必要になります。前述のコンポーネント障害シナリオ（「Unified ICM フェールオーバー シナリオ」 を参照してください）は、このモデルでも有効です。このモデルには、次の障害シナリオが追加されます。

• 「シナリオ 1：Unified ICM セントラル コントローラまたはペリフェラル ゲートウェイ プライベート ネットワークに障害が発生する」

• 「シナリオ 2：ビジブル ネットワークの障害」

• 「シナリオ 3：ビジブル ネットワークとプライベート ネットワークの両方に障害が発生する（二重障害）」

• 「シナリオ 4：Unified CCE エージェント サイトの WAN（ビジブル ネットワーク）障害」

（注） このマニュアルではパブリック ネットワークとビジブル ネットワークの 2 つの用語を同じ意味で使用しています。

シナリオ 1：Unified ICM セントラル コントローラまたはペリフェラル ゲートウェイ プライベート ネットワークに障害が発生する

Unified CCE における WAN 経由のクラスタリングでは、システムの両サイドで状態および同期を維持するために、地理的に分散したセントラル コントローラ（Call Router/Logger）と分割されたペリフェラル ゲートウェイ ペアの間で、個別のプライベート ネットワーク接続が必要です。

このシナリオを完全に理解するためには、ICM 耐障害性アーキテクチャの概要を確認します。各 Call Router には、Message Delivery Service（MDS; メッセージ デリバリ サービス）という名前のプロセスがあります。このプロセスでは router.exe などのローカル プロセスとの間でメッセージを送受信し、両方の Call Router に対するメッセージの同期を処理します。たとえば、キャリアまたは任意のルーティング クライアントからサイド A にルート要求が届いた場合、MDS によって両方の Call Router が要求を確実に受信します。また、MDS は重複する出力メッセージも処理します。

MDS プロセスによって、二重化された ICM の両サイドは、同期実行で機能できます（耐障害性方式）。両方のルータは、MDS からルータが受信した入力に基づいて、ロックステップですべての処理を実行します。この同期実行方式を行うために、MDS プロセスは常にプライベート ネットワークを介して相互に通信する必要があります。MDS プロセスは、100 ミリ秒ごとに生成される TCP キープアライブ メッセージを使用して、冗長プロセス（もう一方のサイド）の状態を確認します。TCP キープアライブ メッセージが 5 回連続して検出されない場合、リンクまたはリモート パートナー システムに障害が発生した可能性があることが Unified ICM に通知されます。

二重化された ICM の両サイドが動作している場合（すべての本稼動システムに対する推奨の方法）、1 つの MDS で同期が有効化され、ペア（有効）状態になります。そのパートナーでは同期が無効となり、ペア（無効）状態となります。サイドが同期して動作しているときは常に、サイド A の MDS はペア（有効）状態で同期が有効になります。そのパートナーであるサイド B では同期が無効になり、ペア（無効）状態になります。同期が有効なサイドでは、入力メッセージの順序がルータに設定され、ICM システムのマスター クロックも維持されます。

Unified ICM セントラル コントローラ間のプライベート ネットワークに障害が発生した場合は、次の状況が当てはまります。

• Call Router では、TCP キープアライブ メッセージが 5 回連続して検出されないことによって障害が検出されます。現在有効なサイド（多くの場合はサイド A）は独立（有効）状態に移行し、システムに設定されている PG の半分以上と通信状態にある限り、機能し続けます。

• ペア（無効）のサイド（多くの場合はサイド B）は独立（無効）状態に移行します。その後、このサイドがデバイスの大半をチェックします。システムに設定されている PG の半分以上に対するアクティブまたはアイドル状態の DMP と通信していない場合は、処理が停止されて、無効になります。

• B サイドにデバイスの大半がある場合（設定されている半分を超える PG に対してアクティブまたはアイドル状態で接続している場合）、B サイドは「テスト」状態に移行し、各 PG に「Test Other Side」（TOS）メッセージを送信します。このメッセージを使用して、もう一方のサイド（この場合はルータ A）の Call Router を認識できるかどうかを PG に確認します。

• TOS メッセージに対していずれかの（1 つの場合でも）PG が A サイドがまだ有効であると応答するとすぐに、ルータ B は独立（無効）状態のまま、アイドル状態になります。Logger B もアイドル状態になり、ルータ B の PG に対するすべての DMP 接続もアイドル状態になります。すべてのコール処理は、影響なくサイド A で続行されます。

• すべての PG が、サイド A はダウンしているか到達不能であると応答した場合、B サイドの Call Router はシンプレックス モード（独立（有効））で再初期化され、Unified ICM のすべてのルーティングよりも優先されます。

• エージェント、接続中のコール、またはキュー内のコールへの影響はありません。システムは正常に機能し続けることができます。ただし、プライベート ネットワーク リンクが復旧するまで Call Router はシンプレックス モードです。

その他の考慮事項

Call Router は、Logger と「ペア」となり、それぞれが所有する Logger にだけプライベート ネットワークを介して構成および履歴データについてローカルに読み書きできます。Call Router のプライベート NIC カードの損失により障害が発生し、Call Router が有効なサイドである場合、Call Router は履歴データを Logger に書き込むことも、Logger データベースに構成の変更を加えることもできなくなります。

Call Router のプライベート NIC は、キャリアベースのプレルーティング ネットワークまたは SS7 インターフェイスと通信する場合にも使用されます。プライベート NIC で障害が発生すると、これらのサービスのいずれにもアクセスできません。

[Call Router Setup] で偶数の PG がチェックオフされ、半分の数の PG のみ使用できる場合、サイド A だけが動作します。プライベート ネットワークの障害が発生中に B サイドを稼動させるには、B サイドがシステム内の半分以上の PG と通信可能であることが必要です。

「余分な」PG またはネットワーク上に存在しない PG を [Call Router Setup] パネルから削除して、存在しない PG に対するデバイスの大半を判別する際の問題が回避されるように設定を維持することが重要です。

Unified CM ペリフェラル ゲートウェイ間のプライベート ネットワークに障害が発生した場合は、次の状況が当てはまります。

• ペリフェラル ゲートウェイの両サイドで、TCP キープアライブ メッセージが 5 回連続して検出されないことにより障害が検出されると、これらのサイドは Call Router と同様の処理に従って、プライベート リンクの障害を処理するときに MDS プロセスを利用します。セントラル コントローラと同様に、一方の MDS プロセスで同期が有効になり、冗長サイドでは同期は無効になります。冗長 PG を実行している場合（本稼動では常に推奨される方法）、A サイドでは常に同期が有効になります。

• 障害が検出された後に、同期が無効なサイド（サイド B）は、パブリック ネットワークまたはビジブル ネットワーク接続で TOS 手順を介してそのピア同期のテストを開始します。PG のサイド B は、A サイドの同期が有効またはアクティブになっていることを示す TOS 応答を受信するとすぐにアウト オブ サービス状態になり、A サイドはプライベート ネットワーク接続が回復するまでシンプレックス モードで稼動を続けます。PIM、OPC、および CTI SVR プロセスが PG のサイド A でアクティブになり（アクティブになっていなかった場合）、PG のサイド B サーバで問題が発生しない限り、CTI OS サーバのプロセスは両方のサイドでアクティブのままです。B サイドは、A サイドが有効であることを示すメッセージを受信しなかった場合、シンプレックス モードで稼動を続け、PIM、OPC、および CTI SVR プロセスは PG のサイド B でアクティブになります（アクティブになっていない場合）。この状態が発生するのは、ビジブル ネットワークおよびプライベート ネットワークの二重の障害により、PG のサイド A サーバが完全にダウンするか到達不能になった場合だけです。

• エージェントは確立済みの CTI OS サーバ プロセス接続に接続されたままであるので、エージェント、進行中のコール、またはキュー内のコールには影響ありません。システムは正常に機能し続けることができます。ただし、プライベート ネットワーク リンクが復旧するまで PG はシンプレックス モードです。

1 つのリンクに 2 つのプライベート ネットワーク接続が組み合されていた場合も、障害は同じ経過をたどります。ただしシステムは、Call Router とペリフェラル ゲートウェイの両方で、シンプレックス モードで動作します。この時点で 2 番目の障害が発生した場合、コール ルーティングおよび ACD 機能の一部または全部が失われる可能性があります。

シナリオ 2：ビジブル ネットワークの障害

この設計モデルにおけるビジブル ネットワークは、メイン システム コンポーネント（Unified CM サブスクライバ、ペリフェラル ゲートウェイ、Unified IP IVR/Unified CVP コンポーネントなど）が存在する、複数のデータ センター ロケーション間のネットワーク パスです。このネットワークは、すべての音声トラフィック（RTP ストリームおよびコール制御シグナリング）、Unified ICM CTI（コール制御シグナリング）トラフィック、およびサイト間のあらゆる通常のデータ ネットワーク トラフィックを伝送するために使用されます。Unified CM における WAN 経由のクラスタリングの要件を満たすには、このリンクが、遅延が非常に少なく帯域幅が十分な、アベイラビリティの高いリンクである必要があります。このリンクは、システムの耐障害設計の一部であり、高い復元力が必要なため、Unified CCE 設計にとって重要です。

• 中央サイト間に設置するハイ アベイラビリティ（HA）WAN は、シングル ポイント障害がなく、完全冗長であることが必要です（サイト間の冗長性オプションの詳細は、 http://www.cisco.com/go/designzone で入手できる、WAN インフラストラクチャと QoS の設計ガイドを参照してください）。ハイ アベイラビリティ WAN で部分的な障害が発生した場合に備え、冗長リンクには、すべての QoS パラメータを満足させた状態で、中央サイトが受け持つすべての負荷を処理できる能力が必要です。詳細は、「WAN 経由の Unified CCE クラスタリングに対する帯域幅の要件」を参照してください。

• ポイントツーポイント テクノロジーを採用したハイ アベイラビリティ（HA）WAN は、2 つの独立したキャリアにわたる実装に最適です。ただし、リング テクノロジーを採用する場合、これは必ずしも必要ではありません。

データ センター ロケーション間のビジブル ネットワークに障害が発生した場合は、次の状況が当てはまります。

• Unified CM サブスクライバが障害を検出し、ローカルで機能し続けます。ローカル コール処理とコール制御に影響はありません。ただし、この WAN リンクを介して設定されたコールは、リンクの障害とともに失敗します。

• Unified ICM Call Router が障害を検出します。これは、リモート ペリフェラル ゲートウェイからの TCP キープアライブの正常なフローが停止するためです。同様に、リモート Call Router からの TCP キープアライブが失われることにより、ペリフェラル ゲートウェイがこの障害を検出します。ペリフェラル ゲートウェイが、データ通信をローカル Call Router に自動的に割り当て直します。次にローカル Call Router がプライベート ネットワークを使用してデータをもう一方のサイドの Call Router に渡し、コール処理を続行します。これにより、ペリフェラル ゲートウェイまたは Call Router のフェールオーバーは発生しません。

• 次の状況では、半分以上のエージェントがこの障害の影響を受ける場合があります。

– エージェント デスクトップ（Cisco Agent Desktop または CTI OS）がシステムのサイド A のペリフェラル ゲートウェイに登録されているが、物理的な電話機が Unified CM クラスタのサイド B に登録されている場合。

正常な状況では、電話イベントは、サイド A のペリフェラル ゲートウェイに示すため、CTI Manager サービスを使用し、ビジブル ネットワークを介してサイド B からサイド A に渡されます。ビジブル ネットワークの障害により、IP 電話がクラスタのサイド A に登録し直されることはありません。電話は独立したサイド B で稼動し続けます。ペリフェラル ゲートウェイはこの電話を認識できなくなり、エージェントが Unified CCE から自動的にログアウトします。これは、エージェントの電話にコールを着信させることが不可能になるためです。

– エージェント デスクトップ（Cisco Agent Desktop または CTI OS）と IP 電話の両方がペリフェラル ゲートウェイと Unified CM のサイド A に登録されているが、電話がリセットされて Unified CM サブスクライバのサイド B に再登録した場合。

IP 電話が登録し直すか、または手動でリセットされて強制的に Unified CM サブスクライバのサイド B に登録した場合、ローカル ペリフェラル ゲートウェイに CTI Manager サービスを提供するサイド A の Unified CM サブスクライバは、電話を登録解除してサービスから削除します。ビジブル ネットワークがダウンしているため、サイド B のリモート Unified CM サブスクライバは、電話登録イベントをリモート ペリフェラル ゲートウェイに送ることができません。Unified CCE はこのエージェントの電話を制御できなくなり、このエージェントをログアウトします。

– エージェント デスクトップ（CTI Toolkit Agent Desktop または Cisco Agent Desktop）がサイド B サイトの CTI OS サーバに登録されているが、アクティブ ペリフェラル ゲートウェイ サイドがサイド A のサイトである場合。

正常な動作では、CTI Toolkit Agent Desktop が、CTI OS サーバ ペアへの接続のロード バランシングを行います。どの時点でも、アクティブ ペリフェラル ゲートウェイ CTI サーバ（CG）に接続するためにビジブル ネットワークを横断する必要がある CTI OS サーバ上に、エージェント接続の半分が存在します。ビジブル ネットワークに障害が発生したときは、CTI OS サーバが、リモート ペリフェラル ゲートウェイ CTI サーバ（CG）への接続が失われたことを検出し、アクティブ エージェント デスクトップ クライアントを接続解除してリモート サイトの冗長 CTI OS サーバに強制的に登録し直します。CTI Toolkit Agent Desktop は、冗長 CTI OS サーバを認識し、自動的にこのサーバを使用します。CTI Toolkit Agent Desktop は、この移行の間無効になり、冗長 CTI OS サーバに接続されると同時に動作状態に戻ります（Unified ICM コンフィギュレーション マネージャで Unified CM ペリフェラル ゲートウェイに定義された /LOAD パラメータによっては、エージェントがログアウトして受信不可状態になる場合があります）。

シナリオ 3：ビジブル ネットワークとプライベート ネットワークの両方に障害が発生する（二重障害）

ビジブル ネットワークとプライベート ネットワークのいずれかに障害が発生した場合は、Unified CCE エージェントおよびコールへの影響は限定的です。しかし、これらのネットワークの両方に同時に障害が発生した場合、システムの機能は大幅に制限されます。この障害は、重大な障害であり、バックアップと復元力を組み込んだ慎重な WAN 設計によって回避する必要があります。

ビジブル ネットワークとプライベート ネットワークに同時に障害が発生した場合は、次の状況が当てはまります。

• Unified CM サブスクライバが障害を検出し、ローカルで機能し続けます。ローカル コール処理とコール制御に影響はありません。ただし、このビジブル WAN リンクを介して設定されて、アクティブな音声パス メディアを送信しているコールは、リンクに失敗します。コールが失敗すると、Unified CCE PG はコールのドロップを認識し、そのコールについてドロップ時点における TCD レコードを ICM データベースに書き込みます。

• Call Router とペリフェラル ゲートウェイが、TCP キープアライブ メッセージを 5 回連続して検出しないことによってプライベート ネットワーク障害を検出します。この TCP キープアライブ メッセージは 100 ミリ秒ごとに生成され、このリンクでは約 500 ミリ秒以内に障害が検出されます。

• Call Router が、障害がネットワーク問題なのか、リモート Call Router に障害が発生して TCP キープアライブ メッセージを送信できなくなっているのかを判別するため、test-other-side メッセージでペリフェラル ゲートウェイへの接触を試みます。Call Router は、アクティブのまま機能するサイド（通常は最もアクティブなペリフェラル ゲートウェイ接続であるサイドである、システムの A サイド）を判別します。そのサイドはリモートの Call Router と PG が独立（無効）モードである間は、シンプレックス モードでアクティブのままになります。Call Router がペリフェラル ゲートウェイにメッセージを送り、データ フィードをアクティブ Call Router だけに割り当て直します。

• ペリフェラル ゲートウェイが、アクティブ Unified CM 接続のあるサイドを判別します。ただしこの際、Call Router の状態も考慮されます。ペリフェラル ゲートウェイは、アクティブ Call Router に接続できない場合は非アクティブになります。通常は、これによって A サイドの PG がアクティブ シンプレックス有効モードになり、B サイドは独立（無効）になります。

• 残った Call Router とペリフェラル ゲートウェイが、ビジブル ネットワーク上の TCP キープアライブの消失から、ビジブル ネットワークの障害を検出します。このキープアライブは 400 ミリ秒ごとに送信されます。したがって、この障害が検出されるまでに最大 2 秒かかる可能性があります。

• Call Router が認識できるのが、ローカル ペリフェラル ゲートウェイだけになります。ローカル ペリフェラル ゲートウェイとは、ローカル Unified IP IVR または Unified CVP コール サーバの制御に使用されるペリフェラル ゲートウェイで、Unified CM クラスタのローカル側です。リモートの Unified IP IVR または CVP コール サーバは、GED-125 IVR PG インターフェイスを介して Unified ICM コール制御なしのオフラインになります。Unified ICM コール ルーティング スクリプトは、peripheral on-line ステータス チェックを使用して、これらのオフライン デバイスへのルーティングを自動的に回避します。オフラインの IP-IVR で進行中だったコールはドロップするか、IP-IVR のローカルのデフォルト スクリプトまたは Unified CM の [Call Forward on Error] 設定を使用します。オフラインのコール サーバから Unified CVP で制御されているコールは、それらの入力音声ゲートウェイのサバイバビリティ TCL スクリプトから処理されます。進行中であるが Unified CCE に表示されなくなったコールの場合、障害の発生時までのコール データの TCD レコードが ICM データベースに書き込まれます。デフォルトまたはサバイバビリティ スクリプトによってコールが別のアクティブな Unified CCE コンポーネントにリダイレクトされると、コールはシステムに「新しいコール」として表示され、レポートまたは追跡目的では元のコールと関係なくなります。

• 無効になったサイドに到着した新規コールは、Unified CCE によってルーティングされませんが、Unified CM の標準の障害時リダイレクトまたは入力音声ゲートウェイの Unified CVP サバイバビリティ TCL スクリプト を使用して CTI ルート ポイントにリダイレクトまたは処理されます。

• 前述のように、エージェントの IP 電話が、アクティブ ペリフェラル ゲートウェイと CTI OS サーバ接続の反対側の Unified CM クラスタ サイドに登録された場合、エージェントが影響を受けます。影響を受けないのは、当該サイトにローカルに登録された電話を持つ、ペリフェラル ゲートウェイの存続サイドでアクティブだったエージェントだけです。

ここで、Call Router と Unified CM ペリフェラル ゲートウェイがシンプレックス モードになり、存続サイドからの新規コールの Unified CCE コール処理だけが受け入れられるようになります。Unified IP IVR/Unified CVP 機能も、存続サイドに制限されます。

シナリオ 4：Unified CCE エージェント サイトの WAN（ビジブル ネットワーク）障害

WAN 経由のクラスタリングのための Unified CCE 設計モデルでは、Unified CCE エージェントが、ビジブル WAN で接続された複数のサイトにリモートに設置されていることを前提としています。各エージェント ロケーションには、Unified CM と Unified ICM コンポーネントが設置された両方のデータ センター ロケーションへのビジブル WAN による WAN 接続が必要です。これらの接続は、冗長性を確保し、ネットワーク全体の障害発生時にも、リモート サイトから基本的なダイヤル トーン サービスを使用して緊急コールを発信できるように、基本的な SRST 機能を備える必要があります。

Unified CCE エージェント サイトの WAN のサイド A に障害が発生した場合は、次の状況が当てはまります。

• サイド A の Unified CM サブスクライバをホームとする IP 電話は、サイド B のサブスクライバに自動的に登録し直します（冗長グループが構成されている場合）。

• このサイトの CTI OS または Cisco Agent Desktop サーバに接続されているエージェント デスクトップは、リモート サイトの冗長 CTI OS サーバに自動的に割り当て直されます（再割り当て中はエージェント デスクトップが無効になります）。

Unified CCE エージェント サイトの WAN の両サイドに障害が発生した場合は、次の状況が当てはまります。

• ローカル音声ゲートウェイが、Unified CM クラスタへの通信経路の障害を検出し、ローカル ダイヤルトーン機能を確保するために SRST モードになります。Unified CVP を使用している場合、これらのゲートウェイは CVP コール サーバが失われたことを検出し、自身のローカル サバイバビリティ TCL スクリプトを実行してインバウンド コールを再ルーティングします。Unified CVP にローカルに存在するアクティブ コールはすでに Unified CCE からは見えないので、障害時に TCD レコードが ICM データベースに書き込まれ、その時点でコールのトラッキングは中止されます。このようなコールは、ローカル サバイバビリティ TCL スクリプトを実行することで、PSTN を経由してまだアクティブな別の Unified CCE サイトにリダイレクトされる可能性がありますが、リダイレクトされたコールは、リダイレクト先の Unified CCE では「新しいコール」と認識され、元のコール情報との関係は維持されません。コールがローカルに留まり、SRST によってローカルの電話にリダイレクトされた場合は、その時点以降、Unified CCE からそのコールを見ることはできません。

• エージェント デスクトップが CTI OS サーバ（または Cisco Agent Desktop サーバ）への接続が失われたことを検出し、このエージェントをシステムから自動的にログアウトします。IP 電話が SRST モードの間は、Unified CCE エージェントとして機能できません。

Unified CM サービス

展開の規模が大きい場合は、エージェント電話が登録されている Unified CM が、Unified CCE の Unified CM ペリフェラル ゲートウェイと通信する CTI Manager サービスを実行していない可能性もあります。アクティブ Unified CM（コール処理）サービスに障害が発生したときは、これに登録されているすべてのデバイスは、CTI Manager サービスにより、ローカルと外部クライアント（異なるサブスクライバ CTI Manager サービス上のペリフェラル ゲートウェイなど）に対してアウト オブ サービスとしてレポートされます。

接続中のコールは接続状態が維持されるため、障害発生後でもコールが数分間継続されている可能性もあります。しかし、Unified CM の Call Detail Reporting（CDR; コール詳細レポート）では、Unified CM の障害発生時にコールが終了したものとして表示されます。障害発生時にコール中ではなかったエージェントの IP 電話は、ただちにバックアップ Unified CM サブスクライバに登録されます。障害発生時にコール中だったエージェントの IP 電話は、エージェントが現在のコールを完了するまでバックアップ Unified CM サブスクライバに登録されません。MGCP、H.323、または SIP ゲートウェイが使用されている場合は、接続中のコールは存続しますが、それ以上のコール制御機能（保留、復帰、転送、会議など）は使用できなくなります。

また、Unified CCE は、すでにコールが終了したと Unified CCE PG にレポートしたため、TCD テーブルにコール レコードを書き込みます。PG がフェールオーバーした後もコールが存続している場合は、元のコールとは無関係の「新しいコール」として、2 番目の TCD レコードが書き込まれます。

アクティブ Unified CM サブスクライバで障害が発生した場合、PG は Unified CM からアウトオブサービス イベントを受け取り、エージェントをログアウトします。コールを受信し続けるには、エージェントの電話がバックアップ Unified CM サブスクライバに再登録されるまで待ち、その後エージェントが Unified CCE デスクトップ アプリケーションに再度ログインして機能を復旧する必要があります。プライマリ Unified CM サブスクライバが復旧すると、エージェント電話が元のサブスクライバに再登録されて、クラスタが通常の状態に戻ります。電話とデバイスは複数のアクティブ サブスクライバ間で適切にバランス調整されます。

まとめると、Unified CM コール処理サービスは CTI Manager サービスから独立しており、CTI Manager サービスは JTAPI 経由で Unified CM PG に接続します。Unified CM コール処理サービスは IP 電話の登録を担い、これに障害が発生しても Unified CM PG に影響はありません。Cisco Unified CCE の視点からは、PG はオフラインになりません。これは、CTI Manager を実行する Unified CM サーバが稼動し続けるためです。したがって、PG はフェールオーバーを必要としません。

Unified IP IVR

CTI Manager サービスに障害が発生すると、Unified IP IVR JTAPI サブシステムがシャットダウンし、クラスタのバックアップ Unified CM サブスクライバ上のセカンダリ CTI Manager サービスへの接続を試みることによって再始動します。さらに、この Unified IP IVR にあるすべての音声コールがドロップされます。バックアップ サブスクライバ上に使用可能なセカンダリ CTI Manager サービスが存在する場合は、Unified IP IVR がそのサブスクライバ上の CTI Manager サービスにログインし、Unified IP IVR JTAPI ユーザに関連付けられたすべての CTI ポートを再登録します。すべての Unified CM デバイスが Unified IP IVR JTAPI ユーザへの再登録に成功すると、サーバが音声応答装置（VRU）機能をレジュームし、新規コールを処理します。Unified CVP は、コール制御について Unified CM CTI Manager サービスに依存していないため、この影響を受けません。

Unified IP IVR Release 3.5 ではコールドスタンバイの冗長性、リリース 4.0 ではホットスタンバイの冗長性が提供されますが、この構成を Unified CCE で使用することはサポートされていません。これらの設計では冗長サーバを利用しますが、冗長サーバはプライマリ Unified IP IVR サーバに障害が発生しない限り使用されません。しかし、フェールオーバー プロセス中には、フェールオーバーの一環として、キューに入っているコールや処理中のコールはすべて、Unified IP IVR でドロップされてしまいます。より復元力の高い設計にするには、2 つ目（または、それ以上）の Unified IP IVR サーバを展開し、すべてをアクティブにします。これにより Unified CCE では、これらのサーバ間で自動的にコールのロード バランシングが行われることになります。図 3-23 に示すとおり、Unified IP IVR サーバの 1 つに障害が発生した場合、そのサーバ上のコールにだけ障害が発生します。もう一方のアクティブ サーバはアクティブのままなので、システムで新規コールを受け入れることができます。

Unified ICM

Unified ICM は、Unified ICM サーバで実行されるサービスおよびプロセスの集合です。これらのサービスに対するフェールオーバーおよびリカバリ プロセスは、サービスごとに固有であり、Unified CCE ソリューションの他のパート（別の Unified ICM サービスを含む）への影響を慎重に調べて理解する必要があります。

Unified CM PG と CTI Manager サービス

アクティブ CTI Manager サービスまたは PG ソフトウェアに障害が発生すると、PG JTAPI Gateway/PIM が OUT_OF_SERVICE イベントを検出し、冗長（二重）PG へのフェールオーバーを開始します。冗長 PG はすでにバックアップ Unified CM サブスクライバの CTI Manager サービスにログインしているため、IP 電話および設定された着信番号または CTI ルート ポイントを自動的に登録します。この初期化サービスは、1 秒間に約 5 デバイスのレートで行われます。エージェント デスクトップには、これらがログアウトしたもの、または受信不可として表示され、ルーティング クライアントまたはペリフェラル（Unified CM）がオフラインになったことを示すメッセージが表示されます（この警告は管理者の好みでオンにもオフにもできます）。障害リカバリが完了するまで、すべてのエージェントでデスクトップ サードパーティ コール制御機能が失われます。デスクトップ上のコール制御アクション ボタンがグレー表示され、デスクトップで何のアクションも実行できなくなることから、エージェントはこのことを認識できます。既存コールは、発信者に影響を与えることなくアクティブのまま存続します。

PG のフェールオーバー中にコールが Unified CM の CTI ルート ポイントに到達した場合に、PIM がまだ完全に稼動していないとき、このようなコールは一部の例外を除き、失敗します。その例外とは、これらのルート ポイントの「未登録のコール転送」または「障害時のコール転送」の設定にリカバリ番号が設定されている場合です。これらのリカバリ番号には、着信コールに確実に応答できるように、Auto Attendant に対応した Cisco Unity ボイスメール システム、または企業のオペレータのいる電話番号を指定できます。

（注） エージェントは、デスクトップ フェールオーバー中はボタンを押してはなりません。これは、これらのキーストロークがバッファリングされ、フェールオーバーが完了してエージェント状態が復旧したときに CTI に送られる可能性があるためです。

アクティブ PG がアイドル サイドにフェールオーバーすると、アクティベーション シーケンスの一部として Unified CM への問い合わせが発行され、まだ接続中のコールが復旧されます。この場合、そのコールの情報を提供する Termination Call Detail レコードは、PG 移行前と移行後の 2 つが存在することになります。ペリフェラル コール変数と ECC 変数は、エージェント デスクトップ上で失われます。また、コールが介入であったか会議コールであったかを示す指標は、エージェント デスクトップからも、レポートからも失われます。ラップアップ状態であったコールは復旧されません。アクティベーションが完了すると、エージェントはエージェント デスクトップからコールのリリース、転送、または会議を行えるようになります。

（注） フェールオーバー期間中にコール状態またはエージェント状態が変更された場合、コール状態およびエージェント状態の情報はフェールオーバーの終了時に完全でないことがあります。

Unified ICM VRU PG

音声応答装置（VRU）PG に障害が発生すると、この Unified IP IVR 上のキューに入っているコールまたは処理中のコールはすべてドロップされます（ただし、デフォルト スクリプトの適用が定義されている場合、または Unified CM で CTI ポートの「障害時のコール転送」設定にリカバリ番号が定義されている場合を除く）。Unified CVP で進行中のコールまたはキューに入っているコールはドロップされず、H.323 または SIP ダイヤル プラン内のセカンダリ Unified CVP または番号（音声ゲートウェイのサバイバビリティ TCL スクリプトで使用可能な場合）にリダイレクトされます。

冗長（二重）VRU PG サイドが Unified IP IVR または CVP に接続し、フェールオーバーと同時に新しいコールの処理を開始します。障害が発生した VRU PG サイドが復旧すると、現在実行中の VRU PG がアクティブ VRU PG として稼動し続けます。したがって、冗長 VRU PG を用意することは非常に有益です。なぜなら、IP IVR または CVP がアクティブ キュー ポイントとして機能し続け、コール処理を継続することが可能になるからです。VRU PG の冗長性がない場合、VRU PG に障害が発生したときに、IP IVR が適切に機能していていも、IP IVR を使用できなくなります（図 3-23 を参照）。

図 3-23 2 つの IP IVR サーバによる冗長 Unified ICM VRU PG

Unified ICM Call Router と Logger

これらの図では、Unified ICM セントラル コントローラまたは Unified ICM サーバが 1 セットの冗長サーバとして示されています。ただし、実装のサイズによっては、次のキー ソフトウェア プロセスを提供するため、複数のサーバを展開する場合があります。

• Unified ICM Call Router

Unified ICM Call Router は、システム内にあるすべてのエージェント、コール、およびイベントの状態に関する一貫したメモリ イメージを保持する、システムの頭脳です。Unified ICM Call Router は、ユーザが作成した Unified ICM ルーティング スクリプトを実行し、アドミン ワークステーションにリアルタイム レポーティング フィードを入力しながら、システム内のコール ルーティングを実行します。Call Router ソフトウェアは同期して実行されるため、冗長サーバの両方で、システム全体の現在の状態に関する同一のメモリ イメージが実行されます。この情報は、プライベート LAN 接続上のサーバ間で状態イベントがやり取りされることにより、最新状態にアップデートされます。

• Unified ICM Logger とデータベース サーバ

Unified ICM Logger とデータベース サーバには、設定（エージェント ID、スキル グループ、コール タイプなど）とスクリプティング（コール フロー スクリプト）、およびコール処理からの履歴データに関するシステム データベースが保持されます。Logger はローカル Call Router プロセスからデータを受け取り、システム データベースに格納します。Call Router は同期されているので、Logger データも同期されています。2 つの Logger データベースの同期が失われた場合は、プライベート LAN 経由で Unified ICMDBA アプリケーションを使用することにより、手動で再同期できます。Logger を使用すると、ビジブル ネットワーク経由で、履歴データをカスタマー Historical Database Server（HDS）アドミン ワークステーションに複製することもできます。

Unified ICM Call Router の 1 つに障害が発生した場合、残ったサーバが、プライベート LAN で TCP キープアライブ メッセージを 5 回連続して検出しないことによって障害を検出します。Call Router はこの TCP キープアライブ メッセージを 100 ミリ秒ごとに生成しているので、この障害が検出されるまでには最大 500 ミリ秒を要します。障害が検出されると、残った Call Router がシステム内のペリフェラル ゲートウェイにコンタクトし、発生した障害のタイプを確認します。プライベート ネットワーク上の TCP キープアライブ メッセージの消失は、次のいずれかの状況で発生します。

• プライベート ネットワーク停止：プライベート LAN スイッチまたは WAN がダウンしても、両方の Unified ICM Call Router が完全に稼動している可能性があります。この場合は、両方の Unified ICM Call Router が、同期データを提供するプライベート ネットワーク経由で相互に認識していなくても、ペリフェラル ゲートウェイには認識されています。同期不能になったルータ（Call Router B）が大半の PG と通信できる場合、Call Router B はそれらの PG に対して順に Test Other Side（TOS）メッセージを送信し、反対サイドの Call Router（サイド A）が稼動しているかどうかを確認します。サイド A が実際には稼動していることを伝えるメッセージが Call Router B で受信された場合、Call Router A はプライベート ネットワークが復旧するまでシンプレックスで動作します。すべての PG が TOS メッセージに応答し、サイド A がダウンしていることを伝えた場合、サイド B はシンプレックス モードで再初期化されます。

• Call Router ハードウェア障害：反対サイドの Call Router に物理ハードウェア障害があり、完全にアウト オブ サービスになっている可能性があります。この場合、ペリフェラル ゲートウェイが反対サイドの Call Router を認識できなくなったことをレポートし、残った Call Router がアクティブな処理ロールをシンプレックス モードで引き継ぎます。この障害は、プライベート ネットワークのハートビート キープアライブの消失により Call Router によって検出されます。

Call Router のフェールオーバー処理中は、残った Call Router がアクティブ シンプレックス モードになるまで、キャリア Network Interface Controller（NIC; ネットワーク インターフェイス コントローラ）またはペリフェラル ゲートウェイから Call Router に送られるルート要求は、キューに入れられます。IVR 内またはエージェントのところで接続中のコールは影響を受けません。

Unified ICM Logger とデータベース サーバの 1 つに障害が発生した場合は、ローカル Call Router がコール処理からのデータを保存できなくなる以外に、直接的な影響はありません。冗長 Logger はローカル Call Router からのデータを受け入れ続けます。Logger サーバが復旧すると、この Logger が冗長 Logger にコンタクトし、オフラインでいた時間の長さを判定します。Logger がオフラインでいた時間が 12 時間未満である場合は、オフライン中に取得できなかったすべてのトランザクションを自動的に冗長 Logger に要求します。Logger は、データベースに記録された各エントリの日付と時刻を追跡するリカバリ キーを保持しています。これらのキーは、障害が発生した Logger にプライベート ネットワーク経由でデータを復元するために使用されます。

Logger がオフラインでいた時間が 12 時間を超える場合は、データベースの同期は自動的には実行されません。この場合は、Unified ICMDBA アプリケーションを使用して手動で再同期する必要があります。手動再同期の場合、プライベート ネットワークでのこのデータ転送をいつ実行するかを、システム管理者が決めることができます。通常この転送は、システム内のコール処理アクティビティが少ないメンテナンス期間に実行します。

Logger データベースから HDS アドミン ワークステーションにデータを送る Logger レプリケーション プロセスでは、同期が行われると同時に、Logger データベースに書き込まれた新規行が自動的に複製されます。

Logger 障害発生時に、コール処理への影響はありません。ただし、Logger から複製された HDS データは、Logger の復旧が可能になるまで停止されます。

また、Unified Outbound Option が使用されている場合、Campaign Manager ソフトウェアは Logger A にだけロードされます。このプラットフォームがアウト オブ サービスの場合は、Logger が稼動状態に復旧可能になるまでアウトバウンド コールが停止されます。

アドミン ワークステーション リアルタイム ディストリビュータ（RTD）

アドミン ワークステーション（AW）Real-Time Distributor（RTD; リアルタイム ディストリビュータ）では、設定およびスクリプティングの変更を行うためのユーザ インターフェイスが提供されます。また、Web ベースのレポーティング ツールである WebView と Internet Script Editor も提供できます。

これらのサーバは、他の Unified ICM システム コンポーネントのように冗長または二重オペレーションをサポートしません。ただし、複数のアドミン ワークステーション サーバを展開して Unified CCE の冗長性を確保することはできます（図 3-24 を参照）。

図 3-24 冗長 Unified ICM ディストリビュータと AW サーバ

アドミン ワークステーション リアルタイム ディストリビュータは、エンタープライズ全体の Unified CCE に関するリアルタイム情報を提供する、Unified ICM Call Router リアルタイム フィードのクライアントです。同一サイトのリアルタイム ディストリビュータは、指定されたプライマリ リアルタイム ディストリビュータと 1 つ以上のセカンダリ リアルタイム ディストリビュータを含む、1 つのアドミン サイトの一部として設定できます。別のオプションとして、ローカル SQL データベースを持たず、SQL データベースとリアルタイム フィードについてはローカルでリアルタイム ディストリビュータをホームとする、クライアント アドミン ワークステーションを加えることもできます。

アドミン サイトを使用すると、Unified ICM Call Router が特定のサイトでサービスを提供する必要があるリアルタイム フィード クライアントの数を減らすことができます。これにより、WAN 接続を介してリモート アドミン ワークステーションをサポートするために必要な帯域幅を減らすことができるため、リモート サイトには利点があります。

アドミン サイトを使用しているときは、リアルタイム フィード用の Unified ICM Call Router に登録しているリアルタイム ディストリビュータがプライマリ リアルタイム ディストリビュータです。アドミン サイト内の他のリアルタイム ディストリビュータは、リアルタイム フィード用のプライマリ リアルタイム ディストリビュータに登録します。プライマリ リアルタイム ディストリビュータがダウンしたとき、またはセカンダリ リアルタイム ディストリビュータからの登録を受け入れない場合は、リアルタイム フィード用の Unified ICM Call Router に登録します。プライマリまたはセカンダリ リアルタイム ディストリビュータに登録できないクライアント AW は、これらのディストリビュータが復旧するまでアドミン ワークステーション タスクを実行できません。

代わりに、各リアルタイム ディストリビュータを、デバイスの物理的サイトにかかわらず、それ自身のアドミン サイトに展開することもできます。この展開では、複数のリアルタイム フィード クライアントを維持するために Unified ICM Call Router のオーバーヘッドが増大しますが、プライマリ リアルタイム ディストリビュータの障害によって、サイト内のセカンダリ リアルタイム ディストリビュータがダウンするのを防止できます。

また、マルチチャネル オプション（Cisco Email Manager オプションと Cisco Collaboration Server オプション）または Cisco Unified Contact Center Management Portal（Unified CCMP）の ConAPI インターフェイスを提供するためにアドミン ワークステーションが使用されている場合、Unified ICM、Cisco Email Manager、Cisco Collaboration Server、または Unified CCMP システムに行われた設定変更が、障害復旧まで ConAPI インターフェイスに渡されません。

CTI サーバ

CTI サーバは、Agent PG 上の Unified CM PIM のデータ トラフィックで、特定の CTI メッセージ（コール呼び出しイベントやオフフック イベントなど）を監視し、これらのメッセージを CTI OS サーバや Cisco Agent Desktop Enterprise サーバなどの CTI クライアントに提供します。また、CTI クライアントからのサードパーティ コール制御メッセージ（コール発信やコール応答など）を処理し、これらのメッセージを PG の PIM インターフェイス経由で Unified CM に送り、エージェント デスクトップに代わってイベントを処理します。

CTI サーバは冗長構成で、Agent PG サーバ上に共存します（図 3-25 を参照）。ただし、障害発生時にエージェントの状態を保持することはできません。CTI サーバの障害発生時には、冗長 CTI サーバがアクティブになり、コール イベントの処理を開始します。CTI OS サーバは、CTI サーバのクライアントであり、二重化された環境内の両 CTI サーバを監視し、フェールオーバー処理中にエージェントの状態を保持するように設計されています。CTI サーバのダウン中に CTI OS エージェントがタスクを実行しないように、フェールオーバー中は、CTI OS エージェントに対してデスクトップ ボタンがグレーで表示されます。これらのボタンは、冗長 CTI サーバが復旧するとただちに復旧します。エージェントがデスクトップ アプリケーションにログインし直す必要はありません。

CTI サーバは、Unified Outbound Option だけでなく、マルチチャネル オプション（Cisco Email Manager と Cisco Content Server）の動作にも重要です。二重エージェント ペリフェラル ゲートウェイ ペアの両サイドで CTI サーバがダウンすると、これらのアプリケーションにログインできるエージェント ペリフェラル ゲートウェイがなくなります。

図 3-25 Agent PG 上に共存する冗長 CTI サーバ

親/子コンポーネント

次の項では、Unified ICM Enterprise（親）と Unified CCE システム（子）の展開で使用されるコンポーネントについて説明します。

Unified ICM Enterprise（親）データ センター

Unified ICM 親データ センター ロケーションには Unified ICM セントラル コントローラが含まれています。図 3-27 では、これは Rogger の冗長（二重）ペアとして示されています。これは、Call Router サーバおよび Logger サーバを組み合せたものです。大規模な展開において必要であれば、Call Router サーバと Logger サーバを別々に展開することも可能です。また、これらのサーバが地理的に分散されるよう異なる 2 つのデータ センターに展開して、耐障害性をさらに高めることも可能です。

Unified ICM Rogger はデータ センター ロケーションのペリフェラル ゲートウェイを制御します。図 3-27 では、アーキテクチャ内の Unified CVP の制御に使用される IVR PG の冗長（二重）ペアは 1 組だけです。Unified CCE への移行時や、TDM またはレガシー ACD を引き続き使用するアウトソースのロケーションをサポートする場合などは、このレイヤにさらに PG を追加して、TDM またはレガシー ACD および IVR を制御することも可能です。このレベルの親 Unified ICM では、AT&T、Sprint、MCI などの IXC（inter-exchange carrier; 中継キャリア）による標準のプレルーティングもサポートできるので、コールがまだキャリア ネットワーク内にあるときに、Unified ICM でコールの最適ターゲットを選択できます。

このモデルでは、親 Unified ICM は直接制御のエージェントをサポートするように設計されていません。つまり、この親 Unified ICM で Unified CM ペリフェラル ゲートウェイがインストールされる従来型の Unified CCE はサポートされません。すべてのエージェントは、親 Unified ICM システムの外部で制御される必要があります。

Unified CVP または IVR PG のペアは、Customer Voice Portal コール サーバを制御します。このサーバは、Unified ICM からの IVR PG コマンドを VoiceXML に変換し、その VoiceXML をリモート コンタクト センター サイトの音声ゲートウェイに送ります。これにより、データ センター ロケーションからのコールが、親ロケーションの CVP の制御でリモート コール センターに入ることが可能になります。親は全サイトにわたるコールのネットワーク キューを制御でき、エージェントが対応可能になるまで、サイトの音声ゲートウェイのキューにコールを保留します。

Unified Contact Center Express（CCX）コール センター（子）サイト

Unified Contact Center Express（CCX）コール センター ロケーションにはローカル Unified CM クラスタが含まれ、これにより、ローカル IP-PBX 機能と IP 電話およびローカル CVP 音声ゲートウェイのコール制御機能が提供されます。また、サイトに IP-ACD 機能を提供する、ローカル Unified CCX Server リリース 4.0 以上も使用可能です。Unified CCX サーバには Unified CCE Gateway PG がインストールされているので、このコンタクト センター サイトのサポートに必要なサーバの数が削減されます。Unified CCE Gateway PG は親 Unified ICM データ センター ロケーションの Unified ICM Call Router（Rogger）に WAN 経由で接続し、リアルタイムのイベント データとエージェント状態を Unified CCX から親に提供します。Unified CCE Gateway PG は設定データ（スキル グループ、CSQ、サービス、アプリケーションなど）も取得して、親 Unified ICM 設定データベースに送ります。

このサイトに Unified CCX サーバをさらに追加して、冗長 Unified CCX サーバ、履歴レポーティング データベース サービス、記録および監視サーバ、ASR/TTS サーバとして使用することも可能です。

Unified CCE コール センター（子）サイト

Unified CCE コール センター ロケーションにはローカル Unified CM クラスタが含まれ、これにより、ローカル IP-PBX 機能と IP 電話およびローカル CVP 音声ゲートウェイのコール制御機能が提供されます。また、ローカル Unified IP IVR があり、Unified CCE サイトにローカル コール キューイング機能が提供されます。Unified CCE Gateway PG の冗長ペアは、Unified ICM 親データ センター ロケーションの Unified ICM 親 Call Router（Rogger）に WAN 経由でこのサイトを接続するのに使用され、さらに、リアルタイムのイベント データとエージェント状態を子 Unified CCE から親に提供するのに使用されています。Unified CCE Gateway PG は設定データ（スキル グループ、サービス、コール タイプなど）も取得して、親 Unified ICM 設定データベースに送ります。

Unified CCE 7.5（ x ）では、子サイトの IP-IVR を Unified CVP インスタンスと置き換えることができます。Unified CVP は、Agent Controller の System PG の一部として統合されていません。つまり、Unified CVP を使用する System CCE のインストールの一部として Unified CVP 用に別の IVR PG が定義されています。Unified CVP は System PG には含まれていないため、Unified CVP のキューに入っているコールや処理中のコールは、Unified CCE Gateway PG をとおして親 ICM に報告されません。

ローカル Unified CCE 子システムは IP-ACD 機能を提供するために使用されます。このシステムの規模は、採用する展開タイプをもとに決定できます。

• Progger の構成

Unified CCE コンポーネントを含む単一（または二重）サーバ：Call Router と Logger、Unified CM の System PG と IP IVR、CTI サーバと CTI OS サーバ、およびオプションの Unified CVP コントローラ。

• Unified CCE Agent Controller を別にする Rogger 構成（System PG とオプションの Unified CVP コントローラおよび CTI/CTI OS サーバ）

Unified CCE コンポーネントを含む Rogger 構成：二重化構成のセントラル コントローラの単一セットとしての Call Router と Logger、および Unified CM の System PG と IP IVR、CTI サーバと CTI OS サーバ、オプションで Unified CVP コントローラを含む二重サーバの別のエージェント コントローラセット。

（注） Unified CCE 7.5（x）では、アウトバウンド コントローラをエージェント コントローラにインストールして、ダイヤラとメディア ルーティング（MR）PGを同じサーバに追加することもできます。

これらの構成のキャパシティの詳細については、「Unified CCE のコンポーネントとサーバのサイジング」を参照してください。

どちらの構成でも、Historical Database Server オプションと同様に、独立したアドミン ワークステーション サーバを用意して、このシステムに Web ベースのレポーティング ツール（WebView)、設定ツール（WebConfig）、スクリプト作成ツール（Internet Script Editor）をホスティングする必要があります。

（注） Cisco Agent Desktop（CAD）は、子 Unified System CCE とともに使用できます。

親/子コール フロー

次の項では、親と子のコール フローについて説明します。

一般的なインバウンド PSTN コール フロー

PSTN からの一般的なインバウンド コール フローでは、あらかじめ定義されたパーセント配分や自動ルーティング方式を使用して、キャリア ネットワークによってコールがコンタクト センター サイトに誘導されます。これらのコールは、Unified ICM 親 CVP による制御のもとで、コール センター ロケーションの CVP 音声ゲートウェイで終端されます。インバウンドのコール フローは、次のようになります。

1. コールが Unified CCE コール センター ロケーションの CVP 音声ゲートウェイに着信します。

2. CVP 音声ゲートウェイは、着信番号をもとにコールを Unified ICM 親サイトの特定の CVP コール サーバにマップします。新規コール イベントをその CVP コール サーバに送ります。

3. CVP コール サーバは新規コール イベント メッセージを、Unified ICM 親サイトの CVP または IVR PG に送ります。

4. CVP PG が親 Unified ICM に新規コール メッセージを送ります。親 Unified ICM はインバウンド着信番号を使用して、そのコールに対する適切なコール処理（メッセージング）またはエージェント グループを判別するためのルーティング スクリプトを決定します。

5. Unified ICM が CVP に、サイトで音声ゲートウェイにコールを保留して、エージェントが空くまで待機するよう指示します。この間、ゲートウェイ内の保留音楽（.wav ファイル）を発信者に流す指示を送ります。

6. エージェントが対応可能になると、Unified ICM が CVP に、トランスレーション ルートを使用して対応可能なエージェントのいるサイトにコールを転送するよう指示します。（同じ物理サイトではなく、WAN を経由したサイトにエージェントがいる場合もあります）Unified ICM 親 CVP で収集されたコール関連のデータは、リモート システムの PG（TDM、レガシー PG、または Unified CCX/Unified CCE の Unified CCE Gateway PG）に転送されます。

7. ターゲット サイトへの着信時、コールは親 Unified ICM によって選択された特定のトランスレーション ルート DNIS に着信します。ターゲット サイトの PG では、コールに関連付けられたプレコール CTI データと照合するために、この DNIS にコールが着信することが期待されています。ローカル ACD または Unified CCE は、コールの最終宛先（通常は、対応可能エージェントのスキル グループの Lead Number）と CTI データを要求するために、ローカル PG にポストルート要求を行います。

8. エージェントがコールに対応できない場合（退席またはプラグを抜いた）、親サイトの Unified CVP は　ICM コール ルーティング スクリプトでルータ再クエリー機能を使用して、コールに別のターゲットを自動的に選択します。

ポストルートのコール フロー

ポストルーティングは、ペリフェラル ACD または IVR に着信しているコールを、別のエージェントやロケーションに臨機応変にルーティングする必要がある場合に使用されます。受け取った ACD または Unified CCE のコールを他のスキル グループまたはロケーションに送る必要がある場合、エージェントはポストルート機能を使用してそのコールを再ルーティングできます。ポストルートのコール フローは、次のようになります。

1. 再ルーティング処理を行うため、エージェントが CTI エージェント デスクトップを使用してコールをローカル CTI ルート ポイントに転送します。

2. 再ルーティング アプリケーションまたはスクリプトが、ローカル Unified CCE Gateway PG 接続をとおして、親 Unified ICM にポストルート要求を行います。

3. 親 Unified ICM が、Unified CCE からの CTI ルート ポイントを着信番号としてマッピングし、その番号を使用してルーティング スクリプトを選択します。コールを別のサイト、同じサイトの別のスキル グループ、または CVP ノード（キューに入れるため）に移動するためのラベルまたはルーティング指示が、スクリプトから返されます。

4. Unified CCE が Unified ICM 親システムからのポストルート応答を受け取ります。受け取ったルーティング ラベルを転送番号として使用し、コールを次の宛先に送ります。

親/子の耐障害性

親/子モデルには、サイトへの Unified CCX または Unified CCE の展開により、IP-ACD を完全に維持するための耐障害性があり、ローカル IP-PBX 機能、コール処理機能、キューイング機能が提供されています。

親 Unified ICM との WAN 接続を失った子 Unified CCE

Unified CCE 子サイトと親 Unified ICM 間の WAN に障害が発生すると、ローカル Unified CCE システムは親と Unified CVP 音声ゲートウェイから切断されてしまいます。サイトに着信するコールは、親 Unified ICM の制御下の CVP では処理されなくなるので、子の設定に応じて、次の機能をローカルで提供する必要があります。

• 子 Unified CCE で、ローカル IP IVR リソースを使用してキューイングと処理を行うように設定する場合、

– ローカル音声ゲートウェイでは、親 CVP コール サーバに接続できない場合、ダイヤル ピア文によってコールの制御をローカル Unified CM クラスタに渡す必要があります。また、ローカル Unified CM クラスタに、インバウンド DNIS または着信番号にマッピングされた CTI ルート ポイントを持たせる必要があります。親 CVP コール サーバに接続できない場合、ローカル音声ゲートウェイはこの CTI ルート ポイントを提示します。

– ローカル IP IVR では、適切な .wav ファイルとアプリケーションを置くように設定する必要があります。これらを Unified CCE 子システムからローカルで呼び出せるようにして、案内メッセージを再生するなどの基本的なコール処理が行われるようにします。

– 子 CCE ルーティング スクリプトにより、ローカル スキル グループのエージェントへのコールのキューイングを行い、IP IVR に、エージェントを待つ間キュー処理を行うように指示する必要があります。

– 通常であれば親 CVP または親 Unified ICM から提供されるデータ検索機能や外部 CTI アクセス機能をローカルで実現し、エージェントがルーティングやスクリーン ポップのためにカスタマー データに完全にアクセスできるようにします。

– この障害時には、ポストルーティング転送スクリプトに障害が発生するので、Unified CCE の設定でこの障害に対応するか、ポストルーティング スクリプトへのアクセスを禁止する必要があります。

• 子 Unified CCE で、ローカル Unified CVP リソースを使用して、Unified CCE 7.5 （x ）でのキューイングと処理を行うように設定する場合、

– ローカル音声ゲートウェイでは、ダイヤル ピア文によってコールの制御を子サイトにあるローカル Unified CVP コール サーバに渡す必要があります。また、これらのコールを子でローカルに処理するために、ローカル音声ゲートウェイによって子 CVP に提示されるインバウンド DNIS または着信番号を子 CCE に設定する必要があります。

– ローカル VXML ゲートウェイと CVP コール サーバでは、適切な .wav ファイルとアプリケーションを置くように設定する必要があります。これらを Unified CCE 子システムからローカルで呼び出せるようにして、案内メッセージを再生するなどの基本的なコール処理が行われるようにします。

– 子サイトにある CVP VXML サーバ（Web アプリケーション サーバ）を使用して、通常であれば親 ICM から提供されるセルフサービス アプリケーションまたは CVP Studio VXML アプリケーションを複製し、これらのアプリケーション用のダイナミック VXML を生成する必要があります。

– 子 CCE ルーティング スクリプトにより、ローカル スキル グループのエージェントへのコールのキューイングを行い、子サイトにあるローカル Unified CVP に、エージェントを待つ間キュー処理を行うように指示する必要があります。

– 通常であれば親 CVP または親 Unified ICM から提供されるデータ検索機能や外部 CTI アクセス機能をローカルで実現し、エージェントがコール ルーティングやスクリーン ポップのためにカスタマー データに完全にアクセスできるようにします。

– この障害時には、ポストルーティング転送スクリプトに障害が発生するので、Unified CCE の設定でこの障害に対応するか、ポストルーティング スクリプトへのアクセスを禁止する必要があります。

親 Unified ICM との WAN 接続を失った子 Unified Contact Center Express

Unified Contact Center Express（CCX）子サイトと親 Unified ICM 間の WAN に障害が発生すると、ローカル Unified CCX システムは親と Unified CVP 音声ゲートウェイから切断されてしまいます。サイトに着信するコールは、親 Unified ICM の制御下の Unified CVP では処理されなくなるので、次の機能をローカルで提供する必要があります。

• ローカル音声ゲートウェイでは、親 CVP コール サーバに接続できない場合、ダイヤル ピア文によってコールの制御をローカル Unified CM クラスタに渡す必要があります。

• Unified CCX JTAPI アプリケーションをこれらの CTI ルート ポイントにマッピングして、案内メッセージの再生などの一般的なインバウンド コール処理が行われるようにします。

• ローカル Contact Service Queue（CSQ）エージェントを待つ間、アプリケーションがコール キューイングやキュー処理を行う必要があります。

• 通常であれば親 CVP または親 Unified ICM から提供されるデータ検索機能や外部 CTI アクセス機能をローカルで実現し、エージェントがコール ルーティングやスクリーン ポップのためにカスタマー データに完全にアクセスできるようにします。

• この障害時には、ポストルーティング アプリケーションや転送スクリプトに障害が発生するので、Unified CCX の設定でこの障害に対応するか、ポストルート アプリケーションへのアクセスを禁止する必要があります。

親 CVP コール サーバによって制御されているローカル Unified CVP 入力音声ゲートウェイから Unified ICM 親 CVP コール サーバが見えない場合にも、同様の障害が発生します。前述のとおりローカル Unified CVP ゲートウェイは、コールを Unified CCE エージェントにルーティングするためローカル Unified CM（または子 CVP）にフェールオーバーするように設定されます。同様に、親 Unified ICM 全体に障害が発生した場合、サイトの親 CVP によって制御されているローカル音声ゲートウェイは親 Unified ICM からコール制御を受けなくなるので、コールはローカル サイトに転送されて処理されます。

Unified CCE Gateway PG に障害が発生した場合、または親 Unified ICM に接続できない場合

Unified CCE Gateway PG に障害が発生したため、または親 Unified ICM に接続できないために、ローカル エージェントが親 Unified ICM から対応可能として見なされなくなった場合でも、サイトへのインバウンド コールが Unified ICM 親 CVP の制御下にある場合があります。このとき親 Unified ICM は、リモート Unified CCE Gateway PG に障害が発生しているのか、実際の Unified CCE IP-ACD がローカルで障害を発生しているのか判断できません。

親 Unified ICM は、PG がオンラインに戻ってエージェント状態のレポーティングが再開されるまでの間、子サイトがダウンしているものと見なして、このサイトへのルーティングを自動的に回避します。別の方法として、Unified CM 上のローカル インバウンド CTI ルート ポイントを使用して、親 Unified ICM が Unified CCE IP-ACD サイトへ一定の割合のコールを転送することも可能です。この方法では、CVP からの CTI データなしでコールが引き継がれますが、Unified CCE システムでは、サイトがダウンしていない限り、ローカルにエージェントへのコールをルーティングできます。

ローカル Unified CCE 子システムに障害が発生した場合、Unified CCE Gateway PG もシステムに接続できなくなるので、親 Unified ICM ではすべてのエージェントがオフラインで対応不能であると見なされます。Unified CCE 子システムがダウンしているときに、ローカル Unified CM にコールが送られた場合、CTI ルート ポイントへのコールは Call-Forward-On-Failure 処理に引き継がれます。この方式では、コールが別のサイトまたは応答リソースにリダイレクトされ、エラーが発生しているので後から掛け直すことを発信者に求めるメッセージが再生されます。

親/子のレポーティングおよび設定の影響

子 Unified CCE が親 Unified ICM から切断されている間も、ローカル IP-ACD ではレポーティング データが収集されているので、ローカル ユーザは子ルーティング スクリプトや設定に変更を加えることができます。子サイトの Unified CCE Gateway PG はこれらのオブジェクトをキャッシュしてメモリ（最終的にはディスク）に格納し、親 Unified ICM が利用できるようになったときに親 Unified ICM に送信します。この機能は、Unified CCE Gateway PG が Unified CCE 子サイトに共存している場合にだけ利用できます。

親/子モデルに関するその他の注意事項

Unified Outbound Option、および Cisco Email Manager、Web Collaboration、EIM/WIM などのマルチチャネル コンポーネントは、親ではなく子 Unified CCE レベルでだけインストールすることが可能です。これらはサイトごとに、ノードでの実装として扱われます。