編者按： 最近幾年視頻會議產(chǎn)品得到了極大的關(guān)注和快速的發(fā)展。產(chǎn)品的用戶體驗，功能和質(zhì)量決定了產(chǎn)品能否在競爭中脫穎而出。而如何選擇一個好的架構(gòu)和解決方案是最為關(guān)鍵的因素。

本次分享將分為幾大部分：第一部分介紹視頻會議產(chǎn)品的歷史以現(xiàn)狀，以及主要的功能要素。第二部分將介紹基于 WebRTC 的解決方案以及優(yōu)缺點，以及主要的挑戰(zhàn)。第三部分介紹 RingCentral 的視頻會議系統(tǒng)的解決方案，以及主要技術(shù)優(yōu)勢。希望通過分享，大家對于如何打造一款優(yōu)秀的視頻會議產(chǎn)品在架構(gòu)選擇和技術(shù)選型上能有一定的收獲。

文 / 何必蒼

整理 / LiveVideoStack

大家好，我今天演講的主題是關(guān)于視頻會議，WebRTC 以及 RingCentral 的解決之道。

本次演講大概分為六部分。首先，介紹下個人及公司，再聊下視頻會議產(chǎn)品發(fā)展及趨勢，之后會講一些主流的網(wǎng)絡(luò)視頻會議解決方案，緊接著說下基于 WebRTC 的解決方案及挑戰(zhàn)，最后詳細談下 RingCentral 是如何解決這些問題以及它的架構(gòu)。

1、個人及公司介紹

按照慣例，我先簡單介紹下我自己以及公司。

我在 RingCentral 擔(dān)任視頻與媒體研發(fā)高級總監(jiān)，同時我也是杭州研發(fā)中心負責(zé)人，負責(zé)公司視頻產(chǎn)品的研發(fā)。加入 RingCentral 以前，我在 Webex 任職 18 年，擔(dān)任系統(tǒng)架構(gòu)師和客戶端負責(zé)人職位，見證了 Webex 從一個非常小的產(chǎn)品發(fā)展壯大到成為 leader，進入全盛時期的過程。我本人比較關(guān)注 RTC 領(lǐng)域、人工智能在這個領(lǐng)域的應(yīng)用等等。

國內(nèi)認識 RingCentral 的人可能不多，實際上我們是一家全球領(lǐng)先的企業(yè)云通信供應(yīng)商，聯(lián)絡(luò)中心解決方案的提供者。RingCentral1999 年成立于美國硅谷，2013 年于紐交所上市。RingCentral 目前在國內(nèi)有三家 office，分別位于杭州、廈門和香港。統(tǒng)一通信領(lǐng)域中存在很多巨頭，像思科、微軟等等，RingCentral 公司已經(jīng)連續(xù)七年獲得榮膺 Gartner 全球 UCaaS 魔力象限領(lǐng)導(dǎo)者，可以說是非常不簡單了。

2、視頻會議產(chǎn)品發(fā)展及趨勢

接下來，我們聊一下網(wǎng)絡(luò)視頻會議產(chǎn)品發(fā)展及趨勢。

可能很多人是從疫情開始接觸到視頻會議，但網(wǎng)絡(luò)視頻會議本身具有非常悠久的發(fā)展歷史。早在 1970 年以前，應(yīng)該說是 20 世紀初這個 idea 就出現(xiàn)了。在 20 世紀 30 年代，貝爾實驗室制造了第一個可視電話原型。后來，AT&T 投入了大量資金研發(fā)出了第一款產(chǎn)品，那時的產(chǎn)品是基于特定網(wǎng)絡(luò)和硬件的，很可惜，AT&T 產(chǎn)品完全失敗了，但他們的想法和技術(shù)在實驗階段逐漸被證實。80 年以后被稱為商業(yè)化階段，數(shù)字電視的普及加速了發(fā)展，第一款商業(yè)化產(chǎn)品也是在 80 年代后期到 90 年期間推出的。這時，AT&T 的第一款 PictureTel 產(chǎn)品也推出了第一個編碼器，當時所有的設(shè)備和產(chǎn)品都是基于專用的撥號網(wǎng)絡(luò)和專用硬件，特定用戶人群才能使用。

