本文由FreeSWITCH 中文社區(qū)創(chuàng)始人杜金房在LiveVideoStack線上分享的演講內(nèi)容整理而成，詳細介紹了FreeSWITCH做為一種開源的視頻會議解決方案如何在開源、開放的基礎(chǔ)上，對接各種無法修改的“標準”視頻會議終端、WebRTC瀏覽器以及微信小程序等，迎接各種挑戰(zhàn)。

文 /?杜金房

整理 /?LiveVideoStack

我們所謂的“標準”解決方案，并非是指這個解決方案是標準的。而是在做視頻會議的過程中，FreeSWITCH作為一個服務(wù)器，會面對不同類型的客戶端以及各種硬件的終端。由于它們使用了各種各樣的標準協(xié)議，是我們沒辦法修改的，所以稱它們?yōu)闃藴实目蛻舳恕６鳩reeSWITCH視頻會議“標準”解決方案就是指針對這些不可修改的標準客戶端所做的一種解決方案。

●視頻會議類型●

視頻會議大體上可以分為三種類型。一是傳統(tǒng)視頻會議，傳統(tǒng)的視頻會議是“標準”的，因為它們之間需要互通。早期的視頻會議協(xié)議一般是H323，即使現(xiàn)在我們也還會經(jīng)常遇到H323的設(shè)備，但后來大部分被SIP協(xié)議的設(shè)備所取代。SIP協(xié)議是一個文本協(xié)議，整體更靈活一些。

近幾年開始出現(xiàn)一些云視頻會議，今年其實也可以算作云視頻會議的元年，由于疫情的原因，大家開始更多地使用視頻會議。例如Zoom，騰訊會議、小魚易連等，據(jù)說騰訊會議一周之內(nèi)上線了10萬臺服務(wù)器，進行緊急擴容，這在傳統(tǒng)的視頻會議時代是不可能實現(xiàn)的，只有在云計算時代才能快速實現(xiàn)擴容，這也體現(xiàn)了云計算的優(yōu)勢。據(jù)了解這些云視頻會議廠商，基本都是使用的私有協(xié)議，其好處是可以無限制的優(yōu)化。但私有協(xié)議無法進行很好的互聯(lián)互通，不過各個視頻會議廠商為了實現(xiàn)與其它設(shè)備互通，自己也會提供一些SDK。

開源領(lǐng)域的視頻會議，有FreeSWITCH、Jitsi、Kurento、Janus、Medooze等，這些視頻會議也有許多年的歷史了，目前大多已經(jīng)開始支持WebRTC。有的以支持WebRTC為主，例如Kurento和Janus；Janus和Medooze最初是支持SIP的，最近幾年我沒有太關(guān)注；Jitsi對WebRTC的支持非常好。

對于FreeSWITCH，大家可能會有些誤解。FreeSWITCH其實最早是用于音頻通信的，即PBX 程控交換機，但實際上FreeSWITCH的視頻會議功能也非常強。開源的視頻會議因為是開源、開放的，使用的是開放的API，因此更多的是使用開放協(xié)議如SIP協(xié)議。

目前WebRTC比較火，所有的視頻會議設(shè)備基本都在支持WebRTC，在瀏覽器里就可以打電話。WebRTC是一個媒體協(xié)議，沒有規(guī)定信令，在信令層面沒有標準，因此大家實現(xiàn)起來會比較靈活。FreeSWITCH在信令層實現(xiàn)了兩種協(xié)議，一種是SIP，它承載在WebSocket上，因為在瀏覽器里只有WebSocket可以實現(xiàn)雙向通信。另外還有自己實現(xiàn)的私有協(xié)議Verto。

●互聯(lián)互通●

隨著我們對于視頻會議軟件的使用越來越多，會發(fā)現(xiàn)一個問題：手機和電腦上的視頻會議客戶端越來越多。

其實我們也非常希望能解決這個問題，方法就是互聯(lián)互通。我們希望所有的終端都能互聯(lián)互通，難道只是因為使用的視頻會議客戶端不同，就不能在一起開會了嗎？

