Number Porting: What ISPs and Carriers Need to Know

Number porting is the regulatory mechanism that lets a subscriber keep an existing telephone number when changing providers, transport types, or service categories. For ISPs and carriers, it is also one of the most administratively painful workflows in voice operations, and one of the easiest places to lose customers when something goes wrong. Most operators do not appreciate this until their first rejected port.

This article is the operational reference for ISPs, ILECs, CLECs, MSPs, and wholesale carriers who run port-in and port-out activity as a recurring part of voice operations, not a one-time migration event. We cover what Local Number Portability (LNP) actually is, how the dominant regimes work in North America, the United Kingdom, the European Union, and several APAC markets, what the Session Border Controller (SBC) has to do at the routing layer once a number has been ported, the operational pipeline for port-in and port-out, and the failure modes that cause most port disputes.

If you are running a one-time migration off the PSTN onto a VoIP platform, the PSTN replacement migration guide for ISPs is the right starting point. This article is for the team that has to handle ports continuously, after migration is finished. For wider context on the SIP architecture this sits inside, see the SIP trunking and interoperability pillar.

What Number Portability Actually Is

Number portability is a regulatory promise: when a subscriber changes voice provider, the number comes with them. The promise is pro-competition in origin, and it is now a fixture of telecom policy in every market that matters. In the United States, the requirement comes from Section 251 of the Telecommunications Act of 1996 (see the FCC’s overview of Wireless Local Number Portability). In the United Kingdom, it comes from Ofcom’s General Conditions of Entitlement. In the European Union, it is codified in Article 106 of the European Electronic Communications Code. Australia, Brazil, India, and most APAC markets have parallel rules administered by their respective regulators.

Three flavors of portability exist in practice. Provider portability is the common case: the number stays the same, the provider changes. Geographic portability allows the number to move with the subscriber to a new physical location, which NANP supports only within the same rate center but which several EU markets allow more broadly. Service portability lets a number move between service types, such as fixed-to-mobile, and remains rare outside a small number of jurisdictions. For ISPs and carriers, provider portability is the workflow that consumes operational time.

What is portable is the number itself, not the service plan, the voicemail box, the calling features, or the SIP credentials. A subscriber who ports a number from a losing carrier to a gaining carrier is buying a new service that happens to share an identifier with the old one. This distinction is the source of a surprising amount of subscriber confusion and a surprising number of post-port support tickets, which is one reason number porting is treated as an operational discipline rather than a technical task.

How LNP Works in the North American Numbering Plan

NANP covers the United States, Canada, and most Caribbean territories. The central database that makes LNP possible across this footprint is the NPAC, operated by iconectiv on a multi-year contract awarded by NAPM (the NANC committee that selects the LNPA). Every port-eligible number in NANP has an NPAC record that maps the telephone number to an LRN identifying the switch currently serving that number. The LRN is what the network routes to after a port has executed.

The actors

The losing carrier currently serves the number and is obligated by FCC and CRTC rules to cooperate with the port. The gaining carrier takes on the number and is responsible for initiating the LSR, collecting the LOA, validating the CSR, coordinating cut-over, and notifying the subscriber. The NPAC holds the authoritative LRN-to-TN mapping. iconectiv administers NPAC, the LERG, the Service Provider Identifier (SPID) registry, and the Service Provider Code (SPC) token program that ties number authorization records to STIR/SHAKEN attestation.

The flow

A port-in starts when the subscriber signs an LOA at the gaining carrier. The gaining carrier validates the LSR against the CSR pulled from the losing carrier, then submits the LSR through a clearinghouse (NeuStar, iconectiv, TNS, or Bandwidth, depending on the operator’s setup). The losing carrier reviews the LSR, confirms account ownership, and returns an FOC with the agreed cut-over time, typically expressed as a date and a four-hour window. On cut-over, the NPAC record for the ported telephone number is updated to point at the gaining carrier’s LRN. From that moment on, every NANP carrier that performs an LNP dip on this number routes the call to the gaining carrier.

Wholesale vs subscriber ports

For ISPs and carriers, both wholesale and subscriber-level porting matter. A subscriber port involves a single end customer moving from one provider to another and runs through the standard LSR process. A wholesale port covers a block of numbers moving between two upstream carriers, often as part of an acquisition or a wholesale supplier change, and is administered in batch through the same NPAC mechanisms. A small ISP terminating service through a wholesale partner may experience both at once: their upstream changes carriers (a wholesale port the ISP did not request), and a subscriber simultaneously chooses to leave (a subscriber port-out the ISP did request). Coordinating the two is operationally tricky and is one of the failure modes covered later in this article.

