你在手机上按下拨号键，两声“嘟——嘟——”之后对方接听。整个过程不到三秒，但在这三秒里，一个INVITE消息跑过了基站、穿越了运营商的核心网、唤醒了至少四类服务器、还顺手在你和对方之间修了一条“专线”。这篇文章就把这三秒拆开，看看一通VoLTE电话到底是怎么被“接通”的。
不聊行业新闻，不背规范条文，只回答一个问题：电话为什么非要这样设计？
先打个比方。你要约一位没见过面的客户在酒店见面，会经历两件事：
VoLTE电话也是这样拆成两件事的：
这个“信令与媒体分离”的设计，是理解VoLTE一切流程的钥匙。很多人第一次抓信令包时会困惑：“我找到了INVITE，怎么在里面找不到声音？”——因为声音根本不走这条路。
为什么非要分开？因为两者的要求完全不同：
| 维度 | SIP信令 | RTP话音 |
|---|---|---|
| 数据量 | 极小（一次呼叫几十KB） | 持续产生（通话期间每秒几十个包） |
| 时延敏感度 | 不敏感（晚半秒没人察觉） | 极敏感（晚150毫秒就难受） |
| 丢包容忍 | 不能丢（丢了流程就乱） | 可以丢一点（丢帧只是轻微沙哑） |
| 路径 | 必须经过业务服务器 | 走最短路径，能抄近道就抄近道 |
信令走得“慢而稳”是因为它要被各种业务逻辑反复检查——有没有呼叫转移、是不是黑名单、要不要放彩铃；媒体走得“快而直”是因为它只有一件事：准时送达。
下图是一通VoLTE电话的网络全景。注意看，信令路径和媒体路径是两条完全不同的路：
flowchart TD
A["主叫手机"] -->|1 SIP信令| B["无线接入网"]
B -->|2 SIP信令| C["SBC<br/>信令媒体锚点"]
C -->|3 SIP信令| D["S-CSCF<br/>呼叫控制中枢"]
D -->|4 触发业务| E["TAS<br/>电话业务服务器"]
D -->|5 SIP信令| F["被叫侧网络"]
F --> G["被叫手机"]
A -->|话音RTP| B
B -->|话音RTP| C
C -.->|话音RTP直连<br/>不进IMS核心| F
图里有几个关键角色：
注意最下面那条虚线：话音RTP包从主叫的SBC直接奔向被叫侧，不进入IMS核心网。IMS核心只负责“把电话接起来”，接起来之后就靠边站。这就是“信令绕城、媒体穿墙”——管理要层层审批，运输要直线最快。
这也解释了一个现网现象：两个城市的用户通话，信令可能在北京的IMS核心绕一圈，而话音包是从上海SBC直接打到广州SBC的。所以看媒体路径问题时，别去IMS核心网上找，去SBC上抓包。
一切的前提是你已经在IMS“注册过”——手机开机时通过一条REGISTER告诉网络“我在这个基站下，有事呼我”。注册流程本身是另一个故事（一条REGISTER如何走完鉴权和登记），这里直接跳到注册完成之后：手机手里握着一条默认承载，专门跑SIP信令。
现在用户按下拨号键。按直觉，合理顺序应该是：先把通话资源准备好，再发INVITE去找人。但VoLTE的设计偏偏反过来——INVITE先出门，资源后准备。
为什么这样设计？想象你组织一场两地的签约仪式：
VoLTE选的是方案B，这就是“前置条件（precondition）”机制的精髓：在双方资源都确认就绪之前，被叫手机不许振铃。
为什么这么执着于“就绪了才响铃”？因为电话有一个网页和微信消息都没有的铁律——响铃的那一刻，接起来就必须能说话。你接到电话，说“喂”，对方听到的却是电子音的卡顿或单通无声，这不是故障，这是事故。要让响铃即通话，就必须提前把“专座”订好。
这个“专座”就是专用承载：一次VoLTE通话会临时建立一条专门的语音承载（4G里叫QCI 1，5G里叫5QI 1），它是有保障比特率的对话级通道，网络会为它预留无线和传输资源。至于GBR资源预留的完整机制（订座、抢占、释放），之前聊QoS的文章已经拆过，这里只强调呼叫视角的一点：注册时的默认承载是“尽力而为”的普通通道，话音绝不能挤在上面——否则视频一抢带宽，你的电话就成了机器人发音。
现在把完整时序摆出来。参与者只有四个：主叫手机、SBC、IMS核心、被叫侧。
sequenceDiagram
participant U as 主叫手机
participant P as SBC
participant C as IMS核心
participant B as 被叫侧
U->>P: INVITE 携带SDP提议
P-->>U: 100 Trying 已收到
P->>C: INVITE 转发
C->>B: INVITE 去往被叫
B-->>C: 183 带回SDP应答
C-->>P: 183 转发
P-->>U: 183 转发
Note over U,P: 双方开始建立专用承载
U->>P: PRACK 确认收到183
B-->>C: UPDATE 本端资源就绪
C-->>P: UPDATE 资源确认
P-->>U: 180 被叫振铃
B-->>C: 200 OK 对方摘机
P-->>U: 200 OK
U->>P: ACK 通话开始
这张图值得反复看，因为现网排障时，80%的呼叫建立问题就藏在这十几条消息的顺序和缺失里。我们一段一段拆。
INVITE消息里塞着一份SDP（会话描述协议）提议，内容类似一份“聊天条件清单”：我想用哪种语音编码、用什么IP地址和端口收发RTP包、媒体方向先设定为“只发不收”（a=sendonly）。
注意这个细节：主叫在INVITE里还不知道对方是谁、在哪，但它已经把自家门口的收货地址写好了。这叫SDP提议/应答（offer/answer）机制——一方开条件，另一方回盘。
被叫侧回的183消息里带着SDP应答：编码就用你提的那个、我的收货地址是这个、我这边也先设为“只发不收”。到这里，双方只是交换了名片，谁的话音都还没资格流动。
183到达主叫后，真正的大戏开始：两部手机各自向无线网络申请QCI 1专用承载。这是整个流程里最耗时的一步，因为要挨个跟基站、核心网要资源，就像订座要一家一家餐厅打电话确认。
承载建好后，双方用UPDATE消息互报“我这边就绪了”。UPDATE是SIP里一个很有意思的方法：它能在不改变呼叫状态的前提下修改会话条件——呼叫还没接通，但条件可以继续谈。资源全部确认后，SDP里的媒体方向升级为“双向收发”（a=sendrecv），此刻起，话音包获得了通行证。
双方资源就绪，被叫手机这才开始振铃，同时向主叫方向回180 Ringing。主叫手机收到180，让你听到“嘟——”。
对比一下：183和180都是“临时响应”（1xx类），但含义完全不同——183的意思是“流程在推进，但别出声”；180的意思是“对方手机在响了”。响铃被刻意安排在资源确认之后，这就是前置条件设计的全部意义。
对方按下接听键，被叫侧回出200 OK（最终应答），主叫再回一个ACK确认。此后RTP话音包开始双向奔流，你们说出的第一句“喂”清晰抵达对方。
你可能已经注意到：这一路全是确认——PRACK、UPDATE、ACK，像三个不同岗位的签收员。它们不是重复设计，而是在补三块不同的可靠性短板。
SIP协议诞生时借鉴了HTTP的“请求—应答”模型，但电话和网页有个本质区别：电话是一次持续数分钟的会话，任何一步消息丢失都会造成状态错乱。于是SIP对不同消息设计了不同的补丁：
| 消息 | 谁发给谁 | 干什么 | 类比 |
|---|---|---|---|
| INVITE | 主叫→被叫 | 发起呼叫，带SDP提议 | 递上邀请函 |
| 100 Trying | 沿途服务器→上跳 | 别催，我在办 | 前台说“正在转接” |
| 183 | 被叫侧→主叫 | 回SDP应答，流程推进 | 对方秘书回话“条件收到” |
| PRACK | 收到1xx的一方 | 确认“临时响应我收到了” | 给秘书回条“知道了” |
| UPDATE | 任一侧 | 通报资源就绪，改会话条件 | “场地订好了” |
| 180 Ringing | 被叫侧→主叫 | 对方手机在响 | 前台说“他来了” |
| 200 OK | 被叫→主叫 | 摘机应答，最终确认 | 握手落座 |
| ACK | 主叫→被叫 | 确认收到200 OK | 说“幸会” |
| BYE | 任一方 | 结束通话 | 起身告辞 |
三块短板分别是：
1. 临时响应没有签收机制 → PRACK。 INVITE的最终应答（200 OK）天然有ACK兜底，但183、180这类临时响应在协议最初的版本里是“发了就算”——发出去石沉大海，主叫永远不知道对方到底收没收到资源条件。电话这种对状态极其敏感的应用受不了这种模糊，于是补了PRACK：每收到一个重要的临时响应，就显式回执一次。这就是为什么时序图里PRACK紧跟在183后面。
2. 会话条件需要“会中修改”→ UPDATE。 前置条件机制要求双方在呼叫过程中多次更新资源状态。用INVITE重新协商会改变呼叫状态（会触发新的应答流程），太重；UPDATE专门干“只改条件、不动状态”的轻活。
3. 最终应答可能丢在半路 → ACK。 INVITE与200 OK之间如果不加确认，被叫摘了机、主叫没收到200 OK，就会出现“我这边以为没接通、对方那边以为在通话”的幽灵局面对。ACK构成完整的三次握手——和TCP握手的思想同源：双方对“双方都知道”这件事达成共识。
一个常见的误解是“现在信令都跑在可靠的传输层上，这些确认是不是多余了”。不是。PRACK解决的从来不是链路层的丢包，而是业务层的确认——中间可能隔着多层服务器转发，最终应答与临时响应的处理路径不同，端到端的状态共识必须由应用层自己构建。这正是通信协议设计的一个反复出现的主题：链路可靠≠业务可靠。
“嘟——嘟——”的回铃音，你有没有想过是谁的音箱在放？
理论上有两个候选：
关键问题在于：主叫怎么知道该听谁的？如果被叫侧已经放了彩铃，主叫手机还自作聪明加一声“嘟”，两段声音就叠在一起了。于是信令里有一个专门的头部字段来声明“早期媒体的发送权归谁”，SBC和IMS核心会逐段协商这个字段。
这是现网排障的高频陷阱：用户投诉“打国际电话没有回铃音，一片寂静直到接通”，八成就是两端对早期媒体的处理策略不一致——被叫网络不回早期媒体，主叫又因为收到了某种响应而关闭了本地回铃。在SBC上查这个头部的透传情况，往往五分钟就能定位。
到了5G，语音的核心逻辑几乎原封不动，换的是承载它的那张网。对比一下：
| 维度 | VoLTE（4G） | VoNR（5G） | OTT通话（如微信语音） |
|---|---|---|---|
| 承载网络 | LTE | NR独立组网 | 任何IP网络 |
| 语音承载 | QCI 1专用承载（GBR） | 5QI 1专用承载（GBR） | 无QoS保障，尽力而为 |
| 信令路径 | 经4G核心网入IMS | 经5G核心网入IMS | 应用私有服务器 |
| 与传统电话互通 | 原生互通 | 原生互通 | 需应用方另建网关 |
| 弱覆盖兜底 | 切到2G/3G延续通话 | 回落4G用VoLTE，或切2G/3G | 直接断掉 |
| 口到耳时延 | 网络有硬指标 | 网络有硬指标 | 无保证，看运气 |
VoNR下的两点本质变化值得展开：
1. 信令的“摆渡方式”变了。 手机和IMS之间的SIP消息，在4G里由4G核心网搬运，在5G里由5G核心网搬运——IMS本身不关心下面是哪代网，这正是当初把业务层和承载层彻底解耦的红利：业务逻辑零改动，换网只换“摆渡船”。
2. 现网多了一种务实的妥协：语音回落。 因为部署VoNR要求5G网络端到端打通语音链路，不少运营商在早期选择了更省事的路线——5G手机要打电话时，先回落到4G，用成熟的VoLTE完成通话，挂机后再回5G上网。这对用户几乎无感，代价是通话瞬间多一次网络切换。所以现网排障时看到一个5G在线的用户打电话，先别急着找VoNR的信令，先确认这部手机走的是VoNR还是语音回落——这直接决定你该去5G网还是4G网抓包。
至于通话中途走进弱覆盖区怎么办？网络有一套专门的“话音连续性”机制：通话中被切出覆盖区时，IMS会把话音锚点保留，把通话递交给 legacy 网络继续说，用户侧的表现只是短暂的一声“咔”。这套机制的工程目标就是把语音中断压到几百毫秒量级（属工程经验值，具体数字以各网络实测为准）。
运营商网络对语音有一条核心考核线：口到耳单向时延。工程上常用的预算式：
$$T_{口到耳} \approx T_{采集编码} + T_{空口} + T_{传输} + T_{抖动缓冲}$$
国际电联的经验口径是：单向150毫秒以内，通话者基本无感；超过400毫秒，就会明显觉得“抢话”。每一项预算都要从别的需求嘴里抢时间。
而衡量通话质量的经典工具是E模型，它把各种损伤折算成一个质量因子：
$$R = 93.2 - I_d - I_{e,\text{eff}}$$
其中 $I_d$ 是时延类损伤，$I_{e,\text{eff}}$ 是编码与丢包类损伤。$R$ 越接近满分听感越好：工程经验上，$R$ 在90以上大约对应4.3分的主观评分（满分5分），低于70就是“能听但不痛快”。
现在回头看那一长串确认消息：INVITE先出门换来了准备时间，专用承载换来了带宽保障，PRACK和UPDATE换来了“响铃即通话”的确定性。每一处看似繁琐的设计，都是在为时延预算和质量因子赎买确定性。互联网应用的态度是“先连上再说，断了重连”；电话的态度是“宁可晚两秒响铃，绝不让你接起来听不清”。这两种哲学没有高下，但电话的哲学，全部写在这三秒钟的信令里。
把原理落到调试现场，给你六条可直接上手的经验：
标准允许各厂家在实现细节上有多种做法，具体行为以各设备厂家官方文档为准，但上面这些原理层面的判断逻辑，在任何一张网里都成立。
Q: SIP和RTP到底是什么关系？一句话说清。 A: SIP是“管接通”的信令协议，负责找人、谈条件、确认、挂断；RTP是“运声音”的媒体协议，负责把话音包准时送到。SIP接通时协商的正是RTP的收发地址和编码方式——SIP是红娘，RTP才是新郎新娘。
Q: 183和180都是振铃前的临时响应，为什么要分两个？ A: 183出现在资源协商阶段，含义是“流程推进中，请继续准备，但别出声”，并且携带SDP应答；180出现在资源全部就绪之后，含义是“对方手机正在响”。分开放是前置条件设计的直接体现——响铃必须发生在通话能力就绪之后。
Q: VoLTE的专用承载和注册时的默认承载有什么区别？ A: 默认承载随注册永久存在，是非保障类型，专门跑SIP信令；专用承载是每次通话临时建立的保障类型承载，有预留带宽和最高优先级，挂机即释放。一个像公司的共享办公位，一个是预约的会议室。
Q: 5G手机打电话一定是VoNR吗？ A: 不一定。取决于运营商是否部署了VoNR以及终端和网络的协商结果。很多现网场景下，5G手机打电话会先回落到4G用VoLTE完成，这就是语音回落方案。判断方法看信令或话单中的语音模式标识，别默认5G在线就一定走VoNR。
Q: 微信语音也走IP网，为什么运营商还要专门建VoLTE/VoNR？ A: 三个硬理由：一是QoS保障，OTT通话在弱网时直接卡顿掉线，电话有专用承载兜底；二是全球互通，任何网络的手机之间凭号码互拨，OTT只能装同一个App；三是应急呼叫等公共服务能力，电话是基础设施，必须无条件可用。
注：因写作环境限制，本次未能在线复核链接可达性；以上均为Wikipedia与RFC官方的固定规范地址，条目内容与本文所述原理一致。
本文由「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 等场景全覆盖。