Initial Filter Criteria (iFC) is the mechanism used by the IMS to invoke Application Servers. It applies to SIP initial requests.

Sentinel VoLTE defines various Route Header Parameters such that the iFC can select specific behaviour from the Sentinel VoLTE applications.

For example, SCC or MMTel functionality, or influencing the T-ADS routing mode are selected through the use of Route Header Parameters.

Requirements for Sentinel VoLTE iFC

The iFC requirements can be met through various different iFC configurations. The purpose of this section is to cover the requirements.

Registered and Un-Registered Service Point Triggers

Both the MMTel and SCC require INVITE processing for originating, terminating, and the registered and un-registered cases. There are not any particular headers that are able to be used to "narrow" which INVITEs the SCC or MMTel receive such that they are triggered in certain cases only (unlike e.g. a voice-mail service that is only triggered on terminating INVITEs to a PSI).

Session Case Consumers of case

Originating Registered

SCC Originating Signalling Anchor for access transfer, MMTel Originating Features

Originating Un-Registered

MMTel Originating Features in case of and unregistered originating party. This is typical when using IMS centralised services without I2. I.e. a non IMS-registered user making an outgoing Circuit Switched call that is routed into the IMS for service control.

Terminating Registered

SCC Terminating Signalling Anchor for access transfer, SCC T-ADS, MMTel Terminating Features

Terminating Un-Registered

SCC T-ADS, MMTel Terminating features (e.g CDIV Not Logged In)

INVITE trigger chaining

VoLTE calls can be processed sequentially by both the MMTel-AS and SCC-AS with INVITE iFC chaining. iFCs are chained together by associating the same Trigger Point (group of one or more SPTs) with multiple AS in a specific order.

The SCC-AS must be the first SIP-AS in the originating iFC trigger chain and last in the terminating iFC trigger chain. I.e it "wraps" the other SIP-AS nodes, and is the "closest" AS to the served UE. Therefore it directly observes the true SIP Dialog Identifier used between the IMS core and the served UE.

Third Party Registration Service Point Triggers

SCC-AS requires third party registration, as both eSRVCC and T-ADS functionality need access to (for example) the IMS private identity. MMTel-AS also requires third party registration so that it can access the default IMS public identity.

Typically the SCC-AS and MMTel-AS are co-located on the same TAS. In this case, there must be only one Third Party Registration request sent to the TAS. The TAS then performs appropriate logic for the MMTel and SCC functions based on the single request. Multiple distinct Third Party Registration requests should only be sent to the SCC-AS and MMTel-AS when the functions are not co-located on the same TAS.

Registration Case Consumers of case Needs first party registration content

Initial Registration

SCC for eSRVCC registration and T-ADS. MMTel for default public identity.

Both first-party request and response

Re-registration

SCC for eSRVCC re-registration and T-ADS (e.g. P-Access-Network-Info). MMTel to refresh its registration data.

Both first-party request and response

De-registration

SCC and MMTel to clean up registration state database

Both first-party request and response
Note Depending on your HSS, the configuration for including first-party request and response messages could be on the iFC or the associated AS.

MMTel Conferencing Service Point Triggers

MMTel Conferencing requires that the Conference Focus has a URI termed the Conference Factory Public Service Identity, or Conference Factory PSI for short.

Both Invites and Subscriptions to the Conference Factory PSI are implemented at the Conference Focus within the MMTel-AS.

Therefore the iFC for Conferencing needs to ensure that SIP SUBSCRIBE and INVITE sessions where the Request URI host part matches the host part of the Conference Factory PSI trigger the MMTel-AS.

Trigger examples

Due to the nature of the iFC XML, and that Method and SessionCase elements are part of a choice (meaning one or the other can be specified inside an SPT) sometimes logical OR is used for different SPT elements inside a Trigger, and sometimes logical AND is used.

SCC-AS INVITE Trigger

The following XML fragment shows the use a single Trigger element to capture the various INVITE cases for the SCC-AS.

<?xml version="1.0"?>

<!-- this is a snippet of an iFC showing only the Trigger elements
     necessary for SCC-AS INVITE processing -->

