RTCP协议中发送时间间隔分析

RTCP协议中发送时间间隔分析

一 设计RTCP的原因 2

二 RTCP发送需要考虑的问题 2

三 对问题进行进一步的细化 3

四 问题的解决 4

五 算法验证 8

六 总结 8

七 参考 9

 

一 设计RTCP的原因

使用网络传输数据没有什么问题，只要通过一定的算法保证数据都能够正确到达即可。但是使用ip网络来传输音视频数据就有一些问题，ip网络是分组交换网络，同时也是虚电路网络，数据包在网络中传输时不可避免的存在丢包和延迟以及乱序的问题，所以从源发出的数据包经过ip到达目的网络后，有可能存在一些数据包丢失，序号不联系和乱序，不稳地的空闲期，集中到达或者延时到达，如果直接拿来进行播放，就可能存在丢帧，丢声音，马赛克，静帧等许多问题。为了对这些问题做出处理，设计了rtp协议来传输网络数据包，在rtp数据包中承载音视频数据的同时我们提供了时间戳和序号来解决丢包，乱序到达以及延时等问题。通过时间戳和序号，接收端可以对接收到的数据做些调整，在播放前。比如针对延时，可以对数据包进行缓冲，然后将它们按照时间戳的标记调整到合理的时间点进行播放；针对乱序和丢包，可以依据序号进行调整，这样播放端可以把数据调整为正确的顺序，跳过丢包的一段等等。

虽然接收端可以根据rtp协议对数据流做这些调整，但是进一步的处理缺乏，比如针对严重的丢包，发送端是否可以调整数据发送速率，比如换一种更低码率的编码方案来编码数据，这样数据就可以以更低的速率发送给接收端，主动减少网络流量，提高接收端的体验。这对转发器来讲是比较重要的，比如大家的接入都是高速网络，而部分用户是低速的串行链路，但是又要想让这部分用户能够进行音视频流的传输和接收，这时可在这部分用户入口安装一个转发器，来对编码进行转换。

要实现这个目的或者功能，我们就应该看到，发送端或者中间设备需要接收端提供反馈。这就是设计rtcp的一个重要原因。Rtcp是传输控制协议的简称，一般同rtp配合使用，提供实时流接收情况的反馈。其实除了上述转换器的功能外，rtcp也可以用于提供故障的诊断，可在网络中放置监视器，专门对rtcp数据流进行分析，提供网络状况的实时分析报告。还有一点，一般音视频流都是通过不同的rtp传输来进行的，比如一路音频流，一路视频流。但是我们知道，音频数据和视频数据的采样率是有比较大的差距的，而由前述的rtp时间戳的说明可以看出，这在接收端同步音视频流时也会出现问题，而rtcp可以解决这一点，这一点在rtcp同步rtp部分进行了比较详细的说明。这时可能有人就问，为啥不将这些信息添加到rtp协议中来实现了，为啥要单独设计一个新的协议。我个人的理解有两方面：一是整体考虑，类似与计算机中对不同问题进行分层的处理方式，每一层关注于一个比较重点的方面，就叫重点突出。这里所述的分层，既有垂直方面的意义，也有水平方面的含义。具体到这里，就是rtp重点关注音视频流的传输，rtcp重点关注视频传输情况的报告反馈。因此我们可以看到在rtp中使用了较少的字段达到了解决基本的音视频等实时流通过网络传输遇到的主要问题。Rtp包头主要就使用了12个字节，这样提高了负载的效率，整体的减少了包数，这在音视频流这种传输数据率很大的应用中作用还是比较突出的。如果这一点不具有说服力的话，那么可以看第二点：我们的反馈不必要每一个包都进行反馈，而应该是隔一段时间进行一次反馈，然后基于该反馈进行微调，这就像锯齿状的延展伸长。而且，在rtp传输中如果每次都反馈这些信息，一方面没有必要有这么高的精确度，另一方面同时对负载消耗却是个不小量，所以我们可以把它单独拿出来，单独设计，完全就是包含统计反馈信息，不含数据，在用户数比较少时包的大小也比较小，在用户数比较大时，又可以灵活做出应对。基于分层设计的考虑，rtp和rtcp的设计也都可以简化。

 

二 RTCP发送需要考虑的问题

