The SRV Record field on Target Platform directs SIP registration to the correct server based on the priority and weight published in the record, providing automatic failover and load balancing across data centers. This page covers verifying an SRV record before deployment and how CCaaS behaves when a registration attempt fails.

SRV Record Format

An SRV record for SIP registration is structured as _sip._<protocol>.<domain>:

Component	Description
`_sip`	Indicates the record is for SIP services.
`_<protocol>`	The transport protocol — `_tls`, `_tcp`, or `_udp`, depending on the connection type. A `_sips` variant also appears on some platforms.
`<domain>`	The domain provided by the platform or partner responsible for the deployment.

For example, a TLS-based record for the domain core2-nj.example.com would be entered as _sip._tls.core2-nj.example.com.

📘
Getting the Domain
The domain portion is specific to the platform or partner being integrated with — it must be obtained from that partner rather than guessed.

Testing an SRV Record

Before entering an SRV Record, its format and reachability should be confirmed using a lookup tool:

Tool	Best For
nslookup.io SRV Lookup	Returns results sorted by priority and weight, useful for understanding server hierarchy ahead of a failover.
MXToolbox SRV Lookup	Supports testing multiple SRV records in one session and retains recent searches for comparison.

If a record does not return results under _sip._tls or _sip._tcp, trying the remaining protocol variations (_sip2._tls, _sips._tcp, _sip._udp, _sips._udp) can confirm whether SRV is supported under a different protocol than expected — support varies by integration platform.

✅
Best Practice
Always verify an SRV record with a lookup tool before deploying a customer, confirming both that it resolves and which protocol variation it resolves under.

Server Selection

When an SRV record returns multiple targets, CCaaS selects the target with the lowest priority value; if multiple targets share the lowest priority, the one with the highest weight is selected. CCaaS currently connects to only this single selected target rather than distributing across all returned targets.

SIP Registration Failover

CCaaS resolves the SRV record and attempts registration against the selected target first. If registration fails, CCaaS rolls to the next-priority target in the record after three consecutive failed REGISTER attempts against the current target — failover is driven entirely by this failure count, with no timer governing when it occurs.

The same rule applies at every subsequent level of the SRV list. If a secondary target also accumulates three consecutive failures, CCaaS rolls to the next entry, wrapping back to the primary in a two-entry SRV record.

📘
No Automatic Failback
CCaaS does not proactively probe higher-priority targets after a failover. Once registration has moved to a secondary or lower target, it remains there as long as that target continues to register successfully — there is no failback timer or periodic recovery check.
If registration needs to return to the primary after it recovers, the secondary must be removed from service to force the three-failure rollover. Because CCaaS does not attempt to fail back automatically, the hold-off period some platforms require before re-registering a recovered primary (often cited as needed to avoid a duplicate-registration conflict on platforms such as Broadworks) is not a concern here.

The SIP re-REGISTER interval — how often CCaaS refreshes its registration with the current target — is a separate setting from failover behavior. Adjusting it does not change when CCaaS rolls between SRV targets.