RFC 3095：ROHC 从没有返回信道开始

摘要

在昂贵的无线链路上，一小段语音负载可能跟着更大的 IP、UDP、RTP 首部。若固定字段和可预测字段不再逐包发送，就能节省容量；代价是接收端必须依赖双方共享的状态重建首部。一次更新丢失，便可能让链路完整送达的后续包也无法解压。

RFC 3095 没把这个问题压成一种运行方式。它先把“状态”与“模式”分开。压缩端的初始化与刷新、一级、二级状态描述模型成熟程度；解压端的无上下文、静态上下文、完整上下文描述可安全重建的范围。模式回答的是另一问题：返回路径到底能赋予双方何种协调能力？

规范的起点很克制：压缩必须从 U-mode 开始。单向模式适用于返回路径不存在或不宜使用的链路。压缩端在重复足够信息后，依“乐观方法”判断解压端大概已经掌握上下文；超时、周期刷新和字段的不规则变化又会把它拉回信息更完整的包型。

“大概掌握”不是确认。它只是面对沉默时控制风险的办法，不能把沉默写成到达证明。

压缩端不能凭自己的愿望创造返回信道。包抵达解压端后，解压端可以发送带有目标模式的反馈，从而请求进入 O-mode 或 R-mode。

这项权力的方向有实际理由。压缩端知道自己发了什么，解压端才知道能否重建。承担眼前上下文失败的一方，把新的控制要求发回选择下一个压缩格式的一方。

RFC 4815 后来进一步说明，模式转换要用三步握手让两端一致移动。确认边界前后的包必须分别按旧模式或新模式解释。“可靠”这个名称不能代替明确的状态转换程序。

O-mode 使用返回信道发送恢复请求，也可以确认重要的上下文更新，但纯序列号更新并不获得同样待遇。周期刷新不再使用，目标是在保持高压缩效率的同时稀疏占用反向信道。

这种节省只是重新分配风险。O-mode 能在发现上下文损坏后请求恢复，却可能在长时间丢包或误码突发中比 R-mode 更频繁地失效。RFC 3095 没有掩饰这个边界。

反馈的对象仍是压缩上下文。NACK 说明重建状态需要修复，并不说明语音是否清晰、应用是否消费了负载，更不说明用户是否获得服务。

R-mode 更密集地使用返回信道，并让两端遵守更严格的逻辑。所有上下文更新，包括序列号字段更新，都要得到确认；不过并非每个 R-mode 包都会更新上下文。其“安全引用原则”规定，只有带 7 位或 8 位 CRC 的包才能修改解压上下文，并成为后续重建的引用。

这里的可靠性很具体：在首部或反馈丢失、损坏时，尽量减少损失传播与损坏传播。它没有宣布失败不可能发生。RFC 3095 仍讨论残余误码、CRC 覆盖和损坏首部到达上层的可能性。R-mode 是相对于另外两种模式的上下文同步策略，不是对负载、应用或整条路径的证书。

RFC 3096 给出了需求背景：高误码率、长往返时延的链路，并明确提到 WCDMA、EDGE、CDMA-2000。它要求语义透明：重建首部必须与原首部等价，否则应丢弃该包；它还把早期丢失导致后续首部损坏定义为误差传播。

需求没有允许一种漂亮但错误的成本算法。辅助控制与反馈信道都必须计入相对开销。正向首部很小，如果依赖反向确认、恢复消息和转换握手，就不能只展示前者。

RFC 3409 把这一点落实到下层。U-mode 不需要反馈；O-mode、R-mode 则要求下层承载小型反馈包，而且及时送达有利于效率。协议可以利用真实存在的返回能力，不能假定每条链路都会提供。

RFC 4815 汇集勘误与澄清。RFC 4995 把框架与具体配置文件拆开，并记录实现者认为 RFC 3095 的部分内容复杂或晦涩，同时说明两套框架定义兼容。RFC 5225 又给出更简化、能处理丢失与重排的 ROHCv2 配置文件。

这些材料证明规范持续演化。RFC 3241 也证明 PPP 获得了协商和承载 ROHC 的标准方式。它们都不能证明某家运营商实际部署、节省了多少频谱、完成了一次切换，或两款具体产品成功互通。

值得保存的历史边界更窄：RFC 3095 把反馈写成一项有方向、有成本、有观察者的能力。它区分压缩端的预测、解压端对共享上下文的确认，以及只有端到端观测才能证明的业务结果。