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

Unified ICM コンポーネント

Unified ICM コンポーネントは、典型的な Unified ICM コンポーネント セット（ルータ、Logger、HDS など）です。これらのコンポーネントは、エージェントの状態データの収集と追跡、ルーティング スクリプトを通じた着信コールの処理、適切なエージェントに対する発信者のキューイングと接続などの通常のジョブを実行します。Expert Advisor ソリューションには、3 つの Peripheral Gateway（PG; ペリフェラル ゲートウェイ）が含まれます。

• Unified CM PG：JTAPI を通じて Unified CM に接続します。図 7-1 に示されている Unified CM PG は 1 つだけですが、通常の二重化およびサイジングのルールと推奨事項が適用されます。なお、Unified CM は展開の必須部分ですが、Unified CM PG は必須ではなく、従来型の Unified CCE エージェントが展開に含まれない場合は省略できます。

• VRU PG：GED-125 を通じて Unified CVP（または他の一部のサービス制御 VRU）に接続します。ここでも、図に示されている VRU PG は 1 つだけですが、通常の二重化およびサイジングのルールと推奨事項が適用されます。

• Expert Advisor PG：これは Unified ICM の新しいコンポーネントであり、Unified EA をサポートするために特別に設計されています。Expert Advisor PG は Unified CCE Gateway PG と同じ実行可能ファイルですが、Unified EA を使用した場合に受信されるコール イベントは終端イベントだけであるという事実をサポートするように機能します。図 7-1 に示す設定では、PG および Unified EA ランタイム サーバが二重化されていると想定していますが、シンプレックス設定もサポートされます。

Unified EA は、Unified System CCE の展開の一部としてはサポートされません。

Unified Customer Voice Portal（CVP）

Unified CVP は、Unified EA ソリューションのオプションのコンポーネントですが、強く推奨されます。Unified EA および任意の Unified ICM ソリューションで、Unified CVP は、エキスパート アドバイザで構成されるグループを含む任意のスキル グループのキューに含まれるコールのためのキューイング プラットフォームを提供します。さらに Unified CVP は、Unified ICM 用の高度な IP コール制御機能も提供します。

Unified CVP を含まない Unified EA の展開には、次のような制限があります。

• 別のサービス制御 VRU（IP-IVR やサードパーティ製品など）をキューイング プラットフォームとして用意する必要があります。キューイングが不要な場合、ルーティング スクリプトで使用できるのは選択ノードまたは同様の非キューイング スキル グループ選択ノードだけです。

• 選択したアドバイザの電話がビジー、到達不能、または応答不能の場合、コール配信は失敗し、Unified ICM ルーティング スクリプト内で処理できるイベントに必ずしもつながりません。

• Unified ICM 内の一部のコール ディスポジション レポーティング フィールドが正確でない可能性があります。これは、Unified CVP は一部の SIP エラーを適切な Unified ICM Termination Call Detail ディスポジション コードに明示的に変換するからです。

• 発信者がエキスパート アドバイザを待機しているものの、もはや Unified ICM にキューイングされていない場合、Unified CVP は擬似呼び出しトーン音声を発信者に対して自動的に再生します。Unified CVP 7.0 は、宛先固有の呼び出しトーン機能を備えています。これにより、前述の場合に呼び出しトーンを保留音で置き換えることができます。しかし、Unified CVP を使用しない場合、発信者は無音の状態で待たされることになります。

Unified CVP Release 4.1 もサポートされますが、Unified CVP 7.0（2）またはそれ以降のメンテナンス リリースを推奨します。Unified EA で Unified CVP 4.1 を使用した場合、次の制限があります。

• Unified CVP 4.1 を通過するコールは、ビデオをサポートしません。

• コールが送信されたときにエキスパートの電話がビジーだった場合、Unified ICM で再クエリーが行われ、ルーティング スクリプトで適切な処理を行うことが可能になります。しかし Unified CVP 4.1 では、再クエリー状態でビジーと他の種類の接続障害を区別することはできません。

• 宛先固有の呼び出しトーンは Unified CVP 4.1 で使用できません。したがって、発信者がエキスパート アドバイザを待機している間に、呼び出しトーンを保留音で置き換えることはできません。

（注） すべての Unified EA の展開ではコール シグナリングに SIP を使用するため、Unified CVP も H.323 ではなく SIP 用に展開する必要があります。一方、コールが PSTN または他の手段を通じて Unified EA にトランスレーション ルーティングされる場合など、Unified CVP が Unified EA への直接 SIP 接続を確立しない展開では、Unified CVP を展開するシグナリング タイプに制限はありません。

コール制御およびプレゼンス インフラストラクチャ コンポーネント

ゲートウェイ

ゲートウェイ（図 7-1 を参照）は、2 つの目的を果たします。まず、PSTN から到達するコールに対して、ゲートウェイは TDM から IP への変換を提供します。また、Unified ICM がコールのキューイングを必要とする場合、Unified CVP はゲートウェイを使用して VXML 音声ブラウザ サービスを提供し、音楽またはその他のプロンプトを再生します。Unified CVP を含まない展開では、TDM から IP への変換を提供する他の何らかの方法と、他の何らかのキューイング プラットフォームが必要です。

Cisco Unified Communications Manager（Unified CM）

Unified CM は、すべての Unified EA の展開で必須です。Unified CM は、最低でも、コールがエキスパート アドバイザに配信されるアドレスをプロキシします。言い換えると、Unified EA はエキスパート アドバイザにコールを配信する場合、Unified CM にコールを接続するよう依頼します。Unified CM で設定可能なすべてのアドレスは、Unified EA がコールをアドバイザに送信できる有効なアドレスです。これには、ローカルおよびリモートの宛先、ハント グループおよびピックアップ グループ、携帯電話またはハード フォンへの PSTN を通じたアウトバウンド コール、ボイスメール転送番号、Mobile Connect リモート宛先番号などが含まれます。

Unified CM は、コールを発信するためにも使用できます。通常、そのようなコールは、Unified CCE エージェントによってコンサルト操作の形式で開始されますが、Unified CM に接続された IP 電話を保持する、企業の任意のメンバーから行われることもあります。

Cisco Unified Presence

Cisco Unified Presence は、サポート対象の Instant Messaging（IM; インスタント メッセージング）クライアントへのインターフェイスを提供するものであり、すべての Unified EA の展開で必須です。究極的な目標は、Cisco Unified Presence がサポートするすべての IM クライアントを Unified EA でサポートすることですが、このリリースでは、Cisco Unified Personal Communicator、IP Phone Messenger（IPPM）、および Microsoft Office Communicator だけがサポートされます。Cisco Unified Presence は、SIP SIMPLE プロトコルを通じて、ユーザがログインし、アクティブ化および非アクティブ化されたときに通常のプレゼンス更新を Unified EA に提供します。この方法で、Unified EA は連絡可能なエキスパート アドバイザを把握します。また、Unified EA と個々のエキスパート アドバイザの間の IM メッセージは、Cisco Unified Presence によってプロキシされます。Microsoft Office Communicator の展開では、Cisco Unified Presence サーバがドメイン間連合を経由して Microsoft Office Communications Server（OCS）に接続し、OCS が個々の Microsoft Office Communicator IM クライアントに接続します。さらに、Cisco Unified Presence ユーザのリストは、AXL プロトコルを通じて Unified EA と共有されます。したがってお客様は、両方のシステムでユーザを冗長に設定する必要はありません。

（注） この方法では、Cisco Unified Personal Communicator ユーザと IPPM ユーザだけをインポートできます。Microsoft Office Communicator ユーザは、Unified EA で手動で設定するか、Unified EA の一括インポート ツールでファイルからインポートする必要があります。

最後に、Cisco Unified Presence サーバは、組み込みの SIP プロキシ サーバも含んでいます（図 7-1 には示されていません）。特に重要なのは、プロキシ サーバのスタティック ルート テーブルです。ここでは、SIP 番号計画全体を 1 箇所で維持できます。スタティック ルート テーブルは、プライマリ ランタイム サーバが SIP メッセージを受け入れることができない場合に、SIP メッセージがバックアップ ランタイム サーバに対して自動的に再試行するようにして、Unified EA ハイ アベイラビリティ戦略でも機能します。このテーブルは、ロード バランシング戦略の一部として Unified CVP にも使用されます。

したがって、Unified EA は 3 つの方法で Cisco Unified Presence と通信します。第 1 にシミュレーションされた通常のプレゼンス ユーザ（実際には、ランタイム サーバごとに 1 ユーザ）として、第 2 に AXL アプリケーション ユーザとして、第 3 にコール制御を目的とした SIP ユーザ エージェントとして通信します。

Cisco Unified Personal Communicator

Cisco Unified Personal Communicator はシスコのインスタント メッセージングとプレゼンスのクライアントであり、通常は、個別のユーザのデスクトップで実行されます。Unified EA の展開では、このコンポーネントは Unified EA システムに対するエキスパート アドバイザのプライマリ インターフェイスとして機能します。これは、プレゼンス情報を Cisco Unified Presence に送信し、エキスパート アドバイザがインスタント メッセージングを使用して Unified EA とやり取りできるようにします。これは、音声とビデオもサポートし、Unified EA はハード フォンを使用できない場合に着信コールを Cisco Unified Personal Communicator に直接送信できます。Unified Expert Advisor は、Cisco Unified Personal Communicator クライアントと Microsoft Office Communicator クライアントのいずれかをサポートします。同じインストール環境で両方をサポートすることはできません。

