什么是WebRTC

WebRTC?即Web Real-Time Communication（網頁實時通信）的縮寫，是一個支持網頁瀏覽器之間進行實時數據傳輸（包括音頻、視頻、數據流）的技術。經過多年的發展與改進，日臻成熟，作為瀏覽器網頁端的通信技術，WebRTC與H5巧妙結合，使得網頁端的音視頻通信變的簡單易行。

WebRTC有哪些優點

• 免費：WebRTC本身是開源的，使用WebRTC本身是免費的。此外WebRTC是可以不借助媒體服務器實現簡單的點對點音視頻通信，減少額外花費。
• 無插件：不需要安裝任何軟件，大家只要打開瀏覽器，輸入一個url，即可實現多人音視頻通話。
• 跨平臺：由于是基于瀏覽器進行音視頻通話，各個平臺只要有瀏覽器即可。
• 控制靈活：WebRTC沒有指定具體的信令協議，具體的信令協議留給應用程序實現，這就方便了開發者根據自己的需求方便靈活的實現各種音視頻業務場景。
• 接合HTML5：HTML5自身的能力能夠為WebRTC提供靈活快捷的音視頻數據的二次處理，可以實現豐富的業務功能。
• 易入門：WebRTC是'JavaScript'引擎庫，允許web開發者只使用幾個簡單的api就能夠基于瀏覽器輕易快捷開發出豐富的實時多媒體應用，無需關注多媒體的數字信號處理過程，只需要編寫簡單的JavaScript即可，大大的降低了音視頻開發的門檻。

WebRTC距離商用還有多少距離

• 信令控制協議的開發：上面說明過WebRTC并沒有實現信令協議，這既帶來了靈活，也帶來了挑戰，想實現一套滿足商業應用業務的信令并不容易。
• 跨平臺的挑戰：即對瀏覽器使用不便，或者不支持瀏覽器（各種盒子或者嵌入式設備）的實際環境的兼容。
• 音視頻設備的適配：音視頻設備支持的能力不同，需要自己的WebRTC產品做復雜的適配處理，才能滿足自己的業務場景。
• 瀏覽器限制：

并非所有的瀏覽器都支持WebRTC，具體請參考瀏覽器兼容性?；

各個瀏覽器廠商工業實現上的兼容。對于WebRTC，各大瀏覽器廠商實現的并不完全一致，比如說Safari瀏覽器不支持VP8系列視頻編碼，一些安卓移動設備上Chrome無法使用H264視頻編碼，還有其他很多細節問題，想要實現各種平臺，各種瀏覽器之間無障礙的互通，還需要很多工作要做；

瀏覽器版本更迭的兼容，瀏覽器本身也是在不停的更新對WebRTC的工業實現，也不斷更新對HTML5的使用，這些更新對于我們的WebRTC產品也是一大挑戰。

• 需要各種服務器的支持：現實情況中，WebRTC應用需要信令服務器、媒體服務器、中繼服務器的支持，才能實現信令的有效穩定傳輸、NAT的穿越、媒體的合理路由和轉發，進而保障穩定、高質量的音視頻通話。而且針對大并發量的使用場景，需要合理的媒體處理框架設計，用于保證音視頻服務的可靠性、穩定性。

為什么選擇云信

• 專業：

研發資歷成熟，19年通信領域研發深耕，億級產品線上驗證，移動端方案優化7年以上；

全球節點覆蓋異地多機房服務集群，覆蓋全球范圍，架構靈活高并發自動水平擴容；

消息必達策略采用動態智能DNS掉線快速重連機制，消息排重持續重連直至到達，保障通信的接通率；

海量資源支持全球超500個CDN節點，超10000個分布式轉碼集群，千萬播放并發，存儲、寬帶無上限。

