Cisco IP Contact Center Enterprise Edition ネットワーク デザイン(SRND) Releases 5.0/6.0

アベイラビリティを高めるための設計上の注意点

---

この章では、IPCC フェールオーバーで可能性がある複数のシナリオを示し、それぞれのシナリオでシステム機能の高アベイラビリティを確保するための、設計上の注意点を説明します。この章の内容は、次のとおりです。

• 「アベイラビリティを高める設計」

• 「データ ネットワークに関する設計上の注意点」

• 「Cisco CallManager と CTI Manager に関する設計上の注意点」

• 「IP IVR（CRS）に関する設計上の注意点」

• 「Internet Service Node（ISN）に関する設計上の注意点」

• 「マルチチャネルに関する設計上の注意点（Cisco Email Manager オプションおよび Cisco Collaboration Server オプション）」

• 「Cisco Email Manager オプション」

• 「Cisco Collaboration Server オプション」

• 「Cisco IPCC アウトバウンド オプションに関する設計上の注意点」

• 「ペリフェラル ゲートウェイに関する設計上の注意点」

• 「障害リカバリの理解」

• 「CTI OS に関する考慮事項」

• 「Cisco Agent Desktop に関する考慮事項」

• 「その他の考慮事項」

アベイラビリティを高める設計

Cisco IPCC は、多数のハードウェアおよびソフトウェア コンポーネントを使用する分散型ソリューションです。障害が発生した場合に影響を受けるコール センター内のリソースが最小限になるように、各展開を設計することが重要です。ネットワーク インフラストラクチャを含むさまざまな IPCC コンポーネントに関する要件がどの程度厳しいのか、またどのような設計特性を選択するのかによって、障害発生時に影響を受けるリソースのタイプと数は異なります。IPCC 設計が優れていれば、ほとんどの障害（この項で定義します）に耐えることができます。ただし、すべての障害を見通すことは不可能です。

Cisco IPCC は、ミッション クリティカルなコール センター用に設計された、洗練されたソリューションです。IPCC の展開が成功するには、データおよび音声のインターネットワーキング、システム管理、および IPCC アプリケーション設定に関する豊富な経験を持ったチームが必要です。

展開サイクルの後半になってアップグレードやメンテナンスに不要なコストがかかるのを防ぐため、IPCC を実装する前に慎重な準備と設計プランニングを行ってください。設計にあたっては、考えられる最悪の障害シナリオを考慮すると同時に、将来のスケーラビリティをすべての IPCC サイトについて考慮してください。

つまりこのガイドと、次の URL にある『 Cisco IP Telephony Solution Reference Network Design (SRND) 』ガイドの設計ガイドラインと推奨事項に従い、慎重にプランニングしてください。

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

IPCC ソリューションのプランニングと設計に関する支援については、シスコおよび認定パートナーの Systems Engineer（SE; システム エンジニア）にお問い合せください。

図3-1 は、耐障害 IPCC 単一サイト展開の高度な設計です。

図3-1 高アベイラビリティのための IPCC 単一サイト設計

図3-1 では、IPCC サイトの各コンポーネントが冗長化され、IPCC エージェントとその電話への Intermediate Distribution Frame（IDF）スイッチ以外は、すべてのプライマリおよびバックアップ サーバに接続されています。IDF スイッチは相互接続されておらず、Main Distribution Frame（MDF）スイッチにだけ接続されています。これは、複数の IDF スイッチにエージェントを分散する方が、ロード バランシングや地理的な（建物の各階同士や都市同士などの）分離のために有利であるためです。1 つの IDF スイッチに障害が発生しても、独立した IDF スイッチ内の他の利用可能なエージェントまたは IP IVR（CRS）キューに、すべてのコールがルーティングされます。次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』に記載された、単一サイト展開に関する設計推奨事項に従ってください。

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

高アベイラビリティとロード バランシングに関する設計が正しい場合、どの IPCC サイトも、システムの半分が失われても稼働を継続できます。このタイプの設計では、IPCC サイトで何が発生しても、各コールは次のいずれかの方法で処理されます。

• 利用可能な IPCC エージェントによってルーティングおよび応答される

• 利用可能な IP IVR（CRS）または ISN ポートに送られる

• Cisco CallManager AutoAttendant によって応答される

• コール センターで技術的問題が発生していることを伝え、後で掛け直すよう求める IP IVR（CRS）または ISN アナウンスによって応答される

図3-1 のコンポーネントは、図3-2 に示すように、2 つの接続された IPCC サイトを形成するように構成し直すことができます。

図3-2 IPCC 単一サイト冗長性

図3-2 は、図3-1 の単一サイト設計の冗長性を強調したものです。サイド A とサイド B は基本的に互いの鏡像になっています。実際、高アベイラビリティを向上するための、IPCC の主要機能の 1 つは、サイトを非冗長サイトから冗長サイトに変換するシンプルなメカニズムです。IPCC 高アベイラビリティを実装するには、最初のサイドを複製し、すべての対応パート同士を相互接続するだけで済みます。

以降の項では、IPCC を高アベイラビリティに設計する際に考慮が必要な問題と機能について、図3-1 をモデル設計として使用しながら説明します。これらの項では、それぞれ独立した段階として展開できる複数セグメントに設計を分割した、（ネットワーク モデルの視点からの、物理層を始点とする）ボトムアップ モデルを使用します。

高アベイラビリティが必要な IPCC 展開には、二重化（冗長化）した Cisco CallManager、IP-IVR/ISN、および ICM 構成だけを使用することをお勧めします。この章では、IPCC フェールオーバー機能がすべての展開における必須要件であるとみなし、各 Cisco CallManager クラスタに 1 つ以上のパブリッシャとサブスクライバを置いた、冗長（二重）Cisco CallManager 構成を使用する展開だけを示します。また可能な場合は、Cisco CallManager パブリッシャではデバイスもコール処理も CTI Manager サービスも実行しないという、ベスト プラクティスに従って展開してください。

データ ネットワークに関する設計上の注意点

図3-3 の IPCC 設計は、Time Division Multiplexing（TDM; 時分割多重）コール アクセス ポイントから始まり、コールが IPCC エージェントに到達する場所で終わります。この設計におけるネットワーク インフラストラクチャの底部では、データおよび音声トラフィック用 IPCC 環境がサポートされます。公衆電話交換網（PSTN）を含むネットワークが、IPCC ソリューションの基礎です。ネットワークにおける障害処理の設計が不十分な場合、すべてのサーバおよびネットワーク デバイスがネットワークに依存して通信することになるため、コール センター内のすべてが障害の可能性にさらされます。したがって、データおよび音声ネットワークはソリューション設計の最重要部分とし、すべての IPCC 実装の第一段階とする必要があります。

