采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送，例如使用不同的 UDP端口号。

RTCP：RTP 控制协议 （RTCP：RTP Control Protocol）

RTCP 提供数据分发质量反馈信息，这是 RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。

RTCP 为 RTP 源携带一个持久性传输层标识符，称为规范名或 CNAME。由于一旦发现冲突或程序重启时， SSRC 标识符会随之改变，所以接收方需要 CNAME 来跟踪每一个参与者。同时接收方还要求 CNAME 能够与一组相关 RTP 会话中来自于给定参与者的多重数据流相关联，例如同步视频和音频。

上述前两个功能要求所有的参与者都要发送 RTCP 包，因此必须控制速率以便 RTP 按比例增加大量的参与者。通过每一个参与者发送各自的控制包给其它所有参与者，每一个参与者能够独立观察到参与者数量，该数量可用来计算控制包的发送速率。

OPTIONAL 功能用于传送最少会话控制信息，例如在用户界面显示参与者标识。这对于“松散受控”会话（在没有成员控制或阐述协商的情况下，参与者可以加入或退出该会话）是非常有用的。

上述功能 1 － 3 适用于所有环境，尤其是 IP 组播环境。RTP 应用程序设计者应该避免设计只能工作于单播模式并且不能增加到大量数量的机制。在某些情况下如单向链接中，不可能有来自接收方的反馈，所以 RTCP 的传输就可能由发送方和接收方分别独立控制。

定义

单位（bit）

Length

Version ― 识别 RTP 版本。RTP 数据包中的该值与 RTCP 数据包中的一样。当前规范定义的版本值为 2。

P ― 间隙（Padding）。设置时， RTCP 数据包包含一些其它 padding 八位位组，它们不属于控制信息。Padding 的最后八位是用于计算应该忽略多少间隙八位位组。一些加密算法中需要计算固定块大小时也可能需要使用 Padding 字段。在一个复合 RTCP 数据包中，只有最后的个别数据包中才需要使用 padding ，这是因为复合数据包是作为一个整体来加密的。

RC ― 接收方报告计数。包含在该数据包中的接收方报告块的数量，有效值为 0。

Packet type ― 包括常量 200 ，识别这是一个 RTCP SR 数据包。

Length ― RTCP 数据包的大小（32 位字减去 1），包含头和任意间隙 （偏移量的引入使得 0 成为有效值，并避免了扫描复合 RTCP 数据包过程中的无限循环现象，而采用 32 位字计数方法则避免了对 4 的倍数的有效性校验）。

RTCP的分组类型

下表为RTCP的五种分组类型

结束分组BYE表示关闭一个数据流。

特定应用分组APP使应用程序能够定义新的分组类型、。

接收端报告分组RR用来使接收端周期性地向所有的点用多播方式进行报告。接收端每收到一个RTP流（一次会话包含多个RTP流）就产生一个接收端报告分组RR。RR分组的内容有：所收到的RTP流的SSRC；该RTP流的分组丢失率（若分组丢失率太高，发送端就应该适当地降低发送分组的速率）；在该RTP流中的最后一个RTP分组的序号；分组到达时间间隔的抖动等；

发送RR分组有两个目的。第一，可以使所有的接收端和发送端了解当前网络的状态。第二，可以使所有发送RTCP分组的站点自适应地调整自己发送RTCP分组的速率，使得起控制作用的RTCP分组不要过多地影响传送应用数据的RTP分组在网络中的传输。通常是使RTCP分组的通信量不超过网络中工大数据分组的数据量的5%，而接收端的通信量又应小于所有RTCP分组的通信量的75%。

发送端报告分组SR用来使发送端周期性地向所有接收端用多播方式进行报告。发送端每发送一个RTP流就要发送一个发送端报告分组SR。SR分组的内容有：该RTP流的SSRC；该RTP流中最新产生的RTP分组的时间戳和绝对时钟时间（或墙上时钟时间wall clock time）；该RTP流包含的分组数；该RTP流包含的字节数。

绝对时钟时间是必要的。因为RTP要求每一种媒体使用一个流。例如，要传送视频图像和相应的声音就需要传送两个流。有了绝对时钟时间就可以进行图像和声音的同步。

源点描述分组SDES给出会话中参加者的描述，它包含参加者的规范名CNAME（Canonical NAME）。规范名是参加者的电子邮件地址的字符串。

RTCP的实现

Introduction

An RTCP implementation has three parts: the packet formats,the timing rules,and the participant database

Packet Formats:

Timing Rules:

所有的RTCP复合包被周期性送出，这个周期称为reporting interval，所有的RTCP活动都是以这个间隔发生的，除了update of source description 和lip synchronization information，以及在这个interval内发生的reception quality statistics.

