CVP Courtesy Callback(CCB)ゲートウェイキャパシティ検証エラーのトラブルシューティング

はじめに

このドキュメントでは、トランクゲートウェイのキャパシティが超過したために発信者がCCBオファーを取得できない場合に、Customer Voice Portal(CVP)CCBの問題をトラブルシューティングする方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• CVP
• Cisco CVP対応コールバック

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づいています。

• CVP Server 10.5
• Unified Contact Center Enterprise(UCCE)10.5

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

ゲートウェイのキャパシティの問題をトラブルシューティングする前に、CCBのトランク検証プロセスを理解することが重要です。基本的には、このプロセスはまずCallback_currentテーブルからのコール数を決定します。この数は、内部にEventTypeID(21、22、23)を持ちます。保留中、処理中、特定のゲートウェイとロケーションの仮承諾です。

2番目に、同じCallback_currentテーブルから、cause connectedで完了したコールの数(EventTypeID = 24（完了）、およびCauseID = 27（接続）)を判別します。

最後に、この2つの値を加算し、Survivability.tclサービスで設定されたトランクの数と比較します。

設定されたトランクのしきい値を超えた結果が返された場合、プロセスはエラー(return 1)を返し、それ以外の場合はok(return 0)を返します。

要約すると、CCBに使用されるトランクを検証する式は次のようになります。

CCBトランク<(Callback_currentテーブルと(21,22,23)のEventTypeID。保留中、処理中、特定のゲートウェイに仮承諾)+ EventTypeID = 24（完了）、およびCauseID = 27（接続済み）

CCBトランクの値が低い場合、検証は失敗します。

症状

着信コールはCCBオファーを取得しません。コールは、推定待機時間(EWT)に関係なく、キューに直接送信されます

トラブルシュート

ステップ 1：Voice Extensible Markup Language(VXML)サーバからCallbackEntryアプリケーションのアクティビティログを収集します。

ステップ 2：アクティビティログ内で、検証が行われていないコールを検索します。

Validate_02,data,result,none

これは、検証がパスしなかったことを意味します。このコールのGUIDを取得します。  アクティビティcallidでコールをフィルタし、次の例のようなcallidを探します。

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

ステップ 3：Reporting ServerのCVPレポートログを収集します。CVPレポートログで同じコールIDを見つけます。

ValidateHandler:ValidateHandler.exec: ValidateHandler GUID=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB results:none validation status bitmask=0x00000103  

ステップ 4：ビットマスク番号を2進数に変換します。プログラマカリキュレータを使用する：0001 00000011

ステップ 5：CCBテーブルのCVPレポートガイドのビットマスクを確認します。「EXCEED_CAPACITY_GW」が原因で検証が失敗することが確認できるはずです。

手順 6：特定のキューに問題を絞り込みます。 CVP ReportingサーバからCCBサーブレットを確認して、CCBが提供されない特定のキューがあるかどうかを判断します。Webブラウザを開き、次のように入力します。

http://{レポーティングサーバのIPアドレス}:8000/cvp/CallbackServlet?method=Diag

CCBが提供されるキューの例を次に示します。

これは、CCBが提供されないキューの例です

ステップ7：キューが特定のゲートウェイによって処理されるかどうかを確認します。ゲートウェイ設定を確認します（存続可能性アプリケーションパラメータ）。

application
 service new-call flash:bootstrap.vxml
 !
 service survivability flash:survivability.tcl
  paramspace callfeature med-inact-det enable
  param ccb id:10.201.198.21;loc:CALO;trunks:512

ステップ 8：設定が正しい場合は、Reporting Serverデータベース(Informix)に保存されている情報を確認して、この特定のゲートウェイと場所のコール数を確認します。CCB ID（この場合は10.201.198.21）または場所（この例ではCALO）で確認できます。

ステップ 9：レポーティングサーバで、Informixデータベースにアクセスします。

CMDプロンプトを開き、dbaccesと入力します。

connection > connectの順に移動します。

cvpインスタンスの選択

ユーザ名「cvp_dbadmin」を入力します。

タイプパスワード

callback@cvp databaseを選択します。

終了してクエリー言語に移動

ステップ 10：次のクエリを実行します。

場所==「CALO」；のcallback_currentからcount(*)を選択

ステップ 11この値が、そのロケーションのゲートウェイで設定されているトランク値と同じか、それより大きい場合、Callback_Currentテーブルで許可されているトランクの最大数に達しているため、検証が失敗します。