• 接入和使用靈活：網易云信提供即時通訊云和視頻云技術的PaaS層服務，以快速集成SDK的模式為開發者提供穩定易用的技術支撐，客戶可以方便快捷地接入，全面滿足自己的業務需求。
• 全平臺支持：支持iOS、Android、Windows、Web、Linux、MacOS、微信小程序等主流平臺觀看、互動及互通，支持點對點、多人實時音視頻通話和旁路直播等功能。
• IM信令：網易云通信IM服務基于網易19年的IM技術積累，致力于打造最穩定的即時通訊平臺。 IM服務提供了一整套即時通訊基礎能力，通過該平臺服務就可以將即時通訊、實時網絡能力快速集成至企業自身應用中。使用IM信令作為WebRTC產品的信令協議必定能滿足用戶的各種需求。
• WebRTC SDK的能力：云信SDK兼容各大瀏覽器，各種版本，對于用戶而言所有的瀏覽器類型，所有的版本都是一致的，所有的差異由SDK統一解決，對用戶不可見。

WebRTC相關知識點

關于WebRTC首先明確一些內容:

WebRTC利用瀏覽器中的JavaScript API和HTML5

WebRTC客戶端之間可以進行點對點的媒體和數據傳輸

webrtc使用sdp協議作為媒體協商協議

webrtc使用ice作為nat穿越的手段

WebRTC 標準API

• getUserMida：通過getUserMida的API能夠通過設備的攝像頭和話筒獲得視頻、音頻的同步流；
• 允許約束媒體能力
• 獲取的媒體流可以輸出到video標簽在web頁面上展示；
• 獲取的媒體流可以輸出到一個RTCPeerConnection中，用于編碼、發送到對端；
• 可以使用HTML5本身的能力對音頻、視頻做二次處理，比如混頻、混頻、變聲、調色能，將處理后的媒體在推送給對端；
• 可以本地錄制獲取到媒體流，也可以把獲取到媒體流用于他出；
• RTCPeerConnection：RTCPeerConnection（免費下載《WebRTC 1.0: 瀏覽器間實時通訊》中文版）是WebRTC用于構建點對點之間穩定、高效的流傳輸的媒體終端；
• 進行sdp交換協商媒體
• 使用ice進行nat穿透
• dtls協商加密秘鑰
• srtp加密媒體
• 媒體編解碼，媒體收發
• 丟包補償、回聲抵消、帶寬自動調整、動態抖動緩沖、噪聲抑制與抑制等
• RTCDataChannel：RTCDataChannel（免費下載《WebRTC 1.0: 瀏覽器間實時通訊》中文版）使得瀏覽器之間（點對點）建立一個高吞吐量、低延時的信道，用于傳輸任意數據；
• 利用RTCPeerConnection會話
• 自定義可靠和不可靠通道
• dtls
• 阻塞控制

WebRTC點對點音視頻通信過程

• 使用getUserMida接口獲取本地mic、camera上音頻流和視頻流
• 本地初始化一個RTCPeerConnection實例
• 將通過getUserMida接口獲取的本地音頻流和視頻流，展示到html頁面上，并且添加到RTCPeerConnection實例中
• 通過RTCPeerConnection實例獲取本端的sdp信息（本地媒體描述信息）
• 通過信令協議把本地的sdp發送到對端
• 通過RTCPeerConnection實例，獲取本地媒體通道地址，然后通過信令協議發送到對端
• 接收對端的sdp信息、媒體通道地址，然后設置到RTCPeerConnection實例中，這樣就完成了媒體協商
• 從RTCPeerConnection實例中獲取對端的媒體流，可以展示到html頁面上

經過上面的步驟，雙方就能進行點對點視頻通話了，后續的nat穿透、dtls協商加密秘鑰、srtp加密媒體、媒體編解碼，媒體收發都由瀏覽器自動完成。

Chrome屏幕共享功能的實現

????上面說明獲取攝像頭的媒體流是通過getUserMida接口，而獲取屏幕共享則是通過其他的方式； - 使用getDisplayMedia接口（chrome 72版本開始支持）

使用方式同getUserMedia接口一致，代碼如下：

if (navigator.getDisplayMedia) {

????? return navigator.getDisplayMedia({video: true});

??? } else if (navigator.mediaDevices.getDisplayMedia) {

????? return navigator.mediaDevices.getDisplayMedia({video: true});

??? }

