聊聊 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
欢迎关注 网易云信官网

官网微信公众号：