这是我毕业设计的英文翻译任务,刚刚翻译完毕。由于英文水平有限,错误难免,希望大家批评指正。联系方法: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服务器可以在这些文件上提供总体控制,尽管容器文件的观念没有被植入协议中。
连续媒体:
数据是数据源和连接之间的实时关系,也就是说,接受器和数据源之间要不断产生关系联接。最普通的连续媒体的例子是音频和动画视频。连接媒体可以交互式的工作,它们在源和接受器之间是一种紧密的实时关系。或者是流的形式,这种关系就没有那么严格了。
实体:
是作为一个请求或者回应的有