Introducing Cisco Webex Calling

Imagine being able to leverage enterprise-grade cloud calling, mobility, and PBX features, along with Cisco Webex for messaging and meetings and calling from a Webex Calling soft client or Cisco device. That's exactly what Webex Calling has to offer you.

Webex Calling provides the following benefits:

  • Calling subscriptions for telephony users and common areas

  • Webex access for every user

  • Public Switch Telephony Network (PSTN) access to let your users dial numbers outside the organization. The service is provided through an existing enterprise infrastructure (local gateway without on-premises IP PBX or with existing Unified CM call environment)

Webex Calling supports the following features. For more information, see the Configure Webex Calling Features chapter.

Table 1. Admin Configurable Features

Feature

Description

Auto Attendant

You can add greetings, set up menus, and route calls to an answering service, a hunt group, a voicemail box, or a real person. You can create a 24-hour schedule or provide different options when your business is open or closed. You can even route calls based on caller ID attributes to create VIP lists or handle calls from certain area codes differently.

Call Queue

You can set up a call queue so that when incoming calls can't be answered, callers are provided with an automated answer, comfort messages, and music on hold until someone can answer their call.

Call Pickup

You can enhance teamwork and collaboration by creating a call pickup group so users can answer each others calls. When you add users to a call pickup group and a group member is away or busy, another member can answer their calls.

Call Park

You can turn on call park so that users can put a call on hold and pick it up from another phone.

Hunt Group

You may want to set up hunt groups in the following scenarios:

  • A Sales team that wants sequential routing. An incoming call rings one phone, but if there's no answer, the call goes to the next agent in the list.

  • A Support team that wants phones to ring all at once so that the first available agent can take the call.

Paging Group

You can create a paging group so that users can send an audio message to a person, a department, or a team. When someone sends a message to a paging group, the message plays on all devices in the group.

Receptionist Client

Help support the needs of your front-office personnel by providing them with a full set of call control options, large-scale line monitoring, call queuing, multiple directory options and views, Outlook integration, and more.

Users can configure the following features in https://settings.webex.com, which cross-launches into the Calling User Portal.

Table 2. User Configurable Features

Feature

Description

Anonymous Call Rejection

Users can reject incoming calls with blocked caller ID's.

Business Continuity

If users' phones are not connected to the network for any reason (such as power outage, network issues, and so on), users can forward incoming calls to a specific phone number.

Call Forwarding

Users can forward incoming calls to another phone.

Call Forwarding Selective

Users can forward calls at specific times from specific callers. This setting will take precedence over Call Forwarding.

Call Notify

Users can send themselves an email when they receive a call according to predefined criteria such as phone number or date and time.

Call Waiting

Users can allow answering of additional incoming calls.

Do Not Disturb

Users can temporarily let all calls to go directly to voicemail.

Office Anywhere

Users can use their selected phones ("Locations") as an extension of their business phone number and dial plan.

Priority Alert

Users can ring their phones with a distinctive ring when predefined criteria are met, such as phone number or date and time.

Remote Office

Users can make calls from a remote phone and have it appear from their business line. In addition, any incoming calls to their business line will ring on this remote phone.

Selective Call Acceptance

Users can accept calls at specific times from specific callers.

Selective Call Rejection

Users can reject calls at specific times from specific callers.

Sequential Ring

Ring up to 5 devices one after another for incoming calls.

Simultaneous Ring

Ring users' and others (“call recipients“) numbers at the same time for incoming calls.

Provisioning Services, Devices, and Users in Control Hub, Cross-Launch to Detailed Configuration in Calling Admin Portal

