每個 WebRTC 會議產品最終都要回答同一個架構問題：媒體串流如何送達所有人，同時不耗盡用戶端頻寬或伺服器容量？這個答案會形塑未來數年的成本、品質與維運複雜度。
本文說明主要拓撲及其實務取捨，不預設特定廠商。
傳輸基礎
WebRTC 透過 UDP（並具 TCP 後備）提供加密媒體，以 ICE 建立連線、DTLS 交換金鑰、SRTP 加密媒體。信令則未被規範：由你設計。
兩項特性主導拓撲選擇：
- 上傳對用戶端而言成本高昂。 與會者的上行頻寬通常是主要限制，在行動網路上尤其如此。
- 要規模化就無法避免伺服器。 點對點對兩位與會者很優雅，對十二位則不切實際。
網狀（Mesh）
每位與會者直接連線到其他所有與會者。
- 每個用戶端上傳：n−1 條串流。
- 伺服器媒體負載：無（僅信令）。
- 最適合：一對一通話、極小型群組通話，或媒體不得經過伺服器的情境。
Mesh 的品質下降得很快。10 位與會者各送 1 Mbit/s 時，每個用戶端約上傳 9 Mbit/s，也接收相同量。行動裝置與非對稱鏈路會吃不消，而且沒有中央點可以套用政策。
SFU（Selective Forwarding Unit）
每個用戶端向伺服器發佈一條串流（或少數 simulcast 層）；伺服器將選定的串流轉發給訂閱者。
- 每個用戶端上傳：通常 1–3 層。
- 伺服器輸出：大致為 發佈者 × 訂閱者 × 層數，隨會議室規模成長。
- 最適合：多數會議產品、互動有限的大型線上研討會，以及選擇性訂閱很重要的大型會議室。
SFU 不解碼媒體，因此 CPU 成本可控，但它會終結 DTLS/SRTP，因而承擔頻寬與密碼學運算。容量規劃主要受輸出流量支配，而非編碼。
Simulcast 與 SVC
使用 simulcast 時，發佈端送出多種解析度；SFU 依每位訂閱者的網路狀況轉發合適的層。SVC 以階層式編碼達到類似的調適效果。兩者都減少對轉碼的需求，並改善壅塞下的表現，代價是發佈端更高的上行頻寬。
SFU 級聯
對於地理分散或極大型的會議室，SFU 可以級聯：一個 SFU 將已發佈的串流轉發給另一個 SFU，由後者在當地分送。這可減少跨區流量，但增加延遲跳點，也使路由與故障處理更複雜。級聯是優化手段，不是預設做法。
MCU（Multipoint Control Unit）
伺服器將音訊與視訊混合成合成串流。
- 每個用戶端上傳：一條。
- 伺服器工作：解碼、混合、編碼——CPU 密集且對編解碼敏感。
- 最適合：極大型直播、異質裝置，或接收端有嚴格頻寬限制的情況。
- 缺點：合成限制了個人化（每位觀看者看到相同版面）、增加延遲，且伺服器成為昂貴的擴充瓶頸。
現代會議產品通常採用具選擇性轉發的 SFU，僅在錄製或直播時使用伺服器端合成，而不是對每位與會者都用傳統 MCU。
比較
| 特性 | Mesh | SFU | MCU |
|---|---|---|---|
| 用戶端上傳 | 隨會議室規模成長 | 一到三層 | 一條串流 |
| 伺服器 CPU | 極低 | 中等（加解密、轉發） | 高（混流） |
| 伺服器頻寬 | 無 | 輸出流量高 | 輸出較低，CPU 較高 |
| 每位觀看者版面 | 原生 | 有彈性 | 受合成限制 |
| 最適會議室規模 | 2–4 | 4 至數百 | 大型直播 |
| 維運複雜度 | 低 | 中 | 高 |
信令設計決策
拓撲只是設計的一半。信令影響可靠度與維運：
- 狀態擁有權。 把權威的會議室狀態放在你的服務中，而不是用戶端記憶體。
- 權杖式授權。 簽發短效期加入權杖；在媒體層與信令層都驗證權限。
- 冪等操作。 重連與重試必然發生；設計加入與發佈流程時要能安全重複。
- 版本協商。 假設在滾動發布期間，用戶端與伺服器版本會不一致。
- 可觀測性鉤子。 針對加入嘗試、協商失敗與媒體品質發出事件，讓你能在無需重現工作階段的情況下除錯。
NAT 穿透與中繼
ICE 會尋找路徑，但某些網路只允許中繼連線。請為 TURN 做規劃：
- 將中繼放在靠近使用者的位置，以限制額外延遲。
- 中繼頻寬要獨立編列；經中繼的媒體會被傳輸兩次。
- 監控中繼使用量；用量突增通常代表網路變更，而非正常成長。
在私有化部署中，TURN 可能僅限內部，但跨站點與遠端存取情境通常需要邊緣中繼。
錄製與處理
錄製是一條媒體管線，不是一個勾選項。選項包括用戶端錄製、伺服器端合成，以及在 SFU 進行串流層擷取。每種做法對 CPU、儲存、同意與保留都有不同影響。先決定政策，再決定實作。
如何選擇拓撲
請用這些問題：
- 最大的典型會議室有多大？可能的最大會議室又有多大？
- 與會者主要位於受管理的網路，還是行動網路與公網？
- 觀看者需要個別版面，或共用合成畫面即可？
- 你願意為跨區流量支付多少成本？
- 你需要錄製嗎？誰能存取錄製內容？
對多數私有企業會議而言，以 SFU 為基礎、搭配 TURN 中繼、simulcast 與清楚容量模型的設計，是務實的選擇。Mesh 對邊緣情境仍有用；MCU 對直播仍有用。
結語
架構選擇其實是隱而未顯的限制條件。先決定會議室規模、網路與合規邊界，拓撲通常會隨之而來。飛雁音視頻 RTC 是基於 SFU、可私有化部署的選項；不論你評估哪家廠商，這些問題都同樣適用。
頁面中標註 Coming soon 或 Roadmap 的能力尚未在目前版本提供；產品能力與上線狀態以正式發行說明為準。