BroadWorks 版 Webex を導入する

展開の概要

次の図は、異なるユーザー プロビジョニング モードでの展開タスクの一般的な順番を示しています。 多くのタスクは、すべてのプロビジョニング モードで共通しています。

表 1. フロースルーのプロビジョニングを展開するために必要なタスク
フロースルー プロビジョニングおよび信頼済みメールによる BroadWorks 版 Webex の展開に必要なタスクの順序を示します
表 2. 信頼されたメールなしのフロースルー プロビジョニングを展開するために必要なタスク
メールなしのフロースルー プロビジョニングによる BroadWorks 版 Webex の展開に必要なタスクの順序を表示します
表 3. ユーザーのセルフプロビジョニングを展開するために必要なタスク
セルフアクティベーションによる BroadWorks 版 Webex の展開に必要なタスクの順序を表示します

BroadWorks 版 Cisco Webex のパートナーのオンボーディング

各 BroadWorks 版 Webex のサービス プロバイダまたは再販業者は、BroadWorks 版 Cisco Webex のパートナー組織としてセットアップする必要があります。 既存の Cisco Webex パートナー組織がある場合、これを使用できます。

必要なオンボーディングを完了するには、BroadWorks 版 Webex の書類処理を実行し、新しいパートナーはオンライン間接チャネル パートナー契約 (ICPA) を承認する必要があります。 これらの手順が完了すると、Cisco コンプライアンスは Partner Hub で新しいパートナー組織を作成し (必要な場合)、書類処理の記録の管理者に認証の詳細を記載したメールを送信します。 同時に、パートナー アクティベーションおよび/またはカスタマー サクセス プログラム マネージャから、オンボーディングを開始する連絡があります。

BroadWorks 版の Webex XSP 用にサービスを構成する

NPS アプリケーションを別の XSP で実行する必要があります。 XSP の要件については、「ネットワークからのコール通知を構成する」に記載されています。

お使いの XSP 上で以下のアプリケーション/サービスが必要です。

サービス/アプリケーション

認証が必要です

サービス/アプリケーションの目的

Xsi-Events

TLS (サーバーは自身をクライアントに対して認証します)

コール制御、サービス通知

Xsi-Actions

TLS (サーバーは自身をクライアントに対して認証します)

コール制御、アクション

デバイス管理

TLS (サーバーは自身をクライアントに対して認証します)

コール構成のダウンロード

認証サービス

TLS (サーバーは自身をクライアントに対して認証します)

ユーザー認証

コンピューター テレフォニーのインテグレーション

mTLS (クライアントとサーバーが互いに認証)

テレフォニーのプレゼンス

コール設定 Webview のアプリケーション

TLS (サーバーは自身をクライアントに対して認証します)

Webex アプリ内のセルフケア ポータルでユーザーのコール設定を露出します

このセクションでは、これらのインターフェイスで TLS と mTLS に必要な設定を適用する方法を説明しますが、既存のドキュメントを参照して、XSP にアプリケーションをインストールする必要があります。

共同レジデンシー要件

  • 認証サービスは Xsi アプリケーションと共同レジデンシーをもつ必要があります。これらのインターフェイスは、サービスの承認のために長期間トークンを受け入れる必要があります。 トークンを検証するには、認証サービスが必要です。

  • 認証サービスと Xsi は必要に応じて同じポートで実行できます。

  • スケールの必要に応じて、他のサービス/アプリケーションを分離することができます (例えば、専用デバイス管理 XSP ファーム)。

  • Xsi、CTI、認証サービスおよび DMS アプリケーションを共同で検索できます。

  • BroadWorks と Webex の統合に使用される XSP に、他のアプリケーションまたはサービスをインストールしなでください。

  • NPS アプリケーションを他のアプリケーションと共同で配置しないでください。

Xsi インターフェイス

Cisco BroadWorks Xtended Services Interface Configuration Guide の説明に従って、Xsi-Actions および Xsi-Events アプリケーションをインストールし、構成します。

認証サービスをインストールする

この手順を使用して、AuthServiceWithCTITokenValidation メソッドを使用して Cisco Webex とオンプレミスの BroadWorks 展開の間で認証を構成します。


この手順は、R22 以上を実行している場合にのみ適用されます。 R21SP1 を実行している場合、「XSP Authentication Service (R21SP1) をインストールする」を参照してください。
  1. オンボーディング連絡先または TAC を使用して、サービス リクエストを作成し、(Webex Common Identity) OAuth クライアント アカウントをプロビジョニングします。 サービス リクエスト「XSP AuthService Configuration」のタイトルを付けます。 Cisco は OAuth クライアント ID、クライアント シークレット、および 60 日間、有効な更新トークンを提供します。 XSP で使用する前にトークンの期限が切れた場合、別の要求を上げできます。

  2. 各 XSP サーバーに次のパッチをインストールします。 リリースに適切なパッチをインストールします。

    • R22 の場合:

      AP.platform.22.0.1123.ap376508

      AP.xsp.22.0.1123.ap376508

    • R23 の場合:

      AP.xsp.23.0.1075.ap376509

      AP.platform.23.0.1075.ap376509

    • R24 の場合—パッチは必要ありません

  3. 各 XSP サービスに AuthenticationService アプリケーションをインストールします。

    1. 次のコマンドを実行して、XSP 上の AuthenticationService アプリケーションを /authService コンテキスト パスにアクティベートします。

      XSP_CLI/Maintenance/ManagedObjects> activate application AuthenticationService 22.0_1.1123/authService
    2. このコマンドを実行して、XSP の AuthenticationService を展開します。

      XSP_CLI/Maintenance/ManagedObjects> deploy application /authServiceBroadWorks SW Manager deploying /authService...
  4. 各 XSP サーバーで次のコマンドを実行して、ID プロバイダを構成します。

    XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco> get

    • set enabled true

    • set clientId <client id>

    • set clientSecret <secret from TAC service request>

    • set issuerName https://idbroker.webex.com/idb

    • set issuerUrl https://idbroker.webex.com/idb

    • set tokenInfoUrl <IdPProxy URL from Control Hub>

    • set ciResponseBodyMaxSizeInBytes 65536

  5. 次のコマンドを実行して、Webex のシステムでユーザー プロファイル必要な Webex エンタイトルメントを指定します。

    XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco/Scopes> set scope broadworks-connector:user

  6. 各 XSP サーバーで次のコマンドを実行して、Cisco Federation の ID プロバイダを構成します。

    XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco/Federation> get

    • set flsUrl https://cifls.webex.com/federation

    • set refreshPeriodInMinutes 1440

    • set refreshToken <token from service request>

  7. 各 XSP サーバーで次のコマンドを実行して、Token Management を構成します。

    • XSP_CLI/Applications/AuthenticationService/TokenManagement>

    • set tokenIssuer BroadWorks

    • set tokenDurationInHours 720

  8. Generate and Share RSA Keys. 1 つの XSP で鍵を生成し、それを他のすべての XSP にコピーする必要があります。 これは次の要因による影響です。

    • 認証サービスのすべてのインスタンスで、トークンの暗号化/暗号解除に同じ公開/秘密鍵のペアを使用する必要があります。

    • 鍵ペアは、トークンを発行するために最初に必要な認証サービスにより生成されます。


    鍵をサイクルするか、鍵の長さを変更する場合、次の構成を繰り返し、すべての XSP を再起動する必要があります。
    1. 鍵ペアを生成するために使用する XSP を 1 つ選択します。

    2. クライアントを使用して、クライアントのブラウザーから次の URL を要求することで、XSP から暗号化されたトークンを要求します。

      https://<XSP-IPAddress>/authService/token?key=BASE64URL(clientPublicKey)

      (まだ作成していない場合、XSP で秘密/公開鍵ペアを生成します)

    3. 鍵ストアのロケーションは構成できません。 鍵をエクスポートします。

      XSP_CLI/Applications/authenticationService/KeyManagement> exportKeys

    4. エクスポートしたファイル /var/broadworks/tmp/authService.keys を他の XSP の同じロケーションにコピーし、必要に応じて古い .keys ファイルを上書きします。

    5. 他の XSP のそれぞれの鍵をインポートします。

      XSP_CLI/Applications/authenticationService/KeyManagement> importKeys /var/broadworks/tmp/authService.keys

  9. ウェブ コンテナに authService URL を提供します。 XSP のウェブ コンテナはトークンを検証するために、authService URL が必要です。 各 XSP について:

    1. 次のように、認証サービス URL を BroadWorks Communications ユーティリティの外部認証サービスとして追加します。

      XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/AuthService> set url http://127.0.0.1/authService

    2. 次のように、コンテナに認証サービス URL を追加します。

      XSP_CLI/Maintenance/ContainerOptions> add tomcat bw.authservice.authServiceUrl http://127.0.0.1/authService

      これにより、Cisco Webex で認証サービスを使用して、資格情報として提示されたトークンを検証できます。

    3. パラメーターを get で確認してください。

    4. XSP を再起動します。

