文 / 杜金房
整理 / LiveVideoStack
大家好，我是杜金房，此次分享和雙向通訊伺服器FreeSWITCH以及WebRTC有關。首先我會為大家簡單介紹FreeSWITCH，鑒于FreeSWITCH主要用于通信領域，我也會介紹WebRTC并闡述FreeSWITCH與WebRTC的關系，同時結合FreeSWITCH的其他功能和使用場景與其功能以及所使用的多媒體庫，進一步探索AI技術加持下FreeSWITCH的未來發展。
1. FreeSWITCH簡介
FreeSWITCH是一套開源的，內建強大多媒體引擎的軟交換系統。FreeSWITCH主要基于C語言編寫，內建的衆多友善靈活的開發接口使其具有出色的互聯互通的能力，不僅相容各種手機電話等終端裝置并與各類軟體互相對接，也提供了對多種應用場景如電話通信、視訊會議的支援。根據FreeSWITCH官方給出的資料，FreeSWITCH已成功被應用于通信營運、線上教育、視訊會議與裝置網際網路關等。
說到開源，想必大家不會對上圖展示的這些Logo感到陌生，包括像Linux、Android這樣的開源作業系統，MySQL等開源資料庫以及APACHE這樣的開源Web伺服器。而通信領域也有兩個較具有代表性的開源軟體：Asterisk與這次重點介紹的FreeSWITCH。
2. 通信發展
其實在誕生初期FreeSWITCH主要被用來解決使用RJ11接口，基于電路交換原理實作的模拟電話機等傳統電話通信問題；随着數字技術的發展，使用RJ45接口/Wi-Fi，基于分組交換的IP通信與在此基礎上進一步更新的視訊電話逐漸普及，成為過去十年人們溝通交流所使用最為頻繁的工具；同時由于網際網路技術的突飛猛進，越來越多的人有機會享用海量網絡資源，基于網際網路傳輸實作的各種實時通訊APP應運而生。
從古代的烽火台與語言交流到近現代的模拟電話，再到現如今人們再熟悉不過的數字電話，通信的進步可以說與社會生産力進步與人類文明發展密不可分。傳統的模拟電話通過傳輸模拟信号實作遠距離聲音傳輸，而随着傳輸距離的增大與傳輸條件的變化，模拟信号會在傳輸過程中遭受明顯衰減，這就需要安裝在接收端的信号放大器處理接收到的模拟信号進而使其中的關鍵資訊更容易被擷取；但這樣做并非完美，放大聲音的同時如噪音、呼吸聲等環境雜音也會被放大，間接導緻有效信号比率降低，直接帶來的影響便是遠距離的通話雙方無法清晰而準确地拾取對方所要表達的關鍵資訊。
為了滿足遠距離通信資料傳輸的有效，數字通訊技術應運而生。數字通訊可實作在進行遠距離傳輸的同時幾乎不損失通話品質，從傳統的電話機到大家使用的第一款GSM手機再到現在的智能手機，可以說數字通訊極大改善了人們遠距離溝通交流的方式。與此同時，從最早的撥号電話、GSM手機到3G、4G以至于未來的5G，通信技術的發展也可謂突飛猛進。通信技術的疊代也帶來了網際網路技術的飛躍。例如在4G/LTE誕生之前，由于通信所使用的網絡通道與網絡傳輸所使用的并不相同，使用者無法在打電話的同時通路網際網路；而對4G/LTE而言，包括語音電話與通路網際網路在内的所有通訊活動都通過IP網絡傳輸資料，這就避免了打電話與通路網際網路的沖突。
FreeSWITCH是一個開源的軟交換系統，所謂的軟交換是指不考慮終端類型，所有話機都可以通過FreeSWITCH與其他裝置互聯互通。上圖中展示的終端除了有電話、手機，還有監控攝像頭、視訊電話甚至RTMP、Flash等等。FreeSWITCH的特點就是可對接任何裝置，例如通過浏覽器可實作WebRTC與FreeSWITCH之間的通信，進而允許使用者通過浏覽器撥打電話。
3. WebRTC風生水起
早期實作浏覽器撥打電話一般需要ActiveX技術的輔助，這是IE上的一個插件系統；與此類似的還有Flash，同樣可以實作網際網路電話的功能，但由于Flash的功耗過大，支援Flash的移動端裝置越來越少，Flash也就此沒落；Flash日漸式微而WebRTC風生水起，WebRTC可以說完美解決了Web端的雙向通訊活動問題。最早的Web都是通過從伺服器加載網頁實作單向通訊，随着WebRTC的誕生，諸如視訊直播等雙向通訊活動也成為可能，現在支援WebRTC的浏覽器包括Chrome、FireFox、Opera與Edge等。
WebRTC并非一項全新的技術而是多種技術的加成結果，包括音視訊編解碼技術、用于避免通話回聲的回聲消除技術、降噪技術、流媒體傳輸技術、NAT穿透技術，當然還有使用者普遍關心的安全技術等等，較為典型的安全解決方案是HTTPS/WSS，其中的HTTPS超文本傳輸安全協定用于安全傳輸資料并驗證資料來源的可靠，而WSS（WebSocket）則是HTTP基礎上的更新，借助雙向的Socket通信解決了基于UDP并使用RTP傳輸協定交換資料的安全性問題。
WebRTC不僅被用于Web，同樣也被用于移動端尤其是各種APP，WebRTC在移動端的普及也讓音視訊編解碼、回聲消除等技術在移動端大放異彩。我們知道WebRTC标準的最早提出者是Google，下一代WebRTC标準是WebRTC 2.0，又稱ORTC（Object RTC）。對比ORTC與WebRTC，二者主要在媒體的描述方式上有較為明顯的差别。WebRTC 1.0的描述基于SDP，通過文本描述媒體特性；而ORTC則直接使用一個對象描述媒體。
需要注意的是，WebRTC僅是一個媒體層标準而并沒有規定信令，傳輸媒體至用戶端需要信令來确定資料的傳輸路徑與終端。以Chrome浏覽器為例，其中被稱為GetUserMedia 的API被用于擷取使用者媒體，所産生的SDP描述了相關音頻與視訊檔案。具體過程是：首先浏覽器發送SDP的同時也會擷取一個SDP，此發送的SDP會從GetUserMedia端獲得相應視訊，信令的作用是實作SDP的交換。WebRTC解決了點對點網絡連接配接與通信傳輸PeerConnection面臨的端口比對、編解碼等問題。信令主要用于交換SDP，PeerConnection點對點連接配接與DataChannel資料信道用于傳輸媒體。
SIP是通信領域中的一個标準信令，想必在通信營運商工作的朋友不會對此感到陌生。上圖展示了SIP信令的具體流程：假設左側A、右側B兩位使用者進行通信活動，A會給B發送INVITE，INVITE中包含A端主叫号碼與B端被叫号碼，同時INVITE裡包括了用于描述音視訊等媒體資訊的SDP；當INVITE發送至B端後，B端會給A端回複100 Trying表示成功接收INVITE，同時回複180 Ringing表示B端振鈴并給A端回報回鈴聲讓A端使用者知道B端已接收到通話請求；當B端使用者拿起電話接通時，B端會發送200 OK，切斷回鈴聲以告知A端使用者通話連接配接成功，雙方正式開始進行通話；圖中的ACK全稱Acknowledgement，INVITE、200 OK、ACK可視為一組三次握手過程，同時也意味着成功建立了媒體資料傳輸；RTP Data代表雙方進行音視訊通話時資料的交換，一旦在通信過程中有一方（B端）挂斷電話，主動挂斷的一方（B端）會發送BYE至另一方（A方）以告知通話結束，同時被挂斷一方（A端）向對方（B端）發送200 OK确認通話挂斷，通話活動結束。SIP信令與HTTP相比在包括文本消息等方面都較為相似，相對于SIP，HTTP隻通過一個Get請求就可得到200 OK。
4. FreeSWITCH與WebRTC
FreeSWITCH實作了兩種信令：基于現有标準的SIP與基于WebSocket和JSON的非标準信令Verto。在絕大多數情況下，浏覽器端的資料主要通過UDP和TCP傳輸，SIP不直接傳輸資料而是承載于UDP或TCP之上；加之雖然UDP的适用範圍更廣但傳輸較為麻煩，于是由HTTP基礎上更新而來的WebSocket協定成為了另一種選擇。FreeSWITCH中有在WebSocket基礎上加入Web協定實作的SIP over WebSocket，但由于SIP主要是為傳統通話設計，對于電腦與移動網際網路裝置來說過于臃腫；随後FreeSWITCH又出現了一種被稱為Verto的非标準信令，主要基于WebSocket，信令格式為Json。無論使用以上兩種信令中的哪一種作為信令，成功進行SDP交換之後FreeSWITCH就可以實作和Chrome的通信了。
FreeSWITCH可以實作萬物互聯，以至于我們探索了基于FreeSWITCH實作的微信小程式之間的通信并成功建構了雙向RTMP通信。我們在FreeSWITCH内部寫入了一個子產品便于所有裝置與FreeSWITCH建立通信，進而實作如果有任何一方接入通信至FreeSWITCH，與FreeSWITCH連接配接的其他所有裝置都可同步進行通信。例如通過微信你可以看到家中IP攝像頭的監控畫面，也可即時加入視訊會議；視訊會議不僅可以通過專業裝置舉行，也可以通過Chrome等浏覽器傳輸，這種互聯互通的特性可以說是FreeSWITCH的最明顯特性。
當然不同的廠商為了追求利益的最大化，都會努力實作開源的FreeSWITCH對全平台的相容。除了我們之前分享的SIP信令，FreeSWITCH中還有一種被稱為H.323的信令，H.323信令主要被用于早期的IP話機與視訊會議裝置，而由于SIP的互通性能更出色，現在絕大多數裝置都放棄了對H.323的支援。H.323協定基于二進制而SIP則是基于文本，相對于前者具有更好的可定制性。Flash與RTMP都是Adobe提出的協定，對比二者RTMP的綜合性能更加優秀。包括現在的許多網際網路直播推流拉流、微信小程式等都因為其穩定可靠而使用RTMP協定，相對于WebRTC，RTMP應用也較為友善。在這裡我們并不是說某一種協定擁有絕對優勢，我們應當按照實際需求與産品特性選擇最适合的協定。
5. 其他功能與使用場景
FreeSWITCH可被用于實作多屏視訊會議，甚至可以實作8x8的畫面部署。
無論是使用FreeSWITCH還是傳統的WebRTC，實作視訊會議都離不開以下三種控制政策：Mesh、MCU與SFU。Mesh是單純的點對點連接配接形成的網狀結構且不需要伺服器，由于每個節點都需編碼傳輸多路，非常浪費帶寬與運算資源；MCU則被FreeSWITCH所采用，也就是通過中間的多點控制單元收集各方傳來的音視訊資料并發送至FreeSWITCH，由FreeSWITCH将多路音視訊信号整理合成為一路包含所有畫面的音視訊流并傳輸給每一個使用者，每個節點僅與多點控制單元進行資料交換，所消耗的帶寬與運算資源也會明顯減少；當然這樣做相當于是把包括編解碼在内的大量運算任務交給FreeSWITCH完成，這就要求FreeSWITCH內建CPU與足夠的帶寬資源。
SFU也就是選擇性轉發單元是第三種實作視訊會議的方式。如上圖最右側展示的那樣，如果有五方進行視訊會議，首先所有人都需要将自己這段的音視訊信号傳輸至中間的選擇性轉發單元，SFU會按照會議需求選擇性轉發信号至每一個使用者。相對于MCU，不處理編解碼任務的SFU節省了一部分CPU運算資源，但代價是帶寬消耗明顯提高，總而言之，實作FreeSWITCH的前提是使用MCU。
如果具體來說MCU在FreeSWITCH中的作用便是如上圖展示的那樣：黑色箭頭代表下發，紅色箭頭代表上行；假設這裡有四台裝置分别輸入的畫面為1、2、3、4，現在我們将這四路畫面傳輸至FreeSwitch的MCU裝置，經過MCU的縮放、拼接、合成一路等一系列處理，我們得到了一個由四方畫面拼接而成的會議畫面；此時每個使用者看到的畫面都是視訊融屏後的結果，同時看到四個畫面且完全一緻。
多畫布是FreeSWITCH的另一項功能，此功能多用于大型會議現場。有些應用場景需要主講人與觀衆看到兩個不同的畫面，例如講師看到的是觀衆的反應而觀衆則看到的是示範文稿或者會場實況，這就需要建構兩個畫布或多個畫布，按照每位觀看者的需求向其投送需要的畫面。
叢集也是FreeSWITCH上較為常用的功能，實作起來也比較複雜。叢集多用于擴充會議規模，當然這需要多台伺服器的集中處理。
FreeSWITCH也支援非常豐富的多媒體編碼，包括音頻領域的PCMA、PCMU，浏覽器中常用且适應性較的OPUS，當然還有常見的H.264、H.263、VP8、VP9等視訊編碼标準。
傳統語音電話領域也有借助FreeSWITCH的力量提升使用者體驗的案例，如互動式語音應答IVR。上圖展示的就是一個較為趣味的場景，通過簡單的程式設計定義每個操作所觸發的活動，進而實作互動語音應答與響應。
除了前面介紹的應用，FreeSWITCH在其他方面的應用如上圖展示的那樣，可以說FreeSWITCH的應用範圍十分廣泛。
6. FreeSWITCH所使用的多媒體庫
FreeSWITCH可以用到的多媒體庫有用于處理各種音視訊檔案的Libsndfile、處理VP8、VP9的libvpx、處理圖像的libpng與Imagemagick，當然還有處理各種音視訊檔案的FFmpeg與用于計算機視覺的OpenCV。
7. AI賦能
盡管FreeSWITCH本身不能實作AI，但這并不妨礙AI為FreeSWITCH處理音視訊賦能。FreeSWITCH内部有一些可用于語音識别/語音文本互轉的ASR/TTS子產品，借助這些子產品FreeSWITCH可把收集到的音頻信号傳至多輪人機對話系統。除此之外，人臉識别、ChromaKey也是較為常見的應用方向。
其中ChromaKey就是虛拟演播室，通過綠幕技術替換主播環境的背景等元素，極大豐富了産品視聽體驗。
當然這些功能的實作離不開Media Bug媒體監聽。例如Alice與Bob通話時Carl端通過類似于三通的路徑監聽二者通話，并在需要時加入ChromeKey等處理。
8. 總結與展望
總結以上分享内容，FreeSWITCH是一個開源的軟交換平台，具有子產品化結構，實作了對包括WebRTC在内的各種互聯互通的良好支援與新特性的部署；同時也易與各種AI平台互動對接，并能作為處理多媒體的伺服器使用。借助FreeSWITCH，我們希望為相關行業帶來更加出色的多媒體傳輸服務，實作通聯世界平等溝通的美好願景。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/88802333「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。