RTSP简介

信令	发送方向	是否一定需要
DESCRIBE	C->S	建议
ANNOUNCE	C->S, S->C	可选择的
GET_PARAMETER	C->S, S->C	可选择的
OPTIONS	C->S, S->C	必需 (S->C: 可选择的)
PAUSE	C->S	建议
PLAY	C->S	必需
RECORD	C->S	可选择的
REDIRECT	S->C	可选择的
SETUP	C->S	必需
SET_PARAMETER	C->S, S->C	可选择的
TEARDOWN	C->S	必需

表1：信令简要描述

C：客户端

S：服务端

下面介绍几个常用的信令

3.4.1 OPTIONS

例子：

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

OPTIONS消息可以在任何时间被发起，如MOTO835手机就会每隔60秒左右向服务器端发送一个OPTIONS的消息，而HMS服务器在检查MOTO835是否仍在线时，也是通过来检查服务器端是否定时收到OPTIONS的消息来实现的。但需注意的是，并不是所有的手机和播放器会定时发送OPTIONS消息到服务器端，即使有发送，发送OPTIONS的消息的时间间隔也是不尽相同的。

3.4.2 DESCRIBE

DESCRIBE消息是由客户端发送到服务器端，用于客户端得到请求链接（request URL）中指定的媒体文件的相关描述。DESCRIBE的这一对交互消息完成了RTSP的媒体初始化。

例子：

C->S:

DESCRIBErtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg

S->C:

RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376

v=0 （这里就是MESSAGE BODY，它的长度由Content_Length来指定）
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.pse=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

DESCRIBE的响应消息必须包含所有的媒体初始化信息。对于基于RTSP的系统，媒体初始化是必须的，但是并不一定要通过DESCRIBE消息来得到，这里是一个RTSP的客户端得到初始化信息的三种方式：

n 通过RTSP的DESCRIBE

n 一些其它的协议，如HTTP，email attachment等

n 命令行方式

3.4.3 SETUP

SETUP请求用于指定流媒体使用的传输机置。在请求消息中会指定客户端在数据传输时相关的传送参数，而在响应消息中将包含由服务器端所指定的传输参数。服务器端在回复SETUP消息时将会生成一个session ID.

例子：

C->S:

SETUP rtsp://example.com/foo/bar/baz.3gpRTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589

S->C:

RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257

服务器端在回复SETUP消息时将会生成一个session ID.

3.4.4 PLAY

PLAY消息是告诉服务器端可以使用在SETUP消息中所指定的传输机置开始传送数据。需要指出的是，客户端不应该发送任何PLAY请求直到所有的SETUP消息被成功解析。PLAY消息会在range中指定媒体的播放时间，服务器在接到PLAY消息后会由range中指定的开始点开始发送媒体数据直到range中指定的结束点。

所有的PLAY消息都是必须按顺序被处理的，即当一个PLAY的请求到达时，而上一个PLAY请求还未完成，后面的PLAY请求将被延时，直到第一个PLAY处理完成时才会被处理。

例子：

C->S:

PLAY rtsp://audio.example.com/audioRTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15

3.4.5 PAUSE

PAUSE消息是用于暂时中断流媒体的传送。当暂停的时间过长（这个值应在SETUP消息中由timeout参数指定），服务器可以自动断开这个会话，释放所占用的资源。

例子:

C->S:

PAUSE rtsp://example.com/fizzle/fooRTSP/1.0
CSeq: 834
Session: 12345678

S->C:

RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT

服务器不是必须要支持PAUSE信令的，例如，对于直播的节目，就可以不支持暂停。当一个服务器不支持某一个信令时，必须要返回给客户端以“501 Not Implemented”的响应消息，并且客户端应该不再尝试向服务器端发送这个请求。

3.4.6 TEARDOWN

TEARDOWN消息是用于停止媒体数据的传送，并释放所占用的资源。

例子：
C->S:

TEARDOWNrtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678

S->C:

RTSP/1.0 200 OK
CSeq: 892

3.5 Header Field解析

在每个消息中都会包含一定的字段用于描述一些信息。

Type ”g” 指通用，在请求消息和响应消息中都可能出现

Type “R” 指请求消息

Type “r” 指响应消息

Type “e” 指实体头字段

