107 lines
2.8 KiB
Markdown
107 lines
2.8 KiB
Markdown
# 整体设计
|
||
|
||
## 设计
|
||
|
||
项目当前采用方案：
|
||
|
||
* 监控（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`地址重写和防火墙自动转发实现，参考方案[拓扑网络](./NetworkTopology.md)
|
||
|
||
## 多级平台
|
||
|
||
信令服务支持下挂多个媒体服务，但是信令服务本身不具备分布式集群功能，如需实现给出以下两种实现建议：
|
||
|
||
### 信令分区
|
||
|
||
将信令服务进行分区管理，分区不要直接管理终端，优先选择分区，然后选择信令服务。
|
||
|
||
### 代理终端
|
||
|
||
将下级信令服务的终端全部使用代理终端注册到上级信令服务，上级信令服务代理终端处理信令时直接路由到下级路由服务，这样一级一级路由直到发送给真正的终端为止。
|
||
|
||
## 重连
|
||
|
||
### 信令重连
|
||
|
||
所有终端信令默认支持重连
|
||
|
||
### 媒体重连
|
||
|
||
信令没有断开媒体重连依赖具体协议支持，如果信令断开默认关闭所有媒体，信令重连以后需要自己实现媒体重连（控制方主动邀请或者重连方主动进入）。
|