コメントありがとうございます。

この記事は、自社と顧客をサポートするサービスプロバイダー組織のテクニカルサポートチームを対象としています。 一般的なトラブルシューティング、ログの閲覧、サブスクライバーケースの取り扱いに精通している必要があります。

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

• リソース—必要なツール、読み物、ログ、連絡先のリストを提供します。
• プロセス—顧客の問題のトラブルシューティング中に実行できるいくつかのアクションについて説明します。
• 特定の問題—発生がわかっている問題、その発見方法、および解決できる可能性のある方法を分類して一覧表示します。

役に立つログファイル

読書リスト

• シスコブロードワークス向けWebexパートナーナレッジポータル
• XSP プラットフォーム設定ガイド (R23)
• ブロードワークスソフトウェア管理ガイド（R23）
• シスコブロードワークスデバイス管理設定ガイド（R23）
• Broadworks Xspコマンドラインインターフェイス管理ガイド
• 長期認証トークンの機能説明リリース23.0です
• SAML認証統合ガイド、R23
• シスコ・ブロードワークス SSL サポートオプションガイド
• シスコ CI サポート機能の説明
• 通知プッシュサーバー（機能の説明）
• 通話のプッシュ通知サポート機能説明リリース 22.0
• 接続（アンドロイド）Firebaseへの移行手順の方法
• Cisco BroadWorks プッシュ通知用デバイストークンのストレージ機能説明リリース 22.0
• シスコブロードワークスシステムキャパシティプランナー（スプレッドシート）
• シスコブロードワークスプラットフォーム寸法測定ガイド
• シスコ・ブロードワークスのシステム・エンジニアリング・ガイド
• CI 認証サポート要件ドキュメントバージョン 1.0 MR-7136

既知の問題と制限事項

既知の問題と制限の記事には、Webex for BroadWorksソリューションで特定された既知の問題に関する最新情報が掲載されています。

サービスアビリティコネクター

Webex Serviceability サービスにより、シスコのテクニカルアシスタンススタッフがインフラストラクチャの問題を診断する時間が短縮されます。 診断ログや情報の検索、取得、SRケースへの保存のタスクを自動化します。 このサービスでは、診断シグネチャに対する分析もトリガーされるため、TACはオンプレミス機器の問題をより効率的に特定して解決できます。

サービスアビリティコネクタの展開方法の詳細については、「サービスアビリティコネクタの導入ガイド」を参照してください。Cisco Webex

問題をエスカレートする

トラブルシューティングのガイダンスをいくつか実行したら、問題の原因をある程度把握できるはずです。

手順

1. 問題に関連するシステムからできるだけ多くの情報を収集してください。
2. ケースを開くには、シスコの適切なチームに連絡してください。

どのようなクライアント情報を収集するか

ケースをオープンしたり、問題をエスカレーションしたりする必要があると思われる場合は、 ユーザーと一緒にトラブルシューティングを行う際に次の情報を収集してください。

• ユーザー識別子：CIのメールアドレスまたはユーザーのUUID（これはWebexの識別子ですが、ユーザーのBroadWorksの識別子も取得している場合は、ケースの詳細に含めてください）。
• 組織識別子。
• 問題が発生したおおよその期間。
• クライアントのプラットフォームとバージョン。
• クライアントからログを送信または収集します。
• クライアントに追跡IDが表示されている場合は、記録してください。

ヘルプデスクでユーザーの詳細を確認してください

ヘルプデスク管理者（基本または上級） の権限を持つパートナー管理者は、この手順を使用して、ヘルプデスクビューを使用してユーザーの詳細を確認できます。

手順

1. ヘルプデスクにサインインしてください。
2. ユーザーを検索してクリックします。 これにより、ユーザー概要画面が開きます。
3. ユーザー名をクリックすると、詳細なユーザー設定が表示されます。 このビューで役立つ情報には、ユーザーの UUID、共通アイデンティティ (CI) クラスタ、Webex アプリクラスタ、通話行動、BroadWorks アカウント GUID などがあります
4. この情報を別のツールで使用したり、 シスコのケースに添付したりする必要がある場合は、「コピー」をクリックしてください。

ヘルプデスクで顧客組織を見る

ヘルプデスク管理者（基本または上級）の権限を持つパートナー管理者は、 この手順を使用して、ヘルプデスクビューで顧客組織の詳細を表示できます。

手順

1. ヘルプデスクにサインインしてください。
2. 顧客の組織名を検索してクリックします。
3. カスタマーポータルビューが表示されるまで下にスクロールし、「 顧客名を表示」をクリックすると、 ユーザーと設定を含む顧客組織の読み取り専用ビューが表示されます。

パートナーハブからユーザーログを取得する

