背景
依据音视频实时通讯项目的需求，想要开发一套多人在线方便多方交流的线上会议工具。要求是音视频地延迟通讯，绘制图形，图文共享，混流录制等功能。
计划调研方向：
- 开源组件：
- SRS
- mediasoup
- 服务平台sdk:
- aliyun - dingrtc
结构简述
服务端主要，以流中转服务配合信令服务，组合为服务端。
- 信令服务：主要用于传输消息，同步信息等等。
- 流中转服务：主要用于接收和转发多媒体数据流。
客户端主要部分，常规的http/ws服务，以及系列hook函数。
- http: 常规http请求，用于作为的基础信息通讯服务。
- ws: 信令服务客户端接口，与服务端信令服务进行通讯。
- upd: 多媒体等信息的数据传输服务。
开源组件的使用
- SRS
一套简易的高性能多媒体实时通信服务。其自身是一套完善的流中转服务，提供丰富的协议支持，以及功能。
我们使用java服务器作为管理方与信令服务，以下是一套基础流程：
- vhost用于设置srs服务的独立服务模块，主要用于提供差异性的，服务模块。
- srs以app + streamId为流标识信息，app主要说明当前流所归于的大类，streamId这表示app类下的具体stream。所以此处用java服务来具体的记录当前用户的详细信息。
- srs本身没有信令服务，所以需要java服务构建信令服务进行配合，如上图之中的notify，通过java服务器进行通知。
- Mediasoup
相比于srs的整套服务的特点，mediasoup的集成方式，则是提供了一个依赖包，api的形式加入到项目的开发之中。当然本身是也是不具备的信令服务。官网的DEMO里推荐我们使用protoo.js来开发，其与mediasoup更为匹配。
我们使用nodejs服务作为管理方，以下是一套基础流程：
- mediasoup针对频道（router）有更为清晰一些划分，同时针对的频道下连接以及传输通道管理起来更为的明确。
- protoo.js以及protoo-client.js同步适配mediasoup以及mediasoup-client.js
两者的比较：
- 想要更快的开始使用的话，srs无疑是一个很好的选择。
- 如果想要更为明确白盒管理你的逻辑，mediasoup是更清晰的一个选择。
服务平台SDK
- aliyun-dingrtc:
阿里云的服务无疑是全面的(当然收费标准也是真的复杂。这里也不得不吐槽一下文档，真的很简洁)。平台支持全面，是一套相对成熟的解决方案。
可以很良好的支持高效率实时的多媒体通讯，同时也可以支持云录制，录制能力也比较良好，但是需要接入阿里云的oss bucket，所以是另外一笔花销。
dingrtc还提供了whiteboard组件的接入，和rtm会话的接入，可以用来线上的实时交流，体验下来还是很不错的。
总体是一个相对稍贵的，但是完整的一整套可行内容。
