摘要

  • César Díaz 在 LACNIC 于 2026 年 8 月 26 日发布的文章中介绍电话向 IP 网络迁移，并明确指出音频之外还要加上协议头和控制数据。文章没有宣布新的容量规则。
  • 在持续单向、单声道语音、每包承载 20 毫秒音频的模型下，G.729 的 8 kbit/s 码流加基本 IPv4/UDP/RTP 头部后为 24 kbit/s，换用 IPv6 基本头部则为 32 kbit/s。
  • 音频压缩八倍，不代表完整 IP 包流量也减少八倍，更不代表每秒处理的数据包同步减少。采购和配置必须保留计算条件。

两张表可能都没错

一张表写着 8 kbit/s，另一张写着 24 kbit/s。前者来自音频编码参数，后者来自完整 IP 包的计算。遇到这样的差异，第一件事不是判断谁测错了，而是问两张表究竟在数什么。

LACNIC 的这篇电话文章提供了很好的入口。César Díaz 从电路交换讲到共享 IP 基础设施，说明更高效的编码如何减少语音数据。他提到 G.711 的 64 kbit/s 和一些更低码率的方案，同时明确保留了协议开销这一条件。这里没有一个需要被揭穿的“错误数字”；值得追问的是，当读者据此购买带宽时，这个条件是否还在。

用 G.729 做一笔有明确边界的计算即可看清。RFC 3551描述的 G.729 语音帧，每 10 毫秒占 10 字节，默认一个包装入两帧，即 20 毫秒、20 字节。假定音频持续发送，每秒便有 50 个包。这只是选定的模型，不是对 LACNIC 成员网络所用编码和配置的调查。

每个包还有固定部分：RTP 基本头部占 12 字节，UDP占 8 字节，IPv4 最小头部占 20 字节。于是，20 字节音频变成一个 60 字节的 IP 包。每秒 50 包，再乘每字节 8 比特，得到 24,000 bit/s，也就是 24 kbit/s。

编码器仍然只产生了 8 kbit/s 音频。多出来的不是压缩失效，而是统计范围扩大了。

少了字节，未必少了包

下面各项均为计算值：单声道、持续单向语音，每包 20 毫秒，采用未压缩的基本 RTP/UDP/IP 头部，不含选项、扩展和填充。IPv6 基本头部为 40 字节，因此与 IPv4 的最小头部相差 20 字节。

编码 纯音频码率 每秒包数 完整 IPv4 包的比特率 完整 IPv6 包的比特率
G.711 64 kbit/s 50 80 kbit/s 88 kbit/s
G.729 8 kbit/s 50 24 kbit/s 32 kbit/s

音频从 64 降到 8，是八倍之差；完整 IPv4 包从 80 降到 24，则约为 3.33 倍。两种情况每秒都是 50 包。因此，不能凭字节量减少，就断言设备逐包处理的工作也同比下降。这张表更不能证明某台设备能承受多少并发通话。

IPv6 一列增加的 8 kbit/s，同样只是一项条件明确的开销：多出的 20 字节乘每秒 50 包。不能据此推断 IPv6 的整体成本或否定部署价值。

这也还不是一通电话的完整账单。表中没有信令、RTCP、额外安全开销、隧道、链路层封装、冗余和容量余量；无线链路还有自身的竞争与传输条件。启用静音抑制后，实际发送规律也会改变。双向通话需要分别考虑两个方向，而不能把这里的单向数字直接贴到整通电话上。

用等待换带宽，需要有人同意

还有一种节省方式：不改变编码，而是让一个包多装一些音频。在相同 G.729 和基本 IPv4 头部模型下，每包 10 毫秒是 40 kbit/s，每包 20 毫秒是 24，每包 40 毫秒是 16。被摊薄的是每包都要支付的头部，而不是音频本身。

代价也很具体。多装音频，需要先等它产生；一个包丢失时，随之丢掉的语音时间更长。RFC 3551 明确说明，较长的打包间隔减少头部开销，却增加延迟，并使丢包更容易被感知。算式没有替用户决定这种交换是否值得。

RTP 提供序号和时间信息，也不等于提供准时送达保证。协议定义、容量模型与真实听感是三件事，后两件必须在实际服务条件下验证。

LACNIC 的文章有助于解释电话为何转向共享网络。但从解释走到容量决策，还需要跨过这一小步：不仅保留编码器的数字，也保留头部、发包频率和统计位置。否则，一句正确的科普可能在采购表里变成另一种未经验证的承诺。