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请求必须在连接可再次播放前发布
|