This page provides notes and guidance regarding DNS redundancy for a Sentinel VoLTE TAS cluster.
Background SIP Routing mechanism
The AS URI defined within a subscriber’s iFC is targeted by the S-CSCF using DNS procedures defined by RFC 3263 which can be summarised as follows:
-
Determine a transport protocol (NAPTR query)
-
Find a server port on a hostname (SRV query)
-
Find an IP Address (A-Record query)
Step 2 is relevant here. The structure of a SRV record is:
_Service._Proto.Name TTL Class SRV Priority Weight Port TargetRFC 2782 provides more detail.
The information element of particular interest is the "Priority". Multiple results are sorted in priority order and when communication toward one fails the next is chosen. RFCs 2782 and 3263 provide details.
Additionally, the response received to an SRV query can be determined by the source IP Address using DNS "views" functionality which enables co-ordinated preference routing between IMS sites.
DNS names for each node
| Node name | DNS Name | Rhino node ID | Savanna Cluster ID |
|---|---|---|---|
VoLTE-1 |
node1.site1.domain.com |
101 |
1 |
VoLTE-2 |
node2.site1.domain.com |
102 |
1 |
VoLTE-3 |
node3.site1.domain.com |
103 |
1 |
VoLTE-4 |
node4.site1.domain.com |
104 |
1 |
How DNS SRV is configured
At least 4 different SRV lookups, because there are 4 nodes (for load sharing purposes).
At minimum for a 4 node cluster in a site, you need
SRV Query 1:
_sip._tcp.volte1.domain.comSRV response:
_sip._tcp.node1.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node2.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node3.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node4.site1.domain.com 3600 IN SRV 30 0 5060SRV Query 2:
_sip._tcp.volte2.domain.comSRV response:
_sip._tcp.node2.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node3.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node4.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node1.site1.domain.com 3600 IN SRV 30 0 5060SRV Query 3:
_sip._tcp.volte3.domain.comSRV response:
_sip._tcp.node3.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node4.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node1.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node2.site1.domain.com 3600 IN SRV 30 0 5060SRV Query 4:
_sip._tcp.volte4.domain.comSRV response:
_sip._tcp.node4.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node1.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node2.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node3.site1.domain.com 3600 IN SRV 30 0 5060It is desirable to have more SRV queries than you have nodes. This is so that you can have a big pool and the ability to add new nodes into the site without changing the URIs configured in iFCs.
AS URI and iFC configuration/provisioning
There are at least four AS URIs, as there are four nodes.
At minimum you need these AS URIs:
sip:volte1.domain.com;transport=tcp
sip:volte2.domain.com;transport=tcp
sip:volte3.domain.com;transport=tcp
sip:volte4.domain.com;transport=tcpThere are therefore four different AS’s configured in the HSS. Each one has one of these URIs.
25% of subscribers use an iFC that has volte1 as the URI, 25% have volte2, and so-on.
This subscriber → iFC mapping is done during provisioning.
Over provisioning for later flexibility
It makes sense to over provision the number of AS URIs and number of SRV records. This is so that there is flexibility to change the SRV DNS lookups without changing the provision of subscriber → iFC provisioned in the HSS.
I.e. have AS URIs of volte[1-100].domain.com;transport=tcp
Then have SRV queries set up like this, assuming 4 nodes in a site. Later on if you need 6 nodes in a site you have more groups of SRV queries.
SRV Query 1 to include over provisioning:
_sip._tcp.volte[001-025].domain.comSRV response:
_sip._tcp.node1.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node2.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node3.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node4.site1.domain.com 3600 IN SRV 30 0 5060SRV Query 2 becomes:
_sip._tcp.volte[026-050].domain.comSRV response:
_sip._tcp.node2.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node3.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node4.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node1.site1.domain.com 3600 IN SRV 30 0 5060SRV Query 3 becomes:
_sip._tcp.volte[051-075].domain.comSRV response:
_sip._tcp.node3.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node4.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node1.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node2.site1.domain.com 3600 IN SRV 30 0 5060SRV Query 4 becomes:
_sip._tcp.volte[076-100].domain.com
SRV response:_sip._tcp.node4.site1.domain.com 3600 IN SRV 0 0 5060
_sip._tcp.node1.site1.domain.com 3600 IN SRV 10 0 5060
_sip._tcp.node2.site1.domain.com 3600 IN SRV 20 0 5060
_sip._tcp.node3.site1.domain.com 3600 IN SRV 30 0 5060DNS failover configuration
The SIS product within the VoLTE TAS handles the configuration of the DNS failover method. Refer to this page in the SIS documentation for details.
