一次通话有两个PeerConnections有什么缺点？

Question

我正在考虑改变我的应用程序，使用单个PeerConnection将媒体双向传输到一个PeerConnection用于上游，一个用于下游用于两个对等体之间的单个呼叫。

我预见的优点：

• 在将提供媒体从video+audio更改为audio时反而更加担心PeerConnection的信号状态，反之亦然
• 可能更容易将kurento等媒体服务器插入应用程序（如果是多用户呼叫，用户需要较少的上传带宽）。
• （不确定这一点）单一责任原则，每个PeerConnection都有单一角色。

我想要做这个改变的主要原因是，我注意到如果peer（peer1）只提供audio而其他同伴（peer2）同时回复video+audio，则peer1只接收音频出于某种原因，但如果peer1是一个回答者，它能够毫无问题地收到两个MediaTracks。不确定它是否是我的应用程序或浏览器中的错误（在Firefox和Chrome中得到相同的结果）。我能够通过维护状态，根据状态和内容改变提议来制定解决方法，但是同时存在两个同伴改变状态（几乎）的问题。上面提出的建议会更简单，我可以摆脱维持状态。

除了更多ICE候选请求额外开销的明显缺点（n STUN n TURN），维护额外的PeerConnections，此设计后可能出现的任何其他问题？

Answer 1

没有什么可以阻止你这样做，但我怀疑你的问题有一个更简单的解决方案，你埋没了：

  

我想要做这个改变的主要原因是，我注意到如果peer（peer1）仅提供音频而其他peer（peer2）同时响应视频+音频，则peer1仅出于某种原因接收音频，

不要问我原因，但是peer1仅提供音频时的默认规范行为是仅从另一方请求音频。要覆盖这一点并让自己接受视频，如果对方有视频，请使用RTCOfferOptions：

peer1.createOffer({ offerToReceiveVideo: true }).then( ... )

（或者如果您使用传统的非承诺API，它就是第三个参数。）

这样做的好处在于它是基于意图的，所以你不需要跟踪任何状态。例如始终使用{ offerToReceiveVideo: true, offerToReceiveAudio: true }可能适合您。

Answer 2

资源问题是您正在使用更多端口，因为连接的两端都必须完成DTLS握手（这是通过对等而不是通过信令服务器完成的）。

设计挑战是正交地跟踪两个连接。如果状态处理不当（浏览器状态错误等），它可能会毛茸茸并且更容易在底层webrtc实现中显示错误。