Use Case：三个同伴正在与同一房间中的另外两个同伴进行视频聊天，服务器发送一条消息，并且所有三个同伴都将模式更改为音频，
目前，只有 chrome 支持重新协商，因此对于 firefox，我只需关闭连接并创建新的对等连接，但在我检查双方都是 chrome 并更改模式后，
- 如果我一次只更改一个对等点的模式，则效果会很顺利。
- 但是，当消息来自服务器时，两个对等点都尝试同时重新协商，但没有成功，我得到了类似错误状态的信息：STATE_SENTINITIATE
- To handle that problem, I did a workaround where, whenever peerconnection has to renegotiate, it checks if it is the caller
- 如果是，则继续重新谈判。
- 否则（如果是应答者），它将更改提供的流并通知呼叫者重新协商。
- 上述解决方法适用于很少的重新协商，但在某些情况下，它会在应答者一侧设置本地描述时抛出错误，声称错误的状态是状态_进行中 or STATE_SENT接受.
我该如何解决这个问题？
由于重新谈判是状态机，让双方同时发起重新协商可能会发生冲突，最终会出现无效状态错误。这就是所谓的glare.
您的解决方法是处理眩光的一种方法，本质上是使用信号来确保重新协商始终从同一端（通常是提供者一侧）发起。
您说即使使用此解决方法，您仍然偶尔会看到无效状态错误。由于重新协商是对等点之间的往返，因此存在一个时间窗口，如果您还响应新重新协商的信令请求，我想如果您过早尝试再次重新协商，您仍然可能会收到无效状态错误。
您可以检查pc.signalingState属性来随时了解您的对等连接处于什么状态。当您收到传入消息时，我会查看一下，看看这是否是问题所在。如果是，我会推迟重新协商，直到您的连接再次处于“稳定”状态。您可以使用pc.onsignalingstatechange对状态变化做出反应。
我听说过（但没有尝试过）的另一个解决眩光的解决方案是让同行独立重新谈判，当他们进行眩光时，让报价者总是获胜。例如应答者将取消其在接收传入报价时所做的任何尝试（通过某种方式将自身恢复到之前的稳定状态），而报价者将在其自己的尝试期间忽略任何传入报价。
顺便说一下，Firefox（38+）现在也支持重新协商，因此您也可以在那里尝试一下，看看是否遇到相同的问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
