The PSTN Decision Is a Long-Term Commitment
Licensing gives you the phone system. PSTN connectivity gives you dial tone. Of the two decisions you make when deploying Webex Calling, the PSTN option is the one that’s harder to change after go-live — carrier contracts, number ports, and SBC infrastructure don’t unwind quickly. Getting it right at the design stage saves significant cost and operational overhead downstream.
Webex Calling supports three PSTN paths: Cisco Calling Plans, Cloud Connected PSTN (Operator Connect), and Local Gateway. Each one represents a different trade-off between simplicity, cost, flexibility, and operational ownership. This article covers what each option actually involves, where each one fits, and how to choose between them based on your specific deployment scenario.
For the licensing foundation that sits underneath all three PSTN options, see Webex Calling Licensing Explained.
Option 1 — Cisco Calling Plans
What It Is
Cisco Calling Plans is the fully managed PSTN option. Cisco acts as the carrier — phone numbers, calling capacity, and billing all live inside your Webex organization. There is no separate carrier contract, no carrier portal to manage, and no SBC infrastructure to operate. Everything from number ordering to porting to call routing is handled through Control Hub.
How It Works
When a Webex Calling organization is provisioned with Cisco Calling Plans, Cisco’s carrier infrastructure connects directly to the Webex Calling cloud on your behalf. From an operational standpoint there is nothing to configure on the PSTN side — you order numbers through Control Hub, assign them to users or services, and calls flow.
Number management is entirely in Control Hub:
- Order new numbers by area code under Calling > Numbers > Add Numbers
- Port existing numbers through the same interface using a Letter of Authorization
- Assign numbers to users, workspaces, call queues, and auto attendants from within user and feature configuration
The full number management workflow is covered in Number Management in Webex Calling.
Regional Availability
Cisco Calling Plans are not available in every country. Availability varies by region and changes as Cisco expands the program. Before committing to Cisco Calling Plans for a multi-country deployment, verify availability for every country where numbers are needed. A deployment where Cisco Calling Plans covers 8 of 10 countries but not the other 2 creates a split PSTN model — Cisco Calling Plans for most locations and Local Gateway or Operator Connect for the remainder — which adds operational complexity that a consistent Operator Connect deployment would avoid.
Check Cisco’s current Calling Plans availability documentation at the time of design, not at the time of reading this article. Regional availability changes.
Cost Structure
Cisco Calling Plans are priced per user per month, bundled with a pool of included minutes. Outbound calls consume from the pool; inbound calls to DIDs are typically included. The per-user pricing works well at small scale. At larger scale — generally approaching 500 users, though the exact inflection point depends on call volume patterns — the per-user cost compares unfavorably to what a carrier will offer through Operator Connect with volume pricing.
The cost model also means you’re paying for capacity whether you use it or not. A deployment where 30% of users make very few outbound calls is still paying full per-user rates for all of them. Operator Connect’s ability to negotiate based on actual usage patterns can produce materially better economics for deployments with uneven usage distribution.
When Cisco Calling Plans Is the Right Choice
Cisco Calling Plans is the right default when simplicity matters more than cost optimization. Specifically:
- Deployments under roughly 100–150 users where the per-user cost difference versus Operator Connect doesn’t justify the carrier relationship overhead
- Organizations with no existing IT support model — no MSP, no internal IT team — where managing a carrier relationship adds operational burden that doesn’t exist with Cisco Calling Plans
- Fast deployments where time to go-live is a priority and a carrier onboarding process would add weeks to the timeline
- Single-country deployments where regional availability isn’t a constraint
If the organization has a competent IT team or an MSP relationship, and call volume is meaningful, run the Operator Connect numbers before defaulting to Cisco Calling Plans. The cost difference at 200 users over a three-year term is often significant enough to change the recommendation.
Option 2 — Cloud Connected PSTN (Operator Connect)
What It Is
Cloud Connected PSTN — Cisco’s term for what Microsoft calls Operator Connect — connects a third-party carrier’s PSTN infrastructure directly to your Webex organization through a Cisco-certified integration. The carrier relationship, pricing, and calling plans are yours to negotiate directly with the operator. Number management and assignment happen through Control Hub, the same as Cisco Calling Plans. The carrier handles everything on the PSTN side.
Carriers in the Cisco Cloud Connected PSTN program include IntelePeer, CallTower, Bandwidth, Tata Communications, Lumen, and others. The carrier list evolves — check Cisco’s partner directory for the current certified carrier roster.
How the Integration Works
The carrier establishes a certified connection to Cisco’s Webex Calling infrastructure on the backend. From an administrative standpoint you don’t manage this connection directly — it’s handled between the carrier and Cisco as part of the certification program. What you manage is the carrier relationship: number provisioning, porting, calling plan terms, and support escalations all go through your carrier account team rather than through Cisco.
In Control Hub, Operator Connect carriers appear as a PSTN option under Calling > PSTN at the location level. Once your carrier has provisioned your organization on their side, their numbers appear in your Control Hub inventory and behave identically to Cisco Calling Plan numbers for assignment purposes.
The Support Model Advantage
This is the point that most PSTN comparisons miss and it’s worth stating clearly: the right time to move to Operator Connect is not only when you cross a user count threshold. It’s also when you want a single carrier who knows your account, knows your deployment, and works with Cisco on your behalf when something goes wrong.
With Cisco Calling Plans, PSTN support goes through Cisco’s standard support channels. With a good Operator Connect carrier, you have an account team that can escalate internally and coordinate with Cisco directly. For organizations with an MSP managing their Webex deployment, the carrier and MSP relationship often produces faster resolution of PSTN issues than working through Cisco’s support queue.
The support model consideration matters at any size. A 50-user deployment run by an MSP that wants to own the full carrier relationship for their customer is a reasonable Operator Connect use case, not just a cost-driven one.
Cost Decision Framework
The seat count where Operator Connect typically becomes the economically obvious choice over Cisco Calling Plans is around 500 users — at that volume, carrier volume pricing consistently beats Cisco’s standard rates by a meaningful margin. But the real framework is more nuanced:
| Scenario | Lean Toward |
|---|---|
| Under 100 users, no IT support, no MSP | Cisco Calling Plans |
| Under 100 users, MSP managing deployment | Operator Connect — MSP may prefer owning carrier relationship |
| 100–500 users, internal IT team | Run the numbers — Operator Connect often wins on cost |
| 100–500 users, high outbound call volume | Operator Connect — volume pricing compounds |
| 500+ users | Operator Connect — Cisco Calling Plans pricing rarely competitive |
| Multi-country deployment | Operator Connect — better global coverage from large carriers |
| Existing carrier relationship worth preserving | Local Gateway or Operator Connect depending on carrier certification status |
The support model — MSP, internal IT, or no IT — is as important as seat count in this decision. An organization with no internal IT capacity and no MSP benefits from Cisco Calling Plans’ simplicity even at 300 users. An MSP managing 50-user deployments across dozens of customers may standardize on a single Operator Connect carrier for all of them because it simplifies their operational model regardless of what the per-seat math says.
Carrier Selection
Not all Operator Connect carriers are equal. When selecting a carrier for a Webex Calling deployment, evaluate:
Geographic coverage — does the carrier provide numbers and calling in every country where the organization operates? Large global carriers (Tata, Lumen, Bandwidth) have broader international reach than regional specialists.
Support model — what does the support relationship look like? Do you get a dedicated account team or a ticketing queue? For MSPs managing multiple customer deployments, a carrier with a strong partner program matters operationally.
Porting process — number porting timelines and LOA processes vary by carrier. A carrier with a well-documented, reliable porting process saves significant pain during cutover.
Pricing structure — per-seat versus per-minute versus bundled plans. Match the pricing structure to the customer’s actual calling patterns. An organization with high inbound and low outbound volume has different cost optimization opportunities than one with high outbound volume.
Existing relationships — if the organization or MSP already has a strong relationship with a carrier who is Operator Connect certified, that relationship has value beyond the per-minute rate.
Option 3 — Local Gateway
What It Is
Local Gateway connects an existing SIP carrier or on-premises telephony infrastructure to Webex Calling through a certified Session Border Controller. The SBC — either Cisco CUBE or a supported third-party device — acts as the translation and security layer between the carrier’s SIP infrastructure and the Webex Calling cloud. You own the SBC, you own the carrier relationship, and you own the routing logic.
This is the most flexible and most operationally intensive PSTN option. It is the right choice when specific constraints make the managed PSTN options insufficient — not when it looks like it might save money without accounting for infrastructure and management overhead.
When Local Gateway Is the Right Choice
Existing carrier contract that can’t be exited. If the organization has a multi-year SIP trunk contract with a carrier that isn’t Operator Connect certified, Local Gateway is how you preserve that investment while moving to Webex Calling. The carrier contract continues, the SBC bridges it to Webex, and you renegotiate or exit when the term ends.
Migration from on-premises PBX. Organizations moving from CUCM or a legacy key system often need to maintain PSTN connectivity during a phased migration. Local Gateway allows both the legacy PBX and Webex Calling to share the same SIP trunks during transition, with calls routing to whichever system the user has been migrated to.
Routing requirements managed PSTN can’t satisfy. Least-cost routing across multiple carriers, specific PSTN failover logic, regulatory requirements for call routing control, or integrations with legacy systems that require SIP-level customization — these are scenarios where Local Gateway’s flexibility justifies the complexity.
Survivability requirement. Local Gateway is a prerequisite for Webex Calling Local Survivability. If the deployment has a hard requirement for PSTN calling during WAN outages, Local Gateway is required — Cloud PSTN and Operator Connect have no local survivability path. Survivability configuration is covered in Webex Calling Cloud Deployment — Full Setup Walkthrough (Part 2).
SBC Selection and Sizing
The SBC is the most significant infrastructure decision in a Local Gateway deployment. Two considerations dominate: certification and sizing.
Certification: The SBC must be on Cisco’s certified Local Gateway device list. Using an uncertified SBC creates an unsupported configuration that Cisco will not troubleshoot. The certified device list includes Cisco CUBE (running on ISR and ASR platforms), Cisco Catalyst 8000 series, and select third-party SBCs including AudioCodes, Ribbon, and Oracle. Check Cisco’s current certification list — it updates as new platforms and firmware versions are validated.
Cisco CUBE is the natural choice for Cisco-first environments. It runs as a feature on Cisco ISR and ASR routers, integrates cleanly with the existing Cisco network infrastructure, and is supported directly by Cisco TAC. The operational model is familiar to teams already managing Cisco routing infrastructure.
Third-party SBCs (AudioCodes, Ribbon) are worth evaluating when the organization doesn’t have existing Cisco router infrastructure that can host CUBE, or when the SBC vendor’s management platform offers capabilities — centralized management, analytics, carrier interop features — that CUBE doesn’t. Third-party SBCs are fully supported for Webex Calling Local Gateway as long as they’re on the certified list.
Sizing is based on concurrent call capacity. Each simultaneous call consumes one session on the SBC. Size for peak concurrent calls, not average — a call center that handles 200 concurrent calls at peak needs an SBC rated for at least 200 sessions, with headroom for growth. Under-sized SBCs are a common source of call failures during busy periods that look like carrier or Webex issues but are actually SBC resource exhaustion.
Registration vs Certificate-Based Authentication
Webex Calling supports two methods for authenticating the Local Gateway to the Webex Calling cloud:
Registration-based authentication has the SBC register to Webex Calling using SIP REGISTER, similar to how a phone registers. It’s simpler to configure initially but creates a dependency on registration state — if the registration expires or the network interrupts the registration keepalive, the trunk goes out of service until re-registration completes. For production deployments where trunk availability is critical, this dependency is a risk.
Certificate-based authentication uses mutual TLS — both the SBC and Webex Calling present certificates to authenticate the connection. There is no registration state to maintain and no keepalive dependency. The trunk is available as long as the network path between the SBC and Webex Calling is healthy. This is the preferred approach for production deployments.
Certificate-based authentication requires a valid certificate on the SBC signed by a trusted CA. Cisco’s documentation specifies which CAs are trusted for Local Gateway certificates. Self-signed certificates are not supported. Factor certificate procurement and renewal into the deployment plan — an expired certificate takes the trunk out of service.
Dial Peer Architecture
Dial peers are the core routing construct in Cisco CUBE — they define how calls are matched on ingress and routed on egress. A well-designed dial peer architecture is maintainable and predictable. A poorly designed one is a troubleshooting nightmare.
The basic Local Gateway architecture involves four dial peer relationships:
Inbound from carrier — matches calls arriving from the SIP trunk on the carrier-facing interface. Typically matched on the incoming called number or on the carrier’s source IP address.
Outbound to Webex Calling — forwards calls from the carrier toward the Webex Calling cloud. Uses the Webex Calling SIP destination configured during Local Gateway registration.
Inbound from Webex Calling — matches calls arriving from Webex Calling destined for the PSTN.
Outbound to carrier — forwards calls toward the carrier SIP trunk for PSTN delivery.
A representative dial peer structure for outbound PSTN calls in CUBE looks like this:
dial-peer voice 100 voip
description Inbound from Webex Calling
session protocol sipv2
session transport tcp tls
incoming uri request WEBEX_INBOUND
codec g711ulaw
!
dial-peer voice 200 voip
description Outbound to Carrier
destination-pattern .T
session protocol sipv2
session target sip-server
codec g711ulaw
This is illustrative — actual dial peer configuration depends on carrier requirements, number format, codec negotiation, and your specific routing design. The point is the structure: matched pairs of inbound and outbound dial peers for each traffic direction, with clear description fields that make the configuration readable six months after deployment.
Codec Strategy
Codec selection at the SBC affects both call quality and interoperability with the carrier.
G.711 (ulaw for North America, alaw for international) is the safest default for carrier-facing trunks. It is universally supported, produces no transcoding at the SBC for calls between the carrier and Webex Calling, and avoids codec mismatch failures with carriers that have limited codec support. Start with G.711 and add other codecs only if there’s a specific requirement.
G.722 provides wideband audio (HD voice) and is worth enabling for internal calling where both endpoints support it. For carrier-facing trunks, G.722 support varies by carrier — confirm before enabling.
Opus is the native codec of the Webex App. Calls between Webex App users use Opus natively. When a Webex App call routes to the PSTN through Local Gateway, the SBC transcodes between Opus and G.711. This transcoding is handled automatically but does consume SBC processing resources. Factor transcoding load into SBC sizing for deployments with high Webex App usage.
Avoid enabling codecs on carrier-facing trunks that the carrier hasn’t confirmed they support. A codec mismatch during SDP negotiation produces a no-audio call that is difficult to diagnose without a packet capture.
SIP Normalization
Carrier SIP implementations are not uniform. Header values, number formats, and SDP attributes vary between carriers and sometimes between trunk configurations from the same carrier. SIP normalization at the SBC resolves these differences before they reach Webex Calling.
Common normalization requirements:
Number format normalization. Webex Calling expects E.164 format (+1XXXXXXXXXX for North America). Many carriers deliver numbers in 10-digit or 7-digit format without the + prefix. A normalization rule on the inbound carrier dial peer adds the + and country code before the call reaches Webex Calling.
From header manipulation. Some carriers send a From header that doesn’t match what Webex Calling expects for caller ID presentation. Normalization rules can rewrite the From header to produce the correct caller ID on inbound calls.
P-Asserted-Identity handling. PAI headers carry the verified caller identity on SIP trunks. Carriers that send PAI in a format Webex Calling doesn’t recognize may require normalization to extract the correct identity.
In CUBE, normalization is handled through voice class sip-profiles — a set of rules that match and transform SIP header values on ingress or egress. The specific rules depend entirely on what your carrier sends. Get a call trace from a test call before writing normalization rules — trying to normalize a header format you haven’t seen produces rules that may work for some calls but not others.
High Availability Considerations
A single SBC is a single point of failure for all PSTN calling. For production deployments where PSTN availability is a business requirement, design for redundancy from the start.
Active/standby SBC pair — two SBCs where one handles all traffic and the other takes over on failure. Simple to operate but the standby capacity is unused during normal operation. Appropriate for deployments where cost control matters more than maximizing utilization.
Active/active SBC pair — two SBCs sharing load during normal operation, each capable of handling full traffic in the event the other fails. More efficient utilization but more complex to configure and operate. Appropriate for deployments with high call volume where a single SBC would be near capacity.
Geographic redundancy — SBCs at separate physical locations connected to separate carrier trunks. Provides resilience against both SBC failure and site-level events (power, connectivity). The most resilient architecture and the most operationally complex. Appropriate for deployments where PSTN availability is mission-critical.
Webex Calling supports multiple Local Gateway trunks per organization. Voice routing policies in Control Hub control which trunk is used for which calls and can be configured to prefer one trunk and fall back to another on failure.
Choosing the Right PSTN Option
The decision framework comes down to three factors: operational model, scale, and existing infrastructure.
| Factor | Cisco Calling Plans | Operator Connect | Local Gateway |
|---|---|---|---|
| Operational complexity | Lowest — fully managed | Low — carrier manages PSTN | Highest — SBC infrastructure to own |
| Cost at small scale (<100 users) | Competitive | Comparable or slightly higher | Higher when SBC cost is included |
| Cost at medium scale (100–500 users) | Starts to lose | Often better with volume pricing | Depends on existing infrastructure |
| Cost at large scale (500+ users) | Rarely competitive | Usually best managed option | Depends on carrier contract |
| Carrier flexibility | None — Cisco is the carrier | High — negotiate with any certified carrier | Maximum — any SIP carrier |
| Survivability support | None | None | Yes — with Survivability Gateway |
| Existing carrier contract | Not relevant | Relevant if carrier is certified | Preserves existing investment |
| Support model preference | No carrier relationship to manage | Single carrier relationship | Carrier + SBC vendor relationships |
| International coverage | Limited by Cisco availability | Strong with global carriers | Any carrier in any country |
The honest summary: Cisco Calling Plans is the right default for simple, small deployments where nobody wants to manage a carrier relationship. Operator Connect is the right choice for most mid-market and enterprise deployments — it offers carrier flexibility and volume pricing without SBC infrastructure. Local Gateway is the right choice when you have existing infrastructure to preserve, survivability requirements, or routing complexity that managed PSTN can’t satisfy.
If you’re building a quote and the customer has no existing carrier contracts, no survivability requirements, and is under 100 users with no MSP, start with Cisco Calling Plans. If any of those conditions change, re-evaluate against Operator Connect before the quote goes out.
Final Thoughts
The PSTN decision is not reversible without effort. A deployment that starts on Cisco Calling Plans and needs to move to Local Gateway two years later because the organization grew and acquired a CUCM environment involves number porting, SBC procurement, and a carrier migration — none of which are quick. Make the decision with a three-year view, not a go-live-day view.
For the network requirements that affect all three options equally, Webex Calling Network Requirements — QoS, Firewall Ports, and Split Tunneling covers what the WAN and firewall need to look like before any PSTN option will perform reliably.