头	类型	支持	信令
Accept	R	opt.	entity
Accept-Encoding	R	opt	entity
Accept-Language	R	opt	all
Allow	r	opt.	all
Authorization	R	opt.	all
Bandwidth	R	opt	all
Blocksize	R	opt.	all but OPTIONS, TEARDOWN
Cache-Control	g	opt.	SETUP
Conference	R	opt	SETUP
Connection	g	req	all
Content-Base	e	opt.	entity
Content-Encoding	e	req.	SET_PARAMETER
Content-Encoding	e	req.	DESCRIBE, ANNOUNCE
Content-Language	e	req	DESCRIBE, ANNOUNCE
Content-Length	e	req.	SET_PARAMETER, ANNOUNCE
Content-Length	e	req.	entity
Content-Location	e	opt	entity
Content-Type	e	req.	SET_PARAMETER, ANNOUNCE
Content-Type	r	req.	entity
CSeq	g	req	All
Date	g	opt.	All
Expires	e	opt.	DESCRIBE, ANNOUNCE
From	R	opt.	All
If-Modified-Since	R	opt.	DESCRIBE, SETUP
Last-Modified	e	opt.	Entity
Proxy-Authenticate Proxy-Require	R	req.	All
Public	r	opt.	All
Range	R	opt	PLAY, PAUSE, RECORD
Range	r	opt.	PLAY, PAUSE, RECORD
Referer	R	opt.	All
Require	R	req.	All
Retry-After	r	opt.	All
RTP-Info	r	req.	PLAY
Scale	Rr	opt.	PLAY, RECORD
Session	Rr	req.	all but SETUP, OPTIONS
Server	r	opt.	All
Speed	Rr	opt.	PLAY
Transport	Rr	req.	SETUP
Unsupported	r	req.	All
User-Agent	R	opt.	All
Via	g	opt.	All
WWW-Authenticate	r	opt.	All

表2：RTSP头字段简述

下面简要介绍一些在RTSP中常用到的头字段，详细的信息请查看RFC 2326。

3.5.1 Accept

Accept字段可用于指定可被接受的描述类型

例子:
Accept: application/rtsl, application/sdp;level=2

3.5.2 Cseq

Cseq域指定一对RTSP请求-响应消息的序列号。在请求消息及响应消息中一定要指定这个域。对于请求消息，会有一个具有相同Cseq域内容的响应消息与之对应。

例子：

C->S:

SETUP rtsp://example.com/foo/bar/baz.3gpRTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589

S->C:

RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257

3.5.3 Range

Range用于在请求消息和响应消息中指定播放的时间段。

例子：:
Range: clock=19960213T143205Z-;time=19970123T143720Z

3.5.4 RTP-Info

这个域用于在回复PLAY消息中指定RTP特殊的参数

url: 与设置的RTP参数对应的流媒体链接

seq: 流媒体第一个包的序列号

rtptime: 用于回复range域对应的RTP时间戳

RTP-Info语法结构：

RTP-Info = "RTP-Info" ":"1#stream-url 1*parameter

stream-url = "url" "=" url

parameter = ";" "seq""=" 1*DIGIT

| ";""rtptime" "=" 1*DIGIT

例子：

RTP-Info:url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,url=rtsp://foo.com/bar.avi/streamid=1;seq=30211

3.5.5 Session

Session域在请求与响应消息中用于识别一个RTSP会话（RTSP session即一个完整的RTSP交互过程。例如：在点播流媒体时，一个典型的会话过程包括一个客户建立一个传输通道（SETUP），用PLAY开始传输流，最后用TEARDOWN来断开这个连接）。一旦客户端接收到Session标识，在这个会话中的任何请求都需要附加这个域。

Session语法结构：

Session = "Session" ":"session-id [ ";" "timeout" "=" delta-seconds ]

例子：

Session: 12345678

3.5.6 Transport

这个域在请求消息中是标识哪一种传输协议将被使用，并指定一些在描述说明中没有指定的参数的值。使用的传输协议之间用逗号分隔，参数之间用分号分隔

常用参数：

unicast | multicast: 单播还是组播（缺省值为multicast）.

destination: 指定流将被传送到到哪个地址

port: (RTP协议):指定RTP/RTCP端口号（multicast）。一般为一个范围。e.g.,port=3456-3457.

Client_port: 客户端选择的用于接收媒体数据及控制信息的单播 RTP/RTCP端口号。e.g.,port=3456-3457

Server_port: 服务器端用于接收媒体数据和控制信息的单播RTP/RTCP端口号。e.g., port=3456-3457

例子:
Transport:RTP/AVP;multicast;ttl=127;mode="PLAY",RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

3.5.7 User-Agent

这个域用于用户标识，不同公司或是型号的手机发出的消息中的这个域的内容都不大相同。有时会指出手机的版本号，播放器的型号等等。在HMS中的terminal.xml文件就是根据这个域中的内容来完成简单的终端适配的功能。

例子：

User-Agent:01056SS68001117616022101802836055;14;41;4578;327;13824;0;1;0x0202;0x00000B;0x028010

4 移动流媒体与RTSP

