Кратко

  • В RFC 6665 значение Subscription-State: terminated означает прекращение активности подписки, а не универсальное исчезновение или завершение наблюдаемого ресурса.
  • Причины предполагают разные продолжения: deactivated может указывать на миграцию, timeout допускает новую подписку, invariant описывает устойчивое состояние, и только noresource прямо говорит, что состояние ресурса больше не существует.
  • Надёжное свидетельство раздельно сохраняет жизненный цикл подписки, тело состояния ресурса, транзакцию NOTIFY, интерпретацию пакета и последующее действие человека или автоматики.

Красный индикатор объединил два автомата состояний

Слово «terminated» провоцирует грамматическую ошибку. Рядом с устройством, учётной записью, вызовом или адресом оно выглядит определением показанного существительного. Однако в заголовке RFC 6665 речь идёт о подписке. Получив это значение, подписчик обязан считать конкретную подписку завершённой. Вывод обязателен, но его предмет узок.

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

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

Семь причин ведут к нескольким будущим

Причины завершения в RFC 6665 имеют разный операционный эффект. deactivated требует немедленно создать новую подписку; один из главных случаев — миграция между узлами уведомления. probation откладывает повторную попытку. rejected сообщает об изменении политики авторизации и советует не повторять запрос. timeout означает, что подписка не была продлена до истечения срока, но разрешает подписаться снова сразу. giveup говорит, что сервер уведомлений не сумел вовремя получить авторизацию.

Граница особенно заметна в паре noresource и invariant. Первая причина утверждает, что наблюдаемого состояния ресурса больше нет. Вторая гарантирует, что это состояние не изменится в обозримом будущем. В обоих случаях повторная подписка не рекомендуется, но один описывает отсутствие, другой — сохранение. Общее значение «всё закончилось» уничтожает смысл обоих.

Причина может отсутствовать или оказаться неизвестной. Тогда клиент вправе подписаться снова с учётом retry-after, но наблюдатель не получает права подставить noresource. Не помогает и параметр expires при завершённом состоянии: спецификация лишает его здесь семантики и требует игнорировать.

Последнее уведомление не обязано содержать последнее значение ресурса

Отписка выполняется запросом SUBSCRIBE с Expires: 0. Успешная отписка вызывает финальный NOTIFY, однако RFC 6665 предупреждает: запрос может содержать сведения о состоянии ресурса, а может не содержать их. Подписчик обязан обработать обе формы.

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

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

Подтверждение создания может обогнать видимый порядок диалога

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

Здесь работают как минимум трое часов: транзакционные отсчитывают запросы и ответы, часы подписки — создание, продление, истечение и завершение, часы ресурса — изменения, описанные пакетом. Четвёртые принадлежат наблюдателю, который принимает, разбирает и показывает сообщение. Если сортировать всё по времени захвата и объявлять последнюю строку истиной, причина и следствие могут поменяться местами.

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

Usage может закончиться, пока dialog продолжается

RFC 6665 определяет подписку как прикладное состояние, связанное с dialog. RFC 5057 Роберта Спаркса объясняет, почему связь нельзя принимать за тождество. Dialog usages имеют независимые жизненные циклы, хотя разделяют состояние dialog. При переводе вызова invite usage и subscription usage могут находиться в одном dialog; подписка завершается, а invite usage остаётся.

Последующие работы уточнили поверхность управления. RFC 7621 разъясняет использование GRUU, чтобы запрос попадал на нужный экземпляр пользовательского агента. RFC 7647, написанная Sparks и Roach, рассматривает неявные подписки REFER и проблемное повторное использование dialog. Более точное назначение и чистая структура уменьшают неопределённость в том, какой usage породил событие, но не превращают terminated в утверждение о ресурсе.

Поэтому ярлык «сеанс завершён» тоже опасно широк. Подписка, dialog, dialog usage, вызов, экземпляр сервера уведомлений и определённый пакетом ресурс связаны, но не являются синонимами. Каждому нужны собственный идентификатор и собственное следующее состояние.

Roach создал рамку, сохраняющую границу

RFC 6665 опубликована в июле 2012 года как документ Standards Track и заменила RFC 3265. Adam Roach указан единственным автором обеих. Текущий профиль IETF отмечает его участие с 1998 года, работу Applications and Real-Time Area Director в 2017–2020 годах и прежнее председательство в XCON, SIPCORE и NETVC. В профиле перечислены 23 RFC и нет активных ролей по состоянию на 22 апреля 2026 года.

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

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

Идентичность: какой dialog, пакет, адрес и локальный ключ? Жизненный цикл: какое состояние, причина, правило истечения и время получения? Ресурс: было ли тело, какой пакет его истолковал, какие хеш и версия сохранены? Транспортная цепочка: какой сервер уведомлений, аутентификация, транзакция и ответ? Действие: система повторила запрос, ждала, мигрировала, подняла тревогу или закрыла случай, и по чьему правилу?

Разделение не ослабляет автоматизацию. timeout может открыть инцидент разрыва мониторинга, не объявляя ресурс мёртвым. deactivated может оставаться нерешённым до первого NOTIFY от преемника. noresource перед необратимым шагом может потребовать прикладного подтверждения. Отсутствующая причина честно отображается как неизвестная.

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

Источники