Twilio Elastic SIP Trunking: origination URI, priority, weight and recovery evidence

Inventory the trunk, numbers and Origination URLs separately

Twilio routes origination calls from associated telephone numbers toward the Origination SIP URLs owned by one Trunk SID. Record the number association, Trunk SID and every OriginationUrl SID, friendly name, sip: URI, enabled state, priority, weight and update time. A number existing in the account does not prove it is associated with the intended trunk, and a created URL does not prove it is enabled or selected.

Elastic SIP Trunking origination is incoming traffic from the PSTN toward the customer PBX or SBC. Keep it distinct from termination, where the customer sends outbound calls to Twilio, and from the separate Twilio SIP Interface registration model.

Treat priority and weight as different routing controls

The lowest numeric priority is the most important. Weight divides requests only among enabled URLs with the same priority; a larger weight receives a larger relative share. Weight is therefore not a standby sequence, and priority is not proof that every request reached or was accepted by the first destination.

The current OriginationUrl API page says the descriptive defaults for priority and weight are 10 while its generated property markers display Default: 0. Configure both values explicitly, read the returned resource and preserve the effective values rather than relying on either default presentation.

Follow the provider attempt and exact SIP result

Twilio documents response-dependent advancement. Its current configuration page says 2xx, 400, 404, 405, 410, 416, 482, 484, 486 and 6xx responses stop failover to the next Origination SIP URI; no SIP response advances after four seconds. Preserve the target URI, selected edge, source and destination addresses, transport, Call-ID, elapsed time and complete response sequence for each attempt.

Do not generalize that published stop list into a complete promise for every transport error, provisional response, timer, retry or restored path. A 486 is an observed final result, not evidence that a later URI should have been tried.

Use disaster recovery only after the SIP destinations are exhausted

Twilio documents a Disaster Recovery URL that is invoked for each new origination request after none of the configured Origination SIP URIs succeeds. The URL must return TwiML and can play a message, collect voicemail, redirect the call or implement other Programmable Voice behavior. Normal Programmable Voice rates apply to that path.

The webhook request, HTTP result, parsed TwiML, subsequent call leg and caller outcome are separate evidence. A configured URL is not proof it was invoked or that the application returned valid instructions, and this new-call workflow does not establish survival of an already connected SIP call.

Keep edge selection and firewall evidence visible

Twilio says origination requests can egress from different edge locations and advises allowing all published signaling and media addresses and ports, because traffic may use another edge during failure. Record the optional edge parameter, current published ranges, observed packet source, firewall decision, SIP destination and RTP endpoints.

A firewall rule that permits one nearby edge is not a complete failover design. Likewise, allowing all documented ranges does not prove number association, URL selection, PBX matching, codec negotiation or two-way decoded audio.

Validate new-call routing without inventing availability

Test the normal destination, same-priority distribution, lower-priority fallback and disaster-recovery application as separate authorized scenarios. Record each new request, selection, response, PBX match, answer, two-way media, release and return to the normal path. Preserve temporary changes and rollback evidence.

Do not infer a service-level result, exact distribution from a tiny sample, active-call survival, price, account capacity or universal compatibility. No Twilio number, trunk, OriginationUrl, PBX, edge, failover event, webhook, media stream or live call was inspected or tested for this guide.

Trace Twilio origination selection into recovery

Use the Twilio origination diagnostic to prove number association, enabled URLs, explicit priority and weight, each SIP result and any disaster-recovery application.