RTSP协议介绍

协议的方法介绍
Page 7
协议的方法介绍
Page 8
RTSP 消息流程
CS 414 - Spring 2009
RTSP Presentation by H. Schulzrinne, 2001
消息语法
• RTSP消息由请求和响应组成。
• 请求消息=请求头+[头域]+[消息体] • 响应消息=状态头+[头域]+[消息体] • 消息体和头域之间用空行（0d0a）分隔 • 请求/状态头以及每个头域都占据一行，以 0d0a结束
Page 17
REDIRECT
• 服务器通过这个请求，告诉客户端应该请求另外一个位置的媒体。 REDIRECT请求携带Location头域，以便告诉客户端新的位置。同时还携 带Range头域，告诉客户端什么时候开始重定向。如下例子是服务器给客 户端发REDIRECT请求： REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 732 Location: rtsp://bigserver.com:8001 Range: clock=19960213T143205Z这个请求让客户端于1996年2月13日14：32：05开始重定向到服务器 bigserver.com:8001。
RTSP协议介绍
第1章 RTSP协议介绍 第2章 SDP介绍 第3章 RTP/RTCP介绍
Page 2
基本概念
• 实时流媒体协议：RTSP 一般作为媒体信道的远程控制使用,不参与媒体数据传输, 也不做媒体的解析. • 实时协议：RTP/RTCP RTP:按照RTP分组的方式传输媒体数据，协议规定了排 序/丢包检查/以及媒体重建信息。媒体特定信息说明，包 括其重建、解释有应用文档规定。 RTCP:作为质量控制，成员控制等功能。 • 会话描述协议：SDP 在会话级别、媒体级别来描述传输媒体的具体信息，不参 与传输 • 媒体净荷应用文档 规定了特定的媒体的处理信息
Page 16
TEARDOWN
• • • •
• • • • • •
TEARDOWN请求结束播放，服务器释放已经分配的资源。结束之后， session id不再有效。如下面例子所示： 客户端请求： TEARDOWN rtsp://192.168.1.100:554/pinball.wmv RTSP/1.0 User-Agent: WMPlayer/9.0.0.2991 guid/3300AD50-2C39-46C0-AE0A79C1934B364D Accept-Charset: UTF-8, *;q=0.1 X-Accept-Authentication: Negotiate, NTLM, Digest, Basic Accept-Language: en-us, *;q=0.1 Session: 4301725529333472257 CSeq: 9 X-Playlist-Gen-Id: 16
Audio Video Decoder RTP CLIENT
Session Control RTSP RTSP
Audio video Coder RTP
SERVER
CS 414 - Spring 2009
Streaming Media: RTSP
CS 414 - Spring 2009
RTSP Presentation by H. Schulzrinne, 2001
CS 414 - Spring 2009
•
•
第1章 RTSP协议介绍 第2章 SDP介绍 第3章 RTP/RTCP介绍
Page 23
实时传输协议RTP
• RTP（Real-time Transport Protocol）是用于 同步传输实时多媒体数据流的一种传输协议。 • RTP被定义为在一对一或一对多的传输情况下 工作，其目的是提供时间信息和实现流同步。 • RTP通常使用UDP来传送数据，但RTP也可以 在TCP或ATM等其他协议之上工作。 • 当应用程序开始一个RTP会话时将使用两个端 口：一个给RTP，一个给RTCP。 • RTP本身并不能为按顺序传送数据包提供可靠 的传送机制，也不提供流量控制或拥塞控制， 它依靠RTCP提供这些服务。
Page 12
SETUP
• • • • • • • •
请求服务器给流分配资源，启动RTSP会话。SETUP请求包含所有的传输初 始化信息。在Transport头域指定了客户端可以接受的数据传输参数，而服务 器的响应会包含服务器选择的传输参数。 如客户端请求： SETUP rtsp://192.168.1.100:554/powered_by_100.wmv/video RTSP/1.0 CSeq:0 Transport:RTP/AVP/TCP;unicast;interleaved=45;ssrc=9440ecec;mode=PLAY Supported:com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, com.microsoft. wm.packetpairssrc 在该请求的响应中，服务器产生会话id，在Session头域携带该信息，而如 果SETUP请求已经携带Session id，服务器必须处理这个Session id，加入 已经存在的Session里面
Page 14
PLAY
• • • • • • • •
PLAY方法请求服务器使用SETUP建立的机制开始发送数据，客户端不能 在SETUP成功之前发送PLAY请求，因为RTSP是一个有状态协议。 PLAY请求通过Range头域设置了正常播放时间（NPT），播放从Range指 定的开始位置开始播放，直到Range指定的结束位置结束播放。不带 Range头也是正常的请求，表示从内容开始处开始播放，直到遇到暂停。 如客户端请求： PLAY rtsp://audio.example.com/audio RTSP/1.0 CSeq: 835 Session: 12345678 Range: npt=10-15 该例子使用npt来指定播放范围。此外还可以使用SMPTE相对时间戳 、 clock 绝对时间
SDP实例பைடு நூலகம்
• v=0 //以下都是sdp信息 o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136 s=/xxx666 u=http:/// e=admin@ c=IN IP4 0.0.0.0 t=0 0 a=isma-compliance:1,1.0,1 a=range:npt=0m=video 0 RTP/AVP 96 //m表示媒体描述，下面是对会话中视频通道的媒体 描述 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-levelid=245;config=000001B0F5000001B509000001000000012000C888B0E0E 0FA62D089028307 a=control:trackID=0//trackID＝0表示视频流用的是通道0
• • • • •
Page 18
RECORD
• • • • • • • RECORD请求服务器录播一段内容，时间戳反映了开始时间和结束时间，格 式是UTC。RECORD请求可以没有时间范围，默认使用内容开始时间和结束 时间。 服务器决定是否使用请求的URI或者另外一个URI来存储内容。如果服务器没 有使用请求URI，服务器返回201（已产生），携带Location头域指定位置， 而且在实体中描述新资源。 如客户端请求服务器： RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 CSeq: 954 Session: 12345678 Conference: 128.16.64.19/32492374
Page 15
PAUSE
• • • • • • • • • •
PAUSE请求暂停播放内容，PAUSE可以携带Range头域，但是不能是一个 范围，而是一个时间点，也就是一个精确的值。如果Range头域不存在，则 立刻停止播放，把停顿点设置成当前时间。 如下是一个PAUSE请求的例子： 客户端请求： PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 834 Session: 12345678 服务器响应： RTSP/1.0 200 OK CSeq: 834 Date: 23 Jan 1997 15:35:06 GMT
Page 11
DESCRIBE
• • • • • • • •
DESCRIBE方法请求得到URI对应的对象或表示的描述，客户端可以使 用Accept头域声明它可以接受的格式。服务器返回被请求资源的描述， DESCRIBE和响应构成了RTSP的媒体初始化阶段。 下面例子说明DESCRIBE的使用。客户端请求服务器描述某个URI对应 的资源。 客户端请求： DESCRIBE rtsp://1.0.7.93:18554/2/asdf/movies/hory_poter.mp4?accounttype=1&ac countinfo=0 RTSP/1.0 CSeq:1 Require:implicit-play Accept:application/sdp, application/rtsl, application/mheg 服务器在成功响应描述请求时，必须包含所有的媒体初始化信息。
Page 10
OPTION
• • • • • • • • • • • • • •
当客户端想进行非标准请求，可以通过OPTIONS请求，请求获得服务器的能力。 OPTIONS在任何时候都可以向服务器请求，而且不会改变服务器的状态。 下面是一个OPTIONS请求的例子，客户端请求服务器的能力。 客户端请求： OPTIONS * RTSP/1.0 CSeq:1 Require:implicit-play Proxy-Require:gzipped-messages 服务器响应： RTSP/1.0 200 OK Server: MDN_HWPSS CSeq: 0 Session: 1729556035 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, RECORD 该服务器是Huawei Technologies Co., Ltd. IPTV系统中的HMS流媒体服务器。
Page 13
SETUP补充
• • • • • • • •
与SIP的SDP交互不同，一般来说RTSP在SETUP的请求响应过程中，通过 Transport字段交换服务器、客户端的媒体IP地址、端口 Transport指示使用的传输协议，以及配置相关参数，如目的地址，压缩方式 、端口等； transport/profile（框架定义）/lower-transport； destination目的地址 client_port目的端口 source流的源地址 interleaved媒体流和控制流混合发送，指定要交织的通道数， 交织格式：媒体数据被封装以$符号（0x24），后跟一字节的通道标识，两 字节的长度（网络字节序），媒体流
Page 19
第1章 RTSP协议介绍 第2章 SDP介绍 第3章 RTP/RTCP介绍
Page 20
RTSP-SDP
• RTSP中的SDP与SIP不同，一般是单向的 • 由服务器在客户端的Describe消息的200响 应中协议带 • 因此SDP一般不能描述服务器、客户端的 媒体地址和端口，只能描述媒体的类型以 及Profile-Level等详细信息
协议栈层次
1：RTP/RTCP推荐在UDP上承载，RTSP推荐在TCP上承载； 2：应用文档作为承载在RTP上，负责对具体的媒体进行解释； 3：SDP承载RTSP上，负责媒体会话的会话级、媒体级解释。
示例
• 一种控制媒体流的应用层协议 • RTSP 本身不负责媒体流传送,只负责客户端与服务 端之间的控制