Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)Cisco Unified Customer Voice Portal(CVP)Release 8.5(x)
サイジング
サイジング
発行日;2012/03/14 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

サイジング

この章の新規情報

サイジングの概要

Unified CVP コール サーバ

エージェント グリーティングに対するコール サーバのサイジング

コール サーバのログ ディレクトリ サイズの見積もり

Unified CVP VXML Server(VXML Server)

エージェント グリーティングに対する VXML ゲートウェイのサイジング

VXML ゲートウェイ エージェント グリーティング プロンプト キャッシュのサイジング

エージェント グリーティングに対するメディア サーバのサイジング

Unified CVP Co-Residency

Unified Presence Server

Unified CVP Video Service

Unified CVP Basic Video Service のサイジング

Unified CVP Reporting Server

複数の Unified CVP Reporting Server の使用方法

レポーティング メッセージの詳細

アプリケーション例

サイジング

この章では、注文する物理マシンの数の決定方法、およびゲートウェイとゲートキーパーの場合は注文するタイプの決定方法について説明します。

この章では、次のトピックについて取り上げます。

「サイジングの概要」

「Unified CVP コール サーバ」

「Unified CVP VXML Server(VXML Server)」

「エージェント グリーティングに対するメディア サーバのサイジング」

「Unified CVP Co-Residency」

「Unified Presence Server」

「Unified CVP Video Service」

「Unified CVP Reporting Server」

この章の新規情報

表 14-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 14-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

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

エージェント グリーティングのサイジング

「エージェント グリーティングに対するコール サーバのサイジング」

「エージェント グリーティングに対する VXML ゲートウェイのサイジング」

「VXML ゲートウェイ エージェント グリーティング プロンプト キャッシュのサイジング」

「エージェント グリーティングに対するメディア サーバのサイジング」

共存展開のサイジング

「Unified CVP Co-Residency」

Unified CVP VXML Server のサイジング

「Unified CVP VXML Server(VXML Server)」

必要なコール サーバ ログ ディレクトリ領域

「コール サーバのログ ディレクトリ サイズの見積もり」

サイジングの概要

コンタクトセンターをサイジングする場合、最初に、各状態におけるコール数の観点から最悪の場合のコンタクトセンター プロファイルを決定します。つまり、最も煩雑する時間に、最も煩雑するインスタンスでコンタクトセンターを監視しなければならない場合に、次のぞれぞれの状態でのコール数を確認します。

セルフ サービス: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 Presence Server と Unified CVP Reporting Server について検討します。この項では、Unified CVP システムをサポートするために必要な物理コンポーネントの数およびタイプのみを取り上げ、冗長性については説明していません。これらの数を増やして信頼性を高める方法については、「ハイアベイラビリティのための Unified CVP の設計」を参照してください。

Unified CVP コール サーバ


) Unified CVP コール サーバ(コール サーバ)は、モデル #1 のスタンドアロン セルフサービスでは使用されません。この項は、こうした展開には適用されません。


Unified CVP コール サーバは、最大コール到着率に加えて Unified CVP コール サーバが処理できるコール数に応じてサイジングされます。

表 14-2 サーバ モデル番号別のコール サーバのコール率

サーバ モデル
MCS-7845-I3-CCE2
USC-C210-M1 以降

最大 SIP コール

1200

 
表の脚注 1 を参照

最大 H.323 コール

500

-- -- --

1 秒当たりの平均コール(SIP)

14

-- -- --

1 秒当たりの平均コール(H.323)

7

-- -- --

1 UCS パフォーマンスの数値については、次の Cisco DocWiki を参照してください。

http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP


) 次のコール サーバのコール率計算の例は、MCS-7845-I3-CCE2 サーバに関するものです。


各コール サーバは、1200 の SIP コールまたは 500 の H.323 コールを処理できます。各コール サーバには、さらに平均コール到着率(SIP の場合は 14 コール数/秒(cps)、H.323 の場合は 7 cps)という制限があります。ただし、モデル #4 は、H.323 または SIP 処理を行わないためこの制限から除外されます。

