In marriage we need to find a way how to make common decisions. In my case we decided that my wife will make those routine, unimportant decisions as what to cook for a dinner, how will spend a weekend or holidays or what to do with the money we have. My responsibility is to take the key, long-term decisions which will have the major influence on our well-being. So I decide what soccer team is our favorite for the next season, brand of a BBQ grill and what is our relationship towards EU.
In the IMS network there are many key network functions which take the decisions about routing, charging, applied services etc. But should I choose one which would allow me to manage the whole network, I’d go for DNS. Without DNS there would be no IMS. And don’t get me wrong. This is not only about the usage of IP protocol and symbolic address translation. DNS is responsible also for other vital mechanisms as routing, load-sharing, resiliency, service discovery and zero-configuration, provisioning, mobile number portability, timezone support, etc.
DNS is defined in many documents the most important for us are IETF RFC 1034, RFC 1035, RFC 3646 and mainly in RFC 3263 and RFC 7984 and GSMA IR.67.
Let’s take a look on routing in the IMS network.
Routing in IMS
We can start with the registration. Well, the DNS is used also during the ePC attach procedure. But we don’t discuses particular access networks here. (The Protocol Configuration Options – PCO response will contain the IPv4/IPv6 address of the P-CSCF anyway). In the IMS the P-CSCF will take the Request-URI header of the SIP REGISTER message and based on the DNS response will identify the I-CSCF.
And it’s not just about the registration. As you probably know, the routing in SIP is done either based on a top most Route header, or if there is no Route header the routing is done based on the Request-URI, which contains the address of the final recipient.
SIP INVITE Routing – Originating part
And every time before a network element can pass the message to a next hop, it has to discover what type of transport will be used (UDP, TCP, TLS, SCTP), what port to use and what numeric IP (IPv4/IPv6). This procedure we call SIP Server Locating. Sometimes the information is already present in the message headers (e.g. routing of responses), sometimes we can use some defaults and in all other cases we use the DNS.
As an example we mentioned the SIP REGISTER message on P-CSCF, because in this case we do the SIP routing based on the domain name, which user is registering to. That means we can’t use any defaults and we have to trigger the DNS.
SIP + DNS
However, as mentioned, it applies in general to all the SIP routing.
The SIP Server discovery is done in 3 steps to discover the Transport, Port and IP. That also corresponds to 3 DNS queries NAPTR, SRV and A/AAA.
Nameserver
Firstly we send the NAPTR request in order to find the right name server (as the I-CSCF can be in a different network).
Domain Name System (query) Flags: 0x0100 Standard query 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data: Unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries operator.com: type NAPTR, class IN Name:operator.com Type: NAPTR (Naming authority pointer) Class: IN (0x0001)
Domain Name System (response) Flags: 0x8580 Standard query response, No error 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .1.. .... .... = Authoritative: Server is an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries operator.com: type NAPTR, class IN Name: operator.com Type: NAPTR (Naming authority pointer) Class: IN (0x0001) Authoritative nameservers operator.com: type SOA, class IN, mname dns_01.operator.com Name: operator.com Type: SOA (Start of zone of authority) Class: IN (0x0001) Time to live: 15 minutes Data length: 68 Primary name server: dns_01.operator.com Responsible authority's mailbox: devnull Serial Number: 167 Refresh Interval: 10800 (3 hours) Retry Interval: 3600 (1 hour) Expire limit: 2419200 (28 days) Minimum TTL: 900 (15 minutes)
Transport discovery
To find out what type of transport to use, there are several rules to follow:
If the target (R-URI or the top most Route header) is a numeric IP, we use UDP transport layer.
sip:2233445566@10.0.0.1
If no transport is specified, but port is specified, we also use UDP.
sip:context123@scscf1.ims.operator.com:5070
Otherwise we can specify the transport directly.
sip:context123@scscf1.ims.operator.com;transport=tcp
For sips we always use TLS.
If none of the rules specified above applies, then we have to use DNS to resolve the address.
; order pref flags service regexp replacement IN NAPTR 10 50 "s" "SIPS+D2T" "" _sips._tcp.icscf.ims.operator.com. IN NAPTR 20 50 "s" "SIP+D2T" "" _sip._tcp.icscf.ims.operator.com. IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.t.ims.operator.com.
The third column defines, what will be the order/priority. The row with the lowest value has the highest priority. In case when more rows have the same priority, then we loadshare using preference/weights in the fourth column. The flag “s” then tells to us, that the next step is the DNS SRV request. Again, for more details, please refer to RFC.
Port Discovery
It is even easier. If the port is specified, simply us it.
sip: context123@scscf1.ims.operator.com:5070
If the target is a numeric IP address, we use default ports for given transport layers.
sip:2233445566@10.0.0.1;transport=tls => port 5061 sip:2233445566@10.0.0.1;transport=tcp => port 5060 sip:2233445566@10.0.0.1;transport=udp => port 5060
Otherwise we send an SRV request to DNS.
;; Priority Weight Port Target
IN SRV 0 1 5060 icscf1.ims.operator.com
IN SRV 0 2 5060 icscf2.ims.operator.com
A full DNS SRV request/response would look like:
Domain Name System (query) Flags: 0x0100 Standard query Queries _sip._udp.operator.com: type SRV, class IN Name: _sip._udp.operator.com Type: SRV (Service location) Class: IN (0x0001)
Domain Name System (response) Flags: 0x8580 Standard query response, No error Queries _sip._udp.operator.com: type SRV, class IN Name: _sip._udp.operator.com Type: SRV (Service location) Class: IN (0x0001) Answers _sip._udp.operator.com: type SRV, class IN, priority 10, weight 100, port 5060, target icscf1.ims.operator.com _sip._udp.operator.com: type SRV, class IN, priority 20, weight 100, port 5060, target icscf2.ims.operator.com Authoritative nameservers operator.com: type NS, class IN, ns dns_01.operator.com Name: operator.com Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 8 hours Data length: 11 Name Server: dns_01.operator.com Additional records icscf1.ims.operator.com: type A, class IN, addr 10.0.1.2 Name: icscf1.ims.operator.com icscf2.ims.operator.com: type A, class IN, addr 10.0.2.2 Name: icscf2.ims.operator.com
Note that the SRV can already contain A/AAA records.
IP Discovery
To discover an exact IP address is just a piece of cake. Either the numeric IP is present, then we will use it.
sip:2233445566@10.0.0.1
Or, if the SRV request was already done, use the returned IP address if present. If it wasn’t present, perform A query based on that result.
icscf1.ims.operator.com
If we haven’t done SRV request, then do A query using the SIP URI domain name. Use the numeric IP in the order returned by DNS.
icscf1.ims.operator.com 1800 IN A 10.10.1.1 icscf2.ims.operator.com 1800 IN A 10.20.1.1
DNS flow
On the first picture of routing in IMS above we have a simplified network with two sites. One is responsible for instance for the customers physically located in the west of a country (e.g. Vancouver) and the other one for those in the east (Montreal). If the DNS will do a loadsharing/loadbalancing, the SIP REGISTER message from Vancouver can end up in the IMS core (S/I-CSCF) in Montreal.
Also the DNS is typically responsible for an AS selection because the iFCs usually contain only generic FQDNs of application servers.
DNS + registration
ENUM
During the session establishment we then use the DNS to find the proper routing based on the ENUM response.
Queries 2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net: type NAPTR, class IN Name: 2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net Type: NAPTR (Naming authority pointer) Class: IN (0x0001)
Answers 2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net: type NAPTR, class IN, order 100, preference 10, flags u Name: 2.1.0.9.8.7.6.5.4.3.2.1.e164enum.net Type: NAPTR (Naming authority pointer) Class: IN (0x0001) Time to live: 10 seconds Data length: 85 Order: 100 Preference: 10 Flags length: 1 Flags: "u" Service length: 7 Service: "E2U+SIP" Regex length: 69 Regex: "!^.*$!sip:+123456789012@ims.mnc000.mcc000.3gppnetwork.org;user=phone!" Replacement length: 1 Replacement: <Root>
The DNS Resolver will support the following service-field values:
-
- “E2U+sip” as defined in RFC 3824
- “E2U+pstn:tel” as defined in RFC 4769
- “E2U+pstn:sip” as defined in RFC 4769
- REGEXP – Contains a substitution expression that is applied to the original string held by the AS in order to construct the next domain name to lookup.
- REPLACEMENT – A 1 octet length field followed by the next NAME to query for NAPTR, SRV, or address records depending on the value of the flags field. If replacement is used this must be a fully qualified domain-name.
The ENUM request can be send by both S-CSCF or AS. The ENUM is as a database indicating the presence in the IMS and for Mobile Number Portability (MNP).
ENUM based Routing
As we can see a correctly working DNS is a must for a 4G network. When we look at the 5G the DNS will become even more critical component. The next generation should be about devices – IoT if you want. Think about all those devices. Some researches show that there will be about 50 billion connected devices in 2020. All these devices will need to use some services. How to do the service discovery when the device itself is supposed to be ‘plug&play’? Sure, the answer is DNS.
Other related posts:
Real Time Communication 