導讀：?5G 與 AI 技術推動音視頻技術持續演進，RTC 技術在多個行業得到了充分應用，但各行業的業務有著不同的需求，因此就需要構建一套 RTC 融合通信服務系統，為產品的創新提供堅實的基礎。本次分享將重點分享：網易云信 RTC 融合通信服務架構，并結合近期熱門的娛樂社交與在線教育場景，從解決各業務場景痛點和難點切入，為大家講解 RTC 融合通信的核心技術和最佳實踐。

文｜吳桐

網易云信流媒體首席架構師

背景

?RTC 行業2021年整體發展?

這兩年 RTC 行業的迅猛發展，不管是在泛娛樂行業的云游戲、音樂、社交、語聊、直播和短視頻，還是在在線教育，都能看到增長曲線是非常可觀的。從技術發展方向上來說，RTC、直播和 VOIP 通信越來越往融合一體化方案架構上發展，各平臺也逐步推出?All in One 的解決方案，這方面的內容我會在今天分享的第二部分詳細展開；娛樂社交和在線教育的 RTC 技術不斷創新，針對各類垂直領域也涌現出很多的音視頻技術的創新方案，這些創新方案會在今天分享的第三、四部分重點闡述；我相信隨著音視頻相關需求的日益增加，未來音視頻行業還將持續高速的增長，也有著無限的機會等著音視頻行業的從業人員，有機會當然也會有挑戰。

?RTC 融合通信后端服務挑戰?

• 在融合通信系統里，需要接入各種類型的客戶端，各客戶端的協議也非常多樣，包括私有協議，以及各類標準協議，比如：WebRTC、RTMP、SIP、PSTN 和 RTSP 等等；為了解決協議接入的問題，融合通信服務端必須具備很強的協議兼容能力。

• 隨著 All in One 的推行，融合通信服務端需要承載的并發也越來越大，包括單頻道的百萬并發，以及晚高峰的的流量蜂擁，這就要求我們的系統具備很好的彈性擴縮容能力。

• 隨著全球化用戶接入，還需要面對全球范圍內復雜多變的網絡情況，包括小運營商，偏遠地區和非洲等國家的 2.5G 和 3G 網絡，以及更為復雜的跨國通話的網絡問題。
  

RTC 融合通信服務架構

?多協議融合通信 RTC 系統?

首先我們從全局的維度來看看云信是怎么做的多協議融合通信 RTC 系統的，整個架構的中間，是我們的流媒體傳輸與處理服務器，其中包括了邊緣媒體接入系統、實時傳輸網系統、流媒體處理服務系統以及直播點播服務系統。在新一代的音視頻融合通信系統中，我們除了云信 SDK 以外還支持了多種協議客戶端的接入，在邊緣媒體接入服務模塊中，我們的邊緣媒體服務器既支持云信 SDK 的接入，也直接支持了標準 Web 端使用 WebRTC 接入；另外我們自研了 SIP 網關服務器，實現了 SIP、PSTN 的接入；我們使用通用媒體網關實現了標準 RTMP 推流工具、小程序、RTSP 監控攝像頭的接入。

在邊緣媒體服務系統收到各協議客戶端的媒體數據包以后，會再通過我們實時傳輸網的邊緣節點和路由節點進行全球的實時媒體數據分發，保證端到端的最優體驗。同時利用流媒體處理服務的通用 MCU 和轉碼服務器，可以將媒體流混合以后通過旁路轉推到我們的互動直播服務器，再通過我們直播的融合 CDN 系統進行分發；還可以在云端進行錄制后，存儲到云信的點播服務系統中。

在流媒體傳輸與處理服務系統的左側是我們的全局流媒體控制服務，它包括了：頻道與流管理服務，統一媒體調度服務和實時傳輸網調度服務，他是整個音視頻融合通信系統的大腦，由它來動態控制整個系統的運轉。

在最右側，是我們的大數據與配置服務系統，它包括了我們的全局大數據分析和挖掘系統，負責全鏈路各個采集的數據處理、告警和質量透明，并利用大數據挖掘的結果指導全鏈路各模塊算法和策略的制定，另一個是我們智能全局配置管理和下發服務，它負責對我們各類云端參數的下發，包括 QoS 參數，音視頻編解碼參數以及 A/B test 的相關開關。

