rtsp协议详解

RTSP(Real Time Streaming Protocol), 实时流传输协议, 是TCP/IP协议体系中的一个<code>应用层</code>协议, 由哥伦比亚大学, 网景和RealNetworks公司提交的IETF RFC标准. 该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据. RTSP在体系结构上位于RTP和RTCP之上, 它使用TCP或RTP完成数据传输.

流媒体服务协议栈

RTSP提供了一个可扩展框架, 使实时数据, 如音频与视频的受控点播成为可能. 数据源包括现场数据与存储在剪辑中数据. 该协议目的在于控制多个数据发送连接, 为选择发送通道, 如UDP, 组播UDP与TCP, 提供途径, 并为选择基于RTP上发送机制提供方法.

它的语法和运作跟HTTP 1.1类似, 但并不特别强调时间同步, 所以比较能容忍网络延迟.

HTTP与RTSP相比, * HTTP传送HTML. HTTP请求由客户机发出, 服务器作出响应 * RTSP传送的是多媒体数据. 使用RTSP时, 客户机和服务器都可以发出请求, 即RTSP可以是<code>双向</code>的.

RTSP是用来控制声音或影像的多媒体串流协议, 并允许同时多个串流需求控制, 传输时所用的网络通讯协议并不在其定义的范围内, 服务器端可以自行选择使用TCP或UDP来传送串流内容.

而前面提到的允许同时多个串流需求控制(Multicast), 除了可以降低服务器端的网络用量, 更进而支持多方视讯会议(Video Conference). 因为与HTTP1.1的运作方式相似, 所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP, 并因RTSP具有重新导向功能, 可视实际负载情况来转换提供服务的服务器, 以避免过大的负载集中于同一服务器而造成延迟.

该协议用于C/S模型, 是一个基于文本的协议, 用于在客户端和服务器端建立和协商实时流会话.

实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体. 尽管连续媒体流与控制流交换是可能的, 通常它本身并不发送连续流. 换言之, RTSP充当多媒体服务器的网络远程控制. RTSP连接没有绑定到传输层连接, 如TCP. 在RTSP连接期间, RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求. 此外, 可使用无连接传输协议, 如UDP. RTSP流控制的流可能用到RTP, 但RTSP操作并不依赖用于携带连续媒体的传输机制.

协议支持的操作如下: (1)从媒体服务器上检索媒体: 用户可通过HTTP或其它方法提交一个演示描述. 如演示是组播, 演示式就包含用于连续媒体的的组播地址和端口. 如演示仅通过单播发送给用户, 用户为了安全应提供目的地址. (2)媒体服务器邀请进入会议: 媒体服务器可被邀请参加正进行的会议, 或回放媒体, 或记录其中一部分, 或全部. 这种模式在分布式教育应用上很有用, 会议中几方可轮流按远程控制按钮. (3)将媒体加到现成讲座中: 如服务器告诉用户可获得附加媒体内容, 对现场讲座显得尤其有用. 如HTTP/1.1中类似, RTSP请求可由代理, 通道与缓存处理.

可扩展性: 新方法和参数很容易加入RTSP.

易解析: RTSP可由标准HTTP或MIME解析器解析.

安全: RTSP使用网页安全机制.

独立于传输: RTSP可使用不可靠数据报协议(EDP), 可靠数据报协议(RDP); 如要实现应用级可靠, 可使用可靠流协议.

多服务器支持: 每个流可放在不同服务器上, 用户端自动与不同服务器建立几个并发控制连接, 媒体同步在传输层执行.

记录设备控制: 协议可控制记录和回放设备.

流控与会议开始分离: 仅要求会议初始化协议提供, 或可用来创建惟一会议标识号. 特殊情况下, 可用SIP或H.323来邀请服务器入会.

适合专业应用: 通过SMPTE时标, RTSP支持帧级精度, 允许远程数字编辑.

演示描述中立: 协议没强加特殊演示或元文件, 可传送所用格式类型; 然而, 演示描述至少必须包括一个RTSP URL.

