Кратко

  • RFC 5263 запрещает агенту присутствия посылать следующий частичный NOTIFY для того же Request-URI до финального ответа или истечения предыдущей транзакции. Правило сериализует передачу, но не даёт квитанцию о долговременном состоянии наблюдателя.
  • Надёжная запись связывает подписку, версию и тело NOTIFY с ответом SIP, результатом разбора и патча, хешами до и после, подтверждением хранилища и показом следующему потребителю.

Хранилище молчало, а очередь уже двигалась дальше

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

После перезапуска процесс вернулся к старой копии и запросил полное состояние. В журнале отправителя сохранился аккуратный 200. В журнале состояния не было долговременного изменения.

RFC не обещает такой конкретный сбой, но его границы позволяют точно сформулировать доказательство: ответ относится к автоматической SIP-транзакции. Устойчивость локального результата нуждается в отдельном событии.

Финальный ответ освобождает следующую отправку

Presence Agent не должен посылать новый частичный NOTIFY для того же Request-URI, пока не получил финальный ответ на предыдущий запрос или пока тот не истёк. Так зависимые изменения не накапливаются в пути без контролируемой последовательности.

Общий механизм событий SIP предписывает обычно отвечать 200 на приемлемый NOTIFY. Транзакция не должна длиться дольше автоматической обработки, и подписчик не вправе ждать реакции пользователя перед финальным ответом.

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

Координатой версии служит подписка

Наблюдатель, разрешающий частичные уведомления, объявляет application/pidf-diff+xml вместе с application/pidf+xml. Предпочтение можно задать, но локальная политика агента участвует в выборе формата.

Первое уведомление в частичном формате содержит полное состояние и начинает версию с единицы. Счётчик относится к подписке, не сбрасывается при обновлении и сбрасывается при её завершении.

Поэтому ответ хранится вместе с Request-URI, диалогом, Call-ID, тегами, CSeq, версией и хешем тела. Число без подписки не является глобальным адресом состояния. Ответ без тела не показывает, какой локальный переход ожидался.

Успешная отправка остаётся фактом отправителя

Агент увеличивает версию относительно ранее успешно отправленного этому наблюдателю частичного документа. Получив финальный ответ или timeout, он может двигать своё окно.

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

В нормальной работе этапы близки. В расследовании близость не заменяет причинную запись. Каждый этап требует собственного владельца и подтверждения.

Сравнение версий определяет локальный результат

Версия, равная локальной или меньшая, считается ошибкой агента и должна быть отброшена. Дельта ровно на единицу выше применяется к полной копии и продвигает счётчик. Прыжок больше единицы означает предполагаемую потерю; наблюдатель должен обновить подписку ради полного состояния либо завершить её.

Отбросить, применить и начать восстановление — разные изменения локальной реальности. Финальный SIP-ответ на границе не кодирует их с достаточной точностью.

Квитанция должна сохранить ожидаемую и полученную версии, выбранную ветвь, результат патча и итоговый хеш.

Ошибка обработки может не вернуться отправителю

Если частичный документ не удаётся обработать, RFC 5263 советует обновить подписку. Наблюдатель также может убрать частичный MIME-тип из нового SUBSCRIBE и вернуться к полным документам.

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

Отсутствие сообщения об ошибке не доказывает успешного применения.

При смене формата номер остаётся, содержимое исчезает

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

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

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

Подлинность сообщения не равна устойчивому применению

RFC 5263 наследует требования к конфиденциальности, целостности, подлинности, защите от повторов и отказу в обслуживании. В исходном контексте рекомендуется TLS между узлами и допускается S/MIME; RFC 8996 обновляет зависимость, выводя TLS 1.0 и 1.1 из употребления.

Внедрённый частичный NOTIFY может создать ложный разрыв и вызвать запрос полного состояния. Защита от этого важна. Но подлинное сообщение всё ещё может не пройти разбор, патч, сохранение или показ.

Криптографическая история и завершение SIP входят в цепочку доказательств. Они не заменяют квитанцию локального состояния.

Квитанция состояния наблюдателя

Для решений с последствиями сохраняйте:

  • presentity, наблюдателя, Request-URI, подписку, диалог и пакет событий;
  • допустимые типы, предпочтения и локальный выбор агента;
  • Call-ID, теги, CSeq, тип, байты, хеш и время NOTIFY;
  • версию подписки и ожидаемое предыдущее значение;
  • код и время ответа SIP, timeout или повтор;
  • результат разбора и точную ошибку обработки;
  • хеш полного документа до применения и результат патча;
  • реконструированный хеш, локальный счётчик и подтверждение хранения;
  • обновление, fallback, смену формата и заменяющее полное состояние;
  • идентичность, хеш и время показа нижестоящему компоненту; и
  • отображение, попытку контакта, доставку и человеческий или сервисный результат.

Квитанция сохраняет правильный смысл 200: окончание транзакции, а не выдуманное доказательство всех последующих стадий.

Sources