iFC Trigger Principle

Page 1 of 3

iFC Trigger Principle

Basic Concepts

Contacting the AS Based on the iFC

Basic flow

When the S-CSCF receives an initial service request, it sorts all iFCs in the service profile in descending order according to their priority and matches the received request with iFCs. If
a match is found, the S-CSCF contacts an AS based on the AS address in the iFC, and the AS provides the supplementary services for the subscriber. This section describes iFC
triggering in a call flow. iFC triggering in the third-party registration flow is not described here.

Basic Concepts

Session association: The S-CSCF adds its address and the ORGDLGID parameter to the Route header field of an INVITE message and then sends the message to the AS. After
the AS triggers services, it forwards the INVITE message to the S-CSCF. In the INVITE message, the ORGDLGID parameter in the Route header field is the same as that in the
Route header field of the INVITE message sent from the S-CSCF to the AS. In this way, the S-CSCF learns that the INVITE message sent from the AS is within the same session
as the one it previously sent. This procedure is called session association. When the S-CSCF receives an INVITE message from the AS in session association mode, it contacts
another AS based on the next iFC.
NOTE:
When the AS forwards an INVITE message to the S-CSCF in non-session association mode, it deletes the ORGDLGID parameter, the S-CSCF obtains the service profile again
for iFC triggering. This may result in repeated service triggering. To prevent repeated service triggering, the AS adds certain header fields to the INVITE message.

iFC termination: The S-CSCF does not perform triggering based on the iFC.
iFC termination applies to the following scenarios:


The S-CSCF receives an initial INVITE message and performs iFC triggering in descending order according to the iFC priority. After the S-CSCF processes the iFC of the
lowest priority, iFC termination applies. iFC triggering will not be performed for subsequent messages.

When the terminating AS forwards an INVITE message to the S-CSCF in session association mode and the called number in the Request-URI of the INVITE message is
changed, the S-CSCF determines that a call forwarding occurs based on the SCFRCG (Call Forward Recognition for S-CSCF) table, which is defined by running ADD
SCFRCG. In this case, iFC termination applies.
NOTE:
If the called number in the Request-URI is changed from a tel URI to a SIP URI containing the user=phone, the S-CSCF, by default, does not regard the situation as call
forwarding based on the SCFRCG table.

Contacting the AS Based on the iFC

Contacting the AS based on the iFC includes contacting the AS during registration and contacting the AS during the call.
Figure 1 shows how the AS is contacted during registration.
Figure 1 Contacting the AS during registration

Figure 2 shows how the AS is contacted (for example, on the originating side) during the call.
Figure 2 Contacting the AS during the call

Basic flow
This section uses the Multi-ringing service in simultaneous ringing mode as an example to describe the basic flow of iFC triggering. Message exchanges over ISC interfaces are
described, and the P-CSCF and I-CSCF are omitted in the flow. For details, see Figure 3.
Figure 3 Basic flow of iFC triggering

http://127.0.0.1:52199/hedex/pages/31186470/01/31186470/01/resources/User_Manual/i...

11/11/2013

iFC Trigger Principle

Page 2 of 3

In this example, UE_A, UE_B, and UE_C have registered with the IMS network, UE_B has subscribed to the Multi-ringing service in simultaneous ringing mode, and UE_C is on
UE_B's association number list. The service profiles of UE_A, UE_B, and UE_C contain two iFCs with the priority 110 and 144. The key contents of the two iFCs are as follows:
<InitialFilterCriteria>
<Priority>110</Priority>
/*The priority is 110.*/
<TriggerPoint>
<ConditionTypeCNF>1</ConditionTypeCNF>
/*The inter-group relationship is OR, and the intra-group releationship is AND.*/
<SPT>
/*A <SPT></SPT> tag represents a trigger condition in a condition group.*/
<ConditionNegated>0</ConditionNegated>
/*The SPT instance is not negated.*/
<Group>0</Group>
/*The group number is 0.*/
<SessionCase>0</SessionCase>
/*The S-CSCF is serving the calling party who is registered with the network.*/
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
/*The SPT instance is not negated.*/
<Group>0</Group>
/*The group number is 0.*/
<SessionCase>3</SessionCase>
/*The S-CSCF is serving the calling party who is not registered with the network.*/
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
/*The SPT instance is not negated.*/
<Group>1</Group>
/*The group number is 1.*/
<Method>INVITE</Method>
/*The SIP Method is INVITE.*/
</SPT>
<SPT>
<ConditionNegated>1</ConditionNegated>
/*The SPT instance is negated.*/
<Group>2</Group>
/*The group number is 2.*/
<SIPHeader>
<Header>P-Access-Network-Info</Header>
<Content>.*3POC.*</Content>
/*The P-Access-Network-Info header field includes 3POC.*/
</SIPHeader>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:as.home.com;orig</ServerName>
<DefaultHandling>0</DefaultHandling>
<ServiceInfo>AS</ServiceInfo>
</ApplicationServer>
<ProfilePartIndicator>0</ProfilePartIndicator>
</InitialFilterCriteria>
<InitialFilterCriteria>
<Priority>144</Priority>
<TriggerPoint>
<ConditionTypeCNF>1</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
/*The SPT instance is not negated.*/
<Group>0</Group>
/*The group number is 0.*/
<SessionCase>1</SessionCase>
/*The S-CSCF is serving the called party who is registered with the network.*/
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
/*The SPT instance is not negated.*/
<Group>0</Group>
/*The group number is 0.*/
<SessionCase>2</SessionCase>
/*The S-CSCF is serving the called party who is not registered with the network.*/
</SPT>
<SPT>
<ConditionNegated>0</ConditionNegated>
/*The SPT instance is not negated.*/
<Group>1</Group>
/*The group number is 1.*/
<Method>INVITE</Method>
/*The SIP Method is INVITE.*/
</SPT>
<SPT>
e
<ConditionNegated>1</ConditionNegated>
/*The SPT instance not negated.*/
<Group>2</Group>
/*The group number is 2.*/
<SIPHeader>
<Header>P-Access-Network-Info</Header>
<Content>.*3PTC.*</Content>
/*The P-Access-Network-Info header field includes 3PTC.*/
</SIPHeader>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:as.home.com</ServerName>
<DefaultHandling>0</DefaultHandling>
<ServiceInfo>AS</ServiceInfo>
</ApplicationServer>
<ProfilePartIndicator>0</ProfilePartIndicator>
</InitialFilterCriteria>
In the iFC whose priority is 110, the key parameters are set as follows:

