过渡到 Webex Calling 的第一步是确保本地网络和 Webex 云之间 可靠且安全的 互联网连接。

由于大多数组织通过一个或多个 防火墙 或 安全设备连接到互联网，因此验证 所需的流量是否得到支持至关重要 。

网络和安全管理员必须从以下几个方面理解这些流程：

• 方向 （入站 vs 出站）

• 协议 （例如：SIP TLS、SRTP、HTTPS）

• Webex 服务使用的 IP 地址范围

• 必须打开或允许的端口号 。

这样可以确保企业防火墙、NAT 设备和其他网络基础设施得到正确配置，以适应 Webex Calling 流量，同时维护企业安全策略。

有关所需流程（包括 IP 地址、端口和协议）的信息，请参阅 Webex Calling 的端口参考信息。使用这些信息配置现有部署中的防火墙、代理和其他网络基础设施，以启用 Webex Calling 网络流。

对于 Webex Calling 等云协作服务，建议采用从每个分支机构或站点分散式互联网接入的方式。通过允许流量从本地流出，该模型：

• 减少往返延迟和抖动，提高整体通话质量

• 随着越来越多的用户和网站迁移到 Webex Calling，其扩展性非常出色。

• 与 SD-WAN 无缝协作，可将会话动态路由到最近的 Webex 云入口点，以实现最佳性能。

• 允许根据用户的公共 IP 地址跟踪用户位置，这有助于媒体路径分析和故障排除。

此外，各机构必须确保每个站点都有足够的互联网带宽。带宽的大小应根据预期的并发呼叫数、所选编解码器（例如 Opus 或 G.711）以及信令、重传和增长的开销来确定。这与 PPDIO 生命周期的准备阶段相一致，并为迁移奠定了坚实的基础。

在部署 Webex Calling 的实施阶段中，初始设置小节是建立结构良好且易于管理的云通话环境的基础。此阶段包括关键任务，例如建立控制中心组织、获取和分配许可证，以及验证和认领公司域名，以确保适当的用户管理和安全。此外，它还包括提供许可证模板以自动分配用户许可证，配置单点登录 (SSO) 以简化用户身份验证和增强安全性，以及调整服务和客户端设置以符合组织政策和用户需求。完成这些初始设置活动可确保 Webex Calling 环境配置得当，以实现可扩展性、安全性和流畅的用户体验，为后续的部署和运营阶段奠定基础。

在实施阶段，执行试点迁移是验证从 Unified CM 过渡到 Webex Calling 的一个关键里程碑。该试点项目涉及在一个或多个地点为 Webex Calling 平台提供具有代表性的用户子集，以确保所选用户群体反映多样化的使用案例和组织角色。在用户迁移的同时，包括语音邮件、自动应答、呼叫队列和呼叫组在内的重要协作服务必须过渡到 Webex Calling 的相应功能，以维持业务连续性和服务功能。

试点迁移应利用思科提供的工具和第三方迁移实用程序的组合，这些工具和实用程序计划用于更广泛的组织部署，以确保在代表性条件下对流程、自动化工作流和集成点进行彻底验证。

本次试点部署的主要目标有两个：首先，验证和完善端到端过渡流程，包括用户配置工作流程、数据迁移程序和终端配置；其次，在实际运行条件下全面验证迁移服务的功能。

这种分阶段的方法使项目团队能够在受控环境中识别和纠正任何技术或程序问题，收集用户对新平台体验的反馈，评估所选迁移工具的有效性，并在进行更广泛的组织部署之前建立对迁移方法的信心。

本次试点阶段获得的见解对于优化后续迁移浪潮、确保整个企业平稳过渡并降低风险至关重要。

要为 Webex Calling 获取 PSTN 服务，首先在控制中心选择 PSTN 连接选项。

如果一个组织计划维持混合双呼叫控制（ 阶段 1 在图 分阶段呼叫转换中：对于混合云和云部署（无论是暂时的还是永久的），他们需要为本地 PSTN 部署一个或多个本地网关，以允许 Webex Calling 和 Unified CM 端点之间进行呼叫。

如果最终目标是完全过渡到云（ 第 2 阶段），包括 PSTN，那么 PSTN 将需要 Cisco Calling Plan 或 Cloud Connect for Webex Calling 选项。