How LNP Works Outside North America

Every regulated voice market has some form of number portability, but the administrative model and the operational rhythm differ. Three patterns dominate.

United Kingdom (Ofcom)

The UK historically operated a donor-led model, where the losing carrier (donor) controlled the port and called were always routed first to the donor before being onward-routed. Ofcom is phasing in a recipient-led model that mirrors the NANP architecture, with a central authoritative database and direct routing to the gaining carrier. Port turnaround under the recipient-led model is one working day for residential subscribers, with same-day execution achievable for business customers in some scenarios. The UK uses XML-based porting messages exchanged through Openreach and the major operators’ systems.

European Union (EECC)

Under Article 106 of the EECC, all member states are required to implement portability across providers within one working day, free of charge to the subscriber. Each member state administers its own central database (the OPTA in the Netherlands, the BIPT registry in Belgium, the BNetzA system in Germany, and so on), but the operational concepts are aligned: the gaining carrier initiates, the losing carrier validates, a central registry records the change, and routing is updated. Many EU markets use ENUM (E.164 to URI mapping) as the routing lookup mechanism for ported numbers, which means the SBC’s job at the routing layer is slightly different from a NANP LRN dip.

Australia, Brazil, India, and other APAC markets

Australia (ACMA, recipient-led, fast turnaround), Brazil (ANATEL, central NP database), and India (TRAI, regional Mobile Number Portability Operators) each maintain their own central registries and porting workflows. The common pattern across all of them is a central database plus a defined exchange between losing and gaining carriers. Where the SBC’s behavior changes from NANP is in the type of dip performed: an LRN dip against NPAC in NANP, an ENUM lookup in much of the EU, a central NP database query in Brazil, and so on. Each query type is technically a different API call against a different source of truth, but the underlying routing question is the same: who serves this number right now?

Cross-border considerations

Number portability is national by design. A US number cannot be ported to a UK carrier, and vice versa. Carriers operating in multiple countries run separate LNP workflows per jurisdiction. International voice traffic from a ported number is routed using the same egress paths as any other call; the portability change is local to the originating market.

The Routing Mechanics: Where the SBC Comes In

Before number portability existed, every telephone number had a fixed home: the NPA-NXX of the dialed digits told the network exactly which switch served it. Routing was static and lived in the LERG. Portability broke that assumption. After a port, the called number’s NPA-NXX still indicates the original rate center, but the actual serving switch is somewhere else entirely. The network has to discover the new location on each call, which is where the SBC comes in.

The LNP dip

An LNP dip is a query against the portability database to retrieve the current routing identifier for a number. In NANP, the dip returns the LRN. In EU markets using ENUM, the dip returns a URI that the call should be routed to. In each case, the SBC takes the called number from the inbound INVITE, queries the appropriate database (or a cached copy), and rewrites the routing decision based on the result.

The dip can happen against the live national database, against a periodically refreshed local mirror, or against a third-party provider that resells dip access (TransNexus, Neustar, iconectiv, Bandwidth, TNS). For ISPs and smaller carriers, third-party dip-as-a-service is the common pattern. Per-dip cost varies by provider and volume, typically a fraction of a cent, but at carrier scale the costs add up, which is why dip caching with sensible TTLs is operationally important.

NPDI flag handling

The NPDI flag in SIP signaling indicates that an upstream node has already performed an LNP dip for this call. When the SBC sees NPDI=yes on an inbound INVITE, the correct behavior is to honor the upstream result and skip the dip. Re-dipping a number that has already been resolved upstream wastes time, costs money, and can cause routing inconsistencies if the upstream and downstream databases disagree. A correctly configured SBC always checks for NPDI before initiating a dip, and always sets NPDI on outbound INVITEs after performing its own dip so downstream nodes can do the same.

Where it fits in the routing pipeline

The LNP dip typically runs early in the call setup, after basic SIP validation and before the routing decision. The dip result either confirms the original NPA-NXX-based route (the number is not ported, or it has been ported back to its original switch) or rewrites the route to the new serving carrier. ProSBC implements LNP dips through its API modules: the routing script invokes an HTTP or SIP query against the LNP provider, parses the response, and updates the routing decision before the call advances. For a full architectural walkthrough of how external lookups slot into SBC call processing, see the SBC REST API call routing integration guide.