また、展開に使用する音声ゲートウェイの選択も重要です。これは、プロトコルによってコール復元力が異なるためです。この章では、Cisco CallManager クラスタにおける高アベイラビリティのための、音声ゲートウェイの構成方法に焦点を当てます。

音声ゲートウェイおよび音声ネットワーク一般については、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』ガイドを参照してください。

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

図3-3 2 つの音声ゲートウェイと 1 つの Cisco CallManager クラスタを持つネットワークにおける高アベイラビリティ

複数の音声ゲートウェイを使用すると、1 つのゲートウェイの障害ですべてのコールが遮断される問題を回避できます。2 つの音声ゲートウェイと 1 つの Cisco CallManager クラスタによる構成では、クラスタ内の各 Cisco CallManager にワークロードを分散するため、各ゲートウェイを別々のプライマリ Cisco CallManager に登録する必要があります。各ゲートウェイのプライマリ Cisco CallManager に障害が発生した場合は、もう一方の Cisco CallManager がバックアップとして使用されます。バックアップ用の Cisco CallManager 冗長グループの設定については、『Cisco IP Telephony Solution Reference Network Design (SRND)』（ http://www.cisco.com/go/srnd ）を参照してください。

公衆電話交換網（PSTN）からのトランク数を決める際は、一部の音声ゲートウェイに障害が発生しても最大 Busy Hour Call Attempts（BHCA; 最頻時発呼数）を処理できるように計算してください。設計段階で、まずそのサイトで許容可能な音声ゲートウェイ障害の最大同時発生数を決めます。この要件と、使用する音声ゲートウェイの数、およびこれらの音声ゲートウェイにまたがるトランクの配置から、必要なトランクの数を求めることができます。トランクを複数の音声ゲートウェイに分散するほど、必要なトランクは少なくなります。ただし、使用する音声ゲートウェイを増やすと、このコンポーネントのコストが増大します。このため、トランクの年間オペレーティング コスト（公衆電話交換網プロバイダーに支払う料金）と、音声ゲートウェイを導入する際の固定コストを比較する必要があります。

たとえば、コール センターの最大 BHCA から 4 つの T1 回線が必要であり、会社の要件として、1 つのコンポーネント（音声ゲートウェイ）の障害で遮断されるコールがゼロである必要がある場合を考えます。このケースで 2 つの音声ゲートウェイを展開する場合は、各音声ゲートウェイに 4 つ（合計 8 つ）の T1 回線をプロビジョニングする必要があります。3 つの音声ゲートウェイを展開する場合は、音声ゲートウェイ 1 つにつき 2 つ（合計 6 つ）の T1 回線で、同じレベルのアベイラビリティが得られます。5 つの音声ゲートウェイを展開する場合は、音声ゲートウェイ 1 つにつき 1 つ（合計 5 つ）の T1 回線で、同じレベルのアベイラビリティが得られます。したがって、音声ゲートウェイを増やすほど、必要な T1 回線の数が減少します。

T1 回線を減らすことによる運用コストの削減額は、音声ゲートウェイを追加する際の資本コストより大きい場合があります。最も費用効果の高いソリューションを設計するには、T1 回線の経常運用コストに加えて、T1 回線設置時のコストも計算に入れる必要があります。アベイラビリティ要件とコスト メトリックはケースごとに異なりますが、複数の音声ゲートウェイを使用する方が費用効果が高くなるケースは少なくありません。したがって、設計にあたってはこのコスト比較を実施することをお勧めします。

必要なトランク数が決定したら、PSTN サービス プロバイダーは、すべての音声ゲートウェイ（または、少なくとも複数の音声ゲートウェイ）に接続されたトランクにコールが終端されるように、トランクを構成する必要があります。PSTN から見ると、複数の音声ゲートウェイに接続されるトランクが 1 つの大きなトランク グループとして構成される場合、1 つの音声ゲートウェイに障害が発生すると、残った音声ゲートウェイにすべてのコールが自動的にルーティングされることになります。PSTN 内部ですべてのトランクが 1 つのトランク グループにグループ化されていない場合は、すべてのダイヤル番号について、他のトランク グループへの PSTN 再ルーティングまたはオーバーフロー ルーティングが設定されるようにする必要があります。

デジタル インターフェイス（T1 または E1）を持つ音声ゲートウェイに障害が発生すると、PSTN ではその音声ゲートウェイへのコールの送信が自動的に停止されます。これは、デジタル回線上の物理層の信号がドロップするためです。物理層の信号が失われると、PSTN ではそのデジタル回線上のすべてのトランクがビジー アウトされるため、障害が発生した音声ゲートウェイに PSTN が新規コールをルーティングしなくなります。障害が発生した音声ゲートウェイがオンラインに復帰し、回線が復旧すると、PSTN はその音声ゲートウェイへのコールの送信を自動的に再開します。

音声ゲートウェイはプライマリ Cisco CallManager に登録されるため、ある音声ゲートウェイ上のトラフィックが増大すると、そのプライマリ Cisco CallManager が処理するトラフィックが増大します。したがって、Cisco CallManager サーバのサイジングにあたっては、音声ゲートウェイの障害の可能性を考慮し、各 CallManager サーバに登録された音声ゲートウェイのうち、障害発生時に残った音声ゲートウェイで使用可能なトランクの最大数を計算する必要があります。

スタンドアロンの音声ゲートウェイの場合、この音声ゲートウェイ自体は動作していても、イーサネット接続の障害などにより、Cisco CallManager サーバとの通信経路が絶たれる可能性があります。H.323 ゲートウェイでこのような状況になった場合は、 busyout-monitor interface コマンドを使用して音声ゲートウェイ上のイーサネット インターフェイスを監視できます。音声ポートをビジーアウトモニタ ステートにするには、 busyout-monitor interface voice-port 設定コマンドを使用します。音声ポートのビジーアウトモニタ ステートを解除するには、このコマンドの no 形式を使用します。

スイッチへの音声ゲートウェイ インターフェイスに障害が発生した場合は、その音声ゲートウェイのすべてのトランクが自動的にビジー アウトされます。これにより、PSTN からこの音声ゲートウェイに新規コールがルーティングされなくなります。Real-Time Transport Protocol（RTP）ストリーム接続が失われるため、接続中のコールは失われます。回線の両側が無音状態になり、設定されたタイムアウトを経て、コールがクリアされます。Transmission Control Protocol（TCP）のタイムアウト パラメータは音声ゲートウェイで設定できます。Cisco CallManager でデフォルト タイムアウトを設定することもできます。どちらのタイムアウトが先に経過しても、コールがクリアされます。スイッチへの音声ゲートウェイ インターフェイスが復旧すると、トランクが自動的にアイドル状態になり、PSTN がこの音声ゲートウェイへのコールのルーティングを再開します（PSTN がこれらのトランクから完全にビジー アウトされていない場合）。

Cisco CallManager と CTI Manager に関する設計上の注意点

