一、術語
- sdp: 在webrtc握手建連時用于描述webrtc會話的文本信息，包含音視頻編解碼信息、傳輸方式、加解密等信息。
- offer sdp: webrtc建連時主動呼叫方的sdp，一般包含多種編解碼方案選項。
- answer sdp: webrtc建連時被動應答方的sdp，應答方選擇優(yōu)先的編解碼信息并返回呼叫方。
二、webrtc建連流程
圖片.png
三、系統(tǒng)整體架構
圖片.png
- 系統(tǒng)主要組成部分
- Client: webrtc客戶端，支持web/ios/android等形態(tài)。
- MediaServer: 媒體服務器，負責直播流的發(fā)布訂閱轉(zhuǎn)發(fā)轉(zhuǎn)存。
- SignalServer: 信令服務器，負責videoroom房間狀態(tài)維護，用戶加入退出消息廣播。
- 用戶/業(yè)務系統(tǒng): 用戶實現(xiàn)用戶鑒權、房間控制等業(yè)務邏輯。
四、信令服務器房間狀態(tài)管理
4.1 用戶加入房間流程
-
用戶加入房間并推流：
圖片.png -
其他用戶訂閱此用戶流
圖片.png -
用戶加入房間并訂閱房間其他所有用戶
圖片.png
4.2 用戶退出房間流程
圖片.png
五、媒體服務器集群設計
5.1 集群的目的
視頻會議場景，發(fā)布流數(shù)等于房間人數(shù)N, 訂閱流數(shù)為 N * (N-1), 房間人數(shù)越多,發(fā)布訂閱數(shù)差距越大；隨著房間人數(shù)的增加，網(wǎng)絡環(huán)境愈加復雜多樣，系統(tǒng)整體負載越高，基于發(fā)布訂閱模式的視頻會議模式，可以很好實現(xiàn)房間跨服務器、跨地域的實現(xiàn)，其主要解決問題如下：
- 提高系統(tǒng)整體容量，提高系統(tǒng)冗余
- 實現(xiàn)媒體的就近接入，提高用戶體驗
5.2 源站、邊沿站集群模式
-
此模式流媒體服務器分為源站、邊沿站；源站負責接收推流，邊沿站負責拉流代理和分發(fā)流。
圖片.png
5.3 平行集群模式
- 此模式不分源站邊沿站，內(nèi)部流媒體服務器都相同，既接收推流，也互相拉流代理分發(fā)。
圖片.png
六、信令服務器集群設計
信令服務器集群實現(xiàn)目的有:
- 提高系統(tǒng)整體容量，提高系統(tǒng)冗余
- 實現(xiàn)信令的就近接入，提高用戶體驗
- 邊沿信令服務器無狀態(tài)，網(wǎng)絡切換/重連不丟失狀態(tài)
圖片.png
七、基于發(fā)布訂閱的VideoRoom與傳統(tǒng)模式對比
| 發(fā)布訂閱模式(zlmediakit) | 傳統(tǒng)模式(janus) | 傳統(tǒng)模式(mediasoup) | 備注 | |
|---|---|---|---|---|
| 負載均衡粒度 | 用戶(流) | 房間 | 房間 | 傳統(tǒng)模式粒度較大 |
| 房間是否可以跨地域 | 可以，容易實現(xiàn)，現(xiàn)成 | 不能 | 不能 | 傳統(tǒng)模式難以解決就近接入體驗問題 |
| 房間是否可以多線程 | 可以，容易實現(xiàn)，現(xiàn)成，基本無鎖實現(xiàn) | 可以，janus需要對房間上鎖，分發(fā)流需要頻繁線程切換 | 不能，單線程模型 | 傳統(tǒng)模式單機性能差距明顯 |
| 信令媒體解耦 | 相互獨立，跨機部署 | 不能，必須同進程運行 | 不能，媒體部分為信令子進程 | |
| 穩(wěn)定性 | 高，線程池，線程隔離模型 | 低，多線程阻塞消息列隊模型 | 高，單線程模型 | janus信令業(yè)務與媒體不分，需要自行控制轉(zhuǎn)發(fā)策略 |
| 可調(diào)試性 | 高，線程隔離清洗 | 低，線程模型混亂，異步多，依賴庫多，出問題難定位調(diào)試 | 高，單線程模型 | mediasoup 媒體部分寄生于typescript，媒體部分可調(diào)試性待考證 |
| 生產(chǎn)力 | 高，媒體部分c++11技術棧，基本現(xiàn)成，開發(fā)量少，信令部分可獨立開發(fā) | 低，c語言開發(fā)，手動引用技術容易出錯，媒體信令業(yè)務耦合 | 中，媒體信令不分，信令部分為typescipt | |
| 安防、直播技術棧整合 | 完善，已完成整合 | 無 | 無 | |
| SDK | js版本demo | android sdk | c++版本sdk | 基本都不全面，需要二次開發(fā)封裝 |
