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

この記事は、自社および顧客をサポートするサービスプロバイダー組織のテクニカルサポートチームを対象としています。彼らは、一般的なトラブルシューティング、ログの読み取り、および加入者からの問い合わせ対応に精通している必要がある。

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

• リソース ― 必要なツール、参考資料、ログ、連絡先の一覧を提供します。
• プロセス ― 顧客の問題を解決する際に実行できるいくつかの手順について説明します。
• 具体的な問題点 ― 発生が確認されている問題点を分類して一覧表示し、それらを見つける方法、そして解決できる可能性のある方法について説明します。

役立つログファイル

読書リスト

• Webex for Cisco BroadWorks パートナーナレッジポータル
• XSPプラットフォーム構成ガイド（R23）
• BroadWorksソフトウェア管理ガイド（R23）
• Cisco BroadWorks デバイス管理設定ガイド（R23）
• Broadworks XSPコマンドラインインターフェイス管理ガイド
• 効力が長く続く認証トークン機能の説明リリース 23.0
• SAML認証統合ガイド、R23
• Cisco BroadWorks SSL サポートオプションガイド
• Cisco CI サポート機能の説明
• 通知プッシュサーバー（機能説明）
• コール機能の説明のプッシュ通知サポート リリース 22.0
• Connect (Android) から Firebase への移行方法の手順
• Cisco BroadWorks プッシュ通知用デバイストークンの保存機能の説明 リリース 22.0
• Cisco BroadWorksシステム容量プランナー（スプレッドシート）
• Cisco BroadWorksプラットフォームサイジングガイド
• Cisco Broadworksシステムエンジニアリングガイド
• CI 認証サポート要件ドキュメント バージョン 1.0 MR-7136

既知の問題と制限事項

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

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

Webex Serviceabilityサービスを利用することで、シスコの技術サポート担当者がインフラストラクチャの問題を診断する速度が向上します。診断ログや情報を検索、取得、保存し、SRケースに格納する作業を自動化します。また、診断署名に対して分析をトリガーするため、TAC がオンプレミス装置に関連する問題を効率的に識別して解決することができます。

Serviceabilityコネクタの展開方法の詳細については、 Cisco Webex Serviceabilityコネクタ展開ガイドを参照してください。

問題をエスカレートさせる

トラブルシューティングの手順をいくつか実行すれば、問題の原因がどこにあるのか、おおよそ見当がつくはずです。

操作手順

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

収集すべき顧客情報とは？

ケースを開くか、問題をエスカレーションする必要がある場合、ユーザーとのトラブルシューティング中に以下の情報を収集します。

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

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

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

操作手順

1. ヘルプデスクにサインインしてください。
2. ユーザーを検索してクリックします。これによりユーザー概要画面が開きます。
3. 詳細なユーザー構成を確認するために、ユーザー名をクリックします。このビューには、ユーザーのUUID、共通ID（CI）クラスタ、Webexアプリクラスタ、通話動作、BroadWorksアカウントGUIDなどの有用な情報が表示されます。
4. 別のツールでこの情報を使用する必要がある場合は、[コピー] をクリックするか、Cisco ケースにそれを添付します。

ヘルプデスクで顧客組織を表示する

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

操作手順

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

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

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

操作手順

1. ユーザーにログの送信を要求します。ヘルプについては次を参照してください。Webexアプリ | 問題を報告。
2. ユーザーに呼び出し環境をエクスポートして、 ced.dat ファイルを送ってもらうように依頼してください。
3. パートナーハブまたはヘルプデスクからクライアントログを入手してください。

   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. ユーザーにバージョン番号の送信を要求します。

通話サービスの顧客確認

操作手順

1. Webex クライアントにサインインします。
2. [Calling オプション] アイコン (上記の歯車のあるハンドセット) がサイドバーに表示されるかを確認します。アイコンが存在しない場合、ユーザーは Control Hub の通話サービスに対して有効に設定されていない可能性があります。
3. [設定/基本設定] メニューを開き、[電話サービス] セクションに進みます。[セッションにサインインSSO 状態] が表示されます。(Webex Calling などの異なる電話サービスが表示される場合、ユーザーは Cisco BroadWorks 版 Webex を使用していません)

   この確認の意味:

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

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

