智能外呼场景下的核心通信能力探索

趋势与背景

在智能语音领域，语音AI是最早落地且应用场景最为广泛的技术之一，自引入深度学习后进一步蓬勃发展，变得更加炙手可热。作为重要切入点，语音AI一方面整合了底层算法与能力调用，另一方面则与各类业务场景融合。

外呼业务场景非常丰富，比如电话营销，用于探客并筛选意向目标；比如回访，用于信息核验；再比如贷后触达等。而随着业务量增加及各类业务规则日趋复杂，为了更有力地支撑业务，仅采用人力填补则代价较大，而且人员的能力评估、业务稽核跟踪、内容质检等痛点特别突出。因此，以AI技术为脑，整合通信能力与业务系统等自动化工具为躯干的智能语音外呼技术一跃而出，成为解决上述问题的一枚银弹。

业务场景下的能力组合

智能外呼功能繁多，系统设计细节繁复，化繁为简归纳一下，其实是围绕着通信能力展开，本质上就是两个终端和一个通信。

第一个终端是目标客户，因此其核心是围绕着目标客户的业务系统，比如常见的CRM、贷后系统等；另一个终端则是AI，是围绕AI能力的一系列底层算法的能力封装，实际上AI端是工程、算法与运营的统一。两个端点间的通信，由呼叫业务系统与底层通信核心组件构成。

从业务角度来看，AI端实际上是包含了一系列话术集合的智能回应者，它具备了一系列能力：语音识别能力（ASR）、自然语言处理能力（NLP）、语音合成能力（TTS）。

语音识别能力

语音识别能力主要是将语音转换为对应文字，其输入是音频，输出则是文字描述。

其过程实际上是搜索，在给定特征X条件下，搜索最大可能的文字序列。一般语音识别过程包含3个部分，即声学识别、语言识别和解码器。声学识别是指在给定特征条件下，识别出对应声学信号。语言识别则是根据给定条件识别出最大概率的文字序列；解码器则是根据声学与语言识别的结果，搜索出概率最高的词序列，实际上是动态规划算法的体现。

自然语言处理能力

自然语言处理能力包括自然语言理解（NLU）与自然语言生成（NLG）两部分。早期的自然语言理解基于规则（CFG/JSGF）、统计（SVM/ME）实现，之后随着引入了深度学习，CNN/RNN/LSTM等大放异彩；再到近年BERT和GPT-2震惊业界，基本都采用Transformaer模型。自然语言生成用于将非语言格式的数据转换成人可以理解的形式。

语音合成能力

语音合成能力（TTS）主要是将一段文字转换并输出语音，即让机器模仿人类交谈。最早的语音合成是通过机械装置实现的。时至今日，CNN/RNN等神经网络模型都可以做语音合成训练，而且深度学习算法能更好模拟人声变化。在这一领域，最大的诉求仍是如何让机器的声音更有温度。

核心通信能力

端到端的信息交互，本质上是通信能力。在早期的业务场景中，业务通常使用的是PSTN网络，也就是日常电话网络。而随着技术发展与演进，PBX产品发生了开源向商业的逆袭，Asterisk、FS等大量优秀产品涌现。

Asterisk大约在1999年左右出现，是当时最流行的开源PBX之一，围绕着它的生态社区非常成熟。早期一些大型互联网企业，比如网易，它的整个企业电话系统（约5000门+），及多个呼叫中心都是基于它构建。

而FS相对算是后起之秀，大约在2006年前后出现。它是一个跨平台的开源PBX，原生就支持Windows、MacOS、Linux等大部分平台。它能处理各种形式的媒体数据，提供路由和互连通信协议，并且填补了大量商业解决方案的空白。相对于前者，它的核心部分精简而稳定，且支持多种语言进行ESL扩展。携程的大规模呼叫中心（200+场景及20000+坐席、日呼百万+）、易信的国际电话系统，底层几乎都基于FS实现。

对于外呼业务场景来说，最为关键的就是通信能力的高效和稳定。要实现商业化输出则必须保证系统的高并发能力和稳定性。因此对于缺少自研技术能力，无法驾驭开源产品的企业，通常也有许多第三方成熟解决方案可选，例如国外产品Genesys等。

智能外呼实际上是将上述各种能力加以有机结合，以解决该业务场景下的业务痛点。

核心通信能力探索

通信能力演进

