Кратко

  • Номер последовательности RTP показывает порядок отправленных пакетов, а метка времени помещает медиа на шкалу часов дискретизации или воспроизведения данного формата. Ни одно поле само по себе не доказывает абсолютное время отправки.
  • Для согласования потоков отчёт отправителя RTCP периодически сопоставляет счётчик RTP с опорным значением в формате NTP. Доказательством общего времени служит это соответствие, а не внешнее сходство чисел.

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

RTP подписан Henning Schulzrinne, Stephen Casner, Ron Frederick и Van Jacobson. RFC 1889 вышел в 1996 году, а RFC 3550 заменил его в 2003-м. Information Sciences Institute при USC называет Casner руководителем разработки и стандартизации RTP. Поэтому он — герой профиля, но не единственный изобретатель коллективного протокола.

Пакеты и медиа движутся по разным осям

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

Метка времени следует другим часам. Их частота определяется форматом полезной нагрузки. В аудио с постоянной частотой блок из 160 периодов дискретизации увеличивает счётчик на 160. Это происходит и тогда, когда блок содержит тишину и не отправляется. Линия медиа проходит этот интервал без пакета в сети.

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

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

Начальная метка тоже случайна. Для перевода разницы в секунды нужна частота. Для указания источника нужен SSRC. Для сравнения с другим потоком нужно отображение на общую шкалу. Изолированное 32-битное число не содержит этих условий.

Звук и изображение нельзя совместить простым вычитанием

Микрофон и камера способны зафиксировать один физический момент, но получить несхожие значения RTP. У потоков разные частоты и независимые случайные смещения. RFC 3550 прямо говорит: непосредственное сравнение меток разных медиа не подходит для синхронизации.

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

Мост появляется в RTCP Sender Report. В отчёте рядом стоят опорная метка в формате NTP и значение RTP, относящиеся к одному моменту. Пара задаёт отношение локального счётчика к опорным часам. Звук и видео получают отдельные отображения, после чего их можно разместить на общей шкале.

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

Формат NTP не гарантирует UTC. RFC 3550 разрешает системе без абсолютного времени использовать общие относительные часы, например время работы. Если неизвестно ни гражданское, ни прошедшее время, отправитель может записать ноль. Формат определяет представление, но не подтверждает источник и точность.

RFC 7273 позднее снова назвал пару NTP/RTP отображением и напомнил: синхронное воспроизведение нескольких источников зависит от синхронизированных опорных значений. Отчёт сохраняет отношение, но не делает сами часы верными.

От пакетной речи к аккуратной грамматике времени

Casner пришёл к этой задаче через пакетную речь в ARPANET. ISI описывает работу, где непрерывный звук требовалось сжать, разрезать под узкую полосу и собрать на приёмной стороне. Затем появились пакетное видео, MBONE и руководство стандартизацией RTP. Мемориальная страница института связывает протокол с Network Voice Protocol и Packet Video Protocol.

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

Редакция 2003 года не изменила форматы пакетов на линии. Главным изменением RFC 3550 называет масштабируемый таймер RTCP для одновременного входа множества участников. Значение метки не расширили; сделали устойчивее ритм поступления контрольных свидетельств.

Вместе с числом нужно хранить домен часов

Полезная запись содержит SSRC, формат нагрузки, частоту, номер последовательности, метку RTP, время наблюдения и ближайшие допустимые пары RTP/NTP. Если опора была относительной или нулевой, это тоже часть квитанции.

Тогда признаки не сливаются. Пробел последовательности указывает на возможную потерю. Разрыв медиа-счётчика может сопровождать перезапуск, смену формата или скачок воспроизведения. Старый Sender Report увеличивает неопределённость отображения. Лишь после переноса на общую шкалу растущая разница потоков становится основанием говорить о дрейфе.

Без контекста панель подставляет скрытые предположения: делит все значения на 90 000, сортирует передачу по времени дискретизации, вычитает случайные смещения или печатает относительное NTP как UTC. Число вычислено, но факт не доказан.

Работа Casner оставляет правило для любой телеметрии: удобное имя не расширяет полномочия поля. Сохраняйте домен и прикладывайте явное отображение к каждому переходу к более широкому выводу.

Источники