前言
平台对接科大机器人时候,需要机器人经过合成和识别的步骤,其中ivr系统和科大机器人交互流程如下:
内容
1.场景
1.机器人识别时候,有两种场景。1.边播音时候时候边识别 2.客户说话说完之后再识别
1.查看ivr和CRS的动态流程
2.一种是纯播音不识别 一种是播放过程中同时识别 如果客户说话 会停掉播音
有 看日志就知道了
看dyflow01的日志
如果是100 就只是播音 不识别
如果是110 就是播音同时识别
如果是010 就是只识别 不放音
你做测试的时候 可以每次重启一下dyflow 这样每通电话都可以产生一个日志
再对照日志看指令 很容易看的
2.wireshake抓包
将流程多过几次 每次都抓一下包
然后用wireshark看一下语音流有没有送过去
记几个指令就行
每个电话抓一次包
tcpdump -w 文件名
比如 tcpdump -w aaa.cap
然后将cap文件拷贝到本地用wireshark打开
图形化就看这个
里面
84是tts 86是asr
通话期间的 选这几个按钮就能听到语音
说明我们送过去了
抓取sip包,去除rtp包:
1.1 边播音时候时候边识别
1.2 客户说话说完之后再识别
3.ipcc活动管理
1.活动暂停(event_state=0)时候ipcc从缓存中移除event并设置状态为-1,此时活动就可以启用了(event_state=1) 此时ipcc会加载活动到内存中,所以我们需要改变活动数据时候,我们需要在event_state=-1时候进行修改,然后再启用活动。
2.活动加载到内存时候,会把活动的策略通过sql读取出来,我们在dbg_dbg01_xxxx.log中可以看到
3.活动在内存中名单少于5000条时候,会大概每个10s扫描一次活动下面的名单
4.基于2,3我们从我们在dbg_dbg01_xxxx.log中可以看到读取活动策略的sql就很少此,而读取活动的名单就很多次
4.ipcc将fsg两个日志级别调到6
在cc/cfg目录下:
1.查看
2.修改fsg.cfg:vi fsg.cfg
3.修改dyflow:vi dyflow.cfg
3.启动
5.mysql
mysql优化:https://blog.csdn.net/afsvsv/article/details/84998119
6.平台任务中名单未拨打
问题:平台任务中名单未拨打
问题排查:
1.查看cti_cdr中拨打记录(查看此表是最直观的,如果此表有记录,但是用户未接到,可能是线路等问题),如果此处没有呼叫记录,继续下看。
2.查看notify进程:ps -ef | grep /cc/bin.
3.dbg_dbg01_1550971499.log日志中:
a.任务加载正常:
1
SELECT event_id, tenant_id, a.queue_id, a.creater, a.max_line, a.caller, a.max_member_id, a.event_state,a.success_count,a.answer_count,a.failed_count,a.toacd_count, a.time_len,a.load_list_count,a.send_type,a.templet_id,a.event_level,a.drop_cause_tid FROM ocm_event a, cti_entinfo b WHERE a.tenant_id=b.id AND b.state=0 AND a.node_flow = '300' AND a.event_state IN(0, 1, 2, 5) AND a.send_time <= NOW() AND NOW() <= a.over_time AND a.send_type IN (1,2,3,4) ORDER BY a.event_id
b.任务工作日正常(ocm_event_strategy):
1
SELECT c.workday_type, date_format(c.start_time, '%Y-%m-%d %H:%i:%s') as st, date_format(c.end_time, '%Y-%m-%d %H:%i:%s') as et FROM ocm_event a, ocm_event_strategy b ,ocm_workday c WHERE a.event_id = 89 and a.event_id=b.event_id and b.strategy_id=c.workday_id and b.strategy_type=1 and c.is_work=0 and c.workday_type = 0 ORDER BY st
c.任务时间段正常(ocm_calltime_strategy):
12
SELECT c.calltime_id, c.start_call_time, c.end_call_time FROM ocm_event a, ocm_event_strategy b ,ocm_calltime_strategy c WHERE a.event_id = 89 and a.event_id=b.event_id and b.strategy_id=c.calltime_idand b.strategy_type=2 and c.is_work=0 ORDER BY c.start_call_time
d.查看拨打的名单是否加载到内存(ocm_buslist ):
1
SELECT b.list_id, b.customer_phone, b.cust_id,b.extend FROM ocm_buslist b WHERE b.event_id = 89 AND b.list_id > 0 ORDER BY b.list_id LIMIT 10000
4.查看企业状态(cti_entinfo)是否为0-启用
5.查看线路资源表(ocm_enti_exinfo)是否0-启用
6.如果上面都没有问题(ocm_buslist表数据已经加载了,任务表里面的memberid还没有更新等),就有可能是平台自身的问题,这些问题都不是简单的出现,而是经过多个批次数据呼叫时候可能出现。比如:maxline太小取整算法有问题。
7.平台-转人工失败查看
1.确保坐席能够嵌入
坐席不能够签入:坐席没有添加到队列中:cti_queue中是否有队列 cti_work_queue中是否加入坐席到队列中
2.ccos系统外拨模块
查看此批次和场景是否配置了选择了转人工,并选择了坐席队列
3.cti_outcaller表查看
点击坐席”上线”,如果坐席不能上线,查看以下表:cti_outcaller是否配置了此租户下的主叫:
如果没有配置,添加进去,然后重启一下acd服务,再试一下坐席是否可上线
4.查看除改坐席之外坐席是否可以上线
- 有时候,同一个坐席工号100001在多台pc端签入时候,导致此坐席不能上线,这个时候,用下100002能否签入。
- 有时候,如果我们的坐席不能签入,这个时候用软电话条demo试试
4.查看cc/logs下acd日志
acd_acd01.log日志:
a.查看坐席转台:r:getworkinfo workno=[888811],callstate[1]
b.查看坐席所在队列id:SELECT queueid FROM cti_work_queue WHERE workno = ‘888811’ AND entid = 1270
8.平台修改科大crs地址
8.1 dyflow修改
ipcc和crs系统对接时候,需要修改对接科大crs地址。在系统cfg目录下dyflow下:
重启dyflow
8.1 httpg修改
平台和crs是通过http协议进行交互,所有交互的都需要经过httpg模块的server
9.平台修改tts,asr地址
- tts以及asr对接是freeswitch模块和其对接的,所以我们需要修改freeswitch配置里面的信息。
- 修改tts和asr地址是在freeswitch模块修改
- 修改之后,我们需要让配置生效就需要重启freeswitch,fsg模块。
1.fs停止:进入:/usr/local/freeswitch/bin,执行如下指令:1./freeswitch -stop
2.fs启动:进入:/usr/local/freeswitch/bin,执行如下指令:
3.然后再 到/cc/bin下 ./fsg.sh restart
9.ivr流程制作
10.查看平台外呼的彩铃录音
freeswitch中开启录音命令:
freeswitch中停止录音命令(开启录音不叫文件目录):
1.进入/usr/local/freeswitch/bin目录下,客户端连接freeswitch
./fs_cli -P 8031 -p testtest
2.设置fs的日志级别为1
console loglevel 1
3.修改彩铃文件路径
4.拨打电话
5.在cc/log目录下下载生成的录音,并试听
11.一人多号码
11.1 主流程
- 针对于一个客户多个号码的情况,客户需求:1.呼叫平台未接通,重呼一次后还没有结果,就通知java应用导入数据到ocm_buslist(外呼名单表) 进行呼叫客户下一个号码 2.平台呼叫通,机器人判断不是本人时候就通知java应用导入数据到ocm_buslist(外呼名单表)进行呼叫客户下一个号码
- 主流程如下:
11.2 平台一人多号码排查
1.一般排查
1.任务表(ocm_event):drop_cause_tid的入口就是ocm_after_call_module中id,如果任务没有配置,则默认drop_cause_tid为-1,以下3表就相当于ivr流程中:cti_flow,cti_action,cti_rootflow
2.查看ocm_after_call_action对应的脚本是否是ivr中类型为http的action,并且对应的callback接口是否是
“主流程”中”临时数据导入”,如下实例:
3.在外呼任务中导入名单呼叫:ocm_after_call_module脚本执行是不会记录到dyflow中的,所以我们不用查看dyflow相关日志,只需要查看callnotify相关日志。
a.从callnotify_callnotify01中查看的是外呼的数据 写入到cti_cdr表中
b.由于平台通知java应用走的是ivr中action—-http 所以在httpghttpg01.log会有记录
4.如果在httpghttpg01.log中没有记录并且一人多号码时候,第一个号码没接听,但是没有调用拨打第二个号码,这个时候说嘛callnotify有问题,我们去callnotify01看日志:
发现脚本加载错误,我们去ocm_after_call_flow查看:
然后发现是ocm_after_call_action问题:
2.深度排查
1.查看notify.cfg中是否配置了httpg
2.查看callnotify_callnotify01xx.log中是否报错”no rootflow”
3.ocm_event的tid = ocm_after_call_module 的rootactid=ocm_after_call_flow表的 actid和preactid = ocm_after_call_action的id
ocm_after_call_param加一条默认记录
以event_id = 174 entid = 1278为例:
ocm_event
ocm_after_call_module
ocm_after_call_flow
ocm_after_call_action
ocm_after_call_param
3.一人多号码轮呼加上重呼(混合呼叫)
一人多号码中,
11.3 查看shell脚本是否执行成功
通过接口创建批次(营销管理系统)时候,我们任务已经启动,但是平台没有呼叫,查看dyflow日志看到对应的脚本:
1source /cc/bin/iniwrite.sh -w /cc/cfg/dyflow.cfg dyflow loadscript 1
已经执行
但是外呼任务加载的日志却没有执行:
1source /cc/bin/iniwrite.sh -w /cc/cfg/notify.cfg callnotify reloadocm 1
这个时候就得看脚本callnotify是否执行
步骤
1.执行重启callnotify命令:
2.postman接口创建新批次:数据如下:
123456789101112131415161718192021222324{"accountId": "1269","comcode": "3200","dataArr": [{"age": "","busNum": "苏EXM512","city": "","custId": "9140772385","id": "PIID201932000039214470","idcard": "321283198409297449","num": "15188317019","salesmanName": "","salesmanNum": "","sex": "","userName": "叶鑫明"}],"endDate": "2020-04-13","frequency": "3","key": "978f774acce1d5d20883bbba38d9bc21","outboundPeriods": [75],"startDate": "2019-04-10","taskName": "2019-04-10_叶鑫明","taskSceneId": "92"}
3.查看是否有执行日志输出(以下是有执行日志输出):
5.特殊情况
之前是营销系统通过接口创建批次 马上就可以呼叫 昨天一直不呼叫 只有重启任务才会呼叫 但是我刚刚通过营销系统创建了批次 发现bin终端打印出了上面的信息 但是批次不呼叫 批次也是默认开启的
解决:看下callnotify_callnotify01_xxxxx.log的日志 有没有出现iniwrite 如果没有 就说明你没修改reloadocm
如果在java应用执行后没有出现上面的日志:我们去/cc/bin目录下执行
此时去callnotify_callnotify01_xxxxx.log查看日志会有inwrite
今天我把notify.sh给stop了,然后执行java应用的Runtime调用
后面发现在notify.cfg里面的reloadocm结果还是0,这个时候就不能呼叫刚创建的批次。
12.外呼提示”系统忙”
外呼提示系统忙是因为家在的flow脚本有问题/或者脚本在呼叫客户之前没来得及加载,查看dyflow_dyflow01xxxx.log即可知道。如下:
在预测式外呼页面操作任务时候:先创建任务和对应的ivr流程脚本(cti_flow,cti_action),导入名单数据,然后我们通过启动任务时候,发现这个时候拨打的数据报错:”系统忙”,原因是因为此时执行脚本:
1
ShellUtil.excute("source /cc/bin/iniwrite.sh -w /cc/cfg/dyflow.cfg dyflow reloadocm 1");
还没有加载时候,就已经拨打了电话。
我们需要在任务创建时候就执行上面脚本。
13.修改流程超时时间sessiontimeout
- 武汉数据呼叫时候,出现几千秒才会挂机的拨打,查看数据库时候,是如下:
- 以上原因是超时未挂机,我们可以设置超时时间来在短时间内挂机(sessiontimeout)。
notify.cfg设置为:10s拨打电话 10s不接听后会自己挂机
dyflow.cfg设置为:10s拨打电话 10s后接听后会自己挂机
14.平台升级
呼叫平台升级时候,我们需要进入平台的lib目录 把测试环境下的lib里面的包 拷贝到 生产环境 如下:
判断升级成功没:
重启后 灌入一条名单进去 导入名单成功的时候才会有日志 查下 callnotify01的日志 loadbeginid 找到这个字样 就升级对了
019-04-28 17:54:17.700 TDbOpt.dbDoSql ok, h=[375015], sql=[select b.list_id,,loadbeginid[3464456],_loadmaxid[3465458] 但确实有3条是在里面的啊
15.平台测试环境下进行呼叫数据测试
平台外呼号码为:5开头的8位数字的号码 拨打时候是不会计费的 可当做测试数据使用
如:80000001 80000002
16.-200问题
- -200 你将sessiontime设置短一点就有了
- 已接听,只看200或者-200或者0不行 还要判断connect is not null
- 所以我们有时候不接听电话,电话主动挂机超时,有可能出现下面问题。
- 出现上面问题的原因如下:
17.系统变量
|
|
18.平台搭建
0.安装前准备
a.查看linux版本:(针对于不同版本,安装不同freeswitch)
cat /etc/redhat-release 查看CentOS版本
b.安装数据库时候确保yum源可用
执行:yum install mysql 出现下面错误:
linux服务器的yum源配置:https://blog.csdn.net/qq_21277477/article/details/82220139123wget http://mirrors.aliyun.com/repo/Centos-7.repo//上传至/etc/yum.repo.d/目录下mv Centos-7.repo Centos-Base.repo
c.出现不能写文件时候执行如下操作:
搭建平台之前我们需要安装数据库:
https://www.cnblogs.com/freely/p/8087885.html
我们有时候需要搭建新的平台环境,常见的方法是从其他环境上整理数据,然后拷贝数据到新的环境下。
|
|
1、压缩文件:cc下面除了log、data两个别压,其他都压。data里面的 全程录音别压、压缩后文件如下(大概900M):
2、解压文件
tar -zxvf cc.tar.z3、添加环境变量并启用:编辑/etc/profile 在最后加入下面一行
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/cc/cclib
生效:
source /etc/profile
- 4、软链接fs:
ln -s /cc/freeswitch /usr/local/freeswitch
- 5、修改vars.xml internal.xml external.xml的地址,启动freeswitch验证fs启动错误提示(正常的话除了提示数据库yccc连接有问题,其它正常)
进入freeswitch/conf文件夹里面:
vars.xml里面配置的是:
修改本服务器提供的外部访问地址及域名:
进入freeswitch/conf/sip_profiles修改internal.xml external.xml
internal.xml修改外部提供的sip和rtp访问地址;
external.xml修改rtp.sip地址:
修改freeswitch连接数据库:freeswitch/scripts/user.lua
修改ipcc呼叫数据源配置:
将acd.cfg、dyflow.cfg、notify.cfg,fsg.cfg、dialout.cfg文件里面数据库用户密码改一下
6、安装数据库(在数据库服务器上装、一定要安装配置日志,避免数据丢失)、odbc并配置、先配置数据库试试 (数据库导入脚本 数据库脚本找小叶要一份最新的)
mysql-odbc驱动安装:1yum install mysql-connector-odbc
修改或创建文件:/etc/odbc.ini,内容如下:
1234567891011121314
[yccc]Description = MySQL test databaseTrace = OffTraceFile = stderrDriver = MySQLSERVER = 127.0.0.1USER = rootPASSWORD = 123456PORT = 3306DATABASE = callcentercharset = UTF8OPTION = 67108864Threading = 0
配置是否成功,执行以下指令:
1
isql yccc
如果连接失败、查看一下地方:
连接失败首先查看下:isql -v yccc
从其他服务器拷贝:
scp root@172.31.185.112:/usr/lib64/libmyodbc* .
a./etc/odbc.ini(内网访问尽量用127.0.0.1、127不用寻找路由)
b./etc/odbcinst.ini
c.连接成功的情况
/etc/odbc.ini
7、安装gdb yum install gdb (不是必须) 安装gc++: yum install gcc++
8、配置jdk 1.8环境 JAVA_HOME CLASSPATH等
1)执行:vi /etc/profile 在文件末尾添加
export JAVA_HOME=/cc/jdk1.8/jdk1.8.0_141
export JRE_HOME=$JAVA_HOME/jre
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib
export PATH=$JAVA_HOME/bin:$PATH2)使配置生效:source /etc/profile
3)执行java -version 确认配置生效9.修改ag.cfg里面的sidhead前缀、这个是用于表示区分集群每个节点数据、将ag重启一下、这样数据就不重复了 将来合库cdr不会有重复。
9.dyflow启动失败解决方案:
- 1.配置core
参照qa那个文档配置core
一、在/etc/profile中加入:
ulimit -c unlimited
二、在/etc/rc.local中加入:
echo “/cc/log/coredump.%e.%p” > /proc/sys/kernel/core_pattern
- 2.查看core
cc/log下,有没core开头的文件
linux下core dump
ICE实战
https://www.cnblogs.com/SGSoft/archive/2007/05/02/734775.html
https://blog.csdn.net/qiunian144084/article/details/80654443
https://blog.csdn.net/god_wot/article/details/50332997/
https://blog.csdn.net/xuzheng_java/article/details/24459181
http://www.blogjava.net/paulwong/archive/2015/11/13/428186.html
https://wenku.baidu.com/view/f80f910bba1aa8114431d9e7.html