RTP_RTCP协议分析

RTP/RTCP协议分析
摘要
本文主要介绍了RTP/RTCP协议组成，在详细了解和分析RFC3550协议和阅读目前国内外在RTP协议研究成果上给出了使用协议的要求及使用过程中需要
注意的问题。

前言
RTP/RTCP协议是IETF的音视频传输工作组提出的在Internet和现有局域网上传输实时信息的一个新型协议，是实现实时通信不可缺少的协议。

该协议是专门为交互的音频、视频等实时性数据而设计的。

RTP/RTCP协议由实时传输协议RTP和实时传输控制协议RTCP两部分组成。

RTP负责实时性数据的传输，它工作于UDP和IP多点传送的顶层，用于处理IP网上的视频和音频流。

每个UDP 包均加上一个包含时间标志和符号化方式识别码后发送出去，接收端配以适当的缓冲区，它就可以利用时间标志和序号信息“复原再生”数据包、记录顺序、同步音频、视频和数据以及改善接收端连接重放效果。

RTCP监测数据传输并管理控制信息，它监视迟滞和带宽，并将其通知发送端。

一旦可用带宽变窄，RTCP 立刻将该信息通知发送端，发送端根据此信息，变更符号化方式识别码，继续进行多媒体通信。

RTP/RTCP充分考虑所给定的网络，实现传送质量与给定网络相适应的多媒体通信。

协议提供端到端的实时数据流传输业务，可以满足实时通信的基本要求，但协议本身并不提供对实时应用的服务质量标准，需要有下层的协议提供服务支持。

RTP/RTCP可以满足实时通信的基本要求，但如果要想保证实时应用的带宽，还需要利用RSVP协议。

RSVP装在端系统和路由器中，用以确保端对端的传输带宽。

它能够在数据网络上为实时性音频和视频业务实现带宽预留并设置队列管理方法，尽量减少实时通信中的时间延迟和延时抖动。

使用RTP/RTCP协议之前要对协议进行说明，以符合各种不同的要求，对RTP/RTCP的说明随应用程序而不同，但至少应包括以下两个文件：框架文件：定义净荷类型的代码，并将这些代码映射到净荷的格式之中;定义对RTP/RTCP的扩充或修改以满足特殊应用的需要。

通常一个框架文件对应一个应用程序;
净荷格式说明文件：定义RTP如何传输特殊的净荷。

对带宽要求较高的服务在使用RTP/RTCP时会降低网络上其它服务的质量。

因此，在实现某一应用程序时应采取预防措施限制占用的带宽。

通常RTP/RTCP协议与资源预留协议RSVP (Resource Reservation Protocol)一起使用，通过RSVP在现有网络上为实时性音频和视频传输预留必须的带宽，并设置队列管理方法。

同时应用程序文档也应详细说明占用高带宽实时服务可能产生的冲突和局限性。

第1章相关定义
实时传输：在RTP中，实时传输不是指发送数据和接收数据在同一时刻进行。

就目前使用的路由技术而言，任何网络在传输信息时都会产生延时。

RTP中的实时传输是指符合某种延时要求的数据传输。

RTP净荷：RTP数据包传输的数据。

如，音频、视频数据等。

RTP数据包：由定长的RTP报头、特定数据源列表和净荷等组成的数据包。

有些底层协议需要定义一个封装的RTP数据包。

通常一个底层协议数据包由一个RTP数据包组成。

如果封装方法允许，那么底层协议数据包可以包含多个RTP 数据包。

RTCP数据包：RTP控制数据包，由定长的RTCP报头和结构化元素组成。

结构化元素随RTCP数据包类型而变化。

通常多个RTCP数据包一起传送，它们在底层协议中被组合成一个混合RTCP数据包。

端口(Port) ：在给定节点中区分多个目的地址的概念。

TCP/IP协议用一个整数来标识端口。

OSI传输层使用的传输选择器(TSEL)与端口等价。

RTP根据底层协议提供的一些方法来实现RTP和RTCP数据包的多路传输。

传输地址：用于标识传输层端点的端口和网络地址的组合，如IP地址和UDP 端口。