Why the SBC is the right place for this

Two reasons. First, the SBC is the natural ingress point: it already terminates SIP, anchors media, applies SIP header manipulation rules, and is the first hop where call routing logic is applied. Adding an LNP dip at this layer keeps routing decisions in one place. Second, the B2BUA architecture gives the SBC complete control over the outbound INVITE, including the ability to insert NPDI, rewrite the Request-URI, set the LRN as a routing number, and pass the original called number untouched for downstream billing.

The Operational Pipeline: Port-In and Port-Out

The technical layer is the easier half. The administrative pipeline is where most ports succeed or fail, and it is also where ISPs without dedicated voice operations staff feel the strain. The pipeline has two mirror-image flows.

Port-in (you are the gaining carrier)

Receive the signed LOA from the subscriber. Validate the request against the CSR pulled from the losing carrier; mismatched billing name or service address is the most common reason for an LSR rejection. Submit the LSR through your clearinghouse with the desired cut-over date. Track the FOC return and resolve any rejection codes the losing carrier raises (typo in the account number, address mismatch, frozen account, pending balance). Once the FOC is in hand, provision the routing on your SBC, confirm dial plan coverage, set up voicemail and any service features the subscriber is expecting, and notify the subscriber of the cut-over time. On cut-over, verify that inbound calls reach the new platform and that outbound caller-ID presents correctly.

Port-out (you are the losing carrier)

Receive the LSR from the gaining carrier. Validate it against your CSR and respond within the regulator’s mandated SLA: FCC rules require simple ports to complete within one business day; complex business ports take longer. Issue the FOC with the agreed cut-over time, or reject the LSR with a specific code if the documentation does not match. Coordinate internally to ensure billing closes the line on cut-over, to retain CDRs for the required regulatory window, and to release the number cleanly from your SBC routing tables.

Who runs which step

In a well-staffed carrier, the pipeline is split: voice operations owns the LSR/FOC exchange, billing owns the account close-out, SBC operations owns the routing change, and customer success owns subscriber communication. In a smaller ISP, the same person often runs three or four of these steps, which is where mistakes creep in. Two practices distinguish the operators who run a clean port pipeline. The first is treating the port as a coordinated workflow with explicit hand-offs and a single owner per port: a tracking ticket, a checklist, and a sign-off on each step. The second is automating the routing change so that on cut-over hour, the SBC routing update happens through an API call rather than a manual configuration push at 2 a.m. by whoever is on call.

Common Failure Modes

Most port failures are administrative, not technical. The pattern across thousands of port disputes is that roughly four out of five trace back to data mismatches, missed deadlines, or unclear ownership, with the technical routing layer accounting for the remainder. The failure modes below are the ones operators see most often.

CSR mismatch causing FOC rejection

The subscriber’s billing name on the LSR has to match the losing carrier’s CSR exactly. “John A. Smith” and “John Smith” can be treated as different identities. The same applies to addresses, account numbers, and authorized contacts. A single mismatched character is enough to reject the LSR, which costs the gaining carrier a cycle of LOA re-collection and re-submission. The fix is process: the gaining carrier pulls the CSR before submitting the LSR, compares it line-by-line to the LOA, and resolves any mismatch with the subscriber before sending anything to the losing carrier.

Missed cut-over window

The FOC sets a specific cut-over time. If the gaining carrier does not have routing provisioned on the SBC at that moment, inbound calls to the ported number fail until the routing is in place. Subscribers tolerate a one-time port; they do not tolerate hours of dropped inbound. The fix is to provision SBC routing in advance and tie the activation to the FOC time through the SBC’s API, so the routing change is event-driven rather than dependent on a human at a keyboard.

Snapback (port reversal)

The losing carrier can reverse a port within a defined window, typically 30 days in NANP, in cases of fraudulent port-out or in response to a subscriber dispute. The gaining carrier ends up with a stranded record: the number is back at the losing carrier, but local routing tables, CDR archives, and billing ledgers still reference the gaining carrier. Snapback handling is a process problem: a regular reconciliation between SBC routing tables and the authoritative NPAC mapping catches stranded records before they cause routing failures.

