Кратко

  • History-Info сохраняет Request-URI, которые раскрыли поддерживающие расширение узлы при смене цели или разветвлении начального запроса. hi-index задаёт упорядоченное дерево, а rc, mp и np классифицируют смену контакта, целевого пользователя либо только следующего перехода.
  • Поддержка необязательна. В дереве возможны старые и замещающие пробел записи, отсутствующие незавершённые ветви и законно анонимизированные адресаты. TLS/SIPS защищает канал от посторонних, но не гарантирует правдивость каждого доверенного посредника.
  • Для обоснования решения нужны также версия правила, его владелец, входные данные, операционная личность, состояния ветвей, преобразование приватности, последующая транзакция и фактический результат. История объясняет путь, но не выдаёт разрешение на его выбор.

Отчёт, в котором маршрут подменил решение

У поставщика коммунальной услуги есть единый аварийный номер. В одном регионе вызов неожиданно попал не в дежурную бригаду, а во внешний колл-центр. В отчёте оператора видна аккуратная History-Info: публичный номер, региональная служба, адрес приложения подрядчика. Индексы корректны, последний адресат ответил успешно. Отчёт называет маршрут «разрешённым».

Но заголовок не содержит такого решения.

Он показывает, какие целевые URI присутствовали в наблюдаемой копии сообщения. Он не отвечает, кто включил правило, из какой версии справочника был выбран подрядчик, действовал ли договор, существовала ли ещё одна ожидающая или скрытая ветвь, что преобразовал сервис приватности, переписал ли запись посредник на пути, установилась ли медиасессия и была ли действительно отправлена аварийная бригада.

RFC 7044 решает более узкую задачу. При обычной смене цели новый Request-URI вытесняет предыдущий. History-Info сохраняет адресаты начального или внедialogового запроса, которые иначе исчезли бы. RFC не стандартизирует локальную политику, выбравшую эти адресаты.

Сначала исполняется правило, затем появляется запись

По RFC 3261 прокси определяет цель через location service, redirect-ответ, маршрутную информацию либо конфигурацию. Исходящий Request-URI сообщает следующему узлу текущий адрес. Предыдущие намерения без дополнительного механизма теряются.

RFC 7044 называет retargeting изменение Request-URI по правилам определения цели с последующей пересылкой. Операционный факт создаёт работающий код прокси, PBX, B2BUA или приложения. History-Info сообщает часть следа этого факта.

Стандарт задаёт общий язык. Реестр параметров SIP IANA регистрирует History-Info, histinfo, history, rc, mp и np. Регистрация подтверждает выделение имён, а не наличие реализации, полноту данных или полномочия на изменение маршрута.

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

Координаты дерева — не временные метки

Каждая запись обязательно содержит целевой URI и hi-index. Неотрицательные целые числа, разделённые точками, задают место узла. Потомок расширяет индекс родителя, а fork создаёт соседние узлы. Передача следует прямому обходу, чтобы получатель восстановил дерево.

Это важнее плоского списка: две параллельные ветви не выглядят двумя последовательными перенаправлениями. Но индекс не измеряет время. Он не показывает задержку, не синхронизирует независимые часы и не доказывает порядок завершения ветвей.

Три параметра описывают механизм перехода:

  • rc — Request-URI изменился, но узел считает целевого пользователя тем же, например при разрешении публичного адреса в зарегистрированный Contact;
  • mp — выполнено отображение на другого целевого пользователя или другой адрес записи;
  • np — Request-URI не менялся, изменился лишь следующий узел.

Это утверждения вставляющего узла, а не разрешения. rc не доказывает институциональную тождественность двух идентичностей. mp не подтверждает законность отображения. np не аттестует следующего посредника. Метку нужно сверять с правилом и данными, породившими её.

Полнота зависит от места и момента наблюдения

Поддержка расширения необязательна. histinfo объявляется в Supported, но не заставляет каждый переход участвовать через Require или Proxy-Require. Один несовместимый узел создаёт пробел без злого умысла.

Могут сохраняться записи из отменённого RFC 4244. RFC 7044 требует передавать их, но запрещает придумывать rc, mp или np для старого решения, которого новый узел не наблюдал. Отсутствие параметра может означать старый формат, а не отсутствие смены цели.

Если входящий Request-URI не совпадает с последней записью, получатель добавляет запись от имени предыдущего посредника. Он знает, что адрес изменился, но не видел механизм. Поэтому замещающая пробел запись остаётся без механической классификации. Неопределённость сохраняется намеренно.

Fork добавляет временную границу. В примере RFC 7044 одна ветвь отвечает 200, пока соседняя ещё ожидает. Успешный ответ не способен содержать будущее состояние открытой ветви. Дерево, полученное на победившем пути, может быть правильным, но не исчерпывающим.

Приватность может скрыть ветвь сознательно. Примеры RFC 4244 показывают, что upstream-узел способен повторно попробовать скрытый адрес, не зная о прежней попытке. Это не повод отменять приватность. Это требование к безопасным значениям по умолчанию при частичной истории.

