ipcc-5-ipcc对接科大机器

前言

平台对接科大机器人时候,需要机器人经过合成和识别的步骤，其中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
tcpdump -i eth0 port 14905 -w sip_20190515.cap

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):

1
2
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_id
and  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-启用

1
SELECT * FROM cti_entinfo WHERE id = 1269

5.查看线路资源表(ocm_enti_exinfo)是否0-启用

1
SELECT * FROM ocm_enti_exinfo WHERE entid = 1269

6.如果上面都没有问题(ocm_buslist表数据已经加载了,任务表里面的memberid还没有更新等),就有可能是平台自身的问题,这些问题都不是简单的出现,而是经过多个批次数据呼叫时候可能出现。比如:maxline太小取整算法有问题。

7.平台-转人工失败查看
1.确保坐席能够嵌入

坐席不能够签入:坐席没有添加到队列中:cti_queue中是否有队列 cti_work_queue中是否加入坐席到队列中

2.ccos系统外拨模块

查看此批次和场景是否配置了选择了转人工,并选择了坐席队列

3.cti_outcaller表查看

点击坐席”上线”,如果坐席不能上线,查看以下表:cti_outcaller是否配置了此租户下的主叫:

如果没有配置,添加进去,然后重启一下acd服务,再试一下坐席是否可上线

4.查看除改坐席之外坐席是否可以上线
  1. 有时候,同一个坐席工号100001在多台pc端签入时候,导致此坐席不能上线,这个时候,用下100002能否签入。
  2. 有时候,如果我们的坐席不能签入,这个时候用软电话条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地址
  1. tts以及asr对接是freeswitch模块和其对接的,所以我们需要修改freeswitch配置里面的信息。
  2. 修改tts和asr地址是在freeswitch模块修改

  3. 修改之后,我们需要让配置生效就需要重启freeswitch，fsg模块。
    1.fs停止:进入:/usr/local/freeswitch/bin,执行如下指令: 
    1
    ./freeswitch -stop


2.fs启动:进入:/usr/local/freeswitch/bin,执行如下指令:

1
./freeswitch -nc -nonat


3.然后再 到/cc/bin下 ./fsg.sh restart

9.ivr流程制作
10.查看平台外呼的彩铃录音

freeswitch中开启录音命令:

1
da2 record 文件目录

freeswitch中停止录音命令(开启录音不叫文件目录):

1
da2 record

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. 针对于一个客户多个号码的情况,客户需求:1.呼叫平台未接通,重呼一次后还没有结果,就通知java应用导入数据到ocm_buslist(外呼名单表) 进行呼叫客户下一个号码 2.平台呼叫通,机器人判断不是本人时候就通知java应用导入数据到ocm_buslist(外呼名单表)进行呼叫客户下一个号码
  2. 主流程如下:
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脚本是否执行成功

  1. 通过接口创建批次(营销管理系统)时候,我们任务已经启动,但是平台没有呼叫,查看dyflow日志看到对应的脚本:

    1
    source /cc/bin/iniwrite.sh -w /cc/cfg/dyflow.cfg dyflow loadscript 1

已经执行

  1. 但是外呼任务加载的日志却没有执行: 

    1
    source /cc/bin/iniwrite.sh -w /cc/cfg/notify.cfg callnotify reloadocm 1

