近期需要做一個類似會議室功能，但網路上大多數是一對一通訊，故記錄分享希望幫助到有用的人
WebRTC一對一聊天原理
關於WebRTC建立一對一聊天的模板網上很多，可參考以下部落格：springboot+websocket+webRTC在chrome上實現web視訊通話
關於WebRTC原理也在此簡單講解，內容引用：WebRTC通訊流程
上述序列中，標註的場景是ClientA向ClientB發起對聊請求，呼叫描述如下（此流程圖最好對著程式碼閱讀後進行理解）：
-
ClientA首先建立PeerConnection物件，然後開啟本地音影片裝置，將音影片資料封裝成MediaStream新增到PeerConnection中。
-
ClientA呼叫PeerConnection的CreateOffer方法建立一個用於offer的SDP物件，SDP物件中儲存當前音影片的相關引數。ClientA透過PeerConnection的SetLocalDescription方法將該SDP物件儲存起來，並透過Signal伺服器傳送給ClientB。
-
ClientB接收到ClientA傳送過的offer SDP物件，透過PeerConnection的SetRemoteDescription方法將其儲存起來，並呼叫PeerConnection的CreateAnswer方法建立一個應答的SDP物件，透過PeerConnection的SetLocalDescription的方法儲存該SDP物件並將它透過Signal伺服器傳送給ClientA。
-
ClientA接收到ClientB傳送過來的應答SDP物件，將其透過PeerConnection的SetRemoteDescription方法儲存起來。
交換Candidate（Candidate資訊是交換SDP物件自動收集的資訊。在建立端點（PeerConnection）的時候，新增回撥函式（onIceCandidate））
-
在SDP資訊的offer/answer過程中（不要被流程圖誤導，認為是按流程圖順序執行），ClientA和ClientB已經根據SDP資訊建立好相應的音訊Channel和影片Channel並開啟Candidate資料的收集，Candidate資料可以簡單地理解成Client端的IP地址資訊（本地IP地址、公網IP地址、Relay服務端分配的地址）。
-
當ClientA收集到Candidate資訊後，PeerConnection會透過OnIceCandidate介面給ClientA傳送通知，ClientA將收到的Candidate資訊透過Signal伺服器傳送給ClientB，ClientB透過PeerConnection的AddIceCandidate方法儲存起來。同樣的操作ClientB對ClientA再來一次。
-
這樣ClientA和ClientB就已經建立了音影片傳輸的P2P通道，ClientB接收到ClientA傳送過來的音影片流，會透過PeerConnection的OnAddStream回撥介面返回一個標識ClientA端音影片流的MediaStream物件，在ClientB端渲染出來即可。同樣操作也適應ClientB到ClientA的音影片流的傳輸。
WebRTC多對多設計思路
如果你已經熟悉上述的流程，那麼就可以構建群聊,首先看流程圖
理解流程圖之後，可以直接下載Demo進行閱讀和改造：WebRTC多對多會議室
可以看出上述方案採用P2P客戶端直連方式，使得上行客戶端的頻寬壓力（ClientC）隨下行客戶端（ClientA、ClientB）呈正相關，因此只適合小型會議室（3-4人），如果為了更好的伸縮延展最好採用SFU架構（訂閱/釋出模式），後續會進行更新講解。