RTCIceCandidate：usernameFragment 属性

包含用户名称片段（通常简称为“ufrag”或“ice-ufrag”）的字符串，该字符串与 ICE 密码（“ice-pwd”）一起唯一标识单个正在进行的 ICE 交互，包括与STUN 服务器的任何通信。该字符串最多可以包含 256 个字符，并且没有默认值。

在 ICE 会话开始时，ICE 层需要随机选择 ufrag 中至少 24 位文本。哪些位是随机的以及 ufrag 文本的其余部分是什么，由浏览器实现决定。例如，浏览器可以选择始终使用 24 个字符的 ufrag，其中每个字符的第 4 位在 0 和 1 之间随机选择。另一个示例：它可能会获取用户定义的字符串并在末尾附加三个 8 位随机字节。或者也许每个字符都是完全随机的。

ICE 使用 usernameFragment 和密码来确保消息完整性。这避免了多个正在进行的 ICE 会话之间的串扰，但更重要的是，有助于保护 ICE 事务（以及所有 WebRTC）免受可能试图注入 ICE 交换的攻击。

每次发生ICE 重启时，usernameFragment 和密码都会更改。

尽管 WebRTC 基础结构将在 ICE 重启后为您过滤掉过时的候选者，但如果您尝试最大程度地减少来回消息的数量，也可以自己执行此操作。

为此，您可以在从信令服务器接收候选者并调用addIceCandidate() 将其添加到可能的候选者集中之前，将其 usernameFragment 值与连接当前使用的 usernameFragment 进行比较。

当 Web 应用程序从信令服务器接收包含要添加到RTCPeerConnection 的候选者的消息时，您可以（并且通常应该）调用 addIceCandidate()。通常不需要手动担心过滤候选者。

但是，让我们假设我们需要最大程度地减少流量。当从信令服务器收到包含要添加到 RTCPeerConnection 的 ICE 候选者的消息 signalMsg 时，将调用以下函数 ssNewCandidate()。为了避免包含 ICE 重启导致过时的候选者，我们可以使用以下代码

const ssNewCandidate = (signalMsg) => {
  let candidate = new RTCIceCandidate(signalMsg.candidate);
  let receivers = pc.getReceivers();

  for (const receiver of receivers) {
    let parameters = receiver.transport.getParameters();

    if (parameters.usernameFragment === candidate.usernameFragment) {
      return;
    }
  }

  pc.addIceCandidate(candidate).catch(reportError);
};

这将遍历用于接收 ICE 数据的RTCRtpReceiver 对象列表，并查看候选者中指示的 usernameFragment 是否与其中任何一个匹配。如果匹配，ssNewCandidate() 将中止。否则，在检查所有接收器后，它会将新的候选者添加到连接中。