目錄

簡介

必要條件

需求

採用元件

背景資訊

症狀

疑難排解

解決方案

永久解決方案

測試最終解決方案

簡介

本文描述當呼叫者由於中繼網關容量超出而無法獲得CCB服務時，如何解決客戶語音門戶(CVP)CCB問題。

必要條件

需求

思科建議您瞭解以下主題：

- CVP

- Cisco CVP禮貌回撥

採用元件

本檔案中的資訊是根據以下軟體版本：

- CVP伺服器10.5

- 整合客服中心企業版(UCCE)10.5

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

背景資訊

在排除網關容量問題之前，瞭解CCB中的中繼驗證過程非常重要。基本上，進程首先確定來自EventTypeID在(21、22、23)中的Callback_current表的呼叫數；   待定、正在進行、暫定，用於特定網關和位置。

第二，從同一個Callback_current表中確定已完成的呼叫數，同時連線原因：   EventTypeID = 24（已完成），CauseID = 27（已連線）。

最後，該過程將這兩個值相加，並與Survivability.tcl服務下配置的中繼數量進行比較。

如果結果超出配置的中繼閾值，進程將發回故障（返回1），否則發回ok（返回0）。

總之，用於驗證CCB的中繼的公式為：

CCB中繼<(Callback_current表，EventTypeID位於(21,22,23)中；Pending、Inprogress、Trigal for specific gateways)+ EventTypeID = 24的Callback_current表（已完成）和CauseID = 27（已連線）

如果CCB中繼值較低，則驗證失敗。

症狀

入站呼叫不會獲得CCB優惠。無論估計等待時間(EWT)如何，呼叫都會直接進入隊列

疑難排解

步驟1.從語音可擴展標籤語言(VXML)伺服器收集CallbackEntry應用程式的活動日誌。

步驟2.在活動日誌中搜尋驗證為無的任何呼叫：

Validate_02,data,result,none

這意味著驗證未通過。獲取此呼叫的GUID。  按活動小數位過濾呼叫，然後查詢類似以下示例的小數位：

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

步驟3.收集報告伺服器的CVP報告日誌。在CVP報告日誌中查詢相同名稱。

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

步驟4.將位掩碼號轉換為二進位制。使用程式設計師計算器：0001 00000011

步驟5.檢查CCB表的CVP報告指南位掩碼。您應該看到由於「EXCEED_CAPACITY_GW」驗證失敗。

00000000 0000001 OK

00000000 0000010 ICM_NO_SCHEDULED_ALLOWED

00000000 00000100 ICM_NO_PREEMPTIVE_ALLOWED

00000000 00001000 NOT_IN_QUEUE

00000000 00010000 TOD

00000000 00100000 EWT

00000000 01000000 PROBE_FAILED_NO_RESPONSE

00000000 10000000 PROBE_FAILED_NO_CONFIG

00000001 00000000 EXCEED_CAPACITY_GW

00000010 00000000 EXCEED_CAPACITY_QUEUE

附註：  ICM_NO_SCHEDULED_ALLOWED，始終設定「確定」位

步驟6.將問題縮小到特定隊列。從CVP報告伺服器檢查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.如果配置正確，請檢查報告伺服器資料庫(Informix)中儲存的資訊，確定此特定網關和位置上的呼叫數。您可以通過CCB id（本例中為10.201.198.21）或位置（本例中為CALO）進行檢查。

步驟9 。在報告伺服器上，訪問Informix資料庫。

開啟CMD提示符並鍵入：dbacces

導覽至connection > connect

選擇cvp例項

鍵入username cvp_dbadmin

鍵入密碼

選擇callback@cvp database

退出並導航到查詢語言

步驟10.運行查詢：

從callback_current中選擇count(*)，其中==置"CALO";

步驟11.如果該值等於或大於在網關中為位置配置的中繼值，則這就是驗證失敗的原因，因為Callback_Current表中已達到允許的中繼的最大數量。

附註：  如CVP報告指南中所述，回撥表由兩個表組成：Callback_Current和Callback_Historical。這兩個表完全相同。每30分鐘，已完成的呼叫的資料從Callback_Pending提取並移動到Callback_Historical。

步驟12.如果在Callback_Current表中每個位置的中繼值已達到其限制，並且隊列中沒有回撥，則表明在將回撥記錄從Callback_Current移動到Callback_Historical表中時出現問題。

步驟13.確保CVPCallbackArchive在計畫任務（CVP報告伺服器）下運行。 導航至開始 — >程式 — >附件 — >系統工具 — >計畫任務。

.

步驟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表。

隊清單上發生GUID到Surrogateid的對映。在呼叫從回撥等待移動到回撥隊列指令碼的情況下，似乎存在一個視窗，在此視窗中，歸檔作業將記錄從當前移至歷史記錄，並且應用程式使用相同的surrogateid在當前表中輸入新記錄。  此問題與此CDETS CSCuq86400相關

解決方案

步驟1.訪問Informix資料庫。開啟CMD提示符並鍵入：dbacces

步驟2.導航到connection > connect 選擇cvp例項。鍵入username cvp_dbadmin並鍵入password

步驟3.選擇callback@cvp database exit並導航至Query Languages

步驟4.運行以下命令：

從callback_current中的surrogateid刪除（從回撥歷史中選擇surrogateid）；

如果存在臨時表錯誤，請執行以下操作：

刪除表t1;

步驟5.運行用於將資訊從查詢語言視窗dbaccess從當前回撥表移動到歷史回撥表的sp過程。

EXECUTE PROCEDURE sp_arch_callback();

步驟6.檢查當前表中的記錄是否沒有以前那麼多。

從callback_current中選擇count(*)，其中==置"CALO";

永久解決方案

步驟1.導航到Cisco\CVP\informix_frag，然後在文本編輯器中開啟sp_arch_callback.sql。

步驟2.在檔案開頭取消對此行的註釋：—drop procedure sp_arch_callback;   （刪除 — 在行首）。

步驟3.新增以下行：從callback_current中刪除代理位置（從回撥歷史中選擇surrogateid）；之後

建立過程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回撥 — f sp_arch_callback

註：如果在運行dbschema命令時出現授權問題，請以cvp_dbadmin身份登入到報告伺服器並嘗試多次。

步驟2.從輸出中，確保Delete from命令已執行。