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 アプリケーションをインストールし、構成します。

認証サービス(CI トークン検証使用)を設定する

この手順を使用して、TLS で CI トークン検証を使用する認証サービスを設定します。 この認証方法は、R22 以降を実行しており、システムがこの認証方法をサポートしている場合に推奨されます。


相互 TLS(mTLS)は、認証サービスの代替認証方法としてサポートされています。 以下の条件がシステムに適用される場合、CI トークン検証ではなく、mTLS 認証を設定してください。

  • R21SP1 を実行している。

  • 同じ XSP サーバーを実行している複数の Webex 組織がある。 この場合、CI トークン検証は同じ XSP 認証サービスへの複数の接続をサポートしないため、mTLS 認証を使用する必要があります。

mTLS 認証を認証サービスに設定するには、付録を参照してください。

R22 以降を実行しており、現在認証サービスに mTLS を使用している場合、TLS で CI トークン検証を使用するよう再設定する必要はない点にも注意してください。

  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 ciResponseBodyMaxSizeInBytes 65536

    • set issuerName <URL>URL には、CI クラスタに適用される IssuerName URL を入力します。 次のテーブルを参照してください。

    • set issuerUrl <URL>URL には、CI クラスタに適用される IssuerUrl を入力します。 次のテーブルを参照してください。

    • set tokenInfoUrl <IdPProxy URL> —Teams クラスタに適用される IdP プロキシ URL を入力します。 次のテーブルを参照してください。

    表 1. ID プロバイダ URL

    IssuerURL および IssuerName URL

    IdP プロキシ URL

    CI クラスターが...

    IssuerURL および IssuerName を次に設定...

    Teams クラスターが...

    IdP Proxy URL を次に設定...

    US-A

    https://idbroker.webex.com/idb

    ACHM

    https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

    EU

    https://idbroker-eu.webex.com/idb

    AFRA

    https://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

    US-B

    https://idbroker-b-us.webex.com/idb

    AORE

    https://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

    * CI クラスタまたはチーム クラスタを知らない場合には、Control Hub の [ヘルプ デスク] ビューから情報を取得できます。 [顧客] の詳細情報の下にある [CI クラスタ][チーム クラスタ] フィールドの値を参照してください。


     
    テストでは、URL の「 idp/authenticate 」の部分を「 ping 」に置き換えることで、URL が有効かどうかを検証できます。
  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 60

    • set refreshToken <token from service request>

  7. 次のコマンドを実行して、FLS 設定が動作している確認を行います。 このコマンドは、ID プロバイダのリストを返します。

    XSP_CLI/Applications/AuthService/IdentityProviders/Cisco/Federation/ClusterMap> Get

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

    • XSP_CLI/Applications/AuthenticationService/TokenManagement>

    • set tokenIssuer BroadWorks

    • set tokenDurationInHours 720

  9. 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

  10. ウェブ コンテナに 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 サーバーインターフェイスに暗号を追加します。


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

    どちらかの名前でスイートを検索する場合は、https://ciphersuite.info/ を参照してください。

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

プロファイル サーバーと XSP はデバイス管理に必須です。 『BroadWorks デバイス管理設定ガイド』(https://xchange.broadsoft.com/node/1031995) の手順に沿って構成する必要があります。

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

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

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

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

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

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

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

BroadWorks 版 Webex CTI クライアント証明書の共通名 (CN) でアプリケーション サーバーの ClientIdentity を更新します。

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 の場合: 次に移動します: 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 インターフェイスで暗号を構成するには、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 標準暗号スイート名を必要とします。 たとえば、openSSL 暗号 ECDHE-ECDSA-CHACHA20-POLY1305 を CTI インターフェイスに追加するには、次を使用します: 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.

      元のファイルにはテキストのブロックが 1 つだけ残っており、次の行で囲まれているはずです: -----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----.

  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.

      元のファイルにはテキストのブロックが 1 つだけ残っており、次の行で囲まれているはずです: -----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----.

  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> certificateFile </path/to/server certificate> chainFile</path/to/chain file>

      BroadWorks 21.sp1 の場合:

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

  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) がホストするアプリケーションです。ユーザーは CSWV により、ソフト クライアントに表示される Webview で BroadWorks コール設定を変更できます。 詳細な CSWV ソリューション ガイドについては、https://xchange.broadsoft.com/node/1050149 を参照してください。

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

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

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

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

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

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

  • Windows ユーザーの場合: プロファイル画像をクリックしてから [Settings (設定)] > [Calling] > [Self Care (セルフ ケア)] をクリックします。

  • Mac ユーザーの場合 プロファイル画像をクリックしてから、[Preferences (基本設定)] > [Calling] > [Self Care (セルフ ケア)] をクリックします