Cisco CallManager Release 3.3( x ) 以降では、CTI マネージャが使用されます。CTI マネージャはアプリケーション ブローカーとして機能するサービスで、すべての CTI リソースを処理するために、特定の Cisco CallManager サーバに対するアプリケーションの物理バインディングを抽象化します（CTI マネージャのアーキテクチャの詳細については、『 Cisco IP Telephony Solution Reference Network Design (SRND) 』を参照してください）。CTI マネージャと Cisco CallManager は、同じ Cisco CallManager サーバで動作する 2 つの独立したサービスです。Cisco CallManager サーバで動作するサービスには、他に TFTP、Cisco Messaging Interface、Real-time Information Server（RIS）データ コレクタ サービスなどがあります。

CTI マネージャの主な機能は、外部 CTI アプリケーションからメッセージを受け入れ、Cisco CallManager クラスタ内の適切なリソースに送信することです。CTI マネージャは、Cisco JTAPI リンクを使用してアプリケーションと通信します。CTI マネージャは、JTAPI メッセージング ルータのように機能します。Cisco CallManager Release 3.1 以降の JTAPI クライアント ライブラリは、3.1 より前のリリースのように Cisco CallManager サービスに直接接続するのではなく、CTI マネージャに接続します。また、クラスタ内の（Cisco CallManager サービス経由で）相互認識（この節で説明します）している複数の Cisco CallManager サーバで、複数の CTI マネージャ サービスを実行することもできます。CTI マネージャは、クラスタ内の Cisco CallManager が通信しあうために使用するメカニズムと同一の、Signal Distribution Layer（SDL）シグナリング メカニズムを使用します。ただし、CTI マネージャがクラスタ内の他の CTI マネージャと直接通信することはありません（これについても後で説明します）。

Cisco CallManager サービスの主な機能は、すべての IP テレフォニー デバイスを登録および監視することです。CTI マネージャ サービスが、システム デバイスに対するすべての CTI アプリケーション要求に関するルータとして機能するのに対して、Cisco CallManager サービスは、基本的にシステム内のすべての IP テレフォニー リソースおよびデバイスに対するスイッチとして機能します。Cisco CallManager サービスに登録する JTAPI によって制御できるデバイスには、IP 電話、CTI ポート、CTI ルート ポイントなどが含まれます。

図3-4 は、Cisco CallManager と CTI マネージャのいくつかの機能を示したものです。

図3-4 Cisco CallManager と CTI マネージャの機能

Cisco CallManager クラスタ内のサーバは、Signal Distribution Layer（SDL）サービスを使用して互いに通信します。SDL シグナリングは、Cisco CallManager クラスタ内のすべてが調和していることを確認するために、Cisco CallManager サービスが他の Cisco CallManager サービスにコンタクトする際にだけ使用されます。クラスタ内の CTI マネージャは、互いに完全に独立しており、互いに直接接続を確立しません。CTI マネージャは、外部 CTI アプリケーション要求を、このサブスクライバ上のローカル Cisco CallManager サービスが対象とする適切なデバイスにルーティングするだけです。ローカル Cisco CallManager サブスクライバ上に当該デバイスが存在しない場合は、Cisco CallManager サービスにより、このアプリケーション要求がクラスタ内の適切な Cisco CallManager に転送されます。図3-5 は、クラスタ内にある別の Cisco CallManager への、デバイス要求のフローを示しています。

図3-5 リモート Cisco CallManager への CTI マネージャ デバイス要求

デバイスおよび CTI アプリケーションのロード バランシングは、Cisco CallManager クラスタ内のすべてのノード間で均等になるように行うことが重要です。

外部 CTI アプリケーションは、CTI マネージャ上の JTAPI ユーザ アカウントを使用して接続を確立し、この JTAPI ユーザに登録された Cisco CallManager デバイスの制御を担います。さらに、CTI マネージャが互いに独立していることにより、どの CTI アプリケーションも、要求を実行するために任意の CTI マネージャに接続できます。ただし、CTI マネージャは独立しているため、障害発生時にある CTI マネージャが別の CTI マネージャに CTI アプリケーションを渡すことができません。最初の CTI マネージャに障害が発生した場合、外部 CTI アプリケーションは、フェールオーバー メカニズムを実装して、クラスタ内の別の CTI マネージャに接続する必要があります。たとえば、Voice Response Unit（VRU; 音声応答装置）Peripheral Gateway（PG; ペリフェラル ゲートウェイ）では、アドミニストレータがプライマリとセカンダリの 2 つの CTI マネージャを入力できます。Cisco CallManager PG は、CTI マネージャのフェールオーバーを、サイド A とサイド B の両サイドを使用して処理します。この両サイドは、2 つの CTI マネージャの初期化時に、同一の JTAPI ユーザにログインします。ただし、Cisco CallManager クラスタ内のシステム リソースを節約するため、JTAPI ユーザがユーザ デバイスを登録および監視できるのは、Cisco CallManager PG の一方のサイドだけです。Cisco CallManager と VRU PG のもう一方のサイドは、ホットスタンバイ モードのまま、アクティブなサイドで障害が発生したときにただちにアクティブなれるように待機します。

CTI アプリケーションは、同一の JTAPI ユーザを複数回使用して、複数の CTI マネージャにログインできます。この機能により、クラスタ内で CTI アプリケーション接続のロード バランシングを行うことができます。また、同一の JTAPI ユーザを使用して制御を維持しながら、独立した複数の CTI マネージャに複数の接続の確立を許可することで、CTI アプリケーション レベルでのフェールオーバーと冗長性のエクストラ レイヤが追加されます。ただし、CTI マネージャで JTAPI 接続が確立されるたびに（JTAPI ユーザが CTI マネージャにログインするたびに）、サーバ CPU およびメモリの使用率が増大する点に注意してください。これは、CTI アプリケーションが、JTAPI ユーザに関連付けられたすべてのデバイス上のイベントを登録および監視するためです。したがって、CTI アプリケーション デバイスを割り振るときは、そのアプリケーションが接続される CTI マネージャに対してローカルになるようにしてください（図3-6 を参照してください）。

図3-6 CTI アプリケーション デバイスの登録

図3-6 は、CTI マネージャ、Cisco CallManager PG、および IP IVR（CRS）を使用する 2 つの外部 CTI アプリケーションを示しています。Cisco CallManager PG が、JTAPI アカウント ユーザ 1 を使用して CTI マネージャにログインします。一方 IP IVR（CRS）はユーザ 2 を使用します。コールのロード バランシングのため各サブスクライバが 2 つの電話を担当し、CTI アプリケーションのロード バランシングのため各サーバが 1 つの JTAPI 接続を担当します。

利用可能なリソースに過大な負荷がかかることを防止するには、Cisco CallManager クラスタ内のすべてのノードの負荷ができるだけ均等になるように、デバイス（電話、ゲートウェイ、ポート、CTI ルート ポイント、CTI ポートなど）と CTI アプリケーションのロード バランシングを行います。

