Webex Calling Configuration Workflow
Webex Calling Configuration Workflow
July 18, 2023
Overview

Imagine being able to leverage enterprise-grade cloud calling, mobility, and PBX features, along with Webex App 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.

Introducing Webex Calling

Webex Calling provides the following features and benefits:

  • Calling subscriptions for telephony users and common areas.

  • Secure and reliable cloud services delivered by trusted regional service providers

  • Webex App access for every user, adding rich unified communications and team collaboration services.

  • Webex Meetings as an optional, integrated add-on to provide the premium meetings experiences that enterprise users expect.

  • 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) or Partner or Cisco provided PSTN options.

  • Tier 1 support provided by your partner, next level support provided by Cisco

Control Hub is a web-based management portal that integrates with Webex Calling to streamline your orders and configuration, and centralize your management of the bundled offer—Webex Calling, Webex App, and Webex Meetings.

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 another users 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 IDs.

Business Continuity

If users' phones are not connected to the network for reason such as power outage, network issues, and so on, then the 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

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 App, and 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.

User Experience

Users have access to the following interfaces:

Customer Administrators

As a customer administrator on a trial or paid subscription to Webex Calling, you can set up your organization in Control Hub by adding locations, licenses, phone numbers, Calling features, users, and Workspaces (Room Devices that register to the Webex cloud). You can manage all these components from there as well.

Partners

As a partner service provider, you can brand, market, and sell Webex Calling to your customers. You can set up and extend trials, deploy services for your customers, and create and provision orders for your customers.

Availability

See the Webex Calling header in the Where is Cisco Webex Available article for countries where Webex Calling is available for sale.

Overview

Webex Calling now includes a dedicated cloud instance option based on the Cisco Unified Communications Manager architecture. Dedicated Instance is integrated with Webex Calling and takes advantage of Webex platform services, to bring centralized administration as well as applicable cloud innovation, developed anywhere on the Webex platform, to enhance the calling experience. Dedicated Instance also supports older Cisco endpoints, or existing integrations that are part of critical business workflows.

The Dedicated Instance add-on for Webex Calling includes:

  • Cisco Unified Communications Manager

  • Cisco Unified IM and Presence

  • Cisco Unified Unity Connection

  • Cisco Expressway

  • Cisco Emergency Responder (Americas region only)

  • Cisco Session Management Edition (SME) (Optional)

Extended ROI – Dedicated Instance supports the same voice and video endpoints as the associated UC Manager release, eliminating the requirement to refresh all customer endpoints when migrating to the cloud and extending the ROI of these assets.

Basic Inter-Op – Dedicated Instance is integrated with Webex Calling for call routing through the Webex platform. Customers have the flexibility to distribute users across both Dedicated Instance and Webex Calling, and adjust over time as needed to address their cloud calling business requirements.


Customers who split users across platforms will experience different features. The calling features aren’t harmonized between Dedicated Instance and Webex Calling. For example, Webex Calling users can’t be part of a hunt group on Dedicated Instance.

Take a Tour of 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 App 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 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 App 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 App.

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

Webex Calling 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 Webex Calling cannot see. The local gateway routes all calls that are coming from Webex Calling 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.

Webex Calling 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 Webex Calling, then the call is sent to the local gateway for further processing. All off-net (outside of Webex Calling) 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 Webex Calling 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 Webex Calling.

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

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

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 Webex Calling. 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 Webex Calling. 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 here.

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

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

Figure 3. Adding Webex Calling destination to the dial plan

To add reachability for Webex Calling destinations to this dial plan, a partition representing all Webex Calling destinations must be created (“Webex Calling”) and a +E.164 route pattern for each DID range in Webex Calling 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 Webex Calling. 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 Webex Calling 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 Webex Calling destination in partition “Webex Calling.” 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 Webex Calling destinations, you add the respective dialing normalization translation pattern for the Webex Calling location to the “Webex Calling” partition (for example “8101XX” in the diagram). After normalization, the call again is sent to Webex Calling after matching the route pattern in the “Webex Calling” partition.

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

Protocol Handlers for Calling

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 App 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 App, you can instruct them to change the protocol associations for Webex App in Windows 10:

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

  2. For each protocol, choose Webex App.

Protocol handlers for macOS

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

In Webex App for Mac, users can confirm that Webex App 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 App when they click an Outlook contact's number.

October 11, 2023
Prepare Your Environment

Requirements for Calling

Licensing

Webex Calling is available through the Cisco Collaboration Flex Plan. You must purchase an Enterprise Agreement (EA) plan (for all users, including 50% Workspaces devices) or a Named User (NU) plan (some or all users).

Webex Calling provides three license types ("Station Types")

  • Professional—These licenses provide a full feature set for your entire organization. This offer includes unified communications (Webex Calling), mobility (desktop and mobile clients with support for multiple devices), team collaboration in Webex App, and the option to bundle meetings with up to 1000 participants per meeting.

  • Basic—Choose this option if your users need limited features without mobility or unified communications. They'll still get a full-featured voice offer but are limited to a single device per user.


    Basic licenses are only available if you have a Named User subscription. Basic licenses aren’t supported for Enterprise Agreement subscriptions.

  • Workspaces (also known as Common Area)—Choose this option if you're looking for basic dial-tone with a limited set of Calling features appropriate for areas such as break rooms, lobbies, and conference rooms.

This documentation later shows you how to use Control Hub to manage these license distributions across locations in your organization.

Bandwidth Requirements

Each device in a video call requires up to 2 Mbps. Each device in an audio call requires 100 kbps. Phones at idle need minimal bandwidth.

Public Switched Telephone Network (PSTN)

Webex Calling requires PSTN services, choose from these three options:

Local Gateway for premises-based PSTN

Both Value Added resellers (VARs) and Service Providers (SPs) can provide PSTN access to Webex Calling organizations. Local gateway is currently the only option to provide premises-based PSTN access. You can deploy the local gateway as standalone or in integration with the Cisco Unified Communications Manager. See Get Started with local gateway for details.

Supported devices

Webex Calling supports Cisco Multiplatform (MPP) IP Phones. As an administrator, you can register the following phones to the cloud. See the following Help articles for more information:


For a complete list of supported devices for Webex Calling, see Supported Devices for Webex Calling.

Cisco Webex Room, Webex Board, and Desk Devices are supported as devices in a Workspace that you create in the Control Hub. See "Cisco Webex Room, Webex Board, and Desk Devices" in Supported Devices for Webex Calling for more information. However, you can provide these devices with PSTN service by enabling Webex Calling for the Workspace.

Firewall

Meet the firewall requirements as documented in Port Reference Information for Cisco Webex Calling.

Local Gateway Requirements for Webex Calling

General prerequisites

Before you configure a local gateway for Webex Calling, ensure that you:

  • Have a basic knowledge of VoIP principles

  • Have a basic working knowledge of Cisco IOS-XE and IOS-XE voice concepts

  • Have a basic understanding of the Session Initiation Protocol (SIP)

  • Have a basic understanding of Cisco Unified Communications Manager (Unified CM) if your deployment model includes Unified CM

See the Cisco Unified Border Element (CUBE) Enterprise Configuration Guide for details.

Hardware and Software Requirements for Local Gateway

Make sure your deployment has one or more of the local gateways (Cisco CUBE (for IP-based connectivity) or Cisco IOS Gateway (for TDM-based connectivity)) that are in Table 1 of the Local Gateway for Webex Calling Ordering Guide. Additionally, make sure the platform is running a supported IOS-XE release as per the Local Gateway Configuration Guide.

Certificate and Security Requirements for Local Gateway

Webex Calling requires secure signaling and media. The local gateway performs the encryption, and a TLS connection must be established outbound to the cloud with the following steps:

  • The LGW must be updated with the CA root bundle from Cisco PKI

  • A set of SIP digest credentials from Control Hub’s Trunk configuration page are used to configure the LGW (the steps are part of the configuration that follows)

  • CA root bundle validates presented certificate

  • Prompted for credentials (SIP digest provided)

  • The cloud identifies which local gateway is securely registered

Firewall, NAT Traversal, and Media Path Optimization Requirements for Local Gateway

In most cases, the local gateway and endpoints can reside in the internal customer network, using private IP addresses with NAT. The enterprise firewall must allow outbound traffic (SIP, RTP/UDP, HTTP) to specific IP addresses/ports, covered in Port Reference Information.

If you want to utilize Media Path Optimization with ICE, the local gateway’s Webex Calling facing interface must have a direct network path to and from the Webex Calling endpoints. If the endpoints are in a different location and there is no direct network path between the endpoints and the local gateway’s Webex Calling facing interface, then the local gateway must have a public IP address assigned to the interface facing Webex Calling for calls between the local gateway and the endpoints to utilize media path optimization. Additionally, it must be running IOS-XE version 16.12.5.

July 06, 2023
Configure Cisco Webex Calling for Your Organization

Customize your organization for Webex Calling in Control Hub. After activating your first location through the First Time Setup Wizard, you can set up and manage additional locations, trunk assignment and usage, dial plan options, users, devices, and features.

The first step to get your Webex Calling services up and running is to complete the First Time Setup Wizard (FTSW). Once the FTSW is completed for your first location, it doesn’t need to be completed for additional locations.

1

Click the Getting Started link in the Welcome email you receive.


 

Your administrator email address is automatically used to sign in to Control Hub, where you'll be prompted to create your administrator password. After you sign in, the setup wizard automatically starts.

2

Review and accept the terms of service.

3

Review your plan and then click Get Started.


 

Your account manager is responsible for activating the first steps for FTSW. Contact your account manager if you receive a “Cannot Setup Your Call” notice, when you select Get Started.

4

Select the country that your data center should map to, and enter the customer contact and customer address information.

5

Click Next: Default Location.

6

Choose from the following options:

  • Click Save and Close if you’re a partner administrator and you want the customer administrator to complete the provisioning of Webex Calling.
  • Fill out the necessary location information. After you create the location in the wizard, you can create more locations later.

 

After you complete the setup wizard make sure you add a main number to the location you create.

7

Make the following selections to apply to this location:

  • Announcement Language—For audio announcements and prompts for new users and features.
  • Email Language—For email communication for new users.
  • Country
  • Time Zone
8

Click Next.

9

Enter an available Cisco Webex SIP address and click Next and select Finish.

Before you begin

To create a new location, prepare the following information:

  • Location address

  • Desired phone numbers (optional)

1

Log in to Control Hub at https://admin.webex.com, go to Management > Location.

Note that new locations will be hosted in the regional data center that corresponds to the country you selected using the First Time Setup Wizard.

2

Configure the settings of the location:

  • Location Name—Enter a unique name to identify the location.
  • Country/Region—Choose a country to tie the location to. For example, you can create one location (headquarters) in the United States and another (branch) in the United Kingdom. The country that you choose determines the address fields that follow. The ones documented here use the U.S. address convention as an example.
  • Location Address—Enter the location's main mailing address.
  • City/Town—Enter a city for this location.
  • State/Province/Region—From the drop-down, choose a state.
  • ZIP/Postal Code—Enter the ZIP or postal code.
  • Announcement Language—Choose the language for audio announcements and prompts for new users and features.
  • Email Language—Choose the language for the email communication with new users.
  • Time zone—Choose the time zone for the location.
3

Click Save and then choose Yes/ No to add numbers to the location now or later.

4

If you clicked Yes, choose one of the following options:

  • Cisco PSTN —Choose this option if you'd like a Cloud PSTN solution from Cisco. The Cisco Calling Plan is a full PSTN replacement solution that provides emergency calling, inbound, and outbound domestic and international calling, and allows you to order new PSTN numbers or port existing numbers to Cisco.


     

    The Cisco PSTN option is only visible under the following conditions:

    • You have purchased at least one committed Cisco Calling Plan OCP (Outbound Calling Plan).

    • Your location is in a country where the Cisco Calling Plan is supported.

    • Your location is new. Pre-existing locations that have had other PSTN capabilities assigned aren't eligible for the Cisco Calling Plan at this time. Open a support case for guidance.

    • You’re hosted in a Webex Calling Data Center in a region in which the Cisco Calling Plan is supported.

  • Cloud Connected PSTN—Choose this option if you’re looking for a cloud PSTN solution from one of the many Cisco CCP partners or if the Cisco Calling Plan isn't available in your location. CCP partners offer PSTN replacement solutions, extensive global coverage, and a broad and varied range of features, packaging, and pricing.

     

    CCP partners and the geographic coverage are listed here. Only partners that support your location’s country are displayed. Partners are listed either with a logo, or as a brief string of text followed by a region, in brackets (Example: (EU), (US) or (CA)). Partners listed with a logo always offer Regional Media for CCP. For partners displaying as a string, choose the region closest to the country of your location to ensure Regional Media for CCP.

    If you see the option to Order numbers now under a listed provider, we recommend that you choose that option so that you can benefit from integrated CCP. Integrated CCP enables procuring and provisioning of phone numbers in Control Hub on a single pane of glass. Non-integrated CCP requires you to procure your phone numbers from the CCP partner outside of Control Hub.

  • Premises-based PSTN (Local Gateway)—You can choose this option if you want to keep your current PSTN provider or you want to connect non-cloud sites with cloud sites.

The choice of PSTN option is at each location level (each location has only one PSTN option). You can mix and match as many options as you’d like for your deployment, but each location will have one option. Once you’ve selected and provisioned a PSTN option, you can change it by clicking Manage in the location PSTN properties. Some options, such as Cisco PSTN, however, may not be available after another option has been assigned. Open a support case for guidance.

5

Choose whether you want to activate the numbers now or later.

6

If you selected non-integrated CCP or Premises-based PSTN, enter Phone Numbers as comma-separated values, and then click Validate.

Numbers are added for the specific location. Valid entries move to the Validated Numbers field, and invalid entries remain in the Add Numbers field accompanied by an error message.

Depending on the location's country, the numbers are formatted according to local dialing requirements. For example, if a country code is required, you can enter numbers with or without the code and the code is prepended.

7

Click Save.

What to do next

After you create a location, you can enable emergency 911 services for that location. See RedSky Emergency 911 Service for Webex Calling for more information.

Before you begin


Get a list of the users and workspaces associated with a location: Go to Services > Calling > Numbers and from the drop-down menu, select the location to be deleted. You must delete those users and workspaces before you delete the location.

1

Log in to Control Hub at https://admin.webex.com, go to Management > Location.

2

Click in the Actions column beside the location that you'd like to delete.

3

Choose Delete Location, and confirm that you want to delete that location.

It typically takes a couple of minutes for the location to be permanently deleted, but it could take up to an hour. You can check the status by clicking beside the location name and selecting Deletion Status.

You can change your PSTN setup, the name, time zone, and language of a location after it's created. Keep in mind though that the new language only applies to new users and devices. Existing users and devices continue to use the old language.


For existing locations, you can enable emergency 911 services. See RedSky Emergency 911 Service for Webex Calling for more information.

1

Log in to Control Hub at https://admin.webex.com, go to Management > Location.

If you see a Caution symbol next to a location, it means that you haven't configured a telephone number for that location yet. You can't make or receive any calls until you configure that number.

2

(Optional) Under PSTN Connection, select either Cloud Connected PSTN or Premises-based PSTN (local gateway), depending on which one you've already configured. Click Manage to change that configuration, and then acknowledge the associated risks by selecting Continue. Then, choose one of the following options and click Save:

  • Cisco PSTN —Choose this option if you'd like a Cloud PSTN solution from Cisco. The Cisco Calling Plan is a full PSTN replacement solution that provides emergency calling, inbound, and outbound domestic and international calling, and allows you to order new PSTN numbers or port existing numbers to Cisco.


     

    The Cisco PSTN option is only visible under the following conditions:

    • You have purchased at least one committed Cisco Calling Plan OCP (Outbound Calling Plan).

    • Your location is in a country where the Cisco Calling Plan is supported.

    • Your location is new. Currently, Pre-existing locations that have had other PSTN capabilities assigned aren't eligible for the Cisco Calling Plan. Open a support case for guidance.

    • You’re hosted in a Webex Calling Data Center in a region in which the Cisco Calling Plan is supported.

  • Cloud Connected PSTN—Choose this option if you’re looking for a cloud PSTN solution from one of the many Cisco CCP partners or if the Cisco Calling Plan isn't available in your location. CCP partners offer PSTN replacement solutions, extensive global coverage, and a broad and varied range of features, packaging, and pricing.

     

    CCP partners and the geographic coverage are listed here. Only partners that support your location’s country are displayed. Partners are listed either with a logo, or as a brief string of text followed by a region, in brackets (Example: (EU), (US) or (CA)). Partners listed with a logo always offer Regional Media for CCP. For partners displaying as a string, choose the region closest to the country of your location to ensure Regional Media for CCP.

    If you see the option to Order numbers now under a listed provider, we recommend that you choose that option so that you can benefit from integrated CCP. Integrated CCP enables procuring and provisioning of phone numbers in Control Hub on a single pane of glass. Non-integrated CCP requires you to procure your phone numbers from the CCP partner outside of Control Hub.

  • Premises-based PSTN (Local Gateway)—You can choose this option if you want to keep your current PSTN provider or you want to connect noncloud sites with cloud sites.

     

    Webex Calling customers with locations that are previously configured with a Local Gateway will automatically be converted to premises-based PSTN with a corresponding trunk.

3

Select the Main Number at which the location's main contact can be reached.

4

(Optional) Under Emergency Calling, you can select Emergency Location Identifier to assign to this location.


 

This setting is optional and is only applicable for countries that require it.

In some countries (Example: France), regulatory requirements exist for cellular radio systems to establish the identity of the cell when you make an emergency call and is made available to the emergency authorities. Other countries like the U.S and Canada implement location determination using other methods. For more information, see Enhanced Emergency Calling.

Your emergency call provider may need information about the access network and is achieved by defining a new private SIP extension header, P-Access-Network-Info. The header carries information relating to the access network.

When you set the Emergency Location Identifier for a Location, the location value is sent to the provider as part of the SIP message. Contact your emergency call provider to see if you require this setting and use the value that is provided by your emergency call provider."

5

Select the Voicemail Number that users can call to check their voicemail for this location.

6

(Optional) Click the pencil icon at the top of the Location page to change the Location Name, Announcement Language, Email Language, Time Zone, or Address as needed, and then click Save.


 

Changing the Announcement Language takes effect immediately for any new users and features added to this location. If existing users and/or features should also have their announcement language changed, when prompted, select Change for existing users and workspaces or Change for existing features. Click Apply. You can view progress on the Tasks page. You can't make any more changes until this is complete.


 

Changing the Time Zone for a location doesn't update the time zones of the features associated with the location. To edit the time zones for features like auto attendant, hunt group, and call queue, go to the General Settings area of the specific feature you would like to update the time zone for and edit and save there.

These settings are for internal dialing and are also available in the first-time setup wizard. As you change your dial plan, the example numbers in Control Hub update to show these changes.


You can configure outgoing calling permissions for a location. See these steps to configure outgoing calling permissions.

1

Log in to Control Hub at https://admin.webex.com/, go to Services > Calling > Service Settings, and then scroll to Internal Dialing.

2

Configure the following optional dialing preferences, as needed:

  • Location Routing Prefix Length—We recommend this setting if you have multiple locations. You can enter a length of 2-7 digits. If you have multiple locations with the same extension, users must dial a prefix when calling between locations. For example, if you have multiple stores, all with the extension 1000, you can configure a routing prefix for each store. If one store has a prefix of 888, you'd dial 8881000 to reach that store.

  •  

    Routing prefix lengths include the steering digit. For example, if you set the routing prefix to four, only three digits can be used to specify the site.

  • Steering Digit in Routing Prefix— Choose the number which will be set as the first digit of every routing prefix.
  • Internal Extension Length—You can enter 2-6 digits and the default is 2.

     

    After you increase your extension length, existing speed dials to internal extensions are not automatically updated.

3

Specify internal dialing for specific locations. Go to Services > Call > Locations, select a location, scroll to Dialing, and then change internal and external dialing as needed:

  • Internal Dialing—Specify the routing prefix that users at other locations need to dial in order to contact someone at this location. The routing prefix of each location must be unique. We recommend that the prefix length matches the length set at the organization level but it must be between 2-7 digits long.
  • External Dialing—Optionally, you can choose an outbound dial digit that users must dial to reach an outside line. The default is None and you can leave it if you don't require this dialing habit. If you do decide to use this feature, we recommend that you use a different number from your organization's steering digit.

     

    Users can include the outbound dial digit when making external calls to mimic how they dialed on legacy systems. However, all users can still make external calls without the outbound dial digit.

Impact to users:

  • Users must restart their phones for changes in dialing preferences to take effect.

  • User extensions should not start with the same number as the location's steering digit or outbound dial digits.

If you're a value added reseller, you can use these steps to start local gateway configuration in Control Hub. When this gateway is registered to the cloud, you can use it on one or more of your Webex Calling locations to provide routing toward an enterprise PSTN service provider.


A location that has a local gateway can't be deleted when the local gateway is being used for other locations.

Follow these steps to create a trunk in Control Hub.

Before you begin

  • Once a location is added, and before configuring premises-based PSTN for a location, you must create a trunk.

  • Create any locations and specific settings and numbers to each one. Locations must exist before you can add a premises-based PSTN.

  • Understand the Premises-based PSTN (local gateway) requirements for Webex Calling.

  • You can't choose more than one trunk for a location with premises-based PSTN, but you can choose the same trunk for multiple locations.

1

Log in to Control Hub at https://admin.webex.com, go to Services > Calling > Call Routing, and select Add Trunk.

2

Select a location.

3

Name the trunk and click Save.


 

The name can't be longer than 24 characters.

What to do next

You're presented with the relevant parameters that you'll need to configure on the trunk. You'll also generate a set of SIP digest credentials to secure the PSTN connection.

Trunk information appears on the screen Register Domain, Trunk Group OTG/DTG, Line/Port, and Outbound Proxy Address.

We recommend that you copy this information from Control Hub and paste it into a local text file or document so you can refer to it when you're ready to configure the premises-based PSTN.

If you lose the credentials, you must generate them from the trunk information screen in Control Hub. Click Retrieve Username and Reset Password to generate a new set of authentication credentials to use on the trunk.

1

Log in to Control Hub at https://admin.webex.com, go to Management > Location.

2

Select a location to modify and click Manage.

3

Select Premises-based PSTN and click Next.

4

Choose a trunk from the drop-down menu.


 

Visit the trunk page to manage your trunk group choices.

5

Click the confirmation notice, then click Save.

What to do next

You must take the configuration information that Control Hub generated and map the parameters into the local gateway (for example, on a Cisco CUBE that sits on the premises). This article walks you through this process. As a reference, see the following diagram for an example of how the Control Hub configuration information (on the left) maps onto parameters in the CUBE (on the right):

After you successfully complete the configuration on the gateway itself, you can return to Services > Call > Locations in Control Hub and the gateway that you created will be listed in the location card that you assigned it to with a green dot to the left of the name. This status indicates that the gateway is securely registered to the calling cloud and is serving as the active PSTN gateway for the location.

1

Log in to Control Hub at https://admin.webex.com, select the building icon .

2

Select the Subscriptions tab, and then click Purchase Now.

An email is sent to your partner letting them know that you're interested in converting to a paid subscription.

You can use Control Hub to set the priority of available calling options that users see in Webex App. You can also enable them for single click-to-call. For more information, see: Set calling options for Webex App users.

You can control what calling application opens when users make calls. You can configure the calling client settings, including mixed-mode deployment for organizations with users entitled with Unified CM or Webex Calling and users without paid calling services from Cisco. For more information, see: Set up calling behavior.

September 20, 2023
Implement CUBE High Availability as Local Gateway

Local Gateway (LGW) is the only option to provide premises-based PSTN access for Cisco Webex Calling customers. The objective of this document is to assist you in building a Local Gateway configuration using CUBE high availability, active or standby CUBEs for stateful failover of active calls.

Fundamentals

Prerequisites

Before you deploy CUBE HA as a local gateway for Webex Calling, make sure you have an in-depth understanding of the following concepts:

The configuration guidelines provided in this article assume a dedicated local gateway platform with no existing voice configuration. If an existing CUBE enterprise deployment is being modified to also utilize the local gateway function for Cisco Webex Calling, pay close attention to the configuration applied to ensure existing call flows and functionalities are not interrupted and make sure you're adhering to CUBE HA design requirements.

Hardware and Software Components

CUBE HA as local gateway requires IOS-XE version 16.12.2 or later and a platform on which both CUBE HA and LGW functions are supported.


The show commands and logs in this article are based on minimum software release of Cisco IOS-XE 16.12.2 implemented on a vCUBE (CSR1000v).

Reference Material

Here are some detailed CUBE HA configuration guides for various platforms:

Webex Calling Solution Overview

Cisco Webex Calling is a collaboration offering that provides a multi-tenant cloud-based alternative to on-premise PBX phone service with multiple PSTN options for customers.

The Local Gateway deployment (represented below) is the focus of this article. Local gateway (Premises-based PSTN) trunk in Webex Calling allows connectivity to a customer-owned PSTN service. It also provides connectivity to an on-premises IP PBX deployment such as Cisco Unified CM. All communication to and from the cloud is secured using TLS transport for SIP and SRTP for media.

The figure below displays a Webex Calling deployment without any existing IP PBX and is applicable to a single or a multi-site deployment. Configuration outlined in this article is based on this deployment.

Layer 2 Box-to-Box Redundancy

CUBE HA layer 2 box-to-box redundancy uses the Redundancy Group (RG) infrastructure protocol to form an active/standby pair of routers. This pair share the same virtual IP address (VIP) across their respective interfaces and continually exchange status messages. CUBE session information is check-pointed across the pair of routers enabling the standby router to take all CUBE call processing responsibilities over immediately if the active router goes out of service, resulting in stateful preservation of signaling and media.


Check pointing is limited to connected calls with media packets. Calls in transit are not check pointed (for example, a trying or ringing state).

In this article, CUBE HA will refer to CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundancy for stateful call preservation

As of IOS-XE 16.12.2, CUBE HA can be deployed as a Local Gateway for Cisco Webex Calling trunk (Premises-based PSTN) deployments and we’ll cover design considerations and configurations in this article. This figure displays a typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment.

Redundancy Group Infra Component

The Redundancy Group (RG) Infra component provides the box-to-box communication infrastructure support between the two CUBEs and negotiates the final stable redundancy state. This component also provides:

  • An HSRP-like protocol that negotiates the final redundancy state for each router by exchanging keepalive and hello messages between the two CUBEs (via the control interface)—GigabitEthernet3 in the figure above.

  • A transport mechanism for checkpointing the signaling and media state for each call from the active to the standby router (via the data interface)—GigabitEthernet3 in the figure above.

  • Configuration and management of the Virtual IP (VIP) interface for the traffic interfaces (multiple traffic interfaces can be configured using the same RG group) – GigabitEthernet 1 and 2 are considered traffic interfaces.

This RG component has to be specifically configured to support voice B2B HA.

Virtual IP (VIP) Address Management for Both Signaling and Media

B2B HA relies on VIP to achieve redundancy. The VIP and associated physical interfaces on both CUBEs in the CUBE HA pair must reside on the same LAN subnet. Configuration of the VIP and binding of the VIP interface to a particular voice application (SIP) are mandatory for voice B2B HA support. External devices such as Unified CM, Webex Calling access SBC, service provider, or proxy, use VIP as the destination IP address for the calls traversing through the CUBE HA routers. Hence, from a Webex Calling point of view, the CUBE HA pairs acts as a single local gateway.

The call signaling and RTP session information of established calls are checkpointed from the active router to the standby router. When the Active router goes down, the Standby router takes over, and continues to forward the RTP stream that was previously routed by the first router.

Calls in a transient state at the time of failover will not be preserved post-switchover. For example, calls that aren't fully established yet or are in the process of being modified with a transfer or hold function. Established calls may be disconnected post-switchover.

The following requirements exist for using CUBE HA as a local gateway for stateful failover of calls:

  • CUBE HA cannot have TDM or analog interfaces co-located

  • Gig1 and Gig2 are referred to as traffic (SIP/RTP) interfaces and Gig3 is Redundancy Group (RG) Control/data interface

  • No more than 2 CUBE HA pairs can be placed in the same layer 2 domain, one with group id 1 and the other with group id 2. If configuring 2 HA pairs with the same group id, RG Control/Data interfaces needs to belong to different layer 2 domains (vlan, separate switch)

  • Port channel is supported for both RG Control/data and traffic interfaces

  • All signaling/media is sourced from/to the Virtual IP Address

  • Anytime a platform is reloaded in a CUBE-HA relationship, it always boots up as Standby

  • Lower address for all the interfaces (Gig1, Gig2, Gig3) should be on the same platform

  • Redundancy Interface Identifier, rii should be unique to a pair/interface combination on the same Layer 2

  • Configuration on both the CUBEs must be identical including physical configuration and must be running on the same type of platform and IOS-XE version

  • Loopback interfaces cannot be used as bind as they are always up

  • Multiple traffic (SIP/RTP) interfaces (Gig1, Gig2) require interface tracking to be configured

  • CUBE-HA is not supported over a crossover cable connection for the RG-control/data link (Gig3)

  • Both platforms must be identical and be connected via a physical Switch across all likewise interfaces for CUBE HA to work, i.e. GE0/0/0 of CUBE-1 and CUBE-2 must terminate on the same switch and so on.

  • Cannot have WAN terminated on CUBEs directly or Data HA on either side

  • Both Active/Standby must be in the same data center

  • It is mandatory to use separate L3 interface for redundancy (RG Control/data, Gig3). i.e interface used for traffic cannot be used for HA keepalives and checkpointing

  • Upon failover, the previously active CUBE goes through a reload by design, preserving signaling and media

Configure Redundancy on Both CUBEs

You must configure layer 2 box-to-box redundancy on both CUBEs intended to be used in an HA pair to bring up virtual IPs.

1

Configure interface tracking at a global level to track the status of the interface.

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit
VCUBE-1#conf t
VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-1(config-track)#exit
VCUBE-2#conf t
VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-2(config-track)#exit

Track CLI is used in RG to track the voice traffic interface state so that the active route will quite its active role after the traffic interface is down.

2

Configure an RG for use with VoIP HA under the application redundancy sub-mode.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit
VCUBE-1(config)#redundancy
VCUBE-1(config-red)#application redundancy
VCUBE-1(config-red-app)#group 1
VCUBE-1(config-red-app-grp)#name LocalGateway-HA
VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-1(config-red-app-grp)#timers delay 30 reload 60
VCUBE-1(config-red-app-grp)#track 1 shutdown
VCUBE-1(config-red-app-grp)#track 2 shutdown
VCUBE-1(config-red-app-grp)#exit
VCUBE-1(config-red-app)#protocol 1
VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-1(config-red-app-prtcl)#exit
VCUBE-1(config-red-app)#exit
VCUBE-1(config-red)#exit
VCUBE-1(config)#
VCUBE-2(config)#redundancy
VCUBE-2(config-red)#application redundancy
VCUBE-2(config-red-app)#group 1
VCUBE-2(config-red-app-grp)#name LocalGateway-HA
VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-2(config-red-app-grp)#timers delay 30 reload 60
VCUBE-2(config-red-app-grp)#track 1 shutdown
VCUBE-2(config-red-app-grp)#track 2 shutdown
VCUBE-2(config-red-app-grp)#exit
VCUBE-2(config-red-app)#protocol 1
VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-2(config-red-app-prtcl)#exit
VCUBE-2(config-red-app)#exit
VCUBE-2(config-red)#exit
VCUBE-2(config)#

Here's an explanation of the fields used in this configuration:

  • redundancy—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • Delay timer which is the amount of time to delay RG group’s initialization and role negotiation after the interface comes up – Default 30 seconds. Range is 0-10000 seconds

    • Reload—This is the amount of time to delay RG group initialization and role-negotiation after a reload – Default 60 seconds. Range is 0-10000 seconds

    • Default timers are recommended, though these timers may be adjusted to accommodate any additional network convergence delay that may occur during bootup/reload of the routers, in order to guarantee that the RG protocol negotiation takes place after routing in the network has converged to a stable point. For example, if it is seen after failover that it takes up to 20 sec for the new STANDBY to see the first RG HELLO packet from the new ACTIVE, then the timers should be adjusted to ‘timers delay 60 reload 120’ to factor in this delay.

  • control GigabitEthernet3 protocol 1—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

    • Hellotime— Interval between successive hello messages – Default 3 seconds. Range is 250 milliseconds-254 seconds

    • Holdtime—The interval between the receipt of a Hello message and the presumption that the sending router has failed. This duration has to be greater than the hello-time – Default 10 seconds. Range is 750 milliseconds-255 seconds

      We recommend that you configure the holdtime timer to be at least 3 times the value of the hellotime timer.

3

Enable box-to-box redundancy for the CUBE application. Configure the RG from the previous step under voice service voip. This enables the CUBE application to control the redundancy process.

