《聊聊 WebRTC 网关服务器》系列文章系由 WebRTCon2018 中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易 NRTC 在 WebRTC 网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。 《聊聊WebRTC网关服务器》第二篇文章将和大家分享如何选择PeerConnection方案。
在会议场景下，网易 NRTC 的 WebRTC 网关使用的是 SFU 方案，如上图举例所示，每个 WebRTC 上行一路媒体数据到 WebRTC 网关服务器，同时还需要从网关接收下行的三路媒体数据，对于一个 WebRTC 客户端来说就有多路流。对于这种多流的场景，我们有两种 PeerConnection 方案可以使用：
- 单个PeerConnection里有多个 media stream (bundle)；
- 为不同的 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 有什么优势呢？
- Server端媒体处理代码相对简单；
- 服务端性能较好，只需要建立一个PeerConnection连接，DTLS握手只需要做一次。
单 PeerConnection 又有什么劣势？
- 服务器需要编写兼容不同浏览器的代码；
- 不同用户的下行媒体流过多后，SDP 里面 m 行或 a 很多，导致 SDP 长度过长；特别是当用户频繁进出或者媒体状态发生改变时，SDP 需要进行频繁 Update， SDP 传输耗费的带宽就会很多；
- 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 官方博客以及微信公众号：**
关注更多技术干货内容： 欢迎关注 欢迎关注官网微信公众号：
