WebRTC網關服務器單端口方案實現

標準WebRTC鏈接創建流程

這裏描述的是Trickle ICE過程，而且省略了通話發起與接受的信令部分。流程以下：
1） WebRTC A經過Signal Server轉發SDP OFFER到WebRTC B。WebRTC B作完本地處理之後，經過 Signal Server轉發SDP ANSWER到A。

2）A、B同時向STUN Server發送Binding request請求自身的外網地址，並從STUN Server回包的MAPPED-ADDRESS中獲得各自的外網地址；

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客戶端如何與網關建連。

首先，咱們網關的Media Server擁有公網IP，所以Server就不須要經過Stun Server收集自身的公網IP。WebRTC客戶端先與網關Signal Server協商SDP，包括ICE Candidate，Media Server分配IP和端口做爲網關的ice candidate發送給客戶端。由於網關是公網IP，因此客戶端向這個IP發送STUN Binding Request會被服務器收到， 並回復Response。接着客戶端與網關媒體服務器進行DTLS握手與祕鑰協商，在此基礎上進一步進行SRTP的音視頻通訊。至此，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的方案。

在線體驗單端口直播與一對一視頻通話：https://github.com/starrtc/an...