实时传送协议

为程序指定处理在单点或多点网络服务上传输多媒体数据的方式的英特网传输标准
收藏
0有用+1
0
实时传送协议(RTP,Real-Time Transport Protocol)是一个为程序指定处理在单点或多点网络服务上传输多媒体数据的方式的英特网传输标准。
中文名称
实时传送协议
英文名称
real-time transport protocol;RTP
定  义
在因特网上,可用于一对一或一对多实时传送多媒体数据流的协议。
应用学科
通信科技(一级学科),通信协议(二级学科)
中文名
实时传输协议
外文名
Real-time Transport Protocol
类    型
概念
简    称
RTP

协议简介

播报
编辑
RTP(real-time transport protocol),实时传输协议。RTP在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传输功能由一个控制协议(RTCP)来扩展,通过扩展,可以用一种方式对数据传输进行监测控制,该协议(RTCP)可以升级到大型的多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。
旧版的RFC1889在线路里传输的数据包格式没有改变,唯一的改变是使用协议的规则和控制算法。为了最小化传输,发送RTCP数据包时超过了设定的速率,而在这时,很多的参与者同时加入了一个会话,在这样的情况下,一个新加入到(用于计算的可升级的)计时器算法中的元素是最大的改变 [1]

协议格式

播报
编辑
图1 RTP协议格式
RTP协议的报文格式如图1 [2]
前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表。这些域有以下意义 [1]
  • 版本(V):2比特此域定义了RTP的版本。此协议定义的版本是2。(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中。)
  • 填充(P):1比特若填料比特被设置,则此包包含一到多个附加在末端的填充比特,填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法,或者用于在底层数据单元中传输多个RTP包。
  • 扩展(X):1比特若设置扩展比特,固定头(仅)后面跟随一个头扩展。
  • CSRC计数(CC):4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目。
  • 标志(M):1比特标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件,如帧边界。
  • 负载类型(PT):7比特此域定义了负载的格式,由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发送端在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流。
  • 序列号(sequence number):16比特每发送一个RTP数据包,序列号加1,接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难。
  • 时间戳(timestamp) 32比特时间戳反映了RTP数据包中第一个字节的采样时间。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。也可以通过RTP方法对负载格式动态描述。如果RTP包是周期性产生的,那么将使用由采样时钟决定的名义上的采样时刻,而不是读取系统时间。例如,对一个固定速率的音频,采样时钟将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块,那么对每个块,时间戳的值增加160。时间戳的初始值应当是随机的,就像序号一样。几个连续的RTP包如果是同时产生的。如:属于同一个视频帧的RTP包,将有相同的序列号。不同媒体流的RTP时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此,虽然这些时间戳足以重构一个单独的流的时间,但直接比较不同的媒体流的时间戳不能进行同步。对于每一个媒体,我们把与采样时刻相关联的RTP时间戳与来自于参考时钟上的时间戳(NTP)相关联。因此参考时钟的时间戳就了数据的采样时间。(即:RTP时间戳可用来实现不同媒体流的同步,NTP时间戳解决了RTP时间戳有随机偏移量的问题。)参考时钟用于同步所有媒体的共同时间。这一时间戳对(RTP时间戳和NTP时间戳),用于判断RTP时间戳和NTP时间戳的对应关系,以进行媒体流的同步。它们不是在每一个数据包中都被发送,而在发送速率更低的RTCP的SR(发送者报告)中。如果传输的数据是存贮好的,而不是实时采样等到的,那么会使用从参考时钟得到的虚的表示时间线(virtual presentation timeline)。以确定存贮数据中的每个媒体下一帧或下一个单元应该呈现的时间。此种情况下RTP时间戳反映了每一个单元应当回放的时间。真正的回放将由接收者决定。
  • SSRC:32比特用以识别同步源。标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源。
  • CSRC列表:0到15项,每项32比特 CSRC列表识别在此包中负载的所有贡献源。识别符的数目在CC域中给定。若有贡献源多于15个,仅识别15个。CSRC识别符由混合器插入,并列出所有贡献源的SSRC识别符。例如语音包,混合产生新包的所有源的SSRC标识符都被列出,以在接收端处正确指示参与者。

