Deploy Webex for Cisco BroadWorks

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.

Only one instance of the Xsi-Events applications should be deployed on the XSP/ADP used for the CTI interface.

All Xsi-Events used for integrating Broadworks with Webex must have the same callControlApplicationName defined under Applications/Xsi-Events/GeneralSettings. For example:

ADP_CLI/Applications/Xsi-Events/GeneralSettings> get

callControlApplicationName = com.broadsoft.xsi-events

When a user is onboarded to Webex, Webex creates a subscription for the user on the AS in order to receive telephony events for presence and call history. The subscription is associated with the callControlApplicationName and the AS uses it to know to which Xsi-Events to send the telephony events.

Note	Changing the callControlApplicationName, or not having the same name on all Xsi-Events webapps will impact subscriptions and telephony events functionality.

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.

Note

Mutual TLS (mTLS) is also supported as an alternative authentication method for the Auth Service. If you have multiple Webex organizations running off the same XSP server, you must use mTLS authentication because CI Token Validation does not support multiple connections to the same XSP Auth Service. To configure mTLS authentication for the Auth Service instead of CI Token Validation, refer to the Appendix for Configure Services (with mTLS for the Auth Service).

Note	If you currently use mTLS for the Auth Service, it's not mandatory that you reconfigure to use CI Token Validation with TLS.

1. Obtaining OAuth credentials for your Webex for Cisco BroadWorks.

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

     AP.xsp.22.0.1123.ap368601

   • 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. Starting with Broadworks build 2022.10, the certificates authorities that are coming with Java are no longer automatically included to the BroadWorks trust store when switching to a new version of java. The AuthenticationService opens a TLS connection to Webex to fetch the access token, and needs to have the following in its truststore to validate the IDBroker and Webex URL:

   • IdenTrust Commercial Root CA 1

   • Go Daddy Root Certificate Authority - G2

   Verify that these certificates are present under the following CLI

   ADP_CLI/System/SSLCommonSettings/Trusts/Defaults> get

   If not present, run the following command to import the default Java trusts:

   ADP_CLI/System/SSLCommonSettings/Trusts/Defaults> importJavaCATrust

   Alternatively, you can manually add these certificates as trust anchors with the following command:

   ADP_CLI/System/SSLCommonSettings/Trusts/BroadWorks> updateTrust <alias> <trustAnchorFile>

   If the ADP is upgraded from a previous release, then the certificate authorities from the old release are automatically imported to the new release and will continue to be imported until they are manually removed.

   Note	The AuthenticationService application is exempt from the validatePeerIdentity setting under ADP_CLI/System/SSLCommonSettings/GeneralSettings, and always validates the peer Identity. See the Cisco Broadworks X509 Certificate Validation FD for more info on this setting.

5. Configure the Identity Providers by running the following commands on each XSP server:

   XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco> get

   • set clientId client-Id-From-Step1

   • set enabled true

   • set clientSecret client-Secret-From-Step1

   • set ciResponseBodyMaxSizeInBytes 65536

   • set issuerName <URL>—For the URL, enter the IssuerName URL that applies to your CI Cluster. See following table.

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

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

   Table 1. Set issuerName and issuerURL

   If CI Cluster is...	Set issuerName and issuerURL to...
   US-A	https://idbroker.webex.com/idb
   EU	https://idbroker-eu.webex.com/idb
   US-B	https://idbroker-b-us.webex.com/idb
   Note   If you don't know your CI Cluster, you can obtain the information from the Customer details in Help Desk view of Control Hub.

   Table 2. Set tokenInfoURL

   If Teams Cluster is...	Set tokenInfoURL to...(IdP Proxy URL)
   ACHM	https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate
   AFRA	https://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate
   AORE	https://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate
   Note   If you don't know your Teams Cluster, you can obtain the information from the Customer details in the Help Desk view of Control Hub. For testing, you can verify that the tokenInfoURL is valid by replacing the "idp/authenticate" portion of the URL with "ping".

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

7. 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 refresh-Token-From-Step1

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

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

   • XSP_CLI/Applications/AuthenticationService/TokenManagement>

   • set tokenIssuer BroadWorks

   • set tokenDurationInHours 720

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

    Note	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

11. 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 Webex to use the Authentication Service to validate tokens presented as credentials.

    3. Check the parameter with get.

    4. Restart the XSP.

Remove Client Authentication Requirement for Auth Service (R24 only)

If you have the Authentication Service configured with CI Token validation on R24, you also need to remove the Client Authentication Requirement for the Authentication Service. Run the following CLI command:

ADP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> set <interfaceIp> <port> AuthenticationService clientAuthReq false

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:

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

The HTTP interface that is interacting with the 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

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.

   Note

   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.

Configure Application Server for CTI Subscriptions

