SIP SRV Records Explained: How SIP Engines Decide Where to Send Your INVITE

1. Why hard-coded host:port doesn’t scale

The classic SIP trunk config has the carrier’s hostname and port baked in: sip.example.com:5060. That works fine for one tenant pointing at one box. It breaks the moment the carrier wants to do anything operational with that hostname, and it always wants to:

• Move a region of customers to a new POP without each one editing their PBX.
• Split traffic across multiple POPs for load and redundancy.
• Take a server down for maintenance without a customer notice window.
• Migrate a region from UDP to TLS in a staged rollout.
• Add a hot-standby POP that takes over the instant the primary fails.

Every one of those is impossible if the customer’s PBX has 1.2.3.4:5060 in its trunk config. You either send a support email to every customer (politically and operationally expensive), or you build a complicated NAT-and-anycast layer that pretends the hostname is one box. SRV records solve all of this at the DNS layer where it belongs, and the SIP protocol was designed to look for them.

2. What an SRV record actually is

SRV (defined in RFC 2782) is a DNS record type that returns four fields per result, in this order:

The query name follows the convention _service._proto.domain. For SIP, the service names are _sip (plain) and _sips (over TLS), and the protocols are _udp and _tcp. So a SIP client looking up a server for example.com queries names like _sips._tcp.example.com or _sip._udp.example.com.

A simple, single-target SRV response reads:

$ dig +short SRV _sips._tcp.example.com
10 5 5061 sip-edge.example.com.

One record, four numbers and a hostname. It says: “for SIPS-over-TCP at example.com, connect to sip-edge.example.com on port 5061, at priority 10 and weight 5.” The trailing dot is the FQDN terminator. Underneath that, a separate A/AAAA query on sip-edge.example.com resolves to the actual IP(s) the client will open a socket to.

3. The RFC 3263 resolution chain

SRV records are just the middle stage. RFC 3263 (“Locating SIP Servers”) defines the full three-stage lookup a compliant SIP stack performs when it’s given a URI like sip:[email protected]:

1. NAPTR query on the bare domain example.com. NAPTR (RFC 3403) returns a list of supported transports, each carrying a service tag like SIP+D2T (SIP over TCP), SIP+D2U (SIP over UDP), or SIPS+D2T (SIP over TLS), plus a replacement field that tells the client which SRV name to query next.
2. SRV query on the chosen _service._proto.domain. Returns one or more priority/weight/port/target records.
3. A / AAAA query on each SRV target. Returns the IPv4 / IPv6 addresses the client will actually connect to.

If NAPTR is missing, the client falls back to direct SRV queries in a defined preference order (_sips._tcp → _sip._tcp → _sip._udp). If SRV is also missing, it falls back to a plain A/AAAA query on the URI host with the default port for the chosen transport (5060 for UDP/TCP, 5061 for TLS).

A full trace against an SRV-published carrier looks like this:

$ dig +short NAPTR example.com
50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com.
60 50 "s" "SIP+D2T"  "" _sip._tcp.example.com.
70 50 "s" "SIP+D2U"  "" _sip._udp.example.com.

$ dig +short SRV _sips._tcp.example.com
10 50 5061 pop-us-east-1.example.com.
10 50 5061 pop-us-east-2.example.com.
20 100 5061 pop-us-west-1.example.com.

$ dig +short A pop-us-east-1.example.com
198.51.100.10
198.51.100.11

Three queries, and the client now knows: prefer TLS; try the two co-equal east-coast POPs first, weighted-randomly between them; fall over to the west-coast POP if both are unreachable; and here are the actual IPs to dial.

4. Priority and weight: a worked example

Two numbers, doing two different jobs. The distinction trips up most people on first contact.

Priority is your failover ordering. Lower wins. A client must completely exhaust every record at priority 10 before considering any record at priority 20.

Weight is your load-balancing dial within one priority. Among records sharing a priority, weight is the proportional share of new connections each target should receive. A weight of 0 means “use this only as a last resort within the priority tier”; equal weights mean “split evenly.”

Consider this published zone:

_sips._tcp.example.com.  10 50  5061 pop-us-east-1.example.com.
_sips._tcp.example.com.  10 50  5061 pop-us-east-2.example.com.
_sips._tcp.example.com.  20 100 5061 pop-us-west-1.example.com.

The pattern reads:

• us-east-1 and us-east-2 are co-primary. Both at priority 10, both with weight 50. New connections split roughly 50/50 across them, weighted-random per client.
• us-west-1 is the failover. Priority 20. The client only ever opens a session to it when both east POPs are unreachable.

The carrier can change the topology entirely by editing one DNS zone. Drain east-1 by dropping its weight to 0 (existing sessions finish, new ones go to east-2). Move the failover to a new region by editing the priority-20 target. None of that requires touching a customer config.

5. How SIP applies SRV: INVITE vs REGISTER

Both INVITE and REGISTER follow the same DNS resolution rules from RFC 3263, the lookup is the same. What differs is what happens after first contact.

Outbound INVITE. Every new dialog is, in principle, a fresh resolution. The SIP stack can re-query DNS (subject to its DNS cache and TTLs), so if one target stops answering, the next call lands on a different SRV target without anyone intervening. This is the easy case, the protocol behaves the way the documentation suggests it does.

Inbound via REGISTER. Different story. A registration binds the client to a specific target: the registrar records “to reach sip:[email protected], send to the IP/port the registration arrived on.” That binding lives in the path the client registered through, and inbound routing depends on it. Three consequences:

1. Once registered, the client pins. Most stacks lock onto the SRV target they registered to and keep talking to it for the lifetime of the binding, even if other targets in the SRV set become preferable.
2. A dead registrar kills inbound until the binding expires. If the registrar target goes unreachable and your client doesn’t notice, your inbound calls die at the carrier’s side. The carrier sees the binding is to an unreachable IP and can’t deliver.
3. OPTIONS pings are the fix. Active SIP OPTIONS pings between client and registrar (Asterisk pjsip qualify_frequency, Kamailio dispatcher, etc.) detect a dead target faster than waiting for the binding to expire and re-register. Some clients also re-resolve SRV on each REGISTER refresh; others cache the resolved target for the lifetime of the process.

6. Why SRV beats host:port

Five concrete wins, all of which are operationally invisible to the customer once the SRV records are in place.

1. Failover without customer action. The carrier edits the SRV records; every PBX that honours SRV automatically follows. No support ticket, no maintenance window scheduled with every tenant.
2. Multi-POP load balancing at DNS speed. Weight does the proportional split. Shifting traffic is a DNS edit rather than a load-balancer reconfiguration.
3. Transport negotiation. NAPTR plus SRV lets clients discover that “this provider supports TLS” without you advertising it out-of-band. Phasing out UDP is a NAPTR edit (drop the UDP entry) followed by an SRV cleanup, not a customer-by-customer migration.
4. Zero-downtime maintenance. Drain a POP by lowering its SRV weight to 0, wait for in-flight registrations and calls to drift away, take it down. Bring it back by restoring the weight. Customers see no interruption beyond the normal session churn.
5. Decoupling the user-facing URI from the actual server. Customers configure sip.example.com forever; internally the carrier can move that across datacenters, change ports, swap transports, all without breaking the PBX-side config.

The cost is one extra DNS lookup at session setup, typically under 10 ms, cached aggressively by every resolver in the chain, and dwarfed by the SIP handshake itself. There is essentially no scenario in which hard-coded host:port is the better long-term call.

7. Which SIP engines honour SRV (and which don’t)

Theory is one thing; reality is what your specific PBX does at 2 a.m. on a Sunday. Here’s the rough landscape as of 2026:

If you’re uncertain about your engine, the test is one line: deliberately set the SRV target to an unreachable IP, place a test call, and watch what happens. A SRV-honouring client tries the next target. A non-honouring client times out.

8. SRV records and DIDHub trunks

DIDHub trunks are reached today by the per-tenant SIP hostname provisioned in your dashboard. The hostname is stable; behind it, we run multi-POP edge SBCs with health-checked failover at the network layer and SIP OPTIONS pinging both directions to keep paths live.

Where SRV publication matters most is when you want the failover decision to happen on your side, the PBX choosing between alternate edges rather than relying on the network behind one hostname. Two ways to get there:

• Use multiple trunk hostnames in your PBX’s own failover/dispatcher logic. Asterisk pjsip with multiple contact entries on the AOR; Kamailio with the dispatcher module; OpenSIPS with load_balancer. You then control retry behaviour and ordering directly.
• Rely on SRV when it’s published. When the carrier publishes SRV records under a single customer-facing hostname, your PBX gets the multi-target behaviour for free without any per-customer configuration. This is the cleaner long-term answer; ask DIDHub support for the current per-region hostnames if you want to set up client-side failover today, and we’ll move you to SRV-discovered routing as that rolls out at the apex.

The relevant DIDHub glossary entries that round out the picture: SIP Trunk, SIP Transports (UDP/TCP/TLS/WSS), SIP REGISTER, SIP OPTIONS, and the related blog post on SIP trunk failover.

9. Six common gotchas

1. TLS SNI / certificate mismatch. If your SRV record points sip.example.com at target pop-1.example.com, a strict client may demand that the TLS certificate cover the URI host (sip.example.com), not the connection target. RFC 5922 spells this out; many real-world clients verify against the connection target instead. Two fixes: serve a certificate covering both names (SAN), or use the URI host as the SRV target.
2. NAT port pinning on UDP. NAT routers cache the source port of the last outbound UDP packet for 30–60 seconds. If your client SRV-resolved to port 5060 and the carrier later moves to port 5070, UDP keepalives keep flowing to the old IP:port pair until the binding ages out. TCP and TLS aren’t affected because the connection re-establishes from scratch.
3. REGISTER target pinning. As covered in section 5, REGISTER bindings lock onto a target. Without active OPTIONS pings between PBX and registrar, you only fail over at binding refresh time.
4. NAPTR ignored in the wild. Many SIP clients skip NAPTR entirely and jump straight to SRV. If you want consistent behaviour across stacks, publish SRV records for every transport you actually support, and don’t lean on NAPTR alone to advertise transport preferences.
5. TTL traps. Long SRV TTLs (24 h or more) make failover slow because intermediate resolvers serve stale answers. Carrier-published SIP SRV records typically use 300–600 s TTLs to balance DNS query load against failover responsiveness. If you operate the zone yourself, that’s the right range.
6. Explicit host:port overrides SRV. If you configure a trunk with both a hostname and an explicit port (or worse, an IP address), most SIP stacks treat that as “the operator overrode the discovery” and skip the SRV lookup entirely. Always configure carrier trunks with the bare hostname and leave the port field empty so the SRV chain runs.

10. Bottom line

SRV records are the difference between a static carrier connection and an actual routing system. They let the carrier control failover, weighted load balancing, transport selection, and POP topology from one DNS zone, without ever asking customers to touch a PBX config. Every modern SIP stack worth running honours them; the rule for the PBX side is one line: configure the carrier as a bare hostname, no port, no IP, and let the chain do its job.

If you’re evaluating a SIP carrier, “do you publish SRV records under your customer-facing hostnames?” is a fast, honest signal of operational maturity. The answer should be yes, or a credible roadmap to yes.

More from the blog