<!-- An example of INVITE trigger point for SCC-AS -->
<TriggerPoint>
    <!-- ConditionTypeCNF 0 means logical AND of SPT elements in the same group
         ConditionTypeCNF 1 means logical OR of SPT elements the same group
         See TS 29.228 for Conjunctive Normal Form vs Disjunctive Normal Form
         SPT elements in different groups are AND'd together
         -->
    <ConditionTypeCNF>1</ConditionTypeCNF>

    <!-- logically the statement is
         INVITE AND (ORIGINATING_REGISTERED OR TERMINATING_REGISTERED OR TERMINATING_UNREGISTERED)
        -->
    <SPT>
        <Group>0</Group>
        <Method>INVITE</Method>
    </SPT>
    <SPT>
        <Group>1</Group>
        <SessionCase>0</SessionCase><!-- ORIGINATING_REGISTERED -->
    </SPT>
    <SPT>
        <Group>1</Group>
        <SessionCase>1</SessionCase><!-- TERMINATING_REGISTERED -->
    </SPT>
    <SPT>
        <Group>1</Group>
        <SessionCase>2</SessionCase><!-- TERMINATING_UNREGISTERED -->
    </SPT>
</TriggerPoint>

SCC-AS Third Party Register Trigger

The following XML fragment shows the use of a Trigger element that includes all three cases of Third Party registration.

<?xml version="1.0"?>

<!-- this is a snippet of an iFC showing only the Trigger element
      necessary for Third Party Registration -->

<!-- Initial Register OR Re-register OR de-register -->
<TriggerPoint>
    <!-- there is only a single SPT so ConditionTypeCNF is not important
         yet it is a mandatory element so it is here as 1-->
    <ConditionTypeCNF>1</ConditionTypeCNF>
    <!-- Register, re-register and de-register -->
    <SPT>
        <Group>4</Group>
        <Method>REGISTER</Method>
    </SPT>
    <Extension>
        <RegistrationType>0</RegistrationType> <!-- INITIAL_REGISTRATION -->
        <RegistrationType>1</RegistrationType> <!-- RE_REGISTRATION -->
        <RegistrationType>2</RegistrationType> <!-- DE_REGISTRATION -->
    </Extension>

</TriggerPoint>

MMTel-AS INVITE Trigger

The following XML fragment shows the use of a single Trigger element to invoke the MMTel-AS for all INVITE sessions except those going to voicemail.

<?xml version="1.0"?>

<!-- this is a snippet of an iFC showing only the Trigger elements
     necessary for MMTel-AS INVITE processing -->

<!-- An example of INVITE trigger point for MMTel-AS excluding voicemail
     All MMTel services will be served on the same AS here -->
<TriggerPoint>
    <!-- ConditionTypeCNF 0 means logical AND of SPT elements in the same group
         ConditionTypeCNF 1 means logical OR of SPT elements the same group
         See TS 29.228 for Conjunctive Normal Form vs Disjunctive Normal Form
         SPT elements in different groups are OR'd togethered
         -->
    <ConditionTypeCNF>1</ConditionTypeCNF>

    <!-- MMTel needs INVITEs for all SessionCases
         Voicemail is often not implemented on the same MMTel-AS platform
         Therefore exclude the voicemail AS, assuming it has a URI of voicemail.example.com
         Logically this is INVITE AND NOT (RequestURI equals voicemail.example.com)
        -->
    <SPT>
        <Group>0</Group>
        <Method>INVITE</Method>
    </SPT>
    <SPT>
        <ConditionNegated>1</ConditionNegated> <!-- Use ConditionNegated to exclude the RequestURI -->
        <Group>2</Group>
        <RequestURI>voicemail.example.com</RequestURI>
    </SPT>
</TriggerPoint>

MMTel-AS SUBSCRIBE Trigger

The following XML fragment shows the use of a Trigger element to invoke the MMTel-AS for subscriptions to the Conference Factory PSI.

<?xml version="1.0"?>

<!-- this is a snippet of an iFC showing only the Trigger for
     subscriptions to the Conf Factory PSI -->

<TriggerPoint>
    <!-- ConditionTypeCNF 0 means logical AND of SPT elements in the same group
         ConditionTypeCNF 1 means logical OR of SPT elements the same group
         See TS 29.228 for Conjunctive Normal Form vs Disjunctive Normal Form
         SPT elements in different groups are OR'd togethered
         -->
    <ConditionTypeCNF>1</ConditionTypeCNF>

    <!--
         Logically this is SUBSCRIBE AND (RequestURI host part equals conf.example.com)
        -->
    <SPT>
        <Group>0</Group>
        <Method>SUBSCRIBE</Method>
    </SPT>
    <SPT>
        <Group>1</Group>
        <RequestURI>conf.example.com</RequestURI>
    </SPT>
</TriggerPoint>

Recommendations for Application Server element

An iFC document joins an Application Server and zero or more Trigger Point elements. Each Trigger Point element includes one or more Service Trigger Points (SPTs). These are discussed above.

This section discusses recommendations for the Application Server section.

Use a TCP transport

The default SIP transport mechanism for AS communication is UDP. TCP can be specified by appending ;transport=tcp to the configured AS URI.

AS functional separation

One Sentinel VoLTE TAS instance can handle both SCC-AS and MMTel-AS roles. However it is possible to logically separate the roles onto their own instance or node. This can be useful for non-functional reasons such as sizing, or functional reasons such as debugging.

This is achieved with the oc-mode parameter as part of the AS URI. The mmtel oc-mode handles MMTel and Conferencing. Conferencing traffic can be diverted to its own node via iFC association.

For example, to split MMTel, SCC and MMTel-Conferencing traffic on such that they are on distinct ports 5060, 5070 and 5080.

Role AS URI Associated TP / iFC

MMTel

sip:<volte-tas-address>:5060;transport=tcp;oc-mode=mmtel

MMTel iFCs

SCC

sip:<volte-tas-address>:5070;transport=tcp;oc-mode=scc

SCC iFCs

MMTel-Conferencing

sip:<volte-tas-address>:5080;transport=tcp;oc-mode=mmtel

Conf iFC

For each configured AS it is possible to assign further specific functions through the use of Route Header Parameters

iFC examples

These examples provide a full initial filter criteria including TriggerPoint and ApplicationServer elements.

SCC-AS INVITE

The SCC-AS is invoked in three INVITE cases

  1. originating

  2. terminating registered

  3. terminating un-registered

These can be shown in a single iFC for the INVITE case

<?xml version="1.0"?>
<InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
        <!-- ConditionTypeCNF 0 means logical AND of SPT elements in the same group
             ConditionTypeCNF 1 means logical OR of SPT elements the same group
             See TS 29.228 for Conjunctive Normal Form vs Disjunctive Normal Form
             SPT elements in different groups are AND'd together
             -->
        <ConditionTypeCNF>1</ConditionTypeCNF>

        <!-- logically the statement is
             INVITE AND (ORIGINATING_REGISTERED OR TERMINATING_REGISTERED OR TERMINATING_UNREGISTERED) AND NOT (Recv-Info Header equals 'g.3gpp.ussd')
            -->
        <SPT>
            <Group>0</Group>
            <Method>INVITE</Method>
        </SPT>
        <SPT>
            <Group>1</Group>
            <SessionCase>0</SessionCase><!-- ORIGINATING_REGISTERED -->
        </SPT>
        <SPT>
            <Group>1</Group>
            <SessionCase>1</SessionCase><!-- TERMINATING_REGISTERED -->
        </SPT>
        <SPT>
            <Group>1</Group>
            <SessionCase>2</SessionCase><!-- TERMINATING_UNREGISTERED -->
        </SPT>
        <SPT>
            <ConditionNegated>1</ConditionNegated>
            <Group>2</Group>
            <SIPHeader>
                <Header>Recv-Info</Header>
                <Content>g.3gpp.ussd</Content>
            </SIPHeader>
            <Extension/>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <ServerName>sip:scc-as.domain.name:5060;transport=tcp;oc-mode=scc</ServerName>
        <DefaultHandling>1</DefaultHandling>
        <Extension>
            <IncludeRegisterRequest/>
            <IncludeRegisterResponse/>
        </Extension>
    </ApplicationServer>
