概述：电话能打通，却听不见对方——单通（One-Way Audio）是通信运维里最“粘人”的软故障：不瘫痪网络、不动摇KPI，却让客服投诉和一线工程师同时崩溃。本文以一次省域VoLTE单通故障的30小时处置实录为轴，讲清信令面与媒体面分离的原理、状态防火墙与非对称RTP的致命组合（对应IETF最佳实践RFC 4961），并沉淀一套可复用的五步定位法与预防清单。回答一个核心问题：信令全绿、接通率正常时，为什么电话还是“听得见说不出”？
在语音网络运维的故障谱系里，故障分三档：断网是灾难，全网上下如临大敌；掉话是慢性病，有指标盯着；而单通是幽灵——网络看起来一切正常，用户却在电话两头干着急。
单通的典型表现有四种：
它折磨人是有道理的。断网有告警轰炸，掉话有掉话率指标，唯独单通：呼叫接通率是100%（信令层面确实接通了），计费话单一条不少（计费只认信令），无线侧MR/掉线指标一片绿。用户的唯一反馈渠道是客服投诉，而客服的第一句话永远是“您重启一下手机试试”。
一线的老经验是：单通投诉占总语音投诉的比例通常不高，但重复投诉率极高——用户打不通可以忍，打通了说不上话，忍不了。所以单通往往不是“指标问题”，而是“口碑问题”。
要理解单通，先要接受一个反直觉的事实：一通电话在IP网络里是两条几乎独立的腿在走——信令腿负责“把电话接起来”，媒体腿负责“把声音送过去”。两条腿各走各的路，一条断了，另一条毫无察觉。
以VoLTE/IMS为例，一次呼叫的信令流程是主叫终端发出INVITE，网络侧（P-CSCF、S-CSCF、被叫侧）逐段转发，被叫振铃、摘机后回200 OK，主叫发ACK确认。到此为止，电话已经“接通”——接通率、应答率这些KPI全部由这条腿产生。
真正承载语音的是RTP报文，它不经过CSCF，而是从终端出发经基站、承载网，直达网络边界的媒体网关，再转发给对端。双方具体“在哪个IP哪个端口收发RTP”，是在信令过程中用SDP（会话描述协议）协商的——INVITE和200 OK的消息体里各带一份SDP，c=行写媒体地址，m=行写端口。
关键角色是SBC（会话边界控制器）。按照维基百科SBC条目的梳理：SBC以B2BUA（背靠背用户代理）方式工作，把一通电话拆成两段——它先终结主叫的呼叫，再向被叫发起一段新呼叫；当配置为媒体锚定时，它还会改写SDP中的c=和m=行，让双方媒体都经过自己中转。在3GPP的IMS架构里，接入侧的SBC对应信令面的P-CSCF（配合IMS-ALG）加媒体面的IMS Access Gateway（即BGF），互联互通侧则对应IBCF加TrGW。所以你抓包时会发现：终端以为自己在和对端通话，其实RTP是发给省内SBC的媒体地址的。
这里就是单通问题的理论核心。IETF在2007年发布的RFC 4961《Symmetric RTP / RTP Control Protocol (RTCP)》（BCP 131，作者Dan Wing，时任职Cisco）把这件事讲透了，三个要点：
看懂这三条，你就明白单通的经典配方了：只要某段路径上存在状态防火墙或NAT，而媒体流又是非对称的（SDP通告的地址/端口与实际发包的源地址/端口对不上），回程RTP就会因为匹配不上已放通的会话表项而被丢弃——信令腿完好无损，媒体腿断了一条，这就是单通。
媒体路径大致长这样：
flowchart LR
A["主叫终端"] -->|RTP| B["无线接入网"]
B -->|RTP| C["SBC媒体面 BGF<br/>媒体锚定与NAT"]
C -->|RTP| D["省际互联防火墙"]
D -->|RTP| E["对端网络"]
A -.->|SIP信令| F["P-CSCF SBC信令面"]
F -.->|SIP信令| G["对端信令网"]
注意两条腿在SBC之后分道扬镳：信令走信令网，媒体走承载网+防火墙。防火墙只看得到RTP，看不到SIP——它不知道有电话，只认识五元组。
以下案例来自笔者在省级运营商核心网团队时的亲历复盘。出于保密要求，地名、局点、设备型号与数据均已脱敏，数量级为示意，但处置过程与根因机制完全真实。
彼时省内VoLTE用户占比刚过半，IMS核心网为两套大区制SBC（信令面P-CSCF+媒体面BGF），与其他省及网间运营商的互联互通经省干防火墙出局。爆发前的那个周末，传输专业对省干防火墙做了一次例行固件升级加安全策略重构——这在当时属于“零风险”常规操作，因为升级后验证了信令互通和测试呼叫一切正常。
周一上午，客服工单聚类开始异常：“能打通但听不到对方”类投诉48小时内从日均个位数涨到200余条。特征很“挑食”：主叫集中在省内用户呼叫他省及网间号码，省内互打几乎无投诉；部分用户反映“响一声就通，对面听得到我，我听不到他”；还有少量“讲了三分多钟突然听不到”的。
timeline
title 单通故障处置时间线（已脱敏）
section D1 白天
上午 : 客服聚类发现跨省与网间方向单通集中爆发
午后 : 信令面逐段核查确认呼叫接通完全正常
傍晚 : SBC媒体话单比对锁定单向流集中在特定局向
section D2
凌晨 : 两侧同步抓包证实回程RTP被防火墙丢弃
清晨 : 根因锁定为策略收紧叠加非对称RTP
上午 : 应急恢复宽口径放通并限定对端媒体网段
下午 : 复盘会输出六项整改清单
对应的详细过程：
| 时间 | 动作 | 关键发现 |
|---|---|---|
| D1 10:20 | 客服工单聚类（号码段/时段/方向） | 无号段与终端聚集，排除终端及签约问题 |
| D1 14:00 | 核心网信令跟踪，逐条核对INVITE/183/200/ACK | 信令流程完整，SDP协商成功，排除信令面 |
| D1 16:30 | 调取SBC媒体话单的RTP/RTCP收发统计 | 异常呼叫呈“发有收无”，集中于两个互联局向 |
| D1 22:00 | 在BGF与省干防火墙内外侧同步抓包 | BGF发出的回程RTP，防火墙内侧可见、外侧消失 |
| D2 02:00 | 分析防火墙会话表与丢弃日志 | 回程RTP命中缺省deny，无对应放通会话 |
| D2 05:30 | 比对割接前后策略与对端SDP通告 | 根因确认：策略收紧+对端媒体地址非对称 |
| D2 08:00 | 应急恢复该局向媒体端口段宽放通（加对端网段ACL） | 投诉量回落 |
| D2 17:00 | 复盘会 | 输出整改清单，推动对端侧配置协同 |
事后还原，这是一个教科书级的组合缺陷：
整条链上没有任何一个环节“坏了”——每个专业单独看都符合自己的规范，组合起来却杀死了电话。这是跨专业故障最典型的样子。
这个案例暴露的不只是一次割接失误，而是运维体系的三个结构性盲区。
盲区一：KPI体系重信令、轻媒体。 接通率、应答率、掉话率全部长在信令腿上，媒体腿长期只有“用户投诉”这一个传感器。语音质量的量化指标其实存在——RTCP的收发报告（SR/RR）里就有丢包率和抖动，IMS多媒体电话的媒体处理与交互由3GPP TS 26.114《IMS多媒体电话；媒体处理与交互》规范（S4工作组负责，适用于UTRAN/E-UTRAN系统，其工作项即MTSI的媒体处理与交互），编解码协商、丢包隐藏等都有章可循。但把RTCP统计做成日常监控的省公司，坦率讲不多。
盲区二：变更验证只验“能不能通”，不验“双向对账”。 割接后的测试呼叫走的是省内对称路径，天然避开了雷区。媒体面的验证必须是双向的：不仅要听到声音，还要核对话单和抓包里上下行RTP的收发计数是否匹配。“测试电话听了一下”对单通无效。
盲区三：跨专业、跨网络的协同断点。 防火墙策略属于传输/安全专业，媒体行为属于交换专业，对端地址对称性属于对方省公司。三个主体各自合规、互相不可见。RFC 4961之所以要把“对称RTP”写成最佳实践，就是因为这件事靠任何单方都无法保证——它需要链路上的所有设备形成默契。跨网协同没有机制化，这类故障就永远会再发生。需要说明的是，各家SBC对对称RTP的具体配置项名称与默认行为存在差异，标准允许多种实现，具体以各厂家官方文档为准。
把这次和历次单通处置的经验压成一套动作，我称之为五步定位法：
flowchart TD
A["投诉爆发<br/>单通与静音工单异常"] --> B["聚类分析<br/>号码段 时段 呼叫方向"]
B --> C["信令面核查<br/>SIP流程与SDP逐段比对"]
C --> D{"信令是否正常"}
D -->|异常| E["信令问题处理<br/>路由 参数 对端局向"]
D -->|正常| F["媒体面核查<br/>RTCP收发统计 SBC话单"]
F --> G{"是否存在单向流"}
G -->|否| H["无线侧排查<br/>空口质量 编解码协商 终端"]
G -->|是| I["分段打环定位<br/>BGF 省干防火墙 互联出口"]
E --> J["根因复现与加固"]
H --> J
I --> J
第一步：聚类。 拿到投诉先别碰设备，先回答三个问题：哪些号码、什么时段、往哪打。单通几乎总带有方向性（局向、网内/网间、地域），纯随机分布反而要怀疑终端侧。
第二步：验信令。 调取异常呼叫的完整信令，确认INVITE/183/200/ACK齐全、SDP协商成功。这一步的目的是排除，不是定位——信令正常恰好是单通的定义。
第三步：看媒体账。 找SBC要媒体话单或RTCP统计，看异常呼叫的RTP收发计数。“发有收无”或“收有发无”即可坐实单向流，并按局向聚合出重灾区。这是整个方法论里性价比最高的一步。
第四步：分段打环。 在媒体路径的每个边界（终端↔基站、基站↔BGF、BGF↔防火墙、防火墙内外侧）同步抓包，RTP流在哪一跳消失，问题就在哪两跳之间。抓包要上下行同时采，只抓单向永远看不见“对面没来”。
第五步：复现与加固。 修复后用受控拨测复现原场景，确认闭环；同时回答“为什么以前没炸、为什么现在炸了”，把变更关联找出来，否则整改只治了标。
各环节的工具链分工：
| 工具/数据源 | 看什么 | 能定位到 | 局限 |
|---|---|---|---|
| 客服工单聚类 | 号码/时段/方向分布 | 故障范围与方向性 | 粒度粗、滞后于爆发 |
| 核心网信令跟踪 | SIP流程、SDP内容 | 排除信令面 | 完全看不到媒体 |
| SBC/BGF媒体话单 | RTP/RTCP收发统计 | 单向流与局向归属 | 依赖话单字段事先配置 |
| 分段同步抓包 | 五元组、丢包边界 | 定位到具体网段/设备 | 需跨专业协同窗口 |
| Wireshark RTP分析 | 流对称性、丢包抖动 | 出具铁证 | 现场条件苛刻 |
| 端到端拨测机器人 | 双向录音比对 | 持续观测复发 | 样本覆盖有限 |
复盘会最后产出的整改清单，我提炼成四条建议：
第一，变更CheckList里加入“媒体双向验证”。 凡涉及防火墙、NAT、SBC、互联出口的割接，验证标准不是“测试电话能通”，而是“测试电话双向录音比对通过+媒体话单收发计数平衡”。宽口径放通到严格模式的策略收紧，必须逐局向验证——尤其是经NAT的互联方向。
第二，配置基线向RFC 4961对齐。 在网络内及对外协同中推动对称RTP成为默认：媒体锚定点的通告地址与实际发包地址保持一致，收发同一五元组。这不仅是排障友好，RFC 4961还指出对称RTP能让防火墙的动态放通规则更收紧，安全性和连通性在这里是同向的。
第三，媒体面监控上架。 从RTCP统计里算出单向流占比、丢包率、MOS估值，按局向出日报。把“单向流占比”当成和掉话率同级的指标，单通就从“投诉驱动”变成“指标驱动”。这个指标不需要大投入——数据一直都在SBC话单里，只是没人看。
第四，常态化拨测。 拨测机器人每天对各互联局向做双向录音呼叫，比对音频指纹。本次故障里，如果有常态化拨测，割接后第二天上午就能自动发现，而不是等用户教我们做人。
单通是通信网络里最诚实的一种故障：它不制造宏大叙事，不会上新闻头条，只暴露最朴素的事实——你以为网络是一条路，其实是两条。信令告诉你“接通了”，只代表双方同意通话；声音能不能过去，是另一套协议、另一条路径、另一批设备在负责。
RFC 4961用五页纸讲清了这件事，二十年后它依然是单通排障的第一性原理：UDP不讲双向，防火墙只认五元组，非对称的媒体流在严格的网络里活不下去。下次值班再遇到“听得见说不出”，先别让用户重启手机——去要一份SBC的媒体话单，看看那条断了腿的RTP流，到底走到了哪一跳。
本文由「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 等场景全覆盖。