标签：SIP 58 同城 机器人 用户 干货 用于 RTP 语音

本次沙龙的干货如下，各位技术大拿们敬请享用。本期摘要

基于语音语义技术实现的智能语音机器人可以代替或者辅助人工来完成一些例程化工作，被广泛应用于企业各场景以提高人效和增加收益。本次议题将重点剖析58同城自研的智能语音机器人工程架构设计，介绍在电话沟通场景下如何基于JAIN-SIP开源库和流式语音识别API实现人机多轮语音交互，并分享海量外呼场景下语音机器人后端系统在并发控制、调度策略和性能优化方面的技术细节。

分享嘉宾  
李鸿勋58同城 | 后端资深工程师58同城AI Lab后端资深工程师，2017年加入58同城，目前主要负责智能语音机器人后端架构设计和研发，曾先后从事58同城推荐系统、智能客服系统后端研发工作。视频回顾

分享内容

一、介绍

利用语音识别、语义理解和语音合成技术赋予机器多轮对话交互能力，使机器能模拟真人与用户对话，识别和理解用户的会话意图，它可以代替或者辅助人来完成一些例程化工作，可以为企业提高人效和增加收益。58同城AI Lab自研的语音机器人支持电话、网络音频通话的外呼和呼入场景，已被广泛应用于销售、客服、产品运营场景。

二、整体架构

智能语音机器人后端架构主要抽象成四层，第一层为接入层，主要负责WEB接入平台和效果展示，方便业务方同学配置人机对话话术和效果数据的查询，第二层业务逻辑层，负责实现机器人的整体逻辑，其中接入服务用于业务方接入；主体服务用于语音接收和发送、人机对话管理；算法子服务用于各功能模块的独立迭代，第三层数据存储层，负责存储人机对话的详情、录音等流水数据，第四层是机器人依赖的第三方服务。

三、如何实现人机语音交互

1.协议介绍

机器人借助SIP线路实现人机语音通话的场景，主要涉及以下三种协议：
1）SIP(Session Initiation Protocol)：多媒体通信协议，用于建立、修改和终止多媒体会话的应用层控制协议，包括网络多媒体会议，网络电话等，机器人通过SIP信令的状态码来控制呼叫流程，状态码100表示三大运营商正在寻呼用户手机/座机，状态码180/183表示用户手机/座机正在响铃，此时可以接收语音包用于后续的通话状态分析，状态码200表示用户已接听，响铃后接收到此状态码通信双方便可以开始语音交互。

2）SDP(Session Description Protocol)：媒体协商协议，用于两个会话实体之间的媒体参数协商，SDP协议中a代表会话属性，如图所示rtpmap: 0 PCMU/8000代表此通电话支持PCMU编码，语音的采样率为8K，携带此信息的RTP包包头 payload type为0，c代表连接属性用于约定通信的ip，m代表媒体信息用于约定本次通信的媒体为音频。
3）RTP(Real-time Transport Protocol)：实时传输协议，为端到端都是实时传输提供时间信息和流同步，RTP包包头介绍几个比较重要的字段，PT全称payload type，用于标识当前RTP包包体中携带的数据类型，Sequence Number用于标识当前RTP包在整个语音流中的位置，Timestamp用于标识相邻两个RTP包之间的时间差，SSRC用于标识当前RTP包是否来自同一个源。

2.建立连接

机器人与用户语音交互之前需要先建立连接，机器人借助SIP线路实现了电话语音呼入和呼出，借助TEG音视频实现了网络语音呼入，以SIP呼出为例，机器人主动呼叫用户，向SIP线路发送SIP信令并携带SDP协议约定媒体信息，SIP线路接收到SIP信令后转发呼叫请求至三大运营商，SIP线路接收到运营商响应后，向机器人发送SIP信令并约定媒体信息，通信双方拿到需要的媒体信息后便建立连接并发送和接收语音包。

3.语音交互

为实现机器人和用户的多轮语音交互，需要对用户语音转文本用于识别用户意图并返回相应的机器人动作，在接收用户语音包时设置一个固定长度的滑动窗口，如图所示VAD（断句算法）判断窗口的前13帧语音包都为人声则认为用户开始说话，如果不都为人声则判断用户说话结束，在断句的同时将语音包实时传入流式语音识别接口，在用户说话结束后获得用户文本并调用意图识别服务得到用户意图，而机器人则会预先抽象出各类策略用于不同的用户意图返回相应的机器人动作，例如按键策略用于识别用户按键信号，并根据事先配置好的话术选择流转的节点并生成语音发送给用户。

4.按键识别

