0
0

RTSP系列一：RTSP协议介绍

RTSP系列：

    RTSP系列一：RTSP协议介绍-CSDN博客

    RTSP系列二：RTSP协议鉴权-CSDN博客 

    RTSP系列三：RTP协议介绍-CSDN博客 

    RTSP系列四：RTSP Server/Client实战项目-CSDN博客

一、RTSP协议介绍

     RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP 协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks 公司提交的IETF RFC 标准。该协议定义了一对多应用程序如何有效地通过IP 网络传送多媒体数据。

    其语法和操作参考了HTTP/1.1，默认端口554。RTSP主要应用在视频监控领域，网络摄像头都支持RTSP协议。RTSP只是对媒体传输进行控制，真正传输音视频是RTP协议，将在后面介绍。

    目前RTSP有两个版本1.0和2.0，1.0定义在RFC2326中，2.0定义在RFC7826。2.0是2016年由IETF发布的RTSP新标准，不过现在基本使用的都是RTSP1.0，就算有使用2.0的，也会兼容1.0，该系列都是围绕RTSP1.0进行讲解的。

    RTSP属于应用层协议，和HTTP类似，使用TCP传输，RTSP主要完成媒体信息交互，确认媒体传输方式和媒体传输控制，即RTSP负责上层控制，底层音视频传输使用的是其他的协议（RTP协议），RTSP交互过程中会把媒体信息告知对端，这个媒体信息就放在RTSP的payload（负载）中，和HTTP中的payload是一样的，在RTSP中媒体信息，也就是这个payload使用的是SDP协议，SDP协议就是规定了怎么描述媒体源(网络摄像头)包含哪些媒体流(主要是音频和视频)以及这些媒体流参数是怎么样的（音视频编解码参数等）。所以从IPC（网络摄像头）中获取音视频涉主要及到三个协议：RTSP、SDP、RTP。RTSP负责媒体控制，协商（确定传输方式，使用TCP还是UDP以及传输通道-TCP和传输端口-UDP）；SDP负责描述媒体信息；RTP负责传输音视频。此外还有RTCP协议，是传输过程中对媒体质量进行控制(统计丢包，时延等)，和RTP是一起使用的，不过RTCP协议是可选的，在具体应用中可以不实现RTCP协议。

    RTSP的请求和响应报文格式如下：

二、RTSP信令

    RTSP报文格式和HTTP完全一样，只不过里面的值不一样，使用的错误码也是一样，比如200表示请求成功，40x表示客户端错误，50x表示服务端错误，这样RTSP就很好理解了。HTTP有GET、POST等方法，同样RTSP也有自己的方法，RTSP1.0包含如下方法：

方法方向是否必须含义OPTIONSC->S否获在取服务器支持的方法。DESCRIBEC->S否向服务器获取URL指定的媒体对象的描述，其中Accept字段指定了描述格式ANNOUNCEC->S
S->C否当客户端向服务器发送时，表示的是将通过请求 URL 识别的表示描述或者媒体对象提交给服务器
当服务器向客户端发送时，表示的是通知客户端更新会话信息SETUPC->S是客户端向服务器请求建立会话并准备传输。请求信息主要包括传输协议和客户端的端口号PLAYC->S是客户端主动通知服务器以SETUP指定的机制开始发送数据。其中Range字段指定了播放的起止时间，当多个PLAY请求到达时，服务器会将PLAY请求排成队列，顺序执行，即必须等待第一个PLAY的时间完成后，才会继续处理第二个PLAY消息。PAUSEC->S否客户端请求服务器的媒体流传输临时暂停。可以通过Range参数在指定时间点暂停，也可以指定某股流暂停，例如如果指定音频流暂停，则播放将是无音状态RECORDC->S否RECORD通知服务器方法客户端将会根据之前的描述开始记录媒体数据。 其中timestamp 字段反映开始和结束时间 (UTC)。如果该字段不存在，则会使用媒体描述中的开始或结束时间。 如果会话已经开始，则立即开始录制。
服务器决定是将记录的数据存储在 request-URI 下还是另一个 URI 下。 如果服务器不使用 request-URI，则响应应该是 201（已创建）并包含描述请求状态并引用新资源的实体和 Location 标头。REDIRECTS->C否重定向请求通知客户端它必须连接到另一个服务器位置。 它包含强制标头 Location，它指示客户端应该发出对该 URL 的请求。 它可能包含参数Range，表示重定向何时生效。 如果客户端想要继续发送或接收此 URI 的媒体，客户端必须为当前会话发出 TEARDOWN 请求，并在指定主机上为新会话发出SETUP。GET_PARAMETERC->S
S->C否GET_PARAMETER 请求检索 URI 中指定的表示或流的参数值。 回复和响应的内容留给实现。 没有实体主体的 GET_PARAMETER 可用于测试客户端或服务器的活跃度（“ping”）。SET_PARAMETERC->S
S->C否这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。TEARDOWNC->S是TEARDOWN请求停止给定URL流发送，释放相关资源。
RTSP是C/S模型，RTSP服务端可向RTSP客户端发送音视频(客户端拉流模式)，也可接受来自RTSP客户端发送过来的音视频流(客户端推流模式)，RTSP拉流模式使用的方法包括DESCRIBE、SETUP、PLAY。RTSP推流模式使用的方法包括ANNOUNCE、SETUP、RECORD。其他的方法都是推流模式和拉流模式通用的。一般RTSP使用的都是拉流模式，即IPC作为RTSP服务端，RTSP客户端通过DESCRIBE、SETUP、PLAY等方法从IPC拉取音视频流。客户端推流一般使用另外一种协议RTMP，RTMP本系列中不会介绍。RTSP拉流模式和推流模式，基本类似，推拉流模式只是媒体流向不同，使用的方法不同，其他大同小异。本文主要对拉流模式也是目前IPC的音视频传输都在用的模式进行详细介绍。

    下面是RTSP拉流信令交互过程。其中RTP是传输音视频数据，RTCP是音视频质量控制。

1）OPTIONS

    C--->S

    客户端向服务器端发现OPTIONS，请求可用的方法。

    S--->C

    服务器端回复客户端，消息中包含当前可用的方法。

2）DESCRIBE

    C--->S

    客户端向服务器请求媒体描述文件，一般通过rtsp 开头的url 来发起请求，格式为sdp。

    S--->C

    服务器回复客户端sdp 文件，该文件告诉客户端服务器有哪些音视频流，有什么属性，如编解码器信息，帧率等。

3）SETUP

    为音视频数据的传输准备通道，确定音视频传输方式(TCP/UDP)

    C--->S

    客户端向服务器端发起建立连接请求，请求建立会话连接，准备开始接收音视频数据，请求信息描述了期望音视频数据包基于UDP 还是TCP 传输，指定了RTP，RTCP 端口，以及是单播还是组播等信息。

    S--->C

    服务器端收到客户端请求后，根据客户端请求的端口号确定发送控制数据的端口(RTCP)以及音视频数据(RTP)的端口。

4）PLAY

    C--->S

    客户端向服务端请求播放媒体。

    S--->C

    服务器回复客户端200 OK! 之后开始通过SETUP 中指定的端口开始发送数据。

5）TEARDOWN

    C---->S

    结束播放的时候，客户端向服务器端发起结束请求。

    S--->C

    服务端收到消息后，向客户端发送200 OK，之后断开连接。

三、SDP

    sdp格式由多行的type=value组成

    sdp会话描述由一个会话级描述和多个媒体级描述组成。会话级描述的作用域是整个会话，媒体级描述描述的是一个视频流或者音频流.

    会话级描述由v=开始到第一个媒体级描述结束，媒体级描述由m=开始到下一个媒体级描述结束

    下面是上面示例的sdp文件，我们就来好好分析一下这个sdp文件

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

    这个示例的sdp文件包含一个会话级描述和一个媒体级描述，分别如下：

1、会话级描述
v=0\r\n

o=- 91565340853 1 IN IP4 192.168.31.115\r\n

t=0 0\r\n

*a=contol:\r\n

解释：

v=0：表示sdp的版本

o=- 91565340853 1 IN IP4 192.168.31.115

格式为 o=<用户名> <会话id> <会话版本> <网络类型><地址类型> <地址>

用户名：-

会话id：91565340853，表示rtsp://192.168.31.115:8554/live请求中的live这个会话

会话版本：1

网络类型：IN，表示internet

地址类型：IP4，表示ipv4

地址：192.168.31.115，表示服务器的地址

2、媒体级描述
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

解释：

m=video 0 RTP/AVP 96\r\n

格式为 m=<媒体类型> <端口号> <传输协议> <媒体格式 >

媒体类型：video

端口号：0，为什么是0？因为在SETUP过程会告知端口号，所以这里就不需要了

传输协议：RTP/AVP，表示RTP OVER UDP，如果是RTP/AVP/TCP，表示RTP OVER TCP

媒体格式：表示负载类型(payload type)，RTP中包含RTP Header和payload(音视频)，RTP Header中有个字段为负载类型，和SDP中的负载类型是对应的，从SDP中获取音视频的payload type，那么传输音视频数据的时候，就可以通过判断RTP中的负载类型来判断当前RTP数据包是音频还是视频。

a=rtpmap:96 H264/90000

格式为a=rtpmap:<媒体格式><编码格式>/<时钟频率>

a=framerate:25表示帧率

a=control:track0 表示这路视频流在这个会话中的编号

    音视频的媒体描述格式是一样的。这里SDP不做详细介绍，作为入门，了解这些就可以完成满足基本的开发需求。

四、RTSP抓包分析

    前面说过RTSP是交互媒体信息，确定数据传输方式的。其中传输方式包括TCP和UDP，UDP又包括单播和组播，下面将对每种方式进行数据包分析。

    下面是wireshark抓取的RTSP数据包(仅包含一路媒体流，SETUP仅请求一次)：

