拒绝 WebRTC 报价的正确方法是什么？

Question

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

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

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

当我创建报价并将其发送给其他用户时，如果我永远不会得到答复，我是否可以只向第三个用户发送报价，然后如果他发送答复，我就与他联系了？

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

Answer 1

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

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

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

基本上，WebRTC 1.0 规范在这方面发生了相当大的变化。简而言之，收发器是一个结合了一个发送器和一个接收器的对象，每个发送或接收一个轨道。 transceiver.stop()允许您拒绝发送信号的 SDP 媒体描述中的单个双向m-line（协商媒体）。例如，您可以拒绝答案中的部分提议，而不是拒绝整个事情。

今天

今天，拒绝单个 m-line 的唯一方法是手动修改 SDP 提供/应答。

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

回滚到稳定状态

报价/应答协商周期是一个状态机。状态是pc.signalingState：

您询问是否有一方退出协商，是否有任何一方需要做任何事情才能将其连接对象重新用于与相同或不同对等方的新尝试。这要看情况。

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

setLocalDescription但是，如果您已调用，那么您现在处于"have-local-offer"状态，这意味着您确实需要以某种方式返回"stable"状态，然后才能重用连接。

你的选择是要么完成谈判，删除连接，或回滚到稳定的状态（目前仅支持在Firefox中，虽然它是在规范中）：

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

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");

当然，你也应该让对方知道，通常是通过带外信令。

为什么这通常不是问题。

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