0.引言

为了更好理解本篇文章，可以先阅读前面几篇文章，文章列表如下:

RTSP协议交互流程之拉流分析

详解RTP打包AAC实战分析(1)

详解RTP协议之H264封包和解包实战

详解RTP协议之H264封包细节(1)

详细解析RTSP框架和数据包分析(1)

手把手搭建RTSP流媒体服务器

RTP协议

HLS实战之Wireshark抓包分析

HTTP实战之Wireshark抓包分析

本篇文章主要是讲解RTSP协议交互流程的推流流程分析，与上篇文章RTSP协议交互流程之拉流分析结合起来进行分析和对比。以下c代表客户端，s代表服务端。

这里继续推荐一篇非常好的RTSP协议的英文文档，如下链接:

https://blog.csdn.net/u012519333/article/details/52746375

如下界面:

1.详细推流步骤

整体流程大致如下:

1.1 查询服务器端可⽤⽅法之OPTIONS

(1)C->S:客户端向服务端发送OPTION request，目的是查询服务端有哪些可用的方法。如下方法:

注意:在拉流时，实时流不一定支持pause方法，需要看看服务器是否支持。

(2)S->C:服务端向客户端回应OPTION response，目的是服务端回应信息的public头字段中，包括提供的所有可用方法，如OPTIONS，DESCRIBE，SETUP等。如下图:

1.2 发送ANNOUNCE

(3)C->S:客户端向服务端发送ANNOUNCE request，目的是客户端发送媒体描述信息给服务器，r如视频的SPS、PPS和音频的profile-level等。如下图:

stream id 表示不同的流通道。

目前传输的是什么数据。可以从content-type得知，实际就是给服务器发送sdp，通过sdp描述音视频的一些基本格式信息。如下图:

如这里的Media Attribute(a)表示音频和视频的属性。告诉服务器视频类型和格式，如Media Attribute(a):rtpmap:96 H264/90000等信息。

客户端发送服务端，如下一些音频相关的信息，如下图:

注意:客户端每次给服务端发送数据，都会把url绝对地址带上，这与http就不一样。如下图:

(4)S->C:服务端向客户端回应ANNOUNCE response，目的是服务端回应媒体描述信息是否能够成功接收，并返回Session ID。到这一步就相当于为建立对话做准备。如下图:

1.3 建⽴RTSP会话

(5)C->S:客户端向服务端发送SETUP request，目的是通过Transport头字段列出可接受的传输选项，客户端请求与服务端建立会话。如下图:

(6)S->C:服务端向客户端回应SETUP response，目的是客户端与服务端建立会话，通过Transport头字段返回选择的具体转输选项，并返回建⽴的Session ID。如下图:

(7)C->S:客户端向服务端再次发送SETUP request，目的是通过Transport头字段列出可接受的传输选项，请求S建⽴会话。注意，到这里就发送了2次SETUP request，一次是视频，一次是音频。如下图:

(8)S->C:服务端向客户端回应SETUP response，目的是通过Transport头字段再次返回选择的具体转输选项。如下图:

运行到这步，会话建立好了，客户端RTP使用的端口号是31590，服务端RTP使用的端口号是59472。客户端RTCP使用的端口号是31591，服务端RTCP使用的端口号是59473。

1.4 请求传送数据

(9)C->S:客户端向服务端发送RECORD request，目的是客户端向服务端请求发送数据。如下图:

(10)S->C:服务端向客户端发送RECORD response，目的是服务端回应客户端允许的信息。如下图:

注意：如果服务端允许客户端推流，就会回应视频和音频的stream id。推流的时候，SSRC由推流端定义，拉流的时候由服务端发送给客户端。

1.5 RTP数据推送

(11)C->S:客户端向服务端发送流媒体数据，注意，流媒体数据是通过RTP协议(这里以基于UDP为基础来举例说明)发送，这个观点，前面已经反复强调过了。视频通道传送，如下图:

⾳频通道传送，如下图:

RTP协议传输数据。

RTCP控制命令传送，如下图:

如在音视频传输中间穿插发送些SSRC，NTP等相关信息。

1.6 关闭会话

(12)C->S:客户端向服务端发送TEARDOWN request，目的是客户端向服务端请求关闭会话。如下图:

(13)S->C:服务端向客户端回应TEARDOWN response，目的是服务端回应客户端该请求。如下图：

2.推流流程和拉流流程的区别

结合前面一篇文章对比，拉流流程和推流流程，有以下一些区别，如下:

(1)上文中描述的1.1步是一样的。

(2)1.2步是有区别，推流的时候发送ANNOUNCE，拉流的时候发送：DESCRIBE。

(3)推流和拉流在1.3步都是发送SETUP。

(4)1.4步骤，推流发送的是RECORD，拉流发送的是PLAY。

(5)1.5步骤，RTP传输，只是方向刚好向反。

(6)1.6步骤，关闭会话TEARDOWN是一样。

3.总结

上述的过程只是标准的的rtsp流程，不同的项目需求和环境中，并不⼀定按此过程。其中第1.3步和1.4步，是必需的。在1.1步过程中，只要服务断与客户端约定好，有哪些⽅法可⽤，则optionS请求可以不要。在1.2步过程中，如果有其它途径得到媒体初始化描述信息(⽐如http请求等等)，则拉流的时候也不需要通过rtsp中的describe请求来完成。当然，各个复杂的需求不一样，这里说明的是一种通用的流程。

RTSP服务器默认端⼝是554，在客户端SETUP的时候，会把⾃身的RTP和RTCP端⼝号，告知服务端。在RTSP的session建⽴后，会使⽤RTP/RTCP在约定好的端⼝上传输数据。欢迎关注，收藏，转发，分享。

后期关于项目知识，也会更新在微信公众号“记录世界 from antonio”，欢迎关注