6 Functional requirements of serving CSCF and Transit Function

23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Modes of operation of the S-CSCF and Transit Function

6.1.1 General overview of functional models and modes of operation of the S-CSCF

Figure 6.1.1.1: S-CSCF functional model with incoming leg control and outgoing leg control

Figure 6.1.1.1 identifies the components of a functional model of the S-CSCF.

NOTE: These components are defined only as a model of the expected behaviour of the S-CSCF and are not intended to define or constrain the actual implementation.

The components include the Combined I/OLSM, the ILCM and OLCM and the Registrar and Notifier. There is a single Combined I/OLSM, which shall be able to store session state information. It may act on each leg independently, acting as a SIP Proxy, Redirect Server or User Agent dependant on the information received in the SIP request, the filter conditions specified or the state of the session.

It shall be possible to split the application handling on each leg and treat each endpoint differently.

There is a single ILCM, which shall store transaction state information.

There is a single OLCM, which shall store transaction state information.

The Registrar and Notifier component handles registration and subscription to and notification of registration events.

6.1.2 General overview of functional models and modes of operation of the Transit Function

Figure 6.1.2.1: Transit Function functional model with incoming leg control and outgoing leg control

Figure 6.1.2.1 identifies the components of a functional model of the Transit Function.

NOTE: These components are defined only as a model of the expected behaviour of the Transit Function and are not intended to define or constrain the actual implementation.

The components include the Combined I/OLSM, the ILCM and OLCM. There is a single Combined I/OLSM, which shall be able to store session state information. It may act on each leg independently, acting as a SIP Proxy, Redirect Server or User Agent dependant on the information received in the SIP request, the invocation conditions specified or the state of the session.

It shall be possible to split the application handling on each leg and treat each endpoint differently.

There is a single ILCM, which shall store transaction state information.

There is a single OLCM, which shall store transaction state information.

6.2 Interfaces defined for S-CSCF and Transit Function

6.2.1 S-CSCF – CSCF (Mw) interface

The protocol used between two CSCFs is also based on Session Initiation Protocol, which is specified in 3GPP TS 24.229 [5].

6.2.2 S-CSCF – Application Server (ISC) interface

The protocol used between the S- CSCF and the Application Servers (ISC interface) is also based on Session Initiation Protocol, which is specified in 3GPP TS 24.229 [5].

6.2.3 S-CSCF – HSS (Cx) interface

This interface is used to send subscriber data to the S-CSCF; including Filter criteria, which indicates which SIP requests should be proxied to which Application Servers.

The protocol used between the S-CSCF and HSS (Cx Interface) is specified in 3GPP TS 29.228 [8].

6.2.4 S-CSCF – MRB (ISC) interface

This interface is used for an MRB operating in In-Line mode when using the capability of the S-CSCF to route to the MRB. The use of this interface is described in subclause 13.2.

6.2.5 S-CSCF – MRF (Mr) interface

This interface is used for an MRF when using the capability of the S-CSCF to route to the MRB. The use of this interface is described in subclause 8.2.1.

6.2.6 Transit Function – Application Server (ISC) interface

The protocol used between the Transit Function and the Application Servers (ISC interface) is based on Session Initiation Protocol, as defined in 3GPP TS 24.229 [5]. The interface implements the Mf reference point, as defined in 3GPP TS 23.228 [3].

6.3 S-CSCF handling of SIP registration

Upon receiving the initial registration request from the served user, the S-CSCF shall authenticate the served user and upon receiving a subsequent registration request containing valid authentication credentials, request the HSS to send the relevant service profile(s) for the served user’s subscription. More than one service profile may be sent, depending on configuration options for identifying implicitly registered public user identities. For further detailed information on registration, profile download and authentication procedures see 3GPP TS 24.229 [5], 3GPP TS 33.203 [11], and 3GPP TS 33.328 [25].

The registration request can contain a list of ICSI values and a list of IARI values supported by the UE.

The initial filter criteria (subset of the profile) is stored locally at the S-CSCF, as specified in 3GPP TS 24.229 [5].

