Кратко

  • RFC 8445 объединяет локальные и удалённые транспортные адреса в пары, проверяет их STUN-транзакциями и поручает controlling agent номинировать одну допустимую пару. Когда номинация есть для нужных компонентов, пары становятся выбранными; это итог выбора пути, а не всей сессии.
  • RFC 7675 обновляет согласие на передачу для одного 5-tuple. RFC 8838 закрывает поступление кандидатов в текущем поколении. Ни одно из этих событий само по себе не доказывает человека, авторизацию, декодирование, воспроизведение или завершение задачи.

После смены мобильной сети журнал показывает новую selected candidate pair. Счётчик исходящих пакетов растёт, а на экране остаётся замерший кадр. Для сводного показателя это одна «подключённая» сессия. Для инженера это несколько разных вопросов, из которых ICE ответил лишь на один.

Какое сочетание локального и удалённого транспортных адресов выбрали для компонента? Это вопрос ICE. Прошла ли криптографическая стадия, был ли пакет принят, расшифрован, декодирован и показан, разрешило ли приложение участие и получил ли пользователь ожидаемый результат? Это другие механизмы и другие точки наблюдения.

Такое разделение заложено в RFC 8445. В авторах документа Standards Track указаны Ari Keränen, Christer Holmberg и Jonathan Rosenberg. Keränen стоит первым, но спецификация остаётся коллективной работой IETF. Публичный профиль, проверенный 30 августа 2026 года, перечисляет 21 RFC и текущие обязанности в T2TRG, Internet of Things Directorate и IRSG. Эти должности зависят от времени. Авторство и профиль не означают единоличного изобретения, контроля над продуктами или ответственности за конкретную сессию.

Точная граница не обесценивает протокол. Она превращает его состояние в полезное свидетельство.

Кандидат — предложение адреса

Кандидат ICE — транспортный адрес, который потенциально может принимать данные. Это может быть host address интерфейса, server-reflexive address, увиденный с внешней стороны NAT, или relayed address, выделенный TURN. Сбор создаёт список возможностей.

Один локальный и один удалённый кандидат образуют candidate pair. До проверки пара остаётся гипотезой: возможно ли отправить отсюда туда? Приоритет задаёт порядок и предпочтение, например в пользу более прямого пути, но не превращает предпочтение в достижимость.

Поэтому число кандидатов не равно числу работающих путей. Relay-кандидат не доказывает, что выбран TURN. Адрес после NAT не идентифицирует владельца устройства, пользователя или организацию. Сигнализация передаёт транспортные сведения, а не удостоверение личности.

Запись о сборе должна сохранять ICE generation, component, тип кандидата, transport address, base или related address, приоритет, источник и время поступления. ICE restart создаёт новое поколение. Если кандидаты разных поколений смешаны, расследование увидит набор альтернатив, которого не существовало в момент выбора.

Успешная проверка создаёт допустимую пару

Агенты формируют checklist и запускают connectivity checks. Проверка представляет собой STUN Binding request от локального кандидата к удалённому и соответствующий response. Адреса и порты совпадают с теми, которые предполагается использовать для данных, поэтому удачная транзакция имеет прямое отношение к пути.

Успех переводит одну или несколько пар в valid list. Запрос второго агента может вызвать triggered check и ускорить встречную проверку. Ответ также способен раскрыть новый peer-reflexive candidate.

Допустимая пара ещё не выбрана окончательно. Работать могут несколько пар, а кандидат с более высоким приоритетом — ещё не прибыть. Проверка отвечает, состоялся ли предусмотренный обмен STUN на этой комбинации. Какую комбинацию предпочесть, решает следующий этап.

Сила свидетельства не распространяется вверх автоматически. STUN-транзакция не подтверждает завершение DTLS, аутентификацию SRTP, расшифровку, работу codec, вывод звука или решение приложения о допуске.

Поле ice_connected стирает различия. Нет кандидатов, истёк STUN, есть valid pair без номинации, после выбора сломалась криптография, медиа расшифровано, но не показано — всё становится одной ошибкой. Удобный показатель лишает команду маршрута ремонта.

Номинация включает локальную политику

Один ICE agent принимает роль controlling, второй — controlled. Первый отвечает за финальный выбор. Он продолжает проверки до локального критерия остановки, выбирает пару из valid list и повторяет проверку с признаком номинации.

RFC 8445 требует в итоге выбрать ровно одну пару для компонента, но конкретные условия остановки и оценки оставляет локальной оптимизации. Это место продуктового решения. Можно ждать прямой путь, чтобы избежать TURN и лишнего посредника. Можно рано номинировать уже допустимый relay, если задержка установления дороже.