Update the ClientIdentity on Application Server with the common name (CN) of the Webex for Cisco 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

Note	The common name of the Webex for Cisco 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:

Note

On a fresh install, the following ciphers are installed by default at the system level. If nothing is configured at the interface level (for example, at the CTI interface or HTTP interface), this cipher list applies. Note that this list may change over time: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

Reading CTI TLS Interface Configuration on the XSP

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

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.

   XSP_CLI/Interface/CTI/CTIServer> get
     Interface IP  Port  Secure  Server Certificate  Client Auth Req
   =================================================================
     10.155.6.175  8012    true                true             true
   

Adding TLS 1.2 Protocol to the CTI Interface

The XSP CTI interface that is interacting with the 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/CTIServer/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

To configure the required ciphers on the CTI interface:

1. Sign in to the XSP and navigate to XSP_CLI/Interface/CTI/CTIServer/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.

   Note

   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/CTIServer/SSLSettings/Ciphers> add 192.0.2.7 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 See https://ciphersuite.info/ to find the suite by either name.

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 CombinedCertChain2023.txt on your local computer.

   Note	These files contain two sets of two certificates. You need to split the files before you upload them to the XSPs. All files are required.

3. Split the certificate chain into two certificates - combinedcertchain2023.txt

   1. Open combinedcertchain2023.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 root2023.txt.

   4. Save the original file as issuing2023.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. /var/broadworks/tmp/root2023.txt and /var/broadworks/tmp/issuing2023.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 - 2023

   XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientroot2023 /var/broadworks/tmp/root2023.txt

   XSP_CLI/Interface/CTI/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientissuing2023 /var/broadworks/tmp/issuing2023.txt

   Note	All aliases must have a different name. webexclientroot2023, and webexclientissuing2023 are example aliases for the trust anchors; you can use your own as long as all entries are unique.

8. Confirm the anchors are updated:

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

     Alias   Owner                                   Issuer
   =============================================================================
   webexclientissuing2023       Internal Private TLS SubCA      Internal Private Root
   webexclientroot2023       Internal Private Root      Internal Private Root[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 R22 and R23:

     XSP_CLI/Interface/CTI/CTIServer> add <Interface IP> 8012 true true true

2. 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 R22 and R23:

     XSP_CLI/Interface/CTI/CTIServer> get

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

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

3. Restart the XSP.

Enable Access to BroadWorks CTI Events on Webex

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

• Specify the CTI address by which 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 Cisco BroadWorks.

User Experience

• Windows users: Click Call Settings and then click Open Call Preferences > Advanced Call Settings.

• Mac users: Click profile picture, then Preferences > Advanced Call Settings.

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 cisco.com 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://software.cisco.com/download/home/286326302/type/286326345/release/RI.2022.04) was the most recent at the time of writing.

3. Install, activate, and deploy the web archive according to the Cisco BroadWorks Xtended Service Platform Configuration Guide for your XSP version. (R24 version is https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/broadworks/Design/XSP/BW-XtendedServicesInterfaceConfigGuide.pdf).

   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 Cisco BroadWorks environment (if necessary).

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

NPS Proxy Overview

For compatibility with Webex for Cisco 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 Cisco 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.

• For more information, see the Push Server for VoIP in UCaaS Feature Description.

• The BroadWorks patches for the feature are available on: https://software.cisco.com/download/home/286326302/type/286326345/release/RI.2022.04.

  For NPS software and patches, see the section Prepare Your NPS for Webex for Cisco BroadWorks.

  Note	Search and download the patch from the software download page.

• More information on the ADP server can be found at https://www.cisco.com/c/en/us/support/unified-communications/broadworks-application-delivery-platform/model.html.

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 and call history).

Note

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.

7. Optional. Update the DAS URL with the URL of the Device Activation Service.

8. Optional. Check the Enable direct BroadWorks authentication check box if you want logins to BroadWorks to be direct to BroadWorks. Otherwise, authentication to BroadWorks is proxied through the Webex-hosted IdP proxy service.

   This check box affects these login situations:

   • User Activation Portal login—Users must enter their BroadWorks credentials when logging in to the portal. The above setting determines if the login is direct to BroadWorks or is through the IdP Proxy.

   • Client Login—If BroadWorks Authentication is configured in the Onboarding Template, the above setting determines if client login to the Webex App is direct to BroadWorks or is proxied through the IdP Proxy.

9. Click Next.

10. On the CTI Interface page, do the following:

    1. Add the CTI URL and Port for the CTI interface to which you want to connect.

    2. Optional. Enable the Call History toggle and then enter your BroadWorks user ID. When this option is selected, BroadWorks call history events get synced to the Webex cloud. Users can view their call history on the Webex App.

    3. Optional. Enable the Do not disturb (DND) sync toggle and then enter your BroadWorks user ID. This option syncs DND events between Webex and BroadWorks, ensuring that the feature works the same on both platforms.

    4. Click Next.

