音视频基础：RTP/RTCP协议
RTP协议
RFC3550定义实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。 IETF的RFC3550定义RTP/RTCP协议的基本内容，包括报文格式、传输规则等。除此之外，IETF还定义一系列扩展协议，包括RTP档次扩展，RTCP报文类型扩展等。
RTP固定头部
V ：RTP协议的版本号，占2位，当前协议版本号为2。
P ：填充标志，占1位，若P=1则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分，表示报文对齐。
X ：扩展标志，占1位，若X=1，则在RTP报头后跟有一个扩展头。
CC：CSRC计数器，占4位，指示CSRC 标识符的个数。
M ：标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
PT ：有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。
序列号：16位，发送RTP报文的序列号，每发送一个报文序列号增1。接收者用序列号来检测报文丢失，排序报文，恢复数据。
时间戳：32位，反映该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
SSRC：32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
CSRC：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。在共流源标识并且没有拓展头部（X=0）的情况下，RTP头部为12个字节。
RTP拓展头部
RTP提供拓展机制以允许实现个性化，某些与常规负载格式功能要求相独立的附加信息在RTP 拓展头的定义中实现。
若 RTP 固定头中的扩展标志位 X 置 1，则一个长度可变的扩展头部分被加到 RTP 固定头之后。扩展包含 16 比特的长度域，指示扩展项中 32 比特字的个数，不包括 4 个字节扩展头(因此零是有效值)。RTP 固定头之后只允许有一头个头扩展。为了使拓展头具有特定的含义,扩展头的前 16 比特用来作为特定含义的识别标识符或参数。这 16 比特的格式由具体实现的上层协议定义。基本的 RTP 说明并不定义任何头扩展本身。
RTP规格级别(profile)
profile定义了一系列负载类型和对应的负载格式，也定义了特定于具体应用的RTP扩展和修改。典型地，某个应用仅基于一个规格级别运行。IETF针对RFC3550在档次方面定义了一系列扩展协议。
RFC3551(RTP/AVP)在RFC3550的基础上针对RTP档次进行补充形成RTP/APVP档次，被用在具有最小会话控制的音视频会议中，是其它扩展档次的基础。该档次在没有参数协商和成员控制的会话中非常有用。该档次也为音视频定义一系列编码和负载格式。对于具体的流媒体负载格式，IETF也定义一系列协议详细描述，如VP8视频负载格式[6]和H264视频负载格式[7]，等等。
RFC3711(SRTP，也即RTP/SAVP)是RTP/AVP在安全方面进行扩展形成的档次，为RTP/RTCP提供数据加密、消息认证、重放保护等功能。SRTP具有高吞吐量和低数据膨胀等特点，是异构环境下对RTP/RTCP数据的有效保护。
RFC4585(RTP/AVPF)是RTP/AVP在及时反馈方面进行扩展形成的档次，使得接收端能够向发送端提供及时反馈，实现短时调整和基于反馈的修复机制。该协议定义早期RTCP报文以实现及时反馈，并定义一系列通用RTCP反馈报文和特定于应用的反馈报文，如NACK、PLI、SLI、RPSI等。
RFC5124(RTP/SAVPF)则是RTP/SAVP和RTP/AVPF的综合。SAVP和AVPF在使用时，需要参与者借助于SDP协议[8]就档次和参数信息达成一致。但是对一个RTP会话来说，这两种档次不能同时被协商。而实际应用中，我们有同时使用这两种档次的需要。因此，RTP/SAVPF档次应运而生，它能够使得RTP会话同时具有安全和及时反馈两方面的特性。
RTCP协议
RTCP需要与RTP协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口（复用情况下占用同一个端口），分别供RTP和RTCP使用。RTP本身并不能为数据包提供可靠传输的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。
RTCP功能概括
RTCP的主要功能可以概括为3个方面，服务质量的监视与反馈、媒体间的同步、多播组中成员的标识。此外还可以进行丢包重传或者 I 帧重传的控制。下面是消息类型
| Type | Description | References |
|---|---|---|
| 0 - 191 |
||
| 192 | FIR, full INTRA-frame request. | RFC 2032 |
| 193 | NACK, negative acknowledgement. | RFC 2032 |
| 194 | SMPTETC, SMPTE time-code mapping. | RFC5484 |
| 195 | IJ, extended inter-arrival jitter report. | RFC 5450 |
| 196 - 199 |
||
| 200 | SR, sender report. | RFC 3550 |
| 201 | RR, receiver report. | RFC 3550 |
| 202 | SDES, source description. | RFC 3550 |
| 203 | BYE, goodbye. | RFC 3550 |
| 204 | APP, application defined. | RFC 3550 |
| 205 | RTPFB, Generic RTP Feedback. | |
| 206 | PSFB, Payload-specific Feedback. | |
| 207 | XR, RTCP extension. | RFC 3611 |
| 208 | AVB, AVB RTCP packet. | IEEE 1733 |
| 209 | RSI, Receiver Summary Information. | RFC 5760 |
| 210 - 255 |
其中以发送者报告举例
版本(V)：同RTP包头域.
填充(P)：同RTP包头域.
接收报告计数器(RC)：5比特, 该SR包中的接收报告块的数目, 可以为零.
包类型(PT)：8比特, SR包是200.
长度域(Length)：16比特, 其中存放的是该SR包以32比特为单位的总长度减一.
同步源(SSRC)：SR包发送者的同步源标识符, 对应RTP包中的SSRC一样.
NTP timestamp：SR包发送时的绝对时间值, NTP的作用是同步不同的RTP媒体流, 一共8个字节，前4个字节代表
RTP timestamp：与NTP时间戳对应, 与RTP数据包中的RTP时间戳具有相同的单位和随机初始值.
Sender's packet count：从开始发送包到产生这个SR包这段时间里, 发送者发送的RTP数据包的总数, SRC改变时这个域清零.
Sender's octet count：从开始发送包到产生这个SR包这段时间里, 发送者发送的净荷数据的总字节数(不包括头部和填充), 发送者改变其SSRC时这个域要清零.
同步源n的SSRC标识符：该报告块中包含的是从该源接收到的包的统计信息.
丢失率(Fraction Lost)：表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率.
累计的包丢失数目：从开始接收到SSRC_n的包到发送SR, 从SSRC_n传过来的RTP数据包的丢失总数.
收到的扩展最大序列号：从SSRC_n收到的RTP数据包中最大的序列号.
接收抖动(Interarrival jitter)：RTP数据包接受时间的统计方差估计.
上次SR时间戳(Last SR,LSR)：取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特, 如果目前还没收到SR包, 则该域清零.
上次SR以来的延时(Delay since last SR,DLSR)：上次从SSRC_n收到SR包到发送本报告的延时.