流媒体协议之RTSP详解20170922
一、RTSP协议介绍
1.什么是rtsp?
RTSP协议以客户服务器方式工作，，如：暂停/继续、后退、前进等。它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制,
因此 RTSP 又称为“因特网录像机遥控协议”。
RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。
是TCP/IP协议体系中的一个应用层协议, 由哥伦比亚大学, 网景和RealNetworks公司提交的IETF RFC标准. 对应的RFC编号是2326，可以在这里搜索 RFC Editor
该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据. RTSP在体系结构上位于RTP和RTCP之上, 它使用TCP或RTP完成数据传输. RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。
媒体数据的传送可通过RTP/RTCP等协议来完成。
该协议用于C/S模型, 是一个基于文本的协议, 用于在客户端和服务器端建立和协商实时流会话.
虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个 RTSP连接期间，
RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。
2.网络体系
RTSP是类似http的应用层协议，一个典型的流媒体框架网络体系可参考下图:
3.一次基本的RTSP操作过程
1).首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。
2).流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
3).客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，
4).客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。
5).最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话
sequenceDiagram
客户端->>服务器:DESCRIBE
服务器->>客户端: 200 OK (SDP)
客户端->>服务器:SETUP
服务器->>客户端: 200 OK
客户端->>服务器:PLAY
服务器->>客户端: (RTP包)
4.协议特点
1).可扩展性: 新方法和参数很容易加入RTSP.
2).易解析: RTSP可由标准HTTP或MIME解析器解析.
3).安全: RTSP使用网页安全机制.
4).独立于传输: RTSP可使用不可靠数据报协议(EDP), 可靠数据报协议(RDP); 如要实现应用级可靠, 可使用可靠流协议.
5).多服务器支持: 每个流可放在不同服务器上, 用户端自动与不同服务器建立几个并发控制连接, 媒体同步在传输层执行.
6).记录设备控制: 协议可控制记录和回放设备.
7).流控与会议开始分离: 仅要求会议初始化协议提供, 或可用来创建惟一会议标识号. 特殊情况下, 可用SIP或H.323来邀请服务器入会.
8).适合专业应用: 通过SMPTE时标, RTSP支持帧级精度, 允许远程数字编辑.
9).演示描述中立: 协议没强加特殊演示或元文件, 可传送所用格式类型; 然而, 演示描述至少必须包括一个RTSP URL.
10).代理与防火墙友好: 协议可由应用和传输层防火墙处理. 防火墙需要理解SETUP方法, 为UDP媒体流打开一个“缺口”.
11).HTTP友好: 此处, RTSP明智地采用HTTP观念, 使现在结构都可重用. 结构包括Internet内容选择平台(PICS). 由于在大多数情况下控制连续媒体需要服务器状态, RTSP不仅仅向HTFP添加方法.
12).适当的服务器控制: 如用户启动一个流, 必须也可以停止一个流.
13).传输协调: 实际处理连续媒体流前, 用户可协调传输方法.
14).性能协调: 如基本特征无效, 必须有一些清理机制让用户决定哪种方法没生效. 这允许用户提出适合的用户界面.
5.RTSP协议与HTTP协议区别
1).RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；
2).HTTP是无状态的协议，而RTSP为每个会话保持状态；
3).RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTPF 协议中，只有客户端能发送Request请求。
4).在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。
5).使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化；
6).RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中；
二、RTSP重要术语
1. 集合控制(Aggregatecontrol ):
对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。
2. 实体(Entity)：
作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成
3. 容器文件（Containerfile）：
可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。
4. RTSP会话(RTSP session )：
RTSP交互的全过程。对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。
三、RTSP 的报文结构
1.RTSP URL的语法结构
一个终端用户是通过在播放器中输入URL地址开始进行观看流媒体业务的第一步，而对于使用RTSP协议的移动流媒体点播而言，URL的一般写法如下：
一个以“rtsp”或是“rtspu”开始的URL链接用于指定当前使用的是RTSP 协议。RTSP URL的语法结构如下：
rtsp_url = (“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
host：可以是一个有效的域名或是IP地址。
port：端口号，对于RTSP协议来说，缺省的端口号为554。当我们在确认流媒体服务器提供的端口号为554时，此项可以省略 说明：当HMS服务器使用的端口号为554时，我们在写点播链接时，可以不用写明端口号，但当使用非554端口时，在RTSP URL中一定要指定相应的端口。
abs_path: 为RTSPServer中的媒体流资源标识
RTSPURL用来标识RTSPServer的媒体流资源，可以标识单一的媒体流资源，也可以标 识多个媒体流资源的集合。
2.RTSP的报文结构
RTSP是一种基于文本的协议，用CRLF作为一行的结束符。使用基于文本协议的好处在于我们可以随时在使用过程中的增加自定义的参数，也可以随便将协议包抓住很直观的进行分析。
RTSP有两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。
由于 RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。
RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行.
2.1.请求报文
请求报文的结构如下图所示
也就是说：
方法 URI RTSP版本 CR LF
消息头 CR LF CR LF
消息体 CR LF
1).请求消息的第一行的语法结构如下：
Request-Line = Method 空格 Request-URI 空格 RTSP-Version CRLF
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，
2).在消息头中除了第一行的内容外，还有一些需求提供附加信息。其中有些是一定要的，后续我们会详细介绍经常用到的几个域的含义。
消息头 = Accept
| Accept-Encoding
| Accept-Language
| Authorization
| From
| If-Modified-Since
| Range
| Referer
| User-Agent
3).最后一个消息头需要有两个CR LF。消息体是可选的，有的Request消息并不带消息体。
2.2.响应报文
响应报文的开始行是状态行，RTSP响应报文的结构如下图所示
也就是说：
RTSP版本状态码解释 CR LF
消息头 CR LF CR LF
消息体 CR LF
1).响应消息的第一行是状态行（status-line），每个元素之间用空格分开。除了最后的CRLF之外，在此行的中间不得有CR或是LF的出现。它的语法格式如下，
Status-Line = RTSP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
状态码（Status-Code） 是一个三位数的整数，用于描述接收方对所收到请求消息的执行结果，
Status-Code的第一位数字指定了这个回复消息的种类，一共有5类：
1XX: Informational – 请求被接收到，继续处理
2XX: Success – 请求被成功的接收，解析并接受
3XX: Redirection – 为完成请求需要更多的操作
4XX: Client Error – 请求消息中包含语法错误或是不能够被有效执行
5XX: Server Error – 服务器响应失败，无法处理正确的有效的请求消息
我们在处理问题时经常会遇到的状态码有如下：
| | |
---|---|---|---|--- Status-Code | = |“200”| : OK . || | “400”| : Bad Request . || | “404”| : Not Found . || | “500”| : Internal Server Error
2).在响应消息的域中存放的是无法放在Status-Line中,而又需要传送给请求者的一些附加信息。
消息头 = Location
| Proxy-Authenticate
| Public
| Retry-After
| Server
| Vary
| WWW-Authenticate
3.RTSP的主要方法
|
方法 |
方向 |
对象 |
要求 |
含义 |
|
DESCRIBE |
C->S |
P,S |
推荐 |
检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式。DESCRIBE的答复-响应组成媒体RTSP初始阶段 |
|
ANNOUNCE |
C->S S->C |
P,S |
可选 |
当从用户发往服务器时，ANNOUNCE将请求URL识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE实时更新连接描述。如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除 |
|
GET_PARAMETER |
C->S S->C |
P,S |
可选 |
GET_PARAMETER请求检查RUL指定的演示与媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况 |
|
OPTIONS |
C->S S->C |
P,S |
要求 |
可在任意时刻发出OPTIONS请求，如用户打算尝试非标准请求，并不影响服务器状态 |
|
PAUSE |
C->S |
P,S |
推荐 |
PAUSE请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在SETUP消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订 |
|
PLAY |
C->S |
P,S |
要求 |
PLAY告诉服务器以SETUP指定的机制开始发送数据；直到一些SETUP请求被成功响应，客户端才可发布PLAY请求。PLAY请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY请求可排成队列，服务器将PLAY请求排成队列，顺序执行 |
|
RECORD |
C->S |
P,S |
可选 |
该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201（创建），并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte格式没有意义 |
|
REDIRECT |
S->C |
P,S |
可选 |
重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求 |
|
SETUP |
C->S |
S |
要求 |
对URL的SETUP请求指定用于流媒体的传输机制。客户端对正播放的流发布一个SETUP请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响 |
|
SET_PARAMETER |
C->S S->C |
P,S |
可选 |
请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示 |
|
TEARDOWN |
C->S |
P,S |
要求 |
TEARDOWN请求停止给定URL流发送，释放相关资源。如URL是此演示URL，任何RTSP连接标识不再有效。除非全部传输参数是连接描述定义的，SETUP请求必须在连接可再次播放前发布 |
注：P---演示，C---客户端,S---服务器， S（对象栏）---流
信令指的是在Request-URI中指定的需要被接收者完成的操作。信令（The method）大小写敏感，不能以字符”$”开始，并且一定要是一个标记符。
4.RTSP重要头字段参数
1).Accept: 用于指定客户端可以接受的媒体描述信息类型。比如: Accept: application/rtsl, application/sdp;level=2
2).Bandwidth: 用于描述客户端可用的带宽值。
3).CSeq： 指定了RTSP请求回应对的序列号，在每个请求或回应中都必须包括这个头字段。对每个包含一个给定序列号的请求消息，都会有一个相同序列号的回应消息。
4).Rang： 用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元。
5).Session: Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的，客户端一当得到Session ID后，在以后的对Session 的操作请求消息中都要包含Session ID.
6).Transport: Transport头字段包含客户端可以接受的转输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如: Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
四、简单的RTSP消息交互过程
C表示RTSP客户端,S表示RTSP服务端
1.第一步：查询服务器端可用方法
C->S OPTION request //询问S有哪些方法可用
S->C OPTION response //S回应信息的public头字段中包括提供的所有可用方法
2.第二步：得到媒体描述信息
C->S DESCRIBE request //要求得到S提供的媒体描述信息
S->C DESCRIBE response //S回应媒体描述信息，一般是sdp信息
3.第三步：建立RTSP会话
C->S SETUP request //通过Transport头字段列出可接受的传输选项，请求S建立会话
S->C SETUP response //S建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;
4.第四步：请求开始传送数据
C->S PLAY request //C请求S开始发送数据
S->C PLAY response //S回应该请求的信息
5.第五步： 数据传送播放中
S->C 发送流媒体数据 // 通过RTP协议传送数据
6.第六步：关闭会话，退出
C->S EARDOWN request //C请求关闭会话
S->C TEARDOWN response //S回应该请求
上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。
其中第三和第四步是必需的！第一步，只要服务器和客户端约定好有哪些方法可用，则option请求可以不要。第二步，
如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。
五、RTSP的请求响应示例
其中C是客户端，S是服务端。
1. OPTIONS:
用于得到服务器提供的可用方法；
如:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1
服务器的回应信息会在Public字段列出提供的方法。如:
RTSP/1.0 200 OK
CSeq: 1 //每个回应消息的cseq数值和请求消息的cseq相对应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
2. DESCRIBE：
客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。
如：
C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,application/mheg)
服务器回应URI指定媒体的描述信息:
如:
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp //表示回应为SDP信息
Content-Length: 376
//这里为一个空行
//以下为具体的SDP信息
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
//字段解释
V=0 ;Version 给定了SDP协议的版本
o=<username><session id> <version> <network type> <address type>
<address>； Origin ,给定了会话的发起者信息
s=<sessionname> ;给定了Session Name
i=<sessiondescription> ; Information 关于Session的一些信息
u=<URI> ; URI
e=<emailaddress> ;Email
c=<networktype> <address type> <connection address> ;Connect Data包含连接数据
t=<start time><stop time> ;Time
a=<attribute> ; Attribute
a=<attribute>:<value>
m=<media><port> <transport> <fmt list> ; MediaAnnouncements
媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过以下方法来接收媒体描述信息：
a) 通过DESCRIBE方法；
b) 其它一些协议（HTTP，email附件，等）；
c) 通过命令行或标准输入设备
另一个例子：
命令名称：DESCRIBE
命令作用：请求SDP
命令格式：
DESCRIBE<BLANK><RTSP URI><BLANK>RTSP/<RTSP VERSION>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n\r\n
（Note：<BLANK>：空格；<COMMAND SEQUENCE>：命令序列，每一次发送命令该数字加1）
命令示例：
DESCRIBE rtsp://127.0.0.1/ansersion RTSP/1.0
CSeq: 1
（Note：虽然看不见，但示例中最后是有空行的，必不可少哦！看看“命令格式”最后连着两个"\r\n"你就明白了。空行（\r\n）是RTSP数据包的结束标识。）
服务端返回信息格式：
RTSP/<RTSP VERSION><BLANK><STATE ID><BLANK><STATE DESCRIBE>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n<OTHER>\r\n\r\n<SDP>
（Note：<OTHER>: 其他描述信息；<SDP>: SDP描述信息，SDP不属于RTSP的打包数据，这里可以看到空行（\r\n）在SDP之前）
服务端返回信息示例：
RTSP/1.0 200 OK
CSeq: 1
Date: Sun, Dec 27 2015 02:16:50 GMT
Content-Base: rtsp://127.0.0.1/ansersion/
Content-Type: application/sdp
Content-Length: 510
v=0
o=- 1451182595570866 1 IN IP4 192.168.81.145
s=Session streamed by "testOnDemandRTSPServer"
i=ansersion
t=0 0
a=tool:LIVE555 Streaming Media v2015.11.09
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"
a=x-qt-text-inf:ansersion
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D4033;sprop-parameter-sets=Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==,aO48gA==
a=control:track1
（Note：以RTSP客户端的角度，以上红字部分信息必须理解。
首先是"RTSP/1.0 200 OK"，这个表示RTSP服务端成功受理客户端的请求。
再者是“m=video 0 RTP/AVP 96”，该信息指出了RTSP客户端提供传输的流媒体类型，“a=control:track1”指出了访问该流媒体的方式，是后续SETUP命令的重要参数，这是一个简化的版本，有时候服务端会返回完整版本：“a=control:rtsp://127.0.0.1/ansersion/track1”。
最后是“Z01AM5JUDAS0IAAAAwBAAAAM0eMGVA==”和“aO48gA==”，这是H264的SPS和PPS的Base64编码。老实说，要让RTSP客户端去考虑具体编码格式的问题，着实是一个设计上的瑕疵。后续我打算把这部分改掉，现在我们将其看作H264的重要参数即可）
在SDP中也说明了本次会话的属性
SDP 参数
下面描述了如何在 SDP 中表示一个 H.264 流:
. "m=" 行中的媒体名必须是 "video"
. "a=rtpmap" 行中的编码名称必须是 "H264".
. "a=rtpmap" 行中的时钟频率必须是 90000.
. 其他参数都包括在 "a=fmtp" 行中.
如:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
下面介绍一些常用的参数.
1). packetization-mode:
表示支持的封包模式.
当 packetization-mode 的值为 0 时或不存在时, 必须使用单一 NALU 单元模式.
当 packetization-mode 的值为 1 时必须使用非交错(non-interleaved)封包模式.
当 packetization-mode 的值为 2 时必须使用交错(interleaved)封包模式.
每个打包方式允许的NAL单元类型总结(yes = 允许, no = 不允许, ig = 忽略)
Type Packet Single NAL Non-Interleaved Interleaved
Unit Mode Mode Mode
-------------------------------------------------------------
0 undefined ig ig ig
1-23 NAL unit yes yes no
24 STAP-A no yes no
25 STAP-B no no yes
26 MTAP16 no no yes
27 MTAP24 no no yes
28 FU-A no yes yes
29 FU-B no no yes
30-31 undefined ig ig ig
这个参数不可以取其他的值.
2). sprop-parameter-sets: SPS,PPS
这个参数可以用于传输 H.264 的序列参数集和图像参数 NAL 单元. 这个参数的值采用 Base64 进行编码. 不同的参数集间用","号隔开.
3).profile-level-id:
这个参数用于指示 H.264 流的 profile 类型和级别. 由 Base16(十六进制) 表示的 3 个字节. 第一个字节表示 H.264 的 Profile 类型, 第三个字节表示 H.264 的 Profile 级别:
4).max-mbps:
这个参数的值是一个整型, 指出了每一秒最大的宏块处理速度.
3. SETUP：
用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。
Request中的Transport头字段指定了客户端可接受的数据传输参数；Response中的Transport 头字段包含了由服务器选出的传输参数。
如:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
服务器端对SETUPRequest产生一个Session Identifiers。
如:
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 //产生一个SessionID
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
另一个例子:
命令名称：SETUP
命令作用：建立流媒体会话，告知RTSP服务端准备资源，以待后续进一步操作（比如“PLAY”）
命令格式：
SETUP<BLANK><RTSP URI>/<SDP ATTRIBUTE CONTROL>RTSP/<RTSP VERSION>\r\nTransport:<BLANK><PROTOCOL>;<CAST METHOD>;client_port=<RTP PORT>-<RTCP PORT>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n\r\n
（Note：<SDP ATTRIBUTE CONTROL>：SDP中“a=control:track1”；<PROTOCOL>：实时流传输协议，一般为RTP+UDP；<CAST METHOD>：传输方式，单播或组播；）
命令示例：
SETUP rtsp://127.0.0.1/ansersion/track1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10330-10331
CSeq: 2
（Note：使用RTP传输（RTP/AVP/UDP），传输方式为单播（unicast），RTP和RTCP的端口号分别为10330和10331（client_port=10330-10331））
服务端返回信息格式：
RTSP/<RTSP VERSION><BLANK><STATE ID><BLANK><STATE DESCRIBE>\r\nCSeq:<BLANK><COMMAND SEQUENCE>\r\n<OTHER>\r\n<SESSION ID>\r\n\r\n
（Note：<SESSION ID>：服务端建立好资源后，通过该标识访问其媒体流资源。）
服务端返回信息示例：
RTSP/1.0 200 OK
CSeq: 2
Date: Sun, Dec 27 2015 02:28:01 GMT
Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=10330-10331;server_port=6970-6971
Session: ABF519D9;timeout=65
（Note：其中“ABF519D9”为SESSION ID，PLAY命令以此为参数，告知服务端以SETUP命令中指定的方式（RTP、unicast、client_port=10330-10331）进行媒体流传输）
4. PLAY：
PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。
PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；
服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。
比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。
不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（the pause point）重新开始。如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。
5. PAUSE：
PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。
比如，指定暂停音频，播放将会无声。如果请求URL指定了一组流，那么在该组中的所有流的传输将被暂停。如：
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
PAUSE请求中可能包含一个Range头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pause point）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。
当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。
如果Range头指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invalid Range" 。
如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。
如果Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。
6. TEARDOWN：
TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。如：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
六、参考的原文:
https://github.com/EasyDarwin/Course/tree/master/流媒体开发实战进阶(RTSP视频播放器)
http://blog.csdn.net/leixiaohua1020/article/details/11955341
http://blog.csdn.net/pu1030/article/details/7619908
http://www.cnblogs.com/ansersion/p/5079758.html
http://blog.csdn.net/ajiva/article/details/276909
http://www.rfc-editor.org/info/rfc2326
http://blog.csdn.net/zblue78/article/details/5948538
