本次LiveVideoStackCon 2020北京線下峰會我們邀請到了北京二六三企業通信有限公司技術總監李志濤來做分享。經過多年的打造，263云視頻平臺已經支持多協議、多種終端的使用場景，他將以視頻+戰略為導向，分享263運營級云視頻平臺搭建的技術迭代歷程。

大家好，我是來自北京二六三企業通信有限公司的李志濤，主要負責公司音視頻業務線的開發工作。

大家可能對263網絡通信有限公司比較陌生，用一句話概括：263深耕行業20年，做最懂企業互聯網通信的服務商。公司成立于1993年，前身是海誠尋呼。在1999年成為基礎運營商以外國內最大的撥號接入服務商。2001年，263自建機房成為國內首批四星級IDC機房。2004年，263獲得國家多方通信牌照的電信增值服務商。2005年，263推出的企業郵箱成為企業郵箱外包服務國內第一品牌。2010年，263網絡通信在深圳上市，股票代碼：002467，同年公司推出了263電話會議系統，這也是當年我們國內成長最快的遠程會議服務提供商。2015年，263收購展視互動，成為了國內當時最大的多媒體互動直播技術服務商。2018年，263獲得了國內首批移動轉售牌照，推出企業定制移動化通信服務，同年263推出了視頻+戰略。自此戰略上已經從之前的尋呼、接入、消息、郵箱、電話會議，到現在基于音視頻的實時服務提供商，做了重大戰略轉型。

接下來，我將主要從四點來介紹263音視頻這塊，以視頻+戰略為導向，技術構建方面的迭代方向。 1 263云視產品簡介

經過多年的打造，以263視頻云為基礎，支持多協議、多終端的使用場景，其中主要包括263云終端。云終端包括多款硬件終端，硬件終端主要根據企業辦公場景，針對個人參會、小型會議、中型會議、大型會議時，我們提出了多種終端的解決方案。除了會議室級別的，我們也支持任何場景、任何地域、任何時間都可以從移動端、PC端、Windows端、Mac端、iOS端、安卓端入會，進行實時音視頻會議溝通。 263視頻云對各種音視頻通信方式做了整個協議層的兼容，以WebRTC協議為主，兼容了VP8/VP9/H.264等編解碼方式，以及對多瀏覽器的兼容適配，對微軟Lync協議的接入支持。現有相當數量的企業客戶擁有大量的基于SIP和H.323協議的硬件終端，263視頻云對這些終端也做了協議支持，可以直接進行接入使用。有些客戶購買的成本比較高的思科、寶利通的硬件的MCU，我們打通了整個的視頻云來接入使用。 視頻云對我們傳統的PSTN網絡的電話會議進行了融合接入。移動電話以及座機可以通過電話會議平臺來進行音頻接入，與視頻云進行音頻的融合。視頻云的實時內容以RTMP標準協議推送到云端進行直播或點播。 1.1 能力矩陣

263視頻云系統的整個能力矩陣主要是有業務的管理系統、支撐管理、用戶管理、多業務平臺的管理、用戶認證及權限信息管理。263視頻云提供了多種視頻服務場景：會議服務是解決企業遠程辦公的；教育類服務，像大班、小班、雙師還有K12；遠程醫療服務，遠程醫療培訓講解、遠程手術等。 消息系統，主要有以下幾類消息，IM消息、應用消息、消息通知；信令中轉系統，包括語音信令、音視頻信令、調度信令。出席系統主要是解決了用戶在登入之后，對他的消息調度進行定位與管控。 實時RTC系統是我們的核心，包括WebRTC Service、Streaming Service。WebRTC Service主要接入的是用戶實時音視頻通信的Web服務和App的服務，Streaming Service主要接入的是用戶推流和直播服務。Core核心系統主要是進行整個集群的管理和調度，包括整個集群硬件可用性的管理，硬件服務器上限、下限的管理，負載均衡與失效轉移的管理，系統平行擴展的管理，根據系統負載情況進行ROOM級別的任務調度管理。基于音視頻配置進行MCU轉碼和混屏處理。SIP Service主要是解決了和外系統SIP模塊的對接，包括電話會議和基于SIP限令的第三方硬件、第三方系統。Recording 是對會議、教育、遠程醫療等業務有錄制需求的，進行按需錄制的服務。 263直播網絡，主要對接到263現有的直播系統，同時也向阿里云、騰訊云進行推流。導播臺基于推流直播時做一些導播、插播的增值服務功能。直播管理針對直播的權限、直播會場管控等進行管理。云存儲是與錄制件相關聯的，錄制件基于對象存儲方式存放在云存儲之后，可以進行相關業務需求的VOD點播。 公共應用系統有多重應用服務，調查問卷、投票、打賞等。電話會議系統以硬件會議橋為核心的PSTN會議系統。SIP MCU可以對接外系統SIP MCU或與SIP終端進行對接。 1.2 SaaS&PaaS

