RTCP协议介绍

来源:互联网 发布:森女部落淘宝 编辑:程序博客网 时间:2024/05/21 01:47

转自:http://blog.csdn.net/youdianmengxiangba/article/details/6308597

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) 。


0 0
原创粉丝点击