VoIP.infoThe independent guide to business communications.
VoIP.info Reference

SIP DNS discovery: NAPTR, SRV and address records

Understand service selection and failover before hard-coding a SIP server IP address.

Reviewed 2026-10-19SIP standards; extension support depends on both peersIntermediateDocumentation based · not lab tested

Discovery is more than an A record

SIP DNS procedures can use NAPTR to select supported services and transports, SRV to locate service targets and ports, and A or AAAA to resolve target addresses. The exact path depends on the URI, explicit port or transport information and client capabilities. Not every deployment uses every record type. Hard-coding an address can bypass the provider's service selection and failover design. Conversely, publishing SRV records does nothing for a client configured to use a fixed IP address and port.

Interpret priority and weight correctly

SRV priority ranks target groups: lower values are preferred. Weight influences selection among records with the same priority; it is not a promise that exactly that percentage of calls will use a target. DNS caches and implementation behavior affect observed distribution. Check the complete chain from the actual SIP domain and transport. Record answers, TTLs, resolver and timestamp. A working A lookup for the domain does not prove that the client queried or resolved the relevant SRV target.

Test failure rather than assuming it

Use the provider's documented configuration and an authorized maintenance window to observe what the client does when its selected target is unavailable. Distinguish DNS selection from registration state, active call state and media continuity. DNS failover does not migrate an established call by itself. For TLS, certificate identity validation must remain correct when service discovery selects another target. Do not disable validation merely because a replacement server has a different hostname. Compare the client's supported discovery and identity rules with the provider's requirements, then preserve the evidence with the incident timeline.

Apply SIP discovery to Asterisk PJSIP

The Asterisk PJSIP DNS guide maps RFC 3263 and SRV priority and weight to the effective URI, Asterisk resolver and transport selection, then keeps TTL, connection reuse, registration retry and service recovery distinct.

Apply SIP retry rules to a provider DNS path

The Voip Unlimited DNS workflow keeps URI inputs, client support, NAPTR order, SRV priority and weight, target addresses and SIP failure classification separate.

Bind Flowroute DNS evidence to the route direction and type

Flowroute prefers NAPTR, SRV, A records and then direct addresses for outbound PoP access, while inbound SIP-REG, PSTN-number and host or URI routes have different edge behavior. The Flowroute failover diagnostic retains that distinction.

Recognize the DIDWW empty-port SRV boundary

DIDWW says an inbound static SIP trunk first performs SRV lookup when its port is empty, then falls back to an A record when no SRV record exists. The DIDWW diagnostic keeps that resolution layer separate from trunk-group advancement.

Keep Twilio trunk identity separate from edge routing

Twilio requires the personal trunk domain in the Request-URI even when a generic localized domain supplies NAPTR and SRV edge routing. The termination diagnostic preserves both names and the selected address.

Treat Telnyx network data and DNS as dated evidence

Telnyx publishes A, SRV, NAPTR and machine-readable voice.json data, with a current Canada-address disagreement between first-party pages. The Telnyx diagnostic reconciles the selected region, DNS, packet source and provider confirmation.

Bind Twilio URI resolution to the selected resource and edge

Record the enabled OriginationUrl, optional edge parameter, current resolution, observed source and selected destination. The Twilio diagnostic keeps them aligned.

Bind Plivo URI resolution to one inbound attempt

Record the configured URI, resolver context, answers, TTL, selected address and provider result using the Plivo inbound diagnostic.

Bind Vonage URI resolution to one provider attempt

Record configured URI, resolver context, answers, selected address, timeout and provider result using the Vonage inbound diagnostic.

Revisit Blink discovery when retry evidence requires it

The Blink registration diagnostic keeps account domain, manual proxy, NAPTR, SRV, address and selected transport distinct.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide

DNS for SIP phones and trunks

Understand why a working IP connection can still fail to locate the intended calling service.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP URI structure: identity, routing and parameters

Parse sip and sips addresses without assuming they behave like ordinary telephone numbers.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide · Current Asterisk PJSIP transport-selection, DNS API, res_resolver_unbound and outbound-registration documentation plus RFC 3263 and RFC 2782 were reviewed October 8, 2026; no Asterisk or FreePBX host, resolver, nameserver, DNS zone, cache, URI, proxy, registrar, transport, connection, registration, request, failover event, availability, compatibility or call was inspected or tested