我們對新一代音視頻融合系統架構做個總結，首先新版音視頻融合通信系統是一個混合了實時媒體邊緣服務器、實時傳輸網以及融合 CDN 的一個多協議混合組網系統，它可以滿足用戶的各類對場景和網絡實時性的需求；第二，我們的媒體邊緣服務器和媒體網關下沉到邊緣，大大降低了用戶到第一跳接入服務的的距離，也可以更好的發揮 5G 邊緣計算的能力。

雖然我們可以靠媒體服務器級聯來實現 RTC 服務器的高并發，但是為了降低成本和提升整個系統的容量上限，最大程度的提升單臺服務器并發能力還是非常重要的。

?超高并發 RTC 媒體服務器?

為了提高服務器的性能，從充分利用多核 CPU 的角度上至少有兩種明確的方案（第三種就近年來以 golang 為主的協程方案）：多線程和多進程。云信先后使用了這兩種方案來實現云信 RTC 的媒體服務器。

單進程多線程：

首先我們來看看單進程多線程的架構，我們采用?Reuseport+IO?讀多線程的方案來實現高性能的 IO 讀，這里利用了 Linux 內核 Reuseport 的負載均衡，會根據收發四元組做負載均衡。IO 線程收到數據包以后，會將數據包投遞到后側的 Worker 多線程上進一步處理業務邏輯，信令和媒體的處理都在 Worker 多線程上。這個架構使用多線程很好的利用了多核 CPU 的能力，整體的性能在業務邏輯不復雜的階段，還是非常不錯的。但是隨著需求的演進也面臨很多問題和挑戰：

1、在業務邏輯復雜以后，多線程的架構的加鎖操作會過多，導致性能受到影響；

2、因為是單進程，而 C++程序的崩潰是一個很難不發生的問題，單進程崩潰后，影響范圍比較大；

3、多線程程序對編碼要求高，特別是很多新人對代碼不熟悉時，比較容易犯錯，而多線程的問題，往往又比較隱蔽，定位和 debug 的難度也比較大。

所以隨著項目的迭代，漸漸的我們開始針對單進程多線程的架構進一步進行了迭代。

多進程架構：

在新的架構中，我們采用了多進程的架構。Master 進程作為父進程，同時也作為其它進程的守護進程，不做其它任何復雜業務，因此 Master 進程的穩定性是比較高的。信令、媒體進程均作為 Master 進程的子進程，信令進程和媒體進程都是單進程單線程架構，大大減少了多線程加鎖的操作；所有的媒體進程只需要和信令進程交互，媒體進程相互之間無需交互。這個架構其實有點像 Nginx 的架構，架構的性能、穩定性都比較好。目前云信在全球范圍的媒體服務器都采用這種架構，系統的的穩定性得到明顯的提高。

?WE-CAN 全球組網?

看完了接入協議的多樣性和海量并發的應對方案以后，我們來解決全球范圍內節點網絡互聯問題。為了解決這個問題我們把目光轉移到音視頻融合通信服務端的另一個核心系統——云信自研的大規模分布式實時傳輸網?WE-CAN。

兩個邊緣媒體服務器在需要級聯的時候，會通過實時傳輸網的邊緣接入節點將流量導入實時傳輸網。實時傳輸網的邊緣節點根據實時傳輸網調度服務的統一調配，通過傳輸網的路由節點，將數據包以最優路徑發送到目的邊緣媒體服務器。在這個過程中實時傳輸網路由探測和計算服務是鏈路路由選擇且保證最優質量的的控制大腦。云信自研的大規模分布式實時傳輸網有四大特點：

1、低延遲：邊緣接入節點全球覆蓋，所以可以做到用戶接入超低延遲，質量可以媲美專線；

2、低成本：使用邊緣計算能力，而不是核心 BGP 機房，在降低成本的同時也保證了質量；

3、高到達：實時傳輸網路由節點的路徑規劃非常智能，在全球范圍內能做到多通道備份保證數據的高可達；

4、高可靠：實時傳輸網支持分級服務，同時多個鏈路通道可以自動快速切換，能夠在秒級做到故障隔離，保證鏈路的穩定可靠。另外相比同類產品，云信自研的大規模分布式實時傳輸網，支持了大規模級聯場景下的應用層組播技術，做到流量復用；同時還借鑒媒體服務器的分段 QoS 思路，支持分段重傳和 FEC ，保證了全鏈路的網絡傳輸質量。

另外相比同類產品，云信自研的大規模分布式實時傳輸網，支持了大規模級聯場景下的應用層組播技術，做到流量復用；同時還借鑒媒體服務器的分段 QoS 思路，支持分段重傳和 FEC，保證了全鏈路的網絡傳輸質量。

