VoLTE 这个技术刚接触的时候很容易被它那一堆缩写和流程图劝退。IMS、SIP、SDP、Precondition、UPDATE、PRACK……每个词单拎出来都认识串在一起就不知道在干什么了。但真正在核心网或者终端侧做过一轮完整信令跟踪之后你会发现它的设计逻辑其实非常清晰——本质上就是把传统电路域那套先建路、再通话的思路搬到了一个全 IP 的架构上同时用 SIP 协议把整个控制面统一起来。这篇内容我打算从实际信令流程的角度把 VoLTE 里最核心的几块东西拆开讲IMS 注册和去注册到底在做什么、一次完整的 IMS 呼叫是怎么一步步走完的、呼叫保持这种看起来简单的补充业务背后藏着什么、以及二次协商重协商在什么场景下会被触发。适合已经对 LTE 有基本了解、想深入理解 VoLTE 信令流程的读者也适合正在做 IMS 相关开发或测试、需要一份能对照信令抓包来看的参考材料的人。我不会只贴流程图了事而是尽量把每一步为什么要有这个动作不做会怎样实际抓包里长什么样讲清楚。因为 VoLTE 这东西光看标准文档和实际跑一遍中间差着十万八千里。1. IMS 注册与去注册终端接入 VoLTE 的第一道门1.1 为什么 VoLTE 必须先注册才能打电话传统 CS 域打电话终端开机附着到网络之后MSC 就知道你在哪来电话了直接寻呼你。但 VoLTE 走的是 PS 域IP 网络本身是无状态的——你接入了一个 PDN 连接网络只知道有个 IP 地址在用并不知道这个 IP 背后是谁、能不能接电话、支持什么编解码。所以必须有一套机制让终端主动告诉网络我是谁、我在哪、我能做什么这就是 IMS 注册要解决的问题。IMS 注册的本质是终端和 IMS 网络之间建立一个绑定关系终端把自己的 IMPI私有身份、IMPU公有身份、联系地址Contact也就是终端的 IP 和端口、能力信息告诉 S-CSCFS-CSCF 把这些信息存下来同时从 HSS 拉取用户的签约数据。注册完成之后S-CSCF 就知道这个用户当前可达联系地址是 XXX来电话的时候才能正确路由过去。这里有个容易混淆的点IMS 注册和 LTE 附着是两回事。LTE 附着完成、建立了默认承载之后终端只是有了 IP 连接能力但 IMS 注册是应用层的动作需要终端主动发起 SIP REGISTER。而且 IMS 注册之前终端通常还要先建立一个专用的 IMS APN 承载或者用默认承载并完成 P-CSCF 地址发现通过 PCO 或 DHCP。这些前置步骤任何一步没走通REGISTER 都发不出去。1.2 注册流程的信令链路拆解一次完整的 IMS 注册从终端到网络侧要经过 P-CSCF、I-CSCF、S-CSCF 三个网元中间还涉及 HSS 的交互。我按实际抓包的顺序把它拆开第一步终端发起 REGISTER终端构造 SIP REGISTER 消息Request-URI 填的是自己的 IMPU 所在的域名比如 sip:ims.mnc001.mcc460.3gppnetwork.orgTo 头域是 IMPUFrom 头域也是 IMPUContact 头域填自己的 IP 和端口。消息里还会带 Expires 头域表示希望注册的有效期。这条消息先发给 P-CSCF。P-CSCF 是终端在 IMS 里的第一个接触点它的地址在 PDN 建立时通过 PCO 下发。P-CSCF 收到 REGISTER 后会根据 Request-URI 里的域名去查 DNS或者本地配置找到 I-CSCF 的地址然后转发过去。第二步I-CSCF 查询 HSS 选择 S-CSCFI-CSCF 收到 REGISTER 后自己并不知道该把这个用户交给哪个 S-CSCF 处理。所以它会先向 HSS 发一个 UARUser-Authorization-Request问这个用户应该由哪个 S-CSCF 服务。HSS 返回 UAAUser-Authorization-Answer里面带上 S-CSCF 的能力要求或者直接指定一个 S-CSCF 名字。如果用户之前已经注册过HSS 可能返回之前分配的那个 S-CSCF如果是首次注册HSS 会根据能力集选一个合适的 S-CSCF。I-CSCF 拿到 S-CSCF 地址后把 REGISTER 转发过去。第三步S-CSCF 鉴权挑战S-CSCF 收到 REGISTER 后不会直接信任终端而是先发起鉴权。它向 HSS 发 MARMultimedia-Auth-Request拉取鉴权向量包括 RAND、AUTN、XRES、CK、IK 等。HSS 返回 MAA带上鉴权五元组。S-CSCF 用这些数据构造一个 401 Unauthorized 响应里面带 WWW-Authenticate 头域包含 RAND 和 AUTN。这条 401 沿着原路返回给终端。终端收到 401 后用 USIM 卡里的密钥和 RAND/AUTN 做 AKA 算法运算算出一个 RES然后用这个 RES 构造一个新的 REGISTER在 Authorization 头域里带上 RES。同时终端还会计算出 CK 和 IK用于后续的 IPsec 加密如果网络要求。第四步鉴权通过注册确认S-CSCF 收到带 Authorization 的 REGISTER 后把终端算出的 RES 和自己手里的 XRES 做比对。一致就鉴权通过然后向 HSS 发 SARServer-Assignment-Request告诉 HSS这个用户我已经接管了同时拉取用户的签约数据比如哪些业务被允许、哪些被禁止。HSS 返回 SAAS-CSCF 拿到签约数据后返回 200 OK 给终端。这个 200 OK 里会带 Service-Route 头域告诉终端后续发请求时要经过哪些 S-CSCF。终端收到 200 OK整个注册流程才算完成。注意实际抓包里401 响应和第二次 REGISTER 之间的时间间隔通常很短几十毫秒因为终端算 AKA 是本地运算很快。但如果看到终端反复发 REGISTER 却一直收不到 200 OK大概率是鉴权失败或者 HSS 侧签约数据有问题。1.3 去注册的触发场景与流程差异去注册De-registration分两种终端主动去注册和网络侧发起去注册。终端主动去注册通常是关机、飞行模式开启、或者 IMS 服务被关闭时触发。流程很简单终端发一个 REGISTERExpires 头域填 0表示我要注销。S-CSCF 收到后向 HSS 发 SAR把用户的注册状态清掉然后返回 200 OK。终端收到 200 OK 后本地也清掉注册状态。网络侧发起去注册场景就多了用户欠费、签约变更、S-CSCF 故障倒换、或者网络维护。网络侧去注册是通过 NOTIFY 消息实现的——S-CSCF 向终端发一个 NOTIFY里面带 registration-state 事件值为 terminated。终端收到后回 200 OK然后本地清状态。如果终端没有正确响应S-CSCF 可能会重发 NOTIFY或者等注册超时后强制清除。这里有个实际测试中经常遇到的问题去注册之后终端没有重新注册。比如飞行模式切换回来终端可能只做了 LTE 附着但没有重新发起 IMS 注册。这时候终端能上网但打不了电话。排查的时候要看终端侧有没有发 REGISTER以及 P-CSCF 地址有没有重新获取。有些终端实现里IMS 注册是跟着 PDN 连接走的PDN 断了重连之后IMS 注册应该自动触发但如果 APN 配置有问题可能就不会触发。2. IMS 呼叫流程从 INVITE 到 200 OK 的完整路径2.1 呼叫建立前的承载准备Precondition 机制VoLTE 呼叫和 CS 域呼叫最大的区别之一就是承载建立和呼叫建立是分离的。CS 域里呼叫建立和语音通道建立是同步的但 VoLTE 里SIP 信令走的是默认承载或者信令承载而语音媒体走的是专用承载QCI1 的 GBR 承载。专用承载什么时候建、建好了没有需要通过 SIP 信令来协调这就是 Precondition 机制要解决的问题。Precondition 的核心思想是主叫和被叫在发送 INVITE/183/180 这些消息时会在 SDP 里带上 precondition 属性告诉对方我这边承载还没准备好或者我这边承载已经准备好了。只有双方都确认承载就绪才会真正振铃和接通。具体来说SDP 里会用adesiredQos、aconfQos、acurQos这些属性来描述承载状态。主叫发 INVITE 时SDP 里带adesiredQos表示我希望建立这个 QoS 的承载。网络侧P-CSCF/PCRF看到这个之后会触发专用承载建立。等承载建好了终端再发 UPDATESDP 里带aconfQos表示承载已经确认建立。被叫侧同理。这个机制的好处是避免出现信令接通了但媒体通道还没建好的情况保证一接通就能说话。坏处是流程变复杂了信令交互次数变多呼叫建立时延比 CS 域略长。2.2 主叫侧信令INVITE 发出之后发生了什么主叫终端发起呼叫时构造 INVITE 消息Request-URI 填被叫的 IMPU比如 sip:8613800138000ims.mnc001.mcc460.3gppnetwork.orgTo 头域也是被叫 IMPUFrom 头域是主叫 IMPU。SDP 里带上主叫支持的编解码列表比如 AMR-WB、AMR-NB、媒体类型audio、端口号以及 precondition 相关属性。INVITE 先发给 P-CSCFP-CSCF 根据 Request-URI 里的域名找到 I-CSCFI-CSCF 再向 HSS 发 LIRLocation-Info-Request查询被叫当前注册在哪个 S-CSCF。HSS 返回 LIA带上被叫的 S-CSCF 地址。I-CSCF 把 INVITE 转发给被叫的 S-CSCF。被叫 S-CSCF 收到 INVITE 后根据被叫的 IMPU 找到对应的 Contact 地址也就是被叫终端的 IP 和端口把 INVITE 转发给被叫的 P-CSCF再转发给被叫终端。被叫终端收到 INVITE 后先做一系列检查自己是否支持请求的编解码、是否有足够资源、是否处于可接听状态。如果都没问题被叫终端会返回 183 Session Progress里面带自己的 SDP包括编解码、端口、precondition 属性。这条 183 沿着原路返回给主叫。主叫收到 183 后知道被叫已经收到了 INVITE 并且给出了媒体协商信息。但这时候承载还没建好所以主叫会发 PRACKProvisional Response Acknowledgement来确认收到 183。PRACK 是 SIP 的一个扩展用来可靠传输临时响应。被叫收到 PRACK 后回 200 OK。接下来是承载建立阶段。主叫和被叫各自触发专用承载建立通过 P-CSCF 通知 PCRFPCRF 再通知 PGW 建立 GBR 承载。承载建好后双方会发 UPDATESDP 里带aconfQos表示承载已确认。UPDATE 的交互也是通过 200 OK 确认。等双方都确认承载就绪后被叫终端开始振铃返回 180 Ringing。主叫听到回铃音。被叫接听时返回 200 OKINVITE 的最终响应里面带最终的 SDP。主叫收到 200 OK 后回 ACK整个呼叫建立完成进入通话状态。2.3 被叫侧的关键动作寻呼与承载建立被叫侧有一个容易被忽略的环节寻呼。如果被叫终端处于 RRC Idle 状态网络需要先寻呼它把它唤醒到 Connected 状态才能把 INVITE 递过去。这个寻呼是通过 LTE 的 Paging 机制完成的和 IMS 信令是两层的事但实际排查问题时经常需要联合看。被叫终端从 Idle 唤醒后先建立 RRC 连接然后收到 INVITE。如果被叫终端此时没有建立 IMS 专用承载它需要先触发承载建立。这个过程和主叫侧类似终端通过 SIP 信令里的 precondition 属性触发 P-CSCF 通知 PCRFPCRF 通知 PGW 建立 GBR 承载。承载建好后终端才能发 UPDATE 确认。实际测试中被叫侧最常见的问题是寻呼失败。原因可能有很多终端不在服务区、寻呼信道配置有问题、或者终端处于某种省电模式没有响应寻呼。排查的时候要看 MME 侧有没有发 Paging终端侧有没有响应。如果 MME 发了 Paging 但终端没回可能是无线环境问题如果 MME 根本没发 Paging可能是 S-CSCF 没有把 INVITE 正确路由到 MME通过 ISC 接口或者 Sh 接口。2.4 呼叫流程中的关键头域与参数实际抓包里有几个头域和参数是必须关注的它们直接决定了呼叫能不能走通头域/参数作用常见问题Request-URI标识被叫填错域名会导致路由失败Contact终端联系地址IP/端口不对会导致消息发不到SDP c媒体连接地址填 0.0.0.0 表示待定填错会导致媒体不通SDP m媒体类型和端口端口不匹配会导致 RTP 收不到adesiredQos请求 QoS缺失会导致专用承载不建立aconfQos确认 QoS缺失会导致呼叫无法接通Service-Route服务路由缺失会导致后续请求路由错误P-Access-Network-Info接入网信息用于计费和策略缺失可能影响业务这些参数里SDP 的 c 行特别容易出问题。如果终端在 SDP 里填了 0.0.0.0表示媒体地址待定需要后续用 UPDATE 或者 ACK 来更新。但如果更新没做媒体就发不出去。实际测试中遇到过终端在 183 里填 0.0.0.0但在 UPDATE 里没有更新 c 行导致主叫侧一直收不到媒体。3. 呼叫保持流程看似简单实则暗藏玄机3.1 呼叫保持的业务逻辑与信令表现呼叫保持Call Hold是 VoLTE 里最常用的补充业务之一。用户 A 在和 B 通话这时候来了个电话 CA 可以把 B 保持住先接 C接完再切回 B。或者 A 主动保持 B去打另一个电话。从信令角度看呼叫保持的本质是媒体流的重新协商。保持方比如 A会发一个 re-INVITE 或者 UPDATESDP 里把媒体方向属性改成asendonly或者ainactive。被保持方B收到后回 200 OKSDP 里把自己的方向改成arecvonly或者ainactive。这样媒体流就停了但 SIP 会话还在随时可以恢复。具体来说A 发 re-INVITESDP 里带asendonly表示我暂时只发不收实际上保持场景下通常是ainactive表示收发都停。B 收到后知道 A 要保持回 200 OKSDP 里带arecvonly或者ainactive。A 收到 200 OK 后回 ACK保持生效。恢复的时候反过来A 发 re-INVITESDP 里带asendrecvB 回 200 OK 带asendrecvA 回 ACK媒体恢复。3.2 保持与恢复中的媒体方向属性详解SDP 里的方向属性有四种asendrecv、asendonly、arecvonly、ainactive。它们决定了 RTP 流的收发方向。实际用的时候保持方和被保持方的属性必须匹配否则会出现一方以为停了、另一方还在发的情况。保持方 SDP被保持方 SDP实际效果asendonlyarecvonly保持方只发不收被保持方只收不发不推荐媒体单向ainactiveainactive双方都停媒体完全中断推荐asendonlyainactive保持方发被保持方停可能出问题arecvonlyasendonly保持方只收不发被保持方只发不收不推荐实际部署中大部分网络推荐用ainactive因为语义最清晰双方都停不会出现单向媒体。但有些终端实现里保持方发asendonly被保持方回arecvonly这样保持方还能发比如发彩铃或者通知音被保持方只能收。这种用法在特定场景下有用但通用性不如ainactive。注意如果保持方发了ainactive但被保持方回了asendrecv就会出现状态不一致。保持方以为媒体停了被保持方还在发结果就是保持方听到被保持方的声音。这种问题在实际测试中遇到过通常是终端 SDP 处理逻辑有 bug。3.3 保持场景下的常见异常与排查思路呼叫保持最常见的异常是保持后无法恢复。表现是A 保持 B 之后再发 re-INVITE 恢复但 B 不回 200 OK或者回了但媒体不通。排查的时候先看 re-INVITE 有没有发出去。如果 A 侧发了但 B 侧没收到可能是路由问题Service-Route 变了、Contact 地址失效。如果 B 侧收到了但不回可能是 B 侧状态机有问题比如 B 认为会话已经结束了。如果 B 回了 200 OK 但媒体不通可能是 SDP 协商有问题比如端口变了但没更新。另一个常见问题是保持期间收到新呼叫。A 保持 B 的时候C 打进来A 需要能正确处理。这时候 A 的终端要同时维护两个会话一个保持的 B一个活跃的 C。如果终端实现有问题可能会出现保持的会话被意外释放或者新呼叫接不起来。这种问题通常需要看终端侧的状态机实现网络侧一般不会有问题。还有一个坑是保持超时。有些网络配置了保持超时定时器如果保持时间太长比如超过 5 分钟网络可能会主动释放会话。这个定时器在 S-CSCF 或者 AS 上配置具体值取决于运营商策略。实际测试中如果发现保持一段时间后自动挂断要查这个定时器。4. 二次协商过程什么时候需要重新谈媒体4.1 二次协商的触发场景二次协商Re-negotiation指的是在会话已经建立之后双方重新协商媒体参数。触发场景有很多呼叫保持/恢复前面讲的保持和恢复都需要重新协商媒体方向。编解码切换通话过程中如果网络质量变化可能需要从 AMR-WB 切到 AMR-NB或者反过来。媒体添加/删除比如通话中要加视频或者从视频通话切回语音。IP 地址变化终端切换网络比如从 Wi-Fi 切到 LTEIP 地址变了需要更新 SDP 里的 c 行。QoS 变化网络侧策略变化需要重新协商 QoS 参数。会议场景多方通话里新成员加入或者退出需要重新协商媒体。这些场景里呼叫保持和编解码切换是最常见的。IP 地址变化在 VoWiFi 和 VoLTE 切换场景下也会遇到。4.2 re-INVITE 与 UPDATE 的选择逻辑二次协商可以用 re-INVITE也可以用 UPDATE。两者都能更新 SDP但适用场景不同。re-INVITE是一个完整的 INVITE 事务会走完整的 offer/answer 流程而且会触发被叫侧的振铃如果 SDP 里有新的媒体流。re-INVITE 的好处是兼容性好几乎所有 SIP 终端都支持坏处是流程重时延大而且如果处理不当可能会影响当前会话。UPDATE是 SIP 的一个扩展专门用于在会话建立过程中或者建立后更新会话参数不会触发振铃。UPDATE 的好处是轻量、快坏处是有些老终端不支持。实际部署中呼叫保持通常用 re-INVITE因为需要可靠传输编解码切换可能用 UPDATE因为要快。但具体用哪个取决于终端实现和网络配置。有些网络强制要求用 re-INVITE有些允许用 UPDATE。提示如果终端发了 UPDATE 但网络不回可能是网络侧不支持 UPDATE或者 S-CSCF 没有正确路由 UPDATE。这时候可以尝试改用 re-INVITE。4.3 二次协商中的 SDP offer/answer 陷阱二次协商的 SDP offer/answer 和初始协商有一些不同容易踩坑的地方也更多。第一个坑offer 里的媒体行数量变化。如果二次协商的 offer 里媒体行数量和初始协商不一致比如初始是 1 个 audio二次协商变成 2 个 audio被叫侧可能不知道怎么处理。标准里规定媒体行数量不能增加只能减少或者保持不变。如果增加了被叫侧应该拒绝。第二个坑端口号为 0。如果 offer 里某个媒体行的端口填 0表示这个媒体流要删除。被叫侧收到后应该在 answer 里也把对应媒体行的端口填 0。如果被叫侧没填 0或者填了但主叫侧没处理就会出现以为删了但实际还在的情况。第三个坑c 行的更新。如果二次协商的目的是更新 IP 地址offer 里的 c 行必须填新的地址。被叫侧收到后要在 answer 里确认。如果被叫侧没更新媒体还是发到旧地址就会不通。第四个坑precondition 属性的处理。二次协商里precondition 属性可能还需要也可能不需要。如果二次协商只是切换编解码不涉及承载变化precondition 可以省略。但如果涉及承载变化比如从语音加到视频precondition 还是要带。这个判断逻辑在终端侧实现如果实现错了可能会导致协商失败。4.4 实际抓包中二次协商的典型序列我拿一个呼叫保持后恢复的场景把实际抓包里的信令序列列出来A - B: re-INVITE (SDP: ainactive) B - A: 200 OK (SDP: ainactive) A - B: ACK 保持生效媒体停止 ...一段时间后... A - B: re-INVITE (SDP: asendrecv) B - A: 200 OK (SDP: asendrecv) A - B: ACK 媒体恢复这个序列看起来简单但实际抓包里可能会看到更多消息。比如如果网络侧要求 preconditionre-INVITE 之后可能会有 UPDATE 交互来确认承载。如果承载需要重建比如保持时间太长专用承载被释放了还会看到承载建立的流程。另一个典型场景是编解码切换A - B: re-INVITE (SDP: maudio, 编解码列表 AMR-WB/AMR-NB) B - A: 200 OK (SDP: maudio, 选定 AMR-NB) A - B: ACK 编解码从 AMR-WB 切到 AMR-NB这个序列里A 在 offer 里列出两个编解码B 在 answer 里选一个。如果 B 选的编解码 A 不支持或者 B 没选answer 里编解码列表为空协商就会失败。5. 从信令跟踪到问题定位几个实战经验5.1 抓包工具的选择与过滤技巧做 VoLTE 信令分析抓包是基本功。常用的工具有终端侧的内置日志比如高通平台的 QXDM、MTK 平台的 ELT、网络侧的抓包比如在 P-CSCF 或者 S-CSCF 上抓、以及专门的 SIP 分析工具。终端侧抓包的好处是能看到终端发出的原始消息和终端的状态机变化坏处是只能看到终端视角看不到网络侧的处理。网络侧抓包的好处是能看到完整的信令链路坏处是需要网络权限而且可能涉及多个网元关联起来麻烦。实际工作中我通常两边都抓然后按时间戳对齐。过滤的时候SIP 消息用sip或者sip || sdp过滤RTP 用rtp过滤。如果要看特定用户可以用 IMPU 或者 IP 地址过滤。提示抓包的时候要注意时间同步。终端侧和网络侧的时间可能不一致差几秒甚至几分钟。对齐的时候可以用一个共同的事件比如 INVITE 发出作为基准。5.2 注册失败的分层排查法注册失败是 VoLTE 里最常见的问题之一。排查的时候我习惯按分层的方式来做第一层PDN 连接是否建立。如果终端连 IMS APN 都没建起来REGISTER 根本发不出去。看终端侧有没有 IMS PDN 的激活记录P-CSCF 地址有没有获取到。第二层REGISTER 是否发出。如果 PDN 建了但 REGISTER 没发可能是终端 IMS 开关没开或者 IMS 注册触发条件没满足。第三层REGISTER 是否到达 P-CSCF。如果终端发了但 P-CSCF 没收到可能是 IP 路由问题或者 P-CSCF 地址配错了。第四层鉴权是否通过。如果 P-CSCF 收到了但返回 401 之后没有第二次 REGISTER或者第二次 REGISTER 之后返回 403可能是鉴权失败。查 USIM 卡状态、HSS 签约数据。第五层S-CSCF 是否返回 200 OK。如果鉴权通过了但没返回 200 OK可能是 S-CSCF 内部错误或者 HSS 交互失败。这个分层法看起来简单但实际用的时候能快速缩小范围。我遇到过很多次问题出在第一层PDN 没建起来但排查的时候一直在看 SIP 信令浪费了很多时间。5.3 呼叫建立时延的优化思路VoLTE 呼叫建立时延比 CS 域长这是公认的。但实际测试中时延可以优化到和 CS 域差不多2-3 秒。优化的思路有几个减少信令交互次数。比如如果网络支持可以用 UPDATE 代替 re-INVITE 来做二次协商减少事务开销。或者如果终端和网络都支持可以省略 PRACK但可靠性会降低。并行处理。承载建立和信令交互可以并行。比如主叫发 INVITE 之后不用等 183 回来就可以开始触发承载建立。这样能省几百毫秒。优化寻呼参数。被叫侧的寻呼时延占呼叫建立时延的很大一部分。优化寻呼周期、增加寻呼信道资源都能减少寻呼时延。预建立承载。有些网络会在终端注册的时候就预建立专用承载这样呼叫的时候就不用再建了。但这样会浪费资源适合高价值用户。实际优化的时候要先测量各阶段的时延找到瓶颈在哪再针对性优化。盲目优化可能效果不明显。5.4 几个容易忽略的配置项最后分享几个实际工作中容易忽略的配置项P-CSCF 地址发现方式。终端获取 P-CSCF 地址有两种方式PCOProtocol Configuration Options和 DHCP。PCO 是 LTE 里常用的DHCP 在 VoWiFi 里常用。如果配置错了终端可能拿不到 P-CSCF 地址注册就失败了。IPsec 策略。IMS 注册和信令通常要求 IPsec 加密。如果终端和 P-CSCF 之间的 IPsec SA 没建起来REGISTER 可能会被拒绝。检查 IPsec 配置加密算法、密钥生命周期是否匹配。Service-Route 头域。这个头域告诉终端后续请求要经过哪些 S-CSCF。如果缺失或者填错后续的 INVITE 可能会路由失败。有些终端不检查这个头域直接按 Request-URI 路由可能会绕过 S-CSCF导致业务失败。QoS 参数映射。SDP 里的 QoS 参数比如adesiredQos需要正确映射到 LTE 的 QCI 和 GBR。如果映射错了专用承载可能建不起来或者建起来了但 QoS 不对。这个映射关系在 PCRF 上配置需要和核心网侧对齐。定时器配置。SIP 有很多定时器比如 T1、T2、T4IMS 也有自己的定时器比如注册超时、会话超时。这些定时器的值会影响信令重传和超时行为。如果配置不当可能会出现消息重传导致信令风暴或者超时太短导致正常流程被中断。实际调优的时候要根据网络时延和终端行为来调整。这些配置项单个看起来都不复杂但组合在一起任何一个出问题都可能导致业务失败。实际排查的时候建议按从底层到上层的顺序检查先看 PDN 和 IP 连接再看 IMS 注册再看呼叫信令最后看媒体。这样能避免在错误的层次上浪费时间。VoLTE 的信令流程刚看的时候觉得复杂但拆开之后每一块都有清晰的逻辑。注册是为了让网络知道你在哪呼叫是为了协商媒体和建立承载保持是为了临时停媒体但保留会话二次协商是为了在会话中动态调整媒体。把这四块搞清楚了大部分 VoLTE 问题都能定位到具体环节。剩下的就是多抓包、多对比、多总结经验积累到一定程度看到信令序列就能猜到问题在哪。