【问题标题】:onicecandidate event is firing before acceping the answeronicecandidate 事件在接受答案之前触发
【发布时间】:2013-11-14 15:05:28
【问题描述】:

我在 chrome 浏览器 v30 中运行自己的 webrtc 演示代码时遇到问题。但该代码在 Firefox 上完美运行。 onicecandidate 事件在对方接受提议之前触发。另一方面,仅在接受报价后才创建对等连接。因此,当 onicecandidate 被触发时,在接收端以对等连接空错误结束。 据我了解 WebRTC 和我的代码流程是
第 1 步:来电者按下通话按钮
第 2 步:将调用 getUsermedia
第 3 步:将创建对等连接
第 4 步:报价将发送给来电者
第 5 步:报价将显示给来电者
第 6 步:仅在调用者接受呼叫后创建对等连接
第 7 步:对等连接将创建答案
第 8 步:回复发送给来电者
第 9 步:调用者将 icecandidates 发送给被调用者
第 10 步:被调用者将 icecandidates 发送给调用者

上述流程的问题是,在被叫方对等连接仅在用户接受报价后创建。但是在报价创建之后和报价被接受之前的调用方,ice 候选被发送给调用方。调用方这是导致空错误。

我在 pastebin 中粘贴了调试日志:- pastebinDOTcom/gMgaxbBp

请为我提供此问题的解决方案。

【问题讨论】:

    标签: google-chrome mozilla webrtc


    【解决方案1】:

    我自己弄明白了。问题实际上是在 chrome 中,一旦设置了对等连接本地描述,它就会开始收集冰块。只有在报价/答案完成后,我们才需要转发这些候选冰。 util它我们需要以某种方式存储在本地。这段代码在 firefox 上完美运行的原因是在 firefox 中,icecandidates 将被收集并放置在 offer 本身中。因此,icecandidate 会根据提议/答案本身进行交换。

    【讨论】:

    • 即使在七年多之后,您的回答也让我了解了冰候选人交换时间:我正在研究完全不同的技术堆栈,但您为我指明了正确的方向:非常感谢!
    【解决方案2】:

    我会更早地创建应答器 PeerConnection - 至少在 Firefox 上它可以开始收集 ICE 候选者并加快连接速度;我认为它会解决你的问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-08-21
      • 2013-08-15
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-06-09
      相关资源
      最近更新 更多