精品案例_SIP487的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未接通案例【摘要】无线链路失败，完整性保护失败，切换失败，与核心交互异常等情况都会导致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业务的时时畅通。

终呼未接通分析基于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网络总结创新案例............................错误!未定义书签。

一、概述 (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未接通目录一、问题描述 (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未接通分析案例摘要：市区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掉话案例在对已经升级为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用户异常掉话故障排查案例目录一、问题描述 (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）。

VoLTE未接通分析优化处理【摘要】：8月份省公司组织VoLTE对标拉网测试，在进行LOG分析时，发现一部分未接通是由于在切换过程中发起了业务起呼，最终造成语音未接通。

分析得出主要因为切换和语音建立冲突，造成VoLTE的QCI=1的承载异常释放造成，通过调整呼叫过程中切换延时定时器解决此问题。

【关键字】切换承载释放【故障现象】：8月份省公司组织进行VoLTE拉网测试，分析LOG时发现很多未接通发生在切换过程中，如下图。

图1：主叫未接通截图【原因分析】：对LOG进行分析处理，发现主叫于11:21:22.901发起起呼。

图2：主叫起呼然后在11:21:23.103承载建立成功。

图3：承载建立完成最终在在一次切换后上报未接通事件，同时反馈SIP 503信令，被叫反馈SIP 580信令。

图4：主叫未接通上报SIP 503 图5：被叫上报SIP 580查询资料得知在VoLTE未接通发生事件中，存在切换和建立冲突导致的未接通，主要原因有2个：1、主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，导致专载被释放，终端回复invite580，呼叫未接通，具体原因如下：终端建立专载成功，回复重配完成并上发NAS确认消息，但基站CTS信令显示NAS消息没有收到，造成切换中MME发给目标小区的HandoverRequest消息里面e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。

2、主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，导致专载被释放，终端回复invite580，呼叫未接通，具体原因如下：终端建立专载成功，回复重配完成并上发NAS确认消息，基站CTS信令显示NAS已收到并上发给MME，但由于切换流程在前，MME收到NAS消息之前，MME已经发给目标小区的HandoverRequest消息，里面e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。

全网V O L T E终呼未接通分析案例分析LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。

终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果终端返回的183消息中不携带SDP，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。

被叫上发的183里不携带SDP信息，正常的是会携带SessionDescriptionProtocol信息的，导致SBC不发起承载建立。

主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。

1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMediaAttribute(a):curr:qoslocalsendrecv||MediaAttributeFieldname:curr||MediaAttributeValue:qoslocalsendrecv||MediaAttribute(a):curr:qosremotenone||MediaAttributeFieldname:curr||MediaAttributeValue:qosremotenone||MediaAttribute(a):des:qosmandatorylocalsendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatorylocalsendrecv||MediaAttribute(a):des:qosmandatoryremotesendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatoryremotesendrecv但在终端返回的183和update 200ok消息中，终端没有完成承载预留MediaAttribute(a):curr:qoslocalnone||MediaAttributeFieldname:curr||MediaAttributeValue:qoslocalnone||MediaAttribute(a):curr:qosremotesendrecv||MediaAttributeFieldname:curr||MediaAttributeValue:qosremotesendrecv||MediaAttribute(a):des:qosmandatorylocalsendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatorylocalsendrecv||MediaAttribute(a):des:qosmandatoryremotesendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatoryremotesendrecv现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。

VoLTE手机被叫未接通案例分析及处理VoLTE手机被叫未接通案例分析【摘要】VoLTE试商用时出现大概率被叫无法接通现象，通过现场测试排查和端到端信令分析，将问题锁定在核心网侧。

省NOC根据故障报告进行排查，针对核心网TLDN回落机制分析，最终确认核心侧TLDN数据配置不全。

【关键字】VoLTE 被叫TLDN 回落背景：随着网络优化和VoLTE商用的推进，安徽电信内部开通VoLTE用户预商用，要求各分公司试用并进行网络质量分析和疑难问题反馈，协助省公司完成VoLTE商用指导。

【故障现象】：省公司开通VoLTE测试卡后，概率性出现VoLTE测试卡作为被叫无法接通现象，未接通时主叫保持呼叫状态，被叫手机无响应，直至主叫手机提示“无声、空号、无法接通、未开通此项业务、增值业务被终止”等各种声音通话结束：图1：测试被叫无响应【告警信息】：登录基站无告警，网元测试，基站与MME、SGW等网元连接正常：图2：网元节点测试【原因分析】：（一）终端排查现场倒换终端进行测试验证，发现开通VoLTE功能终端在CS域做被叫出现大概率未接通，主叫正常：表1：终端排查（二）无线环境分析CQT测试，选取RSRP：-60dbm、SINR：30db覆盖正常，无线环境良好的测试点进行测试，依然出现被叫CS域无法接通现象：图3：无线环境（三）信令对比分析通过以上分析可以看出本次未接通与无线环境无关，只是VoLTE 功能终端在CS域被叫引起的未接通，计划通过CS域被叫正常通话和未接通信令对比来分析差异。

正常接通时：IMS域主叫发起INVITE Request后，2s∽5s左右被叫在C网收到寻呼消息，进而发起CSFB回落到C网通话，信令流程如下：图4：正常呼叫被叫CS域未接通时：信令来看IMS域主叫15:33:48发起INVITE Request请求，15:34:18发起呼叫取消，随后IMS下发呼叫取消确认，并下发INVITE 487呼叫终止，主被叫信令流程如下：此时，发起呼叫到终止经过30s时间，主叫超时释放，造成未接通，信令如下：图5：被叫无法接通主叫终端收到IMS下发的487呼叫终止消息，被叫未收到寻呼导致主叫超时终止通话，可以判断问题出在eNB上层网元IMS寻呼处理阶段。

VoLTE测试常见掉话未接通案例1.背景VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。

首先，高清语音和视频编解码的引入显著提高了通信质量，其次，VoLTE的呼叫接续时长大幅缩短，但VoLTE测试过程中仍发现部分掉话、未接通的现象，严重影响用户的感知。

本文梳理了VoLTE测试过程中常见的掉话、未接通的处理案例，为日后VoLTE试商用后此类问题的处理打下坚实的基础。

2.VoLTE语音通话流程简要如下：1.主叫发起INVITE消息，触发RRC建立过程（假设为空闲态）；INVITE消息包括主被叫电话号码，主叫支持的媒体类型、编码；2.主叫建立SRB2承载、QCI=9的DRB、QCI=5的sip信令承载；3.核心网反馈INVITE 100，表面正在处理应答；4.主叫RRC重配置建立QCI=1的专用承载；并激活；5.主叫收到被叫INVITE 183消息；并反馈PRACK启动资源预留；6.被叫收到PRACK后，反馈PRACK 200，启动资源预留；7.主叫收到PRACK 200，发送UPDATE，表明资源预留成功；8.同样被叫收到UPDATE，反馈UPDATE 200，表明资源预留成功；9.被叫发送INVITE 180 RINGING，振铃；10.被叫反馈INVITE 200，表明摘机11.主叫收到INVITE 200后，反馈ACK给IMS服务器，应答初始INVITE请求；并有IMS发给被叫；12.通话中；13.被叫挂机，发送BYE；IMS转发给主叫；14.主叫挂机，反馈BYE 200，IMS转发给被叫，表明结束会话；15.RRC重配置去激活QCI=1专载；图1.1 释放专载图1.2 简化信令流程图3.DT测试中常见的掉话、未接通问题2.1.切换失败导致常见有较多MR上报但不切，可能邻区漏配，之后触发RRC Re-Establishment，重建立不成功时掉话。

VOLTE异常掉话后连续未接通分析案例设备厂家：华为设备型号：HTC-M8 时间：2016/2/9关键字： VOLTE、掉话、BYE、语音一、问题内容：日常VOLTE测试中(1)主叫在19:15:10.645发起BYE挂机请求；（2）被叫一直未收到BYE消息;（3）主叫在19:15:16.829收到网络侧下发的BYE408消息，原因值是“No Response From Network”，主叫掉话；（4）19:15:30.649和19:15:33.684被叫发BYE请求，19:15:33.779网络侧应答BYE487（Glare Bye condition encountered）主叫掉话后紧接着发生连续两次未接通掉话未接通二、问题分析：掉话分析：主叫发了BYE请求，无线环境较好的情况下被叫却一直未收到BYE消息，需要核心网定位是否下发了BYE消息给被叫手机【IMS核心网信令分析】：被叫侧SBC在主叫挂机后，随即向被叫UE发送了BYE消息。

需EPC继续排查。

主被叫掉话后线环境较好，且主叫手机收到了INVITE100，但是被叫手机一直未收到INVITE。

需要核心网定位这两次呼叫是否向被叫终端下发了INVITE消息。

【IMS核心网信令分析】：两次呼叫中被叫侧SBC在主叫发起INVITE后，随即向被叫UE发送INVITE。

需EPC继续排查。

正常挂机流程：正常挂机流程，由主被叫任何一方发起BYE消息，经由IMS系统、PGW，SGW发送到对端设备，对端设备回复BYE 200确认消息，通话结束。

三、解决方案：问题点原因在空口质量良好的情况下被叫未受到BYE消息，主叫超时未挂断导致掉话，怀疑EPC 和IMS之间的接口问题，目前对问题点占用小区进行反复拨测，未出现问题，接口问题需要厂家进一步定位原因。

1、核心网及无线测设备参数核查，对定时器等参数进行优化2、对于基站故障及空口拥塞区域进行处理，保证覆盖及容量四、借鉴经验：随着4G网络VOLTE技术的到来，VOLTE掉话逐步凸现出来，除去空口质量问题之外还存在一些设备厂家接口之间的问题，需要逐步完善发现的问题，解决问题。

被叫设置呼叫转移导致volte主叫用户呼叫建立时延长未接通案例目录一、问题描述 (3)二、分析过程 (3)三、解决方案 (4)四、经验总结 (5)被叫设置呼叫转移导致volte主叫用户呼叫建立时延长未接通案例【摘要】VOLTE语音呼叫建立时长，在人为感知上是指从用户拨号到听到被叫的彩铃音或者回铃音的时间，从信令角度是指从主叫手机发起业务请求（INVITE）到主叫手机收到振铃消息（180）之间的时长。

VOLTE语音呼叫的建立时长过长，会影响用户对网络服务质量的感知，本次主要解决被叫用户设置的呼叫转移导致建立时长过长从而造成无法接通。

【关键字】volte呼叫建立时长、呼叫转移【业务类型】 VOLTE一、问题描述主叫在Volte呼叫CS域用户，且被叫用户又设置呼叫转移，导致呼叫建立时延长达20s，造成超时ue释放客户投诉使用Volte手机通话拨打被叫时呼叫建立时延很长，且响铃一声后放音“您拨打的用户暂时无法接通”随机挂断。

二、分析过程客户投诉使用Volte手机通话拨打被叫时呼叫建立时延很长，且响铃一声后放音“您拨打的用户暂时无法接通”随机挂断。

通过信令回溯查询用户11:28:22开始拨打被叫电话；从主叫来看，主叫起呼，随后建立CQI=1专载并激活，volte主叫信令正常。

图一被叫设置呼叫前转11:28:40才收到呼叫转移号码响应11:28:51ue超时释放造成一次未接通三、解决方案目前开通VoLTE高清语音通话的所有补充业务，即呼叫等待和呼叫转移，只针对VoLTE 高清语音通话生效，所以如果当前使用的不是VoLTE通话的话，呼叫等待和呼叫转移功能可能会发生异常。

当用户被叫将设置的呼叫转移关闭后问题得已解决。

通过信令回溯发现被叫UE设置呼叫转移导致呼叫建立时延过长造成未接通，多次试呼均出现如上问题现象；同时被叫呼叫主叫正常。

四、经验总结本次VOLTE拨打2G的失败，原因为被叫侧开启呼叫转移导致的未接通，并非是VOLTE 主叫侧的问题。

长治网格2VOLTE拉网测试
分析报告
2015年11月26日
1.1.事件
1.1.1.六分局附近道路出现未接通
【问题描述】：车辆在六分局附近道路行驶，被叫出现一次未接通。

【问题分析】：
1.主叫上发service request（17:21：13.046）,之后上发INVITE(17:21:26.050),10秒内未收到Trying 100消息，在17:21:37.099发起CSFB，统计为主叫未接通1次（17:21:26.050）。

如图2所示。

2.被叫直到17:21:42.518才收到paging，流程正常进行，直到主叫主动中止呼叫流程后（由于测试模板设置30秒超时，到17:21:42.142主叫上发Disconnect中止呼叫流程。

）,统计为CSFB主叫未接通1次。

如图1和图3所示。

3.被叫收到网络下发的IMS_SIP_CANCEL（17:21:42.746）（较主叫上发IMS_SIP_INVITE消息延迟16秒），被叫上发IMS_SIP_CANCEL-OK(200)(17:21:42.749)，之后，被叫上发IMS_SIP_INVITE-request terminated（487）消息（无原因值）,中止呼叫流程。

统计为被叫未接通1次（17:21:42.749）。

备注：核心网未下发IMS_SIP_INVITE-Trying （100）信令，延迟下发paging信令（延迟16秒，该paging也可能是主叫CSFB引发的寻呼消息，但无法证实，此时主叫已经释放）。

图1
图2
图3
【解决措施】：需要核心网进行核查为何未下发trying 100消息。

精品案例_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所终⽌。

广东茂名+ 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请求或响应码是分析问题的关键，现就前期遇到的异常响应消息进行总结，与大家分享。