次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。

次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。

次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。

24000 エージェントリファレンス設計では、通常の動作条件での論理的な接続は 12000 エージェントリファレンス設計のパターンに従います。ただし、最小 12 台の CVP、PG、および Finesse サーバがあります。

Unified CVP は、次の制限がある Cisco IOS XE ソフトウェアをサポートします。

• ASR 1000 シリーズゲートウェイは VXML をサポートしません。そのため、コールの VRU レグを別の VXML ゲートウェイにルートします。コールバックの VRU レグを 発信元の ASR CUBE ゲートウェイにルートするために [発信者に送信（Send To Originator）] 設定を CVP コールサーバに使用しないでください。スタンドアロン CVP コールを別の VXML ゲートウェイにルートします。

• Unified CVP は 、ASR 1000 シリーズ ゲートウェイ上のグローバル Pass Thru SDP 設定をサポートしません。

• メディアフロースルーではなく、メディア フロー アラウンドの CUBE として ASR を構成する場合、サービス コールバック コール フローは機能しません。

• 通常、セッション ボーダー コントローラの背後にプロキシサーバを配置します。プロキシが ASR セッション ボーダー コントローラの正面にある場合は、プロキシサーバを使用して、大きなパケット SIP メッセージを受信するときに UDP から TCP アップ変換を実行します。この場合は、プロキシサーバの電源をオフにし、着信コールの接続に UDP トランスポートを使用することを確実にします。

• ASR では、次の Survivability.tcl オプションを使用することはできません。これらのオプションは、従来 POTS ダイヤルピア向けです。

  • ani-dnis-split.

  • takeback-method.

  • -- *8.

  • -- hf.

  • icm-tbct.

  • digital-fxo.

• 次の Survivability.tcl オプションは、サポートされていません。

  • aa-name — ASR が、CME 自動アテンドサービスをサポートしていないため、このオプションもサポートされていません。

  • standalone — ASR が VXML をサポートしていないため、このオプションもサポートされていません。

  • standalone-isntime — ASR が VXML をサポートしていないため、このオプションもサポートされていません。

• ASR の制限のため、次の機能はサポートされません。

  • 再クエリで参照

  • DTMF *8 ラベルを使用したレガシー転送接続

• ASR 1000 は、TDM トランクを終端しません。したがって、次の TDM ゲートウェイ機能は ASR 1000 に適用されません。

  • SIP コールから Unified CCE に関するPSTN ゲートウェイトランクおよび DS0 情報

  • SIP OPTIONS メッセージから Unified CCE を介した DS0 トランクリソースのリソースの可用性インジケータ（RAI）

Note	ソリューションが ASR 1000 シリーズゲートウェイを使用している場合は、品質評価（A2Q）レビューが必要です。このレビューは、Contact Center Enterprise ソリューション、ASR 1000 にアップグレードする既存のソリューションが対象です。

Unified CVP が ISR をサポートするには次の制限があります。

• CUBE がメディアル フローアラウンド用に構成されているため、サービス コールバック コール フローは ISR では機能しません。代わりに、メディア フロースルー用に構成します。

VXML ゲートウェイを使用すると、カスタマーは DTMF トーンまたは ASR/TTS を介して VXML ブラウザと対話できます。ゲートウェイには PSTN インターフェイスが存在しないので、音声トラフィックは、Real-time Transport Protocol（RTP）を使用して VXML ゲートウェイに送信されます。RFC 2833 は、RTP パケット内でインバンドシグナリングを使用し、DTMF トーンを送信します。DTMF または ASR および TTS を使用する VXML を使用すると、展開の規模を拡大し、数百の VXML セッションをサポートできます。

ブランチオフィストポロジでは、別の PSTN ゲートウェイと VXML ゲートウェイを展開して、冗長性の追加レイヤーを提供し、さらにブランチフィスに Survivable Remote Site Telephony（SRST）のサポートを提供します。

VXML サーバと音声ブラウザは、VXML over HTTP を使用した要求―応答周期で通信します。Uniform Resource 識別子（URI）は、VXML ドキュメントをリンクします。ユーザは HTML に似た Web フォームで情報を入力します。フォームには、ユーザが編集してサーバに送り返した入力フィールドが含まれています。

音声ブラウザのリソースは VXML サーバ上にあります。これらのリソースは、VXML ファイル、デジタルオーディオ、音声認識用の命令（文法）、およびスクリプトです。VXML ブラウザは、音声アプリケーションとの通信プロセスごとに、VXML サーバへの要求として開始します。VXML ファイルには、予測される単語やフレーズを指定する文法が含まれています。リンクには、音声アプリケーションの URL が含まれています。ブラウザは、音声入力と文法の 1 つとの一致が復活するとその URL に接続されます。

