VoLTE语音吞字断续问题根因分析与优化实践-育师

做无线网优或者核心网维护的朋友，估计都有过这种经历——用户明明信号满格，但打电话一开口就是“喂？喂？你刚才说啥？没听清”，或者对方声音像信号不好的对讲机一样一顿一顿的。用户骂的是手机、是运营商，但真正“吞字”的，是VoLTE这条端到端语音链路。

VoLTE语音承载在IP网络上，靠RTP报文把声音切成20ms一包来传。只要是IP承载，就绕不开一个核心矛盾：音视频实时业务最怕丢包和抖动，而空口、传输、核心网、终端任何一个环节出问题，都会直接变成用户耳朵里的“吞字”和“断续”。我这些年处理过不少这类投诉，从无线侧的弱覆盖、切换带，到核心网的丢包、抖动缓冲，再到终端芯片的调度策略，几乎每个环节都踩过坑。这篇就把VoLTE吞字断续的定位思路、优化手段和一些实际经验完整梳理一遍，照着这个思路做，能少走不少弯路。

1. 先说清楚“吞字断续”到底是什么级别的劣化

1.1 先分清是“吞字”还是“断续”，别把病根搞混

很多优化同事喜欢把这两个词混在一起用，但实际上它们的表现和根因是有区别的。

吞字，是某几个字直接没声了，像是磁带被剪掉一截。这种情况基本是RTP报文丢了，或者晚到了超过接收端能容忍的缓冲时间，直接被丢弃。丢几个包，耳朵不一定能感知，但如果连续性丢包超过200ms，听起来就是明显的“吃了半句话”。

断续，更偏向声音断断续续、卡壳，但每个字都还在，只是不连贯。这种情况往往是RTP包时延和抖动过大，或者空口调度被其他业务抢占，导致语音包到得不均匀。接收端虽然有jitter buffer兜底，但抖动太猛的时候，缓冲区也会崩溃，表现为卡顿。

实际测试里，这两种经常同时出现。所以第一步不是急着调参数，而是通过终端日志、核心网媒体面抓包、空口调度统计，先确认当前问题以哪种为主，再针对性排查。

1.2 量化评估：用哪些指标衡量“听起来差”

用户说“听得差”是不够的，优化必须靠数据量化。VoLTE语音质量最常用的几个指标：

MOS值（Mean Opinion Score）：最直观的用户感知指标，1到5分，2.63以下基本无法接受；3.0用户能明显感知质量差；3.5以上才勉强算可用，理想值至少4.0。现在测试常用PESQ/POLQA算法，对端到端音频做对比评分。
RTP丢包率：端到端媒体面丢包，包括空口、传输、核心网三个环节的叠加。通常要求端到端丢包率低于0.5%，超过1%听感明显劣化，超过2%基本不可忍受。
RTP时延与抖动：语音端到端时延建议低于150ms，耳语模式甚至要求在100ms以内；抖动一般要求低于30ms，超过这个值jitter buffer就开始反复扩展或收缩，人耳就感觉卡顿。
空口侧BLER、误块率：反映物理层传输质量，初传BLER目标值一般设在10%左右，太高说明空口质量差，重传比例上升会影响实时性。

这些指标在各个网元侧都能取到，关键是建立“终端->基站->核心网”全链路的数据关联口径。只看任何单侧数据，都容易被局部正常假象误导。

2. 端到端逐段排查：吞字断续到底卡在哪一环

2.1 无线空口侧：最常见的“吞字”温床

VoLTE语音包虽然通过QCI=1承载走GBR保障，具备了比普通数据业务更高的调度优先级，但这不等于空口侧不会出问题。

最典型的是覆盖边缘和切换带。这些区域信号波动剧烈，CQI（信道质量指示）上报频繁跳变，MCS（调制编码方式）来回切换，语音包大小固定，但需要的资源块数量却在不停变化。一旦PDCCH资源受限或者CQI上报不及时，基站可能来不及在下一次调度周期给语音包分配资源，RTP包就只能排在后面，一旦超过PDCP丢弃定时器就直接丢包。

另一个容易忽视的问题是RRC重建。语音通话过程中，如果用户发生无线链路失败（RLF），RRC重建需要几百毫秒到一秒左右，期间RTP包完全中断，重建完成后恢复通话，表现就是一段明显的“静音裁剪”。尤其是移动场景下跨eNodeB切换失败，最容易引发。

还有小区间干扰。LTE是同频组网，小区边缘用户受邻区干扰影响，SINR（信号与干扰加噪声比）变差，语音BLER恶化，即便开启HARQ重传，语音包等不到重传成功就会被PDCP丢包。这种情况在密集城区、城中村、高架桥场景特别多。

2.2 传输与核心网侧：时延抖动的“隐形推手”

空口问题看得见摸得着，传输和核心网的问题往往隐蔽得多。

VoLTE业务经S1-U接口进入核心网后，RTP报文由PGW/SGW承载转发，再经过IMS域的SBC/P-CSCF进行媒体处理和转发。任何一个网元出现单板负荷过高、报文缓冲区溢出、或者传输链路存在误码，都会给RTP报文注入时延抖动。

尤其注意传输侧的小包转发性能。语音包是20ms间隔的固定小包，和视频、数据业务的大包混合传输时，如果承载设备的队列调度算法不当，小包会被大包“挤”在后面，导致到达时间不均匀。我曾经遇到过一个现场，基站和核心网之间经过多跳IP微波，微波链路的调度周期是10ms甚至20ms一帧，语音包到了微波节点必须等下一个调度帧，这就硬生生增加了10-20ms抖动，再叠加上核心网侧处理，用户感知直接掉到3分以下。

核心网侧另一个重点关注点是PCRF下发的QoS策略。VoLTE的QCI=1承载是GBR类型，带有保证速率和最大比特速率参数，如果PCRF策略或HSS签约数据出错，GBR速率配置偏低，当RTP报文瞬时速率超过约束后，分组网关可能直接丢包，或者触发限速。表面看空口很好，但实际语音包已经“偷工减料”了。

2.3 终端侧：用户手里的“变数”

每台手机的芯片平台、协议栈实现、射频能力都不一样，同样的网络条件下，不同终端的语音感知差异非常明显。

最典型的是终端的DRX（非连续接收）周期配置。为了省电，VoLTE终端在通话时也会进入DRX模式，只在特定时刻监听PDCCH获取调度指令。如果eNodeB配置的DRX参数不合理，或者终端实现有缺陷，语音包到达时恰好处于“睡眠”窗口，就要等到下一个监听周期才能收到，直接影响空口时延。业界一般推荐VoLTE语音的DRX周期长度建议配置在40ms或80ms，过长的160ms/320ms周期虽然省电，但对语音时延并不友好。

还有终端的编解码速率选择。VoLTE支持AMR-NB和AMR-WB，还有编解码模式自适应功能。网络侧下发了允许的编码集合后，终端会根据信道质量自动选择合适的编码速率。但在某些终端上，自适应切换算法不灵敏，信道已经很差了还坚持用高编码速率，结果大量语音帧传不出去，表现为“音频破音+吞字”。这类问题往往需要推动终端厂商升级信令或音频处理固件才能解决。

3. 核心优化方案与参数配置实践：可以直接抄的作业

3.1 无线侧优化配置：先守住空口这条生命线

无线侧是VoLTE语音优化的主战场，几个关键开关和参数直接影响用户的语音感知。

第一，TTI Bundling要不要开？

TTI Bundling（传输时间间隔捆绑）是LTE时代专门为VoIP类小包业务设计的特性，把同一数据包的多个冗余版本在连续4个TTI里发送，增加解调成功率。该特性在覆盖边缘场景的价值非常明显，代价是占用更多时频资源。一旦开启，边缘用户的上行语音覆盖将显著增强，RTP丢包率降低是立竿见影的。

但要注意，TTI Bundling对资源消耗较大，在话务拥塞小区不建议全用户开启，一般可以基于无线环境或者用户位置来配置触发条件，比如只对弱信号用户生效。实际处理覆盖边缘吞字问题时，开TTI Bundling是最常用的手段之一。

第二，PDCP丢弃定时器和RLC重传门限怎么配？

PDCP层有丢弃定时器，控制语音包在发射端能等待多久。如果RLC重传一直不成功，超过定时器，PDCP层直接丢弃。对语音而言，适度的丢包好过迟到的包，因为迟到的包到了接收端也可能被jitter buffer丢弃，还浪费了空口资源。

