This explainer is written for telecom, IT and operations teams connecting numbers to a phone system, contact centre or communication platform over a carrier network — not for consumers using a second-line mobile app. A DID (Direct Inward Dialing) number, also called a virtual number, is a public phone number provisioned online and delivered to your infrastructure over SIP (Session Initiation Protocol — the signalling standard that sets up and tears down internet calls). If the concept is new, start with what a DID number is.
The scope here is business and carrier interconnection: your provider delivers inbound calls to equipment you control. Once you understand the call path — how a call placed on the public network arrives at your system as a signalling message — the rest of the setup, from trunk authentication to failover, follows logically. This page walks that path in plain terms and defines each acronym as it appears.
On this page
What happens when someone dials your DID number?
The call travels a short chain from the caller to your system. Someone on the PSTN (Public Switched Telephone Network — the traditional worldwide network of landline and mobile phones) dials your DID. Their originating carrier recognises the number range and passes the call towards the operator that holds it — your provider. At that point the call crosses from the legacy network into internet signalling: the provider builds a SIP INVITE (the SIP request that starts a call, carrying the dialled number and caller ID) and sends it to your endpoint.
Your endpoint is usually a PBX (Private Branch Exchange — the phone system that switches calls inside an organisation) or a softswitch (a software call-routing engine that connects calls between networks). It receives the INVITE, reads the dialled number, and matches it against its routing rules to decide where the call goes next. The audio itself flows once signalling agrees the connection, encoded with a shared codec (the scheme that compresses and decompresses voice, such as G.711 or G.729). In words: PSTN caller, originating carrier, provider network, a SIP INVITE carrying the dialled number, your PBX or softswitch, then the mapped destination.
What is a SIP trunk, and how does it carry a DID?
A SIP trunk is a persistent connection between your phone system and the provider that carries call signalling and media in both directions. It is the pipe those SIP INVITEs arrive through. Rather than provisioning a separate line per number, you point many DIDs at one trunk and the provider delivers every call for those numbers down it.
A single trunk carries multiple calls at the same time, up to its channel limit. A channel is one concurrent call path — one active call in progress. A trunk sized for, say, its busy-hour concurrency can run that many simultaneous calls across all the DIDs pointed at it; when every channel is occupied, additional calls are blocked or diverted until a channel frees. This is why one trunk with an appropriate channel count can serve a large block of numbers: the numbers are just labels the provider delivers, and the channels are the shared capacity that carries them.
Trunk delivery or endpoint registration — what's the difference?
There are two common ways for a provider to know where to send your calls and to trust that it is really you. The first is an IP-authenticated trunk: you give the provider the static public address of your PBX, the provider adds it to an IP whitelist (a list of trusted addresses permitted to exchange traffic), and calls flow to that address without any login. The second is registration: your PBX or device signs in to the provider with a username and secret, periodically refreshing that session so the provider always knows the current address to reach.
| Method | How it authenticates | Best for | What it needs |
|---|---|---|---|
| IP-authenticated trunk | By the network address of your system, matched against an IP whitelist. | Fixed servers and data-centre PBXs with a stable public IP. | A static, reachable IP address the provider can whitelist. |
| Credential registration | By username and secret, refreshed on a recurring registration. | Endpoints or PBXs behind a changing or dynamic address. | Registration credentials and a client that re-registers on schedule. |
Both methods deliver the same SIP INVITEs; they differ only in how your system proves its identity. Fixed infrastructure tends to use IP whitelisting for simplicity, while systems without a stable public address use registration so the provider can follow them.
How does one number map to many extensions?
Routing many people behind one published number is the original purpose of Direct Inward Dialing. When the SIP INVITE arrives, your PBX inspects the dialled number and applies a rule: send it to a specific extension, to a ring group where several phones ring together, to a queue that distributes calls to available agents, or to an IVR menu that lets the caller choose a path. The number is a destination label; the PBX decides what that label means.
Two patterns are common. One number per user gives each person a directly dialable DID that rings only their extension — useful for direct lines. One number to many extensions publishes a single main number that fans out to a team, department or automated menu. Most organisations mix both: a main DID into an IVR or reception queue, plus individual DIDs for people who need a direct line. The trunk carries all of them; the PBX does the mapping.
What keeps calls up if an endpoint fails?
Failover routing keeps calls arriving when your primary endpoint cannot answer. If your PBX does not respond to the SIP INVITE — because it is offline, unreachable or overloaded — the provider tries the next destination you configured. That can be a secondary SIP URI (an alternate address for a backup server), a forward to a backup IP, or a hand-off to a PSTN number such as a mobile so calls still land somewhere staffed.
Registration plays a part here too. Because a registered session carries an expiry and must be refreshed, an endpoint that stops re-registering visibly drops off, and the provider can route to the failover target instead of trying a dead address. With an IP-authenticated trunk you achieve the same resilience by configuring alternate destinations the provider attempts in order. Either way, the goal is that a single failed component does not silence your inbound numbers.