Webrtc音視訊會議之Webrtc“不求甚解”

這裡隻是對Webrtc的“不求甚解”情況下的“高屋建瓴”，想要“細緻入微“”那得好好的研究RFC一堆協定和Webrtc源碼；Webrtc涉及的協定之多和内容之豐富我隻能歎一聲到此處休矣！！！！

來先一睹為快，以下是我梳理的Webrtc開發的時候涉及的協定，其中虛線的是可選的上層協定，實線實必須的；何其浩瀚

再此處我列出來Webrtc中我感興趣的當做記錄，留作以後沒事翻出來看看

協定	用途	規範
ICE	互動式連結建立，利用打洞穿越	RFC5245
SDP	回話描述協定	RFC4566
STUN	NAT會話穿透實用工具	RFC5389
TURN	使用中繼型NAT穿透，是STUN的擴充	RFC5766
RTP	實時傳輸協定，使用者媒體和媒體控制資料包傳輸	RFC3550

對一個技術的深度把我是閱讀源碼；前人的肩膀還是值得站一站的；但是閱讀一個項目源碼的前提是了解源碼中包含的思想，同時設計一個方案的前提是得對方案中涉及的技術原理得有一定的了解；學習Janus源碼和思考音視訊會議的解決方案的前提是熟悉Webrtc，畢竟後續所有的一切都是基于Webrtc；是以首先需要對Webrtc最起碼有一個“不求甚解”的了解和認知；

簡說Webrtc

Webrtc是英文Web Real-Time Communication的縮寫；Webrtc是Google公司搞的一個浏覽器無插件化情況下進行實時音視訊會議的規範或者叫協定，我更喜歡稱之為一攬子解決方案，後面我會說為什麼我要這樣稱呼它；Webrtc中包含媒體的采集，媒體的傳輸，媒體的安全，媒體的編解碼等等這些技術，使媒體能更簡單的采集和傳輸并且在網絡環境不好的情況下抗抖動等等；同時Chrome/Firefox等主流浏覽器都對Webrtc規範進行了實作，這樣這些浏覽器隻需要使用JS語言就能實作音視訊媒體的傳輸（麥克風采集，攝像頭采集，螢幕分享）而無需關心媒體的編解碼網絡抗抖動；Google針對Webrtc并放出了一套标準源碼，這套源碼由C/C++編寫稱為 WebRTC Native C++ API，是以針對各平台原生Webrtc開發就可以通過這套 WebRTC Native C++ API進行開發；我們可以針對不同的平台交叉編譯後進行原生媒體開發接入音視訊會議；Webrtc說起來也算是新瓶裝老酒，他包含的很多協定和算法都是現有的而不是Webrtc所獨有，我稱為一攬子解決方案就是Webrtc把很多現有且成熟的協定和技術拿過來進行組合和包裝形成一套行之有效的音視訊的解決方案；

Webrtc包含的内容

從媒體生命周期來說分為：媒體采集，媒體傳輸，媒體顯示

音視訊會議或者直播這些都可以歸納出這三個周期

那我們針對媒體的這三個生命周期進一步去看Webrtc中如何處理的，并且看看Webrtc為我們做了什麼進而了解到有了Webrtc進行音視訊開發後我們省去了多少工作

媒體采集

在音視訊會議中我們關注的媒體就是，音頻和視訊，而音頻和視訊的來源就是麥克風，攝像頭，螢幕分享（錄屏）；webrtc中音視訊和螢幕分享流的采集和編碼都已經為我們做了，視訊采集支援I420、YUY2、RGB、UYUY，其中編解碼支援VP8（預設的）,VP9,H264等主流的編解碼格式；并且視訊方面加入了JitterBuffer緩沖器可以降低由于視訊抖動和視訊資訊包丢失帶來的體驗；音頻支援Pcm和Wav；并且音頻方面針對音頻資料進行處理，包括回聲消除(AEC)、AECM(AEC Mobile)、自動增益(AGC)、降噪(NS)、靜音檢測(VAD)處理等功能，用來提升聲音品質；

媒體傳輸（我關注的重點）

媒體傳輸這裡涉及很多的協定和規範，其中就包括ICE（Stun/Turn,SDP），RTP(RTP/RTCP);後續我們要研究的Janus的源碼就是針對這塊來實作的Webrtc流轉發；是以這塊的原理的了解是重點

1. ICE[Interactive Connectivity Establishment]

   互動式互聯建立，說白了了就是通過這個協定實作對等的UDP連接配接不管對等用戶端是在NAT前還是NAT後，其中包含兩個重要的協定Stun和Turn；就不細說每個單獨拿出來都是一本書；記住一定ICE就是為了讓兩個裝置打洞穿越而進行對等UDP連接配接，它是一個協定集合,

   SDP[Session Description Protocol] 會話描述協定也是ICE的一部分;SDP 是在Offer/Answer模型下進行會話描述交換的的協定格式也是ICE的一部分；它是多行的文本形式用來交交換協商雙方的協商位址和媒體編解碼格式等等資訊，可以通過a進行屬性擴充；通過ICE兩個裝置之間就開辟一個對等的UDP通道，這樣就可以傳輸媒體了；這其中SDP的互動就需要額外開辟信令通道了，信令不是Webrtc的一部分，是以信令傳輸的方式由我們自己來定，如果想很好的浏覽器支援我們傳輸信令的方式就避免不了http restfull或者websocket了；這兩種方式都是Janus通道插件中的方式;當然還可以用一些類似XMPP這些更高層的IM協定去交換SDP

2. UDP通道打通後，就開始傳輸媒體，但是媒體在傳輸的過程中控制丢包順序等等，這個時候就靠RTP了,RTP分為RTP和RTCP,所有一般是兩個UDP端口，RTP用來傳輸媒體，RTCP用來媒體控制指令的傳輸，RTP協定也不詳細說明了，我的了解也是粗淺的，能讓我寫出RTP網關代理程式就行了；哈哈……

   到這裡上一個我繪制的最簡單的Webrtc連接配接過程時序：

   

   這裡不對這個時序詳細說明；後續的學習記錄中做詳細的說明

媒體顯示

這塊Webrtc在其中承擔的責任是編解碼和弱網環境下的媒體緩存等等，因為我在伺服器方案中是以不是太關心這塊

後記

總結下我關注的重點類容：

1. ICE是用來建立對等UDP通道的，不管Peer是在什麼網絡環境下面
2. 信令是用來交換ICE過程中的SDP資訊的，一般有websocket或者Http Restful API

3. RTP（RTP/RTCP）是用來傳媒體資料和控制資料

   下一篇文部落格重點記錄下Webrtc中ICE打通的過程，因為這是ICE的使用是Janus-gateway的核心原理

再次說明這裡隻是對Webrtc的“不求甚解”情況下的“高屋建瓴”，想要“細緻入微“”那得好好的研究RFC協定和Webrtc源碼；Webrtc涉及的協定之多和内容之豐富我隻能歎一聲到此處休矣！！！！

是以各位看官别過多的苛求啊；

引用文章請标明出處，否則可以保留一切追究責任的權利

技術交流：

qq：408365330

微信：egojit