E.164 Phone Number Format: How SBCs Normalize Numbers Across Dialing Plans

A call fails at setup, or the caller ID shows up wrong, and when you pull the trace you find the problem: one side sent +14165551234, another sent 4165551234, and a third sent 0014165551234. Same number, three formats, and the two systems trying to connect the call cannot agree on which one is correct. This is the everyday reality of the E.164 format. The standard defines one canonical way to write an international phone number, but the networks, PBXs, and applications that exchange calls rarely send numbers in that exact shape.

In this article, we’ll walk you through what an E.164 number actually is, why formats diverge in production, and how a Session Border Controller (SBC) normalizes numbers between mismatched dialing plans at the trunk border.

What the E.164 Format Actually Is

E.164 is the international public telecommunication numbering plan, defined by ITU-T Recommendation E.164. It gives every phone number on the global PSTN a single unambiguous representation, which is what makes a number dialed in one country reachable from any other.

An E.164 number has three parts after the leading +. The Country Code (CC) is one to three digits identifying the country or region, such as 1 for the North American Numbering Plan or 44 for the United Kingdom. The National Destination Code (NDC) identifies a carrier, region, or service within that country, roughly what you think of as an area code. The Subscriber Number (SN) is the line itself.

The whole number, country code through subscriber number, is capped at 15 digits. The canonical form carries no spaces, hyphens, or parentheses, so +1 (416) 555-1234 is written +14165551234. A few worked examples show the segmentation: the US number +14165551234 is CC 1, NDC 416, SN 5551234; the UK number +442079460958 is CC 44, NDC 20, SN 79460958; the German number +498912345678 is CC 49, NDC 89, SN 12345678.

One detail trips people up constantly. The leading + is a notation convention meaning “the international prefix goes here.” It is not a digit you dial. On a North American Numbering Plan (NANP) network the + is typically translated to 011; across most of the rest of the world it is translated into 00. The + exists so the written number stays the same no matter which country you dial it from.

Why Phone Number Formats Diverge in the Real World

E.164 is the canonical form, but the systems on a live network almost never hand each other clean E.164 numbers. The formats diverge for predictable reasons, and each one is a place where a call can break.

National format versus international format is the most common split. A PBX configured for a local dialing plan emits a number the way a local subscriber would dial it, often a national number with no country code. A carrier on the other side of the trunk expects full international E.164. Neither is wrong, they just describe the same line differently.

The international prefix is its own source of mismatch. One network sends 00, another sends 011, another sends a bare +, and another sends nothing at all and assumes the far end will add it. Leading zeros add a further wrinkle: many European national numbers carry a trunk 0 that has to be stripped before the country code is prepended, so the UK national number 020 7946 0958 becomes +442079460958, not +4402079460958.

The NANP has a quirk all its own. The digit 1 is simultaneously the country code and the national long-distance prefix, which produces a steady stream of 1-prefixed and un-prefixed variants of the same ten-digit number, all of which are arguably valid depending on context. Add direct inward dialing (DID) blocks, extensions, and short codes that arrive in non-E.164 shapes, and the result is two systems that both speak SIP yet disagree about what a phone number looks like. That disagreement is what breaks routing, caller ID display, return-call, and the number matching that billing systems depend on.

Where the Number Lives in a SIP Message

Before looking at how an SBC fixes the mismatch, it helps to know where the number actually sits. In a SIP INVITE the phone number appears as the user part of several URIs: the Request-URI that drives routing, the To header, the From header commonly used for caller identity, and identity headers such as P-Asserted-Identity. Normalizing “the number” means rewriting that user part consistently across the SIP fields that matter for routing and identity on a given trunk.

This page is about the digit string itself, the numbering plan and how it gets reshaped. The separate question of which header to add, remove, or rewrite, and how a back-to-back user agent controls each leg, is covered in detail in SIP header manipulation with an SBC.

How an SBC Normalizes Numbers Across Dialing Plans

An SBC sits at the border between networks that use different number formats, and one of its core jobs is to normalize the digit string so each side receives the format it expects. Instead of reconfiguring every PBX and renegotiating with every carrier, you normalize once, at the edge. The work comes down to a handful of digit-manipulation operations.

Prefix addition and stripping is the foundation: prepend a country code, add the +, or strip a national trunk 0 so a national number becomes canonical E.164. International prefix translation converts a 011 or 00 arriving from one network into the + another network expects, and back again on the return path. Leading-zero handling strips or retains the national trunk zero according to the rules of the country in question, which is why per-country logic matters. Pattern-based rules match a number shape and rewrite it, so any number arriving as 0 plus nine digits on a given trunk can be reshaped into full E.164 in one rule rather than one entry per number.

The operation that ties these together is scope. Number normalization is applied per trunk, so a carrier-facing trunk can receive strict E.164 while a legacy PBX trunk on the same SBC receives national format, each governed by its own rules without interfering with the other. On ProSBC each trunk is a Network Access Point (NAP), and its configurable, rule-based routing engine applies normalization independently per NAP. For deployments with very large numbering tables, ProSBC routing scripts can drive number and DID lookups through an HTTP API, so a big dial plan lives in an external system rather than in hand-maintained tables on the SBC. TelcoBridges brings more than 20 years of SIP deployment experience, and ProSBC handles up to 1,024 NAPs on a single instance, which is the kind of trunk density where per-NAP normalization stops being a convenience and becomes a requirement.

ENUM and Number Portability in Normalization

Two related lookups depend on having a clean E.164 number, which is part of why normalization comes first. ENUM, defined in RFC 6116, maps an E.164 number through a DNS query into service information such as a routable URI, and that lookup only works if the number is already in canonical E.164 form.

Local number portability (LNP) lookups behave the same way: the ported-number dip uses the canonical E.164 number as its key, so a number that has not been normalized cannot be reliably dipped. The mechanics of how those LNP and MNP lookups are wired into the routing path are a topic of their own; the point for normalization is simply that a canonical E.164 number is the prerequisite both lookups assume.

Frequently Asked Questions

Bringing It Together

E.164 gives the world one canonical way to write a phone number, but the networks exchanging calls send a steady mix of national formats, stray international prefixes, and leading-zero variants. The SBC is the natural place to reconcile them, because it already sits at the border between the systems that disagree. Normalize the digit string once, per trunk, and routing, caller ID, and billing match line up across every vendor on the path.