Labs 導讀

音視頻通話是實時通信(Real Time Communication, RTC)業務的主要應用場景，也是人與人之間溝通交流的重要方式，伴隨著運營商與互聯網廠商近二十年的競合博弈，人們得以便捷地享受到各類形式的語音或視頻交互應用服務。語音通話作為運營商的重要業務，逐步被互聯網OTT應用沖擊，近些年來也出現了通話量負增長的現象;針對視頻互動通話，互聯網廠商推出的各類軟件應用在低廉資費、功能豐富等方面更是處于領先地位。發展大勢中互聯網廠商不斷將運營商管道化，特別在近兩年來互動直播、視頻會議等應用快速發展的背景下，互聯網廠商也不斷在建設自己的音視頻網絡，將業務打入了運營商的腹地，逐步“旁路化”運營商的用戶流量。俗話說“要致富，先修路”，而在音視頻信息高速公路建設這條賽道上，擁有一張穩定、高性能的底層音視頻傳輸網絡，是上層應用的構建基礎，也是獲得用戶青睞的關鍵因素。

1、同樣的業務形態，不同的底層實現

互聯網許多應用都可以為用戶提供了語音通話、視頻互動等實時通信功能，但與運營商傳統通話業務相比，兩者基于不同的技術棧。例如，互聯網廠商從開始就基于VoIP(Voice over Internet Protocol)開發產品，而運營商從最初的大哥大時代模擬通話到后來的數字通話、從電路交換再到分組交換，底層技術經歷了巨大的改變和發展。從圖1概括了經典語音業務兩類服務者不同的技術實現。 

例如，以語音業務的承載方式為例，早期運營商以時分復用技術承載語音業務，包括移動通信2/3G時代的電路域，以及固定電話接入的公共交換電話網(Public switched telephone network，PSTN)，資源按時隙獨占的方式最大程度保證通話的質量;但隨著通信和互聯網技術的發展與融合，4G時代采納了完全基于IP分組交換來承載數據傳輸的IMS方案，建立專門承載運營商語音業務的IMS網絡，提高資源的利用率。運營商雖然目前也采納IP承載語音業務，但與互聯網廠商仍有本質區別：

• IMS建設獨立于Internet互聯網，通過標識區分語音和數據業務，雖然都基于IP接入，但轉發至IMS網絡的語音業務能夠通過QoS保證通話質量，相比之下，互聯網提供商的APP則需要走公共互聯網，與其他互聯網數據業務競爭網絡傳輸資源;
• 運營商語音通話不需要額外的APP，通過手機終端的撥號功能直接發起通話，是最便捷的觸點入口，而互聯網廠商提供語音服務則必須研發不同的APP。

2、運營商RTC通信

運營商RTC通信主要是通過運營商建立的通信網基礎設施承載語音和視頻業務，包括個人座機和手機等終端形態。隨著移動通信技術的發展，人們日常生活多以手機終端作為媒介聯絡他人。個人座機通過固網PSTN通信場景已經漸漸從個人日常生活中沒落，更多存在于企業客戶場景下，而移動通信技術的高速發展，除了保證基礎電話業務外，互聯網數據服務的發展，造就了近十年來互聯網各類應用井噴式發展的盛世。

運營商RTC最初的業務形態主要針對電話場景，早期2/3G仍采用電路交換，即常說的CS(Circuit Switching)域;4G LTE和目前正在建設的5G SA獨立組網架構，都會采用IP分組交換的方式通過IMS提供服務，實際上通過IP可以提供語音和視頻兩種業務形態，但受限于對手機終端硬件的型號要求和資費問題，運營商的視頻通話業務一直沒有廣泛普及，目前基于運營商網絡提供的RTC通信服務基本上都是語音業務。基于4G的語音解決方案稱作VoLTE，5G則稱為VoNR，但相同點都會采用IMS、圖2展示了4G VoLTE中IMS系統和CS域回落主要的業務流程和網絡體系，方便讀者理解數據傳輸形式的演進。 

LTE包含4G接入和核心網的關鍵網元;CS域則表示了早期使用電路交換的2G/3G通話，數據傳輸采用資源獨占的形式，有別于基于IP盡力而為的分組交換網絡;而IMS網絡中包括了P/I/S-CSCF、HSS、PCRF、MGCF等核心網元，數據的傳輸采用IP分組交換。

在4G VoLTE業務全面部署開通之前，IP分組交換與CS域電路交換傳輸方式并存，IMS網絡中MGCF(Media Gateway Control Function，媒體網關控制功能)用于IMS域與CS域的互通，負責完成控制面信令的互通，并通過媒體網關MGW(Media Gateway)連接4G核心網用戶面數據網關PGW(PDN Gateway)，實現與CS域之間的轉換，達到4G與2/3G語音互通的目的，也就是VoLTE回落至2/3G通話，稱為電路域回退(CS Fallback, CSFB)。用戶直觀的體驗就是打電話與手機上網玩游戲、發微信消息等不可兼得，在IMS建設之前，運營商視角里的語音通話和數據上網是走兩條截然不同的道路。

但隨著VoLTE(LTE+IMS)普及開來，以及5G VoNR緊鑼密鼓地建設發展，電路域傳輸逐步被弱化，運營商在實時通信領域上的電路域回退(CSFB)、語音與流量上網不可兼得的情況早已成為過去。同時，2G/3G退網重耕優質頻譜資源的呼聲也越來越高，這都得益于采用IP分組交換的IMS，使得手機電話與互聯網應用的數據在底層都基于IP傳輸，網關處只需要標識出業務類型，就可讓通話業務走IMS對應的傳輸通路，流量數據通過網關傳入外部互聯網。以圖2為例的IMS主要包括如下核心網元：

（1）HSS(Home Subscriber Server)，歸屬用戶服務器，統一存儲用戶數據，處理IMS網絡中呼叫控制網元對用戶的數據訪問，還通過開通接口接收并響應BOSS業務開通指令;

（2）CSCF ( Call Session Control Function ) ，會話控制和路由，也是整個IMS域的核心，用于處理IMS網絡中主要的控制層數據，進一步又細分為P/I/S/E四種網元，其中：

• P-CSCF：Proxy CSCF，代理CSCF，是IMS拜訪網絡的統一入口點，功能上提供注冊鑒權、信令保護、信令壓縮、媒體授權、QoS控制、信令路由(如SIP協議)、緊急呼叫、漫游計費等功能，主要負責控制信令相關的傳輸，與I-CSCF/S-CSCF側配合完成呼叫的接續處理;此外，在物理部署層面，P-CSCF 可以在統一的會話邊界控制器(Session Border Controller，SBC)設備上實現，同時結合 IMS-ALG/IMS-AGW(IMS Application Level Gateway/IMS Access Gateway，又可簡寫為ATCF/ATGW)分別提供通話業務的控制/媒體流層面的數據交互;
• I-CSCF：Interrogating CSCF，提供S-CSCF指派、路由查詢功能，在 IMS 注冊時，詢問 HSS 以確定哪個合適的 S-CSCF 路由注冊請求，對于來自P-CSCF的移動終端呼叫，詢問 HSS 以確定用戶注冊到哪個 S-CSCF;
• S-CSCF：Serving CSCF，提供會話建立、會話拆除、會話控制和路由功能,為在其控制下的所有會話生成用于計費的記錄、充當SIP協議的注冊服務器，并通過HSS 查詢適用的訂戶配置文件，處理涉及這些端點后續的呼叫流程。
• E-CSCF：Emergency CSCF，從P-CSCF接受緊急會話建立請求，并完成用戶接入位置信息查詢和緊急呼叫路由等功能。

