?2020年新冠疫情持續蔓延全球，億萬人的生活因此發生了巨大的改變，人們對實時音視頻通話的日常需求也越來越大。作為BIGO公司旗下重要的全球性即時通訊產品imo為全球2億多用戶提供優質穩定的即時通訊服務，在2020年上半年全網通話時長提升30%以上，開齋節（穆斯林節日）更是提升50%以上。是什么技術力量支撐讓imo能夠適應全球各式各樣的網絡環境和用戶類型，在各類競品中脫穎而出，為imo全球化的戰略保駕護航，乘風破浪，迎難而上的呢？接下來我們就結合imo的語音傳輸業務和大家探討一下。

?

一、imo實時語音業務背景和面臨挑戰

?

眾所周知當前的絕大部分手機即時通訊產品都是基于VoIP技術。基于IP網絡的VoIP技術，我們公認在網絡架構存在著挑戰。因為VoIP一般走的都是公共網絡,網絡環境不穩定，會面臨丟包、延時以及語音包抖動等問題，所以基于IP的通話是沒有質量保障的。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖1 ?VOIP系統示意圖

?

業界上使用QoE/QoS的模型來介紹和分析這樣的問題。

QoE（Quality of Experience）的評價主體是終端用戶，評價對象是業務和支撐業務的網絡。其設計理念是為了更貼近用戶的真實感受，主要是用來衡量用戶的主觀體驗，例如通話過程發生頻繁卡頓，有多少用戶會因為無法忍受而選擇結束通話。

與之對應，QoS（Quality of Services）主要反映的是客觀指標，如一次通話過程中發生了多少次網絡卡頓或者丟包。其更專注于純網絡范疇的指標，設計理念主要負責從網絡的角度進行業務管理和提供業務的差異性，網絡實體根據不同的質量需求來處理不同業務。終端+整條網絡鏈路的一系列服務需求，例如帶寬，延時，抖動，丟包這些都反應著服務質量QoS。

不難看出，服務質量QoS的優劣與否很大程度上影響著用戶體驗質量QoE，并最終反映在用戶對產品的喜愛和依賴程度等主觀感受上。因此為了更好的讓用戶獲得清晰流暢的用戶體驗，我們imo音視頻傳輸團隊需要盡可能的提升QoS保證服務質量。

而要想提供優質和穩定實時服務，保證服務質量不是一件容易的事情。因為不同于許多國內同類型的其他產品，作為一個全球性的實時音視頻通訊產品，imo面對著更多復雜的挑戰。首當其沖的就是復雜多樣的網絡。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖2 ?imo全網用戶和東南亞某新興市場用戶網絡比例圖

?

imo用戶的一大特點就是遍布全球各地，網絡環境豐富動態差異大，有較好的4G/WIFI網絡，但更多地方特別是近年來用戶增長率高的一些新興市場主要是3G/2G的弱網環境為主。和中國地區4g網絡覆蓋比例達95%以上相比，imo用戶接入網絡相對較為落后。從上圖可以看到全網imo用戶接入網絡占比中，4G網絡比例只占了39%，2G/3G占了29%，而以東南亞某新興市場為例，其imo用戶接入網絡占比中2G+3G的用戶比例占比高達49%。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖3 ?中東與南亞兩個主要市場國內國際電話比例圖

?

imo用戶的另一大特點就是對跨國甚至跨洲際的通話有著極大的需求。

據imo線上數據統計，以中東和南亞的兩個主要市場為例，某中東市場imo用戶的國際電話比例占到總通話次數的60%，而某南亞主要市場imo用戶的國際電話次數比例則高達69%。這樣的國際通話就涉及到更復雜多變的媒體服務中轉和較長的傳輸鏈路。這會導致用戶之間的網絡鏈路較長，使得抖動甚至擁塞突發不可避免。要想在這樣的背景下提供優質穩定的QoS可謂困難重重。

因此我們imo音視頻傳輸團隊圍繞QoS深耕服務，著重設計強化了相關需求模塊，同時針對imo的特殊情況我們也做了許多差異化的服務來應對挑戰。接下來我們就先來了解一下imo語音傳輸技術體系是如何在這樣的網絡環境下提供穩定優質服務的。

?

二、基于QoS的imo語音傳輸技術體系

?

01? 用戶接入

imo通過一系列的措施保障用戶無論何時都享受各種網絡的高可用性

1、通過實時探測計算整體用戶網絡，計算分配最合適的接入節點

隨機挑選少量空閑用戶，通過對用戶到不同節點到小流量的探測，判斷當用戶到節點的網絡狀況，并將探測結果上報到后臺，后臺通過結合客戶端探測結果和各個節點的負載情況，匯總分析出用戶最合適的接入節點，當相同運營商用戶通話時，將實時計算出來的最優節點分配給用戶

2、使用多Relay(中轉服務器)轉發保證跨國用戶通話網絡質量

通過使用計算出來的最優節點解決的是用戶第一公里和最后一公里的接入問題，當用戶進行跨國通話的時候通過多條relay轉發保證用戶通話長鏈路質量的最優

3、通過多協議轉換，保障高可用性

imo通話支持UDP，TCP， HTTP等多種協議，并且數據格式靈活多變，通過不同協議間切換，保障用戶在各個網絡情況下的高可用性。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖4? imo通話各個協議占比

?

如圖4所示，可以看到imo通話中有超過10%的通話使用的不是傳統的UDP協議，通過后臺的配置，將部分用戶配置成TCP或者HTTP，以保證用戶的通話可用性，提高通話接通率。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖5 ?北美和中東用戶通話接入示例圖

?

如圖5所示：北美用戶和中東用戶進行國際通話，通過分別接入倫敦服務器和阿姆斯特丹服務器保證用戶接入最優節點，兩個服務器再進行中轉，以保證整個鏈路的高可用性。

?

02??流量控制模塊

帶寬自適應是指在語音的收發過程中，根據網絡帶寬的變化，自動的來調整發送碼率，來適應帶寬的變化。在帶寬足夠的情況下，增加采樣率和碼率，提高語音的質量，帶來更好的通信體驗。在帶寬不足的情況下，主動降低采樣率和碼率，保證通信的流暢性和可用性，也是帶來更好的通信體驗。帶寬自適應的核心，就是如何準確的估計帶寬。

imo使用了基于接收端的丟包率和延時反饋的帶寬估計算法，同時引入pacer，pacer會根據評估出來的碼率，按照最小單位時間（5ms）做時間分片進行遞進發送數據，避免瞬時對網絡的沖擊。pacer的目的就是讓媒體數據按照評估碼率均勻的分布在各個時間片里發送， 所以在弱網環境，pacer是個非常重要的關鍵步驟。

imo的自適應碼率方案，收集全部模塊的輸出流量按優先級分配，根據帶寬估計反饋的丟包率和延時，決定ARQ和FEC的使用策略。采用冗余包進行上探，碼率穩定后再提升源碼率。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖6 碼率自適應示意圖

?

1、Receiver接收到報文，計算進行到達時間統計和丟包統計

2、Detect根據收端的延遲增量和丟包率信息計算出網絡擁塞狀態, 評估出適合當前網絡傳輸的碼率，并通過feedback反饋到發端

3、收到反饋碼率，pacer會根據這個碼率改變pacer的網絡發送速度，流量控制模塊根據反饋信息，決定是否需要上探或者下調，調整ARQ&FEC的使用策略

4、sender收到pacer的發送事件，開始新一輪的碼率評估流程

?

03??抗丟包模塊

音頻實時通信對信息要求確保盡可能完整恢復信息的同時，盡量降低延時，而且要避免擁塞。業界有多種策略可以解決丟包問題，一般包括：自動重傳請求ARQ、前向糾錯FEC、HARQ(Hybric ARQ)等。

?

▼ 分段和透傳的靈活調度

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 7 分段與透傳FEC示意圖

?

在1v1通話中，需要考慮的一個問題是 server 采用分段還是透傳的方式做FEC。兩種方式各有優缺點。恢復的方式相對直接透傳冗余包的方式，雖然會增加server對RS包的編解碼消耗和編碼時延，但是可以避免丟包率小一側鏈路的冗余流量，因為主被叫兩段鏈路的丟包率往往是不同的。此外，分段恢復的方式也容易擴展到群語音。imo通話中，我們靈活調度這2種方法，對于對流量較為敏感，或者RTT較大的通話，選擇分段恢復的方式；對于流量不太敏感，或者RTT較小的通話，選擇透傳的方式。

?

