由于这里几乎涵盖了所有内容，因此您在这里尝试做的事情对于普通的老式 WebRTC（严格的点对点）是不可能的。因为如前所述，WebRTC 连接会为每个会话重新协商加密密钥以加密数据。因此，您的广播公司 (B) 确实需要根据与会者的数量上传其流。

但是，有一个非常简单的解决方案，效果很好：我已经对其进行了测试，它称为 WebRTC 网关。Janus就是一个很好的例子。它是完全开源的（这里是github repo）。

其工作原理如下：您的广播公司联系说 WebRTC的网关 (Janus) 。所以有一个密钥协商：B 安全地传输（加密流）到 Janus。

现在，当与会者连接时，他们再次连接到 Janus：WebRTC 协商、安全密钥等。从现在开始，Janus 将向每个与会者发回流。

这很有效，因为广播公司 (B) 只向 Janus 上传一次其流。现在，Janus 使用自己的密钥对数据进行解码，并可以访问原始数据（即 RTP 数据包），并且可以将这些数据包发送回每个与会者（Janus 会为您进行加密）。而且由于您将 Janus 放在服务器上，它具有很大的上传带宽，因此您将能够流式传输到许多对等点。

所以是的，它确实涉及一个服务器，但该服务器使用 WebRTC，并且您“拥有”它：您实现了 Janus 部分，因此您不必担心数据损坏或中间人。当然，除非您的服务器受到威胁。但是，您可以做的事情太多了。

为了向您展示它的易用性，在 Janus 中，您有一个名为incoming_rtp()(and incoming_rtcp())的函数，您可以调用它，它为您提供一个指向 rt(c)p 数据包的指针。然后，您可以将其发送给每位与会者（它们存储在sessionsJanus 中，非常易于使用）。在这里寻找一个实现的incoming_rtp()功能，一对夫妇低于行的，你可以看到如何将数据包发送给所有与会者，并在这里你可以看到实际的功能中继的RTP包。

一切都很好，文档相当容易阅读和理解。我建议您从“echotest”示例开始，它是最简单的，您可以了解 Janus 的内部工作原理。建议你编辑一下echo test文件，制作自己的，因为有很多多余的代码要写，所以不妨从一个完整的文件开始。

玩得开心！希望我有所帮助。

正如@MuazKhan 上面提到的：

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

在 chrome 中工作，还没有音频广播，但它似乎是第一个解决方案。

可扩展的 WebRTC 点对点广播演示。

该module简单地初始化 socket.io 并以一种方式配置它，即可以在无限用户上中继单个广播，而不会出现任何带宽/CPU 使用问题。一切都是点对点发生的！

这绝对是可以完成的。
其他人也可以做到这一点：http : //www.streamroot.io/

AFAIK 目前唯一相关且成熟的实现是 Adob​​e Flash Player，它从 10.1 版开始支持对等视频广播的 p2p 多播。

http://tomkrcha.com/?p=1526。

“可扩展”广播在 Internet 上是不可能的，因为那里不允许 IP UDP 多播。但理论上在局域网上是可能的。
Websockets 的问题在于您无法通过设计访问 RAW UDP，并且不允许使用。
WebRTC 的问题在于它的数据通道使用一种 SRTP 形式，其中每个会话都有自己的加密密钥。因此，除非有人“发明”或 API 允许一种在所有客户端之间共享一个会话密钥的方法，否则多播是无用的。

有对等辅助交付的解决方案，这意味着该方法是混合的。服务器和对等点都有助于分发资源。这就是peer5.com和peercdn.com采取的方法。

如果我们专门谈论直播，它看起来像这样：

1. 广播公司将实况视频发送到服务器。
2. 服务器保存视频（通常还将其转码为所有相关格式）。
3. 正在创建有关此实时流的元数据，与 HLS 或 HDS 或 MPEG_DASH 兼容
4. 消费者浏览相关的实时流，播放器在那里获取元数据并知道接下来要获取哪些视频块。
5. 同时消费者正在连接到其他消费者（通过 WebRTC）
6. 然后播放器直接从服务器或从对等方下载相关块。

根据实时流的比特率和观众的协作上行链路，遵循这样的模型可以节省高达约 90% 的服务器带宽。

免责声明：作者在 Peer5 工作