1

我的问题是关于 webrtc 协商。

许多在线教程和 MDN 中描述的内容存在矛盾。

在 MDN 中，它说链接

在每一代候选者结束时，以候选者属性为空字符串的 RTCIceCandidate 形式发送候选者结束通知。仍然应该像往常一样使用 addIceCandidate() 方法将此候选者添加到连接中，以便将该通知传递给远程对等方。

如果在当前协商交换期间根本没有更多候选者，则通过传递候选者属性为空的 RTCIceCandidate 来发送候选者结束通知。此消息不需要发送到远程对等方。这是一个状态的遗留通知，可以通过观察 iceGatheringState 更改为完成，通过观察 icegatheringstatechange 事件来检测。

但是，在这里的教程中，他们介绍了以下代码

function handleICECandidateEvent(event) {
  if (event.candidate) {
    sendToServer({
      type: "new-ice-candidate",
      target: targetUsername,
      candidate: event.candidate
    });
  }
}

如果 Candidate 是一个空字符串，它将被评估为 falsy 并且不会通过sendToServer.

更有趣的是，即使在同一篇文章中

他们有以下示例代码

rtcPeerConnection.onicecandidate = (event) => {
  if (event.candidate) {
    sendCandidateToRemotePeer(event.candidate)
  }
}

但是在这个片段的正下方，他们说

当 ICE 谈判会话中没有候选人为给定的 RTCIceTransport 提出建议时，它已经完成了一代候选人的收集。这由一个候选字符串为空 ("")的 icecandidate 事件指示。

您应该像任何标准候选人一样将其交付给远程对等方，如上面共享新候选人中所述。这可确保远程对等方也收到候选结束通知。

实际上，我阅读了许多在线教程，但我从未见过他们处理空字符串候选者的任何地方。

4

1 回答 1

1

旧规范不需要发送一个空的候选者，但新规范需要发送和 addIceCandidate() 一个空的候选者。由于Chrome还是老规范，空的candidate在addIceCandidate()的时候会报错，所以就不发了。

于 2020-05-03T09:35:28.880 回答