RTCP协议介绍

RTCP

概要


实时传输控制协议(R
eal-t
ime C
ontrol
P
rotocol
，RTCP)
与RTP
共同定义在1996
年提出的RFC 1889
中，
是和 RTP
一起工作的控制协议。RTCP
单独运行在低层协议上，由低层协议提供数据与控制包的复用
。在RTP
会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP
控制信息包，如下图所示。对于RTP
会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP
和RTCP
信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP
信息包和RTCP
信息包区分开来。

RTCP

功能



1
、
为应用程序提供会话质量或者广播性能质量的信息
　

RTCP
的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个
RTCP
信息包不封装声音数据或者电视数据，而是封装发送端和
/
或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息反映了当前的网络状况，对发送端、接收端或者网络管理员都非常有用。
RTCP
规格没有指定应用程序应该使用这些反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来调整传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用
RTCP
信息包中的信息来评估网络用于多目标广播的性能。

2
、确定
RTP
用户源　

RTCP
为每个
RTP
用户提供了一个全局唯一的称为规范名称
(Canonical Name)
的标志符
CNAME
，接收者使用它来追踪一个

RTP
进程的参加者。当发现冲突或程序重新启动时，
RTP
中的同步源标识符
SSRC
可能发生改变，接收者可利用
CNAME
来跟踪参加者。同时，接收者也需要利用
CNAME
在相关
RTP
连接中的几个数据流之间建立联系。当
RTP
需要进行音视频同步的时候，接受者就需要使用
CNAME
来使得同一发送者的音视频数据相关联。

3
、控制
RTCP
传输间隔　

由于每个对话成员定期发送
RTCP
信息包，随着参加者不断增加，
RTCP
信息包频繁发送将占用过多的网络资源，为了防止拥塞，必须限制
RTCP
信息包的流量，控制信息所占带宽一般不超过可用带宽的
5%
，因此就需要调整
RTCP
包的发送速率。由于任意两个
RTP
终端之间都互发
RTCP
包，因此终端的总数很容易估计出来，应用程序根据参加者总数就可以调整

RTCP
包的发送速率。

4
、传输最小进程控制信息　

这项功能对于参加者可以任意进入和离开的松散会话进程十分有用，参加者可以自由进入或离开，没有成员控制或参数协调。

RTCP

信息包


类似于
RTP
信息包，每个
RTCP
信息包以固定部分开始，紧接着的是可变长结构单元，最后以一个
32
位边界结束。

根据所携带的控制信息不同
RTCP
信息包可分为
RR
（接收者报告包）、
SR
（源报告包）、
SEDS
（源描述包）、
BYE
（离开申明）和
APP
（特殊应用包）五类
5
类：

1
、
SR
：

源报告包，用于发送和接收活动源的统计信息；

2
、
RR
：

接收者报告包，用于接收非活动站的统计信息；

3
、
SDES
：

源描述包，用于报告和站点相关的信息，包括
CNAME
；

4
、
BYE
：

断开
RTCP
包，是站点离开系统的报告，表示结束；

5
、
APP
：

应用特定函数。

不同类型的
RTCP
信息包可堆叠，不需要插入任何分隔符就可以将多个
RTCP
包连接起来形成一个
RTCP
组合包，然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个
RTCP
包的显式计数。

组合包中每个
RTCP
包可独立处理，而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束：

1
、只要带宽允许，在
SR
包或
RR
包中的接收统计应该经常发送，因此每个周期发送的组合
RTCP
包中应包含报告包。

2
、每个组合包中都应该包含
SDES CNAME
，因为新接收者需要通过接收
CNAME
来识别源，并与媒体联系进行同步。

3
、组合包前面是包类型数量，其增长应该受到限制。

所有
RTCP
包至少必须以两个包组合形式发送，推荐格式如下：

加密前缀（
Encryption prefix
）：

仅当组合包被加密，才加上一个
32
位随机数用于每个组合包发送。

SR
或
RR
：

组合包中第一个
RTCP
包必须是一个报告包，以帮助分组头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空
RR
，那怕组合包中
RTCP
包为
BYE
。

附加
RR
：

如报告统计源数目超过
31
，在初始报告包后应该有附加
RR

包。

SDES
：

包含
CNAME
项的
SDES
包必须包含在每个组合
RTCP
包中。
SDES
包可能包括其他源描述项，这要根据特别的应用需要，并同时考虑带宽限制。

BYE
或
APP
：

除了
BYE
应作为最后一个包发送，其它
RTCP
包类型可以任意顺序排列，包类型出现可不止一次。

混合器从多个源组合单个
RTCP
包，如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以
SR
或
RR
包开始。附加
RTCP
包类型可在
Internet Assigned Numbers
Authority (IANA)
处注册，以获得合法的类型号。

RTCP

传输间隔


由于
RTP
设计成允许应用自动扩展，可从几个人的小规模系统扩展成上千人的大规模系统。而
每个会话参与者周期性地向所有其他参与者发送
RTCP
控制信息包，
如每个
参与者
以固定速率发送接收报告，控制流量将随
参与者
数量线性增长。由于网络资源有限，相应的数据包就要减少，直接影响用户关心的数据传输。为了限制控制信息的流量，
RTCP
控制信息包
速率必须按比例下降。

一旦确认加入到
RTP
会话中
，即使后来被标记成非活动站，地址的状态仍会被保留，地址应继续计入共享
RTCP
带宽地址的总数中，时间要保证能扫描典型网络分区，建议为
30
分钟。注意，这仍大于
RTCP
报告间隔最大值的五倍。

SR

源报告包和
RR

接收者报告包


