A SIP domain is the hostname that your carrier, PBX, or softphone puts in the request URI when it sends an INVITE to TeleQuick. Every workspace gets one by default, in the form <workspace-id>.sip.<domain>. The SIP domains screen under Admin is where you see that hostname, add your own vanity hostnames alongside it, and check whether each one is verified and accepting traffic. The screen is one implementation rendered in both the contact centre and the voice-AI console, so what you see in either place is the same record set. Reads and writes on this screen go through the control-plane API. The same operations are available to your backend over the control-plane tRPC interface with an API key; the control plane rejects a key that lacks the capability scope for trunk and domain administration. See Authentication.

​
What a SIP domain is and how it differs from a trunk

A domain and a trunk answer two different questions about the same call. A domain is an addressing object. It does not by itself authorise a call, carry codec or CLI policy, or decide where a call lands in the dialplan. A trunk is the authorisation and policy object. A domain with no matching trunk gives you a reachable hostname that rejects everything it receives. Each row on the screen is a single hostname plus its state: whether it is the workspace’s default endpoint or one you added, whether verification has completed, and the transports it currently answers on. Trunks and numbers are managed on their own screens; the domain row links them rather than owning them.

​
How an inbound INVITE is matched to a domain

Matching is done on the leftmost DNS label of the host part of the request URI, not on the full hostname string and not on the To header. For the default endpoint <workspace-id>.sip.<domain>, the leftmost label is the workspace id. An INVITE to sip:+15550001111@acme-4f2b.sip.<domain> resolves to the workspace whose id is acme-4f2b. The remainder of the hostname identifies the TeleQuick SIP edge; it is not tenant-specific. Consequences worth knowing before you configure a carrier:
  • The label must match a domain record exactly. Case is not significant; anything else is.
  • A carrier that rewrites the request URI to its own hostname, or that sends the INVITE to a bare IP address, produces no leftmost label to match. Those INVITEs fall through to source-IP matching on the trunk instead — see the routing order below.
  • A vanity hostname you add is matched the same way, on its own leftmost label. Pointing voice.example.com at the edge does not make example.com match.

​
Adding, verifying, and removing a domain

The default <workspace-id>.sip.<domain> endpoint exists without any setup and cannot be removed. Additional hostnames go through verification so that a workspace cannot claim a hostname it does not control.
  1. Add the hostname on the SIP domains screen. It is created in an unverified state and does not yet match inbound INVITEs.
  2. Publish the DNS record the screen displays for that row, in the zone that owns the hostname. The screen shows the exact name and value to publish; do not guess it, because the value is per-record.
  3. Verify. The screen re-checks DNS and moves the row to verified once the record resolves. Until then the row stays unverified. DNS propagation is outside TeleQuick’s control, so a freshly published record may need another check.
  4. Point your peer at it. Verification only makes the hostname eligible for matching; the call still needs a trunk that authorises the sender.
Removing a domain takes its label out of the match set. Any peer still sending INVITEs to that hostname stops being matched, and its calls are rejected. Remove a domain only after the carrier or PBX has been cut over to another hostname. Removal does not delete trunks or release numbers.

​
Domains, trunks, and numbers: the routing order

An inbound call is resolved in three stages. Each stage can fail independently, which is why a call can be “reaching us” and still be rejected.
  1. Tenant resolution. The leftmost DNS label of the request-URI host is matched against the workspace’s verified domain records. If the INVITE arrived at a bare IP or an unrecognised hostname, this stage produces no tenant and the gateway falls through to stage 2 to identify the sender.
  2. Peer authorisation. The signalling source is matched against the workspace’s trunks — source-IP matching for IP-authenticated trunks, or registration/credential identity for registered peers. The trunk decides whether the INVITE is accepted at all, and supplies the call’s policy. If stage 1 resolved a tenant, the trunk must belong to that tenant; a trunk from a different workspace is not a match.
  3. Number routing. The user part of the request URI is looked up against the numbers (DIDs) provisioned in the workspace to choose the dialplan or agent that handles the call.
Stage 1 narrows the search; stage 2 authorises; stage 3 routes. A vanity domain therefore changes how a peer addresses you, never what the call is allowed to do — that stays on the trunk — and never where the call lands — that stays on the number.

​
Transport and TLS on port 5060

The screen shows which transports each domain answers on. Port 5060 is the standard SIP signalling port and is what a carrier or PBX will use unless you tell it otherwise; it carries unencrypted SIP over UDP or TCP, so the signalling — including the request URI that drives the matching above — is visible on the wire. For encrypted signalling, use the SIP-over-TLS transport and the TLS port shown for the domain on the screen, and configure your peer with the hostname rather than an IP address: TLS certificate validation is done against the hostname, so an IP-addressed peer cannot verify the edge and, as noted above, also defeats leftmost-label matching. Encrypting signalling with TLS does not encrypt media; media encryption is negotiated separately on the trunk.

​
Failure modes: unmatched label, wrong tenant, rejected INVITE

When no CallEvent reaches the SDK at all, the failure is at stage 1 or 2 and you need the SIP exchange itself. Enable HEPv3 capture on the gateway and inspect the INVITE’s request URI and source address directly — see Telemetry.
  • SIP trunking — trunk creation, peer authentication, and the default per-workspace endpoint
  • Authentication — API keys and capability scopes for control-plane calls
  • Telemetry — metrics, CDRs, and SIP packet capture