media/rtcp.md
# RTCP
RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。**RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。**通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。
RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
* 200 SR：(Sender report) 发送端报告，所谓`发送端`是指`发出RTP数据报`的应用程序或者终端，发送端同时也可以是接收端。描述作为活跃发送者成员的发送和接收统计数字(RFC3550)
* 201 RR：(Receiver report) 接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。描述非活跃发送者成员的接收统计数字(RFC3550)
* 202 SDES：(Source description) 源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。 (RFC3550)
* 203 BYE：(Goodbye) 通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。表明参与者将结束会话(RFC3550)
* 204 APP：(Application defined) 由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。应用描述功能(RFC3550)
* RTPFB: (Transport layer feedback) 通用RTP反馈(RFC4585)
* PSFB: (Payload-specific feedback) 有效载荷比(RFC4585)
* XR: (Extended report) RTCP扩展(RFC3611)
RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。
在一个典型的应用场合下，**发送媒体流的应用程序将周期性地产生发送端报告SR**，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节 的计数，**接收端根据这些信息可以估计出实际的数据传输速率**。另一方面，**接收端会向所有已知的发送端发送接收端报告RR**，该RTCP数据报含有已接收数据报 的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，**发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动 态调整发送速率**，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。
## 用途
### 关键帧请求
主要包括SLI／PLI／FIR，集中报文手段，目的是在关键帧丢失无法解码时，请求发送方重新生成并发送一个关键帧。本质是一种重传，但是跟传输层的重传的区别是，它重传是最新生成的帧。
PLI 是Picture LossIndication，SLI 是Slice Loss Indication。发送方接收到接收方反馈的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
这个重传跟关键帧请求的区别是它可以要求任意帧进行重传
### 码率控制
主要包括REMB／TMMBR／TMMBN
TMMBR是Temporal Max MediaBitrate Request，表示临时最大码率请求。表明接收端当前带宽受限，告诉发送端控制码率。
REMB是ReceiverEstimatedMax Bitrate，接收端估计的最大码率。
TMMBN是Temporal Max MediaBitrate Notification
另外，除了关键帧请求和重传，Webrtc还支持RED／FEC等冗余编码和前向纠错手段来保证视频质量。
## PSFB
其中206Type的PSFB中又拥有三个子项，详见rfc4585第六章
PSFB（Payload-Specific FB）消息被定义为载荷类型为PSFB的RTCP消息；
* PLI：The PLI FB messageis identified by PT=PSFB and FMT=1. Picture Loss Indication，为整个图像帧丢失后发送
* SLI：The SLI FB messageis identified by PT=PSFB and FMT=2. Slice Loss Indication，为帧内部分块损坏后发送
* RPSI：The RPSI FB messageis identified by PT=PSFB and FMT=3. Reference Picture Selection Indication
## 传输层反馈消息
传输层FB消息由值RTPFB标识为RTCP
消息类型。
本文档中
定义了单个通用传输层FB消息：Generic NACK。它通过FMT
参数识别如下：
0：未分配
1：通用NACK
2-30：未分配
31：保留用于将来扩展标识符号空间
以下小节定义
此类型FB 的FCI字段格式信息。可以
在将来定义进一步的通用反馈消息。
### 通用NACK
通用NACK消息由PT = RTPFB和FMT = 1标识。
FCI字段必须包含至少一个，并且可以包含多个Generic NACK。
通用NACK用于指示一个或多个RTP分组的丢失。丢失的分组通过分组标识符和比特掩码来识别。
## 有效负载反馈消息
有效负载特定的FB消息由值PT = PSFB标识为
RTCP消息类型。
到目前为止，定义了三个特定于有效负载的FB消息以及
应用层FB消息。它们通过
FMT参数识别如下：
0：未分配
1：图像丢失指示（PLI）
2：切片损失指示（SLI）
3：参考图像选择指示（RPSI）
4-14：未分配
15：应用层FB （AFB）消息
16-30：未分配
31：保留用于将来扩展序列号空间
图像丢失指示（PLI）
PLI FB消息由PT = PSFB和FMT = 1标识。
FCI字段中必须包含一个PLI。
6.3.1.1。语义
利用图像丢失指示消息，解码器向
编码器通知
属于一个或多个图像的未定义量的编码视频数据的丢失。当与
基于图片间预测的任何视频编码方案结合使用时
，接收PLI 的编码器变得知道预测链
可能被破坏。发送方可以通过发送
帧内图像来对PLI作出反应以实现重新同步（使该消息
有效地类似于[ 6 ]中定义的FIR消息）; 但是，
发送方必须考虑第7节中概述的拥塞控制，
可能会限制其发送帧内帧的能力。
其他RTP有效载荷规范（如RFC 2032 [ 6 ]）已经
为某些编解码器定义了一些反馈机制。
支持两种方案的应用程序
在发送反馈时必须使用本规范中定义的反馈机制。出于向后兼容性的
原因，
如果
有效载荷格式需要，这样的应用程序也应该能够接收并响应在相应RTP有效载荷格式中定义的反馈方案。
6.3.1.2。消息格式
PLI不需要参数。因此，长度字段必须是
2，并且不得有任何反馈控制信息。
此FB消息的语义与有效负载类型无关。
6.3.1.3。时间规则
时间安排遵循第3节中概述的规则。在
采用PLI和其他类型反馈的系统中，建议
遵循PLI的常规RTCP RR时序规则，因为PLI
不像其他FB类型那样具有延迟关键性。
6.3.1.4。备注
PLI消息通常触发发送完整的帧内图像。
帧内图像比预测（帧间）
图像大几倍。它们的大小与它们产生的时间无关。
在大多数环境中，尤其是在使用带宽受限的
链路时，使用内部图像意味着允许的延迟，
显着多个典型的帧持续时间。例如：如果
发送帧速率是10 fps，并且假设帧内图像是帧间图像的
10倍，则
必须接受整整一秒的延迟。在这样的环境中，
发送FB消息不需要特别短的延迟。因此，等待
RTCP时序规则允许的下一个可能的时隙，如[ 2 ]所示
，Tmin = 0不会对系统
性能产生负面影响。
[ref](http://blog.csdn.net/tq08g2z/article/details/77773129)
[RTCP介绍及发送间隔控制](https://blog.csdn.net/DittyChen/article/details/78065974)