Cisco Webex Control Hub (https://admin.webex.com) is a management portal that integrates with Webex Calling to streamline your orders and configuration, and centralize your management of the bundled offer—Webex Calling, Webex, and Webex Meetings.

Control Hub is the central point for provisioning all services, devices, and users. You can do first time setup of your calling service, register MPP phones to the cloud (using MAC address), configure users by associating devices, adding numbers, services, calling features, and so on. Also, from Control Hub, you can cross-launch to the Calling Admin Portal for more detailed configuration of features, devices, and users. Provisioning of any additional services (Webex Meetings or Teams) also happens in Control Hub.

The Calling Admin Portal provides customers with access to advanced configuration of calling features as well as a quick view about service assurance. Service assurances provides call quality metrics across multiple locations within their business units by indicating whether the calls are good, fair, or poor quality. Receiving immediate feedback about call quality enables partners and customer administrators to offer the highest quality of services to their customers.

User Experience

Users have access to the following interfaces:

Take a Tour of Cisco Webex Control Hub

Control Hub is your single go-to, web-based interface for managing your organization, managing your users, assigning services, analyzing adoption trends and call quality, and more.

To get your organization up and running, we recommend that you invite a few users to join Webex by entering their email addresses in the Control Hub. Encourage people to use the services you provide, including calling, and to give you feedback about their experience. When you're ready, you can always add more users.


We recommend that you use the latest desktop version of Google Chrome or Mozilla Firefox to access Control Hub. Browsers on mobile devices and other desktop browsers may produce unexpected results.

Use the information presented below as a high-level summary of what to expect when getting your organization set up with services. For more detailed information, see the individual chapters for step-by-step instructions.

Get Started

After your partner creates your account, you'll receive a welcome email. Click the Getting Started link in the email, using Chrome or Firefox to access Control Hub. The link automatically signs you in with your administrator email address. Next, you'll be prompted to create your administrator password.

First Time Wizard for Trials

If your partner has registered you for a trial, the setup wizard automatically starts after you sign in to Control Hub. The wizard walks you through the basic settings to get your organization up and running with Cisco Webex Calling, among other services. You can set up and review your Calling settings before finishing the wizard walkthrough.

Review Your Settings

When Control Hub loads, you can review your settings.

Add Users

Now that you have set up your services, you're ready to add people from your company directory. Go to Users and click Manage Users.

If you use Microsoft Active Directory, we recommend that you enable Directory Synchronization first and then decide how you want to add users. Click Next and follow the instructions to set up Cisco Directory Connector.

Set Up Single Sign On (SSO)

Webex uses basic authentication. You can choose to set up SSO so that users authenticate with your Enterprise Identity Provider using their Enterprise credentials, rather than a separate password stored and managed in Webex.

Go to Settings, scroll to Authentication, click Modify, and then select Integrate a 3rd-party identity provider.

Assign Services to Users

You must assign services to the users that you've added so that people can start using Webex.

Go to Users, click Manage Users, select Export and import users with a CSV file, and then click Export.

In the file you download, simply add True for the services that you want to assign to each of your users.

Import the completed file, click Add and remove services, and then click Submit. You're now ready to configure calling features, register devices that can be shared in a common place, and register and associate devices with users.

Empower Your Users

Now that you've added users and they've been assigned services, they can start using their supported Multiplatform Phones (MPPs) for Webex Calling and Webex for messaging and meetings. Encourage them to use Cisco Webex Settings as a one-stop shop for the access.

Role of the Local Gateway

The local gateway is an enterprise or partner-managed edge device for Public Switch Telephony Network (PSTN) interworking and legacy public branch exchange (PBX) interworking (including Unified CM).

You can use Cisco Webex Control Hub to assign a local gateway to a location, after which Control Hub provides parameters that you can configure on the CUBE. These steps register the local gateway with the cloud, and then PSTN service is provided through the gateway to Webex Calling users in a specific location.

To specify and order a Local Gateway, read the Local Gateway ordering guide.

Supported Local Gateway Deployments for Webex Calling

The following basic deployments are supported:

The local gateway can be deployed standalone or in deployments where integration into Cisco Unified Communications Manager is required.

Local Gateway Deployments Without On-Premises IP PBX

Standalone Local Gateway Deployments

This figure shows a Webex Calling deployment without any existing IP PBX and is applicable to a single location or a multi-location deployment.

For all calls that do not match your Webex Calling destinations, Webex Calling sends those calls to the local gateway that is assigned to the location for processing. The local gateway routes all calls that are coming from Webex Calling to the PSTN and in the other direction, PSTN to Webex Calling.

The PSTN gateway can be a dedicated platform or coresident with the local gateway. As in the following figure, we recommend the dedicated PSTN gateway variant of this deployment; it may be used if the existing PSTN gateway cannot be used as a Webex Calling local gateway.

Coresident Local Gateway Deployment

The local gateway can be IP based, connecting to an ITSP using a SIP trunk, or TDM based using an ISDN or analog circuit. The following figure shows a Webex Calling deployment where the local gateway is coresident with the PSTN GW/SBC.

Local Gateway Deployments With On-Premises Unified CM PBX

Integrations with Unified CM are required in the following cases:

  • Webex Calling-enabled locations are added to an existing Cisco UC deployment where Unified CM is deployed as the on-premises call control solution

  • Direct dialing between phones registered to Unified CM and phones in Webex Calling locations is required.

This figure shows a Webex Calling deployment where the customer has an existing Unified CM IP PBX.

BroadCloud sends calls that do not match the customer’s Webex Calling destinations to the local gateway. This includes PSTN numbers and Unified CM internal extensions, which BroadCloud cannot see. The local gateway routes all calls that are coming from BroadCloud to Unified CM and vice versa. Unified CM then routes incoming calls to local destinations or to the PSTN as per the existing dial plan. The Unified CM dial plan normalizes numbers as +E.164. The PSTN gateway may be a dedicated one or co-resident with the local gateway.

Dedicated PSTN Gateway

The dedicated PSTN gateway variant of this deployment as shown in this diagram is the recommended option and may be used if the existing PSTN gateway cannot be used as a Webex Calling local gateway.

Coresident PSTN Gateway

This figure shows a Webex Calling deployment with a Unified CM where the local gateway is coresident with the PSTN gateway/SBC.

BroadCloud routes all calls that do not match the customer’s Webex Calling destinations to the local gateway that is assigned to the location. This includes PSTN destinations and on-net calls towards Unified CM internal extensions. The local gateway routes all calls to Unified CM. Unified CM then routes calls to locally-registered phones or to the PSTN through the local gateway, which has PSTN/SBC functionality co-located.

Call Routing Considerations

Calls From Webex Calling to Unified CM

The Webex Calling routing logic works like this: if the number that is dialed on a Webex Calling endpoint cannot be routed to any other destination within the same customer in BroadCloud, then the call is sent to the local gateway for further processing. All off-net (outside of BroadCloud) calls are sent to the local gateway.

For a Webex Calling deployment without integration into an existing Unified CM, any off-net call is considered a PSTN call. When combined with Unified CM, an off-net call can still be an on-net call to any destination hosted on Unified CM or a real off-net call to a PSTN destination. The distinction between the latter two call types is determined by the Unified CM and depends on the enterprise dial plan that is provisioned on Unified CM.

The following figure shows a Webex Calling user dialing a national number in the US.

Unified CM now based on the configured dial plan routes the call to a locally registered endpoint on which the called destination is provisioned as directory number. For this the Unified CM dial plan needs to support routing of +E.164 numbers.

Calls From Unified CM to Webex Calling

To enable call routing from Unified CM to Webex Calling on Unified CM a set of routes need to be provisioned to define the set of +E.164 and enterprise numbering plan addresses in Webex Calling.

With these routes in place both the call scenarios shown in the following figure are possible.

If a caller in the PSTN calls a DID number that is assigned to a Webex Calling device, then the call is handed off to the enterprise through the enterprise’s PSTN gateway and then hits Unified CM. The called address of that call matches one of the Webex Calling routes that is provisioned in Unified CM and the call is sent to the local gateway. (The called address must be in +E.164 format when sent to the local gateway.) The BroadCloud routing logic then makes sure that the call is sent to the intended Webex Calling device, based on DID assignment.

Also, calls originating from Unified CM registered endpoints, targeted at destinations in Webex Calling, are subject to the dial plan that is provisioned on Unified CM. Typically, this dial plan allows the users to use common enterprise dialing habits to place calls. These habits do not necessarily only include +E.164 dialing. Any dialing habit other than +E.164 must be normalized to +E.164 before the calls is sent to the local gateway to allow for correct routing in BroadCloud.

Class of Service (CoS)

Implementing tight class of service restrictions is always recommend for various reasons including avoiding call loops and preventing toll fraud. In the context of integrating Webex Calling Local Gateway with Unified CM class of service we need to consider class of service for:

  • Devices registered with Unified CM

  • Calls coming into Unified CM from the PSTN

  • Calls coming into Unified CM from BroadCloud

Devices registered with Unified CM

Adding the Webex Calling destinations as a new class of destinations to an existing CoS setup is pretty straight forward: permission to call to Webex Calling destinations typically is equivalent to the permission to call on-premise (including inter-site) destinations.

If an enterprise dial-plan already implements an “(abbreviated) on-net inter-site” permission then there already is a partition provisioned on Unified CM which we can use and provision all the known on-net Webex Calling destinations in the same partition.

Otherwise, the concept of “(abbreviated) on-net inter-site” permission does not exist yet, then a new partition (for example “onNetRemote”) needs to be provisioned, the Webex Calling destinations are added to this partition, and finally this new partition needs to be added to the appropriate calling search spaces.

Calls coming into Unified CM from the PSTN

Adding the Webex Calling destinations as a new class of destinations to an existing CoS setup is pretty straight forward: permission to call to Webex Calling destinations typically is equivalent to the permission to call on-premise (including inter-site) destinations.

If an enterprise dial-plan already implements an “(abbreviated) on-net inter-site” permission then there already is a partition provisioned on Unified CM which we can use and provision all the known on-net Webex Calling destinations in the same partition.

Otherwise, the concept of “(abbreviated) on-net inter-site” permission does not exist yet, then a new partition (for example “onNetRemote”) needs to be provisioned, the Webex Calling destinations are added to this partition, and finally this new partition needs to be added to the appropriate calling search spaces.

Calls coming into Unified CM from BroadCloud

Calls coming in from the PSTN need access to all Webex Calling destinations. This requires adding the above partition holding all Webex Calling destinations to the calling search space used for incoming calls on the PSTN trunk. The access to Webex Calling destinations comes in addition to the already existing access.

While for calls from the PSTN access to Unified CM DIDs and Webex Calling DIDs is required calls originating in Webex Calling need access to Unified CM DIDs and PSTN destinations.

Figure 1. Differentiated CoS for calls from PSTN and Webex Calling

This figure compares these two different classes of service for calls from PSTN and BroadCloud. The figure also shows that if the PSTN gateway functionality is collocated with the Local Gateway, then two trunks are required from the combined PSTN GW and Local Gateway to Unified CM: one for calls originating in the PSTN and one for calls originating in BroadCloud. This is driven by the requirement to apply differentiated calling search spaces per traffic type. With two incoming trunks on Unified CM this can easily be achieved by configuring the required calling search space for incoming calls on each trunk

Dial Plan Integration

This guide assumes an existing installation that is based on best current practices in the “Preferred Architecture for Cisco Collaboration On-Premises Deployments, CVD.” The latest version is available at https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/products-implementation-design.

The recommended dial plan design follows the design approach that is documented in the Dial Plan chapter of the latest version of the Cisco Collaboration System SRND available at https://www.cisco.com/go/ucsrnd.

Figure 2. Recommended Dial Plan

This figure shows an overview of the recommended dial plan design. Key characteristics of this dial plan design include:

  • All directory numbers that are configured on Unified CM are in +E.164 format.

  • All directory numbers reside the same partition (DN) and are marked urgent.

  • Core routing is based on +E.164.

  • All non-+E.164 dialing habits (for example, abbreviated intrasite dialing and PSTN dialing using common dialing habits) are normalized (globalized) to +E.164 using dialing normalization translation patterns.

  • Dialing normalization translation patterns use translation pattern calling search space inheritance; they have the “Use Originator's Calling Search Space” option set.

  • Class of service is implemented using site and class of service-specific calling search spaces.

  • PSTN access capabilities (for example access to international PSTN destinations) are implemented by adding partitions with the respective +E.164 route patterns to the calling search space defining class of service.

Reachability to BroadCloud

Figure 3. Adding BroadCloud destination to the dial plan

To add reachability for BroadCloud destinations to this dial plan, a partition representing all BroadCloud destinations must be created (“BroadCloud”) and a +E.164 route pattern for each DID range in BroadCloud is added to this partition. This route pattern references a route list with only one member: the route group with the SIP trunk to the Local Gateway for calls to BroadCloud. Because all dialed destinations are normalized to +E.164 either using dialing normalization translation patterns for calls originating from Unified CM registered endpoints or inbound called party transformations for calls originating from the PSTN this single set of +E.164 route patterns is enough to achieve reachability for destinations in BroadCloud independent of the dialing habit used.

If, for example, a user dials “914085550165”, then the dialing normalization translation pattern in partition “UStoE164” normalizes this dial string to “+14085550165” which then matches the route pattern for a BroadCloud destination in partition “BroadCloud.” The Unified CM ultimately sends the call to the local gateway.

Add Abbreviated Intersite Dialing

Figure 4. Adding Abbreviated Intersite Dialing

The recommended way to add abbreviated intersite dialing to the reference dial plan is to add dialing normalization translation patterns for all sites under the enterprise numbering plan to a dedicated partition (“ESN”, Enterprise Significant Numbers). These translation patterns intercept dial strings in the format of the enterprise numbering plan and normalize the dialed string to +E.164.

To add enterprise abbreviated dialing to BroadCloud destinations, you add the respective dialing normalization translation pattern for the BroadCloud location to the “BroadCloud” partition (for example “8101XX” in the diagram). After normalization, the call again is sent to BroadCloud after matching the route pattern in the “BroadCloud” partition.

We do not recommend adding the abbreviated dialing normalization translation pattern for BroadCloud calls to the “ESN” partition, because this configuration may create undesired call routing loops.

Difference between Webex Calling for Service Providers and Value Added Resellers

There are two separate calling offers that leverage the same Webex Calling platform. One offer is for service providers (SPs) and their customers while the other offer is for value added resellers (VARs) and their customers. For the most part, the offers are identical and as such, we refer to them generically as Webex Calling. However, there are a couple differences and where we need to call out those differences, we'll make sure you know whether they apply to SPs or VARs.

While both offers are administered in Control Hub with cross-launches into the Calling Admin Portal, here are some key differences.

SPs can brand their calling portals and apps and must bundle and provide their own PSTN services to their customers or leverage a local gateway deployment. SPs must also provide their own Tier 1 support.

VARs, on the other hand, use the branding provided by Cisco. VARs are not regulated service providers and cannot provide PSTN service. PSTN service must be leveraged through an enterprise local gateway deployment. VARs can also provide their own Tier 1 support or use Cisco's. Both calling offers provide service assurance through media quality metrics and can bundle Webex and Webex Meetings together with their calling applications.

Protocol Handlers for Calling

Cisco Webex Calling registers the following protocol handlers with the operating system to enable click-to-call functionality from web browsers or other application. The following protocols start an audio or video call in Webex Teams when it's the default calling application on Mac or Windows:

  • CLICKTOCALL: or CLICKTOCALL://

  • SIP: or SIP://

  • TEL: or TEL://

  • WEBEXTEL: or WEBEXTEL://

Protocol Handlers for Windows

Other apps can register for the protocol handlers before the Webex app. In Windows 10, the system window to ask users to select which app to use to launch the call. The user preference can be remembered if the user checks Always use this app.

If users need to reset the default calling app settings so that they can pick Webex, you can instruct them to change the protocol associations for Webex in Windows 10:

  1. Open the Default app settings system settings, click Set defaults by app,and then choose Webex.

  2. For each protocol, choose Webex.

Protocol Handlers for Mac

On Mac OS, if other apps registered to the calling protocols before Webex, users must configure their Webex apps to be the default calling option.

In Webex for Mac, users can confirm that Webex is selected for the Start calls with setting under general preferences. They can also check Always connect to Microsoft Outlook if they want to make calls in Webex when they click an Outlook contact's number.