Кратко

  • RFC 3327 позволил выбранным прокси добавлять Path URI в REGISTER; регистратор хранил упорядоченный вектор вместе со связкой публичного адреса и конкретного Contact, а домашний прокси позднее переносил его в Route.
  • Path задавал условие будущей доставки, а не полный журнал: пройденный прокси мог отсутствовать, мог быть указан другой узел, регистратор мог преобразовать вектор, а последующая политика — добавить маршрут.

Сохраненное местоположение еще не было планом доставки

Устройство регистрирует публичную SIP-идентичность из сети доступа. Contact описывает текущую точку назначения, и регистратор принимает связку. Однако устройство может находиться за граничным прокси, межсетевой границей или обязательной службой посещаемой сети. Прямая отправка к Contact способна обойти требуемую политику либо не дойти до адреса, доступного только через эту цепочку.

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

Path сделал этот план явным. Прокси, обрабатывающий REGISTER, мог добавить URI, который следовало использовать в будущих запросах к устройству. Несколько значений образовывали упорядоченный вектор. Регистратор сохранял его вместе с адресом записи и данным Contact и отражал принятые значения в успешном ответе. Позднее, выбрав этот Contact, домашний прокси заранее помещал вектор в набор Route и пересылал запрос.

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

RFC 3263 решал соседнюю задачу: находил SIP-серверы домена через DNS. Такое обнаружение указывало вход в службу, но не временную цепочку от домашнего домена до отдельного зарегистрированного Contact. Path сохранял знание, возникавшее после обнаружения и принадлежавшее конкретной связке.

Название Path не означало трассу

Упорядоченный список URI легко принять за фактический маршрут REGISTER. Спецификация такого обещания не давала. Прокси мог обработать запрос и не добавить себя. Прокси, знающий топологию, мог указать URI другого узла, которому следовало получить будущий трафик. Регистратор мог преобразовать вектор при сохранении. Домашний прокси мог объединить его с уже существующим Route или маршрутом по умолчанию.

Поэтому Path был предписанием для будущего, а не описанием прошлого. Захват пакета доказывает наличие значений в точке наблюдения. Он не доказывает, что перечислены все пройденные прокси, что каждый перечисленный узел был пройден или что будущий запрос повторит ту же последовательность.

Надежный учет разделяет четыре квитанции: наблюдавшийся путь REGISTER, объявленный Path, принятую или преобразованную версию в хранилище регистратора и Route, реально реализованный позднее. Расхождения указывают на политику, ошибку либо вмешательство. Сведение их в одну красивую линию уничтожает важнейшие свидетельства.

Via относится к транзакции и возвращает ответы по ее цепочке. Record-Route строит набор маршрутов диалога из запроса, который этот диалог создает. Path изучается при регистрации для еще не существующих диалогов. Service-Route из RFC 3608 направлен в обратную сторону: регистратор сообщает пользовательскому агенту путь его будущих исходящих служебных запросов, тогда как Path сообщает домашней стороне путь внутрь к Contact. Момент, направление и владелец решения различны.

Отражение позволяло проверить, но не заверяло истину

Успешный ответ REGISTER возвращал сохраненные значения Path. Обычный пользовательский агент не строил по ним собственный маршрут и мог их игнорировать, но имел возможность посмотреть, что принял регистратор. Неожиданный прокси мог показать, что кто-то пытается закрепиться во всех будущих запросах к связке.

Вредоносная вставка переживала одну транзакцию. Пока регистрация действовала, узел мог перехватывать запросы к Contact. Удаление URI могло обойти обязательный контроль, перестановка — изменить первого наблюдателя, а преобразование без журнала — скрыть разницу между объявленным и принятым состоянием.

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

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

Последующие документы уточнили окружение

RFC 3327 был опубликован в декабре 2002 года и позднее обновлен RFC 5626. SIP Outbound систематизировал потоки от устройств за сетевыми границами и участие edge-прокси в сохранении рабочего обратного пути. Он уточнил связь регистрации, потока и маршрута, но не превратил Path в исчерпывающую историю.

RFC 5627 определил GRUU для маршрутизируемой идентификации экземпляра пользовательского агента. RFC 3680 задал уведомления о событиях регистрации. RFC 5922 описал сертификаты доменов SIP. Реестр параметров SIP в IANA фиксирует стандартизированные назначения. Эти источники подтверждают протокольные контракты и развитие документов, но не внедрение, распространенность, доступность или текущее доверие.

Главный исторический вывод RFC 3327 — различать идентичность, текущий локатор, обязательный путь и наблюдаемую историю. Сеть может знать первые два и не уметь доставить запрос. Она может знать будущий маршрут и почти ничего не знать о прошлом. Path сделал недостающее состояние сохраняемым. Его граница столь же важна: объявление о завтрашней доставке не является доказательством вчерашнего пути.

Источники