Note	CVP インストーラは、CVP コールサーバ、CVP VXML サーバ、メディアサーバをまとめてインストールします。

VXML サーバのパフォーマンスを決定するには、次の点が重要です。

• Web アプリケーション サーバと音声ゲートウェイ間の QoS およびネットワーク帯域幅

• VXML サーバのパフォーマンス

• 録音済み音声と音声合成（TTS）の使用

  音声ユーザ インターフェイス アプリケーションは、可能であれば録音済みオーディオ ファイルを使用する傾向があります。TTS よりも優れている録音済みオーディオサウンド。ダウンロード時間やブラウザの解釈に影響しない事前録音済みのオーディオファイルの品質を選択します。録音は 8 ビットの μ-law 8 kHz フォーマットで行います。

• オーディオ ファイルのキャッシング

  音声ゲートウェイが音声コンテンツをキャッシュするように構成します。キャッシングによって、メディアソースからファイルをダウンロードする際の遅延を回避できます。

• 文法の使用

  音声アプリケーションで問題は、正式なユーザビリティテスト、または使用中のアプリケーションの観察によってのみ検知できます。音声認識の精度が低いのは、音声アプリケーションでは一般的です。主な原因としては不十分な文法実装が挙げられます。ユーザが単語の発音を間違えるか、文法の設計者が予想しなかったことを話すと、認識プログラムは入力と文法を照合できません。文法に関するもう 1 つの一般的な問題は、エントリの識別が難しいことが挙げられます。これらのエントリがあると、間違って認識された入力そして、VXML サーバのパフォーマンスの低下の原因となります。認識の精度を向上させるには、そのパフォーマンスを分析し、文法の精度を調整します。

ソリューションは、ブランチオフィのイングレス音声ゲートウェイを使用して、集中型または非地理的な番号ではなく、ローカルのディレクトリ番号によってアクセスを発信者に提供します。この機能は、複数国にまたがったソリューションにとって重要です。

ソリューションは、ローカライズされた PSTN ブレークアウトのために、またはソリューションに統合された 分散化 TDM プラットフォームのために、ブランチでイグレスゲートウェイを使用できます。

ソリューションの別のコンポーネントは中央に位置しています。WAN リンクは、各ブランチオフィスから メイン サイト にデータ接続を提供します。

ブランチで実行される他の音声サービスは、イングレスゲートウェイまたは VXML ゲートウェイに影響を与える可能性があります。たとえば、ブランチがリモートの Unified CM サイトの場合、Unified CM は ACD エージェント回線と非エージェント回線の両方をサポートできます。この展開では、非エージェント回線からの新しい連絡先およびトラフィックに PSTN ゲートウェイを使用します。ブランチで VXML と音声ゲートウェイが別々のデバイス上で機能する場合は、ダイヤルプランがローカル VXML リソースに VRU レグを送信することを確実にします。これは、Unified CVP コールサーバ settransferlabel ラベルが併置されている VXML および音声ゲートウェイ構成のみに適用されるからです。

ソリューションでは、すべてのゲートウェイとサーバを中央集中型にするか、各サイトに一連の Unified CVP VXML サーバと VXML ゲートウェイを同じ場所に分散できます。

併置には以下の利点があります。

• WAN の機能停止がセルフサービス アプリケーションに影響を与える可能性はありません。

• VXML は WAN 帯域幅を使用します。

併置には以下の欠点があります。

• 複製されたブランチオフィスには、追加の Unified CVP VXML サーバが必要です。

• 複数の Unified CVP VXML サーバにアプリケーションを展開すると、オーバーヘッドが大きくなります。

中央集中型 VXML の利点は次のとおりです。

• 管理とレポート生成が一元化されます。

• ブランチオフィスは、Unified CVP VXML サーバのキャパシティを共有できます。

中央集中型 VXML の欠点は次のとおりです。

• 拠点の存続可能性が制限されます。

• XML over HTTP トラフィックに対してより多くの WAN 帯域幅が必要です。

ダイヤルプランとコールルーティングを設定する場合、Unified CVP 機能を組み合わせて必要なエフェクトを実現できます。たとえば、Location Based CAC、SigDigits、SendToOriginator、LocalSRV および Use Outbound Proxy を使用できます。

CVP はこのプロセスを使用して、Unified CVP からのアウトバウンドコールに対して接続先 SIP URI を作成します。ここでは、Unified CCE からのラベルを含む CONNECT メッセージ（VXML ゲートウェイ、Unified CM など）について説明します。また、呼び出し音サービス、録音サーバ、エラー メッセージ再生サービスにも適用されます。

