Water Mark
Oct 9, 2020 | view(s) | people thought this was helpful

Overview of Webex for BroadWorks

Overview of Webex for BroadWorks

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 Teams 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 Teams 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 Teams 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 Teams 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 Teams 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 Teams. Subscribers use a single application (Webex Teams) 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 Teams Infrastructure by selecting the option “Webex Teams Call” in Teams. (These calls are Teams to Teams, not Teams 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 Teams is the 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 Teams 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 three-person “space” meetings. In Webex Teams, 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 Teams 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 Teams to join, using the link provided by the Meetings host. Cisco Webex Dial-in phone numbers will be used for Meetings dial-in.

"Premium" Package

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

Compare Packages

Package

Calling

Messaging

Space Meetings

PMR Meetings

Basic

Included

Included

3 participants

None

Standard

Included

Included

25 participants

25 participants

Premium

Included

Included

25 participants

1000 participants

Messaging and Meeting Features

The Webex Help Center publishes the features and user facing documentation for Webex Teams 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 Webex Teams is the primary soft client.

Limitations

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

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

  • The Teams client isn’t brandable, beyond what is detailed currently in Add Your Company Branding to Webex Teams (This is a client limitation).

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

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.

Security, Data, and Roles

Cisco Webex Teams Security

Webex Teams 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 Teams 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 Teams data in the data center that most closely matches your region. See Data Residency in Cisco Webex Teams 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

  • Webex Teams serves as the primary application in Webex for BroadWorks offers. Teams 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 Teams 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 Teams 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 Teams 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 Teams 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 Teams 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 Teams applications on Apple devices.

  • FCM (FireBase Cloud Messaging) pushes call and message notifications to Webex Teams 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 Teams. 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.

Water Mark
Oct 9, 2020| view(s) | people thought this was helpful

Prepare Your Environment

Prepare Your Environment

Decision Points

Consideration Questions to answer Resources

Architecture & Infrastructure

How many XSPs?

How do they take mTLS?

Cisco BroadWorks System Capacity Planner

Cisco BroadWorks System Engineering Guide

XSP CLI Reference

This document

Customer and user provisioning

Can you assert that you trust emails in BroadWorks?

Do you want users to provide email addresses to activate their own accounts?

Can you build tools to use our API?

Public API docs at https://developer.webex.com

This document

Branding What color and logo do you want to use? Teams branding article
Templates What are your different customer use cases? This document
Subscriber Features per customer/enterprise/group Choose package to define level of service per template. Basic, Standard, Premium

This document

Feature/package matrix

User authentication BroadWorks, or Webex This document
Provisioning adapter (for flowthrough provisioning options)

Do you already use Integrated IM&P, eg for UC-One SaaS?

Do you intend to use multiple templates?

Is there a more common use case anticipated?

This document

Application Server CLI reference

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 infrastructure, according to the Cisco BroadWorks System Capacity Planner (https://xchange.broadsoft.com/node/473873) and theCisco BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/422649).

  • How will Cisco Webex make Mutual TLS connections to your XSPs? Directly to the XSP 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).

Customer and User Provisioning

Which user provisioning method suits you best?

  • Flowthrough Provisioning With Trusted Emails: By assigning the “Integrated IM&P” service on BroadWorks, the subscriber is automatically provisioned in Cisco Webex.

    If you can also assert that the subscriber email addresses in BroadWorks are valid, and unique to Webex, then you can use the "trusted email" variant of flowthrough provisioning. Subscriber Webex accounts are created and activated without their intervention; they simply download the client and sign in.

    Email Address is a key user attribute on Cisco Webex. Therefore the Service Provider must supply a valid email address for the user in order to provision them for Cisco Webex services. This must be in the user’s Email ID attribute in BroadWorks. We recommend that you copy it into the Alternate ID attribute as well.

  • Flowthrough Provisioning Without Trusted Emails: If you cannot trust the subscriber email addresses, you can still assign the Integrated IM&P service in BroadWorks to provision users in Webex.

    With this option, the accounts are created when you assign the service, but the subscribers need to supply and validate their email addresses to activate the Webex accounts.

  • User Self-Provisioning: This option does not require IM&P service assignment in BroadWorks. You (or your customers) distribute a provisioning link instead, and the links to download the different clients, with your branding and instructions.

    Subscribers follow the link, then supply and validate their email addresses to create and activate their Webex accounts. Then they download the client and sign in, and Webex fetches some additional configuration about them from BroadWorks (including their primary numbers).

  • SP Controlled Provisioning via APIs: Cisco Webex expose a set of Public APIs that allow Service Providers to build user/subscriber provisioning into their existing workflows.

Branding

You can apply a logo and a single color (for the navigation bar) to the Webex Teams client. The User Activation Portal uses the same settings.

Customer Templates

Customer Templates allow you to define the parameters by which customers and associated subscribers are automatically provisioned on Cisco Webex for BroadWorks.You may configure multiple Customer Templates as required. Some of the primary parameters are listed below.

Package

  • You must select a default package when you create a template (See Packages in the Overview section for details). All users who are provisioned with that template, whether by flowthrough- or self-provisioning, receive the default package.

  • You have control over the package selection for different customers by creating multiple templates and selecting different default packages in each. You could then distribute different provisioning links, or different per-enterprise provisioning adpaters, depending on your chosen user provisioning method for those templates.

  • You can change the package of specific subscribers from this default, using the provisioning API (see Integrating with Webex for BroadWorks Provisioning API in the Reference section) or through Partner Hub.

  • You cannot change a subscriber’s package from BroadWorks. The assignment of the Integrated IM&P service is either on or off; if the subscriber is assigned this service in BroadWorks, the Partner Hub template associated with that subscriber’s enterprise’s provisioning URL defines the package.

Reseller and Enterprises or Service Provider and Groups?

  • The way your BroadWorks system is configured has an impact on flow through provisioning. If you are a reseller with Enterprises, then you need to enable Enterprise mode when you create a template.
  • If your BroadWorks system is configured in Service Provider mode, you can leave the Enterprise mode switch off in your templates.
  • If you plan to provision customer organizations using both BroadWorks modes, you must use different templates for groups and enterprises.

Authentication Mode

How will customers’ subscribers authenticate?

Authentication Mode BroadWorks Webex
Primary user identity BroadWorks user ID Email address
Identity Provider

BroadWorks.

Authentication is facilitated by an intermediary service hosted by Cisco Webex.

Cisco Common Identity
Multi-factor authentication? No Requires Customer IdP that supports multi-factor authentication.

Credential validation path

  1. Browser is launched where user supplies email to initial login flow and discover their authentication mode.

  2. Browser is then redirected to a Cisco Webex hosted BroadWorks login page (This page is brandable)

  3. User supplies BroadWorks user id and password on the login page.

  4. User credentials are validated against BroadWorks.

  5. On success, an authorization code is obtained from Cisco Webex. This is used to obtained necessary access tokens for Cisco Webex services.

  1. Browser is launched where user supplies email to initial login flow and discover their authentication mode.

  2. Browser is redirect to IdP (either Cisco Common Identity or Customer IdP) where they will be presented with a login portal.

  3. User supplies appropriate credentials on login page

  4. Multi-factor Authentication may take place if the Customer IdP supports this.

  5. On success, an authorization code is obtained from Cisco Webex. This is used to obtained necessary access tokens for Cisco Webex services.

Multiple Partner Arrangements

Are you going to sub-license Webex for BroadWorks to another service provider? In this case, each service provider will need a distinct partner organization in Webex Control Hub to allow them provision the solution for their customer base.

Provisioning Adapter and Templates

When you are using flowthrough provisioning, the provisioning URL that you enter in BroadWorks is derived from the template in Control Hub. You can have multiple templates, and therefore multiple provisioning URLs. This enables you to select, on an enterprise by enterprise basis, which package to apply to subscribers when they are granted the Integrated IM&P service.

You need to consider whether you want to set a system level provisioning URL as a default provisioning path, and which template you want to use for that. This way, you only need to explicitly set the provisioning URL for those enterprises that need a different template.

Also, bear in mind that you may already be using a system level provisioning URL, for example with UC-One SaaS. If that is the case, you may opt to preserve the system level URL for provisioning users on UC-One SaaS, and override for those enterprises moving to Webex for BroadWorks. Alternatively, you may want to go the other way and set the system level URL for Webex for BroadWorks, and reconfigure those enterprises you want to keep on UC-One SaaS.

The configuration choices related to this decision are detailed in Configure Application Server with Provisioning Service URL in the Deploy Webex for BroadWorks section.

Minimum Requirements

Accounts

All subscribers that you are provisioning for Webex must exist in the BroadWorks system that you integrate with Webex. You can integrate multiple BroadWorks systems if necessary.

All subscribers must have BroadWorks licenses and primary numbers.

Webex uses email addresses as primary identifiers for all users. If you are using flowthrough provisioning with trusted emails, then your users must have valid addresses in the email attribute in BroadWorks.

If your template uses BroadWorks authentication, you can copy subscriber email addresses into the Alternate ID attribute in BroadWorks. This makes it possible for users to sign into Webex using their email addresses and their BroadWorks passwords.

Your admins must use their Webex accounts to sign in to Partner Hub.

Servers in Your Network and Software Requirements

  • BroadWorks instance(s) with minimum version R21 SP1. See BroadWorks Software Requirements (in this document) for supported versions and patches. See also Lifecycle Management - BroadSoft Servers.


    R21 SP1 is only supported until mid-2021. Even though you can currently integrate Webex with R21 SP1, we strongly recommend R22 or later for integration with Webex.

  • The BroadWorks instance(s) should include at least the following servers:

    • Application Server (AS) with BroadWorks version as above

    • Network Server (NS)

    • Profile Server (PS)

  • Public-facing XSP Server(s) or Application Delivery Platform (ADP) meeting the following requirements:

    • Authentication service (BWAuth)

    • XSI actions and events interfaces

    • DMS (device management web application)

    • CTI interface (Computer Telephony Intergration)

    • TLS 1.2 with a valid certificate (not self-signed) and any intermediates required. Requires System Level Admin to facilitate enterprise lookup.

    • Mutual TLS (mTLS) authentication for Authentication Service (Requires the public Cisco Webex client certificate chain installed as trust anchors)

    • Mutual TLS (mTLS) authentication for CTI interface (Requires the public Cisco Webex client certificate chain installed as trust anchors)

  • A separate XSP/ADP server acting as a “Call Notifications Push Server” (an NPS in your environment used to push call notifications to Apple/Google. We call it “CNPS” here to distinguish it from the service in Webex that delivers push notifications for messaging and presence).

    This server must be on R22 or later.

  • We mandate a separate XSP/ADP server for CNPS because the unpredictability of the load from Webex for BWKS cloud connections could negatively impact the performance of the NPS server, with the result of increasing notification latency. See the Cisco BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/422649) for more on XSP scale.

Physical Phones and Accessories

Device Profiles

These are the DTAF files you need to load onto your Application Servers to support Webex Teams as calling clients. They are the same DTAF files as used for UC-One SaaS, however there is a new config-wxt.xml.template file that is used for Webex Teams.

Client Name Device Profile Type and Package name

Webex Teams Mobile Template

https://xchange.broadsoft.com/support/uc-one/connect/software

Identity/Device Profile Type: Connect - Mobile

DTAF: ucone-mobile-ucaas_DTAF-#.#.#.###.zip

Config file: config-wxt.xml

Webex Teams Desktop Template

From https://xchange.broadsoft.com/support/uc-one/communicator/software

Identity/Device Profile Type: Business Communicator - PC

DTAF: ucone-desktop-ucaas_DTAF-#.#.#.###.zip

Config file: config-wxt.xml

Order Certificates

Certificate Requirements for TLS Authentication

You will need Security Certificates, signed by a well-known Certificate Authority and deployed on your Public facing XSPs, for all required applications. These will be used to support TLS certificate verification for all inbound connectivity to your XSP servers.

These certificates should include your XSP public fully qualified domain name as Subject Common Name or Subject Alternate Name.

The exact requirements for deploying these server certificates depends on how your public facing XSPs are deployed:

  • Via a TLS bridging proxy

  • Via a TLS pass-through proxy

  • Directly to the XSP

The following diagram summarizes where the CA-signed public server certificate needs to be loaded in these three cases:

The publicly supported CAs that Webex Teams supports for authentication are listed in Supported Certificate Authorities for Cisco Webex Hybrid Services.

