利用RTP包分析提升VoLTE感知方法-USB迷|专注于互联网分享

2024年3月3日发(作者：鱼依萱)

利用RTP包分析提升VOLTE感知方法

一、【背景】

常见的语音感知问题有单通、断续、音质差、掉话等，Volte投诉的主要问题也将会是这些，导致以上问题的原因大都与RTP丢包、时延及抖动有关。众所周知，Volte感知需要通过端到端来界定分析，但目前电信网络中已具备端到端分析的省市尚不多，因此本文拟从无线侧分析UE测试 log和基站S1口抓包来界定问题边界，对RTP包的丢包、时延和抖动等指标来进行语音感知分析，最后结合案例来介绍无线侧分析RTP包方法。

二、【问题描述】

在用三星S7做VoLTE测试时，主叫手机在接通后过了20S主动上发Bye，Reason：RTP-RTCP Timeout（从sip-Ack到bye request时长为20S），导致掉线。在主叫事件窗口中出现MOS Single Mute，无MOS打分数值。如下图所示：

主叫信令窗口

bye主叫事件窗口

信令间隔20S

内容

被叫事件窗口

被叫MOS正常，周期8S，从16：06：56开始

被叫信令窗口

主叫RSRP/SINR时间轴图

PCI=73 PCI=74 PCI74

PCI=74 PCI=73

被叫RSRP/SINR时间轴图

PCI=73

三、【RTP分析方法】

3.1RTP包简介

RTP是实时传输协议，是Volte语音应用层使用协议，语音数据以如下结构进行发送。其中IP首部是IPV4时为20Byte，IPV6则为40Byte；UDP首部为8Byte；RTP首部为12Byte，RTP数据部分大小与编码速率及是否为静默帧有关。

RTP首部格式如下，在分析中常用到序号、时间戳、同步源标识符等。其中序号是指RTP报文的序列号，每发送一个报文就增加1，接收端通过序列号来检测报文丢失情况（丢包）。时间戳用来计算时延和抖动，与抽样频率有关，每个语音流以随机数开始，若抽样频率为16K，则两个相连RTP包之间差16000/（1000/20）=320，两个SID帧差16000/（1000/160）=2560。

RTP数据包即语音包，其大小与语音帧类型以及编码方式有关，如下为AMR-WB的各类型的包大小。静默期以160ms为周期进行传送（SID帧，大小是7Byte）。通话期以20ms周期进行传送，其大小取决于编码速率。以目前常见AMR-WB编码速率23.85kbps为例，其大小为23.85kbps*20ms=477bit，加上填充位和帧类型等，其大小为61Byte。

在无线侧分析语音感知问题时，通常分析到UDP层，因此，常见的2种类型UDP包大小分别是81B(对应23.85kbps)=61(RTP包大小)+12（RTP首部大小）+8（UDP首部大小），和27B（对应SID帧）=7（SID帧）+12（RTP首部）+8（UDP首部），其内容如下：

红框内容是分析时主要关注的信息，比如RTP包的方向，directiion=1是UE To Network，即上行；directiion =0是NetWork To UE，即下行。还有Marker=1代表语音包的起始等等。通过对比发送端和接收端的RTP包，即可得到RTP丢包、时延及抖动等数据，从而对语音感知进行分析。下面从UE侧和基站侧分别进行1

RTP包分析。

3.2UE侧分析方法

通过高通的QXDM或者鼎利的Pioneer可以收集UE的L1信息，查看IMS RTP

SN and Payload内容，可以对UE侧的RTP包进行分析。下面以Pioneer为例，在测试前，先按下图所示顺序进行设置，在软件右上角菜单里点击下拉，选择配置，再选择配置管理，在弹出窗口里选择高级，把手机信令保存设置勾选上，再点击确认即可。

设置好后就可以进行测试了，测试结束，打开测试log，在信令窗口，点击漏斗，把L1点亮，再在空白处点击下，即信令窗口会显示L1和L3内容。

然后点击查询，输入IMS RTP，弹出下来窗口，选择IMS RTP SN and Payload，双击后，再选择过滤，即把IMS RTP SN and Payload过滤出来了。

