Кратко

  • RFC 3323 определял приватность через то, от каких участников скрывают сведения, а не как гарантию полного отсутствия идентификаторов в SIP-запросе.
  • Служба могла скрывать заголовки и одновременно сохранять и восстанавливать состояние маршрутизации диалога: граница доверия перемещалась, но не исчезала.

Анонимен — для кого?

В 2002 году приватность в SIP не была переключателем между «с известной личностью» и «анонимным». RFC 3323 описывал её как сокрытие сведений от одной или нескольких сторон диалога. Вызывающий мог не показывать настоящее имя адресату, но сообщить его доверенной службе. В иной архитектуре, напротив, от пользователя скрывались сетевые детали. Главный вопрос: перед кем именно сохраняется анонимность?

Анонимное значение From не означало, что в запросе не должно быть пригодного адреса. Для анонимного SIP URI спецификация рекомендовала anonymous.invalid, однако последующие запросы в диалоге всё равно должны были достигать нужного конечного узла. Личные идентификаторы могли скрываться, тогда как Contact, Via, Record-Route и другие сведения, нужные для маршрутизации, сохранялись. Приватность ограничивала представление состояния протокола, но не стирала само состояние.

Служба должна помнить то, что скрывает

RFC 3323 различал пользовательскую приватность и защиту на уровне сети. Заголовок Privacy позволял запросить user, header или session; none запрещал службе выполнять действия по сокрытию, а critical требовал отклонить запрос, если требуемый уровень недоступен. Это указания о политике, а не аутентификация, авторизация, шифрование медиа или свидетельство соблюдения правил каждым посредником.

Приватность заголовков показывала операционную цену. Служба могла действовать как B2BUA, удалять или менять идентифицирующие заголовки, заменять Contact собственным адресом и локально хранить исходные маршруты. Когда приходили следующие сообщения диалога, нужно было восстановить значения, необходимые для продолжения связи. Получатель видел меньше, зато служба хранила больше привилегированного состояния. Для этой службы вызывающий не был анонимным.

Для приватности сеанса требовались B2BUA и промежуточный узел для медиа или анонимизации трафика. Поскольку служба становилась частью тракта связи, RFC 3323 предостерегал от такого подхода без сквозной защиты медиа, например SRTP. Это архитектурное предупреждение, а не статистика внедрения.

Сокрытие идентичности создаёт новую точку контроля

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

RFC 3261 задаёт контекст SIP-диалогов и наборов маршрутов. RFC 3325 позднее рассматривает утверждённую идентичность внутри доверенных сетей и прямо не устанавливает общей модели между доменами доверия. Это соседние границы, а не универсальное решение приватности. RFC 3323 не подтверждает распространённость или совместимость реализаций. Он фиксирует проектный компромисс: уменьшить объём сведений для одной стороны, сохранить состояние для продолжения вызова и назвать посредника, отвечающего за этот баланс.

Источники