• 通過插件的方式
• 自己編寫extension插件擴展，使用chrome.desktopCapture.chooseDesktopMedia接口（插件是經過了認證的，瀏覽器不會阻止其運行），調用這個接口時，瀏覽器彈出包含各種共享內容（包括屏幕、應用列表、chrome標簽頁）的彈窗。用戶可以選擇自己想要共享的內容，選定之后，該接口會返回相應的chromeMediaSourceId，然后使用getUserMeida接口把chromeMediaSourceId作為約束條件，就能夠獲取到共享的媒體流。

插件代碼如下：

chrome.runtime.onMessageExternal.addListener((message, sender, sendResponse) => {

??? const sources = message.sources;

??? const tab = sender.tab;?

??? chrome.desktopCapture.chooseDesktopMedia(sources, tab, streamId => {

????? if (!streamId) {

??????? sendResponse({

????????? type: 'error',

????????? message: 'Failed to get stream ID'

??????? });

????? } else {

??????? sendResponse({

????????? type: 'success',

????????? streamId: streamId

??????? });

????? }

??? });

??? return true;

? }

);

?

chrome.runtime.onInstalled.addListener(function(){

? chrome.declarativeContent.onPageChanged.removeRules(undefined, function(){

??? chrome.declarativeContent.onPageChanged.addRules([

??????? {

??????????? conditions: [

????????????? new chrome.declarativeContent.PageStateMatcher({ pageUrl:

{ urlContains: 'app.netease.im'}})

??????????? ],

??????????? actions: [new

chrome.declarativeContent.ShowPageAction()]

??????? }

??? ]);

? });

});

getUserMedia接口的使用如下：

chrome.runtime.sendMessage(EXTENSION_ID, { sources: ['window', 'screen', 'tab'] }, {}, response => {

??? if (response && response.type === 'success') {

????? const constraint = {

??????? video: {

????????? mandatory: {

??????????? chromeMediaSource: 'desktop',

??????????? chromeMediaSourceId: response.streamId

????????? }

??????? }

????? }

????? return

navigator.mediaDevices.getUserMedia(constraint)(constraint)

??????? .then(stream => {

????????? console.log('獲取到演示流:', stream.id)

??????? })

??? }

})

Chrome 72版本unified plan適配

????對WebRTC而言，Unified Plan、Plan B、Plan A是SDP中多路媒體流的協商方式，在72版本中Chrome替換了Plan B，默認使用Unified Plan。

https://webrtc.github.io/samples/src/content/peerconnection/pc1/, { iceServers: [], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan" },

• Plan B：sdp中，一個m行描述多路media stream，以msid 作為區分；

...

a=group:BUNDLE audio

a=msid-semantic: WMS stream-id-2 stream-id-1

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126

...

a=mid:audio

...

a=rtpmap:103 ISAC/16000

...

a=ssrc:10 cname:cname

a=ssrc:10 msid:stream-id-1 track-id-1

a=ssrc:10 mslabel:stream-id-1

a=ssrc:10 label:track-id-1

a=ssrc:11 cname:cname

a=ssrc:11 msid:stream-id-2 track-id-2

a=ssrc:11 mslabel:stream-id-2

a=ssrc:11 label:track-id-2

• Unified Plan：sdp中，一個m行對應一個meida stream；

...

a=group:BUNDLE 0 1

a=msid-semantic: WMS

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126

...

a=mid:0

...

a=sendrecv

a=msid:- <track-id-1>

...

a=rtpmap:103 ISAC/16000

...

a=ssrc:10 cname:cname

a=ssrc:10 msid: track-id-1

a=ssrc:10 mslabel:

a=ssrc:10 label:track-id-1

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126

...

a=mid:1

...

a=sendrecv

a=msid:- track-id-2

...

a=rtpmap:103 ISAC/16000

...

a=ssrc:11 cname:cname

a=ssrc:11 msid: track-id-2

a=ssrc:11 mslabel:

a=ssrc:11 label:track-id-2

