Current Location ：
DNS SRV and SIP Failover: Routing Calls When the Primary Is Down
Failover designs are usually drawn as boxes and arrows: primary path, secondary path, and a line between them. The line is almost always DNS, and it is almost never reviewed with the same care as the boxes. A carrier change, a TTL set to an hour, or a resolver that caches aggressively can turn a well-designed failover into a twenty-minute outage. This article explains how SRV records express preference, what caching does to recovery time, and what to test before you depend on any of it.
What SRV Records Express
An SRV record does three things a simple address record cannot: it names a service and transport, it gives a priority, and it gives a weight. Priority decides order, lower values first. Weight distributes load among records sharing a priority, which is how a provider spreads traffic across equivalent servers. For voice, this means a carrier can advertise a primary and a standby, or several equals, and the platform can follow that intent without custom configuration on each side.
| Field | Meaning | Practical consequence |
|---|---|---|
| Priority | Order of preference, lower first | Failover sequence after a failure is detected |
| Weight | Relative share among equal priorities | Load spreading; zero weight is often a backup |
| Port | Service port for the target | Must match what the carrier actually listens on |
| Target | Hostname of the server | Requires a matching address record to resolve |
| TTL | How long resolvers may cache the answer | Sets the floor on recovery time |
Caching Sets Your Recovery Floor
If a record has a one hour time to live, a resolver that has just fetched it will keep using it for up to an hour even if the target fails. Lowering the TTL to sixty seconds reduces that exposure but increases query volume, and some resolvers ignore short TTLs anyway. The practical answer is to understand the caching chain: the platform, the local resolver, and any intermediate caching layer all hold copies. Failover that depends on DNS changing quickly should be tested end to end, not assumed.
- Lower the TTL before a planned migration, and restore it afterwards
- Test with the resolver the platform actually uses, not with a public one on your laptop
- Check that every SRV target resolves to a reachable address
- Remember that failover still requires the platform to notice failure and retry
- Keep a static fallback path documented for when DNS itself is unavailable
Detection Is Separate From Resolution
DNS tells the platform where it may send a call. Whether it moves depends on detection: an unreachable target has to be identified, and the call retried on the next priority. Some platforms detect failure on the next call attempt and move immediately; others wait for a timeout that can exceed the caller's patience. The combination of a short TTL and slow detection is a failover design that looks correct on paper and produces abandoned calls in practice.
Test the Failure, Not the Configuration
The only meaningful test is to make the primary path fail during a live call and measure what happens: whether the call survives, whether the next call uses the secondary, and how long the interval is. Reading the configuration confirms intent; causing the failure confirms behaviour. The two are frequently different.
Redstone Approach
Redstone voice platforms support DNS-based trunk resolution where the carrier publishes suitable records, and our deployment process includes a deliberate failover test with measured recovery time rather than a configuration review. Where a carrier does not publish reliable records, we configure explicit primary and secondary paths and document the failover behaviour so that expectations match reality.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
