簡介
本文描述當呼叫者由於中繼網關容量超出而無法獲得CCB服務時,如何解決客戶語音門戶(CVP)CCB問題。
必要條件
需求
思科建議您瞭解以下主題:
採用元件
本檔案中的資訊是根據以下軟體版本:
- 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 Trunks值較低,則驗證失敗。
症狀
入站呼叫不會獲得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
00000010 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://{Reporting Server IP Address}: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
退出並導航到Query Languages
步驟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命令已執行。