类似于webrtc这种基于IP网络实时通信中音质好坏受多方面因素的影响，一类为回声，噪声抑制等必须解决的问题，否则无法实现双向通话，另一类是网络丢包延迟等导致的音质变差。本文主要讨论第二类情况。
由于弱网引起的语音通话质量差通常是丢包，乱序，延迟等因素导致，针对这几种情况需要引入自适应 jitter buffer, PLC(丢包补偿)，FEC（丢包恢复），NACK（重传）技术。
1.jitter buffer
jitter buffer 自适应抖动缓冲是实时音频通信中处理乱序，延迟，平滑播放的基础，一个好的jiiter buffer实现会基于网络延迟抖动情况自适应缓存大小，能在网络环境好的情况下延迟降到最低，也能在网络情况差的情况下实现平滑播放，这部分已知的实现有speex 开源的jitter buffer，不过效果一般，webrtc里的neteq 是已知开源里实现最好的，可以参考，如果单独拿neteq出来使用还是有一定工作量，因为里面融合了解码，重传，red，dtmf等内容。
2.PLC
plc是在丢包无法恢复情况下的一种语音补偿技术，有的语音编码内置了plc，比如opus，在丢包情况下，如果没有fec包的情况下，调用opus解码器，传空数据即可产生plc补偿包。如果codec不支持plc，则需要通过plc算法实现，这部分在webrtc 的neteq里也有实现。
3.FEC
前项纠错技术在视频丢包恢复里用的比较多，包括in-band fec和outband fec, inband fec是指codec 内部支持的fec机制，silk, opus这种语音编码内置支持，不过opus的fec只支持前一个包的fec 恢复，实测 opus 的fec在 30%以内效果还好，如果丢包率更高，需要配合其他技术，下面会说。
ouband fec是指codec无关的算法，其基本原理是发送端对原始数据包进行 FEC 编码，生成冗余数据包，接收端收到后，通过冗余数据包和原始数据包来恢复出丢失或者出错的数据包。这种方式的好处是能根据丢包率调节冗余包个数，快速恢复丢失的数据包，不过由于要等待冗余包，则需要引入额外的延迟，实际应用当中需要动态实现fec冗余度的计算。
4.rfc 2198
这个是rfc 是RTP Payload for Redundant Audio Data，这个rfc 定义了当前语音包可用于承载前面的几个包的语音数据，这个设计的好处能处理大量丢包的情况，小鱼易联的方式采用了这种方式。
5.重传
NACK重传技术是接收端检测到丢包后请求发送端重发的机制，这种做法实际当中用的很少，重传需要多个RTT 时间才能收到丢失的包，引入了延迟，不适合实时通话。
6.重复发送
这是一种在丢包率高，带宽又够用情况下的一种粗暴方式，好处是能处理连续丢包情况，坏处是浪费额外带宽。
总结：实际当中需要上面多个方案的组合，在不同丢包率情况下用不同方法，实际当中，使用outband fec/rfc 2198 其一，再结合codec内置的fec 和plc可处理80%丢包率。