IP Phone Messenger（IPPM）

IPPM（図 7-1 には示されていません）は、特定の Cisco IP Phone で実行される IM およびプレゼンスのクライアントです。これは、Unified EA で Cisco Unified Personal Communicator の代替機能としてサポートされます。

Microsoft Office Communicator

Microsoft Office Communicator はインスタント メッセージング（IM）とプレゼンスのクライアントです。IM クライアントとして Unified Expert Advisor で使用できますが、ソフトフォンとしては使用できません。Unified Expert Advisor は、Cisco Unified Personal Communicator クライアントと Microsoft Office Communicator クライアントのいずれかをサポートします。同じインストール環境で両方をサポートすることはできません。現在のところ、エキスパート アドバイザには、Microsoft Office Communicator ソフトフォン用の Cisco Unified Communications Integration ^TM はサポートされていません。

エキスパート アドバイザ の定義

エキスパート アドバイザは、従来のコンタクト センターのエージェントとは具体的に 2 つの点で異なります。

• 電話への応答はアドバイザの主要なジョブではありません。

• アドバイザは、多くの場合、モバイルであり、さまざまなタイミングにさまざまな番号で連絡を取ることができます。

電話による回答は、エキスパートの主要な仕事ではなく、担当者は電話に出ることができない場合や、電話を受けようとしない場合があります。Unified EA は、ポップアップの IM メッセージを使用して、アドバイザに対してまずタスクを提供することにより、アドバイザがコールを受けることができるようにします。その後、アドバイザは、そのコールを拒否することも、まったく応答しないこともできます。Unified EA は、プレゼンス テクノロジーを活用して、電話に出ることができない状態に対して対応します。基本的に、プレゼンスまたは IM クライアントが、アドバイザが対応できる状態であることを示している場合、Unified EA はそのアドバイザにタスクを提供します。

モバイルであることは、アドバイザが固定番号により連絡が取れない場合があることを意味します。Unified EA は、複数のアドレス、優先アドレス、さらに音声とビデオに対応する Cisco Unified Personal Communicator クライアントを直接使用する（そのため、電話を完全にバイパスする）オプションのプレゼンスまでも管理者が設定できるようにして、この可能性に対応します。アドバイザは、IM 応答を使用して、携帯電話番号などの以前設定された電話番号とは異なる電話番号を指定することもできます。

Unified EA 管理者は、スキル、それらのスキルの能力レベル、および任意の属性を各エキスパート アドバイザに割り当てます。これらの要素は、その後、さまざまな割り当てキューでメンバシップに対応するアドバイザの資格を与えるために使用できます（「割り当てキューと Unified ICM スキル グループ」を参照）。

Cisco Unified Presence のユーザ リストの同期

すべてのエキスパート アドバイザは、まず、Cisco Unified Presence でユーザとして定義される必要がありますが、すべての Cisco Unified Presence ユーザがエキスパート アドバイザになる必要はありません。Unified EA は、名前、ログイン ID、電話番号、および電話番号の優先度で構成されるすべての設定されたユーザについての基本情報を Cisco Unified Presence からインポートするプロセスをサポートします。この情報がインポートされると、Unified EA の画面を使用して、どのユーザがエキスパート アドバイザと見なされるかを示し、それらのユーザに対してスキルや属性情報などの EA 固有の設定を追加する必要があります。Unified EA には、基本情報を手動で入力する方法は用意されていません。Cisco Unified Presence からインポートする必要があります。

この「同期」プロセスは、自動的に、初期設定の時点で実行され、その後は、デフォルトでは毎晩深夜 0 時に実行されますが、実行時間と頻度は設定可能です。また、Unified EA 管理者は、同期をオンデマンドで要求できます。ただし、インポート プロセスを完了するためにかけることができる時間は、設定されている Cisco Unified Presence のユーザの数に応じて、5 分までであることに注意してください（「Cisco Unified Presence の同期タスクのスケジューリング」も参照してください）。

割り当てキューと Unified ICM スキル グループ

エキスパート アドバイザは、さまざまな割り当てキュー（AQ）のメンバとして設定されますが、任意の AQ に含めるように柔軟に設定できます。管理者は、明示的に AQ メンバをリスト化するか、指定された AQ のメンバシップを定義するために存在するスキル、能力レベル、および属性値のセットを設定します。管理者は、この後に、各エキスパート アドバイザのスキル、能力、および属性値を設定する場合があります。AQ メンバシップはスタティックですが（これは設定によってだけ変更できます）、指定された AQ のアベイラビリティはダイナミックであり、エキスパート アドバイザのログイン状態、プレゼンス状態、およびコールに対する現在のアクティビティによって異なります。

各割り当てキューは、Unified ICM 内の 1 つのスキル グループだけに直接対応します。管理者は、常に最初に Unified EA で AQ を設定する必要があります。その後で、自動設定プロセスによって自動的に Unified ICM 内の対応するスキル グループが設定されます。すべての追加オブジェクトは、Unified ICM のコンフィギュレーション マネージャ ツールを使用して設定する必要があります。詳細については、 http://www.cisco.com で入手できる『 Administration and Configuration Guide for Cisco Unified Expert Advisor 』を参照してください。

Unified EA スキル グループには、エキスパート アドバイザだけを含めることができます。同じスキル グループに他の Unified ICM エージェントとエキスパート アドバイザを混在させることはできません。ただし、Unified ICM からは、エキスパート アドバイザを含むスキル グループは、従来のエージェントを含むスキル グループと違いがないものとして認識されます。単一の [Queue to Skill Group] ノードには、必要に応じて、従来のスキル グループとエキスパート アドバイザのスキル グループの両方を含めることができます。

エキスパート アドバイザのアベイラビリティの状態

エキスパート アドバイザのアベイラビリティ状態は、その担当者のプレゼンスのクライアントによって決定されます。そのアドバイザのプレゼンスのクライアントが Cisco Unified Presence にログインしていない場合、その担当者は割り当てキューにログインしていないため、Unified ICM スキル グループにもログインしていません。このアドバイザのプレゼンス クライアントにログインしており、使用可能な場合、そのエキスパートはメンバとなっているすべての割り当てキュー（および Unified ICM スキル グループ）に対応可能です。アドバイザのプレゼンス クライアントにログインしていても 「アウェイ」 である場合は、ごの割り当てキューまたは Unified ICM スキル グループでも対応可能ではありません。

Cisco Unified Personal Communicator クライアントでは、他の IM クライアントと同様に、ユーザがそのユーザのドロップダウン リストに表示されるプレゼンス状態のリストを修正できます。同様に、Unified EA では、これらのプレゼンス状態が割り当てキューと Unified ICM スキル グループのアベイラビリティ ステータスにどのようにマッピングされるかを管理者が手動で定義できます。

Unified EA による Unified ICM Enterprise ルーティング セマンティクスの使用

Unified ICM からは、Unified EA は Enterprise Routing Service（ERS）ペリフェラルの 1 つとして認識されます。Unified CCE の子およびその他の任意の従来のサードパーティ ACD と同様に、Unified ICM ルータは、スキル グループから仮想エージェントを選択しますが、その後、コールをエージェントではなくペリフェラルにルーティングします。その後、Unified ICM にどのエージェントが実際にコールを受信したかを示すかどうかは、ペリフェラルによって決定されます。

また、Unified CCE の子とサードパーティ ACD と同様に、エージェントがコールを受信するまでしばらく時間がかかる場合があります。この受信までの時間の間に、要求される可能性がある任意のローカル キューイングに対してペリフェラルが応答します。一方で、Unified ICM は、コールを受け入れることができるエージェントがいることを合理的に確認できるまでコールを送信しないように、スクリプト化する必要があります。Unified EA の場合、ローカルのキューイング時間には、エキスパート アドバイザにタスクが提示されている間だけでなく、タスクを受け入れるアドバイザがいない場合の時間も含まれるため、長くなる可能性があります。その場合、割り当てキューのエキスパート アドバイザが応答可能になるまで、コールは Unified EA の制御下にあります。

次の「長くなる呼び出し時間を管理するための戦略」の項では、このキューイング時間の影響を軽減するための方法について説明します。

長くなる呼び出し時間を管理するための戦略

前述のとおり、アドバイザにタスクを提示する Unified EA のプロセスを考慮すると、コールはキューイングが完了したあと、応答されないまましばらくの間 Unified EA の制御下に置かれる場合があります。この間、発信者は呼び出しトーンを聞いています。次の方法を使用することにより、発信者に与えるマイナスの印象を軽減できます。

• Unified CVP 7.0 以降をルーティング サービスおよびキューイング プラットフォームとして使用している場合は、Unified CVP の設定によりコールが Unified EA の制御下にある間、特別な呼び出しトーンを提供できます。呼び出しトーンに音楽ファイルなどの .wav ファイルを指定し、特定のアウトバウンド着信番号に基づいてその呼び出しトーンを適用できます。この場合は、Unified CVP から Unified EA へのコール転送に使用されるトランスレーション ルートのアドレス パターンに基づきます。詳細については、Unified CVP のマニュアルのカスタム呼び出しトーンのパターン機能に関する説明を参照してください。

• 管理者は、コールが Unified ICM に戻される前に Unified EA で未応答の状態になっている時間を制限することもできます。指定した秒数以内に Unified EA へのコールが応答されるように、アウトバウンド SIP コールで Unified CVP の無応答（RNA）タイムアウト機能を設定できます。指定した時間内に応答されなかったコールは Unified CVP によって取り消され、無応答を示す再クエリー コードにより Unified ICM ルーティング スクリプトで再クエリーが実行されます。Unified CVP 4.1 では、このタイムアウトはグローバル ベースでだけ設定できることに注意してください。Unified EA の宛先に他の宛先と異なる値を設定できません。

• 管理者は、エキスパートがコールに応答する確率を高めるためのさまざまな機能を利用できます。たとえば、割り当てキューの定義でブロードキャスト番号を増やすと、複数のエキスパートに同時にタスクを提示できるようになるため、初回の提示でエキスパートが応答する確率が高まります。また、エキスパート アドバイザがタスクを拒否できないように個人ベースで設定することもできます。これらのアドバイザはタスク依頼のメッセージを受信することはなく、コールだけを受信します。ビジネス慣例としては、最後の手段としてこの方法により特定のユーザを設定するのが適切な場合もあります。この場合、常に誰かの電話が鳴っています。

• 次に示す手法はコールが Unified EA に受信されるまでの時間を確実に短縮できますが、その内容を検討してください。Unified EA には、IM クライアントで [Not Available] と設定しているエキスパート アドバイザに対してもタスクを提示できる機能が用意されています。つまり、これらのエキスパート アドバイザはタスクに対して応対不可を選択できません。この設定は AQ ごとに設定できます。そのため、管理者は同じメンバシップ ルールを使用し、このフラグの設定だけを変えて 2 つの並行した AQ を作成します。次に、Unified ICM スクリプト エディタでエスカレーティング キューを作成して、標準のキューに応対可能なエージェントがいない場合、一定の時間が経過したらこの特別なキューがリストに追加されるようします。この方法を使用すると、IM クライアントにログインはしているが、「不在」状態になっているエキスパート アドバイザをコールに応対可能と見なし効率的に活用できます。

属性

属性は、着信コールおよび各エキスパート アドバイザに関連付けることができる、ユーザが設定可能な変数です。着信コールに関連付ける場合、属性の値を Unified ICM コール変数または Extended Call Context（ECC; 拡張コール コンテキスト）変数から設定したり、発信者を表す SIP エンドポイントで指定された任意の SIP ヘッダー変数から設定したりできます。また、ANI、DNIS、GUID などの追加の標準コール コンタクト情報は、デフォルトでそれぞれのシステム定義属性に格納され、コール関連属性のセット全体は ContactDetail に構成されます。ContactDetail は、各コールについてレポーティング サーバと Unified ICM 履歴データベースの両方に格納される呼詳細レコードのベースとなります。

エキスパート アドバイザに関連付けると、属性を使用し、さまざまな割り当てキューに対し個々のアドバイザが適切であるかどうかを判別できます。たとえば、YearsInJob と呼ばれるエキスパート アドバイザ属性の値に 2 が設定されているアドバイザは、5 年以上の経験を持つアドバイザにコールを設定する割り当てキューから除外されます。

特別なコンタクトを処理するために最適なエキスパート アドバイザを選択する場合、選択戦略が空間的である割り当てキューで属性が判別されます。Unified EA は、エキスパート アドバイザや着信コールに関連付けられた属性を数字のように比較し、多くの値の中で属性の一致度が最も高いアドバイザから順番に選択していくことができます。これは N 次元ルーティングと呼ばれる場合もあります。

タスクが提示または割り当てられるとき、属性はエキスパート アドバイザのプレゼンス クライアント ウィンドウにも表示されます。これにより、プレゼンス クライアントは「ライトウェイト CTI デスクトップとしてのプレゼンス クライアント」で説明するように、ライトウェイト CTI デスクトップの一種として機能します。

各属性は、エキスパート アドバイザの IM クライアント、レポーティング サーバ、およびシステムのデバッグ ログに対して表示、マスキング、または非表示のいずれかに設定できます。Unified EA 管理者は、この方法を使用して、個々の属性について使用目的、履歴データベースに保持するかどうか、およびログに書き込む情報に機密情報が含まれていないかを制御できます。

属性の定義、マッピング、特性、エキスパート アドバイザおよび割り当てキューへの関連付けは、すべて管理者が実行時に変更できます。変更はただちに反映されます。

IM メッセージ セット

Unified EA は、プレゼンス クライアントを通じて IM メッセージ形式でエキスパート アドバイザと通信します。これらの IM メッセージはメッセージ セットに集約されます。メッセージ セットは多数のロケールにローカライズされ、形式とコンテンツに関しては完全にカスタマイズ可能です。新しいメッセージ セットを作成することもできます。さらに、各エキスパート アドバイザを特定のロケールだけでなく、特定のメッセージ セットに割り当てることができます。

特に重要な 3 つのメッセージは、コンタクト応対リクエスト通知、コンタクト応対通知、および コンタクト応対キャンセル通知 です。デフォルトで、これらのメッセージについて事前に設定された US English バージョンは次のとおりです。

• コンタクト応対リクエスト通知：「Are you available to handle this contact?（このコンタクトに応答可能でしょうか。）」

• コンタクト応対通知：「Please standby for incoming call.（コンタクトの着信をお待ちください。）」

• コンタクト応対キャンセル通知：「The system has cancelled the task.（タスクがキャンセルされました。）」

コンタクト応対リクエスト通知は、エキスパート アドバイザに着信コールを知らせ、受け入れるか断るかを応答するよう促します。複数のアドバイザがコールに対応する場合がありますが、実際に受け付けるのは 1 人だけです。応答に少し遅れたアドバイザはコンタクト応対キャンセル通知を受信し、一番先に応答したアドバイザは着信を待つように指示されるコンタクト応対通知を受信します。

以前に説明したように、アドバイザはコンタクトを拒否できる場合とできない場合があります。コンタクトを拒否できないアドバイザは着信を待つように通知されるコンタクト応対通知だけを受信します。この場合、コンタクト応対リクエスト通知はありません。

Unified EA メッセージ セットにはインバウンド メッセージも含まれます。インバウンド メッセージはアドバイザがクエリーに応答するために使用するフォーマットの正規表現の記述です。これらもカスタマイズ可能です。管理者はこのカスタマイズ機能を利用して、一部のエキスパート アドバイザから特定の可能性を除外できます。たとえば、企業ポリシーによって管理者の事前の設定がない限りアドバイザが携帯電話でコールに対応することが許可されていない場合、管理者は、アドバイザが携帯電話番号を指定するためのフォーマットを示す正規表現を削除できます。

ライトウェイト CTI デスクトップとしてのプレゼンス クライアント

メッセージ セットのメッセージの多くには、アドバイザの名前やコールの日時などのシステム変数が組み込まれます。メッセージには ContactDetail 属性からデータを組み込むこともできます。また、ContactDetail 属性は Unified ICM コール変数、ECC 変数、またはカスタム SIP ヘッダー フィールドから取得できます。この方法により、Unified ICM ルーティング スクリプトでエキスパート アドバイザにコール コンテキスト情報を提供できるようになり、プレゼンス クライアントはライトウェイト CTI デスクトップとしての役割を果たします。プレゼンス クライントをこの方法で使用する場合、次のガイドラインおよび条件が適用されます。

• 属性の表示

通常、Unified EA の属性はエージェントによって表示可能または表示不可に設定できます。エージェントが表示可能に設定した属性は、コンタクト応対リクエスト通知メッセージとコンタクト応対通知でエキスパート アドバイザに自動的に表示されます。Cisco Unified Personal Communicator の場合、メッセージは HTML 形式で表示され、属性はメッセージのテキストの下に標準の HTML テーブルで表示されます。HTML をサポートしていないプレゼンス クライアントの場合、属性はリスト形式で表示されます。

• フォーマット機能の向上

前述のとおり、任意またはすべての属性をコンタクト応対リクエスト通知またはコンタクト応対通知のコンテンツに直接埋め込むことができます。必要に応じてテキストを調節できます。

• テーブルからの属性の削除

メッセージ テキストに属性を直接埋め込むと、HTML のテーブルまたはリストから属性が削除されません。属性を削除する唯一の方法は、属性定義自体で属性が Expert Advisor Client に表示されないようにマーキングすることです。このようにマーキングしても、属性が明示的に埋め込まれているメッセージ テキスト コンテンツに属性が表示されなくなることはありません。

• 重複表示の防止

属性テーブルは、[Contact Offer Request Notice] と [Contact Offer Notice] の両方に表示されます。そのため、コンタクトを拒否できるエキスパート アドバイザには、属性テーブルが 2 回表示されることになります。これが煩わしく不要な場合は、属性が Expert Advisor Client に表示されないように宣言し、各メッセージで必要な属性だけをこれらのメッセージに排他的に埋め込む必要があります。

• クリッカブル URL の表示

Cisco Unified Personal Communicator クライアントでは、情報がデフォルトの HTML 形式で表示されるときに、URL のフォーマットに一致するテキストが自動的にクリッカブル リンクの形式で表示されます。このリンクをクリックすると、ユーザの Web ブラウザが開き、指定のページが表示されます。この機能を使用すると、Unified ICM ルーティング スクリプトでバックエンド データベースやアプリケーション ゲートウェイ ソースから取得した情報に基づいて URL を構築し、コールを受けるエキスパート アドバイザにその URL を提供することが簡単にできます。この機能は、エキスパート アドバイザがコールを受けるときに発信者固有の Web ページをエキスパート アドバイザに直接提供するための非常に簡単な方法を提供します。

たとえば、顧客が Siebel や Salesforce.com などの Customer Relationship Management（CRM; カスタマー リレーションシップ マネジメント）アプリケーションのカスタム Web ページを、コールを受けるエキスパート アドバイザに送信することを望んでいるとします。どちらの場合も、他の多くの場合と同様に、特定の事例またはデータベース レコードを示す Web ページを、次の（仮定の）例のような URL で処理できます。

http://salesforce.com/cisco/display?page=detail&record_locator=AE6783X

これを行うために、Unified ICM ルーティング スクリプトは、発信者に関する決定済みの情報を使用し、そのコンポーネントと Unified ICM の式エディタのヘルプを連結して前述の文字列を構築します。Unified ICM ルーティング スクリプトは、Unified EA で前述のコンタクト応対通知に埋め込まれた属性にマップされる ECC 変数にこの情報を格納します。エキスパートは、コールを受け入れるときに、Cisco Unified Personal Communicator クライアントで URL を受け取り、Salesforce.com の該当するページを表示するためにその URL をクリックします。

マルチメディア

Unified EA の役割は発信者をエキスパート アドバイザに接続することです。ほとんどの場合、これは音声接続が確立されることを意味しますが、その他のメディア（特にビデオ）もサポートされます。ネゴシエートするメディアの決定は、エンドポイント（エキスパート アドバイザの電話と発信者の電話）に完全に委ねられます。SIP プロトコルの不可欠な部分であるネゴシエーション プロセスは、Unified EA を介して実行されます。ただし、Unified EA は、進捗状況の監視以外の処理は行いません。メディア自体（音声、ビデオ、またはその他）は、エンドポイントからエンドポイントに直接確立され、Unified EA を経由しません。

レポーティングの観点から、Unified EA は、コール中に使用されたメディアとそのメディアがいつどれだけの時間使用されたかを追跡し、そのデータをレポーティング サーバに書き込みます。Unified CVP 4.1 では、音声以外のメディアはサポートされていないことに注意してください。

セキュリティ

Unified EA には、次のような多数のセキュリティ機能が用意されています。

• 保守運用管理とプロビジョニング（OAMP）のセキュリティ

管理用の Web ページはすべて、Secure Socket Layer（SSL; セキュア ソケット レイヤ）（HTTPS プロトコル）を使用して提供されます。

• Unified Communications オペレーティング システムのルート アクセス

Unified Communications オペレーティング システムは Linux オペレーティング システムをベースにしています。一般に、Linux オペレーティング システムでは、システム上で機能を実行するために特別に付与されるルート アカウントが提供されます。Unified EA では、ルート アクセスは許可されませんが、Cisco Technical Assistance Center（TAC）がルート アクセスを必要とする稀なケースにおいてルート アクセスを開くための機能が用意されています。この手順はかなり複雑で、顧客と TAC の両方が権限を付与する必要があります。

• ユーザおよびユーザ管理

スーパーユーザと管理者の 2 つのレベルの管理ユーザが用意されています。スーパーユーザはシステム レベルの OAMP 機能にアクセスできます。これには、管理者と追加のスーパーユーザの両方を作成および管理する機能が含まれます。デフォルトのスーパーユーザもインストール時に 1 つ作成されます。デフォルトのスーパーユーザ以外はすべて Active Directory で認証されます。スーパーユーザは、追加のレポーティング ユーザ（レポートを実行できるユーザ）のセットを作成および管理することもできます。最後に、Informix ユーザがインストール時に 1 つ作成されます。Informix ユーザは、Informix のさまざまなインスタンスがネットワークを介して相互に通信できるようにするために内部で使用されます。レポーティング ユーザと Informix ユーザは Active Directory で認証されません。

• Active Directory

Unified EA では、Active Directory（AD）への SSL 接続がサポートされます。

• 自己署名証明書

証明書は、Unified EA クラスタ内の 3 つのサーバ間で自動的に交換されます。そのため、これらのサーバは、ActiveMQ メッセージ バス経由での（また、データベース レプリケーションのための）相互通信を安全に行うことができます。各サーバをクラスタに追加するときには、これらの証明書が交換できるように、追加済みのサーバが稼動中でなければなりません。そうでない場合、インストールが失敗します。

• 機密コール データ

Unified EA には、コール固有のデータを保持する属性という概念があります。暗証番号やパスワードなどの機密情報が特定の属性に含まれている場合は、これらの属性がログ ファイルに書き込まれたり、履歴レポーティング データベースに格納されたり、エキスパート アドバイザに表示されたりしないように設定することが簡単にできます。

• 侵入防御

Unified EA をインストールすると、Cisco Security Agent 5.2 も自動的にインストールされます。

（注） Unified EA では、SIP over TLS はまだサポートされていません。SIP over TLS には、コール制御アクティビティやインスタント メッセージングとプレゼンスの連携などが含まれます。

レポーティング

Unified EA でのレポーティングは、Unified ICM によって収集された情報と Unified EA レポーティング サーバによって収集された情報を結合することによって行われます。一般に、Unified ICM レポーティングは、従来の ACD に対してレポートする情報をレポートするために使用されます。一方、Unified EA レポーティング サーバは、エキスパート アドバイザに固有の情報を処理します。

Unified EA レポーティング サーバには、割り当てキュー、エキスパート アドバイザ、およびコンタクトに関する履歴情報を収集する Informix IDS データベースが含まれています。サンプルのレポート テンプレートが用意されており、これを使用すると、Unified EA によってコールが制御されていた期間における割り当てキューのアクティビティ、エキスパート アドバイザのアクティビティ（コンタクト拒否率を含む）、エキスパート アドバイザのプレゼンス統計、コンタクトの詳細情報をカバーする履歴レポートや、音声およびビデオがいつ使用されたかを示すメディア レポートを生成できます。Crystal Reports および Cisco Unified Intelligence Center（Unified IC）Release 7.5(2) 以降に対応する 2 つのテンプレートが用意されています。2 つのテンプレートはともに同じ機能を提供します（Cisco Unified Intelligence Suite は、Unified EA テーブル用の特別なサポートを提供しません）。

Unified ICM では、履歴形式およびリアルタイム形式のスキル グループ レポート、エージェント レポート、およびエージェント スキル グループ レポートを使用できます。前述のように、レポーティング サーバは Unified EA のオプションのコンポーネントです。レポーティング サーバがインストールされていない場合は、Unified ICM によって提供されるレポートしか使用できません。

エキスパート ユーザのログイン数が 3000、各エキスパート ユーザが属する割り当てキューの数が 10、各エキスパートの 1 時間あたりの持続率が 2 という最大負荷を想定した場合、Unified EA レポーティング サーバは約 8 日分のデータを保持できます（キャパシティ情報の詳細については、「Unified CCE のコンポーネントとサーバのサイジング」の章を参照してください）。設定可能な保持期間を過ぎたデータを削除するために、1 日に 2 回実行される自動削除メカニズムがあります。データは常に 24 時間単位で削除されます。

エキスパートのログイン数が少ない、エキスパートあたりの割り当てキュー数が少ない、またはコール率が低い顧客は、それに応じて長い保持期間を設定できます。ただし、望ましい設定を見極めるためのテストが必要になります。削除メカニズムは、データベースがキャパシティの上限に近づいた場合にも自動的に実行されます。したがって、最初に長い保持期間を設定し、その後で徐々に保持期間を短縮しても問題ありません。ただし、安全性と予測可能性を高めるために、長期的にはキャパシティのしきい値に依存せずに固定期間を選択することを推奨します。

サービサビリティ

その他のサービサビリティ機能は、Unified EA OAMP ログイン画面の Navigation ドロップダウン メニューにある Unified Communications オペレーティング システムの Serviceability アプリケーションから継承されます。Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）バージョン 1 ～ 3 と SYSLOG の両方もサポートされます。

一部の機能は Unified Communications オペレーティング システムの Command Line Interface（CLI; コマンドライン インターフェイス）からも利用できます。これらの機能には、任意のプラットフォームの管理者がアクセスできます。

また、Unified EA では、SNMP トラップ メカニズムを基盤とするシステム条件と呼ばれる新しい概念が導入されています。システム条件は、Unified EA の内部において警告または重大度のいずれかで定義され、一度発生するとクリアされるまで存続します。システム条件が発生するかクリアされると、SNMP トラップも発生します。ただし、トラップ イベントが発生しなかったとしても、RTMT を使用してシステム条件の現在の状態を確認できます（ただし、現在のバージョンの RTMT では、システム条件は読みやすいフォーマットで表示されません）。Unified EA System のシステム条件のリストについては、 http://www.cisco.com にある『 Real Time Monitoring Tool Administration Guide for Cisco Unified Expert Advisor 』を参照してください。

Unified Communications オペレーティング システムへのルート アクセスは可能ですが、Unified CM のルート アクセスと同様に、Cisco TAC と顧客の承認を伴う詳細な手順が必要になります。このようにして取得したパスワードは、限られた時間しか使用できません。一方、顧客またはパートナーの通常のアクティビティを実行する場合には、ルート アクセスは必要ありません。

Unified EA コンポーネント

Unified EA は、単一のランタイム サーバまたは二重のランタイム サーバのいずれかで展開できます。どちらの場合も、単一のレポーティング サーバを追加できます。これら 4 つのオプションを図 7-2 に示します。

図 7-2 Unified EA コンポーネントのサーバ展開オプション

レポーティング サーバを追加しない場合の影響については、「レポーティング」を参照してください。また、単一のランタイム サーバの展開と二重のランタイム サーバの展開のトレードオフについては、「ランタイム サーバのハイ アベイラビリティ」を参照してください。

