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

目次

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

この章の新トピック

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

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

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

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

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

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

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

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

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

Cisco Email Manager オプション

Cisco Collaboration Server オプション

Cisco Interaction Manager の Cisco マルチチャネル オプション:E-Mail Interaction Manager(EIM)と Web Interaction Manager(WIM)

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

Unified CCE の統合

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

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

フェールオーバーの管理

Cisco Unified Outbound Option の設計上の注意点

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

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

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

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

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

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

Unified ICM の冗長化オプション

Unified CM の障害シナリオ

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

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

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

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

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

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

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

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

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

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

障害リカバリの理解

Unified CM サービス

Unified IP IVR

Unified ICM

Unified CM PG と CTI Manager サービス

Unified ICM VRU PG

Unified ICM Call Router と Logger

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

CTI サーバ

CTI OS に関する考慮事項

Cisco Agent Desktop に関する考慮事項

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

親/子コンポーネント

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

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

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

親/子コール フロー

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

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

親/子の耐障害性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「Cisco Email Manager オプション」

「Cisco Collaboration Server オプション」

「Cisco Interaction Manager の Cisco マルチチャネル オプション:E-Mail Interaction Manager(EIM)と Web Interaction Manager(WIM)」

「Cisco Unified Outbound Option の設計上の注意点」

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

「障害リカバリの理解」

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

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

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

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

この章の新トピック

表 3-1 は、この章の新トピックまたはこのマニュアルの前リリースから大幅な変更があったトピックの一覧です。

表 3-1 新しい情報またはこのマニュアルの前リリースから変更された情報

新規または改訂されたトピック
説明箇所

Cisco Interaction Manager

「Cisco Interaction Manager の Cisco マルチチャネル オプション:E-Mail Interaction Manager(EIM)と Web Interaction Manager(WIM)」

Computer Telephony Integration(CTI; コンピュータ テレフォニー インテグレーション)Manager または Peripheral Gateway(PG; ペリフェラル ゲートウェイ)のフェールオーバー

「Unified CM PG と CTI Manager サービス」

Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)

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


) この章に示された設計上の注意点と図は、多くの箇所が改訂および更新されています。Unified CCE システムを設計する前に、この章全体を見直すことをお勧めします。


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

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

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


) デモ、ラボ、および非本稼動の展開では、シンプレックス展開を選択できます。ただし、本稼動の展開では必ず ICM のコア コンポーネント(Router、Logger、PG、プレルーティング ゲートウェイ)を冗長化する必要があります。


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

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

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

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

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

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

 

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

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

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

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

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

Cisco Unified Communications Manager AutoAttendant またはハント グループによって応答される

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

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

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

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

 

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

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

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

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

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

図 3-3 の Unified CCE 設計は、音声コールが Public Switched Telephone Network(PSTN; 公衆電話交換網)から入力音声ゲートウェイを経由して Unified CCE エージェントに到達するまでのコール パスを示しています。この設計におけるネットワーク インフラストラクチャでは、データおよび音声トラフィック用 Unified CCE 環境がサポートされます。PSTN を含むネットワークが、Unified CCE ソリューションの基礎です。ネットワークにおける障害処理の設計が不十分な場合は、アベイラビリティの高い通信環境を維持するうえで、すべてのサーバおよびネットワーク デバイスがネットワークに依存することになるため、コンタクト センター内のすべてが障害の可能性にさらされます。したがって、データおよび音声ネットワークはソリューション設計の最重要部分であり、すべての Unified CCE 実装の早い段階で検討する必要があります。


) Network Interface Card(NIC; ネットワーク インターフェイス カード)とイーサネット スイッチは、すべての Unified ICM コア コンポーネント サーバについて、10/100 リンクの場合は 100 MB 全二重に設定し、ギガビット リンクの場合はオートネゴシエートされるように設定することをお勧めします。


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

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

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

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

 

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

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

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