我常用的一组参数是：PDCP discard timer设置150ms；RLC SDU丢弃开启；RLC重传最大次数不用刻意提高，一般默认值即可。这样做的目的是让传输不过来的语音包尽快放弃，给后续的语音包让路，避免多个积压包会造成连锁等待导致整段语音连续丢失。

第三，RoHC头压缩：大流量场景的“减负神器”

RTP头部通常有40字节（IP+UDP+RTP），而语音载荷一般只有20到40字节，如果带上完整头部，空口效率极低。RoHC（鲁棒性头压缩）可以将RTP头部压缩到2到4个字节，大幅提高空口承载效率，减少资源竞争，也能降低丢包概率。

但RoHC也有代价：在有丢包的链路上，RoHC的上下文可能损坏，需要反馈和重建上下文，这个过程中语音包可能暂时丢失。所以单纯追求低丢包率的场景，开RoHC帮助有限；但高话务量、资源拥塞的场景，RoHC释放出的空口资源能显著降低整体丢包率。

实践的平衡点是：在VoLTE渗透率高的重点区域开启RoHC，但要在IMS侧SBC关闭RoHC处理，避免核心网侧又重新加头。保持端到端头压缩能力一致。

第四，QCI=1的调度优先级和BLER目标值

VoLTE专用承载QCI=1在基站里有独立的调度优先级配置，一般建议将QCI=1的调度优先级设置高于QCI=2的实时视频和QCI=9的非实时数据。在空口拥塞时，优先保证语音调度资源，必要时通过“资源抢占”机制，牺牲部分数据业务资源来保障语音。

BLER目标值通常是10%，这是LTE系统默认配置。如果侧重语音覆盖，可以降到8%甚至5%，相当于让MCS选择更保守、传输可靠性更高，用吞吐率换实时性。但这个值不宜全员统一改，否则空口资源利用率下降，反而影响容量。折中做法是只对VoLTE边缘用户启用更低的目标BLER。

3.2 核心网/IMS侧优化配置：别让数据面拖后腿

无线侧做完，核心网侧的参数同样重要，而且经常被忽略。

jitter buffer的自适应策略是重点。SBC或终端都有jitter buffer，用于对抗RTP网络抖动。固定型jitter buffer配置简单，比如固定40ms、60ms、80ms，但如果配置的容量偏小，网络稍有抖动就产生丢包；配置偏大，又会增加端到端时延。现在主流网元支持自适应jitter buffer，根据实时的抖动统计动态调整缓冲区长度。实际优化中，建议开启SBC侧的自适应抖动缓冲功能，并设置合适的上下限范围，比如初始深度20ms，最大不超过200ms——既能吸收突发抖动，又不会让时延增加到影响用户交互的程度。

编解码模式切换参数也要核查。网络侧下发的AMR编解码模式和速率集合，会影响终端在信道变化时的响应策略。常见的优化做法是开启AMR-WB 23.85kbps等高音质档位，同时开启编解码模式自适应，让终端在弱信号时自动降速保连续性。

eSRVCC阈值设置是保障VoLTE在LTE覆盖差时的延续手段。虽然VoLTE用户基本都支持SRVCC，但如果不能顺利切换到2G/3G，覆盖稀疏时还是会发生语音中断。关键是设置合理的B2事件门限，太早切换，浪费LTE资源而且切过去后是3G语音质量不一定好；太晚切换，语音质量已经严重劣化甚至掉话，用户早就骂人了。实际经验是把B2门限设到-110dBm左右，同时结合2G/3G侧空口负荷综合判断，确保关键时刻能及时切换。

3.3 终端侧优化策略：网络侧做好“扶上马送一程”

终端的问题不能完全指望厂商，网络侧也能做一些预防性配置。

比如通过信令配置下发终端支持的VoLTE特性集，包括RoHC能力、AMR-WB编码能力、自适应编码切换等，保证终端以合理的参数组合进入语音业务。部分基站的语音承载配置还可以对特定终端型号进行差异化的参数设置，暂不统一修改，但要留意终端兼容性列表并及时更新。

