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

CTI Manager を冗長化するための Unified ICM の設定

二重 Cisco Unified CallManager モデルで Cisco Unified CallManager が CTI Manager のフェールオーバーをサポートするようにするには、次の手順を実行します。

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

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

ステップ 3 一方の CTI Manager を Cisco Unified CallManager PG のサイド A の JTAPI サービスに割り当てます（図3-7 を参照してください）。

ステップ 4 もう一方の CTI Manager を Cisco Unified CallManager PG のサイド B の JTAPI サービスに割り当てます（図3-7 を参照してください）。

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

Cisco Unified CallManager を使用した Unified IP IVR（CRS）のハイアベイラビリティ

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

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

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

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

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

Unified ICM を使用した Unified IP IVR（CRS）のハイアベイラビリティ

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

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

Cisco Unified CallManager の障害シナリオ

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

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

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

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

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

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

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

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

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

• 「シナリオ 3： プライマリ Cisco Unified CallManager サブスクライバだけに障害が発生する」

• 「シナリオ 4： Cisco Unified CallManager CTI Manager サービスだけに障害が発生する」

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

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

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

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

• Cisco Unified CallManager サブスクライバ A および B は、それぞれ独立したインスタンスの CTI Manager を実行している。

• Cisco Unified CallManager サブスクライバ A 上のすべてのソフトウェア サービス（コール処理、CTI Manager など）に障害が発生すると、すべての電話およびゲートウェイが Cisco Unified CallManager サブスクライバ B に登録し直される。

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

• PG および CTI サーバのフェールオーバー中に処理できないアクションや状態変更をエージェントが実行しないように、エージェント デスクトップでは変更ボタンがグレー表示される。 会議や転送の機能などのサードパーティ コール制御もグレー表示されます。

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

• エージェント デスクトップがサービスに復帰し、状態制御機能およびサードパーティ コール制御機能へのフルアクセスが再び可能になる。 ただし、エージェントが受信不可の状態のままになっている場合は、手動で受信可能状態に戻す必要があります（この動作は設定で変更できます）。

• フェールオーバー時にアクティブ コールがあったエージェントについては、すべてのコールから接続解除されたときに、エージェントのデスクトップ機能がフェールオーバー前と同じ状態に復元され、IP 電話がバックアップ Cisco Unified CallManager サブスクライバ B に登録し直される。

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

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

• この障害が発生している間、Unified CC エージェントの接続中のコールはすべてアクティブのまま。ただし、アクティブのサブスクライバに電話が登録し直されるまで、エージェントは、会議、転送、またはその他の Cisco Unified CallManager 機能を実行できません。 コールが完了すると、電話はバックアップ Cisco Unified CallManager サブスクライバに自動的に登録し直されます。

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

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

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

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

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

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

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

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

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

• 接続中のコールのあるエージェントではそのまま継続されるが、エージェント デスクトップ ソフトフォンでサードパーティ コール制御（会議、転送など）は使用できない。エージェントがすべてのコールから接続解除されると、このエージェントのデスクトップ機能がフェールオーバー前と同じ状態に復元されます。

• PG のサイド A が復旧しても、PG のサイド B がアクティブなままで、Cisco Unified CallManager サブスクライバ B 上の CTI Manager が使用される。

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

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

図3-19 は Cisco Unified CallManager サブスクライバ A 上の障害を示しています。 CTI Manager サービスが Cisco Unified CallManager サブスクライバ C および D で動作しており、Cisco Unified CallManager サブスクライバ C 上の CTI Manager が CallManager Peripheral Gateway（PG; ペリフェラル ゲートウェイ）サイド A にアクティブで接続しています。 ところが、すべての電話とゲートウェイは Cisco Unified CallManager サブスクライバ A に登録されています。 すべての電話とデバイスが個々に、バックアップ Cisco Unified CallManager サブスクライバ B に登録し直されます。 デバイスが使用されている場合（コール中の電話）は、使用が終わるとバックアップの Cisco Unified CallManager サブスクライバ B に登録されます。

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

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

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

• Cisco Unified CallManager サブスクライバ C および D では、それぞれローカルのインスタンスの CTI Manager が実行されている。

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

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

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

• アクティブ コールのあるエージェントは、コールが完了するまで接続状態が維持される。ただし、フェールオーバー中の会議、転送、またはその他のサードパーティ コール制御を防ぐため、エージェント デスクトップはディセーブルにされます。 エージェントがアクティブ コールを接続解除すると、このエージェントの電話がバックアップ サブスクライバに再登録され、エージェント デスクトップ機能がフェールオーバー前と同じ状態に復元されます。

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

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

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