90 年以后迎來了高速發(fā)展的階段，因為隨著互聯(lián)網(wǎng)和 PC 的普及，基于 PC 的商業(yè)化產(chǎn)品 90 年后開始出現(xiàn)，同時也出現(xiàn)了第一款商業(yè)化攝像頭，解決方法都是互聯(lián)網(wǎng)和非專用設(shè)備，得到了極大的普及和加速發(fā)展。2000 年以后，視頻會議進入了成熟的標準化階段，編解碼器、H264 都出現(xiàn)了。WebRTC 也在 2017 年開源了，出現(xiàn)了開源的框架。隨著 SaaS 和云計算的普及，視頻會議也云端化，也出現(xiàn)了移動化及多終端化的支持。2020 年以后，疫情出現(xiàn)導(dǎo)致遠程辦公爆發(fā)增長，大量公司進入這個領(lǐng)域，也產(chǎn)出了大量創(chuàng)新，視頻會議迎來了爆發(fā)的階段。在此之前，很多人可能也沒想過虛擬背景替換等，但隨著居家辦公的出現(xiàn)，虛擬背景替換等創(chuàng)新都慢慢開發(fā)出來了，產(chǎn)品變得智能化并且能與不同行業(yè)不同技術(shù)進行融合。

以我個人見解來看它的趨勢，從發(fā)展來看，首先是融合化。在疫情之前，網(wǎng)絡(luò)視頻就是一個滿足人類基本溝通需求的工具，隨著疫情爆發(fā)之后，我們發(fā)現(xiàn)它和不同的技術(shù)比如 AI、VR 和元宇宙結(jié)合，所以它的趨勢上來說，越來越多的含義和技術(shù)進行融合，呈現(xiàn)出更多的產(chǎn)品和創(chuàng)新。

第二點是智能化，已經(jīng)有很多產(chǎn)品號稱含有智能因素，無論是虛擬背景還是智能降噪或是實時語音翻譯等。我認為這還遠遠不夠，將來隨著技術(shù)發(fā)展，會出現(xiàn)更多智能化元素提供更豐富的功能來提高效率，使生活更便捷。

第三點是生態(tài)化，今天的視頻會議不再是簡單的工具而是一個平臺，成為了一個生態(tài)。在生態(tài)上有硬件產(chǎn)生，有平臺供應(yīng)商，也有提供平臺進行二次開發(fā)的，能創(chuàng)造出更多附加價值。這個趨勢普及范圍會越來越廣。

3、主流網(wǎng)絡(luò)視頻會議解決方案

如今的視頻會議行業(yè)有非常多的玩家，或多或少無論你是否認識，有很多視頻廠商存在于這個行業(yè)。我認為主流網(wǎng)絡(luò)視頻會議決解方案有很多共同點。

首先講的是對終端的支持。所有的主流廠商基本都會支持這些可見的終端，第一個是移動客戶端，隨著遠程辦公和移動辦公的普及，沒有這個終端是很難讓客戶買單的，特別是移動，也許你在路上要加個會、假裝已經(jīng)到公司了，這些都是非常便利的方式。第二個是桌面客戶端，不用我多說，大部分的應(yīng)用產(chǎn)品都在桌面端，所以這塊必須支持。那會議室終端的話，會議室是一個非常特殊的場景，如果很多人一起用電腦加入會議，無論是語音還是視頻都是無法滿足這個應(yīng)用場景的，那就需要一個大屏的電視機加一個強大的外設(shè)，所以這一點也是需要 cover 的。

說到 H5 終端，有些應(yīng)用場景必須用瀏覽器來支持加會，自然而然隨著瀏覽器支持 WebRTC，這是一個非常重要的賣點。那還有電話終端，隨著網(wǎng)絡(luò)會議的發(fā)展，不僅是與對方的電腦，不是每個人隨時隨地都可以在電腦旁或手機旁，有時需要用 PSTN 進行溝通，所以這也是一個必要的支持。除此之外還有 SIP 終端，隨著越來越多的廠商出現(xiàn)，你也不能要求所有客戶都用同一個產(chǎn)品，之間的互操作性也是一個重要點。