然后，双击IMS RTP SN and Payload，即可看到RTP包里的内容，如下所示。

在分析时，可以针对问题出现时的RTP包情况进行针对性分析，另外，软件也支持RTP丢包的统计，见IMS RTP Packet Loss，里面有丢包的内容。

另外，也可以把以上内容导出Excle来进行分析，方法如下：选择菜单，选择文件，点击导出数据。

弹出如下窗口，若已设置好导出模板，则在模板设置里选择模板，然后在添加里把需要导出的log选中，点击导出即可输出excle表。若没有设置过模板，则点击设置后，在弹出窗口中，在参数选择里把需要输出的参数放到已选参数里，然后在模板里输入模板名称，点击保存即可。

输出excel表内容格式如下，可以针对excle内容进行作图分析，可以按需输出，下面这个模板里有丢包、抖动、RTP Sequence、RTP Frame Type等等信息，也可以到Pioneer安装目录，直接把插件文件放到ExportTemplate目录下。

3.3基站侧分析方法

Volte的SIP信令以及RTP包在基站侧都是IPSec封装的，在基站侧通过TcpDump，可以把S1口的内容都抓取下来，然后通过Wireshark来打开。S1抓包内容如下图所示，可以通过输入ESP来过滤SIP信令，也可以通过IPv6和Stream号来过滤呼叫流程，然后对基站侧的RTP包与UE侧的RTP包进行关联分析，从而判断是核心网部分出问题，还是无线侧出问题。

SIP信令在基站内虽然是封装的，但在二进制里还是可以看到其详细内容的，里面有每条SIP信令的内容，比如From/To，CallID等，因此可以与空口内容进行关联。此外，也有第三方软件”流鲨FlowShark”，可以对S1抓包内容进行解码，可以按照呼叫流程显示，这就方便与空口内容进行关联比对了。

四、【问题分析处理】

4.1问题分析

单通在RTP包上可以表现为某段时间内只有单方向的RTP包，包括SID帧，目前鼎利软件是5S内只有单向包时，会判断为Sigle Mute。若连续20S时间单通的话，则会触发UE侧计时器超时，上发Bye来拆链，形成掉话，Cause：RTP-RCTP

Timeout（或者inactie timeout）。

断续或质差，通常是RTP有丢包或抖动较大，通常连续丢3个RTP就会出现吞字现象，而连续吞多个字就出现断续现象。

4.2单通且20S后掉话(RTP Timeout)

主被叫手机无线环境尚可，主被叫占用是PCI73/74，RSRP在-100dBm左右，SINR在6~10dB之间

主叫于16:07:09.851从PCI=73切换到74，被叫于16:07:01.301从74切换到73，被叫于16:07:04.438 MOS打分4.233，MOS打分周期是8S，即从16:06:56开始，从主叫放音，然后被叫进行MOS打分，此时被叫分别占用过PCI74和73，上下行均正常。

随后被叫放音，主叫打分，在此期间，主叫从PCI73切换到74，到打分周期结束，主叫显示MOS Single Mute（即单通），无MOS分，随后20S后主叫手机主动上发Bye（RTP-RTCP Timeout）。

下一次呼叫，主叫占用74，被叫占用73，主被叫正常MOS打分，通话正常。

从RTP包来进一步分析：

主叫在接通后先占用PCI73，还没开始切换，先开始放音，被叫录音，如下图所示，主叫16:06:54.950（UE To Networkd）端口765455，RTPTimestamp1728，Frame Type=8(23.85kbps)，即主叫上发23.85kpbs的语言帧，连续7个，第8个为SID帧(16:06:55.153)，RTPTimestamp3968（=1728+7*320）。被叫从16:06:55.013收到第一个主叫发的语言包，连续7个（到16:06:55.122）,第8个是SID帧。以上可以说明主叫上发的语言帧，被叫都收到了。随后，被叫上发了SID帧（端口767478），查看主叫流程，并没有收到。因此，说明主叫只有上行RTP包，没有下行RTP包，即单通。

第1个RTP包

第8个RTP包

主叫发的RTP1~8包在被叫收到

被叫发的SID帧在主叫没收到