具体的には、必要となるコール サーバの数は、次のうちの大きいほうです。

(セルフサービス + キューとコレクト + トーキング) / 1200(H.323 の場合は 500)、切り上げ

または

平均コール到着率 / 14、切り上げ(H.323 の場合は 7。ただし、モデル #4 は除く)

コール サーバが SIP コールと H.323 コールの両方を処理している場合、各コール タイプに使用されるパフォーマンスを比例配分することで、サーバをサイジングできます。たとえば、コールの 60% が H.323 で、40% が SIP の場合のアクティブ コールに関する最大負荷は次のようになります。

60% * H.323 コール 500 件 + 40% * SIP コール 1200 件 = 780 アクティブ コール

また、Cisco Unified Communications Manager クラスタに配信されるコールについて、そのクラスタ内のサブスクライバ間でロード バランシングが行われる必要があり、各サブスクライバで 2 コール数/秒(cps)を超えないようにする必要があります。

エージェント グリーティングに対するコール サーバのサイジング

エージェント グリーティング機能を使用する場合は、Unified CVP コール サーバのパフォーマンスが、25 % 減少します(サーバは、エージェント グリーティング機能を使用しないシステムの 1 秒当たりのコール数(CPS)の75 % で動作します)。

このマニュアルで説明されている方法を使用してシステムのサイジングをします。その後、CPS に 75 % を掛けます。

たとえば、エージェント グリーティングを使用しない UCS プラットフォームでの 10 CPS は、エージェント グリーティングが有効になっているコール サーバでの 7.5 CPS に変換されます。

必要なポートは、CPS およびエージェント グリーティングの時間に基づいて計算されます。また、サーバのサポートされるポートの総数から考慮する必要があります。


) エージェント グリーティング機能は SIP だけでサポートされます。H.323 はサポートされません。


コール サーバのログ ディレクトリ サイズの見積もり

次の式を使用して、コール サーバのディレクトリ ログ ファイルの 1 日当たりの概算領域(ギガバイト単位)を計算します。

3.5 * R

ここで、R は 1 秒当たりのコール数です。

適切なサービスアビリティのために、5 ~ 7 日分のログ メッセージを保持するのに十分な領域を確保します。

ログ ディレクトリのサイズを設定するには、Operations Console でコール サーバ設定の [Infrastructure] タブを参照してください。

Unified CVP VXML Server(VXML Server)

下の表および例で、VXML Server のコール率計算について説明します。


) 次の VXML Server のコール率計算の例は、MCS-7845-I3-CCE2 サーバに関するものです。


HTTP の場合の Unified CVP VXML Server のサイジングは単純です。1 つの Unified CVP VXML Server は最大 1200 のコールを処理できます。複数の Unified CVP VXML Server を使用している場合は、次の式に従ってこれらのマシンをサイジングする必要があります。

コール / 1200、切り上げ

ここで、 コール は、ビジーな瞬間のスナップショットでそのときに Unified CVP VXML Server セルフサービス アプリケーションに実際に存在するコール数を示します。

表 14-3 サーバ モデル番号別の VXML Server コール率

Unified CVP VXML Server

モデル:
MCS-7845-I3-CCE2
モデル:
USC-C210-M1 以降

最大同時コール

1200

 
表の脚注 1 を参照

1 UCS パフォーマンスの数値については、次の Cisco DocWiki を参照してください。

http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP

Unified CVP は、Unified VXML Server および Unified CVP IVR サービスで HTTPS を使用するように設定することもできます(IVR サービスは、非常に基本的な VoiceXML ドキュメントを生成でき、Unified CVP コール サーバの一部です)。HTTPS の処理オーバーヘッドが大きいため、Tomcat アプリケーション サーバは、コンフィギュレーションによっては、最大でも 100 の同時接続しか確立できません。

表 14-4 に、さまざまなアプリケーションおよびコール フロー モデルを使用する HTTPS コールに関する同時コール情報を示します。

表 14-4 Unified CVP Server の HTTPS 同時コール

