【问题现象】

在呼叫时延问题排查中,出现由于invite信令丢失多次重发导致时延过长现象。

【问题分析】

1、抓取UE侧的原始报文,在wireshark中通过 (sip) && (sip.Method = "INVITE")过滤出所有的invite信令,发现UE侧接着发了下图标记的三条一样invite信令(包序号分别为2194、2196、2198,每条invite信令都分成了两片,第一片分别是2193、2195、2197)。在第一条invite 信令前有一个ACK信令(包序号为2192)。

 

对比这三条invite信令,除了IPV6头扩展头的Identification字段不一样(第一个invite信令是的Identification是0x0163,第二个是0x0164,第 三个是0x0165),其它字段都一样。见下图:

 

 

对比源IP与目的IP相同invite信令,可以发现UDP的checksum字段是不一样的,同时IPV6头扩展头的Identification字段也不一样。如下图。

 

2、对比用户面内部抓包工具,通过invite信令字段内容对比找到了一条上图invite信令所在的位置,如下截图:

包序号为350433和350436为PDCP层收到的第一片和第二片invite信令。包序号为350434为GTP层收到的invite信令的第一片,包序号为350437为GTP层收到的invite信令的第二片。包序号为350435和350438为S1口映射出来的第一片和第二片(可以根据GTP头的源端口为2152区别出来,用户面内部抓包GTP层的源端口为20020)。

 

查看基站侧包序号为350434的包,IPV6头扩展头的Identification字段为0x165,说明这条invite消息是UE发送的第三条invite消息。

 

同时对比包序为350434和UE侧2193的码流(第一片),发现两者的data是相同的。同时对比350437与UE侧2194(第二片),发现两者的data也是相同的(请注意,由于UE侧wireshare将第一片和第二拼起来了,所以第二片的data显示是全部invite 消息头部,可以从后面或者中间对码流信息),说明基站侧确实收到一个invite消息,且该消息是UE发送的最后一条invite消息。

 

同时也可以看到350439包是一条release消息,也说明确实有invite信令丢失导致承载释放。那么基站侧有没有收到另外两条invite信令呢?根据UE发送的信令顺序,UE侧在invite 信令之前发送一条ACK信令。在基站侧找到ACK信令的位置,包序号为334285和334286,也是两片。

 

在ACK消息(334285)和invite 消息(350433)中间查找invite消息的头部净荷(49 4e 56 49 54 45 20 73),找不到任何其它数据包。说明基站侧只收到了一条invite消息,其它两条都没有收到。

 

【问题解决】

对比基站用户面内部抓包结果与UE侧的原始报文,UE侧连着发送了三条发送了INVITE SIP信令,而基站侧只有收到一条INVITE SIP信令,另两条INVITE SIP信令在用户面内部各层都没有收到。经高通工程师反馈是芯片问题导致:INVITE SIP信令在UE的应用层到业务层的时候丢了。芯片升级到4.0版本后,INVITE SIP信令丢失问题解决。