- BroadWorks 版 Webex のトラブルシューティング プロセス
- 問題のエスカレーション
- どのクライアント情報を収集するか検討する
- ユーザーの詳細をヘルプ デスクで確認する
- ヘルプデスクで顧客の組織内を確認する
- Partner Hub からユーザー ログを取得する
- クライアント バージョンの検索方法
- Calling サービスのクライアント チェック
- クライアント ログまたはフィードバックを取得する
- Calling 環境データを取得する
- Webex データベースをリセットする
- Webex が BroadWorks に登録することを確認する
- ユーザー プロビジョニングの問題に対して PSLog を分析する
- XSP ログを分析してサブスクライバー ログインをトラブルシューティングする
BroadWorks 版 Webex のトラブルシューティング プロセス
問題のエスカレーション
トラブルシューティングのガイダンスの一部に従った後で、問題がどこにルートされているのか妥当なアイデアを持っている必要があります。
1 | この問題に関連するシステムからできる限り多くの情報を収集する |
2 | Cisco で適切なチームに連絡してケースを開く (「連絡先」セクションを参照してください) |
どのクライアント情報を収集するか検討する
ケースを開くか、問題をエスカレーションする必要がある場合、ユーザーとのトラブルシューティング中に以下の情報を収集します。
ユーザー ID: CI メール アドレスまたはユーザー UUID (これは Webex ID ですが、ユーザーの BroadWorks ID も取得した場合、これは役立ちます)
組織 ID
問題を経験している間のおよその時間
クライアント プラットフォームとバージョン
クライアントからログを送信または収集する
クライアントに表示されている場合は、トラッキング ID を記録する
ユーザーの詳細をヘルプ デスクで確認する
1 | https://admin.webex.com/helpdesk にサインインします。 |
2 | ユーザーを検索してクリックします。 これによりユーザー概要画面が開きます。 |
3 | 詳細なユーザー構成を確認するために、ユーザー名をクリックします。 このビューの有用な情報には、ユーザーの UUID、共通 ID (CI) クラスター、Webex アプリ クラスター、Calling 動作、BroadWorks アカウント GUID が含まれます。 |
4 | 別のツールでこの情報を使用する必要がある場合は、[コピー] をクリックするか、Cisco ケースにそれを添付します。 |
ヘルプ デスクで顧客の組織内を確認する
1 | https://admin.webex.com/helpdesk にサインインします。 |
2 | 顧客の組織名を検索してクリックします。 |
3 | [顧客ポータルの表示] が表示されるまでスクロールダウンし、[表示][CustomerName] をクリックして、ユーザーおよび構成を含む顧客組織の読み取り専用ビューを表示します。 |
Partner Hub からユーザー ログを取得する
デスクトップとモバイル クライアントの問題をトラブルシューティングする場合、パートナー (および TAC) がクライアント ログを表示することが重要です。
1 | ユーザーにログの送信を要求します。 |
2 | ユーザーに対し、Calling 環境をエクスポートして ced.csv ファイルを送信してください。 |
3 | Partner Hub またはヘルプ デスクからクライアント ログを取得します (以下を参照)。 Partner Hub のオプション:
ヘルプ デスクのオプション:
|
クライアント バージョンの検索方法
1 | このリンクをユーザーと共有します。 https://help.webex.com/njpf8r5 |
2 | ユーザーにバージョン番号の送信を要求します。 |
Calling サービスのクライアント チェック
1 | Webex クライアントにサインインします。 |
2 | [Calling オプション] アイコン (上記の歯車のあるハンドセット) がサイドバーに表示されるかを確認します。 アイコンが存在しない場合、ユーザーは Control Hub のコーリング サービスに対して有効に設定されていない可能性があります。 |
3 | [設定/基本設定] メニューを開き、[電話サービス] セクションに進みます。 [セッションにサインインSSO 状態] が表示されます。 (Webex Calling などの異なる電話サービスが表示される場合、ユーザーは BroadWorks 版 Webex を使用していません。) この確認の意味:
|
クライアント ログまたはフィードバックを取得する
「リソース」セクションを参照して、Webex デスクトップ クライアントの特定のクライアント ログを見つけるか、ログを送信することをユーザーに尋ねください。
モバイル クライアントのユーザーにログの送信を要求してから、Partner Hub またはヘルプ デスクからログを取得できます。
ログの送信はサイレントです。 しかし、ユーザーがフィードバックを送信する場合、フィードバックは Cisco Webex アプリ 開発チームに送信されます。 Cisco でフォローアップする場合は、ユーザーのフィードバック番号を必ず記録してください。 例: ![]() |
Calling 環境データを取得する
Webex クライアント ログは、個人識別情報を削除するために大幅に変更されています。 Calling 環境データは、問題に気づいたのと同じセッションでクライアントからエクスポートする必要があります。
1 | クライアントで、プロファイル画像をクリックし、[ヘルプ] > [Calling 環境データのエクスポート] をクリックします。 |
2 | このユーザーのコーリングの問題をトラブルシューティングするために、結果として生成されたファイル ced.dat を保存します。 重要: クライアントからログアウトまたは再起動すると、内部キャッシュがクリアされます。 その後、ced.dat をエクスポートする場合、エクスポートされたデータはキャッシュ前に送信されたどのログにも対応しません。 |
Webex データベースをリセットする
1 | クライアントで、 をクリックします。 |
2 | [データベースのリセット] を選択します。 これはクライアントの完全なリセットをトリガーし、Webex アプリログイン画面をロードします。
|
Webex が BroadWorks に登録することを確認する
Webex アプリは以下の情報を確認して、BroadWorks に登録するかどうかを判断します。
Broadworks-connector へのユーザー エンタイトルメント
組織とユーザーの Calling 動作
ユーザーの Calling 動作とコネクタ エンタイトルメントを確認する
パートナー管理者資格情報を使用して、ヘルプ デスク (https://admin.webex.com/helpdesk) にサインインします。
ユーザーを検索します。
ユーザーをクリックして、[Calling 動作] エントリを確認します。 「Webex での Calling」である必要があります。
ユーザー名をクリックして、[ユーザーの詳細] 画面を開きます。
下にスクロールして
entitlements
セクションを探し、broadworks-connector
が含まれていることを確認します。BroadWorks に Webex を使用する場合、BroadWorksの Webex ユーザーは
、bc-sp 標準エンタイトルメント
を持つ必要があります。 これは、Cisco が管理するクラウド コーリング サービスを通じた Webex アプリ コーリングである「Webex Calling (Broadcloud)」のエンタイトルメントです。
組織の Calling 動作を確認する
パートナー管理者資格情報を使用して、ヘルプ デスク (https://admin.webex.com/helpdesk) にサインインします。
組織を検索します。
組織をクリックして、[Calling 動作] エントリを確認します。 「Webex での Calling」である必要があります。
ユーザー プロビジョニングの問題に対して 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 プロキシは 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
ヘッダーには
認証が含まれます。 Basic
とuser-agent: broadworksTeamsClient
XSP は、BroadWorks に対して OCI-P Basic 認証を行います (AuthenticationVerifyRequest および AuthenticationVerifyResponse、Xsi 経由で Basic 認証を行う他のアプリケーションと同様)。また、UserGetRequest および ServiceProviderGetRequest を使ってサブスクライバ情報を収集します。
Webex への Xsi 応答には、(BroadWorks)
userId
および他の詳細 (図の 2.2) を含む XMLプロファイル
ブロックが含まれます。
クライアントと Webex サービスの対話:
IDP プロキシは BroadWorks から受け取ったユーザー プロファイルと一致し、SAML アサーションをクライアントに発行します (図の 2.3)。
クライアントは CI トークンの SAML アサーションを交換します (図の 3)
クライアントは、サインインしたユーザーが broadworks-connector エンタイトルメントを持っていることを確認します (図の 4)。 ヘルプ デスクでユーザーのエンタイトルメントを確認します)
クライアントは CI トークンを使用して、IDP プロキシから JSON ウェブ トークン (JWT) を要求します (図の 5)
IDP プロキシが CI で CI トークンを検証します
IDP プロキシは認証サービスから JWT を要求します
authenticationService ログ:
Webex からのトークン要求を検索します (図の 5.2)。例:
GET /authService/token
これには
http_bw_userid
ヘッダーやその他が含まれています。XSP は OCI-P
UserGetLoginInfoRequest
を実行し、提供されたユーザー ID が BroadWorks ユーザーに対応しているか検証します (図の 5.3)。 AuthService は mTLS 接続により Webex との信頼を確立しました。そのため LLT を発行できます。LongLivedTokenManager から応答 (図の 5.4) を検索します - トークンが生成されました、件名: 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
ヘッダー
認証の場合: Bearer token
とuser-agent: WebexTeams (variant/version)
Xsi-Actions インターフェイスはトークンを authservice (アドレス インターフェイスに構成される構成) に POST します。例:
127.0.0.1:80 POST http://127.0.0.1:80/authService/token
これにより、
trackingid と関連付け可能です。
GETの CLIENT…
ヘッダーとPOST
のX-BROADSOFT-CORRELATION-ID : CLIENT…
ヘッダー
authenticationService ログの場合:
Xsi (ループバック) からの POST の受領
StatusCode=200
は xsi に戻る本文に
"token"
JSON ブロックを持つ、トークン検証応答。trackingid: CLIENT… を使用して関連付け
XsiActionsLog の場合:
クライアントのトークンを検証した authservice から 200 OK を受け取り、Xsi-Actions アプリケーションは、
UserPrimaryAndSCADeviceGetListRequest に対して OCI-P 要求を送信するようになりました。
accessDeviceTable
XML 構造を含む OCI-PUserPrimaryAndSCADeviceGetListResponse
を受信します。OCI-P 応答は、
AccessDevices
XML 構造を含むクライアントへの Xsi 応答としてエンコードされます。これはdeviceTypes
をもちます。例:Business Communicator – PC
。また、クライアントがデバイス構成ファイルを取得できる URL を持ちます。
クライアントは通常通り継続します。
デバイス エントリを選択し、DMS と対話してデバイス プロファイルを取得する (図の 6)
DMS からの構成で取得できる SBC 経由の BroadWorks に登録する (図の 7)