由前面我们知道了rtcp是配合rtp用来传输反馈信息的。这些信息主要都是以报告包的形式进行发送。现在就有个问题，什么时候发送rtcp包？发送什么信息？先来看第一个问题，首先需要明确的一点是，rtcp包肯定在整个会话过程中都需要发送的，所以应该是周期性的发送，过一小点时间就发送一个，以对当前网络传输状况做出反馈。此时不得不考虑另一个问题，那就是rtcp包本身也是要占用网络带宽的，rtcp包的发送实质上是剥夺了一部分rtp带宽的，也就是说将传输数据的带宽分出一点来传输控制信息。所以rtcp的发送间隔就需要仔细考虑了，其实就是要达到一个平衡点，一方面要及时的反馈当前传输状况，一方面又不能过多的占用数据带宽，反而影响数据传输。如果占用过多的数据带宽，导致因为传输反馈信息而影响了数据传输，这实际是得不偿失的。（rtp与rtcp占用带宽的动态变化过程）。

对于发送什么信息，这里做个整理：

1 一是需要将同一个源的音频流和视频流关联起来。（这是在sdes包中进行描述的。为了能够同步这两个流，在rtcp的sdes包中设计了一个cname域，属于同一个源的音视频流虽然流的ssrc源描述符不同，但是CNAME是一样的，接收端可据此将具有相同cname的流关联起来。）

2 需要对时间戳进行一些处理，提供一个绝对的参考时间。（这通过SR中的rtp时间戳和ntp时间戳来实现）。

3 发送者发送数据的情况。（通过对累计发送的包数和字节数进行记录来表现）。

4 丢包率和累计丢包数目。（在接收报告包中表现）。

5 传输抖动。（抖动定义为数据包到达时刻统计方差的估计值。方差反映了一组随机变量的抖动这一数学特性。方差的计算式定义为随机变量与其数学期望的差值的和的平均值。在这里，我们将数据包到达的间隔值作为随机参量，这样，传输的最理想、最稳定形态就是这个参量值是一个常量。但是，网络传输的不稳定性决定了这个参量是随机变化的，因此就期望这个变化幅度越小越好，这样间隔值就显得比较均匀，传输的抖动性就较小。）

6 其他需要提供的。

 

三 对问题进行进一步的细化

实际上上面的第一个问题（关于什么时候发送rtcp包）是rtcp传输过程中主要要考虑的问题。单就rtcp传输来讲，基本原则应该是在不影响rtp数据传输的情况下及时的反馈传输信息。再进一步细化就是rtcp传输间隔的确定。以怎样的间隔发送rtcp包才能使得rtcp报告包能够及时的将反馈信息发送给所有的接收者和发送者，同时又不会占用过多的带宽？为了进一步确认这个问题所在，我们考虑哪些因素会使得rtcp影响到整个会话带宽？

1 发送间隔。如果发送间隔越小，那么同一时间段内发送的rtcp包就越多，理论上对带宽的消耗就越多。这与带宽消耗成反比。

2 发送rtcp包的用户数目。如果用户数目越多，同一时间段内发送的rtcp包就越多，理论上对带宽的消耗也就越多。这个量与带宽消耗成正比。

3 前面两点都是rtcp包的数目对带宽消耗的影响，也就是说同一时间段内rtcp包发送的数量会比较明显的影响到带宽消耗。如果同一段时间内rtcp包发送的数量一样，那么Rtcp包的大小就是影响带宽消耗的另一个重要因素。很明显，rtcp包越大，消耗的带宽就越多，这也是一个正比的量。

上面2和3两条是与带宽消耗的正比量，因此要减少带宽占用，就要减小这两个量，而1为反比量，则需要相应的增加。但是实际中，要考虑到rtcp的反馈是不是能最及时的反映当前的传输状况。所以rtcp的传输间隔是不能太大的，而传输内容是不能太少的，（在设计rtcp协议时，也是需要考虑如何用最少的字段，最少的信息量反馈有关rtp传输的最多的状况和信息。比如有些信息可以通过基本字段计算出来，这样可以减少冗余，降低包的平均大小）。仔细考虑，可以发现上述3条不是单独存在的：用户数增多，会使得rtcp报告中接收者数目增多，导致数据包变大；数据包增大，可能意味着一个ip包不能承载，需要分几次来传输，又间接过来影响到传输间隔。

 

四 问题的解决

为了解决上面的问题，我们构建一个数学模型来模拟这个问题，从而给出一个较好的解决方案。

首先我们用下图来表示网络的某一个时刻：

 

配图说明：

MCU为集中管理控制单元

1 2 3 4 为四个参与视频通话过程的用户

每一个用户端都会显示其他三个用户的视频画面。

