1、
流媒体
协议之RTSP详解
1.1 RTSP概述
RTSP(Real Time Streaming Protocol):实时流媒体协议,是由Real network 和 Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议，RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，如音频流、视频流、metadata; 遵循规范IETF RFC 2326,4567,6064，其语法和操作参考了HTTP/1.1，基于文本的协议，采用ISO10646字符集，使用UTF-8编码；承载RTSP的传输层协议为TCP，默认端口554；如果是RTSP-over-HTTP tunneling，则默认TCP端口为8080；实时流数据由不同的协议传输，比如RTP/RTCP完成数据流和控制命令的传输。
RTSP支持的方法如下：
RTSP流媒体协议交互及码流传输过程中所用的协议如下：
后续会对相关协议进行详细介绍，这些协议相互配合，功能完成了流媒体协议会话及码流传输的过程。
可通过请关注公众号壹零仓，发送消息获取，发送rtsp，获取rtsp相关文章，发送rtp，获取rtp/rtcp相关文章
1.2 RTSP协议交互过程
RTSP协议通常是基于TCP的方式进行协议交互，另外也可基于HTTP，其交互过程有所不通，协议交互主要实现流媒体信息描述/码流通道建立/流媒体控制等功能，这里要区分RTSP协议交互与流媒体码流传输，RTSP协议交互，只做流媒体会话交互功能，通过describe来同步流媒体编码、封装、连接等信息，通过setup来建立流媒体传输通道，通过play来开启流媒体播放，通过teardown来结束播放；流媒体码流的传输是通过RTSP交互建立的流媒体传输通道来传输码流，其传输协议一般为RTP/RTCP，其传输层可以为UDP或者TCP。
1.2.1 RTSP基于TCP交互过程
承载RTSP的协议为TCP，其主要交互过程如下图所示：
RTSP返回的状态码与HTTP类似，各个方法的说明也很简单也不做过多的说明，再开发中，RTSP客户端可以直接发送describe，而无强制要求必须要发送option，describe之后，根据其携带的SDP信息，判断流媒体的编码格式/封装格式/payloadtype/timescale，track标识等信息，客户端保存此信息用于后续码流的解复用和解码，根据track标识去申请想要的类型的码流，客户端通过setup来建立码流通道，如果有多路，需要根据不通的track 调用setup方法多次，一般setup建立通道可以是rtp/avp或者rtp/avp/tcp类型，这里标识以rtp传输音视频，前者基于UDP传输，后者基于TCP传输，这里要注意基于UDP传输码流时，需要根据setup交互的信息，单独建立RTP/RTCP两路UDP通道，如果是TCP则与RTSP公用一个TCP通道，通过在RTP/RTCP头加上$开头的四个字节的tcpheader来区分是哪一路的RTP/RTCP，还是RTSP。
1.2.2 RTSP基于HTTP的交互过程
RTSP-over-HTTP tunneling，通过HTTP隧道来传输RTSP协议和媒体流，需要RTSP服务器支持此种方式，开启HTTP隧道监听端口；客户端首先会建立一个链接通过HTTP-GET方法来获取协议响应消息和媒体流，然后再建立一个链路，通过HTTP-POST方法来发送请求消息，两个tcp链接都是长连接，POST 连接中发送RTSP请求消息，一般要进行BASE64编码，来隐藏RTSP信息。数据流的发送封装方式与RTP/TCP一样，通过GET链路发送给客户端，响应消息也是通过GET链路发送给客户端，其流程如下：
1.3 RTSP协议拉流详解
RTSP协议交互无论是基于TCP，还是HTTP，或者近期比较流行的无插件播放的RTSP OVER websocket方式，其协议交互流程不变，以下按照客户端拉流的协议交互顺序，对RTSP协议各个方法极其响应进行详细说明。
1.3.1 OPTION方法
请求及响应实例如下：
OPTIONS rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0 CSeq: 2 User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) RTSP/1.0 200 OK CSeq: 2 Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER Date: Wed, Jul 27 2022 10:37:06 GMT
此方法主要用来询问流媒体服务器支持哪些RTSP方法，此例子说明服务器支持OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER，此方法不是交互必须的，客户端可以跳过此方法直接发describe，服务器需要注意兼容。
1.3.2 DESCRIBE方法
从服务器获取媒体流相关的信息，可以包含多个媒体流类型极信息，通过SDP来描述和区分不通媒体类型的媒体源，客户端根据服务器支持的媒体源通过setup建立媒体流通道，其实例如下：
DESCRIBE rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0 CSeq: 3 User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) Accept: application/sdp RTSP/1.0 401 Unauthorized CSeq: 3 WWW-Authenticate: Digest realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", stale="FALSE" Date: Wed, Jul 27 2022 10:37:06 GMT DESCRIBE rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0 CSeq: 4 Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream", response="be7cde07af4a08db991dd58a89db7621" User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) Accept: application/sdp RTSP/1.0 200 OK CSeq: 4 Content-Type: application/sdp Content-Base: rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ Content-Length: 574 v=0 o=- 1658918226996159 1658918226996159 IN IP4 10.45.12.141 s=Media Presentation e=NONE b=AS:5050 t=0 0 a=control:rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:5000 a=recvonly a=x-dimensions:1920,1080 a=control:rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 a=rtpmap:96 H265/90000 a=fmtp:96 sprop-sps=QgEBAWAAAAMAsAAAAwAAAwB7oAPAgBDlja5JMvTcBAQEAg==; sprop-pps=RAHA8vA8kAA= a=Media_header:MEDIAINFO=494D4B48010300000400050000000000000000000000000000000000000000000000000000000000; a=appversion:1.0
这里客户端发送describe时，一般服务器会进行用户鉴权，如果未携带Authorization鉴权信息，或者认证失败，服务器会返回错误号为401的响应，客户端接收到401响应时，需要根据已知的用户鉴权信息，生成Authorization，再次发送describe，如果认证成功，服务器返回携带有SDP的响应信息。
有关SDP协议的详细解释，请参照我的另一篇文章：
h264和h265视频流SDP描述详解
有关服务器端SDP描述，这里提醒一下，fmtp要根据码流的真实信息填写，不要随意填写，在网页无插件播放时，越来越多的播放插件对这个字段要求很严格，因为网页客户端解码时，一般通过此字段来初始化解码库，所以此字段的填写，需要注意，要根据真实的编码参数来编写。
1.3.3 SETUP方法
此方法根据流媒体服务器返回的SDP描述信息，进行流媒体传输通道的建立，如果sdp描述多个媒体源，客户端可根据需要建立媒体传输链路，play方法后，服务器根据setup建立的媒体流传输通道发送媒体流，一般有RTP over udp和RTP over tcp两张流的传输方式，其setup有一定的区别。
RTP OVER UDP抓包实例：
SETUP rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 RTSP/1.0 CSeq: 5 Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="ac52cf287fe4aa6be5bb168bc9d01446" User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) Transport: RTP/AVP;unicast;client_port=63538-63539 RTSP/1.0 200 OK CSeq: 5 Session: 1279114011;timeout=60 Transport: RTP/AVP;unicast;client_port=63538-63539;server_port=8312-8313;ssrc=3cc5faf7;mode="play" Date: Wed, Jul 27 2022 10:37:07 GMT
首先客户端侧，SETUP的path路径，加上了trackID=1,表示建立的时trackID=1的媒体源的码流传输通道，通过上文SDP描述可知，此路时编码类型为H265，payloadtype=96的视频源，这里要注意，一个setup只能给一种媒体源建立流传输通道。如果服务器需要认证，setup也需要带上认证信息Authorization，Transport字段表示客户端通过何种方式申请建立媒体流传输通道，这里RTP/AVP表示通过UDP方式;unicast表示单播方式(也支持组播，比较少用，这里不做介绍)，如果为UDP方式，则有client_port字段，client_port=63538-63539表示客户端测此路码流的RTP端口为UDP63538，RTCP端口为UDP63539；这里注意建立RTP码流传输通道时，RTP和RTCP要成对出现，一般码流端口号为RTCP=RTP+1
服务器响应时，如果支持客户端的传输方式，则Transport字段中，RTP/AVP;unicast；client_port=63538-63539;要与客户端申请的消息保持一致，增加server_port字段，表示服务器发送RTP/RTCP的UDP端口，可选增加ssrc标识。这里要注意，服务端回复setup时，将会生成一个session ID.后续消息必须带有此Session字段。
RTP OVER TCP抓包实例：
SETUP rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 RTSP/1.0 CSeq: 5 Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="59db6d7ba1acb14582356c8bb8e61ce8", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="129818708e48cd0326f8b6f1b19613a3" User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 RTSP/1.0 200 OK CSeq: 5 Session: 2095163832;timeout=60 Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play" Date: Fri, Aug 26 2022 14:35:46 GMT
RTP通过TCP传输时，与UDP方式在SETUP方法上有一定的区别，主要是Transport头，RTP/AVP/TCP表示RTP流通过TCP传输，当此值出现时，其没有client_port字段，出现interleaved字段，interleaved=0-1，表示streamid，前文已经介绍了，当码流通过TCP传输时，与RTSP共用一个TCP链路，所以其不需要建立新的连接，为了区分RTP、RTCP及RTSP协议，需要增加包头标识，这里采用TCPHEAD头字段，tcphead为四个字节，格式如下：
| magic number | channel number | embedded data length | data
magic number： 1 byte value of hex 0x24（$），标识传输的是数据不是rtsp协议
channel number： 1 byte value to denote the channel，信道ID，标识流的类型
embedded data length ：2 bytes to denote the embedded data length，流长度
data: 表示RTP/RTCP包数据
当TCP接收到的包开头为24时，可以判定其为RTP或者RTCP，通过streamid来却分，setup方法中interleaved=0-1，标识RTP的streamid=0；RTCP的streamid=1
tcphead抓包实例如下：
第一个24000014标识此包为RTP包长度为0x14，解析时只需要根据streamid及长度读取完整的RTP帧，去掉四字节头，通过RTP方式解析即可。由于TCP时流式传输，需要连续根据24标识判断。
1.3.4 PLAY方法
PLAY消息是告诉服务器端可以使用在SETUP消息中所指定的传输机置开始传送数据。需要指出的是，客户端不应该发送任何PLAY请求直到所有的SETUP消息被成功解析。PLAY消息会在range中指定媒体的播放时间，服务器在接到PLAY消息后会由range中指定的开始点开始发送媒体数据直到range中指定的结束点，PlAY可带有scale和speed字段用于点播速度控制。对于实时流range一般为Range: npt=0.000
PLAY rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ RTSP/1.0 CSeq: 6 Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="59db6d7ba1acb14582356c8bb8e61ce8", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="0eef224891c12e902ca9185c70f969cc" User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) Session: 2095163832 Range: npt=0.000- RTSP/1.0 200 OK CSeq: 6 Session: 2095163832 RTP-Info: url=rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1;seq=29458;rtptime=2518517708 Date: Fri, Aug 26 2022 14:35:46 GMT
play方法需要带上Session字段表示统一会话，此Session由setup时服务端返回，客户端发送play方法后，即可准备接收码流，服务器接收到play后，即可打开码流发送通道，发送码流；这里要注意服务器在给出play响应时，最好带有RTP-Info字段描述将要发送码流的RTP信息，比如第一包RTP的seq和rtptime，客户端可以根据此字段进行解复用
1.3.5 TEARDOWN方法
客户端发起表示停止媒体占用，并释放相关资源，其实例如下：
TEARDOWN rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ RTSP/1.0 CSeq: 7 Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="e3dfa4549e00a1d53c0e9f28c3348e2c", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="0c530cba910c33ea3ef7a554dda8d0b2" User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28) Session: 391346974
这里teardown一般会停止RTSP会话及视频传输通道，服务器接收到此方法时，释放相关资源
1.3.6 其他方法
PAUSE方法：录像回放时会用到，用以暂停流媒体传输
SET_PARAMETER/GET_PARAMETER，此方法基本没啥用，一般用来作为心跳使用，也是用option来维持心跳
1.4 RTSP推流方式说明
有关RTSP推流方式，当前用到的越来越少，在媒体分发领域有用到，这里做一个简单的介绍。
RTSP推流流程如下：
抓包实例如下：
OPTIONS rtsp://10.45.12.141:554/live/0001 RTSP/1.0 CSeq: 1 User-Agent: znv RTSP/1.0 200 OK Server: EasyDarwin/7.3 Cseq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD ANNOUNCE rtsp://10.45.12.141:554/live/0001 RTSP/1.0 Content-Type: application/sdp CSeq: 2 User-Agent: znv Content-Length: 325 v=0 o=- 0 0 IN IP4 127.0.0.1 s=Media Server c=IN IP4 192.168.1.108 t=0 0 a=tool:libavformat 57.71.100 m=video 0 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAHqw0ygsBJ/wFuCgoKgAAB9AAAYah0MALFAALE9d5caGAFigAFieu8uFA,aO48MA==; profile-level-id=64001E a=control:streamid=0 RTSP/1.0 200 OK Server: EasyDarwin/7.3 (Build/17.0325; Platform/Win32; Release/EasyDarwin; State/Development; ) Cseq: 2 SETUP rtsp://10.45.12.141:554/live/0001/trackid=0 RTSP/1.0 Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record CSeq: 3 User-Agent: znv RTSP/1.0 200 OK Server: EasyDarwin/7.3 Cseq: 3 Cache-Control: no-cache Session: 132169028622239 Date: Tue, 13 Nov 2018 02:49:48 GMT Expires: Tue, 13 Nov 2018 02:49:48 GMT Transport: RTP/AVP/TCP;unicast;mode=record;interleaved=0-1 RECORD rtsp://10.45.12.141:554/live/0001 RTSP/1.0 Range: npt=0.000- CSeq: 4 User-Agent:znv Session: 132169028622239 RTSP/1.0 200 OK Server: EasyDarwin/7.3 Cseq: 4 Session: 132169028622239 RTP-Info: url=rtsp://192.168.1.108:554/live.sdp/live.sdp
RTSP推流，一般作为流媒体代理，应用CDN等场景，推流由客户端发起，视频由客户端推送给服务器端，因此流媒体描述需要由客户端通知到服务器，通过ANNOUNCE方法完成，其SDP描述与DESCRIBE一致，传输开始时，由客户端发送RECORD方法，然后由客户端推送rtp流到服务器。
有关RTP/RTCP详细描述可参照：
原文链接：
流媒体协议之RTSP详解_rtsp推流_^一二三^的博客-CSDN博客
★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。
见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