Overview of Webex for Cisco BroadWorks

Solution Purpose

• To provide 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 App, 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 Cisco BroadWorks target small to medium business use cases. The Webex for Cisco 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 Cisco BroadWorks

About this Document

The purpose of this document is to help you understand, prepare for, deploy, and manage your Webex for Cisco 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 Cisco BroadWorks toggle to your Webex partner organization. (See Deploy Webex for Cisco BroadWorks > Partner Onboarding in this document.)

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

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

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

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

Note	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 Cisco 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 Cisco BroadWorks Reference > Terminology if a term isn’t explained in context.)

Webex Security

The Webex client is a secure application that makes secure connections to Webex and BroadWorks. The data that is stored in the 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

• https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/esp/cisco-spark-security-white-paper.pdf

• https://trustportal.cisco.com/c/dam/r/ctp/docs/privacydatasheet/collaboration/cisco-broadcloud-uc-one-saas-privacy-data-sheet.pdf

• https://www.cisco.com/c/en/us/products/security/general-data-protection-regulation.html

• https://www.cisco.com/c/en/us/about/trust-center/gdpr.html

• https://www.cisco.com/c/en/us/products/security/comply-with-GDPR.html

• https://www.cisco.com/c/en/us/about/legal/privacy-full.html

Organization Data Residency

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

For information on the roles that are available to partners, the access privileges that accompany those roles, and how to assign roles, see Partner Administrator Roles for Webex for BroadWorks and Wholesale RTM.

Note	The first user provisioned to a new partner organizaiton is assigned automatically to the Full Administrator and Full Partner Administrator roles. That administrator can use the above article to assign additional roles.

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 “Onboarding Templates” to represent the suites or packages served through those systems. You then provision your customers or subscribers.

What's in the Diagram?

Clients

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

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

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

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

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

Service Provider Network

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

• Public-facing XSP, for Webex for Cisco 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) and call history.

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

Webex Cloud

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

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

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

  • User Provisioning APIs

  • Service Provider Configuration

  • User Login using BroadWorks credentials

• Webex Messaging box for messaging-related microservices.

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

Third-Party Web Services

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

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

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

XSP Architecture Considerations

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

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

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

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

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

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

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

XSP Architecture

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 Cisco 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 Cisco BroadWorks. This way the two services can operate independently while you migrate subscribers.

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

• The Cisco BroadWorks System Capacity Planner assumes a dedicated XSP farm and may not be accurate if you use it for collocation calculations.

Unless noted otherwise, the dedicated Webex for Cisco 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)—Optional. It's not mandatory that you deploy a separate DMS instance or farm specifically for Webex for Cisco BroadWorks. You can use the same DMS instance that you use for UC-One SaaS or UC-One Collaborate.

• Call Settings Webview (TLS)—Optional. Call Settings Webview (CSW) is required only if you want Webex for Cisco BroadWorks users to be able to configure calling features on the Webex App.

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

• (Diagram labelled Option 1) One XSP 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.

Note

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

Note	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

Note	This list is subject to change as our cloud security requirements evolve. Follow the current Cisco cloud security recommendation on cipher selection, as described in the requirements list in this document.

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

• TLS_RSA_PSK_WITH_AES_256_GCM_SHA384

• TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

• TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

• TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256

• TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

• TLS_RSA_WITH_AES_256_GCM_SHA384

• TLS_PSK_WITH_AES_256_GCM_SHA384

• TLS_PSK_WITH_CHACHA20_POLY1305_SHA256

• TLS_RSA_PSK_WITH_AES_128_GCM_SHA256

• TLS_DHE_PSK_WITH_AES_128_GCM_SHA256

• TLS_RSA_WITH_AES_128_GCM_SHA256

• TLS_PSK_WITH_AES_128_GCM_SHA256

• TLS_RSA_WITH_AES_256_CBC_SHA256

• TLS_RSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384

• TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

• TLS_RSA_PSK_WITH_AES_256_CBC_SHA384

• TLS_DHE_PSK_WITH_AES_256_CBC_SHA384

• TLS_RSA_PSK_WITH_AES_256_CBC_SHA

• TLS_DHE_PSK_WITH_AES_256_CBC_SHA

• TLS_RSA_WITH_AES_256_CBC_SHA