移动流媒体技术就是把连续的影像和声音信息经过压缩处理后放到网络服务器上，让移动终端用户能够一边下载一边观看、收听，而不需要等到整个多媒体文件下载完成就可以即时观看的技术。实际上移动流媒体技术是网络音视频技术和移动通讯技术发展到一定阶段的产物，它是融合很多网络技术之后所产生的技术，它会涉及到流媒体数据的采集、压缩、存输以及网络通信等多项技术。它大致分为下面两大类业务类型：

·　流媒体点播(VOD)

内容提供商将预先录制好的多媒体内容编码压缩成相应格式，存放在内容服务器上并把内容的描述信息以及链接放置在流媒体的portal上。最终用户就可以通过访问portal，发现感兴趣的内容，有选择的进行播放。

·　流媒体直播

流媒体编码服务器将实时信号编码压缩成相应的格式，并经由流媒体服务器分发到用户的终端播放器。根据实时内容信号源的不同，又可以分为电视直播、远程监控等。

对于点播和直播，都是使用的RTSP协议。下面我们介绍在实际应用中RTSP消息是如何交互来完成点播或是直播功能。

4.1 点播流程

一个移动用户使用手机通过访问网页得到URI，在URI中指定了流媒体服务器的地址及想要访问的媒体内容。通过RTSPSETUP消息来建立客户端与流媒体服务器之间的连接，然后客户端通过发送一个RTSP PLAY的消息来通知服务器开始传送一个或多个媒体流。

具体消息交互过程如下：

SGSN

Media Server

WAP/Web server

Get Web/WAP Page with URI

RTSP:DESCRIBE ( get content description file)

RTSP:SETUP

RTSP:PLAY

RTSP:PAUSE

RTSP:TEARDOWN

IP/UDP/RTP content

图2RTSP消息交互

每次客户端发送一个请求消息，服务器端都会回一个相应的响应消息。

1. 手机通过上网得到带有流媒体地址的网页，并点播一个节目

2. 手机上发RTSP：DESCRIBE的消息给服务器，服务器处理其中的URL链接，得到相应文件的SDP信息，附加在响应消息中返回给手机。如果此时服务器找不到手机想要点播的文件，就会回应400的错误给手机，显示文件不存在。

3. 手机根据收到的SDP的信息向服务器发送RTSP:SETUP消息，与服务器建立连接。如果媒体文件包含音频和视频，就会有两次SETUP的交互消息。一个是音频的信息，一个是视频的信息。如果交互成功，服务器会发送200的OK消息给手机

4. 手机在SETUP消息执行成功后，会向服务器发送RTSP：PLAY的消息，要求服务器开始发送数据。服务器在收到PLAY消息后，即会开始传送UDP/RTP包。

5. 如果在播放过程中需要暂停，手机会发送RTSP：PAUSE的消息给服务器，服务器在收到暂停消息后，即会停止发数据包，手机停止播放。如果需要继续播放，手机只需要再发送RTSP：PLAY的消息给服务器，服务器根据暂停的位置继续开始播放。

6. 当播放完成后，手机会自动向服务器发送RTSP：TEARDOWN消息，当服务器收到下线消息后，就会断开与手机的连接，释放所占用的资源。

7. 点播过程结束。

4.2 SDP

在播放过程中，手机得到内容的相关信息是很重要的，如果这些内容不正确，也会影响播放的正确性，下面简要介绍一下SDP。

SDP文件（Session Description Protocol）包含了会话的描述，媒体类型，媒体的码率。客户端通过RTSP DESCRIBE来得到SDP文件。

RTSP需要一个内容的描述。而SDP就被用于客户端与服务端的一种内容描述的格式。在传送给客户的SDP内容应该声明了这个对话所要访问的媒体内容的媒体编码类型。对于流媒体服务而言，以下几个域是在SDP中一定要包含的。

“a=control:”

“a=range:”

“a=rtpmap:”

“a=fmtp:”

例子：

v=0
o=ghost 2890844526 2890842807 IN IP4 192.168.10.10
s=3GPP Unicast SDP Example
i=Example of Unicast SDP file
u=http://www.infoserver.com/ae600
e=ghost@mailserver.com
c=IN IP4 0.0.0.0
b=AS:128
t=0 0

a=range:npt=0-45.678
m=video 1024 RTP/AVP 96

b=AS:128
a=rtpmap:96 H263-2000/90000
a=fmtp:96 profile=3;level=10
a=control:rtsp;//mediaserver.com/movie
a=recvonly

就如我们以前所了解的，对于直播，我们在建立了直播源后，就会将生成的SDP文件broadcast.sdp放在服务器上，而用户使用rtsp://ip:port/broadcast.sdp就可以进行直播节目的播放，这里的sdp文件里的内容就是上面所提到的这些。它将我们在建立直播源时所设置的音、视频编码，及相应的码率记录下来存在broadcast.sdp文件中，这样手机在进行进播时，得到了相关的SDP信息，然后根据这些信息与服务器建立连接。

4.3 数据传送

