2.8 KiB
2.8 KiB
整体设计
设计
项目当前采用方案:
- 监控(WebRTC)
- 会议(Mediasoup独立Router)
监控(WebRTC)
使用原始WebRTC实现,监控和被监控终端使用P2P连接。
优点
- 实现逻辑简单
- 服务端没有压力(
P2P媒体直连)
缺点
- 终端上行流量较大(同时被多个终端监控时)
监控(Mediasoup独立Router)
使用Mediasoup实现,所有终端进入一个Router,通过Mediasoup转发媒体实现监控。
优点
- 终端只会存在一路上行流量
缺点
- 单个
Router压力较大(监控终端数量较多时)
监控(Mediasoup代理Router)
使用Mediasoup实现,每个终端对应一个代理Router,通过PipeTransport转发代理Router媒体实现监控。
优点
- 终端只会存在一路上行流量
- 压力不会集中某个
Router
缺点
- 实现逻辑复杂
- 服务端压力较大(媒体通道生产者消费者数量增加)
会议(Mediasoup独立Router)
使用Mediasoup实现,每个会议对应一个Router,Router内部媒体直接转发实现会议。
优点
- 实现逻辑清晰
缺点
- 单个终端进入多个会议上行流量较大
会议(Mediasoup代理Router)
会议使用Mediasoup实现,每个终端对应一个代理Router,通过PipeTransport转发代理Router媒体实现会议。
优点
- 终端只会存在一路上行流量
缺点
- 实现逻辑复杂
- 服务端压力较大(媒体通道生产者消费者数量增加)
子网媒体转发
多个子网不能互通时解决方案
监控
如果只有两个子网可以直接通过TURN服务实现,如果超过两个子网需要TURN服务和防火墙自动转发实现。
会议
如果只有两个子网可以直接通过IP地址重写实现,如果超过两个子网可以通过IP地址重写和防火墙自动转发实现,参考方案拓扑网络
多级平台
信令服务支持下挂多个媒体服务,但是信令服务本身不具备分布式集群功能,如需实现给出以下两种实现建议:
信令分区
将信令服务进行分区管理,分区不要直接管理终端,优先选择分区,然后选择信令服务。
代理终端
将下级信令服务的终端全部使用代理终端注册到上级信令服务,上级信令服务代理终端处理信令时直接路由到下级路由服务,这样一级一级路由直到发送给真正的终端为止。
重连
信令重连
所有终端信令默认支持重连
媒体重连
信令没有断开媒体重连依赖具体协议支持,如果信令断开默认关闭所有媒体,信令重连以后需要自己实现媒体重连(控制方主动邀请或者重连方主动进入)。