什麼是 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）媒體格式編碼問題--媒體格式編碼多樣不統一
對于需要音視訊通信的雙方，彼此要了解對方支援的媒體格式才能正常地對流媒體編解碼。比如，PeerA端可支援VP8、H264多種編碼格式，而PeerB端支援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類型處理傳入的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 展示對方遠端音視訊流；
關于IM即時通訊，更多原創技術文章：
開源OpenIM：輕量、高效、實時、可靠、低成本的消息模型 開源OpenIM：高性能、可伸縮、易擴充的即時通訊架構 基于Tablestore Timeline的IM（即時通訊）消息系統架構 - 架構篇