数据包从源地址传送到目的地址。

RTP数据包，以某种方式将接收到的RTP数据包组合成一个新的混合数据包并转发该混合数据包。

由于多个输入数据源在时间上通常是不同步的，因此混合器必须调整接收多个数据包的时间标志，并为混合数据包产生新的时间标志。

这样，由混合器产生的所有数据包可以由其同步源(混合器)来标识。

转换器(Translator)：一个中间系统。

它完整地转发RTP数据包及其同步源标识符。

转换器包括不进行混合的编码转换设备，把多点传送转换为单点传送及防火墙中的应用层过滤器。

监示器(Monitor)：一个应用程序，接收由RTP会话的用户所发送的RTCP数据包，尤其是接收端报告;为分布式监示器评估当前的服务量、错误诊断及统计工作。

监视功能可嵌入在会话用户的应用程序中。

也可以是一个独立的不接收RTP数据包的应用程序，此类监示器称为第三方监示器。

非RTP方式：除RTP协议外，一个有效服务还需要其它的协议和方法。

尤其是在多媒体会议中，会议控制程序要分配多点传送地址和密钥，处理加密算法，为RTP净荷类型码和事先未经定义的净荷类型定义动态映射。

对于有些应用程序可能还需要电子邮件和会议数据库等。

第2章协议分析
2.1 RTP数据传输协议
RTP数据传输协议主要包括RTP报头格式、多路RTP会话的实现和由框架文件说明的对RTP报头的调整。

2.1.1 定长的RTP报头字段
RTP数据传输协议RTP报头的格式如表格2-1。

每个RTP数据包都包含特定数据源标识符前的12个字节。

仅当混合器插入CSRC标识符时，RTP数据包
包含该标识符。

各字段的长度和含义如下：
表2-1 RTP报头格式
V（Version）：2位。

定义RTP版本号，当前版本号为2.0
P (Padding) ：1位。

该位置1时，数据包的尾部有一个或多个补充字节(Padding Octet)。

补充字节不是净荷的组成部分。

最后一个补充字节包含应该勿略的字节数。

具有固定块长度的某些加密算法或底层协议的数据单元要携带多个RTP数据包时需要补充字节。

X (Extension)：1位。

该位置1时，头可以使RTP数据包携带更多的信息，RTP报头之后有一个扩充报头。

扩充报以适应各种不同类型的实时应用。

CSRC计数(CC)：4位。

RTP报头之后CSRC标识符的个数。

M (marker) ：1位。

标志位由框架文件定义。

设置标志位的目的是利用有效标志(如帧边界)来标记数据流的数据包。

框架文件可以定义附加的标志位，也可以通过修改净荷类型字段的位数来说明标志位。

净荷类型（Payload Type）：7位。

定义RTP净荷的格式并决定应用程序如何使用净荷。

框架文件详细说明了净荷类型码与净荷格式之间缺省的静态映射。

一些附加的净荷类型码由非RTP方式动态定义。

在给定时间内，RTP发送端只使用一种RTP净荷。

该字段不能用于多路传输独立的媒体数据流。

序号（Sequence Number）：16位。

每发送一个RTP数据包序号加1。

接收端
可用该序号检测数据包的丢失，确定数据包的正确位置，使接收端按发送端发送数据的顺序重新组织接收到的数据包。

这样，数据包的解压缩可按任意顺序进行，应用程序按序号既可正确组织解压缩的数据包。

时间戳(Timestamp)：32位。

它与数据包中数据的采样频率有关。

采样频率来自时钟，它可用于同步和计算网络阻塞。

它可以由净荷格式说明文件静态地指定，也可以由非RTP方式定义的净荷格式动态地指定。

如果数据包不按其采样顺序传输，那么相邻的RTP数据包的时间标志是非单调的，但数据包的序号仍然是单调的。

SSRC：32位。

SSRC字段用来标识同步源。

该字段的值是一个随机数。

若非故意设置，在同一个RTP会话内，任意两个同步源的SSRC标识符均不应相同。

可用某种算法产生随机的SSRC标识符。

虽然所有的数据源选择相同标识符的概率很少，但RTP必须能够检测和解决所产生的冲突。

