WebRTC 技術概述

WebRTC（Web Real-Time Communication）是一套開放標準，讓瀏覽器和手機 App 不用裝任何外掛，就能做即時語音、視訊和資料傳輸。它把即時通訊的技術門檻拉低了一大截。

WebRTC 架構

核心元件

WebRTC 的技術架構由三個主要部分組成：

元件	功能
getUserMedia	存取裝置的麥克風和攝影機
RTCPeerConnection	建立端對端的媒體連線
RTCDataChannel	端對端的任意資料傳輸

協定堆疊

WebRTC 使用的協定堆疊與傳統 VoIP 有顯著差異：

層級	WebRTC	傳統 VoIP
信令	無標準（通常 WebSocket + 自定義）	SIP
媒體安全	DTLS-SRTP（強制）	SRTP（選配）
媒體傳輸	SRTP over UDP/TCP	RTP over UDP
NAT 穿透	ICE + STUN + TURN（強制）	依賴 SBC 或 STUN
語音 Codec	Opus（強制）+ G.711	G.711 / G.729 等
視訊 Codec	VP8/VP9/H.264（至少一種）	H.264

有一點常讓人意外：WebRTC 刻意不規定信令協定，把選擇權留給開發者。常見的做法有 WebSocket + JSON、SIP over WebSocket（RFC 7118），或各種自定義協定。

媒體處理引擎

WebRTC 內建的媒體處理功能：

迴音消除（Acoustic Echo Cancellation, AEC）
噪音抑制（Noise Suppression, NS）
自動增益控制（Automatic Gain Control, AGC）
抖動緩衝（Jitter Buffer）
頻寬估算（Bandwidth Estimation）
前向錯誤更正（Forward Error Correction）

ICE/STUN/TURN 機制

NAT 穿透的挑戰

在真實網路中，大多數用戶端位於 NAT 或防火牆後方，無法直接被外部連線。WebRTC 使用 ICE 框架統一處理各種 NAT 穿透場景。

ICE（Interactive Connectivity Establishment）

ICE（RFC 8445）是 WebRTC 的 NAT 穿透框架，它收集所有可能的連線候選者（Candidate），並透過系統化的檢查找出最佳路徑。

ICE Candidate 類型：

類型	優先級	說明
Host	最高	本機 IP 位址（可能是私有 IP）
Server Reflexive (srflx)	中	透過 STUN 取得的公網 IP:Port
Relay	最低	TURN 伺服器分配的中繼位址
Peer Reflexive (prflx)	中高	連線檢查中發現的位址

ICE 連線建立流程：

雙方各自收集所有 Candidate
透過信令交換 Candidate 列表
依優先級排列 Candidate 配對
對每對 Candidate 進行連通性檢查（STUN Binding Request）
選擇最佳可用的配對進行通訊

STUN（Session Traversal Utilities for NAT）

STUN（RFC 5389）協助用戶端發現自己在 NAT 後的公網位址：

客戶端                  STUN Server
   |                       |
   |-- Binding Request --->|
   |                       |  （STUN Server 看到客戶端的
   |<-- Binding Response --|    公網 IP:Port 並回傳）
   |                       |

STUN 可以穿透的 NAT 類型：

NAT 類型	STUN 可穿透	說明
Full Cone	可以	最寬鬆的 NAT
Restricted Cone	可以	限制來源 IP
Port Restricted Cone	可以	限制來源 IP + Port
Symmetric	不可以	每個目的地分配不同映射

TURN（Traversal Using Relays around NAT）

TURN（RFC 5766）在 STUN 無法穿透的情況下（如 Symmetric NAT），提供媒體中繼服務：

客戶端 A                TURN Server                客戶端 B
   |                       |                          |
   |-- Allocate Request -->|                          |
   |<-- Allocate Response -|  （分配中繼位址）          |
   |                       |                          |
   |== 媒體 =============>|========= 媒體 ==========>|
   |<= 媒體 ==============|<======== 媒體 ===========|

TURN 是要成本的。中繼會吃伺服器的頻寬和運算，每通通話都得雙倍頻寬（收一份、再轉發一份），規模一大，TURN 伺服器的開銷就不能忽視。實務上大約 10-30% 的連線會走到 TURN。

瀏覽器支援狀況

主要瀏覽器支援

瀏覽器	支援版本	備註
Chrome	28+	Google 主導 WebRTC 開發
Firefox	22+	Mozilla 早期參與者
Safari	11+	較晚加入，功能逐步完善
Edge	79+（Chromium）	與 Chrome 共用引擎
iOS Safari	11+	僅限 Safari（其他瀏覽器受限）
Android Chrome	28+	完整支援

已知限制

平台	限制說明
iOS	所有瀏覽器必須使用 WebKit 引擎，WebRTC 行為一致
Safari	部分進階 API（如 insertable streams）支援較慢
企業環境	部分 Proxy 會阻擋 UDP，需 TURN over TCP/TLS
防火牆	嚴格防火牆可能阻擋 STUN/TURN 流量

Codec 支援

Codec	Chrome	Firefox	Safari
Opus（音訊）	支援	支援	支援
G.711（音訊）	支援	支援	支援
VP8（視訊）	支援	支援	支援
VP9（視訊）	支援	支援	部分支援
H.264（視訊）	支援	支援	支援
AV1（視訊）	支援	支援	逐步支援

