Кратко

  • RFC 3327 разрешил прокси добавлять упорядоченный Path при прохождении REGISTER; после успешной регистрации регистратор связывал этот вектор с привязкой AOR/Contact и возвращал его в ответе.
  • Позднее домашний прокси мог поместить сохранённый вектор в заголовок Route запросов к этому Contact. Но вектор не доказывал, через какие узлы действительно прошёл пакет REGISTER.

Поздний токен не был смыслом исходного Path

Регистратор SIP может сохранить адрес, по которому доступен пользовательский агент (UA). Эта привязка отвечает на узкий вопрос: какому Contact направить запрос для данного адреса записи (AOR)? Но она необязательно отвечает на другой: через какие промежуточные прокси должен пройти запрос, чтобы достичь этого Contact?

Пробел возникает, когда REGISTER проходит через пограничные прокси, которые домашний прокси не может восстановить по DNS или собственным таблицам маршрутизации. UA может регистрироваться из посещаемой сети, регистратор — находиться в другом месте, а последующему входящему запросу может потребоваться пройти через узлы, не видимые в URI Contact. Опубликованный в декабре 2002 года RFC 3327 дал таким узлам способ оставить в обмене регистрации вектор маршрута.

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

Маршрут переживает транзакцию

Path похож на Record-Route, но временные горизонты у них разные. Record-Route задаёт маршрутизацию запросов внутри диалога, в котором был создан. Path передаётся в REGISTER и его успешном ответе, чтобы последовательность прокси могла использоваться в будущих диалогах. Существующие механизмы маршрутизации RFC 3261 выполняют Route; RFC 3327 переносит последовательность через границу регистрации.

Область действия была ограниченной: механизм предназначен для запросов, проходящих через домашний домен пользователя или исходящих из него. Значения соответствуют синтаксису элемента Route и используют параметр свободной маршрутизации ;lr. UA может объявить поддержку через Supported: path; обычно прокси не следует добавлять Path, если UA не заявил такую поддержку. Если регистратор получил Path без этого объявления, RFC рекомендовал отказ, оставляя место для локальной политики.

Исторический сдвиг состоял не в том, что SIP узнал, где прошёл каждый пакет. Регистрация стала моментом, когда прокси могли прикрепить контекст маршрутизации к привязке, влияющей на последующие входящие запросы. Регистратор также возвращал Path UA, делая добавленные прокси доступными для проверки, а не превращая их незаметно в универсальную базу топологии.

Вектор — не свидетель

RFC 3327 прямо разрешал прокси, знающему топологию, добавить Path со ссылкой на другой узел, даже если значение не соответствовало маршруту, по которому REGISTER прошёл фактически. Это определяет правильное прочтение Path: упорядоченное предписание маршрута, сформированное политиками прокси и регистратора, а не криминалистическая запись пути пакетов. Сам по себе он не подтверждает, что прокси переслал предыдущее сообщение, что предложенный маршрут всё ещё доступен или что будущий вызов будет доставлен.

Этот выбор создал и границу безопасности. Прокси, вставленный в сохраняемый вектор, мог попасть в будущие запросы и перехватывать вызовы. Поэтому RFC 3327 обсуждал целостность транспорта и взаимную аутентификацию, например TLS или IPsec, а также защищённые копии S/MIME, позволяющие UA заметить изменение возвращённого Path. Синтаксически корректный URI ещё не делает промежуточный прокси уполномоченным.

Позднейшие работы использовали механизм повторно для более узкой задачи. RFC 5626 помещает в Path уникальный токен потока, чтобы пограничный прокси мог связать будущий запрос с конкретным соединением, инициированным клиентом. Поведение с привязкой к потоку относится к более позднему расширению; его нельзя приписывать каждому вектору RFC 3327. Service-Route из RFC 3608 действует в противоположном направлении: задаёт UA маршрут для его собственных исходящих запросов, а не для входящих запросов к нему.

Источники