Participant Database:

基于收到的RTCP包建立的.

⒈根据这个db可以填充Reception Report，并发送给对方

⒉可以维护Participant Information

⒊可以用于进行lip synchronization.

RTCP的传输

⒈必须发送RTCP compound包，

⒉odd ports，是RTP port + 1（最近不要求必须是奇数，也不要求必须大1了）

⒊所有的参与者应当送出compound packets，也接收所有其他的participants发送的compound packets,

Note that feedback is sent to all participants in a multiparty session: either unicast to a translator,which then redistributes the data,or directly via multicast. The peer-to-peer nature of RTCP gives each participant in a session knowledge of all other participants: their presence,reception quality,and—optionally—personal details such as name,e-mail address,location,and phone number.

RTCP的包格式

SR,RR,SDES,BYE,APP

通用头（固定头）：4 octets

v p ic pt length(be measured in units of 32-bits word)

2 1 5 8 16

---------- p c⑻

⒈RR(Receiver Report)

Reception quality reporting：所有发送RTP数据的Sender的信息，每个block包含一个SSRC的RTP接受质量报告

PT = 201

Format:

Reporter SSRC

*{//一个Reporter Block

固定头

24 octets的内容

包括以下部分：

reportee SSRC:

cumulative number of packets lost :24bit的有符号数，从会话开始到期望收到-实际收到（可为负）

extended highest sequence number :per session

loss fraction :per interval，取整 [丢包/期望收到数目 * 256]（如果丢包为负值，则结果设为0)

interarrival jitter :

last sender report timestamp(LSR) ：从reportee端最后收到的Sender Report中NTP timestamp的中32bits.（无则为0)

delay since last sender report(DLSR) ：最后收到SR和发送RR之间的间隔，以1/65536为单位（否则为0)

}

RR的解释

这是一个接收质量的反馈，对Sender和其他的第三方如网络的monitor等都有意义

如：

1）可以计算Round-trip Time (RR收到时间-LSR - DLSR),round-trip time的估计是很重要的

2）Lost fraction：短期内，对媒体格式的选择有参考

3）Jitter：突然增大的Jitter通常意味着丢包的开始

SR(Sender Report)

Sender Report 提供了有关Sender所发送的媒体的信息，主要用于进行多个媒体流同步等.

PT = 200

Format:

固定头

Reporter SSRC

NTP Timestamp（2 octets）：发送SR的NTP

RTP Timestamp: 与previous field同一时刻，但是单位是RTP Media clock

Sender's packet count：自会话开始

Sender's octet count：自会话开始

SR的解释

计算速率等

媒体时钟和NTP时钟

⒊SDES: Source Description

用于提供参与者的详细信息，通常是人可读的，如email，电话等，依赖于应用.

PT = 202

Format:

固定头

*{

SSRC/CSRC

List of SDES items

}

Items中每个entry如下：

Type Length content

8 8

Type == 0 表示Lists结束

RFC中规定了一些Items如：CNAME,NAME,EMAIL,PHONE,LOC,TOOL,NOTE,and PRⅣ.

⒋RTCP BYE: Membership Control

通常用于指示会话中的某个成员正在离开.

但是RTCP BYE的含义在某种程度上是依赖于应用的，应用通常有其他的控制协议如SIP,H323等控制会话.

记住BYE不终止会话成员的关系，只是表示正在离开，并且不保证传输肯定到达.

PT=203

Format:

固定头

*{

SSRC

}

可选长度，可选原因

⒌RTCP APP: Application-Defined RTCP Packets

PT=204

⒍Compound Packet

以上的RTCP包从不单独发送，它们被打包成复合包（Compound Packet）来发送，有几个规则.

1）对活动的发送者（active data sender),compound必须以SR开始，否则以RR开始，即使没有数据接收和发送.后面跟着*个RR.

2）然后是SDES,SDES必须包含一个CNAME，其他可选.

3）如果有BYE的话，放到最后.其他的包可以随意.

RTCP Packet从来不单独传输，他们按照一定的规则总是组成Compound Packet来传送.下面介绍这个规则：

1）最前面可以有个可选的32位值（在RTCP compound packet加密时使用）

Security and Privacy

SDES的传输中暴露隐私，这是个问题.但是CNAME是必须的.

Packet Validation

⒈所有的包必须是复合包

⒉版本必须是2

⒊复合包开始的RTCP Packet必须是SR和RR

⒋如果需要Padding，则只有最后一个packet是padding的.

⒌所有的RTCP packets的长度必须等于复合RTCP包的长度.

