ウォーター マーク
2021年3月29日 | 回表示 | 人がこの投稿記事が役に立ったと考えています

BroadWorks 版 Webex トラブルシューティングガイド

さまざまな『操作方法』のトピック、ログファイルのリストと使用法、具体的な問題を調査するときのヒントなど、BroadWorks 版 Webex に関するトラブルシューティングのアドバイス。

BroadWorks 版 Webex のトラブルシューティング

BroadWorks 版 Webex のトラブルシューティング

BroadWorks 版 Webex のトラブルシューティング

このドキュメントは、自らと顧客をサポートしているサービス プロバイダの組織の技術ユーザーを対象にしています。 一般的なトラブルシューティング、ログの読み取り、およびサブスクライバーのケースでの作業にすでにご経験があることを想定しています。

記事は 3 つの大きなセクションに分かれています。

  • リソース。これは、必要となる可能性があるツールのリスト、参照資料、ログ、連絡先です。
  • プロセス。これは、顧客の問題をトラブルシューティングする間に実行し得る操作の一部を説明します。
  • 特定の問題。発生することが知られている問題、見つける方法、および潜在的な解決方法を分類してリストします。

変更履歴

日付

変更

セクション

2020 年 12 月 8 日

更新されたドキュメント Webex Teams から Webex (アプリ) に再ブランド化。

エンド ユーザー エラー コードを追加しました

具体的な問題

2020年11月3日

コール設定 Webview を追加しました

具体的な問題

2020年10月22日

新しいドキュメントが導入されました

ウォーター マーク
2021年3月29日| 回表示 | 人がこの投稿記事が役に立ったと考えています

リソース

BroadWorks 版 Webex のトラブルシューティング リソース

連絡先


2020 年 10 月に、BroadSoft カスタマー サポートを Cisco CX サポートのプロセスおよびツールに移行します。 つまり、BroadWorks 版 Webex のパートナーは、ケース管理のために Xchange から Support Case Manager (SCM) を使用するように移動する必要があります。

移行は、2020 年末までに約 3 か月間実行されることが予想されます。 移行されると、BroadWorks/UCaaS TAC チームが、BroadSoft Jira ではなく、CSOne / Lightning のケースのサポートを開始します。 移行期間中に両方のシステムのケースを参照することが必要な場合があります。

詳細については、 「従来の BroadSoft サポートの移行」を参照してください。

便利なログ ファイル

ログ名 ソース トラブルシューティングに使用
PSLog アプリケーション サーバー フロースルー プロビジョニング
tomcat access_log XSP Webex アプリのログイン
XsiActionsLog XSP Webex IDP プロキシでの Webex アプリ ログインのインタラクション、デバイス プロファイル クエリのクライアントのインタラクション
authenticationService ログ XSP Webex アプリ ログイン (トークン検証および発行)
XSLog XSP?

プッシュ通知のためのモバイル サブスクリプション

コール シグナリング

Webex アプリのスタートアップ ログ

Windows: \Users\{username}\AppData\Local\CiscoSpark\current_log.txt

Mac:

/Users/{username}/Library/Logs/SparkMacDesktop/current_log

モバイル: ログの送信の使用

スタートアップ (シーケンス)

ユーザーのエンタイトルメントの確認

BroadWorks に接続するための BWC ライブラリの初期化

getUserProfile と JwT トークンの取得ログ

BroadWorks コーリング Webex アプリ ログ

クライアント

Windows: \Users\{username}\AppData\Local\CiscoSpark\bwc\current_log.txt

Mac:

/Users/{username}/Library/Logs/SparkMacDesktop/bwc/current_log

モバイル: ログの送信の使用

登録とコールのすべての SIP トラフィック

BWKS バックエンドへの Keep Alive トラフィック

シグナリングを必要とする中間コール機能 (保留/再開、転送など)

メディア (Webex Media Engine) ログ

クライアント

Windows:

\Users\{username}\AppData\Local\CiscoSpark\media\*.log

Mac:

/Users/{username}/Library/Logs/SparkMacDesktop/media/

モバイル: ログの送信の使用

すべてのメディアのログ記録

コールに対してネゴシエートされたコーデック

中間コール機能

読み取りリスト

