# 从拨号到回铃：一通电话是怎么被“接通”的 你按下拨号键，听筒里传来“嘟——嘟——”的回铃音，对方接听，通话开始。这中间只隔了两三秒，但这短短几秒里，网络完成了一场横跨两个省份、四个网元、两套协议的精密协作。 先划清一条界线：手机开机后向网络“报到”，告诉网络“我在哪、能被找到”，那叫注册——那是**入场签到**。而今天要讲的，是签到之后的事：**当你真的拨出一通电话，网络如何把两台相隔千里的手机，用一条有质量保证的话路缝起来**。这是IMS网络里最精巧的一段设计，也是现网故障定位中工程师打交道最多的一段流程。 ## 一、先想明白：电话为什么不能像微信一样“发出去” 要理解通话建立的复杂度，得先理解语音业务和普通数据业务的根本区别。 你看一条微信消息，晚到半秒、丢一条重发一次，都无感。但语音是**实时的流**：两边说话必须像面对面一样连续，延迟超过两百毫秒人耳就能察觉“不对劲”，丢包率超过百分之一声音就开始破碎。更重要的是，语音永远在“在线”——这条流从接通到挂断，每一秒都要有资源伺候。 2G时代的人们用了一个简单粗暴的办法：**电路交换**。通话前，网络从你到对方沿路“划”出一条独占的线路，时隙、信道全部预留，全程只有你用。像在餐厅订了个包间，哪怕你不说话，这个包间也空着等——贵，但绝对稳。 4G来了，整个网络只剩一张IP网，语音必须变成IP包来传。问题来了：IP网络的天性是**尽力而为**——大家抢公共车道，谁快谁先过。微信消息抢车道无所谓，语音抢不过别人，通话就毁了。 所以工程师的设计思路是：**让语音在IP网络里，重新“订”到一个包间**。这就是通话建立流程要解决的核心问题——不只是“通知对方来接电话”，而是**在双方手机和基站之间，各修出一条有质量保证的专用车道，修好了才让你听到铃声**。 ## 二、演进全景：一通电话的五种接法 | 代际 | 通话方案 | 话路的本质 | 接通体验 | 语音带宽 | |------|---------|-----------|---------|---------| | 2G | 电路交换 | 端到端独占的时隙专线 | 先占资源再振铃，数秒 | 3.1kHz窄带 | | 3G | 电路交换为主 | 独占专用信道 | 数秒 | 窄带起步，后期有宽带 | | 4G初期 | 电路域回落（CSFB） | 打电话先“退回”2G/3G旧网 | 多花几秒回落时间 | 窄带为主 | | 4G成熟期 | VoLTE | 专用承载上的IP语音包 | 两秒内，边上网边通话 | 宽带（AMR-WB起步，可升EVS） | | 5G | VoNR | 5G专用承载上的IP语音包 | 与VoLTE同量级 | 同上，演进平滑 | 看这张表有个关键洞察：**从VoLTE开始，接通反而变快了**。直觉上“修专用车道”应该更慢，为什么更快？因为电路交换时代，占资源发生在振铃**之前**——网络先把整条电路钉死，才让手机响。而VoLTE把“通知对方”和“修车道”两件事**并行**了：信令一边往对方跑，承载一边同步在修，谁也不等谁。这个并行设计，正是后面流程图里最精彩的伏笔。 ## 三、双轨制：信令走一条路，语音走另一条路 VoLTE基于IMS（IP多媒体子系统）架构。理解通话建立前，先建立一张地图——一通电话在IMS里其实是**两条完全分离的轨道**： ```mermaid flowchart TD UE1["主叫手机"] -->|"SIP信令"| PC1["P-CSCF 主叫门户"] PC1 -->|"SIP信令"| SC1["S-CSCF 主叫大脑"] SC1 -->|"查号码路由"| EN["ENUM 网络地址簿"] SC1 -->|"SIP信令"| SC2["被叫侧IMS核心"] SC2 -->|"SIP信令"| PC2["被叫侧P-CSCF"] PC2 -->|"SIP信令"| UE2["被叫手机"] UE1 -.->|"RTP语音流"| NET["IP承载网"] NET -.->|"RTP语音流"| UE2 ``` 上半部分是**信令轨道**：跑的是SIP协议（会话初始协议），负责“商量”——你是谁、找谁、用什么编码、资源好了没。主叫手机先到自己网络的P-CSCF（第一门户，负责安全与检查），再到S-CSCF（会话大脑，负责路由和触发业务）。S-CSCF拿到一个手机号码后，不是直接发，而是先查**ENUM**——一个把电话号码翻译成SIP地址的分布式“网络地址簿”，翻译完才能在IP世界里路由。如果对方是固话或老网络用户，还会经过媒体网关（MGCF/MGW）做SIP与旧信令、IP语音与传统PCM语音的转换——这就是为什么你的5G手机能打给路边一张座机。 下半部分是**媒体轨道**：真正的话音以RTP包的形式，直接在两台手机之间经IP承载网流动，**不经过任何CSCF**。信令管接通，媒体管说话，各走各的。 为什么要分开？想象婚礼策划：司仪（信令）负责流程、确认宾客到场、宣布开始，但宴席本身（媒体）是厨房和餐桌的事。司仪不需要站在每桌旁边传菜。分离带来的好处是：控制逻辑集中升级（比如加个彩铃业务只动信令侧），媒体路径永远走最短的路。 ## 四、核心难题：为什么不能INVITE一发就振铃 流程的主角是四类SIP消息，先认识一下： | 消息 | 名字的含义 | 在通话里的角色 | |------|-----------|---------------| | INVITE | 邀请 | “我想和你通话”——拨号动作本身 | | 183 Session Progress | 会话进展 | “收到，这是我的媒体参数”——协商开始 | | PRACK / UPDATE | 临时确认 / 更新 | “我这边车道修好了”/“我也是”——资源确认 | | 180 Ringing | 振铃 | “电话在响了”——你听到的回铃音 | | 200 OK | 最终应答 | “接了”——通话正式建立 | 直觉的流程是：发INVITE → 对方振铃 → 接听。**早期纯软件的VoIP确实这么干，但在移动网络里这样设计会出事故**。 原因在于移动网络的一个现实：给手机建一条专用承载（订包间）需要时间——核心网要和基站协商、基站要给手机调度无线资源，这需要几百毫秒甚至更久。如果INVITE一到就振铃，会出现这样的尴尬： > 被叫听到铃声，赶紧接起来——“喂？喂？”——结果专用承载还没修完，话音包根本过不去。**用户听到了一通哑巴电话**。 这就是VoLTE通话设计中最精巧的机制——**媒体前置条件（precondition）**要解决的问题。它的核心思想一句话就能说清： > **振铃前移是事故之源。先把两边的车道都修好、验收完，再让电话响。** 整个协商被拆成三个阶段： ```mermaid flowchart TD A["阶段一 协商
INVITE与183交换SDP"] --> B["阶段二 预留
两端同步建专用承载"] B --> C{"两边资源
都就绪了吗"} C -->|"还没好"| B C -->|"都好了"| D["阶段三 确认
UPDATE互相通报"] D --> E["网络放行 180振铃"] ``` - **阶段一·协商**：INVITE里夹着一份SDP（会话描述协议）——“我会说话，支持这些编码，用这个地址收包”。对方回183，附上自己的SDP应答。两边对齐：用AMR-WB还是EVS编码、RTP包发到哪个IP和端口。**此时谁都没动资源，只是对清单**。 - **阶段二·预留**：协商一致后，网络在两端同时开工修承载。主叫侧和被叫侧**并行**进行——这就是VoLTE接通快的根本原因，修路不串行。 - **阶段三·确认**：任何一端修好了，就发UPDATE告诉对方“我ready了”。**两边都ready**，条件才算满足，网络才放行180振铃。 ## 五、完整时序：一通电话的上下半场 上半场：从拨号到资源预留开始。 ```mermaid sequenceDiagram participant A as 主叫手机 participant X as 主叫侧IMS participant Y as 被叫侧IMS participant B as 被叫手机 A->>X: INVITE 拨号（附SDP媒体提案） X->>X: 查ENUM 触发主叫侧业务 X->>Y: 转发INVITE Y->>B: 转发INVITE B-->>Y: 183 会话进展（附SDP应答） Y-->>X: 183 X-->>A: 183 Note over A: 主叫侧开始建专用承载 Note over B: 被叫侧同步建专用承载 A->>X: PRACK 确认收到183 X->>Y: PRACK Y->>B: PRACK B-->>A: 200 OK（对PRACK的确认） ``` 下半场：从资源确认到接听。 ```mermaid sequenceDiagram participant A as 主叫手机 participant X as 主叫侧IMS participant Y as 被叫侧IMS participant B as 被叫手机 A->>X: UPDATE 主叫资源就绪 X->>Y: UPDATE Y->>B: UPDATE B-->>A: 200 OK（确认资源状态） Note over B: 双方资源齐备，此刻才振铃 B-->>A: 180 Ringing（回铃音来了） Note over A,B: 被叫按下接听键 B-->>A: 200 OK（INVITE的最终应答） A->>B: ACK（通话正式生效） ``` （图中省略了IMS核心逐跳转发的中间箭头；实际上180和200 OK仍沿信令轨道经两侧核心网转发。） 细品几个设计细节，全是“为什么”： **为什么183之后要PRACK？** SIP的临时应答（1xx类）默认不可靠，可能丢。183里带着关键的媒体参数，丢了整个协商就卡死，所以必须用PRACK（PReliminary ACK）补一次“确认收到”的握手。信令世界里的原则：**重要的消息，必须有回执**。 **为什么振铃前的确认用UPDATE而不是再发一次INVITE？** INVITE会开启一个新的协商轮次，动静大；UPDATE是对现有会话的轻量修改，只更新资源状态。资源确认本质上是“改个状态字段”，不值得重开一轮谈判。 **为什么200 OK还要再发ACK？** 200 OK是对整个INVITE的最终应答，这是SIP里最重量级的一步。三次握手（INVITE → 200 OK → ACK）确保双方对“通话开始”这件事**确凿无疑地达成一致**——和TCP握手是同一个哲学。 **回铃音从哪来？** 180 Ringing是信令层的“对方在响”的通知，而你耳朵里听到的“嘟——”声，是网络侧媒体资源（彩铃平台或媒体服务器）播放的音频流，走的是媒体轨道。所以彩铃能 personalized——放什么声音是业务层的自由，与振铃信令无关。 ## 六、车道的规格：专用承载从哪来 三个阶段里的“建承载”，值得单独说透。手机开机时只有一条**默认承载**——公共车道，尽力而为。通话建立时，IMS通过策略控制链路通知核心网，为这条话音流**新建一条专用承载**。三种承载的规格差异巨大： | 承载 | 跑什么 | 保不保速率 | 时延预算 | 丢包预算 | |------|--------|-----------|---------|---------| | 默认承载 | 微信、网页、视频 | 不保，尽力而为 | 约300ms | 百万分之一 | | IMS信令承载（QCI 5） | SIP注册与呼叫信令 | 不保，但高优先调度 | 约100ms | 百万分之一 | | 语音专用承载（QCI 1 / 5QI 1） | RTP语音包 | **保速率（GBR）** | 约100ms | 约百分之一 | 注意最后两列的反直觉之处：**语音承载允许的丢包率（百分之一）反而比网页（百万分之一）高一万倍**。因为语音丢一两个包，人耳靠连续性自动脑补，无感；而网页丢一个字节，整个文件校验就过不去，必须重传。这不是语音要求低，是**两种业务对“错误”的定义完全不同**——这是理解QoS设计最关键的一课。 “保速率”（GBR）意味着基站必须像保证公交专用道一样，给这条承载预留实实在在的无线资源，哪怕挤占普通用户的带宽。这也解释了一个现网现象：**语音专用承载是要“准入”的**——如果小区负载太高、资源不足，网络可能拒绝建立这条承载，你的电话直接打不出去，而不是“接通了但音质差”。宁可打不通，不给你一通破电话——这是电信级语音的铁律。 这条车道的宽度是多少？算一笔账。语音编码器每20毫秒产出一个语音帧： $$\text{每秒语音包数} = \frac{1000\ \text{ms}}{20\ \text{ms}} = 50\ \text{包/秒}$$ 每个语音包套上RTP、UDP、IP三层头，共40字节开销： $$\text{头部开销} = 50 \times 40\ \text{字节} = 16\ \text{kbit/s}$$ 对于两三百比特一帧的窄带语音，头比肉还贵。所以VoLTE在空口强制启用**鲁棒头压缩**，把40字节压到几字节——这正是VoLTE比普通网络电话省流量的关键，也呼应了表中VoLTE容量数倍于3G/2G的原因之一。 ## 七、现网实战：工程师会在这里翻哪些车 **陷阱一：INVITE发出去，183一直不来。** 别盯着IMS核心查，先看**承载侧**：主叫的QCI 5信令承载通不通？被叫的寻呼发了没？被叫侧专用承载建立失败了没有（准入拒绝、无线资源不足）？183是资源协商的起点，它缺席意味着流程根本没走到协商那步。 **陷阱二：180来了，接通后单通或无声。** 典型的**precondition被跳过或媒体参数不匹配**。两头SDP里声明的编码集合没有交集（比如一边只会EVS、另一边只肯AMR-NB），会话虽建立却发不出彼此能解码的包。抓包看INVITE与183里的SDP编码列表，十有八九在这。 **陷阱三：测试正常，商用放号后有人打不通。** 检查ENUM解析。号码翻译配置漏了一段号段，INVITE就在网络里“迷路”。这类问题在补齐号码分析数据后瞬间消失，但排查时极难联想到——因为信令跟踪里看起来一切“正常”，只是没路可走。 **陷阱四：主叫听回铃音极慢或没有。** 现网里最容易被忽略的是**被叫侧资源预留超时**。precondition要求两边都ready才振铃，被叫在弱覆盖下建承载慢，主叫就干等。所以听回铃音的快慢，实际上是被叫无线环境的“体温计”——这是老工程师不抓包也能做的现场诊断。 **一个常见的误解**：很多人以为VoLTE打电话时手机“切到了语音模式”，数据就断了。恰好相反——语音和数据在同一张LTE网上，靠两条不同的承载并行跑。你边打电话边发微信毫无障碍。真正“打电话断网”的是CSFB时代的事，那正是VoLTE要消灭的体验。 ## 八、VoNR：换了跑道，没换剧本 到了5G，语音可以直接驻留NR小区走VoNR，不必回落。但看流程你会发现：**IMS侧的呼叫建立流程几乎原封不动**——还是INVITE、183、precondition、UPDATE、180、200 OK。变的只是承载那一环：QCI 1换成了5G的5QI 1，策略协商的对象从4G核心换成了5G核心。 这正体现了分层设计的威力：**接入网怎么换代，是“车道”的事；“订包间的流程”属于IMS**，一套会话逻辑同时服务4G和5G。对IMS工程师来说，从VoLTE到VoNR几乎是零成本迁移——当年把信令和媒体分离、把会话控制和承载控制分离的决策，在这里收到了全部红利。 ## 常见问题 **Q: VoLTE通话和微信语音，底层不都是IP包吗，区别到底在哪？** A: 包格式相似，待遇天差地别。微信语音走的是默认承载，尽力而为，拥挤时你的语音和图片抢同一条车道；VoLTE走GBR专用承载，基站为其预留资源，时延和丢包有硬性预算。另外VoLTE经ENUM和媒体网关能接通固话、跨运营商老网络，微信语音只能在App内闭环。一句话：微信语音是“寄快递”，VoLTE是“修了一条随时可用的专线”。 **Q: 为什么有时拨号后要等好几秒才听到回铃音，有时立刻就响？** A: 回铃音出现在“双方资源预留完成”之后。被叫手机无线环境好，承载几百毫秒就建好，铃音来得快；被叫在弱覆盖、或在频繁切换中，资源预留反复重试，主叫就得等。所以回铃音延迟九成是被叫侧无线条件的问题，与主叫无关。 **Q: 486 Busy和488 Not Acceptable Here这些错误码，现场怎么用？** A: 486是被叫用户主动拒绝或占线，属于“业务层正常拒绝”，不用查网络；488多出现在媒体协商失败——SDP里编码、带宽参数对不上，重点查两端终端能力配置；而INVITE后连100 Trying都没有，是信令承载或路由问题。错误码是免费的问题定位器，位置对了能省半小时抓包。 **Q: VoNR和VoLTE的通话流程有本质区别吗？** A: IMS会话层完全一致，区别只在承载：QCI 1换成5QI 1，策略控制在5G核心网完成。对调试者来说，掌握一套VoLTE呼叫流程分析，5G语音问题照样通吃。 **Q: 打电话时对方挂断，信令上是什么样的？** A: 对方挂机，其终端沿信令轨道发BYE消息，你这边回200 OK确认，随后专用承载被拆除、资源释放。和建立过程对称——来时怎么修路，走时就怎么拆路，一条都不留。 ## 参考来源 1. [Voice over LTE - Wikipedia](https://en.wikipedia.org/wiki/Voice_over_LTE) — VoLTE的IMS架构基础、GSMA行业档案、QCI机制、编解码与容量的权威概述 2. [IP Multimedia Subsystem - Wikipedia](https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem) — IMS各网元（P-CSCF/S-CSCF/ENUM路由/MGCF媒体网关）职责与SIP信令框架 3. GSMA IR.92《IMS Profile for Voice and SMS》（GSMA官方文档） — 定义VoLTE所需的IMS最小功能集，即"精简版IMS" 4. Poikselkä 等《Voice over LTE: VoLTE》（Wiley出版） — VoLTE呼叫流程与承载建立机制的系统性教材 --- > 本文由「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 等场景全覆盖。