在基于IP的网络中，用于多媒体数据实时传输的协议通常有四种，即资源预留协议(Resource Reservation Protocol , RSVP)、实时流协议(Real-TimeStreaming Protocol, RTSP)和实时传输协议(Real-Time Transport Protocol, RTP)及实时控制协议(Real-Time Control Protocol, RTCP) 。
RSVP被主机用来为特定应用流向网络请求一定的服务质量(QoS)[5]，它也被路由器用来在节点间传送这种服务质量请求，从而建立能提供特定服务质量的状态，并维护这种状态。资源预留协议最终将在数据流的路径上预留相应的资源(主要包括内存资源和CPU资源)。
实时流协议RTSP是由Real Networks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。与HTTP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器响应请求；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
RTP被定义为在一对一或一对多传输的情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，它本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTCP和RTP一起提供流量控制和拥塞控制服务，它们配合使用，能够以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
流媒体协议栈如下图所示：
图1流媒体协议栈‘”
Fig. 1 Streaming video protocol stack
在发送方的数据面，压缩且经过ASF编码的视频数据被读出并在RTP/RTCP/RTSP层上打包，提供定时和同步信息以及包的序列号。然后把这些打包的RTP数据流发送到UDP/TCP 层和IP层，得到的IP包在网络上传输。在接收方则按照相反的方向处理。在控制面，RTCP 包和RTSP包在UDP/TCP层上复用，并且被送到IP层，以便通过网络传输[4]
1. 1、RTP协议
1.1.1、RTP固定头域，RTP头格式如下：
图2 RTP头格式[5]
Fig. 2 RTP head format
头12个字节在每个RTP包中都有，而CSRC标识列表仅在有混合器插入的时
候才有。各段具体意义如下:
1.版本(V): 2bit
RTP版本信息。目前版本是2。 (RTP第一版草案是版本1，最初应用在“vat"音频工具中的是第0版)
2.填充位(P): l bit
如果填充位置1，末尾有一个或者多个附加的非有效载荷的填充字节。填充的最后一个字节是该忽略的填充数目，包括本身所占一个字节。填充在按照固定块大小加密的加密算法中或者在低层的协议数据单元中装载几个RTP包时可能需要。
3.扩展位(X): lbit
如果扩展位置1，固定头后必须跟了一个头扩展。
4. CSRC计数(CO: Obit
CSRC计数包含了紧跟在固定头后的CSRC标识符的个数。
5.标记(M) : 1 bit
在序言中定义了该标记的具体解释，目的是允许重要事件在包流中标记l止来。序言可以定义附加的标记位，或者通过改变有效载荷类型域中的数据位来指示没有标记位。
6.有效载荷类型(PT) : 7bit
定义RTP有效载荷的格式，通过应用程序定义具体的说明。序言可以指定和有效载荷格式相对应的有效载荷码的默认静态影像码。附加的有效载荷码可以通过非RTP方式动态定义。在RFC 3551中定义了一系列音频和视频的默认映射初集。会话中，RTP元可以修改有效载荷的类型，但是该域不能用于复用单独的媒体流。
对于有效载荷类型无法识别的数据包，接收方一律忽略。
7.序列号(Sequence Number) : 16bit
每发送一个RTP数据包序列号就增加1，这样接收方可以检测到数据包的丢失重新保存包序列。序列号的初始值是随机的，这样可以加大被人窃取攻击的难度。
8.时间戳(Timestamp) : 32bit
时间戳反映了RTP数据包的第一个字节的采样信息。采样信息由单调、线性的时钟导出，允许同步与抖动时间计算。时钟必须有足够分辨率，满足所需同步和测定包到达抖动精度。时钟频率依靠有效载荷中装载的数据的格式，在序言中或者定义格式的有效载荷格式说明中静态定义，或者也可以通过非RTP方式动态定义有效载荷的格式。如果RTP包是周期生成的，名义上的采样信息就通过采样时钟决定，而不是读一次系统时钟。例如，对于固定速率的音频每个采样周期时间戳就增加一。如果音频应用程序读一次覆盖了输入设备的160个采样周期，每读一块这样的数据块，时间戳就增加160，而不管这一块是在一个包中传输还是被丢弃了。
像序列号一样，时间戳的初始值也应该是随机的。如果几个连续的RTP包在逻辑上是同时生成的就具有相同的时间戳，比如同一个视频帧。如果数据不是以采集顺序发送，像MPEG插入的视频帧，连续RTP包包含的时间戳可能不是单调的。
源自不同的媒体流的RTP时间戳可能以不同的速率，单独的随机的偏移步进。因此，尽管由这些时间戳就足以重建一个单独流的时间，直接比较从不同的媒体源的RTP时间戮对于同步来说效率不高。相
反，对于每个媒体RTP时间戮和采样间隔是通过参考的时钟配对关联起来的，这个参考时钟代表了和RTP时间戮相对应的数据的采样时间。所有的媒体都共享参考时钟来达到同步。不是每个数据包中都传输了时间戮配对信息，而是在更低速率的RTCP SR包中传输。
采样间隔(instant)的选择目的是RTP时间戳的参考，因为已知传输端点对于所有的媒体信息是一个通常的定义，独立于编码延迟或者其他处理。目的是允许所有的媒体的同步描述都在同一时刻采样。
9. SSRC: 32bit
SSRC段定义了同步源。标识应该是随机选择的，防止在同一个RTP会话中有两个同名的同步源。尽管多个源选择相同的标识的可能性是很低的，所有的RTP实现都必须具有检测和防止碰撞机制。如果源改变了源传输地址，就必须选择一个新的SSRC标识防止被解释为循环源。
10. CSRC列表:0到15项，每个项都32bit
CSRC列表定义了该包中的有效载荷的所有源的标识。CC域给出标识的数量。如果有多于15个作用源(contributing source)，只能标识出其中的15个。CSRC标识由混合器(mixer)加入，使用作用源的SSRC标识。例如，对于音频包来说所有的被混合生成一个包的SSRC 都被列出来了。
1.1.2、复用RTP会话
为了使协议有效运行，应该降低复用点的数量，正像集合层处理设计规则(10)描述的那样。在RTP中，复用是由多个目标传输地址提供(网址和端口号)，每个RTP会话都有不同的传输地址。例如，有单独编码的音频和视频媒体组成的远程电信会议中，每个媒体都用单独的RTP会话来携带，而且有自己的目标传输地址。单独的音频和视频数据流不能用相同的RTP会话携带，分解复用是基于有效载荷
类型或者SSRC载荷类型的。
1.1.3 RTP头的序言特定修改
现在的RTP数据包的头完全符合所有的RTP可能支持的应用程序类型的通用
功能。然而，为了和ALF设计规则相一致，头可以在允许序言独立监视和记录工
具的情况下，通过修改或者在序言说明中适当的附加信息进行功能裁减。
标记位和有效载荷类型域含有序言说明信息，但是它们是放在固定头里的，因为很多应
用程序都要用着它们，不然的话就不得不为了装载它们而附加另外32bit字。含有这些域的字节可以在序言中重新定义来满足不同的需要，例如更多或者更少的标记位。如果有标识位，其中的一位必须放到这个字节的最高位，因为独立于序言的监视器可能能够检测出包损失格式和标识位的关系。
特定有效载荷格式的附加信息，例如编码，应该放在包的有效载荷段中。可以放在有效载荷段起始的头里，也可以用数据格式的一个保留值来指示。
如果特定类型的应用程序需要独立于有效载荷格式的附加功能，那些应用程序运行所符合的序言应该在现存的头的紧跟SSRC域后附加固定域。这些程序能够迅速直接访问附加域，而独立于序言的监视器或者记录器也能通过解析头12个字节信息就处理RTP包。
如果在所有的序言中都附加了相同的附加功能，就要定义一个新版本的RTP，在固定头域中作永久性修改。
1. 1. 4 RTP头扩展
注意只在有限的使用范围内要求头扩展。使用这个机制最好通过另外的方式实现，使用前段描述的方法。例如，给固定头的序言说明扩展处理起来就更加廉价，因为既不是有条件的也不是可变的位置。特定有效载荷格式的附加信息不应该使用头扩展，但是应该在包的有效载荷段中携带。
如果RTP头的X位为1，在RTP头中必须追加可变长度的头扩展，如果CSRC列表存在就紧跟其后。头扩展中包含了16bit长度域，存放的是扩展中的32bit长度字的数量，不包括四字节的扩展头(因此0也是有效长度)。只有一个单独的扩展能够追加到RTP数据头后。为了允许每个协调工作的多个互相作用的
实现和不同的头扩展相独立，或者允许某一特定执行能够和多于一个类型的头扩展协调工作，头扩展的头16bit数据用于区分标识或者参数。这16bit数据的格式定义符合实现所遵守的序言说明。RTP说明不定义任何头扩展本身。
图3 RTP头扩展
Fig. 3 RTP head extension
1．2、RTP控制协议一RTCP
RTP控制协议(RTCP)将控制包周期发送给所有连接者，应用与数据包相同的分布机制。下层的协议必须提供数据包和控制包的复用，例如使用单独的UDP端口号。RTCP具有四个功能:
第一个功能是提供数据发布的质量反馈aRTCP是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP多播经验表明，从发送者收到反馈对诊断发送错误是至关重要的。给所有参与者发送接收反馈报告允许问题观察者估计哪些问题是局部的，哪些是全局的。诸如IP多播等发布机制使网络服务提供商
类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
第二个功能是RTCP携带了一个RTP源永久传输层标识，即规范名字或者CNAME。如果发现了冲突或者程序重新启动SSRC就会改变，接收方需要CNAME跟踪每个参与者。接收方也需要有CNAME来从一系列相关的RTP会话中把多个给定的参与者的多个数据流联合起来，例如把音频和视频数据同步起来。媒体内部的同步也要求数据发送方的RTCP包中包含的NTP和RTP时间戳。
前两个功能要求所有的参与者都发送RTCP数据包，因此必须控制速率来适应大量的参与者。通过每个参与者都把自己的控制包发送给所有的参与者，每个都能独立的观察参与者的数目。这个数目用于计算数据包发送的速率。
第4个可选功能是传达最小的会话控制信息，例如在用户接口处显示参与者身份。这在“松控制”会话中最有用，这类会话中参与者进入或离开而不需要成员控制或者参数信息。RTCP提供到达所有参与者的一个方便的渠道，但是并不要求支持应用程序的所有控制通信要求。可能需要更高层的会话控制协议，但是已经超过了本文探讨的范围。
头三个功能应该用于所有的环境中，尤其在IP多播的情况下。RTP应用程序设计者应该避免只能在单播的情况下工作的机制，也不能适应更大的数量。RTCP传输可以为发送方和接收方单独控制，例如接收方无法接收到反馈的单向连接中。
1 .2. 1、RTCP包格式
下面定义了几个携带变化的控制信息的RTCP包类型:
SR：发送方报告，源于活动发送方参与者的用于传输和接收统计。
RR：接收方报告，源于非活动发送方的参与者用于接收统计，和SR组合起来用于活动发送者报告多于31个源。
多媒体SDES：源描述项，包括CNAME。
BYE：显示参与中止。
APP：应用程序特定功能。
和RTP数据包中的内容类似，每个RTCP包都以固定的部分开头，之后紧跟和包类型有关的长度可能变化的结构化的元素，但是必须以32bit为边界结束。包含了排列要求和每个包中的固定部分内的长度域使RTCP包“可堆叠的”。多个RTCP包不用插入分隔部分就可直接连接到一起形成一个复合RTCP包，这个复合的RTCP包在低层的协议中用一个单独的包发送出去，如UDP。在复合包中没有精确的RTCP包的数量，因为更低层协议只要提供整个长度就可以决定复合包的结束。
复合包中的每个单独的RTCP包都可以单独处理而不依赖于组合包的顺序或者组合。然而，为了执行协议的这些功能，必须满足如下限制：
*接收统计((SR或者RR中)应该经常发送，只要带宽允许，因此每个周期性的传输的复合RTCP包中必须包含有报告包。
*新的接收者需要接收CNAME，并尽快识别源，并开始连接媒体进行同步，所以每个复合RTCP包都必须包括SDES CNAME，除非复合RTCP包分割开用于部分加密。
*出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量。
因此，所有的RTCP包必须用至少有两个单独包的复合包传输，用如下格式:
(1)加密前缀(Encryption Prefix)
仅当复合包被加密，才加上一个32位随机数用于每个复合包发送。
(2)SR或RR:
复合包中的第一个RTCP包必须总是一个报告包，方便头的确认。即使没有数
发布评论