ゲートウェイのトランクのキャパシティを計算する際は、ゲートウェイのフェールオーバーについて考慮し、1 つ以上の音声ゲートウェイに障害が発生しても最大 Busy Hour Call Attempts(BHCA; 最頻時発呼数)を十分に処理できるようにしてください。設計段階で、まずそのサイトで音声ゲートウェイ障害が同時に何件発生する可能性があり、何件まで許容できるかを決めます。この要件と、使用する音声ゲートウェイの数、およびこれらの音声ゲートウェイにまたがるトランクの配置から、通常モード時および災害モード時に必要となるトランクの総数を求めることができます。トランクを複数の音声ゲートウェイに分散するほど、障害モード時に必要なトランクは少なくなります。ただし、使用する音声ゲートウェイまたはキャリア PSTN トランクを増やすと、ソリューションのコストが増大します。このため、ゲートウェイの障害時にもコールを処理できるという利点とコストを比較する必要があります。また、ゲートウェイのフォームファクタについても考慮が必要です。たとえば、Cisco AS5400 音声ゲートウェイ シャーシの 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 または SIP を使用する Cisco IOS 音声ゲートウェイの場合、この音声ゲートウェイ自体は動作しているにもかかわらず、Unified CM サーバとの通信パスに重篤な状態が発生する可能性があります(イーサネット接続の障害など)。このような状況になった場合は、 busyout-monitor interface コマンドを使用して音声ゲートウェイ上のイーサネット インターフェイスを監視できます。音声ポートをビジーアウトモニタ ステートにするには、 busyout-monitor interface voice-port 設定コマンドを使用します。音声ポートのビジーアウトモニタ ステートを解除するには、このコマンドの no 形式を使用します。前述のとおり、Unified CM のコール制御インターフェイスを使用できない場合、これらのゲートウェイでは追加の処理オプションによって、コールを別のサイトまたは別の着信番号へ再ルーティングしたり、ローカルに保存された .wav ファイルを発信者に流してコールを終了できます。

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

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

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

Cisco Unified CM では CTI Manager が使用されます。CTI Manager はアプリケーション ブローカとして機能するサービスで、すべての CTI リソースを処理するために、特定の Unified CM サーバに対するアプリケーションの物理バインディングを抽象化します(CTI Manager のアーキテクチャの詳細については、『 Cisco Unified Communications Solution Reference Network Design (SRND) 』を参照してください)。CTI Manager と CallManager は、同じ Unified CM サーバで動作する 2 つの独立したサービスです。Unified CM サーバで動作するサービスには、他に Trivial File Transfer Protocol(TFTP; トリビアル ファイル転送プロトコル)、Cisco Messaging Interface、Real-time Information Server(RIS; リアルタイム情報サーバ)データ コレクタ サービスなどがあります。

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

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

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

図 3-4 CallManager と CTI Manager サービスの機能

 

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

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

 

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

外部 CTI アプリケーションは、Unified CM 内の CTI が有効なユーザ アカウントを使用します。CTI Manager サービスにログインして接続を確立し、この特定の CTI が有効なユーザ アカウント(通常、JTAPI ユーザまたは PG ユーザと呼ばれます)に関連付けられた Unified CM デバイスを制御します。さらに、CTI Manager が互いに独立していることにより、どの CTI アプリケーションも、要求を実行するためにクラスタ内の任意の CTI Manager に接続できます。ただし、CTI Manager は独立しているため、障害発生時にある CTI Manager が別の CTI Manager に CTI アプリケーションを渡すことができません。最初の CTI Manager に障害が発生した場合、外部 CTI アプリケーションは、フェールオーバー メカニズムを実装して、クラスタ内の別の CTI Manager に接続する必要があります。

たとえば、Agent PG は、サイド A とサイド B の二重 サーバを使用して CTI Manager のフェールオーバーに対応しています。これらのサーバはそれぞれクラスタ内の異なるサブスクライバを、これらのサブスクライバの CTI Manager を使用して参照するように設定されています。重要なのは、PG からのこれらの接続がホット スタンバイ モードで管理されることです。つまり、特定の時点では PG の 1 つのサイドだけがアクティブであり、サブスクライバ上の CTI Manager に接続されます。PG プロセスは、Unified CM に対する CTI アプリケーションの影響を減らすため、両サイドが同時にアクティブになるのを試みないように設計されています。また、二重 PG サーバの両方(サイド A とサイド B)が、同一の CTI が有効な JTAPI または PG のユーザを使用して CTI Manager アプリケーションにログインします。ただし、Cisco Unified CM クラスタ内のシステム リソースを節約するため、JTAPI ユーザがユーザ デバイスを登録および監視できるのは、Cisco Unified CM PG の一方のサイドだけです。Unified CM PG のもう一方のサイドは、ホットスタンバイ モードのまま、アクティブなサイドで障害が発生したときに接続、ログイン、登録、およびアクティブ化できるように待機します。

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

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

 

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

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

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

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


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

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

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

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


 

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

 

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

