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

另外，服务器不应该把DESCRIBE响应当作媒体重定向的手段。

为了使客户端清楚无误地知道什么时候通过DESCRIBE去请求媒体初始化信息，什么时候不需要，需要建立明确的章程。通过强制要求DESCRIBE响应包含媒体初始化包含它要描述的流集合的所有媒体初始化信息，以及不推荐的媒体间接DESCRIBE用法，我们避免了其他途径可能带来的死循环问题。

媒体初始化是所有基于RTSP的系统的要求，但是RTSP规范没有规定这必须通过DESCRIBE方法来实现。RTSP客户端可以有三种途径来得到初始化信息：

*通过RTSP的DESCRIBE方法；

*通过其他协议（HTTP、email 附件，等等）；

*通过命令行或标准输入（从而像浏览器辅助程序以SDP文件或其他媒体初始化式启动一样工作）。

为方便实际交互，强烈建议在最小服务中包括DESCRIBE方法，同时强烈建议最小客户端支持"辅助程序"这样的功能来从标准输入、命令行，及其他适合客户端工作环境的途径，来接受媒体初始化文件。

10.3 通知（ANNOUNCE）

ANNOUNCE方法有两个目的：

当从客户端发往服务器端，ANNOUNCE向服务器端上传请求URL所标识的表示或媒体对象的描述。当从服务器端发往客户端，ANNOUNCE实时更新会话描述。

当一个新的媒体流加入一个表示（例如：在一个现场表示活动期间）时，整个表示而不仅是所增加的部分，应该被重发，以便部分删除。

例子：

C->S: ANNOUNCErtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq:312

Date:23 Jan 1997 15:35:06 GMT

Session: 47112344

Content-Type: application/sdp

Content-Length: 332

v=0

o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4

s=SDP Seminar

i=ASeminar on the session description protocol

u=http://.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=INIP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio3456 RTP/P 0

m=video2232 RTP/P 31

S->C: RTSP/1.0 200 OK

CSeq:312

10.4 建立（SETUP）

针对一个URI的SETUP详细说明了将要用于流媒体的传输机制。客户端可以针对已开始播放的流发出SETUP请求，来改变传输参数--服务器可能会同意。如果它不同意，它必须响应一个"455 此状态下此方法无效"错误。为便于穿透防火墙，客户端必须指示传输参数，即便它不能影响这些参数，例如：服务器向哪里放固定的多播地址的广告。

由于SETUP包含了所有的传输初始化信息，防火墙和其他中间网络设备（那些需要这些信息的）就不用去解析相对费力些的DESCRIBE响应--DESCRIBE响应是为媒体初始化预留的。

传输头部（Transportheader）详细列出了客户端能接受的数据传输参数；响应中会包含服务器选定的传输参数。

C->S: SETUPrtsp://example.com/foo/bar/baz.rm RTSP/1.0

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