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





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.



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


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:


DNF – at least one condition has to be fulfilled:



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






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:



We would evaluate it:

1(SDP m line audio OR video) AND 3(SIP method INVITE) AND 4(ORIGINATING)    => Route: <sip:;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

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.


6 thoughts on “How to read Initial Filter Criteria

  1. Pingback: Much Ado about Registration | Real Time Communication

  2. Pingback: How to read tcpdump – Registration | Real Time Communication

  3. Pingback: VoLTE Illustrated: Beginners Guide | Real Time Communication

  4. Pingback: IP-SM-GW Transport Level Interworking | Real Time Communication

  5. Pingback: Third party registration | Real Time Communication

  6. Pingback: IMS Centralized Services – Overview | Real Time Communication

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s