右上角左侧图显示了2号用户向MCU发送流的示意图，它们被转发到了其他三个用户端。其右侧的图显示了MCU内部逻辑上存在的流的路数。对于N个用户，最大应该是N（N-1）。

 

为了便于描述问题，给出下面一些符号来表示上述环境中的特定量：

N 网络中的成员总数

S 网络中的发送者总数

R 网络中的接收者总数

T rtcp发送时间间隔

BW 网络带宽大小

这里，S小于等于N，R小于等于N，即可能所有成员都发送数据，同时都接收数据，这时网络处于满载状况（这里所说的满载状况是指网络中可能达到的最大数据发送量。当所有的成员都发送和接收数据时，此时该网络的承载最大。）

BW表示当前网络中分配给实时流的传输带宽，这是一个总的带宽，rtp和rtcp就从这个带宽中来分配各自的带宽。

 

在这个模型中我们来看rtcp发送时需要考虑的3个问题。

1，发送间隔，这个完全可以由用户端来控制，也就是成员来控制。这个间隔不能太短，否则rtcp数据包太多可能导致网络阻塞。

2，发送rtcp包的用户数目，用户可能是不断加入和离开的，不能随便对用户数目进行限制，（比如只能允许有多少个用户加入会话），否则设计意义将不再。

3，数据包的大小，这个在一定程度上是由成员数目决定的，也就是说为多个成员发送报告包将导致rtcp包的大小明显增加。本质上来讲，这个量也是不能限制的，但是可以做些控制调整。（比如将对所有成员的报告分几次发送，每次只发送给其中的一部分成员）

所以来看，只有传输间隔才是可控的最重要的因素。但是要看到另一点，就是传输间隔是跟成员数目，包大小有一定关联的，所以2和3控制因素在一定程度上也会作用到间隔因素1上。综合来看，1因素就相当于这些作用的综合表现，包括自身。当所有这些因素作用于系统中时，最终控制系统平衡的杠杆转换到了传输间隔这个因素上，这就是说传输间隔这个因素成了整个系统平衡的控制点。这使得间隔因素的选择变的复杂化了。

 

通过上面的描述，任务就比较明确了。就是我们要通过上面的数学模型设计一个算法，通过这个算法得到一个rtcp传输间隔值。（这个间隔值是经过优化的rtcp传输间隔）而且这个传输间隔应该有下面的特性：

1 随着成员人数的增加，传输间隔相应的应该减少，以减少网络阻塞压力。

2 如果成员人数突然增加，上述算法应该避免用户在同一时间发送（比如相同的rtcp间隔后）rtcp报告包，因为这可能导致网络阻塞。人数突然增加是指短时间内大量用户加入会话。

3 如果成员短时间内离开会话，也就是说成员人数突然减少，算法应该避免用户在同一时间或者短时间内发送大量的rtcp bye包，因为这也可能导致网络阻塞。

4 传输时间间隔还应该避免成员意外的同步（就是即使用户数目不多，但是大家却都在同一时刻发送rtcp报告包）。理想状态应该是网络中的rtcp包均匀发送，而非集中在某个时间段。

另外，时间间隔的估算过程中，rtcp复合包的大小应该被动态的重新估计，以适应需要携带控制信息数量的变化。

 

为了实现这个算法，我们对问题进一步的明确。基于上述数学模型，我们已经得到了输出，就是传输间隔，现在我们将整个模型看做一个黑匣子，来看输入因素。

1 系统当前的成员数目N

2 发送者和接收者数目S和 R

3 用于rtp和rtcp传输的带宽BW

4其他因素

 

为了便于后续的分析，我们假设网络带宽是固定的，实际中可能随着使用状况不同，网络中分配给rtp的带宽会有一些变化，但这不影响我们这里对问题的分析。用户可以将当前的网络带宽值作为一个参数输入模型，同样会得到修正后的传输间隔。

 

同样为了便于分析，以及进一步的进行算法设计，我们添加如下一些约束条件：（关于约束条件中选择的值，其依据是什么？经验值？）

1 rtcp的流量应当限制为不超过会话带宽的5%，即BW的5%分配给rtcp。

2 rtcp带宽的75%分配给接收者，25%分配给发送者

3 接收者平均使用分配给其的75%带宽

这是三条Rtcp速率的限制规则

4 初始的传输间隔设计为5秒，后面记为Ti

5 rtcp复合包的平均大小，记为avg

 

基于上述约束条件，我们来计算一下时间间隔T：

