大家好，我是杜金房，此次分享和雙向通訊服務(wù)器FreeSWITCH以及WebRTC有關(guān)。首先我會為大家簡單介紹FreeSWITCH，鑒于FreeSWITCH主要用于通信領(lǐng)域，我也會介紹WebRTC并闡述FreeSWITCH與WebRTC的關(guān)系，同時結(jié)合FreeSWITCH的其他功能和使用場景與其功能以及所使用的多媒體庫，進一步探索AI技術(shù)加持下FreeSWITCH的未來發(fā)展。

　　FreeSWITCH是一套開源的，集成強大多媒體引擎的軟交換系統(tǒng)。FreeSWITCH主要基于C語言編寫，集成的眾多方便靈活的開發(fā)接口使其具有出色的互聯(lián)互通的能力，不僅兼容各種手機電話等終端設(shè)備并與各類軟件相互對接，也提供了對多種應(yīng)用場景如電話通信、視頻會議的支持。根據(jù)FreeSWITCH官方給出的數(shù)據(jù)，F(xiàn)reeSWITCH已成功被應(yīng)用于通信運營、在線教育、視頻會議與設(shè)備互聯(lián)網(wǎng)關(guān)等。

　　說到開源，想必大家不會對上圖展示的這些Logo感到陌生，包括像Linux、Android這樣的開源操作系統(tǒng)，MySQL等開源數(shù)據(jù)庫以及APACHE這樣的開源Web服務(wù)器。而通信領(lǐng)域也有兩個較具有代表性的開源軟件：Asterisk與這次重點介紹的FreeSWITCH。

　　其實在誕生初期FreeSWITCH主要被用來解決使用RJ11接口，基于電路交換原理實現(xiàn)的模擬電話機等傳統(tǒng)電話通信問題；隨著數(shù)字技術(shù)的發(fā)展，使用RJ45接口/Wi-Fi，基于分組交換的IP通信與在此基礎(chǔ)上進一步升級的視頻電話逐漸普及，成為過去十年人們溝通交流所使用最為頻繁的工具；同時由于互聯(lián)網(wǎng)技術(shù)的突飛猛進，越來越多的人有機會享用海量網(wǎng)絡(luò)資源，基于互聯(lián)網(wǎng)傳輸實現(xiàn)的各種實時通訊APP應(yīng)運而生。

　　從古代的烽火臺與語言交流到近現(xiàn)代的模擬電話，再到現(xiàn)如今人們再熟悉不過的數(shù)字電話，通信的進步可以說與社會生產(chǎn)力進步與人類文明發(fā)展密不可分。傳統(tǒng)的模擬電話通過傳輸模擬信號實現(xiàn)遠(yuǎn)距離聲音傳輸，而隨著傳輸距離的增大與傳輸條件的變化，模擬信號會在傳輸過程中遭受明顯衰減，這就需要安裝在接收端的信號放大器處理接收到的模擬信號從而使其中的關(guān)鍵信息更容易被獲�。坏�這樣做并非完美，放大聲音的同時如噪音、呼吸聲等環(huán)境雜音也會被放大，間接導(dǎo)致有效信號比率降低，直接帶來的影響便是遠(yuǎn)距離的通話雙方無法清晰而準(zhǔn)確地拾取對方所要表達(dá)的關(guān)鍵信息。

　　為了滿足遠(yuǎn)距離通信數(shù)據(jù)傳輸?shù)挠行�，�?shù)字通訊技術(shù)應(yīng)運而生。數(shù)字通訊可實現(xiàn)在進行遠(yuǎn)距離傳輸?shù)耐瑫r幾乎不損失通話質(zhì)量，從傳統(tǒng)的電話機到大家使用的第一款GSM手機再到現(xiàn)在的智能手機，可以說數(shù)字通訊極大改善了人們遠(yuǎn)距離溝通交流的方式。與此同時，從最早的撥號電話、GSM手機到3G、4G以至于未來的5G，通信技術(shù)的發(fā)展也可謂突飛猛進。通信技術(shù)的迭代也帶來了互聯(lián)網(wǎng)技術(shù)的飛躍。例如在4G/LTE誕生之前，由于通信所使用的網(wǎng)絡(luò)通道與網(wǎng)絡(luò)傳輸所使用的并不相同，用戶無法在打電話的同時訪問互聯(lián)網(wǎng)；而對4G/LTE而言，包括語音電話與訪問互聯(lián)網(wǎng)在內(nèi)的所有通訊活動都通過IP網(wǎng)絡(luò)傳輸數(shù)據(jù)，這就避免了打電話與訪問互聯(lián)網(wǎng)的沖突。

