Overview of Webex for BroadWorks

Document Change History

Date

Change

Section

January 12, 2021

  • Updated the Features topic in the Overview for Webex for BroadWorks chapter with screen sharing support information for PMR meetings. Also added a table with additional information on PMR meetings feature support.

  • Updated Note in the Install XSP Authentication procedure in the Deploy Webex for BroadWorks chapter.

Dec 18, 2020

  • Updated the Install XSP Authentication procedure in the Deploy Webex for BroadWorks chapter.

  • Moved the pre-existing procedure to the Appendix.

Dec 15, 2020

Added Directory Synchronisation for BroadWorks Calling.

Dec 08, 2020

Updated document. Rebranding Webex Teams to Webex (app).

Nov 12, 2020

  • User Provisioning and Activation Flows, User Interactions:

    Fixed broken image references.

  • BroadWorks Tags Required for Webex, BroadWorks Software Requirements, Firewall Configuration, DNS Configuration:

    Fixed inconsistent table formatting.

DNS Configuration

Clarified DNS requirements: Do not use round-robin A/AAAA record for client Xsi address

Configure Call Push Notifications in Webex for BroadWorks

  • Reworked NPS proxy section to improve flow and reduce duplication.

  • Removed NPS migration advice to an external article.

  • Add Webex apps to AS allow list.

  • Clarify commands to create CI account for NPS proxy.

October 29, 2020

Managing Users

  • Added procedure to edit user package in Partner Hub.

  • Added procedure to provision users by self-activation.

  • Added options for deleting users.

Using the Provisioning API

  • Added API Responsebody definition

  • Added API error codes

Deploy Webex for BroadWorks

Added Call Settings Webview

Additional Certificate Requirements for Mutual TLS Authentication over CTI Interface

Added missing diagram and clarified text about internal CA and BroadWorks OID.

October 9, 2020

Using the Provisioning API

Added detail about developer and authorizing user roles for implementing applications to use Webex for BroadWorks API.

Added API backward compatibility and versioning strategy.

EMEA Egress Rules

Added idbroker-eu.webex.com to domains that must be allowed outbound from EMEA organizations,and removed idbroker.webex.com from that list.

Configure your NPS to Work with the NPS Proxy

Corrected NPS Proxy account request procedure which directed reader to the wrong Cisco resource.

Configure Services on your Webex for BroadWorks XSPs, CTI Interface and Related Configuration:

Added notes about using container options to configure TLS version and ciphers on XSP R21(SP1).

Configure Services on your Webex for BroadWorks XSPs.

Added XSP R21(SP1) details for generating and sharing RSA keys.

Features and Limitations

Participant limits and dial-in option updated.

Configure Your BroadWorks Clusters

Added note about not saving invalid clusters.

Configure Application Server with Provisioning Service URL

Removed irrelevant section about creating a new administrator on BroadWorks.

October 2020

Document updated with new features.

  • CTI Interface and Related Configuration added.

  • Ordering and Provisioning updated with overviews of new user provisioning flows.

  • NPS proxy IP ranges added to Egress rules.

    (Added ranges 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13 and advice to use FQDN if possible).

  • Added new IPs to Ingress rules to allow from Webex towards your XSPs.

    (For CTI and HTTPS: Source 44.232.54.0, 52.39.97.25, 54.185.54.53)

  • Added a note, strongly recommending SRV in DNS Configuration.

  • Deployment Overview now contains task flows for all provisioning modes.

September 2020

Configure your NPS to Work with the NPS Proxy

Corrected NPS authentication proxy URL

August 2020

  • XSP Identity and Security Requirements

    Corrected cipher suite names to IANA convention

  • Configure Services on Your Webex for BroadWorks XSPs

    Corrected the XSP mTLS trust anchor procedure

July 2020

First Publishing

Introducing Webex for BroadWorks

This section addresses system administrators at Cisco partner organizations (service providers) who implement Cisco Webex for their customer organizations or provide this solution directly to their own subscribers.

