Water Mark
Apr 9, 2021 | view(s) | people thought this was helpful

Webex for BroadWorks Solution Guide

This guide is aimed at partner-level administrators that deploy the Webex for BroadWorks solution.

Overview of Webex for BroadWorks

Overview of Webex for BroadWorks

Document Change History

Date

Change

Section

April 09, 2021

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

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

  • Updated Before You Begin requirements for Directory Synchronisation

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

  • Updated Appendix to clarify Authentication Service mTLS procedure requirements

  • Added Note on reusing XSP servers to Architecture

April 01, 2021

Updated Features and Limitations with following updates:

  • Updated Space Meetings limits for Premium package to 200.

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

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

March 25, 2021

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

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

March 17, 2021

  • Updated Features and Limitations with information on App Integration

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

March 03, 2021

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

March 02, 2021

  • Added Messaging Limits for Webex for BroadWorks topic.

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

February 23, 2021

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

  • Fixed missing images in User Interactions topic.

  • Added IdP Proxy URLs to Install Authentication Service.

February 10, 2021

  • Added procedure topic Migrate NPS to FCMv1.

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

February 05, 2021

  • Added Call Recording and Group Call Pickup and Retrieve features

  • Added Softphone Package to the list of packages

  • Updated TLS references to Authentication Service using CI Token Validation

January 29, 2021

  • Updated links in Architecture & Infrastructure topic

  • Added Limitation around VDI support

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

January 27, 2021

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

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

January 22, 2021

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

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

January 12, 2021

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

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

Dec 18, 2020

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

  • Moved the pre-existing procedure to the Appendix.

Dec 15, 2020

Added Directory Synchronisation for BroadWorks Calling.

Dec 08, 2020

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

Nov 12, 2020

  • User Provisioning and Activation Flows, User Interactions:

    Fixed broken image references.

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

    Fixed inconsistent table formatting.

DNS Configuration

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

Configure Call Push Notifications in Webex for BroadWorks

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

  • Removed NPS migration advice to an external article.

  • Add Webex apps to AS allow list.

  • Clarify commands to create CI account for NPS proxy.

October 29, 2020

Managing Users

  • Added procedure to edit user package in Partner Hub.

  • Added procedure to provision users by self-activation.

  • Added options for deleting users.

Using the Provisioning API

  • Added API Responsebody definition

  • Added API error codes

Deploy Webex for BroadWorks

Added Call Settings Webview

Additional Certificate Requirements for Mutual TLS Authentication over CTI Interface

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

October 9, 2020

Using the Provisioning API

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

Added API backward compatibility and versioning strategy.

EMEA Egress Rules

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

Configure your NPS to Work with the NPS Proxy

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

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

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

Configure Services on your Webex for BroadWorks XSPs.

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

Features and Limitations

Participant limits and dial-in option updated.

Configure Your BroadWorks Clusters

Added note about not saving invalid clusters.

Configure Application Server with Provisioning Service URL

Removed irrelevant section about creating a new administrator on BroadWorks.

October 2020

Document updated with new features.

  • CTI Interface and Related Configuration added.

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

  • NPS proxy IP ranges added to Egress rules.

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

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

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

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

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

September 2020

Configure your NPS to Work with the NPS Proxy

Corrected NPS authentication proxy URL

August 2020

  • XSP Identity and Security Requirements

    Corrected cipher suite names to IANA convention

  • Configure Services on Your Webex for BroadWorks XSPs

    Corrected the XSP mTLS trust anchor procedure

July 2020

First Publishing

Introducing Webex for BroadWorks

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

Solution Purpose

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

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

Context

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

Benefits

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

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

Solution Scope

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

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

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

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

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

Prerequisites for Success with Webex for BroadWorks

#

Requirement

Notes

1

Patch Current BroadWorks 21SP1 or above

Recommend R22 or later

2

XSP for XSI, CTI, DMS, and authService

Dedicated XSP for Webex for BroadWorks

3

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

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

4

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

5

mTLS configured for Webex connections to the CTI interface.

Other applications do not require mTLS.

6

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

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

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

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

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

7

Webex for BroadWorks DTAF file for Webex Client

8

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.

9

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

See the “Prepare your Network” section.

10

TLS v1.2 Configuration on XSPs

11

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


 

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

See the “Prepare your Network” topic.

About this Document

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

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

The minimum set of tasks to deploy the solution are:

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

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

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

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

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


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

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

Terminology

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

How it Works

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

  • Users call PSTN numbers using your BroadWorks infrastructure.

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

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

  • Users can host and join Cisco Webex Meetings.

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

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

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

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

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

  • Users authenticate against BroadWorks or against Cisco Webex.

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

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

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

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

The client registers to your BroadWorks systems for calling features.

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

Features and Limitations

We offer several packages with different features.

"Softphone" Package

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

Softphone users can share their screen while in a call.

"Basic" Package

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

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

"Standard" Package

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

Screen sharing within a PMR meeting is a role initially held only by the host of the meeting, but the host may pass the ‘presenter role’ to any meeting participant they choose, and only the host may re-take the presenter role without the current host passing it to them.

"Premium" Package

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

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

Compare Packages

Package

Calling

Messaging

Space Meetings

PMR Meetings

Softphone

Included

Not Included

None

None

Basic

Included

Included

25 participants

None

Standard

Included

Included

25 participants

25 participants

Premium

Included

Included

200 participants

1000 participants

Messaging and Meeting Features

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

Table 1. Feature Support Differences for PMR Meetings

Meeting Feature

Suported with Standard Package

Supported with Preminum Package

Comment

Meeting Duration

Unlimited

Unlimited

Desktop Sharing

Yes

Yes

Standard —Desktop sharing by PMR meeting host only.

Premium—Desktop sharing by any PMR meeting participant.

Application Sharing

Yes

Yes

Standard —Application sharing by PMR meeting host only.

Premium—Application sharing by any PMR meeting participant.

Multi-party Chat

Yes

Yes

Whiteboarding

Yes

Yes

Password Protection

Yes

Yes

Web app - no downloading or plugins (Guest Experience)

Yes

Yes

Support pairing with Cisco Webex Devices

Yes

Yes

Floor control (Mute One / Expel All)

Yes

Yes

Persistent Meetings link

Yes

Yes

Meetings Site Acces

Yes

Yes

Meeting Join via VoIP

Yes

Yes

Locking

Yes

Yes

Presenter Controls

No

Yes

Remote Destktop Control

No

Yes

Number of participants

25

1000

Recording saved locally in the system

No

Yes

Recording in the cloud

No

Yes

Recording - Cloud Storage

No

10GB

Recording transcriptions

No

Yes

Meeting Scheduling

Yes

Yes

Enable Content sharing with External Integrations

No

Yes

Standard—Content sharing by PMR meeting host only.

Premium—Content sharing by any PMR meeting participant.

Allow PMR URL change

No

Yes

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

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

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

No

Yes

Let other users to schedule meetings on their behalf

No

Yes

Add alternate host

No

Yes

App Integration (e.g. Zendesk, Slack)

Depends on the integration

Yes

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

Integration with Microsoft Office 365 Calendaring

Yes

Yes

Integration with Google Calendaring for G Suite

Yes

Yes

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

Calling Features

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

App Integrations

You can integrate Webex for BroadWorks with the following applications:

Future Roadmap

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

Limitations

Provisioning Limitations

Meetings Site Timezone

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

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

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

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

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

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

General Limitations

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

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

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

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

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

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

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

Messaging Limits

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

  • Basic: 2 GB per user for 3 years

  • Standard 5 GB per user for 3 years

  • Premium: 10 GB per user for 5 years

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

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

Additional Information

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

Security, Data, and Roles

Cisco Webex Security

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

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

Additional Reading

Organization Data Residency

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

Roles

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

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

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

#

Typical Task

SP

Cisco

1

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

2

BroadWorks Configuration in Partner Org via Partner Hub (Cluster)

3

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

4

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

5

Develop Provisioning Integration or Process

6

Prepare GTM Materials

7

Migrate or Provision New Users

Architecture

What's in the Diagram?

Clients

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

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

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

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

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

Service Provider Network

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

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

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

    • Publishes directory to Webex clients.

  • Public-facing XSP, running NPS:

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

  • Application Server:

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

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

    • Pushes user profile into BroadWorks

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

Cisco Webex Cloud

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

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

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

    • User Provisioning APIs

    • Service Provider Configuration

    • User Login using BroadWorks credentials

  • Webex Messaging box for messaging-related microservices.

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

Third-Party Web Services

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

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

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

XSP Architecture Considerations

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

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

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

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

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

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

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

XSP Architecture Requirements

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

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

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

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

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

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

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

  • AuthService (TLS with CI Token Validation or mTLS)

  • CTI (mTLS)

  • XSI-Actions (TLS)

  • XSI-Events (TLS)

  • DMS (TLS)

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

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

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


XSP Reuse

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

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

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

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

Configure NTP Synchronization on XSP

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

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

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

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

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

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

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

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

Required Patches with Flow-through Provisioning

If you are using flow-through provisioning, you must install and activate the patch that applies to your BroadWorks release:

  • For R21: AP.as.21.sp1.551.ap375094

  • For R22: AP.as.22.0.1123.ap376508

  • For R23: AP.as.23.0.1075.ap376509

  • For R24: AP.as.24.0.944.ap375100

Provisioning Extension-Only Users

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

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

Migration and Future-proofing

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

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

Water Mark
Apr 9, 2021| 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? Webex app 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, or Softphone.

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/1051462) and the Cisco BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/1051496).

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

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, but when you onboard a customer it is associated with only one template (you cannot apply multiple templates to one customer).

Some of the primary template 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 adapters, 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 apps 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 apps.

Client Name

Device Profile Type and Package name

Webex Mobile Template

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

Identity/Device Profile Type: Connect - Mobile

DTAF: ucone-mobile-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Config file: config-wxt.xml

Webex Tablet Template

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

Identity/Device Profile Type: Connect - Tablet

DTAF: ucone-tablet-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Config file: config-wxt.xml

Webex Desktop Template

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

Identity/Device Profile Type: Business Communicator - PC

DTAF: ucone-desktop-ucaas-X.X.XX-wxt-MonthYear_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 the Webex app 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 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

(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

    The CN of the internal certificate must be bwcticlient.webex.com.


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

    • Public certificate authorities may not be willing to sign certificates with the proprietary BroadWorks OID that is required. In the case of a bridging proxy, you may be forced to use an internal CA to sign the client certificate that the proxy presents to the XSP.

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

The firewall requirements for the normal functioning of the client application 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 the Webex app 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 App

Xsi/DMS

Any

HTTPS

Your XSP

443

Webex app VoIP endpoints SIP

Any

SIP

Your SBC

SP-defined protocol and port

TCP/UDP


It is strongly advisable for the SIP port to be different from 5060 (for example, 5075) due to known issues with using the standard SIP port (5060) with mobile devices.

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

Webex Common Identity

Auth Service XSP

HTTPS

https://idbroker-eu.webex.com/idb

http://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

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 App   

Xsi/DMS

Any

HTTPS

Your XSP

443

Webex App VoIP endpoints SIP

Any

SIP

Your SBC

SP-defined protocol and port

TCP/UDP


It is strongly advisable for the SIP port to be different from 5060 (for example, 5075) due to known issues with using the standard SIP port (5060) with mobile devices.

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

https://idbroker-b-us.webex.com

443

Webex Common Identity

Auth Service XSP

HTTPS

https://idbroker.webex.com/idb

https://idbroker-b-us.webex.com/idb

https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

http://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

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

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.

How Webex Apps 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.


      Each A/AAAA record must map to one IP address. We mandate this configuration because the client's XSI-event heartbeats must go to the same IP address that is used to establish the event channel.

      If you map the A/AAAA name to more than one IP address, the client eventually sends heartbeats to an address where it did not establish an event channel. This results in the channel being torn down, and also in significantly more internal traffic which impairs your XSP cluster performance.

      The client connects to one of the targets (and therefore its A/AAAA record with a single IP 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.

      As noted above, the A/AAAA record must resolve to one IP address for the same reasons.

      (See following example 2)

  2. (Optional) You may subsequently provide custom XSI-Actions/XSI-Events details in the device configuration for the Webex app, 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 its XSI Actions/ XSI Events connectivity. The first step in this is to perform the same DNS lookup process listed under step 1 – this time requesting a lookup for the value in the %XSI_ROOT_WXT% parameter from its 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 discovery of multiple internet facing XSP servers by Webex apps (SRV lookup not yet supported by Webex for BroadWorks cloud microservices)

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 by Webex apps or by Webex cloud microservices

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 by Webex cloud microservices (not supported by Webex apps)

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


If you map your DNS A/AAAA record to multiple IP addresses (to provide redundant connections for the microservices, as shown in the previous table), then you must not use the same A/AAAA record as the clients' XSI address.

In that case, you can configure a SRV record for the clients (as shown in Table 1 above), but the SRV must resolve to a different set of A/AAAA records. As previously noted, those A/AAAA records must map to one IP address each.

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 only use round-robin A/AAAA records if:

    • you have multiple internet-facing XSP servers that you want the Webex microservices to find.

    • you do not use the round-robin A/AAAA records to resolve the client XSI address.

  • 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
Apr 9, 2021| 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

TLS (server authenticates itself to clients)

User authentication

Computer Telephony Integration

mTLS (client and server authenticate each other)

Telephony presence

Call Settings Webview application

TLS (server authenticates itself to clients)

Exposes user call settings in the selfcare portal within the Webex app

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.

Configure Authentication Service (with CI Token Validation)

Use this procedure to configure the Authentication Service to use CI Token Validation with TLS. This authentication method is recommended if you are running R22 or higher and your system supports it.


Mutual TLS (mTLS) is supported as an alternative authentication method for the Auth Service. If the following conditions apply to your system, configure mTLS authentication rather than CI Token Validation:

  • You are running R21SP1.

  • You have multiple Webex organizations running off the same XSP server. In this case, you must use mTLS authentication as CI Token Validation does not support multiple connections to the same XSP Auth Service.

To configure mTLS authentication for the Auth Service, refer to the Appendix.

Also note that if you are running R22 or higher, and you currently use mTLS for the Auth Service, it's not mandatory that you reconfigure to use CI Token Validation with TLS.

  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 "XSP AuthService Configuration". Cisco gives you an OAuth client ID, a client secret, and a refresh token that is valid for 60 days. If the token expires before you use it with your XSP, you can raise another request.

  2. Install the following patches on each XSP server. Install the patches that are appropriate to your release:

    • For R22:

      AP.platform.22.0.1123.ap376508

      AP.xsp.22.0.1123.ap376508

    • For R23:

      AP.xsp.23.0.1075.ap376509

      AP.platform.23.0.1075.ap376509

    • For R24—no patch required

  3. Install the AuthenticationService application on each XSP service.

    1. Run the following command to activate the AuthenticationService application on the XSP to the /authService context path.

      XSP_CLI/Maintenance/ManagedObjects> activate application AuthenticationService 22.0_1.1123/authService
    2. Run this command to deploy the AuthenticationService on the XSP:

      XSP_CLI/Maintenance/ManagedObjects> deploy application /authServiceBroadWorks SW Manager deploying /authService...
  4. Configure the Identity Providers by running the following commands on each XSP server:

    XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco> get

    • set enabled true

    • set clientId <client id>

    • set clientSecret <secret from TAC service request>

    • set ciResponseBodyMaxSizeInBytes 65536

    • set issuerName <URL>—For the URL, enter the IssuerName URL that applies to your CI Cluster. See the table that follows.

    • set issuerUrl <URL>—For the URL, enter the IssuerUrl that applies to your CI Cluster. See the table that follows.

    • set tokenInfoUrl <IdPProxy URL>—Enter the IdP Proxy URL that applies to your Teams Cluster. See the table that follows.

    Table 1. Identity Provider URLs

    IssuerURL and IssuerName URL

    IdP Proxy URL

    If CI Cluster is...

    Set IssuerURL and IssuerName to...

    If Teams Cluster is...

    Set IdP Proxy URL to...

    US-A

    https://idbroker.webex.com/idb

    ACHM

    https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

    EU

    https://idbroker-eu.webex.com/idb

    AFRA

    http://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

    US-B

    https://idbroker-b-us.webex.com/idb

    AORE

    http://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

    * If you don't know your CI Cluster or Teams Cluster, you can obtain the information from the Help Desk view in Control Hub. Under Customer details, see the value of the CI Cluster and Teams Cluster fields.


     
    For testing, you can verify that the URL is valid by replacing the "idp/authenticate" portion of the URL with "ping".
  5. Specify the Webex entitlement that must be present in the user profile in Webex by running the following command:

    XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco/Scopes> set scope broadworks-connector:user

  6. Configure Identity Providers for Cisco Federation using the following commands on each XSP server:

    XSP_CLI/Applications/AuthenticationService/IdentityProviders/Cisco/Federation> get

    • set flsUrl https://cifls.webex.com/federation

    • set refreshPeriodInMinutes 60

    • set refreshToken <token from service request>

  7. Run the following command to validate that your FLS configuration is working. This command will return the list of Identity Providers:

    XSP_CLI/Applications/AuthService/IdentityProviders/Cisco/Federation/ClusterMap> Get

  8. Configure Token Management using the following commands on each XSP server:

    • XSP_CLI/Applications/AuthenticationService/TokenManagement>

    • set tokenIssuer BroadWorks

    • set tokenDurationInHours 720

  9. Generate and Share RSA Keys. You must generate keys on one XSP then copy them to all other XSPs. This is due to the following factors:

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


    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. The key store location is not configurable. Export the keys:

      XSP_CLI/Applications/authenticationService/KeyManagement> exportKeys

    4. Copy the exported file /var/broadworks/tmp/authService.keys to the same location on the other XSPs, overwriting an older .keys file if necessary.

    5. Import the keys on each of the other XSPs:

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

  10. 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 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 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> certificateFile </path/to/server certificate> chainFile</path/to/chain file>

      On BroadWorks 21.sp1:

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

  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.

Call Settings Webview

Call Settings Webview (CSWV) is an application hosted on XSP (or ADP) to enable users to modify their BroadWorks call settings through a webview that they see in the soft client. There is a detailed CSWV Solution Guide at https://xchange.broadsoft.com/node/1050149.

Webex makes use of this feature to provide users with access to common BroadWorks call settings that are not native to the Webex app.

If you want your Webex for BroadWorks subscribers to access call settings beyond the defaults available in the Webex app, you need to deploy Call Settings Webview feature.

Call Settings Webview has two components:

  • Call Settings Webview application, hosted on a Cisco BroadWorks XSP (or ADP).

  • The Webex app, which renders the call settings in a Webview.

User Experience

  • Windows users: Click profile picture, then Settings > Calling > Self Care.

  • Mac users: Click profile picture, then Preferences > Calling > Self Care

Deploy CSWV on BroadWorks

Install Call Settings Webview on XSPs

CSWV application must be on the same XSP(s) that host the Xsi-Actions interface in your environment. It is an unmanaged application on XSP, so you need to install and deploy a web archive file.

  1. Sign in to Xchange and search for "BWCallSettingsWeb" in the software download section.

  2. Find and download the most recent version of the file.

    For example, BWCallSettingsWeb_1.8.2_1.war (https://xchange.broadsoft.com/node/1057167) was the most recent at the time of writing.

  3. Install, activate, and deploy the web archive according to the Xtended Service Platform Configuration Guide for your XSP version. (R23 version is https://xchange.broadsoft.com/node/1033484).

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

    2. Navigate to the following CLI context and run the install command:

      XSP_CLI/Maintenance/ManagedObjects> install application /tmp/BWCallSettingsWeb_1.7.5_1.war

      The BroadWorks software manager validates and installs the file.

    3. [Optional] Delete /tmp/BWCallSettingsWeb_1.7.5_1.war (this file is no longer required).

    4. Activate the application:

      XSP_CLI/Maintenance/ManagedObjects> activate application BWCallSettingsWeb 1.7.5 /callsettings

      The name and version are mandatory for any application, but for CSWV you must also provide a contextPath because it is an unmanaged application. You can use any value that is not used by another application, for example, /callsettings.

    5. Deploy the Call Settings application on the selected context path:

      XSP_CLI/Maintenance/ManagedObjects> deploy application /callsettings

  4. You can now predict the call settings URL that you will specify for clients, as follows:

    https://<XSP-FQDN>/callsettings/

    Notes:

    • You must supply the trailing slash on this URL when you enter it in the client configuration file.

    • The XSP-FQDN must match the Xsi-Actions FQDN, because CSWV needs to use Xsi-Actions, and CORS is not supported.

  5. Repeat this procedure for other XSPs in your Webex for BroadWorks environment (if necessary)

The Call Settings Webview application is now active on the XSPs.

Additional Configuration for XSP R21

If you're deploying the CSWV application on an R21 XSP:

  1. Navigate to the call settings application context and run get to read its configuration: XSP_CLI/Applications/BWCallSettingsWeb_1.7.5/General> get

    You should see the following parameters and values:

    xsiActionsContextOrURL=/com.broadsoft.xsi-actions
    displayCriteriaOrScheduleName=criteria
    applicationMode=prod
    
  2. Use set (if necessary) to change the parameters to the values shown above.

  3. Repeat for other R21 XSPs if necessary.

Configure the Webex app to Use Call Settings Webview

For more detail on client configuration, see Webex App for BroadWorks Client Configuration Guide on Xchange for your Webex app version. For example, the September 2020 version of this file is at https://xchange.broadsoft.com/node/1054075

There's a custom tag in the Webex app configuration file that you can use to set the CSWV URL. This URL shows the call settings to the users through the application's interface.

<config>
    <services>
        <web-call-settings target="%WEB_CALL_SETTINGS_TARGET_WXT%">
            <url>%WEB_CALL_SETTINGS_URL_WXT%</url>
        </web-call-settings>

In the Webex app configuration template on BroadWorks, configure the CSWV URL in the %WEB_CALL_SETTINGS_URL_WXT% tag.

If you do not explicitly specify the URL, the default is empty and the call settings page is not visible to the users.

  1. Make sure you have the latest configuration templates for the Webex app (see Device Profiles).

  2. Set the Web Call Settings Target to csw:

    %WEB_CALL_SETTINGS_TARGET_WXT% csw

  3. Set the Web Call Settings URL for your environment, for example:

    %WEB_CALL_SETTINGS_URL_WXT% https://yourxsp.example.com/callsettings/

    (You derived this value when deploying the CSWV application)

  4. The resulting client configuration file should have an entry as follows:
    <web-call-settings target="csw">
        <url>https://yourxsp.example.com/callsettings/</url>
    </web-call-settings>

Configure Call Push Notifications in Webex for BroadWorks

In this document we use the term Call Notifications Push Server (CNPS) to describe an XSP-hosted, or ADP-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.

For more information about NPS, see the Notification Push Server Feature Description at 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 Webex users of incoming messages or presence changes.


This section describes how to configure NPS for authentication proxy when the NPS does not already support other apps. If you need to migrate a shared NPS to use NPS proxy, see Updating Cisco BroadWorks NPS to Use NPS Proxy https://help.webex.com/nl5rir2/.

NPS Proxy Overview

For compatibility with Webex for BroadWorks, your CNPS must 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 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.

APNS Considerations

Apple will no longer support the HTTP/1-based binary protocol on the Apple Push Notification service after March 31, 2021. We recommend that you configure your XSP to use the HTTP/2-based interface for APNs. This update requires that your XSP hosting the NPS be running R22 or later.

Prepare Your NPS for Webex for BroadWorks

1

Install and configure a dedicated XSP (minimum version R22), or Application Delivery Platform (ADP).

2

Install the NPS Authentication Proxy patches:

XSP R22 patches:

XSP R23 patches:

3

Activate the Notification Push Server application.

4

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

XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true

5

(For Apple iOS notifications) Enable HTTP/2 on the NPS.

XSP_CLI/Applications/NotificationPushServer/APNS/GeneralSettings> set HTTP2Enabled true

6

Attach a techsupport from the NPS XSP/ADP.

What to do next

For fresh installs of an NPS, go to Configure NPS to Use Authentication Proxy

To migrate an existing Android deployment to FCMv1, go to Migrate NPS to FCMv1

Configure NPS to Use Authentication Proxy

This task applies to a new installation of NPS, dedicated to Webex for BroadWorks.

If you want to configure the authentication proxy on an NPS that is shared with other mobile apps, see Updating Cisco BroadWorks NPS to Use NPS Proxy (https://help.webex.com/nl5rir2).

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.

Cisco gives you an OAuth client ID, a client secret, and a refresh token that is valid for 60 days. If the token expires before you use it with your NPS, you can raise another request.
2

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
New Password: client-Secret-From-Step1
XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> set RefreshToken
New Password: Refresh-Token-From-Step1

To verify the values you entered match with what you were given, run XSP_CLI/Applications/NotificationPushServer/CiscoCI/Client> get

3

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

4

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

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

5

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

XSP_CLI/Applications/NotificationPushServer/APNS/Production/Tokens> add com.cisco.squared

6

Configure the following NPS URLs:

XSP CLI Context

Parameter

Value

  • XSP_CLI/Applications/

    NotificationPushServer/FCM>

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

  • XSP_CLI/Applications/NotificationPushServer

    /APNS/Production>

url

https://api.push.apple.com/3/device

7

Configure the following NPS connection parameters to the recommended values shown:

XSP CLI Context

Parameter

Value

  • XSP_CLI/Applications/

    NotificationPushServer/FCM>

tokenTimeToLiveInSeconds

3600

connectionPoolSize

10

connectionTimeoutInMilliseconds

3600

connectionIdleTimeoutInSeconds

600

  • XSP_CLI/Applications/NotificationPushServer/

    APNS/Production>

connectionTimeout

300

connectionPoolSize

2

connectionIdleTimeoutInSeconds

600

8

Check if the Application Server is screening application IDs, because you may need to add the Webex apps to the allow list:

  1. Run AS_CLI/System/PushNotification> get and check the value of enforceAllowedApplicationList. If it is true, you need to complete this sub task. Otherwise, skip the rest of the sub task.

  2. AS_CLI/System/PushNotification/AllowedApplications> add com.cisco.wx2.android “Webex Android”

  3. AS_CLI/System/PushNotification/AllowedApplications> add com.cisco.squared “Webex iOS”

9

Restart the XSP: bwrestart

10

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

Migrate NPS to FCMv1

This topic contains optional procedures that you can use in Google FCM Console when you have an existing NPS deployment that you need to migrate to FCMv1. There are three procedures:

Migrate UCaaS Clients to FCMv1

Use the below steps in Google FCM Console to migrate UCaaS clients to Google FCM HTTPv1.


If branding is applied to the client, the client must have the Sender ID. In the FCM Console, see Project Settings > Cloud Messaging. The setting appears in the Project credentials table.

For details, see the Connect Branding Guide at https://xchange.broadsoft.com/node/1053211. Refer to the gcm_defaultSenderId parameter, which is located in the Branding Kit, Resource folder, branding.xml file with the below syntax:

<string name="gcm_defaultSenderId">xxxxxxxxxxxxx</string>

  1. Log into FCM Admin SDK at http://console.firebase.google.com.

  2. Select the appropriate Android application.

  3. In the General tab, record the project ID

  4. Navigate to the service accounts tab to configure a service account. You can create a new service account or configure an existing one.

    To create a new Service Account:

    1. Click the blue button for create new service account

    2. Click on the blue button to generate a new private key

    3. Download key to a secure location

    To reuse an existing service account:

    1. Click on the blue text to view existing service accounts.

    2. Identify the service account to use. Service account needs permission firebaseadmin-sdk.

    3. On the very right, click the hamburger menu and create a new private key.

    4. Download key to a secure location.

  5. Copy the key onto the XSP.

  6. Configure the project ID and :

    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 FCMv1:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  9. Run the bwrestart command to restart the XSP.

Migrate SaaS Clients to FCMv1

Use the below steps on Google FCM Console if you want to migrate SaaS clients to FCMv1.


Make sure that you have already completed the procedure "Configure NPS to Use Authentication Proxy".
  1. Disable FCM:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled false
    ...Done
  2. Run the bwrestart command to restart the XSP.

  3. Enable FCM:

    XSP_CLI/Applications/NotificationPushServer/FCM> set V1Enabled true
    ...Done
  4. Run the bwrestart command to restart the XSP.

Update ADP Server

Use the below steps in Google FCM Console if you are migrating the NPS to use an ADP server.

  1. Get the JSON file from the Google Cloud Console:

    1. On the Google Cloud Console, go to the Service Accounts page.

    2. Click Select a project, choose your project and click Open.

    3. Find the row of the service account that you want to create a key for, click the More vertical button, then click Create key.

    4. Select a Key type and click Create

      The file downloads.

  2. Add FCM to the ADP server:

    1. Import the JSON file to the ADP server using the /bw/install command.

    2. Login to the ADP CLI and add Project and API key:

      ADP_CLI/Applications/NotificationPushServer/FCM/Projects> add connect /bw/install/google JSON :

    3. Next, add the Application and key:

      ADP_CLI/Applications/NotificationPushServer/FCM/Applications> add com.broadsoft.ucaas.connect projectId connect-ucaas...Done

    4. Verify the configuration:

      ADP_CLI/Applications/NotificationPushServer/FCM/Projects> g
      Project ID Accountkey
      ========================
      connect-ucaas ********
      
      ADP_CLI/Applications/NotificationPushServer/FCM/Applications> g
      Application ID Project ID
      ===================================
      com.broadsoft.ucaas.connect connect-ucaas

Configure Your Partner Organization in Partner 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 apps 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. (Optional) Enter a BroadWorks user Account Name and Password that you know is within the BroadWorks system you are connecting to Webex, then click Next.

    The validation tests can use this account to validate the connections to the interfaces in the cluster.

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

  7. Add your CTI Interface URL and click Next.

  8. Add your Authentication Service URL.

  9. Select Auth Service with CI token validation.

    This option does not require mTLS to protect the connection from Webex, because the Authentication Service properly validates the user token against the Webex identity service before it issues the long-lived token to the user.

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

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

  12. The Create button may be disabled on the final (preview) screen of the wizard. If you cannot save the template, it indicates a problem with one of the integrations you just configured.

    We implemented this check to prevent errors in subsequent tasks. You can go back through the wizard as you configure your deployment, which may require modifications to your infrastructure (e.g. XSP, load balancer, or firewall) as documented in this guide, before you can save the template.

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

Configure your Customer Templates

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

You can create as many templates as you need, but only one template can be associated with a customer.

  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 Cluster dropdown to choose the cluster you want to use with this template.

  5. Enter a Template Name, then click Next.

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

    Table 2. Recommended Provisioning Settings for Different Provisioning Modes

    Setting Name

    Flowthrough provisioning with trusted emails

    Flowthrough provisioning without emails

    User self-provisioning

    Enable BroadWorks Flow Through Provisioning (include 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

    Service Provider Email Address

    Select an email address from the dropdown (you can type some characters, to find the address if it's 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.

    Country

    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.

    BroadWorks Enterprise Mode Active

    Enable this 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.

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

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

    You can override this setting for individual users via Partner Hub.

  8. 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).

  9. Configure the way users verify their identies to Webex. The settings on this page correspond with your chosen user provisioning mode as shown in the table:

    Table 3. Recommended User Verification Settings for Different Provisioning Modes

    Setting Name

    Flowthrough provisioning with trusted emails

    Flowthrough provisioning without emails

    User self-provisioning

    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:

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

  10. Choose whether you want to Prefill user email addresses in 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.

  11. Choose whether to Enable directory synchronisation.

    This option enables Webex to read BroadWorks contacts into the customer organization, so that users can find and call them from the Webex app.

  12. Enter a Partner Admin.

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

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

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

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

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


    Keep the View Templates page open, as you may 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.

Directory Synchronisation

Directory synchronisation ensures that Webex for BroadWorks users can use the Webex directory to call any calling entity from the BroadWorks server. This feature ensures that even telephony entities without a messaging client are synced to the Webex directory.


Webex for BroadWorks provisioning includes a default sync of messaging users and their associated calling information from the BroadWorks server to the Webex directory. However, the provisioning sync omits users whom are not enabled for messaging and non-user entities (for example, a conference room phone, fax machine or hunt group number). You must enable directory synchronisation to ensure that these omitted calling entities get added to the Webex directory.

Directory Synchronisation Conditions

  • The Directory Synchronisation sync runs weekly for a given customer template. The initial sync gets scheduled for the week following the enabling of the sync (the time chosen to start the sync is random).

  • If a sync failure occurs, the sync is reattempted automatically every 24 hours until the next scheduled sync.

  • You can view sync status in Control Hub (with last successful sync information) for a given customer template.

  • Turning on Synchronisation for a given customer template enables synchronisation for all organizations whom use that template. If there is a sync failure with one or more of these organizations, the status displays a partial failure.

  • The sync ignores users whom do not have a phone number.

  • Each Webex app has a local cache that may take up to 72 hours to clear before the post-sync updates appear in the Webex app. This delay holds whether you are enabling or disabling the feature.

Before You Begin

We recommend that you use the following settings:

  • Rate Limiting Values—Set the following OverloadControl system properties (XSP_CLI/Applications/Xsi-Actions/OverloadControl):

    • userTransactionLimits—Set to 100.

    • transactionLimitPeriodSeconds—Set to 1.

    • userDirectoryTransactionLimit—Set to a null value.

    • globalDirectoryTransactionLimit—Set to a null value.


    It's recommended that you set userDirectoryTransactionLimit and globalDirectoryTransactionLimit to a null value. However, if you do decide to assign values, each must be set to at least five times the value of transactionLimitPeriodSeconds (which should be 1).
  • Paging Values—Set the Paging system properties (XSP_CLI/Applications/Xsi-Actions/Paging):

    • defaultPageSize—Set to 50

    • availableUserMaxLimit—Set to 100

  • CTI Interface—Make sure to upload that Webex CA certificates to the CTI interface trust store and to enable client authentication on the CTI interface.

In addition, we recommend that you apply system patch ap368517 to your BroadWorks deployment before you enable this feature (for patch information, see BroadWorks Software Requirements in the Reference section).

Procedure

Complete the following steps to turn on Directory Synchronisation:

  1. In Partner Hub, choose Settings.

  2. Scroll to BroadWorks Calling and click View Template.

  3. Select the appropriate template.

  4. Scroll to BroadWorks Directory Sync and set the Enable directory synchronisation toggle to On.

  5. Click Save.


To disable Directory Synchronization, set the Enable directory synchronisation toggle to Off. This will remove BroadWorks-only users from the Webex directory.

Call Recording

Webex for BroadWorks supports four modes of call recording.

Table 4. Recording Modes

Recording Modes

Description

Controls/Indicators that display on Webex app

Always

Recording is initiated automatically when the call is established. The user has no ability to start or stop recording.

  • Visual indicator that recording is in progress

Always with Pause/Resume

Recording is initiated automatically when the call is established. User can pause and resume recording.

  • Visual indicator that recording is in progress

  • Pause Recording button

  • Resume Recording button

OnDemand

Recording is initiated automatically when call is established, but the recording is deleted unless the user presses Start Recording.

If user starts recording, the full recording from call setup is retained. After starting the recording, user can also pause and resume recording

  • Start Recording button

  • Pause Recording button

  • Resume Recording button

OnDemand with User-Initiated Start

Recording does not initiate unless the user selects the Start Recording option on the Webex app. The user has the option to start and stop recording multiple times during a call.

  • Start Recording button

  • Stop Recording button

  • Pause Recording button

Requirements

To deploy this feature on Webex for BroadWorks, you must deploy the following BroadWorks patches:

  • AP.as.22.0.1123.ap377718

  • AP.as.23.0.1075.ap377718

  • AP.as.24.0.944.ap377718

The AS must be configured to send the X-BroadWorks-Correlation-Info SIP header:

  • AS_CLI/Interface/SIP> set sendCallCorrelationIDNetwork true

  • AS_CLI/Interface/SIP> set sendCallCorrelationIDAccess true

The following configuration tag must be enabled in order to use this feature: %ENABLE_CALL_RECORDING_WXT%.

This feature requires an integration with a third-party call recording platform.

To configure call recording on BroadWorks, go to the Cisco BroadWorks Call Recording Interface Guide at https://xchange.broadsoft.com/node/1033722.

Additional Information

For user information on how to use the Recording feature, go to Webex | Record Your Calls.

To replay a recording, users or administrators must go to their third-party call recording platform.

Group Call Park and Retrieve

Webex for BroadWorks supports Group Call Park and Retrieve. This feature provides a way for users within a group to park calls, which can then be retrieved by other users in the group. For example, retail employees in a store setting could use the feature to park a call that can then be picked up by someone in another department.

To deploy the feature, an administrator must create a call park group and add users to the group. Once the feature is configured:

  • While in a call, a user clicks the Park option on their Webex app to park the call at an extension that the system selects automatically. The system displays the extension to the user for a period of 10 seconds.

  • Another user in the group clicks the Retrieve call option on their Webex app. The user then enters the extension of the parked call in order to continue the call.

For administration details on how to configure this feature on BroadWorks, refer to the Call Park section of the BroadWorks Application Server Group Web Interface Administration Guide – Part 2 at https://xchange.broadsoft.com/node/1051947.

Additional Information

For user information on how to use Group Call Park, see Webex | Park and Retrieve Calls.

Call Park/Directed Call Park

Regular or directed call park is not supported in the Webex app UI, but provisioned users can deploy the feature using Feature Access Codes:

  • Enter *68 to park a call

  • Enter *88 to retrieve a call

Customize and Provision Clients

Users download and install their generic Webex apps, for desktop or mobile (see Webex App 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 apps 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 Apps Configuration Templates to BroadWorks Application Server

Webex apps 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.


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 app on two different machines.

2

Sign in as your test users on the two machines.

3

Make test calls.

Water Mark
Apr 9, 2021| 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.

Managing Users

To manage users in Webex for BroadWorks, remember that the user exists both in BroadWorks and in Webex. Calling attributes and the user's BroadWorks identity are held in BroadWorks. A distinct email identity for the user, and its licensing for Webex features, are held in Webex.

Provision Users

You can provision users in these ways:

  • Use APIs to create Webex accounts

  • Assign Integrated IM&P (flowthrough provisioning) with trusted emails to create Webex accounts

  • Assign Integrated IM&P (flowthrough provisioning) without trusted emails. Users provide and validate email addresses to create Webex accounts

  • Allow users to self-activate (you send them a link, they create Webex accounts)

Public Provisioning APIs

Cisco Webex exposes public APIs to allow Service Providers to integrate Webex for BroadWorks subscriber provisioning into their existing provisioning workflows. The specification for these APIs is available on developer.webex.com. If you wish to develop with these APIs, contact your Cisco representative to get Webex for BroadWorks.

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.

User Self-Activation

To provision BroadWorks users in Webex, without assigning the Integrated IM&P service:

  1. Sign in to Partner Hub, and find the BroadWorks Settings page.

  2. Click View Templates.

  3. Select the provisioning template you want to apply to this user.

    Remember that each template is associated with a cluster and your partner organization. If the user is not in the BroadWorks system associated with this template, the user cannot self-activate with the link.

  4. Copy the provisioning link and send it to the user.

    You may also want to include the software download link, and remind the user they need to supply and validate their email address to activate their Webex account.

  5. You can monitor the user's activation status on the selected template.

For more information, see User Provisioning and Activation Flows.

Change User ID or Email Address

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

Not required in BroadWorks if you do not assert that you can trust emails

Not required in BroadWorks if you allow subscribers to self-activate

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

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

Change User Package in Partner Hub

1

Sign in to Partner Hub and click Customers.

2

Find and select the customer organization where the user is homed.

The organization overview page opens in a panel on the right of the screen.

3

Click View Customer.

The customer organization opens in Control Hub, showing the Overview page.
4

Click Users, then find and click the affected user.

The user details panel opens on the right of the screen.

5

In the user's Services, click Webex for BroadWorks Packages (Subscriptions).

The user's packages panel opens, and you can see which package is currently assigned to the user.

6

Select the package you want for this user (Basic, Standard, Premium or Softphone).

Control Hub shows a message that the user is updating.

7

You can close the user details and the Control Hub tab.


Standard and Premium packages have distinct meeting sites that are associated with each package. When a subscriber with administrtor privileges with one of these two packages moves to the other package, the subscriber shows up with two meeting sites in Control Hub. The subscriber’s host meeting capabilities and meeting site align to their current package. The previous package's meeting site and any previously created content on that site, such as recordings, remain accessible to the meeting site admin.

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.
    4. If you are using mTLS with Authentication Service, are the Webex client certificates loaded on your XSP/ADP trust store? Is the app (or the interface) configured to require client certificates?

    5. If you are using CI token validation with Authentication Service, is the app (or interface) configured to not require client certificates?

Client Issues

Verify the Client is Connected to BroadWorks

  1. Sign in to the Webex app.

  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 app 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?

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 Webex app help and support topics.

  • The Webex app can be customized with this help URL and a problem report URL.

  • Webex app 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
Apr 9, 2021| 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

Webex: 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 Webex 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 (TLS)

DMS

Install Webex and Sign In (Subscriber Perspective)

1

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

2

Run Webex.

Webex 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. Webex launches a browser for you to complete authentication with your identity provider. This could be multi-factor authentication (MFA).

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

Webex 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 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-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 app 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 Webex app

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

Webex app

BroadWorks Authentication

BroadWorks authentication refers to user sign-in to a Webex app 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 Webex app

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

Webex app

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

Developer Access

The API specification is available on https://developer.webex.com and a guide to using it is at https://developer.webex.com/docs/api/guides/webex-for-broadworks-developers-guide.

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.

BroadWorks Software Requirements

See Lifecycle Management - BroadSoft Servers.

We expect the Service Provider to be "patch current". 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

AP.as.22.0.1123.ap377868

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

AP.platform.22.0.1123.ap376508

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

AP.xsp.22.0.1123.ap376508

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

AP.as.23.0.1075.ap377868

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

Version 24

Server

Required Patches

Application Server

AP.as.24.0.944.ap377868

BroadWorks Tags Required for Webex

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_RECORDING_WXT% Y Y FALSE
%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_DESCRIPTION_WXT% Y Y TRUE
%ENABLE_BROADWORKS_ANYWHERE_ALERT_ALL_LOCATIONS_WXT% Y Y FALSE
%BROADWORKS_ANYWHERE_ALERT_ALL_LOCATIONS_DEFAULT_WXT% Y Y FALSE
%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%