Asterisk PJSIP DNS resolution: SRV, TTL and live-state boundaries

Trace a SIP URI through Asterisk's resolver, SRV selection, address family, transport and live registration state without treating a DNS edit as immediate failover.

Read guide →
Diagnostic · Current Asterisk PJSIP transport-selection, DNS API, res_resolver_unbound and outbound-registration documentation plus RFC 3263 and RFC 2782 were reviewed October 8, 2026; no Asterisk or FreePBX host, resolver, nameserver, DNS zone, cache, URI, proxy, registrar, transport, connection, registration, request, failover event, availability, compatibility or call was inspected or tested

Asterisk PJSIP keeps using the old DNS target

Compare authoritative and recursive DNS, the exact PJSIP query path, TTL, selected target, live connection and registration retry state before flushing caches or restarting Asterisk.

Read guide →
Troubleshooting · Voip Unlimited SIP-trunk DNS descriptions and RFC 3263, RFC 2782 and RFC 3403 reviewed October 13, 2026; the exact account, service FQDN, URI, transport, port, resolver, NAPTR, SRV, address answers, TTL, client support, cached state, first target, failure class, next transaction, provider edge, PBX route and recovery remain deployment specific, and no account, resolver, PBX, SBC, packet, request, response, call, failover event or media stream was inspected or tested

Voip Unlimited SIP DNS failover does not try the next target

Trace one new SIP request from URI and client discovery behavior through NAPTR, SRV, address records, cached state, selected transport, qualifying failure and the next transaction.

Read guide →
Troubleshooting · Current first-party Flowroute and BCM One documentation reviewed October 18, 2026. The current support pages were updated August 27, 2026 and list the Oregon and Virginia PoPs, require all listed signaling ranges for provider-side failover and load balancing, and describe Direct Media as RTP from potentially any source IP to the customer system public media-port range. Older but still public first-party route documentation distinguishes route objects from each number's primary and failover relationships, registration from Host or URI delivery, and preferred inbound PoP selection from customer-destination failover. Documentation and examples are not observed tenant state. No Flowroute account, credential, number, route, registration, DNS answer, certificate, PBX, firewall, packet, media stream, invoice, emergency workflow or live call was inspected or tested

Flowroute number does not use the intended route, PoP or failover path

Prove the number relationships, route type, preferred provider edge, first result, any later attempt, PBX handling and direct-media result.

Read guide →
Troubleshooting · DIDWW failover, trunk-group and response-code documentation updated October 7–8, 2026 was reviewed October 14, 2026; it documents priority, weight, ringing timeout, selected re-routing disconnect codes, capacity controls, DNS SRV and a separate CDR for each routing attempt, but no account, DID, trunk group, endpoint, DNS answer, capacity state, request, response, CDR stream, failover event, media stream or live call was inspected or tested

DIDWW inbound trunk group does not try the next trunk

Prove DID assignment, trunk-group membership, priority and weight, the configured rerouting-code set, ringing timeout, capacity and every DIDWW CDR attempt before changing a working inbound route.

Read guide →
Troubleshooting · Current Twilio Elastic SIP Trunking configuration, troubleshooting, sending-SIP, CredentialList, Trunk-resource and error-32201 documentation reviewed October 14, 2026; the sources distinguish Termination URI identification, DNS and edge selection, IP ACL and credential authentication, 407 challenge flow, E.164 addressing, caller identity and later account policy, but do not prove one account, trunk, ACL, credential list, source address, DNS answer, route, caller identity, permission, capacity state, packet, media stream or completed call, and none was inspected or tested

Twilio termination call gets no response or 403 Forbidden

Separate Termination URI and DNS reachability from initial-INVITE ACL rejection, post-407 credential failure, E.164 addressing, caller identity, geographic permission and capacity policy.

Read guide →
Troubleshooting · Current first-party Telnyx SIP Connection, authentication, inbound routing, failover, response-code, Outbound Voice Profile, round-robin, network and configuration-guide documentation reviewed October 17, 2026. The current network page and machine-readable `voice.json` version 2026-05-25 publish Canada signaling addresses `192.76.120.31` and `64.16.250.13`, while the currently accessible failover guide lists `193.108.220.10` and `193.108.220.25`; this source disagreement is preserved rather than resolved editorially. The selected account, number, Connection, authentication method, registered instance, inbound region, DNS answer, signaling address, route order, response, Outbound Voice Profile, channel control, PBX, firewall, packet, media, availability, price and compatibility remain account, configuration, time or observation specific. No account, Connection, number, profile, DNS lookup, firewall, PBX, packet, route, failover event, media stream or live call was inspected or tested

