環境の準備

意思決定ポイント

考慮事項 質問と回答 リソース

アーキテクチャとインフラストラクチャ

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 の要件:

  • ユーザは、プライマリ番号または内線番号を持つ BroadWorks 上に存在します。

  • ユーザーには、Webex プロビジョニング サービス URL を示す統合型 IM+P サービスが割り当てられます。

  • 信頼できるメールのみ。 ユーザーには、BroadWorks で設定されたメール アドレスがあります。 ユーザーが BroadWorks クレデンシャルを使用してログインできるように、電子メールを [代替 ID] フィールドにも追加することをお勧めします。

  • BroadWorks には、フロースルー プロビジョニング用の必須パッチがインストールされています。 パッチ要件については、「フロースルー プロビジョニングによる必須パッチ」(以下)を参照してください。

  • BroadWorks AS は Webex クラウドに直接接続されているか、または Provisioning Adapter プロキシが Webex プロビジョニング サービス URL への接続で設定されています。

    Webex プロビジョニング サービス URL を取得するには、「Configure Application Server with Provisioning Service URL」を参照してください。

    プロビジョニング アダプタ プロキシを設定するには、Cisco BroadWorks Implement Provisioning Adapter Proxy FD を参照してください。

Webex の要件:

顧客テンプレートには、次の設定が含まれます。

  • BroadWorks フロースルー プロビジョニング を有効にするトグルがオンになっています。

  • プロビジョニング アカウント名とパスワードは、BroadWorks システムレベルの管理者資格情報を使用して割り当てられます

  • ユーザー検証は、「BroadWorks メールを信頼する」または「信頼できないメール」に設定されています。

ユーザー セルフプロビジョニング

管理者は、既存の BroadWorks ユーザーに、ユーザー アクティベーション ポータルへのリンクを提供します。 ユーザーは、BroadWorks の資格情報を使用してポータルにログインし、有効なメール アドレスを入力する必要があります。 メールが検証された後、Webex は追加のユーザー情報を取得してプロビジョニングを完了します。

BroadWorks の要件:

  • ユーザーはプライマリ番号または内線番号で BroadWorks に存在する必要があります

Webex の要件:

顧客テンプレートには、次の設定が含まれます。

  • Enable Flow Through Provisioning のトグルがオフになっています。

  • ユーザー検証信頼できないメールに設定されています。

  • ユーザーによるセルフアクティベーション を許可するにチェックを入れます。

API 経由の SP 制御プロビジョニング

(信頼済みまたは信頼されていないメール)

Webex は、既存のワークフローとツールにユーザーのプロビジョニングを構築できる一連のパブリック API を公開します。 2つの流れがあります。

  • 信頼できるメール—API はユーザーをプロビジョニングし、BroadWorks メールを Webex メールとして適用します。

  • 信頼できないメール—API はユーザーをプロビジョニングしますが、ユーザーはユーザー アクティベーション ポータルにログインし、有効なメール アドレスを提供する必要があります。

BroadWorks の要件:

  • ユーザは、プライマリ番号または内線番号を持つ BroadWorks 上に存在する必要があります。

Webex の要件:

  • 顧客テンプレートで、ユーザー検証はTrust BroadWorksメールまたは信頼できないメールのいずれかに設定されます。

  • アプリケーションを登録し、許可を要求する必要があります。

  • Webex for BroadWorks 開発者ガイドの「認証」セクションで強調表示されているスコープを使用して、OAuth トークンを要求する必要があります。

  • パートナー組織に管理者またはプロビジョニング管理者を割り当てる必要があります。

API を使用するには、[BroadWorks サブスクライバ] に移動します。

フロースルー プロビジョニングで必要なパッチ

フロースルー プロビジョニングを使用している場合、システム パッチをインストールし、CLI プロパティを適用する必要があります。 BroadWorks のリリースに適用される手順については以下のリストを参照してください。

R22 の場合:

  1. AP.as.22.0.1123.ap376508 をインストールします

  2. インストール後にプロパティ bw.msg.includeIsEnterpriseInOSSschematrue[Maintenance/ContainerOptions] の CLI で設定します。

    詳細については、パッチ ノート https://www.cisco.com/web/software/286326332/154309/AP.as.22.0.1123.ap376508.txt を参照してください。

R23 の場合:

  1. AP.as.23.0.1075.ap376509 をインストールします

  2. インストール後にプロパティ bw.msg.includeIsEnterpriseInOSSschematrue[Maintenance/ContainerOptions] の CLI で設定します。

    詳細については、パッチ ノート https://www.cisco.com/web/software/286326332/154325/AP.as.23.0.1075.ap376509.txt を参照してください。

