- Home
- /
- Article
Webex for Cisco BroadWorks Architecture
The content details the architecture and components of Webex for Cisco BroadWorks, focusing on integration, security, and service configuration across various platforms.
Architecture

What's in the Diagram?
Clients
-
The Webex App client serves as the primary application in Webex for Cisco 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 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 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 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|ADP, for Webex for Cisco BroadWorks: (The box represents one or multiple XSP|ADP 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) and call history.
-
Publishes directory to Webex clients.
-
-
Public-facing XSP|ADP, running NPS:
-
host Call Notifications Push Server: A Notification Push Server on an XSP|ADP 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.
Webex Cloud
The blue block in the diagram represents the Webex cloud. Webex microservices support the full spectrum of Webex collaboration capabilities:
-
Cisco Common Identity (CI) is the identity service within Webex.
-
Webex for Cisco BroadWorks represents the set of microservices that support the integration between 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|ADP Architecture Considerations
The Role of Public-Facing XSP|ADP Servers in Webex for Cisco BroadWorks

The public-facing XSP|ADP in your environment provides the following interfaces/services to 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 call history events and 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 Cisco 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|ADP Architecture


We require that you use a separate, dedicated XSP|ADP 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 Cisco BroadWorks on the same XSP|ADP that hosts the NPS application.
We recommend that you use a dedicated XSP|ADP 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|ADP farm for Webex for Cisco BroadWorks. This way the two services can operate independently while you migrate subscribers.
-
If you collocate the Webex for Cisco BroadWorks applications on an XSP|ADP 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 Cisco BroadWorks System Capacity Planner assumes a dedicated XSP|ADP farm and may not be accurate if you use it for collocation calculations.
Unless noted otherwise, the dedicated Webex for Cisco BroadWorks XSP|ADPs must host the following applications:
-
AuthService (TLS with CI Token Validation or mTLS)
-
CTI (mTLS)
-
XSI-Actions (TLS)
-
XSI-Events (TLS)
-
DMS (TLS)—Optional. It's not mandatory that you deploy a separate DMS instance or farm specifically for Webex for Cisco BroadWorks. You can use the same DMS instance that you use for UC-One SaaS or UC-One Collaborate.
-
Call Settings Webview (TLS)—Optional. Call Settings Webview (CSW) is required only if you want Webex for Cisco BroadWorks users to be able to configure calling features on the Webex App.
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|ADP 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|ADP 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|ADP Reuse
If you have an existing XSP|ADP 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 XSP|ADPs. 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|ADP, 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|ADP). 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|ADP.
-
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|ADP’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|ADP’s should be verified in a lab with the intended configuration prior to committing to the reuse.
Configure NTP Synchronization on XSP|ADP
The deployment requires time synchronization for all XSP|ADPs 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|ADP
software installation. See the BroadWorks Software Management Guide for more
detail.
During the interactive installation of the XSP|ADP software, you’re given the option to configure NTP. Proceed as follows:
-
When the installer asks,
Do you want to configure NTP?
, entery
. -
When the installer asks,
Is this server going to be a NTP server?
, entern
. -
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 XSP|ADPs 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|ADP 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|ADP 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|ADP 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 Cisco 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|ADP_CLI/Applications/Xsi-Events/BWIntegration>
eventQueueSize = 2000
XSP|ADP_CLI/Applications/Xsi-Events/BWIntegration>
eventHandlerThreadCount = 50
Multiple XSP|ADPs
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|ADP servers and the Webex for Cisco BroadWorks cloud and clients. In this case, you would provide the URL of the load balancer to the Webex for Cisco 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 XSP|ADP01 and XSP|ADP02 should both have the XSP|ADP domain, for example your-XSP|ADP.example.com, in the Subject Alternate Name. They should have their own FQDNs, for example XSP|ADP01.example.com, in the Common Name. You can use wildcard certificates, but we don’t recommend them.
Internet-Facing XSP|ADP Servers
If you expose the Xsi interfaces directly, use DNS to distribute the traffic to the multiple XSP|ADP servers.

Notes on this architecture:
-
Two records are required to connect to the XSP|ADP servers:
-
For Webex microservices: Round-robin A/AAAA records are required to target the multiple XSP|ADP IP addresses. This is because the Webex microservices can’t do SRV lookups. For examples, see Webex Cloud Services.
-
For Webex App: An SRV record that resolves to A records where each A record resolves to a single XSP|ADP. For examples, see Webex App.
Use prioritized SRV records to target the XSI service for the multiple XSP|ADP addresses. Prioritize your SRV records so that the microservices will always go to the same A record (and subsequent IP address) and will only move to the next A record (and IP address) if the first IP address is down. DO NOT use a round-robin approach for the Webex App.
-
-
Certificates from XSP|ADP01 and XSP|ADP02 should both have the XSP|ADP domain, for example your-XSP|ADP.example.com, in the Subject Alternate Name. They should have their own FQDNs, for example XSP|ADP01.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|ADP URL to an HTTP load balancer, and the load balancer is configured to redirect through a reverse proxy to the XSP|ADP servers.
Webex does not follow a redirect when connecting to the URLs you supply, so this configuration does not work.

Architecture & Infrastructure
-
What kind of scale do you intend to start with? It is possible to scale up in future, but your current usage estimate should drive infrastructure planning.
-
Work with your Cisco account manager / sales representative to size your XSP|ADP infrastructure, according to the Cisco BroadWorks System Capacity Planner and the Cisco BroadWorks System Engineering Guide.
-
How will Webex make Mutual TLS connections to your XSP|ADPs? Directly to the XSP|ADP in a DMZ, or via TLS proxy? This affects your certificate management, and the URLs you use for the interfaces. (We do not support unencrypted TCP connections to the edge of your network).