Deploy Webex for BroadWorks

Deployment Overview

The following diagrams represent the typical order of your deployment tasks for the different user provisioning modes. Many of the tasks are common to all provisioning modes.

Figure 1. Tasks required for deploying flow-through provisioning
Shows the order of tasks required for deploying Webex for BroadWorks with flow-through provisioning and trusted emails
Figure 2. Tasks required for deploying flowthrough provisioning without trusted emails
Shows the order of tasks required for deploying Webex for BroadWorks with flow-through provisioning without emails
Figure 3. Tasks required for deploying user self-provisioning
Shows the order of tasks required for deploying Webex for BroadWorks with self-activation

Partner Onboarding for Cisco Webex for BroadWorks

Each Webex for BroadWorks Service Provider or Reseller needs a to be setup as a Partner Organization for Cisco Webex for BroadWorks. If you have an existing Cisco Webex Partner Organization, this can be used.

In order to complete the necessary onboarding, you must execute your Webex for BroadWorks paperwork and new partners must accept the online Indirect Channel Partner Agreement (ICPA). When these steps are completed, Cisco Compliance will create a new Partner Org in Partner Hub (if needed) and send an email with authentication details to the Admin of Record in your paperwork. At the same time, your Partner Activation and/or Customer Success Program Manager will contact you to start your onboarding.

Configure Services on Your Webex for BroadWorks XSPs

We require that the NPS application be run on a different XSP. Requirements for that XSP are described in Configure Call Notifications from your Network.

You need the following applications / services on your XSPs.

Service/Application

Authentication required

Service/application purpose

Xsi-Events

TLS (server authenticates itself to clients)

Call control, service notifications

Xsi-Actions

TLS (server authenticates itself to clients)

Call control, actions

Device management

TLS (server authenticates itself to clients)

Calling configuration download

Authentication Service

TLS (server authenticates itself to clients)

User authentication

Computer Telephony Integration

mTLS (client and server authenticate each other)

Telephony presence

Call Settings Webview application

TLS (server authenticates itself to clients)

Exposes user call settings in the selfcare portal within the Webex app

This section describes how to apply the required configurations for TLS and mTLS on these interfaces, but you should reference existing documentation to get the applications installed on your XSPs.

Co-Residency Requirements

  • Authentication Service must be co-resident with Xsi applications, because those interfaces must accept long-lived tokens for service authorization. The authentication service is required to validate those tokens.

  • Authentication service and Xsi can run on the same port if required.

  • You may separate the other services/applications as required for your scale (dedicated device management XSP farm, for example).

  • You may co-locate the Xsi, CTI, Authentication Service, and DMS applications.

  • Do not install other applications or services on the XSPs that are used for integrating BroadWorks with Webex.

  • Do not co-locate the NPS application with any other applications.

Xsi Interfaces

Install and configure the Xsi-Actions and Xsi-Events applications as described in Cisco BroadWorks Xtended Services Interface Configuration Guide.

Configure Authentication Service (with CI Token Validation)

Use this procedure to configure the Authentication Service to use CI Token Validation with TLS. This authentication method is recommended if you are running R22 or higher and your system supports it.


Mutual TLS (mTLS) is supported as an alternative authentication method for the Auth Service. If the following conditions apply to your system, configure mTLS authentication rather than CI Token Validation:

  • You are running R21SP1.

  • You have multiple Webex organizations running off the same XSP server. In this case, you must use mTLS authentication as CI Token Validation does not support multiple connections to the same XSP Auth Service.

To configure mTLS authentication for the Auth Service, refer to the Appendix.

Also note that if you are running R22 or higher, and you currently use mTLS for the Auth Service, it's not mandatory that you reconfigure to use CI Token Validation with TLS.

  1. Create a service request with your onboarding contact, or with TAC, to provision your (Webex Common Identity) OAuth client account. Title your service request "XSP AuthService Configuration". Cisco gives you an OAuth client ID, a client secret, and a refresh token that is valid for 60 days. If the token expires before you use it with your XSP, you can raise another request.

  2. Install the following patches on each XSP server. Install the patches that are appropriate to your release:

    • For R22:

      AP.platform.22.0.1123.ap376508

      AP.xsp.22.0.1123.ap376508

    • For R23:

      AP.xsp.23.0.1075.ap376509

      AP.platform.23.0.1075.ap376509

    • For R24—no patch required

  3. Install the AuthenticationService application on each XSP service.

    1. Run the following command to activate the AuthenticationService application on the XSP to the /authService context path.

      XSP_CLI/Maintenance/ManagedObjects> activate application AuthenticationService 22.0_1.1123/authService
    2. Run this command to deploy the AuthenticationService on the XSP:

      XSP_CLI/Maintenance/ManagedObjects> deploy application /authServiceBroadWorks SW Manager deploying /authService...
  4. Configure the Identity Providers by running the following commands on each XSP server:

    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>—For the URL, enter the IssuerName URL that applies to your CI Cluster. See the table that follows.

    • set issuerUrl <URL>—For the URL, enter the IssuerUrl that applies to your CI Cluster. See the table that follows.

    • set tokenInfoUrl <IdPProxy URL>—Enter the IdP Proxy URL that applies to your Teams Cluster. See the table that follows.

    Table 1. Identity Provider URLs

    IssuerURL and IssuerName URL

    IdP Proxy URL

    If CI Cluster is...

    Set IssuerURL and IssuerName to...

    If Teams Cluster is...

    Set IdP Proxy URL to...

    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

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

    US-B

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

    AORE

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

    * If you don't know your CI Cluster or Teams Cluster, you can obtain the information from the Help Desk view in Control Hub. Under Customer details, see the value of the CI Cluster and Teams Cluster fields.


     
    For testing, you can verify that the URL is valid by replacing the "idp/authenticate" portion of the URL with "ping".
  5. Specify the Webex entitlement that must be present in the user profile in Webex by running the following command:

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

  6. Configure Identity Providers for Cisco Federation using the following commands on each XSP server:

    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. Run the following command to validate that your FLS configuration is working. This command will return the list of Identity Providers:

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

  8. Configure Token Management using the following commands on each XSP server:

    • XSP_CLI/Applications/AuthenticationService/TokenManagement>

    • set tokenIssuer BroadWorks

    • set tokenDurationInHours 720

  9. Generate and Share RSA Keys. You must generate keys on one XSP then copy them to all other XSPs. This is due to the following factors:

    • You must use the same public/private key pairs for token encryption/decryption across all instances of the authentication service.

    • The key pair is generated by the authentication service when it is first required to issue a token.


    If you cycle keys or change the key length, you need to repeat the following configuration and restart all the XSPs.
    1. Select one XSP to use for generating a key pair.

    2. Use a client to request an encrypted token from that XSP, by requesting the following URL from the client’s browser:

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

      (This generates a private / public key pair on the XSP, if there wasn’t one already)

    3. The key store location is not configurable. Export the keys:

      XSP_CLI/Applications/authenticationService/KeyManagement> exportKeys

    4. Copy the exported file /var/broadworks/tmp/authService.keys to the same location on the other XSPs, overwriting an older .keys file if necessary.

    5. Import the keys on each of the other XSPs:

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

  10. Provide the authService URL to the web container. The XSP’s web container needs the authService URL so it can validate tokens. On each of the XSPs:

    1. Add the authentication service URL as an external authentication service for the BroadWorks Communications Utility:

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

    2. Add the authentication service URL to the container:

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

      This enables Cisco Webex to use the Authentication Service to validate tokens presented as credentials.

    3. Check the parameter with get.

    4. Restart the XSP.