上述功能分類說明了CSCF網元的邏輯功能，在物理部署層面，P-CSCF與IMS-ALG/IMS-AGW可以合設為同一物理設備，P-CSCF處理IMS呼叫控制層面信令等數據， IMS-ALG/IMS-AGW完成用戶層面媒體流數據的控制/轉發等功能。此外，CSCF除了實現SIP協議完成會話的控制和通話媒體流建立功能之外，還使用Diameter協議完成與核心網和IMS其他網元(如MME、HSS、PCRF等)簽約及鑒權、計費信息等數據信息的傳遞，如P-CSCF通過Diameter Rx接口連接，完成對用戶數據報文的策略和計費控制。

（3）TAS：Telephony Application Server，是運營商核心網絡中用于提供電話應用和附加多媒體功能等功能。

目前，4G VoLTE基本已經全面商用，另正在建設的5G VoNR中，仍將采用IMS實現對多媒體RTC通信服務的IP承載，特別是5G新通話等應用探索IMS數據通道傳遞新型業務數據，此處不再贅述。IMS的發展，讓運營商RTC服務與數據接入互聯網Internet可以共享同樣的IP接入和承載網絡，但在業務類型層面，IMS網絡與用戶上網連接Internet又是互相隔離。此外，IMS作為一張專網，全球移動運營商的IMS網絡又是互聯互通的，因此IMS也是一個全球范圍的網絡，但與互聯網廠商通過Internet提供RTC通信服務相比，IMS網絡的路由優化與可靠性的保證遠優于Internet。

總之，運營商RTC使用IMS承載業務，一般采用SIP協議互通，網絡架構需遵循3GPP等規范開發產品，同時，由于運營商的網絡基本交由各家廠商建設，除考慮兼容性外，在個性化功能定制方面往往受限于各個廠家的支持，并不是只是運營商自己的一局游戲，需要各方都遵循規范、開放互通，研發和推廣周期一般較長。

3、互聯網RTC通信

相比運營商，互聯網RTC通信建立在運營商建立的基礎設施通路之上，一般在專注于應用產品，各個廠商都會研發自己的APP，頭部互聯網玩家為了保證用戶體驗，還會建設大量的IDC機房為用戶提供就近接入等優質服務，或者形成云化產品/解決方案賣給小型企業。由于各大互聯網廠商的應用都運行在公共互聯網Internet之上，因此從一開始就是采用VoIP的方案，憑借各家企業對編碼、網絡傳輸、部署架構等方面的優化，也能夠為用戶提供高質量的互聯網語音通話服務，目前用戶更傾向于使用互聯網產品進行視頻通話、遠程會議或視頻互動等功能，如阿里云、聲網、騰訊云、字節火山引擎等，相比之下，運營商RTC通信服務在諸如此類方面就要落后于互聯網RTC通信服務商。兩者整體區別如圖3所示。 

在4G VoLTE/5G VoNR方案下，用戶直接用手機撥號接入的運營商RTC語音(多媒體)業務將由核心網直接轉發至IMS相關網元/設備，而數據(流量)業務直接通過互聯網傳輸給對應廠商，在此場景下運營商只是充當了用戶的移動接入和數據傳輸的管道職能，具體業務由不同的互聯網廠商進行處理。

互聯網RTC產品的研發相較于運營商而言，可以針對應用場景自行設計私有通信協議或基于通用協議進行定制，在應用層設計產品架構提供PaaS或SaaS服務，開發周期相對較短，但入口只能從APP或H5發起。例如微信語音、視頻等功能，租用好各大運營商的接入線路，只要運營商的Internet線路暢通，通話雙方就可以建立通話連接。而運營商RTC通信經由不同運營商的IMS網絡控制，在跨運營商發起通話時，跨網通信經常需解決兼容性等問題。因此，基于互聯網廠商的RTC產品往往在產品功能豐富、交付時長短等方面具有天然優勢，用戶也習慣了使用互聯網產品。 

