一次通话有两个 PeerConnection 有什么缺点？答案

【问题标题】：what are disadvantages of having two PeerConnections for one call?一次通话有两个 PeerConnection 有什么缺点？
【发布时间】：2015-07-10 22:44:15
【问题描述】：

我正在考虑将我的应用程序从使用单个 PeerConnection 双向传输媒体更改为一个 PeerConnection 用于上游，一个用于下游，用于两个对等方之间的单个调用。

我预见的优势：

将提供媒体从 video+audio 更改为 audio 时，无需担心 PeerConnection 的信号状态，反之亦然
可能更容易将像kurento 这样的媒体服务器插入应用程序（在多用户调用的情况下，用户需要的上传带宽更少）。
（不确定这一点）单一职责原则，每个PeerConnection都有单一角色。

我要进行此更改的主要原因是，我注意到如果 peer(peer1) 仅提供 audio 而其他 peer(peer2) 回答同时使用 video+audio，则 peer1 出于某种原因仅收到音频，但如果 peer1 是应答者，它可以毫无问题地接收两个 MediaTrack。不确定这是否是我的应用程序或浏览器中的错误（在 firefox 和 chrome 中得到相同的结果）。我能够通过维护状态，根据状态和内容更改提供者来解决问题，但是在两个对等方（几乎）同时更改状态时遇到问题。认为上述建议会是更简单的解决方案，我可以摆脱维护状态。

除了更多 ICE 候选请求的额外开销（n STUN n TURN）、维护额外的 PeerConnections 等明显的缺点之外，此设计后可能还有其他问题吗？

【问题讨论】：

标签： webrtc

【解决方案1】：

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

我想要进行此更改的主要原因是，我注意到如果 peer(peer1) 仅提供音频，而其他 peer(peer2) 以视频+音频的方式回答，则 peer1 出于某种原因仅接收音频，

不要问我为什么，但是当 peer1 只提供音频时，默认的规范行为是只从另一端请求音频。要覆盖这一点并让您自己也可以接收视频（如果对方有视频），请使用RTCOfferOptions：

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

（或者，如果您使用的是旧版 non-promise API，则它是第三个参数。）

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

【讨论】：

我会注意到一些系统故意使用两个（或多个）单向连接，例如 TokBox。正如您所提到的，它使一些事情变得更容易，而一些事情变得更难（同步更多状态、设置时间等）

【解决方案2】：

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

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

【讨论】：

我想，既然额外的问题是在浏览器上，应该不会花那么多钱，还认为对于不支持重新协商的旧浏览器会更好，比如当你改变流时，至少你的屏幕一直在接收他的信息流，当你关闭并再次分享你的信息流时，至少它在一侧看起来是无缝的。
@mido22，当然。这就是正交性在这个解决方案中真正闪耀的地方。我只知道浏览器中的 webrtc 状态（至少在过去）在某些情况下可能相当脆弱。它在过去一年左右变得更加强大，希望不会对您的解决方案造成任何严重问题。