Webex for BroadWorks 故障排除流程

上报问题

在遵循了一些疑难解答指南后,应该对问题根源有了合理的认识。

1

从与问题相关的系统收集尽可能多的信息

2

联系 Cisco 相应团队发起专案(请参阅“联系人”部分)

要收集的客户端信息

如果您认为需要打开专案或上报问题,在与用户进行疑难解答时,请收集以下信息:

  • 用户标识符: CI 电子邮件地址或用户 UUID(这是 Webex 标识符,但如果能获取用户的 BroadWorks 标识符也会有帮助)

  • 组织标识符

  • 遇到问题的大致时间范围

  • 客户端平台和版本

  • 从客户端发送或收集日志

  • 记录跟踪 ID(如果显示在客户端上)

在服务台中查看用户详细信息

1

登录到 https://admin.webex.com/helpdesk

2

搜索用户然后单击。 这会打开用户摘要屏幕。

3

单击用户名以查看详细的用户配置。

此视图中的有用信息包括用户 UUID、通用标识 (CI) 集群、Webex 应用程序集群、呼叫行为、BroadWorks 帐户 GUID。

4

如果您需要在另一工具中使用此信息,请单击 Copy(复制),或将其附加到 Cisco 专案。

在服务台中查看客户组织

1

登录到 https://admin.webex.com/helpdesk

2

搜索客户组织名称然后单击。

3

向下滚动至看到 Customer Portal View(客户门户视图),单击 View CustomerName(查看客户名称)以查看客户组织的只读视图(包括用户和配置)。

从 Partner Hub 检索用户日志

对桌面和移动客户端问题进行故障排除时,合作伙伴(和 TAC)必须能够看到客户端日志。

1

要求用户发送日志。

2

要求用户导出呼叫环境,将 ced.dat 文件发送给您。

3

从 Partner Hub 或服务台客户端日志(见下)。

Partner Hub 选项:

  1. 登录 Partner Hub,找到用户的客户组织。

  2. 选择 Troubleshooting(故障排除)。

  3. 选择 Logs(日志)。

  4. 搜索用户(通过电子邮件)。

  5. 查看客户端日志并下载为 zip 文件。

服务台选项:

  1. 登录服务台。

  2. 搜索组织。

  3. 单击组织(打开摘要屏幕)。

  4. 向下滚动,单击 View(查看)客户

  5. 选择 Troubleshooting(故障排除)

  6. 选择 Logs(日志)

  7. 搜索用户(通过电子邮件)。

  8. 查看客户端日志并下载为 zip 文件。

呼叫服务的客户端检查

1

登录 Webex 客户端。

2

检查侧边栏上是否有呼叫选项图标(一个上方有齿轮的听筒)。

如果图标不存在,用户可能尚未在控制中心中启用呼叫服务。

3

打开 Settings/Preferences(设置/首选项)菜单,然后进入 Phone Services(电话服务)部分。 您应能看到您登录的 SSO 会话的状态。

(如果显示其他电话服务,例如 Webex Calling,说明用户未使用 Webex for BroadWorks。)

此验证意味着:

  • 客户端已成功穿越微服务 Webex 请求。
  • 用户已成功通过身份验证。
  • 客户端已由 BroadWorks 系统颁发长效 JSON Web 令牌。
  • 客户端已检索其设备配置文件,并注册到 BroadWorks。

获取客户端日志反馈

  • 请参阅资源部分,在 Webex 桌面客户端上找到特定客户端日志,或要求用户发送日志。

  • 要求移动客户端用户发送日志,然后您可以通过 Partner Hub 或服务台获取这些日志。


发送日志是无提示的。 但是,如果用户发送反馈,它将转到 Cisco Webex 应用程序开发运营团队。 如果要与 Cisco 跟进,请务必记录用户的反馈号码。 例如:

获取呼叫环境数据

Webex 客户日志经过大量修改以删除个人可识别信息。 您应在发现问题时从同一会话中的客户端导出呼叫环境数据。

1

在客户端中,单击档案照片,然后单击 Help(帮助)> Export Calling Environment Data(导出呼叫环境数据)

2

保存生成的文件 ced.dat,以便对此用户的呼叫问题进行故障排除。

重要: 从客户端注销或重启客户端会清除内部缓存。 如果之后导出 ced.dat,导出的数据不会与缓存之前发送的任何日志对应。