TLS Certificate Requirements for TLS-bridge Proxy

  • The publicly signed server certificate is loaded into the proxy.

  • The proxy presents this publicly signed server certificate to Webex.

  • Webex trusts the public CA that signed the proxy’s server certificate.

  • An internal CA signed certificate can be loaded onto the XSP.

  • The XSP presents this internally signed server certificate to the proxy.

  • The proxy trusts the internal CA that signed the XSP server certificate.

TLS Certificate Requirements for TLS-passthrough Proxy or XSP in DMZ

  • The publicly signed server certificate is loaded into the XSPs.

  • The XSPs present publicly signed server certificates to Webex.

  • Webex trusts the public CA that signed the XSPs’ server certificates.

Additional Certificate Requirements for Mutual TLS Authentication against AuthService

Cisco Webex interacts with the Authentication Service over a mutual TLS authenticated connection. This means Webex presents a client certificate and the XSP must validate it. In order to trust this certificate, use the Webex CA certificate chain to create a trust anchor on XSP (or proxy). The certificate chain is available for download via Partner Hub:

  1. Go to Settings > BroadWorks Calling.

  2. Click the download certificate link.


You can also get the certificate chain from https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

The exact requirements for deploying this Webex CA certificate chain depends on how your public facing XSPs are deployed:

  • Via a TLS bridging proxy

  • Via a TLS pass-through proxy

  • Directly to the XSP

The following diagram summarizes where the Webex CA certificate chain must be deployed in these three cases.

Mutual TLS Certificate Requirements for TLS-bridge Proxy

  • Webex presents a Webex CA signed client certificate to the proxy.

  • The Webex CA certificate chain is deployed on the proxy trust store, so the proxy trusts the client certificate.

  • The publicly signed XSP server certificate is also loaded into the proxy.

  • The proxy presents a publicly signed server certificate to Webex.

  • Webex trusts the public CA that signed the proxy’s server certificate.

  • The proxy presents an internally signed client certificate to the XSPs.

    This certificate must have the x509.v3 extension field Extended Key Usage populated with the BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 and the TLS clientAuth purpose. E.g.:

    X509v3 extensions:

    X509v3 Extended Key Usage:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client
                  Authentication 

    When generating internal client certificates for the proxy, note that SAN certificates are not supported. Internal server certificates for the XSP can be SAN.

  • The XSPs trust the internal CA.

  • The XSPs present an internally signed server certificate.

  • The proxy trusts the internal CA.

Mutual TLS Certificate Requirements for TLS-passthrough Proxy or XSP in DMZ

  • Webex presents a Webex CA signed client certificate to the XSPs.

  • The Webex CA certificate chain is deployed on the XSPs’ trust store, so the XSPs trust the client certificate.

  • The publicly signed XSP server certificate is also loaded into the XSPs.

  • The XSPs present publicly signed server certificates to Webex.

  • Webex trusts the public CA that signed the XSPs’ server certificates.

Additional Certificate Requirements for Mutual TLS Authentication over CTI Interface

When connecting to the CTI interface, Cisco Webex presents a client certificate as part of Mutual TLS authentication. The Webex client certificate CA/chain certificate is available for download via Control Hub.

To download the certificate:

Sign in to Partner Hub, got to Settings > BroadWorks Calling and click the download certificate link.

The exact requirements for deploying this Webex CA certificate chain depends on how your public facing XSPs are deployed:

  • Via a TLS bridging proxy

  • Via a TLS pass-through proxy

  • Directly to the XSP

The following diagram summarizes the certificate requirements in these three cases:

Figure 1. mTLS Certificate Exchange for CTI via Different Edge Configurations

This image is not available in preview/cisco.com

(Option) Certificate Requirements for TLS-bridge Proxy

  • Webex presents a publicly signed client certificate to the proxy.

  • The proxy trusts the Cisco internal CA that signed the client certificate. You can download this CA / chain from Control Hub and add it to the proxy’s trust store. The publicly signed XSP server certificate is also loaded into the proxy.

  • The proxy presents the publicly signed server certificate to Webex.

  • Webex trusts the public CA that signed the proxy’s server certificate.

  • The proxy presents an internally signed client certificate to the XSPs.

    This certificate must have the x509.v3 extension field Extended Key Usage populated with the BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 and the TLS clientAuth purpose. E.g.:

    X509v3 extensions:
        X509v3 Extended Key Usage:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

    When generating internal client certificates for the proxy, note that SAN certificates are not supported. Internal server certificates for the XSP can be SAN.

  • The XSPs trust the internal CA.

  • The XSPs present an internally signed server certificate.

  • The proxy trusts the internal CA.

  • The Application Server’s ClientIdentity contains the CN of the internally signed client certificate presented to the XSP by the proxy.

(Option) Certificate Requirements for TLS-passthrough Proxy or XSP in DMZ

  • Webex presents a Cisco internal CA-signed client certificate to the XSPs.

  • The XSPs trust the Cisco internal CA that signed the client certificate. You can download this CA / chain from Control Hub and add it to the proxy’s trust store. The publicly signed XSP server certificate is also loaded into the XSPs.

  • The XSPs present the publicly signed server certificates to Webex.

  • Webex trusts the public CA that signed the XSPs’ server certificates.

  • The Application Server ClientIdentity contains the CN of the Cisco-signed client certificate presented to the XSP by Webex.

Prepare Your Network

Connection Map

The following diagram illustrates integration points. The point of the diagram is to show that you need to review IPs and Ports for connections into and out of your environment. The connections that are used by Webex for BroadWorks are described in the following tables.

The firewall requirements for the normal functioning of the client application however are listed as references since they are already documented on help.webex.com.

Firewall Configuration

The connection map and the following tables describe the connections and protocols required between the clients (on or off the customer’s network), your network, and the Webex platform.

We only document the connections specific to Webex for BroadWorks. We do not show the generic connections between Teams and the Webex cloud, which are documented at:

EMEA Ingress Rules

(Into your network)

Purpose Source Protocol Destination Destination Port

WebexCloud

CTI/Auth/XSI

18.196.116.47

35.156.83.118

35.158.206.190

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

CTI

Your XSP

TCP/TLS 8012

443

Webex Teams Client App

Xsi/DMS

Any

HTTPS

Your XSP

443

Webex Teams VoIP endpoints SIP

Any

SIP

Your SBC

SP configured TCP

EMEA Egress Rules

(Out of your network)

Purpose

Source

Protocol

Destination

Destination Port

User Provisioning via APIs

Your Application Server

HTTPS

webexapis.com

443

Proxy Push Notifications(production service)

Your NPS Server

HTTPS

https://nps.uc-one.broadsoft.com/

OR 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Webex Common Identity

Your NPS Server

HTTPS

https://idbroker-eu.webex.com

443

APNS and FCM services

Your NPS Server

HTTPS

Any IP address*

443

Proxy Push Notifications(production service)

Webex Common Identity

APNS and FCM services

Your NPS Server

HTTPS

https://nps.uc-one.broadsoft.com/ *

https://idbroker-eu.webex.com

Any IP address*

443

User Provisioning via BroadWorks Provisioning Adapter

Your BroadWorks AS

HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(where * could be any letter. Your exact provisioning URL is available in the template you create in Partner Hub)

443

† These ranges contain the hosts for NPS proxy, but we cannot give the exact addresses. The ranges may also contain hosts that are not related to Webex for BroadWorks. We recommend that you configure your firewall to allow traffic to the NPS proxy FQDN instead, to ensure that your egress is only towards the hosts we expose for NPS proxy.

* APNS and FCM do not have a fixed set of IP addresses.

USA Ingress Rules

(Into your network)

Purpose

Source

Protocol

Destination

Destination Port

WebexCloud

CTI/Auth/XSI

13.58.232.148

18.217.166.80

18.221.216.175

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

CTI

Your XSP

TCP/TLS 8012

TLS 443

Webex Teams Client App   

Xsi/DMS

Any

HTTPS

Your XSP

443

Webex Teams VoIP endpoints SIP

Any

SIP

Your SBC

SP configured TCP

USA Egress Rules

(Out of your network)

Purpose

Source

Protocol

Destination

Destination Port

User Provisioning via APIs

Your Application Server

HTTPS

webexapis.com

443

Proxy Push Notifications(production service)

Your NPS Server

HTTPS

https://nps.uc-one.broadsoft.com/

OR 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Webex Common Identity

Your NPS Server

HTTPS

https://idbroker.webex.com

443

APNS and FCM services

Your NPS Server

HTTPS

Any IP address*

443

User Provisioning via BWKS Provisioning Adapter

Your BroadWorks AS

HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(where * could be any letter. Your exact provisioning URL is available in the template you create in Partner Hub)

443

† These ranges contain the hosts for NPS proxy, but we cannot give the exact addresses. The ranges may also contain hosts that are not related to Webex for BroadWorks. We recommend that you configure your firewall to allow traffic to the NPS proxy FQDN instead, to ensure that your egress is only towards the hosts we expose for NPS proxy.

* APNS and FCM do not have a fixed set of IP addresses.

DNS Configuration

Webex for BroadWorks clients must be able to find your BroadWorks XSP server(s) for authentication, authorization, call control, and device management.

The Webex cloud must be able to find your BroadWorks XSP server(s) for connecting to the Xsi interfaces and authentication service.

You may need to record multiple DNS entries if you have different XSP servers for different purposes.


We strongly recommend that you configure SRV records to resolve the XSPs you use with Webex for BroadWorks. Using only A/AAAA records causes unnecessary internal traffic between your XSPs, reducing performance.

How Cisco Webex Cloud Finds XSP Addresses

Cisco Webex Cloud services will perform DNS A/AAAA lookup of the configured XSP hostname and connects to the returned IP Address. This could be a load balancing edge element, or it could be the XSP server itself. If multiple IP Addresses are returned, the initial entry in the list will be selected.

Examples 2 & 3 below capture A/AAAA records mapping to single and multiple IP addresses respectively.

In the multiple IP Address scenario, we recommend that you configure your DNS entries to rotate in a round robin manner, to distribute the client connections from Webex.

How Clients Find XSP Addresses

The client attempts to locate the XSP nodes using the following DNS flow:

  1. Client initially retrieves Xsi-Actions/Xsi-Events URLs from Cisco Webex cloud (you entered them when creating the associated BroadWorks Calling Cluster). The Xsi hostname/domain is parsed from the URL and the client performs SRV lookup as follows:

    1. Client performs an SRV lookup for _xsi-client._tcp.<xsi domain>

      (See following example 1)

    2. If the SRV lookup returns one or more targets:

      The client does A/AAAA lookup for those targets and caches the returned IP addresses.

      The client connects to the SRV port on one of the returned IP addresses. It chooses an address based on the SRV priority, then weight (or at random if they’re all equal).

    3. If the SRV lookup does not return any targets:

      The client does A/AAAA lookup of the Xsi root parameter and then tries to connect to the returned IP address. This could be a load balancing edge element, or it could be the XSP server itself.

      (See following examples 2 and 3)

  2. (Optional) You may subsequently provide custom XSI-Actions/XSI-Events details in the device confguration for the Webex Teams client, using the following tags:

    
    <protocols>
        <xsi>
            <paths>
                <root>%XSI_ROOT_WXT%</root>
                <actions>%XSI_ACTIONS_PATH_WXT%</actions>
                <events>%XSI_EVENTS_PATH_WXT%</events>
            </paths>
        </xsi>
    </protocols>
    1. These configuration parameters take precedence over any configuration in your BroadWorks Cluster in Control Hub.

    2. If they exist, the client will compare against the original XSI address it received via the BroadWorks Cluster configuration.

    3. If there is any difference detected, the Client will re-initialize it’s XSI Actions/ XSI Events connectivity. The first step in this is to perform the same DNS lookup process listed under step 1 – this time using the %XSI_ROOT_WXT% parameter from the configuration file.


      Make sure to create the corresponding SRV records if you use this tag to change the Xsi interfaces.

Example DNS Records

Table 1. Example 1: DNS SRV records for client discovery of multiple internet facing XSP servers

Record type

Record

Target

Purpose

SRV

_xsi-client._tcp.your-xsp.example.com.

xsp01.example.com

Client discovery of Xsi interface

SRV

_xsi-client._tcp.your-xsp.example.com.

xsp02.example.com

Client discovery of Xsi interface

A

xsp01.example.com.

198.51.100.48

Lookup of XSP IP

A

xsp02.example.com.

198.51.100.49

Lookup of XSP IP

