冗余程度 <-> 丢包率
FEC编码产生冗余包过程 发送RTP包过程
接收解码，以及FEC恢复丢失包过程
https://www.cnblogs.com/x_wukong/p/7841012.html
https://www.cnblogs.com/talkaudiodev/p/8053062.html
3，PLC
PLC也主要针对丢包因素。它本质上是一种信号处理方法，利用前面收到的一个或者几个包来近似的产生出当前丢的包。产生补偿包的技术有很多种，比如基音波形复制（G711 Appendix A PLC用的就是这种技术）、波形相似叠加技术（WSOLA）、基音同步叠加（PSOLA）技术等，这些都很专业，有兴趣可以找相关的文章看看。对codec而言，如果支持PLC功能，如G729，就不需要再在外部加PLC功能了，只需要对codec做相应的配置，让它的PLC功能使能。如果不支持PLC功能，如G711，就需要在外部实现PLC。
PLC对小的丢包率（< 15%）有比较好的效果，大的丢包率效果就不好了，尤其是连续丢包，第一个丢的包补偿效果还不错，越到后面丢的包效果越差。
把Jitter Buffer、FEC、PLC结合起来就可以得到如下的接收侧针对网络环境因素的提高音质方案：
从网络收到的RTP包如是原始包不仅要PUT进JB，还要PUT进FEC。如是冗余包则只PUT进FEC，在FEC中如果一组包中原始包的个数加上冗余包的个数达到指定值就开始做FEC解码得到丢失的原始包，并把那些丢失的原始包PUT进JB。在需要的时候把语音帧从JB中GET出解码并有可能做PLC。
4，重传
重传也主要针对丢包这种因素，把丢掉的包再重新传给对方，一般都是采用按需重传的方法。我在用重传的方法时是这样做的：接收方把收到的包排好序后放在buffer里，如果收到RTP包头中的sequence number能被5整除（即模5），就统计一下这个包前面未被播放的包有哪些没收到（即buffer里相应位置为空）， 采用比特位的方式记录下来（当前能被5整除的包的前一个包用比特位0表示，丢包置1，不丢包置0，比特位共16位（short型），所以最多可以看到前16个包是否有丢包），然后组成一个控制包（控制包的payload有两方面信息：当前能被5整除的包的sequence number（short型）以及上面组成的16位的比特位）发给对方，让对方重发这些包。接收方收到这个控制包后就能解析出哪些包丢了，然后重传这些包。在控制包的payload里面也可以把每个丢了的包的sequence number发给对方，这里用比特位主要是减小payload大小，省流量。
在实际使用中重传起的效果不大，主要是因为经常重传包来的太迟，已经错过了播放窗口而只能主动丢弃了。它是这些方法中效果最差的一个。
5，RFC2198
RFC2198是RTP Payload for Redundant Audio Data（用于冗余音频数据的RTP负载格式），用了它后在当前RTP包中不仅可以承载当前语音的payload，还可以承载前几个包的payload，承载以前包的个数越多，在高丢包率的情况下效果越好，但是延时也就越大，同时消耗的流量也就越多。相比于FEC，它消耗的流量更多，因为FEC用一组RTP包编码生一个或多个成冗余包，而它一个RTP包就带一个或多个以前包的payload。在有线网络或者WIFI下可以用，在蜂窝网络下建议慎用。
以上就是我用过的提高音质的方法。还有其他方法，我没实践过，就不写了，写出来也是纸上谈兵。欢迎大家补充其他的方法。