企业官网建设流程全解析

简介：IMS注册及CALL SIP信令分析文档，面向IMS系统开发、测试与维护人员，围绕LTE/IMS网络下的注册流程与MO CALL呼叫信令展开，适合需要快速掌握IMS信令分析方法的工程师参考。资源包内含1个docx文档，大小仅144KB，以精炼的条目式内容呈现，便于边查边用。该文档已有1539人学习下载。内容从实际信令消息出发，逐一拆解IMS注册的五个关键步骤：DS通知LTE服务可用、获取APN列表与属性、触发PDN连接请求、发送SIP注册消息、通知CM注册状态变化；同时对IMS MO CALL的SIP信令进行逐条分析，包括INVITE消息中的主被叫号码、Call-ID、Via/Contact/Route路由信息、Allow/Require权限字段，以及SDP中的AMR/AMR-WB编解码协商、资源预留方向等内容，覆盖呼叫建立、维持与释放的核心信令交互。对于IMS系统开发和日常信令排障，这份分析能提供明确的字段含义和流程节点参考，帮助读者少走弯路。

1. 把IMS注册和CALL信令放在一张抓包里：VoLTE排障的起点

在办公区收到终端测试同事的消息：“手机状态栏显示VoLTE已打开，但网络注册状态一直停在‘未注册’，拨出的电话秒回落2G。”我第一反应不是看手机，而是先要一份抓包。IMS注册和CALL SIP信令分析，干的就是这件事：用SIP协议栈里最核心的REGISTER和INVITE两个流程，判断一个语音业务问题是出在终端、接入网、核心网还是对端。注册决定你能不能在线，CALL决定你在线时能不能打通。这篇文章写给做VoLTE/VoWiFi现网验证、运营商终端测试以及在vIMS模拟环境里调协议栈的工程师：看完你能从一张pcap里把注册阶段、呼叫阶段的问题定位到具体网元和具体字段。

2. 拆解IMS注册流程：REGISTER、401挑战与P-CSCF发现

2.1 注册成功要过四道关：从网络接入到AKA鉴权

IMS注册不是简单发一个REGISTER就完事。UE先用DHCP或PDU会话拿到IP地址，通过ePDG（VoWiFi场景）或LTE默认承载找到P-CSCF，之后才进入SIP信令阶段。P-CSCF发现通常走DNS NAPTR/SRV查询，域名类似ims.mnc001.mcc460.pub.3gppnetwork.org，返回的是支持SIP的传输协议和端口。这一步经常被忽略，但它是“注册不了”的第一个高发原因：DNS返回了错误地址，或者防火墙只放行了UDP 5060，导致REGISTER发出后石沉大海。

IMS的鉴权走的是RFC 3329与AKA（Authentication and Key Agreement）。第一次REGISTER不带安全凭证，P-CSCF/S-CSCF会回401 Unauthorized，并在WWW-Authenticate头里携带RAND和AUTN参数。终端用USIM里的密钥和OPc计算RES，再发第二次REGISTER，这次带Authorization头。网络校验RES通过后，回200 OK，同时下发Service-Route、P-Associated-URI和Contact。这个“401→第二次REGISTER→200”的节奏，是判断鉴权链路是否正常的核心参照。

2.2 用tshark提取注册流程：最小命令与字段说明

现网设备上直接抓包不方便时，我在接入侧镜像口或测试vIMS的P-CSCF节点上用tcpdump先落盘：

tcpdump -i eth0 -s 0 -w ims_register.pcapng \ "host 192.168.10.20 and (port 5060 or port 5061)"

抓完用Wireshark打开，显示过滤器从上到下依次验证三个节点：

sip.Method == "REGISTER" sip.Status-Code == 401 sip.Status-Code == 200

如果需要快速出表格、不打开图形界面，用tshark一条命令把关键字段拉出来：

tshark -r ims_register.pcapng \ -Y 'sip.Method == "REGISTER" || sip.Status-Code == 401 || sip.Status-Code == 200' \ -T fields \ -e frame.number \ -e frame.time_delta_displayed \ -e sip.Method \ -e sip.Status-Code \ -e sip.auth.uri \ -e sip.contact.uri \ -e sip.CSeq

-Y后面是显示过滤器，只保留注册相关报文；-T fields配合多个-e参数，把帧号、相对时间、方法、状态码、Authorization URI和Contact地址平铺成一列。我最看重的是time_delta_displayed这一列：真实AKA鉴权中，第一次REGISTER与401之间、401与第二次REGISTER之间的间隔，通常在几十到几百毫秒。如果间隔超过T1重传定时器（默认500ms）的整数倍，基本能判断是丢包重传而不是正常的网络延迟。

2.3 注册失败的几个关键状态码与排查方向

注册阶段的报错不像CALL阶段那么多样，但每个状态码背后的原因差异很大。下表是现场最常遇到的几类：

