摘要

  • RFC 3680 将地址的注册状态与其联系人集合分开建模。即使没有任何已注册联系人，地址仍处于定义明确的 init 状态。
  • 通知常常只列出发生变化的联系人。订阅方需要依版本顺序应用更新，发现版本跳跃时请求完整刷新；这并不能证明有人在线、设备可用或呼叫成功。

空列表并不等于没有答案。RFC 3680 规定，一个 Address-of-Record（AoR，记录地址）即使没有绑定任何联系人，仍保有 init 状态。状态机属于 AoR；每个联系人另有自己的状态机，只在该联系人注册期间存在。

RFC 3680 于 2004 年 3 月发布，为 SIP 定义了 reg 事件包。获得授权的订阅方发送 SUBSCRIBE，接收 application/reginfo+xml 格式的注册信息。初始通知可以给出完整状态，后续通知通常只包含变化部分。文档用 full 或 partial 标明范围，并带有版本号：每个订阅从 0 开始，之后逐次加一。

增量通知节省传输，却把拼接责任交给订阅方。一个变化包不会重新列出所有未变联系人，因此本地程序必须维护联系人表，并按顺序合并通知。恰好连续的下一版本可以继续处理；低于本地版本的旧文档应丢弃。如果收到的版本向前跳过了一个或多个序号，RFC 3680 建议订阅方刷新，以触发完整状态通知。否则，本地表看起来可能合理，实际上已悄悄漏掉一次变化。

AoR 状态机解释了“最后一个联系人消失”意味着什么。第一个联系人注册后，AoR 从 init 转入 active；只要仍有联系人，它就保持活动。当最后一个联系人到期或被移除，AoR 先转为 terminated，随即回到 init。这个最终转换不得出现在 NOTIFY 中。联系人自身的终止可以作为联系人变化报告。联系人绑定结束了，地址本身却仍保有可报告的状态。

这里的 active 只是注册事实，不是人的状态。它不说明用户此刻有空，不保证设备当前开机，也不保证一次 INVITE 能送达。RFC 3856 另行定义了 SIP Presence（呈现状态）事件包；注册信息可以作为组合呈现状态的原始输入，但二者语义不同。标准文本本身也不能证明任何具体实现遵循了这些规则。

RFC 3680 的价值在于划清观察边界：授权观察者可以获知注册变化；空联系人集合仍有明确状态；漏掉增量后有重新同步的办法。实际排查时，问题不只是“有没有联系人”，还包括“当前视图对应哪个订阅版本、是否漏过更新，以及注册证据究竟能证明什么”。

来源