【问题现象】
被叫连续收到CALL ID不一致的invite消息,导致呼叫失败.
【原因定位】
问题描述:被叫在上一次在2G完成被叫(CSFB或esrvcc)且正常挂机,返回到4G后,多次收到INVITE消息,终端回invite486(BusyHere)。
问题原因:
分析被叫的信令分析流程:
主叫12:14:07.601发起invite,收到183消息未收到180消息,于12:14:24.775主动上发cancel消息;
被叫侧由于在12:14:06.977和12:14:08.521连续收到两次的invite request,两次invite的callID不同,被叫用invite 486(busyhere)拒绝了第二次的invite request,而第二个invite才是主叫发起的;因为第二个invite被拒绝,导致主叫超时未接通,被叫后发invite 580给第一个寻呼表示资源预留失败。
原因分析:
连续的INVITE是正常TCP重发消息机制引起,导致SBG在TCP发送缓存上重发发送多个未发出的INVITE。
由于上一次被叫切到2G接续,无法回复TCP ACK。在此期间再次呼叫被叫号码的Invite消息于是缓存在了SBG里(TCP协议固有机制),当UE切回到4G后(会保持原来相同的QCI5承载,且IP地址没有变化)回应SBG发出TCPACK确认消息,SBG于是将前面缓存的Invite消息重发到被叫终端,此时多个被叫Invite消息下发时,终端会给其中一个INVITE回复183消息,而其他INVITE回复486。
影响范围:被叫连续收到CALLID不一致的invite消息,导致呼叫失败。
【解决方案】
在爱立信SBG上修改到发送到终端的默认承载协议,不使用TCP协议改成UDP协议,使发送到到被叫终端的INVITE消息默认采用UDP,且符合《中国移动VoLTE SBC测试规范》中SBG侧使用UDP协议的要求。
由于终端侧规范要求针对不同长度的报文选择采用UDP或者TCP,后续也要对TCP重传机制的关键参数进行优化,减少重传次数和重传时间,优化效果待测试验证。
本文整理自网络,文章版权归原作者所有,如有侵权,请联系我们进行删除。小编微信(gprshome201101)
长按下方二维码图片 > 识别图中二维码 > 关注“51学通信公众号”
51学通信接头方式如下: