RTP、RTSP、RTCP

RTSP一般和RTP、RTCP搭配使用，该协议用来进行媒体的控制和会话的建立，比如开始、暂停、倍速控制媒体文件的播放，RTP协议用来进行码流的传输，RTCP保障服务的Qos质量。

RTP

RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证；在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的，如下图所示：

每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如下图所示：

各个字段的解释：

V

当前的协议的版本号是2，其中0和1已经在草案规范中被占用，这里基本就是固定值了

P

填充标记，包的末尾包含了一个或者多个填充字节，其中填充字节的第一字节包括了后面填充字节的长度，该长度字段包含自己，主要是为了一些对齐处理

X

如果为1则说明有扩展头，一般默认为0，很少有场景会用到

CC

表示后面有多少个CSRC，四位说明则最大支持15个CSRC，一般默认为0。

负载类型（PT）

标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。

序列号

用于标识发送者发送的RTP报文序列号，每发送一个RTP包，则这里就增加1，当达到最大值后，则重新从0开始。刚才说了一般RTP协议是承载协议是UDP，UDP是不可靠传输协议。那我们如何保证接收端收的数据是正确的呢，就是通过这个字段进行重新排序，所以接收端一般收到RTP数据第一件事就是排序。

时间戳

记录了负载中第一个字节的采样时间，接收方能够根据时间戳确定到达的数据是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。需要说明的是，一个视频帧的时间戳是相同的，但是一个视频帧数据量很大可能需要多个RTP包传输，这样就存在多个RTP包时间戳相同的情况，音频帧数据小，不存在音频帧跨RTP的情况，所以不存在这个问题。

SSRC

同步信源标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

同步信源是指产生媒体流的信源，例如麦克风、摄像机、RTP混合器等；它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。

CSRC

特约信源标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

特约信源是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报文，组合RTP报文将产生一个新的 SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个SSRC。

若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。

用图表示大概是这样：

例如，有三个信号源各发出一路rtp流，RTP1携带的SSRC是SSRC1，RTP2携带的SSRC是SSRC2，RTP3携带SSRC3，这三路RTP流到达混合器时，混合器会将这三路流混合成一路流发出去，它会把这三路流的SSRC记录下来，形成一个列表，叫CSRC表，在发送的混合RTP流中，SSRC域填充的字段是混合器本身的SSRC4，而CSRC字段则会根据该包的负载的源来填入。

例如当前的RTP包的负载是来自SSRC1的，那么在当前RTP包的CSRC字段填入SSRC1。

这样接收者就可以根据CSRC来区分不同的信源；

一般的，混合的RTP流中，每隔一段时间，就会有一个RTP报文包含了完整的CSRC表。例如在发送混合流时的第一个RTP包，它的CSRC域把CSRC表都填入，此时该包的负载可能是无意义或者并不是媒体流；此后的RTP报文中则根据负载的来源来填入CSRC域。

RTP扩展头

用来给RTP传输协议增加一些扩展性，方便未来一些新功能的加入，同时允许用户增加一些私有信息和私有功能在里面，大部分音视频场景都没有启用RTP扩展部分，但是也有例外。在WebRTC中看到利用RTP扩展部分做了FEC（前向纠错，核心思想就是一些异或运算）的算法处理，这样当发生RTP丢包可以通过扩展快速恢复丢包，在网络不好的时候特别有用。

扩展头格式：

字段说明：

扩展字段定义define by profile:16bit两字节，这个由上层的具体实现协议来决定；

扩展头长度length:表示扩展头的长度字段，16bit即2字节，最大扩展长度1024字节；

注意：如果要启用扩展头，固定头的扩展标记X置1，负载类型playload需要按照规范定义，扩展头字段的长度可以为0，因为不包括头字段的4字节，最大1024.

RTCP

RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：

• SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
• RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
• SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
• BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
• APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。

在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节 的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报 的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动 态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。

RTSP

RTSP（Real Time Streaming Protocol）协议以客户端服务器方式工作，对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，RTSP是应用层协议，在体系结构上位于RTP和RTCP之上, 它使用RTP完成数据传输. RTSP用于流媒体服务器的远程控制。

一次基本的RTSP操作过程

• 首先，客户端连接到流服务器并发送一个RTSP 选项命令（OPTIONS）。

• 流服务器支持的命令选项，一般至少包括 OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY。

• 然后，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。

• 流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。

• 客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的RTP和RTCP端口（RTP OVER UDP）或者 TCP通道（RTP OVER TCP）。

• 客户端发送一个播放命令(PLAY)，服务器就开始在传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。

• 最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。

客户端->>服务器:OPTIONS
服务器->>客户端: 200 OK (SDP)

客户端->>服务器:DESCRIBE
服务器->>客户端: 200 OK (SDP)

//每个流SETUP一次
客户端->>服务器:SETUP
服务器->>客户端: 200 OK
...
客户端->>服务器:SETUP
服务器->>客户端: 200 OK

客户端->>服务器:PLAY
服务器->>客户端: (RTP包)

客户端->>服务器:TEARDOWN
服务器->>客户端: (RTP包)

抓包分析如下：

RTSP的报文结构

RTSP在制定时较多地参考了HTTP/1.1协议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。

请求报文

RTSP请求报文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。

响应报文

响应报文的开始行是状态行