VoLTE信令流程深度解析：IMS注册、呼叫、保持与二次协商实战指南

1. 项目背景与整体设计思路

VoLTE这四个字母，干通信这行的都不陌生。它本质上是把语音业务承载在LTE数据通道上，用IMS做业务控制，替代了传统电路域那套2G/3G的语音方案。我第一次接触VoLTE是在一个室内分布优化项目里，当时用户投诉"打电话断断续续、接通慢"，后台一查，SIP信令流程里REGISTER消息反复重传，问题就出在IMS注册环节。从那以后我意识到，想真正搞定VoLTE，光看KPI指标没用，必须把IMS注册/去注册、呼叫建立、呼叫保持、二次协商这几条核心信令流程吃透。

这套东西解决的核心问题是：让语音从"电路交换"平滑迁移到"分组交换"，同时保证通话质量、切换连续性和业务丰富度。适合谁来参考？我建议三类人重点看：一是无线网优工程师，日常要分析SIP/RTP抓包；二是核心网运维人员，需要排查IMS网元交互异常；三是终端侧测试人员，做VoLTE功能验证和兼容性测试。哪怕你刚入行，只要跟着流程走一遍，也能建立起完整的信令分析框架。

整体设计上，我按"注册→呼叫→保持→重协商"这条主线来拆。为什么这么排？因为注册是所有业务的前提，没有成功的IMS注册，后面呼叫根本无从谈起；呼叫流程是核心场景，涉及主被叫、资源预留、编解码协商；呼叫保持考验的是网络对媒体通道的动态控制能力；二次协商则是VoLTE区别于传统语音的关键——通话中改编码、加视频、切网络，全靠它。每个环节我都配了信令流程图解、关键参数说明和实操排查技巧，尽量做到"看完就能上手抓包分析"。

2. IMS注册与去注册流程深度拆解

2.1 注册流程的信令交互与关键参数

IMS注册说白了就是终端告诉网络："我在这个位置，我的能力是这样，请给我分配一个身份标识。"整个过程走SIP REGISTER消息，核心网元涉及P-CSCF、I-CSCF、S-CSCF和HSS。我画过无数次这个流程，最简化的路径是：UE→P-CSCF→I-CSCF→S-CSCF→HSS，然后响应原路返回。

第一次注册叫初始注册，UE发REGISTER时带Expires头域，通常设成600000秒（约7天），但实际运营商一般配得短一些，比如3600秒。为什么？因为要平衡信令负荷和注册刷新频率。如果设太长，用户状态变化了网络不知道；设太短，信令风暴扛不住。我见过某地市把Expires设成300秒，结果忙时P-CSCF CPU直接飙到80%以上。

注册过程中有几个关键参数必须盯紧：

• IMPI/IMPU：前者是私有身份，存在ISIM卡里，用于鉴权；后者是公有身份，就是你的SIP URI，比如sip:13800138000@ims.mnc001.mcc460.3gppnetwork.org。两者关系是一对多，一个IMPI可以关联多个IMPU。
• Authorization头域：携带鉴权响应，基于AKA算法。UE收到401 Unauthorized后，用RAND和AUTN算出RES，再发第二次REGISTER。这里常见问题是SQN不同步，导致MAC校验失败，终端反复注册失败。
• Contact头域：告诉网络当前UE的IP和端口，后续呼叫就按这个地址找终端。如果Contact里的IP是私网地址且NAT没做ALG，呼叫必然失败。
• Path头域：记录注册路径，确保响应能正确回给P-CSCF。多P-CSCF场景下这个特别重要。

我实测抓包时发现，一次成功的初始注册通常需要2-3秒，如果超过5秒还没完成，大概率是P-CSCF到I-CSCF的链路有问题，或者HSS响应慢。这时候先查SCTP偶联状态，再看Diameter链路。

2.2 去注册的触发条件与异常处理

去注册分两种：UE主动去注册和网络侧发起去注册。UE主动去注册一般是关机、飞行模式开启或者SIM卡拔出，发REGISTER时Expires设为0。网络侧去注册则可能是欠费、签约变更或者管理员操作。

去注册流程比注册简单，但坑不少。我遇到过最典型的问题是：UE发了去注册，但S-CSCF没删用户数据，导致下次注册时返回403 Forbidden。排查下来是HSS和S-CSCF之间的Cx接口超时，SAR消息没发出去。解决办法是等HSS的Purge定时器超时，或者手动在S-CSCF上清用户数据。