我們提供SaaS&PaaS的接口能力，上半部分主要是SaaS層的能力，會議類、教育類的應用，還有遠程醫療類的應用。整個系統包括消息SDK、共享SDK、標注SDK， RTC的SDK、點播SDK和直播SDK。我們也可以給有深入開發能力的客戶提供PaaS層能力的開發接口。整個調用方式是方法、函數調用，底層基于Socket或RPC形式進行通信。 2 技術架構

接下來是近幾年我們整個的技術架構的迭代的步驟。

263云視技術開源基礎基于Google開源的WebRTC和Intel開源的OWT這兩個項目。 2.1 架構拓撲V1.0

整個的技術框架是從第一代開始搭建。第一代系統，按照功能分為兩層構建，采用集群分布式部署，基本分布了4類IDC，第一層IDC是我們核心的BJ DC，第二層主要解決國內南北互聯互通，跨運營商訪問的接入問題。針對海外用戶訪問系統，我們提供了海外接入點。 到目前為止，由于對成本的考慮，不可能對全國各大城市都去布機房布節點，所以我們在用戶使用比較多的地方，布了幾個節點，其他的節點我們目前使用阿里云進行補充。我們主要使用阿里云的ECS和它的帶寬，目前就全國用戶接入263視頻云系統來說訪問阿里云的幾個節點質量還是不錯的，可以保障國內用戶使用的全覆蓋。這是我們整個系統架構拓撲的1.0系統。 1.0系統最大的問題是同區域同運營商不同IDC的交互都需要到中心節點交換，成本較高。再有數據鏈路較長，用戶延時比較大，針對RTC應用來說，正常是在400毫秒可以接受，而物理距離來回兩千公里，這個延時可觀。基于這些問題，我們開發了2.0版本。 2.2 架構拓撲V2.0

基于架構拓撲1.0的問題，我們開發了2.0版本,主要做了一個分層，加了一個Relay 池，同一區域，相同運營商，或是跨區域相同運營商的用戶訪問層之間可以互通。如果他們之間不能互通，可以通過Relay池進行互轉，這個Relay可以進行平衡擴展的。整個架構從1.0的二層變成了2.0的三層，北京IDC及Relay層IDC走的是多線BGP機房進行部署。 針對海外，基于美國、德國、歐洲、香港加了Relay層節點。用戶是基于本地進行交互的，直接從本地走，不需要到核心機房進行數據中轉，用戶的延時感受會很好。同時北京的核心機房做了高可用改造，當其中一個核心機房遭到攻擊，可以迅速進行熱備切到其他機房。 2.3 媒體信令邏輯

系統中媒體信令邏輯主要體現了三個層，背景核心層，中間的多線接入機房Relay層，還有用戶就近訪問的接入訪問層。核心邏輯OWT Core，基于Intel的OWT來進行的二次開發，主要負責整個系統的計算、管控、調度。SRC解決智能選路問題，用戶會在全球各地接入訪問，SRC負責找到一個離他訪問網絡質量最好的Access。MC系統負責服務器可用性的訪問甄別，分配負載低、運行同質業務的服務器給用戶。 3 媒體通訊模式

