本文主要介紹WebRTC的架構和協議棧（我們翻譯和整理的，譯者：litie），最早發表在【編風網】
支持原創，轉載必須注明出處，歡迎關注我的微信公眾號blacker（微信ID：blackerteam 或 webrtcorgcn）。
為了便於理解，我們來看一個最基本的三角形WebRTC架構（見下圖）。
在這個架構中，移動電話用“瀏覽器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媒體會話和媒體交換就可以實現了。
5.但是，假如在一個高度限制的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。
譯者：litie，具體詳見:【編風網】