在 WebRTC 專案中，又拍雲團隊做到了覆蓋系統全域性，保證專案程式流暢。這牽涉到主要三大塊技術點：
- 網路端、服務端的開發和傳輸演算法
- WebRTC 協議中牽扯到服務端的應用協議和信令服務
- 客戶端iOS、安卓 H.264 編解碼技術
△ WebRTC 技術點
實時音視訊互動必須遵守三大點
- 必須基於 UDP 協議，否則不要談實時
因為 TCP 協議的重傳機制（傳輸保障）會導致累積延遲問題，用 UDP 協議沒有傳輸保障機制，但需要自行完善丟包容錯邏輯。
又拍雲音視訊互動方案是基於UDP 協議，使用 TCP 協議無法保障實時性。
TCP 協議有包重傳機制，保證傳輸內容100%傳輸到目的地，這個特性導致延時增加。當然，由於UDP協議沒有包重傳機制，需要完善業務的容錯性。目前來說，UTUN 網路提供的兩種配置，都可以保證資料100%傳輸。
在極差的網路狀態下，可以選擇容忍丟包，使用演算法保障90%以上的資料包正常到達，以此達到200ms以內延遲。
UDP協議相比TCP協議具有多鏈路傳輸的優勢。
TCP協議只支援單一鏈路傳輸。當連麥、音畫同時需要傳輸時，TCP協議只有一條通道進行資料傳輸。而通過UDP協議，音視訊可以通過兩個節點將資料一分為二來傳輸，A路傳輸50%資料包，B路傳輸50%資料包。終端收到兩路資料流，再合併放到應用層做解碼處理。
- 考慮多終端適配，使用 WebRTC 協議
客戶端網路跨地區和跨運營商訊號很差，所以不能使用 P2P 模式。目前包括蘋果Safari 在內的所有的桌面端瀏覽器都已支援 WebRTC 協議。
網路層使用 P2P 模式無法解決跨地域、跨 ISP 的跨運營商網路問題，會導致延時過高的情況產生。如果一直糾結於P2P模式，那麼QOS位元速率控制、包容忍等問題就無法在演算法上有所突破。
- 雲服務化
單機、單機房存在硬體瓶頸，唯有云服務化才能按需做到橫向擴充套件。
隨著使用者量的提升，單臺伺服器所能支撐的併發量直播有限，RTMP Server、WebRTC Server一般八核伺服器能承受的併發量只有2000~4000路，單機房也會成為硬體瓶頸，而公有云能承受幾十萬甚至上百萬的數量壓力，所以機房中不能存在單點，必須是雲服務化分散式的。
雲服務化非常重要，上文提到的 UTUN 網路屬於完全分散式網路，分佈在又拍雲兩百多個節點，四千臺伺服器上。只需要接入又拍雲任意邊緣伺服器，就可以做到自主服務，自動選擇出一條甚至數條路徑，讓使用者與通訊網中任何地點的人互動。
又拍雲 WebRTC 架構中遇到的經驗和問題
又拍雲 WebRTC 相比外部的 WebRTC 有較大的差別。即使你在同一個地方、同一個服務商、同一個無線訊號下，又拍雲都沒有使用P2P模式，都是通過雲服務來進行網路傳輸的。
我們嚴格遵循官方標準搭建包括服務端、客戶端在內的 WebRTC 體系。目前 WebRTC 版本為可變性非常大的1.0版本，未來該技術可能會有革命性的迭代。如果採用自研的方式，會有無法跟進版本技術更新的風險。再者如果完全自主編寫 Server 端或者客戶端勢必要投入非常大的精力和研發時間。
因此又拍雲選擇緊跟官方的步伐，無論官方有何種bug修復，都選擇同步更新。
又拍雲在實踐中遇到的問題：
- 當 iOS 端使用新版本 WebRTC 時，由於音訊處理部分導致的 Bug，會導致 CPU 佔用率過高；
- 服務 Server 端由於編碼傳輸時 WebRTC 是可變位元速率、可變幀率的，但是核心程式碼在進行傳輸時卻使用了固定幀率操作，時間戳不一致的 Bug 導致了音視訊不同步的情況，聲音與畫面不同步最大延時可以達到數十秒，不斷累積。為了解決這個 Bug 需要把視訊時間戳進行修正，統一使用音訊的時間戳，來保證音視訊同步；
- Android 端不支援高通外的晶片硬解碼，又拍雲在近期把各個 Android 端編解碼功能完善，目前已經能夠適配華為、MTK、三星等品牌的機型；
- 目前客戶端解碼能力有限，會話人數最好控制在8個人以內；
- 自動根據參與人數控制總頻寬在2Mbps以內；
- 美顏、濾鏡等功能的接入會增加延遲，加入額外功能不能過度消耗客戶端 CPU 資源。
音視訊互動最大的難點——業務信令
目前業務信令還沒有一套完整的解決方法，業務信令在 WebRTC 中雖然是開源的，但是沒有形成標準的信令協議，這個部分需要我們自行構建。
架構網路電話場景時，牽扯到三個信令：呼叫、等待接聽、通話。
但是實際中會有更多信令，假設一個會議場景，A邀請參會B，A會設定多個邀請途徑：1.A直接將B拉到會議室；2.A把會議室號碼給B，B自行進入；3.A配置房間許可權控制，需要得到授權才能進入房間等。隨著業務的發展，業務信令會不斷增加，我們需要構建一套完善的信令體系顯得非常重要。
我們在編寫信令系統時，把信令系統分成了兩類：1.底層系統信令，2.公共業務信令。
底層系統信令只需編寫公共業務信令的總通道協議和 API 介面，讓應用程式對接，將業務信令進行統一標準化。比如在房間裡，傳送一條廣播給所有參會者的業務信令S，而業務信令S只想傳達給B，但是C在同一個會議室也聽到了，C會選擇性的對業務信令S忽略以此達成這個業務功能。
目前來說必須面臨的現實問題：
1.客戶端硬體效能未能支援高清位元速率：多人互動不可能做到720P解析度，一般來說都是在320P或者460P解析度。一般手機因為客戶端的解碼能力支撐不了多路高清解碼，達到6路以上位元速率只能做到300K以下；
2.硬編解碼相容性差：Android 機型太多，僅能有限支援H.264硬編解碼，同時iOS和Android 端均不支援 H.265 硬編解碼；
3.手機發熱、耗電量大：參加會議iPhone電量支撐兩、三個小時。桌面端耗電、發熱最嚴重，測試時使用Chrome硬解碼電量只能支援兩個小時。
以上三點是目前整個業內所都要面臨的最大的問題，只能等待終端的解碼能力提升，相信到明年手機解碼能力就可以支援多路高清互聯。