スケーラビリティを向上させるための複数の Unified EA クラスタの展開

現在のバージョンの Unified EA では、最大 3000 のエキスパート アドバイザがサポートされます。ただし、Cisco Unified Presence 6. x クラスタでは 10,000 ものユーザがサポートされ、そのうちの 3000 以上をエキスパート アドバイザとして設定できます。単一の Unified EA で現在サポートされるよりも多くのエキスパート アドバイザを収容するために、複数の独立した Unified EA クラスタを個別のペリフェラルとして同一の Unified ICM に展開できます。各クラスタは単一または二重にすることができ、それぞれにレポーティング サーバを含めることができます。ただし、レポーティング サーバは共有できません。

図 7-3 に示すように、別々の Unified EA クラスタが同一の Cisco Unified Presence クラスタと通信するように設定できます。これらの Unified EA クラスタからの割り当てキューは、単に Unified ICM の個別のスキル グループにマッピングされます。ただし、個別のスキル グループは、スキル グループ ノードへの同一のキューで両方のスキル グループをリストすることで、常に同種のペアとして扱うことができます。

図 7-3 複数の Unified EA クラスタと単一の Cisco Unified Presence クラスタ

2 つの Unified EA クラスタが同じ Cisco Unified Presence クラスタを共有する場合、これらの Unified EA クラスタは同一の Cisco Unified Presence ユーザ セットをインポートします。機能的には、両方の Unified EA クラスタでこれらのユーザ セットをすべてエキスパート アドバイザとして設定するのが安全です。ただし、このように設定すると、Unified ICM で各アドバイザが 2 つのエージェントとしてカウントされるため、レポートおよび統計で不整合が生じます。したがって、Unified EA 内で Cisco Unified Presence ユーザのリストを分割し、一方のユーザ セットが一方の Unified EA クラスタでエキスパート アドバイザとして設定され、もう一方のユーザ セットがもう一方の Unified EA クラスタでエキスパート アドバイザとして設定されるようにすることが重要です。

さまざまな Cisco Unified Presence 展開での Unified EA の展開

Cisco Unified Presence 6. x は、Cisco Unified Presence および Cisco Unified CM の両方のクラスタリングに関してさまざまな方法で展開できます。この項では、各シナリオが Unified EA でどの程度サポートされるかを説明します。

Cisco Unified Presence のハイ アベイラビリティ

Cisco Unified Presence 6. x および 7. x は、一般にパブリッシャ サーバとサブスクライバ サーバで構成されるクラスタ設定をサポートします。クライアントはどちらのサーバにも接続でき、必要に応じてサーバ間にメッセージが流れます。パブリッシャとサブスクライバのいずれかに障害が発生する停止期間中でも、すべての負荷の処理を他のサーバに任せることができます。Cisco Unified Presence 6. x の環境下では、障害が発生したサーバにログインしている Cisco Unified Personal Communicator クライアントは、残ったサーバに自動的にフェールオーバーしません。ユーザは明示的にログアウトと再ログインを行う必要があります。Cisco Unified Presence 7. x の環境下では、Cisco Unified Personal Communicator クライアントは、このフェールオーバーを自動的に行うことができます。

反対に、Unified EA は、残った Cisco Unified Presence サーバに自動的にフェールオーバーしません。Unified EA では、Cisco Unified Presence サーバのアドレスを 1 つだけ設定できます。そのサーバに障害が発生した場合、Unified EA は、障害が発生したサーバが復旧するまでアウト オブ サービスになります。

コール制御でも同様に Cisco Unified Presence サーバの SIP プロキシ サーバ 1 台だけに接続するように設定できます。現在のところ、自動的に2 台目の SIP プロキシ サーバに SIP 要求を再試行する機能はありません。

一方、Cisco Unified Personal Communicator および IP Phone Messenger（IPPM）のユーザ リストを Unified EA にインポートするためには、パブリッシャとサブスクライバの両方を設定できます。Unified EA は、必要であれば自動的に順に接続を試みます。

SIP、インスタント メッセージング、およびプレゼンスのために、両方の Unified EA ランタイム サーバを Cisco Unified Presence パブリッシャだけに接続するように設定します。これは、Microsoft Office Communicator の展開では、一般に Microsoft Office Communications Server（OCS）と連合するサーバと同じものにするのがベスト プラクティスです。

ドメイン内のクラスタ間展開

Unified EA では、現在、ドメイン内のクラスタ間展開はサポートされていません。このシナリオでは、2 つ以上の Cisco Unified Presence クラスタがそれぞれの個別の Cisco Unified CM クラスタと連携するように構成されます。各 Cisco Unified Presence クラスタは、独自の設定済みユーザ ベースを保持していますが、各ユーザに関するある程度の情報を相互に共有します。そのため、ある Cisco Unified Presence クラスタのユーザは、別の Cisco Unified Presence クラスタのユーザに対してプレゼンスの確認や IM メッセージの送信を行うことができます。

ただし、Unified EA では、この展開はサポートされません。1 つの Unified EA クラスタは、正確に 1 つの Cisco Unified Presence クラスタに接続されている必要があり、そのクラスタに属するユーザのユーザ リストだけをインポートできます。

エキスパート アドバイザが別の Cisco Unified Presence クラスタに属している場合は、別の Unified EA クラスタも展開する必要があります。

ドメイン間の展開

現在、Unified EA は、異なるドメインに展開される Cisco Unified Presence クラスタをサポートしません。エキスパートはすべて、同じドメインに入る必要があります。

エキスパート アドバイザが Microsoft Office Communicator を使用する展開は、Cisco Unified Presence と Microsoft Office Communicator Server 間にドメイン間連合リンクを定義することによって実際に動作します。ただし、Unified Expert Advisor の単一展開では、IM クライアントとして Cisco Unified Personal Communicator を使用するエキスパートと、Microsoft Office Communicator を使用するエキスパートが混在する状態をサポートできません。一部でも Microsoft Office Communicator を使用するのであれば、全体で Microsoft Office Communicator を使用する必要があり、ドメイン名はすべて Microsoft Office Communications Server（OCS）のドメイン名になります。したがって、ドメインは Cisco Unified Presence サーバとは異なりますが、この場合でもすべてのエキスパートが同じドメイン内に属します。

WAN 経由のクラスタリング

Cisco Unified Presence 7.0 サーバは、WAN リンクを介して分割された単一のクラスタとして展開できます。このタイプの展開は、WAN 経由のクラスタリングと呼ばれます。ただし、WAN の遅延要件は非常に厳格で、WAN 接続でこの要件を満たすのは困難であるため、このような展開が行われることはまずありません。そのため、この構成の Unified EA はテストされておらず、現在はサポートされていません。

WAN 経由のクラスタリングの詳細については、 http://www.cisco.com/go/designzone にある 『 Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 』 を参照してください。

Cisco Unified Presence プロキシ サーバを使用した展開

Cisco Unified Presence には、プレゼンス サーバだけでなく SIP プロキシ サーバも含まれています。これらは両方とも Unified EA 展開に必要です。Unified EA 展開のプロキシ サーバには 2 つの目的があります。1 つは 1 箇所で SIP ダイヤル プラン全体を定義する手段としての目的で、もう 1 つは Unified EA フェールオーバー戦略における不可欠の要素としての目的です。

Cisco Unified Presence 6. x サーバではフェールオーバーはサポートされませんが、プロキシ サーバではサポートされます。また現在、Unified EA は、こうしたプロキシ サーバ 1 台だけを参照するように設定できます。ここでは、SIP プロキシ サーバ間のフェールオーバーはサポートされません。

Unified CVP が展開に含まれる場合、Unified CVP で Cisco Unified Presence パブリッシャを SIP プロキシ サーバの 1 つとして使用し、ダイヤル プランの設定を 1 回だけで済むようにする傾向があります。しかし、この利点については、パフォーマンスに及ぼす影響を比較検討する必要があります。パブリッシャとしての既存の負担に加え、IM サービスとプレゼンス サービス、SIP プロキシ サービス、（Microsoft Office Communicator の展開では）Microsoft Office Communications Server（OCS）への連合オーバーヘッドなどの負担が 1 台の Cisco Unified Presence サーバにかかります。

Unified EA ランタイム サーバと Unified ICM PG の関係

ランタイム サーバは、単一または二重のいずれかにすることができます。単一の構成では、単一の Unified ICM PG と二重の Unified ICM PG の両方がサポートされます。ただし、ランタイム サーバを二重化する場合は、Unified ICM PG も二重化する必要があります。

これらの種類の構成を行う場合は、次の点を考慮する必要があります。

• 単一のコンポーネントは展開においてシングル ポイント障害になります。

• エキスパート アドバイザの Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）と二重化された別の PIM（Cisco Unified Communications Manager の PIM など）が共存する場合は、ランタイム サーバ自体が単一であっても、エキスパート アドバイザの PIM も二重化する必要があります。ただし、この要件に従ってもマシン数が増加することはありません。このシナリオでは、エキスパート アドバイザの PIM を保持するために新しいマシンが導入されることはないからです。

Unified ICM を使用した小規模展開

サーバ数を削減して小規模展開を実現するために、Unified ICM PG を PIM で共有し、複数の PG を同じ物理マシンでホストすることができます。ただし、これは、Unified ICM のサイジング ガイドライン、共存ルール、および物理的近接性ルールが順守される場合に限ります。ほとんどの Unified EA インストールには、VRU ペリフェラル（Unified CVP の場合）、Cisco Unified CM ペリフェラル、および Expert Advisor ペリフェラルが含まれています。Cisco Unified CM および Expert AdvisorのPG は、それぞれのペリフェラルの近くに物理的に配置するのが最も適しています。ただし、VRU PG は、ペリフェラルの近くに配置する必要はありません。

