Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン(SRND)Releases 7.0
アベイラビリティを高めるための設計 上の注意点
アベイラビリティを高めるための設計上の注意点
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 4MB) | フィードバック

目次

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

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

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

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

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

Unified IP IVR(CRS)に関する設計上の注意点

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

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

Cisco Unified Customer Voice Portal(Unified CVP)の設計上の注意点

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

Cisco Email Manager オプション

Cisco Collaboration Server オプション

Cisco Unified Outbound Dialer(Unified OUTD)の設計上の注意点

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

Cisco Unified CallManager の障害シナリオ

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

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

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

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

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

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

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

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

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

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

障害リカバリの理解

Cisco Unified CallManager サービス

Unified IP IVR(CRS)

Unified ICM

Cisco Unified CallManager PG と CTI Manager サービス

Unified ICM VRU PG

Unified ICM Call Router と Logger

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

CTI サーバ

CTI OS に関する考慮事項

Cisco Agent Desktop に関する考慮事項

Unified ICM Enterprise とともに Unified CC システムを展開する際の設計上の注意点

親/子コンポーネント

Unified ICM Enterprise(親)データ センター

Unified CCX コール センター(子)サイト

Unified CCE コール センター(子)サイト

親/子コール フロー

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

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

親/子の耐障害性

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

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

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

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

アベイラビリティを高めるためのその他の注意点

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

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

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

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

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

「Unified IP IVR(CRS)に関する設計上の注意点」

「Cisco Unified Customer Voice Portal(Unified CVP)の設計上の注意点」

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

「Cisco Email Manager オプション」

「Cisco Collaboration Server オプション」

「Cisco Unified Outbound Dialer(Unified OUTD)の設計上の注意点」

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

「障害リカバリの理解」

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

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

「Unified ICM Enterprise とともに Unified CC システムを展開する際の設計上の注意点」

「アベイラビリティを高めるためのその他の注意点」

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

Cisco Unified CC は、多数のハードウェアおよびソフトウェア コンポーネントを使用する分散型ソリューションです。各システムは、シングル ポイント障害が発生しない設計にするか、最小限、コール センター リソースに対する影響が最も少なくなる方法で潜在的な障害に対応する設計にすることが重要です。 ネットワーク インフラストラクチャを含むさまざまな Unified CC コンポーネントに関する要件がどの程度厳しいのか、またどのような設計特性を選択するのかによって、障害発生時に影響を受けるリソースのタイプと数は異なります。 適切な Unified CC 設計では、ほとんどの障害(このセクションで定義します)に耐えることができます。ただし、すべての障害を見通すことは不可能です。

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

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

つまりこのガイドと、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』ガイドの設計ガイドラインと推奨事項に従い、慎重にプランニングしてください。

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

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

図3-1 は、耐障害 Unified CC 単一サイト展開の高レベルでの設計を示しています。

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

 

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

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

ハイアベイラビリティと冗長性に関する設計が正しい場合、Unified CC システムはシステムの半分が失われても稼働を継続できます。 このタイプの設計では、Unified CC システムで何が発生しても、各コールは次のいずれかの方法で処理されます。

ルーティングされて、IP 電話またはデスクトップ ソフトフォンを使用している対応可能な Unified CC エージェントによって応答される

利用可能な Unified IP IVR(CRS)または、Unified CVP ポートまたはセッションに送られる

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

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

コール処理が可能なエージェントまたはリソースのある別のサイトにルーティングされる

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

図3-2 Unified CC 単一サイトの冗長性

 

図3-2 は、図3-1 の単一サイト設計の冗長性を強調したものです。 サイド A とサイド B は基本的に互いの鏡像になっています。 実際、ハイアベイラビリティを向上するための Unified CC の主要機能の 1 つは、自動的にフェールオーバーし、人的な介入なしで復旧が行われるように設計された冗長(二重)コンポーネントを追加できる機能です。 冗長(二重)コンポーネントを持つコア システム コンポーネントは相互接続され、専用ネットワーク パス上に 100 ミリ秒ごとに生成される TCP キープアライブ メッセージを利用して、相手側システムの障害検知を行います。 耐障害性設計と障害検出およびリカバリの方式については、この章の後半で説明します。

