環境の準備

判断ポイント

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

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

XSP はいくつですか。

どのように mTLS を取得しますか。

『Cisco BroadWorks システムキャパシティプランナ』

『Cisco BroadWorks システムエンジニアリングガイド』

『XSP CLI リファレンス』

本ドキュメント

顧客とユーザーのプロビジョニング

BroadWorks でのメールを確実に信頼できますか。

アカウントをアクティベートするためにユーザーのメールアドレスの提供を希望しますか。

API を使用するためのツールを作成できますか。

公開 API ドキュメント(https://developer.webex.com [英語])

本ドキュメント

ブランディング どの色とロゴを使用しますか。 Teams のブランド記事
テンプレート 顧客のユースケースにはどのようなものがありますか。 本ドキュメント
顧客/企業/グループごとのサブスクライバ機能 パッケージを選択して、テンプレートごとのサービスレベルを定義します。 基本、標準、プレミアム

本ドキュメント

機能/パッケージマトリックス

ユーザー認証 BroadWorks、または Webex 本ドキュメント
プロビジョニングアダプタ(フロースループロビジョニングオプション用)

UC-One SaaS などの統合 IM&P をすでに使用していますか。

複数のテンプレートを使用する予定ですか。

より一般的なユースケースが予想されますか。

本ドキュメント

『アプリケーションサーバー CLI リファレンス』

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

  • 開始時の規模はどれくらいを予定していますか。 将来的に拡大できますが、現在の使用量の見積もりがインフラストラクチャの計画を推進します。

  • Cisco BroadWorks システムキャパシティプランナ』(https://xchange.broadsoft.com/node/473873 [英語])および『Cisco BroadWorks システムエンジニアリングガイド』(https://xchange.broadsoft.com/node/422649 [英語])に従って、シスコのアカウントマネージャや販売担当者と協力して XSP インフラストラクチャの規模を決定します。

  • Cisco Webex はどのようにして XSP への相互 TLS 接続を確立しますか。 DMZ 内の XSP に直接、または TLS プロキシ経由ですか。 これは、証明書の管理と、インターフェイスに使用する URL に影響します。 (ネットワークのエッジへの暗号化されていない TCP 接続はサポートされていません)。

顧客とユーザーのプロビジョニング

最適なユーザープロビジョニング方法

  • 信頼されたメールを使用したフロースループロビジョニング: BroadWorks で「統合 IM&P」サービスを割り当てることにより、サブスクライバは Cisco Webex で自動的にプロビジョニングされます。

    BroadWorks のサブスクライバメールアドレスが有効であり、Webex に固有であると断言できる場合は、フロースループロビジョニングの「信頼されたメール」バリアントを使用できます。 サブスクライバの Webex アカウントは、操作なしで作成およびアクティベートされます。クライアントをダウンロードしてサインインするだけです。

    メールアドレスは、Cisco Webex の主要なユーザー属性です。 このためサービスプロバイダは、Cisco Webex サービス用にユーザーをプロビジョニングするために、ユーザーの有効なメールアドレスを提供する必要があります。 このアドレスは、BroadWorks のユーザーのメール ID 属性に含まれている必要があります。 代替 ID 属性にもコピーすることをお勧めします。

  • 信頼されたメールを使用しないフロースループロビジョニング: サブスクライバのメールアドレスを信頼できない場合でも、BroadWorks の統合 IM&P サービスを割り当てて、Webex でユーザーをプロビジョニングできます。

    このオプションを使用すると、サービスを割り当てるときにアカウントが作成されますが、サブスクライバは Webex アカウントをアクティベートするために、メールアドレスを指定して検証する必要があります。

  • ユーザーのセルフプロビジョニング: このオプションでは、BroadWorks での IM&P サービスを割り当てる必要はありません。 代わりに、ユーザー(顧客)が、プロビジョニングリンクと、さまざまなクライアントをダウンロードするためのリンクを、ブランディングと指示とともに配布します。

    サブスクライバはリンクをたどり、メールアドレスを指定して検証し、Webex アカウントを作成してアクティベートします。 次に、クライアントをダウンロードしてサインインすると、Webex は BroadWorks からクライアントに関するいくつかの追加構成(プライマリ番号を含む)を取得します。

  • API を介した SP 制御プロビジョニング: Cisco Webex は、サービスプロバイダがユーザーやサブスクライバのプロビジョニングを既存のワークフローに組み込むことができる一連のパブリック API を公開しています。

ブランディング

Webex Teams クライアントにロゴと単色(ナビゲーションバー用)を適用できます。 ユーザーアクティベーションポータルは同じ設定を使用します。

カスタマー テンプレート

カスタマテンプレートを使用すると、Cisco Webex for BroadWorks で顧客および関連するサブスクライバを自動的にプロビジョニングするためのパラメータを定義できます。必要に応じて複数のカスタマーテンプレートを設定できます。 主なパラメータの一部を以下に示します。

パッケージ

  • テンプレートを作成するときに、デフォルトのパッケージを選択する必要があります(詳細については、「概要」セクションの「パッケージ」を参照してください)。 フロースルーとセルフプロビジョニングのどちらによる場合も、そのテンプレートでプロビジョニングされたすべてのユーザーが、デフォルトのパッケージを受け取ります。

  • 複数のテンプレートを作成し、それぞれで異なるデフォルトパッケージを選択することにより、さまざまな顧客のパッケージ選択を制御できます。 次に、それらのテンプレート向けに選択したユーザープロビジョニング方法に応じて、さまざまなプロビジョニングリンク、または企業ごとのさまざまなプロビジョニングアダプタを配布できます。

  • プロビジョニング API を使用するか、パートナーハブ経由で、特定のサブスクライバのパッケージをこのデフォルトから変更できます(「リファレンス」セクションの「BroadWorks プロビジョニング API のための Webex との統合」を参照してください)。

  • BroadWorks からサブスクライバのパッケージを変更することはできません。 統合 IM&P サービスの割り当てはオンまたはオフのいずれかです。サブスクライバが BroadWorks でこのサービスに割り当てられている場合、そのサブスクライバのエンタープライズのプロビジョニング URL に関連付けられているパートナーハブテンプレートがパッケージを定義します。

再販業者と企業ですか、あるいはサービスプロバイダとグループですか。

  • BroadWorks システムの構成方法は、フロースループロビジョニングに影響を与えます。 エンタープライズを使用する再販業者の場合、テンプレートを作成するときにエンタープライズモードを有効にする必要があります。
  • BroadWorks システムがサービスプロバイダモードで構成されている場合は、テンプレートでエンタープライズモードスイッチをオフのままにしておくことができます。
  • 両方の BroadWorks モードを使用して顧客組織をプロビジョニングする場合は、グループと企業に異なるテンプレートを使用する必要があります。

認証モード

顧客のサブスクライバはどのように認証されますか。

認証モード BroadWorks Webex
プライマリユーザー ID BroadWorks ユーザー ID メールアドレス
ID プロバイダ

BroadWorks

Cisco Webex がホストする中継サービスによって認証が容易になります。

Cisco Common Identity
多要素認証ですか。 いいえ 多要素認証をサポートする顧客 IdP が必要です。

サインイン情報の確認パス

  1. ブラウザが起動し、ユーザーが最初のログインフローでメールを入力し、認証モードが検出されます。

  2. 次に、ブラウザは Cisco Webex でホストされている BroadWorks ログインページにリダイレクトされます(このページはブランディング可能です)。

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

  4. ユーザー資格情報が BroadWorks に対して検証されます。

  5. 成功すると、Cisco Webex から認証コードが取得されます。 このコードを使って Cisco Webex サービスに必要なアクセストークンを取得します。

  1. ブラウザが起動し、ユーザーが最初のログインフローでメールを入力し、認証モードが検出されます。

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

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

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

  5. 成功すると、Cisco Webex から認証コードが取得されます。 このコードを使って Cisco Webex サービスに必要なアクセストークンを取得します。

複数のパートナーの取り決め

Webex for BroadWorks を別のサービスプロバイダにサブライセンスしますか。 この場合、各サービスプロバイダは、顧客ベースでソリューションをプロビジョニングできるよう、Webex Control Hub で個別のパートナー組織が必要になります。

プロビジョニングアダプタとテンプレート

フロースループロビジョニングを使用している場合、BroadWorks に入力するプロビジョニング URL は Control Hub のテンプレートから取得されます。 複数のテンプレートを使用できるため、複数のプロビジョニング URL を使用できます。 これにより、サブスクライバが統合 IM&P サービスを付与されたときに、サブスクライバに適用するパッケージを企業ごとに選択できます。

システムレベルのプロビジョニング URL をデフォルトのプロビジョニングパスとして設定するかどうか、およびそのためにどのテンプレートを使用するか検討する必要があります。 このように、別のテンプレートを必要とする企業のプロビジョニング URL を明示的に設定するだけで済みます。

ただし、UC-One SaaS などで、すでにシステムレベルのプロビジョニング URL を使用している可能性があることに注意してください。 その場合は、UC-One SaaS でユーザーをプロビジョニングするためにシステムレベルの URL を保持し、Webex for BroadWorks に移行する企業をオーバーライドすることを選択できます。 または、別の方法で Webex for BroadWorks のシステムレベルの URL を設定し、UC-One SaaS で保持する企業を再構成できます。

この決定に関連する構成の選択については、「Webex for BroadWorks のデプロイ」セクションの「プロビジョニングサービスの URL を使用してアプリケーションサーバーを構成する」を参照してください。

最小要件

アカウント

Webex にプロビジョニングするすべてのサブスクライバは、Webex と統合する BroadWorks システムに存在する必要があります。 必要に応じて、複数の BroadWorks システムを統合できます。

すべてのサブスクライバは、BroadWorks ライセンスとプライマリ番号を持っている必要があります。

Webex では、すべてのユーザーのプライマリ識別子としてメールアドレスを使用します。 信頼されたメールでフロースループロビジョニングを使用している場合、ユーザーは BroadWorks のメール属性に有効なアドレスがある必要があります。

テンプレートで BroadWorks 認証を使用している場合は、サブスクライバのメールアドレスを BroadWorks の代替 ID 属性にコピーできます。 これにより、ユーザーは自分のメールアドレスと BroadWorks パスワードを使用して Webex にサインインできます。

管理者は、Webex アカウントを使用してパートナーハブにサインインする必要があります。

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

  • R21 SP1 以降の BroadWorks インスタンス。 サポートされているバージョンとパッチについては、「BroadWorks ソフトウェア要件」(本ドキュメント内)を参照してください。 「ライフサイクル管理 - BroadSoft サーバー」も参照してください。


    R21 SP1 は、2021 年半ばまでのみサポートされます。 現在、Webex を R21 SP1 と統合できますが、Webex との統合には R22 以降を強くお勧めします。

  • BroadWorks インスタンスには、少なくとも次のサーバーを含めてください。

    • 上記の BroadWorks バージョンのアプリケーションサーバー(AS)

    • ネットワークサーバー(NS)

    • プロファイルサーバー(PS)

  • 次の要件を満たす公開 XSP サーバーまたはアプリケーション配信プラットフォーム(ADP):

    • 認証サービス(BWAuth)

    • XSI Actions および XSI Events のインターフェイス

    • DMS(デバイス管理 Web アプリケーション)

    • CTI インターフェイス(コンピューターテレフォニインテグレーション)

    • 有効な証明書(自己署名ではない)と必要な中間を備えた TLS 1.2。 エンタープライズの参照を容易にするためにシステムレベルの管理者が必要です。

    • 認証サービスの相互 TLS(mTLS)認証(トラストアンカーとしてインストールされたパブリック Cisco Webex クライアント証明書チェーンが必要)

    • CTI インターフェイスの相互 TLS(mTLS)認証(トラストアンカーとしてインストールされたパブリック Cisco Webex クライアント証明書チェーンが必要)

  • 「通話通知プッシュサーバー」(Apple/Google に通話通知をプッシュするために使用される環境内の NPS)として機能する個別の XSP/ADPサーバー。 ここではメッセージングと在席状態のプッシュ通知を配信する Webex のサービスと区別するために、これを「CNPS」と呼びます。

    このサーバーは R22 以降である必要があります。

  • Webex for BWKS クラウド接続の負荷を予測できないと NPS サーバーのパフォーマンスに悪影響を及ぼし、通知の待ち時間が長くなる可能性があるため、CNPS 用に個別の XSP/ADP サーバーを必須としています。 XSP スケールの詳細については、『Cisco BroadWorks システムエンジニアリングガイド』(https://xchange.broadsoft.com/node/422649 [英語])を参照してください。

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

デバイスプロファイル

これらは、呼び出し元クライアントとして Webex Teams をサポートするためにアプリケーションサーバーに読み込む必要がある DTAF ファイルです。 これらは UC-One SaaS で使用されるものと同じ DTAF ファイルですが、Webex Teams に使用される新しい config-wxt.xml.template ファイルがあります。

クライアント名 デバイスプロファイルタイプとパッケージ名

Webex Teams モバイルテンプレート

https://xchange.broadsoft.com/support/uc-one/connect/software

ID/デバイスプロファイルタイプ: 接続 - モバイル

DTAF: ucone-mobile-ucaas_DTAF-#.#.#.###.zip

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

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

https://xchange.broadsoft.com/support/uc-one/communicator/software から

ID/デバイスプロファイルタイプ: ビジネスコミュニケーター - PC

DTAF: ucone-desktop-ucaas_DTAF-#.#.#.###.zip

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

注文証明書

TLS 認証の証明書要件

必要なすべてのアプリケーションには、周知の認証局によって署名され、公開されている XSP に展開されているセキュリティ証明書が必要です。 これらは、XSP サーバーへのすべてのインバウンド接続用 TLS 証明書検証をサポートするために使用されます。

これらの証明書には、サブジェクト共通名またはサブジェクト代替名として XSP パブリック完全修飾ドメイン名を含める必要があります。

これらのサーバー証明書を展開するための正確な要件は、公開されている XSP がどのように展開されているかによって異なります。

  • TLS ブリッジプロキシ経由

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

  • XSP に直接

次の図は、次の 3 つのケースに CA 署名付きパブリックサーバー証明書を読み込む必要がある場所をまとめたものです。

Webex Teams で認証用にサポートされている公的 CA は「Cisco Webex ハイブリッドサービスでサポートされている証明書権限」に記載されています。

TLS ブリッジプロキシの TLS 証明書要件

  • 公的に署名されたサーバー証明書がプロキシに読み込まれる。

  • プロキシは、この公的に署名されたサーバー証明書を Webex に提示する。

  • Webex はプロキシのサーバー証明書に署名したパブリック CA を信頼する。

  • 内部 CA 署名付き証明書を XSP に読み込むことができる。

  • XSP は、この内部署名されたサーバー証明書をプロキシに提示する。

  • プロキシは、XSP サーバー証明書に署名した内部 CA を信頼する。

DMZ での TLS パススループロキシまたは XSP のTLS証明書要件

  • 公的に署名されたサーバー証明書が XSP に読み込まれる。

  • XSPは、公的に署名されたサーバー証明書を Webex に提示する。

  • Webex は、XSP のサーバー証明書に署名したパブリック CA を信頼する。

AuthService に対する相互 TLS 認証の追加の証明書要件

Cisco Webex は、相互 TLS 認証接続を介して認証サービスと対話します。 つまり、Webex がクライアント証明書を提示し、XSP がそれを検証する必要があります。 この証明書を信頼するには、Webex CA 証明書チェーンを使用して XSP(またはプロキシ)でトラストアンカーを作成します。 証明書チェーンはパートナーハブからダウンロードできます。

  1. [設定] > [BroadWorks Calling] の順に選択します。

  2. 証明書のダウンロードリンクをクリックします。


https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt から証明書チェーンを取得することもできます。

この Webex CA 証明書チェーンを展開するための正確な要件は、公開されている XSP がどのように展開されているかによって異なります。

  • TLS ブリッジプロキシ経由

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

  • XSP に直接

次の図は、これら 3 つのケースで Webex CA 証明書チェーンを展開する必要がある場所をまとめたものです。

TLS ブリッジプロキシの相互 TLS 証明書要件

  • Webex は、Webex CA で署名されたクライアント証明書をプロキシに提示する。

  • Webex CA 証明書チェーンはプロキシトラストストアに展開されるため、プロキシがクライアント証明書を信頼する。

  • 公的に署名された XSP サーバー証明書もプロキシに読み込まれる。

  • プロキシは、公的に署名されたサーバー証明書を Webex に提示する。

  • Webex はプロキシのサーバー証明書に署名したパブリック CA を信頼する。

  • プロキシは、内部で署名されたクライアント証明書を XSP に提示する。

    この証明書には、x509.v3 拡張機能フィールドの拡張キー使用法に、BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 と TLS clientAuth 目的を入力する必要があります。 例:

    X509v3 拡張機能:

    X509v3 拡張キー使用法:

    1.3.6.1.4.1.6431.1.1.8.2.1.3、TLS Web クライアント認証 

    プロキシの内部クライアント証明書を生成する場合、SAN 証明書はサポートされていないことに注意してください。 XSP の内部サーバー証明書は SAN にすることができます。

  • XSP は内部 CA を信頼する。

  • XSP は、内部で署名されたサーバー証明書を提示する。

  • プロキシは内部 CA を信頼する。

DMZ での TLS パススループロキシまたは XSP の相互 TLS 証明書要件

  • Webex は、Webex CAで署名されたクライアント証明書を XSP に提示する。

  • Webex CA 証明書チェーンは XSP のトラストストアに展開されるため、XSP はクライアント証明書を信頼する。

  • 公的に署名された XSP サーバー証明書も XSP に読み込まれる。

  • XSPは、公的に署名されたサーバー証明書を Webex に提示する。

  • Webex は、XSP のサーバー証明書に署名したパブリック CA を信頼する。

CTI インターフェイスを介した相互 TLS 認証の追加の証明書要件

CTI インターフェイスに接続すると、Cisco Webex は相互 TLS 認証の一部としてクライアント証明書を提示します。 Webex クライアント証明書 CA/チェーン証明書は、Control Hub からダウンロードできます。

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

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

この Webex CA 証明書チェーンを展開するための正確な要件は、公開されている XSP がどのように展開されているかによって異なります。

  • TLS ブリッジプロキシ経由

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

  • XSP に直接

次の図は、これら 3 つのケースの証明書要件をまとめたものです。

図 1. 異なるエッジ構成を介した CTI の mTLS 証明書交換

(オプション)TLS ブリッジプロキシの証明書要件

  • Webex は、公的に署名されたクライアント証明書をプロキシに提示する。

  • プロキシは、クライアント証明書に署名した Cisco 内部 CA を信頼する。 この CA/チェーンを Control Hub からダウンロードして、プロキシのトラストストアに追加できる。 公的に署名された XSP サーバー証明書もプロキシに読み込まれる。

  • プロキシは、公的に署名されたサーバー証明書を Webex に提示する。

  • Webex はプロキシのサーバー証明書に署名したパブリック CA を信頼する。

  • プロキシは、内部で署名されたクライアント証明書を XSP に提示する。

    この証明書には、x509.v3 拡張機能フィールドの拡張キー使用法に、BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 と TLS clientAuth 目的を入力する必要があります。 例:

    X509v3 拡張機能: X509v3 拡張キー使用法: 1.3.6.1.4.1.6431.1.1.8.2.1.3、TLS Web クライアント認証

    • プロキシの内部クライアント証明書を生成する場合、SAN 証明書はサポートされていないことに注意してください。 XSP の内部サーバー証明書は SAN にすることができます。

    • 公開認証局は、必要な独自の BroadWorks OID を使用して証明書に署名することを推奨しない場合があります。 ブリッジプロキシの場合、プロキシが XSP に提示するクライアント証明書に署名するために内部 CA の使用が強制されることがあります。

  • XSP は内部 CA を信頼する。

  • XSP は、内部で署名されたサーバー証明書を提示する。

  • プロキシは内部 CA を信頼する。

  • アプリケーションサーバーのクライアント ID に、プロキシによって XSP に提示される内部署名されたクライアント証明書の CN が含まれる。

(オプション)DMZ での TLS パススループロキシまたは XSP の証明書要件

  • Webexは、Cisco 内部 CA 署名付きクライアント証明書を XSP に提示する。

  • XSP は、クライアント証明書に署名した Cisco 内部 CA を信頼する。 このCA/チェーンを Control Hub からダウンロードして、プロキシのトラストストアに追加できる。 公的に署名された XSP サーバー証明書も XSP に読み込まれる。

  • XSP は、公的に署名されたサーバー証明書を Webex に提示する。

  • Webex は、XSP のサーバー証明書に署名したパブリック CA を信頼する。

  • アプリケーションサーバーのクライアント ID に、Webex によって XSP に提示されたシスコ署名済みクライアント証明書の CN が含まれている。

ネットワークの準備

接続マップ

次の図は、統合ポイントを示しています。 この図のポイントは、環境に入出力する接続について IP とポートを確認する必要があることを示しています。 Webex for BroadWorks で使用される接続について、次の表で説明します。

ただし、クライアントアプリケーションが正常に機能するためのファイアウォール要件は、すでに help.webex.com で文書化されているため、参照として記載されています。

ファイアウォールの構成

接続マップと次の表は、クライアント(顧客のネットワーク上またはネットワーク外)、ネットワーク、および Webex プラットフォーム間で必要な接続とプロトコルを示しています。

Webex for BroadWorks に固有の接続のみを記載しています。 Teams と Webex クラウド間の一般的な接続は示していません。これらの接続については、次の場所に記載されています。

EMEA の入力ルール

(ネットワークへの入力)

目的 Source プロトコル 移動先 移動先ポート

WebexCloud

CTI/Auth/XSI

18.196.116.47

35.156.83.118

35.158.206.190

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

CTI

XSP

TCP/TLS 8012

443

Webex Teams クライアントアプリ

XSI/DMS

任意

HTTPS

XSP

443

Webex Teams VoIP エンドポイント SIP

任意

[SIP]

SBC

SP 構成済み TCP

EMEA の出力ルール

(ネットワークからの出力)

目的

Source

プロトコル

移動先

移動先ポート

API を介したユーザープロビジョニング

アプリケーションサーバー

HTTPS

webexapis.com

443

プロキシプッシュ通知(本番サービス)

NPS サーバー

HTTPS

https://nps.uc-one.broadsoft.com/

または 34.64.0.0/10、35.208.0.0/12、35.224.0.0/12、35.240.0.0/13

443

Webex Common Identity

NPS サーバー

HTTPS

https://idbroker-eu.webex.com

443

APNS および FCM サービス

NPS サーバー

HTTPS

任意の IP アドレス*

443

プロキシプッシュ通知(本番サービス)

Webex Common Identity

APNS および FCM サービス

NPS サーバー

HTTPS

https://nps.uc-one.broadsoft.com/ *

https://idbroker-eu.webex.com

任意の IP アドレス*

443

BroadWorks プロビジョニングアダプタを介したユーザープロビジョニング

BroadWorks AS

HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(ここでは、* は任意の文字です。 正確なプロビジョニング URL は、パートナーハブで作成したテンプレートで利用できます)

443

† これらの範囲には NPS プロキシのホストが含まれていますが、正確なアドレスを指定することはできません。 範囲には、Webex for BroadWorks に関連しないホストも含まれる場合があります。 代わりに、NPS プロキシ FQDN へのトラフィックを許可するようファイアウォールを構成して、出力が NPS プロキシ用に公開しているホストにのみ向かうようにすることをお勧めします。

* APNS と FCM には固定の IP アドレスのセットがありません。

米国の入力ルール

(ネットワークへの入力)

目的

Source

プロトコル

移動先

移動先ポート

WebexCloud

CTI/Auth/XSI

13.58.232.148

18.217.166.80

18.221.216.175

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

CTI

XSP

TCP/TLS 8012

TLS 443

Webex Teams クライアントアプリ   

XSI/DMS

任意

HTTPS

XSP

443

Webex Teams VoIP エンドポイント SIP

任意

[SIP]

SBC

SP 構成済み TCP

米国の出力ルール

(ネットワークからの出力)

目的

Source

プロトコル

移動先

移動先ポート

API を介したユーザープロビジョニング

アプリケーションサーバー

HTTPS

webexapis.com

443

プロキシプッシュ通知(本番サービス)

NPS サーバー

HTTPS

https://nps.uc-one.broadsoft.com/

または 34.64.0.0/10、35.208.0.0/12、35.224.0.0/12、35.240.0.0/13

443

Webex Common Identity

NPS サーバー

HTTPS

https://idbroker.webex.com

443

APNS および FCM サービス

NPS サーバー

HTTPS

任意の IP アドレス*

443

BWKS プロビジョニングアダプタを介したユーザープロビジョニング

BroadWorks AS

HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(ここでは、* は任意の文字です。 正確なプロビジョニング URL は、パートナーハブで作成したテンプレートで利用できます)

443

† これらの範囲には NPS プロキシのホストが含まれていますが、正確なアドレスを指定することはできません。 範囲には、Webex for BroadWorks に関連しないホストも含まれる場合があります。 代わりに、NPS プロキシ FQDN へのトラフィックを許可するようファイアウォールを構成して、出力が NPS プロキシ用に公開しているホストにのみ向かうようにすることをお勧めします。

* APNS と FCM には固定の IP アドレスのセットがありません。

DNS 構成

Webex for BroadWorks クライアントは、認証、承認、通話制御、およびデバイス管理のために BroadWorks XSP サーバーを検出できる必要があります。

Webex クラウドは、XSI インターフェイスと認証サービスへの接続のために BroadWorks XSP サーバーを検出できる必要があります。

目的ごとに異なる XSP サーバーがある場合は、複数の DNS エントリを記録する必要がある場合があります。


Webex for BroadWorks で使用する XSP を解決するよう SRV レコードを設定することを強くお勧めします。 A/AAAA レコードのみを使用すると、XSP 間に不要な内部トラフィックが発生し、パフォーマンスが低下します。

Cisco Webex Cloud による XSP アドレスの発見方法

Cisco Webex Cloud サービスは、設定された XSP ホスト名の DNS A/AAAA ルックアップを実行し、返された IP アドレスに接続します。 これは、負荷分散エッジ要素である場合もあれば、XSP サーバー自体である場合もあります。 複数の IP アドレスが返される場合は、リストの最初のエントリが選択されます。

以下の例 2 および 3 は、それぞれ単一および複数の IP アドレスにマッピングされている A/AAAA レコードをキャプチャします。

複数の IP アドレスのシナリオでは、Webex からのクライアント接続を分散するために、ラウンドロビン方式でローテーションするよう DNS エントリを構成することをお勧めします。

クライアントによる XSP アドレスの発見方法

クライアントは、次の DNS フローを使用して XSP ノードを見つけようとします。

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

    1. クライアントは「_xsi-client._tcp.<xsi ドメイン>」のルックアップを実行します

      (次の例 1 を参照)

    2. SRV ルックアップが 1 つ以上のターゲットを返す場合:

      クライアントはそれらのターゲットの A/AAAA ルックアップを実行し、返された IP アドレスをキャッシュします。

      クライアントは、返された IP アドレスの 1 つで SRV ポートに接続します。 SRV の優先度に基づいてアドレスを選択し、重みを選択します(重みがすべて等しい場合はランダム)。

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

      クライアントは XSI ルートパラメータの A/AAAA ルックアップを実行してから、返された IP アドレスへの接続を試みます。 これは、負荷分散エッジ要素である場合もあれば、XSP サーバー自体である場合もあります。

      (次の例 2 および 3 を参照)

  2. (オプション)その後、次のタグを使用して、Webex Teams クライアントのデバイス構成でカスタム 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 レコードを作成してください。

DNS レコードの例

表 1. 例 1: 複数のインターネットに面した XSP サーバーのクライアント検出用 DNS SRV レコード

レコードタイプ

録画

ターゲット

目的

SRV

_xsi-client._tcp.your-xsp.example.com

xsp01.example.com

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

SRV

_xsi-client._tcp.your-xsp.example.com

xsp02.example.com

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

A

xsp01.example.com

198.51.100.48

XSP IP のルックアップ

A

xsp02.example.com

198.51.100.49

XSP IP のルックアップ

表 2. 例 2: XSP サーバープールに面したロードバランサ検出用の DNS A レコード

レコードタイプ

名前

ターゲット

目的

A

your-xsp.example.com

198.51.100.50

エッジロードバランサ IP のルックアップ

表 3. 例 3: ラウンドロビン方式バランスでインターネットに面した XSP サーバープールを検出するための DNS A レコード

レコードタイプ

名前

ターゲット

目的

A

your-xsp.example.com

198.51.100.48

XSP IP のルックアップ

A

your-xsp.example.com

198.51.100.49

XSP IP のルックアップ

XSP ノード DNS の推奨事項

  • 次の場合は単一の A/AAAA レコードを使用してください。

    • XSP サーバーへの負荷分散リバースプロキシを解決する必要がある場合

  • 次の場合はラウンドロビン A/AAAA レコードを使用してください。

    •  インターネットに面した XSP サーバーが複数ある場合

  • 次の場合は、DNS サービスディスカバリを使用する必要があります。

    • 複数の XSP がある環境でディレクトリ検索が必要な場合。

    • SRV 検出を必要とする既存の統合がある場合。

    • 標準の A/AAAA レコードでは不十分な独自の構成がある場合。