共存ルールは次のとおりです。

• 1 台のマシンでホストできる PG は 2 つまでです。

• 1 つの PG でホストできるペリフェラルのタイプ（PIM のタイプ）は 2 つまでです。

• 1 つの PG で 2 つのペリフェラル タイプをホストするには、次の条件が満たされている必要があります。

– PG は Generic PG として設定されていなければならない。

– いずれかのタイプが VRU PG でなければならない。

ほとんどの場合、Setup と PG Explorer を使用して、これらの制限を満たさないマシンを設定できます。ただし、PG を開始した場合、実際に開始されるのは 2 つだけです。

ランタイム サーバのハイ アベイラビリティ

Unified EA ランタイム サーバはアクティブ方式またはスタンバイ方式で動作します。通常は、プライマリ サーバがアクティブになり、バックアップ サーバ（ハイ アベイラビリティ サーバとも呼ばれます）がスタンバイ モードになります。通常の状況では、すべてのコールがアクティブ サーバによって処理されます。スタンバイ サーバが実行する唯一の処理は、エキスパート アドバイザのログインおよびプレゼンスの状態を追跡することです。ただし、この処理は、フェールオーバーが発生した場合にすべてのデータを一度に収集するのを回避するためにだけ実行されます。

図 7-4 に示す二重 PG および Unified EA ランタイム マシンを設定するためのルールは次のとおりです。

• PG A はプライマリ ランタイム サーバに接続する必要があります。

• PG B はバックアップ ランタイム サーバに接続する必要があります。

• PG A とバックアップ ランタイム サーバ（または PG B とプライマリ ランタイム サーバ）は相互接続ができません。

これは、プライマリ サーバとバックアップ サーバが WAN を介して物理的に異なるサイトに配置されていることを想定しているためです。Unified ICM の設計ガイドラインにより、PG サイド間の WAN リンクは高帯域幅（本質的に短い遅延）が保証されますが、PG とそのペリフェラル間の接続については、このような保証はありません。また WAN リンクを介してデータを転送すると、LAN リンクでは生じないセキュリティ上の問題が発生することがあります。

図 7-4 Unified ICM を使用したハイ アベイラビリティ展開

ランタイム サーバのフェールオーバーは、一度に 1 つのペリフェラルにしか接続しないという Unified ICM PG の保証に大きく依存しています。したがって、各ランタイム サーバは、Unified ICM PG からのアクティブな接続がある場合だけ自身がアクティブであることを認識します。実際には、2 つのランタイム サーバ間、およびアイドル サイドの PG と非アクティブなランタイム サーバ間には、ハートビートまたは他の直接通信はありません。

そのため、各 PG とそれに対応するランタイム サーバはタンデムにフェールオーバーします。アクティブなランタイム サーバに障害が発生したり、手動でサービスから外されたりすると、アクティブなランタイム サーバは自身を PG から切断し、Unified ICM がスタンバイ ランタイム サーバの PG をアクティブにします。次に、この PG がスタンバイ ランタイム サーバへの接続を確立します。これにより、スタンバイ ランタイム サーバがアクティブになります。

同様に、ある PG がそのスタンバイ PG にフェールオーバーすると、対応するランタイム サーバもフェールオーバーします。

フェールオーバー時のコールおよびエキスパート アドバイザの処理

フェールオーバー時のコールの処理は、フェールオーバーの原因によって異なります。一方では、アクティブ ノードの手動シャットダウンまたは何らかのソフトウェア障害のいずれかに起因するソフトウェア フェールオーバーが考えられます。他方では、ハードウェアまたはネットワークのいずれかの停止に起因するハードウェア フェールオーバーが考えられます。オペレーティング システム レベルの再起動もハードウェア フェールオーバーと同様に作用します。次の表に、これら 2 つのフェールオーバー モードの違いを示します。

「接続待ち」のコールとは、Unified EA ランタイム サーバがすでに受信したものの、エキスパート アドバイザにまだ接続されていないコールのことです。

エキスパート アドバイザがプレゼンス クライアントでログインするのは、Unified EA ではなく Cisco Unified Presence です。そのため、プレゼンス クライアントはフェールオーバーの影響を受けません。ただし、プレゼンス クライアントは Message Set メッセージを受け取ります。これは技術的な問題が発生したことを示すメッセージで、コール制御操作の実行に関する警告をプレゼンス クライアントに通知します。スタンバイ ランタイム サーバは、Unified ICM に関する各アドバイザのエージェントの状態を管理するジョブを引き継ぎますが、どのアドバイザが発信者と通話しているかを認識しません。そのため、一部のアドバイザは応答する準備ができていると見なされ、エキスパート アドバイザのアクティビティとは無関係な何らかの理由で通話しているときと同様に、コールに応答しているときにポップアップのタスク依頼を受け取ることがあります。当然、アドバイザはこのような依頼を無視または断ることができます。

レポーティング サーバのハイ アベイラビリティ

レポーティング サーバは常に単一構成で、両方のランタイム サーバからのレポーティング イベントを常時リッスンしています。1 つのコールは常に 1 台のランタイム サーバによって制御されるため、競合するイベントを受信する可能性はほとんどありません。競合するイベントが発生した場合は、データベース トリガーにより、これらのイベントのデータベースへの格納が自動的に防止されます。

レポーティング サーバに障害が発生した場合またはサービスが何らかの理由で停止した場合、レポーティング イベントは自動的にランタイム サーバ内にバッファされます。このバッファ領域のサイズは設定可能で、現在の推奨サイズはデフォルトの 2 GBです。これは数日分の通常動作をサポートするのに十分なサイズです。ただし、バッファがいっぱいになった場合、コールは引き続き正常に処理されますが、新着のレポーティング イベントは失われます。

フェールオーバー時のレポーティング イベントの処理

さまざまな割り当てキューに関するエキスパート アドバイザの状態変更イベントは、レポーティング サーバによって引き続き受信されます。これらのイベントはランタイム サーバのフェールオーバーに影響されないため、レポーティング サーバはバックアップ ランタイム サーバから引き続きイベントを受信するだけです。

コール イベントおよびタスク イベントは、コールまたはタスクの終了時だけレポーティング サーバによって受信されます。ただし、Expert Advisor PG は、これらのイベントをトランスレーション ルーティング時およびコールの終了時に受信します。これは次のような状況につながります（「フェールオーバー時のコールおよびエキスパート アドバイザの処理」の障害タイプの定義を参照してください）。

• ハードウェア フェールオーバー

レポーティング サーバには、フェールオーバー時にアクティブになっていた（開始済みでまだ終了していなかった）コールまたはタスクに関する情報は格納されません。ただし、Unified ICM には、Expert Advisor ペリフェラルの Termination Call Detail（TCD; 終端コール詳細）レコードが 1 つあります。TCD レコードは、フェールオーバーが発生した時点までのコールに関する情報を反映しており、ステータス コード 27（FAILED_SOFTWARE）を含んでいます。

• ソフトウェア フェールオーバー

レポーティング サーバには、フェールオーバー時にアクティブになっていたすべてのコールおよびタスクに関するレコードが格納されます。ただし、Unified ICM には、Expert Advisor ペリフェラルの TCD レコードが 1 つあります。TCD レコードは、フェールオーバーが発生した時点までのコールに関する情報を反映しており、ステータス コード 27（FAILED_SOFTWARE）を含んでいます。

設定データベースのハイ アベイラビリティ

OAMP 設定は、プライマリ ランタイム サーバの Informix データベースに保存され、Informix の組み込みレプリケーション メカニズムによってバックアップ ランタイム サーバにコピーされます。このように、各ランタイム サーバは、もう一方のランタイム サーバなしに単独で動作できます。ただし、OAMP Web サーバは、プライマリ ランタイム サーバ上でだけ動作します。したがって、OAMP 管理画面にアクセスできるのは、プライマリ サーバが動作している（ただし、エキスパート アドバイザおよびコールの観点からは必ずしもアクティブになっている必要はありません）場合だけです。

さらに、OAMP 設定のサブセットがレポーティング サーバにコピーされます。レポーティング サーバは、オブジェクト識別子をお客様向けの名前に対応付けるためにこの情報を使用します。また、レポーティング サーバは、設定変更の前に発生したイベントを、イベントのキャプチャ時に有効になっていた設定でレポートできるように、設定データの履歴を保持します。

設定データは複数の場所にコピーされますが、障害が発生したプライマリ サーバを再構築するためのソースとしては使用できません。システム管理者は、Data Recovery Framework（DRF）を使用して定期バックアップを実行し、必要に応じてそれらのバックアップから設定を復元する必要があります。

Microsoft Office Communicator Server のハイ アベイラビリティ

Cisco Unified Presence と Microsoft Office Communications Server（OCS）間の連合リンクは、冗長リンクではありません。OCS に接続できるのは、クラスタ内の 1 台の Cisco Unified Presence サーバだけです。その Cisco Unified Presence サーバに障害が発生するか、接続が失われた場合、バックアップ パスは存在しません。

ルータ再クエリーの使用

