可能是由于QCI5的pdch discardtimer过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包，现在已经修改全网CQI 5的discartimer由300ms修改为无穷大，修改后很少发生SIP信令丢失的问题，问题基本解决。
2.1 切换过程中专载被MME释放导致未接通
【问题描述】
主叫或被叫在呼叫时的专载建立过程中，MME若未收到UE反馈专载建立完成的消息，此时发生切换，MME将在目标小区发起专载释放的请求，导致未接通。 【问题分析】
主叫发起INVITE请求后，收到网络转发的100trying消息，接下来进行专载建立与激活流程，在收到网络下发的专载建立请求之前，主叫上报了A3测量报告，随后进行专载建立流程，在激活专载并上报NAS确认消息后，主叫收到网络下发的切换重配置命令，在重切换配置消息中携带了QCI 1专载释放命令，随后主叫上报cancel取消本次通话。
【问题定位】
由于终端上报A3时间在上报NAS确认消息之前，基站侧在收到A3测量报告后向MME发起切换请求，在切换过程中MME发给目标小区的
handoverRequest消息中e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。 【解决措施】
目前主要通过修改QCI5优先级，提高SRB2的优先级来优先传送NAS信息，解决切换过程中专载被释放问题。
2.2 终端未收到专载建立请求导致未接通
【问题描述】
主叫或被叫在呼叫过程中，未收到系统下发的专载建立请求导致未接通。 【问题分析】
上次正常通话结束后，本次通话主叫发送trying100消息后，核心网下发专业承载请求后主叫开始建立和激活专载流程。被叫在上报183后，正常流程应该是由核心网下发专业承载建立请求后被叫开始建立专载过程，但实际上被叫一直未收到核心网下发的QCI1建立请求，主叫在上报PRACK后收到网络下发的481Call leg transaction does not exist消息，随后主叫上报cancel消息取消本次通话。
【问题定位】
终端未收到专载建立请求原因可能有：1、无线环境太差，基站转发了核心网下发的专载建立请求但终端未收到；2、核心网未下发专载建立请求。 【解决措施】
需结合基站测CTS信令查看核心网是否下发专载建立请求消息，如下发了专载建立请求但终端未收到需要检查下行链路是否太差导致，需要优化下行覆盖。核心网问题导致核心网未下发专载建立请求，需要核心网侧查找未下发专载建立请求原因。
2.3 Alerting中eSRVCC导致的未接通设备故障问题
【问题描述】
被叫已振铃，此时主叫或被叫达到了eSRVCC切换条件并进行切换，切换后会话中断，未能接通。 【问题分析】
主被叫呼叫流程正常进行至振铃阶段，被叫在上报180ringing后，收到网络了转发的ACK确认消息前，也就是振铃后接通通话前，被叫上报B2测量报告(BCCH 67 BSIC 2 BCCH Level -86dBm)，核查上报MR已满足B2判决门限，ENB下发eSRVCC命令指示UE切换至2G网络，13：55：45.956上发Handover Complete，13：55：46.156收到网络下发Disconnect 释放原因: (50)Requested facility not subscribed，导致未接通。
【问题定位】
对于Alerting中或Alerting前eSRVCC导致的未接通，主要是由于IMS及核心网功能或版本问题，在呼叫流程进行至ACK之前发生ESRVCC后都会造成未接通情况。 【解决措施】
需要联系IMS和核心网侧研发解决这类问题，无线侧优化手段有提升该路段覆盖，合理设置B2门限，使终端尽量占用LTE网络进行通话。
2.4 设备故障问题导致的未接通
【问题描述】
会话流程正常接续，终端上报Cancel，导致会话未接通 【问题分析】
1、主叫在14：53：03.998起呼，信令流程正常，且被叫上发Ringing 180，
主叫收到网络侧转发的Ringing 180，主被叫都已经振铃。但是主叫突然在14：53：06.510上发Cancel，被叫也收到网络侧转发的Cancel，会话接续停止，导致未接通。