娛樂社交場景技術實戰

?ClubHouse 萬人連麥?

今年年初，由“當代鋼鐵俠”埃隆馬斯克的親自引流，為 ClubHouse 這個在線多人語音聊天的平臺引入了大批用戶，ClubHouse 由此進入了一碼難求的階段，甚至 eBay 上一個邀請碼被炒到數百美元。拋開 ClubHouse 在產品運營維度的相關內容，ClubHouse 本質上就是一個全球的語聊房，從服務端的角度來剖析它的技術難點，我認為有以下三點：全球通話、超大并發以及上麥人數不限制。其中全球通話和超大并發的技術解決方案我們在第二部分都已經涉及這里就不再贅述。這里我們重點展開聊聊上麥人數不限制。

首先，我們先分析一下上麥人數不限制有什么技術難點，我舉個相對極端的例子，一個5000人的頻道，5000人都需要開麥說話，那么這個頻道在系統里面就會有5000路上行，這時候如果服務端是一個純轉發的 SFU 服務器，就需要轉發近兩千五百萬路的音頻給所有的用戶，這個轉發的量是一個特別大的壓力；同時每個用戶的客戶端收到4999個下行語音流的時候，客戶端并不會把這些所有的聲音都進行混音播放，因為在一般理解上，一個混音里有超過3人的聲音的時候，就完全聽不清了，所以一般情況下客戶端會選擇音量最大的3~5路語音進行混音后再播放出來。可以看出來這么做的性價比是特別低的，浪費了大量的下行帶寬流量。因此合理的做法是在服務端上進行語音選路，為客戶端選出合適的語音后再轉發。

在單機里面做音頻選路其實是比較簡單的，只需要在上行的 RTP 包的擴展字段里面打上這個 RTP 包 PayLoad 部分的語音的音量信息，然后在服務器收到語音包以后經過音頻選路器，將里面的音量最高的 N 路選擇出來，當然這里也涉及歷史數據和漸入漸出等相關音頻選路算法，但是總體而言難度不大。但在一個有大規模級聯的分布式環境下來實現選路就有一定的難度了，首先我們能想到的一個簡單的方案就是在整個系統中，同一個頻道的在一個統一的服務上做音頻選路，這種方案在人數不超過1000人場景下是適用的，但是當人數越多，這臺負責整個頻道選路的服務器就會成為系統的瓶頸點，而且這臺服務器的可用性會直接影響整個系統的可用性，它成為徹徹底底的短板。那云信是如何解決這個問題的？

是因為云信采用了分布式音頻選路方案！

我們來簡單的看一下這個方案，客戶端連到邊緣媒體服務器以后，這臺邊緣媒體服務器本機收到的音頻包進入本機的上行選路器進行音頻選擇，上行選路器選擇完成以后會將選路通過的語音包交由下行選路器，同時也會同步一份給級聯的服務器，這部分數據就會進入對端媒體服務器的下行選路器，總結來說就是每臺機器的上行選路器只選直連本機的用戶的音頻包，而下行選路器需要將本機上行選路器和遠端上行選路器的結果再次選路，最終選擇出發給客戶端的數據。通過這個方案，我們最終實現了超大并發下的分布式音頻選路方案，在這套架構下整個選路系統不存在單點故障點，也就是任意一臺邊緣媒體服務器宕機不會影響音頻通話的正常進行，同時級聯的選路和下行選路也大大降低了服務器間的流量和下行客戶端的流量。當然這里還有一個點，就是選路到底應該選音量最大的幾路的問題，以我們的經驗，一般情況下3路就夠了，但是在某些特殊場景下，比如齊聲朗讀、大合唱的時候，選擇8路也足夠，因此云信將選路的路數是開放成接口讓客戶根據自己的場景來設置的。

?在線 KTV?

這兩年隨著音樂社交的不斷發展，在線 KTV 這個場景也越來越火。在線 KTV 主要是為了模擬真實 KTV 的場景，包括單人 K 歌和多人合唱。首先，我們來思考一個問題，在線 KTV 的場景和一般 RTC 場景有什么區別，其實本質上是一樣的，但是有一個技術點在線 KTV 的要求是特別嚴格的，那就是延遲和同步。

單人 K 歌