理想很豐滿，但現(xiàn)實執(zhí)行起來還是很困難的。

其實更多的是由于商業(yè)的原因，沒有人會選擇這么做。當然從技術(shù)層面來說，全部使用私有的協(xié)議、服務(wù)器和終端，能更好地優(yōu)化、更好的保證安全等等。總之，實現(xiàn)互聯(lián)互通任重道遠。

雖然任重道遠，但其實我們一直想做這方面的事情，FreeSWITCH也連接了很多不同的客戶端，希望能跟更多的設(shè)備進行互聯(lián)互通。

●FreeSWITCH的成長史●

說到FreeSWITCH，簡單了解一下它的歷史。

2006年FreeSWITCH發(fā)布了第1個版本。FreeSWITCH本身最開始是作為一個PBX進行的。PBX就是我們所說的企業(yè)里的交換機，打電話用的。

2008年發(fā)布了1.0版本—鳳凰版，像鳳凰涅磐一樣，經(jīng)歷了無數(shù)次的崩潰、優(yōu)化，所以稱為鳳凰版。

2012年發(fā)布FreeSWITCH1.2版本（FreeSWITCH的版本號都是偶數(shù)），1.2版本非常穩(wěn)定，音頻方面也已經(jīng)非常成熟，在電話方面基本上沒什么可做的了。但隨著的WebRTC的出現(xiàn)，FreeSWITCH決定接下來要支持WebRTC。

2014年推出1.4版本，開始支持WebRTC。早期的WebRTC還不是很穩(wěn)定，但WebRTC的標準變得非常快，所以FreeSWITCH也一直在跟著改。

其實早在2008年我就開始做FreeSWITCH了，那時主要做在線教育，早期的在線教育沒有視頻，只有音頻，教師利用音頻做英語的對話教學(xué)。后來又做了一些其它的項目，要求有視頻，然后就增加了一些視頻的功能，包括視頻的MCU。由于FreeSWITCH早期在視頻方面還不是很成熟，做了幾個項目不是特別滿意，所以后來我們就把視頻部分開源了。

2014年-2015年，我們耗費了一年的時間，將自己做的部分合并到FreeSWITCH的主分支中，用一整年的時間將自己寫的代碼規(guī)范化、同時適配Windows、Linux、Unix等各種平臺，實現(xiàn)FreeSWITCH在各種平臺上的編譯和支持，發(fā)布了1.6版。這時FreeSWITCH開始支持視頻通話和視頻會議，之后從2017年開始到2020年，這幾年一直在不停的修bug，將FreeSWITCH做得越來越完善。

在視頻會議開源的這個分支上，我們也做了很多內(nèi)容，有的已經(jīng)合并到1.8版本中，有的合并在1.10版本中。其實我們自己還維護了一個分支沒有合并進去，由于將自己的代碼合并到開放的分支中需要很多勞動力，所以會在后續(xù)逐步完成。

●FreeSWITCH支持的標準協(xié)議●

說到標準協(xié)議，FreeSWITCH支持上圖中的這些標準協(xié)議。

首先FreeSWITCH支持SIP信令，就是音頻和視頻通話標準的協(xié)議，支持各種客戶端、終端，目前市面上很多的會議設(shè)備都是支持SIP的，可以直接實現(xiàn)互通。

其次我們還做了一個H323的模塊，FreeSWITCH本身有兩個H323的模塊，但都不支持視頻，因為有客戶需求，就又做了支持視頻的模塊，這樣也就能跟H323的終端進行互通。隨著移動互聯(lián)網(wǎng)的發(fā)展，目前各種移動端設(shè)備上的APP大多都是支持SIP信令的，可以直接實現(xiàn)互通。

隨著WebRTC的發(fā)展，很多人開始將其移植到手機客戶端上。WebRTC的優(yōu)點在于不需要自己寫媒體層，隨著WebRTC的開源帶來了很多特性，比如說JitterBuffer、回聲消除、降噪等等之類的內(nèi)容在WebRTC中已經(jīng)包含，不需要再自己寫，雖然不如各種私有化的廠家做的好，因為私有化的廠家可以進行更加極致的優(yōu)化。但對于一個開源項目來說，WebRTC做的已經(jīng)足夠好了，由于WebRTC只有媒體層沒有信令層，所以大家都開始往WebRTC上套各種信令。