ソリューションの他のコンポーネントでは、他のタイプの冗長性方針が採用されています。 たとえば、Cisco Unified CallManager ではクラスタ設計の採用により、プライマリ サーバが故障したときの登録先となる複数の Cisco Unified CallManager サブスクライバ(サーバ)を Unified IP Phone およびデバイスに提供します。プライマリが復元されると、それらのデバイスは自動的にプライマリに登録し直します。

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

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

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

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

また、展開に使用する音声ゲートウェイの選択も重要です。これは、プロトコルによってコール復元力が異なるためです。 この章では、Unified CC ソリューションでハイアベイラビリティを実現するための、音声ゲートウェイの構成方法について概説します。

音声ゲートウェイおよび音声ネットワーク一般については、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』ガイドを参照してください。

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

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

 

複数の音声ゲートウェイを使用すると、1 つのゲートウェイの障害ですべてのコールが遮断される問題を回避できます。 2 つの音声ゲートウェイと 1 つの Cisco Unified CallManager クラスタによる構成では、クラスタ内の各 Cisco Unified CallManager にワークロードを分散するため、各ゲートウェイを別々のプライマリ Cisco Unified CallManager に登録する必要があります。 各ゲートウェイのプライマリ Cisco Unified CallManager に障害が発生した場合は、もう一方の Cisco Unified CallManager がバックアップとして使用されます。 コール処理に関連する冗長サービス用に Cisco Unified CallManager を設定する方法の詳細については、次の URL にある『 Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) 』を参照してください。

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

H.323 音声ゲートウェイを使用すると、ゲートウェイが Cisco Unified CallManager に接続してコール制御またはコール処理の指示を受けることができない場合に、TCL スクリプトと追加のダイヤル ピアを使用した付加的なコール処理を実行できます。 MGCP ゲートウェイにはこのような組み込み機能はありません。このようなゲートウェイで終端されるトランクには PSTN キャリアまたはサービス プロバイダーからのバックアップ ルーティングを持たせ、障害時または無応答時にトランクが別のゲートウェイまたは別のロケーションに再ルーティングされるようにする必要があります。

ゲートウェイのトランクのキャパシティを計算する際は、ゲートウェイのフェールオーバーについて考慮し、1 つ以上の音声ゲートウェイに障害が発生しても最大 Busy Hour Call Attempts(BHCA; 最頻時発呼数)を十分に処理できるようにしてください。 設計段階で、まずそのサイトで許容可能な音声ゲートウェイ障害の最大同時発生数を決めます。 この要件と、使用する音声ゲートウェイの数、およびこれらの音声ゲートウェイにまたがるトランクの配置から、通常モード時および災害モード時に必要となるトランクの総数を求めることができます。 トランクを複数の音声ゲートウェイに分散するほど、障害モード時に必要なトランクは少なくなります。 ただし、使用する音声ゲートウェイを増やすと、このコンポーネントのコストが増大します。このため、トランクの年間オペレーティング コスト(公衆電話交換網プロバイダーに支払う料金)と、音声ゲートウェイを導入する際の固定コストを比較する必要があります。 また、ゲートウェイのフォームファクタについても考慮が必要です。たとえば、Cisco Catalyst 6500 シャーシの 8 ポート T1 ブレード全体に障害が発生した場合、そのサイトに着信する 184 のコールに影響がおよびます。

たとえば、コール センターの最大 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 はその音声ゲートウェイへのコールの送信を自動的に再開します。

H.323 音声ゲートウェイの場合、この音声ゲートウェイ自体は動作しているにもかかわらず、Cisco Unified CallManager サーバとの通信パスに重篤な状態が発生する可能性があります(イーサネット接続の障害など)。 H.323 ゲートウェイでこのような状況になった場合は、 busyout-monitor interface コマンドを使用して音声ゲートウェイ上のイーサネット インターフェイスを監視できます。 音声ポートをビジーアウトモニタ ステートにするには、 busyout-monitor interface voice-port 設定コマンドを使用します。 音声ポートのビジーアウトモニタ ステートを解除するには、このコマンドの no 形式を使用します。 前述のとおり、Cisco Unified CallManager のコール制御インターフェイスを使用できない場合、これらのゲートウェイでは追加の処理オプションによって、コールを別のサイトまたは別の着信番号へ再ルーティングしたり、ローカルに保存された .wav ファイルを発信者に流してコールを終了できます。

