在現代生活中，音視訊通話是我們最常使用的溝通方式之一。比如，社交中的一對一音視訊，醫療中的遠端問診諮詢，房產交易中的線上看房，以及遠端工作場景下隨時隨地可能發生的一對一和群組音視訊溝通。*本文轉自公眾號【融雲全球網際網路通訊雲】，回覆 抽獎 獲福利。
而我們在使用中也多少感受過產品邏輯的“卡殼”，比如音視訊無法自由切換、1V1 不能升級群聊、退出群視訊無法隨時加入等等。
6 月 16 日，融雲 RTC · 進階實戰高手課聚焦音視訊通話，從音視訊通話實現、多場景體驗痛點和融雲 New CallLib 的最佳實踐等方面，拆解音視訊通話在多種使用場景下面臨的體驗挑戰，分享優化方案。後臺回覆【通話】獲取完整課件
音視訊通話實現
我們通常說的音視訊通話，指類似微信等必須含有呼叫流程的應用場景。有一個主叫和一個或多個被叫，主叫發起通話，被叫可以選擇接聽或者結束通話。
音視訊通話的使用場景非常多，特別是當我們正在經歷一場大型數字化轉型時。
比如，遠端問診，醫生可以通過音視訊通話對患者進行溝通從而方便診斷；VR 看房，房產中介通過音視訊通話和租客進行溝通，結合 VR 實現遠端看房；線上相親，紅娘可以通過群聊讓相親物件交流，這是一個群組的音視訊通話使用場景。
（音視訊通話使用場景）
音視訊通話出現在我們線上生活的方方面面，也是各類應用的必要能力。那麼，如何實現一個音視訊通話呢？
從需要掌握的基本知識方面來看，大體分三個部分，音視訊、網路傳輸和伺服器。這是一個非常複雜的系統，這裡只做大概描述。
（RTC 基本知識）
音視訊
音視訊的基礎知識：音視訊的採集，不同的平臺採集方法有所不同。開發者需要掌握後設資料的基本知識，也就是我們通過採集直接得到的資料格式。
音視訊資料的處理：要掌握音訊降噪、音訊的迴音消除、影像的裁剪等。
音視訊的編解碼：至少要掌握一種音訊編碼和一種視訊編碼。
編碼格式有對應的解碼器，比較通用的編碼格式還可以使用硬體解碼，可根據解決方案的不同選擇軟解還是硬解。軟解的相容性高，但會損耗 CPU 效能，硬解效能好，但可能面對一些相容性問題。
音視訊的播放和渲染也是必須掌握的，通常播放和渲染指的是對後設資料的播放和渲染，音訊其實就是 PCM 的播放，視訊如果是客戶端會用到 OpenGL，瀏覽器需要用到 WebGL 等。
網路傳輸
客戶端可以選擇 TCP 或 UDP，通常音視訊使用 UDP 傳輸，這是因為音視訊資料要求的是實時性，而不是完整性，音視訊的資料即使不完整也可以正常播放。
TCP 和 QUIC 都是可靠性傳輸協議，類似業務信令資料等要求完整性的更多使用 TCP 或者 QUIC。
QUIC 協議是建立在 UDP 協議上的一種保證完整性的協議。UDP 本身是不可靠協議，如果要保證完整性就需要自己做丟包重傳策略，而 QUIC 是具有丟包重傳策略的一套資料協議，可以達到與 TCP 同樣的效果。
伺服器
通常分為信令伺服器和音視訊伺服器。顧名思義，信令伺服器負責傳輸業務相關資料，音視訊伺服器負責傳輸音視訊資料。不同的技術方案對應實現伺服器的技術也會有所不同。利用以上基本知識，我們可以完成音視訊通話場景的核心邏輯了。在考慮和呼叫場景強相關的業務處理之前，要先解決以下兩個問題。
首先是業務資料的即時傳輸。要發起一個通話，要有主叫端、被叫端兩個客戶端。被叫端如何收到主叫端傳送的發起信令？可以使用 Push+長連結的形式，或者第三方提供的 IM SDK 來實現。
接下來是更關鍵的音視訊基礎能力，以及音視訊資料的實時傳輸能力。
開發者如若自研，可以選擇 WebRTC，這是 Google 提供的一套具有音視訊基礎能力及傳輸能力的完整開源方案；或者可以從頭自研一套完整的 RTC 系統。當然，不管是選擇哪種自研方案，都有非常複雜的底層知識需要學習，需要有相當的研發能力和人員配備。
融云為開發者提供了另一個更加便捷的實現方案，融雲 CallLib。
針對音視訊呼叫場景，融雲將 IM 和 RTC 能力融合封裝，提供了包含完整呼叫流程的 SDK。開發者只需要關心 CallLib 提供的少量介面，即可實現呼叫需求，同時具備以下優勢。
完整性，呼叫流程完整，支援單人、多人呼叫，開發者不需要關心底層實現原理。
易用性，開箱即用，快速實現，靈活定製。
穩定性，IM 訊息 100% 可靠到達，RTC 音訊抗丟包 80%，視訊抗丟包 60%。
場景的多樣性，擴充套件性強，可以滿足多領域對音視訊呼叫的需求。
基於融雲 CallLib，開發者可以快速實現具有呼叫功能的 App，而針對開篇我們說到的使用場景卡殼情況，我們還對產品進行了針對性升級優化。
多場景通話體驗優化需求
呼叫的升級
音視訊的升降級：使用者在打音訊通話時可以直接切換為視訊通話。
1V1 升級為群聊：從 1V1 單聊直接變為多人討論群聊。
隨時加入未結束的通話：當群組通話時，若使用者當下未立即接入，只要通話還沒有結束，就可以選擇加入。
流控制的升級
自由的音視訊流釋出 API；多個通話實現預覽；選擇接聽以及呼叫等待。
主要優化流控制的 API，讓開發者便捷使用的同時可以根據自己的需求開發出一些高階功能。
資料一致性的升級
包括通話計時的一致性、參與者狀態同步一致性以及極端場景下，操作業務邏輯的一致性。
資料一致性的升級主要是為了給所有參與音視訊通話的使用者，特別是通過不同端接入通話的使用者帶來更加一致的體驗，也方便後期的業務擴充套件。
那麼，如何實現這些優化和升級呢？
融雲 CallLib 基於 IMLib 和 RTCLib 實現，是一個重客戶端的設計。
所有的狀態和業務邏輯需要儲存在客戶端，增加了客戶端的實現複雜度，業務邏輯要在每個端進行重複實現，也會導致極端情況下狀態不一致。
比如主叫和被叫同時點選結束通話。主叫結束通話叫取消，被叫結束通話叫拒絕，體現在通話記錄上是不同的。而如果主叫和被叫同時結束通話，由於這個操作都是從客戶端發出和處理的，無法分辨到底是誰先做的操作，導致通話記錄不準確。
這個問題其實是可以處理的，但會很複雜，因為重客戶端的設計很難實現功能的擴充套件。
融雲 New CallLib 實踐
融雲 New CallLib 可以優雅地解決上述問題。
升級業務處理能力：重服務端，輕客戶端的設計。
原有的 CallLib 負責維護的狀態，改為在服務端維護和儲存；CallLib 轉變為了由 Server 驅動的狀態機模型；
大大簡化了客戶端的實現複雜度，並可以避免多端邏輯實現不一致的問題。
因為狀態變更都是由服務端發出，也就保證了狀態的一致性，在處理極端場景和線上離線狀態方面也遊刃有餘。比如上面說到的兩端同時做出結束通話操作，一定有一個操作先到達伺服器，然後伺服器進行狀態的下發，更加有序。通話記錄的生成也是由伺服器完成，就不會造成兩端狀態不一致的情況。
下面結合具體場景看一下，新的設計如何做到體驗再升級。
1V1 音視訊通話呼叫流程
這是我們最基本的通話功能，右側是這個基礎能力的完整時序圖，由 4 個角色共同完成，Client A、Client B 分別代表主叫端和被叫端，Call Server 處理呼叫相關的業務邏輯，RTC Server 處理音視訊的通話。
從圖中可以看出，這個基礎能力的流程實現起來其實非常複雜。
音視訊的升降級
相信很多人有過這樣的體驗，當你在一個語音通話過程中因為一些原因需要開啟攝像頭，要先結束通話音訊通話重新發起視訊。
融雲對這樣的場景做了優化實現，讓這個場景下使用者使用更加便捷，當我需要臨時將音訊通話升級為視訊通話時可以在通話內發起一次升級請求。被髮起端可以選擇接受或拒絕，如果接收了就升級為視訊通話，拒絕就繼續音訊通話。當然發起端也可以選擇取消升級。
這個場景下，也可能出現一些極端操作，比如發起端的取消操作和被髮起端的接受同時點選，這時 CallServer 會起到一個決策的作用，比如我們以取消為準，只要操作了取消，即使被髮起端點選接受依然會讓兩端都降級為音訊通話。而在此前的重客戶端設計中，這個判斷會變得非常複雜。
通話中來電
在我們常見的音視訊通話場景中，如果被呼叫使用者正在進行語音或視訊通話，通常會顯示對方繁忙，需等待他結束通話。
類比電話場景，通話中的我們可能會收到第三個人的來電，此時運營商電話有選擇接聽和呼叫等待的功能，也就是說我們同時可以處理兩個電話。針對這個場景，融雲的 CallServer 儲存了每個電話的狀態，所以即使已經在通話中了依然具備處理其他通話的能力。
群聊呼叫流程
群聊和單聊的區別在於兩點，一是參與者可能為兩人或以上，二是隻要通話中還有一個人，通話就未結束。
所以群聊通話只要發起，發起人就第一時間進入了 RTC 房間，等待其他人加入。另一個比較特殊點在於，過程中可以隨時邀請他人加入房間，流程和發起非常類似。
在我們常用的通訊軟體中，群聊只能發生在某個群組裡，而融雲服務可以支援隨時隨地從不同的群組或者私人通訊錄中做發起和邀請的操作。
1V1 升級群聊
這個場景發生在兩人正在通話的過程中，有可能臨時發現這個溝通需要其他人蔘與，融雲支援將一個 1V1 通話直接升級為一個群通話。
升級的過程和群通話過程中邀請他人的過程類似，不同的是在升級為群聊的時候，Call Server 會明確告訴 1V1 的參與雙方當前通話已經變為一個群通話了。升級成功後的後續流程和群聊是一樣的。
未結束通話的隨時加入
這也是一個常見情況——收到群通話時不方便接聽，或接聽一段時間後臨時有事需要離開一下。群通話只要有一人在就不會結束，所以暫時未參與群聊的使用者，可以選擇在結束前的任意時間再次加入通話。
這是一個特別實用的優化，尤其是在我們現在越來越多的線上辦公和溝通的場景中，臨時有事要離開，後面又需要加入溝通繼續之前的討論。這也得益於 Call Server 對通話狀態的儲存，讓客戶端可以隨時獲取未加入通話的狀態。
通話記錄實現
此前，我們的通話記錄儲存在本地，想要做到多端同步其實很困難。
現在可以做到通話記錄的更新刪除，甚至通話記錄的未讀計數都可以多端同步，給使用者帶來更加合理和統一的體驗。體驗優化是一個長期話題，而音視訊通話屬於既十分常用又極其複雜的功能。融雲基於多年通訊行業深厚技術積累，將持續優化體驗到細枝末節，消滅使用中的“卡殼”，為開發者提供更便捷和契合使用者使用習慣的解決方案。