▼?冗余表

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖8 FEC 控制模型 ? ? 黑線數據流，紅線控制流

?

在FEC的控制中，冗余表扮演一個非常重要的角色，決定了冗余是否高效，在恢復丟包的同時不引入過多冗余。在imo中，我們根據下面的方法計算冗余表。

假設 n 個原始包編 k 個冗余包，每個包的丟包率為p，那么收到 i 個包的概率為：

在收到 i 個包的條件下，原始包個數為 j，那么恢復后的原始包個數期望值為：

如果希望恢復后的丟包率小于某個丟包率，例如1%，那么，對方程求解，就可以得到特定 (n, k) 下可抵抗鏈路丟包率的最大值。

選擇不同的 n 和 k，可以求解得到如下表，如果選定n=5，鏈路丟包率在[4.7%, 9.6%)區間，那么使用 5+2 的冗余，可以使得恢復后的數據丟包率小于1%。下面，我們稱恢復后的數據丟包率為容忍丟包率。

根據這個計算方法，我們可以畫出組包個數 n=5 的容忍丟包率對應的鏈路丟包率率切換閾值曲線。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖 9? n = 5時，容忍丟包率與鏈路丟包切換閾值的關系

?

從上表和圖9，我們可以發現幾個特點：

1、如果控制容忍丟包率趨向0，那么鏈路丟包率切換的曲線也趨向0。

意味著需要增加越來越多的冗余流量，才可以使容忍丟包率控制在一個很小的值，性價比越來越低，以0%為容忍丟包率是不現實的。

2、在不同的容忍丟包率要求下，FEC覆蓋的丟包率范圍不同。

例如，設置1%的容忍丟包率下，只能覆蓋到24.5%的鏈路丟包率。

3、同樣的容忍丟包率和冗余率，組包數n越大，覆蓋的丟包率范圍越大。

例如，同樣在1%的容忍丟包率要求下，n = 1 時，1+1的冗余只能覆蓋到10%的鏈路丟包率；而 n =5 時，5+5 能覆蓋 24.5%的丟包率。

在此基礎上，根據連續丟包個數和容忍的最大延時，選擇不同的分組組合，理論上可以達到高效利用帶寬的目標。真實場景的丟包率并不是恒定的，丟包率的統計、連續丟包數和RS編碼改變冗余有滯后性；因此需要考慮運行中的動態性，適當增加冗余，才可以達到較好的效果。

?

▼?動態冗余率的收斂速度

冗余率的收斂速度是影響恢復效果的。我們發現開啟FEC的丟包率閾值附近，存在頻繁啟停與冗余率切換的問題，這個問題不僅使恢復率大大降低，而且浪費了冗余流量。針對這個問題，我們采用了滯回的策略：在不擁塞前提下，冗余率至少保持一段時間不下降。如下圖9所示，冗余率頻繁切換過程中，丟包不能得到及時恢復，在增加滯回后，恢復效果明顯變好。

?

圖10?

左：頻繁調整? ??

右：滯回 ? 紅線代表丟包率，黑線代表冗余率 ?特定場景下恢復后丟包率從7.35%下降到1.14%

?

▼?HARQ

針對ARQ與FEC兩種抗丟包方法的特點，我們采用了揚長避短的策略，盡可能發揮各自的優勢，這就是HARQ(Hybric ARQ)。整體思路是，HARQ在RTT較小的網絡中，主要采用重傳策略，減少冗余流量；在RTT較大的場景中，主要使用FEC，降低恢復延時。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖11 HARQ策略轉換圖

?

難點一：切換閾值確定

HARQ一個難點是不同策略的切換閾值如何確定，rtt/丟包率的閾值設定小了會浪費流量，閾值設定大了恢復率可能達不到預期。

我們的方法是以恢復率為目標做自動調整：

1、根據當前rtt和鏈路丟包率，先計算ARQ在最大引入延時下的理論恢復率

（1）如果srtt大于設定的ARQ最大引入延時，則關閉ARQ。

（2）如果ARQ恢復率滿足設定目標，則只開啟ARQ。

（3）如果ARQ恢復率不能滿足設定目標，則剔除ARQ恢復后的丟包率作為輸入，計算并調整FEC的冗余度。

