RTP/RTCP协议记录

RTP概述

• 1.简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。
• 2.音频和视频会议。如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。
• 3.基于UDP实现的，RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。

RTP包的封装

• RTP包的格式
  
• 版本号（V）：2比特，用来标志使用的RTP版本。现在唯一有意义的是作为包的有效性检查。
• 填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。
• 扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩展头部。
• CSRC计数器（CC）：4比特，含有固定头部后面跟着的CSRC的数目。
• 标记位（M）：1比特,该位的解释由配置文档（Profile）来承担，例如标记当前包是否是帧的最后一个数据包（标示帧边界作用）；
• 载荷类型（PT）：7比特，标识了RTP载荷的类型。详细说明在profile中，96-127保留作为动态分配使用。
• 序列号（SN）：16比特，发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。其中扩展序列号（32位）：低16位是序列号，高16位是序列号重复的次数。Extended_seq_num=seq_num+（65536*wrap_around_count）
• 时间戳：32比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加（时间在流逝嘛）。时间戳是去除抖动和实现同步不可缺少的。
• 同步源标识符(SSRC)：32比特，同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。
• 贡献源列表（CSRC List）：0～15项，每项32比特，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。

负载数据说明：一个包中可以有多个数据帧
检查帧数量的方式：1.大小固定，可以计算出来；2.帧大小不定，封装的帧中有一个标识位标记当前帧的大小。
包中数据数量的两个影响因素：1.MTU最大传输单元的大小；2.延迟因素（等待更多数据来填充一个更大的数据包）

RTCP协议

1. RTCP为RTP提供服务质量保证

2. RTCP的主要功能是四个功能 ：

○ 基本功能是提供数据传输质量的反馈。这是 RTP 作为一种传输协议的主要作用，它与其他协议的流量和拥塞控制相关。反馈可能对自适应编码有直接作用， 并且 IP 组播的实验表明它对于从接收 端 得到反馈信息以诊断传输故障也有决定性作用。向所有成员发送接收反馈可以使 " 观察员 " 评估这些问题是局部的还是 全局的。利用类似多点广播的传输机制，可以使某些实体，诸如没有加入会议的网络业务观察员，接收到反 馈信息并作为第三 方 监视员来诊断网络故障。反馈功能通过 RTCP 发送者和接收者报告实现。
○ RTCP 为每个 RTP 源传输一个固定的识别符，称为 规范 名 （ CNAME ） 。由于当发生冲突或程序重启时 S SRC可能改变，接收者要用 CNAME 来跟踪每个成员。接收者还要用 CNAME 来关联一系列相关 RTP 会话中来自同 一个成员的多个数据流，例如同步语音和图 像 。
○ 前 两个功能要求所有成员都发送 RTCP 包，因此必须控制速率以使 RTP 成员数可以逐级增长。通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会议中所有成员的数目。此数目可以用来估 计发包 速 率。
○ 第四个可选的功能是传输最少的会议控制信息，例如在用户接口中显示 参与的 成员。这最可能在 " 松散控制 " 的会议中起作用，在 " 松散控制 " 会议里，成员可以不经过资格控制和参数协商而加入或退出会议。RTCP 作为一个延伸到所有成员的方便通路，必须要支持具体应用所需的所有控制信息通信。
○ 在 RTP 用于 IP 多点广播时，功能 1-3 是强制的，在所有情况下都推荐使用。建议 RTP 应用开发商避免使用只能用于单向广播而不能 扩充 到多用户的方法。

3. RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。

RTCP有如下五种分组类型。

下面分别介绍这五种类型

(一) RTP接收者使用RTCP报告包提供接收质量反馈，报告包则根据接收者是否是发送者而采用两种格式中的一种。

除包类型代码外，发送者报告与接收者报告间惟一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR。SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR或RR包中，附加RR包可堆叠在初始SR或RR包之后。发送者报告包由三部分组成，也可能还有第四个特定设置扩展部分