Cisco CallManager と CTI マネージャの設計は、ネットワーク設計の次に行う 2 番目の設計段階です。展開の順序も同じです。これは、テレフォニー アプリケーションを展開するためには、その前にデバイスを使用してコールをダイヤルおよび受信するため、IP テレフォニー インフラストラクチャが存在する必要があるためです。次の設計段階に進む前に、公衆電話交換網の電話から IP 電話へのコールが可能なこと、およびこの同じ IP 電話から公衆電話交換網の電話へのダイヤル アウトが可能なことを確認してください。その際、これらのコールの処理に関わるすべてのコール サバイバビリティ能力を考慮に入れてください。また、Cisco CallManager クラスタが IPCC システムの中核であり、クラスタ内のどのサーバに障害が発生しても 2 つのサービス（CTI と Cisco CallManager）がダウンし、クラスタ内の残りのサーバに対する負荷が増大する点に注意してください。

Cisco CallManager デバイス（電話、CTI ポート、および CTI ルート ポイント）は、すべての Cisco CallManager に均等に分散してください。また、ワーストケース シナリオのもとでも、クラスタ内に残されたすべてのサーバが各々にかかる負荷を処理できるようにしてください。Cisco CallManager クラスタのロード バランシングの詳細については、次の URL にある『 Cisco IP Telephony Solution Reference Network Design (SRND) 』ガイドを参照してください。

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

CTI マネージャの冗長性のための ICM 構成

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

---

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

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

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

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

---

 

図3-7 PG のサイド A およびサイド B への CTI マネージャの割り当て

 

IP IVR（CRS）に関する設計上の注意点

IP IVR（CRS）内の JTAPI サブシステムは、2 つの CTI マネージャとの接続を確立できます。この機能により、IP IVR にコールを送る前に ICM スクリプトを使用して IP IVR のアベイラビリティをチェックできるだけでなく、IPCC 設計に CTI マネージャ レベルで IP IVR の冗長性を追加できます。すべての IP IVR が最も効率的に使用されるように、ロード バランシングを行うことを強くお勧めします。

図3-8 は、1 つの Cisco CallManager クラスタ内で冗長構成された 2 つの IP IVR（CRS）サーバを示しています。IP IVR グループは、ロード バランシングと高アベイラビリティのため、各サーバが、クラスタ内の異なる Cisco CallManager サブスクライバ上で異なる CTI マネージャ サービスに接続されるように構成する必要があります。IP IVR サーバ内の JTAPI サブシステムの冗長機能を使用すると、クラスタから 2 つの Cisco CallManager の IP アドレスまたはホスト名を追加することによって冗長性を実装できます。これにより、1 つの Cisco CallManager に障害が発生したときに、この Cisco CallManager に関連付けられた IP IVR を 2 番目の Cisco CallManager にフェールオーバーできます。

図3-8 2 つの IP IVR サーバと 1 つの Cisco CallManager クラスタによる高アベイラビリティ

IP IVR（CRS）のアベイラビリティは、次のいずれかの方式で増やすことができます。

• Cisco CallManager の call-forward-busy および call-forward-on-error 機能。この方式は比較的複雑です。少数の重要な CTI ルート ポイントおよび CTI ポートについて、Cisco CallManager 内のコール処理レベルまで高アベイラビリティが必要になる特殊なケースにだけ、この方式をお勧めします。この方式の詳細については、「Cisco CallManager を使用した IP IVR（CRS）の高アベイラビリティ」を参照してください。

• IP IVR にコールを送る前に IP IVR のアベイラビリティをチェックする ICM スクリプト機能。この方式の詳細については、「ICM を使用した IP IVR（CRS）の高アベイラビリティ」を参照してください。

（注） IP IVR（CRS）サブシステムとサービスを混同しないように注意してください。IP IVR は、Cisco Application Engine サービスの 1 サービスだけを使用します。IP IVR サブシステムは、CTI マネージャや ICM などの外部アプリケーションとの接続です。

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

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

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

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

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

---

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

---

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

ICM スクリプトを使用して、IP IVR（CRS）の高アベイラビリティを実装できます。IP IVR にコールを送る前に ICM スクリプトを使用して IP IVR ペリフェラル ステータスをチェックすることにより、コールが非アクティブ IP IVR にキューイングされるのを防止できます。たとえば、IF ノードを使用するか、または（ consider if フィールドを使用して）Voice Response Unit（VRU）ノードへのトランスレーション ルートを構成することにより、IP IVR がアクティブかどうかをチェックする ICM スクリプトをプログラムできます。この方式は、修正によって複数の IP IVR 間でポートのロード バランスを調整でき、容易に、事実上いくつでも、IP IVR を追加できます。

---

（注） IP IVR サーバ、IVR と CallManager を結ぶ JTAPI リンク、または IP IVR PG に障害が発生した場合は、この IP IVR 上のコールがすべてドロップされます。

---

Internet Service Node（ISN）に関する設計上の注意点

IPCC では、コール処理およびキューイングのために、IP IVR の代わりに Internet Service Node（ISN）を展開できます。ISN は、JTAPI コール制御のために Cisco CallManager に依存しない点で、IP IVR とは異なります。ISN はコール制御に H.323 を使用し、ハイブリッド IPCC またはマイグレーション ソリューションの一部として、Cisco CallManager またはその他の PBX システムの「前で」使用されます（図3-9 を参照してください）。

図3-9 2 つの ISN サーバによる高アベイラビリティの実現

ISN では次のシステム コンポーネントが使用されます。

• Cisco Voice Gateway

Cisco Voice Gateway は通常、TDM PSTN トランクおよびコールを終端し、IP ネットワーク上の IP ベースのコールにトランスフォームするために使用します。ISN では、これらの音声ゲートウェイにより、IOS 組み込み Voice Extensible Markup Language（VXML）音声ブラウザを使用して、コールを物理 IP IVR に移さずに、音声ゲートウェイ上で発信者処理とコール キューイングを行うことも可能になります。また、Media Resource Control Protocol（MRCP）インターフェイスを使用し、ISN 制御下でゲートウェイに Automatic Speech Recognition（ASR）および Text-To-Speech（TTS）機能を追加することもできます。

• ISN 音声ブラウザ

ISN 音声ブラウザは、入力ゲートウェイと別のエンドポイント ゲートウェイまたは IPCC エージェントの間でコールがスイッチされるとき、コール制御シグナリングを行うため、音声ゲートウェイ上で VXML 音声ブラウザと連携して使用されます。音声ブラウザは、アプリケーション サーバとゲートキーパーに登録されます。これにより、新しいコールがシステムに到達すると、ゲートキーパーがダイヤル番号を、そのコールを処理できる特定の音声ブラウザのセットに関連付けることができます。

