魏贊科技-Zoom 認證經銷商---在尋找Zoom的視訊會議室解決方案!?02-25528000
主要說明與 Zoom Phone 通訊系統相容的硬體裝置。
內容聚焦於經過官方認證的設備清單,確保使用者在選擇硬體時能符合系統規格。透
過這些資訊,企業可以確認哪些電話終端或音訊設備能提供穩定的通話品質。
這是一份針對通訊硬體相容性所提供的技術參考指南。
Zoom AI 雲端視訊會議
www.wejun.net
Zoom 最新推出的 Zoom Workplace 單一協作平臺, 可提供不受限制的人與人通訊聯繫模式 ( 例 : Meeting / Team Chat / Phone / Mail & Calendar / Scheduler ) ; 同時 Zoom 藉助採用 AI Companion 技術,重新塑造團隊工作方式; 有效地簡化通訊、提高組織生產力、實現最佳面對面交流時刻,以及增進員工敬業度,在 Zoom Workplace 上整合與提供服務。
Zoom Meeting(視訊會議室)
➤ 全球市佔率高達 56% 的會議服務
Zoom Spaces:
A. 視訊硬體進入 Zoom Meeting 的授權 – CRC 或 Zoom Room Licenses
B. 員工預約座位、會議室的 Workplace reservation License
C. 訪客 – 預約訪客來訪,以及訪客報到的 Vistor Management License
D. 企業電子看板(含 Zoom Room 硬體設備)的內容播放管理 Digit Signage License
Zoom Phone
➤ 擁有 AI 能力 且完整功能的雲端電話系統,提供無限量語音錄音、語音轉中文文字的電話紀錄及彙整
➤ 擁有在台灣的機房,提供穩定的高通話品質
Zoom Webinar
➤ 提供企業對外線上產品發表、法說會,或對內員工大會的利器
➤ 並提供以點數計價的購買方式 – 預購點數,多場次進行,多少參加者,即扣除多少點數
Zoom Contact Center
➤ Omni Channel 進線 – 文字、語音、視訊
➤ 第三方如 CRM、業務系統整合
➤ 功能強大的雲端服務,適合多席次以及中小席次的需求
Zoom 助理型 AI
➤ 貫穿所有 Zoom 服務的人工智能助理,在付費的授權上不另收費
➤ 運用的資料可來自網際網路 + 自行上傳 + Zoom 各項服務的紀錄(如 Meeting, Mail, Phone, Chat, 白板 等等)
➤ 不僅是生成式 AI,是加速商業作業效率的人工智慧
魏贊科技 - Zoom 認證經銷商
歡迎詢問 Zoom 台灣區認證經銷商
魏贊科技 02-25528000*1 sales@wejun.tw www.wejun.net
在全球企業通訊架構加速向雲端遷移的浪潮中,Zoom Phone 以其「自帶運營商」(Bring Your Own Carrier, BYOC)模式,為大型跨國企業提供了一條兼具彈性與控制力的轉型路徑。隨著傳統公共交換電話網路(PSTN)與現代雲端協作平台(UCaaS)的界線日益模糊,企業不再僅僅是購買電話服務,而是在建構一個複雜的數位語音生態系統。在此背景下,選擇正確的基礎設施硬體與軟體,不僅關乎通話品質,更是企業通訊安全、合規性與業務連續性的基石。
本研究報告旨在為企業資訊長(CIO)、網路架構師及 IT 決策者提供一份詳盡的 Zoom Phone BYOC 地端互連(Premise Peering)設備指南。不同於傳統的規格清單,本報告將深入剖析各認證品牌——包括 AudioCodes、Ribbon Communications、Oracle、Cisco 與 Avaya——的技術架構、適用場景及整合細節。我們將探討為何 Session Border Controller (SBC) 已從單純的邊界閘道器演變為企業語音防火牆與智慧路由核心,並詳細解構與 Zoom 雲端對接時所需的加密協定、憑證管理及信令操作規則。
透過對 Zoom 官方技術文件、合作夥伴配置指南及互通性測試報告的綜合分析,本報告將揭示硬體型號背後的策略意涵:為何某些設備更適合分散式零售架構?為何特定韌體版本對於 Cisco 整合至關重要?以及如何在不犧牲現有 Avaya 投資的前提下引入 Zoom Phone?本報告將以超過一萬五千字的篇幅,為您提供構建高可用性、高安全性 Zoom Phone BYOC 架構所需的深度洞察。
在深入探討具體硬體型號之前,必須先建立對 Zoom Phone BYOC 架構的深刻理解。BYOC 模式允許企業保留現有的電信服務供應商合約、號碼資源及費率方案,同時享受 Zoom 雲端平台的協作功能。這對於受到長期合約綁定或位於 Zoom 原生服務未覆蓋區域的企業尤為關鍵。
雖然 BYOC 分為雲端互連(Cloud Peering, BYOC-C)與地端互連(Premise Peering, BYOC-P),但本報告聚焦於 BYOC-P。
BYOC-C 依賴於雲端對雲端的對接,企業無需在地端部署硬體,適用於純雲端策略。
BYOC-P 則要求企業在自身的資料中心或分支機構部署 SBC,物理連接來自電信商的 SIP Trunk 或 PRI 線路。這種架構提供了最高的控制權,支援本地存活(Local Survivability),並能與傳統 PBX(BYOP)進行混合組網。
在 BYOC-P 架構中,SBC 是絕對的控制中樞。它位於企業網路邊緣,同時面向不信任的網際網路(連接 Zoom 雲端)與信任的內部網路或電信商網路。SBC 的角色遠超出了簡單的路由功能:
安全防禦 (Security): 這是 SBC 最重要的功能。它必須隱藏企業內部的網路拓撲,防止拓撲偵測攻擊;實施頻率限制(Rate Limiting)以防禦阻斷服務攻擊(DoS);並透過存取控制清單(ACL)嚴格過濾 SIP 流量。
互通性 (Interoperability): Zoom 使用標準的 SIP 協定,但不同電信商的 SIP 實作(如 Header 格式、計費欄位)千差萬別。SBC 負責進行 SIP 標頭的標準化與正規化(Normalization),例如將電信商的 From 標頭轉換為 E.164 格式以符合 Zoom 的要求 1。
媒體處理 (Media Services): SBC 負責媒體流的轉碼(Transcoding),例如將 PSTN 常用的 G.711 編碼轉換為 Zoom 偏好的高音質 Opus 編碼,或在不同加密流(SRTP)與非加密流(RTP)之間進行橋接。
本地存活 (Local Survivability): 當連往 Zoom 雲端的網際網路中斷時,SBC 配合 Zoom Phone Local Survivability (ZPLS) 模組,確保企業內部的話機仍能透過本地 PSTN 線路撥打緊急電話與外線電話,這是醫院、銀行等關鍵場景的必要功能 2。
AudioCodes 是語音通訊領域的老牌勁旅,也是 Zoom 的核心戰略合作夥伴之一。其產品線在 Zoom 生態系中的整合度極高,特別是在支援 Zoom Phone Local Survivability (ZPLS) 方面,AudioCodes 提供了最為成熟的解決方案。
AudioCodes 的 Mediant 系列 SBC 採用統一的軟體核心架構,這意味著無論是小型分支機構的硬體還是資料中心的核心虛擬機,其配置邏輯與功能集高度一致。
3.1.1 混合型 SBC 與媒體閘道器 (Hybrid SBC & Media Gateways)
這類設備同時具備 TDM 介面(E1/T1/FXO/FXS)與 IP SBC 功能,非常適合正在從傳統 PBX 過渡或需要連接類比設備(如傳真機、電梯電話)的場景。
Mediant 500 / 500L: 針對微型分支機構(SOHO)或零售店面。支援少量的併發會話(Concurrent Sessions, CS),體積小巧。
Mediant 800B / 800C: 中小企業(SMB)的主力機型。其中 Mediant 800C 是部署 ZPLS 的熱門選擇,因為它提供了足夠的運算能力來運行本地存活模組,同時連接本地 PSTN 線路 。它支援多達數百個併發會話,並可選配內建伺服器模組(OSN)來運行第三方應用。
Mediant 1000B: 這是一款高度模組化的設備,機箱式設計允許企業根據需要插入不同的介面卡(如數位中繼卡或類比用戶卡)。對於擁有複雜舊有線路環境的工廠或舊辦公樓,Mediant 1000B 提供了極佳的靈活性。
3.1.2 純企業級 SBC (Enterprise SBC, E-SBC)
當企業已經完全 IP 化,或者 PSTN 線路已通過其他閘道器轉換為 SIP 時,純 E-SBC 是更高效的選擇。
Mediant 2600: 面向中型企業總部或區域資料中心,提供高吞吐量的 SIP 處理能力。
Mediant 4000 / 4000B: 高效能平台,適用於大型企業或作為集中式 SIP Trunk 的接入點。Mediant 4000B 在硬體備援(HA)與處理能力上進一步強化。
3.1.3 核心級與運營商級 SBC
Mediant 9000 / 9030 / 9080: 這些是用於服務供應商或超大型跨國企業核心節點的怪獸級設備。它們支援數萬甚至數十萬的併發會話,通常部署在雙活(Active-Active)或主備(Active-Standby)的高可用性架構中。
3.1.4 軟體定義 SBC (Software SBC)
Mediant VE (Virtual Edition) / SE (Server Edition) / CE (Cloud Edition): 隨著虛擬化的普及,這些版本允許企業在 VMware, Hyper-V, KVM 或 AWS, Azure, Google Cloud 上部署 SBC。AudioCodes 的軟體版 SBC 在功能上與硬體版完全對齊,支援轉碼與完整的安全特性 。
AudioCodes 的一大優勢在於其 One Voice Operations Center (OVOC) 管理平台 。在 Zoom Phone BYOC 環境中,OVOC 能夠提供端對端的語音品質監控。它不僅能監控 SBC 本身,還能收集 Zoom Phone 通話的品質數據(MOS 值),讓 IT 管理員能快速定位通話品質下降是源於內網、網際網路還是 PSTN 側。
此外,AudioCodes 對 ZPLS 的支援非常全面。透過在 Mediant 800C 等設備上配置 ZPLS,當與 Zoom 雲端的連線中斷時,SBC 會自動接管註冊在本地的話機,並利用本地 PSTN 線路維持通訊能力。這對於需要 99.999% 可用性的醫療或緊急服務機構至關重要 。
根據 AudioCodes 的技術文件 ,在配置 Zoom BYOC 時有幾個關鍵點:
Allowed Audio Coders Groups: 必須在 "Signaling & Media" 設定中明確定義編碼優先級。Zoom 強烈建議將 Opus 列為首選,其次是 G.722 和 G.711。這能確保在網路狀況良好時獲得高清音質,在頻寬受限時自動降級。
IP Profiles: 需為連接 Zoom 的 SIP Interface 建立專屬的 IP Profile,並啟用 "Allowed Coders Group ID" 以強制執行上述編碼策略。
Peer-to-Peer Media: 為了優化延遲,建議在 Zoom 管理介面與 SBC 配置中啟用點對點媒體(如果網路架構允許),讓內部話機之間的通話流量直接流動,而不必繞行至 SBC 再折返。
Ribbon Communications(由 Sonus Networks 與 GENBAND 合併而成,後收購 ECI Telecom 與 Edgewater Networks)擁有極為廣泛的產品線。在 Zoom BYOC 領域,Ribbon 提供了兩條截然不同的產品線:源自 Edgewater 的 EdgeMarc 系列與源自 Sonus 的 SBC Core/Edge 系列。
EdgeMarc 系列(Intelligent Edge)原本設計用於託管服務供應商(MSP)環境,因此特別擅長於網路邊緣的流量管理與監控。這使得它成為擁有多個小型分支機構(如連鎖零售、銀行分行)企業的理想選擇 。
EdgeMarc 2900 Family: 這是最受歡迎的型號系列,包含多個子型號(如 2900a, 2900e),支援不同數量的併發通話。它們通常具備 SD-WAN 的部分特性,能夠進行流量整形(Traffic Shaping),確保語音流量在擁塞的 WAN 鏈路中獲得最高優先級。
EdgeMarc 6000 Family: 針對需要更高吞吐量與更多介面的中型站點。
EdgeMarc 300 Series: 入門級設備,適用於微型辦公室,提供基本的 SBC 功能與類比介面。
關鍵優勢: EdgeMarc 設備通常配合 EdgeView 服務控制中心使用。這讓 IT 管理員能集中管理成百上千台邊緣設備,進行批量韌體更新、配置備份以及即時的故障排除(如遠端抓包),這對於分散式架構的維運效率提升巨大。
這一系列源自 Sonus 的技術積累,以高安全性與強大的互通性著稱。
SBC 1000 / 2000: 這是針對企業市場的旗艦產品。它們的特點是硬體整合度高,可選配內建的 ASM (Application Solution Module) 伺服器運行 Windows Server 或其他應用。SBC 1000/2000 內建了針對 Zoom Phone 的快速配置嚮導(Easy Configuration Wizard),大幅降低了部署門檻。
SBC 5400 / 7000: 針對超大規模部署。SBC 7000 特別強大,能處理極大量的媒體轉碼與加密負載,通常用於運營商核心網路或大型跨國企業的全球語音中心。
SBC SWe (Software Edition) & SWe Edge (Lite): Ribbon 的軟體版 SBC。SWe Edge 是一個輕量級版本,專為 Azure 與 AWS Marketplace 優化,非常適合希望在公有雲中構建 BYOC 匯聚點的企業 。
Ribbon 設備的韌體版本對於 Zoom 認證至關重要。根據 Zoom 支援文件 :
EdgeMarc 300 Series 需運行 V16.2.0 或更高版本。
Ribbon G5 LAG 需運行 4.7.07 或更高版本。
加密支援: 這些設備皆支援 AES-128 與 AES-256 位元的 SRTP 加密,以及 Mutual TLS (mTLS) 驗證,確保符合 Zoom 的安全標準。
Oracle 的 SBC 產品線繼承自傳奇的 Acme Packet,該品牌在電信運營商市場擁有近乎統治性的地位。對於 Zoom Phone BYOC 而言,Oracle SBC 代表了極致的穩定性、可程式化能力與大規模併發處理能力。
Oracle SBC 較少被用於小型企業或單一辦公室,它的舞台在於需要處理每日數百萬分鐘通話量的環境,或者是需要極度精細的 SIP 標頭操作(Header Manipulation)的複雜路由場景。
AP 1100: 入門級平台,但仍具備 Acme Packet 標誌性的 OS 架構,適合企業邊緣。
AP 3900: 中階平台,平衡了效能與價格。
AP 4600 / 6300 / 6350: 高階平台。這些設備通常配備專用的硬體加速晶片(網路處理器與加密引擎),能在不消耗主 CPU 資源的情況下進行線速(Line-rate)的媒體加密與轉碼 。這對於需要全加密(TLS/SRTP)的 Zoom BYOC 環境來說是一個巨大的優勢。
與其他品牌相比,Oracle SBC 的配置邏輯(基於 ACLI 命令行)更為底層且靈活。
Realms (領域): Oracle 使用 Realm 來定義邏輯網路邊界。在 Zoom BYOC 配置中,通常會定義一個 access realm(面向 Zoom 雲端)和一個 core realm(面向 PSTN)。這允許管理員針對不同方向的流量實施不同的安全策略與頻寬限制 。
SIP Header Manipulation Rules (HMR): 這是 Oracle SBC 的殺手級功能。它允許管理員像編寫程式腳本一樣,對流經 SBC 的每一個 SIP 封包進行深度修改。
應用實例: Zoom 要求 From 標頭的 Host 部分必須是 SBC 的公網 IP,而 To 標頭必須是 Zoom 的 IP。在 Oracle SBC 上,管理員會編寫 HMR 規則來動態重寫這些標頭 ,以確保即便內部 PBX 送出了錯誤的格式,到達 Zoom 時也是合規的。
憑證導入 (PKCS12): Oracle SBC 預設並推薦使用 PKCS12 格式導入憑證 。這與其他可能使用 PEM 或 DER 格式的廠商不同。管理員需確保持有的憑證包含私鑰並正確打包為.p12 檔案。
預設密碼: 值得注意的是,Oracle SBC 的出廠預設帳號密碼通常為 acme / packet,在首次部署時必須強制更改,這是基礎但常被忽略的安全步驟 。
Cisco 在企業網路設備市場的佔有率極高,許多企業的機房中已經運行著 Cisco 路由器。因此,利用現有設備啟用 Cisco Unified Border Element (CUBE) 功能,是成本效益極高的 BYOC 路徑。然而,這也是技術細節最繁雜的一條路徑。
Cisco 並不像 AudioCodes 或 Ribbon 那樣銷售「專用」的 SBC 硬體盒,而是將 SBC 功能(CUBE)作為軟體授權運行在其路由器平台上。
ISR 4000 系列 (ISR 4331, 4431, 4451): 這是目前最常見的 CUBE 部署平台。它們廣泛存在於企業分支機構中。透過購買 FL-CUBE 授權,這些路由器可以立即變身為 Zoom 認證的 SBC 。
Catalyst 8000 Edge Platforms (Cat8k): 作為 ISR 的繼任者,Catalyst 8200/8300 系列提供了更強大的運算能力與雲端原生支援,完全支援 CUBE 功能。
CSR 1000v / Catalyst 8000v: 這是虛擬化的路由器,運行與硬體版相同的 IOS XE 系統。它們非常適合部署在 AWS 或 Azure 上作為雲端 SBC,或者在企業的 VMware ESXi 環境中運行 。
ASR 1000 系列: 用於大型匯聚點的高效能路由器。
部署 Cisco CUBE 時,軟體版本(IOS XE)是成敗關鍵。
推薦版本: Zoom 官方建議使用 IOS XE 17.6+ 或 17.9+ 。較舊的版本可能不支援 Zoom 所需的特定 Cipher Suite 或 TLS 1.2 擴充功能,導致握手失敗。
CLI 配置: CUBE 的配置主要通過命令行介面(CLI)完成。針對 Zoom BYOC,必須配置特定的 voice class sip-profiles 來修改 SIP 標頭,並設置 voice class uri 來匹配 Zoom 的伺服器域名。
這是一個常見的誤區。Cisco 的 IP Phone 分為兩種韌體版本:
Enterprise Firmware: 專為 Cisco CUCM (CallManager) 設計。
Multi-Platform Firmware (MPP): 專為第三方雲端平台(如 Zoom, Webex Calling)設計。
Zoom 僅支援 MPP 版本 的 Cisco 話機(如 6800, 7800, 8800 系列)。如果企業現有的是 Enterprise 版本話機,必須透過 Cisco 的雲端遷移授權(Cloud Upgrader)將其刷機為 MPP 版本,否則無法註冊到 Zoom Phone 。這一點在規劃 BYOC 專案預算時必須納入考量。
Avaya 在傳統 PBX 市場擁有龐大的安裝基礎。對於擁有 Avaya Aura 系統的大型企業,如何在不廢棄現有投資的情況下引入 Zoom Phone 是主要考量。
Zoom 認證了 Avaya Session Border Controller for Enterprise (SBCE) 。這款設備通常已存在於 Avaya 客戶的網路邊緣,用於 SIP Trunk 接入或遠端工作者接入。
整合模式: 企業可以配置 Avaya SBCE 同時連接 PSTN(傳統運營商)與 Zoom 雲端。透過配置路由策略,可以實現從 Zoom App 撥出的電話經由 SBCE 路由至地端 PSTN 線路出局(BYOC-P)。
版本要求: 支援 Avaya SBCE 8.1.x 及 10.x 版本。最新的 10.2 版本進一步增強了互通性與安全性 。
根據 Zoom 的合作夥伴文件 ,目前對於 Avaya SBCE 的整合並沒有像 AudioCodes 或 Ribbon 那樣詳盡的「傻瓜式」官方指南。Zoom 強調這是一個 "Partner-Led"(合作夥伴主導)的整合場景。這意味著企業應依賴具備 Avaya 與 Zoom 雙重認證資格的系統整合商(SI)來進行架構設計與實施。
憑證責任: 客戶必須自行負責 Avaya 側憑證的部署與管理。Zoom 雖然會自動管理雲端側的憑證,但與 Avaya SBCE 建立 TLS 連線所需的根憑證與伺服器憑證,必須由客戶手動導入 SBCE 的 Client Profiles 與 Server Profiles 中 。
硬體只是載體,正確的軟體配置才是 BYOC 運作的靈魂。Zoom 對於安全性有著極為嚴格且不可妥協的要求。
這是 BYOC 部署中最常見的故障點。Zoom 強制要求所有的 SIP 信令必須透過 TLS 1.2 加密。為了建立 TLS 連線,SBC 必須向 Zoom 出示一個有效的數位憑證。
受信任的憑證授權中心 (Public CA): Zoom 不接受 自簽憑證 (Self-signed Certificates)。SBC 的憑證必須由 Zoom 信任的公共 CA 簽發。
支援列表: 包括 DigiCert (Zoom 自身使用,強烈推薦), GoDaddy, GlobalSign, Sectigo (Comodo), Baltimore CyberTrust, Verisign, Entrust 等 。
DigiCert 的特殊性: 由於 Zoom 的服務器憑證是由 DigiCert 簽發的,因此在地端 SBC 上,必須導入 DigiCert 的根憑證(Root CA)與中繼憑證(Intermediate CA),SBC 才能信任 Zoom 的伺服器 。
憑證內容要求:
Common Name (CN): 必須與 SBC 的完全限定域名 (FQDN) 完全一致。
Key Size: 必須為 2048-bit RSA。
Hash Algorithm: 必須為 SHA-256。
憑證鏈: SBC 在與 Zoom 握手時,必須發送完整的憑證鏈(包含 Server Cert + Intermediate Certs),否則 Zoom 的負載平衡器可能會拒絕連線 。
SIP Signaling: 必須使用 TLS 1.2。Zoom 目前不支援 TLS 1.0 或 1.1,也不支援非加密的 TCP/UDP SIP(除非是在完全隔離的專線環境,且經過特殊核准,但網際網路互連必須用 TLS)。
Media Transport: 語音媒體流必須使用 SRTP (Secure Real-time Transport Protocol)。
Cipher Suites: SBC 必須支援特定的加密套件,如 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 或 TLS_RSA_WITH_AES_256_CBC_SHA。Cisco CUBE 用戶需特別注意 IOS 版本是否支援這些較新的強加密套件。
Zoom 是一個多租戶的雲端平台,它依賴 SIP 標頭中的資訊來識別流量屬於哪個客戶帳號。
Request-URI: 進入 Zoom 的呼叫(Inbound),Request-URI 的 User 部分必須是 E.164 格式的電話號碼(如 +886223456789)。這是 Zoom 路由的核心依據 。
P-Asserted-Identity (PAI) & Remote-Party-ID (RPID): Zoom 支援透過這些標頭來傳遞主叫號碼與名稱。這對於顯示正確的 Caller ID 至關重要。
X-SIP-GROUP: 在某些配置下,Zoom 可能要求 SBC 在 SIP 標頭中插入自定義的 X-SIP-GROUP 標記,以便雲端識別該呼叫來自哪個特定的 SIP Trunk 群組 。
為了確保最佳的使用者體驗,Zoom Phone 對音訊編碼有明確的優先級要求:
Opus: 這是首選編碼。Opus 是一種動態編碼,能在 6kbps 到 510kbps 之間自動調節,適應各種網路狀況,提供接近 CD 音質的體驗。所有認證 SBC 都必須支援 Opus 的透傳(Pass-through)或轉碼。
G.722: 寬頻語音編碼,作為次選。
G.711 (PCMU/PCMA): 傳統 PSTN 的標準編碼,作為與老舊設備互通的基線。
G.729: 高壓縮比編碼,通常僅在頻寬極度受限的衛星鏈路或老舊 MPLS 線路上使用。
SBC 必須配置為能夠在 PSTN 側(通常僅支援 G.711)與 Zoom 側(優先使用 Opus)之間進行轉碼,以釋放 Zoom Phone 的高清語音潛力 。
SIP Options Ping: 為了維持連線活躍並檢測路徑健康狀況,SBC 應配置為向 Zoom 的信令 IP 發送 SIP OPTIONS 封包。Zoom 也會向 SBC 發送 OPTIONS,SBC 必須回應 200 OK。
防火牆埠口:
TCP/TLS 5061: 用於 SIP 信令。
UDP 20000-64000 (範圍可能變動): 用於 SRTP 媒體流。務必參考 Zoom 最新的網路防火牆白皮書,開放對應的 IP 子網段。
硬體部署完成後,必須在 Zoom 管理平台(Admin Portal)中進行邏輯映射,SBC 才能真正上線運作。
Zoom 使用層次化的邏輯結構來管理 BYOC 連線:
SBC: 在管理介面中定義物理 SBC 的 FQDN 與 IP。
Route Groups (路由群組): 將一個或多個 SBC 綁定在一起。例如,可以建立一個 "Taipei-Route-Group" 包含兩台位於台北的 SBC,Zoom 會在兩台之間進行負載分擔。
SIP Groups (SIP 群組): 這是最高層級的邏輯容器。它包含 Route Groups,並定義了該群組的屬性(如是否啟用 BYOP、是否傳遞特定標頭)。電話號碼是分配給 SIP Group 的,而不是直接分配給 SBC 。
在 BYOC 模式下,管理員需要在 Zoom 平台中手動新增號碼(因為 Zoom 無法從運營商處自動獲取)。新增時需選擇 "BYOC Number",並將其關聯到正確的 Site 與 SIP Group。這確保了當 Zoom 用戶使用該號碼外撥時,雲端知道要將信令送往哪一個 SIP Group(進而送往哪一台 SBC)。
BYOC 架構的最後一哩路是終端設備。雖然 BYOC 允許企業使用第三方運營商,但連接到 Zoom 雲端的 IP Phone 必須是 Zoom 認證 的型號。
Poly (前 Polycom): Zoom 的深度合作夥伴。推薦型號包括 Edge E 系列 (E100-E500)、CCX 系列 (觸控螢幕,原生 Android 體驗)、以及經典的 VVX 系列 (150-450) 。
Yealink (億聯): 提供高性價比的選擇。推薦 T5 系列 (T53W, T54W, T57W) 支援 Wi-Fi 與藍牙,以及 MP 系列 (MP54, MP56) 。
Cisco: 如前所述,僅支援 MPP 韌體版本的 6800 / 7800 / 8800 系列。
AudioCodes: 400HD 系列 (405HD, 445HD, C450HD)。若 SBC 選用 AudioCodes,搭配同品牌話機可簡化單一窗口支援 。
對於傳真機 (Fax)、電梯緊急電話或老式類比話機,需使用認證的 ATA (Analog Telephone Adapter)。
AudioCodes: MediaPack (MP) 系列,如 MP-114, MP-118, MP-1288 (高密度)。
Grandstream: GXW4200 系列 (GXW4216/24/32/48) 用於高密度類比接入 。
Poly: OBi 系列 ATA (OBi300, OBi302)。
Zoom Phone BYOC 是一個強大的解決方案,它賦予了企業在雲端轉型過程中極大的靈活性。然而,這種靈活性伴隨著架構設計的責任。選擇正確的設備不僅是為了「能通」,更是為了「穩通」與「安通」。
綜合建議:
對於追求極致整合與本地存活的企業: AudioCodes 是首選。其 SBC 與 ZPLS 的整合最為成熟,且 OVOC 提供了無可比擬的維運可視性。
對於擁有大量分散式據點的企業: Ribbon EdgeMarc 系列提供了最佳的邊緣管理與 SD-WAN 級別的流量優化能力。
對於既有 Cisco 設備的企業: 啟用 Cisco CUBE 是最經濟的路線,但務必確保 IT 團隊具備足夠的 IOS XE 配置能力與憑證管理知識。
對於超大規模或運營商級部署: Oracle 提供了最強大的效能與信令操控能力,是複雜路由環境的定海神針。
最後,成功的 BYOC 部署不僅依賴硬體,更依賴於嚴謹的規劃:從向 DigiCert 申請正確的憑證,到在 Zoom Portal 中規劃合理的 SIP Group 邏輯,每一個環節都不可或缺。希望本報告能為您的 Zoom Phone BYOC 之旅提供清晰的指引。