在這些主流廠商中，這些關(guān)鍵功能和技術(shù)要點也是要 cover 的。像音視頻和 PSTN 互通，它需要在很多場景或是會中 call 一個電話，像視頻及虛擬背景支持、桌面共享及遠程控制等，這些功能在日常協(xié)作或是分享中都是很必要的。比如電子白板在遠程辦公中可以寫字或是畫圖來相互分享想法。另外，還有弱網(wǎng)優(yōu)化，我們客戶會遇到很多網(wǎng)絡(luò)狀態(tài)，你如果不做優(yōu)化，質(zhì)量一定是無法保證的。還有標準化及互操作性，剛提到的 SIP，隨著客戶與其他客戶開會時，可能會有不同廠商的產(chǎn)品進行相互之間的協(xié)作和交流。

在這里，很多關(guān)鍵協(xié)議和標準是所有廠商要去遵守的，比如信令方面，我想很多廠商可能會想 WebSocket 因為它能兼容瀏覽器，像 HTTP 也好，那也許很多可能是 TCP。在媒體傳輸方面，我想很簡單，無論是 WebRTC 還是自營的產(chǎn)品，RTP+RTCP 必然是首選。在視頻編碼上，像 SVC/AVC+Simulcast/VP8+Simulcast 是比較主流的選擇。那音頻也一樣，我相信絕大多數(shù)是 Opus 支持，那比較古老的可能 SILK 或 G.7xx 更多的協(xié)議。像直播方面，支持的 HLS 或者 DASH 等等等等。對第三方交互，大廠商基本都會支持 SIP 的接入，像 SIP + 媒體傳輸來支撐互操作性。

那么，音視頻框架，現(xiàn)在主流產(chǎn)品分為兩大類。一個是自研框架，很多老牌廠商像 Zoom 等在很久以前就開始研發(fā)，它們都會有自研方案，它的特點是靈活和高性能因為所有都在你的掌控之內(nèi)。它的缺點是研發(fā)周期長，有可能需要幾年的投入，很多技術(shù)難點一個個去摸索也是非常耗時耗力。另外，最近的廠商像微軟 / 谷歌 / 飛書等都會選擇 WebRTC 作為起點，WebRTC 的特點也非常明顯，它有成熟的開源框架，能快速推出源型，資料非常豐富，招人也很方便，因為市場中有大量的人才。相比自研框架它也有很多缺點，它非常龐大，因為有很多標準需要支持，這造成了協(xié)商和交互的繁瑣，遇到問題調(diào)試也是非常麻煩的。另外，性能上來說和自研比也是有差距的，坦白來說有些標準和流程還是存在一定的局限性。

4、基于 WebRTC 的解決方案及挑戰(zhàn)

下面我們重點講基于 WebRTC 的解決方案及挑戰(zhàn)，因為這是目前的先進廠商的主流選擇。

我們有兩種 WebRTC 研發(fā)模式，一種是基于前端開發(fā)模式，主要的研發(fā)前端用 Javascript 或 Typescript，一般主流選擇用 Electron+WebRTC，無論是微軟還是國內(nèi)的飛書都選這種模式，它的特點是跨平臺，一份代碼能 cover Electron 本身和瀏覽器，這個好處是顯而易見的。另一種是原生開發(fā)模式，即不是用前端語言來開發(fā)，還是用 C++ 或者是 native 語言比如 iOS 等來開發(fā)，它的好處是可擴展和定制化，如果發(fā)現(xiàn)哪里性能不行可以很方便地改造它。從性能上來說比前端會好一些，起碼調(diào)優(yōu)還是有辦法去調(diào)，不像前端基本上是不受控的。

那么，基于 WebRTC 還是有不少優(yōu)勢的。首先它免費，研發(fā)這樣一套框架如果自己去做起碼一兩年以上，需要大量投入，比如招人等也是一個漫長的過程，所以這一點是一個巨大的優(yōu)勢，特別是針對于想快速進入市場的公司來說這是一個很不錯的選擇。第二點是資料豐富，基本上你遇到的坑別人都踩過了，網(wǎng)上都能找到，可以快速解決你的問題。第三點是人才，現(xiàn)在市場上有很多熟悉這塊的人才，所以這點對快速迭代或是研發(fā)來說是非常重要的因素。

