基于发布订阅机制的WebRTC videoroom设计

一、术语

• 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	基本都不全面，需要二次开发封装