本文提供網際網路通訊協定客服中心(IPCC)疑難排解的相關資訊,主要針對外圍裝置閘道(PG)和思科智慧客服管理(ICM)。 雖然本文檔包含一些有關Cisco CallManager和Cisco Global Directory常見問題的資訊,但本文檔並不嘗試完整描述這些元件。相反,本文檔重點介紹症狀和方法以確定PG看到的問題的來源。 這些問題可能與軟體或配置有關。
思科建議您瞭解以下主題:
如何排除故障並支援Cisco ICM PG
本文中的資訊係根據以下軟體和硬體版本:
Cisco ICM版本4.6.2
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路正在作用,請確保您已瞭解任何指令可能造成的影響。
如需文件慣例的詳細資訊,請參閱思科技術提示慣例。
檢視IPCC的PG日誌。如果您在外圍裝置介面管理器(PIM)、開放外圍裝置控制器(OPC)或電腦電話介面(CTI)伺服器日誌中看到未指定的錯誤,請直接轉到JTapi網關(GW)日誌以獲得問題的更佳文本說明。JTAPI介面通常會在第三方請求出現錯誤時提供例外情況。這些例外僅提供沒有錯誤代碼的字串說明。因此,PIM/OPC/CTI伺服器會將許多錯誤記錄為未指定的錯誤。
檢查PIM日誌是否存在。如果沒有PIM日誌,請檢查以確保在Cisco ICM設定中啟用了外圍裝置。有時會新增外圍裝置,但您需要啟用外圍裝置。
選擇Edit > Peripheral,然後選中Enabled覈取方塊。
如果PIM進程重新啟動,請使用dumplog實用程式檢視Cisco CallManager PG上的PIM日誌。如果日誌檔案指示出現OPCHeartbeatTimeout錯誤,則必須修改此登錄檔設定。使用regedt32進行更改。
將eagtpim dynamic data下的登錄檔中的OPCHeartbeatTimeout修改為10。路徑如下:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\EAGENTData\Dynamic
注意:因為空間限制,此鍵出現在此處的兩行上。
如果PIM進程處於空閒狀態,請運行以下檢查:
檢查PIM日誌。您必須至少每分鐘看到「嘗試啟用」。
如果PIM處於非活動狀態,請使用dumplog實用程式檢查OPC日誌。運行opctest以檢視OPC進程是否從路由器收到配置。
如果OPC進程沒有從路由器收到配置,請使用dumplog實用程式檢視pgagent日誌。pgagent進程必須具有指向中央控制器的活動路徑。如果pgagent沒有活動路徑,請在PG設定中檢查網路連線和DMP配置。在路由器上,使用dumplog實用程式檢視ccagent日誌。驗證PG裝置(DMP系統ID)是否已作為路由器上的裝置啟用。
通過設定啟用路由器配置中的PG,或在DMP登錄檔下的登錄檔中啟用PG。
在命令視窗中,使用tracert命令驗證路由器和PG之間的網路連線。
注意:DNS和DHCP之間可能存在差異。
驗證路由器的IP地址是否在c:\winnt\system32\drivers\etc目錄的主機檔案中。
檢查PG > Setup中配置的邏輯控制器ID是否與Configure > ICM中PG邏輯介面控制器的ID匹配。確保PG > Setup中配置的外圍裝置ID與Configure > ICM中配置的外圍裝置ID匹配。
修改ICM設定以匹配配置。
轉到命令提示符並鍵入jview,然後按ENTER鍵。此時將顯示有關已安裝Java版本的資訊:
Microsoft (R) Command-line Loader for Java version 5.00.3190
如果您沒有看到此輸出,或者如果版本早於3190,則必須安裝正確版本的Microsoft JVM。運行msjavx86.exe。安裝期間,此檔案安裝在icr\bin目錄中。
在命令提示符下,轉到icr\bin 目錄,鍵入jtapigw,然後按ENTER鍵。 系統將顯示類似以下的響應:
18:43:17 Fail: Node Manager Required Arguments missing. 18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164) 18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs (NodeManager.java:27) 18:43:17 Trace: at MainWorkerThread.mainImplementation (MainWorkerThread.java:41) 18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)
或者,系統會顯示以下訊息:
Java.lang.NoClassDefFoundError: com/cisco/icr/GWThreadGroup
如果在運行jtapigw時看到第二個消息,請檢查Java類路徑。 使用登錄檔編輯器檢視SOFTWARE\Microsoft\Java VM項下的Classpath值。 按如下方式設定金鑰:
C:\WINNT\java\classes;.;c:\icr\bin\icrjavalib.zip
注意:驅動器號和Windows系統目錄可能不同,類後和c:\icr...之前的字元為:分號、句點和分號。
在命令提示符下,轉到icr\bin 目錄,鍵入jtapigw,然後按ENTER鍵。 系統將顯示類似以下的響應:
18:43:17 Fail: Node Manager Required Arguments missing. 18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164) 18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs (NodeManager.java:27) 18:43:17 Trace: at MainWorkerThread.mainImplementation (MainWorkerThread.java:41) 18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)
您會看到以下訊息,而不是上面所示:
Java.lang.NoClassDefFoundError
如果您在運行jtapigw時看到類似第二個消息,請驗證PG上是否安裝了Cisco JTAPI客戶端。檢查c:\winnt\java\lib下的檔案CiscoJtapiVersion.class。
如果此檔案不存在,您可以從Cisco CallManager在PG上安裝該檔案;http://<callmanager name>/main.asp。您可以在「應用程式」頁籤下找到該檔案。
如果您在Cisco CallManager PG上僅安裝了JTAPI 4.1 Service Pack(SP)4,並且任何熱修復程式都小於50,則需要升級。
如果您已運行ICM > Setup來升級PG,請進行檢查以確保檔案\icr\bin\icrjavalib.zip上的日期/時間顯示更新日期。此日期必須在大約一天內與bldXXXXX.version檔案中的日期/時間大致相同。
注意:如果運行安裝程式時檔案正在使用中,則安裝程式無法更新此檔案。如果您開啟了Internet瀏覽器,則可能會發生這種情況,因為如果瀏覽器開啟了zip,則瀏覽器會將zip檔案視為類路徑的目錄。為了避免此問題,請在運行安裝程式之前關閉所有瀏覽器會話。 如果安裝程式無法更新檔案,將顯示一條消息,指示您重新啟動PC以更新檔案。您必須重啟。
PIM與JTAPI網關(JTAPIGW)通訊,而JTAPIGW與Cisco CallManager通訊。當PIM嘗試啟用時,PIM通知JTAPIGW通過JTAPI初始化與Cisco CallManager的通訊。
您必須看到指示JTAPIGW已接受來自PIM的連線並聯絡getProvider()的消息,例如:
13:16:47 pg2A-jgw1 Trace:Calling getProvider () 172.24.79.128; login=PGUser;passwd=<***edited***> 13:16:52 pg2A-jgw1 Trace: Returned successfully from getProvider()
註:由於空間限制,此示例在多個行上顯示。
如果您沒有看到成功返回的跟蹤,則可以在呼叫getProvider()後看到其他錯誤。 getProvider()的跟蹤顯示用於初始化JTAPI的引數。 第一個引數是服務名,即Cisco CallManager電腦的IP主機名或IP地址。 本例中使用的是IP地址。 如果使用名稱,則PG必須能夠通過主機檔案或DNS解析該名稱。 確保您可以ping名稱或地址。 如果您需要更改服務名稱,請重新運行ICM > Setup,然後在Edit Peripheral對話方塊中更改名稱。
呼叫getProvider()的跟蹤還顯示使用的登入名。請注意,跟蹤不顯示密碼。登入名和密碼取自管理員在ICM > Setup下輸入的內容。這些內容必須與在目錄中配置並在Cisco使用者首選項網頁中管理的有效使用者和密碼匹配,以便能夠控制每個代理裝置和路由點。檢查以確保ICM > Setup中的名稱和密碼正確。將目錄中的使用者配置為僅有權控制有效的代理裝置和路由點。
JTAPI GW進程無法解析Cisco CallManager的地址。使用Cisco CallManager主機名或IP地址在設定中的PIM對話方塊中配置服務引數。如果Cisco CallManager的主機名配置正確,請確保可以ping Cisco CallManager。否則,請使用Cisco CallManager的IP地址,而不是主機名。
JTAPI GW使用使用者名稱和密碼登入到全域性目錄。在Setup(設定)中的PIM對話方塊中,使用者名稱和密碼必須與Cisco CallManager管理員網頁中ccmadmin > User > Global Directory下的全域性目錄中配置的使用者使用者名稱和密碼匹配。
如果該使用者不存在,請新增新使用者。確保選中頁面底部的CTI Enabled覈取方塊。
Cisco CallManager全域性目錄使用者頁面上的覈取方塊可以啟用或禁用PIM或IP IVR使用者的CTI許可權。您必須選中並更新此覈取方塊才能啟用PIM/JTAPI GW。此覈取方塊可確保兩個CTI裝置無法連線到Cisco CallManager,從而造成問題(預設限製為400)。
在Cisco CallManager版本3上,此服務在服務控制中顯示為「Cisco CallManager」。 啟動服務。
Cisco CallManager服務通常設定為在異常退出時重新啟動,但您可以將此設定為「off」,以排除故障轉移場景中裝置遷移可能存在的問題。
檢查事件日誌以檢視Cisco CallManager服務是否重新啟動。如果系統發現某個CPU使用不足的問題,系統有時會重新啟動。系統在事件日誌中報告表示「SDL計時器執行緒緩慢」的錯誤或警告。 出現此類錯誤時,Cisco CallManager將重新啟動。此版本的Cisco CallManager以正常優先順序運行,以便系統上運行的其他應用程式可以幹擾呼叫訊號。
當實體記憶體較少或系統遇到其他計時問題時,Cisco CallManager可能會出現一個錯誤,表明在10分鐘的超時和重新啟動後無法初始化。Cisco CallManager資料庫層(DBL)的DCOM元件服務在初始化時遇到問題。通過元件服務 — DCOM元件停止並啟動此DBL DCOM服務以解決此問題。
註:這與Cisco CallManager等系統服務不同。
向思科技術協助中心(TAC)提交案例。 下次重新啟動系統時,這可能是一個問題,除非您解決了根本的計時問題。
確認目錄服務已啟動且運行正常。 預設情況下,這是Cisco CallManager電腦上處於服務控制中的DC目錄伺服器。試著啟動機器。您可能會遇到錯誤。
如果系統耗盡記憶體或磁碟空間,目錄服務可以進入暫停狀態。Microsoft Windows 2000事件日誌中出現錯誤。如有必要,請解決資源問題並重新啟動目錄服務。
驗證Cisco Global Directory使用者網頁是否可以實際檢視和配置使用者,並為控制裝置分配許可權。JTAPIGW和網頁都使用Cisco CallManager訪問目錄伺服器來訪問使用者和許可權。如果JTAPIGW問題是由目錄伺服器問題導致的,則使用者網頁也可能會出現問題。可能的原因是,目錄伺服器沒有運行,或者目錄配置不正確(如果有的話)。
要使用Cisco CallManager 3.0.5及更高版本,必須安裝目錄伺服器。AVVID DC目錄是預設目錄,在Spirian安裝CD上可用。安裝目錄伺服器後,安裝Cisco CallManager將配置目錄。
必須正確執行此安裝,並且目錄伺服器必須啟動且必須正確運行,JTAPIGW才能登入到Cisco CallManager並使用JTAPI。
確保DC目錄服務和Cisco CallManager都正常運行。
安裝Cisco CallManager時,在看到目錄管理器密碼提示時必須輸入「ciscocisco」。如果您輸入其它內容,則可能必須刪除DC目錄軟體(新增/刪除)並重新安裝。如果刪除過程告訴您不能刪除某些檔案,則必須手動刪除或重新命名當前c:\dcdsrvr目錄。
檢查控制面板以確認服務無法啟動。接下來,在「屬性」欄位中驗證是否配置了管理員以及服務的登入和密碼是否正確。
從系統的「開始」選單中啟動「DC目錄管理」。使用密碼「ciscocisco」(預設)或管理員配置的任何密碼,使用使用者目錄管理器登入。如果收到指示使用者未配置的錯誤,請運行DCDSrvr\bin目錄中的一個Cisco AVVID配置檔案。如果這是主Cisco CallManager發佈伺服器,請從DOS提示符運行avvid_cfg.cmd。如果這是輔助Cisco CallManager,請從命令提示符運行avvid_scfg.cmd。
如果看到指示已配置此設定的錯誤,則使用者確實存在。如果沒有錯誤,必須立即開始正常運行。返回並從ccmadmin上的「全域性目錄使用者」頁檢查訪問許可權。
注意:如果目錄的系統資源不足,則DC目錄將進入暫停模式。
此示例對裝置目標使用示例ICM配置:
裝置目標示例 | |
企業名稱 | 代理9782755100 |
全域性地址 | 代理9782755100 |
ConfigParm | /devtype CiscoPhone /dn 9782755100 |
下一個示例使用代理的ICM配置示例:
代理示例 | |
外圍裝置 | CCMPG_PIM1 |
外圍裝置編號 | 1234 |
密碼 | XXX |
運行PG的ICM > Setup時,將代理擴展長度指定為「4」。 因此,在示例配置中,示例裝置的副檔名是/dn引數的最後4位數(例如,"5100")。
嘗試使用CTITest登入。
如果無法使用軟電話登入座席,請通過ctitest嘗試相同操作。以下是可用於將示例代理登入到示例裝置目標的ctitest命令的示例清單。此命令清單假定CTI伺服器偵聽電腦CTIerverA上42027埠100。此清單還假設裝置是表示為ICM外圍裝置5000的外圍裝置的分機。
config /hostA CTIServerA config /portA 42067 config /service CLIENT_EVENTS+CLIENT_CONTROL agent /periph 5001 /inst 9782755100 open login 1234 XXX /inst 9782755100
使用opctest「status」命令並確認IPCC PIM和CTI伺服器顯示為PIM_ACTIVE和CTI_ACTIVE狀態。PIM和CTI伺服器日誌視窗的標題欄也指示進程狀態。
檢查設定以連線到CTI伺服器。對於案頭軟電話,設定位於.ini檔案中(通常為c:\program files\geotel\cti desktop\cticonfig.ini)。 要檢查的設定包括:
PeripheralID — 此值必須與Configure > ICM中IPCC外圍裝置的外圍ID匹配。
SideAHost — 該值必須是CTI伺服器端A的IP主機名或地址。
SideBHost — 該值必須是CTI伺服器端B的IP主機名或地址。 如果CTI伺服器是簡化的,則可以將此欄位留空。
SideAPort — 此值必須與A端CTI伺服器偵聽連線的埠匹配。該值在CTI伺服器的ICM設定中指定。CTI伺服器在標題欄中顯示此埠,並在CTI伺服器啟動時記錄此值。驗證使用者端是否可以ping CTI伺服器。
運行PG/CTI伺服器上\icr\bin目錄中的setup.exe。選擇CTI網關元件。驗證是否未選中Agent Login Required覈取方塊。此覈取方塊選擇不適用於IPCC或任何第三方控制應用程式。此覈取方塊的作用是監控應用或其他ACD代理。
使用procmon 對pim和「trace tp*」啟用第三方跟蹤(區分大小寫)。 這必須顯示登入請求。驗證引數是否正確。該儀器被跟蹤為「Device=」。 此值必須與裝置目標configparam中的/dn字串相匹配。代理ID將跟蹤為「AgentID=」。 此值必須與配置/ICM中的座席外圍裝置編號相匹配。
無效密碼(_P)
確保密碼正確(密碼可能不會以明文跟蹤)。 如果密碼不正確,日誌必須顯示INVALID_PASSWORD_SPECIFIED錯誤。
INVALID_OBJECT
表示裝置目標中的配置引數包含無效的裝置型別。關鍵字之間出現空格時,出現以下錯誤:
/devtype CiscoPhone /dn 9782755100
INVALID_DEVICE_TARGET
表示裝置目標中的某個內容無效,很可能是配置引數欄位中的某個內容。使用dumplog實用程式,檢視PIM上次重新啟動時的PIM日誌。當裝置目標配置字串無效時,日誌將驗證裝置目標和日誌錯誤。
在jgw日誌中查詢嘗試登入時發生的錯誤。使用procmon 對PIM和「trace *TP*」啟用第三方跟蹤(區分大小寫)。 查詢行「MsgAddCallObserver:地址:XXXX",其中XXXX是您嘗試登入的分機。此分機必須是PG使用者有權控制的裝置上的有效Cisco CallManager分機。分機號必須是Cisco CallManager知道的電話的正確位數。換句話說,分機號必須是您從同一Cisco CallManager上的另一部電話撥打的號碼,才能接通有問題的電話。
如果jgw日誌顯示異常(表示裝置不在提供商域中),則電話不會與JTAPI GW登入的使用者相關聯。確保全域性目錄使用者裝置關聯清單遠端的擴展是正確的。此外,請確保裝置行號未註冊兩次。共用線路外觀是IPCC不支援的Cisco CallManager功能。您可能會無意中嘗試用兩條線路相同的電話設定共用線路外觀。如果您更改了一個行號,則其他行號會更改,並且PG無法登入到正確的裝置。為了解決此問題,請刪除這兩行,並將其新增到Cisco CallManager。
要登入,座席必須在「配置/ICM」中配置為至少一個技能組(技能組成員)的成員。
確保該座席(如座席外圍裝置編號所示)尚未登入到另一個裝置目標。檢查這個問題的方法之一是運行監控ICR,然後為有問題的代理運行無代理報告。如果座席已登入,則會顯示座席登入到的裝置目標的網路目標ID。只有在將ICM配置為將外圍裝置的代理資料傳送到此AW時,代理資料才會出現在awdb中。
您還可以在isqlw中針對awdb中的Agent_Real_Time表查詢此資訊。首先,查詢座席的技能目標(例如,從座席中選擇*,其中PeripheralID = XXX,PeripheralNumber = YYY)。 然後,檢查座席是否已登入(例如,從Agent_Real_Time中選擇*,其中SkillTargetID = XXX)。
當您連線到procmon 到PIM並運行dagent <agent peripheral number>時,也可以檢查此問題。
確保裝置目標(如儀器所指定的)尚未有其他座席登入。
檢查此情況的方法之一是在awdb中對Agent_Real_Time表運行isqlw。首先,查詢相關裝置目標的網路目標ID。例如,從Device_Target中選擇*,其中ConfigParam類似於「%1003%」。現在,檢視裝置目標是否已登入。例如,從Agent_Real_Time中選擇*,其中NetworkTargetID = XXX。
在連線到procmon 到PIM並轉儲裝置目標時,也可以檢查此情況。轉儲裝置目標有兩種方法。ddt命令將網路目標ID作為輸入並轉儲裝置目標。dead命令將裝置目標配置中的/dn字串作為輸入並轉儲裝置目標。例如,如果裝置目標/dn字串為/dn 978275100,則將該裝置目標轉儲為dead 978275100。
轉到Cisco CallManager網頁,選擇User/Global Directory並找到PG使用的使用者ID。檢查「關聯裝置」並確保使用者擁有控制裝置的許可權。
如果在使用者頁面上找不到該裝置(選中或未選中),則資料庫(Cisco CallManager在其中儲存裝置)與目錄伺服器(儲存裝置和儲存使用者配置檔案)之間的同步可能存在問題。 檢查目錄伺服器(DC目錄伺服器)是否運行。
檢查Windows NT事件檢視器應用程式日誌,並從DC目錄或metalink中查詢錯誤。如果發生匯入錯誤,請從c:\dcdsrvr\bin運行avvid_recfg。
確保在Cisco CallManager電腦上安裝了Microsoft Java虛擬機器(JVM)。若要測試此功能,請在命令提示符下鍵入jview。對於Cisco CallManager 2.4,您必須手動安裝JVM。對於Cisco CallManager 3,平台為Windows 2000,JVM安裝是自動的。
檢查電話是否通電、已註冊到Cisco CallManager且能夠在沒有座席控制的情況下從電話發出和接收呼叫。
確保座席已登入且未處於「可用」狀態。 如果座席不可用,則該座席無法進行呼叫。若要進行呼叫,請先按一下未就緒。
如果僅在撥打某些號碼時出現錯誤,請從物理電話上檢查這些號碼,以確保可以成功撥入。如果配置了ICM撥號號碼計畫,請檢查撥號號碼是否與撥號號碼計畫中的一個萬用字元匹配。然後檢查該座席的座席工作台設定是否允許座席撥打被叫號碼計畫條目所標識的號碼型別(例如,國際)。
為每個PIM配置的撥號號碼計畫可能配置錯誤或配置正確,以防止座席撥出到某個號碼。PIM日誌中的錯誤必須指示許可權錯誤。當使用撥號號碼計畫進行座席到座席呼叫時,座席和裝置的號碼不能重疊。
當座席發出呼叫或呼叫被路由到座席時,路由器使座席不可用。此機制允許路由器在PIM報告呼叫到達之前將另一個呼叫路由到代理。某些網路實際路由呼叫需要幾秒鐘時間。路由器不會根據代理狀態取消計時器。
如果從路由請求端將呼叫路由到PIM的實際時間相對較短,則可以更改路由器中的可配置時間。在DOS命令視窗中的一個路由器上,使用rtsetting.exe。在Extrapation > Agent下查詢。預設設定為10秒。如果該值太短,路由器會將呼叫路由到即將接收呼叫的代理。這會導致PIM丟棄呼叫。
PIM上的預設超時為7秒。您可以使用regedt32命令修改此值。在此路徑中新增「AgentReserveTimout」金鑰:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\EAGENTData\Dynamic\
注意:此金鑰將新增到版本4.1.5設定中。
注意:因為空間限制,此鍵出現在此處的兩行上。
PIM編號必須始終比路由器外推計時器小幾秒鐘,以防止路由器在處理原始事件之前向PIM傳送新的呼叫前事件。這會導致PIM出現問題。
如果呼叫在PIM超時後到達,則該呼叫被視為非ACD呼叫,並且沒有上下文變數、服務或技能組資訊被分配給該呼叫。
如果座席正在呼叫中並按一下「未就緒」、「忙碌」或「其他」,座席狀態將不會立即更改。這是故意的。在完成呼叫之前,座席將一直處於「通話」或「保持」狀態。根據按下哪個按鈕,代理會轉換為「未就緒」、「工作就緒」或「工作未就緒」。如果在呼叫結束後座席立即轉換到「可用」,則必須檢查座席的座席工作台設定,檢視是否設定了「傳入後可用」或「傳出後可用」。這些設定會覆蓋座席在呼叫期間使用按鈕執行的任務。
在「配置ICM」中檢查座席的座席工作台設定,並檢視是否選中了「需要空閒原因」。如果選中此覈取方塊,則座席在沒有原因代碼的情況下無法進入「未就緒」狀態。修改Desktop_Settings.cfg以匹配配置ICM中的代理台設定,或者更改配置ICM中的代理台設定。
如果沒有為座席分配座席工作台設定,則座席可以登入並進入準備狀態,但座席無法進入not_ready或退出。解決方法是關閉代理應用程式,分配代理案頭設定,然後再次登入。
當座席發出呼叫或呼叫被路由到座席時,路由器使座席不可用。此機制允許路由器在PIM報告收到呼叫之前將另一個呼叫路由到代理。某些網路實際路由呼叫需要幾秒鐘時間。路由器不會根據代理狀態取消計時器。
如果從路由客戶端將呼叫路由到PIM的實際時間相對較短,則可以更改路由器中的可配置時間。在DOS命令視窗中的一個路由器上,使用rtsetting.exe。在Extrapation > Agent下查詢。預設值為10秒。如果該值太短,路由器會將呼叫路由到即將接收呼叫的代理。這會導致PIM丟棄呼叫。
登入請求和就緒請求的資料不一致。可能地,工具、座席ID或外圍裝置編號不匹配。使用procmon開啟CTI伺服器跟蹤,並將regset設定為0xf8以檢視相應的跟蹤。如果開啟第三方(TP)追蹤,則還可以在OPC或PIM日誌中檢視此資訊。
如果座席處於「工作就緒」、「工作未就緒」或「可用」狀態,則在座席註銷之前,座席必須首先進入「未就緒」狀態。修改Desktop_Settings.cfg以匹配配置ICM中的代理台設定,或者更改配置ICM中的代理台設定。
如果座席處於「未就緒」狀態且仍無法註銷,請在配置ICM中檢查座席的座席案頭設定,然後檢視是否檢查了需要註銷原因。
如果軟體電話顯示的呼叫實際上已不存在,則座席狀態可能停滯在「通話」或「保持」狀態,並且座席無法註銷。這可能是由於JTAPI或PIM中的軟體錯誤所造成。若要清除該情況,請先嘗試在啟用釋放按鈕的情況下從軟電話清除呼叫。如果此操作不起作用,則嘗試註銷代理。如果註銷按鈕不起作用,請退出並重新啟動軟電話。如果此情況持續出現,請退出軟體電話,運行工作管理員,運行kill geodcs.exe和common~1.exe,然後重新啟動軟體電話。這些進程可以繼續運行並記住無效的代理狀態。
在procmon中,檢查PIM上的代理狀態。如果重新啟動Agent Desktop且條件未清除,則可以採取更多措施。CTI伺服器和OPC提供通過procmon或opctest的調試介面清除呼叫的機制。這是比另一個選項稍為優先的選項,另一個選項是循環PG服務或至少關閉PIM視窗。
使用regedt32時,請檢查以下登錄檔設定:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\ CurrentVersion\<pim_inst>\CallControl\MaxAlertingTimeAllowedForCall
和
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\ CurrentVersion\<pim_inst>\CallControl\MaxConnectedTimeAllowedForCall
注意:因為空間限制,這些登錄檔項會在此處顯示為兩行。
分別將這些值設定為300和28800。
使用AW Call Tracer工具驗證呼叫是否到達指令碼並且指令碼是否正確運行。運行指令碼編輯器並監視指令碼。檢視路由器、OPC和PIM日誌查詢問題。大多數路由錯誤都會被無條件地跟蹤。
「配置ICM」中標有「使用DN/標籤對映」的每個路由客戶端都有一個設定。 如果將此設定設定為「是」,則需要為撥號號碼和可能的目標標籤的每種組合配置一個「撥號號碼標籤」條目。此設定在PG路由客戶端上不起作用,必須設定為「否」。
驗證路由請求端上的「Label Configured(已配置標籤)」。您必須在每台客戶機上配置Label,即使該標籤在每個客戶機上相同。
要使用Post Routing,必須在Cisco CallManager上配置「CTI路由點」,並為路由點分配具有所需目錄號碼的線路(例如「5000」)。 對於要發佈路由的座席呼叫,請使用撥號號碼計畫。撥打Cisco CallManager CTI路由點的座席混淆了CTI Desktop 4.1.9版中的IPCC軟體電話。
您必須將CTI路由點裝置新增到Cisco CallManager使用者網頁全域性目錄下PG使用者的「關聯裝置」清單中。如果建立新裝置,請先新增行,然後將裝置新增到使用者「關聯裝置」清單。如果向使用者裝置清單中已經存在的裝置新增更多線路,則需要重新啟動JGW以使JGW識別新線路。但是,如果新增新裝置,在裝置中新增一行,然後將該裝置新增到使用者裝置清單,則JGW必須能夠識別新裝置(大約在30秒內)。
檢查所撥號碼,確保已為外圍裝置路由客戶端配置該號碼。運行procmon到JGW,並以「trace *ROUTE*」形式開啟跟蹤(區分大小寫)。 檢查JGW日誌中是否存在與撥叫號碼有關的錯誤。啟動後,JGW嘗試註冊撥回號碼的路由回叫。當呼叫所撥打的號碼時,網關會收到「RouteEvent」。
與撥出號碼一起,驗證呼叫型別是否已建立並正確對映到指令碼。
如果已配置ICM撥號號碼,已設定CTI路由點並將其新增到使用者裝置清單,但在撥打該號碼時仍無法接收路由請求,則可能需要重新啟動JGW(或循環PG)。 如果您已在JGW(trace *ROUTE*)中開啟跟蹤,並且您看到顯示地址不在提供商中的錯誤,則只需重新啟動。通常,JGW必須能夠識別新增到使用者裝置清單中的新CTI路由點,而無需重新啟動。此外,如果線路新增到已經存在的CTI路由點,則JGW無需重新啟動便無法識別這些線路。如果為每個已撥號碼新增新的CTI路由點,而不是向現有裝置新增新的線路,則必須能夠避免重新啟動。
注意:此假設在PIM的winnt\java\lib目錄的JTAPI.ini檔案中啟用了DeviceListPolling。如果關閉DeviceListPolling,則必須啟用DeviceListPolling。如果關閉DeviceListPolling,並且您將任何裝置新增到使用者清單,則必須循環PG或至少JTAPI GW,PG才能看到新裝置。
使用opctest開啟路由跟蹤「debug /routing」,並在對路由點進行呼叫時檢查OPC日誌中是否存在錯誤。檢查是否正在接收路由請求並返回標籤。路由請求顯示為「CSTA_ROUTE_REQUEST」和「ICR_NEW_CALL_REQ」消息。返回的標籤顯示為「ICR_CONNECT」消息。如果發生錯誤,您可以看到「ICR_DIALOG_FAIL」消息而不是「ICR_CONNECT」消息。在這種情況下,請檢查路由器日誌中是否存在錯誤。
使用rtsetting.exe開啟路由跟蹤,並在向路由點進行呼叫時檢查路由器日誌中是否存在錯誤。
確保已配置所有必需的標籤。如果您的路由指令碼面向IPCC/EA代理,則必須為每個目標裝置目標的Post Routing客戶端配置標籤。
檢查路由器日誌中是否存在錯誤。如果沒有:
如果隊列節點排隊到基本優先順序,則代理可用時不會發生任何情況。有兩種方法可以解決此問題:
有一個名為AutoLoginBase的路由器登錄檔設定(使用rtsetting.exe)。 更改此設定允許將呼叫排入基本技能組以按預期或多或少地工作。當發生此類排隊時,沒有優先使用主要技能而非輔助技能。
顯式排隊到隊列節點中的主要和/或次要技能集。
為相關裝置目標以及此路由客戶端可以路由到的所有其他目標配置標籤。使用AW批次配置工具,通過配置ICR更高效地完成此操作。
必須無條件跟蹤路由錯誤。
您可以使用Call Tracer工具測試路由路徑。
使用rtrace開啟路由請求跟蹤,並在對路由點進行呼叫時檢查路由器日誌中是否存在錯誤。
確保已配置所有必需的標籤。如果路由指令碼面向IPCC/EA代理,則必須為每個目標裝置目標配置標籤。每個裝置目標必須為嘗試傳送呼叫的每個路由客戶端配置標籤。因此,如果呼叫從網路預先路由到可用座席,則網路路由請求端必須擁有關聯裝置目標的標籤。如果呼叫先在VRU中排隊,然後被送達代理,則VRU路由客戶端必須具有相關裝置目標的標籤。
確保未在Configuration Manager/PG資源管理器中的「路由選擇客戶端」頁籤中選中「使用DN/標籤對映」。
使用procmon開啟PIM中的跟蹤(跟蹤預呼叫、跟蹤*call_event*)並檢查日誌。路由器會顯示呼叫前消息。您還會看到「DeliveredEvent」,其中「DevTgDevStr」設定為代理擴展。如果呼叫未顯示,請確保該標籤對於路由客戶端正確。
由於Cisco CallManager提供的結果不一致,因此IPCC不支援保留呼叫並進行新呼叫的選項。這被視為產品增強功能,可以考慮在未來的版本中使用。
當諮詢呼叫被交換/替代/保留/檢索時,Cisco CallManager將斷開諮詢關聯。這會導致任意傳輸方案,這是不受支援的。工程師可以重新連線到客戶並開始新的諮詢。IPCC軟電話會禁用備用按鈕,直到問題解決,但第三方供應商可能會投訴。
Cisco CallManager有一個限制,即只有會議發起方可以向會議新增更多參與方。其他方無法在Cisco CallManager中新增更多方。
在「座席案頭」設定中,有一個時間設定用於註銷處於「未就緒」狀態的座席。最長的非活動時間為2小時,但是可以將時間配置為更短。處於「可用」狀態的座席在處於「非活動」狀態時不會被註銷。如果振鈴無應答計時器過期(也是可配置的代理台設定),代理會從「就緒」轉換為「未就緒」。
CTI伺服器已配置心跳超時。較舊的電腦、超負荷工作的CTI伺服器或存在頻寬問題的網路可能是根本原因。CTI伺服器日誌必須在日誌中報告錯誤。
「配置ICR(M)」中的代理案頭設定和代理配置檔案必須都同意代理的處理方式。
在配置引數中,ICM的外圍配置中有一個工作計時器。將引數設定為\WORKTIMER 30,以在自動可用時設定30秒的延遲。
案頭配置檔案位於:
\program files\geotel\cti desktop\Desk_Settings.cfg
在Desk_Settings.cfg和「配置ICR(M)代理程式案頭設定」中,必須將「傳入」的工作模式設定為「必需」、「非必需」。「資料必需」取代了自動可用選項。
檢視JTAPI GW日誌,檢視是否存在指示協商傳輸失敗原因的錯誤。檢查代理軟體是否允許保留/取回或替代諮詢呼叫的操作。當保留/檢索任一呼叫時,該呼叫不再被視為諮詢呼叫,而是Cisco CallManager的「任意」轉接。Cisco CallManager存在任意轉接的問題。限制使用者在諮詢呼叫中重新連線或完成轉接。
Cisco CallManager當前存在會議未完成時發起協商的會議的斷開事件問題。再次斷開呼叫,以清除座席電話上的呼叫外觀。
首先,監視活動指令碼。然後檢查路由客戶端和VRU的路由器、OPC和PIM日誌。大多數錯誤都會被無條件地跟蹤,但您可以向上翻轉跟蹤以更好地瞭解發生的情況。
以下是轉換路由序列:
路由客戶端向路由器發出新的呼叫請求。
路由器返回一個連線到路由客戶端的標籤,該標籤必須將呼叫傳送到IVR。
然後IVR必須傳送一個RequestInstruction,VRU PG使用該指令查詢外圍裝置目標。
路由器將請求指令的外圍目標與其等待的轉換路由外圍目標匹配。
路由指令碼按照客戶的設計繼續運行指令碼或隊列節點。
監視活動指令碼以查詢故障路徑。檢視路由器追蹤以瞭解錯誤。檢查路由客戶端是否收到初始標籤。驗證VRU是否收到呼叫。驗證VRU是否在VRU PIM或OPC級別傳送請求指令。
監視指令碼並驗證請求是否到達到VRU節點的轉換路由。
首先,在路由指令碼中,選擇或路由選擇節點選擇轉換路由不足以將路由轉換為服務控制的VRU。需要到VRU節點的轉換路由。
其次,監控器必須顯示呼叫到達轉換路由節點。此處失敗表示無法確定轉換路由,或者未從IVR接收RequestInstruction路由請求消息。
轉換路由超時錯誤表示路由器沒有收到請求指令。驗證OPC和VRU PIM是否存在錯誤,並檢視RequestInstruction是否到達。
在路由器上使用rtrace工具啟動「轉換路由」和「網路VRU跟蹤」,以便更好地指示路由器中發生的情況。在VRU PG OPC中,使用opctest啟用服務控制報告。
請求指令必須指示對映到為VRU PG配置的一個中繼組中的中繼組外圍裝置號的有效中繼組。循環VRU PG以接收中繼組外圍裝置編號的更新(如果已修改)。
確保IVR PG路由客戶端中的DN標籤對映已關閉。IVR PG需要網路VRU分配。網路VRU必須為型別2。IVR PG必須分配網路中繼組和中繼組。在中繼組中引用網路中繼組。
NIC/post路由PG必須為外圍裝置目標中的每個DNIS設定標籤。(在轉換路由嚮導中,使標籤與路由請求客戶端的DNIS相同。您可以在字首中設定此設定,選擇字首= DNIS選項。)
當代理可用時,VRU路由客戶端需要為其路由到的裝置目標配置標籤。
此Cisco IP IVR部分介紹如何排除IP IVR和ICM之間的配置錯誤,並包括設定IVR PG後期路由和轉換路由的常見問題。有關一般IVR錯誤的更多資訊,請參閱Cisco IP IVR故障排除指南。
通常,檢查appadmin > Engine > Trace檔案網頁下面的MIVR日誌。
在Cisco CallManager、IVR和ICM中配置的IVR CTI埠和CTI路由點。
IVR CTI埠和CTI路由點與Cisco CallManager全域性目錄中的IVR使用者關聯。
在IVR ICM配置中選中服務控制覈取方塊。
IVR指令碼定義中的指令碼名稱與ICM中的網路VRU指令碼名稱匹配。
VRU PG中的中繼組編號與IP IVR中的CTI埠組編號匹配。
除了您用於故障排除的所有其他操作外,您還可以嘗試這些操作來幫助排除IP IVR故障。
檢查MIVR日誌。此日誌通常可以指向問題區域。
使用調試設定開啟Cisco IP IVR是SS_TEL和LIB_ICM。
在IP IVR上使用jtprefs開啟IP IVR的Cisco Jtapi日誌。請參閱偵錯工具。開啟跟蹤後停止並啟動IP IVR引擎。
驗證IP IVR JTAPI轉換路由埠組上的CTI埠組編號是否與ICM中中繼組配置的外圍裝置編號匹配。
檢查engine-trace檔案下的IP IVR日誌以驗證:
收到運行指令碼。
IP IVR可以找到指令碼。使用儲存庫管理工具上傳指令碼。
IP IVR可以找到提示。使用者定義的提示駐留在IP IVR上的\wfavvid\prompts\ user\en_us\中。
這通常意味著在IP IVR中配置的一些CTI埠或CTI路由點尚未配置和/或與Cisco CallManager上的IP IVR使用者相關聯。
這也意味著指令碼的名稱不正確,或者尚未上載到儲存庫管理器。
通常,此條件表示一側或另一側的配置不完整或不匹配。
這是一個配置錯誤的路由指令碼,在配置ICR中的網路VRU指令碼配置中允許太少的超時。
用於ICM介面的IP IVR可用的某些指令碼運行時間非常長,但ICM網路指令碼配置的預設超時為三分鐘。如果指令碼超時,而運行指令碼故障路徑播放另一個運行指令碼,則這些運行指令碼基本上在IVR中排隊。當指令碼出隊時,您會聽到許多指令碼互相玩耍。
IVR統計對於IPCC服務級別報告非常重要。因此,此處包含有關如何進行故障排除的一些資訊。作為概述,在VRU中實現的呼叫在路由器和VRU PG中的更改將計為排隊,而不是連線。當呼叫被路由時,它們被報告為已應答。當隊列中的客戶斷開呼叫時,將其報告為已放棄。請參考熱修復程式53和54的readme.txt以瞭解其他詳細資訊。路由器會向下傳送特殊隊列事件,這些事件表明呼叫在路由器處處於哪種狀態。
在VRU PIM中設定了特殊登錄檔,因此您必須主動開啟此功能以確保最小的中斷。
將VRU服務和Cisco CallManager PG服務新增到一個或多個企業外圍裝置報告時,企業服務即時報告10會特別使用此資料。企業服務即時報告要求將VRU PG和Cisco CallManager PG服務分組到企業服務中,以便進行報告。
其他有用的隊列報告是用於即時和歷史記錄的新呼叫型別報告,技能組即時網格現在顯示按技能組排隊的呼叫。
VRU PIM不生成CSTA事件。在VRU PG設定中啟用服務控制報告。它位於ServiceControlQueueReporting中的登錄檔項中,位於:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\VRUData\Config
注意:由於空間限制,此登錄檔項會在此處顯示為兩行。
如果VRU PIM的啟動日誌不存在,則必須投訴。
新增ServiceControlQueueReporting鍵,並將值設定為1,在:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\VRUData\Config
注意:因為空間限制,此鍵出現在此處的兩行上。
OPC日誌指示在對錯誤服務的呼叫計數時未找到服務對映,或者服務報告中未顯示服務對映。
Cisco ICM的設計目的不是為了輕鬆關聯資料呼叫型別、服務和技能組表。通常,數字在每一組有略微不同的含義。呼叫只有一個服務,但如果涉及多個座席,則可能有兩個技能組。無應答重定向(RONA)功能可能生成另一個後路由,而不生成另一個終端記錄。
症狀:已處理的呼叫或其他統計欄位在服務、呼叫型別和/或技能組報告之間不匹配。
條件:呼叫型別、服務和技能組通過邏輯對映相互設定,但報告仍不完全匹配。
疑難排解:如果呼叫量小於每秒1次呼叫,請根據CSTA、PIM、代理和第三方事件在OPC、PIM和JTAPI GW中啟用跟蹤設定。如需說明,請參閱本檔案的工具一節。
記錄呼叫流程:
Cisco CallManager PG或VRU PG上的初始帖子路由是否?
是否配置無應答轉發(FONA)?FONA配置為重定向到什麼?
是否配置了外圍裝置編號0的預設技能組以將外路由呼叫與非路由呼叫和出站呼叫分開?
從這些表中獲取包含「select *」語句的一天的歷史資料:
外圍裝置半小時
Call_Type_Half_Hour
Service_Half_Hour
Skill_Group_Half_Hour
Termination_Call_Detail
Route_Call_Detail
在Cisco CallManager中收集跟蹤時,可以從Cisco CallManager Admin頁面的Services > Trace Flags下啟用標誌。0xCB05是為SDL跟蹤CTI錯誤而設定的良好跟蹤標誌。在服務引數下設定0xCB05以進行調試。請參閱AVVID TAC案例:收集故障排除信息以瞭解詳細資訊。請參閱Cisco CallManager聯機文檔,包括故障排除指南。
有關如何開啟Cisco CallManager跟蹤的資訊,請參閱為Cisco技術支援設定Cisco CallManager跟蹤。
請參閱更改Cisco CallManager IP地址並更改伺服器名稱。
在Cisco CallManager PG上運行安裝程式,並更改Cisco CallManager PIM的JTAPI服務。如果您有分機移動和/或電話服務。
停止CRA引擎。
在CRA中 — 在引擎配置下更改IP地址。
在JTAPI下更改IP。
停止伺服器上的DC目錄服務。
更改目錄配置中的IP地址。
在Cisco CallManager中 — 在System > Server下更改IP地址。
在System > Enterprise Parameters下更改URL中的IP地址。
在Features > Phone Services下更改所有URL中的IP地址。
更改伺服器IP地址 - 網路屬性。
將DHCP Option 150更改為新IP地址。
更改DC目錄中酒店配置檔案的IP,Cisco CallManager > System Profile > Hoteling。
開啟SQL Enterprise Manager。
更改PlugIn表中的URL中的IP地址。
若要備份您的組態變更:
開啟stiBackup配置。
在所有適當的頁籤下更改伺服器IP地址。
Procmon是一個命令列工具,可用於調試PIM和JTAPI GW進程。
用法:procmon <customer name> <node>程式。
Procmon ipcc pg1a pim1
Procmon ipcc pg1a jgw1
Procmon ipcc cg1a ctisvr
以下是每個進程的一些有用的跟蹤設定:
JTAPI GW(使用procmon)
trace JT_TPREQUESTS(啟用第三方請求跟蹤)
trace JT_JTAPI_EVENT_USED(為PG使用的JTAPI事件啟用跟蹤)
trace JT_PIM_EVENT(為傳送到PIM的事件消息啟用跟蹤)
trace JT_ROUTE_MESSAGE(啟用路由請求端跟蹤)
trace JT_LOW*(基於底層JTAPI和CTI層的跟蹤)
PIM(使用procmon)
trace tp*(開啟第三方請求跟蹤)
trace precall(開啟預呼叫事件跟蹤)
trace *event(開啟座席和呼叫事件跟蹤)
trace csta*(啟用CSTA呼叫事件跟蹤)
CTI伺服器(使用procmon)
regset EMSTraceMask 0xf8(開啟有用的CTI伺服器跟蹤,可能會換行)
Opctest是用於調試PG上的OPC進程的命令列工具。
用法:opctest /cust <客戶名稱> /node <節點>
opctest /cust ipcc /node pg1a
有用的設定
debug /agent(開啟代理事件跟蹤)
debug /routing(開啟路由事件跟蹤)
debug /cstacer(啟用csta事件跟蹤)
debug /tpmsg(啟用第三方呼叫請求跟蹤)
Rttest是一個命令列介面工具,用於調試ICM上的路由器進程。有關GUI版本,請參閱rtrtrace。
用法:rttest /cust ipcc
用於更改路由器登錄檔設定的GUI工具。
有一個選項可以將設定恢復為預設值。
用於開啟ICM上的各種路由器跟蹤的GUI工具。
對IPCC特別有用的設定包括:
排隊 — 用於問題排隊。
服務控制 — 針對VRU介面問題。
轉換路由 — 用於解決轉換路由問題。
將Cisco ICM二進位制檔案轉儲到文本檔案。將目錄更改為進程日誌檔案目錄。
OPC、PIM和JtapiGW進程日誌檔案駐留在icr\<customer_name>\<node>\logfiles\中。
在PG上,有一個名為cdlog的批處理檔案,您可以在其中鍵入>cdlog <cust> <node>。
用法:dumplog進程名稱
Dumplog /"(獲取有關不同dumplog選項的幫助)
Dumplog jgw1
Dumplog pim1
Dumplog opc
用於檢視VRU PG捕獲檔案的工具。類似於dumplog的工作。
可用於調試路由指令碼的Cisco ICM工具。 您可以在AW上的AW選單項中找到此工具。
這是一個在IP IVR上為JTAPI客戶端開啟JTAPI跟蹤的工具。IPCC PG上的JTAPI跟蹤通過procmon介面控制。此工具駐留在program files\CiscoJtapiTools\中。
Microsoft Windows 2000管理工具,顯示Cisco CallManager、Cisco IP IVR和ICM的即時資料。您可以檢視正在進行的呼叫、已註冊裝置和進程CPU利用率。您可以在開始>程式 > 管理工具下找到此工具。
思科ICM日誌檔案位於\icr\<cust>\<node>\logfiles中。此處,customer引用客戶例項名稱,而node引用了路由器、cg1a等的pg1a、ra。使用dumplog檢視日誌檔案。
注意:您可以使用跟蹤工具(如vrutrace)檢視事件捕獲檔案。這些檔案位於不同的目錄中。
Cisco CallManager日誌檔案通常位於\program files\cisco\ccm\trace中,跟蹤目錄為:
Ccm - CallManager SDI日誌。
Dbl — 資料庫層日誌。
Sdl — 呼叫信令日誌。
Tftp - tftp伺服器的日誌。
您可以在Cisco CallManager admin頁面的trace settings下修改這些檔案的跟蹤設定。您可以在Cisco CallManager的服務引數下修改SDL跟蹤設定。
IP IVR日誌檔案位於\program files\wfavvid。您還可以從appadmin頁面的engine-trace files下檢視IPIVR日誌檔案。
使用jtprefs.exe開啟JTAPI事件並重新啟動IP IVR引擎時,您可以檢視Cisco JTAPI客戶端日誌。
收集資料以提交案件時,除了收集日誌檔案外,還要收集本節中列出的資料。
已配置的代理數量是多少?
配置了多少個網關?
Cisco CallManager、JTAPI Client、ICM、網關IOS版本和IP IVR。
您可以在Cisco CallManager管理員網頁的Help > About > Details下找到Cisco CallManager版本。
要查詢JTAPI客戶端版本,只需在Cisco CallManager PG上的\winnt\java\lib目錄中的命令提示符中鍵入jview CiscoJtapiVersion。
您還可以找到IP IVR版本。
正在使用哪種IVR?
正在使用哪些型別的平台/ CPU /和實體記憶體量。
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
21-May-2002 |
初始版本 |