【问题标题】:WebRTC: Why "CreateAnswer can't be called before SetRemoteDescription"?WebRTC:为什么“不能在 SetRemoteDescription 之前调用 CreateAnswer”?
【发布时间】:2016-04-26 17:27:30
【问题描述】:

浏览器:Chrome

我正在尝试调试一个 webRTC 应用程序,该应用程序在四个方面中的三个方面都可以正常工作!我无法从接收方获取视频到呼叫方。我可以从呼叫者到接收者的视频和音频以及从接收者到呼叫者的音频。问题是接收器没有触发视频 (sdpMid="video") ICE 候选。在拼命尝试解决此问题时,我尝试在设置 pc.remoteDescription 之前使用 pc.CreateAnswer 并给出标题中引用的错误。

我的问题是了解这背后的原因。答案 SDP 只是基于 getUserMedia 设置/约束的 SDP。那么,为什么我们要等待设置remoteDescription。我认为 createAnswer 会开始触发 ICE 候选者的集合,这可以提前完成,而无需等待设置 remoteDescription。事实并非如此。为什么?

【问题讨论】:

    标签: webrtc


    【解决方案1】:

    提议和答案不是独立的,它们是本质上不对称交换的一部分。

    答案是对特定提议的直接回应(因此得名“答案”)。因此,对等方在收到您使用setRemoteDescription 设置的报价之前无法回答。

    报价包含特定限制或信封(如 m 行),答案必须遵守/回答/保持在其中。另一种说法是,答案是报价的迭代。

    例如,使用报价选项offerToReceiveVideo: false 创建的报价只能用recvonly 来回答视频(意味着只能从报价者接收视频到回答者),而不能使用sendrecv

    【讨论】:

    • 我以为offer和answer只是对媒体/传输/编解码器/等的描述。在每一端都可用,并将由两端独立分析。我认为 ICE 候选人单独控制 SDP 决定建立通信的可能性的能力,这在理论上是可能的:如果两个独立的 SDP 不兼容 - 没有 ICE 候选人。但是,正如您所解释的那样,基于报价的答案更有意义。
    • Offer和answer是描述,但交换本身是协商。候选人找到要传输的 ip+port 对。
    • 所以在设置本地和远程 SDP 之前,onIceCandidate 事件不应在任何一端触发?
    • @Sam onicecandidate 在设置本地描述后立即触发。它与 setRemoteDescription 没有任何关系。
    • 我使用 Promise 重写并发布了整个代码 here。你帮了大忙。就最后一次,能不能看一下新代码。现在我两端都没有远程视频,但我认为对调用者和接收者使用单一代码并使用 Promises 的方法值得重写。
    猜你喜欢
    • 2020-02-14
    • 2019-01-10
    • 1970-01-01
    • 1970-01-01
    • 2014-11-08
    • 2014-10-08
    • 2013-03-31
    • 2015-09-27
    • 1970-01-01
    相关资源
    最近更新 更多