RFC3550(RTP) 5.3.1-6.3.4(主要是RTCP)翻译

5.3.1  RTP头部扩展
下面给出了一个扩展机制以允许某些实现要求能够试验在RTP数据包头中承载额外信息新的负载格式无关的功能。这个机制被设计为其他未扩展的实现能够忽略这些头部扩展。
注意，这个头部扩展只是打算用作某些受限用途。此机制的大多潜在使用最好以前面章节描述的方式来做。例如，对固定头部的一个策略相关的扩展处理起来更廉价，因为这并不是有条件的或可变的位置。一特定负载要求的额外信息“应当不”使用这个头部扩展，而是“应当”放在包的负载部分。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |

如果RTP头的X比特为1，“必须”在RTP头部可能的CSRC列表之后追加一变长的头部扩展。头部扩展包含16比特长度域给出了除扩展头部前4字节之外扩展头部的32比特字的数目（因而0是合法的）。最多允许一个扩展头部追加到RTP头部。为了允许多个互操作实现独立试验不同的头部扩展，或者允许某特定实现试验多余一种的头部扩展，头部扩展的头16比特被留作区分标识符或者参数。这16比特的格式将被特定实现采用的策略规范所定义。RTP规范自身并没有定义任何头部扩展。

6. RTP控制协议--RTCP
RTP控制协议(RTCP)向会话中所有参与者周期性发送控制包，利用与数据包相同的分发机制。下层协议必须提供数据包和控制包的多工，例如用不同的UDP端口。RTCP完成四个功能：
（1） 基本功能是提供数据传输质量的反馈。这是RTP作为一种传输协议整体的一部分，且与其他传输协议（见第10节关于拥塞控制的要求）的流量和阻塞控制相关。反馈可以直接用于自适应编码[18,19]。IP多播的实验还表明它是从接收机得到反馈信息以诊断传输故障的关键。向所有成员发送接收反馈可以使"观察员"评估相关问题是局部的还是全局的。类似IP多播的分发机制，使某些实体，诸如没有加入会话的网络业务提供者，接收到反馈信息并扮演诊断网络故障的第三方监视器。反馈功能通过 RTCP发射机和接收机报告提供，在第6.4节描述。   
（2）RTCP为每个RTP源携带一个持久性传输层识别符，称为正规名字或CNAME，见第6.5.1节。由于当发生冲突或程序重启时SSRC可能改变，所以接收机要求CNAME以跟踪每个成员。接收机还可能用CNAME来关联一系列相关RTP会话期中来自同一个成员的多个数据流,例如同步语音和图像。媒体间同步还要求数据发送机在其RTCP包中包含NTP和RTP时间戳。
（3）头两个功能要求所有成员都发送RTCP包，因此必须控制速率以使RTP会话成员数目可扩展到大的数量。通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会话中成员数目。此数目用来计算发包速率，见第6.2节。
（4）第四个可选的功能是传递少量的会话控制信息，例如在用户界面上显示的成员标识。这最可能在"松散控制"的会话中起作用。在"松散控制"会话里，成员可以不经过资格控制和参数协商而加入或退出会话。RTCP是一个联系所有成员的方便通路，但不要期望它支持具体应用所需的所有控制信息传递要求。这可能需要本文档范围之外的一个高层的会话控制协议。
在所有环境中，尤其是IP多播环境，都“应当”使用功能1-3。RTP应用设计者“应当”避免仅使用单播模式，这将使得成员数目不具有扩展性。在类似接收机反馈不可行的单向链路这样情形下，发送机和接收机“可能”独立控制RTCP的传输（如6.2节所述）。
非正规注解：在称作源相关多播（Source-Specific Multicast, 简称SSM）这个多播路由方式下，每个“通道”（源地址、组地址对）只有一个发送机，并且接收机（除了通道源）不能用多播来和通道其他成员联系。本处建议只是通过6.2节的完全关闭接收机RTCP来适应SSM。将来要针对SSM调整RTCP以维护接收机反馈。
6.1 RTCP报文格式
本规格定义了多个RTCP报文格式以承载不同的控制信息：
SR：发送机报告，描述作为活跃发送机成员的发送和接收统计数字
RR：接收机报告，描述非活跃发射机成员，或是与SR联合使用以描述活跃发射机的接收统计数字
SDES：源描述，包括CNAME
BYE：表示结束参与
APP：应用相关的功能
每个RTCP报文开始于与RTP数据包类似的固定头部，随后是一块结构化单元,它随报文类型不同而长度“可能”不同，但是总以32比特边界处终止。对齐要求和长度域使RTCP包可“堆栈”。可以将多个RTCP包不加任何间隔地拼接成一个复合RTCP包在一个下层协议(如UDP)中发送。复合包中没有明确给出独立的RTCP包的数目，因为下层协议有会提供一个总体长度以指出复合包的结束之处。   
复合包中的每个RTCP单包可以单独处理，而无需考虑包或包组合的顺序。然而,为了实现某些协议功能，添加以下限制:   
  -   接收统计数字(SR或RR)只要带宽限制允许就应当发送，以最大化统计信息的分辨率。因此每个周期性发送的复合RTCP包必须包含一个报告包。
  -   新的接收机需要尽可能迅速地接收一个源的CNAME以标识此源并且为嘴唇同步（lip-sync）之类目的启动相关的媒体。所以每个复合RTCP包必须还包括SDES CNAME除非这个复合RTCP包按照第9.1节描述的那样分割并部分加密。
  -   必须限制在复合包第一个包可能类型的数目，以增加在第一个字中常数比特的数目，还可以增加成功校验RTCP包的有效性的可能性以区分误传的RTP包或其他无关包。
