Cisco Cucm To Webex Calling

CALLING
Transitioning from Unified CM to

Webex Calling
Deployment Guide
September 22, 2021
© 2021 Cisco – CTG TME

Contents
Contents
CONTENTS .............................................................................................................................. 2
WHAT’S NEW IN THIS GUIDE .................................................................................................. 4
INTRODUCTION ....................................................................................................................... 6
TARGET AUDIENCE ...................................................................................................................... 6

OVERVIEW ................................................................................................................................. 6
CORE COMPONENTS ............................................................................................................ 10
ROLES OF THE COMPONENTS INVOLVED ....................................................................................... 10
TRANSITION .......................................................................................................................... 12
PRE-TRANSITIONS STEPS AND CONSIDERATIONS .......................................................................... 13

1. PERFORM INITIAL READINESS ASSESSMENT OF EXISTING DEPLOYMENT. ..........................................13
2. PERFORM NETWORK READINESS ASSESSMENT ...........................................................................18
3. UNDERSTAND WEBEX CALLING REGION SELECTION ....................................................................18
4. ANALYZE DEPLOYMENT DIAL PLAN............................................................................................20
5. INVENTORY EXISTING LOCATIONS/SITES ....................................................................................22
6. UNDERSTANDING PSTN ACCESS OPTIONS ................................................................................24
7. INVENTORY EXISTING ENDPOINTS/CLIENTS. ................................................................................28
8. INVENTORY AND PLAN FOR EXISTING USERS TRANSITION TO WEBEX CALLING .................................30
TRANSITION STEPS AND CONSIDERATIONS ................................................................................... 30
1. ORDER WEBEX CALLING .........................................................................................................31
2. IMPLEMENT REQUIRED NETWORK AND FIREWALL CHANGES. ..........................................................31
3. PREPARE WEBEX CONTROL HUB FOR DIRECTORY INTEGRATION AND USER PROVISIONING. ...............32
4. DIRECTORY INTEGRATION ........................................................................................................35
5. SETUP AND VERIFY LOCAL GATEWAY .......................................................................................38
6. CONFIGURE CALL ROUTING......................................................................................................39
7. USER PROVISIONING FOR WEBEX CALLING ................................................................................45
8. PHONE MIGRATION AND PROVISIONING FOR WEBEX CALLING .......................................................46
9. ENABLE EMERGENCY CALLING ..................................................................................................53
10. IMPLEMENT CALL RECORDING ..................................................................................................56
POST-TRANSITION STEPS AND CONSIDERATIONS .......................................................................... 57
1. TRANSITION TO CLOUD CONNECTED PSTN ..............................................................................57
2. UPDATE ON-PREMISES INFRASTRUCTURE ..................................................................................58
3. LEVERAGE WEBEX CALLING TROUBLESHOOTING TOOLS ..............................................................59
© 2021 Cisco – CTG TME Collaboration Transitions – Calling: Transitioning from Unified CM to Webex Calling PAGE 2
Contents
4. UTILIZE WEBEX CALLING ANALYTICS ........................................................................................60
REFERENCES ......................................................................................................................... 64
LICENSING ..................................................................................................................................64
NETWORK REQUIREMENTS.............................................................................................................64
PHONES .....................................................................................................................................64
USERS ........................................................................................................................................65
CALLING CONFIGURATION .............................................................................................................65
LOCAL GATEWAY.........................................................................................................................65
DESIGN OVERVIEW .......................................................................................................................66
DCLOUD LAB...............................................................................................................................66
COLLABORATION TRANSITIONS ......................................................................................................66
GLOSSARY ............................................................................................................................ 67
LOCATIONS AND GROUPING ..........................................................................................................68

USERS ........................................................................................................................................74
PHONES .....................................................................................................................................76
FEATURES / FUNCTIONALITY ..........................................................................................................77
OPERATIONS ...............................................................................................................................85
What’s New in This Guide

Table 1 provide a historical list of updated and new topics added to this guide.
Table 1. Unified CM to Webex Calling Transition Deployment Guide Publication History
Date Updated or New Topics Update Details and Location

Initial document
Apr. 24, 2020 Initial release
publication
Minor edits to text and illustrations to
Topics throughout
May 25, 2020 correct spelling, grammar, etc. based on
document
feedback made throughout document.
Clarifications regarding single-site with
Preliminary Transition predominately on-net calling, and 150
Considerations concurrent calls per LGW limitation
(Introduction > Overview).
Bandwidth calculation clarifications – IP
Webex Calling bandwidth only (Perform initial readiness
Bandwidth Calculations assessment of existing deployment >
Network Connectivity).
LGW PSTN and cloud/on-premises interop
concurrent calling capacity clarification
PSTN Connectivity with
(Perform initial readiness assessment of
Local Gateway
Nov. 18, 2020 existing deployment > PSTN Connectivity
with Local Gateway).
Addition of Canadian regional datacenter
Webex Calling Regional
Webex Calling platform (Webex Calling
Datacenters
region selection).
Updated CSV setting information for user
User Migration CSV
migration (User provisioning for Webex
Settings
Calling).
Clarifications related to emergency calling

Emergency Calling
for Webex Calling with RedSky Horizon
Enablement
Mobility service (Enable emergency calling).
Added “Glossary” with tables of Unified CM

concepts and constructs along with a
Glossary
definition and information on potential
alignment with Webex Calling (Glossary).
Topics throughout Product name change: “Webex Teams” to
Jan. 27, 2021
document “Webex”.
Updated per LGW concurrent call capacity
Local Gateway
Jun. 17, 2021 to 250 (Introduction > Overview and PSTN
concurrent call capacity
Connectivity with Local Gateway).
Product reference name changes from
September Topics throughout “Cisco Webex” to “Webex” throughout the
22, 2021 document document along with minor formatting and
textual corrections.
Introduction
Introduction
Target Audience
This transition deployment guide is intended to be used by teams or individuals with
experience configuring and administering Cisco Unified Communications Manager
(Unified CM) and Cisco Endpoints including IP desk phones, video devices, and
Jabber soft clients. There are links to product and support documentation throughout
this document to assist.
Overview
With the growth of cloud-delivered collaboration services, more and more customers
are looking to move their existing collaboration workloads to the cloud given the
promises of reduced total cost of ownership, simplified management, continuous
feature delivery, increased scale, and superior reliability inherent in cloud-based
services. As customers look to make the transition from on-premises to cloud
collaboration services, it’s important for them to understand what the transition entails
and the steps required to make the transition.
The purpose of this document is to provide deployment guidance for customers
specifically looking to transition from on-premises Cisco Unified CM calling to Webex
Calling in the cloud. This deployment guide assumes that the reader has a basic
understanding of the calling transition between Unified CM and Webex Calling
including what changes when making this transition and what the differences are when
moving the calling workload from on-premises to the cloud. Before proceeding ensure
you have reviewed and are familiar with the information available in the transition map
Calling: Transition from Unified CM to Webex Calling available at
https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/TDM_CALLING_Unifi
ed_CM_to_Webex_Calling.pdf. This transition map document provides information
about the changes and differences of this transition.
As shown in Figure 1, a typical deployment includes different collaboration
infrastructure components on the network, a call control platform, and an edge
platform, hardware and software endpoints, and in some cases even conferencing and
scheduling platforms. In the Cisco architecture this would include Cisco Unified CM for
call control, Cisco Expressway for remote access and business-to-business (B2B)
edge services, Cisco Meeting Server / Cisco Meeting Management for on-premises
conferencing, Cisco Unity Connection for voice messaging, and user-facing hardware
(Cisco IP Phones, Webex DX and Room) and software (Cisco Jabber) IP-based
endpoints. These components may vary slightly in some environments, but this is the
Introduction
starting point for the transition described in the rest of this document.
Figure 1. On-Premises Collaboration Architecture: Call Control and Remote Access
Note: The architecture shown in Figure 1 is based on the Preferred Architecture (PA)
for Cisco Collaboration Enterprise On-Premises Deployments. For more information on
the Enterprise On-Premises PA, refer to https://www.cisco.com/go/pa.
Table 2 lists the key elements of the on-premises architecture prior to transitioning to
Webex Calling in the cloud:
Table 2. Before: On-Premises Calling Infrastructure Components
Product Description
On-premises call control providing device

Cisco Unified CM
registration and call routing services
Edge infrastructure providing Mobile and Remote

Access (MRA) (business-to-business (B2B))
functionality enabling remote endpoints to
Cisco Expressway-C/E
connect securely from outside the organization.
Expressway is deployed in pairs to provide firewall
traversal for external endpoints.
Introduction
Cisco Meeting Server (CMS),

On-premises voice, video, and web conferencing
Cisco Meeting Management
infrastructure providing multipoint meetings,
(CMM), and Cisco
meeting management, and scheduling
Telepresence Management
capabilities. [Optional]
Suite (TMS)
On-premises voice messaging platform providing
Cisco Unity Connection voicemail and unified messaging capabilities.
[Optional]
Webex DX, Webex Room /

IP-based devices registered to Unified CM and
Room Kit, Cisco IP Phones,
providing voice and video calling capabilities
and Cisco Jabber
As illustrated in Figure 2, customers who have an on-premises call control with Unified
CM and desk and video IP endpoints have a choice of transitioning the architecture
toward a Webex Calling cloud architecture.
The decision needs to be made based on customer’s functionality requirements.
Customers that have the following requirements should consider carefully before
making this decision and may ultimately decide to keep call control on-premises:
 Phone models other than Cisco 7800 and 8800 IP phone series.
 Complex or numerous integrations with other on-premises systems / solutions.
 Complex dial plan and/or highly granular classes of service.
 Calling within deployment is predominately on-net within a single site.
 Restrictive, limited, or unreliable Internet access.
 Stringent data privacy and ownership policies.
 Compliance requirement for on-premises or in-country media recording and
storage.
 Requirement for more than 250 concurrent PSTN and cloud / on-premises
interop calls per Local Gateway (LGW).
Introduction
Figure 2. On-Premises Calling Transition Decision Tree
Customers who wish to start leveraging Cisco cloud calling services should consider
Webex Calling. This cloud calling service allows the customer to leverage the Webex
global architecture for scale and connectivity. Participants on the corporate network
and remote participants outside the corporate network can communicate using IP-
based hardware endpoints or desktop or mobile soft client applications.
This document focuses on customers with Cisco Unified CM call control deployments
that want to understand the general steps, considerations, and requirements for
enabling Webex Calling deployment as depicted in the next section.
Core Components
Core Components
Roles of the Components Involved
The target architecture for this migration includes several new components. This
includes the Webex Calling service for cloud-based calling, Webex App, Cisco
Directory Connector for identity integration, and Local Gateway IOS-XE router for
PSTN access as well as on-premises to cloud calling integration. Cloud Connected
PSTN (CCP) facilitated by a provider partner is another option for PSTN access.
As shown in Figure 3, the new components (Webex Calling, Directory Connector, and
Local Gateway) are added to the existing on-premises deployment.
Figure 3. After: Webex Calling Architecture
Table 3 lists the new elements of the architecture after transitioning to Webex Calling.
Core Components
Table 3. After: Cloud Calling Infrastructure Components
Product Description
Cloud-based call service delivered from the Webex
Webex Calling platform and providing endpoint registration and call
routing
Windows application running on a Windows domain
Cisco Directory machine providing identity synchronization between the
Connector enterprise Active Directory and the identity store of the
Webex organization.
Cisco IOS-XE Integrated Services Router (ISR 1100

and 4000 series) or Cloud Services Router (CSR1000v)
Cisco IOS-XE Local deployed on-premises and delivering PSTN access for
Gateway cloud-registered endpoints as well as calling
integration between Unified CM registered and cloud
registered endpoints.
Cloud Connected PSTN is a cloud-based option for
Cloud Connected PSTN PSTN access by Webex Calling endpoints. PSTN
(CCP) access is facilitated by a cloud PSTN provider and
requires no on-premises equipment.
Client application running on desktop OS (Windows,
Mac) or mobile OS (Android, iOS) and registered
Webex App
directly to Webex Calling platform for calling
functionality.
Transition
Transition
This section covers the pre-transition preparation steps, the transition implementation
steps, and the post-transition steps to be considered for this workflow transition.
This document describes a phased transition in two parts. As shown in Figure 4, the
initial transition phase (Phase 1) results in a hybrid deployment with dual call control
where some devices are transitioned to cloud calling and other devices maintain on-
premises call control for registration and call routing. The final transition phase (Phase
2) results in a pure cloud calling environment where all devices have been fully
transitioned to cloud call control. How long an organization takes to transition to cloud
calling fully will vary based on the deployment in question. In some cases, organization
may make the initial transition and remain in the hybrid dual call control phase (Phase
1) for an extended period (months or even years) while in other cases an organization
may fully transition to cloud calling (Phase 2) in a very short period of time (days or
weeks). This document is intended to cover both partial (Phase 1) and full transitions
(Phase 2).
Figure 4. Phased Calling Transition: Hybrid and Cloud
Note: It is possible that some organizations may maintain a hybrid dual call control
deployment indefinitely with no plans to ever fully transition to cloud calling.
Transition
Pre-Transitions Steps and Considerations

Below is a summary of pre-transition items/steps to consider when performing the
transition from Unified CM on-premises calling to Webex Calling.
1. Perform initial readiness assessment of existing deployment.
Prior to transition, to determine the feasibility and potential modifications required, it

is important to consider each of the following aspects of your existing deployment.
Likewise, you must understand key elements of the Webex Calling offer in
comparison with the existing on-premises deployment.
Licensing
Understanding the current licensing structure of an existing deployment is a key
consideration when preparing to migrate to Webex Calling. Perform a license
assessment of the following areas of your existing Cisco on-premises solution.
 Platform