重设 Webex 数据库

1

在客户端上单击 Help(帮助)> Health Checker(健康检查程序)

2

选择 Reset Database(重设数据库)

这将触发客户端的完整重置并加载 Webex 应用程序登录屏幕。

验证 Webex 注册到 BroadWorks

Webex 应用程序会检查以下信息来确定是否注册到 BroadWorks:

  • 用户 对broadworks-connector 的权限

  • 组织和用户的呼叫行为

检查用户的呼叫行为以及连接器权限

  1. 使用合作伙伴管理员凭据登录服务台 (https://admin.webex.com/helpdesk)。

  2. 搜索用户。

  3. 单击用户并检查呼叫行为条目。 应为“呼入 Webex”。

  4. 单击用户名打开用户详细信息屏幕。

  5. 向下滚动至权限部分,验证是否包含 broadworks-connector。


    如果 Webex for BroadWorks 用户打算使用 Webex for BroadWorks,则不应拥有 bc-sp-standard 权限。 这是通过 Cisco 托管的云呼叫服务进行的 Webex 应用程序呼叫“Webex Calling (Broadcloud)”的权限。

检查组织的呼叫行为

  1. 使用合作伙伴管理员凭据登录服务台 (https://admin.webex.com/helpdesk)。

  2. 搜索组织。

  3. 单击组织并检查呼叫行为条目。 应为“呼入 Webex”。

针对用户预配置问题分析 PSLog

使用应用程序服务器的 PSLog 查看发送到预配置桥接的 HTTP POST 请求以及 Webex 的响应。

在正常案例中,响应为“200 成功”,并且在几分钟后,您可以看到 Webex 中创建该用户(如果是首个用户)和新的客户组织。

您可以通过在服务台搜索您在 POST 中看到的电子邮件地址来验证。

准备工作

在使用测试用户进行流式预配置的过程中,从应用程序服务器收集 PSLog。

1

要检查的第一件事是 HTTP 响应代码:

  • 除“200 成功”之外的其他代码都说明用户预配置失败。

  • 如果订阅者档案对预配置桥接上游的 Webex 不起作用,即使响应“200 成功”,仍然可能指示故障。

  • 400 响应中可能包含消息节点。 预配置桥接无法处理 subscriberProfile 中的某些内容。 订阅者详细信息可能有问题,或与模板中的某个设置不兼容。

  • 401 表示 AS 上输入的预配置凭据与 Partner Hub 模板中输入的凭据不匹配。

  • 403 可能表明应用程序服务器上有配置错误。 检查请求的目标。它不应为 IP 地址,应为可以在合作伙伴 Hub 中的模板上看到的预配置桥接 URL。

  • 409 表示提供的 subscriberProfile 和现有 Webex 数据冲突。 可能已有使用该电子邮件地址的用户。 检查响应中的消息

2

您还可以检查原始 HTTP POST 中是否有可能导致预配置失败的任何可疑值。

POST 包含 subscriberProfile XML 结构。 其内部,需要检查的有用节点有:

  • bwuserid: 如果您需要在 BroadWorks 中编辑订阅者档案,请使用它查找。

  • 群组: 如果模板是“服务商模式”,此模板会小写并成为在 Partner Hub 中看到的客户组织名称。

  • 服务商: 如果模板是“企业模式”,此模板会小写并成为在 Partner Hub 中看到的客户组织名称。

  • primaryPhoneNumber: 必须存在。 如果不存在,预配置会失败。

  • email: 会成为 Webex 中的用户 ID。 必须有效且对 Webex 唯一,否则预配置会失败。


 

忽略服务节: 该模板由 AS 创建,Webex 已接受但未使用。

分析 XSP 日志以对订阅者登录进行故障排除

本流程描述了 BroadWorks 身份验证模式。 您可以在 Partner Hub 中的 BroadWorks 模板上看到身份验证模式。 请参阅“配置客户模板”(网址为 https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726)。

以下梯形图显示了用户在 Webex 应用程序中执行 BroadWorks 身份验证时,用户、客户端、Webex 服务与 BroadWorks 系统之间的交互。此外,WEBEX 与 XSP 之间的连接还受到 MTLS 保护。

以下讨论说明了调查成功登录日志时会看到的内容。

图 1 BroadWorks 身份验证和设备配置

用户与客户端交互,客户端与 Webex 交互:

  • 用户向应用程序提供其电子邮件地址(图中 1)。

  • CI 知道要重定向此用户以输入其 BroadWorks 密码(通过 UAP)(图中 2)。

  • IDP 代理将获取档案请求提交到 XSP 上的 Xsi 界面。

在 tomcat access_log 中:

  • 查找从 Webex 到 Xsi-Actions(图中 2.1)的订阅者档案 GET 请求。 该请求具有 Webex 用户 ID。 例如:

    GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

在 XsiActionsLog 中:

  • 查找 Webex 发出的档案 GET 请求(图中 2.1)。 该请求具有 Webex 用户 ID。 例如:

    GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

    标题包括 authorization: Basicuser-agent: broadworksTeamsClient

  • 然后,XSP 针对 BroadWorks 执行 OCI-P 基本身份验证(AuthenticationVerifyRequest 和 AuthenticationVerifyResponse,像通过 Xsi 进行基本验证的其他任何应用程序一样)以及 UserGetRequest 和 ServiceProviderGetRequest,以收集订阅者信息。

  • Xsi 对 Webex 的响应包含包含 (BroadWorks) userId 和其他详细信息的 XML 档案块(图中 2.2)。

客户端和 Webex 服务交互:

  • IDP 代理匹配从 BroadWorks 接收的用户档案,并向客户端发送 SAML 断言(图中 2.3)

  • 客户端将 SAML 断言交换为 CI 令牌(图中 3)

  • 客户端会检查已登录的用户是否具有 broadworks-connector 权限(图中 4)。 您可以在服务台中检查用户权限)

  • 客户端使用 CI 令牌从 IDP 代理请求 JSON Web Token (JWT)(图中 5)

  • IDP 代理在 CI 验证 CI 令牌

  • IDP 代理从身份验证服务请求 JWT

在身份验证服务日志中:

  • 查找 Webex 发出的令牌请求(图中 5.2),例如:

    GET /authService/token

    其具有 http_bw_userid 标题和其他内容。

  • XSP 执行 OCI-P UserGetLoginInfoRequest 以验证提供的用户 ID 是否与 BroadWorks 用户对应(图中 5.3)。 AuthService 已通过 mTLS 连接与 Webex 建立信任,因此可以发出 LLT。

  • 查找来自 LongLivedTokenManager 的响应(图中 5.4) - Token generated,主题: bwksUserId@example.com,颁发者: BroadWorks...

    StatusCode=200,您可以使用 trackingid: CLIENT… 标题将其与原始请求关联。

在 XsiActionsLog 中:

  • 客户端现在能够在 Xsi-Actions 接口出示长效令牌以获取其设备配置文件(图中 6)。 例如:

    GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device

    使用标题 authorization: Bearer 令牌user-agent: WebexTeams(变体/版本

  • Xsi-Actions 接口将令牌 POST 至 authservice(配置在环回接口上),例如: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    您可以将这些与 trackingid: CLIENT… 标题(GET 中)和 X-BROADSOFT-CORRELATION-ID : CLIENT… 标题(POST 中)关联。

在身份验证服务日志中:

  • 接收来自 Xsi 的 POST(环回)

  • StatusCode=200 返回 Xsi

  • 以及令牌验证响应,正文中具有“令牌“JSON 块。

  • 使用 trackingid: CLIENT… 关联

在 XsiActionsLog 中:

  • 从验证了客户端令牌的 authservice 收到“200 成功”之后,Xsi-Actions 应用程序现在会发送 UserPrimaryAndSCADeviceGetListRequest 的 OCI-P 请求

  • 接收 OCI-P 用户 UserPrimaryAndSCADeviceGetListResponse(包含 accessDeviceTable XML 结构的)

  • OCI-P 响应编码为 Xsi 对客户端的响应,包括 AccessDevices XML 结构,其包含 deviceTypes,例如 Business Communicator - PC,以及 客户端用于检索设备配置文件的 URL。

客户端继续正常工作:

  • 选择设备条目并与 DMS 交互以获取设备配置文件(图中 6)

  • 通过从 DMS 配置中检索到的 SBC 注册到 BroadWorks(图中 7)