一、點對點視頻通話業務

??1、WebRTC產品中沒有處理過sdp中的msid屬性

??????不用適配，此次的更新對你的產品沒有影響

??2、WebRTC產品中有處理sdp中的msid屬性

??????需要適配，凡是針對msid的判斷和修改都需要廢棄，重新處理

二、多流業務，使用了simulcast

??1、WebRTC產品中沒有處理過sdp中的msid屬性

??????需要適配，調整接口使用，調整sdp的解析處理，增加多m行的處理

??2、WebRTC產品中有處理sdp中的msid屬性

??????需要適配，凡是針對msid的判斷和修改都需要廢棄，重新處理，調整接口使用，調整sdp的解析處理，增加多m行的處理

WebRTC調試

Chrome瀏覽器查看WebRTC狀態方法：

chrome：chrome://webrtc-internals

瀏覽器中輸入chrome://webrtc-internals，界面顯示如下：

WebRTC狀態圖

WebRTC狀態圖說明： 最上面一排依次是：getUserMedia API、二個peerconnection API

• 點擊查看getUserMedia API，簡單說明如下：

Caller origin: https://webrtc.github.io

Caller process id: 15364

Audio Constraints

Video Constraints

{width: {min: 300, max: 640}, height: {min: 200, max: 480}}

• Audio Constraints：表示從麥克風獲取視屏流的參數；

Video Constraints：表示從攝像頭獲取視屏流的參數；

PeerConnection狀態圖

PeerConnection狀態圖說明：

• 最上面的一行：表示peerconnection，大括號中的內容是peerconnection的配置參數，可以看到chrome已經用unified-plan替代了plan B；
• 左上角的Event：peerconnection的內部接口，對應的是內部接口
  • transceiverAdded：添加getUserMeida接口獲取的媒體流
  • transceiverModified: 接收對端的媒體流
  • createOffer：瀏覽器生成的本地sdp
  • setLocalDescription：設置本地sdp
  • setRemoteDescription：設置遠端sdp
  • signalingstatechange：peerconnection的狀態（免費下載《WebRTC 1.0: 瀏覽器間實時通訊》中文版）icegatheringstatechange：本地ice候選地址收集的狀態（免費下載《WebRTC 1.0: 瀏覽器間實時通訊》中文版）
  • icecandidate：候選地址的收集接口
  • iceconnectionstatechange：ICE連通性檢查的狀態（免費下載《WebRTC 1.0: 瀏覽器間實時通訊》中文版）
