终端侧Invite信令丢失导致呼叫建立过长

【问题现象】
在呼叫时延问题排查中，出现由于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信令丢失问题解决。