如果数据源的传输地址发生变化，那么必须重新选择SSRC标识符，以防止产生环路数据源。

CSRC列表：0-15项，每项32位。

CSRC列表用来标识某数据包所含净荷的特定数据源。

标识符的数量由CC字段给出。

当特定数据源超过15个时，只能识别其中的15个。

混合器使用特定数据源的SSRC标识符插入CSRC标识符。

2.1.2 多路复用RTP会话
在RTP中，由RTP会话的目标传输地址(网络地址和端口号)提供多路传输。

例如，在音视频会议中，RTP会话在传输音视频信息时分别使用各自的目标传输地址，而不是通过同一个RTP会话传输两种信息，再把它们按净荷类型或SSRC 字段的值进行分离。

因为使用相同的SSRC标识符交叉存取净荷类型不同的数据包会产生下列问题：
●当RTP会话中净荷类型发生变化时，无法用普通方法识别由新类型代替
的旧类型：
●SSRC标识符用来标识一类时间标志和属于同一序列的序号。

当媒体的
时钟频率不同时，交叉存取需要使用多种类型的时间标志(间隔不同),数
据包丢失时，交叉存取需要使用属于不同序列的序号;
●对于每一个SSRC标识符，RTP发送端和接收端报告只能描述一类时间
标志和属于同一序列的序号;
●对于不同类型的数据，RTP混合器无法将交叉存取的多个数据流组成混
合数据流：
●在一个RTP会话内传输多种媒体信息会产生下列问题：在需要时，无法
使用不同的网络路径，无法分配网络资源;不能接收所传信息的某一部
分，如在视频信息超出可用带宽时，不能只接收音频信息。

即使所用的
RTP会话允许执行多个进程，接收端应用程序仍无法用不同的进程处理
不同的信息。

2.1.3 由框架文件说明对RTP报头的调整
从前面的阐述了解到RTP报头能满足多种应用的需要。

为了扩大RTP的应用范围，需要对RTP报头进行调整。

这种调整可以通过修改RTP报头或在框架文件中增加定义来实现。

但监视和记录功能则仍然独立于框架文件。

具体做法是：
标志位和净荷类型字段携带框架文件说明信息。

为了避免用另一个32位字段来记录这些信息可将它们配置在RTP报头中。

上述字段的含义可以由框架文件重新定义以满足不同的需要;
数据包中描述净荷格式的字段应包含特殊净荷所需的附加信息和视频编码方法等。

这部分信息应位于净荷字段的开始部分，并用表中的保留值表示。

当某一类特殊的应用程序需要独立于净荷的其它功能时，与之相关的框架文件应定义定长的附加字段来说明所需的其它功能并置于SSRC字段之后。

这样应用程序就能迅速、直接地访问附加字段。

扩充RTP报头使其携带所需的附加信息可以使应用程序实现与净荷格式无关的新功能。

不需要扩充的应用程序可以忽略报头中的扩充部分。

RTP报头的X位置1时，该报头含有变长的扩充数据，位于CSRC列表之后。

扩充数据含有一个16位的长度字段，它以32位字为单位对扩充数据计数，不包括4个字节的扩充报头。

只能对RTP报头进行一种类型的扩充。

为使多个应用程序能处理互相独立的扩充数据，使一个应用程序能处理各种扩充数据，扩充数
据的前16位是开放的用于识别标识符和参数。

上述16位数据由应用程序相关的框架文件定义。

RTP本身不定义任何报头扩充。

扩充报头的格式如表格2-2。

表2-2 扩充报头格式
2.2 RTP控制协议--RTCP
RTCP定期为会话中的所有用户传输控制数据包。

底层协议必须为RTP数据包和控制数据包提供多路传输功能。

RTCP实现下列四个功能：
提供数据分布质量反馈信息。

这是传输协议必须具有的功能。

它与其它传输协议的数据流控制和网络阻塞控制有关，反馈信息可直接用于控制自适应编码。

对IP多点传送的试验表明，从接收端获取的反馈信息对于诊断数据分布的失效起关键作用。

