rtsp协议 编码_海康rtsp协议_http 协议(6)

多播，用户选择地址：

若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。

1.7 RTSP状态

RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。

RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.

SETUP：

让服务器给流分配资源，启动RTSP会话。

PLAY与RECORD：

启动SETUP所分配的流的数据传输。

PAUSE：

临时暂停流，而不释放服务器资源。

TEARDOWN：

释放流占用的资源，RTSP会话停止，从服务器端退出。

与状态相关的RTSP方法使用会话头部域（Sessionheader field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节10.4)的响应中，服务器生成会话标识。

1.8 与其他协议关系

RTSP在功能上与HTTP有重叠。它也可能与HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述(presentation description)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立RTSP 服务器与客户端。

但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。

重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价的。

虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。

RTSP假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述式。

2 符号约定

既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）

与[H2.1]类，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。

********************

简单说明增广BNF如下：

增广BNF（augmented BNF）包括下面的结构：

要解释的名词＝名词解释（name= definition）

规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空进行缩进式排版。某些基本的规则使用大写，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定义中还可以使用尖括号来帮助理解规则名的使用。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-47669-6.html