MGCP 制御の音声ゲートウェイを使用している場合、Cisco Unified CallManager への音声ゲートウェイ インターフェイスに障害が発生すると、ゲートウェイは冗長性グループから 2 つ目または 3 つ目の Cisco Unified CallManager サブスクライバを検索します。 MGCP ゲートウェイはグループ内の別のサブスクライバに自動的にフェールオーバーし、それぞれの動作状態を定期的に確認します。オンラインに戻ったときには利用可能としてマーキングされます。 すべてのコールがアイドルになったとき、または 24 時間後に(いずれかの早い時点)、ゲートウェイはプライマリ サブスクライバにフェールバックします。 利用できるサブスクライバがない場合、音声ゲートウェイでは自動的にすべてのトランクがビジー アウトされます。 これにより、PSTN からこの音声ゲートウェイに新規コールがルーティングされなくなります。 Cisco Unified CallManager への音声ゲートウェイ インターフェイスがバックアップ サブスクライバに登録されると、トランクが自動的にアイドル状態になり、PSTN がこの音声ゲートウェイへのコールのルーティングを再開します(PSTN がこれらのトランクから完全にビジー アウトされていない場合)。 この設計手法では、すべてのゲートウェイの登録先プライマリ サブスクライバに障害が発生した場合に、コール センターですべてのゲートウェイ コールが失われてしまうリスクを制限するために、クラスタの複数の Cisco Unified CallManager コール処理サーバにまたがってゲートウェイを分散しています。

Cisco Unified CallManager の Cisco Unified Survivable Remote Site Telephony(SRST)オプションで使用される音声ゲートウェイも、同様のフェールオーバー プロセスに従います。 制御を受けている Cisco Unified CallManager から切断されると、ゲートウェイは SRST モードにフェールオーバーします。このモードでは、すべてのトランク コールが終了され、ゲートウェイが SRST モードにリセットされます。 コール制御のため、電話はローカルの SRST ゲートウェイに登録し直され、コールがローカルで処理され、ローカルの電話に誘導されます。 SRST モード時にはエージェントにデスクトップからの CTI 接続も存在しないとみなされるので、Unified CC ルーティング アプリケーション内でエージェントは受信不可として表示されます。 このため、これらのエージェントには Unified CC からコールが送信されません。 サイトのゲートウェイへのデータ接続が再確立されると、Cisco Unified CallManager がゲートウェイと電話の制御を再開し、エージェントの Unified CC への再接続が許可されます。

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

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

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

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

図3-4 は、Cisco Unified CallManager と CTI Manager のいくつかの機能を示したものです。

図3-4 Cisco Unified CallManager と CTI Manager の機能

 

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

図3-5 リモート Cisco Unified CallManager への CTI Manager デバイス要求

 

すべての Unified CC デバイスをクラスタ内の単一のサブスクライバに登録して、Peripheral Gateway(PG; ペリフェラル ゲートウェイ)がそのサーバを参照するようにする構成もありますが、この構成ではサブスクライバに高い負荷がかかります。 この場合 PG で障害が発生すると、二重 PG は別のサブスクライバに接続し、すべての CTI Manager のメッセージがクラスタ内をわたって元のサブスクライバまでルーティングされることになります。 デバイスおよび CTI アプリケーションを Cisco Unified CallManager クラスタ内のすべてのコール処理ノードにわたって適切に分散し、CTI トラフィックと潜在的なフェールオーバー条件を均等にすることが重要です。

外部 CTI アプリケーションは、CTI Manager 上の JTAPI ユーザ アカウントを使用して接続を確立し、この JTAPI ユーザに登録された Cisco Unified CallManager デバイスの制御を担います。 さらに、CTI Manager が互いに独立していることにより、どの CTI アプリケーションも、要求を実行するために任意の CTI Manager に接続できます。 ただし、CTI Manager は独立しているため、障害発生時にある CTI Manager が別の CTI Manager に CTI アプリケーションを渡すことができません。 最初の CTI Manager に障害が発生した場合、外部 CTI アプリケーションは、フェールオーバー メカニズムを実装して、クラスタ内の別の CTI Manager に接続する必要があります。

たとえば Agent PG は、サイド A とサイド B の二重サーバを使用して CTI Manager のフェールオーバーに対応しています。これらのサーバはそれぞれ、クラスタ内の異なるサブスクライバを参照するように設定されていますが、同時に参照することはありません。 PG プロセスは、両サイドが同時にアクティブにされるのを防止する設計になっています。 また、二重 PG サーバの両方が、同一の JTAPI ユーザを使用して CTI Manager アプリケーションにログインします。 ただし、Cisco Unified CallManager クラスタ内のシステム リソースを節約するため、JTAPI ユーザがユーザ デバイスを登録および監視できるのは、Cisco Unified CallManager PG の一方のサイドだけです。 Cisco Unified CallManager PG のもう一方のサイドは、ホットスタンバイ モードのまま、アクティブなサイドで障害が発生したときにただちにアクティブなれるように待機します。

