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 Target

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

Redundancy in a site

ClusterDNS onesite

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

SRV 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 5060

SRV Query 2:

_sip._tcp.volte2.domain.com

SRV 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 5060

SRV Query 3:

_sip._tcp.volte3.domain.com

SRV 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 5060

SRV Query 4:

_sip._tcp.volte4.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 5060

It 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=tcp

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

SRV 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 5060

SRV Query 2 becomes:

_sip._tcp.volte[026-050].domain.com

SRV 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 5060

SRV Query 3 becomes:

_sip._tcp.volte[051-075].domain.com

SRV 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 5060

SRV 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 5060

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.

Previous page Next page
Sentinel VoLTE Version 2.7.0