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

如果您需要在另一項工具中使用該資訊,請按一下複製,或將其附加至 Cisco 案例。

在技術支援中檢視客戶組織

1

登入 https://admin.webex.com/helpdesk

2

搜尋,然後按一下客戶組織名稱。

3

向下捲動,直到您看到客戶入口網站視圖並按一下檢視 CustomerName以查看客戶組織(包括使用者和組態)的唯讀視圖。

從 Partner Hub 擷取使用者記錄檔

對桌上型電腦及行動用戶端問題進行疑難排解時,合作夥伴(及 TAC)必須能夠檢視用戶端記錄檔。

1

要求使用者傳送記錄檔。

2

要求使用者匯出通話環境並傳送 ced.dat 檔案給您。

3

從 Partner Hub 或技術支援中取得用戶端記錄檔(請參閱下方)。

Partner Hub 選項:

  1. 登入 Partner Hub 並尋找該使用者的客戶組織。

  2. 選取疑難排解。

  3. 選取記錄檔。

  4. 搜尋使用者(依電子郵件)。

  5. 檢視並將用戶端記錄下載為 zip 檔。

技術支援選項:

  1. 登入技術支援。

  2. 搜尋組織。

  3. 按一下組織(會開啟摘要螢幕)。

  4. 向下捲動並按一下檢視客戶

  5. 選取疑難排解

  6. 選取記錄檔

  7. 搜尋使用者(依電子郵件)。

  8. 檢視並將用戶端記錄下載為 zip 檔。

通話服務的用戶端檢查

1

登入 Webex 用戶端。

2

檢查側邊欄上是否顯示通話選項圖示(上方有齒輪的話筒)。

如果圖示不存在,表示使用者可能尚未在 Control Hub 中啟用通話服務。

3

開啟設定/喜好設定功能表,然後前往電話服務區段。 您應該會看到已登入的 SSO 工作階段狀態

(若顯示的是 Webex Calling 等其他電話服務,表示使用者使用的並不是 Webex for BroadWorks)。

此驗證表示:

  • 用戶端已成功周遊所需的 Webex 微型服務。
  • 已成功驗證使用者。
  • 您的 BroadWorks 系統已對用戶端發出長時間使用 JSON Web 權杖。
  • 用戶端已擷取其裝置設定檔,且已註冊 BroadWorks。

取得用戶端記錄檔或意見回饋

  • 請參閱資源部分以在 Webex 桌上型電腦用戶端上尋找特定用戶端記錄檔,或要求使用者傳送記錄檔。

  • 要求行動裝置用戶端的使用者傳送記錄檔,然後您可以透過 Partner Hub 或技術支援取得記錄檔。


傳送記錄檔不會出現訊息。 但是,如果使用者傳送意見回饋,則它會送往 Cisco Webex 應用程式開發團隊。 如果您要追蹤 Cisco 的後續狀況,請務必記錄使用者的意見回饋編號。 例如:

取得通話環境資料

為了移除個人識別資訊,Webex 用戶端記錄檔已大幅編校。 您應該在注意問題的同時,從相同工作階段的用戶端匯出通話環境資料。

1

在用戶端中,按一下設定檔圖片,然後按一下說明 > 匯出通話環境資料

2

儲存產生的 ced.dat 檔案,針對此使用者的通話問題進行疑難排解。

重要: 從用戶端登出或重新啟動用戶端會清除內部快取。 如果之後匯出 ced.dat,則匯出的資料將不會對應到快取之前送出的任何記錄檔。

重設 Webex 資料庫

1

在用戶端上,按一下說明 > 健全度檢查程式

2

選取重設資料庫

這會觸發用戶端完整重設,並載入 Webex 應用程式登入螢幕。

驗證 Webex 應向 BroadWorks 註冊

Webex 應用程式會檢查下列資訊以決定是否向 BroadWorks 註冊:

  • broadworks-connector 的使用者授權

  • 組織和使用者的通話行為