Note	このプロセスでは、SIP サブシステムを使用した通話についてのみ説明します。これには、音声のみと基本的なビデオ SIP 通話が含まれます。 CVP は、併置する IOS VXML ゲートウェイとイングレス音声ゲートウェイ専用の SendToOriginator アルゴリズムをサポートします。シスコ仮想化音声ブラウザ（VVB）は、アルゴリズムをサポートしません。これは、シスコ VVB を使用する際にゲートウェイを併置できないからです。

Unified CCE ラベルを含むアウトバウンドコール用の接続先 SIP URI ホスト部を作成するプロセスは、次のとおりです。

1. プロセスは、Unified CCE ラベルで開始します。Unified CCE サブシステムはすでに、Location siteID を挿入済みの場合があります。SigDigits を使用している場合は、先頭に追加されます。ネットワーク VRU ラベルの場合、Unified CCE サブシステムは、接頭辞および相関 IDにラベルとして渡されます。

2. SendtoOriginator が Unified CCE ラベルと一致する場合、Unified CVP アルゴリズムは、発信者の IP またはホスト名（イングレス音声ゲートウェイ）を使用します。ゲートウェイは、SIP URI を返します。

   SendtoOriginator の設定は、Cisco イングレス音声ゲートウェイの発信者のみに適用されます（SIP UserAgent ヘッダーが選択されています）。Cisco IOS 以外のゲートウェイには、Cisco IOS VXML ゲートウェイが使用する CVP ブートストラップサービスがありません。

3. [アウトバウンドプロキシを使用（use outbound proxy）] が設定されている場合、プロキシのホストを使用して SIP URI を返します。

4. ローカルの静的ルートがラベルで検出された場合、SIP URI を返します。

   Note	ローカルの静的ルートが見つからない場合、アルゴリズムは RouteNotFoundException の例外をスローします。

SIP サブシステムを使用したコールについては、次の点を検討してください。

• 複雑なダイヤル番号の文字列を回避するためには、Locations CAC siteID で SigDigits 機能を使用しないでください。

• サーバグループ FQDN（ローカル SRV FQDN）としてアウトバウンドプロキシ FQDN を指定できます。また、サーバグループ FQDN としてローカルの静的ルート接続先を構成できます。

• 着信音 DN（91919191）、録音サーバ（93939393）、およびエラーメッセージサービス（92929292）は、同じプロセスに従います。

• SendtoOriginator は、REFER ラベルで機能します。

• REFER ラベルは、SigDigits 設定で動作します。

次の方法で音声プロンプトを導入できます。

• ローカル ファイル システム

  音声プロンプトファイルをローカルシステムに保存します。オーディオによる指示の取得は帯域幅を使用しません。このメソッドでは、音声ブラウザは、プロンプト再生のために音声ファイルを取得する必要が無いので WAN 帯域幅に影響はありません。ただし、プロンプトを変更するには、すべての音声ブラウザで変更します。

  • IOS VXML ゲートウェイ — プロンプトは、フラッシュメモリで導入されます。

    IOS VXML ゲートウェイは、VXML ゲートウェイまたは PSTN ゲートウェイのどちらかであり、同じ場所にあるイングレス音声ゲートウェイと VXML ゲートウェイを持ちます。WAN がダウンした場合のエラーメッセージやメッセージなど、重要なプロンプトだけをここに保存します。

    G.711 μ-law フォーマットで録音した場合、一般的なプロンプトのサイズは 10 ～ 15 KB です。これらのゲートウェイの場合、プロンプトの数とそのサイズを分解して、フラッシュメモリのサイズを調整します。Cisco IOS イメージを保存するためのスペースも残します。

  • Cisco VVB — ローカルファイルシステムにプロンプトをアップロードします。

    Cisco VVB には、組み込みの CVP プロンプトが含まれています。エラー トーン デフォルト プロンプトは、Cisco VVB 管理者コンソール で変更できます。

• メディア サーバ

  ローカルの各音声ブラウザが適切に設定されている場合、プロンプトのサイズに応じて、多くのプロンプトをキャッシュできます。Cisco VVB は最大 512 MB、Cisco IOS は最大 100 MB キャッシュできます。メディアサーバがメディア ファイルに適切に配信されているかどうかをテストするには、ブラウザのメディアサーバでプロンプトの URL を指定します。お使いの Web ブラウザは、認証なしで .wav ファイルをダウンロードし、再生します。

