前言
兩年來，新冠疫情給我們的工作生活帶來了巨大影響，社會各界都面臨著嚴峻的挑戰。汽車之家敏銳的洞察到降低人力成本，篩選高優客戶、提高意向成交率已經成為各主機廠的迫切需求，因此，智能外呼平臺，應運而生。
通過對市面上的幾款外呼平臺調研，發現有很多業務場景并不支持，不僅可擴展性差、而且維護成本高，所以為了更好地承接主機廠業務，滿足客戶定制化需求，決定研發自己的智能外呼平臺。
常見的外呼平臺都是基于VoIP（Voice over Internet Protocol，縮寫為VoIP）實現的，VoIP是基于IP的語音傳輸，是一種語音通話技術，經由網際協議（IP）來達成語音通話與多媒體會議。
VoIP電話
不同于傳統的電話，VoIP是一種新興的電話通信方式。它是一種把語音技術集成在IP協議中，通過互聯網進行傳輸的一種全新的通信方式，其成本遠低于傳統電話。
- VoIP電話優點
- VoIP平臺的選擇
目前國內比較流行和擁有大量活躍用戶的是Freeswitch（https://freeswitch.org/）和 Asterisk（http://www.asterisk.org/）
下圖為二者的簡單對比：
結論：基于以上調研和對比，發現Freeswitch的資料相對完備，學習成本低，并且已有較多的成功案例，很多外呼供應商都采用Freeswitch作為軟交換平臺。因此，Freeswitch也 將是我們更優的選擇。
初識Freeswitch
Freeswitch是一個開源的電話交換平臺。官方給它的定義是——世界上第一個跨平臺的、伸縮性極好的、免費的、多協議的電話軟交換平臺。在Freeswitch出現之前，軟交換技術基本上掌握在少數通信企業，集成在硬件設備上整機出售，價格昂貴。需要大量的專業積累才能入門，使用者基本上偏運維，無法掌握實質的技術。
當Freeswitch以BypassMedia(旁路模式：此模式下freeswitch更像是一個信令proxy，媒體不會通過freeswitch，sdp消息體不做修改，沒有錄音，二次撥號等功能)運作時，它和其它VoIP通信原理一致，同樣是點到點的實時通信。負責通話雙方的媒體協商，交換RTP端口，編解碼等信息，詳細的SIP協議或協商流程可參見：RFC3261文檔，源碼及編譯安裝可以參見Freeswitch官網。
- Freeswitch運行機制
Freeswitch內部使用線程模型來處理并發請求，每個連接都在單獨的線程中進行處理，不同的線程間通過Mutex互斥訪問共享資源，并通過消息和異步事件等方式進行通信。這種架構能處理很高的并發， 并且在多核環境中運算能均勻地分布到多顆CPU或單CPU的多個核心上。Freeswitch的核心非常短小精悍，這也是其保持穩定的關鍵。絕大部分應用層的功能都在外圍的模塊中實現。外圍模塊是可以動態加載（以及卸載）的，在實際應用中可以只加載用到的模塊。外圍模塊通過核心提供的Public API與核心進行通信，而核心則通過回調（或稱鉤子）機制執行外圍模塊中的代碼。
- 開發模式的選擇
Freeswitch的開發模式有兩種：
- 面向服務器開發，這種開發模式是基于腳本內嵌的方式，主要開發lua腳本或者使用C語言開發mod，開發人員的學習成本高，不易維護，腳本之間無法復用；
- 面向客戶端開發，Freeswitch支持多種語言，開發人員可以使用自己熟悉的開發語言(java)。通過調用核心API的方式，可以控制整個會話流程。
綜上所述：雖然lua腳本或C語言的執行效率更高，但是客戶端的開發模式更加方便定制化開發，易于開發，況且把復雜的業務邏輯放在Freeswitch服務端不利于后續的維護和擴展。面向客戶端開發有2種連接模式：內連（Inbound）模式和外連（Outbound）模式。這里我們僅說下內連模式
在內連模式下，Freeswitch作為一個服務器，而用戶的程序可以作為一個TCP Client主動連接到Freeswitch上。同樣，Freeswitch允許多個客戶端連接。每個客戶端連接上來以后，可以訂閱Freeswitch的內部事件，實現可定制化開發。
例如：電話轉接、定制化彩鈴等都可以通過內聯模式實現控制。
- Freeswitch下基于sip協議的呼叫流程
下面給出了上述調用流程的逐步解釋
- 發送到代理服務器的INVITE請求負責啟動會話。
- 代理服務器立即向呼叫者(Alice)發送 100 Trying 響應以停止INVITE請求的重傳。
- 代理服務器在位置服務器中搜索Bob的地址。在獲得地址之后，它進一步轉發INVITE請求。
- 此后，由Bob產生的 180響鈴(臨時響應)被返回給Alice。
- Bob在接聽電話后立即生成 200 OK 響應。Alice收到 200 OK 時，Bob會收到來自Alice的 ACK 。
- 同時，會話建立并且RTP分組(對話)開始從兩端流動。
- 在對話之后，任何參與者(Alice或Bob)可以發送 BYE 請求以終止會話。BYE 直接從Alice到Bob繞過代理服務器。
- 最后，Bob發送 200 OK 響應以確認BYE并且會話終止。
- 在上述基本呼叫流程中，三個事務(標記為1,2,3)可用。
完整的呼叫(從INVITE到200 OK)稱為 Dialog 。
- Freeswitch主要配置文件
Freeswitch的核心底層代碼是由C語言編寫，如果需要重構Freeswitch核心功能、基于Freeswitch二次開發軟交換，或者針對Freeswitch開發其他自定義模塊，則需要在符合Freeswitch開發規范的情況下進行改造。而使用Freeswitch或者針對Freeswitch做esl應用端開發，則基本不需要更改Freeswitch底層代碼邏輯，Freeswitch是通過提供基于靜態xml的文件配置方式，來實現對Freeswitch所有功能的配置和調度控制。
撥號計劃（dialplan）是Freeswitch配置文件中至關重要的一部分，它的主要作用就是對電話進行路由。就是當一個用戶撥號時，對用戶所撥的號碼進行分析，進而決定下一步該做 什么。如：可以撥打9197進行接通音樂校驗，撥打1001不在線進入語音信箱留言等，通過撥號計劃可以達到領編碼進行功能的擴展。
由于Freeswitch知識點較多，每一個知識點展開討論都比較大，以上篇幅僅把Freeswitch使用過程中的主要知識點做了介紹。接下來講解下Freeswitch服務中心的演化構建。
Freeswitch 服務中心的演變
- 單Freeswitch服務（1.0）
在智能外呼服務從0到1的孵化過程中，如何保證各個功能點正確實現，業務順利推進是首先需要解決的核心問題。一個簡單的Freeswitch單體架構，是可以滿足智能機器人的外呼通話要求。
外呼機器人撥打流程：
- Freeswitch服務啟動成功；
- 建立私有分機號，作為機器人賬號；
- 機器人通過撥號規則調用Freeswitch；
- Freeswitch接收到撥號后調用配置的網關，把要呼叫的號碼經防火墻后，發送給線路運營商；
- 線路商收到呼叫請求后，連接用戶手機號，最終建立外呼機器人到用戶手機的通信通道。
單體架構問題：
- 1. 存在單點故障風險，從而會導致整個外呼系統癱瘓；2. 并發能力有限。
- 負載均衡（2.0）
隨著業務的的增長，外呼量會越來越大，對服務的穩定性要求也越來越高，對Freeswitch的高可用集群的訴求也被提上日程。
Freeswitch的高可用部署方式有兩種：主備切換和負載均衡，官方文檔介紹的主備切換部署是采用Corosync & Pacemaker，負載均衡采用前置opensips。
為了解決1.0 版本所面臨的性能不足和單點故障風險，引入opensips前置于Freeswitch服務作為信令負載。
Freeswitch負載均衡架構圖如上圖所示，使用opensips服務作為負載控制端。
工作流程：
- 外呼請求通過opensips服務動態分配可用的Freeswitch服務;
- Freeswitch接入mysql數據庫，存儲雙邊通道信息，共用同一份Session數據，保持通話；
- 客戶端與Freeswitch服務直接建立連接；
- 外呼服務接收到轉人工請求，直接通過ESL調用App命令進行撥號路由轉接。
當我們的服務中心需要提供給眾多的主機廠業務一起使用時候，需要萬級甚至十萬級同時并發通話時，上述方式很難支持。
新的的問題緊隨而至：1. 每新增一臺服務器都需要和線路商對接，增加了對接的難度；2. 每新增一臺服務器，保持端口一致的情況下，需要占用一個公網ip地址。
- 匯接局模式+負載均衡（3.0）
上述2.0方案中，隨著外呼業務量的增多，并發量的增大，相應需要部署的Freeswitch服務也會越來越多，從而導致公網ip使用成本上升。為了解決上述問題，進一步提升并發量，引入匯接局+負載均衡的模式。
核心節點：
- fs-router 路由中心
- fs-media 媒體交換中心
fs-router路由中心主要有2個功能點，其一是：撥號尋址，線路對接。其二是：會話中間消息路由的轉發。
fs-media媒體交換中心主要作為媒體（通話語音）傳遞，以及ESL通過Api和命令的方式對fs-media的調用。工作流程：
- 外呼請求通過opensips服務動態分配可用的freeswitch服務;
- fs-media接入mysql數據庫，存儲雙邊通道信息，共用同一份Session數據，以便保持通話；
- fs-mediaA/B(媒體終結服務) 經撥號路由轉發給fs-router，由fs-router和線路商進行sip信令的交互；
- 通信建立成功后由fs-mediaA/B直接和線路商進行語音流傳遞；
- 客戶端通過fs-mediaA/B和用戶進行通話。
匯接局+負載均衡模式的優勢：
- 匯接局模式，解決公網ip的占用問題；
- 統一出局，簡化線路商對接；
- 方便擴展，簡化新增服務配置；
- 由于集群式的部署，可以通過撥號方式的配置，針對不同的租戶，分配到不同的fs-media上，做到租戶之間的物理隔離。
總結
從第一次語音傳輸在1876年使用振鈴電路實現，到現在通過網絡來實現的新型電話通信，歷經了100多年，每一次通信的革新都離不開科技的進步。VoIP網絡電話的興起，不僅預示著通信方式的革新，而且標志著新一代呼叫中心成為了電話通信的寵兒。隨著Freeswitch服務中心的持續建設，通信業務層面的價值會逐步提升，打破了交換技術掌握在少數通信企業的壁壘，降低了接入難度和使用成本。從1.0的單一服務到3.0的匯接局+負載均衡，在架構升級后，Freeswitch服務中心不僅滿足高并發，多租戶的業務場景，而且還保證了服務的高可用、簡化了對接流程、方便了服務的擴展。
- 展望
新一代的呼叫中心更多地融入了媒體渠道與通信渠道。未來，在業務層面，Freeswitch服務中心不僅適應于智能外呼平臺，同時可滿足其他業務場景的使用。如：人機協同、在線客服、多人會議、視頻通話、排隊等待來電呼入等諸多場景。在技術層面，不僅要考慮性能和可用性的提升，而且還要兼顧其通話、視頻等質量的提高。通過多fs-router（路由中心），進一步提高它的性能和可用性。最后，追隨技術的腳步，迎接新的挑戰。
文章參考：
- SIP 教程：https://www.w3cschool.cn/session_initiation_protocol/
- Freeswitch權威指南
