webrtc rtcp发送间隔

RTCP介绍及发送间隔控制

1. 简述

RTP实时传输协议，广泛应用于流媒体传输应用场景, 根据RFC3550介绍，RTP协议应用场景有如下几种

  1. 简单多播音频会议（Simple Multicast Audio Conference）
  2. 音频和视频会议 （Audioand Video Conference）
  3. 混频器和转换器 （MixersandTranslators）
  4. 分层编码 （LayeredEncodings）

2. RFC3550中关于RTCP的介绍

2.1 基本场景介绍

RTP 控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。底层协议必须提供数据包和控制包的复用，例如用不同的 UDP 端口或相同的UDP端口（采用复用模式下）。

RTCP 提供以下四个功能：

2.1.1 基本功能是提供数据传输质量的反馈

这是 RTP 作为一种传输协议的主要作用，它与其他协议的流量和拥塞控制相关。反馈可能对自适应编码有直接作用，并且 IP 组播的实验表明它对于从接收端得到反馈信息以诊断传输故障也有决定性作用。向所有成员发送接收反馈可以使"观察员"评估这些问题是局部的还是全局的。利用类似多点广播的传输机制，可以使某些实体，诸如没有加入会议的网络业务观察员，接收到反馈信息并作为第三方监视员来诊断网络故障。

反馈功能通过 RTCP 发送者和接收者报告实现。

2.1.2 RTCP 为每个 RTP 源传输一个固定的识别符，称为规范名（CNAME）

由于当发生冲突或程序重启时 SSRC可能改变，接收者要用 CNAME 来跟踪每个成员。接收者还要用 CNAME 来关联一系列相关 RTP 会话中来自同一个成员的多个数据流，例如同步语音和图像。

2.1.3 2.1.1和2.1.2功能要求参与方都发送RTCP报文，为保证会议参与方增长，必须严格控制发送包速率，避免过多占用本端带宽，导致视频质量差

通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会议中所有成员的数目。此数目可以用来估计发包速率。

2.1.4 传输最少的会议控制信息

例如在用户接口中显示参与的成员。这最可能在"松散控制"的会议中起作用，在"松散控制"会议里，成员可以不经过资格控制和参数协商而加入或退出会议。

2.2 包格类型介绍

类型 类型简称 描述 RFC文档
192 FIR 关键帧重传请求（IDR帧，无需参考帧可解码） RFC2032
193 NACK 否定确认，NACK重传（丢包） RFC2032
194 SMPTETC SMPTE time-code 映射 RFC5484
195 IJ extended inter-arrival jitter report RFC5450
200 SR 发送者报告，描述作为活跃发送者成员的发送和接收统计数字 RFC3550
201 RR 接收者报告，描述非活跃发送者成员的接收统计数字 RFC3550
202 SDES 源描述项，其中包括规范名 CNAME。 RFC3550
203 BYE 表明参与者将结束会话。 RFC3550
204 APP 应用描述功能。 RFC3550
205 RTPFB(PLI/SLI/RPSI) 通用RTP反馈 RFC4585
206 PSFB 有效载荷比 RFC4585
207 XR RTCP扩展 RFC3611
208 AVB AVB RTCP数据包 IEEE1733
209 RSI 接收端汇总信息 RFC5760

其中各种类型报文均有用途，一般使用中各种类型有如下用途：

  • 关键帧请求（SLI／PLI／FIR）

PLI 是Picture LossIndication，SLI 是Slice Loss Indication 处理的是丢帧的情况， 但是FIR是正常情况，新成员加入。

  • 码率控制(REMB／TMMBR／TMMBN)
    TMMBR是Temporal Max MediaBitrate Request，表示临时最大码率请求
    REMB是ReceiverEstimatedMax Bitrate，接收端估计的最大码率。
    TMMBN是Temporal Max MediaBitrate Notification

  • 重传请求
    主要包括RTX／NACK／RPSI

2.3 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包同时发送，使大量参与者同时离开会话。

3. WebRtc中RTCP报文发送控制

bool RTCPSender::TimeToSendRTCPReport(bool sendKeyframeBeforeRTP) const {
  /*
      For audio we use a configurable interval (default: 5 seconds)                //对于音频，我们使用一个固定的5秒间隔。
                                                                                                            
      For video we use a configurable interval (default: 1 second) for a BW        //在带宽小于360 kbit/s时，视频使用1秒的时间间隔，在视频带宽低于10kbit/s时，表面上我们打破最大5% RTCP 带宽限制，但那应该是非常罕见的。
          smaller than 360 kbit/s, technicaly we break the max 5% RTCP BW for
          video below 10 kbit/s but that should be extremely rare


  From RFC 3550

      MAX RTCP BW is 5% if the session BW                                        //最大的RTCP带宽应是会会话带宽的5%，一个SR报文在包含CNAME时，大约是65个字节，一个RR报文大约为28字节。
          A send report is approximately 65 bytes inc CNAME
          A receiver report is approximately 28 bytes

      The RECOMMENDED value for the reduced minimum in seconds is 360            //最小发送间隔的值推荐为360/会话带宽，发送间隔单位为秒，带宽单位为kbps，这个最低在带宽大于72 kb / s时，这个最小值小于5秒。
        divided by the session bandwidth in kilobits/second.  This minimum
        is smaller than 5 seconds for bandwidths greater than 72 kb/s.

      If the participant has not yet sent an RTCP packet (the variable           //如果参与者尚未发送RTCP包（包已经初始化），则常量Tmin设置为2.5秒，否则设置为5秒。
        initial is true), the constant Tmin is set to half of the configured
        interval.

      The interval between RTCP packets is varied randomly over the              //RTCP包的发送间隔是在[ 0.5,1.5 ]倍计算值之间随机变化的，避免所有参与者同步出现的意外情况
        range [0.5,1.5] times the calculated interval to avoid unintended
        synchronization of all participants

      if we send                                                                  //如果我们需要发送报文
      If the participant is a sender (we_sent true), the constant C is            //参与者是发送者（we_sent为真），常数c设置为RTCP包大小平均值（avg_rtcp_size）除以RTCP带宽的25%（rtcp_bw），和常数n设置为发送方的个数。
        set to the average RTCP packet size (avg_rtcp_size) divided by 25%     
        of the RTCP bandwidth (rtcp_bw), and the constant n is set to the
        number of senders.

      if we receive only                                                         //如果我们只接收报文
        If we_sent is not true, the constant C is set                            //如果we_sent是不为真，常数c设置为RTCP包大小平均值（avg_rtcp_size）除以RTCP带宽的75%。
        to the average RTCP packet size divided by 75% of the RTCP               //常数n被设置为接收的方数（members - senders）。如果发件人 senders的数量大于25%，senders和members一起处理。
        bandwidth.  The constant n is set to the number of receivers
        (members - senders).  If the number of senders is greater than
        25%, senders and receivers are treated together.

      reconsideration NOT required for peer-to-peer
        "timer reconsideration" is                                              //“timer reconsideration”是使用的.该算法实现了一种简单的回退机制,会导致用户阻止RTCP包传输如果群体规模正在增加。
        employed.  This algorithm implements a simple back-off mechanism
        which causes users to hold back RTCP packet transmission if the
        group sizes are increasing.

        n = number of members
        C = avg_size/(rtcpBW/4)

     3. The deterministic calculated interval Td is set to max(Tmin, n*C).         //确定性计算区间Td设置为最大（Tmin，N×C）

     4. The calculated interval T is set to a number uniformly distributed          //计算出的区间t被设置为均匀分布在确定计算区间的0.5到1.5倍之间的数。
        between 0.5 and 1.5 times the deterministic calculated interval.

     5. The resulting value of T is divided by e-3/2=1.21828 to compensate           //由此产生的t值除以 e-3 / 2 = 1.21828，弥补了定时器复议算法收敛到一个值低于预期的平均RTCP带宽
        for the fact that the timer reconsideration algorithm converges to
        a value of the RTCP bandwidth below the intended average
  */

posted on 2023-11-23 15:25  WillingCPP  阅读(378)  评论(0)    收藏  举报

导航