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（其包含accessDeviceTableXML 結構）。OCI-P 回應會編碼為對用戶端的 Xsi 回應，包括
AccessDevicesXML 結構，該結構具有deviceTypes，例如Business Communicator – PC，以及用戶端可在其中擷取裝置組態檔的 URL。
用戶端如常繼續：
選取裝置項目並與 DMS 互動以取得裝置設定檔（圖中的 6）
透過從 DMS 組態中擷取的 SBC 向 BroadWorks 註冊（圖中的 7）
Join the conversation
