Кратко

  • Успешный ответ на REFER в RFC 3515 означал, что получатель согласился обработать инструкцию и сообщать о состоянии. Он не означал, что указанный в ней запрос завершился успешно.
  • Неявная подписка refer, уведомления NOTIFY с телом message/sipfrag и исполняемое действие жили независимо. Прекращение наблюдения не отменяло выполнение, а состояния подписок после разветвления нельзя было сливать.

Привычный рассказ о REFER похож на мгновенный перевод вызова: Алиса просит Боба связаться с Кэрол, Боб соглашается, Кэрол отвечает. Опубликованный в апреле 2003 года протокол не объединял эти моменты в одно событие. Он намеренно оставлял отдельные транзакции, потому что инструкция, попытка, отчёт и человеческий исход могли разойтись.

RFC 3515 как документ Standards Track одновременно определил метод REFER, заголовок Refer-To и пакет событий refer. Request-URI называет агента, которому поручают действие. Единственное значение Refer-To называет ресурс для контакта. Дальше получатель применяет обычный механизм соответствующей URI-схемы: например, создаёт INVITE для SIP URI или обращается к другому протоколу.

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

Сначала получатель решал, готов ли принять поручение. Ошибка синтаксиса, неподдерживаемая URI-схема, неудачная аутентификация или правило политики могли привести к отказу. Для корректного запроса следовало получить согласие пользователя либо опереться на заранее настроенное разрешение. Если иной окончательный ответ не применялся, исходный документ требовал отправить 202 Accepted до истечения транзакции REFER.

Именно слово Accepted чаще всего вводит в заблуждение. Оно отвечало на узкий вопрос: взял ли агент на себя обработку REFER? Оно не утверждало, что последующий INVITE получил финальный 200, что ресурс вне SIP ответил, что появился медиапоток, что человек вступил в разговор или что деловая цель достигнута. Указанный запрос в этот момент мог быть ещё не отправлен.

По первоначальному контракту ответ 2xx также создавал неявную подписку на событие refer. Принявший агент должен был посылать NOTIFY. Этот канал был не декоративной телеметрией, а способом передать сведения о прогрессе, которых в ответе на REFER ещё не существовало.

Первый NOTIFY мог прийти до завершения самой транзакции REFER. Отправитель должен был выдержать кажущееся нарушение порядка: поток наблюдения начинался, пока обмен принятия ещё закрывался. Уведомление о незавершённой работе могло содержать только SIP/2.0 100 Trying. Это была текущая оценка состояния, а не доказательство контакта с целью.

Каждый NOTIFY содержал Event: refer и тело message/sipfrag, начинавшееся со строки статуса SIP. Класс ответа описывал состояние указанного действия в момент отчёта. RFC рассматривал каждое тело как полное заявление о текущем состоянии, а не как дельту, смысл которой можно понять лишь после сборки всей истории.

Минимальная реализация могла сообщить 100 для ожидания, 200 для успеха, 503 для ошибки либо 603, если после принятия REFER пользователь отказал в разрешении. Такая последовательность объясняет, почему исходный 202 был намеренно слабее успеха действия. Поручение принято, но локальное согласие или делегированная операция ещё способны закончиться отказом.

Кроме того, существовали два разных ответа класса 200. Получатель NOTIFY подтверждал собственную транзакцию NOTIFY ответом 200 OK. Это говорило о доставке отчёта. Строка статуса внутри message/sipfrag относилась к указанному запросу. Если журнал подписывает оба события просто как «200», он уничтожает важную границу доказательств.

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

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

У подписки был собственный срок. REFER не задавал его в запросе или ответе. Принявший агент выбирал продолжительность и объявлял её в первом NOTIFY, обычно оставляя достаточно времени для завершения указанного запроса. Инициатор мог продлить подписку либо завершить её раньше.

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

Это решение важно далеко за пределами SIP. Системы часто принимают «больше не присылайте обновления» за «остановите задачу» или считают исчезновение строки в панели доказательством окончания процесса. Архитектура RFC 3515 проводила обратную границу: подписка управляла отчётами, а выполняемая транзакция сохраняла собственную семантику отмены.

Разветвление добавляло ещё одно различие. REFER внутри существующего диалога по правилам документа не разветвлялся. Вне диалога запрос мог достичь нескольких агентов, каждый из которых принимал его и создавал отдельную подписку. Инициатор должен был вести их независимо и не объединять состояние. Ответ 200 одной ветви и 503 другой описывали действия разных получателей, а не один усреднённый исход.

Идентификаторы диалога связывали NOTIFY с правильной подпиской, но корреляция не заменяла авторизацию. Получатель по-прежнему решал, кто вправе заставить его обратиться к какому ресурсу. Неосторожная политика могла превратить REFER в косвенный путь к защищённым целям SIP, HTTP или иных протоколов. Формирование Refer-To и локальная проверка были частью рубежа безопасности.

Позднейшие документы изменили варианты наблюдения. RFC 4488 разрешил просить об отключении неявной подписки. RFC 7614 определил явные подписки. RFC 7647 уточнил REFER в модели событий, обновлённой RFC 6665, а RFC 8217 скорректировал связанную синтаксическую часть. Ни одно обновление не сделало принятие равным результату. Напротив, при нескольких режимах важно фиксировать, какой контракт управлял конкретным обменом.

Здесь полезно различие Heng Lu между символической и операционной реальностью. Ответ 202 — символическая квитанция об ограниченной ответственности. NOTIFY — заявление известного уведомителя в рамках подписки. Указанный запрос исполняется по правилам своего протокола. Медиапоток, речь, согласие человека и коммерческое завершение находятся ещё дальше. Верное сообщение одного слоя не создаёт квитанций следующего.

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

Исторический урок RFC 3515 не в том, что делегирование ненадёжно. Делегированию нужны раздельные записи об инструкции, наблюдении и исполнении. REFER действительно приняли, и этот факт полезен. Но действие ещё должно было произойти в другом месте, а успех требовал собственного доказательства.

Источники