　　FreeSWITCH是一個開源的軟交換系統(tǒng)，所謂的軟交換是指不考慮終端類型，所有話機都可以通過FreeSWITCH與其他設(shè)備互聯(lián)互通。上圖中展示的終端除了有電話、手機，還有監(jiān)控攝像頭、視頻電話甚至RTMP、Flash等等。FreeSWITCH的特點就是可對接任何設(shè)備，例如通過瀏覽器可實現(xiàn)WebRTC與FreeSWITCH之間的通信，從而允許用戶通過瀏覽器撥打電話。

　　早期實現(xiàn)瀏覽器撥打電話一般需要ActiveX技術(shù)的輔助，這是IE上的一個插件系統(tǒng)；與此類似的還有Flash，同樣可以實現(xiàn)互聯(lián)網(wǎng)電話的功能，但由于Flash的功耗過大，支持Flash的移動端設(shè)備越來越少，F(xiàn)lash也就此沒落；Flash日漸式微而WebRTC風(fēng)生水起，WebRTC可以說完美解決了Web端的雙向通訊活動問題。最早的Web都是通過從服務(wù)器加載網(wǎng)頁實現(xiàn)單向通訊，隨著WebRTC的誕生，諸如視頻直播等雙向通訊活動也成為可能，現(xiàn)在支持WebRTC的瀏覽器包括Chrome、FireFox、Opera與Edge等。

　　WebRTC并非一項全新的技術(shù)而是多種技術(shù)的加成結(jié)果，包括音視頻編解碼技術(shù)、用于避免通話回聲的回聲消除技術(shù)、降噪技術(shù)、流媒體傳輸技術(shù)、NAT穿透技術(shù)，當(dāng)然還有用戶普遍關(guān)心的安全技術(shù)等等，較為典型的安全解決方案是HTTPS/WSS，其中的HTTPS超文本傳輸安全協(xié)議用于安全傳輸數(shù)據(jù)并驗證數(shù)據(jù)來源的可靠，而WSS（WebSocket）則是HTTP基礎(chǔ)上的升級，借助雙向的Socket通信解決了基于UDP并使用RTP傳輸協(xié)議交換數(shù)據(jù)的安全性問題。

　　WebRTC不僅被用于Web，同樣也被用于移動端尤其是各種APP，WebRTC在移動端的普及也讓音視頻編解碼、回聲消除等技術(shù)在移動端大放異彩。我們知道WebRTC標(biāo)準(zhǔn)的最早提出者是Google，下一代WebRTC標(biāo)準(zhǔn)是WebRTC 2.0，又稱ORTC（Object RTC）。對比ORTC與WebRTC，二者主要在媒體的描述方式上有較為明顯的差別。WebRTC 1.0的描述基于SDP，通過文本描述媒體特性；而ORTC則直接使用一個對象描述媒體。

　　需要注意的是，WebRTC僅是一個媒體層標(biāo)準(zhǔn)而并沒有規(guī)定信令，傳輸媒體至客戶端需要信令來確定數(shù)據(jù)的傳輸路徑與終端。以Chrome瀏覽器為例，其中被稱為GetUserMedia 的API被用于獲取用戶媒體，所產(chǎn)生的SDP描述了相關(guān)音頻與視頻文件。具體過程是：首先瀏覽器發(fā)送SDP的同時也會獲取一個SDP，此發(fā)送的SDP會從GetUserMedia端獲得相應(yīng)視頻，信令的作用是實現(xiàn)SDP的交換。WebRTC解決了點對點網(wǎng)絡(luò)連接與通信傳輸PeerConnection面臨的端口匹配、編解碼等問題。信令主要用于交換SDP，PeerConnection點對點連接與DataChannel數(shù)據(jù)信道用于傳輸媒體。

　　SIP是通信領(lǐng)域中的一個標(biāo)準(zhǔn)信令，想必在通信運營商工作的朋友不會對此感到陌生。上圖展示了SIP信令的具體流程：假設(shè)左側(cè)A、右側(cè)B兩位用戶進行通信活動，A會給B發(fā)送INVITE，INVITE中包含A端主叫號碼與B端被叫號碼，同時INVITE里包括了用于描述音視頻等媒體信息的SDP；當(dāng)INVITE發(fā)送至B端后，B端會給A端回復(fù)100 Trying表示成功接收INVITE，同時回復(fù)180 Ringing表示B端振鈴并給A端反饋回鈴聲讓A端用戶知道B端已接收到通話請求；當(dāng)B端用戶拿起電話接通時，B端會發(fā)送200 OK，切斷回鈴聲以告知A端用戶通話連接成功，雙方正式開始進行通話；圖中的ACK全稱Acknowledgement，INVITE、200 OK、ACK可視為一組三次握手過程，同時也意味著成功建立了媒體數(shù)據(jù)傳輸；RTP Data代表雙方進行音視頻通話時數(shù)據(jù)的交換，一旦在通信過程中有一方（B端）掛斷電話，主動掛斷的一方（B端）會發(fā)送BYE至另一方（A方）以告知通話結(jié)束，同時被掛斷一方（A端）向?qū)Ψ剑˙端）發(fā)送200 OK確認(rèn)通話掛斷，通話活動結(jié)束。SIP信令與HTTP相比在包括文本消息等方面都較為相似，相對于SIP，HTTP只通過一個Get請求就可得到200 OK。

