Кратко

  • 10 сентября IESG одобрила сообщения запроса и уведомления о временно-пространственном разрешении как Proposed Standard. На момент проверки версия 17 оставалась Internet-Draft без окончательного номера RFC, а работа IANA продолжалась.
  • Получатель запрашивает частоту кадров, ширину и высоту; отправитель сообщает выбранные им будущие значения. Возможности кодера, записанный материал, несколько участников, локальная политика и перегрузка способны изменить результат.
  • TSRR и TSRN подтверждают обмен управляющими сообщениями. Они не измеряют доставленное изображение, энергию получателя, время работы батареи или качество. Для заявления об экономии нужна отдельная цепочка до наблюдаемого эффекта.

Решение IETF не измеряет работу устройства

В объявлении IESG от 10 сентября документ RTP Control Protocol Messages for Temporal-Spatial Resolution одобрен как Proposed Standard. Текущая карточка Datatracker фиксировала отправку объявления, но всё ещё показывала активный Internet-Draft версии 17 и незавершённую работу IANA. Решение уже состоялось; окончательный номер RFC и законченные записи реестра на дату отсечения ещё нельзя было утверждать.

Материалы к одобрению показывают происхождение консенсуса. Первый Working Group Last Call 2024 года не собрал достаточно откликов, чтобы объявить консенсус. После дополнительных рецензий прошёл второй этап, и только затем был сделан вывод о хорошем согласии. Это не основание принижать документ. Это наблюдаемая процедура, на которой стоит институциональное решение.

Практическая задача возникает между двумя устройствами. Декодер знает, что батарея разряжается или вычислительных ресурсов не хватает. Удалённый кодер управляет кадрами и размером изображения. Спецификация добавляет узкий обмен в архитектуру обратной связи RFC 4585 и управления кодеком RFC 5104. Общим становится язык запроса, а не конечный энергетический результат.

TSRR выражает ограниченную просьбу

Версия 17 определяет Temporal-Spatial Resolution Request. TSRR указывает целевой источник медиа, номер последовательности, число кадров в секунду, ширину и высоту. Нулевые значения запрещены, а запрос не должен превышать пределы, согласованные через SDP.

Получатель предлагает параметры. Отправитель, если умеет менять кодирование, может учесть их для будущих кадров. Затем он обязан послать TSRN — уведомление о том, какие значения будет использовать в результате запроса. Эти числа могут не совпадать с просьбой.

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

Поддержка также требует согласия обеих сторон. Если предложение SDP содержит tsrr, а ответ его не сохраняет, механизм в сеансе не согласован. Операционный раздел прямо говорит, что реализация только на одном конце не изменит RTP-сервис. Наличие кода, переговоры, получение TSRR, отправка TSRN и изменение видео — разные этапы.

TSRN фиксирует выбор, а не доставку

Уведомление полезно: оно связано с исходным запросом номером последовательности, подтверждает получение для каждого участника и сообщает намеченные частоту кадров и размеры. Повторные и множественные запросы обрабатываются по заданным правилам.

Но формулировка относится к параметрам, которые отправитель будет применять. Это не выборка потока на стороне получателя. После уведомления могут вмешаться микшер, транслятор, перегрузка или новая конфигурация. Поля также не содержат ватт, джоулей, остатка батареи, загрузки процессора или выбросов.

Даже одинаковое разрешение имеет разную энергетическую цену на разных кодеках, ускорителях, экранах и фоновых нагрузках. Контекст эффективности задаёт ISO/IEC 23001-11:2023, Energy Efficient Media Consumption. Работа IETF переносит часть обратной связи из этого контекста, но не превращается в полную методику измерения энергии.

Нужна последовательность без ложных равенств:

запрос TSRR → выбор TSRN → наблюдаемый поток → измеренная энергия → баланс качества.

Наличие первых двух звеньев не доказывает последние три.

Качество нельзя списать как внешний эффект

Проект предупреждает: выполнение неудачной рекомендации может ухудшить пользовательский опыт и вызвать жалобы. Операторам предлагается калибровать допустимые диапазоны и учитывать механизм в обеспечении SLA. Снижение разрешения может помочь завершить звонок, но также сделать текст нечитаемым, затронуть доступность или вынудить пользователя повторить сеанс.

В групповой связи участник с ограниченной батареей и участник, которому нужна детализация, могут быть разными людьми. Микшер сопоставляет их интересы. Финальные три числа в TSRN сами по себе не объясняют, чья потребность победила, какая версия политики сработала и существовало ли исключение.

Стандарту не нужно централизовать эту политику. Минимальная координация оставляет решение сервису. Но локальный выбор должен сохранять владельца, основание, последствия и путь отмены.

Аутентификация не легитимирует цель

Поддельный запрос способен резко снизить частоту или размеры, попытаться выйти за согласованные пределы либо создать чрезмерную нагрузку частыми сообщениями. Документ требует учитывать аутентификацию и целостность, ссылается на защищённый профиль RFC 5124 и рекомендует осторожность при необычном поведении.

Криптография подтверждает источник в защищённом контексте и отсутствие изменений в пути. Она не подтверждает точность оценки батареи, полномочия просителя влиять на качество других или фактическую экономию. Аутентифицированный плохой совет остаётся плохим.

Решение о внедрении включает и права. Раскрытие Qualcomm IPR 5764 относится к предшествующему проекту и заявляет разумную недискриминационную лицензию с возможной выплатой. Раскрытие InterDigital IPR 6159 связано с ранними версиями проекта рабочей группы и выражает готовность к разумным, взаимным и недискриминационным переговорам на описанных условиях. Это уведомления для проверки, а не решения IETF о действительности, существенности, нарушении, цене или необходимости лицензии.

Цепочка доказательств изменения разрешения

Сервису, который заявляет экономию, нужна ограниченная по персональным данным цепочка доказательств изменения разрешения. В начале фиксируются версии двух сторон, согласование tsrr и защищённый контекст. Затем — роли запрашивающего и цели, последовательность, время, желаемые кадры, ширина и высота.

Блок решения называет отправителя или микшер, версию политики, допустимый диапазон и правило объединения требований. TSRN хранится как объявленная будущая конфигурация. Отдельное наблюдение показывает реально доставленные частоту, размеры и битрейт за определённое окно.

Если сделано энергетическое заявление, добавляются устройство, путь декодирования, ускорение, экран, параллельная нагрузка, базовый режим, единица, длительность и неопределённость. Рядом находятся зависания, читаемость, доступность, жалобы, ручная отмена, откат и исправление. В публичной части убираются личности, секреты сеанса и опасные пороги; защищённые данные остаются для эксплуатации и спора.

Это моя редакционная модель, а не требование IETF, ISO, IANA или правообладателей. Она применяет дисциплину Heng Lu из The Policy Mirror: кто уполномочен решать и какое свидетельство поддерживает состояние. Minimum Initial Specification показывает, как узкий общий сигнал сочетается с добровольным локальным внедрением. Why BTW Media Exists требует не подменять наблюдаемую работу институциональным намерением.

TSRR делает потребность получателя видимой. TSRN делает ответ отправителя проверяемым. Экономию энергии всё равно приходится доказывать после них.

Sources

  1. Объявление о действии IETF
  2. Карточка IETF Datatracker
  3. Internet-Draft, версия 17
  4. Материалы к одобрению
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. Раскрытие IPR 5764
  9. Раскрытие IPR 6159
  10. ISO/IEC 23001-11:2023
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists