How to read Initial Filter Criteria

There are hunters and there are gatherers. My wife she is a gatherer. When she goes shopping, she is gathering (and bet that it requires some time 🙂 ). I hate it, I’m hunting. I need to have a clear goal. A list of things I have to buy. It doesn’t need to be on paper, but I need to know. As a gatherer I’m lost and I always forget something.

In IMS most of the network elements work as state machines. Some of their logic is based on the configuration, some is stored in databases (HSS, DNS). This is also the case of Initial Filter Criteria. Simply said the S-CSCF has a list which tells it what messages forward to what application servers.

IFCs are described in the 3GPP TS 29.228, Annex B. As you probably know (Registration, 3rd Party Registration, HSS-FE), during the registration S-CSCF retrieves in the SAA message from HSS the Subscriber profile.  The profile itself is an XML document which contains information about the user’s identities and also a set of routing rules – IFCs. Note it is also possible to configure iFCs directly on S-CSCF and transfer only id (Shared IFC).

IMSSubscription

 

 

We can understand IFC as a rule. It contains Priority, Trigger Point and Application Server. Trigger Point is a set of conditions and Application Server is an action. The S-CSCF is evaluating IFCs based on priority (0 is the highest priority) and if the Trigger Point – condition – is fulfilled, than the Application Server – action – is applied. More IFCs can match one message.

IFC

For example a Trigger Point contains a condition as:

message is SIP INVITE   AND   SDP contains (audio OR video)  AND   it is ORIGINATING message

then the action is

send message to TAS.ims.operator.com and add 'orig' tag into the Route header.

So anytime the S-CSCF gets a  message from Originator, if it is an invitation to audio or video call, the message is forwarded to TAS to apply the originating services.

Trigger point

Trigger Point

 

Trigger point can contain several conditions called Service Point Trigger (SPT).  The conditions can be related to:

• Request-URI
• SIP Method
• SIP Header
• Session Case
• SDP

Most of the SPTs are self-explaining. The Session Case class represents an enumerated type, with possible values “Originating”, “Terminating_Registered”, “Terminating_Unregistered”, “Originating_Unregistered”, “Originating_CDIV”.

If you are following carefully, you noticed two things. Firstly the Trigger Point has an attribute ConditionTypeCNF. And also that each SPT contains an attribute Group.

The CNF means Conjunctive Normal Form (ConditionTypeCNF set to 1). If the value is set to 0 it means Disjunctive Normal Form (DNF). These forms are defining what logical operators should be used between SPTs belonging to different groups.

CNF – all conditions has to be fulfilled:

SPT AND SPT AND SPT

DNF – at least one condition has to be fulfilled:

SPT OR SPT OR SPT

 

But what if the Group id is same for two or more SPTs? Then we will use the other operator within the group:

CNF:

Group1(SPT OR SPT OR SPT) AND Group2(SPT) AND Group3(SPT OR SPT)

DNF:

Group1(SPT AND SPT AND SPT) OR Group2(SPT) OR Group3(SPT AND SPT)

 

The reason why we use CNF or DNF is that in this notation we are able to write any logical condition and easily save it in XML format. Also with help of negation we are able to create for each condition in CNF a compatible one in DNF and vice versa (using De Morgan’s laws). Which form you’ll pick is up to you. Hint – our brains (and computers as well) are much better in solving of positive conditions than negative ones.

The XML for the example above would look like:

IFC XML

We would evaluate it:

1(SDP m line audio OR video) AND 3(SIP method INVITE) AND 4(ORIGINATING)    => Route: <sip: tas.volte.operator.com;orig>

SIP Headers and SDP can include a regular expression in a form of Extended Regular Expressions (ERE) as defined in chapter 9 in IEEE 1003.

Application Server

Application Server more or less says what application server shall be triggered by S-CSCF, if the Trigger Points are met. Server Name is the SIP URL of the application server to contact. Most of the time it is a general FQDN and the site specific address is retrieved from DNS (more in 3rd party registration).

Default Handling determines whether we should continue or if the dialog should be released in case the Application Server could not be reached. The values are SESSION_CONTINUED or SESSION_TERMINATED. For example if we can’t do a 3rd party registration towards TAS, the user can be deregistred  from the network.

Application Server

The Service Information class allows to convey some information to an Application Server. The 3GPP TS 23.218 describes  the use of this information element in more detail.