WebRTC：同步重新谈判问题

Question

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

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

• 如果我一次只更改一个同伴的模式，它会顺利运行。
• 但是，当消息来自服务器时，两个同行都试图同时重新协商而且它没有工作，我得到了错误的状态： STATE_SENTINITIATE
• 为了解决这个问题，我做了一个解决方法，每当peerconnection必须重新协商时，它会检查它是否是调用者
  • 如果是，则继续进行重新谈判。
  • else（如果它是回答者），它会改变提供的流并通知呼叫者重新协商。
• 上述解决方法适用于少数重新协商，但在某些情况下，它会在回答者方面设置本地描述时出错，声称错误状态为 STATE_INPROGRESS 或 STATE_SENTACCEPT 即可。

如何解决此问题？

Answer 1

由于重新协商是state-machine，双方同时发起重新协商可能会发生冲突，最终导致无效状态错误。这称为眩光。

您的解决方法是处理眩光的一种方法，主要是使用信令来确保重新协商始终从同一端（通常是提议者方）开始。

您说即使使用此解决方法，您仍然会偶尔看到无效状态错误。由于重新协商是对等体之间的往返，因此如果您还要响应新重新协商的信令请求，那么我认为如果您再次尝试重新协商，您仍然会遇到无效状态错误。太快了。

您可以检查pc.signalingState属性，以便随时了解您的peerConnection所处的状态。当你收到收到的消息时，我会看一下，看看这是不是问题。如果是的话，我会推迟重新谈判，直到你的联系在＆＃34;稳定＆＃34;再次声明。您可以使用pc.onsignalingstatechange来响应状态更改。

我已经听说过（但未尝试过）解决眩光问题的另一个解决方案是让同伴独立重新谈判，当他们确实眩光时，让提议者总是赢。例如回答者会取消它在接收收到的报价时所做的任何尝试（通过某种方式将自己恢复到之前的稳定状态），而提议者会在其自己的尝试中忽略任何传入的报价。

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