How DID number routing actually works

What “routing” actually refers to

When routing is working, it is invisible. Someone dials the right extension, the audio is good, the keypad presses register, and no one thinks about the machinery under the hood. It only becomes visible when one of those assumptions breaks down — and the instinct is to call it a routing problem, as if routing were a single hop that either fired or didn’t.

It isn’t. An inbound call has four distinct stages between the moment it hits a DID and the moment it ends on an endpoint: carrier-side ingress, number translation, the routing logic your configuration applies, and endpoint selection. Each is a layer with its own state, its own failure surface, its own diagnostic signature. The symptom you see at the endpoint is rarely born at the endpoint, so “routing problem” is a useless diagnosis. Walk the path once, and all four of the failure modes below drop cleanly onto the layer they originated from. Put the symptom on the right layer, and debugging stops being a guessing game.

The routing decision flow

Follow a single inbound call end to end.

Carrier-side ingress

The call comes into the carrier from the PSTN or an upstream interconnect, bound for one of your DID numbers. At this point it is SIP signalling on the carrier’s edge: the dialled number is carried in the request, and the caller’s identity is carried as CLI. But you haven’t received anything yet — the carrier has just picked up the call and worked out which customer owns the number.

Number translation

Before the call can be handed to your platform, the number almost always has to be rewritten. What arrives from the PSTN side is typically full E.164; the format your PBX expects on the trunk may be local, national, or a stripped extension. This is where prefix manipulation lives: strip a country code, add a leading zero, remove a trunk-access digit, map a block of DIDs onto a range of internal extensions. DDI manipulation — adding and removing prefixes, converting E.164 to local and back — happens here, on the boundary between the carrier and you. It is mechanical and unglamorous, which is exactly why it is the layer that breaks most often at provisioning time.

Routing logic applied

With the number in a usable form, the configured logic decides where the call goes. This is what people mean when they talk about “routing,” and it is the only one of the four stages that is genuinely a policy decision rather than a mechanical transform. Some of this logic runs on the carrier side, before the call ever reaches you; some runs on your PBX after it arrives. The split matters for debugging, so it is worth being explicit about which lives where — see the next section. A provider that handles call routing does most of the carrier-side logic for you. The PBX-side logic is yours to configure.

Endpoint selection

Finally, the call terminates: a specific extension, a queue, a ring group, an IVR, or an external forward. Signalling completes, the media path negotiates, and — if every layer behaved — the call connects with two-way audio. Endpoint selection is the visible end of the path, which is precisely why faults that originated three layers upstream get blamed on it.

Types of routing logic

Routing logic divides naturally by where it executes. Carrier-side logic operates on the call before it reaches your infrastructure. Once the trunk has handed the call off, PBX-side logic takes over. Knowing which side owns a given behaviour is half of knowing where to look when it misbehaves — and it is the first line any managed call-routing setup draws.

Carrier-side

• Geographic routing: calls are directed by origin or by the dialled number’s region, so a number presents locally while terminating wherever the business actually answers.
• Failover (primary → secondary): if the primary route or destination is unreachable, the call shifts to a defined backup rather than failing outright. This is route-level resilience, decided before the call commits to your platform.
• Time-based routing: business-hours traffic goes one way, after-hours another, on a schedule evaluated at the carrier edge.

Number translation itself — E.164 ↔ local conversion, prefix add and remove — also lives carrier-side, as covered above. It precedes every logic decision, since the logic operates on the translated number.

PBX-side

Once the call is delivered over the trunk, your platform takes over. This is where PBX integration determines behaviour:

• DNIS-based routing: different DIDs map to different endpoints, so the dialled number itself selects the destination (sales line, support line, campaign number) without any caller interaction.
• Hunt groups: a single inbound call is offered to a set of extensions sequentially (try A, then B, then C), in round-robin (distribute evenly to balance load), or simultaneously (ring all, first to answer wins).
• Skill-based routing: the call is matched to an agent or group by attribute — language, product, tier — rather than by a flat queue order.

The carrier-side / PBX-side line is not academic. When a time-based rule misfires, the carrier configuration owns it; when a hunt group rings the wrong people, the PBX owns it. Misattributing the side is how an afternoon disappears into the wrong config screen.

Failure modes: where the invisible becomes obvious

Each of the four failures below originates at a specific layer of the flow. The discipline is to name the layer first, because the layer dictates the diagnostic.

Number-plan mismatch

The translation layer

The carrier sends the number one way and the PBX wants it another: an extra country-code prefix the dial plan doesn’t remove, a missing leading zero, a national-format number arriving where the trunk was set up for E.164. The symptom is calls that don’t reach a destination or reach the wrong one, while the signalling is otherwise fine.

It is a translation-layer issue: nothing is faulty about the call, it just doesn’t match the pattern the next layer is searching for. To fix it, check the number the PBX actually receives digit by digit against the pattern its incoming rules expect, and reconcile the prefix manipulation on one side or the other. This is a configuration mismatch, not a malfunction, which is why it shows up during setup rather than in steady-state operation.

