国标28181：什么是RTSP协议

前言

RTSP出现之前，最热的大概就是HTTP协议。想象一下，当你需要欣赏网络中的某一段视频，通过HTTP协议访问其URL、开始下载、下载完成之后播放。对于早期的视频采集设备、网络带宽或是负责渲染的显示器而言，似乎多给予一点耐心、多重连几次断开的HTTP连接、甚至多校验几次下载后文件的完整性，体验上也还能过得去。毕竟那时候的分辨率、帧率、带宽限制了互联网途径传播媒体文件的大小，信息的分享只能通过各种硬盘、U盘、光盘以存储后文件的形式进行传输。

随着硬件设备技术的发展，采集设备分辨率在提升，显示器支持了更高的帧率，网络带宽也指数增长，这都为更好的观影体验提供了基础支持。随着网络资源的日益丰富，用户时间的稀缺性日益凸显，为了快速观看、判别视讯本身是否符合自身口味，在线实时观看成了一大诉求。而传统的HTTP下载显然不能够完全匹配该需求，因此在寻求streaming的道路上，RTSP脱颖而出。

RTSP全程实时流协议（Real Time Streaming Protocol），它是一个网络控制协议，设计用于娱乐、会议系统中控制流媒体服务器。RTSP用于在希望通讯的两端建立并控制媒体会话（session），客户端通过发出VCR-style命令如play、record和pause等来实时控制媒体流。

什么是rtsp

RTSP（Real Time Streaming Protocol 实时流协议）建立并控制一个或几个时间同步的连续流媒体，对媒体流提供了诸如开始、暂停、快进、停止等控制，RTSP的作用相当于流媒体服务器的远程控制，而它本身并不传输数据。对应文档： RFC 2326 - Real Time Streaming Protocol (RTSP)

• RTSP协议是一个多媒体控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，因此 RTSP 又称为“因特网录像机遥控协议”。
• RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法以及一些消息参数等方面，RTSP协议与HTTP协议类似，是TCP/IP协议体系中的一个应用层协议， 由哥伦比亚大学, 网景和RealNetworks公司提交的IETF RFC标准。该协议用于CS模型，是一个基于文本的协议，用于在客户端和服务端建立和协商实时流会话

几个特点：

• 服务端和客户端都是双向的。除了客户端可以请求服务端之外，服务端也可以请求客户端。
• 单个服务端可以支持多个客户端的访问、请求。一对多的关系。这个不稀奇，只要是TCP/IP系统中，socket编写的服务器都是支持一对多。
• 是用来控制声音、影响的多媒体串流协议
• 服务端能够控制多路串流
• 服务端能可以选择TCP传送串流内容，也可以使用UDP传送串流内容，想用哪个就哪个
• 不强调时间同步，可以容忍延时。其实就是客户端请求串流，会缓存起来再播放，不讲究从服务端下载多少，播放多少。
• 因为能控制多路串流，所以可以实现多方视频通讯，比如视频会议。
• 有重新导向功能，可以根据负载情况来提供空闲的服务器。

RTSP、RTP、RTCP

• RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而必须依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送。RTSP负责定义具体的控制信息、操作方法、状态码，以及描述与RTP之间的交互操作。RTSP媒体服务协议框架如下：

• 从上述架构图中可以看出，RTSP和RTP，RTCP配合使用。RTSP传输的一般是TS、MP4格式的流，其传输一般需要2~3个通道，命令和数据通道分离。使用RTSP协议传输流媒体数据需要有专门的媒体播放器和媒体服务器，也就是需要支持RTSP协议的客户端和服务器*。

