RTP 抖动详解：语音 AI 平台如何解决它

实时传输协议（RTP）抖动，是互联网通话上一秒还清晰无比、下一秒就支离破碎的原因，它是互联网上唯一一种没有“第二次机会”的实时媒介。

网页加载慢 200 毫秒，没人会在意；视频卡顿一秒，可以缓冲；文件传输丢包了，可以悄悄重传。语音不行。音频一旦迟到、乱序或干脆没到，人耳瞬间就能察觉——表现为机器人式的断续、卡顿，或句子中间尴尬的停顿。

对语音 AI 来说，问题只会更糟，不会更好。迟到的音频包不仅扭曲听者的听感，还会延迟下游的语音识别，让整段对话显得不自然、有滞后感。理解生产级电话系统如何对抗这个问题，是实时通信工程中被严重低估的话题之一。

抖动到底是什么

每个 RTP 数据包本应按照固定、可预测的间隔到达。如果你使用 G.711 或 Opus，以 20ms 打包，那么理想情况是这样的：

Packet 1 : 20 ms
Packet 2 : 40 ms
Packet 3 : 60 ms
Packet 4 : 80 ms
...

干净、等距、恰好相隔 20ms。这是理论情况。

在生产环境中，几乎永远不会这样。真实抓包看起来更像这样：

Packet 1 : 20 ms
Packet 2 : 23 ms
Packet 3 : 41 ms
Packet 4 : 57 ms
Packet 5 : 91 ms
Packet 6 : 84 ms

有的包提前到，有的迟到，有的乱序到达，有的根本没到。这种到达时间上的差异，就是我们所说的抖动。

抖动为什么会发生

抖动几乎从来不是编解码器的问题，而是网络问题。常见的元凶有：

• 路由器队列拥塞
• WiFi 重传
• LTE/5G 调度延迟
• MPLS 重路由
• 数据包在网络中走了不同的路径
• 通话两端各自的 CPU 调度延迟
• 虚拟机暂停
• 普遍的互联网拥塞

可以把这想象成高速公路上的车流。车辆以稳定的 20 秒间隔驶出收费站，但红绿灯、并线和拥堵意味着有些车挤在一起到达，有些则被远远甩在后面。RTP 数据包一旦进入拥塞的网络路径，行为完全一样。

为什么语音 AI 比传统电话对抖动更敏感

传统电话只有一个任务：把音频播出来。而语音 AI 在同一路音频流背后，还有一条长得多的处理流水线。基础设施的选型差异恰恰体现在这里。

RTP ──▶ Jitter Buffer ──▶ Decoder ──▶ Noise Cancellation / VAD
                                                           │
                                                           ▼
                       RTP ◀── Encoder ◀── TTS ◀── LLM ◀── ASR

每一个迟到的数据包，都会延迟下游所有环节。40ms 的网络延迟不会只停留在 40ms，它会不断叠加：

• 在抖动缓冲中等待 40ms
• ASR 延迟 20ms
• LLM 调度 30ms
• TTS 生成 25ms

一次网络抖动，就会给对话带来接近 100ms 的额外延迟，而用户最先感知到的，就是话轮切换（turn-taking）的不自然。

解决这个问题不能靠一个精妙的算法或一个更大的缓冲，因为没有任何单一方案能覆盖所有故障模式。这就是为什么下面这八种方法被称为“层”而不是“方案”：每一层作用于流水线的不同位置，有的作用于单个数据包（重排、隐藏、纠错），有的作用于缓冲本身（静态或自适应），有的作用于网络路径（QoS、路由）。生产系统会八层齐上，而不是只挑一种。

第一层：静态抖动缓冲

最直接的解决办法，就是有意延迟播放，给迟到的数据包一个追上来的机会。

Incoming Packets: 20, 40, 60, 80, 100
↓
Wait 60 ms
↓
Play

接收端不在音频到达的瞬间就播放，而是先扣住几个包让它们积累起来。这给了较慢的数据包在播放需要它们之前赶到的空间。

举个简单例子。假设数据包分别在 20ms、40ms、62ms、79ms 和 100ms 到达。没有任何缓冲时，本应在 60ms 到达的包没能及时赶到，听者就会听到一声“咔哒”：

20 ✓
40 ✓
60 Missing
80 Play

而有了 60ms 的抖动缓冲后，当播放开始时，那个“迟到”的包其实已经到了，正安静地躺在缓冲里：

20 Store
40 Store
62 Store
79 Store
Playback begins: 20, 40, 60, 80

第二层：自适应抖动缓冲

静态缓冲有一个明显的缺陷：它是静态的，而网络绝不是。这就是为什么如今几乎所有现代 VoIP 技术栈都转向了自适应缓冲——系统会持续估算抖动，并实时调整缓冲大小。

当网络开始恶化时，缓冲随之增大以进行补偿，如20ms → 40ms → 60ms → 80ms。当网络恢复稳定时，它又会立刻缩小以保持低延迟：80ms → 60ms → 40ms → 20ms。

抖动到底是怎么测量的：RFC 3550 使用指数加权移动平均来定义：

J = J + (|D(i-1,i)| - J) / 16

其中 D 是数据包间隔的变化量，J 是实时运行的抖动估计值。这个公式刻意保持简单：它能平滑掉偶发的尖峰而不至于反应过度，但如果拥塞是持续性的而非偶然，它依然能快速响应。你在生产中遇到的大多数 RTP 实现，跑的都是这个公式的某种变体。

Vobiz 在生产中采用自适应缓冲正是出于这个原因：缓冲大小是动态设定的，而非固定值。

第三层：数据包重排

数据包到达的顺序并不总是与发送顺序一致。