LRN dip failures

If the SBC fails to perform the LNP dip (provider timeout, network error, expired API credentials, cache miss with no fallback), routing falls back to NPA-NXX-based logic and the call is delivered to the original rate center. For ported numbers, that is the wrong destination. The fix is dip redundancy: configure primary and secondary LNP providers on the SBC, set a tight timeout (typically 500 to 2,500 ms), log every dip failure to CDRs for monitoring, and define a clear fallback policy when both providers fail. Letting calls fall through to NPA-NXX routing is acceptable in some carrier configurations and unacceptable in others; the policy has to be set explicitly.

Inter-LATA and intra-LATA disputes

Smaller ILECs occasionally resist intra-LATA ports, citing tariff or regulatory grounds that are usually procedural rather than substantive. The resolution path is administrative escalation through the clearinghouse and, in some cases, the FCC. The most effective preventive measure is keeping LSR documentation precise and complete, which removes the procedural grounds for resistance.

Voicemail and feature loss

Voicemail messages, calling features, and per-number customizations are platform-specific. They do not port. Subscribers reasonably expect that everything they had before the port will be there after the port, and they call support when it is not. Setting expectations during the LOA collection step is the only durable fix, alongside a feature-checklist on cut-over to make sure the new platform is provisioned for the same calling features the subscriber had on the old one.

DID porting versus trunk porting

When a subscriber has a trunk with many DIDs, each DID is individually ported through its own LSR. Trying to port a thousand-DID trunk as a single record can lead to partial completions, where some DIDs land on the gaining carrier and others stay with the losing carrier, breaking inbound routing for half the trunk. Wholesale ports use block-port mechanisms specifically to avoid this; subscriber-level ports of large DID inventories require coordinated batching.

STIR/SHAKEN and the Porting Paper Trail

In NANP, porting documentation is no longer a purely operational artifact. Under the FCC’s framework for caller authentication, A-level attestation requires the originating service provider to have a direct, verified relationship with the calling party and accurate records of the number-to-customer assignment. The LOA, the CSR, and the FOC are the evidence that the provider can lawfully attest at the A level for calls originating from the ported number. Providers that cannot produce clean porting documentation are increasingly being downgraded to B or C attestation by their upstream signing partners, with a measurable impact on call completion rates.

The practical consequence: the porting workflow now feeds directly into the compliance workflow. Keep LOAs in long-term archival, tie them to the NPAC port record, and store them in a way that the compliance team can retrieve on demand. For a deeper walk-through of attestation requirements and the operational path from C-level to A-level signing, see the STIR/SHAKEN A-level attestation guide.

What to Look For in an SBC for LNP Operations

An SBC running in an environment with active porting activity has specific requirements. Most of them follow from the architectural points already covered.

Programmable routing engine. Every LNP regime is different. NANP uses NPAC and LRN dips; the EU uses ENUM in many markets; Brazil and India use central NP databases with their own query semantics. An SBC with a programmable routing layer can implement each query type without waiting on a vendor release cycle. ProSBC’s Ruby routing engine exposes more than 100 call parameters and supports HTTP, Radius, and SIP queries against any external system, which makes it straightforward to add a new LNP provider or a new query format.

NPDI awareness on both ingress and egress. The SBC should detect NPDI on inbound calls and honor the upstream dip result, and it should set NPDI on outbound calls after performing its own dip. Skipping this turns a one-hop dip into a multi-hop dip cascade.

Per-NAP control of LNP behavior. Different trunk groups have different needs. A wholesale carrier-facing NAP may always trust upstream NPDI; a subscriber-facing NAP may always dip locally; a Teams Direct Routing trunk may need a different policy again. The SBC should let the operator set LNP behavior on a per-NAP basis without changing global policy.

Dip redundancy and failure logging. Primary and secondary providers, tight timeouts, CDR logging of dip outcomes, and explicit fallback behavior. LNP dips are not optional, so the failure mode has to be defined in advance and observable after the fact.

API-driven routing changes. Cut-over hour should not depend on a human. The SBC should accept routing updates over its REST API so the porting pipeline can trigger the routing change exactly when the FOC says it should.

CDR detail for port audits. Every dip outcome, every LRN, every NPDI flag, every Request-URI rewrite needs to be visible in the CDR so the operations team can reconstruct the routing of any disputed call.

FAQ