VoLTE被叫失踪案：错误码排障

概述：深夜NOC收到一批"打不通"投诉：主叫侧一切正常，被叫手机却毫无反应。本文以3GPP TS 24.229（IMS呼叫控制规范）与RFC 3261（SIP协议）为解读主轴，沿着一通VoLTE被叫电话的信令轨迹，拆解403、404、408、480、486这些"错误码遗言"背后的真实含义：谁产生了它、它想告诉排障者什么、下一步该去查哪个网元。文中三个案例为多起真实工单脱敏合并的场景复盘，方法论部分给出错误码分布看板与"振铃时延预算"两件实战工具。

目录

• 一、深夜工单：谁偷走了振铃
• 二、一通VoLTE被叫的完整旅程
• 三、错误码是信令的遗言
• 四、案例复盘一：486与一个消失的呼转
• 五、案例复盘二：480与寻呼黑洞
• 六、案例复盘三：408与被吃掉的时间预算
• 七、两件实战工具：分布看板与时延预算
• 八、写在最后：先查业务，再查网络

一、深夜工单：谁偷走了振铃

做过核心网维护的人都有这种经历：用户投诉"别人打我电话不响，也不进语音信箱，对方那边直接挂了"。这种工单最难办的地方在于——它不产生任何告警。基站没告警、网元没告警、链路没告警，所有设备都"健康"，但用户就是打不通。

这恰恰是VoLTE/IMS运维区别于传统CS域运维的地方。传统2G/3G时代，被叫失败大多数能从MSC的话单和MAP消息里找到明确原因（关机、出覆盖区、用户不存在）；VoLTE时代，一次被叫呼叫要穿越主叫侧IMS、业务网元TAS、被叫侧IMS、EPC寻呼、无线空口五层，任何一层"卡住"，最终表现都是同一个：主叫听不到回铃音，然后被释放。

但网络其实把线索留下来了，就写在最后那条SIP响应消息里。SIP的错误响应码（4xx/5xx/6xx）就像事故现场的遗言——它是哪个网元写的、写了什么、什么时候写的，这三个问题串起来，就是本文要讲的排障方法论。

先把权威依据摆出来：本文的信令流程依据 3GPP TS 24.229（IP Multimedia Call Control protocol based on SIP and SDP，www.3gpp.org/dynareport/24229.htm），错误码定义与定时器取值依据 IETF RFC 3261（www.rfc-editor.org/rfc/rfc3261.txt）。这是所有VoLTE网络的"普通话"，各厂家实现允许有差异，但SIP响应码和产生逻辑是标准明文规定的，排障时可以放心对照。

二、一通VoLTE被叫的完整旅程

要读懂错误码，先要知道这通电话走了哪些路。按TS 24.229定义，一通典型的VoLTE被叫呼叫信令路径如下（省略了P-CSCF与策略控制的交互细节）：

1. 主叫UE发出INVITE，经主叫侧P-CSCF进入主叫侧S-CSCF；
2. 主叫S-CSCF按HSS里下发的iFC（initial Filter Criteria，初始过滤准则）顺序触发业务，最常见的第一个AS就是TAS（Telephony Application Server），负责补无业务：呼转、呼叫等待、黑白名单、语音信箱；
3. TAS放行后，S-CSCF查被叫号码的路由。网内号码经ENUM/DNS翻译，出网号码走互通网关；
4. 被叫侧S-CSCF收到INVITE后查注册状态：被叫在线则经被叫P-CSCF下发到UE；被叫处于ECM-IDLE，则EPC先发起寻呼，UE通过Service Request响应后SIP才送达；
5. 被叫UE振铃回180 Ringing，主叫听到回铃音；接通走200 OK，被叫侧还要建立专用QCI=1的语音承载。

sequenceDiagram
    participant A as 主叫UE
    participant S1 as 主叫S-CSCF
    participant T as TAS
    participant S2 as 被叫侧IMS
    participant U as 被叫UE
    A->>S1: INVITE
    S1->>T: 按iFC触发业务
    T-->>S1: 放行或返回失败码
    S1->>S2: 路由至被叫域
    S2->>U: 寻呼后下发INVITE
    U-->>S2: 180 振铃
    S2-->>S1: 180 透传
    S1-->>A: 主叫听回铃音

这张图里每条向后的虚线（-->>）都可能是失败码的出生点。排障的第一个基本功，就是从失败响应的来源方向判断它在哪一跳产生：响应是从TAS回来的，还是从被叫域回来的，还是主叫自己超时产生的。三者对应的排查方向完全不同。

还有一条容易被忽略的规则：SIP的CANCEL机制（RFC 3261第9节）规定，CANCEL只能取消"尚未收到最终响应"的INVITE。也就是说，如果用户等了两秒没听到铃就挂机，主叫侧发的是CANCEL，被叫侧话单里会出现一条487（Request Terminated）——这不是故障，是用户行为。把487从失败统计里剔除，是做错误码看板的第一条清洗规则。

三、错误码是信令的遗言

