文 | 楊先君

智慧企業(yè)架構師、技術經理

今天和大家分享一下

如何基于FreeSWITCH搭建一個呼叫中心平臺

入門篇

FreeSWITCH 是一個開源的電話交換平臺。官方給它的定義是–世界上第一個跨平臺的、伸縮性極好的、免費的、多協(xié)議的電話軟交換平臺。 在FreeSWITCH出現(xiàn)之前，軟交換技術是高不可攀的領域，這種技術基本上掌握在少數(shù)通信企業(yè)，集成在硬件設備上整機出售，價格昂貴。需要大量的專業(yè)積累才能入門，使用者基本上偏運維，無法掌握實質的技術。而現(xiàn)在，越來越多的開發(fā)者通過FreeSWITCH來深入了解通信技術。

FreeSWITCH的本質和其它VoIP通信原理一致同樣是點到點的實時通信。當FS以BypassMedia運作時，它即是兩個終端進行實時通信的一個橋梁和工具，負責雙方媒體通道協(xié)商，交換雙方的RTP端口，編解碼，碼率等信息，詳細的SIP協(xié)議或協(xié)商流程可參見：RFC3261文檔，源碼及編譯安裝可以參見FreeSWITCH官網。

當服務啟動完成后，即呈現(xiàn)一個完整的PBX(Private Branch Exchange)系統(tǒng)。直接使用x-lite終端輸入分機號及密碼就能建立P2P通道來傳輸媒體流實現(xiàn)點到點通話。撥號計劃是FreeSWITCH中至關重要的一部分。它的主要作用就是對電話進行路由。就是當一個用戶撥號時，對用戶所撥的號碼進行分析，進而決定下一步該做什么。它所能做的比你想象的要強大的多。如：可以撥打9196進行回聲檢測測試媒體是否暢通，拔打3000進行電話/視頻會議接入，不在線時進行語音留言等，也可以構建IM通信服務完成點到點的文本消息及實時文件傳輸，這些拔號計劃可以達到零編碼來進行功能擴展。同樣可以通過Endpoint模塊來實現(xiàn)不同種類的終端進行互聯(lián)通話，如下圖所示：

當然做信令代理并不是FS的強項和它做為軟交換身份的常規(guī)用途。由于SIP協(xié)議的特殊性(帶狀態(tài)的協(xié)議)，使得它在內網和公網變換且進行NAT穿透時成了一個大麻煩，需要對sip協(xié)議的頭部及包體的SDP信息都要做深度的定制。做信令代理通常都會直接使用openSIPS/Kamailio，后邊的進階篇時再詳說。正常情況下FS同終端之間的連接方式如下圖，媒體服暴露在公網，信令及媒體均通過其進行傳遞，目的是媒體通過服務端后就可以做媒體的播放，橋接，變更，混合，存儲等動作，達到媒體交換的目的。也正是我們后邊講到作為呼叫中心核心網元的常規(guī)操作。

點到點通信的終端可以是Linphone/X-lite這種應用也可以是PSTN電信交換網的接入接出設備，兩者的共同點是都遵循SIP標準可以無縫接入，不同點是來自PSTN網終相對穩(wěn)定且編碼大多是G711，來自互聯(lián)網應用終端如果是移動設備有弱網情況存在，為了應對這種情況就會有iLBC、OPUS、G729、GSM等編碼，也有各種丟包補償機制、抗抖動策略等相關算法。

目前WebRTC的實時音視頻已經比較成熟，很多音視頻的平臺都利用其來搭建自已的點到點或者音視頻會議服務，F(xiàn)reeSWITCH同樣也可以做為RTC的媒體交換參與其中。FS加載mod_sofia及mod_rtc模塊,默認監(jiān)聽在7443端口，來處理wss sip的信令進行sdp協(xié)商，協(xié)商后直接進行rtp在加密通道上進行傳輸。同樣默認監(jiān)聽在5060端口，來處理在tcp或udp通道上的sip協(xié)議進行sdp協(xié)商。

