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

Requirements for Sentinel IP-SM-GW

The Sentinel IP-SM-GW receives Third Party Registration and SIP MESSAGE requests. In particular the SIP MESSAGE requests contain SMS RP-DATA level information encapsulated in the body of the SIP MESSAGE request.

The IP-SM-GW receives SIP MESSAGE requests where the addressing requirements for those SIP MESSAGE requests are standardised in 3GPP TS 24.341. The addressing for these messages provides the requirements for the iFC configuration.

These are:

  1. Submitting a short message - the Request-URI uses the Public Service Identity of the Service Centre of the SM-over-IP sender.

  2. Sending a notification about SM-over-IP receiver having memory available - the Request URI which shall contain the IP-SM-GW address, if available, and shall contain PSI of the SC otherwise.

  3. Sending a delivery report - the Request-URI is set to the received P-Asserted-Identity in the received SIP MESSAGE request including the delivered short message.

This means that there is:

  1. One PSI for each Service Centre - that can include an AS name that resolves (via DNS) to any IP-SM-GW cluster node that represents the Service Centre.

  2. One PSI for each cluster node - such that delivery reports can route directly to the appropriate node.

Flows for submitting a short message are shown in MO Submission Flows. The delivery report is part of the MT Delivery Flows and is mentioned as the SIP MESSAGE request containing an RP-ACK.

Registration

The IP-SM-GW requires Third Party Registration details for various functions, so registrations need to be routed to the IP-SM-GW. First-Party register and response should be included in the Register messages. Depending on your HSS, the configuration for including first-party request and response messages could be on the iFC or the associated AS. The ServerName name in the iFC should resolve to multiple AS nodes through DNS.

<?xml version="1.0"?>
<!-- Example IFC for sending registration messages to the IPSMGW -->
<InitialFilterCriteria>
    <Priority>1</Priority>
    <TriggerPoint>
        <!-- ConditionTypeCNF 1 means logical OR of SPT elements in the same group
        then AND the SPT elements in different groups -->
        <ConditionTypeCNF>1</ConditionTypeCNF>

        <!-- logically, this TriggerPoint matches if the request is
         an Initial Registration or a Re-Registration or a De-registration -->
        <SPT>
            <Group>0</Group>
            <Method>REGISTER</Method>
            <Extension>
                <RegistrationType>0</RegistrationType> <!-- INITIAL_REGISTRATION -->
            </Extension>
        </SPT>
        <SPT>
            <Group>0</Group>
            <Method>REGISTER</Method>
            <Extension>
                <RegistrationType>1</RegistrationType> <!-- RE_REGISTRATION -->
            </Extension>
        </SPT>
        <SPT>
            <Group>0</Group>
            <Method>REGISTER</Method>
            <Extension>
                <RegistrationType>2</RegistrationType> <!-- DE_REGISTRATION -->
            </Extension>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <!-- The DNS name should resolve to a number of IP-SM-GW cluster nodes -->
        <ServerName>sip:ipsmgw-cluster.example.com;transport=tcp</ServerName>
        <DefaultHandling>0</DefaultHandling>
        <Extension>
            <IncludeRegisterRequest/>
            <IncludeRegisterResponse/>
        </Extension>
    </ApplicationServer>
</InitialFilterCriteria>

Messages

Message Request containing Service Centre PSI

SIP MESSAGE requests that contain the Service Centre PSI should be routed to the IP-SM-GW if the Content-Type Header is equal to application/vnd.3gpp.sms. This caters for SMS submission and notification about the SM-over-IP receiver having memory available (if it used the PSI of the SC).

<?xml version="1.0"?>
<!-- example IFC showing MESSAGE requests to the Service Centre PSI -->
<InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
        <!-- logically, this TriggerPoint matches if the request is
        a SIP MESSAGE AND the Content-Type is 'application/vnd.3gpp.sms'
        AND the host part of the Request-URI matches
         -->
        <ConditionTypeCNF>1</ConditionTypeCNF>
        <SPT>
            <Group>0</Group>
            <Method>MESSAGE</Method>
        </SPT>
        <SPT>
            <Group>1</Group>
            <SIPHeader>
                <Header>Content-Type</Header>
                <Content>application/vnd.3gpp.sms</Content>
            </SIPHeader>
        </SPT>
        <SPT>
            <Group>2</Group>
            <RequestURI>service-centre.example.com</RequestURI>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <!-- The DNS name should resolve to a number of IP-SM-GW cluster nodes -->
        <ServerName>sip:ipsmgw-cluster.example.com;transport=tcp</ServerName>
        <DefaultHandling>0</DefaultHandling>
    </ApplicationServer>
