Кратко

  • RFC 3158 связал преобразование RTP-медиа с преобразованием доказательств RTCP. Смена кодирования, пакетизации, последовательности или частоты timestamp требовала соответствующих поправок в счётчиках, времени и отчётах приёма.
  • Получатель наблюдал выходное пространство номеров, а его отчёт шёл обратно против движения медиа. Если осмысленной обратной проекции не существовало, явное отсутствие или локальный синтетический отчёт были точнее формально правильных чисел о другой последовательности.
  • Методика ограничила собственный вывод: она выявляла типичные ошибки и показывала совместимость в выбранных опытах, но её прохождение не удостоверяло полное соответствие RTP, безопасность, производственное качество или опыт человека.

Поток мог работать, а его описание — нет

Источник отправляет два RTP-пакета. Транслятор перекодирует их и объединяет в один для узкого канала. Получатель декодирует выход и показывает кадр. Если смотреть только на изображение, преобразование успешно.

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

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

Поэтому RFC 3158 проверял не только воспроизведение. Изменения payload type, timestamp, sequence number, padding и marker должны были отражаться в управляющей информации. RTCP был кратким свидетельством о потоке, а не служебным украшением.

Испытательный прибор занял третью точку наблюдения

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

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

Третий наблюдатель всё равно видел только своё место и сценарий. RFC 3158 сразу предупредил: набор не исчерпывающий, а успех не обязательно означает соответствие полной спецификации RTP.

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

RTP переносил медиа, RTCP описывал наблюдение

Sender Report связывал SSRC, время NTP, RTP timestamp, количество пакетов и октетов. Receiver Report сообщал потери, наибольший расширенный sequence number, jitter, последний SR и задержку после него.

У каждого поля были координаты. Timestamp без частоты не имел общей шкалы; номер без пространства последовательности не был глобальной позицией; потеря без участка и знаменателя не была сквозным свойством.

RFC 3158 проверял согласованность: SSRC и время относительно медиа, счётчики относительно фактической отправки, потери относительно контролируемого ухудшения. Сам факт своевременного отчёта не доказывал, что он описывает правильную историю.

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

Один SSRC не сохранял единицы измерения

Транслятор сохранял источники раздельными и оставлял их SSRC. Mixer объединял потоки, создавал собственную временную линию и SSRC, при необходимости указывая вклад источников как CSRC.

При стабильном SSRC транслятор всё же мог менять кодирование и объём байтов, payload type, frame rate, частоту timestamp, объединение и деление пакетов, sequence numbers, padding, шифрование и marker. Непрерывность источника и непрерывность измерения были разными утверждениями.

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

Каждое преобразование создавало встречную обязанность

RFC 3158 перечислил пары. Смена кодирования требовала изменить octet count в SR. Объединение нескольких пакетов — packet count. Новая частота дискретизации — RTP timestamp в отчёте отправителя.

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

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

Один потерянный выход мог содержать несколько входов; один потерянный фрагмент — лишь часть исходного пакета. Формула «потерян один пакет» меняла знаменатель на границе.

Умение создать выход не гарантировало обратного объяснения

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

RFC 3550 сделал правило нормативным: транслятор, меняющий payload, обязан соответственно изменить SR и RR и не должен просто пересылать их. Одновременно документ признал, что обратная обработка может быть сложной или вовсе не иметь осмысленного результата.

Право создать пригодный поток не давало способности приписать каждую downstream-потерю конкретной upstream-единице. Граница знания должна была остаться видимой.

Честный пробел был лучше вымышленной точности

RFC 3158 допускал удалить блоки приёма и отправить пустые SR/RR, когда разумного перевода нет. RFC 3550 различил отсутствие отчёта и синтетический отчёт на основе собственного приёма транслятора.

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

Заполнение всех полей ради полноты заменило бы смысл красивой формой. Пробел сохранял границы остальных сведений. Свобода выбрать подходящий метод не разрешала скрыть происхождение.

Репликация, перевод и смешивание были разными ролями

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

Payload-транслятор сохранял источники, но перестраивал отчёты. Если он сообщал о собственном приёме, метрика принадлежала его точке. Mixer создавал новый источник и не мог перенести отчёты об исходных SSRC в другой домен так, будто они оставались там источниками.

Даже агрегация отчётов меняла смысл. RFC 3550 обычно не рекомендовал объединять SR/RR разных источников, поскольку LSR и DLSR участвовали в оценке задержки. Не меняя поля, посредник мог изменить измерение временем и упаковкой.

Криптографическая целостность не проверяла смысл проекции

SRTP и SRTCP позднее защитили медиа и управление от изменения и replay в заданных контекстах. Они не проверяли карту последовательностей транслятора.

Подлинный отчёт мог быть синтетическим. Целый отчёт мог описывать точку транслятора, а не получателя. Аутентификация доказывала автора и защищённые байты; она не расширяла его наблюдения.

Проверка безопасности была отдельной квитанцией. Подписанная локальная метрика не становилась из-за подписи сквозной истиной.

Испытательный текст тоже нуждался в проверке

Раздел о случайности SSRC назвал процедуру приблизительной. Он указал 2 500 выборок в 25 корзинах, а затем ожидание 40 в каждой; прямое деление даёт 100. Зафиксированный для исследования поиск errata RFC Editor не показывает записи для RFC 3158.

Это не официальный erratum и не опровержение RTP. Это причина хранить параметры и независимо проверять арифметику. RFC 2762 объяснял значение равномерного распределения для выборки участников, но ограниченный тест не доказывал идеальные 32 бита случайности.

То же правило относилось к трансляции: утверждать только выполненные случаи и не превращать отсутствие найденной ошибки во всеобщий охват.

Больше метрик не отменяло происхождение

RFC 3611 расширил RTCP Extended Reports, RFC 7667 описал топологии, RFC 3551 связал payload, clock и marker с профилем, а RFC 3711 защитил обмен.

Ни один документ не сделал наблюдателя вездесущим. У метрики оставались автор, интервал, популяция, sequence space и место. Значение после преобразования не становилось значением до него благодаря более богатому формату.

Долговечная запись соединяет входной захват, правило и версию, карту пакетов, выход, изменение SR, обратный перевод RR или причину отсутствия, источник синтетического отчёта, криптографическую проверку, декодирование, воспроизведение и результат приложения.

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

Источники