デスクトップやモバイルクライアントの問題をトラブルシューティングするときは、パートナー（とTAC）がクライアントのログを見ることができることが重要です。

手順

1. ユーザーにログを送信するように依頼してください。 ヘルプが必要な場合は、「Webex アプリ | 問題を報告してください。
2. ユーザーに通話環境をエクスポートして、ced.dat ファイルを送ってもらいます。
3. パートナーハブまたはヘルプデスクからクライアントログを入手してください。

   パートナーハブのオプション:

   1. Partner Hubにサインインして、ユーザーの顧客組織を探してください。
   2. 「トラブルシューティング」を選択します。
   3. ログを選択してください。
   4. ユーザーを（メールで）検索します。
   5. クライアントログをzipファイルとして表示してダウンロードします。

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

   1. ヘルプデスクにサインインしてください。
   2. 組織を検索してください。
   3. 組織をクリックします（概要画面が開きます）。
   4. 下にスクロールして [顧客を表示] をクリックします。
   5. 「トラブルシューティング」を選択します。
   6. ログを選択してください。
   7. ユーザーを（メールで）検索します。
   8. クライアントログをzipファイルとして表示してダウンロードします。

クライアントバージョンを調べる方法

手順

1. このリンクをユーザーと共有してください:https://help.webex.com/njpf8r5
2. ユーザーにバージョン番号を送ってもらいます。

クライアントは通話サービスをチェックします

手順

1. Webex クライアントにサインインします。
2. サイドバーに通話オプションアイコン（上に歯車の付いた携帯電話）が表示されていることを確認してください。 アイコンが表示されていない場合、ユーザーはコントロールハブの通話サービスをまだ有効にしていない可能性があります。
3. 設定/環境設定メニューを開き、電話サービスセクションに移動します。 ログインしているSSOセッションのステータスが表示されます。 （など、別の電話サービスが表示されている場合Webex Calling、ユーザーはCisco BroadWorksでWebexを使用していません。）

   この検証の意味は：

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

クライアントのログやフィードバックを入手してください

• Webex デスクトップクライアントの特定のクライアントログを検索したり、 ユーザーにログを送信するよう依頼したりするには、リソースセクションを参照してください。 ヘルプが必要な場合は、「Webex アプリ | 問題を報告してください。
• モバイルクライアントのユーザーにログを送信してもらうと、Partner Hubまたはヘルプデスクからログを入手できます。
  ログの送信はサイレントです。 ただし、ユーザーがフィードバックを送信すると、Webex App DevOpsチームに送られます。 シスコにフォローアップしたい場合は、ユーザーのフィードバック番号を必ず記録してください。 例えば:

  

通話環境データを取得する

Webex クライアントのログは、個人を特定できる情報を削除するために大幅に編集されています。 問題に気付いたのと同じセッションで、 クライアントから通話環境データをエクスポートする必要があります。

手順

1. クライアントで [ヘルプ] > [ ヘルスチェッカー] をクリックします。
2. 「データベースをリセット」を選択します。 これにより、クライアントが完全にリセットされ、Webex アプリのログイン画面が読み込まれます。

Webex がブロードワークスに登録する必要があることを確認してください

Webex アプリは次の情報をチェックして、BroadWorks に登録するかどうかを判断します。

• ブロードワークスコネクターのユーザー資格。
• 組織とユーザーの通話行動。

ユーザーの通話行動とコネクターの資格を確認してください

1. パートナー管理者の資格情報でヘルプデスクにサインインしてください。
2. ユーザーを検索してください。
3. ユーザーをクリックして、通話行動のエントリを確認してください。 「Webexでの通話」のはずです。

   

4. ユーザー名をクリックして、ユーザーの詳細画面を開きます。
5. 下にスクロールして「権限」セクションを見つけ、broadworks-connectorが含まれていることを確認します

   

   シスコブロードワークス向け Webex ユーザーは、Cisco BroadWorks で Webex を使用するつもりなら、bc-sp-standard の使用権を持つべきではありません。 これは、シスコが管理するクラウド通話サービスを介してWebexアプリを呼び出す「Webex Calling（Broadcloud）」の使用権です。

組織の通話行動を確認してください

1. パートナー管理者の資格情報でヘルプデスクにサインインしてください。
2. 組織を検索してください。
3. 組織をクリックして、通話行動のエントリを確認してください。 「Webexでの通話」のはずです。

PSLogでユーザープロビジョニングの問題を分析してください

アプリケーションサーバーのPSLogを使用して、プロビジョニングブリッジへのHTTP POSTリクエストとWebexからの応答を確認してください。 正しく動作すれば、応答は 200 OK で、 数分後にユーザー（最初のユーザーの場合は新しい顧客組織） がWebexで作成されたことがわかります。 これを確認するには、 POSTに記載されているメールアドレスをヘルプデスクで検索してください。

