從入門到進階-如何基於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機器人接軌也是一個比較熱門的話題，如何實時質檢，如何智能推薦話術輔助辦公，如何進行通話預測，如何進行智能監控及風控管理，是當下作商業服務一體化應用必須研究的課題。呼叫中心雖然是一個有年代感的應用系統，可是它隨着時代的變遷也正日益茁壯的成長，給企業帶來的價值不可小覷，讓咱們一塊兒擁抱變化迎接新的挑戰吧！