说到通信，能想象到的最古老形式可能就是古代的烽火狼烟了。随着近代技术发展，从贝尔实验室开始，从模拟电话到数字电话，再到目前引领世界潮流的华为5G技术，百多年来发展迅猛。早期的PSTN电话采用的是模拟信号，在远距离场景下随着距离增大，信号衰减传输质量下降。而通信系统演进过程的一大步就是从模拟终端到数字终端的变迁。

另一个层面的演进体现在网络互通。PSTN采用的是电路交换网络，即两个终端间采用电路连接。好处是通话稳定性比较高，有一定私密性；弊端则是远程通信基于专用线路，成本比较高；更为重要的一点是，电话网络与互联网传输网络两者互不相通。而4G/LTE以来，不论是语音电话或者互联网的访问，都能通过IP网络实现数据传输，打破了两网间高耸的壁垒。但挑战也随之而来，如何保证不同网络、多类型终端间的连接？如何保证PSTN终端与互联网终端间的连通？

通信协议：SIP与H.323

为了解决上述不同网络复杂终端互连问题，又一项大杀器被祭出——通信协议。常用的协议族有两个，先来看看第一项：SIP。SIP是会话初始协议（Session Initiation Protocol）的缩写，是一个控制发起、修改和终结交互式多媒体会话的信令协议。它是通信领域中的一个标准信令。最初由IETF（Internet Engineering Task Force，即Internet工程任务组）在RFC2543中定义，最早发布于1999年3月，2002年6月又发布了一个新标准RFC3261。初一看，SIP和HTTP长得很相似，结合一个HTTP协议实例来看：

HTTP：GET /index.html HTTP/1.1

SIP：INVITE sip:1001@fs.org SIP/2.0

两者都包含三个部分：HTTP中GET指明获取资源动作，/index.html则指向资源地址，HTTP/1.1为协议版本号。而在SIP中，INVITE表示发起一次请求，1001@fs.org为请求的地址（也称为SIP URI，格式为协议：名称@主机），第三部分SIP/2.0为版本号。

SIP是一个对等协议，与HTTP不同，不是客户端与服务器结构，不像传统电话网络需要一个中心交换机。它可以在不需要服务器的情况下通信，只要双方知道彼此地址即可，即点对点通信。如下图所示，Bob给Alice发送INVITE，Alice回复200 OK，电话接通。

另一个协议称为H.323，出身不凡，来自国际电信联盟ITO，定义了从应用层到传输层的完整协议族。约定了H.225用于通话注册，H.225.0用于维护通话，以及H.245用于通话过程协商；此外还约定使用RTP进行流传输及RTCP用作带宽控制等，整个协议族非常详尽。早期被大量使用，包括Microsoft和Cisco都遵循这一标准。

相比之下，由于IETF一贯的开放性风格，SIP也继承了其灵活与高自由度，相对H.323，不规定具体内容，只约定协议框架、网络结构与传输格式。而且其互通性也更为出色，因此采用得更多。

开源PBX中的翘楚——FreeSwitch

FS是基于上述协议的一个开源系统，官方的定义是：“世界上第一个跨平台、具备伸缩性、免费、多协议电话交换平台”。其突出优势在于能对接几乎任何设备，例如通过Chrome实现WebRTC与FS间的实时音视频通信。FS在开源通信领域，可以视作OS领域的Linux与Android、或者存储领域的MySQL与PostgreSQL。

FS核心结构

FS包含一个稳定核心（FS Core）与一系列外部模块组成。外部模块根据功能与用途，可以分为Endpoint、Codec、Dialplan、Application等不同类别。FS内部采用多线程模型处理并发请求，每个连接都由单独线程处理，不同线程间通过Mutex互斥访问共享资源，并通过消息和异步方式通信。这种架构在多核场景下能均匀分布，不仅能提供最大程度的并发，更重要的是，即使某路电话故障也仅仅影响所在线程，不会波及其他。

其核心主要包括以下四个部分：

1、数据存储层：默认使用SQLite，也支持如MySQL和PostgreSQL等。存储系统接口、任务与当前通道（Channels）以及通话等实时数据。

2、公共应用程序接口：供外部模块调用的核心函数，例如当Endpoint模块收到呼入请求时，会调用核心session_request函数为该呼叫生成新会话，并在挂断时调用session_destroy释放。

3、接口集：对同类型逻辑或功能作实体抽象，具体实现由外部模块负责，核心层通过回调来调用具体实现。

4、事件集：FS内部使用消息和事件机制实现进程和模块间通信。当系统内部状态变化时，会产生一些事件，系统会依次调用这些事件的回调函数。