• ISN アプリケーション サーバ

ISN Application Server は、音声ブラウザ（ゲートウェイ上の VXML 音声ブラウザと ISN 音声ブラウザの両方）を制御します。また、ICM ペリフェラル ゲートウェイにインターフェイスして指示を取得し、データを ICM ルーティング スクリプトに渡します。ICM ペリフェラル ゲートウェイからの指示は、Application Server によって VXML コードに変換され、音声ブラウザに送られて処理されます。

• ISN メディア サーバ

ISN 発信者処理は、MRCP 経由で ASR/TTS 機能を使用するか、メディア サーバに格納された事前定義済み .wav ファイルを使用することによって行われます。メディア サーバは、Web サーバとして機能し、VXML 処理の一環として .wav ファイルを音声ブラウザに送ります。メディア サーバは、Cisco Content Services Switch（CSS）製品を使用してクラスタ化できます。このため、ネットワーク内のすべての音声ブラウザがアクセスする 1 つの URL の背後に、複数のメディア サーバをプールできます。

• H.323 ゲートキーパー

ゲートキーパーは、ISN で、音声ブラウザを登録して特定のダイヤル番号に関連付けるために使用します。コールがネットワークに到達すると、ゲートウェイはゲートキーパーに問い合せて、ダイヤル番号に基づきコールの送信先を検索します。また、アウト オブ サービスの音声ブラウザや利用可能なセッションがない音声ブラウザにコールが送信されないように、ゲートキーパーは音声ブラウザの状態を監視し、音声ブラウザ間でコールのロードバランスを調整します。

ISN のアベイラビリティは次の方法で増やすことができます。

• ICM のプラットフォーム間でコールのバランスを調整できるように、ICM ペリフェラル ゲートウェイの制御下に冗長 ISN システムを追加する。

• ISN システムに ISN コンポーネントを追加する（たとえば、1 つの ISN に複数の音声ブラウザを持たせる）。

• HSRP でゲートキーパーの冗長性を追加する。

• 複数の ISN メディア サーバの間で .wav ファイル要求のロードバランスを調整するため、Cisco Content Server を追加する。

（注） Application Server または ISN PG に障害が発生しても、ISN 内のコールはドロップされません。これは、耐障害設計の一環として、ISN イメージを持つ音声ゲートウェイ内の TCL スクリプトを使用して、別の ISN 制御ゲートウェイにある別の ISN 音声ブラウザに、これらのコールをリダイレクトできるためです。

これらのオプションの詳細については、次の URL にある ISN 製品ドキュメントを参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/icm/isn/isn21/index.htm

マルチチャネルに関する設計上の注意点（Cisco Email Manager オプションおよび Cisco Collaboration Server オプション）

IPCC Enterprise ソリューションは、マルチチャネル カスタマー コンタクトをサポートするように拡張できます。これにより、電子メールおよび Web によるコンタクトを、IPCC によってエージェントにルーティングできるようになります（ブレンド モードまたは「ユニバーサル キュー」モードを使用します）。次のオプション コンポーネントを IPCC アーキテクチャに統合します（図3-10 を参照してください）。

• メディア ルーティング ペリフェラル ゲートウェイ

マルチチャネル コンタクトをルーティングするために、Cisco e-Mail Manager と Cisco Collaboration Server Media Blender がメディア ルーティング ペリフェラル ゲートウェイと通信します。メディア ルーティング ペリフェラル ゲートウェイは、他のペリフェラル ゲートウェイと同様、高アベイラビリティ用に相互接続された 2 つのサーバを使用して、冗長化または二重化して展開できます。通常、メディア ルーティング ペリフェラル ゲートウェイはセントラル コントローラに設置され、マルチチャネル システムに IP ソケット接続されています。

• アドミン ワークステーション ConAPI インターフェイス

Cisco マルチチャネル オプションを統合することにより、ICM およびオプション システムが、エージェントとその関連スキル グループに関する構成情報を共有できるようになります。Configuration Application Programming Interface（ConAPI）は、アドミン ワークステーションで動作します。また、バックアップ サービスが別のアドミン ワークステーションで動作するように構成できます。

• Agent Reporting and Management（ARM）および Task Event Services（TES）接続

ARM および TES サービスは、IPCC CTI サーバからマルチチャネル システムに、コール（ARM）および非音声（TES）の状態およびイベントを通知するサービスです。これらの接続により、電子メールおよび Web 環境にエージェント情報が提供されます。また、これらの環境からのタスク要求を受容および処理できるようになります。この接続は、エージェントに関連付けられた CTI サーバに接続する TCP/IP ソケットです。これは、エージェント ペリフェラル ゲートウェイ上の冗長または二重ペアとして展開できます。

図3-10 マルチチャネル システム

高アベイラビリティに関する推奨事項：

• メディア ルーティング ペリフェラル ゲートウェイを二重化して展開します。

• ConAPI を、構成とスクリプトには使用されないアドミン ワークステーションの冗長ペアとして展開します。これにより、シャットオフまたはリブートされにくくなります。この機能を提供するセントラル サイトとして、HDS サーバを使用することも検討してください。

• IPCC エージェント ペリフェラル ゲートウェイおよび CTI サーバを二重化して展開します。

Cisco Email Manager オプション

Cisco Email Manager を IPCC Enterprise Edition と統合することにより、IPCC によるマルチチャネル コンタクト センターにおいて、電子メールのサポートを強化できます。1 つのサーバ（図3-11 を参照してください）を使用して小さな規模で展開することも、複数のサーバを使用してより大きなシステム設計要件を満たすこともできます。Cisco Email Manager の主要なコンポーネントは次のとおりです。

• Cisco Email Manager サーバ ? コア ルーティングおよび制御サーバ（冗長性なし）。

• Cisco Email Manager データベース サーバ ? すべての電子メールおよびシステム内の構成およびルーティング ルールについての、オンライン データベースを担うサーバ。展開の規模が小さい場合は Cisco Email Manager サーバと共存させることができます。システムの規模が大きい場合は専用サーバにします。

• Cisco Email Manager UI サーバ ? このサーバ使用することにより、エージェント ユーザ インターフェイス（UI）コンポーネントをメインの Cisco Email Manager サーバからオフロードできます。これにより、展開の規模を大きくすることや、複数のリモート エージェント サイトをサポートすることが可能になります。各リモート サイトにローカル UI サーバを置くことにより、エージェント ブラウザ クライアントから Cisco Email Manager サーバへのデータ トラフィックを減らすことができます（図3-12 を参照してください）。

図3-11 1 つの Cisco Email Manager サーバ

図3-12 複数の UI サーバ

Cisco Collaboration Server オプション

