Кратко

  • RFC 5372 позволяет базовым получателям RFC 5371 игнорировать расширенную семантику полей, поэтому участники одного multicast-потока могут законно иметь разные возможности и разные журналы наблюдений.
  • Расширенный получатель использует семь активных значений mh_id. Если он пропустит шесть последовательных изменений main header, новое значение может совпасть со старым cache при ином содержимом.
  • Отчёт о восстановлении должен разделять capability, SDP-согласование, полный header, переходы идентификатора, решение о компенсации, проверку decoder и фактический вывод. Сравнивать получателей без этого контекста нельзя.

Совместимость сохранила поток, но не единый взгляд на него

Расширение полезно только тогда, когда оно не превращает каждого прежнего участника в неисправного. RFC 5372 строится поверх RTP payload format для JPEG 2000 и использует поля, которые базовая реализация может не интерпретировать как новый контракт. Это позволяет источнику работать с неоднородной группой.

Совместимость, однако, имеет наблюдательную цену. Расширенный получатель понимает режим main-header compensation, сохраняет последнюю полную главную заголовочную часть и сравнивает mh_id. Базовый получатель может проигнорировать эту логику и декодировать только то, что получил полностью. Их outcomes нельзя свести к одной колонке receiver success без описания capability.

Представим потерю main header при сохранённом image data. Один получатель имеет подходящий cache и предпринимает компенсацию. Второй такого cache по контракту не создавал и отклоняет кадр. Первый позже выдаёт изображение. Это не обязательно означает, что его сеть была лучше. Различие возникло на уровне реализованной функции.

В другом случае первый применяет устаревший header после rollover и получает ошибку decoder, а базовый участник сразу отказывается от неполного кадра. Простая метрика может назвать второго менее надёжным из-за большего числа ранних отказов, хотя он не внёс старое состояние в decoder. Без этапов решения сравнение переворачивает смысл.

Поэтому inventory возможностей — часть доказательства. Нужны версия реализации, поддерживаемые режимы, результат SDP offer/answer, выбранные параметры, SSRC и момент изменения конфигурации. Факт нахождения адресата в multicast-группе сам по себе ничего не говорит о том, какую семантику он применил.

Переговоры определяют словарь, а не результат

SDP сообщает сторонам, как интерпретировать payload. Для main-header compensation используется договорённость о поддержке механизма, а для priority — выбранный способ отображения значений. Успешный offer/answer создаёт общий словарь.

Но словарь не создаёт объект. После согласования ещё должен прийти полный main header. Его фрагменты должны быть собраны без дыр, отнесены к правильной RTP-сессии и источнику, связаны с sequence number и сохранены. Только тогда расширенный получатель имеет локальное состояние для будущей попытки.

Отсюда следуют разные receipts. Capability receipt говорит, что software умеет функцию. Negotiation receipt говорит, что стороны выбрали её для сессии. Header receipt говорит, что конкретные байты пришли полностью. Cache receipt говорит, что получатель сохранил их в конкретном состоянии. Match receipt фиксирует равенство коротких значений. Ни один из них не является decoder receipt или display receipt.

В операционной системе эти статусы часто сжимаются. Если mhc=1, панель рисует «recovery active». Если mh_id совпал, она рисует «recovered». Такое упрощение скрывает отсутствие полного header, локальный отказ хранения, rollover и позднюю ошибку decoder.

Особенно важно сохранять отрицательные факты. Базовый получатель не обязан сообщать cache miss, потому что cache-механизм не входил в его решение. Отсутствующее поле telemetry здесь означает «не наблюдалось этим типом участника», а не «произошёл нулевой результат».

Семь активных значений описывают ближайшую историю

mh_id занимает три бита, но ноль отключает сохранение и компенсацию. Активный цикл использует значения от одного до семи. Пока определённые параметры кодирования не меняются, sender сохраняет значение. При изменении и передаче нового main header он переходит к следующему.

Такой механизм экономичен. Последовательные JPEG-2000-кадры часто имеют одинаковые параметры, и повторный header может безопасно заменить потерянный. Но идентификатор не является digest. RFC 5372 прямо говорит, что между ним и параметрами нет отношения один к одному.

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

Если пропущены шесть последовательных обновлений main header, sender снова приходит к прежнему номеру. Старый cache и новое поле совпадают, хотя параметры могут отличаться. RFC описывает это в security considerations и допускает как случайную потерю, так и преднамеренное подавление.

В multicast разные получатели теряют разные подмножества пакетов. Один видит все переходы, второй пропускает один, третий — шесть. Поэтому consensus по видимому mh_id не гарантирует общий cache. Даже когда два адресата сообщают «1», их сохранённые header fingerprints и история могут различаться.

Полное содержимое не следует из последнего пакета

Main header может быть фрагментирован по нескольким RTP-пакетам согласно базовому формату RFC 5371. Fragment offset задаёт абсолютное положение payload в JPEG-2000-codestream. Marker сообщает границу передаваемой единицы. Ни один сигнал по отдельности не доказывает отсутствие промежуточной дыры.

Перед сохранением получатель должен установить, что все необходимые интервалы header присутствуют. Иначе частичный объект получит авторитет «последнего полного». При следующей потере система применит его как основание компенсации и ошибку ошибочно припишет decoder.

Полезная запись содержит множество покрытых диапазонов, sequence context, MHF и другие применимые флаги, фактические bytes или стабильный fingerprint. Она также связывает объект с сессией и SSRC. Значение mh_id=4 из другого источника не сопоставимо только потому, что число одинаково.