Solution Purpose

  • To provide Cisco Webex cloud collaboration features to Small and Medium customers who already have calling service provided by BroadWorks Service Providers.

  • To provide BroadWorks based calling service to small and medium Webex customers.

Context

We’re evolving all our collaboration clients towards a unified application. This path reduces adoption difficulties, improves interoperability and migration, and delivers predictable user experiences across our entire collaboration portfolio. Part of this effort is to move the BroadWorks calling capabilities into the Webex client, and eventually reduce investment in the UC-One clients.

Benefits

  • Future proofing: against End-of-life of UC-One Collaborate, movement of all clients towards the Unified Client Framework (UCF)

  • Best of both: Enabling Webex Messaging and Meeting features while retaining BroadWorks calling on your telephony network

Solution Scope

  • Existing / new small to medium customers (fewer than 250 subscribers) who want a suite of collaboration features, may already have BroadWorks calling.

  • Existing small to medium Webex customers looking to add BroadWorks Calling.

  • Not larger enterprises (Please review our Enterprise portfolio for Webex).

  • Not single users (Please evaluate Webex Online offers).

The feature sets in Webex for BroadWorks target small to medium business use cases. The Webex for BroadWorks packages are designed to reduce complexity for SMBs, and we constantly evaluate their suitability for this segment. We may choose to hide or remove features that would otherwise be available in the enterprise packages.

Prerequisites for Success with Webex for BroadWorks

#

Requirement

Notes

1

Patch Current BroadWorks 21SP1 or above

Recommend R22 or later

2

XSP for XSI, CTI, DMS, and authService

Dedicated XSP for Webex for BroadWorks

3

Separate XSP for NPS, can be shared with other solutions that use NPS.

If you have an existing collaborate deployment, then review recommendations on XSP and NPS configurations.

4

mTLS configured for Webex connections to the Authentication Service, and CTI interface.

Other applications do not require mTLS.

5

Users must exist in BroadWorks and need the following attributes, depending on your provisioning decision:

  • Flowthrough with trusted emails: Email attribute of BroadWorks user must contain a valid email address, unique to that user. User must also have a primary number.

  • Flowthrough with untrusted emails, or self-activation, or API provisioning: User do not need email address but must have a primary number.

For trusted emails: We recommend you put the same email address in the Alternate ID attribute as well, to enable users to sign in with email address against BroadWorks.

6

Webex for BroadWorks DTAF file for Webex Client

7

BW Business Lic or Std Enterprise or Prem Enterprise User Lic + Webex for BroadWorks Subscription

If you have an existing collaborate deployment, you no longer need UC-One Add-On Bundle, Collab Lic, and Meet-me conference Ports.

If you have an existing UC-One SaaS deployment, no additional changes other than accepting Premium Package terms.

8

IP/Ports must be accessible through the Webex backend services and the Webex Apps over public internet.

See the “Prepare your Network” section.

9

TLS v1.2 Configuration on XSPs

10

For Flowthrough provisioning, the Application Server must connect out to the BroadWorks Provisioning Adapter.


 

We do not test or support outbound proxy configuration. If you use an outbound proxy, you accept the responsibility for supporting it with Webex for BroadWorks.

See the “Prepare your Network” topic.

About this Document

The purpose of this document is to help you understand, prepare for, deploy, and manage your Webex for BroadWorks solution. The major sections in the document reflect this purpose.

This guide includes conceptual and reference material. We intend to cover all aspects of the solution in this one document.