Cisco Collaboration Server を IPCC Enterprise Edition と統合することにより、IPCC によるマルチチャネル コンタクト センターにおいて、Web チャットおよび Web 画面共有のサポートを強化できます。Cisco Collaboration Server の主要なコンポーネントは次のとおりです（図3-13 を参照してください）。

• Cisco Collaboration Server ? コラボレーション サーバは、このサーバがサポートする企業 Web サーバとともに、DeMilitarized Zone（DMZ; 非武装地帯）内の企業ファイアウォールの外部に展開します。システムの規模が大きい場合は、複数のコラボレーション サーバを展開することもできます。

• Cisco Collaboration Server データベース サーバ ? これは、すべてのチャットおよびブラウジング セッション、ならびにシステム内の構成およびルーティング ルールについての、オンライン データベースを担うサーバです。このサーバは、Cisco Collaboration Server 上に共存できます。ただし、Cisco Collaboration Server はファイアウォールの外部にあるので、ほとんどの企業は、データベース内の履歴データを保護するため、ファイアウォール内部の独立したサーバにこのサーバを展開しています。複数の Cisco Collaboration Server が同一のデータベース サーバを参照するようにすると、ソリューションに必要なサーバの総数を減らすことができます。

• Cisco Collaboration Server Media Blender ? このサーバは、コラボレーション サーバにポーリングして新しい要求をチェックします。また、エージェントと発信者を接続する Media Routing および CTI/Task インターフェイスを管理します。各 IPCC エージェント ペリフェラル ゲートウェイはそれぞれの Media Blender を持ち、各 Media Blender はメディア ルーティング ペリフェラル ゲートウェイ上にメディア ルーティング Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）コンポーネントを持ちます。

• Cisco Collaboration Dynamic Content Adaptor（DCA）? このサーバは、コラボレーション サーバとともに DMZ 内に展開されます。このサーバによって、Web サイト上でプログラムによって動的に生成されるコンテンツを、システムで共有することが可能になります。

図3-13 Cisco Collaboration Server

Cisco IPCC アウトバウンド オプションに関する設計上の注意点

アウトバウンド オプションを使用すると、IPCC Enterprise がカスタマーへのコールを、事前定義されたキャンペーンに基づいてエージェントに代わり発信できるようになります。アウトバウンド オプションの主要なコンポーネントは次のとおりです（図3-14 を参照してください）。

• アウトバウンド オプション Campaign Manager ? 発信されるコールに関連付けられたダイヤリング リストおよびルールを管理する、ソフトウェア モジュール。このソフトウェアは、Logger プラットフォームにロードされます。このソフトウェアは冗長化しません。IPCC システム内の二重化された Logger のうち、1 つのサーバにだけロードされ、このサーバでだけアクティブになります。

• アウトバウンド オプション ダイヤラ ? Campaign Manager に代わってダイヤリング タスクを実行するソフトウェア モジュール。IPCC では、Cisco CallManager によるアウトバウンド コールの際に、このダイヤラが IP 電話のセットをエミュレートします。またこのダイヤラは、発信者を検出し、コールをエージェントに転送するための CTI OS サーバとのインタラクション タスクを管理します。このダイヤラはメディア ルーティング ペリフェラル ゲートウェイと通信します。各ダイヤラは、メディア ルーティング ペリフェラル ゲートウェイ上にそれぞれの Peripheral Interface Manager（PIM）を持ちます。

図3-14 IPCC アウトバウンド オプション

このシステムでは、エンタープライズ全体で複数のダイヤラがサポートされます。これらのダイヤラのすべてが、セントラル Campaign Manager ソフトウェアの制御下に入ります。これらのダイヤラは、ペリフェラル ゲートウェイのように冗長化または二重化されたペアとしては機能しません。しかし、Campaign Manager の制御下に 1 ペアのダイヤラが置かれることにより、一方のダイヤラに発生した障害が自動的に処理され、残ったダイヤラによってコールが処理され続けます。すでにエージェントに接続されているコールは、引き続き接続され、障害の影響は受けません。

実装の規模が小さい場合は、このダイヤラを IPCC ペリフェラル ゲートウェイ上に共存させることができます。システムの規模が大きい場合は、このダイヤラ用のサーバを用意する必要があります。または、セントラル Campaign Manager の制御下で複数のダイヤラを使用することもできます。

高アベイラビリティに関する推奨事項：

• メディア ルーティング ペリフェラル ゲートウェイを二重化して展開します。

• シングル ポイント障害を排除するため、各ダイヤラをスタンドアロン デバイスとしてそれ自身のサーバに展開します（ダイヤラが PG 上に共存している場合、PG サーバに障害が発生した際にダイヤラがダウンします）。

• 障害発生時にセカンド ダイヤラに自動復旧できるように、複数のダイヤラを展開して Campaign Manager 内で使用します。

• Cisco CallManager クラスタ内の他の電話またはデバイス同様、別のサブスクライバにフェールオーバーできるように、Cisco CallManager 内の冗長グループにダイヤラ「電話」（Cisco CallManager 内の仮想電話）を含めます。

ペリフェラル ゲートウェイに関する設計上の注意点

ICM CallManager Peripheral Gateway（PG; ペリフェラル ゲートウェイ）では、Cisco CallManager CTI マネージャ プロセスを使用して、Cisco CallManager クラスタと通信します。これにより、1 つの Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）で、クラスタ内の任意の場所にあるエージェント電話を制御します。ペリフェラル ゲートウェイ PIM プロセスは、クラスタ内の Cisco CallManager サーバの 1 つにある CTI マネージャに登録します。次に CTI マネージャが、PG からクラスタへのすべての JTAPI 要求を受け入れます。PG が制御する電話、ルート ポイント、またはその他のデバイスがクラスタ内の指定された Cisco CallManager サーバに登録されていない場合、CTI マネージャがこの要求を、クラスタ内にある他の Cisco CallManager サーバに Cisco CallManager SDL リンク経由で転送します。1 つの PG が、クラスタ内の複数の Cisco CallManager サーバに接続する必要はありません。

二重 Cisco CallManager PG の実装を強くお勧めします。これは、PG が 1 つの CTI マネージャを使用して、Cisco CallManager クラスタへの接続を 1 つしか持たないためです。CTI マネージャに障害が発生した場合は、PG は Cisco CallManager クラスタと通信できなくなります。冗長または二重 PG を追加することにより、ICM では、クラスタ内の別の Cisco CallManager サーバで動作するセカンド CTI マネージャ プロセスを使用した、CallManager クラスタへのセカンド経路または接続を確保できます。

CTI マネージャと IP IVR（CRS）で ICM 高アベイラビリティをサポートするための最小要件は、2 つ以上のサーバを含む 1 つの Cisco CallManager クラスタを持つ、二重（冗長）Cisco CallManager PG 環境です。したがって、このケースにおける Cisco CallManager クラスタの最小構成は、1 つのパブリッシャと 1 つのサブスクライバです（図3-15 を参照してください）。

