我有一个音频源和一组听众在收听音频流。如果我使用P2P WebRTC进行流传输,那么天真的方法是从扬声器创建
N-1
个连接,这对于N < 3
是可以的。但否则P2P是传输昂贵的。我已经概述了两种方法,并试图找出哪种最适合。
- 有一个集中式服务器中继和记录音频。(-延迟+成本)
- 与其从源打开
N-1
个连接,不如将一些终端节点作为非终端节点,并打开K < N-1
个连接以中继和记录传输。(+延迟-成本)
我对WebRTC非常陌生。我计划我的http端使用C ++。如果我采用第二种方法,则对于音频流,我不会在服务器端增加任何额外成本。但这并不直接。如果已经存在并且运行良好,我肯定不想重新发明轮子。但我不知道现有的情况以及这种方法的风险。
如果采用第一种方法,我应该使用哪个中继服务器?它应该与业务逻辑紧密集成。这部分我很难弄清楚。使用websocket,我发现这部分很容易,因为所有人都在同一个会话中,并且所有上下文信息都可以访问。但是在这里,我需要将用户帐户映射到流,并对其应用业务逻辑。例如,对于某些用户,我会降低音量。
我还需要在同一流中广播数据。
我不能让任何人(不使用我的应用程序的人)使用我的TURN服务器。我需要某种令牌/授权系统。我该怎么做?