RFC 3261给SIP响应码划了清晰的类别：1xx临时响应、2xx成功、3xx重定向、4xx客户端侧失败、5xx服务器侧失败、6xx全局性失败。对排障最有价值的是4xx里的几个高频码。下面这张表是实战速查版，含义列严格对齐RFC 3261原文，"典型根因"列是工程经验补充：

表里最值得展开的是403和404的区别。403是"我认识你，但我拒绝你"——注册或业务数据层面的问题；404是"我根本不认识这个号码"——号码分析层面的问题。NOC新同事最容易犯的错，是把404当成"用户销户了"放过去，而实际是ENUM翻译表漏了一条数据，导致一整个号段的被叫全404。两者的处理优先级完全不同：前者是单用户问题，后者是路由数据问题，扩散面差三个数量级。

另外要说明：标准允许各厂家网元在响应码的选择上有自己的实现细节（例如某些边界场景下返回480还是404），具体行为以各厂家官方文档为准。但一个网络内部的选择应该是稳定的——当你网络里某个错误码的占比突然漂移，那就是网络在说话，这也是第七节分布看板方法的理论基础。

四、案例复盘一：486与一个消失的呼转

现象：用户A投诉，同事打他电话直接听到忙音，但他手机明明闲着，也没在通话。投诉集中在最近两天，此前正常。

排查过程：先取主叫侧话单，发现呼叫的最终响应是486，且话单里带着完整的History-Info头（该头由RFC 4244定义，记录呼叫的转接历史，相当于呼转链的行车记录仪）。History-Info显示：INVITE在TAS被触发了一次无条件呼叫前转（CFU），转接目标是另一个号码B，号码B返回了486。

打电话问用户，用户一脸茫然：从来没设置过什么呼转。再查TAS业务数据，真相浮出水面：该号码半个月前做过一次换套餐操作，开通流程里补无业务数据被重置，CFU被默认指向一个预置的旧号码——而这个号码早已销户。销户号码所在的网元对陌生呼叫返回486，主叫听到的就是"忙音"。

时间线还原：

经验教训：这类问题的本质是业务层数据问题伪装成网络故障。三个要点值得固化到排障手册：

1. 看到486先别信"用户真忙"，History-Info里有几段转接记录，就把呼转链剥几层；
2. 用户"我没设置过"的证词经常是对的——问题出在开通/变更流程对补无业务数据的批量重置，这种情况下投诉往往成批出现，单看一个号码会误判为个案；
3. 话单系统要能把History-Info字段吐出来。很多网络的话单入库时把这个字段截断了，排障时只剩一个光秃秃的486，等于行车记录仪装了没插卡。

五、案例复盘二：480与寻呼黑洞

现象：某片区投诉"别人打我电话，对方听到的不是关机提示音，而是几秒后直接挂断"，用户坚称自己手机满格、开机、没骚扰拦截。

排查过程：480的含义是"被叫暂时不可用"。第一反应是用户确实不在网（关机、脱网），但用户不认账。于是换个视角：不看单个号码，把近一周被叫失败的CDR按错误码×跟踪区（TA）两个维度聚类。结果非常刺眼：全网480占比平稳，但其中一个TA的480占比是邻近TA的六倍。

这就不是用户问题了，是网络喊不应这台手机。顺着这条线到无线侧查：该TA正处于两个基站的覆盖交界，被叫UE大部分时间处于ECM-IDLE态，EPC发起寻呼后，UE在TA边界的两个小区之间来回重选，寻呼响应率明显低于全网均值。UE没收到寻呼，IMS侧等不到任何响应，S-CSCF按规范回480。用户没说谎，网络也没报障——是寻呼环节在无声地丢呼叫。

这里有个容易被忽略的协议细节：IMS侧的等待是有限的。RFC 3261规定INVITE事务的超时Timer B为64×T1（T1默认500毫秒，即32秒量级），而EPC寻呼有自己的重发窗口（TS 24.301定义的T3413定时器，典型配置数秒量级，各网自定义）。两边时间预算一旦错配——寻呼窗口太长、IMS等不及先超时，或者反过来——都会造成"其实能通，但每次都死在中间"的怪象。这个TA的问题正是边界重选拉长了响应时间，叠加寻呼重发次数配置保守，最终在预算内喊不应人。

处置与效果：调整该区域TA边界与小区重选参数，同时将寻呼重发策略与IMS侧超时预算对齐复核。次周该TA的480占比回落到全网基线水平，投诉清零。

经验教训：

1. 480 ≠ 用户关机。它是"网络在寻呼窗口内没有得到被叫任何回应"的记录，覆盖问题、边界重选、寻呼容量、终端异常都可能产出480；
2. 单用户视角看不出模式，错误码×TA（或×基站簇）的二维聚类才是正确打开方式。这也是移动网络排障区别于IT运维的要点：故障空间天然带地理维度；
3. 对"用户坚称手机正常"的投诉要保留敬意——本次案例里用户描述完全准确，傲慢地归因于"用户不会用"会让你错过真正的根因。

六、案例复盘三：408与被吃掉的时间预算

现象：某日午后，某省分被叫失败率爬升，错误码以408为主。网元监控全部正常，无告警、无重启、CPU平稳。