始める前に

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

手順

1. まず、HTTPレスポンスコードを確認してください。
   • 200 OK以外はユーザープロビジョニングの失敗です。
   • プロビジョニングブリッジの上流のWebexサービスでサブスクライバープロファイルに関する何かが機能しない場合は、200 OKでも障害を示している可能性があります。
   • 400の応答にはメッセージノードが含まれる場合があります。 プロビジョニングブリッジは、サブスクライバープロファイル内の何かを処理できませんでした。 購読者の詳細に問題があるか、テンプレートの設定と互換性がない可能性があります。
   • 401は、ASに入力されたプロビジョニング認証情報がパートナーハブのテンプレートに入力されたものと一致しないことを意味します。
   • 403は、アプリケーションサーバーで何かが正しく構成されていないことを示している可能性があります。 リクエストのターゲットを確認してください。IPアドレスではなく、Partner HubのテンプレートにあるプロビジョニングブリッジのURLでなければなりません。
   • 409は、提供されたサブスクライバープロファイルと既存のWebexデータとの間に矛盾があることを示しています。 そのメールアドレスを持つ既存のユーザーがいる可能性があります。 返信のメッセージを確認してください。
2. また、元のHTTP POSTに、 プロビジョニングが失敗する原因となる疑わしい値がないかどうかを確認することもできます。 POSTには、 サブスクライバープロファイルのXML構造が含まれています。 この中で、確認すると便利なノードは次のとおりです。
   • bwuserid: BroadWorksで編集する必要がある場合は、これを使って購読者プロフィールを探してください。
   • グループ:テンプレートが「サービスプロバイダーモード」の場合、これは小文字になり、パートナーハブに表示される顧客組織の名前になります。
   • サービスプロバイダー：テンプレートが「エンタープライズモード」の場合、 これは小文字になり、パートナーハブに表示される顧客組織の名前になります。
   • メインの電話番号:存在する必要があります。 それなしではプロビジョニングは失敗します。
   • 電子メール:WebexのユーザーIDになります。 有効で、 Webex固有のものでなければなりません。そうでない場合、プロビジョニングは失敗します。

     サービススタンザは無視してください。ASによって作成され、受け入れられますが、Webexでは使用されません。

XSPログを分析して、サブスクライバーのログインをトラブルシューティングします

このフローでは、BroadWorksの認証モードについて説明します。 認証モードは、 パートナーハブの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は、（UAP経由で）BroadWorksのパスワードを入力するようにこのユーザーをリダイレクトすることを知っています（図の2）。
• IDPプロキシは、XSPのXSIインターフェイスにプロファイルの取得リクエストを送信します。

トムキャットのアクセスログには：

• WebexからXsi-ActionsインターフェイスへのサブスクライバープロファイルのGETリクエストを探してください（図の2.1）。 WebexのユーザーIDがあります。 例えば:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile

XSIアクションログに：

• WebexからのプロファイルのGETリクエスト（図の2.1）を探してください。 WebexのユーザーIDがあります。 例えば:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile ヘッダーにはオーソライゼーション:ベーシックとユーザーエージェント:BroadworksSteamsClientが含まれます

• その後、XSPはBroadWorksに対してOCI-P基本認証 （ Xsiを介して基本認証を行う他のアプリケーションと同様に、認証検証リクエストと認証検証レスポンス）を行い、UserGetRequestとServiceProviderGetRequestを実行してサブスクライバー情報を収集します。
• WebexへのXsiの応答には、（BroadWorks）ユーザーIDとその他の詳細 （図の2.2）を含むXMLプロファイルブロックが含まれています。

クライアントと Webex サービスのやり取り：

• IDPプロキシは、BroadWorksから受信したユーザープロファイルを照合し、 クライアントにSAMLアサーションを発行します（図の2.3）。
• クライアントはSAMLアサーションをCIトークン（図の3つ）と交換します。
• クライアントは、サインインしたユーザーがbroadworks-Connectorの資格を持っていることを確認します（図の4）。 ユーザーの資格はヘルプデスクで確認できます。
• クライアントはCIトークンを使用して、IDPプロキシ（ 図の5）にJSON Webトークン（JWT）を要求します。
• IDPプロキシはCIでCIトークンを検証します。
• IDPプロキシは認証サービスにJWTを要求します。

認証サービスログに：