还有一个实操里常见的坑——部分安卓手机在VoLTE通话过程中，如果开启了系统级网络省电策略或游戏加速之类的功能，可能会通过“智能网络切换”机制临时改变语音承载路径，频繁在LTE和WLAN间切换，或者触发系统层的WiFi Calling尝试，这会造成VoLTE通话短暂中断。建议在投诉处理时，提醒用户先关闭这类第三方网络优化App，再复测确认。

4. 实战案例：一次“高速移动+重叠覆盖”场景下的吞字问题排查

4.1 现象表现：高铁场景全员中招

有一年处理过一个地市的高铁VoLTE投诉，用户集中反馈在列车行驶经过某个区段时，打电话频繁出现“声音断断续续，一句话要重复三四遍”，严重的时候直接听不见对方说话，但是业务数据上网却几乎不受影响。

后台KPI看，该路段VoLTE的端到端RTP上行丢包率高峰期达到3%左右，MOS均值只有2.8，切换成功率只有97%左右，指标确实异常，但问题是“为什么其他数据业务不受影响”。

4.2 逐段定位过程：三个环节层层排除

先查无线侧。高铁场景的无线网络专门做了连续的D1/D2频段专网覆盖，但列车上用户的移动速度达到250km/h以上，多普勒频移和频繁小区切换都极易造成无线链路变差。通过路测数据发现在两个基站交界的位置，SINR骤降到0dB以下，PDCP层已经开始大量丢包；且该处存在邻区重叠覆盖区域，终端在切换时容易发生测量漏检或者触发A3事件，切换带内反复切换、迟迟不选目标小区。

再查核心网媒体面。用抓包工具观察该路段用户的RTP流，发现RTP报文到达核心网时间间隔不再是稳定的20ms，而是出现20、40、60、80ms交替的情况，甚至出现160ms+的大间隔，抖动值达到80ms以上。这说明无线侧已经明显影响了RTP流的时空连续性，但核心网侧本身没有丢包。

最后看终端日志。高铁用户终端处于高速移动状态，终端的自动邻区关系（ANR）和异频测量能力有限，在切换带内可能出现测量上报不及时，导致切换命令晚到，最终触发RLF和RRC重建。重建期间语音中断500ms以上，用户感知就是“一句话被切掉了一半”。

4.3 优化措施组合拳：三管齐下解决

定位清楚后，没有做单点参数调整，而是组合优化：

第一，调整切换参数。将切换带内A3事件偏移量调大，迟滞时间略微增加，避免终端在重叠覆盖区反复触发切换；同时把同频切换的触发时延从320ms降低到160ms，确保快速切换。这一步解决了切换带内反复切换引发的掉话和语音中断。

第二，开启TTI Bundling并调整PDCP discard timer。高铁场景覆盖边缘的语音上行质量是瓶颈，开启TTI Bundling后，语音包通过冗余传输获得更多解调机会；同时把PDCP丢弃定时器从默认值调整为120ms，确保及时丢弃无法传输的旧包，让语音流保持实时性。

第三，核查核心网侧SBC的自适应jitter buffer配置。将SBC的jitter buffer初始深度从40ms调整为60ms，最大深度从200ms调整为240ms，稍微大一点冗余去吸收高速移动场景下的RTP抖动。这个微调虽然增加了约20ms的时延，但对用户体验来说是值得的。

优化后，该路段VoLTE RTP丢包率从3.1%降到0.4%，MOS均值从2.8提升到3.9，投诉量明显下降，切换失败导致的语音中断概率几乎为零。这个案例能够代表最常见的高铁场景吞字断续问题的处理套路：无线参数优先、核心网参数兜底，双管齐下。

5. 效果验证与常态化保障体系：别让优化措施变成“一次性动作”

5.1 优化前后怎么对比才科学

优化措施上线后，千万不要只看后台指标好转就觉得结束了。后台指标是无数的采样点平均出来，容易掩盖极端值，而用户感知恰恰最受极端值影响。

建议优化后至少安排一轮专业路测，选取之前投诉集中的路线和时段，用语音质量测试设备拨打VoLTE电话，采集端到端MOS、RTP丢包率、切换带切换成功率等指标。路测拨测时，重点测试长呼场景（至少3分钟以上），因为长呼更容易暴露切换带和弱覆盖区域的劣化点；而短呼往往还没有经历任何切换场景，质量当然好。