図3-6 は、CTI Manager、Agent PG、および Unified IP IVR(CRS)を使用する 2 つの外部 CTI アプリケーションを示しています。 Cisco Unified CallManager PG は JTAPI アカウント ユーザ 1 を使用して CTI Manager にログインします。一方、Unified IP IVR(CRS)はアカウント ユーザ 2 を使用します。各外部アプリケーションがそれぞれ別の JTAPI ユーザ アカウントを使用しており、異なるデバイスが登録され、そのユーザによって監視されています。 たとえば、Cisco Unified CallManager PG(ユーザ 1)は 4 つすべてのエージェントの電話とインバウンド CTI ルート ポイントを監視し、Unified IP IVR(ユーザ 2)は自身の CTI ポートと JTAPI トリガーで使用される CTI ルート ポイントを監視します。 複数のアプリケーションで同じデバイスを監視できますが、複数のアプリケーションが同じ物理デバイスを制御しようとする競合条件が発生する可能性があるため、この方式は推奨していません。

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

 

Cisco Unified CallManager CTI アプリケーションは、サブスクライバにデバイスの重み付けを追加し、登録されたデバイスの監視に使用するメモリ オブジェクトを追加します。 これらの監視は、外部アプリケーションとの接続があるサブスクライバに登録されます。 すべての監視対象オブジェクトのトラッキングを担当することで 1 つのサブスクライバが過負荷に陥ることを避けるため、これらのアプリケーションは、複数のサブスクライバにわたる CTI Manager 登録に分散することが適切な設計です。

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

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 の割り当て

 

Unified IP IVR(CRS)に関する設計上の注意点

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

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

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

 

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

Cisco Unified CallManager の call-forward-busy および call-forward-on-error 機能。 この方式は比較的複雑です。少数の重要な CTI ルート ポイントおよび CTI ポートについて、Cisco Unified CallManager 内のコール処理レベルまでハイアベイラビリティが必要になる特殊なケースにだけ、この方式をお勧めします。

Unified IP IVR(CRS)にコールを送る前に Unified IP IVR(CRS)のアベイラビリティをチェックする Unified ICM スクリプト機能。


) Unified IP IVR(CRS)サブシステムとサービスを混同しないように注意してください。 Unified IP IVR(CRS)は、Cisco CRS Node Manager サービスという 1 つのサービスだけを使用します。 Unified IP IVR(CRS)サブシステムは、CTI Manager や Unified ICM などの外部アプリケーションとの接続です。


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 Customer Voice Portal(Unified CVP)の設計上の注意点

コール処理とコール キューイングのための Unified IP IVR(CRS)の代替として、Unified CVP を Unified CC とともに展開できます。 Unified CVP は、JTAPI コール制御のために Cisco Unified CallManager に依存しない点で、Unified IP IVR(CRS)とは異なります。 Unified CVP はコール制御に H.323 を使用し、ハイブリッド Unified CC または移行ソリューションの一部として、Cisco Unified CallManager またはその他の PBX システムの「前面で」使用されます (図3-9を参照してください)。

図3-9 2 つの Unified CVP コール制御サーバによるハイアベイラビリティの実現

 

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

Cisco Voice Gateway

Cisco Voice Gateway は通常、TDM PSTN トランクおよびコールを終端し、IP ネットワーク上の IP ベースのコールにトランスフォームするために使用します。 Unified CVP では特定の H.323 音声ゲートウェイを使用することで、Cisco Unified CallManager MGCP 制御モデル外の、より柔軟なコール制御モデルを実現します。 H.323 により、Unified CVP を Unified CC の複数の IP および TDM アーキテクチャに統合することが可能になります。 Unified CVP 制御の音声ゲートウェイは、Cisco IOS 組み込み Voice Extensible Markup Language(VoiceXML)ブラウザを使用して、コールを物理 IVR デバイスに移さずに、音声ゲートウェイ上で発信者処理とコール キューイングを行う機能も提供します。 また、Media Resource Control Protocol(MRCP)インターフェイスを使用し、Unified CVP 制御下でゲートウェイに Automatic Speech Recognition(ASR)および Text-To-Speech(TTS)機能を追加することもできます。