• Webex（図の5.2）からのトークンリクエストを探してください。たとえば、http_bw_useridヘッダーのあるGET /authService/tokenなどがあります。
• XSPはOCI-P UserGetLoginInfoRequestを実行して、 指定されたユーザーIDがブロードワークスのユーザー（図の5.3）に対応していることを確認します。 AuthServiceはmTLS接続のおかげでWebexとの信頼関係を確立しているので、LLTを発行できます。
• LongLivedTokenManager- トークンが生成されました。件名:bwksUserId@example.com、発行者:BroadWorks...、 StatusCode=200からの応答（図の5.4）を見てください。これは、trackingid: CLIENT... ヘッダーを使用して元のリクエストに関連付けることができます。

XSIアクションログに：

• クライアントは、Xsi-Actionsインターフェイスで長寿命トークンを提示して、デバイスプロファイルを取得できます（図の6）。 例:GET /com.broadsoft.xsi-actions/v2.0/user/BWKSUSERID %40example.com/profile/device ヘッダー付き認証:ベアラートークンとユーザーエージェント:WebExTeams (バリアント/バージョン)
• Xsi-Actionsインターフェイスは、トークンを認証サービス（ループバックインターフェイス上に設定されている）にPOSTします（例：127.0.0. 1:80 POST http://127.0.0.1:80/authService/token）。これは、GETの trackingid: CLIENT... ヘッダーと POST の X-BROADSOFT-CORRELATION-ID: CLIENT... ヘッダーと関連付けることができます。

認証サービスログに：

• XsiからのPOSTの受信（ループバック）

• ステータスコード=200をXsiに戻します

• そして、 本文に「token」JSONブロックを含むトークン検証レスポンス。

• トラッキングIDを使用して関連付けます：CLIENT...

XSIアクションログに：

• 認証サービスから200 OKを受け取り、クライアントのトークンを検証したので、 Xsi-ActionsアプリケーションはUserPrimaryandscadeviceGetListRequestにOCI-Pリクエストを送信するようになりました
• OCI-Pユーザープライマリと、アクセスデバイステーブルのXML構造を含むSCADeviceGetListレスポンスを受信します。
• OCI-P応答は、デバイスタイプを含むAccessDevices XML構造を含む、クライアントへのXsi応答としてエンコードされます。 例：ビジネスコミュニケーター — PCと、クライアントがデバイス設定ファイルを取得できるURL。

クライアントは通常どおり続けます：

• デバイスエントリを選択し、DMSと対話してデバイスプロファイルを取得します（図の6）。
• DMSからの設定でSBC経由でBroadWorksに登録します（図の7）。

パートナーハブの問題

1。管理者は顧客の組織を見ることができません

Webex のパートナー組織の管理者には、フルアドミニストレータの役割が必要です。 その役割は、自分や他の人に管理権限を割り当てるなど、パートナー組織の管理に使用されます。 顧客組織を管理するには、自分自身（または他の人）に営業管理者の役割または営業管理者の役割を付与する必要があります。 詳細については、「Control Hub での組織アカウントロールの割り当て」を参照してください。

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

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

UC-One SaaSとCisco BroadWorks用のWebexなど、さまざまなクラウドコラボレーションサービスを利用している企業が混在している場合は、企業ごとにプロビジョニングアダプターを変更することを選択したかもしれません。

統合IM&P（ より具体的な設定がない限り、企業向けのデフォルト）に何が設定されているかを確認するには、as_CLI/interface/Messaging> getを実行してください。 特定の企業のプロビジョニングパラメータについては、その企業を開いて、 サービス > 統合IM&Pに進んでください。

その企業の統合IM&P構成が、Partner Hubの顧客テンプレートに表示されているものと完全に一致していることを確認してください。 次の設定は一致する必要があります。一致していないと、 企業内のすべてのユーザーのプロビジョニングが失敗します。

2。特定のユーザー向けの統合IM&Pエラー

これは、フロースループロビジョニングを使用しており、プロビジョニングが一部またはほとんどのユーザーに有効であることを前提としている場合に当てはまります（そのため、設定の問題は除外できます）。 「[エラー18215] メッセージングサーバーのプロビジョニングエラー」や「[エラー18211] メッセージングサーバーとの通信エラー」など、BroadWorksで統合IM&Pエラーが発生した場合は、次の考えられる原因を調査してください。

• ユーザーのメールアドレスはすでにCIになっている可能性があります。 ヘルプデスクでユーザーを検索して、そのユーザーのメールアドレスがすでにあるかどうかを確認してください。 ユーザーがヘルプデスクでデータを見ることを許可されていない組織に所属している可能性があるため、これは必ずしも決定的なものではありません。
• ユーザーは、統合IM&Pサービスに割り当てられる前に、独自にWebexにサインアップしました。 この場合の1つの選択肢は、ユーザーに無料アカウントを削除してもらい、プロビジョニングしている顧客組織の一員になることです。 手順は https://help.webex.com/5m4i4y にあります
• ユーザーのプロファイルにプライマリ電話番号が割り当てられていません（Cisco BroadWorks 向け Webex のすべてのサブスクライバーにはプライマリ DID が必要です）。 ASからのPSLogの分析に関するトピックを参照してください。

