摘要

  • RFC 3558 的交错/捆绑格式把 EVRC 或 SMV 的相邻 20 毫秒帧分配到多个包中。一个包丢失时，解码序列里出现的是不连续擦除；缺失内容并未恢复。
  • 接收端宣告的 maxinterleave 只是发送端不得越过的上限。它不能证明缓冲内存已经分配、分组按时重建、解码器已摄取，或最终语音质量可接受。

网络看到的是一个包。解码器等待的却是散落在多个包里的时间位置。这两个视角之间，新增了一块必须有人负责的状态面。

RFC 3558 于 2003 年 7 月以 Proposed Standard 发布，为 EVRC 与 SMV 规定 RTP 载荷。两种声码器都以 20 毫秒为一帧。普通捆绑把连续帧装进同一个包，丢包会形成连续缺口；交错则把相邻帧拆到多个连续发送的包中，使同一丢包对应到时间线上相隔的位置。

这项设计改变的是损伤形状，而不是事实。原始语音帧一旦未到，就仍然未到。接收端只能在更多上下文之间插入擦除帧。

一个分组，两种顺序

载荷第一字节包括三位 LLL 和三位 NNN：前者表示交错长度，后者表示包在交错组中的索引。第二字节包括反向编码的 Mode Request，以及五位帧计数。计数保存“帧数减一”，因此一个包可声明一到 32 帧。

LLL 为零时只是捆绑；LLL 大于零时启用交错，且 NNN 不得大于 LLL。若每包携带 B 帧、交错长度为 L，一个组覆盖 B×(L+1) 个帧位置，并跨越 L+1 个 RTP 包。编号为 N 的包携带 N、N+(L+1) 等位置。

发送端按 NNN 递增发包，以减少接收等待。但这并不等于接收端已经得到可连续播放的语音。网络到达顺序与帧时间顺序不是同一张表。任何审计记录若只保存包序号，就无法说明最早位置何时可用；若只保存重建后的帧序列，又无法追溯哪个包制造了哪些洞。

分组收据至少要连接 RTP 序号、LLL、NNN、帧位置、到达时刻、播放截止时间和最终处置。

多一点状态，换一种丢失形状

交错的价值在于让擦除不连续。声码器一般比起长段连续缺失，更能承受被已接收语音隔开的孤立缺口。但“更能承受”不是“恢复成功”，更不是任何具体会话的质量保证。

RFC 3558 区分两种零比特状态。Null frame 表示没有声码器输出，通常不发送；erasure frame 是接收端遇到丢失或损坏时交给解码器的替代项。擦除会让解码器状态前进一个 20 毫秒周期，却不会复原说话者的音节、数字或意图。

因此，运行记录不能只写“解码持续”。它应保存每个擦除的位置及原因，并与语音质量、转录结果或业务动作关联。否则，一次关键数字的孤立丢失可能被整体可播放率掩盖。

maxinterleave 是能力边界，不是资源凭证

接收端可在会话描述中以 maxinterleave 宣告能接受的最大交错长度。参数缺失时，RFC 3558 的默认值为五。在一对一会话里，发送端不得超过该值。接收端也可在会话中降低上限。

这个值使接收端能够预估最大缓冲需求，却不能证明实现真的预留了内存，也不能证明内存没有被并发会话挤占。它同样不能说明新上限在哪个分组开始生效，或发送端是否在同一时刻完成切换。

另一参数 maxptime 限制单包媒体时长，默认值是 200 毫秒。它主要约束捆绑规模；maxinterleave 约束帧被摊开的范围。两者都不是端到端延迟。实际资源由 B、L、发包间隔、抖动尾部、重排深度、缓冲策略和解码调度共同决定。

应同时记录协商值与运行值：提议、应答、生效时刻、发送器版本、第一个符合新值的分组、已分配字节、占用峰值、强制提前重建次数。SDP 里出现一个数字，只证明有人表达过能力。

晚到的包可能只晚了一部分

交错包中的最早帧与最晚帧有不同播放期限。一个包可能错过第一个位置，却仍赶得上后面的几个位置。把整包丢弃会浪费仍有用的语音；为等待整包而拖延播放会损害对话时延；只接纳尚未过期的帧，则需要逐帧截止时间与部分摄取能力。

这是本地策略，而不是 LLL 字段自动给出的答案。可辩护的收据应说明：包在时刻 T 到达，位置 F1 已过期并成为擦除，F2 与 F3 仍及时进入解码器，所用策略版本为 V，最终播放延迟为 D。

“收到包”过于宽泛，“播放了声音”又过于靠后。逐位置记录才把网络事实与用户结果接起来。

Header-Free 选择的是另一种稀缺资源

Header-Free 格式只承载一个声码帧，不带目录项与交错头。它没有捆绑或交错，因此要为同样的语音支付更多 RTP、UDP、IP 头部，但封包等待更短，接收重建也更直接。

RFC 3558 建议，交互会话在时延重要时采用 LLL=0 或 Header-Free；当抗丢失比即时性更重要时，可考虑四或五。这里没有永远更先进的模式。真正的问题是带宽、内存、对话时间与连续丢失容忍度中，哪一种资源最紧张。

RFC 2508 与 RFC 3095 提供头部压缩背景。压缩可降低单帧包的开销，却必须观察其上下文是否在真实路径上健康；“支持压缩”不是实际节省的证据。

Mode Request 是请求，不是确认

载荷中的 Mode Request 要求反向编码器采用某个模式。一对一时建议对端遵从，多方会话时则应忽略。发送端会重复请求，以免一次丢包使其消失。

重复提高了被看见的概率，却没有形成确认。需要分别保存请求、每次发送、对端接收证据、编码器决定，以及第一个显示新模式的帧。把“已发送请求”写成“已完成切换”，正是把控制面意图误当运行结果。

交错配置亦然：接收能力、发送选择与实际包流是三个不同事实。

相同的擦除，可能来自不同责任面

目录项描述各帧类型和长度。LLL、NNN、帧数或帧字节组合无效时，接收端可能丢弃载荷并向解码器提交擦除。对解码器而言，它与网络丢包相似；对修复责任而言，二者完全不同。

监测必须区分从未到达、到达过晚、载荷无效、不支持的帧类型，以及本地缓冲驱逐。把它们都计作“丢包”，会把问题交给错误团队。

RFC 4788 后来为 EVRC-B、紧凑捆绑、非连续传输以及注册与提议/应答细节更新了这一载荷族。它是后续规范背景，不能被倒推为所有 RFC 3558 实现都具备的行为。

证据边界

本文没有识别任何运营商、设备、通话、用户、事故、实测丢包率、内存分配或听感结果。文中的例子用于解释标准机制，并非生产事件报告。

RFC 3550 与 RFC 3551 提供 RTP 框架与配置背景；RFC 3264 规定提议/应答，RFC 2327 是发布时的 SDP 背景，RFC 8866 是后续状态。RFC 2508 与 RFC 3095 描述压缩方案，RFC 8174 澄清规范措辞。RFC 4788 是后续更新，而非实现凭证。

Heng Lu 的 Running-Code Primacy 与 Minimum Initial Specification 是公开说明的编辑视角：前者要求把书面能力与运行证据分开，后者支持让共同格式保持最小、把后续决策留给本地责任者。它们不是 RFC 作者意图或网络事件的证据。

可证明的结论很窄：RFC 3558 交错能把一个丢包造成的帧缺口分散开，同时把更多状态、缓冲和截止时间判断交给接收端。上限约束发送端，只有运行收据能证明接收端实际付出了这些资源。

Sources