【OpenIM原創】簡單輕松入門 一文講解WebRTC實現1對1音視頻通信原理

什么是 WebRTC ？

WebRTC（Web Real-Time Communication）是 Google于2010以6829萬美元從 Global IP Solutions 公司購買，并于2011年將其開源，旨在建立一個互聯網瀏覽器間的實時通信的平臺，讓 WebRTC技術成為 H5標準之一。我們看官網（https://webrtc.org）的介紹

其中：

Web Real-Time Communications (WEBRTC) W3C 組織：定義瀏覽器 API。

Real-Time Communication in Web-browsers (RTCWEB) IETF 標準組織：定義其所需的協議，數據，安全性等手段。

簡單來說，WebRTC 是一個可以在 Web 應用程序中實現音頻，視頻和數據的實時通信的開源項目。在實時通信中，音視頻的采集和處理是一個很復雜的過程。比如音視頻流的編解碼、降噪和回聲消除等，但是在 WebRTC 中，這一切都交由瀏覽器的底層封裝來完成。我們可以直接拿到優化后的媒體流，然后將其輸出到本地屏幕和揚聲器，或者轉發給其對等端。

點對點音視頻的難點

拋開低延遲、流暢性、回聲消除和海量并發這些難點不講，單純從功能來看，打通通訊雙方的兩端，讓彼此能正常視頻及通話，主要存在兩個問題：

（1）網絡打通問題--無公網IP無法直接通信

當今互聯網到處存在著一些中間件(MIddleBoxes)，如NAT和防火墻，導致兩個(不在同一內網)中的客戶端無法直接通信。這些問題即便是到了IPV6時代也會存在，因為即使不需要NAT，但還有其他中間件如防火墻阻擋了鏈接的建立。

當今部署的中間件大多都是在C/S架構上設計的，其中相對隱匿的客戶機主動向周知的服務端(擁有靜態IP地址和DNS名稱)發起鏈接請求。大多數中間件實現了一種非對稱的通訊模型，即內網中的主機可以初始化對外的鏈接，而外網的主機卻不能初始化對內網的鏈接，除非經過中間件管理員特殊配置。在中間件為常見的NAPT的情況下，內網中的客戶端沒有單獨的公網IP地址，而是通過NAPT轉換，和其他同一內網用戶共享一個公網IP。這種內網主機隱藏在中間件后的不可訪問性對于一些客戶端軟件如瀏覽器來說并不是一個問題，因為其只需要初始化對外的鏈接，從某方面來看反而還對隱私保護有好處。然而在P2P應用中，內網主機（客戶端）需要對另外的終端（Peer）直接建立鏈接，但是發起者和響應者可能在不同的中間件后面，兩者都沒有公網IP地址。而外部對NAT公網IP和端口主動的鏈接或數據都會因內網未請求被丟棄掉。對于WebRTC來說，首先要解決的是如果跨越NAT實現內網主機直接通訊的問題。

（2）媒體格式編碼問題--媒體格式編碼多樣不統一

對于需要音視頻通信的雙方，彼此要了解對方支持的媒體格式才能正常地對流媒體編解碼。比如，Peer-A端可支持VP8、H264多種編碼格式，而Peer-B端支持VP9、H264，要保證二端都正確的編解碼，最簡單的辦法就是取它們的交集H264。有一個專門的協議稱為SDP（Session Description Protoco），可用于描述上述這類信息，在WebRTC中，參與視頻通訊的雙方必須先交換SDP信息，這樣雙方才能知根知底，而交換SDP的過程，也稱為“媒體協商”

SDP(Session Description Protocol) 是一種會話描述協議，基于文本，其本身并不屬于傳輸協議，需要依賴其它的傳輸協議（比如 SIP 和 HTTP）來交換必要的媒體信息，用于兩個會話實體之間的媒體協商。SDP(會話描述協議)定義了一個標準，用于定義兩個（通常）端與端之間媒體（通常是流媒體）交換的參數。IETF已將其發布為RFC 4566。SDP通常嵌入或封裝在另一個協議中，最廣泛使用的應用程序位于大多數IP電話應用程序的SIP協議內部。簡單地說，SDP協議是媒體端到端對其接收規范和能力的聲明；典型的聲明會告訴我們：

（1）哪個IP地址準備好接收傳入的媒體流

（2）哪個端口號正在偵聽傳入的媒體流

（3）端點希望接收的媒體類型（通常是音頻）

（4）端點希望在哪個協議中交換信息（通常為RTP）

（5）端點能夠解碼的壓縮編碼（編解碼器）

在一個典型的會話設置過程中，我們會看到兩個端點參與一個會話，其中每個端點發送一個SDP以通知另一個端點其規范和功能。SDP本身不提供任何媒體，但僅限于協商一組兼容的媒體交換參數；媒體流本身由不同的通道和協議處理。

一個 SDP 的握手由一個 offer 和一個 answer 組成

WebRTC通話原理

點對點的雙方為了實現實時音視頻通信， WebRTC需要解決媒體協商和網絡協商問題，這里要引入信令服務器(Signaling Server)和STUN server

Signaling Server