Controlled agent ждёт номинацию и при необходимости проверяет ту же пару. Если связанные транзакции успешны, агенты устанавливают nominated flag. Когда для всех требуемых компонентов есть nominated pair, они становятся selected pairs и используются для передачи данных этих компонентов.

Controlling — роль протокола, а не организационная власть. Она не даёт оператору одного endpoint полномочий над компанией или человеком на другом конце. Номинация также не является согласием пользователя или решением приложения о доступе.

Аудит должен хранить распределение ролей, разрешение возможного конфликта, valid list на момент решения, версию политики, транзакцию номинации и момент установки. Если остаётся только победитель, уже нельзя понять, победил ли он по приоритету, скорости или отсутствию выбора.

Данные могут появиться до окончательного выбора

RFC 8445 допускает использование любой valid pair компонента до появления selected pairs. Следовательно, событие выбора не обязательно предшествует первому пакету приложения. Временный путь мог уже нести данные, а затем не стать окончательным.

Ранний трафик не доказывает завершённый выбор. И selected pair не доказывает, что после неё прошли полезные данные. Телеметрия должна отдельно показывать временное использование valid pair, номинацию, установку selected pair и смену пути после restart.

Даже «медиа пошло» — не один факт. Отправка не равна доставке. Доставка не равна аутентификации. Аутентификация не равна расшифровке. Расшифровка не равна декодированию. Декодирование не равно воспроизведению. Воспроизведение ещё не доказывает, что человек понял сообщение или завершил нужное действие.

Узкое значение selected pair делает событие сильнее в диагностике. Оно закрывает вопрос о выборе транспорта и указывает, какое следующее свидетельство отсутствует.

Согласие принадлежит одному 5-tuple

Выбор пути не создаёт вечного разрешения. RFC 7675 поддерживает consent freshness новыми STUN-транзакциями. Авторы документа — Matthew Perumal, Dan Wing, Rohan Ravindranath, Tirumaleswar Reddy и Martin Thomson. Ari Keränen среди них нет; это последующее дополнение с отдельной атрибуцией.

Consent to send действует для одного 5-tuple. Удалённый endpoint продолжает разрешать non-ICE traffic на конкретную комбинацию адресов, портов и протокола. Спецификация называет это согласием уровня приложения без участия человека. Это не нажатие кнопки пользователем и не общая лицензия на все пути сессии.

Keepalive для NAT недостаточен. STUN Indication, на которую не ждут ответа, поддерживает mapping, но не доказывает разрешение. Freshness требует соответствующего аутентифицированного Binding response. После истечения срока endpoint обязан прекратить передачу на этом tuple и получить согласие заново до возобновления.

Реакция приложения находится вне RFC 7675. Оно может перезапустить ICE, показать reconnecting или завершить сессию. Истечение объясняет обязательную остановку отправки на пути, но не диагностирует codec и не доказывает отсутствие человека.

Запись должна привязывать согласие к точным паре и 5-tuple, хранить transaction ID, последний корректный ответ, срок и фактическую остановку. Сессионное consent=true может в журнале передать новому пути разрешение, которое было выдано только старому.

Конец кандидатов закрывает вход

RFC 8838, написанный Emil Ivov, Justin Uberti и Philipp Hancke, разрешает Trickle ICE. Кандидаты поступают постепенно, а проверки начинаются до завершения сбора. Это уменьшает задержку, но по паузе нельзя понять, будут ли ещё варианты.

End-of-candidates indication закрывает вход для конкретных поколения и data stream. Агент сообщает, что сбор закончен либо остановлен после приемлемого времени. После этого он не может добавлять кандидатов в ту же ICE session; новый набор требует restart.

Закрытие позволяет признать checklist неудачным, если valid pair нет. Оно также прекращает ожидание более предпочтительного прямого пути, когда работает только relay.

Но закрытие входа не выбирает выход. RFC 8838 сохраняет обычную номинацию. После end-of-candidates controlling agent всё ещё должен выбрать pair. И наоборот, nominated pairs могут позволить закончить ICE до всех сигналов окончания.

Gathered, checked, valid, nominated, selected, consented, transported, authenticated, decoded, rendered и completed — связанные, но разные глаголы. Надёжная система не превращает их в одно состояние.

Атрибуция Ari Keränen требует той же точности

Первое место среди трёх авторов RFC 8445 прямо подтверждает участие Keränen в коллективной спецификации. 21 RFC и текущие роли в профиле дают датированный контекст. Они не делают его автором RFC 7675 и RFC 8838, не подтверждают реализацию любого продукта и не превращают в оператора сети читателя.

Автор, консенсус IETF, разработчик, оператор и пользователь — разные действующие лица. Candidate, valid pair, selected pair, consent и итог приложения — разные свидетельства. Точность защищает смысл обоих рядов.

Пара кандидатов победила в выборе пути. Успех оставался отдельной работой.

Источники