• 右上角的EventStats Tables：是媒體通道的具體信息，數據實時更新
  • bweforvideo (VideoBwe)：視頻帶寬相關信息
    • googActualEncBitrate：視頻編碼器實際編碼的碼率，通常這與目標碼率是匹配的。
    • googAvailableReceiveBandwidth：視頻數據接收可用的帶寬。
    • googAvailableSendBandwidth：視頻數據發送可用的帶寬。
    • googBucketDelay：Google為了處理大數據速率的策略表示，通常是很小的數值。
    • googRetransmitBitrate：如果RTX被使用的話，表示重傳的碼率。
    • googTargetEncBitrate：視頻編碼器的目標比特率。
    • googTansmitBitrate：實際發送的碼率，如果此數值與googActualEncBitrate有較大的出入，可能是fec的影響。
  • googCertificate：兩端使用的DTLS證書、指紋和哈希算法等
  • googComponent：表示認證數據與連接之間的關系，展示當前活躍的候選項對，以及有關用語DTLS和SRTP加密的相關信息。
  • Conn-video-1-0 (googCandidatePair)：RTP通道相關信息
    • googActiveConnection：當前的連接是否活躍
    • bytesReceived：接收的字節數（rtp數據）
    • bytesSent：發送的的字節數（rtp數據）
    • packetsSent：發送的數據包數（rtp數據）
    • requestsSent、responsesSent、requestsReceived、responsesReceived：STUN請求和應答數量
    • googRtt：最近的STUN請求的往返時間
    • googLocalAddress：本地的候選地址
    • googRemoteAddress：遠端的候選地址
    • googTransportType：傳輸通道的類型，通常是udp，即使當前正在使用tcp的連接方式通過turn中繼服務器轉發媒體，只有當ICE-TCP被選用時，這里才會是tcp
  • Conn-video-1-1 (googCandidatePair)：RTCP通道相關
  • ssrc_2052494919_send (ssrc)：音頻發送通道相關信息
    • audioInputLevel：mic采集的音頻能量值
    • audioOutputLevel：揚聲器播出的音頻能力值
    • bytesSent：發送的音頻數據字節數
    • mediaType：媒體類型
    • packetsSent：發送的音頻包數
    • ssrc：音頻rtp包的ssrc
    • googCodecName：音頻編碼名稱
    • googJitterReceived：收到了多少的抖動
    • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中得到的時間戳通過計算得到的往返時延
  • ssrc_4160516329_send (ssrc)：視頻發送通道相關信息
    • bytesSent：發送視頻包的自己數
    • codecImplementationName：視頻編碼器的名稱
    • framesEncoded：累計編碼出來的視頻幀數
    • mediaType：媒體類型
    • packetsLost：丟包數
    • packetsSent：發送的視頻包數
    • qpSum：QP數目
    • ssrc：視頻rtp包的ssrc
    • googTrackId：描述視頻數據軌跡，這個id可以在SDP中，以及本地或遠端媒體流軌道中被找到
    • googAdaptationChanges：發送端因為CPU的負載變化導致的分辨變高或者變低的次數，需要設置googCpuOveruseDetection
    • googAvgEncodeMs：發送端平均編碼時間，越小越好。
    • googBandwidthLimitedResolution：是否因為帶寬受限而降低發送的視頻分辨率
    • googCodecName：視頻編碼名稱
    • googCpuLimitedResolution：是否因為cpu不足而降低發送的視頻分辨率
    • googEncodeUsagePercent：發送端（平均每幀編碼時間）／（平均每幀采集時間），反應編碼效率
    • googFirsReceived：收到的fir請求
    • googFrameHeightSent、googFrameWidthSent：發送的視頻分辨率
    • googFrameRateInput、googFrameRateSent：視頻幀率
    • googHasEnteredLowResolution：是否已經降低了視頻分辨率
    • googNacksReceived：收到的nack請求
    • googPlisReceived：收到的pli請求
    • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中得到的時間戳通過計算得到的往返時延
    • transportId，是指向被用于傳送RTP流的部分，可以從sdp總找到
