从入门到进阶-如何基于FreeSWITCH搭建呼叫中心平台

文 | 杨先君

智慧企业架构师、技术经理

今天和大家分享一下

如何基于FreeSWITCH搭建一个呼叫中心平台

入门篇

FreeSWITCH 是一个开源的电话交换平台。官方给它的定义是--世界上第一个跨平台的、伸缩性极好的、免费的、多协议的电话软交换平台。 在FreeSWITCH出现之前，软交换技术是高不可攀的领域，这种技术基本上掌握在少数通信企业，集成在硬件设备上整机出售，价格昂贵。需要大量的专业积累才能入门，使用者基本上偏运维，无法掌握实质的技术。而现在，越来越多的开发者通过FreeSWITCH来深入了解通信技术。

FreeSWITCH的本质和其它VoIP通信原理一致同样是点到点的实时通信。当FS以BypassMedia运作时，它即是两个终端进行实时通信的一个桥梁和工具，负责双方媒体通道协商，交换双方的RTP端口，编解码，码率等信息，详细的SIP协议或协商流程可参见：RFC3261文档，源码及编译安装可以参见FreeSWITCH官网。

当服务启动完成后，即呈现一个完整的PBX(Private Branch Exchange)系统。直接使用x-lite终端输入分机号及密码就能建立P2P通道来传输媒体流实现点到点通话。拨号计划是FreeSWITCH中至关重要的一部分。它的主要作用就是对电话进行路由。就是当一个用户拨号时，对用户所拨的号码进行分析，进而决定下一步该做什么。它所能做的比你想象的要强大的多。如：可以拨打9196进行回声检测测试媒体是否畅通，拔打3000进行电话/视频会议接入，不在线时进行语音留言等，也可以构建IM通信服务完成点到点的文本消息及实时文件传输，这些拔号计划可以达到零编码来进行功能扩展。同样可以通过Endpoint模块来实现不同种类的终端进行互联通话，如下图所示：

当然做信令代理并不是FS的强项和它做为软交换身份的常规用途。由于SIP协议的特殊性(带状态的协议)，使得它在内网和公网变换且进行NAT穿透时成了一个大麻烦，需要对SIP协议的头部及包体的SDP信息都要做深度的定制。做信令代理通常都会直接使用openSIPS/Kamailio，后边的进阶篇时再详说。正常情况下FS同终端之间的连接方式如下图，媒体服暴露在公网，信令及媒体均通过其进行传递，目的是媒体通过服务端后就可以做媒体的播放，桥接，变更，混合，存储等动作，达到媒体交换的目的。也正是我们后边讲到作为呼叫中心核心网元的常规操作。

点到点通信的终端可以是Linphone/X-lite这种应用也可以是PSTN电信交换网的接入接出设备，两者的共同点是都遵循SIP标准可以无缝接入，不同点是来自PSTN网终相对稳定且编码大多是G711，来自互联网应用终端如果是移动设备有弱网情况存在，为了应对这种情况就会有iLBC、OPUS、G729、GSM等编码，也有各种丢包补偿机制、抗抖动策略等相关算法。

目前WebRTC的实时音视频已经比较成熟，很多音视频的平台都利用其来搭建自已的点到点或者音视频会议服务，FreeSWITCH同样也可以做为RTC的媒体交换参与其中。FS加载mod_sofia及mod_rtc模块,默认监听在7443端口，来处理wss+sip的信令进行sdp协商，协商后直接进行rtp在加密通道上进行传输。同样默认监听在5060端口，来处理在tcp或udp通道上的sip协议进行sdp协商。

FS怎么做到不同端点之间的转换呢？主要通过sip_profile来进行扩展，将SIP会话的流程转变成会话的有限态机来进行维持。将协商的参数存于临时会话结构上，在FS上针对每个通话建立一个Session，每个参与的端点都做为其中一条Leg生成一个Channel，绑定到Session上，针对媒体如果有加密先进行解密，有编码的再进行解码，最终都会转换成L16线性脉冲编码存于缓冲区，当双边媒体通道打通时互相取对端的缓冲区数据进行传递，到对端端点后再根据协商的格式进行编码，如果需要媒体流加密的再进行加密，如果单边接通FS也能主动play到对端，如果需要对媒体进行转储采用mediaBug进行媒体转发，转发一路给录音模块或文件存储模块进行储存。WEB服务端会通过jssip来封装SIP协议栈并通过浏览器来加载WebRTC能力进行媒体协商，协商成功后Browser直接和FS进行媒体交换。如下图：

以上限于篇幅，分别点了一下FS做为一个小型的PBX的构建网元，以及如何协同工作的，其中的每一个知识点展开讲都比较大，比如：FS中的核心构造有哪些，是如何工作的；分别有哪些端点，主要完成了哪些工作；它的编解码模块；它的帐号认证模块；它的拨号计划模块；它的内部三级队列的事件分发机制；它的ESL事件驱动内联/外联模式如何进行主控；还有和AI是如何打通的，如何实现这样的模块，等等。如果后边有机会会进行一系列连载，深度剖析一下这款优秀的工具。接下来进阶篇主要讲一下云呼叫中心是如何构建的。