目前所有的电话和传真机按键都采用DTMF信号进行编码和传输，DTMF信号是利用模拟信号对数字符号进行编码，该编码方案共使用8个模拟频率对16个符号进行编码，分为游戏买号平台地图高音群和低音群，所以称为双音多频（Dual-Tone Multiple-Frequency）编码，每个符号由一个高音频率和一个低音频率唯一确定（0~9*#ABCD），其中智能语音机器人采用RFC2833规范实现的按键信号识别成本最低。

5.常见问题

1）噪音：这种情况一般为RTP包包头Sequence Number错乱导致的，保证一通电话的RTP包Sequence Number是自增即可。

2）爆音：出现爆音一般出现在语音拼接的场景，在实践中为了节省成本，一段不变文本对应的语音为了避免重复语音合成，一般都提前合成存入缓存，需要用到时拼接发送，因为每次语音合成的语音流的前44位为修饰语音流信息的数据，如上图所示，这是导致拼接后在拼接处有明显爆音的原因，去除前44位后即可解决。

3）音速快/慢：一般为发送端和接收端语音采样率不匹配导致。
4）无声音：无声音的问题比较复杂，建议通过以下几步分析。a.双方网络是否连通；
b.使用Linux环境下tcpdump命令抓包，wireshark分析抓包信息，验证是否收到RTP包；
c.查看RTP包头格式是否正确，主要验证PT、Sequence Number、时间戳等是否正常；
d.双方的编解码方式是否一致；

 

四、算法子服务

1.架构服务化

项目早期为了快速验证方案的可行性，所有逻辑都耦合在一个服务中，随着接入的业务方越来越多，代码越来越臃肿，导致开发同学迭代成本高，线上服务容易出bug，为此我们做了一系列架构服务化的工作，实现了业务隔离、代码复用、各算法模块的独立迭代。

为了快速验证算法效果，需要对不同的算法做线上AB实验，在服务化的架构中，通过主体服务控制所有子服务调用和逻辑流转，在日晷平台上建多个实验，这些实验及实验内部各层之间相互正交，主体服务请求日晷服务得到各个算法分流信息再分发至各个子服务。

在项目的迭代中，各个角色的同学的关注重点不同，基于此智能语音机器人将线上语音交互产生的各类数据存储在不同的存储介质中，经过转化处理同步给项目的各个同学，方便产品/业务方同学关注线上运营数据，用于提升用户体验；方便算法同学及时获取训练样本和线上算法效果，用于离线训练和提升各类算法指标；方便后台同学监控线上服务质量和策略迭代，以支持项目快速稳定的滚动迭代。

2.SIP调度策略优化

选取其中一个子服务介绍下后台同学做的相关工作，SIP调度服务主要用于筛选可用的SIP号码提供给机器人与用户语音通话，其中每个SIP号码能同时支持的通话数有限，实践中我们得出以下两个结论。

1）主被叫属于同一归属地时，接通接听率会更高，一是用户接听本地号码的意愿更高，二是各地运营商寻呼本地的手机/座机连接成功率更高。

2）号码使用次数越多，被用户投诉标记概率越高，被用户标记的号码接听率会下降明显。

基于以上结论我们对服务进行针对性优化。

1）将号码按业务线、主叫城市进行分组，缩小需要筛选的号码集合。

2）结合主被叫距离和号码使用次数计算号码权重，权重高的号码优先使用。

3）服务启动时预计算全国各城市之间的距离，SIP调度时并行处理用于提升服务性能。

 

五、系统优化

系统优化是一个非常系统和繁琐的过程，需要根据各个系统的实际情况采取不同的策略，同时也跟系统实现的复杂度，并发量等等有关，本次主要介绍对Java原生线程池做的改造和优化，Java原生的线程池的参数设置需要考虑任务的类型，对于IO密集型任务，可以调大线程池线程数并行处理，而对于CPU密集型的任务，需要考虑上下文切换，并非线程数量设置的越大处理越快，我们在实践中发现在很多场景的任务IO和CPU操作都会涉及，这时如何合理的设置线程池参数将是一个挑战，因此我们结合WConfig（分布式配置中心）、WMonitor、JDK源码及各类告警通道改造了Java原生的线程池，实现线程池参数的动态设置并取得不错的收益。

1）系统耗时下降明显，在业务流量波动时可以灵活及时地调整。

2）成本可控的前提下为开发同学提效，省去编译、打包、上线等繁琐的上线流程。

标签：SIP,58,同城,机器人,用户,干货,用于,RTP,语音
来源： https://www.cnblogs.com/qiucunxin/p/15363740.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。