• 「リソース」セクションを参照して、Webex デスクトップ クライアントの特定のクライアント ログを見つけるか、ログを送信することをユーザーに尋ねください。ヘルプについては次を参照してください。Webexアプリ | 問題を報告。
• モバイルクライアントのユーザーにログの送信を依頼すれば、パートナーハブまたはヘルプデスクを通じてログを入手できます。
  ログの送信はサイレントです。ただし、ユーザーがフィードバックを送信する場合、フィードバックは Webex アプリ開発チームに送信されます。Cisco でフォローアップする場合は、ユーザーのフィードバック番号を必ず記録してください。例:

  

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

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

操作手順

1. クライアントで次のとおりクリックします。[Help (ヘルプ)] > [Health Checker (ヘルス チェッカ)]
2. [データベースのリセット] を選択します。これによりクライアントが完全にリセットされ、Webexアプリのログイン画面が表示されます。

WebexがBroadWorksに登録されていることを確認してください。

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

• broadworks-connectorに対するユーザーの権限。
• 組織およびユーザーに対する呼び出し動作。

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

1. パートナー管理者の認証情報を使用して、 ヘルプデスク にサインインしてください。
2. ユーザーを検索します。
3. ユーザーをクリックして、[Calling 動作] エントリを確認します。「Webex での Calling」である必要があります。

   

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

   

   Webex for Cisco BroadWorks のユーザーは、Webex for Cisco BroadWorks を使用する予定がある場合、 bc-sp-standard の権限を持つべきではありません。これは「Webex Calling (Broadcloud)」のライセンスであり、Ciscoが管理するクラウド通話サービスを介してWebexアプリから通話を行うものです。

組織の Calling 動作を確認する

1. パートナー管理者の認証情報を使用して、 ヘルプデスク にサインインしてください。
2. 組織を検索します。
3. 組織をクリックして、 呼び出し動作 のエントリを確認してください。「Webex での Calling」である必要があります。

ユーザープロビジョニングの問題については、PSLogを分析する。

アプリケーション サーバーの PSLog を使用して、プロビジョニング ブリッジへの HTTP POST 要求と Webex からの応答を確認します。正しい作業事例では、応答は 200 OK です。また、数分後にユーザーが表示され、最初のユーザーの場合は新しい顧客組織が Webex で作成されました。POST に表示されるメール アドレスのヘルプ デスクを検索して、これを確認できます。

始める前に

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

操作手順

1. まず、HTTPレスポンスコードを確認してください。
   • 200 OK 以外のものはすべて、ユーザー プロビジョニングの失敗です。
   • プロビジョニングブリッジより上流のWebexサービスで加入者プロファイルに何らかの問題がある場合、200 OKでもエラーを示している可能性があります。
   • 400番のレスポンスには message ノードが含まれる場合があります。プロビジョニングブリッジは subscriberProfile内の何かを処理できませんでした。サブスクライバーの詳細に問題がある、またはテンプレートの設定と非互換性がある場合があります。
   • 401 は AS に入力したプロビジョニング資格情報が Partner Hub のテンプレートに入力した資格情報と一致しないことを意味します。
   • 403 はアプリケーション サーバーに設定ミスがあることを示す場合があります。要求のターゲットを確認します。IP アドレスであってはなりません。Partner Hub のテンプレートに表示できるプロビジョニング ブリッジ URL である必要があります。
   • 409は、指定された subscriberProfile と既存のWebexデータとの間に競合があることを示します。そのメール アドレスを持つ既存のユーザーがいる可能性があります。レスポンス内の message を確認してください。
2. プロビジョニングが失敗する可能性がある疑わしい値について、元の HTTP POST を確認することもできます。POSTデータには subscriberProfile XML構造が含まれています。この中で確認する便利なノードは次のとおりです。
   • bwuserid: BroadWorks でサブスクライバ プロファイルを編集する必要がある場合は、これを使用してそれを見つけてください。
   • group: テンプレートが「サービスプロバイダーモード」の場合、これは小文字に変換され、パートナーハブに表示される顧客組織の名前になります。
   • serviceProvider: テンプレートが「エンタープライズ モード」の場合、小文字になり、Partner Hub に表示される顧客組織の名前になります。
   • primaryPhoneNumber: 存在する必要があります。それなしでは、プロビジョニングは失敗します。
   • email: Webex のユーザー ID になります。Webex に対して有効で一意である必要があります。そうしないとプロビジョニングに失敗します。

     services のスタンザは無視してください。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によって保護されています。

