- 主页
- /
- 文章
感谢您的反馈。
迁移部署指南
在此文章中
反馈？从本地部署的 Cisco Unified CM 到云端的结构化迁移过程 Webex Calling，采用 PPDIO 方法。这涉及到关键的设计考量。 例如区域选择、拨号方案、紧急服务和通话录音。这个过程也 详细说明许可、用户配置、单点登录和网络就绪情况，以确保顺利和 高效过渡。
介绍
准备工作
本指南适用于有配置和管理 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 Calling Plans 或由 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 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日当周 |
| 旧金山国际机场（1600 位用户） | 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 呼叫队列和客户协助功能比较。
User provisioning（用户设置）
在 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 通话故障排除。