3。プロビジョニングブリッジからの応答によるユーザープロビジョニングの失敗

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

200 OK

200 OKの応答は、ユーザーが正常にプロビジョニングされたことを意味しません。これは、プロビジョニングサービスがリクエストを受け取り、対応するユーザー作成リクエストを上流のサービスに正常に送信したことを意味します。 プロビジョニングトランザクションは設計上非同期です。 ユーザー作成プロセスには数分かかる場合があり、パフォーマンス上の理由から、同じユーザーを作成するリクエストを複数受信したくないため、サービスは200 OKと応答します。 ただし、200 OKの応答があってもユーザーが最終的に顧客組織に表示されない場合は、プロビジョニングサービスの上流のWebexサービスでユーザー作成が失敗した可能性があります。 200 OKの応答があるプロビジョニング障害をエスカレートする必要があります。

400 不正なリクエスト

HTTPレスポンスをチェックしてください。 プロビジョニングサービスからのこのレスポンスの原因となる可能性のある問題の詳細が記載されているはずです。 ノードのいくつかの例：

• 「レガシープロビジョニングAPIではBroadWorksのメールは信頼できません。」 失敗したユーザープロビジョニングリクエストに関連するメールアドレスが有効でないか、入力ミスがありますが 、テンプレートでメールアドレスは信頼できると断言しています。 BroadWorksでユーザーのプロフィール、特にメールIDを確認してください。
• 顧客組織がデータベースに見つかりません。また、新しい組織作成フラグが有効になっていません。」 このプロビジョニングリクエストが失敗すると、 Webexに新しい顧客組織が作成されるはずですが、テンプレートは新しい顧客組織が作成されないように設定されています。 新しい組織や、Webex の既存の顧客と一致しないメールドメインを許可したい場合は、Partner Hub でテンプレートを再設定して、プロビジョニングリクエストを再テストできます。 ただし、 このユーザーのために新しい組織が作成される予定がない場合は、メールアドレス（特にドメインの部分）の入力が間違っている可能性があります。 BroadWorksでユーザーのメールIDを確認してください 。

403 禁じられています

プロビジョニングリクエストは、設定を修正するまで成功しません。 この場合、リクエストとレスポンスを調査する必要があります。 たとえば、プロビジョニングリクエストのターゲットとして、組織の適切なプロビジョニングブリッジURL（ソリューションガイドのファイアウォール設定のトピックを参照）の代わりにIPアドレスが表示される場合は、アプリケーションサーバーに必要なパッチが適用されていない可能性があります（ap373197）。

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

409 コンフリクト

リクエストのメールアドレスと一致する既存のユーザーがWebexにいるため、プロビジョニングリクエストを続行できません。

4。ユーザーはすでにCIに入っています

HTTP POSTリクエストから購読者のメールを取り出して、ヘルプデスクで検索してください。 許可されていない場合はユーザーが表示されないかもしれませんが、ユーザーが 「無料」の組織に所属していることもあります。 「消費者」。 このユーザーに無料アカウントを削除するように依頼することも、別のメールアドレスを使用してアカウントを設定することもできます。 https://help.webex.com/ndta402 を参照してください。

ユーザーのサインインに関する問題

1。ユーザーアクティベーションポータルが読み込まれません

Cisco BroadWorks用の通常のWebexのサインインフローには、ユーザーがパスワードを入力するユーザーアクティベーションポータルが含まれています。 ユーザーが Webex アプリのサインイン画面でメールアドレスを入力した後に、このポータルが読み込まれないことがあります。 この問題は、クライアント側またはサービス側で発生する可能性があります。 クライアント側では、通常、クライアントのネイティブブラウザが何らかの形でサービスと互換性がないことが原因です。

2。シングルサインオンが失敗しました

• BroadWorksで、ユーザーにWebexアプリのデバイスタイプが割り当てられていることを確認します（ソリューションガイドの「環境の準備」セクションの「デバイスプロファイル」セクションを参照してください）。
• ユーザーが正しいパスワードを使用していることを確認してください。 ユーザーの顧客組織（パートナーハブ） の準備に使用したテンプレートがBroadWorks認証用に設定されている場合、ユーザーはBroadWorksの「Web Access」パスワードを入力する必要があります。 メールアドレスが代替ユーザーIDとして設定されていない場合は、ユーザーはBroadWorksユーザーIDの入力も必要になることがあります。 ユーザーが大文字と小文字を正しく入力したことを確認してください。

通話設定と登録の問題