提供RTC服務的互聯網廠商一般采用私有協議提供音視頻能力，或采用近幾年備受歡迎的WebRTC協議建設自己的音視頻網絡。互聯網通信包括即時通訊(Instant Messaging, IM)和RTC兩種類型，前者主要包括文字聊天、語音消息發送、文件傳輸、音視頻播放等應用場景，強調消息的可靠性和送達率;后者場景包括語音、視頻電話會議、網絡電話等，強調低延時和接通率，也是本文討論的重點內容。

早期互聯網RTC產品，采用IP傳輸實現語音通話與多媒體會議的功能，即VoIP。從廣義上講，運營商VoLTE和VoNR也屬于IP多媒體通信范疇，但數據不通過公共互聯網。VoIP已經有二十多年的發展歷程，早在1995年VocalTec公司推出了第一款VoIP電話軟件，其基于Internet傳輸語音服務，是現在所有互聯網RTC產品的雛形。1999年，GIPS的誕生為互聯網通信提供了發動機，對整個VoIP產生了巨大的影響。2003年前后，GIPS向Skype、Webex以及QQ提供了GIPS引擎，并于2011年被谷歌收購，隨后項目開源，即廣為人知的WebRTC開源項目，現在被廣泛應用于互聯網RTC產品中。

國內騰訊是較早提供互聯網RTC產品的公司之一，在音視頻實時通信領域有著深厚的技術積累，QQ也是國內較早并廣受歡迎提供VoIP服務的產品。QQ 音視頻起初使用 GIPS 公司的產品，后來就轉為自研路線，誕生出了TRAE 引擎(QQ)、OpenSDK引擎和XCAST引擎(騰訊會議)。與今日廠商廣泛直接采用WebRTC技術棧實現音視頻網絡不同，騰訊在WebRTC項目開源之前就在音視頻領域有著廣泛的研究，基本采用騰訊自研的音視頻引擎提供服務，如圖5所示。 

由于GIPS引擎對互聯網VoIP產品有著深遠影響，被谷歌收購開源為WebRTC項目后就被眾多RTC廠商廣泛采納，騰訊也順應潮流在微信小程序中支持了WebRTC技術(如圖6所示)，通過轉碼服務器對接其他騰訊系XCAST產品，此外，XCAST對外還兼容其他廠商的WebRTC產品。 

[[419296]]

除騰訊部分產品外，阿里云、聲網、字節跳動等音視頻領域的互聯網廠商在RTC場景下的產品研發，基本都采用WebRTC作為音視頻網絡的基礎協議。下面簡述WebRTC協議。

WebRTC協議簡述

WebRTC，名稱源自網頁實時通信(Web Real-Time Communication)的縮寫，是一項實時通訊技術，在不借助中間媒介的情況下，建立瀏覽器或手機應用之間點對點(Peer-to-Peer)的連接，實現視頻流和(或)音頻流或者其他任意數據的傳輸，支持實時語音對話或視頻對話。它是谷歌收購的GIPS項目和libjingle項目融合而成，其中GIPS部分主要提供媒體的處理的功能，libjingle項目部分主要提供P2P傳輸部分的功能，并于2011年5月開放了工程的源代碼，與相關機構 IETF 和 W3C 制定行業標準，組成了現有的 WebRTC 項目，在行業內得到了廣泛的支持和應用。需要注意的是，WebRTC是RTC應用場景下的協議，不能與RTC直接劃等號。圖7展示了WebRTC的協議棧設計。 

圖7. WebRTC協議棧設計 

圖7右側為基于TCP的可靠傳輸部分，可以建立WebSocket等連接實現信令(如SIP等)的可靠傳輸或使用HTTP協議傳輸業務數據，WebRTC 核心關于音視頻相關的協議在圖例左側基于 UDP 基礎上搭建起來的，提供的API主要包括音視頻抓取、音視頻流通道和數據通道等。其中：