• RTSP协议定义了一对多程序如何有效的通过IP网络传输多媒体数据。RTSP在体系结构上位于RTP和RTCP上，它使用TCP或者RTP完成数据传输。RTSP被用于建立控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时候可以把RTSP控制信息和媒体数据流交织在一起传输，但一般情况下RTSP本身并不用于传送媒体流数据。媒体数据的传输可以通过RTP/RTCP等协议来完成
  RTSP是类似http的应用层协议，一个典型的流媒体框架网络体系可参考下图
  

  • RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它是创建在UDP协议之上的
  • RTCP是实时传输协议（RTP）的一个姐妹协议。。RTP 使用一个 偶数 UDP port ；而RTCP 则使用 RTP 的下一个 port，也就是一个奇数 port。RTCP与RTP联合工作，RTP实施实际数据的传输，RTCP则负责将控制包送至电话中的每个人。其主要功能是就RTP正在提供的服务质量做出反馈。

总的来说：

• RTSP协议：负责服务器与客户端之间的请求与响应
• RTP协议：负责传输媒体数据
• RTCP协议：在RTP传输过程中提供传输信息

RTSP承载与RTP和RTCP之上，RTSP并不会发送媒体数据，而是使用RTP协议传输

RTP并没有规定发送方式，可以选择udp发送或者tcp发送

RTSP VS HTTP

RTSP的语法和运作跟HTTP 1.0类似，但并不特别强调时间同步，所以比较能够容忍网络延迟。

RTSP具有重新导向功能，可以根据实际负载情况来转换提供服务的服务器，以避免过大的负载集中与同一服务器而造成时延。

RTSP协议与HTTP协议的语法非常类似，且都是纯文本协议，但它们也有区别：

• RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；
• RTSP会为为每个会话保持状态，它命令总是按照顺序来发送，其中某个命令可能需要总在另一个命令之前发送。而HTTP是无状态的，协议命令之间是没有依赖性的。
• RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTP协议中，只有客户端能发送Request请求。、
• 在RTSP协议中，载荷数据一般都是通过带外方式来进行传输的(除了交织的情况)，以及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。
• RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中；

RTSP的有很多优点：

• 易于扩展：RTSP中很容易加入新的方法和参数，只需要服务器和客户端重新协商即可
• 易于解析：RTSP可以有标准HTTP或者MIME解析器进行解析
• 安全：RTSP使用网页安全机制，所有HTTP授权机制如basic、digest都可以直接使用
• 独立于传输: RTSP可使用不可靠数据报协议(EDP), 可靠数据报协议(RDP); 如要实现应用级可靠, 可使用可靠流协议.
• 多服务器支持: 每个流可放在不同服务器上, 用户端自动与不同服务器建立几个并发控制连接, 媒体同步在传输层执行.
• 记录设备控制: 协议可控制记录和回放设备.
• 流控与会议开始分离: 仅要求会议初始化协议提供, 或可用来创建惟一会议标识号. 特殊情况下, 可用SIP或H.323来邀请服务器入会.
• 适合专业应用: 通过SMPTE时标, RTSP支持帧级精度, 允许远程数字编辑.
• 演示描述中立: 协议没强加特殊演示或元文件, 可传送所用格式类型; 然而, 演示描述至少必须包括一个RTSP URL.
• 代理与防火墙友好: 协议可由应用和传输层防火墙处理. 防火墙需要理解SETUP方法, 为UDP媒体流打开一个“缺口”.
• HTTP友好: 此处, RTSP明智地采用HTTP观念, 使现在结构都可重用. 结构包括Internet内容选择平台(PICS). 由于在大多数情况下控制连续媒体需要服务器状态, RTSP不仅仅向HTFP添加方法.
• 适当的服务器控制: 如用户启动一个流, 必须也可以停止一个流.
• 传输协调: 实际处理连续媒体流前, 用户可协调传输方法.
• 性能协调: 如基本特征无效, 必须有一些清理机制让用户决定哪种方法没生效. 这允许用户提出适合的用户界面.

RTSP协议格式

RTSP方法

RTSP常用的方法包括：OPTIONS、DESCRIBE、ANNOUNCE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER等。

详细使用介绍如下：

一个基本的RTSP操作过程：

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

