WebRTC RTCP RTP Feedback

已于 2023-02-08 17:12:35 修改
阅读量799 收藏 3
点赞数
分类专栏： WebRTC剖析 文章标签： webrtc
于 2022-04-09 15:42:20 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/A18373279153/article/details/124061800
版权

作为WebRTC RTCP消息中的一种，RTP Feedback包含的内容很多，所以这里单独介绍。
在RTCP Header中，这类消息的负载类型Payload Type=205，反馈消息类型FMT如下：

FMTNameLong NameDescriptionReference
1NACKGeneric negative acknowledgement丢包重传请求RFC4585
3TMMBRTemporary Maximum Media Stream Bit Rate Request临时最大媒体流比特率请求RFC5104
4TMMBNTemporary Maximum Media Stream Bit Rate Notification临时最大媒体流比特率通知RFC5104
7TLLEITransport-Layer Third-Party Loss Early Indication传输层第三方丢失早期指示RFC6642
8ECNExplicit Congestion Notification显式拥塞通知RFC6679
15TWCCTransport Wide Congestion Control传输宽拥塞控制draft-holmer-rmcat-transport-wide-cc-extensions-01

一、丢包重传请求（NACK）

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|  FMT=1  |     PT=205    |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PID                |             BLP               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • PID：数据包ID， 指丢失的RTP包的序列号。
  • BLP：丢失数据包的位掩码，表示从PID开始往后16个RTP包是否有丢失。如果第i位为1，则说明序列号为PID+i的RTP包丢失，若未丢包该位为0。

二、临时最大媒体流比特率请求（​TMMBR）

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|  FMT=3  |     PT=205    |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • MxTBR Exp：指数
  • MxTBR Mantissa：系数
  • Measured Overhead：测量的平均数据包开销值（以字节为单位）

说明：TMMBR用于流控，接收方向发送方请求按指定的最大比特率传输数据流，通常用于网络抖动情况下保证VOIP通信的流畅性（临时降低质量）。最大比特率 = 系数 * 2^指数。

三、临时最大媒体流比特率通知(TMMBN)

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|  FMT=4  |     PT=205    |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

说明：此反馈消息用于通知TMMBR消息的发送者已收到一条或多条TMMBR消息

四、传输层第三方丢失早期指示（TLLEI）

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|  FMT=7  |     PT=205    |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              PID              |             BLP               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • PID：数据包ID， 指丢失的RTP包的序列号。
  • BPL：丢失数据包的位掩码，表示从PID开始往后16个RTP包是否有丢失。如果第i位为1，则说明序列号为PID+i的RTP包丢失，若未丢包该位为0。

五、显式拥塞通知（ECN）

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|  FMT=8  |     PT=205    |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extended Highest Sequence Number                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (0) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (1) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECN-CE Counter                | not-ECT Counter               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lost Packets Counter          | Duplication Counter           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Extended Highest Sequence Number：扩展最大序列号，表示此报告相关的最大 RTP 序列号。
  • ECT (0) Counter ：
  • ECT (1) Counter：
  • ECN-CE Counter：
  • not-ECT Counter：
  • Lost Packets Counter：
  • Duplication Counter：

六、传输宽拥塞控制（TWCC）

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|  FMT=15 |    PT=205     |           length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     SSRC of packet sender                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      SSRC of media source                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      base sequence number     |      packet status count      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 reference time                | fb pkt. count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          packet chunk         |         packet chunk          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         packet chunk          |  recv delta   |  recv delta   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           recv delta          |  recv delta   | zero padding  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • base sequence number：此反馈中的第一个RTP包序列号
  • packet status count：本次反馈包含的RTP包的总数
  • reference time：表示参考时间，以64ms为单位
  • feedback packet count：反馈数据包计数，用于接收方检测反馈包是否有丢失
  • packet chunk：数据包块，记录RTP包的到达状态，记录的这些RTP包序列号通过base sequence number计算得到
  • recv delta：对于每个“已收到数据包”的状态，也就是收到的RTP包，在recv delta列表中添加对应的的到达时间间隔信息，用于记录RTP包到达时间信息。通过前面的reference time以及recv delta信息，我们就可以得到RTP包到达时间。

