Freeze one number, one call and the effective configuration
Record the telephone number, timestamp and timezone, provider or PBX call identifier, enabled voice mode, ordered routes, endpoints and weights, Final Destination URI or call-forward setting, relevant option-order status, first provider attempt, response or timeout, any next attempt, PBX route, caller result and media result. Redact credentials, tokens, personal numbers and packet payloads.
Classify the first missing boundary: number voice mode, effective route configuration, endpoint selection, provider attempt, route advancement, number-option completion, PBX edge receipt, DID normalization, inbound-rule match, answer or media. Do not change all of them in one test.
Prove the number is using SIP Trunking and the intended routes
Confirm that SIP Trunking, rather than Voice API traffic, is enabled for the number. Export or capture the effective route priorities, each endpoint type and target, and each weight. A saved screen or valid outbound realm does not prove that the failed number has the same inbound configuration.
Keep priorities and weights separate: priorities order route groups, while weights distribute traffic among endpoints in one route. Do not promote a weighted endpoint into a standby sequence or infer that a secondary route was eligible merely because it exists.
Follow the first attempt without inventing a trigger table
Retain the first target, provider source, request, response or transport error, elapsed time and any later attempt. The current Build page says a secondary or tertiary route can act as failover when the first endpoint fails, but the reviewed public documentation does not supply a complete response-code list, timer schedule, retry count or restoration rule.
Escalate an unexplained no-advance or unexpected advance with the exact call identifier and timestamps. Do not copy another provider’s retry policy, rewrite a deliberate busy or rejection response to force failover, or claim that a new-call retry preserves an established call.
Verify final destination and asynchronous option state separately
If a Final Destination URI or call-forward option is expected, retain the option-order identifier, create result, later processing status, warnings, errors and effective value for the number. The documented number-option create response can be RECEIVED; later evidence can be COMPLETE. HTTP acceptance therefore does not establish completion.
Treat this number-level option as a separate downstream control from the Build route groups. Confirm which route attempts occurred before the final destination and which system owns any forwarded PSTN or SIP leg.
Trace the delivered request through PBX and media evidence
If the INVITE reaches the edge, preserve its source, Request-URI, called-number form, transport, first PBX object or context, normalized DID, first matching inbound rule, destination and final response. Provider delivery does not prove the intended extension, queue, menu or voicemail handled the call.
After answer, retain SDP offer and answer, chosen codec, RTP endpoints, NAT or firewall decisions, packet flow in both directions and an authorized listening result. Do not weaken signaling or media security, rotate outbound realm credentials or change number routing to repair a demonstrated PBX match, codec, NAT or RTP fault.
Correct the earliest mismatch and retest primary, failure and restoration
Change only the demonstrated owner: number voice mode, route priority, endpoint target or weight, completed number option, edge allowlist, 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 later route or final destination and return to primary. Record 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 establish established-call survival, account capacity, universal availability, emergency behavior or future compatibility. No Bandwidth account, route, PBX, network path, failover event 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.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.