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 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 can contain several conditions called Service Point Trigger (SPT). The conditions can be related to:
- SIP Method
- SIP Header
- Session Case
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:
Group1(SPT OR SPT OR SPT) AND Group2(SPT) AND Group3(SPT OR SPT)
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:
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 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.
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.
different between session case 0 and session case 1??why default handling in 0??
Have you read the article? The Session Case class represents an enumerated type, with possible values “Originating”, “Terminating_Registered”, “Terminating_Unregistered”, “Originating_Unregistered”, “Originating_CDIV”. And well, one value is default … just matter of choice