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.

For enterprises that expect use cases like hosting Events or Training (beyond 200 participants), we expect partners to consider Enterprise Webex Meetings packages. Webex for BroadWorks doesn’t serve use cases that require higher capacities.

Prerequisites for Success with Webex for BroadWorks

#

Requirement

Notes

1

Patch Current BroadWorks 21SP1 or above

Recommend R22, since R21 is EOL in June 2021

2

Public facing XSP for XSI, DMS, NPS

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

3

XSP with mTLS configured for Webex connections to the Authentication Service

Dedicated XSP

4

XSP without mTLS for XSI Actions

Shared XSP

5

Email attribute of BroadWorks user must contain a valid email address, unique to that user.

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

10

If you want to use Flow Through provisioning, the Application Server must connect out to the BroadWorks Provisioning Adapter

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 Control Hub to connect Webex to BroadWorks. (See Deploy Webex for BroadWorks > Configure your Partner Organization in Control Hub in this document.)

  4. Use Control 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.

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.

"Premium" Package

This package includes everything in the Standard package plus up to 200 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

(with BYOPSTN)

Premium

Included

Included

25 participants

200 participants

(with BYOPSTN)

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.

    There’s currently no method in Control Hub to change the package granted to an individual subscriber, or group of subscribers. The package is assigned during provisioning, so we recommend using different templates to assign different packages.

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

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

Once you have your Control 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 Control Hub (Cluster)

3

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

4

Preparing BroadWorks environment for Integration (AS, XSP Patching, firewalls, XSP configuration, XSI, AuthService, NPS, DM 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.

  • Control Hub is a web interface for administering your Webex organization and your customers’ organizations. Control Hub is where you configure the integration between your BroadWorks infrastructure and Cisco Webex. You also use Control 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), and Authentication Service for phones and Webex Teams clients to authenticate themselves, download their calling configuration files, and make and receive calls.

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

    • Used by partner administrator to activate users for Webex for BroadWorks

    • Pushes user profile into BroadWorks

    • Provisions users in Webex, if you choose flow-through provisioning

  • 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

Third-party components are represented at the base of 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:

  • 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

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

Supply URLs for these interfaces when you configure Webex for BroadWorks. (See Configure your BroadWorks Clusters in Control 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.

Recommended XSP Architecture

This diagram illustrates the recommended XSP Architecture in support of Webex for BroadWorks.

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:

  • XSI-Actions (TLS)

  • XSI-Events (TLS)

  • AuthService (mTLS)

  • DMS (TLS)

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

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

  • Two XSP instances or farms, one with an mTLS interface for AuthService only and the other with a TLS interface for other apps


Even if you deploy Auth Service on a dedicated XSP instance or farm for Webex mTLS access, we recommend that you continue to run an Auth Service coresident with the other required applications. This deployment allows those apps verify any long-lived tokens that they receive.

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 on 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 Control 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 these user/subscriber provisioning models:

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

    • Flowthrough Provisioning:

      By configuring the Integrated IM&P service to use a Webex provisioning URL, you can automatically provision users in Webex by assigning that service to them in BroadWorks.

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.