1. Webrtc三種類型通信架構
1.1? 1 對 1 通信
1 對 1 通信模型設計的主要?標是盡量讓兩個終端進?直聯，這樣即可以節省服務器的資源，?可以提? ?視頻的服務質量。WebRTC ?先嘗試兩個終端之間是否可以通過 P2P 直接進?通信，如果?法直接通信 的話，則會通過 STUN/TURN 服務器進?中轉，如下圖：
?1.2? 多對多通信
Mesh 架構：適合剛學習 WebRTC 的場景，簡單易實現，但實際應用中因上行帶寬占用大、線性資源占用等問題，超過 4 人時問題明顯，幾乎無人在真實場景中使用。
MCU 架構：硬件 MCU 曾在視頻會議廣泛應用，技術成熟，但價格昂貴，且隨著互聯網發展逐步被淘汰；軟 MCU 如 FreeSWITCH 雖存在，但因 CPU 消耗大，真正使用者不多。
SFU 架構：近年來流行，是 WebRTC 多方通信媒體服務器的主流架構，具有高靈活性和高性能，配合 Simulcast 或 SVC 模式可更好地適應不同網絡和終端，被多數公司采用。
Janus的多方視頻通話使用VideoRoom插件，采用SFU架構。
| 維度 | mesh(P2P) | SFU | MCU |
|---|---|---|---|
| 延遲 | 最低（直連） | 中等（服務器中轉） | 最高（處理流程復雜） |
| 帶寬消耗 | 上行壓力大（N2增長） | 下行壓力大（服務器承擔） | 整體最低（單一流） |
| 擴展性 | 差（適合1:1） | 優（適合中小型會議） | 一般（適合大型會議） |
| 服務器成本 | 低（僅需穿透輔助） | 中（高帶寬需求） | 高（計算+帶寬雙重壓力） |
| 終端要求 | 需處理多流解碼 | 需多流解碼能力 | 僅需解碼單一流 |
| 靈活性 | 高（端到端控制） | 高（自由訂閱流） | 低（布局固定） |
| 典型應用 | 微信語音、Skype 1:1 | Zoom、騰訊會議 | 傳統硬件視頻會議系統 |
| 特點 | 多對多，Mesh 結構 | 發布訂閱 | 混流集合 |
?
?1.2.1 架構優點
| 架構 方案 | 優勢 |
|---|---|
| Mesh 架構 | - 無需中轉服務器，直接利用 WebRTC 通信模型，無需額外開發媒體服務器，降低了開發成本和復雜度。 - 充分利用客戶端的帶寬資源，將服務器端的帶寬壓力分散到各客戶端，節省了服務器成本。 - 原有通信模型的簡潔性，這種架構充分利用了現有的 WebRTC 通信模型，結構相對簡單，易于實現和維護。 |
| MCU 架構 | - 技術成熟，在硬件視頻會議領域應用廣泛，技術相對成熟可靠，能夠提供穩定的通信服務。 - 兼容性強，作為音視頻網關，通過解碼、再編碼可以屏蔽不同編解碼設備之間的差異化，滿足更多客戶的集成需求，提升用戶體驗和產品競爭力。 - 統一畫面輸出，將多路視頻混合成一路，所有參與者看到的是相同的畫面，有助于提供一致的客戶體驗。 |
| SFU 架構 | - 低資源消耗，數據包直接轉發，不需要進行編解碼操作，對 CPU 資源消耗很小，降低了服務器的硬件成本和運營成本。 - 低延遲，數據包直接轉發極大地降低了延遲，提高了通信的實時性，適合對實時性要求較高的應用場景。 - 靈活性高，可以根據終端下行網絡狀況進行流控，如根據帶寬、網絡延時情況選擇性地丟棄一些媒體數據，以保證通信的連續性，更好地適應不同的網絡狀況和終端設備。 - 支持多種模式，許多 SFU 實現支持 SVC 模式和 Simulcast 模式，能夠更好地適配 WiFi、4G 等不同網絡狀況，以及 Phone、Pad、PC 等不同終端設備，提高了系統的兼容性和可用性。 |
????????Simulcast 模式就是指視頻的共享者可以同時向 SFU 發送多路不同分辨率的視頻流（?般為三路， 如 1080P、720P、360P）。? SFU 可以將接收到的三路流根據各終端的情況?選擇其中某?路發送出 去。例如，由于 PC 端?絡特別好，給 PC 端發送 1080P 分辨率的視頻；?移動?絡較差，就給 Phone 發送 360P 分辨率的視頻。?Simulcast 模式對移動端的終端類型?常有?，它 可以靈活??智能地適應不同的?絡環境。??????
?????????SVC（ Scalable Video Coding） 是可伸縮的視頻編碼模式。與 Simulcast 模式的 SVC 模式是 同時傳多路流不同， 在視頻編碼時做“ ?腳” 。它在視頻編碼時將視頻分成多層—— 核?層、中間層和擴展層。上層依賴于底層，?且越上層越清晰，越底層越模糊。在帶寬不好的情況下，可以只傳輸核?層，在帶寬充?的情況下，可以將三層全部 傳輸過去。
??
?2. Janus 系統架構
????????Janus 被設計為通用的 WebRTC 服務器，專注于模塊化和可擴展性。它提供必要的 WebRTC 基礎設施，同時將特定的應用程序邏輯委托給插件。這種分離使 Janus 變得輕量級和靈活，無需更改內核即可支持廣泛的用例。
架構的關鍵原則：
- 模塊化設計：核心組件通過定義明確的接口清晰分離
- 基于插件的可擴展性：所有特定于應用程序的邏輯都在插件中實現
- 多傳輸支持：用于客戶端交互的多種通信協議
- 媒體和信令分離：WebRTC 媒體處理和信令邏輯之間的明確分離
全局架構圖如下：
2.1 核心組件
????????Janus 核心處理 WebRTC 和會話管理基礎知識，提供插件和傳輸構建的基礎基礎設施。
2.1.1?會話和句柄模型
Janus 中最重要的架構概念之一是 session/handle 模型：
- 會話：表示用戶與 Janus 的連接
- Handle：表示用戶與特定插件之間的連接
- PeerConnection：與句柄關聯的 WebRTC 連接
- transaction：表示當前消息信息的唯一句柄
這種關系在用戶、插件和媒體連接之間建立了明確的分離。客戶端與 Janus 創建會話。在此會話中，客戶端可以附加到多個插件（創建句柄）。每個句柄都有自己的 WebRTC PeerConnection，用于管理媒體交換。
2.1.2?會話管理
會話是客戶端連接到 Janus 的核心抽象。會話管理系統處理：
- 會話創建和銷毀
- 會話超時（可配置，默認 60 秒）
- 會話聲明（在傳輸斷開連接后恢復會話）
每個會話都包含句柄，這些句柄是會話和插件實例之間的橋梁。會話層維護客戶端與其插件附件之間的關系。
2.1.3 Media Handl管理
Janus 的媒體處理層負責 WebRTC 連接和媒體處理。ICE （Interactive Connectivity Establishment） 組件處理：
- 候選人聚集和交流
- NAT 遍歷
- 連接建立
- 用于安全連接的 DTLS 協商
- 用于加密媒體的 SRTP
??????
媒體路徑處理：
- RTP/RTCP 數據包從?routing 到plugins
- SDP offer/answer 處理
- 媒體統計和監控
- 數據包重傳的 NACK 處理
- TWCC（全交通擁堵控制）
2.2 插件系統
????????Janus 提供了一個插件架構，允許開發人員在不修改核心代碼庫的情況下實現各種 WebRTC 應用程序。插件向 Janus 核心注冊，并為消息處理和媒體處理等事件實施回調。內核僅負責 WebRTC 連接和數據包路由，而插件則決定媒體會發生什么并實現應用程序邏輯。
Janus 包含的常見插件：
- VideoRoom：用于多方視頻會議的選擇性轉發單元 （SFU）
- AudioBridge：具有混音功能的音頻會議
- 流式處理：媒體流式處理（RTP、RTSP、HLS 源）
- SIP：用于 WebRTC 到 SIP 互作性的 SIP 網關
- EchoTest：用于測試 WebRTC 功能的簡單 echo 測試插件
- TextRoom：基于數據通道的文本聊天室
- RecordPlay：WebRTC 會話的錄制和播放
插件 API 公開了允許插件執行以下作的函數：
- 接收和發送媒體 （RTP/RTCP）
- 與客戶交換消息
- 管理 WebRTC 連接
- 處理 SDP offers/answers
- 通過 Data Channel 發送和接收數據
2.3?傳輸層
????????傳輸層提供客戶端和 Janus 服務器之間的通信通道。可以同時使用多種傳輸機制，從而靈活地選擇客戶端連接到 Janus 的方式。
- HTTP/REST：用于請求-響應交互的傳統 REST API
- WebSockets：實時雙向通信
- RabbitMQ：基于消息隊列的通信
- MQTT：輕量級發布-訂閱消息傳遞
- Unix 套接字：同一臺機器上的進程間通信
???????
?所有傳輸都實現相同的 API，無論底層協議如何，都為核心提供一致的接口。這允許客戶端選擇最適合其需求的傳輸機制。
傳輸層負責：
- 身份驗證請求（如果已配置）
- 解析和驗證 JSON 消息
- 將請求路由到適當的會話/句柄
- 將事件和響應返回給客戶端
2.4 事件處理程序
????????事件處理程序為外部應用程序提供了一種監視和響應 Janus 中發生的事件的方法。這些事件可以包括會話創建/銷毀、媒體統計、特定于插件的事件等。事件處理程序（如傳輸和插件）在啟動時動態加載，并在內核中注冊。它們從核心接收事件，并將其轉發到外部系統進行監控、記錄或處理。
2.5 實用程序和工具
2.5.1?實用程序
????????Janus 提供了多種后處理工具，用于將錄音轉換為可以使用常見媒體播放器播放的標準格式。實用程序允許您將 Janus Media Recorder （） 文件轉換為標準媒體格式。
Supported Output Formats??支持的輸出格式
| 輸入編解碼器 | 輸出擴展名 | 描述 |
|---|---|---|
| VP8/VP9 | .webm, .mkv | WebM 容器格式用于 VP8/VP9 視頻 |
| H.264 | .mp4, .mkv | MP4/Matroska 容器用于 H.264 視頻 |
| H.265 | .mp4, .mkv | MP4/Matroska 容器用于 H.265 視頻 |
| AV1 | .mp4, .mkv | MP4/Matroska 容器用于 AV1 視頻 |
| Opus | .opus, .ogg, .mka | Opus 音頻的各種容器 |
| G.711 | .wav | WAV 容器用于 G.711 音頻 |
| G.722 | .wav | WAV 容器用于 G.722 音頻 |
| L16 | .wav | WAV 容器用于 L16（PCM）音頻 |
| 文本數據 | .srt | 數據通道文本的 SRT 字幕格式 |
基本用法：
./janus-pp-rec /path/to/source.mjr /path/to/destination.[opus|ogg|mka|wav|webm|mkv|mp4|srt]
#分析錄制信息而不進行處理：
./janus-pp-rec --json /path/to/source.mjr # Print JSON header
./janus-pp-rec --header /path/to/source.mjr # Parse header only
./janus-pp-rec --parse /path/to/source.mjr # Parse without processing
Janus 還包括用于在 Janus 錄音和數據包捕獲格式之間進行轉換的實用程序：
mjr2pcap：將 Janus 記錄轉換為 PCAP 格式，以便在 Wireshark 等工具中進行分析pcap2mjr：將 PCAP 文件轉換為 Janus 錄制格式
?2.5.2 測試工具
????????Janus 提供了測試工具來驗證 WebRTC 網關的功能和性能。aiortc 測試套件！該目錄包含使用 WebRTC 功能測試庫的基于 Python 的測試工具。test/aiortc
測試套件的 Python 依賴項：
websockets==15.0
aiortc==1.10.1
可以使用提供的幫助程序腳本執行測試套件：
./test_aiortc.sh echo.py ws://localhost:8188/3.1 數據流架構
????????下圖說明了在典型的 WebRTC 交互期間通過 Janus 架構的完整數據流。此流程展示了 Janus 的不同層如何協同工作以處理 WebRTC 信令、媒體交換和特定于應用程序的邏輯。各個組件之間的干凈分離實現了靈活性和可擴展性。
英文版：?
學習資料分享
0voice · GitHub
){kind=icon}