熊彬彬
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
rtcp nack 重传抓包
07-10
rtcp nack 重传抓包
RTCP 协议的 NACK 报文
qq_28581781的博客
09-13 2423
接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传。 相对ARQ带来的改进：减少的反馈包的频率和带宽占用，同时也能比较及时地通知发送方进行丢包重传。 NACK 报文的定义在[rfc4585]文档中定义。 RTCP 的反馈报文包头定义如下，FMT 和 PT 决定了该报文的类型，FCI 则是该类型报文的具体负载： 转存失败重新上传取消转存失败重新上传取消 version (V): 2 bits 该字段标识RTP版本。当前版本是2 padding (P): 1 bit 如果...
WebRtc音视频实时通信--NACK丢包重传消息格式详解
chenFteng的博客
08-27 3365
ACK在TCP连接中是数据包确认消息，在TCP连接中，数据接收端在接收到一个数据包的时候会立即发送一个ACK消息给发送端，通知已经接收到此数据包，然后发送端再继续发送下一个数据包。 NACK与ACK刚好相反，在UDP通信中，数据接收端接收到数据包后是不需要通知发送端的，发送端始终不断的发送数据包而不关心对方是否正确收到，亦不关心所发生的数据包是否有序到达。只有在接收端意识到有某个或某几个数据包没有接
RTCP TMMBR字段解析
liang12360640的专栏
08-02 6197
RTCP TMMBR字段解析 TMMBR用于流控，请求发送端按指定的最大比特率传输数据流，通常用于网络抖动情况下保证VOIP通信的流畅性（临时降低质量）。 SSRC（32 bits）： 请求对方控制该媒体源遵从下面的最大比特率 MxTBR Exp（6 bits）： 指数 MxTBR Mantissa（17 bits）： 系数 Measured Overhead（9 bit
WEBRTC 实时视频传输中的RTCP协议码率控制报文
ljh081231的专栏
03-06 684
流媒体传输中常用的RTCP包主要有SR／RR／SDES／BYE／APP／XR，主要由RFC 3611和RFC 3550定义。而WEBRTC视频中常用的RTCP包比语音要多很多，语音的RTCP主要用于状态传递，统计数据。而视频中的RTCP更多赋予了控制功能，比如关键帧请求，码率控制等等。本文不介绍语音中的RTCP，只介绍视频中的RTCP包。这些报文遵守RFC4585和RFC5104协议。第一类：关键...
【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展
CopperSun 技术博客
07-26 822
【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展 参考致谢 本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。 【1】WebRTC之RTCP ...
RTCP中文详解
hnkfwhw的博客
11-01 256
RTCP协议介绍 RTCP概要 实时传输控制协议(Real-time ControlProtocol，RTCP)与RTP共同定义在1996年提出的RFC 1889中，是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上，由低层协议提供数据与控制包的复用。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，如下图所示。对于RTP会话或者广播，通常使用单个多目...
webrtc vp8_rtp抓包样例
10-29
在webrtc系统上捕获的VP8无FEC、SRTP的RTP报文，用于VP8协议分析。
smart_webrtc.zip
09-15
使用详解参见博客 https://blog.csdn.net/freeabc/article/details/108561272
rtcp:RTCP的Go实现
03-17
介子RTCPRTCP的Go实现 有关功能和未来目标的概述，请参见 。...贡献查阅 ，加入令人赞叹的团队，使这个项目成为可能： （ -原作者 RTCP，RTP改进，G.722支持，错误修复 - Linter修复执照MIT许可证-全文请参见
webrtc-streamer
04-18
vue2、vue3播放rtsp视频流
WebRTC API 的纯 Rust 实现
06-28
赶上 pion/rtp v1.6.2RTCP：webrtc-rs/rtcp同步到pion/rtcp/v1.2.4完成：赶上 pion/rtcp v1.2.6SRTP：webrtc-rs/srtp同步到pion/srtp/v1.5.2完成：赶上 pion/srtp/v2 v2.0.2DTLS：webrtc-rs/dtls同步到pion/dtls/v...
webrtc源码分析 拥塞控制上-码率预估
liuhongxian的专栏
02-15 1712
1 前言 本文是webrtc中拥塞控制的上文，主要是分析webrtc中的拥塞控制的码率探测，预估和调整的部分，介绍了整体框架和原理以及相关的类； webrtc版本:M91 2 正文 2.1 整体框架 webrtc中的部分码控结构如下图所示，从socket层接收到数据后，到transport解析rtcp包处理得到feedback，通过call将feedback转发到对应sendstream上的rtcp处理模块，最终通过RtpTransportControllerSend将feedback转发到GoogCcNe
【RFC5104 带有反馈的RTP视听配置文件中的编解码器控制消息（AVPF）】（翻译）
PiPiQ_Blog的博客
06-20 1358
原文rfc5104 (ietf.org)
webrtc研究-remb协议分析
liuhongxian的专栏
12-21 4439
分析入口 webrtc/ideo/vie_remb.ccvoid VieRemb::OnReceiveBitrateChanged(const std::vector<uint32_t>& ssrcs, uint32_t bitrate) { RtpRtcp* sender = nullptr; { rtc::CritScope
【mediasoup TRANSPORT_CC 2】接收端 RTCP Feedback 报文 chunk 解析与构造
突围
04-12 582
参考大神 WebRTC 拥塞控制 | Transport-CC 之 RTP 头部扩展与 RTCP Feedback 报文 在 WebRTC 的 Send-side BWE 中，大多数拥塞控制逻辑被放到了发送端，这样做除了方便维护，也增加了相关算法的灵活性，而这一切正是基于 Transport-CC（Transport-wide Congestion Control）。 Transport-cc中，收流客户端通过TransportFeedback RTCP向发送端反馈收到的各个RTP包的到达时间信息。..
WebRTC RTCP PS Feedback
clark的专栏
04-09 716
作为WebRTC RTCP消息中的一种，PS Feedback包含的内容同样也很多。 在RTCP Header中，这类消息的负载类型Payload Type=206，反馈消息类型FMT如下： FMT Name Long Name Description Reference 1 PLI Picture Loss Indication 图片丢失指示 RFC4585 2 SLI Slice Loss Indication 切片丢失指示
WebRTC的transport wide cc feedback 带宽预估
linux_vae的专栏
06-19 4583
@toc 背景介绍 BWE 带宽预估，参考 https://blog.csdn.net/CrystalShaw/article/details/82981183 的文章 – 丢包预测：丢包率反应带宽情况 – 延时预测： 组包延时，多个包的到达时间delta的趋势来判断带宽情况 – 从之前GCC拥塞的接收端计算带宽并发送remb 到接收端反馈Transport cc， 由发送端sender...
WebRTC音视频通话-WebRTC视频自定义RTCVideoCapturer相机
一名开发者
08-15 6515
WebRTC音视频通话-WebRTC视频自定义RTCVideoCapturer相机。主要获得相机采集的画面CVPixelBufferRef，将处理后的CVPixelBufferRef生成RTCVideoFrame，通过调用WebRTC的localVideoSource中实现的didCaptureVideoFrame方法
android端webrtc的RTP包回调
最新发布
10-26
Android端WebRTC的RTP包回调是通过RtpReceiver类实现的。在RtpReceiver类中，可以通过设置RtpReceiver.Observer来监听RTP包的接收情况。当有RTP包到达时，会触发onFrame方法，该方法中可以获取到RTP包的相关信息，如...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值