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