本文档提供有关排除Internet协议联系中心(IPCC)故障的信息,该中心侧重于外围网关(PG)和思科智能联系管理(ICM)。 尽管本文档包含有关Cisco CallManager和Cisco Global Directory的常见问题的一些信息,但本文档并未尝试完全描述这些组件。相反,本文档重点介绍故障症状和方法,以确定PG发现的问题的根源。 问题可能与软件或配置有关。
Cisco 建议您了解以下主题:
如何排除故障并支持Cisco ICM PG
本文档中的信息基于以下软件和硬件版本:
Cisco ICM 4.6.2版
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。
有关文档规则的详细信息,请参阅 Cisco 技术提示规则。
查看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动态数据下的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)是否作为路由器上的设备启用。
通过设置或在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 key目录下的值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时看到类似第二条消息的内容,请验证Cisco JTAPI客户端是否已安装在PG上。在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文件视为类路径的目录。为避免此问题,请在运行安装程序之前关闭所有浏览器会话。 如果安装程序无法更新文件,则会显示一条消息,并指示您重新启动电脑以更新文件。你必须重新启动。
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并在“编辑外围设备”对话框中更改名称。
对getProvider()的调用的跟踪还显示使用的登录名。请注意,跟踪不显示密码。登录名和密码取自管理员在ICM > Setup下输入的内容。这些必须与目录中配置并在Cisco用户首选项网页中管理的有效用户和密码匹配,才能控制每个代理设备和路由points。检查以确保名称和口令在ICM > Setup中正确。将目录中的用户配置为仅具有控制有效座席设备和路由点的权限。
JTAPI GW进程无法解析Cisco CallManager的地址。在Setup(设置)的PIM对话框中,使用Cisco CallManager主机名或IP地址配置服务参数。如果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目录管理。使用用户目录管理器登录,密码为“cisco cisco”(默认)或管理员配置的任何密码。如果收到错误,表明用户未配置,请在DCDSrvr\bin目录中运行一个Cisco AVVID配置文件。如果这是主Cisco CallManager, Publisher,请从DOS提示符运行avvid_cfg.cmd。如果这是辅助Cisco CallManager,请从命令提示符运行avvid_scfg.cmd。
如果您看到错误表明已配置,则用户确实存在。如果没有错误,则必须立即开始正常工作。返回并检查ccmadmin上“全局目录用户”页面的访问。
注意:如果DC目录在系统资源不足时,该目录将进入暂停模式。
本示例对设备目标使用ICM配置示例:
设备目标示例 | |
企业名称 | Agent9782755100 |
全局地址 | Agent9782755100 |
配置参数 | /devtype CiscoPhone /dn 9782755100 |
下一个示例为座席使用ICM配置示例:
代理示例 | |
外围设备 | CCMPG_PIM1 |
外围设备号 | 1234 |
密码 | 3911、3951、69XX 系列和 894X <tag></tag><tag></tag>电话通过根据配置文件中的以下部分下载 tzdatacsv.csv 文件来更新 tzdata 信息: |
当为PG运行ICM > Setup时,您将指定座席分机长度“4”。 因此,在示例配置中,示例设备的分机号是/dn参数(例如,“5100”)的最后4位。
尝试使用CTITest登录。
如果无法使用软电话登录座席,请通过ctitest尝试相同的操作。以下是可用于将示例代理登录到示例设备目标的ctitest命令的示例列表。此命令列表假设CTI服务器在计算机CTIServerA的端口42027上侦听。此列表还假定设备是表示为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 — 此值必须与“配置”>“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网关组件。验证是否未选中“需要代理登录”复选框。此复选框选择不适用于IPCC或任何第三方控制应用。此复选框的用途是监控应用其他ACD座席。
使用procmon对pim和“trace tp*”启用第三方跟踪(区分大小写)。 这必须显示登录请求。检验参数是否正确。该仪器被跟踪为“Device=”。 此值必须与设备目标configparam中的/dn字符串匹配。代理ID被跟踪为“AgentID=”。 此值必须与“配置/ICM”中的座席外围设备号匹配。
INVALID_PASSWORD
确保密码正确(密码不能以明文形式跟踪)。 如果密码不正确,日志必须显示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登录的用户关联。确保Global Directory用户设备关联列表远端的分机正确。另请确保设备线路号未注册两次。共享线路外观是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)。
当您连接到PIM并运行dagent <代理外围设备号>时,也可以检查此情况。
确保设备目标(如仪器所指定)没有其他座席登录。
检查此情况的一种方法是对awdb中的Agent_Real_Time表运行isqlw。首先,查找相关设备目标的网络目标ID。例如,从Device_Target中选择*,其中ConfigParam与“%1003%”类似。现在,查看设备目标是否已登录。例如,从Agent_Real_Time中选择*,其中NetworkTargetID = XXX。
当连接到PIM并转储设备目标时,您也可以检查此情况。有两种方法可转储设备目标。ddt命令将网络目标ID用作输入并转储设备目标。deadt 命令将设备目标配置中的/dn字符串作为输入并转储设备目标。例如,如果设备目标/dn字符串为/dn 9782755100,则将设备目标转储为deadt 9782755100。
转到Cisco CallManager网页,选择用户/全局目录并查找PG使用的用户ID。检查“关联设备”,并确保用户具有控制设备的权限。
如果在用户页面上找不到设备(选中或取消选中),则数据库(其中Cisco CallManager存储设备)和目录服务器(存储设备和存储用户配置文件)之间的同步可能存在问题。 检查目录服务器(DC目录服务器)是否运行。
检查Windows NT事件查看器应用程序日志并从DC目录或metalink中查找错误。如果出现导入错误,请从c:\dcdsrvr\bin运行avvid_recfg。
确保Cisco CallManager计算机上已安装Microsoft Java Virtual Machine(JVM)。要测试此操作,请在命令提示符下键入jview。对于Cisco CallManager 2.4,必须手动安装JVM。对于Cisco CallManager 3,平台是Windows 2000,JVM安装是自动的。
检查电话是否已通电、已注册到Cisco CallManager,以及是否能够在没有座席控制的情况下从电话发出和接收呼叫。
确保座席已登录,且未处于“可用”状态。 如果座席不可用,则座席无法进行呼叫。要发出呼叫,请首先单击“未就绪”。
如果仅当您拨打某些号码时出现错误,请从物理电话检查这些号码以确保您能够成功拨入。如果已配置ICM拨号号码计划,请检查您拨打的号码是否与您拨打的号码计划中的某个通配符匹配。然后检查座席的座席桌面设置是否允许座席拨打被叫号码计划条目标识的号码类型(例如,国际)。
为每个PIM配置的拨号号码计划可能配置不正确或配置正确,以阻止座席呼出某个号码。PIM日志中的错误必须表示权限错误。当拨号号码计划用于进行座席到座席呼叫时,座席和设备的号码不能重叠。
当座席发出呼叫或呼叫路由到座席时,路由器会使座席不可用。此机制允许路由器在PIM报告呼叫到达之前将另一个呼叫路由到代理。某些网络实际路由呼叫需要几秒钟。路由器不会根据代理状态取消计时器。
如果从路由客户端将呼叫路由到PIM的实际时间相对较短,则可以更改路由器中的可配置时间。在DOS命令窗口的其中一台路由器上,使用rtsetting.exe。在“外推”>“代理”下查找。默认设置为 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。在“外推”>“代理”下查找。默认时间为 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上代理的状态。如果重新启动座席桌面,并且条件不清除,则可以采取更多措施。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路由客户端上无用,必须设置为“否”。
检验路由请求端上配置的标签。您必须在每个客户端上配置标签,即使每个客户端上的标签相同。
要使用后路由,您必须在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在无需重新启动的情况下无法识别这些线路。如果为每个拨叫号码而不是现有设备添加新线路,则必须能够避免重新启动。
注意:这假定在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代理为目标,则必须为每个目标设备目标的路由后客户端配置标签。
检查路由器日志中是否有错误。如果没有:
如果队列节点队列到基本优先级,则当代理变为可用时,不会发生任何情况。有两种方法可解决此问题:
路由器注册表设置称为AutoLoginBase(使用rtsetting.exe)。 更改此设置,允许将呼叫排入基本技能组的队列,以使呼叫按预期工作。发生此类排队时,没有优先于主要技能的倾向。
显式排队到队列节点中的主要和/或辅助技能集。
为有问题的设备目标以及此路由客户端可以路由到的所有其他目标配置标签。使用AW批量配置工具可以更高效地完成ICR配置。
必须无条件地跟踪路由错误。
您可以使用call tracer工具测试路由路径。
使用rtrtrace打开路由请求跟踪,并在呼叫到路由点时检查路由器日志中的错误。
确保配置了所有必需的标签。如果路由脚本以IPCC/EA代理为目标,则必须为每个目标设备目标配置标签。每个设备目标必须为尝试发送呼叫的每个路由客户端配置标签。因此,如果呼叫从网络直接路由到可用代理,则网络路由客户端必须具有关联设备目标的标签。如果呼叫首先在VRU排队,然后被传送到代理,则VRU路由客户端必须具有关联设备目标的标签。
确保在Configuration Manager/PG Explorer的Routing Client选项卡中未选中Use DN/Label map。
使用procmon在PIM中启用跟踪(trace precall、trace *call_event*)并检查日志。路由器上会显示呼叫前消息。您还会看到“DevTgDevStr”设置为座席分机的“DeliveredEvent”。如果呼叫未显示,请确保路由客户端的标签正确。
IPCC不支持将呼叫置于保留状态并进行新呼叫的选项,因为Cisco CallManager提供的结果不一致。这被视为产品增强功能,可以考虑在将来的版本中使用。
当咨询呼叫被切换/交替/保持/检索时,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)座席桌面设置”中的“数据”。Required with Data将取代自动可用选项。
查看JTAPI GW日志,查看是否存在任何错误来指示查询传输失败的原因。检查代理软件是否允许在咨询呼叫上执行保留/检索或备用操作。当保留/检索任一呼叫时,该呼叫不再被视为咨询呼叫,而是由Cisco CallManager进行的“任意”转接。Cisco CallManager在任意传输方面存在问题。在咨询呼叫中限制用户重新连接或完成转接。
当会议未完成时,Cisco CallManager当前存在与会议发起的咨询的断开事件有关的问题。再次断开呼叫以清除座席电话上的呼叫外观。
首先,监控活动脚本。然后检查路由客户端和VRU的路由器、OPC和PIM日志。大多数错误都是无条件跟踪的,但您可以打开跟踪以更好地了解发生的情况。
以下是转换路由序列:
路由客户端向路由器发出新的呼叫请求。
路由器返回到路由客户端的连接,该连接带有必须将呼叫传送到IVR的标签。
IVR必须发送请求指令,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 files网页下的MIVR日志。
IVR CTI端口和CTI路由点在Cisco CallManager、IVR和ICM中配置。
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上启用Cisco Jtapi日志,并启用jtprefs。请参阅调试工具。打开跟踪后停止并启动IP IVR引擎。
验证IP IVR JTAPI转换路由端口组上的CTI端口组号是否与ICM中中继组配置中的外围设备号匹配。
检查引擎跟踪文件下的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 PG中,在VRU中实施的呼叫被计为排队,而不是连接。当呼叫被路由时,它们被报告为已应答。当队列中的客户断开呼叫时,这些呼叫将报告为已放弃。有关详细信息,请参阅热修复程序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个呼叫,请在OPC、PIM和JTAPI GW中根据CSTA、PIM、代理和第三方事件的需要打开跟踪设置。有关说明,请参阅本文档的“工具”部分。
记录呼叫流程:
Cisco CallManager PG或VRU PG上的初始后路由是否?
是否在未配置应答(FONA)时转发,以及FONA配置为重定向什么?
默认技能组是否配置了外围设备号码0以将路由呼叫与非路由呼叫和出站呼叫分离开来?
使用“select *”语句从这些表中获取一天的历史数据:
Peripheral_Half_Hour
Call_Type_Half_Hour
Service_Half_Hour
Skill_Group_Half_Hour
Termination_Call_Detail
Route_Call_Detail
在Cisco CallManager中收集跟踪时,可以在“服务”>“跟踪标志”下的“Cisco CallManager管理员”页面中打开标志。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中 — 在“系统”>“服务器”下更改IP地址。
在“系统”(System)>“企业参数”(Enterprise Parameters)下更改URL中的IP地址(IP Address in URL)。
在“功能”>“电话服务”下更改所有URL中的IP地址。
更改服务器IP地址 — 网络属性。
将DHCP选项150更改为新IP地址。
在DC目录、Cisco CallManager > System Profile > Hoteling中更改酒店简档中的IP。
打开SQL Enterprise Manager。
在插件表中更改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(打开precall事件跟踪)
trace *event(开启座席和呼叫事件跟踪)
trace csta*(打开CSTA呼叫事件跟踪)
CTI服务器(使用procmon)
regset EMSTraceMask 0xf8(打开有用的CTI服务器跟踪,可能绕过)
Opctest是用于在PG上调试OPC进程的命令行工具。
用法:opctest /cust <customer name> /node <node>
opctest /cust ipcc /node pg1a
有用设置
debug /agent(打开代理事件跟踪)
debug /routing(打开路由事件跟踪)
debug /cstacer(打开csta事件跟踪)
debug /tpmsg(打开第三方呼叫请求跟踪)
Rttest是用于调试ICM上的路由器进程的命令行界面工具。有关GUI版本,请参阅rtrtrace。
用法:rttest /cust ipcc
用于更改路由器注册表设置的GUI工具。
有一个选项可将设置设置恢复为默认值。
GUI工具,用于在ICM上打开各种路由器跟踪。
对IPCC特别有用的设置包括:
排队 — 用于问题排队。
服务控制 — VRU接口问题。
转换路由 — 用于转换路由问题。
将Cisco ICM二进制文件转储到文本文件。将目录更改为进程日志文件目录。
OPC、PIM和JtapiGW进程日志文件驻留在icr\<customer_name>\<node>\logfiles\中。
在PG上,有一个名为cdlog的批处理文件,您在其中键入>cdlog <cust> <node>。
用法:dumplog进程名称
Dumplog /"(有关不同转储选项的帮助)
Dumplog jgw1
Dumplog pim1
Dumplog opc
用于查看VRU PG捕获文件的工具。类似于dumplog。
可用于调试路由脚本的Cisco ICM工具。 您可以在AW的AW菜单项中找到此工具。
这是用于在IP IVR上为JTAPI客户端打开JTAPI跟踪的工具。IPCC PG上的JTAPI跟踪由procmon接口控制。此工具位于程序files\CiscoJtapiTools\中。
Microsoft Windows 2000管理工具,显示Cisco CallManager、Cisco IP IVR和ICM的实时数据。您可以看到正在进行的呼叫、已注册的设备和进程CPU利用率。您可以在“开始”>“程序”>“管理工具”下找到此工具。
Cisco ICM日志文件驻留在\icr\<cust>\<node>\logfiles中。在此,客户引用客户实例名称,节点引用pg1a、ra表示路由器、cg1a等。使用dumplog查看日志文件。
注意:您可以使用跟踪工具(如vrutrace)查看事件捕获文件。这些文件位于不同的目录中。
Cisco CallManager日志文件通常位于\program files\cisco\ccm\trace中,跟踪目录为:
Ccm - CallManager SDI日志。
Dbl — 数据库层日志。
SDL — 呼叫信令日志。
TFTP - TFTP服务器的日志。
您可以从Cisco CallManager管理员页面的跟踪设置下修改这些文件的跟踪设置。您可以在Cisco CallManager中的服务参数下修改SDL跟踪设置。
IP IVR日志文件驻留在\program files\wfavid中。您还可以从引擎跟踪文件下的appadmin页面查看IPIVR日志文件。
当您使用jtprefs.exe打开JTAPI事件并重新启动IP IVR引擎时,您可以查看Cisco JTAPI客户端日志。
当您收集数据以打开案例时,除了收集日志文件外,还收集本节中列出的数据。
配置的代理数是多少?
配置了多少个网关?
Cisco CallManager、JTAPI客户端、ICM、网关IOS版本和IP IVR。
您可以在Cisco CallManager管理员网页的“帮助”>“关于”>“详细信息”下找到Cisco CallManager版本。
要查找JTAPI客户端版本,只需在Cisco CallManager PG的目录\winnt\java\lib的命令提示符下键入jview CiscoJtapiVersion。
您还可以找到IP IVR版本。
使用的IVR类型是什么?
使用的平台类型/CPU/和物理内存量。