Кратко

  • RFC 5368 позволяет Refer-To через cid: указать список целей. Получатель REFER создаёт отдельный SIP-запрос для каждой эффективной цели, но ответ на родительский REFER не является сводным результатом этих запросов.
  • Для нескольких целей документ рекомендует norefersub и Refer-Sub: false: обычная неявная подписка с message/sipfrag не умеет честно представить несколько транзакций.
  • Доказательная цепочка должна включать отсутствие fork, ответное Refer-Sub, точный объект Content-ID, нормализованный набор, каждый дочерний запрос и отдельное состояние сервиса. RFC 8262 позднее уточнил границу ссылки на MIME-часть или всё тело.

Получатель команды стал самостоятельным субъектом

До принятия REFER сервер отвечает перед издателем как UAS. После принятия он формирует новые запросы и выступает UAC перед целями. Это не пассивная передача байтов. Сервер выбирает эффективный набор, связывает метод с приложением и принимает локальные решения.

RFC 5368 требует принимать такие REFER только в понятном прикладном контексте и запрещает принимать методы, которых сервер не понимает. Причина сформулирована прямо: получатель не должен превращаться в тупой механизм рассылки произвольных сообщений.

Аутентификация издателя отвечает лишь на вопрос, кто прислал родительскую команду. Авторизация определяет, вправе ли он запросить этот метод в этом приложении. Правила opt-in защищают затронутые цели. Состояние конкретного диалога определяет, существует ли объект для BYE. Ни одно решение не наследуется только из факта успешной проверки соседнего слоя.

Реестр должен сохранять версию политики и основание по каждой цели. Иначе позднее невозможно понять, почему одна запись была выпущена, вторая отклонена, а две записи с эквивалентными URI были объединены.

202 принял поручение, а не его последствия

В примере RFC модератор просит сервер конференции отправить BYE нескольким участникам. Сервер возвращает 202 Accepted, а затем создаёт отдельные BYE.

Порядок событий ограничивает смысл ответа. 202 подтверждает принятие родительского поручения. Он не подтверждает, что дочерний запрос был сформирован, что его Call-ID и маршрут соответствовали нужному диалогу, что удалённый UA ответил или что участник исчез из состояния конференции.

Единственное поле status почти неизбежно смешает уровни. Нужна родительская запись с издателем, правом, ссылкой на список и ответом, а также дочерние записи с целями, методами, идентификаторами транзакций и результатами. Родитель может быть принят, когда дети ещё неизвестны, и оставаться принятым после разных исходов детей.

Количество также требует контекста. Входной список, набор после сравнения URI и фактически созданные запросы могут отличаться. Каждое объединение дубликатов должно иметь правило и след.

Обычный канал результата здесь убрали

Обычный REFER с одной целью создаёт неявную подписку на событие refer. NOTIFY с message/sipfrag сообщает о транзакции, начатой получателем.

Для нескольких целей одной транзакции нет. Одна может завершиться успешно, другая получить отказ, третья перенаправиться, четвёртая ждать. RFC 5368 не определяет, как упаковать эти состояния в прежний канал, и прямо говорит, что не предоставляет издателю механизма для получения всех результатов.

Поэтому запрос обычно требует multiple-refer и norefersub и предлагает Refer-Sub: false. Получатель должен подтвердить false в 200 и не создавать подписку.

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

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

Ответ определял, согласился ли сервер молчать

False в запросе — предложение. Только false в 2xx подтверждает, что оно принято. Если поле отсутствует или равно true, обычная подписка возникает.

Нельзя восстанавливать соглашение только по отправленному пакету. Запрос и ответ следует хранить парой вместе с option-tag, кодом, Refer-To и идентификатором списка.

Подавление допустимо только при уверенности, что REFER не будет fork. Неявная подписка помогает обнаружить несколько диалогов после fork; убрать её при возможных ветвях означает скрыть исполнителей. Пример использует GRUU как основание единственности адресата.

Request-URI, Route, основание отсутствия fork, branch ответа и личность получателя входят в доказательство. Внутренний выбор одного процесса балансировщиком сам по себе не равен протокольной гарантии.

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

Ссылка cid должна была назвать точный объект

Refer-To содержит Content-ID URL, а список находится в теле. Чтобы доказать, какой набор был разрешён, нужно сохранить cid:, заголовок Content-ID, MIME-границы, тип, disposition, байты и хеш.

RFC 8262 зафиксировал старую неоднозначность. Примеры RFC 5368 ссылались на целое тело, хотя действующие правила описывали части. Поздний документ явно разрешил указывать либо body part, либо всё message-body, используя MIME- или SIP-Content-ID.

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

Формат списка не назначал смысл методу

Список может содержать copyControl и anonymize. Для INVITE они способны управлять раскрытием истории адресатов. Для mid-dialog BYE роли to, cc, bcc не несут того же смысла.

Синтаксическая валидность не является разрешением операции. Получатель должен понимать метод, приложение и контекст. Регистрация multiple-refer в IANA доказывает согласованное имя, но не включение функции, право издателя, создание детей или результат.

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

Состояние конференции наблюдало другой объект

Пакет состояния конференции может показать текущий состав по мнению focus. Это сильнее исходного намерения, но не является сетевой квитанцией на каждый BYE или INVITE.

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

Сверка связывает четыре плоскости, не заменяя одну другой: родительский запрос, дочерние транзакции, ответы целей и наблюдаемое состояние. Несовпадения показывают, где искать отказ.

Граница доказательства

После успешного ответа допустимо утверждать: этот получатель принял этот REFER, его Content-ID разрешился в этот эффективный список, а стороны согласовали такое состояние подписки. Нельзя автоматически утверждать выполнение по всем целям.

Минимальная цепочка хранит издателя и полномочие, приложение, отсутствие fork, запрос и ответ, возвращённое Refer-Sub, объект Content-ID, исходный и нормализованный списки, каждого ребёнка, его результат, состояние сервиса с версией и временем, а человеческий или коммерческий итог — отдельно.

Один доверенный вход может породить много действий. Доверие к входу не заменяет доказательства каждого действия.