RTP,实时协议被用来为应用程序如音频,视频等的实时数据的传输提供端到端(end to end)的网络传输功能。传输的模型可以是单点传送或是多点传送。数据传输被一个姐妹协议——实时控制协议(RTCP)来监控,后者允许在一个大的多点传送网络上监视数据传送,并且提供最小限度的控制和识别功能。
RTP是被IETF在RFC1889中提出来的。顺带提及,RTP已经被接受为实时多媒体传送的通用标准。ITU-T跟IETF都在各自的系统中将这一协议标准化。
1.1 为何需要RTP?
TCP不能支持像交互视频,会议等的实时服务,这一原因是由于TCP只是一个“慢”协议,需要三次握手。就此在IP层上UDP是一个比TCP更好的选择。但是UDP是本质上是一个不可靠协议,不支持在包丢情况下的重传机制。诚然,UDP有一些特性,比如多路复用跟校验和服务,这些都是对实时服务很有利的。为了消除UDP的缺点,RTP是作为应用层而被提出来的。
RTP提供的各种服务包括有效负载识别,序列编号,时间戳和投递监听。RTP能够序列化包,当这些包在收端不是按顺序到达的时。序列号也能被用来识别包丢失。时间戳被用于媒体有效的播放。到达的数据一直被RTCP监听,以通知RTP层来校正其编码和传输的参数。例如,如果RTCP层检测到包丢失,它会通知RTP层减缓发送速率。
尽管RTP有助于实时媒体的有效的播放 ,但是要注意的是RTP自身并不提供任何机制来确保及时传递或提供其他服务质量(QoS)的保证,而是依靠低层服务来完成这些。同样,RTP也不保证投递或防止无序投递。RTP被设计出来主要是为了满足有多个参加者的多媒体会议的需要。RTP也同样适合于象持续数据的储存,分布式交互仿真,主动标记以及应用程序的控制和测量。
1.2 RTP特性一览
RTP提供有效负荷类型识别,乱序重排和利用时间戳的媒体有效播放。
RTCP监控服务质量,也提供在一个当前进行的会话中传送关于参加者的信息作用。
RTP对于下层协议是独立的,它能够工作在像TCP/IP,ATM,帧时延等类型的网络上。
如果被下层网络支持,RTP支持利用多路技术的对于多点的数据传输。
RTP序列号也能被用来确定包的合适位置。例如在视频解码,包无需按序解码。
2.0 技术概览
2.1 RTP
RTP头具有如下的格式。开始的12个八位字节在每一个RTP包中都会出现;而CSRC标识符列表只在通过混合器的包中出现。这些域含有以下意义:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (V) (版本号): 这个域长度为2比特,标出了RTP的最近版本。当前的版本为2.0
Padding (P) (填充): 这个域长度为1比特,如果P被置位,包在结尾处包含有一个或多个附加的填充字节,这些填充字节不是有效负荷的一部分。填充是一些需要固定块大小的加密算法所要求的,或是为了在低层PDU搬运RTP包。
Extension (X): 这个域长度为1比特,如果被置位,固定的头后面紧跟了一个头的扩展。
CSRC count (CC): 这个域长度为4比特。这个域表示了跟在固定头后面的CSRC标识符的数目。 如前所述,这个域只有在通过一个混合器才有非零值。
Marker bit (M): 这个域长度为1比特,如果M被置位,表示一些重要的项目如帧边界在包中被标记。例如,如果包中有几个比特的当前帧,连同前一帧,那么RTP的这一位就被置位。
Payload type (PT) (有效负荷类型): 这个域长度为7比特,PT指示的是有RTP包中的有效负荷的类型。RTP音频视频简介(AVP)包含了一个默认的有效负荷类型码到有效负荷格式的映射。附加的有效负荷类型可以向IANA注册。
Sequence number(序列号): 这个域长度为16个比特,每送一个RTP包数目就增加一,初始值被设为一个随机数。接收方不仅可以用这个序列号检测包丢失,也可以重组包序列。
Time stamp(时间戳): 这个域长度为32个比特,时间戳反映了RTP数据包的头一个字节的采样时刻。 采样时刻必须是由一个单调线性增加的时钟产生,这样做是为了接收方的同步和抖动计算。初始值必须为随机数,这是为了避免对原码的攻击。例如,如果RTP源使用了一个编码器, 缓冲20ms的音频数据,那么RTP时间戳必须每个包增加160,无论包是被传递了还是被丢失了。
SSRC: 这个域长度为32比特,这个域表示了正在为会话产生RTP包的源。这个标识符是随机选中的,目的是为了避免同一个RTP会话中两个源有相同的标识符。
CSRC list: 这个列表标识了在这个包中对有效负荷起作用的所有源。标识符的最大数目限定为15,这是由CC域所限定的(全零在CC域中是被禁止的)。如果有超过15个的分配源,只有前15个被标识。
仔细观察RTP可以注意到它不像更低层的协议比如PDU一样,包含一个“定边界”的域。 这一原因是RTP的有效负荷是跟IP的有效负荷相同,因此也就不需要了。
如果相同的用户在一个会话中使用多个媒体,比如说视频跟音频,每个媒体都会打开单独的RTP会话。因此在RTP层面上不存在多路复用。多路复用由更低层来决定。但是RTCP保留了一个叫CNAME的标识符,这个标识符对于由同一用户初始化的媒体是相同的。因此CNAME是在RTP层面上能识别从一个用户产生的不同媒体的唯一的标识符。
从上可以看出,RTP头的开销是相当大的,为了减少这一开销,RTP头压缩被提了出来。
2.2 RTCP
RTP接收者利用RTCP报告包,提供接收质量的反馈。这个报告包可以是发送者类型也可以是接收者类型。如果接收者主动参加到一个会话中,那么它就送SR(sender report),否则它将送RR(receiver report)。除SR跟RR包以外,RTCP还有其他的包类型:SDES (Source Description), BYE 和APP(Application defined),RTCP和SDES包的有效负荷类型值在表1和表2中相应给出。
PACKET TYPE Payload Type
SR (发送者报告) 200
RR (接收者报告) 201
SDES (源描述) 202
BYE 203
APP (应用程序定义) 204
RTCP SDES ITEM Value
END (SDES列表结尾) 0
CNAME (规范名) 1
NAME (用户名) 2
EMAIL 3
PHONE 4
LOC 5
TOOL 6
NOTE 7
PRIV 8
2.2.1 RTCP SR 包
RTCP发送者报告包在图2中显示,各域含有下列意义。
Version (V): 与RTP中同
Padding (P): 与RTP中同
Reception report count (RC): 该域长度为5比特,RC表示接收报告块的大小。
Packet type (PT): 该域长度8比特,SR报告包的包类型是200。
SSRC: 与RTP中同
NTP Time stamp: 该域长度64比特,NTP表示了该包发送时的最大执行时间 (wall clock time),这个信息是被用来测量链路网络(round-trip)传播延时。
RTP Time stamp: 与RTP中同,这些时间戳被用于媒体内/外的同步。
Sender’s packet count: 该域长度为32比特,该域指示了从会话开始直到本SR被发送过程中发送者发出的RTP数据包的数目。
Sender’s octet count: 该域长度为32比特,表示从会话开始发送的有效负荷字节的总数目。
SSRC_n (源标识符): 该域长度为32比特,用于标识在此次阻塞报告中信息源
Fraction lost: 自前一个SR或RR包发送后丢失的RTP包的份额。
Cumulative number of packet lost: 该域长度为24比特,表示从会话开始,丢失的RTP数据包的总数目。
Extended highest sequence number received: 该域长度32比特,低16位包含从SSRC_n收到的RTP包中的最高序列号,最高16位用于扩展相应的序列号的循环周期的计数值。
值得注意的是在同一会话的不同接收这来说,如果他们的起始时间差别比较大的话,接收者将产生不同的扩展位。
Inter-arrival jitter: 该域长度32比特,表示了以时间戳为单位估计的RTP数据包到达时间的统计方差,用无符号的整数表示。
Last SR timestamp: 该域长度32比特,它把收到的NTP时间戳64位中间的32位作为最近的RTCP SR的一部分。
Delay since last SR (DLSR): 该域长度为32比特,延迟的单位是65536分之1秒,表示最近的SR包和本RR包之间的时间。
2.2.2 RTCP RR 包
RR包的结构与SR包相同,只是它没有包含发送者相关项(NTP, RTP 时间戳, 包数目跟字节数目)。 只有被动参加者才发RR包。
2.2.3 RTCP SDES 包
SDES包在图3中给出,不同类型的源描述包如下列出:
CNAME: 这是规范终端标识符。CNAME在SDES包中是必须出现的项目,其余的都是可选的。CNAME可以被接收者用来识别同一个特定用户产生的不同的媒体流。
其他被支持的SDES项是NAME, EMAIL,PHONE, LOC, TOOL, NOTE 和 PRIV
涉及到大量的参加者时,在一个会话过程中有可能RTCP的流量超过RTP的流量,这是由于,在时间的任何一个点上,只有一个人在说而其他的人都在听。为了减少RTCP的流量,RTCP的包传输率,作为参加者数目,RTCP包大小,RTCP带宽等的一个函数做动态变化。根据标准,会话带宽的20%分配给RTCP并且RTCP带宽的5%分配给CNAME。换句话说,每发送五个RTP包才发送一个RTCP的RR跟SR包。对于小型会话(参加者数目比较小),每5秒中会有一个RTCP的传输,每隔15秒钟,一个附加项会被包括在SDES包中。
2.2.4 RTCP BYE 包
RTCP BYE包在RTP会话的结尾被送出,包的结构如图4所示:
2.2.5 RTCP APP 包
APP包是为了新的应用程序和新的特性的实验用途,其结构如图5所示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.0 SIP中的RTP
IETF已经提议会话初始协议(SIP)作为因特网上多媒体调用的建立,修改和终结。RTP/RTCP被媒体用来作为在他们系统中传输的协议。SIP的流图结构如图6所示
4.0 H.323中的RTP
ITU-T已经提出了H.323,这是另一个著名的多媒体通信系统。RTP/RTCP再次被用作媒体传输。H.323的流图结构在图7中给出。
5.0 结论
RTP是应用层级别的协议,它提供了在单点传送或多点传送基础上,适合媒体传输如视频,音频,仿真数据等实时数据的,端到端的网络传输功能。RTP以序列化,有效负载识别和媒体实时播放为目标。数据传输增加了一个控制协议RTCP,这个协议监听了数据传送并且提供了最小限度的控制和识别功能。RTP和RTCP被设计成独立于下层网络传输网络,并且不提供源保留,也不保证实时服务的服务质量(QoS)。
RTP 术语表
RTP 有效负载: 在一个RTP包中被传输的数据。例如,音频样本或压缩视频数据。
RTP 媒体类型: RTP 媒体类型是有效负载类型的一个集合,这个集合在单一的RTP会话中被运载。有效负载类型是在音频视频协议(AVP)中被定义的【RFC 1890】。
RTP 会话:在一个使用RTP进行通讯的参加者集合中的联络。
Synchronizing source(SSRC):RTP包的源,由在RTP头中的一个32位数值SSRC标识符来表示。为了跟网络地址区别开来。
Contributing source (CSRC):RTP包的一个流的源,这个源是通过一个RTP混合器来产生一个混合的新流。
Mixer: 一个媒体间系统,它从一个或多个源发出的RTP包中提取内容,并把它们通过某种方式混合,然后从一个新的RTP包中送出。在此过程中数据格式可能被改变。
Translator: 一个媒体间系统,它把RTP包向前传送,并不改变它们的synchronizing source。Translator的例子包括编码转换而不混合的设备,从多点传送到单一传送的复制器,还有防火墙中应用级别的过滤器。
Monitor: 一个应用程序,它接收在一个RTP会话中参加者送出的RTCP包,并为分配监听,故障诊断,和长期统计估计当前的服务质量。
Non-RTP means:除了RTP以外,为了提供一个可用的服务的协议和机制。例如,在媒体传输之前需要发信号,这在SIP或H.323中被提出来。