另一个常见异常是"注册状态不一致"：UE认为注册成功了，但网络侧已经去注册。这种多半是UE没收到200 OK响应，但实际S-CSCF已经处理了。这时候UE会重发REGISTER，S-CSCF发现IMPI已存在且Contact相同，直接返回200 OK，但不会刷新Expires。结果就是UE以为注册有效，实际快过期了。我建议在终端侧加个定时器，收到200 OK后解析Expires头域，如果剩余时间小于阈值就主动刷新。

注意：去注册时如果Expires=0但Contact头域缺失，部分S-CSCF会返回400 Bad Request。规范要求去注册必须带Contact，且和注册时一致。

2.3 注册流程的实操排查清单

干了这么多年，我整理了一套注册问题的速查表，基本能覆盖80%的现网故障：

实操心得：抓包时一定要同时抓UE侧和P-CSCF侧，对比SIP消息的源目IP和端口。我遇到过UE发的是公网IP，但P-CSCF回的是私网IP，结果UE收不到响应。这种问题单看一侧抓包根本发现不了。

3. IMS呼叫流程全解析

3.1 主叫侧信令流程与资源预留

呼叫流程是VoLTE最核心的部分，我把它拆成主叫侧、被叫侧和媒体协商三段来看。主叫侧从UE发INVITE开始，经过P-CSCF、S-CSCF，最终路由到被叫S-CSCF。INVITE里带SDP Offer，包含主叫支持的编解码列表，常见的有AMR-WB、AMR-NB、EVS。现在运营商主推EVS，因为窄带AMR在嘈杂环境下体验确实差一截。

资源预留是VoLTE呼叫的关键机制。主叫发INVITE后，网络侧会触发PCRF下发QoS策略，建立专用承载。这个过程走Rx接口，PCRF根据SDP里的媒体描述生成PCC规则，然后通过Gx接口下发给PGW。PGW再触发专有承载建立，保证语音包的QCI=1，调度优先级最高。

我实测过，从INVITE发出到收到183 Session Progress，正常在1.5秒左右。如果超过3秒，先查PCRF是否收到AAR消息，再看PGW有没有发起承载建立。常见问题是PCRF和PGW之间的Gx链路闪断，导致QoS策略没下发，语音走默认承载，质量直接崩。

主叫收到183后，会发PRACK确认，然后等待180 Ringing。180表示被叫正在振铃，这时候主叫能听到回铃音。回铃音有两种：本地生成和网络播放。早期VoLTE用本地回铃音，后来为了彩铃业务，改成网络侧播放，通过早期媒体承载传输。

3.2 被叫侧流程与振铃机制

被叫侧收到INVITE后，先做被叫锚定，然后查被叫的注册状态。如果被叫已注册，S-CSCF会把INVITE路由到被叫的Contact地址。被叫UE收到后，先回100 Trying，再回180 Ringing，同时振铃。

被叫侧有个重要概念叫"被叫域选择"，就是确定用哪个域接续。VoLTE终端同时注册在IMS和CS域，网络要根据T-ADS信息决定走VoLTE还是CSFB。T-ADS由MME提供，包含被叫是否支持VoLTE、当前附着状态等。如果T-ADS显示被叫不支持VoLTE，INVITE会被路由到MGCF，转成CS域呼叫。

振铃阶段有个细节容易被忽略：180 Ringing里的SDP。如果被叫想改编码，可以在180里带SDP Answer。但实际现网中，大部分终端在183里就完成协商了，180只做振铃指示。我遇到过被叫在180里改编码导致主叫播放静音的问题，后来查是终端SDP解析有bug，升级固件后解决。

被叫摘机后发200 OK，带最终SDP Answer。主叫收到后回ACK，媒体通道正式建立。这时候双向RTP开始传输，通话建立完成。整个流程从INVITE到200 OK，正常在3-5秒，如果超过6秒，用户就会感觉"接通慢"。

3.3 媒体协商与编解码选择

媒体协商是VoLTE呼叫里最灵活也最容易出问题的环节。SDP Offer/Answer模型决定了双方用什么编码、什么采样率、什么打包时长。我见过太多因为编解码不匹配导致的单通、杂音、断续问题。

编解码选择遵循几个原则：主叫优先、网络策略、终端能力。比如主叫支持EVS和AMR-WB，被叫只支持AMR-WB，那最终就用AMR-WB。如果双方都支持EVS，但网络侧配置只允许AMR-WB，那还是用AMR-WB。所以排查媒体问题时，一定要同时看终端能力和网络策略。

打包时长也很关键。AMR-WB通常用20ms打包，一个RTP包带一个语音帧。如果改成40ms，虽然减少了包头开销，但抗丢包能力下降。我做过对比测试：20ms打包在5%丢包率下MOS分还有3.8，40ms直接掉到3.2。所以现网基本都用20ms。