值得一提的是RTMP，其實最開始我做的就是RTMP的視頻。盡管目前 Flash基本上已經(jīng)沒有人用了，但RTMP協(xié)議還是非常好的，目前更廣泛應(yīng)用于直播和推流等。

視頻會議的幾種實現(xiàn)方式：Mesh、MCU、SFU

視頻會議簡單來講有三種方式：Mesh、MCU、SFU。

Mesh是單純的點對點連接形成的網(wǎng)狀結(jié)構(gòu)且不需要服務(wù)器，但是這種方式使用的非常少，因為不好控制。

目前比較主流的兩種方式，MCU和SFU。

MCU之所以說它比較主流，是因為最開始的視頻會議設(shè)備基本上都是MCU的。MCU中間有一個服務(wù)器，視頻客戶端與服務(wù)器直接通訊，實際上收發(fā)都是一路流。視頻服務(wù)器把所有的流合成一路，即視頻融屏。當然音頻也會融合，簡單起見，我們這里只說視頻。視頻服務(wù)器將視頻流融合到一起形成一個畫面，分發(fā)給所有的終端，所有的終端看到的畫面都是一樣的，這種情況叫MCU（Multipoint Control Unit），即多點控制單元。

隨著WebRTC的出現(xiàn)，很多人開始用SFU（Selective Forward in Unit）。SFU不解碼、不融屏，前面說到MCU會對各種畫面拼接、融屏，也就需要對視頻進行編解碼。而SFU只需要把收到的各個客戶端發(fā)來的視頻和音頻，有選擇的發(fā)給不同的人。其好處是不需要占用過多的CPU，但缺點是比較浪費帶寬。比如5個人進行通話，其中一方只需要發(fā)一路流，轉(zhuǎn)發(fā)單元會進行布置，將這一路流復(fù)制成多份進行分發(fā)，每個人都會收到很多路流，終端所承受的壓力會比較大，因為一方的終端需要對另外的4路流進行解碼。好處是終端可以自由排列所收到的其它客戶端的顯示樣式，每個人看到的畫面都可能是不一樣的。

上圖是MCU的基本原理圖，如圖有4個攝像頭，各個攝像頭把自己的畫面上傳到MCU，MCU進行縮放、拼接，拼接成一個畫面，然后下發(fā)。每個終端顯示器上顯示出來的都是一樣的畫面。FreeSWITCH內(nèi)部也是這樣實現(xiàn)的，FreeSWITCH內(nèi)部實現(xiàn)了諸如1、2、3、4等的多個層，以及一個畫布（canvas），我們將收到的不同視頻解碼，再縮放，拼接到畫布上，形成一路流，最后分發(fā)出去。

畫布的樣式有多種類型，FreeSWITCH除了支持標準的畫布：3×3、4×4、8×8以外，還支持培訓(xùn)班模式：演講者畫面（大）+聽眾畫面（小），以及更多不同的排列形式。

這其中我們做了一個比較關(guān)鍵的優(yōu)化，就是RTP。眾所周知視頻流是靠RTP傳輸，RTP還有一個姊妹協(xié)議叫做RTCP，是一個控制協(xié)議用來控制RTP，這個協(xié)議里有一個東西叫做TMMBR（Temporary Maximum Media Stream Bit Rate Request）。在視頻會議中，一般來說大家看到的高清畫面有720p或1080p的，而在演講者模式中，觀眾的畫面通常是比較小的，沒有必要上傳1080P或720P的畫面，浪費1兆或2兆的帶寬。這時，FreeSWITCH會發(fā)送一條指令-TMMBR，提示不需要高清視頻上傳，降低帶寬上傳，這樣觀眾就可以通過低帶寬消耗的方式上線，減輕服務(wù)器的帶寬壓力、同時也減輕解碼的壓力。

