使用WebRTC进行P2P音频广播

Question

我有一个源和一组听众收听音频流。如果我使用P2P WebRTC流式传输，那么天真的方法是从扬声器创建N-1连接。这可以到N < 3。但是否则P2P的传输成本很高。我概述了两种方法，并试图找出哪种方法最合适。

1. 让中央服务器中继和录制音频。 （-latency + cost）
2. 不是从源打开N-1连接，而是某些终端节点将充当非终端节点，并将打开K < N-1个连接以中继和记录传输。 （+ latency -cost）

我是WebRTC的新手。我正在计划我的http方面是C ++。如果我采用方法（2），我在服务器端增加了音频流的额外费用。但这不是直截了当的。如果它已经存在并旋转良好，我肯定不想重新发明轮子。但我不知道现有的是什么，这种方法有哪些风险。

如果我接近（1）我应该使用什么中继服务器？应该与业务逻辑紧密集成。这部分我很难搞清楚。使用websocket，我发现这部分很容易，因为所有都在同一个会话中，所有上下文信息都是可访问的。但在某种程度上，我需要将用户帐户映射到流并在其上应用业务逻辑。与某些用户一样，我会降低音量。

我还需要在同一个流中广播数据。

我不能让任何人（不使用我的应用程序）使用我的TURN服务器。我需要某种令牌/身份验证系统。我怎么能这样做？

Answer 1

你是对的，不要重新发明轮子。从头开始构建webRTC媒体服务器很难。幸运的是，有很多选项可以简化任务。看看：

• https://janus.conf.meetecho.com/
• http://lynckia.com/licode/
• https://www.kurento.org/

此外，您还必须决定是将所有流发送给任何参与者，还是将其混合到服务器中，并且只向会议中的每个参与者发送一个。它们被称为SFU和MCU方法。

关于如何通过同一个流发送数据的问题，webRTC提供了一个名为DataChannel的机制，仅用于此目的。多亏了它，您可以创建一个包含不同曲目的流：音频，视频，屏幕共享或数据。

Answer 2

  

不是从源打开N-1个连接，而是一些终端节点将充当非终端节点并且将打开K＆lt; N-1连接继电器并记录传输。 （+ latency -cost）

Muaz-Khans rtcmulticonnection的broadcast demo证明了这一点，所以你不需要重新发明那个轮子。正如你所说它的成本低于中央服务器，但增加了延迟，这取决于用例是否优于中央服务器。

Answer 3

  

我不能让任何人（不使用我的应用程序）使用我的TURN服务器。我需要某种令牌/身份验证系统。我怎么能这样做？

执行此操作的标准方法是使用有时间限制的凭据。 coturn服务器支持开箱即用，并具有very good explanation in their wiki

它并不完美，但到目前为止还没有重大的滥用案例。