Кратко

  • RFC 5379 вышел как Informational-документ Independent Stream и прямо заявил, что не меняет механизм RFC 3323/3325/4244 и не вводит нового нормативного поведения.
  • Его матрица связывала priv-value с конкретными заголовками и SDP-полями. Она не превращала Privacy в универсальное разрешение на удаление любых чувствительных данных.
  • Нужны отдельные свидетельства запроса, целевого поля, независимого основания, изменения, корреляционного состояния, сохранения смысла и фактической приватности для заданного наблюдателя.

Документ, который отказался быть источником новой власти

RFC 5379 содержит нормативно звучащие слова, подробную таблицу и рекомендации для множества SIP-полей. Из этого легко сделать неверный вывод: будто в 2010 году появился новый обязательный профиль приватности.

Сам текст отвергает такой вывод. Он опубликован в Independent Stream со статусом Informational. Его назначение — описать практическую работу механизма из RFC 3323, расширенного RFC 3325 и RFC 4244. Он говорит, что не меняет существующий механизм, а нормативная лексика производна от прежних RFC.

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

Тот же принцип действует внутри сообщения. Privacy удобен как единая точка чтения просьбы. Удобство не делает его источником полномочий над каждым полем.

Значения выбирали разные поверхности

user относился к информации, вставленной пользователем. header — к сетевой сигнальной информации. session — к описанию сессии. id касался P-Asserted-Identity в модели доверенного домена RFC 3325. history касался History-Info. none и critical решали иные вопросы.

Это не последовательные уровни силы. session не включал автоматически всё, что связано со звонком, а user не разрешал очищать каждый встреченный идентификатор.

RFC 5379 разложил действия по полям и направлениям. В ячейках были удаление, запрет добавления, анонимизация, условная обработка либо отсутствие действия. Для Privacy:session в SDP были названы строки c, m, o, i, u, e и p.

Поэтому исполнителю недостаточно флага privacy=true. Нужны значение, направление сообщения, тип поля, действие, условие и спецификация. Без типа журнал сообщает, что сервис был активен, но не доказывает, что он обладал полномочием на конкретное изменение.

Отсутствие в таблице тоже было границей

Identity/Identity-Info, Path, Replaces, Route, Service-Route и Target-Dialog названы нецелевыми для перечисленных значений. Их не следовало анонимизировать или изменять лишь на основании Privacy.

При этом они могут раскрывать сведения. Path указывает посещённый или административный домен. Route перечисляет прокси. Identity-Info ссылается на сертификат. Replaces и Target-Dialog связывают диалоги.

Чувствительность описывает риск, но не выдаёт мандат. Path нужен, чтобы запрос достиг зарегистрированного агента. Route задаёт принудительный путь. Удаление раскрывающего имени без функциональной замены может уничтожить достижимость или маршрутизацию.

Если сеть скрывает топологию, это отдельная политика со своим владельцем, версией и методом. Нельзя приписывать её пользователю. Для каждого действия нужно назвать правило, целевое поле и семантику, которая обязана сохраниться.

Нецелевое поле могло потребовать отдельного действия

Нецелевое не означает неизменяемое навсегда. Исторический пример Identity показывает другую причинную цепочку.

В RFC 4474 подпись защищала From, To, Call-ID, CSeq, Date, Contact и тело. Правомерное изменение защищённого поля ради приватности делало подпись недействительной. Identity не становился прямой целью значения, но передавать ложное доказательство целостности было нельзя.

Удаление тогда основывалось на потере целостности, а не на расширении просьбы. Аудит должен хранить два события: целевое поле изменено по Privacy; зависимое доказательство признано недействительным и удалено по отдельному правилу.

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

Предыдущее изменение могло управлять будущим сообщением

Если Call-ID изменён с C1 на C2, сервис создаёт два имени одного диалога. Позднее In-Reply-To, Replaces, параметр replaces или Target-Dialog может нести одно из них.

Будущее сообщение может не содержать Privacy и быть отправлено другой стороной. Перевод всё равно нужен. Его основание — не новая просьба, а обязательство согласованности, созданное прошлой мутацией.

Сценарии переноса в RFC 5379 показывают отказ: начальный INVITE прошёл через сервис, последующий REFER или INVITE пошёл иначе. Одна сторона знает C1, другая C2. Диалог для замены не находится, хотя синтаксис сообщений корректен.

Значит, решение изменить Call-ID включает срок хранения таблицы, репликацию, восстановление, асимметричные пути и длинные диалоги. Компонент не может объявить успех после отправки первого пакета. Он владеет созданной корреляцией, пока от неё зависят другие операции.

Локальная политика должна говорить от своего имени

RFC 5379 допускал вариации реализации и сетевой политики, а также обработку чувствительных нецелевых данных по независимым причинам. Это пространство необходимо, но оно требует происхождения.

Сокрытие топологии, удаление P-Asserted-Identity на недоверенной границе, очистка недействительной подписи и восстановление Route после преобразования Record-Route — разные действия.

Общий статус «приватность применена» стирает авторство. При сбое нельзя определить, виноваты ли просьба пользователя, правило оператора, обработка целостности или корреляция. Каждая локальная политика должна иметь имя, версию, владельца, область и результат.

Privacy остаётся записью просьбы. Матрица — записью её области. Журнал — записью действия. Трасса — записью исполнения. Наблюдательный тест — записью результата. Ни одна запись не создаёт другую реальность одним фактом своего существования.

Результат требовал назвать наблюдателя

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

Утверждение должно называть информацию, наблюдателя, сообщения, медиапоток и время. Оно также должно назвать системы, сохранившие способность корреляции.

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

Отсутствующий заголовок не доказывает работающий звонок. Работающий звонок не доказывает тайну. Таблица обеспечивает согласованность реализации, а не универсальный сертификат результата.

Время меняло источники

Документный статус требует следить за преемниками. RFC 4244 заменён RFC 7044, а RFC 4474 — RFC 8224. Исторические примеры сохраняют объяснительную ценность, но текущие требования проверяются по актуальным документам.

Реестр SIP Parameters IANA — ещё одно ограниченное свидетельство. Он подтверждает зарегистрированное имя и ссылку. Он не доказывает поддержку продукта, правильную обработку, сохранность состояния или результат приватности.

Минимальная цепочка доказательств содержит:

  • исходное сообщение, направление, заявителя и предполагаемого наблюдателя;
  • каждое значение Privacy и применимую спецификацию;
  • решение о целевом статусе каждого поля;
  • независимую локальную или протокольную причину;
  • состояние до и после изменения;
  • ставшее недействительным или пересозданное доказательство;
  • отображения идентификаторов, срок и ответственный узел;
  • последующие сообщения, использовавшие состояние;
  • результат маршрута, диалога, переноса и медиа;
  • проверку раскрытия для каждого наблюдателя.

Так статус документа не превращается в новый мандат, а токен — во всеобщую власть над сообщением.