做过 VoLTE/VoNR 投诉处理的工程师都遇到过这种场景：信令 traced 下来干干净净——IMS 注册成功、INVITE 摘机正常、计费话单也对，但用户就是抱怨“电话像机器人”“说话一顿一顿的”“只能听见一半”。这时如果还盯着 SIP 消息看，方向就错了。问题不在信令面，而在媒体面。
理解这个分界，是排查语音问题的第一课。一次通话其实是两条腿走路：信令面负责“把电话建起来、拆下去”，走的是 SIP/SDP 这类文本协议；媒体面负责“把声音运过去”，走的是 RTP 承载的连续数据流。信令像订座，媒体像飞行——座位订得再顺利，航班颠不颠簸是另一回事。本文就沿着一帧语音的旅程，把媒体面的设计原理讲透：为什么语音包走 UDP 而不走 TCP？为什么要设抖动缓冲？丢了包为什么不是重传而是“脑补”？这些“为什么”正是判断现网故障时的底层依据。
一切从话筒开始。人说话是空气压力的连续波动，而数字网络只能搬运离散的比特，中间要过三道关：采样、量化、压缩。
采样遵循奈奎斯特定理：要想无失真地还原信号，采样频率至少是信号带宽的两倍。
$$f_s \geq 2B$$
传统电话只传 300~3400 Hz 的窄带语音，所以取 8 kHz 采样——这就是“电话音”听起来闷的原因，它先天就丢掉了 3.4 kHz 以上的高频成分，而高频恰恰是人声齿音和“临场感”的载体。VoLTE 引入的宽带语音把采样提到 16 kHz、带宽扩展到 50~7000 Hz，用户最直观的感受就是“接通那一瞬间声音突然变清楚了”，像从收音机换到了 CD。
量化之后是压缩。8 kHz 采样、8 bit 量化的 G.711 是 64 kbps，这对宝贵的空口资源太奢侈，所以移动语音都用参数编码（声码器）：不直接传波形样本，而是每 20 ms 取一帧，分析这一帧里人的声门激励和声道滤波特性，只传少量模型参数，对端再“重建”出语音。20 ms 这个帧长是全行业的默契——帧太短，每帧头部信息和计算开销占比太高；帧太长，算法引入的固有延迟就大，还会放大丢包的可闻影响。
| 编解码器 | 音频带宽 | 码率 | 现网角色 |
|---|---|---|---|
| G.711 | 窄带 300~3400 Hz | 固定 64 kbps | 固话侧、媒体网关互通 |
| AMR-NB | 窄带 | 4.75~12.2 kbps，8 档 | 2G/3G 及早期 VoLTE |
| AMR-WB | 宽带 50~7000 Hz | 6.6~23.85 kbps，9 档 | VoLTE 的基础编解码 |
| EVS | 窄带直到全带 | 5.9~128 kbps 多档 | VoLTE 增强、VoNR 主力 |
从 AMR 到 EVS 的演进逻辑值得体会：EVS 不只是“压得更狠、音质更好”，它在低码率下保持高音质的同时，还引入了信道感知模式——可以按网络指示在“信息量”和“抗错冗余”之间动态分配比特，链路差时少编码细节、多编保护位。这是把传统上属于信道编码的可靠性职责，部分前移到了信源编码里，是“信源信道联合设计”思想的现代实践。
一帧语音编码完成后，要交给传输层发出去。这里有个反直觉的设计：语音刻意避开了以可靠著称的 TCP，选择了“不可靠”的 UDP，再在 UDP 之上加一层轻量的 RTP（实时传输协议，由 IETF 在 RFC 3550 中定义）。
道理可以用一句话讲清：实时对话里，迟到的正确包等于错误包。你 20 ms 后才重传成功的那帧“喂”，早就过了该播出的时刻，补播只会造成节奏错乱。而人耳对一帧（20 ms）语音的丢失几乎无感，加上丢包隐藏技术（后文详述），少量丢包是可以容忍的；但对 200 ms 的等待，人耳极其敏感。所以语音传输的优化目标不是“零丢失”，而是“低延迟下的可控丢失”——TCP 的重传、拥塞退避、队头阻塞机制，全都与这个目标背道而驰。
那 UDP 只管发，丢没丢、乱没乱谁来管？答案是 RTP 包头。它在每个包里塞进两类关键信息：
有了这两样，接收端即使拿不到 TCP 那种可靠传输，也拥有了对实时流做质量评估和秩序恢复的全部依据。
再算一笔开销账。以 G.711、20 ms 一帧为例，语音载荷为：
$$64\ \text{kbps} \times 20\ \text{ms} = 160\ \text{字节}$$
而 IP（20 字节）+ UDP（8 字节）+ RTP（12 字节）共 40 字节头部，开销比高达：
$$\frac{40}{160} = 25\%$$
每五分之一的空口带宽在传“地址”，这对无线资源不可接受。所以蜂窝网络普遍启用头压缩：利用包头字段的强相关性（如 IP 地址、端口号在一条流内基本不变），把 40 字节压缩到几个字节。这也是为什么现网排查媒体面问题时，能看到“头压缩失效导致吞吐异常”这类案例——协议设计上省下来的每一个字节，都是给用户的体验。
发送端是每 20 ms 一帧、规规矩矩匀速发包的，但包到达接收端的时刻却忽快忽慢：不同包可能走了不同的转发路径，可能在某台设备的发送队列里排队久一点，也可能在空口上因为调度轮次不同而迟到。这种到达间隔的不一致性就叫抖动。
对播放来说抖动是致命的。播放器必须匀速出声——人说话的节奏是均匀的，忽快忽慢地播出来就是“机器人声”。解法是一个看似简单、实则精巧的部件：抖动缓冲。它不追求包一到就播，而是故意让最早到达的包等一小会儿，给后面的迟到包留出追赶时间，然后在缓冲区出口按 20 ms 的节奏匀速取帧播放。本质上，它是用一笔固定的小延迟，把“时间的乱流”重新捋成“时间的匀流”。
flowchart TD
A["包到达忽快忽慢<br/>存在抖动"] --> B["自适应缓冲区<br/>深度几十毫秒"]
B --> C["按20ms节奏<br/>匀速取帧播放"]
C --> D{缓冲区水位}
D -->|持续偏高| E["存在过时包<br/>加快播放消化积压"]
D -->|持续偏低| F["有欠载风险<br/>加深缓冲吸收抖动"]
E --> C
F --> C
注意图中“自适应”三个字，这是设计的精髓。缓冲设多深是一场豪赌：设太浅，稍微抖一下缓冲区就欠载（该播的时候没帧可播，只能补噪声）；设太深，白白增加几十毫秒端到端延迟。早期设备用固定深度（如配置成 40 或 60 ms），而现在主流实现是自适应缓冲——实时监测包的到达间隔和缓冲水位，网络抖动变大就自动加深，抖动平息后通过微幅加速播放把多攒的延迟慢慢“吐”出来。整个缓冲区像一个有弹性的水箱：进水忽大忽小，出水口永远恒流，水位则动态调节。
网络里的抖动大小是可以量化计算的。RTP 规范给出了一个指数平滑的估计式，接收端对每对相邻包计算到达间隔与发送间隔之差 $D_i$，然后按下式更新抖动估计：
$$J_i = J_{i-1} + \frac{|D_i| - J_{i-1}}{16}$$
分母 16 意味着每次只吸收新样本的 1/16——一个刻意“迟钝”的低通滤波器，防止单个异常包（比如被调度器卡了一下的那一帧）把抖动估计猛地拉偏。这种“用平滑统计代替单点测量”的思路，在网络测量的各个角落都会反复见到。
UDP 网络里丢包不可避免，但语音有一个得天独厚的优势：人耳和大脑是天然的丢包修复器。连续语音有极强的时域相关性和心理声学冗余，缺一小段，人可以靠上下文“脑补”出来——就像你听清一整句话，其实每个字未必都听清了。丢包隐藏（PLC）技术就是把这种脑补工程化：
PLC 修复的是“丢了之后”，FEC（前向纠错）则追求“丢了也白丢”。思路是把冗余装进后面的包里：第 N 包除了自己的语音，还捎带第 N-1 包的低码率副本。丢一个包，从下一个包里就能把副本捞回来。代价是额外码率，收益是无需等待、即时恢复——这与“宁可丢不能等”的实时原则完全一致。EVS 的信道感知模式更进一步，由网络根据实时信道质量动态决定“当前该多分冗余还是多分音质”，形成闭环。
这里要打破一个常见直觉：语音丢包率 1% 通常完全无感，5% 仍可通话，但同样的丢包率对视频会议可能就是灾难。原因是视频的帧间依赖链长，丢一帧参考帧会引发涟漪式花屏；而语音每帧自成一体、依赖链短。这正是实时媒体宁可要 UDP 的第二个理由——它的容错模型天然适配“尽力而为”的承载。
以上所有自愈机制（自适应缓冲、PLC、FEC、码率切换）都需要一个前提：接收端的质量状况必须传回发送端。这就是 RTP 的孪生兄弟 RTCP 的职责。RTP 管发数据，RTCP 管发“体检报告”——两者用同一对 UDP 端口的相邻端口，各走各的。
sequenceDiagram
participant A as 主叫UE
participant B as 被叫UE
A->>B: RTP语音包，20ms一帧
B->>A: RTP语音包，反向媒体
B->>A: RTCP接收报告，含丢包率与抖动
A->>A: 评估链路，决策降码率或加冗余
A->>B: 后续RTP按新策略发送
Note over A: 反馈周期典型约5秒
RTCP 的接收报告里有几个字段，是现网抓包分析时的“重点观察对象”：
| 报告字段 | 含义 | 工程用途 |
|---|---|---|
| fraction lost | 统计周期内的丢包比例 | 判定链路劣化的第一指标 |
| interarrival jitter | 到达间隔的统计抖动 | 指导缓冲深度与问题定位 |
| extended highest sequence | 已收到的最大序号 | 发现断流、乱序与方向不对称 |
| last SR timestamp | 配合发送方报告估算环路时延 | 定位延迟出在哪一段 |
设计上有一个值得玩味的细节：RTCP 报文默认只占会话带宽的 5% 左右，反馈周期典型为秒级（约 5 秒）。为什么反馈这么“慢”？因为语音质量的变化是慢变量，秒级反馈足够跟上；若为追求快反馈而提高 RTCP 频率，控制流量本身就会挤占宝贵的语音带宽。控制信息的密度，要与被控对象的惯性匹配——这个思想同样贯穿于无线调度、自适应调制等一切闭环系统。
工程上 RTCP 还能诊断一类隐蔽故障：单通。主叫听不到被叫，但双方信令全正常。看 RTP 流方向即可定位——如果只有单向流、对端 RTCP 也从不出现，问题多半在媒体路由或防火墙；如果双向 RTP 都有但对端收包序号断崖，则要看传输路径上的丢包点。
把前文所有部件串起来，就能算一笔完整的账：一帧语音从主叫嘴到被叫耳，单向延迟由哪些部分构成？
| 环节 | 典型量级 | 说明 |
|---|---|---|
| 采集 + 编码 | 20~40 ms | 帧长本身加算法前视窗口 |
| 打包 + 发送队列 | 数毫秒 | 终端协议栈处理 |
| 空口调度 + HARQ | 10~50 ms | 随制式、重传次数波动最大 |
| 核心网 + 承载传输 | 5~30 ms | 由地理距离和路由决定 |
| 抖动缓冲 | 20~80 ms | 人为加入，可动态伸缩 |
| 解码 + 播放 | 数毫秒 | 端侧处理 |
ITU-T 的 G.114 建议给出过一条著名的工程红线：单向端到端延迟控制在 150 ms 以内，通话双方才能保持自然的对话节奏，无需“你说完了吗”式的抢话确认。超过 400 ms，对话就退化成半双工的对讲机。对照上表会发现一个深刻的结论：延迟预算是稀缺资源，各环节是在分蛋糕。空口 HARQ 多重传一次省下的丢包，可能就要抖动缓冲埋单；编码器压得更狠换来的带宽，又以算法延迟的形式还回去。语音工程的所有决策，本质上都是“延迟、丢包、带宽”三角里的取舍。
那么最终质量怎么评分？行业通用的是 MOS（平均意见分），1 到 5 分，由真人试听统计而来。真人打分太贵，工程上用 E-model 这类估算模型代替：把延迟损伤、设备损伤、丢包损伤逐项扣分，得到一个 0~100 的质量因子 R：
$$R = R_0 - I_d - I_{e\text{-eff}}$$
其中 $R_0$ 是无损伤基准（约 93.2），$I_d$ 是延迟带来的损伤，$I_{e\text{-eff}}$ 是编解码与丢包损伤。工程经验上，R 在 80 以上对应 MOS 约 4 分（满意），跌到 50 附近就是“勉强能聊”的底线。MOS 对延迟和丢包的惩罚是非线性的：各项都在舒适区时分数很高，一旦有一项越过阈值，分数断崖式下跌。这解释了现网一个典型现象——大部分用户都说电话没问题，却总有零星投诉“偶尔卡一下”：网络指标平均值漂亮没用，用户体验取决于最差的那几分钟。
把原理翻译成排查动作，媒体面问题基本收敛为三类，各有各的“指纹”：
第一类：单通/双不通。RTP 流单向或双向缺失。常见根因：媒体网关或 UPF 侧媒体路径未建立、防火墙未放行协商出的 RTP 端口段、SDP 协商的地址端口与实际不符（如 NAT 穿越处理不当）。验证方法：抓两侧包，对 RTP 五元组——源目 IP、端口、SSRC 是否如 SDP 所约。
第二类：断断续续、机器人声。流在但质量差。看 RTCP 接收报告的 fraction lost 和 interarrival jitter：丢包高、抖动大，通常是空口质量差（弱覆盖、干扰）或传输网拥塞；丢包不高但 MOS 仍差，查是否在反复触发编码模式切换（网络边缘“探出探头”的典型表现），或抖动缓冲频繁重置。
第三类：延迟大到抢不了话。逐段量延迟：RTP 时间戳与到达时刻之差看缓冲深度，RTCP 环路时延看传输段，空口调度延迟看无线侧统计。最常见的隐藏元凶是自适应缓冲在网络抖动大时悄悄加深到了几十毫秒——单看信令一切正常，延迟全在缓冲里。
再提醒两个高频误区。其一，不要用 ping 判断语音质量：ICMP 的路径优先级、包大小、QoS 标记都与 RTP 不同，ping 通畅不代表语音流不被丢；要抓就抓真实 RTP。其二，丢包统计口径要分清：RTCP 报告的是接收端视角的丢失，传输网设备统计的是链路层丢弃，两者之间还隔着排队溢出、策略丢弃等多个环节，定位时不能直接画等号。
回看整条链路，会发现语音媒体面的每一条设计都围绕一个核心约束展开：服务的对象是人耳，而人耳对延迟敏感、对少量丢失宽容、对节奏错乱零容忍。于是它放弃重传选择即时、用缓冲换节奏、用脑补补丢失、用冗余抗差错、用秒级慢反馈驱动慢调节——与 TCP/IP 世界“绝对正确、顺序、完整”的哲学处处相反，却又处处自洽。
对工程师而言，这套原理的价值在排障时会不断兑现：看到“机器人声”能立刻想到抖动缓冲欠载，看到 RTCP 丢包陡增能区分空口问题与传输问题，看到延迟超标能逐段拆解预算。理解了“为什么这样设计”，“哪里出了问题”往往就藏在设计假设被打破的地方。
Q: RTP 和 RTCP 用的端口是什么关系？会话建立时怎么约定？ A: 两者使用同一传输地址对的相邻奇偶端口：RTP 用偶数端口，RTCP 用其上的奇数端口。端口和编解码等参数都在呼叫建立时通过 SDP 的 offer/answer 协商确定，所以 SDP 里的媒体地址端口错误，是单通类故障的第一嫌疑。
Q: 抖动缓冲是不是越深越好，反正丢包有 PLC 兜底？ A: 不是。缓冲每深 10 ms，端到端延迟就实打实加 10 ms，而延迟对 MOS 的惩罚是持续性的，丢包损伤才是偶发性的。正确姿势是自适应缓冲：平时保持浅水位，抖动恶化时才加深，并在链路恢复后通过微幅加速播放把延迟还回去。
Q: VoLTE 用 AMR-WB，5G VoNR 是不是换了新编解码器？ A: VoNR 沿用 IMS 语音体系，主流仍是 AMR-WB 与 EVS。EVS 在相同码率下音质优于 AMR-WB，并支持全带语音，但能否启用取决于终端与网络的双向协商——它是可选增强而非强制替换，所以同一网络上不同终端的通话音质存在差异是正常现象。
Q: 抓包时看到 RTP 流有丢包，用户为什么没投诉？ A: 有 PLC 和 FEC 兜底，1% 左右的随机丢包通常在人耳无感范围内。真正触发投诉的往往是特征更差的丢失：连续丢（一丢就丢一串，PLC 补不动）、突发周期性丢（有节奏的“卡、卡、卡”人耳最敏感）、或伴随缓冲欠载的“咔嗒”声。分析时看丢包的分布形态比看总数更有价值。
Q: 语音走专用承载，和普通上网数据在网络上待遇差在哪？ A: 差在调度优先级和资源保障：语音承载是 GBR 类，网络为其预留最低速率资源并在调度上优先，拥塞时先牺牲的是上网流量；同时语音包通常有更高的 QoS 标记，传输网沿途设备按标记给优先转发。所以“网速慢”和“通话卡”经常不是同一个瓶颈。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。