B2BUA机制

FS在业务控制环节，主要采用B2BUA机制。所谓业务控制是指，当终端通过多个Proxy代理后，根据Route Set返回处理流程。但是在某些情况下，如果终端忽略Route Set，直接通过呼叫方和被呼叫方，双方可能进行非法呼叫，即跳过代理服务器，导致业务控制难以管理。

官方RFC3261定义是：B2BUA是一个逻辑实体，由UAS和UAC两部分构成，分别负责接收，处理和生成请求。根据定义，为管理双方终端和会话，B2BUA需分别创建两个会话；根据终端不同，可以同时扮演UAS/UAC，这样才能完全控制双方的呼叫流程，保证双方位于同一信令路径。

工作机制剖析之Channel状态机

FS在管理呼叫生命周期时，内部通过状态机实现。每次呼叫都会启动一个Session会话，用来控制呼叫流程并持续到通话结束。其中每个Session都控制一个Channel（也称通道、信道），它是一对UA之间通信的实体。每个Channel都用一个唯一的UUID来标识（即Channel UUID）。Channel中可能包含音视频等媒体流。通话时FS会将两个Channel桥接在一起，使双方可以通讯，这两路桥接的通话在逻辑上组成一个Call。

媒体音频编码与协商模式

从模拟信号到数字信号的过程称为模数转换（AD，Analog Digital Convert）。AD转换一般经过采样、量化和编码三个过程。编码就是按一定规则将采样到的信号用一组二进制数来表示。经过编码后的数据便于网络传输，到达目的端后，再通过解码变为原始信号，进而经过数模转换（DA）再恢复为模拟量，即人类能感知的信号。

在默认配置中，SIP Profile支持媒体列表是在vars.xml文件中配置的，如下所示：

FS中由于不同的SIP终端具有不同特性，支持不同语音编码，因此相互通信时需要对编码进行协商，以便理解双方互相理解媒体流中的数据。SIP采用Offer/Answer机制来协商，请求发起方提供自己支持的媒体编码列表，而被请求一方比较自己支持的编码，并选择一项或几项，以应答方式通知请求者。

AI赋能与智能集成

FS本身不实现AI，但在外呼场景中可以非常便捷地集成AI能力，基于FS处理音视频并赋能。FS甚至在早期的版本中就设计了ASR和TTS接口。

集成TTS

TTS是将文本转换为语音的一种技术，因而也称为语音合成（Synthesis），前文中已详细阐述其原理。FS中支持多种TTS实现，可以通过配置集成大部分主流TTS产品。

mod_flite：基于Flite语音合成引擎的TTS模块，来自爱丁堡大学的开源语音合成引擎。

mod_unimrcp：MRCP（Media Resource Control Protocol）是网络媒体资源控制协议。典型应用是TTS与ASR。其V2版本使用SIP协议。mod_unimrcp基于UniMRCP基础上实现，同时支持TTS和ASR。主流TTS和ASR产品都支持MRCP协议。

集成ASR

ASR技术与TTS可以说是紧密不可分，TTS将文字转换为语音，而ASR将语音转为文字。语音识别分为基于关键词识别和自然语音识别，前者比较成熟，而后者则较复杂。对于ASR实现，FS官方建议是基于MRCPv2协议。FS 通过 mod_unimrcp 与MRCP Server 进行通信。 mod_unimrcp 配置可以参考官方配置。

容器化部署

为了提供稳定服务并支持大体量业务需求，对FS原生的单体结构进行了加工，以实现容器节点的无状态化，有利于快速水平扩展。当节点故障中断，则自动转发请求至其他可用实例，优先保障线上服务稳定。结合容器云原生特性，针对故障节点快速Fail Over，并自动拉起新节点。

展望

从商业角度可以看到，越来越多基于云计算的通信方式逐步应用在各种场景，通信终端形式日益丰富，此类开源的具备通信能力的产品也会应用的越来越广。而随着AI技术进一步演化，针对识别率、拟真、降噪与丢包补偿等问题可以更好地加以解决和优化，能够提供比传统网络更好的服务质量。而在IoT领域，由于开源FS类产品天然自带的设备互连特性，其应用趋势也在逐步上升。希望未来借他山之石，能够打造出更加别具特色的产品。

受篇幅所限，本文仅摘取部分内容进行简要概述，涉及FS各项能力更细粒度的配置与应用，将在之后部门分享中详细介绍和说明，敬请期待。