VoLTE呼叫失败案例分析(华为修订版)

VOLTE起呼失败的案例1. 问题描述使用HTC M8T的VOLTE版本，升级成最新的版本–RC25、R35新版本。

升级完成后注册IMS成功，但在华为MME下无法进行VOLTE呼叫，变成了CSFB语音方案回落至2G进行通话。

2. 问题分析终端使用测试卡已注册VOLTE网络成功，进行呼叫的时候，网络侧回复503错误（SERVICE UNAVAILABLE）。

具体的SIP信令流程如下。

1、UE->NW INVITE2、NW->UE Cancel503终端发起VOLTE呼叫，且支持Silent Redial机制：当VOLTE呼叫失败后，将转成CSFB 语音方案，因此呼叫回落至2G。

而使用相同卡插入三星S6测试VOLTE呼叫，呼叫成功。

问题原因：不同VOLTE终端，采用的附着建立默认承载的方法也不同，主要有两种不同的方法：1、终端附着网络时，使用网络默认APN建立默认承载。

比如，HTC M8T。

2、终端附着网络时，使用终端侧设置的APN建立默认承载。

比如，三星S6。

3、使用终端侧设置的APN建立默认承载，按照3GPP24.301章节8.3.20.2描述，在附着络过程中，建立PDN连接请求消息如果携带“ESM information transfer flag”( ESM 信息传输标记），表示终端希望使用自己提供的APN。

三星S6使用终端侧设置的默认承载信令截图如下：1、终端在Attach request请求信令携带“ESM information transfer flag”：2、网络侧发起APN请求，ESM information request，终端通过ESM information response回复网络侧终端上设置的默认APN。

HTC M8T使用网络侧设置的默认承载信令截图如下：1、终端Attach request请求信令未携带“ESM information transfer flag”：2、网络侧发起APN请求无ESM information request：经过测试分析发现，HTC M8T，使用LTE的APN进行IMS注册期间，终端发起了3次默认承载请求，在第三次默认承载请求，PDN类型为ipv6的PDN连接请求，网络侧处理此请求时，错误地建立了IMS承载。

VoLTE视频呼叫不可用案例分析【摘要】在VoLTE技术的普及与即将到来商用前景的影响下，用户渴望被提供高清晰和高可靠性的视频语音通话服务。

VoLTE语音业务和数据业务的QoS和用户感知存在差异，VoLTE接通率、呼叫时延、掉话等更为敏感，因此，当前做好VoLTE业务保障及优化尤为重要。

本文分析了由于QCI2上行GBR速率受限而导致无法进行视频业务的问题。

一、【问题描述】淮南电信接到用户反映，在电信大楼占用4G信号，无法进行VoLTE视频业务，用户手机界面显示“视频通话不可用”，然后跳转到语音通话后正常。

投诉点位置如下：二、【原因分析】2.1 VoLTE视频业务VoLTE终端在通话时会启动专用承载和默认承载，其中QCI1为语音承载，QCI2为视频承载，QCI5为IMS承载。

2.2 基站状态查询查询占用基站状态正常，无告警，如下图：2.3 测试log分析对现场进行测试发现主叫发起INVITE-Request后，开始建立用于语音和视频通话的QCi1和 QCI2的专用承载，信令如下图：被叫收到主叫的paging消息后，发起INVITE-Request，并回复SIP-183消息，里面携带视频通话需要的bandwidth为960kbs。

之后主叫手机修改了QCI1的MaxBitRate，并发送QCI2的去激活专用承载请求。

随后在单独的QCI1的专用承载下，进行了语音通话，手机显示“视频通话不可用”自动跳转到语音通话。

主叫QCI2去承载的信令是导致视频未接通的原因，其根本原因是基站侧在收到被叫协商速sip-183的消息后，发起QCI2的承载修改，要求修改上行带宽到960，然后被ENB拒绝，需要查询基站QCI2的上下行GBR带宽设置。

基站侧查询发现该站点的QCI2上行设置为840kb/s,下行为2048kb/s，上行GRB速率不满足网络协商的960kb/s。

三、【解决措施】修改基站的QCI2的上行最大GBR速率为2048参数修改后进行复测，主叫正常建立QCI1和QCI2的专用承载，并且在sip-183协商完成后确认修改QCI1和2的速率，被叫正常建立QCI1和QCI2的专用承载，视频通话正常，经过多次测试均正常。

终呼未接通分析基于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部分用户关闭VOLTE功能后呼叫失败问题分析摘要：目前VOLTE正在逐步替换2G语音，因网络结构复杂过程中会产生各种问题，本论文分析了此次呼叫失败的原因及处理措施。

关键词：VOLTE，MGCF，IMS1，VOLTE简介：VoLTE是基于IMS的语音业务。

IMS由于支持多种接入和丰富的多媒体业务，成为全IP时代的核心网标准架构。

经历了过去几年的发展成熟后，已经被3GPP、GSMA确定为移动语音的标准架构。

VoLTE即Voice over LTE，它是一种新型IP数据传输技术，无需2G/3G网，全部业务承载于4G网络上，可实现数据与语音业务在同一网络下的统一。

换言之，4G网络下不仅仅提供高速率的数据业务，同时还提供高质量的音视频通话，后者便需要VoLTE技术来实现。

2，问题描述：河北移动中兴IMS割接后，唐山移动用户反馈，开通VOLTE业务，但是终端上关闭VOLTE功能并且用户联合位置更新到唐山POOL3的端局时（其它POOL端局没有问题），做被叫失败，主叫侧听到嘟嘟通知音，被叫无反应。

3，问题分析：3.1进行问题复测，从被叫MSC端局跟踪的信令看，MSC端局收到关口局发送的IAM消息后，直接发送了REL消息释放呼叫，原因值为：”Normal unspecified（31）”。

将用户归属IMS域改到华为后拨测没问题，对比华为MGCF和中兴MGCF发的IAM消息，有三处区别：1)中兴IAM消息里Transmission Parameter requirement为speech，华为为3.1k audio2)中兴IAM消息里的编解码写上列表里有AMR2和G.711，而华为只有G.7113)中兴IAM消息里有redirection information字段，华为没有这些字段3.2是携带的Transmission Parameter字段为speech导致3.3中兴MGCF修改参数，将该字段填写为3.1k audio后，经过复测，问题现象依旧，排除该参数问题。