</InitialFilterCriteria>
Note The default SIP transport mechanism for AS communication is UDP. TCP can be specified by appending ;transport=tcp to the IP-SM-GW AS URI configured in the <ServerName> attribute.
Note The ServerName name used is intended to be resolved to a number of IP-SM-GW node addresses through DNS.

Message Request containing a per-node PSI

SIP MESSAGE requests that contain a per-node PSI should be routed to the specific IP-SM-GW node that is holding an Open TCAP Transaction from the SMS-C. These messages have the Content-Type header equal to application/vnd.3gpp.sms. This caters for the sending of a delivery report or a memory available notification (if it used the IP-SM-GW address).

There should be one iFC for each IP-SM-GW cluster node, containing its AS name. This name should resolve to only one AS node.

In 24.341 the specification text does not describe the SIP Message carrying a delivery report or a memory available report as being originating, therefore it is treated as terminating.

This iFC indicates that SIP MESSAGE Requests for the per-node PSI shall only be triggered to the IP-SM-GW in a terminating request. As the SIP MESSAGE request carrying a delivery report has an In-Reply-To header containing a SIP Call-ID related to an earlier SIP MESSAGE transaction, the MESSAGE request containing the delivery report should not traverse other SIP-AS B2BUA’s (as B2BUA’s typically change the Call-ID as a message traverses the IMS).

<?xml version="1.0"?>
<!-- example IFC showing MESSAGE requests to a per node PSI -->
<InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
        <!-- logically, this TriggerPoint matches if the request is
        a SIP MESSAGE AND the Content-Type is 'application/vnd.3gpp.sms'
        AND the host part of the Request-URI matches
        AND (TERMINATING_REGISTERED OR TERMINATING_UNREGISTERED)
         -->
        <ConditionTypeCNF>1</ConditionTypeCNF>
        <SPT>
            <Group>0</Group>
            <Method>MESSAGE</Method>
        </SPT>
        <SPT>
            <Group>1</Group>
            <SIPHeader>
                <Header>Content-Type</Header>
                <Content>application/vnd.3gpp.sms</Content>
            </SIPHeader>
        </SPT>
        <SPT>
            <Group>2</Group>
            <RequestURI>ipsmgw-node1.example.com</RequestURI>
        </SPT>
        <SPT> <!-- GROUP 3 elements are OR'd together -->
            <Group>3</Group>
            <SessionCase>TERMINATING_REGISTERED</SessionCase>
        </SPT>
        <SPT>
            <Group>3</Group>
            <SessionCase>TERMINATING_UNREGISTERED</SessionCase>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <!-- The DNS name should resolve to a single IP-SM-GW node -->
        <ServerName>sip:ipsmgw-node1.example.com:5060;transport=tcp</ServerName>
        <DefaultHandling>0</DefaultHandling>
    </ApplicationServer>
</InitialFilterCriteria>

INVITE Request containing USSD content

The IP-SM-GW product implements support for USSD over IMS (USSI) interworking with MAP based USSD. This requires INVITE requests containing USSD messages to be routed to the IP-SM-GW.

For originating USSI INVITEs an originating iFC needs to match the USSI INVITE. The following example matches all INVITEs with a Recv-Info header equal to g.3gpp.ussd.

<?xml version="1.0"?>
<!-- example IFC showing USSI INVITEs routing to the IP-SM-GW -->
<InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
        <!-- logically, this TriggerPoint matches if the request is
        a SIP INVITE AND the Recv-Info header matches the value g.3gpp.ussd
         -->
        <ConditionTypeCNF>1</ConditionTypeCNF>
        <SPT>
                <ConditionNegated>0</ConditionNegated>
                <Group>0</Group>
                <Method>INVITE</Method>
                <Extension/>
        </SPT>
        <SPT>
                <ConditionNegated>0</ConditionNegated>
                <Group>1</Group>
                <SIPHeader>
                        <Header>Recv-Info</Header>
                        <Content>g.3gpp.ussd</Content>
                </SIPHeader>
                <Extension/>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <!-- The DNS name should resolve to a number of IP-SM-GW cluster nodes -->
        <ServerName>sip:ipsmgw-cluster.example.com;transport=tcp</ServerName>
        <DefaultHandling>0</DefaultHandling>
    </ApplicationServer>
</InitialFilterCriteria>

An alternative to the approach used here is to define a wildcard Public Service Identity for USSD over IMS.

Note The Sentinel VoLTE product typically receives INVITE requests. The iFC used to trigger Sentinel VoLTE should exclude INVITEs matching USSD over IMS requests.
Previous page Next page
Sentinel IP-SM-GW Version 3.1.0