The S-CSCF shall verify if the triggers match, from the highest to the lowest priority (see subclause 5.2).

After a successfully authenticated registration, the S-CSCF shall download from the HSS all the implicitly registered public user identities associated with the registered public user identity. The S-CSCF shall then verify, in their order of priority, if the triggers downloaded from the HSS match. For each service profile in the implicit registration set, if the registration request from the served user matches a trigger, the S-CSCF performs a third party registration to the application servers which are interested to be informed about the user registration event of these public user identities. This may trigger services to be executed by an Application Server.

The important information carried in the third party REGISTER request is the public user identity of the served user, the S-CSCF address and the expiration time. It shall be possible based on operator configuration to use one of the implicitly registered public user identities as the public user identity in the To header of the third party REGISTER request sent to the Application Server. Additional application server specific data, which is associated with the Filter Criteria and obtained from the HSS, is added to the REGISTER request body. This data should include the IMSI for an Application Server that supports CAMEL services or the private user identity for other Application Servers as received from the HSS. If indicated by the Filter Criteria the incoming REGISTER request is added to the REGISTER request body. If indicated by the Filter Criteria the final response to the incoming REGISTER request is added to the REGISTER request body.

This third party registration will include an expiration time that is equal to the expiration time sent to the UE by the S-CSCF in the 200 (OK) response to the incoming REGISTER request

On receiving a failure response to one of the REGISTER requests, the S-CSCF shall apply the "default handling" related with the initial Filter Criteria’s trigger used (see subclauses 5.2.2, 6.9.2.2).

See figure 6.3.1:

Figure 6.3.1: S-CSCF handling registration

Application Servers can in addition subscribe to the S-CSCF reg event package. This provides a mechanism for the Application Server to discover all the implicitly registered public user identities without requiring multiple Register requests to be sent to the Application Server and to obtain the current capabilities of the UE as well as be notified about refresh registrations and de-registrations. The S-CSCF will send NOTIFY requests to the Application Server that has subscribed to the reg event package for the registered public user identity. The reg event package also provides a mechanism for the Application Server to obtain the associated parameters (e.g GRUUs, ICSIs and IARIs) for each contact of every registered public identity.

NOTE: When the Application Server maintains a persistent subscription to the reg event package it is not necessary for the Application Server to receive third party registration requests from the S-CSCF in response to refresh and de-registration events as these are communicated to the Application Server in the reg event notifications.

More information on these procedures is contained in 3GPP TS 24.229 [5].

6.4 S-CSCF handling of UE-originating requests

6.4.1 S-CSCF handling of UE-originating requests, registered user

The served user can be included in different information elements than the calling identity. The S-CSCF shall determine the apropriate identity of the served user from one of these information elements.

The S-CSCF shall verify if the public user identity of the served user is barred. If so, it shall respond with a 4xx error code and stop further processing of the request. A UE-originating initial request may originate from an Application Server via the ISC interface. Originating initial requests from an Application Server via the ISC interface also cause the S-CSCF to look for initial filter criteria.

The S-CSCF only looks for initial filter criteria when receiving an initial request.

The initial filter criteria (subset of the profile) has already been downloaded from the HSS and is stored locally at the S-CSCF, as specified in 3GPP TS 24.229 [5].

When such a request comes in, the S-CSCF shall first check whether this is an UE-originating request or a UE-terminating request in order to perform the matching procedure with SPTs within initial filter criteria. This subclause describes the requirements for the S-CSCF when this request is a UE-originating request. If this request is a UE-originating request, the S-CSCF shall:

– determined the served user;

– check whether the request matches a subscribed service (i.e. SDP and other content matches appropriate SDP and other content for each and any of the subscribed services for served user user). As an operator option, if the contents of the request do not match a subscribed service, the S-CSCF may reject the request;

– check whether any contained unauthenticated ICSI value is part of the set of the subscribed services and is consistent with the contents of the request (i.e. SDP and other content is consistent with the unauthenticated ICSI value) if so that is the IMS communication service related to the request;

