Why This Guide Exists
Webex Calling deployments are one of the few UCaaS stacks where networking, licensing, PSTN design, and user provisioning all collide in the same project. Cisco’s documentation covers each piece in isolation. This guide walks through the full deployment in sequence — the decisions that matter, why they matter, and what breaks when you get them wrong.
This is Part 1. It covers architecture, licensing, Control Hub setup, and user provisioning. Part 2 covers device deployment, dial plan design, auto attendants, E911, survivability, security, and validation.
Is Webex Calling the Right Platform?
This guide assumes you’ve already made the platform decision. If you’re still evaluating Webex Calling against Microsoft Teams Phone or working through a customer-specific licensing scenario, the Webex Calling vs Microsoft Teams Calling article covers that decision in full. Come back here once Webex is the answer.
What Webex Calling Actually Is
Webex Calling is Cisco’s cloud-hosted PBX platform. It replaces on-premises call managers — CUCM, Unified Communications Manager, legacy key systems — with a cloud-native calling stack managed through Cisco’s Control Hub. Users get a full phone system feature set: extensions, voicemail, call queues, auto attendants, hunt groups, and PSTN connectivity, all without running a call server on-site.
The deployment model that makes Webex Calling worth considering over alternatives:
- Cisco-first organizations already running Webex Meetings, Webex Devices, or Cisco IP phones get a tightly integrated stack with a single admin plane
- Multi-site SMB and mid-market deployments benefit from centralized management without the complexity of per-site on-premises infrastructure
- Organizations migrating off legacy Cisco get a supported migration path that preserves device investments and carrier relationships where needed
- Teams that want one platform for calling, meetings, messaging, and devices rather than stitching together separate vendors
Webex Calling is not the right answer when a customer is already deep in Microsoft 365 and Teams licensing covers the phone system at no meaningful additional cost. That’s a platform economics decision, not a features decision.
What You Need Before Deployment
Trying to deploy Webex Calling without getting licensing right first is the fastest way to a failed go-live. More deployments get derailed by licensing confusion than by any technical problem.
Licensing Foundation
Webex Calling licensing lives under A-FLEX-3 in Cisco Commerce Workspace. The full breakdown of agreement types, workspace entitlements, Committed Outbound Users, and the 20% growth allowance is covered in the Webex Calling Licensing Explained article. Read that before you build a quote.
The short version for deployment planning:
- Every knowledge worker who needs a personal extension, voicemail, and softphone gets a Webex Calling Professional license
- Every shared phone — lobby, conference room, common area — gets a Workspace for Common Area license
- Committed Outbound Users must equal your total users plus workspaces combined or outbound calling silently fails on under-licensed devices
- PSTN connectivity requires a separate calling plan on top of the software licenses — Cloud PSTN, Operator Connect, or Local Gateway
Webex Suite Overlap
If the customer is already on a Webex Suite license — Webex Suite, Webex Suite Enterprise, or a bundle that includes meetings and messaging — check whether Calling is already included before adding it as a separate line item. Suite bundles vary and Calling entitlements are not always obvious in the CCW output. Verify with your Cisco rep before finalizing the quote.
Webex Calling Architecture Overview
Before touching Control Hub, understand what you’re actually deploying.
Control Hub is the administrative plane for everything Webex. User management, calling configuration, device management, licensing assignment, analytics, and troubleshooting all live here. It is the single pane of glass for the entire deployment — get comfortable in it early.
Webex Calling Cloud is the hosted PBX engine. It handles call processing, dial plan logic, voicemail, call queues, and auto attendants. There is no on-premises call server in a pure cloud deployment. Cisco runs the infrastructure.
PSTN Connectivity is the bridge between Webex Calling and the public telephone network. Three options exist — covered in detail in the next section. Which one you choose affects cost, complexity, and carrier flexibility for the life of the deployment.
Webex App is the softphone client for desktop and mobile. For most users this is the primary calling interface. It handles voice, video, messaging, and meetings in a single application.
Cisco IP Phones and Webex Devices connect to Webex Calling via the cloud. MPP-firmware phones and Cisco desk phones register directly to the Webex Calling cloud without a local call manager. Zero-touch provisioning handles activation for supported devices.
Local Gateway is optional. It connects an existing SIP carrier or on-premises telephony infrastructure to Webex Calling through a certified Session Border Controller — Cisco’s CUBE or a supported third-party SBC. Required for Local Gateway deployments. Not needed for Cloud PSTN or Operator Connect.
Survivability Gateway is also optional. It provides basic PSTN calling capability during a WAN outage by maintaining a local SIP trunk connection. Covered in Part 2.
PSTN Deployment Models
Licensing gives you the phone system. PSTN connectivity gives you dial tone. There are three paths. The full decision framework — including cost comparison, carrier selection, and when Local Gateway is the right choice — is covered in the PSTN Options in Webex Calling article.
Option 1 — Cisco Calling Plans (Cloud PSTN)
Cisco acts as the carrier. Numbers, calling capacity, and billing all live inside your Webex organization and are managed entirely through Control Hub. No carrier contracts, no SIP trunk configuration, no SBC infrastructure.
This is the fastest path to a working deployment and the right default for straightforward SMB deployments under roughly 500 users. The trade-off is cost at scale — per-user per-month pricing adds up in high-volume environments — and regional availability, which varies by country.
Use Cisco Calling Plans when simplicity and speed matter more than carrier flexibility and you’re not approaching the volume threshold where Operator Connect pricing becomes compelling.
Option 2 — Cloud Connected PSTN (Operator Connect)
Third-party carriers certified by Cisco connect their PSTN infrastructure directly to your Webex organization through an API integration. Carriers in the Cisco Cloud Connected PSTN program include IntelePeer, CallTower, Bandwidth, Tata Communications, and others. You manage numbers and assignments through Control Hub the same way you would with Cisco Calling Plans, but the carrier relationship, pricing, and calling plans are negotiated directly with your chosen provider.
This is the right move for mid-market and enterprise deployments where volume pricing from a carrier beats Cisco’s standard plan rates, or where you need flexibility on international calling, toll-free numbers, or number porting that Cisco Calling Plans can’t accommodate.
The calling experience for end users is identical to Cisco Calling Plans. The difference is entirely on the cost and management side.
Option 3 — Local Gateway (Direct Routing)
Local Gateway connects an existing SIP carrier or on-premises telephony system to Webex Calling through a certified SBC — typically Cisco CUBE or a supported third-party device. This is the right path when a customer has an existing carrier contract they’re not ready to exit, is migrating from a legacy on-premises PBX and needs to maintain PSTN during the transition, or has call routing requirements that managed PSTN services can’t satisfy.
The trade-off is the same as Direct Routing in Teams: full control over carrier selection and routing logic, at the cost of SBC management, SIP trunk configuration, and ongoing infrastructure overhead. Local Gateway is not a cost-saving measure — it is a flexibility trade-off. Run the full numbers including Local Gateway licensing and ongoing management overhead before recommending it over Operator Connect.
Local Gateway deployments can be paired with a Survivability Gateway to maintain basic PSTN calling during WAN outages. Cloud PSTN and Operator Connect deployments have no local survivability path without a Local Gateway in the architecture. Make this decision at the design stage, not after go-live.
Network Requirements
Voice quality problems in Webex Calling are almost always network problems. The cloud PBX is rarely the issue — the WAN circuit, the firewall configuration, or the absence of QoS is where calls fall apart.
The full production network requirements for Webex Calling are covered in Webex Calling Network Requirements — QoS, Firewall Ports, and Split Tunneling. Before you provision a single user, the network needs to meet these thresholds:
- Latency — under 150ms one-way to Cisco’s media nodes
- Jitter — under 30ms
- Packet loss — under 1%
- QoS — DSCP EF (46) marking for voice media, CS3 for signaling, enforced end to end from the endpoint to the WAN handoff
- Firewall — required Cisco domains and UDP/TCP ports open per Cisco’s published requirements. SSL inspection must be bypassed for Webex traffic — it breaks SIP/TLS signaling reliably and is one of the most common causes of call setup failures in new deployments
- Split tunneling — Webex Calling traffic should be excluded from VPN tunnels for remote users. Forcing media through a VPN concentrator adds latency and jitter that degrades call quality regardless of the underlying circuit quality
Run a network readiness assessment before you touch Control Hub. Deploying onto a network that isn’t ready produces a call quality problem that looks like a configuration problem, and the troubleshooting cycle is expensive.
Initial Control Hub Setup
Control Hub is where the deployment actually starts. Get identity right here before you touch anything else — identity mistakes made during initial setup create cleanup work that compounds across every subsequent configuration step.
Domain Verification
Before you can provision users with your organization’s email domain, that domain must be verified in Control Hub. The verification process involves adding a DNS TXT record to your public DNS zone. This is a prerequisite for everything downstream — SSO, directory sync, and user provisioning all depend on a verified domain.
If the customer has multiple email domains in use across their organization, verify all of them before you start provisioning users. Unverified domains create orphaned accounts that are painful to clean up after the fact.
Identity Provider and SSO Configuration
For any deployment beyond a handful of users, configure SSO during initial setup — not as a follow-up task. The supported identity providers are Azure AD, Okta, and any SAML 2.0-compliant IdP.
SSO configuration in Control Hub follows a standard SAML exchange: export the Webex metadata, import it into your IdP, configure the attribute mappings, test with a non-admin account before enabling broadly. The specific steps vary by IdP but the sequence is the same.
Getting SSO wrong after users are already provisioned means a forced re-authentication event across the organization and potential account linking issues. Do it first.
MFA Enforcement
Enable MFA at the identity provider level before the deployment goes live. Webex Control Hub admin accounts with weak authentication are a real target — compromised admin credentials in a voice system can generate significant toll fraud before anyone notices. MFA enforcement is not optional in a production deployment.
Location Configuration
Locations in Webex Calling are more than organizational labels — they drive emergency calling behavior, PSTN assignment, and device provisioning. Every physical site where phones will be deployed needs a properly configured location before you assign numbers or provision devices.
Each location requires:
- A physical address (used for E911 routing)
- A time zone
- A language setting
- A main number (can be assigned after PSTN configuration)
Multi-site deployments should have all locations defined before user provisioning begins. Assigning users to the wrong location and correcting it later affects emergency calling records and may require number reassignment.
License Assignment
Assign licenses at the location level where possible, not individually. Group-based licensing through your identity provider — Azure AD dynamic groups, Okta group rules — scales better than manual per-user assignment and reduces the chance of users going live without the correct license combination.
Verify the license assignment is correct before provisioning proceeds: Webex Calling Professional for knowledge workers, Workspace for Common Area for shared phones, and Committed Outbound Users count matching the combined total.
User Provisioning and Directory Sync
Manual user creation does not scale. For any deployment beyond a small office, set up directory sync before you provision users.
Azure AD Sync and SCIM Provisioning
The standard integration for Microsoft-based organizations is Azure AD with SCIM provisioning. SCIM (System for Cross-domain Identity Management) automates user lifecycle management — users created, modified, or deactivated in Azure AD are reflected in Control Hub automatically.
The setup involves configuring the Webex app in Azure AD’s enterprise application gallery, generating a SCIM token in Control Hub, and mapping the attribute schema between the two systems. The attributes that matter most for Webex Calling are display name, email address, and the group membership that drives license assignment.
Test the sync with a small pilot group before enabling it broadly. Verify that the attribute mapping produces clean display names and that license assignment triggers correctly from group membership. Fixing a bad attribute mapping after 500 users have been synced is a longer conversation than testing it upfront with 10.
Manual Users
Manual provisioning is appropriate for small deployments or for admin and service accounts that shouldn’t be managed by directory sync. For bulk imports, Control Hub supports CSV-based user creation. Use the CSV import for initial population of small deployments where directory sync isn’t warranted — it’s faster than one-by-one entry and produces a clean audit trail.
Hybrid Identity Considerations
Organizations with hybrid Azure AD environments — on-premises Active Directory synchronized to Azure AD via Azure AD Connect — have additional considerations. User principal names must be consistent between on-premises and cloud, and the SCIM provisioning needs to be sourced from Azure AD, not on-premises AD directly.
Hybrid identity mistakes are the most common source of long-term operational pain in Webex Calling deployments. Users end up with duplicate accounts, mismatched attributes, or licensing that doesn’t follow the user correctly through lifecycle events. Validate the identity source of truth before you sync.
Where Part 1 Ends
At this point in the deployment you have:
- Licensing confirmed and assigned
- Network validated against production voice requirements
- Control Hub configured with verified domains, SSO, MFA, and locations
- Users provisioned and directory sync running
Part 2 picks up from here: PSTN configuration, device deployment, dial plan design, auto attendants and call queues, E911, survivability, security hardening, and the testing and validation checklist before go-live.