Unified CVP コール制御サーバ

Unified CVP コール制御サーバは、コールを着信ゲートウェイと別のエンドポイント ゲートウェイまたは Unified CC エージェント間で切り替える際、コール制御シグナリングを提供します。 また、Unified ICM VRU ペリフェラル ゲートウェイへのインターフェイスも提供し、特定の Unified ICM VRU コマンドを、Unified CVP 音声ゲートウェイでレンダリングされる VoiceXML コードに変換します。

Unified CVP メディア サーバ

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

Unified CVP Web サーバ

Unified CVP リリース 3.0 では、Eclipse ツールキット ブラウザを使用した VoiceXML サービス作成環境が提供されます。これは Unified CVP Web サーバでホスティングされます。 このサーバでは、ダイナミック VoiceXML スクリプトが実行される Unified CVP VoiceXML ランタイム環境もホスティングされ、外部システムおよびデータベース アクセスのための、Java および Web サービス呼び出しが処理されます。

H.323 ゲートキーパー

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

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

複数の Unified CVP コール制御サーバ間で自動的にコールのバランスを調整できるように、Unified ICM ペリフェラル ゲートウェイの制御下に冗長 Unified CVP システムを追加する。

TCL スクリプトを Unified CVP ゲートウェイに追加して、ゲートウェイが Unified CVP コール制御サーバに接続してコールを正しく送ることができない場合の処理が行われるようにする。

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

複数の Unified CVP メディア サーバ間の .wav ファイル要求のロードバランス、および、複数サーバ間の VoiceXML URL アクセスのロードバランスを調整するため、Cisco Content Server を追加する。


) Unified CVP コール制御サーバまたは Unified CVP PG に障害が発生しても、Unified CVP 内のコールはドロップされません。これは、音声ゲートウェイ内の(Unified CVP イメージで提供される)TCL スクリプトを使用した耐障害設計の一環として、別の Unified CVP 制御ゲートウェイ上の別の Unified CVP コール制御サーバに、コールをリダイレクトできるからです。


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

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

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

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

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

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

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

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

Agent Reporting and Management(ARM)および Task Event Services(TES)接続

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

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

 

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

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

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

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

Cisco Email Manager オプション

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

Cisco Email Manager サーバ:コア ルーティングおよび制御サーバ(冗長性なし)。

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

Cisco Email Manager UI サーバ:このサーバを使用することにより、エージェント ユーザ インターフェイス(UI)コンポーネントをメインの Cisco Email Manager サーバからオフロードできます。これにより、展開の規模を大きくすることや、複数の Unified Mobile Agent(Unified MA)サイトをサポートすることが可能になります。 各リモート サイトにローカル UI サーバを置くことにより、エージェント ブラウザ クライアントから Cisco Email Manager サーバへのデータ トラフィックを減らすことができます。 また、複数の UI サーバを設定すると、電子メール アプリケーションにアクセスするための冗長(セカンダリ)パスをエージェントに提供できます(図3-12を参照してください)。

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

 

図3-12 複数の UI サーバ

 

Cisco Collaboration Server オプション

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

Cisco Collaboration Server:コラボレーション サーバは、このサーバがサポートする企業 Web サーバとともに、DeMilitarized Zone(DMZ; 非武装地帯)内の企業ファイアウォールの外側に展開されます。 通常 Collaboration Server では最大 400 の同時セッションをサポートできますが、複数のサーバを展開してそれ以上のセッションを処理したり、プライマリ サーバに障害が発生したときに、エージェントがアクセスするバックアップのコラボレーション サーバとして使用することもできます。

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

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

Cisco Collaboration Dynamic Content Adaptor(DCA):このサーバは、コラボレーション サーバとともに DMZ 内に展開されます。このサーバによって、Web サイト上でプログラムによって動的に生成されるコンテンツ(静的な HTTP ページに対比して)を、システムで共有することが可能になります。 冗長性を得るために、複数の DCA サーバを設定し、コラボレーション サーバから呼び出せるようにすることも可能です。

図3-13 Cisco Collaboration Server

 

Cisco Unified Outbound Dialer(Unified OUTD)の設計上の注意点

Unified OUTD を使用すると、Unified CCE がカスタマーへのコールを、事前定義されたキャンペーンに基づいてエージェントに代わり発信できるようになります。 Unified OUTD の主要なコンポーネントは次のとおりです(図3-14 を参照してください)。

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

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