与您选择的服务提供商合作，订购和转移电话号码，然后在 Control Hub 中配置它们。订购电话号码或发起端口订单仅 required/possible 适用于本地 PSTN 和 Webex 通话的 Cloud Connect。对于 Cisco 通话计划，一旦创建位置，即可在 Control Hub 内启动订购和端口转移，并且此过程适用于 Cisco 通话计划可用的国家/地区。有关 Cisco Calling 套餐的更多信息，请参阅 Cisco 套餐入门。

作为 PSTN 实施的一部分，请确保您的服务提供商已为您的位置启用入站和出站 PSTN 服务。此外，请执行测试呼叫，以验证呼叫是否通过您选择的 PSTN 连接正确路由。

在向 Webex Calling 添加用户和设备之前，必须先配置呼叫位置。每个地点都必须输入有效的街道地址。在美国和加拿大，该地址经过验证，并由平台用于发送紧急呼叫的 PIDF-LO 位置信息。

配置使用本地 PSTN 的位置时，需要相应地设置本地网关。在 Webex Calling 中，必须为每个本地网关创建一个中继和一个路由组，然后将路由组分配为该位置的 PSTN 选择。Cisco 强烈建议始终选择路由组作为 PSTN 选择，因为这种方法可以方便地在将来添加额外的中继，从而支持可扩展性和冗余性。Cisco 还建议在每个 PSTN 中继上启用双重身份和 P-Charge-Info 支持，因为这简化了对拨出直拨或转拨电话的计费方的识别。如果您的 PSTN 提供商使用不同的计费标头，您可以将本地网关上的 P-Charge-Info 标头中的信息复制到所需的计费标头中。

对于使用 Cloud Connect for Webex Calling 或 Cisco Calling Plan 作为其 PSTN 选项的位置，只需在设置期间为该位置选择相应的 PSTN 选项即可。如果该位置使用 Cloud Connect for Webex Calling 或本地 PSTN，则需要添加在上一步中订购的电话号码。如果您不希望号码立即包含在呼叫路由中，可以将其添加为非活动号码；您可以在稍后将这些号码分配给用户或功能时激活它们。

务必为每个地点设置主号码。主号码可以分配给用户或功能，例如自动语音应答系统。要在该地点启用语音信箱，请确保设置语音信箱引导号码，也称为语音门户号码。

呼叫位置的其他设置包括配置紧急呼叫详细信息，例如紧急回拨号码、通知选项和增强的紧急呼叫功能。您还应根据每个地点的需要，检查并调整录音设置、语言偏好和设备配置。如果您的组织使用带有企业重要号码的缩短的站点间网络拨号，请记住在内部拨号设置中为位置配置唯一的站点代码。最后，如果对外拨号需要拨出拨号数字，请务必在对外拨号设置中进行设置。配置出站拨号数字时，思科建议启用出站拨号数字强制执行，以确保一致性。

要与本地呼叫控制集成，需要配置中继线、路由组、企业拨号计划以及位置和全局设置。首先设置用于与本地呼叫控制系统互连的中继线和本地网关；只有在需要专用中继线时才需要执行此步骤。如果现有的中继和路由组足以满足您的部署需求，则可以将其用于本地互连，而无需额外配置。

一旦中继线和路由组建立完毕，就可以开始创建企业拨号计划，并将相应的路由组分配给每个拨号计划作为目标。当集成涉及通过不同中继线连接的多个本地呼叫控制系统时，将需要多个拨号方案。务必确保这些拨号方案仅包含将呼叫路由到本地目的地所必需的模式。

如果您的部署需要支持未知扩展路由，则应在位置级别启用此功能。此外，当启用未知分机路由时，您必须在 Control Hub 的呼叫服务设置的 Webex Calling 和场所之间的呼叫路由部分 中指定最大未知分机长度。这确保了在集成环境中实现无缝的呼叫路由和基于分机拨号场景的正确处理。

将用户从 Unified CM 迁移到 Webex Calling 时，可能无法同时迁移所有用户。这可能是由多种原因造成的，包括但不限于网站或用户数量、网站迁移所需时间等。 and/or 同时进行的用户组、支持变更窗口的 IT 或站点资源有限、变更窗口持续时间、变更的复杂性等。

分阶段迁移用户时，确定哪些用户需要在同一 批次中一起迁移至关重要。主要目标是将那些在调用服务和功能方面存在依赖关系的用户一起迁移。您希望确保所有通话功能（例如 - 呼叫队列）在 Webex Calling 上都能像在 Unified CM 过渡之前一样完全正常运行。

