RTSP实时流协议0416.doc

Catalog 目 录1RTSP协议的产生42RTSP协议的描述43RTSP 协议的特性54RTSP协议的扩展65RTSP的操作模式66RTSP协议状态67RTSP与其他协议关系78RTSP 协议的信息79RTSP 协议实体810RTSP 协议请求的连接811RTSP方法的定义812流水线操作9 RTSP实时流协议Keywords 关键词：RTSP 、流媒体Abstract 摘 要：本文档详细描述了RTSP实时流协议的产生、特性以及协议的状态。List of abbreviations 缩略语清单： Abbreviations缩略语Full spelling 英文全名Chinese explanation 中文解释RTSP实时流协议1 RTSP协议的产生RTSP（Real-Time Streaming Protocol）实时流协议是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。网络的带宽是完成流媒体传输的物质基础，在传输声音、图像、视频等多媒体信息流时，即使这些媒体流进行了压缩，所需的带宽仍然比文字文件大，但并不是有足够的带宽就可以完全解决流媒体传输问题。一般来说，所需带宽的多少是与应用密切相关的，从应用角度来讲，如果用户数不断增加、信息服务量不断增加，带宽有多少都是不够的。同步是媒体流的基本控制方法。流媒体是实时的，是时间属性的表现，而 HTTP协议不能提供时间的可靠性，因此产生了RTSP协议。2 RTSP协议的描述RTSP是一个应用层协议，目的是为流媒体实现多点传送和以点播方式单一传送提供健壮的协议，从而控制实时数据的发送。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。RTSP利用流技术把数据分成许多包，包的大小由客户端和服务器端的实际带宽决定，当客户端接收到足够的数据包时，用户不需下载整个媒体文件就可以开始播放流媒体。因为播放器在播放一个包的同时，解压另一个包并下载第三个包。流媒体数据可以是输入的实况信息，也可以是存储的视、音频片段。实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。连续媒体流与控制流是有可能交叉，但在通常情况下RTSP本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。RTSP也可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下： 从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。 媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。通过RTSP协议，服务器端可以跟踪流媒体传输的时间、地址和方式。RTSP增加了对流媒体的控制请求，能恢复来自媒体服务器的流媒体。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。在体系结构上，RTSP位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。3 RTSP 协议的特性可扩展性：新方法和参数很容易加入RTSP。易解析：RTSP可由标准 HTTP或MIME解吸器解析。安全：RTSP使用网页安全机制。独立于传输：RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。多服务器支持：每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。记录设备控制：协议可控制记录和回放设备。流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323可用来邀请服务器入会。 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。 演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个缺口。HTTP友好：此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。 适当的服务器控制：如用户启动一个流，他必须也可以停止一个流。 传输协调：实际处理连续媒体流前，用户 可协调传输方法。 性能协调：如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。4 RTSP协议的扩展由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP可以如下三种方式扩展，这里以改变大小排序：方式1： 以新参数扩展现有的方法，如用户需要收到一个拒绝的确认，而方法扩展并不支持，就会在请求段中加入一个与这个扩展相应的标记。方式2：加入新方法，如果信息接收者不能识别请求，则返回错误代码501（还未实现），并且发送者不能再用这种方法发送请求。用户可使用OPTIONS方法查询服务器所支持的方法。而服务器也应该它所支持的使用公共响应头的方法列出来。方式3：定义协议的新版本，允许改变所有部分（除了协议版本号位置）。5 RTSP的操作模式 每个演示和媒体流都可以用RTSP URL识别。整个演示与演示组成的媒体的属性是由演示描述文件定义的。用户可使用HTTP或其它途径获得这个演示描述文件，因此它没有必要保存在媒体服务器上。为了说明这个规定，假设一个演示描述描述了一个或者多个演示，而其中每个演示中又有一个公共时间轴。为简化说明，且不失一般性，我们假定演示描述的确包含了这样的一个演示。一个演示中可以包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式： 单播： 以用户选择的端口号将媒体发送到RTSP请求源。 组播，服务器选择地址： 媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。 组播，用户选择地址： 如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。6 RTSP协议状态 RTSP控制一个通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到RTSP请求，数据也会继续发送。在生命周期内，单个媒体流可以由不同TCP连接顺序发出的RTSP请求来控制。因此，服务器也需要维持一个连接状态使得RTSP请求能与流相互联系。RTSP中很多方法与状态无关，但以下方法在定义服务器流资源的分配与应用上起着重要的作用： SETUP： 让服务器给流分配资源，启动RTSP连接。 PLAY与RECORD： 启动SETUP 分配流的数据传输。 PAUSE： 临时停止流，而不释放服务器资源。 TEARDOWN： 释放流的资源，RTSP连接停止。 标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。7 RTSP与其他协议关系 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点，例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递。而且，它也允许独立的不依靠HTTP的RTSP 服务器与用户存在。 但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，由用户发出请求，服务器作出响应，HTTP请求是没有状态的。在RTSP中，用户和媒体服务器都可发出请求，并且RTSP请求是有一定的状态的，因此在请求确认后很长的一段时间内，仍然可以设置参数，控制媒体流。在流媒体的传输中还是用到了HTTP功能，因为HTTP在安全和代理上的功能要比RTSP强大。由于要求非常接近，所以在缓存、代理和授权上采用HTTP功能是很有价值的。 当大多数实时媒体使用RTP作为传输协议，但是RTSP没有绑定到RTP。RTSP假设了存在演示描述格式可表示包含了几个媒体流的演示的静态属性与临时属性。8 RTSP 协议的信息 RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。 10646字符集避免敏感字符集切换，但这个对应用来说是不可见的。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度由如下因素决定：1、 不管实体的头段是否出现在信息中，不含信息体的的响应信息总以头段后第一个空行结束。2、 如出现内容长度的头段，则以它的字节数来表示信息体长度。如果没有出现内容长度的头段，那么信息体的长度为零。3、 服务器关闭连接。（关闭连接并不能找出请求信息体的末端，因为连接关闭后，服务器就不能再返回一个响应了。） 注：RTSP目前并不支持HTTP/1.1块传输编码，它需要有内容长度头。假如返回适度演示描述长度，即使是动态产生，（这时块传输编码就没有必要了），服务器也应该能决定其长度。虽然在没有实体的情况下也会给出内容长度，但在长度不是十分明确的时候，一些规则可以确保合理行为的实现。 从用户到服务器端的请求信息的第一行包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。9 RTSP 协议实体如果不受请求方法或响应状态编码限制，请求和响应信息可传输实体，一个完整的实体由实体头文件和实体体组成，但是也有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者都可以分别指用户和服务器。实体头定义实体体可选元信息，如没有实体体，实体头定义请求的资源标识的可选元信息。扩展头机制允许不用改变协议定义附加实体头段，但这些段不能假定接收者能识别。不可识别头段将被接收者忽略，而让代理转发。10 RTSP 协议请求的连接RTSP请求可以几种不同方式传送：1、用于多个请求/响应传输的持久传输连接。2、用于单个请求/响应传输的一个连接。3、无连接模式。传输连接类型由RTSP URI来定义。对 rtsp 方案，需要持续连接；而rtspu方案，调用RTSP 请求发送，而不用建立连接。 与HTTP不同，RTSP允许媒体服务器给媒体用户发送请求。但是，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户端，这也是请求信息通过防火墙从媒体服务器传到用户的唯一途径。11 RTSP方法的定义方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。有些设计的防火墙和一些其他的环境可能要求服务器插入RTSP方法和流数据。这种插入将会使客户端和服务器的操作变复杂，并增加了额外的开销，除非确实有必要，否则应避免这样做。插入二进制数据也仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII码的美元符号来封装，后跟一个一字节通道标识，其后是所封装二进制数据的长度，是一个占两字节的整数，然后是流数据，这里没有CRLF，但有一个高层协议头。每个$块包含一个高层协议数据单元（如RTP包）。 当选择RTP传输时，服务器也会通过TCP连接插入RTCP信息。缺省情况下，RTCP包会在比RTP通道高的第一个可用通道上发送。客户端也可能在另一通道显式请求RTCP包 ，这可通过传输头插入参数时指定两个通道来做到。当两个或更多流交叉时，为取得同步，就需要用到RTCP。而且，当网络设置需要通过TCP控制连接（也可能是UDP）为传输RTP/RTCP包建立一个通道时也非常