シナリオ 4： Cisco Unified CallManager CTI Manager サービスだけに障害が発生する

図3-20 は、Cisco Unified CallManager サブスクライバ C 上の CTI Manager サービスの障害を示しています。 CTI Manager サービスが Cisco Unified CallManager サブスクライバ C および D で動作しており、Cisco Unified CallManager サブスクライバ C が Unified CC ペリフェラル ゲートウェイ サイド A に接続されているアクティブな CTI Manager です。 ただし、すべての電話およびゲートウェイが Cisco Unified CallManager サブスクライバ A に登録されています。この障害発生中、CTI Manager と PG の両方がそれぞれのセカンダリ サイドにフェールオーバーします。 PG のサイド B 上の JTAPI サービスがすでにセカンダリ（現時点でのプライマリ）CTI Manager にログインしているため、PG のサイド B 上の JTAPI サービスが CTI Manager にログインする必要がある場合に比べて、デバイスの登録および初期化時間が著しく短くなります。

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

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

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

• Cisco Unified CallManager サブスクライバ C および D では、それぞれローカルのインスタンスの CTI Manager が実行されている。

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

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

• 接続中のコールのあるエージェントではそのまま継続されるが、エージェント デスクトップ ソフトフォンでサードパーティ コール制御（会議、転送など）は使用できない。エージェントがすべてのコールから接続解除されると、このエージェントのデスクトップ機能がフェールオーバー前と同じ状態に復元されます。

• サブスクライバ C 上の Cisco Unified CallManager CTI Manager サービスが復旧しても、PG のサイド B がアクティブであり続け、Cisco Unified CallManager サブスクライバ D 上の CTI Manager サービスが使用される。

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

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

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

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

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

• 「シナリオ 2： ビジブル ネットワークに障害が発生する」

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

• 「シナリオ 4： Unified MA ロケーション WAN（ビジブル ネットワーク）に障害が発生する」

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

Unified CC における WAN 経由のクラスタリングでは、システムの両サイドで状態および同期を維持するために、地理的に分散したセントラル コントローラ（Call Router/Logger）とペリフェラル ゲートウェイ ペアの間で、専用の、独立したプライベート ネットワーク接続が必要です。また、リンクのヘルス検証のため、TCP キープアライブ メッセージが生成されます。 Unified ICM は、TCP キープアライブ メッセージを使用してプライベート リンクの障害を検出します。 TCP キープアライブ メッセージが 5 回連続して検出されない場合、リンクまたはリモート パートナー システムに障害が発生した可能性があることが Unified ICM に通知されます。

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

• Call Router で、TCP キープアライブ メッセージが 5 回連続して検出されないことにより障害が検出される。 両 Call Router がペリフェラル ゲートウェイに test-other-side（TOS）メッセージを送ります。これは PG1A から始まり、次に PG1B、次に PG2A と続きます。 この TOS メッセージは、ペリフェラル ゲートウェイに、反対サイドの Call Router を認識しているかどうかチェックするように要求するもので、これによって障害がネットワーク障害か冗長ペア サーバの障害かを判別します。

• Call Router では TOS メッセージに対する PG の応答から、Call Router ペアのどちらのサイドで、より多くのペリフェラル ゲートウェイのアクティブ接続が確認されたかが判別される。 ペリフェラル ゲートウェイのアクティブ接続を多く確認したサイドがシンプレックス モードのアクティブ Call Router として機能し続けます。冗長 Call Router はディセーブルにされます。

• すべてのペリフェラル ゲートウェイで、ビジブル ネットワーク内のアクティブ Call Router にアクティブ データ フィードが割り当て直される。フェールオーバーやサービスの喪失は発生しません。

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

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

• ペリフェラル ゲートウェイの両サイドで、TCP キープアライブ メッセージが 5 回連続して検出されないことにより障害が検出される。 両ペリフェラル ゲートウェイが、Cisco Unified CallManager クラスタへのアクティブな接続が存在する方のサイドを確認します。

• Cisco Unified CallManager クラスタにアクティブに接続されていたサイドのペリフェラル ゲートウェイが、アクティブ サイドとしてシンプレックス モードで機能し続ける。 もう一方のサイドは、プライベート ネットワーク接続が復旧するまで非アクティブです。

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

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