voice service voip
   redundancy-group 1
   exit
VCUBE-1(config)#voice service voip
VCUBE-1(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-1(config-voi-serv)# exit
VCUBE-2(config)#voice service voip
VCUBE-2(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-2(config-voi-serv)# exit

redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. We'll reload the platforms after all the configuration has been applied.

4

Configure the Gig1 and Gig2 interfaces with their respective virtual IPs as shown below and apply the redundancy interface identifier (rii)

VCUBE-1(config)#interface GigabitEthernet1
VCUBE-1(config-if)# redundancy rii 1
VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-1(config)#
VCUBE-1(config)#interface GigabitEthernet2
VCUBE-1(config-if)# redundancy rii 2
VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-2(config)#interface GigabitEthernet1
VCUBE-2(config-if)# redundancy rii 1
VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-2(config-if)# exit
VCUBE-2(config)#
VCUBE-2(config)#interface GigabitEthernet2
VCUBE-2(config-if)# redundancy rii 2
VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-v(config-if)# exit

Here's an explanation of the fields used in this configuration:

  • redundancy rii—Configures the redundancy interface identifier for the redundancy group. Required for generating a Virtual MAC (VMAC) address. The same rii ID value must be used on the interface of each router (ACTIVE/STANDBY) that has the same VIP.


     

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. Configure the RG group, as well as the VIP assigned to this physical interface.


     

    It is mandatory to use a separate interface for redundancy, that is, the interface used for voice traffic cannot be used as control and data interface specified in Step 2 above. In this example, Gigabit interface 3 is used for RG control/data

5

Save the configuration of the first CUBE and reload it.

The platform to reload last is always the Standby.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

After VCUBE-1 boots up completely, save the configuration of VCUBE-2 and reload it.

VCUBE-2#wr
Building configuration...
[OK]
VCUBE-2#reload
Proceed with reload? [confirm]
6

Verify that the box-to-box configuration is working as expected. Relevant output is highlighted in bold.

We reloaded VCUBE-2 last and as per the design considerations; the platform to reload last will always be Standby.


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

Configure a Local Gateway on Both CUBEs

In our example configuration, we’re using the following trunk information from Control Hub to build the Local Gateway configuration on both the platforms, VCUBE-1 and VCUBE-2. The username and password for this setup are as follows:

  • Username: Hussain1076_LGU

  • Password: lOV12MEaZx

1

Ensure that a configuration key is created for the password, with the commands shown below, before it can be used in the credentials or shared secrets. Type 6 passwords are encrypted using AES cipher and this user-defined configuration key.


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

Here is the Local Gateway configuration that will apply to both platforms based on the Control Hub parameters displayed above, save and reload. SIP Digest credentials from Control Hub are highlighted in bold.


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

To display the show command output, we've reloaded VCUBE-2 followed by VCUBE-1, making VCUBE-1 the standby CUBE and VCUBE-2 the active CUBE

2

At any given time, only one platform will maintain an active registration as the Local Gateway with the Webex Calling access SBC. Take a look at the output of the following show commands.

show redundancy application group 1

show sip-ua register status


VCUBE-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#

VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1

3

Now enable the following debugs on VCUBE-1


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message
4

Simulate failover by issuing the following command on the active LGW, VCUBE-2 in this case.


VCUBE-2#redundancy application reload group 1 self

Switchover from the ACTIVE to the STANDBY LGW occurs in the following scenario as well besides the CLI listed above

  • When the ACTIVE router reloads

  • When the ACTIVE router power cycles

  • When any RG configured interface of the ACTIVE router is shutdown for which tracking is enabled

5

Check to see if VCUBE-1 has registered with Webex Calling access SBC. VCUBE-2 would have reloaded by now.


VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 is now the active LGW.

6

Look at the relevant debug log on VCUBE-1 sending a SIP REGISTER to Webex Calling VIA the virtual IP and receiving a 200 OK.


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0
Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0
Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0
Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0
September 13, 2022
Configure Unified CM

You may require an integration with Unified CM if Webex Calling-enabled locations are added to an existing deployment where Unified CM is the on-premises call control solution and if you require direct dialing between phones registered to Unified CM and phones in Webex Calling locations.

Configure SIP Trunk Security Profile for Trunk to Local Gateway

In cases where Local Gateway and PSTN gateway reside on the same device, Unified CM must be enabled to differentiate between two different traffic types (calls from Webex and from the PSTN) that are originating from the same device and apply differentiated class of service to these call types. This differentiated call treatment is achieved by provisioning two trunks between Unified CM and the combined local gateway and PSTN gateway device which requires different SIP listening ports for the two trunks.

Create a dedicated SIP Trunk Security Profile for the Local Gateway trunk with the following settings:

Setting Value
Name Unique Name, such as Webex
Description Meaningful description, such as Webex SIP Trunk Security Profile
Incoming Port Needs to match port used in local gateway config for traffic to/from Webex: 5065

Configure SIP Profile for the Local Gateway Trunk

Create a dedicated SIP Profile for the Local Gateway trunk with the following settings:

Setting Value
Name Unique Name, such as Webex
Description Meaningful description, such as Webex SIP Profile
Enable OPTIONS Ping to monitor destination status for Trunks with Service Type “None (Default)” Checked

Create a Calling Search Space for Calls From Webex

Create a calling search space for calls originating from Webex with the following settings:

Setting Value
Name Unique Name, such as Webex
Description Meaningful description, such as Webex Calling Search Space
Selected Partitions

DN (+E.164 directory numbers)

ESN (abbreviated inter-site dialling)

PSTNInternational (PSTN access)

onNetRemote (GDPR learned destinations)


 

The last partition onNetRemote is only used in a multi-cluster environment where routing information is exchanged between Unified CM clusters using Intercluster Lookup Service (ILS) or Global Dialplan Replication (GDPR).

Configure a SIP Trunk To and From Webex

Create a SIP trunk for the calls to and from Webex via the Local Gateway with the following settings:

Setting Value
Device Information
DeviceName A unique name, such as Webex
Description Meaningful description, such as Webex SIP Trunk
Run On All Active Unified CM Nodes Checked
Inbound Calls
Calling Search Space The previously defined calling search space: Webex
AAR Calling Search Space A calling search space with only access to PSTN route patterns: PSTNReroute
SIP Information
Destination Address IP address of the Local Gateway CUBE
Destination Port 5060
SIP Trunk Security Profile Previously defined: Webex
SIP Profile Previously defined: Webex

Configure Route Group for Webex

Create a route group with the following settings:

Setting Value
Route Group Information
Route Group Name A unique name, such as Webex
Selected Devices The previously configured SIP trunk: Webex

Configure Route List for Webex

Create a route list with the following settings:

Setting Value
Route List Information
Name A unique name, such as RL_Webex
Description Meaningful description, such as Route list for Webex
Run On All Active Unified CM Nodes Checked
Route List Member Information
Selected Groups Only the previously defined route group: Webex

Create a Partition for Webex Destinations

Create a partition for the Webex destinations with the following settings:

Setting Value
Route List Information
Name Unique name, such as Webex
Description Meaningful description, such as Webex Partition

What to do next

Make sure to add this partition to all calling search spaces that should have access to Webex destinations. You must add this partition specifically to the calling search space that is used as the inbound calling search space on PSTN trunks, so that calls from the PSTN to Webex can be routed.

Configure Route Patterns for Webex Destinations

Configure route patterns for each DID range on Webex with the following settings:

Setting Value
Route Pattern Full +E.164 pattern for the DID range in Webex with the leading “\”. For example: \+140855501XX
Route Partition Webex
Gateway/Route List RL_Webex
Urgent Priority Checked

Configure Abbreviated Intersite Dialing Normalization for Webex

If abbreviated inter-site dialing is required to Webex, then configure dialing normalization patterns for each ESN range on Webex with the following settings:

Setting Value
Translation Pattern ESN pattern for the ESN range in Webex. For example: 80121XX
Partition Webex
Description Meaningful description, such as Webex Normalization Pattern
Use Originator's Calling Search Space Checked
Urgent Priority Checked
Do Not Wait For Interdigit Timeout On Subsequent Hops Checked
Called Party Transformation Mask Mask to normalize the number to +E.164. For example: +140855501XX
January 16, 2024
Configure and Manage Your Users

You must add each and every user in Control Hub in order for them to take advantage of Webex Calling services. The number of users you need to add will determine how you add them in Control Hub, whether you manually add each user by email address or add multiple users using a CSV file. The choice is yours.

March 18, 2024
Configure and Manage Devices

You can assign and manage devices for users and workspaces in Control Hub. Choose to add by the MAC address or by generating an activation code to enter on the device itself.

With Control Hub, you can assign devices to users for personal usage and then register those devices to the cloud.

The devices listed here support Webex Calling. While all these devices can be registered using a MAC address, only the following subset can be registered using an activation code:

  • Cisco IP Phone 6800 Series Multiplatform Phones (Audio phones—6821, 6841, 6851, 6861, 6871)

  • Cisco IP Phone 7800 Series Multiplatform Phones (Audio phones—7811, 7821, 7841, 7861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Audio phones—8811, 8841, 8851, 8861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Video phones—8845, 8865)

  • Cisco IP Conference Phone 7832 and 8832

  • Cisco Video Phone 8875


 

Regarding DECT devices, only DECT base devices (not DECT handsets) are available for assignment in Control Hub. After you assign a base unit to a user, you must then manually pair a DECT handset to that base unit. For more information, see Connect the Handset to the Base Station.

1

From the customer view in https://admin.webex.com, go to one of the following paths:

  • Management > Devices > Add device > Personal Usage > Next. Then search and select the user and choose Cisco IP Phone.

    Or

  • Management > Users. Then, select the user and click Devices > Add device.

2

Choose Personal usage to assign a device to a user and then click Next.

3

Enter either username or the actual name of the phone's owner, choose the user from the results, and then click Next.

4

Choose a device from the drop-down list, and then click Next.

5

Choose one of the following options and then click Save.

  • By Activation Code—Choose this option if you want to generate an activation code that you can share with the device owner. The 16-digit activation code must be manually entered onto the device itself.

     

    Multiplatform phones must have a firmware load of 11.2.3MSR1 or later to display the activation code screen. If phone firmware needs to be updated, point users to https://upgrade.cisco.com/MPP_upgrade.html.

  • By MAC Address—Choose this option if you know the MAC address of the device. A phone's MAC address must be a unique entry. If you enter a MAC address for a phone that's already registered or you make a mistake when you enter the number, an error message appears.

 

Limitations may apply when using third-party devices.

If you chose to generate an activation code for the device but you haven't yet used that code, the status of that device reads as Activating in the assigned user's Devices section and the main Devices list in Control Hub. Keep in mind that it may take up to 10 minutes for device status to be updated in Control Hub.

To modify or manage the devices assigned to the user, see Manage a device for a user section.

When people are at work, they get together in lots of places like lunch rooms, lobbies, and conference rooms. You can set up shared Cisco Webex devices in these Workspaces, add services, and then watch the collaboration happen.

The key principle of a Workspaces device is that it is not assigned to a specific user, but rather a physical location, allowing for shared usage.

The devices listed support Webex Calling. While most of these devices can be registered using a MAC address, only the following subset can be registered using an activation code:

  • Cisco IP Phone 6800 Series Multiplatform Phones (Audio phones—6821, 6841, 6851)

  • Cisco IP Phone 7800 Series Multiplatform Phones (Audio phones—7811, 7821, 7841, 7861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Audio phones—8811, 8841, 8851, 8861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Video phones—8845, 8865)

  • Cisco IP Conference Phone 7832 and 8832

1

From the customer view in https://admin.webex.com, go to one of the following paths:

  • Management > Devices > Add device > Shared Usage > New workspace.

    Or

  • Management > Workspaces > Add workspace

2

Enter a name for the workspace (such as the name of the physical room), select room type and add capacity. Then click Next.


 

A workspace name can't be longer than 30 characters and it can't have %, #, <, >, /, \, and " characters.

3

Choose Cisco IP Phone and then click Next.

4

Choose a device type from the drop-down list.

5

Choose whether you want to register the phone with an activation code (if the option appears) or a MAC address, and then click Next.

If you choose to register the device using an activation code, the code is emailed to the designated administrator for the location.

For Webex Calling, you can only add one shared phone to a Workspace.

For Cisco IP Conference Phone 7832, some softkeys may not be available. If you need a full set of softkeys, we recommend that you assign this phone to a user instead.

6

Click the Calling service, and choose the subscription that you want to assign to the workspace.

7

Assign a Location and Phone Number (determined by the location that you choose), and then click Save. You also have the option of assigning an extension.


 
To modify or manage the devices assigned to the workspace, see Manage a device for a workspace section.

To reuse a phone that is assigned to one Webex Calling user/workspace to another Webex Calling user/workspace, follow these steps:

1

From the customer view in https://admin.webex.com, go to the User/Workspace where the device is currently assigned.

You can reassign the device in these scenarios:

  1. If you wish to delete the user, select Delete User/Workspace to delete the user/workspace and the associated devices.

  2. If you wish to delete a device, select Devices and choose the device to delete.

2

On the phone, go to the settings menu and complete these steps to reassign the phone.

  1. Select Device administration, then Factory Reset .

  2. The phone reboots. On completing the reboot, the phone displays the Activation Code screen.

  3. The phone is now ready for reassignment.

3

Follow instructions in the Add and assign phone to user or Add a phone to a new workspace to assign or add a phone to a user/workspace.

4

On adding the device in Control Hub, complete these actions on the phone:

  1. For activation code:

    Enter the activation code. The phone reboots and is on boarded to the new user/workspace.

  2. For MAC address:

    Enter #000 on the Activation Code screen, the phone is reonboarded with Webex Calling and provisions to the new user/workspace.

When people are at work, they get together in lots of workspaces like lunch rooms, lobbies, and conference rooms. You can set up shared Cisco Webex devices in these Workspaces, add services, and then watch the collaboration happen.

The key principle of a Workspaces device is that it’s not assigned to a specific user, but rather a physical location, allowing for shared usage.

The devices listed here support Webex Calling.

1

From the customer view in https://admin.webex.com, go to one of the following paths:

  • Management > Devices > Add device > Shared Usage > New workspace.

    Or

  • Management > Workspaces > Add workspace

2

Enter a name for the workspace (such as the name of the physical room), select the room type and add capacity. Then click Next.

3

Choose Cisco Collaboration device and then click Next.

Cisco Collaboration device includes Cisco Webex Room or Desk device, including Cisco Webex Board.

4

Choose one of the following services and click Next.

  • Call on Webex (1:1 call, non-PSTN) —Users can only make Webex App or Webex Session Initiation Protocol (SIP) calls using a SIP address (for example, username@example.calls.webex.com).
  • Cisco Webex Calling —In addition to being able to make and receive Webex App and SIP calls, people in this Workspace can use the device to make and receive phone calls from within the Webex Calling numbering plan. For example, you can call your coworker by dialing the phone number 555-555-5555, extension 5555, or SIP address username@example.webex.com but you can also call your local pizzeria.
5

If you've chosen Cisco Webex Calling service, then choose the subscription that you want to assign to the workspace.

6

Assign a Location, Phone Number (determined by the location that you choose), an Extension, and then click Save.

7

Activate the device by using the code provided. You can copy, email, or print the activation code.

To assign several devices to users and workspaces, you can populate a CSV file with the required information and activate those devices in just a couple of easy steps.

The devices listed here support Webex Calling. You can register all devices using a MAC address; however, register the following subset of devices using an activation code:

  • Cisco IP Phone 6800 Series Multiplatform Phones (Audio phones—6821, 6841, 6851)

  • Cisco IP Phone 7800 Series Multiplatform Phones (Audio phones—7811, 7821, 7841, 7861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Audio phones—8811, 8841, 8851, 8861)

  • Cisco IP Phone 8800 Series Multiplatform Phones (Video phones—8845, 8865)

  • Cisco IP Conference Phone 7832 and 8832

  • Cisco Video Phone 8875

1

From the customer view in https://admin.webex.com, go to Management > Devices > Add device > Multiple Cisco IP phones.

2

Choose one of the following options and click Download.

  • Users in my organization—You can get a list of all users in your organization and their associated attributes so you don't have to manually look up each user.
  • Workspaces in my organization—You can get a list of all workspaces in your organization and their associated attributes so you don't have to manually look up each workspace.
  • Add device sample template—You can use the available template to enter information such as usernames, type (indicate whether it's a user or a workspace), MAC addresses, and device models.
You can use the following table to prepare your CSV file.

 
The following fields are mandatory when assigning a device to Webex Calling users and workspaces:
  • For Users: Username, Type, Device Type, and Model if the device type is IP.
  • For Workspace: Username, Type, Phone number or Extension, Webex Calling Workspace [subscription name], Device Type, and Model if the device type is IP.

Column NameDescriptionSupported Value

Username

To assign a device to a user, enter the user's email address.


 
Don't enter the user ID or their name.

To assign a device to a workspace, enter the workspace name.


 
If you enter a workspace that doesn't yet exist, the workspace is automatically created.

Example user email: test@example.com

Example workspace name: Break Room

Type

Enter the appropriate type as user or workspace.

USER

WORKSPACE

Phone Number

Enter a phone number.

Example: +12815550100

Extension

Enter an extension.

Example: 00-999999

Device Type

Enter the type of the device.

To use any Multiplatform Phones, ATA or DECT devices with Webex Calling, enter IP.

To create new workspaces to have RoomOS devices, enter WEBEX or WEBEX_CALLING, depending on the desired Calling option

Model

Enter the device model if the device type is IP.

Example device model: Cisco 7841, Cisco 8851, and so on

MAC Address

Enter the MAC address of the device.

If you leave the MAC address field blank, an activation code is generated.


 
Use activation codes for the RoomOS devices.

Example MAC address: 001A2B3C4D5E

Location

Enter the location of the user or workspace.

Example: San Jose

Calling Plan

Enter TRUE, to enable Cisco Calling Plan for the newly added workspace.

This feature doesn’t work for users, existing workspaces, and workspaces with unsupported location.

TRUE

FALSE

Webex Calling Workspace [subscription name]

Specify the subscription to be utilized for creating common-area calling workspaces.

Each subscription possessing workspace license has a corresponding column. You must designate only one subscription for a workspace. Enter TRUE in the respective column.

You can also transfer workspaces from one subscription to another. To transfer, enter FALSE in the source subscription column and TRUE in the target subscription column.


 
We recommend using a recently generated template to prepare the CSV import file, as it will contain accurate information regarding the active subscriptions for workspace licenses.

TRUE

FALSE


 
These Phone Number and Extension fields were previously titled Directory Number and Direct Line; these column names continue to support for a short time.

 
We recommend that you limit the number of devices to 1000 per CSV file. If you want to add more than 1000 devices, use a second CSV file.
3

Fill out the spreadsheet.

4

Upload the CSV file by dragging and dropping or clicking Choose a file.

5

If the MAC address is blank, you get the options to choose where the activation code gets sent.

  • Provide a link—The activation code gets added to a CSV file. After import, you’ll get a link to download the activation code file on the Import Status screen.
  • Email activation code—If the device is for a workspace, the activation code gets sent to you, as the administrator. If the device is for a user, the activation code is emailed to the user.

You or the user need to enter the activation code on the device for activating it.

6

Click Submit.

Displays the updated status when the devices become active.

 

Multiplatform devices must be running a firmware load of 11.2.3MSR1 or later for users to enter the activation code on their device. For information about upgrading phone firmware, see this article.

If you want to view the list of devices assigned to users and workspaces, you can export the CSV file.

From the customer view in https://admin.webex.com, go to Devices.

Select multiple devices from the device list and select the Export option. You can choose the fields to include in the CSV file, and export the content to a local folder.


 

The fields displayed on the CSV file depend on the connection of the device to the platform. Therefore, some fields aren’t available in the output file.

You can add, remove, reboot, check activation, or create a new activation code for the devices that are assigned to users within your organization. This can be helpful to view and manage devices in the users screen, when needed.

1

From the customer view in https://admin.webex.com, go to Management > Users.

2

Select a user and click Devices.

3

To add a device to this user, click Add Device.


 
If the user is already assigned a device and you want to add another device, click Action > Add device.

For more information on adding the device to a user, see Add phones to a user section.

4

To modify an existing device, select the device name.

This takes you to the Devices page. Here you can view and edit device settings, delete the device, reboot the device, or create a new activation code for the device, if applicable. For more information about configuring phone settings, see Configure and Update Phone Settings.

5

If the device added to the user is Webex Aware, then the Webex Aware option is displayed under the devices as shown in the diagram. Webex Aware indicates that the device has onboarded to the Webex platform and has access to Webex Features supported by the phone.

6

Click Actions to manage the device. Actions help to apply configuration changes or update firmware for the MPP devices.

The Actions tab has these options for a Webex Aware-enabled device:
  • Apply Changes—Issues request to the phone to download and apply changes to the configuration.
  • Reboot—Issues request to force reboot the device and download the current configuration.
  • Report Problem—Issues request to the device to generate and upload a PRT to the cloud.
  • Delete—Deletes a device that is listed for the user.

Devices can be added and managed directly from a workspace profile. Workspace devices can include ATA devices, like fax machines. You can also set up a workspace device as a Hoteling Host. For more information about hoteling, see: Hoteling in Cisco Webex Control Hub.

1

From the customer view in https://admin.webex.com, go to Management > Workspaces.

2

Select the workspace to modify.

3

To add a device, click Add Device in the Devices tile.

For more information on adding devices to workspace, see Add a phone to a new workspace section.

4

To modify an existing device, select the device name.

This takes you to the Devices page. Here you can view and edit device settings, delete the device, reboot the device, and enable the device to be used as a Hoteling Host. For more information about configuring phone settings, see Configure and Update Phone Settings.

5

If the device added to the workspace is Webex Aware, then the Webex Aware option is displayed under the devices as shown in the diagram. Webex Aware indicates that the device has onboarded to the Webex platform and has access to Webex features that are supported by the phone.

6

Click Actions to manage the device. Actions help to apply configuration changes or update firmware for the MPP devices.

The Actions tab has these options for a Webex Aware-enabled device:
  • Apply Changes—Issues request to the phone to download and apply changes to the configuration.
  • Reboot—Issues request to force reboot the device and download the current configuration.
  • Report Problem—Issues request to the device to generate and upload a PRT to the cloud.
  • Delete—Deletes a device that is listed for the user.

Shared line appearance allows you to add lines to a primary device of the user and reorder how the lines appear. This feature allows a user to receive and place calls to and from another user's extension, using their own phone. An example of shared line appearance is an executive assistant who wants to make and receive calls from the boss's line. Shared line appearances can also be another instance of the primary user's line.

The maximum configuration limit is 35 devices for each user phone number, including the desktop or mobile App of the user. You can add additional lines to a workspace phone, but can’t add a workspace phone as a shared line.


 

When assigning a shared line, you can assign numbers from different Webex Calling locations to devices in a different location. For example, a number (user, workspace, virtual line) from the UK location can be assigned to a device that is assigned to a user in the US location.

For more information on shared line across locations, see: Configuration of shared lines and virtual lines across locations.


 

When a user adds the Speed dials to their MPP phone, they aren’t visible in the Control Hub. Speed dials can be overwritten on configuring a shared line.

If a user has numbers from other users/groups configured on their devices, you can add a custom label for the shared line. This custom label helps to identify one shared line appearance from the other.

1

From the customer view in https://admin.webex.com, go to Users or Workspaces (depending on where the device to modify is assigned).

2

Select the user or workspace to modify and scroll to Devices.

3

Select the device to add or modify the shared lines, and scroll to Phone Users and Settings.

The users and places that appear on this phone are listed in order of appearance.

4

To add or remove users or places from this phone, select Configure Lines.

5

To remove a line, click the icon.


 
You can't remove the primary user on line 1.
6

To add a shared line appearance, click the icon.


 
Add the lines in the order in which you want them to appear. To reorder the line appearance, delete and add to the list in the order you want them to appear.
7

Enter the name or phone number and select from the options that appear and click Save.

You can configure the ports on an Analog Telephone Adaptor (ATA) device assigned to a user in Control Hub. Currently, the two configurations for ATA devices available are for devices with two ports and devices with 24 ports.

1

From the customer view in https://admin.webex.com, go to Users.

2

Select the user to modify and scroll to Devices.

3

Select the device where you would like to add or modify.

4

Under Users on this Device, click Configure Ports.

5

To add a shared port configuration, click the icon.

6

Enter the name or phone number and select from the options that appear and then click Save.


 
Only workspaces without devices appear in the lookup.
7

If the device requires T.38 fax compression, check the box in the T.38 column or override the user-level compression options, and then click Save.


 
A workspace can have an ATA. This is useful for fax machines.

You can add phone numbers to desk and room devices in your customer organization at any time, whether you're in the middle of a trial or have been converted to a paid subscription.


 

We've increased the number of telephone numbers that you can add in Control Hub 250 to 1000.

1

From the customer view in https://admin.webex.com, go to Services > Calling > Numbers then click Add Numbers.

2

Specify the Location and Number Type. If you're porting numbers over, enter both your current and new billing numbers.

3

Specify the Location, State, Area Code, Prefix (optional), and then click Search.

Available numbers are displayed.

4

Select the numbers that you want to add to the location.

The numbers you choose move over to the Selected Numbers field.

5

Click Save.

You can see a list of PSTN numbers that your organization has ordered. With this information you can see the unused numbers that are available, and the numbers that have been ordered that will soon become available.

From the customer view in https://admin.webex.com, go to Services > Calling > PSTN Orders.

When you connect accessories (Headsets/KEMs) to an MPP device, they appear as an inventory item under the Devices tab in the Control Hub. From the Control Hub Devices inventory you can find out the accessory model, the status, and to whom the accessory belongs. When you select an accessory, additional information can be obtained, such as the accessory serial number and current software version. The accessory status field is reported as "online" as long as the accessory is connected to MPP. An MPP-connected headset will automatically upgrade its software with the latest version available from Device Management.

Want to see how it's done? Watch this video demonstration on how to view your accessories in Control Hub.
Table 1. Compatible Headsets

Phone Model

Cisco Headset 520 Series

Cisco Headset 530 Series

Cisco Headset 560 Series

Cisco Headset 730 Series

Cisco IP Phone 8811/8841/8845

RJ9 & RJ11

Cisco IP Phone 8851/8861/8865

USB

USB

USB

RJ9 & RJ11

Cisco IP Phone 7811/7821/7841/7861

Cisco IP Phone 6821/6841/6851/6861

Cisco IP Phone 6871

USB

USB

USB

Cisco IP Conference Phone 7832/8832

Table 2. Compatible Key Expansion Modules

Phone Model

KEM

Cisco IP Phone 8811/8841/8845

Cisco IP Phone 8851/8861/8865

BEKEM

CP-8800-A-KEM

CP-8800-V-KEM

Cisco IP Phone 7811/7821/7841/7861

Cisco IP Phone 6821/6841/6861/6871

Cisco IP Phone 6851

CP-68KEM-3PCC

Cisco IP Conference Phone 7832/8832


 

To troubleshoot the issues faced with Key Expansion Module (key expansion module) on phones registered to Webex Calling, see Troubleshoot Key Expansion Modules Issues in Webex Calling for details.

December 18, 2023
Port Reference Information

This article is for network administrators, particularly firewall, and proxy security administrators who use Webex Calling services within their organization. It describes the network requirements and lists the addresses, ports, and protocols used for connecting your phones, the Webex App, and the gateways to Webex Calling services.

A correctly configured firewall and proxy are essential for a successful Calling deployment. Webex Calling uses SIP and HTTPS for call signaling and the associated addresses and ports for media, network connection, and gateway connectivity as Webex Calling is a global service.

Not all firewall configurations require ports to be open. However, if you're running inside-to-outside rules, you must open ports for the required protocols to let out services.

Network Address Translation (NAT)

Network Address Translation (NAT) and Port Address Translation (PAT) functionality are applied at the border between two networks to translate address spaces or to prevent the collision of IP address spaces.

Organizations use gateway technologies like firewalls and proxies that provide NAT or PAT services to provide internet access to Applications or devices that are on a private IP address space. These gateways make traffic from internal Apps or Devices to the internet appear to be coming from one or more publicly routable IP addresses.

  • If deploying NAT, it’s not mandatory to open an inbound port on the firewall.

  • Validate the NAT pool size required for App or Devices connectivity when multiple app users and devices access Webex Calling & Webex aware services using NAT or PAT. Ensure that adequate public IP addresses are assigned to the NAT pools to prevent port exhaustion. Port exhaustion contributes to internal users and devices being unable to connect to the Webex Calling and Webex Aware services.

  • Define reasonable binding periods and avoid manipulating SIP on the NAT device.

  • Configure a minimum NAT timeout to ensure proper operation of devices. Example: Cisco phones send a follow-up REGISTER refresh message every 1-2 minutes.

  • If your network implements NAT or SPI, then set a larger timeout (of at least 30 minutes) for the connections. This timeout allows reliable connectivity while reducing the battery consumption of the users' mobile devices.

SIP Application Layer Gateway

If a router or firewall is SIP Aware, that is the SIP Application Layer Gateway (ALG) or similar is enabled, we recommend that you turn off this functionality to maintain correct operation of service.

Check the relevant manufacturer's documentation for steps to disable SIP ALG on specific devices.

Proxy support for Webex Calling

Organizations deploy an internet firewall or internet proxy and firewall, to inspect, restrict, and control the HTTP traffic that leaves and enters their network. Thus protecting their network from various forms of cyberattacks.

Proxies perform several security functions such as:

  • Allow or block access to specific URLs.

  • User authentication

  • IP address/domain/hostname/URI reputation lookup

  • Traffic decryption and inspection

On configuring the proxy feature, it applies to all the applications that use the HTTP's protocol.

The applications include the following:

  • Webex Services

  • Customer device activation (CDA) procedures using Cisco Cloud provisioning platform such as GDS, EDOS device activation, provisioning & onboarding to Webex cloud.

  • Certificate Authentication

  • Firmware Upgrades

  • Status Reports

  • PRT Uploads

  • XSI Services


 

If a proxy server address is configured, then only the Signaling traffic (HTTP/HTTPS) is sent to the proxy server. Clients that use SIP to register to the Webex Calling service and the associated media aren’t sent to the proxy. Therefore, allow these clients to go through the firewall directly.

Supported Proxy Options, configuration & Authentication types

The supported proxy types are:

  • Explicit Proxy (inspecting or noninspecting)—Configure the clients either App or Device with explicit proxy to specify the server to use. This option supports one of the following authentication types:

  • Transparent Proxy (noninspecting)—The Clients aren’t configured to use a specific proxy server address and don’t require any changes to work with a noninspecting proxy.

  • Transparent Proxy (inspecting)—The Clients aren’t configured to use a specific proxy server address. No HTTP's configuration changes are necessary; however, your clients either App or Devices need a root certificate so that they trust the proxy. The IT team uses the inspecting proxies to enforce policies on the websites to visit and the types of content that aren’t permitted.

Configure the proxy addresses manually for Webex Room devices, Cisco IP Multiplatform Phones (MPP), and Webex App using:

  • Platform OS

  • Device UI

  • Automatic discovery

While configuring, choose from the following Proxy configurations & authentication types:

Product

Proxy Configuration

Authentication Type

Webex for Mac

Manual, WPAD, PAC

No Auth, Basic, NTLM,

Webex for Windows

Manual, WPAD, PAC, GPO

No Auth, Basic, NTLM, , Negotiate

Webex for iOS

Manual, WPAD, PAC

No Auth, Basic, Digest, NTLM

Webex for Android

Manual, PAC

No Auth, Basic, Digest, NTLM

Webex Web App

Supported through OS

No Auth, Basic, Digest, NTLM, Negotiate

Webex Room devices

WPAD, PAC, or Manual

No Auth, Basic, Digest

Cisco IP Phones

Manual, WPAD, PAC

No Auth, Basic, Digest

Webex Video Mesh Node

Manual

No Auth, Basic, Digest, NTLM

For legends in the table:

  1. Mac NTLM Auth - Machine need not be logged on to the domain, user prompted for a password

  2. Windows NTLM Auth - Supported only if a machine is logged onto the domain

  3. Web Proxy Auto Discovery (WPAD) - See Web Proxy Auto Discovery Protocol for details.

  4. Proxy Auto Config (PAC) files - See Proxy Auto-Config Files for details.

  5. To connect Cisco Webex Board, Desk, or Room Series device to a proxy server, see Connect your Board, Desk, or Room Series device to a proxy server.

  6. For Cisco IP phones, see Set Up a Proxy Server as an example for configuring the proxy server and settings.


 

For No Authentication, configure the client with a proxy address that doesn’t support authentication. When using Proxy Authentication, configure with valid credentials. Proxies that inspect web traffic may interfere with web socket connections. If this problem occurs, bypassing the not inspecting traffic to *.Webex.com might solve the problem. If you already see other entries, add a semicolon after the last entry, and then enter the Webex exception.

Proxy settings for Windows OS

Microsoft Windows support two network libraries for HTTP traffic (WinINet and WinHTTP) that allow Proxy configuration.WinINet is a superset of WinHTTP.

  1. WinInet is designed for single-user, desktop client applications only

  2. WinHTTP is designed primarily for multiuser, server-based applications

When selecting between the two, choose WinINet for your proxy configuration settings. For details, see wininet-vs-winhttp.

Refer to Configure a list of allowed domains to access Webex while on your corporate network for details on the following:

  • To ensure that people only sign in to applications using accounts from a predefined list of domains.

  • Use a proxy server to intercept requests and limit the domains that are allowed.

Proxy Inspection and Certificate Pinning

The Webex App and Devices validate the certificates of the servers when they establish the TLS sessions. Certificate checks that such as the certificate issuer and digital signature rely on verifying the chain of certificates up to the root certificate. To perform the validation checks, the Webex App and Devices use a set of trusted root CA certificates installed in the operating system trust store.

If you have deployed a TLS-inspecting Proxy to intercept, decrypt and inspect Webex Calling traffic. Ensure that the certificate the Proxy presents (in lieu of the Webex service certificate) is signed by a certificate authority, and the root certificate is installed in the trust store of your Webex App or Webex device.

  • For Webex App - Install the CA certificate that is used to sign the certificate by the proxy in the operating system of the device.

  • For Webex Room devices and Cisco multiplatform IP Phones - Open a service request with TAC team to install the CA certificate.

This table shows the Webex App and Webex Devices that support TLS inspection by Proxy servers

Product

Supports Custom Trusted CAs for TLS inspection

Webex App (Windows, Mac, iOS, Android, Web)

Yes

Webex Room Devices

Yes

Cisco IP Multiplatform (MPP) Phones

Yes

Firewall configuration

Cisco supports Webex Calling and Webex Aware services in secure Cisco and Amazon Web Services (AWS) data centers. Amazon has reserved its IP subnets for Cisco’s sole use, and secured the services located in these subnets within the AWS virtual private cloud.

Configure your firewall to allow communication from your devices, applications, and internet-facing services to perform their functions properly. This configuration allows access to all the supported Webex Calling and Webex Aware cloud services, domain names, IP addresses, Ports, and protocols.

Whitelist or open access to the following so that the Webex Calling and Webex Aware services function correctly.

  • The URLs/Domains mentioned under the section Domains and URLs for Webex Calling Services

  • IP subnets, Ports, and Protocols mentioned under the section IP Subnets for Webex Calling Services

  • If you're using the Webex Meetings, Messaging, and other services then ensure you have the Domains/URLs mentioned in this article are also open Network Requirements for Webex Services

If you’re using only a firewall, then filtering Webex Calling traffic using IP addresses alone isn’t supported as the IP address pools are dynamic and may change at any time. Update your rules regularly, failing to update your firewall rules list could impact your users' experience. Cisco doesn’t endorse filtering a subset of IP addresses based on a particular geographic region or cloud service provider. Filtering by region can cause severe degradation to your calling experience.

If your firewall doesn’t support Domain/URL filtering, then use an Enterprise Proxy server option. This option filters/allows by URL/domain the HTTPs signaling traffic to Webex Calling and Webex Aware services in your Proxy server, before forwarding to your firewall.

For Webex Calling, UDP is Cisco’s preferred transport protocol for media, and it recommends using only SRTP over UDP. TCP and TLS as transport protocols for media aren’t supported for Webex Calling in production environments. The connection-orientated nature of these protocols affects media quality over lossy networks. If you have queries regarding the transport protocol, raise a support ticket.

Domains and URLs for Webex Calling services

A * shown at the beginning of a URL (for example, *.webex.com) indicates that services in the top-level domain and all subdomains are accessible.

Domain / URL

Description

Webex Apps and devices using these domains / URLs

Cisco Webex Services

*.broadcloudpbx.com

Webex authorization microservices for cross-launch from Control Hub to Calling Admin Portal.

Control Hub

*.broadcloud.com.au

Webex Calling services in Australia.

All

*.broadcloud.eu

Webex Calling services in Europe.

All

*.broadcloudpbx.net

Calling client configuration and management services.

Webex Apps

*.webex.com

*.cisco.com

Core Webex Calling & Webex Aware services

  1. Identity provisioning

  2. Identity storage

  3. Authentication

  4. OAuth services

  5. Device onboarding

  6. Cloud Connected UC

When a phone connects to a network for the first time or after a factory reset with no DHCP options set, it contacts a device activation server for zero touch provisioning. New phones use activate.cisco.com and phones with firmware release earlier than 11.2(1), continue to use webapps.cisco.com for provisioning.

Download the device firmware and locale updates from binaries.webex.com.

Allow Cisco Multiplatform phones (MPPs) older than 12.0.3 version to access sudirenewal.cisco.com through port 80 to renew Manufacturer Installed Certificate (MIC) and have a Secure Unique Device Identifier (SUDI). For details, see Field notice.

All

*.ucmgmt.cisco.com

Webex Calling services

Control Hub

*.wbx2.com and *.ciscospark.com

Used for cloud awareness, CSDM, WDM, mercury, and so on. These services are necessary for the Apps and devices to reach out to Webex Calling & Webex Aware services during and after onboarding.

All

*.webexapis.com

Webex microservices that manage your applications and devices.

  1. Profile picture service

  2. Whiteboarding service

  3. Proximity service

  4. Presence service

  5. Registration service

  6. Calendaring service

  7. Search service

All

*.webexcontent.com

Webex Messaging services related to general file storage including:

  1. User files

  2. Transcoded files

  3. Images

  4. Screenshots

  5. Whiteboard content

  6. Client & device logs

  7. Profile pictures

  8. Branding logos

  9. Log files

  10. Bulk CSV export files & import files (Control Hub)

Webex Apps Messaging services.


 

File storage using webexcontent.com replaced by clouddrive.com in October 2019

*.accompany.com

People insights integration

Webex Apps

Additional Webex-Related Services (Third-Party Domains)

*.appdynamics.com

*.eum-appdynamics.com

Performance tracking, error and crash capture, session metrics.

Control Hub

*.huron-dev.com

Webex Calling micro services like toggle services, phone number ordering, and assignment services.

Control Hub

*.sipflash.com

Device management services. Firmware upgrades and secure onboarding purposes.

Webex Apps

*.walkme.com *.walkmeusercontent.com

Webex user guidance client. Provides onboarding and usage tours for new users.

For more information about WalkMe, click here.

Webex Apps

*.google.com

*.googleapis.com

Notifications to Webex apps on mobile devices (Example: new message, when call is answered)

For IP Subnets, refer to these links

Google Firebase Cloud Messaging (FCM) service

Apple Push Notification Service (APNS)


 

For APNS, Apple lists the IP subnets for this service.

Webex App

IP Subnets for Webex Calling services

IP Subnets for Webex Calling Services*

23.89.0.0/16

85.119.56.0/23

128.177.14.0/24

128.177.36.0/24

135.84.168.0/21

139.177.64.0/21

139.177.72.0/23

144.196.0.0/16

150.253.128.0/17

170.72.0.0/16

170.133.128.0/18

185.115.196.0/22

199.19.196.0/23

199.19.199.0/24

199.59.64.0/21

Connection purpose

Source addresses

Source Ports

Protocol

Destination addresses

Destination ports

Notes

Call signaling to Webex Calling (SIP TLS)

Local Gateway external (NIC)

8000-65535

TCP

Refer to IP Subnets for Webex Calling Services.

5062, 8934

These IPs/ports are needed for outbound SIP-TLS call signaling from Local Gateways, Devices, and Applications (Source) to Webex Calling Cloud (Destination).

Port 5062 (required for Certificate-based trunk). And port 8934 (required for Registration-based trunk

Devices

5060-5080

8934

Applications

Ephemeral (OS dependent)

Call signaling from Webex Calling (SIP TLS) to Local Gateway

Webex Calling address range.

Refer to IP Subnets for Webex Calling Services

8934

TCP

IP or IP range chosen by customer for their Local Gateway

Port or port range chosen by customer for their Local Gateway

Applies to certificate-based local gateways. It is required to establish a connection from Webex Calling to a Local Gateway.

Registration-based local gateway works on reusing a connection created from the local gateway.

Destination port is customer chosen Configure trunks

Call media to Webex Calling (STUN, SRTP, T38)

Local Gateway external NIC

8000-48198*

UDP

Refer to IP Subnets for Webex Calling Services.

5004, 9000 (STUN Ports)

8500-8700,19560-65535 (SRTP over UDP)

  • These IPs/ports are used for outbound SRTP call media from Local Gateways, Devices, and Applications (Source) to Webex Calling Cloud (Destination).

  • For Calls within the organization where STUN, ICE negotiation is successful, the media relay in the cloud is removed as the communication path. In such cases the media flow is directly between the user's Apps/devices.

    For Example: If media optimization is successful, applications send media directly between one another on port ranges between 8500-9700 and devices send media directly to one another on ports ranges between 19560-19660.

  • For certain network topologies where firewalls are used within a customer premise, allow access for the mentioned source and destination port ranges inside your network for the media to flow through.

    Example: For applications, allow the source and destination port range 8500–8700.

Devices

19560-19660

Applications

8500-8700

Call signaling to PSTN gateway (SIP TLS)Local Gateway internal NIC8000-65535

TCP

Your ITSP PSTN GW or Unified CMDepends on PSTN option (for example, typically 5060 or 5061 for Unified CM)

Call media from Webex Calling (SRTP, T38)

Webex Calling address range.

Refer to IP Subnets for Webex Calling Services

19560-65535 (SRTP over UDP)

UDP

IP or IP range chosen by customer for their Local Gateway

Media port range chosen by customer for their Local Gateway

Webex calling allows all remote devices to perform media latching if the device is behind a NAT. For certificate based local gateway, it is required to allow ingress access for specific port range. Refer to the network requirements specific to NAT when deploying a certificate-based local gateway.

Call media to PSTN gateway (SRTP)Local Gateway internal NIC

8000-48198*

UDP

Your ITSP PSTN GW or Unified CMDepends on the PSTN option (for example, typically 5060 or 5061 for Unified CM)

Device configuration and firmware management (Cisco devices)

Webex Calling devices

Ephemeral

TCP

3.20.185.219

3.130.87.169

3.134.166.179

72.163.10.96/27

72.163.15.64/26

72.163.15.128/26

72.163.24.0/23

72.163.10.128/25

173.37.146.128/25

173.36.127.0/26

173.36.127.128/26

173.37.26.0/23

173.37.149.96/27

192.133.220.0/26

192.133.220.64/26

443, 6970, 80

Required for the following reasons:

  1. Migrating from Enterprise phones (Cisco Unified CM) to Webex Calling. See upgrade.cisco.com for more information. The cloudupgrader.webex.com uses ports: 6970,443 for the firmware migration process.

  2. Firmware upgrades and secure onboarding of devices (MPP and Room or Desk phones) using the 16-digit activation code (GDS)

  3. For CDA / EDOS - MAC address-based provisioning. Used by devices (MPP phones, ATAs, and SPA ATAs) with newer firmware.

  4. When a phone connects to a network for the first time or after a factory reset, without the DHCP options set, it contacts a device activation server for zero touch provisioning. New phones use activate.cisco.cominstead of webapps.cisco.com for provisioning. Phones with firmware released earlier than 11.2(1) continue to use webapps.cisco.com. It is recommended to allow all these IP subnets.

  5. Allow Cisco Multiplatform phones (MPPs) older than 12.0.3 version to access sudirenewal.cisco.comthrough port 80 for renewing Manufacturer Installed Certificate (MIC) and to have a Secure Unique Device Identifier (SUDI). For details, see Field Notice

Application configuration

Webex Calling applications

Ephemeral

TCP

62.109.192.0/18

64.68.96.0/19

150.253.128.0/17

207.182.160.0/19

443, 8443

Used for Idbroker Authentication, Application configuration services for clients, Browser based web access for self-care AND Administrative interfaces access.

Device time synchronization (NTP)

Webex Calling devices

51494

UDP

Refer to IP Subnets for Webex Calling Services.

123

These IP addresses are needed for Time Synchronization for Devices (MPP phones, ATAs, and SPA ATAs)

Device name resolution and Application name resolution

Webex Calling devices

Ephemeral

UDP and TCP

Host-defined

53

Used for DNS lookups to discover the IP addresses of Webex Calling services in the cloud.

Even though typical DNS lookups are done over UDP, some may require TCP, if the query responses can’t fit it in UDP packets.

Application time synchronization

Webex Calling applications

123

UDP

Host-defined

123

CScan

Web based Network readiness Pre-qualification tool for Webex Calling

Ephemeral

TCP

Refer to IP Subnets for Webex Calling Services.

8934 and 443

Web based Network readiness Prequalification tool for Webex Calling. Go to cscan.webex.com for more information.

UDP

19569-19760

Additional Webex Calling & Webex Aware Services (Third-Party)

Push notifications APNS and FCM services

Webex Calling Applications

Ephemeral

TCP

Refer to IP Subnets mentioned under the links

Apple Push Notification Service(APNS)

Google-Firebase Cloud Messaging (FCM)

443, 2197, 5228, 5229, 5230, 5223

Notifications to Webex Apps on mobile devices (Example: When you receive a new message or when a call is answered)


 
  • *CUBE media port range is configurable with rtp-port range.

  • If a proxy server address is configured for your Apps and Devices, the signaling traffic is sent to the proxy. Media transported SRTP over UDP flows directly to your firewall instead of the proxy server.

  • If you’re using NTP and DNS services within your enterprise network, then open the ports 53 and 123 through your firewall.

Webex Meetings/Messaging - Network Requirements

Onboard the MPP devices to the Webex Cloud for services like Call History, Directory Search, and Meetings. See the network requirements for these Webex services in Network Requirements for Webex Services. If you're using meetings, Messaging and other services fromWebex App, then ensure that the Domains/URLs/Addresses mentioned in this article are open.

References

To know What's new in Webex Calling, see What's new in Webex Calling

For Security requirements for Webex Calling, see Article

Webex Calling Media Optimization with Interactive Connectivity Establishment (ICE) Article

Document Revision History

Date

We've made the following changes to this article

December 18, 2023

Included the sudirenewal.cisco.com URL and port 80 requirement for device configuration and firmware management of Cisco MPP phone's MIC renewal.

December 11, 2023

Updated the IP Subnets for Webex Calling services to include a larger set of IP addresses.

150.253.209.128/25 – changed to 150.253.128.0/17

November 29, 2023

Updated the IP Subnets for Webex Calling services to include a larger set of IP addresses to accommodate Webex Calling region expansion for future growth.

144.196.33.0/25 – changed to 144.196.0.0/16

The IP Subnets for Webex Calling services sections under Webex Calling (SIP TLS) and Call media to Webex Calling (STUN, SRTP) is updated for clarity on certificate-based trunking and the firewall requirements for Local Gateway.

August 14, 2023

We’ve added the following IP addresses 144.196.33.0/25 and 150.253.156.128/25 to support increased capacity requirements for Edge and Webex Calling Services.


 

This IP range is supported only in the U.S. region.

July 5, 2023

Added the link https://binaries.webex.com to install the Cisco MPP Firmware.

March 7, 2023

We've overhauled the entire article to include:

  1. Included options for Proxy support.

  2. Modified Calling flow diagram

  3. Simplified Domains/URLs/IP subnet portions for Webex Calling and Webex Aware services

  4. Added 170.72.0.0/16 IP subnet range for Webex Calling & Webex Aware services.

    Removed the following ranges 170.72.231.0, 170.72.231.10, 170.72.231.161 and 170.72.242.0/24

March 5, 2023

Updating the article to include the following:

  • Added the UDP-SRTP port range (8500-8700) used by applications.

  • Added the ports for the Push notifications APNS and FCM services.

  • Split the CScan port range for UDP & TCP.

  • Added the references section.

November 15, 2022

We’ve added the following IP addresses for device configuration and firmware management (Cisco devices):

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

We’ve removed the following IP addresses from device configuration and firmware management (Cisco devices):

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

November 14, 2022

Added the IP subnet 170.72.242.0/24 for the Webex Calling service.

September 08, 2022

The Cisco MPP Firmware transitions to use https://binaries.webex.com as the host URL for MPP firmware upgrades in all regions. This change improves firmware upgrade performance.

August 30, 2022

Removed reference to Port 80 from Device configuration and firmware management (Cisco devices), Application configuration and CScan rows in the Port table as there’s no dependency.

August 18, 2022

No change in the solution. Updated the destination ports 5062 (required for Certificate-based trunk), 8934 (required for Registration-based trunk) for Call signaling to Webex Calling (SIP TLS).

July 26, 2022

Added the 54.68.1.225 IP Address, which is required for firmware upgrade of Cisco 840/860 devices.

July 21, 2022

Updated the destination ports 5062, 8934 for Call signaling to Webex Calling (SIP TLS).

July 14, 2022

Added the URLs that support a complete function of Webex Aware services.

Added the IP subnet 23.89.154.0/25 for the Webex Calling service.

June 27, 2022

Updated the Domain and URLs for Webex Calling services:

*.broadcloudpbx.com

*.broadcloud.com.au

*.broadcloud.eu

*.broadcloudpbx.net

June 15, 2022

Added the following ports and protocols under IP Addresses and Ports for Webex Calling Services:

  • Connection purpose: Webex Features

  • Source addresses: Webex Calling Devices

  • Source ports: Ephemeral

  • Protocol: TCP

  • Destination addresses: Refer to IP Subnets and Domains defined in Webex Meetings/Messaging - Network Requirements.

  • Destination ports: 443

    Notes: The Webex Calling Devices use these IP addresses and domains to interface with Webex Cloud Services such as Directory, Call History and Meetings.

Updated information in Webex Meetings/Messaging - Network Requirements section

May 24, 2022

Added the IP subnet 52.26.82.54/24 to 52.26.82.54/32 for Webex Calling service

May 6, 2022

Added the IP subnet 52.26.82.54/24 for Webex Calling service

April 7, 2022

Updated the Local Gateway internal and external UDP port range to 8000-48198

April 5, 2022

Added the following IP subnets for Webex Calling service:

  • 23.89.40.0/25

  • 23.89.1.128/25

March 29, 2022

Added the following IP subnets for Webex Calling service:

  • 23.89.33.0/24

  • 150.253.209.128/25

September 20, 2021

Added 4 new IP subnets for Webex Calling service:

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

April 2, 2021

Added *.ciscospark.com under Domains and URLs for Webex Calling Services to support Webex Calling use cases in Webex app.

March 25, 2021

Added 6 new IP ranges for activate.cisco.com, which will come in effect starting May 8, 2021.

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

March 4, 2021

Replaced Webex Calling discrete IPs and smaller IP ranges with simplified ranges in a separate table for ease of understanding for firewall configuration.

February 26, 2021

Added 5004 as destination port for Call media to Webex Calling (STUN, SRTP) to support Interactive Connectivity Establishment (ICE) that will be available in Webex Calling in April 2021.

February 22, 2021

Domains and URLs are now listed within a separate table.

IP Addresses and Ports table are adjusted to group IP addresses for the same services.

Adding the Notes column to the IP Addresses and Ports table that aids in understanding the requirements.

Moving the following IP addresses to simplified ranges for device configuration and firmware management (Cisco devices):

activate.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

Adding the following IP addresses for Application Configuration because Cisco Webex client points to a newer DNS SRV in Australia in March 2021.

  • 199.59.64.237

  • 199.59.67.237

January 21, 2021

We’ve added the following IP addresses to device configuration and firmware management (Cisco devices):

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

We’ve removed the following IP addresses from device configuration and firmware management (Cisco devices):

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

We’ve added the following IP addresses to the application configuration:

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

We’ve removed the following IP addresses from the application configuration:

  • 64.68.99.6

  • 64.68.100.6

We’ve removed the following port numbers from the application configuration:

  • 1081, 2208, 5222, 5280-5281, 52644-52645

We’ve added the following domains to the application configuration:

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

December 23, 2020

Added new Application Configuration IP addresses to the port reference images.

December 22, 2020

Updated the Application Configuration row in the tables to include the following IP addresses: 135.84.171.154 and 135.84.172.154.

Hid the network diagrams until these IP addresses are added.

December 11, 2020

Updated the Device configuration and firmware management (Cisco devices) and the Application configuration rows for the supported Canadian domains.

October 16, 2020

Updated the call signaling and media entries with the following IP addresses:

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

September 23, 2020

Under CScan, replaced 199.59.64.156 with 199.59.64.197.

August 14, 2020

Added more IP addresses to support the introduction of data centers in Canada:

Call signaling to Webex Calling (SIP TLS)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24

August 12, 2020

Added more IP addresses to support the introduction of data centers in Canada:

  • Call media to Webex Calling (SRTP)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24

  • Call signaling to publicly addressed endpoints (SIP TLS)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24.

  • Device configuration and firmware management (Cisco devices)—135.84.173.155,135.84.174.155

  • Device time synchronization—135.84.173.152, 135.84.174.152

  • Application configuration—135.84.173.154,135.84.174.154

July 22, 2020

Added the following IP address to support the introduction of data centers in Canada: 135.84.173.146

June 9, 2020

We made the following changes to the CScan entry:

  • Corrected one of the IP addresses—changed 199.59.67.156 to 199.59.64.156.

  • New features require new ports and UDP—19560-19760

March 11, 2020

We added the following domain and IP addresses to the application configuration:

  • jp.bcld.webex.com—135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

We updated the following domains with additional IP addresses to device configuration and firmware management:

  • cisco.webexcalling.eu—85.119.56.198, 85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169, 3.20.185.219

February 27, 2020

We added the following domain and ports to device configuration and firmware management:

cloudupgrader.webex.com—443, 6970

Was this article helpful?
Webex Calling Configuration Workflow