即使您通过本地网关实现了 Unified CM 和 Webex Calling 之间的呼叫互通，您也无法通过此连接拆分共享服务或功能。因此，您需要通过查看以下特征来确定用户之间的依赖关系：

• 使用 BLF 监控其他用户

• 在同一狩猎飞行员、呼叫队列等中

• 共用线

• 使用电话接听

• 使用相同的呼叫驻留号码

• 内部通信

• Executive/Admin.

例如，某个用户是 Unified CM Hunt Group 的一部分，而该组正在过渡到 Webex Calling。该用户将通过 Webex Calling 与呼叫组及其所有其他成员进行通话。因此，过渡完成后，Hunt Group及其成员可以在新平台上成功接听电话。

当用户因不同的通话服务和功能而连接到不同的用户组时，这会变得更加具有挑战性。这将需要同时将多组用户和一个通话服务迁移到 Webex Calling。

使用 Control Hub Migration Insights 工具或您在 准备 阶段使用的第三方工具的输出结果，确定哪些用户和功能应该分组在一起。此输出结果应该用于制定迁移计划，并能帮助您了解如何对需要一起迁移的用户和功能进行分组。

批量用户迁移的关键步骤如下：

• 确定要一起迁移的用户

• 确认所有用户都在控制中心。

• 确认所有用户的 TN 都存在于控制中心。

• 请核对目录中电话号码格式是否正确。

• 请确保用户组的许可和设置模板已正确设置。

• 验证或配置用户组的所有呼叫服务和功能（在过渡之前或期间，视情况而定）

• 在公司目录中，将用户添加到已启用呼叫的用户组。

• 利用工具 - 控制中心用户和功能迁移工具 and/or 第三方工具

• Disable/Delete user/device 电话号码查询和呼叫 features/services 过渡后使用统一配置管理。

迁移完一组用户后，测试一部分用户，以验证其所有调用功能和服务是否正常工作。如果呼叫队列、呼叫组等呼叫功能随用户组一起迁移，则测试这些呼叫服务的功能是否正常。

在 Webex Calling 中，“工作区”指的是可以分配设备、分机和用户的共享位置（例如会议室、小型讨论空间或共享办公桌）。与传统的统一通信管理 (Unified CM) 电话不同，工作区具有以下特点：

• 以位置为中心：与物理空间相关。

• 设备灵活：可以配备一个或多个设备（桌面电话、白板等）。

在向 Webex Calling 过渡的过程中，一旦确定了工作区，就可以在“设备”下的“控制中心”中添加它们。每个工作区都需要分配设备，如果它们已经在 Unified CM 中，则需要重置或重新配置以用于 Webex。Webex Calling 的语音信箱、呼叫转移和呼叫代接等功能可以启用或禁用，并且可以根据需要对视频通话、呼叫驻留和移动性应用策略。通过拨打内部和外部电话、测试视频、会议和移动功能来测试每个工作区。最后，告知用户有关工作空间设备和预订的任何适用流程。

有关 Control Hub 中工作区的更多信息，请参阅 工作区。

作为云迁移的一部分，目前已注册到 Unified CM 的电话需要迁移到 Webex Calling。为了尽可能简化迁移过程，并将失败的可能性降到最低，思科建议同时迁移物理站点或部门。但是，由于功能依赖性，您可能需要分批迁移用户。有关更多详细信息，请参阅 “分批迁移用户 ”部分。

任何需要从 Unified CM 过渡到 Webex Calling 的支持的电话都需要在 Webex Calling 上配置为用户或工作区，并且物理电话需要重新配置才能在 Webex Calling 中注册。此外，7800 和 8800 系列电话需要将其固件从企业固件升级到多平台电话 (MPP) 固件。该过程包括在加载 Webex Calling 注册所需的 MPP 固件之前加载过渡固件。此外，还需要相应的迁移许可证。思科在过去几年中改进了这一流程，让您更容易将企业固件电话升级到 MPP 固件。有关完成固件升级的步骤的更多信息，请参阅 在企业版和 MPP 固件之间转换 Cisco 7800 和 8800 系列 IP 电话。