One-way audio

The media layer

Here signalling succeeds and media doesn’t. The call connects, both parties think they’re talking, but audio flows in only one direction. SIP completed cleanly — INVITE, 200 OK, ACK all present per RFC 3261 — while the RTP stream arrives at only one endpoint. Because signalling and media take separate paths, a working call setup tells you nothing about whether the audio path is open.

This is the media layer, and the usual cause is NAT or a firewall mishandling the media path. A device behind NAT advertises a private address in its SDP, the far end dutifully sends RTP to an unroutable destination, and the audio dies in that direction while the reverse path — toward the public-facing side — works fine. Symmetric NAT makes it worse: the external port mapping the far end was told to use no longer matches the port the device is actually receiving on.

Trunk authentication failure

The auth layer

Most common at first setup. The PBX can’t register the trunk, or the carrier rejects calls on it, because credentials don’t line up: a wrong SIP username or password, an IP not on the permitted list where IP-based authentication is in use, a registration pointed at the wrong host, or a mismatch between registration-based and IP-based expectations on the two ends. The symptom is a trunk that shows unregistered, or calls refused before any routing logic gets a chance to run.

This is the auth layer, and it sits logically before routing. A call on an unauthenticated trunk never reaches the translation or logic stages, so symptoms that look like “routing isn’t working” are often the trunk never having come up at all. How the SIP trunk authenticates — registration versus IP — has to match on both ends before anything downstream is worth checking. Check registration state first; an unregistered trunk explains every downstream symptom at once and is the cheapest thing to rule out.

DTMF transmission failure

The media / negotiation layer

The call connects with clean two-way audio, but keypad presses don’t register: IVR menus ignore input, conference PINs fail, callers “press 1” into a void. This is a DTMF-mode mismatch between the two ends, and it lives at the media-negotiation layer because it depends on how digits are carried, not on whether the call routed. The three modes are out-of-band telephone-events in RTP (commonly still called “RFC 2833,” though it was obsoleted by RFC 4733), SIP INFO messages in the signalling channel, and in-band tones inside the audio itself.

When the two ends disagree — one sending out-of-band telephone-events, the other listening for SIP INFO — the digits simply vanish. In-band fails differently: a low-bitrate codec such as G.729 compresses the audio aggressively enough to distort the tones, so digits that survive on G.711 break the moment the path transcodes. The fix is to align the DTMF mode on both ends, and where in-band is unavoidable, to pin a codec that preserves tone integrity. The reason this masquerades as a routing fault is that the call clearly connected, so the keypad failure feels like a destination problem when it is a negotiation problem.

A debugging approach: localize to a layer

The failure list becomes a method the moment you stop guessing and start localizing. Almost every voice fault resolves to one of four layers — auth, translation, signalling, or media — and the checks run cheapest-first, which also happens to be earliest-in-the-path first.

Start with auth, because it costs nothing to check and explains the most. Is the trunk registered, or is the IP authorized? An unregistered trunk accounts for every downstream symptom at once — there is no sense tracing a call that never had a trunk to ride on.

If the trunk is up, trace the SIP. Did the INVITE arrive, and did the exchange complete to 200 OK and ACK? Signalling that never completes puts the fault in routing logic or translation, not media. Signalling that completes cleanly exonerates itself: whatever is wrong is downstream, and you have just halved the search space.

From there the call either landed wrong or connected badly, and the two split clean. Landed in the wrong place, or nowhere, on healthy signalling? That is translation — line up the digits the PBX received against the pattern its rules expect, and the mismatch is usually obvious once both are in front of you. Connected fine but the audio or the keypad misbehaves? That is media: capture RTP at both ends, where one-way audio is NAT or a firewall on the silent return path, and missing digits are a DTMF-mode or codec mismatch.

The whole method is just refusing to skip ahead. “The call connected but there’s no audio” is not a routing problem and never was — signalling already cleared it, which puts the answer in the media layer and nowhere else. Naming the layer is most of the fix; the config change after that is usually trivial.

What to ask a managed-routing provider

When you’re handing this path to someone else to operate, the questions worth asking track the same layers:

• Where does number translation happen, and can they show you the exact prefix manipulation applied to a given DID — is it inspectable or opaque? This is the layer that breaks at provisioning.
• How is the media path handled for endpoints behind NAT — SDP rewriting, media relay, or a VPN that removes NAT entirely? One-way audio is the failure you’ll hit most after setup.
• Which logic runs carrier-side versus on your PBX, so you know which side to open when something needs changing?
• What is the failover behaviour, and is it route-level or destination-level?
• How is DTMF carried by default, and is the mode negotiable per trunk?

It is also worth asking how much PBX-side configuration arrives pre-built. VoipTower is one example of a managed-routing provider that ships pre-configured PBX templates, which collapses much of the trunk-authentication and translation setup that otherwise consumes the first day of any deployment. But the answer that actually tells you something is the one to the questions above: can they name the layer a given symptom comes from? That is the line between operating the path and selling numbers into it.