摘要

  • RFC 3952 没有在 RTP 载荷中写入 iLBC 帧数；接收端必须根据 SDP 中协商的模式，用载荷长度除以每帧 38 或 50 字节。
  • 2026 年提交的一项 Reported 勘误建议把正文里的 32/50 改为 38/50；它提醒我们，长度正确不等于解释、认证、解码和播放结果都正确。

两个同样整齐的数据包

76 字节可以是两个 20 毫秒帧，100 字节可以是两个 30 毫秒帧。两者都整齐，帧数却不是数据包里的一个字段。RFC 3952 要求接收端先知道会话模式，再把 RTP 载荷总长度除以该模式的固定帧长。

这是一种精简而非缺失。20 毫秒模式每帧 38 字节，30 毫秒模式每帧 50 字节；固定长度使显式计数显得多余。但被省去的含义没有消失，而是转移到了会话控制面。只保存 RTP 字节、不保存当时有效的 SDP，事后就可能拥有完整数据却没有完整解释。

规范还封住了几条会破坏除法的路径：一帧不得拆到两个 RTP 包中，两种模式的帧不得混装在同一包里，聚合帧数不应越过传输 MTU。少装帧可以降低打包等待，代价是更多报头；多装帧可摊薄报头，却增加延迟，并让一次丢包带走更长语音。这些规则让计算成立，但不让数据包自行声明模式。

真正的除数来自 SDP

iLBC 在 SDP 中写作 iLBC/8000，模式通过 a=fmtp 参数传递。没有 mode 时，RFC 3952 规定默认使用 30 毫秒。它还特别指出该参数是双向的：双向会话的两端必须得到同一个结果。

Offer 可以提出偏好，Answer 可以同意也可以写另一个模式。共同结果取两者中带宽较低的模式。这里的数字容易误导直觉：30 毫秒帧虽更长，却是 50 字节；20 毫秒模式每 20 毫秒要发 38 字节，单位时间负担更高。因此规范给出的两种交叉示例都落到 mode=30。

协商结果由此控制了媒体解析。载荷类型告诉接收端“这是 iLBC”，模式再告诉它“每多少字节切一刀”。序列号与时间戳由 RFC 3550 提供排序和计时语义，却不能代替这个除数。RFC 2327 的 SDP 结构与 RFC 3264 的 Offer/Answer 过程共同保存了会话上下文；成功协商仍不证明后续发送端始终遵守它。

32 与 38 的冲突为何值得记住

RFC 3952 第 2 节和第 3.1 节都把 20 毫秒帧写为 38 字节，RFC 3951 的编解码定义也支持这一尺寸。然而第 3.2 节讲述“长度除以每帧字节数”时，却印成了 32/50。

RFC 3952 勘误页中的 Errata 8866 于 2026 年 4 月 3 日提交，建议改成 38/50。截至本次冻结，它仍是 Reported，而不是 Verified。内部一致性使 38 很有说服力，但编辑判断不能冒充流程已经确认；文章必须同时保留“冲突存在”“修订已提出”“状态仍待处理”三项事实。

这个错误之所以重要，不是因为六个字节必然造成了某场已知事故——没有证据支持那种说法——而是因为它刚好落在解释权的接缝上。实现若遵循完整规范，会从多处知道 38；只摘录那一句的工具却可能使用 32。网络中的字节没有变，失败发生在知识被裁剪之后。

能整除只是第一张收据

若 mode=20，114 字节除以 38 得到三帧且余数为零。这证明长度与当前模式相容，却不证明三个块都能解码，也不证明发送者身份、SRTP 校验、抖动缓冲接纳、实际播放或听者体验。RFC 3711 所定义的 SRTP 是另一层保护；认证通过也无法把错误的会话模式变正确。

余数不为零则是很强的异常信号，可能指向陈旧协商状态、载荷类型混淆、畸形媒体或采集缺口。但某些长度可能同时被 38 与 50 整除，长度本身又无法说明发送者意图。判断仍需绑定当时生效的 Offer/Answer、动态载荷类型与协商版本。

RFC Editor 元数据把 RFC 3952 记录为 2004 年 12 月发布的 Experimental 文档。它留下的并不是“所有协议都该增加计数字段”的简单教训，而是更精确的一条：删除冗余字段会把状态迁移到别处。若系统没有一并保存那个外部状态，节省下来的字节会在审计时变成缺失的上下文。

资料来源