Webex 联络中心架构

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

图 1 说明了将语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

图 2 说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

图 1 说明了 Webex CC 中的置备工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

图 2 说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

图 1 说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

图 1 说明了将语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

图 2 说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

图 1 说明了 Webex CC 中的置备工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

图 2 说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

图 1 说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

图 1 说明了将语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

图 2 说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

图 1 说明了 Webex CC 中的置备工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

图 2 说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

图 1 说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

图 1 说明了将语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

图 2 说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

图 1 说明了 Webex CC 中的置备工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

图 2 说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

图 1 说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

图 1 说明了将语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

图 2 说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

图 1 说明了 Webex CC 中的置备工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

图 2 说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

图 1 说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

图 1 说明了将语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

图 2 说明了在 Webex CC 中引入电子邮件和消息传递交互的过程。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

图 2 说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

图 1 说明了 Webex CC 中的置备工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

图 2 说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

图 1 展示了嵌入式 CRM Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

图 1 说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

下图说明了语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

下图说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

下图说明了 Webex CC 中的预配置工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

下图说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

下图说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

下图说明了语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

下图说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

下图说明了 Webex CC 中的预配置工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

下图说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• 微软动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如，

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

下图说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。

电话

对于电话服务，入站语音呼叫处理取决于呼叫进入联系人中心的方式（请参阅下面的入口机制）以及与入口点关联的 Webex CC 流。

呼叫得到应答，并按照 Webex CC Flow 定义完成进一步的操作 - 这是在排队和路由到代理之前处理呼叫时要执行的操作的编程表示形式，或者流本身可以处理呼叫而无需转移到代理。

CC 中的流构建器 Webex 允许开发人员定义流并将其分配给调用通过 CC 到达 Webex 入口点。

配置实体 中介绍了这些配置实体及其用法。

有关流生成器的更多信息，将在下一节 中介绍 IVR 系统。

电子邮件和消息传递

从 Webex CC 的角度来看，Webex Connect 为所有数字渠道（电子邮件、消息传递渠道）提供入口和出口功能，最终用户可以使用这些功能联系联系人中心。

Webex 连接流

• 决定此类交互的处理方式，直到交互排队并路由到代理。 这包括针对所有形式的消息传递和电子邮件交互的自动处理和 BOT 处理。

• 将业务逻辑应用于传入交互。

• 在排队前处理联系。

• 流本身可以处理交互，而无需转移到实时代理。

Webex CC 支持的消息传递通道包括：

• Web App / 移动应用聊天

• WhatsApp

• Facebook Messenger

• SMS

Webex CC 支持的电子邮件通道包括：

• Gmail

• Office365

入口机制

本节介绍交互可以进入 CC Webex 机制。根据媒体类型，交互到达 CC Webex 机制也不同。

例如，在电话服务中，需要物理基础结构设置来启用 PSTN 连接、配置电话号码以及将呼叫路由到 Webex CC。

对于电子邮件/消息传递通道，入口配置必须在 Webex Connect 中完成，它涉及电子邮件/消息帐户预配置和 Webex Connect 流配置。

入站语音

对于语音呼叫，一种典型的场景是用户拨打 PSTN 电话号码，然后将其连接到联系人中心。 从入口角度来看，这需要一种机制来将呼叫从 PSTN 路由到 Webex CC。

下图说明了语音呼叫引入 Webex CC。

Webex CC 中的语音入口服务使用 SIP 执行第三方呼叫控制，应答传入呼叫以及执行转接、会议和其他呼叫控制操作。

Webex CC 中呼叫的逻辑入口点是名为“入口点”的配置实体。 对于语音入口，入口点的关键配置是与其关联的电话号码，通常是从所选 PSTN 提供商处获取的有效 PSTN 电话号码。

这样就可以检测电话号码上的传入呼叫，将呼叫关联到入口点，并使用入口点的其他配置参数根据应为交互触发的 Webex CC Flow 定义来处理呼叫。

注意：

有关 PSTN 连接选项的更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

语音边缘基础设施的可扩展性和可用性

Webex CC VPOP 基础架构包括确保高可用性的冗余 SIP SBC 对，并且可以添加更多 SBC 来扩展要支持的并发呼叫量。

VPO 可以处理的最大并发呼叫数取决于正在运行的 SBC 数量以及要发送到的呼叫。

对于地理冗余–支持跨区域的多个对互连的 VPOP SBC 网状网络。

对于语音入口服务，它们可以水平扩展，以处理越来越多的要摄取到 Webex CC 的并发语音呼叫。

语音边缘基础架构的安全注意事项

下表提供了有关语音边缘基础结构的连接选项的详细信息。

有关更多详细信息，请访问 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。

IVR 系统

进入与入口点关联的电话号码的每个语音呼叫都会通过 Webex 抄送来应答，并开始执行与入口点关联的 Webex CC 流。

Webex CC Flow Builder 提供编程构造/运算符和功能块（称为活动），以便管理员或设计和实现 IVR 逻辑的任何人都可以组合这些构建块并创建 Flow 定义。

Flow 支持的编程结构包括：

• 声明和设置变量–与流执行关联的状态

  • 用于设置变量值的 Pebble 表达式

• 条件检查

• 循环–使用条件和转到（能够将活动链接在一起）

• 调用 REST API

• 解析数据–JSON、TOML XML 通常用于解析 API 响应。

• 撰写活动

Flow 提供的一组具有代表性的活动包括： 播放消息 收集用户数据 将呼叫转接到另一个目标/电话号码 将呼叫发送到虚拟代理 将呼叫排队，以便代理应答。

对于每个处于活动状态的调用，流执行的实例也会处于活动状态，直到调用结束，从而导致并发执行流。

流执行的每个实例都为与流关联的数据/状态以及调用提供了隔离的环境。

在呼叫的整个生命周期中，flow 还支持响应发生的某些事件并处理它们 - 例如，当呼叫由代理应答时，事件处理程序可以在代理桌面界面中触发屏幕弹出。

有关 Webex CC 流程的更多信息，请参阅 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。

虚拟代理支持

Flow 提供一项活动，用于将交互移交给虚拟代理，该代理已在 Control Hub 中预先配置 Webex。

呼叫连接到虚拟代理后，它将为用户提供对话式 IVR 体验，并且活动以呼叫终止或将呼叫升级为代理而结束。

在升级的情况下，可以将流程配置为将呼叫排队，然后由代理应答。

入站数字交互

对于传入交互的电子邮件和消息传递通道，Webex CC 利用 Webex Connect 来预配置资产，利用流来处理传入的交互，然后在 Webex Connect 流显式地将交互排队以便代理可以处理时将交互路由到 Webex CC。

下图说明了如何在 Webex CC 中摄取电子邮件和消息传递交互。

虚拟代理/BOT 集成

对于电子邮件和消息传递/社交渠道交互，虚拟代理/BOT 处理是在 Webex Connect 流中配置的。

与语音虚拟代理一样，如果 BOT 处理结果以升级告终，则交互将排队并路由到代理。

代理选择

Webex CC 中的队列支持以下代理选择算法：

• 最长可用代理路由

• 基于技能的路由

  • 最长可用代理（LAA）

  • 最佳可用代理（BAA）

代理通过团队与队列关联。

可以按顺序为队列分配多个呼叫通讯组（每个组有一个或多个组），并配置等待将呼叫通讯组添加到队列中，以便随着时间的推移，匹配代理的搜索空间扩展到其他呼叫通讯组。

对于基于技能的路由，在与队列关联的技能要求匹配代理中，根据 LAA 或 BAA 配置选择一个代理。

特定于语音/电话的附加功能

基于代理的路由（仅适用于语音/电话通道）

Webex CC Flow 使用活动 QueueToAgent 可以根据代理 ID 将交互直接路由到所选代理。

如果代理没有有空来处理交互，则可以将交互停放在特定于代理的队列中，等待代理成为有空

高级队列信息

Webex CC Flow 使用活动 GetQueueInfo，可以获取队列的实时信息，例如队列中的位置（PIQ）、估计等待时间（EWT）、队列中有空的代理数量，并可用于决定是否将联系人排队。

礼貌回电

Webex CC Flow 使用活动回呼，使客户在保持队列中的位置的同时断开呼叫连接，并在队列中的虚拟交互路由到代理时接收回调。

溢出处理

Webex CC 支持使用基于容量的团队（CBT）进行溢出处理。

CBT 类似于具有容量的常规团队，以及为该容量提供服务的关联外部 DN。 它可以与队列呼叫分配周期中的其他团队一起配置。