客户端->>服务器:DESCRIBE
服务器->>客户端: 200 OK (SDP)
客户端->>服务器:SETUP
服务器->>客户端: 200 OK
客户端->>服务器:PLAY
服务器->>客户端: (RTP包)

RTSP报文解析

RTSP有两类报文：请求报文和响应报文。

• 请求报文是指从客户向服务器发送请求报文，
• 响应报文是指从服务器到客户的应答。

RTSP协议格式与HTTP协议格式类似，也由三部分组成，即开始行、首部行和实体主体。

请求报文

在请求报文中，开始行就是请求行，RTSP请求报文的结构如下图所示：

method url vesion\r\n
CSeq: x\r\n
xxx\r\n
...
\r\n

• method：方法，表明这次请求的方法，rtsp定义了很多方法，稍后介绍
• url：格式一般为rtsp://ip:port/session，ip表主机ip，port表端口好，如果不写那么就是默认端口，rtsp的默认端口为554，session表明请求哪一个会话
• version：表示rtsp的版本，现在为RTSP/1.0
• CSeq：序列号，每个RTSP请求和响应都对应一个序列号，序列号是递增的

下面是SETUP请求消息的一个Wireshark抓包，我们以此为例进行报文解析：

从上图的抓包可以明显看出，RTSP的第一行(请求行)的内容包括：方法名称(SETUP) + 空格 + URL地址 + 空格 + RTSP版本 + 回车符（CR）和换行符（LF）

第二、第三、第四行表示的是该消息的各字段名称及其对应的值：字段名 + 空格 + 字段值 + 回车符（CR）和换行符（LF）

• CSeq：表示一个RTSP的请求/响应报文对的序列号，出现在所有请求/响应报文中，一个请求报文必须同它响应报文的CSEQ一致，任何重传的请求报文必须同原始报文的CSeq相同。命令的序列号，逐1增加
• User-Agent：这条表示了客户端使用的是什么播放器，以及播放器的版本

最后一行则直接为回车符（CR）和换行符（LF），表示本次请求报文结束

RTSP URL的语法结构

一个终端用户是通过在播放器中输入URL地址开始进行观看流媒体业务的第一步，而对于使用RTSP协议的移动流媒体点播而言，URL的一般写法如下：

一个以“rtsp”或是“rtspu”开始的URL链接用于指定当前使用的是RTSP 协议。RTSP URL的语法结构如下：

rtsp_url = (”rtsp:” | ”rtspu:” | ”rtsps:”) “//” host [“:”port”] /[abs_path]/content_name

• rtsp:使用可信的底层传输协议，例如TCP
• rtspu:使用不可信的底层传输协议，例如UDP
• rtsps:使用可信加密传输协议，例如TCP + TLS
• host：可以是一个有效的域名或是IP地址。
• port：端口号，对于RTSP协议来说，缺省的端口号为554。当我们在确认流媒体服务器提供的端口号为554时，此项可以省略 说明：当HMS服务器使用的端口号为554时，我们在写点播链接时，可以不用写明端口号，但当使用非554端口时，在RTSP URL中一定要指定相应的端口。
• abs_path: 为RTSPServer中的媒体流资源标识
• RTSPURL用来标识RTSPServer的媒体流资源，可以标识单一的媒体流资源，也可以标 识多个媒体流资源的集合。

例如，一个完整的RTSP URL可写为：

rtsp://192.168.1.67:554/test

又如目前市面上常用的海康网络摄像头的RTSP地址格式为：

rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream

示例

rtsp://admin:[email protected]:554/h264/ch1/main/av_stream

另一个简单的示例如下：

rtsp://media.example.com:554/twister/audiotrack

让我们来看一下上面URL的abs path = twister/audiotrack。twister表示一个标识(Presentation) ，标识(Presentation)由一个或多个实时流组成。audiotrack表示标识(Presentation)中其中一个实时流的名称。从这个名称可以看出，我们要取的是一个音频流。如果abs path = twister/videotrack，则表示我们要取的是twister的视频流。