4.1 单播：UDP

1、OPTIONS

​

    OPTINOS是客户端查询服务端支持哪些方法。​

2、DESCRIBE

​

​ DESCRIBE是客户端请求服务端返回关于音视频的描述，用SDP表示。

3、SETUP

​

​ SETUP是请求音视频，这里只有视频并且视频的control是track0，如果还要音频的话就还需要再发起一次SETUP请求，请求音频数据。RTP/AVP表示使用UDP传输音视频数据，cilent_port中记录了客户端的RTP和RTCP数据接收端口，响应中server_port表示服务端的RTP和RTCP数据发送端口，规定RTCP端口 = RTP端口 + 1。

    此外SETUP响应包中还会包含Session字段，表示当前会话，后面客户端请求都要带上这个Session字段，服务器用Session区分不同的客户端。

4、PLAY

​

​ 服务端收到客户端发起的PLAY请求后，就开始向客户端发送音视频。

5、TEARDOWN

    客户端与服务端断开连接，媒体结束。

4.2 组播：UDP

    组播需要RTSP服务器支持才行，服务器的组播地址会记录在SDP中，组播与单播相比，DESCRIBE和SETUP不同。

1、DESCRIBE

​

    服务器支持组播需要在SDP中描述。

2、SETUP

​

​ 客户端加入多播组即可收到服务端的音视频数据。RTSP中组播一般很少用。

4.3 RTP OVER TCP/RTSP

     当使用TCP协议承载RTSP/RTP时，所有的命令和媒体数据都将通过RTSP端口，RTP数据发送使用RTSP的socket和端口，数据将经过二元交织格式化之后才能发送。

    要使用TCP连接，RTSP客户端需要在SETUP阶段请求TCP连接。SETUP命令中应该包括如下格式的Transport：

Transport: RTP/AVP/TCP;interleaved=0-1

    上述Transport将告诉服务端使用TCP协议发送媒体数据，并且使用信道 0 和 1 对流数据以及控制信息进行交织。详细说来，使用偶数信道作为数据传输信道，使用奇数信道作为控制信道（数据信道 + 1）。所以，如果你设定数据信道为 0 ，那控制信道应该是 0 + 1 = 1。

    RTP，RTCP数据和RTSP数据共享TCP数据通道，所以必须有一个标识来区别三种数据。

    RTP和RTCP数据会以$符号＋1个字节的通道编号＋2个字节的数据长度，共4个字节的前缀开始，RTSP数据是没有前缀数据的。RTP数据和RTCP数据的区别在于第二个字节的通道编号，

RTP基于TCP的包头比基于UDP的包头多了4个字节：

  • magic固定为0x24，

  • channel用来区分音视频等多路流媒体的通道，其中偶数通道为流媒体内容，奇数通道为RTCP

  • len表示数据包的长度减去开始的4个字节，即len字段之后的数据长度

​

SETUP：

​

​

RTP OVER TCP数据传输：

​五、总结

一个完整的RTSP流媒体传输过程是：

  1. RTSP信令交互阶段：- 客户端发起RTSP连接请求到服务端。- 服务端响应，建立RTSP连接。- 客户端与服务端交互，协商媒体传输方式（例如，使用UDP或TCP）。- 服务端确认传输方式，建立媒体传输通道。
  2. 采集音视频阶段：- 服务端开始采集音频和视频数据。
  3. 音视频编码阶段：- 服务端进行H.264/H.265视频编码和AAC/PCM/PCMA/PACMU音频编码。
  4. RTP封装阶段：- 服务端将编码后的音视频数据封装成RTP数据包。- 视频使用H.264/H.265 RTP封装，音频使用AAC/PCM/PCMA/PACMU RTP封装。
  5. RTP数据传输阶段：- 使用选择的传输方式（UDP或TCP），服务端将RTP数据包发送到客户端。
  6. 客户端接收与解包阶段：- 客户端接收RTP数据包。- 如果使用UDP传输，客户端直接解包RTP数据。- 如果使用TCP传输，客户端从RTSP信令中获取通道信息，然后通过TCP连接接收RTP数据。
  7. 解码与播放阶段：- 客户端对接收到的音视频数据进行解码。- 解码后的数据传递给播放器进行播放。
标签： 音视频 网络
本文转载自: https://blog.csdn.net/weixin_43147845/article/details/140851964
版权归原作者 D^ε^S 所有， 如有侵权，请联系我们删除。
登录后发布评论

“RTSP系列一：RTSP协议介绍”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

落实算法安全主体责任：全面保障算法合规与安全

Hadoop生态圈框架部署（四）- Hadoop完全分布式部署

毕设项目 基于大数据的b站数据分析

【前端】Bootstrap：栅格系统 (Grid System)

docker部署rustdesk

【PostgreSQL】实战篇——用户管理、角色和权限控制的高级用法及技巧

AI时代：弯道超车的新思维与实践路径

文章导航