11. Add your Authentication Service URL.

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

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

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

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

5. Optional. Select a cluster if you want to see existing settings for that cluster, such as XSI-Actions, XSI-Events, DAS URL and the CTI interface settings.

Configure your Onboarding Templates

Onboarding 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 3. 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 Onboarding 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. The organization country will determine the default global call-in numbers for Cisco PSTN in Webex Meeting Sites. Refer to the Onboarding section of help page for more information.
   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.

   • ** "Provisioning account" refers to the BroadWorks system-level admin account. On BroadWorks, you need an admin account with these attributes: Administrator Type=Provisioning, Read-only=Off.

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. Optional. Check Disable Cisco Webex Free Calling if you want to disable Webex Calls,.

9. For Meeting Join Configuration, select one of the following options:

   • Cisco Call-in Numbers (PSTN)

   • Partner-provided Call-in Numbers (BYoPSTN)—If you select this option, refer the Bring Your Own PSTN Solution Guide for Webex for Cisco BroadWorks for detailed information on how to configure this option.

10. Click Next.

11. There are two approaches for provisioning subscribers with regards to how their identities are verified – using Trusted Emails or Untrusted Emails.

    In the Trusted Email workflow users provide email addresses to the partner who adds them in BroadWorks. You as a partner are responsible for provisioning the email address as part of either the flow-through or API method.

    Note	It is highly recommended to use the Trusted provisioning method because it ensures that all subscribers are fully provisioned by you as a partner and there is no action required from the end users.

    In the Untrusted email case users need to verify their emails before provisioning, or users can self-activate themselves.

    In the Untrusted case there are several provisioning modes based on the verification settings in the table below:

    Table 4. Recommended User Verification Settings for Untrusted Provisioning Modes

    Setting Name	Flowthrough provisioning without emails	User self-provisioning
    Provision Admin First	Recommended*	Not applicable
    Allow users to self activate	Not applicable	Required

    • Notes from the table:

    • * Each customer organization in Webex is required to have at least one user with administrator role. 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. As a Service Provider you may want to have control over who gets the role. Checking this setting blocks users from completing activation until the first user you provisioned is activated. If you uncheck this setting, then the first user to become active in the new organization becomes the customer administrator.

12. Click Next.

13. Select the default authentication mode (either BroadWorks Authentication or Webex Authentication) for user login to Webex.

    Note	This setting has no effect on user login to the User Activation Portal. Users must use their BroadWorks user ID and password when logging in to the portal, irrespective of how the Onboarding Template is configured.

    Note

    This setting will be applied to newly created customer organizations only. If partner administrators try to apply a new authentication setting to existing customer organizations, the existing settings apply so that existing users don't lose access. To change the authentication mode for existing customer organizations, you must open a ticket with Cisco TAC.

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

14. Click Next.

15. For Preferences, configure the following:

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

    2. If you want to enable directory sync, set the Enable phone directory sync for all new customer organizations toggle to On.

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

    3. Enter a Partner Admin.

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

    4. Make sure the Provisioning Existing Organizations toggle is On (the default setting is On).

    5. Click Next.

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

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

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

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

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

Patch Application Server (R22 and R23 only)

1. If you haven't yet done so, apply the following patch that applies to your release:.

   • For R22: AP.as.22.0.1123.ap373197

   • For R23: AP.as.23.0.1075.ap373197

   • For R24: AP.as.24.0.944.ap384177

   Note	For a complete list of BroadWorks patches that form the requirement for deploying Webex for Cisco BroadWorks, 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

Note	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 provisioningURL

   2. AS_CLI/Interface/Messaging> set provisioningUserId provisioning_account_name

   3. AS_CLI/Interface/Messaging> set provisioningPassword provisioning_account_password

   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

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

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

User Provisioning Data

For information on the user data that gets exchanged between BroadWorks and Webex during user provisioning, see Service Provider User Provisioning.

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.

      • Check the Support Remote Party Info check box. This support is required for desktop sharing to work.

        Note	You can also enable Remote Party support by running the following CLI command on the Application Server: AS_CLI/System/DeviceType/SIP> set <device_profile_type> supportRemotePartyInfo true

   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.

Customize Branding for Webex App

• Partner customizations—Partner administrators can apply advanced branding customizations that apply to the partner organization and/or customers that the partner manages. See Configure Advanced Branding Customizations.

• Customer customizations—If the partner allows customers to apply their own Branding customizations, customer administrators can follow the procedures at Add Your Company Branding to Webex.

Note	The User Activation Portal uses the same logo that you add for client Branding.

Customize Problem Reporting and Help URLs

To customize these options, administators can follow the procedure "Add Feedback and Help Site URLs", which can be found in both of the above Branding articles.