采用与IP多点传送相类似的方法，可使某个用户将接收的反馈信息作为第三方监示器诊断网络可能存在的问题。

反馈功能由RTCP发送端报告和接收端报告实现。

为RTP数据源(CNAME)传送一个固定的传输层标识符。

由于发生冲突或程序重新启动时SSRC标识符会发生变化，因此接收端需要用CNAME来记录每个用户的信息。

接收端还需要用CNAME实现多个数据流的关联。

这些数据流来自相关RTP会话所指定的用户;
前两个功能要求所有的用户都发送RTCP数据包。

为了扩大用户数量，RTCP数据包的发送必须是可控的。

通过向所有其它用户发送控制数据包可以了解用户的数量。

该数量可用于计算数据包的发送速率。

第四个功能是可选的。

传输最少的会话控制信息。

这个功能在“松散藕合型”
会话中非常有用。

在“松散藕合型”会话中，用户的加入与退出不受成员关系的控制。

RTP用于IP多点传送环境时，功能1-3是必须的。

设计RTP应用程序时应避免使用只能实现单点传送的方法，因为这种方法不能适应用户数量较大的应用。

2.2.1 RTCP数据包格式
下面给出RTCP数据包的几种类型，它们分别传输不同的控制信息：SR：发送端报告，发送和接收来自活动发送端的统计信息。

⏹RR：接收端报告，接收来自非活动发送端的统计信息。

⏹SDES：数据源描述项，包括CNAME。

⏹BYE：表示某用户结束会话。

⏹APP：由应用程序指定的功能。

每一个RTCP数据包由一定长的报头和结构化元素组成。

结构化元素的长度随数据包的类型而不同。

RTCP数据包以一个32位的分隔符结尾。

多个RTCP 数据包组成混合数据包时无需为每个数据包插入分隔符。

由于混合数据包的最终长度由底层协议所提供的总长度决定，所以混合数据包中RTCP数据包的数量是不确定的。

应用程序可按任意顺序处理RTCP数据包，而不必须考虑它们在混合数据包中的次序。

为了实现协议的功能必须：
⏹在带宽允许的情况下，尽可能增加发送接收统计信息的次数以便最有效
地利用这些信息。

要求每个RTCP数据包必须含有接收端报告;
⏹新接收端应尽早接收数据源的CNAME以识别数据源并实现信息关联。

要求每个RTCP混合数据包都包含SDES和CNAME;
⏹应限制混合数据包中首次出现的数据包类型，以增加第一个字的固定位
数来提高RTCP数据包的有效性，防止对RTP数据包或其它无关数据包
的错误访问。

因此，所有的RTCP数据包必须以混合数据包的形式发送。

混合数据包至少
应包含具有下列格式的两个独立的数据包：
编码前缀：仅当混合数据包加密时，数据包前附带一个32位随机数，用于重新编码每个传输的数据包。

SR或RR：混合数据包中的第一个数据包必须是接收端或发送端报告以便对报头进行有效性操作。

既使混合数据包只有BYE数据包或者不发送、不接收数据也要如此，因为此时要发送一个空的RR数据包。

附加的RRS：如果被报告的接收统计信息的数据源数量超过31个，即一个SR或RR能容纳的最大数据源的数量，那么初始报告之后应加一个或多个附加的RR数据包。

SDES：每个混合RTCP数据包必须包括含一个CNAME数据项的SDES数据包，对于特殊的应用程序如果需要并且网络带宽也能满足要求，那么可以包括其它可选的信号源说明数据项。

BYE或APP：所有己定义的其它RTCP数据包可按任意次序排列，只有BYE 数据包例外。

在RTCP数据包中，它必须是最后一个数据包并且只能出现一次，而其它类型的数据包可出现多次。

尽可能将来自多个数据源的互相独立的RTCP数据包组成一个混合数据包以减少开销。

这样做对于转换器和混合器是合理可行的。

如果一个混合数据包的总长度超过了某网络路径中的最大传输单元(MTU)，那么应将它拆成多个较短的数据包。

注意：每个混合数据包必须由SR或RR数据包开头。

应用程序将忽略未知类型的RTCP数据包。

