RTSP（Real-Time Streaming Protocol）是一种用于实时流媒体传输的应用层协议。在RTSP通信中，以下是参与的主要角色和组件：

1. 客户端（Client）：发送请求并接收服务器的响应。客户端可以是一个播放器应用程序或其他支持RTSP协议的设备。

2. 服务器（Server）：接收来自客户端的请求，并提供相应的流媒体数据。服务器可以是一个流媒体服务器或其他支持RTSP协议的设备。

3. RTSP协议栈：负责处理RTSP协议的各种细节，包括建立连接、发送请求、解析响应等。

4. RTP（Real-time Transport Protocol）：用于传输实时流媒体数据的协议。RTSP协议通常与RTP协议一起使用，以便在流媒体传输期间进行数据传输。

5. 媒体服务器：存储和管理流媒体文件，并根据RTSP请求提供相应的媒体数据。

6. 流媒体编码器/解码器：负责将音频和视频数据进行编码和解码，以便进行流媒体传输。

7. SDP（Session Description Protocol）：用于描述会话信息的协议。RTSP通信中，SDP通常用于描述流媒体的参数，如编码格式、传输协议、媒体流地址等。

8. NAT（Network Address Translation）：在存在网络地址转换的情况下，处理RTSP通信中的IP地址和端口映射问题。

9. RTCP（Real-Time Control Protocol是用于实时流媒体传输的RTP协议的一个补充协议。它提供了一种用于监测和控制RTP会话质量的机制。尽管在某些情况下RTCP并不是必需的，但在大多数实时流媒体应用中，RTCP是非常有用的。

服务端读取视频文件，客户端进行拉流过程

• 连接到RTSP服务器并发送OPTIONS请求以获取支持的方法列表。
• 发送DESCRIBE请求以获取媒体资源的描述信息。
• 如果需要进行身份验证，拉流客户端会发送SETUP请求以建立安全连接，并提供相关的认证信息。
• 发送SETUP请求以建立传输通道，指定使用的传输协议和端口号。
• 发送PLAY请求以开始拉取媒体流。
• 如果需要暂停或停止拉流，拉流客户端可以发送PAUSE或TEARDOWN请求。

PLAY请求发出后,服务端需要创建UDP连接或者TCP连接,二者都可以,但是UDP连接的话需要创建两个，一个用于RTP包传输，一个用于RTCP反馈，使用TCP传输的话，客户端请求RTSP的Setup请求时，RTSP服务器不需要再对应创建RTP和RTCP的UDP连接通道，因为TCP版的RTP传输，客户端与服务器交互时，无论是RTSP信令还是RTP数据包或者是RTCP数据包，都是使用同一个tcp连接通道。只不过这个tcp连接通道在发送rtp数据包或者rtcp数据包时，需要加一些分隔字节。

下面介绍一下RTP包，他保存的就是视频或者音频的数据了。

 /**    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报文有效载荷中的所有特约信源*/
};struct RtpPacket
{struct RtpHeader rtpHeader;uint8_t payload[0];
};

RTP（Real-time Transport Protocol）报文是用于实时流媒体传输的协议数据单元（PDU），它负责承载音频、视频或其他实时媒体数据。下面对RTP报文进行详细解释：

1. RTP报头（RTP Header）：RTP报文以12字节的报头开始，包含了一些重要的元数据信息，如版本号、源标识符、序列号、时间戳等。

• 版本号（Version）：占据2个比特，表示RTP协议的版本。
• 填充位（Padding）：占据1个比特，如果被设置为1，表示在RTP报文末尾存在额外的填充字节。
• 扩展位（Extension）：占据1个比特，如果被设置为1，表示RTP报头后会包含一个扩展部分。
• CSRC计数（CSRC Count）：占据4个比特，表示CSRC（Contributing Source）标识符的个数。
• 标记位（Marker）：占据1个比特，由应用程序使用，可用于指示关键帧等重要信息。
• 负载类型（Payload Type）：占据7个比特，指定RTP载荷的类型，例如音频或视频编码格式。
• 序列号（Sequence Number）：占据16个比特，用于标识发送的RTP报文的顺序。
• 时间戳（Timestamp）：占据32个比特，用于同步和定时目的，表示报文中第一个字节的采样时刻。
• SSRC（Synchronization Source）标识符：占据32个比特，用于唯一地标识发送RTP报文的源。

2. CSRC列表（CSRC List）：如果在RTP报头的CSRC计数字段中指定了非零值，那么后续的CSRC列表将包含对应的CSRC标识符。每个CSRC标识符占据32个比特。

3. RTP扩展头（RTP Extension Header）：如果RTP报头的扩展位被设置为1，则RTP报文会包含一个扩展头部。扩展头部提供了额外的自定义元数据信息，如传输速率、帧类型等。

4. RTP载荷（RTP Payload）：RTP载荷包含实际的媒体数据，例如音频或视频编码后的数据。其结构和格式由负载类型字段确定，并根据具体的编码标准进行解析和处理。

总而言之，RTP报文是一种用于实时流媒体传输的数据单元，它由报头、CSRC列表、扩展头部和载荷组成。报头包含了一些关键的元数据信息，如版本号、序列号、时间戳等。CSRC列表用于标识参与者的贡献源。扩展头部允许自定义的元数据信息。载荷部分包含实际的媒体数据，其格式由负载类型字段确定，并根据具体的编码标准进行解析和处理。