3.1 基本模式

目前263云視頻各方面的技術保障已經能解決一些接入訪問的質量問題，但如果一些業務場景、業務模式錯誤地使用了基本通信模式，導致流量增大、帶寬受限、服務器計算資源占用過高，網絡抖動、丟包、延遲對實時音視頻適量的影響較大等問題。上圖主要表述了WebRTC目前為止使用的幾種通信模式。第一種MESH模式，WebRTC兩個點是直連的，媒體走P2P方式進行互通。 第二種SFU與MESH之間有一些共性，區別是它把所有的媒體都經過服務器進行轉發。針對每一個客戶端，流的上行是1路，下行是n-1路。兩者劣勢基本一樣，優勢是流通過服務器進行Relay，便于混流推流直播或者其錄制操作。 第三種是基于MCU方式，MCU好處是1路上行，1路下行，客戶端耗費帶寬小，由于該種模式需要對音視頻進行Mixer混流，消耗服務器CPU及GPU的計算資源。以上幾種通信模式各有利弊，后續會講到基于不同業務使用場景而采用的基本通信方式外加混合通信方式的組合方式。 3.2 版本1.0

上圖是1.0使用的數據流程圖。Client按照業務邏輯進行音視頻的發布和訂閱，右邊是服務器，在1.0中我們同時支持MCU和SFU。我舉例了4個Access模塊，虛線代表基于UDP協議的用戶層訪問。如果用SFU模式的話，就不涉及服務器后臺的運算能力。端上使用不同的編解碼方式也會使用到服務器后臺的MCU模塊的轉碼能力，轉碼之后再進行下發客戶端。采用MCU的業務場景會到MCU模塊進行音頻和視頻的混音合屏。在這個版本中SFU缺少SVC或Simulcast的加持，所以音視頻質量不好保障。 3.3 版本1.5

我們在中間又推出了1.5版本，主要用服務器MCU合屏，客戶端屏幕剪切方式實現了用戶使用場景的靈活性。剪切完以后每一路都是可以單獨顯示，靈活布局。 3.4 版本2.0

2.0版本基于1.0版本演變而來，原有SFU增加了Simulcast功能，同時也沿用了MCU。MCU我們又做了一些功能的拓展，包括RTMP推流，RTMP推流時可以按照用戶自定義的編碼格式、自定義布局推送。可以和SIP網關打通，既可以和硬件MCU系統進行融合，也可以通過SIP網關與PSTN電話會議進行融合。 3.5Hybrid模式

這是前面提到的，我們整個系統是基于SFU和MCU這種方式來實現。SFU的優勢是靈活分發、并發高，實時性也高，劣勢是下行轉發路數多，帶寬占用高，影響體驗，客戶端維護多路連接的成本高。MCU的優勢是下行帶寬占用少，劣勢是服務器性能要求高，部署成本太高，同時增加服務器環節，實時性略差。 我們采用的混合模式是基于MCU+SFU，業務場景決定了用MCU還是SFU。如果是五方以下的，SFU優勢還是合適的，成本較低。如果是超過6方以上的，客戶的附加值高一些的話，使用MCU計算資源。交互方式決定通信模式。 4 運營級技術疊加

我們剛才講了WebRTC和OWT這塊。我們在實際使用中，根據我們遇到的弱網質量問題，優化了音視頻傳輸的NACK和FEC功能。解決音視頻唇音不同步的問題。通過切流功能，解決我們在MCU方式下用戶的各端TV端、電腦端、移動端等所希望收到不同分辨率的問題，大屏是1080P，PC端是720P，移動端可能是360P已經足夠了。同時也解決了不同的用戶根據自己的網絡質量獲取不同碼流數據的問題。 系統在跨IDC時，集群內部偶發網絡閃斷，會出現一些異常，增加了容錯機制確保系統的健壯性。數據庫方面使用了MongoDB集群，RabbitMQ消息總線使用了HAProxy+3RMQ高可用。 以上這些分享都是我們對這套系統所做的一個適合運營級的改造。

責任編輯：lq