ウォーター マーク
2021年3月29日| 回表示 | 人がこの投稿記事が役に立ったと考えています

プロセス

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

クライアントで次のとおりクリックします。[Help (ヘルプ)] > [Health Checker (ヘルス チェッカ)]

2

[データベースのリセット] を選択します。

これはクライアントの完全なリセットをトリガーし、Webex アプリログイン画面をロードします。

Webex が BroadWorks に登録することを確認する

Webex アプリは以下の情報を確認して、BroadWorks に登録するかどうかを判断します。

  • Broadworks-connector へのユーザー エンタイトルメント

  • 組織とユーザーの Calling 動作

ユーザーの Calling 動作とコネクタ エンタイトルメントを確認する

  1. 担当パートナーの資格情報を使用して [Help Desk (ヘルプ デスク)] (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. 担当パートナーの資格情報を使用して [Help Desk (ヘルプ デスク)] (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 テンプレートで認証モードを確認できます。 [Configure your Customer Templates (顧客テンプレートを設定する)]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 インターフェイスでは、POST によってトークンが authservice (ループバック インターフェイス上に構成される) になります。例: 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)

ウォーター マーク
2021年3月29日| 回表示 | 人がこの投稿記事が役に立ったと考えています

具体的な問題

BroadWorks 版 Webex のトラブルシューティング特定の懸案事項

Partner Hub の問題

管理者が顧客の組織を見ることができない

Webex のパートナー組織の管理者として、フル管理者のロールを持っている必要があります。 このロールは、自分自身や他のユーザーに管理者権限を割り当てるなど、パートナー組織の管理に使用されます。 顧客の組織を管理するには、自分 (または他の人) に販売フル管理者ロールまたは販売管理者ロールを付与する必要 があります。 https://help.webex.com/fs78p5 を参照してください。

ユーザー プロビジョニングの問題

特定の企業/顧客の IM&P エラーの統合

異なるクラウド コラボレーション サービスを使用する企業が混在する場合 (UC-One SaaS および BroadWorks 版 Webex)、企業ごとにプロビジョニングアダプタを変更することを選択した可能性があります。

統合型 IM&P (より具体的な設定が存在しない限り、企業のデフォルト) に対して設定されていることを確認するには AS_CLI/Interface/Messaging> get を実行します。 特定のエンタープライズのプロビジョニング パラメータについては、エンタープライズを開いて、[サービス] > [統合型 IM&P] に移動します。

そのエンタープライズの統合型 IM&P 構成が、Partner Hub のカスタマー テンプレートに表示されている情報と正確に一致することを確認してください。 以下の設定が一致する必要があります。そうしないと、エンタープライズのすべてのユーザーに対するプロビジョニングが失敗します。

BroadWorks エンタープライズ統合型 IM&P 設定

Partner Hub のカスタマー テンプレートの設定

メッセージング サーバー URL

プロビジョニング URL

メッセージング サーバーのユーザー名

プロビジョニング アカウント名

メッセージング サーバー パスワード

プロビジョニング アカウントのパスワード、パスワードの確認

特定ユーザーの統合型 IM&P のエラー

これは、フロースルー プロビジョニングを使用し、一部/ほとんどのユーザーに対してプロビジョニングが動作すると想定する場合に適用されます (これにより、構成の問題を排除できます)。

たとえば「メッセージング サーバーの [エラー 18215] プロビジョニング エラー」や「[エラー 18211] メッセージング サーバーとの通信エラー」など、BroadWorks で統合型 IM&P エラーが発生する場合、次の潜在的な原因を調査する必要があります。

  • ユーザーのメールアドレスはすでに CI が存在している可能性があります。 ヘルプ デスク内のユーザーを検索して、メールアドレスがすでに存在するかどうかを確認します。 これは必ずしも簡潔な話ではありません。ユーザーは、ヘルプ デスクで閲覧することを許可されていないデータをもつ組織に存在している可能性があります。

  • 統合型 IM&P サービスが割り当てられる前に、ユーザーは Webex に個別にサインアップします。 この場合、1 つのオプションは、ユーザーが無料アカウントを削除して、プロビジョニング中の顧客組織の一員になれる方法です。 手順は https://help.webex.com/5m4i4y に記載されています。

  • ユーザーはプロファイルにプライマリ電話番号が指定されていません (BroadWorks の全 Webex サブスクライバはプライマリ DID を持っている必要があります)。 「AS から PSLog を分析する」を参照してください。

プロビジョニング ブリッジからの応答でユーザー プロビジョニングに失敗しました

ユーザーが Control Hub に表示されない場合、統合型 IM&P を割り当てから数分以内に、プロビジョニング ブリッジ サービスからの応答コードを確認してください。 PSLog を実行して、HTTP 応答コードを確認します。

200 OK

200 OK 応答は、ユーザーが正常にプロビジョニングされたことを意味している意味ではありません。 つまり、プロビジョニング サービスが要求を受け取り、対応するユーザー作成要求をアップストリーム サービスに正常に送信したことを意味します。

設計により、プロビジョニング トランザクションは非同期です。 このサービスは 200 OK を応答します。ユーザー作成プロセスには数分かかり、パフォーマンス上の理由により、同じユーザーを作成するために複数の要求を受け取りたくないためです。

しかし、200 OK 応答の後、最終的にユーザーが顧客組織に表示されない場合、ユーザー作成がプロビジョニング サービスの Webex サービス アップストリームで失敗したこと示す場合があります。

200 OK 応答があるプロビジョニングの失敗をエスカレーションする必要があります

400 Bad 要求

この応答をプロビジョニング サービスから引き起こす可能性がある問題に関する詳細を持つ HTTP 応答を確認します。 <message> ノードのいくつかの例:

  • 「レガシー プロビジョニング API による BroadWorks メールを信頼できません。」

    失敗したユーザーのプロビジョニング要求に関連付けられたメール アドレスは有効ではないか、入力ミスですが、メール アドレスが信頼できることをテンプレートで確認しました。 BroadWorks でユーザーのプロファイル、特にメール ID を確認します。

  • 「顧客の組織はデータベースで見つからず、新しい組織作成フラグは有効になっていません。」

    この失敗したプロビジョニング要求は、Webex で新しい顧客組織を作成する必要がありますが、テンプレートが新しいカスタマー組織が作成されるのを防ぐために構成されています。 新しい組織を、Webex の既存の顧客と一致しないメール ドメインに対して許可する場合は、Partner Hub でテンプレートを再構成し、プロビジョニング要求を再テストできます。 しかし、このユーザーに対して新しい組織が作成されないことが予想される場合、おそらくメール アドレスに入力ミスがあると想定されます (特にドメイン部分)。 BroadWorks で、ユーザーのメール ID を確認します。

403 Forbidden

プロビジョニング要求に成功する可能性はありません。 この場合、要求と応答を調査する必要があります。 たとえば、組織の適切なプロビジョニング ブリッジ URL ではなく、プロビジョニング要求のターゲットとして IP アドレスが表示される場合 (ソリューション ガイドのファイアウォールの構成に関するトピックを参照してください)、アプリケーション サーバーに必要なパッチが欠落している可能性があります (ap373197)。

すべての必要なパッチがアプリケーション サーバーに適用され、関連する構成が正常なフロースルー プロビジョニングに対して完了した構成を確認してください。

409 Conflict

Webex に要求のメール アドレスと一致する既存のユーザーがいるので、プロビジョニングの要求は処理できません。

CI にすでにユーザーがいます

HTTP POST 要求からサブスクライバー メールを取得し、それをヘルプ デスクで検索します。

許可されていない場合はユーザーを見ることができないかもしれませんが、ユーザーが「無料」組織 (例:「消費者」) に所属しているのも見える場合があります。

このユーザーに無料アカウントの削除を求めるか、別のメールアドレスを使用してプロビジョンすることができます。 https://help.webex.com/ndta402 を参照してください。

ユーザーのサインインの問題

ユーザー アクティベーション ポータルがロードされない

BroadWorks の通常のサインイン フローには、ユーザーがパスワードを入力するユーザー アクティベーション ポータルが含まれます。 ユーザーが Webex アプリのサインイン画面でメール アドレスを入力した後で、ポータルがロードされない場合があります。

この問題は、クライアント側またはサービス側にある可能性があります。 クライアント側では、これは通常、クライアントのネイティブブラウザが何らかの形でサービスと互換性がないことが原因です。

シングル サイン オンに失敗しました

  • BroadWorks で、ユーザーに Webex アプリのデバイス タイプが割り当てられているか確認します (ソリューション ガイドの「環境を準備する」セクションの「デバイス プロファイル」セクションを参照してください)。

  • ユーザーが正しいパスワードを使用していることを確認します: ユーザーの顧客組織(Partner Hub)のプロビジョンに使用したテンプレートが BroadWorks 認証用に設定されている場合、ユーザーは BroadWorks の「Web Access」パスワードを入力する必要があります。

コーリングの構成と登録の問題

ユーザーが Webex でプロビジョニングされ、Webex アプリに正常にサインインした後で、アプリは BroadWorks に登録します。 以下は予想される登録シーケンスであり、結果として健全な登録の兆候です (Webex アプリから見た場合):

予想される登録シーケンス

  1. クライアントは XSI に発信し、デバイス管理トークンと DMS への URL を取得します。

  2. クライアントはステップ 1 からトークンを提示することで、DMS からそのデバイス プロファイルを要求します。

  3. クライアントはデバイス プロファイルを読み取り、SIP 資格情報、アドレス、およびポートを取得します

  4. クライアントはステップ 3 からの情報を使用して SIP REGISTER を SBC に送信します。

  5. SBC は SIP REGISTER を AS に送信します (SBC が SIP ユーザーをまだ知らない場合、SBC は AS を検索するために NS の検索を実行する場合があります。)

クライアント登録の成功が予想される兆候

コーリング オプション アイコンが Webex インターフェイスに表示されます。

Webex アプリの電話サービス タブ (Windows では [Settings (設定)] > [Phone Services (電話サービス)]、Mac では [Preferences (環境設定)] > [Phone Services (電話サービス)]) 、メッセージは次のとおりとなります。「SSO セッション: サインインしています」は、アプリが (この場合、BroadWorks に) 正常に登録されたことを意味します。

クライアントに Calling アイコンはありません

ほとんどの場合、これはユーザーが正しいライセンス/エンタイトルメントを持っていないことを意味します。

クライアントが電話サービス タブを表示するが、セッション SSO されない

これは登録が失敗したことを示します。 Webex アプリ クライアントが BroadWorks への登録に失敗する理由は次のように複数あります。

同じクライアントで複数のコーリング サービスをテストする

この既知の問題は、異なるコーリングバックの間でクライアントが変更された場合に生じる場合があります。 Webex アプリ クライアントを経由して提供される (同じ) 異なるコーリング サービスのトライアル中に発生する可能性が高い。 クライアント データベース (リンク) をリセットして、この問題を解決することができます。

認証サービスの構成ミス

認証サービスをホストする XSP をソリューション ガイドに対して確認します (「BroadWorks XSP の Webex でサービスを設定する」 を参照してください)。 具体的には、次の操作を行います。

  • RSA 鍵 (1 つの XSP で生成された) がすべての XSP にコピーされます

  • 認証サービス URL がすべての XSP のウェブ コンテナに提供され、Partner Hub のクラスターに正しく入力されました

  • 証明書による外部認証は次のように設定されます。

    XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>get
            
            allowUserApp = false
            allowClientApp = true
  • MTLS を使用する場合、Webex クライアント証明書を XSP にアップロードする必要があります (BroadWorks 設定ページの Partner Hub から証明書を取得できます)

BroadWorks タグの構成ミス

Webex アプリに必要な BroadWorks タグを構成済み (ソリューションガイドの「Webex に必要なBroadWorksタグ」を参照) であり、競合や間違った値が無いことを確認します。

特に、%SBC_ADDRESS_WXT% タグは、Webex アプリ クライアントの SIP 登録に向けた SBC である必要があります。

デスクトップ クライアントが SSO 接続に成功した後、電話サービスが切断される

この問題は、同じプラットフォーム タイプで同じユーザーが複数のクライアントにサインインすると発生する可能性があります。 たとえば、ユーザーが Windows の Webex アプリに正常にサインインし、異なる Windows マシンで Webex アプリにサインインした場合、アクティブな SSO セッションは 1 台のマシンにのみあります。 これは仕様です。

絶対にこの問題を回避する必要がある場合は、BroadWorks に同じデバイス タイプの複数のインスタンスを構成することができますが、固有の SIP アドレスを持つ必要があります。 この構成は、BroadWorks の Webex の範囲外にあります。

ユーザーに対してプロビジョニングされていないデスクトップ デバイス

この署名は、クライアント (\bwc\) ログに表示されます。

<Error> [0x70000476b000] BroadWorksConfigDownloader.cpp:106 onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - デバイス プロファイル「Business Communicator - PC」が見つかりません。

コール設定 Webview の問題

セルフ ケア ボタン/リンクが Webex アプリに表示されない

この問題には、ボタン/リンクが表示されているが、それをクリックすると外部ブラウザが開くという異なる症状があります。

  • 必要なクライアント構成テンプレートが展開され、CSW タグが適切に設定されていることを確認します。(「BroadWorks 版 Webex ソリューション ガイド」 の 「コール設定 Webview」セクションを参照)。

  • Webex アプリが BroadWorks でコールに対して登録されていることを確認します。

  • Webex アプリが CSWV をサポートする最新のバージョンであることを確認してください。

セルフ ケア ボタン/リンクをクリックした後の空白ページまたはエラーが発生する

一般的に、Webex アプリのこの動作は、BroadWorks XSP の CSWV アプリケーションの構成または展開の問題を示します。

CSWV ログ、アクセス ログ、config-wxt.xml レポジトリ、テンプレート ファイルなど、さらに調査の詳細を収集し、ケースを発生させます。

エンドユーザー エラー コード

次の表では、クライアントユーザーアクティベーション ポータルで確認できるエンドユーザー エラー コードを示します。


これは、エラー コードの徹底的なリストではありません。 この表は、Webex アプリがユーザーに明確な指示を提供していない既存のエラー コードのみをリストします。
表 1. エンドユーザー エラー コード

エラーコード

エラーメッセージ

200010

Broadworks ユーザーとしてが未承認のため、資格情報を確認できませんでした。

200018

ユーザーがロックアウトされたため、資格情報の検証に失敗しました

200019

セルフアクティベーションのためにユーザーを追加するときに、資格情報の検証に失敗しました

200022

ユーザーが未承認のため、メールを送信できませんでした。

200026

事前確認の失敗または保留中のユーザーの不正確な状態によりメールの検証に失敗しました PartnerOrgUUID: {partnerOrgUUID}、 BroadoworksUUID: {broadworksUUID}、ConfigSetUUID: {configSetUUID}

200039

emailId が別の組織ですでに使用されているため、メールを検証できません

200040

configSet が customerConfig の configSet に一致しないため、メールを検証中に失敗しました

200041

ユーザーが競合しているエンタイトルメントである別の共闘するサービスにすでにエンタイトルメントが付与されているため、メールの検証に失敗しました

200042

メールが別の BroadWorks UserID とすでに関連付けられているため、メールの検証に失敗しました

200043

ユーザー構成マッピングが正しくないため、メールの検証に失敗しました

200044

userId がこの BroadWorks クラスタですでに使用されているので、メールの検証に失敗しました

200045

ユーザーがすでに別の組織の一員であるため、セルフアクティベーションを通じてユーザーを追加できませんでした

200046

複数の保留中ユーザーが同じ BroadWorks クラスタの下で同じ BroadWorksUserIDで存在するため、セルフアクティベーションを通じてユーザーを追加できませんでした

200047

userId がこの BroadWorks クラスタですでに使用されているので、セルフアクティベーションを通じてユーザーを追加できませんでした

200048

メール アドレスがすでに別の BroadWorks userId でプロビジョニングされているため、セルフアクティベーションを通じてユーザーを追加できません

200049

userId がこの BroadWorks クラスタで既に使用されているので、セルフアクティベーションを通じてユーザーを追加できませんでした

200050

provisioningID がサブスクライバの企業の想定される provisioningID と一致しないため、セルフアクティベーションを通じてユーザーを追加できませんでした。

200051

この要求で指定された spEnterpriseId が、BroadWorks クラスタからすでにプロビジョニングされているサービス プロバイダ またはエンタープライズと競合するため、セルフアクティベーションを通じてユーザーを追加できませんでした。

この投稿記事は役に立ちましたか?

関連の投稿記事

最近閲覧した投稿記事

×