Кратко

  • RFC 3428 разрешал SIP-прокси разветвлять один запрос MESSAGE на несколько возможных терминалов, передавая отправителю лишь один финальный ответ.
  • По этому ответу отправитель не мог определить, было ли разветвление и сколько пользовательских агентов получили запрос; он также не доказывал, что человек прочитал сообщение.

Это расхождение было частью модели протокола и само по себе не означало сбой службы. RFC 3428 добавил в SIP метод MESSAGE для отдельных сообщений в режиме, похожем на пейджер. Такой запрос сам по себе не устанавливает SIP-диалог. Прокси маршрутизируют его по правилам SIP, а прокси на пути может разветвить запрос на несколько устройств, где получатель потенциально доступен.

Так возникают два взгляда на одну транзакцию. Несколько ветвей могут успешно ответить после получения сообщения, но разветвляющий прокси передаёт выше только один финальный ответ. RFC 3428 прямо указывает: клиент отправителя не способен обнаружить факт разветвления и не должен считать, что один видимый ответ означает получение запроса лишь одним пользовательским агентом. Число ответов, видимых отправителю, не равно числу получателей.

Код ответа по-прежнему важен, но отвечает на другой вопрос. В обычном случае ответа от конечного назначения 200 OK позволяет отправителю считать, что сообщение доставлено этому назначению. Это не означает, что пользователь увидел или прочитал текст. Агент может ответить до отображения сообщения и не обязан отображать его. 202 Accepted означает лишь, что шлюз, сервер хранения с последующей пересылкой или иной сервис принял сообщение; доставка конечному адресу не подтверждена. RFC 3428 оставляет дополнительное подтверждение за пределами стандарта.

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

Модель документа была узкой: каждый MESSAGE независим, а впечатление беседы может существовать лишь в интерфейсе клиента или восприятии пользователей. RFC отличает такой пейджерный режим от сессии с явным началом и завершением. Позднее RFC 8591 уточнил и обновил отдельные аспекты S/MIME для SIP-сообщений, но не превратил ответ SIP в подтверждение прочтения и не изменил разбираемую здесь границу учёта ветвей.

Источники: разделы 2–8 RFC 3428; RFC 3261 о маршрутизации SIP и поведении прокси; RFC 8591 о позднейших обновлениях S/MIME. Полный список: