实时流协议(RTSP),英文全称为Real Time Streaming Protocol。它是一个用来获取所需要属性(编码方式、分辨率或者帧率等)实时流以及控制实时流的应用层协议。
RTSP是一个基于文本的协议，它与HTTP十分相似。在RTSP中，保留了几乎所有的HTTP符号以及相关定义。所以，RTSP十分利于扩展，并且容易使用程序进行解析。
RTSP虽然可以用来获取实时流，但是协议中并没有定义传输实时流的方式。它通过与其它的传输机制配合，例如RTP，进行实时流传输。在RTSP中，我们可以在SETUP方法中设置一些参数，以选择是用TCP还是用UDP作为RTP的底层传输协议。
RTSP通过以会话(Session)的方式描述一个连接的生命周期。会话(Session)通过RTSP客户端使用RTSP的SETUP方法建立，然后RTSP客户端可以通过PLAY、PAUSE、RECORD等方法(Method)来控制实时流的播放、暂停以及回放等。当不再需要实时流的时候，RTSP客户端通过TEARDOWN方法(Method)来结束这个会话(Session)。
1.url
RTSP通过与HTTP相似的方式来定义URL，RTSP完整的URL定义如下：
rtsp URL = ( ”rtsp:” | ”rtspu:” | ”rtsps:” ) ”//” host [ ”:” port ] [ abs path ]
rtsp = 使用可信的底层传输协议，例如TCP
rtspu = 使用不可信的底层传输协议，例如UDP
rtsps = 使用可信加密传输协议，例如TCP + TLS
host = 服务器的IP地址
port = 服务器的端口,该字段在忽略的情况下默认与服务器的554端口进行连接
abs path = 所申请实时流的地址
一个简单的示例如下：
rtsp://media.example.com:554/twister/audiotrack
让我们来看一下上面URL的abs path = twister/audiotrack。twister表示一个标识(Presentation)
，标识(Presentation)由一个或多个实时流组成。audiotrack表示标识(Presentation)中其中一个实时流的名称。从这个名称可以看出，我们要取的是一个音频流。如果abs
path = twister/videotrack，则表示我们要取的是twister的视频流。有的服务器也支持下面的URL形式：
rtsp://media.example.com:554/twister
该URL表示取标识(Presentation)的视频流和音频流。
2.Request
与URL相似，RTSP也有与HTTP相似的请求(Request)定义。完整的RTSP请求(Request)定义如下：
Request = Request-Line
*( general-header |
request-header |
entity-header )
CRLF
[ message-body ]
接下来让我们来看一下请求(Request)中每一部分的定义。
Request-Line =
Method SP Request-URI
SP RTSP-Version CRLF
Method = OPTIONS |
DESCRIBE |
SETUP |
PLAY |
TEARDOWN |
…
SP = 空格
Request-URI = RTSP服务器的URI
RTSP-Version = RTSP的版本号
CRLF = 回车换行
一个简单的Request-Line的示例如下所示：
OPTIONS rtsp://192.168.10.115/live.sdp RTSP/1.0
general-header = Cache-Control |
Connection |
Date |
Via
这个头在我所见应用(VLC)的请求(Request)过程中一般是忽略的。在RTSP服务器的回应(Response)中，一般也只会出现该头的Date字段。示例如下：
Date: Mon, 25 Oct 2010 11:0:22 GMT
request-header = Accept |
Authorization |
User-Agent |
…
Accept = RTSP服务器在响应(Response)的时候通过什么方式说明实时流的属性。一般这个填写application/sdp，表示RTSP客户端希望通过会话描述协议(SDP) 来了解流的属性。
Authorization = 通过BASE64或者DIGEST加密的用户名和密码。
User-Agent = 代理的名称，这个值随便填写什么都可以。
示例如下：
Accept: application/sdp
User-Agent:Netposa
3.response
响应(Response)定义如下：
Response = Status-Line |
*( general-header |
response-header |
entity-header）
CRLF
[ message-body ]
Status-Line = RTSP-Version SP Status-Code SP
Reason-Phrase CRLF
Status-Code = 表示Request的结果。例如200表示成功，400表示失败
Reason-Phrase = 回复结果的文本说明。例如成功的时候为OK
示例如下：
RTSP/1.0 200 OK
response-header = Public | …
Public = 表示RTSP服务器所支持的方法
这个头在实际应用的响应(Response)中一般是很少出现的。只有在OPTIONS方法(Method)的响应中，才会出现。示例如下：
Public: OPTIONS, DESCRIBE, PLAY, SETUP, TEARDOWN
entity-header = Content-Base |
Content-Length |
Content-Type |
…
Content-Base = [ message-body ]中的信息来源。例如rtsp://192.168.10.115/live.sdp/，表示信息来自于一个文件 Content-Type = [ message-body ] 中的信息使用什么方式组织。例如application/sdp，表示使用SDP组织
Content-Length = [ message-body ]的长度
示例如下：
Content-Base: rtsp://192.168.10.115/live.sdp/
Content-Type: application/sdp
Content-Length: 431
message-body = 附加信息。
示例如下：
v=0
o=RTSP 1288004422 894 IN IP4 0.0.0.0
s=RTSP server
c=IN IP4 0.0.0.0
t=0 0
a=charset:Shift_JIS
a=range:npt=0-
a=control:*
a=etag:1234567890
m=video 0 RTP/AVP 26
在RTSP的请求(Request)和响应(Response)中，必须包含请求和响应序数。该序数标识一对请求和响应。在完成一对请求和响应后，无论请求是成功还是失败，都必须将该序数加一。该序数在RTSP中以CSeq字段表示。
4.rtsp的方法
下面让我们来看一下RTSP的方法(Method)。
OPTIONS：RTSP客户端通过该方法(Method)检测RTSP服务器所支持的方法(Method)。该方法(Method)可以在任何的时候发往RTSP服务器。示例如下：
C->S
OPTIONS rtsp://192.168.10.115:554/live.sdp RTSP/1.0
CSeq: 1
User-Agent: Shining100
S->C
RTSP/1.0 200 OK
CSeq: 1
Date: Wed, 10 Nov 2010 11:28:10 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, TEARDOWN
DESCRIBE:获取RTSP服务器中指定标识(Presentation)的说明。通过该方法，我们可以从RTSP服务器的响应(Response)中获取该标识(Presentation)下流的名称和属性。我们可以在该方法(Method)的Request中添加request-header的Accept字段,来指定服务器以什么样的方式来说明流的属性。例如使用SDP。示例如下：
C->S
DESCRIBE rtsp://192.168.10.115:554/live.sdp RTSP/1.0
CSeq: 2
User-Agent: Shining100
Accept: application/sdp
RTSP/1.0 200 OK
CSeq: 2
Date: Mon, 25 Oct 2010 11:0:22 GMT
Content-Base: rtsp://192.168.10.115/live.sdp/
Content-Type: application/sdp
Content-Length: 431
v=0
o=RTSP 1288004422 894 IN IP4 0.0.0.0
s=RTSP server
c=IN IP4 0.0.0.0
t=0 0
a=charset:Shift_JIS
a=range:npt=0-
a=control:*
a=etag:1234567890
m=video 0 RTP/AVP 26
a=control:trackID=1
m=audio 0 RTP/AVP 97
a=control:trackID=6
a=rtpmap:97 mpeg4-generic/8000/2
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1590;SizeLength=13; IndexLength=3; IndexDeltaLength=3; CTSDeltaLength=0; DTSDeltaLength=0;
在DESCRIBE中，我们需要获取具体实时流的名字，以便在SETUP中向RTSP服务器申请实时流。
SETUP:定义RTSP客户端和RTSP服务器之间实时流的传输方式。传输方式可以是TCP、UDP或者是MULTICAST其中之一。通过在SETUP发法中定义Transport Header的字段，可以定义RTSP客户端和RTSP服务器端使用什么方式进行流传输。Transport
Header定义如下：
Transport: transport-protocol/profile/lower-transport/parameter
transport-protocol = 传输协议，一般填写RTP
profile = 概述，固定填写AVP(Audio Video Profile)
lower-transport = 底层传输协议，可以填写TCP或者UDP。如果不填写，则默认使用UDP作为底层传输协议。
Parameter = transport-protocol/profile[/lower-transport] ( ”unicast” | ”multicast” )
| ”;” ”interleaved” ”=” channel [ ”-” channel ]
| ”;” ”port” ”=” port [ ”-” port ]
| ”;” ”client port” ”=” port [ ”-” port ]
| ”;” ”server port” ”=” port [ ”-” port ]
| ”;” ”mode” = <”> 1#mode <”>
unicast = 单播，multicast = 多播，该参数为必填参数
interleaved = 使用传输流和RTSP控制混合传输的方式
port = 多播传输时的端口
client port = UDP做为底层传输协议时的RTSP客户端的端口号
server port = 使用UDP做为底层传输协议时的RTSP服务器的端口号
mode = 即将进行的取流操作。可以填写PLAY或者RECORD。
在SETUP的RESPONSE中，我们需要注意记录下Session这个字段后面的值。该值代表这次会话(Session)的ID，在这次会话(Session)中关于操作实时流的方法(Method)中，比如PLAY或者RECORD，都需要在请求(Request)中加入该ID。
关于SETUP还有一点需要注意，如果我们要同时获取视频流以及音频流。假设首先SETUP视频流，然后SETUP音频流，其实首先SETUP哪个流都可以。第一次SETUP时必须记录下Session ID，因为第二次SETUP时，我们就需要在请求(Request)中传入该ID值。
关于SETUP的示例如下：
TCP
C->S
SETUP rtsp://192.168.10.115:554/live.sdp/trackID=1 RTSP/1.0
CSeq: 3
User-Agent: Shining100
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
S->C
RTSP/1.0 200 OK
CSeq: 3
Date: Wed, 10 Nov 2010 11:28:10 GMT
Session: 18119504;timeout=80
Transport: RTP/AVP/TCP;interleaved=0-1;unicast;mode=play
UDP
C->S
SETUP rtsp://192.168.10.115/live.sdp/trackID=1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=2696-2697
User-Agent: Shining100
S->C
RTSP/1.0 200 OK
CSeq: 3
Date: Mon, 25 Oct 2010 11:7:0 GMT
Session: 504931;timeout=80
Transport: RTP/AVP;unicast;client_port=2696-2697;server_port=5556-5557
PLAY:请求RTSP服务器以在SETUP约定的方式发送流。示例如下：
C->S
PLAY rtsp://192.168.10.115:554/live.sdp RTSP/1.0
CSeq: 4
User-Agent: Shining100
Range: npt=0.000-
Session: 18119504
S->C
RTSP/1.0 200 OK
CSeq: 4
Date: Wed, 10 Nov 2010 11:28:10 GMT
Session: 18119504;timeout=80
Range = 播放的时间。 npt=0.000-表示从开始到结束
timeout = 超时时间。必须在这个时间内向RTSP服务器发送RTSP方法(Method)或者RTCP包，否则RTSP服务器会认为会话失效。
TEARDOWN：终止会话。示例如下：
C->S
TEARDOWN rtsp://192.168.10.115:554/live.sdp RTSP/1.0
CSeq: 5
User-Agent: Shining100
Session: 18119504
S->C
RTSP/1.0 200 OK
CSeq: 5
Session: 18119504
这里介绍底层传输协议为TCP的RTP流的传输格式。在使用PLAY方法并得到成功的Response后，RTSP服务器就会向RTSP客户端发送实时流数据了。发送过来的数据的第一个字节是一个ASCII码$，后面的一个字节是在SETUP里面interleaved定义的Channel(通道)号，再后面的两个字节是RTP/RTCP包的大小，注意该大小是按照网络字节序表示的。最后跟着的就是RTP/RTCP包了。示例如下：
S->C: $/000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $/000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $/001{2 byte length}{"length" bytes RTCP packet}
方法定义：
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。已定义方法如下表所示。
|
方法
|
方向
|
对象
|
要求
|
含义
|
|
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请求必须在连接可再次播放前发布
|