図3-14 Unified CC Unified OUTD

 

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

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

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

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

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

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

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

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

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

このマニュアル内では多くの場合、Agent PG に、Cisco Unified CallManager クラスタに接続する PIM プロセスが 1 つしかないように記載されていますが、Agent PG では、同一 Cisco Unified CallManager クラスタへの PIM インターフェイスを複数管理できます。これは、Unified CC 内に追加のペリフェラルを作成し、CTI ルート ポイントおよび電話の登録を 2 つの別のストリームに分離する場合に使用できます。 1 つのクラスタに 2 つの PIM を使用する必要があるのは、顧客の Unified CC の設定に多数の CTI ルートポイントがあるときだけです。 1 つの PIM では、1 秒あたり約 5 個の CTI ルートポイントを登録できます。 初期化とフェールオーバーに必要な時間を短縮するために、250 を超えるルートポイントがあるときには、2 番目の PIM を使用してください。 CTI ルートポイントの処理専用の別の PIM を Unified CCE PG に追加することをお勧めします。 このモデルでは、最初の PIM にはすべてのエージェントの制御が格納され、2 番目の PIM にはすべての CTI ルートポイントが格納されます。 この処置により、すべてのエージェントの電話機が登録される前に、CTI ルートポイント用の PIM でルートポイントを登録して、システムをオンラインにできるようになります。 このモデルを適用できるのは、Unified CCE モデルだけです。 System Unified CC では、Cisco Unified CallManager PIM を 1 つしか使用できないことに注意してください。

通常の PIM 始動プロセスでは、すべての監視対象オブジェクト(CTI ルート ポイント、着信番号、エージェントの電話、またはデバイス ターゲットなど)についてペリフェラルの登録が行われます。 これらのオブジェクトがすべて登録され、PIM 接続で適切に監視されるまで、PIM はアクティブになりません。

多くの Unified CC 実装では、少数の CTI ルート ポイントが使用され、多数のデバイス ターゲットが登録されます。 2 つの設定オブジェクトを 2 つの PIM に分けることで、CTI ルート ポイントを登録し、エージェントの電話またはデバイス ターゲットが登録されてアクティブになる前に、これをルーティング用に使用できます。 これは、PG または PIM の始動時およびフェールオーバー時に、Unified CC で CTI ルート ポイントをすぐに使用できるようにするという発想によるものです。これにより Cisco Unified CallManager は、エージェントの電話がすべて登録されていない場合でも、ルート要求を処理して、コール処理を開始できます。 つまり、PIM が着信コールを受け付けられない状態の場合、着信コールは、Cisco Unified CallManager のデフォルト Forward-On-Failure 処理に引き継がれるのではなく、発信者を即座にキューに入れたり、メッセージを再生したりすることで処理されます(ただし、この機能は、1 つの PG に 1 つの PIM しか許可されない System Unified CC では利用できません。 PIM の複数構成が許可されるのは、従来型の Unified CCE 構成だけです)。

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

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

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

 

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

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm70doc/coreicm7/plngup7/

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

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

二重 Agent PG 環境では、Agent PG の両サイドからの JTAPI サービスが、初期化時に CTI Manager にログインします。 Cisco Unified CallManager PG のサイド A がプライマリ CTI Manager にログインし、PG のサイド B がセカンダリ CTI Manager にログインします。 ただし、電話および CTI ルート ポイント用モニタを登録するのは、Cisco Unified CallManager PG のアクティブ サイドだけです。 二重化した Agent PG のペアは、ホットスタンバイ モードで機能し、アクティブ側 PG の PIM だけが Cisco Unified CallManager クラスタと通信します。 スタンバイ側は、セカンダリ CTI Manager にログインしてインターフェイスの初期化だけを行い、フェールオーバー時の使用に備えます。 Cisco Unified CallManager デバイスの登録および初期化サービスは、かなり長い時間を要します。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 分かかることがあり、この間エージェントはシステムにログインできません。Cisco Unified CallManager クラスタへの複数の PIM インターフェイスにデバイスを分散すると、この時間を短縮できます。

