众所周知，WebRTC非常适合点对点（即一对一）的音视频会话。然而，当我们的客户要求超越一对一，即一对多、多对一设置多对多的解决方案或者服务，那么问题就来了：“我们应该采用什么样的架构？” 。简单的呢有人会考虑copy多个p2p就完成了多人之间的会话，可并没有考虑到到来的问题：cpu、内存、尤其是流量问题；传统的解决方案是MCU服务器，利用服务器硬件的能力去mix音视频，然后传给各个参与者，这能到达预想的，这个亦能到达我们的需求；使用基于网状拓扑结构的结构可能是前两者的折中之选。

尽管能实现WebRTC多人音视频的方案，该技术的最流行的用途不局限于多方视频会议场景。不要以为只是传统的音视频会议室，更多的情况包括：智能硬件、ipcamera、在线课堂，实时直播等。在每一种情况下，服务器的能力是能够从多个源的媒体流分发到多个客户端。所以...如果你是一个服务供应商如何才能在实现支持WebRTC的多方拓扑结构？

有几种不同的架构根据您的要求，可能是合适的。这些架构基本上他们围绕二点：

§ 集中VS对等网络（P2P）

§ 混合VS路由。

我将在这里介绍最流行的解决方案。如果你需要去深入到协议的影响和实施细则的架构，你可以找到所有的相关信息，RTP拓扑IETF文档。

Mesh解决方案

Mesh方法是最简单的解决方案。因为它不需要假设任何服务器，而且直接使用成熟的WebRTC传输方案。该体系结构基于从每一个发送者创建多个一对一的数据流到每一个接收端。

即使它看起来像一个低效的解决方案，在实践中是非常有效的，并且延迟最低，每个接收端都会根据实际情况产生不同的比特率。

唯一的问题是，这种解决方案需要大量的上行带宽将媒体流同时发送至所有目的地，现有的设备实现所需的CPU功率会显著上升。

Mixer解决方案

Mixer的做法是多人视频会议的传统解决方案，并且使用多年取得了巨大成功。这一成功可以归功于它需要客户端更少消耗这一事实。该架构基于具有中心点保持与每个参与者一对一的流的特性。中心元件接收并混合每个传入的音频流和视频流，以合成一个单一的流出到每一个参加者。在视频会议行业对于这些集中元件的一个常见术语是多点控制单元（MCU）。在实践中，使用一个MCU的通常是指一个混合器容器。

混频器是供传统设备操作间很好的解决方案。它们还允许全位速率适配，因为混频器可以产生不同的输出流，所以每个接收器有不同的品质。混合器解决方案的另一个优点是它可以利用硬件设备编解码。

主要缺点是在MCU的基础设施成本高。此外，由于混合需要解码和再编码，这引入额外的延迟和质量的损失。最后，转码和组合物可在理论上导致对应用程序的用户界面的弹性较小（尽管有此问题的解决方法）。

Router解决方案

Router（或中继）的办法使得H.264 SVC基础设施普及，这也正是广泛应用的。该架构基于具有中心点从每个发送器接收一个流并发送出一个流到每一个参与者。这个中心点只做数据包检测和转发，而不是昂贵的编码和实际的媒体的解码。常见术语是SFU。

Router提供一个便宜的可扩展的多方传输，具有较好的延迟性、与传统的mixer解决方案相比没有质量劣化。

这种方案非常适合大并发的事实会议和直播。目前较成熟的服务提供商就是声网

来一张各个解决方案的流量图？

我应该使用哪种架构？

这个就需要根据自己的项目的需要了。其实，商业解决方案，包括上述所有方案，往往需要根据客户的实际应用场景选择对于的方法。不过，也有经验，你可以使用一些通用规则。

1、如果您仅是提供P2P音视频传输的服务，Mesh架构可能是最适合你的。另外，如果基础设施的成本不是问题，并且参与者具有异构连接，这可以是一个很好的解决方案。

2、假设你提供企业级服务，且有较好的宽带和高效的硬件（即一个企业内部服务），参加人数是有限的，那么你非常适合Mixer方案。

3、一般来说，如果你提供大规模服务的，应优先考虑到Router的方法。Router传输接近把情报在网络的边界，构建最终用户应用程序时，以达到更好的可扩展性和灵活性的网络的范例。

更多linux后台服务器开发免费视频资料获取 后台私信【架构】

详情Linux后台服务器开发大纲

更多音视频免费视频资料获取 后台私信【音视频】

本人成功自研一个音视频多人通话实战项目 需要可以私信我