BroadWorks で CSWV を展開する

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

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

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

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

    たとえば、BWCallSettingsWeb_1.8.2_1.war (https://xchange.broadsoft.com/node/1057167) が執筆時点では最新でした。

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

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

    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> deploy 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 について詳しくは、「Notification Push Server Feature Description」(通知プッシュ サーバー機能の説明)(https://xchange.broadsoft.com/node/485737) を参照してください。

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


このセクションでは、NPS が他のアプリをまだサポートしていない場合に、NPS を認証プロキシのために設定する方法について説明します。 NPS プロキシを使用するために共有 NPS を移行する必要がある場合、「Updating Cisco BroadWorks NPS to Use NPS Proxy」(NPS プロキシの使用を目的とした Cisco BroadWorks 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 デバイスにプッシュ通知する機能も強化されています。

APNS の考慮事項

Apple は Apple Push Notification サービスでの HTTP/1 ベースのバイナリ プロトコル サポートを 2021 年 3 月 31 日付けで終了します。 XSP が HTTP/2 ベース インターフェイスの APN を使用する設定にするようお勧めします。 今回の更新で、NPS をホストする XSP には R22 以降の実行が義務付けられました。

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 を新しくインストールする場合は、[Configure NPS to Use Authentication Proxy (NPS を設定して認証プロキシを使用する)] に移動します

既存の Android 版環境から FCMv1 に移行するには、[Migrate NPS to FCMv1 (NPS を FCMv1 に移行)] に移動します

認証プロキシを使用するために 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 接続パラメータを構成します。

XSP CLI コンテキスト

パラメータ

  • XSP_CLI/Applications/

    NotificationPushServer/FCM>

tokenTimeToLiveInSeconds

3600

connectionPoolSize

10

connectionTimeoutInMilliseconds

3600

connectionIdleTimeoutInSeconds

600

  • XSP_CLI/Applications/NotificationPushServer/

    APNS/Production>

connectionTimeout

300

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 デバイスのコール通知が検証されます。

NPS から FCMv1 に移行

このトピックでは、既存の NPS 展開があり、FCMv1 に移行する必要がある場合に、任意で Google FCM コンソールに使用できる手順について説明します。 次の 3 つの手順があります。

UCaaS クライアントを FCMv1 に移行する

Google FCM コンソールで以下の手順を使用し、UCaaS クライアントを Google FCM HTTPv1 に移行します。


クライアントにブランディングを適用中の場合、クライアントには送信者 ID が必要です。 FCM コンソールで、[Project Settings (プロジェクト設定)] > [Cloud Messaging (クラウド メッセージング)] の順に確認します。 プロジェクトの資格情報一覧表に設定が表示されます。

詳しくは、「 Connect Branding Guide」(接続ブランディング ガイド)(https://xchange.broadsoft.com/node/1053211) を参照してください。 ブランディングキットの Resource フォルダーの branding.xml ファイルにある gcm_defaultSenderId パラメーターを次の構文で参照します:

<string name="gcm_defaultSenderId">xxxxxxxxxxxxx</string>

  1. http://console.firebase.google.com で [FCM Admin SDK (FCM 管理 SDK にログイン)] にログインします。

  2. 適切な Android アプリケーションを選択します。

  3. [General (全般)] タブを開き、プロジェクト ID を記録します

  4. [Service Accounts (サービス アカウント)] タブにナビゲートして、サービス アカウントを設定します。 新しいサービス アカウントを作成するか、既存のサービス アカウントを設定することができます。

    新しいサービス アカウントを作成するには:

    1. 新しいサービス アカウントを作成するには、青いボタンをクリックします

    2. 新しいプライベート キーを生成するには、青いボタンをクリックします

    3. キーを安全な場所にダウンロードします

    既存のサービス アカウントを再使用するには:

    1. 既存のサービス アカウントを表示するには、この青いテキストをクリックします。

    2. 使用するサービス アカウントを特定します。 サービス アカウントに firebaseadmin-sdk のアクセス許可が必要です。

    3. 右端のハンバーガー メニューをクリックして、新しいプライベート キーを作成します。

    4. キーを安全な場所にダウンロードします。

  5. キーを XSP にコピーします。

  6. プロジェクト ID を構成すると、次のようになります。

    XSP_CLI/Applications/NotificationPushServer/FCM/Projects> add <project id> <path/to/key/file>
    ...Done
    
    XSP_CLI/Applications/NotificationPushServer/FCM/Projects> get
      Project ID  Accountkey
    ========================
      my_project    ********
  7. アプリケーションを設定すると、次のようになります。

    XSP_CLI/Applications/NotificationPushServer/FCM/Applications> add <app id> projectId <project id>
    ...Done
    
    XSP_CLI/Applications/NotificationPushServer/FCM/Applications> get
      Application ID    Project ID
    ==============================
              my_app    my_project
  8. 次のとおり FCMv1 を有効にします。

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  9. コマンド bwrestart を実行して XSP を再起動します。

SaaS クライアントを FCMv1 に移行

Google FCM コンソールで以下の手順を使用し、SaaS クライアントを FCMv1 に移行します。


「認証プロキシを使用するために NPS を構成する」手順を完了している必要があります。
  1. 次のとおり FCMv1 を無効にします。

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled false
    ...Done
  2. コマンド bwrestart を実行して XSP を再起動します。

  3. 次のとおり FCM を有効にします。

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  4. コマンド bwrestart を実行して XSP を再起動します。

ADP サーバーをアップデート

NPS を移行して ADP サーバーを使用しようとする場合、Google FCM コンソールで以下の手順を実行します。

  1. 次のとおり Google Cloud Console から JSON ファイルを取得します。

    1. [Google Cloud Console] で [Service Accounts (サービス アカウント)] ページに移動します。

    2. [Select a project (プロジェクトを選択)] をクリックして目的のプロジェクトを選択し、[Open (開く)] をクリックします。

    3. キーを作成しようとするサービス アカウントの行を検索し、縦型の [More (詳細)] ボタンをクリックして、[Create key (キーを作成)] をクリックします。

    4. キーのタイプを選択し、[Create (作成)] をクリックします。

      ファイルがダウンロードされます。

  2. ADP サーバーに FCM を追加します。

    1. 次のコマンドを使用して、JSON ファイルを ADP サーバーにインポート /bw/install します。

    2. 次のとおり ADP CLI にログインし、Project と API のキーを追加します。

      ADP_CLI/Applications/NotificationPushServer/FCM/Projects> add connect /bw/install/google JSON:

    3. 次に、アプリケーションとキーを追加します。

      ADP_CLI/Applications/NotificationPushServer/FCM/Applications> add com.broadsoft.ucaas.connect projectId connect-ucaas...Done

    4. 次の設定を確認します。

      ADP_CLI/Applications/NotificationPushServer/FCM/Projects> g
      Project ID Accountkey
      ========================
      connect-ucaas ********
      
      ADP_CLI/Applications/NotificationPushServer/FCM/Applications> g
      Application ID Project ID
      ===================================
      com.broadsoft.ucaas.connect connect-ucaas

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. [次へ] をクリックします。

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

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

  10. [Auth Service with CI token validation (認証サービスと CI トークンの検証)] を選択します。

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

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

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

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

  13. [作成] ボタンは、ウィザードの最終 (プレビュー) 画面では無効になる場合があります。 テンプレートを保存できない場合、構成したインテグレーションの 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. このテンプレートを使用する顧客のデフォルトのサービス パッケージを選択します (概要セクションの「パッケージ」を参照してください。[Basic][Standard][Premium][Softphone] のいずれかです)。

    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. 必要に応じて、テンプレート名をクリックしてテンプレートを変更または削除します。

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

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


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

BroadWorks 版 Webex を既存の組織に追加する

パートナー管理者が、BroadWorks サービス用の Webex を Control Hub に存在している顧客組織に追加しているが、CI の組織にまだ関連付けられていない場合、顧客組織管理者は、正常にリクエストを成功するために管理者アクセスを承認する必要があります。

以下のいずれかが正しい場合は、組織管理者の承認が必要です。

  • 少なくとも 100 人のユーザーの組織で、サービス プロバイダーと顧客組織と組織の間のユーザーとユーザーの 1 人の電子メールアドレスが CI ユーザーのメール アドレスに一致する管理下の関係はありません

  • 組織には検証済みのメール ドメインがあります

  • 組織ドメインはクレームされていません

パートナー管理者は以下の手順を完了して、BroadWorks Calling サービスを既存の Webex 組織に追加できます。


パートナー ハブで、既存の組織のプロビジョニング トグルは、組織の顧客テンプレート設定内で有効にする必要があります (デフォルトでトグルがオンになっています)。

  1. BroadWorks で、組織のユーザーとして自分自身をプロビジョニングします。

  2. 顧客の BroadWorks 版 Webex をプロビジョニングします。 Calling サービスがアップグレードされましたというタイトルのメール通知を受け取ります。

  3. メール通知で、[今すぐ参加] ボタンをクリックします。 このボタンをクリックした後で、次のような処理が行われます。

    • 組織の添付ファイルが 2017 エラーで失敗します (既存の Webex 組織に契約者をプロビジョニングできません)。

    • 承認リクエスト メールが生成され、顧客組織管理者に送信されます (最大 5 人の管理者)。 通知はパートナー管理者のメールを強調表示し (パートナー ハブ内の顧客テンプレートで構成済み)、組織管理者にリクエストを承認するように依頼します。 プロビジョニング プロセスを完了するには、組織管理者がリクエストを承認し、顧客組織にフル管理者権限を付与する必要があります

  4. 完全な管理者アクセスにより、Calling サービスを正常にプロビジョニングできます。

外部管理者を追加する

顧客組織管理者が、外部管理者としてパートナー管理者を追加するために行える手順については、「外部管理者のリクエストの承認」を参照してください。

プロビジョニングサービス 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 にサインインし、[Settings (設定)] > [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 を貼り付けます。


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

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

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

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

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

  9. フロースルー プロビジョニングを構成するべき、その他のエンタープライズについても、同じ手順を繰り返します。

ディレクトリ同期

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


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

ディレクトリ同期の条件

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

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

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

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

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

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

開始する前に

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


以下の例は、XSP サーバーを使用していることを想定しています。 ADP サーバーの場合、(XSP_CLI) を (ADP_CLI) で置き換えます。
  • レート制限値—次の OverloadControl システム プロパティ (XSP_CLI/Applications/Xsi-Actions/OverloadControl) を設定します。

    • userDirectoryTransactionLimit—null 値に設定します。

    • globalDirectoryTransactionLimit—null 値に設定します。


    userDirectoryTransactionLimit および globalDirectoryTransactionLimit は null 値に設定することをお勧めします。 しかし、値を割り当てる場合は、それぞれを transactionLimitPeriodSeconds の値(1 のはずです)の少なくとも 5 倍に設定する必要があります。
  • トランザクション制限—次の値 (XSP_CLI/System/CommunicationUtility/DefaultSettings) を設定します。

    • userTransactionLimits-少なくとも 100 に設定します。

    • transactionLimitPeriodSeconds-1 に設定します。

  • ページング値—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 for BroadWorks は 4 種類のコール録画モードをサポートしています。

表 4. 録画モード

録画モード

説明

Webex アプリに表示される操作パネルやインジケータ

常時

コールが確立すると、自動的に録画が開始されます。 ユーザーは録画を開始または停止する権限がありません。

  • 視覚的インジケータで録画が進行中であることが示されます

常に一時停止/続行

コールが確立すると、自動的に録画が開始されます。 ユーザーは録画の一時停止や再開ができます。

  • 視覚的インジケータで録画が進行中であることが示されます

  • [Pause Recording (録画一時停止)] ボタン

  • [Resume Recording (録画再開)] ボタン

オンデマンド

コールが確立されると録画が自動的に開始されますが、ユーザーが [録画の開始] を押さない限り録画は削除されます。

ユーザーが録画を開始すると、コール セットアップ以降の完全な録画が保持されます。 ユーザーは録画の開始後、録画を一時停止して再開することもできます。

  • [Start Recording (録画開始) ] ボタン

  • [Pause Recording (録画一時停止)] ボタン

  • [Resume Recording (録画再開)] ボタン

ユーザーの開始操作に合わせオンデマンド

ユーザーが Webex アプリで [録画の開始] オプションを選択 しない限り、録画は開始されます。ユーザーはコール中に録画を何度も開始したり停止したりすることができます。

  • [Start Recording (録画開始) ] ボタン

  • [Stop Recording (録画を停止)] ボタン

  • [Pause Recording (録画一時停止)] ボタン

要件

BroadWorks 版 Webex にこの機能を展開するには、次の BroadWorks パッチを展開する必要があります。

  • AP.as.22.0.1123.ap377718

  • AP.as.23.0.1075.ap377718

  • AP.as.24.0.944.ap377718

AS は X-BroadWorks-Correlation-Info SIP ヘッダーを送信するように構成する必要があります:

  • AS_CLI/Interface/SIP> set sendCallCorrelationIDNetwork true

  • AS_CLI/Interface/SIP> set sendCallCorrelationIDAccess true

この機能を使用するには、次の構成タグを有効にする必要があります。 %ENABLE_CALL_RECORDING_WXT%.

この機能を使用するには、サードパーティのコール録画プラットフォームとのインテグレーションが必要です。

BroadWorks でコール録画を設定するには『Cisco BroadWorks Call Recording Interface Guide』(Cisco BroadWorks コール録画インターフェイス ガイド)(https://xchange.broadsoft.com/node/1033722) を参照してください。

付加情報

録画機能の利用方法に関するユーザー向け情報については、「Webex| Record Your Calls (Webex コールの録画)」を参照してください。

ユーザーや管理者が録画を再生するには、サードパーティのコール録画プラットフォームに移動する必要があります。

グループ コール パークと保留解除

BroadWorks 版 Webex はグループ コール パークと保留解除をサポートしています。 この機能により、グループ内のユーザーはコールをパークし、それをグループ内の他のユーザーが取得することができます。 たとえば、小売店の従業員が店内でこの機能を使用してコールをパークしたあと、そのコールを別の部門の誰か取得し、続けるようなイメージです。

この機能を展開するには、管理者がコール パーク グループを作成し、ユーザーをグループに追加する必要があります。 機能の設定が完了したら:

  • コール中にユーザーが Webex アプリの [Park (パーク)] オプションをクリックし、システムが自動選択した外線でコールをパークします。 システムがユーザーに内線を 10 秒間表示します。

  • グループの別のユーザーが、Webex アプリの [Retrieve (コールを取得)] オプションをクリックします。次にこのユーザーはパークされたコールの内線番号を入力し、コールを続けます。

BroadWorks でこの機能を設定する詳細な管理方法については、『BroadWorks Application Server Group Web Interface Administration Guide –Part 2』 (BroadWorks アプリケーション サーバー グループ ウェブ インターフェイス管理ガイド - パート 2)の「Call Park」(コール パーク) セクション (https://xchange.broadsoft.com/node/1051947) を参照してください。

付加情報

ユーザー向けのグループコール パークの使用方法については、「Webex| Park and Retrieve Calls」(Webex コールのパークと保留解除) を参照してください。

コール パークまたは転送コール パーク

通常または指定されたコール パークは Webex アプリ UI ではサポートされていませんが、プロビジョニングされたユーザーは機能アクセス コードを使用して機能を展開できます。

  • コールをパークするには「*68」と入力してください

  • コール を取得するには *88 と入力してください

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

ユーザーはデスクトップまたはモバイル用の汎用 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

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