RTP&RTCP
时间:2006-07-05 来源:lzhw_lucky
一. 概述
实时传输协议(RTP,Real Time Transport Protocol)由RFC 1889定义,主要用于网络上各种实时应用(Real-time applications)。现在实时应用非常热(图14-02-1)。
图14-02-1 网络实时应用例
为什么不采用TCP?
众所周知,Web网页传输是建立在HTTP协议的基础上的,但是HTTP有着自己的局限性:
1.HTTP是无连接协议,限制了每次连接只处理一个请求,服务器处理完客户的请求,收到应答后,即断开连接,虽然这种方式可以节省时间,但却无法实现广播。
2.HTTP是无状态协议,所谓的无状态协议是指协议对于事件处理无记忆能力,这就意味着如果后续处理需要前面的信息,则必须重传,如果采用HTTP则必须重传,从而导致传输数据量增大,带宽浪费。
存在4个问题:
o不需要100% 的可靠性
o重发延迟
o窗口后退
oN 参与者 -> N*N 连接
实时传输协议提供了支持这些要求的功能:
-
丢失,顺序混乱:序列号
-
丢失,不稳定:时间戳
-
数据源/有效载荷认定
-
速率控制: 服务质量反馈(QoS feedback)
RTP用于一对多传输情况下,提供时间信息和实现媒体同步。此外,实时传输控制协议(RTCP,Real Time Transport Control Protocol)与RTP一起提供流量控制和拥塞控制服务。在RTP会话期间,各参与者周期性地传送RTCP包,RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此服务器可利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合网上的实时数据。
RTP和其他熟悉的协议如HTTP、 FTP等类似,但是根据实时流的特定要求作了剪裁。
和HTTP、FTP不同,RTP并不下载整个视频到客户计算机上,而是用固定的数据速率传输一个细的单向数据流,使其实时播放广播(在很短的初始化握手和数据缓冲之后)。一个流化了的一分钟电影就恰好播放一分钟。当连接具有足够的带宽来处理数据流的时候,电影就将播放。当数据播放完了就丢弃。观众只能通过再请求从流服务器来重放。
实时流是如何被处理的?
当你收听实时广播时,流客户软件 (比如,QuickTime Player, 或者QuickTime 插件) 发送一个请求到流服务器。服务器查找会话描述协议 (SDP,Session Description Protocol)文件, 如找到,就开始通过RTP发送流媒体到你的计算机。
一个SDP文件是一个文本文件,包含了将要发送什么和怎么收听的信息。SDP文件由计算机上的广播软件(比如Sorenson广播器)建立,它捕获实况媒体,但是SDP文件必须在媒体广播之前被拷贝到流服务器。QuickTime Player 和QuickTime 插件可以打开视频的SDP文件。
传送的问题
必须牢记实时流包含一些传送上的问题。
· 数据丢失。 RTP 使用低级的UDP进行传送。 UDP 比TCP/IP快,但是没有丢失报告机制,所以Internet上的流通常都会丢失。
· 网络地址转换。小型网络用路由器连接Internet接收流可能有问题。这些路由器通常使用网络地址转换(NAT, Network Address Translation), 但是RTP的流包含的端口地址会使一些老式NAT软件迷惑。你需要升级NAT软件。
· HTTP 管道。如其他失败,使用HTTP管道将RTP数据包打包进普通HTTP数据包。这常常使流能穿过防火墙或NAT路由器。要使用HTTP管道, 收看者必须配置自己的QuickTime 设置控制面板,通过检查使用HTTP并且设置端口为80(或者是流服务器用HTTP传输的端口),而且服务器必须支持HTTP管道。
RTP 与 RTSP的比较
分清楚RTP和实时流协议(RTSP)很重要, RTSP是另一个传送协议。RTSP 用在观众和Unicast 服务器通信的情况。RTSP 提供双向通信,即观众可以和流服务器通信并且进行如倒带、换章节观看等操作。
相反,RTP 是一个单向协议,只能从服务器发送实况或存储流到客户。
RTP一般和RTCP配合使用(图14-02-2)。两个密切链接的部分(相继的UDP端口):
o 数据部分,传输RT数据
o 控制部分RTCP(Real Time Control Protocol) ,监视QoS和携带预期信息
(a)用途
(b)使用相邻的端口
图14-02-2 RTP和RTCP的使用
二.RTP数据传输协议 RTP提供端对端网络传输功能,适合通过多播和点播传送实时数据,如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务,RTCP扩充数据传输以允许监控数据传送,提供最小的控制和识别功能。RTP与RTCP设计成独立于传输层和网络层。 1.RTP固定头 RTP头格式如图14-02-3所示。 图14-02-3 RTP头格式 开始12个八位组(字节)出现在每个RTP包中,而CSRC标识列表仅出现在混合器插入时。各字段的含义如下: ① 版本(v):2位,标识RTP版本。 ② 填充标识(P):1位,如设置填充位,在包尾将包含附加填充字,它不属有效载荷。填充的最后一个八位组包含应该忽略的八位组。某些加密算法需要固定大小的填充字,或为在低层协议数据单元中携带几个RTP包。 ③ 扩展(x):1位,如设置扩展位,固定头后跟一个头扩展。 ④ CSRC计数(cc):4位,CSRC计数包括紧接在固定头后CSRC标识符个数。 ⑤ 标记(M):1位,标记解释由设置定义,目的在于允许重要事件在包流中标记出来。设置可定义其他标识位,或通过改变位数量来指定没有标记位。 ⑥ 载荷类型(PT,Payload Type):7位,标识RTP载荷格式并决定其解释。设置指定载荷类型代码对载荷格式的静态映射(audio, video, image, texte, html等)。其他载荷类型代码可通过非RTP途径动态定义。对音频和视频的缺省映射初集在相关设置中指出。将来可进一步扩展。 ⑦ 序列号(Sequence Number):16位,序列号随每个RTP数据包而增加1,由接收者用来探测包损失,而恢复包序列。序列号初值是随机的,使对加密的文本攻击更加困难。 ⑧ 时间戳(timestamp):32位,时间戳反映RTP数据包中第一个八位组的采样时刻,采样时刻必须从单调、线性增加的时钟导出,以允许同步与抖动计算。时钟必须有足够分辨率,满足所需同步和测定包到达抖动精度。时钟频率依赖携带数据的格式,并在设置中静态指定。如RTP包周期产生,采用采样所用的时钟确定名义采样时刻,而不是从系统读出。如同序列号,时间戳的初始值是随机的。如几个连续RTP包在逻辑上一次产生它们就有着相同的时间戳,属于同一视频帧。如数据不是以采集顺序发送,像MPEG插入的视频帧,连续RTP包包含的时标可能不是单调的。 ⑨ 同步源标识符(SSRC,Synchronization Source Identifier):32位,SSRC段标识同步源。此标识不是随机选择的,目的在于使同一RTP包连接中设有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低,所有RTP实现都必须探测并解决冲突。如源改变源传输地址,也必须选择一个新SSRC标识以避免插入成环行源。 ⑩ CSRC列表:0到15项,每项32位。CSRC列表表示包内包含的对载荷起作用的源。标识数量由CC段给出。如超过15个作用源,也仅标识15个。CSRC标识由混合器插入,用作源的SSRC标识。 2.复用RP连接 为使协议有效运行,复用点数目应减至最小。RTP中,复用由定义RTP连接的目的传输地址(网络地址与端口号)提供。例如,对音频和视频单独编码的远程会议,每个媒介被携带在单独RTP连接中,具有各自的目的传输地址。目标不再将音频和视频放在单一RTP连接中,而根据SSRC段载荷类型进行多路分解。 使用同一SSRC,而具有不同载荷类型的交叉包将带来几个问题: (1) 如一种载荷类型在连接期间切换,没有办法识别新值将替换哪一个旧值。 (2) SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同,而要求不同系列号空间以说明哪种载荷类型有丢包,交叉复用载荷类型将需要不同计时空间。 (3) RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间,而不携带载荷类型段。 (4) RTP混合器不能将不兼容媒体流合并成一个流。 (5) 在一个RTP连接中携带多个媒介阻止几件事:使用不同网络路径或网络资源分配,接受媒介子集。 对每种媒介使用不同SSRC,但以相同RTP连接发送可避免前三个问题,但不能避免后两个问题。 3.对RTP头特定设置的修改 现用RTP数据包头对RTP支持的所有应用类共同需要的功能集可以认为是完整的。然而,为维持ALF设计原则,头可通过改变或增加设置来裁剪,并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息,但由于很多应用需要它们,否则要容纳它们,就要增加另外32位宇,故允许分配在固定头中。包含这些段的八位组可通过设置重新定义以适应不同的要求,如采用更多或更少标记位。如有标记位,既然设置无关监控器能观察包丢失模式和标记位间关系,我们就可以定位八位组中最重要的位。 其他特殊载荷格式(视频编码)所要求的信息应该携带在包的载荷部分。可出现在头部,总是在载荷部分开始处,或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能,应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段,同时,与监控器和记录器无关设置仍能通过仅解释开始的12个八位组处理RTP包。
|