Unified IP IVR 内の JTAPI サブシステムは、Unified CM クラスタ内の異なるサブスクライバ上の 2 つの CTI Manager と接続を確立できます。この機能により、Unified CCE の設計では、Unified ICM ペリフェラル ゲートウェイ接続などの CTI Manager レベルで Unified IP IVR の冗長性を追加できます。さらに、複数の冗長な IP-IVR サーバを設計に組み込み、Unified ICM コール ルーティング スクリプトが使用可能な IP IVR リソース間でコールを自動的にロード バランシングできるようにすることをお勧めします。

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

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

 

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

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

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

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

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


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


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

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

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


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


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

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

図 3-9 H.323 を使用した 2 つの Unified CVP コール制御サーバによるハイ アベイラビリティの実現

 

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

Cisco Voice Gateway

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

Unified CVP コール サーバ

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

Unified CVP メディア サーバ

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

Unified CVP VXML アプリケーション サーバ

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

H.323 ゲートキーパー

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

SIP プロキシ サーバ

SIP プロキシ サーバは、Unified CVP で、音声ブラウザを選択して特定の着信番号に関連付けるために使用します。コールがネットワークに到達すると、ゲートウェイは SIP プロキシ サーバに問い合せて、着信番号に基づきコールの送信先を検索します。

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

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

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

HSRP または H.323 でのゲートキーパー クラスタリングで、ゲートキーパーの冗長性を追加する。

複数の 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/en/US/products/sw/custcosw/ps1006/tsd_products_support_series_home.html

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


) この項は、2007 年に導入された Cisco Interaction Manager、E-Mail Interaction Manager(EIM)、または Web Interaction Manager(WIM)の各製品には適用されません。この項の内容は Cisco E-Mail Manager(CEM)および Cisco Collaboration Server(CCS) 5.x 製品だけが対象であり、これらの製品は新しいお客様には提供されなくなっています。


Unified CCE ソリューションは、マルチチャネル カスタマー コンタクトをサポートするように拡張できます。これにより、電子メールおよび Web によるコンタクトを、Unified CCE によってエージェントにルーティングできるようになります(ブレンド モードまたはユニバーサル キュー モードを使用します)。次のオプション コンポーネントを Unified CCE アーキテクチャに統合します(図 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 CCE CTI サーバからマルチチャネル システムに、コール(ARM)および非音声(TES)の状態およびイベントを通知するサービスです。これらの接続により、電子メールおよび Web 環境にエージェント情報が提供されます。また、これらの環境からのタスク要求を受容および処理できるようになります。この接続は、エージェントに関連付けられた CTI サーバに接続する TCP/IP ソケットです。これは、エージェント ペリフェラル ゲートウェイ上の冗長または二重ペアとして展開できます。

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

 

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

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

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

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

Cisco Email Manager オプション

Cisco Email Manager を Unified CCE と統合することにより、Unified CCE によるマルチチャネル コンタクト センターにおいて、電子メールのサポートを強化できます。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 CCE によるマルチチャネル コンタクト センターにおいて、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 CCE エージェント ペリフェラル ゲートウェイはそれぞれの Media Blender を持ち、各 Media Blender はメディア ルーティング ペリフェラル ゲートウェイ上にメディア ルーティング Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)コンポーネントを持ちます。

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

図 3-13 Cisco Collaboration Server

 

Cisco Interaction Manager の Cisco マルチチャネル オプション:E-Mail Interaction Manager(EIM)と Web Interaction Manager(WIM)

2007 年に、5 .x バージョンのマルチチャネル製品に代わる製品として Cisco E-Mail Manager(CEM)および Cisco Collaboration Server(CCS)が導入されました。置き換え前の元の製品は、2 つの異なる製品であり、それぞれが独自の統合方法と、エージェントおよび管理者に対する Web インターフェイスを備えていました。新しい Cisco Interaction Manager(CIM)プラットフォームは単一のアプリケーションであり、共通の Web サーバとエージェントおよび管理者用のページを使用して、電子メールと Web の両方の対話管理機能を提供します。新しい製品は、Unified CCE プラットフォームと統合して、異なるメディア チャネルからエージェントへのコンタクトのユニバーサル キューイングを提供するように設計されています。

Interaction Manager プラットフォームに関する設計情報の詳細については、次の URL にある『 Cisco Unified Web and E-Mail Interaction Manager Solution Reference Network Design (SRND) Guide for Unified Contact Center Enterprise, Hosted, and ICM 』を参照してください。

