RTCIceCandidate: usernameFragment-Eigenschaft

Ein String, der das Benutzerfragment enthält (im Allgemeinen in Kurzform als "ufrag" oder "ice-ufrag" bezeichnet), das zusammen mit dem ICE-Passwort ("ice-pwd") eine einzelne laufende ICE-Interaktion eindeutig identifiziert, einschließlich der Kommunikation mit dem STUN-Server. Der String darf bis zu 256 Zeichen lang sein und hat keinen Standardwert.

Mindestens 24 Bits des Textes im ufrag müssen zu Beginn der ICE-Sitzung vom ICE-Layer zufällig ausgewählt werden. Die Details, welche Bits zufällig sind und was der Rest des ufrag-Textes ist, bleiben der Entscheidung der Browser-Implementierung überlassen. Zum Beispiel könnte ein Browser sich entscheiden, immer ein 24-Zeichen langes ufrag zu verwenden, bei dem Bit 4 jedes Zeichens zufällig zwischen 0 und 1 ausgewählt wird. Ein weiteres Beispiel: Er könnte einen benutzerdefinierten String nehmen und drei 8-Bit-Zufallsbytes anhängen. Oder vielleicht ist jedes Zeichen vollständig zufällig.

ICE verwendet das usernameFragment und das Passwort, um die Integrität der Nachrichten sicherzustellen. Dies vermeidet Übersprechen zwischen mehreren laufenden ICE-Sitzungen, aber vor allem hilft es, ICE-Transaktionen (und alles in WebRTC im Allgemeinen) gegen Angriffe abzusichern, die versuchen könnten, sich in einen ICE-Austausch einzufügen.

Das usernameFragment und das Passwort ändern sich jedes Mal, wenn ein ICE-Neustart erfolgt.

Obwohl die WebRTC-Infrastruktur veraltete Kandidaten für Sie nach einem ICE-Neustart herausfiltert, können Sie dies selbst tun, wenn Sie versuchen möchten, die Anzahl der Nachrichten, die hin und her gesendet werden, absolut zu minimieren.

Zu diesem Zweck können Sie den Wert des usernameFragment mit dem aktuellen usernameFragment vergleichen, das für die Verbindung verwendet wird, nachdem Sie den Kandidaten vom Signalisierungsserver erhalten haben und bevor Sie addIceCandidate() aufrufen, um ihn zum Satz möglicher Kandidaten hinzuzufügen.

Wenn die Webanwendung eine Nachricht vom Signalisierungsserver erhält, die einen Kandidaten enthält, der der RTCPeerConnection hinzugefügt werden soll, können Sie (und sollten im Allgemeinen sollten) addIceCandidate() aufrufen. Es gibt normalerweise keinen Bedarf, sich manuell über die Filterung der Kandidaten Gedanken zu machen.

Stellen wir uns jedoch vor, dass wir den Datenverkehr minimieren müssen. Die folgende Funktion, ssNewCandidate(), wird aufgerufen, wenn eine Nachricht, signalMsg, vom Signalisierungsserver eintrifft, die einen ICE-Kandidaten enthält, der der RTCPeerConnection hinzugefügt werden soll. Um zu vermeiden, dass Kandidaten aufgenommen werden, die durch einen ICE-Neustart obsolet geworden sind, können wir Code wie diesen verwenden:

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

Dies durchläuft die Liste der RTCRtpReceiver-Objekte, die verwendet werden, um ICE-Daten zu empfangen, und prüft, ob das im Kandidaten angegebene usernameFragment mit einem von ihnen übereinstimmt. Wenn dies der Fall ist, bricht ssNewCandidate() ab. Andernfalls fügt es den neuen Kandidaten der Verbindung hinzu, nachdem es jeden Empfänger überprüft hat.