コアコンポーネント設計上の考慮事項
一般的なソリューション要件
ソリューションのデータバックアップ
データバックアップツールは、スケジュールされたメンテナンスウィンドウでのみ実行します。ローカル SQL バックアップを使用する場合は、ローカルマシンに十分なキャパシティがあることを確認します。そうでない場合は、ネットワーク上のリモートストレージにバックアップします。
NTP および時刻同期
Contact Center Enterprise ソリューションには、ソリューションのすべての部分に同じ時間が必要です。時間のずれは自然に発生しますが、ソリューション コンポーネントの同期を維持するために NTP を設定することは重要です。ライブデータレポートで時間の差異を回避するため、これら VM での NTP 設定は同期されなければなりません。
-
ルータ
-
Logger
-
Administration & Data Server
-
Unified Intelligence Center のパブリッシャとサブスクライバ
Note |
Finesse Desktop クライアントマシンは、ライブデータレポート内の [期間(Duration)] フィールドへの正確な更新のため、有効な NTP サーバを使用して、時間を同期する必要があります。 |
Contact Center Enterprise リファレンス設計トポロジの詳細
詳細な 2000 エージェントリファレンス設計
次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。
詳細な 4000 エージェントリファレンス設計
次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。
詳細な 12000 エージェントリファレンス設計
次の図は、冗長なデータセンター内の両側面間における通常の動作条件での論理的な接続を示しています。
詳細な 24000 エージェントリファレンス設計
24000 エージェントリファレンス設計では、通常の動作条件での論理的な接続は 12000 エージェントリファレンス設計のパターンに従います。ただし、最小 12 台の CVP、PG、および Finesse サーバがあります。
入力/出力/VXML ゲートウェイの設計上の考慮事項
IOS ゲートウェイの役割
Contact Center Enterprise ソリューションでは、TDM 入力および VXML レンダリングに IOS ゲートウェイが使用されます。通常は、いずれかまたは両方の目的に対して、ソリューションでサポートされている任意の Cisco ゲートウェイを使用できます。次の表は、各機能を使用するコール フローを示しています。
コール フロー |
TDM 入力 |
VXML レンダリング |
---|---|---|
リファレンス設計 |
||
Unified ICM Micro-Apps を使用する包括的コール フロー |
可 |
一部 |
Unified CVP VXML Server を使用する包括的コール フロー |
可 |
一部 |
非リファレンス設計 |
||
スタンドアロン セルフ サービス |
はい |
はい |
コール ディレクタ |
はい |
なし |
NIC 制御ルーティングのみを使用する VRU |
はい |
はい |
Note |
VXML ゲートウェイの代替として Cisco Virtualized Voice Browser を使用できます。 |
入力および VXML の両方が必要な場合は、同じゲートウェイで両方の機能を実行するか、一部のゲートウェイを入力用に指定し、他のゲートウェイを VXML 用に指定できます。次のガイドラインに従って、機能を結合するか分割するかを判断してください。
-
到着したブランチでコールがキューに格納されるブランチ オフィス展開では、入力機能と VXML 機能を常に結合します。
-
多数の非 CVP PSTN 接続でゲートウェイを共有している場合は、各機能ごとに個別のゲートウェイを使用します。
-
VXML のみのゲートウェイは、DSP ファームや TDM カードが不要なためコストが低くなります。
-
コール量が少ない場合は、通常、冗長性のために機能を結合します。結合されたゲートウェイのいずれかで障害が発生した場合は、容量を低減して、他のゲートウェイで引き続きコールを処理できます。
次に、Cisco サービス統合型ルータ(ISR)または ISR-G2 ゲートウェイのどちらを使用するかを決定します。
ISR ゲートウェイを使用する従来のブランチ オフィスには以下が含まれます。
-
TDM コールが PSTN から到着する複数サイトの 1 つ
-
ソリューションの大部分の機器が存在する メイン サイト から分離されたサイト
-
各サイトが 1 つのゲートウェイを使用
TDM-IP ゲートウェイ設計に関する検討事項
さまざまな音声ゲートウェイでサポートされる各種デジタル(T1/E1)およびアナログインターフェイスの最新情報については、次のサイトから入手可能な最新の製品マニュアルを参照してください。
Cisco Unified Border Element 設計に関する考慮事項
Cisco Unified Border Element(CUBE)は、SIP を使用した IP 音声ネットワーク間の接続を提供する Session Border Controller(SBC)です。ソリューションでは、物理 CUBE または仮想 CUBE を使用することができます。ソリューションは、すべてのコールが CUBE を介してルーティングされるフロースルー モードでのみ CUBE を使用できます。
Note |
フロースルー モードとは異なり、フロー アラウンド モードでは、DTMF インターワーキング、トランスコーディング、および電話機やメディア機能などのその他の主要機能を使用することはできません。 |
TDM 音声回線を電話会社の IP 音声トランクに置き換える場合、ソリューションには CUBE が必要となります。CUBE は、IP 音声トランク上で企業をサービス プロバイダーに接続するための機能境界ポイントとして機能します。
Note |
アウトバウンド コールの場合、物理 CUBE はコール進行状況分析(CPA)をサポートします。仮想 CUBE は、CPA をサポートしていません。 |
テストでは、以下のシナリオで CUBE を使用できることが示されています。
-
シスコによって認定済みの SIP トランクを介したサードパーティ製 SIP デバイスと Unified CVP 間の SIP-to-SIP 接続
-
Unified CM と Unified CVP 間の SIP-to-SIP 接続
トポロジや設定など、Unified CVP での CUBE の使用に関する詳細については、http://cisco.com/en/US/docs/voice_ip_comm/unified_communications/cubecc.htmlの コール センター ソリューション向けCisco Unified Border Element を参照してください。
Note |
各 CUBE がサポートする最大セッション数の一覧については、http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v-series/products-installation-and-configuration-guides-list.htmlの Cisco Unified Border Element コンフィギュレーションガイド を参照してください。 |
Note |
Cisco IOS の制限により、CUBE では、音声からビデオ、およびビデオから音声への通話中のエスカレーションまたはデスカレーションはサポートされません。 |
Note |
現在、CVP は SIP メッセージの Allowed-Methods を確認しません。その結果、アウトバウンドは 回避策: |
CUBE 展開の制限
SIP トランクで CUBE を展開する場合は、以下の制限を遵守してください。
-
Unified CVP 展開で、ダイヤル ピアのデフォルト モードであるメディア パススルー モードで CUBE を設定します。メディア フロー アラウンド モードは、Webex エクスペリエンス管理のみでサポートされています。
-
CUBE は、REFER コール フローの開始時に CVP からの Refer-To ヘッダー URI 宛先の受け渡しをサポートしていません。CUBE によって、ダイヤル ピア コンフィギュレーションに基づいて宛先アドレスが書き換えられます。そのため、ダイヤル プランは CVP および CUBE で設定する必要があります。
-
REFER パススルーを耐障害性で使用することはできません。スクリプトは、他の CUBE の設定に関係なく、REFER メッセージが SIP サービス プロバイダーにリレー送信されないようにします。
-
耐障害性およびルータ再クエリでは REFER 消費を使用できません。存続可能性は、転送が完了していない場合でも、常に REFER を受け入れます。Unified CCE は、転送が成功したと見なし、再クエリーしようとしません。
-
サービス プロバイダーの代替宛先ルーティング(ADR)で耐障害性を使用することはできません。スクリプトの処理では、エラー メッセージ(Ring-No-Answer またはビジー)がサービス プロバイダーに到達しないようにします。代わりに、Remote-Party-ID ヘッダの処理が必要となります。
-
GTD が着信コール中であるか、または Unified CCE が UUI 変数の値を設定する場合、Unified CVP は DTMF 転送でディジットをアウトパルスした直後に BYE を送信します。数字の間に遅延が必要な場合は、ラベルの最後にコンマを使用します。
-
着信コールに GTD が存在しない場合、Unified CCE は UUI 変数の値を設定しません。次に、サービス プロバイダーは、DTMF 転送で数字を受信した後、コールを切断しません。Unified CVP は SIP.ExternalTransferWait タイマーの期限が切れた後、BYE 要求を送信します。
-
サービス コールバックを使用したソリューションには、耐障害性が必要です。
Note |
コール耐障害性はCUBE HAモードでサポートされますが、以下の制限があります。
|
Unified Border Element としての Cisco ASR 1000 シリーズ
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 Border Element としての Cisco ISR
Unified CVP が ISR をサポートするには次の制限があります。
-
CUBE がメディアル フローアラウンド用に構成されているため、サービス コールバック コール フローは ISR では機能しません。代わりに、メディア フロースルー用に構成します。
VXML ゲートウェイ設計上の考慮事項
Note |
VXML ゲートウェイの代替として Cisco Virtualized Voice Browser を使用できます。 |
DTMF または ASR/TTS を使用する VXML ゲートウェイ
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 Over HTTP
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 ゲートウェイ
ブランチで実行される他の音声サービスは、イングレスゲートウェイまたは VXML ゲートウェイに影響を与える可能性があります。たとえば、ブランチがリモートの Unified CM サイトの場合、Unified CM は ACD エージェント回線と非エージェント回線の両方をサポートできます。この展開では、非エージェント回線からの新しい連絡先およびトラフィックに
PSTN ゲートウェイを使用します。ブランチで VXML と音声ゲートウェイが別々のデバイス上で機能する場合は、ダイヤルプランがローカル VXML リソースに VRU レグを送信することを確実にします。これは、Unified CVP コールサーバ
settransferlabel
ラベルが併置されている VXML および音声ゲートウェイ構成のみに適用されるからです。
併置された VXML サーバと VXML ゲートウェイ
ソリューションでは、すべてのゲートウェイとサーバを中央集中型にするか、各サイトに一連の Unified CVP VXML サーバと VXML ゲートウェイを同じ場所に分散できます。
併置には以下の利点があります。
-
WAN の機能停止がセルフサービス アプリケーションに影響を与える可能性はありません。
-
VXML は WAN 帯域幅を使用します。
併置には以下の欠点があります。
-
複製されたブランチオフィスには、追加の Unified CVP VXML サーバが必要です。
-
複数の Unified CVP VXML サーバにアプリケーションを展開すると、オーバーヘッドが大きくなります。
Centralized VXML サーバを使用したブランチにあるゲートウェイ
中央集中型 VXML の利点は次のとおりです。
-
管理とレポート生成が一元化されます。
-
ブランチオフィスは、Unified CVP VXML サーバのキャパシティを共有できます。
中央集中型 VXML の欠点は次のとおりです。
-
拠点の存続可能性が制限されます。
-
XML over HTTP トラフィックに対してより多くの WAN 帯域幅が必要です。
Contact Center Enterprise ソリューションのローカルトランク
Contact Center Enterprise ソリューションには、カスタマーオンプレミスのローカルトランクに 2 つのオプションがあります。
-
Cisco Unified Border Element — カスタマーオンプレミスの企業
-
カスタマーオンプレミスの TDM ゲートウェイ
Note |
トランスコーディング リソースは、ローカルのカスタマー オンプレミス ゲートウェイから確定的に選ばれるわけではありません。 |
CVP 設計上の考慮事項
CVP コールサーバ設計上の考慮事項
ルーティングの Unified CVP アルゴリズム
ダイヤルプランとコールルーティングを設定する場合、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 ゲートウェイとイングレス音声ゲートウェイ専用の |
Unified CCE ラベルを含むアウトバウンドコール用の接続先 SIP URI ホスト部を作成するプロセスは、次のとおりです。
-
プロセスは、Unified CCE ラベルで開始します。Unified CCE サブシステムはすでに、Location siteID を挿入済みの場合があります。SigDigits を使用している場合は、先頭に追加されます。ネットワーク VRU ラベルの場合、Unified CCE サブシステムは、接頭辞および相関 IDにラベルとして渡されます。
-
SendtoOriginator
が Unified CCE ラベルと一致する場合、Unified CVP アルゴリズムは、発信者の IP またはホスト名(イングレス音声ゲートウェイ)を使用します。ゲートウェイは、SIP URI を返します。SendtoOriginator
の設定は、Cisco イングレス音声ゲートウェイの発信者のみに適用されます(SIP UserAgent ヘッダーが選択されています)。Cisco IOS 以外のゲートウェイには、Cisco IOS VXML ゲートウェイが使用する CVP ブートストラップサービスがありません。 -
[
アウトバウンドプロキシを使用(use outbound proxy)
] が設定されている場合、プロキシのホストを使用して SIP URI を返します。 -
ローカルの静的ルート
がラベルで検出された場合、SIP URI を返します。
Noteローカルの静的ルート
が見つからない場合、アルゴリズムはRouteNotFoundException
の例外をスローします。
SIP サブシステムを使用したコールについては、次の点を検討してください。
-
複雑なダイヤル番号の文字列を回避するためには、Locations CAC siteID で SigDigits 機能を使用しないでください。
-
サーバグループ FQDN(ローカル SRV FQDN)としてアウトバウンドプロキシ FQDN を指定できます。また、サーバグループ FQDN としてローカルの静的ルート接続先を構成できます。
-
着信音 DN(91919191)、録音サーバ(93939393)、およびエラーメッセージサービス(92929292)は、同じプロセスに従います。
-
SendtoOriginator
は、REFER ラベルで機能します。 -
REFER ラベルは、SigDigits 設定で動作します。
CVP VXML サーバ設計上の考慮事項
VXML アプリケーションが複雑化すると、VXML サーバのパフォーマンスに影響を与えます。許容範囲の VXML サーバのパフォーマンスを維持するために、メモリリークとアプリケーションのデッドロックについてアプリケーションの負荷テストを行います。
CVP メディアサーバ設計に関する検討事項
音声プロンプトの展開と管理
次の方法で音声プロンプトを導入できます。
-
ローカル ファイル システム
音声プロンプトファイルをローカルシステムに保存します。オーディオによる指示の取得は帯域幅を使用しません。このメソッドでは、音声ブラウザは、プロンプト再生のために音声ファイルを取得する必要が無いので 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 ファイルをダウンロードし、再生します。
メディアサーバ導入の設計は、次の要因によって異なります。
-
各ゲートウェイが再生するメディアファイルの数
-
ゲートウェイとメディアサーバ間のネットワーク接続
-
メディアファイルを変更する頻度
多数のメディアファイル設計に関する検討事項
ゲートウェイが顧客に対してさまざまなメディアファイルを再生する場合、ゲートウェイに、すべてのメディアファイルをキャッシュできるスペースがない場合があります。
たとえば、エージェントが多い企業があるとします。各エージェントには、それぞれエージェント グリーティング ファイルがあります。ゲートウェイのフラッシュメモリでは、それらのファイルをキャッシュすることはできません。
音声ブラウザを使用してメディアサーバを同じ場所に配置
この問題の 1 つの方法は、音声ブラウザを使用してメディアサーバを場所に配置する方法です。メディアサーバと音声ブラウザを十分な帯域幅がある LAN 上で共存させる場合、プロンプトをダウンロードしても大きな遅延は発生しません。
WAN 上に分散されたメディアサーバと音声ブラウザ
ソリューションでは、WAN 全体の音声ブラウザから分離されたメディアサーバを使用できます。
次の図は、WAN 上での分散型展開を示しています。
高遅延 WAN 全体のメディアファイルを音声ブラウザにダウンロードすると、大幅な遅延が起こる場合があります。この遅延は、ユーザエクスペリエンスに大きく影響します。この遅延は、WAN 全体で転送されるメディアファイルのサイズと数に大きく影響します。Wide Area Application Services(WAAS)を使用すると、遅延を最適化できます。
メディアストリーミングの設計に関する検討事項
LAN 展開と WAN アクセラレータ展開の両方では次の要因を検討します。
-
最大ネットワーク ラウンドトリップ時間(RTT)の遅延は、200 ミリ秒です。
たとえば、一括管理ファイル転送(BAFT)を使用した CVP オペレーションコンソールからイングレスまたは VXML ゲートウェイへのファイル転送など。
-
メディアフォークを使用したビデオの追加オーバーヘッドなしの各ゲートウェイでサポートされているストリーミングセッションの最大数。
次の表は、さまざまな展開で使用する優先メディアストリーミング方法を示します。
シナリオ |
変更の頻度 |
LAN 上 |
WAN 上 |
---|---|---|---|
少数のファイル |
稀 |
Cached |
Cached |
少数のファイル |
よく利用する |
ストリーミング済みまたはキャッシュ済み |
WAAS でストリーミング |
多数のファイル |
稀 |
ストリーミング済み |
WAAS でストリーミング |
多数のファイル |
よく利用する |
ストリーミング済み |
WAAS でストリーミング |
Note |
Cisco VVB では、メディアストリーミング機能はサポートされていません。 |
メディアファイルの展開の設計に関する検討事項
TCP ソケットの保持はサポートされていません
Unified CVP は TCP ソケットの永続性をサポートしません。
WAN 高速化サポート
Wide Area Application Services(WAAS)システムは、Wide Area Application Engine(WAEs)と呼ばれるデバイスの一式です。ネットワーク上の TCP トラフィックを最適化するために、WAEs が協働します。Cisco WANAS は、TCP の最適化技術とアプリケーション アクセラレーション機能を使用して、WAN を経由したトラフィックの転送に関する最も一般的な課題を解決します。VXM ゲートウェイ側のネットワークの周辺に展開すると、Cisco WAAS が次の機能を実行します。
-
トラフィックを最適化するために TCP ヘッダーを変更します。
-
ローカルに配置された大規模な HTTP キャッシュとして機能します。
-
圧縮アルゴリズムを使用してトラフィックをさらに減らします。
-
データ冗長性排除(DRE)技術によりトラフィックを削減します。
Cisco WAAS は、すべてのデータが強制的に Cisco WAAS にパススルーするインラインモードで展開されます。
IOS ゲートウェイ上のメディアファイルの展開
非ストリーミングおよびストリーミングモード
非ストリーミングモードでは、Media Player がプロンプトの再生を開始する前に、VXML ゲートウェイは、HTTP サーバから音声ファイル全体をダウンロードします。これにより、発信者の遅延が発生します。小規模ファイルの場合、遅延は数ミリ秒です。キャッシングまたはストリーミングモードのいずれかを使用すると、サイズの大きいファイルの遅延を回避できます。
ストリーミングモードでは、Media Player は HTTP サーバから発信者にオーディオをメディアチャンクでストリーミングします。Media Player は、最初のチャンクを受信するとプロンプトの再生を開始します。ストリーミングモードでは、オーディオによる指示のサイズによって、発信者に遅延が追加されることはありません。だたし、チャンクのメディアファイルをフェッチするための前後の対話によりパフォーマンスが低下する場合があります。
メモリ内の音声ファイルをキャッシュすると、HTTP サーバから直接ストリーミングする大きなファイルの利点が少なくなります。
メディア ファイル キャッシュ タイプ
メディアファイルを保存するキャッシュは、2 種類あります。
- HTTP Client キャッシュ
- 非ストリーミングモードでは、HTTP Client キャッシュにメディアファイル全体が保存されます。ストリーミングモードでは、HTTP Client キャッシュに、最初のチャンクのメディアファイルが保存されます。HTTP Client キャッシュには、どちらのモードでも 100 MB のプロンプトが保存されます。構成されている HTTP Client のメモリファイルサイズよりも大きいファイルはキャッシュされません。
- VRU メディア プレーヤー キャッシュ
- 非ストリーミングモードでは、VRU メディア プレーヤー キャッシュは使用しません。ストリーミングの役割では、VRU メディア プレーヤー キャッシュには、ファイルのすべてのサイズが格納されます。非ストリーミングモードでは、VRU メディア プレーヤー キャッシュに 16 MB が保存されます。ストリーミングモードでは、32 MB を保存できます。
クエリ URL のキャッシング
クエリは、疑問符(?)の後に 1 つ以上の name=value 属性ペアが続く URL です。Unified CVP VXML サーバは、動的 VXML ページの生成時にクエリ URL を使用します。各コールは一意なので、クエリ URL から取得したデータは、キャッシュメモリを使い古す場合があります。クエリ URL にアカウント番号や PIN などの情報を含め得る場合があるので、データはセキュリティリスクに該当する場合が考えられます。
Cisco IOS は、デフォルトでクエリ URL キャッシングを無効にします。無効になっていることを確認するには、Cisco IOS で show run コマンドを入力し、次の Cisco IOS コマンドが表示されていないことを確認します。
Gateway configuration: http client cache query
Cisco VVB でのメディアファイルの展開
Cisco VVB には HTTP クライアントが含まれています。クライアントは、VXML ドキュメント、オーディオファイル、その他のファイルリソースをフェッチし、フラッシュメモリに格納します。
キャッシングプロパティは、VXML リソース、オーディオによる指示、文法ファイル、およびスクリプトファイルに関連付けられます。
デフォルトでは、クエリ URL はキャッシュされません。クエリは、疑問符(?)の後に 1 つ以上の name=value 属性ペアが続く URL です。
キャッシュ エージング
HTTP Client は、キャッシュされた各エントリの鮮度によってそのキャッシュを管理します。キャッシュされたエントリが新しいのか古いのかは、[経過期間(Age)
] および [FreshTime
] によって異なります。[経過期間(Age)
] は、サーバから最後にファイルがダウンロードされてからの経過時間です。[FreshTime]
は、ファイルが最後にダウンロードされてから HTTP Client キャッシュにファイルがとどまると想定される時間です。
いくつかの変数は、サーバからの HTTP メッセージヘッダーやキャッシュ更新値などのファイルの [FreshTime]
に影響します。
ファイルの [FreshTime]
は、次のシーケンスで決定されます。
-
ダウンロード時に、ファイルに
Cache Control: max-age
ヘッダーがある HTTP メッセージヘッダーがある場合、[FreshTime]
は、max-age
となります。 -
ステップ 1 を適用しない場合 、
[FreshTime]
は、Expires
ヘッダーからDate
ヘッダーを引き算した値になります。
Note
HTTP/1.1 仕様である、RFC 2616(ハイパーテキスト トランスポートプロトコル)は、
Cache Control: max-age
ヘッダーまたはExpires
ヘッダーのどちらかを使用することを推奨しています。
-
前述のヘッダーが既存しない場合、
FreshTime
は、Date
ヘッダーの 10% 分の値から、最終更新日
ヘッダーを差し引いた値になります。
Cisco IOS VXML ゲートウェイの場合、FreshTime
の値を、http client cache refresh
コマンドと一緒にファイルに割り当てることができます。ただし、その値が適用されるのは、前のシーケンスで値の設定に失敗した場合のみです。
古いファイルは、必要な場合にのみ更新されます。古くキャッシュされたエントリは、次の条件に基づいて新しいファイルのスペースが削除されるまでキャッシュ内に残ります。
-
キャッシュされたエントリが古くなった。
-
更新カウントがゼロ(0)である。つまり、キャッシュされたエントリが使用されていない。
-
キャッシュには、別のエントリのスペースを創るためのメモリスペースが必要です。
[経過時間(Age)] が、[FreshTime] を超過し、ファイルを再生する必要がある場合、HTTP Client は、メディアサーバを使用してファイルを更新するか否かを判断します。HTTP Client は、GET リクエストをサーバに送信し、上限付き GET を使用してネットワークトラフィックへの影響を最小限に抑えます。GET 要求では、サーバに送信されるヘッダーに If-Modified-Since が含まれます。このヘッダーがあると、サーバは 304 応答コード(未修正)を返すか、ファイルが最近更新された場合は、ファイル全体を返します。[経過時間(Age)] が、[FreshTime] を超過し、ファイルを再生する必要がある場合、HTTP Client は、メディアサーバを使用してファイルを更新するか否かを判断します。HTTP Client は、GET リクエストをサーバに送信し、上限付き GET を使用してネットワークトラフィックへの影響を最小限に抑えます。GET 要求では、サーバに送信されるヘッダーに If-Modified-Since が含まれます。このヘッダーがあると、サーバは 304 応答コード(未修正)を返すか、ファイルが最近更新された場合は、ファイル全体を返します。
この条件付き GET は非ストリーミングモードにのみ適用されます。ストリーミングモードでは、HTTP Client は常に条件なしの GET を発行します。ストリーミングモードで各 GET が条件なしでリロードされる GET リクエストには、If-Modified-Since ヘッダーは含まれていません。
CVP コールサーバの設計に関する考慮事項
CVP コールサーバはレポーティングサービスを提供し、IBM Informix Dynamic サーバ(IDS)データベース管理システムをホスティングします。データベースのスキーマを使用すると、データベースに対してカスタムのレポートを作成できます。レポーティングサービス自体は、データベースの管理アクティビティおよびメンテナンスアクティビティ(バックアップや消去など)を実行しません。ただし、Unified CVP では、こうしたメンテナンス タスクに Operations Console を介してアクセスできます。
レポーティングサービス:
-
コンタクトセンター内のセルフサービス アクティビティの 履歴レポートを提供します。サービスは、コンタクトセンター マネージャーのコールアクティビティをまとめたものです。
-
さまざまな VRU アプリケーション運用分析も提供できます。
-
VXML サーバの IVR サービスと SIP サービスからレポートデータを受信します。Reporting サービスは、このデータを Informix データベースに変換して書き込みます。
ソリューションは、単一の複数の CVP コールサーバのいずれかを使用できます。単一の コールサーバが、必ずしもシングルポイント障害であるわけではありません。データベース管理システムは、データの安全性とセキュリティを提供します。ソリューションは、ソースコンポーネントに関する情報が永続的にバッファリングされたことが原因の一時的な機能停止に耐えることができます。
ソリューションが複数の コールサーバを使用している場合は、各 CVP コールサーバを 1 つの コールサーバにのみ関連付けできます。また、レポートは、複数の Informix データベース間で作成できません。
Note |
Unified CVP のサブコンポーネントは、マシン時間そのものを同期できません。ロギングとレポートに対して正確なタイムスタンプを保証するために、NTP などのコンポーネント間の時刻同期機能を提供します。 |
CVP コールサーバの機能
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 は、毎晩管理ログを抽出します。
-
CVP バックアップおよびリストア
Operations Console を使用すると、データベースバックアップの日次スケジュールを設定したり、オンデマンドでデータベースバックアップを実行できます。大きな障害が発生した場合は、前回のバックアップ時間まで手動でデータベースを復元できます。これにより、データの損失は 24 時間までになります。
CVP コールスタジオの設計に関する検討事項
CVP Call Studio でアプリケーションを設計する場合は、アプリケーションを小規模で、ビジネスフローに近い状態でマッピングしてください。大きなアプリケーションでは、保守と作業が難しくなります。サブフローと独立したアプリケーションのバランスを維持します。
Unified CVP の併置
SIP 呼制御に必要なサーバの数を計算するには、次の式を使用します。
(Self Service + Queue and Collect + Talking) / 3000, rounded up
ここで、
セルフサービスは、SIP 呼制御を要求し、VXML サーバ上でアプリケーションを実行するコールの数です。
キューと収集は、SIP 呼制御を必要とするコールの数であり、コールサーバ上でのみ Microapps を使用してアプリケーションを実行します。
通話中は、エージェントのコール数です。
次の例は、VXML セッションおよび HTTP セッションだけに適用されます。
((3000) + (500) + 3700) / 3000 = 3 servers
VXML 要件を処理するフロースルーコールにセッション ボーダー コントローラ(SBC)として CUBE を使用する場合は、例で示すサイジング情報を使用します。
フロースルーコールのみ(VXMLなし)を処理するためにセッション ボーダー コントローラ(SBC)として CUBE を使用する場合、音声アクティビティ検出(VAD)を考慮し、http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/order_guide_c07_462222.html の『Cisco Unified Border Element Ordering Guide』に記載されているサイジング情報を参照してください。
Contact Center Enterprise 設計上の考慮事項
Contact Center Enterprise ソフトウェアは、企業全体へのマルチチャネル コンタクトのディストリビューションを実現します。このソフトウェアは、インバウンドおよびアウトバウンドの電話、Web コラボレーション要求、 E メール メッセージ、チャット要求をサポートできます。また、地理的に離れているコンタクト センターもサポートできます。Contact Center Enterprise ソフトウェアはオープンな標準ベースのソリューションであり、ルーティング、キューイング、モニタリング、耐障害性などの機能を備えています。
Note |
Unified CCE は、Contact Center Enterprise ソリューションのいずれかと、すべてのソリューションのコア コンポーネントのいずれかの両方を示す名前です。 |
ルータの設計上の考慮事項
冗長 Unified CCE サーバを地理的に分散したり、同じ物理サイトで配置できます。実稼働の展開では、ルータと Logger は、パブリックネットワークとは分離されたプライベートネットワーク経由で接続する必要があります。
Note |
セントラルコントローラと PG には同じプライベート ネットワーク パスを使用できます。 |
Logger の設計上の考慮事項
Logger データベースの設計は、通常 2 週間分のデータが保持されています。この期間は、データが AW-HDS-DDS に複製されるのに十分な時間を与えます。
この Logger は、ルータとして同じプライベートネットワーク パスを使用します。
周辺機器ゲートウェイ設計上の考慮事項
エージェント周辺機器ゲートウェイ設計上の考慮事項
エージェント 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 ルート ポイントで一意であることを確認します。 |
アクティブ PG シャットダウン
実稼働環境でアクティブな周辺機器ゲートウェイがシャットダウンしないようにします。これにより、反対側に接続してアクティブになる間、1 分以上のサービスの中断が発生します。中断の長さは、構成のサイズと周辺機器の種類によって異なります。たとえば、VRU 周辺機器は、通常より短い時間しかかかりません。VRU の別のサイドでは、再アクティブ化まで 30 秒以下を要する場合があります。
音声応答設備の周辺機器ゲートウェイ設計上の考慮事項
標準規格の 3 つの PG モデルでは、VRU PG にはサイド A とサイド B にある CVP サーバに 1:1 ペアリングをする 2 台の PIM が含まれています。
メディアリソース周辺機器ゲートウェイ設計上の考慮事項
標準規格 3 台の PG モデルでは、MR PG に次の機能をサポートする PIM が含まれます。
-
アウトバウンド オプション
-
ビジネス チャットおよび E メール
-
Customer Collaboration Platform— この PIM は、タスクルーティングとエージェントリクエストを処理します。
-
サードパーティ製品との統合
Administration & Data サーバ設計上の考慮事項
リファレンス設計ごとの Administration & Data サーバ制限
各 Logger に対してたくさんの Administration & Data サーバを展開できます。
各 Logger 側のコンポーネント | 2000 エージェント | 4000 エージェント | 12,000 エージェント |
---|---|---|---|
AW-HDS-DDS |
各サイドに 1 つ、コアコンポーネントと同じサーバにインストールされます。 |
サイドごとに 2 つ |
NA |
HDS-DDS |
該当なし |
該当なし |
サイドごとに 1 つ |
AW-HDS |
オプションで、コアコンポーネントとは別のサーバにインストールされた、各サイドごとに 1 つの AW-HDS または AW-HDS-DDS のいずれか |
NA |
各サイドごとに 3 つ |
リアルタイム ディストリビュータのみ 1 |
サイドごとに 2 つ |
サイドごとに 2 つ |
各サイドごとに 5 つ |
Note |
各リアルタイム ディストリビュータは 64 人のユーザをサポートできます。 |
Live Data サーバ設計上の考慮事項
ライブデータ構成によるクライアントのレポート
2000 エージェントリファレンス設計にはライブデータの併置構成を使用します。スタンドアロン Live Data サーバを使用するソリューションの場合、Unified CCE Rogger 展開に対して通常、小規模の Live Data 展開構成を使用します。通常は、個別のルータおよび Logger を使用して大規模の Live Data 展開構成を使用します。
Note |
標準規格の Cisco Finess エージェントデスクトップには、ライブデータガジェットが含まれます。 |
Cisco Virtualized Voice Browser の設計上の考慮事項
ソリューションで必要な仮想化音声ブラウザは、ソリューションが VXML ゲートウェイで必要とする VRU ポートに応じて異なります。ソリューションに必要な SIP セッションの数に応じた Cisco VVB をインストールしてください。以下の表に、Cisco VVB による機能サポートを示します。
プラットフォームまたは機能 |
Cisco Virtualized Voice Browser に関する考慮事項 |
---|---|
音声コーデック |
G711 |
コール フロー |
スタンドアロン コール フロー、およびコール存続可能性を備えた包括的コール フローがサポートされます。 |
ASR/TTS |
サポート対象 |
サービス コールバック |
サポート対象 |
HTTP |
サポート対象 |
HTTPS |
サポート対象 |
ローカル プロンプト |
サポート対象 |
ローカル ホスト名の解決 |
サポート対象 |
MRCP v1 および v2 |
サポート対象 |
VXML 2.0 および 2.1 |
サポート対象 |
RTSP ストリーミング |
未サポート |
ビデオ |
未サポート |
Unified Communications Manager の設計上の考慮事項
Note |
リファレンス設計のレイアウトでは 7500 ユーザの Unified CM OVA を使用しており、サブスクライバの冗長ペアごとに 2000 の Contact Center Enterprise エージェントがサポートされます。別の Unified CM OVA を使用する場合は、リファレンス設計のレイアウト内のサーバからクラスタを移動させるか、仕様ベースのハードウェア ポリシーに従ってください。仕様ベースのポリシーの詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.html でソリューションに応じた Cisco Collaboration Virtualization のページを参照してください。 |
Cisco Unified Communications Manager(Unified CM)は、Unified CVP から渡されたコールを Unified CCE で選択されたエージェントに接続します。Unified CVP は、SIP を使用する Unified CCE エージェント電話またはデスクトップに発信者を転送します。Unified CVP コール サーバは、Unified CCE からエージェント ラベルを受信し、そのコールを SIP プロキシを使用してルーティングします。コールはクラスタ内の適切な Unified CM サブスクライバに送信され、発信者がエージェントに接続されます。コール サーバがコール シグナリングの代わりになり、転送完了後、コール シグナリング パスに留まります。ただし、RTP ストリームは、発信元ゲートウェイから電話に直接流れます。
すべての Contact Center Enterprise ソリューションは、冗長 Unified CM、Unified CCE、Unified CVP のコンポーネントを使用します。冗長性のために、ソリューションでコア システムの半分が失われることがありますが、ソリューションは引き続き機能します。そのような場合、ソリューションは、まだ動作可能なコンポーネント上の VRU セッションまたはエージェントに、Unified CVP を介してコールを再ルーティングすることによりコールを処理します。可能な場合は、Unified CM パブリッシャでデバイス、コール処理、CTI Manager サービスが実行されないように、Unified CCE を展開してください。
自動フェールオーバーとリカバリを有効にするには、冗長コンポーネント ペアをプライベート ネットワーク パスを介して相互接続します。コンポーネントは、障害検出に TCP ハートビート メッセージを使用します。Unified CM は、フェールオーバーとリカバリにクラスタ設計を使用します。各クラスタには Unified CM パブリッシャと複数の UM サブスクライバが含まれています。エージェントの電話とコンピュータはプライマリ ターゲットに登録されますが、プライマリで障害が発生した場合は、バックアップ ターゲットに自動的に再登録されます。
Contact Center Enterprise ソリューションの Unified CM クラスタを設定するには、以下の手順を実行します。
-
Unified CM で SIP トランクを設定します。
-
エージェント ラベルを設定するときは、どのデバイスがルーティング クライアントかを考慮します。ラベルが Unified CM に直接返される場合は、Unified CM がルーティング クライアントになります。ラベルが Unified CVP に送信される場合は、Unified CVP スイッチ レッグ コール サーバのそれぞれにラベルを関連付けます。
エージェント PG への Unified CM 接続
次の方法で、Agent PG を展開すると Unified Communications Manager クラスタに接続できます。
-
サブスクライバの各ペアにエージェント PG を導入します。各サブスクライバは、CTI Manager サービスを実行します。各エージェント PG は、対応するサブスクライバペア上で実行されている CTI Manager に接続します。次の図は、4 つのプライマリサブスクライバが必要で、4 つのバックアップサブスクライバが導入され、1:1 の冗長性を提供する例を示しています。
次の図は、2 つのエージェント PG ペアを含むソリューションのコンポーネントと 4 つのサブスクライバを持つクラスタ間の接続を示しています。
-
クラスタ全体に対して 1 つのエージェント PG を導入します。このタイプの導入では、CTI Manager を実行している 1 ペアのサブスクライバが必要です。CTI Manager サービスを実行しているサブスクライバを含む、すべてのサブスクライバ間でエージェントの電話機の登録を分散します。次の図は、4 つのプライマリサブスクライバが必要で、4 つのバックアップサブスクライバを導入して 1:1 の冗長性を提供する例を示しています。
Note
クラスタがバックオフィス電話機とエージェント電話機の両方をサポートしている場合は、このオプションを使用します。
次の図は、2 つのエージェント PG ペアを含むソリューションのコンポーネントと 4 つのサブスクライバを持つクラスタ間の接続を示しています。
このモデルでは、PG のサーバ数が減ります。もう 1 つの利点は、クラスタ全体に対して単一の PIM が使用できることです。そのため、多くのサブスクライバにまたがり、チームを作成できます。これにより、たとえば、スーパーバイザは、クラスタ内のサブスクライバに登録されたエージェント電話機をモニタできます。ただし、この導入では、クラスタ上のリソース使用率が若干高くなる可能性があります。Cisco Unified Communications Manager Capacity ツール を使うと、ソリューションの Unified CM サーバのサイズを変更できます。
単一回線および複数回線機能のサポート
単一回線および複数回線のサポート
Unified CCE は、単一回線と複数のエージェント回線の Unified CM ベースのモニタリングをサポートします。複数回線がサポートする機能は次のとおりです。
-
全回線のコールのモニタリングとレポート。
-
コール開始以外では、ACD 以外の内線上のすべての呼制御は、複数回線に対応したデスクトップでサポートされています。初期コール設定後、デスクフォンから開始されたコールを制御できます。
-
最大 2 つのコールアピアランスが必要です。
-
1 台の電話機あたり最大 4 回線、1 ACD 回線、および最大 3 つの非 ACD 回線をサポートします。
-
ACD および非 ACD 回線の共有電話をサポートします。相違点については、以下の表を参照してください。
-
ACD 以外の回線を共有している複数のデバイスを構成できますが、エージェントにログインできるのは 1 つのデバイスのみです。Unified CCE は、共有電話をサポートしているので、自宅やオフィス両方で音声設備を備えているエージェントが音声メール回線を共有できるようにします。
Note
共有 ACD 以外の回線は、PG Explorer で非 ACD 回線影響の構成をサポートしません。
-
マルチライン エージェント モードが有効な場合、Unified CCE にサードパーティの CTI アプリケーションとの下位互換性がない場合があります。サードパーティベンダーとのマルチラインサポートを検証します。
単一回線の対複数回線の動作
操作 |
単一回線の動作 |
複数回線の動作 |
||
---|---|---|---|---|
通話が 2 番目の回線にあるときに、ルーティングされた通話を受けることはできますか。 |
あり |
はい。展開に影響がないことを確認するために非 ACD 回線影響が設定されている場合。 |
||
Unified CM ベースのサイレントモニタを使用したスーパーバイザモニタ |
はい |
はい
|
||
コール パーク |
監視されていない 2 つ目の回線でサポート |
すべての回線がモニタ対象のため、サポートされていません。 |
||
通話待機/ビジートリガー > 1 |
サポートあり |
サポートは終了しました。69xx シリーズの電話機では 1 にハードコードされています(複数回線を有効にする前に構成する必要があります)。 |
||
2 番目の回線コールに関するレポート |
Unified CM での CDR の使用 |
監視されていないデバイスを使用したエージェントの非 ACD 回線、または別のエージェントの非 ACD 回線との間の通話に対する終了通話詳細レコードは、非 ACD 周辺機器通話タイプで報告されます。ACD 以外の回線上のすべてのコールに対するレポートは、そのエージェントの [エージェント間隔(Agent Interval)] テーブルでキャプチャされます。 |
||
電話機で構成済みの回線数 |
制限に関する説明はなし(1 回線の監視のみ) |
4 回線を超える構成は行わないでください。構成すると、エージェントが任意の回線にサインインできなくなります。これにより、構成アラートが生成されます。 |
||
ACD 共有回線 |
共有電話は、最大 2 台のデバイスに対し ACD 回線でサポートされています。デバイス制御は、オフフックにするか、通話を発信または受信することで、デバイスそのものを介して選択されます。 |
共有電話は、最大 2 台のデバイスに対し ACD 回線でサポートされています。デバイス制御は、オフフックにするか、通話を発信または受信することで、デバイスそのものを介して選択されます。 |
||
ACD 以外の共有回線 ACD 以外の回線を共有している複数のデバイスを構成できますが、エージェントにログインできるのは 1 つのデバイスのみです。Unified CCE は、共有電話をサポートしているので、自宅やオフィス両方で音声設備を備えているエージェントが音声メール回線を共有できるようにします。
|
監視されていない回線でのサポート、構成制限無し |
非 ACD 回線のサポートは、共通の 2 番目の回線を持つデバイスに 1 人のエージェントがログインする場合に限られています。 エージェントは両方の電話機に同時にサインインできません。 別のエージェントは、同じ共通回線を持つ別のデバイスにサインインできません。 |
Unified CM トランクでの MTP の使用
ソリューションで Unified CM SIP トランク を使用する場合は、Cisco Unity Voice Mail や Mobile Agent などの特定のコールフローに、MTP リソースが必要な場合があります。
これは、DTMF のインバンド対アウトオブバンド機能など、エンドポイントの交渉済みメディア機能が一致しない場合の必要です。この場合、Unified CM は、DTMF メディア機能の不一致により、MTP を動的に配置します。
サードパーティ製のデバイスで相互運用する場合、ソリューションに MTP が必要になる場合があります。
モバイル & リモート アクセス
シスコ コラボレーション エッジ アーキテクチャには、エンタープライズ ネットワークにはないデバイスによるアクセスを可能にする Unified Communications Mobile and Remote Access(MRA)が含まれています。MRA は Expressway を使用して、安全なファイアウォール トラバーサルを提供し、Unified CM 登録をサポートします。Unified CM は、サポートされているデバイスに呼制御、プロビジョニング、メッセージング、およびプレゼンスサービスを提供できます。
コラボレーションエッジの詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/tsd-products-support-series-home.html 次のドキュメントを参照してください。Expressway の展開と構成の詳細については、http://www.cisco.com/c/en/us/support/unified-communications/expressway-series/tsd-products-support-series-home.html のドキュメントを参照してください。MRA のデバイスサポートの詳細については、ソリューションの 互換性マトリックス を参照してください。
ソリューションで MRA を使用する場合は、次の点を検討してください。
-
Cisco Finesse クライアントとサーバ間の接続は、MRA 接続ではなく、VPN を使用しています。
-
一部の電話機は、MRA でのエクステンションモビリティをサポートしていません。
-
Contact Center Enterprise ビデオ展開は、MRA に対応していません。
-
電話機の BiBに依存する Agent Greeting、Unified CMベースのサイレントモニタリングなどのコンタクトセンターの特定機能は MRA を介してはサポートされていません。
-
VPN のスプリットトンネリングが構成されている場合は、同じクライアントマシン上で、MRA を備えた Jabber と Finesse デスクトップを使用できます。Cisco AnyConnect モビリティ クライアント スプリット トンネリングの構成に関しては、https://www.cisco.com/c/en/us/support/security/anyconnect-secure-mobility-client/products-installation-and-configuration-guides-list.html を参照してください。
-
VPN スプリットトンネリングを利用できない場合は、2 つのクライアントに分割した後に実行できます。
-
1 台のクライアントマシンで MRA を備えた Jabber と 2台目のクライアントマシンで VPN 接続経由の Finesse デスクトップを実行するリモートエージェント。
-
MRA 経由で接続されているラップトップで Jabber ソフトフォンを実行し、Xenapp シンクライアントとして Finesse デスクトップを実行するリモートエージェント。
-
Cisco Finesse の設計上の考慮事項
Cisco Finesse は、Contact Center Enterprise ソリューションで使用するスーパーバイザおよびエージェントのデスクトップです。Cisco Finesse サーバは VM 上にインストールします。クライアントは Cisco Finesse サーバを指し示す Web ブラウザを使用します。Cisco Finesse ソフトウェアはクライアントにインストールされません。これにより、インストールとアップグレードが簡素化され、その所要時間も短縮されます。
Cisco Finesse クライアント(管理コンソール、エージェント デスクトップ、スーパーバイザ デスクトップ)でサポートされるブラウザとオペレーティング システムについては、Contact Center Enterprise 互換性マトリクス を参照してください。
Cisco Finesse デスクトップ アプリケーションは、クライアントコンポーネントとサーバ コンポーネントから構成されています。クライアントは、OpenSocial 1.0 仕様に準拠するガジェットとして分散される標準の Web プログラミング要素(HTML、JavaScript)を使用します。シスコやサードパーティのガジェットを使用するように、レイアウト管理機能を使ってエージェント デスクトップを設定できます。
Cisco Finesse は Enterprise Mashup と呼ばれるアプリケーション クラスの一部です。Enterprise Mashup は、クライアント側のアプリケーションを結合する Web 中心のメソッドです。Cisco Finesse ガジェット ベースのアーキテクチャによって、クライアント側のマッシュアップが可能になり、より簡単に統合できるようになります。ガジェットのアップグレードは個別に処理されるので、バージョンの互換性の依存関係はわずかです。
Cisco Finesse 管理コンソールを使って、エージェントとスーパーバイザのデスクトップをカスタマイズすることができます。管理者は、デスクトップに表示するタブの名前を定義して、各タブに表示するガジェットを設定できます。
次の表は、Cisco Finesse の機能の要約です。
デスクトップ機能 |
Cisco Finesse |
||
---|---|---|---|
デスクトップ チャット |
可 |
||
チーム メッセージ |
可 |
||
ブラウザ ベースのデスクトップ |
可 |
||
カスタム開発 |
可(HTML や JavaScript などの標準の Web コンポーネントを使用) |
||
デスクトップのセキュリティ |
可
|
||
ワークフローの自動化 |
可 |
||
モバイル(リモート)エージェント |
可 |
||
通話モニタリング |
可 |
||
モニタ モードのアプリケーション |
NA |
||
アウトバウンド コール |
可 |
||
Microsoft ターミナル サービスのサポート |
NA |
||
Citrix Presentation Server のサポート |
NA |
||
エージェントのモビリティ |
可 |
||
エージェントのグリーティング |
可 |
Cisco Finesse REST API
Cisco Finesse は、クライアント アプリケーション向けの REST API を提供して、サポートされているサーバ機能にアクセスします。REST API は、HTTPS 経由で XML ペイロードをトランスポートします。
Cisco Finesse は、サードパーティの統合を支援する JavaScript ライブラリおよびサンプル ガジェット コードも提供しています。REST API、JavaScript ライブラリ、およびサンプル ガジェットの開発マニュアルは、https://developer.cisco.com/site/finesse/ のシスコ開発者ネットワークで確認できます。
Cisco Finess エージェントデスクトップ
エージェントデスクトップには次の追加設定なしの機能が備わります。
-
基本呼制御(通話への応答、保留、取得、終話、発信)
-
高度な呼制御(コンサルテーション、コンサルト後の転送、コンサルト後の会議)
-
シングルステップ転送(エージェントは、最初にコンサルテーションコールを開始せずにコールを転送できます)
-
キュー統計ガジェット(エージェントが割り当てられているキューに関する情報を表示)
-
エージェントのコール履歴と状態履歴の表示
-
準備中およびサインアウトの理由コード
-
連絡先リスト
-
ワークフロー
-
モバイルエージェントのサポート
-
Progressive、Predictive、Preview Outbound、Direct Preview Outbound
-
デスクトップ チャット
-
チーム メッセージ
Cisco Finesse スーパーバイザデスクトップ
Cisco Finesse スーパーバイザ機能により、エージェントデスクトップが拡張し、より多くのスーパーバイザ専用ガジェットが追加されます。たとえば、次のような機能があります。
-
エージェントのステータスを表示するシステム アドミニストレーション ガイド ガジェット
-
スーパーバイザのキューのキュー(スキルグループ)統計を表示するキュー統計ガジェット
-
スーパーバイザコール履歴と状態履歴の表示
-
スーパーバイザチーム内のエージェントのコール履歴と状態履歴を表示
-
システム アドミニストレーション ガイド ガジェット(TPG)からのエージェントコール情報
-
Unified CM のサイレント モニタリング
-
割り込み
-
代行受信
-
エージェントの状態変更(スーパーバイザはエージェントをサインアウトでき、強制的に [準備中(Not Ready)] ステータスまたは [準備完了(Ready)] ステータスに変更できます)
Cisco Finesse IP 電話エージェント
Cisco Finesse IP Phone Agent(IPPA)を使用すると、エージェントは、ブラウザを介してではなく、Cisco IP 電話から Cisco Finesse 機能にアクセスできます。Cisco Finesse IPPA は、ブラウザで使用可能な Cisco Finesse 機能のサブセットのみを提供します。これにより、エージェントとスーパーバイザは、PC にアクセスせずに Cisco Finesse コールを受信および管理できます。
Note |
スーパーバイザは、IP Phone 上でのみエージェントタスクを実行できます。Cisco Finesse IPPA は、モニタ、割り込み、代行受信などのスーパーバイザタスクをサポートしていません。 |
Cisco Finesse IPPA は次の機能をサポートしています。
-
ログインおよびログアウト
-
コール変数の表示
-
保留ステータス
-
ラップアップの理由
-
オプションの要約
-
準備中の理由
-
理由コードを使用したステータス変更
-
ワンボタンサインイン
Cisco Finesse 管理コンソール
Cisco Finesse には、管理者が次を構成できる管理アプリケーションが含まれています。
-
CTI サーバおよび Administration & Data サーバデータベースへの接続
-
VOS 複製用のクラスタ設定
-
準備中およびサインアウトの理由コード
-
ラップアップの理由
-
連絡先リスト
-
ワークフローとワークフローアクション
-
コール変数および ECC 変数レイアウト
-
デスクトップのレイアウト
-
Desktop Chat サーバの設定
-
チームリソース
-
Cisco Finesse IP 電話エージェント(IPPA)
理由コード、ラップアップの理由、連絡先リスト、ワークフロー、およびデスクトップレイアウトは、グローバルか(すべてのエージェントに適用)、特定のチームにすることができます。
Cisco Finesse 展開に関する検討事項
Cisco Finesse とマルチライン機能
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.へのセットの使用中のきっかけ。
Cisco Finesse と Citrix
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 およびファイアウォールを使用した Cisco Finesse
一部のソリューションには、ネットワークアドレス変換(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 とファイアウォールに関しては、ソリューションセキュリティの章を参照してください。 |
IP Phone および IP Communicator のサポート
Cisco Finesse は、Cisco IP ハードウェア電話機および Cisco IP Communicator ソフトウェア電話機の使用をサポートしています。
サポートされる電話機モデルおよび IP Communicator のバージョンの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html のソリューション向け「互換性マトリックス」を参照してください。
IP Phone およびサイレントモニタリング
サイレントモニタリングは、IP ハードウェア電話機と Cisco IP Communicator の両方をサポートします。
IP Phone およびモバイルエージェント
モバイルエージェント機能では、特定のタイプの電話機は不要です。この機能ではアナログ電話でも使用できます。
IP Phones および Citrix または MTS
Cisco Finesse は、Citrix または MTSの使用時に、IP ハードウェア電話機および Cisco IP Communicator の両方をサポートします。
このような環境では、エージェントデスクトップ PC に Cisco IP Communicator をインストールします。Citrix または MTS サーバに Cisco IP Communicator を展開することはできません。
Cisco Finesse と Cisco Jabber
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 のソリューションに対する「互換性マトリックス」を参照してください。
デスクトップ チャット
デスクトップチャットは XMPP ブラウザベースのチャットであり、これは Cisco Instant Messaging and Presence(IM & P)サービスによって提供されます。デスクトップチャットを使用すると、エージェント、スーパーバイザは、組織内の各分野の専門家(SME)とチャットを行うことができます。
詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.htmlを参照してください。
インスタントメッセージングおよびプレゼンス(IM&P)は、Unified CM プラットフォーム内でプレゼンスおよびチャット機能を提供します。デスクトップ チャット インターフェイスは、Finess エージェントデスクトップにホストされ、個別に IM&P サービスにログインする必要があります。
Note |
Release 12.5 (1) からの HCS 展開では、デスクトップチャットユーザ検索に、デフォルトでは LDAP のすべてのユーザが表示されます。この検索を調整して、エージェントまたはスーパーバイザが検索を開始した対応するカスタマーのユーザを、Cisco Unified Communications Manager IM and Presence Service で定義されている組織ユニット(OU)に基づいて表示できます。これは Cisco Unified Communications Manager IM and Presence Service、リリース 12.5(1)SU2 ES ビルドバージョン 12.5.1.12900-26 以降でサポートされています。詳細については、Cisco TAC にお問い合わせください。 デスクトップチャットでは、Cisco Mobile Remote Agent /VPN ベースの IM&P サーバへのアクセスはサポートされていません。デスクトップチャットでは、チャットサーバに接続する IM&P サーバへのダイレクトアクセスが必要となります。 |
詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html にある『Cisco Finesse アドミニストレーション ガイド』の「Desktop Chat サーバの設定」の項を参照してください。
シスコ インスタント メッセージングおよびプレゼンス(IM&P)
IM&P は Jabber プラットフォームを組み込み、XMPP プロトコルをサポートし、複数のデバイスを介してユーザのプレゼンスを追跡できます。IM&P は、チャット機能が有効になっているユーザそして、Unified CM(LDAP 統合が有効である場合は、LDAP から)からユーザリストをプルします。チャット機能が有効になっている Unified CM ユーザのみ IM&P にログインできます。
Cisco IM&P は、高可用性を実現するためにクラスタ化された展開の複数の形式をサポートします。Finesse は、特定のエージェント PG で構成されます。このエージェント PG は、特定の IM&P クラスタに関連付けられた Unified CM に接続されます。Finesse を IM&P クラスタに接続するよう構成します。
アイデンティティ、プレゼンス、Jabber
ユーザは、IM&P で識別され、これは、username@FQDN.com 形式の固有のアイデンティティです。
Unified CCE では、アイデンティティが Unified CCE で設定されたユーザ名または peripheralID と同じではありません。
ユーザは、ユーザ ID、プレゼンスステータス(使用可能、使用不可、またはビジー)、およびユーザのプレゼンス機能の観点から説明されます。
ユーザのプレゼンスステータスは、エージェントステータスとは関係なく、ユーザのポストログインによって個別に管理される必要があります。
Cisco IM&P サービスは、複数のデバイスでユーザのプレゼンスステータスを組み合わせ、連絡先リストに連絡先を追加したサブスクライバに公開します。
IM&P は、エージェントがログインしているすべてのデバイスの状態マトリックスから導出される、ユーザの構成されたプレゼンスをサポートします。Cisco IM&P は、ユーザに対する XMPP クライアントからのプレセンスの送信元を、CUCM からオンホック、およびオフホックステータスを、Microsoft Exchange から会議中ステータスを取得し、ユーザの全体的な構成されたプレゼンスを生成します。デスクトップチャットでは、構成されているユーザのプレゼンスが表示されます。構成されたプレゼンスの到達方法に関しては、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-user-guide-list.html の『Cisco IM&P ユーザガイド』を参照してください。
展開ガイドに関係なく、デスクトップチャットは、Finesse デスクトップにログイン後、ユーザの IM&P アイデンティティを使用して明示的なログインをする必要があります。
SSO はデスクトップチャットではサポートされていないため、SSO モードでは明示的なログインが必要です。
デスクトップチャットのプレゼンスは、設定されているデバイス間で通信できるユーザの存在を示しています。
デスクトップチャットの可用性は、ユーザの統合された IM&P プレゼンスにも反映します。
デスクトップチャットにログインすると、デフォルトで、ユーザのステータスは利用可能に設定されます。
デスクトップチャットにログインするエージェントは、Jabber または IM&P に接続されている XMPP プラットフォームでは利用可能として見られ、該当ユーザと連絡を取り合うことができます。
Note |
ファイル転送は、デスクトップチャットを使用したユーザ間の通信でのみサポートされています。サポートされているファイルタイプおよび添付ファイルの最大サイズに関する詳細は、『Cisco Unified Contact Center Express Administration and Operations Guide』の「デスクトッププロパティ CLI」項を参照してください。 |
デスクトップチャットの可用性の例
デスクトップチャットユーザは、デスクトップチャットと Jabber に同時にログインできます。着信チャットは、デスクトップチャットを含む、ログインしているすべてのクライアントにリレーされます。ただし、デスクトップチャットではマルチデバイス メッセージングがサポートされていません。そのため、Jabber などの他の XMPP クライアントから送信されたメッセージはデスクトップチャット内に表示されません。代替クライアントが着信チャットへの応答に使用されると、ユーザがデスクトップチャットを使用して応答を開始するまで、後続メッセージはデスクトップチャットに表示されません。
ネットワーク設計に関する詳細は、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の『ソリューション リファレンス ネットワーク設計 ガイド』を参照してください。
Cisco IM&P 設計上の考慮事項
Finesse サーバからのチャットサーバ URI を取得すると、Finesse ブラウザによって HTTP を介して Cisco IM&P に個別に接続することができるようになります。HTTPS 導入で自己署名証明書を使用する場合は、別個の証明書を受け入れる必要があります。
チャットの相互作用は、XMPP プロトコルを介して、長期ポーリングを使用した HTTP 接続、または、Cisco IM&P で確立された BOSH で発生します。
Cisco IM&P サーバ構成の取得以外では、チャット関連の機能に対する Finesse サーバおよびブラウザ間の通信はありません。
チャットログの持続は、デスクトップセッション中にブラウザで利用できます。
ユーザ検索機能には、Unified CM LDAP 統合が必要です。それがない場合、リモートの連絡先はユーザが手動で追加する必要があります。
ユーザが、既存の Jabber ユーザの場合、デスクトップチャットおよびセッションで維持される Jabber 間で同じ連絡先が共有されます。
Cisco IM&P で推奨さ入れている制限やガイドライン以外で、デスクトップチャットでの進行中のチャットや連絡先の数には制限はありません。進行中のチャットや連絡先の数に対する制限、およびチャット向けの Cisco IM&P サーバの構成方法に関しては、『IM&P ソリューション リファレンス ネットワーク ガイド』を参照してください。
Note |
デスクトップチャットでは、信頼する Cisco IM and Presence の証明書が必要です。証明書の受け入れ方法の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-user-guide-list.html の『Cisco Unified Contact Center Express 向け Cisco Finesse エージェントおよびスーパーバイザユーザガイド』の「一般的なタスク」章にある「セキュリティ証明書の承認」項を参照してください。 |
Cisco IM&P 展開に関する考慮事項
Finesse は、Cisco Finesse Administration インターフェイスを介してプライマリおよびセカンダリ IM&P チャットサーバを構成します。
デスクトップチャットは、構成済みサーバの接続し、ユーザに対して構成された適切な IM&P ノードを自動的に検出し、IM&P 内の適切なノードに接続します。この解決は、ユーザがブラウザのキャッシュをクリアするまで、チャットが初めてロードされ、その後同じノードを使用するときにのみ実行されます。
Note |
デスクトップチャットは、Jabber とは異なり DNS_SRV* レコードを使用しません。また、ネットワーク構成に基づいて自動的に構成されません。チャットサーバの検出には、管理ページからの明示的なチャット URI 構成が必要です。 |
Cisco IM&P 展開の詳細については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/presence.html の『Unified CM ソリューション リファレンス ネットワーク設計ガイド』を参照してください。
次の詳細に関しては、『Cisco Unified Communications Manager 上の IM および Presence サービスの構成および管理ガイド』を参照してください。
-
IM&P サービスのインストールおよび構成方法。
-
IM&P を構成し、エンドユーザに対してチャットサービスを有効にする方法。
-
クラスタと高可用性展開の構成方法。
-
IM&P フェデレーションの構成方法。
Desktop Chat サーバの設定
デスクトップ チャットは XMPP ブラウザ ベースのチャットであり、これは Cisco Instant Messaging and Presence(IM & P)サービスによって提供されます。Unified CM プラットフォーム内にプレゼンスおよびチャット機能を提供します。詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html の「IM and Presence Service の構成と管理」を参照してください。
デスクトップチャットは、エージェントデスクトップをホストしているブラウザからポート 5280 経由で Cisco IM&P サーバに接続します。クライアントがこの機能を使用する場合は、IM&P サーバの可視性およびポートへのアクセス性を確保する必要があります。デスクトップ チャット ガジェットは、BOSH HTTP を介して IM&P サーバと通信するためにデスクトップが使用する IM&P ホスト BOSH URL を構成します。
IM& P はクラスタ化された設計であり、ユーザはクラスター内の複数のノードに分散されます。デスクトップチャットはまず、ユーザが構成した IM&P ノードを検出し、この情報をキャッシュし、ブラウザのキャッシュがクリアされるまで、後続のログインの実際のサーバと通信します。最初の検出負荷を分散するには、展開に 1 つ以上の Finesse クラスタがある場合、ラウンドロビンでノードを構成することをお勧めします。たとえば、IM&P ノードが 5 つある場合は、ノード 1 と 2 で Finesse クラスタ A を構成し、ノード 3 と 4 で Finesse クラスタ B を構成します。
IM&P URL を構成する一方で、ノードを利用できるよう考慮する必要があります。セカンダリノードは、最初のノードが到達不可能なシナリオで利用できます。セカンダリノードは、プライマリノードが到達不能な場合にのみ、検出のために接続されます。
構成する URL については、『システム、サービスパラメータ』の「Cisco Unified Presence」を参照してください。必要な IM&P サーバを選択し、Cisco XCP Web 接続マネージャーを選択します。[HTTPバインドパス(HTTP Binding Path)] フィードバックに、URL バインドパスが一覧されます。Finesse で構成する完全な URL は https://<hostname>:5280/URL-binding-path です。
Desktop Chat サーバの設定を使用して、Finesse デスクトップのチャットを構成します。次の表に、Desktop Chat サーバ設定ガジェットのフィールドを示します。
フィールド |
説明 |
---|---|
プライマリチャットサーバ |
デスクトップチャットの IM&P プライマリサーバ の URLを入力します。 |
セカンダリチャットサーバ |
デスクトップチャットの IM&P セカンダリサーバ の URLを入力します。 |
-
[保存(save)]:構成変更を保存します
-
元に戻す: 直近に保存されたサーバ設定を取得します
Important |
デスクトップチャットが問題なく動作する場合は、次のサービスが IM&P 上で実行されている事を確認してください。
|
Note |
ブラウザによって自動的に信頼されない証明書で Cisco IM and Presence が構成されている場合、Finesse デスクトップへのサインイン中にセキュリティ証明書を受け入れるプロンプトがユーザに表示されます。証明書を受け入れるプロンプトが必ず表示されるのを避けるために、ユーザは、証明書をブラウザの信頼ストアに追加するか、CA で署名された証明書を使用して IM and Presence を構成するか、サポートされているブラウザのグループポリシーを通じて自己署名証明書をプッシュする必要があります。 |
Note |
デスクトップチャットは、IM&P の無制限バージョンではサポートされません。 |
デスクトップ チャット検索
Note |
Cisco Finesse でこの機能を有効にするには、Finesse 12.0(1) ES4 COP 以降をインストールします。 |
デフォルトでは、デスクトップチャットユーザ検索には LDAP のすべてのユーザが表示されます。この検索を調整して、エージェントまたはスーパーバイザが検索を開始した対応するカスタマーのユーザを、Cisco Unified Communications Manager IM and Presence Service で定義されている組織ユニット(OU)に基づいて表示できます。これは Cisco Unified Communications Manager IM and Presence Service、リリース 12.5(1)SU2 ES ビルドバージョン 12.5.1.12900-26 以降でサポートされています。詳細については、Cisco TAC にお問い合わせください。
Cisco Unified Communications Manager IM and Presence Service では、管理者が [クライアントユーザ(Client User)] フィールドを [検索可能なLDAP属性(Searchable LDAP Attributes)] テーブルの [適切なLDAPユーザ(Appropriate LDAP User)] フィールドにマップする必要があります。
検索可能な LDAP 属性([クライアント(Client)] フィールドと [LDAP] フィールド間の属性マッピング)
設定は、選択した LDAP サーバのタイプによって異なり、LDAP サーバの各論理的なエンティティと完全に一致する必要があります(たとえば、姓、名、氏名など)。XMPP ユーザ検索を行うには、次のようにして各クライアントユーザを [LDAP] フィールド属性にマッピングします。
-
Active Directory は、[クライアントユーザ(Client User)] フィールドと [LDAPユーザ(LDAP user)] フィールドのデフォルト値を提供します。使用している構成に合わせて、必要に応じて各フィールドを編集できます。
-
汎用ディレクトリサーバは、デフォルト値を提供しません。XMPP ユーザ検索を行うには、各 [クライアントユーザ(Client User)] フィールドにマッピングする LDAP 属性を指定する必要があります。
クライアントユーザフィールド |
LDAPユーザフィールド |
---|---|
OU |
ou |
ラストネーム(姓) |
sn |
fullname |
cn |
uid |
sAMAccountName |
サードパーティの XMPP クライアントの LDAP 検索設定の詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html の『IM and Presence Service の構成及び管理』に記載されている「LDAP ディレクトリ統合」章を参照し、検索可能な LDAP 属性に関しては、『IM and Presence Service オンラインヘルプ』を参照してください。
CLI コマンドを使用して、Cisco Finesse でのデスクトップチャット OU 検索を構成します。CLI コマンドの詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html の「Cisco Finesse アドミニストレーション ガイド」に記載されている『デスクトップのプロパティ』項を参照してください。
Cisco Unified Intelligence Center の設計上の考慮事項
Unified Intelligence Center の展開
Unified Intelligence Center の展開は、次の要素で構成されています。
-
クラスタ内の 1 つ以上の Unified Intelligence Center レポート(メンバー)ノード
-
リアルタイムおよび履歴データソース
-
ライブデータソース
-
その他オプションのデータソース
Note |
Unified Intelligence Center とデータソースサーバが同じ NTP サーバと同期中であることを確認してください。 |
Unified Intelligence Center ノードは、Contact Center Enterprise ソリューションのスタンドアロン VM に展開されます。Unified Intelligence Center は、履歴レポート、リアルタイムレポート、ライブデータレポートをサポートしています。
履歴レポートまたは リアルタイムレポートのデータフローは、次のように実行されます。
-
Web クライアントは、Unified Intelligence Center の 履歴レポートまたは リアルタイムレポートに対して HTTPS 要求を行います。
-
Unified Intelligence Center レポートノード上の Web サーバが要求を受信します。
-
レポートノードは、データソースサーバからレポートデータをプルします。
-
レポートノードは、Web サーバを介してレポートを Web クライアントに送信します。
クライアントは、Live Data サービスの Live Data イベントストリームから ライブデータレポートを更新します。ライブデータ制御とデータフローの詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の Cisco Unified ICM/Contact Center Enterprise サービスアビリティ ベスト プラクティス ガイド を参照してください。
Unified Intelligence Center Reporting ノード
レポートノードは Unified Intelligence Center の中核であり、レポート用のすべての機能が備わっています。レポートノードは、以下の構成で展開できます。
-
コントローラノード上のスタンドアロン レポート ノード
-
クラスタ内に最大 7 つのレポートメンバーノードを含むコントローラノード
レポートノードには、次のアプリケーションが含まれます。
-
ファイアウォール
-
Unified Intelligence Center アプリケーションを実行する Web サーバ
-
Web リクエストを HTML に変換する JAVA サービスおよび JSP ページ
-
クラスタ内での複製をサポートする Unified Intelligence Center Database(Informix)
-
管理(OAMP)アプリケーション(発行元ノード上)
Unified Intelligence Center Database(Informix)
各レポートノードには、Unified Intelligence Center アプリケーションデータベースが含まれます。Unified Intelligence Center データベースは、Unified Intelligence Center レポート Web アプリケーションの主要データストアです。クラスタ内の各ノードのユーザ、レポート、およびユーザアクセス権関連の構成情報が保持されています。
Unified Intelligence Center クラスタでは、各データベースサーバは他のすべてのデータベース サーバに接続します。データは、任意のサーバから他のすべてのサーバにすぐに複製されます。
日次自動削除は、午前 0 時に実行され、データベースのメンテナンスアクティビティを処理します。必要に応じて、削除スケジュールを変更できます。削除とバックアップは、ローカルの Unified Intelligence Center データベースの唯一のローカル データベースメンテナンス タスクです。
Unified Intelligence Center データソース
Unified Intelligence Center は、次のデータソースをサポートしています。
-
リアルタイムレポートおよび 履歴レポート用の Microsoft SQL ベースまたは Informix データソース。SQL ベースのデータソースは、有効な JDBC 対応データベースであり、レポートデータを格納するスキーマです。
-
ライブデータレポートに対するストリーミングデータソース
これらデータソースサーバは、以下のレポートをサポートします。
-
Cisco Finesse ガジェットに表示されるレポートを含む、Contact Center Enterprise レポート。
-
インポート可能な Unified CVP レポート
-
Customer Collaboration Platform レポート
-
ビジネス チャットおよび E メール reports
Unified Intelligence Center のライブデータ
Unified CCE は、WebSockets を介してエージェント、スキルグループ、およびコールタイプステータスでリアルタイムの更新を公開します。Unified Intelligence Center レポートは、これらのメッセージをライブデータサービスから直接消費し、リアルタイムで更新を表示します。
Unified CCE では、ライブデータサービスは独自の VM 上に存在します。
ライブデータレポートは、Unified Intelligence Center レポートビューアで実行できます。Cisco Finesse デスクトップでは、ガジェットに ライブデータレポートを表示できます。Cisco Finesse デスクトップの親コンテナからライブデータサービスの 1 つまで WebSocket トンネルを使用します。ガジェットは、ロード中にトンネルを作成します。
WebSocket 接続に障害が発生すると、ライブデータレポートは、現在接続されている Live Data ノードに自動的にフェールオーバーします。
次の図は、Contact Center Enterprise 展開における ライブデータレポートのアーキテクチャを示しています。
データソースとしての Administration & Data サーバ
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 CVP からレポートをインポートする展開の場合、Unified Intelligence Center は、データソースとして CVP コールサーバを使用します。
CVP コールサーバはレポーティングサービスを提供し、IBM Informix Dynamic サーバ(IDS)データベース管理システムをホスティングします。データベースのスキーマを使用すると、データベースに対してカスタムのレポートを作成できます。ソリューションには、複数の CVP コールサーバを含めることができます。
Unified Intelligence Center は、CVP コールサーバにのみ接続します。CVP コールサーバは、他の Unified CVP サブコンポーネントと Unified Intelligence Center 間を仲介します。
WAN 展開での Unified Intelligence Center
Unified Intelligence Center クラスタは、WAN 上で分散できます。クラスタ内の各ノードには、他のすべてのノードへの接続が必要です。クラスタ内では、LAN または WAN を使用して、一方のノード上に作成された構成定オブジェクトは、他のノードに自動的に複製されます。複製では、WAN 全体の帯域幅が使用されます。ただし、構成オブジェクトを作成する頻度は低いため、レポートを実行するよりも WAN 帯域幅に影響を与える頻度が低くなります。
オブジェクトは、ローカルノード上で即座に利用可能なユーザになります。オブジェクトが他のノードに複製されるまで数秒かかる場合があります。複製用の WAN 帯域幅は、クラスタの構成によって異なります。
サイト組織
Unified Intelligence Center クラスタは、最大で 8 つのノードを保持できます。完全な冗長クラスタリングを保持するには、ノードの数は最大 4 つです。資格がある場合、各Unified Intelligence Center は、標準規格のレポートプロファイルで、最大 200人のレポートユーザをサポートします。クラスタ内では、最大 8 つのノードを持つこともできますが、レポートユーザの最大数に関するリファレンス設計上の考慮事項制限を超えることはできません。
プライマリ(コントローラ)ノードはプライマリサイトにあります。プライマリノードは、次のサービスをホストします。
-
管理アプリケーション
-
スケジューラ
WAN 障害
各 Unified Intelligence Center ノードは、複製データをバッファし、クラスタ内の他のノードに送信します。切断中、別のノードへの接続が復元されるまでノードは、データをキューに入れます。各ノードは、接続障害が発生した場合でも、個別に動作し続きます。キューは最大 1600 MB を保持します。バッファ消費の前に接続が復元された場合、ノードはキューに入っているデータの量と接続帯域幅に比例した速度で同期します。
ノードがバッファ消費に近い場合、アラームが送信されます。バッファが使い果たされる前に接続が復元されなかった場合、複製がリセットされます。復元をリセットすることで、ノードは、引き続きレポートを実行し、個別に動作します。複製をリセットするセカンダリノードでは、プライマリノードとの再接続後、プライマリノードとの完全同期(プライマリデータベースのバックアップとセカンダリノードでの復元)が必要です。複製がリセットされると、セカンダリノード上に作成または変更されたすべてのオブジェクトがプライマリデータベースの状態にロールバックされます。
プライマリノードに障害が発生した場合は、再インストールして保存済みバックアップに戻します。データ損失を回避するために、プライマリノードを定期的にバックアップします。
データ複製の詳細については、『Cisco Unified Intelligence Center 向け管理コンソールユーザガイド』を参照してください。
Unified Intelligence Center Administration
Unified Intelligence Center Administration サーバは、運用、管理、メンテナンス、プロビジョニング(OAMP)機能を提供します。Administration サーバは、Unified Intelligence Center クラスタでデバイスを構成およびプロビジョニングするためのプライマリインターフェイスです。クラスタ内のプライマリ(コントローラ)ノードで管理機能を展開しアクセスします。
Cisco Unified Intelligence Center は、アプリケーション クラスタリングに Hazelcast を使用します。Hazelcast は、Unified Intelligence Center アプリケーション層にセカンドレベルのキャッシュを提供します。Hazelcast がキャッシュしたエンティティ(例:レポート、レポート定義など)を、Unified Intelligence Center ノードで更新する際は、クラスタ内の別のすべての Unified Intelligence Center ノードで、エンティティを無効にし、再ロードする必要があります。Hazelcast クラスタは、該当する無効なエンティティなどの識別子を含むクラスタ全体の通知を発行することで、自動的に該当するクラスタをケアします。
Unified Intelligence Center では、Hazelcast クラスタの検出または情報に対するデフォルトメカニズムは、UDP マルチキャストです。Unified Intelligence Center は、マルチキャストグループの IP アドレス 224.2.2.3 および ポート 54327 を使用します。これら設定は、Unified Intelligence Center では変更できません。
次のシナリオでは、UDP マルチキャストベースの検出メカニズムはカスタマーには機能しません。
-
ネットワークでマルチキャストが無効化されている場合。
-
Unified Intelligence Center クラスタ内のノードが異なるサブネット内にある場合。
このようなシナリオでは、検出メカニズムを TCP/IP に変更できます。デフォルトの UDP マルチキャストベースの検出メカニズムではなく、TCP/IP を使用して CUIC アプリケーションクラスタを形成できます。
管理機能および Hazelcast を使用したクラスタ構成の詳細に関しては、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-intelligence-center/products-maintenance-guides-list.html の Cisco Unified Intelligence Center 管理コンソール ユーザ ガイド を参照してください。
Note |
管理アプリケーションは、ネットワーク オプション、証明書、アップグレード、SNMP およびアラート設定などのシステムレベルの機能には使用しないでください。 |
履歴レポートおよび リアルタイムレポートのスロットリング
Unified Intelligence Center のスロットリングメカニズムにより、サーバが極端な負荷の下でメモリ切れ状況で凍結したり、その状況に直面するのを防ぎます。
Note |
サイジングの目的でスロットリングメカニズムを使用しないでください。スロットリングメカニズムは、メモリ切れ状況を回避するのみ使用します。スロットリングは、高品質のサービスを保証するものではありません。導入が過剰に使用されている場合、スロットリングメカニズムがアクティブ化される前に、サービスレベルが大幅に低下する可能性があります。 ソリューションに適したレポートリソースを判断するには、常にサイジングツールを使用します。 |
レポートデータの処理は、Unified Intelligence Center で最もメモリを消費します。スロットリングメカニズムは、レポートアクティビティによるメモリ消費を制御します。
Unified Intelligence Center は、レポート行を通じてレポートアクティビティを測定します。レポートアクティビティのこの測定により、柔軟性が得されます。いくつかの大規模レポートまたはたくさんのの小規模レポートを実行できます。スロットリングメカニズムも調整なしで効果を発揮します。
Unified Intelligence Center は、レポート行を通じてレポートアクティビティを測定します。レポートアクティビティのこの測定により、柔軟性が得されます。いくつかの大規模レポートまたはたくさんのの小規模レポートを実行できます。スロットリングメカニズムも調整なしで効果を発揮します。
ストックレポートを使用したテストでは、2 KB がレポート行のサイズに対する保守的な推定値であるという結果が示されています。その推定値に基づいて、Unified Intelligence Center サーバは、サーバがメモリを使い切る前に、最大 250,000 レポート行をメモリにロードできます。
この制限を適用するために、各 Unified Intelligence Center は、現在メモリにロードされているレポート行の数を保持します。すべてのレポート操作は、その数を確認して、メモリにさらにレポート行がロードできるかを判断します。制限に達すると、レポート操作は失敗し、次のようにエラーが表示されます。
-
データソースからデータをフェッチする際の侵害 — レポート実行のキャンセルまたは失敗としてレポートをマークします。Unified Intelligence Center では、部分的な結果を取得しません。システムは、要求に関するすべてのデータを読み取るか、レポートに失敗のマークを付けるか、すべてのデータを保存しません。
-
ブラウザ の HTTPS 応答準備中の侵害 — Unified Intelligence Center はディスプレイリクエストを拒否します。サーバのリソースが低く、レポートをレンダリングできない旨が記載されたエラーメッセージが表示されます。