摘要

  • RFC 3389 允许发送端在非语音时段停止连续编码，只发送一字节噪声电平和可选频谱系数，让接收端自行合成舒适噪声。
  • 这份负载是环境声的有限模型，不是房间录音；收到并正确解析它，只能证明参数到达，不能证明远端声场被忠实复制。

一通早期网络电话里，对方刚停止说话，扬声器突然变成绝对的数字零。空调、话筒电路、远处车辆以及房间本身的细小纹理同时消失。听者面对的不是自然安静，而是一片像线路断掉的空白，于是下意识追问：“还在吗？”

继续传送完整底噪样本当然可以维持连续感，却会浪费静音抑制刚省下的带宽。另一种办法更符合分组网络：发送端不再搬运每个声波样本，只总结背景噪声的少量特征；接收端拿到这些参数后，合成一段足以让线路听起来仍然存在的环境声。

2002 年 9 月发布的 RFC 3389，把这种交接写成 Standards Track 规范。它主要服务于没有内置舒适噪声机制的音频编解码器，文件列举了 G.711、G.726、G.727、G.728 和 G.722。规范没有把整条语音处理链收进共同控制面，只定义不同实现之间必须理解的最小负载。

本地算法先完成三项工作。语音活动检测器判断一段输入属于活动语音还是非活动语音；不连续传输算法决定何时停发普通语音包、何时发送噪声更新；另一端的舒适噪声生成器再把参数变成可听波形。RFC 3389 明确把分析、合成、VAD 与 DTX 都留给实现者。

共同格式从一个字节开始。舒适噪声负载也称 SID 帧，即“静音插入描述符”。第一字节低七位记录相对于数字过载点的负分贝幅度，范围为 0 至 127；最高位不用，必须保持为零。数值 0 表示 0 dBov，127 表示 −127 dBov。

这里记录的是电平，不是一小段录音。相同的电平字节可以驱动无数条不同波形。两台接收机都完全遵守规范，也可能因为随机源、滤波方法和实现复杂度不同而发出不同声音。字节意义一致，不等于听觉结果相同。

发送端还可以在后续字节里加入量化反射系数，用全极点模型描述噪声的频谱包络。模型阶数不放在独立字段里，而由负载长度推得。编码器可以根据目标质量、计算复杂度、预期环境噪声和信号带宽选择阶数；解码器也可以把高阶系数设为零，主动降低本地复杂度。

这项扩展保留了与早期单字节格式的兼容。只认识电平的旧接收端可以读取第一字节，忽略其余频谱信息。它没有“解析失败”，却只能生成较贫乏的声色。成功互通因此至少有两层含义：共同的最低解释已经成立，更丰富的环境模型却未必被采用。

在 RTP 里，CN 包按一个独立小型编解码器来处理。时间戳指向所描述舒适噪声时段的开始；标记位不应置位。由于负载长度可变，每个 RTP 包的每个声道必须恰好只有一份 CN 负载；多声道共包时，各声道还必须使用相同频谱阶数。

静态负载类型 13 也不是脱离上下文的万能标签。它只在 RTP 时钟为 8000 Hz 时代表 CN。若音频使用其他时钟率，会话必须分配动态负载类型，并通过类似 CN/16000 的映射明确说明。只看到数字 13，而没有时钟和会话描述，就没有获得完整解释权。

进入非活动语音段时，发送端在同一 RTP 流里发出一枚 CN 包。以后多久更新一次，RFC 没有规定统一答案。有的实现定期报告，有的只在背景特征明显变化时才更新。两次更新之间，接收端继续使用上一份模型，并依靠自己的生成算法维持声音。

这套设计把一件听起来连续的事拆成多张回执。VAD 留下的是“本机认为语音不活动”的判断；DTX 留下的是“本机决定停发普通帧”的动作；SID 包留下的是一组电平与可选频谱参数；接收端留下的是解码与合成行为；用户感受到的自然或突兀，则是最后一项独立观察。前一张回执不能代替后一张。

网络上没有包，也不能自动证明舒适噪声正在正常工作。RFC 3389 的 SDP 部分特别说明：媒体描述中不包含 CN 类型，并不意味着不会抑制静音。RTP 允许任何音频负载采用不连续传输。沉默之后，序号只增加一而时间戳出现跨越，可以帮助接收端识别被省略的时间；但丢包、链路中断和采集缺失也会制造空白。要判断原因，必须同时查看协商、序号、时间戳和端点状态。

后来的 RFC 6263 展示了这枚小包的另一重影响。文件讨论用 CN 包维持 NAT 映射，却提醒远端必须支持并协商该类型，而且接收端很可能真的把它播放成噪声。本来为了保活网络路径而发出的消息，会进入人的耳朵。电平选得不当，运维动作就变成听觉事件。

RFC 6465 又沿用了同一套 −dBov 电平约定，用于 RTP 音频电平扩展。共同计量方式有助于实现一致，却不能把两种声明混成一件事。音频电平扩展随媒体报告强度；CN 负载则在语音帧停止时，为接收端制造新声音提供材料。

用 Lu Heng 的“最小初始规范”观察，这是一种很干净的边界。为了互通，参与者必须共同遵守电平编码、可选系数、打包顺序、起始时间、声道、负载命名和时钟率规则。至于怎样判断静音、何时更新、如何让合成声更自然，都可以留在运行软件里继续演化，不需要一个持续批准每次改进的中心。

“运行代码优先”则给标准的权威划出上限。RFC 的存在不能证明弱音没有被误切，也不能证明接收端生成的房间声令人信服。只有实际端点执行、测量和听测，才能给这些结果提供证据。文件规定可互操作的参数，不能把参数本身提升为声学事实。

RFC 3389 最有意思的历史贡献，正是它传送得比声音少，却比空白多。它没有把远端房间送过网络，只把一份有限模型交给另一台机器。语音包停止时，物理房间仍在发声；听者耳中的房间，则由几字节参数与接收端的运行代码重新建成。

来源