シナリオ 2： ビジブル ネットワークに障害が発生する

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

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

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

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

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

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

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

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

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

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

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

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

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

正常な動作では、CTI Toolkit Agent Desktop（および Cisco 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 コンフィギュレーション マネージャで Cisco Unified CallManager ペリフェラル ゲートウェイに定義された /LOAD パラメータによっては、エージェントがログアウトして受信不可状態になる場合があります）。

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

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

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

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

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

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

• ペリフェラル ゲートウェイが、アクティブ Cisco Unified CallManager 接続のあるサイドを判別します。 ただしこの際、Call Router の状態も考慮されます。ペリフェラル ゲートウェイは、アクティブ Call Router に接続できない場合は非アクティブになります。

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

• Call Router が認識できるのが、ローカル ペリフェラル ゲートウェイだけになります。ローカル ペリフェラル ゲートウェイとは、ローカル Unified IP IVR または Unified CVP ポートの制御に使用されるペリフェラル ゲートウェイで、CallManager ペリフェラル ゲートウェイ ペアのローカル側です。 リモート Unified IP IVR または Unified CVP ペリフェラル ゲートウェイがオフラインになり、Unified ICM コール ルーティング スクリプトで（peripheral on-line ステータス チェックを使用して）これらをアウト オブ サービスにします。これらのデバイスで接続中のコールは強制的に接続解除されます（Unified CVP は障害発生時にコールをリダイレクトできます）。

• 無効になったサイドに到着した新規コールは、Unified CC によってルーティングされませんが、Cisco Unified CallManager の標準の障害時リダイレクトを使用して CTI ルート ポイントにリダイレクトまたは処理されます。

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

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

シナリオ 4： Unified MA ロケーション WAN（ビジブル ネットワーク）に障害が発生する

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

Unified MA ロケーションの WAN のサイド A に障害が発生した場合は、次の状況が当てはまります。

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

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

Unified MA ロケーションの WAN の両サイドに障害が発生した場合は、次の状況が当てはまります。

• ローカル音声ゲートウェイが、Cisco Unified CallManager クラスタへの通信経路の障害を検出し、ローカル ダイヤルトーン機能を確保するために SRST モードになります。

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

Cisco Unified CallManager サービス

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

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

アクティブ Cisco Unified CallManager サブスクライバに障害が発生すると、エージェント デスクトップに、エージェントが「受信不可」にされたものとして表示されます。これらの IP 電話には、電話がオフラインになったことを示すメッセージが表示され、電話がバックアップ Cisco Unified CallManager サブスクライバにフェールオーバーするまで、すべての IP 電話のソフト キーがグレー表示されます。 コールを受信し続けるには、エージェントの電話がバックアップ Cisco Unified CallManager サブスクライバに登録され、CTI サーバによってデスクトップ機能が Cisco Unified CallManager サービス障害発生前の状態に復旧するまで、エージェントが待機する必要があります。 プライマリ Cisco Unified CallManager サブスクライバが復旧すると、エージェント電話が元のサブスクライバに再登録されて、クラスタが通常の状態に戻ります。電話とデバイスは複数のアクティブ サブスクライバ間で適切にバランス調整されます。

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

Unified IP IVR（CRS）

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

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

Unified ICM

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

前述したように、この章で説明するすべての冗長 Unified ICM サーバは、同一サイトに設置してローカル プライベート LAN またはクロスケーブルで接続する必要があります。 プライベート LAN を構築するには、セカンド Network Interface Card（NIC; ネットワーク インターフェイス カード）をインストールし、クロスケーブルで接続します。 これにより、すべての外部ネットワーク機器障害を排除できます。

Cisco Unified CallManager PG と CTI Manager サービス

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

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

CTI Manager サービスまたは PG のフェールオーバーが完了すると、エージェントは前の状態に戻ります。 この時点でエージェントは、コールのリリース、転送、または会議も行えるようになります。

Unified ICM VRU PG