我們已經(jīng)將其應(yīng)用在我們的視頻會議里，效果非常明顯。但前提是終端要支持這個協(xié)議，在WebRTC中是支持的，這個協(xié)議的標準叫RFC 5104。RFC 5104里除了規(guī)范TMMBR以外，還規(guī)定了一些其它的協(xié)議，例如FIR、NACK、PLI，都是與關(guān)鍵幀相關(guān)的。在有丟包產(chǎn)生的情況下，FIR是請求一個關(guān)鍵幀，因為解碼失敗將要出馬賽克，請求對方發(fā)送一個關(guān)鍵幀，刷新畫面。NACK是丟包，其實丟包就涉及到了緩存，就是我所說的Jitter Buffer，Jitter Buffer是在兩個通信終端之間，不管是發(fā)送端還是接收端，都會有一個Buffer，這個緩沖區(qū)發(fā)出去的東西，會放到緩沖區(qū)里接收，當發(fā)生丟包的情況下，發(fā)現(xiàn)有一個丟包，就向?qū)Ψ秸埱笾匕l(fā)。這時，對方就看到這個包還在緩沖區(qū)，即可從沖緩沖區(qū)中取出重發(fā)，這種方式叫NACK。PLI是Packet Lost Indication，告訴這一端我丟包了，這個協(xié)議負責(zé)音視頻傳輸?shù)馁|(zhì)量，因為視頻傳輸大多數(shù)用的UDP的協(xié)議是不可靠的，所以在發(fā)生丟包的情況下再做比較多一些補償。

我們還做了一些其它的優(yōu)化，在大規(guī)模視頻會議中，幾十個人甚至上百人參與，對于服務(wù)器的解碼壓力會比較大。而且同時在一個屏上顯示幾百個人是沒意義的，因為太小根本看不清觀眾表情，所以一般在參會人數(shù)比較多的情況下，就直接展示幾個或者幾十個人，太多了就不展示，不展示的部分也就沒有必要解碼，不需要浪費服務(wù)器的處理能力。但觀眾還是需要輪番展示一下的，所以我們還做了一個多人輪循展示，例如現(xiàn)在開始看這10個人，下一次我再看另外10個人，然后做一個定時器進行輪循，讓每個人都有出鏡的機會。當然由于關(guān)鍵幀的原因，展示出來的時候，就需要解碼，這時不一定正好有個關(guān)鍵幀過來，所以需要提前兩秒開啟解碼，然后等展示到它的時候，一般這個關(guān)鍵幀就到了，因為每次展示的同時也會向?qū)Ψ揭P(guān)鍵幀，這樣的話正好能展示出來，不至于黑屏。還有一些我們在視頻會議的過程中遇到很多坑，例如NACK請求太多，有時候由于好多終端的網(wǎng)絡(luò)都不好，然后都過來請求NACk丟包，如果是發(fā)現(xiàn)這個NACK請求太多，我們就直接發(fā)關(guān)鍵幀，不理會丟包情況。

還有就是限制FIR請求的頻率，FIR就是我們說的關(guān)鍵幀請求，刷新關(guān)鍵幀，當終端在網(wǎng)絡(luò)條件不好的情況下請求一個關(guān)鍵幀，若有10個終端都請求關(guān)鍵幀，若一秒鐘之內(nèi)產(chǎn)生10個關(guān)鍵幀，帶寬就會被撐爆或者視頻畫面會非常的模糊，因為滿足不了這么多關(guān)鍵幀的請求，所以我們做了一些算法，其實這也是一些基本的算法，限制關(guān)鍵幀的請求。例如可以設(shè)置兩秒或者三秒，那在這兩秒或者三秒之內(nèi)，只產(chǎn)生兩個關(guān)鍵幀，即第一個請求和最后一個請求會產(chǎn)生關(guān)鍵幀，其他的都忽略，這樣的情況下才會保護帶寬，當然對方可能會有短暫的花屏，但是沒關(guān)系，然后兩秒鐘之內(nèi)就已經(jīng)清晰了，因為畢竟其網(wǎng)絡(luò)狀態(tài)不好自身是可以忍受的，當然如果是網(wǎng)絡(luò)狀態(tài)都好的終端呢，他也不會有影響。

