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

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

便利なログファイル

読書リスト

• Cisco BroadWorks 向け Webex パートナー ナレッジ ポータル
• 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 サービスは、Cisco テクニカル サポート スタッフがインフラストラクチャの問題を診断する速度を向上させます。診断ログと情報を SR ケースで検索、取得、保存するタスクを自動化します。また、診断署名に対して分析をトリガーするため、TAC がオンプレミス装置に関連する問題を効率的に識別して解決することができます。

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

問題のエスカレーション

トラブルシューティングのガイダンスの一部に従った後で、問題がどこにルートされているのか妥当なアイデアを持っている必要があります。

操作手順

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

収集するクライアント情報

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

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

ヘルプデスクでユーザーの詳細を確認する

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

操作手順

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

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

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

操作手順

1. ヘルプデスクにサインインします。
2. 顧客の組織名を検索してクリックします。
3. Customer Portal View が表示されるまで下にスクロールし、 View CustomerName をクリックして、ユーザーと構成を含む顧客組織の読み取り専用ビューを表示します。

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

デスクトップおよびモバイル クライアントの問題をトラブルシューティングする場合、パートナー (および 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 Web トークンが発行されます。
   • クライアントはデバイス プロファイルを取得し、BroadWorks に登録しました。

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

• 「リソース」セクションを参照して、Webex デスクトップ クライアントの特定のクライアント ログを見つけるか、ログを送信することをユーザーに尋ねください。ヘルプについては次を参照してください。Webex アプリ | 問題を報告する.
• モバイル クライアントのユーザーにログの送信を要求してから、Partner Hub またはヘルプ デスクからログを取得できます。
  ログの送信はサイレントです。ただし、ユーザーがフィードバックを送信する場合、フィードバックは 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 、権限を付与しないでください。これは、Cisco が管理するクラウド コーリング サービスを通じた Webex アプリ コーリングである「Webex Calling (Broadcloud)」のエンタイトルメントです。

組織の 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 インターフェイスにプロファイル取得リクエストを送信します。

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 ヘッダーには authorization: Basic と user-agent: broadworksTeamsClientが含まれます

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

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

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

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 の受領

• Xsiに戻る StatusCode=200

• トークン検証応答には、本体に「token」JSON ブロックが含まれます。

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

XsiActionsLog の場合:

• 認証サービスから200 OKを受信し、クライアントのトークンが検証された後、Xsi-ActionsアプリケーションはOCI-Pリクエストを送信します。 UserPrimaryAndSCADeviceGetListRequest
• accessDeviceTable XML構造を含むOCI-P UserPrimaryAndSCADeviceGetListResponse を受け取ります。
• OCI-P 応答は、 deviceTypesを持つ AccessDevices XML 構造を含む、クライアントへの Xsi 応答としてエンコードされます。たとえば、次のようなものです。Business Communicator – PC および、クライアントがデバイス構成ファイルを取得する URL があります。

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

• デバイス エントリを選択し、DMS と対話してデバイス プロファイルを取得します (図の 6)。
• DMS から構成で取得された SBC 経由で BroadWorks に登録します (図の 7)。

パートナーハブの問題

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

Webex のパートナー組織の管理者には、 完全な管理者ロールが必要です。このロールは、自分自身や他のユーザーに管理者権限を割り当てるなど、パートナー組織の管理に使用されます。顧客組織を管理するには、自分自身 (または他の人) に Sales Full Administrator ロールまたは Sales Administrator ロールを付与する必要があります。詳細については、 Control Hub で組織アカウントのロールを割り当てるを参照してください。

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

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

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

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

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

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

これは、フロースルー プロビジョニングを使用し、一部/ほとんどのユーザーに対してプロビジョニングが動作すると想定する場合に適用されます (これにより、構成の問題を排除できます)。たとえば「メッセージング サーバーの [エラー 18215] プロビジョニング エラー」や「[エラー 18211] メッセージング サーバーとの通信エラー」など、BroadWorks で統合型 IM&P エラーが発生する場合、次の潜在的な原因を調査する必要があります。

• ユーザーのメールアドレスはすでに CI が存在している可能性があります。ヘルプ デスク内のユーザーを検索して、メールアドレスがすでに存在するかどうかを確認します。これは必ずしも簡潔な話ではありません。ユーザーは、ヘルプ デスクで閲覧することを許可されていないデータをもつ組織に存在している可能性があります。
• 統合型 IM&P サービスが割り当てられる前に、ユーザーは Webex に個別にサインアップします。この場合、ユーザーに無料アカウントを削除してもらい、プロビジョニングしている顧客組織の一員になれるようにするという選択肢もあります。手順は https://help.webex.com/5m4i4y
• ユーザーのプロファイルにプライマリ電話番号が割り当てられていません (Cisco 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 応答を確認します。 ノードのいくつかの例:

• 「レガシー プロビジョニング 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 を参照してください。

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

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

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

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

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

通話設定と登録の問題

ユーザーが 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 は NS で検索を実行して AS を検索することがあります)。

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

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

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

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

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

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

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

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

認証サービスの設定ミス

認証サービスをホストする 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 にアップロードする必要があります (証明書は、Partner Hub の BroadWorks 設定ページから取得できます)。

BroadWorks タグの構成ミス

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

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

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

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

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

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

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

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

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

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

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

セルフケアをクリックした後に空白ページまたはエラーが表示される button/link

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

ドメインクレームの問題

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

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

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

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

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

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

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