RTP工作机制

播报
编辑
当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 RTP的发送过程如下,接收过程则相反 [1]
1) RTP协议从上层接收流媒体信息码流(如H.263),封装成RTP数据包;RTCP从上层接收控制信息,封装成RTCP控制包。
2)RTP将RTP数据包发往UDP端口对中偶数端口;RTCP将RTCP控制包发往UDP端口对中的接收端口。

协议特点

播报
编辑
RTP以一个控制协议(RTCP)结合它的数据传送,使监测大型的多点网络数据递送成为可能。 监测允许接收器发现是否有任何的信息包丢失和为任何的延迟跳动补偿。两个协议独立地在底部传送层和网络层协议工作。RTP 报头的信息告诉接收器该如何重建数据而且描述 codec比特流是如何被打包的。通常,RTP在用户数据包协议(UDP)的顶端运行,虽然它能使用其他的传送协议。会议开始协议(SIP)和 H.323 都使用 RTP [3]
协议包括如下几个特点 [2]

协议简单灵活

RTP协议相对来说比较简单,比如说它的报头固定部分只包含12字节(Byte),所以开销很小,有利于提高传输效率。灵活性体现在把协议机制和控制策略的具体算法分开。协议本身只提供完成实时传输的机制,对控制策略的有效算法实现不做具体规定。开发者可以根据不同的应用环境,选择实现效率较高的算法和合适的控制策略。

协议独立性

RTP最初设计的目的是Internet,但它更倾向于发展成为独立于底层协议的传输协议。RTP一般建立在UDP协议之上,充分利用了UDP协议的的多路复用服务,它也可以建立在其他协议之上,像ATM、IPV6,、AAL5等,所以RTP协议具有很好的独立性。

同步机制

RTP协议采用时间戳(Timestamp)来控制单一媒体数据流的同步,但它本身并不能控制不同媒体数据流间的同步。如要实现不同数据流之间的同步,必须由应用程序参与完成。

不可靠性

由于RTP协议设计的目的是传输实时数据,而不是可靠的数据,因此它不能提供有关错误检测和报文顺序检测的机制。

协议组成

播报
编辑
RTP组成包括:一个序列数字,用来发现丢失的信息包;负载量确认, 描述特定的媒体编码以便如果它必须适应带宽的变化的时候,它能被改变;帧指示,为每个帧的开始和结束作标记;来源确认,识别帧的发送者;还有媒体本身同步,使用时间戳在单个流里面发现不同的延迟跳动并且为它补偿。
RTPC组成包括: 服务质量(QoS)反馈,包括丢失信息包的数量,来回旅程时间和跳动,所以来源能适当地调整他们的数据速率;会议控制,使用 RTCP BYE(再见)信息包允许叁加者显示他们正在离开会议;确认,为其他参加者提供信息包括参加者的名字,电子邮件账号和电话号码;还有媒介物同步,使分离的声音和视频流能够同步。

协议用途

播报
编辑
在RFC 2509中被指定的被压缩的 RTPCRTP),被发展用来减少 IPUDPRTP 报头的大小。 然而,它被设计成以可靠和快速的点对点链接工作。在不是最佳的环境中,可能有长的延迟,信息包丢失和无序信息包,CRTP 在 通过IP网络传送话音(VoIP)应用上表现不佳。另外的一个改进,增强 CRPT(ECRPT),被定义在一个后来的英特网草案中以克服这个问题。
协议主要使用在如下几个场景 [1]

简单多播音频会议