Unified CVP が展開に含まれる場合、コールに失敗しても、さまざまな理由により Unified CCE への再クエリーが呼び出され、エキスパート アドバイザにコールが到達します。Unified CCE ルーティング スクリプトにより、そのような障害が発生した場合のコールの処理方法を制御できます。この機能を利用するためには、スクリプトの [Queue to Skill Group] ノードの [Enable Requery] チェック ボックスをオンにします。それにより、「X」ブランチ コネクタがノードに表示されます。宛先に正常に到達したコールは通常、[Queue] ノードで終了しますが、再クエリーのコールは「X」ブランチを通過して次のノードに進みます。

スクリプトでは、スクリプト エディタ変数を調べて、再クエリーされた原因が無応答、ビジー、その他の接続障害のいずれであるかを判定できます。その時点でブランチを別の [Queue] ノードに接続してコールを再キューイングすると、適切な結果が得られる場合があります。

この再クエリー機能を展開に使用する場合は、次の注意点を考慮してください。

• 通常、複数または別のスキル グループを構成するなどして、2 番目のキュー ノードは 1 番目と異なるノードになるようにします。そうしないと、コールに対して 1 番目のキュー ノードとまったく同じ結果が生じる可能性があります。

• 同じ理由により、スクリプトが 1 番目のキュー ノードに戻らないように注意してください。異なる結果が得られるように、一部を変更することが重要です。

• サイジングを行う場合、キュー ノードから Expert Advisor にコールを送るたびに、そのコールは、新規コールとしてシステムに表示されます。したがって、単位時間あたりに Expert Advisor に到達したコールの総数は、実際の着信コールと再クエリーによって Expert Advisor に戻ったコールの数の和になります。

• Expert Advisor 自体は、以前のコールの再クエリーかどうかを認識しません。なお、そうしたコールは、ContactId は異なっても、同じ GUID と同じ Unified CCE Router Call Key で表示されるので、ログや履歴データベースで探すことができます。

フェールオーバー後のリカバリ

ランタイム サーバ A の処理能力が低下した場合、またはランタイム サーバ A がランタイム サーバ B にフェールオーバーした場合、新しいコールはすべてランタイム サーバ B によって処理されます。ある時点でランタイム サーバ A が復旧した場合でも、ランタイム サーバ A によるサービスの提供は部分的なものにとどまり、ランタイム サーバ B が引き続きアクティブ サーバとして動作します。ランタイム サーバ A が再びアクティブになるのは、ランタイム サーバ B を手動でシャットダウンした場合か、ランタイム サーバ A が障害の原因となっている自身の欠陥を検出した場合だけです。

ランタイム サーバ A がランタイム サーバ B にフェールオーバーしたら、管理者は、ランタイム サーバ A をできる限り早く復旧させるためにあらゆる努力を払う必要があります。ランタイム サーバ A が適切に動作するようになったら、管理者はランタイム サーバ B を手動でシャットダウンする必要があります。これにより、ランタイム サーバ A が再びアクティブになります。

通常、新規コールはランタイム サーバ B への送信を試みる前にランタイム サーバ A に送信しようとする（SIP プロキシ サーバのスタティック ルート設定の場合）ことから、遅延が発生する可能性があるため、一般にプライマリ ランタイム サーバをアクティブ ランタイム サーバにすることが推奨されます。ランタイム サーバ A が動作している場合は、それがアクティブでなくても、発生する遅延はわずかであり、通常は認識されません。しかし、ランタイム サーバ A がダウンした場合、遅延にはタイムアウトが含まれ数秒に及ぶこともあり、発信者が気になる可能性があります（タイムアウトは Cisco Unified Presence プロキシ サーバのサービス パラメータで設定できます）。

ランタイム サーバ A がダウンまたは長期間切断されることが予想される場合は、SIP プロキシ サーバのスタティック ルート テーブルで、プライマリ ランタイム サーバではなくバックアップ ランタイム サーバが最初の INVITE 要求を受信するように、優先順位を入れ替えることを推奨します。ただし、プライマリ サーバがオンラインに復帰したら、元の優先順位に戻すことを忘れないでください。

プライマリ ランタイム サーバをできるだけ早く復旧して実行中の状態に戻すことが重要である理由として、OAMP は、パーシャル サービス状態であったとしてもプライマリ ランタイム サーバが実行中にだけアクセス可能であるという点も挙げられます。現時点で、バックアップ ランタイム サーバをプライマリに昇格する方法はありません。

ルート パターンまたはルート ポイント

コールが Cisco Unified CM から Unified CCE に送信されるように設定する場合は、次の 2 つのことを決定します。最初に、着信番号が SIP トランクを介して Unified CVP に到達するルート パターンを通過するように設定するか、または着信番号が Unified ICM へのルート ポイントを通過するように設定するかを決定します。次に、コールが Unified ICM に到達し、ルーティング スクリプトが開始されたあと、キューイングが必要ない場合でも Unified CVP に転送する必要があるかを決定します。

関連するトレードオフについて、次の項で説明します。

• コールがルート ポイント経由でルーティングされ、ルーティング スクリプトの [Queue] ノードの前に [SendToVRU] ノードと [RunExternalScript] ノードのどちらも含まれていない場合に、参照スキル グループに応答可能なエキスパート アドバイザがいる（つまり、キューイングが必要ない）場合は、SIP INVITE は Cisco Unified CM から直接 Unified EA に送られ、Unified CVP をバイパスします。これは、Unified CVP ポートが不必要に占有されないことを意味します。ただし、Unified CVP が提供する拡張機能（擬似呼び出しトーン、障害発生時の再クエリー、タイムアウト時の再クエリーなど）は利用できません。

• 前述の状態でない場合は、1 つの SIP ダイアログが Cisco Unified CM と Unified CVP 間で確立され、別の SIP ダイアログが Unified CVP と Unified EA 間で確立されます。この場合、Unified CVP のすべての機能が利用できますが、コールのライフ中（発信者とエキスパート アドバイザが切断するまでの間）1 つの Unified CVP ポートおよびライセンスが占有された状態になることに注意してください。

さらに、コールがコンサルト、会議、または転送の形式で Unified CCE エージェントから送信されてくる場合は、常にルート ポイント経由でコールをルーティングする必要があります。これにより、Unified CCE はこのコールを Unified CCE エージェントによって処理されている最初のコールの一部として追跡できます。

これらのトレードオフを考慮すると、一般的なベスト プラクティスは、まずコールをルート ポイント経由でルーティングすることです。ただし、この場合、ルーティング スクリプトで [Queue] ノードの前に少なくとも [SendToVRU] ノードを含めます。こうすることで適切なレポート機能およびコール処理を実現できますが、コールのライフ中に Unified CVP ポート ライセンスが不必要に使用される可能性は否定できません。

また、Unified CCE エージェントをホストしない通信マネージャとして Cisco Unified CM を含める展開では、Unified CM PG が存在しない場合があります。この場合、Cisco Unified CM から Unified CCE へのすべてのコールは、SIP トランクを介した Unified CVP へのルート パターンを通過しなければなりません。他に方法はありません。

エキスパート アドバイザによるコールへの応答

エキスパート アドバイザはコンタクト センターのエージェントではありません。前述のように、コールに応答することが主要な職務ではありません。発信者がアドバイザからの応答を長時間待たないで済むようにするためのさまざま手法については、「長くなる呼び出し時間を管理するための戦略」を参照してください。ただし、最終的には、アドバイザが進んで電話に出ない限り、企業のビジネス モデルは成功しません。

したがって、アドバイザが進んで電話に応対するようになる、機械に頼らない方法を見つけることが重要です。たとえば、経済的インセンティブを与える、アドバイザ間で競争させる、毎年の給与査定の見直しの判断材料とする、拡大コールに対応するアドバイザを明示的にスケジュールするなどの方法が考えられます。これは、展開全体を成功させる戦略の一環として企業が検討すべき問題です。

SIP の設定

Unified EA の展開で SIP の各種パラメータを設定する場合の最適な方法について、次で具体的に説明します。

• Cisco Unified Presence SIP Proxy Server -- Record Route Header

Cisco Unified Presence Proxy Service の Add Record Route Header サービス パラメータのデフォルト設定は、Cisco Unified Presence のリリースによって異なっています。これはオフに設定してください。

• Cisco Unified Presence SIP Proxy Server -- Maximum INVITE Retransmissions

Cisco Unified Presence Proxy Service の Maximum INVITE Retransmissions サービス パラメータのデフォルト設定は 6 です。ただし、冗長性を備えた Unified EA 環境では、このパラメータを 2 に設定するとフェールオーバーが最も有効に機能します。

• SIP プロトコル

ユーザ データグラム プロトコル（UDP）はフェールオーバー状況を素早く検出して対処することから、TCP より優先されます。通常、1 つのプロトコルを選択し、展開のすべての SIP 接続でそのプロトコルを使用することを推奨します。SIP over TLS は、現行のリリースでは利用できません。

• Media Termination Points（MTP; メディア ターミネーション ポイント）

Cisco IOS の古いリリースでは、Cisco IOS SIP 実装に制限がある場合があります。その場合、エキスパート アドバイザが Unified CM 機能を使用して別の宛先にコンサルト、転送、または会議コールを送信できるようにするには、Cisco Unified CM で、Unified CVP または SIP プロキシ サーバに接続される SIP トランクに MTP が必要でした。特定の展開でこれらの機能が重要と判断されなければ、MTP は不要でした。詳細については、『Expert Advisor 7.5(1) Release Notes』を参照してください。Cisco IOS の最新のリリースでは、この制限が取り除かれたため、MTP は必要ありません。

Unified CVP のタイムアウト