Unified CVP コール サーバ タイプ、アプリケーション、およびコール フロー モデル
モデル:
MCS-7845-I3-CCE2
モデル:
USC-C210-M1 以降

Unified CVP VXML Server
WebSphere での最大同時 HTTPS 接続(スタンドアロン コール フロー モデル)

250

-- -- --

Unified CVP VXML Server
Tomcat での最大同時 HTTPS 接続
(スタンドアロン コール フロー モデル)

100

-- -- --

Unified CVP コール サーバと VXML Server
WebSphere での最大同時 HTTPS 接続(包括コール フロー モデル)

100

-- -- --

Unified CVP コール サーバと VXML Server
Tomcat での最大同時 HTTPS 接続(包括コール フロー モデル)

100

-- -- --

上記すべてのシナリオで、[Reporting] オプションと [Datafeed] オプションは無効になっています。

シスコでは、Cisco IOS VoiceXML ゲートウェイでの HTTPS オプションの次のコンフィギュレーションを推奨します。この設定を使用しないと、VXML ゲートウェイと包括的なソリューション(通常、HTTPS とともに使用)のパフォーマンスおよびサイジングに重大な影響を与える可能性があります。

http client connection persistence
http client cache memory pool 15000
http client cache memory file 1000

エージェント グリーティングに対する VXML ゲートウェイのサイジング

追加のゲートウェイである VXML の必要なポートは、CPS およびエージェント グリーティングの時間に基づいて計算されます。エージェント グリーティングは、VXML ゲートウェイへの 1 つの追加コールとしてカウントされます。

次の式を使用して、エージェント グリーティング機能に必要な追加ポートを決定します。

Total ports = Inbound ports + [ ( Agent Greeting Duration / Total call duration ) * Inbound ports ]

たとえば、それぞれ 60 秒のコール時間で 120 コールを見積もる場合、2 CPS および 120 の着信ポートの要件が与えられます。すべてのコールでエージェント グリーティングの時間が 5 秒であると仮定する場合、1 秒あたりのコール総数は 4 CPS ですが、必要なポート数は 130 です。

ポート総数 = 120 着信ポート + [(エージェント グリーティング時間 5 秒 / コール時間合計 60 秒) * 120 着信ポート] = 130 ポート総数。

VXML ゲートウェイ エージェント グリーティング プロンプト キャッシュのサイジング

エージェント グリーティング プロンプト キャッシュをサイジングする場合は、次の例を考慮します。

次の計算は、g711uLaw コーデックの 1 分間のファイルが約 1/2 MB を使用することを示しています。

64 Kbits/sec = 8 Kbytes/sec (bit rate for g711uLaw codec)
8 Kb/sec * 60 seconds - 480 Kb (~ 0.5 MB)

IOS ルータのプロンプト キャッシュに使用される最大メモリは 100 MB で、1 つのファイルの推奨される最大サイズは、600 KB を超えないようにする必要があります。

上記のサイジング数を使用してキャッシュされたエージェント グリーティングの数を次に示します。

5 秒のグリーティング:40 KB つまり 1 MB あたり約 25 件のグリーティング。この一般的な使用例のシナリオは、約 80 * 25 エージェント = 80 % のスペースがエージェント グリーティングに予約されている状態で 2000 エージェントです。

60 秒のグリーティング:480 KB つまり 1 MB あたり約 2 件のグリーティング。最悪の場合のシナリオは、約 50 * 2 エージェント = 50 % のスペースがエージェント グリーティングに使用されている状態で 100 エージェントのキャッシングを提供します。

エージェント グリーティングに対するメディア サーバのサイジング

メディア サーバのサイジングは、メディア サーバの非常に特殊な導入要件に基づく要件がさまざまであるために、また、メディア サーバには広範囲のハードウェアが使用されるので、一般的には提供されません。ただし、次のサイジング プロファイルは、エージェント グリーティング機能を使用するメディア サーバ用です。

負荷の例:

700 エージェント