メディアサーバ導入の設計は、次の要因によって異なります。

• 各ゲートウェイが再生するメディアファイルの数

• ゲートウェイとメディアサーバ間のネットワーク接続

• メディアファイルを変更する頻度

ゲートウェイが顧客に対してさまざまなメディアファイルを再生する場合、ゲートウェイに、すべてのメディアファイルをキャッシュできるスペースがない場合があります。

たとえば、エージェントが多い企業があるとします。各エージェントには、それぞれエージェント グリーティング ファイルがあります。ゲートウェイのフラッシュメモリでは、それらのファイルをキャッシュすることはできません。

CVP コールサーバを使用してソリューションを設計する際は、次の点を検討してください。

• Informix データベースのサイズは最大 100 GB です。実稼働環境では、2 GB 以下のデータベースを使用することはできません。

• コールサーバは、Analysis Manager ツールをサポートしています。Analysis Manager は、認証済みのユーザのログイン情報を使用して コールサーバを照会できます。

• コールサーバは、Unified CVP データを 15 分単位で集約します。Cisco Unified Intelligence Center は、15 分間、毎日、および毎週の間隔で、コールデータと優先パス情報を表示するテンプレートを提供しています。

• 管理プロセスのすべてのメタデータは 、Ciscoadmin データベースに含まれています。このロケーションは、レポートユーザの通常ビューからテーブルを削除します。

• すべてのデータベース バックアップ ファイルは、圧縮され、Reporting Server に保存されます。バックアップファイルは、cvp_backup_data.gz と呼ばれ、cvp_db_backup フォルダの%INFORMIXBACKUP% ドライブで保存されます。

• システム CLI を使用して、コールサーバ上のログファイルを一覧するリクエスト（show log）を作成できます。この要求には、Informix データベース サーバ エンジンのログが含まれています。show tech-support コマンドは、これらファイルにも含まれます。

• システム CLI 内でデバッグ レベル 3（または 0）コマンドを使用すると、デバッグのオンとオフを切り替えられます。オンにすると、このコマンドは、すべての管理手順、消去、統計、およびアグリゲータに関するトレースファイルを生成します。

  Note	コマンドをオンにしたら、トレースファイルはデータベースにより大きな不可をかけます。

• 管理手順のログデータは、毎晩 %CVP_HOME%\logs フォルダに書き込まれます。

• StartDateTime、EndDateTime および EventDateTime のすべての値は、コールサーバテーブルで UTC で保存されます。

• SIP コールイベントの転送タイプデータおよび転送ラベルは、コールイベントテーブルに保存されます。

• 要約の消去結果が、ログテーブルに記録されます。

• 3 つの新しいスケジュール済みタスクが、コールサーバのスケジューラに追加されました。

  • CVPSummary は、要約テーブルを構築します。

  • CVPCallArchive は、コールバックデータをアーカイブしてコールバックデータベースのパフォーマンスを維持します。

  • CVPLogDump は、毎晩管理ログを抽出します。

Operations Console を使用すると、データベースバックアップの日次スケジュールを設定したり、オンデマンドでデータベースバックアップを実行できます。大きな障害が発生した場合は、前回のバックアップ時間まで手動でデータベースを復元できます。これにより、データの損失は 24 時間までになります。

エージェント PG は、CTI Manager を介して Unified CM クラスタと通信します。エージェント PG は、クラスタ内の任意の場所でエージェントの電話機と CTI ルートポイントを制御できます。エージェント PG は、クラスタ内の Unified CM サブスクライバ上で CTI Manager に登録します。CTI Manager は、クラスタに対して PG からのすべての JTAPI リクエストを受け入れます。PG が別のサブスクライバの電話機またはルートポイントをリクエストすると、CTI Manager はそのリクエストを別のサブスクライバに転送します。

Note	エージェント PG は、Unified CM PIM を含む PG です。これは、Unified CM PG と呼ばれる場合があります。非リファレンス設計でのみ、エージェント PG は汎用 PG である場合があります。

フォールトトレランス設計は、冗長構成でのエージェント PG 展開します。これは、PG のみが単一 CTI Manager を介してクラスタに接続するからです。その CTI Manager に障害は発生すると、PG は、クラスタと通信できなくなります。冗長 PG は、クラスタの異なるサブスクライバ上の異なる CTI Manager を介して二次的な経路を提供します。

高可用性クラスタの最小設計は、1 つのパブリッシャと 2 つのサブスクライバです。プライマリサブスクライバに障害が発生した場合、デバイスはクラスタのパブリッシャではなく、セカンダリサブスクライバにリホームされます。