Voice Response Unit（VRU; 音声応答装置）PG に障害が発生すると、この Unified IP IVR（CRS）上のキューに入っているコールまたは処理中のコールがすべてドロップされます。 Unified CVP でキューに入っているコールはドロップされず、H.323 ダイヤル プラン内のセカンダリ CVP または番号（利用可能な場合）にリダイレクトされます。 冗長（二重）VRU PG サイドが Unified IP IVR（CRS）または CVP に接続し、フェールオーバーと同時にコール処理を開始します。 障害が発生した VRU PG サイドが復旧すると、現在実行中の VRU PG がアクティブ VRU PG として稼働し続けます。 したがって、冗長 VRU PG を用意することは非常に有益です。なぜなら、IP IVR または CVP がアクティブ キュー ポイントとして機能し続け、コール処理を継続することが可能になるからです。 VRU PG の冗長性がない場合、VRU PG に障害が発生したときに、IP IVR が適切に機能していていも、IP IVR を使用できなくなります（図3-21を参照してください）。

図3-21 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 が、反対サイドの Call Router がまだ稼働しているかどうか、およびどちらのサイドをアクティブにするかを判別するため、PG に Test Other Side メッセージを送信します。 PG からのメッセージに基づき、最もアクティブな PG 接続が存在していた Call Router がシンプレックス モードでアクティブであり続け、反対サイドの Call Router はプライベート ネットワークが復旧するまでアイドルになります。

• Call Router ハードウェア障害：反対サイドの Call Router に物理ハードウェア障害があり、完全にアウト オブ サービスになっている可能性があります。 この場合は、残った Call Router だけが Test Other Side メッセージを使用してペリフェラル ゲートウェイと通信します。 ペリフェラル ゲートウェイが反対サイドの 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 OUTD を使用している場合は、1 つの Logger プラットフォーム（通常 Logger A）だけに Campaign Manager ソフトウェアがロードされます。 このプラットフォームがアウト オブ サービスの場合は、Logger が稼働状態に復旧可能になるまでアウトバウンド コールが停止されます。

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

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

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

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

アドミン ワークステーション リアルタイム ディストリビュータは、エンタープライズ全体の Unified CC に関するリアルタイム情報を提供する、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 オプション）の ConAPI インターフェイスを提供するためにアドミン ワークステーションが使用されている場合、Unified ICM、Cisco Email Manager、または Cisco Collaboration Server システムに行われた設定変更が、障害復旧まで ConAPI インターフェイスに渡されません。

CTI サーバ

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

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

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

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

親/子コンポーネント

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

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

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

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

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

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

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

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

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

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

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

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

• Progger の構成

Unified CC コンポーネントを含む単一（または二重）サーバ： Call Router および Logger、Cisco Unified CallManager および IP IVR Queue Manager 用の PG、CTI サーバ、CTI OS サーバ。

• Unified CC Agent Controller を別にする Rogger 構成

Unified CC コンポーネントを含む単一（または二重）サーバとして構成された Rogger： Call Router および Logger、CallManager および IP IVR Queue Manager 用の PG、CTI サーバ、CTI OS サーバを含む独立した Unified CC Agent Controller（単一または二重）サーバ。

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

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

（注） CTI OS の代わりに、子 Unified CCE の一部として Cisco Agent Desktop（CAD）を使用することも可能です。

親/子コール フロー

次のセクションでは、親と子のコール フローについて説明します。

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

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

1. コールが Unified CC コール センター ロケーションの 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 CC Gateway PG）に転送されます。

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

8. エージェントがコールに対応できない場合（退席またはプラグを抜いた）、コールはローカル ACD または Unified CC に残ります。この場合、システムでコールをローカル キューに再ルーティングして、ネクスト アベイラブル エージェントを待つ必要があります。 コールをポストルートして親 Unified ICM に戻し、他のロケーションのエージェントを待つように CVP のキューに入れることも可能です。

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

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

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

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

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

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

親/子の耐障害性

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

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

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

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

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

Unified CCX の場合

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

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

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

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

Unified CCE の場合

• インバウンド コールをローカルで受けて処理するために、Unified ICM では、着信番号を CTI ルート ポイントにマッピングするように設定する必要があります。 これらの番号はコール ルーティング スクリプトにマッピングされている必要があります。このスクリプトはコールをローカル Unified IP IVR または Unified QM で処理するようにトランスレーション ルーティングします。

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

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

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

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

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

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

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

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

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

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

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

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

親/子モデルでは、Unified CC 子システムが子レベルでローカル CVP を使用することは許可されません。 CVP を使用してシステム全体のネットワーク キューイングを実行できるのは、親だけです。 Unified OUTD および Cisco Email Manager や Web Collaboration などのマルチチャネル コンポーネントは、親ではなく子 Unified CC レベルでだけインストールすることが可能です。 これらはサイトごとに、ノードでの実装として扱われます。