排查过程：408是超时响应——发出请求的一方，在定时器烧完之前没等到任何回应。它和480的区别很关键：480是"对端明确告诉你人不在"，408是"根本没人理你"。前者是业务结果，后者是链路或网元失联的前兆。

拉出当天主叫S-CSCF到TAS之间ISC接口的时延分布：P50正常，P99从平时的两百毫秒涨到八秒。也就是说，绝大多数请求还走得动，但尾部时延爆炸。这批尾部请求撞上了上游的定时器，被判408释放。TAS侧再查：当天午后有一批批量业务数据同步任务撞期，TAS的数据库连接池被占满，请求在队列里排队——网元没挂，只是变慢了，而"变慢"在SIP世界里和"死了"是同一种死法。

这个案例的深层教训：一次被叫呼叫的端到端振铃时延是有预算的，每一跳都会从中扣钱。粗略的量级感如下（典型值，随网络设计差异很大）：

任何一跳"慢了几秒"，都不会触发网元告警，但会在用户体验侧表现为"打不通"。失败率和时延必须一起看：只看成功率，这次故障前半小时其实已经有P99抬升的信号；只看时延，又定位不到用户感知。两条曲线交叉的地方，就是故障的预告片。

七、两件实战工具：分布看板与时延预算

三个案例讲完，把方法沉淀成两件可以落地的东西。

第一件：错误码分布看板。不看个案看分布，维度至少三个：错误码类型、时间、地理/网元聚类。健康网络的错误码分布是稳定的（比如480:40:486保持某个固定比例），运维要盯的不是绝对值，而是分布漂移：

• 486占比突增 → 大概率是业务数据批量异动（呼转、补无），去查开通工单；
• 480集中出现在特定TA → 覆盖/边界/寻呼问题，转无线侧；
• 408抬头 → 网元或链路在变慢，故障前兆，优先级最高；
• 404成片出现 → 路由数据或号码翻译事故，立即核对变更记录。

看板清洗规则两条：487按用户主动挂机剔除；被判为用户行为（真关机、真拒接）的长尾样本单独归档，不污染故障视图。

第二件：振铃时延预算表。把第二节那条信令路径的每一跳，标上本网络实测的P50/P99耗时，做成基线。排障时不是问"通不通"，而是问"每一跳花了多久、和基线比漂了多少"。408和一部分480的根因，最终都会落在某一张时延分布图上。

排障时用Wireshark看信令，两个过滤语句用得最多：按错误码捞样本（sip.Status-Code == 480，字段定义见 Wireshark SIP过滤参考），按呼叫串联全程（sip.Call-ID contains "xxx"）。把同一Call-ID在Gm、Mw、ISC多个接口点的消息按时间排齐，一通电话的"病历"就齐了。

最后补一张排障决策树，把三个案例的路径画成图，新同事照着走：

flowchart TD
    E["话单出现被叫失败码"] --> Q1{"错误码是哪种"}
    Q1 -->|"486或3xx"| C1["查TAS呼转数据"]
    Q1 -->|"480"| C2["查寻呼响应率"]
    Q1 -->|"408"| C3["查各跳时延分布"]
    Q1 -->|"404"| C4["查号码翻译路由"]
    C1 --> R1["读History-Info剥转接链"]
    C2 --> R2["做TA级480占比聚类"]
    C3 --> R3["对比时延基线找漂移跳"]
    C4 --> R4["核对变更与ENUM记录"]

八、写在最后：先查业务，再查网络

VoLTE运维十年，我最大的感受是：被叫故障十有八九不在"网络连接"上，而在"业务数据"和"时间预算"上。呼转数据错一个字符，网络健健康康，用户就是打不通；寻呼窗口和IMS定时器差几秒，每次呼叫都精准死在中间。

3GPP TS 24.229和RFC 3261把每条响应码的定义写得明明白白，但把错误码翻译成"下一步查哪"的映射表，规范里没有，只能从一次次深夜工单里攒。攒下来之后你会发现，IMS排障并不玄——它只是一门关于证据链的手艺：话单告诉你结果，History-Info告诉你业务层发生了什么，信令告诉你网络层发生了什么，时延告诉你性能层发生了什么。四层证据对齐，真相只有一个。

下次再收到"打不通"的投诉，别急着重启网元。先把那个错误码请出来，问它三句话：你从哪来（产生者）、你想说什么（RFC定义）、你还有多少同类（分布统计）。遗言读懂了，案子就破了一半。

参考来源

1. RFC 3261: SIP: Session Initiation Protocol — SIP协议原文，错误码定义、Timer B等定时器取值的权威出处
2. 3GPP TS 24.229 — IMS呼叫控制规范，iFC触发与SIP流程的标准依据，本文解读主轴
3. 3GPP TS 23.228 — IMS体系架构规范，P-CSCF/S-CSCF/TAS功能定位
4. 3GPP TS 24.301 — EPC NAS协议，寻呼流程与T3413定时器定义
5. Wireshark SIP Display Filter Reference — SIP字段过滤语法参考，信令分析实操工具

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