WebRTC：同时重新协商问题 [英] WebRTC: simultaneous renegotiation issue

问题描述

使用案例：三个同伴在与同一房间中的其他两个人进行视频聊天，服务器发送消息并将所有三种更改模式转换为音频，

现在只有chrome支持重新协商，所以对于firefox，我只需关闭连接并创建新的对等连接，但在检查双方都是Chrome和更改模式后，

• 如果我一次只更改一个对等模式，它可以正常工作。


• 但是当消息来自服务器，两个同伴试图同时重新协商，并且它没有工作，我得到了类似错误的状态： STATE_SENTINITIATE


• 为了解决这个问题，我做了一个解决方法每当对等连接需要重新协商时，它会检查它是否是调用者
  
  
  
  • 如果是，则继续进行重新协商。
  
  
  • else （如果是回复者），它会改变提供的流并发信号给调用者重新协商。
  
  


• 上述解决方法适用于很少重新谈判，但在某些情况下，它在回答者一方设置本地描述时发生错误，声称错误状态为 STATE_INPROGRESS 或 STATE_SENTACCEPT
。

我该如何解决这个问题？

解决方案

既然重新谈判是一个国家机器，双方都会发起重新谈判。同一时间可能会发生碰撞，最终导致无效状态错误。这就是所谓的眩光。

您的解决方法是处理眩光的一种方法，基本上使用信号来确保重新协商总是始于相同（通常是提供者的一方）。

你说即使采用这种解决方法你仍然偶尔会看到无效状态错误。由于重新协商是双方之间的往返行程，因此如果您也在响应新的重新协商的信令请求，那么我认为如果您尝试过早重新协商，您仍然可能会收到无效状态错误。 p>

您可以检查 pc.signalingState 属性，以随时了解您的peerConnection处于何种状态。我会在收到传入消息时看看，看看是否有问题。如果是这样，我会阻止重新谈判，直到你的连接再次处于稳定状态。您可以使用 pc.onsignalingstatechange 对状态更改作出反应。

我听说过的另一个解决方案尝试）解决眩光将让同行独立重新谈判，当他们做眩光时，让提议者总是赢。例如回答者会取消它在接收传入要约时所做的任何尝试（以某种方式将自己恢复到之前的稳定状态），而提议者会在自己的尝试期间忽略任何传入的要约。

顺便说一下，Firefox现在也支持重新协商（38+），所以你可以在那里尝试一下，看看你是否遇到同样的问题。

Use Case: three peers are in video chat with other two in same room, server sends a message and all three change mode to audio,

for now, only chrome supports renegotiation, so for firefox, i just close the connection and create new peer connection, but after I check both sides are chrome and change mode,

• If I am changing mode of only one peer at a time, it works smoothly.
• but when, message comes from server, both peers try to renegotiate simultaneously and it didn't work, I got something like wrong state : STATE_SENTINITIATE
• To handle that problem, I did a workaround where, whenever peerconnection has to renegotiate, it checks if it is the caller
  • if yes, it goes ahead with renegotiation.
  • else(if it is answerer), it would change the offered stream and signal the caller to renegotiate.
• The above workaround works for few renegotiations, but for some cases, it throws error at setting local description on the answerer's side, claiming wrong state to be either STATE_INPROGRESS or STATE_SENTACCEPT.

how do I resolve this issue?

解决方案

Since renegotiation is a state-machine, having both sides initiate renegotiation at the same time can collide, and you end up with invalid-state errors. This is called glare.

Your workaround is one way to deal with glare, essentially using signaling to make sure renegotiation is always initiated from the same end (typically the offerer's side).

You say you're still seeing occasional invalid-state errors even with this workaround. Since renegotiation is a round-trip between peers, there's a window of time where if you're also responding to signaling requests for new renegotiation, I suppose you could still get invalid-state errors if you try to renegotiate again too soon.

You can check the pc.signalingState attribute to know what state your peerConnection is in at any time. I would look at that when you receive incoming messages, to see if this is the problem. If it is, I would hold off on renegotiating until your connection is in the "stable" state again. You can use pc.onsignalingstatechange to react to state changes.

Another solution I've heard of (but not tried) to solve glare would be to let peers renegotiate independently, and when they do glare, let the offerer always win. e.g. the answerer would cancel any attempts it was making on receiving an incoming offer (by somehow reverting itself back to its previous stable state), whereas the offerer would ignore any incoming offers during its own attempt.

By the way, renegotiation is supported in Firefox as well now (38+) so you could try it there as well to see if you get the same problems.

这篇关于WebRTC：同时重新协商问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！