未能设置远程应答sdp:未能下推传输描述:未能为通道设置SSL角色
我正在使用webRTC构建一个支持音频呼叫的系统。下面是它的工作原理:未能设置远程应答sdp:未能下推传输描述:未能为通道设置SSL角色,ssl,webrtc,sdp,Ssl,Webrtc,Sdp,我正在使用webRTC构建一个支持音频呼叫的系统。下面是它的工作原理: -用户AcreateOffer,然后使用offer -用户BreceiveOffer,然后setRemoteDescription使用offer -用户BcreateAnswer,然后setLocalDescription使用answer -用户AreceiveAnswer,然后使用answer 问题是,在收到B的答复后,当A设置RemoteDescription(answer)时,出现以下错误: 未捕获(承诺中)DOMEE
-用户A
createOffer
,然后使用offer
-用户B
receiveOffer
,然后setRemoteDescription
使用offer
-用户B
createAnswer
,然后setLocalDescription
使用answer
-用户A
receiveAnswer
,然后使用answer
问题是,在收到B的答复后,当A设置RemoteDescription(answer)时,出现以下错误:
未捕获(承诺中)DOMEException:无法设置远程应答sdp:无法下推传输描述:无法为通道设置SSL角色。
我不知道为什么会出现这个错误。我试着用谷歌搜索它,但到目前为止运气不好。任何帮助都将不胜感激 看起来确实如此。总之,发生的事情是:
-Firefox提供了actpass
-Chrome回答激活
。这将Chrome建立为DTLS客户端,Firefox建立为DTLS服务器。
-Chrome重新提供了活动的(因为这是规范所说的,或者至少是我们长期以来对它的解释)
-Firefox提供了活动的
,但具有相同的DTLS指纹。Chrome不喜欢这样;这被解释为试图将DTLS角色从服务器
更改为客户端
,而不创建新关联。
为了解决这个问题,我所做的是:确保提供/回答的方向保持一致。也就是说,如果Firefox生成初始报价,它也会生成所有后续报价。我不确定这种做法有多普遍,但它可能会避免很多互操作错误。
更详细的讨论:我在重新谈判时遇到了这个问题。我通过确保服务器应将sdp设置应答为被动来解决这个问题。在chrome firefox上通常会出现此错误
您也可以在此处查看: