# DID — a direct inward dialling number

A DID is a telephone number a carrier allocates to you and points at something you control. The name comes from direct inward dialling — the arrangement that let outside callers reach an extension directly instead of through a switchboard. You rent it rather than own it, and where it rings is configured at the carrier, not in your code.

- **Status:** Reference
- **Audience:** both
- **Channels:** phone
- **In the app:** #/phone
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/did/

## From switchboard bypass to a rented endpoint

The original mechanism solved a scarcity problem. A business with two hundred extensions could not afford two hundred lines, so the exchange delivered a block of numbers over a smaller group of trunks and signalled the dialled digits, letting the private exchange ring the right desk. The caller reached the extension directly; the switchboard operator was bypassed.

The word survived the technology. Today a DID usually means a number you buy from a carrier and attach to an application: a number that terminates on your system rather than on a physical line. The scarcity argument is gone; the addressing idea remains, and it is why a business can hold separate numbers for sales, support and a single campaign without holding separate anything else.

- Numbers are allocated under a national plan. You hold a right to use one; when you release it, it returns to the pool and may later be issued to somebody else.
- Eligibility and documentation vary by country and by number type. Some categories require a local address or a registered entity.
- Portability lets a number move between carriers, which is why the prefix no longer tells you who carries it.
- The number you present on an outbound call is a separate setting from the number you receive on, and presenting one you do not control is prohibited in most places.

## Where routing is actually decided

This is the part that surprises people building their first telephony integration: the decision about where a number rings lives in the carrier's own configuration, not in your application. The carrier holds the number and points it at one of two things — an application whose answer URL it will post to when a call arrives, or a SIP trunk whose origination URI it will send the call to.

For the realtime voice path in Connect, that second form is what is used: the number is linked at the carrier to an inbound trunk whose origination URI is the media platform's SIP host, given as `host:5060` with no `sip:` prefix. A dispatch rule then spawns the voice worker on the room the call lands in.

> **Careful** A carrier posts to the *same* answer URL for a customer calling in and for one of your own SIP endpoints calling out. A handler that never reads the direction field greets an outbound caller as though they were the customer, and the person they dialled never rings. This was a real production defect and it is invisible in every test that only simulates inbound calls.

## Does Connect use DIDs, and how is one represented?

Yes. Every business number in Connect is a DID at a carrier plus a row in `channel_routes` — the same table that answers 'whose endpoint is this and what is it for' for every channel. No separate table exists for phone lines, deliberately.

| Field group | What it decides |
|---|---|
| Provider and assignment | Which carrier holds the number, and who or what it belongs to |
| Inbound and outbound permission | Whether the line may receive, place, or both |
| Hours and routing | When it answers and where a call goes |
| Recording policy and capabilities | What the provider supports, asked rather than assumed |
| Limits and status | Caps, and whether the line is live |

A person's browser line is a row in the same table with the channel set to `softphone`. That is why a colleague's extension and the company's main number are configured in the same place and obey the same permission questions — and why an endpoint that is not attached to the voice application can register successfully and still never place a call.

## Choosing numbers for a business

1. One number per **purpose**, not per person: inbound enquiries, service, transactional calls, promotional calls. Purpose is what selects behaviour downstream, and a number is the cleanest way to carry it.
2. Keep the published number stable. It is on invoices, on signage and in search results, and it is the number people recognise when you call them.
3. Do not reuse a released number for a different purpose. Someone will still be dialling it for the old one.
4. Check what the line is permitted to do before debugging why it will not do it — inbound and outbound permission are separate fields for a reason.

## Questions

### Do I own my business number?

You hold a right to use it under a national numbering plan, and you can usually port it to another carrier. You cannot hold it outside that system, and if you stop paying for it, it eventually returns to the pool. Treat it as a rented identifier that is nonetheless very expensive to change.

### Why does changing where a number rings not require a deployment?

Because the routing decision belongs to the carrier. Pointing a number at a different application or trunk is a change in the carrier's configuration. What lives in Connect is what happens *after* the call arrives — which line it is, what it is for, who may be called and when.

### Can one number serve two purposes?

Technically yes, and it usually creates work rather than saving it. Purpose drives the voice profile and behaviour for the call, so a number doing two jobs has to infer from the conversation what it could have known from the dialled number.

## Related

- [PSTN](https://connectbyjbrh.com/docs/technology/pstn/)
- [Telephony carriers](https://connectbyjbrh.com/docs/technology/carrier/)
- [SIP trunks](https://connectbyjbrh.com/docs/technology/sip-trunk/)
- [Call routing](https://connectbyjbrh.com/docs/technology/call-routing/)
- [Phone and voice in Connect](https://connectbyjbrh.com/docs/phone/)

## What this page is based on

- Source pack: phone and voice — `docs-source/sources/PHONE.md` §1, §2 and §3 (a line is `channel_routes`; `Direction` was never read; the inbound trunk and dispatch rule)
- ITU-T Recommendation E.164 — international numbering (https://www.itu.int/rec/T-REC-E.164/en)
- Connect capability registry (`docs-source/facts.py`) — `softphone`, `inbound_call`