通常，此周期配置为最后一个周期，以便在所有已配置的呼叫通讯组都找不到用于处理交互的有空匹配代理之后，如果没有有空代理，它也会充当溢出。

Agent Desktop 运营

当代理登录到 CC Agent Desktop Webex 时，代理会指定一个电话号码，代理的传入呼叫可以连接到该号码。 这可以是 PSTN 电话、移动电话或分机号（如果代理是 Cisco Webex Calling 用户）。

请注意，此号码必须是可以路由呼叫的有效电话号码。 否则，代理将无法收到传入呼叫。

根据代理正在处理的交互类型，代理桌面上的小组件提供执行特定媒体控制操作的功能。

例如，呼叫被应答后，代理可以执行以下与该呼叫相关的操作。

• 将呼叫置于保持状态

• 发起咨询呼叫和

  • 将呼叫转接到另一个电话号码（例如代理电话号码）/入口点

  • 会议其他代理进行呼叫

• 将呼叫转接到另一个队列

• 结束呼叫

代理桌面允许管理员在其中添加自定义小组件，方法是扩展桌面功能，使其成为代理以高效方式完成工作所需的小组件的统一集合。

桌面体系结构

代理桌面是一个基于微前端的单页应用程序，它托管基于 Web 组件体系结构构建的小部件。 所有标准/常用小部件都由 API 或服务器端推送机制检索的数据提供支持。

这些通常是异步 API，其中调用的响应通过 WebSocket 连接来到桌面。

Webex CC Agent Desktop 使用 Cisco Common Identity（CI）对用户进行身份验证，令牌将传递到所有 API 调用。 对于自定义小组件，基于身份验证模型，如果自定义小组件的身份验证模型与 CI 集成，它将为代理提供单点登录体验。

一旦代理成为交互的一部分，对该交互状态或关联数据的所有更新也会通过 WebSocket 连接推送到桌面。

桌面对连接性和延迟的弹性

异步 API 和服务器端推送可实现扩展，并检测到与 WebSocket 接口的任何连接丢失，并且桌面尝试重新连接并重新登录。

下图说明了 Webex CC 中的代理桌面体系结构。

引导客户

Webex Control Hub 是合作伙伴和客户用于引导客户以及启用或配置功能的主要界面。

在 Control Hub 中预配置组织和联络中心功能后，它将在 CC 中触发工作流 Webex 该工作流会根据客户选择的产品执行预配置所有联络中心功能中的其余步骤。

所有联系人中心配置都是使用 BPM 工作流引擎完成的，该引擎支持以声明性方式定义所涉及的步骤，并使整个预配置步骤能够抵御故障并确保数据完整性。

下图说明了 Webex CC 中的预配置工作流。

配置实体

Webex CC 中的关键配置实体（作用域在组织内）包括：

站点

站点是指一个或多个团队、用户（代理/主管）所在的位置。

每个用户和团队都必须属于一个站点。

小组

一组用户。 团队用于通过队列向代理分发交互。

每个团队都必须属于一个站点。

座席

可以登录以 Agent Desktop 和处理在 Webex CC 中配置的媒体类型之间的交互的用户。

主管

主管被分配到团队，可以监控/指导代理，并可以访问属于主管分配到的团队的团队级别状态和代理统计信息。

队列

队列是一个逻辑实体，可以在其中进行交互，同时等待代理有空，然后路由到代理。

队列映射到团队，作为代理的搜索空间，能够通过将其他团队添加到搜索空间来根据经过的时间阈值扩展搜索空间。

入口点

入口点是一个逻辑实体，表示交互进入 CC Webex 入口点。对于电话服务，这主要映射到呼叫到达的电话号码，对于电子邮件/消息传递通道，入口点指向 Webex Connect 中的资产配置。

流

与入口点关联的流（通过路由策略），它决定处理交互所涉及的步骤。

对于非电话渠道（电子邮件、消息传递/社交），在 Webex Connect 中，选择 Flow 作为资产配置的一部分。

多站点联络中心的访问控制

Webex CC 管理员可以为用户档案配置对特定站点、团队、队列和入口点的访问权限。 此外，由于网站和团队的等级性质，一旦提供了对特定网站的访问权限，用户就只能访问属于这些网站或此类团队明确指定的子集的团队或与团队相关的日期。

