排除CVP禮貌回撥(CCB)網關容量驗證故障
簡介
本文描述當呼叫者由於中繼網關容量超出而無法獲得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」驗證失敗。
步驟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表中已達到允許的中繼的最大數量。
步驟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
步驟2.從輸出中，確保Delete from命令已執行。
意見