<!-- title: 电话单通：听得见说不出的故障 -->

**概述**：电话能打通，却听不见对方——单通（One-Way Audio）是通信运维里最“粘人”的软故障：不瘫痪网络、不动摇KPI，却让客服投诉和一线工程师同时崩溃。本文以一次省域VoLTE单通故障的30小时处置实录为轴，讲清信令面与媒体面分离的原理、状态防火墙与非对称RTP的致命组合（对应IETF最佳实践RFC 4961），并沉淀一套可复用的五步定位法与预防清单。回答一个核心问题：信令全绿、接通率正常时，为什么电话还是“听得见说不出”？

## 目录

- 一、什么是单通：最折磨人的“软故障”
- 二、原理：一通电话的两条腿
- 三、实录：一次省域VoLTE单通的30小时
- 四、根因拆解：媒体面为何总是灯下黑
- 五、方法论：单通五步定位法
- 六、预防：把媒体面当一等公民
- 七、结语：写给值班的你

## 一、什么是单通：最折磨人的“软故障”

在语音网络运维的故障谱系里，故障分三档：**断网**是灾难，全网上下如临大敌；**掉话**是慢性病，有指标盯着；而**单通**是幽灵——网络看起来一切正常，用户却在电话两头干着急。

单通的典型表现有四种：

1. **A听得见B，B听不见A**（最常见，即单向语音）；
2. **双向都听不见，但双方话单显示通话正常**，各自对着空气讲了三分钟；
3. **时好时坏**：同一对号码，上午打正常，下午打单通，换个地方又好了；
4. **通话中途突然单向**：前两分钟好好的，第三分钟对方声音消失。

它折磨人是有道理的。断网有告警轰炸，掉话有掉话率指标，唯独单通：呼叫接通率是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的媒体地址的。

### 灯下黑的根源：UDP天生“不讲双向”

这里就是单通问题的理论核心。IETF在2007年发布的**RFC 4961《Symmetric RTP / RTP Control Protocol (RTCP)》（BCP 131，作者Dan Wing，时任职Cisco）**把这件事讲透了，三个要点：

1. **RTP不要求收发同端口**。RFC 4961开篇指出：TCP天然双向、收发同端口；而UDP不是，RTP（RFC 3550）甚至没有规定发送和接收必须用同一个端口。理论上，设备A用端口1234收，完全可以用端口5678发，本地收发端口和远端端口之间没有任何约束关系。
2. **防火墙和NAT普遍假设“对称”**。RFC 4961明确写道：“许多防火墙、NAT和RTP实现都期望对称RTP，在非对称RTP面前无法工作。”没有内嵌ALG的NAT，以及“地址依赖型”NAT，**要求**端点使用对称UDP端口才能建立双向流量；即使部署了SBC这类媒体中继，跨这类NAT仍然离不开对称端口。
3. **结论是一条RECOMMENDED**：双向RTP/RTCP流应当始终使用对称RTP/RTCP——收发同一个五元组。这样有状态防火墙只需要一条动态开洞规则，排障时也对得上账。

看懂这三条，你就明白单通的经典配方了：**只要某段路径上存在状态防火墙或NAT，而媒体流又是非对称的（SDP通告的地址/端口与实际发包的源地址/端口对不上），回程RTP就会因为匹配不上已放通的会话表项而被丢弃**——信令腿完好无损，媒体腿断了一条，这就是单通。

媒体路径大致长这样：

```mermaid
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单通的30小时

以下案例来自笔者在省级运营商核心网团队时的亲历复盘。出于保密要求，地名、局点、设备型号与数据均已脱敏，数量级为示意，但处置过程与根因机制完全真实。

### 背景与现象

彼时省内VoLTE用户占比刚过半，IMS核心网为两套大区制SBC（信令面P-CSCF+媒体面BGF），与其他省及网间运营商的互联互通经省干防火墙出局。爆发前的那个周末，传输专业对省干防火墙做了一次例行固件升级加安全策略重构——这在当时属于“零风险”常规操作，因为升级后验证了信令互通和测试呼叫一切正常。

周一上午，客服工单聚类开始异常：**“能打通但听不到对方”类投诉48小时内从日均个位数涨到200余条**。特征很“挑食”：主叫集中在省内用户呼叫**他省及网间**号码，省内互打几乎无投诉；部分用户反映“响一声就通，对面听得到我，我听不到他”；还有少量“讲了三分多钟突然听不到”的。

### 处置时间线

```mermaid
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 | 复盘会 | 输出整改清单，推动对端侧配置协同 |