15 秒のグリーティング(118 Kb のグリーティング ファイル)

30 分のコンテンツの期限

次のものと同等(またはそれ以上)のメディア サーバのハードウェアが、上記のプロファイルの処理に必要です。

RAID 0 を使用した MCS-7825-H1(メディア サーバのみ)

RAID 1 を使用した MCS-7825-I4(メディア サーバのみ)

RAID 1 を使用した MCS-7845-H2(メディアおよびコール サーバの共存)

Unified CVP Co-Residency


) 次のコール率計算は、MCS-7845-I3-CCE2 サーバに関するものです。


次のコンポーネントは、1 つの物理サーバにインストールできます(共存)。

Unified CVP コール サーバ(コール サーバ)

Unified CVP VXML Server(VXML Server)

メディア サーバ

SIP ベースの共存サーバでは、1200 の SIP コールと 1200 の VXML Server セッションを同時に処理でき、1 秒当たり 14 コールの平均コール到着率を処理できます。


) これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 のポートと、VXML Server の 1200 のポートを 1 台のサーバ上で実行できることを意味します。


H.323 共存サーバでは、500 の H.323 コールと 500 の VXML Server セッションを同時に処理でき、1 秒当たり 6 コールの平均コール到着率を処理できます。


) これは、500 ポート ライセンスで、H.323 呼制御を行うコール サーバの 500 のポートと、VXML Server の 500 のポートを 1 台のサーバ上で実行できることを意味します。


必要となる Unified CVP コール サーバの数は、次のうちの大きいほうです。

(セルフサービス + キューとコレクト + トーキング) / 1200(H.323 の場合は 500)、切り上げ

または

平均コール到着率 / 14(H.323 の場合は 6)、切り上げ、VRU のみのモデルの場合を除く

プロンプト キャッシングが VoiceXML ゲートウェイで有効になっていることを想定した場合、共存メディア サーバを使用して、最大で 1200 のコール(H.323 の場合は 500)を処理できます。複数の共存サーバを使用する場合、コールの負荷をこれらのすべてのサーバに分散するために、共存メディア サーバ全体でロード バランシングを行う必要があります。複数のメディア サーバでのコンテンツ管理の管理オーバーヘッドを減らすために、個別の専用メディア サーバを使用できます。

これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 ポートと、VXML Server の 1200 のポートをすべて 1 台のサーバ上で実行できることを意味します。H.323 共存サーバでは、500 の H.323 コールと 500 の VXML Server セッションを同時に処理でき、1 秒当たり 6 コールの平均コール到着率を処理できます。これは、500 ポート ライセンスで、H.323 呼制御を行うコール サーバの 500 ポートと、VXML Server の 500 のポートをすべて 1 台のサーバ上で実行できることを意味します。

たとえば、現在の展開を、1200 のセルフサービス ポート、500 のキューとコレクト ポート、およびエージェントへの 3700 の同時コール用にサイジングするとします。


) 上記の定義例で、セルフサービスは、コールが SIP または H.323 呼制御を必要とし、VXML Server でアプリケーションを実行することを意味します。キューとコレクトは、コールが SIP または H.323 呼制御を必要とし、マイクロアプリケーションのみをコール サーバ上で使用してアプリケーションを実行することを意味します。


次の例は、VXML セッションおよび HTTP セッションだけに適用されます。同じ値が、コール サーバと VXML Server の共存展開と分散型展開の両方に適用されます。

SIP 呼制御を使用するサーバの必要数は、次のようになります。

(セルフサービス + キューとコレクト + トーキング) / 1200(H.323 の場合は 500)、切り上げ

(1200 + 500 + 3700) / 1200 = 5 サーバ

フロースルー コールに対して Cisco Unified Border Element を Session Border Controller(SBC; セッション ボーダー コントローラ)として使用し、VXML 要件を処理する場合は、上記で示しているサイジング情報を使用する必要があります。特定の状況およびハードウェア プラットフォームについて上記で説明されているように、Cisco Unified Border Element は、同時 VXML セッションまたはコールの最大数に制限されています。