冗長 PG は、パブリックネットワークとは分離されたプライベートネットワークを介して同期を維持します。2 台の PG サーバが地理的に分散されている場合は、プライベートネットワーク用に別個の WAN 接続を使用します。ネットワーク内でのシングルポイント障害を回避するために、パブリックネットワークに対して同じ回路またはネットワークギアを使用しないでください。

エージェント PG 内では、JTAPI ゲートウェイおよび Unified CM PIM が、クラスタへの接続を管理します。JTAPI ゲートウェイは、Jabber ソケット接続プロトコルおよび PIM および CTI Manager 間のメッセージを処理します。PIM は、Unified CCE、JTAPI ゲートウェイおよびクラスタ間のインターフェイスを管理します。クラスタからのルートリクエストを監視および処理する特定のオブジェクトをリクエストします。PG は、ノード管理プロセスとして JTAPI ゲートウェイと PIM を自動的に開始します。PG が監視および処理をして、障害が発生した場合は、自動的に再起動します。

両方の冗長エージェント PG からの JTAPI サービスは、初期化後に CTI Manager にサインインします。エージェント PG-A がプライマリ CTI Manager にサインインし、エージェント PG B がセカンダリ CTI Manager にサインインします。ペアになっている 1 つの PG のみが、電話機とCTI ルートポイントを積極的に登録し、監視します。冗長 PG は、ホットスタンバイモードのみで実行されます。冗長 PG はセカンダリ CTI Manager にサインインし、インターフェイスを初期化して、フェールオーバーで使用できるようにします。この取り決めにより、フェールオーバーの時間が大幅に短縮されます。

システムが起動すると、最初に Router サーバに接続された PG とリクエスト構成情報が、アクティブな PG になります。ルータは、接続が最適な PG がアクティブになることを確認します。「サイド A」と「サイド B」の名目上の指定することで、どの PG がアクティブになるかへの影響はありません。プライベートリンクの障害による PG のフェールオーバー中、重みづけメカニズムは、どの PG をアクティブにするかを選択し、コンタクトセンターへの影響を最小に抑えます。

PIM が運用可能になる前に、コールが CTI ルートポイントに到着した場合、リカバリ回数を設定しない限りそのコールは失敗し続けます。ルートポイントの [未登録時のコール転送（Call Forward on Unregistered）] または [障害時のコール転送（Call Forward on Failure）] 設定にリカバリ回数を指定します。たとえば、[自動応答（Auto Attendant）] の Cisco Unity 音声メールシステムに対してリカバリ回数を設定できます。

Note	別のパーティションの別の CTI ルート ポイントでの CTI ルート ポイントの DN は使用できません。DN がすべてのパーティション上のすべての CTI ルート ポイントで一意であることを確認します。

標準規格の 3 つの PG モデルでは、VRU PG にはサイド A とサイド B にある CVP サーバに 1:1 ペアリングをする 2 台の PIM が含まれています。

標準規格 3 台の PG モデルでは、MR PG に次の機能をサポートする PIM が含まれます。

• アウトバウンド オプション

• ビジネス チャットおよび E メール

• Customer Collaboration Platform— この PIM は、タスクルーティングとエージェントリクエストを処理します。

• サードパーティ製品との統合

2000 エージェントリファレンス設計にはライブデータの併置構成を使用します。スタンドアロン Live Data サーバを使用するソリューションの場合、Unified CCE Rogger 展開に対して通常、小規模の Live Data 展開構成を使用します。通常は、個別のルータおよび Logger を使用して大規模の Live Data 展開構成を使用します。

Note	標準規格の Cisco Finess エージェントデスクトップには、ライブデータガジェットが含まれます。

Unified CCE がマルチライン用に構成されている場合、Cisco Finesse は、エージェント電話機での複数回線の構成をサポートします。エージェント電話機で複数の二次回線を構成できます。ただし、Cisco Finesse サーバは、二次回線での操作の応答で CTI サーバが送信するイベントをブロックします。Cisco Finesse サーバは、これらのイベントを Cisco Finesse クライアントに発行しません。二次回線上のコールに関する情報は、Cisco Finesse デスクトップには表示されません。

エージェントが 8900 シリーズまたは 9900 シリーズの電話機を使用している場合は、Unified CM 周辺機器でマルチラインを有効にします。この構成オプションは、周辺機器全体に適用されるオプションです。8900 シリーズまたは 9900 シリーズの電話機を使用する 1 つのエージェントに対してマルチラインを有効にする場合は、すべてのエージェントに対しても有効にします。

マルチラインをサポートするには、すべての電話機を次の設定で構成します。

