# 消失的半声喂：语音单通排障记 **概述**：电话接通了，却只听得到半边声音——“喂喂喂”之后是一片死寂。这就是让无数核心网和无线运维工程师夜不能寐的“单通”故障。它信令面一切正常、KPI一片绿，却直接砸掉用户对网络最朴素的信任。本文以 3GPP TS 26.114 定义的 IMS 媒体机制为基准，讲清单通故障的媒体面原理、四大根因家族、一套从投诉聚类到 RTP 抓包取证的完整排查方法，并用两个脱敏的实战案例复盘“消失的半声喂”是怎么被找回来的。回答一个问题：为什么语音单通是通信运维里最隐蔽、也最能考验基本功的故障类型？ ## 目录 - 一、从一句“喂”说起：什么是单通 - 二、媒体面原理：那半声音到底走哪条路 - 三、单通的四大根因家族 - 四、实战复盘一：防火墙“偷走”了回程 - 五、实战复盘二：SBC 端点泄漏的慢性病 - 六、工具链：把“听不见”变成“看得见” - 七、修复的证明：MOS 与拨测回归 - 八、预防体系：把单通堵在割接之前 - 结语 ## 一、从一句“喂”说起：什么是单通 用户视角的单通，通常长这几种样子： - **主叫单通**：主叫听不到被叫，被叫能听到主叫； - **被叫单通**：反过来，被叫成了“哑巴”； - **双向静音**：两边都听不到对方，但计费时长照走，通话能正常挂断。 单通和掉话不同。掉话是连接断了，用户会重拨；单通是连接“看起来”完好，双方对着空气喊话，直到其中一方挂断。从用户感知的角度说，单通比掉话更伤：掉话像“电话没打通”，单通像“运营商在耍我”。 对运维来说，单通还有一个更讨厌的特征：**它是媒体面故障，而不是信令面故障**。SIP 信令一切正常——INVITE、180、200 OK、BYE 时序完整，S1/NG 承载建立顺利，核心网侧 E-RAB/DRB 建立成功率、IMS 注册成功率全绿。唯一的异常发生在 RTP 语音包的流向里：包没到，或者到了但没人能听懂。传统网管告警体系盯着信令和资源，对“包在流动但只有一边”这件事几乎失明。这就是为什么单通往往先由用户投诉发现，而不是网管先发现——在投诉聚类平台成熟之前，很多省网的单通平均发现时间是以“天”计的。 ## 二、媒体面原理：那半声音到底走哪条路 要排查单通，先得知道语音包的完整旅程。以 VoLTE/VoNR 语音为例，媒体面的规则由 3GPP TS 26.114（IMS 媒体处理与交付）定义，它规定了语音媒体用 RTP/RTCP 承载、AMR/AMR-WB 编解码的协商与打包方式、jitter buffer 管理与丢包处理要求，是解读一切语音媒体故障的标准基准。配合 GSMA IR.92（VoLTE 档案）对编解码集、专属承载 QCI=1（VoNR 下为 5QI=1）的要求，构成媒体面的“宪法”。 一通 VoLTE 电话的媒体路径，简化后是这样： ```mermaid sequenceDiagram participant UA as 主叫手机 participant RAN as 基站 participant SBC as SBC媒体锚点 participant UB as 被叫手机 UA->>SBC: SIP INVITE 协商AMR参数 SBC->>UB: INVITE 转发应答 UB-->>SBC: 200 OK 带应答SDP UA->>RAN: 上行RTP语音包 RAN->>SBC: 经核心网转发 SBC->>UB: 下行RTP送达对方 Note over UA,RAN: 上行无线劣化时此段丢包 UB-->>UA: 回程RTP缺失即单通 ``` 几个对排障至关重要的机制细节： **第一，媒体必须过锚点。** 依照 IMS 架构，P-CSCF/SBC 始终在媒体路径上（媒体锚定），eSRVCC 场景下 ATCF/ATGW 还要在切换时接管媒体。锚点是好事——出了问题只有一个确定的位置可查——但锚点自身资源出问题时，也是全网性的。 **第二，RTP 是“无连接式”的流。** 承载建立后，两端按协商好的 IP:端口 对发 UDP 包。UDP 没有 keepalive，中间任何一台有状态的设备（防火墙、NAT、SBC 会话表）都靠“多久没看到包”来决定是否删除会话表项。这引出单通最经典的坑：**会话老化时间与媒体间隙的冲突**。开静音抑制（DTX/VAD）时，说话间隙媒体流可能只剩稀疏的舒适噪声包，如果防火墙的 UDP 老化时间被改得比这个间隙还短，表项被删，后续回程包全部被静默丢弃——注意是**静默**丢弃，不回任何错误，通话照常计时。 **第三，编解码协商是双向承诺。** TS 26.114 与 IR.92 规定 AMR-WB 为主力编解码，SDP 中通过 mode-set 等参数约束模式集。主被叫两侧（或两侧网络）模式集不一致、payload type（PT）映射错位、SDES 加密协商失败后回退不干净，都会造成“包到了，但解不出来”——双向静音的常见来源。 **第四，无线侧天然不对称。** 上下行是两条独立的无线链路。对方听你断续，问题往往在**你的上行**（发射功率、干扰、功控异常），而不在对方的下行。这个不对称是无数新手排障时绕弯路的根源。 ## 三、单通的四大根因家族 把多年遇到的成百起单通归纳一下，逃不出四个家族。标准允许多种实现，具体网元在媒体处理上的行为细节以各厂家官方文档为准，但故障模式高度收敛： | 家族 | 典型根因 | 现场特征 | 定位手段 | 修复动作 | |---|---|---|---|---| | A 承载与资源类 | QCI=1 专载被删、eSRVCC 时 ATGW 媒体分支未更新、媒体网关端点泄漏 | 集中于切换边界、跨制式切换时刻；故障随时间累积加重 | 信令跟踪看承载事件；查 SBC/MGW 端点占用水位 | 修正切换参数、清理泄漏、升级缺陷版本 | | B 协商与参数类 | AMR 模式集不一致、PT 映射错位、SDES 回退残留 | 双向静音居多；特定号段/特定路由成规模复现 | 比对两侧 SDP；抓包看 RTP 头 PT 与实际编码 | 统一模式集配置、修正 PT 映射 | | C 无线上行类 | 上行干扰、功控异常、RLC UM 丢包、麦克风硬件故障 | 对方听我方断续/无声；与小区、楼层、终端型号相关 | 路测上行 SINR/MCS；基站侧上行质量统计 | 排干扰、调功控、换机验证 | | D 有状态中间盒类 | 防火墙/NAT 老化时间过短、会话表满、策略误杀 | 变更后批量爆发；跨安全域通话才出问题 | 中间盒会话表核查；两端抓包对比 | 老化时间设基线、放行媒体端口段 | 四个家族里，A 和 D 是核心网运维的主战场，C 归无线优化，B 是割接和互联互通的高发区。实战中大约七成的“玄学单通”，最后都落在这张表的某一行里。 ## 四、实战复盘一：防火墙“偷走”了回程 > 以下案例为作者亲历故障的脱敏改写，涉及网络与数据已做示意化处理，时间线结构保留原貌。 某东部省网，晚 21:40 起投诉平台开始涌入“打通了没声音”的工单，22:30 达到峰值，投诉集中在同一地市的两个行政区。这就是典型的“单通风暴”开局。完整处置时间线如下： | 时间 | 事件 | 关键判断 | |---|---|---| | 21:40 | 首批投诉进入客服，按个案派单 | 无整体视图，黄金半小时流失 | | 22:10 | 投诉聚类命中“单通”标签，关联度异常 | 升级为重大故障，拉起应急 | | 22:25 | 信令面核查：SIP 时序、承载建立全正常 | 排除信令，转向媒体面 | | 22:50 | 投诉样本回拨测试复现：主叫能听到被叫，反向无声 | 确认单向，方向性成为最重要线索 | | 23:15 | SBC 双侧抓包：SBC 收到被叫侧 RTP，向主叫侧发出的包无应答 | 断点锁定在 SBC 与主叫侧网络之间 | | 23:40 | 中间防火墙会话表核查：回程 RTP 会话表项不存在 | 会话未建立即被丢弃 | | 00:20 | 查变更记录：当晚 21:30 该防火墙 UDP 老化时间由 1800 秒调整为 60 秒 | 根因浮出水面 | | 00:35 | 回退防火墙配置，回拨验证恢复 | 从首例投诉到恢复 2 小时 55 分 | | 次日 | 回溯：为何 21:40 前的通话正常 | 见下文“渐进失效”解释 | 这个案例最有教学价值的是最后一步。为什么老化时间改小后，故障不是立刻全网爆发，而是逐步出现？因为只有 RTP 静音间隙超过 60 秒的通话才会触发表项回收——而正常说话的间隙远短于此。真正中招的是两拨人：通话中长时间沉默的用户（会议电话、等待音乐、放着没挂的电话），以及媒体流因切换短暂中断超过阈值的用户。**故障面是随时间“泡”出来的**，这种渐进性让当晚值班一度怀疑是话务高峰导致的资源类问题，绕了不小的弯。 复盘的教训有三条。其一，任何中间盒的老化时间变更，影响面评估必须覆盖“静音抑制场景下的媒体间隙”，这是 TS 26.114 允许 DTX 之后必然出现的物理事实，却常年不在变更检查单上。其二，方向性（谁听不到谁、包在哪一侧消失）是单通排障的第一指纹，抓包必须双侧同步做，单侧抓包无法回答“包死在哪一段”。其三，变更窗口 21:30、故障 21:40，十分钟延迟在变更与故障之间划了一条几乎笔直的因果线——**变更时间戳必须进入故障定位的第一屏**。 ## 五、实战复盘二：SBC 端点泄漏的慢性病 第二个案例慢得多，也更典型。某 VoLTE 网连续数月零星单通投诉，每周十几单，不成规模、不成区域、不成终端型号，投诉聚类完全无法命中，一直被当成用户手机问题消化掉。转折点是 Quality 团队把 RTCP 收发报告（Receiver Report 里的丢包与抖动统计）接进了报表体系：RTCP 是 TS 26.114 里媒体流的“体检报告”，收端会周期性地把收包质量告诉发端。报表显示某一对 SBC 的媒体端点会话数呈锯齿状爬升——每次重启后回落，随后周而复始地涨。 定位过程：对该 SBC 做端口级核查，发现大量媒体端点处于“信令已释放、媒体未释放”的悬挂状态——通话 BYE 之后，对应的 RTP 端点没有归还端点池，池子耗尽后新通话分配不到端点，该节点对媒体的处理进入异常状态，部分通话表现为单向无声。根因指向该版本在特定 BYE 时序（与 183 早应答竞争）下的一处资源释放缺陷，升级版本后水位曲线拉平，单通投诉同步消失。 这类“慢性单通”的教训在于：**低频但持续的单通，往往不是无线问题，而是资源缓慢泄漏**。它骗过了所有以“爆发”为假设的告警体系。对策是把 SBC/MGW 的媒体端点占用率、悬挂端点数做成趋势告警——水位连续 N 天单调上升即触发，而不是等池子打满的那一刻才告警（那一刻的表现往往是新呼叫失败，又会被误判成容量问题）。同时把 RTCP 统计当作免费的分布式探针：全网几万路并发通话，每一路都在实时上报丢包抖动，这是任何人工拨测都望尘莫及的监测密度。 ## 六、工具链：把“听不见”变成“看得见” 单通排障的本质，是把一个主观感受问题转化为一个包流向问题。成熟的排查链路是一棵决策树： ```mermaid flowchart TD A["投诉：听不到对方"] --> B{"信令面正常吗"} B -->|信令异常| C["先修信令面
查SIP时序与承载"] B -->|信令正常| D{"RTP死在哪一段"} D -->|只有上行无下行| E["查对端网元
与NAT防火墙会话"] D -->|只有下行无上行| F["查主叫上行无线
与终端麦克风"] D -->|包都在但听不懂| G["查编解码协商
PT映射与解密回退"] E --> H["核对老化时间基线
与会话表容量"] F --> I["查上行干扰功控
与RLC丢包统计"] G --> J["逐字段比对SDP
与RTP头实测"] ``` 链路上的关键工具与用法： **投诉聚类先行。** 不要拿到第一张工单就开始抓包。先用投诉平台把 24/48 小时内的语音类投诉按“无音/单通/断续/回声”打标聚类，看有没有时间、区域、号段、终端的聚集性。单通风暴与慢性单通的第一小时处置差异，完全取决于这一步的效率。 **信令与媒体关联跟踪。** 现代核心网都支持带关联标识的信令跟踪（SIP Call-ID、S1/NGAP 关联、RTP SSRC 的映射），目标是把“这一通电话”的 SIP 信令、承载事件、RTP 流拼成一条证据链。抓包首选 SBC 两侧同步进行——SBC 是媒体锚点，它两侧的包差就是断点判决书。 **Wireshark 的 RTP 分析。** 抓到包后，Telephony 菜单下的 RTP 流分析可以按 SSRC 分方向列出丢包率、抖动、时延曲线，波形图会直观地告诉你：这条流是“断流的”（一个包都没有）、“半流的”（单向有包），还是“有包但解不出来”（包在，内容乱）。三者分别对应 D 类、C 类和 B 类根因，一张图完成初判。Wireshark 官方文档对 RTP 分析功能有完整说明。 **无线侧回归路测。** 决策树走到 C 类，就该轮到路测车了：上行 SINR、MCS、功率余量、RLC UM 丢包，配合基站侧上行质量统计。别忘了最朴素的物理验证——换一台手机复拨，排除麦克风硬件，这一步每年都能为运营商省下无数无效排查工时。 ## 七、修复的证明：MOS 与拨测回归 “包通了”不等于“修好了”。语音质量是主观量，行业用 ITU-T P.863（POLQA）把主观听感模型化为 MOS 分——它是 P.862（PESQ）的继任者，针对宽带与超宽带语音做了重新校准，是当前运营商语音测评的主流算法。POLQA 官方站点对算法原理与适用范围有完整说明。 实战中的回归验证分三层：**定点拨测**（修复点周边布点，主被叫互拨几十至上百次，统计单通复现率是否归零）；**路测回归**（车载 MOS 采集，修复区域与对照区域对比）；**投诉曲线观测**（修复后 72 小时投诉量是否回落到基线）。实战复盘一的案例里，回退后当晚的定点拨测 200 通零复现、次日起投诉回落至基线，才算闭环。跳过这一步的“修复”，在运维考核里不算修复——这是用无数返工换来的纪律。 ## 八、预防体系：把单通堵在割接之前 单通的预防，本质是三件事： **变更防线。** 凡涉及媒体路径的变更——SBC 扩容、防火墙策略、NAT 设备更换、编解码策略调整——检查单必须包含三项：媒体间隙与老化时间的约束校验、变更前后双向定点拨测、回退预案及触发条件。实战复盘一里的 60 秒老化时间，若有拨测这道闸，撑不过十分钟。 **水位防线。** SBC/MGW 媒体端点占用率、悬挂端点数、会话表利用率全部纳入趋势告警；RTCP 统计进报表，分网元聚合丢包率，单网元丢包率异常抬升即预警。资源泄漏类故障在水位曲线上藏不住。 **指标防线。** 建立“信令正常但媒体异常”的隐性故障 KPI：按网元聚合的 RTCP 丢包超标通话占比、拨测单通率，进每周质量例会。单通率的分母是接通通话、分子是媒体异常通话，它不在传统的接通率里——**接通率 99.9% 的网络，单通率可能是 1%**，这两张面孔必须同时盯着。 最后说一句行当里的老话：信令面故障考验的是对协议的记忆，媒体面故障考验的是对系统的想象力。单通之所以是运维的基本功试金石，因为它逼着你把 SIP、承载、无线、中间盒、编解码在脑子里串成一条完整的水路——哪一环没串通，哪一环就会在某天深夜，替你把用户的半声“喂”吞掉。 ## 参考来源 1. [3GPP TS 26.114 — IMS Media handling and delivery (RTP/RTCP)](https://www.3gpp.org/dynareport/26114.htm) — IMS 语音媒体承载的标准基准：RTP/RTCP 用法、AMR 协商、jitter buffer 与丢包处理要求，本文媒体面解读的主轴 2. [GSMA IR.92 — LTE/VoLTE Profile](https://www.gsma.com/) — GSMA 官方 VoLTE 档案，规定编解码集、QCI=1 专载与媒体锚定要求（文档可在 GSMA 官网检索 IR.92 获取） 3. [ITU-T P.863 (POLQA)](https://www.itu.int/rec/T-REC-P.863) — 语音质量客观评测国际标准，MOS 分数的算法来源，PESQ 的继任者 4. [3GPP TS 23.237 — IMS Service Continuity](https://www.3gpp.org/dynareport/23237.htm) — eSRVCC/ATCF-ATGW 媒体锚定与切换的规范依据，承载与资源类单通的标准背景 5. [Wireshark 官方文档](https://www.wireshark.org/docs/) — RTP 流分析、Telephony 功能的使用说明，媒体面取证工具链参考 --- > 本文由「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 等场景全覆盖。