2、理論計算和實際情況會有偏差，為了矯正這個偏差，接收端反饋丟包恢復情況給發送端，發送端根據反饋的恢復率和目標恢復率比較，如果偏小則對應調大冗余。

?

難點二：擁塞避免

不管是ARQ還是FEC，都需要增加額外的流量來實現抗丟包。然而在擁塞場景，這種額外的流量反而會惡化網絡，使丟包率變大；這時如果抗丟包模塊不對這種情況做區分發送更多額外流量，只會使得網絡更差。

我們在剛上線HARQ的時候，就碰到了這樣的問題。從AB實驗數據中，我們發現部分的case的恢復率較低，一小段時間出現丟包率特別高、rtt增大明顯的情況，可以推測發生了擁塞。為此，我們在抗丟包模塊增加了基于rtt梯度變化來做擁塞判斷邏輯。在srtt大于一定閾值，認為可能存在，這時計算梯度變化，變化大則認為擁塞，從而調整抗丟包冗余。另外，我們也設計增加BWE做更精確的擁塞判斷，這個工作也正在進行之中。

下圖12是東南亞某市場增加擁塞判斷邏輯前后線上數據對比，在丟包恢復率相當的前提下，優化后rtt從增量100ms到變化不大，擁塞現象減少：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖12 增加擁塞判斷邏輯前后線上數據對比

?

下圖13是不同場景下HARQ和ARQ+FEC各自處理的效果對比，可以看到，限速場景HARQ恢復率提升明顯，減少擁塞發生提升了恢復率；另外引入流量降低明顯，HARQ統一決策有效降低無效流量。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖13 不同場景下恢復率和引入流量

?

▼?抗丟包整體效果

丟包場景下，抗丟包模塊明顯提升了mos，丟包率40%以下mos分能保持在4分以上，音質平穩度較高，有效地提升了用戶體驗。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖14 ?無抗丟包版本mos分測試?

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖15 抗丟包版本mos分測試

?

▼?運營挑戰和思路

在運營中，因為很多數據是基于整個通話來統計，但是在實際問題和排查中，難以定位具體的原因。例如，在一個30分鐘的通話中，前28分鐘的通話質量非常好，最后2分鐘因為通話卡頓或者聽不到聲音而掛斷電話。在這樣的場景下，分析整個通話的播放丟包、網絡丟包情況，丟包率并不高，難以定位到用戶發生了什么問題。為了解決這個痛點，我們設計了trace運營思路：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖16 ?抗丟包trace運營流程圖

?

通過trace抽樣上報，我們達到了全鏈路包級別數據可泛化，這樣讓我們對于問題收集和分類更加充分和完備。對線上具體bad case分析，以此推動了抗丟包模塊的不斷優化迭代；同時，對線上用戶的痛點了解更加深刻，對如果評價抗丟包效果有更多思考。

?

04??抗抖動模式

抗抖動的基本思路是用適當的延時來換取卡頓率的下降并在二者之間達到最優的播放體驗，業界常見的抗抖動算法有基于自回歸(AR)估算算法，基于統計(Statistically)的算法和基于自適應濾波（Adaptive Filter）的算法。

基于自回歸估算的算法，輸入的是單向延時，經過自回歸估算得出播放延時。實現上可在talkspurt之間調整延時（需要靜音信息），或talkspurt期間調整延時（需要引入TSM，變速器），甚或引入Spike檢測，可以適應網絡擁塞引入的突發抖動，快速響應網絡變化。

基于統計的算法，以過去一段時間收包的網絡延時做直方圖統計，取一定概率總和所對應的延時值作為網絡抖動的估計，難點在于過去一段時間長短的取舍，取得太長，最近網絡變化會被平均，取得太短，估值起伏隨網絡變化太快，也就失去了統計的意義，經典的實現代表是webrtc neteq，使用遺忘算法對每種遲包概率進行動態調整，結合峰值檢測得到較好的網絡抖動估值，在此就不作詳解。

基于自適應濾波器的算法沒有對網絡延時做出反應，而是嘗試預測網絡延時。自適應濾波算法旨在最小化實際網絡延時和估計之間的期望均方誤差。先前的延時通過有限脈沖響應（FIR）濾波器傳遞，以計算當前估算值。然后，將均方誤差用于調整自適應濾波器的抽頭權重。經典實現有歸一化最小均方算法（NLMS）。