Unified CVP 7.0 以降は、エキスパート アドバイザが応答しないコールを Unified EA が制御できる時間を制限するための設定が必要です。この設定は、Unified CVP の [Call Server Configuration] > [SIP] > [Patterns for RNA timeout on outbound SIP calls] で行います。コールを Unified EA に転送するために使用されるトランスレーション ルートの一連の DNIS に対応した着信番号パターンのエントリがあります。これらのコールについて、Unified ICM ルーティング スクリプトが再クエリーされるまでのタイムアウトを適切な秒数（通常 30 ～ 120 秒）に設定します。

Unified CVP 7.0 よりも前のリリースでは、このタイムアウトを宛先ごとに制御する方法がありません。タイムアウトは設定できますが、その設定が Unified CVP によって送信されるすべての宛先のすべてのコールに適用されます。

Cisco Unified Presence の同期タスクのスケジューリング

Cisco Unified Presence ユーザ リストを Unified EA にインポートする同期タスクは、毎日深夜 0 時に実行するにように設定されています。これはデフォルト スケジュールです。別の時刻や別の時間間隔で実行するように変更できます。必要に応じて頻度を分単位で指定することもできます。ただし、不必要な頻度で実行しないでください。同期タスクは、通常のシステム メンテナンスの期間内での実行にとどめることが適切です。システム管理者は、Cisco Unified Presence に対してユーザが追加、更新、削除される頻度や、これらの変更をどの程度早く Unified EA に反映する必要があるかについて検討する必要があります。同期は必要に応じていつでも手動で起動できることに注意してください。

PSTN からのインバウンド コール

図 7-5 は、一般的なインバウンド PSTN コールが処理されるときに発生する一連のイベントを示しています。

図 7-5 インバウンド コール フロー

PSTN からの一般的なインバウンド コールは、着信ゲートウェイを経由して Unified CVP に到達します。次に、Unified CVP はコールを VRU PIM 経由で Unified ICM に通知し、Unified ICM はルーティング スクリプトを開始します。ルーティング スクリプトは Unified CVP に対しセルフ サービス、プロンプトとコレクト、またはメニュー アクションの実行を指示し、さらに [Queue to Skill Group] ノードを使用して複数のエキスパート アドバイザ スキル グループにコールをキューイングします。これらのスキル グループに応答可能なエキスパート アドバイザがいない場合は、VXML ゲートウェイを使用して Unified CVP 経由でコールをキューイングします。

関連スキル グループの 1 つに少なくとも 1 人のエキスパート アドバイザが応答可能な場合、Unified ICM は、Unified CVP に対しトランスレーション ルーティングによってコールを Unified EA ランタイム サーバに配信するように指示します。Unified CVP はランタイム サーバに SIP INVITE を送信（Cisco Unified Presence SIP Proxy Server を経由する場合もある）し、同時に発信者に対し呼び出しトーンの再生を開始します。ここで、Unified ICM によるキューイングのサポートは終了し、Unified EA に制御が移ります。

Unified EA は、Expert Advisor PG 経由でルート要求を送信して、Unified ICM によるトランスレーション ルートを終了します。Unified ICM は対象のスキル グループのラベルを返します。ここからは、Unified EA が、そのスキル グループ内でコールに対応するエキスパート アドバイザを探します。Unified EA ではスキル グループは Assignment Queue（AQ）と呼ばれます。

Unified EA は、AQ 設定に指定されている応答可能なエキスパートをリストにして、一度に複数のエキスパートに対しタスクの提示を開始します。設定可能なタスク提示のタイムアウト期間内にすべてのアドバイザがコールを拒否、または応答しなかった場合は、選択された AQ の次のアドバイザ グループがタスク提示を受信します。すべてのリストを使用してもコールに対応するアドバイザがいなかった場合、コールは Unified EA のキューに残り、新しいアドバイザが応答可能になる（Unified EA がそのアドバイザにタスク提示する）か、または Unified CVP がコールを取り消して Unified ICM の再クエリーを起動するまで、発信者は呼び出しトーンを聞いている状態になります。

エキスパート アドバイザがコールに対応したら、Unified EA は即座にそのアドバイザにコールを配信します。アドバイザが複数の異なるアドレスでコールに応答する可能性がある場合、Unified EA は 1 つの番号だけを呼び出します。宛先の優先アドレス、宛先の優先アドレスでないアドレスの 1 つ、またはアドバイザが応答に指定しているその他のアドレスのいずれかです。選択されるアドレスは、ハードウェアの電話、ソフトウェア電話、サードパーティの電話、自宅の電話、携帯電話、または Cisco Unified CM を介してアドレス指定できるその他のデバイスです。

エキスパート アドバイザが応答したら、アドバイザと発信者は会話を開始します。エキスパート アドバイザはこのコールを別の宛先に渡したり、コンタクト センターに戻したりする場合、電話の通常のコンサルト、会議、および転送機能を使用して実行できます（ただし、これらの機能をサービス プロバイダーと契約している場合）。結果として Unified EA に戻るコールが発生することがありますが、この場合は、新規コールとして戻ります。Unified EA は、2 つのコールの関係を認識しません。

Unified Contact Center Enterprise Agent からのコンサルト コール

このコール フローは、Unified EA に関する限り、PSTN からのインバウンド コールの場合とまったく同じです。Cisco Unified CM から Unified CCE へのコールは、JTAPI インターフェイス経由の Unified CCE へのルート ポイント、または SIP トランクを介した Unified CVP へのルート パターンのいずれかで送信できます。どちらの場合も同じルーティング スクリプトが実行され、コール フローは前述のようにセルフサービス、キューイング、Unified EA の順に進んでいきます。ただし、実際の SIP レベルのルーティングは、コールが最終的に Unified CVP を通過するかどうかによって異なります。詳細は、「ルート パターンまたはルート ポイント」を参照してください。

応答後のエキスパート アドバイザの転送

エキスパート アドバイザは発信者との通話が終了したら、他の宛先にコンサルト、転送、または会議コールを送信できます。これらの活動は、エキスパート アドバイザの各自のスイッチング システムで利用できる方法だけを使用して処理されます。たとえば、アドバイザが Cisco Unified CM ハード フォンを使用している場合は、その電話のソフト キーを利用して発信者を保留状態にし、他の人またはルート ポイントにダイヤルすることができます。この操作により、従来のコンタクト センター エージェントのアドバイザまたは発信者、さらには別のエキスパート アドバイザのアドバイザまたは発信者のキューイングが発生する可能性があります。ただし、この場合、Unified ICM や Unified EA への新規コールと見なされます。元のコールのコール コンテキスト情報は新規コールに引き継がれません。

Unified EA の展開でこのアクティビティが完全にサポートされる場合、Unified EA 自体は実行に何も役割を果たしません。ただし、Unified EA は SIP のシグナリング レベルで利用可能な操作に関する情報を監視しています。Unified EA は、エキスパートがコールを転送したこと、またはコール会議にしたあとに会議から抜けたことを検出したら、そのエキスパートが再びコールに応答可能になったことを自動的に宣言します。ただし、最初のコールの SIP シグナリングは、エキスパートが接続されていなくても、引き続き Unified EA の連続するユーザ エージェントを通過し、Unified EA は発信者が実際に電話を切るまでコールの期間およびメディア変更を追跡することに注意してください。

最終的に、この機能は、会議および転送シナリオで Cisco Unified CM が Unified EA に提供するシグナリングに依存しています。PSTN、携帯電話が利用する MSC など、さらにダウンストリームのコール制御デバイスがスイッチングを実行した場合、適切に機能する保証はありません。これらの場合によく見られる問題は、発信者が電話を切るまでエスパートがそのコールに対してアクティブな状態を維持しているように表示されることです。

エキスパート アドバイザのログイン

上記のコール フローでは、コールがシステムに届いてからエキスパート アドバイザに到達するプロセスについて説明しました。この項では、エキスパート アドバイザがそれらのコールに応答できるようになるプロセスについて説明します。図 7-6 は、エキスパート アドバイザが Unified EA にログインする場合の一連のイベントを示しています。

図 7-6 エキスパート アドバイザのログイン シーケンス

まず Unified EA を起動し、1 人はプライマリ ランタイム サーバから、もう 1 人はバックアップ ランタイム サーバから、2 人の Cisco Unified Personal Communicator 擬似ユーザとして Cisco Unified Presence にログインします。擬似ユーザのどちらも、エキスパート アドバイザとして指定されているすべての Cisco Unified Presence ユーザへのプレゼンス通知に登録します。ただし、実際にはアクティブ ランタイム サーバのユーザが IM メッセージの交換を行います。

エキスパート アドバイザがログインするか、自分のプレゼンスの状態を応答可能に設定して Cisco Unified Presence と対話すると、対応するプレゼンス ドキュメントが Unified EA に転送されます（プレゼンス ドキュメントは、SIP/SIMPLE メッセージに添付される XML 形式のドキュメントです）。アドバイザが応答可能であることがドキュメントに示されている場合、Unified EA は、アドバイザが認定されたすべての Unified ICM スキル グループでコールに応答する準備ができていることを Unified ICM に通知します。アドバイザが応答不能であることがドキュメントに示されている場合、Unified EA は、アドバイザが Unified ICM スキル グループでコールに応答する準備ができていないことを Unified ICM に通知します。

（注） Unified EA の現在のリリースでは、アイドル状態は応答不能と見なされます。アイドルとは、設定可能な期間コンピュータ上でアクティビティが実行されなかった場合にプレゼンス クライアントが遷移する状態のことです。