流媒体传输协议
在基于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设计规则相一致，头可以在允许序言独立监视和记录工
具的情况下，通过修改或者在序言说明中适当的附加信息进行功能裁减。
标记位和有效载荷类型域含有序言说明信息，但是它们是放在固定头里的，因为很多应