</InitialFilterCriteria>

MMTel-AS INVITE

An example showing the iFC for an MMTel-AS for INVITE requests is below.

<?xml version="1.0"?>
<InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
        <!-- ConditionTypeCNF 0 means logical AND of SPT elements in the same group
             ConditionTypeCNF 1 means logical OR of SPT elements the same group
             See TS 29.228 for Conjunctive Normal Form vs Disjunctive Normal Form
             SPT elements in different groups are AND'd together
             -->
        <ConditionTypeCNF>1</ConditionTypeCNF>

        <!-- MMTel needs INVITEs for all SessionCases
             Voicemail is often not implemented on the same MMTel-AS platform
             Therefore exclude the voicemail AS, assuming it has a URI of voicemail.example.com
             Logically this is INVITE AND NOT (RequestURI equals voicemail.example.com) AND NOT (Recv-Info Header equals 'g.3gpp.ussd')
            -->
        <SPT>
            <Group>0</Group>
            <Method>INVITE</Method>
        </SPT>
        <SPT>
            <ConditionNegated>1</ConditionNegated> <!-- Use ConditionNegated to exclude the RequestURI -->
            <Group>2</Group>
            <RequestURI>voicemail.example.com</RequestURI>
        </SPT>
        <SPT>
            <ConditionNegated>1</ConditionNegated>
            <Group>3</Group>
            <SIPHeader>
                <Header>Recv-Info</Header>
                <Content>g.3gpp.ussd</Content>
            </SIPHeader>
            <Extension/>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <ServerName>sip:mmtel-as.domain.name:5060;transport=tcp;oc-mode=mmtel</ServerName>
        <DefaultHandling>1</DefaultHandling>
        <Extension>
            <IncludeRegisterRequest/>
            <IncludeRegisterResponse/>
        </Extension>
    </ApplicationServer>
</InitialFilterCriteria>

Note: if the MMTel-AS will run the MMTel-Conferencing feature (ie. not the discrete conferencing example) then the iFC needs to also include SUBSCRIBE requests where the RequestURI matches the host name part of the conference factory PSI.

MMTel-AS SUBSCRIBE

If the MMTel-AS is running the MMTel-Conferencing feature, rather than a discrete MMTel-Conferencing AS node, then the MMTel-AS needs to receive SUBSCRIBE requests for the Conference Factory PSI.

An example is shown

<?xml version="1.0"?>
<InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
        <!-- ConditionTypeCNF 0 means logical AND of SPT elements in the same group
        ConditionTypeCNF 1 means logical OR of SPT elements the same group
        See TS 29.228 for Conjunctive Normal Form vs Disjunctive Normal Form
        SPT elements in different groups are OR'd togethered
         -->
        <ConditionTypeCNF>1</ConditionTypeCNF>
        <!--
         Logically this is SUBSCRIBE AND (RequestURI host part equals conf.example.com)
         -->
        <SPT>
            <Group>0</Group>
            <Method>SUBSCRIBE</Method>
        </SPT>
        <SPT>
            <Group>1</Group>
            <RequestURI>conf.example.com</RequestURI>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <ServerName>sip:mmtel-as.domain.name:5060;transport=tcp;oc-mode=mmtel</ServerName>
        <DefaultHandling>1</DefaultHandling>
        <Extension>
            <IncludeRegisterRequest/>
            <IncludeRegisterResponse/>
        </Extension>
    </ApplicationServer>
</InitialFilterCriteria>

Third Party Registration example

The following example adds triggers for REGISTER request, for:

  • initial registration

  • re-registration

  • de-registration

When sending the third-party register request, both the first party register request and response are included.

