rtsp协议属于哪一层_rtmp rtsp

流媒体协议之RTSP详解 　　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。



　　相关学习资料推荐，下方链接免费报名，先码住不迷路~】 　　音视频免费学习地址：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发 　　【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以加群免费领取~



　　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方法 　　请求及响应实例如下： 　　此方法主要用来询问流媒体服务器支持哪些RTSP方法，此例子说明服务器支持OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER，此方法不是交互必须的，客户端可以跳过此方法直接发describe，服务器需要注意兼容。 　　1.3.2 DESCRIBE方法 　　从服务器媒体流相关的信息，可以包含多个媒体流类型极信息，通过SDP来描述和区分不通媒体类型的媒体源，客户端根据服务器支持的媒体源通过setup建立媒体流通道，其实例如下： 　　这里客户端发送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的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标识。这里要注意，服务端sigusoftsetup时，将会生成一个session ID.后续消息必须带有此Session字段。 　　RTP OVER TCP抓包实例： 　　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抓包实例如下：

　　第一个标识此包为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方法需要带上Session字段表示统一会话，此Session由setup时服务端返回，客户端发送play方法后，即可准备接收码流，服务器接收到play后，即可打开码流发送通道，发送码流；这里要注意服务器在给出play响应时，最好带有RTP-Info字段描述将要发送码流的RTP信息，比如第一包RTP的seq和rtptime，客户端可以根据此字段进行解复用 　　1.3.5 TEARDOWN方法 　　客户端发起表示停止媒体占用，并释放相关资源，其实例如下： 　　这里teardown一般会停止RTSP会话及视频传输通道，服务器接收到此方法时，释放相关资源 　　1.3.6 其他方法 　　PAUSE方法：录像回放时会用到，用以暂停流媒体传输 　　SET_PARAMETER/GET_PARAMETER，此方法基本没啥用，一般用来作为心跳使用，也是用option来维持心跳 　　1.4 RTSP推流方式说明 　　有关RTSP推流方式，当前用到的越来越少，在媒体分发领域有用到，这里做一个简单的介绍。 　　RTSP推流流程如下：

　　抓包实例如下： 　　RTSP推流，一般作为流媒体代理，应用CDN等场景，推流由客户端发起，视频由客户端推送给服务器端，因此流媒体描述需要由客户端通知到服务器，通过ANNOUNCE方法完成，其SDP描述与DESCRIBE一致，传输开始时，由客户端发送RECORD方法，然后由客户端推送rtp流到服务器。 　　有关RTP/RTCP详细描述可参照： 　　H264码流RTP封装方式详解 　　H265码流RTP封装方式详解 　　RTP/RTCP协议 　　原文链接：https://blog.csdn.net/water1209/article/details/