《聊聊 WebRTC 網關服務器》系列文章系由 WebRTCon2018 中網易雲信音視頻技術專家的分享內容《從零開始構建音視頻網關服務器》整理而成,該系列文章將和你們分享網易 NRTC 在 WebRTC 網關項目的自研過程當中遇到的一些問題,以及咱們最終的解決方法。
《聊聊WebRTC網關服務器》第二篇文章將和你們分享如何選擇PeerConnection方案。
在會議場景下,網易 NRTC 的 WebRTC 網關使用的是 SFU 方案,如上圖舉例所示,每一個 WebRTC 上行一路媒體數據到 WebRTC 網關服務器,同時還須要從網關接收下行的三路媒體數據,對於一個 WebRTC 客戶端來講就有多路流。對於這種多流的場景,咱們有兩種 PeerConnection 方案可使用:git
那咱們如何選擇 PeerConnection 的方案呢?github
首先咱們來看看單 PeerConnection 方案,全部的客戶端和服務器之間只須要創建一個 PeerConnection,這個 PeerConnection 是一個雙向的 PeerConnection,它既能夠發數據,也能夠收數據,這個方案簡單明瞭,實現時候要注意一個問題,就是 Chrome 和 Firefox 在實現單 PeerConnection bundle 時採用的 SDP 方案是不同的。Chrome 是用了Plan B 的方案,Firefox 是用了 Unified Plan 的方案。固然 Chrome 將來即將支持 Unified Plan,而當前要使用單 PeerConnection 方案就必須在 Server 端編寫兼容代碼。PlanB 採用的是一個 m 行,多個 a 行來描述多流,而 Unified Plan 是多個 m 行,描述多流,具體的作法 RFC 草案文檔裏面有詳細描述,我這裏就不贅述了。web
那麼單 PeerConnection 有什麼優點呢?算法
單 PeerConnection 又有什麼劣勢?瀏覽器
而相對單 PeerConnection,多 PeerConnection 的方案就比較便於理解了,如圖 A/B/C/D 四我的的會,對於 A 來講有一個上行的 PeerConnection,以及 3 個下行的 PeerConnection對應 B/C/D。每個用戶的上下行數據都是分開的,這個也是WebRTC比較推薦的方案。
這個方案主要的難點是服務端要去維護每一個用戶的上下行 PeerConnection 對應關係,總體的代碼邏輯較複雜。可是它的兼容性比較好。因此 NRTC 的 WebRTC 網關最終選擇了多 PeerConnection 方案。服務器
在分享完 PeerConnecton 的方案後,下面就進入 Server 的線程方案的選擇和優化。這個也是網關服務器架構設計的核心部分。微信
《聊聊 WebRTC 網關服務器》第三篇文章將具體爲你們介紹如何優化 Server 的線程方案。
隨着音頻處理和壓縮技術的不斷髮展,效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現,若是你有好的技術或者分享,歡迎關注網易 MC 官方博客以及微信公衆號:**架構
關注更多技術乾貨內容: 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網官網微信公衆號:
性能