多方音视频是少数几种一旦中断五秒就会被所有参会者立刻察觉的负载。当媒体链路运行在自有网络内，你获得了对数据和拓扑的控制权，同时也要对容量、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 或可分层视频编码，使 SFU 能向不同接收端转发不同质量。
- 音频处理与回声消除，它们对主观质量的影响大于分辨率。
要显式测试自适应能力：人为制造丢包和带宽限制，然后验证视频劣化时音频仍然可用。
上线后的日常运维
私有化 RTC 并不止于上线。需要规划：
- 监控——入会成功率、首帧时间、丢包率、往返时延、单节点负载。告警应基于用户可感知的症状，而不只是 CPU。
- 升级——组件兼容性、滚动升级和回滚路径。通话期间媒体节点是有状态的，摘流需要谨慎。
- 容量复盘——跟踪并发峰值，并在季度业务高峰前更新规划。
- 故障预案——中继故障、证书过期、节点丢失和网络策略变更。
- 配置管理——把拓扑和策略当作代码管理，使各环境保持一致。
安全
- 使用由自有系统签发的短期令牌对接入房间进行鉴权。
- 对传输中的媒体加密；如果要求端到端加密，需确认服务端仍能观察到哪些信息。
- 将管理接口限制在管理网内。
- 将对录制文件和媒体存储的访问日志与应用日志分开记录。
POC 验收标准
有价值的 POC 规模不大，但足够“对抗”：
- 一个房间，10–20 位参会者，混合网络与设备。
- 在媒体路径上注入丢包和时延。
- 通话过程中发生节点故障。
- 从上一版本执行一次升级。
- 在规划的峰值下做带宽测试，并在之后复盘监控数据。
什么情况下不适合选择私有化 RTC
如果会议使用是偶发的、容量难以预测，或者你没有负责媒体基础设施的运维团队，托管服务通常能以同样的投入带来更好的体验。只有当数据控制、网络隔离或集成深度确实超过运维负担时，私有化部署才划算。
飞雁音视频 RTC 面向私有化部署而构建，但如果托管服务更适合你的情况，我们也会如实告知。
页面中标注 Coming soon 或 Roadmap 的能力尚未在当前版本提供；产品能力与上线状态以正式发布说明为准。