WebRTC架構和協議棧-zz

爲了便於理解，咱們來看一個最基本的三角形WebRTC架構（圖4）。在這個架構中，移動電話用「瀏覽器M」表示，筆記本電腦用「瀏覽器L」表示，經過Web服務器將它們鏈接起來。要創建一個實時媒體通信，兩臺設備須要瞭解彼此的媒體功能，經過交換呼叫信令控制協議實現。諸如這樣的信令協議在WebRTC標準中並不是事先規定，而是由開發者自行制定。在瀏覽器RTC會話的步驟以下:

首先，兩個瀏覽器都從Web服務器下載了WebRTC程序（HTML5/JavaScript）；

其次，兩個瀏覽器經過Web服務器交換控制信令信息（使用嵌入式信令服務器），創建媒體功能功能互通；

最後，兩個瀏覽器直接創建RTC媒體的音頻、視頻和數據通道。

WebRTC使用P2P媒體流，音頻、視頻和數據的鏈接直接經過瀏覽器實現。可是，瀏覽器卻隱藏在NAT（網絡地址翻譯）和防火牆的後面，這增長了創建P2P媒體會話的難度。這些流程和協議，如ICE或Trickle ICE，STUN和TURN，在創建P2P媒體流都是必不可少的。

如何使用STUN協議創建一個P2P RTC媒體（如圖5所示），簡化版的ICE流程以下：

1.兩個瀏覽器經過本身的公網IP地址，使用STUN協議信息和STUN服務器創建聯繫；

2.兩個瀏覽器經過SDP提供/應答機制，使用呼叫控制信令消息交換它們已發現的公共IP地址（ICE候選）；

3.兩個瀏覽器執行鏈接檢查（ICE衝孔），確保P2P能夠鏈接；

4.創建鏈接後，RTC媒體會話和媒體交換就能夠實現了。

可是，假如在一個高度限制的NAT或防火牆，這種直接的路徑將沒法創建，只能到達TURN服務器。結果是媒體經過TURN服務器分程傳遞（如圖6所示）。

由互聯網工程任務組（IETF）基於標準的可互操做的通訊模型和協議棧詳細地定義了WebRTC技術（參見圖7），以下：

›如前所述的信令棧，並不是由WebRTC實現規定，而是由開發者自行決定。在這個例子中，咱們將使用SIP-over-WebSocket（SIPoWS）做爲信令棧。HTTP協議用於瀏覽器下載HTML5/JavaScript程序內容；

›NAT棧解決P2P鏈接問題；

›媒體棧用於發送和接收RTC的音頻和視頻。LETF標準規定G.711和Opus做爲音頻/視頻解碼器。視頻解碼器還沒有受權，可是H.248和VP8已經得到受權。媒體棧也用於交換RTC數據。本例中，實時信息採用消息會話中繼協議（MSRP），實時會議採用二層控制協議（BFCP），實時文本服務採用T.140。