因此，所有RTCP包必须在至少包含两个单包的复合包中传输，具有以下推荐格式：
加密前缀：当且仅当复合包按照9.1节被加密时，对每个RTCP复合包“必须”加随机32比特的前缀。如果加密要求填充，则填充“必须”增加到复合包的最后一个包。
SR或RR：复合包中的第一个RTCP包必须是一个报告包，以方便附录A.2所述的头部校验。即使没有数据发送和接收数据，此时“必须”发送空的RR包；或者复合包中其他的唯一包是BYE包。   
附加的RR：若被报告的接收统计源数目超过一个SR/RR包最大允许的31个，附加的RR包“应当”跟在最初的报告包后面。
SDES：每个复合RTCP包“必须”包括一个含有CNAME项的SDES包，除非9.1节特别说明的情形。如果特定应用要求的话，在带宽限制前提下（见6.3.9节），“可以”可选地报刊其他源描述项。
BYE或APP：其他RTCP包类型，包括将来定义的，“可以”按照任何顺序，除了BYE“应当”是一个给定SSRC/CSRC的最后一个包。同一包类型“可以”出现不止一次。
为了能正确估计（见6.2节）每个参数者的RTCP带宽，一个RTP参与者“应当”在每个报告间隔仅发送一个复合RTCP包，除非复合RTCP包按照9.1节分割以部分加密。如果源数目过多以至于不能将所有需要的RR放入单个RTCP包而不超出网络路径的最大传输单元（MTU），则每个间隔“应当”只把不超过MTU的一部分放入复合包。这个子集“应当”在多个间隔时循环选择以使得报告所有的源。
“建议”转换器和混合器在任何可能的时候，把其转发的从多个源来的独立的RTCP包组合经一个复合包以分摊报文过载（见第7节）。图1给出了一个混合器可能产生的RTCP复合包的例子。如果一个复合包总长度将操作网络MTU，“应当”将其分片成多个更短的复合包在下层协议独立的包中传输。这不会损害RTCP带宽估计，因为每个复合包代表至少一个不同的参与者。注意，每个复合包“必须”开始与一个SR或RR包。
一个实现“应当”忽略它不能识别类型的RTCP包。其他RTCP包类型可能按照第15节描述注册到IANA。
if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
|<----------------------- compound packet ----------------------->|
|<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound packet

