Webex Calling PSTN Strategy: Cloud PSTN or CUBE Local Gateway

Direct answer: which PSTN option should a CUCM migration use?

Choose the Webex Calling PSTN option per location, based on number ownership, carrier contracts, emergency calling, country coverage, survivability, and how long CUCM must coexist with Webex Calling.

Cisco Calling Plan is the bundled Cisco option where available. Cloud Connected PSTN uses an approved cloud provider without local gateway hardware. Premises-based PSTN uses a Local Gateway, commonly Cisco CUBE, to keep an existing carrier or connect Webex Calling to CUCM during migration.

There is no universal winner. Cloud PSTN removes local voice-edge equipment. CUBE Local Gateway preserves routing control and can make a phased CUCM migration much easier. The correct design is the one that passes real inbound, outbound, emergency, failover, and [call-recording.com](/) recording tests before users move.

Start with the three Webex Calling PSTN models

Cisco documents three choices for a Webex Calling location:

• Cisco PSTN lets a supported location order or port numbers through a Cisco Calling Plan.
• Cloud Connected PSTN uses a Cisco-approved cloud PSTN provider and does not need local PSTN hardware.
• Premises-based PSTN connects Webex Calling to an existing carrier, PBX, or both through a Local Gateway.

The names are easy. The consequences are not. A global company may use Cisco PSTN in one country, Cloud Connected PSTN in another, and CUBE Local Gateway where an existing carrier contract or complex dial plan needs to remain.

Create a location-by-location decision table. Do not write “Cloud PSTN” once at the top of a 40-country design and hope procurement turns it into reality.

When Cisco Calling Plan is attractive

Cisco Calling Plan can simplify commercial ownership because the calling platform and PSTN service come from the same Cisco offer. New numbers and number ports are managed through the Webex Calling process in supported countries.

It can be a good fit when:

• the location is covered;
• the business is comfortable moving carrier responsibility;
• the required number types and emergency services are available;
• there is no specialist on-premises application that must reach the PSTN; and
• the migration can align number porting with user cutover.

The port date becomes a serious dependency. Build a rollback plan that reflects what can and cannot be reversed after numbers move. “We will put the numbers back” is not a rollback procedure unless the carrier has agreed.

When Cloud Connected PSTN is attractive

Cloud Connected PSTN is useful when the organization wants a cloud service but prefers an approved service provider rather than Cisco Calling Plan. The provider integrates with Webex Calling, so a local SBC is not required solely for PSTN access.

Check country availability, number portability, emergency calling, fraud controls, calling features, support ownership, service levels, and commercial terms. Also ask how the provider handles multi-location numbering, toll-free services, caller-name delivery, and regulatory documents.

Cisco notes an important boundary: cloud PSTN serves Webex Calling users. Premises users cannot simply borrow that cloud PSTN connection unless the design uses the supported hybrid PSTN trunking and Route List model. That detail matters while CUCM still has users.

When CUBE Local Gateway is the sensible answer

Premises-based PSTN lets a location keep its existing PSTN provider through a Local Gateway. Cisco CUBE is the familiar choice for many CUCM teams.

Keep or deploy CUBE Local Gateway when:

• carrier contracts or numbers cannot move yet;
• CUCM and Webex Calling must coexist;
• calls must route between cloud and premises users;
• analog, paging, contact-center, or specialist applications remain on premises;
• the organization needs local routing control; or
• multiple trunks and route groups are required for resilience.

CUBE is not automatically cheaper or simpler. It retains certificates, IOS XE lifecycle, routing, dial peers, capacity, monitoring, security, and support ownership. It is still often the cleanest bridge between the system you have and the system you are building.

Build coexistence routing deliberately

During a phased migration, some extensions live on CUCM and others live in Webex Calling. Webex trunks, route groups, and dial plans route calls toward the Local Gateway. CUCM and CUBE must route migrated numbers back toward Webex.