對于主播來說，主播自己在演唱的時候，看著 MV 和歌詞、聽到的伴奏開始演唱，所以主播的體驗是肯定可以做得同步的，但是觀眾側要做到 MV、伴奏、延遲以及歌詞的完全同步就有一定的技術含量了，這里其實有兩種方案來實現。

• 主播發送音視頻

方案具體細節：主播側將含有歌詞的 MV 視頻和 MV 伴奏在本地播放，同時主播開始演唱，SDK 將 MV 和 MV 伴奏使用自定義入口輸入的 SDK 引擎，同時采集麥克風的主播演唱聲音，在 SDK 引擎內部將 MV 的伴奏和主播聲音進行混音，并使用通用的音畫同步方案將MV和混合出來的聲音做同步后發送到聽眾接收端；此時聽眾接收端只需要把收到音頻和視頻按常規的播放渲染流程就能得到同步的效果了。

這個方案的明顯優勢就是：簡單、并且能做的很好的同步；但是也存在明顯的劣勢：MV 視頻是通過 RTC 的視頻流進行傳輸的，流量成本特別高，而且往往 MV 的視頻分辨率都比較高至少在720p，高分辨率的視頻也比較容易引起傳輸的擁塞，最后造成觀眾側體驗卡頓。

• 主播發送純音頻

為了應對第一種方案的問題，我們提出了第二種相對復雜的方案，如右圖。主播不需要將高清的 MV 視頻發送給對端，我們利用補充增強信息?SEI NAL，主播側將當前 MV 的播放時間戳填入到 SEI 中。

主播側的 SDK 會在引擎內部做主播演唱的語音和 SEI 的對齊，接著 SDK 把 SEI 和主播的演唱發送到聽眾側，聽眾側根據 SEI 里面時間戳信息控制 MV 的播放節奏，這樣就可以做到同步了，通過這個方案可以就大大減少了視頻的流量。當然這個方案在聽眾側 MV 的播放控制方面也有一定的實現難度，需要深入到播放器的內核。總結來說這兩個方案也各有優劣吧，各位同學可以按需選擇。

多人合唱

其實多人 K 歌這幾年也有多套方案在演進，早期的方案存在主播無法聽到合唱者的聲音等眾多問題。隨著音視頻技術的不斷迭代進步，云信解決了多人合唱最核心的兩大問題，全球時間戳精準同步和端到端的延遲控制；端到端的延遲控制，不僅涉及端語音采集播放的低延時處理，還涉及了全球范圍內全鏈路端到端的延遲要控制在?70ms?以內。這里利用了?WE-CAN，分段 QoS?等多種手段。

而全球時間戳精準同步，云信自研了利用 WE-CAN 的分布式 NTP 對時系統，讓全球所有的邊緣媒體服務器的 NTP 時間都能做到1ms?內的誤差，這樣所有的主播、合唱者和聽眾再和邊緣媒體服務器進行高精度時間戳同步，就能做到在全球范圍內超高精度同步，目前云信的時間戳同步能做主播和合唱者 的1ms 誤差。有了這樣的技術解決方案，主播與合唱者就只需要在同步的開始在本地播放伴奏，然后演唱就可以做到很好的多人合唱體驗了。

?元宇宙——Metaverse?

?“元宇宙”一詞源自90年代的一本科幻小說，它指的是現實中的人可以在一個沉浸式的虛擬世界中，使用數字化的特定身份相互交流，獲得互動體驗。2021年被大家稱為元宇宙元年，我相信大家或多或少都聽說過，特別是在《頭號玩家》電影里面大家也都體驗過了那種在虛擬世界里面體驗人生的感覺。從 RTC 技術的挑戰的角度，我簡單提幾個點：

VR、AR 技術是元宇宙的核心基礎，這幾年 VR 與 RTC 的結合業界已經有很多探索，核心要解決超高清視頻和超低延遲，對于超高清 8K 及以上分辨率的視頻非常依賴高性能視頻編解碼技術和底層硬件的支持；而超低延遲除了需要傳輸協議層面和 QoS 做相關優化，也依賴 5G 乃至 6G 的底層通信技術；另外，為了讓大家在元宇宙的世界中有身臨其境的感覺 RTC 里面需要 3D 立體音，另外前面我們提到的大房間音頻選路，在元宇宙里面還需要在服務端上實現根據距離的音頻選路。

上面這幅圖是游戲公司 Beamable 的創始人近期發表解析的元宇宙文章里的配圖，他從結構化方向上深度解析了元宇宙7層價值鏈，感興趣的同學可以進一步的去了解一下。

