【音视频开发】：RTSP服务器协议内容

一、什么是RTSP协议

RTSP是一个实时传输流协议 ，是一个应用层的协议。通常说的RTSP包括RTSP协议、RTP协议、RTCP协议。

RTSP协议：负责服务器与客户端之间的请求与相应
RTP协议：负责服务器与客户端之间传输媒体数据
RTCP协议：负责提供有关RTP传输指令的反馈，就是确保RTP传输的质量
吧
三者关系 ：RTSP并不会发送媒体数据，只是完成服务器和客户端之间的交互。
RTP协议负责媒体数据传输，RTCP负责RTP数据包的监视和反馈。RTP和RTCP并没有规定传输层的类型，可以选择UDP或者TCP。RTSP的传输层则是TCP。

二、协议分析

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

方法	方向	是否必须	含义
OPTIONS	C->S	否	查询服务器支持的方法和协议选项，帮助客户端了解服务器的能力和限制，以便进行后续的实时流传输控制。
DESCRIBE	C->S	否	客户端可以获取到媒体流的详细信息，例如媒体类型、编解码格式、传输协议等，以便为后续的播放或者录制操作做准备。
SETUP	C->S	是	用于建立媒体传输的通道。客户端和服务器可以就媒体流的传输进行协商，并最终确定有效的传输通道，为后续的播放或者录制操作做准备。
PLAY	C->S	是	客户端告知服务器可以开始传输媒体流数据，服务器收到PLAY请求后即可开始向客户端发送实时的媒体流数据，实现实时的音视频播放。当多个PLAY请求到达时，服务器会将PLAY请求排成队列，顺序执行，即必须等待第一个PLAY的时间完成后，才会继续处理第二个PLAY消息。
。。。	。。。	。。。	。。。

简单的RTSP交互过程：

C表示RTSP客户端，S表示RTSP服务端

1.C->S：OPTIONS request //询问S有哪些方法可用

1.S->C：OPTIONS response //S回应信息中包括提供的所有可用方法

2.C->S：DESCRIBE request //要求得到S提供的媒体初始化描述信息

2.S->C：DESCRIBE response //S回应媒体初始化描述信息，主要是sdp

3.C->S：SETUP request //设置会话的属性，以及传输模式，提醒S建立会话

3.S->C：SETUP response //S建立会话，返回会话标识符，以及会话相关信息

4.C->S：PLAY request //C请求播放

4.S->C：PLAY response //S回应该请求的信息

S->C：发送流媒体数据

5.C->S：TEARDOWN request //C请求关闭会话

5.S->C：TEARDOWN response //S回应该请求

连接信息交流过程（rbuf为客户端发送信息， sbuf为服务器发送信息）

bash 复制代码

accept client;client ip : xxx.xxx.xxx.xxx,client port:62922
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = OPTIONS rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
CSeq: 1
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, PLAY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = DESCRIBE rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Content-Base: rtsp://xxx.xxx.xxx.xxx:8554
Content-type: application/sdp
Content-length: 128
v=0
o=- 91710247606 1 IN IP4 xxx.xxx.xxx.xxx
t=0 0
a=control:*
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:track0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = SETUP rtsp://xxx.xxx.xxx.xxx:8554/track0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10150-10151
CSeq: 3
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Transport: RTP/AVP;unicast;client_port=10150-10151;server_port=55532-55533
Session: 66334873
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = PLAY rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf60.13.100
Session: 66334873
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Range: npt=0.000-
Session: 66334873; timeout=10
start play
client ip:xxx.xxx.xxx.xxx
client port:10150

三、RTPHeader分析

cpp 复制代码

  *    0                   1                   2                   3
  *    7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0
  *   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
  *   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *   |                           timestamp                           |
  *   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *   |           synchronization source (SSRC) identifier            |
  *   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  *   |            contributing source (CSRC) identifiers             |
  *   :                             ....                              :
  *   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct RtpHeader
{
    /* byte 0 */
    uint8_t csrcLen : 4;//CSRC计数器，占4位，指示CSRC 标识符的个数。（多路流汇成一路流时会用到）
    uint8_t extension : 1;//占1位，如果X=1，则在RTP报头后跟有一个扩展报头。
    uint8_t padding : 1;//填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
    uint8_t version : 2;//RTP协议的版本号，占2位，当前协议版本号为2。

    /* byte 1 */
    uint8_t payloadType : 7;//有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。
    uint8_t marker : 1;//标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

    /* bytes 2,3 */
    uint16_t seq;//占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。

    /* bytes 4-7 */
    uint32_t timestamp;//占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

    /* bytes 8-11 */
    uint32_t ssrc;//占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

   /*标准的RTP Header 还可能存在 0-15个特约信源(CSRC)标识符
   
   每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源

   */
};