Кратко

  • RFC 7865 называет XML-документ метаданных записи SIPREC application/rs-metadata+xml, тогда как RFC 7866 использует application/rs-metadata в процедурах и примерах.
  • Erratum 7987 сообщил о противоречии в июне 2024 года и сейчас по-прежнему имеет статус Held for Document Update. Опубликованный в июне 2025 года RFC 9806 обновляет RFC 7866 и заменяет все старые вхождения.
  • RFC 9806 также выполнил регистрацию IANA, которую не сделали документы 2016 года. В актуальной строке реестра стоит application/rs-metadata+xml со ссылками на RFC 7865 и RFC 9806.
  • Эта цепочка устанавливает действующее имя, но не показывает, что отправил SRC, что принял SRS, как разобран multipart и какую метку сохранил архив.

Документы пришли к согласию, системы — не обязательно

RFC 7865 описывает участников и другие метаданные записываемого сеанса в отдельном XML-документе SIPREC и присваивает ему тип application/rs-metadata+xml. Выпущенный в том же месяце RFC 7866 определяет Session Recording Protocol, но в разделе 9 и примерах сокращает значение до application/rs-metadata.

Речь не идет о двух конкурирующих XML-форматах: RFC 7866 ссылается на RFC 7865 как на определение содержимого. Расхождение находится в MIME-идентификаторе, по которому программное обеспечение выбирает обработчик. Получатель может понимать те же XML-байты и отклонить тело, потому что Content-Type отсутствует в таблице диспетчеризации. Отправитель может создать корректные SIP и XML, объявив неверное имя.

Erratum 7987 зафиксировал проблему 12 июня 2024 года. На странице приведены исходное и исправленное значения, а также указано, что ни один из первоначальных RFC не зарегистрировал тип. Текущий статус — Held for Document Update, а не Verified. Для доказательной цепочки эта формулировка существенна.

RFC 9806 содержит последующее формальное решение. Документ опубликован в июне 2025 года как IETF Standards Track, помечен Updates: 7866, говорит, что разрешает Erratum 7987, и заменяет каждое application/rs-metadata в RFC 7866 на application/rs-metadata+xml. Современное прочтение спецификации определено. Состояние установленного ПО из него не следует.

Обновление не стирает страницу, прочитанную раньше

В исходном тексте RFC 7866 короткая метка видна до сих пор. RFC 9806 не переписал архивный файл задним числом, а добавил отслеживаемую связь обновления. Благодаря этому аудитор видит первоначальное утверждение, сообщение об ошибке и принятое решение.

Но доказательства распределены. Разработчик, открывший только RFC 7866, способен скопировать старую строку. Запись в реестре активов «поддерживает RFC 7866» не раскрывает вариант реализации. Сборщик errata может сохранить статус Held, не связав его с более поздним RFC. Проверка IANA находит правильное имя, но не показывает, использовал ли его конкретный релиз.

RFC 7865 подтверждает задуманное имя типа. RFC 7866 показывает место, где несогласованность вошла в процедуру. Erratum 7987 сохраняет сообщение и его редакционный статус. RFC 9806 задает обновление и регистрацию. Ни один из этих источников не является инвентарем работающих процессов и конфигураций.

IANA закрывает пробел в пространстве имен

RFC 9806 прямо указывает на отсутствие регистрации и приводит шаблон. Тип — application, подтип — rs-metadata+xml, обязательных и необязательных параметров нет, кодирование согласовано с application/xml по RFC 7303. Приложения — Session Recording Client и Session Recording Server, назначение — COMMON, контроль изменений остается у IETF.

Снимок реестра IANA от 20 сентября 2026 года содержит application/rs-metadata+xml со ссылками на RFC 7865 и RFC 9806. Это точное доказательство координации имени. Оно не говорит, включена ли строка в сборку, активирована ли настройка, переписал ли заголовок посредник и сохранил ли архив принятое значение.

Суффикс +xml также доказывает только ограниченный факт. Универсальное ПО может распознать MIME-сущность семейства XML. Суффикс не подтверждает соответствие схеме SIPREC, принадлежность правильной Recording Session или целостность последовательности полных снимков и частичных обновлений.

