聊聊 WebRTC 網關服務器 2:如何選擇 PeerConnection 方案?

《聊聊 WebRTC 網關服務器》系列文章系由 WebRTCon2018 中網易雲信音視頻技術專家的分享內容《從零開始構建音視頻網關服務器》整理而成,該系列文章將和你們分享網易 NRTC 在 WebRTC 網關項目的自研過程當中遇到的一些問題,以及咱們最終的解決方法。
《聊聊WebRTC網關服務器》第二篇文章將和你們分享如何選擇PeerConnection方案。

圖片描述

在會議場景下,網易 NRTC 的 WebRTC 網關使用的是 SFU 方案,如上圖舉例所示,每一個 WebRTC 上行一路媒體數據到 WebRTC 網關服務器,同時還須要從網關接收下行的三路媒體數據,對於一個 WebRTC 客戶端來講就有多路流。對於這種多流的場景,咱們有兩種 PeerConnection 方案可使用:git

  1. 單個PeerConnection裏有多個 media stream (bundle);
  2. 爲不一樣的 media stream 建立不一樣的 PeerConnection。

那咱們如何選擇 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 有什麼優點呢?算法

  1. Server端媒體處理代碼相對簡單;
  2. 服務端性能較好,只須要創建一個PeerConnection鏈接,DTLS握手只須要作一次。

單 PeerConnection 又有什麼劣勢?瀏覽器

  1. 服務器須要編寫兼容不一樣瀏覽器的代碼;
  2. 不一樣用戶的下行媒體流過多後,SDP 裏面 m 行或 a 不少,致使 SDP 長度過長;特別是當用戶頻繁進出或者媒體狀態發生改變時,SDP 須要進行頻繁 Update, SDP 傳輸耗費的帶寬就會不少;
  3. Firefox Unified Plan 在多人場景下,較高的機率下會出現崩潰 Bug,咱們已經向 Firefox 提交了 bug。

圖片描述

而相對單 PeerConnection,多 PeerConnection 的方案就比較便於理解了,如圖 A/B/C/D 四我的的會,對於 A 來講有一個上行的 PeerConnection,以及 3 個下行的 PeerConnection對應 B/C/D。每個用戶的上下行數據都是分開的,這個也是WebRTC比較推薦的方案。
這個方案主要的難點是服務端要去維護每一個用戶的上下行 PeerConnection 對應關係,總體的代碼邏輯較複雜。可是它的兼容性比較好。因此 NRTC 的 WebRTC 網關最終選擇了多 PeerConnection 方案。服務器

在分享完 PeerConnecton 的方案後,下面就進入 Server 的線程方案的選擇和優化。這個也是網關服務器架構設計的核心部分。微信

《聊聊 WebRTC 網關服務器》第三篇文章將具體爲你們介紹如何優化 Server 的線程方案。

隨着音頻處理和壓縮技術的不斷髮展,效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現,若是你有好的技術或者分享,歡迎關注網易 MC 官方博客以及微信公衆號:**架構

關注更多技術乾貨內容: 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網

官網微信公衆號:
圖片描述性能

相關文章
相關標籤/搜索