VoLTE无法寻呼案例分析一、问题现象：在进行VoLTE测试时，在做UE主被叫测试时，发现UE处在idle状态下，无法被寻呼到。

二、问题分析1.基站故障问题：对测试基站进行告警查看，无任何告警，查询历史告警，也无异常。

在该基站下作数据业务，也为发行异常，排除基站故障引起的可能性；2.核心网设置问题：对核心网侧发端进行抓包，确定Paging已经发出。

3.参数设置问题：在基站侧，确定是否收到Paging包。

若收不到，那么，就要排查传输。

若收到，就是eNodeB本身的问题。

4.而确定基站是否收到Paging方法有2种。

可以上前台用Wireshark抓包，也可以后台通过信令确定是否收到Paging消息。

使用后台系统工具-----统一信令跟踪，对Paging进行跟踪。

因此，确定，基站自身收到核心网发来的Paging消息，问题排查，关注基站本身。

三、优化方案1.终端UE收到的寻呼消息中如果带有UE ID列表，终端需要用自己的UE ID来跟寻呼消息中携带的UE ID一一进行匹配，以判断此寻呼消息是否是在呼叫自己。

同时，在寻呼消息中如果所指示Paging ID是S-TMSI，则表示本次寻呼是一个正常的业务呼叫；如果Paging ID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错误恢复，此种情况下终端需要重新做一次附着(Attach)过程。

2.从传输信道角度来看，最终由PDSCH下行共享物理信道承载寻呼信息。

在接收寻呼消息之前，终端UE需要先去监听PDCCH物理信道，然后根据PDCCH物理信道上是否有携带P-RNTI，来判断网络在本次寻呼周期是否有发寻呼消息给自己。

