RTSP协议详解

最新推荐文章于 2025-03-31 17:44:35 发布
最新推荐文章于 2025-03-31 17:44:35 发布
阅读量2.1k 收藏 2
点赞数
分类专栏： 网络 文章标签： linux rtsp sdp 取流 流媒体

第一部分:RTSP协议

  1. RTSP协议概述

RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。

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

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

  1. RTSP协议与HTTP协议区别

    1. RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP等，并且有不同的协议标识符，RTSP为rtsp1.0,HTTP为http1.1；

    2. HTTP是无状态的协议，而RTSP为每个会话保持状态；

    3. RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTPF协议中，只有客户端能发送Request请求。

    4. 在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。

    5. 使用ISO10646(UTF-8) 而不是ISO8859-1，以配合当前HTML的国际化；

    6. RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中；

  2. RTSP重要术语

    1. 集合控制(Aggregatecontrol ):

对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。

    1. 实体(Entity)：

作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-headerfield）形式存在的元信息和以实体主体（entitybody）形式存在的内容组成

    1. 容器文件（Containerfile）：

可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。

    1. RTSP会话(RTSPsession )：

RTSP交互的全过程。对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。

  1. RTSP请求消息

    1. 消息格式：

方法 URI RTSP版本      CRLF

       消息头 CRLF          CRLF         

       消息体 CRLF


其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp。

RTSP版本一般都是RTSP/1.0。每行后面的CRLF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CRLF

消息体是可选的，有的Request消息并不带消息体。

  1. RTSP回应消息

    1. 消息格式：

       RTSP版本状态码解释     CRLF

       消息头 CRLF          CR LF

       消息体 CRLF

其中RTSP版本一般都是RTSP/1.0,状态码是一个数值，用于表示Request消息的执行结果,比如200表示成功,解释是与状态码对应的文本解释.

  1. RTSP重要方法

    1. OPTIONS:

用于得到服务器提供的可用方法；

如:

OPTIONSrtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq:1        

服务器的回应信息会在Public字段列出提供的方法。如:

RTSP/1.0200 OK

CSeq:1        //每个回应消息的cseq数值和请求消息的cseq相对应

Public:OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

    1. DESCRIBE：

客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept头指定客户端可以接受的媒体述信息类型。

如：

C->S:DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq:312

Accept:application/sdp, application/rtsl, application/mheg)


服务器回应URI指定媒体的描述信息:

如:

S->C:RTSP/1.0 200 OK

CSeq:312

Date:23 Jan 1997 15:35:06 GMT

Content-Type:application/sdp //表示回应为SDP信息

Content-Length:376

//这里为一个空行

//以下为具体的SDP信息

v=0

o=mhandley2890844526 2890842807 IN IP4 126.16.64.4

s=SDPSeminar

i=ASeminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu(Mark Handley)

c=INIP4 224.2.17.12/127

t=28733974962873404696

a=recvonly

m=audio3456 RTP/AVP 0

m=video2232 RTP/AVP 31

m=whiteboard32416 UDP WB

a=orient:portrait


媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过以下方法来接收媒体描述信息：

    1. 通过DESCRIBE方法；

    2. 其它一些协议（HTTP，email附件，等）；

    3. 通过命令行或标准输入设备

    1. SETUP：

用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455Method Not Valid In This State"。

Request中的Transport头字段指定了客户端可接受的数据传输参数；Response中的Transport头字段包含了由服务器选出的传输参数。

如:

C->S:SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0

CSeq:302

Transport:RTP/AVP;unicast;client_port=4588-4589


服务器端对SETUPRequest产生一个SessionIdentifiers。

如:

S->C:RTSP/1.0 200 OK

CSeq:302

Date:23 Jan 1997 15:35:06 GMT

Session:47112344 //产生一个SessionID

Transport:RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257


    1. PLAY：

PLAY方法告知服务器通过SETUP中指定的机制开始发送数据。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。

PLAY请求将正常播放时间（normalplaytime）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。

比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。

C->S:PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq:835

Session:12345678

Range:npt=10-15


C->S:PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq:836

Session:12345678

Range:npt=20-25


C->S:PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq:837

Session:12345678

Range:npt=30-


Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。

不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点（thepause point）重新开始。

如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。

    1. PAUSE：

PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。比如，指定暂停音频，播放将会无声。如果请求URL指定了一组流，那么在该组中的所有流的传输将被暂停。如：

C->S:PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq:834

Session:12345678


S->C:RTSP/1.0 200 OK

CSeq:834

Date:23 Jan 1997 15:35:06 GMT



PAUSE请求中可能包含一个Range头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pausepoint）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。如果Range头指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457Invalid Range"。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。

    1. TEARDOWN：

TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。如：

C->S:TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq:892

Session:12345678


S->C:RTSP/1.0 200 OK

CSeq:892

  1. RTSP重要头字段参数

    1. Accept:

用于指定客户端可以接受的媒体描述信息类型。比如:

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

    1. Bandwidth:

用于描述客户端可用的带宽值。

    1. 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

    1. Rang：

用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元。

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

Range: clock=19960213T143205Z-;time=19970123T143720Z

    1. Session:

Session头字段标识了一个RTSP会话。SessionID 是由服务器在SETUP的回应中选择的，客户端一当得到SessionID后，在以后的对Session的操作请求消息中都要包含SessionID.

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

Session语法结构：

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

例子：

Session: 12345678

    1. Transport:

Transport头字段包含客户端可以接受的转输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如:

Transport:RTP/AVP;multicast;ttl=127;mode="PLAY",

RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"


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

常用参数：

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"

7.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

      8.User-Agent

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

例子：

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

  1. 简单的RTSP消息交互过程

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

  1. 第一步：查询服务器端可用方法

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

1.S->C:OPTIONresponse    //S回应信息的public头字段中包括提供的所有可用方法

  1. 第二步：得到媒体描述信息

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

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

  1. 第三步：建立RTSP会话

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

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

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

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

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

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

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

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

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

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

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

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

第二部分:SDP协议

  1. SDP协议概述

SDP(SessionDescription Protocol)会话描述协议，用于描述多媒体会话，它为会话通知、会话初始和其它形式的多媒体会话初始等操作提供服务。

SDP的设计宗旨是通用性协议，所有它可以应用于很大范围的网络环境和应用程序，但SDP不支持会话内容或媒体编码的协商操作。

SDP信息包括：

  • 会话名称和目标；

  • 会话活动时间；

  • 构成会话的媒体；

  • 有关接收媒体的信息、地址等。

  1. SDP格式

SDP信息是文本信息，UTF-8编码采用 ISO10646 字符设置。SDP会话描述如下（标注*符号的表示可选字段）：

  • v=（协议版本）

  • o=（所有者/创建者和会话标识符）

  • s=（会话名称）

  • i=*（会话信息）

  • u=* （URI描述）

  • e=*（Email地址）

  • p=*（电话号码）

  • c=*（连接信息 ―如果包含在所有媒体中，则不需要该字段）

  • b=*（带宽信息）

　　一个或更多时间描述（如下所示）：

  • z=*（时间区域调整）

  • k=*（加密密钥）

  • a=*（0个或多个会话属性线路）

  • 0个或多个媒体描述（如下所示）

　　时间描述

  • t=（会话活动时间）

  • r=*（0或多次重复次数）

　　媒体描述

  • m=（媒体名称和传输地址）

  • i=*（媒体标题）

  • c=*（连接信息 —如果包含在会话层则该字段可选）

  • b=*（带宽信息）

  • k=*（加密密钥）

  • a=*（0个或多个会话属性线路）

  1. SDP示例

v=0

o=mhandley2890844526 2890842807 IN IP4 126.16.64.4

s=SDPSeminar

i=ASeminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu(Mark Handley)

c=INIP4 224.2.17.12/127

t=28733974962873404696

a=recvonly

m=audio49170 RTP/AVP 0

m=video51372 RTP/AVP 31

m=application32416 udp wb

a=orient:portrait


//字段解释

V=0 ;Version 给定了SDP协议的版本

o=<username><session id> <version> <network type> <addresstype>

<address>；Origin,给定了会话的发起者信息

s=<sessionname> ;给定了SessionName

i=<sessiondescription> ; Information关于Session的一些信息

u=<URI>; URI

e=<emailaddress> ;Email

c=<networktype> <address type> <connection address> ;ConnectData包含连接数据

t=<starttime> <stop time> ;Time

a=<attribute> ; Attribute

a=<attribute>:<value>

m=<media><port> <transport> <fmt list> ; MediaAnnouncements

转载：http://blog.youkuaiyun.com/yangzhongxuan/article/details/8198229

一文读懂RTSP协议-【RTSP协议详解】
yinshipin007的博客
09-03 4757
接下来的数据包头部第二个字节位置就是interleaved，它的值是每个通道都不同的，trackID＝0的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接受端根据interleaved的值来区别是哪种数据包。其中方法包括OPTIONS、SETUP、PLAY、TEARDOWN等待，URI是接收方（服务端）的地址，例如：rtsp://192.168.22.136:5000/v0，每行后面的CR LF表示回车换行，需要接收端有相应的解析，最后一个消息头需要有两个CR LF。
RTSP协议分析
08-31
RTSP协议分析 rtp_over_rtsp精简分析 rfc2326(RTSP) 详细文档说明 RTSP协议资料 几个文档资料比较全
RTSP协议介绍
husthlj的专栏
08-05 1934
1. 实时流协议RTSP RTSP[3]协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。 1.1.   RTSP协议简介 要实现 RTS
RTSP协议简单实现
最新发布
m0_50127633的博客
03-31 282
RTSP是一个实时传输流协议，是一个应用层的协议。通常说的RTSP 包括RTSP协议、RTP协议、RTCP协议，对于这些协议的作用简单的理解如下：负责服务器与客户端之间的请求与响应： 负责服务器与客户端之间传输媒体数据：负责提供有关RTP传输质量的反馈，就是确保RTP传输的质量三者的关系：。rtp和rtcp并没有规定传输层的类型，可以选择udp和tcp。Rtsp的传输层则要求是基于tcp。
RTSP协议
chenchizhao的专栏
06-06 797
RTSP协议 因为项目需要，学习了一下RTSP协议，为了防止以后忘记，就把学习过程和成果记载下来。期间参考了一些网上的资料，并分析了VLC的RTSP报文。     RTSP（Real Time Streaming Protocol，实时流协议），是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，能够提供可控制
RTSP协议解析
rongdeguoqian的专栏
01-05 2万+
RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。 一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、
rtsp协议笔记
04-25 2862
RTSP协议学习笔记... 1 第一部分:RTSP协议... 3 一、       RTSP协议概述... 3 二、       RTSP协议与HTTP协议区别... 3 三、       RTSP重要术语... 4 1.       集合控制(Aggregatecontrol ):. 4 2.       实体(Entity)：... 4 3.       容器文件
RTSP协议详解.zip
09-16
RTSP协议的核心概念包括会话（Session）、播放器（Client）、服务器（Server）以及媒体源（Media Server）。客户端通过发送RTSP请求来控制服务器上的媒体流，服务器则响应这些请求，执行相应的操作。RTSP协议使用TCP...
RTSP协议详解-RTSP
05-20
关于 RTSP. RTSP 协议是一个非常类似 HTTP 协议的流控制协议。它们都使用纯文本来发送信息，而且 rtsp 协议的语法也和 HTTP 类似。 Rtsp 一开始这样设计，也是为了能够兼容使用以前写的 HTTP 协议分析代码 。这是个好消息。
RTSP协议基本分析
万事亨通
12-01 2928
目录一、介绍二、RTSP与HTTP三、RTSP推流过程1、OPTION 查询服务器端可用方法2、ANNOUNCE 发送媒体描述信息3、SETUP建立RTSP会话 一、介绍 RTSP(Real-Time Stream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面， RTSP协议与HTTP协议类似。 RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的⻆色。尽管有时可以把 RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数
网络流媒体协议之——RTSP协议
热门推荐
牧羊女
01-29 6万+
RTSP(Real-Time Stream Protocol)协议是一个基于文本的多媒体播放控制协议，属于应用层。RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。 RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而
RTSP协议全面解析
hello.reader
10-19 4018
实时流传输协议（Real-Time Streaming Protocol，简称RTSP）是一种应用层协议，专门用于控制多媒体流的传输。RTSP的主要作用是管理流媒体的连接和控制操作，比如播放、暂停和停止，而实际的媒体传输通常由RTP（Real-time Transport Protocol）或其他协议来完成。RTSP本身并不处理媒体内容的编码或解码工作，而是用于定义如何在客户端与服务器之间建立和控制媒体流会话。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值