RFC2326實时流协议(RTSP).doc

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有很大的不同： 2 RTSP引入了很多新方法并且有不同的协议标识符。2 RTSP服务器在大多数默认情况下需要维持一个状态，但HTTP是无状态协议。2 RTSP客户机和服务器都可以发出请求。2 数据由另一个协议传送（有一特例除外）。2 RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。2 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服务器的主机上，也可以建立在不同的主机上。媒体服务器重定向： 重新定向媒体客户端到另外一个媒体服务器。(媒体)流： 单个媒体实例，比如，在应用中共用音频流或视频流。当使用RTP时，流包括由RTP 会话(session)中源所创建的所有RTP和RTCP包。这和定义DSM-CC流时相同。消息：RTSP通讯的基本单元。由15章