那么，它的代碼是非常成熟的，全世界有成千上萬的人每天日日夜夜在維護和使用，所以我認為很多 bug 和問題都有非常多的經(jīng)驗可以借鑒。然后，很多主流瀏覽器都已經(jīng)支持，這也是非常大的優(yōu)勢，因為剛說的 H5 終端它需要支持。

WebRTC 雖然免費，但它作為一個一流產(chǎn)品還是需要付出很大代價的。它需要強大的服務(wù)器端支持，WebRTC 本身是 P2P 模式，服務(wù)器端需要自己研發(fā)，因為它整套框架非常復(fù)雜，需要支持眾多協(xié)議，標準等，相應(yīng)的服務(wù)器需要自己去識別這些協(xié)議也是巨大的挑戰(zhàn)工作。因為框架是基于瀏覽器，有時候你的解決方案可能是為了照顧瀏覽器，很多方案必須在服務(wù)器端實現(xiàn)。由于瀏覽器不受控制，它提供的接口或者說是能控制的地方不多，所以像回音消除等功能可能選擇服務(wù)器端去完成，這會帶來一些額外的問題，有些局限性比如查問題會比較困難，信令網(wǎng)絡(luò)斷了等會經(jīng)常發(fā)生。另外，服務(wù)性能挑戰(zhàn)也是一個問題，一方面是因為協(xié)議的復(fù)雜性，另一方面是因為 P2P 模式服務(wù)器可能存在大量的工作，所以在性能上比較受限。

第二個挑戰(zhàn)是它對弱網(wǎng)支持非常有限。WebRTC 的設(shè)計初期不是為了優(yōu)化弱網(wǎng)，他們當初做這個框架的時候認為網(wǎng)絡(luò)不能差到哪里去，太差的網(wǎng)絡(luò)不應(yīng)該做音視頻會議，它默認只能抗 15% 左右的丟包。另外，它對默認 QoS 算法比較敏感，對于一些網(wǎng)絡(luò)的變化是沒法及時調(diào)整和適配的。所以有時明明帶寬還可以，但檢測出來反而只有最基本的語音通信幾十 K。所以，這是它對于弱網(wǎng)支持來說一個非常大的問題。

對于平臺和設(shè)備也一樣，WebRTC 在一些平臺上的實現(xiàn)不是很完美，它的音頻采集就是默認 16K 的采集，諸如此類。它也無法使用平臺本身的一些能力來提早用戶體驗，那在一些設(shè)備上比如新的蘋果手機，它有時會有明顯的回聲消除問題，所以這也是一個需要關(guān)注的問題。

另外，它雖然提供了一個音視頻框架，但很多功能還是需要自主去研發(fā)的，作為一個主流產(chǎn)品完全靠它肯定是不夠的。包括直播它就完全沒有提供任何支持，需要自己去實現(xiàn)，比如 E2EE（端對端加密），它本身就是 P2P，那對于 WebRTC 來說，天然就不支持這個功能，還有像 SIP 會議、字幕功能等等。

5、RingCentral 解決之道

那對于這些問題，我們重點講下 RingCentral 的解決之道以及構(gòu)架。

首先，RingCentral 產(chǎn)品名稱是 MVP，分別是 Message、Video 和 Phone，它是統(tǒng)一一個 client，一個 client 能讓你日常協(xié)作在同一個場景里發(fā)生，我們的目標是提供任意時間、任意地點、任意設(shè)備、任意方式的溝通和通訊。

這是一個非常簡單的系統(tǒng)架構(gòu)圖，簡化再簡化，這只是一個概念上的東西。首先，我們會支持非常多的終端。我們的 data center 會有級聯(lián)操作，對于終端來說，它會選擇最接近的邊緣節(jié)點，通過信令和媒體進行交互。數(shù)據(jù)中心通過級聯(lián)進行數(shù)據(jù)傳輸，這能提高用戶體驗，用戶可以選擇離他最近，體驗最好的一個服務(wù)器來接入。同時，我們會支持非常多的終端支持，比如電話終端我們通過電話網(wǎng)關(guān)接入以后進行后臺 mix，通過 PSTN 到數(shù)據(jù)中心等等。對于第三方客戶端支持我們通過 SIP 的網(wǎng)關(guān)來接入，能夠通過 SIP 和媒體的交互來支持目前來說所有主流的產(chǎn)品無論是微軟的 Teams 還是 Zoom 等等。對于第三方直播系統(tǒng)我們也通過 RTMP 協(xié)議，通過信令網(wǎng)絡(luò)進行分發(fā)，對超大型會議進行足夠支持，包括將來 Facebook、YouTube，能直播到第三方系統(tǒng)中去。

