Aayush: weblog

Posts Tagged ‘MGCF’

Race Condition for “tel” URI Routing in IMS – Unknown numbers !

Posted by Aayush Bhatnagar on April 4, 2011


Recently, in a discussion I came across a race condition that occurs in IMS for routing tel URIs which no longer exist in the IMS domain (operator’s network).

The problem statement is as follows:


When the operator de-provisions a telephone number from the IMS core, and another IMS subscriber dials this invalid number, then the call traverses the Proxy CSCF and hits the S-CSCF. I am assuming that it is an intra IMS domain call – synonymous to a local call. Here the called party (B-party) is the invalid subscriber. The S-CSCF executes the originating iFC set for the calling party as per the standards. Then, the S-CSCF realizes that the called party address is a tel URI and an ENUM query needs to be performed. As the subscriber has been de-provisioned from the network completely, the ENUM query fails.

This triggers the S-CSCF to forward the call to BGCF believing that legacy interconnect procedures need to be performed and the called party is a legacy subscriber. The BGCF attempts breakout towards the MGCF, which converts it to an IAM and sends it to the PSTN.

The situation would become even more complex with number portability, where we can no longer filter numbers based on ranges alone at the BGCF.

The PSTN domain would send it back to the IMS core thinking that the call was destined towards IMS. As inter-working will take place again at the MGCF for the incoming call leg, this call would land as a brand new call to the I-CSCF (with a refreshed Max-Forwards header) and a new Call-id.

Now, the I-CSCF will perform the DIAMETER user location query to the HSS and this query would fail, as the tel uri never existed in the first place. Based on the procedures in TS 24.229, the I-CSCF will inspect the address (which is the tel URI) and then perform the ENUM query. This query would fail as expected and the call will be forwarded to the BGCF once more mistaking it to the legacy interconnect case.

The sequence of events above would lead to an infinite loop in the network for this call.

Solution:

The solution to this problem is to avoid the breakout to the PSTN through the BGCF in case the user has dialed an invalid number. In order for this to happen, the ENUM query must not fail. Hence, it is proposed that when the user is de-provisioned from the network, the ENUM mapping of his number is changed to a generic SIP URI such as the following –

sip:doesnotexist@domain

This will ensure that this generic SIP URI is returned when the ENUM query is fired. In this case, the S-CSCF will forward the call to the I-CSCF instead of the BGCF. The I-CSCF will then forward the call to the MRFC by executing PSI subdomain routing in the sense of TS 23.228.

This would ensure that the MRF will play an announcement that the “number does not exist”. This is what is needed in this scenario. But, even here, the I-CSCF needs to do some NETANN magic before forwarding the call to the MRF (refer here: http://tools.ietf.org/html/rfc4240). Hence, the I-CSCF implementation has to be careful to make this work well.

 

As and when I come across more race conditions in the IMS network, I will post them here (most probably with a possible solution to get around them).

 

Posted in HSS, I-CSCF, IMS, IMS data, IMS procedures, IMS Release 11 | Tagged: , , , , , , | Leave a Comment »