摘要

  • RFC 4028 只有在会话刷新 re-INVITE 或 UPDATE 收到 2xx 时才延长 SIP 会话期限；请求已经发出、收到 422 或中间节点看见流量都不能替代这一步。
  • Session-Expires、Min-SE 与 refresher 分配刷新频率、责任与清理边界，不证明 RTP 媒体可用、用户仍在、质量合格或计费合理。
  • 可追责的系统把事务、对话、媒体、应用和商业状态分别保留，再解释它们为什么一致或分离，而不是压成一个“通话存活”布尔值。

一个 200 OK 如何制造过大的结论

设想一通企业语音会话。SIP 信令经过保留呼叫状态的代理，RTP 媒体走另一条网络路径。刷新方在会话间隔过半时发送不带 SDP 的 UPDATE，对端正常返回 200 OK。代理把本地到期时间向后移动。

与此同时，媒体路径的一侧已经中断。RTP 计数停止，RTCP 接收报告消失，用户听见的只有静音。终端软件没有发 BYE，自动刷新仍然运行。计费系统只消费“session refreshed”事件，于是继续累计时长。

这不要求 RFC 4028 实现出错。刷新事务可以完全正确，计时器也可以正确延期。错误来自证据越权：一个描述 SIP 状态的事件被要求代表媒体、人的行为和商业交付。

RFC 4028 解决的是更窄的问题。SIP 核心无法保证呼叫结束时一定有 BYE 到达。终端可能没有发送，网络也可能把它丢掉。保留呼叫状态的代理若没有其他机制，就可能长期占用状态与资源。周期性的 re-INVITE 或 UPDATE 让信令状态具备可更新的期限。

该 RFC 特意说明，音频会话还可能从 RTCP 获得会话特有的活性信号。SIP 计时器之所以存在，正是为了把“信令会话是否仍被维护”与具体媒体机制分开。分开本身不是缺陷；把分开后的答案重新混成一个答案才是。

同一个字段背后的三种时间

运营界面常把 Session-Expires 直接标成“通话超时”。规范实际区分三件事。

会话间隔是两次成功刷新之间允许经过的最长时间。当前值取自最近一次相关 2xx 响应中的 Session-Expires。

最小计时器是节点愿意接受的最快刷新频率。对话内请求会消耗处理能力，因此 Min-SE 防止某一方强迫整条路径高频刷新。

会话到期时间则由各节点本地计算。UAS 从发送最后一个 2xx 的时刻开始，UAC 从收到它的时刻开始，代理从自己转发和观察响应的时刻开始。网络传输与排队意味着这些截止点彼此接近，却不是一个由所有人共同签署的全球时刻。

事故记录若只写“间隔 1800 秒”，仍然缺少决定性信息：哪个响应安装了它，谁是刷新方，每个节点何时启动本地倒计时，后续响应是否移除了计时器。更稳妥的实现使用单调时钟保存本地截止点，同时保留来源事件与墙钟时间用于重建。

一条路径共同塑造间隔

初始 UAC 可以用 timer 选项标签表明支持，并提出 Session-Expires。保留状态的代理也有利益，因为它们需要知道何时释放呼叫资源。代理可以请求启用计时器、缩短会话间隔或提高 Min-SE，但不能把间隔压到累计最小值以下。

UAS 在 2xx 中确定最终间隔并写入 refresher。响应返回途中，代理可以观察最终值，却不能再次改写。

若某节点认为提出的间隔太短，它返回 422 Session Interval Too Small，并给出自己的 Min-SE。UAC 可以用更大的 CSeq 发起新事务，并记住相关 422 中最大的最小值。

422 是协商证据，不是刷新成功。旧的到期时间继续前进。若 422 在旧期限临近时出现，新请求虽然为未来提出更长间隔，却仍必须在当前期限内拿到 2xx。只记录最终 200 会把最危险的窗口抹掉。

最小间隔也是拒绝服务防护。恶意端点或路径节点若能强迫每秒刷新，会把少量会话放大成大量工作。422 激增可能来自路由变化、策略调整、容量保护、错误默认值或攻击；响应码本身不会替运营者完成归因。

uac 与 uas 不是永久身份

refresher=uac 或 refresher=uas 只说明谁负责下一次刷新。UAC 和 UAS 是当前 SIP 事务的角色，并不是永久的呼叫方、被叫方、客户账户或人的身份。

初始 INVITE 的接收端在主动发送后续 UPDATE 时会成为新的 UAC。RFC 4028 对后续请求中的参数另有规则，使实际刷新责任可以在事务角色翻转时保持稳定。

因此，日志只保存 uac 会造成归责错误。必须把角色解析到本次事务中的具体端点，并同时保存对话标识、方法、CSeq 与方向。

分叉让问题更复杂。一个 INVITE 可能建立多个对话。每个对话可以拥有不同间隔、不同刷新方、不同到期点，甚至没有计时器。一条分支的成功刷新不能替另一条分支续命。

刷新责任也可以在后续协商中重新选择。更隐蔽的是，最近一次 2xx 若不含 Session-Expires，计时器可以在对话中途被关闭。“这通呼叫曾经启用 timer”不是当前状态证明。

延长期限的唯一门槛

RFC 4028 的边界十分明确：只有刷新请求得到 2xx 才延长会话到期时间。

