从入门到进阶-如何基于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、G72九、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机器人接轨也是一个比较热门的话题，如何实时质检，如何智能推荐话术辅助办公，如何进行通话预测，如何进行智能监控及风控管理，是当下作商业服务一体化应用必须研究的课题。呼叫中心虽然是一个有年代感的应用系统，可是它随着时代的变迁也正日益茁壮的成长，给企业带来的价值不可小觑，让咱们一块儿拥抱变化迎接新的挑战吧！