• TLS_PSK_WITH_AES_256_CBC_SHA384

• TLS_PSK_WITH_AES_256_CBC_SHA

• TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

• TLS_RSA_PSK_WITH_AES_128_CBC_SHA256

• TLS_DHE_PSK_WITH_AES_128_CBC_SHA256

• TLS_RSA_PSK_WITH_AES_128_CBC_SHA

• TLS_DHE_PSK_WITH_AES_128_CBC_SHA

• TLS_RSA_WITH_AES_128_CBC_SHA

• TLS_PSK_WITH_AES_128_CBC_SHA256

• TLS_PSK_WITH_AES_128_CBC_SHA

Xsi Events Scale Parameters

You may need to increase the Xsi-Events queue size and thread count to handle the volume of events that the Webex for Cisco BroadWorks solution requires. You can increase the parameters to the minimum values shown, as follows (don’t decrease them if they are above these minimum values):

XSP_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 Cisco BroadWorks cloud and clients. In this case, you would provide the URL of the load balancer to the Webex for Cisco BroadWorks configuration.

Notes on this architecture:

• Configure DNS so the clients can find the load balancer when connecting to the Xsi interface (see DNS configuration).

• We recommend that you configure the edge element in reverse SSL proxy mode, to ensure point to point data encryption.

• Certificates from 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:

• Two records are required to connect to the XSP servers:

  • For Webex microservices: Round-robin A/AAAA records are required to target the multiple XSP IP addresses. This is because the Webex microservices can’t do SRV lookups. For examples, see Webex Cloud Services.

  • For Webex App: An SRV record that resolves to A records where each A record resolves to a single XSP. For examples, see Webex App.

    Use prioritized SRV records to target the XSI service for the multiple XSP addresses. Prioritize your SRV records so that the microservices will always go to the same A record (and subsequent IP address) and will only move to the next A record (and IP address) if the first IP address is down. DO NOT use a round-robin approach for the Webex App.

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

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.

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

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.

Note	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

Webex exposes a set of public APIs that enable you to build Webex for Cisco BroadWorks user/subscriber provisioning into your existing user management workflow/tools.

Required Patches with Flow-through Provisioning

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

For R22:

1. Install AP.as.22.0.1123.ap376508.

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

   For more information, see the patch notes https://www.cisco.com/web/software/286326332/154309/AP.as.22.0.1123.ap376508.txt.

For R23:

1. Install AP.as.23.0.1075.ap376509

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

   For more information, see the patch notes https://www.cisco.com/web/software/286326332/154325/AP.as.23.0.1075.ap376509.txt.

For R24:

1. Install AP.as.24.0.944.ap375100

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

   For more information, see the patch notes https://www.cisco.com/web/software/286326332/154326/AP.as.24.0.944.ap375100.txt.

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

Extension Dialing

Extension Dialing feature support allows Webex for Cisco Broadworks users to dial other users with an extension similar to the primary phone number within the same enterprise. This is especially useful for users who do not have DID numbers.

During provisioning, the extension of the users gets stored in the Webex directory as the user’s extension. For BroadWorks calling, the extension appears on the Webex App in the extension field of all the call initiation method areas and the user’s profile. Webex for Cisco BroadWorks supports extension-only calls between users within the same group and different groups of the same enterprise with the combination of location dialing code and extension. However, calling between two enterprises using only extensions is not supported.

An extension can be provisioned for the Cisco BroadWorks users through the following methods:

• Cisco BroadWorks users

  • Public API provisioning as ‘extension

    • The extension parameter should be explicitly passed as part of the API call. For enterprises/groups that have Location Dialing Code (LDC) configured, the extension parameter should be the combination of LDC and 'extension number.

  • Flowthrough or Self-Activation provisioning

    • Extension and LDC (where applicable) will be automatically retrieved from BroadWorks.

• BroadWorks-only Calling users or entities

  • Synced automatically from BroadWorks by Directory Sync using the combination of Location Dialing Code (LDC) and extension number.

Prerequisites

1. Client version required for supporting this feature is 42.11 or later.

2. Patch where extension and location dialing codes are added to XSI and Provisioning Adapter February 2022 for version 23 or above as part of :

   • AP.platform.23.0.1075.ap380045

   • AP.as.23.0.1075.ap380045

   • AP.xsp.23.0.1075.ap380045

   • AP.as.24.0.944.ap380045