注:『CVPレポートガイド』で参照されるように、Callbackテーブルは2つのテーブル（Callback_CurrentとCallback_Historical）のビューです。2つのテーブルは同一です。30分ごとに、完了したコールのデータがCallback_PendingからCallback_Historicalに移動します。

ステップ 12 ロケーションごとのトランク値がCallback_Currentテーブル内の制限に達していて、キューにコールバックがない場合、これはコールバックレコードをCallback_CurrentテーブルからCallback_Historicalテーブルに移動する際に問題があることを示します。

ステップ 13スケジュールタスク(CVVP Reporting Server)でCVPCallbackArchiveが実行されていることを確認します。 Start -> Programs -> Accessories -> System Tools -> Scheduled Taskの順に移動します。

.

ステップ 14：このタスクCVPCallbackArchiveが完了したら、終了コード(0x0)であることを確認します。

ステップ 15：ステップ13と14で問題ないが、Callback_Historicalテーブルにまだデータがない場合は、データベースに情報が追加されない理由を確認する必要があります。現在のテーブルと履歴テーブルに格納されている情報の整合性を確認します。  informix dbaccess CMDウィンドウで次のクエリを実行します。

Select  count (*) from callback_current where surrogateid in (select surrogateid from callback_historical);

ステップ16：カウントが1以上の場合は、現在のテーブルのプライマリ・キーが履歴テーブルにすでに存在しており、その情報がデータベースに追加されていないことを意味します。これらのシナリオのほとんどでは、競合状態が原因で重複レコードがcallback_currentテーブルに入力されます。

サロゲートIDへのGUIDのマッピングはキューテーブルで行われます。呼び出しがコールバック待機からコールバックキュースクリプトに移動する状況では、アーカイブジョブによってレコードが現在のテーブルから履歴に移動され、アプリケーションによって同じサロゲートIDを持つ新しいレコードが現在のテーブルに入力されるウィンドウがあるように見えます。  この問題は、このCDETS CSCuq86400に関連するものです。

解決方法

ステップ 1：InformixデータベースにアクセスするCMDプロンプトを開き、dbaccesと入力します。

ステップ 2：connection > connectに移動し、cvp instanceを選択します。username cvp_dbadminとtype passwordを入力します。

ステップ 3：callback@cvp database exitを選択し、Query Languagesに移動します。

ステップ 4：次のコマンドを実行します。

surrogateidが含まれるcallback_currentから削除します（callback_historicalからsurrogateidを選択します）。

一時的なテーブルエラーがある場合は、次の操作を実行します。

テーブルt1をドロップします。

ステップ 5：現在のコールバックテーブルから履歴コールバックテーブルに情報を移動するspプロシージャを、クエリ言語ウィンドウdbaccessから実行します。

EXECUTEプロシージャsp_arch_callback();

手順 6：現在のテーブルに以前と同じ数のレコードが存在しないことを確認します。

場所==「CALO」；のcallback_currentからcount(*)を選択

永続的な解決策

ステップ 1：Cisco\CVP\informix_fragに移動し、テキストエディタでsp_arch_callback.sqlを開きます。

ステップ 2：ファイルの先頭の次の行のコメントを解除します。—drop procedure sp_arch_callback;（削除 – 行の先頭）。

ステップ 3：次の行を追加します。 delete from callback_current where surrogated in (select surrogateid from callback_historical) ; after

プロシージャsp_arch_callback()行を作成します。

ステップ 4：ファイルを保存します。

ステップ 5：これは、ファイルの最初の部分がどのように見えるかを示す例です。

{*********************************************************************************
Stored procedure to move completed calls out of the active table into the
historical table.
*********************************************************************************}
drop procedure sp_arch_callback;
create procedure sp_arch_callback()

DEFINE p_ageoff INTEGER;

-- delete any duplicates found in current table.

 

delete from callback_current where surrogateid in (select surrogateid from callback_historical);

 

 

最終ソリューションのテスト

ステップ1:CMDプロンプトを開き、コマンドdbschemaを実行します。 

dbschema -d callback -f sp_arch_callback

注：dbschemaコマンドの実行時に認証の問題が発生した場合は、cvp_dbadminとしてレポートサーバにログインし、もう一度やり直してください。

ステップ 2：出力から、Delete fromコマンドが実行されたことを確認します。