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。

响应报文

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

RTP、RTSP、RTCP相关推荐

RTP、RTCP、RTSP、RSVP介绍
原文地址:RTP.RTCP.RTSP.RSVP介绍作者:爬爬概括性的说明一下: RTP是实时数据传输协议.它提供时间标志,序列号以及其它能够保证在实时数据传输时处理时间的方法.它是依靠RVSP保证 ...
全面了解MKV、MP4、H.265、RTMP、RTSP、HLS、码率\码流、多码流等等
转载请标明出处:http://blog.csdn.net/xx326664162/article/details/51784440 文章出自:薛瑄的博客你也可以查看我的其他同类文章,也会让你有一定的 ...
android基于ffmpeg本地视频、在线视频、直播播放器支持rtmp、rtsp、http等协议
最近做了一个支持onvif标准的摄像头管理程序,主要就是在局域网中通过程序控制摄像头获取摄像头视频流分发给广域网中的客户端设备:这里面用了onvif协议相关知识和ffmpeg视频流处理的相关知识. o ...
SkeyeVSS综合安防监控Onvif、RTSP、GB28181安防协议互联网无插件直播点播解决方案
系统介绍 SkeyeVSS是一个基于Web无插件直播点播的视频云综合监控管理系统: 支持 WEB 页面配置管理; 支持组织机构管理; 支持设备或平台通过GB/T28181协议接入; 支持IPC.NVR ...
GB28181转RTMP、HLS、RTSP、FLV
背景 GB28181协议凭借其在安防流媒体行业独有的大统一地位,目前已经在各种安防项目上使用.雪亮工程.幼儿园监控.智慧工地.物流监控等等项目上目前都需要接入安防摄像头或平台进行直播.回放.而GB28 ...
SkeyeVSS综合安防Onvif、RTSP、GB28181视频云无插件直播点播解决方案之服务器资源管理
SkeyeVSS综合安防监控Onvif.RTSP.GB28181视频云无插件直播点播解决方案之服务器资源管理 SkeyeVSS支持各安防子服务器集群部署管理,通过资源配置-服务器配置项目进入服务器 ...
常用的RTMP、RTSP、HTTP协议流直播流地址
一.RTMP.RTSP.HTTP协议这三个协议都属于互联网 TCP/IP 五层体系结构中应用层的协议.理论上这三种都可以用来做视频直播或点播.但通常来说,直播一般用 RTMP.RTSP.而点播用 H ...
RTMP、RTSP、HTTP协议流常用直播流地址
引用一.RTMP.RTSP.HTTP协议这三个协议都属于互联网 TCP/IP 五层体系结构中应用层的协议.理论上这三种都可以用来做视频直播或点播.但通常来说,直播一般用 RTMP.RTSP.而点播 ...
SkeyeVSS综合安防监控Onvif、RTSP、GB28181视频云无插件直播点播解决方案之监控视频实时多屏预览
SkeyeVSS综合安防监控Onvif.RTSP.GB28181视频云无插件直播点播解决方案之监控视频实时多屏预览 SkeyeVSS支持一分屏.四分屏.九分屏.16分屏.25分屏.36分屏等几种N*N ...
SkeyeVSS综合安防监控Onvif、RTSP、GB28181视频云无插件直播点播解决方案之子系统微服务集群解决方案
SkeyeVSS综合安防监控Onvif.RTSP.GB28181视频云无插件直播点播解决方案之子系统微服务集群我们通过SkeyeVSS系列文章<SkeyeVSS集群部署说明文档>可以了解 ...

RTP、RTSP、RTCP

RTP

V

P

X

CC