– if the request contains an unauthenticated ICSI value then remove the unauthenticated ICSI value;

– if the request does not contain an unauthenticated ICSI value, or the one that is included is not part of the set of the subscribed services, then as an operator option, the S-CSCF may:either reject the request, or proceed without a service identifier or choose one of the others from the subscribed set;

– include an authenticated ICSI value if the contents of the request are related to an IMS communication service based upon the previous checks and use this authenticated ICSI value as the IMS communication service identifier when applying the initial filter criteria in the subsequent steps;

– use the initial Filter Criteria for the UE-originating case tied to the served user;

– check whether this request matches the initial filter criteria with the highest priority for the served user by checking the service profile against the public user identity of the served user, which was used to place this request;

– if this request matches the initial filter criteria, the S-CSCF shall forward this request to that application server, then check for matching of the next following filter criteria of lower priority, and apply the filter criteria on the SIP method received from the previously contacted application server;

– if this request does not match the highest priority initial filter criteria, check for matching of the following filter criteria priorities until one applies;

– if no more (or none) of the initial filter criteria apply, the S-CSCF shall forward this request downstream based on the route decision;

– in any instance, if the contact of the application server fails, the S-CSCF shall use the "default handling" associated with the initial Filter Criteria to determine if it shall either terminate the call or let the call continue based on the information in the filter criteria; if the filter criteria does not contain instruction to the S-CSCF regarding the failure of the contact to the application server, the S-CSCF shall let the call continue as the default behaviour.

6.4.2 S-CSCF handling of UE-originating requests, unregistered user

The served user can be included in different information elements other than calling identity. The S-CSCF shall determine the appropriate identity of the served user from one of these information elements.

The S-CSCF shall verify if the public user identity of the served user is barred. If so, it shall respond with a 4xx error code and stop further processing of the request.

The S-CSCF only looks for initial filter criteria when receiving an initial request. A UE-originating initial request may originate from an Application Server via the ISC interface. Originating initial requests from an Application Server via the ISC interface also cause the S-CSCF to look for initial filter criteria.

When such a request comes in, the S-CSCF shall first check this is an UE-originating request or a UE-terminating request. This subclause describes the requirements for the S-CSCF when this request is a orginating request. So, if this request is a UE-originating request, the S-CSCF shall:

– check whether the request matches a subscribed service (i.e. SDP and other content matchs appropriate SDP and other content for each and any of the subscribed services for the served user). As an operator option, if the contents of the request do not match a subscribed service, the S-CSCF may reject the request;

– if the request contains an unauthenticated ICSI value then remove the unauthenticated ICSI value;

– if the request does not contain an unauthenticated ICSI value, or the one that is included is not part of the set of the subscribed services, then as an operator option, the S-CSCF may: either reject the request, or proceed without a service identifier or choose one of the others from the subscribed set;

– if unavailable, download the relevant subscriber profile including the initial filter criteria from the HSS;

– use the initial Filter Criteria for the UE-originating request for unregistered served user;

– if this request does not match the highest priority initial filter criteria, check for matching of the following filter criteria priorities until one applies;

– if no more (or none) of the initial filter criteria apply, the S-CSCF shall forward this request downstream based on the route decision;

6.5 S-CSCF handling of UE-terminating requests

6.5.1 S-CSCF handling of UE-terminating requests, registered user

The served user can be included in different information elements than the called identity The S-CSCF shall determine the apprpriate identity of the served user from one of those information elements. If the selected information element includes a GRUU associated with a particular public user identity it is the associated public user identity that is the served user for the request and the S-CSCF shall use that served user for the following terminating request handling procedures.

The S-CSCF shall verify if the public user identity is barred of the served user. If so, it shall respond with a 4xx error code and stop further processing of the request.

The S-CSCF only looks for initial filter criteria when receiving an initial request. A UE-terminating initial request may also originate from an Application Server via the ISC interface. Terminating Initial requests from an Application Server via the ISC interface also cause the S-CSCF to look for initial filter criteria.

When such a request comes in, the S-CSCF shall first check whether this is an UE-originating request or a UE-terminating request. For UE-terminating initial requests the S-CSCF shall first perform any routing of the request to Application Server based on matching of initial Filter Criteria before performing other routing procedures towards the terminating UE, (e.g. forking, caller preferences etc). This subclause describes the requirements for the S-CSCF when this request is a UE-terminating request. So, if this request is a UE-terminating request, the S-CSCF shall:

– if the request contains an authenticated ICSI value the S-CSCF shall check whether the IMS communication service identified by the authenticated ICSI value is allowed for the subscribed services for the served user and is consistent with the contents of the request (i.e. SDP and other content is consistent with the unauthenticated ICSI value) and if not remove the authenticated ICSI value otherwise use this as the authenticated ICSI value;

– if the request does not contain an authenticated ICSI value then check whether the request matches a subscribed service (i.e. SDP and other content matchs appropriate SDP and other content for each and any of the subscribed services for the served user) As an operator option, if the contents of the request do not match a subscribed service, the S-CSCF may reject the request;

– if unavailable, download the relevant subscriber profile including the initial filter criteria from the HSS;

– use the initial Filter Criteria for the UE-terminating request to registered served user;

– in case the Request-URI changes when visiting an Application Server, terminate the checking of filter criterias, and either:

a) route the request, without attempting to verify the barring status of the changed public user identity, based on the changed value of the Request-URI and do not execute the subsequent steps;

b) use the initial Filter Criteria for the UE-originating case after retargeting and perform the matching procedure with SPTs within this initial Filter Criteria as described in subclause 6.4.1; or

c) continue to use the intial Filter Criteria for the UE terminating case and perform the matching procedure with SPT within the UE terminating UE case.

NOTE: The S-CSCF determines whether to apply a), b) or c) based on information in the initial Filter Criteria.

– the subsequent requirements for the S-CSCF are the same as those for handling UE-originating requests.

Originating UE and terminating UE can share the same S-CSCF and Application Server, therefore the shared application server may interact with the S-CSCF twice in one transaction but in UE-originating and UE-terminating procedures respectively.

6.5.2 S-CSCF handling of UE-terminating requests, unregistered user

The Served user can be included in different information elements than the called identity The S-CSCF shall determine the appropriate identity of the served user from one of those information elements. If the selected information element includes a GRUU associated with a particular public user identity it is the associated public user identity that is the served user for the request and the S-CSCF shall use that served user for the following terminating request handling procedures.

The S-CSCF shall verify if the public user identity of the served user is barred. If so, it shall respond with a 4xx error code and stop further processing of the request.

The S-CSCF only looks for initial filter criteria when receiving an initial request. A UE-terminating initial request may also originate from an Application Server via the ISC interface. Terminating initial requests from an Application Server via the ISC interface also cause the S-CSCF to look for initial filter criteria.

When such a request comes in, the S-CSCF shall first check this is an UE-originating request or a UE-terminating request. This subclause describes the requirements for the S-CSCF when this request is a UE-terminating request. So, if this request is a UE-terminating request, the S-CSCF shall:

– if the request does not contain an authenticated ICSI value then check whether the request matches a subscribed service (i.e. SDP and other content matchs appropriate SDP and other content for each and any of the subscribed services for the served user user) As an operator option, if the contents of the request do not match a subscribed service, the S-CSCF may reject the request;

– if unavailable, download the relevant subscriber profile including the initial filter criteria from the HSS;

– use the initial Filter Criteria for the UE-terminating request to unregistered served user;

– in case the Request-URI changes when visiting an Application Server, terminate the checking of filter criterias, and either:

a) route the request, without attempting to verify the barring status of the changed public user identity, based on the changed value of the Request-URI and do not execute the subsequent steps;

b) use the initial Filter Criteria for the UE-originating case after retargeting and perform the matching procedure with SPTs within this initial Filter Criteria as described in subclause 6.4.1; or

c) continue to use the intial Filter Criteria for the UE terminating case and perform the matching procedure with SPT within the UE terminating UE case.

