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

a=control:rtsp://audio.com/movie.aud

m=audio 8004RTP/P 3

a=control:rtsp://video.com/movie.vid

注意：描述中控制URL的位置暗示客户端要分别建立到服务器audio.com 和 video.com的RTSP控制会话。

推荐在SDP文件中包含完整的媒体初始化信息，即使SDP是通过非RTSP途径传送到媒体客户端的。这是有必要的，因为没有机制可以指示客户端应该通过DESCRIBE请求更多媒体流细节信息。

C.3 合控制有效

此种前提下，服务器有可以被当作一个整体控制的多个流。在此情况下，就即有用于给出流URL的媒体级"a=control:"属性，又有用作合控制的请求URL的会话级"a=control:"。如果媒体级URL是相对URL，它将根据上文C1.1节所述被处理为绝对URL。

如果表示只由单个流组成，媒体级"a=control:"将被全部忽略。但是，如果表示包含多于一个流，每个媒体流部分【必须】包含自己的"a=control:"属性。

例子：

v=0

o=- 28908442562890842807 IN IP4 204.34.34.32

s=I contain

i=<moreinfo>

t=0 0

c=IN IP4 0.0.0.0

a=control:rtsp://example.com/movie/

m=video 8002RTP/P 31

a=control:trackID=1

m=audio 8004RTP/P 3

a=control:trackID=2

在此实例里，客户端被要求建立一个到服务器的RTSP会话，并用分别用URL rtsp://example.com/movie/trackID=1 和rtsp://example.com/movie/trackID=2建立视频和音频流。URL rtsp://example.com/movie/控制整个电影。

附录D：最小RTSP实现

D.1 客户端

客户端实现【必须】能够做到如下几点：

*生成下列请求：SETUP,TEARDOWN, 和 PLAY (意即, 一个最小回放客户端) 或 RECORD (意即, 一个最小录制客户端)。如果RECORD被实现，ANNOUNCE【必须】也被实现。

*在请求中包含下列头部：CSeq, Connection, Session, Transport。如果ANNOUNCE 被实现，也应该实现包含Content-Language, Content-Encoding,Content-Length, 及 Content-Type 头部的能力。

*解析并理解下列响应中的头部：CSeq,Connection,Session, Transport, Content-Language, Content-Encoding, Content-Length,Content-Type。如果实现了RECORD，则也必须理解Location头部。RTP-compliant（RTP适用的）实现应该再实现RTP-Info。

*如果收到一个型别为4xx或5xx的错误代码，理解所收到错误代码的型别并通知最终用户。如果最终用户明确指出不想要一个或所有状态码的产生条件，则可以不进行通知。

虽然不是必需，但为了便于实际中同早期实现协同工作且/或成为“好市民”，在发布时仍强烈推荐实现下述功能。

* 实现 RTP/P/UDP ，使其成为有效 transport.

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