與 SIP 的橋接

為何需要橋接

企業客服中心的電話系統普遍採用 SIP 協定，而 WebRTC 使用不同的信令和媒體機制。WebRTC Gateway 負責在兩個世界之間進行轉換。

WebRTC Gateway 的轉換工作

轉換項目	WebRTC 側	SIP 側
信令協定	WebSocket (WSS)	SIP over UDP/TCP/TLS
媒體加密	DTLS-SRTP（強制）	SRTP 或 RTP
金鑰交換	DTLS 握手	SDES 或無
NAT 穿透	ICE/STUN/TURN	SBC 處理
語音 Codec	Opus	G.711 / G.729
視訊 Codec	VP8/VP9	H.264

橋接架構

瀏覽器                WebRTC GW / SBC              SIP 環境
  |                        |                          |
  |-- WSS (SIP/JSON) ---->|                          |
  |                        |-- SIP/UDP -------------->|
  |-- DTLS-SRTP --------->|                          |
  |                        |-- RTP/SRTP ------------>|
  |                        |                          |
  | ICE/STUN/TURN         | NAT/拓撲隱藏             | IP-PBX

在客服中心的應用場景

場景一：瀏覽器軟體電話

客服人員使用瀏覽器中的 WebRTC 軟體電話取代實體 IP 話機：

優勢：

無需安裝桌面應用程式
降低終端設備成本
支援遠端客服（居家辦公）
整合 CRM 等 Web 應用

考量：

需要穩定的網路環境
瀏覽器需保持開啟
部分功能（如 BLF 指示燈）需以 UI 方式實現
音訊設備（耳麥）品質影響通話體驗

場景二：網頁即時客服

客戶從企業網站直接發起語音或視訊通話：

客戶瀏覽器  ──WebRTC──>  WebRTC GW  ──SIP──>  ACD  ──>  客服座席

優勢：

客戶無需撥打電話，點擊即可通話
降低客戶的通訊成本
可同時搭配螢幕共享、文字聊天
收集更多客戶互動數據

場景三：行動 App 整合

將 WebRTC 嵌入企業的行動 App，提供 App 內通話功能：

使用 WebRTC SDK（iOS / Android 原生或跨平台函式庫）
透過推播通知喚醒 App 接聽來電
支援語音與視訊通話
可搭配文字訊息和檔案傳輸

場景四：視訊客服

特定場景需要面對面溝通（如保險理賠、遠端身分驗證）：

應用	說明
遠端身分驗證	視訊通話 + 證件拍照上傳
保險理賠	現場拍攝損壞情況
技術支援	視訊指導客戶操作
VIP 服務	面對面專屬服務體驗

在客服中心部署 WebRTC，有幾個實務建議：TURN 伺服器要佈得夠，連線成功率才穩；橋接點選一台支援 WebRTC 的 SBC；座席配高品質的 USB 耳麥（音訊設備直接影響通話體驗）；網路的 QoS 一定要設好，尤其座席用無線網路的時候。

安全性考量

WebRTC 的安全設計

WebRTC 在設計上強制啟用安全機制：

安全特性	說明
DTLS-SRTP 強制	媒體加密不可關閉
安全來源限制	getUserMedia 僅允許 HTTPS 或 localhost
使用者授權	存取麥克風/攝影機需使用者明確同意
無永久授權	重新載入頁面需重新授權

企業環境的額外考量

考量點	建議
信令加密	WebSocket 使用 WSS（TLS）
身分驗證	整合企業 SSO / Token 驗證
存取控制	限制 WebRTC 功能的存取權限
錄音合規	確保 WebRTC 通話可被錄音系統擷取
日誌記錄	記錄所有 WebRTC 會話的建立與結束

參考標準

標準	名稱
RFC 7742	WebRTC Video Processing and Codec Requirements
RFC 7874	WebRTC Audio Codec and Processing Requirements
RFC 8445	ICE: Interactive Connectivity Establishment
RFC 5389	STUN: Session Traversal Utilities for NAT
RFC 5766	TURN: Traversal Using Relays around NAT
RFC 7118	SIP over WebSocket
RFC 8834	Media Transport and Use of RTP in WebRTC

WebRTC 技術概述 ​

WebRTC 架構 ​

核心元件 ​

協定堆疊 ​

媒體處理引擎 ​

ICE/STUN/TURN 機制 ​

NAT 穿透的挑戰 ​

ICE（Interactive Connectivity Establishment） ​

STUN（Session Traversal Utilities for NAT） ​

TURN（Traversal Using Relays around NAT） ​

瀏覽器支援狀況 ​

主要瀏覽器支援 ​

已知限制 ​

Codec 支援 ​

與 SIP 的橋接 ​

為何需要橋接 ​

WebRTC Gateway 的轉換工作 ​

橋接架構 ​

在客服中心的應用場景 ​

場景一：瀏覽器軟體電話 ​

場景二：網頁即時客服 ​

場景三：行動 App 整合 ​

場景四：視訊客服 ​

安全性考量 ​

WebRTC 的安全設計 ​

企業環境的額外考量 ​

參考標準 ​