SIP Fundamentals

SIP SRV Records (DNS-based server discovery)

DNS SRV records (RFC 2782) let a SIP client discover where to send an INVITE or REGISTER without a hard-coded host:port. They carry priority, weight, port, and target, and they are the middle stage of the three-stage RFC 3263 lookup (NAPTR → SRV → A/AAAA) that lets one carrier hostname route across multiple POPs, balance load by weight, and fail over without any PBX-side change.

Record format

An SRV record returns four fields per result, queried under the name _service._proto.domain. For SIP, the service names are _sip and _sips; the protocols are _udp and _tcp.

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

Reads as: priority 10, weight 5, port 5061, target sip-edge.example.com. A normal A/AAAA query on the target then gives the IPs.

Priority vs weight

Two numbers, two jobs:

Priority, lower is preferred. All records at one priority must be exhausted before a client moves to the next. This is failover ordering.
Weight, among records sharing a priority, the proportional share of new connections each target receives (RFC 2782 weighted-random algorithm).

_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.

Two co-primary east POPs splitting traffic 50/50; west is the failover only used when both east targets are unreachable.

The RFC 3263 resolution chain

Given a SIP URI like sip:[email protected], a compliant client performs three lookups:

NAPTR on the domain, advertises supported transports (SIPS+D2T, SIP+D2T, SIP+D2U) and points to the SRV name to query next.
SRV on the chosen _service._proto.domain, returns priority/weight/port/target.
A / AAAA on the SRV target, returns the IP(s) to connect to.

If NAPTR is missing, the client falls back to SRV queries in a defined order (_sips._tcp → _sip._tcp → _sip._udp). If SRV is also missing, it falls back to a direct A/AAAA on the URI host using the default port for the transport.

INVITE vs REGISTER

Both follow the same DNS rules. The difference is post-resolution behaviour:

INVITE, each new dialog can re-resolve. A dead target affects one call; the next call picks a different SRV target.
REGISTER, the binding pins to a specific target for the registration lifetime. A dead registrar silently breaks inbound until the binding expires and re-registers. Active SIP OPTIONS pings (Asterisk pjsip qualify_frequency, Kamailio dispatcher) shorten that window dramatically.

Which engines honour SRV

Honour SRV by default: Asterisk pjsip (13+), FreeSWITCH (sofia), Kamailio (add dns_srv_lb = 1 for weighted balancing), OpenSIPS (use_dns_failover = yes), modern Polycom / Yealink / Snom firmware. FreePBX and 3CX honour SRV when trunks are configured by hostname only with the port left blank. Microsoft Teams Direct Routing hard-codes its SBC FQDN+port and does not consult SRV at the Teams → SBC hop (carrier-side SRV still works normally). Cisco CUCM needs SRV explicitly enabled on the SIP trunk profile; Avaya Aura supports it but rarely uses it in practice.

Common gotchas

Explicit host:port overrides SRV. If your trunk config has both a hostname and a port, most stacks skip SRV. Configure as bare hostname.
TLS SNI / cert mismatch. Some clients verify the cert against the connection target rather than the URI host (RFC 5922). Use SANs covering both, or use the URI host as the SRV target.
NAT port pinning on UDP. NAT mappings cache port pairs for 30–60s; SRV target changes won’t propagate to UDP keepalives mid-binding. TCP/TLS aren’t affected.
REGISTER target pinning. Binding pins to the registered target until refresh. Use OPTIONS pings to detect dead targets faster.
NAPTR ignored. Many clients skip NAPTR and jump straight to SRV. Publish SRV for every transport you support; don’t rely on NAPTR alone.
TTL traps. Long SRV TTLs (24h+) slow failover. 300–600s is the standard carrier range.