中国移动LTE VOLTE案例分析汇总
Volte-VoLTE语音质量优化案例精编个
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPPLTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE12.2kbps）和VoLTE高清语音（或VoLTE23.85kbps）。
【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。
●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。
AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。
可见两者显着的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMRNB的语音带宽范围：300－3400Hz，8KHz采样。
AMRWB 的语音带宽范围：?50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMRWB与AMRNB不同之处在于AMRWB按16kHz采样，分别按频率带50~6400Hz?和6400~7000Hz进行编码。
用来降低复杂度，AMRWB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的,目的是调整与在声音基础上的低频有关的高频带.高频带的声频通过使用由低带LP过滤器产生的LP滤波器进行重建。
案例-Volte_Mos分析优化总结
深圳电信Volte Mos分析优化总结概述近年来，伴随着移动互联网的快速发展，传统电信运营商的业务体系不够丰富、占用资源多、商业模式创新不足、用户使用体验不佳的劣势日益凸显。
在此背景下，以VoLTE为核心的融合通信成为运营商加快转型，应对互联网公司跨界竞争的重要业务形态。
随着目前VOLTE建设的推进开通，针对VoLTE 的MOS优化进行分总结，用于为后续VOLTE优化提供分析指导。
1.Mos评分标准语音质量问题包含两类，一类可以通过MOS分衡量，称为MOS分问题，主要表现为MOS 不达标；另一类通过用户主观感受来衡量，主要表现为单通、静音、杂音、掉话等等。
ITU-T P.800定义了MOS的主观测试方法，即请40至60个有代表性的人士来听一段相同的语音样本，然后对该样本经过VoIP传输后的语音质量进行投票评价，这是一种纯粹主观的定性评估。
ITU-T选取在非常宽的听觉范围内，根据不同年龄、性别和语言组别的得分，做出语音质量的判别。
主观测试方法应用比较广泛，但有一定局限性。
比如，主观测试方法要求有专业分析统计方法、经过专门培训的第三方语音测试人员、特殊的语音测试环境、标准的声源，对环境和人员都有较高的要求。
目前在对设备厂商设备语音质量测试时，国内和国际运营商更多地采用客观测试测试方法。
MOS值（mean opinion score参考ITU-T P.800），语音质量的平均意见，是衡量通信系统语音质量的重要指标，它是一种五分制判断标尺，可以用数字或者文字表达。
Volte语音质量的客观评价体系与2/3G相同，仍采用MOS评分，但是2/3G采用的是8k采样的AMR-NB 语音编码（评分标准用的是ITU-T P.862），Volte采用的是16k的MAR-WB语音编码，评分标准采用的是ITU-T P.863.MOS得分说明不同的语音评分标准，MOS值存在差异。
1)PSQMPSQM (Perceptual Speech Quality Measurement)即感知的语音质量测试，它是一种语音质量的客观测试方法，参考ITU-T的P.861中描述。
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，属于端到端问题，需要集团规范协议流程。
VoLTE优化经验总结及案例
VoLTE优化经验总结及案例分享1优化经验总结1.1日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3.导致NAS的层3消息已经比MR要早，但是因为优先级比MR 和SIP低，未及时发送。
优化措施：降低QCI5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3QCI5PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
VoLTE语音质量优化案例(14个)
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPP LTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE 12.2kbps）和VoLTE 高清语音（或VoLTE 23.85kbps）。
【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。
●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。
AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。
可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMR NB的语音带宽范围：300－3400Hz，8KHz采样。
AMR WB的语音带宽范围：50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMR WB与AMR NB不同之处在于AMR WB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz 进行编码。
用来降低复杂度，AMR WB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms 的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs 速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。
VoLTE评估测试典型案例分析
VoLTE评估测试典型案例分析【案例分类】VoLTE【案例摘要】结合VoLTE网络城区测试评估工作，对测试中的异常事件进行分析，总结VoLTE优化分析经验。
1、切换与承载建立流程冲突问题导致掉话问题描述：UE在行驶至此路段占用二中分校-432486_51小区在被叫上发sip183之后，在激活EPS承载之前，终端上报一条MR，满足A3，触发同频切换，在目标小区成功接入后很快发生掉话。
问题分析：起呼时MME进行激活EPS承载流程过程中，恰好发生切换时，由于EPS承载建立未完成，MME在切换准备阶段，对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载，导致VOLTE专载源小区完成的情况下，在目标小区下发的rrc ConnectionReconfiguration消息中的radioResourceConfig Dedicated中释放了DRB-Identity = 6，切换完成后呼叫中断。
结论建议：切换与EPS激活流程碰撞，为无线网与核心网配合问题。
在进行激活EPS专载过程中，发生切换时，均会造成上述问题，需要和核心网确认目前是否有解决方案。
2、弱覆盖导致掉话问题描述：终端RSRP持续低于-120dbm左右，SINR在-7左右,主被叫UE均发生切换失败，单通，最终掉话。
问题分析：主被叫问题一直为弱覆盖，终端RSRP持续低于-120dbm左右，SINR在-7左右，切换失败后的TAU无法成功建立RRC 连接，此时段RTP包不能正常发送，上下行丢包严重（丢包率60%以上），出现单通，10s后RTP Inactivity定时器超时，会话终端，产生掉话。
结论建议：附近已有建设任务站点，开通后可解决弱覆盖问题。
3、弱覆盖导致未接通问题描述：本通话过程中，主叫占用HF-市区-太阳湾9号楼-HFTA-430739-51无线环境良好（RSRP=-92,SINR=9）,被叫占用HF-市区-金色池塘-HFTA-905606-54无线环境较差（RSRP=-100,SINR=-7）,呼叫发起6s左右释放，造成未接通。
VOLTE接通率优化思路及案例
VOLTE接通率优化思路及案例随着移动通信技术的快速发展，人们对通话质量的要求也越来越高。
VOLTE（Voice over LTE）作为一种高质量的语音通信技术，具有更高的音质、更快的连接速度和更低的延迟，逐渐取代了传统的2G和3G语音通信方式。
然而，由于各种原因，VOLTE接通率可能会受到一些干扰，影响通话质量。
因此，提高VOLTE接通率成为了运营商和设备厂商共同面临的一个重要问题。
下面将介绍一些优化VOLTE接通率的思路和案例：1.信号覆盖优化：VOLTE需要在LTE网络下进行语音通信，因此优化LTE网络的覆盖范围和信号强度可以提高VOLTE接通率。
对于信号覆盖不好的区域，可以增设更多的LTE基站或放置室内LTE小站，以消除信号死角和盲区。
案例：城市的一些居民小区信号覆盖很差，导致VOLTE接通率低。
该地区的运营商决定在小区内增设室内LTE小站，通过强化信号覆盖，提高VOLTE接通率。
经过实施后，VOLTE接通率显著提高，用户体验得到了极大改善。
2. QoS优化：VOLTE语音通话对QoS（Quality of Service）要求较高，需要保证较低的延迟和较高的网络带宽。
因此，通过对网络中的资源进行调度和优化，可以提高VOLTE接通率。
例如，对于VOLTE通话流量进行优先级调度，确保其能够优先获得网络资源。
案例：国家的一个运营商发现，其LTE网络中VOLTE语音通话的延迟较高，导致VOLTE接通率较低。
通过对网络的QoS策略进行优化，提高了VOLTE语音通话的优先级，将相关资源分配给VOLTE通话，从而提高了接通率。
案例：运营商发现其IMS网络存在一些性能问题，导致VOLTE接通率较低。
运营商对IMS网络进行优化，增加了IMS服务器的数量，改进了通信协议，优化了网络参数等。
通过这些改进措施，VOLTE接通率得到了明显提高。
4.终端设备优化：VOLTE通话不仅依赖于网络的性能，还与终端设备的质量和性能密切相关。
5.VoLTE案例分析
注：该问题正在与终端厂家沟通中….
几类人工剔除异常介绍
平台规则问题：3分钟双bye收OK回复案例
现象：呼叫满3分钟后，终端上发SIP bye后3秒又上发sip bye消息，并收到OK回复。 规则：已有网络问题发现，存在双bye后掉话的情况，因此平台算法对全部双bye问题标记为掉话。 分析：虽然出现了双bye挂断，（1）满足呼叫规则3分钟挂断且收到OK回复，（2）期间RTP包交互正常 确认应为正常挂断，sip bye消息重发。
2. 被叫振铃不接听案例 现象：被叫update交互完成后，上发振铃，未上发 OK,主叫收到振铃，18秒后上发了cancel取消。 软件：惠杰朗CDS 分析：被叫上发振铃后，按照软件设置应在1秒后立 即接听，怀疑软件触发的接听AT指令未其作用。
注：平台对掉话判断规则，在出现sip invite OK后，监测后续 的sip bye消息，若出现sip bye且收到OK则判断为正常，若无 发生下1次起呼，则以下次起呼时间作为上次掉话的时间点。。
现象/原因分类 振铃不接听
呼叫过程中主叫再次起呼或被叫异常发起寻呼 终端主动挂机
LOG信令记录丢失 SIM卡故障
说明 被叫振铃但不接听 接通状态下起呼或寻呼 起呼或接通后的立即挂断 由于软件问题导致的LOG未记录 非人为因素导致的SIM卡松动
问题判定
问题子类判定
测试软件问题 测试设备问题
丢信令
如GSM下的信令丢失，TD、LTE信令不连续则需要仔细辨认，确 认非基站闪断造成
注：VOLTE未接通触发CSFB接通，仍然统计VOLTE未接通；特别说明由于是统计规则后续可能会按照集团要求变更。
HTC M8版本升级引入silent redial功能
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
广东移动4GTD-LTE详细案例分析案例1：580 Precondition Failure导致的未接通。
【问题描述】在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。
Log文件名：MO UE:MT UE:时间：10：16：1、呼叫过程中，被叫发送Ringing 180后，收到网络下发的专载去激活命令，QCI 1被释放，被叫随后上报580 Precondition Failure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。
2、从信令中可以看到，被叫回复Ringing 180且主叫也已经收到Ringing 180，被叫随后收到网络侧下发的RRC重配，携带有QCI 1被释放的信息，被叫去激活专有承载。
由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition Failure失败消息。
主叫收到网络侧下发的580，接续被中止，导致了会话未接通。
3、从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层nomal_release，导致专载QCI 1被释放。
4、专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE580，会话流程中断，导致未接通在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。
【测试验证】案例2：Server Internal Error 500导致的未接通【问题描述】在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。
Log文件名：MO UE:MT UE:时间：10：19：【问题分析】1、主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE 200，随后被叫发送Ringing 180，主叫同时收到UPDATE 200和Ringing 180。
按照正常的信令流程应该是先收到UPDATE 200，再收到Ringing 180。
2、然后主叫收到网络侧下发的INVITE Server Internal Error 500.主叫专载被释放，去激活，导致会话未接通。
【问题定位】主叫收到网络侧下发的INVITE 500，然后网络侧又下发RRC重配，释放掉QCI 1，然后去激活，会话流程终止，导致未接通【解决措施】需要核心网确认，为什么会下发INVITE 500，什么情况下会导致网络侧下发INVITE 500，随后的专载释放是否由INVITE 500导致的【测试验证】案例3：软件对失败事件的误判导致统计错误【问题描述】在集团测试LOG中，存在软件的误判而错误统计的失败事件。
如在某个特定时间点上，信令显示主被叫正常通话，软件却统计出掉话或未接通事件。
Log文件名：MO UE:MT UE:时间：09：44：【问题分析】1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功，在通话过程中信令流程正常，中间出现一次RRC重建被拒，导致RRC释放，事件表现为掉话，软件统计为掉话。
2、在09：44：主叫收到网络侧下发的RRC重建被拒，主叫随后发起RRC建立请求，在09：44：15：004，然后因为TAU，在09：44：15：128 RRC Connection Release了，软件统计为掉话。
随后主叫又发起RRC连接，且在09：44：重建完成，从RRC重建被拒到RRC 连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。
3、到最后结束通话正常挂机都没有出现失败事件【问题定位】主叫接通后，在没有收到通话结束的情况下，中间出现RRC Connection Release，软件判断为掉线，此次是在会话建立后出现，软件统计为掉话【解决措施】需要鼎利修改判断事件失败的机制【测试验证】案例4：软件对失败事件的重复统计【问题描述】软件对于失败事件存在重复统计的问题，在集团测试问题统计表中，多次出现同一次失败事件，软件却作了多次统计，导致失败事件的增多。
Log文件名：MO UE:MT UE:时间：10：04：【问题分析】1、主叫在10：04：发出INVITE会话请求，被叫在10：04：收到网络侧下发的BYE Request，软件统计为掉话。
查看BYE Request中的CALL-ID，发现是上次会话的BYE Request2、被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100，又在10：04：收到网络侧下发的INVITE Request同时发送Trying 100，并在同时发送INVITE 486，软件统计为未接通。
3、主叫在收到网络侧下发的UPDATE 200后，在10：04：上报Cancel，主叫的整个会话流程到这里被终止，事件上表现为未接通。
且承载都存在【问题定位】通话期间，被叫收到网络下发的BYE Request会被软件统计为掉话。
被叫连续两次收到网络下发的INVITE Request，回复INVITE 486 Busy Here，由于第一次INVITE Request未释放，故第二次INVITE Request网络侧才会下发INVITE 486，流程停止，软件统计为未接通。
此时主叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。
直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。
【解决措施】需要鼎利确认对失败事件的统计机制。
【测试验证】案例5：LTE到2G eSRVCC切换失败导致的掉话【问题描述】呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置命令，但在2G侧切入失败，导致掉话。
Log文件名：MO UE:MT UE:时间：11：16：42：311【问题分析】1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入2G网络，2G网络下发TMSI Reallocation Command，被叫回复TMSI Reallocation Complete，此后流程中断，eSRVCC切换失败。
3、信令上看，4G流程正常走完且建立会话，被叫切换到2G，但是网络下发TMSI ReallocationCommand导致流程终止，eSRVCC切换失败，会话流程结束，怀疑是2G问题。
【问题定位】4G流程正常且已正常建立会话，由于2G网络侧下发TMSI Reallocation Command导致eSRVCC 切换失败，会话流程结束，导致掉话，怀疑是2G的问题。
【解决措施】下周准备复侧，准备定位。
【测试验证】案例6：TAU过程中RRC Connection Release 导致的未接通【问题描述】在越秀区网格10的测试LOG中，出现如下的未接通事件：主叫起呼发出Invite消息后，在收到网络效应Trying 100之前，先收到了网络下发的RRC Connection Release消息，RRC连接释放后，接续被终止，出现了Blocked Call事件。
【问题分析】1、通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：2、在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。
然而Invite上发后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release 消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫释放，从而导致了Blocked Call事件的发生：3、进一步分析信令可以发现，主叫在该测试路段内连续在3个TAC（9437、10315、10014）间进行TAU更新，其中从11:42:53至11:43:04就发生了4次，可能在存在TAC规划不合理的问题。
【问题定位】【解决措施】【测试验证】案例7：Alerting中eSRVCC失败导致未接通【问题描述】主叫起呼后，流程正常，达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180，主叫未摘机，由于切换失败导致未接通。
Log文件名：MO UE:MT UE:时间：11：25：28：189【问题分析】1、主叫在11：25：起呼，到11：25：收到网络侧转发的Ringing 180，整个信令流程正常2、在主叫几乎收到网络侧转发的Ringing 180的同时，主叫达到eSRVCC切换门限，网络侧在11：25：下发eSRVCC切换命令，在切换过程中主叫处于振铃中，并未摘话，而切换失败，导致了未接通。
【问题定位】主叫已经收到Ringing 180，处于振铃状态还未摘话，由于在Alerting中发生了eSRVCC 切换失败导致了未接通【解决措施】需要核心网方面帮忙定位【测试验证】案例8：CSFB失败导致未接通【问题描述】主叫起呼后，被叫CSFB失败，主叫直接Cancel导致未接通Log文件名：MO UE:MT UE:时间：15：42：53：063【问题分析】1、主叫于15:42:22发起invite，被叫未收到网络侧转发的INVITE Request，但是主叫能一直收到网络侧下发的INVITE 183 、PRACK、UPDATE消息，这些消息被叫并没有收到也没有回复。
被叫在15:42:24收到网络侧下发的CSFB request，但CSFB到2G后从信令看没有呼叫相关的信令交互过程2、直到15:42:35 CSFB失败，由于收不到被叫的响应，主叫主动于15:42:53发起CANCLE。
导致会话未接通。
【问题定位】主叫发起会话后，被叫没有收到会话请求，直接CSFB，CSFB失败，主叫一直未收到被叫的响应，直接Cancel，导致会话未接通。
【解决措施】需要核心网查看为什么被叫没有收到主叫的会话请求，且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息。
【测试验证】案例9：被叫Detach导致会话未接通【问题描述】主叫发起会话，被叫驻留在2G未返回4G，没有响应主叫的会话请求，主叫收不到被叫相应，直接Cancel导致未接通。