RTP、RTCP、RTSP协议详解
一、RTP协议
实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。

应用程序通常在UDP 上运行RTP以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。

但是RTP可以与其它适合的底层网络或传输协议一起使用。

如果底层网络提供组播方式，那么RTP可以使用该组播表传输数据到多个目的地。

RTP本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。

RTP协议并不保证传送或防止无序传送，也不确定底层网络的可靠性。

RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

RTP协议由两个紧密链接部分组成：
RTP―传送具有实时属性的数据；
RTP控制协议（RTCP）―监控服务质量并传送正在进行的会话参与者的相关信息。

RTCP 第二方面的功能对于“松散受控”会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。

协议结构
1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC (variable 0 –15 items 32bits each)V ―版本。

识别RTP版本。

P ―间隙（Padding）。

设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。

X ―扩展位。

设置时，在固定头后面，根据指定格式设置一个扩展头。

CSRC Count ―包含CSRC 标识符（在固定头后）的编号。

M ―标记。

标记由Profile 文件定义。

允许重要事件如帧边界在数据包流中进行标记。

Payload Type ―识别RTP有效载荷的格式，并通过应用程序决定其解释。

Profile 文件规定了从Payload 编码到Payload 格式的缺省静态映射。

另外的Payload Type 编码可能通过非RTP方法实现动态定义。

Sequence Number ―每发送一个RTP数据包，序列号增加1。

接收方可以依次检测数据包的丢失并恢复数据包序列。

Timestamp ―反映RTP数据包中的第一个八位组的采样时间。

采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。

SSRC ―同步源。

该标识符随机选择，旨在确保在同一个RTP协议会话中不存在两个同步源具有相同的SSRC 标识符。

CSRC ―贡献源标识符。

识别该数据包中的有效载荷的贡献源。

二、RTCP：RTP 控制协议
RTP 控制协议（RTCP）采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。

底层协议必须提供数据和控制包的多路发送，例如使用不同的UDP 端口号。

RTCP 主要完成四个功能服务：
RTCP 提供数据分发质量反馈信息。

这是RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。

RTCP 为RTP 源携带一个持久性传输层标识符，称为规范名或CNAME 。

由于一旦发现冲突或程序重启时，SSRC 标识符会随之改变，所以接收方需要CNAME 来跟踪每一个
参与者。

同时接收方还要求CNAME 能够与一组相关RTP 会话中来自于给定参与者的多重数据流相关联，例如同步视频和音频。

上述前两个功能要求所有的参与者都要发送RTCP 包，因此必须控制速率以便RTP 按比例增加大量的参与者。

通过每一个参与者发送各自的控制包给其它所有参与者，每一个参与者能够独立观察到参与者数量，该数量可用来计算控制包的发送速率。

OPTIONAL 功能用于传送最少会话控制信息，例如在用户界面显示参与者标识。

这对于“松散受控”会话（在没有成员控制或阐述协商的情况下，参与者可以加入或退出该会话）是非常有用的。

上述功能 1 － 3 适用于所有环境，尤其是IP 组播环境。

RTP 应用程序设计者应该避免设计只能工作于单播模式并且不能增加到大量数量的机制。

在某些情况下如单向链接中，不可能有来自接收方的反馈，所以RTCP 的传输就可能由发送方和接收方分别独立控制。

协议结构
2 3 8 16 bit
Ver P RC Packet type
Length
Version ――识别RTP 版本。

RTP 数据包中的该值与RTCP 数据包中的一样。

当前规范定义的版本值为2 。

P ――间隙（Padding）。

设置时，RTCP 数据包包含一些其它padding 八位位组，它们不属于控制信息。

Padding 的最后八位是用于计算应该忽略多少间隙八位位组。

一些加密算法中需要计算固定块大小时也可能需要使用Padding 字段。

在一个复合RTCP 数据包中，只有最后的个别数据包中才需要使用padding ，这是因为复合数据包是作为一个整体来加密的。

RC ――接收方报告计数。

包含在该数据包中的接收方报告块的数量，有效值为0 。

Packet type ――包括常量200 ，识别这是一个RTCP SR 数据包。

Length ――RTCP 数据包的大小（32 位字减去1），包含头和任意间隙（偏移量的引入使得0 成为有效值，并避免了扫描复合RTCP 数据包过程中的无限循环现象，而采用32 位字计数方法则避免了对4 的倍数的有效性校验）。

三、实时流协议RTSP
RTSP[3]协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。

因此RTSP 又称为“因特网录像机遥控协议”。

RTSP协议简介
要实现RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和媒体服务器(media server)。

媒体服务器与媒体播放器的关系是服务器与客户的关系。

媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。

但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。

图1 RTSP与RTP和RTCP的关系
RTSP 仅仅是使媒体播放器能控制多媒体流的传送。

因此，RTSP 又称为带外协议，而多媒体流是使用RTP 在带内传送的。

RTSP的报文结构
RTSP有两类报文：请求报文和响应报文。

请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。

由于RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些ASCII 码
串，因而每个字段的长度都是不确定的。

RTSP报文由三部分组成，即开始行、首部行和实体主体。

在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所示。

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

RTSP请求报文的常用方法及作用如表1所示。

表1 RTSP请求报文的常用方法及作用
方法作用OPTIONS获得服务器提供的可用方法DESCRIBE得到会话描述信息SETUP客户端提醒服务器建立会话，并确定传输模式TEARDOWN客户端发起关闭请求PLAY客户端发送播放请求响应报文的开始行是状态行，RTSP响应报文的结构如图3所示。

图3 RTSP响应报文的结构
RTSP交互过程
C表示RTSP客户端，S表示RTSP服务端
①C->S: OPTION request //询问S有哪些方法可用
S->C: OPTION response //S回应信息中包括提供的所有可用方法
②C->S: DESCRIBE request //要求得到S提供的媒体初始化描述信息
S->C: DESCRIBE response //S回应媒体初始化描述信息，主要是sdp
③C->S: SETUP request //设置会话属性，及传输模式，提醒S建立会话
S->C: SETUP response //S建立会话，返回会话标识符及会话相关信息
④C->S: PLAY request //C请求播放
S->C: PLAY response //S回应请求信息
S->C: 发送流媒体数据
⑤C->S: TEARDOWN request //C请求关闭会话
S->C: TEARDOWN response //S回应请求。