有的服务器也支持下面的URL形式：

rtsp://media.example.com:554/twister

该URL表示取标识(Presentation)的视频流和音频流。

响应报文

每一个请求发出后，都能收到一个响应。响应报文的开始行是状态行，RTSP响应报文的结构如下图所示：

rtsp-vesion 200 OK\r\n
CSeq: x\r\n
xxx\r\n
...
\r\n

• version：表示rtsp的版本，现在为RTSP/1.0
• CSeq：序列号，这个必须与对应请求的序列号相同

下面是SETUP响应消息的一个Wireshark抓包，我们以此为例进行报文解析：

从上面的抓包可以看出，RTSP的第一行(状态行)的内容包括：

RTSP版本 + 空格 + 状态码 + 空格 + 状态语 + 回车符（CR）和换行符（LF）

第二、第三、第四、第五行表示的是该消息的各字段名称及其对应的值：

字段名(CSeq:) + 空格 + 字段值 + 回车符（CR）和换行符（LF）

最后一行则也直接为回车符（CR）和换行符（LF），表示报文结束

RTSP常用字段含义

• Accept: 用于指定客户端通知服务器自己可以接受的实体数据结构类型。例如: Accept: application/sdp，之后服务器通过Content-Type字段返回其实体数据结构类型
• Accept-Encoding:用于客户端通知服务器自己可以接受的数据压缩格式，例如:Accept-Encoding: gzip, compress, br，之后服务器将通过Content-Encoding字段通知客户端它的选择。
• Accept-Language: 用于客户端通知服务器自己可以理解的语言及其接受度，例如:Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5 ，之后服务器将通过Content-Language字段通知客户端它的选择
• Authorization:客户端请求消息头含有服务器用于验证用户代理身份的凭证
• Bandwidth: 用于描述客户端可用的带宽值。例如: Bandwidth: 4000
• Blocksize：此字段由客户端发送到媒体服务器，要求服务器提供特定的媒体包大小，服务器可以自由使用小于请求的块大小。 此数据包大小不包括 IP、UDP 或 RTP 等低层标头
• CSeq： 指定了RTSP请求响应对的序列号，对每个包含一个给定序列号的请求消息，都会有一个相同序列号的回应消息，且每个请求或回应中都必须包括这个头字段。
• Cache-Control：通过指定指令来实现缓存机制。缓存指令是单向的，这意味着在请求中设置的指令，不一定被包含在响应中
• Conference：通知服务器不得更改同一 RTSP 会话的会议 ID
• Connection：该字段决定当前的事务完成后，是否会关闭网络连接。如果该值是“keep-alive”，网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成或者Connection: close。
• Content-Length：该字段指明在RTSP协议最后一个标头之后的双 CRLF 之后的内容长度。例如在服务器响应DESCRIBE中，指明sdp信息长度
• Content-Type:告诉客户端实际返回的内容的内容类型
• User-Agent: 该字段用来让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号。
• Expires：指明过期的时间
• Range： 用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元。
• Session: Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的，客户端一当得到Session ID后，在以后的对Session 的操作请求消息中都要包含Session ID.例如：Session: 411B4161;timeout=65
• Transport: Transport头字段包含客户端可以接受的传输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如: Transport: RTP/AVP/TCP;unicast;destination=192.168.31.222;source=192.168.31.222;interleaved=0-1

简单的RTSP交互过程

第1步：OPTIONS

• C–>S：客户端向服务器请求可用方法

OPTIONS rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 2\r\n
\r\n

• S–>C：服务端回复客户端，当前可用方法OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY

RTSP/1.0 200 OK\r\n
CSeq: 2\r\n
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY\r\n
\r\n

第2步：DESCRIBE

• C–>S：客户端向服务器请求媒体描述文件，格式为sdp

DESCRIBE rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 3\r\n
Accept: application/sdp\r\n
\r\n

