資源中心
承暉資訊官網

傳真與多媒體協定 ​

語音還是客服中心的主力，但傳真、視訊、即時通訊這些多媒體技術，在全渠道客服裡的份量越來越重。這篇談三塊：IP 傳真、視訊通話、即時通訊。

T.38 傳真協定 ​

傳真在 IP 網路中的挑戰 ​

傳統傳真（T.30）設計在 PSTN 電路交換環境中運作，使用類比數據機（Modem）信號傳輸。這些信號對以下因素極為敏感：

因素影響
封包遺失任何遺失都可能導致傳真失敗
抖動數據機信號需要精確的時序
Codec 壓縮壓縮 Codec 會破壞數據機信號
延遲T.30 協定的計時器較嚴格

T.38 協定概述 ​

T.38（ITU-T T.38）是專為 IP 網路設計的即時傳真協定，它不傳輸傳真的類比信號，而是將傳真資料提取後以數位形式在 IP 網路中傳輸。

T.38 vs Fax Passthrough 比較：

特性T.38Fax Passthrough（G.711）
運作方式提取傳真資料，以 T.38 封包傳輸傳真信號作為 G.711 音訊傳輸
頻寬需求較低（僅傳資料）較高（64 kbps 全程）
容錯能力有冗餘機制（ECM）對丟包敏感
Codec 要求無（不使用語音 Codec）必須使用 G.711（禁用壓縮 Codec）
VoIP 設備支援需要 T.38 支援大多數設備支援
建議方式優先使用備選方案

T.38 運作流程 ​

傳真機 A        VoIP GW-A          VoIP GW-B        傳真機 B
   |               |                  |                |
   |-- T.30 CNG -->|                  |                |
   |               |-- SIP INVITE --->|                |
   |               |  (SDP: T.38)     |                |
   |               |<-- 200 OK -------|                |
   |               |                  |-- T.30 CNG --->|
   |               |                  |                |
   |-- T.30 DIS -->|                  |                |
   |               |== T.38 IFP ====>|-- T.30 DIS --->|
   |               |                  |                |
   |   [傳真頁面資料傳輸]              |                |
   |               |== T.38 IFP ====>|                |
   |               |                  |                |

T.38 封包格式 ​

T.38 使用 IFP（Internet Facsimile Protocol）封包，可透過 UDPTL（UDP Transport Layer）或 TCP 傳輸：

傳輸方式說明冗餘機制
UDPTL最常用，基於 UDPFEC（前向錯誤更正）或封包重傳
TCP可靠但延遲較高TCP 本身保證可靠性
RTP部分設備支援依 RTP 機制

SIP 中的 T.38 協商 ​

T.38 會話通常透過 SIP re-INVITE 從語音切換至傳真模式：

1. 初始呼叫建立（SDP 包含語音 Codec）
2. 偵測到傳真音（CNG/CED tone）
3. 發送 re-INVITE，SDP 改為 T.38：
   m=image 49170 udptl t38
   a=T38FaxVersion:0
   a=T38MaxBitRate:14400
   a=T38FaxRateManagement:transferredTCF
   a=T38FaxUdpEC:t38UDPRedundancy
4. 對方回應 200 OK（接受 T.38）
5. 傳真資料透過 T.38 UDPTL 傳輸

說句實話，IP 傳真是 VoIP 環境裡最容易出包的功能之一。常見的幾種：T.38 協商失敗、ECM（Error Correction Mode）跟非 ECM 模式對不上、SBC 不支援 T.38 透傳。排查時把 SIP 信令和 T.38/RTP 媒體封包一起抓下來對，會快很多。

視訊通話技術 ​

視訊編碼格式 ​

Codec組織特點授權
H.264（AVC）ITU-T / ISO最廣泛支援，效率佳有（MPEG-LA 專利池）
H.265（HEVC）ITU-T / ISO比 H.264 壓縮率高 40-50%有（複雜授權）
VP8Google / WebMWebRTC 支援，開放格式免授權費（BSD）
VP9Google / WebM比 VP8 效率高 30-50%免授權費（BSD）
AV1AOMedia最新一代，開放格式免授權費

視訊通話的頻寬需求 ​

解析度品質建議頻寬 (H.264)建議頻寬 (VP9)
320x240 (QVGA)低200-400 kbps150-300 kbps
640x480 (VGA)中500-1000 kbps400-800 kbps
1280x720 (HD)高1500-3000 kbps1000-2000 kbps
1920x1080 (FHD)極高3000-5000 kbps2000-3500 kbps

視訊通話的 SDP 協商 ​

m=video 49172 RTP/AVP 96 97
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1
a=rtpmap:97 VP8/90000
a=sendrecv

SIP 視訊通話架構 ​

視訊話機 A  ──SIP──>  SBC  ──SIP──>  視訊話機 B
     |                 |                  |
     |<===== RTP 語音（G.711）=========>|
     |<===== RTP 視訊（H.264）=========>|

要注意視訊很吃頻寬——一通 720p 視訊可能要 1.5-3 Mbps，而語音才 87 kbps，差了一個量級。所以在客服中心開視訊功能之前，得先確認網路頻寬和 QoS 撐得住預期的並發視訊數，別開了才發現塞爆。