• 左下角的部分：也是媒體通道的具體信息，以圖表的形式展示，與右上角的EventStats Tables一一對應
  • bweforvideo (VideoBwe)：視頻帶寬相關信息
    • googActualEncBitrate：視頻編碼器實際編碼的碼率，通常這與目標碼率是匹配的。
    • googAvailableReceiveBandwidth：視頻數據接收可用的帶寬。
    • googAvailableSendBandwidth：視頻數據發送可用的帶寬。
    • googBucketDelay：Google為了處理大數據速率的策略表示，通常是很小的數值。
    • googRetransmitBitrate：如果RTX被使用的話，表示重傳的碼率。
    • googTargetEncBitrate：視頻編碼器的目標比特率。
    • googTansmitBitrate：實際發送的碼率，如果此數值與googActualEncBitrate有較大的出入，可能是fec的影響。
  • googCertificate：兩端使用的DTLS證書、指紋和哈希算法等
  • googComponent：表示認證數據與連接之間的關系，展示當前活躍的候選項對，以及有關用語DTLS和SRTP加密的相關信息。
  • Conn-video-1-0 (googCandidatePair)：RTP通道相關信息
    • googActiveConnection：當前的連接是否活躍
    • bytesReceived：接收的字節數（rtp數據）
    • bytesSent：發送的的字節數（rtp數據）
    • packetsSent：發送的數據包數（rtp數據）
    • requestsSent、responsesSent、requestsReceived、responsesReceived：STUN請求和應答數量
    • googRtt：最近的STUN請求的往返時間
    • googLocalAddress：本地的候選地址
    • googRemoteAddress：遠端的候選地址
    • googTransportType：傳輸通道的類型，通常是udp，即使當前正在使用tcp的連接方式通過turn中繼服務器轉發媒體，只有當ICE-TCP被選用時，這里才會是tcp
  • Conn-video-1-1 (googCandidatePair)：RTCP通道相關
  • ssrc_2052494919_send (ssrc)：音頻發送通道相關信息
    • audioInputLevel：mic采集的音頻能量值
    • audioOutputLevel：揚聲器播出的音頻能力值
    • bytesSent：發送的音頻數據字節數
    • mediaType：媒體類型
    • packetsSent：發送的音頻包數
    • ssrc：音頻rtp包的ssrc
    • googCodecName：音頻編碼名稱
    • googJitterReceived：收到了多少的抖動
    • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中得到的時間戳通過計算得到的往返時延
  • ssrc_4160516329_send (ssrc)：視頻發送通道相關信息
    • bytesSent：發送視頻包的自己數
    • codecImplementationName：視頻編碼器的名稱
    • framesEncoded：累計編碼出來的視頻幀數
    • mediaType：媒體類型
    • packetsLost：丟包數
    • packetsSent：發送的視頻包數
    • qpSum：QP數目
    • ssrc：視頻rtp包的ssrc
    • googTrackId：描述視頻數據軌跡，這個id可以在SDP中，以及本地或遠端媒體流軌道中被找到
    • googAdaptationChanges：發送端因為CPU的負載變化導致的分辨變高或者變低的次數，需要設置googCpuOveruseDetection
    • googAvgEncodeMs：發送端平均編碼時間，越小越好。
    • googBandwidthLimitedResolution：是否因為帶寬受限而降低發送的視頻分辨率
    • googCodecName：視頻編碼名稱
    • googCpuLimitedResolution：是否因為cpu不足而降低發送的視頻分辨率
    • googEncodeUsagePercent：發送端（平均每幀編碼時間）／（平均每幀采集時間），反應編碼效率
    • googFirsReceived：收到的fir請求
    • googFrameHeightSent、googFrameWidthSent：發送的視頻分辨率
    • googFrameRateInput、googFrameRateSent：視頻幀率
    • googHasEnteredLowResolution：是否已經降低了視頻分辨率
    • googNacksReceived：收到的nack請求
    • googPlisReceived：收到的pli請求
    • googRtt：是發送端從接受端發送過來的RTCP Receiver Report中得到的時間戳通過計算得到的往返時延
    • transportId，是指向被用于傳送RTP流的部分，可以從sdp總找到

?

網易云信翻譯了W3C推薦標準WebRTC 1.0: Real-time Communication Between Browsers，并提供《WebRTC1.0: 瀏覽器間實時通訊》中文版免費下載。

本文是WebRTC工作組最新一次會議后的候選推薦標準，基于WebIDL定義了一組ECMAScript API，允許在實現了相關實時協議的瀏覽器或設備之間發送和接收媒體內容。同時也是對WebRTC的一個全面介紹，包括WebRTC中的各個術語，獨有的概念，API的使用規范，詳細的算法流程和一些注意點，并且對涉及的數據結構及其屬性進行了剖析。在特定的使用場景下，草案的作者們還附上了示例代碼。

• 對于WebRTC初學者，本文檔可以作為學習教程，幫助你快速對WebRTC有全面且詳細的了解，學習相關API的使用，其附帶的示例代碼也是很好的學習資料；
• 對于WebRTC資深開發者，本文檔可以作為開發中的使用手冊，根據所提供的函數調用鏈或是算法流程進行開發或bug定位；
• 對于高階玩家，也可通過閱讀本文檔對WebRTC工作組反饋改進意見。

限時免費下載，WebRTC開發者必備，機不可失哦~

總結

以上是生活随笔為你收集整理的【入门】WebRTC知识点概览 | 内有技术干货免费下载的全部內容，希望文章能夠幫你解決所遇到的問題。

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