Summary

  • RFC 3428 allowed a SIP proxy to fork one MESSAGE request to several possible terminals, while forwarding only one final response to the sender.
  • That response could not tell the sender whether a fork occurred or how many user agents received the request; it did not prove that a person read it.

The mismatch was built into the protocol model, not necessarily evidence of a broken service. RFC 3428 added MESSAGE to SIP for standalone, pager-like instant messages. A MESSAGE request does not itself establish a SIP dialog. Proxies route it under SIP rules, and a downstream proxy may fork the request toward multiple devices where the recipient might be.

That creates two different views of one transaction. Several branches may return successful responses after receiving the message. The proxy nevertheless forwards one final response upstream. RFC 3428 says the user-agent client has no way to detect whether this fork happened and must not infer that only one user agent received the request from the single response it sees. The sender-visible response count is not a recipient count.

Status still matters, but it answers a different question. In the ordinary final-destination case, 200 OK lets the sending client assume delivery to that destination; it does not mean the user saw or read the content. A user agent need not display the message before replying. 202 Accepted is weaker: a gateway, store-and-forward server, or another service has accepted it, but final delivery is not established. Confirmation after a 202 requires another mechanism outside RFC 3428.

The distinction is useful when reconstructing a trace. A sender may have one transaction and one final response while downstream logs show multiple successful branches. Those records are not contradictory. Conversely, one upstream 200 alone cannot establish exactly-once delivery, the number of receiving devices, or human attention. RFC 3428 specifies what may happen; it does not show that a named service forked a message or that a person opened it.

The method also belonged to a narrow interaction model. The RFC described each MESSAGE as standalone, with any apparent conversation grouping supplied by the client interface or the users. It distinguished that pager model from a session with an explicit beginning and end. Later RFC 8591 updated and clarified S/MIME handling for SIP messaging; it did not turn a SIP response into proof of reading or change the fork accounting point examined here.

Sources: RFC 3428 Sections 2–8; RFC 3261 for SIP routing and proxy behavior; RFC 8591 for later S/MIME updates. Full frozen source set: