FFmpeg入门详解之111：RTSP协议2

rtsp消息详解

1.RTSP的消息有两大类，一是请求消息(request)，一是回应消息(response)，两种消息的格式不同。

请求消息格式：

方法 URI RTSP版本 CR LF

消息头 CR LF CR LF

消息体 CR LF

方法包括：OPTIONS、SETUP、PLAY、TEARDOWN DESCRIBE

URI是接收方（服务端）的地址，例如：rtsp://192.168.22.136:5000/v0

每行后面的CR LF表示回车换行，需要接收端有相应的解析，消息头需要有两个CR LF。

DESCRIBE  rtsp://192.168.1.211   RTSP/1.0

CSeq: 1

Accept: application/sdp

User-Agent: magnus-fc

回应消息格式：

RTSP版本 状态码 解释 CR LF

消息头 CR LF CR LF

消息体 CR LF

2.请求消息格式,CR LF表示回车换行

       方法 URI RTSP版本 CR LF

       消息头 CR LF CR LF         

       消息体 CR LF

3.OPTIONS命令， 得到服务器上可用的方法

   CSeq头要从1开始，服务器针对请求命令的应答也应该有相同的CSeq头，这样可以知道是针对哪条请求发的应答。

请求示例：

OPTIONS rtsp://video.fjtu.com.cn:80/vs01/flws/flws_01.rm RTSP/1.0

CSeq: 1

User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)

响应示例：

RTSP/1.0 200 OK

CSeq: 1

Date: Tue, 29 May 2012 06:19:53 GMT

Server: Helix Server Version 11.1.0.719 (win32) (RealServer compatible)

Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, PAUSE, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN

TurboPlay: 1

RealChallenge1: 1105b1d46a973db1bc7787d1adca20d6

StatsMask: 8

4.DESCRIBE 为了得到会话描述信息SDP

请求示例：

DESCRIBE rtsp://video.fjtu.com.cn:80/vs01/flws/flws_01.rm RTSP/1.0

CSeq: 2

Authorization: Basic YWRtaW4=

User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25)

Accept: application/sdp

响应示例：

RTSP/1.0 200 OK

CSeq: 2

Date: Tue, 29 May 2012 06:48:38 GMT

Set-Cookie: cbid=efjgfmdicjckhldmeorrgplqmojrktluekjgkidlegcfdlplmnmrqprtqrrsltmudfhjjmhl;path=/;expires=Thu,31-Dec-2037 23:59:59 GMT

vsrc: http://video.fjtu.com.cn:80/viewsource/template.html?nuyhtgfcswz6bdE057Axc8chvqrEsfaba5E6qvm6wfy23p4efqDCr4x3gEf6Bs9wr4enf6r4ovCoa7Dqjlh87pp257e5w48bjd2hA1

Last-Modified: Thu, 10 Apr 2003 02:16:54 GMT

Content-base: rtsp://video.fjtu.com.cn:80/vs01/flws/flws_01.rm/

Vary: User-Agent, ClientID

Content-type: application/sdp

x-real-usestrackid: 1

Content-length: 2207

(以下都是SDP信息)

v=0

o=- 1049941014 1049941014 IN IP4 210.34.46.23

s=

i=

c=IN IP4 0.0.0.0

t=0 0

a=SdpplinVersion:1610641560

a=StreamCount:integer;2

a=control:*

a=Flags:integer;11

a=IsRealDataType:integer;1

a=Author:buffer;"uKO9qMqmt7a089GnzfjC59Gn1LoA"

a=Copyright:buffer;"uKO9qMqmt7a089GnzfjC59Gn1LoA"

a=Title:buffer;"t6jCyc7EyukgILXa0ru9sgA="

a=range:npt=0-2672.331000

m=audio 0 RTP/AVP 101  //这里指示音频流

b=AS:8

b=RR:243

b=RS:81

a=control:streamid=0

a=range:npt=0-2672.331000

a=length:npt=2672.331000

a=rtpmap:101 x-pn-realaudio/1000

a=fmtp:101 

a=mimetype:string;"audio/x-pn-realaudio"

a=Helix-Adaptation-Support:1

a=ActualPreroll:integer;1713

a=AvgBitRate:integer;6500

a=AvgPacketSize:integer;232

a=EndOneRuleEndAll:integer;1

a=EndTime:integer;2671699

a=MaxBitRate:integer;6500

a=MaxPacketSize:integer;232

a=Preroll:integer;3426

a=OpaqueData:buffer;"LnJh/QAEAAAucmE0ZgVhxwAEAAAAOQAAAAAA6AAg7CAAALzN+fn5+QAGAOgAAAAAH0AAAAAQAAEEc2lwcgRzaXByAQcAAAAAAA=="

a=RMFF 1.0 Flags:buffer;"AAIAAgAA"

a=ASMRuleBook:string;"priority=5,averagebandwidth=6500,PNMKeyFrameRule=T;priority=5,averagebandwidth=0,PNMNonKeyFrameRule=T,OnDepend="0",OffDepend="0";"

a=intrinsicDurationType:string;"intrinsicDurationContinuous"

a=StreamName:string;"Audio Stream"

m=video 0 RTP/AVP 101   //这里指示视频流

b=AS:15

b=RR:506

b=RS:168

a=control:streamid=1

a=range:npt=0-2671.546000

a=length:npt=2671.546000

a=rtpmap:101 x-pn-realvideo/1000

a=fmtp:101 

a=mimetype:string;"video/x-pn-realvideo"

a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;13500

a=AvgPacketSize:integer;506

a=EndOneRuleEndAll:integer;1

a=MaxBitRate:integer;13500

a=MaxPacketSize:integer;607

a=Preroll:integer;3539

a=OpaqueData:buffer;"AAAAJlZJRE9SVjMwAPgAyAAMAAAAAAAPAAABCpAwMCAgAiwkPjI="

a=RMFF 1.0 Flags:buffer;"AAMAAgAAAAI="

a=ASMRuleBook:string;"#($Bandwidth >= 13500),priority=9,averagebandwidth=13500,PNMKeyFrameRule=T;#($Bandwidth >= 13500),OnDepend="0",priority=5,averagebandwidth=0,PNMNonKeyFrameRule=T;#($Bandwidth < 13500),priority=9,timestampdelivery=T,DropByN=T,PNMThinningRule=T;"

a=intrinsicDurationType:string;"intrinsicDurationContinuous"

a=StreamName:string;"Video Stream"

SDP文本说明：

v=0 //指示协议的版本。

o=- 1049941014 1049941014 IN IP4 210.34.46.23 // 与会话所有者有关的六个参数：

第一个参数表明会话发起者的名称，该参数可不填写，如填写和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协议。

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

m=指示在媒体数据中都有哪些流，及其类型，如

m=audio 0 RTP/AVP 101  //指示音频流

m=video 0 RTP/AVP 101   //指示视频流

m=application 0 RTP/AVP 96 //控制流，不携带媒体内容

a=control:后的值表示流的标识 ，如 a=control:streamid=1 ， a=control:trackID=0

a=rtpmap:0   PCMU

       a=rtpmap:96  G726-32/8000

       a=rtpmap:97  AMR-WB

    a行为媒体的属性行，以属性的名称：属性值的方式表示。

    格式为：a=rtpmap:<净荷类型><编码名称>

l净荷类型0固定分配给了PCMU，

l净荷类型96对应的编码方案为G.726,为动态分配的。

l净荷类型97对应的编码方式为自适应多速率宽带编码（AMR-WB），为动态分配的。   

        

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

SETUP请求的作用是指明媒体流该以什么方式传输；每个流PLAY之前必须执行SETUP操作；发送SETUP请求时，客户端会指定两个端口，一个端口用于接收RTP数据；另一个端口接收RTCP数据，偶数端口用来接收RTP数据，相邻的奇数端口用于接收RTCP数据！

32010-32011

image.png

SETUP表明消息类型；

URI表示请求的RTSP服务器的地址；

RTSP_VER表明RTSP的版本；

TRANSPORT表明媒体流的传输方式，具体包括传输协议如RTP/UDP；指出是单播，组播还是广播；声明两个端口，一个奇数，用于接收RTCP数据（统计与控制信息），一个偶数，用于接收RTP数据（音视频数据流）；

CSeq数据包请求序列号；

User-Agent指明用户代理；

Session标识会话ID；

Authorization标识认证信息；

请求示例：

SETUP rtsp://192.17.1.63:554/trackID=1 RTSP/1.0

Transport: RTP/AVP/UDP;unicast;client_port=26968-26969

CSeq: 4

User-Agent: Lavf58.42.100

Authorization: Digest username="admin", realm="IP Camera(23306)", nonce="a946c352dd3ad04cf9830d5e72ffb11e", uri="rtsp://192.17.1.63:554/trackID=1", response="e29ca030062df6022faa77fefde40b28"

该SETUP请求中，Transport字段声明了两个端口，26968和26969，同时指明了通过UDP发送RTP数据，26968端口用来接收RTP数据，26969端口用来接收RTCP数据,unicast表示传输方式为单播！

请求之后，如果没有异常情况，RTSP服务器的回复比较简单，回复200 OK消息，同时在Transport字段中增加sever_port，指明对等的服务端RTP和RTCP传输的端口，增加ssrc字段，增加mode字段，同时返回一个session id，用于标识本次会话连接，之后客户端发起PLAY请求的时候需要使用该字段，回复消息大概结构如下图：