Telnyx inbound route or failover is wrong

Trace one inbound call through number-to-Connection assignment, authentication type, selected region, current network evidence, route order, provider response, PBX match and any next attempt.

Read guide →
Troubleshooting · Current first-party Twilio Elastic SIP Trunking configuration, OriginationUrl, failover, IP-address, troubleshooting and Trunk-resource documentation reviewed October 17, 2026. Number association, Trunk SID, enabled Origination URLs, priority, weight, edge selection, provider attempt, SIP result, disaster-recovery webhook, TwiML result, PBX handling and media remain separate evidence. The OriginationUrl page currently contains conflicting default-value presentation, so effective values must be read explicitly. No Twilio account, number, trunk, OriginationUrl, disaster-recovery application, PBX, SBC, DNS answer, firewall, packet, media stream or live call was inspected or tested

Twilio origination URI, failover or disaster recovery is wrong

Trace one inbound call through number association, enabled Origination URLs, priority and weight, edge selection, SIP results, disaster recovery, PBX handling and media.

Read guide →
Troubleshooting · Current first-party Plivo Zentrunk quickstart, technical-specification, account-limit, hangup-code and debug-log documentation reviewed October 18, 2026. Number assignment, inbound trunk, primary and fallback URI, URI authentication, DNS result, provider attempt, SIP response, hangup source and cause, PBX handling, answer and each media direction remain separate evidence. Plivo documents fallback when the primary URI is unresponsive, not as a universal retry after every SIP final response. No Plivo account, trunk, number, URI, credential, PBX, DNS answer, firewall, packet, media stream or live call was inspected or tested

Plivo inbound primary or fallback URI is wrong

Trace one inbound call through number assignment, trunk and URI state, primary reachability, fallback eligibility, SIP results, PBX routing and media.

Read guide →
Troubleshooting · Current first-party Vonage SIP technical, dashboard, Asterisk, FreePBX and Voice Logs documentation reviewed October 18, 2026. Number ownership, number-to-trunk link, trunk type, inbound region, SIP URI, priority, timeout, DNS result, provider attempt, transport, PBX identification, route, answer and each media direction remain separate evidence. Priority orders eligible URIs; the reviewed pages do not publish one universal SIP-response advancement matrix. No Vonage account, number, trunk, URI, credential, PBX, DNS answer, firewall, packet, media stream or live call was inspected or tested

Vonage inbound SIP URI priority or timeout is wrong

Trace one inbound call through number linking, trunk and region, ordered SIP URIs, timeout, transport, PBX identification, routing and media.

Read guide →
Client research · Current Blink Windows/Linux manual pages for SIP accounts, the main interface, incoming-call alerts and audio calls, the platform-specific changelog, and RFC 3261 response and proxy-processing rules reviewed October 14, 2026; the documentation describes Blink sending 603 for Reject, 486 for Busy, and no SIP response when Escape only silences the local alert, but it does not prove the selected package, account, registrar, proxy, forked branches, PBX response handling, voicemail policy, forwarding policy or observed call result, and no package, workstation, account, credential, SIP trace, PBX, provider, branch, forwarding rule, voicemail destination, alert action or live call was inspected or tested; registration timeout, explicit service-unavailable and retry evidence refreshed October 19, 2026

Blink softphone: platform tracks, SIP accounts and negotiated protection

Evaluate AG Projects' separate Windows, Linux, Blink Pro for Mac and Mac beta artifacts, local SIP account ownership and negotiated protection.

Read guide →
Troubleshooting · Current first-party Blink product, account, troubleshooting, download and platform-changelog pages plus RFC 3261, RFC 3263 and RFC 5626 were reviewed October 19, 2026. Product track, operating system, package, SIP account, DNS answers, proxy override, transport, network policy, server response, retry timing and call behavior remain deployment specific. No package, workstation, account, credential, DNS answer, proxy, registrar, firewall, NAT device, SIP trace, packet, media stream or live call was inspected or tested

Blink registration shows 408 timeout, 503 unavailable or stays gray

Trace Blink account identity, DNS or manual proxy selection, transport, network reachability, SIP response and retry timing before changing codecs or security settings.

Read guide →