Кратко

  • В SDP есть две разные версии: v=0 обозначает версию формата протокола, а sess-version в o= повышается при изменении идентифицированного описания сеанса.
  • Число действует лишь внутри полного кортежа origin. Сравнение разных источников или чтение похожего на timestamp значения как заверенного времени уничтожает доказательство преемственности.

Максимум оказался максимумом другой истории

После failover резервный контроллер может начать с числа выше или ниже числа основного. Каждый генератор ведёт собственную последовательность. RFC не задаёт всем создателям SDP единый счётчик, а смена хоста меняет часть идентичности ещё до сравнения версий.

Ключ session_id + max(version) удобен, но смешивает порядок создателя, время получения и разрешение стать преемником. Позднее получение не означает позднюю ревизию. Большая версия не выдаёт полномочий. Разрешённая миграция ещё не означает, что другая сторона приняла новое описание.

v=0 не означает нулевую ревизию звонка

RFC 8866 требует начинать описание с v=0. Это версия самого Session Description Protocol; младшей версии нет. Добавление видео, смена codec или адреса media не превращает строку в v=1.

Обязательная o= содержит username, session ID, session version, network type, address type и unicast address. Здесь sess-version относится к ревизии описания. Создающий инструмент обязан увеличить его при изменении документа; RFC рекомендует использовать timestamp.

Смешение полей даёт две противоположные ошибки. Увеличение v= объявляет несуществующий формат протокола. Изменение байтов без повышения sess-version выдаёт два состояния за одну ревизию. Хранить нужно оба поля, но смысл у них разный.

Пять значений задают имя, шестое — порядок

Текущий RFC говорит, что username, session ID, network type, address type и unicast address вместе образуют глобально уникальный идентификатор сеанса. Одного значения недостаточно. Тот же session ID на другом хосте не наследует историю; username не аутентифицирует человека; новый адрес не получает непрерывность автоматически.

RFC 2327 прямо объяснял исходную задачу. Handley и Van Jacobson писали, что версия нужна proxy-объявлениям, чтобы определить самое новое среди нескольких объявлений одного сеанса. Граница — «одного сеанса». Сначала устанавливается идентичность, затем сравниваются ревизии.

Если плановая миграция меняет кортеж, ей нужен отдельный документ: прежний и новый origin, одобривший субъект, момент действия, переданное состояние и путь отмены. Большое число не подписывает переход.

В offer/answer та же версия требует тот же текст

RFC 3264 задаёт точное правило изменения сеанса. Новая offer сохраняет строку o= прежнего SDP, кроме версии, которая увеличивается на один. Если версия не выросла, SDP обязан совпадать с документом, уже носившим это число. Повтор без изменений фактически является no-op, хотя answerer всё равно формирует корректный answer.

Так появляется воспроизводимая проверка. Одинаковые origin и version при разных байтах — не обычная повторная передача. Следует сохранить оба текста и hash, отметить конфликт линии и применить локальную политику ошибки. Выбор последнего поступления стирает доказательство.

Новая версия также не доказывает работающий media-сеанс. Она показывает лишь объявление изменения создателем. Принятие, RTP и пользовательский результат требуют отдельных записей.

Число в форме времени не заверяет часы

RFC 8866 рекомендует секунды с 1 января 1900 года UTC для session ID и timestamp для sess-version. Это практичный способ получить различимые возрастающие числа внутри одного создателя. Он не удостоверяет синхронизацию часов, время получения или организационные полномочия.

Условие доверия находится в разделе безопасности: описание можно считать надёжным, только если оно получено от известного доверенного источника по аутентифицированному и защищённому по целостности транспорту. Поэтому receipt соединяет заявленный origin с аутентифицированным principal и результатом проверки канала.

У SAP собственный признак изменения

RFC 2974 определяет для Session Announcement Protocol отдельные originating source и message identifier hash. Изменение hash заставляет получателя разобрать изменённое объявление. SDP внутри payload сохраняет собственные origin и session version. Сигнал слоя распространения не становится генеалогией документа.

SDP — формат описания, а не транспорт, и сам по себе он не ведёт переговоры о содержимом или кодировании. SIP offer/answer использует его в ограниченной модели переговоров; SAP, HTTP или почта могут его доставлять. Получение, идентичность, решение и media-результат связаны, но не тождественны.

Mark Handley в коллективной линии

RFC 2327 подписали Mark Handley и Van Jacobson. Авторы RFC 4566 — Handley, Jacobson и Colin Perkins. Действующий RFC 8866 подписан Ali Begen, Paul Kyzivat, Perkins и Handley. Это коллективная работа, которую нельзя превращать в историю одинокого изобретателя.

Royal Society называет Handley профессором сетевых систем UCL, автором многих интернет-стандартов и бывшим членом Internet Architecture Board. ACM SIGCOMM присудила ему премию 2019 года за вклад в интернет-мультимедиа, multicast, congestion control, multipath-сети и стандартизацию протоколов.

Точное доказательство номера

При наличии полного origin, точных байтов и надёжной записи получения sess-version поддерживает узкое утверждение: этот создатель пометил описание как более позднюю ревизию того же сеанса. В RFC 3264 он также выявляет разные данные под одной версией или изменение без повышения.

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

Источники