RTSP协议介绍

来源：互联网发布：电信网络诈骗情形编辑：程序博客网时间：2024/05/18 01:11

RTSP协议介绍

1. 实时流协议RTSP

RTSP[3]协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。

1.1. RTSP协议简介

要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。

媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。

RTSP协议具有如下的特点：

● 可扩展性：新方法和参数很容易加入RTSP。

● 易解析：RTSP可由标准 HTTP或MIME解析器解析。

● 安全：RTSP使用网页安全机制。

● 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级可靠，可使用诸如TCP的可靠流协议。

● 记录设备控制：协议可控制记录和回放设备。

● 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。

● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI。

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

● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。

● 传输协调：实际处理连续媒体流前，用户可协调传输方法。

● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。

图1 RTSP与RTP和RTCP的关系

RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。

1.2. RTSP的报文结构

RTSP有两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。

由于 RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。

RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所示。

图2 RTSP请求报文的结构

RTSP请求报文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。RTSP请求报文的常用方法及作用如表1所示。

表1 RTSP请求报文的常用方法及作用

方法

作用

OPTIONS

获得服务器提供的可用方法

DESCRIBE

得到会话描述信息

SETUP

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

TEARDOWN

客户端发起关闭请求

PLAY

客户端发送播放请求

响应报文的开始行是状态行，RTSP响应报文的结构如图3所示。

图3 RTSP响应报文的结构

1.3. RTSP交互过程

C表示RTSP客户端，S表示RTSP服务端

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

S->C: OPTION response //S回应信息中包括提供的所有可用方法

② C->S: DESCRIBE request //要求得到S提供的媒体初始化描述信息

S->C: DESCRIBE response //S回应媒体初始化描述信息，主要是sdp

③ C->S: SETUP request //设置会话属性，以及传输模式，提醒S建立会话

S->C: SETUP response //S建立会话，返回会话标识符及会话相关信息

④ C->S: PLAY request //C请求播放

S->C: PLAY response //S回应请求信息

S->C: 发送流媒体数据

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

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

上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。其中第3和4步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则OPTIONS请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过RTSP中的DESCRIBE请求来完成。第五步，可以根据系统需求的设计来决定是否需要。
rtsp中常用方法：
1.OPTIONS
目的是得到服务器提供的可用方法：
OPTIONS rtsp://192.168.22.136:5000/v0 RTSP/1.0
CSeq: 1 //每个消息都有序号来标记，第一个包通常是OPTIONS请求消息
User-Agent: bestilyq //自定义的字符串

服务器的回应信息包括提供的一些方法。例如：
RTSP/1.0 200 OK
Cseq: 1         //每个回应消息的cseq数值和请求消息的cseq相对应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY //服务器提供的可用的方法

2.DESCRIBE
C向S发起DESCRIBE请求，为了得到会话描述信息(SDP)：
DESCRIBE rtsp://192.168.20.136:5000/v0 RTSP/1.0
CSeq: 2
Accept: application/sdp
Authorization: Basic YWRtaW46YWRtaW4= //有认证，不需要认证时不需要该字段
User-Agent: bestilyq

服务器回应一些对此会话的描述信息(sdp)：
RTSP/1.0 200 OK
Cseq: 2
Date: Sat Feb 5 22:49:39 2009 GMT
Content-Type: application/sdp
Content-Length: 182

v=0                     //以下都是sdp信息
o=- 0 0 IN IPV4 127.0.0.1
t=0 0
s=No Name
a=tool:libavformat
m=video 0 RTP/AVP 96 //m表示媒体描述，下面是对会话中视频通道的媒体描述
b=AS:2000
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=1
a=control:streamid=0 //streamid＝0表示视频流用的是通道0

3.SETUP
客户端提醒服务器建立会话，并确定传输模式：
(1)TCP模式
SETUP rtsp://192.168.20.136:5000/v0/streamid=0 RTSP/1.0
CSeq: 3
Authorization: Basic YWRtaW46YWRtaW4=
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: bestilyq
(2)UDP模式
SETUP rtsp://192.168.20.136:5000/v0/streamid=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=3008-3009
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: bestilyq
    URI中带有streamid＝0，表示对该通道进行设置。
    Transport参数设置了传输模式。RTP/AVP/TCP表示通过TCP传输RTP包，RTP/AVP表示使用UDP传输RTP包。unicast表示单播。interleaved值有两个：0和1，0表示RTP包，1表示RTCP包，接收端根据interleaved的值来区别是哪种数据包。client_port值有3008和3009，3008表示客户端接收RTP包的端口，3009表示客户端接收RTCP包的端口，服务端要分别将RTP包和RTCP包发送到这两个端口。

服务器回应信息：
(1)TCP模式
RTSP/1.0 200 OK
CSeq: 3
Date: Sat Feb 5 22:35:27 2009 GMT
Session: a522bbb4335617db
Transport: RTP/AVP/TCP;interleaved=0-1
(2)UDP模式
RTSP/1.0 200 OK
CSeq: 3
Date: Sat Feb 5 22:49:39 2009 GMT
Session: 01fa4ca2566a6301      //服务器回应的会话标识符
Transport: RTP/AVP/UDP;unicast;client_port=3008-3009;server_port=1024-1025

4.PLAY
客户端发送播放请求：
PLAY rtsp://192.168.20.136:5000/v0 RTSP/1.0
CSeq: 4
Session: a522bbb4335617db      //SETUP返回的会话标识符
Range: npt=0.000-              //设置播放时间的范围
User-Agent: bestilyq

服务器回应信息：
RTSP/1.0 200 OK
CSeq: 4
Date: Sat Feb 5 22:49:39 2009 GMT
Session: a522bbb4335617db

5.TEARDOWN
客户端发起关闭请求:
TEARDOWN rtsp://192.168.20.136:5000/v0 RTSP/1.0
CSeq: 5
Session: a522bbb4335617db
User-Agent: bestilyq

服务器回应:
RTSP/1.0 200 OK
Cseq: 5
Date: Sat Feb 5 22:49:47 2009 GMT
Session: a522bbb4335617db

    以上方法都是交互过程中最为常用的,其它还有一些重要的方法如GET_PARAMETER,SET_PARAMETER,PAUSE,REDIRECT等等。

ps：
sdp的格式
v=<version>
o=<username> <session id> <version> <network type> <address type> <address>
s=<session name>
i=<session description>
u=<URI>
e=<email address>
p=<phone number>
c=<network type> <address type> <connection address>
b=<modifier>:<bandwidth-value>
t=<start time> <stop time>
r=<repeat interval> <active duration> <list of offsets from start-time>
z=<adjustment time> <offset> <adjustment time> <offset> ....
k=<method>
k=<method>:<encryption key>
a=<attribute>
a=<attribute>:<value>
m=<media> <port> <transport> <fmt list>
v = （协议版本）
o = （所有者/创建者和会话标识符）
s = （会话名称）
i = * （会话信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （电话号码）
c = * （连接信息）
b = * （带宽信息）
z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
时间描述：
t = （会话活动时间）
r = * （0或多次重复次数）
媒体描述：
m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）
k = * （加密密钥）
a = * （0 个或多个媒体属性行）
带*为可选信息。

RTSP的实现

RTSP功能实现结构如下图所示。

RTSP在流媒体传输过程中，仅仅为双方建立连接，并不具备任何智能，也就不能很好地应付难以预料的网络状态。因此，必须在它原有功能的基础上，进行改进。

1、初始化

在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。初始化的目的，是为了获取客户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使客户端获得最佳观看效果。

接到这个请求之后，服务器将根据自身情况进行如下测试：

● 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。

● 采用UDP协议，向客户端下发测试数据包。

测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。

需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。

2、TCP传输

如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的网络状况良好，可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。

当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输。这种传输方式也存在一定的问题：

● 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。

● 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。

● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。

因此，一般情况下，都默认使用RTP over TCP的方式发送数据。

3、UDP传输

如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。

目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。

收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件;否则，认为测试不成功，由于网络状况的限制，仅对客户端下发低码率的电影文件。

在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克出现的主要原因是：

● 不可靠连接造成的网络丢包，为客户端被动丢包。

● 高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包。

但从整体而言，UDP传输消耗的带宽，要比TCP小许多。在一般的视频点播要求下，使用基于UDP的传输线路，是完全可以满足要求的。

4、传输反馈

在传输过程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，还存在一个回传端口RTCP。

在服务器收到客户端的RTCP回传信息后，需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之下，就认为目前传送的视频文件可令客户端获得最大程度的音视频享受;否则，考虑改为传输更低码率的视频文件或放弃这次RTSP会话，以避免更大范围的拥塞。

5、实际效果

采取如上方法设计的系统，可以满足视频点播的基本要求，避免了服务器视频文件下发的盲目性，同时使客户端应用效果最好。

引入智能流技术

随着针对流媒体技术研究的不断深入，简单的流媒体实现已经不能满足人们日益增长的网络文化需求。即使在宽带条件下，当网络用户达到一定限额时，简单的流媒体技术将面临着网络拥塞、丢包等常见的网络问题。因此，如何在网络出现异常的情况下，依然保证客户端音视频享受的最大化，就成为现在研究的热点。

一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲，在RealSystem 5.0中，这种方法称为“视频流瘦化”。这种方法的限制是RealVideo文件必须是一种数据速率设计，结果可通过抽取内部帧扩展到更低速率，导致质量较低，离原始数据速率越远，质量越差。

另一种解决方法是根据不同连接速率创建多个文件，根据用户连接，服务器发送相应文件，这种方法带来制作和管理上的困难，而且，用户连接是动态变化的，服务器也无法实时协调。

智能流技术通过两种途径克服带宽协调和流瘦化:首先，确立一个编码框架，允许不同速率的多个流同时编码，合并到同一个文件中；第二，采用一种复杂客户/服务器机制探测带宽变化。

针对软件、设备和数据传输速度上的差别，用户以不同带宽浏览音视频内容。为满足客户要求，Real Networks公司编码、记录不同速率下媒体数据，并保存在单一文件中，此文件被称为智能流文件，即创建可扩展流式文件。当客户端发出请求时，它将其带宽容量传给服务器，媒体服务器根据客户带宽将智能流文件相应部分传送给用户。以此方式，用户可使用最优质的传输，制作人员只需要压缩一次，管理员也只需要维护单一文件，而媒体服务器根据所得带宽自动切换。智能流通过描述Internet上变化的带宽特点来发送高质量媒体并保证其可靠性，并对混合连接环境的内容授权提供了解决方法。这样流媒体实现方式如下：对所有连接速率环境创建一个文件。在混合环境下以不同速率传送媒体。根据网络的变化情况，无缝切换到其他速率。关键帧优先，音频比部分视频帧数据更重要，向后兼容老版本RealPlayer。

端口说明：554端口默认情况下用于“Real Time Streaming Protocol”（实时流协议，简称RTSP），该协议是由RealNetworks和Netscape共同提出的，通过RTSP协议可以借助于 Internet将流媒体文件传送到RealPlayer中播放，并能有效地、最大限度地利用有限的网络带宽，传输的流媒体文件一般是Real服务器发布的，包括有.rm、.ram。如今，很多的下载软件都支持RTSP协议，比如FlashGet、影音传送带等等。

　　端口漏洞：目前，RTSP协议所发现的漏洞主要就是RealNetworks早期发布的Helix Universal Server存在缓冲区溢出漏洞，相对来说，使用的554端口是安全的。

　　操作建议：为了能欣赏并下载到RTSP协议的流媒体文件，建议开启554端口。

　　1024端口

　　端口说明：1024端口一般不固定分配给某个服务，在英文中的解释是“Reserved”（保留）。之前，我们曾经提到过动态端口的范围是从 1024～65535，而1024正是动态端口的开始。该端口一般分配给第一个向系统发出申请的服务，在关闭服务的时候，就会释放1024端口，等待其他服务的调用。

　　端口漏洞：著名的YAI木马病毒默认使用的就是1024端口，通过该木马可以远程控制目标计算机，获取计算机的屏幕图像、记录键盘事件、获取密码等，后果是比较严重的。

　　操作建议：一般的杀毒软件都可以方便地进行YAI病毒的查杀，所以在确认无YAI病毒的情况下建议开启该端口。

　　1080端口

　　端口说明：1080端口是Socks代理服务使用的端口，大家平时上网使用的WWW服务使用的是HTTP协议的代理服务。而Socks代理服务不同于HTTP代理服务，它是以通道方式穿越防火墙，可以让防火墙后面的用户通过一个IP地址访问Internet。Socks代理服务经常被使用在局域网中，比如限制了QQ，那么就可以打开QQ参数设置窗口，选择“网络设置”，在其中设置Socks代理服务（如图1）。另外，还可以通过安装Socks代理软件来使用QQ，比如Socks2HTTP、SocksCap32等。

　　端口漏洞：著名的代理服务器软件WinGate默认的端口就是1080，通过该端口来实现局域网内计算机的共享上网。不过，如 Worm.Bugbear.B（怪物II）、Worm.Novarg.B（SCO炸弹变种B）等蠕虫病毒也会在本地系统监听1080端口，给计算机的安全带来不利。

　　操作建议：除了经常使用WinGate来共享上网外，那么其他的建议关闭该端口。

　　1755端口

　　端口说明：1755端口默认情况下用于“Microsoft Media Server”（微软媒体服务器，简称MMS），该协议是由微软发布的流媒体协议，通过MMS协议可以在Internet上实现Windows Media服务器中流媒体文件的传送与播放。这些文件包括.asf、.wmv等，可以使用Windows Media Player等媒体播放软件来实时播放。其中，具体来讲，1755端口又可以分为TCP和UDP的MMS协议，分别是MMST和MMSU，一般采用TCP 的MMS协议，即MMST。目前，流媒体和普通下载软件大部分都支持MMS协议。

　　端口漏洞：目前从微软官方和用户使用MMS协议传输、播放流媒体文件来看，并没有什么特别明显的漏洞，主要一个就是MMS协议与防火墙和 NAT（网络地址转换）之间存在的兼容性问题。

　　操作建议：为了能实时播放、下载到MMS协议的流媒体文件，建议开启该端口。
6.3.3 RTSP 信息
RTSP 是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。
10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。
如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
服务器关闭连接。
注意：RTSP目前并不支持HTTP/1.1"块"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
6.3.4 实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
6.3.5 连接
RTSP请求可以几种不同方式传送：
1、持久传输连接，用于多个请求/响应传输。
2、每个请求/响应传输一个连接。
3、无连接模式。
传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用RTSP 请求发送，而不用建立连接。
不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
6.3.6 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。
当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过 RTP/RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
6.3.7 流水线操作
支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。
RTT 在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与 RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头

7.RTSP状态码

8.实例

以下是某省IPTV的RTSP协商过程：

DESCRIBE rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp?playtype=1&boid=001&backupagent=118.122.89.27:554&clienttype=1&time=20100929182111+08&life=172800&ifpricereqsnd=1&vcdnid=001&userid=123&mediaid=ch10083121594790060557&ctype=2&TSTVTimeLife=1800&contname=&authid=0&UserLiveType=1&nodelevel=3 RTSP/1.0
/媒体URL
Accept: application/sdp
//协商用于描述媒体信息协议
CSeq: 1

User-Agent:ZTE Ltd.co RTSP protocal verion 1.0 guid-2.1.1.100/B519D290-C0EC-EE35-7368-893BE4C0B347
//User Agnet信息，显示是中兴的服务器，1.0的版本。如果是Helix服务器的话会有Helix 服务器的标识。
x-NAT:2.1.1.100:20081
//主要用于NAT穿透
x-zmssRtxSdp: yes

RTSP/1.0 200 OK
//应答编号
Server: ZXUSS100 1.0

Cache-Control: no-cache

Content-Base: rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp/

Content-Length: 320
//内容长度信息
Content-Type: application/sdp
//描述内容信息所用的协议
CSeq: 1

Date: Wed, 29 Sep 2010 10:20:38 GMT

Expires: Wed, 29 Sep 2010 10:20:38 GMT
// SDP 描述信息

v=0

o=- 296874273 1 IN IP4 118.122.89.27

s=envivio

c=IN IP4 0.0.0.0

b=AS:1500

t=0 0

a=range:clock=20100929T095038.00Z-20100929T102038.00Z

m=video 5140 RTP/AVPF 33 96

a=control:trackID=2

a=rtpmap:33 MP2T/90000

a=3GPP-Adaptation-Support:5

a=rtcp-fb:33 nack

a=rtpmap:96 rtx/90000

a=fmtp:96 apt=33;rtx-time=0

SETUP rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp/trackID=2 RTSP/1.0
//用于建立RTSP连接，协商传输用的协议。
CSeq: 2

3GPP-Adaptation: url=rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp/trackID=2;size=1061400;target-time=2200

Transport: MP2T/RTP/UDP;unicast;destination=2.1.1.100;client_port=8360-8361,MP2T/RTP/TCP;unicast;destination=2.1.1.100;interleaved=0-1,MP2T/UDP;unicast;destination=2.1.1.100;client_port=8360-8361,MP2T/TCP;unicast;destination=2.1.1.100;interleaved=0-1
// MP2T/RTP/UDP表示是TS流用于RTP打包，基于UDP传输。MP2T/RTP/TCP表示是TS流用于RTP打包，基于TCP。
User-Agent:ZTE Ltd.co RTSP protocal verion 1.0 guid-2.1.1.100/B519D290-C0EC-EE35-7368-893BE4C0B347

RTSP/1.0 200 OK

Server: ZXUSS100 1.0

CSeq: 2

Date: Wed, 29 Sep 2010 10:20:38 GMT

Expires: Wed, 29 Sep 2010 10:20:38 GMT

Session: 65565885