提示：媒体协商失败时，先看SDP里m行是否被拒绝（端口为0），再看rtpmap里的编码是否双方都支持。如果被叫回了488 Not Acceptable Here，说明没有共同编码，需要检查终端编解码配置。

4. 呼叫保持流程与二次协商机制

4.1 呼叫保持的信令交互与媒体控制

呼叫保持这个功能，普通用户用得不多，但在商务场景里很常见。比如你正在通话，突然要接另一个电话，或者要查个号码，就把当前通话保持住。VoLTE的呼叫保持走SIP的re-INVITE或者UPDATE消息，核心是把媒体流从双向改成单向或者暂停。

具体流程是：主叫发re-INVITE，SDP里把a=sendrecv改成a=sendonly或者a=inactive。被叫收到后回200 OK，SDP里对应改成a=recvonly或者a=inactive。这时候媒体通道还在，但RTP包要么只发不收，要么双向都停。网络侧不会拆承载，因为QoS资源还要保留，方便快速恢复。

我实测发现，呼叫保持的响应时间通常在200-500ms，比初始呼叫快得多。因为承载已经建好了，只需要改SDP属性。但有个坑：部分终端在保持时会把RTP包完全停掉，导致网络侧误判为媒体超时，触发承载去激活。后来运营商要求终端在保持期间发静音包（SID帧），维持媒体通道活性。

呼叫保持还有个变种叫"呼叫等待"，就是通话中收到新呼叫，系统提示你有来电。这时候你可以选择接听、拒接或者保持当前通话接听新呼叫。呼叫等待的信令流程和保持类似，但多了一个通知机制，通过NOTIFY消息告诉UE有新来电。

4.2 二次协商的触发场景与实现细节

二次协商是VoLTE里最体现"分组交换"优势的地方。传统CS域通话中想改编码？基本不可能，除非重建呼叫。但VoLTE可以随时通过re-INVITE或UPDATE改SDP，实现编码切换、媒体增删、方向变更。

常见的二次协商场景有：

• 编码切换：通话中从EVS降到AMR-WB，通常是因为网络拥塞或者切换到了不支持EVS的小区。
• 视频添加：语音通话中发起视频请求，SDP里增加视频m行，走同一个QoS承载或者新建承载。
• 网络切换：从LTE切到Wi-Fi，或者从Wi-Fi切到LTE，IP地址变了，必须重新协商媒体地址。
• 呼叫转移：转移过程中需要更新媒体端点。

二次协商的实现细节里，最麻烦的是"媒体地址变更"。比如UE从LTE切到Wi-Fi，IP从10.x.x.x变成192.168.x.x，这时候必须发re-INVITE更新SDP里的c行和m行端口。如果网络侧没及时更新，RTP包还往旧地址发，直接单通。

我处理过一个典型案例：用户在家用Wi-Fi打电话，走到楼下切回LTE，通话中断。抓包发现UE发了re-INVITE更新IP，但P-CSCF回了491 Request Pending，因为之前有个UPDATE还没完成。等UPDATE完成后，re-INVITE重发才成功。整个过程中断了2秒左右。后来优化了终端侧的定时器，让UPDATE和re-INVITE串行执行，问题解决。

4.3 二次协商的异常场景与容错处理

二次协商失败的情况不少见，我总结了几种典型异常：

第一种是"glare冲突"，就是双方同时发re-INVITE。SIP协议规定用491响应解决，但实际终端实现参差不齐。有的终端收到491后直接拆呼叫，有的会重试。我建议在终端侧加个随机退避定时器，避免同时发起。

第二种是"协商超时"，re-INVITE发出去后没收到响应。这时候UE会重传，通常T1=500ms，重传5次后超时。如果超时后UE直接拆呼叫，用户就掉线了。更好的做法是回退到原SDP，保持通话继续。

第三种是"媒体质量降级"，二次协商后编码变了，但QoS策略没跟着更新。比如从EVS降到AMR-WB，带宽需求降低了，但PCRF还按EVS的带宽预留，浪费资源。这时候需要PCRF支持动态策略更新，根据SDP变化调整QoS。

注意：二次协商期间，RTP流可能会短暂中断。为了减少对用户的影响，建议在re-INVITE里带SDP时，尽量保持媒体地址和端口不变，只改编码属性。这样RTP流可以无缝切换。

5. 常见问题排查与实操经验汇总

5.1 注册类问题速查与解决思路

