環境の準備
意思決定ポイント
考慮事項 | 質問と回答 | リソース |
アーキテクチャとインフラストラクチャ |
XSP の数は? mTLS の使用法は? |
Cisco BroadWorks システム容量プランナ Cisco BroadWorks System Engineering Guide (Cisco BroadWorks システム エンジニアリング ガイド) XSP CLI リファレンス このドキュメント |
顧客とユーザーのプロビジョニング | BroadWorks のメールは信頼できると言い切れますか? ユーザーがアカウントをアクティベートするとき、メール アドレスの入力を要求しますか? Cisco の API を使用するツールを構築できますか? |
公開 API ドキュメント。公開場所: https://developer.webex.com このドキュメント |
ブランディング | 使用する色とロゴは? | Webex アプリのブランディング記事 |
テンプレート | その他の顧客の使用事例は? | このドキュメント |
顧客、エンタープライズ、グループごとのサブスクライバ機能 | テンプレートごとにサービス レベルを定義するパッケージを選択します。 [Basic (ベーシック)]、[Standard (標準)]、[Premium (プレミアム)]、または[Softphone (ソフトフォン)]。 | このドキュメント 機能とパッケージの一覧 |
ユーザー認証 | BroadWorks または Webex | このドキュメント |
プロビジョニング アダプタ (フロースルー プロビジョニング オプション) | UC-One SaaS など、統合型 IM&P をすでに使用していますか? 複数のテンプレートを使用しますか? より一般的な使用事例が予想されていますか? |
このドキュメント アプリケーション サーバー CLI リファレンス |
アーキテクチャとインフラストラクチャ
想定している開始当初のスケールは? 将来スケールアップは可能ですが、現在の使用量見積もりに沿ってインフラストラクチャ計画を推進する必要があります。
担当の Cisco アカウント マネージャーまたは営業担当者と共同で、Cisco BroadWorks システム容量プランナーおよび『Cisco BroadWorks システム エンジニアリング ガイド』に沿って XSP インフラストラクチャの規模を判断します。
Webex から XSP への相互 TLS 接続の方法は? DMZ の XSP に直接、または TLS プロキシを経由しますか? これは証明書の管理とインターフェイス用 URL に影響します。 (ネットワーク エッジへの非暗号化 TCP 接続はサポート対象外)。
顧客とユーザーのプロビジョニング
最適なユーザープロビジョニング方法は?
信頼済みメールによるフロースルー プロビジョニング: BroadWorks で「統合型 IM&P」サービスを割り当てると、Webex でサブスクライバーのプロビジョニングが自動で実行されます。
BroadWorks のサブスクライバ メール アドレスが有効であり、Webex で重複することはないと断定できる場合は、フロースルー プロビジョニングの「trusted email (信頼済みメール)」のオプションを選択できます。 サブスクライバの Webex アカウントは、サブスクライバの操作は一切交えずに作成され、アクティベートされます。サブスクライバはクライアントをダウンロードしてサインインするだけです。
メール アドレスは Webex の重要なユーザー属性です。 したがって、Webex サービスのプロビジョニングを行う場合、サービス プロバイダはユーザーに有効なメール アドレスを提供する必要があります。 これを BroadWorks でのユーザーのメール ID 属性に組み込む必要があります。 代替 ID 属性にもコピーすることをお勧めします。
信頼済みメールなしでのフロースルー プロビジョニング: サブスクライバのメール アドレスを信頼できない場合でも、BroadWorks で統合型 IM&P サービスを割り当てると、Webex のユーザーをプロビジョニングできます。
この選択肢では、パートナー様がサービスを割り当てるとアカウントが作成されますが、サブスクライバが Webex アカウントをアクティベートするには、各自のメール アドレスを入力し、検証を受ける必要があります。
ユーザー セルフプロビジョニング: この選択肢では BroadWorks での IM&P サービスの割り当てが必要ありません。 代わりにパートナー様 (またはパートナー様の顧客) からプロビジョニング リンク、別々のクライアントをダウンロードするリンク、ブランディング、手順を配布します。
サブスクライバはリンクに従い、メール アドレスを入力して検証を受け、自身の Webex アカウントを作成してアクティベートします。 続いてクライアントをダウンロードしてサインインすると、Webex がサブスクライバに関する追加設定 (プライマリ番号など) を BroadWorks からフェッチします。
API による SP 管理プロビジョニング: Webex は、サービス プロバイダーが既存のワークフローにユーザーやサブスクライバーのプロビジョニングを構築できるように公開 API 一式を公開します。
プロビジョニングの要件
次の表は、各プロビジョニング方法の要件をまとめたものです。 これらの要件に加えて、展開はこのガイドで説明されている一般的なシステム要件を満たしている必要があります。
プロビジョニング方法 |
要件 |
---|---|
フロースルー プロビジョニング (信頼済みまたは信頼されていないメール) |
ユーザーが要件を満たし、統合型 IM+P サービスをオンに切り替えたら、Webex プロビジョニング API により、既存の BroadWorks ユーザーが Webex に自動的に追加されます。 Webex の顧客テンプレート経由で割り当てる 2 つのフロー (信頼されたメールまたは信頼されていないメール) があります。 BroadWorks の要件:
Webex の要件: 顧客テンプレートには、次の設定が含まれます。
|
ユーザー セルフプロビジョニング |
管理者は、既存の BroadWorks ユーザーに、ユーザー アクティベーション ポータルへのリンクを提供します。 ユーザーは、BroadWorks の資格情報を使用してポータルにログインし、有効なメール アドレスを入力する必要があります。 メールが検証された後、Webex は追加のユーザー情報を取得してプロビジョニングを完了します。 BroadWorks の要件:
Webex の要件: 顧客テンプレートには、次の設定が含まれます。
|
API 経由の SP 制御プロビジョニング (信頼済みまたは信頼されていないメール) |
Webex は、既存のワークフローとツールにユーザーのプロビジョニングを構築できる一連のパブリック API を公開します。 2つの流れがあります。
BroadWorks の要件:
Webex の要件:
API を使用するには、[BroadWorks サブスクライバ] に移動します。 |
フロースルー プロビジョニングで必要なパッチ
フロースルー プロビジョニングを使用している場合、システム パッチをインストールし、CLI プロパティを適用する必要があります。 BroadWorks のリリースに適用される手順については以下のリストを参照してください。
R22 の場合:
インストール後にプロパティ
bw.msg.includeIsEnterpriseInOSSschema
~true
に [Maintenance/ContainerOptions] の CLI で設定します。詳細については、パッチ ノート https://www.cisco.com/web/software/286326332/154309/AP.as.22.0.1123.ap376508.txt を参照してください。
R23 の場合:
インストール後にプロパティ
bw.msg.includeIsEnterpriseInOSSschema
~true
に [Maintenance/ContainerOptions] の CLI で設定します。詳細については、パッチ ノート https://www.cisco.com/web/software/286326332/154325/AP.as.23.0.1075.ap376509.txt を参照してください。
R24 の場合:
インストール後にプロパティ
bw.msg.includeIsEnterpriseInOSSschema
~true
に [Maintenance/ContainerOptions] の CLI で設定します。詳細については、パッチ ノート https://www.cisco.com/web/software/286326332/154326/AP.as.24.0.944.ap375100.txt を参照してください。
これらの手順を完了すると、UC-One Collaborate サービスで新規ユーザーをプロビジョニングできなくなります。 新しくプロビジョニングされるユーザーは、Cisco BroadWorks 版 Webex のユーザーである必要があります。
|
サポートされている言語ロケール
プロビジョニング中に、BroadWorks で最初にプロビジョニングされた管理ユーザーに割り当てられた言語が、その顧客組織のデフォルトロケールとして自動的に割り当てられます。 この設定は、顧客組織のアクティベーション メール、ミーティング、ミーティングの招待状に使用されるデフォルトの言語を決定します。
(ISO-639-1)_(ISO-3166)形式の5文字言語ロケールがサポートされています。 たとえば、en_USはnglish_E UnitedStatesに相当します。 2 文字の言語のみを要求する場合(ISO-639-1 形式を使用)、サービスは、要求された言語とテンプレートの国コード(「requestedLanguage_CountryCode」)を組み合わせて 5 文字の言語ロケールを生成します。有効なロケールを取得できない場合、必要な言語コードに基づいて使用されるデフォルトの賢明なロケールです。
次の表に、サポートされているロケールと、2 文字の言語コードを 5 文字のロケールに変換するマッピングを示します。
サポートされている言語ロケール (ISO-639-1)_(ISO-3166) |
2文字の言語コードしか使用できない場合... |
|
---|---|---|
言語コード (ISO-639-1) ** |
代わりにデフォルトの Sensible Locale を使用する (ISO-639-1)_(ISO-3166) |
|
en_米国 en_AU en_ GB en_CA |
はあ? |
en_米国 |
fr_FR fr_CA |
FR |
fr_FR |
cs_CZシリーズ |
CSについて |
cs_CZシリーズ |
da_デンマーク |
ああ... |
da_デンマーク |
de_DE |
DE |
de_DE |
hu_ハンガリー |
フン |
hu_ハンガリー |
id_ID |
id |
id_ID |
it_IT |
それ |
it_IT |
ja_JP |
「JA」 |
ja_JP |
ko_KR |
KO |
ko_KR |
es_ES es_コラボレーション es_MXについて |
ES |
es_ES |
nl_NL |
NL |
nl_NL |
nb_いいえ |
メモ |
nb_いいえ |
pl_PLについて |
PLについて |
pl_PLについて |
pt_PT pt_BR |
pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/pt/ |
pt_PT |
ru_RU |
RU |
ru_RU |
ro_RO |
ロロ |
ro_RO |
zh_CN zh_台湾 |
ズー |
zh_CN |
sv_南アメリカ |
sv |
sv_南アメリカ |
ar_南アフリカ |
アール |
ar_南アフリカ |
tr_TR |
トライ |
tr_TR |
ロケール es_CO、id_ID、nb_NO、pt_PT は Webex ミーティングサイトではサポートされていません。 これらのロケールでは、Webex Meetings サイトは英語のみになります。 サイトに no/invalid/unsupported ロケールが必要な場合、英語がサイトのデフォルト ロケールです。 この言語フィールドは、組織と Webex Meetings サイトの作成時に適用されます。 投稿またはサブスクライバの API に言語が記載されていない場合、テンプレートからの言語がデフォルトの言語として使用されます。 |
ブランディング
パートナー管理者は高度なブランディングのカスタマイズを使用して、 Webexアプリがパートナーが管理する顧客組織を検索する方法をカスタマイズます。 パートナーの管理者は次の設定をカスタマイズして、 Webexアプリに会社のブランドとアイデンティティを反映させることができます。
企業ロゴ
ライト モードまたはダーク モードに対応する独自のカラー スキーム
カスタマイズされたサポート URL
ブランディングのカスタマイズ方法の詳細については、「高度なブランディングのカスタマイズの設定」を参照してください。
|
カスタマー テンプレート
カスタマー テンプレートを使用すると、Cisco BroadWorks 版 Webex で顧客や関連するサブスクライバーが自動的にプロビジョニングされるパラメータを定義できます。 必要に応じて複数のカスタマー テンプレートを設定できますが、顧客が登録時に関連付けられるテンプレートは 1 つだけです (同じ顧客に複数のテンプレートを適用することはできません)。
以下は主なテンプレート パラメータの例です。
パッケージ
テンプレートを作成するときは、デフォルトのパッケージを選ぶ必要があります (詳しくは「概要」セクションの「パッケージ」を参照してください)。 フロースルーまたはセルフ プロビジョニングを通じてテンプレートでのプロビジョニングが終わったユーザーはすべて、デフォルトのパッケージを受け取ります。
複数のテンプレートを作成し、テンプレートごとに異なる内容のデフォルト パッケージを選ぶことで、各顧客に適したパッケージ選択を管理できます。 その結果、選んだテンプレートに対応するユーザー プロビジョニング方法に応じて、配布するプロビジョニング リンクを変えたり、エンタープライズ別のプロビジョニング アダプタを配布したりできます。
特定のサブスクライバーのパッケージをこのデフォルトから変更するには、プロビジョニング API (Webex for Cisco BroadWorks API のドキュメント を参照) または Partner Hub (「Partner Hub のユーザー パッケージを変更する」を参照) を使用します。
BroadWorks からはサブスクライバのパッケージを変更できません。 統合型 IM&P サービスの割り当てはオンかオフのどちらかです。サブスクライバが BroadWorks でこのサービスに割り当てられている場合、そのサブスクライバの企業のプロビジョニング URL に関連付けられているパートナー ハブのテンプレートでパッケージが決まります。
再販業者とエンタープライズ、またはサービス プロバイダとグループですか?
BroadWorks システムの設定方法は、フロースルー プロビジョニングに影響を与えます。 エンタープライズとリセラーの場合、テンプレートを作成するとき [Enterprise (エンタープライズ)] モードを有効にする必要があります。
BroadWorks システムが [Service Provider (サービス プロバイダ)] モードで設定されている場合、テンプレートで [Enterprise (エンタープライズ)] モードのスイッチをオフにしておきます。
BroadWorks の両モードを使用して顧客の組織をプロビジョニングする予定がある場合は、グループとエンタープライズに異なるテンプレートを割り当てる必要があります。
フロースルー プロビジョニングに必要な BroadWorks パッチが適用されていることを確認してください。 詳細については、「フロースルー プロビジョニングに必要なパッチ」を参照してください。
|
認証モード
Webex にログインするときに、サブスクライバが認証する方法を決定します。 このモードは、顧客テンプレートの認証モード設定を使用して割り当てることができます。 次の表に、いくつかのオプションの概要を示します。
この設定は、ユーザー アクティベーション ポータルへのログインには影響しません。 ポータルにサインインするユーザーは、顧客テンプレートの認証モードの設定方法に関係なく、BroadWorksで設定されたBroadWorksユーザーIDとパスワードを入力する必要があります。
|
認証モード | BroadWorks | Webex |
プライマリ ユーザー ID | BroadWorks ユーザー ID | メール アドレス |
ID プロバイダ | BroadWorks。
|
Cisco Common Identity |
多要素認証を使用しますか? | いいえ | 多要素認証をサポートする IdP を顧客に義務付けます。 |
資格情報の確認パス |
|
|
BroadWorks への直接認証による SSO ログイン フローの詳細については、「SSO ログイン フロー」を参照してください。
|
BroadWorks 認証による UTF-8 エンコーディング
BroadWorks 認証では、認証ヘッダーに UTF-8 エンコーディングを設定することをお勧めします。 UTF-8は、Webブラウザが文字を適切にエンコードしない特殊文字を使用するパスワードで発生する問題を解決します。 UTF-8 エンコードを使用して、base 64 エンコードされたヘッダーがこの問題を解決します。
XSP または ADP で次の CLI コマンドのいずれかを実行して、UTF-8 エンコーディングを設定できます。
XSP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
ADP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
国
テンプレートを作成するときは、国を選択する必要があります。 この国は、共通 ID のテンプレートでプロビジョニングされたすべての顧客の組織国として自動的に割り当てられます。 さらに、組織国は Webex Meeting サイトの Cisco PSTN のデフォルトの国際コールイン番号を決定します。
サイトのデフォルトのグローバル コールイン番号は、組織の国に基づいてテレフォニー ドメインで定義された最初の利用可能なダイヤルイン番号に設定されます。 テレフォニー ドメインで定義されたダイヤルイン番号に組織の国が見つからない場合、そのロケーションのデフォルト番号が使用されます。
いいえ。 |
場所 |
国番号 |
国名 |
---|---|---|---|
1 |
アメリカ |
+1 |
私達のCA |
2 |
アジアパシフィック |
+65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 +65 |
シンガポール |
3 |
オーストラリア、ニュージーランド |
+61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) +61 (+61) |
オーストラリア |
4 |
欧州、中東、アフリカ |
+44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) +44 (+44) |
イギリス |
5 |
ユーロ |
+49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) +49 (+49) |
ドイツ |
複数のパートナーの設定
別のサービス プロバイダーに Cisco BroadWorks 版 Webex のサブライセンスを行いますか? その場合、各サービス プロバイダがそれぞれの顧客基盤でこのソリューションのプロビジョニングを行うには、Webex Control Hub に異なるパートナー組織として登録する必要があります。
プロビジョニング アダプタとテンプレート
フロースルー プロビジョニングでは、BroadWorks に入力したプロビジョニング URL は Control Hub のテンプレートに基づいて提供されます。 複数のテンプレートを設定できるため、結果的にプロビジョニング URL も複数になることがあります。 この方法では、エンタープライズごとに、サブスクライバに統合 IM&P サービスを付与するタイミングで、サブスクライバに適用するパッケージを選択できます。
システム レベルのプロビジョニング URL をデフォルトのプロビジョニング パスに設定するかどうか、またその設定にどのテンプレートを使用するかを検討する必要があります。 この方法なら、テンプレートを使い分ける必要がある企業の分だけ、明示的にプロビジョニング URL を設定すればよいことになります。
なおパートナー様によっては、UC-One SaaS など、システム レベルのプロビジョニング URL をすでに使用している可能性があります。 その場合、UC-One SaaS でユーザー プロビジョニングに使用するシステム レベルの URL を保持し、Cisco BroadWorks 版 Webex に移行する企業を上書きする方法を選択できます。 このほかに、BroadWorks 版 Webex 用にシステム レベルの URL を設定し、UC-One SaaS で保持する企業を再構成する方法も取ることができます。
この決定に関連する設定オプションの詳細については、「Provisioning Service URLを使用したアプリケーションサーバーの設定」を参照してください。
プロビジョニング アダプタ プロキシ
セキュリティを強化するため、プロビジョニング アダプタ プロキシを使用すると、AS と Webex 間のフロースルー プロビジョニングのために、アプリケーション デリバリ プラットフォームで HTTP(S) プロキシを使用できます。 プロキシ接続により、AS と Webex 間のトラフィックを中継するエンドツーエンド TCP トンネルが作成され、AS がパブリック インターネットに直接接続する必要がなくなります。 安全な接続のために、TLS を使用できます。
この機能では、BroadWorks でプロキシを設定する必要があります。 詳細については、「Cisco BroadWorks プロビジョニング アダプタ プロキシ機能の説明」を参照してください。
最小要件
アカウント
Webex を利用するためにプロビジョニング対象とするサブスクライバはすべて、Webex と統合する BroadWorks システムに存在している必要があります。 必要に応じて複数の BroadWorks システムを統合できます。
すべてのサブスクライバは、BroadWorks ライセンスとプライマリ番号または内線番号を持っている必要があります。
Webex はメール アドレスをあらゆるユーザーのプライマリ識別子として使用します。 信頼済みメールによるフロースルー プロビジョニングを使用している場合、各ユーザーに BroadWorks のメール属性で有効なアドレスが必要です。
BroadWorks 認証を使用するテンプレートを使用する場合、BroadWorks の [Alternate ID (代替 ID)] 属性にはサブスクライバのメール アドレスをコピーしてもかまいません。 結果としてユーザーはメール アドレスと BroadWorks パスワードを使用して Webex にサインインできるようになります。
管理者がパートナー ハブにサインインするには、Webex アカウントを使用する必要があります。
Cisco BroadWorks 版 Webex に BroadWorks 管理者をオンボードすることはサポートされていません。 プライマリ番号および/または内線番号を持つ BroadWorks 通話ユーザーのみをオンボードできます。 フロースルー プロビジョニングを使用している場合は、統合型 IM&P サービスもユーザに割り当てる必要があります。
|
ネットワーク内のサーバーとソフトウェア要件
最小バージョンの R22 での BroadWorks インスタンス。 サポートされるバージョンとパッチについては、このドキュメントの「BroadWorks ソフトウェア要件」セクションを参照してください。 詳細については、BroadSoft 製品のライフサイクルポリシーBroadSoft ライフサイクルポリシーおよび BroadWorks ソフトウェア互換性マトリクスのセクション。
BroadWorks インスタンスには、少なくとも以下のサーバーが含まれる必要があります。
前述の BroadWorks バージョンのアプリケーション サーバー (AS)
ネットワーク サーバー (NS)
プロファイル サーバー (PS)
以下の要件を満たす公開 XSP サーバーまたはアプリケーション配信プラットフォーム (ADP):
認証サービス (BWAuth)
XSI アクションとイベントのインターフェイス
DMS (デバイス管理ウェブ アプリケーション)
CTI インターフェイス (コンピュータ テレフォニーのインテグレーション)
有効な証明書 (自己署名は無効) と必要な中間証明書がそろった TLS 1.2。 エンタープライズ ルックアップを簡素化するために、システム レベルの管理が必要です。
認証サービスの相互 TLS (mTLS) 認証 (信頼アンカーとしてインストールされている公開 Webex クライアント証明書チェーンが必要)
CTI インターフェイスの相互 TLS (mTLS) 認証 (信頼アンカーとしてインストールされている公開 Webex クライアント証明書チェーンが必要)
「コール通知プッシュ サーバー」(Apple/Google にコール通知をプッシュするために使用する環境内の NPS) として機能する別の XSP/ADP サーバー。 ここでは頭文字を取って「CNPS」と呼び、メッセージングとプレゼンスに必要なプッシュ通知を提供する Webex サービスから区別します。
このサーバーは R22 以降にする必要があります。
BroadWorks 版 Webex のクラウド接続の負荷がかかり、通知遅延増大の影響も受けて、NPS サーバーのパフォーマンスがどの程度劣化するかが予測しきれないため、CNPS には別途 XSP/ADP サーバーが必要です。 XSP スケールについて詳しくは『Cisco BroadWorks システム エンジニアリング ガイド』 を参照してください。
Webex アプリ プラットフォーム
Webex アプリの英語版をダウンロードするには、https://www.webex.com/webexfromserviceproviders-downloads.htmlにアクセスしてください。 Webex アプリは次から利用できます。
Windows PC またはノートパソコン
Apple PC または MacOS 対応のノートパソコン
iOS (Apple ストア)
Android (Play ストア)
ウェブブラウザ(https://teams.webex.com/に進む)
ローカライズされたバージョン
Webex アプリのローカライズ版をダウンロードするには、次のリンクのいずれかを使用します。
https://origin-webex-uat.cisco.com/ko/webexfromserviceproviders-downloads.html (韓国語)
https://origin-webex-uat.cisco.com/fr/webexfromserviceproviders-downloads.html (フランス語)
https://origin-webex-uat.cisco.com/pt/webexfromserviceproviders-downloads.html (ポルトガル語)
https://origin-webex-uat.cisco.com/zh-tw/webexfromserviceproviders-downloads.html (中国語)
https://origin-webex-uat.cisco.com/zh-cn/webexfromserviceproviders-downloads.html (簡体字中国語)
https://origin-webex-uat.cisco.com/ja/webexfromserviceproviders-downloads.html (日本)
https://origin-webex-uat.cisco.com/es/webexfromserviceproviders-downloads.html (スペイン)
https://origin-webex-uat.cisco.com/de/webexfromserviceproviders-downloads.html (ドイツ語)
https://origin-webex-uat.cisco.com/it/webexfromserviceproviders-downloads.html (イタリア語)
物理的な電話器とアクセサリ
Cisco IP Phone:
Cisco IP Phone 6800 シリーズとマルチプラットフォーム ファームウェア
Cisco IP Phone 7800 シリーズとマルチプラットフォーム ファームウェア
Cisco IP Phone 8800 シリーズとマルチプラットフォーム ファームウェア
モデルなどについて詳しくは、https://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phones/multiplatform-firmware.html を参照してください。
その他の BroadWorks インテグレーションと同様の方法でサードパーティ製の電話をサポートします。 ただし、Cisco BroadWorks 版 Webex との連絡先とプレゼンスの統合はまだありません。
アダプター:
Cisco ATA 191 マルチプラットフォーム アナログ電話アダプタ
Cisco ATA 192 マルチプラットフォーム アナログ電話アダプタ
モデルなどについて詳しくは、https://www.cisco.com/c/en/us/products/unified-communications/ata-190-series-analog-telephone-adapters/index.html を参照してください。
ヘッドセット:
Cisco ヘッドセット 500 シリーズ
モデルと詳細については、 https://www.cisco.com/c/en/us/products/collaboration-endpoints/headset-500-series/index.html を参照してください。
- Room OS デバイス:
Webex Room および Room Kit シリーズ
Webex Desk シリーズ
Webex Board シリーズ
デバイスの統合
Cisco BroadWorks 版 Webex のオンボードおよびサービスルーム OS および MPP デバイスの詳細については、「Cisco BroadWorks 版 Webex のデバイス統合ガイド」を参照してください。
デバイス プロファイル
以下は、通話クライアントとして Webex アプリをサポートするために、アプリケーション サーバーにロードする必要がある DTAF ファイルです。 これらは UC-One SaaS で使用される場合と同じ DTAF ファイル群ですが、Webex アプリ用の新規の config-wxt.xml.template
Webex アプリで使用されるファイル。
最新のデバイスプロファイルをダウンロードするには、Application Delivery Platform Software Downloadsサイトに移動して、最新のDTAFファイルを取得します。 これらのダウンロードは ADP と XSP の両方で機能します。
クライアント名 |
デバイス プロファイル タイプとパッケージ名 |
---|---|
Webex モバイル テンプレート |
ID/デバイス プロファイル タイプ: 接続 - モバイル DTAF: 構成ファイル: |
Webex タブレット テンプレート |
ID/デバイス プロファイル タイプ: 接続 - タブレット DTAF: 構成ファイル: |
Webex デスクトップ テンプレート |
ID/デバイス プロファイル タイプ: Business Communicator - PC DTAF: 構成ファイル: |
識別/デバイス プロファイル
Cisco BroadWorks 版 Webex のすべてのユーザーは、Webex アプリを使用してコールを発信するには、上記のいずれかのデバイス プロファイルを使用する BroadWorks で ID/デバイス プロファイル が割り当てられている必要があります。 プロファイルは、ユーザがコールを発信できる設定を提供します。
Cisco BroadWorks 版 Webex の OAuth 資格情報を取得する
オンボーディング エージェントまたは Cisco TAC を使用して、Cisco Identity Provider Federation アカウントの Cisco OAuth をプロビジョニングするためのサービス リクエストを作成します。
各機能に次のリクエストタイトルを使用します。
XSP でサービスを設定するには、[XSP AuthService Configuration] を使用します。
認証プロキシを使用するために NPS を設定するには、「認証プロキシセットアップの NPS 設定」。
CI ユーザ UUID 同期の CI ユーザ UUID 同期。 この機能の詳細については、次を参照してください。 Cisco BroadWorks は CI UUID をサポートしています。
BroadWorks で Cisco Billing for BroadWorks および Webex For BroadWorks サブスクリプションを有効にするには、BroadWorks を設定します。
Cisco は OAuth クライアント ID、クライアント シークレット、および 60 日間、有効な更新トークンを提供します。 トークンを使用する前に期限が切れた場合は、別のリクエストを発生できます。
すでに Cisco OAuth Identity Provider クレデンシャルを取得している場合は、新しいサービス リクエストを完了してクレデンシャルを更新してください。 |
注文証明書
TLS 認証の証明書要件
必要なアプリケーションすべてで、権威のある証明機関から署名を受け、パブリック XSP に展開されたセキュリティ証明書が義務付けられています。 これらは XSP サーバーへの全インバウンド接続で、TLS 証明書の確認をサポートするために使用されます。
これらの証明書には、サブジェクト共通名またはサブジェクト代替名と同じ XSP パブリック完全修飾ドメイン名を記載する必要があります。
これらのサーバー証明書の展開にかかわる正確な要件は、公開 XSP が展開される方法によって異なります。
TLS ブリッジ プロキシを使用
TLS パススルー プロキシを経由
XSP に直接
次の図は、CA が署名したパブリック サーバー証明書が次の 3 つのケースで読み込まれる場所について簡単に説明しています。
Webex アプリが認証をサポートする公的にサポートされた CA は、Webex ハイブリッド サービスのサポート対象認証局のリストに登録されています。
TLS ブリッジ プロキシの TLS 証明書要件
パブリック署名サーバー証明書がプロキシにロードされます。
プロキシがこのパブリック署名のサーバー証明書を Webex に提示します。
Webex がプロキシのサーバー証明書に署名した公開 CA を信頼します。
内部 CA 署名付き証明書を XSP にロードできます。
XSP が、プロキシに内部署名されたサーバー証明書を提示します。
プロキシが XSP サーバー証明書に署名した内部 CA を信頼します。
TLS パススルー プロキシまたは DMZ の XSP の TLS 証明書要件
パブリック署名サーバー証明書が XSP にロードされます。
XSP がパブリック署名サーバー証明書を Webex に提示します。
Webex が XSP のサーバー証明書に署名したパブリック CA を信頼します。
CTI インターフェイス上の相互 TLS 認証に関する追加の証明書要件
CTI インターフェイスに接続するとき、Webex が相互 TLS 認証の一部としてクライアント証明書を提示します。 Webex クライアントの証明書 CA/チェーン証明書は、Control Hub からダウンロードできます。
証明書をダウンロードするには:
パートナー ハブにサインインし、
に移動し、証明書のダウンロード リンクをクリックします。この Webex CA 証明書チェーンを展開するための具体的な要件は、パブリック XSP が展開される方法によって異なります。
TLS ブリッジ プロキシを使用
TLS パススルー プロキシを経由
XSP に直接
下図にこの 3 つのケースの証明書要件をまとめました。
(オプション) TLS ブリッジ プロキシの証明書要件
Webex がパブリック署名クライアント証明書をプロキシに提示します。
プロキシが、クライアント証明書に署名した Cisco 内部 CA を信頼します。 Control Hub からこの CA とチェーンをダウンロードして、プロキシの信頼ストアに追加できます。 パブリック署名の XSP サーバー証明書もプロキシにロードされます。
プロキシがパブリック署名のサーバー証明書を Webex に提示します。
Webex がプロキシのサーバー証明書に署名した公開 CA を信頼します。
プロキシが、内部署名されたクライアント証明書を XSP に提示します。
この証明書 には 、BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 と TLS clientAuth の目的で収集された [拡張キー使用] フィールドが x509.v3 拡張フィールドに含まれる必要があります。 例:
X509v3 extensions: X509v3 Extended Key Usage: 1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication
内部証明書の CN は bwcticlient.webex.com にする必要があります。
プロキシの内部クライアント証明書を生成する場合、SAN 証明書はサポートされません。 XSP の内部サーバー証明書は SAN になる場合があります。
パブリック認証局は、BroadWorks 独自の必須 BroadWorks OID が使われた証明書への署名を渋る可能性もあります。 ブリッジ プロキシの場合、プロキシが XSP に提示するクライアント証明書に署名するために、内部 CA を使用せざるを得ない場合もあります。
XSP が内部 CA を信頼します。
XSP が内部署名されたサーバー証明書を示します。
プロキシが内部 CA を信頼します。
アプリケーション サーバーの ClientIdentity には、プロキシから XSP に提示される内部署名クライアント証明書の CN が含まれています。
(オプション) DMZ の XSP または TLS パススルー プロキシの証明書要件
Webex が XSP に Cisco の内部 CA 署名クライアント証明書を提示します。
XSP がクライアント証明書に署名した Cisco 内部 CA を信頼します。 Control Hub からこの CA とチェーンをダウンロードして、プロキシの信頼ストアに追加できます。 パブリック署名の XSP サーバー証明書も XSP にロードされます。
XSP がパブリック署名のサーバー証明書を Webex に提示します。
Webex が XSP のサーバー証明書に署名したパブリック CA を信頼します。
アプリケーション サーバーの ClientIdentity には、Webex が XSP に提示する Cisco 署名クライアント証明書の CN が含まれます。
ネットワークを準備する
Cisco BroadWorks 版 Webex で使用される接続の詳細については、次を参照してください。 Cisco BroadWorks 版 Webex のネットワーク要件。 この記事では、ファイアウォール Ingress および Egress ルールの設定に必要な IP アドレス、ポート、プロトコルのリストを示します。
Webex サービスのネットワーク要件
前述の「受信ルール」や「送信ルール」のファイアウォール テーブルには、Cisco Broadworks 版 Webex 専用の接続のみが記載されています。 Webex アプリと Webex クラウド間の接続に関する一般的な情報については、「Webex サービスのネットワーク要件」を参照してください。 この記事は Webex の一般的な内容です。次のテーブルでは記事のさまざまなセクションと、各セクションと Cisco Broadworks 版 Webex との関連性を示します。
ネットワーク要件に関する記事のセクション |
情報の関連性 |
---|---|
お知らせ |
|
お知らせ |
|
必読 |
|
必読 |
|
必読 |
|
オプション |
|
オプション |
|
オプション |
|
オプション |
|
オプション |
|
オプション |
|
FedRAMP 顧客向けの Webex サービス |
適用なし |
付加情報
詳細については「Webex App Firewall Whitepaper」(PDF)(日本語版は「Webex ファイアウォール テクニカル ペーパー」)を参照してください。
Broadworks の冗長性サポート
パートナーのネットワークにアクセスする必要がある Webex クラウド サービスと Webex クライアント アプリは、パートナーが提供する Broadworks XSP の冗長性をフルサポートしています。 計画的なメンテナンスや予定外の事情で XSP またはサイトを利用できない場合も、Webex のサービスとアプリは、リクエストを完了するために、パートナーが提供する別の XSP またはサイトに進むことができます。
ネットワーク トポロジ
Broadworks XSP はインターネットで直接展開できます。また代わりに DMZ に常駐させ、その前面に F5 BIG-IP などのロード バランシング要素を配置することもできます。 geo 冗長性に対応するために、XSP は 2 つ(以上)のデータセンターに展開できます。それぞれの前面に 1 つのロードバランサを配置し、それぞれにパブリック IP アドレスを持たせることができます。 1 つのロード バランサの背後に複数の XSP がある場合、Webex のマイクロサービスとアプリでは、ロードバランサの IP アドレスのみを認識するため、背後に複数の XSP があったとしても、Broadworks が 1 つの XSP しか持たないかのように認識されます。
以下の例では、XSP がサイト A とサイト B の 2 つのサイトで展開されます。各サイトで 1 つのロードバランサが 2 つの XSP の前面に表示されています。 サイト A では XSP1 と XSP2 の前面に LB1 が表示され、サイト B では XSP3 と XSP4 の前面に LB2 が表示されています。 ロードバランサのみが公開ネットワーク上に公開され、XSP は DMZ プライベートネットワーク内に含まれます。
Webex クラウドサービス
DNS の構成
Webex クラウド マイクロサービスは、Xsi インターフェイス、認証サービス、CTI に接続するために Broadworks XSP サーバーを見つける必要があります。
Webex クラウド マイクロサービスは、構成された XSP ホスト名の DNS A/AAAA ルックアップを実行し、返された IP アドレスに接続します。 具体的には、負荷を分散するエッジ要素や XSP サーバー自身などが考えられます。 複数の IP アドレスが返された場合、リストの最初の IP が選択されます。 SRV ルックアップは現在サポートされていません。
例: パートナーのDNS A Recordは、ラウンドロビンバランスのインターネット対応のXSPサーバ/ロードバランサの検出に使用されます。
記録タイプ |
名前 |
ターゲット |
目的 |
---|---|---|---|
A |
|
|
LB1(サイト A)にポイント |
A |
|
|
LB2(サイト B)にポイント |
フェールオーバー
Webex マイクロサービスが XSP またはロードバランサにリクエストを送信し、リクエストが失敗した場合、次のようないくつかの状況が発生する可能性があります。
ネットワークエラーが原因で失敗した場合(例: TCP、SSL)、Webex マイクロサービスは IP をブロック中としてマークし、すぐに次の IP へのルート変更を実行します。
エラーコード (HTTP 5xx) が返された場合、Webex マイクロサービスは IP をブロック済みとしてマークし、次の IP へのルートをすぐに実行します。
HTTP 応答が 2 秒以内に受信されない場合、リクエストは時間切れになります。Webex マイクロサービスは IP をブロック中としてマークし、代わりに次の IP へのルーティングを実行します。
リクエストごとに 3 回試しても成功しない場合、マイクロサービスにエラーレポートが戻されます。
ブロック中のリストにある IP は、XSP にリクエストを送信するとき試すアドレスのリストから除外されます。 所定の時間が過ぎると、ブロックされたIP は期限切れとなり、別のリクエストで試されるリストに戻ります。
すべての IP アドレスがブロックされている場合、マイクロサービスではブロック中のリストから IP アドレスをランダムに選択する形で、リクエスト送信を試みます。 成功すると、その IP アドレスはブロック中のリストから削除されます。
ステータス
XSP またはロードバランサに対する Webex クラウドサービスの接続ステータスは、Control Hub で確認できます。 Broadworks の通話クラスタの下に、以下の各インターフェイスに対する接続ステータスが表示されます。
XSI アクション
XSI イベント
認証サービス
ページが読み込まれたときか、入力更新中に、接続ステータスが更新されます。 次のような接続ステータスになる可能性があります。
緑: A レコードルックアップの IP の 1 つでインターフェイスに到達できる場合。
赤: A レコードルックアップのすべての IP が到達不可能で、インターフェイスが使用不可の場合。
次のサービスはマイクロサービスを使用して XSP に接続し、XSP インターフェイスの可用性の影響を受けます。
Webex アプリのログイン
Webex アプリのトークン更新
信頼できないメールまたはセルフアクティベーション
Broadworks サービスの正常性チェック
Webex アプリ
DNS の構成
Webex アプリは XSP の Xtended Services Interface(XSI-Actions & XSI-Events)とデバイス管理サービス(DMS)サービスにアクセスします。
XSI サービスを検索するには、Webex アプリが DNS SRV ルックアップを実行します _xsi-client._tcp.<webex app xsi domain>
です。 SRV は、XSP ホストまたは XSI サービスのロード バランサに設定された URL を指します。 SRV ルックアップが利用できない場合、Webex アプリは A/AAAA ルックアップに戻ります。
SRV は複数の A/AAAA ターゲットに解決できます。 ただし、各 A/AAAA レコードは、単一の IP アドレスにのみマッピングする必要があります。 ロードバランサやエッジデバイスの背後にある DMZ に複数の XSP がある場合、同一セッションのすべてのリクエストを同一の XSP にルーティングするように、セッション永続性を維持するようロードバランサを構成する必要があります。 クライアントの XSI イベントのハートビートは、イベント チャネルの確立に使用した XSP に送る必要があるため、この構成は必須です。
例 1 では、webex-app-xsp.example.com の A/AAAA レコードは存在せず、必要もありません。 DNS で 1 つの A/AAAA レコードを定義する必要がある場合は、1 つの IP アドレスだけを返す必要があります。 いずれの場合も、SRV は Webex アプリに対して定義されている必要があります。 Webex アプリが複数の IP アドレスに解決する A/AAAA 名を使用する場合、またはロード バランサ/エッジ要素がセッションの持続性を維持しない場合、クライアントは最終的にイベント チャネルを確立しなかった XSP にハートビートを送信します。 するとチャネルがダウンし、内部トラフィックへの依存度が高まるため、XSP クラスタのパフォーマンスが著しく低下することになります。 Webex Cloud と Webex アプリには A/AAAA レコードルックアップの異なる要件があるため、Webex Cloud と Webex アプリに別の FQDN を使用して XSP にアクセスする必要があります。 例に示すように、Webex Cloud はレコードを使用します |
例 1—複数の XSP、それぞれ別のロードバランサの背後
この例では、SRV は A レコードを、それぞれの A レコードが別のサイトにある別のロード バランサを指し示すように指します。 Webex アプリは常にリストの最初の IP アドレスを使用し、最初のレコードがダウンしている場合にのみ次のレコードに移動します。
記録タイプ |
登録 |
ターゲット |
目的 |
---|---|---|---|
SRV |
|
|
Xsi インターフェイスのクライアント検出 |
SRV |
|
|
Xsi インターフェイスのクライアント検出 |
A |
|
|
LB1(サイト A)にポイント |
A |
|
|
LB2(サイト B)にポイント |
例 2:1 つのロード バランサの後ろに複数の XSP(TLS ブリッジを使用)
最初のリクエストでは、ロードバランサはランダムな XSP を選択します。 その XSP は、今後のリクエストで Webex アプリに含まれる Cookie を返します。 今後のリクエストでは、ロード バランサは Cookie を使用して接続を正しい XSP にルーティングし、イベント チャネルが壊れないようにします。
記録タイプ |
登録 |
ターゲット |
目的 |
---|---|---|---|
SRV |
|
|
ロードバランサ |
A |
LB.example.com (LBサンプル) |
|
ロードバランサの IP アドレス (XSP はロードバランサの背後にあります) |
DMSのURL
設定ファイルをダウンロードするため、Webex アプリはログインプロセス中に DMS URL も取得します。 URL のホストが解析されると、DMS サービスをホストする XSP に接続するために、Webex アプリがホストの DNS A/AAAA ルックアップを実行します。
例: ラウンドロビン負荷分散インターネット接続側 XSP サーバーまたはロードバランサの検出に使用する DNS A レコード(Webex アプリが DMS 経由で構成ファイルをダウンロードするために使用):
記録タイプ |
名前 |
ターゲット |
目的 |
---|---|---|---|
A |
|
|
LB1(サイト A)にポイント |
A |
|
|
LB2(サイト B)にポイント |
Webex アプリが XSP アドレスを検出する方法
クライアントが、以下の DNS フローを使用して XSP ノードの検索を試みます。
クライアントは最初に Webex クラウドから Xsi-Actions/Xsi-Events URL (関連する BroadWorks Calling クラスタを作成するときパートナー様が入力したもの) を取得します。 Xsi ホスト名/ドメインが URL から解析され、クライアントは次の SRV ルックアップを実行します。
_xsi-client._tcp に対し、クライアントが SRV ルックアップを実行します。<xsi domain="">
SRV ルックアップが 1 つ以上の A/AAAA ターゲットを返した場合:
クライアントは、該当するターゲットに対して A/AAAA ルックアップを実行し、返された IP アドレスをキャッシュします。
クライアントが、SRV の優先順位、次に重み (すべてに等しい場合はランダム) に基づいて、ターゲットの 1 つ (つまり IP アドレスを 1 つ持つ A/AAAA レコード) に接続します。
SRV ルックアップがターゲットを返さなかった場合:
クライアントは Xsi ルート パラメータの A/AAAA ルックアップを実行し、返された IP アドレスへの接続を試みます。 具体的には、負荷を分散するエッジ要素や XSP サーバー自身などが考えられます。
以上の説明のとおり、同じ理由で A/AAAA レコードは 1 つの IP アドレスに解決される必要があります。
(オプション) その後、次のタグを使用すると、Webex アプリのデバイス設定でカスタム XSI-Actions/XSI-Events を細かく指定することもできます。
<protocols> <xsi> <paths> <root>%XSI_ROOT_WXT%</root> <actions>%XSI_ACTIONS_PATH_WXT%</actions> <events>%XSI_EVENTS_PATH_WXT%</events> </paths> </xsi> </protocols>
以上の構成パラメータは、Control Hub の BroadWorks クラスタの設定より優先されます。
存在する場合、クライアントが BroadWorks クラスタ設定で受け取った元の XSI アドレスと比較されます。
違いが検出された場合、クライアントは XSI Actions/ XSI Events 接続を再び初期化します。 この最初のステップは、ステップ1にリストされている同じDNSルックアッププロセスを実行することです。今回は、設定ファイルから%XSI_ROOT_WXT%パラメータの値のルックアップを要求します。
このタグを使用して Xsi インターフェイスを変更する場合は、必ず対応する SRV レコードを作成してください。
フェールオーバー
Webex アプリはログイン中に _xsi-client._tcp.<xsi domain=""> の DNS SRV ルックアップを実行し、ホストのリストを構築し、SRV の優先順位、重み付けに基づいてホストの 1 つに接続します。 この接続済みホストは以後のリクエストで選択されます。 その後、選択したホストへのイベント チャネルが開き、チャネル確認のために定期的にハートビートが送信されます。 2 番目に送信されるリクエストからは、すべてのリクエストが HTTP 応答で返される Cookie を含むため、ロード バランサがセッション永続性 (アフィニティ) を維持し、常に同じバックエンド XSP サーバーにリクエストを送信することが重要です。
ホストへのリクエストまたはハートビートリクエストが失敗すると、次のいくつかの状況が発生する可能性があります。
失敗の原因がネットワークエラーの場合 (例: TCP、SSL)、Webex アプリはすぐにリスト内の次のホストにルートを変更します。
エラーコード (HTTP 5xx) が返された場合、Webex アプリは IP アドレスをブロック済みとしてマークし、リストの次のホストにルーティングします。
一定時間内に応答が受信されなかった場合は時間切れとなるため、リクエストは失敗したと見なされ、次のリクエストは次のホストに送信されます。 ただし時間切れリクエストは失敗したと見なされます。 一部のリクエストは失敗した後に再試行されます(再試行の時間が増加)。 必須ではないと思われるリクエストは再試行されません。
新しいホストを試して成功した場合、そのホストがリストに存在していれば、そのホストが新しく選択されたホストになります。 リストの最後のホストが試されたあとに、Webex アプリは最初のホストから繰り返します。
ハートビートの場合、リクエストが 2 つ続けて失敗すると、Webex アプリがイベントチャネルを初期化し直します。
Webex アプリはフェイルバックを実行せず、DNS サービス検出がサインイン時に 1 回のみ実行されます。
Webex アプリはサインイン中に XSP/DMS インターフェイスを介して構成ファイルのダウンロードを試みます。 取得した DMS URL でホストの A/AAAA レコードルックアップを実行し、最初の IP に接続します。 まず、SSO トークンを使用して構成ファイルをダウンロードするリクエストの送信を試みます。 何らかの理由で失敗した場合は再試行しますが、デバイスのユーザー名とパスワードを使用することになります。