另外，不同的編碼有不同的編碼器， FreeSWITCH支持不同的編碼，由于歷史原因，Chrome支持vp8，蘋果的瀏覽器只支持H.264,不能實現(xiàn)互通，然后最開始的WebRTC也不能互通，當然最近幾年可以了，Chrome也支持H.264了，其他的瀏覽器也支持vp8了，所以說FreeSWITCH從最開始就支持多種編碼，然后在同一個會議里，不同編碼的會議，用不同的編碼器即可。

還有情況不同的終端，可能這些做私有終端、私有通信的沒有這種困擾，因為終端都是他自己的，規(guī)定用什么編碼就用什么編碼，但是在開源領(lǐng)域，需要面對各種各樣的客戶端，例如軍隊的項目，他們好多設(shè)備還是H.263的，不能被替換，我們就只能去適配H.263，H.263不支持720p的分辨率，它只支持CIF分辨率的，CIF即不是16:9也不是4:3，所以需要我們單獨分一個編碼器。等等之類的情況，想要支持的終端的型號越多需要做的就越多。

早期的我們也做了一些優(yōu)化，降分辨率、降幀率，發(fā)現(xiàn)有終端使用flash是我們處理不了的，那么我們就降分辨率，把分辨率降低一半，然后降幀，原先30幀降成15幀。現(xiàn)在有了更好的技術(shù)叫SVC，SVC就是在一個編碼器里出多個分辨率和多個幀率，當然對CPU還是有代價的，它編出來之后可以有選擇的去分出去，其實FreeSWITCH有一個模塊叫mod_openh264，使用的是思科開源的編解碼器，支持SVC，但目前我們還沒有使用，只是用了它比較簡單的編解碼的功能，我們在FreeSWITCH內(nèi)部使用的，另外一個就是內(nèi)部的libx264，它是在FFmpeg自帶的。

在視頻會議里邊我們經(jīng)常遇到的還有一個就是雙流，傳統(tǒng)的視頻會議設(shè)備，H.323的設(shè)備，一般支持的協(xié)議叫H.239，它可以在一個通話里支持兩個流，一個流是演講者的視頻，另外一個就是PPT，兩個流可以上到MCU，大家可以看到，甚至對方也可以放兩個電視或者投影儀，一個投影儀展示演講者的視頻，另一個投影儀展示PPT。

SIP設(shè)備也支持雙流，SIP設(shè)備的雙流叫BFCP，全稱是Binary Floor Control Protocol。演講者會做一些控制，H.323的雙流我們沒有做，只做了簡單的對接，由于對接的設(shè)備比較少，能通即可。對于SIP協(xié)議的雙流，我們現(xiàn)在還沒有開源，也是BFCP的。我們直接在SIP的模塊中挾持了SDP，因為在SDP里邊會有兩個視頻流，挾持到以后處理生成一路新的呼叫（一個假的呼叫），FreeSWITCH在收到一路呼叫時，就看到他是一個雙流的呼叫，然后就生出兩個呼叫，這樣的話兩個呼叫會同時調(diào)到會議里邊，會議的代碼不需要改。對會議來講是來了兩個呼叫，但是對FreeSWITCH來講是一路呼叫，這樣就可以支持雙流了。

另外在WebRTC中，雙流有一個叫Simlcast，它也可以在一個SDP里邊看多個流，由于Simlcast早期不穩(wěn)定，有很多問題，現(xiàn)在我們利用Simlcast只是做了一些實驗，還沒有具體詳細的代碼，我們只是比較簡單粗暴的，直接在瀏覽器里發(fā)起兩路呼叫，一個呼叫是演講者的這個視頻，另外一個呼叫是共享桌面，因為在瀏覽器里發(fā)起WebRTC呼叫時，可以直接選視頻源是攝像頭還是屏幕或者是共享某個應(yīng)用程序，形成了這種雙流。同樣到了FreeSWITCH，它還是作為兩路流，作為兩個呼叫進到會議中。