<?xml version="1.0"?>
<!-- sip registration IFC -->
<InitialFilterCriteria>
    <Priority>1</Priority>

    <!-- Initial Register OR Re-register OR de-register -->
    <TriggerPoint>
        <!-- there are three SPTs, and we want OR, so ConditionTypeCNF 1 -->
        <ConditionTypeCNF>1</ConditionTypeCNF>

        <!-- Register -->
        <SPT>
            <Group>0</Group>
            <Method>REGISTER</Method>
            <Extension>
                <RegistrationType>0</RegistrationType> <!-- INITIAL_REGISTRATION -->
            </Extension>
        </SPT>

        <!-- re-register -->
        <SPT>
            <Group>0</Group>
            <Method>REGISTER</Method>
            <Extension>
                <RegistrationType>1</RegistrationType> <!-- RE_REGISTRATION -->
            </Extension>
        </SPT>

        <!-- de-register -->
        <SPT>
            <Group>0</Group>
            <Method>REGISTER</Method>
            <Extension>
                <RegistrationType>2</RegistrationType> <!-- DE_REGISTRATION -->
            </Extension>
        </SPT>

    </TriggerPoint>
    <ApplicationServer>
        <ServerName>sip:third-party-registrar:5060;transport=tcp</ServerName>
        <DefaultHandling>0</DefaultHandling>
        <Extension>
            <IncludeRegisterRequest/>
            <IncludeRegisterResponse/>
        </Extension>
    </ApplicationServer>
</InitialFilterCriteria>

Discrete Conferencing Example

Sentinel VoLTE implements many MMTel Services, including MMTel Conferencing. It may be useful to configure the Conference as a different set of VMs than the rest of MMTel, for example for sizing reasons.

If so, this iFC for conferencing can be defined.

<?xml version="1.0"?>
<!-- Conferencing IFC
    MMTel Conferencing requires SUBSCRIBE and INVITE requests to the
    Conference Factory PSI
-->
<InitialFilterCriteria>
    <Priority>2</Priority>

    <!-- Logically (INVITE OR SUBSCRIBE) AND (RequestURI host part equals conf.example.com) AND Terminating Unregistered
     -->
    <TriggerPoint>
        <ConditionTypeCNF>1</ConditionTypeCNF>
        <SPT>
            <Group>0</Group>
            <Method>INVITE</Method>
        </SPT>
        <SPT>
            <Group>0</Group>
            <Method>SUBSCRIBE</Method>
        </SPT>
        <SPT>
            <Group>1</Group>
            <RequestURI>conf.example.com</RequestURI>
        </SPT>
        <SPT>
            <Group>2</Group>
            <SessionCase>2</SessionCase> <!-- Terminating Unregistered -->
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <ServerName>sip:conf-as.example.com:5060;transport=tcp;oc-mode=mmtel</ServerName>
        <DefaultHandling>0</DefaultHandling>
    </ApplicationServer>
</InitialFilterCriteria>

Note: if MMTel-Conferencing is provided on a different node, then the Conference Factory PSI should be excluded from the MMTel-AS Trigger.

Excluding services

There are cases where there are services that are not implemented on a particular SIP-AS. If there are no other distinguishing characteristics of the INVITE (such as for MMTel) then any Public Service Identifiers for services that are not implemented on the MMTel-AS should be excluded. If there are distinguishing characteristics, such as a unique SIP header, these can be used for exclusion.

  • Example - Voicemail AS

Add a negated condition specifying a Service Point Trigger where the URI is the host-part of the PSI for the VoiceMail service. An example is shown below.

    <SPT>
      <ConditionNegated>1</ConditionNegated>
      <Group>3</Group>
      <RequestURI>voicemail.example.com</RequestURI>
    </SPT>

  • Example - USSI AS

Sentinel VoLTE does not implement the role of a USSI Application Server. As USSD over IMS requests are signalled using SIP INVITE, and MMTel and SCC AS are signalled using INVITE, a negated condition is added to the iFC for Sentinel VoLTE. USSI INVITE requests contain a Recv-Info header with the value g.3gpp.ussd.

An example is shown below.

    <SPT>
       <ConditionNegated>1</ConditionNegated>
       <Group>4</Group>
       <SIPHeader>
           <Header>Recv-Info</Header>
           <Content>g.3gpp.ussd</Content>
       </SIPHeader>
       <Extension/>
   </SPT>

Note: each excluded service should be in a Group that is independent of the other groups. This is because SPTs in different groups are AND’ed together.

Previous page Next page
Sentinel VoLTE Version 4.1