這是 RingCentral 視頻客戶端架構(gòu)。整個客戶端分為四層，最底下一層是網(wǎng)絡(luò)協(xié)議層，我們提供眾多的協(xié)議接入包括 HTTP、WebSocket 這種信令級別的協(xié)議，對于媒體傳輸或控制有 RTP，第三方用 SIP，還有其他眾多協(xié)議等。

在協(xié)議之上，我們會提供非常多的組件，每個組件可能帶著某一項特定的功能，比如視頻可能有眾多的功能供上層使用，會有音頻、桌面共享等等。

在組件層之上，我們有 SDK 層，SDK 提供完整的產(chǎn)品功能的實現(xiàn)，例如會議 SDK 能讓用戶開發(fā)出完整的會議系統(tǒng)，還有直播 SDK 對大型會議或大型直播能用這個 SDK 進行直播客戶端的開發(fā)和實現(xiàn)。剛提到的會議室大屏?xí)h系統(tǒng)，我們用 SDK 能覆蓋到這些應(yīng)用場景，除此之外還有 SIP 等等。

SDK 層之上，APP 層提供了完整的客戶端的實現(xiàn)，客戶端的桌面端也好、移動端也好甚至能通過 SDK 向第三方開放，使他們能實現(xiàn)自己的第三方客戶端。

RingCentral 產(chǎn)品提供了高質(zhì)量的音視頻體驗，技術(shù)上和很多友商是一樣的，分為很多模塊，在采集階段利用硬件的能力，在渲染和播放方面進行優(yōu)化，我們會有 AI 預(yù)處理進行一些 AI feature 的集成比如降噪、虛擬背景、編解碼器、弱網(wǎng)對抗等，我們能夠從各方面進行優(yōu)化例如性能等，通過智能路由能夠選擇最近的邊緣節(jié)點，在網(wǎng)絡(luò)層提供更好的用戶體驗。這是我們音視頻體驗方面的架構(gòu)。

說到對大型會議的支持，對于一家公司有時需要召開員工大會，特別是上萬人的公司，這時普通的會議場景是無法支撐的。我們的解決方案是基于亞馬遜服務(wù)加直播功能，主持人和小組成員在 SFU 之間交換數(shù)據(jù)，但 SFU 通過 MCU，再通過 RTMP 推流到第三方服務(wù)，之后，觀眾端通過 CDN 網(wǎng)絡(luò)能支撐超大量的用戶。我們目前能支撐到 100K 級別的用戶，同時，我們媒體內(nèi)容也受 DRM 保護，是無法通過截取 URL 或嗅探方式觀察到數(shù)據(jù)內(nèi)容。

我們對第三方的會議支持，剛提到的是 SIP 網(wǎng)關(guān)的接入。我們有一個 SIP 會議網(wǎng)關(guān)，通過在 RC 自己的終端之間，相互之間通過內(nèi)部的 SFU 或者信令服務(wù)器進行媒體的信令交互。但我們會有專門的 SIP 網(wǎng)關(guān)來對接第三方如微軟和 Zoom，它通過 SIP 信令的交互來進行協(xié)商，同時通過 BFCP 來對桌面共享等進行傳輸和支持。所以，我們目前對主流 SIP 終端支持的非常好，所以它的體驗對于弱網(wǎng)優(yōu)化等會比一般的 SIP 終端更好。

我們同時也提供端到端的加密，數(shù)據(jù)安全是非常重要的一點，很多會議內(nèi)容本身就是保密的，他們不想讓 RingCentral 知道具體內(nèi)容，默認情況下數(shù)據(jù)經(jīng)過服務(wù)器，服務(wù)器必然知道其中交流的音頻和視頻。端對端加密就是用來解決技術(shù)服務(wù)器也不一定能截獲數(shù)據(jù)。我們這是業(yè)界標準的做法，通過一個密鑰的協(xié)商服務(wù)器，只提供密鑰的交換功能，服務(wù)器本身不知道非對稱密鑰交換。同時，我們通過消息層安全協(xié)議來交換密鑰，還用 SFrame 的加密方式對視頻幀和音頻幀的每一幀進行加密。對于接收端來說，因為發(fā)送端是用公鑰來進行加密，接收端是用私鑰進行接收。對服務(wù)器來說，由于它沒有獲取私鑰，是無法獲得其中的內(nèi)容。以上是我們端對端加密方案。

