学习日记之一：RTP的封装
关于RTP的封装:
版本号V[y1] :标识使用的RTP版本 2比特
[y1]版本号字段的唯一有意义的用途是作为数据包有效性检查的一部分。
填充位P[y2] :该位置1，则该RTP包尾部添加填充字节 1
[y2]填充很少使用，但是对于某些使用特定块大小的加密方案，以及使有效载荷格式适应固定容量信道，需要填充。
扩展位X[y3] :该位置1，RTP固定头部后添加扩展头部 1
[y3]较少使用
CSRC计数器CC:包含固定头部后面跟着的CSRC数目 4
标记位M[y4] :该位的解释由配置文档(profie)来承担
[y4]标记媒体流中感兴趣的事件
载荷类型PT:标识RTP载荷的类型 7
序列号SN: 发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值[y5] 是随机[y6] 的。 16
[y5]与时间戳一样都有可能发生环绕——当数据满的时候归零，此外由于初始值随机导致环绕可能随时发生
[y6]初始值随机是为了避免被攻击
时间戳: 记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增。时间戳是去除抖动和实现同步不可缺少的。 32
同步源标识符(SSRC)：同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。[y7] 该标识符是随机选取的 RFC1889推荐了MD5随机算法。 32
[y7]由于SSRC的值是在本地选择的，两个参与者是有可能选择值相同。可通过RTCP BYE调节(暂时还没看到)
贡献源列表（CSRC List）：0～15项，每项32比特，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。[y8] 由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。
[y8]正常情况下，RTP数据由单个源产生，但是当多个RTP流通过混合器或转换器时，多个数据源可能对RTP数据包有贡献。贡献源列表（CSRC）标识了对RTP数据包做出贡献但不对其时序和同步负责的参与者。
Header Extensions[y9] 头部扩展：
[y9]如果特定有效载荷格式需要附加头，则它们不应使用头扩展，而应作为有效载荷头在分组的有效载荷部分中携带
Payload Headers[y10] 有效载荷报头：有效载荷头部包含在固定头部和任何CSRC列表和头部扩展之后的RTP分组中。通常，有效载荷报头的定义构成了有效载荷格式规范的大部分。
[y10]头部包含信息越多，会话期间开销变大，但是信令将会变得简单？(不太懂)
Payload Data 有效载荷数据：直接在任何有效载荷报头之后的一个或多个媒体有效载荷数据帧构成RTP数据包的最后部分（如果需要，除了填充之外）。有效载荷数据的大小和格式取决于在会话建立期间选择的有效载荷格式和格式参数。
Padding 填充
下面是学习遇到的几点问题，我会在今后的学习中慢慢补充：
1.不同RTP包的SSRC码是在本地生成的，如果发生两个不同数据源的SSRC一样该如何进行处理
虽然SSRC标识符冲突的概率很低，但所有RTP 实现必须准备好检测冲突并采取适当的措施来解决它们。如果某个源在任何时候发现另一个源使用与其自身相同的SSRC标识符，它必须发送旧标识符的RTCP BYE数据包并 选择另一个随机数据包。（如下所述，在循环的情况下，此步骤仅执行一次。）如果接收器发现其他两个源发生冲突，则可以保留数据包中的一个并丢弃另一个数据包，这可以通过不同的方式检测到源传输地址或CNAME。预计这两个来源 解决碰撞，使情况不会持续。
2.序列号和时间戳都是递增，不过是递增差值不同，我以为两者是一致的，没必要分成两个
这点我自己有点思路说一下，同一时间的数据可能会以若干个RTP数据包发出去，然而就时间戳上来说，这些数据包的时间戳是相同的，而它们的序列号则会加一。通过序列号可以对这些同一时间产生的数据包进行排序。
3.看书的时候有提到环绕，如果初始值是确定的，产生环绕时间是可以确认的，然而出于安全考虑初始值被设计成随机的，这导致环绕发生时间变得不可预测，我想要了解一下解决措施
4.由于不同的数据源其时间戳初始值都是不同的，当通过混合器将它们合并成一个RTP数据时，如何确定它们的时间顺序，是按照接收时间重新生成时间戳吗？如果是按照接收顺序重新生成时间戳的话，有一组数据的第一个数据丢失了或者滞后了，在时间戳上这组数据会不会靠后？如果两组数据源产生数据的时间是相同的，却因为滞后或者丢失导致时间戳靠后，会不会在播放的时候显得不同步？