再看主叫从PCI73切换到PCI74之后，被叫此时也已从PCI74切换到PCI73的RTP包，此时应该是被叫放音，主叫录音。主叫一直在向Network发SID帧，如下图，16:07:09.773与16:07:09.976(RTPTimestamp243968-241408=2560=8*320)，被叫可以收到这2个主叫发的SID帧，时间是16:07:09.991到16:07:10.132，在此期间，被叫上发了7个23.85kbps的语音帧，但主叫在此期间只有上行的SID帧，没有下行的RTP包，这也说明在切换后占用不同小区时，主叫仍然是上行正常，下行没有RTP包，即单通。

主叫连续2个SID帧,在被叫都收到

但被叫在2个SID帧之间上发RTP包主叫没有收到

以上是Pioneer软件里查看的信息，还可以用前面的导出模板导出csv文件进行作图。如下图所示，UE1是主叫，UE2是被叫，对主被叫的上下行RTP Sequence以及Payload进行作图，其中Payload=73对应23.85kbps的语音包，Payload=19对应SID帧。RTP Sequence按顺序递增，可以看到主叫UE1在开始时间段只有上行RTP包，没有下行RTP包，到16:07:45之后才有下行RTP包，而同样时间段，被叫UE2上下行RTP包都有，这是正常的，因此从主被叫的2张图可以看出主叫的下行无RTP包，形成单通。

450Payload=73是23.85kbps语音包

payload=19是SID帧

UE1此时才有下行8010016:06:54.95016:06:55.62316:06:56.41916:06:56.63716:06:56.85516:06:57.07416:06:57.30816:06:57.52616:06:57.72916:06:57.94716:06:59.19516:07:00.11616:07:00.33416:07:00.55316:07:00.77116:07:00.98916:07:01.22316:07:01.44216:07:01.66016:07:01.87916:07:02.09716:07:02.31516:07:03.70516:07:05.45216:07:07.23016:07:08.97716:07:10.74016:07:12.31116:07:12.52116:07:12.73116:07:12.95116:07:13.19116:07:13.40116:07:13.61616:07:13.83516:07:14.10016:07:46.112UE1 DL RTP Sequence NumberUE1 UL RTP Sequence NumberUE1 RTP Payload Size

300500录音间隙，上下行都是SID帧

8010016:06:54.79416:06:54.98116:06:55.12216:06:55.70116:06:56.32516:06:56.46516:06:56.60616:06:56.76216:06:56.88716:06:57.04316:06:57.16716:06:57.32316:06:57.44816:06:57.62016:06:57.72916:06:57.88516:06:58.02516:06:58.50916:06:59.14916:06:59.78816:07:00.13116:07:00.27216:07:00.41216:07:00.56816:07:00.70916:07:00.81816:07:00.97416:07:01.13016:07:01.27016:07:01.42616:07:01.56716:07:01.69116:07:01.84716:07:01.97216:07:02.12816:07:02.25316:07:02.42516:07:02.986UE2 DL RTP Sequence NumberUE2 UL RTP Sequence NumberUE2 RTP Payload Size

由于测试时并未进行基站侧S1抓包，因此尚无法完全确定是核心网问题还是无线侧问题，后续测试还遇到过1次，但也未同时进行S1抓包。专门安排复测并未复现。

4.3断续或质差问题

如下图所示，被叫UE2在16:08:59.652和16:09:15.613时，MOS打分仅2.626和2.56。此时RSRP-100dBm，SINR11.9dB，在信令窗口过滤L1的IMS RTP Packet

Loss，可以看到16:08:53.138的RTP Packet Loss显示有14个RTP包丢了，在16:09:13.006时也有14个RTP包丢了，中间一次丢了1个RTP包。再把Voice

RFC1889 Jitter用Table表显示，可以看到对应时段的抖动情况尚好，packet

delay也好，因此，可以判断主要是被叫的下行RTP丢包影响了MOS值，需要结合基站侧的S1抓包，看基站侧是否也存在下行RTP丢包。

五、【问题总结】

通过Pioneer的UE log以及基站侧的S1抓包的关联进行RTP包分析，可以用来分析Volte语音感知中的单通、断续或质差等问题。另外，从Pioneer导出的CSV文件作图，可以清晰看出单通问题。