VOLTE单通问题发现和定位手册一、原理介绍Volte业务不管是单通，断续，金属音还是双不通等感知问题，归根结底还是RTP丢包，导致语音失真
，或者断续。RTP/RTCP协议介绍：基于IP承载的语音业务流是在UDP（User Datagram Protocol）上传输的，
而UDP协议用于专门传输数据流，设计时并没有考虑实时业务传输的特殊要求，如媒体流的同步等。因此在UDP上传送实时业务时，需要对UD
P进行扩充。为此IETF（Internet Engineering Task Force）专门制定了实时传输协议RTP（Real-
time Transport Protocol）。RTP协议的功能是提供实时的端对端传输业务（如交互的语音和图像），包括负载类型标
识、序列号、时间戳、传输监视等。RTP协议包括两个紧密相关的部分： 1、实时传输协议（RTP）：传输有实时特性的信息。 2、RTP
控制协议RTCP（RTP Control Protocol）：监视业务质量和传输会话中成员的信息。RTP协议使得音视频的实时传送及
同步得到保证。RTCP协议则是监视RTP报文及其QoS（Quality of Service）的协议。RTP不预留资源，也不保证实
时业务的服务质量。数据传输的加强则是通过使用控制协议RTCP来实现。RTCP协议利用与数据包相同的传输机制定期向对端发送RTP控制
包，主要实现以下功能： 1、提供数据传输质量的反馈。反馈功能通过RTCP发送报告和接收报告实现，接收端通过RTCP报文的反馈信息来
诊断传输线路是否故障，控制RTP报文的发送。 2、RTCP为每个RTP源传输一个固定的识别符，称为标名（CNAME）。当发生冲突或
程序重启时SSRC（Synchronization Source）可能改变，接收端根据CNAME（Canonical End-Po
int Identifier）来跟踪对方。协议栈消息结构二、定位思路单通问题主要就是定位RTP丢包，整体流程如下：备注：如果从基站
S1口抓包存在以下几方面不方便：第一、上站困难；第二、用户级定位困难；第三，数据包太大，分析困难；所以我们为了快速定位，建议优先采
用移动第三方平台业务包进行定位，例如炎强平台，华为GN口平台等。2.1问题搜集和确认1、被动客户投诉，则需要获取以下几个方面信息：
终端类型，出现频次，出现地点，同时获取用户电话号码。一方面通过SEQ平台查看话单，确认上下行RTP丢包情况，确认是主叫丢包还是被叫
丢包；另一方面安排人去现场拨测，采用不同类型终端复测，确认无线环境或者终端是否有收敛性。 如果终端有收敛性，需要联合终端厂家共同定
位；如果没有任何收敛性，则按照上面的处理流程进行逐级排查。2、主动发现问题，目前VOLTE单通现象主要通过第三方端到端平台监控发现
，华为SEQ平台有上下行RTP/RTCP丢包率统计，RTP单通比例相关指标统计，结合这些推断用户感知。单通类似现象如下：eNode
B名称VoLTE上行RTP单通比例S1U(%)VoLTE上行RTP单通次数S1U(次数)VoLTE上行RTP有效语音流(次数)Vo
LTE下行RTP单通比例S1U(%)VoLTE下行S1U接口RTP单通次数(次数)VoLTE下行RTP有效语音流(次数)D7870
48松阳工业园区七F37.00%133537.00%1335D782104青田温溪港F89.00%25280.00%028D782
039青田中学F88.00%1481670.00%0168D782012青田油竹桥头F47.00%26550.00%055D786
076遂昌云峰二F79.00%19240.00%021D780267莲都地区医院（卫校）LY（中心医院）信源池D41.00%225
30.00%053D780565莲都东方宾馆LY（人民医院分布）信源池E32.00%491520.00%0152第一步需要确认单通
问题是否存在，去现场采用不同类型终端复测，从目前验证来看，单通比例达到30%以上基本确认会存在单通现象。第二步确认问题是否存在收敛
性，如果没有收敛性，同样按照处理VOLTE感知问题处理流程逐级排查。2.2数据核查内容第一步，基站告警排查。由于基站出现驻波比和光
误码会导致语音包丢失，引发VOLTE单通，通过排查确认基站运行是否正常。第二步，基站参数核查。通过对复现站点进行 VOLTE相关参
数进行核查，尤其是RLC SN域长度参数，确认是否参数配置问题导致。第三步，提取相关告警和异常日志，排查单通时间段是否存在异常信息
。2.3导入产品线需要的相关日志信息如果确认基站状态，参数，无线环境等都没有问题，则导入产品线处理，这时需要复测提取相关日志信息：
公共日志，1号日志，70号日志。2.4附Wireshark抓包技巧打开软件后，选择菜单Capture->Options，或者用快捷
方式Ctrl+K，打开选项卡。在Interface框中选择需要跟踪的网卡，选择某个网卡后在IP address中会显示该网卡的IP
地址。如果是无线网卡，则需要建立连接后才会在Interface框中出现。选好网卡后，点击右下角的Start，即开始跟踪数据。停止跟
踪时，则可点击如下图所示对话框中的Stop快捷键，或者直接用Ctrl＋E来停止。一些常用的选项：限制跟踪包长，防止抓包数据过大，推
荐使用100B字长抓包头抓包时按ip地址过滤，防止抓包数据过大过杂，host ... 表明只抓取IP地址中包含...
的报文；直接存储抓包数据到硬盘，防止占用内存过大，同时还可使用多个文件，避免单个文件过大；实时显示抓到的包并保持当前视图在最后四
、VOLTE单通案例案例一DRB Id翻转和高通芯片不兼容问题问题描述：2016年7月中旬左右，丽水现网出现了比较多的volte单
通投诉。丽水移动投诉，连续几天都能遇到volte打电话单通的现象，具体表现为“能听到对方的声音，对方听不到自己的声音”。使用vol
te业务的终端均有不同程度的表现。现场使用volte商用终端单通的情况复现，具体表现和客户投诉一致。问题分析：针对出现的单通问题，
通过现场对复现测试数据和SEQ提取其他地市相应话单对比分析，从以下几步进行定位分析排查。第一步，基站运作状态和参数核查，没有异常。
第二步，单通指标分析与地市指标对比。现场针对单通问题，从SEQ平台进行分析，发现在单通时“RTCP上行包数为0”，“RTCP下行包
数不为0”，指标截图如下：为分析丽水近期单通事件比其他地市概率要大，于是现场分析对杭州与丽水的5终端号码进行指标提取分析，从SEQ
平台的提取指标，并统计“RTCP上下行包数”判定单通次数得出占比。统计数据佐证：按照单次单通的表现，随机找了5个手机号码分析话单发
现，在丽水的单通比例高达10%，而对应杭州的单通比例较低。见下：时间7月4日7月5日地市通话次数（主叫）通话次数（被叫）主叫单通次
数被叫单通次数主叫占比被叫占比通话次数（主叫）通话次数（被叫）主叫单通次数被叫单通次数主叫占比被叫占比杭州7777303.90%0
.00%2552100.00%0.00%丽水8278819.76%1.28%617313321.31%4.11%至此，可以明确得出
结论：（1）丽水网络的单通问题是存在的（2）丽水网络的单通出现比例较杭州要频繁。第三步，厂家测试指标对比分析。使用同样的终端和测试
软件在我司网络和华为网络（同在丽水）下对比测试。测试终端HTC M8t，测试软件CDS，测试方法是定点拨通volte呼叫主被叫听声
音如果不是单通则挂电话继续下一次测试，如果出现单通则停止测试。测试结果：在我司网络下20分钟出现一次单通，在华为网络下拨打超过20
0次（对应超过2小时）未出现单通。测试结论：HTC M8t出现的单通问题是我司网络才有的，需要进一步分析。在以上4步进行问题排查，
可以排除基站参数，故障导致的单通问题，而在进行不同地市和设备对比分析发现，我司网络确实存在单通问题。为此针对测试数据进行再次分析总
结规律，并进一步抓包定位分析。第四步，问题复现规律总结。问题复现规律总结的目的是为了找到触发问题的条件，力争做到可以稳定复现问题。
这样就可以有的放矢抓取需要的log，为问题的进一步解决做准备。HTC M8t的外场测试规律：约30次复现一次，如下：单接通测试统计
LOG总次数正常次数单接通次数单接通发生前正常接通次数统计单接通概率发生时间点1发生时间点2发生时间点312310097332，2
6，393.00%12:01:46.0012:10:07.0012:22:49.0022223221224.35%15:41:32
.67 33329281283.45%17:53:40.00 40556551551.79%18:57:39.00 大唐站下
测试单通7-7日230227331,89,281.30%14:35:13.0014:53:45.0014:59:30.00总计43
84299 2.05% 对比分析单通QCI1建立和正常未单通QCI1建立过程；发现正常情况下， ENB收到EPC的S1 ERA
B Setup Request，通过RRC重配置通知终端进行建立erab和eps承载；但是在单通的日志中，发现Enb收到epc的S
1 ERAB Setup Request，通过RRC重配置进行建立erab承载，通过直传消息建立eps承载，具体如下：进一步分析正
常erab和单通erab建立过程的RRC重配置，发现单通RRC重配置过程中，携带了切换的重配置；而正常ERAB建立过程中没有携带；
根据现场的分析，实验室复现结果显示：高通芯片可以稳定复现单通的问题，而海思芯片则不能复现问题。具体如下：HTC M8t拨打固话，d
rb为5时（第28次），发生小区内切换，QCI1已经建立，下行没有语音，20秒后释放。试到第56次，RRC重配置未完成，出现RRC
重建立，CSFB失败。移动N1拨打固话，drb为5时（第28/56次），RRC重配置未完成，出现RRC重建立，CSFB失败。华为P
9拨打固话，drb为5时（第28次），发生小区内切换，信令语音正常。试了两次都正常。华为mate8拨打固话，drb为30/31/3
2时（第25/26/27/53/54/55次）， QCI1已经建立，下行没有语音，20秒后释放。drb为5时（第28/56次），发
生小区内切换，信令语音正常。于此同时，外场用Mate8和P9也没有复现单通的问题。至此，可以得出结论，高通芯片（至少包含HTC M
8t、N1终端）在我司网络下出现单通的情况，且约30次复现一次。第五步，问题定位。问题复现后抓取前台和后台log分析。前台使用测试
终端连接上CDS软件，后台上站抓S1口的log。用wireshark抓S1口的log，分析RTP和RTCP的数据包。后台抓log的
方法控制开关-》协议栈抓包开关，复现，立刻提70日志。如果能上站，打开镜像，通过wireshark抓包比较方便。信令CDL和业务C
DL提取一下对应时间段的另外SEQ平台，尽量能找到出问题的用户的mmeapid或s1apid啥的，根据imsi找不到enb对应的用
户。空口log分析：对比分析出现单通和正常的数据，发现单通的时候上行PDCP层速率为0，对应的物理层速率正常。这说明问题出在物理层
和PDCP层之间。如下：分析wireshark抓的S1数据包，可以看到S1的RTP/RTCP数据包为0进一步分析空口log，总结规
律单通出现前一次呼叫的DRB id均为32，如下：volte业务建立的时候基站分配DRB=x（x是一个较小的数，比如是0或者1），
之后，每一次呼叫X+1，直到加到32。当达到32的时候，在下一次呼叫建立中就会发生DRB翻转，DRB又从较小的值开始。DRB id
翻转各个厂家的差异分析：DRB id是针对用户的，当发生切换，重新进入一个小区后，DRB id重新计算。所以，DRB ?id翻转发
生在某一个用户在同一个小区下连续拨打超过32次。经测试确认，华为和中兴的DRB ?id是固定的，不会发生翻转，爱立信的实现机制和大
唐一致，当DRB达到27（大唐是32）后发生翻转。 ?不一样的是，爱立信的DRB翻转和QCI 1建立是分2条信令实现的，大唐是同一
条信令实现。查阅协议，对DRB id翻转没有规定，可以设置为保持不变，也可以累计到一定数值再翻转。 ?对DRB id翻转是否可以和
QCI1建立在一起实现也没有规定。至此，问题定位为我司DRB Id翻转中和高通芯片不兼容问题。问题结论：兼容性的范围外场测试的结果
：HTC m8t（芯片为高通801）是有问题的。还测试了高通的其他芯片终端，包含苹果、三星S7、小米、N1 max等都没有出现问题
。我们还测试了海思芯片的mate8、P9，也没有发现问题。 ?“问题”指的是，由于DRB id翻转导致的单通问题包含高通801芯片
终端。其中实验室复现的N1终端问题和外场N1 max终端版本不一致。投诉的问题闭环投诉的终端没有收敛性，而实际定位的无线网络问题只
和高通801芯片终端如HTC M8有关系，说明无线网络的问题解决，并不能解决所有单通的投诉问题。涉及到核心网元的单通问题仍然在定位
中。解决方法：目前测试只有HTC m8这款存在类似问题，由于市场上并没有这款这款终端，所以解决版本并没有升级。案例二头压缩开启导致
的VOLTE双不通问题描述：移动客户投诉，在D780565莲都人民医院E-1小区下进行VOLTE通话时出现双不通现象问题分析：1、
问题确认方法：SEQ平台有上下行RTP单通相关的统计项，如下表中所示，通过这些统计项进行判断，主要看上行RTP单通次数以及上行RT
P单通比例，如果每天单通次数超过10次就有可能存在类似问题。目前已经有2个站去过现场复测，跟平台统计指标吻合确实出现双不通天市eN
odeB名称是否复位VoLTE上行RTP单通比例S1U(%)VoLTE上行RTP单通次数S1U(次数)VoLTE上行RTP有效语音
流(次数)VoLTE下行RTP单通比例S1U(%)VoLTE下行S1U接口RTP单通次数(次数)VoLTE下行RTP有效语音流(次
数)9月7日丽水D787048松阳工业园区七F-ENODEB未复位37.00%133537.00%13359月7日丽水D78210
4青田温溪港F-ENODEB已复位89.00%25280.00%0289月7日丽水D782039青田中学F-ENODEB已复位88
.00%1481670.00%01689月7日丽水D782012青田油竹桥头F-ENODEB已复位47.00%26550.00%0
559月7日丽水D786076遂昌云峰二F-ENODEB已复位79.00%19240.00%0219月7日丽水D780267莲都地
区医院（卫校）LY（中心医院）信源池D-ENODEB未复位（已验证存在单通）41.00%22530.00%0539月7日丽水D78
0565莲都东方宾馆LY（人民医院分布）信源池E-ENODEB未复位（已验证存在单通）32.00%491520.00%01522、
问题现象及初步分析：1、现场通过SEQ平台提取问题话单发现存在RTP包和RTCP包为0情况，并进行全网筛选统计发现有27个站点存在
类似情况；2、使用不同终端进行复测，均存在双不通现象，排除个别终端问题；3、终端侧log无线环境很好，信令面正常，排除无线环境问题
；4、核查RLC SN等相关参数，排除参数问题；5、19:35时安排现场再次进行复测并提取相关日志，复测时验证数据业务、CSFB正
常。同时采取不同测试用例进行验证测试：1）主被叫都在问题小区下，复现双不通。2）一部在正常小区下，一部在问题小区下，无论做主叫还是
被叫，仍然复现双不通。初步判定该小区语音业务上下行都存在问题。3、进一步提取异常日志分析发现问题小区下存在大量的获取PDCP pb
uf失败和ROHC解压缩失败告警怀疑双不通可能与ROHC头压缩有关，目前现场的头压缩总开关是开启的，0x0001关闭，0x0002
开启针对ROHC头压缩功能验证1、关闭ROHC总开关进行复测，小区通话正常2、打开总开关，打开0x0001关闭0x0002复现双不
通问题；3、打开总开关，关闭0x0001打开0x0002同样复现双不通4、打开总开关，关闭0x0001同时关闭0x0002小区通话
正常5、去激活小区和复位基站也都可以解决问题，但是这两种方式不可逆。验证结论： 0x0001和0x0002任何一个打开都会导致双不
通；关闭ROHC头压缩总开关或者把所以压缩方式都关闭，都可以解决问题。问题结论：目前分析初步怀疑，基站在空口无线环境差的时候，语音
RTP包如果产生10%以上的连续的丢包，存在一定概率的buffer泄露的情况，导致头压缩算法的内存分配失败，影响VOLTE的上下行
语音包发送和接收，从终端侧表现是信令面正常，但是语音单通。规避方法：关闭头压缩算法，这样在发送和接收语音包的时候不需要进行压缩，可
以规避；规避方案影响：评估关闭头压缩后会多占用0.5%的PRB，目前的VOLTE用户规模，不会对容量造成影响。（VOLTE业务20
ms调度周期，关闭头压缩后每次会多占用4个prb，平均到每个5ms半帧多1个prb，再计算上静默因子50%，总共100个prb，最
终估算，每5ms多占用0.5个prb） 解决方法：1、目前怀疑是PDCP头压缩 维护的链表出现耗尽的情况，具体挂住原因还在进一步定
位；2、在问题真正解决之前，申请把全网的头压缩开关暂时关闭进行验证，计划9月9日晚进行操作。案例三RLC层UM SN参数配置错误导
致单通问题描述：室分站点D780625莲都水木清华苑E发现信号都正常，数据业务和CSFB等都正常，但是打VOLTE电话互相都听不到
声音问题分析： 3个小区都存在问题，怀疑参数存在问题，现场在29日凌晨进行了参数修改。29日凌晨进行发送端RLC配置 UM SN长
度、接收端RLC配置 UM SN长度、2个参数的全网拉齐工作。发送端RLC配置 UM SN长度参数由5该为10、接收端RLC配置
UM SN长度参数由5改为10.在执行脚本的时候先由发送端RLC配置 UM SN长度参数修改，下发完成。如下图：在执行接收端RLC
配置 UM SN长度参数的时候由于设备掉线，D780625莲都水木清华苑E没有修改成功。脚本跑完时间为29日1点23分。由于发送端
RLC配置 UM SN长度已经执行完成。导致送端RLC配置 UM SN长度为10和接收端接收端RLC配置 UM SN长度5。 现场把发送端和接收端RLC配置UM SN长度同时改为5和10，保持一样，VOLTE业务就恢复正常。 咨询研发，关于这两个参数的含义：基站上的配置是按照Uu口协议设计的：接收端配置参数：应该通过空口信令配置给UE的接收端参数，基站应该使用该参数作为发送端参数；发送端配置参数：应该通过空口信令配置给UE的发送端参数，基站应该使用该参数作为接收端参数；而目前基站程序中存在bug，实现的现状是：接收端配置参数：通过空口信令配置给UE的接收端参数，基站使用该参数作为接收端参数；发送端配置参数：通过空口信令配置给UE的发送端参数，基站使用该参数作为发送端参数；问题结论：1、当QCI1使用的接收端参数和发送端配置不一致时，将导致基站的发送端和UE的接收端参数不一致，基站的接收端和UE的发送端参数不一致，从而导致空口数据解析不正确，造成QCI1承载上的数据全部丢包，现象就是听不到语音。2、在V3版本解决，BUG：DTMUC00306383解决方法：“发送端和接收端RLC配置UM SN长度”参数配置成一样 |
|