檢查使用者的通話行為及連接器權限

  1. 使用合作夥伴管理員認證登入技術支援 (https://admin.webex.com/helpdesk)。

  2. 搜尋使用者。

  3. 按一下使用者並檢查通話行為項目。 它應該是「在 Webex 中通話」。

  4. 按一下使用者名稱以開啟使用者詳細資料螢幕。

  5. 向下捲動以找到 entitlements 區段,並驗證 broadworks-connector 已包含在內。


    Webex for BroadWorks 使用者不應具有 bc-sp-standard 授權(如果他們打算使用 Webex for BroadWorks)。 這是「Webex Calling (Broadcloud)」的權限,是透過受 Cisco 管理的雲端通話服務進行的 Webex 應用程式通話。

檢查組織的通話行為

  1. 使用合作夥伴管理員認證登入技術支援 (https://admin.webex.com/helpdesk)。

  2. 搜尋組織。

  3. 按一下組織並檢查通話行為項目。 它應該是「在 Webex 中通話」。

分析使用者佈建問題的 PSLog

使用應用程式伺服器的 PSLog 來查看對佈建橋接器的 HTTP POST 請求,以及來自 Webex 的回應。

在正確的工作案例中回應是 200 OK,幾分鐘後,您可以在 Webex 中查看已建立使用者(如果是首位使用者)和新客戶組織。

您可以在技術支援中搜尋在 POST 中看見的電子郵件地址,來驗證這一點。

在開始之前

在測試使用者進行佈建流程嘗試期間,從應用程式伺服器收集 PSLog。

1

要檢查的第一件事是 HTTP 回應代碼:

  • 200 OK 以外的其他內容都表示使用者佈建失敗。

  • 如果訂閱者設定檔的一些內容在佈建橋接器的 Webex 服務上游無法運作,則 200 OK 仍可能表示失敗。

  • 400 可能在回應中包含 message 節點。 佈建橋接器無法處理此處的某些內容: subscriberProfile 。 訂閱者詳細資料可能有問題,或者與範本中的設定不相容。

  • 401 表示在 AS 上輸入的佈建認證與 Partner Hub 範本中輸入的認證不符。

  • 403 可能指示應用程式伺服器上有某些錯誤組態。 檢查請求的目標。它不應該是 IP 位址,而是您可以在 Partner Hub 的範本上查看的佈建橋接器 URL。

  • 409 表示提供的 subscriberProfile 和現有的 Webex 資料間存在衝突。 可能有使用該電子郵件地址的現有使用者。 檢查回應中的 message

2

您也可以檢查原始 HTTP POST 是否有可能導致佈建失敗的任何可疑值。

POST 包含 subscriberProfile XML 結構。 當中需要檢查的有用節點為:

  • bwuserid :如果您需要在 BroadWorks 中編輯訂閱者設定檔,請使用此功能來尋找該設定檔。

  • group :如果範本為「服務提供者模式」,則此範本會小寫,並且成為您於 Partner Hub 中看到的客戶組織名稱。

  • serviceProvider :如果範本為「企業者模式」,則此範本會小寫,並且成為您於 Partner Hub 中看到的客戶組織名稱。

  • primaryPhoneNumber :必須存在。 如果沒有提供,則佈建會失敗。

  • email :成為 Webex 中的使用者 ID。 必須有效且為 Webex 的唯一值,否則佈建會失敗。


 

忽略 services 一節: 它由 AS 建立,且被 Webex 接受,但不被 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 服務互動:

  • 使用者將電子郵件地址提供給 Webex 應用程式(圖中的 1)。

  • CI 知道重新導向此使用者以輸入其 BroadWorks 密碼(透過 UAP)(圖中的 2)。

  • IDP Proxy 將獲取設定檔請求提交至 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 的回應包含 XML Profile 區塊,其中包含 (BroadWorks) userId 及其他詳細資訊(圖中為 2.2)。

用戶端和 Webex 服務互動:

  • IDP Proxy 比對從 BroadWorks 接收的使用者設定檔,並且向用戶端發出 SAML 判斷提示(圖中的 2.3)

  • 用戶端為 CI 權杖交換 SAML 判斷提示(圖中的 3)

  • 用戶端會檢查已登入的使用者是否具有 broadworks-connector 權限(圖中的 4)。 您可以在技術支援中檢查使用者權限)

  • 用戶端使用 CI 權杖從 IDP Proxy 請求 JSON Web 權杖 (JWT)(圖中的 5)

  • IDP Proxy 在 CI 驗證 CI 權杖

  • IDP Proxy 從驗證服務請求 JWT

在 authenticationService 記錄檔中:

  • 尋找來自 Webex 的權杖請求(圖中的 5.2),例如:

    GET /authService/token

    其中具有 http_bw_userid 標頭及其他。

  • XSP 會執行 OCI-P UserGetLoginInfoRequest ,以驗證提供的使用者 ID 是否與 BroadWorks 使用者的 ID(圖中為 5.3)相對應。 AuthService 已憑藉 mTLS 連接建立與 Webex 的信任,因此可以發出 LLT。

  • LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

    StatusCode=200 尋找回應(圖中為 5.4),您可使用 trackingid: CLIENT… 標頭將它們與原始請求關聯。

在 XsiActionsLog 中:

  • 用戶端現在可以在 Xsi-Actions 介面呈現長時間使用權杖,以取得其裝置設定檔(圖中的 6)。 例如:

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

    使用標頭 authorization: Bearer tokenuser-agent: WebexTeams (variant/version)

  • 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 )。

在 authenticationService 記錄檔中:

  • 從 Xsi 接收 POST(回送)

  • A StatusCode=200 返回至 Xsi

  • 權杖驗證回應,其在內文中具有 "token" JSON 區塊。

  • 使用以下項目相互關聯: trackingid: CLIENT…

在 XsiActionsLog 中:

  • 從驗證用戶端權杖的 authservice 收到 200 OK 後,Xsi 動作應用程式現在會傳送該項目的 OCI-P 請求: UserPrimaryAndSCADeviceGetListRequest

  • 接收 OCI-P UserPrimaryAndSCADeviceGetListResponse ,其包含 accessDeviceTable XML 結構。

  • OCI-P 回應會編碼為 Xsi 對用戶端的回應,包括 AccessDevices XML 結構,具有 deviceTypes 例如: Business Communicator – PC 以及用戶端可在其中擷取裝置設定檔的 URL。

用戶端如常繼續:

  • 選取裝置項目並與 DMS 互動以取得裝置設定檔(圖中的 6)

  • 透過從 DMS 組態中擷取的 SBC 向 BroadWorks 註冊(圖中的 7)