RFC2326 Real Time流媒体协议（RTSP）--前三章

这是我毕业设计的英文翻译任务，刚刚翻译完毕。由于英文水平有限，错误难免，希望大家批评指正。联系方法：ggdw@cn99.com

                      RFC2326
              Real Time流媒体协议（RTSP）
这个备忘录的地位：
这个文档详细说明了因特网传输协议中的一种因特网标准路径协议，而且为了提高需要不断讨论和建议。请查阅正确的,与这协议相关的标准化的声明和情况的因特网官方协议标准协议.分发这备忘录是没有限制的.

摘要：
Real Time流媒体协议或者RTSP，是一种在应用层上控制实时传输数据的工具。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。这协议有意识的控制多重数据,传递会议,提供一种选择传递通道,比如UDP,多点传递UDP,
和TCP,以及一种基于RTP(RFC1889)选择传递机制.
目录内容:(略).

1. 介绍
 1.1 目的
 实时流媒体传输协议建立和控制一种简单的,或者几种时间同步,连续的媒体流,比如音频和视频.他不是代表性的传递连续流,尽管交错受到控制的连续媒体流是可能的(看10.12章).另一点,RTSP担当着为多媒体服务提供网络遥控控制.

被控制的流的设置是被一个介绍描写定义的.这个备忘录不是为介绍图象定义的格式.

这里没有RTSP连接的概念：作为代替，一个服务器的维护，一个被验证人标签的会议。一个RTSP会议是绝不会连到传输层连接的，比如，TCP连接。在一个RTSP会议中，一个 RTSP会议客户端可以开和关许多可靠的传送器，连接到发送RTSP请求的服务器上，作为选择，它可以使用无连接传输协议，比如UDP。

用RTSP控制流可以使用RTP，但是RTSP的操作不依靠通常传输连续媒体的传输机制。这个协议有意地在运作在上与HTTP/1.1相似。所以HTTP地扩展机制能够最大程度上被加到RTSP。但是RTSP与HTTP地许多重要不同在于：
* RTSP介绍许多新模式，并且有一个不同地协议标识符。
* 一个RTSP服务器需要默认地几乎所有地情况来维持正常运行。
* RTSP服务端和客户端都要能发出请求。
* 数据通过不同地协议传送。
* RTSP是用比ISO 8859-1要好地ISO 10646定义的，使它与当前的HTML的国际化努力相一致。
* 要求URI总使包括绝对URI.因为向后兼容性在历史上范过大错，HTTP/1.1只能传递要求的绝对路径，把主机名放入没有联系的标题栏上。
这使“虚拟主机”更简单，这时，带1 IP地址的单一的主机可以服务几个文件树。

本协议支持一下操作：
 从媒体服务器端取回媒体资料：
     客户端能够要求一个图象描述通过HTTP或者其它模式。如果图象使被多点传输的，图象描述包含了多点传输的地址和端口，用来传输连续媒体。如果图像只能经过UNICAST，那客户端就要因为安全而提供给目的文件。

对会议的媒体服务器的邀请：
    一个媒体服务器端能够被邀请参加一个存在的会议，可以向后播放图像，记录媒体文件的全部或者一部分。这种模式对分布式教学软件是有用的。查看会议中的几个部分可以按遥控控制按钮。

对存在图像的媒体追加：
    尤其为存在的图像，如果服务器能告诉客户端可以利用的补充性的媒体，那它是有用的。

在http/1.1 [ 2 ]中RTSP要求可以是通过代理，通道和缓存。
 
1.2 要求
 在这些文档中的关键字“必需”，“一定不能”，“必需的”，“会”，“不会”，“应该”，“不应该”，“被推荐的”，“可以”，和“可选择的”都在RFC2119中解释描述。

1.3 术语
一些术语采用于HTTP/1.1.在这里就不列举了。
总体控制：
多重流的控制通过服务器使用一种简单的时间线。为了音频/视频的反馈，可以通过客户端发送一个简单的开始或暂停的指令去控制视频/音频的反馈。
讨论：
一个多部件的，多媒体的图像，这里的多表示大于或者等于一。
客户端：
    客户端从服务器端请求连续的媒体数据。
连接：
   为了通讯的目的在两个程序之间确定的传输层虚拟线路。
容器文件：
  可以包含多媒体，包含图像的文件被打开的时候。RTSP服务器可以在这些文件上提供总体控制，尽管容器文件的观念没有被植入协议中。
连续媒体：
  数据是数据源和连接之间的实时关系，也就是说，接受器和数据源之间要不断产生关系联接。最普通的连续媒体的例子是音频和动画视频。连接媒体可以交互式的工作，它们在源和接受器之间是一种紧密的实时关系。或者是流的形式，这种关系就没有那么严格了。
实体：
  是作为一个请求或者回应的有