RTP协议

RTP,实时协议被用来为应用程序如音频,视频等的实时数据的传输提供端到端(end to end)的网络传输功能。传输的模型可以是单点传送或是多点传送。数据传输被一个姐妹协议——实时控制协议(RTCP)来监控,后者允许在一个大的多点传送网络上监视数据传送,并且提供最小限度的控制和识别功能。

 

RTP是被IETFRFC1889中提出来的。顺带提及,RTP已经被接受为实时多媒体传送的通用标准。ITU-TIETF都在各自的系统中将这一协议标准化。

 

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/IPATM,帧时延等类型的网络上。

如果被下层网络支持,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层面上能识别从一个用户产生的不同媒体的唯一的标识符。

posted @ 2007-07-04 17:14  AndyHai  阅读(2944)  评论(1编辑  收藏  举报
QQ: 2369537