以K表示会话某一计算时刻的带宽（实际上K=BW），则发送者和接收者使用带宽的情况如下：

T(发送者) = (S)/(25% * 5% * K) * avg(rtcp packet size)

T(接收者) = (R)/(75% * 5% * K) * avg(rtcp packet size)

也就是每个成员占用的带宽乘以平均包大小即为该成员发送报告包所需的时间，这就是我们之前提出的T，模型的输出。

 

这只是根据约束条件简单计算出的一个值，还不足以应对复杂的网络环境，就连所应该具有的基本特性也不满足，所以需要进行进一步的优化、限制（约束）和调整。为此，我们对会话参与者额外保存如下一些变量，来对模型输入条件做进一步限制。（细化，具体化）

1 Tp：最近一次发送rtcp包的时间。（就是上一次发送rtcp包的时间）

2 tc：当前的时间

3 tn：下一次调度时rtcp包传送的时间，就是下一个rtcp应该发送的时间，是个预估的时间值。

4 pmembers：tn最后一次（就是最近一次）被重新计算时估计的会话成员人数。

5 members：关于会话成员人数的当前估计。

6 senders：当前估计的发送者人数。

7 rtcp_bw：rtcp目标带宽，就是被rtcp所使用的全部带宽，以字节每秒计。这是会话带宽的一部分，5%。

8 we_sent：是一个标识，如果在之前的两个rtcp报告被发送的间隔内有数据发送，则设置为true。

9 avg_rtcp_size：rtcp复合包的平均大小，以字节计。包括发送和接收的，也包括包的底层数据头，比如udp头和ip头。

10 initial：是一个标记，如果应用还没有发送rtcp报告包，则设置为true。

（这部分摘自rtcp协议文档，其中成员数，发送者数和带宽在之前已经提及，以N,S,BW表示。）

 

基于上述新的输入条件，我们对约束条件也作出进一步的限制，并描述整个算法：

1 如果发送者小于等于会话总人数的25%，则T还进一步决定于参与者是否发送了数据。如果we_sent为true，则c=avg_rtcp_size/(0.25*rtcp_bw),n=senders；否则，c=avg_rtcp_size/(0.75*rtcp_bw),n=(members- senders)；如果发送者人数不大于会话总人数的25%，那么c=avg_rtcp_size/rtcp_bw,n=members。

2 如果initial 为true，则Ti=2.5s，否则Ti=5s。

3计算时间间隔Td=max(Ti, n*c);

4 T=Td*λ，其中λ服从0.5到1.5之间的均匀分布。这是为了避免意外同步。

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

通过上述约束条件和计算，我们产生了一个随机的计算时间间隔，并把至少25%的rtcp带宽分配给发送者，其余分配给接收者，如果发送者超过25%，则带宽平均分配给所有参与者。

 

通过上面的算法产生的时间间隔已初步具有了我们之前描述的一些特性，下面结合发送和接收数据包，对算法进行细化，描述算法的所有行为。

1 初始化。初始加入会话时，各个状态参量的值为：tp=0, tc=0, senders=0, pmembers=1, members=1, we_sent=false, rtcp_bw由参数得到，initial=true, avg_rtcp_size为应用稍后发送rtcp包的可能大小，T为上面计算的值，tn=T。

 

2 接收到rtcp报告包。若其ssrc不在成员列表中，则将其加入成员列表中，并将members加1。每收到一个rtcp复合包，avg_rtcp_size更新为：1/16 * packet_size + 15/16 * avg_rtcp_size，其中packet_size是刚收到的rtcp复合包的大小。

 

3 接收到rtp包。若其ssrc不在成员列表中，则将其加入成员列表中，并将members加1。如果当前发送者是新的发送者，则将其加入发送者列表中，并将senders加1。

 

4 接收到rtcp bye包。如果收到一个rtcp bye包，则检测成员列表，如果ssrc存在，则移除，并更新成员变量，比如如果是sender，则senders减1，成员数members减1。为使rtcp的发送速率和组中的人数变化更加协调，当members<pmembers时需执行下面的逆向重估算法：

tn = tc + (((double) *members)/(*pmembers))*(tn - tc);

tp = tc - (((double) *members)/(*pmembers))*(tc - *tp);

下一个rtcp包将使用更新后的tn，在tn发送，这比更新前要更早一些。

Pmembers = members，即pmembers更新为members。