同时要做几个不同方向的对比：优化前和优化后对比、不同终端型号对比、忙闲时对比。如果条件允许，尽量用同一测试终端、同一路线、同一时段，保证控制变量。

5.2 建立常态化监控和预警机制

优化不是一次性项目，尤其是VoLTE语音质量，会因为无线环境变化、话务模型变化、终端更新换代而持续劣化。建议在日常网络运维中，建立专门针对VoLTE语音的质量监控看板，至少覆盖以下指标：

端到端RTP丢包率、时延、抖动，按基站粒度统计；
小区级接入性、保持性、完整性指标；
MOS均值及劣化小区（MOS低于3.0的小区）数量；
切换带指标，比如切换成功率、切换时延、切换带内RLF次数；
异系统互操作指标，比如eSRVCC切换成功率、切换时延。

另外可以建立“语音竞分”或者“语音体验质量评分”机制，用综合评分对全网小区做月度排名，连续两月排末位的小区自动生成工单并安排现场测试。这种方式远比等用户投诉后再被动响应更有效。

每当网络进行重大操作（软件升级、参数变更、承载结构调整）后，也建议把VoLTE语音质量指标作为重点回归项，多跑一轮语音质量专项测试，把“优化方案”变成“保障方案”的一部分。

6. 常见问题与排查技巧实录：这些年踩过的坑

6.1 易混淆问题速查表：先看表现，再定方向

很多VoLTE语音质量问题在初期表现相似，但在处理时思路差别很大。我做了一个速查表，基本能从现象直接索引到可能的根因：

现象	可能根因	重点排查环节
每隔一小段时间固定丢字	SID帧（静音描述帧）丢失，DTX/DRX配置异常	终端侧省电参数、空口调度
打电话时看视频不卡、语音卡	QCI=1承载被限速，PCRF下发GBR参数异常	核心网PCRF、HSS签约数据
高速移动时明显，静止时正常	多普勒频偏大、切换带重叠覆盖	无线侧频偏补偿、切换参数
同一区域某型号手机投诉多，其他手机正常	终端芯片VoLTE实现存在Bug或射频性能差异	终端日志、厂商固件版本
呼通后前1-2秒正常，然后断续几秒	jitter buffer初始化慢，RTP媒体面切换	SBC媒体面会话建立流程
无线指标很好RTP丢包却高	传输链路误码率高、微波/卫星链路抖动	传输侧Ping测试、端口抓包

6.2 我自己坚持的几条排查原则

处理VoLTE语音问题时，我有几条一直坚持的实践原则，虽然看起来基础，但关键时刻能救急：

第一，先看终端日志，再看网侧数据。终端日志记录的是用户真实感知的最小闭环，包含了从空口到下层的完整时间戳和RTP报文序列。很多网侧指标都正常、但用户感知很差的情况，最终都是靠终端日志定案的。日志里重点关注RTP乱序、RTP时间戳异常、编解码模式切换和DRX周期这几类信息。

第二，抓包要“多点同步”。单点抓包只能说明单段没有问题，不能证明整条链路没问题。最好做到终端、基站、核心网媒体面三个点同时抓包，然后再做时间对齐，用RTP序号和时间戳关联推演出哪一段产生了问题。这个方式虽然麻烦，但定位准确率很高。

第三，不要忽视语音以外的隐性业务对语音的影响。同一个用户可能同时在使用微信语音、抖音视频等数据业务，大量的后台数据流量会冲击VoLTE调度的实时性。虽然QCI=1有高优先级，但调度器面对大量数据业务排队和射频资源紧张时，有时也保不住语音的实时调度。排查时要问用户“通话时是不是同时开着数据业务”，必要时先复现再对比开关数据业务的情况。

第四，改参数要小步快跑，不要一把梭。VoLTE参数之间是相互关联的，比如PDCP丢弃定时器和RLC重传次数会互相影响，TTI Bundling和DRX参数也有关联关系。如果一次性改太多参数，出了问题不知道是哪一项引起的。我的习惯是一次只改1-2个参数，验证效果后再动下一项，既稳又能沉淀经验。