RTCP总结.docx

RTCP总结.docx

《RTCP总结.docx》由会员分享，可在线阅读，更多相关《RTCP总结.docx（14页珍藏版）》请在冰豆网上搜索。

RTCP总结

一、RTCP包格式  

这部分定义了几个RTCP包类型，可以传送不同的控制信息：

 ○SR：

发送者报告，描述作为活跃发送者成员的发送和接收统计数字；

○RR：

接收者报告，描述非活跃发送者成员的接收统计数字；

○SDES：

源描述项，其中包括规范名CNAME。

○BYE：

表明参与者将结束会话。

○APP：

应用描述功能。

 在本文中将详细介绍SR和RR。

 每个RTCP包的开始部分是与RTP数据包相类似的固定部分，随后是一块结构化单元，它随负载类型不同长度发生变化，但是总以32比特终止。

对齐要求和长度域使RTCP包可"堆栈"，即可以将多个RTCP包形成一个复合RTCP包，在底层协议（如UDP）中，通常都是将复合包作为一个包传输的。

复合包中的每个RTCP单包可以单独处理，而无需考虑包复合的顺序。

然而，为了实现某些协议功能，添加以下限制：

○接收数据的统计信息（在SR或RR中）。

只要带宽允许应尽可能经常的发送，以达到统计数字的最大分辨率。

因此每个周期发送的RTCP包必须包含一个报告包。

○新的参与者需要尽快接收一个源的规范名以识别数据源并与媒体建立会话。

因此，每个包中必须包含源描述项中的规范名。

除非复合包进行了分割以进行部分加密。

○必须限制首次在复合包中出现的包类型的数目，以增加在第一个字中常数比特的数目，这样可以增加RTCP包的有效性，以区分误传的RTP包和其他无关的包。

因此，所有RTCP包必须以复合包的形式发送。

复合包中至少有两个单个的RTCP包。

具有以下格式：

 ○加密前缀：

当且仅当复合包被加密时，对每个RTCP复合包加32比特的前缀。

 ○SR或RR：

复合包中的第一个RTCP包必须是一个报告包。

即使没有数据发送和接收，此时发送空的RR包，或者复合包中其他的唯一包是BYE包，也必须发送报告包。

○附加的RR：

若被报告的接收统计源数目超过SR/RR包中最大允许的31个，附加的RR必须跟在最初的报告包后面。

　　○源描述SDES

○BYE或APP包

每个RTP参与者在一个报告间隔内应只发送一个RTCP复合包，以便正确估计每个参与者的RTCP带宽。

如果数据源的个数太多，以至于不能把所有的RR包都放到同一个RTCP包中而不超过网络路径的最大传输单元（MTU），那么可在每个间隔中发送其中的一部分包。

在多个发送间隔中，所有的包应该被等概率的选中。

这样就可以报告所有数据源的接收数据的情况。

如果一个RTCP复合包的长度超过了网络路径的MTU，则它应当被分割为多个更短的RTCP包来传输。

这不会影响对RTCP带宽的估计，因为每一个复合包至少代表了一个参与者。

要注意的是每个RTCP复合包必须以SR或RR包开头。

|[---------packet--------][----------packet----------][-packet-]

--------------------------------------------------------------------