FS怎么做到不同端點之間的轉換呢？主要通過sip_profile來進行擴展，將SIP會話的流程轉變成會話的有限態(tài)機來進行維持。將協(xié)商的參數(shù)存于臨時會話結構上，在FS上針對每個通話建立一個Session，每個參與的端點都做為其中一條Leg生成一個Channel，綁定到Session上，針對媒體如果有加密先進行解密，有編碼的再進行解碼，最終都會轉換成L16線性脈沖編碼存于緩沖區(qū)，當雙邊媒體通道打通時互相取對端的緩沖區(qū)數(shù)據(jù)進行傳遞，到對端端點后再根據(jù)協(xié)商的格式進行編碼，如果需要媒體流加密的再進行加密，如果單邊接通FS也能主動play到對端，如果需要對媒體進行轉儲采用mediaBug進行媒體轉發(fā)，轉發(fā)一路給錄音模塊或文件存儲模塊進行儲存。WEB服務端會通過jssip來封裝SIP協(xié)議棧并通過瀏覽器來加載WebRTC能力進行媒體協(xié)商，協(xié)商成功后Browser直接和FS進行媒體交換。如下圖：

以上限于篇幅，分別點了一下FS做為一個小型的PBX的構建網元，以及如何協(xié)同工作的，其中的每一個知識點展開講都比較大，比如：FS中的核心構造有哪些，是如何工作的；分別有哪些端點，主要完成了哪些工作；它的編解碼模塊；它的帳號認證模塊；它的撥號計劃模塊；它的內部三級隊列的事件分發(fā)機制；它的ESL事件驅動內聯(lián)/外聯(lián)模式如何進行主控；還有和AI是如何打通的，如何實現(xiàn)這樣的模塊，等等。如果后邊有機會會進行一系列連載，深度剖析一下這款優(yōu)秀的工具。接下來進階篇主要講一下云呼叫中心是如何構建的。

進階篇

市面上大部分呼叫中心類型產品有幾類做法，坐席端要么針對各類操作系統(tǒng)開發(fā)相關的APP或SDK，要么使用OCX控件來集成終端音頻能力，采用pjsip等類似的開源或自研協(xié)議棧在udp/tcp通道上傳輸標準的sip協(xié)議，連接到指定的FreeSWITCH軟交換，另一端采用E1線從運營商接入使用OpenVox板卡或其它廠商的硬件轉換網關把pri信令轉成sip信令接入。

對于軟交換核心的穩(wěn)定性主要是采用的雙機熱備方案，如下圖所示，這也是最常規(guī)的接入方式和高可用的方案。對于軟交換來說主從實例能共用DB或Cache中的同一份Session數(shù)據(jù)，存儲了雙邊通道的協(xié)商信息，我們都知道FreeSWITCH是一個有狀態(tài)的服務，所有會話信息都在內存中處理，也會同步到db或Cache，當主節(jié)點掛掉后，從節(jié)點接管時會初始化DB或者Cache中的會話信息進行會話實例的重新加載。

對于終端來說在服務切換時有短暫的無聲情況，如果媒體端口在防火墻等設備上仍然是暢通時直接就可以恢復媒體流，當發(fā)現(xiàn)端口不通時會通過reinvite來重新協(xié)商，整個過程非常短暫。這種模式是最流行的一種高可用方案，也是硬件廠商最常使用的一種方式。

賬號體系可以用Doc文檔或者DB方式管理，IVR樹，ACD坐席分配，QUEUE入隊，Cdr計費話單生成等管理，全部使FreeSWITCH自身的模塊功能來構建，這種方式短小精悍，高內聚。它的最大的問題就是并發(fā)能力有限，在8U16C的主機上做過測試，在做過深度調優(yōu)的情況下能支撐1800Chennel通話音質無損失。單個小企業(yè)內部支撐完全沒有問題。

當我們要做一個云呼叫中心提供給眾多企業(yè)一起使用，需要萬級甚至十萬級同時并發(fā)通話時，上述方式已經很難支撐。FreeSWITCH官方作者也講述了這類問題，并表示現(xiàn)有的架構體系很難支持Cluster方式，需要自己來解決。

我們不需要發(fā)明創(chuàng)造，完全可以借鑒Redis的Proxy集群方案和Dubbo服務發(fā)現(xiàn)方案，組合使用即是一個能級聯(lián)分布，橫向擴展性能無衰減，服務上線能自動發(fā)現(xiàn)，服務異常能自動下線的高可用軟交換集群，如下圖：

先講一下幾個關鍵的網元節(jié)點，其中媒體交換中心集群、路由中心集群、接入中繼集群都是使用FreeSWITCH來實現(xiàn)，接入代理集群都是使用Kamailio來實現(xiàn)。最核心的就是：

