关于视频会议系统（WebRTC）的反思

转载请注明出处：https://blog.csdn.net/impingo
项目官网：https://pingos.io
项目地址：https://github.com/im-pingo/pingos

误区？究竟什么是信令，什么是事件

虽然本人做流媒体研发有些年头了，但是以往所用的流媒体协议都是rtmp、hls、http-flv、http-fmp4等等比较“单纯”的流媒体协议。在接触WebRTC协议的初期，甚至看到网上一些架构方案的时候都习惯把信令和媒体混在一起，不管是逻辑上或是物理部署上。就像下图：

在这张图上offer、answer等等这类用来传输媒体参数的消息和“流通知”、“用户上线通知”、“呼叫通知”等等消息并列都由所谓的“信令服务器”分发，并且在协议的设计上也是同一类型的消息（最初我也是这么做的）。
与此同时“信令服务器”还要负责维护进出房间的逻辑，负责选择后台媒体服务器（类似选点），如果考虑跨节点回源的情况，问题会更复杂。
但是我个人认为这种将所有业务都砸在信令服务器的思路是极其错误的。

思考一：怎样划分消息类别

列举几个常见的消息

媒体信令（signal）	事件消息（event）
offer/answer	新用户加入/退出
candidate/ready	新流发布/取消
pause/stop	退出房间

第一种消息类型是媒体信令消息（我们姑且叫它们 signal），这种消息传递的是与媒体参数有关的内容，在webrtc里如offer/answer/candidate/ready等等，它们是WebRTC协议的一部分，就如同rtmp协议中的handshake/connection/play等，再如rtsp协议中的setup、play等信令一样是与媒体流不可拆分的整体。

第二种消息类型是事件消息（我们姑且叫它们 event），这种消息传递的是与媒体无关的内容，如“上下线”、“流发布成功”、“流移除”等等，这些消息并不是webrtc建连所必须的，而是客户端之间发布和订阅的消息，它们和webrtc毫无关系。

那么为什么还是在很多新人的方案或者认知里总是把它们放在一起？我觉得是因为rtmp、hls等协议有比较完善的标准，它们的握手、控制等信令都是和媒体传输严格绑定的。另外它们都是单TCP链接，信令和媒体在连接上是无法分开的。而webrtc则不同，控制信令部分没有标准，就连信令连接都是和媒体连接独立的，这就造成了一种错觉，“既然webrtc signal是长连接，event也是长连接，那么他们应该就是同样的东西，放在一起实现有何不可？”这样的思想容易让人把signal和event放在一起实现，从而导致信令服务器的角色定位混乱。其实webrtc这样的协议并不特殊，完全可以把它看做一个另类的rtsp协议，同样是信令和媒体数据分开传输，为什么大家不会把rtsp的信令和上下线业务混在一起？原因就像上面说到的，因为rtsp协议完善并且有成熟的库可调用，在rtsp库的调用者看来它和rtmp一样不能拆分。然而到了webrtc协议，大家的思路就开始发散了，signal和event完全混在了一起。

综上这两种消息应该要严格区分的，不管是逻辑上的耦合还是代码上的耦合亦或是物理上服务实例的部署耦合都是原罪。
说得更极端一点：这两种消息最好连监听同一个端口这种事情都不要做，因为它们真的天上地下，毫无关系。（这里并不是完全反对使用同一个端口，只是为了表达一下它们毫无关系的程度。）

思考二：怎样理解信令服务器

信令是媒体服务器必不可少的一部分，但它不是IM服务器，它没有分发消息的责任，应该与IM服务器严格区分。

上文图中的信令服务器至少具有：WebRTC信令能力、IM能力（event转发/文字消息转发）、服务器调度能力。
但是我们已经对消息进行了分类，既然职责不同，为何还要在一起？我认为应该将信令服务器的能力拆分，原来所认为的信令服务器应该对应拆分为：信令服务器、IM服务器、调度服务器三种。

由于不管是从WebRTC协议上看还是业务控制上看信令服务都是媒体服务器的一部分，不可独立。我建议让信令服务器和媒体服务器绑定，就像rtsp服务器一样，信令和媒体组合为一个整体。这时候就没有独立的信令服务器了，因为它已经被包含在了媒体服务器的实例中。

从现在开始“信令服务器”就消失了，它已经成为WebRTC媒体服务器不可拆分的一部分。下文中提到“媒体服务器”是已经集成了“信令服务器”的。

拆分后的结构是什么样子的？

此时的流程为：

1. IM系统负责即时消息和事件转发。
2. 客户端需要推拉流时由IM系统向调度服务集群请求流媒体服务器地址。
3. 客户端向媒体服务器建立信令连接和推拉流操作。
4. 媒体服务器将流状态通知给调度系统，由调度服务判断是否需要转码或存储，如果需要转码或者存储则通知转码或录制服务拉取媒体流。
5. 媒体服务器之间的回源地址由调度服务器提供，媒体服务器向调度服务器请求回源地址进行回源。

从上图可以看出此时的“调度服务”、“媒体服务”、“IM服务”已经极大地解耦，各自的系统可以相对独立地开发维护或升级。

下面聊聊设计原则

• 媒体服务：媒体服务器集成媒体信令功能，客户端推拉流功能，服务器间推拉流功能，流状态通知功能。此时的媒体服务已经成为了一个与业务完全脱离的角色，它仅仅是受调度服务摆布的提供流转发功能的木偶而已。
• IM服务：负责同步同一个房间内的所有人的信息、状态、事件等等，IM服务器已经与媒体服务完全脱离，它仅仅需要关心同一个房间内的客户端消息是否能够在房间内广播，当客户端需要推拉流的时候IM服务器从调度服务那里获取一下媒体服务器的地址，然后返回给客户端就好，剩下的事就与IM服务器无关了。
• 调度服务：负责记录流发布的信息，并且提供服务器调度查询，是否转码等相关业务的判断和触发功能。

QQ交流群：697773082

QQ交流群：697773082