排除故障与JTAPI错误和精良桌面洛金问题涉及的CAD

简介

当桌面登录失效由于Java Telephony API (JTAPI)问题时，本文描述可能的原因和他们的解决方法。

背景信息

这些错误消息被看到，当登录Cisco代理桌面(CAD)和精良，如这些镜像所显示时

.。

在CAD的错误消息

 在精良的错误消息

这些是遇到在CAD/Finesse的桌面登录期间，并且有此的多个原因的多数常见错误。

原因和应急方案

1. 电话的MAC没有关联与RMCM CUCM的应用程序用户

IP Contact Center (IPCC)分机位于电话的MAC地址必须选择在资源管理器联络管理器软件(RMCM)应用程序用户的受控的设备下。

解决方法：连结MAC地址与RMCM应用程序用户。在Cisco Unified Communications Manager (CUCM)，请导航给用户管理>应用程序用户

如果电话的MAC已经关联，然后

1. 取消关联MAC。
2. 点击“Save”。
3. 重新关联MAC。
4. 点击“Save”。

.。 您能也设法终止然后开始在所有JTAPI供应商的思科计算机电话集成(CTI)管理器服务。

2. Extension Mobility (EM)配置文件没有关联与RMCM用户

如果与CUCM 8.0或以上一起使用EM，请关联设备配置文件而不是设备的MAC与RMCM应用程序用户。

不考虑设备配置文件，您连结应用程序用户与，设置在CUCM的簇内部多个洛金行为Extension Mobility服务参数为自动注销。

此操作帮助解决在方案注意的CTI/JTAPI的设计限制，发生，当簇内部多个洛金行为Extension Mobility服务参数设置为允许时的多登录。

• 代理程序登录EM在电话并且登陆对CAD。

• 如果电话从CUCM未注册，而代理程序仍然是登录的EM，电话不重新登记。此疏忽注册可能发生，当代理程序关闭电话时，无需记录在EM外面或，当网络被切断时。

• 代理程序登录从一个不同的设备的EM。

• 当代理程序尝试登录到CAD时，系统显示错误消息-登录失败由于一个配置错误用您的电话和JTAPI或者Unified CM。与您的管理员联系。
  

bug CSCtx48427描述此限制。

3. 与EM的记录的配置文件

如果CAD代理程序使用Extension Mobility，如此镜像所显示，设备配置文件有与自动呼叫启用的记录选项的目录号，能导致登录问题。

这发生，因为Cisco Unified Contact Center Express (UCCX)没有发送deviceUnregisteredEvent消息，当EM注销发生时。此问题在CUCM版本发生在9.X之前。

Bug CSCty63105和CSCty63127描述这些限制。

没有适当的应急方案对此问题，但是重置电话设备在登陆以后对EM知道在某些情况下工作。然而，这断断续续。

您能也尝试 

1. 禁用记录选项
2. 从目录号(DN)删除录音配置文件
3. 重置电话

永久的修正是升级CUCM对有已经被解决的Bug的版本。

4. 共享线路

IPCC分机不应该是共享线路。

您能检查CUCM由去的呼叫路由>路由计划报告。请确保IPCC分机是唯一。请参阅下面镜像，那里应该在没有DN的其他实例。

并且IPCC分机不能是搜索组的一部分。

5. IPCC分机必须在前4条线路

IPCC分机必须在代理程序设备的前4条线路。假设这些线路没有共享， UCCX允许超过在代理程序设备，但是监视器将配置的4条线路仅前四条线路。

6. 允许从 CTI 控制设备

保证如此imahe所显示，允许设备控制从CTI复选框的被检查IPCC分机，电话和在最终用户。如果它已经关联，请尝试不选定和检查它回到。

7. RMCM角色

RMCM应用程序用户应该安排组英文虎报CTI启用，并且，如果使用SIP电话，英文虎报CTI允许支持已连接Xfer和Conf的电话控制。

8. 常见设备配置配置文件有启用的IPV6

如果座席电话有常见设备配置配置文件分配到它，请保证IP寻址模式字段有IPV4只分配到它。要检查CUCM，请导航对设备>设备设置>常见设备配置。

9. 在正在初始化滞留的么RmCm子系统

当么RmCm子系统在正在初始化被滞留，当打开CAD应用程序，您时时获得初始化失败，请重新启动应用程序错误。

如果CAD已经是开放的，并且输入凭证登陆，您获得登录失败由于一个配置错误用您的电话和JTAPI或者Unified CM。请与您的管理员错误联系。

要检查，请导航给Cisco Unified CCX维护性> Tools>网络服务> Cisco Unified CCX引擎>子系统管理器。

RMCM是在负责对监控代理程序状态和对选择根据代理程序的代理程序的UCCX内的一个子系统？s技能和要求的队列技能。

必要的操作被采取带来RMCM上一步在使用中：

•  如果么RmCm子系统在初始化状态被滞留在任何一个节点，然后

          1.禁用CDS/HDS

           2. 重置复制

           3. 启用CDS/HDS。

• 重置在UCCX的RMCM用户密码，保存它并且重新启动UCCX引擎。如果它？s HA，重新启动在两节点的引擎。

•  创建一个新的RMCM供应商用户。创建UCCX的用户传播它对CUCM。

• 在UCCX版本9.0.1， 9.0.2.10000-71 (9.0.2基础)和9.0.2.11001-24 (9.0.2 SU1) RMCM在初始化状态被滞留JMX日志是否全双工。

检查磁盘登录是否通过运行show status命令是全双工在受影响的服务器的CLI。

 admin:show status 

 Host Name    : pub9 
 Date              : Wed May 13, 2015 07:14:53 
 Time Zone      : India Standard Time (Asia/Kolkata) 
 Locale            : en_US.UTF-8 
 Product Ver  : 9.0.2.11001-24 
 OS Ver       : 5.0.0.0-2 
 License MAC  : 0183a27e0bc7 

 Uptime: 
  07:14:54 up 3 days, 21:35,  1 user,  load average: 0.74, 0.81, 0.67 

 CPU Idle:   88.12%  System:   00.00%    User:   09.90% 
   IOWAIT:   01.98%     IRQ:   00.00%    Soft:   00.00%   Intr/sec: 263.37 

 Memory Total:        6097316K 
         Free:        2412372K 
         Used:        3684944K 
       Cached:        1990132K 
       Shared:              0K 
      Buffers:         297104K 

                       Total         Free               Used 
 Disk/active         26657340K       15888436K       10493712K (40%) 
 Disk/inactive       27087452K       18957564K        7854696K (30%) 
Disk/logging        92738892K       40350056K       47601872K (100%) 
 

Bug CSCul18667和CSCun54915描述此行为。

在theJMX日志根据缺陷CSCul18667后删除，您需要与技术支持中心(TAC)联系执行缺陷CSCun54915的应急方案必须。如果CSCun54915应急方案然后没有被执行，在服务器重新启动， UCCX引擎不后出现。

•  如果是在CCX 8.5 SU1以下， RMCM可以在初始化状态被滞留，当代理程序没有创建如表示由bug CSCtq84602时。

 您能总是重新启动在所有CUCM节点的CTI Manager。删除电话的Indentity托拉斯列表(ITL) /Certificate托拉斯列表(CTL)文件帮助。

如果上述应急方案不是有用的，请开TAC案例。