当前位置:文档之家› RTSP协议详解中文版

RTSP协议详解中文版

E-mail:**************译者:Bryan.Wong(王晶,宁夏固原)译文版本:alpha 0.80译文发布时间:2007-7-25版权:本中文翻译文档之版权归王晶所有。

可于非商业用途前提下自由转载,但必须保留此翻译及版权信息。

/filedownload?user=bryanj&id=611206网络工作组 H. Schulzrinne请求注释: 2326 哥伦比亚大学.类别: 标准跟踪 A. RaoNetscapeR. LanphierRealNetworks1998年4月实时流协议(RTSP)本备忘录状态本文为Internet社区描述了一种Internet标准跟踪协议,还需要讨论和建议以便进行改善。

请查看最新版本的"Internet正式协议标准"(STD 1)了解本协议的标准化进程和状态。

本备忘录的传播不受限制。

版权声明:版权为The Internet Society 所有。

所有权利保留。

摘要:实时流协议(RTSP)是应用层协议,控制实时数据的传送。

RTSP提供了一个可扩展框架,使受控、按需传输实时数据(如音频与视频)成为可能。

数据源包括现场数据与存储在剪辑中的数据。

本协议旨在于控制多个数据发送会话,提供了一种选择传送途径(如UDP、组播UDP与TCP)的方法,并提供了一种选择基于RTP (RFC1889)的传送机制的方法。

目录:1 介绍1.1 目的1.2 要求1.3 术语1.4 协议特性1.5 RTSP扩展1.6 整体运作1.7 RTSP状态1.8 与其他协议的关系2 符号协定3 协议参数3.1 RTSP版本3.2 RTSP URL3.3 会议标识3.4 会话标识3.5 SMPTE 相对时间戳3.6正常播放时间3.7 绝对时间3.8 选项标签3.8.1 用IANA注册新的选项标签*4 RTSP消息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成功2xx 3011.1.1 存储空间低250 3011.2 重定向3xx 3111.3 客户端错误4xx 3111.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 头部段定义(Header Field Definitions)38 12.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)46 12.24 最后修改(Last-Modified)4612.25 位置(Location)4612.26 代理认证4712.27 代理要求4712.28 公布 4712.29 范围4912.30 提交方(Referer)4912.31 稍后重试4912.32 要求4912.33 RTP信息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 WWW-认证(WWW-Authenticate)50 *13 缓存50*14 例子5014.1 按需点播(单播)5014.2 容器文件的流化5114.3 单个流容器文件5114.4 实况媒体表示的组播5114.5 在存在的会话中播放媒体5114.6 录制52*15 语法5215.1 基本语法5216 安全考虑(Security Considerations)52*附录A RTSP协议状态机53*A.1 客户端状态机53*A.2 服务器端状态机53*附录B 与RTP协议的交互53*附录C 使用SDP进行RTSP会话描述54 +C.1 定义54o C.1.1 控制URL 55o C.1.2 媒体流55o C.1.3 有效载荷类型55o C.1.4 详细格式参数55o C.1.5 表示的范围56o C.1.6 有效时间56o C.1.7 连接信息56o C.1.8 实体标签57+C.2 合控制不可用57+C.3 合控制可用57*附录D 最小RTSP实现58+D.1 客户端58D.1.1基本回放58D.1.2 认证enabled 58+D.2 服务器59D.2.1基本回放 59D.2.2认证enabled 59*附录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使用ISO 10646(UTF-8) 而不是ISO 8859-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章所述。

媒体初始化:数据类型/编码的具体初始化。

这包括时钟频率,颜色空间等。

客户端请求一个媒体流回放时所需的任何独立于传输的信息,都是在流创建时媒体初始化阶段产生的。

媒体参数:对于某种特定的媒体类型来说,回放前或者回放中有可能会发生改变的一些参数。

相关主题