3.终端在一个DRX的周期内，可以只在相应的寻呼无线帧(PF)上的寻呼时刻(PO)先去监听PDCCH上是否携带有P—RNTI，进而去判断相应的PDSCH上是否有承载寻呼消息。

如果在PDCCH上携带有P—RNTI，就按照PDCCH上指示的PDSCH的参数去接收PDSCH上的数据；如果终端在PDCCH上未解析出P—RNTI，则无需再去接收PDSCH物理信道，就可以依照DRX周期进入休眠。

案例1：“2、3G手机拨打VoLTE（驻留4G），被叫摘机后无法听到主叫，
3秒后掉话”问题的处理。

根据信令分析：
1.序号4862，被叫摘机,摘机200 OK送到被叫侧的IMS核心网。

2.序号4908-4983，摘机200 OK经过CATAS时，CATAS向主叫发UPDATE，将媒
3.序号4985、5009，MGCF收到UPDATE后向被叫发该UPDATE的200 OK，随后根据"a=conf:qos remote sendrecv"的要求再次向被叫侧发送UPDATE，进行二次确认。

4.序号5095、5106，MGCF发送200 OK消息送到CATAS，CATAS向被叫S-CSCF 发摘机200 OK，被叫S-CSCF应将此消息转发向其它AS。

5.序号5128，S-CSCF将摘机200 OK发到TAS，TAS没有进行转发，后续S-CSCF 重传的摘机200 OK，TAS也没有转发。

6.序号5129，MGCF发的二次确认UPDATE到达S-CSCF，这条消息与摘机200 OK 碰撞，没有进行后续转发，后续该消息的重传消息也没有转发。

被叫CATAS发的。

VoLTE三方通话失败解决案例【摘要】VoLTE内部体验测试中，多次出现双方通话正常、三方通话失败。

通过跟踪S1口信令分析和参数排查，确定基站QCI=1的承载修改过程中速率协商失败，导致三方通话异常。

通过端到端参数协同，保证业务顺利进行。

【关键字】VoLTE三方通话建立失败端到端参数协同一、问题描述VoLTE业务测试时，多次出现双方通话正常、三方通话失败：主叫A呼叫被叫B正常通话。

A与B呼叫保持，主叫A呼叫被叫C时，C终端无响应，主叫A等待6s挂机。

图1：三方通话呼叫失败二、三方通话过程Step1：主叫A呼叫被叫B；Step2：主叫A呼叫被叫C，此时A与B之间处于Hold状态。

该过程需要协商QCI=1的GBR，保证满足三部终端合并通话要求。

Step3：点击“合并”通话，A、B、C合并到会议组建立三方通话。

被叫B、C挂机不影响通话业务，主叫A挂机则通话结束。

图2：三方通话建立过程三、问题分析过程针对VoLTE三方通话失败问题，首先排除终端问题和小区故障，结合终端Log、Wireshark S1信令、Trace LOG进行分析，查找异常原因，有针对性的分析参数设置问题。

尤其是VoLTE业务涉及网元众多，流程复杂，需要详细了解各个环节才能迅速准确的定位问题，从用户SIM卡、终端、基站、无线环境、参数检查、信令流程等分析，具体流程如下：图3：分析流程1、终端、SIM卡、eNB版本排查主叫A单独呼叫被叫B通话正常，单独呼叫被叫C时通话正常；被叫C倒换为主叫终端测试呼叫正常。

同样的终端在其它基站测试，现象一致，因此排除终端、SIM卡、eNB版本问题。

2、覆盖分析选择一个小区，使用VoLTE终端连接PC端软件测试：RSRP、SINR 良好，Attach、FTP、ping、VoLTE双方通话等各项业务均正常。

因此排除基站业务异常和无线环境问题。

只有在进行VoLTE三方通话业务异常。

3、设备侧核查传输检查：eNB能够正常ping通，eNB ping MME、源基站ping 邻基站、邻基站ping源基站，均能ping通，时延均正常，说明网元之间链路正常。

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掉话没有出现。