代理与防火墙友好: 协议可由应用和传输层防火墙处理. 防火墙需要理解SETUP方法, 为UDP媒体流打开一个“缺口”.

HTTP友好: 此处, RTSP明智地采用HTTP观念, 使现在结构都可重用. 结构包括Internet内容选择平台(PICS). 由于在大多数情况下控制连续媒体需要服务器状态, RTSP不仅仅向HTFP添加方法.

适当的服务器控制: 如用户启动一个流, 必须也可以停止一个流.

传输协调: 实际处理连续媒体流前, 用户可协调传输方法.

性能协调: 如基本特征无效, 必须有一些清理机制让用户决定哪种方法没生效. 这允许用户提出适合的用户界面.

C表示rtsp客户端, S表示rtsp服务端

上述的过程是标准的, 友好的rtsp流程, 但实际的需求中并不一定按部就班来. 其中第3和4步是必需的！

第一步, 只要服务器客户端约定好, 有哪些方法可用, 则option请求可以不要.

第二步, 如果我们有其他途径得到媒体初始化描述信息(比如http请求等等), 则我们也不需要通过rtsp中的describe请求来完成.

第五步, 可以根据系统需求的设计来决定是否需要.

RTSP的消息有两大类: <code>请求消息(request)</code>, <code>回应消息(response)</code>.

请求消息

其中<code>方法</code>包括OPTION回应中所有的命令,URI是接受方的地址,例如:rtsp://192.168.20.136. RTSP版本一般都是 RTSP/1.0. 每行后面的CR LF表示回车换行, 需要接受端有相应的解析, 最后一个<code>消息头</code>需要有两个CR LF(即空行)

回应消息

其中RTSP版本一般都是RTSP/1.0, 状态码是一个数值, 200表示成功, 解释是与状态码对应的文本解释.

方法记号表示资源上执行的方法, 它区分大小写. 新方法可在将来定义, 但不能以$开头. 已定义方法如下表所示:

(注: P----演示, S----流, C----用户端, S----服务器端)

某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据. 由于插入将使客户端和服务器操作复杂, 并增加附加开销, 除非有必要, 应避免这样做. 插入二进制数据仅在RTSP通过TCP传输时才可使用. 流数据(如RTP包)用一个ASCII字符'ʹ封装, 后跟一个一字节通道标识, 其后是封装二进制数据的长度, 两字节整数. 流数据紧跟其后, 没有CRLF, 但包括高层协议头. 每个块包含一个高层协议数据单元.

当传输选择为RTP, RTCP信息也被服务器通过TCP连接插入. 缺省情况下, RTCP包在比RTP通道高的第一个可用通道上发送. 客户端可能在另一通道显式请求RTCP包, 这可通过指定传输头插入参数中的两个通道来做到. 当两个或更多流交叉时, 为取得同步, 需要RTCP. 而且, 这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径, 可能时, 在UDP上进行传输.

消息头的定义如下表. 表格说明:

Type:

类型 "g" 表示请求和响应中的通用请求头;

类型 "R" 表示请求头;

类型 "r" 表示响应头;

类型 "e" 表示实体头字段.

Support:

"req." 表示必须由接收者以特殊的方法实现; 注意, 不是所有 "req." 字段在该类型的每个请求中都会被发送. "req." 只表示客户机(支持响应头)和服务器(支持请求头)必须执行该字段.

"opt." 表示是可选的.

最后一栏列出了关于头字段产生作用的方法; 其中 "entity" 针对于返回一个信息主体的所有方法. )

常用头解析:

标准RTSP 消息的状态码(在应答消息的第一行表示)

本节针对上面所述的典型交互过程进行说明

OPTION

目的是得到服务器提供的可用方法:

服务器的回应信息包括提供的一些方法,例如:

DESCRIBE

C向S发起DESCRIBE请求,为了得到会话描述信息(SDP):

服务器回应一些对此会话的描述信息(sdp):

SETUP