その後のディスカッションでは、正常なログインに対してログを調査するときに期待できる内容が説明されています。

ユーザーはクライアントと対話し、クライアントは Webex サービスと対話します。

• ユーザーはWebexアプリに自分のメールアドレスを入力します（図の1）。
• CI はこのユーザーをリダイレクトして、BroadWorks パスワード (UAP 経由) を入力することを知っています (図の 2)。
• IDP プロキシは XSP の Xsi インターフェイスにプロファイル取得リクエストを送信します。

トムキャットの中で 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 Basic 認証を行います (AuthenticationVerifyRequest および AuthenticationVerifyResponse、Xsi 経由で Basic 認証を行う他のアプリケーションと同様)。また、UserGetRequest および ServiceProviderGetRequest を使ってサブスクライバ情報を収集します。
• Xsi の Webex への応答には、(BroadWorks) userId およびその他の詳細を含む XML Profile ブロックが含まれています (図の 2.2)。

クライアントと Webex サービスの対話:

• IDPプロキシはBroadWorksから受信したユーザープロファイルと照合し、クライアントにSAMLアサーションを発行します（図の2.3）。
• クライアントはSAMLアサーションをCIトークン（図の3）と交換します。
• クライアントは、サインインしたユーザーが broadworks-connector エンタイトルメントを持っていることを確認します (図の 4)。ヘルプデスクでユーザーの権限を確認できます。
• クライアントは CI トークンを使用して、IDP プロキシ (図の 5) から JSON Web トークン (JWT) を要求します。
• 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 - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks … と StatusCode=200 からの応答 (図の 5.4) を探し、 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します。例：127.0.0.1:80 POST http://127.0.0.1:80/authService/token これは、 GET の [ trackingid: CLIENT… ヘッダーと [ POSTの X-BROADSOFT-CORRELATION-ID : CLIENT… ヘッダーに関連付けることができます。

authenticationService ログ:

• Xsi (ループバック) からの POST の受領

• A StatusCode=200 Xsiに戻る

• そしてトークン検証レスポンスには、本文に「token」JSONブロックが含まれます。

• 関連付けに使用するのは、 trackingid: CLIENT…

XsiActionsLog の場合:

• authserviceからクライアントのトークンを検証した200 OKを受け取った後、Xsi-ActionsアプリケーションはOCI-Pリクエストを送信します。 UserPrimaryAndSCADeviceGetListRequest
• accessDeviceTable XML構造を含むOCI-P UserPrimaryAndSCADeviceGetListResponse を受信します。
• OCI-P レスポンスは、クライアントへの Xsi レスポンスとしてエンコードされ、 AccessDevices XML 構造を含み、 deviceTypesが含まれます。例: Business Communicator – PC および、クライアントがデバイス構成ファイルを取得する URL があります。

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

• デバイスエントリを選択し、DMSと連携してデバイスプロファイルを取得します（図の6）。
• DMSから構成情報として取得されたレジスタをSBC経由でBroadWorksに送信します（図中の7）。

パートナーハブの問題

1. 管理者は顧客組織を表示できません

Webex のパートナー組織の管理者として、 フル管理者ロールを持っている必要があります。このロールは、自分自身や他のユーザーに管理者権限を割り当てるなど、パートナー組織の管理に使用されます。顧客組織を管理するには、自分自身（または他のユーザー）に Sales Full Administrator ロールまたは Sales Administrator ロールを付与する必要があります。詳細については、 コントロールハブで組織アカウントの役割を割り当てるを参照してください。

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

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エラー