6.2 RTP传输间隔
RTP被设计为允许一个应用涉及的会话尺寸从少量参与者到上千数目自动地扩展。例如，音频会议中的数据流量是自限制的，因为同时只有一到两个人同时说话，所以在任何给定链路上的多播数据速率相对于参与者数目而言是不变的。然而控制信息流量并不是自限制的。如果每个参与者以一个恒定速率发送接收报告，控制信息流量将随着参与者数目线性增长。因而，必须通过动态计算RTCP包传输间隔降低发送速率。
对每个会话，假设数据流量取决于参与者分享的一个称为“会话带宽”的总计限制。此带宽可能被网络保留。如果没有保留，可能有取决于环境的其他约束来设置此会话使用带宽的“合理的”最大值，这就是会话带宽。会话带宽可能基于本会话的价格或可用网络带宽的预先知识来选择。这在某种程度上与媒体编码无关，但是会话带宽可能限制了编码的选择。会话带宽常常就是同时活跃的发送机名义上的（nominal）带宽之和。对电话会议音频，这个数字一般是一个发送机的带宽。对分层编码（layered encodings），每一层是一个独立的RTP会话，具有自己的会话带宽参数。
会话带宽参数期望在一个会话管理应用被一个媒体应用调用时提供。但是媒体应用“可以”基于单个发送机数据带宽设置一个默认值。应用还“可以”基于多播范围规则或其他标准强制带宽限制。所有参与者都“必须”使用相同的会话带宽值，这样就能计算出相同的RTCP间隔。
控制和数据流量的带宽计算包括了低层传输和网络协议（例如UDP和IP），因为资源预留系统需要知道它们。应用还期望知道使用了这些协议中的那些。链路层头部排除在计算之外，因为报文在传输过程中将被用不同的链路层头部封装。
控制流量应当被限制到整个会话带宽的一个已知的小的比例：小是为了不至于损害传递数据这一主要功能；已知是为了给资源预留协议带宽规格时能考虑进控制流量，并且每个参与者能独自计算自己分享的那部分带宽。控制流量带宽是会话带宽中除数据流量外的那部分。由RTCP占用的会话带宽比例“建议”固定为5%。“建议”1/4的RTCP带宽给发送数据的的参与者，这样在一个包含大量接收机但少量发送机的会话中，新加入的参与者能更快的收到来自发送机的CNAME。当发送机在所有参与者所占比例超过1/4时，发送机应获得相应比例的RTCP带宽。虽然在间隔计算中这些值以及其他常量并不重要，但会话中所有的参与者“必须”使用相同的值以计算出相同的间隔。因而，在特定策略中这些常量“应当”是固定的。
一个策略“可以”规定控制流量带宽是会话的一个独立参数而不是会话带宽的一个严格的比例。使用独立参数使得速率自适应应用能设置RTCP带宽以与比会话带宽参数规定的最大带宽小的一个“典型的”数据带宽保持一致。
策略还“可以”进一步规定控制流量带宽分解成两个独立的会话参数分别针对活跃数据发射机和其他参与者：我们称这两个参数为S和R。按照“1/4 RTCP带宽分配给数据发射机”的建议，这两个参数的默认值“建议”分别为1.25%和3.75%。当发射机比例超过S/(S+R)，发送机获得(S+R)中相应比例。使用两个参数使得如下成为可能：对特定会话通过设置非数据发射机RTCP带宽为0，同时保持数据发射机RTCP带宽非0，RTCP接收报告完全关闭，而发送机报告仍然被发送以使能媒体间同步。“不建议”不关闭RTCP接收报告，因为第6节开始的功能列表需要它们。然而，这样做在一下情形下可能是合适的：单向链路上的系统，或者不需要接收质量或存在性反馈的反馈的会话，或是有其他办法避免拥塞的会话。
计算出来的符合RTCP包的传输间隔还“应当”有一个下界以避免在参与者数目较少而流量不平滑时报文突发而超过了允许的带宽。这还防止了在网络部分瞬变时报告间隔变得过小而延误了网络恢复时后的调节。在应用启动和发送第一个符合RTCP包之间“应当”强制一个延迟，这样就有时间受到从其他参与者来的俄RTCP包，从而报告间隔能更快地趋向正确值。此延迟“可以”设置为最小间隔的一半以更快地通告新参与者的键入。固定的最小间隔的“推荐”值是5秒。
一个实现“可以”把最小RTCP间隔变得更小以适合会话带宽参数，有以下限制：
  -  对多播会话，仅活跃数据发射机“可以”使用更小的最小值来计算符合RTCP包传输间隔。
  -  对单播会话，非活跃数据发射机也“可以”使用更小的值，发送第一个复合RTCP包之前的延迟“可以”是0。
  -  对所有会话，计算参与者超时间隔（见6.3.5节）时“应当”使用上述固定的最小值，这样那些不使用更小值的实现就不会被其他参与者过早地认为超时。
  -  更小值（以秒计）“推荐”采用360除以会话带宽（单位kb/s）。这个值在带宽超过72kb/s时小于5秒。