對于整個系統(tǒng)來說，我們有很多 AI feature，比如實時語音翻譯，對于聽力不太好的用戶有很大的幫助，它可以實時將語音轉(zhuǎn)化為文字。再說 Presentation Mode，類似于天氣預(yù)報模式，桌面共享時用戶頭像能顯示在左下角，使體驗更好，大家既能看到你的人又能看到你共享的東西，看到你的肢體語言等等。還有會議總結(jié)，我們能自動對會議生成摘要并總結(jié)，會后能自動生成省去做筆記的麻煩。同時，我們也支持語音命令，通過命令來控制終端，避免頻繁操作。另外還有自動跟隨，比如我在來回走動，攝像頭會自動跟隨，通過軟件來實現(xiàn) AI 的狀況。當然還有很多這里就不一一列舉了。

我們還是有非常多的挑戰(zhàn)比如性能問題，我們知道 Electron 它本身作為一種框架性能是有缺陷的，內(nèi)存管理有時會達到 2 個 G，這是框架本身帶來的，即使是微軟 Teams 也會遇到類似問題，國內(nèi)的飛書也一樣。同時，我們是 Web 技術(shù)也會帶來性能損耗，特別是大量計算，如果用前端語言的話會非常耗 CPU。還有媒體處理和 AI，這些都是非常耗性能的比如虛擬背景，可能計算量非常巨大，打開這種功能明顯能看到 CPU 在飆升。對于這種問題，我們的解決方案一方面是我們深度定制 Electron 本身，特別是對內(nèi)存管理等做了很多優(yōu)化，降低損耗，另一方面涉及到高耗能計算功能的任務(wù)我們都移到 C++ 或 native 語言去，以 NodeJS 模塊的方式提供前端訪問，提高性能。如果對于某一些無法移到 native 語言的，我們會用別的方式解決性能問題。

第二個挑戰(zhàn)是媒體質(zhì)量和體驗。WebRTC 在弱網(wǎng)情況下，媒體質(zhì)量不佳，在網(wǎng)絡(luò)好的情況下大家都感覺不到，當丟包或者抖動比較嚴重的時候，視頻卡頓是非常明顯，有時可能視頻或桌面共享加載是非常緩慢的，存在呼吸效應(yīng)時而清晰時而不清晰等。我們一方面深度定制 WebRTC 本身，特別是對桌面共享，我們加了一個全新的模塊，它默認的性能是非常糟糕的，像 QoS 就完全重寫，不同場景、不同業(yè)務(wù)需求下有不同的策略來對應(yīng)，而不是統(tǒng)一的算法去 cover 所有場景。還有就是引入更好的 Codec 和算法，提供最佳的用戶體驗，比如引入 RS-FEC 來支撐抗丟包策略，這是性能方面的一種解決方案。

另外，還有對于平臺和設(shè)備的適配，WebRTC 默認在有些平臺上做的不是很到位，有些終端支持的不是很好，特別是一些安卓的設(shè)備性能本身就非常糟糕，WebRTC 默認實現(xiàn)非常耗時，對于這種設(shè)備我們一方面是改變平臺的支持比如增加對 Windows 上的 48K 音頻采集的支持，同時對不同終端引入云端配置，如果發(fā)現(xiàn)新的設(shè)備回音消除非常差，需要加入回音消除算法，可以通過遠程配置動態(tài)調(diào)整算法來支持不同設(shè)備的硬件能力。還有，在用戶體驗設(shè)計上，如果設(shè)備性能真的特別差到不能用，比如很便宜的安卓設(shè)備，當一些指標差到一定程度時，會實現(xiàn) “功能降級”，比如視頻最多顯示九個，以獲得更好的音頻體驗等。

以上是我所有的分享，謝謝。