通過重寫WEBRTC傳輸模組來實現一個簡單的視訊會議，效果如下圖：

說明：

1、畫面1、2、3都是其他手機傳過來的影象，區域網內有點點卡頓，同時軟解3路資料你懂的。

2、聲音比較清晰，服務端沒有做混音處理。

實現原理：

1、服務端是小夥伴用C++配合實現的，主要作用就是信令控制與轉發，所以原理沒有太多好講的。

2、因為有在WEBRTC裡面註冊自己的傳輸模組，所以在這個基礎上實現多人就很容易了，主要就是讓服務端轉發的時候知道往哪裡轉發。

3、WEBRTC裡面有channel機制，每個會話對應一個channel，如果要實現多個會話，就註冊多個channel，關鍵程式碼如下：

下面是收到RTP包後通過channel找到對應的transport進行處理

總結：

1、通過上面這個demo可以做很多擴充套件，比如視訊直播、線上教學、安防監控。

2、很多開源框架都是基於這種架構模式，如Licode，jitsi。

3、這種模式以後結合VP9,H265和SVC會有很好的發展空間，不過需要時間，所以我們會繼續關注。

思考：

這種模式下怎麼處理NACK和RTCP？

隨著移動網際網路和智慧硬體的快速發展，音視訊變得越來越重要，加上WEBRTC的出現，讓開發這些高大上的功能變得越來越容易，

實際上是這樣嗎？讓我們先來看看WEBRTC應用中的一些現象吧！

一、專案開始前都是這樣的：

1、程式碼都開源了，找個開發人員2個月內將他整合進來，到時候就是中國特色的完全自主研發。

2、Google在搞的東西，不說效果比QQ和微信好多少，至少不會差到哪裡去。

3、我們開發人員裡面精通C++，安卓，iOS，Web前端的好幾個，搞定這套東西還不是收到擒拿。

4、手機端不需要用Native開發，用WebView即可，這樣可省下好多人力成本。

5、如果用這套東西做成視訊會議或直播秀，是不是可以跟現有廠家有得一拼，我們有線下資源啊。

6、直接招個熟悉這個東西的人進來做這個專案算了，工資可以稍微高點。

7、等等等等。

二、開發過程中很多都是這樣的：

1、到底從哪裡入手呢？資料少不說，很多資料還是有問題的。

2、服務端客戶端到底怎麼搭建的，要不要編譯整套程式碼呢？

3、下載和編譯了2個星期了，還是啥都沒搞定，鬱悶。

4、怎麼有時候沒有視訊，有時候沒有聲音，延遲怎麼那麼大呢？

5、搞了1個多月了，問題好多，沒一點思路，不知道咋搞，放棄算了。

6、原定1個月整合進來的，現在都搞了快3個月了，還有好多沒搞定。

7、東西是弄的差不多了，但是後續還是得有人來優化和維護，包括部分安卓機型的適配。

8、招聘了大半年，都沒找到合適的人，在我們公司待遇不是問題，有合適的人就行。

9、webrtc沒有支援多人視訊，開源的用哪個好呢？或者有沒有其他成熟第三方平臺呢？

10、如果要支援全球部署，還得考慮服務端架設成本啊，這塊費用也很高。

11、等等等等，不搞不知道，一搞下去問題好多。

...... ......

曾經或現在正在弄WEBRTC的朋友們，有沒有同感？

其實上面這些現象我們都見過，只不過不同企業因為能力和實力不一樣，所碰到的狀況不一樣，比如：

專業做音視訊的可能對WEBRTC裡面很多思想都清楚，甚至某些方面他們做得比WEBRTC更好，可能只需要應用裡面的部分模組。大公司高手多，研究和突破起來速度比較快，比如華為，但是他們也會碰到很多問題。所以下面的這些建議要結合自己的實際：