imo用戶分布全球，通話類型也以跨國通話為主，為適應這種網絡鏈路引入的抖動，我們引入并優化了業界多種抗抖動算法，經過比較，最終Bigojitter勝出。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖17 ?BigoJitter原理架構和網絡抖動估算示意圖

?

如上圖17所示，Bigojitter主體包括語音包緩沖區，網絡抖動估算，播放延時估算，播放決策，解碼器，變速器，解碼數據緩沖區等模塊，核心算法在于網絡抖動估算，播放延時估算以及播放策略，Bigojitter使用歷史抖動范圍和自回歸算法來估算播放延時，從而可以快速適應網絡的抖動變化。

Bigojitter的優化主要分為兩個階段：第一階段是在實驗室構造各種弱網場景，使MOS分和延時都能達到最佳狀態。由圖17可見，MOS分在各個場景平穩下降，延時和網絡抖動符合線性關系。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖18 ?BigoJitter實驗室優化效果示意圖

?

雖然Bigojitter優化在實驗室測得較好成績，但上線運營符合預期才是關鍵。借助強大的ab實驗系統，可分析不同版本各個維度參數的變化趨勢，甚至提取trace數據進行研究，我們發現imo用戶在某些地區和通話場景下，網絡擁塞和超大抖動是不可避免的。在這種情況下，jitter基于實時通信的要求觸發了主動丟包降低延時，導致信號完整性問題。于是我們及時調整了策略，增加jitter自適應范圍的上限，用適當的延時來換取遲包丟包率和播放丟包率的下降，事實證明，這個優化使得ab結果從一直負向轉向顯著正向，最終達到技術優化和業務增長雙贏的目標。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖19 Bigojitter迭代優化過程：遲包丟包率和播放丟包率明顯下降

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖20? Bigojitter迭代優化過程：buffersize分布

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖21 ?某新興市場的音頻單次通話時長趨勢（注：該新興市場在4月推全BigoJitter優化版本）

?

04??完善的語音質量測評體系

想要持續運營維護一款受眾數億用戶的產品，單單只專注于功能性需求的開發是肯定不夠的。搭建一套完善而全面的語音質量評測體系，不僅能支撐各項優化開發穩步前進，提供數據平臺的支持，還能賦能各個開發人員，提供驅動力在各種評估體系中探尋不斷優化完善產品的突破。

?

▼ 實驗室內部自動化測評工具建設，分為以下幾方面

（1）采購第三方語音質量評測儀器，該儀器采用ITU-T P.863(POLQA)算法，覆蓋了超寬帶語音傳輸評測，用到感知模型和認知模型模擬了人耳聽覺對外界聲音信號的心理物理反應；

（2）搭建網絡實驗室，采購了能夠精確模擬的硬件網絡損傷儀、自己搭建TC網絡模擬環境以及自研內嵌網絡模擬配合白盒測試，模擬用戶各種網絡場景；

（3）打通測試平臺，與CI結合建立全自動音頻質量測試，制定音頻質量基線。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖22 自動化測試流程示意圖

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖23 ?自動化測試報告對比圖

?

通過實驗室自動化測試，基于質量基線開發，不僅節省測試人力成本提高測試和研發效率而且還支持異地和海外同事遠程使用。

?

▼ 研發線上無參考評估系統

在基于網絡參數的無參考這方面參考ITU-T G.107(E-Model)等標準，首先模擬網絡情況構造嚴重卡頓和輕微卡頓的測試樣本，記錄卡頓次數break_num；其次是獲取codec、采樣率、編碼碼率等參數，記錄為codec_type、sample_rate、encode_rate；然后將測試樣本通過polqa/主觀打分得出mos；最后通過mos、codec_type、sample_rate、encode_rate、break_num多元擬合得到無參考模型；根據大量的polqa/主觀打分修正無參考模型。

在基于音頻信號的無參考模型建模方面，建立純粹的語音通話Demo（排除網絡因素）；構造噪聲，響度，回聲，內容卡頓檢測等測試樣本，同樣測試樣本需要polqa/主觀打分得出mos；通過LSTM深度學習提取無參考模型；最后根據大量的polqa/主觀打分修正無參考模型。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖24 ?imo語音線上質量評估體系圖

?

