Freeze one inbound call and the effective trunk objects
Record the dialed Twilio number, timestamp and timezone, account and Trunk SID, number association, every OriginationUrl SID, enabled state, explicit priority and weight, SIP URL, optional edge parameter, Disaster Recovery URL and method, provider Call SID where available, SIP Call-ID, every attempt, PBX match, answer, media and caller outcome. Redact credentials, full customer numbers and webhook secrets.
Classify the first disputed boundary: number association, URL state, priority, weight, edge, network receipt, SIP result, next attempt, disaster-recovery invocation, TwiML execution, PBX route, answer or media. Do not edit them together.
Prove the number association and current OriginationUrl resources
Confirm the called number is associated with the intended Elastic SIP Trunk. Export or query the trunk and its OriginationUrl resources, including enabled state and update time. The API requires a sip: address and gives each resource its own SID.
Enter priority and weight explicitly. The current API page presents descriptive defaults of 10 but generated default markers of 0; do not choose between them by assumption. Use the stored and returned values from the actual resource.
Calculate the intended selection before reading one call
Group enabled URLs by priority. The lowest numeric priority group is considered first; within that group, weight controls relative share. A higher weight is not a higher priority, and equal weights do not prove a deterministic round-robin sequence.
For one call, preserve which URL was selected and why it was eligible. For distribution questions, use an authorized sample large enough for the purpose and retain the individual attempts instead of declaring a percentage from a handful of calls.
Trace every SIP attempt and its stopping result
Capture the selected URI, edge, source and destination, transport, elapsed time and response sequence. Twilio currently documents that 2xx, 400, 404, 405, 410, 416, 482, 484, 486 and 6xx stop failover, while no SIP response advances after four seconds. Compare the observed outcome with that published boundary.
If the request never arrives, inspect current Twilio signaling ranges, DNS, NAT and firewall decisions before changing the PBX dialplan. If it arrives, record endpoint identification, Request-URI, first matching route, destination and response before changing another URL.
Distinguish SIP exhaustion from disaster-recovery execution
The Disaster Recovery URL is a later Programmable Voice path after the configured SIP URIs do not succeed. Preserve whether the webhook was invoked, its HTTP response, returned TwiML, validation or execution error, any new call leg, charge owner and caller treatment.
A configured URL is not execution proof. A valid HTTP response is not proof that the TwiML produced the intended caller result. Do not treat the disaster-recovery application as another SIP URI or as evidence that an already established call survived.
Retest normal routing, failover, recovery and media separately
Correct only the first demonstrated owner: number association, URL, enabled state, explicit priority or weight, edge parameter, firewall policy, PBX match or disaster-recovery application. Repeat authorized new-call tests for normal routing, same-priority selection, lower-priority failover, URL exhaustion, TwiML recovery and return to normal.
Record answer, two-way audio, release and caller outcome separately, then remove temporary routes, captures and elevated logging. One successful sequence does not establish universal availability, capacity, price, active-call survival or compatibility. No Twilio account, trunk, route, webhook, PBX, packet, media stream 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.
- Twilio Elastic SIP Trunking configuration ↗
- Twilio OriginationUrl resource ↗
- Twilio Programmable Voice failover best practices ↗
- Twilio Elastic SIP Trunking IP addresses ↗
- Twilio Elastic SIP Trunking troubleshooting ↗
- Twilio Trunk resource ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.