我见过最典型的翻车是：测试终端第一次REGISTER后收到401，但没有自动发第二次REGISTER。查抓包发现401的WWW-Authenticate头里没有autn参数，或者终端的USIM卡是普通数据卡而非VoLTE签约卡。这种问题在模拟器里用“空鉴权”跑惯了的人，一上真实网络就被打回原形。建议在验证AKA流程时，先确认Authorization头里的response字段每次都在变化，否则说明终端压根没有参与挑战，网络自然不认。

3. 深挖CALL信令：INVITE的SDP协商、状态码与RTP接续对照

3.1 主叫接续的完整SIP信令链：从INVITE到BYE

IMS注册成功只是拿到入场券，真正的考验在CALL阶段。一次最简单的VoLTE呼叫，信令链是主叫发出INVITE，P-CSCF返回100 Trying，被叫振铃时回180 Ringing，被叫接听后回200 OK，主叫回ACK，通话结束后任一方发BYE，对端回200 OK。如果开了Precondition，还会看到183 Session Progress和PRACK/200 OK的握手，那是IMS里做资源预留时的额外环节。

我在分析INVITE报文时必看四个头域：Request-URI是否是被叫的tel URI（E.164格式，例如tel:+8613912345678）；Route头里是否带着注册阶段网络下发的Route Set；P-Asserted-Identity是否显示主叫真实号码；以及SDP的m行。用tshark抽SDP信息，可以这样：

tshark -r call_ims.pcapng \ -Y 'sip.Method == "INVITE"' \ -T fields \ -e sip.Request-Line \ -e sip.contact.uri \ -e sip.Route \ -e media.coding \ -e media.type \ -e media.pt

sip.Route字段能直接反映核心网下发的路由路径，如果INVITE里没有Route头，或者Route头里只有一个IP而没有sip:orig@scscf这类域名，基本可以断定终端没有维护好注册阶段获得的Route Set，呼叫会被S-CSCF拒绝或导致路由环路。

3.2 SDP协商与编解码错位：488和单通都从这里来

SDP协商是CALL信令里最容易出问题的区域。主叫在INVITE里发SDP offer，被叫在200 OK里回SDP answer，双方必须在公共编解码集合里选一个。一个典型的IMS语音offer长这样：

m=audio 49152 RTP/AVP 97 98 3 0 a=rtpmap:97 AMR-WB/16000/1 a=rtpmap:98 AMR-WB/16000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:0 PCMU/8000/1 a=ptime:20 a=sendrecv b=AS:24.6

这里的b=AS:24.6代表音频带宽上限为24.6kbps，对应AMR-WB 12.65kbps编码。如果网络侧只放行AMR-WB，而终端offer里把PCMU放在最前面优先级最高，可能被对端回488 Not Acceptable Here。我曾排查过一起“主叫听得到、被叫听不到”的单通，抓包显示被叫回的200 OK里m=audio行没有a=rtpmap，Wireshark直接把它标成无效payload类型，终端只能静默发送。

遇到单通和编码问题，把SDP的m行、a=rtpmap、a=sendrecv/recvonly、b=参数四个值拉出来对照就够。多数单通的根因不在SIP头，而在SDP的recvonly：如果被叫回的是a=recvonly，说明被叫侧资源预留失败，主动方只收不发。

3.3 CALL阶段状态码的会话断点定位

CALL阶段的状态码比注册阶段复杂，但它能直接告诉你呼叫断在哪一步：

还有一类是183 Session Progress之后再也没有后续。这种情况不要只盯着SIP报文，要看资源预留：Precondition流程里，主叫在收到183后应发PRACK，确认媒体流可用后再发UPDATE。如果183之后跟的是INVITE的重传而不是PRACK，说明终端不认183里的SDP，常见原因是被叫回183时携带了早媒体（early media），而主叫没有做相应处理。

4. 信令分析避坑：注册和呼叫里最容易误判的五个现场

4.1 401后没有第二次REGISTER：鉴权挑战没走完

现象：抓包里只有第一次REGISTER和401，之后终端不再发包，注册超时。

原因：终端收到401后需要解析WWW-Authenticate里的nonce和AUTN。若USIM里的AKA参数与网络侧不匹配，RES计算失败，终端会放弃挑战；另一类常见原因是401响应的algorithm=AKAv1-MD5与实际SIM卡能力不一致，终端直接丢弃。

解决：先核对401响应里WWW-Authenticate是否完整，再检查终端使用的IMPI是否与SIM卡IMSI一致。在测试环境中，不要把网络侧的鉴权模式配成“空鉴权”来绕过，否则真机上到现网必然踩坑。

4.2 注册成功但INVITE被拒：Route Set没保住

现象：手机状态栏显示VoLTE已经注册成功，但一拨号就收到403或呼叫转2G。

原因：注册阶段200 OK里带回了Service-Route和Record-Route，终端维护了Route Set。但某些软终端或定制ROM在掉网重注册后只刷新了Contact，没有刷新Route，INVITE发出时不带Route头，S-CSCF无法定位服务会话控制，只能回403。