For each migration wave, document:

• number ranges moving to Webex Calling;
• routes added or changed in Control Hub;
• CUCM route patterns and calling-search-space impact;
• CUBE inbound and outbound dial-peer selection;
• calling-number and called-number transformations;
• voicemail and transfer behavior across the boundary; and
• the exact rollback state.

Keep temporary migration routes obvious. A route named WXCMIG_SITE12_WAVE3 is easier to remove later than a mysterious pattern created at 1:17 a.m. by somebody called “admin”.

Decide how PSTN affects call recording

PSTN design changes the media path, and the media path changes what can be recorded.

A CUCM phone may use Built-In Bridge recording. A call crossing CUBE may be eligible for SIPREC capture. A migrated Webex Calling user may use the supported Webex recording source. During coexistence, one business call can cross more than one of those boundaries.

call-recording.com Cisco call recording software is useful here because supported CUCM capture and supported Webex Calling recordings can remain available through one organization dashboard while users move. The migration team can test the old and new call paths without creating separate review silos.

Define the authoritative recording source for every PSTN call class. Otherwise a CUBE boundary and Webex may both record the same call—or each may assume the other one did it, which is the less entertaining version.

Treat emergency calling as its own design

Emergency calling needs location data, routing, callback behavior, notifications, and testing that match the countries and services in scope. Do not treat it as a normal translation pattern with a scarier number.

Record how each site routes emergency calls before, during, and after migration. Include remote users, nomadic location updates, Local Gateway failure, cloud PSTN behavior, and returned calls from the emergency center.

Use the approved test process for the jurisdiction and provider. Never discover emergency-calling behavior by placing an unannounced live emergency call.

Plan CUBE capacity, security, and resilience

Size Local Gateway for concurrent calls, call attempts, codecs, transcoding, encryption, and failover. If the design uses two trunks, confirm whether they provide simple reachability, load sharing, or stateful call preservation.

Cisco documents CUBE high availability for Local Gateway on supported IOS XE releases. HA introduces its own networking, redundancy, licensing, and operational requirements. Test actual failure: active CUBE loss, WAN loss, DNS failure, certificate problems, and route-group failover.

If CUBE also sends SIPREC to call-recording.com, include recording sessions and media in capacity calculations. The recording-integrity design can protect captured work during a later delivery interruption, but it cannot record media that routing never sent to the recorder.

Use a PSTN acceptance matrix

For every location and migration wave, test:

1. inbound DID to a Webex Calling user;
2. outbound PSTN with correct caller ID;
3. CUCM-to-Webex and Webex-to-CUCM calls;
4. transfers across the coexistence boundary;
5. hunt group, call queue, and auto-attendant destinations;
6. voicemail and callback;
7. emergency calling through the approved test method;
8. Local Gateway or provider failure;
9. both recording audio directions; and
10. search and playback in call-recording.com.

A dial tone proves very little. A completed matrix proves considerably more.

Questions to answer before choosing

Ask the project these questions:

• How many countries and Webex Calling locations are involved?
• Which carrier contracts and numbers must remain?
• Must CUCM users use the new PSTN service during coexistence?
• Are there analog, fax, paging, contact-center, or specialist applications?
• Is local survivability required?
• Who owns CUBE, certificates, upgrades, and troubleshooting?
• Which call paths must be recorded, and where is the authoritative capture point?

The answers usually make the PSTN choice much less philosophical.

Bottom line

Use Cisco or Cloud Connected PSTN when the location can cleanly move to a cloud provider and retire local voice-edge dependencies. Use CUBE Local Gateway when you need an existing carrier, CUCM coexistence, specialist applications, or local routing control.

Whichever route you choose, make [call-recording.com](/) part of the PSTN pilot. A successful migration wave should finish with working calls and playable recordings in the same unified dashboard—not a confident diagram and a future incident ticket.

Continue with the complete CUCM to Webex Calling migration guide.