• fs-media：媒體交換中心集群；
• fs-router：路由中心集群；
• fs-tandem：接入中繼網關；
• kama-pstn：企業(yè)接入代理；
• kama-wss：坐席接入代理。

為什么接入代理使用Kamailio而不是FreeSWITCH呢？它們的接入準標都是一樣的，原則上來講都可以作為接入代理，但是他們的側重點不同，FreeSWITCH更注重媒體的處理，及號碼變換，Kamailio更注重的是NAT網絡穿透，信令路由尋址。Kamailio可以在呼叫的整個流程中分析、存儲、變換SIP協(xié)議頭部或包體中的各項參數(shù)。比如：在NAT環(huán)境中SIP請求在每經過一個代理節(jié)點都會在頭部添加一項Record-Route/Route，在響應消息時每經過一個代理節(jié)點都會在頭部刪除一項Record-Route/Route，同時會在頭部攜帶各種標識,也會攜帶contact，from，to等字段。

當有NAT環(huán)境時需要在代理上主動來對這些字段對內外網的IP,Port等做替換。如果未進行轉換，這條到達本網關的消息會路由到錯誤的IP,Port上去，最終的結果就是信令不通，協(xié)商超時等不成功。對于網絡環(huán)境這塊兒是傳統(tǒng)通信最大的問題，沒有統(tǒng)一規(guī)范和標準可尋，只能實際拔測抓現(xiàn)場報文來分析并解決問題。如下圖所示，即本方案的代理接入：

在企業(yè)內部一般都會采取媒體交換,CTI集成系統(tǒng)全都部署在內網，坐席終端一般也在同一辦公網環(huán)境，也有在家等公網場合，這種情況是最為復雜的，因為既有公網，又要支持內網。我們可以將媒體全部監(jiān)聽在內網IP, 在代理出口使用Kamailio RTPEngine來構建一個SBC網元做信令和媒體的代理，如果遇到對稱型網絡NAT類型,無法進行NAT穿透時，終端可以采取ICE接入。本圖是一個WebRTC終端的坐席代理側，Web終端使用jssip來接入，我們使用Kamailio的ws模塊來解析并剝除協(xié)議內容將解析出來的標準Sip再路由轉發(fā)給FreeSWITCH。

協(xié)議的下一跳即是fs-router集群了，fs-router的主要功能有兩點，其一是：注冊路由的保持，當有被叫時需要推送至客服端進行尋址。其二是：會話中間消息的路由轉發(fā)層。首先要講的是從代理集群上的信令怎么尋址到fs-router集群的一臺具體的主機上呢？kama-wss會通過策略服務以Session為基本單位進行分配，分配規(guī)則是通過fs-router節(jié)點實時監(jiān)測的并發(fā)會話數(shù)來取最輕負載優(yōu)先。當然也支持隨機，hash，順序，加權隨機等機制。只有在invite消息即會話開始時會選擇一個節(jié)點，在會話的整個生命周期內都落在本節(jié)點上。同時并將Session記錄到公共緩存，當本節(jié)點宕機時，在會話過程中的指令尋址到fs-router集群時會通過緩存找到router節(jié)點，通過zk的存活檢測最終會發(fā)現(xiàn)本節(jié)點已無效，在此刻會重新分配fs-router節(jié)點，reinvite進行重新協(xié)商然后恢復通話。

為什么需要存在fs-router這個節(jié)點呢？它到底能解決什么問題？主要是為了解決單臺媒體服容量上限及數(shù)據(jù)傾斜問題。如果沒有這個路由節(jié)點，當前集群流量以租戶為單位，可以通過tenantId來劃分流量，將一個企業(yè)下的所有通話都引流到一個軟交換媒體服上去，這樣做有一個弊端，當一個企業(yè)的客服數(shù)或并發(fā)通話量過大時就會超出一臺媒體服的容量上限，按租戶來劃分流量就會導致數(shù)據(jù)傾斜，資源使用不均衡。引入fs-router就是為了解決此問題，它可以將注冊和媒體分離，原來按租戶來進行的流量劃分就可以做到粒度更小的按會話來劃分，只需要將同一會話參與的兩端或多端引流到同一臺媒體服,會話生命周期結束后就會重新分配。