解决：在INVITE报文里确认Route头存在且与注册阶段200 OK下发的一致。用sip软电话安卓版做信令测试时尤其要留意这点，这类轻量级SIP客户端往往不做IMS规范里的Route Set持久化。

4.3 VoWiFi场景下“已注册但无法接通”：ePDG接入类型错误

现象：WiFi环境下网络注册状态显示IMS已注册，但拨入方听到“您拨打的用户暂时无法接通”，主叫侧抓包发现被叫的S-CSCF直接拒绝。

原因：VoWiFi注册流程和VoLTE不同，UE要先建ePDG隧道，再通过隧道发起REGISTER。注册请求里的P-Access-Network-Info头携带接入类型，如果值为3GPP-E-UTRAN而实际走的是WLAN，核心网策略会误判用户仍在LTE网络，导致话务路由到错误域。

解决：检查REGISTER报文里P-Access-Network-Info头的值是否与接入环境匹配。VoWiFi注册流程受阻时，抓包点要放在ePDG与P-CSCF之间，而不是只在UE侧看，因为隧道封装后SIP报文的内容在UE侧是IPSec加密的。

4.4 单通问题查到SDP时被假象迷惑：只看codec不看方向和带宽

现象：双方都听到拨号音，但通话建立后一方完全无声音。分析报告写的是“编解码协商一致，无异常”。

原因：编解码一致只是前提。看SDP时漏了a=recvonly和b=AS。当被叫侧终端在做媒体资源预留，回200时可能把方向改成recvonly，主叫侧如果没有在ACK里重新协商，最终媒体流就是单向的。另有运营商IMS对G.711的带宽限制会压低RTP包，导致对端丢包率高，表现也是“无声”。

解决：把通话建立的三条消息（INVITE、200 OK、ACK）里的SDP并列对比，重点看a=方向行和b=带宽行。RTP在Wireshark里显示异常丢包时，优先检查是带宽限速还是抖动缓冲问题，不要一上来就怀疑无线空口。

4.5 SIP over UDP的隐藏致死问题：信令超时与重传风暴

现象：注册和呼叫暂时成功，但偶发“呼叫未接通”和“注册丢失”，抓包看到大量重复的REGISTER和INVITE。

原因：IMS虽然允许UDP传输，但UDP没有确认机制，所有可靠性都靠应用层重传。如果运营商防火墙对UDP会话老化时间设置过短，SIP会话超过NAT超时时间后，后续信令会把包发到一个已失效的会话，所有中间节点静默丢弃。

解决：在SIP层配置把传输协议优先级设为TCP/TLS优先，IMS核心网普遍支持。如果做信令仿真测试，别让脚本里REGISTER的间隔被操作系统TCP拥塞控制影响，改用独立的事务定时器。运营商的语音现网标准和终端的实现有些差异，这类问题靠看frame.time_delta_displayed的重传间隔就能快速识别。

5. 从一段trace穿透端到端链路：用Call-ID关联Gm/Mw接口定位故障

前面几节的抓包基本都在UE侧或单个网元侧，遇到跨网元问题，我会用Call-ID这个字段把一段呼叫串起来。Call-ID是SIP事务的全网唯一标识，从UE发出的REGISTER到P-CSCF再转到S-CSCF，同一个注册流程的Call-ID完全一致。在多个网元侧采集点拿到独立的pcap后，用Call-ID做关联键，就能把同一事务在不同节点的处理时延拆出来。

操作上，我在Wireshark里先把sip.Call-ID设为自定义列，然后对采集点A（Gm口，UE与P-CSCF之间）和采集点B（Mw口，P-CSCF与S-CSCF之间）分别过滤同一个Call-ID，对比两边的抓包时间戳：

sip.Call-ID == "3b2f8a0e-1d6a-4c9f-9e83-9e1f7c5f6a33"

如果Gm口已经收到401，而Mw口没有对应请求，问题在P-CSCF；如果Mw口有请求但没有后续响应，问题在S-CSCF或HSS。这种定位法在vIMS环境里尤其有效，因为所有网元都在同一套虚拟化平台上，采集点布起来很快，十分钟就能判断故障归属。

注册流程验证还有一个习惯，我每次必做：用Wireshark的Telephony菜单里的SIP流图（Flow Sequence）看时序。它自动按时间线排列请求和响应，401重传、事务超时、非标准状态码在流图里一目了然。确认注册畅通后，再用同样的方式打开CALL的pcap，重点看183/180出现的顺序。需要我认真负责地讲一句：IMS信令分析做久了，我的固定动作是拿到pcap先放注册三连件（REGISTER/401/200），再看INVITE里的Route头和一个有效SDP，先确认这两件事，再谈QoS和MOS。这套习惯帮我处理过不少“玄学故障”，也希望能帮到你。

本文还有配套的精品资源，点击获取