一、术语
- sdp: 在webrtc握手建连时用于描述webrtc会话的文本信息，包含音视频编解码信息、传输方式、加解密等信息。
- offer sdp: webrtc建连时主动呼叫方的sdp，一般包含多种编解码方案选项。
- answer sdp: webrtc建连时被动应答方的sdp，应答方选择优先的编解码信息并返回呼叫方。
二、webrtc建连流程
图片.png
三、系统整体架构
图片.png
- 系统主要组成部分
- Client: webrtc客户端，支持web/ios/android等形态。
- MediaServer: 媒体服务器，负责直播流的发布订阅转发转存。
- SignalServer: 信令服务器，负责videoroom房间状态维护，用户加入退出消息广播。
- 用户/业务系统: 用户实现用户鉴权、房间控制等业务逻辑。
四、信令服务器房间状态管理
4.1 用户加入房间流程
-
用户加入房间并推流：
图片.png
-
其他用户订阅此用户流
图片.png
-
用户加入房间并订阅房间其他所有用户
图片.png
4.2 用户退出房间流程
图片.png
五、媒体服务器集群设计
5.1 集群的目的
视频会议场景，发布流数等于房间人数N, 订阅流数为 N * (N-1), 房间人数越多,发布订阅数差距越大；随着房间人数的增加，网络环境愈加复杂多样，系统整体负载越高，基于发布订阅模式的视频会议模式，可以很好实现房间跨服务器、跨地域的实现，其主要解决问题如下：
- 提高系统整体容量，提高系统冗余
- 实现媒体的就近接入，提高用户体验
5.2 源站、边沿站集群模式
-
此模式流媒体服务器分为源站、边沿站；源站负责接收推流，边沿站负责拉流代理和分发流。
图片.png
5.3 平行集群模式
- 此模式不分源站边沿站，内部流媒体服务器都相同，既接收推流，也互相拉流代理分发。
图片.png
六、信令服务器集群设计
信令服务器集群实现目的有:
- 提高系统整体容量，提高系统冗余
- 实现信令的就近接入，提高用户体验
- 边沿信令服务器无状态，网络切换/重连不丢失状态
图片.png
七、基于发布订阅的VideoRoom与传统模式对比
| 发布订阅模式(zlmediakit) | 传统模式(janus) | 传统模式(mediasoup) | 备注 | |
|---|---|---|---|---|
| 负载均衡粒度 | 用户(流) | 房间 | 房间 | 传统模式粒度较大 |
| 房间是否可以跨地域 | 可以，容易实现，现成 | 不能 | 不能 | 传统模式难以解决就近接入体验问题 |
| 房间是否可以多线程 | 可以，容易实现，现成，基本无锁实现 | 可以，janus需要对房间上锁，分发流需要频繁线程切换 | 不能，单线程模型 | 传统模式单机性能差距明显 |
| 信令媒体解耦 | 相互独立，跨机部署 | 不能，必须同进程运行 | 不能，媒体部分为信令子进程 | |
| 稳定性 | 高，线程池，线程隔离模型 | 低，多线程阻塞消息列队模型 | 高，单线程模型 | janus信令业务与媒体不分，需要自行控制转发策略 |
| 可调试性 | 高，线程隔离清洗 | 低，线程模型混乱，异步多，依赖库多，出问题难定位调试 | 高，单线程模型 | mediasoup 媒体部分寄生于typescript，媒体部分可调试性待考证 |
| 生产力 | 高，媒体部分c++11技术栈，基本现成，开发量少，信令部分可独立开发 | 低，c语言开发，手动引用技术容易出错，媒体信令业务耦合 | 中，媒体信令不分，信令部分为typescipt | |
| 安防、直播技术栈整合 | 完善，已完成整合 | 无 | 无 | |
| SDK | js版本demo | android sdk | c++版本sdk | 基本都不全面，需要二次开发封装 |
网友评论