前沿

呼叫中心中呼叫对于话务平台来说一般都分为呼入跟呼出;呼入的话需要一般又分为两种:

  • 内线呼入
  • 外线呼入

内容

呼入

1.内线呼入

1.1 分机注册

内线外呼的流程入上图所示,内线外呼,需要我们将分机注册到freeswitch上面。

查看分机是否注册到freeswitch上面使用以下指令:

./fs_cli -H 172.17.125.206 -P 8031 -p testtest -x 'sofia status profile internal reg'

效果图如下:
image.png

1.2 发起内线呼入

8002分机呼叫8003分机具体呼叫日志如下:
image.png

小电话9999998,拨打6669,提示:系统忙,请稍后再试,前端ivr流程管理配置了6669的中继和流程引导码,以及编辑了流程;
查看日志:
image.png
需要重启下平台dylow模块即可根据:
image.png

2、外线呼入

2.1 外线呼入流程

外呼呼叫场景: 客户拨打中继号码,然后接入到系统的呼入。
这里引入场景:客户拨打中继外线,然后进入rl(第三方呼叫平台)进行ivr导航,然后如果转人工的话,进行按照6操作进入,然后rl转接到ipcc呼叫平台。进行客户跟机器人交互,交互后如果需要转人工的化,ipcc将转人工请求再次转发到rl约定的序列号,rl拿到这个序列号当作队列id然后转接到队列里面的人工坐席。

拨号计划如下:

https://blog.csdn.net/gredn/a...

整体流程图如下:
image

配置如下:
lixx: 配置授权时间
fsg: 首先确保fsg能够连接上fs;如果出现下面问题,说明连接fs有问题,
image.png

需要设置:
image

中继热线字冠跟系统内部热线号配置:
image.png

配置根流程:
image.png

配置动作:
image.png

配置流程:
image.png

让后转人工ipcc系统呼叫配置:
image.png

2.2、外线呼入实践

我们在中继字冠热线表里面可以配置一个中继字冠对应多个热线号码;
但是ipcc默认会走id最小的一个热线流程。
根据我们配置的中继号码我们客户端发起呼叫。发现没有按照流程拨打电话
然后拨打计划如下所示:
image
从上面可以知道第一个拨打计划解析失败后会走第二个拨号计划。

然后我们查看ag日志:

image.png
发现有拨打信息产生,主要根据sid=callid+index;

查看流程入口:
image.png
发现流程入口正常。
然后去看dyflow日志:根据sid:
image.png
发现filename=[]所以我们检查我们的流程配置:
image.png
发现配置人员压根乱配置了流程。
调整后即可实现。

呼出

呼出逻辑查看上面图示;

1、预测式呼出

预测式呼出是:ipcc主动配置外呼主叫,在没有坐席在线时候主动发起的呼出。

1.1 预测式号码检测呼出时候-200结果

问题: 我们在进行号码检测拨打时候创建了特殊的entid=1然后进行呼出的时候,出现-200保存到数据库。并且通话时长是8分钟情况。

排查解决: 号码呼出按照上面流程,然后我们排查日志时候,现在ag日志里面根据called查找到号码,然后查找到sid,根据sid就能够查找到呼叫记录详情。
image.png
根据被叫查找到sid:我们发现一下正常跟异常的情况。
image.png
发现异常情况下ag没有发起到fsg(没有R)
说明号码防火墙可能出问题了,查询得知:
image.png
发现号码防火墙报数组异常。

2、预览式呼出

2.1 配置外呼

对于登录坐席工号进行呼出的情况,我们有如下步骤:1.坐席签入后能上线成功 2.坐席能够正确路由到运营商的sip电话进行呼叫
话机注册
有时我们配合软电话条跟软电话进行测试时候,发现我们的软电话条输入分机号跟密码是可以嵌入的;但是发现我们的软电话是不能够注册的,总是提示:"incorrect password".
原因是:我们进行软电话条对应的是cti_work表;我们的话机注册是:cti_siptel表。我们将其密码改正即可。
image.png

坐席上线
1.在cti_work表中找到分机,如:100003。
2.配置100003到cti_work_queue中去
3.在cti_outcaller中配置上线的主叫
3.在cti_telno中配置分机路由:100003分机呼出使用内线字段、长度在1-6(因为:100003是6位数)、
4.查看/cc/bin/log下面的日志:
发现话机没有注册,打开一看:是注册的服务错了
5.如果出问题,查看Acdgate模块下Tomcat日志,在查看/cc/log/acd_acd01.log下的日志
acd_acd01.log里面r:开头的。

2.3 呼出显示的主叫错误问题

现象: 在话务平台上配置了新的主叫号码,但是在发起呼叫客户手机时候,发现客户手机上显示的不是配置的号码?
查看fsg下binlog时候,显示的是正常配置号码1,但是客户显示是号码2.
配置的有问题吧 call out/transfer,caller=号码1,called=13253062317,cmd=bgapi originate {sip_h_X-sourcesid=90001351500452,origination_caller_id_name=号码1,origination_uuid=00000115-0453,originate_timeout=60,origination_caller_id_number=号码1}sofia/gateway/gw1/13253062317 &park

分析: 呼出时候出现主叫号码不对问题,主要是以下3个原因:
1、freeswitch自身的落地网关里面的gw配置中caller-id-in-from没有配置。需要修改下gw配置:
image.png

2、话务网关路由转发时候转发到了一个随机号码
3、运营商中继线路配置限制了呼出号码为指定号码。

软电话条

1、前端心跳检测设计原理

acdgate前端进行心跳检测的时候,会返回servicecode;设计原理基于:
在websocket支持不好的情况下,socket经常断开重连,存在以下情况:
后端准备给前端推送数据的时候,socket断开后移除了 然后此时又需要推送消息,那么判断其对应的连接为空时候,不推送数据,但是这个消息数据也不会在后端内存保存,后端里面保存的就是agent坐席的信息-----所以针对于这种情况可能存在消息丢失,但是如果心跳检测时候,返回坐席的servicecode的话,前端根据servicecode来及时调整坐席前端变化。做一些状态补偿。


startshineye
91 声望26 粉丝

我在规定的时间内,做到了我计划的事情;我自己也变得自信了,对于外界的人跟困难也更加从容了,我已经很强大了。可是如果我在规定时间内,我只有3分钟热度,哎,我不行,我就放弃了,那么这个就是我自己的问题,因为你自己...


引用和评论

0 条评论