参与者和会话的信息

⒈RTCP的全局配置信息

1）The RTP bandwidth

1）RTCP所占总带宽的比例（这意味必须知道RTP所占的总带宽）：default 0.05

2）发送间隔：default 5s（最小）

3）发送部分所占的比例：default 0.025

4）The average size of all RTCP packets sent and received by this participant.

5）The number of members in the session,the number of members when this participant last sent an RTCP packet,and the fraction of those who have sent RTP data packets during the preceding reporting interval.

6）The time at which the implementation last sent an RTCP packet,and the next scheduled transmission time.

8）A flag indicating whether the implementation has sent any RTP data packets since sending the last two RTCP packets.

9）A flag indicating whether the implementation has sent any RTCP packets at all.

10）The number of packets and octets of RTP data it has sent.

11）The last sequence number it used.

12）The correspondence between the RTP clock it is using and an NTP-format timestamp.

会话中每个成员的信息

1）SSRC identifier.

2）Source description information: the CNAME is required; other information may be included (note that these values are not null-terminated,and care must be taken in their handling).

3）Reception quality statistics (packet loss and jitter),to allow generation of RTCP RR packets.

4）Information received from sender reports,to allow lip synchronization (see Chapter 7）.

5）The last time this participant was heard from so that inactive participants can be timed out.

6）A flag indicating whether this participant has sent data within the current RTCP reporting interval.

7）The media playout buffer,and any codec state needed (see Chapter 6,Media Capture,Playout,and Timing).

8）Any information needed for channel coding and error recovery—for example,data awaiting reception of repair packets before it can

Timing Rules

总的目标是限制RTCP占RTP会话量的一小部分，通常是5%.在这个目标的前提下，参与者送出RTCP packet的速率是不固定的，而是变化了，如对有大量的listener的Internet Radio，客户端可能几分钟才发送，而对two-party的电话可能是几秒钟.

有一些规则可以参考，这些规则可以确保实现的可缩放性（Scalability).

⒈Reporting Interval

根据以下几个部分来计算：

1）.The bandwidth allocated to RTCP:5%通常 * Session带宽

2）.The average size of RTCP packets sent and received：包括所有头（UDP,IP)

3）.The total number of participants and the fraction of those participants who are senders

在计算时，

SNo:Sender Number

ANo：所有参与者数目

RNo:Receiver Number

Intl:Interval

ARS:average RTCP size

RW:RTCP bandwidth

if (senders > 0 && senders <= （25% of total number of participants)

{

if (we are sending)

{

Interval = average RTCP size * senders / （25% of RTCP bandwidth)

}

else

{

Interval = average RTCP size * receivers / （75% of RTCP bandwidth)

}

}

else if ((senders = 0) or (senders > （25% of total number of participants))

{

Interval = average RTCP size * total number of members / RTCP bandwidth

}

这样可以确保Sender即使很少的情况下也可以确保25%的带宽，能够送出足够的lip synchronization信息

If (Interval < minimum interval)

{

Interval = minimum interval

}

当会话中的参与者的数目或者sender所占比例发生变化时，报告间隔应当重新计算.

⒉Basic Transmission Rules

基本的传输规则就是：

I = (Interval * random[0.5,1.5])

if (this is the first RTCP packet we are sending) {

I *= 0.5

}

next_rtcp_send_time = current_time + I

对于有很多参与者，并且数目还在变化的会话，每次发送当前的RTCP Packet后，根据得到的Participants Number来计算.

⒊Forward Reconsideration

方法：

在每次发送前，根据当前的会话信息重新计算发送时间，

if (current_time >= next_rtcp_check_time) {//1.21828是一个补偿因子

new_rtcp_send_time = (rtcp_interval() / 1.21828） + last_rtcp_send_time

if (current_time >= new_rtcp_send_time) {

send RTCP packet

next_rtcp_check_time = (rtcp_interval() /1.21828） + current_time

} else {

next_rtcp_check_time = new_send_time

}

}

⒋Reverse Reconsideration

为此，当BYE来时，立即重新计算下个包的发送时间.

⒌BYE Reconsideration

大量的BYE，为此可以：延迟BYE的发送，或者干脆不发送.

⒍Comments on Reconsideration

各个实现应该考虑这个问题，并尽可能的使用各个Reconsideration.

⒎Common Implementation Problems

1）没有正确的考虑参与者的数目，固定的Reporting Interval会导致流量呈线性增长.

2）Reporting interval没有随机化.有潜在的可能：同步他们的reports，导致

3）在带宽计算时未考虑Headers(IP,UDP）等

4）padding使用不正确