Freeze one new request and the discovery inputs
Record timestamp and timezone, account and trunk variant, exact SIP URI or configured outbound-proxy value, whether transport or port is explicit, client and version, resolver path, NAPTR, SRV, A and AAAA answers with TTLs, cached records, selected target and address, transaction branch, response or transport error, and whether a later target was attempted.
Keep a new-call request separate from an established dialog. DNS target selection does not migrate an existing dialog or RTP stream, and a later call reaching another node does not prove the failed transaction retried correctly.
Prove that the client reaches NAPTR or SRV processing
RFC 3263 varies discovery by URI, transport, explicit port and available records. Confirm what the configured client actually queries and whether it supports the returned services and transports. Preserve the client log and a packet or resolver trace for the same attempt.
An explicit numeric address, pinned proxy, configured port, stale local hosts entry or incomplete client implementation can bypass expected DNS stages. Do not change provider records or firewall rules before proving which lookup the client used.
Interpret NAPTR order and SRV priority correctly
NAPTR order and preference choose an applicable service path; SRV then supplies priority, weight, port and target. RFC 2782 requires the lowest reachable priority first and uses weight only among records at the same priority. Weight is static selection information, not live health telemetry.
Do not expect every call to alternate, treat a low weight as a disabled backup, or sort the largest number first. Preserve the full answer and the client-produced ordered list rather than inferring selection from a single target.
Resolve the selected target and retain TTL boundaries
For each selected SRV target, retain its A or AAAA records, TTL, resolver and the address the client tried. Separate authoritative data, recursive-cache data, local cache and application cache. A current command-line lookup does not prove what the long-running PBX held when the request failed.
Do not flush every cache as the first action. Compare timestamps and TTLs, preserve the previous answer and restart or refresh only the demonstrated cache owner under an approved change plan.
Classify a qualifying SIP failure before expecting retry
RFC 3263 treats a 503 response, transport failure or transaction timeout without any provisional or final response as failure for moving to the next element. It calls for a new request with a different Via branch. An ordinary application rejection, successful connection, provisional response or failure after the PBX route can require different handling.
Capture the exact response or transport event and transaction timers. Do not force all 4xx or 5xx responses into DNS failover, shorten timers blindly or loop the same transaction across targets.
Retest selection, delivery and restoration separately
In a provider-approved window, exercise one reversible non-emergency new-call failure. Prove first-target selection, qualifying failure, new branch to the next eligible target, edge arrival, provider response and final call outcome. Restore the first path, respect cache lifetimes and prove later selection without claiming an exact recovery timer.
Correct only the earliest demonstrated mismatch: configuration, resolver, client discovery support, cache, transport reachability, failure classification or downstream SIP handling. No DNS record, request, call or failover was inspected or tested for this article.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Voip Unlimited SIP Trunks ↗
- RFC 3263: Locating SIP Servers ↗
- RFC 2782: DNS SRV resource records ↗
- RFC 3403: DDDS DNS database and NAPTR records ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.