注册问题我遇到最多的就是"注册失败但原因不明"。这时候别急着抓包，先看终端显示的注册状态。如果显示"已注册"但打不了电话，多半是注册状态和实际网络侧不一致。这时候可以手动触发去注册再注册，看能否恢复。

如果终端显示"注册中"一直转圈，先查APN配置。VoLTE需要专门的IMS APN，通常叫"ims"，类型是IMS。如果APN配错了，UE根本连不上P-CSCF。我见过有人把IMS APN的类型设成default，结果UE走默认承载去注册，P-CSCF直接拒绝。

还有一种情况是"注册成功但呼叫失败"，这多半是Contact地址问题。UE注册时带的Contact是私网IP，但P-CSCF没做NAT ALG，导致INVITE路由不到UE。解决办法是在P-CSCF上开启NAT ALG，或者让UE用公网IP注册。

5.2 呼叫类问题排查与信令分析

呼叫失败的原因五花八门，我按信令阶段来分类排查：

INVITE阶段失败：看UE有没有发出INVITE。如果没发，查拨号键是否触发、APN是否正常。如果发了但没响应，查P-CSCF到S-CSCF的链路。

183阶段失败：看PCRF有没有收到AAR。如果没收到，查P-CSCF的Rx接口配置。如果收到了但没回AAA，查PCRF策略配置。

180阶段失败：看被叫是否振铃。如果被叫没振铃，查被叫的T-ADS信息，看是否被路由到了CS域。

200 OK阶段失败：看被叫是否摘机。如果摘机了但主叫没收到200 OK，查S-CSCF的路由配置。

媒体阶段失败：看RTP包有没有双向传输。如果单向，查NAT、防火墙、QoS承载。

我常用的排查工具是Wireshark，过滤条件用" sip || rtp "。抓包点选在UE侧和P-CSCF侧，对比SIP消息的源目地址。如果发现SDP里的IP和实际RTP包的IP不一致，那就是NAT问题。

5.3 保持与二次协商问题排查

呼叫保持的问题相对少，但一旦出问题就很影响体验。最常见的是"保持后无法恢复"，就是按了恢复键但通话没回来。这多半是re-INVITE没发出去或者响应超时。查UE侧信令，看有没有发re-INVITE，SDP里a属性有没有改回sendrecv。

二次协商的问题更复杂，我遇到过"编码切换后单通"，就是协商成功了但一方听不到另一方。抓包发现SDP里编码改了，但RTP包的payload type没跟着改。这是终端实现bug，升级固件解决。

还有"二次协商后掉话"，通常是媒体地址变更后网络侧没更新。查PCRF的PCC规则，看有没有根据新SDP更新QoS。如果没有，手动触发PCRF重授权。

提示：二次协商期间，建议开启RTP的序列号连续性检查。如果发现序列号跳变，说明媒体通道中断过，需要分析中断原因。

5.4 实操经验与避坑指南

干了这么多年VoLTE，踩过的坑能写一本书。挑几个最有价值的分享：

第一，抓包一定要抓全。我见过有人只抓了UE侧，分析半天没结果。后来抓了P-CSCF侧，发现SIP消息根本没到P-CSCF。所以UE侧、P-CSCF侧、S-CSCF侧，能抓的都抓。

第二，时间同步很重要。多网元抓包时，如果时间不同步，根本没法关联分析。建议所有抓包点都配NTP，误差控制在10ms以内。

第三，SDP要逐行看。很多人看SDP只看m行和rtpmap，忽略了a行和c行。a行里的方向属性、c行里的IP地址，都是排查问题的关键。

第四，QoS承载要确认。VoLTE语音必须走QCI=1的专有承载。如果走了QCI=9的默认承载，质量没保障。查PGW的承载列表，确认QCI=1的承载已建立。

第五，终端兼容性要测试。不同品牌的终端对VoLTE的支持程度不一样。我遇到过某品牌终端在二次协商时不支持UPDATE，只能用re-INVITE。所以做网络优化时，要针对主流终端做兼容性测试。

最后分享一个我常用的信令分析模板，按这个顺序查，基本不会漏：

1. 注册状态是否正常
2. INVITE是否发出并收到100 Trying
3. 183是否收到并触发资源预留
4. 专有承载是否建立（QCI=1）
5. 180是否收到并振铃
6. 200 OK是否收到并回ACK
7. RTP是否双向传输
8. 通话中是否有re-INVITE或UPDATE
9. 挂机信令是否正常（BYE）

这套流程走下来，90%的VoLTE问题都能定位到具体网元或终端。剩下的10%，多半是终端实现差异或者网络配置的边角问题，需要具体问题具体分析。