Cisco Unified CallManager では、1 つのクラスタで複数の PG または PIM 接続が許可されます。このため Unified CC は、異なるタイプの登録を複数の接続に分散できます。 たとえば、ある PIM では JTAPIuser1 としてログインするように設定して、これに CTI ルート ポイントだけを関連付け、次の PIM では JTAPIuser2 としてログインするよう設定して、これにエージェントの IP 電話を登録できます。 このように設定することで、エージェントは始動時にすぐにログインできるようになり、着信番号が CTI Manager に登録されるまで待つ必要はありません。

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 と相互接続できない

 

シナリオ 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 エージェントとして機能できません。

障害リカバリの理解

このセクションでは、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 サーバ

 

CTI OS に関する考慮事項

CTI OS サーバは、Cisco Unified CallManager ペリフェラル ゲートウェイ上で共存実行されるソフトウェア コンポーネントです。 CTI OS サーバ ソフトウェアは耐障害性に向けた設計になっており、通常、冗長化された物理サーバに展開されます。しかし、ホットスタンバイ モードで実行する PG プロセスとは異なり、両方の CTI OS サーバ プロセスが常にアクティブ モードで実行されます。 CTI OS サーバ プロセスは NodeManager で管理されます。NodeManager は、CTI OS サービスの一部として実行されている各プロセスを監視し、異常終了したプロセスを自動的に再始動します。

CTI OS は関連コンポーネントのフェールオーバーを、次のシナリオのように処理します(図3-24 を参照)。

図3-24 冗長 CTI OS サーバ プロセス

 

シナリオ 1: CTI サーバのサイド A(アクティブ)に障害が発生する

このシナリオでは、CTI サーバのサイド A が PG のサイド A と共存しています。次のイベントが発生します。

CTI サーバのサイド B がサイド A の障害を検出し、アクティブになります。

NodeManager が CTI サーバのサイド A を再始動し、アイドルになります。

CTI サーバ A への接続を失った後、CTI OS サーバのサイド A とサイド B の両方がすべての CTI OS クライアント/エージェント接続をドロップして再始動します。始動時、CTI サーバのサイド B への接続が確立されるまでは、CTI OS サーバのサイド A およびサイド B は CONNECTING 状態です。その後 CONFIGURING 状態になり、エージェント、コール状態、および設定情報がダウンロードされます。 状態が CONNECTING または CONFIGURING の間は、CTI OS サーバ A および B で CTI OS クライアント接続は許可されません。 CTI OS サーバと CTI サーバの同期が行われると、状態が ACTIVE になり、CTI OS クライアント接続の受け入れ準備が整います。

CTI OS クライアント 1 および 2 は CTI OS サーバとの接続を失い、接続する CTI OS サーバをランダムに選択します。 CTI OS クライアント 1 が CTI OS サーバ A または B のいずれかに接続します。CTI OS クライアント 2 も同様に接続します。この移行の間、CTI Toolkit Agent Desktop のボタンは無効になり、CTI OS に接続されると同時に動作状態に戻ります。

シナリオ 2: CTI サーバのサイド B(アイドル)に障害が発生する

このシナリオでは、CTI サーバのサイド B が PG のサイド B と共存していますが、これはアクティブのサイドではありません。 次のイベントが発生します。

CTI サーバのサイド A はアクティブのままです。

NodeManager が CTI サーバのサイド B を再始動し、アイドルの状態を継続します。

CTI OS クライアントも CTI OS サーバも、この障害の影響を受けません。

シナリオ 3: CTI OS サーバ A に障害が発生する

このシナリオでは、CTI OS サーバのサイド A のプロセスが、PG および CTI サーバのサイド A と共存しています。次のイベントが発生します。

CTI OS クライアント 1 がネットワーク接続の消失を検出し、CTI OS サーバ B に自動的に接続します。この移行の間、CTI Toolkit Agent Desktop のボタンは無効になり、CTI OS サーバ B に接続されると同時に動作状態に戻ります。

CTI OS クライアント 2 は CTI OS サーバ B に接続されたままです。

NodeManager が CTI OS サーバ A を再始動します。

シナリオ 4: CTI OS サーバ B に障害が発生する

このシナリオでは、CTI OS サーバのサイド B のプロセスが、PG および CTI サーバのサイド B と共存しています。次のイベントが発生します。

CTI OS クライアント 2 がネットワーク接続の消失を検出し、CTI OS サーバ A に自動的に接続します。この移行の間、CTI Toolkit Agent Desktop のボタンは無効になり、CTI OS サーバ A に接続されると同時に動作状態に戻ります。

CTI OS クライアント 1 は CTI OS サーバ A に接続されたままです。

