学习日记之四：RTP/RTCP字段作用总结
RTP的封装:
版本号(V):
作用：标识使用的RTP版本，当前版本为2，版本号字段的唯一有意义的用途是作为数据包有效性检查的一部分。
字段丢失带来的影响：丢失意味着机器无法判断该数据包是否有效，丢弃。
填充位(P):
作用：该位置1，则该RTP包尾部添加填充字节，填充很少使用，但是对于某些使用特定块大小的加密方案，以及使有效载荷格式适应固定容量信道，需要填充。
字段丢失带来的影响：填充部分失去作用，加密失效，有效载荷格式与信道不匹配。
扩展位(X):
作用：该位置1，RTP固定头部后添加扩展头部，允许各个实现尝试新的与有效负载格式无关的功能。如果特定有效载荷格式需要附加头，则它们不应使用头扩展，而应作为有效载荷头在分组的有效载荷部分中携带。
字段丢失带来的影响：如果置1的情况下，头部扩展内容将变得无法识别。
CSRC计数器(CC):
作用：包含固定头部后面跟着的CSRC数目
字段丢失带来的影响：CSRC数目未知，如果该字段作为参数使用，则相应功能丧失。（不过我觉得遍历贡献源列表也可以计算出CC，只是浪费了时间）
标记位(M):
作用：标记媒体流中感兴趣的事件;其精确含义由使用的RTP配置文件和媒体类型定义。置1往往意味着音频流的开始，视频流的结束。
字段丢失带来的影响：无法很容易的确认前一帧的完整性（虽说即便接收到了也无法确认是否接收到了完整帧，但是有了它的话检测帧的完整性就会简单点），即便是在该位丢失的情况下，音频流可以结束静默期，因为***和时间戳之间的关系会发生变化。而通过改变时间戳也能来检测视频帧的开始。不过应用程序会根据这些观察值来降低其性能。
载荷类型(PT):
作用：标识RTP载荷的类型，接收应用程序检查有效负载类型以确定如何处理数据。
字段丢失带来的影响：很明显当该字段丢失，接收端将无法解码该RTP包，该RTP包将被丢弃
***(SN):
作用：发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。***的初始值是随机的。
字段丢失带来的影响：该字段丢失意味着这个RTP包序列未知，无法进行排序，丢弃。
时间戳(timestamp):
作用：记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增。时间戳是去除抖动和实现同步不可缺少的。
字段丢失带来的影响：该字段丢失意味着这个RTP包时间戳未知，无法进行排序，丢弃。（与***不同的是同一个数据流可能由若干个RTP包发出那么它们的时间戳是一致的，仅能通过***进行排序。而且数据流被采样的时间并不意味着这是它被发送的时间，我们可以这么理解，接收端通过***来判断接收数据的完整性，而通过时间戳来对这些数据进行排序以便播放媒体。）
同步源标识符(SSRC)：
作用：同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。并且当源信息发生变化时SSRC也要随之变化。该标识符是随机选取的 RFC1889推荐了MD5随机算法。
字段丢失带来的影响：该字段丢失意味着这个RTP包的来源无法确认，无法对其进行分组，丢弃。
贡献源列表(CSRC List)：0～15项，每项32比特，
作用：用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。
字段丢失带来的影响：该字段的丢失会导致接收端无法确认交谈双方（或者双方以上）的身份
Header Extensions 头部扩展：
Payload Headers 有效载荷报头：有效载荷头部包含在固定头部和任何CSRC列表和头部扩展之后的RTP分组中。通常，有效载荷报头的定义构成了有效载荷格式规范的大部分。
Payload Data 有效载荷数据：直接在任何有效载荷报头之后的一个或多个媒体有效载荷数据帧构成RTP数据包的最后部分（如果需要，除了填充之外）。有效载荷数据的大小和格式取决于在会话建立期间选择的有效载荷格式和格式参数。
Padding 填充
RTCP的封装：
RTP规范中定义了五种类型的RTCP数据包：接收者报告（RR），发送者报告（SR），源描述（SDES），离开申明（BYE）和特殊应用包（APP）。 它们都遵循一个共同的结构，如下图5.1所示：
版本号(V):
作用：标识使用的RTP版本，当前版本为2，版本号字段的唯一有意义的用途是作为数据包有效性检查的一部分。
字段丢失带来的影响：丢失意味着机器无法判断该数据包是否有效，丢弃。
填充位(P):
作用：该位置1，则该RTP包尾部添加填充字节，填充很少使用，但是对于某些使用特定块大小的加密方案，以及使有效载荷格式适应固定容量信道，需要填充。
字段丢失带来的影响：填充部分失去作用，加密失效，有效载荷格式与信道不匹配。
项目数IC：
作用：某些数据包类型包含项目列表，可能除了某些固定的类型特定信息之外。这些数据包类型使用项目计数字段来指示数据包中包含的项目数（该字段根据其用途在不同的数据包类型中具有不同的名称）。每个RTCP分组中可以包括多达31个项目，也受到网络的最大传输单元的限制。如果需要超过31个项目，则应用程序必须生成多个RTCP数据包。项目计数为零表示项目列表为空（这并不一定意味着数据包为空）。不需要项目计数的数据包类型可以将此字段用于其他目的。
字段丢失带来的影响：该字段丢失依据其所在的数据包类型判断，可以确定该字段功能丧失。
载荷类型(PT):
作用：标识RTP载荷的类型，接收应用程序检查有效负载类型以确定如何处理数据。
字段丢失带来的影响：很明显当该字段丢失，接收端将无法解码该RTP包，该RTP包将被丢弃
长度：
作用：长度字段表示公共报头之后的分组内容的长度。它以32位字为单位进行测量，因为所有RTCP数据包的长度都是32位的倍数，因此计数八位字节只会出现不一致的可能性。零是有效长度，表示该数据包仅包含四个八位字节的标头（在这种情况下，IC标头字段也将为零）。
字段丢失带来的影响：RTCP数据包长度未知，如果该字段作为参数使用，则相应功能丧失。（不过我觉的在读取数据的时候也可以计算出长度，就是有点浪费时间）
RTCP数据包永远不会单独传输; 相反，它们总是组合在一起进行传输，形成复合数据包。 每个复合数据包都封装在单个较低层数据包中 - 通常是UDP / IP数据包 - 用于传输。 如果要加密复合数2.据包，则RTCP数据包组的前缀为32位随机值。复合数据包结构如下图5.2所示：
RTCP SR：发送者报告
除了来自接收器的接收质量报告之外，RTCP还传送最近发送数据的参与者发送的发送者报告（SR）包。 它们提供有关正在发送的媒体的信息，主要是为了使接收器可以同步多个媒体流（例如，对口音同步音频和视频）。
RTCP SR包格式
发送方报告数据包由数据包类型200标识， 有效载荷包含一个24字节的发送器信息块，后跟零个或多个接收器报告块，由RC字段表示，就像这是一个接收器报告包一样。 当发件人也是接收者时，存在接收者报告块。其格式如下图所示：
版本号(V):
作用：标识使用的RTP版本，当前版本为2，版本号字段的唯一有意义的用途是作为数据包有效性检查的一部分。
字段丢失带来的影响：丢失意味着机器无法判断该数据包是否有效，丢弃。
填充位(P):
作用：该位置1，则该RTP包尾部添加填充字节，填充很少使用，但是对于某些使用特定块大小的加密方案，以及使有效载荷格式适应固定容量信道，需要填充。
字段丢失带来的影响：填充部分失去作用，加密失效，有效载荷格式与信道不匹配。
接收报告计数器(RC)：
作用：该SR包中的接收报告块的数目，可以为零。
字段丢失带来的影响：接收报告数不明，如果该字段被作为参数使用，则相应功能丧失。
载荷类型(PT):
作用：标识RTP载荷的类型，接收应用程序检查有效负载类型以确定如何处理数据。
字段丢失带来的影响：很明显当该字段丢失，接收端将无法解码该RTP包，该RTP包将被丢弃
长度域(Length)：
作用：其中存放的是该SR包以32比特为单位的总长度减一。包括标题和任何填充。（1的偏移使零成为有效长度并避免在扫描复合RTCP数据包时可能存在无限循环，而计数32位字则避免对4的倍数进行有效性检查。）
字段丢失带来的影响：RTCP数据包长度未知，如果该字段作为参数使用，则相应功能丧失。（不过我觉的在读取数据的时候也可以计算出长度，就是有点浪费时间）
同步(SSRC)：
作用：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
字段丢失带来的影响：该字段丢失意味着这个RTCP包的来源无法确认，无法对其进行分组，丢弃。
|
RTP时间戳计数器与实时之间的关系从相应的NTP时间戳计算，通过在采样时刻周期性地检查时钟时间来维持。 |
NTP Timestamp(Network time protocol)：
作用：SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。
字段丢失带来的影响：NTP时间戳丢失，无法用来同步RTP媒体流，丢弃。
RTP Timestamp：
作用：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。RTP与NTP时间戳之间存在某种映射关系，用于协调接收端与发送端之间时钟速率不同步。用于NTP 时间戳同步的源的媒体内和媒体间同步.
字段丢失带来的影响：RTP时间戳丢失，无法对媒体流内和媒体间进行同步，丢弃。
|
用于计算丢失率，便于在短期和长期内进行测量，并使报告丢失具有弹性。 |
发送方的数据包数(Sender’s packet count)：
作用：从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数.SSRC改变时，这个域清零。
字段丢失带来的影响：发送方的数据包数未知，如果该字段作为参数使用，则相应功能丧失。
发送方的八位字节数(Sender’s octet count)：
作用：从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其SSRC时，这个域要清零。
字段丢失带来的影响：发送方的八位字节数未知，如果该字段作为参数使用，则相应功能丧失。
同步源n的SSRC标识符：
作用：该报告块中包含的是从该源接收到的包的统计信息。此接收报告块中的信息所属的源的SSRC标识符。
字段丢失带来的影响：该报告块的数据源未知，其携带的相应信息作废，丢弃。
丢失率(Fraction Lost)：
|
用于优化当前使用的媒体格式和错误保护编码，提高传输质量 |
作用：表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。
字段丢失带来的影响：丢失率未知，发送者无法判断损失是短暂的还是长期的。如果该字段作为参数使用，则相应功能丧失。
累计的包丢失数目：
作用：从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
字段丢失带来的影响：累计的包丢失数目未知，如果该字段作为参数使用，则相应功能丧失。
收到的扩展最大***：
作用：从SSRC_n收到的RTP数据包中最大的***。
字段丢失带来的影响：从SSRC_n收到的RTP数据包中最大的***未知，该数据源发送数据的数目无法确认，如果该字段作为参数使用，则相应功能丧失。
接收抖动(Interarrival jitter)：
作用：RTP数据包接受时间的统计方差估计
字段丢失带来的影响：RTP数据包接受时间的统计方差估计未知。无法用于检测网络拥塞。如果该字段作为参数使用，则相应功能丧失。
|
用于计算与接收方之间的往返时间优化媒体编码降低延时 |
上次SR时间戳(LastSR,LSR)：
作用：取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零。
字段丢失带来的影响：上次SR时间戳未知。如果该字段作为参数使用，则相应功能丧失。
上次SR以来的延时(DelaysincelastSR,DLSR)：
作用：上次从SSRC_n收到SR包到发送本报告的延时。
字段丢失带来的影响：上次SR以来的延时时间未知。如果该字段作为参数使用，则相应功能丧失。
RTCP RR：接收者报告
RTCP的主要用途之一是接收质量报告，它通过RTCP接收器报告（RR）数据包完成，这些数据包由接收数据的所有参与者发送。
接收器报告分组由201的分组类型标识，接收方报告数据包包含正在发送报告的参与者（报告者SSRC）的SSRC（同步源），后跟零个或多个报告块，由RC字段表示。格式如下图所示：
与SR相同只是和发送者相关的五个参数被省略了
RTCP SDES：源描述项
RTCP还可用于传送源描述（SDES）数据包，这些数据包提供参与者标识和补充详细信息，例如位置，电子邮件地址和电话号码。 SDES数据包中的信息通常由用户输入，并且通常显示在应用程序的图形用户界面中，尽管这取决于应用程序的性质（例如，提供从电话系统到RTP的网关的系统可能会使用 SDES包传送来电显示）。
RTCP SDES包格式
每个源描述包具有图5.7中所示的格式并使用RTCP包类型202.SDES包包括零个或多个SDES项列表，由SC头字段表示的确切数字，每个包含关于单个源的信息。
源计数SC：5位，此SDES数据包中包含的SSRC / CSRC块的数量。一个零值是有效的，但没用。
SDES项格式如下：
RTP规范中定义了几种类型的SDES项，其他类型可能由未来的配置文件定义。项目类型为零保留，表示项目列表的结尾。其他标准项类型包括CNAME，NAME，EMAIL，PHONE，LOC，TOOL，NOTE和PRIV。
必须包含CNAME 项以提供从SSRC 标识符到保持不变的源（发送方或接收方）的标识符的绑定。
CNAME标识符具有以下属性：如果发现SSRC冲突或程序重新启动，随机分配的SSRC标识符可能会更改，接收者可利用CNAME来跟踪参加者。
RTCP BYE：表明参与者将结束会话
RTCP通过RTCP BYE数据包提供松散的成员资格控制，这表明一些参与者已离开会话。当参与者离开会话时，或者由于冲突而更改其SSRC时，会生成BYE数据包。 BYE数据包可能在传输过程中丢失，某些应用程序不会生成它们;所以即使没有收到他们的BYE，接收者也必须准备好暂停一段时间未被听到的参与者。
BYE数据包的重要性在某种程度上取决于应用程序。它始终指示参与者正在离开RTP会话，但参与者之间可能还存在信令关系（例如，SIP，RTSP或H.323）。 RTCP BYE数据包不会终止参与者之间的任何其他关系。
BYE数据包由数据包类型203标识，其格式如下图5.10所示。公共RTCP报头中的RC字段指示分组中SSRC标识符的数量。值为零有效但无用。在接收到BYE数据包时，实现应假定列出的源已离开会话并忽略来自该源的任何其他RTP和RTCP数据包。在收到BYE后的一段时间内保持离开参与者的状态非常重要，以允许延迟数据包。
RTCP APP：应用描述功能
最后一类RTCP数据包（APP）允许应用程序定义的扩展。 它有数据包类型204，格式如下图5.11所示。 应用程序定义的数据包名称是一个四字符前缀，用于唯一标识此扩展名，每个字符都从ASCII字符集中选择，大写和小写字符被视为不同。 建议选择数据包名称以匹配它所代表的应用程序，并选择由应用程序协调的子类型值。 数据包的其余部分是特定于应用程序的。