WebRTC：同时重新协商问题

Question

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

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

• 如果我一次仅更改一个同伴的模式，则它可以正常运行。
• 但是，当消息来自服务器时，两个对等方都尝试同时重新协商，但没有成功，我得到了类似错误的状态：STATE_SENTINITIATE
• 为了解决该问题，我做了一个变通办法，其中在对等连接必须重新协商时，它会检查是否是调用方
  • 如果是，它将继续进行重新谈判。
  • 否则（如果是应答者），它将更改提供的流并向呼叫者发出重新协商的信号。
• 上述解决方法仅适用于很少的重新协商，但在某些情况下，它会在答答器侧设置本地描述时抛出错误，声称错误状态为STATE_INPROGRESS或STATE_SENTACCEPT。

我该如何解决这个问题？

Answer 1

由于重新协商是一种状态机，因此双方同时发起重新协商可能会发生冲突，并且最终会导致无效状态错误。这称为眩光。

解决方法是处理眩光的一种方法，实际上是使用信号发送来确保始终从同一端（通常是提供方）开始重新协商。

您说即使采用这种解决方法，仍然偶尔会看到无效状态错误。由于重新协商是对等方之间的往返行程，因此在一段时间内，如果您还响应新的重新协商的信号请求，我想如果您尝试过早重新协商，您仍然会收到无效状态错误。

您可以随时检查pc.signalingState属性以了解peerConnection处于什么状态。当您收到传入消息时，我会看看是否是问题所在。如果是这样，我将推迟进行重新协商，直到您的连接再次处于“稳定”状态。您可以pc.onsignalingstatechange用来对状态更改做出反应。

我听说过（但没有尝试过）解决眩光的另一种方法是让同龄人重新协商，当他们眩目时，让要约人总是赢。例如，应答者将取消其在收到传入要约时所做的任何尝试（通过某种方式使其自身恢复到其先前的稳定状态），而要约人则将在其自身尝试期间忽略任何传入要约。

顺便说一句，Firefox现在也支持重新协商（38+），因此您也可以在那里进行尝试，以查看是否遇到相同的问题。