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. Partner Hub にサインインし、ユーザーの顧客組織を見つけます。

  2. [トラブルシューティング] をクリックします。

  3. [ログイン] を選択します。

  4. ユーザーを検索します (メールで)。

  5. クライアント ログを zip ファイルとして表示し、ダウンロードします。

ヘルプ デスクのオプション:

  1. ヘルプ デスクにサインインします。

  2. 組織を検索します。

  3. 組織をクリックします (概要画面を開きます)。

  4. 下にスクロールして [表示][顧客] をクリックします。

  5. [トラブルシューティング] を選択します。

  6. [ログイン] を選択します。

  7. ユーザーを検索します (メールで)。

  8. クライアント ログを zip ファイルとして表示し、ダウンロードします。

クライアント バージョンの検索方法

1

このリンクをユーザーと共有します。 https://help.webex.com/njpf8r5

2

ユーザーにバージョン番号の送信を要求します。

Calling サービスのクライアント チェック

1

Webex クライアントにサインインします。

2

[Calling オプション] アイコン (上記の歯車のあるハンドセット) がサイドバーに表示されるかを確認します。

アイコンが存在しない場合、ユーザーは Control Hub のコーリング サービスに対して有効に設定されていない可能性があります。

3

[設定/基本設定] メニューを開き、[電話サービス] セクションに進みます。 [セッションにサインインSSO 状態] が表示されます。

(Webex Calling などの異なる電話サービスが表示される場合、ユーザーは BroadWorks 版 Webex を使用していません。)

この確認の意味:

  • クライアントは必要な Webex マイクロサービスを正常に通過しました。
  • ユーザーが清浄に認証されました。
  • クライアントが BroadWorks システムによって長期間 JSON ウェブ トークンを発行されました。
  • クライアントはデバイス プロファイルを取得し、BroadWorks に登録しました。

クライアント ログまたはフィードバックを取得する

  • 「リソース」セクションを参照して、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 動作とコネクタ エンタイトルメントを確認する

  1. パートナー管理者資格情報を使用して、ヘルプ デスク (https://admin.webex.com/helpdesk) にサインインします。

  2. ユーザーを検索します。

  3. ユーザーをクリックして、[Calling 動作] エントリを確認します。 「Webex での Calling」である必要があります。

  4. ユーザー名をクリックして、[ユーザーの詳細] 画面を開きます。

  5. 下にスクロールしてentitlementsセクションを探し、broadworks-connector が含まれていることを確認します。


    BroadWorks に Webex を使用する場合、BroadWorksの Webex ユーザーは 、bc-sp 標準エンタイトルメント を持つ必要があります。 これは、Cisco が管理するクラウド コーリング サービスを通じた Webex アプリ コーリングである「Webex Calling (Broadcloud)」のエンタイトルメントです。

組織の Calling 動作を確認する

  1. パートナー管理者資格情報を使用して、ヘルプ デスク (https://admin.webex.com/helpdesk) にサインインします。

  2. 組織を検索します。

  3. 組織をクリックして、[Calling 動作] エントリを確認します。 「Webex での Calling」である必要があります。

ユーザー プロビジョニングの問題に対して PSLog を分析する

アプリケーション サーバーの PSLog を使用して、プロビジョニング ブリッジへの HTTP POST 要求と Webex からの応答を確認します。

正しい作業事例では、応答は 200 OK です。また、数分後にユーザーが表示され、最初のユーザーの場合は新しい顧客組織が Webex で作成されました。

POST に表示されるメール アドレスのヘルプ デスクを検索して、これを確認できます。

スケジューリングを始める前に

テスト ユーザーを使用したフロースルー プロビジョニング試行中に、アプリケーション サーバーから PSLog を収集します。

1

最初に確認する必要があるのは、HTTP 応答コードです。

  • 200 OK 以外のものはすべて、ユーザー プロビジョニングの失敗です。

  • プロビジョニング ブリッジの Webex サービスのアップストリームでサブスクライバー プロファイルについて何かが機能しない場合、[200 OK] は引き続き失敗を示す場合があります。

  • 400 は応答に メッセージ ノードを含む場合があります。 プロビジョニング ブリッジは subscriberProfile の何かを処理できませんでした。 サブスクライバーの詳細に問題がある、またはテンプレートの設定と非互換性がある場合があります。

  • 401 は AS に入力したプロビジョニング資格情報が Partner Hub のテンプレートに入力した資格情報と一致しないことを意味します。

  • 403 はアプリケーション サーバーに設定ミスがあることを示す場合があります。 要求のターゲットを確認します。IP アドレスであってはなりません。Partner Hub のテンプレートに表示できるプロビジョニング ブリッジ URL である必要があります。

  • 409 は提供された subscriberProfile と既存の Webex データの間の競合を示します。 そのメール アドレスを持つ既存のユーザーがいる可能性があります。 応答の メッセージ を確認します。

2

プロビジョニングが失敗する可能性がある疑わしい値について、元の HTTP POST を確認することもできます。

POST には subscriberProfile XML 構造が含まれます。 この中で確認する便利なノードは次のとおりです。

  • bwuserid: BroadWorks でサブスクライバ プロファイルを編集する必要がある場合は、これを使用してそれを見つけてください。

  • group: テンプレートが「サービス プロバイダ モード」の場合、小文字になり、Partner Hub に表示される顧客組織の名前になります。

  • serviceProvider: テンプレートが「エンタープライズ モード」の場合、小文字になり、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 サービスと対話します。

  • ユーザーは 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

    ヘッダーには認証が含まれます。 Basicuser-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 tokenuser-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… ヘッダーと POSTX-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-P UserPrimaryAndSCADeviceGetListResponse を受信します。

  • OCI-P 応答は、AccessDevices XML 構造を含むクライアントへの Xsi 応答としてエンコードされます。これは deviceTypes をもちます。例: Business Communicator – PC。また、クライアントがデバイス構成ファイルを取得できる URL を持ちます。

クライアントは通常通り継続します。

  • デバイス エントリを選択し、DMS と対話してデバイス プロファイルを取得する (図の 6)

  • DMS からの構成で取得できる SBC 経由の BroadWorks に登録する (図の 7)