1
Real Time Streaming Protocol(RTSP) 中文版
(前十章)
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 有很大的不同:
z RTSP 引入了很多新方法并且有不同的协议标识符。
z RTSP 服务器在大多数默认情况下需要维持一个状态,但 HTTP 是无状态协议。
z RTSP 客户机和服务器都可以发出请求。
z 数据由另一个协议传送(有一特例除外)。
z RTSP 使用 ISO 10646(UTF-8) 而不是 ISO 8859-1,以配合当前 HTML 的国
际化。
z RTSP
使用 URI 请求时包含绝对 URI。而由于历史原因造成的向后兼容性问题,
HTTP/1.1 只在请求中包含绝对路径,把主机名放入单独的标题域中。
这使得“虚拟主机”实现更为简便,一个单独 IP 地址的主机可虚拟为几个文件树主
机。
协议支持的操作如下:
z 从媒体服务器上检索媒体:
用户可通过 HTTP 或其它方法请求一个表示描述。如表示是组播,表示描述就包含
用于连续媒体的的组播地址和端口。如表示仅通过单播发送给用户,用户为了安全应
提供目的地址。
z 媒体服务器邀请进入会议:
媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录其中一部分,或全
部。这种模式在分布式教育应用上很有用,会议中几方可轮流按远程控制按钮。
z 将媒体加到现成讲座中:
如服务器告诉用户可获得附加媒体内容,对现场讲座显得尤其有用。
如 HTTP/1.1 中类似,RTSP 请求可由代理、通道与缓存处理。
1.2 要求
在本文档中的关键字“必须”,“一定不能”,“要求”,“会”,“不会”,“应该”,“不
评论1