HTTP インターフェイスでの TLS および暗号の設定 (XSI および認証サービス)

認証サービス、Xsi-Actions、および Xsi-Events アプリケーションは、HTTP サーバー インターフェイスを使用します。 これらのアプリケーションの TLS 設定可能性のレベルは以下の通りです。

最も一般的 = System > Transport > HTTP > HTTP サーバー インターフェイス = 最も具体的

異なる SSL 設定を表示または変更するために使用する CLI コンテキストは、次のとおりです。

具体性 CLI コンテキスト
システム (グローバル)

XSP_CLI/System/SSLCommonSettings/JSSE/Ciphers>

XSP_CLI/System/SSLCommonSettings/JSSE/Protocols>

このシステムの転送プロトコル

XSP_CLI/System/SSLCommonSettings/OpenSSL/Ciphers>

XSP_CLI/System/SSLCommonSettings/OpenSSL/Protocols>

このシステム上の HTTP

XSP_CLI/Interface/Http/SSLCommonSettings/Ciphers>

XSP_CLI/Interface/Http/SSLCommonSettings/Protocols>

このシステム上の特定の HTTP サーバー インターフェイス

XSP_CLI/Interface/Http/HttpServer/SSLSettings/Ciphers>

XSP_CLI/Interface/Http/HttpServer/SSLSettings/Protocols>

XSP で HTTP Server TLS インターフェイス構成を読み取る

  1. XSP にサインインし、XSP_CLI/Interface/Http/HttpServer> にナビゲートします

  2. get コマンドを入力し、結果を読み取ります。 インターフェイス (IP アドレス) と、それぞれの インターフェイスがセキュアかどうか、およびクライアント認証が必要かどうか確認する必要があります。

Apache tomcat は各セキュアインターフェイスに証明書を要求しています。必要な場合、システムは自己署名証明書を生成してください。


  XSP_CLI/Interface/Http/HttpServer> get

TLS 1.2 プロトコルを HTTP サーバー インターフェイスに追加する


この操作は R22 以降が対象です。 R21(SP1) で TLS バージョンを設定するには、XSP プラットフォーム コンテナ オプション bw.apache.sslenabledprotocols を使用する必要があります。

Cisco Webex クラウドと対話する HTTP インターフェイスは、TLSv1.2 に構成する必要があります。 クラウドは以前のバージョンの TLS プロトコルをネゴシエートしません。

HTTP Server インターフェイスで TLSv1.2 プロトコルを構成するには:

  1. XSP にサインインし、XSP_CLI/Interface/Http/HttpServer/SSLSettings/Protocols> にナビゲートします

  2. コマンド get <interfaceIp> 443 を入力して、このインターフェイスですでに使用されているプロトコルを確認します。

  3. コマンド add <interfaceIp> 443 TLSv1.2 を入力して、インターフェイスがクラウドとの通信時に TLS 1.2 を使用できるよう確認します。

TLS 暗号化構成の HTTP サーバー インターフェイスでの編集


この操作は R22 以降が対象です。 R21(SP1) で TLS 暗号を構成するには、XSP プラットフォーム コンテナ オプション bw.apache.sslciphersuite を使用する必要があります。

必要な暗号を設定するには:

  1. XSP にサインインし、XSP_CLI/Interface/Http/HttpServer/SSLSettings/Ciphers> にナビゲートします

  2. コマンド get <interfaceIp> 443 を入力して、このインターフェイスですでに使用されている暗号を確認します。 Cisco が推奨するスイートから少なくとも 1 つ存在する必要があります (概要セクションの 「XSP アイデンティティおよびセキュリティ要件 」を参照してください)。

  3. コマンド add <interfaceIp> 443 <cipherName> を入力して、HTTP Server インターフェイスに暗号を追加します。


    XSP CLI では、openSSL 暗号スイート名ではなく、IANA 標準暗号スイート名を必要とします。 たとえば、HTTP サーバー インターフェイスに openSSL cipher ECDHE-ECDSA-CHACHA20-POLY1305 を追加するには、次を使用します。 XSP_CLI/Interface/Http/HttpServer/SSLSettings/Ciphers>add 192.0.2.7 443 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

    いずれかの名前によりスイートを検索する方法については、「https://ciphersuite.info/」を参照してください。

AuthenticationService の mTLS を構成する

信頼 (R21 SP1) の構成
  1. Partner Hub にサインインします。

  2. [設定] > [BroadWorks Calling] にアクセスし、[Webex CA 証明書のダウンロード] をクリックして、ローカル コンピューターで CombinedCertChain.txt を取得します。


    このファイルには 2 つの証明書が含まれています。 ファイルを XSP にアップロードする前に、ファイルを分割する必要があります。
  3. 証明書チェーンを 2 つの証明書に分割します。

    1. テキスト エディターで combinedcertchain.txt を開きます。

    2. -----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----を含むテキストの最初のブロックを切り取り、そのテキスト ブロックを新しいファイルに貼り付けます。

    3. 新規ファイルを broadcloudroot.txt として保存します。

    4. 元のファイルを broadcloudissuing.txt として保存します。

      元のファイルは行 -----BEGIN CERTIFICATE----------ENDCERTIFICATE----- で囲まれた 1 つのブロックのテキストのみをもつはずです。

  4. セキュリティを設定している XSP の一時ロケーションに両方のテキスト ファイルをコピーします。例: /tmp/broadcloudroot.txt および /tmp/broadcloudissuing.txt.

  5. XSP にサインインし、/XSP_CLI/Interface/Http/ClientAuthentication> にナビゲートします

  6. get コマンドを入力し、chainDepth パラメータを読み取ります。

    (chainDepth はデフォルトで 1 です。2 つの証明書がある Webex チェーンでは低すぎます)

  7. chainDepth がまだ 2 より大きくない場合、set chainDepth 2 を実行します。

  8. (オプション) help updateTrust を実行して、パラメータとコマンド形式を確認してください。

  9. 証明書ファイルを新しい信頼アンカーにアップロードします:

    XSP_CLI/Interface/Http/ClientAuthentication/Trusts> updateTrust webexclientroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/Http/ClientAuthentication/Trusts> updateTrust webexclientissuing /tmp/broadcloudissuing.txt


    webexclientroot および webexclientissuing は、信頼アンカーのサンプル エイリアスです。自分のエイリアスを使用できます。
  10. 両方の証明書がアップロードされているのを確認します。

    /XSP_CLI/Interface/Http/ClientAuthentication/Trusts> get

信頼 (R22 以降) の構成

  1. パートナー管理者アカウントを使って Control Hub にサインインします。

  2. [設定] > [BroadWorks Calling] にアクセスし、[Webex CA 証明書のダウンロード] をクリックして、ローカル コンピューターで CombinedCertChain.txt を取得します。


    このファイルには 2 つの証明書が含まれています。 ファイルを XSP にアップロードする前に、ファイルを分割する必要があります。
  3. 証明書チェーンを 2 つの証明書に分割します。

    1. テキスト エディターで combinedcertchain.txt を開きます。

    2. -----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----を含むテキストの最初のブロックを切り取り、そのテキスト ブロックを新しいファイルに貼り付けます。

    3. 新規ファイルを broadcloudroot.txt として保存します。

    4. 元のファイルを broadcloudissuing.txt として保存します。

      元のファイルは行 -----BEGIN CERTIFICATE----------ENDCERTIFICATE----- で囲まれた 1 つのブロックのテキストのみをもつはずです。

  4. セキュリティを設定している XSP の一時ロケーションに両方のテキスト ファイルをコピーします。例: /tmp/broadcloudroot.txt および /tmp/broadcloudissuing.txt.

  5. (オプション) help UpdateTrust を実行して、パラメータとコマンド形式を確認してください。

  6. 証明書ファイルを新しい信頼アンカーにアップロードします:

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientissuing /tmp/broadcloudissuing.txt


    webexclientroot および webexclientissuing は、信頼アンカーのサンプル エイリアスです。自分のエイリアスを使用できます。
  7. アンカーが更新されるのを確認します。

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> get

     Alias Owner Issuer ============================================================================= webexclientissuing BroadCloud Commercial Issuing CA – DA3 BroadCloud Commercial Trusted Root CA webexclientroot BroadCloud Commercial Trusted Root CA BroadCloud Commercial Trusted Root CA[self-signed]

(オプション) HTTP インターフェイス/ポート レベルで mTLS を構成します

HTTP インターフェイス/ポート レベルで、またはウェブ アプリケーションごとに mTLS を構成することができます。

