精品案例_SIP487的VoLTE未接通处理
VOLTE异常事件典型案例分析
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。
此处属于测试软件问题，应该予以剔除。
（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。
2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。
案例-与IMS网络交互异常导致VOLTE未接通处理
案例-与IMS网络交互异常导致VOLTE未接通处理芜湖与IMS网络交互异常导致VOLTE未接通案例【摘要】无线链路失败，完整性保护失败，切换失败，与核心交互异常等情况都会导致volte 未接通或者掉话的情况，这些都会直接的影响到用户使用的感受和系统的性能。
本文是分析与核心网交互异常导致的异常未接通情况。
【关键字】IMS 未接通【故障现象】当UE行驶至赭山路附近，主叫叫占用WH-市区-同庆楼赭山路店（紫津店）-445556-54起呼，随后UE向核心网发Active Dedicated EPS Request命令请求，随后Active Dedicated EPS Success,但是紧接着就发生了Outgoing Blocked Call（主叫未接通）。
第1页, 共7页【告警信息】对周边小区进行告警查询，无影响业务异常告警。
【原因分析】（一）VOLTE基本流程和信令解释如下：第1页, 共7页（二）volte未接通分析流程如下：第1页, 共7页（三）未接通见原因：1、无线侧问题1）信号覆盖质量差通过log查看，rsrp=-64.88，sinr=15.6,信号很好，不存在信号覆盖质量差的原因，因此排除覆盖差、无线环境差导致的未接通。
第1页, 共7页2）参数设置问题通过后台网格核查该站点的参数设置，发现该站点的参数设置符合省公司标准，且与周边站点设置一致。
3、核心网问题第1页, 共7页从上面信令流程可以看出，被叫未收到IMS的Prack消息，同时被叫也没有发送200OK【解决方法】该问题初步怀疑是核心网侧的问题，应从核心网侧查找问题，并解决。
本次测试，log信令里面还出现了大量的NB-IoT的信令，也可能是测试设备解析出现了问题。
【结论与推广】此问题主要是主叫与核心网侧交互出现了问题导致未接通。
在处理volte问题时，我们应从无线侧、参数设置与核心网等多方面进行排查，发现问题根源后，应及时解决，以保证volte业务的时时畅通。
全网VOLTE终呼未接通分析案例分析
终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。
终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。
被叫上发的183里不携带SDP信息，正常的是会携带Session Description Protocol 信息的，导致SBC不发起承载建立。
主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。
1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMedia Attribute (a): curr:qos local sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local sendrecv| | Media Attribute (a): curr:qos remote none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote none| | Media Attribute (a): des:qos mandatory local sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv | | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 但在终端返回的183和update 200ok消息中，终端没有完成承载预留Media Attribute (a): curr:qos local none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local none| | Media Attribute (a): curr:qos remote sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote sendrecv| | Media Attribute (a): des:qos mandatory local sendrecv| | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv| | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。
VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例
广东茂名+ VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例目录利用VOLTE-SIP协议分析优化VOLTE网络总结创新案例............................错误!未定义书签。
一、概述 (3)二、创新方案 (3)2.1技术原理 (3)2.1.1 SIP协议定义 (3)2.1.2 SIP协议主要概念模型 (5)2.1.3 SIP协议主要消息 (8)2.1.4 消息格式 (13)2.1.5 SIP协议主要响应码 (16)2.1.6 SIP呼叫过程实例 (17)2.2 SIP协议异常原因优化指导 (18)2.2.1网络侧下发503问题分析 (18)2.2.2呼叫前转号码签约SIP格式，前转失败 (19)2.2.3 CSCF返回的RTA消息报错 (19)2.2.4 呼叫转移失败 (19)2.2.5注册失败，ims回500错误 (20)2.2.6 SIP平台拒绝主叫的INVITE呼叫请求 (20)2.2.7 SIP呼叫主叫用户无法听回铃音 (21)2.3 茂名VOLTE经典问题分析 (21)2.3.1QCI1建立与切换流程冲突，核心网下发INVITE503问题 (21)2.3.2无线信号环境差导致网络侧未收到BYE200 (23)2.3.2 核心网信令丢失导致未收到寻呼 (25)三、经验总结 (26)VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例【摘要】本文主要论述通过对VOLTE的SIP协议信令分析对VOLTE问题进行原因挖掘分析，总结出VOLTE优化过程中所遇到的各类异常SIP协议消息的处理思路与方法，优化网络，提升volte用户感知。
【关键字】VOLTE异常事件、SIP消息、响应码【业务类别】VoLTE、流程类一、概述VOLTE日常分析优化过程中经常会遇到出现注册异常、掉话、未接通等异常事件，而L3信令用于呈现的是SIP消息响应码，信令分析时，正确解析L3中的SIP请求或响应码是分析问题的关键，现就前期遇到的异常响应消息进行总结，与大家分享。
精品案例_TAC设置不合理导致VoLTE未接通
TAC设置不合理导致VoLTE未接通目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)TAC设置不合理导致VoLTE未接通【摘要】随着VoLTE业务的不断推广，VoLTE用户数逐步增加，VoLTE业务的感知成为关注的焦点。
经过几个月的不断优化，铜陵VoLTE网络掉话率逐步减少，但是未接通现象仍时有发生。
为提高用户的VoLTE通话感知，需时刻关注未接通发生的原因，逐步解决，提升接通率，保障用户通话感知。
【关键字】VoLTE 未接通【业务类别】VoLTE、参数优化一、问题描述RCU设备在铜陵铜官区北京东路上进行VOLTE路测时，主叫起呼发出Invite消息后，在收到核心网响应Trying 100之前,先收到了核心网下发的RRC Connection Release消息,RRC连接释放后,接续被终止，出现了未接通事件。
二、分析过程通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从TL-市区-康复中心-HFTA-448900-53小区（PCI：210）重选至TL-市区-市二院-HFTA-448913-54小区（PCI：356小区），由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。
然而Invite上发0.172s后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫同时释放，从而导致了Blocked Call事件的发生。
三、解决措施由于TL-市区-康复中心-HFTA-448900-53小区的TAC设置为28035，TL-市区-市二院-HFTA-448913-54小区的TAC为28039，两个小区之间正好处于TAC边界。
该路段是一段长距离的连续下坡，车速较快，TAC更新引起此次未接通。
案例-VOLTE未接通分析案例
VOLTE未接通分析案例摘要：市区2.1G覆盖不连片导致的邻区干扰对VOLTE呼叫建立成功率和掉话影响较大关键字： VOLTE未接通 2.1G【故障现象】：汤王大道玉兰苑向北， 16:36:45.596主叫起呼随后信令正常交互至prack200，在16:37:05.391发cancel取消通话，此时统计为主叫未接通。
主叫占用BZ-市区-建安中学-HFTA-439095-50（RSRP=-63,SINR=17.3）。
【原因分析】：volte呼叫信令说明如下：1．1到6，UE起呼，UE高层协议层需要发送INVITE到IMS，触发RRC连接、安全模式等过程，并通过RRC重配置消息建立SRB2信令无线承载、恢复QCI 5承载，配置测量控制，IMS收到主叫的INITE消息，开始寻呼，并发送INVITE 100（TRYING）给主叫UE，用于响应INVITE 消息，INVITE消息中包含呼叫类型、主被叫的号码、主叫方支持的媒体类型和编码等；2．7到15，核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户，被叫UE收到寻呼后，触发RRC连接、安全模式等过程，被叫通过RRC重配置消息建立SRB2信令无线承载，CN侧通过QCI=5的RB向被叫发送INVITE消息，UE收到后发送INVITE 100消息进行响应，同时被叫发送INVITE 183消息给CN表示会话正在处理，启动Precondition(资源预留)过程，并通知主叫自己所支持的媒体类型和编码，并建立起QCI=1的承载；3. 16到17，IMS收到被叫的INVITE 83 后，对主叫启动Precondition(资源预留)过程，通过EPC通知主叫SM层建立起QCI=1的承载后，向UE发送INVITE 183消息；4．18到25，主叫向被叫发送PRACK消息，PRACK过程是一个预确认过程，主要为了防止会话超时及拥塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，发送UPDATE消息，进行媒体格式协商过程，被叫通过UPDATE 200返回协商结果；5. 26到31是振铃接听过程，被叫发送INVITE 180给主叫，振铃，摘机后发送INVITE 200给主叫，主叫返回ACK进行确认，通话完全建立，进入通话过程；6. 32到37为挂机过程，通话结束后，主叫发送BYE请求结束本次会话，IMS服务器给被叫发送BYE,请求结束本次会话，被叫挂机，回BYE 200消息，核心网IMS服务器给主叫发BYE 200，标明会话结束，主被叫分别去激活EPS专用承载消息，删除QCI=1的数据无线承载。
Volte掉话案例(参数指向错误)
Volte掉话案例在对已经升级为14.3版本的网格10进行拉网测试时发现，仍出现主叫与被叫先后上发BYE，去激活专用承载后收到BYE487导致掉话问题，具体情况如下：被叫，主被叫先后发起Bye消息，去激活专用承载后，网络侧下发Bye 487导致掉话（截图如下）：（A）核心网消息跟踪上看，被叫在15:35:51.470先上发BYE，核心侧未等到主叫回BYE200，就在15:35:51.556又收到主叫上发的BYE消息。
导致核心侧发BYE487：Glare BYE condition encountered，原因：在下发一个bye请求(来自被叫)，但还没有收到应答，收到一个上行的bye请求（来自主叫）。
（B）之前已经出现BYE487掉话的问题，是因为与华为站点的PDCP-SN-SIZE设置不同导致的掉话，但是网格10进行升版之后已经全部修改一致。
为了对问题更好的定位，次日我们对网格10又进行了一次拉网测试，并留意观察在掉话之前是否有声音以最终确定问题现象与PDCP-SN-SIZE导致的问题是否一致！结果发现在BYE487问题导致掉话前10s是没有声音的。
所以依然是单通和不通导致的掉话。
在对拉网数据进行分析时发现，在黄浦路二试扩L-1小区下进行起呼时在下发重配消息中的PDCP-SN-SIZE还是12bit。
（C）所以我们再一次进行了参数的核查，发现14.3版本的站点的应该和LR13.3一样指向DedicatedConf/0 PdcpConf/1，因为DedicatedConf/0 PdcpConf/2中定义的PDCPPDUSNSIZE=12,所以指向到了DedicatedConf/0 PdcpConf/2，就出错了。
截图如下：（D）最终核查结果又一百多个站点的指向错误，在修改指向后进行了复测，BYE487掉话没有出现。
精品案例_电信Volte用户异常掉话故障排查案例
精品案例_电信Volte用户异常掉话故障排查案例Volte用户异常掉话故障排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)宣城电信Volte用户异常掉话故障排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB 异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。
【关键字】VoLTE 掉话专用承载【业务类别】VoLTE、掉话一、问题描述3月23日对宣城电信市区的主要路段进行了VOLTE业务拉网测试。
统计分析指标时，按照省公司下发的VOLTE业务能力测试规范统计指标时，发现1处掉话测试UE在其他基站可以正常进行VoLTE呼叫，基本可以排除测试UE的问题。
并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。
由于之前一直未查出原因，现场还进行数据重新制作，也未能解决。
二、分析过程按逻辑时间在MS1信令中查找该问题点，是一条RRC连接释放消息，如下图：向上查找，在22:53:13:452时刻发现DEACTIVATE EPS REQ （EPS承载去激活请求）消息，并得到了网络的响应（DEACTIVATE EPS ACC）。
继续向上查找，发现在22:53:13:392时刻MS1收到了BYE 500 Service Internal消息，如下图：查看消息体（下图），该消息为网络下发给UE的（Network to UE）,告警正文中显示无法收到对端（MS2）的响应（No Response From Peer）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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用户的使用感知。