NOTE: The S-CSCF determines whether to apply a), b) or c) based on information in the initial Filter Criteria.

– the subsequent requirements for the S-CSCF are the same as those for handling UE-originating requests with one exception: if no more (or none) of the initial filter criteria apply, the S-CSCF shall reject the request.

6.5A Transit Function handling of requests

6.5A.1 Transit Function handling of initial requests and standalone requests

An initial request or a standalone request may originate from an Application Server via the ISC interface. Originating initial requests and standalone requests from an Application Server via the ISC interface also cause the Transit Function to look for Transit Invocation Criteria.

The Transit Invocation Criteria is locally configured at the Transit Function.

When the Transit Function receives an initial request, or a standalone request, and the request is associated with a transit scenario where IMS application services are provided, in order to perform the matching procedure with SPTs within Transit Invocation Criteria. Then the Transit Function shall:

– check whether the request matches a service configured for the transit scenario. As an operator option, if the contents of the request do not match a configured service, the Transit Function may reject the request;

– use the Transit Invocation Criteria for the transit scenario;

– check whether this request matches the Transit Invocation Criteria with the highest priority configured for the transit scenario;

– if this request matches the Transit Invocation Criteria, the Transit Function shall forward this request to that Application Server, then check for matching of the next following criteria of lower priority, and apply the criteria on the SIP method received from the previously contacted Application Server;

– if this request does not match the highest priority Transit Invocation Criteria, check for matching of the following criteria priorities until one applies;

– if no more (or none) of the Transit Invocation Criteria apply, the Transit Function shall forward this request downstream based on the route decision; and

– in any instance, if the contact of the Application Server fails, the Transit Function shall use the "default handling" associated with the Transit Invocation Criteria to determine if it shall either terminate the call or let the call continue based on the information in the criteria; if the criteria does not contain instruction to the Transit Function regarding the failure of the contact to the Application Server, the Transit Function shall let the call continue as the default behaviour.

6.6 S-CSCF and Transit Function handling of IP multimedia session release requests

6.6.0 Introduction

In handling session release, the S-CSCF and the Transit Function may either proxy the release request or initiates a release request.

6.6.1 S-CSCF and Transit Function proxying release request

When the S-CSCF and the Transit Function receives a release request from some entities (etc, application server, user agent) for a dialog, it proxies the release request to the destination according to route information in that release request.

Figure 6.6.1.1: S-CSCF proxying release request

6.6.2 S-CSCF and Transit Function initiating release request

For some reason (etc. administration decision of the network), the S-CSCF and the Transit Function may be required to release an ongoing dialog. In this case, the S-CSCF and the Transit Function shall send a release request to all the entities that are involved in this dialog. In a typical AS involved dialog, the S-CSCF and the Transit Function should send the release request to the AS and the UE it is serving as shown in figure 6.6.2.1.

Figure 6.6.2.1: S-CSCF initiating release request

6.7 S-CSCF handling of subscription and notification

The S-CSCF supports subscription to and notification of the reg event package by the UE, P-CSCFs and Application Servers. The subscribing entity may subscribe to the registration state of individual public user identities for the purpose of discovering the implicitly registered public user identities and associated parameters (e.g. GRUUs, ICSIs, IARIs) for each registered contact. When notifying a subscribing entity of a change in the registration state of a subscribed to public user identity the S-CSCF shall include in the notification all the implicitly registered public user identities associated with the registered public user identity in addition to the registered public user identity along with the associated parameters of every contact of each registered public user identity.

Figure 6.7.1: Application Server – S-CSCF subscribe notify dialog

6.8 S-CSCF handling IMS charging

In registration processing, a S-CSCF may send a third party REGISTER to an application server, where the ICID, IOI and charging function addresses are included in the message.

During a session, the S-CSCF shall generate the CDR for charging purposes.

In a session originating case, when receiving an incoming initial request, this request will carry the ICID generated by the upstream P-CSCF, which is serving the originating user; the S-CSCF shall store the ICID for this session and handle this request based on filter criteria. After processing this request the S-CSCF shall include the ICID and the charging function addresses received from the HSS in the outgoing message. The charging function addresses identify on-line, and off-line charging entities in the home network. It is implementation dependent how IMS related entities such as P-CSCF in the visited network get the local CCF or AAA addresses in the case that the P-CSCF is located in the visited network. Charging function addresses may be allocated as locally preconfigured addresses. If this message is sent outside the home network, S-CSCF shall include Inter Operator Identifier (IOI) that identifies the home network into the message. IOI is globally unique identifier for using inter operator accounting purposes. The response to the outgoing message may contain a separate IOI that identifies the home network of the called party. The S-CSCF shall retain either IOI in the message when contacting the Application Servers. The S-CSCF will receive access network (IP-CAN) charging information from subsequent requests and responses, the S-CSCF shall store these parameters and shall remove them from the outgoing message if this message is sent to the terminating UE’s home network or the originating UE’s visited network. The access network (IP-CAN) charging information may be sent to application servers.

In a session terminating case, when receiving an incoming initial request, this request will carry the ICID generated by the originating UE’s P-CSCF; the S-CSCF shall store the ICID for this session and handle this request based on filter criteria. After processing this request the S-CSCF shall include the ICID and the charging function addresses received from the HSS in the outgoing message. The charging function addresses identify on-line and off-line charging entities in the home network. IOI may be received from another network or is inserted by the MGCF to identify the originating PSTN/PLMN. If IOI is received at the S-CSCF, the S-CSCF shall store the IOI value for the network that sent the request. The response to the incoming message may contain a separate IOI that identifies the home network of the S-CSCF. The S-CSCF shall retain either IOI in the message when contacting the Application Servers. Afterwards, the S-CSCF shall remove the IOI of the requesting network from the message before sending the message further within the network. The S-CSCF will receive access network (IP-CAN) charging information from subsequent requests and responses, the S-CSCF shall store these parameters and removes them from the outgoing message if this message is sent to the terminating UE’s visited network or the originating UE’s home network. The access network (IP-CAN) charging information may be sent to application servers.

For detailed information on transporting charging parameters between IMS entities using SIP, see 3GPP TS 24.229 [5].

6.8A Transit Function handling IMS charging

During a session, the Transit Function shall generate a CDR for charging purposes. Charging function addresses are configured in the Transit Function.

Incoming initial SIP requests or a stand-alone SIP requests will carry an ICID generated by an upstream functional entity and an Inter Operator Identifier (IOI) identifying the network sending the request (the home network serving a user or a visited network where the user is connected). The Transit Function shall store the ICID and the IOI for this session.

Incoming SIP requests within an existing dialog will carry the ICID received in the initial SIP request and an IOI identifying the network sending the request (the home network serving a user or a visited network where a user is connected).

When sending SIP requests to Application Servers the Transit Function shall:

– include the ICID received in the incoming initial SIP request or stand-alone SIP request;

– remove the IOI received in the request; and

– include an IOI value identifying the network where the Transit Function resides.

When forwarding the incoming initial request, the stand-alone request or the request received within the existing dialog to a down stream functional entity, i.e. an functional entity that is not an Application Server, the Transit Function shall include the ICID and the IOI received in the incoming request.

Responses to the initial SIP request, the stand-alone SIP request or the SIP request received within the existing dialog will contain the ICID received in the incoming request and an IOI value included by an down stream entity.

When sending responses to Application Servers the Transit Function shall:

– include the ICID value received in the response;

– remove the IOI value received in the response; and

– include an IOI value identifying the network where the Transit Function resides.

The Transit Function shall store any IOI received from an Application Server in requests or responses.

For detailed information on transporting charging parameters between IMS entities using SIP, see 3GPP TS 24.229 [5].

6.9 S-CSCF description of subscriber data

6.9.1 Application Server subscription information

The Application Server Subscription Information is the set of all Filter Criteria that are stored within the HSS for service profile for a specific user. This information shall be sent by the HSS to the S-CSCF via the Cx Interface during registration. More than one set of Filter Criteria may be sent during registration if implicitly registered public user identities belong to different service profiles. Filter Criteria shall also be sent after registration via the Cx interface when requested, as specified in 3GPP TS 29.228 [8].

