RTSP协议
RTSP是real time streaming protocol,按照我的理解为流媒体控制协议,协议双方的的编码类型和地址，以及对stream media的控制（play,pause,record).
作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作。
RTSP在制定时较多地参考了 HTTP/1.1协议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。
由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信息，如数据编码/解码算法、网络地址、媒体流的内容等。
rtsp工作流程如下图：
下面通过介绍RTSP的几种方法来说明协议
1:options
这个通常由client发送server,询问服务器所支持的方法种类,当然在应用中也可以用来作为心跳,因为它是状态无关的.例如:
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
服务端发送的200ok里表明服务端支持describe,setup,teardown,play,pause.
在这里可以看到请求和响应的cseq相同,对应后面所有的消息,请求和响应的cseq都是相同的.
2:describe
按照字面意思,就是描述,描述什么呢?当然是流媒体的信息呢,在返回的应答中包含SDP.举个例子
DESCRIBE rtsp://server.address:port/object.sdp RTSP/1.0\r\n
CSeq: 1\r\n
\r\n
-----------------------------------------------------------------------
RTSP/1.0 200 OK\n
Server: QTSS(IFI)/v88\n
Cseq: 1\n
Content-Type: application/sdp\n
Content-Base: rtsp://bildeus.ifi.uio.no:8000/12.sdp/\n
Content-length: 785\n
\n
n=2236805513 2236805513 932036356 224.2.127.254 9875 127 trusted\n
v=0\n
o=yozo 3138827440 3138828177 IN IP4 aohakobe.ipc.chiba-u.ac.jp\n
s=Places all over the world\n
i=Low bandwidth video (10kb/s) with views from all over the world. Audio is primarily for feedback for the senders of video. (looks like there's some problem for the session announcement from sweden distributes to the whole MBone, I'm repeating the announcement from japan. -- yozo.)\n
e=Yozo TODA at IPC, Chiba University, JAPAN <[email protected].>\n
p=+81-43-290-3539\n
c=IN IP4 224.2.213.113/127\n
t=3138827400 3141246600\n
a=tool:sdr v2.6.1\n
a=type:test\n
m=audio 20154 RTP/AVP 0\n
c=IN IP4 224.2.213.113/127\n
a=ptime:40\n
a=control:trackID=1\n
m=video 51482 RTP/AVP 31\n
c=IN IP4 224.2.172.238/127\n
a=control:trackID=2\n
在应答中, 我们重点关注SDP字段.在SDP中,我们看到了流媒体包含了2个资源(m行):audio和video,其中a行是m(media)的属性描述.在m行中,中间的数字为服务端推荐客户端接收的端口,如果服务端不想这样做,可以将port置为0.在sdp中,还有a=control字段,在rfc2326中,对其的解释如下:
The "a=control:" attribute is used to convey the control URL. This
attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URL to be used for
controlling that particular media stream. If found at the session
level, the attribute indicates the URL for aggregate control.
Example:
a=control:rtsp://example.com/foo
This attribute may contain either relative and absolute URLs,
following the rules and conventions set out in RFC 1808 [25].
Implementations should look for a base URL in the following order:
1. The RTSP Content-Base field
2. The RTSP Content-Location field
3. The RTSP request URL
If this attribute contains only an asterisk (*), then the URL is
treated as if it were an empty embedded URL, and thus inherits the
entire base URL.
这里我们对集合控制(aggregate control)进行说明.当服务端支持集合控制,比如对一个音频视频流,它就不需要建立2个session,集合成一个session就ok,如果不支持就得分别建立2个session.我的理解a=control即是对媒体的标识:比如track1表示视频,track2表示音频.在后续的setup中可以看到这点.
通过SDP这些参数我们就可以知道流媒体的编码格式.
3:setup
建立会话,如果支持集合控制,在setup中会包含session字段.下面的消息是支持集合操作的例子.
SETUP rtsp://server.address:port/object.sdp/trackID=1 RTSP/1.0\r\n
CSeq: 2\r\n
Transport: RTP/AVP;unicast;client_port=9000-9001\r\n
\r\n
-------------------------------------------------------------------------
RTSP/1.0 200 OK\n
Server: QTSS(IFI)/v88\n
Cseq: 2\n
Session: 1234567890;timeout=60
Transport: rtp/avp;source=129.240.65.208;server_port=9000-9001;client_port=9000-9001\n
\n
--------------------------------------------------------------------------
SETUP rtsp://server.address:port/object.sdp/trackID=2 RTSP/1.0\r\n
CSeq: 3\r\n
Session: 1234567890\r\n
Transport: RTP/AVP;unicast;client_port=9000-9001\r\n
\r\n
在例子中我们看到,通过setup的响应,即建立了流媒体的会话.后续的setup必须带上session字段,通过上面的消息我们看到客户端发送了2次setup,分别是代表video的track1和audio的track2.如果服务端不支持集合操作,那么setup里带上session字段则是非法的.在消息中,我们看到了transport字段,在这里表明了客户端接收流媒体的端口,以及编码格式.在本例中采用的是udp方式传送RTP,如果采用TCP的方式传送RTP,则可能transport字段为:Transport: RTP/AVP/TCP;unicast;interleaved=0-1 ,这里解释下interleaved,因为采用TCP方式传送,所以传送的RTP,RTCP包都在同一个链路上,需要区分,所以有了interleaved,0表示是RTP的通道,1表示是RTCP的通道.体现在包上面就是在RTP,RTCP包上封装了一层interleaved frame,格式如下:
Magic:0x24
Channel:0x01(表示RTCP)
Length:84
4:play
play 即对流媒体的播放指令:
PLAY rtsp://server.address:port/object.sdp RTSP/1.0\r\n
CSeq: 4\r\n
Session: 1234567890\r\n
\r\n
通常在play中有range字段,但不是必需的.这个字段表示播放的流媒体的范围.
5:teardown
teardown指令即对流媒体的结束
在teardown中是否必须带有session,我们曾经进行过讨论.如果一个session对应一个链路,则可以不需要对应session,但是在我们遇到的应用中,teardown基本都是携带了teardown.谈到这里,我们说下RTSP的几种连接类型:
* persistent transport connections used for several request-response transactions
* one connection per request/response transaction;
* connectionless mode.
对几种基本的消息的介绍就到这里了,我们现在来谈谈RTSP的状态机.其实RTSP的状态机很简单,不像sip协议那么复杂.对应很多消息,是状态无关的.现在这里只介绍与服务器相关的状态机:
state message received next state
Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
SETUP Ready
TEARDOWN Init
RECORD Recording
Playing PLAY Playing
PAUSE Ready
TEARDOWN Init
SETUP Playing
Recording RECORD Recording
PAUSE Ready
TEARDOWN Init
SETUP Recording
通过上面的表,我们就可以知道消息的发送必须是有序的,比如还没有发送setup,就不能发送play.还有连续2次的pause肯定是错误的.在这个状态机中,是没有结束的,我们通常teardown后一个会话就会结束,甚至会关闭链路.但是在上图中又回到了init状态,我对此有些迷惑,这里又要提到了上面我们讨论的话题:teardown是否该带session,在这个状态机中,在任何阶段都可以接收teardown,比如init阶段,这个阶段是没有session的.