• [Maximum number of calls] を 2 に設定します。

• 1.へのセットの使用中のきっかけ。

Contact Center Enterprise ソリューションは、Citrix 環境内での Cisco Finesse デスクトップの実行をサポートします。Cisco Finesse は、Citrix XenApp および XenDesktop をサポートします。

Note	AW、構成専用管理サーバ、および管理クライアントは、特定の VM 上で単一のリモートインスタンスとしてのみ動作できます。

サポートされるバージョンの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html の「互換性マトリックス」を参照してください。

一部のソリューションには、ネットワークアドレス変換（NAT）をインターコネクトする 2 つ以上の切り離されたネットワークがあります。

Cisco Finesse は、NAT に対するサポートが限定されています。Cisco Finesse は、Cisco Finesse サーバとクライアント間の基本的な NAT（1 対 1 の IP アドレスマッピング）をサポートします。

次の注意事項は、Cisco Finesse と NAT に適用されます。

• Cisco Finesse サーバとクライアントの間では、PAT/NPAT（ポートを使用する 1 対多アドレスマッピング）を使用できません。

• Cisco Finesse サーバおよび接続されている任意のサーバ間では、NAT は使用できません。

• Cisco Finesse IP Phone Agent（IPPA）は NAT をサポートしません。

Note	NAT とファイアウォールに関しては、ソリューションセキュリティの章を参照してください。

Cisco Finesse は Contact Center Enterprise の音声エンドポイントとして Windows 版 Cisco Jabber をサポートしています。Cisco Finesse は次の Jabber 機能をサポートしています。

• 音声とビデオ

• サイレントモニタリングの組み込みブリッジ（BIB）

• IM and Presence

Note	エージェントは、Jabber を使用して通話を転送、または電話会議することはできません。エージェントは、転送や会議に Cisco Finesse デスクトップを使用する必要があります。

Cisco Finesse で Jabber を使用するには、デフォルトの Jabber 構成を次のように変更します。

• コールの最大数を 6 から 2 に変更します。

• ビジートリガーを 2 から 1 に変更します。

Jabber サポートの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html のソリューションに対する「互換性マトリックス」を参照してください。

Unified CCE は、WebSockets を介してエージェント、スキルグループ、およびコールタイプステータスでリアルタイムの更新を公開します。Unified Intelligence Center レポートは、これらのメッセージをライブデータサービスから直接消費し、リアルタイムで更新を表示します。

Unified CCE では、ライブデータサービスは独自の VM 上に存在します。

ライブデータレポートは、Unified Intelligence Center レポートビューアで実行できます。Cisco Finesse デスクトップでは、ガジェットに ライブデータレポートを表示できます。Cisco Finesse デスクトップの親コンテナからライブデータサービスの 1 つまで WebSocket トンネルを使用します。ガジェットは、ロード中にトンネルを作成します。

WebSocket 接続に障害が発生すると、ライブデータレポートは、現在接続されている Live Data ノードに自動的にフェールオーバーします。

次の図は、Contact Center Enterprise 展開における ライブデータレポートのアーキテクチャを示しています。

Unified Intelligence Center の株価レポートでは、データソースとして Administration & Data サーバを使用します。Contact Center Enterprise 展開では、複数の Administration & Data サーバを使用できます。Unified Intelligence Center は、データベースとそのビューをデータソースクエリのテーブルとして使用します。

Unified Intelligence Center をインストールすると、レポート（メンバー）ノードに 2 つのデータソースが追加されます。

• 履歴データソースは、履歴レポートとユーザ統合にデータを提供します。

• リアルタイムデータソースは、リアルタイムレポートにデータを提供します。

展開では、両方のデータソースに同じ AW-HDS を使用できます。また、データソースごとに異なるサーバを構成することもできます。Unified Intelligence Center では、標準規格の 履歴レポートのデータソースとして AW-HDS が必要です。ただし、標準規格の リアルタイムレポートにはデータソースとして AW を使用できます。Unified Intelligence Center では、TCD レコードに関するカスタムレポートのデータソースとして AW-HDS-DDS または HDS-DDS が必要です。

Unified CVP からレポートをインポートする展開の場合、Unified Intelligence Center は、データソースとして CVP コールサーバを使用します。

CVP コールサーバはレポーティングサービスを提供し、IBM Informix Dynamic サーバ（IDS）データベース管理システムをホスティングします。データベースのスキーマを使用すると、データベースに対してカスタムのレポートを作成できます。ソリューションには、複数の CVP コールサーバを含めることができます。