6.9.2 Filter Criteria

6.9.2.0 Introduction

This subclause defines the contents of the Filter Criteria. This information is part of the Application Server Subscription Information. For further information about the XML modelling see 3GPP TS 29.228 [8].

Filtering is done for initial SIP request messages only.

The S-CSCF shall apply filter criteria to determine the need to forward SIP requests to Application Servers. These filter criteria will be downloaded from the HSS.

Initial Filter Criteria (iFC) are stored in the HSS as part of the user profile and are downloaded to the S-CSCF upon user registration, or upon a terminating initial request for an unregistered user if unavailable, or upon an originating initial request from an Application Server for an unregistered user if unavailable. They represent a provisioned subscription of a user to an application. After downloading the User Profile from the HSS, the S-CSCF assesses the filter criteria. Initial Filter Criteria are valid throughout the registration lifetime of a user or until the User Profile is changed.

Subsequent Filter Criteria (sFC) are not used in this version of this specification.

6.9.2.1 Application Server address

Address to be used to access the Application Server for a particular subscriber.

6.9.2.2 Default handling

The default handling procedure indicates whether to abandon matching of lower priority triggers and to release the dialogue, or to continue the dialogue and trigger matching.

6.9.2.3 Trigger point

Trigger Points are the information the S-CSCF receives from the HSS that defines the relevant SPTs for a particular application. They define the subset of initial SIP requests received by the S-CSCF or headers (eg P-Asserted-Service header) created by S-CSCF that should be sent or proxied to a particular application server. When the S-CSCF receives an initial SIP request, it evaluates the filter criteria one by one. If the initial SIP request matches the filter criteria, the S-CSCF proxies the SIP request to the corresponding SIP AS/IM-SSF/OSA SCS.

6.9.2.4 iFC Priority

If there are multiple initial Filter Criteria assigned for one subscriber, the priority shall describe the order in which the S-CSCF shall assess them, and then contact the Application Servers when the SIP request matches the initial filter criteria. In this case, the S-CSCF shall interact with the application server associated with the initial matching filter criteria, starting from the filter criteria which has the highest priority.

6.9.2.5 Service Information

Service Information is transparent information, and is not processed by the HSS or the S-CSCF. Service Information is optionally part of an initial Filter Criteria. If it is available from the initial Filter Criteria the S-CSCF shall include it into the body of the SIP request which is sent from the S-CSCF to the AS to which the initial Filter Criteria is pointing to. Service Information is only included by the S-CSCF in REGISTER requests where the S-CSCF acts as a UAC.

6.9.2.6 Include Register Request

Include Register Request defines whether the S-CSCF is to include the incoming REGISTER request in the body of the third party REGISTER request.

NOTE: When the AS is outside the trust domain for any header field that is permitted in the REGISTER request received from the UE, including an Include Register Request indication in the initial Filter Criteria would cause the incoming REGISTER request contents to be delivered to the AS revealing information that AS is not trusted to obtain. Include Register Request indication is therefore not included in the initial Filter Criteria for an AS that exists outside the trust domain for any such header field.

6.9.2.7 Include Register Response

Include Register Response defines whether the S-CSCF is to include the final response to the incoming REGISTER request in the body of the third party REGISTER request.

NOTE: When the AS is outside the trust domain for any header field that is permitted in the final response to the REGISTER request received from the UE, including an Include Register Response indication in the initial Filter Criteria would cause the final response to the incoming REGISTER request contents to be delivered to the AS revealing information that AS is not trusted to obtain. Include Register Response indication is therefore not included in the initial Filter Criteria for an AS that exists outside the trust domain for any such header field.

6.9.3 Authentication data

This subclause defines the Authentication Data. This data shall be sent by the HSS to the S-CSCF via the Cx Interface during registration.

For definition of authentication data see specification 3GPP TS 23.008 [10]. For the handling of authentication data, see 3GPP TS 33.203 [11].