Configuring TLS and Ciphers on the HTTP Interfaces (for XSI and Authentication Service)

The Authentication Service, Xsi-Actions, and Xsi-Events applications use HTTP server interfaces. Levels of TLS configurability for these applications are as follows:

Most general = System > Transport > HTTP > HTTP Server interface = Most specific

The CLI contexts you use to view or modify the different SSL settings are:

Specificity CLI context
System (global)

XSP_CLI/System/SSLCommonSettings/JSSE/Ciphers>

XSP_CLI/System/SSLCommonSettings/JSSE/Protocols>

Transport protocols for this system

XSP_CLI/System/SSLCommonSettings/OpenSSL/Ciphers>

XSP_CLI/System/SSLCommonSettings/OpenSSL/Protocols>

HTTP on this system

XSP_CLI/Interface/Http/SSLCommonSettings/Ciphers>

XSP_CLI/Interface/Http/SSLCommonSettings/Protocols>

Specific HTTP server interfaces on this system

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

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

Reading HTTP Server TLS Interface Configuration on the XSP

  1. Sign in to the XSP and navigate to XSP_CLI/Interface/Http/HttpServer>

  2. Enter the get command and read the results. You should see the interfaces (IP addresses) and, for each, whether they are secure and whether they require client authentication.

Apache tomcat mandates a certificate for each secure interface; the system generates a self-signed certificate if it needs one.

XSP_CLI/Interface/Http/HttpServer> get

Adding TLS 1.2 Protocol to the HTTP Server Interface


This procedure applies to R22 and later. To configure TLS version on R21(SP1), you must use the XSP platform container option bw.apache.sslenabledprotocols.

The HTTP interface that is interacting with the Cisco Webex cloud must be configured for TLSv1.2. The cloud does not negotiate earlier versions of the TLS protocol.

To configure the TLSv1.2 protocol on the HTTP Server interface:

  1. Sign in to the XSP and navigate to XSP_CLI/Interface/Http/HttpServer/SSLSettings/Protocols>

  2. Enter the command get <interfaceIp> 443 to see which protocols are already used on this interface.

  3. Enter the command add <interfaceIp> 443 TLSv1.2 to ensure that interface can use TLS 1.2 when communicating with the cloud.

Editing TLS Ciphers Configuration on the HTTP Server Interface


This procedure applies to R22 and later. To configure TLS ciphers on R21(SP1), you must use the XSP platform container option bw.apache.sslciphersuite.

To configure the required ciphers:

  1. Sign in to the XSP and navigate to XSP_CLI/Interface/Http/HttpServer/SSLSettings/Ciphers>

  2. Enter the command get <interfaceIp> 443 to see which ciphers are already used on this interface. There must be at least one from the Cisco recommended suites (see XSP Identity and Security Requirements in the Overview section).

  3. Enter the command add <interfaceIp> 443 <cipherName> to add a cipher to the HTTP Server interface.


    The XSP CLI requires the IANA standard cipher suite name, not the openSSL cipher suite name. For example, to add the openSSL cipher ECDHE-ECDSA-CHACHA20-POLY1305 to the HTTP server interface, you would use: XSP_CLI/Interface/Http/HttpServer/SSLSettings/Ciphers>add 192.0.2.7 443 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

    See https://ciphersuite.info/ to find the suite by either name.

Configure Device Management on XSP, Application Server, and Profile Server

