原来面对这些问题，除了网络层的优化外，协议层的优化也很重要，WebRTC中涉及相关的算法和标准的应用，理解和优化这些算法能力是很重要的！
代码语言：javascript复制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
代码语言：javascript复制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;
}
