本文摘抄于：https://blog.csdn.net/DittyChen/article/details/78065974
在实时音视频应用场合，考虑低延迟问题一般都使用RTP over UDP进行媒体数据的传输，因此对于丢包、延迟、流畅性的考虑，发送端必须了解发送出去的流媒体数据到达对端的统计信息，RTP控制协议RTCP，就是用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息，包括对抗卡顿、网络拥塞控制扩展功能的实现，均利用RTCP报文实现，有名的是Google的GCC（拥塞控制算法：Google Congestion Control，简称GCC），RTCP的NACK,FIR,PLI报文都是实现抗丢包的策略，详细可查看rfc4585
RTCP为每个RTP源传输一个固定的识别符，称为规范名CNAME
FIR：Full Intra Request，关键帧重传请求
NACK：否定确认，NACK重传（丢包）
SR：发送者报告，描述作为活跃发送者万岁的发送和接收统计数据
RR：接收者报告，描述非活跃发送者成员的接收统计数据
SDES：源描述项，其中包括规范名CNAME
BYE：表明参与者将结束会话
APP：应用描述功能
RTPFB：通过RTP反馈
PLI：Picture loss Indication，为整个图像帧丢失后发送
SLI：Slice Loss Indication，为帧内部分块损坏后发送
RPSI：Reference Picture Selection Indication
AVB：RTCP数据包
RSI：接收端汇总信息
PSFB：payload-Specific FB，消息被定义为载荷类型为PSFB的RTCP消息
关键帧请求：
主要包括SLI / PLI / FIR，集中报文手段，目的是在关键帧丢失无法解码时，请求发送方重新生成并发送一个关键帧。本质是一种重传，但是跟传输层的重传的区别是，它重传的是最新生成的帧。
发送方接收到反馈的PLI或SLI需要重新让编码器生成关键帧并发送给接收端。
FIR是Full Intra Request，这里面的Intra的含义可能很多人不知道。Intra的含义是图像内编码，不需要其它图像信息即可解码；Inter指图像间编码，解码需要参考帧。故Intra Frame其实就是指I帧，Inter Frame指的是P帧或者B帧。
那么为什么在PLI和SLI之外还需要一个FIR呢？原因是使用场景不同，FIR更多的是在一个中心化的Video Conference中，新的参与者加入，就需要发送一个FIR，其它的参与者给它发送一个关键帧这样才能解码，而PLI和SLI的含义更多的是在发生丢包或解码错误的时候使用。
重传请求：
主要包括RTX / NACK /RPSI
这个重传跟关键帧请求的区别是它可以要求任意帧进行重传
码率控制：
主要包括REME /TEMBR / TMMBN
TMMBR：Temporal Max MediaBitrate Request，表示临时的最大码率请求。表明接收端当前带宽受限，告诉发送端控制码率。
REMB：Receiver EstimatedMax Bitrate，接收端估计的最大码率。
TMMBN：Temporal Max MediaBitrate Notification，临时最大码率通知
另外，除了关键帧请求重传，webrtc还支持RED / FEC 等冗余编码和前向纠错手段来保证视频质量