对于队列和入口点，它们在组织级别是全局的，因此对于不同的地理位置（特定代理和团队所在的站点），可以配置单独的入口点和队列，主管/用户可以访问适用于特定站点的实体。

下图说明了引用这些实体的关键配置实体和用户配置文件。

除了限制对这些实体的访问之外，Webex CC 管理员可以控制用户可在管理界面中访问的特定功能/模块，从而使用户对特定实体以及 Webex CC 管理界面的部分/功能具有管理/配置权限。

桌面嵌入式连接器：CRM 应用程序作为主要接口

在这种操作模式下，代理作为主应用程序登录到 CRM 控制台。

Webex CC 是一种嵌入式应用程序（也称为嵌入式桌面应用程序或嵌入式软件电话），主要用于登录联系人中心并接收 Webex CC 路由的联络中心交互。

收到呼叫或对话请求后，CRM 集成在 CRM 控制台上执行以下操作

• 弹出与 ANI 或其他呼叫相关数据关联的客户记录。

• 将呼叫元数据作为活动注释发布到客户记录中

• 允许座席“点击呼叫”，方法是单击 CRM 中的联系人并向客户发起出站呼叫

• 将呼叫记录发布到 CRM 报告表中，以便在 CRM 上进行主要报告。

• 提供 Agent Desktop 和呼叫控制（桌面应用程序的嵌入式和缩小版）的全部功能

与 CRM 集成的主要模式是 Webex CC 桌面应用程序嵌入单独的 iFrame 中。

此外，Webex CC 桌面应用程序运行在后台运行的自定义无头小部件（无用户界面），与底层 CRM 系统交互以代表代理执行自动化操作。

交互由无头小部件使用的两个 SDK 提供支持。

• Webex CC 桌面 JS SDK：这是 Webex CC 提供的 JavaScript SDK，用于注册代理和联系人操作的事件侦听器。

• CRM JS SDK：这是适用于每个 CRM 的 CRM 客户端 SDK，它使用 CRM 抽象出 REST API 调用。 例如，对于 salesforce，Salesforce 提供的 CTI JS 库用于执行操作并侦听 CRM 中的事件。

下图说明了 CRM 嵌入式 Webex CC 桌面和连接器体系结构

Webex CC 支持以下用于上述集成的 CRM 解决方案：

• Salesforce

• 服务现在

• Microsoft 动态 365

• Zendesk

• Freshdesk

有关更多详细信息，请访问 https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10。

有关配置 Webex CC 桌面布局以启用 CRM 连接器、功能集和更改日志的更多信息，请访问 https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。

CRM 连接器的全球可用性

CRM 连接器在运行 CC 的所有地理位置和区域中有空 Webex。

弹性规模和性能

Webex CC 托管自定义小组件，该小组件可在 AWS CloudFront CDN 中实现 CRM 应用程序和 Webex CC 桌面之间的双向通信，确保小组件 AWS 跨可用区和区域的高可用性。

所有特定于 CRM 集成的计算都在代理使用 CRM 应用程序的浏览器上进行 Webex 并在 CRM 应用程序中嵌入了 CC 桌面。

安全

CRM 连接器通过 Webex CC 代理桌面布局调用，可选参数通过桌面布局传递到小组件中，以打开和关闭功能。

例如，要启用 Salesforce actions Widget，管理员可以开启桌面布局参数，将 sfdcWidgetEnabled 设置为 true。

软件包安装

要使集成双向工作，CRM 控制台需要安装嵌入式应用程序。 这是为了支持在 iFrame 中加载桌面应用程序。

所有桌面嵌入式连接器都在 CRM 市场上有空。

例如

服务现在： https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5？

Zendesk： https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

市场应用程序安装会激活所需的插件并将所需的 XML 文件导入 CRM 控制台，以支持在 CRM 上报告呼叫记录。

通过 IVR 中的 HTTPs 连接器进行流集成

Webex CC 流构建器支持使用 Webex Control Hub 中配置并在 Webex CC Flow 上使用的 HTTPs 连接器 Webex CC 和 CRM 系统之间的双向数据流。

这些主要用于语音交互中的个性化和 IVR 中的自定义路由。

默认情况下，Webex CC 支持 Control Hub 上的 Salesforce HTTP 连接器。 其他 CRM 连接器可以添加为自定义连接器 Webex Control Hub 上。

