rtcp丢包抖动时延计算原理
丢包延迟抖动测试方法
丢包延迟抖动测试方法一、引言丢包延迟抖动测试是网络性能测试中常用的一种方法。
通过测试网络的丢包率、延迟和抖动情况，可以评估网络的稳定性和性能。
本文将介绍丢包延迟抖动测试的方法和步骤，以帮助读者更好地了解和应用这一测试方法。
二、丢包测试丢包是指在网络传输过程中丢失的数据包。
丢包率是衡量网络稳定性的重要指标之一。
为了测试网络的丢包率，可以使用ping命令。
在命令行中输入“ping IP地址”，系统会向目标地址发送数据包，并等待目标地址返回响应。
通过统计发送和接收的数据包数量，可以计算出丢包率。
在进行丢包测试时，需要注意以下几点：1. 测试时应选择合适的目标地址，可以选择与本地网络相连的服务器或路由器。
2. 测试时应选择合适的数据包大小，一般来说，较小的数据包更容易丢失，较大的数据包更能反映网络的真实情况。
3. 测试时应选择合适的测试时间，通常建议测试时间不少于1分钟，以获取更准确的丢包率。
三、延迟测试延迟是指数据包从发送端到接收端所需的时间。
延迟测试可以通过ping命令或专业的网络测试工具来进行。
在ping命令中，可以通过“ping -n 次数IP地址”来指定测试次数，系统会向目标地址发送数据包，并记录下每个数据包的往返时间。
通过统计这些时间，可以计算出平均延迟。
在进行延迟测试时，需要注意以下几点：1. 测试时应选择合适的目标地址，可以选择与本地网络相连的服务器或路由器。
2. 测试时应选择合适的测试次数，通常建议测试次数不少于100次，以获取更准确的延迟值。
3. 测试时应选择合适的时间段，避免网络繁忙时进行测试，以保证测试结果的准确性。
四、抖动测试抖动是指网络延迟的变化波动。
抖动测试可以通过专业的网络测试工具来进行。
这些工具可以记录下每个数据包的往返时间，并计算出延迟的变化范围。
通常，抖动较小的网络延迟更稳定，抖动较大的网络延迟更不稳定。
在进行抖动测试时，需要注意以下几点：1. 测试时应选择合适的目标地址，可以选择与本地网络相连的服务器或路由器。
ping、网络抖动与丢包
ping、网络抖动与丢包
ping、⽹络抖动与丢包
基本概念：
ping:
PING指⽹个数据包从⽹户的设备发送到测速点，然后再⽹即从测速点返回⽹户设备的来回时间。
也就是俗称的“⽹络延迟”
⽹般以毫秒（ms）计算
⽹般PING在0~100ms都是正常的速度，不会有较为明显的卡顿。
测试ping值⽹法：
在powershell中输⽹ping [⽹络地址]即可测试，默认会测4次。
如果需要测更多次，则把命令改为ping [⽹络地址] -t。
通过Ctrl+C⽹动结束。
⽹络抖动：
⽹络抖动是指最⽹延迟与最⽹延迟的时间差，如最⽹延迟是20毫秒，最⽹延迟为5毫秒，那么⽹络抖动就是15毫秒，它主要标识⽹个⽹络的稳定性。
抖动越⽹，⽹络越稳定。
丢包：
丢包是指⽹个或多个数据包的数据⽹法通过⽹络到达⽹的地。
可能原因是多⽹⽹的，或是⽹络中多路径衰落造成信号衰减；或是通道阻塞造成丢包；或是损坏的数据包被拒绝通过等等。
接收端如果发现数据丢失，会根据队列序号向发送端发出请求，进⽹丢包重传。
04-RTP和RTCP协议原理
HUAWEI TECHNOLOGIES CO., LTD.
Page 8
第1章 RTP/RTCP概述
1.1 RTP/RTCP简介 1.2 RTP/RTCP功能 1.3 RTP工作原理
HUAWEI TECHNOLOGIES CO., LTD.
Page 9
1.2 RTP功能
RTP在VoIP中的作用为：
HUAWEI TECHNOLOGIES CO., LTD.
Page 4
第1章 RTP/RTCP概述
1.1 RTP/RTCP简介 1.2 RTP/RTCP功能 1.3 RTP工作原理
HUAWEI TECHNOLOGIES CO., LTD.
Page 5
1.1 RTP/RTCP简介--多媒体服务
多媒体服务特点:
域名 长度（bit） 2 定义了RTP的版本，此协议定义的版本是2。 含义
Version （V）
Padding （P）
Item count （IC）
1
如果填充位被设置为1，则一个或多个附加的字节会加在包头的最后， 附加的最后一个字节放置附加的字节数。填充可能用于某些具有固定长 度的加密算法，或者在底层数据单元中传输多个RTP包。
第2章 RTP/RTCP报文格式
2.1 RTP报文格式 2.2 RTCP报文格式
HUAWEI TECHNOLOGIES CO., LTD.
Page 24
2.2 RTCP报文格式--报文类型
在RTP的规范（RFC 3550）中，一共定义了5种RTCP报告用来报告当前控制信息：
Packet Type值
NTP timestamp
RTP timestamp Sender's packet count
5g抖动时延丢包指标 -回复
5g抖动时延丢包指标-回复5G抖动、时延、丢包指标是评估5G网络性能和稳定性的重要指标。
本文将从什么是5G抖动、时延和丢包开始，介绍它们的定义和计算方法，并探讨它们对5G网络的影响以及相关的解决方案。
第一部分：什么是5G抖动、时延和丢包抖动（Jitter）是指数据包到达目的地的时间间隔的不稳定性。
在5G网络中，抖动是指信号在传输过程中的时延变化。
时延（Delay）是信号从发出到接收所需的时间。
丢包（Packet Loss）是指在信号传输过程中丢失的数据包。
第二部分：5G抖动、时延和丢包的定义和计算方法1. 5G抖动的定义和计算方法：5G抖动是指信号在传输过程中的时延变化。
计算5G抖动的方法是，首先测量多个数据包的到达时间间隔，然后计算这些时间间隔的标准差。
2. 5G时延的定义和计算方法：5G时延是信号从发出到接收所需的时间。
计算5G时延的方法是，测量发送数据包的时间戳和接收数据包的时间戳之间的差值，并取平均值。
3. 5G丢包的定义和计算方法：5G丢包是指在信号传输过程中丢失的数据包。
计算5G丢包的方法是，统计发送数据包和接收数据包之间丢失的数据包数量，并计算丢包率。
第三部分：5G抖动、时延和丢包对网络的影响1. 5G抖动对网络的影响：抖动会导致信号传输中的时延变化，使得接收端无法按时接收数据包。
这会影响音视频通信的质量，引起卡顿和延迟。
2. 5G时延对网络的影响：时延过大会导致实时应用的体验下降。
例如，在云游戏中，高时延会导致操作延迟，影响游戏体验；在远程医疗中，高时延可能导致医生和患者之间的通信不流畅。
3. 5G丢包对网络的影响：丢包会导致数据传输的不完整，降低网络传输的可靠性。
在实时应用中，如视频通话和在线会议中，丢包会导致画面和声音的断断续续，影响用户体验。
第四部分：解决5G抖动、时延和丢包的方案1. 优化网络拓扑结构：通过优化网络拓扑结构，减少网络节点之间的跳数，降低信号传输的延迟和抖动。
5g抖动时延丢包指标 -回复
5g抖动时延丢包指标-回复什么是5G抖动、时延、丢包指标？在讨论5G抖动、时延和丢包指标之前，我们需要先了解5G技术的基本概念。
5G是第五代移动通信技术，是对现有4G网络进行改进和升级的新一代无线通信技术。
在高速移动通信和大容量数据传输方面，5G具有更快的传输速度、更低的时延、更高的数据容量等优势。
抖动（Jitter）是指数据在传输过程中的时间变化或波动。
在网络中，抖动是网络性能稳定性的一个重要指标。
抖动越小，代表网络传输的稳定性越高。
抖动较大的网络可能会导致数据丢失或接收端数据缺失，同时也会使数据传输的可靠性下降。
时延（Latency）是指网络中数据传输所需时间的度量。
时延可以分为往返时延（Round-Trip Time, RTT）和单程时延（One-Way Delay, OWD）。
往返时延是指从发送端发送数据到接收端接收到确认信号所需的时间；单程时延是指从发送端发送数据到接收端接收到数据所需的时间。
时延越小，代表数据在网络中传输的速度越快，通信的响应时间也越短。
丢包（Packet Loss）是指网络中数据包在传输过程中丢失或错误的现象。
丢包率是描述数据传输过程中丢失数据包数量所占比例的指标。
丢包率的大小直接影响网络传输的质量和可靠性。
丢包率越低，代表网络传输的稳定性和可靠性越高。
为什么5G抖动、时延、丢包指标重要？5G技术的发展使得移动互联网的应用越来越广泛。
高速移动通信和大容量数据传输已成为许多应用领域的基本需求，如智能医疗、智能交通、工业自动化等。
对于这些对网络稳定性和传输性能要求较高的应用而言，抖动、时延和丢包等指标的优化是至关重要的。
抖动的控制对于实时通信应用非常重要，如视频通话、在线游戏等。
如果抖动过大，会导致视频卡顿、声音不同步等问题，影响用户体验。
通过优化网络拓扑结构、提高网络带宽、使用网络流量控制机制等方法，可以减少抖动的发生，提高通信质量。
时延的控制对于许多应用场景非常关键，如自动驾驶汽车、远程手术等。
如何测试延时、抖动、丢包率
如何测试延时、抖动、丢包率？延时、抖动、丢包率各个数据的含义是什么？很简单，在Windows的左下角点击"开始"，选"运行"，键入 cmd 回车，就可以进入DOS窗口，在DOS命令状态下输入：ping 202.105.135.211就会得到下面的结果：Pinging 202.105.135.211 with 32 bytes of data:Reply from 202.105.135.211: bytes=32 time=93ms TTL=42Reply from 202.105.135.211: bytes=32 time=86ms TTL=42Reply from 202.105.135.211: bytes=32 time=81ms TTL=42Reply from 202.105.135.211: bytes=32 time=80ms TTL=42Ping statistics for 202.105.135.211:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 80ms, Maximum = 93ms, Average = 85ms这里面，丢包率0%,抖动是-5ms到+8ms，延时是 85ms（毫秒），测试另外两个IP地址，可以看到：Pinging 221.221.23.7 with 32 bytes of data:Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=60ms TTL=48Reply from 221.221.23.7: bytes=32 time=113ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=52ms TTL=48Reply from 221.221.23.7: bytes=32 time=58ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=112ms TTL=48Reply from 221.221.23.7: bytes=32 time=76ms TTL=48Reply from 221.221.23.7: bytes=32 time=154ms TTL=48Ping statistics for 221.221.23.7:Packets: Sent = 16, Received = 16, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 26ms, Maximum = 154ms, Average = 54ms丢包率0%,抖动是-28ms到+100ms，延时是 54ms（毫秒）Pinging 221.221.23.209 with 32 bytes of data:Reply from 221.221.23.209: bytes=32 time=885ms TTL=48Reply from 221.221.23.209: bytes=32 time=688ms TTL=48Reply from 221.221.23.209: bytes=32 time=482ms TTL=48Reply from 221.221.23.209: bytes=32 time=119ms TTL=48Reply from 221.221.23.209: bytes=32 time=61ms TTL=48Reply from 221.221.23.209: bytes=32 time=456ms TTL=48Reply from 221.221.23.209: bytes=32 time=962ms TTL=48Reply from 221.221.23.209: bytes=32 time=890ms TTL=48Reply from 221.221.23.209: bytes=32 time=939ms TTL=48Reply from 221.221.23.209: bytes=32 time=891ms TTL=48Reply from 221.221.23.209: bytes=32 time=141ms TTL=48Reply from 221.221.23.209: bytes=32 time=420ms TTL=48Reply from 221.221.23.209: bytes=32 time=517ms TTL=48Reply from 221.221.23.209: bytes=32 time=463ms TTL=48Reply from 221.221.23.209: bytes=32 time=798ms TTL=48Reply from 221.221.23.209: bytes=32 time=451ms TTL=48Reply from 221.221.23.209: bytes=32 time=604ms TTL=48Ping statistics for 221.221.23.209:Packets: Sent = 17, Received = 17, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 61ms, Maximum = 962ms, Average = 574ms丢包率0%,抖动是-511ms到+488ms，延时是 574ms（毫秒）从上面3个结果看，第一组延时小，第三组延时大，丢包率为0％，第二组抖动大不可用，第三组延时、抖动都大，也不可用。
4G优化案例：VoLTE语音质量优化方法总结
VoLTE语音质量优化方法总结XX1VoLTE语音质量分析 (4)1.1VoLTE语音编码 (4)1.2RTP包解析 (5)1.3RTCP包解析 (6)2VoLTE语音质量指标定义 (9)2.1感知平台语音质量指标 (9)2.1.1RTP包采集说明 (10)2.1.2吞字、断续、单通的定义 (12)2.1.3感知平台MOS评估 (13)2.2网优平台语音质量指标 (14)2.3路测语音质量指标 (15)3VoLTE语音质量参数优化 (15)3.1优化参数 (15)3.1.1调度类参数 (15)3.1.2头压缩（ROHC）功能 (16)3.1.3上下行最大HARQ重传次数 (17)3.1.4上行闭环功控门限 (18)3.1.5上行合并（UL CoMP）功能 (19)3.1.6上行补偿调度（QCI1） (20)3.1.7TTIB功能 (21)3.1.8切换优化 (22)3.2参数试验 (22)3.2.1试验1 调度类参数改善上下行空口丢包 (22)3.2.2试验2 ROHC（头压缩）功能改善上下行空口丢包 (23)3.2.3试验3 增加QCI1上下行最大HARQ重传次数降低上下行空口丢包 (24)3.2.4试验4 上行闭环功控门限参数优化降低上下行空口丢包 (24)3.2.5试验5 UL CoMP功能开启降低上行空口丢包 (25)3.2.6试验6 上行补偿调度功能降低空口丢包 (26)4VoLTE语音质量TOP小区优化 (26)4.1TOP小区定义 (26)4.1.1集团高丢包工单 (26)4.1.2省内感知平台派单 (27)4.2TOP小区优化 (27)4.2.1概述 (27)4.2.2覆盖问题及优化 (28)4.2.3上行干扰问题及优化 (29)4.2.4下行干扰问题及优化 (31)4.2.5容量类问题及优化 (31)4.2.6邻区问题及优化 (32)4.2.7参数类优化 (33)5优化参数汇总 (35)5.1大网语音相关的基线参数 (35)5.2语音质量TOP小区优化参数 (37)1 VoLTE 语音质量分析VoLTE 语音模型如下，分为通话期与静默期，其中通话期每隔20ms 发送一次，其大小取决于编码速率，静默期每隔160ms 发送一次，为SID 帧（静默指示符），大小是7Byte 。
5g抖动时延丢包指标 -回复
5g抖动时延丢包指标-回复5g抖动时延丢包指标是评估5G网络质量和性能的重要指标之一。
在本文中，我将一步一步回答关于这个指标的问题，从定义、影响因素到解决方法等方面进行详细解析。
一、什么是5g抖动时延丢包指标？1.定义：5g抖动是指数据传输过程中，网络延迟不稳定的现象，即传输延迟的波动。
而时延是指数据在网络中传输所需要花费的时间。
丢包则是指在数据传输过程中由于各种原因导致数据包丢失的情况。
2.意义：5G网络的设计目标是提供低时延、高速率和可靠性强的服务，因此抖动时延和丢包指标的评估可以帮助运营商和网络管理员了解网络性能是否满足用户的需求，并进行相应的优化和改进。
二、抖动时延和丢包的影响因素1.网络拥塞：当网络负载过大时，传输延迟会增加，进而导致抖动和丢包现象。
而丢包率的增加也会引起抖动。
2.链路质量：网络链路的质量直接影响到网络的抖动和丢包。
例如，信号干扰、传输介质的质量、链路的带宽等都可能导致抖动和丢包的增加。
3.网络设备性能：路由器、交换机等网络设备的性能也会影响到网络的抖动和丢包。
例如，设备负载过高、硬件故障等都可能导致抖动和丢包的发生。
三、如何评估5G网络的抖动时延丢包指标？1.选择评估指标：常用的5G抖动时延丢包指标有平均抖动时延、最大抖动时延、Jitter值、丢包率等。
选择合适的指标进行评估可以更全面地了解5G网络的质量和性能。
2.数据采集与分析：通过在5G网络上设置监控点，实时采集网络延迟和丢包情况，并对数据进行分析。
可以使用网络性能管理工具或采集技术进行数据的获取和分析。
3.制定评估标准：根据实际需求和网络性能要求，制定相应的评估标准。
例如，平均抖动时延在多少范围内属于正常水平，丢包率达到多少才需要进行优化等。
4.评估结果分析：根据数据分析结果，判断网络的抖动时延和丢包情况是否满足要求。
如果存在问题，可以进一步分析影响因素，找出问题的根源。
四、如何改善5G网络的抖动时延丢包指标？1.网络优化：根据评估结果分析的影响因素，针对网络拥塞、链路质量等问题进行相应的网络优化工作。
rtcp丢包抖动时延计算原理
RTP/RTCP 丢包/抖动/时延计算原理1.RTP/RTCP的基本功能介绍实时传输协议RTP（A Transport Protocol for Real-Time Application）提供实时的端对端传输业务（如交互的语音和图象），包括负载类型标识，序列号，时间戳，传输监视。
实时传输协议（RTP）本身并不提供任何机制保证实时传输或业务质量保证，而是让底层协议去实现。
RTP包括两个紧密相关的部分：实时传输协议（RTP－Real Time Transport Protocol），传输有实时特性的信息；RTP控制协议（RTCP－RTP Control Protocol），监视业务质量和传输对话中成员的信息。
RTP/RTCP报文封装格式为：DL+IP+UDP+RTP/RTCP2.RTP报文统计方法介绍RTP报文发送统计：NTP时间标志：64比特，指示了此报告发送时的壁钟（wallclock）时刻，它可以与从其它接收者返回的接收报告块中的时间标志结合起来，测量到这些接收者的环路时延。
RTP时间标志：32比特，与以上的NTP时间标志对应同一时刻，但是与数据包中的RTP时间标志具有相同的单位和偏移量。
发送包数：32比特，从开始传输到此SR包产生时该发送者发送的RTP数据包总数。
若发送者改变SSRC识别符，该计数器重设。
发送字节数：32比特，从开始传输到此SR包产生时该发送者在RTP数据包发送的字节总数（不包括头和填充）。
若发送者改变SSRC识别符，该计数器重设。
RTP报文接收统计：丢包率：8比特，自从前一SR包或RR包发送以来，从SSRC_n传来的RTP数据包的损失比例，以固定点小数的形式表示，小数点在此域的左侧，等于将丢包率乘256后取整数部分。
该值定义为损失包数被期望接收的包数除。
（对应RTCP消息中的丢包率时，除以256再乘以100即可，如为127，则丢包率为50%。
）累计包损：24比特，从开始接收到现在，从源SSRC_n 发到本源的RTP 数据包的丢包总数。
如何测试延时、抖动、丢包率
如何测试延时、抖动、丢包率如何测试延时、抖动、丢包率？延时、抖动、丢包率各个数据的含义是什么？很简单，在Windows的左下角点击"开始"，选"运行"，键入 cmd 回车，就可以进入DOS窗口，在DOS命令状态下输入：ping 202.105.135.211就会得到下面的结果：Pinging 202.105.135.211 with 32 bytes of data:Reply from 202.105.135.211: bytes=32 time=93ms TTL=42 Reply from 202.105.135.211: bytes=32 time=86ms TTL=42 Reply from 202.105.135.211: bytes=32 time=81ms TTL=42 Reply from 202.105.135.211: bytes=32 time=80ms TTL=42 Ping statistics for 202.105.135.211:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 80ms, Maximum = 93ms, Average = 85ms这里面，丢包率0%,抖动是-5ms到+8ms，延时是85ms（毫秒），测试另外两个IP地址，可以看到：Pinging 221.221.23.7 with 32 bytes of data:Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=60ms TTL=48Reply from 221.221.23.7: bytes=32 time=113ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=52ms TTL=48Reply from 221.221.23.7: bytes=32 time=58ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=112ms TTL=48Reply from 221.221.23.7: bytes=32 time=76ms TTL=48Reply from 221.221.23.7: bytes=32 time=154ms TTL=48Ping statistics for 221.221.23.7:Packets: Sent = 16, Received = 16, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 26ms, Maximum = 154ms, Average = 54ms丢包率0%,抖动是-28ms到+100ms，延时是54ms（毫秒）Pinging 221.221.23.209 with 32 bytes of data:Reply from 221.221.23.209: bytes=32 time=885ms TTL=48 Reply from 221.221.23.209: bytes=32 time=688ms TTL=48 Reply from 221.221.23.209: bytes=32 time=482ms TTL=48 Reply from 221.221.23.209: bytes=32 time=119ms TTL=48 Reply from 221.221.23.209: bytes=32 time=61ms TTL=48Reply from 221.221.23.209: bytes=32 time=456ms TTL=48 Reply from 221.221.23.209: bytes=32 time=962ms TTL=48 Reply from 221.221.23.209: bytes=32 time=890ms TTL=48 Reply from 221.221.23.209: bytes=32 time=939ms TTL=48 Reply from 221.221.23.209: bytes=32 time=891ms TTL=48 Reply from 221.221.23.209: bytes=32 time=141ms TTL=48 Reply from 221.221.23.209: bytes=32 time=420ms TTL=48 Reply from 221.221.23.209: bytes=32 time=517ms TTL=48 Reply from 221.221.23.209: bytes=32 time=463ms TTL=48 Reply from 221.221.23.209: bytes=32 time=798ms TTL=48 Reply from 221.221.23.209: bytes=32 time=451ms TTL=48 Reply from 221.221.23.209: bytes=32 time=604ms TTL=48 Ping statistics for 221.221.23.209:Packets: Sent = 17, Received = 17, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 61ms, Maximum = 962ms, Average = 574ms丢包率0%,抖动是-511ms到+488ms，延时是 574ms（毫秒）从上面3个结果看，第一组延时小，第三组延时大，丢包率为0％，第二组抖动大不可用，第三组延时、抖动都大，也不可用。
时延抖动概念
1、时延时延是指数据包第一个比特进入路由器到最后一比特从路由器输出的时间间隔。
在测试中通常使用测试仪表发出测试包到收到数据包的时间间隔。
时延与数据包长相关，通常在路由器端口吞吐量范围内测试，超过吞吐量测试该指标没有意义。
时延的产生有多种因素，下面列出了主要的时延源：编码的处理：模拟形式的声音信号在CODEC被采样和量化为PCM信号，DSP对PCM 信号进行压缩处理所产生的时延为编码处理时延。
这种时延产生在设备侧，如果设备的编码器固定，则编码时延也固定。
包化：包化就是将编码器输出的语音净荷放置到RTP/UDP/IP包中的过程，相对于编码的时延，包化的时延很小，因为包化的过程没有复杂的运算，仅仅是增加包头和计算校验和，而编码则有大量的数学运算。
队列（Queuing）：语音的净荷放置到IP包中后，要被设备转发到目的地，这些包会在设备的出接口队列中，等待被调度。
转发设备不同的队列机制对IP包的处理有很大不同。
可以通过合理的配置来减少语音包在队列中等待的时间，进而减少队列时延。
串行化（Serialization）：接口队列中的语音IP包，被送离设备前会放置到接口的物理队列当中，如果物理队列中有一个较大分组，还在发送状态，则语音分组必须等待这个较大的分组发送完毕后才能发送，这个等待的时间就是串行化时延。
比如一个时钟速率为64kbps 的链路要发送一个1600Bytes大小的FTP分组，则串行化产生的时延会达到200ms （1600×8/64000×1000）。
这对于后面等待的语音包来说已经是很大的时延了。
广域网时延：对于ISP提供的广域网链路，对于用户来说只是一个黑盒子，除了上述的编码时延外，构成广域网链路的路由器交换机都会产生包化、队列、串行化的时延。
而且到达同一目的的路径不同，其每个包的时延也不同，而这些时延对于用户来说是不可控的，当然我们在租用ISP的线路时，可以要求ISP提供符合时延要求的线路。
如何测试延时、抖动、丢包率
如何测试延时、抖动、丢包率？延时、抖动、丢包率各个数据的含义是什么？很简单，在Windows的左下角点击"开始"，选"运行"，键入 cmd 回车，就可以进入DOS窗口，在DOS命令状态下输入：ping 202.105.135.211就会得到下面的结果：Pinging 202.105.135.211 with 32 bytes of data:Reply from 202.105.135.211: bytes=32 time=93ms TTL=42Reply from 202.105.135.211: bytes=32 time=86ms TTL=42Reply from 202.105.135.211: bytes=32 time=81ms TTL=42Reply from 202.105.135.211: bytes=32 time=80ms TTL=42Ping statistics for 202.105.135.211:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 80ms, Maximum = 93ms, Average = 85ms这里面，丢包率0%,抖动是-5ms到+8ms，延时是 85ms（毫秒），测试另外两个IP地址，可以看到：Pinging 221.221.23.7 with 32 bytes of data:Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=26ms TTL=48Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=28ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=60ms TTL=48Reply from 221.221.23.7: bytes=32 time=113ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=52ms TTL=48Reply from 221.221.23.7: bytes=32 time=58ms TTL=48Reply from 221.221.23.7: bytes=32 time=27ms TTL=48Reply from 221.221.23.7: bytes=32 time=112ms TTL=48Reply from 221.221.23.7: bytes=32 time=76ms TTL=48Reply from 221.221.23.7: bytes=32 time=154ms TTL=48Ping statistics for 221.221.23.7:Packets: Sent = 16, Received = 16, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 26ms, Maximum = 154ms, Average = 54ms丢包率0%,抖动是-28ms到+100ms，延时是 54ms（毫秒）Pinging 221.221.23.209 with 32 bytes of data:Reply from 221.221.23.209: bytes=32 time=885ms TTL=48Reply from 221.221.23.209: bytes=32 time=688ms TTL=48Reply from 221.221.23.209: bytes=32 time=482ms TTL=48Reply from 221.221.23.209: bytes=32 time=119ms TTL=48Reply from 221.221.23.209: bytes=32 time=61ms TTL=48Reply from 221.221.23.209: bytes=32 time=456ms TTL=48Reply from 221.221.23.209: bytes=32 time=962ms TTL=48Reply from 221.221.23.209: bytes=32 time=890ms TTL=48Reply from 221.221.23.209: bytes=32 time=939ms TTL=48Reply from 221.221.23.209: bytes=32 time=891ms TTL=48Reply from 221.221.23.209: bytes=32 time=141ms TTL=48Reply from 221.221.23.209: bytes=32 time=420ms TTL=48Reply from 221.221.23.209: bytes=32 time=517ms TTL=48Reply from 221.221.23.209: bytes=32 time=463ms TTL=48Reply from 221.221.23.209: bytes=32 time=798ms TTL=48Reply from 221.221.23.209: bytes=32 time=451ms TTL=48Reply from 221.221.23.209: bytes=32 time=604ms TTL=48Ping statistics for 221.221.23.209:Packets: Sent = 17, Received = 17, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 61ms, Maximum = 962ms, Average = 574ms丢包率0%,抖动是-511ms到+488ms，延时是 574ms（毫秒）从上面3个结果看，第一组延时小，第三组延时大，丢包率为0％，第二组抖动大不可用，第三组延时、抖动都大，也不可用。
gstreamer rtpjitterbuffer 原理
GStreamer是一个构建媒体处理组件图的库，它提供了一系列工具来处理和传输音频和视频数据。
在GStreamer中，`rtpjitterbuffer`是一个用于处理RTP（实时传输协议）流中的抖动的插件。
抖动是指由于网络延迟波动造成的数据包到达时间的不一致性，这可能导致媒体播放出现杂音或图像抖动等问题。
`rtpjitterbuffer`的原理主要涉及以下几个方面：1. **数据包缓冲**：`rtpjitterbuffer`会将接收到的RTP数据包存入内部缓冲区。
这些数据包可能会因为网络抖动而乱序到达，所以需要重新排序。
2. **重排序**：缓冲区内的数据包会根据它们的序列号进行排序。
序列号是RTP头部的一部分，用于标识数据包的顺序。
正确的顺序对于解码器正确解码音视频流至关重要。
3. **延迟播放**：为了减少抖动带来的影响，`rtpjitterbuffer`会引入一定的延迟。
这意味着即使数据包早到，也不会立即被处理，而是等待直到一个预设的时间点。
这样可以为之后到达的乱序包提供时间进行排序，并确保连续的数据流。
4. **丢包处理**：在网络传输过程中，数据包可能会丢失。
`rtpjitterbuffer`可以通过各种机制来处理丢包情况，例如利用前后相邻的数据包来估计丢失包的内容，或者使用特殊的FEC（Forward Error Correction，前向错误纠正）技术来恢复丢失的数据。
5. **超时处理**：如果一个数据包在超过特定时间后仍未到达，`rtpjitterbuffer`可能会判定该数据包已经丢失，并根据配置的策略进行处理，比如跳过或者插入静音/黑帧等。
6. **适应性调整**：`rtpjitterbuffer`还可能实现一些适应性算法，根据网络状况动态调整缓冲时间，以优化播放体验和减少延迟。
`rtpjitterbuffer`通常配合其他GStreamer插件使用，比如`rtpbin`，它封装了多个与RTP 相关的功能，包括`rtpjitterbuffer`，以便于处理复杂的RTP流媒体场景。
宁波MOSRTP丢包率和抖动时延的优化小结v1.0
MOS, RTP丢包率和抖动时延的优化小结Contents1概述 (2)2参数实验及验证 (3)2.1两站之间参数实验 (3)2.2小范围实验 (4)2.3网格内参数实验 (5)3Qci1drx参数调整指标对比 (6)3.1Qci1drx关闭 (6)3.2Qci1drx打开周期20ms（SR周期20ms） (7)4SR周期调整指标对比 (8)4.1SR周期20ms/80ms对比 (8)4.2Qci1drx关闭及SR周期统一20ms (9)4.3下行Packet aggregation关闭 (10)5RTP抖动感知测试 (11)5.1测试背景 (11)5.2测试结果 (11)6总结 (12)6.1最优配置 (12)6.2Qci1drx打开后最优配置 (12)7附录 (12)7.1被叫BYE丢失（跟踪） (12)7.2主叫上发Cancel+专载未建立（跟踪） (13)7.3无线质量类 (14)1 概述2015年12月省公司对宁波地市进行摸底测试，省公司测试队伍提供的全国范围指标如下：其中：1、RTP丢包率，全国范围1.97%~0.21%；2、RTP抖动(ms)，全国范围14.06~3。
宁波测试完，RTP丢包率、RTP抖动指标较杭州指标有明显差的情况，详细指标如下：1、RTP丢包率1.25%虽然在全国测试范围内，但是较杭州以及其他地市指标有一定的差距。
2、RTP抖动，明显异常，比全国测试区间还要高。
详细网格指标见附件：宁波杭州测试指标.xlsx针对MOS值、RTP丢包率、RTP抖动率，进行了大量参数实验，实验证明：1、Qci1drx相关参数与MOS值、RTP丢包率有较大关联；2、SR周期参数与RTP抖动率有较大关联。
2 参数实验及验证2.1 两站之间参数实验实验区域：江北宁慈中路进行了切换实验，覆盖该道路NBJB横峰堰FHTL-2，NBJB朝东屋FHTL-3。
测试方法：长call，每种配置下在该路段匀速行驶，往返3次。
什么是时延和抖动
什么是时延和抖动1.时延什么是时延（Delay）？时延很好理解，就是我说话你听见的这个时间段。
对于VOIP网络可以认为是端到端包传递的时间。
如果大家以前用卫星线路打过电话或前些年的免费PC-TO-PHONE的VOIP国际长途电话，大家会切身感觉到时延对我们通话的影响。
ITU G.114规范建议，在传输语音流量时,单向语音包端到端延迟要低于150ms(对于国际长途呼叫,特别是卫星传输时,可接受的单向延迟为300ms。
如果超过300ms则通话的质量会变的让人不能忍受。
过多的包延迟可以引起通话声音不清晰、不连贯或破碎。
例如，当通话的一方不能及时接收到期望的回复时，说话者可能会重复所说的话，这样会与远端延迟的回复碰撞，导致重复。
大的时延也往往说明承载网络的某个地方发生了拥塞，队列中的报文等待时间过长，拥塞不仅仅是增加了包的时延，而很可能导致部分包被丢弃，这时听者会感觉到声音会发生异变、破碎。
大多数用户察觉不到小于100毫秒的延迟，当延迟在100毫秒和300毫秒之间时，说话者可以察觉到对方回复的轻微停顿。
这种停顿可以影响到通话双方的交流。
超过300毫秒，延迟就会很明显，用户开始互相等待对方的回复，通话过程变成类似对讲机式的模式。
而且较长的时延也会将回声问题的影响放大。
时延的产生有多种因素，下面列出了主要的时延源：编码的处理：模拟形式的声音信号在CODEC被采样和量化为PCM信号，DSP对PCM信号进行压缩处理所产生的时延为编码处理时延。
这种时延产生在设备侧，如果设备的编码器固定，则编码时延也固定。
包化：包化就是将编码器输出的语音净荷放置到RTP/UDP/IP包中的过程，相对于编码的时延，包化的时延很小，因为包化的过程没有复杂的运算，仅仅是增加包头和计算校验和，而编码则有大量的数学运算。
队列（Queuing）：语音的净荷放置到IP包中后，要被设备转发到目的地，这些包会在设备的出接口队列中，等待被调度。
转发设备不同的队列机制对IP包的处理有很大不同。
VoIP网络电话技术问题解答：如何测试延时,抖动,丢包率？
VoIP网络电话技术问题解答：如何测试延时,抖动,丢包率？做网络电话代理的主要任务是技术支持，能不能搞好用户端的安装，直接影响VoIP业务的开展，这里介绍一下安装网络电话用户端时，一个必须注意的技术参数：延时、抖动、丢包率。
如何保证用户端安装网络电话以后，能够获得满意的通话效果？关键在用户端的IP网络到服务器端的带宽。
只有保证足够的带宽，才有通话质量的保障。
网络电话是依赖互联网传送话音的，带宽应该怎样宽才符合要求？语音效果才好呢？就要测试：延时、抖动、丢包率。
如何测试延时、抖动、丢包率？有两个简单的DOS命令可以让你知道用户本地与服务器之间的网络状况。
在Windows的左下角点击“开始”，选“运行”，键入cmd回车，就可以进入DOS窗口，在DOS命令状态下输入第一种命令ping，比如：ping 202.105.135.211 -t 就会得到下面的结果：Pinging 202.105.135.211 with 32 bytes of data:Reply from 202.105.135.211: bytes=32 time=93ms TTL=42Reply from 202.105.135.211: bytes=32 time=86ms TTL=42Reply from 202.105.135.211: bytes=32 time=81ms TTL=42Reply from 202.105.135.211: bytes=32 time=80ms TTL=42Ping statistics for 202.105.135.211:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 80ms, Maximum = 93ms, Average = 85ms这里面，Lost = 0 (0% loss)是指丢包率0%，Minimum = 80ms，延时最小值是80ms（毫秒），Maximum = 93ms，延时最大值是93ms，Average = 85ms，延时的平均值是85ms。
rtcp协议
RTCP 协议RTCP（RTP Control Protocol）是用于实时传输协议（RTP）的一个控制协议，用于支持多媒体会话中的实时控制和统计信息的交换。
它是RTP协议的重要补充，为实时应用提供了一些重要的功能。
1. RTCP 协议的介绍RTCP 是一个基于UDP的协议，用于在RTP会话中传输控制信息和统计信息。
它通过定期发送RTCP报文，实现了多媒体会话的控制和监控。
RTCP报文包含了多媒体会话的统计信息，例如发送者的丢包率、延迟和抖动等。
这些统计信息对于实时应用的质量控制和性能优化非常重要。
RTCP协议还可以用于传输一些控制信息，例如会话的开始和结束信号、参与者的加入和离开等。
2. RTCP 报文格式RTCP报文的格式非常灵活，可以根据需要进行扩展。
一个RTCP报文通常包含一个头部和一个或多个分组。
2.1 RTCP 头部RTCP头部一般包含以下字段：•版本（Version）：用于指定RTCP协议的版本号，通常为2。
•填充（Padding）：用于进行报文填充，保证报文长度为4字节的倍数。
•压缩（Compact）：用于指定报文是否采用压缩格式。
•分组类型（Packet Type）：用于指定RTCP分组的类型，例如SR （Sender Report）和RR（Receiver Report）等。
•长度（Length）：用于指定RTCP分组的长度，以32位为单位。
2.2 RTCP 分组RTCP分组是RTCP报文的实际内容，可以根据需要进行扩展。
一个RTCP分组通常包含以下字段：•域（Field）：用于指定分组的类型，例如发送者报告（SR）和接收者报告（RR）等。
•长度（Length）：用于指定分组的长度，以8字节为单位。
•数据（Data）：用于存储分组的具体数据。
3. RTCP 协议的应用RTCP协议广泛应用于实时应用中，例如音视频会议、流媒体传输等。
在音视频会议中，RTCP用于传输参与者的统计信息，例如延迟、抖动和丢包率等。
经典案例-VoLTE抖动时延优化专题研究
经典案例-VoLTE抖动时延优化专题研究VOLTE抖动时延优化专题研究目录摘要 (3)背景 (4)一、RTP简介 (5)1.1RTP是什么 (5)1.2RTP的应用环境 (5)1.3RTP时延抖动公式 (6)二、VOLTE调度概述 (7)2.1向网侧发送BSR (7)2.2向网侧发送SR (7)2.3发起竞争随机接入 (8)三、智能预调度优化 (8)3.1优化背景 (8)3.2预调度原理 (8)3.3智能预调度与DRX关系 (10)3.4预调度功能验证 (11)3.4.1定点验证 (11)3.4.2连片验证 (13)3.4.3智能预调度参数组验证 (15)四、DRX优化 (18)4.1DRX原理 (18)4.1.1DRX概述 (18)4.1.2为什么要使用DRX-InactivityTimer (19)4.1.3长周期和短周期 (19)4.1.4DRX流程 (20)4.2DRX功能生效验证 (21)4.2.1测试软件观察DRX参数配置 (21)4.2.2智能预调度与DRX关系 (22)4.3DRX参数优化验证 (26)4.3.1DRX长周期优化 (26)4.3.2拉网验证 (27)五、上行补偿调度优化 (29)5.1优化原理 (29)5.2测试验证 (30)5.2.1定点验证 (30)5.2.2连片验证 (31)六、语音调度优先优化 (33)6.1优化原理 (33)6.2测试验证 (34)6.2.1定点验证 (34)6.2.2连片验证 (35)七、总结 (36)摘要随着4G网络的快速发展，以及电信VOLTE的商用的临近，电信用户也对高清VOLTE业务充满着期待，同时VOLTE语音新业务的兴起及用户对体验的追求时时刻刻挑战着目前网络的现状。
语音抖动时延是各个语音承载网络制式下的重要感知指标，本文主要以优化VOLTE调度方式为切入点，从绑定智能预调度参数组、优化DRX长周期、上行调度补偿和语音调度优先四个方面探索缩短语音抖动时延的方法，提升VOLTE用户感知。
webrtc 时延抖动标准
webrtc 时延抖动标准
在WebRTC中，抖动时长不能超过10ms，超过10ms则认为数据包丢失。
具体来说，网络抖动的衡量是最大延迟与最小延迟的时间差，如最大延迟是20毫秒，最小延迟为5毫秒，那么网络抖动就是15毫秒，它主要标识一个网络的稳定性。
如果不处理网络抖动，会对音视频服务质量造成严重影响：对于视频来说，网络抖动会造成频繁卡顿和快播现象；对于音频而言，则会出现短音、吞音等问题。
因此，对于WebRTC而言，时延抖动标准要求非常高，主要是为了提供更
好的音视频服务质量和稳定性。
更多信息可访问信息技术论坛或社区获取。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
RTP/RTCP 丢包/抖动/时延计算原理
1.RTP/RTCP的基本功能介绍
实时传输协议RTP（A Transport Protocol for Real-Time Application）提供实时的端对端传输业务（如交互的语音和图象），包括负载类型标识，序列号，时间戳，传输监视。
实时传输协议（RTP）本身并不提供任何机制保证实时传输或业务质量保证，而是让底层协议去实现。
RTP包括两个紧密相关的部分：
实时传输协议（RTP－Real Time Transport Protocol），传输有实时特性的信息；
RTP控制协议（RTCP－RTP Control Protocol），监视业务质量和传输对话中成员的信息。
RTP/RTCP报文封装格式为：DL+IP+UDP+RTP/RTCP
2.RTP报文统计方法介绍
RTP报文发送统计：
NTP时间标志：64比特，指示了此报告发送时的壁钟（wallclock）时刻，它可以与从其它接收者返回的接收报告块中的时间标志结合起来，测量到这些接收者的环路时延。
RTP时间标志：32比特，与以上的NTP时间标志对应同一时刻，但是与数据包中的RTP时间标志具有相同的单位和偏移量。
发送包数：32比特，从开始传输到此SR包产生时该发送者发送的RTP数据包总数。
若发送者改变SSRC识别符，该计数器重设。
发送字节数：32比特，从开始传输到此SR包产生时该发送者在RTP数据包发送的字节总数（不包括头和填充）。
若发送者改变SSRC识别符，该计数器重设。
RTP报文接收统计：
丢包率：8比特，自从前一SR包或RR包发送以来，从SSRC_n传来的RTP数据包的损失比例，以固定点小数的形式表示，小数点在此域的左侧，等于将丢包率乘256后取整数部分。
该值定义为损失包数被期望接收的包数除。
（对应RTCP消息中的丢包率时，除以256再乘以100即可，如为127，则丢包率为50%。
）
累计包损：24比特，从开始接收到现在，从源SSRC_n发到本源的RTP数据包的丢包总数。
该值定义为期望接收的包数减去实际接收的包数。
扩展的最高接收序列号：32比特，低16比特包含从源SSRC_n来的最高接收序列号，高16比特用相应的序列号周期计数器扩展该序列号。
到达间隔抖动：32比特，RTP数据包到达时刻统计方差的估计值，以时间标志为单位测量，用无符号整数表达。
到达间隔抖动J定义为一对包中接收者相对发射者的时间跨度差值的平均偏差。
计算方法：若Si是包i的RTP时间标志，Ri是包i以RTP时间标志单位的到达时刻值，对于两个包i和j，D可以表达为D(i,j)=(Rj-Rj)-(Ri-Si);到达间隔抖动可以在收到从源SSRC_n来的每个数据包i 后连续计算，利用该包和前一包i-1的偏差D（按到达顺序，而非序号顺序），根据公式J=J+(|D(i-1,i)|-J)/16计算。
循环计算，生成报告块时，取当时值。
（具体可参考后面的详细描述）
环路时延：上一个SR时间标志（LSR）：32比特，接收到的来自源SSRC_n的最新RTCP 发送者报告（SR）的64位NTP时间标志的中间32位。
若还没有接收到SR，该域值为零。
上一个SR以来的延时（DLSR）：32比特，是从收到来自SSRC_n的SR包到发送此接收报告块之间的延时，以1/65536秒为单位。
若还未收到来自SSRC_n的SR
包，该域值为零。
环路时延计算方法：假设SSRC_r 为发出此接收报告块的接收者。
源SSRC_n 可以通过记录收到此接收报告块的时刻A 来计算到SSRC_r 的环路传输时延。
可以利用最新的SR 时间标志（LSR ）域计算整个环路时间A-LSR ，然后减去此DLSR 域得到环路传播时延。
（具体可参考后面的详细描述）
3. 丟包率计算的实现
4. 环路时延计算的实现
5. 间隔抖动计算的实现 21用户在线时间轴InitRTPSeqNo ExtRTPSeqNo1RcvRTPPkt1ExtRTPSeqNo2
RcvRTPPkt2InitRTPSeqNo-------表示本端收到的第一个RTP 报文的序列号ExtRTPSeqNo1-----表示本端在采样点1处收到的RTP 报文中最大的序列号(（ 即PreExpRcvRTPPkt ＝ExtRTPSeqNo1－InitRTPSeqNo ）RcvRTPPkt1---------表示本端在采样点1处实际收包数（PreRcvRTPPkt ）ExtRTPSeqNo2-----表示本端在采样点2处收到的RTP 报文中最大的序列号
RcvRTPPkt2---------表示本端在采样点2处实际收包数1预期间隔收包数ExpectedInterval 实际间隔收包数ReceivedInterval LostInterval ＝（ExpectedInterva －ReceivedInterval ）/ExpectedInterval A 端发送SR B 端接收SR B 端发送SR
时间基准(设备启动时间) 1.此段时间用RTCP 报文中的Rtp_ts 保存，发送给B 端
2.此段时间表示A 端点上线时间，即StartTime
3.此段时间用RTCP 报文中的Ntp 保存，发送给B 端，即PeerSRTime
4.此段时间表示B 端点上线时间，即StartTime
5.此段时间表示端点B 收到SR 报文相对时间，即RcvSRTime
6.此段时间用RTCP 报文中的Ntp 保存，发送给A 端，即PeerSRTime
7.此段时间表示端点A 收到SR 报文相对时间，即RcvSRTime 132端点上线时间64LSR 5DLSR=6-5LSR,DLSR 随SR 报文发回A 端
7在A 端收到SR 报文时计算:环路时延＝7－LSR(3)－DLSR
承载软件根据协议计算间隔抖动；上层控制软件直接使用此值进行打包和告警。
备注：RTCP 一共有如下5个告警：
接收报文丢报率告警
发送报文丢报率告警
接收报文间隔抖动告警
发送报文间隔告警
接收报文时延告警
对于同一个IP 地址，告警恢复之前，只上报一种告警；发送报文相关的告警是本端计算的，接收报文相关的告警是对端计算，通过RTCP 报文传送过来的。
上报告警的原则如下：计算出的丢包率/时延/抖动如果连续4个周期大于MML （SET RTCP ）设置的对应告警上限，且同一个IP 地址没有上报RTCP 相关的告警，则上报该告警。
如果计算出的相关值小于MML 设置的告警下限，则恢复告警。
参考协议：RFC1889
承载软件根据协议计算jitter 上层控制软件直接使用jitter 打包、告警jitter。