- 首頁
- /
- 文章
感謝您的意見回饋。
移轉部署指南
在此文章中
意見回饋？結構化遷移程序從內部部署 Cisco Unified CM 到雲端架構 Webex Calling，利用 PPDIO 方法。這涉及重要的設計考量 例如地區選擇，撥號計劃，緊急服務和通話記錄。這個過程也 詳細說明授權、使用者佈建、SSO 和網路準備，以確保順暢和 有效的過渡。
在開始之前
本指南適用於有設定和管理 Cisco Unified Communications Manager (Unified CM) 和 Cisco 終端機（包括 IP 桌上型電話、視訊設備和 Jabber 軟體用戶端）經驗的團隊或個人。本文檔中提供了指向產品和支援文件的鏈接，以提供協助。
本文檔僅關注從 Unified CM 到 Webex Calling 多租戶的過渡。本文檔中的術語 Webex Calling 始終指 Webex Calling 多租用戶。
在開始從 Unified CM 遷移到 Webex Calling 之前，必須全面了解 Webex Calling 解決方案及其個別元件。成功遷移需要熟悉 Webex Calling 的架構、服務模型、部署選項和相關功能，以便正確對應現有的 Unified CM 工作負載並設計有效的過渡計畫。
要製定有效的過渡策略和營運準備，必須透徹了解以下 Webex Calling 元件。
-
Control Hub
-
目錄和使用者配置
-
Webex通話平台
-
支援的呼叫端點
-
PSTN 連線選項
-
Webex Calling撥號方案和號碼管理
-
安全性和合規性功能。
更多信息，請參閱 Cisco Webex Calling 首選架構。
本指南將重點放在轉型生命週期中可使用的工具和流程。然而，從本地通話系統 Unified CM 過渡到新的雲端通話平台 Webex Calling 可能是一項重大工程，並可能面臨業務、技術和複雜方面的挑戰。為了幫助您克服這些挑戰，思科提供了一些不同的選擇來協助您完成您的轉型之旅。請務必查看 企業雲端呼叫 - 呼叫遷移 中的信息，以了解每個選項以及每個選項如何幫助您進行自己的遷移。
-
Webex遷移工具： Control Hub 內建了自助式免費工具，可簡化您向 Webex Calling 的轉型。
-
認證的移民服務提供者： Cisco 已驗證了開發遷移解決方案的軟體和工具供應商，這些解決方案可協助 Webex 合作夥伴和客戶進行複雜和大規模的遷移。這些解決方案可以幫助簡化、管理和加速向 Webex Calling 的過渡。
-
Webex 設定助手： 思科主導的遷移服務，指導客戶和合作夥伴完成 Webex Calling 的部署和配置，這是將 Unified CM 使用者和服務成功遷移到 Webex Calling 所必需的。
概覽
隨著雲端交付協作服務的成長，越來越多的客戶希望將現有的協作工作負載遷移到雲端，因為雲端服務具有降低整體擁有成本、簡化管理、持續功能交付、提高規模和增強可靠性等優點。當客戶考慮從本地部署過渡到雲端協作服務時，了解過渡過程涉及哪些方面以及過渡所需的步驟至關重要。
本文檔的目的是為希望從本地統一 CM 過渡到雲端 Webex Calling 的客戶提供部署指導。本部署指南假定讀者對 Unified CM 和 Webex Calling 之間的呼叫轉換有基本的了解，包括進行此轉換時會發生哪些變化，以及將呼叫工作負載從本地遷移到雲端時會有哪些不同。在繼續操作之前，請確保您已查看並熟悉 過渡圖中提供的資訊。這份過渡路線圖文件提供了有關此次過渡期間的變化和差異的資訊。
如圖 所示，本地協作架構：呼叫控制和遠端存取，典型的本地部署包括網路上的不同協作基礎架構元件、呼叫控制平台、邊緣平台、硬體和軟體終端，在某些情況下甚至包括會議和日程安排平台。在思科架構中，這包括用於呼叫控制的統一呼叫管理 (Unified CM)、用於遠端存取和企業對企業 (B2B) 邊緣服務的 Expressway 以及思科會議伺服器 (Cisco Meeting Server)。 / Cisco Meeting Management 用於本地會議，Unity Connection 用於語音訊息傳遞，以及面向使用者的硬體（Cisco IP 電話、Cisco 桌面和會議室視訊系統）和軟體（Cisco Jabber）基於 IP 的終端。這些元件在某些環境中可能會略有不同，但這是本文檔其餘部分所描述的過渡的起點。
圖 所示的架構為本地協作架構：呼叫控制和遠端存取 基於 Cisco Collaboration Enterprise 本地部署的首選架構 (PA)。有關企業本地部署的更多信息，請參閱 Cisco 協作首選架構。
之前：本機呼叫基礎架構元件 表列出了在過渡到雲端 Webex Calling 之前本地架構的關鍵要素。
| 產品 | 說明 |
|---|---|
| Unified CM | 本地呼叫控制提供設備註冊和呼叫路由服務 |
| 思科 Expressway-C/E | 邊緣基礎設施提供行動和遠端存取 (MRA) 以及企業對企業 (B2B) 功能，使遠端端點能夠從組織外部安全連接。Expressway 成對部署，提供外部端點防火牆穿透功能。 |
| Cisco Meeting Server (CMS)、Cisco Meeting Management (CMM) 和 Cisco Telepresence Management Suite (TMS) | 提供本地語音、視訊和網路會議基礎設施，支援多點會議、會議管理和日程安排功能。[Optional] |
| Cisco Unity Connection | 提供語音郵件和統一訊息功能的本地語音訊息平台。[Optional] |
| Cisco Desk、Cisco Room、Cisco Board、Cisco IP Phones 與 Cisco Jabber | 已註冊到 Unified CM 並提供語音和視訊通話功能的基於 IP 的設備 |
如圖 所示，過渡決策：對於擁有 Unified CM 和桌面及視訊 IP 端點的本機呼叫控制的客戶，他們可以選擇將架構過渡到 Webex Calling雲端架構。
該決定需要根據客戶的功能需求來做出。有以下需求的客戶在做出決定前應仔細考慮，並最終可能決定將呼叫控制保留在本地：
- Webex Calling 不支援的手機型號
- 與其他本地系統或解決方案的複雜或眾多集成，尤其是在難以用 Webex Calling 複製這些集成，或沒有等效替代解決方案的情況下，會非常棘手。
- 複雜的撥號方案、高度細化的服務等級或兩者兼有
- 受限、有限或不可靠的網路存取
- 嚴格的資料隱私和所有權政策
- 本地或境內媒體錄製和儲存的合規性要求
- 第三方集成，但沒有可行的替代 Webex Calling 集成方案
- 聯絡中心集成，其中聯絡中心集成尚未遷移到雲端。
本文檔主要針對已部署 Unified CM 呼叫控制的客戶，旨在協助他們了解啟用 Webex Calling 部署的一般步驟、注意事項和要求，如下一節所述。
核心組件
此次遷移的目標架構包含多個新元件。這包括用於基於雲端的通話的 Webex Calling 服務、Webex App、用於身分整合的 Cisco Directory Connector 和用於 PSTN 存取的本地網關 (LGW)，以及本地到雲端的通話整合。Cisco 通話計畫或由 Cloud Connect for Webex Calling 合作夥伴提供的雲端連線 PSTN (CCP) 是 PSTN 存取的其他選擇。
如圖 所示，之後：Webex Calling 架構，新元件（Webex Calling、目錄連接器、本機閘道和生存能力閘道）會被加入到現有的本機部署。
之後：雲端呼叫基礎設施元件 表列出了過渡到 Webex 後架構的新元素。
| 產品 | 說明 |
|---|---|
| Webex Calling | 基於 Webex 平台的雲端通話服務，提供終端機註冊和呼叫路由功能。 |
| Cisco 目錄連接器 | 執行在 Windows 網域電腦上的 Windows 應用程序，提供企業本機 Active Directory 和 Webex 組織的身份儲存之間的身份同步。 對於從本機 Active Directory 遷移到 Entra ID 的客戶，與 Webex 而不是 Cisco Directory Connector 的身分整合使用 Entra ID Wizard 應用程式。 |
| 本端閘道 | 本地網關可作為客戶本地統一通訊網路和 Webex Calling 雲端之間的橋樑。它可以部署在本地或由合作夥伴託管，為雲端註冊端點提供 PSTN 訪問，以及 Unified CM 註冊端點和雲端註冊端點之間的呼叫整合。Cisco IOS-XE 整合服務路由器（ISR 1100 與 4000 系列）、Cisco Catalyst 8200/8300 Cisco Catalyst 8000V Edge 軟體系列以及各種經過認證的第三方會話邊界控制器 (SBC) 可用作分階段遷移方法的 LGW。 |
| 生存能力閘道 | 生存網關 (SGW) 是一個基於本機網路 IOS-XE 的網關，可在網路中斷期間為現場 Webex Calling 端點提供回退呼叫服務。 |
| Cisco 通話計劃，Webex 通話雲端連接 | Cisco Calling Plan 和 Cloud Connect for Webex Calling 是 Webex Calling 端點的基於雲端的 PSTN 存取選項。PSTN 存取由雲端 PSTN 供應商提供，無需任何本地設備。 |
| Webex 應用程式 | 用戶端應用程式運行於桌面作業系統（Windows、Mac）或行動作業系統（Android、iOS）上，並直接註冊到 Webex Calling 平台以實現通話功能。 |
PPDIO流程概述
PPDIO 流程代表 準備、規劃、設計、實施和最佳化。這是思科提供的結構化方法論，指導專案從初步評估到持續改進，確保高效、成功的部署或遷移。
PPDIO概述
-
準備： 評估當前環境，收集需求，並協調利益相關者，以建立堅實的基礎。
-
方案： 制定詳細的專案計劃，包括時間表、資源和風險緩解策略。
-
設計： 根據業務和技術需求，設計目標解決方案。
-
實施： 根據設計執行部署或遷移，並驗證功能和效能。
-
最佳化: 實施後，透過監控效能、改進配置以及利用自動化和整合工具，不斷改進解決方案。
使用 PPDIO 進行 Unified CM 到 Webex Calling 的遷移項目
從 Unified CM 過渡到 Webex Calling 時，PPDIO 流程提供了清晰的路線圖，以確保平穩高效的過渡：
準備
-
評估現有的統一配置管理環境和遷移準備情況
-
收集有關使用者、裝置、網路和依賴關係的詳細數據
-
收集位置詳細信息，包括緊急響應地址、用戶數量、互聯網接入情況、公共交換電話網路接入情況
-
識別風險並明確專案範圍，以協調所有利害關係人。
方案
-
制定包含批次計畫、資源分配和時間表的全面遷移計畫。
-
定義諸如設備韌體升級、許可證配置和用戶入職等任務
-
與思科及合作夥伴協調遷移時間，以最大程度地減少中斷。
設計
-
將目前 Unified CM 設定、撥號方案和使用者設定檔對應到 Webex Calling 的對應項
-
設計 Webex Calling 環境，包括 PSTN 策略（臨時和最終方案）、位置、使用者角色以及整合點，例如本地網關 (CUBE) 和目錄同步。
-
制定在遷移過程中 Unified CM 和 Webex Calling 同時運作的共存方案。
執行
-
使用 Control Hub 遷移工具以及第三方工具來執行裝置韌體模式變更、功能配置和使用者遷移。
-
利用 Webex API 進行批量操作和配置，以簡化大規模遷移和配置。
-
執行許可證配置、設備註冊和配置更新
-
透過測試和運行驗證來確認遷移是否成功。
最佳化
-
持續監控 Webex Calling 的效能與使用者體驗
-
根據營運數據和回饋改進配置和工作流程
-
利用自動化和整合功能來提高效率和可擴展性
-
根據需要停用舊版統一配置管理元件，並為日常營運提供持續支援。
這種增強型 PPDIO 方法可確保從 Unified CM 到 Webex Calling 的可控、透明和高效遷移，利用 Cisco 的工具、API 和合作夥伴生態系統來維持業務連續性並提高協作能力。
PPDIO回饋迴路
圖 中所示的高階概述在執行 PPDIO 時進行了迭代，展示了從 優化 階段到 準備 階段的單一回饋迴路。這意味著，在初步實施之後，仍有持續改進的機會。每次優化週期都可以發現新的需求或需要改進的領域，這些需求或領域可以透過後續的專案或計劃來解決。這些單獨的專案又各自遵循既定的 PPDIO（準備、規劃、設計、實施、最佳化）生命週期。這種迭代方法確保系統始終與不斷變化的業務目標和技術進步保持一致，從而培養持續改進和適應的文化。
在 PPDIO 流程的執行過程中，後期階段的調查結果通常需要重新審視並可能修改早期階段所做的決定。例如，在實施階段遇到的問題，例如發現設計歧義或缺失的細節，可能會揭示某些方面在設計階段沒有充分解決。在這種情況下，必須回到相關的先前階段來解決這些問題，然後再繼續進行。如圖 所示，統一配置管理輔助 PPDIO 流程 中的這種迭代反饋機制確保解決方案得到徹底驗證和完善，最終有助於實現更穩健、更有效的部署。
從 Unified CM 過渡到 Webex Calling 時，PPDIO 流程的每個階段都可以從現有 Unified CM 環境中收集的資訊中獲益匪淺。例如，可以從目前的統一 CM 配置中提取使用者、電話號碼、呼叫功能和撥號計劃組件的全面清單。這些數據是對利害關係人直接提供的資訊的補充，有助於簡化規劃和設計活動。利用合適的工具實現資料擷取和分析的自動化，不僅可以提高準確性，還可以加快整個流程。透過利用現有部署的洞察，向 Webex Calling 的過渡可以比傳統的全新實施更有效率地執行，同時仍遵循結構化的 PPDIO 方法。過程如圖 統一 CM 輔助 PPDIO 過程所示。
遷移方法
在規劃從本地統一內容管理過渡到 Webex Calling 時，您需要確定如何著手進行此過渡過程。首先，您需要決定遷移方式是採用 閃速 （一次全部遷移）還是 分階段 （分批遷移） users/devices 在較長一段時間內）。
執行 快速 遷移可以最快遷移所有使用者和裝置。透過此方法，您可以同時將所有使用者和裝置從本機 Unified CM 遷移到 Webex Calling。從本質上講，它為所有用戶和設備提供了一個統一的遷移視窗。遷移完成後，您的所有使用者和裝置都會遷移到 Webex Calling 平台，並且您的所有 Unified CM 基礎架構都可以停用。然而，由於呼叫部署的規模和範圍，許多組織無法採用這種方法。
第二種方法是 分階段 遷移。大多數組織都會採用這種方法，因為它能更好地控制、管理和擴展遷移規模。此外，它也更適合大規模統一通訊部署。 and/or 跨多個區域部署。因此，本文檔重點介紹 分階段實施的過渡方法 ，該方法包含兩個過渡步驟。
如圖所示 分階段呼叫轉換：混合雲，第一個過渡階段（階段 1）將實現具有雙重呼叫環境的共存部署。在此階段，部分使用者、裝置和軟體用戶端將過渡到 Webex Calling，而其他使用者、裝置和軟體用戶端仍將使用本機 Unified CM 呼叫控制。最終過渡階段（第二階段）將形成一個純粹的雲端通話環境，其中所有使用者、裝置和軟體用戶端都已完全過渡到 Webex Calling 平台。
組織完全過渡到雲端呼叫所需的時間取決於其目前的部署情況。在某些情況下，組織可能會進行初步過渡，並在共存雙呼叫控制階段（階段 1）保持較長時間（數月甚至數年），而在其他情況下，組織可能會在很短的時間內（數週或數月）完全過渡到 Webex Calling（階段 2）。本文檔旨在涵蓋兩個階段（第一階段－共存，第二階段－完全過渡）。
有些組織可能會無限期地維持雙重呼叫控制共存部署，而沒有計劃完全過渡到雲端呼叫。
第二個需要考慮的問題是如何將使用者、裝置和軟體客戶端從本地呼叫控制過渡到雲端呼叫控制。建議採用三階段過渡方案。下圖 建議的 3 階段轉變 將此方法分解為 3 個階段。
遷移前： 此階段的重點是為遷移做好 Webex 和 Unified CM 環境的準備。這不是關於具體的規劃或配置，而是專注於完成現在可以在任何 Webex Calling 遷移專案開始之前完成的活動。目標是為兩個環境的遷移奠定基礎。
移民準備： 在這個階段，我們將開始為遷移到 Webex Calling 做準備。此處需要審查和更新業務和技術需求。不要只是簡單地將目前使用 Unified CM 部署的內容進行 遷移 ，而是利用 Webex Calling 的強大功能，重新定義貴公司現在和將來所需的業務和技術要求。此外，在這個階段，您將完成設計、配置規劃和遷移。 planning/schedule.
遷移（部署和停用）： 在這個階段，用戶、裝置、電話號碼和軟體客戶端將實際遷移。如上所述，此階段可以一次完成（閃切），也可以分多個變更視窗完成（分階段切割）。最終用戶採納計劃、培訓和溝通至關重要，這樣您的用戶才能了解變化、如何使用新的通話平台以及何時進行更改。最後一步是停用所有不再使用的本地統一通訊基礎設施。
遷移前階段包含一些活動（必需的、建議的和可選的），您可以立即開始進行這些活動。建議儘早完成這些工作，最好是在專案開始之前完成。有些活動可能需要更長時間才能完成，因此儘早開始這些活動將有助於簡化您的實際遷移專案。
下圖 遷移前活動 突顯了與 Webex Calling 遷移相關的五類具體活動。
準備
業務和技術要求
在計劃從 遷移到 時，在計劃階段徹底收集技術和業務需求至關重要。這一步驟確保遷移與貴組織的營運目標和技術能力保持一致，從而最大限度地降低風險和中斷。
為什麼收集需求很重要：
-
使業務目標保持一致： 了解業務需求有助於客製化遷移方案，以支援關鍵工作流程、使用者體驗和成長計畫。
-
確保技術相容性： 儘早確定技術需求可以避免與現有基礎設施、網路和終端機出現整合問題。
-
有助於資源規劃： 明確的需求有助於準確估算時間、成本和所需資源。
-
降低風險： 及早發現潛在問題可以採取積極主動的解決方案，從而減少停機時間和業務中斷。
業務需求
典型的業務需求包括：
-
待遷移的使用者數量和位置
-
所需功能和服務（例如：呼叫路由、語音信箱、電話會議、自動應答、呼叫佇列）
-
合規和安全政策
-
預算限制和成本預期
-
使用者培訓和支援需求
-
遷移時間表和業務連續性注意事項。
收集所需的功能和 服務是確保新系統滿足業務需求的關鍵步驟。在收集這些需求時，不僅要考慮目前配置的內容，還要嘗試從將要使用該系統的業務實體收集實際需求。否則，該計劃可能基於過時的假設。務必評估 中提供的其他或增強功能，這些功能在 中可能不存在，例如基於雲端的呼叫、進階呼叫佇列、 和 。這有助於充分利用雲端平台的優勢。
在評估目前配置時，必須認識到，由於系統生命週期中需求的不斷變化，並非所有現有設定都仍然是必要的。重點應該放在識別和保留那些符合當前和未來部署需求的配置。
多關注你需要什麼，而不是你擁有什麼。
在從遷移到 Webex Calling 的過程中，合規性和安全策略是至關重要的考慮因素 ，以確保新的基於雲端的通訊系統符合法律、監管和組織標準。
-
監理合規性： 組織必須驗證其是否符合行業特定法規，例如 GDPR、HIPAA 或 SOX，這些法規涉及資料隱私、保留和處理的要求，以及與資料駐留、收費繞行和媒體本地化相關的國家/地區特定規定。
-
資料安全： 確保語音和訊號資料在傳輸和儲存過程中均進行加密，以防止被攔截或未經授權的存取。
-
存取控制： 定義並實施使用者身分驗證、授權和基於角色的存取控制，以防止未經授權使用通訊資源。
-
審計和監控： 實施日誌記錄和監控功能，以追蹤存取和使用情況，用於合規性稽核和安全事件調查。
-
政策一致性： 使遷移與現有的企業安全策略保持一致，包括終端安全、網路分段和事件回應計畫。
-
供應商安全保障： 評估思科的安全認證和合規性證明，以確保其可信度。
在規劃階段解決這些合規和安全策略有助於降低風險、避免法律處罰，並在整個遷移過程中以及遷移後維護通訊的完整性和保密性。
使用者培訓和支援需求 是從到遷移過程中確保平穩過渡和使用者採納的重要組成部分。主要考慮因素包括：
-
培訓項目： 為不同的使用者群體（最終使用者、管理員、服務台人員）制定客製化的培訓課程，使他們熟悉各項功能、使用者介面和新的工作流程。
-
文件： 提供清晰易懂的使用者指南、常見問題解答和快速參考資料，包括 新增功能和不同之處 資源以及逐步 遷移前後 操作指南（影片或快速指南格式），以幫助使用者適應遷移後的更新體驗。
-
變更管理： 主動溝通變更，以管理使用者預期並減少阻力。
-
支撐結構： 建立專門的支援團隊或升級途徑，以便在遷移期間和遷移後及時解決用戶問題。
-
繼續教育： 隨著新功能或更新的發布，制定持續培訓更新計劃。
-
回饋機制： 建立使用者回報問題和提供回饋的管道，以改善培訓和支援流程。
在規劃階段解決這些培訓和支援需求有助於最大限度地減少干擾，增強使用者信心，並最大限度地發揮遷移到新系統的好處。
技術要求
為了成功從 [系統名稱] 遷移到 [系統名稱]，需要收集並記錄幾個關鍵的技術要求，包括以下方面的詳細資訊：
-
網路就緒性和頻寬容量
進行全面的網路評估至關重要，以確保您現有的基礎架構能夠支援新的 Webex Calling 環境。這些調整包括：
-
頻寬分析： 評估目前和預期的頻寬使用情況，以處理語音、視訊和資料流量而不會出現擁塞。
-
服務品質（QoS）： 實施 QoS 策略，優先處理語音流量，最大限度地減少延遲、抖動和丟包。
-
廣域網路和網際網路連線： 驗證廣域網路鏈路和網際網路連線是否符合基於雲端的呼叫的要求，包括冗餘和故障轉移功能。
-
防火牆和NAT配置： 確保防火牆和 NAT 設定允許所需的訊號和媒體流量。
-
-
與現有系統集成
與現有業務系統無縫整合對於使用者體驗和工作流程的連續性至關重要：
-
目錄服務： 評估與企業目錄的集成，以實現使用者自動配置和身份驗證。
-
客戶關係管理與業務應用： 確定與客戶關係管理系統和其他業務關鍵應用程式的整合點。
-
傳統PBX互通： 若過渡期間仍需保留任何傳統電話系統，則需制定共存或分階段遷移策略。
-
-
端點相容性和配置
應評估所有終端設備（包括桌上型電話、軟體電話和行動裝置）的相容性：
-
設備支援： 確認現有 IP 電話和設備是否受支持，或確定需要更換的設備。
-
配置流程： 建立自動化或簡化的配置方法，以有效率地完成終端設備的存取。
-
韌體和軟體更新： 制定必要的更新計劃，以確保互通性和安全性。
-
-
安全配置和加密標準
在雲端通訊中，安全性至關重要：
-
加密： 依照思科安全最佳實踐，對訊號和媒體流強制執行端對端加密。
-
身份驗證和存取控制： 實施安全身份驗證機制（例如 SSO、多因素身份驗證）和細粒度的使用者存取控制。
-
遵守： 確保解決方案符合相關的監管和行業合規標準（例如 GDPR、HIPAA）。
-
安全監控： 與 SIEM 工具集成，並設定潛在安全事件警報。
-
| 需求 | 關鍵考慮因素 |
|---|---|
| 網路就緒性和頻寬 | 頻寬、服務品質、 WAN/Internet, Firewall/NAT |
| 與現有系統的集成 | 目錄、CRM、PBX、 Email/Calendar |
| 端點相容性和配置 | 設備支援、配置、韌體更新 |
| 安全性配置和加密 | 加密、身份驗證、合規性、安全監控 |
| 使用者培訓和變更管理 | 培訓計畫、文件、變更溝通 |
| 號碼可攜性和撥號方案 | 數位 migration/porting, 撥號方案翻譯 |
| 第三方集成 | 呼叫器、呼叫中心、傳真機、類比設備 |
網路就緒性與要求
網路就緒對於成功遷移到任何基於雲端的通話解決方案（例如 ）至關重要。網路規劃不善會導致通話品質下降、斷線，以及用戶不滿。客戶在遷移到新系統之前需要進行網路評估。建議確認網路頻寬是否足以滿足預期的通話量，確保滿足服務品質 (QoS) 要求，並了解必須在邊緣防火牆中開啟的各種連接埠。
可靠的網路連線以及足夠的服務品質（頻寬、丟包率、RTT）是確保所有支援語音和視訊的終端、用戶端和應用程式獲得最佳端對端用戶體驗的基本要求。
客戶和合作夥伴除了可以透過 OTT 網路連接外，還可以使用其他連接方式來優化連接，例如 Webex Edge Connect。有關 Webex Edge Connect 設計詳情的更多信息，請參閱 Cisco 推薦的 Webex Edge Connect 架構，適用於 Webex Meetings、呼叫多租戶和專用實例。
客戶可以使用 CScan 進行網路評估，該評估提供有關客戶網路品質、可建立的通話數量、延遲等資訊。有關 CScan 工具的更多信息，請參閱 使用 CScan 測試 Webex Calling 網路品質。
為確保網路已做好遷移準備，請參考以下清單：
-
頻寬規劃
計算每個網站的並發呼叫數，以確保您有足夠的上行和下行頻寬，並為其他業務關鍵流量和未來成長預留餘裕。
Webex Calling 呼叫類型頻寬計算 表顯示了部署中可用的呼叫類型，以及每種呼叫類型所需的編解碼器和最大頻寬。如 Webex Calling 通話類型頻寬計算 表所示，可以使用以下通用公式計算每種通話類型所需的音訊通話頻寬：
預期並發呼叫次數 * 基於編解碼器的每次呼叫頻寬 = 所需網路吞吐量。
表格 2. Webex Calling 通話類型頻寬計算 呼叫類型 編解碼器 - 頻寬 頻寬計算 / 桌上型電話 -> OPUS - 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 / 桌上型電話 -> 桌上型電話 OPUS – 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 / 桌上型電話 -> 透過LGW的PSTN G.711 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 透過雲端 PSTN 進行 PSTN 通訊（例如 Cisco 通話套餐） G.711 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 企業透過LGW G.722 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 語音信箱 OPUS – 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 透過對每種通話類型所需的並發網路吞吐量進行求和，可以確定特定站點的總潛在頻寬需求。
所有呼叫線路始終錨定在接取 SBC 上。要確定任何給定位置所需的互聯網頻寬，不僅需要考慮位置間的呼叫，還需要考慮位置內的呼叫以及與該位置的本地網關之間的呼叫。例如，兩部 MPP 電話之間的站點內通話需要該站點互聯網接入提供高達 2 x 70 kbps 的全雙工頻寬。
Webex Calling 頻寬計算範例 表格顯示了一個完整的頻寬計算範例，假設所有裝置都在同一網站。
表格 3. Webex Calling 頻寬計算範例 呼叫類型 並發呼叫次數 總頻寬 Webex 應用 / 桌上型電話 → Webex 應用 15 2 * 15 * 70 kbps = 2100 kbps Webex 應用 / 桌上型電話 → 桌上型電話 15 2 * 15 * 70 kbps = 2100 kbps Webex 應用 / 桌面電話 → 透過LGW接入PSTN 50 2 * 50 * 80 千秒 = 8,000 千秒 Webex 應用 / 桌上型電話 → 透過 Cloud Connect 進行 Webex 通話的 PSTN 0 0 * 80 Kbps Webex 應用 / 桌上型電話 → 透過 LGW 的企業 15 2 * 15 * 80 kbps = 2400 kbps Webex 應用 / 桌上型電話 → Webex 通話語音信箱 5 5 * 70 千秒 = 350 千秒 總通話次數 / 頻寬 100通電話 14,950 kbps / 14.95 Mbps -
上表中所有頻寬值均指 IP 頻寬。鏈路頻寬取決於廣域網路封裝方式。
-
以上表格中的頻寬指的是音訊通話的頻寬。視訊通話頻寬方面，Webex 應用程式和 MPP 均適用。 8845/65 手機支援 H.264 視頻，最高解析度為 720p，每次通話最大頻寬為 1,500 kbps。然而，通話期間任何時刻消耗的頻寬量都會根據視訊通訊固有的可變位元率而波動。
-
-
服務品質 (QoS)
在本地環境中實施 QoS 策略，以優先處理即時流量，並確保在交換器、路由器和防火牆之間保持 QoS。
-
延遲、抖動和丟包目標
以下閾值建議用於在透過網路進行OTT通話時獲得最佳語音品質：
-
單向延遲小於100毫秒
-
抖動小於 10 毫秒
-
丟包率 - 0.5% 或更低。
-
-
防火牆和NAT
確保防火牆已配置為允許流量，如 Webex Calling 連接埠參考資訊所述。此外，允許存取同一指南中列出的網域和 IP 範圍，並避免使用 SIP ALG，因為它會幹擾 SIP 訊號。應避免透過代理伺服器進行媒體流量傳輸。
-
DNS 和 NTP
確保網域名稱解析正確，並使用可靠的 NTP 伺服器同步設備時鐘，以進行 TLS 憑證驗證和日誌記錄。
-
故障轉移計劃
考慮現有提供者資料連線（MPLS、SD-WAN 等），並規劃在部署中的每個位置直接連接到網際網路。在需要高可用性的場景下，應規劃冗餘的網路連結。由於您將使用基於雲端的服務，因此可靠的網路連線和足夠的頻寬是基本要求。如果您的組織場所的網路連線通常不夠可靠，延遲不夠低，上下行吞吐量也不夠，那麼您應該重新考慮進行這種轉換。
-
場地存活率
網站生存能力確保即使網路連線中斷，您的業務也能隨時可存取。站點生存能力利用本地網路中的網關，在網路連線中斷的情況下，為現場端點提供回退呼叫服務。如果業務需求要求在網路中斷時仍能持續呼叫，請考慮使用本地生存網關 (SGW) 來提高站點生存能力。有關站點生存能力檢查的更多信息，請參閱 Webex Calling 的站點生存能力。
設定雲端連接的統一通信
Cloud Connected UC (CCUC) 是一種基於雲端的管理和分析解決方案，旨在為本地部署（如 Unified CM）和雲端部署提供集中式的可見性、管理和洞察。它充當傳統本地環境和思科雲端服務之間的橋樑，為組織從本地遷移到雲端的整個過程提供支援。
在向統一通訊系統過渡的過程中，CCUC 透過促進從現有統一通訊部署中收集全面數據，在簡化遷移過程中發揮至關重要的作用。CCUC 可協助完成關鍵的過渡任務，例如遷移裝置、功能和使用者聯絡人，以及自動更新支援的 IP 電話的韌體。CCUC 透過提供集中式的視覺性和管理，協助確保更順暢、更有效率的遷移體驗。
Cisco 強烈建議在過渡專案的早期階段部署 CCUC，理想情況下是在準備階段之前或期間部署。這將使您能夠獲得所需的洞察力和能力，從而徹底評估、清點和規劃後續的遷移活動，並開啟您邁向未來混合能力的旅程。
評估當前環境
遷移計畫中的關鍵活動是評估目前的本地環境和部署情況。這有助於我們了解成功過渡到新階段可能需要哪些潛在改變。它還允許您將平台的關鍵要素與現有的本地部署進行比較。您可以利用這些資訊來幫助確定過渡期間所需的特定任務，以及為了滿足您的業務和技術要求及用例，您希望做出哪些更改。
作為這項工作的一部分，以下幾個方面需要重點審查。
授權
了解現有部署的目前許可結構是準備遷移到新部署的關鍵。對您現有的 Cisco 本機部署解決方案的下列事項進行授權評估。
-
平台
在與客戶團隊或合作夥伴共同確定靈活授權的最佳方案時，能夠清楚闡述您核心平台上目前已授權的內容至關重要。有關靈活許可的更多信息，請參閱 Cisco 協作靈活計劃。
-
使用者和設備
確定您現有使用者和裝置需要哪種授權類別。這將用於確定使用者和設備所需的許可證類型。提供多種許可證類型，包括使用者的專業版和標準版許可證，以及針對工作區的專業版和公共區域版授權。有關設備許可的更多信息，請參閱 設備許可中的數據表。
-
本機閘道
如果此次過渡需要 Cisco Unified Border Element (CUBE) 來實現 PSTN 接入，則還必須考慮 CUBE 許可。CUBE 許可方面的注意事項將在本文檔後面部分介紹。
Locations/Sites
在規劃此過渡時，應考慮現有部署中的站點數量和類型（大型中央站點、區域站點、分公司等）。充分了解現有部署站點將有助於制定策略計劃，以實現成功的過渡，尤其是在確定要遷移哪些站點以及遷移順序方面。詳細了解每個網站的撥接方案需求（號碼、撥接習慣、限制類別等）、網站網路連線和頻寬（網際網路、廣域網路、區域網路）以及 PSTN 接取（本地或集中式、IP 或 TDM）對於制定遷移決策至關重要。有關常見部署模型和關鍵考慮因素的更多信息，請參閱 Collaboration SRND中提供的協作部署模型資訊。
當遷移到新平台時，另一個重要的部署考慮因素是位置可用性。根據部署位置的不同，可用的功能、訂閱和設備也會有所不同。有關地理位置可用性的更多信息，請參閱 Webex 在哪裡可用？。
最後，了解過渡到新系統對其他協作服務的影響也很重要。根據本文檔的目標，一般假設是，如果要維護呼叫工作負載之外的現有協作服務，則需要過渡到上面提到的第 1 階段混合部署。可能需要混合部署的協作服務範例包括尚未遷移到 Webex 聯繫中心的本地聯絡中心，以及與尋呼系統和計費系統等系統的緊密整合。有關其他協作工作負載和服務的過渡的更多信息，請參閱 協作過渡。
現有庫存 devices/clients
在開始過渡之前，清點您現有的硬體和軟體終端非常重要。擁有完整的設備清單 types/models, 硬體版本、軟體用戶端作業系統類型和數量將確保您能夠充分規劃設備的過渡，並減輕那些無法遷移到雲端通話的裝置的影響。應利用庫存清單確定過渡期間需要過渡的設備以及過渡前需要更換的設備。
桌上型電話
僅支援 6800、7800、8800 和 9800 系列音訊和視訊桌面電話。這是受支援的 Cisco IP 電話的子集。6800、7800 和 8800 系列手機的某些型號和版本不能與 . 有關支援哪些型號和硬體版本的更多信息，請參閱 Webex Calling 支援的設備。
Cisco 6800 系列 IP 電話無法從企業韌體升級至多平台 (MPP) 韌體，而多平台 (MPP) 韌體是必要的。因此，任何註冊運行企業韌體的 6800 電話都必須更換為 6800 MPP 型號或其他受支援的電話型號。
Cisco 7800 和 8800 系列 IP 電話必須先升級到多平台電話 (MPP) 固件，然後才能進行過渡並註冊。若要確定哪些 7800 和 8800 型號和硬體版本支援 MPP 韌體，請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
8845、8865 和 8865NR 已停止銷售，不建議遷移。
不建議將較舊版本的 8800 系列電話（8811、8841、8851、8851NR、8861）與 Webex Calling 搭配使用。硬體版本為 VID 14 或更早的手機可以註冊，但由於硬體原因可能會出現一些效能問題。
9800 系列桌上型電話運行 PhoneOS，支援註冊和登入。因此，這些手機無需韌體升級即可進行過渡。
所有其他 IP 電話都需要更換為 Webex Calling 支援的 6800、7800、8800 或 9800 系列電話。有關支援的 IP 和桌面電話的更多信息，請參閱 文章 Webex Calling 支援的設備。
視訊終端
個人和會議室視訊終端，包括 Cisco Board 系列、Room 系列和 Desk 系列，可原生註冊到 SIP。任何需要發出音訊的端點 and/or PSTN 呼叫需要呼叫許可證：
-
會議室、小型討論空間等處的共享設備需要專業工作區或工作區授權。
-
終端使用者的個人設備需要專業版或標準版授權。
確定有多少個視訊終端已註冊並用於進行音訊通話。某些視訊終端可能僅用於加入會議或進行 SIP 視訊通話。無論哪種情況，終端設備仍需在伺服器停用之前進行遷移，但這將有助於確定其中有多少設備需要許可證才能繼續撥打電話。
-
當視訊設備從本機註冊遷移到雲端註冊時，這些端點的 URI 將會發生變化，因為它們現在是在雲端註冊的。
-
8845、8865 和 8875 型號的電話是支援的個人視訊電話。
軟體客戶端
這是唯一支援的軟體用戶端，與同時支援 Webex App 和 Jabber 的 Unified CM 不同，並且是最終用戶的新預設軟體用戶端。
根據 Jabber 所實施的部署模式（僅限即時通訊、僅限電話、 and/or （完整的 UC 模式），您可能還需要考慮訊息傳遞的過渡。 and/or 將 Jabber 中的會議工作負載轉移到 . 如果僅用作通話用戶端，則可部署為 僅電話模式 ；如果還需處理其他工作負載，例如 Webex Messaging，則可部署為 完整的 Webex 套件 。 and/or Webex Meetings 正在過渡到具有通話功能的應用程式。
它透過提供人工智慧功能來增強最終用戶體驗，例如 audio/video 情報、通話轉錄等。如需相關資訊，請參閱 。https://www.webex.com/all-new-webex
在將使用者遷移到新系統之前，您需要將他們的 Jabber 用戶端遷移到新系統。完成此次過渡有兩種選擇。
-
在將它們過渡到
-
當你將它們過渡到.
為了方便使用者首次過渡到新系統，建議使用選項 1，並先呼叫該選項將使用者遷移到新系統。這樣一來，用戶就有時間熟悉新的應用程序，同時他們仍然可以繼續使用現有的本地呼叫平台。準備好將用戶遷移到雲端後，您需要設定他們的裝置以在雲端呼叫平台上註冊。
有關這兩個選項的更多信息，請參閱 遷移之旅 - 一步還是兩步？。
有關 Webex Calling 支援的設備的完整列表，請參閱 Webex Calling 支援的設備。
驗證設備資格
如前所述，它支援部分思科 IP 電話，並且 7800 和 8800 系列電話需要不同的韌體類型。Unified CM 電話運行企業韌體，而 Phones 則運行多平台電話 (MPP) 韌體。建議在準備階段確認哪些已註冊的手機符合升級到 MPP 韌體的條件。這樣您就有時間將不符合條件的手機更換為支援的手機型號之一，或者確定替代方案，例如將用戶遷移到僅 Webex 應用程式。
為了協助確定電話的資格，Control Hub 內建了一個名為 「將您的電話遷移到 Webex Calling」的工具。使用此工具檢查裝置資格時，選擇移轉選項 僅產生裝置授權。
此選項可讓您上傳包含電話號碼的 CSV 文件，以便檢查每部電話號碼的資格。選擇此遷移選項後，由於您仍處於準備階段，尚未準備好執行此操作，因此不會將手機新增至遷移清單。如需相關資訊，請參閱將電話移轉至Webex Calling 。
部分手機可能顯示 未知 資格。這通常是因為無法在後端系統中驗證有關手機的某些資訊。對於任何狀態為 未知 的手機，您有兩種方法可以驗證它們是否符合升級到 MPP 韌體的條件。
-
手動檢查每部手機，並核實型號和硬體版本（PID VID）。
7800/8800 電話標籤，包含型號和硬體版本信息 -
使用 Cisco IP 電話就緒工具
從 https://github.com/joemar2/mpp_readiness_check下載該工具。
此工具並非思科官方工具，也不受TAC支援。它提供盡力而為的支持，但可以免費使用。
該工具必須在本機電腦上運行，並且能夠存取伺服器和 IP 電話。它提供了一個選項，可以在 IP 電話上啟用網路訪問，建議啟用此功能以獲得最佳效果，並且這是必需的。因此，應在非工作時間使用，以免對最終使用者造成乾擾。該工具的輸出結果會產生一份報告，列出哪些 7800 和 8800 系列電話符合升級到 MPP 韌體的條件。因為它直接存取手機，所以可以驗證從控制中心工具報告的 未知 裝置。
Cisco IP電話就緒工具報告
使用者
確保遷移成功的最重要準備步驟之一是正確配置使用者。即使分階段遷移，也需要為所有使用者做好妥善規劃。使用者必須具備以下任一條件：
-
使用呼叫進行部署
-
部署與
-
為使用者配置服務
-
使用戶可在目錄中被搜尋（點選撥號、使用者聯絡資訊、電話簿搜尋）。
建議您在專案開始之前或開始時配置所有使用者。這包括那些仍然使用 Unified CM 的用戶，因為他們的呼叫平台與其呼叫設備（IP 電話、Jabber 等）無關。隨著用戶遷移到 (and/or 您將更新他們的許可證，以啟用他們需要的服務。透過在開始過渡之前配置所有企業通話用戶，可以允許已過渡到其他平台的用戶在目錄中搜尋仍在使用 Jabber 的企業通話用戶。 and/or 在 。這樣可以確保過渡用戶能夠找到任何其他用戶的聯絡訊息，並使用目錄查找功能撥打電話。
圖 目錄搜尋 顯示了一個使用者搜尋另一個使用者的範例。搜尋結果顯示用戶的聯絡訊息，可能包括仍在使用 Jabber 的用戶，也可能包括已遷移到其他平台的用戶。 and/or 。
接下來確定哪些現有的本地呼叫用戶將被遷移到新系統。如果需要遷移全部或大部分用戶，建議分批遷移用戶，以確保專案團隊、IT 人員和支援人員能夠處理遷移以及可能出現的任何問題。您還應該安排一些時間提供初步資訊和培訓課程，以幫助使用者做好過渡準備。使用者轉換分組可以根據各種標準進行，包括使用者被分配到的位置或網站、使用者的部門，甚至是使用者類型（知識工作者、管理人員、行動工作者等）。
例如，如果部署中的使用者分佈在三個主要站點，即紐約 (NYC)、舊金山 (SFC) 和研究三角園區 (RTP)，則使用者過渡計畫可能類似於 按站點劃分的使用者過渡計畫 表中概述的計畫。
| 使用者網站 / 地點 | 過渡前資訊與培訓課程 | 過渡期 | 過渡後支持 |
|---|---|---|---|
| 紐約市（1,525 位用戶） | 4月1日當週 | 4月15日至4月27日 | 4月29日當週 |
| 舊金山國際機場（1,600 位使用者） | 5月6日當週 | 5月20日至5月31日 | 6月3日當週 |
| RTP（1,275 位使用者） | 6月3日當週 | 6月17日至6月28日 | 7月1日當週 |
另一個重要因素是讓彼此有依賴關係的使用者一起過渡。這可能包括但不限於以下內容：
-
BLF監測
-
同樣的狩獵 pilot/group
-
分享線
-
屬於同一個呼叫接聽組
-
使用相同的呼叫駐留號碼
-
內部通訊
-
管理員/執行
您可以查看配置（GUI 或匯出）或使用 遷移洞察 工具來協助識別具有這些依賴關係的使用者群組。
PSTN 連線
可以透過三種方式接取公共交換電話網路（PSTN）：Cisco 通話套餐、雲端連線（以前稱為雲端連線 PSTN）和本地 PSTN（本地閘道）。但是，依照規定定義的單一位置只能指派給一個 PSTN 選項。
具有本地網關 (LGW) 的本地 PSTN 是過渡策略的重要組成部分。它提供本地部署之間的連接 and/or PSTN 和此平台支援 Cisco 和經認證的第三方會話邊界控制器 (SBC)，這些控制器可用作本地網關。有關最新支援的 SBC 列表，請參閱 支援的 SBC 列表。
支援來自單一基於註冊的本地網關的最多 250 個並發調用，以及來自單一基於憑證的本地網關的超過 250 個並發調用。基於憑證的本機閘道最多可支援 6500 個同時呼叫，但這取決於本機閘道的連線類型（OTT 與互連對等連線）以及本機閘道部署的 SBC 模型。這些限製本質上是本地網關 PSTN 呼叫和站點間呼叫的預設計數限制。有關更多信息，請參閱 本地網關入門。
任何超過此限制的呼叫都將被拒絕，並傳回 403 Forbidden。可以在任何時刻在本機閘道上執行 show call active voice 指令，以決定活動呼叫的總數。
本機閘道與接取 SBC 之間的網路狀況不佳會限制訊號連線的效能，從而導致同時呼叫限制進一步降低。本地網關與資料中心之間的單向延遲不得超過 100 毫秒，抖動應小於 10 毫秒，丟包率應小於 0.5%。 %.
特徵 & 功能使用
在評估當前環境時，識別和審查已配置的功能非常重要。此外，了解這些功能的使用方法也很重要，這樣您才能（重新）定義部署的業務和技術要求。
若要確定配置了哪些功能，請分析配置。這些都是靜態數據，是在系統配置某個功能或設定時設定的。可以使用以下選項完成此分析：
-
在管理 GUI 中查看配置
-
配置匯出 -- 批次匯出或 AXL
-
遷移洞察工具（推薦）
-
思科第三方合作夥伴工具（建議）。
為了有效分析功能利用率，必須檢查動態系統數據，例如使用率、註冊量和呼叫活動。各種分析工具和儀錶板提供了對這些指標的深入了解，從而能夠全面了解系統性能和容量，為遷移和優化工作中的明智決策提供支援。可以使用以下選項完成此類分析：
-
審查原始CDR記錄
-
統一 CM RTMT 資料審查
-
使用 CDR 資料的遷移洞察工具
-
雲端連線統一通訊分析的回顧
-
通話量
-
已註冊的端點
-
（CAC）地點
-
主幹線利用率。
-
-
思科第三方合作夥伴工具。
Cisco 建議先使用 Webex Control Hub 遷移洞察工具進行此分析。您需要將匯出的 .TAR 檔案和統一 CM CDR 檔案（可選，但功能利用率分析需要）匯入到該工具中。該工具將產生以下基於 CSV 的報告，可用於開始分析：
| 報告名稱 報告說明 |
|---|
| ImportedDataBulk.csv
來自統一組態管理 (Unified CM) 資料的所有使用者和設備 |
| DeviceEligibility.csv
識別符合遷移到 Webex Calling 條件的設備（IP 電話、會議室作業系統設備、ATA 和第三方設備） |
| DevicePoolNumbers.txt 特定設備池中的所有號碼列表 |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv 根據共用線路、呼叫群組、呼叫佇列、呼叫駐留和呼叫代接群組配置，提供有關應一起遷移的裝置和使用者的詳細資訊。 |
| HuntGroupMigrationInsight.csv 有關已指派呼叫線路、線路組和相關代理的詳細信息 |
| SharedlineGroupMigrationReport.csv 用戶間共享電話號碼（目錄號碼）的方式概述 |
| 報告名稱 報告說明 |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv 根據功能使用情況提供的設備遷移資格信息 |
| FeatureUsageWithLastUsageDateReport.csv 使用次數統計，包括呼叫調度員和呼叫佇列的呼叫次數以及上次使用日期。 |
| UserWorkspaceLastUsage.csv 軟體客戶端和硬電話的使用者和工作區的最後使用日期 |
| DIDUsageReport.csv DID 的使用情況，包括已指派和未指派的 DID |
有關遷移洞察報告的更多詳細信息，請參閱 遷移洞察。
如果您在查看遷移洞察報告中的信息後仍需要有關功能和使用方法的更多信息，思科建議您考慮使用思科的第三方合作夥伴遷移工具。 and/or 查看圖形使用者介面或配置匯出資料中的配置。
思科整合：Unity Connection UCCX UCCE
語音信箱是該服務不可或缺的一部分，並且已原生內建於解決方案中。它無法與 Unity Connection 或 Unity Connection Express 等本地部署的語音信箱解決方案整合。此外，目前還沒有原生方法可以將現有的 Unity Connection 語音郵件訊息或問候語遷移到原生語音郵件服務中。思科的一些第三方合作夥伴的遷移工具確實具備遷移部分此類資料的功能。有關語音信箱的更多信息，請參閱 配置和管理 Webex Calling 用戶的語音信箱設定。
也支援共享語音信箱和傳真郵箱。有關更多信息，請參閱 管理 Webex Calling 的共享語音郵件和入站傳真箱。
它內建了自動語音應答功能，該功能包含在核心平台中。此功能允許遷移 Unity Connection 的呼叫處理程序和自動助理功能。Control Hub 工具 從 Unified CM 遷移功能 支援將 Unity Connection 配置遷移到 Auto-Atdendants。有關使用此工具的更多信息，請參閱 將設備和功能從 Unified CM 遷移到 Webex Calling。
通話錄音
包含兩種通話錄音選項，無需額外費用。
-
Webex通話錄音
-
Dubber Go 錄製（合作夥伴優惠）—與 Dubber 的集成，所有錄製的媒體都安全地保存在雲端。
包含錄音選項 表格重點介紹了兩種無需額外費用即可使用的通話錄音選項的一些關鍵功能。
| Webex | 杜伯·戈 |
|---|---|
| 所有使用者均可使用 | 所有使用者均可使用 |
| 無限次錄音 | 無限次錄音 |
| 1 年保留期* | 30天保留期 |
| 每個組織 100 GB 儲存空間 | - |
| 合規官可以存取和管理通話錄音。 | - |
| 用於管理錄製內容的 API | - |
管理員可以設定和管理使用者對其通話錄音的存取權限。
|
只有使用者才能存取和管理自己的錄音。
|
如果您的組織需要額外的錄音功能，例如合規性通話錄音、更長的保質期、更大的儲存空間、人工智慧分析等， and/or 思科和第三方錄製提供者都提供管理員存取權限、付費服務或附加元件。有關錄音提供者、配置和附加合作夥伴服務的更多信息，請參閱 管理 Webex Calling 的通話錄音。
第三方集成
支援多種第三方集成，包括但不限於本地網關的SBC、IP電話、對講電話 等。 Speaker/Pagers, ATA 等。除了這些第三方設備外，Webex Calling 還支援不同的第三方解決方案 ，用於客戶支援、分析、錄音、計費等。有關第三方解決 方案的更多信息，請參閱 Webex App Hub。
計劃
高層專案計劃
在製定從 到 的高級專案計劃時，必須建立與業務目標和技術要求一致的清晰階段和里程碑。該計劃應從全面的評估階段開始，包括收集詳細的技術和業務需求，以及確定利害關係人和定義成功標準。關鍵考慮因素包括資源分配、時間安排估算、風險管理和溝通策略，以確保所有各方在整個遷移過程中都能了解情況並參與其中。此外，該計劃應包含驗證檢查點，例如試點測試和分階段推廣，以最大限度地減少干擾，並允許根據回饋進行調整。
專案計畫中應包含的要素範例包括：
-
確定遷移範圍（例如，哪些使用者、裝置和功能將進行遷移）
-
為最終用戶和支援團隊安排培訓課程
-
協調網路就緒評估，以及
-
制定切換活動計畫並配備備用方案。將合規性和安全性審查以及遷移後支援和優化階段納入其中也十分重要。
透過根據這些考慮因素建立專案計劃，組織可以更好地管理複雜性，降低風險，並實現更平穩的過渡。
移民之旅－一步還是兩步？
要求用戶使用其呼叫軟客戶端。因此，如果還有用戶在使用，您可以選擇何時將他們遷移到。您可以執行單步驟用戶遷移或雙步驟用戶遷移。
選項 1：單步用戶遷移
在單步驟遷移中，使用者從 Unified CM 遷移到 的同時，也從 遷移到 。此選項通常適用於使用者數量較少的客戶，可以同時管理使用者的軟客戶端和呼叫服務的遷移。圖 用戶呼叫服務，軟客戶端 & 手機遷移到同一時間 下面突出顯示了這種類型的遷移。使用此選項，使用者將同時完成以下所有操作：
-
呼叫服務已從
-
電話號碼和分機號碼已從…遷移至…
-
軟體客戶端已從 Jabber 過渡到 - 將註冊
-
電話註冊從 移至 。
這仍然可以是一個分階段的遷移，用戶群組在不同的時間進行遷移，但當每個用戶被遷移時，所有這些操作都是同時進行的。
選項 2：雙步用戶遷移
另一種方法是兩步遷移。在步驟 1 中，使用者從 [此處應填寫具體位置] 過渡到 [此處應填寫具體位置]，但仍保留 [此處應填寫具體位置] 以撥打服務電話。然後在步驟 2 中，使用者從 Unified CM 遷移到 。對於希望管理最終用戶變更並將用戶軟體客戶端變更與呼叫服務變更分開的大型客戶，建議採用此選項。下圖 遷移軟客戶端；然後遷移呼叫服務，軟客戶端 & 以下透過電話到 Webex 通話 突出顯示了這種遷移方式。
步驟 1
-
軟客戶端已從過渡到 - 將註冊到。
步驟 2
-
呼叫服務已從 遷移到 。
-
電話號碼和分機號碼已從 移轉到 。
-
註冊地點從 轉移到 。
-
電話註冊從 移至 。
這仍然可以是一個分階段的遷移，在兩個步驟中，使用者群組會在不同的時間進行遷移。
您選擇的選項取決於您希望如何管理使用者向新系統的過渡。建議分步驟進行（方案 2）。這樣可以最大限度地減少最終用戶一次性進行的更改，並將工作量分配到專案的不同部分。但是，如果您希望使用者只受到一次影響，那麼使用選項 1 也是可行的。
查看建議的流程（選項 1）， Jabber 到 Webex App 進階轉換圖 下圖顯示了步驟 1 的進階轉換。
在此步驟中，用戶將從 Jabber 過渡到其所有通話服務。然而，呼叫平台仍然是 Unified CM，並且將其呼叫服務註冊到該平台。從 Jabber 到 Webex App 的高階過渡圖 可以看出，本地基礎架構不會改變，其運作方式與 Jabber 相同。唯一的改變是需要連接到外部網路。
有關此過渡的更多信息，請參閱 Jabber 到 Webex 過渡圖和部署指南 ，位於 協作過渡 頁面的客戶端部分。
Unified CM to Webex Calling high-level transition map figure is a high-level transition from to . 這是推薦行程的第二步。
如果您決定採用單步法，這同樣適用。
在此步驟中，使用者將被分組。此時，用戶開始使用呼叫服務、呼叫註冊和 IP 電話註冊。
由於用戶是成組遷移的，因此在過渡期間，企業用戶將被分散到兩個通話平台之間。 Unified CM 到 Webex Calling 進階轉換圖 中的第一階段描述了此狀態。在此階段，需要規劃如何管理兩個平台上的使用者之間的通話以及如何路由 PSTN 通話。每次有一組使用者遷移到新系統時，都需要在新系統和本地網關上更新撥號方案和呼叫路由。
一旦所有使用者、軟體客戶端和設備都過渡到（第二階段），那麼所有本地統一通訊基礎設施都可以被移除和停用。
設計
區域選擇
可在全球範圍內使用，並透過位於多個地區的冗餘資料中心進行交付：美國（達拉斯、芝加哥）、加拿大（溫哥華、多倫多）、歐洲（法蘭克福、阿姆斯特丹）、英國（倫敦、曼徹斯特）、澳洲（墨爾本、雪梨）、日本（東京、大阪）、沙烏地阿拉伯（利雅德、吉達）和印度（孟買、清奈）。媒體接入點提供媒體服務，以優化媒體往返時間。例如，新加坡資料中心用於優化亞洲國家客戶的媒體往返時間，因為往返澳洲或日本地區的媒體往返時間可能不夠理想。資料中心透過多千兆位元、完全冗餘的主幹網路互連。圖 全球分散式資料中心 顯示了所有資料中心的概覽。有關可用資料中心的最新列表，請參閱 Webex Calling 資料中心位置。
每個客戶都分配到其中一個實例。該客戶的所有設定資訊都儲存在該實例中，並且為該客戶配置的所有端點和本機網關的 SIP 訊號都與該客戶所在的實例相關聯。由於很難改變最初的區域選擇，因此在進行區域選擇決策的過程中，必須考慮所有相關因素。為了避免訊號往返延遲過長，在過渡過程中儘早決定應該使用哪個實例非常重要。Cisco 建議選擇能夠提供部署中最多使用者最簡訊令往返時間的執行個體。
有關國家/地區的可用性，請參閱 Webex 在哪裡可用？。
位置
為了準備提供遷移目標位置所需的信息，需要收集所有遷移目標位置的相關資訊。每個地點所需的資訊匯總在 每個地點需要捕獲的資訊。
| 資訊 | 評論 |
|---|---|
| 擴展範圍 | 每個位置都可以有以不同數字開頭的分機號碼。必須留出一位數字作為站點間撥號轉向數字（例如 8），一位數字作為 PSTN 轉向數字（例如 9）。任何擴展號碼都不能以這兩個數字中的任何一個開頭。 所有位置的擴展範圍長度必須相等。 |
| DID範圍 | - |
| PSTN轉向數字 | - |
| 網站程式碼 | 所有地點的所有站點代碼都必須是唯一的，且長度必須相同。 |
| 主要號碼 | 建立位置時需要配置兩個 DID。一個作為主要號碼（例如分配給自動應答服務），一個用於語音信箱入口網站。 為語音信箱號碼提供一個DID號碼。 |
| 語音信箱號碼 | |
| 授權數目 | 所需許可證類型包括：標準版、專業版、工作區版、路由清單版、外呼計畫版。 |
| 繁忙時段的並發呼叫 | 設備之間以及設備與本地網關之間並發呼叫的總和（PSTN 和呼叫到設備）。需要確定所需的網路存取頻寬。 |
| Country | - |
| 時區 | - |
| 語言 | - |
| 聯絡方式（姓名、電話、信箱） | - |
| 地址（街道地址、城市、州/省、郵遞區號） | - |
| 緊急服務終端的實體調度位置 | 用於緊急呼叫的設備可調度位置通常包括以下位置：建築物地址，建築物地址 + 樓層號，樓宇地址 + 套房號或樓宇地址 + 樓層號 + office/cubical 數字。 |
| 每個設備唯一的實體網路位置，用於緊急服務 | 緊急呼叫的實體網路位置通常包括以下部分：轉變 / 用於有線設備的交換器端口，用於無線連接設備的無線接入點（AP）基本服務集標識符（BSSID）。 and/or 用於終端設備的本機 IP 子網路。 |
PSTN
在設計部署方案時，客戶有三種主要的PSTN連線選項：Cisco Calling Plans（由 Cisco 管理的雲端交付 PSTN 服務）、雲端連線 PSTN 供應商 (CCPP，供應商透過雲端提供 PSTN 服務) 和本地 PSTN (本地網關將企業網路連接到 PSTN)。透過引入用於混合部署的 PSTN 中繼（有關更多信息，請參閱 PSTN 中繼中的用於混合 Webex Calling 部署的 PSTN 中繼），組織在遷移方法上獲得了更大的靈活性。此功能使客戶能夠在過渡之旅開始時將 PSTN 遷移到 CCPP，並開始為使用者過渡到雲端 PSTN，同時利用 CCPP 在分階段遷移期間為留在 Cisco 的使用者維持 PSTN 服務。
這種混合方法允許組織先將選定的使用者群組遷移到雲端，而無需立即徹底改造其整個電話環境。然而，這也帶來了額外的複雜性和風險，尤其是在調整現有呼叫路由邏輯以支援新架構方面。與傳統應用程式（例如傳真伺服器、呼叫中心或尋呼系統）的互通性也需要仔細考慮。關鍵技術挑戰可能包括確保在混合環境中實現無縫的端到端編解碼器協商和 DTMF（雙音多頻）信令，以及驗證與專用電話功能的兼容性。妥善的規劃和測試對於最大限度地減少中斷和在整個遷移過程中保持可靠的語音服務至關重要。此外，商業因素也很重要，因為混合中繼需要根據本地環境和雲端連接 PSTN 供應商 (CCPP) 之間的並發呼叫數量來獲得使用授權。
或者，各組織可以選擇在整個過渡階段保留其內部 PSTN 連線。在這種情況下，遷移到 CCPP 可以透過兩種方式執行：遷移完成後，可以對所有使用者和地點進行一次統一協調的切換，也可以逐步進行，PSTN 遷移根據使用者遷移到的地點逐一進行。這種方法有助於簡化共存並保持傳統整合的連續性，但同時也引入了一些操作上的複雜性。其中包括與號碼攜號轉網相關的挑戰，例如需要精確協調號碼攜號轉網訂單、可能出現的延遲以及運營商施加的限制，例如限制同時進行的攜號轉網請求數量或限制攜號轉網大號碼塊的子集。各組織必須仔細規劃其 PSTN 過渡策略，並將這些後勤因素考慮在內，以避免服務中斷並確保平穩的遷移體驗。
圖 一開始遷移到 CCCP 與保留本地 PSTN 顯示了上面解釋的兩個 PSTN 遷移選項。左圖顯示的場景是所有本地用戶和應用程式都透過本地中繼和連接本地與雲端的本地網關來使用雲端連接的 PSTN 服務，而右圖顯示的場景是現有的本地 PSTN 保持不變，Webex Calling 用戶透過本地與雲端之間的本地網關連接來使用本地 PSTN。過渡期間，各地點可以切換到使用雲端連線的 PSTN。
在這兩種情況下，本機系統和使用者之間的呼叫都使用本地網關連接。本地與外部之間的連接需要根據預期的並發呼叫數量和所需的冗餘度進行相應的設計和規模調整。
撥號計劃
為了在遷移期間實現無縫互通性，必須在兩個平台之間開發和實施全面的撥號方案架構。這種雙平台撥號方案設計確保了呼叫路由、號碼轉換和功能透明度的一致性，使兩個系統上的使用者都能在整個共存階段進行通信，而不會出現服務降級或使用者體驗中斷。
本地撥號方案
在過渡期間，為了允許在 Unified CM 和企業撥號計劃上註冊的設備共存，需要進行更改，以便至少滿足以下要求：
-
+E.164 撥號從到
-
分機撥號（站點內撥號，若分機號碼範圍唯一，也可站點間撥號）
-
從到站點間的簡短撥號
-
強制從到網內撥號
-
從未接來電目錄回撥至目的地
-
如果在過渡期間使用本地 PSTN，則 PSTN 通話將從本地 PSTN 呼叫到本地 PSTN。
-
如果在混合部署的過渡期間，使用 PSTN 中繼透過 Cloud Connect 為本地用戶提供 PSTN 訪問，則 PSTN 呼叫將從本地呼叫發送到本地呼叫。
-
被迫從網路到
-
分機撥號（站點間）。
如果在過渡之前不支援上述任何撥號習慣，例如不存在縮短的站點間撥號習慣，那麼在過渡期間不一定需要引入這些習慣。
圖 最佳實務撥號方案 顯示了 Cisco Collaboration 12.x 企業本地部署首選架構 (CVD) 中所述的最佳實務撥號方案方法。此方法的主要特點包括：
-
單一分區 +E.164 電話號碼簿
-
基於核心路由 +E.164 路線模式
-
將所有撥號習慣規範化 +E.164 使用翻譯模式
-
使用翻譯模式呼叫搜尋空間繼承（選項 使用發起者的呼叫搜尋空間 設定在翻譯模式上）。
例如，PSTN撥號 (9+1+10D) 來自 SJC 中已配置線路呼叫搜尋空間 SJCInternational 的裝置將首先與 相符。 9.1[2-9]XX[2-9]XXXXXX 將被叫號碼規範化的轉換模式 +E.164. 然後，二次查找再次使用相同的呼叫搜尋空間 SJCInternational （呼叫搜尋空間繼承），並且 +E.164-digit 字串要么會被匹配，要么會被其他字串匹配。 +E.164 在 DN 分區中，或透過 USPSTNNational 或 SJCPSTNLocal 分區中的 PSTN 路由模式之一。站點內和站點間撥號習慣的簡化是透過 ESN 和 SJCtoE164 分區中的翻譯實現的。雖然 ESN 分區是全域分區（所有位置的手機均可存取），但 SJCTOE164 分區僅對位於 SJC 位置的用戶可存取。這是假設擴展範圍重疊的情況。
啟用從到的呼叫的第一步是確保 +E.164 目的地將根據目的地進行相應路由。這可以透過向撥號計劃添加分區來實現，添加 +E.164 為到該分區的所有目的地建立路由模式，最後將該分區新增至所有呼叫搜尋空間，表示需要能夠到達的服務類別。需要建立一個專用分區，以便為來自以下位置的呼叫建立差異化的服務類別：為避免呼叫循環，本機閘道中繼上的入站呼叫搜尋空間不應存取該分割區。
如圖所示 +E.164 路由到 Webex Callex，以啟用從某個位置到某個位置的路由 +E.164 DID範圍 +1 221 555 2XXX 和站點代碼 121，與此相符的緊急路線模式 +E.164 需要將範圍加入 分區。
如果不需要選擇特定站點的本機網關，則可以不採用以本機路由群組為目標的路由列表，而是設定以本機網關為唯一成員的路由群組，然後路由模式指向一個僅包含該路由群組條目的路由列表。
為了實現站點間的短撥號，需要將所需的路由模式 8121.2XXX 新增至分區。為使站點能夠過渡到撥號規範化模式 8121.2XXX ，此模式將 ESN 撥號規範化為 +E.164 可能已存在於 ESN 分區中。在這種情況下， 8121.2XXX 似乎是多餘的，但是一旦相應位置的所有 DN 都遷移到 8121.2XXX 撥號規範化轉換模式，就可以刪除 8121.2XXX 路由模式，即使對於該範圍內的分機用戶，也可以啟用 ESN 撥號。
透過這些撥號方案的更改，不僅可以撥打站點間短撥號碼，還可以撥打其他撥號號碼撥打到該位置。 +E.164. 此外，國際和國內PSTN撥號是可行的，因為這些撥號習慣首先被規範化。 +E.164 透過現有的撥號規範化轉換模式，然後透過配對進行路由。 +E.164 分區中的路由模式。
這 +E.164 在所有 DID 仍託管在 上的情況下，可以設定位置 DID 範圍的路由模式比對。最佳匹配模式匹配演算法確保當撥打託管在 [此處應填寫系統名稱] 上的號碼時， +E.164 目錄號碼的匹配度比通配符更高。 +E.164 路由模式指向，以便將呼叫擴展到線路，而不是發送到。
撥號計劃
每個用戶都分配有一個擴展名。 and/or 一個 +E.164 電話號碼。擴展長度是一個固定的全域設定：部署中的所有擴充長度都相同。分機撥號功能既可以在同一地點內使用，也可以在不同地點之間使用。簡單的站點間分機撥號（後一種情況）僅在所撥打的分機是唯一的情況下才有效。
如果需要在不同地點之間進行縮短的站點間撥號，但不同地點分配的分機號碼有重疊，則需要建立企業特定的號碼方案，在分機號碼前加上接取碼和站台代碼。有關更多信息，請參閱 Cisco Collaboration 15 本地部署的首選架構，設計概述 可在 Cisco Collaboration Preferred Architectures處獲取。
分機長度、跨區分機撥號行為、跨區撥號前綴長度以及跨區撥號路由前綴中的轉向數字均在呼叫服務設定中進行設定。 :
-
位置路由前綴長度: 前綴長度（包括轉向數字）。只有在需要建立企業編號方案作為備用的縮短的企業間撥號習慣時才需要。
-
路由前綴中的轉向數字: 用於簡化企業間撥號習慣的導向數字。應避免與任何位置的首位數字和位置外撥號碼重疊。只有在需要建立企業編號方案作為備用的縮短的企業間撥號習慣時才需要。
-
內部延伸長度: 標準長度的接髮。可以是2到10之間的任何值。
當需要從本地呼叫控制中心撥打分機號碼或使用企業有效號碼（轉向代碼、站點代碼、分機號）撥打電話，並且本地呼叫控制中心將分機號碼作為呼叫者 ID 發送時，請確保在 “呼叫路由 ”部分中設置 “最大未知分機長度 ”參數，以確保從本地呼叫控制中心到本地呼叫控制中心的上游呼叫能夠被正確分類為本地呼叫。 -
允許不同地點之間撥打分機號碼: 切換到 enable/disable 在不同地點之間進行分機撥號。只有當組織內的所有分機號碼都是唯一的時，才應啟用此選項。如果停用此選項，則需要在各個位置之間撥打企業重要號碼（路由代碼、站點代碼、分機號碼）或電話號碼。
前三個參數主要用於建立電話撥號方案，以最大限度地減少摘機撥號時的數位間逾時。仍然可以偏離這些全域設定（例如 - 可以配置不同長度的分機），但控制中心會彈出警告訊息，並且從電話撥號可能需要進行整體撥號，以避免與預先載入的撥號計劃發生衝突。
表 企業編號範例 顯示了三個位置的範例，其中兩個位置（紐約市和 RTP）的擴展範圍相同。建立企業編號方案，採用站點間引導數字 8，後面接著三位數站點代碼和四位數分機號，從而形成不重疊的站點間撥號縮寫習慣。
| 站點 | 擴展範圍 | 網站程式碼 | 企業級 |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
為了實現平穩過渡，用戶在過渡前後的撥號習慣最好保持一致。為了做好每個地點過渡的準備，需要記錄 DID 號碼範圍和分機號碼範圍（或站點內撥號習慣）。根據這些信息，需要選擇站點間轉向數字。
表 固定長度擴展範圍 顯示了三個位置和固定長度擴展範圍的範例。由於需要避免重疊的撥號習慣，因此必須確保任何分機號碼範圍的第一位數字與短程站點間撥號的轉向數字不符。例如，如果選擇 8 作為站點間撥號的轉向數字，則任何站點中的任何分機號碼都不能以 8開頭。通常情況下，某個位置的分機號碼與分配給該位置的 DID 號碼的最後幾位數字相符。為避免衝突，可以更改分機號碼的第一位數字。例如，如果DID在 +1 如果某個地點使用了 408、555 和 8XXX 範圍的號碼，那麼該網站的擴充號碼範圍可以改用 7XXX，而不是 8XXX。
| 站點 | 擴展範圍 | 分機 | 網站程式碼 | 企業級 |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
使用美國撥號方案的裝置撥打的七位撥號字串與預先載入的美國撥號方案中用於本地撥號的七位撥號模式重疊。為避免網內撥號及網外撥號（PSTN）習慣重疊，此位置可使用強制外部接取碼。如果現有的企業編號方案和相應的站點間短撥號與國家撥號模式重疊，那麼在過渡到編號方案時，為了避免重疊，也可以將其更改為更長或更短的形式。實現這一目標最簡單的方法是在編號方案中添加一個額外的填充數字。新的更長的站點間撥號方案只需要已遷移到的用戶採用。仍在線上的用戶可以繼續撥打七位數。在這種情況下，企業撥號方案需要確保從 Unified CM 到其他系統的七位短撥號碼能夠轉換為以下兩種方式之一： +E.164 或使用部署在 上的簡化撥號格式。這需要在向本地網關發送呼叫之前完成。
表格 過渡到七位撥號 顯示了這種重新編號的範例。在這個例子中，站點間撥號的縮寫形式是使用引導數字 8，後面跟著兩位數的站點代碼和四位數的分機號碼。為了避免對 上的地點使用七位數的縮寫站點間撥號，可以透過在 中使用的兩位站點代碼前添加任意填充數字（例如8 ）輕鬆地將站點代碼更改為三位數字，這樣，從電話撥打站點間電話時，將使用引導數字 8 ，後跟填充數字 8，舊的兩位分代碼。使用者無需記住新的網站代碼；他們只需記住在站點間撥號時使用 88 作為前綴，而不是 8 。
| 站點 | 分機 | 站點代碼 | 企業級 | 站點 ode | 企業天使 |
| NYC | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
如果企業號碼格式不同，且企業號碼會顯示為呼叫方資訊（例如，沒有 DID 的裝置撥打的電話），則必須實現呼叫方資訊的不同號碼格式之間的映射，以確保回撥功能正常運作。可以透過在本地網關和主幹線路之間使用呼叫方轉換模式來實現這種映射。
錄製檔
一個架構完善的通話錄音解決方案需要仔細考慮幾個關鍵的設計要素，以確保其符合組織目標、監管要求和技術限制。兩個最關鍵的決策涉及供應商選擇和地區選擇，這兩項決策可能都需要在全球範圍內進行調整，並根據業務需求在特定地點進行調整。
1. 選擇通話錄音服務供應商
選擇合適的通話錄音服務提供者對於實現業務目標和確保組織內功能一致性至關重要：
-
全球供應商選擇： 企業通常會在全球範圍內指定一家主要的通話錄音服務供應商，以確保所有地區的功能、合規性和支援保持一致。
-
基於位置的覆蓋： 在特定地點或地區有特殊業務需求或監管要求的情況下，可能需要涵蓋全域供應商選擇，並為這些地點指定替代供應商。這種靈活性能夠滿足不同的合規要求和本地營運需求。
-
業務需求： 選擇服務提供者時，應基於對業務驅動因素的評估，例如監管合規性（例如MiFID II、HIPAA）、品質保證、爭議解決或培訓需求。
-
功能可用性： 應根據服務提供者提供所需功能的能力對其進行評估，例如即時監控、搜尋和回放功能、加密、保留策略、與分析平台的整合以及對不同呼叫類型（呼入、呼出、內部）的支援。
2. 區域選擇
確定通話錄音的儲存和處理區域對於合規性和效能至關重要：
-
全球區域選擇： 預設情況下，組織可以選擇單一區域來儲存通話錄音，以簡化管理和治理。
-
基於位置的區域覆蓋： 根據資料駐留法律或公司政策的要求，可能需要針對特定位置覆蓋全球區域設置，以確保通話錄音在規定的地理範圍內儲存和處理。
-
資料駐留要求： 該設計必須考慮到國際和本地資料保護法規（例如 GDPR、CCPA 或特定國家/地區的強制性規定），這些法規可能會規定通話錄音的保存地點和方式。
在規劃和設計通話錄音解決方案時，需要解決的另一個關鍵方面是儲存需求的估算。準確預測儲存需求對於確保有足夠的容量來支援持續的業務運作、保持合規性以及避免服務中斷至關重要。
在確定預期儲存需求時，應考慮以下幾個關鍵參數：
-
錄音通話量： 評估在給定的時間間隔內（例如，每天、每週或每月）預計會記錄的通話數量。這不僅包括對外通話，還包括內部溝通，如果業務政策或監管要求需要的話。
-
平均通話時長： 計算錄音通話的典型時長，因為通話時間越長，佔用的儲存空間就越多。不同部門或使用者群體之間的通話時長差異也應納入估算。
-
保留期： 確定錄音必須保留的時間長度，這通常由組織政策或外部法規（例如行業特定的合規標準）規定。更長的保質期將增加整體儲存需求。
-
成長預測： 考慮預期呼叫量的成長或錄音範圍的擴大，這可能是由於業務規模擴大、新的監管要求或新增使用者或地點所致。
透過徹底分析這些參數，組織可以製定強大的儲存策略，從而確保其通話錄音解決方案的可擴展性、成本效益和合規性。隨著使用模式隨時間推移而變化，建議定期審查和調整儲存分配。
緊急呼叫
任何提供 PSTN 服務的呼叫服務都必須將緊急呼叫轉移到相應的調度中心。有了它，緊急呼叫路由功能就內建在解決方案中，並支援所有支援的國家/地區的國家緊急號碼。緊急呼叫的路由是根據呼叫方定義的位置以及該位置的 PSTN 存取方式來決定的。緊急號碼是預先設定的，並且特定於用戶和設備部署所在的國家/地區。
有兩種方法可以撥打緊急電話。有基本緊急呼叫路由服務和增強型緊急呼叫路由服務。基本的緊急呼叫路由服務將使用管理員選擇的號碼來識別位置和呼叫路由，從而聯繫緊急服務部門。對於基本的緊急呼叫，呼叫路徑通常會透過客戶在該地點的公共交換電話網路 (PSTN) 選項。此外，還提供增強型緊急呼叫路由，專為美國和加拿大的部署而設計，這些部署有監管合規性要求，需要使用全國性服務提供者將緊急呼叫轉移到正確的調度中心。
所有客戶應至少部署基本的緊急呼叫配置。基本的緊急呼叫要求至少有一位客戶擁有 +E.164 將編號指派給定義在 中的每個位置。對於基本的緊急呼叫，每個地點都將由一個街道地址定義，在緊急情況下，警察、消防或救護服務將被派往該地址。在大多數情況下，位置的主要編號是代表緊急情況實際位置的最佳選擇。通常情況下，地址的分配是 +E.164 號碼與PSTN提供者協調。下面的圖片顯示了 Richardson 地點分配用作緊急回撥號碼的主要號碼。
在大多數情況下，建築物地址足以作為該地點的調度地址。但是，如果需要特定使用者或設備的額外位置詳細信息，則管理員可以使用上述相同的流程，將這些設備分配給特定地址或地址內更精確的位置（例如樓層或房間）。在 使用者管理 中， 呼叫 標籤允許為使用者及其裝置使用特定號碼來取得特定調度位址。以下圖片顯示如何為設備指派一個特定的編號。管理員負責確保設備使用的號碼已分配正確的派送位址。地址分配通常由該地區的公共交換電話網路 (PSTN) 提供者完成。
對於必須提供增強型緊急呼叫解決方案的美國電話部署，使用 RedSky 的 Horizon Mobility 整合到緊急呼叫路由。使用 RedSky 進行呼叫路由時，管理員必須透過 Cisco 註冊帳戶，並在 Calling 中設定相應的資訊。 -> 服務設定 以啟用此功能。在系統層級啟用 RedSky 服務後，管理員將在每個位置層級啟用 RedSky 服務。在某個地點啟用增強型緊急呼叫功能後，分配給該地點的所有裝置都會啟動該服務。支援增強型緊急呼叫的設備包括 Cisco MPP 電話、Cisco PhoneOS 電話和 Cisco 的 。
有兩種設定可用於在某個位置啟用增強型緊急呼叫功能。應該使用 允許 RedSky 接收網路連接資訊和測試呼叫 來驗證 RedSky 設備和基礎設施映射的配置是否正確。此設定還允許撥打 933 進行測試呼叫，以使用 RedSky 的 IVR 系統執行位置驗證，讀取呼叫者的位置。雖然本文檔不會涵蓋 RedSky 的位置追蹤配置，但管理員應始終在啟動緊急呼叫路由到 RedSky 之前測試其位置發現功能。一旦測試完成並驗證準確無誤，管理員將透過切換「將緊急呼叫路由到 RedSky」選項，將呼叫路由到 RedSky。此開關會將該地點的所有緊急呼叫轉移到 RedSky，再由 RedSky 轉接到該地點的應答中心。
增強型緊急呼叫設定同樣適用於公司內部和外部的客戶。在公司內部，可以像追蹤桌上型電話一樣追蹤它們。當用戶不在公司時，可以直接在應用程式中動態設定他們的位置。有關緊急呼叫的更多信息，請參閱 增強型緊急呼叫。
授權
有多種方法可以為使用者分配許可證。
手動分配
管理員透過介面手動為各個使用者分配許可證。
管理員可以編輯單一使用者的服務許可證，並直接指派呼叫許可證。
自動許可證分配模板
使用許可證分配模板，根據群組或組織設定自動為使用者分配許可證。
自動許可可以透過目錄同步或手動使用者更新來實現，但使用者必須擁有有效的許可證。 +E.164 格式化的電話號碼，並且這些電話號碼必須在使用者配置之前存在於某個位置。如果條件不滿足（例如電話號碼格式無效），則不會指派許可證。
透過 CSV 模板進行批量分配
上傳包含使用者詳細資料和許可證分配的 CSV 文件，即可一次新增或修改多個使用者。
CSV 匯入支援新增最多 20,000 個使用者並分配許可證，但許可證需要電話號碼和分機號碼等特定欄位。
基於 API 的分配
使用 API 以程式方式指派許可證和管理使用者。
支援使用者和許可證管理的 API 操作（人員、SCIM 2.0 和許可證 API），可用於許可證分配自動化。許可證 API 允許同時分配許可證、電話號碼和分機號碼。
| 賦值方法 | 優點 | 缺點 |
|---|---|---|
| 手動操作 | 簡單易用，適合少數用戶。 允許對許可證分配進行精確和細緻的控制。 | 不具備可擴展性，且耗時。 手動輸入容易出現人為錯誤。 |
| 自動許可證模板 | 可擴充 減少人為錯誤 可應用於新用戶和現有用戶。 | 需要提供有效的電話號碼和地址。 設定起來更複雜。 此外，還需要為每個使用者群組設定具有同等許可要求的使用者群組。 |
| 批次上傳 CSV 文件 | 對大型用戶集來說很高效 允許同時分配許可證、電話號碼和分機號碼。 | 需要仔細格式化 CSV 文件 如果電話號碼或分機號碼缺失或錯誤，則可能發生錯誤。 |
| 基於 API 的分配 | 可自動化，靈活。 允許同時分配許可證、電話號碼和分機號碼。 | 需要具備開發和API知識。 |
表 使用者配置選項 - 概要 總結了使用者配置選項及其優缺點。此概述有助於根據客戶組織規模、自動化能力以及使用者配置流程和要求選擇最佳的許可證分配方法。
Cisco 建議盡可能使用許可證範本來指派呼叫許可證。這就要求對於每個需要不同授權的使用者群組（例如 - 標準版與專業版），都存在一個具有相應群組成員資格的群組。如 使用者群組 部分所述，使用者群組可以在企業目錄中手動定義，也可以從企業目錄同步。兩種方法結合起來也是可行的。
屬於多個群組的使用者將獲得應用於其所有群組的所有分配的許可證。這樣就可以在企業目錄中使用特定於許可證的安全群組來管理許可證分配，其中最終的使用者許可證分配由群組成員資格的共同控制。
有關更多信息，請參閱 在 Control Hub 中設定自動許可證分配 和 為 Webex Calling 用戶設定自動許可證分配模板。
許可證要求
本節僅涵蓋相關許可證。其他許可證類型（例如 Webex 設備註冊、訊息傳遞、會議）不包含在內。作為設計過程的一部分，需要確定許可證要求。需要計算以下幾種許可證類型的許可證數量：
-
標準: 需要標準電話功能的個人使用者數量。
-
專業的: 需要進階電話功能的使用者和工作區數量。虛擬線路和群組語音信箱有權享有以下服務： 1:1 每種專業執照的比例。因此，在極少數情況下，當所需的虛擬線路或群組語音郵件數量超過需要進階電話功能的使用者和工作區數量時，就需要考慮額外的專業授權。
-
公共區域工作空間: 需要標準通話功能的共享使用或公共區域位置數。
-
客戶服務: 需要客戶協助功能的客服人員及主管人數。客戶協助服務包括專業執照。
-
路由清單調用: 本機用戶之間所需的雲端連線 PSTN 通話數量 and/or 本地部署的第三方專用應用程式。
-
服務生控制台: 需要存取助手控制台客戶端的使用者數量。
-
Cisco 通話計劃（外撥計劃）: 需要PSTN號碼的使用者數量 and/or Cisco PSTN 服務的出站 PSTN 呼叫存取。
專業工作區沒有專門的許可證類型。專業工作區需要專業版許可證。
僅提供共享辦公桌的工作空間提供共享辦公桌主機服務和來自共享辦公桌主機的緊急呼叫，並且不需要任何許可證。有關更多信息，請參閱 添加和管理僅限共享辦公桌的設備。
若要根據所需功能決定每個使用者和工作區所需的許可證類型，請參閱 Webex Calling 按許可證類型提供的功能。
若要區分呼叫佇列與專業授權結合提供的功能與客戶協助提供的功能，請參閱 Webex Calling 呼叫佇列與客戶協助功能比較。
使用者佈建
在 Webex 中配置使用者時，有多種選項可供選擇，每種選項都適用於不同的組織需求和環境：
-
手動配置: 管理員可以直接在系統中新增和管理單一使用者。這種方法簡單直接，但最適合小型組織或使用者變更有限的情況。
-
透過 CSV 檔案批量配置: 對於使用者數量較多的情況，管理員可以透過上傳 CSV 檔案批次匯入和更新使用者。這樣可以同時有效率地管理多達數千名用戶。
-
目錄同步選項：
目錄連接器: 這是微軟Active Directory環境中使用的自動同步工具。它會按計劃（每小時、每天或每週）同步使用者帳戶、群組和屬性。它支援多網域和多林 Active Directory 設置，並且可以同步設定檔映像和會議室物件。
Entra ID（Azure AD）精靈應用程式: 此方法專為使用 Microsoft Entra ID (Azure AD) 的組織而設計，可實現使用者帳戶和屬性從 Entra ID 到 Azure AD 的自動、近乎即時的同步。它完全由系統內部管理，只需要極少的設定。
SCIM 2.0 應用: 對於非微軟環境或其他身分識別提供者（如 Okta 或 Duo），基於 SCIM 的同步應用程式可實現自動使用者配置和取消配置，並支援屬性對應和群組同步。
-
統一 CM 用戶同步: 此選項允許透過從現有最終用戶同步到現有最終用戶來建立用戶帳戶。這要求雲端連接統一通訊（CCUC）在本地叢集上運作。但是，通常建議從 Entra ID 等集中式雲端目錄同步用戶，而不是直接從本地同步。
-
API配置: 可以使用公共 API（People、SCIM 2.0）來設定使用者。使用 API 的主要好處是可以將使用者配置與其他企業系統整合。
此概述和表格反映了主要的使用者配置選項、它們的優點和局限性，以幫助您選擇最適合您組織需求的方法。表 6. 使用者配置選項 佈建方法 說明 優點 缺點 手動 Create/manage 使用者單獨 使用者數量少時操作簡單；無需基礎設施 不具備可擴展性；對許多用戶來說耗時較長 批量（CSV 檔案） Import/update 透過 CSV 檔案批次匯入用戶 適用於團隊協作；無需編程 手動準備 CSV 檔案；動態性較低 人員和 SCIM 2.0 API 透過 Webex API 進行程式化使用者管理 靈活；支援自動化和集成 需要開發和基礎設施 目錄同步 自動同步來自 AD、Entra ID、SCIM 應用程式和統一設定管理 自動化生命週期；支援篩選和映射 設定複雜度：部分選項功能有限或需要基礎設施。
使用者群組
使用者群組管理允許管理員將使用者組織成群組，以便有效率地大量管理許可證、設定和資源。群組透過同時將策略、授權和設定範本應用於多個用戶，而不是單獨管理用戶，從而簡化管理。
使用者群組管理有以下幾個優點：
-
簡化管理 : 一次性管理多個使用者的許可證、設定和策略。
-
一致性: 在同一組使用者中套用統一的設定和許可證。
-
可擴展性: 每個群組最多可容納 25 萬名成員。
-
一體化: 從 Microsoft Entra ID (Azure AD) 或 Active Directory 同步群組，實現使用者和群組的自動化管理。
-
靈活性: 建立本機群組或同步安全性群組；手動或透過 CSV 檔案管理群組成員。
-
資源分配: 根據群組成員身分控制對嵌入式應用程式和服務的存取權。
使用者群組在配置過程中的主要應用場景包括：
-
許可證分配: 將許可證分配給群組，以便自動為群組成員提供通話、會議、訊息傳遞或混合服務等服務。
-
設定模板: 將服務設定集合（例如，訊息傳遞、會議、通話）應用於群組，以獲得一致的使用者體驗。
-
批量用戶管理 : 透過 CSV 檔案或目錄同步批次新增或刪除使用者。
-
自動化和集成 : 使用 API 或目錄同步實現使用者和群組生命週期的自動化管理。
下表總結了管理使用者群組和群組管理的不同選項。
| 選項 | 說明 | 優點 | 缺點 |
|---|---|---|---|
| 群組配置（群組） | 直接在 .中建立和管理群組。Add/remove 手動新增或透過 CSV 檔案新增成員。 | 對群組成員資格擁有完全控制權 立即應用許可證和模板 建立和編輯群組都很方便 |
需要手動更新 手動上傳CSV檔案有出錯風險 不支援與外部目錄自動同步 |
| 從 Entra ID（Azure AD）或 Active Directory 同步群組 | 自動從外部目錄服務同步安全性群組和成員關係。 | 自動同步減少了人工工作 確保與公司名錄保持一致 支持大型組織 |
無法編輯群組成員資格 同步延遲最長可達 12 小時 嵌套組需要手動選擇 |
| 群組和 SCIM 2.0 API（群組） | 使用 Groups 或 SCIM 2.0 API 進行程式化群組和成員管理 | 自動化以及與其他系統的集成 可擴展以適應大型或複雜環境 |
需要開發工作 複雜性取決於 API 的使用情況 |
雖然同步群組可以確保一致性並提供單一的管理點，但也可以採用混合方法，將同步群組和群組（在控制中心管理或透過 API 管理）結合起來。例如，許可證分配組可以是同步群組，而分配使用者和呼叫範本可以使用另一組單獨的群組。
這種全面的使用者群組管理方法使組織能夠有效地管理使用者授權、設定和策略，從而確保一致且可擴展的協作體驗。
從到遷移的建議方法
使用者的主要資料來源是資料庫，其中包含最終使用者資訊。然而，它通常不是使用者身分管理的權威來源，更重要的是，它將在過渡結束時關閉，因此被排除在身分資訊的長期權威來源之外。
Cisco 建議使用集中式雲端目錄（例如 Microsoft Entra ID (Azure AD)）作為使用者身分的唯一真實來源。將 Entra ID 中的使用者同步，可確保一致性，簡化管理，並支援單一登入 (SSO) 功能。
為確保所有使用者也存在於 Entra ID 中，各組織應核實使用者帳戶是否與 Entra ID 中的帳戶相對應。這可以透過從 Entra ID 匯出使用者清單並將其與 Entra ID 使用者清單進行比較來實現。
總而言之，建議的設定方法是使用 Azure AD 精靈或 SCIM 應用程式將使用者從 Microsoft Entra ID (Azure AD) 同步到 Webex。手動和 CSV 批量配置可作為補充方法，但對於大型組織而言，其可擴展性較差，更容易出錯。確保 Entra ID 是權威來源，並且所有使用者都存在於 Entra ID 中，對於成功遷移和跨環境的一致使用者體驗至關重要。
從本機目錄服務（如 Active Directory）過渡到雲端目錄服務（如 Entra ID (Azure ID)）與呼叫過渡無關。Cisco 建議在開始呼叫系統遷移之前，先完成向雲端目錄服務的遷移。
使用者群組設計
將企業目錄從本地端遷移到雲端後，根據授權和功能範本要求收集所需的使用者群組。對於每個群組文檔：
-
群組名稱：該團體的獨特名稱。
-
授權：若要指派給該群組的許可證（如有）以及範圍（許可證是分配給現有使用者還是僅指派給新使用者）
-
設定模板：Webex 應用程式和使用者呼叫範本。
-
目錄同步：這個群組是從企業目錄同步的，還是在 Control Hub 或透過 API 配置的本機 Webex 群組？
-
說明：這個群組將如何使用？哪些用戶應該成為這個群組的成員？
這些細節將在實施階段用於建立本機群組或企業目錄中的群組，並管理使用者的群組成員身分。
單一登入（SSO）
Cisco 建議使用 SSO 進行使用者身份驗證。使用單一登入 (SSO) 具有一些顯著的優勢，包括：
-
簡化使用者身份驗證： 使用者可以使用其企業憑證（例如 Azure ID）登入一次，即可存取其他整合應用程序，從而無需多個密碼，並減少登入提示。這樣可以確保企業密碼在身份驗證後永遠不會被儲存或傳輸，從而增強安全性。
-
簡化用戶管理： 根據公司目錄的變更自動建立、更新和停用使用者帳戶，從而減少管理開銷，並確保只有授權使用者才能存取。
-
安全性提升： SSO 透過受信任的身份提供者 (IdP) 集中進行身份驗證，從而減少密碼疲勞和與密碼相關的洩露風險。
-
輕鬆整合多因素身份驗證 (MFA)： MFA 可以透過 Cisco Duo 等身分存取管理解決方案輕鬆實現，也可以透過 IdP 的 MFA 支援實現。
實現服務單一登入 (SSO) 有多種方案：
-
基於 SAML 2.0 的單一登入： 支援 SSO 整合的主要協議，可在身分識別提供者 (IdP) 和服務提供者之間安全地交換身分驗證資訊。
-
OpenID Connect (OIDC)： 支援作為 SSO 整合的替代現代身份驗證協定。
-
Webex身分： 同時支援作為身分提供者選項。
SSO 透過集中配置和管理，需要在和所選的身份提供者 (IdP) 之間交換元資料。
配置完成後，可以在啟動前對 SSO 進行測試，以確保設定正確。
Cisco 支援與多種經過測試且常用的身分識別提供者 (IdP) 和身分識別管理系統 (IAM) 集成，包括但不限於：
-
思科雙核
-
Okta
-
微軟活動目錄聯合身分驗證服務 (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 BIG-IP.
這些身分提供者符合 SAML 2.0 或 OpenID Connect 標準，並且經過驗證，與 Cisco 協作解決方案相容。
支援多個身分提供者
允許組織配置具有多個身分提供者的 SSO，以適應複雜的 IT 環境，例如合併、收購或分散的 IT 部門，其中不同的群體使用不同的身分提供者。可以透過使用 Cisco Duo 等企業 IAM 系統中的多 IdP 功能來實現多 IdP 支持，也可以透過整合該系統來實現。
的多重身分提供者 (IdP) 支援可滿足組織在各種 IT 環境中進行靈活、安全的身份驗證的幾個關鍵用例：
1. 合併與收購
當公司合併或收購其他公司時，它們通常擁有獨立的 IT 基礎設施和不同的身分提供者，這些提供者無法進行聯合。支援多個身分提供者 (IdP) 可以讓兩個組織的使用者進行身份驗證並安全地協作，而無需立即統一他們的身份系統。
2. 多個獨立的IT部門
大型組織或政府機構可能擁有多個獨立的 IT 部門，每個部門管理自己的身分提供者 (IdP)。的多身份提供者功能使這些部門能夠維護自己的身份驗證系統，同時允許用戶無縫存取。
3. 不同的使用者群組或網域
擁有不同使用者群組（例如，員工與承包商）或多個電子郵件網域的組織可以設定路由規則，根據網域或群組成員資格將身分驗證請求導向至對應的身分提供者。這支援差異化的存取策略和安全控制。
4. 支援多種身份驗證協議
支援 SAML 和 OpenID Connect (OIDC) 身分提供者，讓組織可以根據其現有的基礎架構和安全要求整合不同類型的身分提供者。
5. 增強安全性和合規性
透過啟用多個身分提供者 (IdP)，組織可以實施更強大的身分驗證機制，包括透過 Duo 等整合實現多因素身分驗證 (MFA)，並在不同的使用者群體中強制執行一致的安全性策略。
6. 簡化的使用者體驗
使用者可以使用各自身分提供者 (IdP) 提供的現有憑證進行驗證，從而提供統一的登入體驗，即使底層存在多個身分系統的複雜性。
雖然支援多種身分提供者 (IdP) 提供了靈活性，但這需要安全性和身分識別團隊之間仔細協調，以保持一致的安全策略並避免潛在的漏洞。
雙 MFA 與 SSO
Duo Access Gateway (DAG) 可以使用現有的本機或雲端目錄（例如 Active Directory (AD) 和 OpenLDAP）對使用者進行身份驗證。它還支援與其他身分識別提供者（如 Microsoft ADFS、Microsoft Azure、Okta、OneLogin、CAS 和 Shibboleth）的整合。這種靈活性使得組織能夠使用其現有的目錄基礎架構來實現具有 Duo MFA 的 Webex SSO。
Duo 在主目錄驗證之上提供了一個強大的身份驗證層。它作為身分提供者 (IdP) 使用 SAML 2.0 來強制執行雙重認證 (2FA)，然後再授予存取權限。Duo 會根據可設定的策略評估使用者、裝置和網路環境，以允許或拒絕訪問，從而增強安全性，而不僅僅依賴使用者名稱和密碼。Duo 還提供靈活的策略控制，例如對某些應用程式要求每次登入時都進行 MFA 驗證，而對其他應用程式則要求較少頻率的 MFA 驗證。
Cisco Duo 的優點包括：
-
增強安全性： 增加防釣魚的多因素身份驗證 (MFA) 以保護訪問，降低密碼洩露的風險。
-
靈活的政策： 允許對每個應用程式或使用者群組的身份驗證要求進行精細控制。
-
與現有目錄整合： 支援本地 AD、OpenLDAP、雲端目錄和各種 SSO 供應商，最大限度地減少基礎架構變更。
-
用戶便利性： 支援單一登入 (SSO)，使用戶只需登入一次即可安全地存取多個資源，從而減少密碼疲勞。
-
可信賴端點： 支援 Windows 和 macOS 用戶端的裝置信任，提高安全性。
-
自助註冊： 線上註冊和雙重提示可改善 MFA 設定過程中的使用者體驗。
雙重認證 (Duo MFA) 結合單一登入 (SSO)，利用現有目錄（如 Active Directory 和 OpenLDAP）或雲端身分提供者來驗證使用者身分。Duo 的角色是透過 SAML 2.0 整合強大的、策略驅動的第二因素身份驗證，在透過 SSO 增強安全性的同時保持用戶便利性。其優點包括：增強安全態勢、靈活執行策略、無縫整合以及更好的使用者體驗。
Cisco建議為使用者實施SSO。為了增強安全性，建議與 Cisco Duo 整合。
企業身分與存取管理 (IAM) 和單一登入 (SSO) 策略應在開始從 [此處應填入系統名稱] 過渡到 [此處應填入系統名稱] 之前部署。
功能
具備該服務所包含的所有核心功能。這包括許多企業級通話功能，這些功能已經存在多年。您可能無法看到功能和功能之間 100% 的對等性，但是，正如您在下圖中所看到的，關鍵的通話功能在 中可用。
除了眾多使用者功能外，該平台還包含一些核心系統功能。這些功能包括自動應答、呼叫佇列、呼叫駐留等。您可以在 服務 → 通話 → 功能 下查看所有可用的核心系統功能，如圖 Webex 通話核心功能所示。
自動語音應答
自動應答系統允許 24/7 實現來電處理的自動化，無需人工接聽每個來電即可高效處理來電。
自動應答系統會接聽來電，並為來電者提供一系列選項，供其選擇將電話轉接到哪裡。這可以是給某人、語音信箱或呼叫服務（例如呼叫佇列）。來電者使用手機撥號鍵盤從自動應答選單輸入號碼。
自動應答系統支援以下主要功能：
-
工作時間和非工作時間安排
-
假日排程
-
撥號選單選項，引導您的客戶前往他們需要去的地方
-
自訂問候語
-
按名稱撥號選項
-
來電轉接選項
-
控制中心分析和報告。
有關更多信息，請參閱 管理自動助理。
呼叫駐留
呼叫駐留功能使用戶能夠輕鬆地將通話 置於保持狀態 ，以便其他用戶在有空時輕鬆取回通話。它還允許接聽原始電話的用戶在通話保持期間撥打或接聽其他電話。
有兩種類型的呼叫停車服務可供選擇。 :
-
呼叫駐留直撥 - 允許任何使用者將呼叫駐留到其他使用者的分機號碼或管理員定義的呼叫駐留分機號碼。
-
呼叫駐留群組 - 允許指定使用者群組自動將呼叫駐留到為該群組定義的可用駐留目的地。這些目的地可以是群組成員的分機號碼或呼叫停車分機號碼。
根據配置和停車類型，用戶可以透過撥打 來找回呼叫。 *88+><extension of parked call>，按下與呼叫駐留分機關聯的線路鍵，或使用其 IP 電話上的軟鍵。
使用者可以設定召回選項，在指定時間後將已停放的呼叫召回給停放呼叫的使用者或備用使用者。
有關更多信息，請參閱 控制中心中的呼叫駐留管理。
來電代接
呼叫代接功能允許管理員定義一組使用者（成員），他們可以接聽其他成員的電話。這樣，當隊友忙碌而無法接聽來電時，用戶可以接聽電話。
同一組使用者必須位於同一地點。
用戶可以使用手機或辦公桌上的電話接聽電話。
-
:
-
支援視覺和音訊通知
-
來電通知
-
基於FAC的撥號 *98) 或通知彈出視窗接聽
-
多線路來電接聽通知。
-
-
桌上型電話：
-
來電通知
-
透過手機 LED 指示燈發出聲音提示和視覺通知。6821 型號僅支援音訊提示音。
-
當選擇的通知類型不是 無
-
-
僅對主線路發送來電接聽通知。
-
更多資訊請參閱 設定呼叫代接群組。
呼叫佇列
其核心功能包括純語音通話佇列，任何擁有專業版授權的使用者都可以成為呼叫佇列的一員，擔任座席或主管。此功能使用戶能夠有效率地與客戶互動。呼叫佇列支援呼叫中心的一些核心功能，例如語音佇列、回撥、技能或優先權路由、座席佇列管理、分析、報告等。
Cisco 呼籲整合 Microsoft Teams，讓客服人員可以直接透過 Microsoft Teams 用戶端存取呼叫佇列呼叫和功能。
呼叫隊列支援以下主要功能：
-
問候與留言（歡迎、安慰、輕聲細語等）
-
待話期間背景音樂
-
回撥
-
佇列路由策略（夜間服務、假日、轉送）
-
代理隊列 login/logout
-
代理佇列狀態管理
-
或桌上型電話支援
-
主管代理呼叫監控、指導、插話或透過功能存取代碼 (FAC) 接管
-
（管理員權限）適用於：
-
隊列管理
-
代理和隊列分析及報告
-
隊列、代理和主管管理。
-
有關更多信息，請參閱 配置呼叫隊列。
它具有客戶協助附加功能，可提供額外的呼叫佇列功能，並為代理商和主管提供更好的使用者體驗。有關呼叫佇列和客戶協助功能的比較，請參閱 Webex Calling 呼叫佇列和客戶協助功能比較。
群組搜尋
呼叫群組允許透過預先設定的呼叫路由模式，將呼入呼叫路由到特定的使用者群組。這樣可以確保電話由正確的使用者群組接聽，或前往語音信箱進行後續跟進。
呼叫群組和呼叫佇列之間的一個很大的區別是，呼叫在呼叫群組中不會排隊，因此，如果呼叫群組中沒有使用者可以接聽電話，則該電話將被斷開、發送到語音信箱或轉發到另一個號碼（使用者或服務）。
有關更多信息，請參閱 在 Control Hub 中管理狩獵組。
操作模式
運作模式功能可讓企業有效率地將呼叫路由到各種目的地（使用者、語音信箱、呼叫服務，如呼叫佇列）。呼叫的路由地點和時間取決於一天中的時間和一周中的日期安排，任何使用者都可以被授權管理這些模式（安排），以控制呼叫路由的變更。
例如，呼叫佇列的呼叫可以路由到另一個呼叫佇列，由不同時區的客服人員在非工作時間接聽電話；在工作時間內，呼叫可以路由到本地客服人員；在假日，呼叫可以路由到語音信箱，以便在客服人員返回辦公室後進行跟進。
授權使用者可以根據需要更改來電在特定時間段內的路由方式，在這些不同的呼叫轉移方案（模式）之間進行切換。這些用戶可以透過他們的…來管理這些模式。 6800/7800/8800 MPP 電話、9800 電話或在使用者中心 管理模式。
有關更多信息，請參閱 Webex Calling 中基於操作模式的呼叫路由。
傳呼群組
尋呼群組允許用戶發起單向呼叫，向一組用戶發送語音訊息。每個群組最多可包含 75 個目標用戶 and/or 透過撥打預先定義的號碼或分機號碼即可存取的工作區。
當使用者呼叫尋呼群組時，會同時呼叫群組內所有指定目標，此時呼叫者可以說出他們的留言，並在說完後掛斷電話。
有關更多信息，請參閱 在 Control Hub 中配置分頁組。
錄製檔
支援錄製使用者撥打或接聽的電話。這可能是出於品質保證、安全保障或訓練方面的需要。預設情況下，通話會被錄音，但如果需要其他錄音功能或合規性和監管要求，也可以使用其他第三方錄音提供者。
當使用該平台進行錄音時，所有錄製的通話都在其中進行管理。具有合規官角色的完整管理員可以播放和下載錄影。如果沒有合規官角色，管理員只能刪除錄音。
有關此功能的更多資訊以及第三方錄音列表，請參閱 管理 Webex Calling 的通話錄音。
單一號碼存取
單一號碼通話功能允許撥打用戶電話號碼的來電同時響鈴多個裝置。這包括其他座機以及手機。用戶還可以透過這些裝置撥打電話，並且可以在這些裝置之間推送和拉取電話。
有關此功能的更多資訊以及管理員如何在 中配置它，請參閱 配置單一號碼存取（隨時隨地辦公）。
如需了解使用者如何在 Webex 使用者中心（入口網站）中自行管理和設定此功能，請參閱 設定單號碼存取（隨時隨地辦公）。
語音信箱群組
語音信箱群組允許共用語音信箱，可以將其指派給使用者或用於呼叫路由功能。設定語音信箱群組的一些原因包括：
-
部門或工作小組通用語音信箱
-
為自動應答機或呼叫群組新增語音信箱選項
-
從呼叫佇列發送溢位呼叫
-
只需要語音信箱的用戶。
有關更多信息，請參閱 管理 Webex Calling 的共享語音郵件和入站傳真箱。
Webex 的「呼叫功能」頁面上列出了話務員控制台，但它是一個附加功能，需要購買話務員控制台許可證才能使用。
有關更多信息，請參閱 開始使用助理控制台。
有關所有功能（包括一些附加功能）的信息，請參閱 Webex Calling 按許可證類型提供的功能。
實施
網路整備
過渡到雲端的第一步是確保本地網路和雲端之間 可靠、安全的 網路連線。
由於大多數組織透過一個或多個 防火牆 或 安全設備連接到互聯網，因此驗證 所需的流量是否得到支援至關重要 。
網路和安全管理員必須從以下幾個方面來理解這些流程：
-
方向 （入站 vs 出站）
-
協定 （例如：SIP TLS、SRTP、HTTPS）
-
服務使用的 IP 位址範圍
-
必須開啟或允許的連接埠號碼 。
這樣可以確保企業防火牆、NAT 設備和其他網路基礎架構得到正確配置，以適應流量，同時維護企業安全策略。
有關所需流程（包括 IP 位址、連接埠和協定）的信息，請參閱 Webex Calling 的連接埠參考資訊。利用這些資訊配置現有部署中的防火牆、代理程式和其他網路基礎設施，以啟用網路流量。
對於雲端協作服務，建議採用從每個分公司或站點進行去中心化網路存取的方式。透過允許流量從本地流出，該模型：
-
減少往返延遲和抖動，提高整體通話質量
-
隨著更多用戶和網站過渡到新平台，可高效擴展。
-
與 SD-WAN 無縫協作，可將會話動態路由到最近的雲端入口點，以實現最佳效能。
- 允許根據用戶的公共 IP 位址追蹤用戶位置，這有助於媒體路徑分析和故障排除。
此外，各機構必須確保每個站點都有足夠的網路頻寬。頻寬的大小應根據預期的同時呼叫數、所選編解碼器（例如 Opus 或 G.711）以及訊號、重傳和成長的開銷來決定。這與 PPDIO 生命週期的準備階段相一致，並為遷移奠定了堅實的基礎。
初始設定
部署實施階段的初始設定小節是建立結構良好且易於管理的雲端呼叫環境的基礎。此階段包括一些關鍵任務，例如建立組織、取得和分配許可證，以及驗證和認領公司域名，以確保適當的使用者管理和安全。此外，它還包括提供許可證範本以自動分配使用者許可證，配置單一登入 (SSO) 以簡化使用者身份驗證和增強安全性，以及調整服務和用戶端設定以符合組織政策和使用者需求。完成這些初始設定活動可確保環境配置得當，以實現可擴展性、安全性和流暢的使用者體驗，為後續的部署和營運階段奠定基礎。
網域驗證
為了能夠識別在貴公司電子郵件網域上註冊的用戶，驗證您的網域至關重要。如果沒有進行網域驗證，用戶將被分配到消費者組織，這將使貴公司的用戶管理變得複雜。網域驗證是必要的步驟，它可以讓您的組織有效地認領和管理這些使用者。
請確保與使用者電子郵件地址關聯的所有網域均已驗證。域名驗證並非排他性的；同一個域名可以在多個組織中進行驗證。
有關管理域名的更多信息，請參閱 管理您的域名。
認領（轉換）現有用戶
成功驗證網域後，您可以將已註冊使用貴公司電子郵件網域的使用者新增至您的組織。此流程將所有使用者整合到一個組織框架下，從而實現集中管理和簡化管理。透過認領這些用戶，您可以確保公司對用戶帳戶擁有完全控制權，從而能夠有效地分配適當的授權、配置服務並提供必要的支援。這種統一的管理方法增強了安全性，簡化了使用者配置，並確保了整個組織對服務的一致存取。認領使用者還可以防止他們在外部或消費者組織中被管理，從而維護組織的完整性和對協作資源的控制。
有關認領用戶的更多信息，請參閱 將用戶認領到您的組織（轉換）用戶。
配置並測試目錄同步
為了實現無縫的使用者和群組管理，您可以將企業目錄中的使用者和群組（無論是 Microsoft Entra ID（以前稱為 Azure AD）還是 Microsoft Active Directory (AD)）同步到 。此流程可確保使用者身分和群組成員資格在您的環境中保持一致。
對於實施分階段部署的組織而言，在初始推廣階段控制和限制同步範圍至關重要。這樣可以最大限度地降低意外變更的風險，並允許在更廣泛採用之前進行有針對性的測試。
篩選同步使用者最有效的方法是利用目錄群組成員關係：
| 1 |
建立專用同步群組： 在企業目錄（Microsoft Entra ID 或 AD）中，建立一個專門用於同步的安全性群組（例如，同步群組）。 |
| 2 |
將目標用戶加入群組： 僅將您想要同步的使用者（例如試點階段的測試群組）新增至此群組。這樣可以讓你嚴格控制哪些人參與同步過程。 |
| 3 |
配置基於群組的篩選同步協定： 在 Directory Connector 或 Entra ID 設定中設定同步協定時，請將範圍設定為僅包含指定群組的成員使用者。
|
| 4 |
根據需要擴展群組： 隨著部署階段的推進，只需在同步群組中新增其他使用者或群組即可。同步範圍將自動擴大到包括這些用戶，從而實現可控和漸進式的推廣。 範例實施步驟：
參考： |
設定並測試單一登入 (SSO)
單一登入 (SSO) 透過允許使用者使用其企業憑證進行一次身份驗證並無縫存取來增強安全性並簡化使用者存取。支援與符合 SAML 2.0 標準的身份提供者 (IdP) 的 SSO 集成，包括 Microsoft Entra ID（以前稱為 Azure AD）、Active Directory (AD) 聯合解決方案和各種第三方身分提供者。
此時應該實施並測試已設計的 SSO 設定。
參考：
取得、提供和核實許可證
作為初始設定的一部分，必須採購、提供和驗證適當的許可證，以有效地啟用和管理服務。採購流程包括根據使用者角色和工作負載選擇授權類型，例如專業版、標準版和工作區版授權。許可證透過思科的軟體平台或合作夥伴產生和分配。採購和配置完成後，需要核實許可證數量是否正確。此流程可確保組織擁有已啟動並可用於部署的正確許可證。
作為初始許可設定的一部分，配置基於組織的自動許可對於簡化新使用者的許可證分配至關重要。這種設定允許在將使用者新增至組織時自動授予許可證，從而無需手動分配許可證。在組織層級配置自動許可時，您可以選擇要指派的服務並定義範圍，例如僅將授權套用至未來的用戶，或也包含現有使用者。
但是，如果您的部署計劃涉及在群組層級使用自動許可，您可以選擇不在組織層級分配許可證，以避免衝突或重複的許可證分配。透過群組層級自動許可，許可證是根據群組成員身分分配的。多個使用者群組的使用者將獲得所有適用群組分配的許可證。
必須在目錄同步完成後執行基於群組的許可證分配配置，以便同步群組存在並可用於許可證分配。
具體來說，自動許可證分配需要額外的配置詳細信息，例如用戶位置和電話號碼分配。使用者的工作電話號碼必須已輸入。 +E.164 格式已設定好，已預先配置，並已指派給有效位置，以便許可證自動啟動。如果這些條件不滿足，則不會自動為使用者提供服務，可能需要人工幹預。
總而言之，如果您想要進行廣泛的、組織範圍內的授權分配，請為新使用者設定基於組織的自動許可。如果您希望進行更精細的控制，或者每個群組有不同的許可需求，請在群組層級配置自動許可，避免在組織層級分配許可證，以防止重疊並確保正確的許可證管理。
Webex 通話服務設定
對全域服務設定進行全面審查和配置至關重要。
首先訪問並導航至設定部分。仔細檢查每個可設定選項，包括但不限於內部撥號配置、緊急呼叫參數、呼叫路由策略、語音郵件管理和設備預設設定。
調整這些全局設置，以反映貴組織的政策和設計決策。
此外，還要設定設定、使用者和應用程式模板。
試辦移民
在實施階段，執行試點遷移是驗證從到過渡的關鍵里程碑。此試點計畫涉及在一個或多個地點為平台提供代表性的使用者子集，以確保所選用戶群體反映多樣化的使用案例和組織角色。在用戶遷移的同時，包括語音郵件、自動應答、呼叫佇列和呼叫組在內的重要協作服務必須過渡到其等效版本，以維持業務連續性和服務功能。
試點遷移應利用思科提供的工具和第三方遷移實用程式的組合，這些工具和實用程式計劃用於更廣泛的組織部署，以確保在代表性條件下對流程、自動化工作流程和整合點進行徹底驗證。
本次試點部署的主要目標有兩個：首先，驗證並改善端到端過渡流程，包括使用者配置工作流程、資料遷移程序和終端配置；其次，全面驗證遷移服務在實際運作條件下的功能。
這種分階段的方法使專案團隊能夠在受控環境中識別和糾正任何技術或程序問題，收集使用者對新平台體驗的回饋，評估所選遷移工具的有效性，並在進行更廣泛的組織部署之前建立對遷移方法的信心。
本次試點階段所獲得的見解對於優化後續遷移浪潮、確保整個企業平穩過渡並降低風險至關重要。
採購公共交換電話網
若要為 [此處應填寫特定名稱] 取得 PSTN 服務，首先在 [此處應填寫特定名稱] 中選擇 PSTN 連線選項。
如果一個組織計劃維持混合雙呼叫控制（ 階段 1 在圖 分階段呼叫轉換：對於混合雲和雲端)，無論是暫時的還是永久的，他們都需要為本地 PSTN 部署一個或多個本地網關，以允許在端點之間進行呼叫。
如果最終目標是全面過渡到雲端（ 第 2 階段），包括 PSTN，那麼 PSTN 將需要 Cisco Calling Plan 或 Cloud Connect 選項。
與您選擇的服務提供者合作，訂購和轉移電話號碼，然後再進行配置。訂購電話號碼或發起端口訂單僅 required/possible 適用於本地 PSTN 和 Cloud Connect。對於 Cisco 通話計劃，一旦建立位置，即可在 Control Hub 內啟動訂購和連接埠轉移，且此流程適用於 Cisco 通話計劃可用的國家/地區。有關 Cisco Calling 套餐的更多信息，請參閱 Cisco 套餐入門。
作為 PSTN 實施的一部分，請確保您的服務提供者已為您的位置啟用入站和出站 PSTN 服務。此外，請執行測試呼叫，以驗證呼叫是否透過您選擇的 PSTN 連線正確路由。
配置位置
在向系統中新增使用者和設備之前，必須先配置呼叫位置。每個地點都必須輸入有效的街道地址。在美國和加拿大，該位址經過驗證，並由平台用於發送緊急呼叫的 PIDF-LO 位置資訊。
配置使用本地 PSTN 的位置時，需要相應地設定本地網關。在[此處應填入系統名稱]中，必須為每個本機閘道建立一個中繼和一個路由組，然後將路由組指派為該位置的 PSTN 選擇。Cisco 強烈建議始終選擇路由組作為 PSTN 選擇，因為這種方法可以方便地在將來添加額外的中繼，從而支援可擴展性和冗餘性。Cisco 還建議在每個 PSTN 中繼上啟用雙重身分和 P-Charge-Info 支持，因為這簡化了對撥出直撥或轉撥電話的計費方的識別。如果您的 PSTN 供應商使用不同的計費標頭，您可以將本地網關上的 P-Charge-Info 標頭中的資訊複製到所需的計費標頭中。
對於使用 Cloud Connect 或 Cisco Calling Plan 作為其 PSTN 選項的位置，只需在設定期間為該位置選擇相應的 PSTN 選項即可。如果該位置使用 Cloud Connect 或本地 PSTN，則需要新增在上一個步驟中訂購的電話號碼。如果您不希望號碼立即包含在呼叫路由中，可以將其新增為非活動號碼；您可以在稍後將這些號碼指派給使用者或功能時啟動它們。
務必為每個地點設定主號碼。主號碼可以分配給使用者或功能，例如自動語音應答系統。若要在該地點啟用語音信箱，請確保設定語音信箱引導號碼，也稱為語音入口網站號碼。
呼叫位置的其他設定包括配置緊急呼叫詳細信息，例如緊急回撥號碼、通知選項和增強的緊急呼叫功能。您還應根據每個地點的需要，檢查並調整錄音設定、語言偏好和設備配置。如果您的組織使用帶有企業重要號碼的縮短的站點間網路撥號，請記住在內部撥號設定中為位置配置唯一的站點代碼。最後，如果對外撥號需要撥出撥號數字，請務必在對外撥號設定中進行設定。在設定出站撥號數字時，思科建議啟用出站撥號數字強制執行，以確保一致性。
與本地呼叫控制系統集成
要與本地呼叫控制集成，需要設定中繼線、路由組、企業撥號計畫以及位置和全域設定。首先設定用於與本機呼叫控制系統互連的中繼線和本機閘道；只有在需要專用中繼線時才需要執行此步驟。如果現有的中繼和路由組足以滿足您的部署需求，則可以將其用於本地互連，而無需額外配置。
一旦中繼線和路由群組建立完畢，就可以開始建立企業撥號計劃，並將對應的路由群組指派給每個撥號計劃作為目標。當整合涉及透過不同中繼線連接的多個本地呼叫控制系統時，將需要多個撥號方案。務必確保這些撥號方案僅包含將呼叫路由到本地目的地所需的模式。
如果您的部署需要支援未知擴充路由，則應在位置層級啟用此功能。此外，當啟用未知分機路由時，必須在呼叫服務設定的 呼叫路由和場所之間 部分中指定最大未知分機長度。這確保了在整合環境中實現無縫的呼叫路由和基於分機撥號場景的正確處理。
分批遷移用戶
當您將使用者從 [系統名稱] 遷移到 [系統名稱] 時，可能無法同時遷移所有使用者。這可能是由多種原因造成的，包括但不限於網站或使用者數量、網站遷移所需時間等。 and/or 同一時間的使用者群、支援變更視窗的 IT 或網站資源有限、變更視窗持續時間、變更的複雜性等。
分階段遷移使用者時，確定哪些使用者需要在同一 批次中一起遷移至關重要。主要目標是將那些在呼叫服務和功能方面存在依賴關係的使用者一起遷移。您希望確保其所有呼叫功能（例如呼叫隊列）在過渡到新系統後都能像過渡之前一樣完全正常運作。
即使您實現了本機網關之間的呼叫互通，您也無法透過此連線拆分共用服務或功能。因此，您需要透過查看以下特徵來確定使用者之間的依賴關係：
-
使用 BLF 監控其他用戶
-
在同一狩獵飛行員、呼叫隊列等中
-
共用線路
-
使用電話接聽
-
使用相同的呼叫駐留號碼
-
內部通訊
-
行政人員/管理員。
例如，某個使用者是正在過渡到新版本的 Hunt Group 的成員。該用戶將過渡到 Hunt Group，並與 Hunt Group 的所有其他成員進行互動。因此，過渡完成後，Hunt Group及其成員可以在新平台上成功接聽電話。
當用戶因不同的通話服務和功能而連接到不同的用戶群組時，這會變得更加具有挑戰性。這將需要同時對多組用戶和一個呼叫服務進行遷移。
使用您在 準備 階段使用的 Migration Insights 工具或第三方工具的輸出結果，確定哪些使用者和功能應該分組在一起。此輸出結果應該用於制定遷移計劃，並能幫助您了解如何將需要一起遷移的使用者和功能進行分組。
批量用戶遷移的關鍵步驟如下：
-
確定要一起遷移的用戶
-
確認所有用戶均已登入
-
驗證所有使用者的 TN 是否存在
-
請核對目錄中電話號碼格式是否正確。
-
請確保使用者群組的許可和設定範本已正確設定。
-
驗證或配置使用者群組的所有呼叫服務和功能（在過渡之前或期間，視情況而定）
-
在公司目錄中，將使用者新增至已啟用通話的使用者群組。
-
利用工具－使用者和功能遷移工具 and/or 第三方工具
-
Disable/Delete user/device 電話號碼查詢和呼叫 features/services 過渡之後。
遷移完一組用戶後，測試一部分用戶，以驗證其所有呼叫功能和服務是否正常運作。如果呼叫佇列、呼叫群組等呼叫功能會隨使用者群組一起遷移，則測試這些呼叫服務的功能是否正常。
工作區
在[此處原文缺失]，工作區指的是可以分配設備、分機和使用者的共享位置（例如會議室、小型討論空間或共享辦公桌）。與傳統的統一通訊管理 (Unified CM) 電話不同，工作區具有以下特點：
-
以位置為中心：與物理空間相關。
-
設備靈活：可配備一個或多個設備（桌上型電話、白板等）。
一旦確定了過渡到新系統所需的工作區，就可以在「設備」下添加它們。每個工作區都需要分配設備，如果它們已經在 Unified CM 中，則需要重設或重新配置。可啟用或停用語音郵件、呼叫轉移和呼叫代接等功能，並可依需求套用視訊通話、呼叫駐留和行動策略。透過撥打內部和外部電話、測試視訊、會議和行動功能來測試每個工作區。最後，告知使用者有關工作空間設備和預訂的任何適用流程。
有關工作區的更多信息，請參閱 工作區。
供應設備
目前已註冊的手機需要遷移到新系統，作為雲端遷移的一部分。為了盡可能簡化遷移過程，並將失敗的可能性降到最低，思科建議同時遷移實體站點或部門。但是，由於功能依賴性，您可能需要分批遷移使用者。有關更多詳細信息，請參閱 “分批遷移用戶 ”部分。
任何需要從中遷移過來的支援電話都需要配置為使用者或工作區，實體電話需要重新配置才能註冊。此外，7800 和 8800 系列電話需要將其韌體從企業韌體升級到多平台電話 (MPP) 韌體。該過程包括在載入註冊所需的 MPP 韌體之前載入過渡固件。此外，還需要相應的遷移許可證。思科在過去幾年中改進了這個流程，讓您更容易將企業韌體電話升級到 MPP 韌體。有關完成韌體升級的步驟的更多信息，請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
除了本文中概述的步驟之外，還有一個內建工具 將您的電話遷移到 Webex Calling，您可以使用該工具幫助您將 7800 和 8800 電話從企業版韌體遷移到 MPP 韌體。該工具還允許您將手機新增至相應的使用者或工作區，並將其分配給相應的使用者或工作區。有關工具使用的更多信息，請參閱 遷移您的手機。
對於已註冊的 9800 系列手機，上述韌體遷移要求不適用。這些手機運行 PhoneOS，該系統同時受到 和 的支援。要將這些電話遷移到 Webex Calling，您需要將它們新增至 Webex Calling，將它們指派給使用者或工作區，然後將電話恢復原廠設定。PhoneOS 註冊啟動順序 下圖顯示了 PhoneOS 的啟動順序，以及手機添加到 [此處應填寫系統名稱] 後如何註冊，即使手機仍在 [此處應填寫系統名稱] 上配置 and/or DHCP 選項（例如 - 150）正在使用中。
支援將 PhoneOS 設備恢復出廠設置，從而實現零接觸入駐。管理員可以透過 CUCM 管理頁面遠端將 9800 和 8875 電話恢復出廠設置，從而無需實體存取電話即可完成入駐。此功能自 2025 年 9 月 9 日起在設備包中支援：
-
CUCM v15 - 統一通訊管理器版本 15
-
CUCM v14 - 統一通訊管理器版本 14。
有關 9800 系列註冊流程的更多信息，請參閱 註冊流程。
除了 Cisco IP 電話之外，可能還需要設定其他設備 ，例如類比電話適配器 (ATA)、無線 (Wifi、DECT) 電話、視訊設備、語音閘道以及第三方設備和電話。許多此類設備不像 IP 電話那樣有韌體升級途徑，無法從企業韌體過渡到雲端韌體。因此，您需要在控制中心配置這些設備。有些設備無法直接過渡，需要用同等型號的設備來替代（例如ATA）。 191/192) 還有一些需要手動重新配置。 and/or 軟體變更。
-
語音網關 - 若要遷移本機網關，請參閱 遷移本機網關。
有關在 Control Hub 中配置語音網關 VG400、VG410 或 VG420 的更多信息，請參閱 本地網關
-
類比電話適配器 (ATA) - 若要開始使用 Cisco ATA 191 和 192，請參閱 Cisco ATA。
-
Wifi 無線電話 - 若要整合無線電話 840 和 860，請參閱 整合 Webex 無線電話。
-
DECT 無線電話 - 若要開始使用您的新 Cisco IP DECT 6800 系列，請參閱 Cisco IP DECT。
若要在 Control Hub 中建置和管理數位 DECT 網絡，請參閱 管理 DECT 網路
有關 Cisco IP DECT 6800 的更多信息，請參閱 部署指南
-
第三方設備和手機 -與 第三方供應 商合作 device/phone 要求以及遷移或替換這些要求的過程以提供支援。
設定功能
任何所需的通話功能都需要在過渡之前或期間進行設定。如在「分批遷移使用者」部分所討論的，當使用這些功能的使用者進行遷移時，需要配置和遷移呼叫功能。
有關如何配置各項功能的詳細信息，請參閱相應的配置幫助文章。
驗收測試
驗收測試確保遷移後的環境符合功能要求，按預期運行，並在所有通訊工作流程中提供無縫的使用者體驗。此驗證過程涉及多個方面，涵蓋從用戶配置和號碼分配到高級呼叫功能的運行性能等各個方面。
本節提供範例並重點介紹驗收測試期間需要考慮的關鍵方面；但是，它並非旨在作為詳盡或全面的檢查清單。
用戶配置和號碼分配
驗收測試的一個基礎面向是驗證所有使用者是否已在系統中準確、完整地配置。這需要對來源目錄和新建立的用戶群進行徹底比較，以確保每個用戶帳戶及其相關屬性（例如分機號碼和直接撥入號碼 (DID) 分配）都已正確遷移。配置的完整性不僅對第一天的運作至關重要，而且對後續的管理和支援也至關重要。
號碼分配驗證包括確認每個使用者都分配了正確的分機號碼和外部號碼，並且這些號碼在內部（網內）和外部（PSTN）呼叫流程中都能正確路由。必須檢查是否有重疊、缺少分配或配置錯誤，這些都可能導致呼叫路由錯誤或服務中斷。
PSTN通話流程與來電顯示
一個完善的驗收測試程序必須包含 PSTN 通話流程的端對端驗證。這包括呼入和呼出兩種情況。對於 PSTN 來電，測試團隊應確認通話是否已送達至預期的終端，無論是個人使用者、呼叫佇列、呼叫群組或自動話務員。必須成功撥出 PSTN 電話，尤其要注意正確傳遞和顯示來電顯示訊息。這包括確保按照組織政策和監管要求，向外部接收者顯示正確的來電者姓名和號碼。
測試還應涵蓋故障轉移場景，例如處理無法存取的端點或網路中斷。這有助於確認回退機制和備用路由是否正常運行，從而維持服務的連續性和可靠性。
網內呼叫流程
內部或網內呼叫流程構成了企業通訊的骨幹。該領域的驗收測試驗證了組織內使用者之間的通話是否正確路由，以及呼叫轉移、保持、轉送和會議等功能是否如預期運作。必須確認撥號方案的完整性、分機之間的連接性以及對組織呼叫策略的支援。
使用者呼叫處理和功能驗證
驗收測試的一個重要方面是驗證使用者如何使用 和支援的桌面電話處理通話。此流程的重點是確認日常通話工作流程是否直觀可靠，以及使用者是否能夠無縫存取其角色所需的核心功能。測試應評估使用者撥打和接聽電話、管理保持和恢復功能以及執行盲轉和諮詢轉接的便利程度。此外，還必須確認呼叫轉移、電話會議和其他進階功能（如呼叫保留和恢復或啟用「請勿打擾」功能）是否可用且運作順暢。
應評估使用者體驗的清晰度和回應速度，並考慮使用者如何與通話記錄、語音郵件和整合目錄進行互動。還應特別注意在設備之間轉移通話的功能，以及在應用程式或實體電話上有效使用通話控制功能的功能。最終目標是確保遷移後最終使用者體驗的一致性、高效性，並能充分滿足組織的溝通需求。
呼叫佇列：代理人和主管經驗
呼叫佇列常用於處理大量來電的情況。這裡的驗收測試著重於以下幾個方面。首先，應驗證呼叫是否依照配置的佇列邏輯（例如輪詢、最長空閒或同時振鈴）指派給座席。必須檢查座席桌面上排隊呼叫的顯示方式是否清晰易用，以確保座席能夠有效率地接聽、保持和轉接通話。
對於主管人員來說，應該評估桌面體驗的功能，例如即時監控、呼叫介入以及佇列效能分析或洞察。這包括但不限於驗證提供有關呼叫分配、座席活動和佇列指標的可操作資料的儀表板和報告工具。
搜尋群組：呼叫分配
呼叫群組是將呼叫指派給預定義使用者集的關鍵機制。驗收測試需要確認呼叫是否根據配置的尋呼演算法路由到群組成員，以及是否依照設計處理溢位、轉送和無應答情況。確保群組成員資格和呼叫路由行為與先前建立的行為一致，對於營運一致性和使用者滿意度至關重要。
自動語音應答：公告和選單操作
自動應答器代表了自動呼叫處理的第一道防線。測試必須涵蓋公告的播放、錄製問候語的準確性以及選單樹的正確操作。選單選擇應能可靠地將來電者路由到相應的部門、個人或外部號碼。測試還應包括無效或逾時場景，以確認呼叫者是否收到清晰的指導或按預期被重定向。
語音信箱操作
最後，語音信箱功能對使用者體驗至關重要。驗收測試應驗證語音信箱是否已正確分配，以及是否可以從組織內部和遠端存取。必須確認具備記錄、檢索和管理訊息的功能，以及通知送達功能。
最佳化
PSTN 遷移到 Cloud Connect
一旦所有終端和使用者都遷移到雲端呼叫，Unified CM 的唯一目的就是充當 PSTN 閘道和本地網關之間的傳輸通道。使用 Cloud Connect 作為所有 Webex Calling 用戶的 PSTN 存取方式，從系統中移除 PSTN 網關和本地網關，具有許多優勢，包括降低成本和提高可靠性。若要將本機 PSTN 存取遷移到 Cloud Connect，請依照下列步驟操作：
-
Cloud Connect 用於合作夥伴選擇。
請參閱 Cloud Connect 合作夥伴列表，並從中選擇適用於您組織所在地的合作夥伴。
-
Cloud Connect 用於驗證。
在將 PSTN 存取點切換到 Cloud Connect 之前，應先驗證並確認透過選定的 Cloud Connect 合作夥伴與 PSTN 的連線。為此，需要配置一個測試地點，並在該測試地點配置一些測試使用者。然後，將此測試地點的 PSTN 存取設定為 Cloud Connect 合作夥伴，之後使用測試電話驗證 PSTN 連線。驗證成功後，即可取消測試地點的配置。
-
號碼轉移。
為了準備切換到 Cloud Connect，需要對目前分配給終止於此的 PSTN 中繼線的所有號碼下達連接埠訂單。所有號碼都需要轉移到 Cloud Connect 合作夥伴處。為了保持不同地點之間的可及性，所有地點的所有號碼都需要同時進行攜號轉網。
-
切換到 Cloud Connect 合作夥伴。
在切換之日，所有地點的 PSTN 存取都需要設定為雲端連接 PSTN 供應商，並且應驗證入站和出站連線。
如設計章節的 PSTN 部分所述，客戶也可以選擇在過渡開始時將其 PSTN 接取遷移到 Cloud Connect，以便使用 PSTN 中繼進行混合部署。有關更多信息，請參閱 混合 Webex Calling 部署的 PSTN 中繼。在這種情況下，過渡期間 PSTN 存取是透過本地網關進行的，並且在將所有使用者遷移到本地網關之後，除了停用本地網關之外，沒有其他與 PSTN 相關的遷移步驟。
優化本地基礎設施
一旦所有使用者都已遷移到雲端註冊，並且所有端點都已遷移到雲端註冊（或已停用），現在雲端呼叫正在使用，請更新相應的本地基礎架構。基礎設施更新包括：
-
從本機 DNS 伺服器中刪除本機呼叫控制和訊息 DNS SRV 記錄，包括 cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. 這些 SRV 記錄不再用於客戶端服務發現。
-
從公用 DNS 系統中刪除與邊緣相關的 DNS SRV 記錄，包括 collab_edge._tls.<domain>. 這些 SRV 記錄不再是客戶端發現協作邊緣服務所必需的。
-
更新所有相關的 DHCP 作用域，移除選項 66 和選項 150。 TFTP/boot 伺服器位址。這些作用域不再用於端點呼叫控製配置的發現和下載。
-
Update/remove 本地適當的撥號對等體 Gateway/CUBE 此路由調用與 Unified CM 之間的通訊。這些撥號對等體不再是本地呼叫路由所必需的。
-
刪除或移除所有叢集節點虛擬機 and/or 伺服器. 根據需要重新分配計算資源和硬體。這些資源不再用於呼叫控制和邊緣服務。
-
刪除或移除所有叢集節點虛擬機 and/or 伺服器. 根據需要重新分配計算資源和硬體。語音郵件和統一訊息服務不再需要這些資源。
-
清理：將 PSTN 存取遷移到雲端連接 PSTN 後，可以停用 PSTN 中繼線、PSTN 閘道和本機閘道。
-
對於任何現有的本機 E911 解決方案，刪除已遷移到的任何位置或號碼，並在完全過渡完成後，刪除應用程式虛擬機器或伺服器。根據需要重新分配計算資源和硬體。這些資源不再用於緊急呼叫和定位服務。
-
應將屬於已遷移使用者的 DN 放置在隱藏分區中，以避免呼叫路由失敗，並確保所有 CSS 都能優先存取相同 DN 的雲端路徑。
-
當發生變更時，更新 Horizon Mobility 中的實體可調度位置和網路元素。需要更新的常見活動包括：
-
網路交換器更換
-
無線接入點更換
-
DHCP作用域變更
-
建築物內部的物理變化（如果決定進行） cubical/office)
-
建築物內部辦公空間的實際擴張或收縮。
-
利用分析和故障排除
提供全面的分析和故障排除功能，幫助您視覺化和追蹤部署情況。這些功能包括媒體品質、詳細通話記錄、呼叫佇列、呼叫組和自動應答分析。圖 [] 顯示了媒體品質分析的範例 媒體品質分析。
在故障排除中，可以使用以下信息查看每次呼叫，其中包含有關關鍵媒體品質和信令相關問題的詳細信息，以幫助確定媒體問題以及呼叫失敗的原因，如圖 媒體品質故障排除所示。
故障排除功能還可以與其他思科產品（如 ThousandEyes 和 Meraki 交換器）集成，從而在 Control Hub 中提供更豐富的集成體驗。有關使用 Webex Calling 分析和故障排除的更多信息，請參閱 Control Hub 中的 Webex Calling 通話故障排除。
在開始之前
本指南適用於有設定和管理 Cisco Unified Communications Manager (Unified CM) 和 Cisco 終端機（包括 IP 桌上型電話、視訊設備和 Jabber 軟體用戶端）經驗的團隊或個人。本文檔中提供了指向產品和支援文件的鏈接，以提供協助。
本文檔僅關注從 Unified CM 到 Webex Calling 多租戶的過渡。本文檔中的術語 Webex Calling 始終指 Webex Calling 多租用戶。
在開始從 Unified CM 遷移到 Webex Calling 之前，必須全面了解 Webex Calling 解決方案及其個別元件。成功遷移需要熟悉 Webex Calling 的架構、服務模型、部署選項和相關功能，以便正確對應現有的 Unified CM 工作負載並設計有效的過渡計畫。
要製定有效的過渡策略和營運準備，必須透徹了解以下 Webex Calling 元件。
-
Control Hub
-
目錄和使用者配置
-
Webex通話平台
-
支援的呼叫端點
-
PSTN 連線選項
-
Webex Calling撥號方案和號碼管理
-
安全性和合規性功能。
更多信息，請參閱 Cisco Webex Calling 首選架構。
本指南將重點放在轉型生命週期中可使用的工具和流程。然而，從本地通話系統 Unified CM 過渡到新的雲端通話平台 Webex Calling 可能是一項重大工程，並可能面臨業務、技術和複雜方面的挑戰。為了幫助您克服這些挑戰，思科提供了一些不同的選擇來協助您完成您的轉型之旅。請務必查看 企業雲端呼叫 - 呼叫遷移 中的信息，以了解每個選項以及每個選項如何幫助您進行自己的遷移。
-
Webex遷移工具： Control Hub 內建了自助式免費工具，可簡化您向 Webex Calling 的轉型。
-
認證的移民服務提供者： Cisco 已驗證了開發遷移解決方案的軟體和工具供應商，這些解決方案可協助 Webex 合作夥伴和客戶進行複雜和大規模的遷移。這些解決方案可以幫助簡化、管理和加速向 Webex Calling 的過渡。
-
Webex 設定助手： 思科主導的遷移服務，指導客戶和合作夥伴完成 Webex Calling 的部署和配置，這是將 Unified CM 使用者和服務成功遷移到 Webex Calling 所必需的。
概覽
隨著雲端交付協作服務的成長，越來越多的客戶希望將現有的協作工作負載遷移到雲端，因為雲端服務具有降低整體擁有成本、簡化管理、持續功能交付、提高規模和增強可靠性等優點。當客戶考慮從本地部署過渡到雲端協作服務時，了解過渡過程涉及哪些方面以及過渡所需的步驟至關重要。
本文檔的目的是為希望從本地統一 CM 過渡到雲端 Webex Calling 的客戶提供部署指導。本部署指南假定讀者對 Unified CM 和 Webex Calling 之間的呼叫轉換有基本的了解，包括進行此轉換時會發生哪些變化，以及將呼叫工作負載從本地遷移到雲端時會有哪些不同。在繼續操作之前，請確保您已查看並熟悉 過渡圖中提供的資訊。這份過渡路線圖文件提供了有關此次過渡期間的變化和差異的資訊。
如圖 所示，本地協作架構：呼叫控制和遠端存取，典型的本地部署包括網路上的不同協作基礎架構元件、呼叫控制平台、邊緣平台、硬體和軟體終端，在某些情況下甚至包括會議和日程安排平台。在思科架構中，這包括用於呼叫控制的統一呼叫管理 (Unified CM)、用於遠端存取和企業對企業 (B2B) 邊緣服務的 Expressway 以及思科會議伺服器 (Cisco Meeting Server)。 / Cisco Meeting Management 用於本地會議，Unity Connection 用於語音訊息傳遞，以及面向使用者的硬體（Cisco IP 電話、Cisco 桌面和會議室視訊系統）和軟體（Cisco Jabber）基於 IP 的終端。這些元件在某些環境中可能會略有不同，但這是本文檔其餘部分所描述的過渡的起點。
圖 所示的架構為本地協作架構：呼叫控制和遠端存取 基於 Cisco Collaboration Enterprise 本地部署的首選架構 (PA)。有關企業本地部署的更多信息，請參閱 Cisco 協作首選架構。
之前：本機呼叫基礎架構元件 表列出了在過渡到雲端 Webex Calling 之前本地架構的關鍵要素。
| 產品 | 說明 |
|---|---|
| Unified CM | 本地呼叫控制提供設備註冊和呼叫路由服務 |
| 思科 Expressway-C/E | 邊緣基礎設施提供行動和遠端存取 (MRA) 以及企業對企業 (B2B) 功能，使遠端端點能夠從組織外部安全連接。Expressway 成對部署，提供外部端點防火牆穿透功能。 |
| Cisco Meeting Server (CMS)、Cisco Meeting Management (CMM) 和 Cisco Telepresence Management Suite (TMS) | 提供本地語音、視訊和網路會議基礎設施，支援多點會議、會議管理和日程安排功能。[Optional] |
| Cisco Unity Connection | 提供語音郵件和統一訊息功能的本地語音訊息平台。[Optional] |
| Cisco Desk、Cisco Room、Cisco Board、Cisco IP Phones 與 Cisco Jabber | 已註冊到 Unified CM 並提供語音和視訊通話功能的基於 IP 的設備 |
如圖 所示，過渡決策：對於擁有 Unified CM 和桌面及視訊 IP 端點的本機呼叫控制的客戶，他們可以選擇將架構過渡到 Webex Calling雲端架構。
該決定需要根據客戶的功能需求來做出。有以下需求的客戶在做出決定前應仔細考慮，並最終可能決定將呼叫控制保留在本地：
- Webex Calling 不支援的手機型號
- 與其他本地系統或解決方案的複雜或眾多集成，尤其是在難以用 Webex Calling 複製這些集成，或沒有等效替代解決方案的情況下，會非常棘手。
- 複雜的撥號方案、高度細化的服務等級或兩者兼有
- 受限、有限或不可靠的網路存取
- 嚴格的資料隱私和所有權政策
- 本地或境內媒體錄製和儲存的合規性要求
- 第三方集成，但沒有可行的替代 Webex Calling 集成方案
- 聯絡中心集成，其中聯絡中心集成尚未遷移到雲端。
本文檔主要針對已部署 Unified CM 呼叫控制的客戶，旨在協助他們了解啟用 Webex Calling 部署的一般步驟、注意事項和要求，如下一節所述。
核心組件
此次遷移的目標架構包含多個新元件。這包括用於基於雲端的通話的 Webex Calling 服務、Webex App、用於身分整合的 Cisco Directory Connector 和用於 PSTN 存取的本地網關 (LGW)，以及本地到雲端的通話整合。Cisco 通話計畫或由 Cloud Connect for Webex Calling 合作夥伴提供的雲端連線 PSTN (CCP) 是 PSTN 存取的其他選擇。
如圖 所示，之後：Webex Calling 架構，新元件（Webex Calling、目錄連接器、本機閘道和生存能力閘道）會被加入到現有的本機部署。
之後：雲端呼叫基礎設施元件 表列出了過渡到 Webex 後架構的新元素。
| 產品 | 說明 |
|---|---|
| Webex Calling | 基於 Webex 平台的雲端通話服務，提供終端機註冊和呼叫路由功能。 |
| Cisco 目錄連接器 | 執行在 Windows 網域電腦上的 Windows 應用程序，提供企業本機 Active Directory 和 Webex 組織的身份儲存之間的身份同步。 對於從本機 Active Directory 遷移到 Entra ID 的客戶，與 Webex 而不是 Cisco Directory Connector 的身分整合使用 Entra ID Wizard 應用程式。 |
| 本端閘道 | 本地網關可作為客戶本地統一通訊網路和 Webex Calling 雲端之間的橋樑。它可以部署在本地或由合作夥伴託管，為雲端註冊端點提供 PSTN 訪問，以及 Unified CM 註冊端點和雲端註冊端點之間的呼叫整合。Cisco IOS-XE 整合服務路由器（ISR 1100 與 4000 系列）、Cisco Catalyst 8200/8300 Cisco Catalyst 8000V Edge 軟體系列以及各種經過認證的第三方會話邊界控制器 (SBC) 可用作分階段遷移方法的 LGW。 |
| 生存能力閘道 | 生存網關 (SGW) 是一個基於本機網路 IOS-XE 的網關，可在網路中斷期間為現場 Webex Calling 端點提供回退呼叫服務。 |
| Cisco 通話計劃，Webex 通話雲端連接 | Cisco Calling Plan 和 Cloud Connect for Webex Calling 是 Webex Calling 端點的基於雲端的 PSTN 存取選項。PSTN 存取由雲端 PSTN 供應商提供，無需任何本地設備。 |
| Webex 應用程式 | 用戶端應用程式運行於桌面作業系統（Windows、Mac）或行動作業系統（Android、iOS）上，並直接註冊到 Webex Calling 平台以實現通話功能。 |
PPDIO流程概述
PPDIO 流程代表 準備、規劃、設計、實施和最佳化。這是思科提供的結構化方法論，指導專案從初步評估到持續改進，確保高效、成功的部署或遷移。
PPDIO概述
-
準備： 評估當前環境，收集需求，並協調利益相關者，以建立堅實的基礎。
-
方案： 制定詳細的專案計劃，包括時間表、資源和風險緩解策略。
-
設計： 根據業務和技術需求，設計目標解決方案。
-
實施： 根據設計執行部署或遷移，並驗證功能和效能。
-
最佳化: 實施後，透過監控效能、改進配置以及利用自動化和整合工具，不斷改進解決方案。
使用 PPDIO 進行 Unified CM 到 Webex Calling 的遷移項目
從 Unified CM 過渡到 Webex Calling 時，PPDIO 流程提供了清晰的路線圖，以確保平穩高效的過渡：
準備
-
評估現有的統一配置管理環境和遷移準備情況
-
收集有關使用者、裝置、網路和依賴關係的詳細數據
-
收集位置詳細信息，包括緊急響應地址、用戶數量、互聯網接入情況、公共交換電話網路接入情況
-
識別風險並明確專案範圍，以協調所有利害關係人。
方案
-
制定包含批次計畫、資源分配和時間表的全面遷移計畫。
-
定義諸如設備韌體升級、許可證配置和用戶入職等任務
-
與思科及合作夥伴協調遷移時間，以最大程度地減少中斷。
設計
-
將目前 Unified CM 設定、撥號方案和使用者設定檔對應到 Webex Calling 的對應項
-
設計 Webex Calling 環境，包括 PSTN 策略（臨時和最終方案）、位置、使用者角色以及整合點，例如本地網關 (CUBE) 和目錄同步。
-
制定在遷移過程中 Unified CM 和 Webex Calling 同時運作的共存方案。
執行
-
使用 Control Hub 遷移工具以及第三方工具來執行裝置韌體模式變更、功能配置和使用者遷移。
-
利用 Webex API 進行批量操作和配置，以簡化大規模遷移和配置。
-
執行許可證配置、設備註冊和配置更新
-
透過測試和運行驗證來確認遷移是否成功。
最佳化
-
持續監控 Webex Calling 的效能與使用者體驗
-
根據營運數據和回饋改進配置和工作流程
-
利用自動化和整合功能來提高效率和可擴展性
-
根據需要停用舊版統一配置管理元件，並為日常營運提供持續支援。
這種增強型 PPDIO 方法可確保從 Unified CM 到 Webex Calling 的可控、透明和高效遷移，利用 Cisco 的工具、API 和合作夥伴生態系統來維持業務連續性並提高協作能力。
PPDIO回饋迴路
圖 中所示的高階概述在執行 PPDIO 時進行了迭代，展示了從 優化 階段到 準備 階段的單一回饋迴路。這意味著，在初步實施之後，仍有持續改進的機會。每次優化週期都可以發現新的需求或需要改進的領域，這些需求或領域可以透過後續的專案或計劃來解決。這些單獨的專案又各自遵循既定的 PPDIO（準備、規劃、設計、實施、最佳化）生命週期。這種迭代方法確保系統始終與不斷變化的業務目標和技術進步保持一致，從而培養持續改進和適應的文化。
在 PPDIO 流程的執行過程中，後期階段的調查結果通常需要重新審視並可能修改早期階段所做的決定。例如，在實施階段遇到的問題，例如發現設計歧義或缺失的細節，可能會揭示某些方面在設計階段沒有充分解決。在這種情況下，必須回到相關的先前階段來解決這些問題，然後再繼續進行。如圖 所示，統一配置管理輔助 PPDIO 流程 中的這種迭代反饋機制確保解決方案得到徹底驗證和完善，最終有助於實現更穩健、更有效的部署。
從 Unified CM 過渡到 Webex Calling 時，PPDIO 流程的每個階段都可以從現有 Unified CM 環境中收集的資訊中獲益匪淺。例如，可以從目前的統一 CM 配置中提取使用者、電話號碼、呼叫功能和撥號計劃組件的全面清單。這些數據是對利害關係人直接提供的資訊的補充，有助於簡化規劃和設計活動。利用合適的工具實現資料擷取和分析的自動化，不僅可以提高準確性，還可以加快整個流程。透過利用現有部署的洞察，向 Webex Calling 的過渡可以比傳統的全新實施更有效率地執行，同時仍遵循結構化的 PPDIO 方法。過程如圖 統一 CM 輔助 PPDIO 過程所示。
遷移方法
在規劃從本地統一內容管理過渡到 Webex Calling 時，您需要確定如何著手進行此過渡過程。首先，您需要決定遷移方式是採用 閃速 （一次全部遷移）還是 分階段 （分批遷移） users/devices 在較長一段時間內）。
執行 快速 遷移可以最快遷移所有使用者和裝置。透過此方法，您可以同時將所有使用者和裝置從本機 Unified CM 遷移到 Webex Calling。從本質上講，它為所有用戶和設備提供了一個統一的遷移視窗。遷移完成後，您的所有使用者和裝置都會遷移到 Webex Calling 平台，並且您的所有 Unified CM 基礎架構都可以停用。然而，由於呼叫部署的規模和範圍，許多組織無法採用這種方法。
第二種方法是 分階段 遷移。大多數組織都會採用這種方法，因為它能更好地控制、管理和擴展遷移規模。此外，它也更適合大規模統一通訊部署。 and/or 跨多個區域部署。因此，本文檔重點介紹 分階段實施的過渡方法 ，該方法包含兩個過渡步驟。
如圖所示 分階段呼叫轉換：混合雲，第一個過渡階段（階段 1）將實現具有雙重呼叫環境的共存部署。在此階段，部分使用者、裝置和軟體用戶端將過渡到 Webex Calling，而其他使用者、裝置和軟體用戶端仍將使用本機 Unified CM 呼叫控制。最終過渡階段（第二階段）將形成一個純粹的雲端通話環境，其中所有使用者、裝置和軟體用戶端都已完全過渡到 Webex Calling 平台。
組織完全過渡到雲端呼叫所需的時間取決於其目前的部署情況。在某些情況下，組織可能會進行初步過渡，並在共存雙呼叫控制階段（階段 1）保持較長時間（數月甚至數年），而在其他情況下，組織可能會在很短的時間內（數週或數月）完全過渡到 Webex Calling（階段 2）。本文檔旨在涵蓋兩個階段（第一階段－共存，第二階段－完全過渡）。
有些組織可能會無限期地維持雙重呼叫控制共存部署，而沒有計劃完全過渡到雲端呼叫。
第二個需要考慮的問題是如何將使用者、裝置和軟體客戶端從本地呼叫控制過渡到雲端呼叫控制。建議採用三階段過渡方案。下圖 建議的 3 階段轉變 將此方法分解為 3 個階段。
遷移前： 此階段的重點是為遷移做好 Webex 和 Unified CM 環境的準備。這不是關於具體的規劃或配置，而是專注於完成現在可以在任何 Webex Calling 遷移專案開始之前完成的活動。目標是為兩個環境的遷移奠定基礎。
移民準備： 在這個階段，我們將開始為遷移到 Webex Calling 做準備。此處需要審查和更新業務和技術需求。不要只是簡單地將目前使用 Unified CM 部署的內容進行 遷移 ，而是利用 Webex Calling 的強大功能，重新定義貴公司現在和將來所需的業務和技術要求。此外，在這個階段，您將完成設計、配置規劃和遷移。 planning/schedule.
遷移（部署和停用）： 在這個階段，用戶、裝置、電話號碼和軟體客戶端將實際遷移。如上所述，此階段可以一次完成（閃切），也可以分多個變更視窗完成（分階段切割）。最終用戶採納計劃、培訓和溝通至關重要，這樣您的用戶才能了解變化、如何使用新的通話平台以及何時進行更改。最後一步是停用所有不再使用的本地統一通訊基礎設施。
遷移前階段包含一些活動（必需的、建議的和可選的），您可以立即開始進行這些活動。建議儘早完成這些工作，最好是在專案開始之前完成。有些活動可能需要更長時間才能完成，因此儘早開始這些活動將有助於簡化您的實際遷移專案。
下圖 遷移前活動 突顯了與 Webex Calling 遷移相關的五類具體活動。
準備
業務和技術要求
在計劃從 遷移到 時，在計劃階段徹底收集技術和業務需求至關重要。這一步驟確保遷移與貴組織的營運目標和技術能力保持一致，從而最大限度地降低風險和中斷。
為什麼收集需求很重要：
-
使業務目標保持一致： 了解業務需求有助於客製化遷移方案，以支援關鍵工作流程、使用者體驗和成長計畫。
-
確保技術相容性： 儘早確定技術需求可以避免與現有基礎設施、網路和終端機出現整合問題。
-
有助於資源規劃： 明確的需求有助於準確估算時間、成本和所需資源。
-
降低風險： 及早發現潛在問題可以採取積極主動的解決方案，從而減少停機時間和業務中斷。
業務需求
典型的業務需求包括：
-
待遷移的使用者數量和位置
-
所需功能和服務（例如：呼叫路由、語音信箱、電話會議、自動應答、呼叫佇列）
-
合規和安全政策
-
預算限制和成本預期
-
使用者培訓和支援需求
-
遷移時間表和業務連續性注意事項。
收集所需的功能和 服務是確保新系統滿足業務需求的關鍵步驟。在收集這些需求時，不僅要考慮目前配置的內容，還要嘗試從將要使用該系統的業務實體收集實際需求。否則，該計劃可能基於過時的假設。務必評估 中提供的其他或增強功能，這些功能在 中可能不存在，例如基於雲端的呼叫、進階呼叫佇列、 和 。這有助於充分利用雲端平台的優勢。
在評估目前配置時，必須認識到，由於系統生命週期中需求的不斷變化，並非所有現有設定都仍然是必要的。重點應該放在識別和保留那些符合當前和未來部署需求的配置。
多關注你需要什麼，而不是你擁有什麼。
在從遷移到 Webex Calling 的過程中，合規性和安全策略是至關重要的考慮因素 ，以確保新的基於雲端的通訊系統符合法律、監管和組織標準。
-
監理合規性： 組織必須驗證其是否符合行業特定法規，例如 GDPR、HIPAA 或 SOX，這些法規涉及資料隱私、保留和處理的要求，以及與資料駐留、收費繞行和媒體本地化相關的國家/地區特定規定。
-
資料安全： 確保語音和訊號資料在傳輸和儲存過程中均進行加密，以防止被攔截或未經授權的存取。
-
存取控制： 定義並實施使用者身分驗證、授權和基於角色的存取控制，以防止未經授權使用通訊資源。
-
審計和監控： 實施日誌記錄和監控功能，以追蹤存取和使用情況，用於合規性稽核和安全事件調查。
-
政策一致性： 使遷移與現有的企業安全策略保持一致，包括終端安全、網路分段和事件回應計畫。
-
供應商安全保障： 評估思科的安全認證和合規性證明，以確保其可信度。
在規劃階段解決這些合規和安全策略有助於降低風險、避免法律處罰，並在整個遷移過程中以及遷移後維護通訊的完整性和保密性。
使用者培訓和支援需求 是從到遷移過程中確保平穩過渡和使用者採納的重要組成部分。主要考慮因素包括：
-
培訓項目： 為不同的使用者群體（最終使用者、管理員、服務台人員）制定客製化的培訓課程，使他們熟悉各項功能、使用者介面和新的工作流程。
-
文件： 提供清晰易懂的使用者指南、常見問題解答和快速參考資料，包括 新增功能和不同之處 資源以及逐步 遷移前後 操作指南（影片或快速指南格式），以幫助使用者適應遷移後的更新體驗。
-
變更管理： 主動溝通變更，以管理使用者預期並減少阻力。
-
支撐結構： 建立專門的支援團隊或升級途徑，以便在遷移期間和遷移後及時解決用戶問題。
-
繼續教育： 隨著新功能或更新的發布，制定持續培訓更新計劃。
-
回饋機制： 建立使用者回報問題和提供回饋的管道，以改善培訓和支援流程。
在規劃階段解決這些培訓和支援需求有助於最大限度地減少干擾，增強使用者信心，並最大限度地發揮遷移到新系統的好處。
技術要求
為了成功從 [系統名稱] 遷移到 [系統名稱]，需要收集並記錄幾個關鍵的技術要求，包括以下方面的詳細資訊：
-
網路就緒性和頻寬容量
進行全面的網路評估至關重要，以確保您現有的基礎架構能夠支援新的 Webex Calling 環境。這些調整包括：
-
頻寬分析： 評估目前和預期的頻寬使用情況，以處理語音、視訊和資料流量而不會出現擁塞。
-
服務品質（QoS）： 實施 QoS 策略，優先處理語音流量，最大限度地減少延遲、抖動和丟包。
-
廣域網路和網際網路連線： 驗證廣域網路鏈路和網際網路連線是否符合基於雲端的呼叫的要求，包括冗餘和故障轉移功能。
-
防火牆和NAT配置： 確保防火牆和 NAT 設定允許所需的訊號和媒體流量。
-
-
與現有系統集成
與現有業務系統無縫整合對於使用者體驗和工作流程的連續性至關重要：
-
目錄服務： 評估與企業目錄的集成，以實現使用者自動配置和身份驗證。
-
客戶關係管理與業務應用： 確定與客戶關係管理系統和其他業務關鍵應用程式的整合點。
-
傳統PBX互通： 若過渡期間仍需保留任何傳統電話系統，則需制定共存或分階段遷移策略。
-
-
端點相容性和配置
應評估所有終端設備（包括桌上型電話、軟體電話和行動裝置）的相容性：
-
設備支援： 確認現有 IP 電話和設備是否受支持，或確定需要更換的設備。
-
配置流程： 建立自動化或簡化的配置方法，以有效率地完成終端設備的存取。
-
韌體和軟體更新： 制定必要的更新計劃，以確保互通性和安全性。
-
-
安全配置和加密標準
在雲端通訊中，安全性至關重要：
-
加密： 依照思科安全最佳實踐，對訊號和媒體流強制執行端對端加密。
-
身份驗證和存取控制： 實施安全身份驗證機制（例如 SSO、多因素身份驗證）和細粒度的使用者存取控制。
-
遵守： 確保解決方案符合相關的監管和行業合規標準（例如 GDPR、HIPAA）。
-
安全監控： 與 SIEM 工具集成，並設定潛在安全事件警報。
-
| 需求 | 關鍵考慮因素 |
|---|---|
| 網路就緒性和頻寬 | 頻寬、服務品質、 WAN/Internet, Firewall/NAT |
| 與現有系統的集成 | 目錄、CRM、PBX、 Email/Calendar |
| 端點相容性和配置 | 設備支援、配置、韌體更新 |
| 安全性配置和加密 | 加密、身份驗證、合規性、安全監控 |
| 使用者培訓和變更管理 | 培訓計畫、文件、變更溝通 |
| 號碼可攜性和撥號方案 | 數位 migration/porting, 撥號方案翻譯 |
| 第三方集成 | 呼叫器、呼叫中心、傳真機、類比設備 |
網路就緒性與要求
網路就緒對於成功遷移到任何基於雲端的通話解決方案（例如 ）至關重要。網路規劃不善會導致通話品質下降、斷線，以及用戶不滿。客戶在遷移到新系統之前需要進行網路評估。建議確認網路頻寬是否足以滿足預期的通話量，確保滿足服務品質 (QoS) 要求，並了解必須在邊緣防火牆中開啟的各種連接埠。
可靠的網路連線以及足夠的服務品質（頻寬、丟包率、RTT）是確保所有支援語音和視訊的終端、用戶端和應用程式獲得最佳端對端用戶體驗的基本要求。
客戶和合作夥伴除了可以透過 OTT 網路連接外，還可以使用其他連接方式來優化連接，例如 Webex Edge Connect。有關 Webex Edge Connect 設計詳情的更多信息，請參閱 Cisco 推薦的 Webex Edge Connect 架構，適用於 Webex Meetings、呼叫多租戶和專用實例。
客戶可以使用 CScan 進行網路評估，該評估提供有關客戶網路品質、可建立的通話數量、延遲等資訊。有關 CScan 工具的更多信息，請參閱 使用 CScan 測試 Webex Calling 網路品質。
為確保網路已做好遷移準備，請參考以下清單：
-
頻寬規劃
計算每個網站的並發呼叫數，以確保您有足夠的上行和下行頻寬，並為其他業務關鍵流量和未來成長預留餘裕。
Webex Calling 呼叫類型頻寬計算 表顯示了部署中可用的呼叫類型，以及每種呼叫類型所需的編解碼器和最大頻寬。如 Webex Calling 通話類型頻寬計算 表所示，可以使用以下通用公式計算每種通話類型所需的音訊通話頻寬：
預期並發呼叫次數 * 基於編解碼器的每次呼叫頻寬 = 所需網路吞吐量。
表格 2. Webex Calling 通話類型頻寬計算 呼叫類型 編解碼器 - 頻寬 頻寬計算 / 桌上型電話 -> OPUS - 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 / 桌上型電話 -> 桌上型電話 OPUS – 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 / 桌上型電話 -> 透過LGW的PSTN G.711 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 透過雲端 PSTN 進行 PSTN 通訊（例如 Cisco 通話套餐） G.711 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 企業透過LGW G.722 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 語音信箱 OPUS – 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 透過對每種通話類型所需的並發網路吞吐量進行求和，可以確定特定站點的總潛在頻寬需求。
所有呼叫線路始終錨定在接取 SBC 上。要確定任何給定位置所需的互聯網頻寬，不僅需要考慮位置間的呼叫，還需要考慮位置內的呼叫以及與該位置的本地網關之間的呼叫。例如，兩部 MPP 電話之間的站點內通話需要該站點互聯網接入提供高達 2 x 70 kbps 的全雙工頻寬。
Webex Calling 頻寬計算範例 表格顯示了一個完整的頻寬計算範例，假設所有裝置都在同一網站。
表格 3. Webex Calling 頻寬計算範例 呼叫類型 並發呼叫次數 總頻寬 Webex 應用 / 桌上型電話 → Webex 應用 15 2 * 15 * 70 kbps = 2100 kbps Webex 應用 / 桌上型電話 → 桌上型電話 15 2 * 15 * 70 kbps = 2100 kbps Webex 應用 / 桌面電話 → 透過LGW接入PSTN 50 2 * 50 * 80 千秒 = 8,000 千秒 Webex 應用 / 桌上型電話 → 透過 Cloud Connect 進行 Webex 通話的 PSTN 0 0 * 80 Kbps Webex 應用 / 桌上型電話 → 透過 LGW 的企業 15 2 * 15 * 80 kbps = 2400 kbps Webex 應用 / 桌上型電話 → Webex 通話語音信箱 5 5 * 70 千秒 = 350 千秒 總通話次數 / 頻寬 100通電話 14,950 kbps / 14.95 Mbps -
上表中所有頻寬值均指 IP 頻寬。鏈路頻寬取決於廣域網路封裝方式。
-
以上表格中的頻寬指的是音訊通話的頻寬。視訊通話頻寬方面，Webex 應用程式和 MPP 均適用。 8845/65 手機支援 H.264 視頻，最高解析度為 720p，每次通話最大頻寬為 1,500 kbps。然而，通話期間任何時刻消耗的頻寬量都會根據視訊通訊固有的可變位元率而波動。
-
-
服務品質 (QoS)
在本地環境中實施 QoS 策略，以優先處理即時流量，並確保在交換器、路由器和防火牆之間保持 QoS。
-
延遲、抖動和丟包目標
以下閾值建議用於在透過網路進行OTT通話時獲得最佳語音品質：
-
單向延遲小於100毫秒
-
抖動小於 10 毫秒
-
丟包率 - 0.5% 或更低。
-
-
防火牆和NAT
確保防火牆已配置為允許流量，如 Webex Calling 連接埠參考資訊所述。此外，允許存取同一指南中列出的網域和 IP 範圍，並避免使用 SIP ALG，因為它會幹擾 SIP 訊號。應避免透過代理伺服器進行媒體流量傳輸。
-
DNS 和 NTP
確保網域名稱解析正確，並使用可靠的 NTP 伺服器同步設備時鐘，以進行 TLS 憑證驗證和日誌記錄。
-
故障轉移計劃
考慮現有提供者資料連線（MPLS、SD-WAN 等），並規劃在部署中的每個位置直接連接到網際網路。在需要高可用性的場景下，應規劃冗餘的網路連結。由於您將使用基於雲端的服務，因此可靠的網路連線和足夠的頻寬是基本要求。如果您的組織場所的網路連線通常不夠可靠，延遲不夠低，上下行吞吐量也不夠，那麼您應該重新考慮進行這種轉換。
-
場地存活率
網站生存能力確保即使網路連線中斷，您的業務也能隨時可存取。站點生存能力利用本地網路中的網關，在網路連線中斷的情況下，為現場端點提供回退呼叫服務。如果業務需求要求在網路中斷時仍能持續呼叫，請考慮使用本地生存網關 (SGW) 來提高站點生存能力。有關站點生存能力檢查的更多信息，請參閱 Webex Calling 的站點生存能力。
設定雲端連接的統一通信
Cloud Connected UC (CCUC) 是一種基於雲端的管理和分析解決方案，旨在為本地部署（如 Unified CM）和雲端部署提供集中式的可見性、管理和洞察。它充當傳統本地環境和思科雲端服務之間的橋樑，為組織從本地遷移到雲端的整個過程提供支援。
在向統一通訊系統過渡的過程中，CCUC 透過促進從現有統一通訊部署中收集全面數據，在簡化遷移過程中發揮至關重要的作用。CCUC 可協助完成關鍵的過渡任務，例如遷移裝置、功能和使用者聯絡人，以及自動更新支援的 IP 電話的韌體。CCUC 透過提供集中式的視覺性和管理，協助確保更順暢、更有效率的遷移體驗。
Cisco 強烈建議在過渡專案的早期階段部署 CCUC，理想情況下是在準備階段之前或期間部署。這將使您能夠獲得所需的洞察力和能力，從而徹底評估、清點和規劃後續的遷移活動，並開啟您邁向未來混合能力的旅程。
評估當前環境
遷移計畫中的關鍵活動是評估目前的本地環境和部署情況。這有助於我們了解成功過渡到新階段可能需要哪些潛在改變。它還允許您將平台的關鍵要素與現有的本地部署進行比較。您可以利用這些資訊來幫助確定過渡期間所需的特定任務，以及為了滿足您的業務和技術要求及用例，您希望做出哪些更改。
作為這項工作的一部分，以下幾個方面需要重點審查。
授權
了解現有部署的目前許可結構是準備遷移到新部署的關鍵。對您現有的 Cisco 本機部署解決方案的下列事項進行授權評估。
-
平台
在與客戶團隊或合作夥伴共同確定靈活授權的最佳方案時，能夠清楚闡述您核心平台上目前已授權的內容至關重要。有關靈活許可的更多信息，請參閱 Cisco 協作靈活計劃。
-
使用者和設備
確定您現有使用者和裝置需要哪種授權類別。這將用於確定使用者和設備所需的許可證類型。提供多種許可證類型，包括使用者的專業版和標準版許可證，以及針對工作區的專業版和公共區域版授權。有關設備許可的更多信息，請參閱 設備許可中的數據表。
-
本機閘道
如果此次過渡需要 Cisco Unified Border Element (CUBE) 來實現 PSTN 接入，則還必須考慮 CUBE 許可。CUBE 許可方面的注意事項將在本文檔後面部分介紹。
Locations/Sites
在規劃此過渡時，應考慮現有部署中的站點數量和類型（大型中央站點、區域站點、分公司等）。充分了解現有部署站點將有助於制定策略計劃，以實現成功的過渡，尤其是在確定要遷移哪些站點以及遷移順序方面。詳細了解每個網站的撥接方案需求（號碼、撥接習慣、限制類別等）、網站網路連線和頻寬（網際網路、廣域網路、區域網路）以及 PSTN 接取（本地或集中式、IP 或 TDM）對於制定遷移決策至關重要。有關常見部署模型和關鍵考慮因素的更多信息，請參閱 Collaboration SRND中提供的協作部署模型資訊。
當遷移到新平台時，另一個重要的部署考慮因素是位置可用性。根據部署位置的不同，可用的功能、訂閱和設備也會有所不同。有關地理位置可用性的更多信息，請參閱 Webex 在哪裡可用？。
最後，了解過渡到新系統對其他協作服務的影響也很重要。根據本文檔的目標，一般假設是，如果要維護呼叫工作負載之外的現有協作服務，則需要過渡到上面提到的第 1 階段混合部署。可能需要混合部署的協作服務範例包括尚未遷移到 Webex 聯繫中心的本地聯絡中心，以及與尋呼系統和計費系統等系統的緊密整合。有關其他協作工作負載和服務的過渡的更多信息，請參閱 協作過渡。
現有庫存 devices/clients
在開始過渡之前，清點您現有的硬體和軟體終端非常重要。擁有完整的設備清單 types/models, 硬體版本、軟體用戶端作業系統類型和數量將確保您能夠充分規劃設備的過渡，並減輕那些無法遷移到雲端通話的裝置的影響。應利用庫存清單確定過渡期間需要過渡的設備以及過渡前需要更換的設備。
桌上型電話
僅支援 6800、7800、8800 和 9800 系列音訊和視訊桌面電話。這是受支援的 Cisco IP 電話的子集。6800、7800 和 8800 系列手機的某些型號和版本不能與 . 有關支援哪些型號和硬體版本的更多信息，請參閱 Webex Calling 支援的設備。
Cisco 6800 系列 IP 電話無法從企業韌體升級至多平台 (MPP) 韌體，而多平台 (MPP) 韌體是必要的。因此，任何註冊運行企業韌體的 6800 電話都必須更換為 6800 MPP 型號或其他受支援的電話型號。
Cisco 7800 和 8800 系列 IP 電話必須先升級到多平台電話 (MPP) 固件，然後才能進行過渡並註冊。若要確定哪些 7800 和 8800 型號和硬體版本支援 MPP 韌體，請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
8845、8865 和 8865NR 已停止銷售，不建議遷移。
不建議將較舊版本的 8800 系列電話（8811、8841、8851、8851NR、8861）與 Webex Calling 搭配使用。硬體版本為 VID 14 或更早的手機可以註冊，但由於硬體原因可能會出現一些效能問題。
9800 系列桌上型電話運行 PhoneOS，支援註冊和登入。因此，這些手機無需韌體升級即可進行過渡。
所有其他 IP 電話都需要更換為 Webex Calling 支援的 6800、7800、8800 或 9800 系列電話。有關支援的 IP 和桌面電話的更多信息，請參閱 文章 Webex Calling 支援的設備。
視訊終端
個人和會議室視訊終端，包括 Cisco Board 系列、Room 系列和 Desk 系列，可原生註冊到 SIP。任何需要發出音訊的端點 and/or PSTN 呼叫需要呼叫許可證：
-
會議室、小型討論空間等處的共享設備需要專業工作區或工作區授權。
-
終端使用者的個人設備需要專業版或標準版授權。
確定有多少個視訊終端已註冊並用於進行音訊通話。某些視訊終端可能僅用於加入會議或進行 SIP 視訊通話。無論哪種情況，終端設備仍需在伺服器停用之前進行遷移，但這將有助於確定其中有多少設備需要許可證才能繼續撥打電話。
-
當視訊設備從本機註冊遷移到雲端註冊時，這些端點的 URI 將會發生變化，因為它們現在是在雲端註冊的。
-
8845、8865 和 8875 型號的電話是支援的個人視訊電話。
軟體客戶端
這是唯一支援的軟體用戶端，與同時支援 Webex App 和 Jabber 的 Unified CM 不同，並且是最終用戶的新預設軟體用戶端。
根據 Jabber 所實施的部署模式（僅限即時通訊、僅限電話、 and/or （完整的 UC 模式），您可能還需要考慮訊息傳遞的過渡。 and/or 將 Jabber 中的會議工作負載轉移到 . 如果僅用作通話用戶端，則可部署為 僅電話模式 ；如果還需處理其他工作負載，例如 Webex Messaging，則可部署為 完整的 Webex 套件 。 and/or Webex Meetings 正在過渡到具有通話功能的應用程式。
它透過提供人工智慧功能來增強最終用戶體驗，例如 audio/video 情報、通話轉錄等。如需相關資訊，請參閱 。https://www.webex.com/all-new-webex
在將使用者遷移到新系統之前，您需要將他們的 Jabber 用戶端遷移到新系統。完成此次過渡有兩種選擇。
-
在將它們過渡到
-
當你將它們過渡到.
為了方便使用者首次過渡到新系統，建議使用選項 1，並先呼叫該選項將使用者遷移到新系統。這樣一來，用戶就有時間熟悉新的應用程序，同時他們仍然可以繼續使用現有的本地呼叫平台。準備好將用戶遷移到雲端後，您需要設定他們的裝置以在雲端呼叫平台上註冊。
有關這兩個選項的更多信息，請參閱 遷移之旅 - 一步還是兩步？。
有關 Webex Calling 支援的設備的完整列表，請參閱 Webex Calling 支援的設備。
驗證設備資格
如前所述，它支援部分思科 IP 電話，並且 7800 和 8800 系列電話需要不同的韌體類型。Unified CM 電話運行企業韌體，而 Phones 則運行多平台電話 (MPP) 韌體。建議在準備階段確認哪些已註冊的手機符合升級到 MPP 韌體的條件。這樣您就有時間將不符合條件的手機更換為支援的手機型號之一，或者確定替代方案，例如將用戶遷移到僅 Webex 應用程式。
為了協助確定電話的資格，Control Hub 內建了一個名為 「將您的電話遷移到 Webex Calling」的工具。使用此工具檢查裝置資格時，選擇移轉選項 僅產生裝置授權。
此選項可讓您上傳包含電話號碼的 CSV 文件，以便檢查每部電話號碼的資格。選擇此遷移選項後，由於您仍處於準備階段，尚未準備好執行此操作，因此不會將手機新增至遷移清單。如需相關資訊，請參閱將電話移轉至Webex Calling 。
部分手機可能顯示 未知 資格。這通常是因為無法在後端系統中驗證有關手機的某些資訊。對於任何狀態為 未知 的手機，您有兩種方法可以驗證它們是否符合升級到 MPP 韌體的條件。
-
手動檢查每部手機，並核實型號和硬體版本（PID VID）。
7800/8800 電話標籤，包含型號和硬體版本信息 -
使用 Cisco IP 電話就緒工具
從 https://github.com/joemar2/mpp_readiness_check下載該工具。
此工具並非思科官方工具，也不受TAC支援。它提供盡力而為的支持，但可以免費使用。
該工具必須在本機電腦上運行，並且能夠存取伺服器和 IP 電話。它提供了一個選項，可以在 IP 電話上啟用網路訪問，建議啟用此功能以獲得最佳效果，並且這是必需的。因此，應在非工作時間使用，以免對最終使用者造成乾擾。該工具的輸出結果會產生一份報告，列出哪些 7800 和 8800 系列電話符合升級到 MPP 韌體的條件。因為它直接存取手機，所以可以驗證從控制中心工具報告的 未知 裝置。
Cisco IP電話就緒工具報告
使用者
確保遷移成功的最重要準備步驟之一是正確配置使用者。即使分階段遷移，也需要為所有使用者做好妥善規劃。使用者必須具備以下任一條件：
-
使用呼叫進行部署
-
部署與
-
為使用者配置服務
-
使用戶可在目錄中被搜尋（點選撥號、使用者聯絡資訊、電話簿搜尋）。
建議您在專案開始之前或開始時配置所有使用者。這包括那些仍然使用 Unified CM 的用戶，因為他們的呼叫平台與其呼叫設備（IP 電話、Jabber 等）無關。隨著用戶遷移到 (and/or 您將更新他們的許可證，以啟用他們需要的服務。透過在開始過渡之前配置所有企業通話用戶，可以允許已過渡到其他平台的用戶在目錄中搜尋仍在使用 Jabber 的企業通話用戶。 and/or 在 。這樣可以確保過渡用戶能夠找到任何其他用戶的聯絡訊息，並使用目錄查找功能撥打電話。
圖 目錄搜尋 顯示了一個使用者搜尋另一個使用者的範例。搜尋結果顯示用戶的聯絡訊息，可能包括仍在使用 Jabber 的用戶，也可能包括已遷移到其他平台的用戶。 and/or 。
接下來確定哪些現有的本地呼叫用戶將被遷移到新系統。如果需要遷移全部或大部分用戶，建議分批遷移用戶，以確保專案團隊、IT 人員和支援人員能夠處理遷移以及可能出現的任何問題。您還應該安排一些時間提供初步資訊和培訓課程，以幫助使用者做好過渡準備。使用者轉換分組可以根據各種標準進行，包括使用者被分配到的位置或網站、使用者的部門，甚至是使用者類型（知識工作者、管理人員、行動工作者等）。
例如，如果部署中的使用者分佈在三個主要站點，即紐約 (NYC)、舊金山 (SFC) 和研究三角園區 (RTP)，則使用者過渡計畫可能類似於 按站點劃分的使用者過渡計畫 表中概述的計畫。
| 使用者網站 / 地點 | 過渡前資訊與培訓課程 | 過渡期 | 過渡後支持 |
|---|---|---|---|
| 紐約市（1,525 位用戶） | 4月1日當週 | 4月15日至4月27日 | 4月29日當週 |
| 舊金山國際機場（1,600 位使用者） | 5月6日當週 | 5月20日至5月31日 | 6月3日當週 |
| RTP（1,275 位使用者） | 6月3日當週 | 6月17日至6月28日 | 7月1日當週 |
另一個重要因素是讓彼此有依賴關係的使用者一起過渡。這可能包括但不限於以下內容：
-
BLF監測
-
同樣的狩獵 pilot/group
-
分享線
-
屬於同一個呼叫接聽組
-
使用相同的呼叫駐留號碼
-
內部通訊
-
管理員/執行
您可以查看配置（GUI 或匯出）或使用 遷移洞察 工具來協助識別具有這些依賴關係的使用者群組。
PSTN 連線
可以透過三種方式接取公共交換電話網路（PSTN）：Cisco 通話套餐、雲端連線（以前稱為雲端連線 PSTN）和本地 PSTN（本地閘道）。但是，依照規定定義的單一位置只能指派給一個 PSTN 選項。
具有本地網關 (LGW) 的本地 PSTN 是過渡策略的重要組成部分。它提供本地部署之間的連接 and/or PSTN 和此平台支援 Cisco 和經認證的第三方會話邊界控制器 (SBC)，這些控制器可用作本地網關。有關最新支援的 SBC 列表，請參閱 支援的 SBC 列表。
支援來自單一基於註冊的本地網關的最多 250 個並發調用，以及來自單一基於憑證的本地網關的超過 250 個並發調用。基於憑證的本機閘道最多可支援 6500 個同時呼叫，但這取決於本機閘道的連線類型（OTT 與互連對等連線）以及本機閘道部署的 SBC 模型。這些限製本質上是本地網關 PSTN 呼叫和站點間呼叫的預設計數限制。有關更多信息，請參閱 本地網關入門。
任何超過此限制的呼叫都將被拒絕，並傳回 403 Forbidden。可以在任何時刻在本機閘道上執行 show call active voice 指令，以決定活動呼叫的總數。
本機閘道與接取 SBC 之間的網路狀況不佳會限制訊號連線的效能，從而導致同時呼叫限制進一步降低。本地網關與資料中心之間的單向延遲不得超過 100 毫秒，抖動應小於 10 毫秒，丟包率應小於 0.5%。 %.
特徵 & 功能使用
在評估當前環境時，識別和審查已配置的功能非常重要。此外，了解這些功能的使用方法也很重要，這樣您才能（重新）定義部署的業務和技術要求。
若要確定配置了哪些功能，請分析配置。這些都是靜態數據，是在系統配置某個功能或設定時設定的。可以使用以下選項完成此分析：
-
在管理 GUI 中查看配置
-
配置匯出 -- 批次匯出或 AXL
-
遷移洞察工具（推薦）
-
思科第三方合作夥伴工具（建議）。
為了有效分析功能利用率，必須檢查動態系統數據，例如使用率、註冊量和呼叫活動。各種分析工具和儀錶板提供了對這些指標的深入了解，從而能夠全面了解系統性能和容量，為遷移和優化工作中的明智決策提供支援。可以使用以下選項完成此類分析：
-
審查原始CDR記錄
-
統一 CM RTMT 資料審查
-
使用 CDR 資料的遷移洞察工具
-
雲端連線統一通訊分析的回顧
-
通話量
-
已註冊的端點
-
（CAC）地點
-
主幹線利用率。
-
-
思科第三方合作夥伴工具。
Cisco 建議先使用 Webex Control Hub 遷移洞察工具進行此分析。您需要將匯出的 .TAR 檔案和統一 CM CDR 檔案（可選，但功能利用率分析需要）匯入到該工具中。該工具將產生以下基於 CSV 的報告，可用於開始分析：
| 報告名稱 報告說明 |
|---|
| ImportedDataBulk.csv
來自統一組態管理 (Unified CM) 資料的所有使用者和設備 |
| DeviceEligibility.csv
識別符合遷移到 Webex Calling 條件的設備（IP 電話、會議室作業系統設備、ATA 和第三方設備） |
| DevicePoolNumbers.txt 特定設備池中的所有號碼列表 |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv 根據共用線路、呼叫群組、呼叫佇列、呼叫駐留和呼叫代接群組配置，提供有關應一起遷移的裝置和使用者的詳細資訊。 |
| HuntGroupMigrationInsight.csv 有關已指派呼叫線路、線路組和相關代理的詳細信息 |
| SharedlineGroupMigrationReport.csv 用戶間共享電話號碼（目錄號碼）的方式概述 |
| 報告名稱 報告說明 |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv 根據功能使用情況提供的設備遷移資格信息 |
| FeatureUsageWithLastUsageDateReport.csv 使用次數統計，包括呼叫調度員和呼叫佇列的呼叫次數以及上次使用日期。 |
| UserWorkspaceLastUsage.csv 軟體客戶端和硬電話的使用者和工作區的最後使用日期 |
| DIDUsageReport.csv DID 的使用情況，包括已指派和未指派的 DID |
有關遷移洞察報告的更多詳細信息，請參閱 遷移洞察。
如果您在查看遷移洞察報告中的信息後仍需要有關功能和使用方法的更多信息，思科建議您考慮使用思科的第三方合作夥伴遷移工具。 and/or 查看圖形使用者介面或配置匯出資料中的配置。
思科整合：Unity Connection UCCX UCCE
語音信箱是該服務不可或缺的一部分，並且已原生內建於解決方案中。它無法與 Unity Connection 或 Unity Connection Express 等本地部署的語音信箱解決方案整合。此外，目前還沒有原生方法可以將現有的 Unity Connection 語音郵件訊息或問候語遷移到原生語音郵件服務中。思科的一些第三方合作夥伴的遷移工具確實具備遷移部分此類資料的功能。有關語音信箱的更多信息，請參閱 配置和管理 Webex Calling 用戶的語音信箱設定。
也支援共享語音信箱和傳真郵箱。有關更多信息，請參閱 管理 Webex Calling 的共享語音郵件和入站傳真箱。
它內建了自動語音應答功能，該功能包含在核心平台中。此功能允許遷移 Unity Connection 的呼叫處理程序和自動助理功能。Control Hub 工具 從 Unified CM 遷移功能 支援將 Unity Connection 配置遷移到 Auto-Atdendants。有關使用此工具的更多信息，請參閱 將設備和功能從 Unified CM 遷移到 Webex Calling。
通話錄音
包含兩種通話錄音選項，無需額外費用。
-
Webex通話錄音
-
Dubber Go 錄製（合作夥伴優惠）—與 Dubber 的集成，所有錄製的媒體都安全地保存在雲端。
包含錄音選項 表格重點介紹了兩種無需額外費用即可使用的通話錄音選項的一些關鍵功能。
| Webex | 杜伯·戈 |
|---|---|
| 所有使用者均可使用 | 所有使用者均可使用 |
| 無限次錄音 | 無限次錄音 |
| 1 年保留期* | 30天保留期 |
| 每個組織 100 GB 儲存空間 | - |
| 合規官可以存取和管理通話錄音。 | - |
| 用於管理錄製內容的 API | - |
管理員可以設定和管理使用者對其通話錄音的存取權限。
|
只有使用者才能存取和管理自己的錄音。
|
如果您的組織需要額外的錄音功能，例如合規性通話錄音、更長的保質期、更大的儲存空間、人工智慧分析等， and/or 思科和第三方錄製提供者都提供管理員存取權限、付費服務或附加元件。有關錄音提供者、配置和附加合作夥伴服務的更多信息，請參閱 管理 Webex Calling 的通話錄音。
第三方集成
支援多種第三方集成，包括但不限於本地網關的SBC、IP電話、對講電話 等。 Speaker/Pagers, ATA 等。除了這些第三方設備外，Webex Calling 還支援不同的第三方解決方案 ，用於客戶支援、分析、錄音、計費等。有關第三方解決 方案的更多信息，請參閱 Webex App Hub。
計劃
高層專案計劃
在製定從 到 的高級專案計劃時，必須建立與業務目標和技術要求一致的清晰階段和里程碑。該計劃應從全面的評估階段開始，包括收集詳細的技術和業務需求，以及確定利害關係人和定義成功標準。關鍵考慮因素包括資源分配、時間安排估算、風險管理和溝通策略，以確保所有各方在整個遷移過程中都能了解情況並參與其中。此外，該計劃應包含驗證檢查點，例如試點測試和分階段推廣，以最大限度地減少干擾，並允許根據回饋進行調整。
專案計畫中應包含的要素範例包括：
-
確定遷移範圍（例如，哪些使用者、裝置和功能將進行遷移）
-
為最終用戶和支援團隊安排培訓課程
-
協調網路就緒評估，以及
-
制定切換活動計畫並配備備用方案。將合規性和安全性審查以及遷移後支援和優化階段納入其中也十分重要。
透過根據這些考慮因素建立專案計劃，組織可以更好地管理複雜性，降低風險，並實現更平穩的過渡。
移民之旅－一步還是兩步？
要求用戶使用其呼叫軟客戶端。因此，如果還有用戶在使用，您可以選擇何時將他們遷移到。您可以執行單步驟用戶遷移或雙步驟用戶遷移。
選項 1：單步用戶遷移
在單步驟遷移中，使用者從 Unified CM 遷移到 的同時，也從 遷移到 。此選項通常適用於使用者數量較少的客戶，可以同時管理使用者的軟客戶端和呼叫服務的遷移。圖 用戶呼叫服務，軟客戶端 & 手機遷移到同一時間 下面突出顯示了這種類型的遷移。使用此選項，使用者將同時完成以下所有操作：
-
呼叫服務已從
-
電話號碼和分機號碼已從…遷移至…
-
軟體客戶端已從 Jabber 過渡到 - 將註冊
-
電話註冊從 移至 。
這仍然可以是一個分階段的遷移，用戶群組在不同的時間進行遷移，但當每個用戶被遷移時，所有這些操作都是同時進行的。
選項 2：雙步用戶遷移
另一種方法是兩步遷移。在步驟 1 中，使用者從 [此處應填寫具體位置] 過渡到 [此處應填寫具體位置]，但仍保留 [此處應填寫具體位置] 以撥打服務電話。然後在步驟 2 中，使用者從 Unified CM 遷移到 。對於希望管理最終用戶變更並將用戶軟體客戶端變更與呼叫服務變更分開的大型客戶，建議採用此選項。下圖 遷移軟客戶端；然後遷移呼叫服務，軟客戶端 & 以下透過電話到 Webex 通話 突出顯示了這種遷移方式。
步驟 1
-
軟客戶端已從過渡到 - 將註冊到。
步驟 2
-
呼叫服務已從 遷移到 。
-
電話號碼和分機號碼已從 移轉到 。
-
註冊地點從 轉移到 。
-
電話註冊從 移至 。
這仍然可以是一個分階段的遷移，在兩個步驟中，使用者群組會在不同的時間進行遷移。
您選擇的選項取決於您希望如何管理使用者向新系統的過渡。建議分步驟進行（方案 2）。這樣可以最大限度地減少最終用戶一次性進行的更改，並將工作量分配到專案的不同部分。但是，如果您希望使用者只受到一次影響，那麼使用選項 1 也是可行的。
查看建議的流程（選項 1）， Jabber 到 Webex App 進階轉換圖 下圖顯示了步驟 1 的進階轉換。
在此步驟中，用戶將從 Jabber 過渡到其所有通話服務。然而，呼叫平台仍然是 Unified CM，並且將其呼叫服務註冊到該平台。從 Jabber 到 Webex App 的高階過渡圖 可以看出，本地基礎架構不會改變，其運作方式與 Jabber 相同。唯一的改變是需要連接到外部網路。
有關此過渡的更多信息，請參閱 Jabber 到 Webex 過渡圖和部署指南 ，位於 協作過渡 頁面的客戶端部分。
Unified CM to Webex Calling high-level transition map figure is a high-level transition from to . 這是推薦行程的第二步。
如果您決定採用單步法，這同樣適用。
在此步驟中，使用者將被分組。此時，用戶開始使用呼叫服務、呼叫註冊和 IP 電話註冊。
由於用戶是成組遷移的，因此在過渡期間，企業用戶將被分散到兩個通話平台之間。 Unified CM 到 Webex Calling 進階轉換圖 中的第一階段描述了此狀態。在此階段，需要規劃如何管理兩個平台上的使用者之間的通話以及如何路由 PSTN 通話。每次有一組使用者遷移到新系統時，都需要在新系統和本地網關上更新撥號方案和呼叫路由。
一旦所有使用者、軟體客戶端和設備都過渡到（第二階段），那麼所有本地統一通訊基礎設施都可以被移除和停用。
設計
區域選擇
可在全球範圍內使用，並透過位於多個地區的冗餘資料中心進行交付：美國（達拉斯、芝加哥）、加拿大（溫哥華、多倫多）、歐洲（法蘭克福、阿姆斯特丹）、英國（倫敦、曼徹斯特）、澳洲（墨爾本、雪梨）、日本（東京、大阪）、沙烏地阿拉伯（利雅德、吉達）和印度（孟買、清奈）。媒體接入點提供媒體服務，以優化媒體往返時間。例如，新加坡資料中心用於優化亞洲國家客戶的媒體往返時間，因為往返澳洲或日本地區的媒體往返時間可能不夠理想。資料中心透過多千兆位元、完全冗餘的主幹網路互連。圖 全球分散式資料中心 顯示了所有資料中心的概覽。有關可用資料中心的最新列表，請參閱 Webex Calling 資料中心位置。
每個客戶都分配到其中一個實例。該客戶的所有設定資訊都儲存在該實例中，並且為該客戶配置的所有端點和本機網關的 SIP 訊號都與該客戶所在的實例相關聯。由於很難改變最初的區域選擇，因此在進行區域選擇決策的過程中，必須考慮所有相關因素。為了避免訊號往返延遲過長，在過渡過程中儘早決定應該使用哪個實例非常重要。Cisco 建議選擇能夠提供部署中最多使用者最簡訊令往返時間的執行個體。
有關國家/地區的可用性，請參閱 Webex 在哪裡可用？。
位置
為了準備提供遷移目標位置所需的信息，需要收集所有遷移目標位置的相關資訊。每個地點所需的資訊匯總在 每個地點需要捕獲的資訊。
| 資訊 | 評論 |
|---|---|
| 擴展範圍 | 每個位置都可以有以不同數字開頭的分機號碼。必須留出一位數字作為站點間撥號轉向數字（例如 8），一位數字作為 PSTN 轉向數字（例如 9）。任何擴展號碼都不能以這兩個數字中的任何一個開頭。 所有位置的擴展範圍長度必須相等。 |
| DID範圍 | - |
| PSTN轉向數字 | - |
| 網站程式碼 | 所有地點的所有站點代碼都必須是唯一的，且長度必須相同。 |
| 主要號碼 | 建立位置時需要配置兩個 DID。一個作為主要號碼（例如分配給自動應答服務），一個用於語音信箱入口網站。 為語音信箱號碼提供一個DID號碼。 |
| 語音信箱號碼 | |
| 授權數目 | 所需許可證類型包括：標準版、專業版、工作區版、路由清單版、外呼計畫版。 |
| 繁忙時段的並發呼叫 | 設備之間以及設備與本地網關之間並發呼叫的總和（PSTN 和呼叫到設備）。需要確定所需的網路存取頻寬。 |
| Country | - |
| 時區 | - |
| 語言 | - |
| 聯絡方式（姓名、電話、信箱） | - |
| 地址（街道地址、城市、州/省、郵遞區號） | - |
| 緊急服務終端的實體調度位置 | 用於緊急呼叫的設備可調度位置通常包括以下位置：建築物地址，建築物地址 + 樓層號，樓宇地址 + 套房號或樓宇地址 + 樓層號 + office/cubical 數字。 |
| 每個設備唯一的實體網路位置，用於緊急服務 | 緊急呼叫的實體網路位置通常包括以下部分：轉變 / 用於有線設備的交換器端口，用於無線連接設備的無線接入點（AP）基本服務集標識符（BSSID）。 and/or 用於終端設備的本機 IP 子網路。 |
PSTN
在設計部署方案時，客戶有三種主要的PSTN連線選項：Cisco Calling Plans（由 Cisco 管理的雲端交付 PSTN 服務）、雲端連線 PSTN 供應商 (CCPP，供應商透過雲端提供 PSTN 服務) 和本地 PSTN (本地網關將企業網路連接到 PSTN)。透過引入用於混合部署的 PSTN 中繼（有關更多信息，請參閱 PSTN 中繼中的用於混合 Webex Calling 部署的 PSTN 中繼），組織在遷移方法上獲得了更大的靈活性。此功能使客戶能夠在過渡之旅開始時將 PSTN 遷移到 CCPP，並開始為使用者過渡到雲端 PSTN，同時利用 CCPP 在分階段遷移期間為留在 Cisco 的使用者維持 PSTN 服務。
這種混合方法允許組織先將選定的使用者群組遷移到雲端，而無需立即徹底改造其整個電話環境。然而，這也帶來了額外的複雜性和風險，尤其是在調整現有呼叫路由邏輯以支援新架構方面。與傳統應用程式（例如傳真伺服器、呼叫中心或尋呼系統）的互通性也需要仔細考慮。關鍵技術挑戰可能包括確保在混合環境中實現無縫的端到端編解碼器協商和 DTMF（雙音多頻）信令，以及驗證與專用電話功能的兼容性。妥善的規劃和測試對於最大限度地減少中斷和在整個遷移過程中保持可靠的語音服務至關重要。此外，商業因素也很重要，因為混合中繼需要根據本地環境和雲端連接 PSTN 供應商 (CCPP) 之間的並發呼叫數量來獲得使用授權。
或者，各組織可以選擇在整個過渡階段保留其內部 PSTN 連線。在這種情況下，遷移到 CCPP 可以透過兩種方式執行：遷移完成後，可以對所有使用者和地點進行一次統一協調的切換，也可以逐步進行，PSTN 遷移根據使用者遷移到的地點逐一進行。這種方法有助於簡化共存並保持傳統整合的連續性，但同時也引入了一些操作上的複雜性。其中包括與號碼攜號轉網相關的挑戰，例如需要精確協調號碼攜號轉網訂單、可能出現的延遲以及運營商施加的限制，例如限制同時進行的攜號轉網請求數量或限制攜號轉網大號碼塊的子集。各組織必須仔細規劃其 PSTN 過渡策略，並將這些後勤因素考慮在內，以避免服務中斷並確保平穩的遷移體驗。
圖 一開始遷移到 CCCP 與保留本地 PSTN 顯示了上面解釋的兩個 PSTN 遷移選項。左圖顯示的場景是所有本地用戶和應用程式都透過本地中繼和連接本地與雲端的本地網關來使用雲端連接的 PSTN 服務，而右圖顯示的場景是現有的本地 PSTN 保持不變，Webex Calling 用戶透過本地與雲端之間的本地網關連接來使用本地 PSTN。過渡期間，各地點可以切換到使用雲端連線的 PSTN。
在這兩種情況下，本機系統和使用者之間的呼叫都使用本地網關連接。本地與外部之間的連接需要根據預期的並發呼叫數量和所需的冗餘度進行相應的設計和規模調整。
撥號計劃
為了在遷移期間實現無縫互通性，必須在兩個平台之間開發和實施全面的撥號方案架構。這種雙平台撥號方案設計確保了呼叫路由、號碼轉換和功能透明度的一致性，使兩個系統上的使用者都能在整個共存階段進行通信，而不會出現服務降級或使用者體驗中斷。
本地撥號方案
在過渡期間，為了允許在 Unified CM 和企業撥號計劃上註冊的設備共存，需要進行更改，以便至少滿足以下要求：
-
+E.164 撥號從到
-
分機撥號（站點內撥號，若分機號碼範圍唯一，也可站點間撥號）
-
從到站點間的簡短撥號
-
強制從到網內撥號
-
從未接來電目錄回撥至目的地
-
如果在過渡期間使用本地 PSTN，則 PSTN 通話將從本地 PSTN 呼叫到本地 PSTN。
-
如果在混合部署的過渡期間，使用 PSTN 中繼透過 Cloud Connect 為本地用戶提供 PSTN 訪問，則 PSTN 呼叫將從本地呼叫發送到本地呼叫。
-
被迫從網路到
-
分機撥號（站點間）。
如果在過渡之前不支援上述任何撥號習慣，例如不存在縮短的站點間撥號習慣，那麼在過渡期間不一定需要引入這些習慣。
圖 最佳實務撥號方案 顯示了 Cisco Collaboration 12.x 企業本地部署首選架構 (CVD) 中所述的最佳實務撥號方案方法。此方法的主要特點包括：
-
單一分區 +E.164 電話號碼簿
-
基於核心路由 +E.164 路線模式
-
將所有撥號習慣規範化 +E.164 使用翻譯模式
-
使用翻譯模式呼叫搜尋空間繼承（選項 使用發起者的呼叫搜尋空間 設定在翻譯模式上）。
例如，PSTN撥號 (9+1+10D) 來自 SJC 中已配置線路呼叫搜尋空間 SJCInternational 的裝置將首先與 相符。 9.1[2-9]XX[2-9]XXXXXX 將被叫號碼規範化的轉換模式 +E.164. 然後，二次查找再次使用相同的呼叫搜尋空間 SJCInternational （呼叫搜尋空間繼承），並且 +E.164-digit 字串要么會被匹配，要么會被其他字串匹配。 +E.164 在 DN 分區中，或透過 USPSTNNational 或 SJCPSTNLocal 分區中的 PSTN 路由模式之一。站點內和站點間撥號習慣的簡化是透過 ESN 和 SJCtoE164 分區中的翻譯實現的。雖然 ESN 分區是全域分區（所有位置的手機均可存取），但 SJCTOE164 分區僅對位於 SJC 位置的用戶可存取。這是假設擴展範圍重疊的情況。
啟用從到的呼叫的第一步是確保 +E.164 目的地將根據目的地進行相應路由。這可以透過向撥號計劃添加分區來實現，添加 +E.164 為到該分區的所有目的地建立路由模式，最後將該分區新增至所有呼叫搜尋空間，表示需要能夠到達的服務類別。需要建立一個專用分區，以便為來自以下位置的呼叫建立差異化的服務類別：為避免呼叫循環，本機閘道中繼上的入站呼叫搜尋空間不應存取該分割區。
如圖所示 +E.164 路由到 Webex Callex，以啟用從某個位置到某個位置的路由 +E.164 DID範圍 +1 221 555 2XXX 和站點代碼 121，與此相符的緊急路線模式 +E.164 需要將範圍加入 分區。
如果不需要選擇特定站點的本機網關，則可以不採用以本機路由群組為目標的路由列表，而是設定以本機網關為唯一成員的路由群組，然後路由模式指向一個僅包含該路由群組條目的路由列表。
為了實現站點間的短撥號，需要將所需的路由模式 8121.2XXX 新增至分區。為使站點能夠過渡到撥號規範化模式 8121.2XXX ，此模式將 ESN 撥號規範化為 +E.164 可能已存在於 ESN 分區中。在這種情況下， 8121.2XXX 似乎是多餘的，但是一旦相應位置的所有 DN 都遷移到 8121.2XXX 撥號規範化轉換模式，就可以刪除 8121.2XXX 路由模式，即使對於該範圍內的分機用戶，也可以啟用 ESN 撥號。
透過這些撥號方案的更改，不僅可以撥打站點間短撥號碼，還可以撥打其他撥號號碼撥打到該位置。 +E.164. 此外，國際和國內PSTN撥號是可行的，因為這些撥號習慣首先被規範化。 +E.164 透過現有的撥號規範化轉換模式，然後透過配對進行路由。 +E.164 分區中的路由模式。
這 +E.164 在所有 DID 仍託管在 上的情況下，可以設定位置 DID 範圍的路由模式比對。最佳匹配模式匹配演算法確保當撥打託管在 [此處應填寫系統名稱] 上的號碼時， +E.164 目錄號碼的匹配度比通配符更高。 +E.164 路由模式指向，以便將呼叫擴展到線路，而不是發送到。
撥號計劃
每個用戶都分配有一個擴展名。 and/or 一個 +E.164 電話號碼。擴展長度是一個固定的全域設定：部署中的所有擴充長度都相同。分機撥號功能既可以在同一地點內使用，也可以在不同地點之間使用。簡單的站點間分機撥號（後一種情況）僅在所撥打的分機是唯一的情況下才有效。
如果需要在不同地點之間進行縮短的站點間撥號，但不同地點分配的分機號碼有重疊，則需要建立企業特定的號碼方案，在分機號碼前加上接取碼和站台代碼。有關更多信息，請參閱 Cisco Collaboration 15 本地部署的首選架構，設計概述 可在 Cisco Collaboration Preferred Architectures處獲取。
分機長度、跨區分機撥號行為、跨區撥號前綴長度以及跨區撥號路由前綴中的轉向數字均在呼叫服務設定中進行設定。 :
-
位置路由前綴長度: 前綴長度（包括轉向數字）。只有在需要建立企業編號方案作為備用的縮短的企業間撥號習慣時才需要。
-
路由前綴中的轉向數字: 用於簡化企業間撥號習慣的導向數字。應避免與任何位置的首位數字和位置外撥號碼重疊。只有在需要建立企業編號方案作為備用的縮短的企業間撥號習慣時才需要。
-
內部延伸長度: 標準長度的接髮。可以是2到10之間的任何值。
當需要從本地呼叫控制中心撥打分機號碼或使用企業有效號碼（轉向代碼、站點代碼、分機號）撥打電話，並且本地呼叫控制中心將分機號碼作為呼叫者 ID 發送時，請確保在 “呼叫路由 ”部分中設置 “最大未知分機長度 ”參數，以確保從本地呼叫控制中心到本地呼叫控制中心的上游呼叫能夠被正確分類為本地呼叫。 -
允許不同地點之間撥打分機號碼: 切換到 enable/disable 在不同地點之間進行分機撥號。只有當組織內的所有分機號碼都是唯一的時，才應啟用此選項。如果停用此選項，則需要在各個位置之間撥打企業重要號碼（路由代碼、站點代碼、分機號碼）或電話號碼。
前三個參數主要用於建立電話撥號方案，以最大限度地減少摘機撥號時的數位間逾時。仍然可以偏離這些全域設定（例如 - 可以配置不同長度的分機），但控制中心會彈出警告訊息，並且從電話撥號可能需要進行整體撥號，以避免與預先載入的撥號計劃發生衝突。
表 企業編號範例 顯示了三個位置的範例，其中兩個位置（紐約市和 RTP）的擴展範圍相同。建立企業編號方案，採用站點間引導數字 8，後面接著三位數站點代碼和四位數分機號，從而形成不重疊的站點間撥號縮寫習慣。
| 站點 | 擴展範圍 | 網站程式碼 | 企業級 |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
為了實現平穩過渡，用戶在過渡前後的撥號習慣最好保持一致。為了做好每個地點過渡的準備，需要記錄 DID 號碼範圍和分機號碼範圍（或站點內撥號習慣）。根據這些信息，需要選擇站點間轉向數字。
表 固定長度擴展範圍 顯示了三個位置和固定長度擴展範圍的範例。由於需要避免重疊的撥號習慣，因此必須確保任何分機號碼範圍的第一位數字與短程站點間撥號的轉向數字不符。例如，如果選擇 8 作為站點間撥號的轉向數字，則任何站點中的任何分機號碼都不能以 8開頭。通常情況下，某個位置的分機號碼與分配給該位置的 DID 號碼的最後幾位數字相符。為避免衝突，可以更改分機號碼的第一位數字。例如，如果DID在 +1 如果某個地點使用了 408、555 和 8XXX 範圍的號碼，那麼該網站的擴充號碼範圍可以改用 7XXX，而不是 8XXX。
| 站點 | 擴展範圍 | 分機 | 網站程式碼 | 企業級 |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
使用美國撥號方案的裝置撥打的七位撥號字串與預先載入的美國撥號方案中用於本地撥號的七位撥號模式重疊。為避免網內撥號及網外撥號（PSTN）習慣重疊，此位置可使用強制外部接取碼。如果現有的企業編號方案和相應的站點間短撥號與國家撥號模式重疊，那麼在過渡到編號方案時，為了避免重疊，也可以將其更改為更長或更短的形式。實現這一目標最簡單的方法是在編號方案中添加一個額外的填充數字。新的更長的站點間撥號方案只需要已遷移到的用戶採用。仍在線上的用戶可以繼續撥打七位數。在這種情況下，企業撥號方案需要確保從 Unified CM 到其他系統的七位短撥號碼能夠轉換為以下兩種方式之一： +E.164 或使用部署在 上的簡化撥號格式。這需要在向本地網關發送呼叫之前完成。
表格 過渡到七位撥號 顯示了這種重新編號的範例。在這個例子中，站點間撥號的縮寫形式是使用引導數字 8，後面跟著兩位數的站點代碼和四位數的分機號碼。為了避免對 上的地點使用七位數的縮寫站點間撥號，可以透過在 中使用的兩位站點代碼前添加任意填充數字（例如8 ）輕鬆地將站點代碼更改為三位數字，這樣，從電話撥打站點間電話時，將使用引導數字 8 ，後跟填充數字 8，舊的兩位分代碼。使用者無需記住新的網站代碼；他們只需記住在站點間撥號時使用 88 作為前綴，而不是 8 。
| 站點 | 分機 | 站點代碼 | 企業級 | 站點 ode | 企業天使 |
| NYC | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
如果企業號碼格式不同，且企業號碼會顯示為呼叫方資訊（例如，沒有 DID 的裝置撥打的電話），則必須實現呼叫方資訊的不同號碼格式之間的映射，以確保回撥功能正常運作。可以透過在本地網關和主幹線路之間使用呼叫方轉換模式來實現這種映射。
錄製檔
一個架構完善的通話錄音解決方案需要仔細考慮幾個關鍵的設計要素，以確保其符合組織目標、監管要求和技術限制。兩個最關鍵的決策涉及供應商選擇和地區選擇，這兩項決策可能都需要在全球範圍內進行調整，並根據業務需求在特定地點進行調整。
1. 選擇通話錄音服務供應商
選擇合適的通話錄音服務提供者對於實現業務目標和確保組織內功能一致性至關重要：
-
全球供應商選擇： 企業通常會在全球範圍內指定一家主要的通話錄音服務供應商，以確保所有地區的功能、合規性和支援保持一致。
-
基於位置的覆蓋： 在特定地點或地區有特殊業務需求或監管要求的情況下，可能需要涵蓋全域供應商選擇，並為這些地點指定替代供應商。這種靈活性能夠滿足不同的合規要求和本地營運需求。
-
業務需求： 選擇服務提供者時，應基於對業務驅動因素的評估，例如監管合規性（例如MiFID II、HIPAA）、品質保證、爭議解決或培訓需求。
-
功能可用性： 應根據服務提供者提供所需功能的能力對其進行評估，例如即時監控、搜尋和回放功能、加密、保留策略、與分析平台的整合以及對不同呼叫類型（呼入、呼出、內部）的支援。
2. 區域選擇
確定通話錄音的儲存和處理區域對於合規性和效能至關重要：
-
全球區域選擇： 預設情況下，組織可以選擇單一區域來儲存通話錄音，以簡化管理和治理。
-
基於位置的區域覆蓋： 根據資料駐留法律或公司政策的要求，可能需要針對特定位置覆蓋全球區域設置，以確保通話錄音在規定的地理範圍內儲存和處理。
-
資料駐留要求： 該設計必須考慮到國際和本地資料保護法規（例如 GDPR、CCPA 或特定國家/地區的強制性規定），這些法規可能會規定通話錄音的保存地點和方式。
在規劃和設計通話錄音解決方案時，需要解決的另一個關鍵方面是儲存需求的估算。準確預測儲存需求對於確保有足夠的容量來支援持續的業務運作、保持合規性以及避免服務中斷至關重要。
在確定預期儲存需求時，應考慮以下幾個關鍵參數：
-
錄音通話量： 評估在給定的時間間隔內（例如，每天、每週或每月）預計會記錄的通話數量。這不僅包括對外通話，還包括內部溝通，如果業務政策或監管要求需要的話。
-
平均通話時長： 計算錄音通話的典型時長，因為通話時間越長，佔用的儲存空間就越多。不同部門或使用者群體之間的通話時長差異也應納入估算。
-
保留期： 確定錄音必須保留的時間長度，這通常由組織政策或外部法規（例如行業特定的合規標準）規定。更長的保質期將增加整體儲存需求。
-
成長預測： 考慮預期呼叫量的成長或錄音範圍的擴大，這可能是由於業務規模擴大、新的監管要求或新增使用者或地點所致。
透過徹底分析這些參數，組織可以製定強大的儲存策略，從而確保其通話錄音解決方案的可擴展性、成本效益和合規性。隨著使用模式隨時間推移而變化，建議定期審查和調整儲存分配。
緊急呼叫
任何提供 PSTN 服務的呼叫服務都必須將緊急呼叫轉移到相應的調度中心。有了它，緊急呼叫路由功能就內建在解決方案中，並支援所有支援的國家/地區的國家緊急號碼。緊急呼叫的路由是根據呼叫方定義的位置以及該位置的 PSTN 存取方式來決定的。緊急號碼是預先設定的，並且特定於用戶和設備部署所在的國家/地區。
有兩種方法可以撥打緊急電話。有基本緊急呼叫路由服務和增強型緊急呼叫路由服務。基本的緊急呼叫路由服務將使用管理員選擇的號碼來識別位置和呼叫路由，從而聯繫緊急服務部門。對於基本的緊急呼叫，呼叫路徑通常會透過客戶在該地點的公共交換電話網路 (PSTN) 選項。此外，還提供增強型緊急呼叫路由，專為美國和加拿大的部署而設計，這些部署有監管合規性要求，需要使用全國性服務提供者將緊急呼叫轉移到正確的調度中心。
所有客戶應至少部署基本的緊急呼叫配置。基本的緊急呼叫要求至少有一位客戶擁有 +E.164 將編號指派給定義在 中的每個位置。對於基本的緊急呼叫，每個地點都將由一個街道地址定義，在緊急情況下，警察、消防或救護服務將被派往該地址。在大多數情況下，位置的主要編號是代表緊急情況實際位置的最佳選擇。通常情況下，地址的分配是 +E.164 號碼與PSTN提供者協調。下面的圖片顯示了 Richardson 地點分配用作緊急回撥號碼的主要號碼。
在大多數情況下，建築物地址足以作為該地點的調度地址。但是，如果需要特定使用者或設備的額外位置詳細信息，則管理員可以使用上述相同的流程，將這些設備分配給特定地址或地址內更精確的位置（例如樓層或房間）。在 使用者管理 中， 呼叫 標籤允許為使用者及其裝置使用特定號碼來取得特定調度位址。以下圖片顯示如何為設備指派一個特定的編號。管理員負責確保設備使用的號碼已分配正確的派送位址。地址分配通常由該地區的公共交換電話網路 (PSTN) 提供者完成。
對於必須提供增強型緊急呼叫解決方案的美國電話部署，使用 RedSky 的 Horizon Mobility 整合到緊急呼叫路由。使用 RedSky 進行呼叫路由時，管理員必須透過 Cisco 註冊帳戶，並在 Calling 中設定相應的資訊。 -> 服務設定 以啟用此功能。在系統層級啟用 RedSky 服務後，管理員將在每個位置層級啟用 RedSky 服務。在某個地點啟用增強型緊急呼叫功能後，分配給該地點的所有裝置都會啟動該服務。支援增強型緊急呼叫的設備包括 Cisco MPP 電話、Cisco PhoneOS 電話和 Cisco 的 。
有兩種設定可用於在某個位置啟用增強型緊急呼叫功能。應該使用 允許 RedSky 接收網路連接資訊和測試呼叫 來驗證 RedSky 設備和基礎設施映射的配置是否正確。此設定還允許撥打 933 進行測試呼叫，以使用 RedSky 的 IVR 系統執行位置驗證，讀取呼叫者的位置。雖然本文檔不會涵蓋 RedSky 的位置追蹤配置，但管理員應始終在啟動緊急呼叫路由到 RedSky 之前測試其位置發現功能。一旦測試完成並驗證準確無誤，管理員將透過切換「將緊急呼叫路由到 RedSky」選項，將呼叫路由到 RedSky。此開關會將該地點的所有緊急呼叫轉移到 RedSky，再由 RedSky 轉接到該地點的應答中心。
增強型緊急呼叫設定同樣適用於公司內部和外部的客戶。在公司內部，可以像追蹤桌上型電話一樣追蹤它們。當用戶不在公司時，可以直接在應用程式中動態設定他們的位置。有關緊急呼叫的更多信息，請參閱 增強型緊急呼叫。
授權
有多種方法可以為使用者分配許可證。
手動分配
管理員透過介面手動為各個使用者分配許可證。
管理員可以編輯單一使用者的服務許可證，並直接指派呼叫許可證。
自動許可證分配模板
使用許可證分配模板，根據群組或組織設定自動為使用者分配許可證。
自動許可可以透過目錄同步或手動使用者更新來實現，但使用者必須擁有有效的許可證。 +E.164 格式化的電話號碼，並且這些電話號碼必須在使用者配置之前存在於某個位置。如果條件不滿足（例如電話號碼格式無效），則不會指派許可證。
透過 CSV 模板進行批量分配
上傳包含使用者詳細資料和許可證分配的 CSV 文件，即可一次新增或修改多個使用者。
CSV 匯入支援新增最多 20,000 個使用者並分配許可證，但許可證需要電話號碼和分機號碼等特定欄位。
基於 API 的分配
使用 API 以程式方式指派許可證和管理使用者。
支援使用者和許可證管理的 API 操作（人員、SCIM 2.0 和許可證 API），可用於許可證分配自動化。許可證 API 允許同時分配許可證、電話號碼和分機號碼。
| 賦值方法 | 優點 | 缺點 |
|---|---|---|
| 手動操作 | 簡單易用，適合少數用戶。 允許對許可證分配進行精確和細緻的控制。 | 不具備可擴展性，且耗時。 手動輸入容易出現人為錯誤。 |
| 自動許可證模板 | 可擴充 減少人為錯誤 可應用於新用戶和現有用戶。 | 需要提供有效的電話號碼和地址。 設定起來更複雜。 此外，還需要為每個使用者群組設定具有同等許可要求的使用者群組。 |
| 批次上傳 CSV 文件 | 對大型用戶集來說很高效 允許同時分配許可證、電話號碼和分機號碼。 | 需要仔細格式化 CSV 文件 如果電話號碼或分機號碼缺失或錯誤，則可能發生錯誤。 |
| 基於 API 的分配 | 可自動化，靈活。 允許同時分配許可證、電話號碼和分機號碼。 | 需要具備開發和API知識。 |
表 使用者配置選項 - 概要 總結了使用者配置選項及其優缺點。此概述有助於根據客戶組織規模、自動化能力以及使用者配置流程和要求選擇最佳的許可證分配方法。
Cisco 建議盡可能使用許可證範本來指派呼叫許可證。這就要求對於每個需要不同授權的使用者群組（例如 - 標準版與專業版），都存在一個具有相應群組成員資格的群組。如 使用者群組 部分所述，使用者群組可以在企業目錄中手動定義，也可以從企業目錄同步。兩種方法結合起來也是可行的。
屬於多個群組的使用者將獲得應用於其所有群組的所有分配的許可證。這樣就可以在企業目錄中使用特定於許可證的安全群組來管理許可證分配，其中最終的使用者許可證分配由群組成員資格的共同控制。
有關更多信息，請參閱 在 Control Hub 中設定自動許可證分配 和 為 Webex Calling 用戶設定自動許可證分配模板。
許可證要求
本節僅涵蓋相關許可證。其他許可證類型（例如 Webex 設備註冊、訊息傳遞、會議）不包含在內。作為設計過程的一部分，需要確定許可證要求。需要計算以下幾種許可證類型的許可證數量：
-
標準: 需要標準電話功能的個人使用者數量。
-
專業的: 需要進階電話功能的使用者和工作區數量。虛擬線路和群組語音信箱有權享有以下服務： 1:1 每種專業執照的比例。因此，在極少數情況下，當所需的虛擬線路或群組語音郵件數量超過需要進階電話功能的使用者和工作區數量時，就需要考慮額外的專業授權。
-
公共區域工作空間: 需要標準通話功能的共享使用或公共區域位置數。
-
客戶服務: 需要客戶協助功能的客服人員及主管人數。客戶協助服務包括專業執照。
-
路由清單調用: 本機用戶之間所需的雲端連線 PSTN 通話數量 and/or 本地部署的第三方專用應用程式。
-
服務生控制台: 需要存取助手控制台客戶端的使用者數量。
-
Cisco 通話計劃（外撥計劃）: 需要PSTN號碼的使用者數量 and/or Cisco PSTN 服務的出站 PSTN 呼叫存取。
專業工作區沒有專門的許可證類型。專業工作區需要專業版許可證。
僅提供共享辦公桌的工作空間提供共享辦公桌主機服務和來自共享辦公桌主機的緊急呼叫，並且不需要任何許可證。有關更多信息，請參閱 添加和管理僅限共享辦公桌的設備。
若要根據所需功能決定每個使用者和工作區所需的許可證類型，請參閱 Webex Calling 按許可證類型提供的功能。
若要區分呼叫佇列與專業授權結合提供的功能與客戶協助提供的功能，請參閱 Webex Calling 呼叫佇列與客戶協助功能比較。
使用者佈建
在 Webex 中配置使用者時，有多種選項可供選擇，每種選項都適用於不同的組織需求和環境：
-
手動配置: 管理員可以直接在系統中新增和管理單一使用者。這種方法簡單直接，但最適合小型組織或使用者變更有限的情況。
-
透過 CSV 檔案批量配置: 對於使用者數量較多的情況，管理員可以透過上傳 CSV 檔案批次匯入和更新使用者。這樣可以同時有效率地管理多達數千名用戶。
-
目錄同步選項：
目錄連接器: 這是微軟Active Directory環境中使用的自動同步工具。它會按計劃（每小時、每天或每週）同步使用者帳戶、群組和屬性。它支援多網域和多林 Active Directory 設置，並且可以同步設定檔映像和會議室物件。
Entra ID（Azure AD）精靈應用程式: 此方法專為使用 Microsoft Entra ID (Azure AD) 的組織而設計，可實現使用者帳戶和屬性從 Entra ID 到 Azure AD 的自動、近乎即時的同步。它完全由系統內部管理，只需要極少的設定。
SCIM 2.0 應用: 對於非微軟環境或其他身分識別提供者（如 Okta 或 Duo），基於 SCIM 的同步應用程式可實現自動使用者配置和取消配置，並支援屬性對應和群組同步。
-
統一 CM 用戶同步: 此選項允許透過從現有最終用戶同步到現有最終用戶來建立用戶帳戶。這要求雲端連接統一通訊（CCUC）在本地叢集上運作。但是，通常建議從 Entra ID 等集中式雲端目錄同步用戶，而不是直接從本地同步。
-
API配置: 可以使用公共 API（People、SCIM 2.0）來設定使用者。使用 API 的主要好處是可以將使用者配置與其他企業系統整合。
此概述和表格反映了主要的使用者配置選項、它們的優點和局限性，以幫助您選擇最適合您組織需求的方法。表 6. 使用者配置選項 佈建方法 說明 優點 缺點 手動 Create/manage 使用者單獨 使用者數量少時操作簡單；無需基礎設施 不具備可擴展性；對許多用戶來說耗時較長 批量（CSV 檔案） Import/update 透過 CSV 檔案批次匯入用戶 適用於團隊協作；無需編程 手動準備 CSV 檔案；動態性較低 人員和 SCIM 2.0 API 透過 Webex API 進行程式化使用者管理 靈活；支援自動化和集成 需要開發和基礎設施 目錄同步 自動同步來自 AD、Entra ID、SCIM 應用程式和統一設定管理 自動化生命週期；支援篩選和映射 設定複雜度：部分選項功能有限或需要基礎設施。
使用者群組
使用者群組管理允許管理員將使用者組織成群組，以便有效率地大量管理許可證、設定和資源。群組透過同時將策略、授權和設定範本應用於多個用戶，而不是單獨管理用戶，從而簡化管理。
使用者群組管理有以下幾個優點：
-
簡化管理 : 一次性管理多個使用者的許可證、設定和策略。
-
一致性: 在同一組使用者中套用統一的設定和許可證。
-
可擴展性: 每個群組最多可容納 25 萬名成員。
-
一體化: 從 Microsoft Entra ID (Azure AD) 或 Active Directory 同步群組，實現使用者和群組的自動化管理。
-
靈活性: 建立本機群組或同步安全性群組；手動或透過 CSV 檔案管理群組成員。
-
資源分配: 根據群組成員身分控制對嵌入式應用程式和服務的存取權。
使用者群組在配置過程中的主要應用場景包括：
-
許可證分配: 將許可證分配給群組，以便自動為群組成員提供通話、會議、訊息傳遞或混合服務等服務。
-
設定模板: 將服務設定集合（例如，訊息傳遞、會議、通話）應用於群組，以獲得一致的使用者體驗。
-
批量用戶管理 : 透過 CSV 檔案或目錄同步批次新增或刪除使用者。
-
自動化和集成 : 使用 API 或目錄同步實現使用者和群組生命週期的自動化管理。
下表總結了管理使用者群組和群組管理的不同選項。
| 選項 | 說明 | 優點 | 缺點 |
|---|---|---|---|
| 群組配置（群組） | 直接在 .中建立和管理群組。Add/remove 手動新增或透過 CSV 檔案新增成員。 | 對群組成員資格擁有完全控制權 立即應用許可證和模板 建立和編輯群組都很方便 |
需要手動更新 手動上傳CSV檔案有出錯風險 不支援與外部目錄自動同步 |
| 從 Entra ID（Azure AD）或 Active Directory 同步群組 | 自動從外部目錄服務同步安全性群組和成員關係。 | 自動同步減少了人工工作 確保與公司名錄保持一致 支持大型組織 |
無法編輯群組成員資格 同步延遲最長可達 12 小時 嵌套組需要手動選擇 |
| 群組和 SCIM 2.0 API（群組） | 使用 Groups 或 SCIM 2.0 API 進行程式化群組和成員管理 | 自動化以及與其他系統的集成 可擴展以適應大型或複雜環境 |
需要開發工作 複雜性取決於 API 的使用情況 |
雖然同步群組可以確保一致性並提供單一的管理點，但也可以採用混合方法，將同步群組和群組（在控制中心管理或透過 API 管理）結合起來。例如，許可證分配組可以是同步群組，而分配使用者和呼叫範本可以使用另一組單獨的群組。
這種全面的使用者群組管理方法使組織能夠有效地管理使用者授權、設定和策略，從而確保一致且可擴展的協作體驗。
從到遷移的建議方法
使用者的主要資料來源是資料庫，其中包含最終使用者資訊。然而，它通常不是使用者身分管理的權威來源，更重要的是，它將在過渡結束時關閉，因此被排除在身分資訊的長期權威來源之外。
Cisco 建議使用集中式雲端目錄（例如 Microsoft Entra ID (Azure AD)）作為使用者身分的唯一真實來源。將 Entra ID 中的使用者同步，可確保一致性，簡化管理，並支援單一登入 (SSO) 功能。
為確保所有使用者也存在於 Entra ID 中，各組織應核實使用者帳戶是否與 Entra ID 中的帳戶相對應。這可以透過從 Entra ID 匯出使用者清單並將其與 Entra ID 使用者清單進行比較來實現。
總而言之，建議的設定方法是使用 Azure AD 精靈或 SCIM 應用程式將使用者從 Microsoft Entra ID (Azure AD) 同步到 Webex。手動和 CSV 批量配置可作為補充方法，但對於大型組織而言，其可擴展性較差，更容易出錯。確保 Entra ID 是權威來源，並且所有使用者都存在於 Entra ID 中，對於成功遷移和跨環境的一致使用者體驗至關重要。
從本機目錄服務（如 Active Directory）過渡到雲端目錄服務（如 Entra ID (Azure ID)）與呼叫過渡無關。Cisco 建議在開始呼叫系統遷移之前，先完成向雲端目錄服務的遷移。
使用者群組設計
將企業目錄從本地端遷移到雲端後，根據授權和功能範本要求收集所需的使用者群組。對於每個群組文檔：
-
群組名稱：該團體的獨特名稱。
-
授權：若要指派給該群組的許可證（如有）以及範圍（許可證是分配給現有使用者還是僅指派給新使用者）
-
設定模板：Webex 應用程式和使用者呼叫範本。
-
目錄同步：這個群組是從企業目錄同步的，還是在 Control Hub 或透過 API 配置的本機 Webex 群組？
-
說明：這個群組將如何使用？哪些用戶應該成為這個群組的成員？
這些細節將在實施階段用於建立本機群組或企業目錄中的群組，並管理使用者的群組成員身分。
單一登入（SSO）
Cisco 建議使用 SSO 進行使用者身份驗證。使用單一登入 (SSO) 具有一些顯著的優勢，包括：
-
簡化使用者身份驗證： 使用者可以使用其企業憑證（例如 Azure ID）登入一次，即可存取其他整合應用程序，從而無需多個密碼，並減少登入提示。這樣可以確保企業密碼在身份驗證後永遠不會被儲存或傳輸，從而增強安全性。
-
簡化用戶管理： 根據公司目錄的變更自動建立、更新和停用使用者帳戶，從而減少管理開銷，並確保只有授權使用者才能存取。
-
安全性提升： SSO 透過受信任的身份提供者 (IdP) 集中進行身份驗證，從而減少密碼疲勞和與密碼相關的洩露風險。
-
輕鬆整合多因素身份驗證 (MFA)： MFA 可以透過 Cisco Duo 等身分存取管理解決方案輕鬆實現，也可以透過 IdP 的 MFA 支援實現。
實現服務單一登入 (SSO) 有多種方案：
-
基於 SAML 2.0 的單一登入： 支援 SSO 整合的主要協議，可在身分識別提供者 (IdP) 和服務提供者之間安全地交換身分驗證資訊。
-
OpenID Connect (OIDC)： 支援作為 SSO 整合的替代現代身份驗證協定。
-
Webex身分： 同時支援作為身分提供者選項。
SSO 透過集中配置和管理，需要在和所選的身份提供者 (IdP) 之間交換元資料。
配置完成後，可以在啟動前對 SSO 進行測試，以確保設定正確。
Cisco 支援與多種經過測試且常用的身分識別提供者 (IdP) 和身分識別管理系統 (IAM) 集成，包括但不限於：
-
思科雙核
-
Okta
-
微軟活動目錄聯合身分驗證服務 (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 BIG-IP.
這些身分提供者符合 SAML 2.0 或 OpenID Connect 標準，並且經過驗證，與 Cisco 協作解決方案相容。
支援多個身分提供者
允許組織配置具有多個身分提供者的 SSO，以適應複雜的 IT 環境，例如合併、收購或分散的 IT 部門，其中不同的群體使用不同的身分提供者。可以透過使用 Cisco Duo 等企業 IAM 系統中的多 IdP 功能來實現多 IdP 支持，也可以透過整合該系統來實現。
的多重身分提供者 (IdP) 支援可滿足組織在各種 IT 環境中進行靈活、安全的身份驗證的幾個關鍵用例：
1. 合併與收購
當公司合併或收購其他公司時，它們通常擁有獨立的 IT 基礎設施和不同的身分提供者，這些提供者無法進行聯合。支援多個身分提供者 (IdP) 可以讓兩個組織的使用者進行身份驗證並安全地協作，而無需立即統一他們的身份系統。
2. 多個獨立的IT部門
大型組織或政府機構可能擁有多個獨立的 IT 部門，每個部門管理自己的身分提供者 (IdP)。的多身份提供者功能使這些部門能夠維護自己的身份驗證系統，同時允許用戶無縫存取。
3. 不同的使用者群組或網域
擁有不同使用者群組（例如，員工與承包商）或多個電子郵件網域的組織可以設定路由規則，根據網域或群組成員資格將身分驗證請求導向至對應的身分提供者。這支援差異化的存取策略和安全控制。
4. 支援多種身份驗證協議
支援 SAML 和 OpenID Connect (OIDC) 身分提供者，讓組織可以根據其現有的基礎架構和安全要求整合不同類型的身分提供者。
5. 增強安全性和合規性
透過啟用多個身分提供者 (IdP)，組織可以實施更強大的身分驗證機制，包括透過 Duo 等整合實現多因素身分驗證 (MFA)，並在不同的使用者群體中強制執行一致的安全性策略。
6. 簡化的使用者體驗
使用者可以使用各自身分提供者 (IdP) 提供的現有憑證進行驗證，從而提供統一的登入體驗，即使底層存在多個身分系統的複雜性。
雖然支援多種身分提供者 (IdP) 提供了靈活性，但這需要安全性和身分識別團隊之間仔細協調，以保持一致的安全策略並避免潛在的漏洞。
雙 MFA 與 SSO
Duo Access Gateway (DAG) 可以使用現有的本機或雲端目錄（例如 Active Directory (AD) 和 OpenLDAP）對使用者進行身份驗證。它還支援與其他身分識別提供者（如 Microsoft ADFS、Microsoft Azure、Okta、OneLogin、CAS 和 Shibboleth）的整合。這種靈活性使得組織能夠使用其現有的目錄基礎架構來實現具有 Duo MFA 的 Webex SSO。
Duo 在主目錄驗證之上提供了一個強大的身份驗證層。它作為身分提供者 (IdP) 使用 SAML 2.0 來強制執行雙重認證 (2FA)，然後再授予存取權限。Duo 會根據可設定的策略評估使用者、裝置和網路環境，以允許或拒絕訪問，從而增強安全性，而不僅僅依賴使用者名稱和密碼。Duo 還提供靈活的策略控制，例如對某些應用程式要求每次登入時都進行 MFA 驗證，而對其他應用程式則要求較少頻率的 MFA 驗證。
Cisco Duo 的優點包括：
-
增強安全性： 增加防釣魚的多因素身份驗證 (MFA) 以保護訪問，降低密碼洩露的風險。
-
靈活的政策： 允許對每個應用程式或使用者群組的身份驗證要求進行精細控制。
-
與現有目錄整合： 支援本地 AD、OpenLDAP、雲端目錄和各種 SSO 供應商，最大限度地減少基礎架構變更。
-
用戶便利性： 支援單一登入 (SSO)，使用戶只需登入一次即可安全地存取多個資源，從而減少密碼疲勞。
-
可信賴端點： 支援 Windows 和 macOS 用戶端的裝置信任，提高安全性。
-
自助註冊： 線上註冊和雙重提示可改善 MFA 設定過程中的使用者體驗。
雙重認證 (Duo MFA) 結合單一登入 (SSO)，利用現有目錄（如 Active Directory 和 OpenLDAP）或雲端身分提供者來驗證使用者身分。Duo 的角色是透過 SAML 2.0 整合強大的、策略驅動的第二因素身份驗證，在透過 SSO 增強安全性的同時保持用戶便利性。其優點包括：增強安全態勢、靈活執行策略、無縫整合以及更好的使用者體驗。
Cisco建議為使用者實施SSO。為了增強安全性，建議與 Cisco Duo 整合。
企業身分與存取管理 (IAM) 和單一登入 (SSO) 策略應在開始從 [此處應填入系統名稱] 過渡到 [此處應填入系統名稱] 之前部署。
功能
具備該服務所包含的所有核心功能。這包括許多企業級通話功能，這些功能已經存在多年。您可能無法看到功能和功能之間 100% 的對等性，但是，正如您在下圖中所看到的，關鍵的通話功能在 中可用。
除了眾多使用者功能外，該平台還包含一些核心系統功能。這些功能包括自動應答、呼叫佇列、呼叫駐留等。您可以在 服務 → 通話 → 功能 下查看所有可用的核心系統功能，如圖 Webex 通話核心功能所示。
自動語音應答
自動應答系統允許 24/7 實現來電處理的自動化，無需人工接聽每個來電即可高效處理來電。
自動應答系統會接聽來電，並為來電者提供一系列選項，供其選擇將電話轉接到哪裡。這可以是給某人、語音信箱或呼叫服務（例如呼叫佇列）。來電者使用手機撥號鍵盤從自動應答選單輸入號碼。
自動應答系統支援以下主要功能：
-
工作時間和非工作時間安排
-
假日排程
-
撥號選單選項，引導您的客戶前往他們需要去的地方
-
自訂問候語
-
按名稱撥號選項
-
來電轉接選項
-
控制中心分析和報告。
有關更多信息，請參閱 管理自動助理。
呼叫駐留
呼叫駐留功能使用戶能夠輕鬆地將通話 置於保持狀態 ，以便其他用戶在有空時輕鬆取回通話。它還允許接聽原始電話的用戶在通話保持期間撥打或接聽其他電話。
有兩種類型的呼叫停車服務可供選擇。 :
-
呼叫駐留直撥 - 允許任何使用者將呼叫駐留到其他使用者的分機號碼或管理員定義的呼叫駐留分機號碼。
-
呼叫駐留群組 - 允許指定使用者群組自動將呼叫駐留到為該群組定義的可用駐留目的地。這些目的地可以是群組成員的分機號碼或呼叫停車分機號碼。
根據配置和停車類型，用戶可以透過撥打 來找回呼叫。 *88+><extension of parked call>，按下與呼叫駐留分機關聯的線路鍵，或使用其 IP 電話上的軟鍵。
使用者可以設定召回選項，在指定時間後將已停放的呼叫召回給停放呼叫的使用者或備用使用者。
有關更多信息，請參閱 控制中心中的呼叫駐留管理。
來電代接
呼叫代接功能允許管理員定義一組使用者（成員），他們可以接聽其他成員的電話。這樣，當隊友忙碌而無法接聽來電時，用戶可以接聽電話。
同一組使用者必須位於同一地點。
用戶可以使用手機或辦公桌上的電話接聽電話。
-
:
-
支援視覺和音訊通知
-
來電通知
-
基於FAC的撥號 *98) 或通知彈出視窗接聽
-
多線路來電接聽通知。
-
-
桌上型電話：
-
來電通知
-
透過手機 LED 指示燈發出聲音提示和視覺通知。6821 型號僅支援音訊提示音。
-
當選擇的通知類型不是 無
-
-
僅對主線路發送來電接聽通知。
-
更多資訊請參閱 設定呼叫代接群組。
呼叫佇列
其核心功能包括純語音通話佇列，任何擁有專業版授權的使用者都可以成為呼叫佇列的一員，擔任座席或主管。此功能使用戶能夠有效率地與客戶互動。呼叫佇列支援呼叫中心的一些核心功能，例如語音佇列、回撥、技能或優先權路由、座席佇列管理、分析、報告等。
Cisco 呼籲整合 Microsoft Teams，讓客服人員可以直接透過 Microsoft Teams 用戶端存取呼叫佇列呼叫和功能。
呼叫隊列支援以下主要功能：
-
問候與留言（歡迎、安慰、輕聲細語等）
-
待話期間背景音樂
-
回撥
-
佇列路由策略（夜間服務、假日、轉送）
-
代理隊列 login/logout
-
代理佇列狀態管理
-
或桌上型電話支援
-
主管代理呼叫監控、指導、插話或透過功能存取代碼 (FAC) 接管
-
（管理員權限）適用於：
-
隊列管理
-
代理和隊列分析及報告
-
隊列、代理和主管管理。
-
有關更多信息，請參閱 配置呼叫隊列。
它具有客戶協助附加功能，可提供額外的呼叫佇列功能，並為代理商和主管提供更好的使用者體驗。有關呼叫佇列和客戶協助功能的比較，請參閱 Webex Calling 呼叫佇列和客戶協助功能比較。
群組搜尋
呼叫群組允許透過預先設定的呼叫路由模式，將呼入呼叫路由到特定的使用者群組。這樣可以確保電話由正確的使用者群組接聽，或前往語音信箱進行後續跟進。
呼叫群組和呼叫佇列之間的一個很大的區別是，呼叫在呼叫群組中不會排隊，因此，如果呼叫群組中沒有使用者可以接聽電話，則該電話將被斷開、發送到語音信箱或轉發到另一個號碼（使用者或服務）。
有關更多信息，請參閱 在 Control Hub 中管理狩獵組。
操作模式
運作模式功能可讓企業有效率地將呼叫路由到各種目的地（使用者、語音信箱、呼叫服務，如呼叫佇列）。呼叫的路由地點和時間取決於一天中的時間和一周中的日期安排，任何使用者都可以被授權管理這些模式（安排），以控制呼叫路由的變更。
例如，呼叫佇列的呼叫可以路由到另一個呼叫佇列，由不同時區的客服人員在非工作時間接聽電話；在工作時間內，呼叫可以路由到本地客服人員；在假日，呼叫可以路由到語音信箱，以便在客服人員返回辦公室後進行跟進。
授權使用者可以根據需要更改來電在特定時間段內的路由方式，在這些不同的呼叫轉移方案（模式）之間進行切換。這些用戶可以透過他們的…來管理這些模式。 6800/7800/8800 MPP 電話、9800 電話或在使用者中心 管理模式。
有關更多信息，請參閱 Webex Calling 中基於操作模式的呼叫路由。
傳呼群組
尋呼群組允許用戶發起單向呼叫，向一組用戶發送語音訊息。每個群組最多可包含 75 個目標用戶 and/or 透過撥打預先定義的號碼或分機號碼即可存取的工作區。
當使用者呼叫尋呼群組時，會同時呼叫群組內所有指定目標，此時呼叫者可以說出他們的留言，並在說完後掛斷電話。
有關更多信息，請參閱 在 Control Hub 中配置分頁組。
錄製檔
支援錄製使用者撥打或接聽的電話。這可能是出於品質保證、安全保障或訓練方面的需要。預設情況下，通話會被錄音，但如果需要其他錄音功能或合規性和監管要求，也可以使用其他第三方錄音提供者。
當使用該平台進行錄音時，所有錄製的通話都在其中進行管理。具有合規官角色的完整管理員可以播放和下載錄影。如果沒有合規官角色，管理員只能刪除錄音。
有關此功能的更多資訊以及第三方錄音列表，請參閱 管理 Webex Calling 的通話錄音。
單一號碼存取
單一號碼通話功能允許撥打用戶電話號碼的來電同時響鈴多個裝置。這包括其他座機以及手機。用戶還可以透過這些裝置撥打電話，並且可以在這些裝置之間推送和拉取電話。
有關此功能的更多資訊以及管理員如何在 中配置它，請參閱 配置單一號碼存取（隨時隨地辦公）。
如需了解使用者如何在 Webex 使用者中心（入口網站）中自行管理和設定此功能，請參閱 設定單號碼存取（隨時隨地辦公）。
語音信箱群組
語音信箱群組允許共用語音信箱，可以將其指派給使用者或用於呼叫路由功能。設定語音信箱群組的一些原因包括：
-
部門或工作小組通用語音信箱
-
為自動應答機或呼叫群組新增語音信箱選項
-
從呼叫佇列發送溢位呼叫
-
只需要語音信箱的用戶。
有關更多信息，請參閱 管理 Webex Calling 的共享語音郵件和入站傳真箱。
Webex 的「呼叫功能」頁面上列出了話務員控制台，但它是一個附加功能，需要購買話務員控制台許可證才能使用。
有關更多信息，請參閱 開始使用助理控制台。
有關所有功能（包括一些附加功能）的信息，請參閱 Webex Calling 按許可證類型提供的功能。
實施
網路整備
過渡到雲端的第一步是確保本地網路和雲端之間 可靠、安全的 網路連線。
由於大多數組織透過一個或多個 防火牆 或 安全設備連接到互聯網，因此驗證 所需的流量是否得到支援至關重要 。
網路和安全管理員必須從以下幾個方面來理解這些流程：
-
方向 （入站 vs 出站）
-
協定 （例如：SIP TLS、SRTP、HTTPS）
-
服務使用的 IP 位址範圍
-
必須開啟或允許的連接埠號碼 。
這樣可以確保企業防火牆、NAT 設備和其他網路基礎架構得到正確配置，以適應流量，同時維護企業安全策略。
有關所需流程（包括 IP 位址、連接埠和協定）的信息，請參閱 Webex Calling 的連接埠參考資訊。利用這些資訊配置現有部署中的防火牆、代理程式和其他網路基礎設施，以啟用網路流量。
對於雲端協作服務，建議採用從每個分公司或站點進行去中心化網路存取的方式。透過允許流量從本地流出，該模型：
-
減少往返延遲和抖動，提高整體通話質量
-
隨著更多用戶和網站過渡到新平台，可高效擴展。
-
與 SD-WAN 無縫協作，可將會話動態路由到最近的雲端入口點，以實現最佳效能。
- 允許根據用戶的公共 IP 位址追蹤用戶位置，這有助於媒體路徑分析和故障排除。
此外，各機構必須確保每個站點都有足夠的網路頻寬。頻寬的大小應根據預期的同時呼叫數、所選編解碼器（例如 Opus 或 G.711）以及訊號、重傳和成長的開銷來決定。這與 PPDIO 生命週期的準備階段相一致，並為遷移奠定了堅實的基礎。
初始設定
部署實施階段的初始設定小節是建立結構良好且易於管理的雲端呼叫環境的基礎。此階段包括一些關鍵任務，例如建立組織、取得和分配許可證，以及驗證和認領公司域名，以確保適當的使用者管理和安全。此外，它還包括提供許可證範本以自動分配使用者許可證，配置單一登入 (SSO) 以簡化使用者身份驗證和增強安全性，以及調整服務和用戶端設定以符合組織政策和使用者需求。完成這些初始設定活動可確保環境配置得當，以實現可擴展性、安全性和流暢的使用者體驗，為後續的部署和營運階段奠定基礎。
網域驗證
為了能夠識別在貴公司電子郵件網域上註冊的用戶，驗證您的網域至關重要。如果沒有進行網域驗證，用戶將被分配到消費者組織，這將使貴公司的用戶管理變得複雜。網域驗證是必要的步驟，它可以讓您的組織有效地認領和管理這些使用者。
請確保與使用者電子郵件地址關聯的所有網域均已驗證。域名驗證並非排他性的；同一個域名可以在多個組織中進行驗證。
有關管理域名的更多信息，請參閱 管理您的域名。
認領（轉換）現有用戶
成功驗證網域後，您可以將已註冊使用貴公司電子郵件網域的使用者新增至您的組織。此流程將所有使用者整合到一個組織框架下，從而實現集中管理和簡化管理。透過認領這些用戶，您可以確保公司對用戶帳戶擁有完全控制權，從而能夠有效地分配適當的授權、配置服務並提供必要的支援。這種統一的管理方法增強了安全性，簡化了使用者配置，並確保了整個組織對服務的一致存取。認領使用者還可以防止他們在外部或消費者組織中被管理，從而維護組織的完整性和對協作資源的控制。
有關認領用戶的更多信息，請參閱 將用戶認領到您的組織（轉換）用戶。
配置並測試目錄同步
為了實現無縫的使用者和群組管理，您可以將企業目錄中的使用者和群組（無論是 Microsoft Entra ID（以前稱為 Azure AD）還是 Microsoft Active Directory (AD)）同步到 。此流程可確保使用者身分和群組成員資格在您的環境中保持一致。
對於實施分階段部署的組織而言，在初始推廣階段控制和限制同步範圍至關重要。這樣可以最大限度地降低意外變更的風險，並允許在更廣泛採用之前進行有針對性的測試。
篩選同步使用者最有效的方法是利用目錄群組成員關係：
| 1 |
建立專用同步群組： 在企業目錄（Microsoft Entra ID 或 AD）中，建立一個專門用於同步的安全性群組（例如，同步群組）。 |
| 2 |
將目標用戶加入群組： 僅將您想要同步的使用者（例如試點階段的測試群組）新增至此群組。這樣可以讓你嚴格控制哪些人參與同步過程。 |
| 3 |
配置基於群組的篩選同步協定： 在 Directory Connector 或 Entra ID 設定中設定同步協定時，請將範圍設定為僅包含指定群組的成員使用者。
|
| 4 |
根據需要擴展群組： 隨著部署階段的推進，只需在同步群組中新增其他使用者或群組即可。同步範圍將自動擴大到包括這些用戶，從而實現可控和漸進式的推廣。 範例實施步驟：
參考： |
設定並測試單一登入 (SSO)
單一登入 (SSO) 透過允許使用者使用其企業憑證進行一次身份驗證並無縫存取來增強安全性並簡化使用者存取。支援與符合 SAML 2.0 標準的身份提供者 (IdP) 的 SSO 集成，包括 Microsoft Entra ID（以前稱為 Azure AD）、Active Directory (AD) 聯合解決方案和各種第三方身分提供者。
此時應該實施並測試已設計的 SSO 設定。
參考：
取得、提供和核實許可證
作為初始設定的一部分，必須採購、提供和驗證適當的許可證，以有效地啟用和管理服務。採購流程包括根據使用者角色和工作負載選擇授權類型，例如專業版、標準版和工作區版授權。許可證透過思科的軟體平台或合作夥伴產生和分配。採購和配置完成後，需要核實許可證數量是否正確。此流程可確保組織擁有已啟動並可用於部署的正確許可證。
作為初始許可設定的一部分，配置基於組織的自動許可對於簡化新使用者的許可證分配至關重要。這種設定允許在將使用者新增至組織時自動授予許可證，從而無需手動分配許可證。在組織層級配置自動許可時，您可以選擇要指派的服務並定義範圍，例如僅將授權套用至未來的用戶，或也包含現有使用者。
但是，如果您的部署計劃涉及在群組層級使用自動許可，您可以選擇不在組織層級分配許可證，以避免衝突或重複的許可證分配。透過群組層級自動許可，許可證是根據群組成員身分分配的。多個使用者群組的使用者將獲得所有適用群組分配的許可證。
必須在目錄同步完成後執行基於群組的許可證分配配置，以便同步群組存在並可用於許可證分配。
具體來說，自動許可證分配需要額外的配置詳細信息，例如用戶位置和電話號碼分配。使用者的工作電話號碼必須已輸入。 +E.164 格式已設定好，已預先配置，並已指派給有效位置，以便許可證自動啟動。如果這些條件不滿足，則不會自動為使用者提供服務，可能需要人工幹預。
總而言之，如果您想要進行廣泛的、組織範圍內的授權分配，請為新使用者設定基於組織的自動許可。如果您希望進行更精細的控制，或者每個群組有不同的許可需求，請在群組層級配置自動許可，避免在組織層級分配許可證，以防止重疊並確保正確的許可證管理。
Webex 通話服務設定
對全域服務設定進行全面審查和配置至關重要。
首先訪問並導航至設定部分。仔細檢查每個可設定選項，包括但不限於內部撥號配置、緊急呼叫參數、呼叫路由策略、語音郵件管理和設備預設設定。
調整這些全局設置，以反映貴組織的政策和設計決策。
此外，還要設定設定、使用者和應用程式模板。
試辦移民
在實施階段，執行試點遷移是驗證從到過渡的關鍵里程碑。此試點計畫涉及在一個或多個地點為平台提供代表性的使用者子集，以確保所選用戶群體反映多樣化的使用案例和組織角色。在用戶遷移的同時，包括語音郵件、自動應答、呼叫佇列和呼叫組在內的重要協作服務必須過渡到其等效版本，以維持業務連續性和服務功能。
試點遷移應利用思科提供的工具和第三方遷移實用程式的組合，這些工具和實用程式計劃用於更廣泛的組織部署，以確保在代表性條件下對流程、自動化工作流程和整合點進行徹底驗證。
本次試點部署的主要目標有兩個：首先，驗證並改善端到端過渡流程，包括使用者配置工作流程、資料遷移程序和終端配置；其次，全面驗證遷移服務在實際運作條件下的功能。
這種分階段的方法使專案團隊能夠在受控環境中識別和糾正任何技術或程序問題，收集使用者對新平台體驗的回饋，評估所選遷移工具的有效性，並在進行更廣泛的組織部署之前建立對遷移方法的信心。
本次試點階段所獲得的見解對於優化後續遷移浪潮、確保整個企業平穩過渡並降低風險至關重要。
採購公共交換電話網
若要為 [此處應填寫特定名稱] 取得 PSTN 服務，首先在 [此處應填寫特定名稱] 中選擇 PSTN 連線選項。
如果一個組織計劃維持混合雙呼叫控制（ 階段 1 在圖 分階段呼叫轉換：對於混合雲和雲端)，無論是暫時的還是永久的，他們都需要為本地 PSTN 部署一個或多個本地網關，以允許在端點之間進行呼叫。
如果最終目標是全面過渡到雲端（ 第 2 階段），包括 PSTN，那麼 PSTN 將需要 Cisco Calling Plan 或 Cloud Connect 選項。
與您選擇的服務提供者合作，訂購和轉移電話號碼，然後再進行配置。訂購電話號碼或發起端口訂單僅 required/possible 適用於本地 PSTN 和 Cloud Connect。對於 Cisco 通話計劃，一旦建立位置，即可在 Control Hub 內啟動訂購和連接埠轉移，且此流程適用於 Cisco 通話計劃可用的國家/地區。有關 Cisco Calling 套餐的更多信息，請參閱 Cisco 套餐入門。
作為 PSTN 實施的一部分，請確保您的服務提供者已為您的位置啟用入站和出站 PSTN 服務。此外，請執行測試呼叫，以驗證呼叫是否透過您選擇的 PSTN 連線正確路由。
配置位置
在向系統中新增使用者和設備之前，必須先配置呼叫位置。每個地點都必須輸入有效的街道地址。在美國和加拿大，該位址經過驗證，並由平台用於發送緊急呼叫的 PIDF-LO 位置資訊。
配置使用本地 PSTN 的位置時，需要相應地設定本地網關。在[此處應填入系統名稱]中，必須為每個本機閘道建立一個中繼和一個路由組，然後將路由組指派為該位置的 PSTN 選擇。Cisco 強烈建議始終選擇路由組作為 PSTN 選擇，因為這種方法可以方便地在將來添加額外的中繼，從而支援可擴展性和冗餘性。Cisco 還建議在每個 PSTN 中繼上啟用雙重身分和 P-Charge-Info 支持，因為這簡化了對撥出直撥或轉撥電話的計費方的識別。如果您的 PSTN 供應商使用不同的計費標頭，您可以將本地網關上的 P-Charge-Info 標頭中的資訊複製到所需的計費標頭中。
對於使用 Cloud Connect 或 Cisco Calling Plan 作為其 PSTN 選項的位置，只需在設定期間為該位置選擇相應的 PSTN 選項即可。如果該位置使用 Cloud Connect 或本地 PSTN，則需要新增在上一個步驟中訂購的電話號碼。如果您不希望號碼立即包含在呼叫路由中，可以將其新增為非活動號碼；您可以在稍後將這些號碼指派給使用者或功能時啟動它們。
務必為每個地點設定主號碼。主號碼可以分配給使用者或功能，例如自動語音應答系統。若要在該地點啟用語音信箱，請確保設定語音信箱引導號碼，也稱為語音入口網站號碼。
呼叫位置的其他設定包括配置緊急呼叫詳細信息，例如緊急回撥號碼、通知選項和增強的緊急呼叫功能。您還應根據每個地點的需要，檢查並調整錄音設定、語言偏好和設備配置。如果您的組織使用帶有企業重要號碼的縮短的站點間網路撥號，請記住在內部撥號設定中為位置配置唯一的站點代碼。最後，如果對外撥號需要撥出撥號數字，請務必在對外撥號設定中進行設定。在設定出站撥號數字時，思科建議啟用出站撥號數字強制執行，以確保一致性。
與本地呼叫控制系統集成
要與本地呼叫控制集成，需要設定中繼線、路由組、企業撥號計畫以及位置和全域設定。首先設定用於與本機呼叫控制系統互連的中繼線和本機閘道；只有在需要專用中繼線時才需要執行此步驟。如果現有的中繼和路由組足以滿足您的部署需求，則可以將其用於本地互連，而無需額外配置。
一旦中繼線和路由群組建立完畢，就可以開始建立企業撥號計劃，並將對應的路由群組指派給每個撥號計劃作為目標。當整合涉及透過不同中繼線連接的多個本地呼叫控制系統時，將需要多個撥號方案。務必確保這些撥號方案僅包含將呼叫路由到本地目的地所需的模式。
如果您的部署需要支援未知擴充路由，則應在位置層級啟用此功能。此外，當啟用未知分機路由時，必須在呼叫服務設定的 呼叫路由和場所之間 部分中指定最大未知分機長度。這確保了在整合環境中實現無縫的呼叫路由和基於分機撥號場景的正確處理。
分批遷移用戶
當您將使用者從 [系統名稱] 遷移到 [系統名稱] 時，可能無法同時遷移所有使用者。這可能是由多種原因造成的，包括但不限於網站或使用者數量、網站遷移所需時間等。 and/or 同一時間的使用者群、支援變更視窗的 IT 或網站資源有限、變更視窗持續時間、變更的複雜性等。
分階段遷移使用者時，確定哪些使用者需要在同一 批次中一起遷移至關重要。主要目標是將那些在呼叫服務和功能方面存在依賴關係的使用者一起遷移。您希望確保其所有呼叫功能（例如呼叫隊列）在過渡到新系統後都能像過渡之前一樣完全正常運作。
即使您實現了本機網關之間的呼叫互通，您也無法透過此連線拆分共用服務或功能。因此，您需要透過查看以下特徵來確定使用者之間的依賴關係：
-
使用 BLF 監控其他用戶
-
在同一狩獵飛行員、呼叫隊列等中
-
共用線路
-
使用電話接聽
-
使用相同的呼叫駐留號碼
-
內部通訊
-
行政人員/管理員。
例如，某個使用者是正在過渡到新版本的 Hunt Group 的成員。該用戶將過渡到 Hunt Group，並與 Hunt Group 的所有其他成員進行互動。因此，過渡完成後，Hunt Group及其成員可以在新平台上成功接聽電話。
當用戶因不同的通話服務和功能而連接到不同的用戶群組時，這會變得更加具有挑戰性。這將需要同時對多組用戶和一個呼叫服務進行遷移。
使用您在 準備 階段使用的 Migration Insights 工具或第三方工具的輸出結果，確定哪些使用者和功能應該分組在一起。此輸出結果應該用於制定遷移計劃，並能幫助您了解如何將需要一起遷移的使用者和功能進行分組。
批量用戶遷移的關鍵步驟如下：
-
確定要一起遷移的用戶
-
確認所有用戶均已登入
-
驗證所有使用者的 TN 是否存在
-
請核對目錄中電話號碼格式是否正確。
-
請確保使用者群組的許可和設定範本已正確設定。
-
驗證或配置使用者群組的所有呼叫服務和功能（在過渡之前或期間，視情況而定）
-
在公司目錄中，將使用者新增至已啟用通話的使用者群組。
-
利用工具－使用者和功能遷移工具 and/or 第三方工具
-
Disable/Delete user/device 電話號碼查詢和呼叫 features/services 過渡之後。
遷移完一組用戶後，測試一部分用戶，以驗證其所有呼叫功能和服務是否正常運作。如果呼叫佇列、呼叫群組等呼叫功能會隨使用者群組一起遷移，則測試這些呼叫服務的功能是否正常。
工作區
在[此處原文缺失]，工作區指的是可以分配設備、分機和使用者的共享位置（例如會議室、小型討論空間或共享辦公桌）。與傳統的統一通訊管理 (Unified CM) 電話不同，工作區具有以下特點：
-
以位置為中心：與物理空間相關。
-
設備靈活：可配備一個或多個設備（桌上型電話、白板等）。
一旦確定了過渡到新系統所需的工作區，就可以在「設備」下添加它們。每個工作區都需要分配設備，如果它們已經在 Unified CM 中，則需要重設或重新配置。可啟用或停用語音郵件、呼叫轉移和呼叫代接等功能，並可依需求套用視訊通話、呼叫駐留和行動策略。透過撥打內部和外部電話、測試視訊、會議和行動功能來測試每個工作區。最後，告知使用者有關工作空間設備和預訂的任何適用流程。
有關工作區的更多信息，請參閱 工作區。
供應設備
目前已註冊的手機需要遷移到新系統，作為雲端遷移的一部分。為了盡可能簡化遷移過程，並將失敗的可能性降到最低，思科建議同時遷移實體站點或部門。但是，由於功能依賴性，您可能需要分批遷移使用者。有關更多詳細信息，請參閱 “分批遷移用戶 ”部分。
任何需要從中遷移過來的支援電話都需要配置為使用者或工作區，實體電話需要重新配置才能註冊。此外，7800 和 8800 系列電話需要將其韌體從企業韌體升級到多平台電話 (MPP) 韌體。該過程包括在載入註冊所需的 MPP 韌體之前載入過渡固件。此外，還需要相應的遷移許可證。思科在過去幾年中改進了這個流程，讓您更容易將企業韌體電話升級到 MPP 韌體。有關完成韌體升級的步驟的更多信息，請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
除了本文中概述的步驟之外，還有一個內建工具 將您的電話遷移到 Webex Calling，您可以使用該工具幫助您將 7800 和 8800 電話從企業版韌體遷移到 MPP 韌體。該工具還允許您將手機新增至相應的使用者或工作區，並將其分配給相應的使用者或工作區。有關工具使用的更多信息，請參閱 遷移您的手機。
對於已註冊的 9800 系列手機，上述韌體遷移要求不適用。這些手機運行 PhoneOS，該系統同時受到 和 的支援。要將這些電話遷移到 Webex Calling，您需要將它們新增至 Webex Calling，將它們指派給使用者或工作區，然後將電話恢復原廠設定。PhoneOS 註冊啟動順序 下圖顯示了 PhoneOS 的啟動順序，以及手機添加到 [此處應填寫系統名稱] 後如何註冊，即使手機仍在 [此處應填寫系統名稱] 上配置 and/or DHCP 選項（例如 - 150）正在使用中。
支援將 PhoneOS 設備恢復出廠設置，從而實現零接觸入駐。管理員可以透過 CUCM 管理頁面遠端將 9800 和 8875 電話恢復出廠設置，從而無需實體存取電話即可完成入駐。此功能自 2025 年 9 月 9 日起在設備包中支援：
-
CUCM v15 - 統一通訊管理器版本 15
-
CUCM v14 - 統一通訊管理器版本 14。
有關 9800 系列註冊流程的更多信息，請參閱 註冊流程。
除了 Cisco IP 電話之外，可能還需要設定其他設備 ，例如類比電話適配器 (ATA)、無線 (Wifi、DECT) 電話、視訊設備、語音閘道以及第三方設備和電話。許多此類設備不像 IP 電話那樣有韌體升級途徑，無法從企業韌體過渡到雲端韌體。因此，您需要在控制中心配置這些設備。有些設備無法直接過渡，需要用同等型號的設備來替代（例如ATA）。 191/192) 還有一些需要手動重新配置。 and/or 軟體變更。
-
語音網關 - 若要遷移本機網關，請參閱 遷移本機網關。
有關在 Control Hub 中配置語音網關 VG400、VG410 或 VG420 的更多信息，請參閱 本地網關
-
類比電話適配器 (ATA) - 若要開始使用 Cisco ATA 191 和 192，請參閱 Cisco ATA。
-
Wifi 無線電話 - 若要整合無線電話 840 和 860，請參閱 整合 Webex 無線電話。
-
DECT 無線電話 - 若要開始使用您的新 Cisco IP DECT 6800 系列，請參閱 Cisco IP DECT。
若要在 Control Hub 中建置和管理數位 DECT 網絡，請參閱 管理 DECT 網路
有關 Cisco IP DECT 6800 的更多信息，請參閱 部署指南
-
第三方設備和手機 -與 第三方供應 商合作 device/phone 要求以及遷移或替換這些要求的過程以提供支援。
設定功能
任何所需的通話功能都需要在過渡之前或期間進行設定。如在「分批遷移使用者」部分所討論的，當使用這些功能的使用者進行遷移時，需要配置和遷移呼叫功能。
有關如何配置各項功能的詳細信息，請參閱相應的配置幫助文章。
驗收測試
驗收測試確保遷移後的環境符合功能要求，按預期運行，並在所有通訊工作流程中提供無縫的使用者體驗。此驗證過程涉及多個方面，涵蓋從用戶配置和號碼分配到高級呼叫功能的運行性能等各個方面。
本節提供範例並重點介紹驗收測試期間需要考慮的關鍵方面；但是，它並非旨在作為詳盡或全面的檢查清單。
用戶配置和號碼分配
驗收測試的一個基礎面向是驗證所有使用者是否已在系統中準確、完整地配置。這需要對來源目錄和新建立的用戶群進行徹底比較，以確保每個用戶帳戶及其相關屬性（例如分機號碼和直接撥入號碼 (DID) 分配）都已正確遷移。配置的完整性不僅對第一天的運作至關重要，而且對後續的管理和支援也至關重要。
號碼分配驗證包括確認每個使用者都分配了正確的分機號碼和外部號碼，並且這些號碼在內部（網內）和外部（PSTN）呼叫流程中都能正確路由。必須檢查是否有重疊、缺少分配或配置錯誤，這些都可能導致呼叫路由錯誤或服務中斷。
PSTN通話流程與來電顯示
一個完善的驗收測試程序必須包含 PSTN 通話流程的端對端驗證。這包括呼入和呼出兩種情況。對於 PSTN 來電，測試團隊應確認通話是否已送達至預期的終端，無論是個人使用者、呼叫佇列、呼叫群組或自動話務員。必須成功撥出 PSTN 電話，尤其要注意正確傳遞和顯示來電顯示訊息。這包括確保按照組織政策和監管要求，向外部接收者顯示正確的來電者姓名和號碼。
測試還應涵蓋故障轉移場景，例如處理無法存取的端點或網路中斷。這有助於確認回退機制和備用路由是否正常運行，從而維持服務的連續性和可靠性。
網內呼叫流程
內部或網內呼叫流程構成了企業通訊的骨幹。該領域的驗收測試驗證了組織內使用者之間的通話是否正確路由，以及呼叫轉移、保持、轉送和會議等功能是否如預期運作。必須確認撥號方案的完整性、分機之間的連接性以及對組織呼叫策略的支援。
使用者呼叫處理和功能驗證
驗收測試的一個重要方面是驗證使用者如何使用 和支援的桌面電話處理通話。此流程的重點是確認日常通話工作流程是否直觀可靠，以及使用者是否能夠無縫存取其角色所需的核心功能。測試應評估使用者撥打和接聽電話、管理保持和恢復功能以及執行盲轉和諮詢轉接的便利程度。此外，還必須確認呼叫轉移、電話會議和其他進階功能（如呼叫保留和恢復或啟用「請勿打擾」功能）是否可用且運作順暢。
應評估使用者體驗的清晰度和回應速度，並考慮使用者如何與通話記錄、語音郵件和整合目錄進行互動。還應特別注意在設備之間轉移通話的功能，以及在應用程式或實體電話上有效使用通話控制功能的功能。最終目標是確保遷移後最終使用者體驗的一致性、高效性，並能充分滿足組織的溝通需求。
呼叫佇列：代理人和主管經驗
呼叫佇列常用於處理大量來電的情況。這裡的驗收測試著重於以下幾個方面。首先，應驗證呼叫是否依照配置的佇列邏輯（例如輪詢、最長空閒或同時振鈴）指派給座席。必須檢查座席桌面上排隊呼叫的顯示方式是否清晰易用，以確保座席能夠有效率地接聽、保持和轉接通話。
對於主管人員來說，應該評估桌面體驗的功能，例如即時監控、呼叫介入以及佇列效能分析或洞察。這包括但不限於驗證提供有關呼叫分配、座席活動和佇列指標的可操作資料的儀表板和報告工具。
搜尋群組：呼叫分配
呼叫群組是將呼叫指派給預定義使用者集的關鍵機制。驗收測試需要確認呼叫是否根據配置的尋呼演算法路由到群組成員，以及是否依照設計處理溢位、轉送和無應答情況。確保群組成員資格和呼叫路由行為與先前建立的行為一致，對於營運一致性和使用者滿意度至關重要。
自動語音應答：公告和選單操作
自動應答器代表了自動呼叫處理的第一道防線。測試必須涵蓋公告的播放、錄製問候語的準確性以及選單樹的正確操作。選單選擇應能可靠地將來電者路由到相應的部門、個人或外部號碼。測試還應包括無效或逾時場景，以確認呼叫者是否收到清晰的指導或按預期被重定向。
語音信箱操作
最後，語音信箱功能對使用者體驗至關重要。驗收測試應驗證語音信箱是否已正確分配，以及是否可以從組織內部和遠端存取。必須確認具備記錄、檢索和管理訊息的功能，以及通知送達功能。
最佳化
PSTN 遷移到 Cloud Connect
一旦所有終端和使用者都遷移到雲端呼叫，Unified CM 的唯一目的就是充當 PSTN 閘道和本地網關之間的傳輸通道。使用 Cloud Connect 作為所有 Webex Calling 用戶的 PSTN 存取方式，從系統中移除 PSTN 網關和本地網關，具有許多優勢，包括降低成本和提高可靠性。若要將本機 PSTN 存取遷移到 Cloud Connect，請依照下列步驟操作：
-
Cloud Connect 用於合作夥伴選擇。
請參閱 Cloud Connect 合作夥伴列表，並從中選擇適用於您組織所在地的合作夥伴。
-
Cloud Connect 用於驗證。
在將 PSTN 存取點切換到 Cloud Connect 之前，應先驗證並確認透過選定的 Cloud Connect 合作夥伴與 PSTN 的連線。為此，需要配置一個測試地點，並在該測試地點配置一些測試使用者。然後，將此測試地點的 PSTN 存取設定為 Cloud Connect 合作夥伴，之後使用測試電話驗證 PSTN 連線。驗證成功後，即可取消測試地點的配置。
-
號碼轉移。
為了準備切換到 Cloud Connect，需要對目前分配給終止於此的 PSTN 中繼線的所有號碼下達連接埠訂單。所有號碼都需要轉移到 Cloud Connect 合作夥伴處。為了保持不同地點之間的可及性，所有地點的所有號碼都需要同時進行攜號轉網。
-
切換到 Cloud Connect 合作夥伴。
在切換之日，所有地點的 PSTN 存取都需要設定為雲端連接 PSTN 供應商，並且應驗證入站和出站連線。
如設計章節的 PSTN 部分所述，客戶也可以選擇在過渡開始時將其 PSTN 接取遷移到 Cloud Connect，以便使用 PSTN 中繼進行混合部署。有關更多信息，請參閱 混合 Webex Calling 部署的 PSTN 中繼。在這種情況下，過渡期間 PSTN 存取是透過本地網關進行的，並且在將所有使用者遷移到本地網關之後，除了停用本地網關之外，沒有其他與 PSTN 相關的遷移步驟。
優化本地基礎設施
一旦所有使用者都已遷移到雲端註冊，並且所有端點都已遷移到雲端註冊（或已停用），現在雲端呼叫正在使用，請更新相應的本地基礎架構。基礎設施更新包括：
-
從本機 DNS 伺服器中刪除本機呼叫控制和訊息 DNS SRV 記錄，包括 cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. 這些 SRV 記錄不再用於客戶端服務發現。
-
從公用 DNS 系統中刪除與邊緣相關的 DNS SRV 記錄，包括 collab_edge._tls.<domain>. 這些 SRV 記錄不再是客戶端發現協作邊緣服務所必需的。
-
更新所有相關的 DHCP 作用域，移除選項 66 和選項 150。 TFTP/boot 伺服器位址。這些作用域不再用於端點呼叫控製配置的發現和下載。
-
Update/remove 本地適當的撥號對等體 Gateway/CUBE 此路由調用與 Unified CM 之間的通訊。這些撥號對等體不再是本地呼叫路由所必需的。
-
刪除或移除所有叢集節點虛擬機 and/or 伺服器. 根據需要重新分配計算資源和硬體。這些資源不再用於呼叫控制和邊緣服務。
-
刪除或移除所有叢集節點虛擬機 and/or 伺服器. 根據需要重新分配計算資源和硬體。語音郵件和統一訊息服務不再需要這些資源。
-
清理：將 PSTN 存取遷移到雲端連接 PSTN 後，可以停用 PSTN 中繼線、PSTN 閘道和本機閘道。
-
對於任何現有的本機 E911 解決方案，刪除已遷移到的任何位置或號碼，並在完全過渡完成後，刪除應用程式虛擬機器或伺服器。根據需要重新分配計算資源和硬體。這些資源不再用於緊急呼叫和定位服務。
-
應將屬於已遷移使用者的 DN 放置在隱藏分區中，以避免呼叫路由失敗，並確保所有 CSS 都能優先存取相同 DN 的雲端路徑。
-
當發生變更時，更新 Horizon Mobility 中的實體可調度位置和網路元素。需要更新的常見活動包括：
-
網路交換器更換
-
無線接入點更換
-
DHCP作用域變更
-
建築物內部的物理變化（如果決定進行） cubical/office)
-
建築物內部辦公空間的實際擴張或收縮。
-
利用分析和故障排除
提供全面的分析和故障排除功能，幫助您視覺化和追蹤部署情況。這些功能包括媒體品質、詳細通話記錄、呼叫佇列、呼叫組和自動應答分析。圖 [] 顯示了媒體品質分析的範例 媒體品質分析。
在故障排除中，可以使用以下信息查看每次呼叫，其中包含有關關鍵媒體品質和信令相關問題的詳細信息，以幫助確定媒體問題以及呼叫失敗的原因，如圖 媒體品質故障排除所示。
故障排除功能還可以與其他思科產品（如 ThousandEyes 和 Meraki 交換器）集成，從而在 Control Hub 中提供更豐富的集成體驗。有關使用 Webex Calling 分析和故障排除的更多信息，請參閱 Control Hub 中的 Webex Calling 通話故障排除。
簡介
在開始之前
本指南適用於有設定和管理 Cisco Unified Communications Manager (Unified CM) 和 Cisco 終端機（包括 IP 桌上型電話、視訊設備和 Jabber 軟體用戶端）經驗的團隊或個人。本文檔中提供了指向產品和支援文件的鏈接，以提供協助。
本文檔僅關注從 Unified CM 到 Webex Calling 多租戶的過渡。本文檔中的術語 Webex Calling 始終指 Webex Calling 多租用戶。
在開始從 Unified CM 遷移到 Webex Calling 之前，必須全面了解 Webex Calling 解決方案及其個別元件。成功遷移需要熟悉 Webex Calling 的架構、服務模型、部署選項和相關功能，以便正確對應現有的 Unified CM 工作負載並設計有效的過渡計畫。
要製定有效的過渡策略和營運準備，必須透徹了解以下 Webex Calling 元件。
-
Control Hub
-
目錄和使用者配置
-
Webex通話平台
-
支援的呼叫端點
-
PSTN 連線選項
-
Webex Calling撥號方案和號碼管理
-
安全性和合規性功能。
更多信息，請參閱 Cisco Webex Calling 首選架構。
本指南將重點放在轉型生命週期中可使用的工具和流程。然而，從本地通話系統 Unified CM 過渡到新的雲端通話平台 Webex Calling 可能是一項重大工程，並可能面臨業務、技術和複雜方面的挑戰。為了幫助您克服這些挑戰，思科提供了一些不同的選擇來協助您完成您的轉型之旅。請務必查看 企業雲端呼叫 - 呼叫遷移 中的信息，以了解每個選項以及每個選項如何幫助您進行自己的遷移。
-
Webex遷移工具： Control Hub 內建了自助式免費工具，可簡化您向 Webex Calling 的轉型。
-
認證的移民服務提供者： Cisco 已驗證了開發遷移解決方案的軟體和工具供應商，這些解決方案可協助 Webex 合作夥伴和客戶進行複雜和大規模的遷移。這些解決方案可以幫助簡化、管理和加速向 Webex Calling 的過渡。
-
Webex 設定助手： 思科主導的遷移服務，指導客戶和合作夥伴完成 Webex Calling 的部署和配置，這是將 Unified CM 使用者和服務成功遷移到 Webex Calling 所必需的。
概觀
隨著雲端交付協作服務的成長，越來越多的客戶希望將現有的協作工作負載遷移到雲端，因為雲端服務具有降低整體擁有成本、簡化管理、持續功能交付、提高規模和增強可靠性等優點。當客戶考慮從本地部署過渡到雲端協作服務時，了解過渡過程涉及哪些方面以及過渡所需的步驟至關重要。
本文檔的目的是為希望從本地統一 CM 過渡到雲端 Webex Calling 的客戶提供部署指導。本部署指南假定讀者對 Unified CM 和 Webex Calling 之間的呼叫轉換有基本的了解，包括進行此轉換時會發生哪些變化，以及將呼叫工作負載從本地遷移到雲端時有哪些不同之處。在繼續操作之前，請確保您已查看並熟悉 過渡圖中提供的資訊。這份過渡路線圖文件提供了有關此次過渡期間的變化和差異的資訊。
如圖 所示，本地協作架構：呼叫控制和遠端存取，典型的本地部署包括網路上的不同協作基礎架構元件、呼叫控制平台、邊緣平台、硬體和軟體終端，在某些情況下甚至包括會議和日程安排平台。在思科架構中，這包括用於呼叫控制的統一呼叫管理 (Unified CM)、用於遠端存取和企業對企業 (B2B) 邊緣服務的 Expressway 以及思科會議伺服器 (Cisco Meeting Server)。 / Cisco Meeting Management 用於本地會議，Unity Connection 用於語音訊息傳遞，以及面向使用者的硬體（Cisco IP 電話、Cisco 桌面和會議室視訊系統）和軟體（Cisco Jabber）基於 IP 的終端。這些元件在某些環境中可能會略有不同，但這是本文檔其餘部分所描述的過渡的起點。
圖 所示的架構為本地協作架構：呼叫控制和遠端存取 基於 Cisco Collaboration Enterprise 本地部署的首選架構 (PA)。有關企業本地部署的更多信息，請參閱 Cisco 協作首選架構。
前：本機呼叫基礎架構元件 表列出了在過渡到雲端 Webex Calling 之前本地架構的關鍵要素。
| 產品 | 說明 |
|---|---|
| Unified CM | 本地呼叫控制提供設備註冊和呼叫路由服務 |
| 思科 Expressway-C/E | 邊緣基礎設施提供行動和遠端存取 (MRA) 以及企業對企業 (B2B) 功能，使遠端端點能夠從組織外部安全連接。Expressway 成對部署，提供外部端點防火牆穿透功能。 |
| Cisco Meeting Server (CMS)、Cisco Meeting Management (CMM) 和 Cisco Telepresence Management Suite (TMS) | 提供本地語音、視訊和網路會議基礎設施，支援多點會議、會議管理和日程安排功能。[Optional] |
| Cisco Unity Connection | 提供語音郵件和統一訊息功能的本地語音訊息平台。[Optional] |
| Cisco Desk、Cisco Room、Cisco Board、Cisco IP Phones 與 Cisco Jabber | 已註冊到 Unified CM 並提供語音和視訊通話功能的基於 IP 的設備 |
如圖 所示，過渡決策：對於擁有 Unified CM 和桌面及視訊 IP 端點的本機呼叫控制的客戶，他們可以選擇將架構過渡到 Webex Calling雲端架構。
該決定需要根據客戶的功能需求來做出。有以下需求的客戶在做出決定前應仔細考慮，並最終可能決定將呼叫控制保留在本地：
- Webex Calling 不支援的手機型號
- 與其他本地系統或解決方案的複雜或眾多集成，尤其是在難以用 Webex Calling 複製這些集成，或沒有等效替代解決方案的情況下，會非常棘手。
- 複雜的撥號方案、高度細化的服務等級或兩者兼有
- 受限、有限或不可靠的網路存取
- 嚴格的資料隱私和所有權政策
- 本地或境內媒體錄製和儲存的合規性要求
- 第三方集成，但沒有可行的替代 Webex Calling 集成方案
- 聯絡中心集成，其中聯絡中心集成尚未遷移到雲端。
本文檔主要針對已部署 Unified CM 呼叫控制的客戶，旨在協助他們了解啟用 Webex Calling 部署的一般步驟、注意事項和要求，如下一節所述。
核心組件
此次遷移的目標架構包含多個新元件。這包括用於基於雲端的通話的 Webex Calling 服務、Webex App、用於身分整合的 Cisco Directory Connector 和用於 PSTN 存取的本地網關 (LGW)，以及本地到雲端的通話整合。Cisco 通話計畫或由 Cloud Connect for Webex Calling 合作夥伴提供的雲端連線 PSTN (CCP) 是 PSTN 存取的其他選擇。
如圖 所示，之後：Webex Calling 架構，新元件（Webex Calling、目錄連接器、本機閘道和生存能力閘道）會被加入到現有的本機部署。
後：雲端呼叫基礎設施元件 表列出了過渡到 Webex 後架構的新元素。
| 產品 | 說明 |
|---|---|
| Webex 通話 | 基於 Webex 平台的雲端通話服務，提供終端機註冊和呼叫路由功能。 |
| Cisco 目錄連接器 | 執行在 Windows 網域電腦上的 Windows 應用程序，提供企業本機 Active Directory 和 Webex 組織的身份儲存之間的身份同步。 對於從本機 Active Directory 遷移到 Entra ID 的客戶，與 Webex 而不是 Cisco Directory Connector 的身分整合使用 Entra ID Wizard 應用程式。 |
| 本端閘道 | 本地網關可作為客戶本地統一通訊網路和 Webex Calling 雲端之間的橋樑。它可以部署在本地或由合作夥伴託管，為雲端註冊端點提供 PSTN 訪問，以及 Unified CM 註冊端點和雲端註冊端點之間的呼叫整合。Cisco IOS-XE 整合服務路由器（ISR 1100 與 4000 系列）、Cisco Catalyst 8200/8300 Cisco Catalyst 8000V Edge 軟體系列以及各種經過認證的第三方會話邊界控制器 (SBC) 可用作分階段遷移方法的 LGW。 |
| 生存能力閘道 | 生存網關 (SGW) 是一個基於本機網路 IOS-XE 的網關，可在網路中斷期間為現場 Webex Calling 端點提供回退呼叫服務。 |
| Cisco 通話計劃，Webex 通話雲端連接 | Cisco Calling Plan 和 Cloud Connect for Webex Calling 是 Webex Calling 端點的基於雲端的 PSTN 存取選項。PSTN 存取由雲端 PSTN 供應商提供，無需任何本地設備。 |
| Webex 應用程式 | 用戶端應用程式運行於桌面作業系統（Windows、Mac）或行動作業系統（Android、iOS）上，並直接註冊到 Webex Calling 平台以實現通話功能。 |
PPDIO流程概述
PPDIO 流程代表 準備、規劃、設計、實施和最佳化。這是思科提供的結構化方法論，指導專案從初步評估到持續改進，確保高效、成功的部署或遷移。
PPDIO概述
-
準備： 評估當前環境，收集需求，並協調利益相關者，以建立堅實的基礎。
-
方案： 制定詳細的專案計劃，包括時間表、資源和風險緩解策略。
-
設計： 根據業務和技術需求，設計目標解決方案。
-
實施： 根據設計執行部署或遷移，並驗證功能和效能。
-
最佳化: 實施後，透過監控效能、改進配置以及利用自動化和整合工具，不斷改進解決方案。
使用 PPDIO 進行 Unified CM 到 Webex Calling 的遷移項目
從 Unified CM 過渡到 Webex Calling 時，PPDIO 流程提供了清晰的路線圖，以確保平穩高效的過渡：
準備
-
評估現有的統一配置管理環境和遷移準備情況
-
收集有關使用者、裝置、網路和依賴關係的詳細數據
-
收集位置詳細信息，包括緊急響應地址、用戶數量、互聯網接入情況、公共交換電話網路接入情況
-
識別風險並明確專案範圍，以協調所有利害關係人。
方案
-
制定包含批次計畫、資源分配和時間表的全面遷移計畫。
-
定義諸如設備韌體升級、許可證配置和用戶入職等任務
-
與思科及合作夥伴協調遷移時間，以最大程度地減少中斷。
設計
-
將目前 Unified CM 設定、撥號方案和使用者設定檔對應到 Webex Calling 的對應項
-
設計 Webex Calling 環境，包括 PSTN 策略（臨時和最終方案）、位置、使用者角色以及整合點，例如本地網關 (CUBE) 和目錄同步。
-
制定在遷移過程中 Unified CM 和 Webex Calling 同時運作的共存方案。
執行
-
使用 Control Hub 遷移工具以及第三方工具來執行裝置韌體模式變更、功能配置和使用者遷移。
-
利用 Webex API 進行批量操作和配置，以簡化大規模遷移和配置。
-
執行許可證配置、設備註冊和配置更新
-
透過測試和運行驗證來確認遷移是否成功。
最佳化
-
持續監控 Webex Calling 的效能與使用者體驗
-
根據營運數據和回饋改進配置和工作流程
-
利用自動化和整合功能來提高效率和可擴展性
-
根據需要停用舊版統一配置管理元件，並為日常營運提供持續支援。
這種增強型 PPDIO 方法可確保從 Unified CM 到 Webex Calling 的可控、透明和高效遷移，利用 Cisco 的工具、API 和合作夥伴生態系統來維持業務連續性並提高協作能力。
PPDIO回饋迴路
圖 中所示的高階概述在執行 PPDIO 時進行了迭代，展示了從 優化 階段到 準備 階段的單一回饋迴路。這意味著，在初步實施之後，仍有持續改進的機會。每次優化週期都可以發現新的需求或需要改進的領域，這些需求或領域可以透過後續的專案或計劃來解決。這些單獨的專案又各自遵循既定的 PPDIO（準備、規劃、設計、實施、最佳化）生命週期。這種迭代方法確保系統始終與不斷變化的業務目標和技術進步保持一致，從而培養持續改進和適應的文化。
在 PPDIO 流程的執行過程中，後期階段的調查結果通常需要重新審視並可能修改早期階段所做的決定。例如，在實施階段遇到的問題，例如發現設計歧義或缺失的細節，可能會揭示某些方面在設計階段沒有充分解決。在這種情況下，必須回到相關的先前階段來解決這些問題，然後再繼續進行。如圖 所示，統一配置管理輔助 PPDIO 流程 中的這種迭代反饋機制確保解決方案得到徹底驗證和完善，最終有助於實現更穩健、更有效的部署。
從 Unified CM 過渡到 Webex Calling 時，PPDIO 流程的每個階段都可以從現有 Unified CM 環境中收集的資訊中獲益匪淺。例如，可以從目前的統一 CM 配置中提取使用者、電話號碼、呼叫功能和撥號計劃組件的全面清單。這些數據是對利害關係人直接提供的資訊的補充，有助於簡化規劃和設計活動。利用合適的工具實現資料擷取和分析的自動化，不僅可以提高準確性，還可以加快整個流程。透過利用現有部署的洞察，向 Webex Calling 的過渡可以比傳統的全新實施更有效率地執行，同時仍遵循結構化的 PPDIO 方法。過程如圖 統一 CM 輔助 PPDIO 過程所示。
遷移方法
在規劃從本地統一內容管理過渡到 Webex Calling 時，您需要確定如何著手進行此過渡過程。首先，您需要決定遷移方式是採用 閃速 （一次全部遷移）還是 分階段 （分批遷移） users/devices 在較長一段時間內）。
執行 快速 遷移可以最快遷移所有使用者和裝置。透過此方法，您可以同時將所有使用者和裝置從本機 Unified CM 遷移到 Webex Calling。從本質上講，它為所有用戶和設備提供了一個統一的遷移視窗。遷移完成後，您的所有使用者和裝置都會遷移到 Webex Calling 平台，並且您的所有 Unified CM 基礎架構都可以停用。然而，由於呼叫部署的規模和範圍，許多組織無法採用這種方法。
第二種方法是 分階段 遷移。大多數組織都會採用這種方法，因為它能更好地控制、管理和擴展遷移規模。此外，它也更適合大規模統一通訊部署。 and/or 跨多個區域部署。因此，本文檔重點介紹 分階段實施的過渡方法 ，該方法包含兩個過渡步驟。
如圖所示 分階段呼叫轉換：混合雲，第一個過渡階段（階段 1）將實現具有雙重呼叫環境的共存部署。在此階段，部分使用者、裝置和軟體用戶端將過渡到 Webex Calling，而其他使用者、裝置和軟體用戶端仍將使用本機 Unified CM 呼叫控制。最終過渡階段（第二階段）將形成一個純粹的雲端通話環境，其中所有使用者、裝置和軟體用戶端都已完全過渡到 Webex Calling 平台。
組織完全過渡到雲端呼叫所需的時間取決於其目前的部署情況。在某些情況下，組織可能會進行初步過渡，並在共存雙呼叫控制階段（階段 1）保持較長時間（數月甚至數年），而在其他情況下，組織可能會在很短的時間內（數週或數月）完全過渡到 Webex Calling（階段 2）。本文檔旨在涵蓋兩個階段（第一階段－共存，第二階段－完全過渡）。
有些組織可能會無限期地維持雙重呼叫控制共存部署，而沒有計劃完全過渡到雲端呼叫。
第二個需要考慮的問題是如何將使用者、裝置和軟體客戶端從本地呼叫控制過渡到雲端呼叫控制。建議採用三階段過渡方案。下圖 建議的 3 階段轉變 將此方法分解為 3 個階段。
遷移前： 此階段的重點是為遷移做好 Webex 和 Unified CM 環境的準備。這不是關於具體的規劃或配置，而是專注於完成現在可以在任何 Webex Calling 遷移專案開始之前完成的活動。目標是為兩個環境的遷移奠定基礎。
移民準備： 在這個階段，我們將開始為遷移到 Webex Calling 做準備。此處需要審查和更新業務和技術需求。不要只是簡單地將目前使用 Unified CM 部署的內容進行 遷移 ，而是利用 Webex Calling 的強大功能，重新定義貴公司現在和將來所需的業務和技術要求。此外，在這個階段，您將完成設計、配置規劃和遷移。 planning/schedule.
遷移（部署和停用）： 在這個階段，用戶、裝置、電話號碼和軟體客戶端將實際遷移。如上所述，此階段可以一次完成（閃切），也可以分多個變更視窗完成（分階段切割）。最終用戶採納計劃、培訓和溝通至關重要，這樣您的用戶才能了解變化、如何使用新的通話平台以及何時進行更改。最後一步是停用所有不再使用的本地統一通訊基礎設施。
遷移前階段包含一些活動（必需的、建議的和可選的），您可以立即開始進行這些活動。建議儘早完成這些工作，最好是在專案開始之前完成。有些活動可能需要更長時間才能完成，因此儘早開始這些活動將有助於簡化您的實際遷移專案。
下圖 遷移前活動 突顯了與 Webex Calling 遷移相關的五類具體活動。
準備
業務和技術要求
在計劃從 遷移到 時，在計劃階段徹底收集技術和業務需求至關重要。這一步驟確保遷移與貴組織的營運目標和技術能力保持一致，從而最大限度地降低風險和中斷。
為什麼收集需求很重要：
-
使業務目標一致： 了解業務需求有助於客製化遷移方案，以支援關鍵工作流程、使用者體驗和成長計畫。
-
確保技術相容性： 儘早確定技術需求可以避免與現有基礎設施、網路和終端機出現整合問題。
-
有助於資源規劃： 明確的需求有助於準確估算時間、成本和所需資源。
-
降低風險： 及早發現潛在問題可以採取積極主動的解決方案，從而減少停機時間和業務中斷。
業務需求
典型的業務需求包括：
-
待遷移的使用者數量和位置
-
所需功能和服務（例如，呼叫路由、語音信箱、電話會議、自動應答、呼叫佇列）
-
合規和安全政策
-
預算限制和成本預期
-
使用者培訓和支援需求
-
遷移時間表和業務連續性注意事項。
收集所需的功能和 服務是確保新系統滿足業務需求的關鍵步驟。在收集這些需求時，不僅要考慮目前配置的內容，還要嘗試從將要使用該系統的業務實體收集實際需求。否則，該計劃可能基於過時的假設。務必評估 中提供的其他或增強功能，這些功能在 中可能不存在，例如基於雲端的呼叫、進階呼叫佇列、 和 。這有助於充分利用雲端平台的優勢。
在評估目前配置時，必須認識到，由於系統生命週期中需求的不斷變化，並非所有現有設定都仍然是必要的。重點應該放在識別和保留那些符合當前和未來部署需求的配置。
多關注你需要什麼，而不是你擁有什麼。
在從遷移到 Webex Calling 的過程中，合規性和安全策略是至關重要的考慮因素 ，以確保新的基於雲端的通訊系統符合法律、監管和組織標準。
-
監理合規性： 組織必須驗證其是否符合行業特定法規，例如 GDPR、HIPAA 或 SOX，這些法規涉及資料隱私、保留和處理的要求，以及與資料駐留、收費繞行和媒體本地化相關的國家/地區特定規定。
-
資料安全： 確保語音和訊號資料在傳輸和儲存過程中均進行加密，以防止被攔截或未經授權的存取。
-
存取控制： 定義並實施使用者身分驗證、授權和基於角色的存取控制，以防止未經授權使用通訊資源。
-
審計和監控： 實施日誌記錄和監控功能，以追蹤存取和使用情況，用於合規性稽核和安全事件調查。
-
政策一致性： 使遷移與現有的企業安全策略保持一致，包括終端安全、網路分段和事件回應計畫。
-
供應商安全保障： 評估思科的安全認證和合規性證明，以確保其可信度。
在規劃階段解決這些合規性和安全策略有助於降低風險、避免法律處罰，並在整個遷移過程中以及遷移後維護通訊的完整性和保密性。
使用者培訓和支援需求 是從到遷移過程中確保平穩過渡和使用者採納的重要組成部分。主要考慮因素包括：
-
培訓項目： 為不同的使用者群體（最終使用者、管理員、服務台人員）制定客製化的培訓課程，使他們熟悉各項功能、使用者介面和新的工作流程。
-
文件： 提供清晰易懂的使用者指南、常見問題解答和快速參考資料，包括 新增功能和不同之處 資源以及逐步 遷移前後 操作指南（影片或快速指南格式），以幫助使用者適應遷移後的更新體驗。
-
變更管理： 主動溝通變更，以管理使用者預期並減少阻力。
-
支撐結構： 建立專門的支援團隊或升級途徑，以便在遷移期間和遷移後及時解決用戶問題。
-
繼續教育： 隨著新功能或更新的發布，制定持續培訓更新計劃。
-
回饋機制： 建立使用者回報問題和提供回饋的管道，以改善培訓和支援流程。
在規劃階段解決這些培訓和支援需求有助於最大限度地減少干擾，增強使用者信心，並最大限度地發揮遷移到新系統的好處。
技術要求
為了成功從 [系統名稱] 遷移到 [系統名稱]，需要收集並記錄幾個關鍵的技術要求，包括以下方面的詳細資訊：
-
網路就緒性和頻寬容量
進行全面的網路評估至關重要，以確保您現有的基礎架構能夠支援新的 Webex Calling 環境。這些調整包括：
-
頻寬分析： 評估目前和預期的頻寬使用情況，以處理語音、視訊和資料流量而不會出現擁塞。
-
服務品質（QoS）： 實施 QoS 策略，優先處理語音流量，最大限度地減少延遲、抖動和丟包。
-
廣域網路和網際網路連線： 驗證廣域網路鏈路和網際網路連線是否符合基於雲端的呼叫的要求，包括冗餘和故障轉移功能。
-
防火牆和NAT配置： 確保防火牆和 NAT 設定允許所需的訊號和媒體流量。
-
-
與現有系統集成
與現有業務系統無縫整合對於使用者體驗和工作流程的連續性至關重要：
-
目錄服務： 評估與企業目錄的集成，以實現使用者自動配置和身份驗證。
-
客戶關係管理與業務應用： 確定與客戶關係管理系統和其他業務關鍵應用程式的整合點。
-
傳統PBX互通： 若過渡期間仍需保留任何傳統電話系統，則需制定共存或分階段遷移策略。
-
-
端點相容性和配置
應評估所有終端設備（包括桌上型電話、軟體電話和行動裝置）的相容性：
-
設備支援： 確認現有 IP 電話和設備是否受支持，或確定需要更換的設備。
-
配置流程： 建立自動化或簡化的配置方法，以有效率地完成終端設備的存取。
-
韌體和軟體更新： 制定必要的更新計劃，以確保互通性和安全性。
-
-
安全配置和加密標準
在雲端通訊中，安全性至關重要：
-
加密： 依照思科安全最佳實踐，對訊號和媒體流強制執行端對端加密。
-
身份驗證和存取控制： 實施安全身份驗證機制（例如 SSO、多因素身份驗證）和細粒度的使用者存取控制。
-
遵守： 確保解決方案符合相關的監管和行業合規標準（例如 GDPR、HIPAA）。
-
安全監控： 與 SIEM 工具集成，並設定潛在安全事件警報。
-
| 需求 | 關鍵考慮因素 |
|---|---|
| 網路就緒性和頻寬 | 頻寬、服務品質、 WAN/Internet, Firewall/NAT |
| 與現有系統的集成 | 目錄、CRM、PBX、 Email/Calendar |
| 端點相容性和配置 | 設備支援、配置、韌體更新 |
| 安全性配置和加密 | 加密、身份驗證、合規性、安全監控 |
| 使用者培訓和變更管理 | 培訓計畫、文件、變更溝通 |
| 號碼可攜性和撥號方案 | 數位 migration/porting, 撥號方案翻譯 |
| 第三方集成 | 呼叫器、呼叫中心、傳真機、類比設備 |
網路就緒性與要求
網路就緒對於成功遷移到任何基於雲端的通話解決方案（例如 ）至關重要。網路規劃不善會導致通話品質下降、斷線，以及用戶不滿。客戶在遷移到新系統之前需要進行網路評估。建議確認網路頻寬是否足以滿足預期的通話量，確保滿足服務品質 (QoS) 要求，並了解必須在邊緣防火牆中開啟的各種連接埠。
可靠的網路連線以及足夠的服務品質（頻寬、丟包率、RTT）是確保所有支援語音和視訊的終端、用戶端和應用程式獲得最佳端對端用戶體驗的基本要求。
客戶和合作夥伴除了可以透過 OTT 網路連接外，還可以使用其他連接方式來優化連接，例如 Webex Edge Connect。有關 Webex Edge Connect 設計詳情的更多信息，請參閱 Cisco 推薦的 Webex Edge Connect 架構，適用於 Webex Meetings、呼叫多租戶和專用實例。
客戶可以使用 CScan 進行網路評估，該評估提供有關客戶網路品質、可建立的通話數量、延遲等資訊。有關 CScan 工具的更多信息，請參閱 使用 CScan 測試 Webex Calling 網路品質。
為確保網路已做好遷移準備，請參考以下清單：
-
頻寬規劃
計算每個網站的並發呼叫數，以確保您有足夠的上行和下行頻寬，並為其他業務關鍵流量和未來成長預留餘裕。
Webex Calling 呼叫類型頻寬計算 表顯示了部署中可用的呼叫類型，以及每種呼叫類型所需的編解碼器和最大頻寬。如 Webex Calling 通話類型頻寬計算 表所示，可以使用以下通用公式計算每種通話類型所需的音訊通話頻寬：
預期並發呼叫次數 * 基於編解碼器的每次呼叫頻寬 = 所需網路吞吐量。
表2。 Webex Calling 通話類型頻寬計算 呼叫類型 編解碼器 - 頻寬 頻寬計算 / 桌上型電話 -> OPUS - 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 / 桌上型電話 -> 桌上型電話 OPUS – 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 / 桌上型電話 -> 透過LGW的PSTN G.711 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 透過雲端 PSTN 進行 PSTN 通訊（例如 Cisco 通話套餐） G.711 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 企業透過LGW G.722 – 80 kbps 並發呼叫次數 * 80 kbps = 所需網路吞吐量 / 桌上型電話 -> 語音信箱 OPUS – 70 kbps 並發呼叫次數 * 70 kbps = 所需網路吞吐量 透過對每種通話類型所需的並發網路吞吐量進行求和，可以確定特定站點的總潛在頻寬需求。
所有呼叫線路始終錨定在接取 SBC 上。要確定任何給定位置所需的互聯網頻寬，不僅需要考慮位置間的呼叫，還需要考慮位置內的呼叫以及與該位置的本地網關之間的呼叫。例如，兩部 MPP 電話之間的站點內通話需要該站點互聯網接入提供高達 2 x 70 kbps 的全雙工頻寬。
Webex Calling 頻寬計算範例 表格顯示了一個完整的頻寬計算範例，假設所有裝置都在同一網站。
表格 3. Webex Calling 頻寬計算範例 呼叫類型 並發呼叫次數 總頻寬 Webex 應用 / 桌上型電話 → Webex 應用 15 2 * 15 * 70 kbps = 2100 kbps Webex 應用 / 桌上型電話 → 桌上型電話 15 2 * 15 * 70 kbps = 2100 kbps Webex 應用 / 桌面電話 → 透過LGW接入PSTN 50 2 * 50 * 80 kbps = 8,000 kbps Webex 應用 / 桌上型電話 → 透過 Cloud Connect 進行 Webex 通話的 PSTN 0 0 * 80 Kbps Webex 應用 / 桌上型電話 → 透過 LGW 的企業 15 2 * 15 * 80 kbps = 2400 kbps Webex 應用 / 桌上型電話 → Webex 通話語音信箱 5 5 * 70 kbps = 350 kbps 總通話次數 / 頻寬 100通電話 14,950 kbps / 14.95 Mbps -
以上表格中的所有頻寬值均指 IP 頻寬。鏈路頻寬取決於廣域網路封裝方式。
-
以上表格中的頻寬指的是音訊通話的頻寬。視訊通話頻寬方面，Webex 應用程式和 MPP 均適用。 8845/65 手機支援 H.264 視頻，最高解析度為 720p，每次通話最大頻寬為 1,500 kbps。然而，通話期間任何時刻消耗的頻寬量都會根據視訊通訊固有的可變位元率而波動。
-
-
服務品質 (QoS)
在本地環境中實施 QoS 策略，以優先處理即時流量，並確保在交換器、路由器和防火牆之間保持 QoS。
-
延遲、抖動和丟包目標
以下閾值建議用於在透過網路進行OTT通話時獲得最佳語音品質：
-
單向延遲小於100毫秒
-
抖動小於 10 毫秒
-
丟包率 - 0.5% 或更低。
-
-
防火牆和NAT
確保防火牆已配置為允許流量，如 Webex Calling 連接埠參考資訊所述。此外，允許存取同一指南中列出的網域和 IP 範圍，並避免使用 SIP ALG，因為它會幹擾 SIP 訊號。應避免透過代理伺服器進行媒體流量傳輸。
-
DNS 和 NTP
確保網域名稱解析正確，並使用可靠的 NTP 伺服器同步設備時鐘，以進行 TLS 憑證驗證和日誌記錄。
-
故障轉移計劃
考慮現有提供者資料連線（MPLS、SD-WAN 等），並規劃在部署中的每個位置直接連接到網際網路。在需要高可用性的場景下，應規劃冗餘的網路連結。由於您將使用基於雲端的服務，因此可靠的網路連線和足夠的頻寬是基本要求。如果您的組織場所的網路連線通常不夠可靠，延遲不夠低，上下行吞吐量也不夠，那麼您應該重新考慮進行這種轉換。
-
場地存活率
網站生存能力確保即使網路連線中斷，您的業務也能隨時可存取。站點生存能力利用本地網路中的網關，在網路連線中斷的情況下，為現場端點提供回退呼叫服務。如果業務需求要求在網路中斷時仍能持續呼叫，請考慮使用本地生存網關 (SGW) 來提高站點生存能力。有關站點生存能力檢查的更多信息，請參閱 Webex Calling 的站點生存能力。
設定雲端連接的統一通信
Cloud Connected UC (CCUC) 是一種基於雲端的管理和分析解決方案，旨在為本地部署（如 Unified CM）和雲端部署提供集中式的可見性、管理和洞察。它充當傳統本地環境和思科雲端服務之間的橋樑，為組織從本地遷移到雲端的整個過程提供支援。
在向統一通訊系統過渡的過程中，CCUC 透過促進從現有統一通訊部署中收集全面數據，在簡化遷移過程中發揮至關重要的作用。CCUC 可協助完成關鍵的過渡任務，例如遷移裝置、功能和使用者聯絡人，以及自動更新支援的 IP 電話的韌體。CCUC 透過提供集中式的視覺性和管理，協助確保更順暢、更有效率的遷移體驗。
Cisco 強烈建議在過渡專案的早期階段部署 CCUC，理想情況下是在準備階段之前或期間部署。這將使您能夠獲得所需的洞察力和能力，從而徹底評估、清點和規劃後續的遷移活動，並開啟您邁向未來混合能力的旅程。
評估當前環境
遷移計畫中的關鍵活動是評估目前的本地環境和部署情況。這有助於我們了解成功過渡到新階段可能需要哪些潛在改變。它還允許您將平台的關鍵要素與現有的本地部署進行比較。您可以利用這些資訊來幫助確定過渡期間所需的特定任務，以及為了滿足您的業務和技術要求及用例，您希望做出哪些更改。
作為這項工作的一部分，以下幾個方面需要重點審查。
授權
了解現有部署的目前許可結構是準備遷移到新部署的關鍵。對您現有的 Cisco 本機部署解決方案的下列事項進行授權評估。
-
平台
在與客戶團隊或合作夥伴共同確定靈活授權的最佳方案時，能夠清楚闡述您核心平台上目前已授權的內容至關重要。有關靈活許可的更多信息，請參閱 Cisco 協作靈活計劃。
-
使用者和設備
確定您現有使用者和裝置需要哪種授權類別。這將用於確定使用者和設備所需的許可證類型。提供多種許可證類型，包括使用者的專業版和標準版許可證，以及針對工作區的專業版和公共區域版授權。有關設備許可的更多信息，請參閱 設備許可中的數據表。
-
本機閘道
如果此次過渡需要 Cisco Unified Border Element (CUBE) 來實現 PSTN 接入，則還必須考慮 CUBE 許可。CUBE 許可方面的注意事項將在本文檔後面部分介紹。
Locations/Sites
在規劃此過渡時，應考慮現有部署中的站點數量和類型（大型中央站點、區域站點、分公司等）。充分了解現有部署站點將有助於制定策略計劃，以實現成功的過渡，尤其是在確定要遷移哪些站點以及遷移順序方面。詳細了解撥號方案要求（號碼、撥號習慣、限制類別等）、網站網路連線和頻寬（網際網路、廣域網路、區域網路）以及每個站點的 PSTN 存取（本地或集中式、IP 或 TDM）對於制定遷移決策至關重要。有關常見部署模型和關鍵考慮因素的更多信息，請參閱 Collaboration SRND中提供的協作部署模型資訊。
當遷移到新平台時，另一個重要的部署考慮因素是位置可用性。根據部署位置的不同，可用的功能、訂閱和設備也會有所不同。有關地理位置可用性的更多信息，請參閱 Webex 在哪裡可用？。
最後，了解過渡到新系統對其他協作服務的影響也很重要。根據本文檔的目標，一般假設是，如果要維護呼叫工作負載之外的現有協作服務，則需要過渡到上面提到的第 1 階段混合部署。可能需要混合部署的協作服務範例包括尚未遷移到 Webex 聯繫中心的本地聯絡中心，以及與尋呼系統和計費系統等系統的緊密整合。有關其他協作工作負載和服務的過渡的更多信息，請參閱 協作過渡。
現有庫存 devices/clients
在開始過渡之前，清點您現有的硬體和軟體終端非常重要。擁有完整的設備清單 types/models, 硬體版本、軟體用戶端作業系統類型和數量將確保您能夠充分規劃設備的過渡，並減輕那些無法遷移到雲端通話的裝置的影響。應利用庫存清單確定過渡期間需要過渡的設備以及過渡前需要更換的設備。
桌上型電話
僅支援 6800、7800、8800 和 9800 系列音訊和視訊桌面電話。這是受支援的 Cisco IP 電話的子集。6800、7800 和 8800 系列手機的某些型號和版本不能與 . 有關支援哪些型號和硬體版本的更多信息，請參閱 Webex Calling 支援的設備。
Cisco 6800 系列 IP 電話無法從企業韌體升級至多平台 (MPP) 韌體，而多平台 (MPP) 韌體是必要的。因此，任何註冊運行企業韌體的 6800 電話都必須更換為 6800 MPP 型號或其他受支援的電話型號。
Cisco 7800 和 8800 系列 IP 電話必須先升級到多平台電話 (MPP) 固件，然後才能進行過渡並註冊。若要確定哪些 7800 和 8800 型號和硬體版本支援 MPP 韌體，請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
8845、8865 和 8865NR 已停止銷售，不建議遷移。
不建議將較舊版本的 8800 系列電話（8811、8841、8851、8851NR、8861）與 Webex Calling 搭配使用。硬體版本為 VID 14 或更早的手機可以註冊，但由於硬體原因可能會出現一些效能問題。
9800 系列桌上型電話運行 PhoneOS，支援註冊和登入。因此，這些手機無需韌體升級即可進行過渡。
所有其他 IP 電話都需要更換為 Webex Calling 支援的 6800、7800、8800 或 9800 系列電話。有關支援的 IP 和桌面電話的更多信息，請參閱 文章 Webex Calling 支援的設備。
視訊終端
個人和會議室視訊終端，包括 Cisco Board 系列、Room 系列和 Desk 系列，可原生註冊到 SIP。任何需要發出音訊的端點 and/or PSTN 呼叫需要呼叫許可證：
-
會議室、小型討論空間等處的共享設備需要專業工作區或工作區授權。
-
終端使用者的個人設備需要專業版或標準版授權。
確定有多少個視訊終端已註冊並用於進行音訊通話。某些視訊終端可能僅用於加入會議或進行 SIP 視訊通話。無論哪種情況，終端設備仍需在伺服器停用之前進行遷移，但這將有助於確定其中有多少設備需要許可證才能繼續撥打電話。
-
當視訊設備從本機註冊遷移到雲端註冊時，這些端點的 URI 將會發生變化，因為它們現在是在雲端註冊的。
-
8845、8865 和 8875 型號的電話是支援的個人視訊電話。
軟體客戶端
這是唯一支援的軟體用戶端，與同時支援 Webex App 和 Jabber 的 Unified CM 不同，並且是最終用戶的新預設軟體用戶端。
根據 Jabber 所實施的部署模式（僅限即時通訊、僅限電話、 and/or （完整的 UC 模式），您可能還需要考慮訊息傳遞的過渡。 and/or 將 Jabber 中的會議工作負載轉移到 . 如果僅用作通話用戶端，則可部署為 僅電話模式 ；如果還需處理其他工作負載，例如 Webex Messaging，則可部署為 完整的 Webex 套件 。 and/or Webex Meetings 正在過渡到具有通話功能的應用程式。
它透過提供人工智慧功能來增強最終用戶體驗，例如 audio/video 情報、通話轉錄等。如需相關資訊，請參閱 。https://www.webex.com/all-new-webex
在將使用者遷移到新系統之前，您需要將他們的 Jabber 用戶端遷移到新系統。完成此次過渡有兩種選擇。
-
在將它們過渡到
-
當你將它們過渡到.
為了方便使用者首次過渡到新系統，建議使用選項 1，並先呼叫該選項將使用者遷移到新系統。這樣一來，用戶就有時間熟悉新的應用程序，同時他們仍然可以繼續使用現有的本地呼叫平台。準備好將用戶遷移到雲端後，您需要設定他們的裝置以在雲端呼叫平台上註冊。
有關這兩個選項的更多信息，請參閱 遷移之旅 - 一步還是兩步？。
有關 Webex Calling 支援的設備的完整列表，請參閱 Webex Calling 支援的設備。
驗證設備資格
如前所述，它支援部分思科 IP 電話，並且 7800 和 8800 系列電話需要不同的韌體類型。Unified CM 電話運行企業韌體，而 Phones 則運行多平台電話 (MPP) 韌體。建議在準備階段確認哪些已註冊的手機符合升級到 MPP 韌體的條件。這樣您就有時間將不符合條件的手機更換為支援的手機型號之一，或者確定替代方案，例如將用戶遷移到僅 Webex 應用程式。
為了協助確定電話的資格，Control Hub 內建了一個名為 「將您的電話遷移到 Webex Calling」的工具。使用此工具檢查裝置資格時，選擇移轉選項 僅產生裝置授權。
此選項可讓您上傳包含電話號碼的 CSV 文件，以便檢查每部電話號碼的資格。選擇此遷移選項後，由於您仍處於準備階段，尚未準備好執行此操作，因此不會將手機新增至遷移清單。如需相關資訊，請參閱將電話移轉至Webex Calling 。
部分手機可能顯示 未知 資格。這通常是因為無法在後端系統中驗證有關手機的某些資訊。對於任何狀態為 未知 的手機，您有兩種方法可以驗證它們是否符合升級到 MPP 韌體的條件。
-
手動檢查每部手機，並核實型號和硬體版本（PID VID）。
7800/8800 電話標籤，包含型號和硬體版本信息 -
使用 Cisco IP 電話就緒工具
從 https://github.com/joemar2/mpp_readiness_check下載該工具。
此工具並非思科官方工具，也不受TAC支援。它提供盡力而為的支持，但可以免費使用。
該工具必須在本機電腦上運行，並且能夠存取伺服器和 IP 電話。它提供了一個選項，可以在 IP 電話上啟用網路訪問，建議啟用此功能以獲得最佳效果，並且這是必需的。因此，應在非工作時間使用，以免對最終使用者造成乾擾。該工具的輸出結果會產生一份報告，列出哪些 7800 和 8800 系列電話符合升級到 MPP 韌體的條件。因為它直接存取手機，所以可以驗證從控制中心工具報告的 未知 裝置。
Cisco IP電話就緒工具報告
使用者
確保遷移成功的最重要準備步驟之一是正確配置使用者。即使分階段遷移，也需要為所有使用者做好妥善規劃。使用者必須具備以下任一條件：
-
使用呼叫進行部署
-
部署與
-
為使用者配置服務
-
使用戶可在目錄中被搜尋（點選撥號、使用者聯絡資訊、電話簿搜尋）。
建議您在專案開始之前或開始時配置所有使用者。這包括那些仍然使用 Unified CM 的用戶，因為他們的呼叫平台與其呼叫設備（IP 電話、Jabber 等）無關。隨著用戶遷移到 (and/or 您將更新他們的許可證，以啟用他們需要的服務。透過在開始過渡之前配置所有企業通話用戶，可以允許已過渡到其他平台的用戶在目錄中搜尋仍在使用 Jabber 的企業通話用戶。 and/or 在 。這樣可以確保過渡用戶能夠找到任何其他用戶的聯絡訊息，並使用目錄查找功能撥打電話。
圖 目錄搜尋 顯示了一個使用者搜尋另一個使用者的範例。搜尋結果顯示用戶的聯絡訊息，可能包括仍在使用 Jabber 的用戶，也可能包括已遷移到其他平台的用戶。 and/or 。
接下來確定哪些現有的本地呼叫用戶將被遷移到新系統。如果需要遷移全部或大部分用戶，建議分批遷移用戶，以確保專案團隊、IT 人員和支援人員能夠處理遷移以及可能出現的任何問題。您還應該安排一些時間提供初步資訊和培訓課程，以幫助使用者做好過渡準備。使用者轉換分組可以根據各種標準進行，包括使用者被分配到的位置或網站、使用者的部門，甚至是使用者類型（知識工作者、管理人員、行動工作者等）。
例如，如果部署中的使用者分佈在三個主要站點，即紐約 (NYC)、舊金山 (SFC) 和研究三角園區 (RTP)，則使用者過渡計畫可能類似於 按站點劃分的使用者過渡計畫 表中概述的計畫。
| 使用者網站 / 地點 | 過渡前資訊與培訓課程 | 過渡期 | 過渡後支持 |
|---|---|---|---|
| 紐約市（1,525 位用戶） | 4月1日當週 | 4月15日至4月27日 | 4月29日當週 |
| 舊金山國際機場（1,600 位使用者） | 5月6日當週 | 5月20日至5月31日 | 6月3日當週 |
| RTP（1,275 位使用者） | 6月3日當週 | 6月17日至6月28日 | 7月1日當週 |
另一個重要因素是讓彼此有依賴關係的使用者一起過渡。這可能包括但不限於以下內容：
-
BLF監測
-
同樣的狩獵 pilot/group
-
分享線
-
同屬一個呼叫接聽組
-
使用相同的呼叫駐留號碼
-
內部通訊
-
Admin/Exec.
您可以查看配置（GUI 或匯出）或使用 遷移洞察 工具來協助識別具有這些依賴關係的使用者群組。
PSTN 連線
可以透過三種方式接取公共交換電話網路（PSTN）：Cisco 通話套餐、雲端連線（以前稱為雲端連線 PSTN）和本地 PSTN（本地閘道）。但是，依照規定定義的單一位置只能指派給一個 PSTN 選項。
具有本地網關 (LGW) 的本地 PSTN 是過渡策略的重要組成部分。它提供本地部署之間的連接 and/or PSTN 和此平台支援 Cisco 和經認證的第三方會話邊界控制器 (SBC)，這些控制器可用作本地網關。有關最新支援的 SBC 列表，請參閱 支援的 SBC 列表。
支援來自單一基於註冊的本地網關的最多 250 個並發調用，以及來自單一基於憑證的本地網關的超過 250 個並發調用。基於憑證的本機閘道最多可支援 6500 個同時呼叫，但這取決於本機閘道的連線類型（OTT 與互連對等連線）以及本機閘道部署的 SBC 模型。這些限製本質上是本地網關 PSTN 呼叫和站點間呼叫的預設計數限制。有關更多信息，請參閱 本地網關入門。
任何超過此限制的呼叫都將被拒絕，並傳回 403 Forbidden。可以在任何時刻在本機閘道上執行 show call active voice 指令，以決定活動呼叫的總數。
本機閘道與接取 SBC 之間的網路狀況不佳會限制訊號連線的效能，從而導致同時呼叫限制進一步降低。本地網關與資料中心之間的單向延遲不得超過 100 毫秒，抖動應小於 10 毫秒，丟包率應小於 0.5%。 %.
特徵 & 功能使用
在評估當前環境時，識別和審查已配置的功能非常重要。此外，了解這些功能的使用方法也很重要，這樣您才能（重新）定義部署的業務和技術要求。
若要確定配置了哪些功能，請分析配置。這些都是靜態數據，是在系統配置某個功能或設定時設定的。可以使用以下選項完成此分析：
-
在管理 GUI 中查看配置
-
配置匯出 -- 批次匯出或 AXL
-
遷移洞察工具（推薦）
-
思科第三方合作夥伴工具（建議）。
為了有效分析功能利用率，必須檢查動態系統數據，例如使用率、註冊量和呼叫活動。各種分析工具和儀錶板提供了對這些指標的深入了解，從而能夠全面了解系統性能和容量，為遷移和優化工作中的明智決策提供支援。可以使用以下選項完成此類分析：
-
審查原始CDR記錄
-
統一 CM RTMT 資料審查
-
使用 CDR 資料的遷移洞察工具
-
雲端連線統一通訊分析的回顧
-
通話量
-
已註冊的端點
-
（CAC）地點
-
主幹線利用率。
-
-
思科第三方合作夥伴工具。
Cisco 建議先使用 Webex Control Hub 遷移洞察工具進行此分析。您需要將匯出的 .TAR 檔案和統一 CM CDR 檔案（可選，但功能利用率分析需要）匯入到該工具中。該工具將產生以下基於 CSV 的報告，可用於開始分析：
| 報告名稱 報告說明 |
|---|
| ImportedDataBulk.csv 來自統一組態管理 (Unified CM) 資料的所有使用者和設備 |
| DeviceEligibility.csv 識別符合遷移到 Webex Calling 條件的設備（IP 電話、會議室作業系統設備、ATA 和第三方設備） |
| DevicePoolNumbers.txt 特定設備池中的所有號碼列表 |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv 根據共用線路、呼叫群組、呼叫佇列、呼叫駐留和呼叫代接群組配置，提供有關應一起遷移的裝置和使用者的詳細資訊。 |
| HuntGroupMigrationInsight.csv 有關已指派呼叫線路、線路組和相關代理的詳細信息 |
| SharedlineGroupMigrationReport.csv 用戶間共享電話號碼（目錄號碼）的方式概述 |
| 報告名稱 報告說明 |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv 根據功能使用情況提供的設備遷移資格信息 |
| FeatureUsageWithLastUsageDateReport.csv 使用次數統計，包括呼叫調度員和呼叫佇列的呼叫次數以及上次使用日期。 |
| UserWorkspaceLastUsage.csv 軟體客戶端和硬電話的使用者和工作區的最後使用日期 |
| DIDUsageReport.csv DID 的使用情況，包括已指派和未指派的 DID |
有關遷移洞察報告的更多詳細信息，請參閱 遷移洞察。
如果您在查看遷移洞察報告中的信息後仍需要有關功能和使用方法的更多信息，思科建議您考慮使用思科的第三方合作夥伴遷移工具。 and/or 查看圖形使用者介面或配置匯出資料中的配置。
思科整合：Unity Connection UCCX UCCE
語音信箱是該服務不可或缺的一部分，並且已原生內建於解決方案中。它無法與 Unity Connection 或 Unity Connection Express 等本地部署的語音信箱解決方案整合。此外，目前還沒有原生方法可以將現有的 Unity Connection 語音郵件訊息或問候語遷移到原生語音郵件服務中。思科的一些第三方合作夥伴的遷移工具確實具備遷移部分此類資料的功能。有關語音信箱的更多信息，請參閱 配置和管理 Webex Calling 用戶的語音信箱設定。
也支援共享語音信箱和傳真郵箱。有關更多信息，請參閱 管理 Webex Calling 的共享語音郵件和入站傳真箱。
它內建了自動語音應答功能，該功能包含在核心平台中。此功能允許遷移 Unity Connection 的呼叫處理程序和自動助理功能。Control Hub 工具 從 Unified CM 遷移功能 支援將 Unity Connection 配置遷移到 Auto-Atdendants。有關使用此工具的更多信息，請參閱 將設備和功能從 Unified CM 遷移到 Webex Calling。
通話錄音
包含兩種通話錄音選項，無需額外費用。
-
Webex通話錄音
-
Dubber Go 錄製（合作夥伴優惠）—與 Dubber 的集成，所有錄製的媒體都安全地保存在雲端。
包含錄音選項 表格重點介紹了兩種無需額外費用即可使用的通話錄音選項的一些關鍵功能。
| Webex | 杜伯·戈 |
|---|---|
| 所有使用者均可使用 | 所有使用者均可使用 |
| 無限次錄音 | 無限次錄音 |
| 1 年保留期* | 30天保留期 |
| 每個組織 100 GB 儲存空間 | - |
| 合規官可以存取和管理通話錄音。 | - |
| 用於管理錄製內容的 API | - |
管理員可以設定和管理使用者對其通話錄音的存取權限。
|
只有使用者才能存取和管理自己的錄音。
|
如果您的組織需要額外的錄音功能，例如合規性通話錄音、更長的保質期、更大的儲存空間、人工智慧分析等， and/or 思科和第三方錄製提供者都提供管理員存取權限、付費服務或附加元件。有關錄音提供者、配置和附加合作夥伴服務的更多信息，請參閱 管理 Webex Calling 的通話錄音。
第三方集成
支援多種第三方集成，包括但不限於本地網關的SBC、IP電話、對講電話 等。 Speaker/Pagers, ATA 等。除了這些第三方設備外，Webex Calling 還支援不同的第三方解決方案 ，用於客戶支援、分析、錄音、計費等。有關第三方解決 方案的更多信息，請參閱 Webex App Hub。
方案
高層專案計劃
在製定從 到 的高級專案計劃時，必須建立與業務目標和技術要求一致的清晰階段和里程碑。該計劃應從全面的評估階段開始，包括收集詳細的技術和業務需求，以及確定利害關係人和定義成功標準。關鍵考慮因素包括資源分配、時間安排估算、風險管理和溝通策略，以確保所有各方在整個遷移過程中都能了解情況並參與其中。此外，該計劃應包含驗證檢查點，例如試點測試和分階段推廣，以最大限度地減少干擾，並允許根據回饋進行調整。
專案計畫中應包含的要素範例包括：
-
確定遷移範圍（例如，哪些使用者、裝置和功能將進行遷移）
-
為最終用戶和支援團隊安排培訓課程
-
協調網路就緒評估，以及
-
制定切換活動計畫並配備備用方案。將合規性和安全性審查以及遷移後支援和優化階段納入其中也十分重要。
透過根據這些考慮因素建立專案計劃，組織可以更好地管理複雜性，降低風險，並實現更平穩的過渡。
移民之旅－一步還是兩步？
要求用戶使用其呼叫軟客戶端。因此，如果還有用戶在使用，您可以選擇何時將他們遷移到。您可以執行單步驟用戶遷移或雙步驟用戶遷移。
選項 1：單步用戶遷移
在單步驟遷移中，使用者從 Unified CM 遷移到 的同時，也從 遷移到 。此選項通常適用於使用者數量較少的客戶，可以同時管理使用者的軟客戶端和呼叫服務的遷移。圖 用戶呼叫服務，軟客戶端 & 手機遷移到同一時間 下面突出顯示了這種類型的遷移。使用此選項，使用者將同時完成以下所有操作：
-
呼叫服務已從
-
電話號碼和分機號碼已從…遷移至…
-
軟體客戶端已從 Jabber 過渡到 - 將註冊
-
電話註冊從 移至 。
這仍然可以是一個分階段的遷移，用戶群組在不同的時間進行遷移，但當每個用戶被遷移時，所有這些操作都是同時進行的。
選項 2：雙步用戶遷移
另一種方法是兩步遷移。在步驟 1 中，使用者從 [此處應填寫具體位置] 過渡到 [此處應填寫具體位置]，但仍保留 [此處應填寫具體位置] 以撥打服務電話。然後在步驟 2 中，使用者從 Unified CM 遷移到 。對於希望管理最終用戶變更並將用戶軟體客戶端變更與呼叫服務變更分開的大型客戶，建議採用此選項。下圖 遷移軟客戶端；然後遷移呼叫服務，軟客戶端 & 以下透過電話到 Webex 通話 突出顯示了這種遷移方式。
步驟 1
-
軟客戶端已從過渡到 - 將註冊到。
步驟 2
-
呼叫服務已從 遷移到 。
-
電話號碼和分機號碼已從 移轉到 。
-
註冊地點從 轉移到 。
-
電話註冊從 移至 。
這仍然可以是一個分階段的遷移，在兩個步驟中，使用者群組會在不同的時間進行遷移。
您選擇的選項取決於您希望如何管理使用者向新系統的過渡。建議分步驟進行（方案 2）。這樣可以最大限度地減少最終用戶一次性進行的更改，並將工作量分配到專案的不同部分。但是，如果您希望使用者只受到一次影響，那麼使用選項 1 也是可行的。
查看建議的流程（選項 1）， Jabber 到 Webex App 進階轉換圖 下圖顯示了步驟 1 的進階轉換。
在此步驟中，用戶將從 Jabber 過渡到其所有通話服務。然而，呼叫平台仍然是 Unified CM，並且將其呼叫服務註冊到該平台。從 Jabber 到 Webex App 的高階過渡圖 可以看出，本地基礎架構不會改變，其運作方式與 Jabber 相同。唯一的改變是需要連接到外部網路。
有關此過渡的更多信息，請參閱 Jabber 到 Webex 過渡圖和部署指南 ，位於 協作過渡 頁面的客戶端部分。
Unified CM to Webex Calling high-level transition map figure is a high-level transition from to . 這是推薦行程的第二步。
如果您決定採用單步法，這同樣適用。
在此步驟中，使用者將被分組。此時，用戶開始使用呼叫服務、呼叫註冊和 IP 電話註冊。
由於用戶是成組遷移的，因此在過渡期間，企業用戶將被分散到兩個通話平台之間。 Unified CM 到 Webex Calling 進階轉換圖 中的第一階段描述了此狀態。在此階段，需要規劃如何管理兩個平台上的使用者之間的通話以及如何路由 PSTN 通話。每次有一組使用者遷移到新系統時，都需要在新系統和本地網關上更新撥號方案和呼叫路由。
一旦所有使用者、軟體客戶端和設備都過渡到（第二階段），那麼所有本地統一通訊基礎設施都可以被移除和停用。
設計
區域選擇
可在全球範圍內使用，並透過位於多個地區的冗餘資料中心進行交付：美國（達拉斯、芝加哥）、加拿大（溫哥華、多倫多）、歐洲（法蘭克福、阿姆斯特丹）、英國（倫敦、曼徹斯特）、澳洲（墨爾本、雪梨）、日本（東京、大阪）、沙烏地阿拉伯（利雅德、吉達）和印度（孟買、清奈）。媒體接入點提供媒體服務，以優化媒體往返時間。例如，新加坡資料中心用於優化亞洲國家客戶的媒體往返時間，因為往返澳洲或日本地區的媒體往返時間可能不夠理想。資料中心透過多千兆位元、完全冗餘的主幹網路互連。圖 全球分散式資料中心 顯示了所有資料中心的概覽。有關可用資料中心的最新列表，請參閱 Webex Calling 資料中心位置。
每個客戶都分配到其中一個實例。該客戶的所有設定資訊都儲存在該實例中，並且為該客戶配置的所有端點和本機網關的 SIP 訊號都與該客戶所在的實例相關聯。由於很難改變最初的區域選擇，因此在進行區域選擇決策的過程中，必須考慮所有相關因素。為了避免訊號往返延遲過長，在過渡過程中儘早決定應該使用哪個實例非常重要。Cisco 建議選擇能夠提供部署中最多使用者最簡訊令往返時間的執行個體。
有關國家/地區的可用性，請參閱 Webex 在哪裡可用？。
位置
為了準備提供遷移目標位置所需的信息，需要收集所有遷移目標位置的相關資訊。每個地點所需的資訊匯總在 每個地點需要捕獲的資訊。
| 資訊 | 意見 |
|---|---|
| 擴展範圍 | 每個位置都可以有以不同數字開頭的分機號碼。必須留出一位數字作為站點間撥號轉向數字（例如 8），一位數字作為 PSTN 轉向數字（例如 9）。任何擴展號碼都不能以這兩個數字中的任何一個開頭。 所有位置的擴展範圍長度必須相等。 |
| DID範圍 | - |
| PSTN轉向數字 | - |
| 網站程式碼 | 所有地點的所有站點代碼都必須是唯一的，且長度必須相同。 |
| 主要號碼 | 建立位置時需要配置兩個 DID。一個作為主要號碼（例如分配給自動應答服務），一個用於語音信箱入口網站。 為語音信箱號碼提供一個DID號碼。 |
| 語音信箱號碼 | |
| 授權數目 | 所需許可證類型包括：標準版、專業版、工作區版、路由清單版、外呼計畫版。 |
| 繁忙時段的並發呼叫 | 設備之間以及設備與本地網關之間並發呼叫的總和（PSTN 和呼叫到設備）。需要確定所需的網路存取頻寬。 |
| 國家或地區 | - |
| 時區 | - |
| 語言 | - |
| 聯絡方式（姓名、電話、信箱） | - |
| 地址（街道地址、城市、州/省、郵遞區號） | - |
| 緊急服務終端的實體調度位置 | 用於緊急呼叫的設備可調度位置通常包括以下位置：建築物地址，建築物地址 + 樓層號，樓宇地址 + 套房號或樓宇地址 + 樓層號 + office/cubical 數字。 |
| 每個設備唯一的實體網路位置，用於緊急服務 | 緊急呼叫的實體網路位置通常包括以下部分：轉變 / 用於有線設備的交換器端口，用於無線連接設備的無線接入點（AP）基本服務集標識符（BSSID）。 and/or 用於終端設備的本機 IP 子網路。 |
PSTN
在設計部署方案時，客戶有三種主要的PSTN連線選項：Cisco Calling Plans（由 Cisco 管理的雲端交付 PSTN 服務）、雲端連線 PSTN 供應商 (CCPP，供應商透過雲端提供 PSTN 服務) 和本地 PSTN (本地網關將企業網路連接到 PSTN)。透過引入用於混合部署的 PSTN 中繼（有關更多信息，請參閱 PSTN 中繼中的用於混合 Webex Calling 部署的 PSTN 中繼），組織在遷移方法上獲得了更大的靈活性。此功能使客戶能夠在過渡之旅開始時將 PSTN 遷移到 CCPP，並開始為使用者過渡到雲端 PSTN，同時利用 CCPP 在分階段遷移期間為留在 Cisco 的使用者維持 PSTN 服務。
這種混合方法允許組織先將選定的使用者群組遷移到雲端，而無需立即徹底改造其整個電話環境。然而，這也帶來了額外的複雜性和風險，尤其是在調整現有呼叫路由邏輯以支援新架構方面。與傳統應用程式（例如傳真伺服器、呼叫中心或尋呼系統）的互通性也需要仔細考慮。關鍵技術挑戰可能包括確保在混合環境中實現無縫的端到端編解碼器協商和 DTMF（雙音多頻）信令，以及驗證與專用電話功能的兼容性。妥善的規劃和測試對於最大限度地減少中斷和在整個遷移過程中保持可靠的語音服務至關重要。此外，商業因素也很重要，因為混合中繼需要根據本地環境和雲端連接 PSTN 供應商 (CCPP) 之間的並發呼叫數量來獲得使用授權。
或者，各組織可以選擇在整個過渡階段保留其內部 PSTN 連線。在這種情況下，遷移到 CCPP 可以透過兩種方式執行：遷移完成後，可以對所有使用者和地點進行一次統一協調的切換，也可以逐步進行，PSTN 遷移根據使用者遷移到的地點逐一進行。這種方法有助於簡化共存並保持傳統整合的連續性，但同時也引入了一些操作上的複雜性。其中包括與號碼攜號轉網相關的挑戰，例如需要精確協調號碼攜號轉網訂單、可能出現的延遲以及運營商施加的限制，例如限制同時進行的攜號轉網請求數量或限制攜號轉網大號碼塊的子集。各組織必須仔細規劃其 PSTN 過渡策略，並將這些後勤因素考慮在內，以避免服務中斷並確保平穩的遷移體驗。
圖 一開始遷移到 CCCP 與保留本地 PSTN 顯示了上面解釋的兩個 PSTN 遷移選項。左圖顯示的場景是所有本地用戶和應用程式都透過本地中繼和連接本地與雲端的本地網關來使用雲端連接的 PSTN 服務，而右圖顯示的場景是現有的本地 PSTN 保持不變，Webex Calling 用戶透過本地與雲端之間的本地網關連接來使用本地 PSTN。過渡期間，各地點可以切換到使用雲端連線的 PSTN。
在這兩種情況下，本機系統和使用者之間的呼叫都使用本地網關連接。本地與外部之間的連接需要根據預期的並發呼叫數量和所需的冗餘度進行相應的設計和規模調整。
撥號計劃
為了在遷移期間實現無縫互通性，必須在兩個平台之間開發和實施全面的撥號方案架構。這種雙平台撥號方案設計確保了呼叫路由、號碼轉換和功能透明度的一致性，使兩個系統上的使用者都能在整個共存階段進行通信，而不會出現服務降級或使用者體驗中斷。
本地撥號方案
在過渡期間，為了允許在 Unified CM 和企業撥號計劃上註冊的設備共存，需要進行更改，以便至少滿足以下要求：
-
+E.164 撥號從到
-
分機撥號（站點內撥號，若分機號碼範圍唯一，也可站點間撥號）
-
從到站點間的簡短撥號
-
強制從到網內撥號
-
從未接來電目錄回撥至目的地
-
如果在過渡期間使用本地 PSTN，則 PSTN 通話將從本地 PSTN 呼叫到本地 PSTN。
-
如果在混合部署的過渡期間，使用 PSTN 中繼透過 Cloud Connect 為本地用戶提供 PSTN 訪問，則 PSTN 呼叫將從本地呼叫發送到本地呼叫。
-
被迫從網路到
-
分機撥號（站點間）。
如果在過渡之前不支援上述任何撥號習慣，例如不存在縮短的站點間撥號習慣，那麼在過渡期間不一定需要引入這些習慣。
圖 最佳實務撥號方案 顯示了 Cisco Collaboration 12.x 企業本地部署首選架構 (CVD) 中所述的最佳實務撥號方案方法。此方法的主要特點包括：
-
單一分區 +E.164 電話號碼簿
-
基於核心路由 +E.164 路線模式
-
將所有撥號習慣規範化 +E.164 使用翻譯模式
-
使用翻譯模式呼叫搜尋空間繼承（選項 使用發起者的呼叫搜尋空間 設定在翻譯模式上）。
例如，PSTN撥號 (9+1+10D) 來自 SJC 中已配置線路呼叫搜尋空間 SJCInternational 的裝置將首先與 相符。 9.1[2-9]XX[2-9]XXXXXX 將被叫號碼規範化的轉換模式 +E.164. 然後，二次查找再次使用相同的呼叫搜尋空間 SJCInternational （呼叫搜尋空間繼承），並且 +E.164-digit 字串要么會被匹配，要么會被其他字串匹配。 +E.164 在 DN 分區中，或透過 USPSTNNational 或 SJCPSTNLocal 分區中的 PSTN 路由模式之一。站點內和站點間撥號習慣的簡化是透過 ESN 和 SJCtoE164 分區中的翻譯實現的。雖然 ESN 分區是全域分區（所有位置的手機均可存取），但 SJCTOE164 分區僅對位於 SJC 位置的用戶可存取。這是假設擴展範圍重疊的情況。
啟用從到的呼叫的第一步是確保 +E.164 目的地將根據目的地進行相應路由。這可以透過向撥號計劃添加分區來實現，添加 +E.164 為到該分區的所有目的地建立路由模式，最後將該分區新增至所有呼叫搜尋空間，表示需要能夠到達的服務類別。需要建立一個專用分區，以便為來自以下位置的呼叫建立差異化的服務類別：為避免呼叫循環，本機閘道中繼上的入站呼叫搜尋空間不應存取該分割區。
如圖所示 +E.164 路由到 Webex Callex，以啟用從某個位置到某個位置的路由 +E.164 DID範圍 +1 221 555 2XXX 和站點代碼 121，與此相符的緊急路線模式 +E.164 需要將範圍加入 分區。
如果不需要選擇特定站點的本機網關，則可以不採用以本機路由群組為目標的路由列表，而是設定以本機網關為唯一成員的路由群組，然後路由模式指向一個僅包含該路由群組條目的路由列表。
為了實現站點間的短撥號，需要將所需的路由模式 8121.2XXX 新增至分區。為使站點能夠過渡到撥號規範化模式 8121.2XXX ，此模式將 ESN 撥號規範化為 +E.164 可能已存在於 ESN 分區中。在這種情況下， 8121.2XXX 似乎是多餘的，但是一旦相應位置的所有 DN 都遷移到 8121.2XXX 撥號規範化轉換模式，就可以刪除 8121.2XXX 路由模式，即使對於該範圍內的分機用戶，也可以啟用 ESN 撥號。
透過這些撥號方案的更改，不僅可以撥打站點間短撥號碼，還可以撥打其他撥號號碼撥打到該位置。 +E.164. 此外，國際和國內PSTN撥號是可行的，因為這些撥號習慣首先被規範化。 +E.164 透過現有的撥號規範化轉換模式，然後透過配對進行路由。 +E.164 分區中的路由模式。
這 +E.164 在所有 DID 仍託管在 上的情況下，可以設定位置 DID 範圍的路由模式比對。最佳匹配模式匹配演算法確保當撥打託管在 [此處應填寫系統名稱] 上的號碼時， +E.164 目錄號碼的匹配度比通配符更高。 +E.164 路由模式指向，以便將呼叫擴展到線路，而不是發送到。
撥號計劃
每個用戶都分配有一個擴展名。 and/or 一個 +E.164 電話號碼。擴展長度是一個固定的全域設定：部署中的所有擴充長度都相同。分機撥號功能既可以在同一地點內使用，也可以在不同地點之間使用。簡單的站點間分機撥號（後一種情況）僅在所撥打的分機是唯一的情況下才有效。
如果需要在不同地點之間進行縮短的站點間撥號，但不同地點分配的分機號碼有重疊，則需要建立企業特定的號碼方案，在分機號碼前加上接取碼和站台代碼。有關更多信息，請參閱 Cisco Collaboration 15 本地部署的首選架構，設計概述 可在 Cisco Collaboration Preferred Architectures處獲取。
分機長度、跨區分機撥號行為、跨區撥號前綴長度以及跨區撥號路由前綴中的轉向數字均在呼叫服務設定中進行設定。 :
-
位置路由前綴長度: 前綴長度（包括轉向數字）。只有在需要建立企業編號方案作為備用的縮短的企業間撥號習慣時才需要。
-
路由前綴中的轉向數字: 用於簡化企業間撥號習慣的導向數字。應避免與任何位置的首位數字和位置外撥號碼重疊。只有在需要建立企業編號方案作為備用的縮短的企業間撥號習慣時才需要。
-
內部延伸長度: 標準長度的接髮。可以是2到10之間的任何值。
當需要從本地呼叫控制中心撥打分機號碼或使用企業有效號碼（轉向代碼、站點代碼、分機號）撥打電話，並且本地呼叫控制中心將分機號碼作為呼叫者 ID 發送時，請確保在 “呼叫路由 ”部分中設置 “最大未知分機長度 ”參數，以確保從本地呼叫控制中心到本地呼叫控制中心的上游呼叫能夠被正確分類為本地呼叫。 -
允許不同地點之間撥打分機號碼: 切換到 enable/disable 在不同地點之間進行分機撥號。只有當組織內的所有分機號碼都是唯一的時，才應啟用此選項。如果停用此選項，則需要在各個位置之間撥打企業重要號碼（路由代碼、站點代碼、分機號碼）或電話號碼。
前三個參數主要用於建立電話撥號方案，以最大限度地減少摘機撥號時的數位間逾時。仍然可以偏離這些全域設定（例如 - 可以配置不同長度的分機），但控制中心會彈出警告訊息，並且從電話撥號可能需要進行整體撥號，以避免與預先載入的撥號計劃發生衝突。
表 企業編號範例 顯示了三個位置的範例，其中兩個位置（紐約市和 RTP）的擴展範圍相同。建立企業編號方案，採用站點間引導數字 8，後面接著三位數站點代碼和四位數分機號，從而形成不重疊的站點間撥號縮寫習慣。
| 網站 | 擴展範圍 | 網站程式碼 | 企業級 |
|---|---|---|---|
| 紐約市 | 2XXX | 202 | 8 202 2XXX |
| 舊金山 | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
為了實現平穩過渡，用戶在過渡前後的撥號習慣最好保持一致。為了做好每個地點過渡的準備，需要記錄 DID 號碼範圍和分機號碼範圍（或站點內撥號習慣）。根據這些信息，需要選擇站點間轉向數字。
表 固定長度擴展範圍 顯示了三個位置和固定長度擴展範圍的範例。由於需要避免重疊的撥號習慣，因此必須確保任何分機號碼範圍的第一位數字與短程站點間撥號的轉向數字不符。例如，如果選擇 8 作為站點間撥號的轉向數字，則任何站點中的任何分機號碼都不能以 8開頭。通常情況下，某個位置的分機號碼與分配給該位置的 DID 號碼的最後幾位數字相符。為避免衝突，可以更改分機號碼的第一位數字。例如，如果DID在 +1 如果某個地點使用了 408、555 和 8XXX 範圍的號碼，那麼該網站的擴充號碼範圍可以改用 7XXX，而不是 8XXX。
| 網站 | 擴展範圍 | 分機 | 網站程式碼 | 企業級 |
|---|---|---|---|---|
| 紐約市 | 2XXX | 2XXX | 202 | 8 202 2XXX |
| 舊金山 | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
使用美國撥號方案的裝置撥打的七位撥號字串與預先載入的美國撥號方案中用於本地撥號的七位撥號模式重疊。為避免網內撥號及網外撥號（PSTN）習慣重疊，此位置可使用強制外部接取碼。如果現有的企業編號方案和相應的站點間短撥號與國家撥號模式重疊，那麼在過渡到編號方案時，為了避免重疊，也可以將其更改為更長或更短的形式。實現這一目標最簡單的方法是在編號方案中添加一個額外的填充數字。新的更長的站點間撥號方案只需要已遷移到的用戶採用。仍在線上的用戶可以繼續撥打七位數。在這種情況下，企業撥號方案需要確保從 Unified CM 到其他系統的七位短撥號碼能夠轉換為以下兩種方式之一： +E.164 或使用部署在 上的簡化撥號格式。這需要在向本地網關發送呼叫之前完成。
表格 過渡到七位撥號 顯示了這種重新編號的範例。在這個例子中，站點間撥號的縮寫形式是使用引導數字 8，後面跟著兩位數的站點代碼和四位數的分機號碼。為了避免對 上的地點使用七位數的縮寫站點間撥號，可以透過在 中使用的兩位站點代碼前添加任意填充數字（例如8 ）輕鬆地將站點代碼更改為三位數字，這樣，從電話撥打站點間電話時，將使用引導數字 8 ，後跟填充數字 8，舊的兩位分代碼。使用者無需記住新的網站代碼；他們只需記住在站點間撥號時使用 88 作為前綴，而不是 8 。
| 網站 | 分機 | 站點代碼 | 企業級 | 站點 ode | 企業天使 |
| 紐約市 | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| 舊金山 | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
如果企業號碼格式不同，且企業號碼會顯示為呼叫方資訊（例如，沒有 DID 的裝置撥打的電話），則必須實現呼叫方資訊的不同號碼格式之間的映射，以確保回撥功能正常運作。可以透過在本地網關和主幹線路之間使用呼叫方轉換模式來實現這種映射。
錄製檔
一個架構完善的通話錄音解決方案需要仔細考慮幾個關鍵的設計要素，以確保其符合組織目標、監管要求和技術限制。兩個最關鍵的決策涉及供應商選擇和地區選擇，這兩項決策可能都需要在全球範圍內進行調整，並根據業務需求在特定地點進行調整。
1. 選擇通話錄音服務供應商
選擇合適的通話錄音服務提供者對於實現業務目標和確保組織內功能一致性至關重要：
-
全球供應商選擇： 企業通常會在全球範圍內指定一家主要的通話錄音服務供應商，以確保所有地區的功能、合規性和支援保持一致。
-
基於位置的覆蓋： 在特定地點或地區有特殊業務需求或監管要求的情況下，可能需要涵蓋全域供應商選擇，並為這些地點指定替代供應商。這種靈活性能夠滿足不同的合規要求和本地營運需求。
-
業務需求： 選擇服務提供者時，應基於對業務驅動因素的評估，例如監管合規性（例如MiFID II、HIPAA）、品質保證、爭議解決或培訓需求。
-
功能可用性： 應根據服務提供者提供所需功能的能力對其進行評估，例如即時監控、搜尋和回放功能、加密、保留策略、與分析平台的整合以及對不同呼叫類型（呼入、呼出、內部）的支援。
2. 區域選擇
確定通話錄音的儲存和處理區域對於合規性和效能至關重要：
-
全球區域選擇： 預設情況下，組織可以選擇單一區域來儲存通話錄音，以簡化管理和治理。
-
基於位置的區域覆蓋： 根據資料駐留法律或公司政策的要求，可能需要針對特定位置覆蓋全球區域設置，以確保通話錄音在規定的地理範圍內儲存和處理。
-
資料駐留要求： 該設計必須考慮到國際和本地資料保護法規（例如 GDPR、CCPA 或特定國家/地區的強制性規定），這些法規可能會規定通話錄音的保存地點和方式。
在規劃和設計通話錄音解決方案時，需要解決的另一個關鍵方面是儲存需求的估算。準確預測儲存需求對於確保有足夠的容量來支援持續的業務運作、保持合規性以及避免服務中斷至關重要。
在確定預期儲存需求時，應考慮以下幾個關鍵參數：
-
錄音通話量： 評估在給定的時間間隔內（例如，每天、每週或每月）預計會記錄的通話數量。這不僅包括對外通話，還包括內部溝通，如果業務政策或監管要求需要的話。
-
平均通話時長： 計算錄音通話的典型時長，因為通話時間越長，佔用的儲存空間就越多。不同部門或使用者群體之間的通話時長差異也應納入估算。
-
保留期： 確定錄音必須保留的時間長度，這通常由組織政策或外部法規（例如行業特定的合規標準）規定。更長的保質期將增加整體儲存需求。
-
成長預測： 考慮預期呼叫量的成長或錄音範圍的擴大，這可能是由於業務規模擴大、新的監管要求或新增使用者或地點所致。
透過徹底分析這些參數，組織可以製定強大的儲存策略，從而確保其通話錄音解決方案的可擴展性、成本效益和合規性。隨著使用模式隨時間推移而變化，建議定期審查和調整儲存分配。
緊急呼叫
任何提供 PSTN 服務的呼叫服務都必須將緊急呼叫轉移到相應的調度中心。有了它，緊急呼叫路由功能就內建在解決方案中，並支援所有支援的國家/地區的國家緊急號碼。緊急呼叫的路由是根據呼叫方定義的位置以及該位置的 PSTN 存取方式來決定的。緊急號碼是預先設定的，並且特定於用戶和設備部署所在的國家/地區。
有兩種方法可以撥打緊急電話。有基本緊急呼叫路由服務和增強型緊急呼叫路由服務。基本的緊急呼叫路由服務將使用管理員選擇的號碼來識別位置和呼叫路由，從而聯繫緊急服務部門。對於基本的緊急呼叫，呼叫路徑通常會透過客戶在該地點的公共交換電話網路 (PSTN) 選項。此外，還提供增強型緊急呼叫路由，專為美國和加拿大的部署而設計，這些部署有監管合規性要求，需要使用全國性服務提供者將緊急呼叫轉移到正確的調度中心。
所有客戶應至少部署基本的緊急呼叫配置。基本的緊急呼叫要求至少有一位客戶擁有 +E.164 將編號指派給定義在 中的每個位置。對於基本的緊急呼叫，每個地點都將由一個街道地址定義，在緊急情況下，警察、消防或救護服務將被派往該地址。在大多數情況下，位置的主要編號是代表緊急情況實際位置的最佳選擇。通常情況下，地址的分配是 +E.164 號碼與PSTN提供者協調。下面的圖片顯示了 Richardson 地點分配用作緊急回撥號碼的主要號碼。
在大多數情況下，建築物地址足以作為該地點的調度地址。但是，如果需要特定使用者或設備的額外位置詳細信息，則管理員可以使用上述相同的流程，將這些設備分配給特定地址或地址內更精確的位置（例如樓層或房間）。在 使用者管理 中， 呼叫 標籤允許為使用者及其裝置使用特定號碼來取得特定調度位址。以下圖片顯示如何為設備指派一個特定的編號。管理員負責確保設備使用的號碼已分配正確的派送位址。地址分配通常由該地區的公共交換電話網路 (PSTN) 提供者完成。
對於必須提供增強型緊急呼叫解決方案的美國電話部署，使用 RedSky 的 Horizon Mobility 整合到緊急呼叫路由。使用 RedSky 進行呼叫路由時，管理員必須透過 Cisco 註冊帳戶，並在 Calling 中設定相應的資訊。 -> 服務設定 以啟用此功能。在系統層級啟用 RedSky 服務後，管理員將在每個位置層級啟用 RedSky 服務。在某個地點啟用增強型緊急呼叫功能後，分配給該地點的所有裝置都會啟動該服務。支援增強型緊急呼叫的設備包括 Cisco MPP 電話、Cisco PhoneOS 電話和 Cisco 的 。
有兩種設定可用於在某個位置啟用增強型緊急呼叫功能。應該使用 允許 RedSky 接收網路連接資訊和測試呼叫 來驗證 RedSky 設備和基礎設施映射的配置是否正確。此設定還允許撥打 933 進行測試呼叫，以使用 RedSky 的 IVR 系統執行位置驗證，讀取呼叫者的位置。雖然本文檔不會涵蓋 RedSky 的位置追蹤配置，但管理員應始終在啟動緊急呼叫路由到 RedSky 之前測試其位置發現功能。一旦測試完成並驗證準確無誤，管理員將透過切換「將緊急呼叫路由到 RedSky」選項，將呼叫路由到 RedSky。此開關會將該地點的所有緊急呼叫轉移到 RedSky，再由 RedSky 轉接到該地點的應答中心。
增強型緊急呼叫設定同樣適用於公司內部和外部的客戶。在公司內部，可以像追蹤桌上型電話一樣追蹤它們。當用戶不在公司時，可以直接在應用程式中動態設定他們的位置。有關緊急呼叫的更多信息，請參閱 增強型緊急呼叫。
授權
有多種方法可以為使用者分配許可證。
手動分配
管理員透過介面手動為各個使用者分配許可證。
管理員可以編輯單一使用者的服務許可證，並直接指派呼叫許可證。
自動許可證分配模板
使用許可證分配模板，根據群組或組織設定自動為使用者分配許可證。
自動許可可以透過目錄同步或手動使用者更新來實現，但使用者必須擁有有效的許可證。 +E.164 格式化的電話號碼，並且這些電話號碼必須在使用者配置之前存在於某個位置。如果條件不滿足（例如電話號碼格式無效），則不會指派許可證。
透過 CSV 模板進行批量分配
上傳包含使用者詳細資料和許可證分配的 CSV 文件，即可一次新增或修改多個使用者。
CSV 匯入支援新增最多 20,000 個使用者並分配許可證，但許可證需要電話號碼和分機號碼等特定欄位。
基於 API 的分配
使用 API 以程式方式指派許可證和管理使用者。
支援使用者和許可證管理的 API 操作（人員、SCIM 2.0 和許可證 API），可用於許可證分配自動化。許可證 API 允許同時分配許可證、電話號碼和分機號碼。
| 賦值方法 | 優點 | 缺點 |
|---|---|---|
| 手動操作 | 簡單易用，適合少數用戶。 允許對許可證分配進行精確和細緻的控制。 | 不具備可擴展性，且耗時。 手動輸入容易出現人為錯誤。 |
| 自動許可證模板 | 可擴充 減少人為錯誤 可應用於新用戶和現有用戶。 | 需要提供有效的電話號碼和地址。 設定起來更複雜。 此外，還需要為每個使用者群組設定具有同等許可要求的使用者群組。 |
| 批次上傳 CSV 文件 | 對大型用戶集來說很高效 允許同時分配許可證、電話號碼和分機號碼。 | 需要仔細格式化 CSV 文件 如果電話號碼或分機號碼缺失或錯誤，則可能發生錯誤。 |
| 基於 API 的分配 | 可自動化，靈活。 允許同時分配許可證、電話號碼和分機號碼。 | 需要具備開發和API知識。 |
表 使用者配置選項 - 概要 總結了使用者配置選項及其優缺點。此概述有助於根據客戶組織規模、自動化能力以及使用者配置流程和要求選擇最佳的許可證分配方法。
Cisco 建議盡可能使用許可證範本來指派呼叫許可證。這就要求對於每個需要不同授權的使用者群組（例如 - 標準版與專業版），都存在一個具有相應群組成員資格的群組。如 使用者群組 部分所述，使用者群組可以在企業目錄中手動定義，也可以從企業目錄同步。兩種方法結合起來也是可行的。
屬於多個群組的使用者將獲得應用於其所有群組的所有分配的許可證。這樣就可以在企業目錄中使用特定於許可證的安全群組來管理許可證分配，其中最終的使用者許可證分配由群組成員資格的共同控制。
有關更多信息，請參閱 在 Control Hub 中設定自動許可證分配 和 為 Webex Calling 用戶設定自動許可證分配模板。
許可證要求
本節僅涵蓋相關許可證。其他許可證類型（例如 Webex 設備註冊、訊息傳遞、會議）不包含在內。作為設計過程的一部分，需要確定許可證要求。需要計算以下幾種許可證類型的許可證數量：
-
標準: 需要標準電話功能的個人使用者數量。
-
專業的: 需要進階電話功能的使用者和工作區數量。虛擬線路和群組語音信箱有權享有以下服務： 1:1 每種專業執照的比例。因此，在極少數情況下，當所需的虛擬線路或群組語音郵件數量超過需要進階電話功能的使用者和工作區數量時，就需要考慮額外的專業授權。
-
公共區域工作空間: 需要標準通話功能的共享使用或公共區域位置數。
-
客戶服務: 需要客戶協助功能的客服人員及主管人數。客戶協助服務包括專業執照。
-
路由清單調用: 本機用戶之間所需的雲端連線 PSTN 通話數量 and/or 本地部署的第三方專用應用程式。
-
服務生控制台: 需要存取助手控制台客戶端的使用者數量。
-
Cisco 通話計劃（外撥計劃）: 需要PSTN號碼的使用者數量 and/or Cisco PSTN 服務的出站 PSTN 呼叫存取。
專業工作區沒有專門的許可證類型。專業工作區需要專業版許可證。
僅提供共享辦公桌的工作空間提供共享辦公桌主機服務和來自共享辦公桌主機的緊急呼叫，並且不需要任何許可證。有關更多信息，請參閱 添加和管理僅限共享辦公桌的設備。
若要根據所需功能決定每個使用者和工作區所需的許可證類型，請參閱 Webex Calling 按許可證類型提供的功能。
若要區分呼叫佇列與專業授權結合提供的功能與客戶協助提供的功能，請參閱 Webex Calling 呼叫佇列與客戶協助功能比較。
使用者佈建
在 Webex 中配置使用者時，有多種選項可供選擇，每種選項都適用於不同的組織需求和環境：
-
手動配置: 管理員可以直接在系統中新增和管理單一使用者。這種方法簡單直接，但最適合小型組織或使用者變更有限的情況。
-
透過 CSV 檔案批量配置: 對於使用者數量較多的情況，管理員可以透過上傳 CSV 檔案批次匯入和更新使用者。這樣可以同時有效率地管理多達數千名用戶。
- 目錄同步選項：
目錄連接器: 這是微軟Active Directory環境中使用的自動同步工具。它會按計劃（每小時、每天或每週）同步使用者帳戶、群組和屬性。它支援多網域和多林 Active Directory 設置，並且可以同步設定檔映像和會議室物件。
Entra ID（Azure AD）精靈應用程式: 此方法專為使用 Microsoft Entra ID (Azure AD) 的組織而設計，可實現使用者帳戶和屬性從 Entra ID 到 Azure AD 的自動、近乎即時的同步。它完全由系統內部管理，只需要極少的設定。
SCIM 2.0 應用: 對於非微軟環境或其他身分識別提供者（如 Okta 或 Duo），基於 SCIM 的同步應用程式可實現自動使用者配置和取消配置，並支援屬性對應和群組同步。
-
統一 CM 用戶同步: 此選項允許透過從現有最終用戶同步到現有最終用戶來建立用戶帳戶。這要求雲端連接統一通訊（CCUC）在本地叢集上運作。但是，通常建議從 Entra ID 等集中式雲端目錄同步用戶，而不是直接從本地同步。
-
API配置: 可以使用公共 API（People、SCIM 2.0）來設定使用者。使用 API 的主要好處是可以將使用者配置與其他企業系統整合。
此概述和表格反映了主要的使用者配置選項、它們的優點和局限性，以幫助您選擇最適合您組織需求的方法。表 6. 使用者配置選項 配置方法 說明 優點 缺點 手動 Create/manage 使用者單獨 使用者數量少時操作簡單；無需基礎設施 不具備可擴展性；對許多用戶來說耗時較長 批量（CSV 檔案） Import/update 透過 CSV 檔案批次匯入用戶 適用於團隊協作；無需編程 手動準備 CSV 檔案；動態性較低 人員和 SCIM 2.0 API 透過 Webex API 進行程式化使用者管理 靈活；支援自動化和集成 需要開發和基礎設施 目錄同步 自動同步來自 AD、Entra ID、SCIM 應用程式和統一設定管理 自動化生命週期；支援篩選和映射 設定複雜度：部分選項功能有限或需要基礎設施。
使用者群組
使用者群組管理允許管理員將使用者組織成群組，以便有效率地大量管理許可證、設定和資源。群組透過同時將策略、授權和設定範本應用於多個用戶，而不是單獨管理用戶，從而簡化管理。
使用者群組管理有以下幾個優點：
-
簡化管理 : 一次性管理多個使用者的許可證、設定和策略。
-
一致性: 在同一組使用者中套用統一的設定和許可證。
-
可擴展性: 每個群組最多可容納 25 萬名成員。
-
一體化: 從 Microsoft Entra ID (Azure AD) 或 Active Directory 同步群組，實現使用者和群組的自動化管理。
-
靈活性: 建立本機群組或同步安全性群組；手動或透過 CSV 檔案管理群組成員。
-
資源分配: 根據群組成員身分控制對嵌入式應用程式和服務的存取權。
使用者群組在配置過程中的主要應用場景包括：
-
許可證分配: 將許可證分配給群組，以便自動為群組成員提供通話、會議、訊息傳遞或混合服務等服務。
-
設定模板: 將服務設定集合（例如，訊息傳遞、會議、通話）應用於群組，以獲得一致的使用者體驗。
-
批量用戶管理 : 透過 CSV 檔案或目錄同步批次新增或刪除使用者。
-
自動化和集成 : 使用 API 或目錄同步實現使用者和群組生命週期的自動化管理。
下表總結了管理使用者群組和群組管理的不同選項。
| 選項 | 說明 | 優點 | 缺點 |
|---|---|---|---|
| 群組配置（群組） | 直接在 .中建立和管理群組。Add/remove 手動新增或透過 CSV 檔案新增成員。 | 對群組成員資格擁有完全控制權 立即應用許可證和模板 建立和編輯群組都很方便 |
需要手動更新 手動上傳CSV檔案有出錯風險 不支援與外部目錄自動同步 |
| 從 Entra ID（Azure AD）或 Active Directory 同步群組 | 自動從外部目錄服務同步安全性群組和成員關係。 | 自動同步減少了人工工作 確保與公司名錄保持一致 支持大型組織 |
無法編輯群組成員資格 同步延遲最長可達 12 小時 嵌套組需要手動選擇 |
| 群組和 SCIM 2.0 API（群組） | 使用 Groups 或 SCIM 2.0 API 進行程式化群組和成員管理 | 自動化以及與其他系統的集成 可擴展以適應大型或複雜環境 |
需要開發工作 複雜性取決於 API 的使用情況 |
雖然同步群組可以確保一致性並提供單一的管理點，但也可以採用混合方法，將同步群組和群組（在控制中心管理或透過 API 管理）結合起來。例如，許可證分配組可以是同步群組，而分配使用者和呼叫範本可以使用另一組單獨的群組。
這種全面的使用者群組管理方法使組織能夠有效地管理使用者授權、設定和策略，從而確保一致且可擴展的協作體驗。
從到遷移的建議方法
使用者的主要資料來源是資料庫，其中包含最終使用者資訊。然而，它通常不是使用者身分管理的權威來源，更重要的是，它將在過渡結束時關閉，因此被排除在身分資訊的長期權威來源之外。
Cisco 建議使用集中式雲端目錄（例如 Microsoft Entra ID (Azure AD)）作為使用者身分的唯一真實來源。將 Entra ID 中的使用者同步，可確保一致性，簡化管理，並支援單一登入 (SSO) 功能。
為確保所有使用者也存在於 Entra ID 中，各組織應核實使用者帳戶是否與 Entra ID 中的帳戶相對應。這可以透過從 Entra ID 匯出使用者清單並將其與 Entra ID 使用者清單進行比較來實現。
總而言之，建議的設定方法是使用 Azure AD 精靈或 SCIM 應用程式將使用者從 Microsoft Entra ID (Azure AD) 同步到 Webex。手動和 CSV 批量配置可作為補充方法，但對於大型組織而言，其可擴展性較差，更容易出錯。確保 Entra ID 是權威來源，並且所有使用者都存在於 Entra ID 中，對於成功遷移和跨環境的一致使用者體驗至關重要。
從本機目錄服務（如 Active Directory）過渡到雲端目錄服務（如 Entra ID (Azure ID)）與呼叫過渡無關。Cisco 建議在開始呼叫系統遷移之前，先完成向雲端目錄服務的遷移。
使用者群組設計
將企業目錄從本地端遷移到雲端後，根據授權和功能範本要求收集所需的使用者群組。對於每個群組文檔：
-
群組名稱：該團體的獨特名稱。
-
授權：若要指派給該群組的許可證（如有）以及範圍（許可證是分配給現有使用者還是僅指派給新使用者）
-
設定模板：Webex 應用程式和使用者呼叫範本。
-
目錄同步：這個群組是從企業目錄同步的，還是在 Control Hub 或透過 API 配置的本機 Webex 群組？
-
說明：這個群組將如何使用？哪些用戶應該成為這個群組的成員？
這些細節將在實施階段用於建立本機群組或企業目錄中的群組，並管理使用者的群組成員身分。
單一登入（SSO）
Cisco 建議使用 SSO 進行使用者身份驗證。使用單一登入 (SSO) 具有一些顯著的優勢，包括：
-
簡化使用者身份驗證： 使用者可以使用其企業憑證（例如 Azure ID）登入一次，即可存取其他整合應用程序，從而無需多個密碼，並減少登入提示。這樣可以確保企業密碼在身份驗證後永遠不會被儲存或傳輸，從而增強安全性。
-
簡化用戶管理： 根據公司目錄的變更自動建立、更新和停用使用者帳戶，從而減少管理開銷，並確保只有授權使用者才能存取。
-
安全性提升： SSO 透過受信任的身份提供者 (IdP) 集中進行身份驗證，從而減少密碼疲勞和與密碼相關的洩露風險。
-
輕鬆整合多因素身份驗證 (MFA)： MFA 可以透過 Cisco Duo 等身分存取管理解決方案輕鬆實現，也可以透過 IdP 的 MFA 支援實現。
實現服務單一登入 (SSO) 有多種方案：
-
基於 SAML 2.0 的單一登入： 支援 SSO 整合的主要協議，可在身分識別提供者 (IdP) 和服務提供者之間安全地交換身分驗證資訊。
-
OpenID Connect (OIDC)： 支援作為 SSO 整合的替代現代身份驗證協定。
-
Webex身分： 同時支援作為身分提供者選項。
SSO 透過集中配置和管理，需要在和所選的身份提供者 (IdP) 之間交換元資料。
配置完成後，可以在啟動前對 SSO 進行測試，以確保設定正確。
Cisco 支援與多種經過測試且常用的身分識別提供者 (IdP) 和身分識別管理系統 (IAM) 集成，包括但不限於：
-
思科雙核
-
Okta
-
微軟活動目錄聯合身分驗證服務 (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 BIG-IP。
這些身分提供者符合 SAML 2.0 或 OpenID Connect 標準，並且經過驗證，與 Cisco 協作解決方案相容。
支援多個身分提供者
允許組織配置具有多個身分提供者的 SSO，以適應複雜的 IT 環境，例如合併、收購或分散的 IT 部門，其中不同的群體使用不同的身分提供者。可以透過使用 Cisco Duo 等企業 IAM 系統中的多 IdP 功能來實現多 IdP 支持，也可以透過整合該系統來實現。
的多重身分提供者 (IdP) 支援可滿足組織在各種 IT 環境中進行靈活、安全的身份驗證的幾個關鍵用例：
1. 合併與收購
當公司合併或收購其他公司時，它們通常擁有獨立的 IT 基礎設施和不同的身分提供者，這些提供者無法進行聯合。支援多個身分提供者 (IdP) 可以讓兩個組織的使用者進行身份驗證並安全地協作，而無需立即統一他們的身份系統。
2. 多個獨立的IT部門
大型組織或政府機構可能擁有多個獨立的 IT 部門，每個部門管理自己的身分提供者 (IdP)。的多身份提供者功能使這些部門能夠維護自己的身份驗證系統，同時允許用戶無縫存取。
3. 不同的使用者群組或網域
擁有不同使用者群組（例如，員工與承包商）或多個電子郵件網域的組織可以設定路由規則，根據網域或群組成員資格將身分驗證請求導向至對應的身分提供者。這支援差異化的存取策略和安全控制。
4. 支援多種身份驗證協議
支援 SAML 和 OpenID Connect (OIDC) 身分提供者，讓組織可以根據其現有的基礎架構和安全要求整合不同類型的身分提供者。
5. 增強安全性和合規性
透過啟用多個身分提供者 (IdP)，組織可以實施更強大的身分驗證機制，包括透過 Duo 等整合實現多因素身分驗證 (MFA)，並在不同的使用者群體中強制執行一致的安全性策略。
6. 簡化的使用者體驗
使用者可以使用各自身分提供者 (IdP) 提供的現有憑證進行驗證，從而提供統一的登入體驗，即使底層存在多個身分系統的複雜性。
雖然支援多種身分提供者 (IdP) 提供了靈活性，但這需要安全性和身分識別團隊之間仔細協調，以保持一致的安全策略並避免潛在的漏洞。
雙 MFA 與 SSO
Duo Access Gateway (DAG) 可以使用現有的本機或雲端目錄（例如 Active Directory (AD) 和 OpenLDAP）對使用者進行身份驗證。它還支援與其他身分識別提供者（如 Microsoft ADFS、Microsoft Azure、Okta、OneLogin、CAS 和 Shibboleth）的整合。這種靈活性使得組織能夠使用其現有的目錄基礎架構來實現具有 Duo MFA 的 Webex SSO。
Duo 在主目錄驗證之上提供了一個強大的身份驗證層。它作為身分提供者 (IdP) 使用 SAML 2.0 來強制執行雙重認證 (2FA)，然後再授予存取權限。Duo 會根據可設定的策略評估使用者、裝置和網路環境，以允許或拒絕訪問，從而增強安全性，而不僅僅依賴使用者名稱和密碼。Duo 還提供靈活的策略控制，例如對某些應用程式要求每次登入時都進行 MFA 驗證，而對其他應用程式則要求較少頻率的 MFA 驗證。
Cisco Duo 的優點包括：
-
增強安全性： 增加防釣魚的多因素身份驗證 (MFA) 以保護訪問，降低密碼洩露的風險。
-
靈活的政策： 允許對每個應用程式或使用者群組的身份驗證要求進行精細控制。
-
與現有目錄整合： 支援本地 AD、OpenLDAP、雲端目錄和各種 SSO 供應商，最大限度地減少基礎架構變更。
-
用戶便利性： 支援單一登入 (SSO)，使用戶只需登入一次即可安全地存取多個資源，從而減少密碼疲勞。
-
可信賴端點： 支援 Windows 和 macOS 用戶端的裝置信任，提高安全性。
-
自助註冊： 線上註冊和雙重提示可改善 MFA 設定過程中的使用者體驗。
雙重認證 (Duo MFA) 結合單一登入 (SSO)，利用現有目錄（如 Active Directory 和 OpenLDAP）或雲端身分提供者來驗證使用者身分。Duo 的角色是透過 SAML 2.0 整合強大的、策略驅動的第二因素身份驗證，在透過 SSO 增強安全性的同時保持用戶便利性。其優點包括：增強安全態勢、靈活執行策略、無縫整合以及更好的使用者體驗。
Cisco建議為使用者實施SSO。為了增強安全性，建議與 Cisco Duo 整合。
企業身分與存取管理 (IAM) 和單一登入 (SSO) 策略應在開始從 [此處應填入系統名稱] 過渡到 [此處應填入系統名稱] 之前部署。
功能
具備該服務所包含的所有核心功能。這包括許多企業級通話功能，這些功能已經存在多年。您可能無法看到功能和功能之間 100% 的對等性，但是，正如您在下圖中所看到的，關鍵的通話功能在 中可用。
除了眾多使用者功能外，該平台還包含一些核心系統功能。這些功能包括自動應答、呼叫佇列、呼叫駐留等。您可以在 服務 → 通話 → 功能 下查看所有可用的核心系統功能，如圖 Webex 通話核心功能所示。
自動語音應答
自動應答系統允許 24/7 實現來電處理的自動化，無需人工接聽每個來電即可高效處理來電。
自動應答系統會接聽來電，並為來電者提供一系列選項，供其選擇將電話轉接到哪裡。這可以是給某人、語音信箱或呼叫服務（例如呼叫佇列）。來電者使用手機撥號鍵盤從自動應答選單輸入號碼。
自動應答系統支援以下主要功能：
-
工作時間和非工作時間安排
-
假日排程
-
撥號選單選項，引導您的客戶前往他們需要去的地方
-
自訂問候語
-
按名稱撥號選項
-
來電轉接選項
-
控制中心分析和報告。
有關更多信息，請參閱 管理自動助理。
呼叫駐留
呼叫駐留功能使用戶能夠輕鬆地將通話 置於保持狀態 ，以便其他用戶在有空時輕鬆取回通話。它還允許接聽原始電話的用戶在通話保持期間撥打或接聽其他電話。
有兩種類型的呼叫停車服務可供選擇。 :
-
呼叫駐留直撥 - 允許任何使用者將呼叫駐留到其他使用者的分機號碼或管理員定義的呼叫駐留分機號碼。
-
呼叫駐留群組 - 允許指定使用者群組自動將呼叫駐留到為該群組定義的可用駐留目的地。這些目的地可以是群組成員的分機號碼或呼叫停車分機號碼。
根據配置和停車類型，用戶可以透過撥打 來找回呼叫。 *88+><extension of parked call>，按下與呼叫駐留分機關聯的線路鍵，或使用其 IP 電話上的軟鍵。
使用者可以設定召回選項，在指定時間後將已停放的呼叫召回給停放呼叫的使用者或備用使用者。
有關更多信息，請參閱 控制中心中的呼叫駐留管理。
來電代接
呼叫代接功能允許管理員定義一組使用者（成員），他們可以接聽其他成員的電話。這樣，當隊友忙碌而無法接聽來電時，用戶可以接聽電話。
同一組使用者必須位於同一地點。
用戶可以使用手機或辦公桌上的電話接聽電話。
-
:
-
支援視覺和音訊通知
-
來電通知
-
基於FAC的撥號 *98) 或通知彈出視窗接聽
-
多線路來電接聽通知。
-
-
桌上型電話：
-
來電通知
-
透過手機 LED 指示燈發出聲音提示和視覺通知。6821 型號僅支援音訊提示音。
-
當選擇的通知類型不是 無
-
-
僅對主線路發送來電接聽通知。
-
更多資訊請參閱 設定呼叫代接群組。
呼叫佇列
其核心功能包括純語音通話佇列，任何擁有專業版授權的使用者都可以成為呼叫佇列的一員，擔任座席或主管。此功能使用戶能夠有效率地與客戶互動。呼叫佇列支援呼叫中心的一些核心功能，例如語音佇列、回撥、技能或優先權路由、座席佇列管理、分析、報告等。
Cisco 呼籲整合 Microsoft Teams，讓客服人員可以直接透過 Microsoft Teams 用戶端存取呼叫佇列呼叫和功能。
呼叫隊列支援以下主要功能：
-
問候與留言（歡迎、安慰、輕聲細語等）
-
待話期間背景音樂
-
回撥
-
佇列路由策略（夜間服務、假日、轉送）
-
代理隊列 login/logout
-
代理佇列狀態管理
-
或桌上型電話支援
-
主管代理呼叫監控、指導、插話或透過功能存取代碼 (FAC) 接管
-
（管理員權限）適用於：
-
隊列管理
-
代理和隊列分析及報告
-
隊列、代理和主管管理。
-
有關更多信息，請參閱 配置呼叫隊列。
它具有客戶協助附加功能，可提供額外的呼叫佇列功能，並為代理商和主管提供更好的使用者體驗。有關呼叫佇列和客戶協助功能的比較，請參閱 Webex Calling 呼叫佇列和客戶協助功能比較。
群組搜尋
呼叫群組允許透過預先設定的呼叫路由模式，將呼入呼叫路由到特定的使用者群組。這樣可以確保電話由正確的使用者群組接聽，或前往語音信箱進行後續跟進。
呼叫群組和呼叫佇列之間的一個很大的區別是，呼叫在呼叫群組中不會排隊，因此，如果呼叫群組中沒有使用者可以接聽電話，則該電話將被斷開、發送到語音信箱或轉發到另一個號碼（使用者或服務）。
有關更多信息，請參閱 在 Control Hub 中管理狩獵組。
操作模式
運作模式功能可讓企業有效率地將呼叫路由到各種目的地（使用者、語音信箱、呼叫服務，如呼叫佇列）。呼叫的路由地點和時間取決於一天中的時間和一周中的日期安排，任何使用者都可以被授權管理這些模式（安排），以控制呼叫路由的變更。
例如，呼叫佇列的呼叫可以路由到另一個呼叫佇列，由不同時區的客服人員在非工作時間接聽電話；在工作時間內，呼叫可以路由到本地客服人員；在假日，呼叫可以路由到語音信箱，以便在客服人員返回辦公室後進行跟進。
授權使用者可以根據需要更改來電在特定時間段內的路由方式，在這些不同的呼叫轉移方案（模式）之間進行切換。這些用戶可以透過他們的…來管理這些模式。 6800/7800/8800 MPP 電話、9800 電話或在使用者中心 管理模式。
有關更多信息，請參閱 Webex Calling 中基於操作模式的呼叫路由。
傳呼群組
尋呼群組允許用戶發起單向呼叫，向一組用戶發送語音訊息。每個群組最多可包含 75 個目標用戶 and/or 透過撥打預先定義的號碼或分機號碼即可存取的工作區。
當使用者呼叫尋呼群組時，會同時呼叫群組內所有指定目標，此時呼叫者可以說出他們的留言，並在說完後掛斷電話。
有關更多信息，請參閱 在 Control Hub 中配置分頁組。
錄製檔
支援錄製使用者撥打或接聽的電話。這可能是出於品質保證、安全保障或訓練方面的需要。預設情況下，通話會被錄音，但如果需要其他錄音功能或合規性和監管要求，也可以使用其他第三方錄音提供者。
當使用該平台進行錄音時，所有錄製的通話都在其中進行管理。具有合規官角色的完整管理員可以播放和下載錄影。如果沒有合規官角色，管理員只能刪除錄音。
有關此功能的更多資訊以及第三方錄音列表，請參閱 管理 Webex Calling 的通話錄音。
單一號碼存取
單一號碼通話功能允許撥打用戶電話號碼的來電同時響鈴多個裝置。這包括其他座機以及手機。用戶還可以透過這些裝置撥打電話，並且可以在這些裝置之間推送和拉取電話。
有關此功能的更多資訊以及管理員如何在 中配置它，請參閱 配置單一號碼存取（隨時隨地辦公）。
如需了解使用者如何在 Webex 使用者中心（入口網站）中自行管理和設定此功能，請參閱 設定單號碼存取（隨時隨地辦公）。
語音信箱群組
語音信箱群組允許共用語音信箱，可以將其指派給使用者或用於呼叫路由功能。設定語音信箱群組的一些原因包括：
-
部門或工作小組通用語音信箱
-
為自動應答機或呼叫群組新增語音信箱選項
-
從呼叫佇列發送溢位呼叫
-
只需要語音信箱的用戶。
有關更多信息，請參閱 管理 Webex Calling 的共享語音郵件和入站傳真箱。
Webex 的「呼叫功能」頁面上列出了話務員控制台，但它是一個附加功能，需要購買話務員控制台許可證才能使用。
有關更多信息，請參閱 開始使用助理控制台。
有關所有功能（包括一些附加功能）的信息，請參閱 Webex Calling 按許可證類型提供的功能。
執行
網路整備
過渡到雲端的第一步是確保本地網路和雲端之間 可靠、安全的 網路連線。
由於大多數組織透過一個或多個 防火牆 或 安全設備連接到互聯網，因此驗證 所需的流量是否得到支援至關重要 。
網路和安全管理員必須從以下幾個方面來理解這些流程：
-
方向 （入站 vs 出站）
-
協定 （例如：SIP TLS、SRTP、HTTPS）
-
服務使用的 IP 位址範圍
-
必須開啟或允許的連接埠號碼 。
這樣可以確保企業防火牆、NAT 設備和其他網路基礎架構得到正確配置，以適應流量，同時維護企業安全策略。
有關所需流程（包括 IP 位址、連接埠和協定）的信息，請參閱 Webex Calling 的連接埠參考資訊。利用這些資訊配置現有部署中的防火牆、代理程式和其他網路基礎設施，以啟用網路流量。
對於雲端協作服務，建議採用從每個分公司或站點進行去中心化網路存取的方式。透過允許流量從本地流出，該模型：
-
減少往返延遲和抖動，提高整體通話質量
-
隨著更多用戶和網站過渡到新平台，可高效擴展。
-
與 SD-WAN 無縫協作，可將會話動態路由到最近的雲端入口點，以實現最佳效能。
- 允許根據用戶的公共 IP 位址追蹤用戶位置，這有助於媒體路徑分析和故障排除。
此外，各機構必須確保每個站點都有足夠的網路頻寬。頻寬的大小應根據預期的同時呼叫數、所選編解碼器（例如 Opus 或 G.711）以及訊號、重傳和成長的開銷來決定。這與 PPDIO 生命週期的準備階段相一致，並為遷移奠定了堅實的基礎。
初始設定
部署實施階段的初始設定小節是建立結構良好且易於管理的雲端呼叫環境的基礎。此階段包括一些關鍵任務，例如建立組織、取得和分配許可證，以及驗證和認領公司域名，以確保適當的使用者管理和安全。此外，它還包括提供許可證範本以自動分配使用者許可證，配置單一登入 (SSO) 以簡化使用者身份驗證和增強安全性，以及調整服務和用戶端設定以符合組織政策和使用者需求。完成這些初始設定活動可確保環境配置得當，以實現可擴展性、安全性和流暢的使用者體驗，為後續的部署和營運階段奠定基礎。
網域驗證
為了能夠識別在貴公司電子郵件網域上註冊的用戶，驗證您的網域至關重要。如果沒有進行網域驗證，用戶將被分配到消費者組織，這將使貴公司的用戶管理變得複雜。網域驗證是必要的步驟，它可以讓您的組織有效地認領和管理這些使用者。
請確保與使用者電子郵件地址關聯的所有網域均已驗證。域名驗證並非排他性的；同一個域名可以在多個組織中進行驗證。
有關管理域名的更多信息，請參閱 管理您的域名。
認領（轉換）現有用戶
成功驗證網域後，您可以將已註冊使用貴公司電子郵件網域的使用者新增至您的組織。此流程將所有使用者整合到一個組織框架下，從而實現集中管理和簡化管理。透過認領這些用戶，您可以確保公司對用戶帳戶擁有完全控制權，從而能夠有效地分配適當的授權、配置服務並提供必要的支援。這種統一的管理方法增強了安全性，簡化了使用者配置，並確保了整個組織對服務的一致存取。認領使用者還可以防止他們在外部或消費者組織中被管理，從而維護組織的完整性和對協作資源的控制。
有關認領用戶的更多信息，請參閱 將用戶認領到您的組織（轉換）用戶。
配置並測試目錄同步
為了實現無縫的使用者和群組管理，您可以將企業目錄中的使用者和群組（無論是 Microsoft Entra ID（以前稱為 Azure AD）還是 Microsoft Active Directory (AD)）同步到 。此流程可確保使用者身分和群組成員資格在您的環境中保持一致。
對於實施分階段部署的組織而言，在初始推廣階段控制和限制同步範圍至關重要。這樣可以最大限度地降低意外變更的風險，並允許在更廣泛採用之前進行有針對性的測試。
篩選同步使用者最有效的方法是利用目錄群組成員關係：
| 1 |
建立專用同步群組： 在企業目錄（Microsoft Entra ID 或 AD）中，建立一個專門用於同步的安全性群組（例如，同步群組）。 |
| 2 |
將目標用戶加入群組： 僅將您想要同步的使用者（例如試點階段的測試群組）新增至此群組。這樣可以讓你嚴格控制哪些人參與同步過程。 |
| 3 |
配置基於群組的篩選同步協定： 在 Directory Connector 或 Entra ID 設定中設定同步協定時，請將範圍設定為僅包含指定群組的成員使用者。
|
| 4 |
根據需要擴展群組： 隨著部署階段的推進，只需在同步群組中新增其他使用者或群組即可。同步範圍將自動擴大到包括這些用戶，從而實現可控和漸進式的推廣。 範例實施步驟：
參考： |
設定並測試單一登入 (SSO)
單一登入 (SSO) 透過允許使用者使用其企業憑證進行一次身份驗證並無縫存取來增強安全性並簡化使用者存取。支援與符合 SAML 2.0 標準的身份提供者 (IdP) 的 SSO 集成，包括 Microsoft Entra ID（以前稱為 Azure AD）、Active Directory (AD) 聯合解決方案和各種第三方身分提供者。
此時應該實施並測試已設計的 SSO 設定。
參考：
取得、提供和核實許可證
作為初始設定的一部分，必須採購、提供和驗證適當的許可證，以有效地啟用和管理服務。採購流程包括根據使用者角色和工作負載選擇授權類型，例如專業版、標準版和工作區版授權。許可證透過思科的軟體平台或合作夥伴產生和分配。採購和配置完成後，需要核實許可證數量是否正確。此流程可確保組織擁有已啟動並可用於部署的正確許可證。
作為初始許可設定的一部分，配置基於組織的自動許可對於簡化新使用者的許可證分配至關重要。這種設定允許在將使用者新增至組織時自動授予許可證，從而無需手動分配許可證。在組織層級配置自動許可時，您可以選擇要指派的服務並定義範圍，例如僅將授權套用至未來的用戶，或也包含現有使用者。
但是，如果您的部署計劃涉及在群組層級使用自動許可，您可以選擇不在組織層級分配許可證，以避免衝突或重複的許可證分配。透過群組層級自動許可，許可證是根據群組成員身分分配的。多個使用者群組的使用者將獲得所有適用群組分配的許可證。
必須在目錄同步完成後執行基於群組的許可證分配配置，以便同步群組存在並可用於許可證分配。
具體來說，自動許可證分配需要額外的配置詳細信息，例如用戶位置和電話號碼分配。使用者的工作電話號碼必須已輸入。 +E.164 格式已設定好，已預先配置，並已指派給有效位置，以便許可證自動啟動。如果這些條件不滿足，則不會自動為使用者提供服務，可能需要人工幹預。
總而言之，如果您想要進行廣泛的、組織範圍內的授權分配，請為新使用者設定基於組織的自動許可。如果您希望進行更精細的控制，或者每個群組有不同的許可需求，請在群組層級配置自動許可，避免在組織層級分配許可證，以防止重疊並確保正確的許可證管理。
Webex 通話服務設定
對全域服務設定進行全面審查和配置至關重要。
首先訪問並導航至設定部分。仔細檢查每個可設定選項，包括但不限於內部撥號配置、緊急呼叫參數、呼叫路由策略、語音郵件管理和設備預設設定。
調整這些全局設置，以反映貴組織的政策和設計決策。
此外，還要設定設定、使用者和應用程式模板。
試辦移民
在實施階段，執行試點遷移是驗證從到過渡的關鍵里程碑。此試點計畫涉及在一個或多個地點為平台提供代表性的使用者子集，以確保所選用戶群體反映多樣化的使用案例和組織角色。在用戶遷移的同時，包括語音郵件、自動應答、呼叫佇列和呼叫組在內的重要協作服務必須過渡到其等效版本，以維持業務連續性和服務功能。
試點遷移應利用思科提供的工具和第三方遷移實用程式的組合，這些工具和實用程式計劃用於更廣泛的組織部署，以確保在代表性條件下對流程、自動化工作流程和整合點進行徹底驗證。
本次試點部署的主要目標有兩個：首先，驗證並改善端到端過渡流程，包括使用者配置工作流程、資料遷移程序和終端配置；其次，全面驗證遷移服務在實際運作條件下的功能。
這種分階段的方法使專案團隊能夠在受控環境中識別和糾正任何技術或程序問題，收集使用者對新平台體驗的回饋，評估所選遷移工具的有效性，並在進行更廣泛的組織部署之前建立對遷移方法的信心。
本次試點階段所獲得的見解對於優化後續遷移浪潮、確保整個企業平穩過渡並降低風險至關重要。
採購公共交換電話網
若要為 [此處應填寫特定名稱] 取得 PSTN 服務，首先在 [此處應填寫特定名稱] 中選擇 PSTN 連線選項。
如果一個組織計劃維持混合雙呼叫控制（ 階段 1 在圖 分階段呼叫轉換：對於混合雲和雲端)，無論是暫時的還是永久的，他們都需要為本地 PSTN 部署一個或多個本地網關，以允許在端點之間進行呼叫。
如果最終目標是全面過渡到雲端（ 第 2 階段），包括 PSTN，那麼 PSTN 將需要 Cisco Calling Plan 或 Cloud Connect 選項。
與您選擇的服務提供者合作，訂購和轉移電話號碼，然後再進行配置。訂購電話號碼或發起端口訂單僅 required/possible 適用於本地 PSTN 和 Cloud Connect。對於 Cisco 通話計劃，一旦建立位置，即可在 Control Hub 內啟動訂購和連接埠轉移，且此流程適用於 Cisco 通話計劃可用的國家/地區。有關 Cisco Calling 套餐的更多信息，請參閱 Cisco 套餐入門。
作為 PSTN 實施的一部分，請確保您的服務提供者已為您的位置啟用入站和出站 PSTN 服務。此外，請執行測試呼叫，以驗證呼叫是否透過您選擇的 PSTN 連線正確路由。
配置位置
在向系統中新增使用者和設備之前，必須先配置呼叫位置。每個地點都必須輸入有效的街道地址。在美國和加拿大，該位址經過驗證，並由平台用於發送緊急呼叫的 PIDF-LO 位置資訊。
配置使用本地 PSTN 的位置時，需要相應地設定本地網關。在[此處應填入系統名稱]中，必須為每個本機閘道建立一個中繼和一個路由組，然後將路由組指派為該位置的 PSTN 選擇。Cisco 強烈建議始終選擇路由組作為 PSTN 選擇，因為這種方法可以方便地在將來添加額外的中繼，從而支援可擴展性和冗餘性。Cisco 還建議在每個 PSTN 中繼上啟用雙重身分和 P-Charge-Info 支持，因為這簡化了對撥出直撥或轉撥電話的計費方的識別。如果您的 PSTN 供應商使用不同的計費標頭，您可以將本地網關上的 P-Charge-Info 標頭中的資訊複製到所需的計費標頭中。
對於使用 Cloud Connect 或 Cisco Calling Plan 作為其 PSTN 選項的位置，只需在設定期間為該位置選擇相應的 PSTN 選項即可。如果該位置使用 Cloud Connect 或本地 PSTN，則需要新增在上一個步驟中訂購的電話號碼。如果您不希望號碼立即包含在呼叫路由中，可以將其新增為非活動號碼；您可以在稍後將這些號碼指派給使用者或功能時啟動它們。
務必為每個地點設定主號碼。主號碼可以分配給使用者或功能，例如自動語音應答系統。若要在該地點啟用語音信箱，請確保設定語音信箱引導號碼，也稱為語音入口網站號碼。
呼叫位置的其他設定包括配置緊急呼叫詳細信息，例如緊急回撥號碼、通知選項和增強的緊急呼叫功能。您還應根據每個地點的需要，檢查並調整錄音設定、語言偏好和設備配置。如果您的組織使用帶有企業重要號碼的縮短的站點間網路撥號，請記住在內部撥號設定中為位置配置唯一的站點代碼。最後，如果對外撥號需要撥出撥號數字，請務必在對外撥號設定中進行設定。在設定出站撥號數字時，思科建議啟用出站撥號數字強制執行，以確保一致性。
與本地呼叫控制系統集成
要與本地呼叫控制集成，需要設定中繼線、路由組、企業撥號計畫以及位置和全域設定。首先設定用於與本機呼叫控制系統互連的中繼線和本機閘道；只有在需要專用中繼線時才需要執行此步驟。如果現有的中繼和路由組足以滿足您的部署需求，則可以將其用於本地互連，而無需額外配置。
一旦中繼線和路由群組建立完畢，就可以開始建立企業撥號計劃，並將對應的路由群組指派給每個撥號計劃作為目標。當整合涉及透過不同中繼線連接的多個本地呼叫控制系統時，將需要多個撥號方案。務必確保這些撥號方案僅包含將呼叫路由到本地目的地所需的模式。
如果您的部署需要支援未知擴充路由，則應在位置層級啟用此功能。此外，當啟用未知分機路由時，必須在呼叫服務設定的 呼叫路由和場所之間 部分中指定最大未知分機長度。這確保了在整合環境中實現無縫的呼叫路由和基於分機撥號場景的正確處理。
分批遷移用戶
當您將使用者從 [系統名稱] 遷移到 [系統名稱] 時，可能無法同時遷移所有使用者。這可能是由多種原因造成的，包括但不限於網站或使用者數量、網站遷移所需時間等。 and/or 同一時間的使用者群、支援變更視窗的 IT 或網站資源有限、變更視窗持續時間、變更的複雜性等。
分階段遷移使用者時，確定哪些使用者需要在同一 批次中一起遷移至關重要。主要目標是將那些在呼叫服務和功能方面存在依賴關係的使用者一起遷移。您希望確保其所有呼叫功能（例如呼叫隊列）在過渡到新系統後都能像過渡之前一樣完全正常運作。
即使您實現了本機網關之間的呼叫互通，您也無法透過此連線拆分共用服務或功能。因此，您需要透過查看以下特徵來確定使用者之間的依賴關係：
-
使用 BLF 監控其他用戶
-
在同一狩獵飛行員、呼叫隊列等中
-
共用線路
-
使用電話接聽
-
使用相同的呼叫駐留號碼
-
內部通訊
-
Executive/Admin.
例如，某個使用者是正在過渡到新版本的 Hunt Group 的成員。該用戶將過渡到 Hunt Group，並與 Hunt Group 的所有其他成員進行互動。因此，過渡完成後，Hunt Group及其成員可以在新平台上成功接聽電話。
當用戶因不同的通話服務和功能而連接到不同的用戶群組時，這會變得更加具有挑戰性。這將需要同時對多組用戶和一個呼叫服務進行遷移。
使用您在 準備 階段使用的 Migration Insights 工具或第三方工具的輸出結果，確定哪些使用者和功能應該分組在一起。此輸出結果應該用於制定遷移計劃，並能幫助您了解如何將需要一起遷移的使用者和功能進行分組。
批量用戶遷移的關鍵步驟如下：
-
確定要一起遷移的用戶
-
確認所有用戶均已登入
-
驗證所有使用者的 TN 是否存在
-
請核對目錄中電話號碼格式是否正確。
-
請確保使用者群組的許可和設定範本已正確設定。
-
驗證或配置使用者群組的所有呼叫服務和功能（在過渡之前或期間，視情況而定）
-
在公司目錄中，將使用者新增至已啟用通話的使用者群組。
-
利用工具－使用者和功能遷移工具 and/or 第三方工具
-
Disable/Delete user/device 電話號碼查詢和呼叫 features/services 過渡之後。
遷移完一組用戶後，測試一部分用戶，以驗證其所有呼叫功能和服務是否正常運作。如果呼叫佇列、呼叫群組等呼叫功能會隨使用者群組一起遷移，則測試這些呼叫服務的功能是否正常。
工作區
在[此處原文缺失]，工作區指的是可以分配設備、分機和使用者的共享位置（例如會議室、小型討論空間或共享辦公桌）。與傳統的統一通訊管理 (Unified CM) 電話不同，工作區具有以下特點：
-
以位置為中心：與物理空間相關。
-
設備靈活：可配備一個或多個設備（桌上型電話、白板等）。
一旦確定了過渡到新系統所需的工作區，就可以在「設備」下添加它們。每個工作區都需要分配設備，如果它們已經在 Unified CM 中，則需要重設或重新配置。可啟用或停用語音郵件、呼叫轉移和呼叫代接等功能，並可依需求套用視訊通話、呼叫駐留和行動策略。透過撥打內部和外部電話、測試視訊、會議和行動功能來測試每個工作區。最後，告知使用者有關工作空間設備和預訂的任何適用流程。
有關工作區的更多信息，請參閱 工作區。
供應設備
目前已註冊的手機需要遷移到新系統，作為雲端遷移的一部分。為了盡可能簡化遷移過程，並將失敗的可能性降到最低，思科建議同時遷移實體站點或部門。但是，由於功能依賴性，您可能需要分批遷移使用者。有關更多詳細信息，請參閱 “分批遷移用戶 ”部分。
任何需要從中遷移過來的支援電話都需要配置為使用者或工作區，實體電話需要重新配置才能註冊。此外，7800 和 8800 系列電話需要將其韌體從企業韌體升級到多平台電話 (MPP) 韌體。該過程包括在載入註冊所需的 MPP 韌體之前載入過渡固件。此外，還需要相應的遷移許可證。思科在過去幾年中改進了這個流程，讓您更容易將企業韌體電話升級到 MPP 韌體。有關完成韌體升級的步驟的更多信息，請參閱 在企業版和 MPP 韌體之間轉換 Cisco 7800 和 8800 系列 IP 電話。
除了本文中概述的步驟之外，還有一個內建工具 將您的電話遷移到 Webex Calling，您可以使用該工具幫助您將 7800 和 8800 電話從企業版韌體遷移到 MPP 韌體。該工具還允許您將手機新增至相應的使用者或工作區，並將其分配給相應的使用者或工作區。有關工具使用的更多信息，請參閱 遷移您的手機。
對於已註冊的 9800 系列手機，上述韌體遷移要求不適用。這些手機運行 PhoneOS，該系統同時受到 和 的支援。要將這些電話遷移到 Webex Calling，您需要將它們新增至 Webex Calling，將它們指派給使用者或工作區，然後將電話恢復原廠設定。PhoneOS 註冊啟動順序 下圖顯示了 PhoneOS 的啟動順序，以及手機添加到 [此處應填寫系統名稱] 後如何註冊，即使手機仍在 [此處應填寫系統名稱] 上配置 and/or DHCP 選項（例如 - 150）正在使用中。
支援將 PhoneOS 設備恢復出廠設置，從而實現零接觸入駐。管理員可以透過 CUCM 管理頁面遠端將 9800 和 8875 電話恢復出廠設置，從而無需實體存取電話即可完成入駐。此功能自 2025 年 9 月 9 日起在設備包中支援：
-
CUCM v15 - 統一通訊管理器版本 15
-
CUCM v14 - 統一通訊管理器版本 14。
有關 9800 系列註冊流程的更多信息，請參閱 註冊流程。
除了 Cisco IP 電話之外，可能還需要設定其他設備 ，例如類比電話適配器 (ATA)、無線 (Wifi、DECT) 電話、視訊設備、語音閘道以及第三方設備和電話。許多此類設備不像 IP 電話那樣有韌體升級途徑，無法從企業韌體過渡到雲端韌體。因此，您需要在控制中心配置這些設備。有些設備無法直接過渡，需要用同等型號的設備來替代（例如ATA）。 191/192) 還有一些需要手動重新配置。 and/or 軟體變更。
- 語音網關 - 若要遷移本機網關，請參閱 遷移本機網關。
有關在 Control Hub 中配置語音網關 VG400、VG410 或 VG420 的更多信息，請參閱 本地網關
-
類比電話適配器 (ATA) - 若要開始使用 Cisco ATA 191 和 192，請參閱 Cisco ATA。
-
Wifi 無線電話 - 若要整合無線電話 840 和 860，請參閱 整合 Webex 無線電話。
-
DECT 無線電話 - 若要開始使用您的新 Cisco IP DECT 6800 系列，請參閱 Cisco IP DECT。
若要在 Control Hub 中建置和管理數位 DECT 網絡，請參閱 管理 DECT 網路
有關 Cisco IP DECT 6800 的更多信息，請參閱 部署指南
-
第三方設備和手機 -與 第三方供應 商合作 device/phone 要求以及遷移或替換這些要求的過程以提供支援。
設定功能
任何所需的通話功能都需要在過渡之前或期間進行設定。如在「分批遷移使用者」部分所討論的，當使用這些功能的使用者進行遷移時，需要配置和遷移呼叫功能。
有關如何配置各項功能的詳細信息，請參閱相應的配置幫助文章。
驗收測試
驗收測試確保遷移後的環境符合功能要求，按預期運行，並在所有通訊工作流程中提供無縫的使用者體驗。此驗證過程涉及多個方面，涵蓋從用戶配置和號碼分配到高級呼叫功能的運行性能等各個方面。
本節提供範例並重點介紹驗收測試期間需要考慮的關鍵方面；但是，它並非旨在作為詳盡或全面的檢查清單。
用戶配置和號碼分配
驗收測試的一個基礎面向是驗證所有使用者是否已在系統中準確、完整地配置。這需要對來源目錄和新建立的用戶群進行徹底比較，以確保每個用戶帳戶及其相關屬性（例如分機號碼和直接撥入號碼 (DID) 分配）都已正確遷移。配置的完整性不僅對第一天的運作至關重要，而且對後續的管理和支援也至關重要。
號碼分配驗證包括確認每個使用者都分配了正確的分機號碼和外部號碼，並且這些號碼在內部（網內）和外部（PSTN）呼叫流程中都能正確路由。必須檢查是否有重疊、缺少分配或配置錯誤，這些都可能導致呼叫路由錯誤或服務中斷。
PSTN通話流程與來電顯示
一個完善的驗收測試程序必須包含 PSTN 通話流程的端對端驗證。這包括呼入和呼出兩種情況。對於 PSTN 來電，測試團隊應確認通話是否已送達至預期的終端，無論是個人使用者、呼叫佇列、呼叫群組或自動話務員。必須成功撥出 PSTN 電話，尤其要注意正確傳遞和顯示來電顯示訊息。這包括確保按照組織政策和監管要求，向外部接收者顯示正確的來電者姓名和號碼。
測試還應涵蓋故障轉移場景，例如處理無法存取的端點或網路中斷。這有助於確認回退機制和備用路由是否正常運行，從而維持服務的連續性和可靠性。
網內呼叫流程
內部或網內呼叫流程構成了企業通訊的骨幹。該領域的驗收測試驗證了組織內使用者之間的通話是否正確路由，以及呼叫轉移、保持、轉送和會議等功能是否如預期運作。必須確認撥號方案的完整性、分機之間的連接性以及對組織呼叫策略的支援。
使用者呼叫處理和功能驗證
驗收測試的一個重要方面是驗證使用者如何使用 和支援的桌面電話處理通話。此流程的重點是確認日常通話工作流程是否直觀可靠，以及使用者是否能夠無縫存取其角色所需的核心功能。測試應評估使用者撥打和接聽電話、管理保持和恢復功能以及執行盲轉和諮詢轉接的便利程度。此外，還必須確認呼叫轉移、電話會議和其他進階功能（如呼叫保留和恢復或啟用「請勿打擾」功能）是否可用且運作順暢。
應評估使用者體驗的清晰度和回應速度，並考慮使用者如何與通話記錄、語音郵件和整合目錄進行互動。還應特別注意在設備之間轉移通話的功能，以及在應用程式或實體電話上有效使用通話控制功能的功能。最終目標是確保遷移後最終使用者體驗的一致性、高效性，並能充分滿足組織的溝通需求。
呼叫佇列：代理人和主管經驗
呼叫佇列常用於處理大量來電的情況。這裡的驗收測試著重於以下幾個方面。首先，應驗證呼叫是否依照配置的佇列邏輯（例如輪詢、最長空閒或同時振鈴）指派給座席。必須檢查座席桌面上排隊呼叫的顯示方式是否清晰易用，以確保座席能夠有效率地接聽、保持和轉接通話。
對於主管人員來說，應該評估桌面體驗的功能，例如即時監控、呼叫介入以及佇列效能分析或洞察。這包括但不限於驗證提供有關呼叫分配、座席活動和佇列指標的可操作資料的儀表板和報告工具。
搜尋群組：呼叫分配
呼叫群組是將呼叫指派給預定義使用者集的關鍵機制。驗收測試需要確認呼叫是否根據配置的尋呼演算法路由到群組成員，以及是否依照設計處理溢位、轉送和無應答情況。確保群組成員資格和呼叫路由行為與先前建立的行為一致，對於營運一致性和使用者滿意度至關重要。
自動語音應答：公告和選單操作
自動應答器代表了自動呼叫處理的第一道防線。測試必須涵蓋公告的播放、錄製問候語的準確性以及選單樹的正確操作。選單選擇應能可靠地將來電者路由到相應的部門、個人或外部號碼。測試還應包括無效或逾時場景，以確認呼叫者是否收到清晰的指導或按預期被重定向。
語音信箱操作
最後，語音信箱功能對使用者體驗至關重要。驗收測試應驗證語音信箱是否已正確分配，以及是否可以從組織內部和遠端存取。必須確認具備記錄、檢索和管理訊息的功能，以及通知送達功能。
最佳化
PSTN 遷移到 Cloud Connect
一旦所有終端和使用者都遷移到雲端呼叫，Unified CM 的唯一目的就是充當 PSTN 閘道和本地網關之間的傳輸通道。使用 Cloud Connect 作為所有 Webex Calling 用戶的 PSTN 存取方式，從系統中移除 PSTN 網關和本地網關，具有許多優勢，包括降低成本和提高可靠性。若要將本機 PSTN 存取遷移到 Cloud Connect，請依照下列步驟操作：
-
Cloud Connect 用於合作夥伴選擇。
請參閱 Cloud Connect 合作夥伴列表，並從中選擇適用於您組織所在地的合作夥伴。
-
Cloud Connect 用於驗證。
在將 PSTN 存取點切換到 Cloud Connect 之前，應先驗證並確認透過選定的 Cloud Connect 合作夥伴與 PSTN 的連線。為此，需要配置一個測試地點，並在該測試地點配置一些測試使用者。然後，將此測試地點的 PSTN 存取設定為 Cloud Connect 合作夥伴，之後使用測試電話驗證 PSTN 連線。驗證成功後，即可取消測試地點的配置。
-
號碼轉移。
為了準備切換到 Cloud Connect，需要對目前分配給終止於此的 PSTN 中繼線的所有號碼下達連接埠訂單。所有號碼都需要轉移到 Cloud Connect 合作夥伴處。為了保持不同地點之間的可及性，所有地點的所有號碼都需要同時進行攜號轉網。
-
切換到 Cloud Connect 合作夥伴。
在切換之日，所有地點的 PSTN 存取都需要設定為雲端連接 PSTN 供應商，並且應驗證入站和出站連線。
如設計章節的 PSTN 部分所述，客戶也可以選擇在過渡開始時將其 PSTN 接取遷移到 Cloud Connect，以便使用 PSTN 中繼進行混合部署。有關更多信息，請參閱 混合 Webex Calling 部署的 PSTN 中繼。在這種情況下，過渡期間 PSTN 存取是透過本地網關進行的，並且在將所有使用者遷移到本地網關之後，除了停用本地網關之外，沒有其他與 PSTN 相關的遷移步驟。
優化本地基礎設施
一旦所有使用者都已遷移到雲端註冊，並且所有端點都已遷移到雲端註冊（或已停用），現在雲端呼叫正在使用，請更新相應的本地基礎架構。基礎設施更新包括：
-
從本機 DNS 伺服器中刪除本機呼叫控制和訊息 DNS SRV 記錄，包括 cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. 這些 SRV 記錄不再用於客戶端服務發現。
-
從公用 DNS 系統中刪除與邊緣相關的 DNS SRV 記錄，包括 collab_edge._tls.<domain>. 這些 SRV 記錄不再是客戶端發現協作邊緣服務所必需的。
-
更新所有相關的 DHCP 作用域，移除選項 66 和選項 150。 TFTP/boot 伺服器位址。這些作用域不再用於端點呼叫控製配置的發現和下載。
-
Update/remove 本地適當的撥號對等體 Gateway/CUBE 此路由調用與 Unified CM 之間的通訊。這些撥號對等體不再是本地呼叫路由所必需的。
-
刪除或移除所有叢集節點虛擬機 and/or 伺服器. 根據需要重新分配計算資源和硬體。這些資源不再用於呼叫控制和邊緣服務。
-
刪除或移除所有叢集節點虛擬機 and/or 伺服器. 根據需要重新分配計算資源和硬體。語音郵件和統一訊息服務不再需要這些資源。
-
清理：將 PSTN 存取遷移到雲端連接 PSTN 後，可以停用 PSTN 中繼線、PSTN 閘道和本機閘道。
-
對於任何現有的本機 E911 解決方案，刪除已遷移到的任何位置或號碼，並在完全過渡完成後，刪除應用程式虛擬機器或伺服器。根據需要重新分配計算資源和硬體。這些資源不再用於緊急呼叫和定位服務。
-
應將屬於已遷移使用者的 DN 放置在隱藏分區中，以避免呼叫路由失敗，並確保所有 CSS 都能優先存取相同 DN 的雲端路徑。
-
當發生變更時，更新 Horizon Mobility 中的實體可調度位置和網路元素。需要更新的常見活動包括：
-
網路交換器更換
-
無線接入點更換
-
DHCP作用域變更
-
建築物內部的物理變化（如果決定進行） cubical/office)
-
建築物內部辦公空間的實際擴張或收縮。
-
利用分析和故障排除
提供全面的分析和故障排除功能，幫助您視覺化和追蹤部署情況。這些功能包括媒體品質、詳細通話記錄、呼叫佇列、呼叫組和自動應答分析。圖 [] 顯示了媒體品質分析的範例 媒體品質分析。
在故障排除中，可以使用以下信息查看每次呼叫，其中包含有關關鍵媒體品質和信令相關問題的詳細信息，以幫助確定媒體問題以及呼叫失敗的原因，如圖 媒體品質故障排除所示。
故障排除功能還可以與其他思科產品（如 ThousandEyes 和 Meraki 交換器）集成，從而在 Control Hub 中提供更豐富的集成體驗。有關使用 Webex Calling 分析和故障排除的更多信息，請參閱 Control Hub 中的 Webex Calling 通話故障排除。