avg_rtcp_size更新为：1/16 * packet_size + 15/16 * avg_rtcp_size，其中packet_size是刚收到的rtcp复合包的大小。

 

5 ssrc超时。在随机时间间隔中（等待发送rtcp报告包的期间？），一个参与者必须检测其他参与者是否已经超时。为此，对接收者（we_sent 为false），要计算决定性时间间隔Td，如果从时刻Tc-M*Td(M 为超时因子，默认为5 秒)开始，未发送过RTP或RTCP 包，则超时。其SSRC 将被从列表中移除，成员被更新。在发送者列表中也要进行类似的检测。发送者列表中，任何从时间tc-2T(在最后两个RTCP 报告时间间隔内)未发送RTP 包的发送者，其SSRC 从发送者列表中移除，列表更新。

如果有成员超时，应该执行5条描述的逆向检测算法。

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

 

6 发送时钟到。当包传输的发送时钟到时，执行下列操作：

首先按之前的算法计算T。

如果tc<= tp+T,tn=tp+T,pmembers=members;

否则，发送rtcp包，tp=tc,tn=tc+T,initial=false。

avg_rtcp_size更新为：1/16 * packet_size + 15/16 * avg_rtcp_size，其中packet_size是刚收到的rtcp复合包的大小。

 

7 发送bye包。当一个参与者离开会话时，应该发送bye包通知其他参与者。为避免大量参与者同时离开会话，导致大量的bye包发送，如果会话人数超过50，则参与者离开会话时，应该执行下面的算法：

当参与者决定离开系统时，tp复位为tc，members和pmembers初始化为1，initial设置为1，we_sent设置为false，senders设置为0，avg_rtcp_size设置为将要发送的bye复合包的大小。计算传输间隔T，该bye包将于调度时间tn发送，tn=tc+T。

每当接收到来自其他参与者的bye包时，members增加1，而不管那个参与者是否存在于成员列表。当接收到其他rtcp或者rtp包时members不增加，除非是bye包。类似的，avg_rtcp_size也仅仅在接收到bye包时进行重新预估。当其他rtp包达到时，Senders也不进行更新，而保持为0。

在此基础上，bye包的传输服从上面规定的一般rtcp包的传输规则。（bye包的传输，是专注于统计会话中发送bye包的人数的。上述行为规则以参与者要离开会话为基础，统计量的新的变化规则是在该参与者等待发送bye包的期间执行的。）

这允许bye包被立即发送，并控制总的带宽使用。在最坏的情况下，这可能使rtcp控制包使用两倍于正常水平的带宽，5%给非bye类型的rtcp包，5%给bye包。

一个参与者若不想使用上面的机制进行bye包的发送，可以直接离开会话，他会被其他参与者因为超市而删除。

如果组人数少于50，参与者可以直接发送bye并离开会话。

不论是那种情况，一个从未发送过rtp或者rtcp的参与者离开时，不能发送bye包。

 

8 we_sent的更新。当参与者最近发送过rtp包时，该变量被设置为true，否则为false。这种相同的机制可以用来管理发送者列表中的其他参与者。如果参与者发送了rtp包，其we_sent是false，则添加自己到发送者列表中，并设置we_sent为true。之前的逆向重估算法应当被执行，来减少发送SR报告包的延时。每当发送一个rtp包时，其相应的传输时间都会记录到表中。正常的发送者超时算法被应用到参与者：如果从tc—2T时间内还没有一个rtp包被发送，参与者将自己从发送者列表中移除，并减少发送者计数，设置we_sent为false。

 

通过上面的行为分析，可以看出实际上我们并不是只使用了一个单一的算法来解决这个问题，而是几个算法来完成之前提出的所要达到的目标。

 

五 算法验证

 

六 总结

通过上面的描述，我们完成了从问题的分析到解决方案的提出再到算法的验证的整个过程。

Rtcp包的发送间隔问题主要是用来分配带宽的。也就是算法设计的目的。一方面我们要不断的周期性的发送报告包，以提供对当前网络流传输情况的监测，并根据丢包情况对传输做出调整，另外一方面，要保证报告包能够不断的发送出，但是不能影响rtp本身流的传输，也就是要限制rtcp报告包占用带宽的情况。此时我们就要根据当前会话的情况（成员的加入和离开）以及带宽使用情况对rtcp报告包的发送间隔做出动态的调整，已达到上述两个目的。通过上面的建模和算法设计，我们初步达到了这一目的。

 

七 参考

RFC 3550 - RTP: A Transport Protocol for Real-Time Applications