• ICE、STUN、TURN 用于NAT穿透, 解決了獲取與綁定外網映射地址，以及 keep alive 機制;DTLS 用于對傳輸內容進行加密，可以看做是 UDP 版的 TLS。
• SRTP 與 SRTCP 是對媒體數據的封裝與傳輸控制協議。
• SCTP 流控制傳輸協議，提供類似 TCP 的特性，在 WebRTC 里基于 DTLS 和UDP協議之上。
• RTCPeerConnection 用來建立和維護端到端連接，并提供高效的音視頻流傳輸;RTCDataChannel 用來支持端到端的任意二進制數據傳輸，例如文字聊天內容等。

總之，WebRTC可通過getUserMedia(獲得用戶設備的攝像頭及話筒視頻、音頻的媒體流)、RTCPeerConnection、RTCDataChannel面向Web開發者提供應用開發接口，實現功能豐富的Web應用;向下針對音視頻的編解碼、傳輸等底層技術，廠商可以自行進行優化，如支持不同的編解碼協議。各大主流瀏覽器內核目前基本都支持了WebRTC，安卓和iOS應用也可以集成使用WebRTC與其他移動設備或PC端Web應用建立音視頻通信。

但是，在控制層面WebRTC沒有指明特定的信令協議，旨在最大限度地提高與已有技術的兼容性，可以與已有的系統進行對接。目前已經有企業在探索SIP/PSTN與WebRTC互通的系統，如音視頻會議對接SIP/PSTN音視頻通話、企業內部APP移動工作臺(智能辦公電話)等場景，因此，WebRTC已不僅限于互聯網音視頻領域，還可以通過信令交互和代理的模式，打通應用App與傳統移動電話網絡的通路。

WebRTC作為一個天生的P2P通話協議，為什么各大互聯網廠商都在建設基于WebRTC的音視頻網絡?其中比較重要的原因是RTC服務提供商為了能夠為用戶提供就近接入的服務，最大程度降低端端時延，并且提高統一通話線路(房間)內可同時互動的人數。

回顧WebRTC的協議棧，在媒體流數據轉發層面，P2P是其一個典型的特征，終端之間形成兩兩互聯的網狀結構，即Mesh方案。但在實際中，Mesh方案往往只做理論對比，針對終端的性能和帶寬要求都很高，并不會真正使用，因此，往往需要服務提供商建立音視頻媒體流的傳輸分發網絡作為中繼，MCU(MultiPoint Control Unit)和SFU(Selective Forwarding Unit)是兩種較為常見的中繼方案，如圖8所示。 

MCU 不僅接收每個共享端的音視頻流，還會經過解碼并把解碼后的音視頻進行混流、重新編碼，之后再將混好的音視頻流發送給房間里的所有人，最終每個端側只有一條上行通路和一條下行通路，因此，所有人看到的都是經過服務器混流后相同的一路畫面，用戶體驗較好。但對服務器而言，性能要求較高，不僅需要進行數據轉發，還要進行媒體流的編解碼處理，對 CPU等硬件資源的消耗很大，圖9展示了MCU服務器涉及的工作流。 

相比之下，SFU的功能更像一個“媒體流路由器”，基本功能包括媒體流的轉發和選路等功能。圖8只示意了SFU基本原理，各端除了一條上行通路外，還需要多路下行通道同步來自其他端側的媒體流信息。實際上，SFU服務器可以通過兩兩級聯的方式靈活組網，形成跨區域的媒體流傳輸分發網絡，可以為用戶提供就近接入的服務，然后通過最優路徑的選取進行媒體流轉發，最大程度降低端端時延。由于SFU多下行的設計，多人RTC進行音視頻通話時，多路視頻可能會出現不同步，且對下行帶寬的要求也較高。圖10展示了SFU服務器的工作流程，包括接收、選路和轉發。 

基于SFU還有Simulcast模式和SVC(Scalable Video Coding)編碼模式，前者由發送端推送多路不同分辨率的視頻流，由下行接收端適配網絡狀況拉取不同分辨率的數據流，例如，在多方RTC通話(如視頻會議、直播等)場景下，推流端發送360P/720P/1080P三路不同分辨率的視頻流，接收端可基于對網絡狀況的測量選擇性拉取不同分辨率的視頻流;后者則是采用SVC編碼格式，可通俗理解為將視頻劃分為自底向上的層級結構，越靠上層畫面越清晰，相應需要帶寬也越大，因此，接收端可以根據自身網絡狀況選擇不同的視頻分層進行拉流呈現。