需要通信的雙方之間建立WebRTC連接需要一個信令服務器來實現雙方通過網絡進行連接。信令服務器的作用是作為一個中間人幫助雙方在盡可能少的暴露隱私的情況下建立連接。WebRTC并沒有提供信令傳遞機制，信令的傳遞和交換需要服務器參與，這個角色就是信令服務器。WebRTC信令指建立、控制和終止通信會話的過程以及業務本身的需求來看，需要交換幾個信息：媒體信息，網絡信息，具體業務。

一、媒體信息

需要媒體數據來確定呼叫者和被呼叫者共有的編解碼器和媒體類型。如果嘗試啟動通信會話的端具有不同的分辨率和編解碼器配置，則會話不太可能成功。通過使用會話描述協議（SDP）格式的提供和應答在對等方之間交換媒體配置信息的信令，這些信息是通過SDP協議描述出來，通過信令服務器中轉的。

二、網絡信息

兩個WebRTC客戶端如何發現對方的？通過信令服務器交互雙方在Internet上的位置（IP地址和端口），以便呼叫者可以找到被呼叫者。

三、具體業務

會話控制信息確定何時初始化、關閉和修改通信會話，比如加入房間，離開房間，禁言，媒體流訂閱發布等功能，需要信令服務器來控制。

**STUN server **

STUN?（Session Traversal Utilities for NAT?，NAT會話穿越應用程序）是一種?網絡協議，它允許位于?NAT**（或多重NAT）后的客戶端找出自己的公網地址，查出自己位于哪種類型的NAT之后以及NAT為某一個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處于NAT路由器之后的主機之間建立UDP通信。該協議由RFC 5389定義。****STUN 是 C/S 模式的協議，可以簡單理解為：由客戶端發送 STUN 請求；STUN 服務響應，告知由 NAT 分配給主機的 IP 地址和端口號。一旦擁有了ip和端口，點對點通信的雙方就能直連通信了。（注：以上的響應同時還使得STUN客戶端能夠確定正在使用的?NAT類型——因為不同的NAT類型處理傳入的UDP分組的方式是不同的。四種主要類型中有三種是可以使用的：?完全圓錐型NAT?、?受限圓錐型NAT和?端口受限圓錐型NAT?——但大型公司網絡中經常采用的對稱型NAT（又稱為雙向NAT）則不能使用，這時TURN就要登場了，本文暫且不講）

專有名詞介紹

Signaling Server ：信令服務器，負責處理通信雙方的信息交互，包括媒體信息，網絡信息，業務信息。

STUN server：STUN的全稱是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)， 即穿越NAT的簡單UDP傳輸，是一個輕量級的協議。可以簡單理解為：由客戶端發送 STUN 請求；STUN 服務響應，告知由 NAT 分配給主機的 IP 地址和端口號。

SDP：Session Description Protocol 為了連接到對端用戶，我們必須要對其他用戶的設備情況有所了解，比如音頻視頻的編碼解碼器、使用何種編碼格式、使用何種網絡、設備的數據處理能力，，而 SDP 為我們提供了這些功能

ICE：Interactive Connectivity Establishment 通信的兩側可能會處于不同的網絡環境中，有時會存在好幾層的訪問控制、防火墻、路由跳轉，所以我們需要一種方法在復雜的網絡環境中找到對方，并且連接到相應的目標。WebRTC 使用了集成了 STUN、TURN 的 ICE 來進行雙方的數據通信。

offer、answer：一個 SDP 的握手由一個 offer 和一個 answer 組成，一方發送offer，另一方接收到offer后，發送answer。

**WebRTC音視頻通信流程

**

在同一房間的雙方通過WebRTC建立音視頻通信，主要分為四個階段：

（一）加入房間、呼叫對方，對方應答

** **（1）ClientA登錄后連接信令服務器，選擇進入某個房間；

** **（1）ClientB登錄后連接信令服務器，選擇進入某個房間；（1）（2）不分先后

** **（3）ClientA 在此房間中看到ClientB在線，選擇呼叫ClientB；

** **（4）ClientB選擇同意接聽； （3）（4）中的ClientA和ClientB可以互換；

（二）交換SDP，發送/接收offer，發送/接收answer

** **（1）ClientA 執行getUserMedia() ->new RTCPeerConnection->Peer.addStream->createOffer

** **（2）ClientB 執行getUserMedia() ->new RTCPeerConnection->Peer.addStream；（1）（2）并行執行；

** **（3）ClientA通過信令服務器中轉offer給ClientB；

** **（4）ClientB收到offer后，setRemoteDescription->createAnswer；并通過信令服務器中轉answer給ClientA；

** **（5）ClientA收到answer后，setRemoteDescription；

（三）交換ICE candidate

** ****（1）ClientA 向STUN Server請求ICE（請求可能在之前某個時候已經發出），STUN Server返回ICE candidate **

** ****（2）ClientB 向STUN Server請求ICE（請求可能在之前某個時候已經發出），STUN Server返回ICE candidate **

** **（3）ClientA通過信令服務器中轉ICE candidate到達ClientB；ClientB通過信令服務器中轉ICE candidate到達ClientA；

** **（4）ClientA收到B的ICE canditate，addIceCandidate

** **（5）ClientB收到A的ICE canditate，addIceCandidate

（四）開始音視頻通信

** **（1）ClientA addStream 展示對方遠程音視頻流；

** **（2）ClientA addStream 展示對方遠程音視頻流；

數據通信

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。