3.4CTI+UAP3300网呼流程失败问题分析报告

发布时间:  2014-07-17 浏览次数:  150 下载次数:  0
问题描述
XX局点全国呼叫中心网呼IVR功能测试,发现从A局点网呼B局点成功,A局点网呼C局点失败
CTI:C01B072SPC006
UAP:V100R001C05B05cSPC002
2.1 5月10号日志分析
检查了安徽、湖南、湖北三个中心的平台配置,以及网呼配置,没有发现问题。
跟踪icddebug消息,从NIRC的icddebug中20616号消息看到湖北中心上报给NIRC的流程状态经常是占用率100%,而湖南中心上报给NIRC的流程占用率是0%。导致网呼到湖北中心流程的时候会路由失败。


检查代码我们可以发现,CCS会定时一秒钟向登陆的IVR进行状态的查询,如果500毫秒内没有收到IVR的回音,就会把此设备使用占有率设置为100%。通过对比湖南和湖北的icddebug发现,湖南中心每次查询两个ivr都是立马应答,但湖北中心CCS查询的时候,很多时候要发好几次后才能收到ivr的侧反馈的状态上报,且一有上报就是两个2个ivr同时上报。
湖北的:


湖南的:


但是从湖北的ivr侧看,只要ivr收到了,ivr就会很返回,且从收到的情况看,它并不是1秒收到一次,也就是CCS发查询,很多时候ivr并没有收到,下面这个就隔了5秒才收到一个请求。

但后又通过在湖北部署IVR侧进行网络抓包,从抓包数据看,从网卡层看,CCS发的查询监控请求已收到,但是从IVR应用层没有收到这个数据,从icddebug消息码流看并没有延迟的情况,只要有消息就立马处理,并不存在中间有阻塞情况。
2.2 5月19号日志分析
通过今天新获取的ICDDEBUG日志分析,发现在海南上面经常出现CCS向IVR定时查询监控时,只有一个IVR有响应结果,这个IVR经过查看数据发现是新部署上去的IVR,因此可以得出原因为环境问题,具体和原因需要等待现场日志后进行分析。

2.3 5月20号日志分析
今天收集了湖北等地的CTI版本及信息,通过对比湖北,湖南、广西的信息进行对比,如下:
局点 状态 组件 服务端版本 IVR端版本

      从对比结果看,成功的局点中byteorder.dll的服务端和客户端的版本都是一致的,结合在CCS上面部署IVR也能正常,该情况byteorder.dll版本也是一致的。
2.4 5月21号日志分析
今天收集了贵州等等地的CTI版本及信息,通过对比湖北,湖南、广西, 贵州,山西,海南的信息进行对比,出现问题点IVR服务器版本基本都是spc001, 且基本都是跟服务器版本不匹配的。
    
告警信息
处理过程
替换了湖北ivr服务器302的ctiapi,byteorder,ivr保持跟服务器版本保持一致,都为spc006后,ivr不能上报监控信息问题得到解决。
根因
服务端的版本和IVR客户端的版本不一致导致,监控使用率消息返回异常。
建议与总结
方案一:每个局点将服务器和IVR及其他客户端软件版本保持一致
方案二:将每个局点的版本统一升级到SPC006或者更高版本
日常维护针对这种时间比较长的局点,需要将相关细节版本信息总结汇总,进行版本匹配。

END