RFC2326(中文版)(3)

RFC2326(中文版)

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有很大的不同：

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中定义的