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()。通常不需要手動處理候選者的過濾。

但是，讓我們設想我們需要最小化流量。下面的函式 ssNewCandidate() 在從信令伺服器收到包含要新增到 RTCPeerConnection 的 ICE 候選者的訊息 signalMsg 時被呼叫。為了避免包含被 ICE 重新啟動所淘汰的候選者，我們可以使用如下程式碼：

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

  for (const receiver of receivers) {
    const parameters = receiver.transport.iceTransport.getRemoteParameters();

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

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

這會遍歷用於接收 ICE 資料的 RTCRtpReceiver 物件列表，並檢查候選者中指示的 usernameFragment 是否與其中任何一個匹配。如果匹配，則 ssNewCandidate() 會中止。否則，在檢查完所有接收器後，它會將新的候選者新增到連線中。

規範

瀏覽器相容性