【问题标题】：What is the proper way to reject a WebRTC offer?拒绝 WebRTC 报价的正确方法是什么？
【发布时间】：2017-07-02 18:04:53
【问题描述】：

在 WebRTC 中，事情发生的顺序似乎非常明确。在本地，我使用getUserMedia 获取本地流，并将流保存到变量中。我创建了一个RTCPeerConnection 对象，我将其命名为pc，并将本地流添加到它。我将onaddstream 事件处理程序添加到pc，以便我可以将远程用户的流保存到变量中，并最终将其设置为audio 等HTML 元素的src 属性。我还在我的pc 上设置了onicecandidate 事件处理程序来处理候选冰。

此时，有一个RTCPeerConnection，但还没有远程用户“连接”。这是“提议/答案”开始的地方。假设我正在使用 websockets 发送信号，我收到了一个报价，这是一条名为“报价”的消息，包含一个 SDP 对象。我该如何拒绝它，这应该如何在两个端点上处理？

例如，我可以发送一条消息“拒绝”，该消息将转发给其他用户。我的 RTCPeerConnection 仍然存在，也许我希望能够接听其他电话。照原样，我不必对我的 RTCPeerConnection 做任何事情，对吗？发送报价的其他用户是否必须做任何事情？他是否必须关闭那个特定的 RTCPeerConnection？我认为不会，因为他所做的只是创建一个 SDP 对象，然后在 WebRTC 之外，通过 websockets 将对象发送给其他用户。不过，他确实使用setLocalDescription 添加了报价。当offer被拒绝时，他需要对此做些什么吗？

当我创建报价并将其发送给其他用户时，如果我从未得到回复，我是否可以将报价发送给第三个用户，然后如果他发送了答案，我就与他保持联系？

我没有找到任何关于 RTCPeerConnection 生命周期的信息。

【问题讨论】：

标签： javascript webrtc

【解决方案1】：

拒绝媒体的正确（规范）方式

尚未在任何浏览器中实现在答案中“拒绝”提供的媒体的“正确”方式：

pc.ontrack = e => e.transceiver.stop();

基本上，WebRTC 1.0 规范在这方面有 changed quite significantly。简而言之，收发器是一个结合了一个发送器和一个接收器的对象，每个发送或接收一个轨道。 transceiver.stop() 允许您在信号 SDP 媒体描述中拒绝单个双向 m-line（协商媒体）。例如。您可以在回答中拒绝部分要约，而不是全部拒绝。

今天

今天，拒绝单个 m 行的唯一方法是手动修改 SDP 提议/答案。

但听起来你实际上根本没有问这个问题。相反，听起来您在问如何摆脱不完整的信号并将对等连接回滚到“稳定”状态。

回滚到稳定状态

提议/答复协商周期为state machine。状态为pc.signalingState：

您询问是否一方退出协商，任何一方是否需要做任何事情才能重新调整其连接对象的用途，以便与相同或不同的对等方进行新尝试。好吧，这取决于。

如果您只调用了createOffer，则不需要回滚状态，因为createOffer 不在上图中。

如果您调用了setLocalDescription，那么您现在处于"have-local-offer" 状态，这意味着您确实需要以某种方式回到@987654333 @state 才能重用连接。

您的选择是完成协商、删除连接或回滚到稳定状态（目前只有 supported 和 Firefox，虽然它是在规范中）：

let pc = new RTCPeerConnection();

pc.onnegotiationneeded = async e => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    console.log(pc.signalingState); // have-local-offer

    await pc.setLocalDescription({type: "rollback"});
    console.log(pc.signalingState); // stable

  } catch(e) {
    console.log(e);
  }
}
pc.createDataChannel("dummy");

&lt;script src="https://webrtc.github.io/adapter/adapter-latest.js"&gt;&lt;/script&gt;

当然，您还应该让对等方知道，通常是通过带外信令。

为什么这通常不是问题。

在典型情况下，您在两端都拥有 JavaScript，因此不会出现这种情况。换句话说，建立联系的愿望通常先于建立联系。

【讨论】：