ユーザーがWebexでプロビジョニングされ、Webexアプリに正常にサインインすると、アプリはBroadWorksに登録されます。 以下は、予想される登録順序と、その結果生じる正常な登録の兆候です（Webexアプリから見ると）。

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

1. クライアントはXSIを呼び出して、デバイス管理トークンとDMSのURLを取得します。
2. クライアントは、手順1のトークンを提示して、DMSにデバイスプロファイルを要求します。
3. クライアントはデバイスプロファイルを読み取り、SIP認証情報、アドレス、ポートを取得します。
4. クライアントは、ステップ3の情報を使用してSBCにSIPレジスターを送信します。
5. SBCはSIPレジスターをASに送信します（SBCがSIPユーザーをまだ認識していない場合、SBCはNSでルックアップを実行してASを見つけることがあります）。

2。クライアント登録が成功すると予想される兆候

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

Webexアプリの電話サービスタブ（Windowsでは [設定] > [電話サービス]、Macでは [設定] > [電話サービス]）で、「SSOセッション：サインインしました」というメッセージは、アプリが（この場合はBroadWorksに）正常に登録されたことを意味します。

3。クライアントには通話アイコンがありません

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

これは登録の失敗です。 Webex アプリクライアントが BroadWorks への登録に失敗する理由は複数あります。

4。同じクライアントで複数の通話サービスをテスト中

この既知の問題は、クライアントが異なるコールバックエンドを切り替えることが原因である可能性があります。 これは、（同じ）Webexアプリクライアントを介して提供されるさまざまな通話サービスの試用中に発生する可能性が最も高いです。 この問題を解決するには、クライアントデータベース（リンク）をリセットできます。

5。認証サービスの設定ミス

認証サービスをホストしているXSPをソリューションガイドと照合してください（「Cisco BroadWorks XSP用のWebexでのサービスの設定」を参照）。 具体的には:

• RSAキー（1つのXSPで生成したもの）はすべてのXSPにコピーされます
• 認証サービスのURLは、すべてのXSPのWebコンテナに提供され、パートナーハブのクラスターに正しく入力されています
• 証明書による外部認証が設定されています：

  xsp_cli/システム/通信ユーティリティ/デフォルト設定/外部認証/証明書認証 > GET

  allowUserApp = false

  allowClientApp = true

• MTLSを使用するときは、Webexクライアント証明書をXSPにアップロードする必要があります（証明書はパートナーハブのBroadWorks設定ページから入手できます）。

6。ブロードワークスのタグの設定ミス

Webex アプリに必要な BroadWorks タグが設定されていることを確認してください。 コンフィグレーションタグについては、Webex for Cisco BroadWorks コンフィギュレーションガイドを参照してください。 矛盾や間違った値がないことを確認してください。 具体的には、%SBC_ADDRESS_WXT%タグは、WebexアプリクライアントのSIPレジストラへのSBCでなければなりません。

7。デスクトップクライアントは、SSO接続が成功すると電話サービスを切断します

この問題は、同じユーザーが同じプラットフォームタイプの複数のクライアントにサインインすることが原因である可能性があります。 たとえば、ユーザーが Windows 上の Webex アプリに正常にサインインし、別の Windows マシンで Webex アプリにサインインした場合、いずれかのマシンにはアクティブな SSO セッションしかありません。 これは設計によるものです。 どうしてもこの問題を回避する必要がある場合は、同じデバイスタイプの複数のインスタンスを持つようにBroadWorksを設定できますが、それらのインスタンスには固有のSIPアドレスが必要です。 この設定は、シスコブロードワークス向け Webex の範囲外です。

8。デスクトップデバイスはユーザー用にプロビジョニングされていません

この署名はクライアントログに表示されます：

[0x70000476b000] ブロードワークスコンフィグダウンローダー.cpp: 106 <Error>

OnAccessデバイスリストが成功しました：BWC：SCF：設定ダウンロード-デバイスプロファイル「ビジネスコミュニケーター-PC」が見つかりません。

9。インバウンドの携帯電話の着信は一度鳴るか、応答できません

Webex mobile へのインバウンドコールは 1 回だけ鳴ります。そうしないと、ユーザーはインバウンドコールに応答できません。 同じユーザーの他のエンドポイントからも呼び出し音が鳴り続ける可能性があります。

見分け方は？

Webexモバイルクライアントログで、プッシュコールフローのXSIエラーコード101002を探してください。 例えば:

レスポンスコード:400

<callID>ハンドルのプッシュコール情報失敗:BWC: 内部:プッシュコール:コール ID の XSI ステータス:xsi エラーコード:101002

<callID>理由のあるプッシュコールを閉じる：BWC：内部：ID =、理由 = コール放棄でプッシュコールを終了しようとしました

