摘要
本文描述RTP(real-time transport protocol),实时传输协议。RTP在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传输功能由一个控制协议(RTCP)来扩展,通过扩展,可以用一种方式对数据传输进行监测控制,该协议(RTCP)可以升级到大型的多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。
本文的大多数内容和旧版的RFC1889相同。The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.
本文详细的介绍实时传输协议RTP,RTP提供带有实时特性的端对端数据传输服务,传输的数据如:交互式的音频和视频。服务包括payload type identification,序列号,时间戳和delivery monitoring。应用程序在UDP上运行RTP来使用它的multiplexing和checksum服务。两种协议都提供传输协议的部分功能。不过,RTP可能被其他适当的下层网络和传输协议使用(见11节)。如果下层网络支持,RTP支持数据使用多播分发机制转发到多个目的地。
注意RTP本身没有提供任何的机制来确保实时的传输或其他的服务质量保证,而是由低层的服务来完成。它不保证传输或防止乱序传输,它不假定下层网络是否可靠,是否按顺序传送数据包。RTP包含的序列号允许接受方重构发送方的数据包顺序,但序列号也用来确定一个数据包的正确位置,例如,在视频解码的时候不用按顺序的对数据包进行解码。
但是RTP原先的设计是用来满足多参与者的多媒体会议的需要,它没有限定于专门的应用。RTP可能也同样适用于:Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications。
该文档定义RTP,由两个密切联系的部分组成:
因此,除了本文档,用于特定应用的完整RTP规格还需要一个或者更多的辅助文档(见13节):
在这个文档里的关键词“一定要”,“一定不能”,“必需的”,“会”,“不会”,“应该”,“不应该”,“推荐”,“可能”和“可选” 将会像在BCP 14(Basic Control Program,基本控制程序),RFC2119[2]里描述一样的解释。并指出适合RTP实现的需要的级别。
以下章节描述了用到RTP的一些方面。所举例子用来说明RTP应用的基本操作,但RTP的用途不限于此。在这些例子中,RTP运行于IP和UDP之上,并且遵循RFC3551所描述的音频和视频的配置文件中的约定。
IETF的一个工作组开会讨论最新协议草案时,使用Internet的IP多播服务来进行语音通讯。通过一些分配机制,工作组主持人获得一个多播的组地址和一对端口。一个端口用于音频数据,另一个端口用于控制(RTCP)数据包。该地址和端口信息发布给预定的参与者。如果有私密性要求,则可用章节9.1中说明的方法,对数据和控制包进行加密;这时就需要生成和发布加密密钥。分配和发布机制的详细细节不在RTP的讨论范围之内。
每个与会者所使用的音频会议应用程序,都以small chunk形式(比方说20毫秒一段)来发送音频数据。每个音频数据块都前缀RTP报头;RTP报头和数据然后包含在UDP包中。RTP报头指明了各个包里音频编码的类型(如PCM, ADPCM,LPC),这样发送方可以在会议过程中改变编码格式,例如,为了要适应一个低带宽的参与者,或是要应付网络拥塞。
Internet,像其他的packet network,偶而会丢失和重排包或造成时长不等的延迟。为应付这种损伤,RTP报头里包含时间戳和序列号,这样就允许接收方重构 源的时间轴。 This timing reconstruction is performed separately for each source of RTP packets in the conference. 序列号还被接收方用来评估包丢失的数目。
由于会议期间不断有工作组成员加入或离开,因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。出于这个目的,会议中每个音频应用程序,都周期性地多播一个附加着用户名的接收报告到RTCP端口。接收报告指明了当前说话者被收听到的状况,可用于控制自适应性的编码。除了用户名外,可以包含其他标识信息,只要符合控制带宽限制。一个参与者在离开会议时发送RTCP BYE包(章节6.5)。
一个会议如果同时使用音频和视频媒体,则二者传输时使用不同的RTP会话。也就是说,两种媒体中RTP包和RTCP包的传输,是使用两个不同的UDP端口对和(或)多播地址。在RTP层次,音频和视频会话没有直接的耦合;一个同时参加两个会话的参与者,在两个会话的RTCP包中,SHOULD 使用相同的规范名,这样两个会话就发生关联(耦合)了。
这样分割的其中一个目的是允许一些会议参与者只接受自己选择的某一个媒体(或者音频,或者视频)。更进一步的说明在章节5.2给出。尽管两种媒体区分开来了,但通过两个会话RTCP包内载有的计时信息,同源的音频与视频还是能够同步回放。
到目前为止,我们皆假设所有站点都收到相同格式的媒体数据。然而这并不总是行得通。考虑一下这种情况,一个地方的参与者只能低速接入会议,而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽,不如在只能低速接入的地方,放置一个减质量音频编码的RTP层次的中继(称作混频器)。混频器将重新同步输入的音频包,重建发送方产生的20ms固定间隔,混频已重建过的音频流为单一的流,转换音频编码为低带宽格式,最后通过低带宽连接转发数据包流(package stream)。这些包可能被单播到一个接收方,也可能多播到另一个的地址而发给多个接收方。RTP报头为混频器提供了一种方法,使其能辨识出对混频后的包有用的源,从而保证提供给接收方正确的说话者指示。
在音频会议中,一些预定参与者尽管有高带宽连接,但不能通过IP多播直接接入会议。例如,他们可能位于一个不允许任何IP包通过的应用层防火墙后面。对这些站点,可能就不需要混频,而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器,外侧转换器将所有多播包通过安全连接转入内侧转换器,内侧转换器再转发给内部网的一个多播组(multicast group)。
混频器和转换器可以设计成用于各种目的。比如,一个视频混频器在测量多个不同视频流中各人的单独影像后,将它们组合成一个单一视频流来模拟群组场景。又如,在只用IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如,在没有重新同步或混频时,用packet-by-packet编码转换来自各个独立源的视频流。混频器和转换器的操作细节见章节7。
为了匹配接收方的能力(容量)以及适应网络拥塞,多媒体应用程序应当能够调整其传输速率。许多应用实现把调适传输速率的责任放在源端。这种做法在多播传输中并不好,因为不同接收方对带宽存在着冲突性需求。这经常导致最小公分母的场景,网格中最小的管道支配了全部实况多媒体“广播”的质量和保真度。
相反地,可以把分层编码和分层传输系统组合起来,从而把调适速率的责任放在接收端。在IP多播之上的RTP上下文中,对一个横跨多个RTP会话(每个会话在独自多播组上开展)的分级表示信号(a hierarchically represented signal),源能够把它的分层(layers)分割成条。 接收方仅需合并适当的多播组子集,就能适应异种网络和控制接收带宽。
RTP分层编码的细节在章节6.3.9,8.3和11中给出。
RTP头有以下格式:
Real Time Transport Protocol 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 | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP包头格式
前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表。这些域有以下意义:
version (V):2 bits
此域定义了RTP的版本。此协议定义的版本是2。(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中。)
padding (P):1 bit
若设置了padding位,则该packet在尾端包含一到多个padding octets,padding octets 不算作负载的一部分。padding的最后一个字节指明可以忽略多少个 padding octets(包括它自己)。padding可能在某些要求固定块大小的加密算法中需要,或者用于在底层数据单元中传输多个RTP包。
extension (X):1 bits
若设置extension位,固定头后面MUST跟随一个(且仅一个)头扩展,头扩展的格式定义与Section 5.3.1。
CSRC count (CC):4 bits
CSRC计数包含了跟在固定头后面CSRC识别符的数目。
marker (M):1 bit
标志的解释由具体profile规定。它用来允许在比特流中标记重要的事件,如帧边界。
payload type (PT):7bits
此域定义了负载的格式,由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发送端在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流。
sequence number:16 bits
每发送一个RTP数据包,序列号加1,接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难。
timestamp: 32 bits
时间戳反映了RTP数据包中第一个字节的采样时间。(采样时钟必须来源于一个及时的单调、线性递增时钟,以便允许同步和去除网络引起的数据包抖动(见章节6.4.1)。该时钟的分辨率必须满足期望的同步精度和测量数据包到来时的抖动的需要(一种典型的时钟分辨率不满足情况是每个视频帧仅一个时钟周期)时钟频率依赖于负载数据的格式,并在描述文件(profile)中或者是在负载格式描述中(payload format specification)进行静态描述。也可以通过非RTP方法(non-RTP means)对负载格式动态描述。
如果RTP包是周期性产生的,那么将使用由采样时钟决定的名义上的采样时刻,而不是读取系统时间。例如,对一个固定速率的音频,采样时钟(时间戳时钟)将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块,那么对每个块,时间戳的值增加160,而不考虑该块是否用一个包传递或是被丢弃。
时间戳的初始值应当是随机的,就像序号一样。几个连续的RTP包如果(逻辑上)是同时产生的,如:属于同一个视频帧的RTP包,将有相同的时间戳。如果数据并不是以它采样的顺序进行传输,那么连续的RTP包可以包含不是单调递增(或递减)的时间戳(RTP包的序列号仍然是单调变化的)。
不同媒体流的RTP时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此,虽然这些时间戳足以重构一个单独的流的时序,但直接比较不同的媒体流的时间戳不能有效的进行同步。对于每一个媒体,我们把与采样时刻相关联的RTP时间戳与来自于参考时钟上的时间戳(NTP)相关联(相反,对于每一种媒体,RTP时间戳通过与一个参考时间戳wallclock配对的方法来与采样时刻联系起来。)。参考时钟的时间戳表示了(对应于RTP时间戳的)数据的采样时刻。(即:RTP时间戳可用来实现不同媒体流的同步,NTP时间戳解决了RTP时间戳有随机偏移量的问题。)参考时钟用于同步所有媒体的共同时间(参考时间戳为所有媒体所公用,以此来实现同步)。这一时间戳对(RTP时间戳和NTP时间戳),用于判断RTP时间戳和NTP时间戳的对应关系,以进行媒体流的同步。它们不是在每一个数据包中都被发送,而在发送速率更低的RTCP的SR(发送者报告)中。即RTP时间戳记录当前是第几个采样数据,NTP时间戳记录当前数据包相对于参考时钟(1900年1月1日0点算起,当前时间相对于该时刻所经过的秒数)的绝对时间。
选取采样时间作为RTP时间戳的参考点是因为它可以被传输的终节点获知,而且对所有媒体内容有一个相同的定义,再者是它不受编码延迟或其它数据处理的约束。目的是为了对所有在同一时刻采样的媒体进行同步。
如果传输的数据是存贮好的,而不是实时采样等到的,那么会使用从参考时钟得到的虚的表示时间线(virtual presentation timeline虚拟表示时间表)以确定存贮数据中的每个媒体下一帧或下一个单元应该呈现的时间(还是时刻???)。此种情况下RTP时间戳反映了每一个单元应当回放的时间(时刻???)。这就是说,每个单元的RTP时间戳将会和参考时钟相关。真正的回放将由接收者决定。
为事先录制的视频插播实时音频旁白的例子阐述了选择采样时刻作为参考点的重要性。在这种情况下,视频会在“本地”播放给解说员观看,同时会通过RTP向外界传输。RTP传输的一个视频帧的“采样时刻”将会被建立,建立的方法是将RTP包的时间戳与该视频帧播放给旁白者的时刻(参考时钟)相比较(即当前的采样序号结合绝对时间得出“采样时刻”)。包含有解说员解说的的音频RTP包,它的采样时刻将会在音频被采样的时刻,通过与同一参考时钟相比较而建立。音频和视频甚至可以被不同的主机传输只要这两个主机的参考时钟通过比如NTP之类的途径实现了同步。接受者能够使用RTCP SR包中的时间戳对从而将音频和视频同步。
SSRC:32 bits
用以识别同步源。标识符应该被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。一个用于创造随机标示符的示例算法在A.6第六章讲述。尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突。第8章讲述了冲突的可能性及其解决机制。若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源(see Section 8.2)。
CSRC列表:0到15项,每项32bits
CSRC列表指出了对此包中负载内容的所有贡献源。识别符的数目在CC域中给定。若有贡献源多于15个,仅识别15个。CSRC识别符由混合器插入(see Section 7.1),并列出所有贡献源的SSRC识别符。例如语音包,混合产生新包的所有源的SSRC标识符都被列出,以在接收端处正确指示参与者。
省略第一段
独立的音频和视频流不应该在一个RTP会话中传输然后根据负载的类型或SSRC来解除复用。包含不同RTP媒体类型的交错包,并且这些包使用同一SSRC将会引起下面一系列问题。
已经存在的RTP数据包包头被认为已经满足通常所有应用类型的需要。然而,为了符合ALF设计原则,该包头可以通过修改或作一些定义在特性说明中的增加的方法实现个性定制。同时,仍然允许与特性独立的显示和记录工具产生作用。
RTP提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP数据包头中传输。设计此扩展机制可以使其它没有扩展的交互忽略此头扩展。RTP头扩展的格式如下图所示。 注意特殊负载类型需要的附加信息不能使用这种头扩展,而是应该被存贮在数据包的负载部分中。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | .... |
若RTP头中的扩展比特位置1,则一个长度可变的头扩展部分被加到RTP固定头之后。头扩展包含16比特的长度域,指示扩展项中32比特字的个数,不包括4个字节扩展头(因此零是有效值)。RTP固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前16比特用以识别标识符或参数。这16比特的格式由具体实现的上层协议定义。基本的RTP说明并不定义任何头扩展本身。
RTP控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。底层协议必须提供数据包和控制包的复用,例如用不同的UDP端口。RTCP提供以下四个功能:
这部分定义了几个RTCP包类型,可以传送不同的控制信息:
SR: 发送者报告,描述当前发送者的的发送和接收统计;
RR:接收者报告,描述非当前发送者的接收统计;
SDES:源描述项,其中包括规范名(CNAME);
BYE:表明参与者将结束会话;
APP:应用特定功能。
每个RTCP包以与RTP数据包类似的固定头部起始,接着是根据RTCP包类型而可能长度不同的结构化元素,但是必须结尾于32位边界(即该RTCP包的总位数可以被32整除)。对齐要求和每个包固定头部中的长度域使RTCP包"可堆叠",即可以将多个RTCP包形成一个复合RTCP包,在底层协议(如UDP)中,通常都是将复合包作为一个包传输的。 在RTCP复合包中不明确指定有多少个RTCP包,而是依靠底层协议提供(该复合包的)总长度来决定该复合包的结束(UDP在头部包含一个field,指定其长度)。
复合包中的每个RTCP包可以单独处理,而无需考虑包复合的顺序。然而,为了实现RTCP协议的某些功能,添加以下限制:
加密前缀:当且仅当复合包被加密时,对每个RTCP复合包前缀一个32位随机数。如果加密需要padding,必须添加到复合包的最后一个封包中。
SR或RR:复合包中的第一个RTCP包必须是一个报告包,以利于附录A.2中描述的头部验证。即使还没有数据发送和接收,该限制也是适用的。此时必须发送一个空的RR包,同样必须在复合包中搭配一个其他的RTCP包,即使是BYE。
额外的RR:若被报告的接收统计源数目超过SR/RR包中最大允许的31个,附加的RR必须跟在最初的报告包后面。
SDES:除了9.1节描述的情况外,每个RTCP复合包都必须包含一个SDES包。
BYE或APP:其他RTCP包类型(非SR/RR/SDES packet),包括那些尚未定义的,可以遵循任何顺序,除了BYE必须是最后一个封包(每个BYE包都包含一个给定的SSRC/CSRC)。
每个RTP参与者在一个报告间隔内应只发送一个RTCP复合包,以便正确估计每个参与者的RTCP带宽。除非像9.1节描述的情况——把一个RTCP复合包分割以进行加密。如果数据源的个数太多,以至于不能把RR包都放到同一个RTCP复合包中而不超过路径MTU,那么可在每个间隔中发送RR包的子集。在多个发送间隔中,所有的RR包应该被等概率的选中,这样就可以报告所有数据源的接收数据的情况。
为了分摊the packet overhead,推荐Translators and Mixers在可行的时候,把来自多个source的各自的RTCP packet综合到一个复合包。如果一个RTCP复合包的长度超过了路径MTU,则它应当被分割为多个更短的复合包来传输(以什么规则segment?)。这不会影响对RTCP带宽的估计,因为每一个复合包至少代表了一个参与者。要注意的是每个RTCP复合包必须以SR或RR包开头。
应该忽略那些未知类型的输入RTCP包。
if encrypted: random 32-bit integer | |[--------- packet --------][---------- packet ----------][-packet-] | | receiver chunk chunk V reports item item item item -------------------------------------------------------------------- R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why] -------------------------------------------------------------------- | | |<----------------------- compound packet ----------------------->| |<-------------------------- UDP packet ------------------------->| #: SSRC/CSRC identifier Figure 1: Example of an RTCP compound packet
RTP被设计为自动适应不同的规模的会话――从几个参与者到几千个参与者的会话。例如,在一个音频会议中,data traffic is inherently self-limiting,因为同时只会有一个或两个人说话;因此在组播分发的情况下,任何link上的data rate都保持相对固定,不管有多少个参与者。尽管如此,control traffic却不是self-limiting。If the reception reports from each participant were sent at a constant rate, the control tra c would grow linearly with the number of participants. Therefore, the rate must be scaled down by dynamically calculating the interval between RTCP packet transmissions.
对每一个会话,我们假定数据传输受到一个上限――会话带宽的限制。会话带宽分配给所有的参与者。这个带宽会被预留,并由网络所限制。如果没有预留,基于环境的其他约束将会确定合理的最大带宽供会话使用,这就是会话带宽。会话带宽在一定程度上独立于媒体编码,但媒体编码却依赖于会话带宽。
在涉及媒体应用时,会话带宽参数最好由一个会话控制应用提供。但媒体应用可能设置一个默认参数。此参数由单个发送者选择的编码方式的数据带宽算出。会话管理可能会基于多播范围的规则或其他标准确定带宽限制。所有的参与者应使用相同的会话带宽值以保证计算出相同的RTCP间隔。
控制传输带宽应当是会话带宽的一小部分,这部分所占总的会话带宽的百分比应是已知的。一小部分:传输协议的首要功能是传输数据;已知:控制传输带宽可以被放进带宽描述中提供给资源预留协议,并且使每个参与者都可以独立的计算出他所占有的带宽份额。
控制传输带宽作为额外的一部分加入到会话带宽中。建议RTCP控制传输带宽为RTCP会话带宽的5%。其中的1/4分配给发送者;当发送者的比例超过所有参与者的1/4时,其RTCP控制带宽相应增加。所有的会话参与者必须使用相同的常数(以上提到的百分比),以便计算出相同的发送时间间隔。这些常数应在一个特殊的描述文件中确定。
计算出的RTCP复合包的发送时间间隔应该有一个下限,以免参与者数量较少时大量发送RTCP包。这也使网络暂时断开时,发送间隔不会太小。在应用开始时,一个延迟应加到第一个的TCP复合包发送之前,以便从其他参与者接收RTCP复合包。这样,发送时间间隔能更快的收敛到正确的值。这个延迟可以设为最小时间间隔的一半。固定的时间间隔建议为5秒。
一个实现可能使RTCP最小发送时间间隔与会话带宽参数成比例。则应满足下列约束:
当侦听到新的站点的时候,应当把他们加入计数。每一个登录都应在表中创建一条记录,并以SSRC或CSRC进行索引。新的登录直到接收到含有SSRC的包或含有与此SSRC相联系的规范名的SDES包才视为有效(见附录A.1)。当一个与SSRC标识符相对RTCP BYE包收到时,登录会被从表中删除。除非一个“掉队”的数据包到达,使登录重新创建。
如果在几个RTCP报告时间间隔内没有RTP或RTCP包收到,一个参与者可能标记另外一个站点静止,并删除它。这是针对丢包提供的一个很强健的机制。所有站点对这个超时时间间隔乘子应大体相同,以使这种超时机制正常工作。因此这个乘子应在特别的描述文件中确定。
对于一个有大量参与者的会话,维持并存贮一个有所有参与者的SSRC及各项信息的表几乎是不可能的因此,只可以只存贮SSRC。其他算法类似。关键的问题就是,任何算法都不应当低估组的规模,虽然它有可能被高估。
下面列出了如何发送RTCP包,当接收到的TCP包时该干什么的规则。
为执行规则,一个会话参与者就维持下列变量:
tp: RTCP包发送的最后时间。
tc: 当前时间。
tn: 估计的下一个RTCP包要发送的时间。
pmembers: tn最后被重新计算时,会计的会话成员的人数。
members: 会话成员人数的当前估计。
senders: 会话成员中发送者人数的估计。
rtcp_bw: 目标RTCP带宽。例如用于会话中所有成员的RTCP带宽。单位bit/s。这将是程序开始时,指定给“会话带宽”参数的一部分。
we_sent: 自当前第二个前面的RTCP发送后,应用程序又发送了数据,则此项为true。
avg_rtcp_size: 此参与者收到的和发送的RTCP复合包的平均大小。单位:bit。按6.2节,此大小包括底层传输层和网络层协议头。
initial: 如果应用程序还未发送RTCP包,则标记为true。
许多规则都用到了RTCP包传输的“计算时间间隔”。此时间间隔将在随后的小节描述。
一个会话参与者包的平均发送时间间隔应当和所在会话组中人数成正比。这个间隔称为计算时间间隔。它由上面提到的各个状态参量结合起来计算得出。计算时间间隔T的计算如下:
1.(1)如果发送者人数≤会话总人数×25%。则T取决于此参与者是否是发送者(we_sent的值);否则,发送者和接收者将统一处理。
如6.2节所述,RTP描述文件可能用两个独立的参数(S,R)确定发送者与非发送者。此时,25%和75%只要相应的换成S/(S+R),R/(S+R)即可。注意R=0的情况。
2.如果initial为true(则未发送过RTCP包),则设Tmin=2.5s;否则设Tmin=5s。
3.决定性的计算时间间隔(deterministic calculated interval)Td=max(Tmin ,n*c)。
4. T=Td*λ;其中λ~U(0.5,1.5)。即λ服从0.5到1.5之间的均匀分布。
5. T=T/(e-0.5)≈T/1.21828,补偿时间重估算法,使之收敛到比计算出的平均RTCP带宽小的一个值。
这个算法产生了一个随机的计算时间间隔,并把至少25%的RTCP带宽分配给发送者,其余的分给接收者。若发送者超过会话总人数的25%,此算法将把带宽平均分给所有的参与者。
一加入会话,参与者的各状态参量初始化为:tp=0; tc=0; senders=0; pmembers=1; members=1; vw_sent=false; rtcp_bw:由会话带宽参数的相应部分得到;initial=true;avg_rtcp_size:初始化为应用程序稍后将发送的RTCP包的可能大小;T:如6.3.1节;tn=T(这意味着,一个计时器将经T时间后被唤醒);应用程序可以用任何它需要的方式实现计时器。
参与者把它自己的SSRC加到成员列表中。
当收到一个参与者的RTP或RTCP包时,若其SSRC不在成员列表中,将其SSRC加入列表;若此参与者被确认有效(如6.2.1节描述),就把列表中成员的值更新。对每个有效的RTP包中的CSRC执行相同的过程。
当收到一个参与者的RTP包时,若其SSRC不在发送者列表中,则将其SSRC加入发送者列表,更新相应的值。
每收到一个RTCP复合包,avg_rtcp_size更新为avg_rtcp_size = 1/16 * packet_size + 15/16 * avg_rtcp_size ;其中packet_size是刚收到的RTCP复合包的大小。
除6.3.7小节描述的发送RTCP BYE包之外,如果收到一个RTCP BYE包,则检测成员列表。若SSRC存在;先移除之,并更新成员的值。
另外,为使RTCP包的发送速率与组中人数变化更加协调,当收到一个BYE包使得members的值pmembers时,下面的逆向重估算法应当执行:
(1)tn的更新:tn = tc + ( members / pmembers ) * ( tn –tc );
(2)tp的更新:tp = tc – ( members / pmembers ) * ( tc – tp );下一个RTCP包将在时刻tn 被发送,比更新前更早一些。
(3)pmembers的更新:pmembers=members;
这个算法并没有防止组的大小被错误的在短时间内估计为0的情况。如:在一个较多人数的会话中,多数参与者几乎同时离开而少数几个参与者没有离开的情况。这个算法并没有使估计迅速返回正确的值。因为这种情况较罕见,且影响不大。
在随机的时间间隔中,一个参与者必须检测其他参与者是否已经超时。为此,对接收者(we_sent为false),要计算决定性时间间隔Td,如果从时刻Tc-M*Td(M为超时因子,默认为5秒)开始,未发送过RTP或RTCP包,则超时。其SSRC将被从列表中移除,成员被更新。在发送者列表中也要进行类似的检测。发送者列表中,任何从时间tc-2T(在最后两个RTCP报告时间间隔内)未发送RTP包的发送者,其SSRC从发送者列表中移除,列表更新。
如果有成员超时,应该执行6.3.4节中的逆向检测算法。每个参与者在一个RTCP包发送时间间隔内至少要进行一次这样的检测。
当包传输的发送时钟到时,参与者执行下列操作:
(1)按6.3.1节的办法计算T。
(2)更新发送时钟的定时时间,判断是否发送RTCP包,更新pmembers。如图:
当一个参与者离开会话时,应发送BYE包,通知其他参与者。为避免大量参与者同时离开系统时,大量BYE包的发送,若会话人数超过50,则参与者在要离开会话时,应执行下面的算法。这个算法实际上“篡夺”了一般可变成员的角色来统计BYE包。
(1)tp=tc ; members=1; pmembers=1; sinitial=1; we_sent=false; senders=0; rtcp_size:设置为将要发送的RTCP包大小;计算“计算时间间隔”T;tn=tc+T;(BYE包预计在时刻tn被发送)。
(2)每当从另外一个参与者接收到BYE包时,成员人数加1。不管此成员是否存在于成员列表中,也不管SSRC采样何时使用及BYE包的SSRC是否包含在采样之中。如果收到RTP包或甚的RTCP包(除BYE包之外的RTCP包),成员人数不增加。类似,只有在收到BYE包时,avg_rtcp_size才更新。当RTP包到达时,发送者人数senders不更新,保持为0。
(3)在此基础上,BYE包的传输服从上面规定的一般的RTCP包的传输。
(BYE包的传输,是专注于统计会话中发送BYE包的人数的。)
这允许BYE包被立即发送,并控制总的带宽使用。在最坏情况下上,这可能会使RTCP控制包使用两倍于正常水平的带宽,达到10%――其中5%给BYE包的RTCP包,其余5%给BYE包。
一个参与者若不想用上面的机制进行RTCP包的发送,可以直接离开会话,而根本不发送BYE包。他会被其他参与者因超时而删除。
一个参与者想离开会话时,如果组中的人数会计数目小于50,则参与者可以直接发送BYE包。
另外,一个从未发送过RTP或RTCP包的参与者,在离开会话时,不能发送BYE包。
如果一个参与者最近发过RTP包,则变量we_sent值为true,否则为false。相同的机制可以管理发送者中的其他参与者。如果参与者发送了TPT包而此时,其对应的we_sent变量值为false,则就把它自己加到发送者列表中,并设置其we_sent变量为true。6.3.4节中描述的逆向重估算法(reverse reconsideration algorithm)应当被执行。以可能减少发送SR包前的延迟。每次发送一个RTP包,其相应的传输时间都会记录在表中。一般发送者的超时算法应用到参与者自身:从tc-2T时开始,一直没有发送RTP包,则此参与者就从发送者列表中将其自身移除,减少发送者总数,并设置we_sent变量值为false。
这里定义了几种源描述项,强制性的规范名(CNAME)除外。例如,个人姓名(NAME)和电子邮件地址(EMAIL)。它也提供了方法定义新的RTCP包的类型。应用程序在给这些额外信息分配带宽时应额外小心。因为这会降低接收报告及CNAME的发送速率,可能破坏协议发挥作用。建议分配给一个参与者用于传输这些额外信息的带宽不超过总的RTCP带宽的20%。另外,并非所有的源描述项都将包含进每一个应用程序中。包含进应用程序的源描述项应根据其用途分配给相应的带宽百分比。建议不要动态会计这些百分比,而应根据一个源描述项的典型长度将所占带宽的百分比的转化为报告间隔。
例如,一个应用程序可能仅发送CNAME,NAME和EMAIL,而不需要其他项。NAME可能会比EMAIL给予更高的优先级。因为NAME可能会在应用程序的用户界面上持续显示,但EMAIL可能仅仅在需要时才会显示。在每一个RTCP时间间隔内,一个包含CNAME项的SDES包和一个RR包将会被发送。最小的会话时间间隔平均为5秒。每经过3个时间间隔(15秒),一个额外的项将会包含进这个SDES包中。7/8的时间是NAME项,每经过8个这样的间隔(15s*8=2min),将会是EMAIL项。
当多个会话考虑使用一个通用的规范名为每个参与者进行绑定时,如在一个RTP会话组成的多媒体会议中,额外的SDES信息可能只在一次RTP会话中被发送。其余的会话将只发送CNAME。特别,这个办法也应该用在分层编码的多个会话中。
RTP接收者利用RTCP报告包提供接收质量反馈。根据接收者是否同时还是发送者,RTCP包采取两种不同的形式。发送者报告(SR)和接收者报告(RR)格式中唯一的不同,除包类型码之外,在于发送者报告包括20字节的发送者信息。
SR包和RR包都包括零到多个接收报告块。针对该接收者发出上一个报告块后接收到RTP包的起始同步源,每个源一个块。报告不发送给CSRC列表中的贡献源。每个接收报告块提供从特定数据源接收到数据的统计信息。由于SR/RR包最多允许31个接收报告块,故可以在最初的SR或RR包之后附加RR包,以包含从上一个报告以来的间隔内收听到的所有源的接收报告。如果数据源太多,致使若把所有的RR包放到同一个RTCP复合包中会超出网络的MTU。那么就在一个周期内选择上面RR包的一部分以不超过MTU。这些RR包的选取应让各个包都有同等的几率被取到。这样在几个发送周期间隔中,对所有的数据源就都发送接收报告了。
以下部分定义了两种报告的格式。如果应用程序需要其他信息,他们可以被扩展。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ sender | NTP timestamp, most significant word | info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
发送者报告包由3部分组成,若定义,可能跟随第4个面向协议的扩展部分。
第一部分,头部,8字节长。该域有以下意义:
第二部分,发送者信息,20字节长。在每个发送者报告包中出现。它概括了从此发送者发出的数据传输情况。此域有以下意义:
第三部分:零到多个接收报告块。块数等于从上一个报告以来该发送者侦听到的其它源(不包括自身)的数目。每个接收报告块传输从某个同步源来的数据包的接收统计信息。若数据源因冲突而改变其SSRC标识符,接收者重新设置统计信息。这些统计信息有:
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算。利用该包和前一包i-1的偏差D(按到达顺序,而非序号顺序),根据公式
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16计算。无论何时发送接收报告,都用当前的J值。
此处描述的抖动计算允许与协议独立的监视器对来自不同实现的报告进行有效的解释。.
假设SSRC_r为发出此接收报告块的接收者。源SSRC_n可以通过记录收到此接收报告块的时刻A来计算到SSRC_r的环路传输时延。可以利用最新的SR时间标志(LSR)计算整个环路时间A-LSR,然后减去此DLSR域得到环路传输的时延。
如下图所示
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC] n SR(n) A=b710:8000 (46864.500 s) ----------------------------------------------------------------> v ^ ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s) ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s) (3024992005.125 s) v ^ r v ^ RR(n) ----------------------------------------------------------------> |<-DLSR->| (5.250 s) A 0xb710:8000 (46864.500 s) DLSR -0x0005:4000 ( 5.250 s) LSR -0xb705:2000 (46853.125 s) ------------------------------- delay 0x0006:2000 ( 6.125 s) Figure 2: Example for round-trip time computation
可以用此来近似测量到一组接收者的距离,尽管有些连接可能有非常不对称的时延。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
接收者报告包(RR)与发送者报告包基本相同,除了包类型域包含常数201和没有发送者信息的5个字(NTP和RTP时间标志和发送者包和字节计数)。余下区域与SR包意义相同。若没有发送和接收据报告,在RTCP复合包头部加入空的RR包(RC=0)。
扩展部分是发送报告包和接收报告包的第四部分。如果有的话,应紧跟在接收报告块的后面。如果需要更多的发送者信息,它应当跟在发送者报告的开关,而不应在报告中出现。如果要包含进接收者的信息,它应该以块数组的方式放到接收报告块的后面。即这些块也应被计入RC字段中。
接收质量反馈不仅对发送者有用,而且对于其它接收者和第三方监视器也有作用。发送者可以基于反馈修正发送信息量;接收者可以判断问题是本地的,区域内的还是全局的;网络管理者可以利用与协议无关的监视器(只接收RTCP包而不接收相应的RTP包)去评估多点传送网络的性能。
在发送者信息和接收者报告块中都连续统计丢包数,因此可以计算任何两个报告块中的差别。在短时间和长时间内都可以进行测算。最近收到的两个包之间差值可以评估当前传输质量。包中有NTP时间戳,可以用两个报告间隔的差值计算传输速率。由于此时间间隔与数据编码速率独立,因此可以实现与编码及协议独立的质量监视。
一个例子是计算两个报告间隔时间内的丢包率。丢包率=此间隔内丢失的包/此间隔内期望收到的包。如果此值与“丢失比例”字段中的值相同,说明包是连续的;若否,说明包不是连续的。间隔时间内的丢包率/间隔时间=每秒的丢包率。
从发送者信息中,第三方监视器可以在一个时间间隔内计算平均负载数据发送速率和平均发包速率,而无需考虑数据接收。两个值的比就是平均负载大小(平均每个包的负载大小)。(即:平均负载大小=平均负载数据发送速率/平均发包率。)若能假定丢包与包的大小无关,那么某个特定接收者收到的包数乘以平均负载大小(或相应的包大小)就得出接收者可得到的外在吞吐量。
除了累计计数允许利用报告间差值进行长期包损测量外,单个报告的“丢包比例”字段提供一个短时测量数据。当会话规模增加到无法为所有接收者保存接收状态信息,或者报告间隔变得足够长以至于从一个特定接收者只能收到一个报告时,短时测量数据变得更重要。
到达间隔抖动字段提供另一个有关网络阻塞的短时测量量。丢包反映了长期阻塞,抖动测量反映出短时间的阻塞。抖动测量可以在导致丢包前预示阻塞。由于到达间隔抖动字段仅仅是发送报告时刻抖动的一个快照,因此需要在一个网络内在一段时间内分析来自某个接收者的报告,或者分析来自多个接收者的报告。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| SC | PT=SDES=202 | length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_1 | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_2 | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
BYE包表明一个或多个源将要离开。如果混合器收到BYE包,混合器应当发送这个BYE包,并保持SSRC/CSRC不变。如果混合器关闭,应向贡献源列表中的所有SSRC,包括它自己的SSRC发送BYE包。BYE包可能会有选择的包含8个字节的统计字段,其后跟上几个字节的文本表明离开的原因。文本字符串编码格式和SDES中描述的相同。
UDP packet UDP packet ----------------------------- ------------------------------ [random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2] ----------------------------- ------------------------------ encrypted not encrypted #: SSRC identifier Figure 4: Encrypted and non-encrypted RTCP packets
接收者加密的使用和正确密钥的使用通过头或负载的有效性检查进行确认。RTP和RTCP头的有效性检查由附录A.1和A.2给出。
为和RFC1889中RTP初始描述中的实现相一致。默认的算法是链式加密块模式(cipher block chaining (CBC) mode)下的数据加密算法,见RFC1423中1.1节的描述。除非出现由5.1节描述指明的填充多个字节的情况,否则,初始的随机向量是0,因为随机值由RTP头或RTCP复合包的随机前缀提供。CBC初始向量的细节见参考文献[30]。支持本节的加密算法的实现也应当支持CBC下的DES算法。因为此算法可实现最大程度的交互可操作性。采用这种方法的原因是,因特网上通过音频、视频工具做实验证明它简便且有效。但DES被发现很容易被破解。建议用更强健的加密算法,例如三层DES加密算法来代替默认的加密算法。另外,安全CBC模式要求每个包的第一个块和一个随机数求异或。对于RTCP,这通过在每个包前附加一个32位的随机数实现。每个包的随机数相互独立。对RTP,时间戳和序列号将从附加的数值开始,但对连续的包,它们并不是被独立的随机化的。应该注意到对RTP和RTCP,这种随机性都受到了限制。高安全性的应用应当考虑其他更加简捷安全的方法。其他加密算法应通过非RTP方法对一个会话动态指定。特别是基于AES的SRTP描述文件(见参考文献[23])将会是未来的一个不错的选择。以上描述了IP层或RTP层加密。作为它的替代,描述文件可以定义另外的负载类型以用于加密、编码。这些编码必须描述如何填充,以及编码的其他方面如何控制。这种方法可以按照应用的要求,只加密数据,不加密头部。这可能对同时处理解密和解码的硬件服务特别重要。这也可能对RTP和底层头部的链路层的应用很有用。既然头部的加密已经进行了压缩,负载(而不是地址)的保密性就足够了。
因特网上的所有传输协议都必须在一些方面涉及拥塞控制(见参考文献[31]),RTP也不例外。但由于RTP传输的数据通常缺少弹性(以固定的或控制好的速率产生包)。因此,RTP拥塞控制的方法和其他传输协议(如TCP)很不相同。某种意义上,缺乏弹性意味着降低了拥塞的风险。因为RTP流不会像TCP流那样可以增长到消耗掉所有可用带宽的程度。但是,缺乏弹性也意味着RTP流不能任意减小它在网络上的负载量,以在出现拥塞时消除之。
因为RTP可能会广泛应用于不同环境,所以没有一个通用的拥塞控制机制。因此,在每个RTP profile中定义拥塞控制才是合适的。对于某些profile,包含一个应用声明,限制该profile只用于那些设计时就预防拥塞的情况,这样就足够了。对其它profile,可能需要特别的方法,如基于RTCP反馈的自适应数据传输速率调整。
RTP依赖于下层协议提供RTP数据和RTCP控制流的解复用。对于UDP和相似协议,RTP应该使用一个偶数端口作为目的地址,相应的的RTCP流应该使用下一个奇数端口。
在一个单播会话中,两个参与者都需要指定一个端口对用于接收RTP和RTCP包,可以使用同一个端口对。一个参与者绝对不能假设输入的RTP或RTCP包的源端口可以用作输出的RTP或RTCP包的目的端口。当RTP数据包双向传输时,每个参与者的RTCP SR包必须发送到另一个参与者指定用于接收RTCP包的那个端口。RTCP SR包包含输出数据的发送者信息和输入数据的接收报告信息。如果一方不发送数据(参考6.4节),则替换为发送RTCP RR包。
... ...
如果传输RTP包的底层协议是连续字节流(TCP)而不是消息(或封包,UDP),必须定义一种RTP包的封装以提供Framing机制。如果底层协议可能包含padding,以至于RTP payload的长度无法确定,那么也需要Framing。
通常一个应用在一个特定RTP会话中只执行一个profile,在RTP协议中没有明确的指示符标识哪个profile在被执行。
Normative References [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC 2279, January 1998. [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [7] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [8] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Informative References [10] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE Computer Communications Review, Vol. 20(4), September 1990. [11] Schulzrinne, H., "Issues in designing a transport protocol for audio and video conferences and other multiparticipant real-time applications." expired Internet Draft, October 1993. [12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991. [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [14] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non- guaranteed quality of service", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003. [15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [18] Bolot, J.-C., Turletti, T. and I. Wakeman, "Scalable Feedback Control for Multicast Video Distribution in the Internet", in SIGCOMM Symposium on Communications Architectures and Protocols, (London, England), pp. 58--67, ACM, August 1994. [19] Busse, I., Deffner, B. and H. Schulzrinne, "Dynamic QoS Control of Multimedia Applications Based on RTP", Computer Communications , vol. 19, pp. 49--58, January 1996. [20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, September 1993. Also in [34]. [21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group Membership in RTP", RFC 2762, February 2000. [22] Cadzow, J., Foundations of Digital Signal Processing and Data Analysis New York, New York: Macmillan, 1987. [23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC 1627, July 1994. [26] Feller, W., An Introduction to Probability Theory and its Applications, vol. 1. New York, New York: John Wiley and Sons, third ed., 1968. [27] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. and D. Oran, "Secure Real-time Transport Protocol", Work in Progress, April 2003. [29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III", RFC 1423, February 1993. [30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171, June 1983. [31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [33] Stubblebine, S., "Security Services for Multimedia Conferencing", in 16th National Computer Security Conference, (Baltimore, Maryland), pp. 391--395, September 1993. [34] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, vol. 2, pp. 122--136, April 1994.