Cisco Unified Border Element を SBC として使用して、フロースルー コールのみ(VXML なし)を処理している場合は、Voice Activity Detection(VAD; 音声アクティビティ検出)を考慮し、次の URL から入手可能な『 Cisco Unified Border Element Ordering Guide 』のサイジング情報を参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/order_guide_c07_462222.html

Unified CVP Reporting Server と Unified CVP コール サーバの共存

Unified CVP Reporting Server は Unified CVP コール サーバと共存することもできますが、スタンドアロン VoiceXML 展開の場合に限ります。スタンドアロン VoiceXML 展開では通常、コール サーバは必要ありませんが、レポートが必要な場合は、レポーティング データを VXML Server から Reporting Server に送信するために、コール サーバが必要となります。したがって、Reporting Server がコール サーバと共存している場合、コール サーバは SIP または H.323 コールをいっさい処理せず、単に VXML Server からのレポーティング データを中継します。

共存コール サーバによるこのモデルへのパフォーマンスの影響は大きくないため、「Unified CVP Reporting Server」のこの項のサイジング情報に変更はありません。


) CUBE を SBC として使用し、VAD を考慮してフロースルー コールまたはフローアラウンド コールのみ(VXML なし)を処理する場合、サイジングのために CUBE 発注ガイドを使用できます。

フロースルー コールまたはフローアラウンド コールに対して CUBE を SBC として使用し、かつ、CUBE で VXML 要件を処理する必要がある場合は、CVP SRND のサイジング情報を使用する必要があります。特定の状況およびハードウェア プラットフォームについて説明されているように、CUBE は、同時 VXML セッション/コールの最大数に制限されています。


Unified Presence Server

Cisco Unified Presence Server は、シスコが Unified CVP で使用するために提供している SIP プロキシ サーバです。 表 14-5 に、さまざまなサーバ タイプのパフォーマンスを示します。

表 14-5 Cisco Unified Presence Server のコール処理性能

Cisco サーバ モデル
録音機能
UDP
TCP

MCS-7825

[Record-Route] オン

200 cps

100 cps

[Record-Route] オフ

300 cps

300 cps

MCS-7835

[Record-Route] オン

200 cps

100 cps

[Record-Route] オフ

300 cps

300 cps

MCS-7845

[Record-Route] オン

600 cps

200 cps

[Record-Route] オフ

1100 cps

500 cps

表 14-5 に示すサイジング数は、専用 SIP プロキシの場合を想定しています。プレゼンス サービスにも同じ Cisco Unified Presence Server を使用している場合、使用されるキャパシティに応じて数を調整する必要があります。たとえば、Cisco Unified Presence Server が 2500 のプレゼンス ユーザをサポートするが、実際に存在するのは 1250(50%)のみである場合、SIP プロキシのキャパシティは約 50% が使用されないままです。

表 14-5 に示すキャパシティは、1 秒当たりのコール数(cps)で測定されています。ただし、PSTN からの 1 つの着信コールは、Cisco Unified Presence を介した 1 つのコールと同等ではありません。実際には、キューイング、呼び出し音、および以降のエージェントへの転送のために、着信顧客コールごとに複数のコールが生成されます。典型的な着信コールは、Unified CVP によって 4 回転送されるため、着信 PSTN コール率は 4 倍する必要があります。

例:

Unified CVP が 1 秒当たり 20 の PSTN コールを受信する場合、Cisco Unified Presence は 1 秒当たり約 80 のコールを確認します。

CUSP の公開データ シート 「Performance Measured in the Number of New Call Attempts per Second」の表 2 には、CUSP サーバに関する追加のパフォーマンス データが示されています。

Unified CVP Video Service

Cisco Unified CVP Release 7.0 で、Cisco Unified Contact Center Enterprise(Unified CCE)のビデオ対応エージェント用の機能が追加されました。