1. 第一部分为头，8个八位组长，内容如下。
   ① 版本（V）：2位，标识RTP版本。
   ② 填充§：1位，如设置于此位，RTCP包结尾包含一些附加填充八位组，它们不属于控制信息。最后一个八位组填充表示应忽略多少个填充。有些加密算法需要填充，块大小固定。在组合RTCP包内，填充仅在最后一个包中需要，因为组合包加密成一个整体。
   ③ 接收报告计数(RC)：5位，包含在包内的接收报告块数目，0值为有效。
   ④ 包类型(PT)：8位，包含常数200标识此包为RTCP的SR包。
   ⑤ 长度：16位，32位字RTCP包长度的一半。
   ⑥ SSRC：32位，同步源标识。
2. 第二部分为发送者信息，20个八位组，出现在每个发送者报告包中。含义如下。
   ① NTP时标：64位，表示报告发送时的时钟时间，这样它就可用于合并从其他发送者到那些接收者的接收报告返回的时标。
   ② RTP时标：32位，与上述NTP时标同一时间有关，但与RTP时标有着相同的时间单位和同样的随机偏移。
   ③ 发送者包计数：32位，自开始发送来，直到SR包产生时刻，发送者发送RTP数据包总数。如改变SSRC标识符，此计数重置。
   ④ 发送者八位组计数：32位，发送者在RTP数据包中发送的载荷八位组总数。从发送开始，直到产生SR包，如发送者改变SSRC标识，重置此计数。这部分可用于估计载荷数据平均速率。
3. 第三部分包含接收报告块，大小不固定。每个接收报告块传送单个同步源接收RTP包的统计。发生冲突，当源改变SSRC标识时，接收者并不继续统计。这些统计包括：
   ① SSRC_n(源标识)：32位，接收报告块中信息所属源的SSRC标识。
   ② 丢失部分：8位，前一个SR或RR包发送以来所丢失的源SSRC_n的RTP数据包中一部分，定义成所丢失包的数目。
   ③ 丢失包累积数：24位，自接收以来所丢失的源SSRC_n的RTP数据包总数，定义成小于实际所接收包的数量，该数量包括迟到或复制的包。因此，迟到的包不计为丢失，如有复制，此数量可能为负数。
   ④ 收到已扩展的最高系列号：32位，低16位包含从SSRC_n源RTP数据包中收到的最高系列号，最重要的16位以系列号循环相应计数扩展系列号。如开始时间明显不同，同一连接内不同接收者将对系列号产生不同扩展。
   ⑤ 间隔抖动：32位，RTP数据包间隔时间的统计估计，以时标为单位，是一个无符号整数。
   ⑥ 最后SR时标(LSR)：32位，NIP时标的中间32位，如还没有收到SR，此段设为零。
   ⑦ 自最后一个SR来的延迟(DLSR)：32位，延迟以1／65536秒为单位，表示源SSRC_n收到的最后一个SR包与发送此接收块之间的时间，如还没有收到SR，此段设为零。

(二) 接收报告包格式与SR包类似，但包类型包含常数201，并删除发送者信息的五个字域。当没有数据传输或接收报告时，则将一个空RR包(RC=O)放在组合RTCP包的前头。

人们总是希望接收质量反馈不仅对发送者有用，而且对其他接收者和第三方监控都有用。发送者可根据反馈改变发送，接收者决定问题是出现在本地、区域还是全局。网络管理员可仅使用接收RTCP包、而不是RTP数据包的设置无关监控器来估计网络多播的性能。
累计计数用在发送信息与接收者报告块中，可考虑长期和短期测量与提供报告丢失恢复能力之间的差别。后两个接收到报告之间的差别可用来估计近来发送的质量。将NTP时标包含在内，从两个报告间隔的差别考虑速率。由于时标独立于数据编码时钟速率，很可能实现编码与设置无关的质量监控器。
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别则给出间隔期间希望发送的包数量，两者之比等于间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失率可通过NTP时标差除以丢失部分得到。
根据发送者信息，第三方监控器可计算出载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