原因:エラーコード101002は、LocateUserの応答で間違ったアプリケーションサーバー（AS）が返されたことを示している可能性があります。 これは、ユーザーがセカンダリASに移行したときに発生する可能性があります。

おすすめのチェック:

プッシュがデプロイされているADPまたはXSPから、影響を受けるユーザーに対してLocateUserを実行してください。

<FQDN or IP address of NS Server>curl 'http: //:80/サーブレット/ロケートユーザー?<BW userID @domain >URL=&互換性のあるXSP=true&callPrequest=true'

例:curl 'http://1.1.1.1:80/servlet/LocateUser?url = 9721112222@gmail.com &returnCompatiblexsp=true&callPrequest=true'

解決策：LocateUserがユーザーのセカンダリASを返す場合は、プライマリNSサーバーでmigrateUserToDefaultNode.plスクリプトを実行して、ユーザーをクラスターのプライマリアプリケーションサーバーに戻します。

SSH経由でNSサーバーにログインし、/usr/local/broadworks/bw_base/binディレクトリに移動して、次のコマンドを実行します。migrateUserToDefaultNode.pl <hostingNE>

例:ユーザーをデフォルトノードに移行します。pl bwas1

ホスティングNEの値を取得するには、次のコマンドを実行してください：NS_CLI/システム/デバイス/ホスティングNE> get

このスクリプトはまず、引数として指定したホスティング NE を見つけることができるかどうかをチェックします。 ホスティングNEが有効であることを確認したら、DN、拡張子、URLをそのホスティングNEのデフォルトノードに更新します。

可能であれば、トラフィックが少ない時期にスクリプトを実行してください。 ただし、影響を受けるユーザーのサービスを回復する必要がある場合は、いつでもスクリプトを実行しても問題ありません。

このスクリプトは、1人のユーザーだけで実行することはできません。 LocateUser出力にリストされているすべてのユーザーを移行します。 スクリプトを実行できない場合は、影響を受けたユーザーを削除してBroadWorksで再構築し、ユーザーが正しいASで再構築されるようにします。

ユーザーデバイスからセカンダリASへのSIPメッセージがあると、ユーザーは移行する可能性があります。 受信リクエストが引き続きセカンダリASに到達しない限り、ユーザーは通常、デフォルトの15分間隔後にプライマリASにロールバックします。 たとえば、SBCがAS1に接続できず、セカンダリASに再接続した場合、影響を受けるユーザーはセカンダリASに移行する可能性があります。 導入環境によっては、SBCが引き続きプライマリASに到達できない場合でも、1つのトランクグループまたはユーザーをセカンダリASに接続したままにすることができます。

詳細については、次のドキュメントを参照してください。

• Cisco BroadWorks冗長ガイドのセクション3.4.5アプリケーションサーバーのユーザーロールバック機能および5.4.5自動ロールバック

• シスコブロードワークス ASR 拡張機能の説明

9。電話サービスが切断されました

ユーザーが Webex App にサインインした後に電話サービスが切断されたと表示される場合や、ユーザーがクライアントを使用しているときに電話サービスが切断された場合は、クライアントの種類と登録フローを確認してください。

WindowsおよびMacクライアントの場合、Webex アプリは SIP に登録し、ユーザーがサインインしている間もアクティブな SIP 登録を維持します。

以下を確認してください:

1. config-wxt.xml が正常にダウンロードされたことを確認してください。

クライアントログで、ConfigDownloadを検索してください。

ダウンロードが成功すると、以下が表示されます。

configダウンロード-正常に完了しました

ログに次のエラーが表示される場合は、AuthServiceのログでトークン関連のエラーを確認してください。

コンフィグダウンロード-エラーコード1511で失敗しました

2. Webex デバイスプロファイルが見つかったことを確認してください。

クライアントログで、アクセスデバイスが見つかり、used_valueが1であることを確認します。 used_valueが0の場合は、プライマリラインが有効か無効かを確認し、タグの値を確認してください。 詳細については、Webex for BroadWorks 設定ガイドのセクション 6.1.44 プライマリプロファイルを参照してください。

ログエントリの例:

: BWC: SCF: 設定ダウンロード-アクセスデバイスが見つかりました

: BWC: SCF: ダウンロード設定-アクセスデバイス:デバイスタイプ=ビジネスコミュニケーター-PC、デバイスレベル=グループ、許可終了=1、isDeviceOwner [has_value: 0、used_value: 1]、HA所有者デバイス:1、エンドポイントタイプ:共有コールアピアランス

: BWC: SCF: ダウンロードの設定-アクセスデバイス:デバイスタイプ=接続-モバイル、デバイスレベル=グループ、許可終了=1、isDeviceOwner [has_value: 0、used_value: 1]、haOwnerデバイス:1、エンドポイントタイプ:共有コールアピアランス

