WebRTC中使用的QOS相关的标准协议

原来面对这些问题,除了网络层的优化外,协议层的优化也很重要,WebRTC中涉及相关的算法和标准的应用,理解和优化这些算法能力是很重要的!

rtx : https://tools.ietf.org/html/rfc4588
red: https://tools.ietf.org/html/rfc2198
ulpfec:https://tools.ietf.org/html/rfc5109

之前调测WebRTC的UlpFEC能力,发现一些问题,记录下来:

问题1. 默认支持的音频codec type过多,出现主叫侧单方向音频类型的payload type和VP8 的payload 121冲突,会更新冲突VP8的payload type,但服务器转发被叫侧的payload type还是121,ulpfec使用red封装数据包,而被叫侧red包头的payload type依旧是121,服务器转发的时候没有做更新,导致主叫侧认为该payload type不合法,主叫侧不解码,出现听不到声音现象。

修改:主叫侧删除不需要的codec。

 

问题2. rtt越大时,ulpfec包生成越多,和正常使用场景不符,rtt越大,表示网络拥塞越严重,但这个时候根据rtt增大ulpfec冗余包的冗余比率,冗余包发的越多,rtt变得更长,网络卡顿更明显。

一旦rtt值大于80, 最小保护包的个数修改为4个,也就是4个rtp包1个fec冗余包,冗余比率达到20%。
constexpr size_t kMinMediaPackets = 4;
constexpr uint8_t kHighProtectionThreshold = 80;

//文件 Ulpfec_generator.cc

UlpfecGenerator::AddRtpPacketAndGenerateFec()方法中:
 if (complete_frame &&
      (num_protected_frames_ == params_.max_fec_frames ||
       (ExcessOverheadBelowMax() && MinimumMediaPacketsReached()))) {
    // We are not using Unequal Protection feature of the parity erasure code.
    constexpr int kNumImportantPackets = 0;
    constexpr bool kUseUnequalProtection = false;
    int ret = fec_->EncodeFec(media_packets_, params_.fec_rate,
                              kNumImportantPackets, kUseUnequalProtection,
                              params_.fec_mask_type, &generated_fec_packets_);
    if (generated_fec_packets_.empty()) {
      ResetState();
    }
    return ret;
  }


呱牛笔记

请先登录后发表评论
  • 最新评论
  • 总共0条评论