简介IMS即IP多媒体子系统是支撑VoLTE等多媒体业务的网络核心控制架构。文档面向从事IMS系统开发、测试与维护的通信工程师基于Android终端抓取的真实信令日志按注册和主叫呼叫两条主线展开重点帮读者理清从终端接入到业务建立的完整信令过程。注册部分依次介绍DS通知IMS其LTE服务可用、IMS获取APN列表和属性、DS触发PDN连接请求、发送SIP注册消息、通知呼叫管理模块注册状态变化等关键环节呼叫部分则围绕IMS MO CALL中的INVITE消息逐项解析呼叫标识、主被叫地址、Via/Contact/Route路由信息、首选标识、允许的方法集合以及会话描述协议中的媒体编解码、远端协商状态等字段并结合具体手机抓包样例说明IPv6地址、SRVCC响铃、AMR-WB等常见问题。压缩包内为单个docx文档共1个文件仅144KB信息密度高已有1539人学习适合需要快速掌握IMS注册信令与SIP呼叫流程的工程师也适合在VoLTE注册失败或呼叫接通异常时作为信令排查的速查参考。1. IMS注册及CALL SIP信令分析先确认你抓到的究竟是注册失败还是注册未完成想象一个常见排障场景终端在现网注册IMS时失败你抓回一个pcap按sip过滤后满屏REGISTER和401。很多人一看到401就开始怀疑网络拒绝但IMS的注册流程里第一次REGISTER收到401才是正常开始——真正的问题藏在第二次REGISTER之后藏在Authorization头、Expires字段、以及那些你容易漏掉的503/423响应里。这篇CALL SIP信令分析笔记不从头讲SIP协议教科书只讲IMS域里怎么读注册和呼叫的SIP信令、用什么工具把信令变成可复现的分析过程、哪些参数直接影响成败、故障往哪查。适合正在做VoLTE/VoWiFi终端调试、IMS语音网关对接或者刚接手SIP信令分析的人。2. IMS注册流程拆解REGISTER事务里决定成败的五个环节2.1 注册状态机与401/407挑战为什么第一次REGISTER必然失败IMS注册的起点是终端构造一条REGISTER请求。Request-URI填归属网络的域名To头填公共用户标识通常是sip:用户域名Contact头填终端当前可达的地址并带Expires表达想注册多久。网络侧收到第一条REGISTER时因为此时还没有任何鉴权信息会回401 Unauthorized并在WWW-Authenticate头里带realm、nonce和算法标识MD5或AKA。这条401不是失败是挑战是SIP协议从无状态到有状态鉴权的必经一步。终端收到401后计算摘要填进新的REGISTER的Authorization头再次发出网络校验通过后回200 OK注册才真正建立。这里有一个新手常犯的误判看到401就当失败去改终端的鉴权配置反而把本来正常的状态机打乱。IMS终端在注册周期里REGISTER(无Authorization)→401→REGISTER(带Authorization)→200 OK是一个完整且正常的序列序列缺失才是问题。再区分401与407401是UAS/注册服务器层的挑战对应Authorization头407是代理层挑战对应Proxy-Authorization头。当信令路径上存在SBC、P-CSCF这类代理时先出现407并不罕见此时检查代理链路和信任域配置比盯着注册服务器更像排障方向。注册用401Authorization呼叫建立或语音邮箱订阅场景常见407Proxy-Authorization。注册状态机本身不复杂Unregistered → 挑战成功 → Registered → 定时刷新 → 续期或注销。抓包时把每条REGISTER的摘要结果按时间排出来状态机每一步对应哪一条消息就一目了然。若401里带staletrue说明nonce过期而不是密码错终端不需要重算口令重新走一次挑战流程即可。2.2 从抓包里读懂Contact、Expires与注册刷新周期Contact头承载终端的可达地址包含IP、端口、transport参数并常带sip.instance终端实例标识与reg-id同实例多注册场景。IMS归属网络会完整保存这份Contact作为注册绑定后续被叫时按它把INVITE路由回终端。所以Contact里的IP写错、端口被NAT改写表现就是“注册显示成功但一呼入就被400/480打回”。Expires决定这条注册的存活时间。IMS现网常见值是600秒或3600秒网络侧允许的最小值由Min-Expires约束。若REGISTER带的Expires小于Min-Expires网络回423 Interval Too Brief若为0则是注销注册常见于终端关机、WiFi断开或VoWiFi功能关闭的流程。终端通常会在Expires过半时发起刷新一条600秒的注册大约在300秒处出现下一次REGISTER这条刷新REGISTER同样要走401挑战吗不一定——如果网络和终端已建立了信任例如AKA鉴权通过且安全联盟仍有效刷新REGISTER可以省略挑战直接回200这是正常现象别当成异常。验证注册链路时我会先看时间线第一条无Authorization的REGISTER到401、到第二条带Authorization的REGISTER、再到200 OK整体应在几十毫秒到几百毫秒内完成。若401和第二次REGISTER之间隔了几秒多半是终端在算AKA向量或等待USIM卡响应这会让注册时延变长但不算故障若REGISTER重传次数过多反而要先怀疑UDP丢包或MTU分片而不是鉴权参数。2.3 用tcpdump和Wireshark过滤器把注册信令从全量流量里拉出来IMS信令通常承载在UDP或TCP 5060端口上加密场景是TLS 5061。抓包时如果只关心注册最好在终端侧或用户接入侧抓命令很简单但有两个点要注意一是-s 0保证抓完整报文SIP头里带SDP时截断会误导分析二是尽量用端口过滤把信令面拎出来别把RTP媒体流也写进同一个文件否则一场一个多小时的通话能撑爆磁盘。# 终端侧抓注册与呼叫信令存成pcap sudo tcpdump -i any -s 0 -w ims_reg.pcap udp port 5060 or tcp port 5060 # 用tshark只看REGISTER事务的帧号、源地址和高层响应码 tshark -r ims_reg.pcap -Y sip.Method REGISTER \ -T fields -e frame.number -e ip.src -e sip.Status-Code -e sip.User-Agent第一条命令中的-i any覆盖所有物理接口尤其适合无线网卡抓包时不确定流量走哪块接口的情况-s 0表示不截断帧抓到的IP报文长度接近实发值过滤条件里的udp/tcp都要写因为IMS现网很可能同时存在UDP信令和TCP信令漏一边就丢了线索。第二条用tshark把每个REGISTER的帧号、源地址、响应码和UA打出来可以快速看出一轮注册的往返节奏和重传情况。如果REGISTER响应码字段为空说明该请求还没等到应答需要回到原pcap里按源目IP查丢包。若嫌命令行输出不直观也可以把pcap拖进Wireshark过滤器填sip.Method REGISTER再右键任意一条SIP消息选择Follow SIP Stream就能看到从REGISTER到200 OK的完整头字段对话。注意Wireshark对SIP的解析依赖sip解码器触发抓包端口若不是默认5060需要在Decode As里手动指定为SIP否则会看到一坨UDP负载。抓包点和解码设置这两个基础动作是注册信令分析最容易被忽略的误差来源。2.4 注册失败快速定位从401到403之间查什么第二条REGISTER收到403 Forbidden时先看响应有没有原因文本再看WWW-Authenticate里声明的算法与终端实际使用的算法是否一致。MD5与AKA不匹配是IMS终端配置错误的高频点终端只能算MD5网络下发的鉴权向量却是AKA参数结果就是RES校验不过、403循环。AKA鉴权还依赖SQN序列号。终端与网络侧SQN偏移超过阈值时网络会判定同步失败并拒绝表现为重启前怎么试都403、重启网络模块后立刻正常。这类问题在长期不关机的终端上尤其突出排障时先让用户开关一次飞行模式往往比反复抓包更快见效。这类“玄学”故障本质是AKA状态机失步不是信令参数错误别在配置文件里白费力气。最后查423 Interval Too Brief把REGISTER里的Expires调大到网络侧Min-Expires以上。这个问题在企业语音网关对接IMS时很常碰到比如网关默认Expires60秒而IMS网络要求至少600秒网关会反复收到“你的注册有效期太短”。很多厂商文档会把这一步写成“增加注册间隔”但实际要改的是SIP注册的Expires参数不是定时器重传间隔。3. 用sngrep把CALL信令变成可复读的通话时间线3.1 为什么选sngrep面向会话而非面向报文的SIP分析sngrep是基于ncurses的SIP抓包和回放工具。它按Call-ID把属于同一通电话的SIP消息聚合到一条会话流里INVITE、100、183、200、ACK、BYE按时间顺序展开比在Wireshark里按时间戳翻几百条报文直观得多。对集中在服务器或网关上做IMS对接的人来说一个不依赖图形界面的工具能省下大量时间尤其是现网服务器通常没有X11转发条件sngrep直接在终端里就能完成“定位→钻取→导出”整个流程。sngrep还能解析SDP并汇总RTP统计对早期媒体不可闻、单通这类问题可以直接在会话详情里看媒体协商结果和实际收发包情况。和Wireshark的分工一般是sngrep负责“快读定位”Wireshark负责“深挖字段”。一条信令在sngrep里看到异常后再导出pcap到Wireshark里查具体头字段两边配合效率最高。若对接的是安卓SIP软电话这类终端sngrep的SDP视图尤其有用可以直接看出软电话报给网络的内网地址。3.2 抓取和回放一条完整CALL命令与参数CALL信令和注册共用5060端口抓包时直接盯SIP端口即可。sngrep支持实时抓包和pcap回放两种模式回放模式非常适合把现网抓到的包在办公电脑上复盘# 实时抓取并把会话列表按Call-ID聚合展示 sudo sngrep -d any -P 5060 # 回放pcap同时保留INVITE起呼与REGISTER注册两类会话 sudo sngrep -r ims_call.pcap -c -f sip.Method INVITE or sip.Method REGISTER-d any抓所有接口-P 5060只关注SIP端口RTP不会冲进列表-c开启同Call-ID着色-r回放pcap-f指定BPF过滤器。进入sngrep交互界面后方向键切换会话回车进入消息详情按s看原始SIP报文按i看媒体信息按r看RTP统计按q退出。抓现网时若担心漏REGISTER就把过滤条件里的INVITE去掉全按端口抓数量大但定位不受影响。实际操作时有个习惯值得养成回放pcap后先看列表里哪些Call-ID没有200 OK再点进去对比是停在183还是被487/480终止。没有200 OK意味着主叫侧没听到回铃音、Call流程多半在等待阶段被释放BYE的Reason头则告诉你是谁挂断的、为什么挂断。sngrep列表页顶部还会给每个会话标注起止时间和消息数消息数异常少的会话往往是丢包或分片造成的值得优先展开。3.3 CALL流程的七条关键消息怎么读才算没有漏一个基本呼叫流程由七条消息组成对照表如下消息方向作用分析要点INVITE主叫→被叫发起会话并携带SDP查Request-URI、Route、SDP的c与m100 Trying被叫→主叫表示请求已收到缺失多半是UDP丢包或代理转发异常180 Ringing被叫→主叫被叫振铃不必带SDP本地回铃音由主叫侧生成183 Session Progress被叫→主叫早期媒体协商必须有SDP无SDP的183要排查200 OK被叫→主叫会话建立成功携带最终SDP紧跟ACK后通话开始ACK主叫→被叫确认200 OK由主叫发本身没有SIP响应BYE任一方向结束会话查Reason头定位挂断方和原因很多现网问题就藏在180和183之间。某些被叫网关彩铃和回铃音混在一起183里带了SDP但主叫终端没有按早期媒体处理用户听到的是一段“静音彩铃”直到接通才有声。分析时在sngrep的会话详情里找183这条消息确认Content-Type是否为application/sdp、SDP里有没有完整的maudio行以及语音编码是否双方都有交集。双方编解码无交集时会回488 Not Acceptable Here这种情况在IMS对接初期非常常见。另一类容易被忽视的消息是100 Trying。IMS核心网里100由P-CSCF或S-CSCF生成表示请求已经进入处理流程如果INVITE出去后连100都没有优先怀疑网络路由不通而不是被叫方问题。同理看到180后长时间没有200或486优先查被叫域的终端状态通知而不是反复刺激主叫侧。CALL信令分析里最忌讳的就是只看主叫侧的半段消息就下结论跨域对接时被叫侧抓包往往才是真相所在。3.4 当媒体面黑匣子打开时SDP里的IP端口与RTP统计SIP信令里携带的SDP描述了媒体面的流向。拿到SDP先看两行c连接地址和m媒体行含端口和编解码然后把它们与终端实际发出的RTP源地址对比。NAT场景下SDP里地址往往与实际RTP地址不一致若不一致媒体流就发不到对端或对端不回包最终表现为单通或双不通。sngrep的RTP统计给出收发包数、丢包率、抖动和基于编解码的MOS估算。注意MOS只是估算算法对G.711和AMR的假设不一样别当成用户感知的绝对等级。我一般把RTP统计当作“有没有流、往哪流”的判据再回到SDP判断路由是否对称。不对称路由信令走A路径、媒体走B路径在跨域IMS对接时常见直接结果是媒体被防火墙丢掉此时修改点往往在路由策略而不是SIP参数。对安卓SIP软电话这类轻量终端SDP里的IP经常写的是内网地址必须配合STUN或网关的媒体代理功能才能通话这也是软电话在WiFi下“注册正常、呼叫不通”的高频根因。4. IMS信令必调参数五组决定注册和呼叫成败的字段4.1 注册里的Path与呼叫里的Route谁在转发、谁在路由Path头是IMS注册阶段的特色参数。网络侧代理SBC/P-CSCF收到REGISTER时会插入Path通知归属网络“以后往这个地址转发”。终端侧不需要自己填Path但在后续刷新REGISTER里必须原样携带网络侧下发的Path值否则注册绑定会丢失。分析刷新类REGISTER时可以对比两次Path头是否一致不一致就说明终端或中间设备的拓扑隐藏逻辑有问题。Route头决定单个请求的转发路径。发起INVITE时终端用Route指向P-CSCFP-CSCF再按网络预置路由指向S-CSCF。抓包时若发现INVITE绕过P-CSCF直达被叫域最直接后果是PAI、计费头缺失被叫返回403。企业网关或路由器上配置set sip voice trunk ims on router这类SIP trunk时核心就是把出局INVITE的Route固定成P-CSCF地址注册能过但呼叫不通的场景九成出在Route和注册绑定不一致。4.2 P-Asserted-Identity与Privacy主叫号码从哪来PAI头由信任域的代理P-CSCF/S-CSCF插入表示已经网络侧确认的主叫公共用户标识。排查来电显示异常时PAI比From头可靠From可以由终端随意填写PAI则是网络侧依据注册绑定改写的。终端若不想被显示号码会在请求里带Privacy: id网络侧看到这个值会限制对端呈现主叫号码。对接IMS时经常要处理tel URI和SIP URI两种格式PAI里是tel:86138...还是sip:86138domain直接影响对端号码解析。很多“号码被吞”的问题其实是PAI里的tel URI与国家码格式不匹配。再往边上说P-Charging-Vector头用于计费关联不参与呼叫接续但话单对不上时要先查它是否被中间设备剥离。这三个头是IMS信任域的标志性头字段如果从SBC出去后PAI和P-Charging-Vector丢失基本可以判定SBC的信任域配置没做对。4.3 Session-Expires与Min-SE会话存活的生命线Session-Expires表示一个会话在无媒体活动的情况下能存活多久到期前由刷新方发UPDATE或re-INVITE续期。IMS常用默认值是1800秒Min-SE约束最小值。发起INVITE时主叫方在头里带Session-Expires: 1800; refresheruac被叫支持就正常继续不支持就回422 Session Interval Too Small并给出网络侧要求的Min-SE。静音但不挂断的通话能够保持几小时靠的就是这个刷新机制。出现“通话恰好到整点自动断”的现象时先在抓包里找会话建立后约1800秒处有没有UPDATE或re-INVITE有刷新但没收到200 OK说明刷新请求被某层静默丢弃会话到期后网络侧就会发BYE强制结束。做VoWiFi对接时还要注意终端可能同时存在多个注册和会话Session-Expires的刷新必须走与该会话相同的Route路径否则SBC会认为刷新不合法。4.4 Allow、Supported与Require100rel和UPDATE能不能用这三个头决定SIP扩展协商。Require: 100rel表示本端必须收到PRACK确认才继续典型用途是183早期媒体。对端不支持时应回420 Bad Extension并列出Unsupported值如果对端假装支持但不回PRACK早期媒体卡住表现是“彩铃听得见、接通后双不通”。分析时先确认Require/Supported里有没有100rel再查PRACK是否发出、是否收到200。Allow头列出支持的请求方法如INVITE、ACK、BYE、UPDATE、PRACK、INFO。会话刷新依赖UPDATE时如果对端Allow里没有UPDATE就会出现刷新请求被405 Method Not Allowed死死卡住的问题。更新一些老旧的SIP网关固件Allow列表会变得更完整这类问题常常因此“莫名其妙”就好了——其实就是能力协商从不通变成通了。IMS注册还涉及IPsec安全联盟抓包时若大量SIP消息显示为ESP且无法解析先别急着怪抓包工具先确认终端是否已建立IPsec SA或尝试关闭IPsec后对比。4.5 Expires与呼叫建立时延的折中注册刷新周期Expires调短网络侧绑定更新及时适合终端频繁移动的场景调长可以减少注册风暴适合大量终端的网关场景。但Expires过长会拉大终端与网络侧的失同步窗口WiFi切换或断电后网络侧仍认为终端在线被叫呼入会被转发到一个已经不可达的Contact直到注册超时。IMS现网终端多数设600秒上下同时配合Contact里的reg-id做多路注册来缓解切换问题。呼叫建立时延的瓶颈通常在鉴权与100rel交互REGISTER 401到REGISTER 200 OK的计算耗时、INVITE到183再到PRACK的往返都直接影响拨号音之后的等待时长。做终端侧优化时我会分别统计“REGISTER 401到REGISTER 200 OK”与“INVITE到183”两个间隔前者超过一个RTT加AKA计算时间的数倍优先查终端卡处理后者超时优先查AS或被叫域。参数折中没有绝对最优解能给出可量化的间隔数据再谈调参才有意义。5. IMS信令分析避坑五个高频故障从现象到原因再到解决5.1 现象REGISTER一直401循环从未出现200抓包看到401后终端重新发REGISTER但仍回401且多轮重复。先区分是鉴权失败还是重传风暴看第二条REGISTER有没有Authorization头。没有说明终端根本没解析401或解析失败有但仍401就是网络侧校验不过。校验不过时优先查时间与SQN同步AKA鉴权依赖UE与HSS的SQN长时间不关机的终端SQN落后网络会检测到失步并拒绝。解决是让终端重新开关一次飞行模式重取同步或在HSS侧重置鉴权向量。若抓包显示401里nonce已过期也要先核对终端时间对不对终端时钟漂移超过容限时AKA和nonce校验都会出问题。5.2 现象INVITE发出去之后收到487 Request Terminated487表示呼叫被中间实体终止。先看487的Reason头它由终止方填写能区分“被叫主动拒绝”和“网络超时释放”。常见两类一是被叫域处理超时AS查询被叫状态超过定时器后释放二是被叫终端先拒绝代理把486/603转换成了487。只看状态码无法区分必须把同一Call-ID的后续消息和Reason头一起读。还有一种情况是主叫侧自己超时取消则抓包里先有CANCEL再有487问题的根因要往前找回看INVITE发出后超过多少秒没等到非100响应。这种场景里修改主叫侧的T1/T2定时器或网络侧的会话定时器比动被叫侧更有效。5.3 现象信令正常、电话接通了但双不通或单通信令面全绿不代表媒体面通。先拿sngrep看RTP统计确认有没有双向RTP流再看SDP的c行和m行与真实RTP源IP端口是否一致。若SDP里写内网地址、又没有对应NAT映射媒体流自然发不到对端。高频翻车点是防火墙上的SIP ALG把SDP改写坏了或ALG只改了信令没改媒体映射。解决关掉SIP ALG、改用固定端口映射、让终端开启对称RTP并检查STUN配置。安卓SIP软电话这类轻终端在WiFi下尤其容易踩这个坑因为SDP里暴露的往往不是公网可达地址。若RTP统计显示单方向有流而反向为零再看回包地址是不是去了另一个端口这种不对称通常是NAT会话老化或路由策略导致的。5.4 现象注册成功刚拨出就挂断BYE后面跟403注册200 OK正常INVITE也到达被叫但通话建立后立刻BYEBYE之后有403。先看BYE的发起方和Reason被叫侧发起查被叫收到的INVITE里的PAI、Privacy和SDP是否被中间设备改写网络侧发起优先怀疑IPsec SA过期或会话刷新失败。实践中更常见的根因是INVITE没有走注册时协商的Path/Route路径SBC按绑定表查不到合法转发路径于是当作非法呼叫处理。解决思路是让终端或网关严格按注册时确认的Route/Path转发INVITE并核对SBC上的注册绑定是否存在、是否过期。有些SBC对未知域呼出直接回403而不是404目的就是避免暴露内部拓扑别被这个行为误导到鉴权方向上去。5.5 现象一些海外机型在非官方网络显示“无法注册IMS”比如Pixel类机型在非运营商官方网络下注册不了IMS典型表现是状态栏不出现VoLTE/VoWiFi图标抓包只看到REGISTER或根本发不出REGISTER。这类问题多数不是信令错误而是网络配置没下发IMS APN缺失、MCC/MNC与网络侧不匹配、VoWiFi配置未被推送。排查先看REGISTER请求里的Domain字段是否匹配当前SIM卡的MCC/MNC如果终端连REGISTER都没发就先查IMS APN和“WiFi呼叫”开关开启后等待网络侧推送配置。在VoWiFi注册流程里配置下发的先后顺序很关键——先有PDN连接和配置然后才有REGISTER只对着信令反复分析容易白忙一场。遇到“状态栏无图标、终端不发注册请求”的机型先放弃信令分析回到APN和运营商配置维度排查。6. 进阶把CALL里的隐形事务挖出来——PRACK、UPDATE与Rel100当会话带早期媒体或需要刷新时除了INVITE、200、ACK、BYE这条主干还会有PRACK和UPDATE两个容易被忽略的事务。PRACK是100rel扩展的确认消息专门确认183这类临时响应UPDATE则用于在已建立的会话中修改媒体参数和re-INVITE功能重叠但语义更干净很多现网网关只用UPDATE做会话刷新而不发re-INVITE。排障时我会先把这两个方法单独滤出来看# 把一次CALL里的PRACK和UPDATE提炼出来按帧号输出 tshark -r ims_call.pcap -Y sip.Method PRACK or sip.Method UPDATE \ -T fields -e frame.number -e sip.Method -e sip.CSeq -e sip.RAck -e sip.FromPRACK要和它确认的183对应着看PRACK的CSeq数值应等于183的CSeqRAck头里包含被确认临时响应的序号和方法。如果183发出了而PRACK没回或被叫收到PRACK后没有200早期媒体链路就断了用户听到的彩铃或回铃音可能时有时无。UPDATE的分析则重点看SDP它携带的媒体参数应当与最近一次协商一致不一致的UPDATE会被回488导致客户端在切换WiFi与蜂窝后没有声音。还有一个阅读信令的习惯想分享我每次做IMS信令分析一定先看注册事务是否构成完整闭环REGISTER→401→REGISTER→200再看呼叫的CSeq是否连续再查Expires和Session-Expires是否会在分析窗口内到期最后才打开媒体面统计。这个顺序帮我排掉过很多次“看起来一切正常”的故障——许多看似诡异的问题其实只是CSeq断了、刷新到期了、或者非官方网络的VoWiFi配置根本没下发。希望帮到你。本文还有配套的精品资源点击获取