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

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

文 / 何必蒼

整理 / LiveVideoStack

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

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

1、個(gè)人及公司介紹

按照慣例，我先簡(jiǎn)單介紹下我自己以及公司。

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

國內(nèi)認(rèn)識(shí) RingCentral 的人可能不多，實(shí)際上我們是一家全球領(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)者，可以說是非常不簡(jiǎn)單了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面我們重點(diǎn)講基于 WebRTC 的解決方案及挑戰(zhàn)，因?yàn)檫@是目前的先進(jìn)廠商的主流選擇。

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

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

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

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

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

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

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

5、RingCentral 解決之道

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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