[TOC] 轉載文章 ## webrtc的概念可以有三個角度去解釋： （1）.一個W3C和IETF制定的標準，約定了Web間實時音視頻通信機制，通過該標準可開發基于瀏覽器的、無插件的web多媒體應用（一般是js），該標準僅設定了點對點無中心的實時會話場景，沒有強制約束信令協議與內容，沒有要求有媒體處理的中心服務器，主要目標是形成開發者與瀏覽器廠商良好的生態環境，并積極向HTML5靠攏爭取被納入進去； （2）.一群音視頻算法和網絡適應性算法，這些算法囊括了視頻會議幾乎所有的核心技術，包括音視頻的采集、編解碼、網絡傳輸、播放顯示、安全等功能，還提供了操作系統系統調用跨平臺封裝的實現，包含Windows，Linux，Mac，Android，iOS； （3）.一個開源工程，核心由c++實現，可通過修改、封裝、提取代碼等方式實現一套視頻會議系統，客戶端可實現為Web js、App或Windows應用程序等多種形式，服務端可實現包括業務外的所有服務，包括媒體服務、信令服務、穿墻服務、中繼服務等等，這些服務稍微調整后可輕易支持分布式部署、容器部署、云部署等。 ## 對webrtc的理解與使用，我認為有三個境界： （1）.能搭建一個簡易的視頻會議系統，其中客戶端部分可以這樣做： Windows端Mac端Linux（x86）端在自帶的peerconnection client或libjingle改一下（取決于信令是http還是sip家族信令）；Android/iOS端在apprtc或licodeAndroidClient及Licode-ErizoClientIOS改一下；web端用webrtc 自帶js api實現一下。服務端部分可以這樣做：信令服務器在apprtc的collider改一下；穿墻服務器用自帶的stun server，turn server部署一下；中繼服務器在自帶的relay server改一下；媒體服務器在kurentos、licode、jitsi、Intel Collaboration Suite for WebRTC或janus改一下；如果需要和傳統的SIP體系互通則在webrtc2sip改一下；如果需要關注實時通信過程中的延時、丟包、接通率、掉線率等質量問題，可以部署callstats來進行專業監測；把所有服務都再部署于云平臺的多個虛擬主機上或阿里云的容器云服務，完成以上操作就搭建起初級規模的云上視頻會議系統原型了。 （2）.能提取、理解并使用webrtc的算法模塊，即或將算法模塊融入到自己的代碼中，或將自己的算法添加至webrtc里作為開源貢獻或自己產品的差異性優勢。值得提取的算法模塊包括音視頻編解碼與處理框架（vp8、vp9、voice engine、video engine），音視頻采集呈現封裝、音視頻預處理（NetEq、NS、AEC、Video Jitter Buffer）、網絡適應性（GCC算法、ARQ、FEC）、安全性（Dtls、Srtp/Srtcp）等，自己可添加的有視頻編碼模塊（x265、nvenc、intel qsv、xavs2、以及其他定制化的網絡傳輸策略）。 （3）.能夠結合基于rtmp-cdn/p2p等直播技術，構建既支持交互互動，又支持海量圍觀，可商用、能運營、易擴展、全兼容的音視頻PaaS服務平臺，完成一個多媒體通信的終極產品。 ## webrtc開源服務器 licode: Licode是達到第一境界技術層面所需要了解的開源工程，它從webrtc代碼中提取出了SFU/MCU媒體服務所用到的音視頻、媒體傳輸、信令的功能代碼，結合libnice與libav實現了ICE與媒體轉發功能，并封裝成了可被調用的js API，此外還用js實現了包含全局管理服務、數據庫服務、業務邏輯服務與信令媒體的調用服務的業務代碼。Licode實現了webrtc開源工程沒直接實現的中心側的媒體服務功能，并提供了簡單的業務模型與分布式部署方式，從而得到了多媒體通信工程師的廣泛關注。但是Licode的相關文檔與資料非常少，故本文是在我個人觀察運行調試代碼后總結所寫的，不正確之處希望在留言中能夠得以指正。