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

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;
  }