Кратко

  • RFC 3524 определил SRF, чтобы несколько медиастрок с идентификаторами mid могли запросить один общий поток резервирования.
  • Группа задавала желаемое отображение; допуск, политика, состояние классификатора и планировщика, refresh и воспроизведение оставались отдельными фактами.

Строка a=group:SRF 1 2 связывала два описания, например звук и видео, семантикой Single Reservation Flow. Удалённой стороне больше не приходилось угадывать, нужен один запрос ресурсов или два.

Но RFC 3524 с самого начала различал медиапотоки и потоки резервирования. Сеанс мог объединить всё, выделить каждому средству свой поток или смешать варианты. SRF выбирал связь, а не предоставлял полосу, маршрут или очередь.

Нормативные слова сохраняли границу. Строки внутри группы SHOULD отображаться в один поток, а внешние SHOULD NOT попадать туда. Группа могла состоять даже из одной медиастроки. Это правило построения следующего запроса, а не отчёт об установленном ресурсе.

Механизм группировки делал ссылки проверяемыми. Каждый mid должен быть уникальным в SDP-сеансе, а group перечислял имена в рамках конкретной семантики. Несуществующее имя не создаёт объект. RFC 5888 позже сохранил структуру. Неизвестные атрибуты SDP могут игнорироваться, поэтому корректная строка ещё не означает поддержку.

SRF требовался, когда удалённая сторона участвовала в резервировании. Если создатель SDP сам распределял ресурсы в обоих направлениях, он мог выбрать отображение локально. Без строки группы получатель примера свободно создавал два RSVP-сеанса.

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

RSVP оставлял много работы. Получатель отправлял Resv с flowspec желаемого QoS и filter spec для выбора пакетов. На каждом узле admission control проверял наличие ресурсов, а policy control — право запроса. Отказ любого теста не позволял установить состояние. Только после успеха настраивались классификатор и планировщик.

Установленное состояние было мягким. Сообщения Path и Resv периодически его обновляли. При изменении маршрута новое состояние строилось на другом пути, а старое истекало. SDP мог оставаться подлинным, когда резерва уже не было.

Даже ResvConf не давал гарантий: RFC 2205 допускал подтверждение, после которого приходит ошибка из-за конкурирующих запросов или слияния. Тем более ранняя строка SRF не могла служить квитанцией услуги.

RFC 3312 разделял текущий и желаемый статус QoS. Такое разделение нужно именно потому, что описание цели не создаёт состояние. SRF отвечал, какие медиа должны разделить попытку, но не подтверждал выполнение условия в обоих направлениях.

Угроза была практической. Добавив SRF-строки, атакующий мог заставить конечный узел открыть слишком много или мало потоков. Первое расходовало его ресурсы, второе ухудшало качество. Поэтому целостность SDP настоятельно рекомендовалась, а для SIP назывался S/MIME.

Целостность доказывает автора и отсутствие изменения инструкции. Она не создаёт ёмкость, не отменяет политику, не добавляет поддержку, не продлевает состояние и не доказывает показ видео. Реестр IANA тоже лишь закрепляет общий токен и не видит живую сеть.

Исторический вывод — не смешивать квитанции: валидный SDP, разрешённые mid, аутентифицированное намерение, выбранное отображение, отправленный запрос, допуск каждого узла, установленное состояние, refresh, классификация, пакеты и воспроизведённые медиа. Наличие SRF относится только к началу цепочки.

Источники