この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
Unified CVP VXML Server を使用してアプリケーションを実行するコール
エージェントのキューに入っているコール、またはプロンプト/コレクト タイプのセルフ サービス アプリケーションを実行するコール
エージェント、またはサードパーティの TDM VRU アプリケーションに接続されるコール
トーキング状態のコール数をカウントする場合、Unified CVP またはゲートウェイのリソースを使用しているコールのみをカウントします。 トーキング コールがリソースを使用しているかどうかを判別するには、コールがその VRU またはエージェントにどのように転送されるかを考慮する必要があります。 VoIP を使用して転送されたコールの場合は、入力ゲートウェイ ポートおよび Unified CVP のリソースを使用し続けます。これは、Unified CVP がコールを継続してモニタし、そのコールを取得して後で再配信する機能を提供するためです。 入力と出力の TDM ポートの両方を同じゲートウェイまたは異なるゲートウェイ(つまり、トール バイパス)で使用して TDM ターゲットにトロンボーニングされるコールにも、同じことが当てはまります。 この方法で VRU またはエージェントに転送されるコールは、トーキング コールとしてカウントされます。
ただし、コールが *8 TNT、フックフラッシュ、Two B Channel Transfer(TBCT)、または ICM NIC を介して転送された場合、ゲートウェイと Unified CVP のいずれもこのコールでは何の役割も果たしません。 両方のコンポーネントはそれぞれのリソースを回収したため、このようなコールはトーキング コールとしてカウントされません。
最後に、キューイングやセルフサービスのために、ブラインドまたはウォームのいずれかの転送方法を使用して Unified CVP に戻されたコールは、コールの全体カウントに含めます。 たとえば、ウォーム転送が使用され、エージェントが Unified CVP でポストルート フェーズ時にキューイングされた場合、このコールは、Unified CVP に 2 つの個別呼制御セッションがあるため、2 つのポートを使用します。 これらのコールは、通常、その量がコール ボリューム全体の 5% または 10% を超えることはないため、見落としがちです。
これらのコールの状態の定義は、ポート ライセンシングの目的で使用される定義とは若干異なります。 Automatic Speech Recognition(ASR; 音声自動認識)または Text-To-Speech(TTS; 音声合成)の使用は、どのコールがどの状態にあるかを定義するのには関係しませんが、ライセンシング目的の場合は関係します。 同様に、コール状態の判別は、エージェントが Unified CCE エージェントであるか ACD エージェントであるかには関係ありません。また、ユーザが Unified CVP を使用してコールを取得し、そのコールを別のエージェントに再配信したりセルフサービスに戻したりするかどうかも関係ありません。
(注) |
ソリューションは、トーキング状態のコールをエージェントに転送するために使用するポート数に応じてサイジングする必要があります。 Unified CCE エージェントを使用する場合はこれらのポートのライセンスは必要ありませんが、TDM エージェントにはコール ディレクタのライセンスが必要となります。 |
コンタクトセンターのコールの全体的なスナップショット プロファイルに加えて、最もビジーな期間のコール到着率を 1 秒当たりのコール数で考慮する必要もあります。 コンタクトセンター全体に関するこの情報が必要です。 正確な最大到着率を特定するのは難しいため、統計的手法を使用してこの数値を割り出すことができます。 非常に小規模な実装を除き、これがサイジング決定の重要な要因となることはほとんどありません。
上記のデータを使用して、ネットワーク内の各コンポーネントのサイジングを開始できます。 この項では、次に Unified CVP 製品(Unified CVP コール サーバと Unified CVP VXML Server)について検討した後、Unified CVP Reporting Server について検討します。 この項では、Unified CVP システムをサポートするために必要な物理コンポーネントの数およびタイプのみを取り上げ、冗長性については説明していません。 これらの数を増やして信頼性を高める方法については、ハイアベイラビリティのための Unified CVP 設計を参照してください。
(注) |
Unified CVP 9.0(1) では、コール サーバ、VXML Server、およびメディア サーバは、1 つのインストールとして統合されます。 CVP Server をインストールすると、3 つすべてのコンポーネントがインストールされます。 以前のバージョンでは、コール サーバ、VXML Server、およびメディア サーバは、異なるマシンにインストールできました。 |
(注) |
次のコール率計算は、MCS-7845-I3-CCE2 サーバに関するものです。 |
次のコンポーネントは、1 つの物理サーバにインストールできます(共存)。
SIP ベースの共存サーバでは、1200 の SIP コールと 1200 の VXML Server セッションを同時に処理でき、1 秒当たり 14 コールの平均コール到着率を処理できます。
(注) |
これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 のポートと、VXML Server の 1200 のポートを 1 台のサーバ上で実行できることを意味します。 |
必要となる Unified CVP コール サーバの数は、次のうちの大きいほうです。
((セルフ サービス) + (キューとコレクト) + トーキング) / 1200、切り上げ
または
(平均コール到着率) / 14、切り上げ、VRU のみのモデルの場合を除く
プロンプト キャッシングが VoiceXML ゲートウェイで有効になっていることを想定した場合、共存メディア サーバを使用して、最大で 1200 のコールを処理できます。 複数の共存サーバを使用する場合、コールの負荷をこれらのすべてのサーバに分散するために、共存メディア サーバ全体でロード バランシングを行う必要があります。 複数のメディア サーバでのコンテンツ管理の管理オーバーヘッドを減らすために、個別の専用メディア サーバを使用できます。
これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 ポートと、VXML Server の 1200 のポートをすべて 1 台のサーバ上で実行できることを意味します。
たとえば、現在の展開を、1200 のセルフサービス ポート、500 のキューとコレクト ポート、およびエージェントへの 3700 の同時コール用にサイジングするとします。
(注) |
上記の定義例で、セルフサービスは、コールが SIP コール制御を必要とし、VXML Server でアプリケーションを実行することを意味します。 キューとコレクトは、コールが SIP コール制御を必要とし、マイクロアプリケーションのみをコール サーバ上で使用してアプリケーションを実行することを意味します。 |
次の例は、VoiceXML セッションおよび HTTP セッションだけに適用されます。 同じ値が、コール サーバと VXML Server の共存展開と分散型展開の両方に適用されます。
SIP 呼制御を使用するサーバの必要数は、次のようになります。
((セルフ サービス) + (キューとコレクト) + トーキング) / 1200、切り上げ
(1200 + 500 + 3700) / 1200 = 5 サーバ
フロースルー コールに対して Cisco Unified Border Element をセッション ボーダー コントローラ(SBC)として使用し、VoiceXML 要件を処理する場合は、上記で示しているサイジング情報を使用する必要があります。 特定の状況およびハードウェア プラットフォームについて上記で説明されているように、Cisco Unified Border Element は、同時 VoiceXML セッションまたはコールの最大数に制限されています。
Cisco Unified Border Element を SBC として使用して、フロースルー コールのみ(VoiceXML なし)を処理している場合は、音声アクティビティ検出(VAD)を考慮し、次の URL から入手可能な『Cisco Unified Border Element Ordering Guide』のサイジング情報を参照してください。
Unified CVP Reporting Server と Unified CVP コール サーバの共存
Unified CVP Reporting Server は Unified CVP コール サーバと共存することもできますが、スタンドアロン VoiceXML 展開の場合に限ります。 スタンドアロン VoiceXML 展開では通常、コール サーバは必要ありませんが、レポートが必要な場合は、レポーティング データを VXML Server から Reporting Server に送信するために、コール サーバが必要となります。 したがって、Reporting Server がコール サーバと共存している場合、コール サーバは SIP コールを一切処理せず、単に VXML Server からのレポーティング データを中継します。
共存コール サーバによるこのモデルへのパフォーマンスの影響は大きくないため、Unified CVP Reporting Serverのこの項のサイジング情報に変更はありません。
(注) |
Unified Border Element を SBC として使用し、VAD を考慮してフロースルー コールまたはフローアラウンド コールのみ(VXML なし)を処理する場合、サイジングのために『Unified Border Element Ordering Guide』を使用できます。 |
(注) |
フロースルー コールまたはフローアラウンド コールに対して Unified Border Element を SBC として使用し、かつ、Unified Border Element で VXML 要件を処理する必要がある場合は、CVP SRND のサイジング情報を使用する必要があります。 特定の状況およびハードウェア プラットフォームについて説明されているように、Unified Border Element は、同時 VXML セッション/コールの最大数に制限されています。 |
Cisco Unified CVP Release 7.0 で、Cisco Unified Contact Center Enterprise(Unified CCE)のビデオ対応エージェント用の機能が追加されました。
同じ Unified CVP コール サーバを使用して、ビデオ コールと従来の音声コールの両方にサービスを提供できます。ただし、Unified CVP 包括コール フローを使用して音声コールが処理されている場合に限ります。 包括モデル以外のモデルが音声コールに使用されている場合は、ビデオ コールと音声コールに別々のコール サーバを使用する必要があります。
Unified CVP Basic Video Service では、Unified CVP 包括コール フローを使用します。したがって、Unified CVP コール サーバ、Unified CVP VoiceXML Server、および VXML ゲートウェイが必要です。 これらのコンポーネント用に Basic Video Service をサイジングするには、従来の音声アプリケーションの場合と同じ方法を使用します。
Cisco Unified Videoconferencing ハードウェア、Radvision IVP、および Radvision iContact は、Basic Video Service には必要ありません。
Unified CVP Reporting Server のサイジングの際には、多数の変数を考慮に入れる必要があります。 さまざまな VoiceXML アプリケーションはそれぞれ異なる特性を持ち、こうした特性が、生成されるレポーティング データの量に大きく関係します。 こうした特性の一部を次に示します。
Reporting Server をサイジングするには、最初に VoiceXML アプリケーションで生成されるレポーティング データ量を見積もる必要があります。 この章の以降の項で例として挙げているアプリケーションおよび表は、ご使用のアプリケーションで生成されるレポーティング メッセージの数を特定するのに役立ちます。
ご使用のアプリケーションで生成されるレポーティング メッセージの数を特定した後は、各 VoiceXML アプリケーションに対して次の手順を実行します。
次の式を使用して、各 VoiceXML アプリケーションで 1 秒当たりに生成されるレポーティング メッセージの数を特定します。
A# = %CPS * CPS * MSG
説明:
A# は、アプリケーションで生成される 1 秒当たりのレポーティング メッセージの推定数です。 アプリケーション(A1、A2、...、An)ごとに 1 つの計算を実行します。
CPS は、1 秒当たりのコール数です。
%CPS は、VoiceXML アプリケーションを使用するコールの割合です。
MSG は、このアプリケーションが生成するレポーティング メッセージの数です。 アプリケーションで生成されるレポーティング メッセージの数を特定するには、レポーティング メッセージの詳細およびアプリケーション例の項で示している情報を使用します。
次に、各アプリケーションに関して前の計算で得られた値を合計することで、現在の展開で生成されるレポーティング メッセージの合計数を見積もります。
A(合計) = A1+ A2+.....+An
これは、VoiceXML アプリケーションで 1 秒当たりに生成されるレポーティング メッセージの合計数です。 Cisco MCS-7845 Reporting Server は、1 秒当たり 420 のメッセージを処理できます。 現在の展開における 1 秒当たりのレポーティング メッセージの合計数が 420 よりも少ない場合、1 つの Reporting Server を使用できます。 これよりも多い場合は、複数の Reporting Server を使用し、特定の Reporting Server を使用するように複数の VoiceXML アプリケーションを分ける必要があります。
(上記のステップ 1 および 2 で決定した)1 秒当たりのメッセージ数が Unified CVP Reporting Server(Reporting Server)のキャパシティを超える場合は、展開を縦割りで分ける必要があります。
レポーティング データのロード バランシングのために縦割りで分けた場合、Unified CVP システム設計者は、複数の Reporting Server の展開に適用される次の要件を考慮する必要があります。
これらの要件の詳細については、次の URL から入手可能な『Reporting Guide for Cisco Unified Customer Voice Portal』を参照してください。
複数の Reporting Server を使用する Unified CVP 展開を設計する場合は、次のガイドラインに従います。
複数のデータベースからのデータを結合する必要がある場合、使用できる可能性があるオプションは次のとおりです。
次の表に、さまざまな要素またはアクティビティ、およびそれぞれによって生成されるレポーティング メッセージの数について説明します。
(注) |
これらの要素は、すべてのアプリケーションで必須であり、フィルタリングすることはできません。 |
この項では、ご使用の特定のアプリケーションで生成されるレポーティング メッセージの数を見積もるために使用できる適用例をいくつか示します。
合計: コールごとに 107 のレポーティング メッセージ。