Web RTC 重新协商错误

Question

我设置了一个 WebRTC 应用程序，其工作方式如下：（从第 5 步开始，我停止使用 CALLER/CALLEE，因为 CALLER 或 CALLEE 都可以启动流）

1. CALLER 仅使用数据通道创建对等连接，创建报价，设置本地描述，并将报价发送给 CALLEE。
2. CALLEE 设置远程描述，创建答案，设置本地描述，并将答案发送给 CALLER。
3. CALLER 设置远程描述。
4. CALLER 和 CALLEE 可以通过数据通道成功通信。
5. PEERA 将音频和/或视频流添加到对等连接。
6. PEERA 的 onnegotiationneeded 事件触发。
7. PEERA 创建报价，设置本地描述，并将报价发送给 PEERB。
8. PEERB 接收报价，设置远程描述，创建答案，设置本地描述，并将答案发送给 PEERA。

如果 PEERA 和 PEERB 都使用 Chrome： 如果 PEERA 是 CALLER，则一切正常，PEERB 成功接收流。 如果 PEERA 是 CALLEE，则在设置 LOCAL 描述时，PEERB 在步骤 8 中爆炸。流由 PEERB 接收，但在发送到 <video> 元素时仅显示为黑框。

记录的错误是：

设置本地应答 sdp 失败：下推传输描述失败：为通道设置 SSL 角色失败。

当 PEERA 和 PEERB 都使用 FireFox 时： PEERA可以是CALLER也可以是CALLEE，一切正常，PEERB接收成功。

当 CALLEE 使用 Firefox 而 CALLER 使用 Chrome 时： PEERA可以是CALLER(Chrome)也可以是CALLEE(Firefox)，一切正常，PEERB接收成功。

当 CALLEE 使用 Chrome 而 CALLER 使用 Firefox 时： 如果 PEERA 是 CALLER(FireFox)，则一切正常，PEERB(Chrome) 成功接收流。 如果 PEERA 是 CALLEE(Chrome)，那么在设置 REMOTE 描述时，PEERB(FireFox) 在第 8 步中爆炸。

记录的错误是：

DOMException [InvalidSessionDescriptionError：“此时不支持 ICE 重启（新的远程描述更改了 ice-ufrag 或 ice-pwd）ice-ufrag（旧）：a59T34ixyZjsTUuJice-ufrag（新）：rsCN1ugVKHJQzmMbice-pwd（旧） : KqOHtqdzFp6VwG+3hxbjcQFcice-pwd (new): uVvowvgsKIwuCq/bDmcGbSPA" 代码: 0 nsresult: 0x0]

Answer 1

ChromeChrome 重新协商

当 PEERA 是重新协商中的被调用方时出现的错误通常是由于 Chrome 更改了 DTLS 角色，但是我无法重现您的问题。我相信this JSFiddle link 说明了您所描述的场景，并且我能够使用 Chrome 47 成功地重新协商通话。

如果您仍然可以重现该问题，请查看报价/答案中生成的 SDP 的 a=setup: 位，并将它们与初始报价/答案进行比较。如果我是对的，您会首先看到，CALLER 将在报价中包含a=setup:actpass，而 CALLEE 将在答案中包含a=setup:active。这意味着 CALLER 现在正在扮演“被动”DTLS 角色，而被呼叫者正在扮演“主动”DTLS 角色。

然后，当您发起重新协商时，PEERA 很可能会发送a=setup:actpass。应该发送 a=setup:passive 的 PEERB 正在发送 a=setup:active，这实质上会导致 DTLS 角色交换。该错误是由于 Chrome 不支持为对等连接更改 DTLS 角色。

有一个与此相关的open ticket on the google chrome bug tracker，我在其中发布了您使用不同场景描述的问题的复制品：开始纯视频通话和被叫方重新协商以添加视频+音频。

我目前知道的唯一解决方案是在调用 setLocalDescription 之前“修改”（更改）SDP，以便它具有您想要的值。因此，例如，如果您要处理答案并且您知道自己是 被动 DTLS 角色，您可以这样做

answer.sdp = answer.sdp.replace('a=setup:active','a=setup:passive');
pc.setLocalDescription(answer).then(...);

FirefoxFirefox 重新协商

是的，一切都很好！那是因为在我运行的所有测试中重新协商时，Firefox 对 DTLS 角色“做了正确的事情”。看看这些 SDP 和 Chrome SDP 之间的区别。

FirefoxChrome 重新协商互操作

我我能够重现您所描述的问题，InvalidSessionDescriptionError 出现在 Firefox 中。目前我还没有想出解决方案，也不知道原因。

我还有无数其他重新协商互操作问题。眼下真的很郁闷。

如果您了解更多信息，请回帖。在重新协商互操作方面肯定还有很多挣扎！