聊聊 WebRTC 网关服务器 2：如何选择 PeerConnection 方案？

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

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

1. 单个PeerConnection里有多个 media stream (bundle)；
2. 为不同的 media stream 创建不同的 PeerConnection。

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

首先我们来看看单 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。

而相对单 PeerConnection，多 PeerConnection 的方案就比较便于理解了，如图 A/B/C/D 四个人的会，对于 A 来说有一个上行的 PeerConnection，以及 3 个下行的 PeerConnection对应 B/C/D。每一个用户的上下行数据都是分开的，这个也是WebRTC比较推荐的方案。
这个方案主要的难点是服务端要去维护每个用户的上下行 PeerConnection 对应关系，整体的代码逻辑较复杂。但是它的兼容性比较好。所以 NRTC 的 WebRTC 网关最终选择了多 PeerConnection 方案。

在分享完 PeerConnecton 的方案后，下面就进入 Server 的线程方案的选择和优化。这个也是网关服务器架构设计的核心部分。

《聊聊 WebRTC 网关服务器》第三篇文章将具体为大家介绍如何优化 Server 的线程方案。

---

随着音频处理和压缩技术的不断发展，效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现，如果你有好的技术或者分享，欢迎关注网易 MC 官方博客以及微信公众号：**

关注更多技术干货内容：网易云信博客
欢迎关注网易云信 GitHub
欢迎关注网易云信官网

官网微信公众号：