Profile Server and XSP are mandatory for Device Management. They must be configured according to instructions in the BroadWorks Device Management Configuration Guide (https://xchange.broadsoft.com/node/1031995).

CTI Interface and Related Configuration

The “inmost to outmost” configuration order is listed below. Following this order is not mandatory.

  1. Configure Application Server for CTI Subscriptions

  2. Configure XSPs for mTLS Authenticated CTI Subscriptions

  3. Open Inbound Ports for Secure CTI Interface

  4. Subscribe Your Webex Organization to BroadWorks CTI Events

Configure Application Server for CTI Subscriptions

Update the ClientIdentity on Application Server with the common name (CN) of the Webex for BroadWorks CTI client certificate.

For each Application Server you are using with Webex, add the certificate identity to the ClientIdentity as follows:

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


The common name of the Webex for BroadWorks client certificate is bwcticlient.webex.com.

Configure TLS and Ciphers on the CTI Interface

The levels of configurability for the XSP CTI interface are as follows:

Most general = System > Transport > CTI Interfaces > CTI interface = Most specific

The CLI contexts you use to view or modify the different SSL settings are:

Specificity

CLI Context

System (global)

(R22 and later)

XSP_CLI/System/SSLCommonSettings/JSSE/Ciphers>

XSP_CLI/System/SSLCommonSettings/JSSE/Protocols>

Transport protocols for this system

(R22 and later)

XSP_CLI/System/SSLCommonSettings/OpenSSL/Ciphers>

XSP_CLI/System/SSLCommonSettings/OpenSSL/Protocols>

All CTI interfaces on this system

(R22 and later)

XSP_CLI/Interface/CTI/SSLCommonSettings/Ciphers>

XSP_CLI/Interface/CTI/SSLCommonSettings/Protocols>

A specific CTI interface on this system

(R22 and later)

XSP_CLI/Interface/CTI/SSLSettings/Ciphers>

XSP_CLI/Interface/CTI/SSLSettings/Protocols>

Reading CTI TLS Interface Configuration on the XSP

  1. Sign in to the XSP and navigate to XSP_CLI/Interface/CTI/SSLSettings>

    On BroadWorks R21: navigate to XSP_CLI/Interface/CTI/SSLConfiguration>

  2. Enter the get command and read the results. You should see the interfaces (IP addresses) and, for each, whether they require a server certificate and whether they require client authentication.

Adding TLS 1.2 Protocol to the CTI Interface


This procedure applies to R22 and later. To configure the TLS version on the CTI interface for R21(SP1), you must use the tomcat container option bw.cti.sslenabledprotocols.

The XSP CTI interface that is interacting with the Cisco Webex cloud must be configured for TLS v1.2. The cloud does not negotiate earlier versions of the TLS protocol.

To configure the TLSv1.2 protocol on the CTI interface:

  1. Sign in to the XSP and navigate to XSP_CLI/Interface/CTI/SSLSettings/Protocols>

  2. Enter the command get <interfaceIp> to see which protocols are already used on this interface.

  3. Enter the command add <interfaceIp> TLSv1.2 to ensure that interface can use TLS 1.2 when communicating with the cloud.

Editing TLS Ciphers Configuration on the CTI Interface


This procedure applies to R22 and later. To configure the ciphers on the CTI interface for R21(SP1), you must use the tomcat container option bw.cti.enabledciphers.

To configure the required ciphers on the CTI interface:

  1. Sign in to the XSP and navigate to XSP_CLI/Interface/CTI/SSLSettings/Ciphers>

  2. Enter the get command to see which ciphers are already used on this interface. There must be at least one from the Cisco recommended suites (see XSP Identity and Security Requirements in the Overview section).

  3. Enter the command add <interfaceIp> <cipherName> to add a cipher to the CTI interface.


    The XSP CLI requires the IANA standard cipher suite name, not the openSSL cipher suite name. For example, to add the openSSL cipher ECDHE-ECDSA-CHACHA20-POLY1305 to the CTI interface, you would use: XSP_CLI/Interface/CTI/SSLSettings/Ciphers> add 192.0.2.7 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

    See https://ciphersuite.info/ to find the suite by either name.

Update Trust Anchors for CTI Interface (R22 and later)

This procedure assumes the XSPs are either internet-facing or face the internet via pass-through proxy. The certificate configuration is different for a bridging proxy (see TLS Certificate Requirements for TLS-bridge Proxy).

For each XSP in your infrastructure that is publishing CTI events to Webex, do the following:

  1. Sign in to Partner Hub.

  2. Go to Settings > BroadWorks Calling and click Download Webex CA Certificate to get CombinedCertChain.txt on your local computer.


    This file contains two certificates. You need to split the file before you upload it to the XSPs.

  3. Split the certificate chain into two certificates:

    1. Open combinedcertchain.txt in a text editor.

    2. Select and cut the first block of text, including the lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, and paste the text block into a new file.

    3. Save the new file as broadcloudroot.txt.

    4. Save the original file as broadcloudissuing.txt.

      The original file should now only have one block of text, surrounded by the lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.

  4. Copy both text files to a temporary location on the XSP you are securing, e.g. /tmp/broadcloudroot.txt and /tmp/broadcloudissuing.txt.

  5. Sign in to the XSP and navigate to /XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts>

  6. (Optional) Run help updateTrust to see the parameters and command format.

  7. Upload the certificate files to new trust anchors:

    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 and webexissuing are example aliases for the trust anchors; you can use your own.

  8. Confirm the anchors are updated:

    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. Allow clients to authenticate with certificates:

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

Update Trust Anchors for CTI Interface (R21)

This procedure assumes the XSPs are either internet-facing or face the internet via pass-through proxy. The certificate configuration is different for a bridging proxy (see TLS Certificate Requirements for TLS-bridge Proxy).

For each XSP in your infrastructure that is publishing CTI events to Webex, do the following:

  1. Sign in to Partner Hub.

  2. Go to Settings > BroadWorks Calling and click Download Webex CA Certificate to get CombinedCertChain.txt on your local computer.


    This file contains two certificates. You need to split the file before you upload it to the XSPs.

  3. Split the certificate chain into two certificates:

    1. Open combinedcertchain.txt in a text editor.

    2. Select and cut the first block of text, including the lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, and paste the text block into a new file.

    3. Save the new file as broadcloudroot.txt.

    4. Save the original file as broadcloudissuing.txt.

      The original file should now only have one block of text, surrounded by the lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.

  4. Copy both text files to a temporary location on the XSP you are securing, e.g. /tmp/broadcloudroot.txt and /tmp/broadcloudissuing.txt.

  5. Sign in to the XSP and navigate to /XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts>

  6. (Optional) Run help updateTrust to see the parameters and command format.

  7. Update new trust anchors with the certificates:

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

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

    (where “webexroot” and "webexissuing" are example aliases for the trust anchors, you can choose your own)

  8. Confirm both certificates are uploaded:

    /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. Allow clients to authenticate with certificates:

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

Add CTI Interface and Enable mTLS

  1. Add the CTI SSL interface.

    The CLI context depends on your BroadWorks version. The command creates a self-signed server certificate on the interface, and forces the interface to require a client certificate.

    • On BroadWorks 22 and 23.0:

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

    • On BroadWorks 21.sp1:

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

  2. Enable and define the secure CTI port on XSPs:

    XSP_CLI/Interface/CTI> set securePortEnabled true

    XSP_CLI/Interface/CTI> set securePort 8012

  3. Replace the server certificate and key on the XSP's CTI interfaces. You need the IP address of the CTI interface for this; you can read it from the following context:

    • On BroadWorks 22 and 23.0:

      XSP_CLI/Interface/CTI/SSLSettings> get

    • On BroadWorks 21.sp1:

      XSP_CLI/Interface/CTI/SSLConfiguration> get

      Then run the following commands to replace the interface’s self-signed certificate with your own certificate and private key:

      On BroadWorks 22.0 and 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>

      On 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. Restart the XSP.

Open Inbound Ports for Secure CTI Interface

Open the secure port for CTI on your firewall (TCP 8012 by default) for an inbound TLS connection to your XSP CTI interface.

To check that the secure port is enabled, and its port number:

  1. Sign in to the XSP CLI and navigate to the XSP_CLI/Interface/CTI> context.

  2. Enter get.

Among other information, you should see the following:

securePortEnabled = true

securePort = 8012

This ensures that Webex can initiate an encrypted connection.

Webex only uses the secure port, so we recommend that you set portEnabled = false to disable the unsecured port.

Enable Access to BroadWorks CTI Events on Cisco Webex

You need to add and validate the CTI interface when you configure your clusters in Partner Hub. See Configure Your Partner Organization in Control Hub for detailed instructions.

  • Specify the CTI address by which Cisco Webex can subscribe to BroadWorks CTI Events.

  • CTI subscriptions are on a per-subscriber basis and are only established and maintained while that subscriber is provisioned for Webex for BroadWorks.

Call Settings Webview

Call Settings Webview (CSWV) is an application hosted on XSP (or ADP) to enable users to modify their BroadWorks call settings through a webview that they see in the soft client. There is a detailed CSWV Solution Guide at https://xchange.broadsoft.com/node/1050149.

Webex makes use of this feature to provide users with access to common BroadWorks call settings that are not native to the Webex app.

If you want your Webex for BroadWorks subscribers to access call settings beyond the defaults available in the Webex app, you need to deploy Call Settings Webview feature.

Call Settings Webview has two components:

  • Call Settings Webview application, hosted on a Cisco BroadWorks XSP (or ADP).

  • The Webex app, which renders the call settings in a Webview.

User Experience

  • Windows users: Click profile picture, then Settings > Calling > Self Care.

  • Mac users: Click profile picture, then Preferences > Calling > Self Care

Deploy CSWV on BroadWorks

Install Call Settings Webview on XSPs

CSWV application must be on the same XSP(s) that host the Xsi-Actions interface in your environment. It is an unmanaged application on XSP, so you need to install and deploy a web archive file.

  1. Sign in to Xchange and search for "BWCallSettingsWeb" in the software download section.

  2. Find and download the most recent version of the file.

    For example, BWCallSettingsWeb_1.8.2_1.war (https://xchange.broadsoft.com/node/1057167) was the most recent at the time of writing.

  3. Install, activate, and deploy the web archive according to the Xtended Service Platform Configuration Guide for your XSP version. (R23 version is https://xchange.broadsoft.com/node/1033484).

    1. Copy the .war file to a temporary location on the XSP, such as /tmp/.

    2. Navigate to the following CLI context and run the install command:

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

      The BroadWorks software manager validates and installs the file.

    3. [Optional] Delete /tmp/BWCallSettingsWeb_1.7.5_1.war (this file is no longer required).

    4. Activate the application:

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

      The name and version are mandatory for any application, but for CSWV you must also provide a contextPath because it is an unmanaged application. You can use any value that is not used by another application, for example, /callsettings.

    5. Deploy the Call Settings application on the selected context path:

      XSP_CLI/Maintenance/ManagedObjects> deploy application /callsettings

  4. You can now predict the call settings URL that you will specify for clients, as follows:

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

    Notes:

    • You must supply the trailing slash on this URL when you enter it in the client configuration file.

    • The XSP-FQDN must match the Xsi-Actions FQDN, because CSWV needs to use Xsi-Actions, and CORS is not supported.

  5. Repeat this procedure for other XSPs in your Webex for BroadWorks environment (if necessary)

The Call Settings Webview application is now active on the XSPs.

Additional Configuration for XSP R21

If you're deploying the CSWV application on an R21 XSP:

  1. Navigate to the call settings application context and run get to read its configuration: XSP_CLI/Applications/BWCallSettingsWeb_1.7.5/General> get

    You should see the following parameters and values:

    xsiActionsContextOrURL=/com.broadsoft.xsi-actions
    displayCriteriaOrScheduleName=criteria
    applicationMode=prod
    
  2. Use set (if necessary) to change the parameters to the values shown above.

  3. Repeat for other R21 XSPs if necessary.

Configure the Webex app to Use Call Settings Webview

For more detail on client configuration, see Webex App for BroadWorks Client Configuration Guide on Xchange for your Webex app version. For example, the September 2020 version of this file is at https://xchange.broadsoft.com/node/1054075

There's a custom tag in the Webex app configuration file that you can use to set the CSWV URL. This URL shows the call settings to the users through the application's interface.

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

In the Webex app configuration template on BroadWorks, configure the CSWV URL in the %WEB_CALL_SETTINGS_URL_WXT% tag.

If you do not explicitly specify the URL, the default is empty and the call settings page is not visible to the users.

  1. Make sure you have the latest configuration templates for the Webex app (see Device Profiles).

  2. Set the Web Call Settings Target to csw:

    %WEB_CALL_SETTINGS_TARGET_WXT% csw

  3. Set the Web Call Settings URL for your environment, for example:

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

    (You derived this value when deploying the CSWV application)

  4. The resulting client configuration file should have an entry as follows:
    <web-call-settings target="csw">
        <url>https://yourxsp.example.com/callsettings/</url>
    </web-call-settings>

Configure Call Push Notifications in Webex for BroadWorks

In this document we use the term Call Notifications Push Server (CNPS) to describe an XSP-hosted, or ADP-hosted application that runs in your environment. Your CNPS works with your BroadWorks system to be aware of incoming calls to your users, and pushes notifications of those to the Google Firebase Cloud Messaging (FCM) or Apple Push Notification service (APNs) notification services.

Those services notify the mobile devices of Webex for BroadWorks subscribers that they have incoming calls on Webex.

For more information about NPS, see the Notification Push Server Feature Description at https://xchange.broadsoft.com/node/485737.

A similar mechanism in Webex works with Webex messaging and presence services to push notifications to the Google (FCM) or Apple (APNS) notification services. Those services in turn notify the mobile Webex users of incoming messages or presence changes.


This section describes how to configure NPS for authentication proxy when the NPS does not already support other apps. If you need to migrate a shared NPS to use NPS proxy, see Updating Cisco BroadWorks NPS to Use NPS Proxy https://help.webex.com/nl5rir2/.

NPS Proxy Overview

For compatibility with Webex for BroadWorks, your CNPS must be patched to support the NPS Proxy feature, Push Server for VoIP in UCaaS.

The feature implements a new design in the Notification Push Server to resolve the security vulnerability of sharing push notification certificate private keys with service providers for mobile clients. Instead of sharing push notification certificates and keys with the service provider, the NPS uses a new API to obtain a short-lived push notification token from Webex for BroadWorks backend, and uses this token for authentication with the Apple APNs and Google FCM services.

The feature also enhances the capability of the Notification Push Server to push notifications to Android devices through the new Google Firebase Cloud Messaging (FCM) HTTPv1 API.

APNS Considerations

Apple will no longer support the HTTP/1-based binary protocol on the Apple Push Notification service after March 31, 2021. We recommend that you configure your XSP to use the HTTP/2-based interface for APNs. This update requires that your XSP hosting the NPS be running R22 or later.

Prepare Your NPS for Webex for BroadWorks

1

Install and configure a dedicated XSP (minimum version R22), or Application Delivery Platform (ADP).

2

Install the NPS Authentication Proxy patches:

XSP R22 patches:

XSP R23 patches:

3

Activate the Notification Push Server application.

4

(For Android notifications) Enable the FCM v1 API on the NPS.

XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true

5

(For Apple iOS notifications) Enable HTTP/2 on the NPS.

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

6

Attach a techsupport from the NPS XSP/ADP.

What to do next

For fresh installs of an NPS, go to Configure NPS to Use Authentication Proxy

To migrate an existing Android deployment to FCMv1, go to Migrate NPS to FCMv1

Configure NPS to Use Authentication Proxy

This task applies to a new installation of NPS, dedicated to Webex for BroadWorks.

If you want to configure the authentication proxy on an NPS that is shared with other mobile apps, see Updating Cisco BroadWorks NPS to Use NPS Proxy (https://help.webex.com/nl5rir2).

1

Create a service request with your onboarding contact, or with TAC, to provision your (Webex Common Identity) OAuth client account. Title your service request NPS Configuration for Auth Proxy Setup.

Cisco gives you an OAuth client ID, a client secret, and a refresh token that is valid for 60 days. If the token expires before you use it with your NPS, you can raise another request.
2

Create the client account on the 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

To verify the values you entered match with what you were given, run XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> get

3

Enter the NPS Proxy URL, and set the token refresh interval (30 minutes recommended):

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

XSP_CLI/Applications/NotificationPushServer/CloudNPSService> set VOIPTokenRefreshInterval 1800

4

(For Android notifications) Add the Android application ID to the FCM applications context on the NPS.

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

5

(For Apple iOS notifications) Add the application ID to the APNS applications context, making sure to omit the Auth key – set it to empty.

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

6

Configure the following NPS URLs:

XSP CLI Context

Parameter

Value

  • 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

Configure the following NPS connection parameters to the recommended values shown:

XSP CLI Context

Parameter

Value

  • 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

Check if the Application Server is screening application IDs, because you may need to add the Webex apps to the allow list:

  1. Run AS_CLI/System/PushNotification> get and check the value of enforceAllowedApplicationList. If it is true, you need to complete this sub task. Otherwise, skip the rest of the sub task.

  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

Restart the XSP: bwrestart

10

Test call notifications by making calls from a BroadWorks subscriber to two Webex mobile users. Verify that call notification appears on iOS and Android devices.

Migrate NPS to FCMv1

This topic contains optional procedures that you can use in Google FCM Console when you have an existing NPS deployment that you need to migrate to FCMv1. There are three procedures:

Migrate UCaaS Clients to FCMv1

Use the below steps in Google FCM Console to migrate UCaaS clients to Google FCM HTTPv1.


If branding is applied to the client, the client must have the Sender ID. In the FCM Console, see Project Settings > Cloud Messaging. The setting appears in the Project credentials table.

For details, see the Connect Branding Guide at https://xchange.broadsoft.com/node/1053211. Refer to the gcm_defaultSenderId parameter, which is located in the Branding Kit, Resource folder, branding.xml file with the below syntax:

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

  1. Log into FCM Admin SDK at http://console.firebase.google.com.

  2. Select the appropriate Android application.

  3. In the General tab, record the project ID

  4. Navigate to the service accounts tab to configure a service account. You can create a new service account or configure an existing one.

    To create a new Service Account:

    1. Click the blue button for create new service account

    2. Click on the blue button to generate a new private key

    3. Download key to a secure location

    To reuse an existing service account:

    1. Click on the blue text to view existing service accounts.

    2. Identify the service account to use. Service account needs permission firebaseadmin-sdk.

    3. On the very right, click the hamburger menu and create a new private key.

    4. Download key to a secure location.

  5. Copy the key onto the XSP.

  6. Configure the project ID and :

    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. Configure the application:

    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. Enable FCMv1:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  9. Run the bwrestart command to restart the XSP.

Migrate SaaS Clients to FCMv1

Use the below steps on Google FCM Console if you want to migrate SaaS clients to FCMv1.


Make sure that you have already completed the procedure "Configure NPS to Use Authentication Proxy".
  1. Disable FCM:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled false
    ...Done
  2. Run the bwrestart command to restart the XSP.

  3. Enable FCM:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  4. Run the bwrestart command to restart the XSP.

Update ADP Server

Use the below steps in Google FCM Console if you are migrating the NPS to use an ADP server.

  1. Get the JSON file from the Google Cloud Console:

    1. On the Google Cloud Console, go to the Service Accounts page.

    2. Click Select a project, choose your project and click Open.

    3. Find the row of the service account that you want to create a key for, click the More vertical button, then click Create key.

    4. Select a Key type and click Create

      The file downloads.

  2. Add FCM to the ADP server:

    1. Import the JSON file to the ADP server using the /bw/install command.

    2. Login to the ADP CLI and add Project and API key:

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

    3. Next, add the Application and key:

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

    4. Verify the configuration:

      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

Configure Your Partner Organization in Partner Hub

Configure Your BroadWorks Clusters

[once per cluster]

This is done for the following reasons:

  • To enable Webex cloud to authenticate your users against BroadWorks (via XSP-hosted authentication service).

  • To enable Webex apps to use Xsi interface for call control.

  • To enable Webex to listen for CTI events published by BroadWorks (telephony presence).


The cluster wizard automatically validates the interfaces as you add them. You can continue editing the cluster if any of the interfaces do not validate successfully, but you cannot save a cluster if there are invalid entries.

We prevent this because a misconfigured cluster could cause issues that are difficult to solve.

What you need to do:

  1. Sign in to Partner Hub (admin.webex.com) with your partner administrator credentials.

  2. Open Settings page from the side menu, and find BroadWorks Calling settings.

  3. Click Add Cluster.

    This launches a wizard where you supply your XSP interfaces (URLs). You can add a port to the interface URL if you are using a non-standard port.

  4. Name this cluster and click Next.

    The cluster concept here is simply a collection of interfaces, typically collocated on an XSP server or farm, that enable Webex to read information from your Application Server (AS). You may have one XSP per AS cluster, or multiple XSPs per cluster, or multiple AS clusters per XSP. Scale requirements for your BroadWorks system are out of scope here.

  5. (Optional) Enter a BroadWorks user Account Name and Password that you know is within the BroadWorks system you are connecting to Webex, then click Next.

    The validation tests can use this account to validate the connections to the interfaces in the cluster.

  6. Add your XSI Actions and XSI Events URLs and click Next.

  7. Add your CTI Interface URL and click Next.

  8. Add your Authentication Service URL.

  9. Select Auth Service with CI token validation.

    This option does not require mTLS to protect the connection from Webex, because the Authentication Service properly validates the user token against the Webex identity service before it issues the long-lived token to the user.

  10. Review your entries on the final screen, and then click Create. You should see a success message.

    Partner Hub passes the URLs to various Webex microservices that test the connections to the supplied interfaces.

  11. Click View Clusters and you should see your new cluster, and whether the validation succeeded.

  12. The Create button may be disabled on the final (preview) screen of the wizard. If you cannot save the template, it indicates a problem with one of the integrations you just configured.

    We implemented this check to prevent errors in subsequent tasks. You can go back through the wizard as you configure your deployment, which may require modifications to your infrastructure (e.g. XSP, load balancer, or firewall) as documented in this guide, before you can save the template.

Checking the Connections to Your BroadWorks Interfaces

  1. Sign in to Partner Hub (admin.webex.com) with your partner administrator credentials.

  2. Open Settings page from the side menu, and find BroadWorks Calling settings.

  3. Click View Clusters.

  4. Partner Hub initiates connectivity tests from the various microservices towards the interfaces in the clusters.

    After the tests complete, the cluster list page shows status message next to each cluster.

    You should see green Success messages. If you see a red Error message, click the affected cluster name to see which setting is causing the problem.

Configure your Customer Templates

Customer templates are the way that you will apply shared configuration to one or more customers as you onboard them via the provisioning methods. You must associate each template with a cluster (that you created in previous section).

You can create as many templates as you need, but only one template can be associated with a customer.

  1. Sign in to Partner Hub (admin.webex.com) with your partner administrator credentials.

  2. Open Settings page from the side menu, and find BroadWorks Calling settings.

  3. Click Add Template.

    This launches a wizard where you can supply configuration for customers that will use this template.

  4. Use the Cluster dropdown to choose the cluster you want to use with this template.

  5. Enter a Template Name, then click Next.

  6. Configure your provisioning mode, using these recommended settings:

    Table 2. Recommended Provisioning Settings for Different Provisioning Modes

    Setting Name

    Flowthrough provisioning with trusted emails

    Flowthrough provisioning without emails

    User self-provisioning

    Enable BroadWorks Flow Through Provisioning (include provisioning account credentials if On)

    On

    Supply the provisioning Account Name and Password as per BroadWorks configuration.

    On

    Supply the provisioning Account Name and Password as per BroadWorks configuration.

    Off

    Automatically Create New Organizations in Control Hub

    On

    On

    On

    Service Provider Email Address

    Select an email address from the dropdown (you can type some characters, to find the address if it's a long list).

    This email address identifies the administrator within your Partner organization who will be granted delegated admin access to any new customer organizations created with the customer template.

    Country

    Choose which country you use for this template.

    The country you choose matches customer organizations that are created with this template to a particular region. At present, the region could be (EMEAR) or (North America and rest of world). See the country to region mappings in this spreadsheet.

    BroadWorks Enterprise Mode Active

    Enable this if the customers you provision with this template are enterprises in BroadWorks.

    If they are groups, leave this switch off.

    If you have a mix of enterprises and groups in your BroadWorks, you should create different templates for those different cases.

    • Notes from the table:

    • † This switch ensures that a new customer organization is created if a subscriber’s email domain does not match an existing Webex organization.

      This should always be on, unless you are using a manual ordering and fulfilment process (via Cisco Commerce Workspace) to create customer organizations in Webex (before you start provisioning users in those organizations). That option is often referred to as the "Hybrid Provisioning" model, and is out of the scope of this document.

  7. Select the default services package for customers using this template (see Packages in the Overview section); either Basic, Standard, Premium or Softphone.

    You can override this setting for individual users via Partner Hub.

  8. Select the default authentication mode (either BroadWorks Authentication or Webex Authentication) for customers using this template.

    (See Authentication Mode in the Prepare your Environment section).

  9. Configure the way users verify their identies to Webex. The settings on this page correspond with your chosen user provisioning mode as shown in the table:

    Table 3. Recommended User Verification Settings for Different Provisioning Modes

    Setting Name

    Flowthrough provisioning with trusted emails

    Flowthrough provisioning without emails

    User self-provisioning

    User Verification

    Trust BroadWorks emails

    Untrusted Emails

    Untrusted Emails

    First user provisioned is admin

    Recommended*

    Recommended*

    Not applicable

    Allow users to self activate

    Not applicable

    Not applicable

    Required

    • Notes from the table:

    • * The first user to whom you assign Integrated IM&P in BroadWorks takes the customer administrator role if a new customer organization is created in Webex. Choose this setting to give you some control over who takes the role. If you uncheck this setting, then the first user to become active in the new organization becomes the customer administrator.

      You can modify the customer user roles in Partner Hub after provisioning, if necessary.

  10. Choose whether you want to Prefill user email addresses in login page.

    You should only use this option if you selected BroadWorks Authentication and have also have put the users’ email addresses in the Alternate ID attribute in BroadWorks. Otherwise, they will need to use their BroadWorks username. The login page gives an option to change user, if necessary, but this may lead to login issues.

  11. Choose whether to Enable directory synchronisation.

    This option enables Webex to read BroadWorks contacts into the customer organization, so that users can find and call them from the Webex app.

  12. Enter a Partner Admin.

    This name is used in the automated email message from Webex, that invites users to validate their email addresses.

  13. Review your entries on the final screen. You can click the navigation controls at the top of the wizard to go back and change any details. Click Create.

    You should see a success message.

  14. Click View Templates and you should see your new template listed with any other templates.

  15. Click the template name to modify or delete the template, if necessary.

    You do not need to re-enter the provisioning account details. The empty password/password confirm fields are there to change the credentials if you need to, but leave them empty to keep the values you gave to the wizard.

  16. Add more templates if you have different shared configurations you want to provide to customers.


    Keep the View Templates page open, as you may need template details for a following task.

Configure Application Server with Provisioning Service URL


This task is only required for flow through provisioning.

Patch Application Server

  1. Apply the patch ap373197 (See BroadWorks Software Requirements in the Reference section).

  2. Change to the Maintenance/ContainerOptions context.

  3. Enable the provisioning URL parameter:

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

Get the Provisioning URL(s) from Partner Hub

Refer to the Cisco BroadWorks Application Server Command Line Interface Administration Guide for details (Interface > Messaging and Service > Integrated IM&P) of the AS commands.

  1. Sign in to Partner Hub and go to Settings > BroadWorks Calling.

  2. Click View Templates.

  3. Select the template you’re using to provision this enterprise/group’s subscribers in Webex.

    The template details display in a flyout pane on the right. If you haven’t yet created a template, you need to do that before you can get the provisioning URL.

  4. Copy the Provisioning Adapter URL.

Repeat this for other templates if you have more than one.

(Option) Configure System-Wide Provisioning Parameters on Application Server


You may not want to set system-wide provisioning and service domain if you are using UC-One SaaS. See Decision Points in the Prepare your Environment section.

  1. Sign in to the Application Server and configure the messaging interface.

    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. Activate the Integrated IMP interface:

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

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


You must enter the fully qualified name for the provisioningURL parameter, as it was given in Control Hub. If your Application Server cannot access DNS to resolve the hostname, then you must create the mapping in the /etc/hosts file on the AS.

(Option) Configure Per-Enterprise Provisioning Parameters on Application Server

  1. In BroadWorks UI, open the enterprise you want to configure, and go to Services > Integrated IM&P.

  2. Select Use service domain and enter a dummy value (Webex ignores this parameter. You could use example.com).

  3. Select Use Messaging Server.

  4. In the URL field, paste the provisioning URL you copied from your template in Partner Hub.


    You must enter the fully qualified name for the provisioningURL parameter, as it was given in Partner Hub. If your Application Server cannot access DNS to resolve the hostname, then you must create the mapping in the /etc/hosts file on the AS.

  5. In the Username field, enter a name for the provisioning administrator. This must match the value on the template in Partner Hub.

  6. Enter a password for the provisioning administrator. This must match the value on the template in Partner Hub.

  7. For Default User Identity for IM&P ID, select Primary.

  8. Click Apply.

  9. Repeat for other enterprises you want to configure for flow through provisioning.

Directory Synchronisation

Directory synchronisation ensures that Webex for BroadWorks users can use the Webex directory to call any calling entity from the BroadWorks server. This feature ensures that even telephony entities without a messaging client are synced to the Webex directory.


Webex for BroadWorks provisioning includes a default sync of messaging users and their associated calling information from the BroadWorks server to the Webex directory. However, the provisioning sync omits users whom are not enabled for messaging and non-user entities (for example, a conference room phone, fax machine or hunt group number). You must enable directory synchronisation to ensure that these omitted calling entities get added to the Webex directory.

Directory Synchronisation Conditions

  • The Directory Synchronisation sync runs weekly for a given customer template. The initial sync gets scheduled for the week following the enabling of the sync (the time chosen to start the sync is random).

  • If a sync failure occurs, the sync is reattempted automatically every 24 hours until the next scheduled sync.

  • You can view sync status in Control Hub (with last successful sync information) for a given customer template.

  • Turning on Synchronisation for a given customer template enables synchronisation for all organizations whom use that template. If there is a sync failure with one or more of these organizations, the status displays a partial failure.

  • The sync ignores users whom do not have a phone number.

  • Each Webex app has a local cache that may take up to 72 hours to clear before the post-sync updates appear in the Webex app. This delay holds whether you are enabling or disabling the feature.

Before You Begin

We recommend that you use the following settings:

  • Rate Limiting Values—Set the following OverloadControl system properties (XSP_CLI/Applications/Xsi-Actions/OverloadControl):

    • userTransactionLimits—Set to 100.

    • transactionLimitPeriodSeconds—Set to 1.

    • userDirectoryTransactionLimit—Set to a null value.

    • globalDirectoryTransactionLimit—Set to a null value.


    It's recommended that you set userDirectoryTransactionLimit and globalDirectoryTransactionLimit to a null value. However, if you do decide to assign values, each must be set to at least five times the value of transactionLimitPeriodSeconds (which should be 1).
  • Paging Values—Set the Paging system properties (XSP_CLI/Applications/Xsi-Actions/Paging):

    • defaultPageSize—Set to 50

    • availableUserMaxLimit—Set to 100

  • CTI Interface—Make sure to upload that Webex CA certificates to the CTI interface trust store and to enable client authentication on the CTI interface.

In addition, we recommend that you apply system patch ap368517 to your BroadWorks deployment before you enable this feature (for patch information, see BroadWorks Software Requirements in the Reference section).

Procedure

Complete the following steps to turn on Directory Synchronisation:

  1. In Partner Hub, choose Settings.

  2. Scroll to BroadWorks Calling and click View Template.

  3. Select the appropriate template.

  4. Scroll to BroadWorks Directory Sync and set the Enable directory synchronisation toggle to On.

  5. Click Save.


To disable Directory Synchronization, set the Enable directory synchronisation toggle to Off. This will remove BroadWorks-only users from the Webex directory.

Call Recording

Webex for BroadWorks supports four modes of call recording.

Table 4. Recording Modes

Recording Modes

Description

Controls/Indicators that display on Webex app

Always

Recording is initiated automatically when the call is established. The user has no ability to start or stop recording.

  • Visual indicator that recording is in progress

Always with Pause/Resume

Recording is initiated automatically when the call is established. User can pause and resume recording.

  • Visual indicator that recording is in progress

  • Pause Recording button

  • Resume Recording button

OnDemand

Recording is initiated automatically when call is established, but the recording is deleted unless the user presses Start Recording.

If user starts recording, the full recording from call setup is retained. After starting the recording, user can also pause and resume recording

  • Start Recording button

  • Pause Recording button

  • Resume Recording button

OnDemand with User-Initiated Start

Recording does not initiate unless the user selects the Start Recording option on the Webex app. The user has the option to start and stop recording multiple times during a call.

  • Start Recording button

  • Stop Recording button

  • Pause Recording button

Requirements

To deploy this feature on Webex for BroadWorks, you must deploy the following BroadWorks patches:

  • AP.as.22.0.1123.ap377718

  • AP.as.23.0.1075.ap377718

  • AP.as.24.0.944.ap377718

The AS must be configured to send the X-BroadWorks-Correlation-Info SIP header:

  • AS_CLI/Interface/SIP> set sendCallCorrelationIDNetwork true

  • AS_CLI/Interface/SIP> set sendCallCorrelationIDAccess true

The following configuration tag must be enabled in order to use this feature: %ENABLE_CALL_RECORDING_WXT%.

This feature requires an integration with a third-party call recording platform.

To configure call recording on BroadWorks, go to the Cisco BroadWorks Call Recording Interface Guide at https://xchange.broadsoft.com/node/1033722.

Additional Information

For user information on how to use the Recording feature, go to Webex | Record Your Calls.

To replay a recording, users or administrators must go to their third-party call recording platform.

Group Call Park and Retrieve

Webex for BroadWorks supports Group Call Park and Retrieve. This feature provides a way for users within a group to park calls, which can then be retrieved by other users in the group. For example, retail employees in a store setting could use the feature to park a call that can then be picked up by someone in another department.

To deploy the feature, an administrator must create a call park group and add users to the group. Once the feature is configured:

  • While in a call, a user clicks the Park option on their Webex app to park the call at an extension that the system selects automatically. The system displays the extension to the user for a period of 10 seconds.

  • Another user in the group clicks the Retrieve call option on their Webex app. The user then enters the extension of the parked call in order to continue the call.

For administration details on how to configure this feature on BroadWorks, refer to the Call Park section of the BroadWorks Application Server Group Web Interface Administration Guide – Part 2 at https://xchange.broadsoft.com/node/1051947.

Additional Information

For user information on how to use Group Call Park, see Webex | Park and Retrieve Calls.

Call Park/Directed Call Park

Regular or directed call park is not supported in the Webex app UI, but provisioned users can deploy the feature using Feature Access Codes:

  • Enter *68 to park a call

  • Enter *88 to retrieve a call

Customize and Provision Clients

Users download and install their generic Webex apps, for desktop or mobile (see Webex App Platforms in the Prepare Your Environment section). Once the user authenticates, the client registers against the Cisco Webex cloud for messaging and meetings, retrieves its branding info, discovers its BroadWorks service info and downloads its calling configuration from BroadWorks Application Server (via DMS on XSP).

You configure the calling parameters for Webex apps in BroadWorks (as normal). You configure branding, messaging, and meeting parameters for the clients in Control Hub. You do not directly modify a configuration file.

These two sets of configurations can overlap, in which case the Webex configuration supersedes the BroadWorks configuration.

Add Webex Apps Configuration Templates to BroadWorks Application Server

Webex apps are configured with DTAF files. The clients download a configuration XML file from the Application Server, via the Device Management service on the XSP.

  1. Get the required DTAF files (see Device Profiles in the Prepare Your Environment section).

  2. Check that you have the right tag sets in BroadWorks System > Resources > Device Management Tag Sets.

  3. For each client you're provisioning:

    1. Download and extract the DTAF zip file for the particular client.

    2. Import DTAF files to BroadWorks at System > Resources > Identity/Device Profile Types

    3. Open the newly added device profile for editing and enter the XSP farm FQDN and Device Access Protocol.

    4. Modify the templates according to your environment (see table below).

    5. Save the profile.

  4. Click Files and Authentication and then select the option to rebuild all system files.

Name

Description

Codec Priority

Configure priority order for the audio and video codecs for VoIP calls

TCP, UDP and TLS

Configure the protocols used for SIP signaling and media

RTP Audio and Video Ports

Configure port ranges for RTP audio and video

SIP options

Configure various options related to SIP (SIP INFO, use rport, SIP proxy discovery, refresh intervals for registration and subscription, etc.)

Customize Clients in Control Hub

There are separate branding configurations for desktop and mobile clients, so you must repeat this branding process if using both:

  1. Sign in to Control Hub and go to Configuration > Clients.

  2. Locate the Branding area of the client configuration page.

  3. Update logo and primary navigation bar color. For more information, see Add Your Company Branding to Webex.


The User Activation Portal uses the same logo you add for Client Branding.

Customize Problem Reporting and Help URLs

See https://help.webex.com/n0cswhcb “Customize Branding and Problem Reporting for Customers”.

Configure Your Test Organization for Webex for BroadWorks

Before you begin

With Flowthrough Provisioning

You must configure all the XSP services, and the partner organization in Control Hub, before you can perform this task.

1

Assign Service in BroadWorks:

  1. Create a test enterprise under your service provider enterprise in BroadWorks, or create a test group under your Service Provider (depends on your BroadWorks setup).

  2. Configure the IM&P service for that enterprise, to point to the template you are testing (retrieve the provisioning adapter URL and credentials from Control Hub customer template).

  3. Create test subscribers in that enterprise / group.

  4. Give the users unique email addresses in the email field in BroadWorks. Copy those into the Alternate ID attribute as well.

  5. Assign the Integrated IM&P service to those subscribers.


     

    This triggers the creation of the customer organization and the first users, which takes several minutes. Please wait a little while before trying to sign in with your new users.

2

Verify Customer Organization and Users in Control Hub:

  1. Sign in to Control Hub with your partner administrator account.

  2. Go to Customers and verify that your new customer organization is in the list (name follows the group name or enterprise name, from BroadWorks).

  3. Open the customer organization and verify that the subscribers are users in that organization.

  4. Verify that the first subscriber to whom you assigned the Integrated IM&P service has become the customer administrator of that organization.

User Testing

1

Download the Webex app on two different machines.

2

Sign in as your test users on the two machines.

3

Make test calls.