2.2.2 发送端报告(SR)和接收端报告(RR)
RTP接收端用RTCP报告为发送端提供接收质量反馈信息。

RTCP报告分为两种，发送端报告(SR)和接收端报告(RR)。

根据接收端是否同时也是发送端，RTCP报告可能使用两个表格中的一个。

除数据包类型码外，发送端报告表格和接收端报告表格之间的唯一差别是发送端报告含有供活动态发送端使用的20个字节的发送端信息。

如果一个会话现场在发送最后一个报告或者在发送前一个报告之后的一个周期内发送了数据包，那么该现场就发送SR报告，否则就发送
RR报告。

SR和RR表格包括0个或多个接收报告数据块，每个数据块对应一个同步源。

每个数据块表示从收到最后一个报告以后，接收端又从这些同步源收到了RTP 数据包。

报告不用于CSRC列表中列出的特定数据源。

每一个接收报告数据块都提供从某个特定数据源收到数据的统计信息。

SR或RR数据包最多可包含31个数据块。

为了能包含所有数据源的接收报告，应将附加的RR数据包放在原始SR或RR数据包之后。

下面分别介绍SR报告和RR报告的格式，并说明在应用程序需要附加的反馈信息时，如何用框架文件方式扩充SR和RR，如何使用报告。

2.2.2.1 发送端报告RTCP数据包(SR)
SR的格式如表2.3。

它由三部分成组成，也可包含扩充部分。

第一部分是长度为8个字节的报头。

每个字段的含义如下：
V、P字段与RTP报头中相应字段的含义相同。

RC：接收报告计数，5位。

数据包中RR数据块的数目，可为0。

PT：数据包类型，8位。

其值为常量200，用于标识SR数据包。

Length：16位。

RTCP数据包的长度，包括报头和补充字节信息，每32位为一个计数单元。

SSRC：32位。

创建SR数据包的同步源标识符。

第二部分是长度为20个字节的发送端信息，每个SR都含有这部分信息。

它对发送端传输的数据进行计数。

每个字段的含义如下：
NTP时间标志：64位。

表示SR的发送时间。

它与从接收端返回的时间标志配合用来计算在发送端和接收端间的数据传输时间。

RTP时间标志：32位。

与NTP时间标志对应的时间值。

它用于同步与NTP 时间标志同步的数据源。

也可用于接收端估算RTP时钟频率。

发送端数据包计数：32位。

从开始传输到产生SR数据包这段时间内由发送端发送的RTP数据包。

发送端改变其SSRC标识符时重新设置该计数值。

第三部分是0个或多个RR数据块。

数据块的数量由接收最后一个报告以来该发送端所收听的其它数据源的数量确定。

每个RR数据块通过接收来自单同步源的RTP数据包传输统计信息。

由于冲突而使数据源改变其SSRC标识符时，接收端不改变其统计信息。

统计信息有：
SSRC_n(数据源标识符)：32位。

SSRC标识符，在RR数据块中与数据源有关的信息。

丢失率：8位。

发送前一个SR或RR数据包后来自数据源SSRC_ n的RTP 数据包的丢失比例等于丢失的数据包除以发送的数据包。

因复制而使数据包丢失数为负值时，丢失率为0。

丢失数据包累计数：24位。

开始接收后，来自数据源SSRC_n的丢失数据包数量等于发送的数据包减去实际收到的数据包，包括以后收到的或复制的数据包。

因此，后来收到的数据包不作为丢失数据包。

当复制数据包时，丢失数据包的值可能为负数。

发送的数据包个数等于收到的数据包中的最大序号减去最小序号。

收到的最大序号扩展：32位。

低16位为从数据源SSRCen收到的RTP数据包的最大序号。

高16位为对上述序号的扩展。

接收抖动:32位。

RTP数据包收到时刻的统计偏差的估值，用时间标志单元作测量单位，用无符号正数表示。

最后SR延时(LSR)：32位。

NTP时间标志的中间32位。

若没有收到SR报告，则该字设置为0。

从最后一个SR以来的延时(DLSR)：32位。

从数据源SSRC_ n接收到最后的SR数据包到发送相应的接收报告间的延时，以1/65536秒为单位。

