Overview of Webex for BroadWorks

Document Change History




April 20, 2021

  • Added Restricted by Partner Mode description.

  • Updated Features and Limitations with Note on Space Meeting participant limit issue for Basic users.

  • Updated Directory Synchronisation with minor edit around CLI prerequisites.

April 16, 2021

  • Updated Required Patches with Flow-through Provisioning with additional information on CLI updates that are required.

  • Updated Test and Lab Guidelines with addiitonal information.

April 09, 2021

  • Updated Ordering and Provisioning with Extension-only dialing support.

  • Updated EMEA Egress Rules and USA Egress Rules firewall tables with information on IdP URLs

  • Updated Before You Begin requirements for Directory Synchronisation

  • Updated Configure Authentication Service procedure with guidance on how to configure the service if you are running multiple Webex organizations off the same XSP server.

  • Updated Appendix to clarify Authentication Service mTLS procedure requirements

  • Added Note on reusing XSP servers to Architecture

April 01, 2021

Updated Features and Limitations with following updates:

  • Updated Space Meetings limits for Premium package to 200.

  • Updated Standard Package description to clarify screen sharing support for host.

  • Updated Softphone Package description to clarify that softphone users can share their screen during a call.

March 25, 2021

  • Updated Install Authentication Service with updated for finding IssuerUrl and IdPProxy URL.

  • Corrected CLI command for replacing the server certificate and key in Add CTI Interface and Enable mTLS.

March 17, 2021

  • Updated Features and Limitations with information on App Integration

  • Updated Install Authentication Service with IssuerName URL info and FLS configuration validation

March 03, 2021

  • Updated setting for refreshPeriodInMinutes setting in Install Authentication Service procedure.

March 02, 2021

  • Added Messaging Limits for Webex for BroadWorks topic.

  • Minor edit to IdP Proxy URL information in Install Authentication Service topic.

February 23, 2021

  • Updated USA Ingress Rules and EMEA Ingress Rules tables around ports and protocols for SIP VoIP endpoints.

  • Fixed missing images in User Interactions topic.

  • Added IdP Proxy URLs to Install Authentication Service.

February 10, 2021

  • Added procedure topic Migrate NPS to FCMv1.

  • Moved mTLS configuration information to Appendix. Also applied additional TOC formatting to make the Appendix easier to use.

February 05, 2021

  • Added Call Recording and Group Call Pickup and Retrieve features

  • Added Softphone Package to the list of packages

  • Updated TLS references to Authentication Service using CI Token Validation

January 29, 2021

  • Updated links in Architecture & Infrastructure topic

  • Added Limitation around VDI support

  • Corrections to PMR Feature support in Features and Limitations topic. Added desktop sharing and meeting duration.

January 27, 2021

  • Updated Device Profiles table with updated DTAF files and links. Added new Webex Tablet template.

  • Minor correction to Features and Limitations table around Webex Meetings support.

January 22, 2021

  • Updated the Features and Limitations topic with feature support information for Webex Meetings.

  • Added APNs Considerations topic with update on HTTP protocol support with Apple.

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,,, 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,,

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


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.


  • 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





Patch Current BroadWorks 21SP1 or above

Recommend R22 or later


XSP for XSI, CTI, DMS, and authService

Dedicated XSP for Webex for BroadWorks


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.


CI Token Validation (with TLS) configured for Webex connections to the Authentication Service.


mTLS configured for Webex connections to the CTI interface.

Other applications do not require mTLS.


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.

For untrusted emails: Depending on the user’s email settings, the use of untrusted emails may result in the email getting sent to the user’s Junk or SPAM folder. The administrator may have to change the user’s email settings to allow domains


Webex for BroadWorks DTAF file for Webex Client


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.


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

See the “Prepare your Network” section.


TLS v1.2 Configuration on XSPs


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.


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.

"Softphone" Package

This package type uses the Webex app as a softphone only client with calling capability, but no messaging capabilities. Users with this package type can join Webex meetings, but cannot start meetings on their own.

Softphone users can share their screen while in a call.

"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 a role initially held only by the host of the meeting, but the host may pass the ‘presenter role’ to any meeting participant they choose, and only the host may re-take the presenter role without the current host passing it to them.

"Premium" Package

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

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

Compare Packages




Space Meetings

PMR Meetings



Not Included






25 participants





25 participants

25 participants




200 participants

1000 participants

There is a technical issue with the Space meeting participant limit that displays on the Webex app for Webex for BroadWorks Basic users. Prior to the meeting, the Webex app displays an incorrect limit of 100 participants per Space meeting to cover all possibilities of free and paid Locus user combinations. When the meeting is created, the actual Basic user limit of 25 participants is applied to the meeting. However, if a paid Locus user joins the meeting, the actual meeting limit reflects the limit to which the paid Locus user is entitled (100 participants).

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


Meeting Duration



Desktop Sharing



Standard —Desktop sharing by PMR meeting host only.

Premium—Desktop sharing by any PMR meeting participant.

Application Sharing



Standard —Application sharing by PMR meeting host only.

Premium—Application sharing by any PMR meeting participant.

Multi-party Chat






Password Protection



Web app - no downloading or plugins (Guest Experience)



Support pairing with Cisco Webex Devices



Floor control (Mute One / Expel All)



Persistent Meetings link



Meetings Site Acces



Meeting Join via VoIP






Presenter Controls



Remote Destktop Control



Number of participants



Recording saved locally in the system



Recording in the cloud



Recording - Cloud Storage



Recording transcriptions



Meeting Scheduling



Enable Content sharing with External Integrations



Standard—Content sharing by PMR meeting host only.

Premium—Content sharing by any PMR meeting participant.

Allow PMR URL change



Standard—The PMR URL can be changed only from Partner Hub by Partner and org admins.

Premium—Users can modify the PMR URL from the Webex site. Partner and org admins can modify the URL from Partner Hub.

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



Let other users to schedule meetings on their behalf



Add alternate host



App Integration (e.g. Zendesk, Slack)

Depends on the integration


See the App Integrations section below for more information on support.

Integration with Microsoft Office 365 Calendaring



Integration with Google Calendaring for G Suite



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.

App Integrations

You can integrate Webex for BroadWorks with the following applications:

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.


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 using your chosen provisioning method, 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.

  • Webex for BroadWorks is not supported in Virtual Desktop Infrastructure (VDI) deployments.

Messaging Limits

The following data storage limits (messaging and files combined) apply to organizations that have purchased Webex for BroadWorks services through a Service Provider. These limits represent the maximum storage for messaging and files combined.

  • Basic: 2 GB per user for 3 years

  • Standard 5 GB per user for 3 years

  • Premium: 10 GB per user for 5 years

For each customer organization, these per user totals are pooled to provide an aggregated total for that customer, based on the number of users. For example, a company with five premium users has a total messaging and file storage limit of 50 GB. An individual user can exceed the per-user limit (10 GB) provided the company is still under the aggregated maximum (50 GB).

For team spaces that are created, the messaging limits apply against the aggregated total for the customer organization that owns the team space. You can find information on the owner of individual team spaces from the Space Policy. For information on how to view the Space Policy for an individual team space, see https://help.webex.com/en-us/baztm6/Webex-Space-Policy.

Additional Information

For additional information on general messaging limits that apply to Webex messaging team spaces, refer to https://help.webex.com/en-us/n8vw82eb/Webex-Capacities.

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.


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




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


BroadWorks Configuration in Partner Org via Partner Hub (Cluster)


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


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


Develop Provisioning Integration or Process


Prepare GTM Materials


Migrate or Provision New Users


What's in the Diagram?


  • 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 TLS, 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 recommend that you use a dedicated XSP instance/farm to host the required applications for Webex integration for the following reasons

  • 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 (TLS with CI Token Validation or mTLS)

  • CTI (mTLS)

  • XSI-Actions (TLS)

  • XSI-Events (TLS)

  • DMS (TLS)

Webex requires access to 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 CTI and a TLS interface for other apps such as the AuthService.

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

XSP Reuse

If you have an existing XSP farm that conforms to one of the suggested architectures above (Option 1 or 2) and it is lightly loaded, then it is possible to reuse your existing XSPs. You will need to verify that there are no conflicting configuration requirements between existing applications and the new application requirements for webex. The two primary considerations are:

  • If you need to support multiple webex partner organizations on the XSP, then that means you must use mTLS on the Auth Service (CI Token Validation is only supported for a single partner organization on an XSP). If you use mTLS on the Authentication Service, then that means you can’t have clients which are using basic authentication on the Authentication Service at the same time. This situation would prevent reuse of the XSP.

  • If the existing CTI Service configured to be used by clients with the secure port (typically 8012) but without mTLS (i.e. client authentication) then that will conflict with the webex requirement to have mTLS.

Because the XSP’s have many applications and the number of permutations of these applications is large, there may be other unidentified conflicts. For this reason, any potential reuse of XSP’s should be verified in a lab with the intended configuration prior to committing to the reuse.

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_SERVER=<NTP Server address, e.g., pool.ntp.org>

XSP Identity and Security Requirements


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:





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.






















































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.

Required Patches with Flow-through Provisioning

If you are using flow-through provisioning, you must install a system patch and apply a CLI property. Refer to the below list for instructions that apply to your BroadWorks release:

For R21:

  1. Install AP.as.21.sp1.551.ap375094

  2. After installation, set the property bw.msg.includeIsEnterpriseInOSSschema to true from the CLI in Maintenance/ContainerOptions.

    For more information, see the patch notes https://xchange.broadsoft.com/node/1054597.

For R22:

  1. Install AP.as.22.0.1123.ap376508

  2. After installation, set the property bw.msg.includeIsEnterpriseInOSSschema to true from the CLI in Maintenance/ContainerOptions.

    For more information, see the patch notes https://xchange.broadsoft.com/node/1054368.

For R23:

  1. Install AP.as.23.0.1075.ap376509

  2. After installation, set the property bw.msg.includeIsEnterpriseInOSSschema to true from the CLI in Maintenance/ContainerOptions.

    For more information, see the patch notes https://xchange.broadsoft.com/node/1054490.

For R24:

  1. Install AP.as.24.0.944.ap375100

  2. After installation, set the property bw.msg.includeIsEnterpriseInOSSschema to true from the CLI in Maintenance/ContainerOptions.

    For more information, see the patch notes https://xchange.broadsoft.com/node/1054590.

After you complete these steps, you will be unable to provision new users with UC-One Collaborate services. Newly provisioned users must be Webex for BroadWorks users.

Provisioning Extension-Only Users

Webex for BroadWorks supports the provisioning of users whom have only a primary extension on BroadWorks, and not a full phone number. During provisioning, the extension gets stored in the Webex directory as the user's Work number. For BroadWorks calling, the extension appears on the Webex app as a Work number.

Webex for BroadWorks supports extension-only calls between users within the same group, and whom have the same location code. Calling between two enterprises using only extensions is not supported.

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.