Telnyx SIP trunking: connections, regions and route evidence

Inventory the number, Connection, region, routes and outbound profile separately

Record the account, owned number, assigned SIP Connection ID and type, authentication method, selected inbound SIP region, configured route list and method, registered instance when applicable, Outbound Voice Profile ID, associated Connections, PBX object and operating owner. Protect credentials, tokens, prefixes, authorization fields and customer numbers.

Telnyx documents the SIP Connection as the inbound authentication and handling object, the number assignment as the inbound-routing relationship and the Outbound Voice Profile as a separate outbound-routing, destination, rate and spend-control object. A working Connection does not prove that the number targets it, and an inbound delivery result does not prove outbound-profile attachment or destination permission.

Bind the authentication method and number to the intended Connection

The authentication reference distinguishes credential registration, IP plus token, IP plus tech prefix, IP plus P-Charge-Info, FQDN plus credentials and FQDN plus IP. Credential Connections use registration; an FQDN supplies an inbound destination while outbound authentication still uses credentials or a permitted source address. P-Charge-Info also depends on an E.164 number assigned to the Connection.

Preserve the exact method, effective identifiers, allowed origins, registration Contact and expiry when used, number-to-Connection assignment and first provider transaction. Do not rotate a password to repair an IP route, treat a registered endpoint as proof of number assignment or apply one generic registration template to every Connection type.

Treat regional network addresses as versioned evidence

The current network page says regional SIP FQDNs expose A, SRV and NAPTR records: A resolves the primary address, while SRV and NAPTR can distribute across both regional signaling addresses and indicate transports or ports. It also says inbound registration can use a region, IP or FQDN Connections select an inbound region, and all addresses for that selected region should be allowed. The machine-readable voice.json is the versioned network-data source.

There is a current first-party source disagreement for Canada: the network page and voice.json list 192.76.120.31 and 64.16.250.13, while the failover guide lists 193.108.220.10 and 193.108.220.25. Do not copy either pair into a universal allowlist. Reconcile the selected Connection region, current voice.json, live DNS answers, observed packet source, firewall owner and Telnyx confirmation for the incident date.

Trace route order, method, response and actual advancement

For IP and FQDN Connections, the failover guide describes trying the first signaling address across configured routes before the second address, with sequential or round-robin route ordering. The round-robin guide describes equal incoming distribution rather than active-call load balancing, then trying remaining destinations after a failure. Credential Connections use a separately described registered KSS-instance path with internal failover.

The failover guide lists 408, 480, 503, 504 and transport errors as advancement triggers, while 180, 200, 404, 486 and 603 do not trigger another route. Preserve each destination, source address, request, response or timeout, elapsed time, next attempt and final caller treatment. Call forwarding after exhausted SIP routes is another termination leg, not proof of established-call survival.

Keep outbound controls and provider response evidence outside inbound routing

The Outbound Voice Profile controls associated Connections, destination permissions, service plan, concurrent outbound channel limit, maximum per-minute rate and daily spend limit. The current network page separately publishes an outbound rate of 20 calls per second for the same source IP or SIP username and reserves provider adjustment. These are different controls; neither is proven for a selected account by its public description.

Retain the first provider response and Telnyx-specific code. Current documentation distinguishes, among other cases, absent outbound-profile attachment, concurrent-channel limits, caller-ID validation, missing routes, unregistered users and SRTP mismatch. Use the recorded code as evidence for the matching boundary instead of attributing every 403, 488 or failed call to credentials or failover.

Treat PBX templates, media, availability and commercial state as later boundaries

Telnyx describes its third-party configuration guides as general guidance rather than exact templates because product versions, options and add-ons differ. Record the installed Asterisk, FreePBX, SBC or gateway release, loaded object, inbound context, Request-URI, normalized DID, first matching route, transport, SDP, chosen codec, RTP endpoints and both media directions. Provider delivery does not prove the PBX selected the intended extension, queue, menu or voicemail.

Confirm number inventory, porting, messaging, fax, emergency service, destination eligibility, concurrency, support, price, taxes and regional availability for the selected account and date. A documentation review, one response code or one successful call is not a guarantee of compatibility, quality, availability or failover. No Telnyx service or live call was tested for this guide.

Trace Telnyx inbound routing with current network evidence

Use the Telnyx inbound-route diagnostic to prove number assignment, Connection type, selected region, DNS or voice.json evidence, first provider attempt, response eligibility, PBX route and restoration.