Janus网关的集成与优化( 二 ) _Janus网关

右边的浏览器在接收到SDP offer工作请求以后，会根据自己所支持的编码器情况进行匹配和筛选，然后生成SDP answer作为响应，通过信令服务器中转返回给左边的浏览器，这样双方就完成了SDP的协商和交换。
在交换了SDP之后, 双方通信需要的信息都完备了. 随后这两个浏览器会分别初始化好各自的音视频设备，比如麦克风、摄像头设备。然后根据协商好的编解码, 初始化编解码器. 于此同时，它们会向对方发送ICE建立请求的消息，该消息会带上双方协商好的ICE参数，主要是携带用户名和密码的信息(后面的单端口改造借助了这里的用户名字段) 。在完成ICE的请求交换后进行握手认证，这样就建立起了ICE的连接，双方随后以P2P的方式通过ICE连接发送编码后的媒体数据。
直接将媒体数据发送给对方的这种形式被称之为P2P直连，这种方式看似很好，因为它中间不需要经过服务器，但在一些情况下会有问题。

文章插图

首先，一般的设备都没有公网IP地址，在访问外网时需要经过路由器，路由器上的NAT转换会分配相应的外网地址，再进行设备到外网的访问工作. 这时路由器上的NAT策略直接影响到ICE连接是否能够建立起来。整个过程涉及到UDP穿透问题，比如在对称型、限制型锥形NAT上，穿透是很难完成的。
其次，在P2P直连的方式下，中间链路我们无法控制，因此传输质量难以保证。假设图中这两台电脑，一个位于电信，一个位于网通，即使它们能够完成UDP的穿透，它们之间的传输延迟大概率也是很高的。
最后，因为数据不经过服务器，行为监管和媒体录制都难以实现,, 尤其对教育行业来讲，行为监管这块是一个必不可少的需求。
2.2 WebRTC网关架构

文章插图

这是WebRTC网关的架构图。通常情况下我们将WebRTC网关部署到外网，这两个浏览器分别通过NAT连接到网关，并通过网关来转发相应的媒体数据。网关上的WebRTC logo表示在网关上实现了WebRTC模块的功能. 因此它可以和浏览器上的WebRTC模块进行通信。浏览器和WebRTC网关之间的红色箭头表示信令消息的交互，绿色箭头表示媒体消息。
下面来看看关于上个小节中的几个问题在WebRTC网关上是如何解决的。
首先穿透问题，因为WebRTC网关是部署到外网的，浏览器通过内网去访问外网. 只要能够正常上网，访问外网是没有问题的，因此不会有穿透失败的问题, 同时也可以省去STUN服务.
其次是联通到电信的情况，可以把WebRTC网关部署到BGP的多线机房, 电信和联通到BGP的延迟可以做到很低，通过一个中转，整体的中转质量反而比P2P直连质量更好。
最后是监管和录制，因为媒体数据会经过WebRTC网关，可以方便地在网关上进行录制，同时也可以在网关上针对媒体内容进行相应的数据分析，实现对其监管的功能。
在讨论WebRTC网关时，一般会根据网关对媒体消息的处理方式划分为两类：SFU和MCU 。

文章插图

SFU在收到媒体数据以后，不会对媒体数据本身进行处理，只做一些基本处理(SSRC, timestamp等转换)和转发。左图是SFU的示意图，不同颜色所表示的媒体数据在进入SFU之后，它是以原来的形态发送到其他浏览器上的。
右图是MCU的示意图，媒体数据在进入MCU以后，MCU会对媒体内容进行深度处理，比如把多路的声音合并成一路或者把多路的头像合并成一个大头像，再根据需要做转码，并转发到其他浏览器上。合流的一个好处是可以节省相应的带宽，同时可以在发送媒体数据的时候, 根据浏览器所支持的编解码情况进行转码，因此它的适应性会比较好。
2.3 Janus网关

文章插图

Janus网关是SFU. 它是用C语言来实现的。其次, 在Janus上，业务模块以插件的形式实现，部署是以SO动态库的形式进行部署的，所以它的主程序和插件开发是一个分离的方式。最后，Janus Demo非常简单直观，很容易上手。
接下来这部分介绍Janus网关的软件架构。从层级上分析，Janus网关主要分为三层，从上至下分别是插件层、核心层和传输层。

文章插图

插件层主要是决定SFU的转发逻辑，比如决定转发给房间里面的所有人，还是只转发给其中的一部分人，是转发音频或者视频，还是音视频同时转发。一个完整的插件方案，除了Janus网关服务器上的插件实现之外，还包括浏览器上的JS SDK 。JS SDK处理的逻辑主要包括进出房间、订阅相应的媒体流等. 除此之外, 调用WebRTC的API获取麦克风和摄像头的数据，还有播放音频和视频数据，都是通过JS SDK来完成的。