Поэтому строгая формулировка указывает точку: «эта копия сообщения содержала эти записи здесь». Для утверждения о полном пути нужны внешние журналы.

Reason объясняет протокольное событие

History-Info может нести Reason в компоненте headers URI. RFC 3326 определяет причины SIP и Q.850 и допускает несколько протокольных пространств. RFC 7044 применяет их к определённым отказам и тайм-аутам.

Запись помогает понять, что ветвь сообщила «занято» или истекло ожидание. Она не доказывает человеческий мотив настройки, правомерность политики, истинность ответа либо деловую первопричину. Без защиты целостности Reason можно удалить или изменить. Его следует хранить вместе с исходным сообщением, субъектом и точкой наблюдения.

Реестр errata RFC 7044 содержит три записи Reported — об индексе пробела, классах ответов для Reason и редакционной ссылке — и две Rejected. Reported не означает Verified. Это темы для тестирования конкретных реализаций, не вступившие в силу нормативные исправления.

Приватность намеренно уменьшает видимую правду

История Request-URI способна раскрыть личное устройство, псевдоним, внутренний отдел, голосовую почту и топологию. RFC 3323 объясняет роль посредников в приватности SIP: именно они добавляют маршрутные данные.

RFC 7044 вводит значение Privacy history. Защита может относиться ко всей значимой истории или отдельной записи. Домен вправе скрывать внутренний маршрут даже без запроса приватности во входящем сообщении. UAS может не раскрывать инициатору конечную цель. Пограничный сервис может заменить URI адресом под anonymous.invalid.

Это может быть правильным исполнением политики, а не враждебной фальсификацией. Однако последующий аудитор получает более узкое доказательство. Следует сохранять границу, версию политики, преобразование и защищённую таблицу соответствия для уполномоченной проверки, когда это допустимо.

Право выбирать цель и право скрывать её принадлежат разным ролям. Одно событие «нормализации маршрута» не должно стирать обе ответственности.

TLS защищает канал между редакторами истории

RFC 7044 настоятельно рекомендует TLS либо безопасную среду. В своей модели SIPS мешает произвольному участнику вне пути. Но посредники на пути должны читать и дополнять History-Info.

Злонамеренный или взломанный посредник может удалять, переставлять и переписывать записи. RFC 7044 прямо говорит, что механизм этого не предотвращает и не обнаруживает. Заголовок защищён так же, как остальные SIP-заголовки на пути, но не сильнее.

Доказательная цепочка сохраняет TLS-peer, результат проверки сертификата, домен доверия, отпечаток сообщения и место захвата. Фраза «доставлено по SIPS» описывает канал, а не сквозную аттестацию каждого рассказчика.

Приложение обязано раскрыть правило чтения

RFC 7044 требует определить поведение при отсутствующей или неполной истории. Разным сервисам могут быть нужны разные позиции rc.

Корпоративная PBX и потребительская голосовая почта способны искать разные идентичности вызываемого. Если запрос был переадресован ещё до предприятия, правило «брать первый rc» ошибочно выберет внешнее лицо. RFC 4458 показывает, что для голосовой почты параметры target и cause могут оказаться в текущем Request-URI или History-Info в зависимости от поддержки и пути.

У дерева нет универсального селектора. Приложение должно назвать цель, доверенные домены, обработку пробелов и приватности, правило разрешения конфликтов. Это соответствует принципу Heng Lu о минимальной начальной спецификации: общий слой координирует, а обычные последующие решения остаются у участников с контекстом и риском. Локальное правило при этом обязано быть версионируемым и оспоримым.

Досье решения вне заголовка

Первый слой хранит метод, входящий и исходящий Request-URI, Call-ID, CSeq, Via branch, время, точку наблюдения и контролируемый отпечаток.

Входящее и исходящее деревья сохраняются раздельно: порядок, индекс, URI, ссылка rc/mp/np, Reason, Privacy, старый формат, результат разбора и замещающая пробел запись. Неизвестный механизм не дополняется догадкой.

Отдельно хранится решение: ID и версия правила, источник запроса и результат, redirect-ответ, кандидаты, выбор, fallback, создание ветвей, сервисная идентичность, tenant, владелец, одобрение и срок действия.

Доверие и приватность также разделены: входящий и исходящий домен, TLS-peer, преобразование, политика, защищённая карта, доступ и хранение.

Затем связываются транзакции ветвей, ответы, timeout, CANCEL, победитель, сопоставление плеч B2BUA, диалог, медиа, приложение, запись, расчёты и жалоба.

Противоречия нельзя сглаживать: победитель без известной соседней ветви; rc вопреки границе tenant; Reason вопреки журналу приложения; правильное дерево B2BUA без карты плеч; 200 без аудио. Они показывают разрыв слоёв. Сводка «маршрут одобрен» отдаёт агрегатору власть через сжатие.

Источники