對于上面提到的SFU，FreeSWITCH是可以實現(xiàn)SFU的，其實我們也做了很多的嘗試，但是SFU比較復(fù)雜，需要控制很多路呼叫，未來FreeSWITCH的核心是要支持多路流，但是目前實現(xiàn)SFU的計劃還未提上日程，另外一個原因也是由于市面上很多做SFU的產(chǎn)品，并且都比較成熟了，例如Jitsi、Kurento、Janus都有SFU的實現(xiàn)，如果需要的話，可以搭配FreeSWITCH進行實現(xiàn)。

當視頻會議的規(guī)模比較大時，就需要級聯(lián)，因為一臺服務(wù)器支撐不下。FreeSWITCH的視頻會議在實驗室測試一臺服務(wù)器可以支撐400路720p的視頻流，根據(jù)具體的應(yīng)用場景選擇服務(wù)器的規(guī)格是32核或64核，當然我們在開大會的場景下，不會把所有的人都顯示出來，只把展示出來的人編解碼，就是上面提到的優(yōu)化不解碼，這樣可以只編碼一路流下發(fā)，所以對CPU的壓力不大。其實我們在實驗室里做到400路流，但是給客戶上線的是一臺服務(wù)器支撐100路終端，最大應(yīng)該能上到200路。但是應(yīng)用場景是需要800路客戶終端，那我們就做了級聯(lián)。

級聯(lián)存在一個問題，我們稱之為“看對眼”，就是當兩個MCU級聯(lián)時，例如1、2、3在一個MCU上，5、6、7在另外一個MCU上，當MCU合成出的畫面進入到另外一個畫面的時候，它就會把你的畫面返回來，這樣這中間就有一個無限循環(huán)的畫面，當然下圖的動圖就體現(xiàn)的比較直觀。

在做桌面共享的時候肯定對上圖這個界面比較熟悉了。

其實Google上能搜出很多類似的情況，這就是我們收到的視頻又作為視頻源發(fā)出去了，這種情況就稱為看對眼。視頻會議在兩個MCU進行級聯(lián)的情況下就會出現(xiàn)這種情況。那么如何解決呢？

FreeSWITCH實現(xiàn)了一個功能叫做多畫布，如上圖的應(yīng)用場景，當一個人開始演講時，就將其當做主會場，放在畫布1上。所有的與會者都需要看到主會場，同時演講者需要監(jiān)督其它與會者學(xué)習(xí)，就需要看到其它與會者的畫面，我們把與會者的畫面都放在第2個畫布上，主會場人員就可以看到分會場的與會者情況。

甚至FreeSWITCH還有一個Super Canvas——超級畫布，主要用來做監(jiān)控的，無論會議里有多少個畫布，都可以一目了然的看到。這樣，后臺管理人員做會議控制的時候，就可以很方便地看到整個會議的場景。通過這種方式，我們就解決了這個“看對眼”的問題，這樣兩個MCU就可以級聯(lián)了，例如上行MCU永遠放在畫布2上，下行MCU永遠在畫布1上，這樣就可以它們區(qū)分開。

上圖是一個級聯(lián)的示意圖，Master是主服務(wù)器，下邊有很多FreeSWITCH的從服務(wù)器，下行畫面永遠是在第1張畫布上，上行畫面的永遠是在第2張畫布上，反之也可以。這樣的話就可以隨時切換，查看上行的情況，各個與會者也都可以看到主會場。有時在開會的過程中，為了防止與會者只看到主會場而感到孤獨，這時我們就會把第2張畫布的畫面也推下去，這樣所有人都看到其它的與會者。甚至在開會的過程中要交流，例如舉手發(fā)言，這時也可以替換掉主會場的畫面。級聯(lián)的基本原理就是這樣，但實際控制還是比較復(fù)雜的。

值得一提的是，FreeSWITCH與現(xiàn)在的一些視頻會議不同，比如某些會議可以簡單的支持幾百人規(guī)模的會議，將演講者畫面推到一個流媒體服務(wù)器上，但是演講者是看不到與會者的。這是實際上是一種直播的模式，與會者收到的流都是單向流，只有下行的流。

