问题：
WebRTC为我们提供点对点视频/音频连接。它非常适合p2p通话，环聊。但是广播怎么样（一对多，例如，1到10000）？
假设我们有一个广播员“B”和两个参加者“A1”，“A2”。当然它似乎是可以解决的：我们只用B连接B，然后用A2连接B.因此B将视频/音频流直接发送到A1，将另一个流发送到A2。 B发送两次流。
现在让我们想象有10000名与会者：A1，A2，...，A10000。这意味着B必须发送10000个流。每个流约为40KB / s，这意味着B需要400MB / s的外出网速来维持这种广播。不能接受的。
原始问题（已废除）
是否有可能以某种方式解决这个问题，所以B只在某个服务器上发送一个流，而与会者只是从这个服务器中提取这个流？是的，这意味着此服务器上的传出速度必须很高，但我可以保持它。
或者这可能意味着毁掉WebRTC的想法？
笔记
根据最终客户的不良用户体验，Flash无法满足我的需求。
解决方案（不是真的）
26.05.2015 - 目前没有针对WebRTC的可扩展广播的解决方案，您根本不使用媒体服务器。市场上有服务器端解决方案以及混合（p2p +服务器端，具体取决于不同的条件）。
有一些有前途的技术，但像https://github.com/muaz-khan/WebRTC-Scalable-Broadcast，但他们需要回答这些可能的问题：延迟，整体网络连接稳定性，可扩展性公式（它们可能不是无限可扩展）。
几点建议
由于这里几乎涵盖了这一点，因此无法使用普通的，老式的WebRTC（严格的点对点）来实现您在这里所要做的。因为如前所述，WebRTC连接重新协商加密密钥以加密每个会话的数据。因此，您的广播公司（B）确实需要像参加者一样多次上传其流。
但是，有一个非常简单的解决方案，它运行得很好：我测试过它，它被称为WebRTC网关。 Janus就是一个很好的例子。它是完全开源的（github repo here）。
其工作原理如下：您的广播公司联系了WebRTC的网关（Janus）。所以有一个关键的协商：B安全地（加密流）传输给Janus。
现在，当与会者连接时，他们再次连接到Janus：WebRTC协商，安全密钥等。从现在开始，Janus将向每个与会者发回流。
这很有效，因为广播公司（B）只将其流一次上传到Janus。现在，Janus使用自己的密钥对数据进行解码，并可以访问原始数据（即RTP数据包），并可以将这些数据包发回给每个与会者（Janus负责为您加密）。由于您将Janus放在服务器上，它具有很好的上传带宽，因此您可以流式传输到许多对等端。
所以是的，它确实涉及服务器，但该服务器会说WebRTC，并且您“拥有”它：您实现Janus部分，因此您不必担心数据损坏或中间人。当然，除非您的服务器受到损害。但是你可以做很多事情。
为了向您展示使用它是多么容易，在Janus中，您可以调用一个名为incoming_rtp()（和incoming_rtcp()）的函数，它可以为您提供指向rt（c）p数据包的指针。然后，您可以将其发送给每个与会者（它们存储在Janus非常容易使用的sessions中）。 Look here for one implementation of the incoming_rtp() function，a couple of lines below你可以看到如何将数据包传输给所有与会者和here你可以看到实际的功能来中继rtp数据包。
这一切都很好，文档相当容易阅读和理解。我建议你从“回声”的例子开始，它是最简单的，你可以理解Janus的内部运作。我建议你编辑echo测试文件来制作你自己的，因为有很多冗余的代码要编写，所以你不妨从一个完整的文件开始。
玩得开心！希望我帮忙。
由于peer1只是调用getUserMedia（）的对等方，即peer1创建一个房间。
随着许多对等体彼此连接，此过程持续进行。
因此，通过这种方式，可以在无限制的用户上传输单个广播，而不会出现任何带宽/ CPU使用问题。
最后，以上所有内容均来自Link。
您正在描述使用具有一对多要求的WebRTC。 WebRTC专为点对点流媒体而设计，但有些配置可让您在向许多观众提供视频的同时，从WebRTC的低延迟中受益。
诀窍是不向每个观众征税流媒体客户端，就像你提到的那样，有一个“中继”媒体服务器。您可以自己构建，但老实说，最好的解决方案通常是使用像Wowza的WebRTC Streaming product这样的东西。
要从手机中高效流式传输，您可以使用Wowza的GoCoder SDK，但根据我的经验，像StreamGears这样的更高级的SDK效果最佳。
我正在使用Kurento Media Server开发WebRTC广播系统。 Kurento支持多种流协议，如RTSP，WebRTC，HLS。它在实时和缩放方面也很有效。
因此，Kurento不支持现在在Youtube或Twitch中使用的RTMP。我的一个问题是用户并发的数量。
希望它有所帮助。
正如@MuazKhan所说：
https://github.com/muaz-khan/WebRTC-Scalable-Broadcast
在Chrome中工作，还没有音频广播，但它似乎是第一个解决方案。
可扩展的WebRTC点对点广播演示。
该模块简单地初始化socket.io并以一种方式对其进行配置，即单个广播可以通过无限用户进行中继，而不会出现任何带宽/ CPU使用问题。一切都发生在点对点！
绝对可以完成。 其他人也能够实现这一目标：http://www.streamroot.io/
AFAIK是目前唯一相关且成熟的实施方案，是Adobe Flash Player，自10.1版以来支持p2p多播用于点对点视频广播。
互联网上无法实现“可扩展”广播，因为那里不允许进行IP UDP多播。但从理论上讲，它可以在局域网上实现。 Websockets的问题在于您无法通过设计访问RAW UDP，因此不允许这样做。 WebRTC的问题在于它的数据通道使用一种SRTP形式，其中每个会话都有自己的加密密钥。因此，除非有人“发明”或API允许在所有客户端之间共享一个会话密钥，否则多播是无用的。
有同伴辅助交付的解决方案，这意味着该方法是混合的。服务器和对等方都帮助分发资源。这就是peer5.com和peercdn.com采取的方法。
如果我们专门谈论直播，它看起来像这样：
遵循这样的模型可以节省高达服务器带宽的约90％，这取决于直播的比特率和观众的协作上行链路。
免责声明：作者正在Peer5工作
我的主人专注于使用WebRTC开发混合cdn / p2p直播流协议。我在http://bem.tv发表了我的第一个成绩
一切都是开源的，我正在寻找贡献者！ :-)
Angel Genchev的答案似乎是正确的，然而，有一种理论架构，允许通过WebRTC进行低延迟广播。想象一下B（广播公司）流到A1（与会者1）。然后A2（与会者2）连接。 A1开始将从B接收的视频流传输到A2，而不是从B流式传输到A2。如果A1断开，则A2开始从B接收。
如果没有延迟和连接超时，此架构可以工作。所以理论上它是正确的，但不是实际的。
目前我正在使用服务器端解决方案。
WebRTC可扩展解决方案市场上有一些解决方案。它们提供低延迟，可扩展的webrtc流。这是一些样本。 Janus，Jitsi，Wowza，Red5pro，Ant Media Server
我是Ant Media Server的开发人员，我们提供社区和企业版，包括android和iOS SDK。如果我们能以某种方式帮助您，请告诉我们。