RTCIceCandidate: свойство usernameFragment

Только для чтения usernameFragment свойство интерфейса RTCIceCandidate — это строка, указывающая фрагмент имени пользователя ("ufrag"), который однозначно идентифицирует сеанс взаимодействия ICE.

Это значение задаётся с помощью свойства usernameFragment в объекте опций candidateInfo, который передаётся конструктору RTCIceCandidate(). Если вы вызываете конструктор со строкой m-строки вместо объекта опций, значение usernameFragment извлекается из указанной строки кандидата m-строки.

Обратите внимание, что браузеру необходимо сгенерировать 24 бита фрагмента имени пользователя случайным образом. Подробности см. в разделе «Генерация случайных значений» ниже.

Строка, содержащая фрагмент имени пользователя (обычно сокращённо обозначается как «ufrag» или «ice-ufrag»), который вместе с паролем ICE («ice-pwd») однозначно идентифицирует текущее взаимодействие ICE, включая любые коммуникации с сервером STUN. Длина строки может достигать 256 символов, значение по умолчанию отсутствует.

Браузеру необходимо случайным образом выбрать по меньшей мере 24 бита текста в ufrag, в начале сессии ICE. Конкретные биты для случайного выбора и остальная часть текста ufrag остаются на усмотрение реализации браузера. Например, браузер может всегда использовать 24-символьный ufrag и случайным образом выбирать бит 4 каждого символа между 0 и 1. Другой пример: он может взять заданную пользователем строку и добавить к ней три 8-битных случайных байта в конец. Либо каждый символ может быть полностью случайным.

ICE использует usernameFragment и пароль для обеспечения целостности сообщений. Это позволяет избежать взаимных помех между несколькими активными сессиями ICE, но, что более важно, помогает защитить операции ICE (и весь WebRTC в целом) от атак, которые могут попытаться встроиться в обмен ICE.

usernameFragment и пароль меняются каждый раз при перезапуске ICE, как описано в статье о перезапуске ICE.

Хотя инфраструктура WebRTC отфильтрует устаревшие кандидаты для вас после перезапуска ICE, вы можете сделать это самостоятельно, если пытаетесь максимально сократить количество сообщений, передаваемых в обе стороны.

Для этого вы можете сравнить значение usernameFragment с текущим используемым usernameFragment для подключения после получения кандидата от сервера сигнализации и перед вызовом addIceCandidate() для добавления его в список возможных кандидатов.

Когда веб-приложение получает сообщение с сервера сигнализации, содержащее кандидата для добавления к RTCPeerConnection, вы можете (и, как правило, должны) вызвать addIceCandidate(). Обычно нет необходимости вручную фильтровать кандидатов.

Однако давайте представим, что нам нужно минимизировать трафик. Функция ниже, ssNewCandidate(), вызывается при поступлении сообщения signalMsg с сервера сигнализации, содержащего кандидата ICE для добавления к RTCPeerConnection. Чтобы избежать добавления устаревших кандидатов после перезапуска 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(window.reportError);
};

Этот код проходит по списку объектов RTCRtpReceiver, используемых для получения данных ICE, и проверяет, соответствует ли usernameFragment, указанное в кандидате, какому-либо из них. Если да, ssNewCandidate() прерывает выполнение. В противном случае, после проверки каждого приемника, новый кандидат добавляется к подключению.