これは、フロー スルー プロビジョニングを使用している場合に適用され、プロビジョニングが機能していることを前提としています。 some/most ユーザー（設定の問題ではないことを確認するため）。統合IMが表示されている場合 & BroadWorksにおけるPエラー、例えば、 “[Error 18215] メッセージングサーバーでのプロビジョニングエラー」 “[Error [18211] メッセージングサーバーとの通信エラー」が発生した場合は、以下の潜在的な原因を調査する必要があります。

• ユーザーのメールアドレスはすでに CI が存在している可能性があります。ヘルプデスクでユーザーを検索し、メールアドレスが既に登録されているかどうかを確認してください。これは必ずしも決定的な証拠とは言えません。なぜなら、ユーザーが所属する組織によっては、ヘルプデスクでその組織のデータを見る権限がない場合があるからです。
• 統合型 IM&P サービスが割り当てられる前に、ユーザーは Webex に個別にサインアップします。この場合、一つの選択肢として、ユーザーに無料アカウントを削除してもらい、そのアカウントをプロビジョニング中の顧客組織に追加してもらう方法があります。手順は https://help.webex.com/5m4i4y
• ユーザーのプロファイルに主要な電話番号が割り当てられていません（Webex for Cisco BroadWorksのすべての加入者は、主要なDID番号を持っている必要があります）。「AS から PSLog を分析する」を参照してください。

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

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

200 OK

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

400 Bad 要求

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

• 「レガシー プロビジョニング API による BroadWorks メールを信頼できません。」失敗したユーザーのプロビジョニング要求に関連付けられたメール アドレスは有効ではないか、入力ミスですが、メール アドレスが信頼できることをテンプレートで確認しました。BroadWorks でユーザーのプロファイル、特にメール ID を確認します。
• 顧客組織がデータベースに見つかりません。また、新規組織作成フラグも有効になっていません。この失敗したプロビジョニング要求は、Webex で新しい顧客組織を作成する必要がありますが、テンプレートが新しいカスタマー組織が作成されるのを防ぐために構成されています。新しい組織を、Webex の既存の顧客と一致しないメール ドメインに対して許可する場合は、Partner Hub でテンプレートを再構成し、プロビジョニング要求を再テストできます。しかし、このユーザーに対して新しい組織が作成されないことが予想される場合、おそらくメール アドレスに入力ミスがあると想定されます (特にドメイン部分)。BroadWorks で、ユーザーのメール ID を確認します。

403 Forbidden

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

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

409 Conflict

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

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

HTTP POST 要求からサブスクライバー メールを取得し、それをヘルプ デスクで検索します。許可されていない場合はユーザーを見ることができないかもしれませんが、ユーザーが「無料」組織 (例:「消費者」) に所属しているのも見える場合があります。このユーザーに無料アカウントの削除を求めるか、別のメールアドレスを使用してプロビジョンすることができます。https://help.webex.com/ndta402 を参照してください。

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

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

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

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

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

呼び出し設定と登録の問題

ユーザーがWebexでプロビジョニングされ、Webexアプリに正常にサインインすると、アプリはBroadWorksに登録されます。以下は、想定される登録手順と、Webexアプリで確認できる正常な登録の兆候です。

1. 想定される登録シーケンス

1. クライアントは XSI に発信し、デバイス管理トークンと DMS への URL を取得します。
2. クライアントはステップ 1 からトークンを提示することで、DMS からそのデバイス プロファイルを要求します。
3. クライアントはデバイス プロファイルを読み取り、SIP 資格情報、アドレス、およびポートを取得します。
4. クライアントはステップ 3 からの情報を使用して SIP REGISTER を SBC に送信します。
5. SBCはSIP REGISTERをASに送信します（SBCがSIPユーザーを既に認識していない場合、SBCはNSを検索してASを特定する場合があります）。

2. 顧客登録が成功したことを示す兆候

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

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

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

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

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

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

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

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

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

• RSA 鍵 (1 つの XSP で生成された) がすべての XSP にコピーされます
• 認証サービス URL がすべての XSP のウェブ コンテナに提供され、Partner Hub のクラスターに正しく入力されました
• 証明書による外部認証は次のように設定されます。

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>get

  allowUserApp = false

  allowClientApp = true

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

6. BroadWorks タグの構成ミス

Webexアプリに必要なBroadWorksタグが正しく設定されていることを確認してください。設定タグに関する情報については、 Webex for Cisco BroadWorks 設定ガイド を参照してください。競合や誤った値がないことを確認してください。具体的には、 %SBC_ADDRESS_WXT% タグは Webex アプリ クライアント用の SIP レジストラへの SBC である必要があります。

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

この問題は、同じプラットフォーム タイプで同じユーザーが複数のクライアントにサインインすると発生する可能性があります。例えば、ユーザーがWindows上のWebexアプリに正常にサインインした後、別のWindowsマシン上のWebexアプリにサインインした場合、アクティブなSSOセッションはどちらか一方のマシンにのみ存在します。これは仕様です。絶対にこの問題を回避する必要がある場合は、BroadWorks に同じデバイス タイプの複数のインスタンスを構成することができますが、固有の SIP アドレスを持つ必要があります。この構成は Cisco BroadWorks 版 Webex の範囲外です。

8. ユーザー向けにデスクトップデバイスがプロビジョニングされていません

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

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - the device profile 'Business Communicator - PC' is not found.

9. 着信した携帯電話の通話は1回だけ鳴るか、応答できない。

Webexモバイルへの着信は1回しか鳴らないか、ユーザーが着信に応答できません。同じユーザーの他の端末では、引き続き着信音が鳴る場合があります。

どのように識別するか？

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

応答コード: 400

handlePushCallInfoFailure:BWC:INTERNAL: プッシュコール: callIDのxsiステータス:<callID> xsiエラーコード: 101002

closePushCallWithReason:BWC:INTERNAL: IDを使用してプッシュコールを閉じようとします = <callID>、 理由 = 通話放棄

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

推奨されるチェック項目：

Pushが展開されているADPまたはXSPから、影響を受けるユーザーに対して LocateUser を実行します。

curl 'http://:80/servlet/LocateUser?url=&returnCompatibleXSP=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

例: migrateUserToDefaultNode.pl bwas1

hostingNE の値を取得するには、以下を実行します。 NS_CLI/System/Device/HostingNE> get

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

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

このスクリプトは、単一ユーザーのみで実行することはできません。これは、 LocateUser 出力にリストされているすべてのユーザーを移行します。スクリプトを実行できない場合は、BroadWorksで該当ユーザーを削除して再構築し、正しいAS上にユーザーが再構築されるようにしてください。

ユーザーデバイスからセカンダリASへのSIPメッセージは、ユーザーの移行を引き起こす可能性があります。受信リクエストがセカンダリASに到達し続けない限り、ユーザーは通常、デフォルトの15分間隔後にプライマリASにロールバックします。例えば、SBCがAS1に接続できず、セカンダリASに再接続した場合、影響を受けるユーザーはセカンダリASに切り替わる可能性があります。展開方法によっては、SBCがプライマリASへの接続に問題を抱え続ける場合、単一のトランクグループまたはユーザーがセカンダリASに固定されたままになることがあります。

詳細については、以下の文書を参照してください。

• Cisco BroadWorks冗長化ガイドのセクション3.4.5 アプリケーションサーバのユーザーロールバック機能および5.4.5 自動ロールバックを参照してください。

• Cisco BroadWorks ASRの機能強化に関する説明

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

1. 自己治療 button/link Webexアプリに表示されない

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

• 必要なクライアント構成テンプレートがデプロイされ、CSWタグが正しく設定されていることを確認してください。（Webex for Cisco BroadWorks ソリューションガイドの 通話設定 Webview セクションを参照してください。）
• BroadWorksでWebexアプリが通話用に登録されていることを確認してください。
• WebexアプリがCSWVをサポートする最新バージョンであることを確認してください。

2. 「セルフケア」をクリックした後に空白ページが表示されるか、エラーが発生します。 button/link

一般的に、Webexアプリにおけるこの動作は、BroadWorks XSP上のCSWVアプリケーションの設定または展開に関する問題を示しています。CSWV ログ、アクセス ログ、config-wxt.xml レポジトリ、テンプレート ファイルなど、さらに調査の詳細を収集し、ケースを発生させます。

ドメインクレームの問題

ドメインの主張で発生したエラーの結果として、ユーザー登録エラーが発生する可能性があります。ドメインを主張する前に、必ず以下を理解してください。

• サービス プロバイダーは、管理している顧客組織のドメインを主張しないでください。サービス プロバイダーは、サービス プロバイダーの内部組織に所属するユーザーのドメインのみを主張してください。別の組織のユーザーのドメインを主張すると、たとえサービス プロバイダーが管理している組織であっても、顧客組織のユーザーに登録エラーが生じることがあります。なぜなら、ユーザー認証リクエストが顧客組織ではなくサービス プロバイダーを経由してルーティングされることがあるからです。
• 2 つの顧客組織 (会社 A と会社 B) が同じドメインを共有し、会社 A がドメインを主張している場合、ユーザー認証リクエストは当該ドメインを主張した組織 (会社 A) を経由してルーティングされるため、会社 B のユーザーの登録は失敗する可能性があります。

  エラーのあるドメインを主張し、主張を削除する必要がある場合、「ドメインの管理」の Webex 記事を参照してください。

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

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

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

ディレクトリ同期には次のエラー コードがあります。