1 简介
实时流传输协议，是一个应用层协议（TCP/IP网络体系中），它是一个多媒体播放控制协议，主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制，即可以对流媒体进行暂停/继续、后退和前进等控制。RTSP体系结位于RTP和RTCP之上，使用TCP或UDP完成数据传输。
2 功能
RTSP用于 发起/设置/终结 流媒体。
RTSP消息分为两大类，一类是请求消息（request），一类是回应消息（ressponse）
常见信令：
1 OPTIONS 功能：请求服务端支持的 RTSP 命令列表，即取服务器支持的方法
2 DESCRIBE功能：向服务器获取URL指定的媒体对象的描述，其中Accept字段指定了描述格式
3 SETUP 功能： 客户端向服务器请求建立会话并准备传输。请求信息主要包括传输协议和客户端的端口号
4 PLAY: 功能：请求流，客户端主动通知服务器以SETUP指定的机制开始发送数据
5 PAUSE 功能：客户端请求服务器的媒体流传输临时暂停
如下RTSP交互过程 (VLC : RTP RTSP OVER TCP) ：
取服务器支持的方法
C ---->
[INFO rtsp_demo.c:409:rtsp_new_client_connection] new rtsp client 192.168.8.100:6006 comming
[DEBUG rtsp_msg.c:865:rtsp_msg_parse_from_array]
OPTIONS rtsp://192.168.8.1:554/live/chn1/mainstream RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.17.4 (LIVE555 Streaming Media v2016.11.28)
回复支持的方法
<------S
[DEBUG rtsp_demo.c:712:rtsp_handle_OPTIONS]
[DEBUG rtsp_msg.c:998:rtsp_msg_build_to_array]
RTSP/1.0 200 OK
CSeq: 2
Date: Fri Nov 4 09:52:36 2022
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN
Server: rtsp_demo
获取URL指定的媒体对象的描述
C ---->
[DEBUG rtsp_msg.c:865:rtsp_msg_parse_from_array]
DESCRIBE rtsp://192.168.8.1:554/live/chn1/mainstream RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.17.4 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp //描述格式
回复 URL指定的媒体对象的描述
<------S
[DEBUG rtsp_demo.c:733:rtsp_handle_DESCRIBE]
[DEBUG rtsp_msg.c:998:rtsp_msg_build_to_array]
RTSP/1.0 200 OK
CSeq: 3
Date: Fri Nov 4 09:52:36 2022
Server: rtsp_demo
Content-Type: application/sdp //sdp格式
Content-Length: 390
v=0
o=- 0 0 IN IP4 0.0.0.0
s=rtsp_demo
t=0 0
a=control:rtsp://192.168.8.1:554/live/chn1/mainstream
a=range:npt=0-
/*
格式为 m=<媒体类型> <端口号> <传输协议> <媒体格式 >
媒体类型：video
端口号：传输端口开没有确定（0表示不确定）
传输协议：RTP/AVP，表示RTP OVER UDP，如果是RTP/AVP/TCP，表示RTP OVER TCP
媒体格式：一般使用96表示 H.264
*/
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
a=rtpmap:96 H265/90000
a=fmtp:96 sprop-vps=QAEMAf//AWAAAAMAgAAAAwAAAwB4vAk=;sprop-sps=QgEBAWAAAAMAgAAAAwAAAwB4oAKAgC0WNvkkyuAQAAADABAAAAMBQIA=;sprop-pps=RAHA8vATZA==
a=control:rtsp://192.168.8.1:554/live/chn1/mainstream/track1
向服务器请求建立会话并准备传输。请求信息主要包括传输协议
C----->
[DEBUG rtsp_msg.c:865:rtsp_msg_parse_from_array]
SETUP rtsp://192.168.8.1:554/live/chn1/mainstream/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.17.4 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 // 请求使用TCP传输
回复客户端建立会话请求
<------S
[DEBUG rtsp_demo.c:937:rtsp_handle_SETUP]
[INFO rtsp_demo.c:881:rtsp_new_rtp_connection] new rtp over tcp for video ssrc:22345678 peer_addr:192.168.8.100 interleaved:0-1
[DEBUG rtsp_msg.c:998:rtsp_msg_build_to_array]
RTSP/1.0 200 OK
CSeq: 4
Date: Fri Nov 4 09:52:36 2022
Session: 12345678
Transport: RTP/AVP/TCP;ssrc=22345678;interleaved=0-1
Server: rtsp_demo
通知服务器以SETUP指定的机制开始发送数据
C------>
[DEBUG rtsp_msg.c:865:rtsp_msg_parse_from_array]
PLAY rtsp://192.168.8.1:554/live/chn1/mainstream RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.17.4 (LIVE555 Streaming Media v2016.11.28)
Session: 12345678
Range: npt=0.000-
回复play请求 并开始发数据
<-------S
[DEBUG rtsp_demo.c:1024:rtsp_handle_PLAY]
[DEBUG rtsp_msg.c:998:rtsp_msg_build_to_array]
RTSP/1.0 200 OK
CSeq: 5
Date: Fri Nov 4 09:52:36 2022
Session: 12345678
Server: rtsp_demo
随着多媒体网络应用的发展，针对网络多媒体的通用、实时交互式应用的传输协议——实时传输协议（Real-Transport Protocol，RTP）与实时传输控制协议（Real-Transport Control Protocol，RTCP）应运而生。
RTP定义了两种报文：RTP报文用于传送媒体数据（如音频和视频），它由 RTP报头和数据两部分组成，RTP报头占用最少12个字节，最多72个字节，包含包含序列号和时间戳，目的是提供时间信息和实现流同步。RTP数据部分称为有效载荷，用来封装实际的数据负载，如封装h264编码的视频数据。
序列号:随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难
时间戳:时标反映RTP数据包中第一个八进制数的采样时刻
由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。
RTCP报文负责管理传输质量，以实现协议控制功能。当应用程序开始一个rtp会话时将使用两个端口：一个给rtp，一个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。在rtp的会话之间周期的发放一些rtcp包以用来传监听服务质量和交换会话用户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。rtp和rtcp配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个相邻端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。
RTP的发送时，RTP协议从上层接收流媒体信息码流（如H.265），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
总而言之，RTSP发起/设置/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制，同步。
双方会在 RTSP协商中确定 通讯协议等信息，准确一点 客户端会在 SETUP 请求中向服务端确认 通讯协议和端口号。
如果是TCP 传输，那么RTSP , RTCP, RTP 则共用同一个 TCP Socket。传输数据的时候 以特殊包头区分不同类型的数据包。
RTP和RTCP数据会以 "$"符号 + 一个字节的通道编号 + 2个字节的数据长度，共四个字节的前缀开始，RTSP数据没有四个字节的前缀；RTP和RTCP数据的区别在于第二个字节的通道编号
如 RTP和RTCP数据头
[0]= '$'
[1]= mark //RTP通道编号是偶数，RTCP通道编号是奇数
[2][3] = size
如果是UDP传输 则需要另外创建 RTP udp Socket 与 RTCP udp Socket，并且 RTP和RTCP分别使用两个相邻的UDP端口，RTP报文使用低端口，并且是偶数的UDP端口，RTCP报文使用高端口，并且是奇数的UDP端口（偶数的UDP端口＋1）。
1.怎样重组乱序的数据包
可以根据RTP包的序列号来排序。
2.怎样获得数据包的时序
可以根据RTP包的时间戳来获得数据包的时序。
3.声音和图像怎么同步
根据声音流和图像流的相对时间（即RTP包的时间戳），以及它们的绝对时间（即对应的RTCP包中的RTCP），可以实现声音和图像的同步。
4.接收缓冲和播放缓冲的作用
接收缓冲用来排序乱序了的数据包；播放缓冲用来消除播放的抖动，实现等时播放。
5.为什么RTP可以解决时延问题
RTP协议是一种基于UDP的传输协议，RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。这样，对于那些丢失的数据包，不存在由于超时检测而带来的延时，同时，对于那些丢弃的包，也可以由上层根据其重要性来选择性的重传。比如，对于I帧、P帧、B帧数据，由于其重要性依次降低，故在网络状况不好的情况下，可以考虑在B帧丢失甚至P帧丢失的情况下不进行重传，这样，在客户端方面，虽然可能会有短暂的不清晰画面，但却保证了实时性的体验和要求。