RTSP协议解析

转载地址：http://blog.csdn.net/rongdeguoqian/article/details/17888407

RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。

一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。
在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。
一、
1、OPTIONS

功能：
获取服务器/客户端支持的能力集
关键字段：无
特殊说明：IPTV系统中未使用该方法

2、DESCRIBE

主要功能：
从服务器获取流媒体文件格式信息
从服务器获取流媒体文件传输信息
关键字段：
Content-Type：一般是SDP
Content-length：一般是SDP的长度
特殊说明：媒体信息通过SDP协议给出



3.SETUP

主要功能：
与服务器协商流媒体传输方式
此过程中，建立RTP通道
关键字段：
Transport——传输方式
Transport: MP2T/RTP/UDP;unicast;destination=121.60.21.53;client_port=8342-8343,MP2T/RTP/TCP;unicast;destination=121.60.21.53;interleaved=0-1



4、PLAY

主要功能：
与服务器协商流媒体播放
关键字段：
Range——播放时间
•Range: npt=0.0-end
•Range:clock=20100318T021919.35Z-20100318T031919.80Z
Scale——播放速度
•Scale: 1.0

相对时间描述——npt(normalplay time)
方法1位置描述
•beginning      节目起始点
•now               当前播放点
•end                节目结束点
方法2时间描述
•直接用数字形式表示与起始点的时间
绝对时间描述——clock
ISO 8601时间戳标准



5、TEARDOWN

主要功能：拆除连接
关键字段：无



6、PAUSE
主要功能：

暂停流媒体播放

关键字段：无从服务器获取参数，目前主要获取时间范围

保持RTSP连接（发送空的GET_PARAMETER）

关键字段（电信扩展）：

x-Timeshift_Range: clock=20100318T021915.84Z-20100318T031915.84Z

x-Timeshift_Current: clock=20100318T031915.84Z

可能存在的问题：
长时间Pause后，RTSP的TCP连接超时中断。解决办法——定期发送心跳包维持连接（参见GetParam）

7、GET PARAMETER
从服务器获取参数，目前主要获取时间范围

保持RTSP连接（发送空的GET_PARAMETER）

关键字段（电信扩展）：

x-Timeshift_Range: clock=20100318T021915.84Z-20100318T031915.84Z

x-Timeshift_Current: clock=20100318T031915.84Z



二、简单的rtsp消息交互的
1. 第一步：查询服务器端可用方法

 1.C->S:OPTION request       //询问S有哪些方法可用

1.S->C:OPTION response    //S回应信息的public头字段中包括提供的所有可用方法过程。
2.第二步：得到媒体描述信息

2.C->S:DESCRIBE request      //要求得到S提供的媒体描述信息

2.S->C:DESCRIBE response    //S回应媒体描述信息，一般是sdp信息

3. 第三步：建立RTSP会话

3.C->S:SETUP request             //通过Transport头字段列出可接受的传输选项，请求S建立会话

3.S->C:SETUP response          //S建立会话，通过Transport头字段返回选择的具体转输选项，
并返回建立的Session ID;

4. 第四步：请求开始传送数据

4.C->S:PLAY request        //C请求S开始发送数据

4.S->C:PLAY response            //S回应该请求的信息

5. 第五步： 数据传送播放中

S->C:发送流媒体数据    // 通过RTP协议传送数据

6. 第六步：关闭会话，退出

6.C->S:TEARDOWN request      //C请求关闭会话

6.S->C:TEARDOWN response //S回应该请求

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。

其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。
第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），
则我们也不需要通过rtsp中的describe请求来完成。