The minimum set of tasks to deploy the solution are:

  1. Reach your account team to become a Cisco Partner. It's imperative that you explore the Cisco touch points to familiarize yourself (and get trained). When you become a Cisco Partner, we apply the Webex for BroadWorks toggle to your Webex partner organization. (See Deploy Cisco Webex for BroadWorks > Partner Onboarding in this document.)

  2. Configure your BroadWorks systems for integration with Webex. (See Deploy Cisco Webex for BroadWorks > Configure Services on Your Webex for BroadWorks XSPs in this document.)

  3. Use Partner Hub to connect Webex to BroadWorks. (See Deploy Webex for BroadWorks > Configure your Partner Organization in Partner Hub in this document.)

  4. Use Partner Hub to prepare User Provisioning Templates. (See Deploy Webex for BroadWorks > Configure your Customer Templates in this document.)

  5. Test and onboard a customer by provisioning at least one user. (See Deploy Webex for BroadWorks > Configure Your Test Organization.)


    • These are high-level steps, in the typical order. There are several contributing tasks that you can't ignore.

    • If you want to create your own applications to manage your Webex for BroadWorks subscribers, you should read Using the Provisioning API in the Reference section of this guide.

Terminology

We try to limit the jargon and acronyms used in this document, and to explain each term when it’s first used. (See Webex for BroadWorks Reference > Terminology if a term isn’t explained in context.)

How it Works

Cisco Webex for BroadWorks is an offer that integrates BroadWorks Calling in Webex. Subscribers use a single application (the Webex app) to take advantage of features provided by both platforms:

  • Users call PSTN numbers using your BroadWorks infrastructure.

  • Users call other BroadWorks numbers using your BroadWorks infrastructure (audio/video calls by selecting the numbers associated to the users or the dialpad to introduce the numbers).

  • Users can, alternatively, make a Webex VOIP Call over the Webex Infrastructure by selecting the option “Webex Call” on the Webex app. (These calls are Webex app to Webex app, not Webex app to PSTN).

  • Users can host and join Cisco Webex Meetings.

  • Users can message each other one to one or in spaces (persistent group chat), and benefit from features like search and file share (on Webex infrastructure).

  • Users can share presence (status). They can choose custom presence or client calculated presence.

  • After we onboard you as a Partner Organization in Control Hub, with the correct entitlements, you can configure the relationship between your BroadWorks instance and Cisco Webex.

  • You create customer organizations in Control Hub, and provision users in those organizations.

  • Each subscriber in BroadWorks gets a Webex identity based on their email address (Email ID attribute in BroadWorks).

  • Users authenticate against BroadWorks or against Cisco Webex.

  • Clients are issued with long-lived tokens to authorize them for services at BroadWorks and Cisco Webex.

The Webex client at the center of this solution; it’s a brandable application available on Mac/Windows desktops, and Android/iOS mobiles and tablets.

There’s also a web version of the Webex app that doesn't currently include calling features.

The client connects to the Cisco Webex cloud to deliver messaging, presence, and meetings features.

The client registers to your BroadWorks systems for calling features.

The Cisco Webex cloud works with your BroadWorks systems to ensure a seamless user provisioning experience.

Features and Limitations

We offer several packages with different features.

"Basic" Package

Basic package includes Calling and Messaging features. It includes 25-person “space” meetings. In Webex, this feature is the ability to initiate a "Meet" session with participants in a "space". There’s no dial-in into this meeting and all users must be Webex users in the same space.

Basic package does NOT include Personal Meeting Room (PMR).

"Standard" Package

This package includes everything in the Basic package plus up to 25 participant “space” meetings and up to 25 participants in a Personal Meeting Room (PMR). The SP provides BYOPSTN (SP dial-in numbers) for meetings and all users. Participants can dial in or use the Webex app to join, using the link provided by the Meetings host. Cisco Webex Dial-in phone numbers will be used for Meetings dial-in.

Screen sharing within a PMR meeting is supported for the meeting host only. However, within a meeting, the PMR owner can designate new hosts for screen sharing.

"Premium" Package

This package includes everything in the Standard package plus up to 1000 participants in a Personal Meeting Room (PMR).

Screen sharing within a PMR meeting is supported for any meeting attendee.

Compare Packages

Package

Calling

Messaging

Space Meetings

PMR Meetings

Basic

Included

Included

25 participants

None

Standard

Included

Included

25 participants

25 participants

Screen sharing by meeting host

Premium

Included

Included

25 participants

1000 participants

Screen sharing by all attendees

Messaging and Meeting Features

Refer to the following table for PMR meeting feature support differences for Standard and Premium packages. Note that PMR meetings are not supported with the Basic Package.

Table 1. Feature Support Differences for PMR Meetings

Meeting Feature

Suported with Standard Package

Supported with Preminum Package

Application Sharing

Unlimited

Unlimited

Multi-party Chat

Yes

Yes

Whiteboarding

Yes

Yes

Password Protection

Yes

Yes

Web app

Yes

Yes

Support pairing with Cisco Webex Devices

Yes

Yes

Floor control

Yes

Yes

Persistent Meetings link

Yes

Yes

Meetings Site Acces

Yes

Yes

Meeting Join via VoIP

Yes

Yes

Locking

Yes

Yes

Presenter Controls

No

Yes

Remote Destktop Control

No

Yes

Number of participants

25

1000

Recording saved locally in the system

No

Yes

Recording in the cloud

No

Yes

Recording - Cloud Storage

No

10GB

Recording transcriptions

No

Yes

PMR Meeting Scheduling

No

Yes

Enable Content sharing with External Integrations

No

Yes

Allow PMR URL change

No

Yes

Meetings Live Streaming (E.g., on Facebook, Youtube)

No

Yes

Let other users to schedule meetings on their behalf

No

Yes

Add alternate host

No

Yes

App Integration

No

Yes

Integration with Microsoft Office 365 Calendaring

Yes

Yes

Integration with Google Calendaring for G Suite

Yes

Yes

The Webex Help Center publishes the features and user facing documentation for Webex at help.webex.com. Read the following articles to learn more about the features:

Calling Features

The calling experience is similar to previous solutions that use the BroadWorks call control engine. The difference to UC-One Collaborate and UC-One SaaS is that the Webex app is the primary soft client.

Future Roadmap

For insight into our intentions for the future versions of Webex for BroadWorks, visit https://salesconnect.cisco.com/#/program/PAGE-16649. The roadmap items aren’t binding in any capacity. Cisco reserves the right to withhold or revise any or all of these items from future releases.

Limitations

Provisioning Limitations

Meetings Site Timezone

The timezone of the first subscriber for each package becomes the timezone for the Webex Meetings site created for that package.

If no timezone is specified in the provisioning request for the first user of each package, the Webex Meetings site timezone for that package is set to the regional default of the subscribers' organization.

If your customer needs a specific Webex Meetings site timezone, specify the timezone parameter in the provisioning request for:

  • the first subscriber provisioned for Standard package in the organization.

  • the first subscriber provisioned for Premium package in the organization.

    (This limitation does not affect organizations that are provisioned with the Basic package.)

General Limitations

  • No calling in the Web version of the Webex client (This is a client limitation, not a solution limitation.)

  • Webex may not yet have all the UI controls to support some of the call control features available from BroadWorks.

  • The Webex client can’t currently be “White Labeled”.

  • When you create customer organizations with flow through provisioning, they are automatically created in the same region as your partner organization. This behavior is by design. We expect multinational partners to create a partner organization in each region where they are managing customer organizations.

  • Authentication through the Service Provider’s IdP isn’t supported.

  • There are no partner-level analytics and reports on Webex for BroadWorks. Reporting on meetings and messaging usage is available through the customer organization in Control Hub.

Security, Data, and Roles

Cisco Webex Security

The Webex client is a secure application that makes secure connections to Webex and BroadWorks. The data that is stored in the Cisco Webex cloud, and exposed to the user through the Webex app interface, is encrypted both in transit and at rest.

There’s more detail on data exchange in the Reference section of this document.

Additional Reading

Organization Data Residency

We store your Webex data in the data center that most closely matches your region. See Data Residency in Cisco Webex in the Help Center.

Roles

Service provider administrator (you): For day to day maintenance activities, you manage the on-premises (calling) parts of the solution using your own systems. You manage the Webex parts of the solution through Partner Hub.

Cisco cloud operations team: Creates your “partner organization” in Partner Hub, if it doesn’t exist, during your onboarding.

Once you have your Partner Hub account, you configure the Webex interfaces to your own systems. You next create “Customer Templates” to represent the suites or packages served through those systems. You then provision your customers or subscribers.

#

Typical Task

SP

Cisco

1

Partner Onboarding - Creating the Partner Org if one doesn’t exist and enabling the necessary feature toggles

2

BroadWorks Configuration in Partner Org via Partner Hub (Cluster)

3

Configuring Integration settings in Partner Org via Partner Hub (Offer Templates, Branding)

4

Preparing BroadWorks environment for Integration (AS, XSP Patching, firewalls, XSP configuration, XSI, AuthService, CTI, NPS, DMS applications on XSP)

5

Develop Provisioning Integration or Process

6

Prepare GTM Materials

7

Migrate or Provision New Users

Architecture

What's in the Diagram?

Clients

  • The Webex client serves as the primary application in Webex for BroadWorks offers. The client is available on desktop, mobile, and web platforms.

    The client has native messaging, presence, and multiparty audio/video meetings provided by the Cisco Webex cloud. The Webex client uses your BroadWorks infrastructure for SIP and PSTN calls.

  • Cisco IP phones and related accessories also use your BroadWorks infrastructure for SIP and PSTN calls. We expect to be able to support third-party phones.

  • User Activation Portal for users to sign into Cisco Webex using their BroadWorks credentials.

  • Partner Hub is a web interface for administering your Webex organization and your customers’ organizations. Partner Hub is where you configure the integration between your BroadWorks infrastructure and Cisco Webex. You also use Partner Hub to manage client configuration and billing.

Service Provider Network

The green block on the left of the diagram represents your network. Components hosted in your network provide the following services and interfaces to other parts of the solution:

  • Public-facing XSP, for Webex for BroadWorks: (The box represents one or multiple XSP farms, possibly fronted by load balancers.)

    • Hosts the Xtended Services Interface (XSI-Actions & XSI-Events), Device Management Service (DMS), CTI interface, and Authentication Service. Together, these applications enable phones and Webex clients to authenticate themselves, download their calling configuration files, make and receive calls, and see each other's hook status (telephony presence).

    • Publishes directory to Webex clients.

  • Public-facing XSP, running NPS:

    • host Call Notifications Push Server: A Notification Push Server on an XSP in your environment. It interfaces between your Application Server and our NPS proxy. The proxy supplies short-lived tokens to your NPS to authorize notifications to the cloud services. These services (APNS & FCM) send call notifications to Webex clients on Apple iOS and Google Android devices.

  • Application Server:

    • Provides call control and interfaces to other BroadWorks systems (generally)

    • For flowthrough provisioning, the AS is used by partner administrator to provision users in Webex

    • Pushes user profile into BroadWorks

  • OSS/BSS: Your Operations Support System / Business SIP Services for administering your BroadWorks enterprises.

Cisco Webex Cloud

The blue block in the diagram represents Cisco Webex. Cisco Webex microservices support the full spectrum of Cisco Webex collaboration capabilities:

  • Cisco Common Identity (CI) is the identity service within Cisco Webex.

  • Webex for BroadWorks represents the set of microservices that support the integration between Cisco Webex and Service Provider Hosted BroadWorks:

    • User Provisioning APIs

    • Service Provider Configuration

    • User Login using BroadWorks credentials

  • Webex Messaging box for messaging-related microservices.

  • Webex Meetings box representing media processing servers and SBCs for multiple participant video meetings (SIP & SRTP)

Third-Party Web Services

The following third-party components are represented in the diagram:

  • APNS (Apple Push Notifications Service) pushes call and message notifications to Webex applications on Apple devices.

  • FCM (FireBase Cloud Messaging) pushes call and message notifications to Webex applications on Android devices.

XSP Architecture Considerations

The Role of Public-Facing XSP Servers in Webex for BroadWorks

The public-facing XSP in your environment provides the following interfaces/services to Cisco Webex and clients:

  • Authentication Service (AuthService), secured by mTLS, which responds to Webex requests for BroadWorks JWT (JSON Web Token) on user’s behalf

  • CTI interface, secured by mTLS, to which Webex subscribes for telephony presence status from BroadWorks (hook status)

  • Xsi actions and events interfaces (eXtended Services Interface) for subscriber call control, contact and call list directories, and end-user telephony service configuration

  • DM (Device Management) service for clients to retrieve their calling configuration files

Supply URLs for these interfaces when you configure Webex for BroadWorks. (See Configure your BroadWorks Clusters in Partner Hub in this document.) For each cluster, you can only provide one URL for each interface. If you have multiple interfaces into your BroadWorks infrastructure, you can create multiple clusters.

XSP Architecture Requirements

Figure 1. Recommended XSP Architecture Option 1
Figure 2. Recommended XSP Architecture Option 2

We require that you use a separate, dedicated XSP instance or farm to host your NPS (Notification Push Server) application. You can use the same NPS with UC-One SaaS or UC-One Collaborate. However, you may not host the other applications required for Webex for BroadWorks on the same XSP that hosts the NPS application.

We strongly recommend that you use a dedicated XSP instance/farm to host the required applications for Webex integration.

  • For example, if you’re offering UC-One SaaS, we recommend creating a new XSP farm for Webex for BroadWorks. This way the two services can operate independently while you migrate subscribers.

  • If you collocate the Webex for BroadWorks applications on an XSP farm that is used for other purposes, it's your responsibility to monitor usage, manage the resulting complexity, and plan for the increased scale.

  • The capacity calculator assumes a dedicated XSP farm and may not be accurate if you use it for collocation calculations.

The dedicated Webex for BroadWorks XSPs must host the following applications:

  • AuthService (mTLS)

  • CTI (mTLS)

  • XSI-Actions (TLS)

  • XSI-Events (TLS)

  • DMS (TLS)

Webex requires access to Auth Service and CTI through an interface secured by mutual TLS authentication. To support this requirement, we recommend one of these options:

  • (Diagram labelled Option 1) One XSP instance or farm for all applications, with two interfaces configured on each server: an mTLS interface for the AuthService and CTI, and a TLS interface for other apps

  • (Diagram labelled Option 2) Two XSP instances or farms, one with an mTLS interface for AuthService and CTI, and the other with a TLS interface for other apps


Even if you deploy the Authentication Service on a dedicated XSP instance or farm for Webex mTLS access, we require that you continue to run an instance of Authentication Service that is coresident with the other required applications. This is because the Authentication Service must verify long-lived tokens received from clients by the other applications.

Configure NTP Synchronization on XSP

The deployment requires time synchronization for all XSPs that you use with Webex.

Install the ntp package after you install the OS and before you install the BroadWorks software. Then you can configure NTP during the XSP software installation. See the BroadWorks Software Management Guide for more detail.

During the interactive installation of the XSP software, you’re given the option to configure NTP. Proceed as follows:

  1. When the installer asks, Do you want to configure NTP?, enter y.

  2. When the installer asks, Is this server going to be a NTP server?, enter n.

  3. When the installer asks, What is the NTP address, hostname, or FQDN?, enter the address of your NTP server, or a public NTP service, for example, pool.ntp.org.

If your XSPs use silent (noninteractive) installation, the installer configuration file must include the following Key=Value pairs:

NTP
NTP_SERVER=<NTP Server address, e.g., pool.ntp.org>

XSP Identity and Security Requirements

Background

The protocols and ciphers of Cisco BroadWorks TLS connections are configurable at different levels of specificity. These levels range from the most general (SSL provider) to the most specific (individual interface). A more specific setting always overrides a more general setting. If they aren’t specified, ‘lower’ level SSL settings are inherited from ‘higher’ levels.

If no settings are changed from their defaults, all levels inherit the SSL provider default settings (JSSE Java Secure Sockets Extension).

