你按下拨号键，听筒里传来“嘟——嘟——”的回铃音，对方接听，通话开始。这中间只隔了两三秒，但这短短几秒里，网络完成了一场横跨两个省份、四个网元、两套协议的精密协作。
先划清一条界线：手机开机后向网络“报到”，告诉网络“我在哪、能被找到”，那叫注册——那是入场签到。而今天要讲的，是签到之后的事：当你真的拨出一通电话，网络如何把两台相隔千里的手机，用一条有质量保证的话路缝起来。这是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里其实是两条完全分离的轨道：
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。信令管接通，媒体管说话，各走各的。
为什么要分开？想象婚礼策划：司仪（信令）负责流程、确认宾客到场、宣布开始，但宴席本身（媒体）是厨房和餐桌的事。司仪不需要站在每桌旁边传菜。分离带来的好处是：控制逻辑集中升级（比如加个彩铃业务只动信令侧），媒体路径永远走最短的路。
流程的主角是四类SIP消息，先认识一下：
| 消息 | 名字的含义 | 在通话里的角色 |
|---|---|---|
| INVITE | 邀请 | “我想和你通话”——拨号动作本身 |
| 183 Session Progress | 会话进展 | “收到，这是我的媒体参数”——协商开始 |
| PRACK / UPDATE | 临时确认 / 更新 | “我这边车道修好了”/“我也是”——资源确认 |
| 180 Ringing | 振铃 | “电话在响了”——你听到的回铃音 |
| 200 OK | 最终应答 | “接了”——通话正式建立 |
直觉的流程是：发INVITE → 对方振铃 → 接听。早期纯软件的VoIP确实这么干，但在移动网络里这样设计会出事故。
原因在于移动网络的一个现实：给手机建一条专用承载（订包间）需要时间——核心网要和基站协商、基站要给手机调度无线资源，这需要几百毫秒甚至更久。如果INVITE一到就振铃，会出现这样的尴尬：
被叫听到铃声，赶紧接起来——“喂？喂？”——结果专用承载还没修完，话音包根本过不去。用户听到了一通哑巴电话。
这就是VoLTE通话设计中最精巧的机制——媒体前置条件（precondition）要解决的问题。它的核心思想一句话就能说清：
振铃前移是事故之源。先把两边的车道都修好、验收完，再让电话响。
整个协商被拆成三个阶段：
flowchart TD
A["阶段一 协商<br/>INVITE与183交换SDP"] --> B["阶段二 预留<br/>两端同步建专用承载"]
B --> C{"两边资源<br/>都就绪了吗"}
C -->|"还没好"| B
C -->|"都好了"| D["阶段三 确认<br/>UPDATE互相通报"]
D --> E["网络放行 180振铃"]
上半场：从拨号到资源预留开始。
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的确认）
下半场：从资源确认到接听。
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要消灭的体验。
到了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确认，随后专用承载被拆除、资源释放。和建立过程对称——来时怎么修路，走时就怎么拆路，一条都不留。
本文由「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 等场景全覆盖。