按下拨号键，手机屏幕显示"正在呼叫"，大约一两秒后，你听见了"嘟——"。
这一两秒，是移动通信网络里最密集的一次信令合作。你的手机、两边的基站、核心网、IMS服务器要在这么短的时间里完成三件事：找到对方、谈妥条件、铺好专线。任何一件没做完，那个"嘟"声就不会响——网络宁可让你多等，也不让你在一条泥路上开始通话。
这篇文章就讲这一两秒里发生了什么。IMS注册（开机后那次"入会"）已经完成、信令通道已经就绪，这些是本文的起点，不再展开。我们从你按下拨号键的那一刻讲起。
先用一个类比定调。用微信打网络电话，本质上是两个App在公网上互相喊话：能连上就说，连不上就卡——这是"尽力而为"（best effort）。而运营商的VoLTE/VoNR通话更像一场正式会晤：
普通VoIP把三步压缩成一步，快，但质量随缘；蜂窝语音把三步走扎实，慢一两秒，换来的是接通瞬间就有保证的带宽。这个取舍是理解整篇文章的钥匙。
flowchart TD
A[按下拨号键] --> B[阶段一：找到对方]
B --> C[号码翻译成SIP地址]
C --> D[INVITE经IMS转发]
D --> E[阶段二：谈条件]
E --> F[菜单来回：编解码与端口]
F --> G[阶段三：双向铺路]
G --> H[主叫侧建专用承载]
G --> I[被叫侧建专用承载]
H --> J[双方资源就绪]
I --> J
J --> K[180到主叫：嘟]
K --> L[被叫接听：200 OK]
你按下拨号键后，手机发出的第一条关键消息叫 INVITE。它要解决的问题是：把一个人类习惯的电话号码，变成网络能路由的地址。
号码 139xxxxxxxx 会被写进INVITE的请求行，变成一个SIP地址（形如 sip:[email protected] 的结构）。这个地址里带着运营商的移动国家码和移动网络码，IMS网络里的查询节点据此找到"管理这个号码的注册服务器在哪"，然后像接力一样把INVITE一级级转发：从主叫的接入节点（P-CSCF）到主叫的归属服务器（S-CSCF），再跨网查询，落到被叫的归属服务器，最后送达被叫手机。整条路径上的每个转发节点都会在消息里留下"路过印章"（Via和Record-Route字段），响应消息沿着印章原路返回。
但INVITE真正的内容在消息体里——一段叫 SDP（会话描述协议）的文本，它是一份菜单：
curr:qos local none、des:qos mandatory sendrecv这类属性）。为什么发菜单而不是直接决定？因为主叫不知道被叫是谁、支持什么。老手机可能只听得懂AMR窄带，新手机可能 agree on EVS超宽带。所以SIP采用"提议-应答"（offer/answer）模型：主叫列出全部能力，被叫从中挑一个它能接受的，在应答里写明。抓包时你会看到INVITE的SDP里罗列着七八种编码格式，而对方回的183里只剩一种——那就是双方谈判的结果。
EVS是目前的主流选择，采样率最高到超宽带（16kHz以上），码率可从约6kbps灵活调到128kbps；AMR-WB（市场名"高清语音"）是保底选项。谈判结果直接决定了你这次通话的音质上限。
这是整个呼叫建立中最精妙、也最容易被忽略的设计：资源预留（precondition）机制。
设想一个没有资源预留的世界：主叫INVITE发出，被叫手机立刻响铃，用户按下接听——然后才开始为语音流申请无线资源。申请需要时间，于是接通瞬间的话音要么丢包、要么卡顿半秒。用户体感就是"接通了却听不清"，比打不通更糟。
VoLTE/VoNR的解法是把顺序倒过来：先把两端的专用通道全部铺好，才允许铃声响起。具体约定写在那份SDP菜单里：双方声明"我的资源预留必须完成（mandatory）"，并随时报告当前进度（curr字段：none表示还没开始，sendrecv表示上下行都就绪）。
于是呼叫流程里多出了几个"看起来多余"的消息，各有各的用处：
183 Session Progress（会话进展）——被叫对菜单的正式回答。注意它是个"临时响应"（1xx开头），按SIP的默认规则，临时响应像贴在门上的便条，不要求签收、丢了就丢了。但183里装着谈判结果，丢不得。于是引入了 PRACK：临时响应的签收回执。被叫发183后要等到主叫的PRACK，收到后才确认"他看到了"。没有PRACK，precondition流程就失去了可靠地基。
UPDATE——资源就绪通知书。183发出去后，被叫网络开始给被叫手机建专用承载；建好之后，被叫用UPDATE告诉主叫："我这边红毯铺好了。"主叫一看自己的红毯也铺好了，就回200 OK确认。双向资源全部就绪的此刻，被叫手机才开始振铃，并发出 180 Ringing。
主叫听到"嘟"的那一刻，意味着：菜单谈完了、两端的专用通道都通了。铃声不是一个邀请的开始，而是一次质量承诺的兑现。
为什么VoLTE接通普遍要一到两秒、比很多OTT通话慢？时间主要就花在这里：两条专用承载的建立各自要穿过基站、移动性管理节点、网关、策略服务器多层信令，各花几百毫秒。这是用接通延迟换通话质量的刻意设计，不是网络慢。
"铺红毯"具体铺的是什么？以4G为例，是一条 QCI=1的专用承载（5G里对应5QI=1的QoS流）。
回顾一下这部手机已有的通道：开机附着时建了上网用的默认承载（QCI=9），注册IMS时又建了一条信令承载（QCI=5），SIP消息走的就是它。但语音包不能挤在信令通道里——它需要保证比特速率（GBR）：网络承诺这条通道的带宽，即使小区再拥挤也要优先保障；无线层用不重传模式（丢一个语音包不补发，重传就超时了，宁可丢也不迟）；再配上头压缩，把IP/UDP/RTP那几十字节的协议头压到几字节。
这条承载不是主叫手机自己能开的，流程是由网络侧驱动：
sequenceDiagram
participant G as 网关PGW
participant M as MME
participant E as 基站
participant U as 主叫UE
G->>M: 创建专用承载请求
M->>E: 承载建立指令
E->>U: RRC重配置加无线专线
U-->>E: 重配置完成
E-->>M: 承载建立完成
M-->>G: 反馈结果
Note over U,G: QCI1通道就绪
有趣的是"怎么知道哪些包该走这条通道"。答案写在承载参数里的业务流模板（TFT）上，它像一张车牌白名单：本地端口对远端端口、协议为UDP——只有INVITE菜单里约定好的那对端口之间的RTP流，才被放行进入VIP通道；你通话时顺手刷的网页，依然走普通承载，互不干扰。真实抓包里能看到TFT精确到"本地端口50010、远端端口60000、协议UDP"这样的细节。
还有一个容易误解的点：SIP信令和语音媒体走的是两条完全不同的通道。信令走QCI=5（非保证速率），媒体走QCI=1（保证速率）。调信令问题时抓QCI=5的包，看话音断续时看QCI=1的指标，混在一起看只会越看越糊涂。
把前面三步拼起来，就是一次完整的VoLTE呼叫建立（两侧各4个参与方，拆成两张图看）。
先看端到端的SIP信令主线：
sequenceDiagram
participant A as 主叫UE
participant P as P-CSCF
participant S as S-CSCF
participant B as 被叫UE
A->>P: INVITE 附菜单
P->>S: 转发
S->>B: 转发
B-->>P: 183 选定编码
P-->>A: 183 要求签收
A->>B: PRACK 签收回执
B-->>A: 200 OK for PRACK
Note over B: 被叫侧建专用承载
B->>A: UPDATE 资源就绪
A-->>B: 200 OK for UPDATE
Note over A: 主叫侧承载也就绪
B->>A: 180 Ringing 振铃
A->>P: ACK
再看与此并行发生的承载建立（两侧各一次，只画主叫侧）：
sequenceDiagram
participant C as P-CSCF
participant G as 网关
participant M as MME
participant U as 主叫UE
C->>G: 通告媒体参数
G->>M: 发起专载建立
M->>U: 激活专用承载
U-->>M: 承载激活接受
M-->>G: 完成上报
G-->>C: 资源就绪
Note over G,U: 通道与TFT绑定生效
两张图在时间上是咬合的：SIP信令跑到183之后，承载建立开始；承载建好，UPDATE才会出现。调试时如果发现183之后长时间没有UPDATE，八成是被叫侧承载建立环节出了问题——无线资源不足、专载被拒绝，都会卡在这里。
铃声响起之后的最后一步反而简单：被叫按下接听，发送 200 OK（对INVITE的最终回答），主叫回 ACK，RTP语音包双向奔流，通话开始。
SIP为什么对别的消息都用"请求-响应"就够，唯独给INVITE配了个专门的ACK？因为200 OK的送达路径允许与请求路径不同，SIP把INVITE设计成唯一需要"三次握手"的请求——邀请、接受、握手落定。实战里的经典故障正是ACK丢了：被叫收不到ACK会反复重发200 OK，表现为"接听后两三秒自动挂断"，抓包一看满屏重传的200 OK，问题就清楚了。
到了5G独立组网，语音搬进VoNR，IMS那套SIP流程原封不动——还是INVITE、183、PRACK、UPDATE、180、200、ACK。变的全是承载层的名字和形态：
| 维度 | 2G/3G电路语音 | VoLTE（4G） | VoNR（5G） |
|---|---|---|---|
| 承载形态 | 独占电路时隙 | QCI=1专用承载 | 5QI=1 QoS流 |
| 信令通道 | 七号信令 | QCI=5默认承载 | 5QI=5 QoS流 |
| 承载建立方式 | 呼叫时占用时隙 | 激活专用承载流程 | PDU会话修改流程 |
| 资源预留机制 | 电路天然独占 | precondition | precondition（沿用） |
| 5G部署早期的兜底 | — | 不需要 | EPS Fallback回落到VoLTE |
| 核心网角色 | MSC交换机 | EPC+IMS | 5GC+IMS |
两点值得展开。
其一，5G里建语音通道的方式从"新建一条承载"变成了"修改既有会话"。4G的承载体系里，专载是一条独立的新管道；5G的QoS体系里，同一PDU会话内加一条5QI=1的QoS流即可，网络向手机下发"会话修改命令"，手机确认后这条流生效。思想没变——还是那条只放行语音RTP流的保证速率通道——但管子的粒度更细了。
其二，EPS Fallback是VoNR成熟前的过渡拐杖。5G网络初期若不具备VoNR能力，用户发起通话时网络直接把手机"推"回4G，用VoLTE完成这次通话。这对信令调试意味着另一种节奏：不是"一条呼叫流程走完"，而是"一次切换/重定向+一条新的呼叫流程"。判断现网语音走的哪条路，是5G语音优化的第一课。
把一次呼叫从按下拨号键到铃声响起的时间拆开看：
$$T_{接通} = T_{无线接入} + N_{往返} \times T_{SIP} + T_{承载建立}$$
其中：
这个拆解直接对应排查思路：接通慢，先定位慢在哪一段。无线接入慢看RRC建立指标；SIP往返慢看转发链路上各节点的时间戳；承载建立慢就查专载建立时延统计。笼统地说"网络卡"，不如算清这笔账。
响铃慢或长时间只有"正在呼叫"：大概率卡在precondition阶段。看SIP抓包，若183之后迟迟没有UPDATE，去被叫侧查专用承载建立记录；若承载建立被拒绝，常见原因是无线资源不足或策略用户数据（签约里是否允许GBR业务）有问题。
响铃了但一接听就掉话：铃声能响说明双向资源曾就绪，接听瞬间掉线常见于承载被抢占或丢失——比如通话刚建立时无线环境骤变，专载重建失败。这种情况SIP层一切正常，问题在承载层。
接听后自动挂断：优先怀疑200 OK与ACK的握手问题，抓包看重传。这类问题还常与跨运营商互通的边界设备有关。
音质差但接通很快：注意一个反直觉现象——如果某些终端或网络配置跳过了资源预留（协议允许，标准允许多种实现，具体以各厂家官方文档为准），接通会明显变快，但接通瞬间的服务质量失去了保证。所以"接通特别快"未必是好事，先确认precondition是否真的执行了。
最后澄清一个常见误解："VoLTE打电话不走流量套餐"和"VoLTE走专用网络"是两回事。VoLTE的话音确实以IP数据包的形式在LTE/5G网络上传输，与上网数据物理同网，只是逻辑上被专用承载隔离、被调度器区别对待；计费上多数运营商对话音单独计费不计入流量，那是商业模式，不是技术隔离。
Q: 180 Ringing和200 OK都是"被叫同意了"吗？ A: 不是。180的意思是"被叫手机在振铃了"——此刻专线已铺好、铃已在响，但人还没决定接；200 OK才是"被叫按了接听键"。两者之间隔着的正是整个振铃时长，期间主叫听到的嘟声或彩铃，就是180（或网络侧早媒体）触发的。
Q: PRACK和ACK都是确认，为什么要有两个？ A: 确认的对象不同。PRACK确认的是"临时响应"（比如183）——SIP默认不确认临时响应，但precondition流程里的183装着编解码谈判结果，必须可靠送达，所以要专门签收。ACK确认的是INVITE的最终响应（200 OK），是SIP为邀请类请求设计的第三步握手。一个管过程，一个管终局。
Q: 微信电话为什么接通更快，体验却时好时坏？ A: 微信电话走公共互联网，没有precondition、没有专用承载，双方一应答就直接开说——省掉了铺路时间，所以快。但带宽没有保证，网络一挤就卡顿掉包。VoLTE/VoNR用接通时的一两秒，换整个通话期间的速率保证。这是两种设计哲学：先通再抢资源，还是先铺路再通话。
Q: 彩铃是在哪一步插进来的？ A: 振铃阶段。被叫网络在180前后由媒体资源设备向主叫方向播放彩铃，术语叫"早媒体"——通话尚未建立，铃音流先行。这也解释了为什么彩铃不影响通话本身：它借用的只是振铃阶段的媒体通道，200 OK之后放的才是双方的话音。
Q: 通话中途信号变差，专用承载会怎样？ A: 承载是逻辑概念，跟着手机走。手机切换到新小区时，网络会把QCI=1承载在新小区重建，保证速率承诺继续有效——这正是"判决之后的信令接力"要干的活。如果切换后承载重建失败，语音才会真正中断。
本文由「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 等场景全覆盖。