在一些直播場景中，交流互動即直播連麥。由于參與用戶規(guī)模比較大，例如十萬人的直播場景，當主播跟觀眾想要進行互動的時候，就需要把這個觀眾的層級提升，提升到主播的階層，這時我們才可以把他的畫面廣播出去。這種應(yīng)用場景與視頻會議在實現(xiàn)原理上基本是一樣的，不過FreeSWITCH的會議自始至終都是雙向流的。

有了這種方式以后， FreeSWITCH就可以跟其它的MCU進行級聯(lián)。另外有的單位已經(jīng)有MCU了， FreeSWITCH又有多個畫布，就可以把上行和下行的區(qū)分在不同的畫布上。例如圖中左邊兩個1、2是FreeSWITCH的用戶，右邊兩個手機客戶端上3、4是其它MCU的用戶，上行以后在其它MCU上進行融屏后下發(fā)即可。

●與其它會議系統(tǒng)對接●

FreeSWITCH除了與其它MCU對接、級聯(lián)外，還做了一些優(yōu)化。

因為FreeSWITCH是開源的，如果要與其它的視頻會議系統(tǒng)對接，就需要集成其它視頻會議的SDK。比如我們可以跟騰訊會議對接（目前已經(jīng)接通了音頻，視頻還沒有接），TRTC提供多平臺的SDK，我們寫了一個模塊將其放到FreeSWITCH里，FreeSWITCH就可以與它進行通信。通過PSTN我們可使用電話撥號接入到FreeSWITCH中，也就可以直接接入到騰訊會議中，FreeSWITCH可以當做網(wǎng)關(guān)一樣使用。當然PSTN現(xiàn)在還不支持視頻，只支持音頻。

另外一個是Agora的SDK，我們早在很多年前就集成了Agora的SDK，音頻和視頻都可以接通。

以Agora為例，我們在FreeSWITCH中寫了一個模塊叫mod_agrtc，這樣就可以實現(xiàn)與Agora的互通。Agora與WebRTC類似，只有媒體層的SDK沒有信令層，因此就需要自己實現(xiàn)一個信令的服務(wù)。當然一般公司會做自己的APP，需要進行注冊、鑒權(quán)等，已經(jīng)有信令服務(wù)，那么只需要調(diào)用FreeSWITCH的API，就可以控制發(fā)起呼叫、錄音等，實現(xiàn)互聯(lián)互通。但有的客戶不想自己寫信令服務(wù)，或是自己的信令服務(wù)難以擴展。所以我們也寫了一個基于WebRTC的信令服務(wù)，在移動端集成Agora的SDK，FreeSWITCH里集成了Linux的SDK，即可實現(xiàn)互通。

這其中存在一個問題，無論是Agora還是 TRTC，由于早期的SDK是針對客戶端的，所以只支持一個客戶端，也就是一個SDK只支持一路通話。于是我們又做了一個服務(wù) — IPC，有幾個通話就在FreeSWITCH中創(chuàng)建幾個進程，這樣就可以實現(xiàn)與FreeSWITCH的互通。

●微信小程序解決方案●

說到微信小程序，我們再講一下Flash。其實對于Flash的支持很早就已經(jīng)在FreeSWITCH中實現(xiàn)，FreeSWITCH有個模塊叫mod_rtmp，RTMP協(xié)議已經(jīng)實現(xiàn)了。因為微信小程序使用了RTMP的協(xié)議，我們最開始做微信小程序的時候，本來就是想在RTMP的基礎(chǔ)上進行擴展實現(xiàn)微信小程序的支持，但實際上并非如此，原來的Flash只需要一個socket和信令，就可以進行音視頻的通信，但是微信小程序不行。

