RFC2326(中文版)(7)

RFC2326(中文版)

入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
1.7 RTSP状态
　 RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的会话状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
　 让服务器给流分配资源，启动RTSP会话。
PLAY与RECORD：
　 启动SETUP 分配流的数据传输。
PAUSE：
　 临时停止流，而不释放服务器资源。
TEARDOWN：
　 释放流的资源，RTSP会话停止。
　 标识状态的RTSP方法使用会话(session)标题域识别RTSP会话，为回应SETUP请求，服务器生成会话标识。
1.8 与其他协议关系
　 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，表示描述(presentation description)可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。
　 但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出回应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。
重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
　 当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。
RTSP假设存在表示描述格式可表示包含几个媒体流的表示的静态与临时属性。
2 符号协定
既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类似，本文对所有机制的说明都是以散文和补充反馈的方式来描述的。除RTSP中以”1#”代替”,”为分隔符不同外，其余在RFC 2234中有详细的描述。简单说明补充反馈方式如下：


补充反馈方式（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name = definition）
规则的名字（name）就是它本身（不带任何尖括号，“<”，“>”），后面跟个等号＝，
然后就是该规则的定义。如果规则需要用多个行来描述，