客户端提醒服务器建立会话,并确定传输模式:

服务器回应信息:

PLAY

客户端发送播放请求:

TEARDOWN

客户端发起关闭请求:

服务器回应:

以上方法都是交互过程中最为常用的, 其它还有一些重要的方法如<code>get/set_parameter,pause,redirect</code>等等

SDP 完全是一种会话描述格式, 它不属于传输协议.

它使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、 实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。

SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强, 这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商, 所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现．

SDP描述由许多文本行组成，文本行的格式为&lt;类型&gt;=&lt;值&gt;，&lt;类型&gt;是一个字母，&lt;值&gt;是结构化的文本串，其格式依&lt;类型&gt;而定。

<code>＜type＞=&lt;value&gt;[CRLF]</code>

sdp的格式:

SDP（Session Description Protocol）是一个用来描述多媒体会话的应用层控制协议，它是一个基于文本的协议，用于会话建立过程中的媒体类型和编码方案的协商等。

消息正文格式：

v=0 //该行指示协议的版本

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 //o行中包含与会话所有者有关的参数

第一个参数表明会话发起者的名称，该参数可不填写，如填写和SIP消息中，from消息头的内容一致。

第二个参数为主叫方的会话标识符。

第三个参数为主叫方会话的版本，会话数据有改变时，版本号递增。

第四个参数定义了网络类型，IN表示Internet网络类型，目前仅定义该网络类型。

第五个参数为地址类型，目前支持IPV4和IPV6两种地址类型。

第六个参数为地址：表明会话发起者的IP地址，该地址为信令面的IP地址，信令PDP激活时为手机分配。

s=SDP Seminar //表明本次会话的标题，或会话的名称

i=A Seminar on the session description protocol //会话的描述

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps //会话的URI，通过该地址可以查阅到会话的更多内容

[email protected] (Mark Handley) //会话责任人的EMIAL地址

c=IN IP4 224.2.17.12/127 //C行包含为多媒体会话而建立的连接的信息，其中指出了真正的媒体流使用的IP地址

第一个参数为网络类型，目前仅定义INTERNET网络类型。用“IN”表示。

第二个参数为地址类型，目前支持两种地址类型：IPV4和IPV6。

第三个参数为地址，该地址为多媒体流使用的IP地址。

t=2873397496 2873404696 //表示会话的开始时间和结束时间

第一个参数表明会话的开始时间，数字表明从1900年1月1日00：00以来所经过的秒数。

第二个参数表明会话的结束时间，数字表明从1900年1月1日00：00以来所经过的秒数。

m=audio 3458 RTP/AVP 0 96 97 // m行又称媒体行，描述了发送方所支持的媒体类型等信息

第一个参数为媒体名称：表明支持音频类型。

第二个参数为端口号，表明UE在本地端口为3458上发送音频流。

第三个参数为传输协议，一般为RTP/AVP协议。

第四~七参数为所支持的四种净荷类型编号

a=rtpmap:0 PCMU //a行为媒体的属性行，以属性的名称：属性值的方式表示。

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

格式为：a=rtpmap:&lt;净荷类型&gt;&lt;编码名称&gt; * 净荷类型0固定分配给了PCMU， * 净荷类型96对应的编码方案为G.726,为动态分配的。 * 净荷类型97对应的编码方式为自适应多速率宽带编码（AMR-WB），为动态分配的。

m=video 3400 RTP/AVP 98 99 //m行又称媒体行，描述了发送方所支持的媒体类型等信息

第一个参数为媒体名称：表明支持视频类型。

第二个参数为端口号，表明UE在本地端口为3400上发送视频流。

四、五参数给出了两种净荷类型编号

a=rtpmap:98 MPV

a=rtpmap:99 H.261

格式为：a=rtpmap:&lt;净荷类型&gt;&lt;编码名称&gt; * 净荷类型98对应的编码方案为MPV,为动态分配的。 * 净荷类型97对应的编码方式为H.261，为动态分配的。