同じ Unified CVP コール サーバを使用して、ビデオ コールと従来の音声コールの両方にサービスを提供できます。ただし、Unified CVP 包括コール フローを使用して音声コールが処理されている場合に限ります。包括モデル以外のモデルが音声コールに使用されている場合は、ビデオ コールと音声コールに別々のコール サーバを使用する必要があります。

Unified CVP Basic Video Service のサイジング

Unified CVP Basic Video Service では、Unified CVP 包括コール フローを使用します。したがって、Unified CVP コール サーバ、Unified CVP VXML Server、および VXML ゲートウェイが必要です。これらのコンポーネント用に Basic Video Service をサイジングするには、従来の音声アプリケーションの場合と同じ方法を使用します。

Cisco Unified Videoconferencing ハードウェア、Radvision IVP、および Radvision iContact は、Basic Video Service には必要ありません。

Unified CVP Reporting Server

Unified CVP Reporting Server のサイジングの際には、多数の変数を考慮に入れる必要があります。さまざまな VoiceXML アプリケーションはそれぞれ異なる特性を持ち、こうした特性が、生成されるレポーティング データの量に大きく関係します。こうした特性の一部を次に示します。

アプリケーションで使用される要素のタイプ

必要なデータの精度

アプリケーション内でユーザが使用するコール フロー

コールの長さ

コールの数

Reporting Server をサイジングするには、最初に VoiceXML アプリケーションで生成されるレポーティング データ量を見積もる必要があります。この章の以降の項で例として挙げているアプリケーションおよび表は、ご使用のアプリケーションで生成されるレポーティング メッセージの数を特定するのに役立ちます。

ご使用のアプリケーションで生成されるレポーティング メッセージの数を特定した後は、 各 VoiceXML アプリケーション に対して次の手順を実行します。

1. アプリケーションによる VoiceXML コール処理をお客様が受信するのに何分かかるかを見積もります。

2. アプリケーションが受信する 1 秒当たりのコールを見積もります。

3. アプリケーションで生成されるレポーティング メッセージの数を見積もります。

次の式を使用して、各 VoiceXML アプリケーションでコールごとに 1 秒当たり生成されるレポーティング メッセージの数を特定します。

A# = %CPS ∗ CPS ∗ MSG / Min / 60

定義:

A# は、アプリケーションで生成される 1 秒当たりのレポーティング メッセージの推定数です。アプリケーション(A1、A2、...、A n )ごとに 1 つの計算を実行します。

CPS は、1 秒当たりのコール数です。

%CPS は、VoiceXML アプリケーションを使用するコールの割合です。

MSG は、このアプリケーションが生成するレポーティング メッセージの数です。アプリケーションで生成されるレポーティング メッセージの数を特定するには、「レポーティング メッセージの詳細」および「アプリケーション例」の項で示している情報を使用します。

Min は、アプリケーションで消費される時間(分単位)です。

60 は、1 分の秒数です。

次に、各アプリケーションに関して前の計算で得られた値を合計することで、現在の展開で生成されるレポーティング メッセージの合計数を見積もります。

A(合計)= A1 + A2 + ..... + A n

これは、VoiceXML アプリケーションで 1 秒当たりに生成されるレポーティング メッセージの合計数です。Cisco MCS-7845 Reporting Server は、1 秒当たり 420 のメッセージを処理できます。現在の展開における 1 秒当たりのレポーティング メッセージの合計数が 420 よりも少ない場合、1 つの Reporting Server を使用できます。これよりも多い場合は、複数の Reporting Server を使用し、特定の Reporting Server を使用するように複数の VoiceXML アプリケーションを分ける必要があります。

複数の Unified CVP Reporting Server の使用方法

(上記のステップ 1 および 2 で決定した)1 秒当たりのメッセージ数が Unified CVP Reporting Server(Reporting Server)のキャパシティを超える場合は、展開を縦割りで分ける必要があります。

レポーティング データのロード バランシングのために縦割りで分けた場合、Unified CVP システム設計者は、複数の Reporting Server の展開に適用される次の要件を考慮する必要があります。

各 Unified CVP コール サーバおよび各 Unified CVP VXML Server は、1 つの Unified CVP Reporting Server とのみ関連付けることができる。

複数の Informix データベースにまたがったレポートを作成することはできない。

これらの要件の詳細については、次の URL から入手可能な『 Reporting Guide for Cisco Unified Customer Voice Portal 』を参照してください。

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

複数の Reporting Server を使用する Unified CVP 展開を設計する場合は、次のガイドラインに従います。

コール処理メッセージとアプリケーション メッセージを合計した場合に、1 つの Reporting Server がサポートするよりも多くのメッセージを生成する複数のアプリケーションを分けます。

VoiceXML はフィルタリングできます。不要なデータをフィルタで除外すると、より多くのメッセージ量をサポートする使い勝手の良いデータ リポジトリが作成されます。

着信コールを適切なコール サーバおよび VXML Server に転送するように、ダイヤル プランやその他の使用可能な方法を設定します。

複数のデータベースからのデータを結合する必要がある場合、使用できる可能性があるオプションは次のとおりです。

レポーティング データを Excel、Comma Separated Value(CSV; カンマ区切り値)ファイル、またはデータベースの外部でデータを結合できるその他の形式にエクスポートする。

レポーティング データを CSV ファイルにエクスポートし、それをユーザ指定のデータベースにインポートする。

ユーザ指定のデータ ウェアハウスにデータを抽出し、そのデータに対するレポートを実行する。

レポーティング メッセージの詳細

表 14-6 に、さまざまな要素またはアクティビティ、およびそれぞれで生成されるレポーティング メッセージの数を示します。

表 14-6 要素またはアクティビティごとのレポーティング メッセージ数

要素またはアクティビティ
レポーティング メッセージの数(フィルタリングなし)

Start1

2

End1

2

Subdialog_start1

2

Subdialog_return1

2

Hotlink

2

HotEvent

2

Transfer w/o Audio

2

Currency w/o Audio

2

Flag

2

Action

2

Decision

2

Application Transfer

2

VXML Error

2

CallICMInfo(コールごと)

2

Session Variable(変更ごと)

2

Custom Log(アイテムごと)

2

Play(音声ファイルまたは TTS)

2

Get Input(DTMF)

5

Get Input(ASR)

9

Form

10

Digit_with_confirm

20

Currency_with_confirm

20

ReqICMLabel

30

1.これらの要素は、すべてのアプリケーションで必須であり、フィルタリングすることはできません。

アプリケーション例

この項では、ご使用の特定のアプリケーションで生成されるレポーティング メッセージの数を見積もるために使用できる適用例をいくつか示します。

低複雑度

合計:コールごとに 1 分当たり 16 のレポーティング メッセージ。

要素タイプ
レポーティング メッセージの概数

Start

2

Subdialog_start

2

Play element

2

Play element

2

Play element

2

Play element

2

Subdialog_end

2

End

2

中複雑度(DTMF のみ)

合計:コールごとに 1 分当たり 39 のレポーティング メッセージ。

要素タイプ
レポーティング メッセージの概数

Start

2

Subdialog_strart

2

Play element

2

Get input

5

Play element

2

Get input

5

Form

10

Input

5

Transfer with audio

2

Subdialog_end

2

End

2

中複雑度(Automatic Speech Recognition(ASR; 音声自動認識)を使用)

合計:コールごとに 1 分当たり 51 のレポーティング メッセージ。

要素タイプ
レポーティング メッセージの概数

Start

2

Subdialog_strart

2

Play element

2

Get input

9

Play element

2

Get input

9

Form

10

Input

9

Transfer with audio

2

Subdialog_end

2

End

2

高複雑度(Automatic Speech Recognition(ASR; 音声自動認識)を使用)

合計:コールごとに 1 分当たり 107 のレポーティング メッセージ。

要素タイプ
レポーティング メッセージの概数

Start

2

Subdialog_strart

2

Icmrequrestlabel

30

Form

10

ASR capture

9

Digit with confirm

20

Form

10

Digit with confirm

20

Subdialog_end

2

End

2