一、Mesh架构

WebRTC（Web Real-Time Communications）中的Mesh架构是一种将多个终端之间两两进行连接，形成网状结构的通信模式。以下是关于WebRTC的Mesh架构的详细解释：

1. 基本概念：在Mesh架构中，每个参与者（或称为peer）都需要与其他所有参与者建立直接的媒体连接。例如，如果有A、B、C、D四个参与者，那么A需要分别与B、C、D建立连接，B也需要分别与A、C、D建立连接，以此类推。
2. 带宽需求：在Mesh架构中，每个参与者都需要将自己的音视频流发送给其他所有参与者，同时也需要从其他参与者那里接收音视频流。因此，对于每个参与者来说，带宽需求会随着参与者数量的增加而线性增长。例如，如果每个音视频流占用1M带宽，那么每个参与者需要向其他三个参与者发送数据，总共需要3M上行带宽，同时从其他三个参与者接收数据，也需要3M下行带宽，即每个参与者总共需要6M上下行带宽。
3. 优点：Mesh架构不需要服务器中转数据，充分利用了客户端的带宽资源，节省了服务器资源。此外，由于所有参与者都直接相连，因此网络延迟较低，实时性较好。
4. 缺点：Mesh架构的缺点主要在于带宽消耗和客户端资源占用。由于每个参与者都需要与其他所有参与者建立连接，因此带宽消耗会随着参与者数量的增加而急剧增长。此外，为了建立和管理这些连接，客户端也需要消耗大量的系统资源。另外，由于要向其他所有参与者发送数据，因此在同等带宽条件下，支持的多人通话路数就相对有限，视频质量（码率）也比较低。
5. 适用场景：Mesh架构比较适合网络状况较好、人数较少（如3-4人）的小型会议场景。在大型会议或网络状况较差的情况下，可能需要考虑其他架构（如MCU或SFU）来优化性能和带宽使用。

总的来说，WebRTC的Mesh架构是一种直接、简单的通信模式，适用于小型、实时性要求较高的场景。但在大型会议或网络状况较差的情况下，可能需要考虑其他更复杂的架构来优化性能和带宽使用。

二、设计

如果你已经能熟练掌握1V1通话（http://t.csdnimg.cn/P8n3x），那么设计Mesh构架的多人通话将十分简单。下面我将逐步分析多人通话的整个“握手”过程。

以A、B、C、D四人通话为例。

1. A发起offer，A、B、C、D分别创建3个RTCPeerConnection实例，A分别与B、C、D协商，协商成功后A页面有1个localVideo与3个remoteVideo，实现多人通话。
2. A发起offer后，B、C、D仅与A协商，B、C、D页面分别有1个localVideo与1个remoteVideo，仅仅实现了单人通话。
3. A发起offer后，B发起offer，A与B已经通话跳过协商，B与C、D协商，此时B页面有1个localVideo与3个remoteVideo，实现多人通话。
4. A发起offer后，B发起offer后，C、D分别有1个localVideo与2个remoteVideo，未实现与所有人通话。
5. A发起offer后，B发起offer后，C（或D）发起offer，C跳过已经建立的A、B协商，仅仅与D协商，最终A、B、C、D都实现了对话房间的所有人通话。

以上过程4个用户供发起了3次（n-1）次offer，共协商了6次（n*(n-1)/2）。

三、实现

1. 根据对话房间人数动态创建RTCPeerConnection实例与remoteVideo。
2. 对端用户ID分别与RTCPeerConnection、remoteVideo建立映射。
3. 信令服务器跳过已经建立通话的offer。

多人通话效果见下图：

需要源码与教学的请私信我(*￣︶￣)