Unified Intelligence Center は、CVP コールサーバにのみ接続します。CVP コールサーバは、他の Unified CVP サブコンポーネントと Unified Intelligence Center 間を仲介します。

タスク ルーティング API を使用して、CCE でサードパーティ製マルチチャネルタスクを要求、キュー、ルーティング、および処理します。

次の使用例がサポートされています。

• 1 つの Media Routing Domain（MRD）の複数の同時タスクを MRD 内で処理するエージェント。

• 割り込み可能 MRD これら MRD のタスクを処理するエージェントは、別の MRD のタスクによって中断される場合があります。たとえば、電子メール MRD を中断可能にセットすると、電子メールのタスクを処理しているエージェントは、音声通話やチャットなどの別の MRD からのタスクによって中断される場合があります。

• 指定されたスクリプトセレクタへのブラインド転送。直接転送はサポートされていません。

• 割り当てられたタスクを使用してエージェントがサインアウトします。これらのタスクは、Finesse Media API のエージェントの dialogLogoutAction 設定に応じて、閉じたり転送されます。

• RONA. エージェントが、MRD のタイムアウト開始しきい値以内にオファーされたタスクを受け入れない場合、Finesse はルーティング用にタスクをサイド提出し、そのエージェントをルーティング可能にします。

このタスクフローでは、エージェントが電子メールとチャットタスクを処理するように構成されている一般的なマルチチャネルシナリオについて説明します。

電子メール メディア ルーティング ドメイン（MRD）は割り込み可能であり、エージェントは、その MRD で割り込みを許可するよう構成されます。電子メール MRD は、割り込み可能なので、別の MRD からのタスクが電子メールタスクを処理するエージェントに割り込むことができます。エージェントが割り込みを受け入れるように構成されているため、別の MRD からのタスクがエージェントに割り当てられると、電子メール MRD でのエージェントの状態、電子メールタスク、Finesse ダイアログは、[割り込み中（INTERRUPTED）] に変わります。割り込み中、エージェントは、電子メールタスクの作業を行うことはできません。

チャット MRD は中断できません。

MRD の中断および中断の許可、却下に関しては、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html の Cisco Unified Contact Center Enterprise 機能ガイド を参照してください。

パートナーは、Finesse および Customer Collaboration Platform API に統合された電子メールおよびチャットアプリケーションを開発しました。

1. カスタマーが会社の電子メールを送信します。電子メールアプリケーションは、新規電子メールタスクリクエストを CCE に送信します。タスクリクエストには、スクリプトセレクタ、電子メールへの処理を含むカスタマー固有の情報が入った Call および ECC 変数が含まれます。

2. CCE が、スクリプトセレクタを通話タイプにマッピングすると、どのルーティングスクリプトが実行されるか決まります。ルーティングスクリプトは、電子メールタスクを電子メール MRD の適切なスキルグループまたはポスト コール調査にキューします。

3. 電子メールアプリケーションは、ステータスと推定待機時間（EWT）をポーリングします。

4. エージェントが、電子メール MRD にサインインすると、ステータスが [準備完了（Ready）] に変わります。

5. CCE は、電子メールをエージェントに割り当てます。タスクを作成するために使用する Call および ECC 変数は、ダイアログ メディア プロパティに含まれます。アプリケーションはこれらの変数を使用して、エージェントが電子メールに返信できるようにします。エージェントは Finesse の電子メールダイアログで作業を開始します。

6. 別のカスタマーがチャットリクエストを会社に送信します。チャットアプリケーションは、CCE に新しいチャットタスクリクエストを送信します。コール変数と ECC 変数には、チャットルームの URL が含まれます。

7. CCE が、チャットリクエストで送信されたスクリプトセレクタをコールタイプにマッピングすると、どのルーティングスクリプトを実行するかが決まります。ルーティングスクリプトは、チャットタスクをチャット MRD の適切なスキルグループまたはポスト コール調査にキューします。

8. チャットアプリケーションは、ステータスと推定待機時間（EWT）をポーリングします。

9. 電子メールタスクの作業中に、同じエージェントがチャット MRD にサインインすると ステータスが [準備完了（Ready）] に変わります。

10. CCE は、チャットタスクをエージェントに割り当てます。アプリケーションは、Call および ECC 変数を使用して、エージェントをカスタマーとのチャット ルームに追加します。エージェントは Finesse のチャットメールダイアログで作業を開始します。

11. 電子メール MRD のエージェントのステータスは [割り込み中（Interrupted）] に変わり、電子メールダイアログのステータスが [割り込み中（Interrupted）] に変わります。アプリケーションは、電子メールダイアログのアクションを無効にします。