元宇宙價值鏈包括七個層面：體驗（Experience）；發現（Discovery）；創作者經濟（Creator economy）；空間計算（Spatial Computing）；去中心化（Decentralizition）；人機交互（Human Interface）；基礎設施（Infrastructure）。

在線教育場景技術實戰

大家應該都知道今年因為“雙減”政策對在線教育公司有不少影響，但是在線教育的場景這幾年是一直推著 RTC 技術不斷往前的迭代優化的。在這一部分，我會與大家分享小班課、大班課還有超級小班課的技術實戰。

?在線教育小班課的優質體驗?

在線教育的小班課作為音視頻場景里面相對復雜的一個場景，其實需要面臨的挑戰很多，小班課中各個終端的觀看需求不同、網絡情況也各不相同。因此為了做好小班課的體驗，我們需要有一個完善的發布訂閱系統，同時配合好服務端的智能選擇，這依賴于服務器上的一套智能碼率分配以及碼流選擇算法；另一個核心功能是要實現服務器的分段 QoS，所謂分段 QoS 就是在服務器上需要分別針對用戶到服務器的上行鏈路和服務器到用戶的下行鏈路做好 QoS 保障，當然對于服務器來說核心是要做好下行的帶寬估計、擁塞控制和弱網對抗。

為了做好自動適配下行帶寬，首先針對每個上行用戶和下行用戶需要分別估算他們的上行和下行可用帶寬，這里涉及到分段帶寬估計以及帶寬估計算法的優化，云信在融合了 GCC 和 BBR 算法優勢的基礎上研發了自己的發送側帶寬估計算法，該算法帶寬估計準確度能做到95%。在估算到準確帶寬以后，為了適配下行帶寬，我們使用了各類策略包括：

1、最基礎的是基于大小流（simuclast）的選流策略，發送端發送不同分辨率的視頻流到服務器上，服務器根據下行帶寬情況，選擇相匹配的分辨率發送給各個下行客戶端；

2、云信實現了基于 SVC 時域分層的選流策略，再結合大小流，就能提供更精細的碼率分配策略；

3、除了碼率選擇，云信還在系統中提供了基于優先級的帶寬分配策略，特別是會議和在線教育場景，主講者的優先級明顯高于其他參會者，這時候就設置主講者為高優先級，那么下行策略就會優先把更多帶寬留給主講者，保證大家看到主講者的畫面是最優的；

4、基于 TopN 的帶寬反饋策略，在默認情況下我們會盡量保證多數用戶都能看到高清的畫面，這個時候會適當壓制上行的碼率，以匹配 TopN 的客戶，N 是可配參數。

通過上訴手段我們就能保證在服務端上，為所有用戶決策出最佳匹配當前下行網絡狀態的碼流分配結果。

低延時大班課的平衡之道?

當前，大班課絕大多數都是通過傳統的直播解決方案實現的。傳統方案采用基于??TCP 協議的 CDN 直播，盡管經過了多年發展和改進，但由于 TCP 協議本身的特性決定了它在實時流媒體領域的固有問題是很難攻克的，這就導致了延遲高、弱網抗性差等問題，直接影響了學生的用戶體驗。而 RTC 方案雖能解決上述問題，但其高昂的成本讓人“又愛又恨”，也讓眾多平臺望而卻步。所謂的平衡之道，其實就是要在效果（也就是清晰度、端到端延時、流暢度）與成本間去找到二者之間的平衡點。

為了實現低延時大班課的平衡之道， 我們實現了低延時直播。

在推流端支持第三個推流工具和云信推流 SDK，將流用?RTMP 或者云信的私有協議推到媒體邊緣加速服務器，對于開通了低延時功能的會通過 WE-CAN 大網進行高效分發，否則就通過融合 CDN 分發。WE-CAN 針對低延時直播的流做了全鏈路的延時優化，相比于 CDN 直播?4s?以上的延遲，低延時直播可以將延時控制在0.6~1.2s。另外，低延時直播也復用了部分 RTC 的弱網對抗和首屏優化技術，可以將首屏控制在500ms 以內；我們實際測試，在30%的丟包的場景下基于傳統 CDN 基本上已經不可用了，而低延時直播還是非常流暢。通過各類技術保障，其實就是讓用戶用 CDN 的價格體驗到了 RTC 的效果。

?超級小班課場景落地?

