精品案例_SIP487的VoLTE未接通处理

SIP487的VoLTE未接通

目录

一、问题描述 (3)

二、分析过程 (4)

三、解决措施 (7)

四、经验总结 (8)

SIP487的VoLTE未接通

【摘要】本文分析于4月24日出现的VoLTE未接通的工单，发现18:30到19:00期间RCU1197设备产生大量未接通，对数据进行详细分析为设备吊死导致。

【关键字】VoLTE 未接通 SIP 吊死

【业务类别】优化方法

一、问题描述

问题发生过程中，终端由宁芜高速向南京行驶，行驶到南京境内后再由宁芜高速返回马鞍山，RCU1197设备4月24日18：30至19:00产生大量未接通事件，且未接通为全程存在。

图1：未接通事件截图

二、分析过程

图2：18:31:28起呼的未接通情况

核查相关基站，基站无告警和故障，底噪正常，负荷水平也较低，查询扇区性能指标，无线接通率和掉话率正常，无明显波动和异常。

图

图3：未接通占用扇区性能指标情况

问题数据未接通事件较多，选取18:31:28起呼的未接通事件进行分析。18:31:28.230进行起呼，占用MA-市区-昭明派出所-ZFTA-443830-51，RSRP-97dBm，SINR在10dB，信号良好。

图4：VoLTE信令流程

图5：18:31:28未接通的事件和信令详情

对呼叫流程和信令进行详细分析，18:31:28.230发起起呼后，18:31：38.351发起IMS_SIP_INVITE->Request，18:31：38.398收到Try100信令，随后在18:31：48.136收到INVITE 183消息，并在18:31：48.202上报PRACK，在18:31：48.234收到PACK200,。然后在18:31：58.198上报SIP_CANCEL信令，上报原因为IMS_SIP_INVITE 487。

图6：IMS_SIP_INVITE 487信令详情

对IMS_SIP_INVITE 487详细分析，其中Warning上报原因值为Cancel received on initial invite，表示请求被BYE或者CANCEL所终止。

图7：主被叫呼叫过程信令对比

对主被叫信令进行对比，发现被叫在18:31：38至18:31:58期间虽然有paging信令，但是未

发起寻呼流程，故主叫在18:31：58.198收到的SIP_CANCEL信令为超时导致主动释放。

主被叫呼叫时无线环境均良好，不存在质差等网络问题。主叫在118:31：38.398收到Try100信令，在10s后的18:31：48.136收到INVITE 183消息，并立刻上报PRACK，在18:31：48.234收到PACK200,。但是又经过10s无响应，故在18:31：58.198已经到了20s时限，主动上报CANCE。由此过程可以发现，主叫端信令流转正常，但是在收到信令上时延较大。故主要查询被叫测问题。

图8：18:28:50主被叫时间详情

主叫侧每20s发生一次呼叫，20s后超时主动释放，但是被叫侧无响应，由此怀疑为设备问题导致。

三、解决措施

4月25日对1197设备RCU进行重启后，该设备未发生连续未接通现象，设备恢复正常，故此次问题应该为RCU1197在4月24日18:28吊死导致主叫呼叫无响应，判断为未接通。

图9：重启后设备路测情况

四、经验总结

虽然此次未接通为设备问题导致，但是随着VoLTE用户的不断增长，话音业务不断落到4G承载，需要密切关注VoLTE的各项性能，以提升VoLTE用户的使用感知。