類似於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%丟包率。