除了本文中概述的步骤之外，Control Hub 还内置了一个工具 将您的电话迁移到 Webex Calling，您可以使用该工具帮助您将 7800 和 8800 电话从企业版固件迁移到 MPP 固件。该工具还允许您将电话添加到控制中心，并将其分配给相应的用户或工作区。有关工具使用的更多信息，请参阅 迁移您的手机。

对于已在 Unified CM 注册的任何 9800 系列电话，上述固件迁移要求不适用。这些手机运行 PhoneOS 系统，该系统同时受 Unified CM 和 Webex Calling 支持。要将这些电话迁移到 Webex Calling，您需要将它们添加到 Webex Calling，将它们分配给用户或工作区，然后将电话恢复出厂设置。PhoneOS 注册启动顺序 下图显示了 PhoneOS 的启动顺序，以及手机添加到 Control Hub 后如何注册到 Webex Calling，即使手机仍在 Unified CM 上配置。 and/or DHCP 选项（例如 - 150）正在使用中。

Unified CM 支持将 PhoneOS 设备恢复出厂设置，从而实现 Webex Calling 的零接触式注册。Unified CM 管理员可以通过 CUCM 管理页面远程将 9800 和 8875 电话恢复出厂设置，这样就无需物理访问电话即可将电话加入 Webex Calling。此功能自 2025 年 9 月 9 日起在设备包中得到支持：

• CUCM v15 - 统一通信管理器版本 15

• CUCM v14 - 统一通信管理器版本 14。

有关 9800 系列注册流程的更多信息，请参阅 注册流程。

除了 Cisco IP 电话之外，可能还需要配置其他设备，例如模拟电话适配器 (ATA)、无线 (Wifi、DECT) 电话、视频设备、语音网关以及^{第三方设备和} 电话。许多此类设备不像 IP 电话那样有固件升级途径，无法从企业固件过渡到云固件。因此，您需要在控制中心配置这些设备。其中一些功能无法迁移到 Webex Calling，需要用等效的 Webex Calling 模型来替代（例如 ATA）。 191/192) 还有一些需要手动重新配置。 and/or 软件变更。

• 语音网关 - 要迁移本地网关，请参阅 迁移本地网关。

  有关在 Control Hub 中配置语音网关 VG400、VG410 或 VG420 的更多信息，请参阅 本地网关

• 模拟电话适配器 (ATA) - 要开始使用 Cisco ATA 191 和 192，请参阅 Cisco ATA。

• Wifi 无线电话 - 要集成 Webex 无线电话 840 和 860，请参阅 集成 Webex 无线电话。

• DECT 无线电话 - 要开始使用您的新 Cisco IP DECT 6800 系列，请参阅 Cisco IP DECT。

  要在 Control Hub 中构建和管理数字 DECT 网络，请参阅 管理 DECT 网络

  有关 Cisco IP DECT 6800 的更多信息，请参阅 部署指南

• 第三方^{设备和手机} -与 第三方^供应 商合作 device/phone 支持 Webex Calling 的要求以及迁移或替换这些要求的过程。

Webex Calling 中所需的任何通话功能都需要在过渡之前或期间进行配置。如在“分批迁移用户”部分中所讨论的，当使用这些功能的用户进行迁移时，需要配置和迁移调用功能。

有关如何配置 Webex Calling 各项功能的详细信息，请参阅相应的配置帮助文章。

• 自动服务员 - 要管理自动服务员，请参阅 自动服务员

• 呼叫驻留 - 要管理呼叫驻留，请参阅 呼叫驻留

• 呼叫代接 - 要配置呼叫代接组，请参阅 呼叫代接

• 呼叫队列 - 要配置呼叫队列，请参阅 呼叫队列

• 狩猎组 - 要管理狩猎组，请参阅 管理狩猎组

• 操作模式 - 要了解基于操作模式的呼叫路由，请参阅 基于操作模式的呼叫路由

• 分页组 - 要配置分页组，请参阅 配置分页组

• 录音 - 要管理 Webex Calling 的通话录音，请参阅 管理录音

• 单号码接入 - 要配置单号码接入（任何办公地点），请参阅 配置单号码接入

• 语音邮件组 - 要管理 Webex Calling 的共享语音邮件和入站传真箱，请参阅 管理语音邮件。

验收测试确保迁移后的环境满足功能要求，按预期运行，并在所有通信工作流程中提供无缝的用户体验。该验证过程涉及多个方面，涵盖从用户配置和号码分配到高级呼叫功能的运行性能等各个方面。