　　FreeSWITCH實現(xiàn)了兩種信令：基于現(xiàn)有標(biāo)準(zhǔn)的SIP與基于WebSocket和JSON的非標(biāo)準(zhǔn)信令Verto。在絕大多數(shù)情況下，瀏覽器端的數(shù)據(jù)主要通過UDP和TCP傳輸，SIP不直接傳輸數(shù)據(jù)而是承載于UDP或TCP之上；加之雖然UDP的適用范圍更廣但傳輸較為麻煩，于是由HTTP基礎(chǔ)上升級而來的WebSocket協(xié)議成為了另一種選擇。FreeSWITCH中有在WebSocket基礎(chǔ)上加入Web協(xié)議實現(xiàn)的SIP over WebSocket，但由于SIP主要是為傳統(tǒng)通話設(shè)計，對于電腦與移動互聯(lián)網(wǎng)設(shè)備來說過于臃腫；隨后FreeSWITCH又出現(xiàn)了一種被稱為Verto的非標(biāo)準(zhǔn)信令，主要基于WebSocket，信令格式為Json。無論使用以上兩種信令中的哪一種作為信令，成功進行SDP交換之后FreeSWITCH就可以實現(xiàn)和Chrome的通信了。

　　FreeSWITCH可以實現(xiàn)萬物互聯(lián)，以至于我們探索了基于FreeSWITCH實現(xiàn)的微信小程序之間的通信并成功構(gòu)建了雙向RTMP通信。我們在FreeSWITCH內(nèi)部寫入了一個模塊便于所有設(shè)備與FreeSWITCH建立通信，從而實現(xiàn)如果有任何一方接入通信至FreeSWITCH，與FreeSWITCH連接的其他所有設(shè)備都可同步進行通信。例如通過微信你可以看到家中IP攝像頭的監(jiān)控畫面，也可即時加入視頻會議；視頻會議不僅可以通過專業(yè)設(shè)備舉行，也可以通過Chrome等瀏覽器傳輸，這種互聯(lián)互通的特性可以說是FreeSWITCH的最明顯特性。

　　當(dāng)然不同的廠商為了追求利益的最大化，都會努力實現(xiàn)開源的FreeSWITCH對全平臺的兼容。除了我們之前分享的SIP信令，F(xiàn)reeSWITCH中還有一種被稱為H.323的信令，H.323信令主要被用于早期的IP話機與視頻會議設(shè)備，而由于SIP的互通性能更出色，現(xiàn)在絕大多數(shù)設(shè)備都放棄了對H.323的支持。H.323協(xié)議基于二進制而SIP則是基于文本，相對于前者具有更好的可定制性。Flash與RTMP都是Adobe提出的協(xié)議，對比二者RTMP的綜合性能更加優(yōu)秀。包括現(xiàn)在的許多互聯(lián)網(wǎng)直播推流拉流、微信小程序等都因為其穩(wěn)定可靠而使用RTMP協(xié)議，相對于WebRTC，RTMP應(yīng)用也較為方便。在這里我們并不是說某一種協(xié)議擁有絕對優(yōu)勢，我們應(yīng)當(dāng)按照實際需求與產(chǎn)品特性選擇最適合的協(xié)議。

　　FreeSWITCH可被用于實現(xiàn)多屏視頻會議，甚至可以實現(xiàn)8x8的畫面部署。

　　無論是使用FreeSWITCH還是傳統(tǒng)的WebRTC，實現(xiàn)視頻會議都離不開以下三種控制策略：Mesh、MCU與SFU。Mesh是單純的點對點連接形成的網(wǎng)狀結(jié)構(gòu)且不需要服務(wù)器，由于每個節(jié)點都需編碼傳輸多路，非常浪費帶寬與運算資源；MCU則被FreeSWITCH所采用，也就是通過中間的多點控制單元收集各方傳來的音視頻數(shù)據(jù)并發(fā)送至FreeSWITCH，由FreeSWITCH將多路音視頻信號整理合成為一路包含所有畫面的音視頻流并傳輸給每一個用戶，每個節(jié)點僅與多點控制單元進行數(shù)據(jù)交換，所消耗的帶寬與運算資源也會明顯減少；當(dāng)然這樣做相當(dāng)于是把包括編解碼在內(nèi)的大量運算任務(wù)交給FreeSWITCH完成，這就要求FreeSWITCH集成CPU與足夠的帶寬資源。

