Кратко

  • RFC 3407 позволял объявить форматы, которые конечная точка сейчас могла и хотела поддержать, не делая их конфигурацией сеанса.
  • Объявление, выбор через offer/answer и реально работающий медиапоток были разными свидетельствами.

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

RFC 3407 добавил минимальные обратно совместимые атрибуты. Старые получатели могли их пропустить. Описание возможности находилось рядом с реальной конфигурацией, но ничего не выбирало. Для использования требовался внешний процесс, например offer/answer.

Стандарт запретил считать объявленный формат гарантией будущего успеха. Другая сторона могла отказаться, ресурсы — измениться, параметры — не совпасть, сочетание — оказаться невозможным. Возможность давала основание попробовать.

Набор был полным и временным. Один номер последовательности охватывал все описания; новый набор отменял старый. Получатель мог пропустить обновления, поэтому разрыв счётчика по модулю 256 не был основанием для отказа. Номер отмечал эпоху, а не безошибочную доставку.

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

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

Номера возможностей были локальными ссылками внутри текущего набора. Пропуски допускались. Внешний механизм мог ссылаться на них, но RFC 3407 не превращал ссылку в согласие.

Для чувствительных параметров повторные переговоры без аутентификации создавали угрозу понижения защиты и отказа в обслуживании. Наличие слабого варианта не означало полномочия выбрать его.

RFC 5939 позже определил возможности, потенциальные и фактические конфигурации и процедуры offer/answer. Он рекомендовал новый каркас, разрешал оба описания для совместимости и формально не отменял RFC 3407. Его переговоры не использовали старые описания.

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

Источники