RFC2326(中文版)－实时流协议(RTSP)

实时流协议(RTSP) ( Real Time Streaming Protocol (RTSP) ) 备忘录的状态： 本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。 版权声明： 版权为The Internet Society 所有。所有权利保留。 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP(RFC1889)上传送机制提供方法。 目录： 1 绪论      5 1.1 目的      5 1.2 要求      6 1.3 术语      6 1.4 协议特点      7 1.5 RTSP扩展      8 1.6 操作模式      9 1.7 RTSP状态      9 1.8 与其他协议关系      10 2 符号协定      10 3 协议参数      10 3.1 RTSP版本      10 3.2 RTSP URL      11 3.3 会议标识      13 3.4 会话标识      13 3.5 SMPTE 相对时间戳      13 3.6正常播放时间      14 3.7 绝对时间      15 3.8 选择标签      15 3.8.1 用IANA注册新的选择标签      15 4 RTSP消息      15 4.1 消息类型      16 4.2 消息标题      17 4.3 消息主体      17 4.4 消息长度      18 5 普通标题域      18 6 请求      19 6.1 请求队列      19 6.2 请求标题域      19 7 回应      20 7.1 状态行      20 7.1.1 状态代码和原因分析      20 7.1.2 回应标题域      23 8 实体      23 8.1 实体标题域      24 8.2 实体主体      24 9 连接      25 9.1 流水线操作      25 9.2 可靠性及确认      25 10 方法定义      25 10.1 选择      26 10.2 描述      26 10.3 通告      26 10.4 建立      26 10.5 播放      27 10.6 暂停      27 10.7 断开      27 10.8 获取参数      28 10.9 设置参数      28 10.10 重定向      28 10.11 录制      29 10.12 嵌入二进制数据      29 11状态代码定义（Status Code Definitions）      29 11.1成功2xx（Success 2xx）      30 11.1.1 存储空间低 250      30 11.2 重定向（Redirection 3xx）      31 11.3 客户端错误（Client Error ）4xx      31 11.3.1方法不允许      32 11.3.2参数不能理解      32 11.3.3会议未找到      33 11.3.4 带宽不足      33 11.3.5 会话未找到      34 11.3.6 本状态下该方法无效      34 11.3.7 标题域对资源无效      34 11.3.8 无效范围      35 11.3.9 参数只读      35 11.3.10 不允许合操作      36 11.3.11 只允许合操作      36 11.3.12 不支持的传输      36 11.3.13 目标不可达      37 11.3.14 选择不支持      37 12 标题域定义（Header Field Definitions）      38 12.1 接受      38 12.2 接受编码      38 12.3 接受语言      39 12.4 允许（Allow）      39 12.5 授权（Authorization）      40 12.6 带宽      40 12.7 块大小      40 12.8 缓存控制      41 12.9 会议      41 12.10 连接      41 12.11 基本内容      42 12.12 内容编码（Content-Encoding）      42 12.13 内容语言      43 12.14 内容长度（Content-Length）      43 12.15 内容位置      43 12.16 内容类型（Content-Type）      44 12.17 序列号      44 12.18 日期（Date）      44 12.19 过期（Expires）      45 12.20 来自（From）      45 12.21 主机      45 12.22 如果匹配      45 12.23 从何时更改（If-Modified-Since）      46 12.24 最近更改（Last-Modified）      46 12.25 位置（Location）      46 12.26 代理授权      47 12.27 代理要求      47 12.28 公用性      47 12.29 范围      49 12.30 提交方（Referer）      49 12.31 稍后再试      49 12.32 要求      49 12.33 RTP信息      49 12.34 比例      49 12.35 速度      49 12.36 服务器（Server）      49 12.37 会话      49 12.38 时间戳      49 12.39 传输      49 12.40 不支持      49 12.41 用户代理（User-Agent）      49 12.42 变化      49 12.43 通过      49 12.44 WWW-授权（WWW-Authenticate）      50 13 缓存      50 14 实例      50 14.1 要求媒体（单播）      50 14.2 容器文件的流      51 14.3 单个流容器文件      51 14.4 组播现场媒体表示      51 14.5 在存在的会话中播放媒体      51 14.6 录制      52 15 语法      52 15.1 基本语法      52 16 安全考虑（Security Considerations）      52 附录A RTSP协议状态机      53 A.1 客户端状态机      53 A.2 服务器端状态机      53 附录B 同RTP协议的交互      53 附录C 使用SDP进行RTSP会话描述      54 C.1 定义      54 C.1.1 控制URL      55 C.1.2 媒体流      55 C.1.3 有效载荷类型      55 C.1.4 详细格式参数      55 C.1.5 表示的范围      56 C.1.6 有效时间      56 C.1.7 连接信息      56 C.1.8 实体标签      57 C.2 合控制不可用      57 C.3 合控制可用      57 附录D 最简单的RTSP实现      58 D.1 客户端      58 D.1.1回放      58 D.1.2 授权      58 D.2 服务器      59 D.2.1回放      59 D.2.2授权      59 附录E 作者地址      60 附录F 致谢      60 参考书目      60 版权申明      61 1 绪论 1.1 目的 实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流有可能交叉，但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的网络远程控制。 表示描述(presentation description)定义了被控流，但本文并没有定义表示描述的格式。 这里没有使用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中解释。 1.3 术语 一些术语原由HTTP/1.1采用。在HTTP/1.1中定义的术语这里不再列举。 合控制： 服务器使用单条时间线对多个流的控制。对音频/视频回馈来讲，这就意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回馈。 会议： 多方参与的多媒体表示，这里的多方意味着大于或者等于一方。 客户端： 指请求媒体服务器上连续流媒体数据的客户端。 连接：       两个应用程序以通讯为目的在传输层建立虚拟电路。 容器文件：       可以容纳多个共同播放时包含表示(presentation)的媒体流的文件。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不是本协议内容。 连续媒体：       接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重新产生存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（但是不交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流的形式，这种关系就没有那么严格了。 实体： 作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成，如第八章所述。 媒体的初始化： 数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。用户请求媒体回放的任何独立传输信息，是在创建流时初始化媒体流相位时产生的。 媒体参数: 针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。 媒体服务器： 可对一个或多个媒体流提供回放和录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建立在作为传送请求表示(presentation)的Web服务器的主机上，也可以建立在不同的主机上。 媒体服务器重定向：