RTSP协议详解中文版

E-mail：[e-mail]译者：Bryan.Wong（王晶，宁夏固原）译文版本：alpha0.80译文发布时间：2007-7-25版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。=bryanj&id=611206网络工作组H.Schulzrinne请求注释:2326哥伦比亚大学.类别:标准跟踪A.RaoNetscapeR.LanphierRealNetworks1998年4月实时流协议(RTSP)本备忘录状态本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的Internet正式协议标准（STD1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。版权声明：版权为TheInternetSociety所有。所有权利保留。摘要：实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP(RFC1889)的传送机制的方法。目录：1介绍1.1目的1.2要求1.3术语1.4协议特性1.5RTSP扩展1.6整体运作1.7RTSP状态1.8与其他协议的关系2符号协定3协议参数3.1RTSP版本3.2RTSPURL3.3会议标识3.4会话标识3.5SMPTE相对时间戳3.6正常播放时间3.7绝对时间3.8选项标签3.8.1用IANA注册新的选项标签*4RTSP消息4.1消息类型4.2消息头4.3消息主体4.4消息长度*5普通头部段*6请求6.1请求行6.2请求消息头段*7响应7.1状态行7.1.1状态码和原因短语7.1.2响应头部段*8实体8.1实体头部域8.2实体主体24*9连接9.1流水线化259.2可靠性及确认25*10方法定义2510.1可选项2610.2描述2610.3通知2610.4建立2610.5播放2710.6暂停2710.7断开2710.8获取参数2810.9设置参数2810.10重定向2810.11录制2910.12嵌入（交织）的二进制数据29*11状态码定义2911.1成功2xx3011.1.1存储空间低2503011.2重定向3xx3111.3客户端错误4xx3111.3.1方法不允许3211.3.2无法理解参数3211.3.3会议未找到3311.3.4带宽不足3311.3.5会话未找到3411.3.6本状态下该方法无效3411.3.7头部域与资源不匹配3411.3.8无效范围3511.3.9参数为只读3511.3.10不允许合操作3611.3.11只允许合操作3611.3.12不支持的传输3611.3.13目标不可达3711.3.14不支持的选项3712头部段定义（HeaderFieldDefinitions）3812.1接受3812.2接受-编码3812.3接受-语言3912.4允许（Allow）3912.5授权（Authorization）4012.6带宽4012.7块大小4012.8缓存控制4112.9会议4112.10连接4112.11内容-基础4212.12内容-编码（Content-Encoding）4212.13内容-语言4312.14内容-长度（Content-Length）4312.15内容-位置4312.16内容-类型（Content-Type）4412.17命令序列题头（CSeq）4412.18日期（Date）4412.19过期（Expires）4512.20来自（From）4512.21主机4512.22如果匹配4512.23如果-被修改-自从（If-Modified-Since）4612.24最后修改（Last-Modified）4612.25位置（Location）4612.26代理认证4712.27代理要求4712.28公布4712.29范围4912.30提交方（Referer）4912.31稍后重试4912.32要求4912.33RTP信息4912.34倍速（Scale）12.35速度4912.36服务器（Server）4912.37会话4912.38时间戳4912.39传输4912.40不支持4912.41用户代理（User-Agent）4912.42变化4912.43通过4912.44认证（）50*13缓存50*14例子5014.1按需点播（单播）5014.2容器文件的流化5114.3单个流容器文件5114.4实况媒体表示的组播5114.5在存在的会话中播放媒体5114.6录制52*15语法5215.1基本语法5216安全考虑（SecurityConsiderations）52*附录ARTSP协议状态机53*A.1客户端状态机53*A.2服务器端状态机53*附录B与RTP协议的交互53*附录C使用SDP进行RTSP会话描述54+C.1定义54oC.1.1控制URL55oC.1.2媒体流55oC.1.3有效载荷类型55oC.1.4详细格式参数55oC.1.5表示的范围56oC.1.6有效时间56oC.1.7连接信息56oC.1.8实体标签57+C.2合控制不可用57+C.3合控制可用57*附录D最小RTSP实现58+D.1客户端58D.1.1基本回放58D.1.2认证enabled58+D.2服务器59D.2.1基本回放59D.2.2认证enabled59*附录E作者地址60*附录F致谢60*参考书目60*版权申明611介绍1.1目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的网络遥控器。表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。RTSP没有连接这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：*RTSP引入了很多新方法并且有不同的协议标识符。*RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。*RTSP客户机和服务器都可以发出请求。*数据由信带外的另一个协议传送（但有一个特例）。*RTSP使用ISO10646(UTF-8)而不是ISO8859-1，以配合当前HTML的国际化。*RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。当只有一个IP的主机要提供多个文档树时，可使虚拟主机的实现更简单。协议支持以下操作：从媒体服务器上获得媒体：用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。邀请媒体服务器进入会议：媒体服务器可被邀请加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流按网络遥控器的按钮。将媒体加到已存在的表示中：现场表示的专用概念。当服务器可以告诉客户端可以附加媒体时有用。和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。1.2要求在本文档中的关键字必须，必须不、需要、必须、必须不、应该、不应该、推荐、可能、和可选的，都和RFC2119[4]中的解释一致。1.3术语一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。合控制：服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。会议：多方参与的多媒体表示，这里的多方意味着大于或等于一方。客户端：指请求媒体服务器上连续流媒体数据的客户端。连接：以通讯为目的，在传输层建立的两个程序间的虚拟信道。容器文件：可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。连续媒体：接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。实体：请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。媒体初始化：数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。媒体参数:对于某种特定的媒体类型来说，回放前或者回放中有可能会发生改变的一些参数。媒体服务器：提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。媒体服务器重定向：重新把媒体客户端定向到另外一个媒体服务器。(媒体)流：单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。消息：RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。参与者：表示(presentation)：作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。表示描述(presentationdescription)：表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语会话(session)代替现场表示。表示描述可以采用包括会话描述(sessiondescription)SDP在内的多种格式。响应：RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。请求：RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。RTSP会话(session)：包括一次RTSP事务（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。传输初始化：客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。1.4协议特点RTSP有以下特性：易于扩展：可以很容易地向RTSP加入新方法和参数。易解析：RTSP可由标准HTTP或MIME解析器解析。安全：RTSP重用了网页安全机制。所有HTTP授权