Google chrome Web RTC重新协商错误

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

调用者仅使用数据通道创建对等连接，创建报价，设置本地描述，并将报价发送给被调用者

被调用者设置远程描述、创建应答、设置本地描述并将应答发送给调用者

调用方设置远程描述

调用者和被调用者可以通过数据通道成功通信

PEERA将音频和/或视频流添加到对等连接

PEERA的OnGotiationNeedEvent火灾

PEERA创建报价，设置本地描述，并将报价发送给PEERB

PEERB接收报价，设置远程描述，创建应答，设置本地描述，并将应答发送给PEERA

如果PEERA和PEERB都使用Chrome： 如果PEERA是调用者，那么一切都正常，PEERB成功地接收到流。 如果PEERA是被调用方，那么在设置本地描述时，PEERB在步骤8中爆炸。PEERB接收流，但发送到

元素时仅显示为黑框

记录的错误是：

未能设置本地应答sdp:未能下推传输描述：未能为通道设置SSL角色

当PEERA和PEERB都使用FireFox时： PEERA可以是调用者，也可以是被调用者，并且一切正常，PEERB成功地接收到流

当被调用者使用Firefox且调用者使用Chrome时： PEERA可以是调用者（Chrome）或被调用者（Firefox），并且一切正常，PEERB成功接收流

当被叫方使用Chrome浏览器且被叫方使用Firefox时： 如果PEERA是调用方（FireFox），那么一切正常，PEERB（Chrome）成功接收流。 如果PEERA是被调用方（Chrome），那么在设置远程描述时，PEERB（FireFox）在第8步启动

记录的错误是：

DOMEException[InvalidSessionDescriptionError:“此时不支持ICE重启（新的远程描述更改ICE ufrag或ICE pwd）ICE ufrag（旧）：a59T34ixyZjsTUuJice ufrag（新）：RSCN1UGVKHJQZMBICE pwd（旧）：KqOHtqdzFp6VwG+3hxbjcQFcice pwd（新）：UVVOVGSKIWUCQ/BDMCGBSP”代码：0 nsresult:0x0]

ChromeChrome重新协商

当PEERA是重新协商中的被调用方时，您会遇到错误，这通常是由于Chrome更改了DTLS角色，但是我无法重现您的问题。我相信这说明了您正在描述的场景，我能够使用Chrome47成功地重新协商通话

如果仍然可以重现问题，请查看在报价/应答中生成的SDP的

a=setup:

位，并将其与初始报价/应答进行比较。如果我是对的，您将看到，首先，呼叫者将在报价中包含

a=setup:actpass

，被呼叫者将在回答中包含

a=setup:active

。这意味着调用者现在扮演“被动”DTLS角色，而被调用者则扮演“主动”DTLS角色

然后，当您启动重新协商时，PEERA很可能会发送

a=setup:actpass

。PEERB应该发送

a=setup:passive

，而不是发送

a=setup:active

，这实际上会导致DTLS角色交换。该错误是由于Chrome不支持对等连接的DTLS角色更改

有一个与此相关的例子，我在这里发布了一个你正在描述的问题的复制品，使用了一个不同的场景：启动一个仅视频通话，被叫方重新协商以添加视频+音频

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

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

FirefoxFirefox重新协商

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

FirefoxChrome重新协商互操作

我能够重现您描述的问题，Firefox中显示InvalidSessionDescriptionError。目前我还没有找到解决办法，也不知道原因

我还有很多其他的重新协商互操作问题。目前这相当令人沮丧

如果您了解更多信息，请发回。当然，在重新协商互操作方面仍然有很多困难