1v1 用 P2P，多人立刻评估 SFU。这一节回答：拓扑怎么选、SFU 怎么挑、录制/转推/互通怎么做。
阅读顺序（计划）
| 顺序 | 文件 | 解决的问题 |
|---|
| 1 | 拓扑选型Mesh-SFU-MCU.md | 各自适用规模、成本 |
| 2 | SFU横向对比.md | mediasoup / Janus / LiveKit / Pion / Jitsi |
| 3 | 录制方案.md | 客户端录制 vs 服务端旁路 vs 合流转推 |
| 4 | 与传统视频系统互通.md | WebRTC ↔ SIP / RTMP / WHIP-WHEP |
| 5 | 可观测性与QoE.md | trace、指标、上报模型 |
拓扑决策树
| 拓扑 | 上行 | 下行 | 适合 | 致命缺点 |
|---|
| Mesh | (N-1)× 上行 | (N-1)× 下行 | ≤ 3 人 | 4 人开始爆炸 |
| SFU（Selective Forwarding Unit） | 1× 上行 | (N-1)× 下行 | 5~50 人 | 需要服务器、抗丢包靠端 |
| MCU（Multipoint Conferencing Unit） | 1× 上行 | 1× 下行（合流） | 移动端弱算力 | 服务器算力贵，自由度低 |
现代 WebRTC 几乎全部用 SFU。MCU 仅在移动端弱算力或合规要求统一合流时使用。
SFU 横向对比
| 选型 | 语言 | 强项 | 弱点 | 适合 |
|---|
| mediasoup | Node + C++ | 灵活度极高、性能好、社区强 | 没有开箱即用 UI / 房间逻辑 | 自研产品 |
| LiveKit | Go | 工程化最完整、有 SDK 全家桶、云服务可对照 | 部分定制要改源码 | 90% 业务首选 |
| Janus | C | 模块化插件、与 SIP 互通强 | 文档老旧、API 复杂 | VoIP 互通 |
| Pion | Go | 纯 Go 实现、定制 WHIP/WHEP 极方便 | 不是完整 SFU 框架 | 自研直播 |
| Jitsi Videobridge | Java | 与 Jitsi Meet 集成 | 跨产品集成成本高 | 内部会议系统 |
录制三种路线
| 路线 | 实现 | 优点 | 缺点 |
|---|
| 客户端录制 | MediaRecorder | 简单、本地保存 | 占客户端 CPU；离场即断 |
| 服务端旁路 | SFU 拉一份 RTP → ffmpeg | 服务端可控 | 需要 SFU 暴露端口 |
| 合流转推 | SFU 把多路合成一路推 RTMP/HLS | 直接走 CDN | 合流贵，自由度低 |
WHIP / WHEP：标准化的低延迟直播
- WHIP（WebRTC-HTTP Ingestion Protocol，RFC 9725）：用 HTTP POST 上传 SDP Offer，服务端回 Answer，建立 WebRTC 推流。OBS 31+ 原生支持。
- WHEP（WebRTC-HTTP Egress Protocol，IETF draft）：对称的拉流协议。
意义：简化信令——不用维护 WebSocket 房间，直接打一次 HTTP 就能推流/拉流，对 CDN 极友好。
可观测性最小集
每路通话至少上报：
| 维度 | 字段 |
|---|
| 接入 | 用户 ID、房间 ID、客户端版本、平台、UA |
| 网络 | 选定 candidate-pair 类型（host/srflx/relay）、RTT |
| 媒体 | 发送码率、丢包率、freezeCount、qualityLimitationReason |
| 决策 | 当前订阅哪一层 Simulcast / SVC |
| 异常 | ICE failed、DTLS failed、断线、ICE Restart |
QoE 模型推荐参考 LiveKit 的 Analytics 或自研 freeze ratio + MOS 估计。
反模式
| 反模式 | 后果 |
|---|
| 5 人会议硬上 Mesh | 上行带宽爆炸 |
| 自研 SFU 不接 TWCC | 弱网用户体验崩 |
| 录制全靠客户端 | 用户走了录像没了 |
| 直播平台用 WebRTC 扛万人 | SFU 级联成本远高于 CDN |
| 不区分 host/relay 上报 | QoE 看不出问题在自家还是用户网络 |
权威资料