在6.3节和附录A.7中描述的算法符合本节提出的目标。此算法计算出发送RTCP复合包的间隔，并在所有参与者间分配允许的控制流量带宽。这允许应用在如标识所有参与者是重要的这样的小会话能快速响应，并且能自动调节到更大会话。此算法具有如下特征：
  -  计算出的RTCP包间隔随组内成员数目线性增涨。正是这个线性使得所有成员的控制流量总和为常量。
  -  实际RTCP包间隔在计算值[0.5,1.5]倍范围内随即选取，以避免不期望的所有参与者同步[20]。加入会话后的第一个RTCP包延迟是最小RTCP间隔[0,0.5]倍范围内随机值。
  -  计算出复合RTCP包的平均尺寸的估计值，包括所有发送和接收的，以自动适应承载的控制信息量的变化。
  -  既然计算出的间隔依赖于观察到的组成员数目，可能存在不希望的启动效应：在一新用户加入一正退出的会话，或多个用户同时加入一新会话。这些新用户刚开始对组规模估计不正确，这样它们的RTCP传输间隔非常短。这个问题在多个用户同时加入会话时比较明显。为处理这种情况，应用了一个被称为“timer reconsideration”的算法。此算法实现了一个简单的补偿(back-off)机制使得用户在组规模增长时阻止发送RTCP包。
  -  当用户离开会话，以BYE或超时，组规模减小，这样计算出的间隔应当减小。“reverse reconsideration”算法能够使得成员更快地减小其间隔以对组规模减小作出反应。
  -  BYE包与其他RTCP包处理不同。当用户离开组时并希望发送BYE包时，它可以在其安排的下一个RTCP包之前发送。但是，BYE包发送遵循一个补偿算法以避免大量成员同时离开会话时BYE包的泛滥。
这个算法可以用于那些允许所有参与者发送数据的会话。在此情形下，会话带宽参数是单个发送机带宽乘以参与者总数，并且RTCP带宽占其中5%。
此算法的细节在接下来给出。附录A.7给出了一个示范实现。

6.2.1 会话成员数目的维护
RTCP包间隔的计算依赖于对参与会话的站点数目的估计。新站点被计入当它们被听到时，并且“应当”为每个新站点在以SSRC或CSRC标识符索引的表（见8.2节）中创建相应条目以跟踪它们。新条目“可以”被认为无效，直到收到多个包含新SSRC的报文被（见附录A.1），或者收到一个包含对应SSRC的CNAME的SEDS RTCP包。当收到RTCP BYE包时，相应SSRC的条目“可以”被删除，除非此后一些散乱的数据包到达并导致重新创建此条目。替代地，“应当”标记此条目收到BYE并在适当延迟之后删除它。
一参与者“可以”标记另一站点非活跃，或如果条目无效则删除它，如果几个RTCP报告间隔（“推荐”5s）内没有收到RTP或RTCP包。这为丢包提供了某种健壮性。所有站点必须使用相同的乘数且必须计算出大指向等的RTCP报告间隔，这个超时才能正常工作。因而，特定策略“应当”固定此乘数。
对大量成员参与的会话，维护一个存储着SSRC标识符和相应状态信息的表可能并不可行。一个实现“可以”按照[21]所述那样使用SSRC抽样（sampling）以减小存储需求。一个实现“可以”使用其他类似的算法。一个关键要求就是这样的算法“应当不”大体上低估组规模，然而“可以”高估。

6.3 RTCP包发送和接收的规则
这儿概述了怎样发送和接收后如何处理RTCP包的规则。一个允许多播环境或多点单播（multipoint unicast）环境的实现“必须”符合6.2节的要求。这样的实现“可以”使用本节定义的算法以符合那些要求，或者“可以”使用其他相同性能或更高效的算法。一个限制为两方单播的实现“应当”仍然使用RTCP传输间隔随机值以避免不期望的多实例操作的同步，但是“可以”忽略6.3.3，6.3.6和6.3.7节中的“timer reconsideration”和“reverse reconsideration”算法。
为实施这些规则，一个会话参与者必须维护如下几个状态信息：
tp：最近一次发送RTCP包的时间；
tc：当前时间；
tn：下一个计划发送RTCP包的时间；
pmembers：最经一次计算tn时估计的会话成员总数；
members：会话成员总数的最新估计；
senders：会话中发射机总数的最新估计；
trcp_bw：目标RTCP带宽，即本会话中所有成员的RTCP包使用的总带宽，单位字节每秒。这是应用启动时提供给应用的“会话带宽”的一个指定的比例。
we_sent：一个标记，如果应用从上2个RTCP报告依赖发送过数据则为真。
avg_rtpc_size：本参与者发送和接收的所有RTCP复合包的平均尺寸，单位字节。此尺寸包含了低层传输和网络层协议头部（例如UDP和IP），如6.2节所述。
initial：一个标记，如果一个应用还没有发送第一个RTCP包则为真。
这些规则大多利用了在包传输期间“计算出的间隔”。此间隔在下面章节中描述。

