摘要

  • RFC 3428 允许 SIP 代理把同一条 MESSAGE 请求分叉发送到多个可能的终端，但只向发送方转发一条最终响应。
  • 这条响应无法告诉发送方是否发生过分叉，也不能说明有多少用户代理收到了请求，更不能证明有人读过消息。

这种差异来自协议模型本身，并不自动意味着服务故障。RFC 3428 为独立、类似寻呼的即时消息在 SIP 中增加了 MESSAGE 方法。该请求本身不会建立 SIP 对话。代理按 SIP 规则转发请求；下游代理可以把请求分叉到多个可能连接着收件人的设备。

于是，同一笔事务出现了两种视角。多个分支都可能在收到消息后返回成功响应，但分叉代理仍只向上游转发一条最终响应。RFC 3428 明确指出，用户代理客户端无法检测是否发生分叉，也不得因为只看见一条最终响应就断定仅有一个用户代理收到请求。发送端可见的响应数量，不等于接收端数量。

响应状态仍然重要，只是回答的是另一个问题。在通常由最终目的地响应的情形下，发送端收到 200 OK 可以认为消息已送达该目的地；这不表示用户看见或读过内容。用户代理可以先响应、后显示，甚至不显示。202 Accepted 的含义更有限：网关、存储转发服务器或其他服务接受了消息，但尚不能认定已到最终目的地。RFC 3428 将所需的后续确认机制留在范围之外。

因此，在还原一条记录时，发送端看到一笔事务和一个最终响应，下游日志却显示多个成功分支，两者并不矛盾。反过来，上游的单个 200 也无法证明恰好送达一次、统计接收设备数量，或证明有人注意到了消息。RFC 3428 规定的是一种可能性，并未证明某项具体服务实际分叉过消息或有人打开过消息。

该标准覆盖的交互模型也很窄：每条 MESSAGE 相互独立，所谓对话可能只存在于客户端界面或用户的理解中。RFC 将这种寻呼模型与有明确起止的会话区分开来。2019 年的 RFC 8591 更新并澄清了 SIP 消息中的部分 S/MIME 处理，但没有把 SIP 响应变成已读证明，也没有改变本文讨论的分叉计数边界。

来源：RFC 3428 第 2–8 节；RFC 3261 关于 SIP 路由和代理；RFC 8591 关于后续 S/MIME 更新。完整来源集：