Операционное исправление видно внутри MIME-конверта

RFC 7866 позволяет SRC отправлять полный снимок или частичное обновление в INVITE либо UPDATE. Когда одно SIP-сообщение несет и предложение SDP, и метаданные, внешнее тело должно быть multipart/mixed: одна часть содержит SDP, другая — метаданные с Content-Disposition: recording-session.

Полезное доказательство связывает метод и ограниченные идентификаторы SIP, внешний Content-Type и boundary, Content-Type и Content-Disposition части, хеш XML-тела, namespace, состояние снимка и результат обработки на другой стороне. Отметка «RFC 9806 поддерживается» этих данных не заменяет.

SRS поддерживает состояние. Он отслеживает порядок частичных обновлений, а после внутренней потери состояния может запросить новый полный снимок. При синтаксической или семантической ошибке метаданных SRS может завершить Recording Session. Ответ 2xx на другом уровне диалога не доказывает принятие этой цепочки.

Наличие аудиофайла тоже недостаточно. Хранение и воспроизведение лежат вне области RFC 7866. Аудио могло сохраниться, пока метаданные были отклонены, задержаны, нормализованы или проиндексированы под старым именем. Следует проверить сохраненную метку, правило индекса и дальнейшее воспроизведение или экспорт.

Совместимость может скрыть последний старый узел

На переходном этапе разумно принимать и application/rs-metadata, и application/rs-metadata+xml. Это сохраняет связь со старыми узлами, пока новые генераторы переходят на правильное имя. Но RFC 9806 не предписывает такую политику, а успешность при двойном приеме дает меньше информации.

Если все SRS бессрочно разрешают обе строки, устаревший SRC остается незаметным. Если шлюз заменяет старое значение новым, последующая телеметрия ошибочно показывает исправленный источник. Если журнал нормализует значения до записи, исчезает возможность посчитать остаточный старый трафик.

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

Квитанция о хранении исправления

Предлагаемая квитанция — редакционный механизм Daniel Kade, а не поле RFC 9806 и не требование IETF, RFC Editor или IANA.

Сначала она фиксирует документальную цепь: точные места в двух исходных RFC; ID, дату, статус и замену Erratum 7987; категорию, связь обновления и правило RFC 9806; датированный снимок и хеш регистрационного шаблона IANA.

Затем привязывает реализацию: продукт, версию и build SRC и SRS, модули разбора и генерации, поколение конфигурации, точные принимаемые и отправляемые значения по направлениям. Для старого псевдонима отмечается отказ, прием, нормализация или перезапись вместе с правилом наблюдаемости.

Для транзакции сохраняются метод, ограниченные идентификаторы, Accept, Content-Type, boundary, Content-Disposition, хеш и namespace документа, состояние снимка, связь с SDP и решение узла. Отказ, запрос снимка и завершение сеанса не сводятся к фразе «запись успешна».

Последняя часть присоединяет архив: сохраненную метку, ключ индекса, правило нормализации, экспортное представление и тест воспроизведения. Добавляются когорта внедрения, счетчики нового/старого/неизвестного, canary, окно совместимости, негативные тесты, условие отката, владелец, решение об удалении псевдонима и остаточные исключения.

Публикация стандарта доказывает существование правила. Квитанция показывает, где это правило выполнялось.

Граница доказательств

Источники подтверждают противоречие, erratum, обновление и состояние реестра. В них нет переписи продуктов или внедрений SIPREC, матрицы поддержки поставщиков, долей двух меток и описанных инцидентов, вызванных различием. Статья не объявляет какую-либо названную реализацию устаревшей или несоответствующей.

Риски выше — проверяемые сценарии, а не наблюдавшиеся сбои. Они следуют из явных поверхностей протокола: точного токена, структуры multipart, разбора XML, последовательности обновлений и работы архива. Их нужно тестировать в каждой среде, а не подменять операционное доказательство фактом существования RFC 9806.

Источники