SessionCase is 0 or 3.

SIP Method is INVITE.

http://127.0.0.1:52199/hedex/pages/31186470/01/31186470/01/resources/User_Manual/i...

11/11/2013

iFC Trigger Principle

Page 3 of 3

The P-Access-Network-Info header field does not contain 3POC.

In the iFC whose priority is 144, the key parameters are set as follows:

SessionCase is 1 or 2.

SIP Method is INVITE.

The P-Access-Network-Info header field does not contain 3PTC.

The flow is as follows:

1: UE_A calls UE_B. An INVITE message is sent to the originating S-CSCF. The key field in the INVITE message is as follows:
P-Access-Network-Info: IEEE-802.11;"location-info=164.132.176.2"
2. When the originating S-CSCF receives the INVITE message, it sorts the iFCs in UE_A's service profile in descending order according to the iFC priority and matches the INVITE
message with the iFCs. The originating S-CSCF first matches the INVITE message with the iFC whose priority is 110. After the originating S-CSCF determines that a match is found, it
adds the Server Name (included in the iFC whose priority is 110), the S-CSCF address, and the ORGDLGID parameter to the Route header field and sends the INVITE message to
the originating AS. The key fields in the INVITE message are as follows:
Route: <sip:as.home.com;orig;lr>,<sip:scscf.home.com;lr;ORGDLGID=2689-1;Dpt=75e4_6;TRC=ffffffff-ffffffff>
P-Access-Network-Info: IEEE-802.11;"location-info=164.132.176.2"
3: When the originating AS receives the INVITE message, it processes UE_A's service and forwards the INVITE message to the originating S-CSCF in session association mode. The
key fields in the INVITE message are as follows:
P-Access-Network-Info: IEEE-802.11;"location-info=164.132.176.2"
Route: <sip:scscf.home.com;lr;ORGDLGID=2689-1;Dpt=75e4_6;TRC=ffffffff-ffffffff>
4: When the originating S-CSCF receives the INVITE message, it matches the INVITE message with the iFC whose priority is 144. After the originating S-CSCF determines that a
match is not found, it applies iFC termination and routes the call to the IMS network where UE_B is located. The key field in the INVITE message is as follows:
P-Access-Network-Info: IEEE-802.11;"location-info=164.132.176.2"
5. When the terminating S-CSCF receives the INVITE message, it sorts the iFCs in UE_B's service profile in descending order according to the iFC priority, and matches the INVITE
message with the iFCs. The terminating S-CSCF first matches the INVITE message with the iFC whose priority is 110. After the terminating S-CSCF determines that a match is not
found, it then matches the iFC whose priority is 144 and determines that a match is found. The terminating S-CSCF adds the Server Name (included in the iFC whose priority is 144),
the S-CSCF address, and the ORGDLGID parameter to the Route header field and sends the INVITE message to the terminating AS. The key fields in the INVITE message are as
follows:
Route: <sip:as.home.com;lr>,<sip:scscf.home.com;lr;ORGDLGID=2691-1;Dpt=75e4_6;TRC=ffffffff-ffffffff>
P-Access-Network-Info: IEEE-802.11;"location-info=164.132.176.2"
6: When the terminating AS receives the INVITE message, it triggers the Multi-ringing service in simultaneous ringing mode for UE_B and forwards the INVITE message to the
terminating S-CSCF. The key fields in the INVITE message are as follows:
Route: <sip:scscf.home.com;lr;ORGDLGID=2691-1;Dpt=75e4_6;TRC=ffffffff-ffffffff>
P-Access-Network-Info: IEEE-802.11;"location-info=164.132.176.2"
7: The terminating S-CSCF receives the INVITE message forwarded in session association mode and determines that call forwarding is not required. After all the iFCs in UE_B's
service profile are triggered, the terminating S-CSCF routes the call to UE_B.
8: The terminating AS initiates a call to UE_C. An INVITE message is sent to the terminating S-CSCF. The key fields in the INVITE message are as follows:
Route: <sip:scscf.home.com;lr>
P-Access-Network-Info: 3PTC
9. When the terminating S-CSCF receives the INVITE message, it sorts the iFCs in UE_C's service profile in descending order according to the iFC priority, and matches the INVITE
message with the iFCs. The terminating S-CSCF first matches the INVITE message with the iFC whose priority is 110. After the terminating S-CSCF determines that a match is not
found, it then matches the iFC whose priority is 144 and determines that a match is not found. After all iFCs in UE_C's service profile are triggered, the terminating S-CSCF applies iFC
termination and routes the call to UE_C.
Parent topic: Trigger Principle

Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

http://127.0.0.1:52199/hedex/pages/31186470/01/31186470/01/resources/User_Manual/i...

11/11/2013