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.
Note: The use of TCP is assumed in this page, as in general, we recommend the use of SIP over TCP rather than UDP. If the use of UDP is required, then the DNS setup will need to add records using _udp for the Proto part of the SRV record.
DNS 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.
Shards and DNS configuration
A "shard" is a subset of a system that is able to serve a particular subscriber. Use of non-Sharded or Sharded configurations relates to the use of the Application Server URI(s) in Initial Filter Criteria (iFC).
Sentinel VoLTE supports the use of non-sharded configurations, as well as sharded configurations.
Non-sharded DNS configuration
In a non-sharded configuration of Sentinel VoLTE, a subscriber can be served by any node in the cluster. There is no mapping of subscriber to node. When iFC is configured for a non-sharded configuration, only one Application Server URI is needed per role.
So, if there is an MMTel-AS and an SCC-AS, then only two Application Server URIs are configured.
sip:scc-as.domain;transport=tcp;oc-mode=scc
sip:mmtel-as.domain;transport=tcp;oc-mode=mmtelAll nodes are the same, with respect to a subscriber. Therefore DNS SRV lookups should return nodes with equal priority.
SRV Query 1:
_sip._scc-as.volte1.domainSRV response:
_sip._tcp.node1.site1.domain 3600 IN SRV 20 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 20 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 20 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 20 0 5060 node4.site1.domainSRV Query 2:
_sip._mmtel-as.volte1.domainSRV response:
_sip._tcp.node1.site1.domain 3600 IN SRV 20 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 20 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 20 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 20 0 5060 node4.site1.domainSharded DNS Configuration
A "shard" is a subset of a system that is able to serve a particular subscriber.
In a sharded configuration of Sentinel VoLTE sessions for a subscriber must must be routed to a single Rhino node. This section of the documentation is only applicable when configuring a deployment when using sharding.
In order to spread load across 4 nodes then at a minimum the following is needed.
SRV Query 1:
_sip._tcp.volte1.domainSRV response:
_sip._tcp.node1.site1.domain 3600 IN SRV 0 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 10 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 20 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 30 0 5060 node4.site1.domainSRV Query 2:
_sip._tcp.volte2.domainSRV response:
_sip._tcp.node2.site1.domain 3600 IN SRV 0 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 10 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 20 0 5060 node4.site1.domain
_sip._tcp.node1.site1.domain 3600 IN SRV 30 0 5060 node1.site1.domainSRV Query 3:
_sip._tcp.volte3.domainSRV response:
_sip._tcp.node3.site1.domain 3600 IN SRV 0 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 10 0 5060 node4.site1.domain
_sip._tcp.node1.site1.domain 3600 IN SRV 20 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 30 0 5060 node2.site1.domainSRV Query 4:
_sip._tcp.volte4.domainSRV response:
_sip._tcp.node4.site1.domain 3600 IN SRV 0 0 5060 node4.site1.domain
_sip._tcp.node1.site1.domain 3600 IN SRV 10 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 20 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 30 0 5060 node3.site1.domainIt 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;transport=tcp
sip:volte2.domain;transport=tcp
sip:volte3.domain;transport=tcp
sip:volte4.domain;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;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].domainSRV response:
_sip._tcp.node1.site1.domain 3600 IN SRV 0 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 10 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 20 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 30 0 5060 node4.site1.domainSRV Query 2 becomes:
_sip._tcp.volte[026-050].domainSRV response:
_sip._tcp.node2.site1.domain 3600 IN SRV 0 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 10 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 20 0 5060 node4.site1.domain
_sip._tcp.node1.site1.domain 3600 IN SRV 30 0 5060 node1.site1.domainSRV Query 3 becomes:
_sip._tcp.volte[051-075].domainSRV response:
_sip._tcp.node3.site1.domain 3600 IN SRV 0 0 5060 node3.site1.domain
_sip._tcp.node4.site1.domain 3600 IN SRV 10 0 5060 node4.site1.domain
_sip._tcp.node1.site1.domain 3600 IN SRV 20 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 30 0 5060 node2.site1.domainSRV Query 4 becomes:
_sip._tcp.volte[076-100].domain
SRV response:_sip._tcp.node4.site1.domain 3600 IN SRV 0 0 5060 node4.site1.domain
_sip._tcp.node1.site1.domain 3600 IN SRV 10 0 5060 node1.site1.domain
_sip._tcp.node2.site1.domain 3600 IN SRV 20 0 5060 node2.site1.domain
_sip._tcp.node3.site1.domain 3600 IN SRV 30 0 5060 node3.site1.domainRecord Routing
Record Route for non replicated sessions
When not replicating session state, the IP address of the node is record routed. This means that all subsequent requests for a session go to the particular cluster node.
Record Route to enable fail-over of sticky sessions
A sticky session means that a particular session has to be processed by a single node. It only "migrates" between nodes if that node fails.
When replicating session state with sticky sessions, instead of record routing the IP address, the node’s own SIP URI is used as a basis for record routing. This per-node SIP URI is not the same as the URI used for iFC.
When Sentinel VoLTE records route for sticky sessions, it records route using a pattern, that essentially converts the IP address of the node into a particular DNS name.
So, if a node has an IP address of 192.168.10.20 then a DNS name like ip-192-168-10-20.domain is used.
Paired with this IP is a related SRV configuration.
SRV configuration for fail-over of sticky sessions
;; SRV address Priority Weight Port Target
_sip._tcp.ip-192-168-10-20.domain. <ttl> IN SRV 0 1 5060 node1.site1.domain.
_sip._tcp.ip-192-168-10-20.domain. <ttl> IN SRV 10 1 5060 node2.site1.domain.
;; ADDITIONAL SECTION:
node1.site1.domain <ttl> IN A 192.168.10.20
node2.site1.domain <ttl> IN A 192.168.10.21When a SIP client receives a Record-Route header such as <sip:ip-192-168-10-20.domain;transport=tcp> and the DNS it uses has the above configuration
the client must try node1 first as it is the only entry at priority 0. If that fails, it will try node2 next.
There are some subtleties to note. The SRV record also contains a port. The Record-Route has to omit the port, but can include a transport parameter.
Given a Record-Route containing the URI <sip:ip-192-168-10-20.domain;transport=tcp>, the SIP client will look up the _sip._tcp.ip-192-168-1-20.domain SRV record.
If the URI had a port, then by the rules of RFC 3263 the client would skip the SRV lookup and instead perform an A record lookup on ip-192-168-10-20.domain which won’t have weighted results.
This means that fail-over of a session would not work resulting in all sessions on that node being lost. Therefore, Sentinel VoLTE does not record route using a port.
Additionally, when configuring DNS, ensure the port numbers are correct.
For further details on URI patterns for record routing, please refer to the SIS documentation.