Когда приходит новый полный header с другой активной идентификацией, RFC рекомендует удалить старый и сохранить новый. Для рабочего cache это однозначно. Для аудита нужно дополнительно сохранить факт замены: прежний fingerprint, новый fingerprint, доказательство полноты и причину перехода.

Так можно отличить нормальную эволюцию от очистки после ошибки. Оба события уменьшают содержимое cache, но имеют разный операционный смысл. Если они попадают в один счётчик eviction, команда теряет сигнал о нарушении согласованности.

Ноль обозначает отказ от shortcut

mh_id=0 не следует включать в обычный кольцевой счётчик. Эта величина сообщает, что main-header compensation не используется. Получатель не должен сохранять header для этой цели и не должен восполнять отсутствующий.

В неоднородной группе ноль может появиться из-за режима источника, профиля совместимости или изменения конфигурации. Его рост не доказывает network loss. Нужно смотреть negotiation и capability каждого участника.

Переход через период нулей также разрывает простую историю cache. Даже если старые bytes физически остались в памяти, их полномочие не возобновляется автоматически с появлением единицы. Услуга должна явно решить, требует ли она свежий полный header после повторного включения.

Этот выбор может быть локально строже минимального механизма. Главное — не выдавать его за требование стандарта и не скрывать в безымянном fallback. Policy receipt должен сообщать, почему старое состояние было отклонено или принято.

Priority ноль не уравнивает транспортные условия

Расширение RFC 5372 назначает смысл priority-полю. В зависимости от режима оно помогает ранжировать main header, tile-part header и packet data по progression order, layer, resolution или component. Значение ноль обозначает наиболее важный материал.

Это всё ещё описание важности, а не квитанция о доставке. Маршрутизатор или локальная очередь может вообще не знать об этом поле. Между объявлением и результатом находятся mapping, scheduler, congestion и конкретный path.

В multicast различия могут быть ещё шире: ветви дерева испытывают разную потерю и задержку. Один получатель получает priority-zero header, другой теряет его. Общая передача источника не превращается в общий delivery receipt.

Оператор должен хранить выбранную таблицу priority и измерять фактическое обращение на каждом наблюдаемом участке. Если высокоприоритетные единицы теряются так же, как остальные, заявленная важность не реализована. Если они доставлены, а decoder всё равно не согласен, причина находится не в очереди, а в содержимом, cache или codestream.

Защищённые пакеты не закрывают невидимые интервалы

SRTP может обеспечивать конфиденциальность, целостность и аутентификацию источника в пределах своего security context. IPsec способен защищать сетевой слой. Такие механизмы необходимы там, где требуется противодействие изменению или подмене.

Они не создают пакеты, которые были потеряны. Успешная проверка всех полученных сообщений не подтверждает, что между ними не было шести header transitions. Криптография отвечает за наблюдаемый материал, а continuity — за покрытие нужной последовательности.

Эти вопросы следует показывать рядом, но не объединять. Packet-auth status может быть зелёным, transition coverage — неопределённым, decoder outcome — красным. Сведение их к «secure stream» лишает каждый сигнал полезной границы.

Также нельзя избирательную потерю автоматически называть атакой. Она создаёт модель, совместимую с атакой, особенно если концентрируется на header updates. Для атрибуции нужны дополнительные данные пути, времени и источника. Правильная система сохраняет неопределённость, не уменьшая серьёзность риска.

Decoder узнаёт о проблеме после применения cache

Если decoder обнаруживает несогласованность, RFC 5372 рекомендует очистить сохранённые mh_id и main header. Это предотвращает повторное использование подозрительного состояния. Но обнаружение происходит после того, как выбор уже повлиял на обработку.

Не всякая неправильная комбинация обязана завершиться явной ошибкой. Некоторые изменения могут оставить syntactically допустимый поток, но изменить смысл декодирования. Поэтому decoder accepted не равно image correct, а frame produced не равно frame displayed.

Для каждого адресата полезно регистрировать выбранный header fingerprint, основание match, начало decode, warning/error, очистку cache, результат frame и передачу приложению. Тогда поздняя защита остаётся поздней и не маскируется как предотвращение.

Версия decoder необходима для сравнения. После обновления один участник может обнаруживать больше несовместимостей, чем другой. Рост ошибок может означать лучшую видимость, а не худшее качество потока.

Матрица наблюдаемости для смешанной группы

Вместо единого статуса можно вести матрицу по участникам:

  • поддержка RFC 5372 и выбранный профиль;
  • результат SDP и время последнего изменения;
  • последний полный main header, его fingerprint и sequence range;
  • наблюдаемые переходы mh_id и неопределённые интервалы;
  • состояние ноль или активная компенсация;
  • фактическая обработка priority;
  • попытки компенсации и выбранный cache-объект;
  • decoder outcome, frame output и display evidence.

Матрица позволяет сравнивать только сопоставимые группы. Если базовый клиент чаще отклоняет кадры, это оценивается относительно его контракта. Если расширенный клиент чаще показывает кадры, нужно проверить, не скрывает ли агрегат повреждённый output.

Она же помогает локализовать проблему. Одновременный сбой многих расширенных получателей у одного перехода указывает на sender state или общий участок path. Ошибка одного устройства может быть локальным cache, ресурсным пределом или версией decoder. Разница между capability-классами может быть ожидаемой.

Отсутствие данных должно иметь причину: функция не поддерживается, событие не наблюдалось, telemetry недоступна или значение действительно нулевое. Эти состояния нельзя кодировать одним null, если от него зависят автоматические решения.