導(dǎo)讀
隨著互聯(lián)網(wǎng)技術(shù)的高速發(fā)展获列，國內(nèi)客戶日益增長的需求，給傳統(tǒng)通信業(yè)務(wù)也帶來了較大的沖擊與變革，呼叫中心發(fā)展至今徒蟆，從最初簡單的人工熱線電話到交互式自動語音應(yīng)答系統(tǒng)，從企業(yè)內(nèi)部自建系統(tǒng)逐漸演變成為支持云化可分租戶來服務(wù)于眾多可聚類的企業(yè)應(yīng)用或托管式云呼叫中心解決方案型型，它的難點(diǎn)在哪里段审，準(zhǔn)入門檻到底有多高，又能做到怎么樣的極致體驗(yàn)闹蒜？今天就和大家來分享一下如何基于FreeSWITCH搭建一個呼叫中心平臺寺枉。
入門篇
FreeSWITCH 是一個開源的電話交換平臺。官方給它的定義是--世界上第一個跨平臺的绷落、伸縮性極好的姥闪、免費(fèi)的、多協(xié)議的電話軟交換平臺砌烁。 在FreeSWITCH出現(xiàn)之前筐喳，軟交換技術(shù)是高不可攀的領(lǐng)域，這種技術(shù)基本上掌握在少數(shù)通信企業(yè)函喉，集成在硬件設(shè)備上整機(jī)出售避归，價格昂貴。需要大量的專業(yè)積累才能入門管呵，使用者基本上偏運(yùn)維梳毙，無法掌握實(shí)質(zhì)的技術(shù)。而現(xiàn)在撇寞，越來越多的開發(fā)者通過FreeSWITCH來深入了解通信技術(shù)顿天。
FreeSWITCH的本質(zhì)和其它VoIP通信原理一致同樣是點(diǎn)到點(diǎn)的實(shí)時通信。當(dāng)FS以BypassMedia運(yùn)作時蔑担，它即是兩個終端進(jìn)行實(shí)時通信的一個橋梁和工具牌废，負(fù)責(zé)雙方媒體通道協(xié)商，交換雙方的RTP端口啤握，編解碼鸟缕，碼率等信息，詳細(xì)的SIP協(xié)議或協(xié)商流程可參見：RFC3261文檔排抬，源碼及編譯安裝可以參見FreeSWITCH官網(wǎng)懂从。
當(dāng)服務(wù)啟動完成后，即呈現(xiàn)一個完整的PBX(Private Branch Exchange)系統(tǒng)蹲蒲。直接使用x-lite終端輸入分機(jī)號及密碼就能建立P2P通道來傳輸媒體流實(shí)現(xiàn)點(diǎn)到點(diǎn)通話番甩。撥號計(jì)劃是FreeSWITCH中至關(guān)重要的一部分。它的主要作用就是對電話進(jìn)行路由届搁。就是當(dāng)一個用戶撥號時缘薛，對用戶所撥的號碼進(jìn)行分析窍育，進(jìn)而決定下一步該做什么。它所能做的比你想象的要強(qiáng)大的多宴胧。如：可以撥打9196進(jìn)行回聲檢測測試媒體是否暢通漱抓，拔打3000進(jìn)行電話/視頻會議接入，不在線時進(jìn)行語音留言等恕齐，也可以構(gòu)建IM通信服務(wù)完成點(diǎn)到點(diǎn)的文本消息及實(shí)時文件傳輸乞娄，這些拔號計(jì)劃可以達(dá)到零編碼來進(jìn)行功能擴(kuò)展。同樣可以通過Endpoint模塊來實(shí)現(xiàn)不同種類的終端進(jìn)行互聯(lián)通話显歧，如下圖所示：
當(dāng)然做信令代理并不是FS的強(qiáng)項(xiàng)和它做為軟交換身份的常規(guī)用途仪或。由于SIP協(xié)議的特殊性(帶狀態(tài)的協(xié)議)改鲫，使得它在內(nèi)網(wǎng)和公網(wǎng)變換且進(jìn)行NAT穿透時成了一個大麻煩鸳吸，需要對SIP協(xié)議的頭部及包體的SDP信息都要做深度的定制。做信令代理通常都會直接使用openSIPS/Kamailio，后邊的進(jìn)階篇時再詳說敦间。正常情況下FS同終端之間的連接方式如下圖，媒體服暴露在公網(wǎng)束铭，信令及媒體均通過其進(jìn)行傳遞廓块，目的是媒體通過服務(wù)端后就可以做媒體的播放，橋接契沫，變更带猴，混合，存儲等動作懈万，達(dá)到媒體交換的目的拴清。也正是我們后邊講到作為呼叫中心核心網(wǎng)元的常規(guī)操作。
點(diǎn)到點(diǎn)通信的終端可以是Linphone/X-lite這種應(yīng)用也可以是PSTN電信交換網(wǎng)的接入接出設(shè)備会通，兩者的共同點(diǎn)是都遵循SIP標(biāo)準(zhǔn)可以無縫接入口予，不同點(diǎn)是來自PSTN網(wǎng)終相對穩(wěn)定且編碼大多是G711，來自互聯(lián)網(wǎng)應(yīng)用終端如果是移動設(shè)備有弱網(wǎng)情況存在涕侈，為了應(yīng)對這種情況就會有iLBC沪停、OPUS、G729裳涛、GSM等編碼木张，也有各種丟包補(bǔ)償機(jī)制、抗抖動策略等相關(guān)算法端三。
目前WebRTC的實(shí)時音視頻已經(jīng)比較成熟舷礼，很多音視頻的平臺都利用其來搭建自已的點(diǎn)到點(diǎn)或者音視頻會議服務(wù)，F(xiàn)reeSWITCH同樣也可以做為RTC的媒體交換參與其中郊闯。FS加載mod_sofia及mod_rtc模塊,默認(rèn)監(jiān)聽在7443端口妻献，來處理wss+sip的信令進(jìn)行sdp協(xié)商浮声，協(xié)商后直接進(jìn)行rtp在加密通道上進(jìn)行傳輸。同樣默認(rèn)監(jiān)聽在5060端口旋奢，來處理在tcp或udp通道上的sip協(xié)議進(jìn)行sdp協(xié)商泳挥。
FS怎么做到不同端點(diǎn)之間的轉(zhuǎn)換呢？主要通過sip_profile來進(jìn)行擴(kuò)展至朗，將SIP會話的流程轉(zhuǎn)變成會話的有限態(tài)機(jī)來進(jìn)行維持屉符。將協(xié)商的參數(shù)存于臨時會話結(jié)構(gòu)上，在FS上針對每個通話建立一個Session锹引，每個參與的端點(diǎn)都做為其中一條Leg生成一個Channel矗钟，綁定到Session上，針對媒體如果有加密先進(jìn)行解密嫌变，有編碼的再進(jìn)行解碼吨艇，最終都會轉(zhuǎn)換成L16線性脈沖編碼存于緩沖區(qū)，當(dāng)雙邊媒體通道打通時互相取對端的緩沖區(qū)數(shù)據(jù)進(jìn)行傳遞腾啥，到對端端點(diǎn)后再根據(jù)協(xié)商的格式進(jìn)行編碼东涡，如果需要媒體流加密的再進(jìn)行加密，如果單邊接通FS也能主動play到對端倘待，如果需要對媒體進(jìn)行轉(zhuǎn)儲采用mediaBug進(jìn)行媒體轉(zhuǎn)發(fā)疮跑，轉(zhuǎn)發(fā)一路給錄音模塊或文件存儲模塊進(jìn)行儲存。WEB服務(wù)端會通過jssip來封裝SIP協(xié)議棧并通過瀏覽器來加載WebRTC能力進(jìn)行媒體協(xié)商凸舵，協(xié)商成功后Browser直接和FS進(jìn)行媒體交換祖娘。如下圖：
以上限于篇幅，分別點(diǎn)了一下FS做為一個小型的PBX的構(gòu)建網(wǎng)元啊奄，以及如何協(xié)同工作的渐苏，其中的每一個知識點(diǎn)展開講都比較大，比如：FS中的核心構(gòu)造有哪些菇夸，是如何工作的琼富；分別有哪些端點(diǎn)，主要完成了哪些工作峻仇；它的編解碼模塊公黑；它的帳號認(rèn)證模塊；它的撥號計(jì)劃模塊摄咆；它的內(nèi)部三級隊(duì)列的事件分發(fā)機(jī)制凡蚜；它的ESL事件驅(qū)動內(nèi)聯(lián)/外聯(lián)模式如何進(jìn)行主控；還有和AI是如何打通的吭从，如何實(shí)現(xiàn)這樣的模塊朝蜘，等等。如果后邊有機(jī)會會進(jìn)行一系列連載涩金，深度剖析一下這款優(yōu)秀的工具谱醇。接下來進(jìn)階篇主要講一下云呼叫中心是如何構(gòu)建的暇仲。
進(jìn)階篇
市面上大部分呼叫中心類型產(chǎn)品有幾類做法，坐席端要么針對各類操作系統(tǒng)開發(fā)相關(guān)的APP或SDK副渴，要么使用OCX控件來集成終端音頻能力奈附，采用pjsip等類似的開源或自研協(xié)議棧在udp/tcp通道上傳輸標(biāo)準(zhǔn)的sip協(xié)議，連接到指定的FreeSWITCH軟交換煮剧，另一端采用E1線從運(yùn)營商接入使用OpenVox板卡或其它廠商的硬件轉(zhuǎn)換網(wǎng)關(guān)把pri信令轉(zhuǎn)成sip信令接入斥滤。
對于軟交換核心的穩(wěn)定性主要是采用的雙機(jī)熱備方案，如下圖所示勉盅，這也是最常規(guī)的接入方式和高可用的方案佑颇。對于軟交換來說主從實(shí)例能共用DB或Cache中的同一份Session數(shù)據(jù)，存儲了雙邊通道的協(xié)商信息草娜，我們都知道FreeSWITCH是一個有狀態(tài)的服務(wù)挑胸，所有會話信息都在內(nèi)存中處理，也會同步到db或Cache宰闰，當(dāng)主節(jié)點(diǎn)掛掉后茬贵，從節(jié)點(diǎn)接管時會初始化DB或者Cache中的會話信息進(jìn)行會話實(shí)例的重新加載。對于終端來說在服務(wù)切換時有短暫的無聲情況议蟆，如果媒體端口在防火墻等設(shè)備上仍然是暢通時直接就可以恢復(fù)媒體流闷沥，當(dāng)發(fā)現(xiàn)端口不通時會通過reinvite來重新協(xié)商，整個過程非常短暫咐容。這種模式是最流行的一種高可用方案，也是硬件廠商最常使用的一種方式蚂维。
賬號體系可以用Doc文檔或者DB方式管理戳粒，IVR樹，ACD坐席分配虫啥，QUEUE入隊(duì)蔚约，Cdr計(jì)費(fèi)話單生成等管理，全部使FreeSWITCH自身的模塊功能來構(gòu)建涂籽，這種方式短小精悍苹祟，高內(nèi)聚。它的最大的問題就是并發(fā)能力有限评雌，在8U16C的主機(jī)上做過測試树枫，在做過深度調(diào)優(yōu)的情況下能支撐1800Chennel通話音質(zhì)無損失。單個小企業(yè)內(nèi)部支撐完全沒有問題景东。
當(dāng)我們要做一個云呼叫中心提供給眾多企業(yè)一起使用砂轻，需要萬級甚至十萬級同時并發(fā)通話時，上述方式已經(jīng)很難支撐斤吐。FreeSWITCH官方作者也講述了這類問題搔涝，并表示現(xiàn)有的架構(gòu)體系很難支持Cluster方式厨喂，需要自己來解決。我們不需要發(fā)明創(chuàng)造庄呈，完全可以借鑒Redis的Proxy集群方案和Dubbo服務(wù)發(fā)現(xiàn)方案蜕煌，組合使用即是一個能級聯(lián)分布，橫向擴(kuò)展性能無衰減诬留，服務(wù)上線能自動發(fā)現(xiàn)幌绍，服務(wù)異常能自動下線的高可用軟交換集群，如下圖：
先講一下幾個關(guān)鍵的網(wǎng)元節(jié)點(diǎn)故响，其中媒體交換中心集群傀广、路由中心集群、接入中繼集群都是使用FreeSWITCH來實(shí)現(xiàn)彩届，接入代理集群都是使用Kamailio來實(shí)現(xiàn)伪冰。最核心的就是：
fs-media：媒體交換中心集群；
fs-router：路由中心集群樟蠕；
fs-tandem：接入中繼網(wǎng)關(guān)贮聂；
kama-pstn：企業(yè)接入代理；
kama-wss：坐席接入代理寨辩。
為什么接入代理使用Kamailio而不是FreeSWITCH呢吓懈？它們的接入準(zhǔn)標(biāo)都是一樣的，原則上來講都可以作為接入代理靡狞，但是他們的側(cè)重點(diǎn)不同耻警，FreeSWITCH更注重媒體的處理，及號碼變換甸怕，Kamailio更注重的是NAT網(wǎng)絡(luò)穿透甘穿，信令路由尋址。Kamailio可以在呼叫的整個流程中分析梢杭、存儲温兼、變換SIP協(xié)議頭部或包體中的各項(xiàng)參數(shù)。比如：在NAT環(huán)境中SIP請求在每經(jīng)過一個代理節(jié)點(diǎn)都會在頭部添加一項(xiàng)Record-Route/Route武契，在響應(yīng)消息時每經(jīng)過一個代理節(jié)點(diǎn)都會在頭部刪除一項(xiàng)Record-Route/Route募判，同時會在頭部攜帶各種標(biāo)識,也會攜帶contact，from咒唆，to等字段届垫。當(dāng)有NAT環(huán)境時需要在代理上主動來對這些字段對內(nèi)外網(wǎng)的IP,Port等做替換。如果未進(jìn)行轉(zhuǎn)換钧排，這條到達(dá)本網(wǎng)關(guān)的消息會路由到錯誤的IP,Port上去敦腔，最終的結(jié)果就是信令不通，協(xié)商超時等不成功恨溜。對于網(wǎng)絡(luò)環(huán)境這塊兒是傳統(tǒng)通信最大的問題符衔，沒有統(tǒng)一規(guī)范和標(biāo)準(zhǔn)可尋找前，只能實(shí)際拔測抓現(xiàn)場報(bào)文來分析并解決問題。如下圖所示判族，即本方案的代理接入：
在企業(yè)內(nèi)部一般都會采取媒體交換,CTI集成系統(tǒng)全都部署在內(nèi)網(wǎng)躺盛，坐席終端一般也在同一辦公網(wǎng)環(huán)境，也有在家等公網(wǎng)場合形帮，這種情況是最為復(fù)雜的槽惫，因?yàn)榧扔泄W(wǎng)，又要支持內(nèi)網(wǎng)辩撑。我們可以將媒體全部監(jiān)聽在內(nèi)網(wǎng)IP, 在代理出口使用Kamailio+RTPEngine來構(gòu)建一個SBC網(wǎng)元做信令和媒體的代理界斜，如果遇到對稱型網(wǎng)絡(luò)NAT類型,無法進(jìn)行NAT穿透時，終端可以采取ICE接入合冀。本圖是一個WebRTC終端的坐席代理側(cè)各薇，Web終端使用jssip來接入，我們使用Kamailio的ws模塊來解析并剝除協(xié)議內(nèi)容將解析出來的標(biāo)準(zhǔn)Sip再路由轉(zhuǎn)發(fā)給FreeSWITCH君躺。
協(xié)議的下一跳即是fs-router集群了峭判，fs-router的主要功能有兩點(diǎn)，其一是：注冊路由的保持棕叫，當(dāng)有被叫時需要推送至客服端進(jìn)行尋址林螃。其二是：會話中間消息的路由轉(zhuǎn)發(fā)層。首先要講的是從代理集群上的信令怎么尋址到fs-router集群的一臺具體的主機(jī)上呢俺泣？kama-wss會通過策略服務(wù)以Session為基本單位進(jìn)行分配疗认，分配規(guī)則是通過fs-router節(jié)點(diǎn)實(shí)時監(jiān)測的并發(fā)會話數(shù)來取最輕負(fù)載優(yōu)先。當(dāng)然也支持隨機(jī)砌滞，hash侮邀，順序，加權(quán)隨機(jī)等機(jī)制贝润。只有在invite消息即會話開始時會選擇一個節(jié)點(diǎn)，在會話的整個生命周期內(nèi)都落在本節(jié)點(diǎn)上铝宵。同時并將Session記錄到公共緩存打掘，當(dāng)本節(jié)點(diǎn)宕機(jī)時，在會話過程中的指令尋址到fs-router集群時會通過緩存找到router節(jié)點(diǎn)鹏秋，通過zk的存活檢測最終會發(fā)現(xiàn)本節(jié)點(diǎn)已無效尊蚁，在此刻會重新分配fs-router節(jié)點(diǎn)，reinvite進(jìn)行重新協(xié)商然后恢復(fù)通話侣夷。
為什么需要存在fs-router這個節(jié)點(diǎn)呢横朋？它到底能解決什么問題？主要是為了解決單臺媒體服容量上限及數(shù)據(jù)傾斜問題百拓。如果沒有這個路由節(jié)點(diǎn)琴锭，當(dāng)前集群流量以租戶為單位晰甚，可以通過tenantId來劃分流量，將一個企業(yè)下的所有通話都引流到一個軟交換媒體服上去决帖，這樣做有一個弊端厕九，當(dāng)一個企業(yè)的客服數(shù)或并發(fā)通話量過大時就會超出一臺媒體服的容量上限，按租戶來劃分流量就會導(dǎo)致數(shù)據(jù)傾斜地回，資源使用不均衡扁远。引入fs-router就是為了解決此問題，它可以將注冊和媒體分離刻像，原來按租戶來進(jìn)行的流量劃分就可以做到粒度更小的按會話來劃分畅买，只需要將同一會話參與的兩端或多端引流到同一臺媒體服,會話生命周期結(jié)束后就會重新分配。
協(xié)議的再下一跳即是fs-media集群了尋址方式和kama-wss到fs-router類似,同樣是借助策略服務(wù)及狀態(tài)服務(wù)來發(fā)現(xiàn)服務(wù)的可用性及負(fù)載情況來在初始會話時選擇一個具體節(jié)點(diǎn)细睡，在會話的過程中通過緩存來進(jìn)行真正尋址谷羞，當(dāng)有服務(wù)異常的情況做同樣的處理。唯一不同的就是fs-router和fs-media是雙向?qū)Φ鹊姆?wù)接入方式纹冤。洒宝，對于媒體交換節(jié)點(diǎn)的主控服務(wù)采取ESL內(nèi)聯(lián)模式，主要實(shí)現(xiàn)了一個業(yè)務(wù)層與通信層的一個離散萌京、聚合雁歌，協(xié)議轉(zhuǎn)換包裝，業(yè)務(wù)拆解與分發(fā)的主控服務(wù)如下圖所示：
fs-media集群又可以按租戶來進(jìn)行劃分也可以按功能來進(jìn)行劃分知残，真正做到租戶間的物理隔離及功能間的物理隔離靠瞎，可以分為通用媒體集群，灰度媒體集群求妹，外呼機(jī)器人媒體集群乏盐，呼入機(jī)器人媒體集群，預(yù)測試外呼媒體集群制恍，電話會議媒體集群父能，內(nèi)部通話媒體集群等，可隨意按需定制净神，如下圖所示何吝，為媒體集群節(jié)點(diǎn)注冊時的數(shù)據(jù)模型，主要通過租戶表來區(qū)分企業(yè)鹃唯，通過應(yīng)用節(jié)點(diǎn)表來區(qū)分FS節(jié)點(diǎn)為路由節(jié)點(diǎn)還是媒體節(jié)點(diǎn)爱榕，通過企業(yè)應(yīng)用表來做節(jié)點(diǎn)和企業(yè)關(guān)聯(lián)可做到以企業(yè)粒度隨意切換。媒體集群是有狀態(tài)的坡慌，但此種設(shè)計(jì)可以支持熱切換黔酥，如正在通話中從一個集群切至另一個集群時，本次通話仍在切換前的集群上工作，新建的會話都會直接建立在新的集群上跪者，當(dāng)老的通話全部結(jié)束后再轉(zhuǎn)移到新集群棵帽，需要注意的是如果服務(wù)要下線必須得先unregister，觀察流量為0時才能真正下線坑夯。
協(xié)議的再下一跳就是線路落地岖寞，云呼叫中心的線路落地采取兩種方式，一種是混合云的方式柜蜈，另一種是純云的方式仗谆。混合云是適應(yīng)傳統(tǒng)企業(yè)內(nèi)部有拉過運(yùn)營商E1線專線，或者有自己的PBX系統(tǒng)淑履，可以方便的接入到云呼叫中心上來隶垮，這種方式和企業(yè)內(nèi)部復(fù)雜的網(wǎng)絡(luò)有關(guān)，所以在云端也采取了對網(wǎng)絡(luò)穿透適配性更好的kama-pstn代理來對接秘噪，可以無任何限制的對NAT環(huán)境做協(xié)議變換狸吞。而純云的方式主要是和各大運(yùn)營商進(jìn)行對接，能滿足企業(yè)客戶線上操作即可接入指煎，省去很多不必要的技術(shù)對接工作蹋偏，達(dá)到即開即用的目的，由于都是對等連接至壤，但是運(yùn)營商過來的號碼關(guān)系比較復(fù)雜威始，但網(wǎng)絡(luò)情況比較單一，采用了fs-tandem中繼網(wǎng)關(guān)的方式來對接像街，重點(diǎn)保障安全認(rèn)證和號碼變換黎棠。
下圖是一通呼叫從坐席注冊，用戶到坐席的一個接入流程镰绎，遵循SIP的流程機(jī)制脓斩，就不展開討論了。
總結(jié)
點(diǎn)：我們先從FreeSWITCH這個核心點(diǎn)講述了它是一個核心軟交換應(yīng)用畴栖，及功能特性随静。
線：又從搭建一個小型的PBX及功能調(diào)測以及可以連接哪些終端來連成一條可P2P的音視頻通話的線。
面：繼續(xù)通過講企業(yè)內(nèi)部的呼叫中心應(yīng)用展開成面討論到了一個呼叫中心應(yīng)具備的基本要素吗讶。
體：最后通過云呼叫中心的高可用挪挤，分布式，高性能关翎，多租戶的架構(gòu)設(shè)計(jì)方案匯聚成體，詮釋了一套商業(yè)化可行的體系鸠信。
本文我們只從總體來講解了一下呼叫中心云化必須具備的設(shè)計(jì)方案纵寝。云呼叫中心要關(guān)注或要解決的問題點(diǎn)還很多，通話質(zhì)量是一個不可或缺的關(guān)注點(diǎn)，如何監(jiān)測平臺整體性的通話質(zhì)量爽茴，如何進(jìn)行通話質(zhì)量調(diào)優(yōu)葬凳，是流媒體平臺必不可少的研究課題。同智能化AI機(jī)器人接軌也是一個比較熱門的話題室奏，如何實(shí)時質(zhì)檢火焰，如何智能推薦話術(shù)輔助辦公，如何進(jìn)行通話預(yù)測胧沫，如何進(jìn)行智能監(jiān)控及風(fēng)控管理昌简，是當(dāng)下做商業(yè)服務(wù)一體化應(yīng)用必須研究的課題。呼叫中心雖然是一個有年代感的應(yīng)用系統(tǒng)绒怨，但是它隨著時代的變遷也正日益茁壯的成長纯赎，給企業(yè)帶來的價值不可小覷，讓我們一起擁抱變化迎接新的挑戰(zhàn)吧南蹂！
