Give callers a way to reach your voice service. There are three routes to an address, and they are not equally finished — so lead with the one that is production-ready today:
RouteWhat you getStatus
Per-tenant SIP subdomainA ready-to-use address <orgId>.sip.telequick.dev provisioned when your workspace is created — no carrier, no purchase.Shipped
Bring your own numbers (DID)Your existing carrier DIDs, pointed at a SIP trunk and imported into the number registry.Shipped
Buy from the managed catalogSearch-and-purchase a new DID from an upstream carrier through TeleQuick.Preview / stub
Whichever route you take, the last step is the same: assign the address to a trunk, an agent, or a routing flow so inbound calls land somewhere. That mapping is what this page is really about.
The managed “buy a number” catalog is a stub today — search returns a small demo set (India-only, a placeholder catalog provider), pending live Twilio / Telnyx / Bandwidth integration. The allocation registry and the inbound routing that reads it are real, so a number you import by hand behaves exactly like a purchased one will. If you need a live number now, bring your own DID (below).

​
Your tenant already has an address

Every workspace is provisioned with a per-tenant SIP subdomain at onboarding. Org bootstrap creates CNAMEs for <orgId>.sip.telequick.dev (SIP), <orgId>.webrtc.telequick.dev (browser media), and the bare <orgId>.telequick.dev, all pointing at the voice engine. When a call arrives, the engine reads the leftmost DNS label of the inbound SIP request as the tenant id — so multiple tenants share the engine with no cross-tenant extension collisions. You don’t provision this; it exists the moment your org does. It’s the SIP realm your agent endpoints register against and the host a carrier or upstream SBC points its trunk at. See SIP trunking for the trunk side and PBX & ACD for registering human-agent phones under that realm.
A per-tenant SIP subdomain is enough to place and receive SIP calls internally (softphones, deskphones, on-net dialing). You only need a DID — a real E.164 phone number — when you want the public phone network to reach you.

​
Bring your own numbers (DID)

The production path. You already own DIDs from a carrier; you keep them and point them at TeleQuick. Two moves: get the carrier delivering calls to a trunk, then register the number so the engine knows where to route it.
1

Create a trunk for the carrier

Configure a SIP trunk that terminates your carrier (or SBC). Match it by the carrier’s source IP or by the DID it delivers, and set its inbound rule so calls hand off to an agent or flow rather than being rejected. See Trunks for every field and SIP trunking for the addressing and codec setup.
2

Point the carrier at your SIP subdomain

In your carrier’s dashboard, route the DID’s inbound calls to <orgId>.sip.telequick.dev (or the trunk’s advertised SIP IP). Trunk INVITEs are matched by source IP and bypass the registrar ACL.
3

Import the number into the registry

Register the E.164 number in the allocation registry with its provider set to manual (a BYO import) and a trunk_id so inbound calls on it resolve to that trunk. This is the record inbound routing reads on every call.
4

Verify inbound routing

Place a test call to the DID. The engine resolves the trunk by DID first, then by source IP, and follows the trunk’s inbound rule. Confirm the call lands where you assigned it (see Inbound calls).
A registry entry is one row keyed uniquely per (org, e164):
​
e164
string
required
The number in E.164 form, e.g. +15551234567. Unique within your org.
​
provider
'twilio' | 'telnyx' | 'manual'
Where the number came from. manual = a bring-your-own DID you imported; twilio / telnyx are set by the managed catalog when that ships.
​
number_type
string
Classification (e.g. local, toll-free, mobile) — carried for reporting and compliance, not routing.
​
country
string
ISO country of the number.
​
trunk_id
string
The trunk this number routes over. Set for BYO DIDs so inbound calls resolve to your carrier trunk.
​
agent_id
string
Optional. Bind the number directly to an AI agent — a call to it starts that agent with no intermediate flow.
​
vdn_id
string
Optional. Route the number into a VDN (a routing flow / IVR entry point) instead of straight to an agent. Exactly one of agent_id / vdn_id is the usual choice.
​
status
string
Lifecycle state of the allocation (active, released, …).

​
Buy from the managed catalog

The eventual one-click path: search available numbers by country and type, purchase, and the DID is provisioned onto a managed trunk automatically.
This is a preview. The number-search endpoint (telephony.searchAvailableNumbers) is wired end to end, but the catalog behind it is a stub — it returns a fixed demo set (India-only, a placeholder catalog provider) rather than live carrier inventory. Treat search results as sample data. The purchase-and-provision leg against a real carrier (Twilio / Telnyx / Bandwidth) is not shipped yet. Everything downstream of allocation — the registry row, assignment, and inbound routing — is real and identical to the BYO path, so your integration code won’t change when live inventory lands.
When the catalog goes live it will populate the same registry record shown above (with provider set to the upstream carrier), so build against that shape now.

​
Assign a number

Assignment is what makes a number do something. Every allocated number points at exactly one destination; pick the one that matches how much routing logic you want in front of the caller:
Set trunk_id. Inbound calls on the number are delivered over that trunk and follow the trunk’s own inbound rule. This is the baseline for a BYO DID — the number is reachable and lands on your carrier edge, and the trunk decides the rest.
The registry is default-private control-plane state: manage it from the voice console at agent.telequick.dev (or the control-plane API), not from the data-plane Voice SDK. The SDK’s Voice client places and controls calls; it does not buy or assign numbers. Assignments are hydrated to the engine so a change takes effect on the next inbound call without a redeploy.
One number, one primary destination. Setting both agent_id and vdn_id is ambiguous — choose the level of indirection you want (straight-to-agent vs. flow-first) and set one. trunk_id governs how the call arrives; agent_id / vdn_id govern what happens once it does.

​
Honest status

  • Per-tenant SIP subdomain provisioning — shipped. Created automatically at org onboarding; the engine routes by the leftmost DNS label.
  • Bring-your-own DID — shipped. Import into the allocation registry with provider: "manual" and a trunk_id; inbound routing reads it live.
  • Assign to trunk / agent / flow — shipped. The registry, and the inbound resolution that consumes it, are real.
  • Managed buy-a-number catalog — preview. Search works against a stub (India-only demo inventory); live carrier purchase-and-provision is not yet built. Don’t ship a self-serve “buy a number” flow on it.

SIP Trunking

Bring your own carrier or a managed trunk — addressing and codecs.

Trunks (control plane)

Every trunk field, including inbound rules and AI handoff.

Inbound Calls

How a call on your number is received and routed.

PBX & ACD

Front a number with a VDN, IVR, and skill-queue routing.

Build voice agents

Bind a number straight to an AI agent.

Telephony overview

How the phone network bridges into the voice stack.