Table 2. Example 2: DNS A Record for discovery of load balancer fronting XSP server pool

Record type

Name

Target

Purpose

A

your-xsp.example.com.

198.51.100.50

Lookup of edge load balancer IP

Table 3. Example 3: DNS A Record for discovery of Round-Robin balanced internet-facing XSP server pool

Record type

Name

Target

Purpose

A

your-xsp.example.com.

198.51.100.48

Lookup of XSP IP

A

your-xsp.example.com.

198.51.100.49

Lookup of XSP IP

XSP Nodes DNS Recommendations

  • You should use a single A/AAAA record:

    • if you need to resolve a load balancing reverse proxy to the XSP servers

  • You should use round-robin A/AAAA records:

    •  if you have multiple internet facing XSP servers

  • You must use DNS Service Discovery if you:

    • Need directory search in environments with multiple XSPs.

    • Have pre-existing integrations that require SRV discovery.

    • Have unique configurations where standard A/AAAA records are insufficient.

Water Mark
Oct 9, 2020| view(s) | people thought this was helpful

Deploy Webex for BroadWorks

Deploy Webex for BroadWorks

Deployment Overview

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

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

Partner Onboarding for Cisco Webex for BroadWorks

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

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

Configure Services on Your Webex for BroadWorks XSPs

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

You need the following applications / services on your XSPs.

Service/Application

Authentication required

Service/application purpose

Xsi-Events

TLS (server authenticates itself to clients)

Call control, service notifications

Xsi-Actions

TLS (server authenticates itself to clients)

Call control, actions

Device management

TLS (server authenticates itself to clients)

Calling configuration download

Authentication Service

mTLS (client and server authenticate each other)

User authentication

Computer Telephony Integration

mTLS (client and server authenticate each other)

Telephony presence

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

Co-Residency Requirements

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

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

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

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

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

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

Xsi Interfaces

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

Install Authentication Service

Install Authentication Service

On BroadWorks R22 and up, you don’t need to install the authentication service, as it’s a managed application.

On BroadWorks 21SP1, the authentication service is an unmanaged application. Install it by completing the following steps:

  1. Download authenticationService_1.0.war (web application resource) file from Xchange (https://xchange.broadsoft.com/node/499012).

    On each XSP used with Webex, do the following:

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

  3. Install authentication service application with the following CLI context and command:

    XSP_CLI/Maintenance/ManagedObjects> install application /tmp/authenticationService_1.0.war

Configure Authentication Service

BroadWorks long-lived tokens are generated and validated by the authentication service hosted on your XSPs.

Requirements

  • The XSP servers hosting the Authentication Service must have an mTLS interface configured.

  • XSPs must share the same keys for encrypting/decrypting BroadWorks long lived tokens. Copying these keys to each XSP is a manual process.

  • XSPs must be synchronized with NTP.

Configuration Overview

The essential configuration on your XSPs includes:

  • Deploy the authentication service.

  • Configure token duration to at least 60 days (leave the issuer as BroadWorks).

  • Generate and share RSA keys across XSPs.

  • Provide the authService URL to the web container.

Deploy the Authentication Service on XSP

On each XSP used with Webex:

  1. Activate the authentication service application on the path /authService (you must use this path):

    XSP_CLI/Maintenance/ManagedObjects> activate application authenticationService <version> /authService

    (where <version> is 1.0 for the unmanaged application on 21SP1, or your BroadWorks version for 22 or later).

  2. Deploy the application:

    XSP_CLI/Maintenance/ManagedObjects> deploy application /authService

Configure Token Duration

  1. Check the existing token configuration (hours):

    On 21SP1:XSP_CLI/Applications/authenticationService_1.0/TokenManagement> get

    On 22 and later: XSP_CLI/Applications/authenticationService/TokenManagement> get

  2. Set the duration to 60 days (max is 180 days):

    On 21SP1:XSP_CLI/Applications/authenticationService_1.0/TokenManagement> set tokenDuration 1440

    On 22 and later: XSP_CLI/Applications/authenticationService/TokenManagement> set tokenDurationInHours 1440

Generate and Share RSA Keys

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

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

Because of these two factors you need to generate keys on one XSP then copy them to all other XSPs.


If you cycle keys or change the key length, you need to repeat the following configuration and restart all the XSPs.

  1. Select one XSP to use for generating a key pair.

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

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

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

  3. (21SP1 only) Check the configurable key location using the following command:

    XSP_CLI/Applications/authenticationService_1.0/KeyManagement> get

  4. (21SP1 only) Take note of the returned fileLocation parameter.

  5. (21SP1 only) Copy the whole fileLocation directory, which contains public and private subdirectories, to all other XSPs.

  6. (R22 and later) The key store location is not configurable. Export the keys:

    XSP_CLI/Applications/authenticationService/KeyManagement> exportKeys

  7. (R22 and later) Copy the exported file /var/broadworks/tmp/authService.keys to the same location on the other XSPs, overwriting an older .keys file if necessary.

  8. (R22 and later) Import the keys on each of the other XSPs:

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

Provide the authService URL to the web container

The XSP’s web container needs the authService URL so it can validate tokens.

On each of the XSPs:

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

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

  2. Add the authentication service URL to the container:

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

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

  3. Check the parameter with get.

  4. Restart the XSP.

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

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

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

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

Specificity CLI context
System (global)

XSP_CLI/System/SSLCommonSettings/JSSE/Ciphers>

XSP_CLI/System/SSLCommonSettings/JSSE/Protocols>

Transport protocols for this system

XSP_CLI/System/SSLCommonSettings/OpenSSL/Ciphers>

XSP_CLI/System/SSLCommonSettings/OpenSSL/Protocols>

HTTP on this system

XSP_CLI/Interface/Http/SSLCommonSettings/Ciphers>

XSP_CLI/Interface/Http/SSLCommonSettings/Protocols>

Specific HTTP server interfaces on this system

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

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

Reading HTTP Server TLS Interface Configuration on the XSP

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

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

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

XSP_CLI/Interface/Http/HttpServer> get

Adding TLS 1.2 Protocol to the HTTP Server Interface


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

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

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

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

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

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

Editing TLS Ciphers Configuration on the HTTP Server Interface


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

To configure the required ciphers:

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

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

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


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

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

Configure mTLS for AuthenticationService

Configure Trust (R21 SP1)
  1. Sign in to Partner Hub.

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


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

  3. Split the certificate chain into two certificates:

    1. Open combinedcertchain.txt in a text editor.

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

    3. Save the new file as broadcloudroot.txt.

    4. Save the original file as broadcloudissuing.txt.

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

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

  5. Sign in to the XSP and navigate to /XSP_CLI/Interface/Http/ClientAuthentication>

  6. Run the get command and read the chainDepth parameter.

    (chainDepth is 1 by default, which is too low for the Webex chain which has two certificates)

  7. If the chainDepth is not already greater than 2, run set chainDepth 2.

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

  9. Upload the certificate files to new trust anchors:

    XSP_CLI/Interface/Http/ClientAuthentication/Trusts> updateTrust webexclientroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/Http/ClientAuthentication/Trusts> updateTrust webexclientissuing /tmp/broadcloudissuing.txt


    webexclientroot and webexclientissuing are example aliases for the trust anchors; you can use your own.

  10. Confirm both certificates are uploaded:

    /XSP_CLI/Interface/Http/ClientAuthentication/Trusts> get

Configure Trust (R22 and later)

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

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


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

  3. Split the certificate chain into two certificates:

    1. Open combinedcertchain.txt in a text editor.

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

    3. Save the new file as broadcloudroot.txt.

    4. Save the original file as broadcloudissuing.txt.

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

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

  5. (Optional) Run help UpdateTrust to see the parameters and command format.

  6. Upload the certificate files to new trust anchors:

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientissuing /tmp/broadcloudissuing.txt


    webexclientroot and webexclientissuing are example aliases for the trust anchors; you can use your own.

  7. Confirm the anchors are updated:

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

      Alias   Owner                                   Issuer
    =============================================================================
    webexclientissuing    BroadCloud Commercial Issuing CA – DA3     BroadCloud Commercial Trusted Root CA
    webexclientroot       BroadCloud Commercial Trusted Root CA      BroadCloud Commercial Trusted Root CA[self-signed]

(Option) Configure mTLS at the HTTP interface/port level

It is possible to configure mTLS at the HTTP interface/port level or on a per-web application basis.

The way you enable mTLS for your application depends on the applications you are hosting on the XSP. If you are hosting multiple applications that require mTLS, you should enable mTLS on the interface. If you only need to secure one of several applications that use the same HTTP interface, you can configure mTLS at the application level.

When configuring mTLS at the HTTP interface/port level, mTLS is required for all hosted web applications accessed via this interface/port.

  1. Sign in to the XSP whose interface you're configuring.

  2. Navigate to XSP_CLI/Interface/Http/HttpServer> and run the get command to see the interfaces.

  3. To add an interface and require client authentication there (which means the same as mTLS):

    XSP_CLI/Interface/Http/HttpServer> add IPAddress Port Name true true

    See the XSP CLI documentation for detail. Essentially, the first true secures the interface with TLS (server certificate is created if required) and the second true forces the interface to require client certificate authentication (together they are mTLS).

For example:

XSP_CLI/Interface/Http/HttpServer> get

Interface Port Name Secure Client Auth Req Cluster Fqdn
         =======================================================
         192.0.2.7 443 xsp01.collab.example.net true false 
         192.0.2.7 444 xsp01.collab.example.net true true

In this example, mTLS (Client Auth Req = true) is enabled on 192.0.2.7 port 444. TLS is enabled on 192.0.2.7 port 443.

(Option) Configure mTLS for specific web applications

It is possible to configure mTLS at the HTTP interface/port level or on a per-web application basis.

The way you enable mTLS for your application depends on the applications you are hosting on the XSP. If you are hosting multiple applications that require mTLS, you should enable mTLS on the interface. If you only need to secure one of several applications that use the same HTTP interface, you can configure mTLS at the application level.

When configuring mTLS at the application level, mTLS is required for that application regardless of the HTTP server interface configuration.

  1. Sign in to the XSP whose interface you're configuring.

  2. Navigate to XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> and run the get command to see which applications are running.

  3. To add an application and require client authentication for it (which means the same as mTLS):

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> add IPAddress Port ApplicationName true

    See the XSP CLI documentation for detail. The application names are enumerated there. The true in this command enables mTLS.

For example:

XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> add 192.0.2.7 443 AuthenticationService true

The example command adds the AuthenticationService application to 192.0.2.7:443 and requires it to request and authenticate certificates from the client.

Check with get:

XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> get

Interface Ip Port Application Name Client Auth Req
         ===================================================
         192.0.2.7 443 AuthenticationService      true          

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

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

CTI Interface and Related Configuration

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

  1. Configure Application Server for CTI Subscriptions

  2. Configure XSPs for mTLS Authenticated CTI Subscriptions

  3. Open Inbound Ports for Secure CTI Interface

  4. Subscribe Your Webex Organization to BroadWorks CTI Events

Configure Application Server for CTI Subscriptions

Update the ClientIdentity on Application Server with the common name (CN) of the client certificate. If you are using a TLS-bridging proxy, it is the CN of the internally signed certificate that the proxy presents to the XSP. Otherwise, it is the CN of the Webex for BroadWorks CTI client certificate.

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

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


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

Configure TLS and Ciphers on the CTI Interface

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

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

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

Specificity

CLI Context

System (global)

(R22 and later)

XSP_CLI/System/SSLCommonSettings/JSSE/Ciphers>

XSP_CLI/System/SSLCommonSettings/JSSE/Protocols>

Transport protocols for this system

(R22 and later)

XSP_CLI/System/SSLCommonSettings/OpenSSL/Ciphers>

XSP_CLI/System/SSLCommonSettings/OpenSSL/Protocols>

All CTI interfaces on this system

(R22 and later)

XSP_CLI/Interface/CTI/SSLCommonSettings/Ciphers>

XSP_CLI/Interface/CTI/SSLCommonSettings/Protocols>

A specific CTI interface on this system

(R22 and later)

XSP_CLI/Interface/CTI/SSLSettings/Ciphers>

XSP_CLI/Interface/CTI/SSLSettings/Protocols>

Reading CTI TLS Interface Configuration on the XSP

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

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

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

Adding TLS 1.2 Protocol to the CTI Interface


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

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

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

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

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

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

Editing TLS Ciphers Configuration on the CTI Interface


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

To configure the required ciphers on the CTI interface:

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

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

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


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

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

Update Trust Anchors for CTI Interface (R22 and later)

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

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

  1. Sign in to Partner Hub.

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


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

  3. Split the certificate chain into two certificates:

    1. Open combinedcertchain.txt in a text editor.

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

    3. Save the new file as broadcloudroot.txt.

    4. Save the original file as broadcloudissuing.txt.

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

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

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

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

  7. Upload the certificate files to new trust anchors:

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

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


    webexroot and webexissuing are example aliases for the trust anchors; you can use your own.

  8. Confirm the anchors are updated:

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

      Alias   Owner                                   Issuer
    =============================================================================
    webexissuing    BroadCloud Commercial Issuing CA – DA3     BroadCloud Commercial Trusted Root CA
    webexroot       BroadCloud Commercial Trusted Root CA      BroadCloud Commercial Trusted Root CA[self-signed]
  9. Allow clients to authenticate with certificates:

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

Update Trust Anchors for CTI Interface (R21)

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

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

  1. Sign in to Partner Hub.

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


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

  3. Split the certificate chain into two certificates:

    1. Open combinedcertchain.txt in a text editor.

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

    3. Save the new file as broadcloudroot.txt.

    4. Save the original file as broadcloudissuing.txt.

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

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

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

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

  7. Update new trust anchors with the certificates:

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

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

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

  8. Confirm both certificates are uploaded:

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

    XSP_CLI/Interface/CTI/SSLConfiguration/ClientAuthentication/Trusts> get
                 Alias                                   Owner                                           Issuer
    ===========================================================================================================
         webexissuing   BroadCloud Commercial Issuing CA - DA3 BroadCloud Commercial Trusted Root CA
            webexroot   BroadCloud Commercial Trusted Root CA  BroadCloud Commercial Trusted Root CA[self-signed]
  9. Allow clients to authenticate with certificates:

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

Add CTI Interface and Enable mTLS

  1. Add the CTI SSL interface.

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

    • On BroadWorks 22 and 23.0:

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

    • On BroadWorks 21.sp1:

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

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

    XSP_CLI/Interface/CTI> set securePortEnabled true

    XSP_CLI/Interface/CTI> set securePort 8012

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

    • On BroadWorks 22 and 23.0:

      XSP_CLI/Interface/CTI/SSLSettings> get

    • On BroadWorks 21.sp1:

      XSP_CLI/Interface/CTI/SSLConfiguration> get

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

      On BroadWorks 22.0 and 23.0:

      XSP_CLI/Interface/CTI/SSLSettings/Certificates> sslUpdate <interface IP> keyFile </path/to/certificate key file>

      XSP_CLI/Interface/CTI/SSLSettings/Certificates> sslUpdate <interface IP> certificateFile </path/to/server certificate>

      On BroadWorks 21.sp1:

      XSP_CLI/Interface/CTI/SSLConfiguration> sslUpdate <interface IP> keyFile </path/to/certificate key file>

      XSP_CLI/Interface/CTI/SSLConfiguration> sslUpdate <interface IP> certificateFile </path/to/server certificate>

  4. Restart the XSP.

Open Inbound Ports for Secure CTI Interface

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

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

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

  2. Enter get.

Among other information, you should see the following:

securePortEnabled = true

securePort = 8012

This ensures that Webex can initiate an encrypted connection.

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

Enable Access to BroadWorks CTI Events on Cisco Webex

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

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

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

Configure Call Push Notifications From Your Network

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

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

For more information about NPS, see https://xchange.broadsoft.com/node/485737.

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

NPS Proxy Overview

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

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

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

The BroadWorks patches for the feature are available on Xchange: https://xchange.broadsoft.com/node/1046235

For more information, see the Push Server for VoIP in UCaaS Feature Description on Xchange: https://xchange.broadsoft.com/node/1045458

Considerations for Existing NPS to be Used with Webex for BroadWorks

Read these notes before you configure your shared NPS to use the NPS Proxy:

  • You must not change from GCM API to FCM v1 API before you have the NPS Proxy configured. You must only change over while configuring NPS to use NPS Proxy.

  • When you have verified that notifications are working properly for older apps with the NPS proxy, you can remove the GCM API key for the Android app, and the APNs auth key for the iOS app.

Configure your NPS to Work with the NPS Proxy

Prerequisite: XSP R22 or later, with NPS activated. Patched with https://xchange.broadsoft.com/node/1046235

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

    You’ll get the OAuth client ID, client secret, and a refresh token that is valid for 60 days from Cisco. If the token expires before you use it with your NPS, you can raise another request.

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

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

    XSP_CLI/Applications/NotificationPushServer/CloudNPSService> set VOIPTokenRefreshInterval 1800

  3. Create the client account on the NPS:

    XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set clientId client-Id-From-Step1

    XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set clientSecret client-Secret-From-Step1

    XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set RefreshToken Refresh-Token-From-Step1

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

    • Webex Teams for Android: com.cisco.wx2.android

    • Android UC-One/SAAS: com.broadsoft.connect

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

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

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true


    This step can be performed prior to configuring the NPS Proxy, but only if you are not already using this NPS for UC-One. You can set V1enabled false to revert to using the GCM API key.

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

    • Webex Teams iOS:XSP_CLI/Applications/NotificationPushServer/APNS/Production/Tokens> add com.cisco.squared

    • iOS UC-One/SAAS: XSP_CLI/Applications/NotificationPushServer/APNS/Production/Tokens>add com.broadsoft.uc-one

  7. Restart the XSP:

    bwrestart

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

Migrating from FCM to FCMv1

The XSP-to-host NPS must meet the following requirements:

  • There is only one NPS app in a deployment. If you're using Mobile Collaborate/Connect and or SaaS implementing Webex for BroadWorks, you must share this single NPS app.

  • We recommend that the NPS be on a dedicated XSP/ADP and that the NPS is the only NPS app on the XSP, to eliminate interference with the delivery of Push notifications.

  • More information on the new ADP server can be found on the Application Delivery Platform.

IOS HTTP/2 Support

  • You must be on r22+ or r23 XSP. An r22 / r23 XSP is compatible to run in parallel with an r21 stack if the XSP only runs NPS and the AS is r21.sp1. See the BroadWorks Compatibility Matrix for more information.

  • If you have deployed any iOS apps non-Cisco/BroadSoft, those apps must be configured to use the HTTP/2 APNS protocol.

  • XSP/ADPs that already support the Collaborate or SaaS BroadWorks app need to be migrated to HTTP/2. For instructions, see HTTP/2 Support to Notification Push Server for APNS.

  • Additional steps for HTTP2 for SaaS clients:

    1. Login to your BAM portal.

    2. Select Configuration > BroadWorks.

    3. In the Notification Push Server section, select Release 22 in the drop-down menu, then follow the instructions.

Android FCMv1 /HTTPv1

  • If you have deployed any Android apps Non-Cisco/BroadSoft, those apps must be configured to use the FCMv1 keys.

  • If the XSP/ADP currently supports the Connect or UC-One SaaS app, then FCMv1 keys cannot be enabled prior to the next step in the XSP/ADP configuration. We recommend that you migrate all additional apps to FCMv1 keys, enable and test, then disable until you're ready to complete the setup instructions.

Install the following required patches:

R22

  • AP.xsp.22.0.1123.ap369607

  • AP.platform.22.0.1123.ap369607

  • AP.xsp.22.0.1123.ap374677

  • AP.xsp.22.0.1123.ap375206

R23

  • AP.xsp.23.0.1075.ap369607

  • AP.platform.23.0.1075.ap369607

  • AP.xsp.23.0.1075.ap374677

  • AP.xsp.23.0.1075.ap375206

XSP Setup

Important: If the XSP/ADP is already supporting the Android UC-One SaaS or Connect clients, then FCMv1 keys must only be enabled during this process. If the XSP/ADP does not already support these clients, then FCMv1 keys can be enabled before completing the steps below.

Once you complete all of the steps in Migrating from FCM to FCMv1 above, complete the steps below using the OAuth client ID, client secret, and a refresh token provided to you by Cisco.

Note the following:

  • Steps 1 – 3 can be done without affecting any existing setups.

  • Step 4 can be done before this setup if the UC-One SaaS or Connect client is not supported on the XSP; otherwise, it must be done during this setup (see Important note above about FCMv1 keys).

  • Step 5 must be done during this setup. It cannot be done beforehand.

  1. Set the CI OAuth client information as sent to you by Cisco:

    XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> get
    clientId = ******
    clientSecret = ******
    refreshToken = ******
  2. Set the UCaaS cloud URL. The staging FQDN is nps.stage.broadsoft.cloud, and production is is nps.uc-one.broadsoft.com.

    XSP_CLI/Applications/NotificationPushServer/CloudNPSService> get
    url = https://<ucaas_fqdn>/nps/
    VOIPTokenRefreshInterval = 1800
  3. Add the appropriate Android clients to FCM, depending on whether the service provider will be using the UC-One client, the Webex client, or both.

    Android UC-One/SAAS: com.broadsoft.connect
    Android WebEx Teams: com.cisco.wx2.android
    
    Example:
    XSP_CLI/Applications/NotificationPushServer/FCM/Applications> add com.cisco.wx2.android
    ...Done
  4. Enable the FCM v1 keys.

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
  5. Verify the Timers and Timeouts values are as shown below; if not, make the necessary changes.

    XSP_CLI/Applications/NotificationPushServer/FCM> get
    tokenTimeToLiveInSeconds = 3600
    connectionPoolSize = 10
    connectionTimeoutInMilliseconds = 3000
    connectionIdleTimeoutInSeconds = 600
  6. Verify the URLs are as listed:

    XSP_CLI/Applications/NotificationPushServer/FCM> get
    authURL = https://www.googleapis.com/oauth2/v4/token
    pushURL = https://fcm.googleapis.com/v1/projects/PROJECT-ID/messages:send
    scope = https://www.googleapis.com/auth/firebase.messaging
  7. For iOS, ensure the appropriate apps (UC-One and/or Webex Teams) do not have auth keys associated with them.

    iOS UC-One/SAAS: com.broadsoft.uc-one
    iOS WebEx Teams: com.cisco.squared
    
    
    XSP_CLI/Applications/NotificationPushServer/APNS/Production/Tokens> get
                                        App Id  Auth Key Id
    =======================================================
                             com.cisco.squared
         com.broadsoft.enterprise.uc-one-teams   D36WVNTQHD
                        com.cisco.webexcalling   CJYT2F4FXN
  8. Restart XSP by executing the bwrestart command, and test to verify functionality. If everything works correctly, the FCM/GCM API key for the SaaS Android app and the older APNS key for the SaaS iOS app can be removed from the box.

Google PUSH config for Webex for Broadworks FCMv1, and/or Migrating UC Legacy Apps to FCMv1

All legacy apps, such as Connect, must be migrated to FCM HTTPv1 (oauth) keys. Complete the following steps to migrate an existing FCM application on HTTP keys (basic auth) to HTTPv1.


These steps are not required for clients using just Webex for BroadWorks.

  1. Log in to the FCM Admin SDK at console.firebase.google.com

  2. Select the appopriate Android application.

  3. In the General tab, note the project ID.

  4. Select the Service Accounts tab.

    To create a new service account:

    1. To create a new service account, click Create New Service Account.

    2. Click Create a New Private Key.

    3. Download the key to a secure location.

    To update an existing service account:

    1. Click View Existing Service Accounts.

    2. Identify the service account to use, then in the menu on the right, select Create a New Private Key.

    3. Download the key to a secure location.

  5. Copy the key to the XSP.

  6. Configure the project ID and key:

    XSP_CLI/Applications/NotificationPushServer/FCM/Projects> add <project id> <path/to/key/file>
    ...Done
    
    
    XSP_CLI/Applications/NotificationPushServer/FCM/Projects> get
      Project ID  Accountkey
    ========================
      my_project    ********
  7. Configure the application:

    XSP_CLI/Applications/NotificationPushServer/FCM/Applications> add <app id> projectId <project id> ...Done XSP_CLI/Applications/NotificationPushServer/FCM/Applications> get Application ID Project ID ============================== my_app my_project
  8. Enable FCM HTTPv1:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  9. Restart XSP by executing the bwrestart command.

  10. If XSP also provides call PNs for UC-One SaaS, then validate and disable FCM HTTPv1 keys until the UC-One app is added later on this guide.

Connect SaaS Clients

If you were using GCM with your CNPS, then you need to reconfigure your CNPS to use FCM.

For more information, see the Communicator (Android) Migration to Firebase Method of Procedure at https://xchange.broadsoft.com/node/499312.

The GCM and FCM APIs are compatible. Complete the following steps:

  1. Set the FCM URL for your push notification messages. The old URL is https://gcm-http.googleapis.com/gcm/send and the new one is https://fcm.googleapis.com/fcm/send.

    You can change this by issuing the following command:

    XSP_CLI/Applications/NotificationPushServer/GCM> set url https://fcm.googleapis.com/fcm/send

  2. Restart the XSP.

Configure Your Partner Organization in Control Hub

Configure Your BroadWorks Clusters

[once per cluster]

This is done for the following reasons:

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

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

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


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

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

What you need to do:

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

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

  3. Click Add Cluster.

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

  4. Name this cluster and click Next.

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

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

  6. Add your CTI Interface URL and click Next.

  7. Add your Authentication Service URL.

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

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

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

Testing the Connections to Your BroadWorks Interfaces

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

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

  3. Click View Clusters.

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

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

    You should see green Success messages. If you see a red Error message, click the affected cluster name to see which setting is causing the problem. For example, if the connection to the Authentication Service failed, check that you correctly configured the XSPs for mTLS authentication and uploaded the Webex Certificate Chain to the trust store of the XSP interface.

Configure your Customer Templates

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

You can create as many templates as you need.

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

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

  3. Click Add Template.

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

  4. Use the dropdown, or start typing, to choose the cluster you want to use with this template.

  5. Enter a name for the template, then click Next.

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

    Table 1. Recommended Template Settings for Different Provisioning Modes

    Setting Name

    Flowthrough provisioning with trusted emails

    Flowthrough provisioning without emails

    User self-provisioning

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

    On

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

    On

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

    Off

    Automatically Create New Organizations in Control Hub

    On

    On

    On

    User Verification

    Trust Broadworks emails

    Untrusted Emails

    Untrusted Emails

    First user provisioned is admin

    Recommended*

    Recommended*

    Not applicable

    Allow users to self activate

    Not applicable

    Not applicable

    Required

    • Notes from the table:

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

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

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

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

  7. Enable BroadWorks Enterprise Mode if the customers you provision with this template are enterprises in BroadWorks. If they are groups, leave this switch off.

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

  8. Choose which country you use for this template.

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

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

  10. Select the default authentication mode (either BroadWorks Authentication or Webex Authentication) for customers using this template (see Authentication Mode in the Prepare your Environment section).

  11. Select your Service Provider Email Address from the dropdown (you can type some characters in a search box, to find the address if there is a long list).

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

  12. Choose whether you want the email address to be pre-filled on the login page.

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

  13. Enter a Service Provider Brand Name.

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

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

    You should see a success message.

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

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

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

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


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

Configure Application Server with Provisioning Service URL


This task is only required for flow through provisioning.

Patch Application Server

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

  2. Change to the Maintenance/ContainerOptions context.

  3. Enable the provisioning URL parameter:

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

Get the Provisioning URL(s) from Partner Hub

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

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

  2. Click View Templates.

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

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

  4. Copy the Provisioning Adapter URL.

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

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


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

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

    1. AS_CLI/Interface/Messaging> set provisioningUrl EnterValueFromPartnerHubTemplate

    2. AS_CLI/Interface/Messaging> set provisioningUserId EnterValueFromPartnerHubTemplate

    3. AS_CLI/Interface/Messaging> set provisioningPassword EnterValueFromPartnerHubTemplate

    4. AS_CLI/Interface/Messaging> set enableSynchronization true

  2. Activate the Integrated IMP interface:

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

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


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

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

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

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

  3. Select Use Messaging Server.

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


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

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

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

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

  8. Click Apply.

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

Customize and Provision Clients

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

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

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

Add Webex Teams Configuration Templates to BroadWorks Application Server

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

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

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

  3. For each client you're provisioning:

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

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

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

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

    5. Save the profile.

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

Name

Description

Codec Priority

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

TCP, UDP and TLS

Configure the protocols used for SIP signaling and media

RTP Audio and Video Ports

Configure port ranges for RTP audio and video

SIP options

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

Customize Clients in Control Hub

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

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

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

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


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

Customize Problem Reporting and Help URLs

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

Configure Your Test Organization for Webex for BroadWorks

Before you begin

With Flowthrough Provisioning

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

1

Assign Service in BroadWorks:

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

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

  3. Create test subscribers in that enterprise / group.

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

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


     

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

2

Verify Customer Organization and Users in Control Hub:

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

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

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

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

User Testing

1

Download the Webex Teams client on two different machines.

2

Sign in as your test users on the two machines.

3

Make test calls.

Water Mark
Oct 9, 2020| view(s) | people thought this was helpful

Managing Webex for BroadWorks

Managing Webex for BroadWorks

Provision Customer Organizations

In the current model, we automatically provision the customer organization when you onboard the first user through any of the methods described in this document. Provisioning happens only once for each customer.

Provision Users

You can provision users in these ways:

  • Use APIs

  • Assign Integrated IM&P (flowthrough provisioning)

Public Provisioning APIs

Cisco Webex will expose a set of public APIs to allow Service Providers to integrate Webex for BroadWorks subscriber provisioning into their existing provisioning workflows. As with all public APIs, we’ll make available the specification for these APIs on developer.webex.com to entitled developers. If you wish to develop with these APIs, contact your Cisco representative to gain access.

Flowthrough Provisioning

On BroadWorks, you can provision users with the Enable Integrated IM&P option. This action causes the BroadWorks provisioning adapter to make an API call to provision the user on Cisco Webex. Our provisioning API is backwards-compatible with the UC-One SaaS API. BroadWorks AS requires no code change, only a configuration change to the API endpoint for the provisioning adapter.


Subscriber provisioning on Cisco Webex can take considerable (several minutes for the initial user within an enterprise). Webex performs the provisioning as a background task. So, success on flowthrough provisioning indicates that the provisioning has started. It doesn't indicate completion.

To confirm that users and the customer organization are fully provisioned on Cisco Webex, you must sign in to Partner Hub and look in your Customers list.

For more information, see User Provisioning and Activation Flows.

Add / Edit / Delete Users

You can add, edit, or delete users as follows:

1

Assign the Integrated IM&P service in BroadWorks to add the users.

2

Modify the user package with the provisioning API to edit the users.

You currently can't modify a user package in Control Hub. Use different templates, and different provisioning URLs, to apply different packages to different Enterprises or Groups.

3

To remove the Webex license of a user, unassign the Integrated IM&P service in BroadWorks.

User ID and Email Address Changes

Email ID and Alternate ID are the BroadWorks user attributes used with Webex for BroadWorks. The BroadWorks User ID is still the primary identifier of the user in BroadWorks. The following table describes the purposes of these different attributes, and what to do if you need to change them:

Attribute in BroadWorks Corresponding Attribute in Webex Purpose Notes
BroadWorks User ID None Primary identifier You cannot change this identifier and still link the user to the same account in Webex. You can delete the user and recreate if it’s wrong.
Email ID User ID Mandatory for flow-through provisioning (creating Webex User ID) when you assert that you trust email

There is a manual process to change this in both places if provisioned with wrong email:

  1. Change user’s email address in Control Hub

  2. Change Email ID attribute in BroadWorks

Do not change the BroadWorks user id. This is not yet supported.

Alternate ID None Enables authn of user, by email and password, against BroadWorks User ID Should be the same as the Email ID. If You cannot put the email in the Alternate ID attribute, users will have to enter their BroadWorks User ID when authenticating.

Reconfigure the System

You can reconfigure the system as follows:

  • Add a BroadWorks Cluster in Partner Hub—

  • Edit or Delete a BroadWorks Cluster in Partner Hub

  • Add a Customer Template in Partner Hub—

  • Edit or Delete a Customer Template in Partner Hub

Edit or Delete a BroadWorks Cluster in Partner Hub

You can edit or remove a BroadWorks cluster in Partner Hub.

1

Sign in to Partner Hub with your partner admin credentials at https://admin.webex.com.

2

Go to Settings and find the BroadWorks Calling section.

3

Click View Clusters.

4

Click the cluster that you want to edit or delete.

The cluster details display in a flyout pane on the right.
5

You have these options:

  • Change any details you need to change, and then click Save.
  • Click Delete to remove the cluster, then confirm.

     

    If a template is associated with the cluster, you can’t delete a cluster. Delete the associated templates before you delete the cluster. See Edit or Delete a Customer Template in Partner Hub.

The cluster list updates with your changes.

Edit or Delete a Customer Template in Partner Hub

You can edit or delete customer templates in Partner Hub.

1

Sign in to Partner Hub with your partner admin credentials at https://admin.webex.com.

2

Go to Settings and find the BroadWorks Calling section.

3

Click View Templates.

4

Click the template that you want to edit or delete.

5

You have these options:

  • Edit any details that you need to change, and then click Save.
  • Click Delete to remove the template, then confirm.

Setting

Values

Notes

Provisioning account name / password

User-supplied strings

You do not need to re-enter the provisioning account details when editing a template. The empty password/password confirm fields are there to change the credentials if you need to, but leave them empty to keep the values you originally supplied.

Prefill user email address in login page

On/Off

It can take up to 7 hours for a change in this setting to take effect. That is, after you enable it, users may still need to enter their email addresses at the login screen.

The cluster list updates with your changes.

Increasing Capacity

XSP Farms

We recommend you use the capacity planner to determine how many additional XSP resources you need for the proposed increase in subscriber numbers. For either of the dedicated NPS or dedicated Webex for BroadWorks farms, you have the following scalability options:

  • Scale dedicated farm: Add one or more XSP servers to the farm that needs extra capacity. Install and activate the same set of applications and configurations as the farm’s existing nodes.

  • Add dedicated farm: Add a new, dedicated XSP farm. You’ll need to create a new cluster and new templates in Partner Hub, so you can start adding new customers on the new farm, to relieve pressure on existing farm.

  • Add specialized farm: If you are experiencing bottlenecks for a particular service, you may want to create a separate XSP farm for that purpose, taking into consideration the co-residency requirements listed in this document. You may need to reconfigure your Control Hub clusters and DNS entries if you change the URL of the service that has a new farm.

In all cases, the monitoring and resourcing of your BroadWorks environment is your responsibility. Should you wish to engage Cisco assistance, you can contact your account representative, who can arrange professional services.

Managing HTTP Server Certificates

You must manage these certificates for mTLS authenticated web applications on your XSPs:

  • Our chain of trust certificate from Cisco Webex cloud

  • Your XSP’s HTTP server interfaces’ certificates

Chain of Trust

You download the chain of trust certificate from Control Hub and install it on your XSPs during your initial configuration. We expect to update the certificate before it expires, and notify you of how and when to change it.

Your HTTP Server Interfaces

The XSP must present a publicly signed server certificate to Webex, as described in Order Certificates. A self-signed certificate is generated for the interface when you first secure the interface. This certificate is valid for one year from that date. You must replace the self-signed certificate with a publicly signed certificate. It’s your responsibility to request a new certificate before it expires.

Troubleshooting Webex for BroadWorks

Subscribe to the Webex Status Page

First check https://status.webex.com when you experience an unexpected interruption of service. If you haven't changed your configuration in Control Hub or BroadWorks before the interruption, check the status page. Read more about subscribing for status and incident notifications at Webex Help Center.

Use Control Hub Analytics

Webex tracks usage and quality data for your organization and your customer’s organizations. Read more about the Control Hub Analytics on Webex Help Center.

Network Issues

Customers or users are not being created in Control Hub with flowthrough provisioning:

  • Can the application server reach the provisioning URL?

  • Are the provisioning account and password correct, does that account exist in BroadWorks?

Clusters are consistently failing connectivity tests:


The mTLS connection to authentication service is expected to fail when you create the first cluster in Partner Hub, because you need to create the cluster to get access to the Webex certificate chain. Without that, you cannot create a trust anchor on the authentication service XSPs, so the test mTLS connection from Partner Hub is not successful.

  • Are the XSP interfaces publicly accessible?

  • Are you using the correct ports? You can enter a port in the interface definition on the cluster.

Interfaces Failing Validation

Xsi-Actions and Xsi-Events Interfaces:

  • Check that the interface URLs are correctly entered on the cluster in Partner Hub, including the /v2.0/ at the end of the URLs.
  • Check the firewall allows communication between Webex and these interfaces.

  • Review the interface configuration advice in this document.

Authentication Service Interface:

  • Check that the interface URLs are correctly entered on the cluster in Partner Hub, including the /v2.0/ at the end of the URLs.
  • Check the firewall allows communication between Webex and these interfaces.

  • Review the interface configuration advice in this document, with particular attention to:

    1. Make sure you shared RSA keys across all XSPs.
    2. Make sure you provided AuthService URL to the web container on all XSPs.
    3. If you edited the TLS cipher configuration, check that you used the correct naming convention. The XSP requires that you enter the IANA name format for the TLS ciphers. An earlier version of this document incorrectly listed the required cipher suites in the OpenSSL naming convention.

Client Issues

Verify the Client is Connected to BroadWorks

  1. Sign in to Webex Teams.

  2. Check that the Calling Options icon (a handset with a gear above it) is present on the sidebar.

    If the icon is not present, the user may not yet be enabled for the calling service in Control Hub.

  3. Open the Settings/Preferences menu and go to the Phone Services section. You should see the status SSO Session You're signed in.

    If a different phone service, such as Webex Calling, is shown, the user is not using Webex for BroadWorks.

This verification means:

  • The client has successfully transveresed the required Webex microservices.

  • The user has successfully authenticated.

  • The client has been issued a long-lived JSON web token by your BroadWorks system.

  • The client has retrieved its device profile and has registered to BroadWorks.

Client Logs

All Webex Teams clients can Send Logs to Webex. This is the best option for mobile clients. You should also record the user email address and approximate time the issue occurred if you are seeking assistance from TAC. For more information, see Where Do I Find Support for Cisco Webex Teams?

If you need to manually collect logs from a Windows PC, they are located as follows:

Windows PC: C:\Users\{username}\AppData\Local\CiscoSpark

Mac: /Users/{username}/Library/Logs/SparkMacDesktop

User Sign-In Issues

mTLS Auth Misconfigured

If all users are affected, check the mTLS connection from Webex to your Authentication Service URL:

  • Check that either the authentication service application, or the interface it uses, are configured for mTLS.

  • Check that the Webex certificate chain is installed as a trust anchor.

  • Check that the server certificate on the interface/application is valid, and signed by a well-known CA.

Known BroadWorks Misconfigurations

chainDepth too low

  • Conditions: You followed the procedure to copy the certificate chain to the XSP, and used it to create a trust anchor for validating Cisco Webex client connections. The XSP is running R21 SP1.

  • Symptom: In R21, XSP_CLI/Interface/HttpClientAuthentication/Trusts> get does not show all of the certificates that are expected in the issuer chain.

  • Cause: In R21 there is a chainDepth parameter which, if set too low, will prevent the whole certificate issuer chain from being added to the trust anchor.

  • Fix: /XSP_CLI/Interface/Http?ClientAuthentication> set chainDepth 3


    At the time of writing, the Webex client certificate chain has 2 intermediate issuers. Do not set this parameter below 2, especially if it is already higher. In the case that chainDepth is not below 2, these symptoms could indicate a corrupt chain file.

Support

Steady State Support Policy

The Service Provider is the first point of contact for the end customer (enterprise) support. Escalate issues that the SP can't resolve to TAC. BroadWorks server version support follows the BroadSoft policy of the current version and two previous major versions (N-2). Read more at https://xchange.broadsoft.com/php/xchange/support/maintenancesupport/softwaremaintenancepolicies/lifecyclepolicy/broadworksservers.

Escalation Policy

  • You (Service Provider/ Partner) are the first point of contact for end customer (enterprise) support.

  • Issues that cannot be resolved by the SP are escalated to TAC.

BroadWorks Versions

Self-Support Resources

  • Users can find support through the Webex Help Center, where there is a Webex for BroadWorks-specific page listing common Teams help and support topics.

  • Teams can be customized with this help URL and a problem report URL.

  • Teams users can send feedback or logs directly from the client. The logs go to the Webex cloud, where they can be analyzed by Cisco Webex DevOps.

  • We also have a Help Center page dedicated to administrator-level help for Webex for BroadWorks.

Collect Information for Submitting a Service Request

When you see errors in Control Hub, they might have attached information that can help TAC to investigate your problem. For example, if you see a tracking ID for a particular error, or an error code, save the text to share with us.

Try to include at least the following information when you’re submitting a query or opening a case:

  • Customer Organization ID and Partner Organization ID (each ID is a string of 32 hex digits, separated by hyphens)

  • TrackingID (also a 32 hex digit string) if the interface or error message provides one

  • User email address (if a particular user is experiencing issues)

  • Client versions (if the issue has symptoms noticed through the client)

Water Mark
Oct 9, 2020| view(s) | people thought this was helpful

Webex for BroadWorks Reference

Webex for BroadWorks Reference

UC-One SaaS Comparison with Webex for BroadWorks

Solution >

UC-One SaaS

Webex for BroadWorks

Cloud

Cisco UC-One Cloud (GCP)

Cisco Webex cloud (AWS)

Clients

UC-One: Mobile, Desktop

Receptionist, Supervisor

Teams: Mobile, Desktop, Web

Major Technology Difference

Meetings delivered on Broadsoft Meet Technology

Meetings delivered on Webex Meetings Technology

Early Field Trials

Staging environment, Beta clients

Production environment, GA clients

User identity

BroadWorks ID served as primary ID, unless Service Provider has SSO Integration already.

 

User ID and secret in BroadWorks

Email ID in Cisco CI serves as primary ID

SSO integration into Service Provider BroadWorks where User will authenticate with BroadWorks User ID and BroadWorks secret at time.

 

User supplies credentials via SSO with BroadWorks and secret in BroadWorks

OR

User ID and secret in CI IdP

OR

User ID in CI, ID and secrets in IdP

Client authentication

Users supply credentials through client

BroadWorks long-lived tokens required if using Teams messaging

Users supply credentials via browser (either login page from Webex BIdP proxy or CI)

Webex access and refresh tokens

Management / configuration

Your OSS/BSS systems and

Reseller portal

Your OSS/BSS systems and Control Hub

Partner/Service Provider activation

One time setup by Cisco Operations

One time setup by Cisco Operations

Customer/enterprise activation

Reseller portal

Control Hub

Auto-created upon first user enrollment

User activation options

Self-enrolled

Set external IM&P in BroadWorks

Set Integrated IM&P in BroadWorks (typically enterprises)

XSP service interfaces

XSI-Actions

 

XSI-Events

CTI (mTLS)

AuthService (mTLS optional)

DMS

XSI-Actions

XSI-Actions (mTLS)

XSI-Events

CTI (mTLS)

AuthService (mTLS required)

DMS

Install Webex Teams and Sign In (Subscriber Perspective)

1

Download and install Webex Teams. For details, see Webex Teams | Download the App.

2

Run Teams.

Teams prompts you for your email address.
3

Enter your email address and click Next.

4

One of the following happens, depending on the way your organization is configured in Webex:

  1. Teams launches a browser for you to complete authentication with your identity provider. This could be multi-factor authentication (MFA).

  2. Teams launches a browser for you to enter your BroadWorks user ID and password.

Teams loads after you successfully authenticate against the IdP or BroadWorks.

Data Exchange and Storage

These sections provide detail on data exchange and storage with Cisco Webex. All data is encrypted both in transit and at rest. For additional details, see Cisco Webex Teams App Security.

Service Provider Onboarding

When you configure clusters and user templates in Cisco Webex Control Hub during Service Provider onboarding, you exchange the following BroadWorks data which Webex stores:

  • Xsi-Actions URL

  • Xsi-Actions mTLS URL

  • Xsi-Events URL

  • CTI interface URL

  • Authentication service URL

  • BroadWorks Provisioning Adaptor credentials

Service Provider User Provisioning

This table lists user and enterprise data that is exchanged as part of user provisioning through the Webex APIs.

Data Moving to Webex

From

Through

Stored by Webex?

BroadWorks UserID

BroadWorks

Webex APIs

Yes

Email (if SP Provided)

BroadWorks

Webex APIs

Yes

Email (if User Provided)

User

User Activation Portal

Yes

First name

BroadWorks

Webex APIs

Yes

Last name

BroadWorks

Webex APIs

Yes

Primary Phone Number

BroadWorks

Webex APIs

Yes

Mobile Phone Number

BroadWorks

Webex APIs

No

Primary Extension

BroadWorks, by API

Webex APIs

No

BroadWorks Service Provider ID & Group ID

BroadWorks, by API

Webex APIs

Yes

Language

BroadWorks, by API

Webex APIs

Yes

Time zone

BroadWorks, by API

Webex APIs

Yes

User Removal

Webex for BroadWorks APIs support both partial and full user removal. This table lists all user data that is stored during provisioning and what is deleted in each scenario.

User Data

Partial Deletion

Full Deletion

BroadWorks UserID

Yes

Yes

Email

No

Yes

First name

No

Yes

Last name

No

Yes

Primary Phone Number

Yes

Yes

BroadWorks Service Provider ID & Group ID

Yes

Yes

Language

No

Yes

User Login and Configuration Retrieval

Webex Authentication

Webex authentication refers to user sign-in to a Webex Teams client by any of the Cisco Webex support authentication mechanisms. (BroadWorks authentication is covered separately.) This table illustrates the type of data exchanged between the different components on the authentication flow.

Data Moving

From

To

Email address

User through Teams client

Webex

Limited access token and (independent) IdP URL

Webex

User browser

User credentials

User browser

Identity provider (which already has user identity)

SAML assertion

User browser

Webex

Authentication code

Webex

User browser

Authentication code

User browser

Webex

Access and Refresh tokens

Webex

User browser

Access and Refresh tokens

User browser

Teams client

BroadWorks Authentication

BroadWorks authentication refers to user sign-in to a Webex Teams client using their BroadWorks credentials. This table illustrates the type of data exchanged between the different components on the authentication flow.

Data Moving

From

To

Email address

User through Teams client

Webex

Limited access token and (Webex Bwks IdP proxy) IdP URL

Webex

User browser

Branding information and BroadWorks URLs

Webex

User browser

BroadWorks user credentials

User through browser (branded sign-in page served by Webex)

Webex

BroadWorks user credentials

Webex

BroadWorks

BroadWorks user profile

BroadWorks

Webex

SAML assertion

User browser

Webex

Authentication code

Webex

User browser

Authentication code

User browser

Webex

Access and Refresh tokens

Webex

User browser

Access and Refresh tokens

User browser

Teams client

Client Configuration Retrieval

This table illustrates the type of data exchanged between the different components while retrieving client configurations.

Data Moving

From

To

Registration

Client

Webex

Organization settings, including BroadWorks URLs

Webex

Client

BroadWorks JWT token

BroadWorks through Webex

Client

BroadWorks JWT token

Client

BroadWorks

Device Token

BroadWorks

Client

Device Token

Client

BroadWorks

Config file

BroadWorks

Client

Steady State Usage

This section describes the data moving between components during re-authentication after token expiry, either through BroadWorks or Webex.

This table lists data movement for calling.

Data Moving

From

To

SIP signalling

Client

BroadWorks

SRTP media

Client

BroadWorks

SIP signalling

BroadWorks

Client

SRTP media

BroadWorks

Client

This table lists data movement for messaging, presence, and meetings.

Data Moving

From

To

HTTPS REST messaging and presence

Client

Webex

HTTPS REST messaging and presence

Webex

Client

SIP signalling

Client

Webex

SRTP media

Client

Webex

SIP signalling

Webex

Client

SRTP media

Webex

Client

Using the Provisioning API

The Webex for BroadWorks Provisioning API is for BroadWorks Service Providers (SPs) who sign up for Cisco Webex for BroadWorks. The API enables those SPs to provision, update, and remove Cisco Webex services for their subscribers.

Developer Access

The API specification is available on https://developer.webex.com to developers to whom we have explicitly given access. Contact your Cisco Administrator to gain access to these API specifications.

You need to sign in to read the API specification at https://developer.webex.com/docs/api/v1/broadworks-subscribers.

Application Authentication and Authorization

Your application integrates with Cisco Webex as an Integration. This mechanism allows the application to perform administrative tasks (such as subscriber provisioning) for an administrator within your Partner organization.

Cisco Webex APIs follow the OAuth 2 standard (http://oauth.net/2/). OAuth 2 allows third-party integrations to obtain refresh and access tokens on behalf of your chosen Partner administrator for authenticating API calls.

You must first register your integration with Cisco Webex. Once registered, your application must then support this OAuth 2.0 authorization grant flow to obtain the necessary refresh and access tokens.

For more details on integrations and how to build this OAuth 2 authorization flow into your application, see https://developer.webex.com/docs/integrations.


There are two required roles for implementing integrations - the developer and the authorizing user - and they may be held by separate people/teams in your environment.

  • The developer creates the app and registers it on https://developer.webex.com to generate the required OAuth ClientID/Secret with scopes expected for the application. If your application is being created by a third-party, they could register the application (if you have requested their access), or you could do it with your own access.

  • The authorizing user is the account that the application uses to authorize its API calls, to change your partner organization, your customers' organizations, or their subscribers. This account needs to have either the Full Administrator or Sales Full Administrator role in your partner organization. This account must not be held by a third party.

Methods and Content Types

The Webex for BroadWorks Provisioning API is RESTful. In REST, a base URL represents each resource. You use the HTTP methods GET, POST, PUT, and DELETE to request data and perform actions on those resources.

For methods that accept request parameters, the platform accepts only application/json content types.

API Errors

This API returns standard HTTP status codes for request responses. If an error occurs, the response body provides more information.

Backward Compatibility and Versioning

Our APIs change over time as we build new functionality. However, we are aware that API users need their applications to continue working as expected when the APIs change.

For that reason, our APIs follow a backward-compatibility and versioning strategy as follows:

When we add new API endpoints, new query parameters to existing endpoints, new optional fields in request bodies, and new data in response bodies, we do not necessarily create a new version of the API. Those kinds of changes should not affect the compatibility of the API with existing calls to the API, and we expect your applications to be robust to those kinds of improvements to the API.

When we need to change the API outside of the scope described above, we create a new version of the API. For example, if we added a new required field to the request body, your application would not be aware of that requirement. If we changed the original version, your application would experience an unexpected failure.

When we create a new version of an API, we continue to support the original version of the API for a reasonable period of time. This enables your application to continue working while you adapt it to using the new version of the API.

We have an API framework team that works across the Cisco collaboration portfolio to approve any API changes before they are rolled out, ensuring that our backwards compatibility requirements are met and avoiding unpleasant surprises for our developer community.

Important Implementation Notes

OAuth Scopes

When registering your application as an Integration on https://developer.webex.com, enable the following scopes to access all Webex for BroadWorks Provisioning APIs:

  • spark-admin:broadworks_subscribers_write

  • spark-admin:broadworks_subscribers_read

  • spark-admin:broadworks_enterprises_read

Asynchronous Provisioning Model

Subscriber provisioning on Cisco Webex can take considerable time. Therefore, the Webex for BroadWorks provisioning APIs don’t wait or block until subscriber is fully provisioned. Instead, the API responds quickly while initiating subscriber provisioning as a background task.

You can design your application to query the subscriber later to determine its provisioning status. All representations of the subscriber through the APIs include a “status” attribute to indicate the subscriber’s provisioning status:

  • On successful completion, the subscriber status changes to “provisioned”.

  • If any error occurs during provisioning, the user status transitions to “error”. The subscriber representation through these APIs also includes specific error codes and the reasons behind the provisioning error.

Enterprise ID

When provisioning a BroadWorks subscriber for Webex for BroadWorks, one of the required parameters is the spEnterpriseId. This parameter defines as a unique identifier for subscriber's enterprise on BroadWorks.

This table defines how to supply the spEnterpriseId value for your model:

Enterprise Configuration Model

Description

Logic

Example enterpriseID

Service Provider Model

Individual customers are configured as Groups under a Service Provider on BroadWorks.

The spEnterpriseId must be a concatenation of Service Provider ID and Group ID on BroadWorks, separated by a plus, as follows:

"<Service Provider ID>" + "+" + "<Group ID>"

“SP1+Acme"

Enterprise Model

Individual customers are configured as Enterprises on BroadWorks.

The spEnterpriseId must be an exact match of the Enterprise ID on BroadWorks:

"<Enterprise ID>"

“Acme”

Avoid Refresh Token Expiry

If a Refresh Token expires, then the application can no longer generate the necessary access tokens for this API. A Service Provider admin needs to reauthorize the application to gain access to the APIs again. So, it's important that your application maintains an active Refresh Token.

Generating a new access token automatically renews the lifetime of your Refresh Token. An application that regularly makes requests to this API also generates new access tokens. By its nature, the application also renews its Refresh Token lifetime. However, if the application becomes inactive for a long time, then the Refresh Token can expire. (Refresh token expiry is 60 days.) We recommend that your application runs a scheduled task/job that generates a new access token using the Refresh Token. This technique ensures that the Refresh Token doesn't expire, even during periods of inactivity.

Subscriber Deletion

Webex for APIs supports both a soft and hard deletion model for subscribers.

  • Soft Delete—The Webex for BroadWorks Subscriber Delete API removes all entitlements and capabilities from when the subscriber was first provisioned for Webex for BroadWorks. But, the subscriber remains provisioned within their Customer organization on Cisco Webex. The subscriber may continue to use Webex Teams in line with their remaining capabilities.

  • Hard Delete—If you wish to remove the subscriber completely from Cisco Webex, perform a DELETE with the People APIs as documented at https://developer.webex.com/docs/api/v1/people.

BroadWorks Software Requirements

See Lifecycle Management - BroadSoft Servers.

We expect the Service Provider to be on the current patch. The list of patches below is the minimum requirement for integrating with Webex.

Version 21 SP1 (Minimum supported version)

Server

Patches required

Application Server

AP.as.21.sp1.551.ap233913

AP.as.21.sp1.551.ap342028

AP.as.21.sp1.551.ap343504

AP.as.21.sp1.551.ap343572

AP.as.21.sp1.551.ap343670

AP.as.21.sp1.551.ap343760

AP.as.21.sp1.551.ap343918

AP.as.21.sp1.551.ap346337

AP.as.21.sp1.551.ap358508

AP.as.21.sp1.551.ap369763

Platform

AP.platform.21.sp1.551.ap233913

AP.platform.21.sp1.551.ap346337

AP.platform.21.sp1.551.ap347534

AP.platform.21.sp1.551.ap348531

AP.platform.21.sp1.551.ap355855

AP.platform.21.sp1.551.ap358508

AP.platform.21.sp1.551.ap364243

AP.platform.21.sp1.551.ap367732

AP.platform.21.sp1.551.ap361945

AP.platform.21.sp1.551.ap364239

Profile Server

AP.ps.21.sp1.551.ap233913

Execution Server

AP.xs.21.sp1.551.ap233913

XSP

AP.xsp.21.sp1.551.ap233913

AP.xsp.21.sp1.551.ap338964

AP.xsp.21.sp1.551.ap338965

AP.xsp.21.sp1.551.ap339087

AP.xsp.21.sp1.551.ap346337

AP.xsp.21.sp1.551.ap347534

AP.xsp.21.sp1.551.ap347879

AP.xsp.21.sp1.551.ap348531

AP.xsp.21.sp1.551.ap348574

AP.xsp.21.sp1.551.ap348987

AP.xsp.21.sp1.551.ap349230

AP.xsp.21.sp1.551.ap349443

AP.xsp.21.sp1.551.ap349923

AP.xsp.21.sp1.551.ap350396

AP.xsp.21.sp1.551.ap350524

AP.xsp.21.sp1.551.ap351040

AP.xsp.21.sp1.551.ap352340

AP.xsp.21.sp1.551.ap358508

AP.xsp.21.sp1.551.ap362075

Version 22

Server

Required Patches

Application Server

AP.as.22.0.1123.ap364260

AP.as.22.0.1123.ap365173

AP.as.22.0.1123.ap369763

AP.as.22.0.1123.ap372989

AP.as.22.0.1123.ap372757

Profile Server

AP.ps.22.0.1123.ap372989

AP.ps.22.0.1123.ap372757

Platform

AP.platform.22.0.1123.ap353577

AP.platform.22.0.1123.ap354313

AP.platform.22.0.1123.ap365173

AP.platform.22.0.1123.ap367732

AP.platform.22.0.1123.ap369433

AP.platform.22.0.1123.ap369607

AP.platform.22.0.1123.ap372757

XSP

AP.xsp.22.0.1123.ap354313

AP.xsp.22.0.1123.ap365173

AP.xsp.22.0.1123.ap368067

AP.xsp.22.0.1123.ap370952

AP.xsp.22.0.1123.ap369607

AP.xsp.22.0.1123.ap373008

AP.xsp.22.0.1123.ap372757

AP.xsp.22.0.1123.ap372433

AP.xsp.22.0.1123.ap374677

AP.xsp.22.0.1123.ap375206

Other

AP.xsa.22.0.1123.ap372757

AP.xs.22.0.1123.ap372757

Version 23

Server

Required Patches

Application Server

AP.as.23.0.1075.ap369763

Platform

AP.platform.23.0.1075.ap367732

AP.platform.23.0.1075.ap370952

AP.platform.23.0.1075.ap369607

XSP

AP.xsp.23.0.1075.ap368067

AP.xsp.23.0.1075.ap370952

AP.xsp.23.0.1075.ap369607

AP.xsp.23.0.1075.ap373008

AP.xsp.23.0.1075.ap374677

AP.xsp.23.0.1075.ap375206

BroadWorks Tags Required for Webex Teams

System Tags

System Tag

Description

%BWNETWORK-CONFERENCESIPURI-1%

This is the server URI used to enable N-Way conferencing.

%BWVOICE-PORTAL-NUMBER-1%

This number is used for voice mail. The client dials this number when retrieving voice mail.

%BWLINEPORT-1%

SIP username used in SIP signaling, for example, in registration.

%BWAUTHPASSWORD-1%

SIP password used in SIP signaling.

%BWHOST-1%

Typically used as the SIP domain.

%BWAUTHUSER-1%

SIP username typically used in 401 and 407 signaling. Can be different from the default SIP username.

%BWE164-1%

This tag provides the user’s phone number in international format.

Custom Tags

Tag

Desktop

Mobile

Default

%ENABLE_CALL_STATISTICS_WXT%

Y

Y

FALSE

%ENABLE_CALL_PULL_WXT%

Y

Y

FALSE

%PN_FOR_CALLS_CONNECT_SIP_ON_ACCEPT_WXT%

N

Y

FALSE

%PN_FOR_CALLS_USE_REGISTRATION_V1_WXT%

N

Y

FALSE

%ENABLE_MWI_WXT%

Y

Y

FALSE

%MWI_MODE_WXT%

Y

Y

empty

%ENABLE_VOICE_MAIL_WXT%

Y

Y

FALSE

%ENABLE_VISUAL_VOICE_MAIL_WXT%

Y

Y

FALSE

%ENABLE_FORCED_LOGOUT_WXT%

Y

N

FALSE

%FORCED_LOGOUT_APPID_WXT%

Y

N

empty

%ENABLE_CALL_FORWARDING_ALWAYS_WXT%

Y

Y

FALSE

%ENABLE_BROADWORKS_ANYWHERE_WXT%

Y

Y

FALSE

%ENABLE_BROADWORKS_ANYWHERE_ALERT_ALL_LOCATIONS_WXT%

Y

Y

FALSE

%BROADWORKS_ANYWHERE_ALERT_ALL_LOCATIONS_DEFAULT_WXT%

Y

Y

FALSE

%ENABLE_BROADWORKS_ANYWHERE_DESCRIPTION_WXT%

Y

Y

TRUE

%ENABLE_BROADWORKS_ANYWHERE_CALL_CONTROL_WXT%

Y

Y

FALSE

%BROADWORKS_ANYWHERE_CALL_CONTROL_DEFAULT_WXT%

Y

Y

FALSE

%ENABLE_BROADWORKS_ANYWHERE_DIVERSION_INHIBITOR_WXT%

Y

Y

FALSE

%BROADWORKS_ANYWHERE_DIVERSION_INHIBITOR_DEFAULT_WXT%

Y

Y

FALSE

%ENABLE_BROADWORKS_ANYWHERE_ANSWER_CONFIRMATION_WXT%

Y

Y

FALSE

%BROADWORKS_ANYWHERE_ANSWER_CONFIRMATION_DEFAULT_WXT%

Y

Y

FALSE

%SETTINGS_PORTAL_URL_WXT%

Y

Y

empty

%ENABLE_EMERGENCY_DIALING_WXT%

N

Y

FALSE

%EMERGENCY_DIALING_NUMBERS_WXT%

N

Y

911,112

%ENABLE_USE_RPORT_WXT%

Y

Y

FALSE

%RPORT_USE_LOCAL_PORT_WXT%

Y

Y

FALSE

%USE_TLS_WXT%

Y

Y

FALSE

%SBC_ADDRESS_WXT%

Y

Y

empty

%SBC_PORT_WXT%

Y

Y

5060

%USE_PROXY_DISCOVERY_WXT%

Y

Y

FALSE

%USE_TCP_FROM_DNS_WXT%

Y

Y

TRUE

%USE_UDP_FROM_DNS_WXT%

Y

Y

TRUE

%USE_TLS_FROM_DNS_WXT%

Y

Y

TRUE

%DOMAIN_OVERRIDE_WXT%

Y

Y

empty

%SOURCE_PORT_WXT%

Y

Y

5060

%USE_ALTERNATIVE_IDENTITIES_WXT%

Y

Y

FALSE

%TCP_SIZE_THRESHOLD_WXT%

Y

Y

18000

%SIP_REFRESH_ON_TTL_WXT%

Y

Y

FALSE

%ENABLE_SIP_UPDATE_SUPPORT_WXT%

Y

Y

FALSE

%ENABLE_PEM_SUPPORT_WXT%

Y

Y

FALSE

%ENABLE_SIP_SESSION_ID_WXT%

Y

Y

FALSE

%ENABLE_FORCE_SIP_INFO_FIR_WXT%

Y

Y

FALSE

%SRTP_ENABLED_WXT%

Y

Y

FALSE

%SRTP_MODE_WXT%

Y

Y

FALSE

%ENABLE_REKEYING_WXT%

Y

Y

TRUE

%RTP_AUDIO_PORT_RANGE_START_WXT%

Y

Y

8000

%RTP_AUDIO_PORT_RANGE_END_WXT%

Y

Y

8099

%RTP_VIDEO_PORT_RANGE_START_WXT%

Y

Y

8100

%RTP_VIDEO_PORT_RANGE_END_WXT%

Y

Y

8199

%ENABLE_RTCP_MUX_WXT%

Y

Y

TRUE

%ENABLE_XSI_EVENT_CHANNEL_WXT%

Y

Y

TRUE

%CHANNEL_HEARTBEAT_WXT%

Y

Y

10000

User Provisioning and Activation Flows


Provisioning describes adding the user to Webex. Activation includes email validation and service assignment in Webex.

Users email addresses must be unique as Webex uses the email address to identify a user. If you have trusted email addresses for the users, you can choose to have them automatically activated when you automatically provision them. This process is “automatic provisioning and automatic activation”.

Automated User Provisioning and Automatic Activation (Trusted Email Flow)

Prerequisites

  • Your provisioning adapter points to Webex for BroadWorks (which requires an outbound connection from AS to Webex Provisioning Bridge).

  • You must have valid reachable end-user email addresses as alternate IDs in BroadWorks.

  • Control Hub has a provisioning account in your partner organization configuration.

Figure 1.

This image is not available in preview/cisco.com

Step

Description

1

You quote and take orders for the service with your customers.

2

You process the customer order and provision the customer in your systems.

3

The service provisioning system triggers the provisioning of BroadWorks. This step, in summary, creates the enterprise and the users. It then assigns the necessary services and numbers to each user. One of those services is the external IM&P.

4

This provisioning step triggers the automatic provisioning of the customer organization and users in Cisco Webex. (The IM&P service assignment causes the provisioning adapter to call the Webex provisioning API).

5

Your systems need to use the Webex provisioning API if you later need to adjust the package for the user (to change from the default).

User Interactions

Sign In

Figure 2.
  1. The Webex Teams client launches a browser to Cisco Common Identity (CI) to allow users to enter their email address.

  2. CI discovers that the associated customer org has the BroadWorks IDP Proxy (IDP) configured as their SAML IDP. CI redirects to the IDP which presents the user with a sign-in page. (The Service Provider can brand this sign-in page.)

  3. The user enters their BroadWorks credentials.

  4. Broadworks authenticates the user through the IDP. On success, the IDP redirects the browser back to CI with a SAML Success to complete the authentication flow (not shown in diagram).

  5. On successful authentication, the Webex Teams client obtains access tokens from CI (not shown in diagram). The client uses them to request a BroadWorks long-lived Jason Web Token (JWT).

  6. Teams discovers its calling configuration from BroadWorks and other services from Webex.

  7. Teams registers with BroadWorks.

Sign In from a User Perspective

This diagram is the typical sign-in flow, as seen by the end user or subscriber:

Figure 3.
  1. You download and install the Webex Teams client.

  2. You may have received the link from your service provider, or you can find the download on Cisco Webex downloads page.

  3. You enter your email address at the Teams sign-in screen. Click Next.

  4. Typically, you’re redirected to a Service Provider branded page.

  5. That page may welcome you by your email address.

    If there’s no email address, or if the email address is wrong, enter your BroadWorks user name instead.

  6. Enter your BroadWorks password.

  7. Teams opens if you signed in successfully.

Call Flow—Corporate Directory

Figure 4.

Call Flow—PSTN Number

Figure 5.

Presentation and Sharing

Figure 6.

Start a Space Meeting

Figure 7.

Client Interactions

Retrieve Profile from DMS and SIP Register with AS

  1. Client calls XSI to get a device management token and the URL to the DMS.

  2. Client requests its device profile from DMS by presenting the token from step 1.

  3. Client reads the device profile and retrieves the SIP credentials, addresses, and ports.

  4. Client sends a SIP REGISTER to SBC using the information from step 3.

  5. SBC sends the SIP REGISTER to the AS (SBC may perform a look-up in the NS to locate an AS if SBC does not already know the SIP user.)

Terminology

ACL
Access Control List
ALG
Application Layer Gateway
API
Application Programming Interface
APNS
Apple Push Notification Service
AS
Application Server
ATA
Analog Telephone Adapter, adapter that converts analog telephony to VoIP
BAM
BroadSoft Application Manager
Basic authentication
A method of authentication where an account (username) is validated by a shared secret (password)
BMS
BroadSoft Messaging Server
BOSH
Bidirectional-streams Over Synchronous HTTP
BRI
Basic Rate Interface BRI is an ISDN access method
Bundle
A collection of services as delivered to an end user or subscriber (cf. Package)
CA
Certification Authority
Carrier
An organization that handles telephony traffic (cf. Partner, Service Provider, Value Added Reseller)
CAPTCHA
Completely Automated Public Turing test to tell Computers and Humans Apart
CCXML
Call Control eXtensible Markup Language
CIF
Common Intermediate Format
CLI
Command Line Interface
CN
Common Name
CNPS
Call Notifications Push Server. A Notification Push Server that runs on an XSP in your environment, to push call notifications to FCM and APNS. See NPS Proxy.
CPE
Customer Premises Equipment
CPR
Custom Presence Rule
CSS
Cascading Style Sheet
CSV
Comma-Separated Value
CTI
Computer Telephony Integration
CUBE
Cisco Unified Border Element
DMZ
Demilitarized Zone
DN
Directory Number
DND
Do Not Disturb
DNS
Domain Name System
DPG
Dial Peer Group
DSCP
Differentiated Services Code Point
DTAF
Device Type Archive File
DTG
Destination Trunk Group
DTMF
Dual-Tone Multi-Frequency
End user
The person who is using the services, that is making calls, joining meetings, or sending messages (cf. Subscriber)
Enterprise
A collection of end users (cf. Organization)
FCM
Firebase Cloud Messaging
FMC
Fixed Mobile Convergence
Flow-through provisioning
Creating users in the Webex identity store by assigning the “Integrated IM&P” service in BroadWorks.
FQDN
Fully Qualified Domain Name
Full flow-through provisioning
Creating and verifying users in the Webex identity store by assigning the “Integrated IM&P” service in BroadWorks and asserting that each BroadWorks user has a unique and valid email address.
FXO
Foreign Exchange Office is the port that receives the analog line. It is the plug on the phone or fax machine or the plugs on your analog phone system. It delivers an on-hook/off-hook indication (loop closure). Since the FXO port is attached to a device, such as a fax or a phone, the device is often called the “FXO device”.
FXS
Foreign Exchange Subscriber is the port that actually delivers the analog line to the subscriber. In other words, it is the "plug in the wall" that delivers a dial tone, battery current, and ring voltage.
GCM
Google Cloud Message
GCM
Galois/Counter Mode (encryption technology)
HID
Human Interface Device
HTTPS
Hypertext Transfer Protocol Secure Sockets
IAD
Integrated Access Device
IM&P
Instant Messaging and Presence
IP PSTN
A service provider that provides VoIP to PSTN services, interchangeable with ITSP, or a general term for internet-connected 'public' telephony, collectively provided by major telecomms providers (rather than by countries, as PSTN is)
ITSP
Internet Telephony Service Provider
IVR
Interactive Voice Response / Responder
JID
The native address of an XMPP entity is called a Jabber Identifier or JID localpart@domain.part.example.com/resourcepart (@ . / are separators)
JSON
Java Script Object Notation
JSSE
Java Secure Socket Extension; the underlying technology providing secure connectivity features to BroadWorks servers
KEM
Key Extension Module (hardware Cisco phones)
LLT
Long-lived (or Long Life) Token; a self-describing, secure form of bearer token that enables users to remain authenticated for longer, and is not tied to specific applications.
MA
Message Archival
MIB
Management Information Base
MS
Media Server
mTLS
Mutual authentication between two parties, using certificate exchange, when establishing a TLS connection
MUC
Multi-User Chat
NAT
Network Address Translations
NPS
Notification Push Server; see CNPS
NPS Proxy

A service in Cisco Webex that supplies short-lived authorization tokens to your CNPS, enabling it to push call notifications to FCM and APNs, and ultimately to Android and iOS devices running Webex Teams.

OCI
Open Client Interface
Organization
A company or organization representing a collection of end users (cf. Enterprise)
OTG
Outgoing Trunk Group
Package
A collection of services as delivered to an end user or subscriber (cf. Bundle)
Partner
An agent organization that works with Cisco to distribute products and services to other organizations (cf. Value Added Reseller, Service Provider, Carrier)
PBX
Private Branch Exchange
PEM
Privacy Enhanced Mail
PLMN
Public Land Mobile Network
PRI
Primary Rate Interface (PRI) is a telecommunications interface standard used on an Integrated Services Digital Network (ISDN)
PS
Profile Server
PSTN
Public Switched Telephone Network
QoS
Quality of Service
Reseller portal
A web site that enables the reseller’s administrator to configure their UC-One SaaS solution. It is sometimes referred to as BAM portal, admin portal, or management portal.
RTCP
Real-Time Control Protocol
RTP
Real-Time Transport Protocol
SBC
Session Border Controller
SCA
Shared Call Appearance
SD
Standard Definition
SDP
Session Description Protocol
SP
Service Provider; An organization that provides telephony or related services to other organizations (cf. Carrier, Partner, Value Added Reseller)
SIP
Session Initiation Protocol
SLT
Short-lived (or Short Life) Token (also called BroadWorks SSO Token); a single-use authenticated token that is used to gain secure access to web applications.
SMB
Small to Medium Business
SNMP
Simple Network Management Protocol
sRTCP
secure Realtime Transfer Control Protocol (VoIP call media)
sRTP
secure Realtime Transfer Protocol (VoIP call media)
SSL
Secure Sockets Layer
Subscriber
The person who is using the services, that is making calls, joining meetings, or sending messages (cf. End user)
TCP
Transmission Control Protocol
TDM
Time Division Multiplexing
TLS
Transport Layer Security
ToS
Type of Service
UAP
User Activation Portal
UC
Unified Communications
UI
User Interface
UID
Unique Identifier
UMS
Messaging Server
URI
Uniform Resource Identifier
URL
Uniform Resource Locator
USS
Sharing Server
UTC
Coordinated Universal Time
UVS
Video Server
Value Added Reseller (VAR)
An agent organization that works with Cisco to distribute products and services to other organizations (cf. Carrier, Partner, Service Provider)
VGA
Video Graphics Array
VoIP
Voice over Internet Protocol (IP)
VXML
Voice Extensible Markup Language
WebDAV
Web Distributed Authoring and Versioning
WebRTC
Web Real-Time Communications
WRS
WebRTC Server
XMPP
Extensible Messaging and Presence Protocol

Was this article helpful?

Related Articles

Recently Viewed

×