UPDATE 已发出不算；临时响应不算；401 或 407 挑战不算；422 不算；套接字写入成功不算；代理看见请求进入也不算。认证后的重试以后可能成功，但第一次尝试不能提前占用成功的含义。

刷新事务超时或返回 408、481 时，作为刷新方的 UA 按规则发送 BYE。其他错误可以触发有限重试，却不应无限重复同一失败。

非刷新方的责任不同。若到期前没有收到刷新，它应略早于截止点发送 BYE。建议提前量为 32 秒与间隔三分之一中的较小者。原因很实际：防火墙或 NAT ALG 可能在期限一到就不再放行 SIP，等到最后一刻才发 BYE 反而送不出去。

代理拥有更小的权限。自身到期后，它可以删除呼叫状态、释放资源；它不得代表 UA 发 BYE。代理有权清理自己的账本，没有权冒充端点宣布对话结束。

于是多个真实状态可能短暂分离：代理已经忘记会话，直连媒体仍在；一侧发送了 BYE，另一侧没有收到；不同节点的本地截止点相差若干毫秒或秒。把它们事后压成一个“挂断时间”，只会制造虚假的精度。

刷新消息可能同时改变别的东西

会话刷新使用的 re-INVITE 或 UPDATE 仍是普通 SIP 请求，不是脱离方法语义的心跳。

RFC 3311 允许 UPDATE 修改会话信息，也把它作为目标刷新请求。RFC 3261 则让 re-INVITE 进入对话、目标地址与 offer/answer 规则。

RFC 4028 建议在对端支持 UPDATE 时，用不带 offer 的 UPDATE 做纯计时刷新。re-INVITE 通常应带 offer，即使会话描述没有变化，也必须以规范方式表明未变化。另一方面，为了 hold、恢复或更改媒体而发送的请求也会顺便刷新计时器。

所以，同一个 2xx 旁边可能同时发生：计时延期、Contact 改变、SDP 交换、媒体方向变化、地址或编解码器更新、认证重试或请求竞争解决。RFC 6141 之所以专门处理 re-INVITE 竞争、491、状态恢复和目标更新，正因为 re-INVITE 从来不是简单 ping。

遥测至少要记录请求是否原本只为 timer、是否携带 SDP、SDP origin 版本和流方向是否变化、Contact 是否变化，以及哪个最终响应完成事务。“refresh success”无法承担这些信息。

媒体有自己的事实体系

RFC 3264 的 offer/answer 可以把流协商为 sendonly、recvonly、sendrecv、inactive，或用端口零拒绝。它描述双方允许或希望的媒体状态，不是数据包收据。

RFC 3550 明确指出 RTP 不保证交付，也不保证服务质量。RTCP 能提供接收报告、同步与参与者信息，是重要证据，但仍不能证明一个人听见、理解、同意或获得商业价值。

至少应区分五层：SIP 事务；对话与计时器；RTP/RTCP 媒体；应用与人的行为；合同、计费和合规。2xx 对前两层很强，对后三层只能提供背景。

信令成功刷新时媒体可以已经死亡。信令分区时媒体可以暂时继续。inactive 流可以完全符合协商。无人参与时软件仍可自动刷新。

这与 Heng Lu 所说的现实层相呼应：符号记录并非虚假，但它不能因为整齐、可查询，就取得对执行现实的主权。真正承载、测量、计费和恢复的系统仍要为各自决定负责。

逐跳完整性也有尽头

代理本来就会合法修改计时器字段，因此端到端 S/MIME 不适合保护它们。RFC 4028 建议在相关每一跳使用 TLS，并配合 SIPS。

这能减少外部攻击者篡改间隔、制造高频刷新，但前提是路径上每一跳都得到保护。受保护的 Session-Expires 仍只是计时政策，不会变成人在场或计费授权的证明。

RFC 4028 勘误登记 含有已经验证的 UAC/UAS 用词和示例修正，也含未定案的技术建议。2026 年 5 月一条 Reported 勘误讨论代理在显式 refresher=uas 情形下的处理。它值得做互操作测试，却不能当作已经生效的规范修改。

能经受争议的证据链

可重建的记录把 Call-ID 和双方 tag 与每次事务的实际角色绑定，保存方法、CSeq、branch、route、每跳前后的 timer 字段、请求与响应时间、本地到期点，以及真正推动期限的 2xx。

同时保存副作用：SDP 是否存在及其哈希、offer/answer 版本、媒体方向、Contact、认证挑战和重试。BYE 需要来源与原因：用户动作、刷新失败、等待超时还是应用政策。

媒体、应用和计费证据保持独立但可关联。SIP 原文含身份与拓扑，可放在受限事故存储；一般指标使用带密钥指纹或字段投影即可。

测试应覆盖临近期限的 422、401 后成功、408、481、非刷新方等待超时、代理清理但无 BYE、媒体死而 SIP 新鲜、媒体活而信令丢失、多分支不同计时、2xx 移除计时器、不带 offer 的 UPDATE、带变化 SDP 的 re-INVITE、目标刷新、故障切换丢状态，以及缺少逐跳保护。

最终产物不该是一个绿灯，而是一条能回答“哪一层还活着、谁依据什么采取了行动”的时间线。

来源