(三) 源描述RTCP包（SDES）为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。

1. 项描述如下：
   （1）版本(V)、填充§、长度：如SR包中所描述。
   （2）包类型(PT)：8位，包含常数202，标识RTCP SDES包。
   （3）源计数(X)：1位，包含在SDES包中的SSRC／CSRC块数量，零值有效，但没有意义。
2. 源描述项
   CNAME
   规范终端标识SDES项。CNAME标识属性如下：
   如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
   像SSRC标识，CNAME标识在RTP连接的所有参加者中应是惟一的。
   为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。
   为方便第三方监控，CNAME应适合程序或人员定位源。
   
   NAME
   用户名称SDES项，这是用于描述源的真正的名称，如"John Doe，BitRecycler，Megacorp"，可以是用户想要的任意形式。对诸如会议应用，这种名称也许是参加者列表显示所最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中惟一依赖。
   

E-mail
电子邮件地址SDES项。邮件地址格式由RFC822规定，如“John.Doe@megacorp.com"。连接期间，电子邮件仍希望保持为常数。

PHONE
电话号码SDES项。电话号码应带有加号，代替国际接入代码，如“+86 288541 1212"即为中国电话号码。

LOC
用户地理位置SDES项。根据不同应用，此项具有不同的详细程度。对会议应用，字符串如"MurrayHill，New Jersey"就足够了。然而，对活动标记系统，字符串如“Room2A244，AT&T BLMH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。

TOOL
应用或工具名称SDES项，是一个字符串，表示产生流的应用的名称与版本，如“videotool1.2”。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。

NOTE
通知／状态SDES项。推荐的该项语法如下所述，但这些或其他语法可在设置中显式定义。NOTE项旨在描述源当前状态的过渡信息，如"onthe phone，can’ttalk"，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。
当其为活动时，由于NOTE项对显示很重要，其他非CNAME项(如NAME)传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20~30倍RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。

PRIV
专用扩展SDES项。该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前组长度段为8位。前缀字符中是定义PRIV项人员选择的名称，惟一对应应用接收到的其他PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其他人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
注意，前缀消耗了总长为255个八位组项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDESPRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性，IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。

(四) 断开RTCP包（BYE）

如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC／CSRC标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个八位组计数，后跟表示离开原因的很多八位组文本，如：“cameramalfunction"或"RTP loopdetected"。字符串具有同样的编码，如在SDES中所描述的。如字符串填充包至下32位边界，字符中就不以空结尾；否则，BYE包以空八位组填充。

(五) 定义应用的RTCP包（APP）

APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。

注意：

基于网络和传输协议的RTP

• 这部分讲述特殊网络和传输协议内与携带RTP包相关的内容。如果没有规范外特定协议定义替代，下列规则可适用。
• RTP依赖低层协议提供RTP数据和RTCP控制流的多路分解。对UDP和类似协议，RTP使用一个偶数端口号，而相应RTCP流使用下一个(奇数，递增)端口号。如应用使用一个奇数RTP端口，就应该用下一个小偶数端口代替。RTP数据包不包含长度段或其他描述，因此RTP依赖低层协议提供长度指示，RTP包最大长度仅受低层协议限制。如RTP包包含在提供连续八位组流的低层协议而不是信息(包)中，必须定义RTP包的封装以提供帧机制。如低层协议包含填充，也需要帧机制，否则结果无法决定RTP负载程度。这里没有定义帧机制。
• 当RTP包含在提供帧的协议中时，为了允许在一个低层协议数据单元(UDP包)包括几个RTP包，设置可指定所使用的帧方法。在网络或传输包中携带几个RTP包可减少头部，并可能简化不同流之间的同步。