这个时候就得看脚本callnotify是否执行

  1. 步骤
    1.执行重启callnotify命令:

    2.postman接口创建新批次:数据如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
       {
     "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调用

1
ShellUtil.excute("source /cc/bin/iniwrite.sh -w /cc/cfg/notify.cfg callnotify reloadocm 1");//这条指令相当于手动去修改notify.cfg中的参数reloadocm=1

后面发现在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
  1. 武汉数据呼叫时候,出现几千秒才会挂机的拨打,查看数据库时候,是如下:
  2. 以上原因是超时未挂机,我们可以设置超时时间来在短时间内挂机(sessiontimeout)。
    notify.cfg设置为:10s拨打电话 10s不接听后会自己挂机


    dyflow.cfg设置为:10s拨打电话 10s后接听后会自己挂机
14.平台升级

呼叫平台升级时候,我们需要进入平台的lib目录 把测试环境下的lib里面的包 拷贝到 生产环境 如下:

1
scp root@内网ip:/cc/lib/libT*so*  .

判断升级成功没:
重启后 灌入一条名单进去 导入名单成功的时候才会有日志 查下 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问题
  1. -200 你将sessiontime设置短一点就有了
  2. 已接听,只看200或者-200或者0不行 还要判断connect is not null
  3. 所以我们有时候不接听电话，电话主动挂机超时,有可能出现下面问题。
  4. 出现上面问题的原因如下:
17.系统变量
1
2
3
4
5
6
7
8
9
10
11
12
13
14
setSessionParam(index, "callid", sinfo.sid.substr(0, sinfo.sid.length() - 5), sinfo);
setSessionParam(index, "caller", sinfo.caller, sinfo);
setSessionParam(index, "called", sinfo.called, sinfo);
setSessionParam(index, "callop", sinfo.callop, sinfo);
setSessionParam(index, "dropcause", ::FunUtil::intToString(sinfo.dropcause), sinfo);
setSessionParam(index, "starttime", sinfo.iamtime, sinfo);
setSessionParam(index, "starttimesec", ::FunUtil::intToString(sinfo.iamtimestp), sinfo);
setSessionParam(index, "endtime",sinfo.reltime, sinfo);
setSessionParam(index, "anctime", sinfo.anctime, sinfo);
setSessionParam(index, "entid", ::FunUtil::intToString(sinfo.entid), sinfo);
setSessionParam(index, "notifyid", ::FunUtil::intToString(sinfo.vsTask.notifyid), sinfo);
setSessionParam(index, "memberid", ::FunUtil::intToString(sinfo.vsTask.memberid), sinfo);
setSessionParam(index, "userid", ::FunUtil::intToString(sinfo.vsTask.userid), sinfo);
setSessionParam(index, "extend", sinfo.vsTask.extinfo, sinfo);
18.平台搭建

  1. 0.安装前准备
    a.查看linux版本:(针对于不同版本,安装不同freeswitch)
    cat /etc/redhat-release 查看CentOS版本

    b.安装数据库时候确保yum源可用
    执行:yum install mysql 出现下面错误：

    linux服务器的yum源配置:https://blog.csdn.net/qq_21277477/article/details/82220139

    1
    2
    3
    wget 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
tar -zcvf cc.tar.gz /cc --exclude=/cc/log --exclude=/cc/data --exclude=/cc/freeswitch/bin/da_record  --exclude=/cc/bin/log  --exclude=/cc/apps  --exclude=/cc/tomcat-acdgate --exclude=/cc/tomcat-loglook

  1. 1、压缩文件:cc下面除了log、data两个别压，其他都压。data里面的 全程录音别压、压缩后文件如下(大概900M):

  2. 2、解压文件
    tar -zxvf cc.tar.z

  3. 3、添加环境变量并启用:编辑/etc/profile 在最后加入下面一行
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/cc/cclib

生效:
source /etc/profile

  1. 4、软链接fs:
    ln -s /cc/freeswitch /usr/local/freeswitch
  1. 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文件里面数据库用户密码改一下

  1. 6、安装数据库(在数据库服务器上装、一定要安装配置日志，避免数据丢失)、odbc并配置、先配置数据库试试 （数据库导入脚本 数据库脚本找小叶要一份最新的）
    mysql-odbc驱动安装: 

    1
    yum install mysql-connector-odbc

修改或创建文件:/etc/odbc.ini,内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  
      [yccc]
Description     = MySQL test database
Trace       = Off
TraceFile   = stderr
Driver      = MySQL
SERVER      = 127.0.0.1
USER        = root
PASSWORD    = 123456
PORT        = 3306
DATABASE    = callcenter
charset = UTF8
OPTION = 67108864
Threading = 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

  1. 7、安装gdb yum install gdb （不是必须） 安装gc++: yum install gcc++

  2. 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:$PATH

    2）使配置生效：source /etc/profile
    3）执行java -version 确认配置生效

  3. 9.修改ag.cfg里面的sidhead前缀、这个是用于表示区分集群每个节点数据、将ag重启一下、这样数据就不重复了 将来合库cdr不会有重复。

9.dyflow启动失败解决方案:

  1. 1.配置core
    参照qa那个文档配置core
    一、在/etc/profile中加入：
    ulimit -c unlimited

二、在/etc/rc.local中加入：
echo “/cc/log/coredump.%e.%p” > /proc/sys/kernel/core_pattern

  1. 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

work-5-cmcc系统softphone集成

前言

  1. 我们有时候需要将平台acdgate前端对应的softphone相关的js集成到crm系统中去,以此来实现和软交换平台相关的呼叫
  2. Demo文件cbanner_wstext.4.6.1.html中拥有完整的软电话控制，只需调用页面时调用sfc_platagentinfo设置server地址和座席信息，并对呼叫事件进行处理即可。

内容

1.获取相关softphone的js和css以及html文件

拿到相关的softphone前端文件:我们以版本:sv10css_v2.0.0.4为例子,基本目录如下所示:

2.相关js说明
  1. SV-callbanner-common-cmclient-1.0.0.js 封装了呼叫事件 相关振铃,接通,挂断,鉴权事件都在这里面 业务:可用于做来电弹屏 小结弹屏
  2. SV-callbanner-common-cms-4.6.1.js 为 callbanner,crm 提供通信平台相关查询类服务
  3. SV-callbanner-common-engine-4.6.2.js 对callbanner的基本通讯、高级功能、组长功能等交互模块进行模块的逻辑控制
  4. SV-callbanner-common-wscomm-1.0.0.js Websocket通信js封装

以上在业务代码集成时候,我们可以自定义js重写SV-callbanner-common-cmclient-1.0.0.js的事件,然后降低crm和softphone相关的耦合度,减少排查问题的困难

3.测试softphone是否正常
  1. softphone前端和后端acdgate是通过java-websocket进行交互的,所以我们主要改造:cbanner_wstext.4.6.1.html(websocket和后端服务交互的主要文件)
  2. 我们先打开cbanner_wstext.4.6.1.html文件看其功能是否正常,如果是以下情况,则正常
4.修改softphone文件集成到crm系统中去

我们以cmcc平台管理系统为例:

  1. cmcc系统的主页面是ace_main.jsp 我们从下面可以看到,通过权限控制acdInfo非空然后嵌入cbanner_wstext.4.6.1.jsp,其他系统可供参考
    4.1 集成步骤
  2. 1.修改cbanner_wstext.4.6.1.html文件为cbanner_wstext.4.6.1.jsp页面,添加jsp相关标签即可
  3. 2.将sv10css_v2.0.0.4里面的css,images,js文件拷贝到cmcc系统的softphone文件下面,并修改cbanner_wstext.4.6.1.jsp引入js和css的路径
4.2 图片路径修改

有时候,我们图片路径是有问题的,此时我们需要修改:var g_ImgPath = “./webpage/main/softphone/images”;

5.修改拨号盘图片路径

拨号盘img的图片文件地址是从sv10css_v2.0.0.4里面的images里面加载,所以我们需要修改其路径为:

6.测试软电话

最后做完之后,我们以坐席登录,然后打开crm系统,如下说明集成完毕

毕业于<br>相信技术可以改变人与人之间的生活<br>码农一枚