IETF的一个工作组开会讨论最新协议草案时,使用Internet的IP多播服务来进行语音通讯。工作组中心分配到一个多播的组地址和一对端口。一个端口用于音频数据,另一个端口用于控制(RTCP)数据包。该地址和端口信息发布给预定的参与者。如果有私密性要求,对数据和控制包进行加密,这时就需要生成和发布加密密钥。分配和发布机制的精确细节不在RTP的讨论范围之内。
每个与会者所使用的音频会议应用程序,都以小块形式(比方说持续20秒时间)来发送音频数据。每个音频数据块都前导RTP报头;RTP报头和数据依次包含在UDP包里。RTP报头指明了各个包里音频编码的类型(如PCM,ADPCM,LPC),这样发送方可以在会议过程中改变编码方式,以适应状况的变化,例如,要加进一个低带宽接入的参与者,或是要应付网络拥塞。
Internet,像其他的报文分组网络一样,偶而会丢失和重排包,造成时长不等的延迟。为弥补这个不足,RTP报头里包含计时信息和一个序列号,允许接收方重建来自源的计时信息,比如前文例子中音频块以20s的间隔在扬声器中连续播放。会议中,对每个RTP包的源,单独地实施计时重建。序列号还被接收方用来评估丢失包数目。
由于会议期间不断有工作组成员加入或离开,因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。出于这个目的,会议中每个音频应用程序的实例,都在RTCP(控制)端口上周期性地多播一个附加用户名的接收报告。接收报告指明了当前说话者被收听到的状况,可用于控制自适应性编码。除了用户名外,通过控制带宽限度,可以包含其他标识信息。一个站点在离开会议时发送RTCP BYE包 [1]

音频和视频会议

一个会议如果同时使用音频和视频媒体,则二者传输时使用不同的RTP会话。也就是说,两种媒体中RTP包和RTCP包的传输,是使用两个不同的UDP端口对和(或)多播地址。在RTP层次,音频和视频会话没有直接的耦合,下面这种情况除外:一个同时参加两个会话的参与者,在两个会话的RTCP包中,使用了相同的规范名,这样两个会话就发生关联(耦合)了。这样区隔开来的目的之一,是允许一些会议参与者只接受自己选择的单一媒体(或者音频,或者视频)。尽管两种媒体区分开来了,但通过两个会话RTCP包内载有的计时信息,同源的音频与视频还是能够同步回放 [1]

混频器和转换器

到目前为止,我们皆假设所有站点都收到相同格式的媒体数据。然而这并不总是行得通。考虑一下这种情况,一个地方的参与者只能低速接入会议,而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽,不如在只能低速接入的地方,放置一个减质量音频编码的RTP层次的中继(称作混频器)。混频器将重新同步输入的音频包,重建发送方产生的20ms固定间隔,混频已重建过的音频流为单一的流,转换音频编码为低带宽格式,最后通过低带宽连接转发数据包流(package stream)。这些包可能被单播到一个接收方,也可能多播到另一个的地址而发给多个接收方。RTP报头为混频器提供了一种方法,使其能辨识出对混频后的包有用的源,从而保证提供给接收方正确的说话者指示。
在音频会议中,一些预定参与者尽管有高带宽连接,但不能通过IP多播直接接入会议。例如,他们可能位于一个不允许任何IP包通过的应用层防火墙后面。对这些站点,可能就不需要混频,而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器,外侧转换器将所有多播包通过安全连接转入内侧转换器,内侧转换器再转发给内部网的一个多播组(multicast group)。
混频器和转换器可以设计成用于各种目的。比如,一个视频混频器在测量多个不同视频流中各人的单独影像后,将它们组合成一个单一视频流来模拟群组场景。又如,在只用IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如,在没有重新同步或混频时,用packet-by-packet编码转换来自各个独立源的视频流 [1]

分层编码

为了匹配接收方的能力(容量)以及适应网络拥塞,多媒体应用程序应当能够调整其传输速率。许多应用实现把调适传输速率的责任放在源端。这种做法在多播传输中并不好,因为不同接收方对带宽存在着冲突性需求。这经常导致最小公分母的场景,网格中最小的管道支配了全部实况多媒体“广播”的质量和保真度。
相反地,可以把分层编码和分层传输系统组合起来,从而把调适速率的责任放在接收端。在IP多播之上的RTP上下文中,对一个横跨多个RTP会话(每个会话在独自多播组上开展)的分级表示信号(hierarchically represented signal),源能够把它的分层(layers)分割成条。 接收方仅需合并适当的多播组子集,就能适应异种网络和控制接收带宽 [1]