### 根因链条

事后还原，这是一个教科书级的组合缺陷：

1. **安全基线整改**：割接时为收敛会话表，把互联出口从“媒体端口段宽口径放通”改成了“按信令动态开洞+严格会话模式”。信令测试呼叫是省内路径，验证不到跨省媒体面。
2. **对端媒体地址非对称**：某些互联局向的对端BGF经出口NAT做地址转换，SDP里通告的媒体地址与实际发包的源地址不一致——典型的**非对称RTP**，正是RFC 4961第4节点名的场景：这类环境下没有对称UDP端口就无法穿越NAT和防火墙。
3. **动态开洞基于通告地址**：防火墙按SDP协商结果预开洞，但回程RTP的实际五元组对不上洞，严格模式下作为“未知新连接”命中缺省deny。
4. **方向性由此解释**：省内路径无NAT、地址对称，所以省内互打正常；跨省方向里，对端对称的局向正常、非对称的局向单通——“时好时坏”取决于呼叫落到对端BGF资源池的哪台设备。
5. **“通话中途变单向”**：与割接同步调短的UDP会话老化时间相关，个别依赖回程流量维持的会话项在长通话中途老化，媒体腿当场断掉。

整条链上没有任何一个环节“坏了”——每个专业单独看都符合自己的规范，组合起来却杀死了电话。这是跨专业故障最典型的样子。

## 四、根因拆解：媒体面为何总是灯下黑

这个案例暴露的不只是一次割接失误，而是运维体系的三个结构性盲区。

**盲区一：KPI体系重信令、轻媒体。** 接通率、应答率、掉话率全部长在信令腿上，媒体腿长期只有“用户投诉”这一个传感器。语音质量的量化指标其实存在——RTCP的收发报告（SR/RR）里就有丢包率和抖动，IMS多媒体电话的媒体处理与交互由**3GPP TS 26.114《IMS多媒体电话；媒体处理与交互》**规范（S4工作组负责，适用于UTRAN/E-UTRAN系统，其工作项即MTSI的媒体处理与交互），编解码协商、丢包隐藏等都有章可循。但把RTCP统计做成日常监控的省公司，坦率讲不多。

**盲区二：变更验证只验“能不能通”，不验“双向对账”。** 割接后的测试呼叫走的是省内对称路径，天然避开了雷区。媒体面的验证必须是**双向的**：不仅要听到声音，还要核对话单和抓包里上下行RTP的收发计数是否匹配。“测试电话听了一下”对单通无效。

**盲区三：跨专业、跨网络的协同断点。** 防火墙策略属于传输/安全专业，媒体行为属于交换专业，对端地址对称性属于**对方省公司**。三个主体各自合规、互相不可见。RFC 4961之所以要把“对称RTP”写成最佳实践，就是因为这件事靠任何单方都无法保证——它需要链路上的所有设备形成默契。跨网协同没有机制化，这类故障就永远会再发生。需要说明的是，各家SBC对对称RTP的具体配置项名称与默认行为存在差异，标准允许多种实现，具体以各厂家官方文档为准。

## 五、方法论：单通五步定位法

把这次和历次单通处置的经验压成一套动作，我称之为五步定位法：

```mermaid
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流，到底走到了哪一跳。

## 参考来源

1. [RFC 4961: Symmetric RTP / RTP Control Protocol (RTCP)](https://www.rfc-editor.org/rfc/rfc4961) — IETF最佳实践BCP 131（Dan Wing，Cisco，2007年），本文原理部分的主轴来源：非对称RTP与防火墙/NAT的兼容性问题、对称RTP的定义与强制适用场景均出自此文。
2. [3GPP TS 26.114: IMS Multimedia telephony; Media handling and interaction](https://www.3gpp.org/dynareport/26114.htm) — 3GPP官方规格页，S4工作组维护，规范IMS多媒体电话的媒体处理与交互，文中作为IMS语音媒体面标准的出处。
3. [Session border controller - Wikipedia](https://en.wikipedia.org/wiki/Session_border_controller) — SBC的B2BUA工作方式、SDP c=/m=行改写、IMS架构映射（P-CSCF/IMS-ALG与IMS Access Gateway、IBCF/TrGW）的通用参考。
4. [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550) — RTP/RTCP协议本体，RFC 4961的规范性引用，RTCP收发报告（SR/RR）即媒体面监控的数据来源。
5. [RFC 4787: NAT Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) — RFC 4961引用的NAT行为分类（地址依赖型NAT等），解释非对称媒体流穿越NAT失败的底层依据。

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)