文 | 杨先君
智慧企业架构师、技术经理
明天和大家分享一下
如何基于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机器人接轨也是一个比拟热门的话题,如何实时质检,如何智能举荐话术辅助办公,如何进行通话预测,如何进行智能监控及风控治理,是当下做商业服务一体化利用必须钻研的课题。呼叫核心尽管是一个有年代感的利用零碎,然而它随着时代的变迁也正日益茁壮的成长,给企业带来的价值不可小觑,让咱们一起拥抱变动迎接新的挑战吧!