Transport: MP2T/RTP/UDP;unicast;destination=2.1.1.100;client_port=8360-8361;server_port=13306-13307;source=118.122.89.29
// 通过协商MP2T/RTP/UDP表示是TS流用于RTP打包，基于UDP传输。server端端口：13306-13307。client端端口：8360-8361
3GPP-Adaptation:url=rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp/trackID=2;size=1061400;target-time=2200

PLAY rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp?playtype=1&boid=001&backupagent=118.122.89.27:554&clienttype=1&time=20100929182111+08&life=172800&ifpricereqsnd=1&vcdnid=001&userid=123&mediaid=ch10083121594790060557&ctype=2&TSTVTimeLife=1800&contname=&authid=0&UserLiveType=1&nodelevel=3 RTSP/1.0
//播放视频。对于有些视频可能会分别要对音频视频进行play。
CSeq: 3

Session: 65565885

User-Agent:ZTE Ltd.co RTSP protocal verion 1.0 guid-2.1.1.100/B519D290-C0EC-EE35-7368-893BE4C0B347

Scale: 1.0

Range: npt=end-

//npt=end-在IPTV2.0里面有其自身的定义（可参看上海电信IPTV2.0标准）

RTSP/1.0 200 OK

Server: ZXUSS100 1.0

CSeq: 3

Range: npt=end-

Scale: 1.0

Session: 65565885

RTP-Info: url=rtsp://118.122.89.29:13306/live/ch10083121594790060557.sdp/trackID=2

......

PLAY rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp?playtype=1&boid=001&backupagent=118.122.89.27:554&clienttype=1&time=20100929182111+08&life=172800&ifpricereqsnd=1&vcdnid=001&userid=123&mediaid=ch10083121594790060557&ctype=2&TSTVTimeLife=1800&contname=&authid=0&UserLiveType=1&nodelevel=3 RTSP/1.0
//play的另外一种用法。用于快进和快退。
CSeq: 43

Session: 65565885

User-Agent:ZTE Ltd.co RTSP protocal verion 1.0 guid-2.1.1.100/B519D290-C0EC-EE35-7368-893BE4C0B347

Scale: -32.0
//Scale: -32.0，表示以32倍速快退。Scale: 32.0，表示以32倍速快进。
Range: npt=now-

RTSP/1.0 200 OK

Server: ZXUSS100 1.0

CSeq: 43

Range: clock=20100929T102609.02Z-20100929T095637.75Z

Scale: -32.0

Session: 65565885

RTP-Info: url=rtsp://118.122.89.36:10084/live/ch10083121594790060557.sdp/trackID=2;seq=22277;rtptime=1792329138

GET_PARAMETER rtsp://118.122.89.27:554/live/ch10083121594790060557.sdp?playtype=1&boid=001&backupagent=118.122.89.27:554&clienttype=1&time=20100929182111+08&life=172800&ifpricereqsnd=1&vcdnid=001&userid=123&mediaid=ch10083121594790060557&ctype=2&TSTVTimeLife=1800&contname=&authid=0&UserLiveType=1&nodelevel=3 RTSP/1.0
//获取当前的一些播放参数。
CSeq: 44

Session: 65565885

User-Agent:ZTE Ltd.co RTSP protocal verion 1.0 guid-2.1.1.100/B519D290-C0EC-EE35-7368-893BE4C0B347

x-Timeshift_Range
//请求时移的范围
x-Timeshift_Current
//获取当前的时间点

RTSP/1.0 200 OK
//返回当前的媒体信息。
Server: ZXUSS100 1.0

CSeq: 44

Session: 65565885

x-Timeshift_Range: clock=20100929T095638.83Z-20100929T102638.83Z

x-Timeshift_Current: clock=20100929T102530.20Z;rtptime=1788844914

中间省去了45，46，47三个包。通过CSeq: 48字段可以看出来

Session: 65565885

User-Agent:ZTE Ltd.co RTSP protocal verion 1.0 guid-2.1.1.100/B519D290-C0EC-EE35-7368-893BE4C0B347

Scale: 1.0

Range: npt=beginning-

RTSP/1.0 200 OK

Server: ZXUSS100 1.0

CSeq: 48

Range: clock=20100929T095730.00Z-20100929T102730.61Z
//可以时移的范围。
Scale: 1.0

Session: 65565885

RTP-Info: url=rtsp://118.122.89.36:10084/live/ch10083121594790060557.sdp/trackID=2;seq=39900;rtptime=1637595010

＜中间在Descript应答中所用的ＳＤＰ协议将会在以后中描述＞