R[SR#sendinfo#site1#site2][SDES#CNAMEPHONE#CNAMELOC][BYE##why]

--------------------------------------------------------------------

|<-----------------------compoundpacket----------------------->|

|<--------------------------UDPpacket------------------------->|

#:

SSRC/CSRCidentifier

图1:

RTCP复合包举例

二、RTCP传输时间间隔

RTP被设计为允许应用自动适应不同的规模的会话――从几个参与者到几千个参与者的会话。

对每一个会话，我们假定数据传输受到一个上限――会话带宽的限制。

会话带宽分配给所有的参与者。

这个带宽会被预留，并由网络所限制。

如果没有预留，基于环境的其他约束将会确定合理的最大带宽供会话使用，这就是会话带宽。

会话带宽在一定程度上独立于媒体编码，但媒体编码却依赖于会话带宽。

在涉及媒体应用时，会话带宽参数最好由一个会话控制应用提供。

但媒体应用可能设置一个默认参数。

此参数由单个发送者选择的编码方式的数据带宽算出。

会话管理可能会基于多播范围的规则或其他标准确定带宽限制。

所有的参与者应使用相同的会话带宽值以保证计算出相同的RTCP间隔。

控制传输带宽应当是会话带宽的一小部分，这部分所占总的会话带宽的百分比应是已知的。

一小部分：

传输协议的首要功能是传输数据；已知：

控制传输带宽可以被放进带宽描述中提供给资源预留协议，并且使每个参与者都可以独立的计算出他所占有的带宽份额。

控制传输带宽作为额外的一部分加入到会话带宽中。

建议RTCP控制传输带宽为RTCP会话带宽的5%。

其中的1/4分配给发送者；当发送者的比例超过所有参与者的1/4时，其RTCP控制带宽相应增加。

所有的会话参与者必须使用相同的常数（以上提到的百分比），以便计算出相同的发送时间间隔。

这些常数应在一个特殊的描述文件中确定。

计算出的RTCP复合包的发送时间间隔应该有一个下限，以免参与者数量较少时大量发送RTCP包。

这也使网络暂时断开时，发送间隔不会太小。

在应用开始时，一个延迟应加到第一个的TCP复合包发送之前，以便从其他参与者接收RTCP复合包。

这样，发送时间间隔能更快的收敛到正确的值。

这个延迟可以设为最小时间间隔的一半。

固定的时间间隔建议为5秒。

一个实现可能使RTCP最小发送时间间隔与会话带宽参数成比例。

则应满足下列约束：

○对多播会话，只有活动的数据发送者使用减小的最小化的值计算RTCP复合包的发送时间间隔。

○对单播会话，减小的值也可能被不是活动的数据发送者使用，发送初始的RTCP复合包之前的延迟可能是0。

○对所有会话，在计算参与者的离开时间时，这个固定最小值会被用到。

因此，不使用减小的值进行RTCP包的发送，就不会被其他参与者提前宣布超时。

○减小的最小时间间隔建议为：

360/sb（秒），其中sb：

会话带宽（千字节/秒）。

当sb>72kb/s时，最小时间间隔将小于5s。

○计算出的RTCP包的时间间隔与组中参与者的人数成正比。

（参与者越多，发送时间间隔越长，每个参与者占有的RTCP带宽越小）。

○RTCP包的（真实）时间间隔是计算出的时间间隔的0.5～1.5倍之间某个随机的值，以避免所有的参与者意外的同步。

○RTCP复合包的平均大小将会被动态估计，包括所有发送的包和接收的包。

以自动适应携带的控制信息数量的变化。

○由于计算出的时间间隔依赖于组中的人数。

因此，当一个的用户加入一个已经存在的会话或者大量的用户几乎同时加入一个新的会话时，就会有意外的初始化效应。

这些新用户将在开始时错误的估计组中的人数（估计太小）。

因此他们的RTCP包的发送时间间隔就会太短。

如果许多用户同时加入一个会话，这个问题就很重要了。

为了处理这处问题考虑了一种叫“时间重估”的算法。

这个算法使得组中人数增加时，用户能够支持RTCP包的传输。

当有用户离开会话，不管是发送BYE包还是超时，组中的人数会减少。

计算出的时间间隔也应当减少。

因此，应用“逆向重估”算法，使组中的成员更快的减少他们的时间间隔，以对组中的人数减少做出响应。

○BYE包的处理和其他RTCP包的处理不同。

BYE包的发送用到一个“放弃支持”算法。

以避免大量的BYE包同时发送，使大量参与者同时离开会话。

这个算法适用于所有参与者都允许RTCP包的情况。

此时，会话带宽＝每个发送者的带宽×会话中参与者的总人数。

维持会话成员的人数

当侦听到新的站点的时候，应当把他们加入计数。

每一个登录都应在表中创建一条记录，并以SSRC或CSRC进行索引。

新的登录直到接收到含有SSRC的包或含有与此SSRC相联系的规范名的SDES包才视为有效。

当一个与SSRC标识符相对RTCP　BYE包收到时，登录会被从表中删除。

除非一个“掉队”的数据包到达，使登录重新创建。

如果在几个RTCP报告时间间隔内没有RTP或RTCP包收到，一个参与者可能标记另外一个站点静止，并删除它。

这是针对丢包提供的一个很强健的机制。

所有站点对这个超时时间间隔乘子应大体相同，以使这种超时机制正常工作。

因此这个乘子应在特别的描述文件中确定。

对于一个有大量参与者的会话，维持并存贮一个有所有参与者的SSRC及各项信息的表几乎是不可能的因此，只可以只存贮SSRC。

其他算法类似。

关键的问题就是，任何算法都不应当低估组的规模，虽然它有可能被高估。

三、RTCP包的发送和接收规则

下面列出了如何发送RTCP包，当接收到的TCP包时该干什么的规则。

为执行规则，一个会话参与者就维持下列变量：

tp:

　RTCP包发送的最后时间。

tc:

当前时间。

tn:

估计的下一个RTCP包要发送的时间。

pmembers:

tn最后被重新计算时，会计的会话成员的人数。

members:

会话成员人数的当前估计。

senders:

会话成员中发送者人数的估计。

rtcp_bw:

目标RTCP带宽。

例如用于会话中所有成员的RTCP带宽。

单位bit/s。

这将是程序开始时，指定给“会话带宽”参数的一部分。

we_sent:

自当前第二个前面的RTCP发送后，应用程序又发送了数据，则此项为true。

avg_rtcp_size:

此参与者收到的和发送的RTCP复合包的平均大小。

单位：

bit。

此大小包括底层传输层和网络层协议头。

initial:

如果应用程序还未发送RTCP包，则标记为true。

许多规则都用到了RTCP包传输的“计算时间间隔”。

此时间间隔将在随后的小节描述。

1）计算RTCP传输时间间隔一个会话参与者包的平均发送时间间隔应当和所在会话组中人数成正比。

这个间隔称为计算时间间隔。

它由上面提到的各个状态参量结合起来计算得出。

计算时间间隔T的计算如下：

1．如果发送者人数≤会话总人数×25%。

则T取决于此参与者是否是发送者（we_sent的值）；否则，发送者和接收者将统一处理。

2．如果initial为true（则未发送过RTCP包），则设Tmin=2.5s;否则设Tmin=5s。

3．决定性的计算时间间隔（deterministiccalculatedinterval）Td=max（Tmin,n*c）。

4.T=Td*λ；其中λ~U（0.5,1.5）。

即λ服从0.5到1.5之间的均匀分布。

5.T=T/（e-0.5）≈T/1.21828，补偿时间重估算法，使之收敛到比计算出的平均RTCP带宽小的一个值。

这个算法产生了一个随机的计算时间间隔，并把至少25%的RTCP带宽分配给发送者，其余的分给接收者。

若发送者超过会话总人数的25%，此算法将把带宽平均分给所有的参与者。

2）初始化

一加入会话，参与者的各状态参量初始化为：

tp=0；tc=0；senders=0；pmembers=1；members=1；vw_sent=false；rtcp_bw:

由会话带宽参数的相应部分得到；initial=true；avg_rtcp_size:

初始化为应用程序稍后将发送的RTCP包的可能大小；tn=T（这意味着，一个计时器将经T时间后被唤醒）；应用程序可以用任何它需要的方式实现计时器。

参与者把它自己的SSRC加到成员列表中。

3）接收到的TP包或一个非BYE的RTCP包

当收到一个参与者的RTP或RTCP包时，若其SSRC不在成员列表中，将其SSRC加入列表；若此参与者被确认有效，就把列表中成员的值更新。

对每个有效的RTP包中的CSRC执行相同的过程。

当收到一个参与者的RTP包时，若其SSRC不在发送者列表中，则将其SSRC加入发送者列表，更新相应的值。

每收到一个RTCP复合包，avg_rtcp_size更新为avg_rtcp_size　=　1/16　*　packet_size　+　15/16　*　avg_rtcp_size　；其中packet_size是刚收到的RTCP复合包的大小。

4）接收RTCP　BYE包

如果收到一个RTCP　BYE包，则检测成员列表。

若SSRC存在；先移除之，并更新成员的值。

另外，为使RTCP包的发送速率与组中人数变化更加协调，当收到一个BYE包使得members的值pmembers时，下面的逆向重估算法应当执行：

（1）tn的更新：

tn=tc+（members/pmembers）*（tn–tc）；

（2）tp的更新：

tp=tc–（members/pmembers）*（tc–tp）；下一个RTCP包将在时刻tn被发送，比更新前更早一些。

（3）pmembers的更新：

pmembers=members；

这个算法并没有防止组的大小被错误的在短时间内估计为0的情况。

如：

在一个较多人数的会话中，多数参与者几乎同时离开而少数几个参与者没有离开的情况。

这个算法并没有使估计迅速返回正确的值。

因为这种情况较罕见，且影响不大。

5）SSRC超时

在随机的时间间隔中，一个参与者必须检测其他参与者是否已经超时。

为此，对接收者（we_sent为false），要计算决定性时间间隔Td，如果从时刻Tc-M*Td（M为超时因子，默认为5秒）开始，未发送过RTP或RTCP包，则超时。

其SSRC将被从列表中移除，成员被更新。

在发送者列表中也要进行类似的检测。

发送者列表中，任何从时间tc-2T（在最后两个RTCP报告时间间隔内）未发送RTP包的发送者，其SSRC从发送者列表中移除，列表更新。

如果有成员超时，应该执行4）节中的逆向检测算法。

每个参与者在一个RTCP包发送时间间隔内至少要进行一次这样的检测。

6）发送时钟到时了

当包传输的发送时钟到时，参与者执行下列操作：

（1）按1）节的办法计算T。

（2）更新发送时钟的定时时间，判断是否发送RTCP包，更新pmembers。

如图：

7）发送一个BTE包

当一个参与者离开会话时，应发送BYE包，通知其他参与者。

为避免大量参与者同时离开系统时，大量BYE包的发送，若会话人数超过50，则参与者在要离开会话时，应执行下面的算法。

这个算法实际上“篡夺”了一般可变成员的角色来统计BYE包。

（1）tp=tc；members=1；pmembers=1；sinitial=1；we_sent=false；senders=0；rtcp_size:

设置为将要发送的RTCP包大小；计算“计算时间间隔”T；tn=tc+T；（BYE包预计在时刻tn被发送）。

（2）每当从另外一个参与者接收到BYE包时，成员人数加1。

不管此成员是否存在于成员列表中，也不管SSRC采样何时使用及BYE包的SSRC是否包含在采样之中。

如果收到RTP包或甚的RTCP包（除BYE包之外的RTCP包），成员人数不增加。

类似，只有在收到BYE包时，avg_rtcp_size才更新。

当RTP包到达时，发送者人数senders不更新，保持为0。

（3）在此基础上，BYE包的传输服从上面规定的一般的RTCP包的传输。

这允许BYE包被立即发送，并控制总的带宽使用。

在最坏情况下上，这可能会使RTCP控制包使用两倍于正常水平的带宽，达到10%――其中5%给BYE包的RTCP包，其余5%给BYE包。

一个参与者若不想用上面的机制进行RTCP包的发送，可以直接离开会话，而根本不发送BYE包。

他会被其他参与者因超时而删除。

一个参与者想离开会话时，如果组中的人数会计数目小于50，则参与者可以直接发送BYE包。

另外，一个从未发送过RTP或RTCP包的参与者，在离开会话时，不能发送BYE包。

8）更新we_sent变量

如果一个参与者最近发过RTP包，则变量we_sent值为true,否则为false。

相同的机制可以管理发送者中的其他参与者。

如果参与者发送了TPT包而此时，其对应的we_sent变量值为false,则就把它自己加到发送者列表中，并设置其we_sent变量为true。

第4）节中描述的逆向重估算法应当被执行。

以可能减少发送SR包前的延迟。

每次发送一个RTP包，其相应的传输时间都会记录在表中。

一般发送者的超时算法应用到参与者自身：

从tc-2T时开始，一直没有发送RTP包，则此参与者就从发送者列表中将其自身移除，减少发送者总数，并设置we_sent变量值为false。

9）源描述带宽的分配

LIVE555中只有规范名（CNAME）,其余的没有实现。

四、发送者和接收者报告

 RTP接收者利用RTCP报告包提供接收质量反馈。

根据接收者是否同时还是发送者，RTCP包采取两种不同的形式。

发送者报告（SR）和接收者报告（RR）格式中唯一的不同，除包类型码之外，在于发送者报告包括20字节的发送者信息。

 SR包和RR包都包括零到多个接收报告块。

针对该接收者发出上一个报告块后接收到RTP包的起始同步源，每个源一个块。

报告不发送给CSRC列表中的贡献源。

每个接收报告块提供从特定数据源接收到数据的统计信息。

由于SR/RR包最多允许31个接收报告块，故可以在最初的SR或RR包之后附加RR包，以包含从上一个报告以来的间隔内收听到的所有源的接收报告。

如果数据源太多，致使若把所有的RR包放到同一个RTCP复合包中会超出网络的MTU。

那么就在一个周期内选择上面RR包的一部分以不超过MTU。

这些RR包的选取应让各个包都有同等的几率被取到。

这样在几个发送周期间隔中，对所有的数据源就都发送接收报告了。

 以下部分定义了两种报告的格式。

如果应用程序需要其他信息，他们可以被扩展。

1）SR：

发送者报告RTCP包

 0123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header|V=2|P|RC|PT=SR=200|length|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|SSRCofsender|

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

sender|NTPtimestamp,mostsignificantword|

info+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|NTPtimestamp,leastsignificantword|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|RTPtimestamp|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|sender'spacketcount|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|sender'soctetcount|

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report|SSRC_1（SSRCoffirstsource）|

block+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1|fractionlost|cumulativenumberofpacketslost|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|extendedhighestsequencenumberreceived|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|interarrivaljitter|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|lastSR（LSR）|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|delaysincelastSR（DLSR）|

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report|SSRC_2（SSRCofsecondsource）|

block+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2:

...:

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|profile-specificextensions|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 发送者报告包由3部分组成，若定义，可能跟随第4个面向协议的扩展部分。

 第一部分，头部，8字节长。

该域有以下意义：

 版本（V）：

2比特 RTP版本识别符，在RTCP包内的意义与RTP包中的相同。

此协议中定义的版本号为2。

 填充（P）：

1比特 若设置填充比特，该RTCP包在末端包含一些附加填充比特，并不是控制信息的基本部分。

填充的最后一个比特统计了多少个字节必须被忽略。

填充可能会用于需要固定长度块的加密算法。

在复合RTCP包中，复合包作为一个整体加密，填料比特只能加在最后一个单个RTCP包的后面。

 接收报告块计数（RC）：

5比特 该包中所含接收报告块的数目。

零值有效。

 包类型（PT）：

8比特 包含常数200，用以识别这个为SR包。

 长度：

16比特 该RTCP包的长度减1。

其单位是32比特字，包括头和任何填充字节。

（偏移量1保证零值有效，避免了在扫描RTCP包长度时可能发生的无限循环，同时以32比特为单位避免了对以4为倍数的有效性检测。

） 

 SSRC：

32比特 SR包发送者的同步源标识符。

 第二部分，发送者信息，20字节长。

在每个发送者报告包中出现。

它概括了从此发送者发出的数据传输情况。

此域有以下意义：

 NTP时间戳：

64比特 指示了此报告发送时的背景时钟（wallclock）时刻，它可以与从其它接收者返回的接收报告块中的时间标志结合起来，计算往返每个接收者所花的时间。

接收