微信小程序中提供了兩個組件，Live Publisher以及Live Player，是推流與拉流的概念，用RTMP的流可以收和發(fā)。于是我們就引入了SRS的服務(wù)（SRS也是一個開源軟件，主要用于直播平臺），起了個名叫mod_weixin。FreeSWITCH可以推流到SRS上，通過小程序來拉取，反之微信小程序可以推流到SRS上，FreeSWITCH再拉取。這樣就實現(xiàn)了一個雙向的通信。

由于RTMP沒有信令，所以我們又實現(xiàn)了Websocket的信令，小程序還是通過Websocket連到FreeSWITCH，這樣才能控制通話的建立和連接。

●ASR/TTS●

FreeSWITCH還支持ASR/TTS，當然并不是原生的支持，而是通過調(diào)用一些第三方的SDK實現(xiàn)，這樣就可以實現(xiàn)智能控制，甚至做自動會議記錄、自動翻譯等等。

上面是我錄制的一個視頻會議的演示視頻。我們呼入一個視頻會議，加入一個ASR的通道，然后就可以自動進行語音識別了。ASR是作為一個普通成員加進來的，大家可以看到在視頻右側(cè)已經(jīng)顯示出識別到的內(nèi)容，這樣就可以用語音來控制視頻會議的一些進展。

●NAT穿越●

在公網(wǎng)上實現(xiàn)視頻會議，不可避免的涉及到NAT穿越問題。對于NAT穿越，WebRTC已經(jīng)做得很好了，比如ICE方式。FreeSWITCH當前已經(jīng)支持ICE，在ICE打不通的時候，也可以用Stun/TURN服務(wù)器進行打通。

還有一些應(yīng)用如銀行，由于情況特殊不能開太多端口。而基于FreeSWITCH的通信每一路通話都要求多個RTP的端口。所以可以采用VPN的方式，連接到公網(wǎng)的服務(wù)器上，這樣只需要一個UDP的端口即可實現(xiàn)。

針對大規(guī)模的視頻會議，我們使用了iptables。例如我們在北京和上海都有服務(wù)器，就可以在上海的服務(wù)器上做一個iptables，然后將所有的流量全部轉(zhuǎn)化到北京的服務(wù)器，這樣客戶端就可以實現(xiàn)就近接入。當然對于一些比較靈活的應(yīng)用，就需要通過設(shè)計相應(yīng)的應(yīng)用程序來控制如何調(diào)用這些iptables做轉(zhuǎn)發(fā)。

除此之外，我們也嘗試了騰訊云的CLB（負載均衡）。實際上騰訊云的負載均衡，可以直接提供一個云的負載均衡IP，然后轉(zhuǎn)發(fā)到后端的服務(wù)上。

下一步我們計劃嘗試使用阿里的LVS。

在目前情況下，加上前面提及的會議室級聯(lián)技術(shù)，其實已經(jīng)可以實現(xiàn)相對比較大規(guī)模的視頻會議。

●4G/5G●

下一步就是4G/5G，我們其實已經(jīng)做了很多的嘗試。目前直接用手機的4G發(fā)視頻呼叫的情況可能還比較少，但在業(yè)界一些客服系統(tǒng)中已經(jīng)開始使用，部分客戶可以直接通過電話的方式，使用4G視頻呼叫到呼叫中心，進行信息交互。相信隨著未來5G的發(fā)展，通信技術(shù)與能力也會愈加強大。

FreeSWITCH社區(qū)官網(wǎng)：https://www.freeswitch.org.cn歡迎大家關(guān)注、一起交流，未來我們也會將開源進行到底。另外，考慮到FreeSWITCH涉及面可能會太窄，我們就做了一個RTS的社區(qū)—Real-Time Solutions，未來也會把對FreeSWITCH擴展的一些代碼開源，放入其中。當然最終的目標是直接放到上游的FreeSWITCH當中，但因為需要經(jīng)過各種的代碼審查，接收可能會比較慢，所以會先存放在這個倉庫中，等待時機成熟再開源到FreeSWITCH上游。如果大家有條件、有能力的話也非常歡迎一起參與進來。

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點擊【閱讀原文】了解更多詳細信息

總結(jié)

以上是生活随笔為你收集整理的​FreeSWITCH视频会议“标准”解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。