Кратко

  • Строка o= в SDP соединяет устойчивый tuple идентичности с отдельным sess-version: новое описание может продолжать тот же сеанс.
  • Общий SDP требует повышать версию при изменении. Offer/Answer задаёт точнее: изменённый offer сохраняет остальной origin и прибавляет один, а повторённая версия несёт идентичный SDP.
  • Большее число помогает распознать старое описание, но не аутентифицирует отправителя, не принимает предложение и не доказывает согласие или доставку media.

Одному сеансу понадобились две координаты

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

SDP поместил оба ответа в origin:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Username, session ID, типы сети и адреса и origin-address образуют lineage. sess-version упорядочивает описания только внутри него. Сначала получатель проверяет весь tuple и лишь затем сравнивает версии. Одинаковый sess-id у разных origins не создаёт общего сеанса.

Origin не был удостоверением личности

Username может быть login, а может быть . Современная спецификация разрешает ради privacy произвольное имя и private origin-address, если полный tuple остаётся глобально уникальным.

Значит, строка origin — namespace описания, а не credential человека, компании или устройства. Её адрес не обязан быть адресом media. Рекомендуемый идентификатор в форме NTP timestamp уменьшает риск коллизии, но не подтверждает точность часов, момент создания или владение адресом.

Кто прислал текст, не изменился ли он по пути и вправе ли источник предлагать правку, определяет внешний signaling protocol.

Каждая сторона сама оценивала свежесть

После изменения создатель повышает sess-version. Получатель хранит origin, версию и fingerprint принятого текста, а затем не позволяет старой копии заменить новую.

Глобальный сервис версий не нужен. Но доказательство относительно: общий SDP требует роста, а не обязательного +1; timestamp-подобное число не становится гражданским временем; версии разных origins не имеют общей шкалы.

Полезная запись звучит не «увидел 42», а «в этом signaling context для этого origin tuple получил именно эти байты как версию 42 и принял такое локальное решение».

Offer/Answer ужесточил контракт

SDP возник как формат описания. Offer/Answer определил, как два agents строят общее представление, оставив transport, context, ordering, rejection и конфликт одновременных offers протоколу верхнего уровня, например SIP.

Когда agent меняет свой прежний offer, новая строка o= остаётся идентичной, кроме версии, увеличенной ровно на один. Постоянные поля сохраняют lineage, один шаг обозначает следующую редакцию этого agent.

Если версия не меняется, SDP обязан совпадать с текстом, связанным с ней. Неизменный offer можно повторить как no-op, и answerer всё равно формирует корректный answer. Новые байты под старой версией недопустимы.

Поэтому два разных тела под одним (origin, version) — конфликтующие свидетельства, а не равноправные варианты. Последний arrival не исправляет противоречие.

Offer/Answer также требует представимости ID и версии как signed 64-bit и начальной версии ниже 2^62 - 1, чтобы избежать rollover. Это предел конкретной модели, не кольцевая арифметика для всего SDP.

Новая редакция всё ещё была предложением

Число не принимает изменение. Answerer может выбрать совместимые streams, отклонить другие или через signaling отвергнуть весь offer. После rejection действует предыдущее состояние описания.

Конкуренцию число тоже не решает. Agent не выдаёт новый offer, пока ждёт answer или должен ответить peer. Одновременные offers создают glare, который разрешает верхний протокол. Правила «побеждает максимум» нет.

Даже valid answer доказывает лишь согласование описания. Он не подтверждает прохождение пакетов, работу codec, разрешение firewall, согласие человека, законность записи, billing или завершение услуги.

Свежесть не создавала доверия

Злоумышленник тоже может выбрать огромное число. Поэтому Offer/Answer полагается на end-to-end authentication и integrity в signaling protocol. Получатель отдельно применяет admission и consent policy.

Authentication называет признанный источник; integrity защищает перенос; origin заявляет lineage; version заявляет редакцию; состояние Offer/Answer фиксирует предложение и решение; media telemetry показывает эффект. Эти свидетельства не взаимозаменяемы.

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

Источники и границы доказательств

Нормативная цепочка — RFC 2327, RFC 4566, RFC 8866 и RFC 3264. Документы задают grammar и Offer/Answer, но не измеряют нынешнюю реализацию, не удостоверяют живого отправителя и не доказывают доставку media.