主頁 / Teams電話可否取代傳統PBX？ Teams電話可否取代傳統PBX？ 把辦公室電話搬上協作平台，表面上是換一部話機，實際上是把通話控制由機房搬到雲端服務。能否完全取代原有的PBX，關鍵不在功能表比較，而在三件事：對外線路如何接入、機房裡那些接着模擬線的裝置如何處理、以及網絡與供電是否支撐得住。本頁逐項說明架構分別與遷移前必須確認的條件。
兩種架構在通話路徑與管理方式上的根本分別 傳統PBX（Private Branch Exchange，專用小型交換機）是一部安裝在公司機房的交換設備。它一端接電訊商提供的外線，另一端接內部分機，所有撥號規則、分機號碼、響鈴群組與轉接邏輯都儲存在這部機器之內。通話的媒體流一般在建築物內部完成交換，只有對外通話才經過外線離開現場。
協作平台的電話功能走的是另一條路。以 Microsoft Teams 為例，Teams 是 Microsoft 365 的其中一個應用程式，本身已支援一對一與群組通話，這些平台內部的通話由 Microsoft 365 的雲端服務處理。要能撥打與接聽公眾交換電話網絡（PSTN）的號碼，還須為租戶加上 PSTN 連接，並為使用者配置 Teams Phone 授權。換言之，通話控制的位置由公司機房移到雲端租戶，話機或電腦客戶端只是註冊上去的終端。
設定的儲存位置 PBX 的設定寫在本機，改動要在現場或經遠端管理介面登入該部設備；雲端平台的通話行為由原則（policy）控制，可在全租戶、群組或個別使用者三個層級套用，管理入口是雲端管理中心或 PowerShell。
功能的開關方式 來電保留音樂、通話駐留、通話錄音一類功能，在雲端架構下透過原則開啟或關閉，而非在硬件上安裝授權板卡。連「可否撥打私人通話」本身都是一項通話原則設定，關閉後使用者的客戶端不會顯示通話功能。
終端的形態 PBX 年代的終端以專用話機為主，接線與型號綁定該品牌的交換機；雲端架構下的終端可以是電腦客戶端、手機應用程式，或經認證的實體話機，它們共用同一個使用者身分，撥出時顯示同一個號碼。
所以「取代」這個問法要拆開看。就日常內線通話、轉接、語音留言、群組響鈴而言，雲端平台的功能覆蓋一般辦公室的需要並無疑問；但PBX承擔的其他角色，例如接駁模擬線路的裝置、在斷網時仍維持本地通話，就不是靠功能表能夠對應的。這些差異在後面幾節逐項處理。
對外通話的三種接入方式與適用情況 雲端平台本身不會自動擁有電話號碼，對外通話必須另外接入。以 Teams Phone 為例，可行的路徑主要有三類，選擇哪一類直接決定工程範圍與供應商數目。
接入方式 號碼與線路由誰提供 需要的現場設備 Calling Plan 由平台供應商直接提供通話計劃與號碼 無須現場話務設備 Operator Connect 由參與該計劃的電訊商提供，於管理中心內配置 無須現場話務設備 Direct Routing 沿用公司自己與電訊商的中繼線合約 須自行提供受支援的工作階段邊界控制器（SBC）
官方文件對 Direct Routing 的定位說得相當直接：它讓客戶自行提供的 SBC 連接到平台的電話服務，從而以現場設備建立 PSTN 連接。適合採用這條路徑的情況有三種——供應商的通話計劃在該國家或地區未提供、機構需要接駁第三方模擬裝置或客戶服務中心系統、以及機構與電訊商仍有生效的中繼線合約。香港項目落在這三種情況的比例相當高，因此 Direct Routing 在本地屬常見選擇。
採用 Direct Routing 有一組明確的基建條件，遷移前必須逐項核對：一台受支援的 SBC、一條或多條接上該 SBC 的中繼線、一個可連接 SBC 的公網IP位址、一個完全限定域名（FQDN），而該域名的網域部分必須是租戶內已註冊的網域（不能使用系統自動建立的預設網域）、對應該 FQDN 的公共域名系統記錄，以及一張受公眾信任的證書供所有與平台之間的通訊使用。連接點為三個固定的域名，主要一個須先嘗試，其餘兩個依地理位置對應次選與第三順位區域。
這組條件的實際含意是：Direct Routing 並非「插線即用」，證書到期、域名系統記錄錯誤或防火牆未開放對應埠，都會令對外通話整批失效。因此部署時應把證書更新日期與負責人一併寫入維護記錄。
機房裡那些接着模擬線的裝置如何處理 遷移計劃最常卡住的一步，不是使用者的話機，而是機房牆上那一排接着兩芯電話線的舊裝置。這些裝置只認得模擬線路的電壓、振鈴與按鍵音，並不會註冊到雲端租戶，也不能改用軟件客戶端代替。
升降機廂內的緊急通話裝置 ——按下求助鍵之後通往管理處或保安室的線路，一般由升降機承辦商連同機廂設備一併安裝，屬於升降機安全裝置的一部分，不會為了電話系統升級而改動。消防泵房與水泵房電話 ——這類位置的線路屬固定裝置，改動需與相關承辦商協調。傳真機 ——物流報關、醫療轉介與部分政府表格仍以傳真作為正式往來方式，傳真機只有一個電話線接口。門口對講與電閘控制 ——以電話線接入的門鈴電話，按鈴後在分機聽筒按鍵開鎖。入侵警報主機的電話撥報線路 ——部分警報主機以模擬電話線把訊號送往中央監控中心。處理方式有兩條路。第一條是保留一台小型設備專責處理這些模擬埠：官方文件說明 Direct Routing 的用途時，明確包括在客戶自有話務設備（例如第三方 PBX、模擬裝置）與平台之間建立互通，即透過 SBC 把兩邊接起來，模擬裝置維持原有接線。第二條是把模擬裝置獨立成一組，繼續使用一至兩條電訊商的實體電話線，與雲端系統各行其路，適合裝置數量少且不需要與內線互通的情況。
要留意的是傳真在封包網絡上的表現與語音不同：傳真的訊號是資料而非人聲，經壓縮編碼處理後容易失真。若傳真量仍有實際業務需要，較穩妥的做法是保留一條實體線給傳真機，或改用電子郵件傳真服務，而不是假設它會隨語音一併正常運作。
公共區域的話機亦值得提早列出。走廊、貨倉出入口、會議室門外一類位置的話機沒有專屬使用者，雲端平台一般以「共用區域話機」的授權與帳戶方式處理，管理上與個人使用者不同，這部分的數量與位置應在勘察階段點清。
網絡、頻寬與供電：遷移前必須量度的條件 PBX 年代的通話品質主要取決於銅線與交換機；雲端架構下的通話品質等同於網絡品質。官方的網絡準備文件把三種常見徵狀與成因對應得很清楚：運作緩慢多與頻寬不足有關，通話中斷多與防火牆或代理伺服器阻擋有關，而聲音斷斷續續或聽起來像機械聲，則指向抖動或封包遺失。
頻寬方面，官方列出的每個終端用量參考值為：純語音的一對一通話與會議，最低每方向 10 kbit/s，建議值 58 kbit/s，最佳表現 76 kbit/s。這些數字看似很小，但要注意兩點：一是這是每個終端的用量，同一位使用者若同時以電腦與手機加入會議，就算兩個終端；二是辦公室的實際瓶頸多數不在語音本身，而在同時進行的視訊與畫面分享——視訊會議的建議值為每方向 2,500 kbit/s 下載 4,000 kbit/s，與語音相差兩個數量級。
虛擬私人網絡的處理 官方建議讓即時媒體流量繞過虛擬私人網絡。理由是這類網絡通常並非為即時媒體而設計，部分甚至不支援平台所需的UDP傳輸；此外它在已加密的媒體之上再加一層加密，並可能把流量繞經較遠的接入點，額外增加延遲與抖動。
服務質素設定 官方建議在受管理網絡的所有區段實施服務質素（QoS）以優先處理語音封包，並指出即使頻寬已足夠，QoS 仍能在網絡出現非預期事件時降低風險。
無線網絡 與虛擬私人網絡同理，無線網絡並非天生為即時媒體而設。官方建議實施 QoS 或無線多媒體（WMM）機制，確保媒體流量在無線側同樣獲得優先處理。
供電是另一項容易被忽略的條件。傳統PBX 有自己的後備電池，停電時內線通話往往仍可維持一段時間；雲端架構下，話機靠以太網供電（PoE）由樓層交換機取電，交換機又靠市電。若只為主機房的設備配置不斷電系統而忽略樓層交換機，停電時整層話機會同時失電。實際規劃時應把「哪一批話機在停電後仍須可用」寫成清單，再回推需要備援的交換機。
緊急通話、斷網風險與合規考慮 這一節的內容與功能多寡無關，而是關乎最壞情況下電話是否仍可撥通，屬於遷移方案必須交代的部分。
雲端架構下的緊急通話有一項結構性差異：號碼與地點不再綁定於一條實體線路。使用者帶着電腦或手機在不同地點登入，系統若不知道終端實際身處何處，緊急通話的處理便會出現落差。平台一般以緊急通話路由原則配合位置資訊處理這個問題，部署時需要為每個辦公地點登記地址，並確認外撥緊急通話時所帶的位置資料正確。多層辦公室應把樓層一併記錄，方便救援人員到場定位。
斷網風險是第二項。雲端架構的通話控制在雲端，互聯網中斷時，本地話機之間亦無法互相通話——這與傳統PBX 在斷網後仍可維持內線通話的行為明顯不同。對於通話中斷會直接影響營運的行業（例如需要接聽客戶落單的服務業、需要對外聯絡的診所），應考慮配置備援的互聯網線路，或保留少量實體電話線作為最後手段。單靠單一寬頻線路而把全部通話搬上雲端，屬於把營運風險集中在一個環節。
合規方面，通話錄音在雲端架構下由原則控制，開啟後錄音檔案儲存於雲端服務內。香港的實務重點在於：錄音涉及個人資料，收集、使用與保留期限受香港法例第486章《個人資料（私隱）條例》規範，需要有明確目的與告知安排。此外，通話明細與錄音的存取權應按職責分級，離職員工的權限要即時移除。這些安排與系統是否雲端無關，但雲端架構令資料存取更容易跨地域進行，因此更需要在原則層面寫清楚。
號碼方面，若公司希望沿用原有的固網號碼，需要處理攜號轉網的手續與時間表。攜號的申請與生效日期由電訊商安排，遷移計劃應把號碼生效日與話機到貨日分開處理，避免出現有話機而無號碼，或號碼已轉而終端未就緒的空窗期。
香港辦公室的實際取捨與遷移次序 香港的辦公環境有幾項特徵，直接影響這個決定的答案：租約期較短、單位面積小、樓宇樓齡分佈廣、而寬頻覆蓋普遍良好。以下按常見情況說明取捨。
甲級商業大廈的新單位裝修，是最適合直接採用雲端架構的情況。裝修期本身要重新鋪設網絡佈線，一次鋪好資料點位便可同時支援電腦與話機，省下另一套電話幹線；單位內若沒有升降機電話一類固定裝置的接駁需求，機房只需交換機與路由設備，佔用空間明顯減少。香港寫字樓租金按面積計算，機房縮小是實質的成本考慮。
舊式商業大廈與工廠大廈的情況相反。這類單位的既有電話線是多年前鋪設的兩芯線，網絡點位不足以令每個座位安裝話機；工廈單位面積大、樓底高，貨倉與裝卸區的話機位置往往遠離弱電櫃。這些情況下較實際的做法是混合部署：辦公區採用雲端架構，倉庫與特殊位置保留模擬話機並以設備接入，同時把升降機與泵房電話維持原狀。
診所、律師行與會計師行一類專業服務辦公室，重點在接聽不能漏。這類客戶通常話務量不高但每通電話價值高，適合的配置是雲端架構加上一條備援互聯網線路，並把總機的來電流向（未接時轉手機、午膳時段轉留言）在部署階段測試清楚。
至於遷移次序，建議按以下步驟推進：先做網絡評估，量度現有線路的延遲、抖動與封包遺失；再清點所有模擬裝置與公共區域話機；然後確認對外接入方式與號碼安排；接着在一個部門試行，觀察兩至四星期；最後才分批切換其餘部門，並在全部切換完成後才退掉舊線路。舊系統與新系統並行一段時間的成本，遠低於切換失敗後的補救成本。
回到最初的問題：對絕大多數以辦公室通話為主的香港公司而言，雲端平台的電話功能足以取代傳統PBX 的日常角色；但若現場仍有升降機電話、消防泵房電話或傳真等模擬裝置，或者營運不容許斷網後失去通話能力，答案便是「取代大部分，保留一小部分」，而這一小部分正是需要在勘察階段點清的內容。