iOS WebRTC 杂谈之 Kurento

关于使用WebRTC来做视频会议，我们还是从三种架构说起：

三种架构.png

图中〇代表客户端，▉表示服务器。

第一种是我们最常见的P2P模式，也叫做mesh，是一个网状对等网络，当房间中有n个人时，需要建立n*(n-1)个连接，也就是房间里每个人都要与其他所有人建立一个对等连接来进行数据通讯。因为其不需要服务器，所以所需投入最低，正因如此，每个终端对编解码和网络的压力就会非常大，因此，也就决定了mesh模型下房间中的人数n不会太大，这是P2P无法逾越的鸿壑。一般来说，P2P模式下，10人可以算是一个临界点，甚至在一些性能较差的移动端，5人就已经比较勉强了。

第二种是SFU（Selective Forwarding Unit），选择性转发模式中，需要一个中间服务器，这个服务器只做音视频数据的接收与转发，不进行解码或者重新编码，因此对服务器的压力比较小。发布客户端将音视频流发送到中央Server上，然后由server分发到各个订阅端，因此，相比于mesh，对发布端的上行带宽的压力也降低了太多。SFU典型的应用场景是多人音视频会议。目前国内做的比较领先的声网就是采用的这种架构。

第三种是MCU（Multi-point Control Unit），多点控制单元同样采用中间服务器进行转发，但服务器会对所接收到的流进行混合处理，合成一路视频流，发给订阅端。因而每个客户端只需要一路上行流和一路下行流就可以了，这大大缓解了客户端的压力，对于因设备原因受限的情况非常有用。

除了Mesh是采用P2P（peer-to-peer），SFU和MCU都是采用的P2S（peer-to-server）。虽然最初WebRTC被定义为P2技术，但现实中的很多应用场景使得P2S的作用越来越明显。

我们今天要说的Kurento架构的解决方案就是基于SFU的。客户端与Kurento Media Server（KMS）建立peerConnection，所有的协商过程SDP/ICE Candindate都是发送给KMS。当连接建立后，每个客户端都将stream发送到KMS，KMS在收到流，进行混合，根据需求生成一个stream，将混合后的stream再发送到所需的客户端。同时，KMS在混合视频流时，还可以对视频流做很多操作，比如转码，切换分辨率，音视频合成等，当然还可以进行录制操作。

Kurento架构.jpg

Kurento架构中，必不可少的三部分，客户端，信令服务器和媒体服务器。客户端负责音视频数据的采集，编码，上传，通过信令服务器进行统一的分配调度，将数据传到KMS后，KMS将处理后的stream发送给订阅端。
对于Kurento的实现，nubomedia公司在GitHub开源了一个项目https://github.com/nubomediaTI/Kurento-iOS适用于iOS的Kurento Toolbox。
在KMS模式下，PeerA和PeerB进行通话的主要流程可以描述为：

流程示意图.png

这里还有一个问题。我们知道在WebRTC中，流的关系是音视频数据记录在Track中，Track封装到Stream里，然后通过PC进行发送。当PeerA要订阅房间内其他人的Stream的时候，最好的方式就是把要订阅的人的Stream都放在一个PC里，这样最大程度的减少了PC个数，当然，如果不使用端口复用的话，那就订阅了几个人，就创建几个PC，一样是可以实现的。