摘要

  • RFC 3322 以 9.6 kbit/s 链路和 140 ms 往返时延计算一组 SIP/SDP 消息，总计 4,131 ms；文档同时明确称这个近似“相当粗略”。
  • 这个数字用于约束压缩方案的设计目标，不是用户实测、SigComp 部署证明，也不是压缩必然带来某种收益的承诺。

没有进入公式的重传

计算方法看起来十分精确：消息的比特数除以每秒 9,600 比特，再加上 70 ms，也就是假定往返时延的一半。把 INVITE、临时响应、PRACK、200 OK 和最后的 ACK 依次代入，信令部分得到 4,131 ms。无线承载建立、RSVP 与会话管理还会带来另外的近似时间。

真正决定这个数字性质的，是文档随后列出的限制。模型假设路径中只有一段蜂窝链路；中间 IP 网络被简化处理；消息大小只是典型值；由错误引起的可能重传没有计算。无线系统用前向纠错、交织与 ARQ 降低损失，同时也可能增加时延。公式固定了前两个时钟，却没有让重传时钟运行。

因此，4.131 秒不是错误数字，而是有边界的数字。它回答的是：在指定速率、RTT 与消息序列下，序列化和传播会累积多少时间。它没有回答某位用户实际等了多久，也没有证明 SigComp 在生产环境中节省了多少时间。RFC 3322 还引用了普通 GSM 呼叫约 3.6 秒、SIP 场景约 7.9 秒的比较；那同样是需求背景，不是普遍服务等级。

需求文档位于实现之前

RFC 3322 于 2003 年 1 月以 Informational 身份发布。它不定义互联网标准，而是整理为什么需要信令压缩，以及未来方案必须满足什么条件。SIP、SDP 和 RTSP 都以文本为主，在建立阶段需要多轮请求与响应。每一次等待都可能把有限无线容量转化为用户可感知的停顿。

文档比较了五条道路。提高单用户速率会减少小区可承载用户，并且在小区边缘未必可行。降低 RTT 需要系统级改造。改变请求响应顺序会改动上层协议。删除字段虽然缩短消息，却破坏透明性和端到端原则。压缩的优势，是可以更换传输表示而不改写应用消息。

这个选择仍然只是设计方向。写下“必须”不等于实现已经合规；发布 RFC 不等于网络自愿采用；后来存在代码也不等于某次会话协商启用了它。证据必须逐层保存，不能用文档权威代替运行事实。

比特完全一致划定了控制边界

第一项一般需求规定：压缩后再解压的结果必须与原消息逐比特一致。SigComp 可以节省无线传输资源，却不能借机编辑 SIP 或 SDP 的语义。它还要与 ROHC 头压缩共存，允许支持与不支持压缩的端点互通，处理任意消息流，而不是依赖固定会话模式。

方案必须同时适用于 UDP 与 TCP，也必须能在没有解压端显式反馈的单向路由上工作，尽管效率可能降低。是否使用压缩的协商被明确排除在压缩方案范围之外，应由产生消息的协议处理。这意味着，在设备中发现 SigComp 能力，不足以证明某条会话实际使用了 SigComp。

性能需求同样是待验证的约束。终端内存和处理能力不同，方案必须可伸缩。为了提高压缩率而排队等待多条消息，会增加原本想消除的时延，因此不可接受。低层未发现的残余错误不应经常造成错误解压；单条消息损坏不应污染后续所有消息；轻度乱序和丢失后，后面的消息仍应可用。

RFC 3320 的体系结构、RFC 3485 的 SIP/SDP 静态字典、RFC 3486 的 SIP 用法，以及 RFC 4077 与 RFC 5049 的后续指导，构成了一条设计演进链。它证明工程工作继续推进，却不能自动证明普及率、互操作质量或实际时延收益。

RFC 3322 留下的历史方法很清楚：模型用于比较，需求用于约束，实现用于接受检验，部署结果需要独立观测。把四者折叠成一个数字，才是对技术史最危险的压缩。

这种区分还解释了为什么需求文档值得单独保存。若只留下后来发布的协议，人们会误以为所有结构都来自抽象优雅；若只留下部署数据，又会看不见工程师当时试图避免哪些失败。RFC 3322 把约束条件、被拒绝的方案和不确定性同时写下，使后来的测试能够追问：实现是否保持逐比特透明，是否真的减少用户等待，是否在单向路径、丢包和乱序下仍可恢复。历史证据的价值不在于替实现宣布胜利，而在于让实现面对最初的问题。

这才是边界。

Sources