3. Enable the header X-BroadWorks-Remote-Party-Info on the AS using the below CLI command for this SIP call flow which is required for extension dialing feature support.

   AS_CLI/System/DeviceType/SIP> set <device_profile_type> supportRemotePartyInfo true

App Call Options Priority

As part of the Extension Dialing feature support, The app call options priority setting is also provided at the partner level for all the Webex for Cisco Broadworks partners. Using this setting, the partner can control the call priority settings of all its managed customers from Partner Hub. The app call options priority setting for a customer can also be modified at a customer level from Control Hub.

The app call options priority setting contains extension as second option in both Partner Hub and Control Hub when a Webex for Cisco Broadworks user is newly provisioned with extension through any of the above-mentioned provisioning methods.

For all the existing provisioned Orgs, the extension option will be in the hidden state (by default) in the app call options priority setting. This will not show an extension in the audio/video call option of the user in the Webex App.

Following are the options to make the extension call option visible for the existing customers:

1. If a partner wants all its managed customer orgs to be provided with an extension as one of the call options, it is recommended for the Partner Admin to move the Extension from hidden to available in Partner Hub. This will let the managed customer orgs inherit the setting from their partner.

2. If a Partner wants to provide an extension in call options for a specific customer org, it is recommended for the Partner Admin to move the extension from hidden to available in Control Hub.

Group Contacts Support

This feature enhances the Webex for BroadWorks DirSync service by removing the limitation for syncing up to 1500 contacts from the Group phone lists on BroadWorks and allowing partners to sync up to 30K contacts from a single Group phone list and bring it on par with the 30K contacts increase for Enterprise phone list, which was released separately.

There is an overall limit of 200K for all external contacts per Organization, which would apply to the sum of Enterprise and Group phone lists in a single BroadWorks enterprise. For example, a BroadWorks enterprise that has Enterprise phone list with 30K and also 5 Group phone lists each with 30K will be supported (180K total per Org). However, if there are 6 group phone lists each with 30K, this will not be supported (210K total).

Note

This feature is available on request. Please contact your account team to have it enabled. Before enabling the feature, a prerequisite migration is to be run to provision and associate groups for all the existing provisioned users. Cisco team will run an internal API to migrate any existing provisioned users to associate them with the correct group. NOTE: This can take up to one week to process. Once the migration is completed for the partner and the feature is enabled, any newly provisioned users will be 'grouped' appropriately.

After the feature is enabled, the DirSync service starts syncing BroadWorks Group phone list contacts into dedicated per group contact storage in the Webex Contact Service.

During provisioning, the enterprise group of the user needs to be stored in the Webex directory to indicate the group this user belongs to. The association of the user with a BroadWorks group in the Webex Directory allows the Webex app to do contact search in the Contact Service group storage for the specific group of the user.

The feature requires the Webex for BroadWorks subscribers to be provisioned in Webex with the BroadWorks enterprise Group Id.

The BroadWorks enterprise Group Id can be provisioned for the Cisco BroadWorks users through the following methods:

• Webex for Cisco BroadWorks users

  • Public API provisioning as ‘spEnterpriseGroupId’

    • The BroadWorks enterprise Group Id should be explicitly passed in spEnterpriseGroupId parameter of the API call.

  • Flowthrough or Self-Activation provisioning

    • BroadWorks enterprise Group Id will be automatically retrieved from BroadWorks.

  • BroadWorks-only Calling users or entities

    • Not applicable. It’s not required to sync BroadWorks enterprise Group Id for these users.

Note

Public API must be updated PRIOR to the MIGRATION. Migration cannot be completed until THIS API is completed The BroadWorks enterprise Group Id should be explicitly passed in spEnterpriseGroupId parameter of the API call https://developer.webex.com/docs/api/changelog#2023-march After the feature is enabled and as a result of the next directory sync the enterprise user groups will also be displayed in Control Hub. Visualizing the groups in Control Hub for Webex for BroadWorks is purely informational at this stage. Partner and customer admins should not make any modifications to groups or group membership in Control Hub as these changes will not be reflected back to BroadWorks. Group Management in Control Hub is intended for use by partners who will be adopting the upcoming Contact Management APIs.