在在線教育的領域，優質的老師資源一直是稀缺資源，因此很多教育場景使用了直播大班的方案來最大化利用優質教師的內容，但是直播大班課相比與小班課也有一個弊端就是學生的互動體驗較差，為了解決這個問題云信提出了超級小班課方案。

它就是直播大班與互動小班的合體，即：一名主講老師面向數萬名學生進行直播授課，學生被分成若干個小班，在小班內與老師、班內其他同學進行互動，同時還可以安排多名助教分別進入多個小班，助教負責管理小班內課堂秩序和輔助教學。通過該方案就完美了平衡了名師資源和學生互動的問題。

超級小班課的技術要點，我們分別需要實現聊天室的超級小班能力以及音視頻的超級小班能力。

對于?IM 聊天室，核心技術是 IM 聊天室標簽功能——靈活地支持聊天室消息定向收發、聊天室權限定向管理、聊天室成員定向查詢等個性化功能，分組互動。而對于音視頻，核心技術有兩個：

1、跨房間連麥，這個在今天分享第二部分提到，云信的媒體服務器是以流的作為管理單元而不是以房間作為管理單元，那么實現跨房間連麥時，就非常方便；

2、加入多房間，客戶端需要支持同時加入多房間，這樣學生就可以同時加入老師的大班課和互動小班兩個房間；

云信通過這些 IM 和音視頻的底層能力，完美的解決了超級小班課的痛點，也為多個在線教育平臺提供了超級小班的能力。

RTC 數據驅動

大家都知道現在是一個大數據時代，我認為做好大數據驅動對于音視頻技術持續演進來說極其重要。

為了做好大數據驅動，我們從?SDK、引擎、調度服務器、頻道與流管理服務器、邊緣媒體服務器、實時傳輸網，也就是音視頻業務的每一個環節都做了數據采集上報。我們上報了100+的關鍵事件，這些事件包括了用戶行為，各系統行為，QoS 行為，還有很多的音視頻 QoE 體驗相關的關鍵事件，比如：分辨率切換、登錄耗時、出圖時間等等；還上報了300+的核心指標，這些指標包括：全鏈路的系統運行時狀態，QoS 指標，QoE 指標以及服務端狀態。這些上報的數據都會經由我們大數據平臺進行處理，日均有百億行的數據，有 T 級的存儲。利用我們的高性能大數據平臺，我們可以秒級的實時處理這些數據。有了這些數據以后，我們可以驅動很多事情，包括質量透明平臺（對用戶開放）、業務質量報表、產出接入調度優化、大網路由優化、QoS 算法優化、QoE 故障實時告警、各維度聚合質量分析。云信新一代音視頻，就是在源源不斷的大數據驅動下，不斷打磨，提升自身的質量。

展望

最后來對 RTC 技術做個簡單的展望，同時也是我個人比較關注的幾的技術方向，我認為：低成本 RTC 會成為業界一個標配，低成本體現在兩個方面：接入低成本和費用低成本， RTC 的接入會像現在 CDN 接入這么簡單，而價格也會匹配目前 CDN 的價格，RTC-CDN 應該會在未來幾年內到來；而未來的音視頻編解碼還是會斷的迭代創新：比如視頻編碼器 AV1 和基于 AI 的音頻編器 SoundStream，未來肯定還會涌現出更多優秀的音視頻編解碼器；對于 Web 技術：我個人比較關注?Webtransport 和 WebCodec，我相信 Webtransport 會大大優化 Web 端的傳輸方式，而 WebRTC 的 Next Version 會開放更多 low level 的底層接口，也會讓 WebRTC 的使用更加靈活，值得大家保持持續關注；AI 與大數據挖掘技術，肯定會不斷在 RTC 領域中發揮重要作用。

我堅信技術的進步是永無止境的，同時技術也是可以改變世界的，音視頻領域未來還有無限可能的！

?作者簡介?

吳桐，網易云信流媒體首席架構師，網易多媒體開發專家。2013年從浙江大學碩士畢業后加入網易，現任網易云信云平臺技術負責人、在線教育行業線負責人，全面負責實時音視頻、互動白板、低延時直播、互動直播、WE-CAN 全球傳輸網等項目的架構設計與研發，對音視頻、高性能服務器以及網絡傳輸等領域均有多年的工作與項目經驗。

總結

以上是生活随笔為你收集整理的RTC 融合通信服务架构与场景应用 | 2021稀土开发者大会音视频专场的全部內容，希望文章能夠幫你解決所遇到的問題。

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