Navigating PSTN Migration with Webex Calling

Moving a phone system onto a cloud platform raises a question that has to be settled before any feature comparison matters: how calls reach the public telephone network, and who is accountable when they do not. It usually arrives in four parts.

• How do the numbers we already have get to the cloud?
• Does anybody have to be issued a new number?
• What happens to the carrier contract we are still inside?
• What do we do about numbers that cannot be ported?

There are three general ways an organization reaches the public switched telephone network (PSTN) from a cloud calling platform, and a large estate usually ends up running more than one of them at once. On a proposal they look similar. What separates them is who holds the carrier relationship, and that decides four practical things: who you call when a call fails, whose name sits on the number records, what happens to the contract you are still paying for, and how much porting lands on the critical path.

Option one: buy the numbers from the platform vendor

The platform vendor sells the calling service and the telephone numbers together. Numbers are ordered in the same administrative portal as the user licenses and arrive on the same invoice. Nothing is installed on your premises.

• When a call fails: one vendor owns the whole path, and there is one number to call. The same fact cuts the other way. You cannot escalate around that vendor, and you have no second opinion on what its network did with the call.
• Number records: the vendor, or the carrier standing behind it, becomes the carrier of record for every number you hold there. Requests to move a number later go through the vendor.
• Existing contracts: they do not disappear. You either run the current agreement to its end date or pay whatever the termination language says, and that figure belongs in the comparison from the beginning.
• Porting: every number you intend to keep has to be ported in. This is the option with the most porting in it, so it is the option most exposed to a port request that stalls.

It fits an organization with a number inventory it can actually account for, no particular reason to keep the incumbent carrier, and a preference for a single bill and a single support path.

Option two: bring your own carrier through a certified provider program

Cloud calling platforms run programs in which carriers integrate their networks with the platform and are certified against it. You buy trunks and numbers from the carrier under your own agreement, and the platform links the ordering and provisioning so numbers appear in the administrative portal the same way. There is still nothing installed on your premises.

• When a call fails: two organizations are involved, and the point of the certification is that they have already agreed where their boundary sits. Get it in writing which one you open the ticket with, before the morning you need to know.
• Number records: the carrier is the carrier of record and holds a direct commercial relationship with you. If the carrier you use today is in the program, some numbers may not have to move at all.
• Existing contracts: sometimes they survive. A carrier already in the program may be able to move you to a different service under the same master agreement, which is a conversation worth having before anybody writes off the contract as sunk cost.
• Porting: less of it where the incumbent participates. Where it does not, the porting work looks the same as option one.

It fits an organization that wants to keep a carrier relationship it negotiated, needs coverage the platform vendor does not sell directly, or has regulatory reasons for calls to leave through a particular network.

Option three: connect your own gateways to your own SIP trunks

A session border gateway sits in your building or your data center. It registers to the cloud platform on one side and terminates the trunks or circuits you already buy on the other. The platform hands calls to it, and it hands them to the carrier. Designs normally use a pair per region, because dial tone for those sites now depends on equipment you own.

• When a call fails: you own the middle. The platform sees a call that left its network intact, the carrier sees a call it delivered, and the answer is in the gateway logs. Somebody has to be able to read a SIP trace, either in your team or under a support agreement that names the gateway.
• Number records: unchanged. The carrier you use today stays the carrier of record and the numbers never move.
• Existing contracts: they continue exactly as written, which is frequently the whole reason this option gets chosen.
• Porting: none for the numbers that stay where they are, which takes porting off the critical path of the platform migration. It is also the available answer for numbers that cannot be ported and for lines that have to terminate at a specific site.

The price of that control is that part of the call path is now yours to operate: hardware, a redundant pair, certificate renewals, software maintenance and somebody on the hook at three in the morning. It is also the usual mechanism for a phased migration, with users moving to the platform in groups while the trunks stay where they are.

What none of the three options changes

A multi-line telephone system that was manufactured, imported, offered for first sale or lease, first sold or leased, or installed after 16 February 2020 carries federal obligations for emergency calling however it reaches the network. Kari’s Law requires that a user can dial 911 directly, with no additional digit, code, prefix or post-fix. It also requires a notification, which may go to a central location at the facility or to another person or organization regardless of location, where the system can be configured to provide it without an improvement to the hardware or software of the system. Under the same rules, a fixed device must convey an automated dispatchable location with the call, while a non-fixed on-premises device or an off-premises device must do so where technically feasible and otherwise supply a location the end user can update. What differs between the three options is where the location information is held and who has to keep it accurate as people move desks. The obligation itself applies either way. Settle it during design, because building location data for a few hundred stations after cutover is its own project with its own budget.

How the decision actually gets made

The comparison starts with two documents: the carrier contracts, with their end dates and termination language, and a complete inventory of the numbers. Most estates finish with a mix. Head office numbers port to the platform, a site with a non-portable range or an unfinished term stays behind a gateway, and the analog lines serving elevators, alarms and fire panels get handled on their own terms.

Then there is the schedule. Porting in the United States runs under FCC rules, which define what counts as a simple port and the interval that applies to one. The interval itself is rarely what slips. Requests get rejected for reasons that have nothing to do with engineering: a billing telephone number that does not match, a service address written differently from the one on the invoice, numbers discovered in an account nobody knew existed, an authorization signed by someone who left two years ago. Each rejection sends the request back to the start of the queue. Nobody can give you a firm cutover date before the customer service records are in hand and reconciled against that inventory, and that includes us.

Trybus Solutions works across all three models and does not publish comparisons between manufacturers or carriers. What we do is build the number inventory, reconcile it against the carrier records, cost each option against the commitments you already hold, and implement the one you choose.

Where this work starts

The first deliverable on a project like this is not a design. It is a list. Every number the organization holds, the account and carrier of record it sits in today, and what each one does: main lines, direct dial ranges, fax, alarm and elevator lines, and the number printed on a card somewhere that still reaches a machine in a closet. That list is what makes the three options costable, and it is normally the slowest part of the work, because the records are spread over several invoices and they rarely agree with each other.

We offer a no-obligation assessment that produces the inventory, reads the contracts alongside it, and models each option against what you are already committed to. The wider sequence of a platform move is set out in our note on the UCaaS transformation journey.