• S–>C：服务器回复了sdp文件，这个文件告诉客户端当前服务器有哪些音视频流，有什么属性。客户端可以根据这些信息得知有哪些音视频流可以发送

RTSP/1.0 200 OK\r\n
CSeq: 3\r\n
Content-length: 146\r\n
Content-type: application/sdp\r\n
\r\n

v=0\r\n
o=- 91565340853 1 in IP4 192.168.31.115\r\n
t=0 0\r\n
a=contol:*\r\n
m=video 0 RTP/AVP 96\r\n
a=rtpmap:96 H264/90000\r\n
a=framerate:25\r\n
a=control:track0\r\n

第3步：SETUP

• C–>S：客户端发送建立请求，请求建立连接会话，准备接收音视频数据。对于Transport: RTP/AVP;unicast;client_port=54492-54493\r\n
  • RTP/AVP：表示RTP通过UDP发送，如果是RTP/AVP/TCP则表示RTP通过TCP发送
  • unicast：表示单播，如果是multicast则表示多播
  • client_port=54492-54493：由于这里希望采用的是RTP OVER UDP，所以客户端发送了两个用于传输数据的端口，客户端已经将这两个端口绑定到两个udp套接字上，54492表示是RTP端口，54493表示RTCP端口(RTP端口为某个偶数，RTCP端口为RTP端口+1)

SETUP rtsp://192.168.31.115:8554/live/track0 RTSP/1.0\r\n
CSeq: 4\r\n
Transport: RTP/AVP;unicast;client_port=54492-54493\r\n
\r\n

• S–>C
  • 服务端接收到请求之后，得知客户端要求采用RTP OVER UDP发送数据，单播，客户端用于传输RTP数据的端口为54492，RTCP的端口为54493
  • 服务器也有两个udp套接字，绑定好两个端口，一个用于传输RTP，一个用于传输RTCP，这里的端口号为56400-56401
  • 之后客户端会使用54492-54493这两端口和服务器通过udp传输数据，服务器会使用56400-56401这两端口和这个客户端传输数据

RTSP/1.0 200 OK\r\n
CSeq: 4\r\n
Transport: RTP/AVP;unicast;client_port=54492-54493;server_port=56400-56401\r\n
Session: 66334873\r\n
\r\n

第4步：PLAY

• C–>S：客户端请求播放媒体

PLAY rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 5\r\n
Session: 66334873\r\n
Range: npt=0.000-\r\n
\r\n

• S–>C：服务器回复之后，会开始使用RTP通过udp向客户端的54492端口发送数据

RTSP/1.0 200 OK\r\n
CSeq: 5\r\n
Range: npt=0.000-\r\n
Session: 66334873; timeout=60\r\n
\r\n

第5步：S->C:发送流媒体数据

第6步：S:TEARDOWN

• C–>S

TEARDOWN rtsp://192.168.31.115:8554/live RTSP/1.0\r\n
CSeq: 6\r\n
Session: 66334873\r\n
\r\n

• S–>C

RTSP/1.0 200 OK\r\n
CSeq: 6\r\n
\r\n

上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。
其中第3和4步是必需的！只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第2步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。第5步，可以根据系统需求的设计来决定是否需要。

RTSP错误码

RTSP的响应内容通常包含3位整数响应码以及一个原因短语，短语的目的是给出状态代码的简短文本描述， 客户端不需要检查或显示原因短语。 按照响应码的首位数字区别，可以分为以下五个类别：

• 1xx: 提示- 请求已经收到，正在处理中
• 2xx: 成功- 请求已经被成功处理
• 3xx: 重定向- 必须采取进一步行动才能完成请求
• 4xx: 客户端错误 - 请求中包含错误的参数或语法导致请求无法被满足
• 5xx: 服务器错误 - 服务器无法满足客户端正确的请求

当然，RTSP的错误码和RTSP方法是强相关的，某些错误可能只会在特定方法中才会触发，详细错误码信息如下：

网络体系

参考

• RTSP协议