協(xié)議的再下一跳即是fs-media集群了尋址方式和kama-wss到fs-router類似,同樣是借助策略服務及狀態(tài)服務來發(fā)現(xiàn)服務的可用性及負載情況來在初始會話時選擇一個具體節(jié)點，在會話的過程中通過緩存來進行真正尋址，當有服務異常的情況做同樣的處理。唯一不同的就是fs-router和fs-media是雙向對等的服務接入方式。對于媒體交換節(jié)點的主控服務采取ESL內聯(lián)模式，主要實現(xiàn)了一個業(yè)務層與通信層的一個離散、聚合，協(xié)議轉換包裝，業(yè)務拆解與分發(fā)的主控服務如下圖所示：

fs-media集群又可以按租戶來進行劃分也可以按功能來進行劃分，真正做到租戶間的物理隔離及功能間的物理隔離，可以分為通用媒體集群，灰度媒體集群，外呼機器人媒體集群，呼入機器人媒體集群，預測試外呼媒體集群，電話會議媒體集群，內部通話媒體集群等，可隨意按需定制，如下圖所示，為媒體集群節(jié)點注冊時的數(shù)據(jù)模型，主要通過租戶表來區(qū)分企業(yè)，通過應用節(jié)點表來區(qū)分FS節(jié)點為路由節(jié)點還是媒體節(jié)點，通過企業(yè)應用表來做節(jié)點和企業(yè)關聯(lián)可做到以企業(yè)粒度隨意切換。媒體集群是有狀態(tài)的，但此種設計可以支持熱切換，如正在通話中從一個集群切至另一個集群時，本次通話仍在切換前的集群上工作，新建的會話都會直接建立在新的集群上，當老的通話全部結束后再轉移到新集群，需要注意的是如果服務要下線必須得先unregister，觀察流量為0時才能真正下線。

協(xié)議的再下一跳就是線路落地，云呼叫中心的線路落地采取兩種方式，一種是混合云的方式，另一種是純云的方式。混合云是適應傳統(tǒng)企業(yè)內部有拉過運營商E1線專線，或者有自己的PBX系統(tǒng)，可以方便的接入到云呼叫中心上來，這種方式和企業(yè)內部復雜的網絡有關，所以在云端也采取了對網絡穿透適配性更好的kama-pstn代理來對接，可以無任何限制的對NAT環(huán)境做協(xié)議變換。而純云的方式主要是和各大運營商進行對接，能滿足企業(yè)客戶線上操作即可接入，省去很多不必要的技術對接工作，達到即開即用的目的，由于都是對等連接，但是運營商過來的號碼關系比較復雜，但網絡情況比較單一，采用了fs-tandem中繼網關的方式來對接，重點保障安全認證和號碼變換。

下圖是一通呼叫從坐席注冊，用戶到坐席的一個接入流程，遵循SIP的流程機制，就不展開討論了。

總結

點：我們先從FreeSWITCH這個核心點講述了它是一個核心軟交換應用，及功能特性。

線：又從搭建一個小型的PBX及功能調測以及可以連接哪些終端來連成一條可P2P的音視頻通話的線。

面：繼續(xù)通過講企業(yè)內部的呼叫中心應用展開成面討論到了一個呼叫中心應具備的基本要素。

體：最后通過云呼叫中心的高可用，分布式，高性能，多租戶的架構設計方案匯聚成體，詮釋了一套商業(yè)化可行的體系。

本文我們只從總體來講解了一下呼叫中心云化必須具備的設計方案。云呼叫中心要關注或要解決的問題點還很多，通話質量是一個不可或缺的關注點，如何監(jiān)測平臺整體性的通話質量，如何進行通話質量調優(yōu)，是流媒體平臺必不可少的研究課題。

同智能化AI機器人接軌也是一個比較熱門的話題，如何實時質檢，如何智能推薦話術輔助辦公，如何進行通話預測，如何進行智能監(jiān)控及風控管理，是當下做商業(yè)服務一體化應用必須研究的課題。呼叫中心雖然是一個有年代感的應用系統(tǒng)，但是它隨著時代的變遷也正日益茁壯的成長，給企業(yè)帶來的價值不可小覷，讓我們一起擁抱變化迎接新的挑戰(zhàn)吧！

作者:楊先君

來源:微信公眾號:網易智企技術

出處:https://mp.weixin.qq.com/s/_4zzmPh2FfFJSo-VuAoN0w