若没有收到SR数据包，则DLSR字段设置为0。

表2-3发送端报告格式
2.2.2.2 接收端报告RTCP数据包(RR)
RR数据包的格式如表2. 4所示。

除净荷类型字段的值为常量201外，其它字段与SR数据包中相应字段的含义相同。

去掉了5个字(NTP时间标志、RTP 时间标志、发送端数据包和字节计数)的发送端信息。

不发送数据或不接收报告时，在混合RTCP数据包的开始部分应放置空的RR 数据包(RC=0)。

表2-4发送端报告格式
2.2.2.3 扩充发送端和接收端报告
发送端和接收端需要报告附加信息时，框架文件应扩充SR和RR。

这种方法比重新定义一种RTCP数据包类型要好，因为它的开销较少：
●数据包中的字节数更少(没有RTCP报头或SSRC字段)。

●由于应用程序运行在相关的框架文件之下，所以它能在收到接收报告后
直接访问其中的扩充字段，送端信息时，收端信息时，应先将其放在因
此能更简单快捷地分析接收报告。

需要附加的发SR的扩充部分，但不
出现在接收端报告中。

需要接应将其组织成以数据块为单位的数组，收
报告数据块数组并行放置，即数据块的数量由RC并将该数组与己存在
的接字段给出。

2.2.2.4 分析发送端和接收端报告
可以肯定，接收质量反馈信息不仅对发送端有用，而且对接收端和第三方监示器也有用。

发送端可以根据反馈信息来调整其传输速度；接收端可以通过反馈信息确定所发生的问题是本地的、局部的还是全局的，网络管理人员可以使与框架文件无关的监示器只接收RTCP数据包而不接收相应的RTP数据包，并通过接收的RTCP数据包评估网络的性能。

在SR和RR中使用数据包累计数可以计算任何两个报告的差异并可防止报告的丢失。

最后收到的两个报告间的差异可用来估计分布的质量。

发送端报告中包含NTP时间标志的目的是通过两个报告的差异计算传输速率。

由于时间标志与数据编码所用的时钟频率无关，所以可以实现独立于数据编码或独立于框架文件的质量测检。

通过发送端信息，第三方监示器能在不接收数据的情况下算出净荷和数据包的平均传输速率。

两者的比例给出了净荷的平均大小。

如果数据包的丢失与数据包的大小无关，那么某接收端所收到的数据包的数量乘以净荷的平均大小就是该接收端吞吐量的近似值。

2.2.3 数据源描述RTCP数据包(SDES)
表2-5数据源描述RTCP数据包
数据源描述RTCP数据包如表格2-5， SDES数据包分为三层，它由报头和0个或多个数据块组成。

每个数据块由描述块中数据源的数据项组成。

下面将分别介绍这些数据项。

V, P, Length, SSRC/CSRC字段与SR数据包中相应字段的含义相同。

PT: 8位。

其值为常量202，标识RTCP SDES数据包。

SC: 5位。

SDES数据包所含的SSRC/CSRC数据块数。

0为有效值。

每个数据块由一个SSRC/CSRC标识符再加上0个或多个数据项组成。

这些数据项携带SSRC/CSRC信息。

每个数据块用一个32位的分隔符分隔。

每个数据项由一个8位的类型字段，一个8位的描述文本长度的字节计数字段和文本组成。

文本长度不能超过255个字节，文本不能用空字节结束。

数据块的数据项以一个或多个空字节结尾。

在最后一个数据项的未尾，若不足32个字节，则以空字节填补。

下面说明几种SDES数据项。

其中CNAME数据项是必须的，有些仅用于特定的框架文件，但通常指定所有类型的数据项以实现共享并可简化独立于框架文件的应用程序。

2.2.
3.1 CNAME：端点标识符SDES数据项
表2-6应用程序或工具名SDES数据项
CNAME有下列特点:
●由于发生冲突或程序重新启动时SSRC标识符会发生变化，因此需要
CNAME来为此间未发生变化的数据源提供标识符。

●与SSRC标识符类似，在同一RTP会话中，对应于每个会话人员的CNAME。