Implement DNS SRV/NAPTR Resolution for Outbound SIP Routing (RFC 3263)

[thorsager]

Problem

Currently, trunk configuration requires a hardcoded host:port and transport. In production, SIP providers publish their infrastructure via DNS SRV/NAPTR records (RFC 3263), enabling automatic failover and load balancing across redundant servers. Without RFC 3263 support, trunk configs are brittle: a single provider-host change or server outage requires a config reload.

Proposed Solution

Implement RFC 3263 DNS resolution in the outbound SIP routing path so that when a trunk host is a domain name (e.g. sip.twilio.com), the PBX performs:

1. NAPTR query — resolves the domain to discover available transport protocols (UDP, TCP, TLS, SCTP) and their respective SRV targets
2. SRV query — resolves the SRV target to obtain host:port pairs for the selected transport, sorted by priority and weight per RFC 2782
3. A/AAAA fallback — if neither NAPTR nor SRV records exist, fall back to standard A/AAAA resolution

The resolved target (host:port) should be cached with the DNS TTL to avoid querying on every outbound call.

Scope

• Add DNS resolution to internal/sip/transport.go — specifically in TargetFromContact() or a new ResolveTarget(host, transport string) function
• Cache resolved entries with configurable TTL (minimum 60s)
• Implement automatic failover: if the highest-priority target is unreachable (connection refused, transaction timeout), try the next target in the SRV list
• Wire into the trunk outbound path: when sending an INVITE over a trunk, resolve the trunk host via RFC 3263 first
• Log the resolved target at INFO level for operational visibility

Out of scope for this issue

• TLS/SCTP transport support (covered by Implement SIP over TLS (RFC 5630 / RFC 3261) and Secure RTP (SRTP) (RFC 3711) #5)
• ICE candidate gathering (covered by ICE/STUN Implementation #8)
• Client-side DNS server configuration (use system resolver)

Testing

1. Unit tests — mock NAPTR/SRV/A responses and verify correct target selection and ordering
2. Integration tests — start a local DNS server with SRV records pointing to a test SIP server, verify the PBX resolves and routes calls correctly
3. Failover test — configure two SRV targets, kill the first, verify the PBX retries on the second

References

• RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers
• RFC 2782: A DNS RR for specifying the location of services (DNS SRV)
• RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The NAPTR Resource Record