Failover Takes 4 Seconds, Location Doesn't Follow: The SIP Trunk Failover and E911 Location Gate for Callbot Loops

Origination and termination fail over on different clocks

Twilio's own Elastic SIP Trunking documentation treats inbound (origination) and outbound (termination) failover as separate mechanisms. On origination, you assign priority and weight across several SIP URIs; endpoints that share a priority split traffic, and when one drops, the rest absorb its share. Termination works differently: resolving the termination hostname returns several IP addresses spread across edge regions, and the trunk tries each one in turn, skipping any that doesn't answer. Twilio recommends a 4-second timeout for that first attempt, and lets you configure a fallback URI at a different edge — Frankfurt backing up Dublin, for example — for when the primary edge itself is unreachable.

One firewall rule can silently defeat the failover

If the origination endpoint only allowlists the primary edge's IP ranges, the moment traffic shifts to the secondary edge, the firewall drops those packets. Twilio's documentation is explicit that you should open the full signaling and media IP ranges regardless of which edge you've selected — skip that step and the failover configuration looks fine in the console while silently failing the one time it actually has to fire.

The 911 dispatchable-location duty runs on its own clock, not the failover's

The FCC order implementing Section 506 of RAY BAUM'S Act set January 6, 2021 as the deadline for automated dispatchable location on fixed devices, and January 6, 2022 for non-fixed devices where technically feasible. Kari's Law overlaps on systems manufactured or installed after February 16, 2020, requiring direct 911 dialing with no extra prefix plus a notification to a central location such as a front desk. All three dates are already in the past, which means every callbot loop standing up a new SIP trunk today is adding failover on top of an obligation it should already be meeting.

From the dial plan to the 911 call: operating a SIP trunk failover

Planning starts by pinning target numbers into the dial plan document itself. Set the per-endpoint termination timeout at 4 seconds, cap the full detect-to-switch window at 10 seconds end to end, and spread origination across at least two physically separate SBCs with priority and weight.

The first failure pattern is DNS caching. If trunk hardware caches the termination hostname's answer past its TTL, a region outage keeps retrying stale IPs and the switch is delayed. Honoring the record's TTL, instead of hardcoding an IP list into the trunk, is the precondition for recovery here.

The second is a missing location mapping. When the audio region shifts to the secondary edge, the 911 dispatchable location still needs to be registered per line or extension, not per edge. Bind location to the edge and the moment failover fires, the outbound line's location record goes empty — an emergency call lands with no coordinates attached. Location has to be mapped to the line ID and kept independent of whichever edge is currently carrying the call.

The third is the firewall gap from the section above, turned into a signed checklist item rather than left implicit. Without a separate sign-off line covering the secondary edge's IP ranges before launch, a configuration that tests clean will only reveal the gap during a real outage.

For the operating checklist, run a quarterly drill that deliberately kills the primary SBC. Log the trunk ID, when the switch occurred, how long it took, and whether the 911 location lookup succeeded; keep caller numbers as hashes rather than raw digits, and purge them once the retention window closes.

The improvement loop starts by tracking monthly failover counts and average switch time as a trend. When a carrier's SLA changes or the FCC adjusts the non-fixed-device requirement, update the dial plan and timeout values first, so the code and the regulation don't drift apart.

It isn't done until the emergency call survives it

A SIP trunk failover isn't finished just because the call survives — it's finished once the 911 dispatchable location survives the same switch. Pin the 4-second termination timeout and the 10-second end-to-end switch window into the dial plan, map location to the line rather than the edge, and run a quarterly drill to confirm the firewall never blocks the secondary edge, so the emergency call stays connected.

References

Twilio Voice Failover Best Practices — Twilio

911 Dispatchable Location — Federal Communications Commission