Received: 100, 120, 140, 160, 180
becomes:  100, 140, 120, 160, 180

解决办法很直接：接收端将数据包短暂扣留，利用 RTP 序列号重新排序，然后再交给解码器。跳过这一步，即使每个包技术上全都到达了，语音听起来也会明显失真。

第四层：丢包隐藏（PLC）

有些数据包永远不会出现，而你不能无限期等下去。所以现代编解码器不再等待，而是预测缺失的音频大概是什么样子。

比如一个词，中间缺了一段：

Hello Wo___d

丢一两个包时，大多数听者完全察觉不到。Opus 内置了真正精密的 PLC。G.711 的实现则比较粗糙，通常只是重复上一帧音频或在采样点之间插值，但总比死寂或刺耳的咔哒声强。

Vobiz 在所有通话中应用 PLC，短暂的丢包被隐藏掉，而不是被听成一段空白。

第五层：前向纠错（FEC）

如果说 PLC 是事后修补，那么 FEC 则是事前预防，在原始数据流之外，额外发送冗余数据。

Packet 1, Packet 2, Packet 3, Parity Packet

如果数据包 2 在传输中丢失，接收端可以直接从校验数据中重建它，而不是靠隐藏：

Packet 1, Packet 3, Parity
↓
Recover Packet 2

Opus 原生支持 FEC。代价是带宽：你总是要发送比最低需求更多的数据，换来的则是干净利落地从丢包中恢复的能力。

在 Vobiz 上，FEC 不适用于承载大多数通话的常见中继编解码器（PCMU、PCMA、G.722），因为 FEC 是 Opus 专属功能。这些通话上仍然应用隐藏（PLC），但不做纠错（FEC）。

第六层：RTP 时间戳同步

这一层很微妙但很重要：播放时机绝不应该由数据包到达的时刻驱动，而应由数据包内嵌的 RTP 时间戳驱动。

由于播放是按照时间戳而不是到达时间排程的，迟到的包依然会被安排到音频流中正确的位置，而不是错位播放。即使到达时间真的极不稳定，这也是让音频保持流畅的关键。

第七层：网络服务质量（QoS）

无论抖动缓冲调得多好，都无法完全补偿严重拥塞的网络。到某个临界点，你必须在传输层解决问题。运营商网络的做法，是把 RTP 流量优先于其他一切流量处理：

• DiffServ（DSCP EF）
• MPLS QoS
• VLAN 优先级
• 流量整形
• 队列调度

最终效果：语音数据包可以越过批量数据流量排队，而不是与之竞争。

第八层：更智能的路由

最后一层作用于平台层面，而非数据包层面。大型 CPaaS 提供商会实时监控每一条网络路径的质量，某条路径一出现劣化，立刻绕行。

Carrier A → 40 ms jitter → Switch → Carrier B → 8 ms jitter

这种路由决策不是人工完成的，而是由丢包率、RTT、MOS 评分、抖动和历史质量数据持续驱动的。

无法靠工程消除的权衡

降低抖动和降低延迟是两股相反方向的力量，你不可能同时把两者做到极致。ITU-T G.114 建议将长途质量的单向延迟上限设为 150ms，这也是生产环境的抖动缓冲即使在恶劣网络上也很少超过 100–120ms 的部分原因。

具体到语音 AI，大多数平台会刻意偏向该表格中低延迟的一端，即使这意味着容忍略高的丢包概率——因为一个响应及时的对话，比一个完美无瑕的对话更重要。

各层如何作为一个系统协同工作

抖动无法靠一个精妙的算法或一个大缓冲解决，而是八层协同：

• 稳定的网络路径
• 自适应抖动缓冲
• 数据包重排
• 丢包隐藏（PLC）
• 前向纠错（FEC）
• RTP 时间戳同步
• 服务质量（QoS）
• 智能媒体路由

对语音 AI 而言，每一毫秒都直接体现在对话的自然程度上。这套技术栈正是“听起来像人”的系统与“听起来像 2003 年电话”的系统之间的分水岭。

常见问题（FAQ）

什么是 RTP 抖动？

RTP 抖动是指网络上传输的语音数据包到达时间的差异。本应每 20ms 到达一个的包，却会提前、迟到或乱序出现，导致实时通话中出现音频卡顿、中断或机器人般的语音。

VoIP 通话中的抖动由什么引起？

抖动几乎总是网络造成的，而非音频编解码器。常见原因包括路由器队列拥塞、WiFi 重传、LTE/5G 调度延迟、MPLS 重路由，以及通话两端 CPU 或虚拟机的调度延迟。

如何修复实时音频中的抖动？

生产系统采用分层方案而非单一技术来修复抖动：自适应抖动缓冲、数据包重排、丢包隐藏（PLC）、前向纠错（FEC）、RTP 时间戳同步、网络 QoS 和动态运营商路由协同工作。

抖动缓冲会增加延迟吗？

会。任何抖动缓冲，无论是静态还是自适应，都会有意延迟播放，让迟到的包有时间赶上来。这就是为什么语音 AI 平台会谨慎调校缓冲大小，在更流畅的音频和更高的对话延迟之间做平衡。

为什么抖动对语音 AI 的影响大于普通电话？

传统电话只需要播放音频，而语音 AI 流水线在同一路音频流背后还要叠加 ASR、LLM 和 TTS 处理。一个迟到的包，等它传到听者耳中时，可能已经堆叠出近 100ms 的额外对话延迟。

抖动和丢包有什么区别？

抖动是数据包到达时间的差异，而丢包是数据包根本没到达。生产系统对两者的处理方式不同：抖动靠缓冲和重排，丢包靠隐藏或前向纠错。

作者：Vikash Srivastava