本节提供示例并重点介绍验收测试期间需要考虑的关键方面；但是，它并不旨在作为详尽或全面的检查清单。

用户配置和号码分配

验收测试的一个基础方面是验证所有用户是否已在 Webex Calling 中准确、完整地配置。这需要对源（统一 CM）目录和新建立的 Webex Calling 用户群进行彻底比较，以确保每个用户帐户以及相关属性（例如分机号码和直接拨入 (DID) 分配）都已正确迁移。配置的完整性不仅对第一天的运行至关重要，而且对后续的管理和支持也至关重要。

号码分配验证包括确认每个用户都分配了正确的分机号和外部号码，并且这些号码在内部（网内）和外部（PSTN）呼叫流程中都能正确路由。必须检查是否存在重叠、缺失分配或配置错误，这些都可能导致呼叫路由错误或服务中断。

PSTN呼叫流程和来电显示

一个完善的验收测试程序必须包括对 PSTN 呼叫流程的端到端验证。这包括呼入和呼出两种情况。对于 PSTN 来电，测试团队应确认呼叫是否已送达至预期的终端，无论是个人用户、呼叫队列、呼叫组还是自动话务员。必须成功拨出 PSTN 电话，尤其要注意正确传递和显示来电显示信息。这包括确保按照组织政策和监管要求，向外部接收者显示正确的来电者姓名和号码。

测试还应涵盖故障转移场景，例如处理无法访问的端点或网络中断。这有助于确认回退机制和备用路由是否正常运行，从而维持服务的连续性和可靠性。

网内呼叫流程

内部或网内呼叫流程构成了企业通信的骨干。该领域的验收测试验证了组织内用户之间的呼叫是否正确路由，以及呼叫转移、保持、转发和会议等功能是否按预期运行。必须确认拨号方案的完整性、分机之间的连接性以及对组织呼叫策略的支持。

用户呼叫处理和功能验证

验收测试的一个重要方面是验证用户如何使用 Webex应用和支持的 桌面电话处理通话。该流程的重点是确认日常通话工作流程是否直观可靠，以及用户是否能够无缝访问其角色所需的核心功能。测试应评估用户拨打和接听电话、管理保持和恢复功能以及执行盲转和咨询转接的便捷程度。此外，还必须确认呼叫转移、电话会议和其他高级功能（如呼叫保留和恢复或启用“请勿打扰”功能）是否可用且运行顺畅。

应评估用户体验的清晰度和响应速度，并考虑用户如何与通话记录、语音邮件和集成目录进行交互。还应特别注意在设备之间转移通话的功能，以及在应用程序或实体电话上有效使用通话控制功能的功能。最终目标是确保迁移后最终用户体验的一致性、高效性，并能充分满足组织的沟通需求。

呼叫队列：代理人和主管经验

呼叫队列常用于处理大量来电的情况。这里的验收测试侧重于以下几个方面。首先，应验证呼叫是否按照配置的队列逻辑（例如轮询、最长空闲或同时振铃）分配给座席。必须检查座席桌面上排队呼叫的显示方式是否清晰易用，以确保座席能够高效地接听、保持和转接呼叫。

对于主管人员来说，应该评估桌面体验的功能，例如实时监控、呼叫介入以及队列性能分析或洞察。这包括但不限于验证提供有关呼叫分配、座席活动和队列指标的可操作数据的仪表板和报告工具。

寻线组：呼叫分配

呼叫组是将呼叫分配给预定义用户集的关键机制。验收测试需要确认呼叫是否根据配置的寻呼算法路由到组成员，以及是否按照设计处理溢出、转发和无应答情况。确保组成员关系和呼叫路由行为与之前在 Unified CM 中建立的关系一致，对于运营一致性和用户满意度至关重要。

自动语音应答：公告和菜单操作

自动应答器代表了自动呼叫处理的第一道防线。测试必须涵盖公告的播放、录制问候语的准确性以及菜单树的正确操作。菜单选择应能可靠地将呼叫者路由到相应的部门、个人或外部号码。测试还应包括无效或超时场景，以确认呼叫者是否收到清晰的指导或按预期被重定向。

语音信箱操作

最后，语音信箱功能对用户体验至关重要。验收测试应验证语音信箱是否已正确分配，以及是否可以从组织内部和远程访问。必须确认具备记录、检索和管理消息的功能，以及通知送达功能。