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