アプリケーションで mTLS を有効にする方法は、XSP にホストしているアプリケーションによって異なります。 mTLS を必要とする複数のアプリケーションをホストしている場合、インターフェイスで mTLS を有効にする必要があります。 同じ HTTP インターフェイスを使用する複数のアプリケーションの 1 つのみをセキュアにする必要がある場合、アプリケーション レベルで mTLS を構成できます。

HTTP インターフェイス/ポート レベルで mTLS を設定する場合、mTLS は、このインターフェイス/ポート経由でアクセスされるすべてのホストされたウェブ アプリケーションに必要です。

  1. 構成しているインターフェイスを持つ XSP にサインインします。

  2. XSP_CLI/Interface/Http/HttpServer> に移動して、get コマンドを実行してインターフェイスを確認します。

  3. インターフェイスを追加し、そこにクライアント認証を要求するには (つまり mTLS と同じ意味です):

    XSP_CLI/Interface/Http/HttpServer> add IPAddress Port Name true true

    詳細については、XSP CLI のドキュメントを参照してください。 基本的に、最初の true は TLS のインターフェイスをセキュアにします (サーバー証明書が必要な場合は作成されます)、2 番目の true はインターフェイスにクライアント証明書の認証を要求します (それらは共に mTLS です)。

例:

XSP_CLI/Interface/Http/HttpServer> get

Interface Port Name Secure Client Auth Req Cluster Fqdn ======================================================= 192.0.2.7 443 xsp01.collab.example.net true false 192.0.2.7 444 xsp01.collab.example.net true true

この例では、mTLS (Client Auth Req = true) が 192.0.2.7 ポート 444 で有効 になっています。 TLS は 192.0.2.7 ポート 443 で有効になっています。

(オプション) 特定のウェブ アプリケーションに mTLS を構成する

HTTP インターフェイス/ポート レベルで、またはウェブ アプリケーションごとに mTLS を構成することができます。

アプリケーションで mTLS を有効にする方法は、XSP にホストしているアプリケーションによって異なります。 mTLS を必要とする複数のアプリケーションをホストしている場合、インターフェイスで mTLS を有効にする必要があります。 同じ HTTP インターフェイスを使用する複数のアプリケーションの 1 つのみをセキュアにする必要がある場合、アプリケーション レベルで mTLS を構成できます。

アプリケーション レベルで mTLS を構成するとき、HTTP サーバー インターフェイス構成に関係なく、mTLS がアプリケーションに必要です。

  1. 構成しているインターフェイスを持つ XSP にサインインします。

  2. XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> に移動して、get コマンドを実行して、実行されているアプリケーションを確認します。

  3. アプリケーションを追加し、クライアント認証を要求するには (つまり mTLS と同じ意味です):

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> add IPAddress Port ApplicationName true

    詳細については、XSP CLI のドキュメントを参照してください。 アプリケーション名はそこで列挙されます。 このコマンドの true が mTLS を有効にします。

例:

XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> add 192.0.2.7 443 AuthenticationService true

この例のコマンドは、AuthenticationService アプリケーションを 192.0.2.7:443 に追加し、クライアントからの証明書を要求し、認証する必要があります。

Get で確認します。

XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> get

Interface Ip Port Application Name Client Auth Req =================================================== 192.0.2.7 443 AuthenticationService true 

XSP、アプリケーション サーバー、プロファイル サーバーでデバイス管理を構成する