Imo線上的無參考質量體系實現了對語音通話的實時評估，撈取低分案例，結合低分原因以及診斷工具可以更好地分析跟進badcase，提升通話質量；imo線上的無參考質量體系打破了以通話時長作為技術優化的標準，同時給AB實驗提供支持。

?

▼ 線上質量問題分析跟進利器-診斷工具

要能夠及時解決線上用戶的問題，就必須具備以下的兩個條件：1. 聚合線上用戶所有相關的日志 ?2. 高效分析用戶日志。診斷工具已把以上的兩個條件全程自動化，開發員只要輸入用戶的UID就能一鍵查詢到相關日志和看到這通通話的初步分析拓撲圖。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖25? 診斷工具分析拓撲圖

?

從拓撲圖25可以看到服務器與被叫的下行鏈路丟包率異常的高，并也導致jitter的播放丟包率升高。根據這個分析，我們就能快速的定位到發生問題的模塊，讓模塊的負責人深入的調查問題根源。這樣，解決問題的效率能夠大大的提升，提升了團隊的問題響應速度和定位問題的能力。

?

▼ 競品對比-主動尋找與業界差距

技術在不斷更新，我們會定期與業界競品進行質量對比，主動發掘與競品的差距，例如在一次與競品的測試中發現，imo的丟包抗性不如某國外競品，通過對抗丟包模塊進行專項優化實現了對齊該競品甚至超越。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖26 ?imo語音抗丟包優化前后音質對比某競品

?

同時，我們也不局限于實驗室，imo是一個全球化的產品，每個用戶所處的環境都是不一樣，特別是跨國通話，網絡環境的差異、服務器的部署等都環環相扣，imo在新加坡等海外地區也有專業的測試團隊，imo團隊也是全球化的團隊，依托Bigo海外30多個辦公室，可以比較全面的與競品進行實地評測。

?

三、基于imo特點的差異化服務

?

為了能夠從眾多競品中脫穎而出，imo除了深耕于傳統的QoS相關模塊，提高服務質量的基礎上，針對全球化用戶的特點，也不斷探索了出一些差異化的服務需求。

?

01??用戶數據的隱私性和安全性

隨著網絡音視頻產品的普及和需求日益增加，相對的安全性問題也在不斷凸顯，私人音視頻信息遭泄露等事件時有出現，前不久爆紅視頻會議軟件ZOOM也因其安全性問題而飽受抨擊。而imo在早期就已經開始關注用戶數據的隱私性和安全性的保護。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖27 ?imo媒體加密示意圖

?

imo客戶端之間的數據傳輸使用128比特AES-CTR加密模式加密，客戶端與服務器之間的數據傳輸使用256比特AES-CBC加密模式在確保用戶數據安全的同時性保護用戶隱私，這兩種加密模式都是當前主流商用密碼加密模式，加密安全強度有保障。相較于AES-ECB，RC4，imo采用的AES-CBC加密模式可以較好的隱藏數據細節，以此為用戶數據提供更高的安全性保護。

?

02? 針對機型碎片化改進的統計上報機制

如上文所提到的一樣， imo用戶的手機機型碎片化是非常嚴重的。通過分析線上數據imo用戶機型分布，我們發現前一百機型的比例只占不到50%。而且imo用戶手機升級也較為緩慢，以android機為例，Android系統從4.1～11都存在，所以音頻采集和播放需要考慮設備的兼容性。為此，imo在設備運行各個環節都埋下狀態碼統計，并對最終采集和播放結果進行檢測，通過后臺數據分析和用戶反饋，即可發現碎片化的問題，并實現設備各種模式和參數切換的可配置，從而及時解決線上用戶的設備異常問題。

?

03? 基于統計學設計的AB測試實驗

為優化imo音視頻的通話質量，需要不斷迭代并上線新的feature，而在未證實該feature確切有效之前，是絕不可輕易上線的。AB實驗正是為了驗證feature是否有效而設計的，它是一個樣本推斷總體的過程，方式是進行小流量的測試，利用樣本的效果來推斷上線后的效果。AB實驗的解讀思想是假設檢驗，通過定義原假設，并試圖利用小概率事件推翻原假設。AB實驗的正確設計和正確解讀，能夠幫助開發人員更好評估新特性，以決定是上線還是繼續優化。

既然是用樣本推斷總體，就難免犯錯，指標解讀過程中會存在以下兩種錯誤：