进阶篇

市面上大部分呼叫中心类型产品有几类做法，坐席端要么针对各类操作系统开发相关的APP或SDK，要么使用OCX控件来集成终端音频能力，采用pjsip等类似的开源或自研协议栈在udp/tcp通道上传输标准的sip协议，连接到指定的FreeSWITCH软交换，另一端采用E1线从运营商接入使用OpenVox板卡或其它厂商的硬件转换网关把pri信令转成sip信令接入。

对于软交换核心的稳定性主要是采用的双机热备方案，如下图所示，这也是最常规的接入方式和高可用的方案。对于软交换来说主从实例能共用DB或Cache中的同一份Session数据，存储了双边通道的协商信息，我们都知道FreeSWITCH是一个有状态的服务，所有会话信息都在内存中处理，也会同步到db或Cache，当主节点挂掉后，从节点接管时会初始化DB或者Cache中的会话信息进行会话实例的重新加载。

对于终端来说在服务切换时有短暂的无声情况，如果媒体端口在防火墙等设备上仍然是畅通时直接就可以恢复媒体流，当发现端口不通时会通过reinvite来重新协商，整个过程非常短暂。这种模式是最流行的一种高可用方案，也是硬件厂商最常使用的一种方式。

账号体系可以用Doc文档或者DB方式管理，IVR树，ACD坐席分配，QUEUE入队，Cdr计费话单生成等管理，全部使FreeSWITCH自身的模块功能来构建，这种方式短小精悍，高内聚。它的最大的问题就是并发能力有限，在8U16C的主机上做过测试，在做过深度调优的情况下能支撑1800Chennel通话音质无损失。单个小企业内部支撑完全没有问题。

当我们要做一个云呼叫中心提供给众多企业一起使用，需要万级甚至十万级同时并发通话时，上述方式已经很难支撑。FreeSWITCH官方作者也讲述了这类问题，并表示现有的架构体系很难支持Cluster方式，需要自己来解决。

我们不需要发明创造，完全可以借鉴Redis的Proxy集群方案和Dubbo服务发现方案，组合使用即是一个能级联分布，横向扩展性能无衰减，服务上线能自动发现，服务异常能自动下线的高可用软交换集群，如下图：

先讲一下几个关键的网元节点，其中媒体交换中心集群、路由中心集群、接入中继集群都是使用FreeSWITCH来实现，接入代理集群都是使用Kamailio来实现。最核心的就是：

• fs-media：媒体交换中心集群；
• fs-router：路由中心集群；
• fs-tandem：接入中继网关；
• kama-pstn：企业接入代理；
• kama-wss：坐席接入代理。

为什么接入代理使用Kamailio而不是FreeSWITCH呢？它们的接入准标都是一样的，原则上来讲都可以作为接入代理，但是他们的侧重点不同，FreeSWITCH更注重媒体的处理，及号码变换，Kamailio更注重的是NAT网络穿透，信令路由寻址。Kamailio可以在呼叫的整个流程中分析、存储、变换SIP协议头部或包体中的各项参数。比如：在NAT环境中SIP请求在每经过一个代理节点都会在头部添加一项Record-Route/Route，在响应消息时每经过一个代理节点都会在头部删除一项Record-Route/Route，同时会在头部携带各种标识,也会携带contact，from，to等字段。

当有NAT环境时需要在代理上主动来对这些字段对内外网的IP,Port等做替换。如果未进行转换，这条到达本网关的消息会路由到错误的IP,Port上去，最终的结果就是信令不通，协商超时等不成功。对于网络环境这块儿是传统通信最大的问题，没有统一规范和标准可寻，只能实际拔测抓现场报文来分析并解决问题。如下图所示，即本方案的代理接入：

在企业内部一般都会采取媒体交换,CTI集成系统全都部署在内网，坐席终端一般也在同一办公网环境，也有在家等公网场合，这种情况是最为复杂的，因为既有公网，又要支持内网。我们可以将媒体全部监听在内网IP, 在代理出口使用Kamailio+RTPEngine来构建一个SBC网元做信令和媒体的代理，如果遇到对称型网络NAT类型,无法进行NAT穿透时，终端可以采取ICE接入。本图是一个WebRTC终端的坐席代理侧，Web终端使用jssip来接入，我们使用Kamailio的ws模块来解析并剥除协议内容将解析出来的标准Sip再路由转发给FreeSWITCH。