有关 HTTP 连接器的更多信息，请访问 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。

IVR HTTP 连接器：

• Salesforce IVR HTTP 连接器（内置）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP 连接器（自定义）： https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

边缘的语音基础架构

语音边缘组件允许来自客户网络/PSTN 运营商的 SIP 中继终止，这是基于允许连接到边缘组件的白名单 IP 启用的。

计算基础架构安全性

Webex CC 计算实例在 AWS 中预置，服务在具有多个命名空间的 Kubernetes 集群中作为 Pod 运行，并且对每个命名空间的访问受到单独的凭证限制。

所有基础架构配置都是使用代码完成的（无需手动步骤），并且无法手动访问任何凭据。

有一个中央凭据存储，其中包含为一组特定的服务/团队配置的特定路径，并且对凭据存储本身的访问受到限制，并在生成和部署系统中配置为机密。

没有任何基础设施组件/服务直接暴露在 AWS VPC 外部，只有公开公开的接口是使用 api 网关控制和管理的 API 和 WebSocket 服务器，

除此之外，开发人员还使用某些内部系统和接口用于查看日志、指标、部署详细信息、构建状态和测试结果，这些系统和接口使用角色和组进行保护，并与思科内部身份验证系统集成。

用户界面的身份验证和授权

各种联络中心用户（代理、主管、管理员、分析师）使用的所有用户界面都受基于思科通用身份的持有者令牌身份验证（OAuth 流）的保护。

授权是使用获取令牌的用户的角色和分配给令牌的范围完成的。

传输中的数据

所部署的服务/基础架构组件的任何接口都不会直接暴露给外部传入流量。

选择服务，使用 http API 通过网关公开这些接口，所有传入的 http（包括 WebSocket 的 http）在 ALB 中终止，并且通过 http 的内部流量路由到服务。

所有传出交互都通过 https / TLS（对于非 http 协议）。

在 VPC 内部，服务之间的内部通信（通过 http/自定义 TCP 协议）通过普通 TCP 套接字进行。

静态数据

存储的所有数据都在存储层加密。 此外，VPC 外部的数据存储受到保护，并且具有凭证的访问控制和授权安全地存储在密钥存储中并管理。

下图说明了传输和静态的数据流和安全模型。

最终用户 PII 数据

Webex CC Flow 是用于处理交互的编程控制器，可用于收集用户数据，这些数据可以分配给专门标记为“包含敏感数据”的流变量。 此类数据的值是加密的，数据传输路径中的任何服务都无法访问此数据。

此外，此类数据永远不会保留在 CC 报告数据存储 Webex 并且日志/消息传递基础结构将具有加密数据，并且明文数据不会存储在 CC Webex 任何地方。

联络中心代理/主管 PII 数据

联系人中心用户相关数据在日志中被编辑，但在 Webex CC 数据存储中有空用于数据分析和可视化。

规模因素

对于 Webex CC，影响规模的因素包括：

• 并发登录的代理数

• 正在进行的交互的并发数

  • 对这些交互执行的操作

• 主管/代理在处理交互之外执行的操作并发数

• 生成并保留的数据量

实现规模化的架构方面

Webex CC 的架构和设计所依据的原则使解决方案能够在为各种服务和平台组件提供的基础架构强制实施的限制内根据需要动态扩展。

事件驱动架构

Webex CC 中的服务使用消息进行通信，关键消息处理流不涉及任何阻塞 IO 操作，并且处理消息所需的状态已本地化为正在处理消息的服务实例。

无状态服务（或外部化状态）

无状态服务通过轻松添加/删除服务的其他实例来实现弹性。 某些服务本质上是有状态的，这些服务具有外部化的状态存储，并且基础结构也支持动态更改此类服务的实例数，并自动重新平衡/状态传输/将状态本地化为需要状态的实例。

弹性基础架构

在 Kubernetes 中运行的所有服务和基础设施（也称为 Kubernetes 节点）会根据使用情况自动扩展，这样可以动态添加更多计算节点，直至达到预先配置的最大高阈值。

荷载预测和定期验证

所有服务都针对性能特征进行了基准测试，并在服务级别验证了扩展模式。

进行进一步的连续验证、峰值负载和耐久性测试，并根据规模影响属性的预计增长调整测试参数，从而能够识别瓶颈，计划更新基础设施资源使用的高阈值并为比赛日做好准备。