14. RTCP 协议

本文主要是介绍14. RTCP 协议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

RTCP 协议概述

RTCP（Real-time Transport Control Protocol 或 RTP Control Protocol 或简写 RTCP），实时传输控制协议，是实时传输协议（RTP）的一个姐妹协议。
注：RTP 协议和 RTP 控制协议（RTCP）一起使用，而且它是建立在 UDP 协议上的（一般用于视频会议）

RTCP 工作机制

当应用程序开始一个 rtp 会话时将使用两个端口：一个给 rtp，一个给 rtcp。rtp 本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠 rtcp 提供这些服务。

RTCP 负责管理传输质量在当前应用进程之间交换控制信息。在 RTP 会话期间，各参与者周期性地传送 RTCP 包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

RTP 和 RTCP 配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。

RTCP 数据报

在 RTCP 通信控制中，RTCP 协议的功能是通过不同的 RTCP 数据报来实现的，主要有如下几种类型：
在这里插入图片描述
SR：发送端报告，所谓发送端是指发出 RTP 数据报的应用程序或者终端，发送端同时也可以是接收端。
RR：接收端报告，所谓接收端是指仅接收但不发送 RTP 数据报的应用程序或者终端。
SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP：由应用程序自己定义，解决了 RTCP 的扩展性问题，并且为协议的实现者提供了很大的灵活性。
这些RTCP包类型中，SR（Sender Report）和RR（Receiver Report）在实时流中经常被使用。
然后还有一些扩展的：
在这里插入图片描述

RTCP SR 包文详解

在这里插入图片描述

版本（V）：2比特，RTCP版本。
填充（P）：1比特，如果该位置为1，则该RTCP包的尾部就包含附加的填充字节。
接收报告计数器（RC）：5比特，该SR包中的接收报告块的数目，可以为零。
包类型（PT）：8比特，SR包是200。
长度域（Length）：16比特，RTCP包的长度，包括填充的内容。
同步源（SSRC of sender）：32比特，SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
NTP timestamp（MSW+LWS）：64比特，表示发送此报告时以挂钟时间测量的时间点。结合来自各个接收器的接收报告中返回的时间戳，它可用于估计往返于接收器的往返传播时间。
RTP timestamp：32比特，与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。
Sender’s packet count：32比特，从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零。
Sender`s octet count：32比特，从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其SSRC时，这个域要清零。
SSRC_n ：32比特，在此块中报告其接收的发送者的 SSRC 标识符,因为可能有多个接收者。
丢失率(Fraction Lost):8比特，表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率
累计的包丢失数目（cumulative number of packets lost C ）：24比特，从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
收到的扩展最大序列号(extended highest sequence number received EHSN )：从SSRC_n收到的RTP数据包中最大的序列号
接收抖动（Interarrival jitter）：32比特，RTP数据包接受时间的统计方差估计
上次SR时间戳（Last SR,LSR）：32比特，取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零
上次SR以来的延时（Delay since last SR,DLSR）：32比特，上次从SSRC_n收到SR包到发送本报告的延时
扩展字段 profile-specific extensions

其实我们可以发现他是可以分成3大部分的：

header 头部信息
sender Information block
report block
这个是有多个的，因为可能有多个接收者。

RTCP RR 包文详解

除包类型代码外，SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送SR；否则，就发送RR。
SR和RR包都可没有接收报告块也可以包括多个接收报告块，其发布报告表示的源不一定是在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR 或 RR包中。
丢失包累计数差别给出间隔期间丢包的数量，而系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。
从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。
如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
格式如下图所示：
在这里插入图片描述

Source Description RTCP Packets(源点描述)

资源描述协议，最常用的就是传递CNAME名称，用于标识会话，当SSRC发生变化也能很好的匹配会话。协议ID：202。
SDES源描述包提供了直观的文本信息来描述会话的参加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项，这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成，数据块可以没有，也可有多个。
格式如下图所示：
在这里插入图片描述
V, P, PT, L:和RR包的描述一样，只不过其PT值为202

SC：5比特，此 SDES 数据包中包含的 SSRC/CSRC 块的数量。

CNAME: 规范终端标识SDES项，类似SSRC标识，RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时，由于随机分配的SSRC标识可能发生变化，CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。为方便第三方监控，CNAME应适合程序或人员定位源。不同的 SDES 项根据类型-长度-值方案进行编码。目前，CNAME、NAME、EMAIL、PHONE、LOC、TOOL、NOTE 和 PRIV 项目在 [RFC1889] 中定义。CNAME 项在每个 SDES 数据包中都是强制性的，而这又是每个复合 RTCP 数据包的强制性部分。与 SSRC 标识符一样，CNAME 必须与其他所有会话参与者的 CNAME 不同。但不是随机选择 CNAME 标识符，CNAME 应该允许人或程序都可以通过 CNAME 内容来定位源。
在这里插入图片描述