Кратко

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

Система мониторинга увидела запрос обратной связи и не нашла отдельного ответа. Она подняла тревогу: приёмник «пропустил» управляющее сообщение. В трассе запрос действительно пришёл. Но до него уже был обработан запрос, привязанный к более новой Frame ID. Старый пакет задержался, затем был восстановлен или повторно передан и оказался последним только по времени доставки.

Приёмник сделал именно то, что защищает состояние от отката: учёл сведения о самом кадре, но не исполнил устаревшую просьбу.

Проект RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement прямо учитывает переупорядочивание, повторную передачу и восстановление FEC. Если запрос относится к текущей Frame ID, приёмник сохраняет состояние этой единицы. Однако он обрабатывает просьбу об обратной связи только тогда, когда ранее не был обработан запрос, связанный с более новой Frame ID. Иначе запрос игнорируется.

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

Рассматриваемая редакция 01 датирована 6 июля 2026 года и истекает 7 января 2027 года. Это активный рабочий Internet-Draft группы AVTCORE с предполагаемым статусом Informational. Datatracker показывает I-D Exists; у документа нет shepherd, ответственного Area Director, оценки IESG, номера RFC или завершённого назначения IANA. RTCP использует PT 205, а FMT остаётся TBD с предложением значения 12. Это проект механизма, а не свидетельство внедрения или совместимости.

Пять порядков вместо одной временной линии

Frame ID — 16-битное число, которое увеличивается на единицу для каждой отмеченной единицы в порядке отправки и после максимума переходит к нулю. Приёмник должен допускать любое начальное значение. RTP-расширение рекомендуется ставить на последний пакет кадра и запрещено повторять в пределах одной единицы.

Однако порядок Frame ID — только один из нескольких. Есть порядок доставки RTP-пакетов, порядок самих кадров, порядок прихода запросов, порядок окончания декодирования и граф ссылочных зависимостей. Они могут расходиться без нарушения протокола.

Сам «кадр» здесь означает декодируемую единицу битового потока, изменяющую состояние, на которое могут ссылаться последующие единицы. Это может быть полное изображение, не отображаемый кадр, независимый tile или slice. Поэтому номер не равен моменту показа.

FFR 00 несёт только идентификатор; 01 добавляет неявный запрос для текущей единицы; 10 задаёт независимые Feedback Start и Length; 11 зарезервирован. Ответ RTCP содержит флаг ресинхронизации R, начальную ID, восьмибитную длину и битовый вектор.

Один означает «получено и декодировано либо будет декодироваться». Для меньшей задержки приёмник может сообщить его до завершения, если гарантирует попытку. При последующей ошибке он обязан запросить ключевой кадр даже для сбрасываемого слоя. Ноль объединяет «не получено», «не декодировано» и «декодирование не планируется».

У каждого из этих фактов своя временная точка. Сортировка по одному timestamp коллектора уничтожает причинность.

Игнорирование — это тоже проверяемое решение

В хорошо устроенном журнале старый запрос не исчезает. Запись показывает: пакет прибыл; состояние связанной с ним Frame ID было принято; управляющая часть была отклонена как устаревшая; причиной стала уже обработанная более новая ID; отдельный ответ не требовался.

Такое представление отличает защиту от отката от потери, перегрузки или ошибки реализации. Метрика «запросы без ответа» без причины игнорирования будет систематически завышать отказ.

Важна и серийная арифметика. После 65535 следует 0, поэтому простое числовое сравнение способно назвать новое старым. Сравнение выполняется внутри эпохи пары SSRC. Если SSRC отправителя или получателя меняется, последовательность начинается заново и прежнее состояние удаляется. Одинаковое число из другой эпохи не участвует в том же отношении «старше — новее».

Вне смены SSRC произвольные сбросы и пробелы не допускаются. Наблюдение должно различать нормальный wrap, новую эпоху и реальную аномалию.

Отложенный ответ тоже может устареть

Правила времени и полосы RTCP способны задержать формирование ответа. Пока он ждёт, окно приёмника движется. Проект требует строить сообщение по состоянию в момент отправки, а не по снимку в момент запроса. Запрос 1–4 может получить только 3–4, если окно успело сдвинуться к 3–6.

Если до отправки старого ответа приходит новый запрос, приёмнику рекомендуется отказаться от прежнего и ответить только на последний. Это ещё один вид законного отсутствия ответа. Он предотвращает очередь устаревших сообщений, но означает, что факт приёма запроса не является бессрочным обещанием ответить на исходный диапазон.

Окно по умолчанию хранит 255 Frame ID и может согласовываться от 1 до 32767. Старые состояния удаляются FIFO. При частичном пересечении Start сдвигается к старейшему сохранённому состоянию; без пересечения возвращается нулевая длина. Это сообщает об утрате записи, а не о потере или успехе кадра.

Новый Feedback Start также неявно закрывает более старые состояния. Закрытие жизненного цикла не выдаёт им сертификат полного декодирования.

Ресинхронизация не отменяет порядок полномочий

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

Если она есть, следующую единицу следует кодировать от неё или иной ссылки, известной приёмнику. Если отправитель её уже вытеснил, следует создать ключевой кадр. Приёмная память и отправительский reference buffer — независимые источники.

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

resync-timeout в диапазоне 1–65535 мс задаёт порог голодания декодера для запуска запроса, но не срок успешного восстановления. status-window-size ограничивает приёмную память и число незакрытых ID, не гарантируя объём буфера отправителя.

Независимые цепочки и посредники усложняют «новее»

В одном SSRC могут чередоваться независимые simulcast-цепочки. Более поздняя ID в одной цепочке не доказывает состояние более ранней ID в другой. Диапазон и вектор нужны именно потому, что глобальный максимум недостаточен.

SFU или SFM способен переписывать Frame ID для непрерывности каждой нисходящей последовательности. Обычно он не должен подтверждать вверх, пока не подтвердили все активные получатели. Для этого нужны версия активного множества и родословная преобразований. Порядок на одной ноге нельзя без доказательства переносить на другую.

SDP-объявление расширения и rtcp-fb показывает способность говорить на этом языке. Оно не подтверждает обработку конкретного запроса, сохранение окна, декодирование или восстановление.

Минимальная модель управляющего времени

Разделение слоёв реальности у Heng Lu помогает не путать управляющий символ с исполнением. Frame ID, диапазон и битовый вектор — сообщения координации. Окно и reference buffers — изменяемое машинное состояние. Доставка, завершённое декодирование, отображение и опыт пользователя — последующие наблюдения.

Минимальная начальная спецификация должна хранить пару SSRC, эпоху, Frame ID, FFR, связанный диапазон, время прихода, серийный порядок запроса, решение обработать или игнорировать с причиной, время ответа, границы окна, точную семантику статуса, ссылки обоих концов и последующее действие.

Running-Code Primacy требует доставлять старые запросы после новых через reorder, retransmission и FEC; проводить 16-битный wrap; менять SSRC; сдвигать окно во время RTCP-задержки; ломать декодирование после положительного бита; переплетать цепочки и вытеснять sender reference. Проверка должна подтвердить, что состояние кадра сохраняется, но власть старой команды не оживает.

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

Sources