简介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地址通过ePDGVoWiFi场景或LTE默认承载找到P-CSCF之后才进入SIP信令阶段。P-CSCF发现通常走DNS NAPTR/SRV查询域名类似ims.mnc001.mcc460.pub.3gppnetwork.org返回的是支持SIP的传输协议和端口。这一步经常被忽略但它是“注册不了”的第一个高发原因DNS返回了错误地址或者防火墙只放行了UDP 5060导致REGISTER发出后石沉大海。IMS的鉴权走的是RFC 3329与AKAAuthentication 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阶段那么多样但每个状态码背后的原因差异很大。下表是现场最常遇到的几类状态码含义第一排查点401 Unauthorized需要鉴权正常流程的一部分是否出现了第二次REGISTER403 ForbiddenAKAIK鉴权失败或用户未开通VoLTEHSS中IMPI/IMPU绑定关系USIM鉴权参数404 Not FoundP-CSCF/S-CSCF找不到服务域名或用户DNS返回的P-CSCF地址Request-URI归属423 Interval Too Brief注册间隔太短网络拒绝刷新Contact头里的expires参数是否低于网络最小值500 Server Internal ErrorS-CSCF或HSS内部异常核心网侧日志用户数据缺失时最常见我见过最典型的翻车是测试终端第一次REGISTER后收到401但没有自动发第二次REGISTER。查抓包发现401的WWW-Authenticate头里没有autn参数或者终端的USIM卡是普通数据卡而非VoLTE签约卡。这种问题在模拟器里用“空鉴权”跑惯了的人一上真实网络就被打回原形。建议在验证AKA流程时先确认Authorization头里的response字段每次都在变化否则说明终端压根没有参与挑战网络自然不认。3. 深挖CALL信令INVITE的SDP协商、状态码与RTP接续对照3.1 主叫接续的完整SIP信令链从INVITE到BYEIMS注册成功只是拿到入场券真正的考验在CALL阶段。一次最简单的VoLTE呼叫信令链是主叫发出INVITEP-CSCF返回100 Trying被叫振铃时回180 Ringing被叫接听后回200 OK主叫回ACK通话结束后任一方发BYE对端回200 OK。如果开了Precondition还会看到183 Session Progress和PRACK/200 OK的握手那是IMS里做资源预留时的额外环节。我在分析INVITE报文时必看四个头域Request-URI是否是被叫的tel URIE.164格式例如tel:8613912345678Route头里是否带着注册阶段网络下发的Route SetP-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.ptsip.Route字段能直接反映核心网下发的路由路径如果INVITE里没有Route头或者Route头里只有一个IP而没有sip:origscscf这类域名基本可以断定终端没有维护好注册阶段获得的Route Set呼叫会被S-CSCF拒绝或导致路由环路。3.2 SDP协商与编解码错位488和单通都从这里来SDP协商是CALL信令里最容易出问题的区域。主叫在INVITE里发SDP offer被叫在200 OK里回SDP answer双方必须在公共编解码集合里选一个。一个典型的IMS语音offer长这样maudio 49152 RTP/AVP 97 98 3 0 artpmap:97 AMR-WB/16000/1 artpmap:98 AMR-WB/16000/1 artpmap:3 GSM/8000/1 artpmap:0 PCMU/8000/1 aptime:20 asendrecv bAS:24.6这里的bAS:24.6代表音频带宽上限为24.6kbps对应AMR-WB 12.65kbps编码。如果网络侧只放行AMR-WB而终端offer里把PCMU放在最前面优先级最高可能被对端回488 Not Acceptable Here。我曾排查过一起“主叫听得到、被叫听不到”的单通抓包显示被叫回的200 OK里maudio行没有artpmapWireshark直接把它标成无效payload类型终端只能静默发送。遇到单通和编码问题把SDP的m行、artpmap、asendrecv/recvonly、b参数四个值拉出来对照就够。多数单通的根因不在SIP头而在SDP的recvonly如果被叫回的是arecvonly说明被叫侧资源预留失败主动方只收不发。3.3 CALL阶段状态码的会话断点定位CALL阶段的状态码比注册阶段复杂但它能直接告诉你呼叫断在哪一步状态码触发节点下一步看什么404 Not FoundS-CSCF/E-CSCF被叫号码前缀分析是否号码搬迁未同步480 Temporarily Unavailable被叫P-CSCF被叫是否离线是否启用了呼叫等待486 Busy Here被叫终端被叫在忙结合History-Info看是否做了前转488 Not Acceptable Here任意节点SDP协商失败对比offer和answer的codec603 Decline被叫终端被叫主动拒接检查被叫侧UI日志还有一类是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响应的algorithmAKAv1-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没有刷新RouteINVITE发出时不带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时漏了arecvonly和bAS。当被叫侧终端在做媒体资源预留回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设为自定义列然后对采集点AGm口UE与P-CSCF之间和采集点BMw口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。这套习惯帮我处理过不少“玄学故障”也希望能帮到你。本文还有配套的精品资源点击获取