Кратко

  • RFC 3497 расширил порядковый номер RTP до 32 бит: при передаче несжатого HDTV со скоростью 1,485 Гбит/с обычные 16 бит оборачивались за 336 миллисекунд, расширенные — примерно за шесть часов.
  • Новый счётчик обнаруживал потери и перестановку, но не снижал постоянную скорость. В сети best effort получатель должен был покинуть сеанс, если сопоставимый поток TCP не мог получить такую же пропускную способность.

У получателя не было мягкой реакции. Он не мог попросить поток стать немного медленнее и затем продолжить просмотр. Если потери показывали, что фиксированный HDTV-трафик занял больше, чем в тех же условиях получил бы TCP, получатель обязан был выйти.

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

SMPTE 292M описывал последовательный студийный интерфейс для несжатого телевидения высокой чёткости между камерами, кодерами и записывающим оборудованием. Десятибитные слова шли со скоростью 1,485 Гбит/с либо 1,485/1.001 Гбит/с. Выделенный кабель соответствовал такой нагрузке. RFC 3497 перенёс сигнал в RTP ради дальней доставки по IP, но не объявил любой IP-маршрут эквивалентом студийного кабеля.

Одна строка SMPTE могла занимать несколько пакетов. Структуры начала активного видео SAV и конца EAV вместе с номером строки и CRC запрещалось разрывать, поскольку декодер находил по ним границы сканирования. За стандартным заголовком RTP следовал четырёхоктетный заголовок полезной нагрузки. Маркер отмечал конец кадра, а одиннадцатибитный номер строки сохранял контекст при потере пакета EAV.

Отдельной границей служила группа пикселей. Для 4:2:2 обычно требовалось пять октетов, для 4:2:0 и 4:4:4 — пятнадцать. pgroup=1 позволял деление на любой октетной границе, если исходное представление неизвестно, но не отменял защиту SAV и EAV. Тип video/SMPTE292M, обязательная частота и необязательный pgroup позволяли SDP описать взаимопонимание конечных систем.

Линейная скорость почти уничтожила полезность обычного номера RTP. При пакетах не меньше тысячи октетов 16 бит повторялись через 336 миллисекунд. Старый задержанный пакет становилось трудно отличить от нового. Дополнительные шестнадцать бит образовали 32-битную последовательность с горизонтом около шести часов. Потеря и изменение порядка стали наблюдаемыми на практическом интервале.

У потока были и более быстрые круги. Метка времени RTP с частотой 148,5 МГц оборачивалась за 21 секунду. Счётчик отправленных октетов RTCP — за 23, накопленная потеря — за 93. Приложение, которому нужны итоги от начала сеанса, должно было само считать обороты. Если мониторинг принимал оборот за сброс, протокол оставался исправен, а история исчезала.

Ни один из этих счётчиков не был регулятором нагрузки. RFC прямо называл поток постоянным, высокоскоростным и неуправляемым по перегрузке. Одни 1,485 Гбит/с без накладных расходов RTP могли вызвать отказ в обслуживании на большинстве доступных в 2003 году маршрутов. Поэтому использование следовало узко ограничить подходящими конечными системами, частными сетями либо сетями с настоящими гарантиями ресурсов и QoS.

Даже объявленная QoS не заменяла измерение. Получатель должен был следить за потерями и проверять, действительно ли заказанная услуга доставлена. Если факты противоречили обещанию, следовало считать сервис best effort. Имя услуги находилось в символическом слое; очередь, загрузка канала и пропускная способность конкурентов — в слое исполнения.

Для best effort потеря запускала обязательный выключатель. При слишком высоком уровне получатель покидал сеанс. Допустимость определялась через TCP: поток на том же пути и при тех же условиях должен был получить среднюю скорость не ниже RTP. Если это невозможно, фиксированный поток не разделял ресурс на условиях, доступных реагирующему трафику.

Так точная нумерация стала свидетелем необходимости отключения. Она не превратилась в окно перегрузки. RTP переносил данные, RTCP сообщал состояние, SDP описывал сеанс, IANA координировала параметры — ни одна из этих функций не создавала ёмкость.

Позднейшие RFC развили окружение. RFC 3550 обновил RTP, RFC 4175 расширил форматирование несжатого видео, RFC 8083 оформил мультимедийные выключатели, RFC 8085 дал общие правила UDP, а RFC 8888 — более богатую обратную связь. Они улучшили наблюдение и реакцию, но не сделали исторический поток RFC 3497 эластичным задним числом.

Цепочка квитанций должна храниться раздельно: SDP описан, пакет верен, граница строки цела, номер понят, время восстановлено, обороты RTCP учтены, QoS подтверждена нагрузкой, сравнение с TCP пройдено, изображение пригодно, сеть остаётся безопасной. Первые шесть пунктов могут быть истинны, когда последние четыре уже ложны.

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

Sources