Thanks for your feedback.

Key benefits

• Advanced call center features—Provides intelligent call routing, agent management, and AI-driven insights.

• Integrated agent workspace—Agents access an integrated environment within the Webex App for calls, messaging, and meetings.

• Enhanced collaboration—Enables communication between Customer Assist agents (on Webex Calling) and other employees (on BroadWorks).

• Deployment flexibility—Allows organizations to maintain core business operations on BroadWorks while deploying Webex for specialized customer service roles.

Understand the hybrid model

This hybrid model supports phased adoption of advanced customer experience features without replacing your entire phone system.

In this hybrid model, you provision the users within the organization in the following ways:

• Webex Calling Customer Assist for agents and supervisors—Provision users who need call center functionalities on the Webex Calling platform. They use Webex App to access Customer Assist features and calling capabilities.

• BroadWorks for other employees—Continue using BroadWorks to manage users who don't need call center features.

Interconnection and call routing

The Partner-Hosted Gateway plays a critical role in this hybrid setup. It routes calls and enables communication between the Webex Calling environment (where agents reside) and the BroadWorks environment (where other employees reside). With the gateway, agents interact with their BroadWorks-based colleagues, and the system directs calls appropriately across both platforms.

High-level call flows:

• PSTN to Customer Assist agent—External PSTN calls to Webex Calling hosted Customer Assist queue are routed through BroadWorks and the premises-based PSTN to reach Webex Calling agents.

• Agent to BroadWorks employee—Webex Calling agents can call employees on the BroadWorks platform through the premises-based PSTN.

• BroadWorks employee to agent—BroadWorks employees can call Customer Assist agents through premises-based PSTN.

• Internal calls (platform-specific)—Agent-to-agent calls remain on Webex Calling, and employee-to-employee calls remain on BroadWorks.

• Agent PSTN calls—Customer Assist agents can make and receive PSTN calls directly through BroadWorks or optionally through Webex Calling PSTN connectivity.

  While Webex Calling PSTN connectivity is an option, we encourage you to use your own PSTN to avoid potential charges for internal calls (for example, when using 10-digit dialing). You must use a certified PSTN solution.

Role of Webex for Cisco BroadWorks in hybrid deployments

Enabling Webex for BroadWorks for the BroadWorks customer organization is mandatory to enhance the overall collaboration experience in a hybrid deployment.

Benefits of Webex for BroadWorks integration:

• BroadWorks directory sync—Automatically synchronizes BroadWorks users and entities (with phone numbers or extensions) to Cisco Common Identity. This allows Customer Assist agents on Webex Calling to easily search for and call their BroadWorks-hosted colleagues.

• BroadWorks authentication—Provides you with the option to manage credentials for all users (both BroadWorks and Webex Calling) within the customer organization using their BroadWorks platform as the authentication source.

• Improved collaboration—BroadWorks users with Webex for BroadWorks packages can use Webex App to send messages and join meetings with Customer Assist agents and supervisors.

Key features and capabilities

Webex Calling Customer Assist features

Customer Assist provides the following capabilities:

• Advanced call queues—Supports intelligent routing, queue management, and customizable call flows.

• Agent management—Provides tools for agents to manage their availability, handle calls, and access customer context.

• Supervisor features—Includes real-time monitoring, reporting, and coaching capabilities.

• AI integration roadmap—AI features in Webex App, offering capabilities like caller intent, suggested responses, call summaries, sentiment analysis, and AI assistants.

For more details, see Webex Calling Customer Assist.

Interoperability features

The hybrid solution ensures seamless interaction across platform and provides the following capabilities:

• Unified communications—Agents can call and collaborate with BroadWorks employees using Webex Messaging and Meetings.

• PSTN Access—Customer Assist agents can make and receive external PSTN calls, routing them efficiently through the integrated architecture.

• Centralized directory—BroadWorks Directory Sync provides a unified contact list for easy lookup and dialing.

User authentication

Customer Assist agents and supervisors can authenticate using either BroadWorks or Webex. You can define the authentication method during the customer onboarding process within the Partner Hub template. For details, see User Login and Configuration Retrieval section in the Webex for Cisco BroadWorks Solution Guide.

Outbound caller ID management

Agents can manage how to display their identity to end customers when making outbound calls. They can select their personal phone number, a custom configurable Calling Line Identification (CLID), or a group or queue number. For details, see Select Caller ID section in the Webex for Cisco BroadWorks Solution Guide.

Partner prerequisites

Before onboarding the BroadWorks customers for Webex Calling Customer Assist, you must align your licensing and subscription models with Cisco Wholesale requirements. Use the following table to determine the necessary actions based on your current deployment status.

Webex App requirements

To support Webex Calling Customer Assist features and ensure smooth hybrid functionality, all agents and supervisors must use the minimum Webex App version 46.2 or later.

Customer Assist user and licensing

1. Can Customer Assist agents and supervisors use BroadWorks authentication even if they are hosted on the Webex Calling platform?

   Yes. To use BroadWorks Authentication for these users, you must create a user entry in BroadWorks for each agent or supervisor by updating their email address in the Alternate ID attribute. These specific BroadWorks users don't need a phone number or a physical device associated with them on the BroadWorks platform. Instead, their phone numbers are associated with the SIP trunk group, which routes incoming calls directly to Webex Calling for handling.

2. Can an existing Webex for Cisco BroadWorks user act as a Customer Assist agent?

   No. Customer Assist agents must be provisioned as Webex Calling users. If a user is currently provisioned only as a Webex for Cisco BroadWorks user, you must convert or re-provision that user as a Webex Calling user before assigning the user as a Customer Assist agent.

3. Can migration scripts move only selected BroadWorks users to Wholesale RTM?

   Support for migration scripts to migrate only selected users from BroadWorks to Wholesale RTM is on the roadmap.

4. Where should the Customer Assist license be provisioned?

   The Customer Assist license must be provisioned within the customer organization. The partner organization defines and manages the customer relationship, but the customer organization receives the Customer Assist license and user entitlements.

5. Can Webex Calling users and Customer Assist agents be provisioned through the API?

   Yes. Webex Calling users can be provisioned using either the API or Control Hub, depending on your operational model. For API-based provisioning, use the Webex Public API with calling data enabled, and assign the required calling and Customer Assist entitlements as part of the customer organization setup.

6. Can Wholesale BroadWorks support be enabled in a staging environment?

   Yes. In a staging environment, We can enable the Wholesale BroadWorks subscription and associated toggles through the Early Partner Testing program. For production environments, a live Wholesale subscription is required.

Emergency Calling and HELD

1. How is the HELD URL populated for Webex Calling clients?

   Webex Calling automatically populates the HELD URL when the deployment uses the default RedSky emergency-calling model. If your deployment uses a different emergency provider, such as Intrado ERS, the default RedSky HELD URL behavior doesn't apply.

2. What values must be associated with the HELD URL for an Intrado ERS deployment?

   An Intrado ERS deployment requires a Level 1 account for the provider and a Level 2 account for each BroadWorks group. You must provision the Level 2 account ID and token (retrieved from Intrado ERS) to ensure Webex Calling clients perform HELD transactions against the correct emergency services account.

3. How does emergency calling align between Webex for Cisco BroadWorks and Webex Calling?

   The goal is to align Webex Calling behavior with the existing Webex for Cisco BroadWorks emergency-calling model. Typically, desktop clients route emergency calls through the configured emergency provider, whereas mobile clients may use the local dialer for emergency calls.

4. How are emergency calls placed by Customer Assist agents routed?

   Emergency call routing depends on the configuration of the agent's Webex Calling location. If emergency calling isn’t configured for the location in Webex Calling, emergency calls placed by Customer Assist agents are routed to BroadWorks over the SIP trunk. If emergency calling is configured for the location in Webex Calling, the calls are routed by Webex Calling to the configured emergency provider, such as RedSky or Intrado.

5. Will non-user devices on BroadWorks, such as lobby phones or conference room phones, be able to reach Customer Assist users?

   Yes. The BroadWorks directory sync is comprehensive. It pushes not only standard user data but also group features (such as hunt groups and auto-attendants) and non-user entities (such as conference room and lobby phones) to the Webex Common Identity (CI). This ensures that all devices and services across the hybrid environment remain reachable and can search for Customer Assist users.

Trunks, domains, and SIP requirements

1. Should this integration use a registration-based or certificate-based trunk?

   Certificate-based trunking is recommended for the BroadWorks to Webex Calling integration. This method is preferred for deployments that require customer-specific FQDN identity, SRV-based routing, and higher concurrent call capacity. Verify the required trunk type for your specific deployment before implementation.

2. Can multiple customers share the same FQDN for certificate-based trunking?

   No. Requests sent from the partner or customer SBC to Webex Calling must use a unique customer FQDN in the SIP Contact header for all request types, including INVITE, OPTIONS, and CANCEL. While you may use a shared SBC, the identity in the Contact header must remain unique for each customer.

3. Do the LGW cert management enhancements remove the unique Contact-header FQDN requirement?

   No. These enhancements don't change the contact-header requirement. Requests sent from the SBC to Webex Calling must continue to include a unique customer FQDN in the Contact header.

4. Which domain should be used in the Request-URI for requests sent to Webex Calling?

   Use the Cisco-generated Webex Calling FQDN as the domain in the Request-URI when sending requests to Webex Calling. The Contact header should contain the configured unique customer FQDN.

5. Where can I find the OTG/DTG value for a Webex Calling trunk?

   You can retrieve this value using the Webex Calling call routing "Get Trunk" API, which includes the otgDtgId field in its response. If you don't know the trunk ID, use the "List Trunks" API first to identify it, and then call the "Get Trunk" API for that specific trunk.

6. For a certificate-based trunk, are linePort, pilotUserId, and sipAuthenticationUserName required in BroadWorks or SBC configuration?

   No, these fields aren’t required for certificate-based trunk configuration. The peerIdentity field is used to represent the SBC SRV record. Verify these requirements against the current Webex Calling trunk API and your specific SBC configuration.

7. Is the password in the Create Trunk API used for certificate-based trunks?

   No. The password isn’t used for certificate-based trunks. If the API requires a password field during creation, generate one according to internal policy, but don't design the certificate-based call flow to depend on it.

8. What are the concurrent-call limits for certificate-based trunks?

   Certificate-based trunks support a range of 250 to 6,500 concurrent calls. In contrast, registration-based trunks are capped at 250 concurrent calls. Note that billing isn’t determined by the configured concurrent-call limit.

9. Can Webex Calling edge proxy addresses be assumed to remain consistent across trunks or over time?

   No. Don't hardcode edge proxy addresses, as they may vary between trunks and are subject to change. Always retrieve current trunk details from Control Hub or the Webex Calling APIs during configuration and operational validation.

10. How should SRV records and route groups be used for redundancy?

    Route groups provide redundancy across trunks. Webex Calling supports route advancement on timeout when a SIP trunk uses SRV and the SRV record resolves to multiple A records. If a route group contains both primary and secondary trunks, Webex Calling can advance the call based on route-group behavior when the primary path times out.

Routing, dial plans, and BroadWorks interworking

1. When are SIP trunks required for extension dialing between BroadWorks and Webex Calling?

   SIP trunks are required if extension dialing between BroadWorks and Webex Calling is necessary. Cloud Connected PSTN (CCP) doesn't support extension dialing between these environments and shouldn’t be used for this specific use case.

2. How is a Webex Calling dial plan associated with routing?

   In Control Hub, a dial plan is associated with a routing choice, either a trunk or a route group. When a location is configured to use a specific trunk or route group for PSTN or interworking, the dial plan associated with that routing choice applies.

3. Does Webex Calling use the directory to validate BroadWorks employee extensions?

   No. Webex Calling doesn't use the directory to validate BroadWorks employee extensions for routing. You must configure dial-plan patterns that match BroadWorks employee extensions, for example, 22XX, and associate those patterns with the trunk or route group that routes calls to BroadWorks.

4. How should agent-to-employee extension dialing be configured?

   Add the BroadWorks employee extension patterns to the Webex Calling dial plan and route those patterns over the appropriate trunk or route group. For example, if all BroadWorks employee extensions use the format 22XX, configure 22XX as a dial-plan pattern and route it to BroadWorks.

5. Are Webex Calling dial-plan entries the same as endpoint digit maps?

   No. Webex Calling dial-plan entries are routing patterns, not endpoint digit maps, and they don’t use the T (timeout) marker commonly found in phone-based digit maps. If a dialed number doesn’t match a configured dial-plan pattern, the system follows default routing behavior, which may result in the call being rejected.

6. How should a Route List user be associated with an enterprise trunk?

   Under the Route List user's Profile > Addresses configuration, select the Trunking device type and choose the appropriate Enterprise Trunk. Assign the enterprise trunk number range to the Route List user so BroadWorks can route the relevant numbers over the correct enterprise trunk.

7. If the enterprise trunk number range already includes the enterprise trunk, is additional Route List user configuration required?

   Yes. You must explicitly configure the Route List user by navigating to their Profile > Addresses, selecting "Trunking" as the device type, and choosing the appropriate Enterprise Trunk. This step is necessary to ensure proper routing.

Administration and SSO

1. Can partner administrators use a claimed corporate domain and corporate SSO?

   Yes. If the Wholesale organization is managed within the main corporate Webex organization, a partner administrator can use corporate SSO, provided they are already a user within that organization. Once the user is provisioned in the Webex organization, they can be granted Partner Hub permissions and access the platform using the corporate SSO flow.

2. What steps should be taken if administrators can’t be added using a corporate domain?

   Verify that the domain is claimed in the target Webex organization and that the user is already provisioned within that organization. Also, ensure that the Wholesale or partner organization relationship allows the user to receive Partner Hub permissions. If these conditions are met and the issue persists, investigate potential organization or domain configuration conflicts before scaling administrator access.