为了让初学者快速起步把 WebRTC demo 跑起来，我写了一个极其简单的 startup demo 项目，展示了如何基于 WebRTC API 实现一对一的视频通话。
该项目地址：Jhuster/RTCStartupDemo
本文则更近一步，主要介绍如何从一对一通话升级到多人通话，即视频会议，其中涉及到如下几个问题：
1. 多人会议，每个 Client 是创建多个 PeerConnection 还是只有一个 PeerConnection ？
2. 多人会议，谁来发起 OFFER，谁来作为 ANSWER，如何把多个 Client 相互间的连接分别建立起来 ？
首先，我们用下面这一张图来看看两个 WebRTC Peer 之间是如何建立一对一通话链路的：
在一对一通话场景中，每个 Client 均创建有一个 PeerConnection 对象，由一方主动发 OFFER SDP，另一方则应答 ANSWER SDP，最后双方交换 ICE Candidate 从而完成通话链路的建立。
如果要再加入一个人，其实也是一样的流程，假设新加入的人是 C，那么，只需要 C 分别跟 A 和 B 交换 SDP 和 Candidate 即可建立新的通话链路。C 加入后，谁来主动发送 OFFER 呢 ？常用的策略有 2 种：
1. 每当有新的成员加入到房间后，房间内的每个人主动给新成员发 OFFER，并等待他回复 ANSWER 建立新的 PeerConnection 连接
2. 每当有新的成员加入到房间后，新成员主动给房间的每个人发 OFFER，并等待 ANSWER 建立新的 PeerConnection 连接
当然，还有其他的策略，无非就是谁主动扮演 OFFER 发起者的角色触发整个建联过程而已。
如图所示，3 人会议，则每个人都会创建 2 个 PeerConnection 分别与其他两个人建立通话连接。
我这里实现了一套 Web 端 3 人连麦会议的 demo 代码，完整地复现了上述场景和逻辑，大家有兴趣可以看一看：
本文一直描述的是通过多 PeerConnection 的方案来实现多人会议，那么，是否也可以仅仅使用单个 PeerConnection 呢 ？答案是肯定的，不过这需要服务器端的参与，让多路流通过一个 PeerConnection 连接端口进行传输，到端上再利用 ssrc 等信息提取和分离出来，整体来说要复杂很多，但是也是有不少好处的。
有一篇文章关于单 PeerConnection 和多 PeerConnection 的优劣分析，有兴趣的小伙伴可以看看，链接如下：
《WebRTC RTCPeerConnection. One to rule them all, or one per stream?》
简单来说，多 PeerConnection 会导致连接到 SFU 服务器的连接数量超多，对服务端的压力是比较大的；另外，多 PeerConnection 也比单 PeerConnection 要消耗更多的资源。而单 PeerConnection 虽然整个逻辑复杂，但是在上述这两点上还是有一些不错的优化的。
关于 WebRTC 如何从一对一通话到多人会议，就分享到这里了，如有疑问的小伙伴欢迎来信 lujun.hust@gmail.com 交流。另外，也欢迎大家关注我的新浪微博 @卢_俊或者 微信公众号 @Jhuster 获取最新的文章和资讯。