図3-15 1 つの Cisco CallManager クラスタでの ICM 高アベイラビリティ

冗長 ICM サーバは、同一の物理サイトに置くことも、地理的に分散することもできます。いずれの場合も、ICM Call Router および Logger/Database Server プロセスは、プライベートの専用 LAN 経由で相互接続します。サーバを同一サイトに置く場合は、各サーバ（サイド A およびサイド B）にセカンド NIC カードを挿入してクロスケーブルで相互接続することにより、プライベート LAN を提供できます。サーバを地理的に分散配置する場合は、各サーバ（サイド A およびサイド B）にセカンド NIC カードを挿入し、固有のネットワーク要件を満たす専用 T1 回線で相互接続することにより、プライベート LAN を提供できます。ネットワーク要件については、次の URL にある『Cisco ICM Software Installation Guide』を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm50doc/coreicm5/plngupin/instlgd.pdf

ICM PG 内では、Cisco CallManager クラスタへの接続を管理するため、JTAPI Gateway と CallManager PIM の 2 つのソフトウェア プロセスが実行されます。JTAPI Gateway は PG によって自動的に始動され、ノード管理プロセスとして実行されます。これは、PG がこのプロセスを監視し、何らかの理由で障害が発生したときは自動的に再始動することを意味します。JTAPI Gateway は、PIM と Cisco CallManager CTI マネージャの間の、低レベル JTAPI ソケット接続プロトコルおよびメッセージングを処理します。JTAPI Gateway は、Cisco CallManager のこのバージョンに固有のソフトウェア プロセスです。

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

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

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

Cisco CallManager の障害シナリオ

二重 ICM モデルには、シングル ポイント障害は含まれません。ただし、複数の障害の組み合せによって、IPCC が新しい着信コールを受け入れられなくなるシナリオは存在します。また、IPCC ソリューションのコンポーネント自体が冗長性とフェールオーバーをサポートしない場合、このコンポーネント上にある既存のコールがドロップされます。高アベイラビリティに最も影響があるのは、次の ICM 障害シナリオです。次の障害シナリオのいずれかが発生した場合、Cisco CallManager Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）は始動できません（図3-16 を参照してください）。

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

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

これらのいずれのケースでも、ICM から Cisco CallManager クラスタへの接続性が失われます。

図3-16 Cisco CallManager PG はバックアップ CTI マネージャと相互接続できない

 

シナリオ 1 - Cisco CallManager と CTI マネージャに障害が発生する

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

• すべての電話およびゲートウェイが Cisco CallManager A に登録されています。

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

• Cisco CallManager A および B は、それぞれ独立したインスタンスの CTI マネージャを実行しています。

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

• PG のサイド A が障害を検出し、PG のサイド B へのフェールオーバーを開始します。

• PG のサイド B がアクティブになり、すべてのダイヤル番号および電話を登録します。コール処理は継続されます。

• エージェントがすべてのコールから接続解除されると、このエージェントのデスクトップ機能がフェールオーバー前と同じ状態に復元され、IP 電話がバックアップ Cisco CallManager B に登録し直します。

• Cisco CallManager A が復旧すると、すべての電話およびゲートウェイが Cisco CallManager A に登録し直します。

• PG のサイド B は、Cisco CallManager B 上の CTI マネージャを使用してアクティブなままです。

• この障害発生中、IPCC エージェントで接続中のコールはすべてアクティブなままです。コールが完了すると、電話がバックアップ Cisco CallManager に自動的に登録し直します。

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

図3-17 シナリオ 1 - Cisco CallManager と CTI マネージャに障害が発生する

 

シナリオ 2 - Cisco CallManager PG のサイド A に障害が発生する

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

• すべての電話およびゲートウェイが Cisco CallManager A に登録されています。

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

• Cisco CallManager A および B は、それぞれ独立したインスタンスの CTI マネージャを実行しています。

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

• PG B サイドがすべてのダイヤル番号および電話を登録し、コール処理は継続されます。

• エージェントがすべてのコールから接続解除されると、このエージェントのデスクトップ機能がフェールオーバー前と同じ状態に復元されます。

• PG のサイド A が復旧しても、PG のサイド B がアクティブなまま Cisco CallManager B 上の CTI マネージャを使用します。

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

 

シナリオ 3 - Cisco CallManager だけに障害が発生する

図3-19 は Cisco CallManager A 上の障害を示しています。CTI マネージャ サービスが Cisco CallManagers C および D で動作しており、Cisco CallManager C がプライマリ CTI マネージャとして機能しています。ただし、すべての電話およびゲートウェイが Cisco CallManager A に登録されています。この障害発生中、Cisco CallManager は影響を受けません。これは、PG が Cisco CallManager サービスではなく CTI マネージャ サービスと通信するためです。すべての電話が、コール中でなければ個別にスタンバイ Cisco CallManager B に登録し直します。コール中の電話は、コールから接続解除後に Cisco CallManager B に登録し直します。

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

• すべての電話およびゲートウェイが Cisco CallManager A に登録されています。

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

• Cisco CallManager C および D は、それぞれ独立したインスタンスの CTI マネージャを実行しています。

• Cisco CallManager A に障害が発生すると、電話およびゲートウェイが Cisco CallManager B に登録し直します。

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

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

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

• Cisco CallManager A が復旧すると、電話およびゲートウェイが Cisco CallManager A に登録し直します。この登録し直しは、電話およびデバイスのグループを時間をかけて徐々に戻すように設定するか、またはコール センターへの影響を最小化するため、メンテナンス期間中に手動介入を必要とするように設定します。設定は Cisco CallManager で行います。

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

図3-19 シナリオ 3 - Cisco CallManager だけに障害が発生する

 

シナリオ 4 - CTI マネージャだけに障害が発生する

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

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

• すべての電話およびゲートウェイが Cisco CallManager A に登録されています。

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

• Cisco CallManager C および D は、それぞれ独立したインスタンスの CTI マネージャを実行しています。

• Cisco CallManager C に障害が発生すると、PG のサイド A がこのサーバ上の CTI マネージャの障害を検出し、PG のサイド B へのフェールオーバーを開始します。

• PG のサイド B が、Cisco CallManager D ですべてのダイヤル番号および電話を登録します。コール処理が継続されます。

• エージェントがすべてのコールから接続解除されると、このエージェントのデスクトップ機能がフェールオーバー前と同じ状態に復元されます。

• Cisco CallManager C が復旧しても、PG のサイド B がアクティブであり続け、Cisco CallManager D 上の CTI マネージャを使用します。

図3-20 CTI マネージャだけに障害が発生する

 

障害リカバリの理解

この項では、IPCC ソリューションの各パート（製品および各製品のサブコンポーネント）のフェールオーバー リカバリを分析します。

Cisco CallManager PG と CTI マネージャ サービス

