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(new):rsCN1ugVKHJQzmMbice-pwd(old):KqOHtqdzFp6VwG + 3hxbjcQFcice-pwd(新):uVvowvgsKIwuCq/bDmcGbSPA"代码:0 nsresult:0x0]

Answer 1

Chrome<->Chrome 重新协商

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

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

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

谷歌浏览器错误跟踪器上有一个与此相关的开放票证，我在其中发布了您使用不同场景描述的问题的再现：开始仅视频通话，被叫方重新协商添加视频+音频。

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

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

Firefox<->Firefox 重新协商

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

Firefox<->Chrome 重新协商互操作

我是通过 Firefox 中显示的 InvalidSessionDescriptionError 重现您所描述的问题。目前我还没有找到解决方案，也不知道原因。

我还遇到了无数其他重新协商互操作问题。目前这非常令人沮丧。

如果您了解更多信息，请回帖。肯定还有很多与重新协商互操作有关的问题！