6.3.1 计算RTCP传输间隔
为了保持可扩展性，会话参与者的包间平均间隔应当随组规模扩展。此间隔被成为计算出的间隔（calcutated interval）。它有以上描述的状态的某些部分来导出。计算出的间隔T按照如下方式决定：
1. 如果发送机数目少于或等于总数的25%，间隔T依赖于参与者是否为发射机（基于变量we_sent）。如果是发射机（we_sent为真），常量C被设置为平均RTCP包尺寸（avg_rtcp_size）除以25%的RTCP带宽（rtcp_bw），常量n被设置为发送机数目。如果we_sent为假，常量C被设置为平均RTCP包尺寸除以75%的RTCP带宽。常量n被设置为接收机数目（成员总数减去接收机数目）。如果发送机数目超过25%，发送机和接收机一起处理：常量C被设置为平均RTCP包尺寸除以总的RTCP带宽，n被设置为成员总数。如6.2节所述，一个RTP策略“可以”规定RTCP带宽被两个独立的参数（称为S和R）分别针对发射机和接收机。在此情形下，25%比例变为S/(S+R)，75%比例变为R/(S+R)。注意如果R为0，则发送机比例不过超过S/(S+R)，实现必须避免被0除。
2. 如果参与者还没有发送第一个RTCP包（变量initial为真），常量Tmin设置为2.5秒，否则设置为5秒。
3. 决定性的计算出的间隔Td设置为max(Tmin, n*C)。
4. 计算出的间隔T设置为[0.5,1.5]倍Td之间均匀分布的一个随机值。
5. T除以e-3/2=1.21828以补偿，因为timer reconsideration算法计算出的RTCP带宽的均值低于期望的平均值。
上述过程产生的间隔T是随机的，但平均意义上将至少25%的RTCP带宽给了发射机。如果发射机占总数的1/4多，在平均意义上，上述过程在所有参与者间分配相等的带宽。

6.3.2 初始化
一旦加入会话，参与者这样初始化以下值：tp为0，tc为0，senders为0，pmembers为1，members为1，we_send为假，rtcp_bw为会话带宽中指定的比例，initial为真，avg_rtcp_size为本应用稍后将构造的第一个RTCP包的可能尺寸。接下来计算T，并且第一个包设置计划在时间点tn=T处。这意味着一个传输定时器设置为在时间点T超时。注意，一个应用“可以”用任何它希望的方式实现这个定时器。
参与者增加自己的SSRC到成员表。

6.3.3 收到一个RTP或者非BYE RTCP包
当收到来自一个在成员表中不存在其SSRC的参与者的一个RTP或RTCP包，SSRC增加到此表，并且一旦按照6.2.1节所述那样校验此参与者通过就更新参数members。对校验过的RTP包中的每个CSRC执行同样的过程。
当收到来自一个在发送机表中不存在其SSRC的参与者的一个RTP包，SSRC增加到此表，并且更新senders的值。
对收到的每个复合RTCP包，avg_rtcp_size这样更新：
        avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
上式中packet_size是刚收到的RTCP包的尺寸。

6.3.4 收到一个RTCP BYE包
除了6.3.7描述的情形之外，如果收到一个RTCP BYE包，按照成员表检查包的SSRC。如果存在，则从表中删除此条目并且更新members值。再按照发射机表检查。如果存在，则从表中删除此条目并且更新senders值。
进一步，为了使得RTCP包发送速率更适应组规模的变化，当收到一个将导致members减少到小于pmembers的BYE包时，“应当”执行下面的“reverse reconsideration”算法：
  -  tn的值按照如下公式更新：
        tn = tc + (members/pmembers) * (tn - tc)
  -  tp的值按照如下公式更新：
        tp = tc - (members/pmembers) * (tc - tp).
  -  下一个RTCP包发送时间点被重新安排到tn，这之前的计划时间点更早。
  -  pmembers的值设置为等于members
本算法并没有防止如下情形：大多数而不是全部参与者同时离开一个大会话时，计算出的过早的超时就会使得估计出的组规模不正确地短暂性地降为0。本算法并没有使得估计值更快地回归到正确值。这种情形很少见，并且导致的后果也没什么害处，所以这个问题被认为不需要关注。