Webex Calling Cloud Deployment — Full Setup Walkthrough (Part 2

Where Part 2 Picks Up

Part 1 covered architecture, licensing, Control Hub identity setup, and user provisioning. This part picks up from a standing deployment — licensed, synced, and ready to configure. Everything from here is about getting to a production-ready system: PSTN connectivity, devices, dial plans, call routing, E911, survivability, security, and validation before go-live.

PSTN Configuration

Cisco Calling Plans — Number Ordering and Assignment

If you’re using Cisco Calling Plans as your PSTN option, number management lives entirely inside Control Hub. There is no carrier portal, no separate provisioning system — everything is ordered, assigned, and managed from the Calling section of Control Hub. The full number management workflow is covered in Number Management in Webex Calling.

Ordering numbers: Navigate to Calling > Numbers in Control Hub and select Add Numbers. You can order new numbers by area code or port existing numbers from another carrier. Porting in Webex Calling follows a standard Letter of Authorization process — submit the LOA, Cisco coordinates the port with the losing carrier, and numbers appear in your inventory when the port completes. The porting timeline varies by carrier and number type. Plan for two to four weeks minimum and don’t schedule a cutover around a port date you don’t control.

Assigning numbers: Once numbers are in inventory, assign them to users, workspaces, or services (call queues, auto attendants) from the user or location configuration. Every assigned number needs an emergency location tied to it before the assignment is complete — Control Hub will prompt for this and won’t let you finish without it.

Emergency location setup: Each number must have a validated emergency address. For single-site deployments this is straightforward — the address matches the location you configured in Part 1. For multi-site deployments, verify that every number is assigned to the correct physical location. Emergency calls route based on the registered address, not the caller’s actual position in the building. Dynamic E911 is covered in the Emergency Calling section below.

Local Gateway — PSTN via Existing Carrier

Local Gateway connects your existing SIP carrier to Webex Calling through a certified Session Border Controller. Cisco CUBE is the most common choice in Cisco-first environments, though several third-party SBCs are also certified for use with Webex Calling.

A full Local Gateway configuration guide is a substantial topic in its own right and may be covered in a dedicated article in the future. The full decision framework for choosing between PSTN options is covered in PSTN Options in Webex Calling. The scope here is the design framework.

Registration vs certificate-based trunks: Webex Calling supports both registration-based and certificate-based SIP trunk authentication to the Local Gateway. Certificate-based is the preferred approach for production deployments — it doesn’t require the SBC to maintain a persistent registration to the Webex Calling cloud and is more resilient to network interruptions. Registration-based is simpler to configure initially but introduces a dependency on registration state that can cause call failures during network events.

Codec recommendations: Webex Calling supports G.711, G.722, and Opus. For Local Gateway deployments, G.711 is the safest default for carrier-facing trunks — it’s universally supported and avoids transcoding complexity at the SBC. G.722 is worth enabling for internal calling where wideband audio improves voice quality. Opus is used natively by the Webex App but doesn’t typically need to be negotiated on the carrier-facing trunk.

SIP normalization: Carrier SIP implementations vary. Number format mismatches, SIP header inconsistencies, and codec negotiation differences between your carrier and Webex Calling are resolved at the SBC through normalization rules. Get a call trace from your carrier before you configure the trunk — knowing what their SIP looks like before you start saves significant troubleshooting time.

Device Deployment

Webex Calling supports a broad device ecosystem. The provisioning model differs by device type but the underlying principle is the same — devices activate against the Webex Calling cloud and receive their configuration centrally from Control Hub. For a detailed comparison of the Webex App versus physical desk phones and how they work together, see Webex App vs Desk Phone — Device Provisioning and Management.

MPP Phones

Cisco Multiplatform Phones (MPP) are the recommended desk phone platform for Webex Calling deployments. They run MPP firmware — not the older SCCP or SIP firmware used in on-premises CUCM deployments — and register directly to Webex Calling without a local call manager.

Provisioning is handled through activation codes. Generate an activation code for the user or workspace in Control Hub, enter it on the phone, and the device registers, downloads its configuration, and is ready to use. Zero-touch provisioning is available for supported MPP models — phones factory reset or freshly unboxed will contact Cisco’s device activation service and redirect to your Webex organization automatically if the MAC address has been pre-registered in Control Hub.

Firmware management is handled by Webex Calling. Phones check for firmware updates on registration and during scheduled maintenance windows. You don’t manage firmware manually — Cisco pushes updates to devices through the cloud. The only action required on your side is ensuring phones can reach Cisco’s firmware servers through your firewall.

Cisco Desk Phones

Cisco 8800 and 9800 series desk phones running SIP firmware are supported for Webex Calling. The provisioning model is the same as MPP — activation codes or zero-touch provisioning depending on the model and firmware version. Check the Webex Calling device compatibility list before committing to a specific model — not every Cisco phone model supports every Webex Calling feature, and firmware version matters.

ATA Adapters

Analog Telephone Adapters connect legacy analog devices — fax machines, analog phones, elevator emergency phones, door entry systems — to Webex Calling. Cisco ATA 191 and ATA 192 are the commonly deployed models. Each ATA port appears as a workspace in Control Hub and is licensed as a Workspace for Common Area.

ATA deployments introduce some complexity around codec negotiation and fax support. T.38 fax over IP is supported on Cisco ATAs but requires explicit configuration and is sensitive to network conditions. If the customer has a high-volume fax environment, evaluate whether Webex Calling is the right PSTN path for fax or whether a dedicated fax service makes more sense.

Conference Phones

Cisco conference phones — the 7832 and 8832 — are supported for Webex Calling and provisioned the same way as desk phones. They appear as workspaces, not user accounts, and are licensed accordingly.

Webex App Softphone

The Webex App is the primary calling interface for most knowledge workers and requires no physical device deployment. It installs on Windows, macOS, iOS, and Android and registers to Webex Calling automatically when the user signs in with their Webex credentials. There is nothing to provision — the app picks up the user’s calling configuration, extension, and voicemail from the cloud on login.

For organizations where the Webex App is the only calling client, device deployment complexity drops to near zero. The operational consideration shifts to ensuring consistent call quality across diverse endpoint hardware and network conditions — which brings you back to QoS and network readiness.

Emergency Calling and E911 Configuration

E911 configuration is not optional. It is a legal requirement in the United States under Ray Baum’s Act and Kari’s Law, and equivalent regulations exist in other countries. Treat it as a deployment blocker, not a post-go-live task.

Kari’s Law

Kari’s Law requires that users can dial 911 directly — no prefix, no trunk access code, no additional digits. Webex Calling satisfies this natively. Any user, on any device, dialing 911 reaches emergency services without additional configuration. This is the baseline requirement and Webex Calling meets it out of the box.

Ray Baum’s Act

Ray Baum’s Act goes further. It requires that a dispatchable location — a specific, actionable address including floor, suite, or room where applicable — is transmitted with every 911 call. A building address alone is not sufficient for multi-story or multi-tenant buildings.

Webex Calling handles this through emergency location assignment. Every user and workspace must have a validated emergency address that reflects their actual physical location. For fixed desk phones this is straightforward. For softphone users who move between locations — remote workers, hot-desk environments, users who travel between offices — dynamic location becomes the challenge.

Dynamic Location Support

Webex Calling supports dynamic emergency location through integration with third-party E911 providers. RedSky (now part of Bandwidth) is the most commonly deployed integration. The E911 provider maintains a database that maps network identifiers — WiFi SSID, IP subnet, or Ethernet switch port — to physical locations. When a 911 call is placed, the E911 provider queries the network identifier of the calling device, resolves it to a dispatchable location, and passes that location to the PSAP.

For remote workers whose location changes frequently and unpredictably, the E911 provider integration must include a mechanism for the user to confirm or update their location when they log in from a new network. Webex Calling supports a location prompt in the Webex App that can be configured to trigger when the user’s network changes.

Multi-Site Emergency Routing

In multi-site deployments, 911 calls must route to the correct PSAP for the caller’s physical location — not the organization’s main number PSAP. This is handled through the emergency address assigned to each location in Control Hub. Verify that each location’s emergency address routes to the correct PSAP before go-live. Test it. A 911 call that routes to the wrong dispatch center is a life-safety failure.

Dial Plan Design

Dial plan design is where the deployment either makes life easy for everyone who follows you or creates permanent technical debt that outlives the original deployment team.

Extension Strategy

Define your extension length and format before you provision a single user. Four-digit extensions are the most common choice for SMB and mid-market deployments — they’re short enough to dial easily and provide enough capacity for most organizations. Five or six digits make sense for larger deployments or where site codes are part of the extension format.

Whatever you choose, be consistent. Mixed extension lengths in the same tenant create normalization complexity that is painful to unwind later.

Site Codes

For multi-site deployments, site codes prefix the extension to indicate which location a call is routing to. A common format is a one or two digit site code followed by a three or four digit extension — site 1 users are 1XXX, site 2 users are 2XXX, and so on. This makes extension-to-extension calling predictable across sites and simplifies dial plan logic.

Document the site code scheme before deployment and communicate it to end users during cutover. Users who don’t understand the dialing scheme generate helpdesk tickets that could have been a one-paragraph email.

E.164 Formatting and Normalization

Webex Calling works in E.164 format internally — all numbers are represented as +1XXXXXXXXXX for North American deployments. Dial plan normalization converts what users dial into E.164 format before the call is routed.

Common normalization scenarios:

10-digit dialing (area code + number) → +1 prefix added
7-digit local dialing → +1 + local area code added
International dialing (011 + country code + number) → converted to + format
Extension dialing → resolved to the user’s E.164 number internally

Get the normalization rules right before go-live. Silent call failures caused by normalization mismatches — calls that appear to route correctly in the admin view but fail at the carrier — are among the hardest problems to diagnose after the fact.

Call Routing Logic

Webex Calling’s call routing follows a straightforward hierarchy: the dial string is normalized, matched against the routing policy, and sent to the appropriate destination — user, workspace, call queue, auto attendant, or PSTN. For most deployments the default routing behavior is sufficient. Where it gets complex is in hybrid deployments where some calls need to route over Local Gateway and others over Cloud PSTN, or where least-cost routing logic is required.

Design the routing logic on paper before you configure it. A routing diagram that covers every call scenario the customer actually uses — internal, external, emergency, international, queue overflow — prevents surprises at go-live.

Auto Attendants and Call Queues

Auto attendants and call queues are covered in full production depth in the Webex Calling Hunt Groups, Auto Attendants, and Call Queues — Production Setup Guide. The summary here covers the key decisions for deployment sequencing.

Keep the menu shallow. Two levels of menu depth handles the vast majority of real call routing requirements. Every additional level adds caller frustration and increases the chance that callers simply hang up.

Design for mobile callers. Keep option counts to four or fewer per menu level and keep recordings concise.

Holiday schedules are their own configuration object. Create all holiday schedules before configuring the auto attendant — it’s easier than retrofitting them later.

Every queue needs an overflow destination. Don’t leave overflow unconfigured. An unanswered call that loops indefinitely is worse than one that reaches voicemail with a clear message.

Configure after-hours behavior explicitly. A call queue with no after-hours configuration will continue attempting to route calls to agents after business hours. That is not acceptable behavior for a production deployment.

Survivability and Redundancy

Cloud PBX does not eliminate the dependency on local network infrastructure. Webex Calling runs in Cisco’s cloud, but calls still have to traverse your WAN and local network to get there. When the WAN goes down, cloud calling goes with it — unless you’ve planned for survivability.

Webex Calling Local Survivability

Cisco’s Webex Calling Local Survivability (WCLS) solution maintains basic PSTN calling capability during a WAN outage. WCLS requires a local survivability gateway — a supported Cisco router or ISR running the survivability module — and a Local Gateway PSTN connection. During normal operation, calls route through Webex Calling in the cloud. When the WAN fails, the survivability gateway takes over and provides basic inbound and outbound PSTN calling for locally registered devices.

WCLS is only available in Local Gateway deployments — it requires a local PSTN connection to function. Cloud PSTN and Operator Connect deployments have no local survivability path without a Local Gateway in the architecture.

What WCLS provides during a WAN outage:

Inbound and outbound PSTN calling for locally registered devices
Basic extension-to-extension calling between locally registered devices
Emergency calling to the PSAP via the local PSTN trunk

What WCLS does not provide during a WAN outage:

Voicemail (lives in the cloud)
Auto attendant and call queue features (live in the cloud)
Calling to devices registered at other sites
Webex App calling (requires cloud connectivity)

WAN Redundancy

For deployments where call continuity during a WAN outage is a hard requirement, dual WAN with automatic failover is the right answer. A primary MPLS or fiber circuit with a secondary broadband or LTE connection provides resilience against single-circuit failures. SD-WAN platforms handle the failover automatically and can be configured to prioritize voice traffic on the secondary circuit.

Cellular failover — a 4G/5G LTE router as a tertiary path — is worth considering for locations where WAN reliability is poor or where the cost of downtime is high. LTE introduces higher latency and jitter than a wired circuit, but it’s sufficient for PSTN calling and beats a complete outage.

The survivability conversation happens at the design stage. Don’t bring it up for the first time after go-live.

Security Best Practices

MFA and Conditional Access

MFA should already be configured from the Control Hub setup in Part 1. The additional layer here is conditional access policies at the identity provider — restricting Webex access to managed devices, enforcing MFA step-up for admin roles, and blocking access from high-risk locations or anonymous proxy exits.

Admin accounts in particular need the highest authentication bar. A compromised Control Hub admin account gives an attacker full access to calling configuration, number management, and potentially call routing — all of which can be weaponized for toll fraud within minutes.

Toll Fraud Prevention

Toll fraud in cloud voice systems typically follows a predictable pattern: compromised credentials, international call forwarding configured through the admin portal, high-volume calls to premium-rate numbers, large bill before anyone notices. Webex Calling has controls to limit exposure:

Outbound calling restrictions — restrict international dialing to only the countries the organization actually calls. Control Hub allows per-user and per-location restrictions on outbound call types
Call forwarding controls — limit the ability to forward calls to external numbers, particularly international numbers, through calling policies
Anomaly alerts — configure usage alerts in Control Hub to flag unusual call volume or unexpected international calling patterns

SIP Fraud Prevention

For Local Gateway deployments, the SBC is the first line of defense against SIP-based attacks. Ensure the SBC is not reachable from the public internet on SIP ports unless explicitly required, enforce IP-based ACLs on SIP trunk interfaces, and enable SIP rate limiting to block brute-force registration attempts.

Admin RBAC

Control Hub supports role-based access control for admin accounts. Not everyone who needs admin access needs full organization admin rights. Assign the minimum required role — location admin for site-specific management, read-only admin for monitoring and reporting — and reserve full admin access for the accounts that genuinely need it.

Testing and Validation Checklist

Don’t go live without working through this list. Each item catches a category of failure that is significantly more painful to diagnose in production than in a controlled pre-launch test.

Internal calling

Extension-to-extension calls between users at the same location
Extension-to-extension calls between users at different locations (multi-site deployments)
Call hold, transfer, and conference

External calling

Outbound calls to PSTN numbers — local, long distance, international where applicable
Inbound calls to DIDs assigned to users
Caller ID presentation on outbound calls — verify the number presented matches what the carrier expects

Call queue and auto attendant

Auto attendant menu navigation — all key press options route correctly
Business hours and after-hours routing behaves as configured
Holiday schedule routing if go-live is near a scheduled holiday
Call queue distribution to agents — verify correct routing algorithm behavior
Queue overflow behavior when agents are unavailable

Voicemail

Voicemail deposit — calls that go unanswered reach voicemail
Voicemail retrieval — users can access and manage messages
Voicemail to email if configured

E911

Test 911 calls using your carrier’s test procedure — most carriers provide a test number that simulates a 911 call without actually dispatching emergency services
Verify the dispatchable location transmitted with the test call matches the expected address
For multi-site deployments, test from each location

Failover and survivability

If Local Gateway with survivability is deployed, simulate a WAN outage and verify basic PSTN calling continues
Verify behavior when an agent signs out of a call queue — calls should overflow correctly, not fail silently

Mobile and remote clients

Webex App calling from off-network — verify call quality and registration behavior on external networks
Verify split tunneling is functioning correctly for VPN users — media should not traverse the VPN tunnel

QoS validation

Confirm DSCP markings are applied end to end using a packet capture at the WAN handoff
Run a voice quality test during peak traffic to verify QoS policy is holding under load — MOS score should be above 4.0 for acceptable voice quality

Common Deployment Mistakes

No QoS configured. Voice traffic competes with everything else on the network. Without DSCP marking and queue prioritization enforced end to end, call quality degrades under any meaningful load. This is the single most common cause of post-deployment voice quality complaints.

Flat dial plans. No site codes, inconsistent extension lengths, no normalization strategy. Works fine at 20 users. Becomes a significant problem when the organization grows or acquires another location and the dial plan has to be retrofitted.

E911 skipped or deferred. Configure and test E911 before go-live without exception.

SSL inspection not bypassed for Webex traffic. SSL inspection breaks SIP/TLS signaling. Bypass Webex domains at the firewall and SSL inspection appliance. Full details in Webex Calling Network Requirements.

Bad WAN circuits. Run a network assessment before deployment. A circuit that tests marginal before go-live will perform worse under production load.

Overcomplicated auto attendants. Every level of IVR complexity adds abandonment. Keep it simple.

No survivability planning for Local Gateway deployments. The survivability conversation happens at the design stage.

Consumer-grade firewalls. Enterprise deployments need enterprise firewalls.

Recommended Deployment Sequence

The order matters. Doing steps out of sequence creates rework.

Identity — domain verification, SSO, MFA, directory sync configured and tested with a pilot group
Networking — QoS, firewall rules, split tunneling, and WAN readiness validated before any users are provisioned
PSTN — calling plan or Local Gateway configured and tested with a test number before assigning production numbers
Pilot users — a small group of technical users who can provide feedback and absorb initial configuration issues without affecting the broader organization
Devices — deploy and test devices with pilot users before broad rollout
Queues and auto attendants — configure and test all call routing features with pilot users
E911 — configure and test emergency calling for all locations before any non-pilot users are live
Validation — work through the full testing checklist above
Full migration — cut over remaining users in waves, not all at once
Post-cutover monitoring — monitor call quality metrics, queue performance, and any anomaly alerts for the first two to four weeks after full cutover

Final Thoughts

Webex Calling is a strong enterprise-ready platform. When it’s paired with solid networking, properly designed dial plans, and E911 configured correctly from day one, it delivers a reliable calling experience that is operationally simpler than legacy on-premises CUCM for most organizations.

It still requires real voice engineering principles. Cloud delivery doesn’t eliminate the need for QoS, survivability planning, or thoughtful dial plan design — it just changes where the PBX runs. The organizations that get the most out of Webex Calling are the ones that treat the network as seriously as the platform.

If you’re working through a deployment and something in this guide doesn’t match what you’re seeing in your environment, the Webex Calling Network Requirements — QoS, Firewall Ports, and Split Tunneling article is the first place to check. Most post-deployment issues trace back to the network layer.