RTCP RTP报文结构

RTP协议的报文头格式结构

开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下：
①版本（V）
2位，标识RTP版本。

②填充标识（P）
1位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。

③扩展（X）
1位，如设置扩展位，固定头后跟一个头扩展。

④CSRC计数（CC）
4位，CSRC计数包括紧接在固定头后CSRC标识符个数。

⑤标记（M）
1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位。

⑥载荷类型（PT）
7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來。

[align=left]常用 types：[/align]

[align=center]Payload Type[/align]	[align=center]Codec[/align]
[align=center]0[/align]	[align=center]PCM μ -Law[/align]
[align=center]8[/align]	[align=center]PCM-A Law[/align]
[align=center]9[/align]	[align=center]G..722 audio codec[/align]
[align=center]4[/align]	[align=center]G..723 audio codec[/align]
[align=center]15[/align]	[align=center]G..728 audio codec[/align]
[align=center]18[/align]	[align=center]G..729 audio codec[/align]
[align=center]34[/align]	[align=center]G..763 audio codec[/align]
[align=center]31[/align]	[align=center]G..761 audio codec[/align]

⑦系列号
16位，系列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。

⑧时标
32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。



由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。

⑨SSRC
32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。

⑩CSRC列表
0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。

RTCP协议的报文头格式结构

http://blog.csdn.net/hrbeuwhw/article/details/8135109  参考这个更全面。



RTCP 主要完成四个功能服务：
RTCP 提供数据分发质量反馈信息。这是 RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。
RTCP 为 RTP 源携带一个持久性传输层标识符，称为规范名或 CNAME 。由于一旦发现冲突或程序重启时， SSRC 标识符会随之改变，所以接收方需要 CNAME 来跟踪每一个参与者。同时接收方还要求 CNAME 能够与一组相关 RTP 会话中来自于给定参与者的多重数据流相关联，例如同步视频和音频。
上述前两个功能要求所有的参与者都要发送 RTCP 包，因此必须控制速率以便 RTP 按比例增加大量的参与者。通过每一个参与者发送各自的控制包给其它所有参与者，每一个参与者能够独立观察到参与者数量，该数量可用来计算控制包的发送速率。
OPTIONAL 功能用于传送最少会话控制信息，例如在用户界面显示参与者标识。这对于“松散受控”会话（在没有成员控制或阐述协商的情况下，参与者可以加入或退出该会话）是非常有用的。
上述功能 1 － 3 适用于所有环境，尤其是 IP 组播环境。 RTP 应用程序设计者应该避免设计只能工作于单播模式并且不能增加到大量数量的机制。在某些情况下如单向链接中，不可能有来自接收方的反馈，所以 RTCP 的传输就可能由发送方和接收方分别独立控制。