聊聊WebRTC网关服务器2:如何选择PeerConnection方案?

最新文章 6834℃

《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成,该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题,以及我们最终的解决方法。

 

《聊聊WebRTC网关服务器》第二篇文章将和大家分享如何选择PeerConnection方案。

1

在会议场景下,网易NRTC的WebRTC网关使用的是SFU方案,如上图举例所示,每个WebRTC上行一路媒体数据到WebRTC网关服务器,同时还需要从网关接收下行的三路媒体数据,对于一个WebRTC客户端来说就有多路流。对于这种多流的场景,我们有两种PeerConnection方案可以使用:

1)单个PeerConnection里有多个media stream(bundle);

2)为不同的media stream创建不同的PeerConnection。

那我们如何选择PeerConnection的方案呢?

2

首先我们来看看单PeerConnection方案,所有的客户端和服务器之间只需要建立一个PeerConnection,这个PeerConnection是一个双向的PeerConnection,它既可以发数据,也可以收数据,这个方案简单明了,实现时候要注意一个问题,就是Chrome和Firefox在实现单PeerConnection bundle时采用的SDP方案是不一样的。Chrome是用了Plan B的方案,Firefox是用了Unified Plan的方案。当然Chrome未来即将支持Unified Plan,而当前要使用单PeerConnection方案就必须在Server端编写兼容代码。PlanB采用的是一个m行,多个a行来描述多流,而Unified Plan是多个m行,描述多流,具体的做法RFC草案文档里面有详细描述,我这里就不赘述了。

那么单PeerConnection有什么优势呢?

1)Server端媒体处理代码相对简单;

2)服务端性能较好,只需要建立一个PeerConnection连接,DTLS握手只需要做一次。单PeerConnection又有什么劣势?

1)服务器需要编写兼容不同浏览器的代码;

2)不同用户的下行媒体流过多后,SDP里面m行或a很多,导致SDP长度过长;特别是当用户频繁进出或者媒体状态发生改变时,SDP需要进行频繁Update, SDP传输耗费的带宽就会很多;

3)Firefox Unified Plan在多人场景下,较高的概率下会出现崩溃Bug,我们已经向Firefox提交了bug。

3

而相对单PeerConnection,多PeerConnection的方案就比较便于理解了,如图A/B/C/D四个人的会,对于A来说有一个上行的PeerConnection,以及3个下行的 PeerConnection对应B/C/D。每一个用户的上下行数据都是分开的,这个也是WebRTC比较推荐的方案。

这个方案主要的难点是服务端要去维护每个用户的上下行PeerConnection对应关系,整体的代码逻辑较复杂。但是它的兼容性比较好。所以NRTC的WebRTC网关最终选择了多PeerConnection方案。

 

在分享完PeerConnecton的方案后,下面就进入Server的线程方案的选择和优化。这个也是网关服务器架构设计的核心部分。《聊聊WebRTC网关服务器》第三篇文章将具体为大家介绍如何优化Server的线程方案。