R24 の場合:

  1. AP.as.24.0.944.ap375100 をインストールします

  2. インストール後にプロパティ bw.msg.includeIsEnterpriseInOSSschematrue[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 文字のロケールに変換するマッピングを示します。

表 1. サポートされている言語ロケールコード

サポートされている言語ロケール

(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

ブランディングのカスタマイズ方法の詳細については、「高度なブランディングのカスタマイズの設定」を参照してください。


  • 基本的なブランディングのカスタマイズは廃止される予定です。 幅広いカスタマイズを提供する Advanced Branding を展開することをお勧めします。

  • 既存の顧客組織に添付する際のブランディングの適用方法の詳細については、「BroadWorks 版 Webex を既存の組織に添付する」セクションの「組織添付の条件」を参照してください。

カスタマー テンプレート

カスタマー テンプレートを使用すると、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。

  • BroadWorks への直接接続を設定すると、Webex アプリは BroadWorks サーバーに直接認証されます。

    直接接続を設定するには、Partner Hub の BroadWorks クラスタ設定で [BroadWorks 直接認証を有効にする] チェックボックスをオンにする必要があります (デフォルトでは、この設定はオフになっています)。

  • それ以外の場合は、BroadWorks への認証は Webex がホストする仲介サービスを通じて行われます。

Cisco Common Identity
多要素認証を使用しますか? いいえ 多要素認証をサポートする IdP を顧客に義務付けます。

資格情報の確認パス

  1. 起動したブラウザでユーザーが最初のログイン フローに電子メール情報を入力すると、認証モードが表示されます。

  2. その後、ブラウザは Webex がホストする BroadWorks ログイン ページにリダイレクトされます (このページはブランディングできます)

  3. ログインページで BroadWorks のユーザー ID とパスワードを入力します。

  4. BroadWorks でユーザー資格情報が検証を受けます。

  5. 成功すると、Webex から認証コードを取得できます。 このコードは Webex サービスに必要なアクセス トークンを取得するために使用します。

  1. 起動したブラウザでユーザーが最初のログイン フローに電子メール情報を入力すると、認証モードが表示されます。

  2. ブラウザは IdP (Cisco Common Identity または Customer IdP) にリダイレクトされ、そこでログイン ポータルが表示されます。

  3. ユーザーがログイン ページで適切な資格情報を入力します

  4. 顧客 IdP がサポートしている場合、多要素認証が行われる場合もあります。

  5. 成功すると、Webex から認証コードを取得できます。 このコードは Webex サービスに必要なアクセス トークンを取得するために使用します。


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 のデフォルトの国際コールイン番号を決定します。

サイトのデフォルトのグローバル コールイン番号は、組織の国に基づいてテレフォニー ドメインで定義された最初の利用可能なダイヤルイン番号に設定されます。 テレフォニー ドメインで定義されたダイヤルイン番号に組織の国が見つからない場合、そのロケーションのデフォルト番号が使用されます。

表 2. 次の表に、各ロケーションに基づくデフォルトのコールイン国コードを示します。

いいえ。

場所

国番号

国名

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 サービスもユーザに割り当てる必要があります。

ネットワーク内のサーバーとソフトウェア要件

  • 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 アプリのローカライズ版をダウンロードするには、次のリンクのいずれかを使用します。

物理的な電話器とアクセサリ

デバイスの統合

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: ucone-mobile-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

構成ファイル: config-wxt.xml

Webex タブレット テンプレート

ID/デバイス プロファイル タイプ: 接続 - タブレット

DTAF: ucone-tablet-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

構成ファイル: config-wxt.xml

Webex デスクトップ テンプレート

ID/デバイス プロファイル タイプ: Business Communicator - PC

DTAF: ucone-desktop-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

構成ファイル: config-wxt.xml

識別/デバイス プロファイル

Cisco BroadWorks 版 Webex のすべてのユーザーは、Webex アプリを使用してコールを発信するには、上記のいずれかのデバイス プロファイルを使用する BroadWorks で ID/デバイス プロファイル が割り当てられている必要があります。 プロファイルは、ユーザがコールを発信できる設定を提供します。

Cisco BroadWorks 版 Webex の OAuth 資格情報を取得する

オンボーディング エージェントまたは Cisco TAC を使用して、Cisco Identity Provider Federation アカウントの Cisco OAuth をプロビジョニングするためのサービス リクエストを作成します。

各機能に次のリクエストタイトルを使用します。

  1. XSP でサービスを設定するには、[XSP AuthService Configuration] を使用します。

  2. 認証プロキシを使用するために NPS を設定するには、「認証プロキシセットアップの NPS 設定」。

  3. CI ユーザ UUID 同期の CI ユーザ UUID 同期。 この機能の詳細については、次を参照してください。 Cisco BroadWorks は CI UUID をサポートしています

  4. 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 からダウンロードできます。

証明書をダウンロードするには:

パートナー ハブにサインインし、[設定] > [BroadWorks Calling] に移動し、証明書のダウンロード リンクをクリックします。

この Webex CA 証明書チェーンを展開するための具体的な要件は、パブリック XSP が展開される方法によって異なります。

  • TLS ブリッジ プロキシを使用

  • TLS パススルー プロキシを経由

  • XSP に直接

下図にこの 3 つのケースの証明書要件をまとめました。

図 1. 各種エッジ設定による CTI 用 mTLS 証明書の交換

(オプション) 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 との関連性を示します。

表 3. Webex アプリ接続のネットワーク要件(全般)

ネットワーク要件に関する記事のセクション

情報の関連性

Webex によってサポートされるデバイス タイプとプロトコルの概要

お知らせ

クラウド登録 Webex アプリおよびデバイスのためのトランスポート プロトコルと暗号化暗号

お知らせ

Webex サービス – ポート番号とプロトコル

必読

Webex メディア サービスの IP サブネット

必読

Webex サービスにアクセスする必要があるドメインと URL

必読

Webex ハイブリッド サービスの追加 URL

オプション

プロキシの機能

オプション

802.1X – ポートベースのネットワーク アクセス コントロール

オプション

SIP ベースの Webex サービスのネットワーク要件

オプション

Webex Edge 音声のネットワーク要件

オプション

その他の 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

webex-cloud-xsp.example.com

198.51.100.48

LB1(サイト A)にポイント

A

webex-cloud-xsp.example.com

198.51.100.49

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 はレコードを使用します webex-cloud-xsp.example.com 、および Webex アプリは SRV を使用します _xsi-client._tcp.webex-app-xsp.example.com です。

例 1—複数の XSP、それぞれ別のロードバランサの背後

この例では、SRV は A レコードを、それぞれの A レコードが別のサイトにある別のロード バランサを指し示すように指します。 Webex アプリは常にリストの最初の IP アドレスを使用し、最初のレコードがダウンしている場合にのみ次のレコードに移動します。

記録タイプ

登録

ターゲット

目的

SRV

_xsi-client._tcp.webex-app-xsp.example.com

xsp-dc1.example.com

Xsi インターフェイスのクライアント検出

SRV

_xsi-client._tcp.webex-app-xsp.example.com

xsp-dc2.example.com

Xsi インターフェイスのクライアント検出

A

xsp-dc1.example.com

198.51.100.48

LB1(サイト A)にポイント

A

xsp-dc2.example.com

198.51.100.49

LB2(サイト B)にポイント

例 2:1 つのロード バランサの後ろに複数の XSP(TLS ブリッジを使用)

最初のリクエストでは、ロードバランサはランダムな XSP を選択します。 その XSP は、今後のリクエストで Webex アプリに含まれる Cookie を返します。 今後のリクエストでは、ロード バランサは Cookie を使用して接続を正しい XSP にルーティングし、イベント チャネルが壊れないようにします。

記録タイプ

登録

ターゲット

目的

SRV

_xsi-client._tcp.webex-app-xsp.example.com

LB.example.com

ロードバランサ

A

LB.example.com (LBサンプル)

198.51.100.83

ロードバランサの IP アドレス (XSP はロードバランサの背後にあります)

DMSのURL

設定ファイルをダウンロードするため、Webex アプリはログインプロセス中に DMS URL も取得します。 URL のホストが解析されると、DMS サービスをホストする XSP に接続するために、Webex アプリがホストの DNS A/AAAA ルックアップを実行します。

例: ラウンドロビン負荷分散インターネット接続側 XSP サーバーまたはロードバランサの検出に使用する DNS A レコード(Webex アプリが DMS 経由で構成ファイルをダウンロードするために使用):

記録タイプ

名前

ターゲット

目的

A

xsp-dms.example.com

198.51.100.48

LB1(サイト A)にポイント

A

xsp-dms.example.com

198.51.100.49

LB2(サイト B)にポイント

Webex アプリが XSP アドレスを検出する方法

クライアントが、以下の DNS フローを使用して XSP ノードの検索を試みます。

  1. クライアントは最初に Webex クラウドから Xsi-Actions/Xsi-Events URL (関連する BroadWorks Calling クラスタを作成するときパートナー様が入力したもの) を取得します。 Xsi ホスト名/ドメインが URL から解析され、クライアントは次の SRV ルックアップを実行します。

    1. _xsi-client._tcp に対し、クライアントが SRV ルックアップを実行します。<xsi domain="">

    2. SRV ルックアップが 1 つ以上の A/AAAA ターゲットを返した場合:

      1. クライアントは、該当するターゲットに対して A/AAAA ルックアップを実行し、返された IP アドレスをキャッシュします。

      2. クライアントが、SRV の優先順位、次に重み (すべてに等しい場合はランダム) に基づいて、ターゲットの 1 つ (つまり IP アドレスを 1 つ持つ A/AAAA レコード) に接続します。

    3. SRV ルックアップがターゲットを返さなかった場合:

      クライアントは Xsi ルート パラメータの A/AAAA ルックアップを実行し、返された IP アドレスへの接続を試みます。 具体的には、負荷を分散するエッジ要素や XSP サーバー自身などが考えられます。

      以上の説明のとおり、同じ理由で A/AAAA レコードは 1 つの IP アドレスに解決される必要があります。

  2. (オプション) その後、次のタグを使用すると、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>
    1. 以上の構成パラメータは、Control Hub の BroadWorks クラスタの設定より優先されます。

    2. 存在する場合、クライアントが BroadWorks クラスタ設定で受け取った元の XSI アドレスと比較されます。

    3. 違いが検出された場合、クライアントは 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 トークンを使用して構成ファイルをダウンロードするリクエストの送信を試みます。 何らかの理由で失敗した場合は再試行しますが、デバイスのユーザー名とパスワードを使用することになります。