12. エージェントは、チャットタスクを別のスクリプトセレクタに転送します。Finesse はチャットダイアログを閉じ、タスクを Customer Collaboration Platform に再送信します。アプリケーションはチャットルームを閉じます。

13. エージェントは他の非割り込みダイアログを処理せず、電子メールダイアログはアクティブになります。

14. エージェントは、電子メールダイアログの作業を続行します。エージェントは、ダイアログを一時停止して、短い休憩を取り、ダイアログを再開します。

15. 電子メールの返信が完了すると、エージェントはそのダイアログのまとめ作業を実行します。エージェントはダイアログを閉じます。Finesse は 、電子メールタスクのために Customer Collaboration Platform にハンドルイベントを送信します。アプリケーションは、カスタマーに対して電子メールの返信を送信します。

Cisco Finesse は、Unified CM のサイレントモニタリングを介してサイレントモニタリング機能を提供します。Cisco Finesse は、Unified CM サイレントモニタリング機能時に、以下のように動作します。

1. サイレントモニタリングを開始するため、スーパーバイザ アプリケーションは、Cisco Finesse サーバに REST 要求を送信します。

2. サイレント モニタリング セッションを開始するため、Cisco Finesse サーバは、AgentSuperviseCall(）メッセージを Unified CCE に送信します。

3. Unified CCE は、Unified CM に CallStartMonitor(）メッセージを送信します。

4. Unified CM はスーパーバイザの電話機に対し、エージェント電話機の組み込みブリッジ（BIB）にコールするよう指示します。

5. スーパーバイザの電話機は、エージェント電話機で BIB をコールします。

6. エージェントの電話機は、エージェントの音声ストリームと顧客の音声ストリームの組み合わせを転送します。

7. Unified CM は、サイレント モニタリング コールのコールイベントを Unified CCE に送信します。

8. Unified CCE は、Cisco Finesse サーバに更新イベントを送信します。

9. Cisco Finesse サーバは、Cisco Finesse スーパーバイザ アプリケーションに XMPP アップデートを送信します。

Cisco Finesse では、モバイルエージェントのサイレントモニタリングはサポートされません。スーパーバイザは、モバイルエージェントをサイレントモニタリングできず、モバイルスーパーバイザは、サイレントモニタリングを実行できません。

スーパーバイザは、Cisco Finesse IP Phone からサイレントモニタリングを実行できません。スーパーバイザは、Cisco Finesse デスクトップからのサイレントモニタリングのみ実行できます。

Unified CM は、スーパーバイザ（監視）デバイスとエージェント（監視対象）デバイスの間のコールを使用してサイレントモニタリングを行います。エージェントの電話機はエージェントの会話をミックスしてスーパーバイザの電話機に送信し、スーパーバイザに再生します。

Unified CCE は、Unified CM で利用可能なサイレント モニタリング機能をサポートしています。Unified CM のサイレント モニタリングでは、同じエージェント電話に対して 1 つのサイレント モニタリング セッションおよび 1 つの録音セッションのみがサポートされます。

Note	Unified CM サイレント モニタリングは、モバイル エージェントはサポートしていません。

以下の条件に該当する場合、Unified CM サイレントモニタリングは、任意の Unified CCE エージェントデスクトップを監視できます。

• 監視対象のエージェントは、互換性のある Cisco Unified IP Phone または Cisco IP Communicator を使用します。ソリューションの詳細に関しては、「互換性マトリックス」を参照してください。

• コンタクト センターでは、互換性のあるバージョンの Cisco Unified CM が使用されています。使用するソリューションの詳細については、 互換性マトリクス を参照してください。

スーパーバイザは、Cisco IP Communicator を含む任意の Cisco IP 電話を使用してエージェントをサイレントモニタできます。

Unified CM サイレント モニタリングは、Unified CM で提供されるその他のコール制御機能 (会議や転送など) と同様に動作します。サイレントモニタリングのセッションが開始されると、デスクトップは Unified CCE を介してメッセージを送信し、サイレントモニタが実行されている電話機に送信します。

Unified CCE および Unified CM を介したメッセージングは、Unified CCE のパフォーマンスに影響を及ぼします。

• エージェント間の通話転送では、ネットワークベースの録音は機能しませんが、電話ベースの録音は機能します。ネットワークベースの録音を使用する場合は、Unified CVP と Unified CM 間で ISR ゲートウェイを使用できます。

• NBR 機能は IOS イメージトレインでのみサポートされます。サポートされている IOS イメージトレインの詳細については、ご使用のソリューション向けの「互換性マトリックス」を参照してください。