# 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](https://www.3gpp.org/dynareport/24229.htm)），错误码定义与定时器取值依据 IETF RFC 3261（[www.rfc-editor.org/rfc/rfc3261.txt](https://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的语音承载。 ```mermaid 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原文，"典型根因"列是工程经验补充： | 错误码 | RFC 3261含义 | 通常产生者 | 典型根因 | 排查入口 | |---|---|---|---|---| | 403 Forbidden | 服务器理解请求但拒绝执行 | 注册/业务网元 | 鉴权通过但签约不允许、IMPI/IMPU数据错 | HSS签约数据、TAS业务键 | | 404 Not Found | 服务器找不到请求的用户 | 出口网元/S-CSCF | 号码翻译错（ENUM）、号码不存在、路由数据错 | 号码分析与ENUM记录 | | 408 Request Timeout | 超时前未收到任何响应 | 代理/客户端定时器 | 下一跳网元过载、链路抖动 | 各跳时延分布 | | 480 Temporarily Unavailable | 被叫暂时不可用 | 被叫侧S-CSCF/代理 | 寻呼无响应、UE失联、TA边界问题 | 寻呼响应率、TA聚类 | | 486 Busy Here | 被叫端点忙 | 被叫UE或TAS | 真忙、呼转配置指向异常目标 | History-Info头 | | 487 Request Terminated | 请求被CANCEL终止 | 被叫侧 | 用户主动放弃（非故障） | 从统计中剔除 | | 600/603 | 全网忙/拒接 | 被叫UA | 终端应用层拒接 | 终端与补无业务数据 | 表里最值得展开的是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，主叫听到的就是"忙音"。 **时间线还原**： | 时间 | 事件 | |---|---| | D-15天 | 用户办理套餐变更，CFU数据被重置为预置旧号码 | | D-1天 | 旧号码正式销户，呼转目标失效 | | D日 | 主叫开始听到"忙音"，用户投诉 | | D+1日 | 话单History-Info定位到TAS呼转记录，业务数据修正 | **经验教训**：这类问题的本质是**业务层数据问题伪装成网络故障**。三个要点值得固化到排障手册： 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世界里和"死了"是同一种死法**。 **这个案例的深层教训**：一次被叫呼叫的端到端振铃时延是有预算的，每一跳都会从中扣钱。粗略的量级感如下（典型值，随网络设计差异很大）： | 环节 | 典型耗时量级 | 超预算的表现 | |---|---|---| | 主叫接入与iFC触发 | 数百毫秒 | 主叫侧感知接续慢 | | TAS业务判定 | 数十至数百毫秒 | 尾部请求撞上游定时器变408 | | 号码翻译与被叫域路由 | 数十毫秒 | 表现为批量404或路由失败 | | EPC寻呼+UE响应 | 数秒（含重发） | 超时后IMS侧回480 | | 被叫专用承载建立 | 数百毫秒 | 振铃后接通慢、掉话 | 任何一跳"慢了几秒"，都不会触发网元告警，但会在用户体验侧表现为"打不通"。**失败率和时延必须一起看**：只看成功率，这次故障前半小时其实已经有P99抬升的信号；只看时延，又定位不到用户感知。两条曲线交叉的地方，就是故障的预告片。 ## 七、两件实战工具：分布看板与时延预算 三个案例讲完，把方法沉淀成两件可以落地的东西。 **第一件：错误码分布看板。**不看个案看分布，维度至少三个：错误码类型、时间、地理/网元聚类。健康网络的错误码分布是稳定的（比如480:40:486保持某个固定比例），运维要盯的不是绝对值，而是**分布漂移**： - 486占比突增 → 大概率是业务数据批量异动（呼转、补无），去查开通工单； - 480集中出现在特定TA → 覆盖/边界/寻呼问题，转无线侧； - 408抬头 → 网元或链路在变慢，故障前兆，优先级最高； - 404成片出现 → 路由数据或号码翻译事故，立即核对变更记录。 看板清洗规则两条：487按用户主动挂机剔除；被判为用户行为（真关机、真拒接）的长尾样本单独归档，不污染故障视图。 **第二件：振铃时延预算表。**把第二节那条信令路径的每一跳，标上本网络实测的P50/P99耗时，做成基线。排障时不是问"通不通"，而是问"每一跳花了多久、和基线比漂了多少"。408和一部分480的根因，最终都会落在某一张时延分布图上。 排障时用Wireshark看信令，两个过滤语句用得最多：按错误码捞样本（`sip.Status-Code == 480`，字段定义见 [Wireshark SIP过滤参考](https://www.wireshark.org/docs/dfref/s/sip.html)），按呼叫串联全程（`sip.Call-ID contains "xxx"`）。把同一Call-ID在Gm、Mw、ISC多个接口点的消息按时间排齐，一通电话的"病历"就齐了。 最后补一张排障决策树，把三个案例的路径画成图，新同事照着走： ```mermaid 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](https://www.rfc-editor.org/rfc/rfc3261.txt) — SIP协议原文，错误码定义、Timer B等定时器取值的权威出处 2. [3GPP TS 24.229](https://www.3gpp.org/dynareport/24229.htm) — IMS呼叫控制规范，iFC触发与SIP流程的标准依据，本文解读主轴 3. [3GPP TS 23.228](https://www.3gpp.org/dynareport/23228.htm) — IMS体系架构规范，P-CSCF/S-CSCF/TAS功能定位 4. [3GPP TS 24.301](https://www.3gpp.org/dynareport/24301.htm) — EPC NAS协议，寻呼流程与T3413定时器定义 5. [Wireshark SIP Display Filter Reference](https://www.wireshark.org/docs/dfref/s/sip.html) — 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 等场景全覆盖。