WebSocket 即時通訊 ​

WebSocket 協定概述 ​

WebSocket（RFC 6455）提供在單一 TCP 連線上的全雙工通訊通道，是 Web 應用即時通訊的基礎技術。

特性HTTPWebSocket
通訊模式請求-回應全雙工
連線持續性短連線（或 Keep-alive）持久連線
延遲每次請求都有 HTTP overhead建立後幾乎零 overhead
伺服器推送需要輪詢或 SSE原生支援
適用場景一般 API 呼叫即時通訊、串流

WebSocket 在 VoIP 中的應用 ​

應用說明
SIP over WebSocketRFC 7118，WebRTC 信令傳輸
即時文字聊天客服文字通道
狀態推送座席狀態、佇列資訊即時更新
CTI 事件推送通話事件即時通知至 Web 應用
螢幕共享控制遠端協助的控制信令

SIP over WebSocket ​

瀏覽器                          SIP Proxy / SBC
  |                                   |
  |-- WebSocket Upgrade Request ----->|
  |<-- 101 Switching Protocols -------|
  |                                   |
  |== SIP REGISTER ==================>|  (SIP 訊息透過 WebSocket 傳輸)
  |<== 200 OK ========================|
  |                                   |
  |== SIP INVITE ===================>|
  |<== 100 Trying ===================|
  |<== 180 Ringing ==================|
  |<== 200 OK =======================|
  |== ACK ==========================>|

WebSocket 安全性 ​

安全措施說明
WSS（WebSocket Secure）TLS 加密的 WebSocket，使用 wss:// URI
Origin 檢查伺服器驗證 WebSocket 連線的來源域名
Token 認證連線建立時驗證 JWT 或 Session Token
心跳機制Ping/Pong 框架偵測斷線

多媒體在客服中心的趨勢 ​

全渠道整合 ​

現代客服中心正從單一語音渠道轉向全渠道（Omnichannel）服務：

渠道底層技術特點
語音通話SIP/RTP傳統核心渠道
視訊通話WebRTC / SIP Video面對面服務體驗
文字聊天WebSocket / HTTP低門檻、可多工處理
EmailSMTP/IMAP非即時但正式
社群媒體API 整合LINE, Facebook Messenger
手機 AppWebRTC SDK品牌一致的 App 體驗

媒體混合會話 ​

一通客服互動中，可能同時或依序使用多種媒體：

1. 客戶透過 App 文字聊天發起諮詢
2. 客服發現文字難以說明，邀請客戶升級為語音通話
3. 通話中需要確認證件，切換為視訊通話
4. 問題解決後，透過 App 推送確認訊息

上面這種在文字、語音、視訊之間切換的能力，叫媒體升降級（Media Escalation/De-escalation），是全渠道客服的關鍵。要做到，技術上有三個前提：統一的會話管理（同一個 Session ID 貫穿各渠道）、SIP re-INVITE 能變更媒體類型、WebRTC 能動態新增或移除媒體軌道。

螢幕共享與協同瀏覽 ​

技術說明適用場景
WebRTC Screen SharinggetDisplayMedia API客服引導客戶操作
協同瀏覽（Co-browsing）JavaScript DOM 同步共同瀏覽網頁
遠端桌面RDP / VNC over WebSocket技術支援

傳真的未來 ​

傳統傳真正逐步被其他技術取代：

替代方案說明
電子傳真（eFax）傳真轉 Email，Email 轉傳真
安全文件上傳Web 或 App 上傳文件影像
電子簽章取代需要簽名回傳的傳真用途
API 整合系統對系統的文件傳輸

規劃多媒體客服中心時，有幾個實務上的建議：先以語音為底、再逐步擴渠道；確保背後是同一套路由引擎在管所有渠道；視訊初期不必全開，先擺在特定場景（VIP 服務、遠端身分驗證）；文字渠道搭個 AI 自動回應（Chatbot），能明顯省下人力。

多媒體 QoS 建議 ​

各媒體類型的 QoS 需求 ​

媒體類型延遲要求丟包容忍頻寬需求DSCP 建議
語音< 150 ms< 1%31-87 kbps/通EF (46)
視訊< 200 ms< 1%500-3000 kbps/通AF41 (34)
即時訊息< 500 ms0%（TCP）極低AF21 (18)
傳真 (T.38)< 250 ms< 0.5%10-40 kbps/通AF31 (26)
螢幕共享< 300 ms< 2%500-2000 kbps/通AF31 (26)

頻寬規劃範例 ​

100 席客服中心，混合媒體使用情境：

渠道同時使用數每通頻寬總頻寬需求
語音通話80 通87 kbps7.0 Mbps
視訊通話10 通2000 kbps20.0 Mbps
螢幕共享5 通1000 kbps5.0 Mbps
即時訊息30 會話10 kbps0.3 Mbps
總計32.3 Mbps
含 30% 餘裕42 Mbps

承暉資訊資源中心

Copyright © 2026 承暉資訊