• 第一類錯誤α：原假設為真，卻被我們拒絕了

• 第二類錯誤β：原假設為假，卻被我們接受了

傳統的ab解讀，基本上都只對第一類錯誤α進行控制，因為第一類錯誤是人為定義的，是確定的，易于控制。但是，如果只控制α錯誤，而不對β進行控制的話，會發生“實驗有效果，但是卻沒被檢測出來”的情況，導致錯過有效果的feature。

實際上，在實驗中，如果發現指標不顯著，有可能是流量不足而沒被檢測出來，這時候我們需要加大樣本量。那么，樣本量越大越好嗎？其實不然，因為在大樣本的情況下，我們會檢測出那些細小但有時不具有任何意義的差別，也就是說，即使假設檢驗的結果具有統計顯著性，但是由于該結果效應量太小，實際上并沒有什么意義。

為解決這個問題，在imo實驗中，我們會基于定義好的α錯誤，期望達到的效應量，以及可接受的β錯誤，事先計算出合適的樣本量。這樣在實驗觀察過程中，如果發現指標不顯著，并且沒有到達預期樣本量，那么我們便會加大樣本量，再觀察實驗結果。

下表為演示具體case的計算流程，比如我們拿到的樣本數據如下所示（此處數據為偽數據，主要用于公式說明，非實際線上數據）：

1、提出假設

（1）H0（原假設）：假設Bigojitter表現和speexjitter表現無差異，即μ1-μ2=0

（2）H1（備擇假設）：Bigojitter表現優于speexjitter，即μ1-μ2>0

2、如果原假設成立，那么得到該樣本，即x1-x2=4.46的概率多大？

（1）抽樣分布均值：0

（2）抽樣分布標準差：利用樣本標準差替代總體標準差，可得到

??

3、計算當前樣本之差4.46距離0有幾個標準差：4.46÷1.43≈3.12

#sigma為3.12，說明在原假設成立的條件下，該樣本均值距離總體參數超過3個標準差，出現概率極低（如下圖紅色面積），所以我們有理由拒絕原假設，認為Bigojitter表現優于speexjitter。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖28 Bigojitter抽樣結果概率分布圖

?

當前，imo音視頻已有一套強大的ab系統，該系統不僅涵蓋了幾百個關鍵指標，并且每個指標都會自動計算出#sigma。利用ab系統，開發人員能快速判斷核心指標是否顯著，以決定功能是否上線。

下面為imo ab系統的部分指標，對于第一個指標，其#sigma為107.2，遠高于閾值3，可以得出指標顯著的結論。對于第二個指標，雖然指標不顯著，但我們可以根據效應量計算理論樣本量，評估當前樣本量是否ok，從而決定是否放量再進行觀測。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖29 ?imo AB實驗系統指標展示圖

?

四、總結?

?

綜上所述，imo音視頻傳輸團隊圍繞QoS不斷深耕核心模塊，以解決網絡丟包，抖動，延時等實時音視頻通信中的核心挑戰。與此同時也在不斷完善完整的語音質量評價體系，完備的測試環境和置信度更高專項性更強的線上ab測試實驗與統計。這一切都是為了能夠不斷產生新的驅動力去優化imo的音頻傳輸業務。

目前而言我們已經具備了語音傳輸相關的QoS相關算法模塊并各自取得了一定的成績，但實際上QoS保證牽扯到了編解碼，鏈路，傳輸，處理， 設備等眾多環節，處理好技術的協作關系，如何對各種 QoS 算法的調度、管理、配合是核心難點，也是我們未來階段不斷前進的目標與方向。相信隨著對更多基于業務細節的不斷深入研究和探索，我們團隊會找到更加適合imo的協作策略，讓我們的實時音頻傳輸體系能夠在更多的業務場景中發揮它的優勢和價值。

?

?

版權聲明

轉載本網站原創文章需要注明來源出處。因互聯網客觀情況，原創文章中可能會存在不當使用的情況，如文章部分圖片或者部分引用內容未能及時與相關權利人取得聯系，非惡意侵犯相關權利人的權益，敬請相關權利人諒解并聯系我們及時處理。

?

關于本文

本文首發于公眾號【BIGO技術】，感興趣的同學可以移步至公眾號，獲取最新文章~

?

總結

以上是生活随笔為你收集整理的BIGO | imo实时语音传输优化揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。