NodeManager が CTI OS サーバ B を再始動します。

シナリオ 5: CTI OS クライアント 1 に障害が発生する

このシナリオでは、次のイベントが発生します。

エージェントが CTI OS クライアント 1 アプリケーションを手動で再始動します。

CTI OS クライアント 1 は接続する CTI OS サーバを 1 つランダムに選択します(CTI OS クライアント 1 は CTI OS サーバ A または B のいずれかに接続できます)。

接続後エージェントがログインし、CTI OS クライアント 1 が、接続先の CTI OS サーバからエージェント状態およびコール状態を取得して、状態を回復します。

シナリオ 6: CTI OS クライアント 2 に障害が発生する

このシナリオでは、次のイベントが発生します。

エージェントが CTI OS クライアント 2 アプリケーションを手動で再始動します。

CTI OS クライアント 2 は接続する CTI OS サーバを 1 つランダムに選択します(CTI OS クライアント 2 は CTI OS サーバ A または B のいずれかに接続できます)。

接続後エージェントがログインし、CTI OS クライアント 2 が、接続先の CTI OS サーバからエージェント状態およびコール状態を取得して、状態を回復します。

シナリオ 7:CTI OS クライアント 1 と CTI OS サーバ A 間のネットワーク障害

このシナリオでは、次のイベントが発生します。

CTI OS サーバ A が CTI OS クライアント 1 の接続をドロップします。

CTI OS クライアント 1 がネットワーク接続の消失を検出し、CTI OS サーバ B に自動的に接続します。この移行の間、CTI Toolkit Agent Desktop のボタンは無効になり、CTI OS サーバ B に接続されると同時に動作状態に戻ります。

シナリオ 8: CTI OS クライアント 1 と CTI OS サーバ B 間のネットワーク障害

CTI OS クライアント 1 は CTI OS サーバ A に接続されているので、この障害の影響を受けません。

シナリオ 9: CTI OS クライアント 2 と CTI OS サーバ A 間のネットワーク障害

CTI OS クライアント 2 は CTI OS サーバ B に接続されているので、この障害の影響を受けません。

シナリオ 10: CTI OS クライアント 2 と CTI OS サーバ B 間のネットワーク障害

このシナリオでは、次のイベントが発生します。

CTI OS サーバ B が CTI OS クライアント 2 の接続をドロップします。

CTI OS クライアント 2 がネットワーク接続の消失を検出し、CTI OS サーバ A に自動的に接続します。この移行の間、CTI Toolkit Agent Desktop のボタンは無効になり、CTI OS サーバ A に接続されると同時に動作状態に戻ります。

Cisco Agent Desktop に関する考慮事項

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

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

Unified ICM Enterprise とともに Unified CC システムを展開する際の設計上の注意点

Unified CCE 7.0 には、1 つの Unified ICM Enterprise システムで管理される単一のシームレスなコンタクト センター環境と、複数の Unified CC システムを相互に接続するための新しい展開モデルが導入されています。これにより、複数の Unified CC システムによる企業全体のルーティングおよびレポーティングが可能になります。 この展開モデルは 親/子 モデルと呼ばれ、Unified ICM が 1 つ以上の Unified CC システムの子 IP ACD を制御する親として機能します(図3-25を参照してください)。このモデルでは、Unified ICM Enterprise システムがコンタクト センターのネットワーク コール ルーティング エンジンとして設計され、Unified CVP および Unified CC ゲートウェイのペリフェラル ゲートウェイを使用したネットワーク キューイングにより、子 Unified CC システム(Unified CCE または Unified CCX)が接続されます。 子 Unified CC システムは独立した IP-ACD システムで、親 Unified ICM システムとの WAN 接続を失った場合、コール処理のフル機能をローカルで実行できます。 この構成により、Unified CC ソリューションで高レベルの冗長性とアベイラビリティが提供されます。これにより、集中型コール処理リソースとの接続が解除された場合でも、各サイトが Unified CC サイトとして機能し続けることができます。

図3-25 親/子の展開モデル

 

親/子コンポーネント

次のセクションでは、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 レベルでだけインストールすることが可能です。 これらはサイトごとに、ノードでの実装として扱われます。

アベイラビリティを高めるためのその他の注意点

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

レポーティング

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

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

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

詳細については、次の URL にある『 Reporting Guide for Cisco Unified CCE and Hosted Editions 』を参照してください。

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