　　SFU也就是選擇性轉(zhuǎn)發(fā)單元是第三種實現(xiàn)視頻會議的方式。如上圖最右側(cè)展示的那樣，如果有五方進行視頻會議，首先所有人都需要將自己這段的音視頻信號傳輸至中間的選擇性轉(zhuǎn)發(fā)單元，SFU會按照會議需求選擇性轉(zhuǎn)發(fā)信號至每一個用戶。相對于MCU，不處理編解碼任務(wù)的SFU節(jié)省了一部分CPU運算資源，但代價是帶寬消耗明顯提高，總而言之，實現(xiàn)FreeSWITCH的前提是使用MCU。

　　如果具體來說MCU在FreeSWITCH中的作用便是如上圖展示的那樣：黑色箭頭代表下發(fā)，紅色箭頭代表上行；假設(shè)這里有四臺設(shè)備分別輸入的畫面為1、2、3、4，現(xiàn)在我們將這四路畫面?zhèn)鬏斨罠reeSwitch的MCU設(shè)備，經(jīng)過MCU的縮放、拼接、合成一路等一系列處理，我們得到了一個由四方畫面拼接而成的會議畫面；此時每個用戶看到的畫面都是視頻融屏后的結(jié)果，同時看到四個畫面且完全一致。

　　多畫布是FreeSWITCH的另一項功能，此功能多用于大型會議現(xiàn)場。有些應(yīng)用場景需要主講人與觀眾看到兩個不同的畫面，例如講師看到的是觀眾的反應(yīng)而觀眾則看到的是演示文稿或者會場實況，這就需要構(gòu)建兩個畫布或多個畫布，按照每位觀看者的需求向其投送需要的畫面。

　　集群也是FreeSWITCH上較為常用的功能，實現(xiàn)起來也比較復(fù)雜。集群多用于擴展會議規(guī)模，當(dāng)然這需要多臺服務(wù)器的集中處理。

　　FreeSWITCH也支持非常豐富的多媒體編碼，包括音頻領(lǐng)域的PCMA、PCMU，瀏覽器中常用且適應(yīng)性較的OPUS，當(dāng)然還有常見的H.264、H.263、VP8、VP9等視頻編碼標(biāo)準(zhǔn)。

　　傳統(tǒng)語音電話領(lǐng)域也有借助FreeSWITCH的力量提升用戶體驗的案例，如互動式語音應(yīng)答IVR。上圖展示的就是一個較為趣味的場景，通過簡單的編程定義每個操作所觸發(fā)的活動，從而實現(xiàn)互動語音應(yīng)答與響應(yīng)。

　　除了前面介紹的應(yīng)用，F(xiàn)reeSWITCH在其他方面的應(yīng)用如上圖展示的那樣，可以說FreeSWITCH的應(yīng)用范圍十分廣泛。

　　FreeSWITCH可以用到的多媒體庫有用于處理各種音視頻文件的Libsndfile、處理VP8、VP9的libvpx、處理圖像的libpng與Imagemagick，當(dāng)然還有處理各種音視頻文件的FFmpeg與用于計算機視覺的OpenCV。

　　盡管FreeSWITCH本身不能實現(xiàn)AI，但這并不妨礙AI為FreeSWITCH處理音視頻賦能。FreeSWITCH內(nèi)部有一些可用于語音識別/語音文本互轉(zhuǎn)的ASR/TTS模塊，借助這些模塊FreeSWITCH可把收集到的音頻信號傳至多輪人機對話系統(tǒng)。除此之外，人臉識別、ChromaKey也是較為常見的應(yīng)用方向。

　　其中ChromaKey就是虛擬演播室，通過綠幕技術(shù)替換主播環(huán)境的背景等元素，極大豐富了產(chǎn)品視聽體驗。

　　當(dāng)然這些功能的實現(xiàn)離不開Media Bug媒體監(jiān)聽。例如Alice與Bob通話時Carl端通過類似于三通的路徑監(jiān)聽二者通話，并在需要時加入ChromeKey等處理。

　　總結(jié)以上分享內(nèi)容，F(xiàn)reeSWITCH是一個開源的軟交換平臺，具有模塊化結(jié)構(gòu)，實現(xiàn)了對包括WebRTC在內(nèi)的各種互聯(lián)互通的良好支持與新特性的部署；同時也易與各種AI平臺交互對接，并能作為處理多媒體的服務(wù)器使用。借助FreeSWITCH，我們希望為相關(guān)行業(yè)帶來更加出色的多媒體傳輸服務(wù)，實現(xiàn)通聯(lián)世界平等溝通的美好愿景。