Requirements List

  • The XSP must authenticate itself to clients using a CA-signed certificate in which the Common Name or Subject Alternate Name matches the domain portion of the XSI interface.

  • The Xsi interface must support TLSv1.2 protocol.

  • The Xsi interface must use a cipher suite that meets the following requirements.

    • Diffie-Hellman Ephemeral (DHE) or Elliptic Curves Diffie-Hellman Ephemeral (ECDHE) key-exchange

    • AES (Advanced Encryption Standard) cipher with a minimum block size of 128 bits (e.g. AES-128 or AES-256)

    • GCM (Galois/Counter Mode) or CBC (Cipher Block Chaining) cipher mode

      • If a CBC cipher is used, only the SHA2 family of hash functions is allowed for key derivation (SHA256, SHA384, SHA512).

For example, the following ciphers meet the requirements:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_PSK_WITH_AES_256_CBC_SHA384


The XSP CLI requires the IANA naming convention for cipher suites, as shown above, not the openSSL convention.

Supported TLS Ciphers for the AuthService and XSI Interfaces


This list is subject to change as our cloud security requirements evolve. Follow the current Cisco cloud security recommendation on cipher selection, as described in the requirements list in this document.

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_RSA_PSK_WITH_AES_256_GCM_SHA384

  • TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

  • TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_PSK_WITH_AES_256_GCM_SHA384

  • TLS_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_RSA_PSK_WITH_AES_128_GCM_SHA256

  • TLS_DHE_PSK_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_PSK_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_256_CBC_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_RSA_PSK_WITH_AES_256_CBC_SHA384

  • TLS_DHE_PSK_WITH_AES_256_CBC_SHA384

  • TLS_RSA_PSK_WITH_AES_256_CBC_SHA

  • TLS_DHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_PSK_WITH_AES_256_CBC_SHA384

  • TLS_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_RSA_PSK_WITH_AES_128_CBC_SHA256

  • TLS_DHE_PSK_WITH_AES_128_CBC_SHA256

  • TLS_RSA_PSK_WITH_AES_128_CBC_SHA

  • TLS_DHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_PSK_WITH_AES_128_CBC_SHA256

  • TLS_PSK_WITH_AES_128_CBC_SHA

Xsi Events Scale Parameters

You may need to increase the Xsi-Events queue size and thread count to handle the volume of events that the Webex for BroadWorks solution requires. You can increase the parameters to the minimum values shown, as follows (don’t decrease them if they are above these minimum values):

XSP_CLI/Applications/Xsi-Events/BWIntegration> eventQueueSize = 2000

XSP_CLI/Applications/Xsi-Events/BWIntegration> eventHandlerThreadCount = 50

Multiple XSPs

Load Balancing Edge Element

If you have a load balancing element on your network edge, it must transparently handle the distribution of traffic between your multiple XSP servers and the Webex for BroadWorks cloud and clients. In this case, you would provide the URL of the load balancer to the Webex for BroadWorks configuration.

Notes on this architecture:

  • Configure DNS so the clients can find the load balancer when connecting to the Xsi interface (see DNS configuration).

  • We recommend that you configure the edge element in reverse SSL proxy mode, to ensure point to point data encryption.

  • Certificates from XSP01 and XSP02 should both have the XSP domain, for example your-xsp.example.com, in the Subject Alternate Name. They should have their own FQDNs, for example xsp01.example.com, in the Common Name. You can use wildcard certificates, but we don’t recommend them.

Internet-Facing XSP Servers

If you expose the Xsi interfaces directly, use DNS to distribute the traffic to the multiple XSP servers.

Notes on this architecture:

  • Use round-robin A/AAAA records to target the multiple XSP IP addresses, because the Webex microservices can’t do SRV lookup. See DNS Configuration for examples.

  • Certificates from XSP01 and XSP02 should both have the XSP domain, for example your-xsp.example.com, in the Subject Alternate Name. They should have their own FQDNs, for example xsp01.example.com, in the Common Name.

  • You can use wildcard certificates, but we don’t recommend them.

Avoid HTTP Redirects

