Freeze one number, one call and every routing identity
Record the owned number, timestamp and timezone, call or trace ID, assigned SIP Connection ID and type, authentication method, selected inbound SIP region, configured route order and method, registered instance when applicable, current DNS answers, provider source address, first request and response or timeout, any next attempt, PBX endpoint and route, caller result and media result. Redact credentials, tokens, authorization fields, personal numbers and packet payloads.
Classify the first missing boundary: number-to-Connection assignment, authentication or registration, regional network selection, provider attempt, route advancement, PBX edge receipt, DID normalization, dialplan match, answer or media. Do not change all of them in one test.
Prove the number assignment and Connection type before the PBX
Confirm that the number targets the intended SIP Connection and that the Connection uses the expected credential, IP or FQDN authentication method. For credential service, retain the current registration Contact, expiry and selected region. For IP or FQDN delivery, retain the configured routes, inbound region and allowed origins.
A successful REGISTER applies to a credential Connection; it does not prove the number assignment, an IP or FQDN route, or PBX dialplan selection. Likewise, a visible route object does not prove that the failed number used the same Connection.
Reconcile DNS, versioned network data and the first provider edge
Capture the current A, SRV or NAPTR result used by the Connection, the selected inbound SIP region, the relevant voice.json version, the observed packet source and the matching firewall decision. Preserve the current Canada source disagreement: voice.json and the network page list 192.76.120.31 and 64.16.250.13, while the failover guide lists 193.108.220.10 and 193.108.220.25.
Treat that mismatch as an escalation and evidence problem, not permission to allow every address or replace DNS with an undocumented constant. Correlate the actual Connection, DNS response, packet and Telnyx confirmation before changing the production allowlist.
Follow route order and determine whether the first result can advance
For IP or FQDN delivery, write the route sequence and whether it is sequential or round robin, then record the first provider attempt, signaling address, destination, response or transport error, elapsed time and any second attempt. Equal round-robin distribution is not active-call load balancing. For credential service, follow the registered-instance path instead of applying the IP-route sequence.
The current failover guide says 408, 480, 503, 504 and transport errors can trigger failover, while 180, 200, 404, 486 and 603 do not trigger failover. A deliberate busy, rejection or not-found response therefore differs from an unreachable route. Preserve the Telnyx-specific response code when present and do not rewrite a response merely to force advancement.
Trace the delivered request through the PBX and media boundary
If an INVITE reaches the edge, preserve its source, Request-URI, To and asserted identity, transport, first PBX object or context, normalized DID, first matching route, destination and final SIP response. Provider delivery does not prove that FreePBX or Asterisk selected the intended extension, queue, menu, voicemail or failover treatment.
After signaling success, compare SDP offers and answers, chosen codec, RTP endpoints, firewall or NAT decisions, packet flow in both directions and an authorized two-way listening result. Do not change Connection assignment or route order to repair a demonstrated certificate, SRTP, codec, NAT or RTP-path fault.
Correct the earliest mismatch and retest primary, failure and restoration
Change only the demonstrated owner: number assignment, Connection authentication, registration binding, inbound region, DNS use, firewall rule, route order or method, PBX context, DID normalization or media path. Preserve the prior state and repeat an authorized new-call test for the normal primary path, the approved failure condition, any next destination and return to primary. Record the provider attempt, PBX match, answer, two-way media, clean release and caller treatment separately.
Remove temporary routes, broad allowlists, packet captures and elevated logging after the test. One successful new call does not prove active-call survival, universal regional availability, exact capacity, emergency behavior or future compatibility. No account, number, Connection, network path, failover event, PBX or live call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Telnyx SIP trunking service objects ↗
- Telnyx authentication methods ↗
- Telnyx failover and retries ↗
- Telnyx SIP response codes ↗
- Telnyx Outbound Voice Profiles ↗
- Telnyx round-robin routing ↗
- Telnyx current SIP network information ↗
- Telnyx machine-readable voice network data ↗
- Telnyx configuration-guide boundary ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.