是否应使用addicecandidate添加空字符串icecandidate？

Question

我的问题是关于webrtc谈判的。

[许多在线教程中都有矛盾，并且MDN中描述了什么。

在MDN中，它表示link

在每一代候选人的末尾，候选人通知以RTCIceCandidate 其候选者属性是一个空字符串。此候选人仍应添加到照常使用addIceCandidate（）方法进行连接将该通知传递给远程对等。

[如果在当前的协商交流，候选人终止通知是通过传递候选属性为null的RTCIceCandidate发送。此消息不需要发送到远程对等方。它是可以检测到的状态的旧式通知通过观看观看冰收集状态更改为完成用于icegatheringstatechange事件。

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

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

如果候选者是一个空字符串，它将被评估为伪造，不会通过sendToServer发送。

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

他们有以下示例代码

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

但是在此片段的下面，他们说

[当ICE协商会议用尽候选人以求给定的RTCIceTransport，它已经完成了一代人的收集的候选人。发生这种情况的对象是一个冰候选人事件其候选字符串为空（“”）。

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

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

我的问题是关于webrtc谈判的。许多在线教程与MDN中描述的内容存在矛盾。在MDN中，它表示链接。在每一代候选者的末尾，都有一个end -...

Answer 1

旧规范不需要发送空的候选，但是新规范要求send和addIceCandidate（）为空候选。由于Chrome仍然是一个旧规范，如果添加的IceCandidate（）为空，则候选者将导致错误，因此我将不发送它。