webrtc流媒体转发服务器

定义

由于webrtc是基于P2P技术的一个协议栈，大多数情况下能满足1-5人的同时并发音视频通讯。但是对于多于5人乃至10、20人的并发，使用P2P技术会造成终端设备无法承受负荷。因此需要将P2P模式改造成能适应大量并发模式，即媒体转发服务（MCU）。

难点

由于webrtc本身是基于P2P的技术，没有MCU的实现。因此需要自己编写MCU的源码。难点有如下几个：

1. 如何与终端设备建立连接
2. 如何接收和转发媒体流
3. 转发如何高效，尽量少的延时
4. 转发后如何保证视频质量
   这几点前两点是核心技术问题，如果突破不了则无法实现MCU转发。后两点是如何提高品质的问题，但是品质决定了该技术的可行性。如果视频品质比P2P下差太多，也无实际意义。

建立连接

如何与终端设备建立连接的技术是直接关系到MCU端是否能正常运行的核心技术，为了能使终端设备和MCU的连接简单化，我们把MCU也想象成是一个PEER，那么换言之，MCU只需要完全遵循webrtc的P2P连接过程即可。那么按照此观点，我们需要在MCU服务器端引入webrtc协议栈来进行连接。但是注意，webrtc流媒体连接与转发都是在协议栈内部完成，也就是说我们没法从webrtc的外部接口直接拿到媒体流数据，拿不到媒体流数据也就意味着我们没法做自定义转发。因此该方案被否决。
那么如何能完全模拟webrtc的连接过程同时又能拿到终端媒体流数据呢？那么我们需要去了解webrtc的连接过程。
webrtc是依照叫PeerConnection的连接过程，其连接过程需要四个角色来合作完成，即：

1. 终端设备A
2. 终端设备B
3. STUN服务器：用于解析终端设备的外部Internet IP，通常部署在云端，需要在设备A和B的交换明文SDP中指定。
4. Signal服务器：用于在终端设备A和B之间交换连接信息，所有终端设备需要与该服务器保持连接。
   一个经典的连接过程包括以下步骤
   a. 设备A发送一条SDP消息给Signal服务器，该消息包含需要与设备B进行连接的有效信息即SDP，以及终端设备B的IP地址，表明设备A需要和设备B进行通信
   b. Signal服务器设备A发送的SDP信息转发给设备B
   c. 设备B将自己的SDP信息发送给服务器，服务器同时转发给设备A
   d. 设备A和设备B通过双方SDP中包含的局域网IP、公网IP以及有效端口，选择一条有效路由进行连接
   e. 连接成功后设备A和设备B交换媒体流。
   基于以上过程，我们不难发现该连接过程是一个经典的P2P连接过程，我们不需要通过webrtc协议栈来完成。通过其他用于P2P连接的协议栈即可完成这个过程。经过实验我们发现NICE库是一个小巧、高效的P2P连接库。但是其实现是基于linux内核编写。也就是说我们必须选用linux做MCU服务器。
   NICE库能够完成主叫或被叫的P2P连接过程，但是由于它不处理跟媒体设备相关事宜，而SDP文本中需要包含设备相关信息，因此在MCU端需要自行生成SDP以备和终端设备进行交换。这个SDP生成过程需要去理解SDP文本，并仿造终端设备发送过来的SDP文本格式自行生成。经过实验，在完成SDP文本中关键几个字段的替换（将设备端SDP关键信息替换成MCU端），终于能够正常连接了。

如何转发媒体流

由于NICE库在建立起PeerConnection连接的前提下，可以直接拿到媒体数据，因此接收和转发媒体流相对来说就简单了。
接收数据可以直接从NICE的接口callback得到
转发无非是MCU与多个设备终端同时建立连接，然后通过NICE接口将数据通过转发端的连接发送过去。
由于P2P技术是端对端，只考虑2个设备间的连接，不存在连接管理问题。但是在会议模式下，就要考虑连接管理问题了。因为会议模式下是1+N的连接模式。因此我们引进了一个经典的会议概念，其中有如下几条关键概念：

1. 会议：一个会议包括一个会议ID，以及其下属的多个终端设备或者叫与会者（与会者ID）。
2. 发布：该会议中的其中一个与会者发布自己的媒体流到MCU服务器
3. 订阅：会议中除了发布者外，其他与会者订阅该发布者的媒体流。
   按照以上概念，视讯会议就可以简单理解为以下过程
   a. 创建会议
   b. 进入会议，即所有与会人与Signal服务器建立连接
   c. 发布媒体流
   d. 订阅媒体流

如何高效转发媒体流

由于P2P连接下，媒体流是直接从终端设备A发送到终端设备B，没有中间过程。在MCU模式下，需要MCU进行中转，因此实时性一定不如P2P。针对该课题，我们需要定义可接受的延时标准，同时在MCU端需要尽量减少程序架构带来的额外延时，亦即我们需要引入高性能服务器编程，来保证高并发、高实时。因此我们引入了连接池、线程池和内存池三项技术。通过测试发现同样的网络环境下，设备A和设备B在P2P和MCU下延时的差别在30%左右，在可接受范围内。

转发后如何保证视频质量

由于webrtc在视频品质控制方面有一套自己的技术，来应对在Internet复杂网络环境下保证传输音视频质量。但是MCU转发服务器模式下，没法直接打通端对端的连接，该机制无法起到作用。如果不在MCU端加入该套机制，在Internet下的音视频品质会大打折扣。因此需要去理解webrtc的流媒体控制机制。
经过查阅资料发现，webrtc主要通过以下三项控制指令来完成品质控制

1. 关键帧请求：主要包括SLI／PLI／FIR，作用是在关键帧丢失无法解码时，请求发送方重新生成并发送一个关键帧。
2. 重传请求：主要包括RTX／NACK／RPSI。这个重传跟关键帧请求的区别是它可以要求任意帧进行重传
3. 码率控制：主要包括REMB／TMMBR／TMMBN。TMMBR是Temporal Max Media Bitrate Request，表示临时最大码率请求。表明接收端当前带宽受限，告诉发送端控制码率。
   另外，除了关键帧请求和重传，Webrtc还支持RED／FEC等冗余编码和前向纠错手段来保证视频质量，后续有空了再写。
   通过上述介绍大家了解到有三种类型的控制包，只需要将这三种包接收到并转发给对应的连接，MCU端即可兼容webrtc媒体控制技术。通过实验发现该策略是有效的，并且主要是PLI、FIR、RTX三种对品质影响最大。