http://www.cisco.com/en/US/products/ps7236/products_implementation_design_guides_list.html


) Cisco Interaction Manager(EIM/WIM)4.2(1)リリースは、Unified ICM または Unified Contact Center Enterprise 7.5(1)ではサポートされていません。詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/compatibilty_matrix/guide/ipcc75compat.pdf にある互換性情報を参照してください。


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

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

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

 

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

外部クライアント

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

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

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

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

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

ティア 1:Web サーバ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unified CCE の統合

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

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

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

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

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

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

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

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

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

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

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

フェールオーバーの管理

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

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

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

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

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

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

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

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

Cisco Unified Outbound Option の設計上の注意点

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

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

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

メディア ルーティング ペリフェラル ゲートウェイ:Unified Outbound Option やマルチチャネル製品などの「非インバウンド音声」システムからルート要求を受け付けることができるソフトウェア コンポーネント。Unified Outbound Option ソリューションでは、各 Dialer は、メディア ルーティング ペリフェラル ゲートウェイ上のそれぞれの Peripheral Interface Manager(PIM)と通信します。

図 3-15 Unified CCE Unified Outbound Option

 

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

すべての展開で、ダイヤラは、Unified CM の Unified CCE ペリフェラル ゲートウェイ上に共存します。Unified System CCE 7.5( x )では、System の展開モデルに必要なサーバ数を減らせるように、アウトバウンド コントローラをエージェント コントローラ上にインストールできます。

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

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

障害発生時にセカンド ダイヤラに自動復旧できるように、二重化された Unified CCE ペリフェラル ゲートウェイのサイドごとに 1 つのダイヤラという形で複数のダイヤラを展開し、Campaign Manager 内でそれらのダイヤラを使用します。複数のダイヤラを使用する場合は 2 つのオプションがあります。まず、同じポート数を使用してセカンド ダイヤラを設定できます(100% の冗長性)。また、2 つのダイヤラは独立して動作し、両方が同時にアクティブになるので、2 つのダイヤラ間でポートを分けることもできます。ダイヤラ ポート数が少ない設計では、ポートを分けると、キャンペーンのパフォーマンスに影響する場合があります。

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

音声ゲートウェイに障害が発生した場合にダイヤラがコールを発信するのに十分なトランクを使用できるように、アウトバウンド ダイヤリングの冗長音声ゲートウェイを展開します。アウトバウンドが主な用途である場合、これらのゲートウェイはアウトバウンド コール専用になります。

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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


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

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

 


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


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

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

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

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

 

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

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

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

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

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

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

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


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

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


 

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

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

Unified ICM の冗長化オプション

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

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

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

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

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

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

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

JTAPI Gateway

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

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

Agent PG Peripheral Interface Manager(PIM)

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

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

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

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

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

Unified CM の障害シナリオ

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

その他の考慮事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

障害リカバリの理解

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

Unified CM サービス

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

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

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

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

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

Unified IP IVR

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

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

Unified ICM

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

Unified CM PG と CTI Manager サービス

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

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


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


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


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


Unified ICM VRU PG

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

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

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

 

Unified ICM Call Router と Logger

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

Unified ICM Call Router

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

CTI サーバ

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

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

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

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

 

CTI OS に関する考慮事項

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

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

図 3-26 冗長 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 サーバに自動フェールオーバーと冗長性を提供します。Unified CM ペリフェラル ゲートウェイまたは 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 CCE システムを展開する際の設計上の注意点

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

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

 

親/子コンポーネント

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

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

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

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

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

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

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

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

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

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

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

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

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

Progger の構成

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

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

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


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


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

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


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


親/子コール フロー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

親/子の耐障害性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

レポーティング

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

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

エージェントがログアウトすると、エージェントのレポーティング統計がすべて停止します。次回エージェントがログインしたときには、エージェントのリアルタイム統計がゼロから始まります。通常は、Unified ICM セントラル コントローラのフェールオーバーによって強制的にエージェントがログアウトされたり、エージェントの統計情報がリセットされたりすることはありませんが、PG フェールオーバーの場合は、エージェントの統計値をメモリ内に維持する PIM および OPC プロセスが再起動されるため、エージェントの統計情報はリセットされます。CTI OS または CAD サーバがフェールオーバーまたは再起動しなかった場合、エージェント デスクトップ機能はフェールオーバー前の状態に復元されます。

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

http://www.cisco.com/en/US/products/sw/custcosw/ps4145/products_user_guide_list.html