此外，基于微服務的設計理念，SFU還可以配合編轉碼、混流等外接服務，選擇性地插拔額外功能，較為靈活，因此，也是當前互聯網廠商建設音視頻網絡時廣泛采用的方案。無論是SFU還是MCU，在WebRTC協議棧下，最核心的特點是服務器把自己 “偽裝” 成了一個 WebRTC的Peer客戶端，并且服務器一般擁有可達的公網地址，因此，在與端側建立連接時，P2P打洞建連流程也可以大大簡化。

4、從終端到服務

基于上述，用戶使用移動終端使用運營商或互聯網公司的RTC產品時，數據流向如圖11所示，其中主要包括了互聯網產品移動接入的場景，固網接入與移動場景類似，不再單獨說明。 

在OTT平面，圖11主要介紹了以WebRTC SFU組網為代表RTC產品的部署方案。相較于運營商，不同的互聯網公司會根據自身情況，酌情在全國范圍內搭建機房節點，通過購買不同運營商的底層接入專線，讓不同區域內的用戶能夠根據位置就近接入OTT廠商自建的音視頻網絡。與其他互聯網類產品類似，互聯網廠商自建音視頻網絡，仍是運行在運營商建設的數據網絡之上。但是，互聯網雖然是開放互聯的，但是互聯網RTC應用卻是相對封閉的，不同互聯網RTC類產品，會經過用戶終端APP入口，然后通過運營商的接入網傳輸到核心網，最終出口到互聯網后到達對應服務提供商的音視頻應用機房內，整條鏈路以公司為單位，鮮有不同互聯網公司之間的音視頻網絡能夠互通。

在運營商平面，4G/5G 通話類業務都已IP化，通過分組交換的方式互聯互通。隨著IMS網絡不斷升級演進，無論是4G VoLTE，還是5G VoNR，IMS已然是媒體類應用的控制/用戶面數據流的承載體，特別是5G VoNR持續發展的當下，IMS有望承載更多各類的新型業務，如AR通話、實時3D通信等5G新通話類業務。與互聯網OTT平面不同的是，不同運營商之間能夠且必須做到互聯互通，例如移動號碼必須能夠打通聯通和電信的號碼，在具體實施時，不同IMS網絡的TrGW(Transition Gateway)網關通過Izi接口交換彼此的RTC通話媒體流，從而實現IMS網絡的在運營商平面內的互聯。從這一點上講，運營商平面的RTC基礎設施比互聯網廠商各自為政的RTC音視頻網絡更加開放一些。

此外，由于本質上都采用了IP分組交換，大多數互聯網廠商基于WebRTC協議自建音視頻網絡和運營商IMS專網之間的互聯互通，已經在標準組織內進行討論， 3GPP關于IMS與WebRTC技術結合的標準已經出臺，也體現出來通信網與互聯網融合的大趨勢。

5、小結

本文主要介紹了互聯網廠商與運營商在RTC領域的異同，重點包括運營商IMS網絡、互聯網廠商音視頻網絡(重點圍繞WebRTC協議)等內容。后續將探討運營商與互聯網廠商在RTC領域如何互惠互利。

參考文獻

[1] VoLTE Service Description and Implementation Guidelines. Version 1.1. 2014.

[2] 「電信RTC通信」vs「互聯網RTC通信」.

[3] WebRTC access to IMS - network-based architecture. 3GPP TR 23.228 Annex U.

[4] 馬澤芳,馬瑞濤.IMS網間互通架構演進及網內實施方案[J].郵電設計技術,2020(09):61-65.

[5] ETSI TS 123 334 V10.2.0.