: BWC: SCF: ダウンロード設定-アクセスデバイス:デバイスタイプ=接続-タブレット、デバイスレベル=グループ、許可終了=1、isDeviceOwner [has_value: 0、used_value: 1]、ha所有者デバイス:1、エンドポイントタイプ:共有コールアピアランス

3. SIPプロキシアドレスを解決するときは、DNS障害をチェックしてください。

SIPプロキシ検出の詳細については、Webex for BroadWorks設定ガイドのセクション6.1.6の動的SIPプロキシ検出を参照してください。

プロキシ検出が成功すると、次のようになります。

プロキシ検出が終了し、<number>結果が出ました

4. SIP登録が失敗していないか確認してください。

ログにmRegistration: TCPTimeoutまたは理由:SIP; cause=200; text= "last=TCP-timeout」と表示されている場合、Webex クライアントは SBC への低レベル TCP 接続を確立できません。 このエラーが発生すると、SIP登録は完了しません。 ユーザーのネットワークでTCPがブロックされているかどうか、またはSBCがTCP接続を拒否していないかどうかを確認してください。

SIP REGISTERリクエストが拒否されたり、応答がなかったりした場合は、ログでREGISTER SIPを検索し、SIP/2.0 200 OKが返されることを確認してください。 返されない場合は、ユーザーのネットワークがSIPをブロックしているかどうか、またはSBCがリクエストを拒否していないかどうかを確認してください。

BroadWorks Adminで、ユーザ > ユーティリティ > 登録に進み、Webexクライアントに有効なSIP登録があることを確認します。

Android と iOS のモバイルクライアントの場合、Webex アプリは、電話がかけられるか受信されるまで SIP に登録されません。 通話が完了すると、登録は削除されます。 モバイルクライアントはプッシュ通知に登録します。

モバイルクライアントの場合は、以下を確認してください。

1. WindowsとMacのクライアントで説明されているように、config-wxt.xml が正常にダウンロードされ、デバイスプロファイルが見つかったことを確認してください。

2. プッシュ登録が成功したことを確認してください。

Webex ログで、プッシュ登録の状態を探してください。

onPush 登録状態が変更されました:: プッシュ登録状態が変更されました、state=未登録

onPush 登録状態が変更されました:: プッシュ登録状態が変更されました、state=登録済み

BroadWorks Adminで、ユーザー > ユーティリティ > プッシュ通知登録に進み、Webexクライアントに有効なプッシュ登録があることを確認します。

通話設定、ウェブビューの問題

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

この問題の別の症状は、ボタン/リンクが表示されているのに、 それをクリックすると外部ブラウザが開く場合です。

• 必要なクライアント設定テンプレートが導入され、 CSWタグが正しく設定されていることを確認してください。 （Cisco BroadWorks 向け Webex ソリューションガイドの「 通話設定ウェブビュー」セクションを参照してください）。
• WebexアプリがBroadWorksで通話できるように登録されていることを確認してください。
• Webex アプリが CSWV をサポートする最新バージョンであることを確認してください。

2。セルフケアボタン/リンクをクリックした後の空白ページまたはエラー

一般的に、Webex アプリでのこの動作は、BroadWorks XSP 上の CSWV アプリケーションの設定または導入に問題があることを示しています。 CSWVログ、アクセスログ、config-wxt.xml リポジトリ、テンプレートファイルなど、さらなる調査のために詳細を収集し、訴訟を提起してください。

ドメインクレームの問題

ユーザー登録エラーは、ドメインの申請で発生したエラーの結果として発生する可能性があります。 ドメインを申請する前に、次のことを理解していることを確認してください。

• サービスプロバイダーは、自分が管理する顧客組織のドメインを申請してはいけません。 サービスプロバイダーの内部組織に属するユーザーのドメインのみを申請する必要があります。 別の組織（サービスプロバイダーが管理している組織も含む）でユーザーのドメインを主張すると、ユーザー認証要求が顧客組織ではなくサービスプロバイダーを経由するため、 顧客組織のユーザーの登録エラーが発生する可能性があります。
• 2つの顧客組織（企業Aと企業B）が同じドメインを共有していて、 企業Aがドメインを申請した場合、 ユーザー認証要求はドメインを要求されている組織（企業A）を経由するため、企業Bのユーザーの登録が失敗する可能性があります。

  誤ってドメインを申請し、 申し立てを削除する必要がある場合は、ドメインの管理 Webexの記事を参照してください。

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

次の表は、 クライアントユーザーアクティベーションポータルに表示されるエンドユーザーのエラーコードの概要です。

ディレクトリ同期のエラーコード

次のエラーコードはディレクトリ同期に適用されます。