绪论
目的
实时流协议（）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与
控制流有可能交叉，但 本身通常并不发送连续媒体流。换言之， 充当多媒体
服务器的网络远程控制。
表示描述定义了被控流，但本文并没有定义表示描述的格式。
这里没有使用 连接的概念，而由 会话代替（每次服务由服务器端
保持一个带标签的会话）。 会话没有绑定到传输层连接（如 连接）。因为虽然
在 会话期间， 客户端可打开或关闭多个对服务器端的可靠传输连接以发出
请求。但此外，也可能使用无连接传输协议，比如用 发送 请求。
控制的流可能用到 ，但 操作并不依赖用于携带连续媒体的传输机制。实
时流协议在语法和操作上与 类似，因此 的扩展机制大都可加入 。
尽管如此， 在很多方面还是和 有很大的不同：
引入了很多新方法并且有不同的协议标识符。
服务器在大多数默认情况下需要维持一个状态，但 是无状态协议。
客户机和服务器都可以发出请求。
数据由另一个协议传送（有一特例除外）。
使用 !"而不是 ""#$!，以配合当前 %& 的国际化。
使用 请求时包含绝对 。而由于历史原因造成的向后兼容性问题，
只在请求中包含绝对路径，把主机名放入单独的标题域中。
这使得“虚拟主机”实现更为简便，一个单独 地址的主机可虚拟为几个文件树主机。
协议支持的操作如下：
从媒体服务器上检索媒体：
用户可通过 或其它方法请求一个表示描述。如表示是组播，表示描述就包含用于连
续媒体的的组播地址和端口。如表示仅通过单播发送给用户，用户为了安全应提供目的地
址。
媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种
模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。
如 中类似， 请求可由代理、通道与缓存处理。
要求
在本文档中的关键字“必须”，“一定不能”，“要求”，“会”，“不会”，“应该”，“不应该”，“被推
荐的”，“可以”，和“可选择的”都在 $ 中解释。
1
