在基于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包必须总是一个报告包，方便头的确认。即使没有数
据发送或者接收，也必须发送空的RR，哪怕复合包中的另一个RTCP包是BYE.
(3)附加RR:
如果接收统计报告的源的数量超过了31，在初始报告包后面应该附加RR包。 (4)SDES:
每个复合RTCP包必须包含CNAME项的SDES包。其他源描述项可选，但受到带宽制。 (5)BYE或者APP:
其他的RTCP包类型可以任意顺序排列，但是BYE应作为最后一个包发送，包类型出现可以不止一次。
建议转换器(translator)或者混合器(mixer)从多个组合单个的RTCP包。如复合包整体长度超过了网络路径最大传输单元，可以分成多个较短组合包用低层协议以单个包形式发送。注意，每个复合包必须以SR或者RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。注意每个复合包都必须用SR或者RR包开始。程序要能够忽略接收到的RTCP包中无法识别类型的包。
1.2.2、发送方与接收方报告
RTP接收方使用RTCP报告包提供接收质量反馈，报告包根据接收方是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收方报告间唯一的差别是发送方报告包含一个20个字节发送方信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR;否则，就发出RR; SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR或RR包中，附加RR包可堆叠在初始SR或RR包之后。 发送方报告包由3部分组成，也可能还有第四个特定设置扩展部分。 第一部分为头，8个字节长，包括了版本(V)、填充位(P)、接收报告计数(RC),包类型(PT)、长度、同步源标识(SSRC)等信息。
第二部分为发送方信息，20个字节，出现在每个发送方报告包中。包括了NTP时间戳、RTP时间戳、发送方包计数、发送方字节计数等信息。 第三部分包括接收报告块，大小与自最后一个报告来发送方监听的其他源数量有关。每个接收报告块传输单个同步源接收RTP包的统计。发生冲突，当源改变SSRC标识时，接收方并不继续统计。这些统计包括:SSRC n(源标识)、丢失部分、丢失包累积数、收到已扩展的最高系列号、时间抖动、最后SR时间戳(LSR ),自最后一个SR来的延迟(DLSR)统计。
1.2.3 SDES:源描述RTCP包
SDES包为三层结构，由头与数据块组成，数据块可以没有，也可以有多个，组成项描述块所表明的源。 项描述如下:
1.版本(V)、填充(P)、长度：如SR包中所描述。
2.包类型(PT) ：8bit，包含常数202，区别RTCP SDES包。 3.源计数(SC)：Sbit，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。 4.源描述项内容包括:CNAME, NAME, E-mail, PHONE, LOC, TOOL，NOTE, PRIV。 1) CNAME:规范终端标识SDES项。 2) NAME:用户名称SDES项。 3) E-mail:电子邮件地址SDES项。 4) PHONE:电话号码SDES项。 5) LOC:用户地理位置SDES项。
6) TOOL:应用或工具名称SDES项。 7) NOTE:通知/状态SDES项。 8) PRIV:专用扩展SDES项。
1. 2. 4、 BYE:断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8bit的字节计数，后跟很多字节文本，标识离开原因，如:\"camera malfunction”或“RTP loop detected\".字符串具有同样的编码，如在SDES中所描述的。如字符串填充包至下32bit边界，字符串就不以空结尾;否则，BYE包以空字节填充。
1. 2. 5、APP:定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
1．3、RTSP协议[6]
1.3.1简介 1.目的:
实时流协议(RTSP)建立并控制一个或者多个时间同步连续媒体流，如视频和音频。尽管连续媒体流与控制流可以交叉，通常它不直接传输连续流本身。换句话说，RTSP是多媒体服务器的“网络远程控制”。
TCP可以绑定到传输层连接上，而RTSP会话无法绑定到传输层连接上。RTSP会话期间，RTSP用户可以打开和关闭很多连接到服务器的可靠传输来发出RTSP请求。此外，它可以使用无连接传输协议，比如UDP 。
RTSP流控制的流可能使用到RTP协议，但是RTSP操作不依赖于用来传输连续媒体的传输机制。这个协议在语法和操作方面类似于HTTP/1.1，以至于扩展的HTTP机制也可以被加入到RTSP中。这个协议支持如下操作: ※从媒体服务器恢复媒体:
用户可以通过HTTP或者别的方式请求一个演示描述。如果演示正在多播，演示描述符包含了多播地址和传输连续媒体的端口。如果演示是通过单播传输给用户的，用户提供安全目的地地址。
※邀请媒体服务器加入到会议中:
媒体服务器可以被“邀请”来参加正进行的会议，或回放媒体，或记录其中一部分或全部。这个模式对分布式的教学应用方面很有用。会议中的几个组可以轮流“按下远程控制按钮”。
※把媒体加入到现成的讲座中:
如果服务器可以告诉用户可以获得的附加媒体内容，在直播讲座方面尤其有用。RTSP请求可以用代理，管道，缓存处理，正像HTTP/ 1.1中那样。
2. RTSP特性
RTSP有如下特性:
可扩展性、解析简单、安全、传输独立、流控制和会议初始化分离、适合专业应用、友
好的代理和防火墙、友好的HTTP等。 更早一点的RTSP要求可以多用户。然而后来人们决定最好的办法是协议能够很容易地扩展到多用户。流标识符可以被几个控制流共同使用，以至于“通过远程”可以成为可能。协议不能指定几个用户怎样互相访问。 3.和其他协议的关系
RTSP在性能方面和HTTP有些重叠。和HTTP相互作用体现在与流内容的初始接触是通过web页的。目前的协议说明目的在于允许在WEB服务器和媒体服务器之间存在不同传输点。比如，演示描述符可以用HTTP或者RTSP获得，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP 。
然而，RTSP在另一种协议下数据传输超过带宽方面和HTTP有基础性的不同。HTTP是一个不对称协议，用户发出请求，服务器响应。在RTSP中，媒体用户和服务器都能够发出请求，RTSP请求是无序的，请求收到之后还可以设置参数和控制媒体流。 重新使用HTTP功能在至少两个方面有优势，即安全和代理。请求很类似，所以使HTTP能够工作在缓存、代理和鉴权方面是很有价值的。
很多实时媒体传输协议使用RTP，但是RTSP不是绑到RTP上的。 RTP假设演示描述符格式存在包括几个媒体流，这些演示描述符格式能表达静态和暂时的演示特性。
1.3.2、协议参数 1.RTSP版本
(H3.1)采用，用RTSP代替HTTP o 2. RTSP URL
rtsp命令通过可靠协议(Internet中用TCP)处理，而rtspu命令使用不可靠协议处理(Internet网中使用UDP) o
如果端口554没有被使用，默认情况下使用端口554。服务器端在主机的这个端口监听TCP (rtsp)或者UDP(rtspu)来控制唯一的资源用RTSP协议，资源的请求URI是rtsp URL a 在URL中应该避免直接使用IP。 3.会议标识
会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何字节数值。会议标识必须全局唯一。 4.连接标识
连接标识是长度不确定的字符串，必须随机选择，至少要8个字节长，使它很难能被猜测出。
5. SMPTE相关时间戳
SMPTE相关时间戳标识相对剪辑开始的时间，相关时间戳表示成SMPTE时间代码，精确到帧级。时间代码格式为小时:分钟:秒:帧。缺省SMPTE格式是\"SMPTE 30\"，帧速率为每秒29.97帧。其他SMPTE代码可选择使用SMPTE时间获得支持(如“SMPTE 25\")。时间数值中帧段值可从0到29。顺便指出30帧每秒和29.97帧每秒的区别:30帧每秒的视频帧序列中丢弃每分钟的起始两帧，除了时间是10分钟的整数倍的那些分钟，就变成了29.97帧每秒了。
6.正常播放时间
正常播放时间(NPT)标识相对演示开始的流绝对位置。时间戳由十进制分数组成。左边部分用秒或小时、分钟、秒表示;小数点右边部分表示秒的部分。演示的开始对应0.0上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。
7.绝对时间
绝对时间表示成IS08601时间戳，采用UTC (GMT). 8.可选标签
可选标签是用于指定RTSP新可选项的唯一标记。这些标记用在请求和代理一请求头段。当登记新RTSP选项时，需提供下列信息:
(1)名称和描述选项。名称长度不限，但应该不多于20个字符。名称不能包括空格、控制字符。
(2)表明谁改变选项的控制。如IETF, ISO, ITU-T，或其他的国际标准团体、联盟或公司。 (3)深入描述的参考，如RFC、论文、专利、技术报告、文档源码和计算机手册。 (4)对专用选项，附上联系方式。
1.3.3、RTSP消息
RTSP是基于文本的协议，使用ISO 10646字符集UTF-8编码(RFC 2279)方案。RTCP也使用ISO 10646编码方式。
如果消息中有消息体，消息体的长度按照如下方法确定(按照优先权顺序):
1.没有消息体的任何回应信息(如lxx, 204和304回应信息)，总是在头域后紧跟一个空行来结束消息，不管消息中的实体头域。(注意:空行仅仅包含CRLF回车换行。)
2.如果内容长度头域存在，以字节为单位的数值代表消息体的长度。如果头域不存在，这个数值为Oo
3.服务器关闭连接的时候。(关闭连接不意味着请求体的结束，因为那样的话服务器将不可能发回一个回应信息。)
如果合适长度的演示描述符返回，服务器应该能够知道它的长度，尽管它是动态生成的，使大块传输编码不必要。尽管如果有实体内容长度必须存在，尽管长度没有明确给出，这个规则保证了合理的行为。
1.3.4、实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机 制允许定义附加实体头段，而不用改变协议，但这些段不能假定。
1.3.5、连接
RTSP请求可以用几种不同的方式传输出去: ※几个请求一一回应模式的永久的传输连接 ※每个请求/回应模式的连接 ※无连接模式
传输连接的类型用RTSP的URI定义。对于“rtsp\"，就假设永久连接，然而“rtspu”请求在发送数据的时候就不建立连接。
不像HTTP, RTSP允许媒体服务器给媒体用户发送请求。然而，只是在永久连接的情况下才支持，因为不然的话媒体服务器就没有可靠的到达用户的方式。而且，这是从媒体服务器发给用户的请求穿过防火墙的唯一方式。
如果可靠传输协议用于携带RTSP，请求必须不能重新传输；RTSP应用必须依靠下层的传输来提供可靠性。
如果下层的可靠传输(如TCP)和RTSP应用程序重新传输请求，可能每个包丢了两次重新传输的结果。接收者不能典型的应用层重传，因为传输堆栈不能在第一次请求到达接收者之前重新传输。如果丢包是由于拥塞引起，不同层的多重传会加剧拥塞。
如果RTSP用在小RTT局域网中，标准的程序对优化初始TCP RTT估值是很有用的。时间戳头用于防止重传含糊问题，排除了Karn的算法的需要。
每个请求都有一个序列号在Cseq头中，每个不同的请求传输后都自动加1。如果请求由于缺少确认信息而重复，请求必须使用的一直都是最初的序列号(也就是序列号不递增)。
采用RTSP的系统必须支持在TCP上传输RTSP，也可能支持UDP。不管是UDP还是TCP，默认的RTSP服务器端口号都是5540
很多个去往同一个控制端点的RTSP包可以打包到单独的更低层PDU或者封装给TCP流。RTSP数据可以用RTP和RTCP包交替。不像HTTP，只要信息包含了有效载荷，RTSP信息必须包含内容长度头。不然，RTSP包就要在最后一个信息头后用一个空行来中止。
1.3.6、缓冲
在HTTP中，回应一一请求对是缓冲的。RTSP在这方面是不同的。回应是不缓冲的，除了演示描述符由DESCRIBE返回或者包含在ANNOUNCE中。(因为除了DERCRIBE和GET PARAMETER之外的回应不返回任何数据，对于这些请求来说缓冲不是必要的)。然而，对于连续媒体数据，尤其是用RTSP协议传输超过带宽的数据和会话描述符时，缓冲是必要的。
接收到建立和播放请求的时候，代理确定它是否有新的连续媒体内容的复制和描述符。它是通过处理建立或者描述请求来决定复制是否是最新的，把最后的修改过的头和缓冲了的复制比较。如果复制不是最新的，就把修改“建立”(SETUP)传输参数修改成合适的数字，继续把请求发给原始服务器。接下来的控制命令如\"PLAY\"(播放)或者“PAUSE\"(停止)，之后不修改任何代理继续传输出去。代理把连续媒体递送给用户，同时也会拷贝一份留着后来使用。允许缓冲做的准确行为是由缓冲回应指示描述的。如果缓冲正在给请求器送流信息，缓冲必须回答任何DESCRIBE(描述)请求，因为流描述符的低电平详情可能在原始服务器上改变了。
注意:不像HTTP缓冲，RTSP缓冲具有“cut through”型变量。不是从原始服务器中提取出完整的资源，缓冲只是简单的在把数据传送给用户途中顺便拷贝流数据。因此，不加入额外的冗余。
对于用户来说，RTSP代理缓冲像是一个常规的媒体服务器，而原始的服务器倒像是个用户。正像HTTP缓冲必须储存它所要储存对象的内容类型、内容语言等等，媒体缓冲必须要储存演示描述符。典型地，缓冲降低了所有的演示描述符的传输内容(即多播信息)，因为这些是从缓冲到用户的独立数据传输。编码器的信息仍然没变。如果缓冲能够翻译缓冲的媒体数据，它就尽自己所能提供的所有编码方式生成一个新的演示描述符。
[4]吴国勇，邱学刚，万燕仔等.《网络视频流媒体技术与应用》.北京:北京邮电大学出版社。2001年.
[5] (RFC 3550) H.Schulzrinne Columbia University,etc ,July 2003 [6] (RFC 2326) H.Schulzrinne Columbia Universityetc ,April 1998 [7] Microsoft Corporation.(ASF Specification)): America:2004.
因篇幅问题不能全部显示，请点此查看更多更全内容