WebRTC閘道器伺服器單埠方案實現

標準webrtc連線建立流程

這裡描述的是trickle ice過程，並且省略了通話發起與接受的信令部分。流程如下： 1） webrtc a通過signal server**sdp offer到webrtc b。webrtc b做完本地處理以後，通過 signal server**sdp answer到a。

3）a、b收集完內外網ice candidate，並通過signal server傳送給對方；

4）雙方開始做nat穿越，互相給對方的ice candidate傳送stun binding request；

5）nat穿越成功，a、b之間的p2p連線建立，進入**互通階段。在這個過程中，我們看到了有三個核心的部分，sdp協商、ice candidate交換、stun binding req/res的連通性檢查。

webrtc閘道器連線建立流程

在了解了標準webrtc的建連流程以後，我們來看看webrtc客戶端如何與閘道器建連。

webrtc閘道器伺服器**架構最簡的伺服器端埠方案是我們可以為每個客戶端分配乙個埠，伺服器上使用這個埠區分每個使用者，就像圖里描述的a、b、c、d四個人在webrtc閘道器伺服器上分別對應udp埠10001~1004。這種方案邏輯上很簡單，很多開源的伺服器都採用這個方案，如janus。另外乙個原因是使用了libnice庫在伺服器上來和客戶端做ice建連，類似的做法都是採用多埠的架構。那麼多埠有什麼不足呢？ 1）很多的網路出口防火牆對能夠通過的udp埠是有限制的；

2）對於服務端來說開闢這麼多埠，安全性本身也有一定的問題，特別是運維同學，更是拒絕；

3）開闢這麼多的埠在server端上，埠的開銷和效能均有一定的影響。那能否用單埠？使用單埠前，核心要解決的乙個問題是：如何區分每乙個rtp/rtcp包是屬於哪乙個webrtc客戶端。

為了解決這個問題，我們需要使用一些小技巧。首先，有幾個基礎知識點我們先了解一下。如下圖：

1）sdp offer和answer裡配置的ice-ufrag欄位裡面內容，原來是用來作為stun資料報的鑑權的，因此stun binding request裡面的username欄位就是由上offer和answer的ice-ufrag內容拼接而成。

2）傳送stun binding request的客戶端本地udp fd，與ice建連成功後傳送**資料的udp fd是同乙個，也就是說server上看到的ip port是同乙個。

有了上面的背景知識，你肯定已經大致有乙個方案了。我們來看看實現細節是怎麼樣的：

1）在伺服器給web端的sdp answer中設定ice-ufrag為roomid/userid，其中roomid和userid是通話業務層分配的內容，用於區分每對通話以及參與者。接著做ice candidate協商，web端開始做連通性檢測，也就是stun binding request裡的username為sdp local和remote的ice-ufrag指定內容。

2）伺服器收到stun binding request的客戶端ip和埠，並正常回stun binding response。

3）記錄客戶端位址與使用者的資訊的對映關係。

4）伺服器收到乙個rtp/rtcp**資料報，通過包的源ip和埠，查詢對映表就可以識別這個包屬於哪個使用者。

webrtc客戶端使用peerconnection來表示不同的**連線，接下來我們將介紹如何選擇peerconnection的方案。

WebRTC閘道器伺服器單埠方案實現

WebRTC閘道器伺服器單埠方案實現

WebRTC伺服器搭建

閘道器伺服器

相關推薦