Sometimes, DNS is configured to resolve the XSP URL to an HTTP load balancer, and the load balancer is configured to redirect through a reverse proxy to the XSP servers.

Webex does not follow a redirect when connecting to the URLs you supply, so this configuration does not work.

Ordering and Provisioning

Ordering and provisioning applies at these levels:

  • Partner/Service Provider provisioning:

    Each Webex for BroadWorks Service Provider (or Reseller) onboarded must be configured as a Partner Organization in Cisco Webex, and granted the necessary entitlements. Cisco Operations provides the administrator of the Partner Organization with access to manage Webex for BroadWorks on Cisco Webex Partner Hub. The Partner Administrator must do all required provisioning steps before they can provision a Customer/Enterprise organization.

  • Customer/Enterprise ordering and provisioning:

    Each BroadWorks Enterprise enabled for Webex for BroadWorks triggers creation of an associated Cisco Webex Customer Organization. This process occurs automatically as part of user/subscriber provisioning. All users/subscribers within a BroadWorks enterprise are provisioned in the same Cisco Webex Customer organization.

    The same behavior applies if your BroadWorks system is configured as a Service Provider with Groups. When you provision a subscriber in a BroadWorks group, a Customer organization that corresponds with the group is automatically created in Webex.

  • User/Subscriber ordering and provisioning:

    Cisco Webex for BroadWorks currently supports the following user provisioning models:

    • Flowthrough provisioning with trusted emails

    • Flowthrough provisioning without trusted emails

    • User Self-provisioning

    • API provisioning

Flowthrough Provisioning With Trusted Emails

You configure the Integrated IM&P service to use a Webex provisioning URL, and then assign the service to users. The Application Server uses the Webex provisioning API to request the corresponding Webex user accounts.

If you can assert that BroadWorks has subscriber email addresses that are valid, and unique to Webex, this provisioning option automatically creates and activates Webex accounts with those email addresses as user IDs.

You can change the subscriber package through Partner Hub, or you can write your own application to use the provisioning API to change subscriber packages.

Flowthrough Provisioning Without Trusted Emails

You configure the Integrated IM&P service to use a Webex provisioning URL, and then assign the service to users. The Application Server uses the Webex provisioning API to request the corresponding Webex user accounts.

If you cannot rely on the subscriber email addresses held by BroadWorks, this provisioning option creates Webex accounts, but cannot activate them until subscribers supply and validate their email addresses. At that point, Webex can activate the accounts with those email addresses as user IDs.
Figure 3. Flowthrough Provisioning Without Trusted Emails

You can change the subscriber package through Partner Hub, or you can write your own application to use the provisioning API to change subscriber packages.

User Self-Provisioning

With this option, there is no flowthrough provisioning from BroadWorks to Webex. After you configure the integration between Webex and your BroadWorks system, you get one or more links that are specific for provisioning users within your Webex for BroadWorks partner organization.

You then design your own communications (or delegate to your customers) to distribute the link to subscribers. The subscribers follow the link, then supply and validate their email addresses to create and activate their own Webex accounts.

Figure 4. Self-Provisioning

Because the accounts are provisioned within the scope of your partner organization, you can manually adjust user packages through Partner Hub, or use the API to do that.


Users must exist in the BroadWorks system that you integrate with Webex, or they are forbidden from creating accounts with that link.

Service Provider Provisioning by APIs

Cisco Webex exposes a set of public APIs that enable you to build Webex for BroadWorks user/subscriber provisioning into your existing user management workflow/tools.

Migration and Future-proofing

The Cisco progression of the BroadSoft unified communications client is to move away from UC-One towards Webex. There’s a corresponding progression of the supporting services away from the Service Provider network – except for calling – towards the Cisco Webex cloud platform.

Whether you’re running UC-One SaaS, or BroadWorks Collaborate, the preferred migration strategy is to deploy new, dedicated XSPs for integration with Webex for BroadWorks. You can run the two services in parallel while you migrate customers to Webex, and eventually recoup the infrastructure used for the previous solution.