アクティブ CTI マネージャまたは PG に障害が発生すると、JTAPI が OUT_OF_SERVICE イベントを検出し、スタンバイ PG へのフェールオーバーを開始します。スタンバイ PG はすでにスタンバイ CTI マネージャにログインしているため、電話用モニタの登録は、ログインしているエージェントと、設定されたダイヤル番号およびルート ポイントで行います。この初期化サービスは、1 秒間に約 5 デバイスのレートで行われます。エージェント デスクトップには、これらがログアウトしたものとして表示され、ルーティング クライアントまたはペリフェラル（Cisco CallManager）がオフラインになったことを示すメッセージが表示されます（この警告は管理者の好みでオンにもオフにもできます）。障害リカバリが完了するまで、すべてのエージェントがデスクトップ機能を失います。デスクトップ上のエージェント状態表示にログアウトしたことが表示され、使用できるボタンがログイン ボタンだけになるため、エージェントはこのイベントを認識できます。エージェントが処理している既存コールは、発信者に影響を与えることなく存続します。

---

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

---

CTI マネージャまたは PG のフェールオーバーが完了すると、エージェントは前のコール状態（通話中、受信可、受信不可など）に戻ることができます。エージェントが障害発生時にコール中であった場合は、この時点でコールのリリース、転送、または会議も行えるようになります。コール データ アップデート メッセージ経由で収集および保存されたコール データは、すべてエージェント デスクトップに保持され、回復され、PG に保存されたコール コンテキスト情報と照合されます。ただし、アクティブ コールのないエージェントは、すべてデフォルトの受信不可状態にリセットされます。また、Longest Available Agent（LAA）アルゴリズムによってすべてのエージェントのタイマーがゼロにリセットされます。

ICM VRU PG

Voice Response Unit（VRU; 音声応答装置）PG に障害が発生すると、この IP IVR（CRS）上のキューに入っているコールがすべてドロップされます。Internet Service Node（ISN）でキューに入っているコールはドロップされず、ダイヤル プラン内のセカンダリ ISN または番号（利用可能な場合）にリダイレクトされます。ただし、障害が発生した VRU PG の Service Control Interface（SCI; サービス制御インターフェイス）リンクは、自動的にバックアップ VRU PG に接続するので、新規コールはすべて適切に処理されます。障害が発生した VRU PG が復旧すると、現在実行中の VRU PG がアクティブ VRU PG として稼働し続けます。したがって、冗長 VRU PG を用意することは非常に有益です。なぜなら、IP IVR がアクティブ IP IVR として機能し続けることが可能になるからです。VRU PG の冗長性がない場合、VRU PG に障害が発生したときに、IP IVR が適切に機能していていも、IP IVR を使用できなくなります（図3-21 を参照してください）。

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

 

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

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

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

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

 

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

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

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

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

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

CTI サーバ

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

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

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

図3-23 Cisco Agent Desktop サーバがインストールされていない冗長 CTI サーバ

 

CTI OS に関する考慮事項

CTI OS は、CTI サーバに対してクライアントとして機能し、IPCC にエージェントおよびスーパーバイザ デスクトップ機能を提供します。CTI サーバへのフェールオーバー中は、エージェントの状態と機能を管理します。また、冗長 CTI OS サーバとして展開することもできます。CTI OS エージェントデスクトップでは、冗長サーバ間のロード バランシングが自動的に行われます。また、隣合って座っている 2 人のエージェントが、実際に 2 つの異なる CTI OS サーバに登録される場合があります。

CTI Object Server（CTI OS）は、CTI OS サービスと CTI ドライバの 2 つのサービスで構成されています。これらのいずれかに障害が発生すると、アクティブ CTI OS がピア サーバにフェールオーバーします。したがって、これらのサービスの両方を常にアクティブに保つことが重要です。

Cisco Agent Desktop に関する考慮事項

Cisco Agent Desktop は、CTI OS のクライアントで、Cisco Agent Desktop サーバに自動フェールオーバーと冗長性を提供します。Cisco CallManager ペリフェラル ゲートウェイまたは CTI サーバ（CG）がフェールオーバーする場合は、フェールオーバーによってエージェントがログアウトされるのを防ぐため、フェールオーバーの間 CTI OS がエージェントの状態および情報を保持します。

コア Cisco Agent Desktop コンポーネントのフェールオーバーが可能なように、Cisco Agent Desktop サーバ（Enterprise サーバ、チャット、RASCAL など）も冗長化できます。Cisco Agent Desktop ソフトウェアは、冗長 Cisco Agent Desktop サーバを認識し、Cisco Agent Desktop サーバ プロセスまたはハードウェアの障害が発生したときは、自動的にフェールオーバーします。

その他の考慮事項

IPCC フェールオーバーは、ソリューションの他のパートに影響する可能性があります。IPCC がダウンせずに稼働していても、一部のデータはフェールオーバー中に失われる可能性があります。また、適切に機能するために IPCC を必要とするその他の製品が、IPCC フェールオーバーを処理できない可能性もあります。この項では、フェールオーバーの最中および後に、IPCC ソリューション内のその他の重要領域で起こることについて説明します。

レポーティング

IPCC レポーティング機能では、リアルタイム、5 分、および 30 分インターバルを使用してレポーティング データベースを作成します。したがって、5 分および 30 分インターバルが終了するごとに、各ペリフェラル ゲートウェイがローカルに保持するデータを収集し、Call Router に送信します。Call Router はこのデータを処理し、履歴データ保存のためにローカル Logger とデータベース サーバに送ります。Historical Data Server（HDS）オプションを含めた展開の場合は、次にこのデータが、Logger データベースに書き込まれると同時に Logger から HDS サーバに複製されます。

ペリフェラル ゲートウェイは、ネットワーク切断またはネットワーク応答速度の低下に対処するため、システムによって収集された 5 分および 30 分データを（メモリ内およびディスク上に）バッファリングし、ネットワーク サービスが復旧したときにデータを自動転送します。ただし、冗長ペア内の両ペリフェラル ゲートウェイに物理障害が発生した場合は、セントラル コントローラに未転送の 30 分または 5 分データが失われる可能性があります。停止期間中に、物理ハードウェア デバイスとこれらに関連付けられたデータの両方が消失する可能性を減らすため、冗長ペリフェラル ゲートウェイを使用することをお勧めします。

エージェントがログアウトすると、エージェントのレポーティング統計がすべて停止します。次回エージェントがログインしたときには、エージェントのリアルタイム統計がゼロから始まります。通常は、ICM フェールオーバーによってエージェントが強制ログアウトされることはありませんが、ICM フェールオーバーの完了時にエージェント統計がリセットされます。ただし、エージェント デスクトップ機能はフェールオーバー前の状態に復元されます。

詳細については、次の URL にある『Cisco IP Contact Center Reporting Guide』を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm50doc/icm5rept/index.htm