4G to IMS call flow – Register to IMS – part 5

Posted: August 29, 2010 in technical
Tags: , , , , , , , , , , , , , , , , , , , , ,

18. DNS query

The specifics of the SIP information retrieval via DNS queries are described in RFC 3263 – Session Initiation Protocol (SIP): Locating SIP Servers. This RFC details the SIP specificities on top of RFC 2782 – A DNS RR for specifying the location of services (DNS SRV).

In our case, the P-CSCF of the visited domains looks at the Request-URI the UE sent in its Register message. It observes this domain is different than its own, so it concludes the UE is in roaming, so it has to locate the home I-CSCF, in order to see if it can serve this subscriber or not.

So, what steps does the visited P take in order to get to the right home I?

The P performs a NAPTR query for the domain specified in the Request-URI;

This NAPTR thinggie comes from Name Authority Pointer and it is actually a type of DNS RR – Resource Record. The reason behind the invention of this horrible RR is the quest to map everything around the interwebs – we’re mapping you over!!! Resistance is futile !!! HA HA HAAA 😛

Now, seriously, they are trying to map resources like services (like printers, LDAP servers or..why not…I-CSCF servers!!!) to a plain domain name. This NAPTR has a specific structure:

– service name

– set of flags

– regexp rule (yes, regular expressions, we all hate them 😛 , or at least I surely do so, at least after the Perl learning tentative I had a while back)

– an order value

– a preference

– replacement

and, even more, they can also come chained in multiple records carefully cascaded to make our poor lives even more miserable.

These NAPTR things are standardized by RFC 2915 and RFC 3403. Good luck with that!

Moving on, let’s take a look at how a P-CSCF NAPTR Query may look like:


QNAME=registrar1.home.net, QCLASS=IN, QTYPE=NAPRT

The NAPTR Response would be like this:


QNAME=registrar1.home.net, QCLASS=IN, QTYPE=NAPTR

registrar1.home.net       0   IN   NAPTR   50 50 “s” “SIP+D2U” “” _sip._udp.registrar1.home.net

0   IN   NAPTR 90 50 “s” “SIP+D2T” “” _sip._tcp.registrar1.home.net

0   IN   NAPTR 100 50 “s” “SIPS+D2T” “” _sips._tcp.registrar1.home.net

UDP is preferred, as the UDP record appears first – order criteria. The “s” means this is a SRV record. What this P needs to do further on is to perform a SRV Query at the address provided in the NAPTR record first ( _sip._udp.registrar1.home.net) in order to get the services supported by this guy (the I-CSCF).

The SRV Query would look something like this:


QNAME=_sip._udp.registrar1.home.net, QCLASS=IN, QTYPE=SRV

And the SRV Response:


QNAME=_sip._udp.registrar1.home.net, QCLASS=IN, QTYPE=SRV

_sip._udp.registrar1.home.net   0   IN   SRV   1   10   5060   icscf1_p.home.net

0   IN   SRV   1   0   5060   icscf7_p.home.net

icscf1_p.home.net   0   IN   AAA   5555::aba:abb:abc:abd

icscf7_p.home.net   0   IN   AAA   555::dba:dbb:dbc:dbd

Here there are listed all the I-CSCF proxies in the home.net domain, with their Priority and Weight. The best one will be chosen, according to the rules defined in RFC 2782. As the answer also contains the IP address of the I-CSCF, the visited P-CSCF will forward the REGISTER message to this I-CSCF (here icscf1), on port 5060.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s