三星终端打开IPSec时无法建立语音和视频呼叫-

【问题现象】

三星终端打开IPsec时，无法建立VOLTE语音和视频呼叫。

【原因定位】

故障诊断：网络侧抓取log，通过信令流程来看，三星终端无法建立呼叫是由于网络侧没有收到被叫终端侧发送的183：

被叫SBG下发INVITE请求后经过8秒，由于没有收到被叫终端返回的183消息，因而发生超时，网络侧cancel掉会话，呼叫建立失败。
原因排查：鉴于问题仅出现在IPSec打开时，因而从IPSec涉及的加密方式等方面开始相关排查工作。
经与终端厂家沟通，三星终端支持四种IPSec加密方式：aes-cbc、des-ede3-cbc、none、all。

因此，网络侧要求终端分别配置了不同加密算法，并测试不同配置时手机端返回183的情况。经测试，只有终端配置aes-cbc、all（默认是aes-cbc）两种加密算法时，网络侧无法收到被叫终端的183消息。所以必须针对aes-cbc这个算法来重点核查一下终端与网络的适配问题，并进行了如下问题排查步骤：

从IMS网络侧SBG进行了大包ping包测试到enb，没有发生丢包现象，因此排除EPC/IMS网络丢包、导致183消息丢失的可能性。
再而需确认被叫终端确实发出了183消息，这可以通过终端侧的log进行确认。三星终端提供了相关log，证实终端的应用层在收到INVITE后发出了183，但是无法确定底层（传输层）的消息发送情况。此处终端是否真正发出了183消息尚存疑点。
再次在网络侧确查是否收到终端上报的183消息，但由于终端开启IPsec，无法看到具体消息，只能通过大小比对加密的ESP消息包。具体分析如下：

在正常可建立呼叫的情况下，三星采用DES3算法、会话成功，通过信令抓包截图可以看到：
下行情况下（SBG->终端）：

31489行：核心网发给SBG的INVITE消息，大小为1354Byte

31821行：SBG发给终端的ESP消息，该消息大小为1338byte，与核心网可见的INVITE消息对应;

与此类似，上行情况下（终端->SBG）：

31952、32029行:终端发给SBG的两个消息，消息长度很小，都是100byte左右；（预计是对INVITE消息的回应、以及即将发出消息的通知）

32029行：终端给SBG发送了大小为1298Byte的消息，该消息大小和SBG发往核心网的183消息32132行（1514Byte）相似，也可以基本对应；

但对于aes-cbc算法、会话失败的信令截图可以看到：
下行情况下（SBG->终端）：

21111行：核心网发给SBG的INVITE消息，大小为1354Byte

21381行：为SBG发给终端的ESP加密消息，该消息根据长度判断对应为INVITE消息;—-

与正常DES加密情况相同

上行情况下（终端->SBG）：

21612、21867行:终端发给SBG的两个ESP消息，消息长度很小，都是100byte左右；（预计是对INVITE消息的回应、以及即将发出消息的通知）—-与正常DES加密情况相同

之后终端再也没有ESP消息发到SBG；—-对比第一个图的32029行，可以清楚的看到终端再无反应，与正常DES加密情况不同
通过以上对比，我们可以发现网络侧并没有收到MT侧发回给SBG的大小为1300Byte左右的183消息，初步判断终端并没有真正上报183消息。
网络侧与终端再次同步抓包，并通过分享密钥解开加密的ESP包再次确认消息的收发。
从上图解出的信令中可以看到，并没有终端向网络侧发送的大小为1300byte左右的183消息。因此更进一步肯定是终端未发出183消息。
最终终端同意将完整的应用层和传输层log提供出来，与网络侧一同分析。
由终端被叫侧抓到的log可以看到，手机端针对一个大小为1296byte的数据包出现了Packet Too Big的传输错误。

从信令流程及消息包大小分析，此1296byte的数据包即SIP 183消息，由于终端侧的传输层出错，认为该数据包过大，因而该消息并没有真正通过终端发出至网络侧。

原因分析：按照上述排障步骤与终端共同进行问题定位之后，最后与终端厂家达成了一致共识：该问题是由于终端在AES加密方式下认为“消息过大”，没有真正向网络侧发出183而导致业务失败。经终端厂家分析传输层问题后，确认需要终端修改MTU值来完成适配。
【解决方案】

终端通过更新版本并且修改终端MTU值为1500后解决该问题，开启IPSec各种加密配置下183消息均可正常发送至网络侧，呼叫可以成功建立。

本文整理自网络，文章版权归原作者所有，如有侵权，请联系我们进行删除。小编微信（gprshome201101）