协议的下一跳即是fs-router集群了，fs-router的主要功能有两点，其一是：注册路由的保持，当有被叫时需要推送至客服端进行寻址。其二是：会话中间消息的路由转发层。首先要讲的是从代理集群上的信令怎么寻址到fs-router集群的一台具体的主机上呢？kama-wss会通过策略服务以Session为基本单位进行分配，分配规则是通过fs-router节点实时监测的并发会话数来取最轻负载优先。当然也支持随机，hash，顺序，加权随机等机制。只有在invite消息即会话开始时会选择一个节点，在会话的整个生命周期内都落在本节点上。同时并将Session记录到公共缓存，当本节点宕机时，在会话过程中的指令寻址到fs-router集群时会通过缓存找到router节点，通过zk的存活检测最终会发现本节点已无效，在此刻会重新分配fs-router节点，reinvite进行重新协商然后恢复通话。

为什么需要存在fs-router这个节点呢？它到底能解决什么问题？主要是为了解决单台媒体服容量上限及数据倾斜问题。如果没有这个路由节点，当前集群流量以租户为单位，可以通过tenantId来划分流量，将一个企业下的所有通话都引流到一个软交换媒体服上去，这样做有一个弊端，当一个企业的客服数或并发通话量过大时就会超出一台媒体服的容量上限，按租户来划分流量就会导致数据倾斜，资源使用不均衡。引入fs-router就是为了解决此问题，它可以将注册和媒体分离，原来按租户来进行的流量划分就可以做到粒度更小的按会话来划分，只需要将同一会话参与的两端或多端引流到同一台媒体服,会话生命周期结束后就会重新分配。

协议的再下一跳即是fs-media集群了寻址方式和kama-wss到fs-router类似,同样是借助策略服务及状态服务来发现服务的可用性及负载情况来在初始会话时选择一个具体节点，在会话的过程中通过缓存来进行真正寻址，当有服务异常的情况做同样的处理。唯一不同的就是fs-router和fs-media是双向对等的服务接入方式。对于媒体交换节点的主控服务采取ESL内联模式，主要实现了一个业务层与通信层的一个离散、聚合，协议转换包装，业务拆解与分发的主控服务如下图所示：

fs-media集群又可以按租户来进行划分也可以按功能来进行划分，真正做到租户间的物理隔离及功能间的物理隔离，可以分为通用媒体集群，灰度媒体集群，外呼机器人媒体集群，呼入机器人媒体集群，预测试外呼媒体集群，电话会议媒体集群，内部通话媒体集群等，可随意按需定制，如下图所示，为媒体集群节点注册时的数据模型，主要通过租户表来区分企业，通过应用节点表来区分FS节点为路由节点还是媒体节点，通过企业应用表来做节点和企业关联可做到以企业粒度随意切换。媒体集群是有状态的，但此种设计可以支持热切换，如正在通话中从一个集群切至另一个集群时，本次通话仍在切换前的集群上工作，新建的会话都会直接建立在新的集群上，当老的通话全部结束后再转移到新集群，需要注意的是如果服务要下线必须得先unregister，观察流量为0时才能真正下线。

协议的再下一跳就是线路落地，云呼叫中心的线路落地采取两种方式，一种是混合云的方式，另一种是纯云的方式。混合云是适应传统企业内部有拉过运营商E1线专线，或者有自己的PBX系统，可以方便的接入到云呼叫中心上来，这种方式和企业内部复杂的网络有关，所以在云端也采取了对网络穿透适配性更好的kama-pstn代理来对接，可以无任何限制的对NAT环境做协议变换。而纯云的方式主要是和各大运营商进行对接，能满足企业客户线上操作即可接入，省去很多不必要的技术对接工作，达到即开即用的目的，由于都是对等连接，但是运营商过来的号码关系比较复杂，但网络情况比较单一，采用了fs-tandem中继网关的方式来对接，重点保障安全认证和号码变换。

下图是一通呼叫从坐席注册，用户到坐席的一个接入流程，遵循SIP的流程机制，就不展开讨论了。

总结

点：我们先从FreeSWITCH这个核心点讲述了它是一个核心软交换应用，及功能特性。

线：又从搭建一个小型的PBX及功能调测以及可以连接哪些终端来连成一条可P2P的音视频通话的线。

面：继续通过讲企业内部的呼叫中心应用展开成面讨论到了一个呼叫中心应具备的基本要素。

体：最后通过云呼叫中心的高可用，分布式，高性能，多租户的架构设计方案汇聚成体，诠释了一套商业化可行的体系。

本文我们只从总体来讲解了一下呼叫中心云化必须具备的设计方案。云呼叫中心要关注或要解决的问题点还很多，通话质量是一个不可或缺的关注点，如何监测平台整体性的通话质量，如何进行通话质量调优，是流媒体平台必不可少的研究课题。

同智能化AI机器人接轨也是一个比较热门的话题，如何实时质检，如何智能推荐话术辅助办公，如何进行通话预测，如何进行智能监控及风控管理，是当下做商业服务一体化应用必须研究的课题。呼叫中心虽然是一个有年代感的应用系统，但是它随着时代的变迁也正日益茁壮的成长，给企业带来的价值不可小觑，让我们一起拥抱变化迎接新的挑战吧！