控制及媒体数据的传送是通过TCP/IP和UPD/IP上完成的，下图是一个协议栈的简单描述。媒体数据被打包成RTP包进行传送。

图3协议栈的简单描述

4.4 消息流程

下面让我们来看一个具体的消息交互过程。我们可以通过ETHEREAL或是TCPDUMP这些抓包工具来获得这些信息。

c->s【向服务器请求SDP信息】

【DESCRIBE】 DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0

【交互标识】 CSeq: 1

【请求内容】 Accept: application/sdp

【用户标识】 User-Agent:01056SS68001117616022101802836055;

14;41;4578;327;13824;0;1;0x0202;0x00000B;0x028010

s->c 【服务端返回SDP信息】

【成功响应】 RTSP/1.0 200 OK

【服务器版本号】 Server:HMS Mobile V100R001B08D023

【交互标识】 CSeq: 1

【SDP长度】 Content-Length:625

【包含内容类型】 Content-Type:application/sdp

【包含内容信息】 Content-Base:rtsp://211.94.164.227/3.3gp/

【以下为SDP内容】

【SDP版本号】 v=0

【服务器信息】 o=StreamingServer 32764749291067418948000 IN

IP4 10.70.139.108

【文件名】 s=3.3gp

【URL】 u=rtsp://211.94.164.227/3.3gp

【e-mail】 e=admin@

【IPv4】 c=IN IP4 0.0.0.0

t=00

【控制属性】 a=control:rtsp://211.94.164.227/3.3gp

【视频信息】 m=video0 RTP/AVP 96【媒体类型】

【视频带宽】 b=AS:16

【视频格式】 a=rtpmap:96MP4V-ES【格式】/90000【采样率】

【视频格式】 a=fmtp:96profile-level-id=8;

config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463F

a=mpeg4-esid:201

【厂家信息】 a=x-envivio-verid:00011118

【视频轨道】 a=control:trackID=65737

【音频信息】 m=audio 0 RTP/AVP 97【媒体类型】

【音频带宽】 b=AS:19

【音频格式】 a=rtpmap:97 MP4A-LATM【格式】/11025【采样率】/1

a=fmtp:97profile-level-id=15; object=2;

cpresent=0;config=40002A103FC0

a=mpeg4-esid:101

【厂家信息】 a=x-envivio-verid:00011118

【音频轨道】 a=control:trackID=65637

c->s【向服务器发起建立视频连接的呼叫】

【SETUP信令】 SETUPrtsp://211.94.164.227/3.3gp/trackID=65737 RTSP/1.0

CSeq:2

【传输信息】 Transport: RTP/AVP;unicast【单播区别组播】;

client_port=5004-5005【客户端端口号】

s->c【服务器返回视频连接建立成功信息】

RTSP/1.0 200 OK

Server: HMS MobileV100R001B08D023

CSeq: 2

【会话标识】 Session: 4

【传输信息】 Transport:RTP/AVP;unicast;client_port=5004-5005;

source=211.94.164.227;【服务器IP】

server_port=8090-8091【服务器端口号】;

ssrc=3e06【同步源描述符】

c->s【向服务器发起建立音频连接的呼叫】

SETUPrtsp://211.94.164.227/3.3gp/trackID=65637 RTSP/1.0

CSeq: 3

Transport:RTP/AVP;unicast;client_port=5006-5007

Session: 4

s->c【服务器返回音频连接建立成功信息】

RTSP/1.0 200 OK

Server:HMS Mobile V100R001B08D023

CSeq:3

Session: 4

Transport:RTP/AVP;unicast;client_port=5006-5007;

source=211.94.164.227;server_port=8092-8093;ssrc=3e06

c->s【向服务器发出播放请求】

PLAYrtsp://211.94.164.227/3.3gp RTSP/1.0

CSeq: 4

Session: 4

【播放位置】 Range: npt=now-【从当前位置开始播放】

s->c【服务器返回发出播放成功响应请求】

RTSP/1.0 200 OK

Server: HMS MobileV100R001B08D023

CSeq: 4

Session: 4

【RTP信息】 RTP-Info:url=trackID=65737;【轨道信息】seq=1;【RTP包序列号】

rtptime=0【RTP包时间戳】,url=trackID=65637;seq=1;rtptime=0

【播放范围】 Range: npt=0.000000-60.193000

s->c【服务器发送视音频数据给终端】

【RTP包略】 xxxx

c->s【向服务器发送终止请求】

【TEARDOWN信令】TEARDOWN rtsp://211.94.164.227/3.3gp RTSP/1.0

CSeq: 5

Session: 4

s->c【服务器返回终止成功信息】

RTSP/1.0 200 OK

Server: HMS MobileV100R001B08D023

CSeq: 5

Session: 4

petershina

关注

0
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录