WebRTC系列-Qos系列之RTP/RTCP协议分析rtcp-1

已于 2023-01-16 17:17:28 修改
阅读量690 收藏
点赞数
分类专栏： WebRTC进阶 文章标签： webrtc
于 2023-01-08 11:00:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lym594887256/article/details/128564141
版权
本文深入探讨了WebRTC中的RTCP协议，重点分析了Sender Report (SR)和Receiver Report (RR)报文的结构与功能。SR用于发送方周期性报告发送和接收统计，而RR则由接收方报告接收状态。RTCP报文头部包含版本、填充、接收计数和包类型等字段。SR包含发送者信息，如NTP和RTP时间戳、发送包和字节数。RR则包含接收数据的统计，如丢包率、序列号和网络抖动。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

文章目录


上一篇文章介绍了RTP协议，通常RTP负责传输数据，RTCP一起工作，RTCP负责对RTP的通信和会话进行控制（如流量控制、拥塞控制、会话源管理等）；同rtp协议一样，协议由 IETF（http://www.ietf.org/）定义在 RFC 3550 第6节和3551中；RTCP 有下面四个功能：

  1. 其最基本的功能是对提供对数据分发的质量反馈，这种反馈的功能有 RTCP sender 和receiver report 两种实现，其在RFC文档的第 6.4 节；
  2. 当只用SSRC 作为一个源的标识的时候有可能会出现冲突(有重复的可能)； RTCP 会为 RTP 的数据源携带一个可靠 identifier用于标识这个通常是唯一的，通常叫CNAME（ 或canonical name）；
  3. 通过让每个参与者将其RTCP包发送给其他每一个参与者，这时候每个参与者都可以独立观察其他参与者的的包的数量，为了这种方式实现，就需要控制发送的速率；
  4. 提供