响应示例：

RTSP/1.0 200 OK

CSeq: 4

Session: 337474243;timeout=60

Transport: RTP/AVP/UDP;unicast;client_port=26968-26969;server_port=8284-8285;ssrc=4a7fb757;mode="play"

Date: Fri, Apr 10 2020 19:07:19 GMT

解释：

uri中 带有trackID＝0，表示对该通道进行设置。

Transport参数设置了传输模式，包的结构。

RTP/AVP表示默认使用UDP传输RTP包，RTP/AVP/TCP表示通过TCP传输RTP包。

unicast表示单一传播。

client_port值中-前的表示客户端的接收RTP包的端口，-后的表示客户端的接收RTCP包的端口。

如果采用TCP方式传送，传送的RTP，RTCP包都在同一个链路上，需要区分，所以有了interleaved，0表示是RTP的通道，1表示是RTCP的通道，interleaved值有两个：0和1，0表示RTP包，1表示RTCP包，接收端根据interleaved的值来区别是哪种数据包。

rtsp方法定义

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

RTSP方法

RTSP方法

方法方向对象要求含义

DESCRIBEC->SP，S推荐检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式。DESCRIBE的答复-响应组成媒体RTSP初始阶段

ANNOUNCEC->S

S->CP，S可选当从用户发往服务器时，ANNOUNCE将请求URL识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE实时更新连接描述。如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除

GET_PARAMETERC->S

S->CP，S可选GET_PARAMETER请求检查URL指定的演示与媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况

OPTIONSC->S

S->CP，S要求可在任意时刻发出OPTIONS请求，如用户打算尝试非标准请求，并不影响服务器状态

PAUSEC->SP，S推荐PAUSE请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在SETUP消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订

PLAYC->SP，S要求PLAY告诉服务器以SETUP指定的机制开始发送数据；直到一些SETUP请求被成功响应，客户端才可发布PLAY请求。PLAY请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY请求可排成队列，服务器将PLAY请求排成队列，顺序执行

RECORDC->SP，S可选该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201（创建），并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte格式没有意义

REDIRECTS->CP，S可选重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求

SETUPC->SS要求对URL的SETUP请求指定用于流媒体的传输机制。客户端对正播放的流发布一个SETUP请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响

SET_PARAMETERC->S

S->CP，S可选这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示

TEARDOWNC->SP，S要求TEARDOWN请求停止给定URL流发送，释放相关资源。如URL是此演示URL，任何RTSP连接标识不再有效。除非全部传输参数是连接描述定义的，SETUP请求必须在连接可再次播放前发布

注：P----演示，S----流，C----用户端，S----服务器端

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

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

状态

RTSP状态机

RTSP控制通过单独协议发送的数据流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用： 

（1） SETUP：让服务器给流分配资源，启动RTSP连接。

（2） PLAY与RECORD：启动SETUP分配流的数据传输。

（3） PAUSE：临时停止流，而不释放服务器资源。

（4） TEARDOWN：释放流的资源，RTSP连接停止。

标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。

RTSP与HTTP

实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。

然而，在很多重要方面RTSP仍不同于HTTP：

RTSP引入了大量新方法并具有一个不同的协议标识符；

在大多数情况下，RTSP服务器需要保持缺省状态，与HTTP的无状态相对；

RTSP中客户端和服务器都可以发出请求；

在多数情况下，数据由不同的协议传输；

RTSP使用ISO 10646（UTF-8）而并非ISO 8859-1，与当前的国际标准HTML相一致；

URI请求总是包含绝对URI。为了与过去的错误相互兼容，HTTP/1.1只在请求过程中传送绝对路径并将主机名置于另外的头字段。

RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP。

但是，RTSP与HTTP的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近时，在缓存、代理和授权上采用HTTP功能是有价值的。

当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。

RTSP视频监控与直播

GB/T--28181

国标GB/T28181由公安部科技信息化局提出，该标准规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求。

GB/T28181不仅包括设备间的级联，也包含系统的级联，故并不矛盾。如网络摄像机通过ONVIF协议接入NVR，NVR在通过GB/T28181标准接入平台，或者网络摄像机通过ONVIF协议接入平台，平台间的级联通过GB/T28181规范进行。故ONVIF/PSIA、与GB/T28181往往还能起到互补的作用，可以使设备选型、推广更为广泛，更好地推动平安城市网络化、高清化的进程。

当RTSP或者Onvif等局域网监控其他IP视频需要转公网直播(rtmp/hls/ts)等，比如景区监控直播或者校园监控直播都可以实现多机位多角度切换功能；如果将小区、公园、企事业单位等传统的监控链接到公安部天网系统都可能会涉及到各种协议流相互转换。