Webex for BroadWorks 疑難排解程序
呈報問題
遵循一些疑難排解指引之後,您應該對問題的根源有相當程度的瞭解。
1 | 從與問題相關的系統盡量收集詳盡的資訊 |
2 | 請聯絡 Cisco 的適當團隊提交案例(請參閱聯絡人一節) |
要收集的用戶端資訊
如果您認為需要提交案例或呈報問題,那麼在協助使用者進行疑難排解時應收集以下資訊:
使用者識別碼: CI 電子郵件地址或使用者 UUID(這是 Webex 識別碼,但如果也能取得使用者的 BroadWorks 識別碼尤佳)
組織識別碼
遇到問題的大致時間範圍
用戶端平台和版本
從用戶端傳送或收集記錄檔
在用戶端上顯示時記錄追蹤 ID
在服務台中檢查使用者詳細資料
1 | |
2 | 搜尋,然後按一下使用者。 這會開啟使用者摘要螢幕。 |
3 | 按一下使用者名稱以查看詳細的使用者組態。 此視圖中的有用資訊包括使用者的 UUID、通用身份識別 (CI) 叢集、Webex 應用程式叢集、通話行為、BroadWorks 帳戶 GUID。 |
4 | 如果您需要在另一項工具中使用該資訊,請按一下複製,或將其附加至 Cisco 案例。 |
在服務台中檢視客戶組織
1 | |
2 | 搜尋,然後按一下客戶組織名稱。 |
3 | 向下捲動,直到您看到客戶入口網站視圖並按一下檢視 CustomerName以查看客戶組織(包括使用者和組態)的唯讀視圖。 |
從 Partner Hub 擷取使用者記錄檔
對桌上型電腦及行動用戶端問題進行疑難排解時,合作夥伴(及 TAC)必須能夠檢視用戶端記錄檔。
1 | 要求使用者傳送記錄檔。 |
2 | 要求使用者匯出通話環境並傳送 ced.dat 檔案給您。 |
3 | 從 Partner Hub 或服務台取得用戶端記錄檔(請參閱下方)。 Partner Hub 選項:
服務台選項:
|
如何尋找用戶端版本
1 | 與使用者共用此連結: https://help.webex.com/njpf8r5。 |
2 | 要求使用者將版本編號傳送給您。 |
通話服務的用戶端檢查
1 | 登入 Webex 用戶端。 |
2 | 檢查側邊欄上是否顯示通話選項圖示(上方有齒輪的話筒)。 如果圖示不存在,表示使用者可能尚未在 Control Hub 中啟用通話服務。 |
3 | 開啟設定/偏好設定功能表,然後前往電話服務區段。 您應該會看到已登入的 SSO 工作階段狀態 (若顯示的是 Webex Calling 等其他電話服務,表示使用者使用的並不是 Webex for BroadWorks)。 此驗證表示:
|
取得用戶端記錄檔或意見回饋
請參閱資源部分以在 Webex 桌上型電腦用戶端上尋找特定用戶端記錄檔,或要求使用者傳送記錄檔。
要求行動裝置用戶端的使用者傳送記錄檔,然後您可以透過 Partner Hub 或服務台取得記錄檔。
傳送記錄檔不會出現訊息。 但是,如果使用者傳送意見回饋,則它會送往 Cisco Webex 應用程式開發團隊。 如果您要追蹤 Cisco 的後續狀況,請務必記錄使用者的意見回饋編號。 例如: ![]() |
取得通話環境資料
為了移除個人識別資訊,Webex 用戶端記錄檔已大幅編校。 您應該在注意問題的同時,從相同工作階段的用戶端匯出通話環境資料。
1 | 在用戶端中,按一下設定檔圖片,然後按一下說明 > 匯出通話環境資料。 |
2 | 儲存產生的 ced.dat 檔案,針對此使用者的通話問題進行疑難排解。 重要: 從用戶端登出或重新開啟用戶端會清除內部快取。 如果之後匯出 ced.dat,則匯出的資料將不會對應到快取之前送出的任何記錄檔。 |
重設 Webex 資料庫
1 | 在用戶端上,按一下 。 |
2 | 選取重設資料庫。 這會觸發用戶端完整重設,並載入 Webex 應用程式登入螢幕。
|
驗證 Webex 應向 BroadWorks 註冊
Webex 應用程式會檢查下列資訊以決定是否向 BroadWorks 註冊:
broadworks-connector 的使用者權限
組織和使用者的通話行為
檢查使用者的通話行為及連接器權限
使用合作夥伴管理員認證登入服務台 (https://admin.webex.com/helpdesk)。
搜尋使用者。
按一下使用者並檢查通話行為項目。 它應該是「在 Webex 中通話」。
按一下使用者名稱以開啟使用者詳細資料螢幕。
向下捲動找到
entitlements
區段,並確認包含broadworks-connector
。Webex for BroadWorks 使用者若有意使用 Webex for BroadWorks,則不應具備
bc-sp-standard
權限。 這是「Webex Calling (Broadcloud)」的權限,是透過受 Cisco 管理的雲端通話服務進行的 Webex 應用程式通話。
檢查組織的通話行為
使用合作夥伴管理員認證登入服務台 (https://admin.webex.com/helpdesk)。
搜尋組織。
按一下組織並檢查通話行為項目。 它應該是「在 Webex 中通話」。
分析使用者佈建問題的 PSLog
使用應用程式伺服器的 PSLog 來查看對佈建橋接器的 HTTP POST 請求,以及來自 Webex 的回應。
在正確的工作案例中回應是 200 OK,且幾分鐘後,您可以在 Webex 中查看已建立使用者(如果是首位使用者)和新客戶組織。
您可以在服務台中搜尋在 POST 中看見的電子郵件地址,來驗證這一點。
開始之前
在測試使用者進行佈建流程嘗試期間,從應用程式伺服器收集 PSLog。
1 | 要檢查的第一件事是 HTTP 回應代碼:
|
||
2 | 您也可以檢查原始 HTTP POST 是否有可能導致佈建失敗的任何可疑值。 POST 包含
|
分析 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 保護。
以下討論說明在您調查成功登入的記錄檔時,預期可查看的內容。

使用者與用戶端互動,用戶端與 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: Basic
與user-agent: broadworksTeamsClient
然後,XSP 針對 BroadWorks 執行 OCI-P 基本驗證(AuthenticationVerifyRequest 和 AuthenticationVerifyResponse,如透過 Xsi 執行基本驗證的其他任何應用程式),以及 UserGetRequest 和 ServiceProviderGetRequest 以收集訂閱者資訊。
對 Webex 的 Xsi 回應包含
Profile
區塊,內有 (BroadWorks)userId
及其他詳細資料(圖中的 2.2)的 XML。
用戶端和 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 使用者對應(圖中的 5.3)。 AuthService 已憑藉 mTLS 連接建立與 Webex 的信任,因此可以發出 LLT。尋找回應(圖中的 5.4),其來自
LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks ...
以及
StatusCode=200
,您可以與原始請求建立關聯,方法是使用trackingid: CLIENT…
標頭。
在 XsiActionsLog 中:
用戶端現在可以在 Xsi-Actions 介面呈現長時間使用權杖,以取得其裝置設定檔(圖中的 6)。 例如:
GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device
使用以下標頭:
authorization: Bearer token
與user-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(回送)
StatusCode=200
返回 Xsi以及權杖驗證回應,在本體中有
「權杖」
JSON 區塊。使用
trackingid: CLIENT… 建立關聯
在 XsiActionsLog 中:
從驗證用戶端權杖的 authservice 收到 200 OK 後,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)