了解本专栏 订阅专栏 解锁全文 超级会员免费看
WebRTC系列-Qos系列之RTP/RTCP协议分析rtcp-2
HOSTEN的博客
01-10 598
本文是接文章继续分析RTCP的SDES、Compound RTCP在WebRTC的使用；
WebRTC系列-Qos系列之RTP/RTCP源码分析-RTP/RTCP包解析-3
HOSTEN的博客
01-12 608
在前面的文章和中分别介绍了RTP及RTCP协议，最后通过抓包的方式直观的了解的包的组成；这一篇文章，根据前面对WebRTC的了解基础上，进行WebRTC源码分析，看WebRTC是怎样实现这些协议及处理流程得；本文的源码分析基于WebRTC m76分支；
RTP QOS
weixin_33796177的博客
06-22 467
在RTP会话中，RTCP周期性地给所有参与者发送控制包，应用程序或第三方监控者接受RTCP控制包，从中获取控制信息，估计当前QoS，以便进行传输控制、拥塞处理、错误诊断等。 RTCP报文头部参数首先要区别携带不同控制信息的RTCP报文的类型，RTCP报文的类型主要有以下几种：(1)SR：发送报告，当前活动发送者发送、接收统计;(2)RR：接收报告，非活动发送者接收统计;(3)SDES：源描述...
Qos RTCP
chenliangming的专栏
05-03 1912
http://www.netbei.com/Article/zz7/s14/200412/3140_3.html   http://net.it168.com/pl/2007-09-04/200709040930735_10.shtml   　4 、具体事例分析　　针对某大型网络系统，没有QoS设备网络质量控制系统情况下的网络拓朴图如下：　　从上图可以看出主
webrtc QOS笔记二 音频buffer数据不足生成很多gap的问题
靑い空゛
02-23 401
webrtc QOS笔记二 音频buffer数据不足生成很多gap的问题
基于RTP_RTCP协议的QoS研究
08-03
基于RTP_RTCP协议的QoS研究 更多资源请访问http://www.59186618.com
WebRTC系列-Qos系列之RTP/RTCP协议分析
HOSTEN的博客
01-04 509
rtp在RFC3550前12个8Byte(96-bit)存在于每个 RTP 数据包中，而CSRC部分只有Mixer发送的报文才会有。这些字段含义如下：版本 (V)：2 位version默认都是2，这个字段表示当前使用的 RTP 的版本。（值 1 由 RTP 的第一个草案版本使用，值 0 由最初在“vat”音频工具中实现的协议使用。）填充（P）：1位表示当前这个包是不是有RTP填充的数据，如果p=1表示有填充数据，p=0表示没有填充；
WebRTC中RTP/RTCP协议实现分析
yinshipin007的博客
12-28 552
RTP协议是Internet上针对流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP协议本身只保证实时数据的传输，RTCP协议则负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RFC3550 [1]定义RTP/RTCP协议的基本内容，包括报文格式、传输规则等。
基于RTP的QOS算法简介
用可见的方式来记录和分享每一次收获
04-13 603
服务质量QoS（Quality of Service）用于评估服务方满足客户服务需求的能力。通过配置QoS，对企业的网络流量进行调控，避免并管理网络拥塞，减少报文的丢失率，同时也可以为企业用户提供专用带宽或者为不同的业务（语音、视频、数据等）提供差分服务。 本方案的QOS是狭义上的QOS，特指用来解决RTP(UDP)传输在不可靠线路（尤其是3G,4G,WIFI）下网络乱序，包重复，包延时抖动的一种技术。 RTP协议头的包序号为我们进行乱序重排以及重复包丢弃提供了理想的参考值。正常情况下，包序号逐包递
RTP的详解和配置对语音来说很有用。QOS一定能用得着
12-14
对RTP的描述很详细。很不错的资料。大家肯定用得着。对语音来说。很有用
WebRTC系列分享 第五期 | WebRTC QoS方法之Sender Side BWE实现
Lce的专栏
09-01 529
BWE（Bandwidth Estimation）可能是WebRTC视频引擎中最关键的模块了。BWE模块决定视频通讯中可以发送多大码率视频不会使网络拥塞，防止视频通讯质量下降。早期的带宽评估算法比较简单，大多是基于丢包来估计，基本的策略是逐步增加发送的数据量，直到检测到丢包为止。为了让发送端获悉网络上的丢包信息，可以使用标准的RTCP的RR来发送周期性的报告。现代的带宽评估算法则可以在网络链路发生丢包以前就监测到网络拥塞，它可以通过侦测数据包接收的时延来预测未来可能的拥塞。
流媒体协议之RTCP
最新发布
wushakun的博客
08-23 2111
RTCP（Real-Time Control Protocol）是用于实时音视频通信的控制协议，用于监控和反馈RTP流。RTCP的作用包括流同步、带宽管理、QoS保证和流控制。它是RTP的重要补充，通过周期性发送RTCP报告，能监控和控制RTP流质量，提高实时多媒体传输效率和质量。RTCP的基本工作原理如下：在RTP会话开始时，发送方周期性发送包含RTP流统计信息和控制信息的RTCP报告，接收方提取并维护相关状态信息用于生成报告，还会根据收到的报告更新状态和发送应答报文，发送方根据报告调整发送速率。
WebRTC系列分享 | WebRTC视频QoS全局技术栈
yinshipin007的博客
03-02 731
当网络条件比较差的时候，码率降的比较低，若不降低帧率，视频质量会大幅度下降。JitterBuffer实现原理是，在收到网络上的RTP报文后，不直接进行解码，需要缓存一定个数的RTP报文，按照时间戳或者seq的顺序进行重排，消除报文的乱序和抖动问题。WebRTC的vpx编码器使用了Temporal Scalability时间可适性编码，仅需通过FEC+NACK方式保护T0层的数据完整性，其余层的视频帧有丢失，可通过逐级降帧率方案（丢弃Tn-T1之间的数据），保证视频通话整体的流畅性。
webrtc QOS方法一.3(发送端NACK实现)
CrystalShaw的博客
07-28 1041
1、RTCPReceiver::HandleNack 处理接收到的NACK报文 2、RTPSender::OnReceivedNack 重发NACK反馈的RTP报文 3、加入pace队列，按照高优先级重传
WebRTC系列-Qos系列之发送NACK
HOSTEN的博客
01-18 1375
在之前的文章介绍了音频开启对包重传的方式及验证是否开启的成功的方式；在文章的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。在WebRTC中是支持音频和视频的NACK，本文只分析NACK及其重点相关的机制，不分析jitterbuffer或者neteq的相关知识及实现，这些将会有其他的文章重点介绍。
流媒体基础-RTCP
键盘敲的劈啪响
01-10 1519
RTCP对于流传输QoS起着至关重要的作用
webrtc QOS笔记三 RTT计算，SRS增加XR
靑い空゛
03-22 1443
完整NTP时间戳用64bits表示，左半32bits表示整数，右半32bits表示小数，一般为了紧凑，取中间32bits表示即可，这时整数与小数分别16bits表示）。记录着上次源SSRC_n发送SR的NTP时间，从收到的SR记录的NTP时间戳获取。记录着上次源SSRC_n发送Receiver Reference Time Report Block的NTP时间，从收到的Receiver Reference Time Report Block记录的NTP时间戳获取。记录着发送该SR的NTP时间戳。
RTP 控制协议 (RTCP) 反馈用于拥塞控制
03-16 1596
有效的 RTP 拥塞控制算法，需要比标准 RTP 控制协议(RTCP)发送方报告(SR)和接收方报告(RR)数据包提供的关于数据包丢失、定时和显式拥塞通知 (ECN) 标记的更细粒度的反馈。本文档描述了 RTCP 反馈消息，旨在使用 RTP 对交互式实时流量启用拥塞控制。反馈消息设计用于基于发送方的拥塞控制算法，其中 RTP 流的接收方向发送方发送回 RTCP 反馈数据包，其中包含发送方执行拥塞控制所需的信息。
音视频处理相关基础概念
luotuo28的博客
04-02 1056
RTP协议的应用场景非常广泛，包括实时视频会议、流媒体播放、网络直播、网络电话等。在这些场景中，RTP协议可以保证音频和视频数据的实时性和稳定性，从而提升用户体验。值得注意的是，RTP协议运行在用户空间，与应用层协议链接，看上去更像应用层协议。然而，从TCP/IP协议体系的角度来看，它应该位于应用层之下、UDP之上，是一种专用于有实时性要求的网络应用的传输层协议。当应用程序开始一个RTP会话时，将使用两个端口：一个用于RTP，另一个用于RTCP。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

简简单单lym

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值