一个呼叫有两个 PeerConnections 有什么缺点? [英] what are disadvantages of having two PeerConnections for one call?

问题描述

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

I am thinking of changing my application from using a single PeerConnection for transferring media both ways to one PeerConnection for upstream and one for downstream for a single call between two peer.

我预见的优势:

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

• Less worry about signalling state of PeerConnection when changing offering media from video+audio to audio and vice-versa
• Might be easier to plug an Media Servers like kurento into the application ( in case of multi user call, lesser upload bandwidth required by user).
• (not sure of this one) single responsibility principle, each PeerConnection has single role.

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

the major reason I want to do this change is, I am noticing that if peer(peer1) offers only audio but other peer(peer2) answers with both video+audio, peer1 recieves only the audio for some reason, but if peer1 had been an answerer, it is able to recieve both MediaTracks without any problem. Not sure if it is a bug in my app or browser( got same result in firefox and chrome). I was able to make a workaround by maintaining states, changing offerer based on state and stuff, but having problems with both peers changing state (nearly) simultaneously. Thought above proposal would be simpler solution and I can get rid of maintaining states.

除了更多 ICE 候选请求 (n STUN n TURN) 的额外开销的明显缺点、维护额外的 PeerConnections 之外，这种设计可能还有其他问题吗?

Other than the obvious disadvantages of extra overhead of more ICE candidate requests( n STUN n TURN), maintaining extra PeerConnections, any other issue possible following this design?

推荐答案

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

Nothing prevents you from doing that, but I suspect there's a simpler solution to your problem which you kind of buried:

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

the major reason I want to do this change is, I am noticing that if peer(peer1) offers only audio but other peer(peer2) answers with both video+audio, peer1 recieves only the audio for some reason,

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

Don't ask me why, but the default spec behavior when peer1 only offers audio, is to only request audio from the other side. To override this and leave yourself open to receiving video as well if the other side has it, use RTCOfferOptions:

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

(或者，如果您使用的是旧版 non-promise API，则这是第三个参数.)

(or if you're using the legacy non-promise API it's the third argument.)

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

The nice thing with this is that it is intent-based so you don't need to track any state. e.g. always using { offerToReceiveVideo: true, offerToReceiveAudio: true } may be right for you.

这篇关于一个呼叫有两个 PeerConnections 有什么缺点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！