多人即時音視訊是少數「中斷五秒就會被所有與會者立刻察覺」的工作負載。當媒體路徑跑在自家網路內，你換來了對資料與拓撲的控制權，同時也得為容量、NAT 穿透與升級負責。
本文說明哪些規劃工作，決定了一套私有 RTC 會議部署能否在真實使用下站得住腳。
為什麼私有化部署會改變設計
在託管式服務中，容量、邊緣節點位置與網路路徑是供應商的問題。在私有化部署中，拓撲由你選擇，故障模式也由你承擔。這使得三個問題成為核心：
- 媒體串流往哪裡流動，經過哪些網路段？
- 尖峰時需要多少頻寬、多少媒體節點？
- 誰負責操作、監控與升級這套叢集？
參考架構
典型的私有會議堆疊會把媒體平面與控制平面分開。
用戶端 SDK
負責擷取、編碼、抗封包遺失、渲染與網路調適。行動、桌面與瀏覽器用戶端共用同一套會議室模型，但在背景執行與網路切換下的行為不同——請分別測試。
信令與會議室服務
管理會議室生命週期、身分驗證、成員資格與協商。它通常是無狀態或輕度有狀態，可以放在標準負載平衡器之後。
SFU 媒體服務
接收每位發佈者的串流，並轉發給訂閱者。對於 n 位與會者的會議，網狀（mesh）拓撲要求每個用戶端上傳 n−1 條串流；SFU 則每位用戶端只需一次上傳，由伺服器負責分送。這就是 SFU 在會議部署中佔主流的原因。
TURN／中繼服務
在直連失敗時提供中繼路徑。在內網中，這可能需求有限，但混合式與跨站點情境通常需要。請獨立規劃中繼容量：經中繼的流量會佔用兩次頻寬。
選用的媒體處理
錄製、轉碼或閘道功能應視為獨立服務，各自有容量與儲存規劃。並非每套部署都需要它們；若拓撲已預留位置，上線後再加會比較容易。
頻寬與容量估算
頻寬規劃是帶假設的算術。先從每位與會者的目標值出發，再推導出整體設施需求。
常見的規劃做法：
- 針對主要解析度與內容類型，選定每位與會者的平均傳送位元率。
- 乘上同時發佈者數量。
- 加上 SFU 的轉發係數：單一會議室的轉發串流大致等於 訂閱者 × 發佈者，叢集則按會議室加總。
- 在涉及 TURN 或跨站點鏈路時，加上中繼開銷。
- 為重傳與突發流量加上餘裕——通常是相當有感的百分比，而不是四捨五入的誤差。
以下範例的假設明確設定為假設值：
- 跨會議共 200 位同時與會者。
- 每位與會者平均 1.0 Mbit/s 視訊加上 0.05 Mbit/s 音訊。
- SFU 轉發係數 2.5（每條發佈串流的平均訂閱者數）。
- 尖峰係數為平均值的 1.5 倍。
上傳流量 ≈ 200 × 1.05 ≈ 210 Mbit/s。轉發流量 ≈ 210 × 2.5 ≈ 525 Mbit/s；再計入尖峰係數，叢集內的鏈路與節點大約要規劃到 800 Mbit/s 的媒體流量。這些數字僅供示意：你的解析度政策、內容組合與會議室規模才是決定結果的主因。
同時也要規劃：
- 單節點上限。 用於加密與轉發的 CPU、用於抖動緩衝的記憶體，以及網路介面容量。
- 故障餘裕。 失去一個媒體節點不應讓整場會議中斷。在關鍵處以 n+1 規劃。
- 跨站點流量。 若與會者分散在不同站點，要決定媒體是跨 WAN 轉發，還是就近終結後再橋接。
網路考量
- UDP 是預設。 為媒體提供清楚的連接埠範圍與防火牆規則，並以與正式環境相同的防火牆政策測試。
- NAT 與對稱式網路。 純內網部署或許可避開公用 STUN，但混合式情境仍需要 TURN 或中繼。
- MTU 與分段。 VPN 與通道會縮小可用 MTU；請驗證大封包行為。
- QoS 標記。 若網路支援，請標記音訊與視訊流量，讓壅塞時優先影響正確的流量。
編解碼與調適
瀏覽器與裝置的支援度，對編解碼選擇的約束比偏好更大。會議場景可考慮：
- 硬體加速編解碼，以節省電量與 CPU。
- Simulcast 或可階層式編碼（SVC），讓 SFU 能對不同接收端轉發不同品質。
- 音訊處理與回音消除——它們對主觀品質的影響比解析度更大。
請明確測試調適行為：強制封包遺失與頻寬限制，然後驗證視訊降級時音訊仍能維持。
上線後的維運
私有 RTC 不會在上線當天結束。請規劃：
- 監控——加入成功率、首次畫面時間、封包遺失、往返延遲、各節點負載。告警要針對使用者可見的症狀，而不只是 CPU。
- 升級——元件相容性、滾動升級與回復路徑。通話期間媒體節點是有狀態的，排空（draining）需要謹慎。
- 容量檢視——追蹤尖峰併發數，並在每季業務高峰前更新規劃。
- 事件手冊——中繼故障、憑證到期、節點失效與網路政策變更。
- 組態管理——把拓撲與政策當成程式碼管理，讓各環境保持一致。
安全
- 以你的系統簽發的短效期權杖驗證加入會議。
- 傳輸中的媒體要加密；若需要端對端加密，請確認伺服器仍能觀察到什麼。
- 把管理介面限制在管理網路內。
- 將錄製內容與任何媒體儲存的存取紀錄，與應用程式日誌分開記錄。
POC 的驗收標準
有用的 POC 規模不大，但具對抗性：
- 一個 10–20 位與會者、橫跨混合網路與裝置的會議室。
- 在媒體路徑上注入封包遺失與延遲。
- 通話期間使節點失效。
- 從前一版本升級。
- 在規劃尖峰下執行頻寬測試，並在事後檢視監控結果。
何時不該選私有 RTC
若會議是偶發性的、容量難以預測，或你沒有負責媒體基礎設施的維運團隊，託管式服務通常能在相同投入下提供更好的體驗。唯有當資料控制、網路隔離或整合深度確實大於維運負擔時，私有化部署才划算。
飛雁音視頻 RTC 就是為私有化部署而設計；若託管式服務更適合你的情況，我們會誠實告訴你。
頁面中標註 Coming soon 或 Roadmap 的能力尚未在目前版本提供；產品能力與上線狀態以正式發行說明為準。