プロファイル サーバーと XSP はデバイス管理に必須です。 「BroadWorksデバイス管理構成ガイド」 (https://xchange.broadsoft.com/node/1031995) の指示に従って構成する必要があります。

CTI インターフェイスと関連する構成

「最も内側から最も外側へ」の構成順が以下に表示されます。 この順序に従うことは必須ではありません。

  1. CTI サブスクリプションに対するアプリケーションサーバーを構成する

  2. mTLS 認証済み CTI サブスクリプションの XSP を構する

  3. セキュアな CTI インターフェイスのために受信ポートを開く

  4. Webex 組織を BroadWorks CTI Events にサブスクライブする

CTI サブスクリプションに対するアプリケーションサーバーを構成する

クライアント証明書の共通名 (CN) でアプリケーション サーバーの ClientIdentity を更新します。 TLS ブリッジング プロキシを使用している場合、それはプロキシが XSP に提示する内部署名証明書の CN です。 それ以外の場合、BroadWorks CTI クライアント証明書の Webex の CN です。

Webex と共に使用する各アプリケーション サーバーに対して、以下のように証明書 ID を ClientIdentity に追加します。

AS_CLI/System/ClientIdentity> add bwcticlient.webex.com


BroadWorks 版 Webex クライアント証明書の共通名は、bwcticlient.webex.com です。

CTI インターフェイスで TLS と暗号を構成する

XSP CTI インターフェイスの構成可能性のレベルは、以下の通りです。

最も一般的 = System > Transport > CTI インターフェイス > CTI インターフェイス = 最も具体的

異なる SSL 設定を表示または変更するために使用する CLI コンテキストは、次のとおりです。

具体性

CLI コンテキスト

システム (グローバル)

(R22 以降)

XSP_CLI/System/SSLCommonSettings/JSSE/Ciphers>

XSP_CLI/System/SSLCommonSettings/JSSE/Protocols>

このシステムの転送プロトコル

(R22 以降)

XSP_CLI/System/SSLCommonSettings/OpenSSL/Ciphers>

XSP_CLI/System/SSLCommonSettings/OpenSSL/Protocols>

このシステム上のすべての CTI インターフェイス

(R22 以降)

XSP_CLI/Interface/CTI/SSLCommonSettings/Ciphers>

XSP_CLI/Interface/CTI/SSLCommonSettings/Protocols>

このシステム上の特定の CTI インターフェイス

(R22 以降)

XSP_CLI/Interface/CTI/SSLSettings/Ciphers>

XSP_CLI/Interface/CTI/SSLSettings/Protocols>

Reading CTI TLS Interface Configuration on the XSP

  1. XSP にサインインし、XSP_CLI/Interface/CTI/SSLSettings> にナビゲートします

    BroadWorks R21 の場合: navigate to XSP_CLI/Interface/CTI/SSLConfiguration>

  2. get コマンドを入力し、結果を読み取ります。 インターフェイス (IP アドレス) と、それぞれに対して、サーバー証明書を必要とするかどうか、およびクライアント認証が必要かどうか確認する必要があります。

TLS 1.2 プロトコルを CTI インターフェイスに追加する


この操作は R22 以降が対象です。 R21(SP1) の CTI インターフェイスで TLS バージョンを構成するには、 tomcat コンテナ オプション bw.cti.sslenabledprotocols を使用する必要があります。

Cisco Webex クラウドと対話する XSP CTI インターフェイスは、TLS v1.2 に対して構成する必要があります。 クラウドは以前のバージョンの TLS プロトコルをネゴシエートしません。

CTI インターフェイスで TLSv1.2 プロトコルを構成するには:

  1. XSP にサインインし、XSP_CLI/Interface/CTI/SSLSettings/Protocols> にナビゲートします

  2. コマンド get <interfaceIp> を入力して、このインターフェイスですでに使用されているプロトコルを確認します。

  3. コマンド add <interfaceIp> TLSv1.2 を入力して、インターフェイスがクラウドとの通信時に TLS 1.2 を使用できることを確認します。

TLS 暗号構成の HTTP インターフェイスでの編集


この操作は R22 以降が対象です。 R21(SP1) の CTI インターフェイスで TLS バージョンを構成するには、 tomcat コンテナ オプション bw.cti.enabledciphers を使用する必要があります。

CTI インターフェイスで必要な暗号を構成するには:

  1. XSP にサインインし、XSP_CLI/Interface/CTI/SSLSettings/Ciphers> にナビゲートします

  2. コマンド get を入力して、このインターフェイスですでに使用されている暗号を確認します。 Cisco が推奨するスイートから少なくとも 1 つ存在する必要があります (概要セクションの 「XSP アイデンティティおよびセキュリティ要件 」を参照してください)。

  3. コマンド add <interfaceIp> <cipherName> を入力して、CTI インターフェイスに暗号を追加します。


    XSP CLI では、openSSL 暗号スイート名ではなく、IANA 標準暗号スイート名を必要とします。 たとえば、CTI インターフェイスに openSSL 暗号 ECDHE-ECDSA-CHACHA20-POLY1305 を追加するには、次を使用します。 XSP_CLI/Interface/CTI/SSLSettings/Ciphers> add 192.0.2.7 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

    いずれかの名前によりスイートを検索する方法については、「https://ciphersuite.info/」を参照してください。

CTI インターフェイスの信頼アンカーを更新する (R22 以降)

この手順は、XSP がインターネットに接続されている、またはパススルー プロキシ経由でインターネットに接している必要があります。 証明書の構成はブリッジ プロキシとは異なります (「TLS ブリッジ プロキシの TLS 証明書要件」を参照してください)。

CTI イベントを Webex に公開しているインフラストラクチャの各 XSP の場合、次の手順に従います。

  1. Partner Hub にサインインします。

  2. [設定] > [BroadWorks Calling] にアクセスし、[Webex CA 証明書のダウンロード] をクリックして、ローカル コンピューターで CombinedCertChain.txt を取得します。


    このファイルには 2 つの証明書が含まれています。 ファイルを XSP にアップロードする前に、ファイルを分割する必要があります。

  3. 証明書チェーンを 2 つの証明書に分割します。

    1. テキスト エディターで combinedcertchain.txt を開きます。

    2. -----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----を含むテキストの最初のブロックを切り取り、そのテキスト ブロックを新しいファイルに貼り付けます。

    3. 新規ファイルを broadcloudroot.txt として保存します。

    4. 元のファイルを broadcloudissuing.txt として保存します。

      元のファイルは行 -----BEGIN CERTIFICATE----------ENDCERTIFICATE----- で囲まれた 1 つのブロックのテキストのみをもつはずです。

  4. セキュリティを設定している XSP の一時ロケーションに両方のテキスト ファイルをコピーします。例: /tmp/broadcloudroot.txt および /tmp/broadcloudissuing.txt.

  5. XSP にサインインし、/XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts> にナビゲートします

  6. (オプション) help updateTrust を実行して、パラメータとコマンド形式を確認してください。

  7. 証明書ファイルを新しい信頼アンカーにアップロードします:

    XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexissuing /tmp/broadcloudissuing.txt


    webexroot および webexissuing は、信頼アンカーのサンプル エイリアスです。自分のエイリアスを使用できます。

  8. アンカーが更新されるのを確認します。

    XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts> get

     Alias Owner Issuer ============================================================================= webexissuing BroadCloud Commercial Issuing CA – DA3 BroadCloud Commercial Trusted Root CA webexroot BroadCloud Commercial Trusted Root CA BroadCloud Commercial Trusted Root CA[self-signed]
  9. クライアントの証明書を使った認証を許可する:

    
      XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication> set allowClientApp true

CTI インターフェイスの信頼アンカーを更新する (R21)

この手順は、XSP がインターネットに接続されている、またはパススルー プロキシ経由でインターネットに接している必要があります。 証明書の構成はブリッジ プロキシとは異なります (「TLS ブリッジ プロキシの TLS 証明書要件」を参照してください)。

CTI イベントを Webex に公開しているインフラストラクチャの各 XSP の場合、次の手順に従います。

  1. Partner Hub にサインインします。

  2. [設定] > [BroadWorks Calling] にアクセスし、[Webex CA 証明書のダウンロード] をクリックして、ローカル コンピューターで CombinedCertChain.txt を取得します。


    このファイルには 2 つの証明書が含まれています。 ファイルを XSP にアップロードする前に、ファイルを分割する必要があります。

  3. 証明書チェーンを 2 つの証明書に分割します。

    1. テキスト エディターで combinedcertchain.txt を開きます。

    2. -----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----を含むテキストの最初のブロックを切り取り、そのテキスト ブロックを新しいファイルに貼り付けます。

    3. 新規ファイルを broadcloudroot.txt として保存します。

    4. 元のファイルを broadcloudissuing.txt として保存します。

      元のファイルは行 -----BEGIN CERTIFICATE----------ENDCERTIFICATE----- で囲まれた 1 つのブロックのテキストのみをもつはずです。

  4. セキュリティを設定している XSP の一時ロケーションに両方のテキスト ファイルをコピーします。例: /tmp/broadcloudroot.txt および /tmp/broadcloudissuing.txt.

  5. XSP にサインインし、/XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts> にナビゲートします

  6. (オプション) help updateTrust を実行して、パラメータとコマンド形式を確認してください。

  7. 新しい信頼アンカーが証明書で更新されます。

    /XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts> updateTrust webexroot /tmp/broadcloudroot.txt

    /XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts> updateTrust webexissuing /tmp/broadcloudissuing.txt

    (「webexroot」および「webexissuing」は、信頼アンカーのサンプル エイリアスで、自分のものを選択できます)

  8. 両方の証明書がアップロードされているのを確認します。

    /XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts> get

    XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts> get Alias Owner Issuer =========================================================================================================== webexissuing BroadCloud Commercial Issuing CA - DA3 BroadCloud Commercial Trusted Root CA webexroot BroadCloud Commercial Trusted Root CA BroadCloud Commercial Trusted Root CA[self-signed]
  9. クライアントの証明書を使った認証を許可する:

    
      XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication> set allowClientApp true

CTI インターフェイスを追加し、mTLS を有効にする

  1. CTI SSL インターフェイスを追加します。

    CLI コンテキストは、BroadWorks バージョンに依存します。 コマンドはインターフェイスに自己署名サーバー証明書を作成し、インターフェイスにクライアント証明書が必要な必要があります。

    • BroadWorks 22 および 23.0 の場合:

      XSP_CLI/Interface/CTI/SSLSettings> add <Interface IP> true true

    • BroadWorks 21.sp1 の場合:

      XSP_CLI/Interface/CTI/SSLConfiguration> add <Interface IP> true true

  2. XSP のセキュアな CTI ポートを有効にして定義します。

    XSP_CLI/Interface/CTI> set securePortEnabled true

    XSP_CLI/Interface/CTI> set securePort 8012

  3. XSP の CTI インターフェイスでサーバー証明書と鍵を置き換えます。 この場合、CTI インターフェイスの IP アドレスが必要です。次のコンテキストから読み取るできます。

    • BroadWorks 22 および 23.0 の場合:

      XSP_CLI/Interface/CTI/SSLSettings> get

    • BroadWorks 21.sp1 の場合:

      XSP_CLI/Interface/CTI/SSLConfiguration> get

      次に、以下のコマンドを実行して、インターフェイスの自己署名証明書を独自の証明書と秘密鍵に置き換わります。

      BroadWorks 22.0 および 23.0 の場合:

      XSP_CLI/Interface/CTI/SSLSettings/Certificates> sslUpdate <interface IP> keyFile </path/to/certificate key file>

      XSP_CLI/Interface/CTI/SSLSettings/Certificates> sslUpdate <interface IP> certificateFile </path/to/server certificate>

      BroadWorks 21.sp1 の場合:

      XSP_CLI/Interface/CTI/SSLConfiguration> sslUpdate <interface IP> keyFile </path/to/certificate key file>

      XSP_CLI/Interface/CTI/SSLConfiguration> sslUpdate <interface IP> certificateFile </path/to/server certificate>

  4. XSP を再起動します。

セキュアな CTI インターフェイスのために受信ポートを開く

XSP CTI インターフェイスへのインバウンド TLS 接続のファイアウォール (デフォルトでは TCP 8012) で CTI のセキュアポートを開きます。

セキュア ポートが有効であり、ポート番号をチェックするには:

  1. XSP CLI にサインインし、XSP_CLI/Interface/CTI> コンテキストにナビゲートします。

  2. get と入力します。

その他の情報の中には、以下が表示されます。

securePortEnabled = true

securePort = 8012

これにより、Webex が暗号化された接続を開始できます。

Webex はセキュアなポートのみを使用するため、セキュアでないポートを無効にするには、portEnabled = false を設定することを推奨します。

Cisco Webex で BroadWorks CTI Events へのアクセスを有効にする

Partner Hub でクラスターを構成するときに、CTI インターフェイスを追加し、検証する必要があります。 詳細については、「Control Hub でパートナー組織を構成する」を参照してください。

  • Cisco Webex が BroadWorks CTI Events をサブスクライブすることができる CTI アドレスを指定します。

  • CTI サブスクリプションはサブスクライバーベースごとに、BroadWorks 版 Webex のサブスクライバーがプロビジョニングされている間にのみ確立および維持されます。

コール設定 Webview

コール設定 Webview (CSWV) は、XSP (または ADP) でホストされるアプリケーションで、ユーザーがソフト クライアントで表示される Webview を通して、BroadWorks コール設定を変更することができます。 https://xchange.broadsoft.com/node/1050149 に詳細な CSWV ソリューション ガイドがあります。

Webex ではこの機能を利用して、ユーザーが Webex アプリからネイティブではない共通の BroadWorks コール設定にアクセスできます。

BroadWorks 版 Webex のサブスクライバーが Webex アプリで利用可能なデフォルトを超えてコール設定にアクセスするには、コール設定 Webview 機能を展開する必要があります。

コール設定 Webview には 2 つのコンポーネントがあります。

  • Cisco BroadWorks XSP (または ADP) でホストされるコール設定 Webview アプリケーション。

  • Webex アプリ。Webview でコール設定をレンダリングします。

ユーザーエクスペリエンス

  • Windows ユーザーの場合: プロファイル画像をクリックし、[設定] > [Calling] > [セルフ ケア] を選択します。

  • Mac ユーザーの場合 プロファイル画像をクリックし、[基本設定] > [Calling] > [セルフ ケア] を選択します。

BroadWorks で CSWV を展開する

XSP にコール設定をインストールする

CSWV アプリケーションは、お使いの環境で Xsi-Actions インターフェイスをホストするのと同じ XSP 上にある必要があります。 XSP の管理されていないアプリケーションなので、ウェブ アーカイブ ファイルをインストールして展開する必要があります。

  1. Xchange にサインインし、ソフトウェア ダウンロード セクションで「BWCallSettingsWeb」を検索します。

  2. ファイルの最新バージョンを見つけてダウンロードします。

    例えば、BWCallSettingsWeb_1.7.5_1.war (https://xchange.broadsoft.com/node/1054451) は、書き込み時に最近でした。

  3. お使いの XSP バージョンの Xtended Service Platform Configuration Guide に従ってウェブ アーカイブをインストール、アクティベート、展開します。 (R23 バージョンは https://xchange.broadsoft.com/node/1033484です)。

    1. .war ファイルを /tmp/ など XSP の一時的な場所にコピーします。。

    2. 次の CLI コンテキストに移動し、インストール コマンドを実行します。

      XSP_CLI/Maintenance/ManagedObjects> install application /tmp/BWCallSettingsWeb_1.7.5_1.war

      BroadWorks ソフトウェア マネージャがファイルの検証とインストールを行います。

    3. [オプション] /tmp/BWCallSettingsWeb_1.7.5_1.war (このファイルは必要なくなりました) を削除します。

    4. アプリケーションをアクティベートにする:

      XSP_CLI/Maintenance/ManagedObjects> activate application BWCallSettingsWeb 1.7.5 /callsettings

      どのアプリケーションにも nameversion は必須ですが、CSWV の場合は、管理対象ではないアプリケーションなので contextPath も提供する必要があります。 /callsettings など、別のアプリケーションで使用されていない値を使用することができます。

    5. 選択したコンテキスト パスに、コール設定アプリケーションを展開します。

      XSP_CLI/Maintenance/ManagedObjects> は application /callsettings を展開します

  4. クライアントに指定するコール設定 URL を、次のように予測できます。

    https://<XSP-FQDN>/callsettings/

    注意:

    • クライアント構成ファイルに入力する際に、この URL の末尾のスラッシュに指定する必要があります。

    • CSWV は Xsi-Actions を使用する必要があり、CORS はサポートされていないので、XSP-FQDN は Xsi-Actions FQDN と一致する必要があります。

  5. BroadWorks 版 Webex 環境でその他の XSP に対してこの手順を繰り返します (必要な場合)

コール設定 Webview アプリケーションは、XSP でアクティブになりました。

XSP R21 の追加構成

R21 XSP で CSWV アプリケーションを展開する場合:

  1. コール設定アプリケーション コンテキストにナビゲートし、get を実行して、構成を読み取ります。 XSP_CLI/Applications/BWCallSettingsWeb_1.7.5/General> get

    以下のパラメーターと値が表示されます。

    xsiActionsContextOrURL=/com.broadsoft.xsi-actions displayCriteriaOrScheduleName=criteria applicationMode=prod 
  2. set (必要な場合) を使用して、パラメーターを上記の値に変更します。

  3. 必要な場合は、その他の R21 XSP に対して繰り返します。

コール設定 Webview を使用するために Webex アプリを構成する

クライアント構成の詳細については、Webex アプリ バージョンの Xchange の「BroadWorks クライアント構成ガイドの Webex アプリ」を参照してください。 例えば、このファイルの 2020 年 9 月のバージョンは、https://xchange.broadsoft.com/node/1054075 にあります

CSWV URL を設定するために使用できる Webex アプリ構成ファイルにカスタム タグがあります。 この URL は、アプリケーションのインターフェイスを通じてユーザーにコール設定を表示します。

<config>
    <services>
        <web-call-settings target="%WEB_CALL_SETTINGS_TARGET_WXT%">
            <url>%WEB_CALL_SETTINGS_URL_WXT%</url>
        </web-call-settings>

BroadWorks の Webex アプリ構成テンプレートの %WEB_CALL_SETTINGS_URL_WXT% タグで CSWV URL を構成します。

URL を明示的に指定しない場合、デフォルトは空で、コール設定ページはユーザーには表示されません。

  1. Webex アプリの最新の構成テンプレートを持っている必要があります (デバイス プロファイル を参照してください)。

  2. ウェブ コール設定ターゲットを csw に設定します。

    %WEB_CALL_SETTINGS_TARGET_WXT% csw

  3. お使いの環境に Web コール設定 URL を設定します。例:

    %WEB_CALL_SETTINGS_URL_WXT% https://yourxsp.example.com/callsettings/

    (CSWV アプリケーションを展開する際にこの値を導き出しました)

  4. 結果のクライアント構成ファイルは、次のようにエントリする必要があります。
    <web-call-settings target="csw">
        <url>https://yourxsp.example.com/callsettings/</url>
    </web-call-settings>

BroadWorks 版 Webex でコール プッシュ通知を設定する

この文書では、コール通知プッシュ サーバー (CNPS) という用語を使用して、環境で動作する XSP がホストする、または ADP がホストするアプリケーションを説明します。 CNPS は BroadWorks システムと機能し、ユーザーへの着信コールを認識し、Google Firebase Cloud Messaging (FCM) または Apple Push Notification Service (APN) 通知サービスに通知をプッシュします。

これらのサービスは、BroadWorks 版 Webex のサブスクライバが Webex での着信コールの通知をモバイルデバイスに送信します。

NPS の詳細については、 ページの「通知プッシュサーバー機能の説明」を https://xchange.broadsoft.com/node/485737 で参照してください。

Webex の同様のメカニズムは、Webex メッセージングとプレゼンス サービスで動作し、Google (FCM) または Apple (APNS) 通知サービスに通知をプッシュします。 これらのサービスは、モバイル版の Webex ユーザーに着信メッセージまたはプレゼンス変更を通知します。


このセクションでは、NPS が他のアプリをまだサポートしていない場合に、NPS を認証プロキシのために設定する方法について説明します。 NPS プロキシを使用するために共有 NPS を移行する必要がある場合、「Cisco BroadWorks NPS を NPS プロキシ を使用するために更新するhttps://help.webex.com/nl5rir2/」を参照してください。

NPS プロキシの概要

BroadWorks 版 Webex との互換性のために、CNPS は NPS プロキシ機能、UCaaS で VoIP のプッシュ サーバーをサポートするために、パッチされる必要があります。

この機能は、通知プッシュ サーバーの新しい設計を実装して、モバイル クライアントのサービス プロバイダとプッシュ通知証明書の秘密鍵を共有するセキュリティ上の脆弱性を解決します。 NPS は、プッシュ通知証明書と鍵をサービス プロバイダと共有する代わりに、新しい API を使用して、短期間プッシュ通知トークンを BroadWorks 版 Webex のバックエンドから取得し、このトークンを Apple APN および Google FCM サービスを使用した認証に使用します。

この機能により、通知プッシュ サーバーが新しい Google Firebase Cloud Messaging (FCM) HTTPv1 API 経由で Android デバイスにプッシュ通知する機能も強化されています。

BroadWorks 版 Webex の NPS を準備する

1

専用 XSP (最小バージョン R22)、または Application Delivery Platform (ADP) をインストールおよび構成します。

2

NPS Authentication Proxy パッチをインストールします。

XSP R22 パッチ:

XSP R23 パッチ:

3

通知プッシュサーバーアプリケーションを有効にします。

4

(Android 通知の場合) NPS の FCM v1 API を有効にします。

XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true

5

(Apple iOS 通知) NPS で HTTP/2 を有効にします。

XSP_CLI/Applications/NotificationPushServer/APNS/GeneralSettings> set HTTP2Enabled true

6

NPS XSP/ADP から技術サポートに接続します。

認証プロキシを使用するために NPS を構成する

このタスクは、BroadWorks 版 Webex 専用の NPS の新しいインストールに適用されます。

他のモバイル アプリと共有されている NPS で認証プロキシを構成する場合は、「NPS プロキシを使用するために Cisco BroadWorks NPS を更新する」( https://help.webex.com/nl5rir2) を参照してください。

1

オンボーディング連絡先または TAC を使用して、サービス リクエストを作成し、(Webex Common Identity) OAuth クライアント アカウントをプロビジョニングします。 「認証プロキシ設定のための NPS 構成」とサービス リクエストにタイトルを付けします。

Cisco は OAuth クライアント ID、クライアント シークレット、および 60 日間、有効な更新トークンを提供します。 NPS で使用する前にトークンの期限が切れた場合、別の要求を上げできます。
2

NPS のクライアント アカウントを作成します。

XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set clientId client-Id-From-Step1


  XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set clientSecret New Password: client-Secret-From-Step1

  XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set RefreshToken New Password: Refresh-Token-From-Step1

入力した値が指定された値と一致した可能性を確認するには XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> get を実行してください

3

NPS プロキシ URL を入力し、トークン更新間隔を設定します (推奨 30 分)。

XSP_CLI/Applications/NotificationPushServer/CloudNPSService> set url https://nps.uc-one.broadsoft.com/nps/

XSP_CLI/Applications/NotificationPushServer/CloudNPSService> set VOIPTokenRefreshInterval 1800

4

(Android 通知の場合) Android アプリケーション ID を NPS 上の FCM アプリケーション コンテキストに追加します。

XSP_CLI/Applications/NotificationPushServer/FCM/Applications> add applicationId com.cisco.wx2.android

5

(Apple iOS 通知) アプリケーション ID を APNS アプリケーション コンテキストに追加し、Auth 鍵を省略して空に設定します。

XSP_CLI/Applications/NotificationPushServer/APNS/Production/Tokens> add com.cisco.squared

6

以下の NPS URL を構成します。

XSP CLI コンテキスト

パラメータ

XSP_CLI/Applications/NotificationPushServer/FCM>

authURL

https://www.googleapis.com/oauth2/v4/token

pushURL

https://fcm.googleapis.com/v1/projects/PROJECT-ID/messages:send

scope

https://www.googleapis.com/auth/firebase.messaging

XSP_CLI/Applications/NotificationPushServer/APNS/Production>

URL

https://api.push.apple.com/3/device

7

以下に示す推奨値に、以下の NPS 接続パラメータを構成します。

表 1.

XSP CLI コンテキスト

パラメータ

XSP_CLI/Applications/NotificationPushServer/FCM>

tokenTimeToLiveInSeconds

3600

connectionPoolSize

10

connectionTimeoutInMilliseconds

3000

connectionIdleTimeoutInSeconds

600

XSP_CLI/Applications/NotificationPushServer/APNS/Production>

connectionTimeout

3000

connectionPoolSize

2

connectionIdleTimeoutInSeconds

600

8

Webex アプリを許可リストに追加するために必要な可能性があるため、アプリケーション サーバーがアプリケーション ID を審査中か確認してください。

  1. AS_CLI/System/PushNotification> get を実行し、enforceAllowedApplicationList の値を確認します。 それが true の場合、このサブ タスクを完了する必要があります。 それ以外の場合は、残りのサブ タスクをスキップします。

  2. AS_CLI/System/PushNotification/AllowedApplications> add com.cisco.wx2.android “Webex Android”

  3. AS_CLI/System/PushNotification/AllowedApplications> add com.cisco.squared “Webex iOS”

9

XSP を再起動します: bwrestart

10

BroadWorks のサブスクライバから 2 名の Webex モバイルユーザーに発信し、コール通知をテストします。 iOS および Android デバイスのコール通知が検証されます。

Partner Hub でパートナー組織を構成する

BroadWorks クラスターを構成する

[クラスターごとに 1 回]

これは、次の理由で発生する場合があります。

  • Webex クラウドが BroadWorks に対してユーザーを認証するため (XSP がホストする認証サービス経由)。

  • Webex アプリを有効にし、コール制御のために Xsi インターフェイスを使用するため。

  • Webex が BroadWorks によって公開された CTI イベントを聞き取りを有効にするため (テレフォニーのプレゼンス)。


クラスター ウィザードは、追加するインターフェイスを自動的に検証します。 インターフェイスの 1 つが正常に検証されない場合、クラスターの編集を続けできますが、無効なエントリがある場合はクラスターを保存できません

正しく設定されていないクラスターによって、解決が困難な問題を引き起こす可能性があるため、これを防止します。

行う必要があること:

  1. パートナー管理者資格情報を使用して、Partner Hub (admin.webex.com) にサインインします。

  2. サイド メニューから [設定] ページを開き、BroadWorks Calling 設定を検索します。

  3. [クラスタの追加] をクリックします。

    これにより、XSP インターフェイス (URL) を指定するウィザードが起動します。 非標準ポートを使用している場合は、インターフェイス URL にポートを追加できます。

  4. このクラスターに名前を付け、[次へ] をクリックします。

    ここでのクラスターの概念は単にインターフェイスの集合で、一般的には XSP サーバーまたはファームに共存し、Webex がアプリケーション サーバー (AS) から情報を読み取ることができるようにするものです。 AS クラスターあたり 1 つの XSP、クラスターごとに複数の XSP、または XSP ごとに複数の AS クラスターを持つ場合があります。 お使いの BroadWorks システムのスケール要件については、この範囲外です。

  5. (オプション) Webex に接続している BroadWorks システムにあると知っている BroadWorks のユーザー アカウント名パスワードを入力し、[次へ] をクリックします。

    検証テストは、このアカウントを使用して、クラスターのインターフェイスへの接続を検証することができます。

  6. XSI アクションXSI Events URL を追加し、[次へ] をクリックします。

  7. CTI インターフェイス URL を追加し、[次へ] をクリックします。

  8. 認証サービス URL を追加します。

  9. ユーザー トークンを検証するために、認証サービスがどのように機能する方法を選択してください。

    • MTLS 認証による認証サービス

      XSP/ADP は Webex を信頼します。そのため、認証サービスは受け取ったユーザートークンを、BroadWorks サービスに対してユーザーが承認するために、長時間トークンと交換します。

    • CI トークン検証による認証サービス

      認証サービスは、長期間有効なトークンをユーザーに発行する前に、Webex ID サービスに対してユーザー トークンを適切に検証するため、このオプションでは、Webex からの接続を保護するために mTLS は必要ありません。

  10. 最終的な画面でエントリを確認し、[作成] をクリックします。 成功のメッセージが表示されるはずです。

    Partner Hub は URL を提供されたインターフェイスへの接続をテストするさまざまな Webex マイクロサービスに渡します。

  11. [クラスターの表示] をクリックすると、新しいクラスターが表示され、検証が成功したかどうかを確認します。

  12. [作成] ボタンは、ウィザードの最終 (プレビュー) 画面では無効になる場合があります。 テンプレートを保存できない場合、構成したインテグレーションの 1 つで問題がある場合を示します。

    その後のタスクでエラーが発生するのを防ぐために、このチェックを実施しました。 テンプレートを保存する前に、ウィザードに戻ってインフラストラクチャ (例: XSP、ロード バランサ、ファイアウォールなど) に変更を加える必要がある展開を通じて戻ることができます。

BroadWorks インターフェイスへの接続の確認

  1. パートナー管理者資格情報を使用して、Partner Hub (admin.webex.com) にサインインします。

  2. サイド メニューから [設定] ページを開き、BroadWorks Calling 設定を検索します。

  3. [クラスターの表示] をクリックします。

  4. Partner Hub は、さまざまなマイクロサービスからクラスターのインターフェイスに対する接続テストを開始します。

    テストが完了したら、クラスター リスト ページには、各クラスターの隣にステータス メッセージが表示されます。

    成功のメッセージが表示されるはずです。 赤のエラー メッセージが表示された場合は、影響を受けるクラスター名をクリックして、問題を生じしている設定を確認します。

顧客テンプレートを設定する

顧客テンプレートは、プロビジョニング方法でオンボードする 1 つ以上の顧客に共有設定を適用する方法です。 各テンプレートをクラスターに関連付ける必要があります (前のセクションで作成)。

必要な数だけテンプレートを作成できますが、顧客に関連付けられるのは 1 つのテンプレートのみです。

  1. パートナー管理者資格情報を使用して、Partner Hub (admin.webex.com) にサインインします。

  2. サイド メニューから [設定] ページを開き、BroadWorks Calling 設定を検索します。

  3. [Add template] をクリックします。

    ウィザードを起動すると、このテンプレートを使用する顧客に構成を提供することができます。

  4. [クラスター] ドロップダウンを使用して、このテンプレートで使用するクラスターを選択します。

  5. [テンプレート名] を入力して、[次へ] をクリックします。

  6. 次の推奨設定を使用して、プロビジョニング モードを構成します。

    表 2. 異なるプロビジョニング モードに対して推奨されるプロビジョニング設定

    設定名

    信頼済みメールによるフロースルー

    メールなしのフロースルー プロビジョニング

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

    BroadWorks Flow Through Provisioning を有効にする (オンの場合、プロビジョニング アカウント資格情報を含む)

    日付:

    BroadWorks 構成に基いてプロビジョニング アカウント名パスワードを提供します。

    日付:

    BroadWorks 構成に基いてプロビジョニング アカウント名パスワードを提供します。

    オフ

    Control Hub で新規組織を自動作成

    オン

    オン

    オン

    サービス プロバイダのメール アドレス

    ドロップダウンからメール アドレスを選択します (長いリストの場合は、いくつかの文字を入力してアドレスを検索します)。

    このメール アドレスは、パートナー組織内で、顧客テンプレートで作成された新しい顧客組織に対する管理者の権限が付与される管理者を識別します。

    このテンプレートに使用する国を選択します。

    選択した国は、このテンプレートで作成された顧客組織を特定の地域に一致させます。 現在、地域は (EMEAR) または (北米および他の世界) である場合があります。 「このスプレッドシートで国と地域のマッピング」を参照してください。

    BroadWorks Enterprise モードがアクティブ

    このテンプレートを使用してプロビジョニングした顧客が BroadWorks の企業である場合、これを有効にします。

    彼らがグループの場合は、このスイッチをオフにしたままにしてください。

    BroadWorksでエンタープライズとグループが混在する場合は、これらの異なるケースに対して異なるテンプレートを作成する必要があります。

    • 表中のメモ:

    • †このスイッチは、サブスクライバのメール ドメインが既存の Webex 組織と一致しない場合に、新しい顧客組織が作成されるのを確認します。

      手動注文およびフルフィルメント プロセス (Cisco Commerce Workspace 経由) を使用して Webex で顧客組織を作成しない限り、これは常にオンである必要があります (これらの組織のユーザーのプロビジョニングを開始する前に)。 このオプションは、「ハイブリッド プロビジョニング」モデルと呼ばれることが多く、この文書の範囲外にあります。

  7. このテンプレートを使用する顧客のデフォルトのサービス パッケージを選択します (概要セクションの「パッケージ」を参照してください。BasicStandard、または Premiumのいずれかです)。

    Partner Hub 経由で個々のユーザーに対してこの設定をオーバーライドできます。

  8. このテンプレートを使用する顧客のデフォルトの認証モード (BroadWorks 認証または Webex認証のいずれか) を選択します。

    (「環境 の準備」セクションの「認証モード」を参照してください)。

  9. ユーザーが Webex のために身元を確認する方法を構成します。 表に示されている通り、このページの設定は選択したユーザーのプロビジョニング モードに対応します。

    表 3. 異なるユーザー プロビジョニング モードに対して推奨されるユーザー検証設定

    設定名

    信頼済みメールによるフロースルー

    メールなしのフロースルー プロビジョニング

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

    ユーザーの確認

    Broadworks メールを信頼する

    信頼されないメール

    信頼されないメール

    最初にプロビジョニングされるユーザーは管理者です

    推奨*

    推奨*

    適用できません

    ユーザーにセルフ アクティベーションを許可する

    適用できません

    適用できません

    必須

    • 表中のメモ:

    • * BroadWorks の統合型 IM&P を割り当てる最初のユーザーは、新しい顧客組織が Webex で作成された場合に、顧客管理者のロールを担います。 この設定を選択して、誰がそのロールを担うのか制御できます。 この設定をオフにすると、新規組織で最初にアクティブになるユーザーが顧客管理者になります。

      必要に応じて、プロビジョニング後に Partner Hub の顧客ユーザー ロールを変更できます。

  10. ログイン ページでユーザーのメール アドレスをあらかじめ入力するかを選択します。

    BroadWorks 認証を選択し、BroadWorks の代替 ID 属性にユーザーのメール アドレスを設定している場合にのみ、このオプションを使用してください。 そうでない場合、BroadWorks ユーザー名を使用する必要があります。 ログイン ページに、必要に応じてユーザーを変更するオプションが与えられますが、ログインの問題が発生する可能性があります。

  11. [ディレクトリ同期を有効にする] かどうかを選択します。

    このオプションにより、Webex は BroadWorks の連絡先を顧客組織に読み込み、ユーザーが Webex アプリから連絡先を見つけて発信することができるようになります。

  12. パートナー管理者 を入力します。

    この名前は Webex からの自動メール メッセージで使用され、メール アドレスを検証するためにユーザーを招待します。

  13. 最終画面でエントリーを確認します。 ウィザードの上部にあるナビゲーション コントロールをクリックして、戻って、詳細を変更できます。 [作成] をクリックします。

    成功のメッセージが表示されるはずです。

  14. [テンプレートの表示] をクリックすると、他のテンプレートと一緒に新しいテンプレートがリストされます。

  15. 必要に応じて、テンプレート名をクリックしてテンプレートを変更または削除します。

    プロビジョニング アカウントの詳細を再入力する必要はありません。 空のパスワード/パスワード確認フィールドは、必要な場合は資格情報を変更するためのフィールドとしてありますが、ウィザードで指定した値を保持するには空のままにします。

  16. 顧客に指定したい共有設定が異なる場合は、さらにテンプレートを追加します。


    次のタスクではテンプレートの詳細が必要になるので、以下の [テンプレートの表示] ページを開いたままにします。

プロビジョニングサービス URL でアプリケーション サーバーを構成する


このタスクは、フロースルー プロビジョニングにのみ必要です。

パッチ アプリケーション サーバー

  1. パッチ ap373197 を適用します (参照セクションの「BroadWorks ソフトウェア要件」を参照してください)。

  2. Maintenance/ContainerOptions コンテキストに変更します。

  3. プロビジョニング URL パラメータを有効にする:

    /AS_CLI/Maintenance/ContainerOptions> add provisioning bw.imp.useProvisioningUrl true

Partner Hub からプロビジョニング URL を取得する

AS コマンドの 詳細 (インターフェイス > メッセージングとサービス > 統合型 IM&P) については、「Cisco BroadWorks アプリケーション サーバー コマンド ライン管理ガイド」を参照してください。

  1. Partner Hub にサインインし、[設定] > [BroadWorks Calling] にアクセスします。

  2. [テンプレートの表示] をクリックします。

  3. Webex でこのエンタープライズ/グループのサブスクライバをプロビジョニングするために使用するテンプレートを選択します。

    テンプレートの詳細が、右のフライアウト ペインに表示されます。 テンプレートをまだ作成していない場合は、プロビジョニング URL を取得する前に作成する必要があります。

  4. プロビジョニング アダプター URL をコピーします。

複数のテンプレートがある場合、他のテンプレートにもこれを繰り返します。

(オプション) アプリケーション サーバーでシステム全体のプロビジョニングパラメータを構成する


UC-One SaaS を使用している場合は、システム全体のプロビジョニングとサービス ドメインを設定したくない場合があります。 (「環境の準備」セクションの「意思決定ポインター」を参照してください)。

  1. アプリケーション サーバーにサインインしてメッセージ インターフェイスを設定してください。

    1. AS_CLI/Interface/Messaging> set provisioningUrl EnterValueFromPartnerHubTemplate

    2. AS_CLI/Interface/Messaging> set provisioningUserId EnterValueFromPartnerHubTemplate

    3. AS_CLI/Interface/Messaging> set provisioningPassword EnterValueFromPartnerHubTemplate

    4. AS_CLI/Interface/Messaging> set enableSynchronization true

  2. 統合型 IMP インターフェイスをアクティベートする:

    1. /AS_CLI/Service/IntegratedIMP> set serviceDomain example.com

    2. /AS_CLI/Service/IntegratedIMP/DefaultAttribute> set userAttrIsActive true


Control Hub に指定された通り、 provisioningURL パラメータの完全修飾名を入力する必要があります。 アプリケーション サーバーが DNS にアクセスしてホスト名を解決できない場合、AS の /etc/hosts ファイルでマッピングを作成する必要があります。

(オプション) アプリケーション サーバーでエンタープライズごとのプロビジョニング パラメーターを構成する

  1. BroadWorks UI で、構成するエンタープライズを開き、[サービス] > [統合型 IM&P] に移動します。

  2. [サービス ドメインを使用する] を選択し、値を入力します (Webex はパラメーターを無視します。 example.com を使用できました)。

  3. [メッセージング サーバーを使用] を選択します。

  4. [URL] フィールドで、Partner Hub のテンプレートからコピーしたプロビジョニング URL を貼り付けます。


    Partner Hub で指定された provisioningURL パラメータの完全修飾名を入力する必要があります。 アプリケーション サーバーが DNS にアクセスしてホスト名を解決できない場合、AS の /etc/hosts ファイルでマッピングを作成する必要があります。

  5. [ユーザー名] フィールドに、プロビジョニング管理者の名前を入力します。 これは、Partner Hub のテンプレートの値と一致する必要があります。

  6. プロビジョニング管理者のパスワードを入力します。 これは、Partner Hub のテンプレートの値と一致する必要があります。

  7. [IM&P ID のデフォルト ユーザー ID][プライマリ] を選択します。

  8. [適用] をクリックします。

  9. プロビジョニングを通じたフローに対して構成する他のエンタープライズに対して繰り返します。

BroadWorks Calling のディレクトリ検索

ディレクトリ同期によって、BroadWorks 版 Webex のユーザーは Webex ディレクトリを使用して、BroadWorks サーバーの任意のコーリング エンティティに発信できることを確認します。 この機能により、メッセージング クライアントを持つテレフォニー エンティティでさえ Webex ディレクトリと同期することができます。


BroadWorks 版 Webex のプロビジョニングには、BroadWorks サーバーから Webex ディレクトリに、メッセージング ユーザーとそれに関連するコーリング情報のデフォルト同期が含まれます。 しかし、プロビジョニング同期によって、メッセージングと非ユーザー エンティティ (例えば、会議室 の電話、FAX マシン、または ハント グループ 番号) に対して有効になっていないユーザーは省略されます。 これらの省略されたコーリング エンティティが Webex ディレクトリに追加されるのを確認するために、ディレクトリ同期を有効にする必要があります。

ディレクトリ同期の条件

  • ディレクトリ同期の同期は、特定の顧客テンプレートに対して毎週実行されます。 最初の同期は、同期を有効にしたその後の週にスケジュールされます (同期を開始するために選択された時間はランダムです)。

  • 同期に失敗した場合、同期は次のスケジュールされた同期まで、24 時間ごとに自動的に再試行されます。

  • 特定の顧客テンプレートについては、Control Hub (最後に成功した同期情報とともに) で同期ステータスを表示できます。

  • 指定された顧客テンプレートの同期をオンにすることで、テンプレートを使用するすべての組織の同期を有効にします。 1 つ以上の組織で同期に失敗した場合、ステータスには部分的な障害が表示されます。

  • 同期によって電話番号を持たないユーザーは無視されます。

  • 各 Webex アプリには、同期後の更新が Webex アプリに表示される前にクリアに最大 72 時間かかるローカル キャッシュがあります。この遅延は、機能を有効または無効にするかどうかを決定します。

開始する前に

次の設定を使用することをお勧めします。

  • レート制限値—次の OverloadControl システム プロパティ (XSP_CLI/Applications/Xsi-Actions/OverloadControl) を設定します。

    • userDirectoryTransactionLimit—null 値に設定します。 そうではない場合は、5 (最低限) に設定します。

    • globalDirectoryTransactionLimit—null 値に設定します。 そうではない場合は、5 (最低限) に設定します。

  • ページング値—Paging システム プロパティ (XSP_CLI/Applications/Xsi-Actions/Paging) を設定します。

    • defaultPageSize—50 に設定します

    • availableUserMaxLimit—100 に設定します

  • CTI インターフェイス—Webex CA 証明書を CTI インターフェイス信頼ストアにアップロードし、CTI インターフェイスでクライアント認証を有効にすることを確認してください。

さらに、この機能を有効にする前に、BroadWorks 展開にシステムパッチ ap368517 を適用することをお勧めします (パッチ情報については、参照セクションの「BroadWorks ソフトウェア要件」を参照してください)。

操作手順

以下の手順を完了して、ディレクトリ同期をオンにします。

  1. Partner Hub で、[設定] を選択します。

  2. BroadWorks Calling にスクロールし、[テンプレートの表示] をクリックします。

  3. 適切なテンプレートを選択します。

  4. [BroadWorks ディレクトリ同期] までスクロールし、[ディレクトリ同期の有効化] トグルを [オン] に設定します。

  5. [保存] をクリックします。


[ディレクトリ同期] を無効にするには、[ディレクトリ同期の有効化] トグルを [オフ] に設定します。 これにより、BroadWorks のみのユーザーを Webex ディレクトリから削除します。

クライアントのカスタマイズとプロビジョニング

ユーザーはデスクトップまたはモバイル用の汎用 Webex アプリをダウンロードしてインストールします (「環境の準備」セクションの 「Webex App プラットフォーム 」を参照してください)。 ユーザー認証後、クライアントはメッセージングとミーティングのために Cisco Webex クラウドに登録し、ブランディング情報を取得し、BroadWorks サービス情報を見つけ、BroadWorks アプリケーション サーバーからコール構成をダウンロードします (XSP の DMS 経由)。

BroadWorks (通常通り) の Webex アプリのコーリング パラメータを構成します。 Control Hub でクライアントのブランディング、メッセージング、ミーティング パラメータを構成します。 構成ファイルは直接、変更できません。

これらの 2 セットの構成は重複することができます。この場合、Webex 構成が BroadWorks 構成に優先されます。

BroadWorks アプリケーション サーバーに Webex アプリ構成テンプレートを追加する

Webex アプリは DTAF ファイルで構成されます。 クライアントは、XSP のデバイス管理サービス経由で、アプリケーション サーバーから構成 XML ファイルをダウンロードします。

  1. 必要な DTAF ファイルを取得します (「環境の準備」セクションの「デバイス プロファイル」を参照してください)。

  2. [BroadWorks システム] > [リソース] > [デバイス管理タグ セット] で適切なタグセットを持っていることを確認します。

  3. 各クライアントに対してプロビジョニングを行います。

    1. 特定のクライアント向け DTAF zip ファイルをダウンロードし、抽出します。

    2. DTAF ファイルを BroadWorks に [システム] > [Id/デバイス プロファイル タイプ] にインポートする

    3. 編集のために新しく追加されたデバイス プロファイルを開き、XSP ファーム FQDN とデバイス アクセス プロトコルを入力します。

    4. お使い環境に合わせてテンプレートを変更します (下表を参照)。

    5. プロファイルを保存する。

  4. [ファイルと認証] をクリックしてから、すべてのシステム ファイルを再構築するオプションを選択します。

名前

説明

コーデックの優先順位

VoIP コールの音声とビデオ コーデックに対して優先順位を構成します。

TCP、UDP、および TLS

SIP シグナリングとメディアに使用するプロトコルを構成します

RTP 音声およびビデオ ポート

RTP 音声とビデオのポート範囲を構成する

SIP オプション

SIP に関連する様々なオプションを構成します (SIP 情報、使用 rport、SIP プロキシ検出、登録とサブスクリプションの更新間隔など)。

Control Hub のクライアントをカスタマイズする

デスクトップ クライアントとモバイル クライアントには異なるブランディング設定が含まれるので、両方を使用する場合は、このブランディング プロセスを繰り返す必要があります。

  1. Partner Hub にサインインし、[構成] > [BroadWorks クライアント] にアクセスします。

  2. クライアント構成ページの [ブランディング] エリアを探します。

  3. ロゴとプライマリ ナビゲーション バーのカラーを更新します。 詳細については、「Webex に会社のブランディングを追加する」を参照してください。


[ユーザー アクティベーション] ポータルは、クライアント ブランディングに追加したロゴと同じロゴを使用します。

問題の報告とヘルプ URL をカスタマイズする

https://help.webex.com/n0cswhcb 『顧客のブランディングと問題の報告をカスタマイズする』 を参照してください。

BroadWorks 版 Webex のテスト組織を構成する

スケジューリングを始める前に

フロースルー プロビジョニングの使用

このタスクを実行する前に、Control Hub ですべての XSP サービスとパートナー組織を構成する必要があります。

1

BroadWorks でのサービスの指定:

  1. BroadWorks のサービス プロバイダ エンタープライズの下にテスト エンタープライズを作成するか、または サービス プロバイダの下にテスト グループを作成します (BroadWorks のセットアップに依存)。

  2. テスト中のテンプレートをポイントするために、エンタープライズの IM&P サービスを構成します (Control Hub の顧客テンプレートからプロビジョニング アダプターの URL と資格情報を取得します)。

  3. そのエンタープライズ/グループにテスト サブスクライバーを作成します。

  4. BroadWorks のメール フィールドでユーザーに固有のメール アドレスを提供します。 それらは [代替 ID] 属性にもコピーします。

  5. それらのサブスクライバーに統合型 IM&P サービスを割り当てます。


     

    これは顧客組織と最初のユーザーの作成をトリガーします。これには数分かかります。 新規ユーザーとのサインインを試みようとする前に、少しお待ちください。

2

Control Hub で顧客の組織とユーザーを検証します。

  1. パートナー管理者アカウントを使って Control Hub にサインインします。

  2. [顧客] に移動して、新しい顧客組織がリストにあるか確認します (名前には BroadWorks のグループ名またはエンタープライズ名に続きます)。

  3. 顧客の組織を開いて、サブスクライバが組織のユーザーであることを確認します。

  4. 統合型 IM&P サービスを割り当てた最初のサブスクライバが、その組織の顧客管理者になったことを確認します。

ユーザー テスト

1

2 台の異なるマシンに Webex アプリをダウンロードしてください。

2

2 台のマシンでテスト ユーザーとしてサインインします。

3

テスト コールを発信します。