The ability to fully articulate what is currently licensed on your core platform
will be critical when working with your account team or partner to determine
the best path to Flex licensing. Webex Calling is licensed using Flex licensing.
For more information on Flex licensing refer to the Cisco Collaboration Flex
Plan information available at https://www.cisco.com/c/en/us/products/unified-
communications/collaboration-flex-plan/index.html.
 Devices
Determine what license category your existing and planned new devices will
belong to with Webex Calling. Webex Calling licensing station types include
knowledge worker, basic user, and non-user assigned devices for common
areas. For more information on Webex Calling device licensing refer to the
data sheet available at
https://www.cisco.com/c/en/us/products/collateral/unified-
communications/webex-calling/datasheet-c78-742056.html.
 Local Gateway
Because Cisco Unified Border Element (CUBE) is required for PSTN access for
this transition, CUBE licensing must also be considered. CUBE licensing
considerations are covered later in this document.
Deployment Sites
Transition
The number and types of sites (large central, regional, branch, and so on) within
your existing deployment should be considered when planning this transition. A full
understanding of the existing deployment sites will aid in strategically planning for a
successful transition particularly when it comes to determining what sites to
migrate and in what order. Understanding in detail dial plan requirements
(numbering, dialing habits, classes of restriction, and so on), site network
connectivity and bandwidth (Internet, WAN, LAN), and PSTN access (local or
centralized, IP or TDM) for each site will be critical when making migration
decisions. For more information on common deployment models and key
considerations, please refer to the collaboration deployment models information
available in the Collaboration SRND at
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/colla
b12/models.html.
Another important deployment consideration when transitioning to Webex Calling is

location availability. Webex Calling has different capabilities, subscriptions and
devices that are available depending on where your deployment is located. For
more information on Webex Calling geographic availability, refer to the Where is
Cisco Webex Available article available at https://help.webex.com/en-
us/n6fwepj/Where-is-Cisco-Webex-Available#id_98285.
Finally, it is important to understand the impact the transition to Webex Calling will
have on other collaboration services. Based on the objective of this document, the
general assumption is that if existing collaboration services outside of the calling
workload are to be maintained, then transition to the phase 1 hybrid deployment
mentioned above is expected. Examples of collaboration services that may require
hybrid deployment include contact center, meetings, paging, call reporting, and so
on. For more information about the transition of additional collaboration workloads
and services refer to the Collaboration Transitions documentation available at
https://cisco.com/go/ct.
Network Connectivity
Consider existing provider data connections (MPLS, SD-WAN, and so on) and
generally plan for direct Internet access at each location within your deployment.
Because you will be consuming cloud-based services, reliable Internet connectivity
with sufficient bandwidth is a base requirement. You should reconsider making this
transition if your organization locations’ Internet connection(s) are not generally
reliable with low latency and adequate up and downstream throughput.
Transition
Table 4 shows the call types available with a Webex Calling deployment along with
the codec and maximum bandwidth required for each call type. As shown in Table
4 the required audio call bandwidth for each call type can be calculated using the
following general formula:
Number of expected concurrent calls * Bandwidth per call based on codec =

Required network throughput.
Table 4. Webex Calling Call Type Bandwidth Calculations
Codec -
Call Types Bandwidth Calculations
Bandwidth
Webex App / MPP1 Phone OPUS - Number of concurrent calls * 70 kbps
-> Webex App 70 kbps = Required network throughput
Webex App / MPP1 Phone OPUS – Number of concurrent calls * 70 kbps
-> MPP1 Phone 70 kbps = Required network throughput
Webex App / MPP1 Phone G.711 – Number of concurrent calls * 80 kbps
-> PSTN via LGW 80 kbps = Required network throughput
Webex App / MPP1 Phone G.711 – Number of concurrent calls * 80 kbps
-> PSTN via CCP 80 kbps = Required network throughput
Webex App / MPP1 Phone - G.722 – Number of concurrent calls * 80 kbps
> Enterprise via LGW 80 kbps = Required network throughput
Webex App / MPP1 Phone - OPUS – Number of concurrent calls * 70 kbps
> Webex Calling Voicemail 70 kbps = Required network throughput
1
Multiplatform Phone (MPP)
By summing the concurrent required network throughput per call type, the total
potential bandwidth requirement for a specific site can be determined.
All call legs are always anchored on the Webex Calling access SBCs. To determine
the required internet bandwidth for any given Webex Calling location not only the
inter-location calls need to be considered, but also intra-location calls and calls to
and from a Local Gateway at that location. For example, an intra-site call between
two MPPs would need up to 2 x 70 kbps full duplex on the location’s internet
access.
By summing the concurrent required network throughput per call type, the total
potential bandwidth requirement for a specific site can be determined.
Transition
Table 5 shows an example of a complete bandwidth calculation exercise assuming

that all devices are located in the same site.
Table 5. Webex Calling Bandwidth Calculation Examples
Number of
Call Types Concurrent Total Bandwidth
Calls
Webex App / MPP1 Phone
15 2 * 15 * 70 kbps = 2,100 kbps
-> Webex App
15 2 * 15 * 70 kbps = 2,100 kbps
-> MPP1 Phone
50 2 * 50 * 80 kbps = 8,000 kbps
-> PSTN via LGW
0 0 * 80 Kbps
-> PSTN via CCP
Webex App / MPP1 Phone -
15 2 * 15 * 80 kbps = 2,400 kbps
> Enterprise via LGW
Webex App / MPP1 Phone -
5 5 * 70 kbps = 350 kbps
> Webex Calling Voicemail
TOTAL CALLS / BANDWIDTH 100 calls 14,950 kbps / 14.95 mbps

1
Multiplatform Phone (MPP)
Note: All bandwidth values in Table 4 and Table 5 refer to IP bandwidth. Link
bandwidth is higher depending on WAN encapsulations.
Note: The bandwidth in Table 4 and Table 5 is for audio calls. For video call
bandwidth, Webex App and the MPP 8845/65 phones support H.264 video with
maximum resolution of 720p at a maximum bandwidth of 1,500 kbps per call.
However, the amount of bandwidth consumed at any point during the will fluctuate
based on variable bit rate inherent in video communications.
Webex Calling requires reliable Internet connectivity and offers global reach from
all the customer locations thus, eliminating the need for endpoint survivability. If an
Transition
SRST like option for endpoints is critical to the existing deployment, then Webex
Calling should not be considered as a migration option.
Call Recording
Call Recording integration is between Webex Calling and Dubber (partner offering)
data centers and all recorded media is securely kept in the cloud. If compliance
and regulation require media be kept on-premises or in your country of
deployment, understand this option is not available as part of the call recording
architecture.
Voicemail
Voicemail is an integral part of the Webex Calling offer and integration with a
premise-based voicemail solution such as Cisco Unity Connection or Cisco Unity
Connection Express is not available. Further, there is no ability to migrate existing
Unity Connection voicemail messages or greetings to the native voicemail service
available with Webex Calling. Likewise, there is no migration of Unity Connection
call handlers and auto-attendant functionality to Webex Calling, however, the basic
auto-attendant functionality available with Webex Calling may be configured as a
possible replacement.
PSTN Connectivity with Local Gateway

Local Gateway is an essential component of the transition strategy and the Local
gateway platform must be either a Cisco Integrated Services Router (ISR) 4000
series, Cisco 1100 Integrated Services Router series, or Cloud Services Router
(CSR1000v) series.
Currently, Webex Calling allows no more than 250 concurrent sessions from a
single Local Gateway, which by default becomes the session count limit for Local
Gateway based PSTN calls and Inter-site calls between Unified CM and Webex
Calling endpoints. If a Local Gateway deployment requires more than 250
concurrent calls, please contact Cisco Technical Assistance Center (TAC) to
request increasing this limit.
Any calls exceeding this limit are rejected with a “403 Forbidden”. The “show call
active voice” command can be run on the Local Gateway at any instance to
determine the total number of active calls.
Contact your Cisco account team to explore other deployment options if you need
a higher number of concurrent sessions.
Transition
Poor network conditions between Local Gateway and Webex Calling access SBC
can limit the performance of the signaling connection leading to an even lower
concurrent calls limit. One-way latency between the Local Gateway and the Webex
Calling data center should not exceed 100 ms and the jitter should be less than
10 ms.
2. Perform network readiness assessment
Customers need to conduct a network assessment prior to migrating to Webex

Calling. It is recommended to confirm network bandwidth availability for expected
call volume, ensure quality of service (QoS) requirements are met, and understand
the various ports that must be opened in the edge firewall(s).
For more details on network requirements for Webex Calling, refer to the Cisco
Webex Calling Customer Network Minimum Requirements Service Guide available
at:
https://callinghelp.cisco.com/wp-content/uploads/2019/05/WC-Customer-
Network-Minimum-Requirements-Guide-v2.2_062019.pdf.
Customers can also use cscan.webex.com for network assessment which gives
information on customer’s network quality, how many calls can be established,
latency, and so on. For more information on the cscan tool, refer to the Use CScan
to Test Webex Calling Network Quality article available at
https://help.webex.com/en-us/y27bej/Use-CScan-to-Test-Webex-Calling-
Network-Quality.
3. Understand Webex Calling region selection
Webex Calling operates five regional platforms as shown in Figure 5: North

America, Canada, EMEAR, APJC (Japan) and APJC (Australia). Each Webex Calling
instance provides redundant datacenters within that region.
Transition
Figure 5. Webex Calling Regional Datacenters
Each Webex Calling customer is provisioned on one of the four Webex Calling
instances. All provisioning information of that customer is stored in that Webex
Calling instance and the SIP signaling of all endpoints and Local Gateways
provisioned for that customer is tied to the Webex Calling instance the customer is
provisioned on. Because the initial Webex Calling region selection cannot be
changed later it is important to consider all relevant factors as part of the decision
process leading to the Webex Calling region selection. To avoid excessive
signaling round-trip delay it is important to decide early in the transition process
which Webex Calling instance should be used. Cisco recommends selecting the
Webex Calling instance which provides the lowest signaling round-trip times for
the largest number of users within the deployment.
Another factor to consider in the Webex Calling region selection is the country
availability of PSTN services provided by Cloud Connected PSTN (CCP) providers
available within that region. While during the transition period PSTN access for
Webex Calling devices must be facilitated via a Local Gateway to enable
interworking with Unified CM registered devices, after successful completion of the
transition, PSTN access for Webex Calling may be switched to CCP. At that point
the country availability of the CCP providers available within the Webex Calling
region becomes an important factor.
Refer to the Cloud Connected PSTN providers list available at

https://community.cisco.com/t5/collaboration-voice-and-video/cloud-connected-
pstn-provider-partners-for-cisco-webex-calling/ta-p/3916211. In addition, for
Transition
Webex Calling country availability refer to the Where is Cisco Webex Available
article https://help.webex.com/en-us/n6fwepj/Where-is-Cisco-Webex-
Available#id_98285.
4. Analyze deployment dial plan
Each user in Webex Calling is provisioned with an extension. The extension length
is a fixed global setting: all extensions in a Webex Calling deployment have the
same length. Extension dialing can be used between Webex Calling users both
within a location and between locations. Abbreviated inter-site extension dialing
(the latter case) only works if the dialed extension is unique.
The dial plan described in the Preferred Architecture for Cisco Collaboration 14
Enterprise On-Premises Deployments, CVD does not support abbreviated inter-site
extension dialing. Instead, the Preferred Architecture for Cisco Collaboration 14
Enterprise On-Premises Deployments, CVD recommends establishing an enterprise
specific numbering plan by prefixing the extensions with a unique steering digit
followed by a fixed length site code and to use this number format for abbreviated
inter-site dialing.
Table 6 shows an example of three locations where the extension ranges of two
locations, NYC and RTP, are identical. Establishing an enterprise numbering
scheme with inter-site steering digit “8”, followed by a three-digit site code, and
the four-digit extension creates a non-overlapping abbreviated inter-site dialing
habit.
Table 6. Enterprise Numbering Example
Extension Enterprise
Site Site Code
Range Range
NYC 2XXX 202 8 202 2XXX
SFO 3XXX 203 8 203 3XXX
RTP 2XXX 204 8 204 2XXX
To allow for a smooth transition the set of dialing habits for users before and after
transitioning to Webex Calling ideally should be the same. To prepare for the
transition for each location the DID ranges and extension ranges (or abbreviated
intra-site dialing habits) need to be documented. Based on this information then
the inter-site steering digit needs to be selected.
Transition
Table 7 shows an example of three locations and fixed length extension ranges.
Because overlapping dialing habits need to be avoided, it is important to make sure
that for any extension range the first digit of the range does not match the steering
digit for abbreviated inter-site dialing. If for example “8” is selected as the steering
digit for inter-site dialing, then no extension range in any site can start with “8”.
Typically, the extensions at a given location match the last few digits of the DIDs
assigned to that location. To avoid conflicts the first digit of the extension can be
changed. If, for example, DIDs in the +1 408 555 8XXX range are used in a given
location, then instead of using 8XXX as extension range 7XXX can be used for the
extensions in that site.
Table 7. Fixed Length Webex Calling Extension Ranges
Extensions (Pre- Webex Calling Enterprise

Site Site Code
Transition) Extensions Range
NYC 2XXX 2XXX 202 8 202 2XXX
SFO 8XXX 7XXX 203 8 203 7XXX
RTP 1XX 11XX 204 8 204 11XX
Any seven-digit dial string dialed on a Webex Calling device using the US Webex
Calling dial plan always gets transformed to a full 10-digit national number. This
behavior makes it impossible to use seven-digit enterprise numbering schemes
with Webex Calling. If the existing enterprise numbering schema and the
corresponding abbreviated inter-site dialing habit has seven digits, then during the
transition to Webex Calling the numbering schema must be changed to a longer or
shorter form. The easiest way to achieve this is to add an additional padding digit
to the numbering schema. The new longer inter-site dialing schema only needs to
be adopted by users already migrated to Webex Calling. Users still on Unified CM
can continue to dial seven digits. The enterprise dial plan on Unified CM in this
case needs to make sure that abbreviated seven-digit dialing from Unified CM to
Webex Calling gets transformed to either +E.164 or to the abbreviated dialing
format deployed on Webex Calling. This needs to be done before sending the call
to the Local Gateway.
Table 8 shows an example how this renumbering. In this example abbreviated

inter-site dialing on Unified CM uses steering digit “8” followed by a two-digit site
code and a four-digit extension. To avoid seven-digit abbreviated inter-site dialing
Transition
for locations on Webex Calling, the site codes can easily be changed to three digits
by prefixing an arbitrary padding digit (“8” in the example) to the two-digit site
codes used in Unified CM so that inter-site dialing from Webex Calling phones
uses steering digit “8” followed by the padding digit “8”, the old two-digit site
code, and the four-digit extension. Users on Webex Calling don’t need to
remember new site codes; they only need to remember to use “88” as prefix for
inter-site dialing instead of “8” on Unified CM.
Table 8. Transitioning Seven-Digit Dialing
UCM Webex Calling
Enterprise Enterprise
Site Extensions Site Code Site Code
Range Range
NYC 2XXX 22 8 22 2XXX 822 8 822 2XXX
SFO 8XXX 23 8 23 7XXX 823 8 823 7XXX
RTP 1XXX 24 8 24 11XX 824 8 824 11XX
In a scenario with different enterprise number formats on Unified CM and Webex

Calling if enterprise numbers are presented as calling party information for calls
from Unified CM to Webex Calling (for example for calls from devices without a
DID), it is important to also implement a mapping between the different number
formats for calling party information to ensure callback works. This mapping can be
achieved by using calling party transformation pattern on the trunk between Unified
CM and the Local Gateway.
5. Inventory existing locations/sites
To prepare for the provisioning of locations on Webex Calling the required

information for all migration target locations needs to be collected. Table 9
summarizes the information needed for each location.
Transition
Table 9. Information to Capture for Each Location
Information Comment
 Each location in Webex Calling can have

extensions starting with different digits. One digit
must be spared for the inter-site dialing steering
digit (for example “8”) and one for the PSTN
Extension Range(s)
steering digit (for example “9”). No extension range
can start with either of these two digits.
 All extension ranges of all locations must be of
equal length.
DID Range(s)
PSTN Steering Digit
All site codes of all locations need to be unique and to
Site Code
have the same length.
When creating a location two DIDs need to be
provisioned. One as main number (for example to be
Main Number
assigned to an auto attendant service) and one for the
voicemail portal.
Voicemail Number See above
Number of Licenses
Sum of concurrent calls between Webex Calling
devices and between Webex Calling devices and the
Concurrent Calls in
Local Gateway (PSTN and calls to Unified CM devices).
the Busy Hour
Needed to determine the required internet access
bandwidth
Country
Time Zone
Language
Contact
(Name, Phone, Email)
Address
(Street Address, City,
State, Zip Code)
Transition
Device dispatchable location used for emergency

Emergency Services calling generally includes the following: building
Physical Dispatchable address, building address + floor number, building
Location for Endpoints address + suite number, or building address + floor
number + office/cubical number.
Physical network location for emergency calling

Per Device Unique generally includes the following: switch / switchport for
Physical Network wired devices, wireless access point (AP) basic service
Location for set identifiers (BSSIDs) for wirelessly connected
Emergency Services devices, and/or on-premises IP subnet(s) for endpoint
devices.
6. Understanding PSTN access options
When it comes to PSTN access for Webex Calling, it is important to understand the
following considerations:
 PSTN is required for off-net calling and between enterprises.
 Cisco never supplies the PSTN.
 Only one PSTN option per location is possible:
o Cloud Connected PSTN (CCP).
o Cisco Local Gateway for on-premises PSTN and Unified CM integration.
 Emergency call routing and lawful intercept are the responsibility of the PSTN
provider.
A Local Gateway is required to create a connection between Webex Calling and
Unified CM as long as Unified CM and Webex Calling coexist. This connection is
not only required to route all calls between Unified CM registered devices and
Webex Calling registered devices; it also provides PSTN access for all Webex
Calling devices. PSTN access for each location in Webex Calling can either be
facilitated by a CCP provider or via a Local Gateway. It is not possible to setup
Webex Calling so that inter-enterprise calls originating from within a given Webex
Calling location use a Local Gateway while PSTN calls use a CCP provider. This
limitation implies that during the transition PSTN access for both, Unified CM
registered devices and Webex Calling devices, needs to be through PSTN trunks
controlled by Unified CM. Only at the end of the transition, when no Unified CM
registered devices remain, PSTN access for all users can be moved to a CCP
provider. These steps are shown in Figure 6.
Transition
Figure 6. PSTN Transition
Before proceeding, it is important to understand the Local Gateway and CCP

architectures as shown in Figure 7.
Figure 7. Local Gateway and Cloud Connected PSTN (CCP) Architecture
Transition
At the on-premises side, the Local Gateway relies on a SIP connection or trunk to
Unified CM and in the case of IP-based PSTN connections a SIP trunk is also used
to communicate with the IP PSTN provider network. To connect to Webex Calling
in the cloud, the Local Gateway communicates via secure SIP TLS to the Webex
Calling service. This connection is anchored at a Webex Calling cloud-hosted
Access Session Border Controller (SBC) which serves as the gateway to cloud
calling services. In all cases, the Local Gateway relies on RTP or sRTP (encrypted
RTP) for all media connections.
In the case of CCP, cloud-hosted Peering SBCs serve as the SIP interconnect to
CCP provider partner networks. The Peering SBCs are responsible for all
integration aspects with the partner network.
The choice to eventually deploy a CCP option or a Local Gateway is up to the

customer. With the CCP option, a customer does not need to invest in local
gateway hardware and maintenance. Additionally, with a CCP option, there is no
media hair-pinning to the Webex Calling cloud.
On the other hand, a Local Gateway allows the customer to re-use an existing UC
enabled Cisco ISR or CSR1000v router (assuming the existing ISRs or CSR1000v
router are supported for Local Gateway and that the scalability of the existing
platforms is sufficient to carry the additional load of the Local Gateway role). This is
also preferable if they have a pending service contract with their current PSTN
provider. It also allows for PSTN interconnect in locations not supported by the
Cloud connected PSTN provider.
A single Local Gateway can be deployed and utilized by multiple Webex Calling
locations. However, only a single local gateway can be assigned to a location within
Control Hub. Further, if during the transition multiple split sites (some users within
the same location still on Unified CM and some already on Webex Calling) with the
same extension range exist and extension dialing from Webex Calling to Unified
CM is a requirement, then on Unified CM for extension dialed calls from Webex
Calling to Unified CM a location specific dialing context needs to be established to
enable Unified CM to differentiate between extension dialed calls from different
locations. This can be achieved by configuring dedicated Local Gateways for each
location requiring split site extension dialing so that the dialing context on Unified
CM can be established via calling search spaces inbound on the now location
specific trunks from the different Local Gateways. These Local Gateways do not
require dedicated CUBEs. All Local Gateways can be configured as “logical”
Transition
instances on the same CUBE (or CUBE High Availability pair) by overlaying the
Local Gateway specific dial-peer sets within the CUBE configuration.
For all IP-based environments, customers have the option to deploy CUBE high
availability as Local Gateway for call preservation. CUBE high availability Layer 2
box-to-box redundancy uses the Redundancy Group (RG) Infrastructure protocol
to form an active/standby pair of routers. The active/standby pair share the same
virtual IP address (VIP) across the respective interfaces and continually exchange
status messages. CUBE session information is check-pointed across the
active/standby pair of routers enabling the standby router to immediately take over
all CUBE call processing responsibilities if the active router should go out of
service, resulting in stateful preservation of signaling and media.
Note: Check pointing is limited to connected calls with media packets. Calls in
transit are not check pointed, for example, Trying or Ringing state.
Refer to Figure 8 below which depicts a typical CUBE high availability as Local
Gateway setup.
Figure 8. CUBE High Availability with Local Gateway
The CCP option entails a static SIP trunk from the Webex Calling data centers to
CCP provider data centers. Redundancy is achieved by full mesh connectivity
between two Webex Calling data centers and two CCP provider data centers and
failover is automatic and transparent to end users. Figure 9 shows this high
availability architecture.
Transition
Figure 9. Cloud Connected PSTN High Availability
When a customer Location is added within Webex Control Hub, the customer
administrator may select a CCP provider from the list of integration options. The
country of the customer location determines which CCP providers appear in the
drop-down list. Only CCP providers that support that country are displayed.
7. Inventory existing endpoints/clients.
Before beginning the transition it’s important to inventory your existing hardware
and software endpoints. Having a complete list of phone types, models, and
quantities will ensure you can adequately plan for transitioning endpoints and
mitigating the impact to your deployment for those devices that cannot be migrated
to cloud calling. The inventory should be used to determine the endpoints to
transition, the endpoints to replace prior to the transition, and the endpoints that
may remain managed and registered to on-premises call control.
Desk Phones
For audio and video VoIP desk phones including Cisco IP Phone 7800 and 8800
series, Cisco Unified IP Phone 7900 series, and other personal desk endpoints,
only the 7800 and 8800 series endpoints are supported with Webex Calling. Prior
to transition these phones must be migrated to Multiplatform Phone (MPP) in order
to be transitioned to Webex Calling.
Transition
All other desk phones will need to be replaced with 7800 and 8800 series
endpoints or must remain registered to Unified CM if you plan to maintain them.
Video Endpoints
Personal and room video endpoints including the Webex series, Webex Room
series, Webex DX series, and other hardware video endpoints are not supported
with Webex Calling. These devices must remain registered to on-premises Unified
CM or transitioned to the Webex platform (registered as Webex Devices) if cloud
registration is desired.
Note: When video devices are moved from Unified CM registration to Webex, the
URI for these endpoints will change as they are now cloud registered.
The underlying assumption for video endpoints in this deployment is that they are
running CE firmware and are shared endpoints used for point-to-point video calling
and multi-point on-premises or cloud-based conferencing.
Note: Phone models 8845 and 8865 are personal video endpoints and are
supported with Webex Calling.
Soft Clients
Cisco Jabber clients on desktop and mobile platforms are not supported with
Webex Calling. Depending on the deployment mode(s) implemented for Jabber
(IM-only, phone-only, and/or full UC modes), you may decide to maintain Jabber
registration to Unified CM and other on-premises services (Unified CM IM&P, Unity
Connection, Cisco Meeting Server). On the other hand, users may be transitioned
to the Webex app, the preferred cloud-based software client. Moving users to the
Webex app may be done prior to transitioning to Webex Calling to give users time
to familiarize themselves with the new application. Alternatively, users may be
migrated from Jabber on-premises services in phases after the transition to Webex
Calling begins.
To ease the initial transition to Webex app, consider moving users to the Webex
app with Unified CM calling, so they can begin using cloud messaging and meeting
services while at the same time enjoying the existing on-premises Unified CM
calling experience.
Transition
8. Inventory and plan for existing users transition to Webex Calling
Determine which users within the existing set of on-premises calling users will be
transitioned to Webex Calling. If all users will be transitioned, but the number of
users is large, it is a good idea to move users in groups in order to ensure that IT
staff and support personnel are able to handle the transition and any issues that
may arise. You should also allow some time to provide initial information and
training sessions to prepare users for this transition. User transition grouping can
be done based on a variety of criteria including the location or site users are
assigned to, users’ departments, or even user types (knowledge workers,
executives, mobile workers, and so on).
As an example, if users in the deployment are divided across three main sites, New
York (NYC), San Francisco (SFC), and Research Triangle Park (RTP), a user
transition plan may look like the plan outlined in Table 10 below.
Table 10. User Transition Plan by Site
Pre-transition
User Site / Post-Transition
Information and Transition Period
Location Support
Training Sessions
NYC
Week of April 1 April 15 – April 27 Week of April 29
(1,525 users)
SFO
Week of May 6 May 20 – May 31 Week of June 3
(1,600 users)
RTP
Week of June 3 June 17 – June 28 Week of July 1
(1,275 users)
Transition Steps and Considerations

Below is a summary of transition steps required for the transition from Unified CM on-
premises calling to Webex Calling in the cloud. You should only perform these steps
during a planned maintenance window for your organization. Before proceeding you
should back up all collaboration and infrastructure systems if you must back out or
abandon the transition.
Follow these transition steps to move from on-premises calling (Unified CM) to cloud
calling (Webex Calling):
Transition
1. Order Webex Calling
To begin the transition, a Webex Calling organization with proper licensing is

required. For information on ordering Webex Calling and licensing, start with the
Webex Calling datasheet available at
communications/webex-calling/datasheet-c78-742056.html.
CUBE Trunk Licenses (CUBE-T-STD or CUBE-T-RED) are included as part of the

Webex Calling subscription at a ratio of one license for every two knowledge
workers. However, unified communications and security platform licenses for the
hardware-based platforms or AX technology package and throughput licenses for
CSR1000v platform are not included and must be procured separately before
beginning with the transition.
For more details, check the "Local Gateway for Webex Calling Ordering Guide" at
communications/unified-border-element/guide-c07-742037.html.
2. Implement required network and firewall changes.
The first step in transitioning to Webex Calling is ensuring that there is connectivity
over the Internet between the on-premises network and the Webex cloud. Most
organizations do not connect directly to the Internet, but instead connect through
one or more firewalls. For this reason, it is important to understand the traffic flows
required between the on-premises network and Webex for Webex Calling.
Network and security administrators must understand these flows in terms of
direction, protocols, IP addresses, and port numbers so that corporate firewalls and
other network components can be configured to accommodate this traffic.
For information on the required flows including IP address, ports, and protocols
refer to the Port Reference Information for Cisco Webex Calling article available at
https://help.webex.com/en-us/b2exve/Port-Reference-Information-for-Cisco-
Webex-Calling.
Use this information to properly configure the firewall, proxies, and other network
infrastructure in the existing deployment to enable Webex Calling network flows.
Transition
3. Prepare Webex Control Hub for directory integration and user

provisioning.
Before enabling directory integration between the corporate directory and the
Webex cloud identity store, the following set of summarized steps should be taken:
i. Add and verify organization domain(s).
ii. Convert existing users.
iii. Claim organization domain(s).
iv. Set up SSO.
v. Suppress automated user email invitation.
vi. Determine license assignment method.
Each step is explained in detail below.
i. Add and verify organization domain(s).
To add a domain to your Webex organization use the Add Domain option under
Settings > Domain in Webex Control Hub (https://admin.webex.com/). Start by
entering the administrator domain and click Add. Then find the verification token
by selecting Retrieve verification token (available by clicking the ellipsis (…) next
to the domain name). This verification token must then be added as a DNS TXT
record to your DNS host. Once this is done click Verify next to the domain. If
successfully verified, you will see “Verified” next to your domain. Repeat this
process for each domain owned by your organization.
Note: You must add and verify the administrator domain first. Failure to do so
will result in administrator lockout.
ii. Convert existing users.
Existing users from other organizations, including in the free consumer

organization are not automatically converted to your organization. You will need
to convert these users manually. You should convert consumer users to your
organization(s) before claiming the domain. That way, these users will not
receive notification after domain claim.
Transition
iii. Claim organization domain(s).
As a further security measure claim organization domain(s). By claiming your

domain(s), you are marking an email domain for use only in your Webex
organization. This prevents users with the claimed domain from existing in any
other organization, including the free consumer organization.
To claim a domain for your Webex organization under Settings > Domain in
Control Hub (https://admin.webex.com/), click the ellipsis (…) next to the
domain you added and verified previously and select Claim verified domain.
After claiming the domain, you will see “Claimed” next to your domain. Repeat
this process for each domain owned by your organization.
Note: Once a domain is claimed, any administrator outside of your organization

that attempts to add a user with this domain will receive an error message.
For more information on adding, verifying, and claiming domains refer to the
Add, Verify, and Claim Domains article available at https://help.webex.com/en-
us/nxz79m5/Add-Verify-and-Claim-Domains.
iv. Set up SSO.
While optional, the use of single sign-on (SSO) is recommended to provide the
best end-user experience. The benefit of SSO is that a user can use a single
common set of credentials for authenticating to any Webex services as well as
other collaboration applications. With SSO, a user only must provide credentials
a single time per session in order to be authorized for any services they are
subscribed to.
To enable SSO for the Webex organization, from Control Hub navigate to
Settings and scroll down to Authentication, click Modify and then, select the
Integrate a 3rd-party identity provider. (Advanced). Next, click the Download
Metadata File button to download the file for import to your Identity Provider
(IdP).
At this point you will need to configure your IdP as appropriate and import the
metadata file you downloaded from Control Hub. Then, download or export the
metadata file from your IdP.
Return to Control Hub and on the Import IdP Metadata screen, drag and drop
the IdP metadata file or navigate to the file using the file browser. Next, under
Transition
Signing of Metadata (Advanced) select Require certificate signed by a

certificate authority in Metadata (more secure) (unless IdP certificate is not
signed by a CA, in which case you can select the less secure Allow self-signed
certificate in Metadata option).
Finally, test the SSO setup by clicking the Test SSO Connection button. When
prompted enter valid SSO credentials to confirm SSO is working properly.
Assuming the test is successful, select This test was successful. Enable Single
Sign-On and click Next to complete the SSO configuration.
For more information on tested IdPs and enabling SSO for your Webex org refer
to the Single Sign-On Integration in Control Hub article available at
https://help.webex.com/en-us/lfu88u/Single-Sign-On-Integration-in-Control-
Hub.
v. Suppress automated user email invitation.
You should prevent automated email invitations to users when assigning

licenses to users in your organization in order to activate users without
interaction. These email invitations are not necessary and can cause confusion.
These automated emails provide an initial password (not required with SSO),
requests user validate their activation (not required with verified domain), and
requests user provide additional user account details (not required with
Directory Connector LDAP integration).
To prevent these automated invitations, from Control Hub navigate to Settings,

scroll to Enroll, and toggle the Suppress Admin Invite Emails setting to on and
click Save.
Note: This setting toggle may only be turned on when SSO is enabled.
vi. Determine license assignment method.
Before proceeding, it is important to decide on the method of license

assignment you will use for the deployment. Assigning Webex Calling licenses
is a manual process and must be done after users are available in the Webex
organizations identity store. However, the simplest method for assigning other
licenses (for example, meeting and messaging) is to automatically assign
licenses using the Auto-Assign template for all users synced to the organization
from Directory Connector.
Transition
To configure automatic license assignment for synced users, in Control Hub

navigate to Users and select the Manage Users button. On the Manage Users
page click Set up Auto-Assign Template link in the Licenses section. Next,
select the desired message, meeting, and/or hybrid services licenses you wish
to automatically assign to synced users. Review the license summary and then
click Save to save the template.
Note: One point of consideration when using Auto-Assign template to assign

licenses automatically to synced users is the potential for license starvation
when importing users from Directory Connector. With this method, all users that
are synced from Directory Connector will be automatically consume the licenses
assigned by the template, even if they are not actively using Webex services.
Alternatively, users can be synced from Directory Connector without using the
Auto-Assign template and licenses can be assigned later using the CSV method
for bulk user updates.
4. Directory integration
The first step for transitioning users to Webex Calling is importing users from the
on-premises directory to the cloud identity store for the Webex Calling
organization. In addition to initially importing users to the cloud organization, regular
synchronization of user information from the corporate directory to the cloud
common identity store is imperative to ensure identity information is consistent in
both places.
The preferred method for importing and synchronizing users between the on-
premises corporate directory and the identity store in Webex is to use hybrid
directory service with Cisco Directory Connector. Directory Connector running on a
Windows domain server retrieves user information from the corporate Active
Directory and synchronizes this information to the cloud identity store using REST-
based APIs. The administrator can determine which users are synchronized and
what attributes are mapped between the on-premises and cloud directories based
on sync agreement configuration. This synchronization is performed at regular
intervals to ensure the cloud common identity store is up to date with any changes
to the corporate Active Directory environment.
Deploy and Configure Directory Connector

Begin by downloading the Directory Connector software from Control Hub
(https://admin.webex.com/). Navigate to Users, click Manage Users, click Enable
Directory Synchronization, and then choose Next.
Transition
Next, click the Download and Install link to save the latest version of the connector
installation .zip file to the target Windows domain server. Unzip the file and run the
.msi setup file in the setup folder.
Note: For Windows server and other deployment requirements refer to the
Deployment Guide for Directory Connector available at
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark
/hybridservices/directoryconnector/cmgt_b_directory-connector-guide-
admins.html
Note: A separate instance of Directory Connector is required for each domain in

the organization. Further, for redundancy, two Directory Connectors (per domain)
should be installed and configured on two separate Windows domain servers. If the
primary Directory Connector server for a domain fails, the secondary Directory
Connector can take over and maintain directory synchronization for that domain.
Once installation is complete, launch Cisco Directory Connector and sign into the
Webex organization by entering the email address and password of the
administrator account for the organization. Note that this is the same email address
and password used to log into the Control Hub management portal. Click to
confirm the Webex organization and domain.
Next, perform initial configuration of Directory Connector. From the Directory
Connector dashboard click the Configuration tab. At a minimum configure the
following:
 Under General specify the Connector Name, for example, DIRSYNC1 (this
name will be displayed in Control Hub under Directory Synchronization
settings). Add one or more Windows Domain Controllers based on your
Windows environment (two domain controllers are recommended for
redundancy purposes).
 Under Object Selection, at a minimum, tick Object Type: Users and configure
LDAP filter(s) as required. Specify Base DNs to synchronize by clicking the
Select button and specifying the container(s) in Active Directory you wish to
synchronize.
 Under User Attribute Mapping configure any required Active Directory to
Webex attribute name mappings by selecting options from the Active
Directory attribute drop-down lists. At a minimum, ensure that the Active
Directory attribute name mail is mapped to the required Webex attribute name
Transition
uid. The mail attribute plays a key role in Webex because it uniquely identifies
the user.
On the redundant Cisco Directory Connector, configure the same settings outlined
above, but use a unique name for the Connector Name setting (for example,
DIRSYNC2).
Once the base configuration is complete, click the Dashboard tab and then click
Sync Dry Run and click OK to confirm. A dry run validates your configuration and
ensures the expected user accounts will be synchronized prior to performing a full
synchronization. Review the dry run report to check for user or other sync
anomalies (especially mismatched users). Click Done to close the dry run report.
If no issues are found, next, perform a full sync by navigating to Actions > Sync
Now > Full. Click Yes to confirm the request.
After the first full directory sync has completed, you should configure the
synchronization schedule to ensure any changes to Active Directory (additions,
modifications, and/or deletions) are reflected in the Webex organization.
From the Directory Connector dashboard click the Configuration tab and under
Schedule specify the following:
 The Incremental Sync Interval in minutes (for example, 30 minutes) which
determines how often an incremental sync is performed. An incremental sync
picks up user account adds, changes, and deletions in Active Directory.
 Tick Enable Full Sync Schedule and select the time and day(s) of week to
perform a periodic full synchronization (for example, 11:30 PM on F(riday)). A
full sync picks up user avatar, attribute mapping, base DN, and LDAP filter
addition/changes as well as adds, changes, and deletions of user accounts.
 Specify the Failover Interval in minutes (for example, 60 minutes) before the
secondary Directory Connector becomes primary and takes over incremental
and full synchronization. This setting applies for high availability deployments
with more than one Directory Connector (recommended).
For more details on deploying and configuring Directory Connector refer to the
Deployment Guide for Cisco Directory Connector available at
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark
/hybridservices/directoryconnector/cmgt_b_directory-connector-guide-
admins.html.
Transition
Alternatively, rather than using Directory Connector, users may be manually added
to the Webex organization common identity store individually or in bulk using CSV
files. This is a manual process adding administrative overhead but may make sense
for small deployments.
5. Setup and verify Local Gateway
Prior to setting up the Local Gateway for Webex Calling, ensure that Webex Calling
has been licensed and enabled for the organization, and the Local Gateway has
been onboarded within the Control Hub. For more details, refer to the Webex
Calling deployment guide.
Baseline Local Gateway platform configuration must be configured according to

your organization's policies and procedures and should include:
 Network Time Protocol (NTP) server access for time synchronization.
 Access Control Lists.
 Layer 3 interface(s) with valid and routable IP addresses assigned.
 IOS-XE security changes configuration requirements (master password and
AES encryption).
 Enable passwords.
 IP Name Server to enable DNS lookup and ensure it is reachable by pinging it.
Then apply the following Local Gateway specific configuration:

 Enable TLS 1.2 exclusivity and a default dummy trustpoint.
 Update the Local Gateway trustpool by downloading the latest “Cisco Trusted
Core Root Bundle” from http://www.cisco.com/security/pki/.
 Map parameters obtained from the Control Hub onboarding to IOS-XE CLI
including global voice service voip configuration.
 Configure appropriate dial-peers for call routing.
Once the Local Gateway registers to the Webex Calling Access SBCs successfully,
it will show up as Online within Webex Control Hub. Additionally, registration status
can be verified using the show sip-ua register status command as shown below
with the reg (registration) value showing “yes”.
Transition
6. Configure call routing
During the transition to allow for coexistence of devices registered on Unified CM

and on Webex Calling the enterprise dial plan on Unified CM needs to be changed
to that at least the following requirements can be met:
 +E.164 dialing from Unified CM to Webex Calling.
 Extension dialing from Unified CM to Webex Calling (intra-site but also inter-
site if the extension ranges are unique).
 Abbreviated inter-site dialing from Unified CM to Webex Calling.
 Forced on-net dialing from Unified CM to Webex Calling.
 Call-back from missed calls directory to destinations on Webex Calling.
 PSTN calls from Webex Calling to PSTN.
 Forced on-net from Webex Calling to Unified CM.
 Extension dialing from Webex Calling to Unified CM (inter-site).
If any of the above are not supported dialing habits prior to the transition, for
example no abbreviated inter-site dialing habit exists, then they don’t necessarily
need to be introduced during the transition.
Figure 10 shows the best practice dial plan approach as described in the
“Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises
Deployments, CVD”. Key characteristics of this approach include:
 Single partition for +E.164 directory numbers.
 Core routing based on +E.164 route patterns.
 Normalization of all dialing habits to +E.164 using translation patterns.
 Use of translation pattern calling search space inheritance (option “Use
Originator's Calling Search Space” set on translation patterns).
Transition
Figure 10. Best Practices Dial Plan
For example, PSTN dialing (9+1+10D) from a device in SJC provisioned with line
calling search space “SJCInternational” will first get matched by the
“9.1[2-9]XX[2-9]XXXXXX” translation pattern which normalizes the called party
number to +E.164. The secondary lookup then uses the same calling search space
“SJCInternational” again (calling search space inheritance) and the +E.164-digit
string will either get matched by a +E.164 directory number in the “DN” partition or
by one of the PSTN route patterns in the “USPSTNNational” or “SJCPSTNLocal”
partition. Abbreviated intra-site and inter-site dialing habits are implemented by the
translations in the “ESN” and “SJCtoE164” partition. While the “ESN” partition is a
global partition (accessible for phones in all locations) the “SJCTOE164” partition is
only accessible for users in location SJC. This is assuming overlapping extension
ranges.
The first step to enable calling from Unified CM to Webex Calling is to make sure
that +E.164 destinations get routed accordingly. This can be achieved by adding a
“WebexCalling” partition to the dial plan, adding +E.164 route patterns for all
Webex Calling destinations to that partition, and finally adding the “WebexCalling”
Transition
partition to all calling search spaces representing classes of service which need to
be able to reach Webex Calling. Creating a dedicated “WebexCalling” partition is
required to enable creation of a differentiated class of service for calls originating
from Webex Calling. To avoid call loops the inbound calling search space on the
trunk from the Local Gateway should not have access to the “WebexCalling”
partition.
As shown in Figure 11 to enable routing from Unified CM to Webex Calling for a

location with +E.164 DID range +1 221 555 2XXX and site code 212 an urgent
route pattern matching this +E.164 range needs to be added to the “WebexCalling”
partition.
Figure 11. +E.164 Routing to Webex Calling
If no site-specific Local Gateway selection is required, then instead of using a route

list with a Webex Calling Local Route Group as the destination for route patterns
pointing to Webex Calling a single route group can be provisioned with the Local
Gateway as the only member and then the Webex Calling route patterns point to a
single Webex Calling route list with this one route group as only entry.
To enable inter-site abbreviated dialing to the Webex Calling site the required
dialing normalization translation pattern “8121.2XXX” is added to the already
existing ESN partition. This is the same dialing normalization translation pattern
which also needs to be provisioned for a site with this site code on Unified CM: for
Transition
sites to be transitioned to Webex Calling this enterprise abbreviated dialing

normalization patterns already exists and does not need to be provisioned to
transition that Unified CM site to a Webex Calling location.
With these dial plan changes calls to the Webex Calling location can be placed not
only by dialing abbreviated inter-site and +E.164. Also, international and national
PSTN dialing are possible because these dialing habits are first normalized to
+E.164 via the already existing dialing normalization translation patterns and then
get routed to Webex Calling by matching the +E.164 route pattern in the
“WebexCalling” partition.
The +E.164 route pattern matching on a the Webex Calling location’s DID range
can be provisioned while all DIDs are still hosted on Unified CM. The best match
pattern matching algorithm of Unified CM makes sure that when a number hosted
on Unified CM is dialed then the +E.164 directory number provisioned on Unified
CM is a better match than the wildcarded +E.164 route pattern pointing to Webex
Calling so that the calls get extended to a line on Unified CM and not sent to
Webex Calling.
The Preferred Architecture for Cisco Collaboration 12.x Enterprise On-Premises

Deployments recommends a dedicated enterprise number range for users and
devices without a DID. Directory numbers for these users and phones are
provisioned in the regular “DN” partition using the full ESN format (steering digit
followed by site code and extension). Table 11 shows an example of three sites
with dedicated enterprise number ranges for users without a DID.
Table 11. ESN Ranges for DIDs and Non-DIDs
ESN Range for ESN Range for

Site +E.164 Range Site Code
DIDs Non-DIDs
SJC +1 408 555 4XXX 140 8 140 4XXX 8 140 5XXX
RCD +1 972 555 5XXX 197 8 197 5XXX 8 197 6XXX
NYC +1 212 555 2XXX 121 8 121 2XXX 8 121 3XXX
To enable abbreviated inter-site dialing to these non-DID destinations on Webex

Calling route patterns matching on the non-DID number ranges need to be
provisioned in the “WebexCalling” partition. This is shown in Figure 12.
Transition
Figure 12. Abbreviated inter-site route pattern for non-DID destinations
Equivalent to the +E.164 route pattern again the best match routing logic of Unified
CM makes sure that directory numbers using the enterprise number format are a
better match than the enterprise number route pattern in the “WebexCalling”
partition so that only enterprise numbers which don’t exist on Unified CM get
matched and sent over to Webex Calling.
Preparation
Prior to transitioning the first locations and users to Webex Calling the Local
Gateway configuration and Unified CM configuration needs to be completed as
described in these documents:
 Configure Local Gateway on IOS-XE for Webex Calling:
https://help.webex.com/article/jr1i3r
 Configure Unified CM for Webex Calling:
https://help.webex.com/article/nqqzbk7
Also, in the Webex Calling administration make sure to configure the following
internal dialing settings:
Transition
 Location Routing Prefix Length.
 Set Steering Digit in Routing Prefix.
 Internal Extension Length.
Figure 13 shows an example with steering digit “8”, three-digit site codes (the
steering digit is counted as part of the routing prefix length), and four-digit
extensions. The total length of enterprise number in this case is 8.
Figure 13. Internal Dialing Settings
Transitioning a Location
To prepare for the transition of users from Unified CM to a Webex Calling location
these configuration steps need to be completed:
Transition
 Create location in Webex Calling with the setting collected based on the
information in Table 6 (see step 5. Inventory existing locations/sites in the
Pre-Transition Steps section).
 Define site code and PSTN access code for location.
 Add and activate phone numbers in Control Hub. Adding phone number in
Control Hub does not change Webex Calling call routing. Phone numbers
become active as soon as the number is assigned to user and a device gets
provisioned. All DIDs of users in the location to transition need to be added.
 Provision the site-specific route patterns in the “WebexCalling” partition:
+E.164 and (if needed) enterprise numbers.
7. User provisioning for Webex Calling
Because all users already exist in Control Hub (either through LDAP directory
integration with Directory Connector or manual individual or bulk provisioning), the
next step is to use bulk update (recommended) to enable appropriate users for
Webex Calling, assign them to a location, provision their phones and assign phone
numbers and extensions. The CSV template for this update can be downloaded
from Control Hub by clicking Manage Users and selecting the CSV Add or Modify
Users option. To avoid errors, you can also export all users, filter out the users to
modify and then update the settings only for a selected set of users.
Table 12 provides an overview of the CSV file columns relevant for the user
migration and the required settings. Quotes are used to indicate literal values;
insert the values without the quotes.
Table 12. User migration CSV settings
Column Setting
Extension extension
Phone Number DID (if available)

Caller ID override, if empty for users
with DID the DID is used and for users
Caller ID Number
without DID the locations’ main number
is used
Caller ID First Name Caller ID override; can be empty
Caller ID Last Name Caller ID override; can be empty
Transition
Location Name of location
Jabber with Webex Teams “FALSE”
Jabber Calling “FALSE”

“NATIVE_WEBEX_TEAMS_CALLING”
or “USE_ORG_SETTINGS” if native
Calling Behavior
calling is configured at the organization
level
Webex Calling VAR Enterprise “TRUE”
To enable Webex Calling supplementary user and system features and services,
navigate to Control Hub to update users individually or in bulk (Bulk Edit Users) for
features like call forwarding, voicemail, and so on. Further, enable system features
like auto attendants, hunt groups, call queuing, and so on.
Once users provisioning is complete, the next step is to provision Webex Calling
devices and migrate existing phones as described in the next step.
8. Phone migration and provisioning for Webex Calling
Phones that are currently registered to Unified CM will need to be migrated to

Webex Calling as part of the cloud transition. To make the migration as simple as
possible with minimal chance for failure, Cisco recommends migrating physical
sites or departments at the same time.
In order to become Webex Calling cloud registered devices, the migration process
will use the cloud-based service to deliver the transitional and MPP firmware loads
to complete the migration. Since the transitional firmware loads are phone model
specific, the upgrade process will use common device selection criteria to make
sure the correct phones are migrated to the Webex Calling platform.
The process to migrate phones to Webex Calling can be summarized in the

following 6 steps:
i. Verify phone model support and firmware version.
ii. Upload migration licenses to upgrade.cisco.com.
iii. Provision phones for Webex Calling.
iv. Select phones to migrate.
v. Apply transitional firmware load and MPP firmware load.
vi. Update dial plan to complete migration.
Transition
Each step is explained in detail below.
i. Verify phone model support and firmware version.
The phone migration process is only supported on the 7800 and 8800 phones
(refer to Convert between Enterprise Firmware and Multiplatform Firmware for
Cisco IP Phone 7800 and 8800 Series Guide to verify supported phone
models and versions). Any phone device that does not meet the minimum
model version will need to be replaced with an MPP phone.
Additionally, any supported phone model must be on firmware version
12.5.1SR2 or later. If any phone is on a previous version, then the phone must
be updated to the latest Unified CM firmware prior to applying the transitional
firmware to the phone.
To check to make sure that no phone has a different load than the default
firmware load, in Unified CM, navigate to Device > Device Settings > Firmware
Load Information to load information on firmware loads for the devices
configured on the system as shown in Figure 14.
Figure 14. Firmware Load Information for Existing Devices
Selecting one of the hyperlinks on the Firmware Load Information page will
show you which phones may not be running the current default load. As
shown in Figure 15, any phone that has a name in the ‘Load Information’ field
indicates it is not using the default firmware.
Transition
Figure 15. Non-Default Firmware Load Information
Clicking through on any phone in the list will allow direct access to any device
that needs to be upgraded to the model default firmware version.
The migration process should not continue until all phones to be migrated are
on version 12.5.1SR2 or later.
Note: This procedure was verified using 12.7.1 as the base firmware.
ii. Upload migration licenses to upgrade.cisco.com.
Refer to Appendix A: Flex plan – Ordering and Appendix B: How to generate

licenses for firmware conversion of the Convert
between Enterprise Firmware and Multiplatform Firmware for Cisco IP Phone
7800 and 8800 Series Guide available at
https://www.cisco.com/c/en/us/products/collateral/collaboration-
endpoints/unified-ip-phone-7800-series/guide-c07-742786.html.
After ordering and downloading the licenses for migrating firmware, navigate
to https://upgrade.cisco.com/e2m_converter to upload your migration
licenses to the Cisco Cloud Upgrader service. Cisco Cloud Upgrader is a
service that allows customers to easily upgrade/migrate the software on Cisco
IP Phones so they can connect to Webex Calling.
Once the licenses have been uploaded, you will need to provision the phones
in Webex Calling.
iii. Provision phones for Webex Calling.
Transition
The recommended approach for provisioning phones for Webex Calling is to

use the bulk operation as described in the Configure and Manage Webex
Calling Devices article available at: https://help.webex.com/en-
us/n9r1aac/Configure-and-Manage-Webex-Calling-Devices#id_118912.
Table 13 provides an overview of the CSV file columns for device provisioning
and the required settings. Quotes are used to indicate literal values; insert the
values without the quotes.
Table 13. Bulk device operation settings
Column Setting
Username Email address of user this device is associated with
Type “USER”
Directory Number Leave empty; inherited from the linked user
Direct Line Leave empty; inherited from the linked user
Device Type “IP”
Model Phone model. For example, “Cisco 8865”
MAC address of the phone; 12 characters, no

MAC ADDRESS
separators. For example, “571432DDDE65”
Location Leave empty; inherited from the linked user
Bulk provisioning should also be performed as described above for any new
phones added as part of this transition. This can be done now or later.
Note: Make sure to complete bulk provisioning for all phones to be migrated
before initiating firmware migration in the next step.
iv. Select phones to migrate.
Cisco recommends migrating groups of phones at the same time. A ‘group’ as

used in this document will be any set of phones that have a common
characteristic that can be used to select the phones to be migrated. This may
Transition
include configurations related to Device Pool, Physical Location or Description.

For smaller installations, the grouping could be phone model type.
In order to select a group of phones to migrate, navigate to Bulk

Administration > Phones > Update Phones > Query. The first search criteria
should be phone model and the second should be the grouping criteria.
Device pool is a common setting that can associate a phone to a location. As
shown in the example in Figure 16, the search for device type and grouping
criteria is for all 8865 phones that are part of the Boulder, CO site (they have a
device pool that contains ‘BOULDER’ in the name).
Figure 16. Search by Device Type and Grouping Criteria of Device Pool
Once a group of phones has been returned, click Next.
v. Apply transitional firmware load followed by MPP firmware load.
On the Update Phone page, as shown in Figure 17, select the Apply Config
setting. This instructs the phones to download the new configuration
information after executing the update.
Figure 17. ‘Apply Config’ Setting for BAT Execution
In the Phone Load Name field, specify the correct model specific firmware for
the phone model that was originally selected. In this example, as shown in
Figure 18, the selected 8845/65 phone models will load the configured
transitional firmware load: sip8845_65.TLexE2m-11-2-3C-10.
Figure 18. ‘Phone Load Name’ Setting with Configured Transitional Firmware Load
Transition
Next, the phone needs to be configured with the location to find the migration
firmware files. The Load Server value must be set to use the cloud
downloader. As shown in Figure 19, the cloud downloader URL is
cloudupgrader.webex.com.
Figure 19. ‘Load Server’ Setting of cloudupgrader.webex.com
Note: As shown in Figure 18 and Figure 19, the checkbox on the left side of
the Update Phones page is required for the Phone Load Name and the Load
Server entries. The Bulk Administration update job updates only the entries
that have a check box selected. In this example, only these two values are
getting updated on the selected phones.
At the bottom of the Updates Phones page, change the Job Description name
(in this example ‘Update Phones – 8865_E2M’) and select the Run
Immediately option in the Job Information section (see Figure 20). After
clicking Submit, the batch update will occur immediately, and all selected
phones will download the migration firmware from the cloud upgrade service.
Figure 20. BAT Job Description and ‘Run Immediately’ Setting
Once the phones complete the loading of the interim load, they will contact
the cloud upgrader services, verify the device is entitled to migrate to Webex
Calling and download the latest MPP firmware. All of this happens
automatically once the interim load is successfully downloaded and the phone
reboots.
Each phone model has a different interim load, so the above process must be
repeated for each phone model type to be migrated.
Transition
Table 14 shows the interim firmware loads for all supported models.
Table 14. Interim Firmware Loads for Eligible Webex Calling Devices
Device Type Phone Load
7832 sip7832.TLexE2M-11-2-3C-10
78xx sip78xx.TLexE2M-11-2-3C-10
8832 sip8832.TLexE2M-11-2-3C-10
8845/65 sip8845_65.TLexE2M-11-2-3C-10
88xx sip88xx.TLexE2M-11-2-3C-10
In cases where devices on Unified CM are running firmware versions earlier

than 12.5.1SR2, the process above may be used to download the latest
enterprise phone firmware needed in order to load the interim code. To use
the cloud upgrader to get to the latest enterprise firmware, using the same
selection criteria as above, follow the same directions above, but for the
Phone Load Name setting specify a newer firmware load (minimum
12.5.1SR2). Table 15 below shows the firmware version used to validate this
procedure.
Table 15. Firmware Version Upgrade to Support Migration to Interim Load
Device Type Phone Load
7832 sip7832.12-7-1-0001-393
78xx sip78xx.12-7-1-0001-393
8832 sip8832.12-7-1-0001-403
8845/65 sip8845_65.12-7-1-0001-393
88xx sip88xx.12-7-1-0001-393
After the phones download the latest enterprise firmware, repeat the process
above to convert the phones to cloud registered phones using the appropriate
.TLexE2M-11-2-3C-10 interim build for each phone model transitioned.
Transition
vi. Update dial plan to complete migration.
Finally, to make sure that calls get routed from Unified CM to Webex, the
existing devices and directory numbers need to be deleted from Unified CM.
To delete the phones from Unified CM follow the steps described in the
Phones Deletions section of the Bulk Administration Guide for Cisco Unified
Communications Manager available at
https://www.cisco.com/c/en/us/support/unified-communications/unified-
communications-manager-callmanager/products-maintenance-guides-
list.html.
If devices provisioned in Unified CM use a site-specific device pool using the

“Device Pool” search allows to easily identify all devices provisioned in one
site. If all devices are not migrated at the same time, the “Delete Phones Using
Custom File” procedure can be used to delete phones based on device
names, MAC addresses or directory numbers. A list of directory numbers
should be readily available as the same directory numbers have been used
above when provisioning the users for Webex Calling.
After deleting the devices from Unified CM, the now unassigned directory
numbers need to be deleted using the “Delete Unassigned Directory
Numbers” procedure in the Phones Deletions section of the Bulk
Administration Guide for Cisco Unified Communications Manager referenced
previously.
Routing from Unified CM to Webex Calling only becomes active after the
directory numbers have been deleted because the directory numbers always
are a better match than the wildcarded route patterns in the “WebexCalling”
partition.
9. Enable emergency calling
Foundational to Webex is the ability to call emergency support numbers. Each

country supported by Webex Calling defines the emergency numbers to enable
basic emergency calling (for example, 911, 112, 999, and so on). The physical
location of an emergency call is presented to the PSAP (Public Safety Access
Point) as defined by the PSTN link carrier. It is a requirement of the PSTN carrier to
correctly define and deliver the physical address to the PSAP for emergency calls.
Transition
For US and Canada based telephony deployments that must provide enhanced
emergency calling solutions, Webex Calling may be augmented with Horizon
Mobility from RedSky (https://www.redskye911.com/horizon-mobility-for-webex-
calling). The Horizon Mobility solution meets all the regulatory requirements under
the recently enacted Kari’s Law and Ray Baum’s Act legislation (compliance
requirement anticipated in February 2021). The RedSky Horizon Mobility solution is
a subscription model and aligns with the subscription levels of Webex Calling end
users. RedSky’s Horizon Mobility is a cloud-based solution and has no reliance on
an on-premises application server managed by the customer (like Cisco
Emergency Responder).
Horizon Mobility service relies on Webex Calling devices to provide network

connection information to the cloud at boot time so the device can be associated
to a physical location within the customer’s deployment. Webex Calling MPP
devices will send switch/switchport and/or the wireless access point BSSID along
with IP address to the Horizon Mobility service via an “over the top” HTTPS service
called HTTP-Enabled Location Delivery (HELD). As shown in Figure 21, step 1,
after registering with Webex Calling, the endpoint will receive a URL to access the
RedSky Horizon Mobility service as a configuration parameter. The endpoint will
send a location update directly to the Horizon Mobility service with the
infrastructure information noted above. The endpoint will establish a persistent
connection to Webex Calling service through the Access SBC, while the
connection Horizon Mobility service will only occur when the endpoint is restarted,
moved, or the location information has timed out (every 24 hours).
Transition
Figure 21. Cloud: Webex Calling Enhanced Emergency Calling with Horizon Mobility
The physical locations within the customers network are configured and managed
by the customer / partner in the Horizon Mobility portal. Any time a device sends a
location update via the HTTPS service, the device’s physical location will be
updated to be associated with the new upstream switch, switch port, wireless
access point, or IP Subnet.
When a user places an emergency call to 911 from a Webex Calling device (Figure
21, step 2), the call will be sent through a Webex Calling managed link to the
RedSky Horizon Mobility service (step 3). Redsky Horizon Mobility service will then
identify the location of the calling device and deliver the call to the appropriate
PSAP (step4). The PSAP that receives the call will also get the current physical
address of the calling device (step 5).
During the transition to Webex Calling the following is required to enable E911 with
RedSky Horizon Mobility:
 Configure each physical dispatchable location in the Horizon Mobility Portal.
 Assign each network element (switch, switchport, wireless access point, and
IP subnet or endpoint) to the physical dispatchable location.
 Reboot all phones at the physical location to trigger the location registration
with Horizon Mobility using HELD.
 Test emergency calling using the 933-test dial string to confirm that the
proper physical location of the calling device is processed.
Transition
10. Implement call recording
Call recording solutions provide a way to record audio and video calls that traverse
various components in a unified communications and collaboration solution. These
recordings can then be used by call centers and other enterprise operations for
various purposes such as compliance, transcription and speech analysis, or for
podcasting and blogging. Existing media forking call recording solutions for an on-
premises deployment, for example, CUBE controlled recording, Unified CM
network-based recording, and SPAN-based recording solutions are not supported
with Webex Calling.
The call recording solution for Webex Calling is provided by the partner Dubber
(https:///www.dubber.net). The Dubber solution enables recording of all calls
(Internal and PSTN) placed/received on the Webex Calling platform for replay and
management. Dubber integrates with the Webex calling platform in the cloud. Prior
to transitioning to Webex Calling, ensure your call recording compliance and
regulation is met by this architecture. For example, in certain countries, regulation
requires the recorded media to stay within the geographic boundary of that country
and that requirement may not be satisfied as Webex Calling platform and the
Dubber data center integration only exists in certain countries.
The following steps are required to deploy call recording in Webex Calling, which
should take place once the end users and devices have been migrated to the
cloud:
i. Partner must first establish an agreement and partner account with Dubber.
ii. Partner then sells the service to the Webex Calling customer.
iii. Partner enables call recording for the Webex Calling customer in Webex
Control Hub.
iv. The call recording license is assigned to an end user either by partner or
customer administrator.
v. The call recording feature for an end user is enabled within the Webex Calling
platform.
vi. Lastly, the partner creates the customer administrator and user in Dubber
portal using data from the Webex Control Hub.
Dubber call recording feature options for Webex Calling are configurable on a per
user basis by the customer administrator or partner and include the following:
 Call recording designation.
Transition
o Never: Do not record any calls.

o Always: Record all calls.
o Always with Pause/Resume: All calls are recorded, but the end user has
the option to pause recording to protect personally identifiable
information (band account numbers, credit cards, PIN, social security
number, and so on).
 Call recording announcement.
Play recording start/stop announcement: If selected, a system message is
played to both parties in the language of the customer site.
o When both parties are connected, the played message is "This call is
being recorded."
o If recording is paused, upon resumption the played message is "Your call
recording service has been activated successfully. Thank you."
 Recording Reminder Tone: Option to play message during pause and resume.
 Repeat Tone Every: Option to play a tone periodically (with configurable
between tones increments from 10 to 90 seconds).
Post-Transition Steps and Considerations

Once the transition from Unified CM on-premises calling to Webex Calling is
complete, there are a few additional steps that should be considered:
1. Transition to Cloud Connected PSTN
Once all endpoints and users are migrated to cloud calling the single purpose of
Unified CM is to act as transit between the PSTN gateways and Webex Calling via
Local Gateway. Removing PSTN gateways, Unified CM, and Local Gateway from
the picture by using Cloud Connected PSTN as PSTN access for all Webex Calling
users has several benefits including cost reduction and improved reliability. To
transition from Local Gateway based PSTN access to Cloud Connected PSTN
follow these steps:
i. Cloud Connected PSTN provider selection.
Refer to the list of Cloud Connect PSTN providers and select from the available
provider(s) available for your organization’s location.
ii. Cloud Connected PSTN validation.
Transition
Before switching PSTN access for Webex Calling locations to Cloud Connected
PSTN, connectivity to PSTN via the selected Cloud Connected PSTN provider
should be verified and validated. For this purpose, a test location needs to be
provisioned in Webex Calling with some test users provisioned in that test
location. PSTN access for this test location is then set to the Cloud Connected
PSTN provider before validating PSTN connectivity using the test phones. Upon
successful validation the test location can be deprovisioned.
iii. Number porting.
To prepare for the cut-over to Cloud Connected PSTN a port order for all
numbers currently assigned to the PSTN trunk terminating on Unified CM needs
to be placed. All numbers need to be ported to the Cloud Connected PSTN
provider. To maintain inter-location reachability all numbers of all locations need
to be ported at the same time.
iv. Switch to Cloud Connected PSTN.
At date of the cut over PSTN access for all locations in Webex Calling needs to
be set to the Cloud Connected PSTN provider and inbound and outbound
connectivity should be verified.
2. Update on-premises infrastructure
Once all users have been transitioned to Webex Calling and all endpoints have
been transitioned to cloud registration (or have been decommissioned), update
appropriate on-premises infrastructure now that cloud calling is in use. Updates to
the infrastructure include:
 Remove on-premises call control and messaging DNS SRV records from the
on-premises DNS server(s) including cisco_uds._tcp.<domain>,
cup_login._tcp.<domain>. These SRV records are no longer required for client
service discovery.
 Remove edge-related DNS SRV records from the public DNS system including
collab_edge._tls.<domain>. These SRV records are no longer required for
client service discovery of collaboration edge services.
Transition
 Update all relevant DHCP scopes to remove option 66 and option 150
TFTP/boot server addresses. These scopes are no longer required for
endpoint call control configuration discovery and download.
 Update/remove appropriate dial-peers in Local Gateway/CUBE that route calls
to and from Unified CM. These dial-peers are no longer required for on-
premises call routing.
 Delete or remove all Unified CM and Expressway cluster node virtual machines
and/or servers. Repurpose compute resources and hardware as needed.
These resources are no longer needed for call control and edge services.
 Delete or remove all Unity Connection cluster node virtual machines and/or
servers. Repurpose compute resources and hardware as needed. These
resources are no longer needed for voicemail and unified messaging services.
 Clean-up: After migrating PSTN access to Cloud Connected PSTN Unified
CM, PSTN trunks, PSTN gateways, and Local Gateway can be
decommissioned.
 For any existing on-premises e911 solution, delete any locations or numbers
that have migrated to Webex Calling and once full transition is complete,
remove application virtual machines or servers. Repurpose compute resources
and hardware as needed. These resources are no longer needed for
emergency calling and location services.
 Update the physical dispatchable location and network element in Horizon
Mobility whenever changes occur. Common activities that require updates are:
o Network switch replacement.
o Wireless access point replacement.
o DHCP scope changes.
o Physical changes inside the building (if resolving to cubical/office).
o Physical office space expansion or contraction inside a building.
3. Leverage Webex Calling troubleshooting tools
Admin and users can always follow the Webex calling service’s status on
https://status.broadsoft.com/.
During transition, admin can utilize existing tools to diagnose and resolve issues.
These include:
 Unified CM traces.
Transition
 IOS-XE debugs.
 Sniffer captures of network traffic.
 Syslog.
Administrators can also open a service request with Cisco Technical Assistance
Center (TAC).
4. Utilize Webex Calling analytics
Webex Calling Analytics in Control Hub brings a new level of insight into your
Webex Calling deployments. With the enablement of this feature, historical data of
call usage and engagement is available in Control Hub, including media quality
records. The Webex Calling analytics are presented in Control Hub under
Analytics > Calling.
Engagement Analytics
Under Analytics > Calling > Engagement are historical engagement analytics for
your Webex Calling service (see Figure 22).
Figure 22. Webex Calling Engagement Analytics
Transition
As shown in Figure 23, the Calls and Call Minutes graphs contain details of all the
point-to-point calls made in the organization. The graphs are split into the following
categories, depending on the client used for the call:
 Desktop –Webex App for Windows and Mac.
 Browser –Webex App for Web.
 Mobile –Webex App for iPhone, iPad and Android.
 Device –Webex Room Device or Webex Board.
 WXC Desktop –Webex Calling App for Windows and Mac.
 WXC Mobile –Webex Calling App for iPhone, iPad and Android.
 MPP –Webex Calling Multiple Platform Phone.
The Call Details table contains one entry for each call containing the following
information:
 Name – Username.
 Email – User email.
 Start Date – When the call was made in GMT.
 Duration – Duration of the call-in seconds.
 Endpoint – Type of device or client used. WXC means Webex Calling app, and
MPP means Webex Calling Multiple Platform Phone.
 Uaversion – User agent version if reported by the endpoint.
 Call ID – A unique identifier for the call.
 User ID – A unique identifier for the user.
As an example, if Alice calls Bob and both devices are within the same
organization, two records will be shown in this view, one for Alice and one for Bob.
Quality Analytics
The Quality Analytics tab allows you to view records for each call and use sliders to
filter calls based on quality statistics (see Figure 23).
Transition
Figure 23. Webex Calling Quality Analytics
The analytic headings available for quality are:

 Name – Username.
 Email – User email.
 Start Date – When the call was made in GMT.
 Duration – Duration of the call-in seconds.
 Endpoint – Type of device or client used. WXC means Webex Calling app, and
MPP means Webex Calling Multiple Platform Phone.
 Audio Packet Loss (%) – Packet Loss in percent as reported by the
endpoint/soft client.
 Audio Latency (ms) – Audio latency reported by the endpoint.
 Audio Jitter (ms) – Audio jitter reported by the endpoint.
 Video Packet Loss (%) – If applicable, video packet loss reported by the
endpoint.
 Uaversion – User agent version if reported by the endpoint.
 Call ID – A unique identifier for the call.
Transition
 User ID – A unique identifier for the user on the call.
All statistics are collected from the devices/endpoints directly, and so the statistics
(packet loss, jitter, latency) reflect the experience of the call from the perspective
of the user’s endpoint.
References
References
Licensing
 Cisco Collaboration Flex Plan
https://www.cisco.com/c/en/us/products/unified-
communications/collaboration-flex-plan/index.html
Network Requirements
 Prepare Your Environment for Webex Calling
https://help.webex.com/en-us/n4cprps/Prepare-Your-Environment-for-
Webex-Calling
 Port Reference Information for Webex Calling

https://help.webex.com/en-us/b2exve/Port-Reference-Information-for-
Cisco-Webex-Calling
Phones
 Supported Devices for Webex Calling
https://help.webex.com/en-us/qkwt4j/Supported-Devices-for-Webex-Calling
 Configure & Manager Webex Calling Devices

https://help.webex.com/en-us/n9r1aac/Configure-and-Manage-Webex-
Calling-Devices
 Convert between Enterprise Firmware and Multiplatform Firmware for Cisco IP

Phone 7800 and 8800 Series Guide
https://www.cisco.com/c/en/us/products/collateral/collaboration-
endpoints/unified-ip-phone-7800-series/guide-c07-742786.html
 Enterprise to Webex Calling /MPP Firmware Migration

https://upgrade.cisco.com/e2m_converter
 Configure and Manage Webex Calling Devices, Add and Assign Devices in Bulk
https://help.webex.com/en-us/n9r1aac/Configure-and-Manage-Webex-
Calling-Devices#id_118912
References
 Bulk Administration Guide for Cisco Unified Communications Manager, Release

12.5(1), Chapter: Phone Deletions
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/bat/12_5_1/c
ucm_b_bulk-administration-guide-1251/cucm_b_bulk-administration-guide-
1251_chapter_01000.html
Users
 Getting Started with Cisco Webex Control Hub
https://help.webex.com/en-us/nkhozs6/Get-Started-with-Cisco-Webex-
Control-Hub
 Configure & Manage Webex Calling Users

https://help.webex.com/en-us/nz0krq9/Configure-and-Manage-Your-
Webex-Calling-Users
Calling Configuration
 Configure Webex Calling for Your Organization
https://help.webex.com/en-us/njvdjf2/Configure-Cisco-Webex-Calling-for-
Your-Organization
 Configure Webex Calling Features

https://help.webex.com/en-us/0r7a2z/Set-Up-Your-Webex-Calling-Features
 Configure Unified CM for Webex Calling

https://help.webex.com/en-us/nqqzbk7/Configure-Unified-CM-for-Webex-
Calling
Local Gateway
 Configure Local Gateway (IOS-XE) for Webex Calling
https://help.webex.com/en-us/b2exve/Port-Reference-Information-for-
Cisco-Webex-Calling
References
Design Overview
 Cisco Preferred Architecture for Cisco Webex Calling
https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hy
brid/AltDesigns/PA-WbxCall.pdf
dCloud Lab
 Transitioning from Unified CM to Webex Calling Lab
https://dcloud-cms.cisco.com/demo_news/transitioning-from-unified-cm-to-
webex-calling-lab
Collaboration Transitions
 Collaboration Transitions Program Page
https://www.cisco.com/go/ct
 Transition Map for Transitioning from Unified CM to Webex Calling

https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/TDM_CALLIN
G_Unified_CM_to_Webex_Calling.pdf
Glossary
Glossary
The following tables provide a glossary of Unified CM concepts and constructs along
with a definition and information on potential alignment with Webex Calling.
The glossary is divided into the following sections:

 Locations and Grouping
 Users
 Phones
 Features / Functionality
 Operations
Glossary
Locations and Grouping
Unified CM Concept Comment
Regions are used to control bandwidth

consumption for audio and video calls within a
region and between regions. Regions are
assigned to devices at the device pool level.
Region
In Webex Calling devices are grouped by location
and the same codec selection policy is used for
calls within a location and between locations.
Call Manager Groups are used to control device

registration and balance the load over all call
processing subscriber nodes of a Unified CM
cluster.
Call Manager Group
With a cloud-based call control there is no need
for the administrator to define registration policies
to manage load and performance.
Device pools allow to group devices of similar
characteristics and to apply common
configurations like region, location, calling party
transformations to devices at the device pool
Device Pool level.
In Webex Calling there is no concept of device

grouping for administration purposes. All settings
need to be applied to the devices individually.
Glossary
Using Common Device Configurations in Unified

CM allows to create sets of device settings which
can then be applied to individual devices together.
Settings include softkey template, music on hold,
locale, and others. Common Device
Common Device Configuration Configurations get applies to devices at the
device level (not at the device pool level).
There is no equivalence in Webex Calling. In

Webex Calling all device configuration is applied
at the device level.
Locations are used in Unified CM to group

together devices residing in the same network
location. The location concept in Unified CM is
purely used for Call Admission Control (CAC).
Devices are assigned to locations by selecting a
location at the device pool level.
While Webex Calling does not have any CAC

Locations
capabilities Webex Calling locations group
together devices sharing the same geographical
location (address), PSTN access, main number,
site code, PSTN steering digit etc. Unified CM
location assignment among other aspects can be
used during a Unified CM to Webex Calling
transition to identify devices in the same Webex
Calling location.
Multiple attributes can be used to group devices

in Unified CM including: Device Pool, Device
Mobility, Locations, DN ranges, Physical Location,
Directory Information, Region, Geolocation, SRST
Device Grouping reference, Logical Partitioning, MRGL, and others.
Webex Calling has no concept of grouping

devices other than associating devices with a
Webex Calling location.
Glossary
Directory numbers represent dialable patterns

assigned to endpoints in Unified CM.
Directory Number
In Webex Calling endpoints inherit extension and
number from the user the device is configured for.
Dialable patterns are grouped in partitions to form

equivalence classes of dialable patterns to be
used in calling search spaces to define classes of
service and dialing habits in Unified CM.
There is no equivalent concept in Webex Calling.

Instead in Webex Calling DIDs, extensions, PSTN
Partition
steering digit, inter-site dialing steering digit, and
outbound dial plans are used as parameters to
configure dialing habits. From a migration
standpoint, partitions, calling search spaces, and
patterns can be analyzed to derive this
information from an existing Unified CM
configuration.
Unified CM and Webex Calling use fundamentally

different concepts for Class of Service. While CoS
in Unified CM is built based on calling search
spaces, partitions, and dialable patterns, Webex
Class of Service (CoS)
Calling offers a fixed set of classes of service.
Especially there is no (easy) way to build
differentiated CoS based on dialed on-net
destination.
Calling search spaces are ordered list of partitions

containing dialable patterns. A destination is
reachable by a calling device if the dialed
Calling Search Space (CSS)
destination matches a pattern in any partition
contained in the effective calling search of the
calling device.
Glossary
Local route groups in Unified CM are used to

define site and call type specific egress gateway
or trunk selection policy.
Local Route Group In Webex Calling a single egress connection can

be configured per location. This connection can
either be a Cloud Connected PSTN (CCP) trunk or
a trunk via a Cisco Unified Border Element (CUBE)
acting as Local Gateway (LGW).
Route Groups are used in Unified CM to group

trunks and gateways into equivalence groups
which are used to configure prioritizes egress
gateway or trunk selection.
Route Group
In Webex Calling a single egress connection can
Route Lists in Unified CM are ordered lists of

route groups. They are used to define egress
gateway or trunk selection policies.
Route List In Webex Calling a single egress connection can

Route filters are used in combination with national

numbering plans to define class of service based
on number types defined by national numbering
Route Filter plans.
In Webex Calling the class of service concept is

different and there is no equivalent to route filters.
Glossary
A route pattern comprises a string of digits (an

address) and a set of associated digit
manipulations that can be assigned to a route list
or a gateway. Route patterns provide flexibility in
network design. They work in conjunction with
route filters and route lists to direct calls to
Route Pattern
specific devices and to include, exclude, or
modify specific digit patterns.
In Webex Calling with a Local Gateway configured

as trunk all unknown destinations are sent to the
Local Gateway.
Calling and called party transformations can be

applied at various points in Unified CM including
implicitly as part of call routing on route and
translation patterns, and explicitly using calling
and called party transformation patterns in
Calling/Called Party
partitions addressed by calling and called party
Transformations
transformation calling search spaces.
In Webex Calling called party transformations are

limited to normalization of dial strings in line with
the respective national numbering plan.
Glossary
National Numbering Plans in Unified CM define

the characteristics of country specific numbering
plans including number types, digit discard
instructions, and number formats. When defining
the call routing in Unified CM the national
numbering plan can be referenced which can
simplify the configuration of the enterprise dial
plan.
National Numbering Plan In Webex Calling all country specific numbering

plans of all supported countries are pre-
provisioned and selected based on the county
selection of the location of a calling device. There
is no need to install country specific numbering
plans in Webex Calling.
Webex Calling allows to set the caller ID for each
user to the direct line, the main number of the
user’s location, or to a different number from the
caller’s location.
Glossary
Users
User profiles use settings from the following phone

and phone line templates to build a profile for the
end user:
 Universal Line Template—a collection of
common phone line settings that are typically
assigned to a directory number. Universal line
templates allow to quickly configure phone
lines for new directory numbers that get
assigned to an end user.
 Universal Device Template—a collection of
common device settings that are typically
assigned to a phone or other device.
Universal device templates allow to quickly
Universal Line Template, configure new phones that get assigned to an
Universal Device Template, end user.
User Profile
User profiles together with Universal Line and
Device templates ease administrative tasks that
relate to setting up users and devices and keep a
range of device settings on one central,
customizable interface. They are also used to
determine the settings for users enabled for self-
provisioning and are the basis for auto-
provisioning of devices for users created via LDAP
directory synchronization.
Webex Calling does not offer mechanisms to

group devices or to prepare templates to be used
during user and device provisioning. Each user and
device are provisioned individually.
Glossary
These templates are used to define settings to use

when using the quick User/phone add functionality
of Unified CM. Furthermore, a feature group
template is also used to determine the settings for
users and phones added through LDAP
Feature Group Template
synchronization.
Webex Calling does not to offer any functionality to

pre-define user or device settings. Instead, users
and devices are configured individually.
Unified CM can be configured to automatically

synchronize user data from an LDAPv3 directory to
the Unified CM end user database. Also,
password-based authentication can be delegated
to LDAP based authentication. Feature Group
Templates can be linked to LDAP synchronization
agreements to define settings for users and
phones automatically created through LDAP
synchronization.
LDAP (System, Filter, Directory Connector can be used to link account

Directory, Authentication) creation in Webex Common Identity to Microsoft
Active Directory. In addition, account creation can
be linked to Okta or Azure AD; this does not
require any on-premises infrastructure.
Authentication can be delegated to enterprise
identity management systems using SAML 2.0
compliant Single Sign On (SSO). Webex calling
has no option to automatically configure calling
related settings like extension, phone number,
location, or calling entitlement for users synced
from Microsoft Active Directory, Okta, or Azure AD.
Glossary
Unified CM supports two ways of self-provisioning:

 Users dialing into an IVR from an auto-
registered phone and then attributes of the
phone are set based on user and device
profiles.
Self-Provisioning  Activation code-based onboarding.

The latter option of activation code device
provisioning also exists in Webex Calling. The main
difference is that in Webex Calling the device type
is fixed and by entering an activation code a
specific device is associated with the actual
device.
Phones
Webex Calling currently does not have any ability

to use templates when provisioning phones. All
Phone Button Templates
configuration must be applied to each phone
individually.
In Webex Calling devices get associated to users

during the provisioning process and the phone
inherits the extension/DID from the user while in
Unified CM the configuration is DN centric, DNs
User/Device/Association get associated to phones via line appearances,
and then finally phones are owned by users. A
user in Unified CM does not really have a routable
number. The information in the user record is
mainly used for directory lookups.
Glossary
Features / Functionality
Unified CM offers the option to implement topology

aware call admission control based on locations, links
interconnecting locations, and available audio and
video bandwidth on these links. Calls get rejected if
the bandwidth manager identifies lack of available
bandwidth on any of the links based on location of
Call Admission Control
calling and called device.
(CAC)
Webex Calling is not aware of the network topology
the solution is deployed on and thus is not able to
offer call admission control. Instead, customers are
encouraged to overprovision links and continuously
monitor bandwidth utilization.
Automated Alternate Routing allows to reroute calls

to the PSTN or a different network when the call is
blocked by Unified CM due to lack of bandwidth as
Automated Alternate Routing determined by call admission control.
(AAR)
The concept of AAR does not apply to Webex Calling
because Webex Calling does not offer any bandwidth
utilization controls.
Cisco Unified Mobility allows users to manage

business calls using a single phone number and pick
up in-progress calls on the desktop phone and
cellular phone. Access lists determine the phone
numbers that are explicitly allowed or blocked for in-
Access List progress call transfers. These access lists are used in
the remote destination configuration.
With Webex Calling Call Forwarding Selective Users

can forward calls at specific times from specific
callers.
Glossary
In Unified CM a time schedule can be assigned to a

partition which contains dialable patterns. Outside of
the schedule, the associated partitions are not
considered for call routing. This enables time
dependent classes of service.
Time of day routing
In Webex Calling time schedules can be used in
combination with Auto Attendant, call queues,
Executive and Executive Assistant, selective call
acceptance, and selective call rejection
Unified CM supports the following types of dial rules:

 Application Dial Rules: The administrator uses
application dial rules to add and sort the priority
of dialing rules for applications such as Cisco
web dialer and Cisco Unified Communications
Manager Assistant.
 Directory Lookup Dial Rules: The administrator
uses directory lookup dial rules to transform
caller identification numbers and perform a
directory search from the assistant console in
application such as Cisco Unified
Communications Manager Assistant.
Dial Rules
 SIP Dial Rules: The administrator uses SIP dial
rules to perform system digit analysis and
routing. The administrator configures SIP dial
rules and adds the SIP dial rule to the Cisco
Unified IP Phone before the call processing
takes place.
Webex Calling does not have an equivalent to this.
Phones registering to Webex Calling download a
core, simple dial map based on the national
numbering plan. During digit collection on the phone
guard timers are used to terminate digit collection in
case of numeric overlaps.
Glossary
In Unified CM each directory number can have

multiple associated alphanumeric URIs and both, the
alphanumeric URIs and the directory number are
dialable destinations. The primary URI also serves as
caller ID in conjunction with a numeric identity
URI Dialing derived from the directory number value.
Webex Calling is a numeric only call control and

cannot handle URIs as addresses for users. The only
way to dial a URI from a phone is to assign a URI to a
speed dial and then dial the URI via a speed dial.
In multi-cluster Unified CM deployments Global Dial

Plan Replication (GDPR) allows to replicate dial plan
information between clusters. This simplifies the call
routing configuration for complex call routing
Global Dial Plan Replication topologies covering large deployments both in terms
(GDPR) of number of users and geographic footprint.
Webex Calling is a scalable solution with global

footprint capable of supporting users at scale in
various geographies.
Intercom is a type of phone line that combines the

functionality of a traditional line and a speed dial.
With an intercom line, a user can call the intercom
line of another user, which answers automatically to
one-way audio whisper. The recipient can then
acknowledge the whispered call and initiate a two-
Intercom way intercom call.
In Webex Calling the push-to-talk feature allows

users to treat their desktop phones as either a one-
way or two-way intercom. When enabled, the
administrator can create an allowed or blocked user
list.
Glossary
In Unified CM with client matter codes (CMCs) and

forced authorization codes (FACs), you can
effectively manage call access and accounting.
CMCs assist with call accounting and billing for
clients, and FACs regulate the types of calls that
certain users can place. CMCs force the user to
enter a code; this action specifies that the call relates
to a specific client matter. You can assign client
matter codes to customers, students, or other
Client Matter Codes,
populations for call accounting and billing purposes.
Forced Authorization Codes
FACs force the user to enter a valid authorization
code that is assigned at a certain access level before
the call is completed.
Webex Calling has no replacement for CMCs. FAC

means Feature Access Code in Webex Calling that is
different from Forced Authorization Code in CUCM.
Webex Calling supports Authorization Codes to
bypass Calling Restrictions.
In Unified CM the SUBSCRIBE Calling Search Space

determines how Cisco Unified CM routes BLF
presence requests that come from the trunk or the
phone. The SUBSCRIBE calling search space, which
is associated with a watcher, specifies the list of
partitions to search for routing information to a
Presence Subscription
presence entity for BLF presence requests.
In Webex Calling to prevent someone from

monitoring a user’s line status selective line status
sharing can be configured in the user’s advanced
calling settings.
Glossary

A Media Resource Group List (MRGL) provides a
prioritized grouping of Media Resource Groups
(MRG). Media resource, such as an MOH server,
conference bridges and transcoders, from among the
available media resources based on the priority order
Media Resource Group,
defined in an MRGL.
Media Resource Group List
In Webex Calling management of media resources is
part of the service provided in the cloud. There is no
need for the administrator to configure any selection
order
The Busy Lamp Field (BLF) presence feature allows a
user who is a watcher to monitor the real-time status
of another user from the device of the watcher.
A watcher can monitor the status of the user or BLF
presence entity (also called presentity) by using the
following options:
 BLF and Speed Dial buttons.
 Missed call, placed call, or received call lists in
the directories window.
 Shared directories, such as the corporate
directory.
Busy Lamp Field (BLF),
BLF presence group BLF presence group authorization ensures that only
authorized watchers can access the BLF presence
status for a destination. Because the administrator
ensures that the watcher is authorized to monitor the
destination when a BLF or Speed Dial is configured,
BLF presence group authorization does not apply to
BLF or Speed Dials.
In Webex Calling BLF speed dials can be configured

in the monitoring section of the Advanced Call
Settings in Control Hub. Directories are not presence
enabled so that the concept of BLF presence groups
is not needed in Webex Calling.
Glossary
Cisco Extension Mobility allows users to temporarily

access their phone settings, such as line
appearances, services, and speed dials, from other
phones within your system.
Extension Mobility
In Webex Calling Hoteling enables a user’s phone
profile of phone number, features, and calling plan to
be temporarily loaded onto a shared (host) phone.
Hoteling can be enabled for users by the
administrator in Control hub.
Expressway Mobile and Remote Access is a core

part of the Cisco Collaboration Edge Architecture. It
allows endpoints such as Cisco Jabber to have their
registration, call control, provisioning, messaging,
and presence services that are provided by Unified
CM when the endpoint is not within the enterprise
Mobile Remote Access
network.
This concept is not applicable to Webex Calling

because all endpoints connect to the Webex Calling
cloud service over the top whether they are within or
outside of the enterprise network.
Cisco Unified Mobility gives users the ability to

redirect incoming IP calls from Unified CM to different
designated phones, such as cellular phones. Users
can also transition active calls between their Cisco
desktop and mobile phone without interruption. Cisco
Unified Mobility offers the following mobility-related
Cisco Unified Mobility
features: Single Number Reach, Move to Mobile,
Mobile Voice Access, Enterprise Feature Access,
Intelligent Session Control.
In Webex Calling similar functionality can be achieved

using Remote Office, Office Anywhere, or Mobility.
Glossary
Extend and Connect enables users to use basic

third-party call control operations from Jabber such
as Make Call, Answer, and Disconnect with endpoints
not registered with Unified CM.
Extend and Connect
Webex Calling does not have a directly equivalent
feature but features such as Remote Office and
Office Anywhere address a similar use case.
While Webex Calling also offers Hunt Groups the

functionality in Webex Calling is not identical to the
Hunt Groups functionality offered by Unified CM. For example,
currently Webex Calling does not offer a hunt groups
login/logout option for users.
In Unified CM the Call Pickup feature allows users to

answer calls that come in on a directory number
other than their own. There are four flavors of Call
Pickup:
 Group Call Pickup.
 Other Group Pickup.
 Directed Call Pickup.
Call Pickup  BLF Call Pickup.
In Webex Calling the call pickup service enables a

user to answer any ringing line within their pickup
group. A pickup group is a group administrator-
defined set of users within a location, to which the
call pickup feature applies. The call pickup feature
requires call pickup groups to be added as well as
assigning specific users to that pickup group. Call
pickup only works within the pickup group
Glossary

Call Park feature on Unified CM allows to place a call
on hold so that it can be retrieved from another
phone in Unified CM. Directed Call Park allows a user
to transfer a call to an available user-selected
directed call park number. Directed call park Busy
Lamp Field (BLF) on a phone can be used to monitor
the busy or idle status of specific directed call park
numbers. Users can also use the BLF to speed dial a
Call Park,
directed call park number. Call Park monitoring (call
Directed Call Park
reversion) can be configured for directory numbers
and hunt pilots.
In Webex Calling calls can be parked against

members of a call park group and can be retrieved
later by dialing the respective call park member. Call
Park monitoring (call reversion) can be configured on
the location and call park group level.
Webex Calling supports 3-way and N-way-
Ad Hoc Conferencing
conferencing (up to 6 participants).
There is no equivalent feature in Webex Calling.

Meet-Me Conferencing
Webex Meetings can be used as an alternative.
There is no equivalent feature in Webex Calling.

Conference Now
Webex Meetings can be used as an alternative.
No equivalent in Webex Calling: all media resources

Music on Hold (MoH) are cloud based; no need for location specific MRG
selection.
Voicemail Basic VM available in Webex Calling.
Webex Calling supports Analog Telephony Adapters

(ATA), Cisco Unified Border Elements as Local
Gateways, Trunks Gateway (Local Gateway), and Cloud Connected
PSTN. Local Gateways can be used to interwork with
virtually any technology.
Glossary
Operations
Credential policies control the authentication

process for resources in Unified CM. A credential
policy defines password requirements and account
lockout details such as failed login attempts,
expiration periods and lockout durations for end
Credential Policy user passwords, end user PINs, and application
user passwords.
In Webex Calling the password policy is

determined by the organization level setting in
Control Hub.
An access control group is a list of users and the
roles that are assigned to those users. When you
assign an end user, application user, or
administrator user to an access control group, the
user gains the access permissions of the roles that
are associated to the group.
With Webex Calling users within the organization

can be assigned specific administrative roles to
Access Control Group, Roles, determine what they can see and have access to
User Rank in Control Hub:
 Full Administrator
 Read-Only Administrator
 Support Administrator
 User and Device Administrator
 Device Administrator
 Compliance Office
Glossary
Unified CM offers various bulk administration

options including but not limited to:
 Add, update, delete, export phones.
 Add, update, delete, export, users.
Bulk Administration Tool Web Bulk Administration Tools are also available in
Webex Calling with some limitations:
 Bulk User Import.
 Bulk Device Import.
 Bulk Device-User Assignment.
Headset management is a Webex Calling roadmap

Headset management
item.
Unified CM has APIs for provisioning (AXL),

external call routing (CURRI), Serviceability
(SXML), Device Monitoring and Call Control
(JTAPI, TAPI, Web Dialer).
The Webex Calling administration API is limited to

basic provisioning tasks:
 Retrieve a Webex Calling license.
 Retrieve Locations .
 Create a Webex Calling user & assign phone
APIs number, extension, location.
 Delete a Webex Calling user.
 Assign Webex Calling license to existing
Webex user & specify phone number,
extension, location.
 Update phone number, extension for existing
Webex Calling user.
 Retrieve Webex Calling user with phone
number, extension, location.
 Query Webex Calling users by Location.
Glossary
The Webex Calling call control API allows tasks:

 Place a call (dial).
 Answer a call (answer).
 Reject an incoming call (reject).
 Hang up a call (hang-up).
 Divert an incoming call (divert).
 Hold a call (hold).
 Resume a held call (resume).
APIs (cont.)
 Transfer an active call (transfer).
 Park an active call (park).
 Retrieve a parked call (retrieve).
 List active calls.
 Get the details for a specific active call.
 Get the Call History.
There are no APIs for device monitoring,

serviceability, or external call routing.

Cisco Cucm To Webex Calling

Uploaded by

Copyright:

Available Formats

Cisco Cucm To Webex Calling

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco Cucm To Webex Calling

Uploaded by

Copyright:

Available Formats

CALLING

Transitioning from Unified CM to

September 22, 2021

© 2021 Cisco – CTG TME

WHAT’S NEW IN THIS GUIDE .................................................................................................. 4

TARGET AUDIENCE ...................................................................................................................... 6

CORE COMPONENTS ............................................................................................................ 10

ROLES OF THE COMPONENTS INVOLVED ....................................................................................... 10

PRE-TRANSITIONS STEPS AND CONSIDERATIONS .......................................................................... 13

4. UTILIZE WEBEX CALLING ANALYTICS ........................................................................................60

LOCATIONS AND GROUPING ..........................................................................................................68

What’s New in This Guide

Date Updated or New Topics Update Details and Location

Clarifications related to emergency calling

Added “Glossary” with tables of Unified CM

Figure 1. On-Premises Collaboration Architecture: Call Control and Remote Access

Table 2. Before: On-Premises Calling Infrastructure Components

On-premises call control providing device

Edge infrastructure providing Mobile and Remote

Cisco Meeting Server (CMS),

Webex DX, Webex Room /

Figure 2. On-Premises Calling Transition Decision Tree

Figure 3. After: Webex Calling Architecture

Table 3. After: Cloud Calling Infrastructure Components

Cisco IOS-XE Integrated Services Router (ISR 1100

Figure 4. Phased Calling Transition: Hybrid and Cloud

Pre-Transitions Steps and Considerations

1. Perform initial readiness assessment of existing deployment.

Prior to transition, to determine the feasibility and potential modifications required, it

Another important deployment consideration when transitioning to Webex Calling is

Number of expected concurrent calls * Bandwidth per call based on codec =

Table 4. Webex Calling Call Type Bandwidth Calculations

Table 5 shows an example of a complete bandwidth calculation exercise assuming

TOTAL CALLS / BANDWIDTH 100 calls 14,950 kbps / 14.95 mbps

PSTN Connectivity with Local Gateway

2. Perform network readiness assessment

Customers need to conduct a network assessment prior to migrating to Webex

3. Understand Webex Calling region selection

Webex Calling operates five regional platforms as shown in Figure 5: North

Figure 5. Webex Calling Regional Datacenters

Refer to the Cloud Connected PSTN providers list available at

4. Analyze deployment dial plan

NYC 2XXX 202 8 202 2XXX

SFO 3XXX 203 8 203 3XXX

RTP 2XXX 204 8 204 2XXX

Extensions (Pre- Webex Calling Enterprise

NYC 2XXX 2XXX 202 8 202 2XXX

SFO 8XXX 7XXX 203 8 203 7XXX

RTP 1XX 11XX 204 8 204 11XX

Table 8 shows an example how this renumbering. In this example abbreviated

UCM Webex Calling

NYC 2XXX 22 8 22 2XXX 822 8 822 2XXX

SFO 8XXX 23 8 23 7XXX 823 8 823 7XXX

RTP 1XXX 24 8 24 11XX 824 8 824 11XX

In a scenario with different enterprise number formats on Unified CM and Webex

5. Inventory existing locations/sites

To prepare for the provisioning of locations on Webex Calling the required

Table 9. Information to Capture for Each Location

 Each location in Webex Calling can have