求索阁

rtsp是real time streaming protocol,按照我的理解为流媒体控制协议,协议双方的的编码类型和地址，以及对stream media的控制（play,pause,record).注意这里不要与RTCP协议搞混,rtcp是用来控制rtp的.

下面通过介绍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 <yozo@ipc.chiba-u.ac.jp.>\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的.

PS:这篇是在DR的最后一个项目（全球眼）结束后写的一篇总结。如今看来，却有部分连自己都不懂了。