SR
源报告包和
RR
接收者报告包用于提供接收质量反馈，除包类型代码外，
SR
与
RR
间唯一的差别是源报告包含有一个
20
字节发送者信息段。
RR
针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时间抖动、接收最后一个
SR
的时间、接收最后一个
SR
的延迟等信息。
SR
不仅提供接收质量反馈信息（与
RR
相同），而且提供
SSRC
标识符、
NTP
时间戳、
RTP
时间戳、发送包数以及发送字节数等。根据接收者是否为发送者来决定使用
SR
还是
RR
包，活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送
SR
；否则，就发送
RR
；
SR
和
RR
包都可没有接收报告块也可以包括多个接收报告块，其发布报告表示的源不一定是在
CSRC
列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有
31
个接收报告块嵌入在
SR
或
RR
包中，丢失包累计数差别给出间隔期间丢包的数量，而系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

SDES

源描述包


SDES
源描述包提供了直观的文本信息来描述会话的参加者，包括
CNAME
、
NAME
、
EMAIL
、
PHONE
、
LOC
等源描述项，这些为接收方获取发送方的有关信息提供了方便。
SDES
包由包头与数据块组成，数据块可以没有，也可有多个。包头由版本（
V
）、填充（
P
）、长度指示、包类型（
PT
）和源计数（
SC
）组成。
PT
占
8
位，用于识别
RTCP
的
SDES
包，
SC
占
5
位，指示包含在
SDES
包中的
SSRC/CSRC
块数量，零值有效，但没有意义。数据块由源描述项组成，源描述项的内容如下：

CNAME:
规范终端标识
SDES
项

类似
SSRC
标识，
RTCP
为
RTP
连接中每一个参加者赋予唯一一个
CNAME
标识。在发生冲突或重启程序时，由于随机分配的
SSRC
标识可能发生变化，
CNAME
项可以提供从
SSRC
标识到仍为常量的源标识的绑定。

为方便第三方监控，
CNAME
应适合程序或人员定位源。

NAME
：用户名称
SDES
项

这是用于描述源的真正的名称，如
"John Doe, Bit Recycler, Megacorp"
，可以是用户想要的任意形式。由于采用文本信息来描述，对诸如会议应用，可以对参加者直接列表显示，
NAME
项是除
CNAME
项以外发送最频繁的项目。
NAME
值在一次
RTP
会话期间应该保持为常数，但它不该成为连接的所有参加者中唯一依赖。

EMAIL
：电子邮件地址
SDES
项

邮件地址格式由
RFC822
规定，如
"John.Doe@megacorp.com"
。一次
RTP
会话期间，
EMAIL
项的内容希望保持不变。

PHONE
：电话号码
SDES
项

电话号码应带有加号，代替国际接入代码，如
"+1 908 555 1212"
即为美国电话号码。　

LOC
：用户地理位置
SDES
项

根据应用，此项具有不同程度的细节。对会议应用，字符串如
"Murray Hill, New Jersey"
就足够了。然而，对活动标记系统，字符串如
"Room 2A244, AT&T BL MH"
也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在一次
RTP
会话期间，除移动主机外，
LOC
值期望保持不变。

TOOL
：应用或工具名称
SDES
项

TOOL
项包含一个字符串，表示产生流的应用的名称与版本，如
"videotool 1.2"
。这部分信息对调试很有用，类似于邮件或邮件系统版本
SMTP
头。
TOOL
值在一次
RTP
会话期间保持不变。

NOTE:
通知
/
状态
SDES
项

NOTE
项旨在描述源当前状态的过渡信息，如
"on the phone, can't talk"
，或在讲座期间用于传送谈话的题目，它的语法可在设置中显式定义。
NOTE
项一般只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和
CNAME
发送的速度，损害协议的性能。一般
NOTE
项不作为用户设置文件的项目，也不会自动产生。

由于
NOTE
项对显示很重要，当会话的参加者处于活动状态时，其它非
CNAME
项（如
NAME
）传输速率将会降低，结果使
NOTE
项占用
RTCP
部分带宽。若过渡信息不活跃，
NOTE
项继续以同样的速度重复发送几次，并以一个串长为零的字符串通知接收者。

PRIV:
专用扩展
SDES
项

PRIV
项用于定义实验或应用特定的
SDES
扩展，它由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值组成。前缀长度段为
8
位。前缀字符串是定义
PRIV
项人员选择的名称，唯一对应应用接收到的其它
PRIV
项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。

注意，前缀应尽可能的短。
SDES

的
PRIV
项前缀没在
IANA
处注册。如证实某些形式的
PRIV
项具有通用性，
IANA
应给它分配一个正式的
SDES
项类型，这样就不再需要前缀，从而简化应用，并提高传输的效率。

BYE

断开
RTCP

包


如混合器接收到一个
BYE
包，混合器转发
BYE
包，而不改变
SSRC/CSRC
标识。如混合器关闭，在关闭之前它应该发出一个
BYE
包，列出混合器处理的所有源，而不只是自己的
SSRC
标识。作为可选项，
BYE
包可包括一个
8
位八进制计数，后跟文本信息，表示离开原因，如：
"camera
malfunction"
或
"RTP
loop detected"
。字符串的编码与在
SDES
项中所描述的相同。如字符串信息至
BYE
包下
32
位边界结束处，字符串就不以空结尾；否则，
BYE
包以空八进制填充。

APP

特殊应用包


APP
包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的
APP
包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个
APP
包，而不用向
IANA
注册子类型和名称段。

RTP/ RTCP

的不足之处


RTP
与RTCP
相结合虽然保证了实时数据的传输，但也有自己的缺点。最显著的是当有许多用户一起加入会话进程的时候，由于每个参与者都周期发送RTCP
信息包，导致RTCP
包泛滥
(flooding)
。