5.13 ISC gateway function

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

5.13.1 General

As specified in 3GPP TS 23.218 [5] border control functions may be applied between the IM CN subsystem and an application server based on operator preference. The ISC gateway function may act both as an entry point and as an exit point for a network. If it processes a SIP request received from another network it functions as an entry point (see subclause 5.13.3) and it acts as an exit point whenever it processes a SIP request sent to other network (see subclause 5.13.2).

In many cases, the ISC interface carries more than one hop of the session, e.g.. the application server has applied a service to a SIP request and then returned the SIP request to the S-CSCF, or a AS acting as a third-party call controller generates multiple outgoing legs. In these cases all the requests relating to the session on all hops / legs should be configured to route through the same ISC gateway function.

NOTE 1: This is to provide for future requirements for the ISC gateway function that may need to provide correlation of the SIP transactions, and additional functionality based on that correlation.

This ISC gateway function exists on a one to one basis with its addressed AS, i.e. the URI used to address the ISC gateway function will always reach the same AS beyond the ISC gateway function.

The functionalities of the ISC gateway function are entry and exit point procedures as defined in subclause 5.13.2 and subclause 5.13.3 and additionally can include:

– network configuration hiding (as defined in subclause 5.13.4);

– application level gateway (as defined in subclause 5.13.5);

– transport plane control, i.e. QoS control (as defined in subclause 5.13.5); and

– screening of SIP signalling (as defined in subclause 5.13.6);

NOTE 2: The functionalities performed by the application level gateway are configured by the operator, and it is network specific.

The application level gateway shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field based on local policy.

5.13.2 ISC gateway function as an exit point

5.13.2.1 Registration

There are no specific requirements for the REGISTER method, i.e. the REGISTER method is treated as for other SIP methods.

5.13.2.2 General

This subclause applies for requests sent from the S-CSCF to the AS via the ISC gateway function.

For all SIP transactions identified:

– if priority is supported, as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field, the ISC gateway function shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the ISC gateway function shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.

NOTE: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

5.13.2.3 Initial requests

Upon receipt of:

– an initial request for a dialog;

– a request for a standalone transaction; or

– a request for an unknown method that does not relate to an existing dialog;

the ISC gateway function shall:

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response;

2) remove the topmost entry from the Route header field in accordance with RFC 3261 [26] procedures for processing Route header fields, and then add as the topmost entry the URI of the application server associated with this ISC gateway function, followed by a next entry of a URI needed to reach this ISC gateway function from the application server;

3) if the request is an INVITE request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, save the Contact, CSeq and Record-Route header field values received in the request such that the ISC gateway function is able to release the session if needed;

4) If the request is a SUBSCRIBE and the ISC gateway function does not need to act as B2BUA, based on operator policy, the ISC gateway function shall determine whether or not to retain, for the related subscription, the SIP dialog state information and the duration information;

NOTE 1: The event package name can be taken into account to decide whether or not the SIP dialog state and the subscription duration information needs to be retained.

NOTE 2: The ISC gateway function needs to insert its own URI in the Record-Route header field of the initial SUBSCRIBE request and all subsequent NOTIFY requests if it decides to retain the SIP dialog state information.

5) if the request is an initial request for a dialog and local policy requires the application of ISC gateway function capabilities in subsequent requests, perform record route procedures as specified in RFC 3261 [26];

6) if the recipient of the request is understood from configured information to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;

7) store the values from the P-Charging-Function-Addresses header field, if present;

8) if the request is an initial request and "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain;

– store the "fe-identifier" header field parameter of the P-Charging-Vector header field; and

– remove the "fe-identifier" header field parameter from the P-Charging-Vector header field;

9) remove some of the parameters from the P-Charging-Vector header field or the header field itself, depending on operator policy, if present; and

NOTE 3: An example where an ISC-GW removes the P-Charging-Vector header field is where the request is forwarded to outside the trust domain.

10) remove the P-Charging-Function-Addresses header fields, if present, prior to forwarding the message;

and forwards the request according to RFC 3261 [26].

NOTE 4: If ISC gateway function processes a request without a pre-defined route (e.g. the subscription to reg event package originated by the AS), the next-hop address can be either obtained as specified in RFC 3263 [27A] or be provisioned in the ISC gateway function.

When the ISC gateway function receives an INVITE request, the ISC gateway function may require the periodic refreshment of the session to avoid hung states in the ISC gateway function. If the ISC gateway function requires the session to be refreshed, the ISC gateway function shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE 5: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

When the ISC gateway function receives a response to any of the requests handled in this subclause, then the ISC gateway function shall:

1) in the P-Charging-Vector header field, subject to operator policy, reinsert any parameters that were removed and stored. In addition, where the operator policy requires it, include on behalf of the supported application server a type 3 "term-ioi" header field parameter. This IOI may represent either the network of the ISC gateway function or the network providing the AS.

In responses, if "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain, the ISC gateway function acting as an exit point shall:

– delete in the P-Charging-Vector header field any received "fe-identifier" header field parameter; and

– add the stored"fe-identifier" to the P-Charging-Vector header field and include its own address or identifier as an "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header.

With the exception of 305 (Use Proxy) responses, the ISC gateway function shall not recurse on 3xx responses.

5.13.2.4 Subsequent requests

Upon receipt of a subsequent request, the ISC gateway function shall:

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response;

2) if the request is a NOTIFY request with the Subscription-State header field set to "terminated" and the ISC gateway function has retained the SIP dialog state information for the associated subscription, once the NOTIFY transaction is terminated, the ISC gateway function can remove all the stored information related to the associated subscription;

3) if the request is a target refresh request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed; and

4) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog where the method is unknown) and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed;

and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 [26].

5.13.2.5 Call release initiated by ISC gateway function

If the ISC gateway function provides transport plane control functionality and receives an indication of a transport plane related error the ISC gateway function may:

1) generate a BYE request for the terminating side based on information saved for the related dialog; and

2) generate a BYE request for the originating side based on the information saved for the related dialog.

NOTE: Transport plane related errors can be indicated from e.g. TrGW. The protocol for indicating transport plane related errors to the ISC gateway function is out of scope of this specification.

Upon receipt of the 2xx responses for both BYE requests, the ISC gateway function shall release all information related to the dialog and the related multimedia session.

5.13.3 ISC gateway function as an entry point

5.13.3.1 Registration

There are no specific requirements for the REGISTER method, i.e. the REGISTER method is treated as for other SIP methods.

5.13.3.2 General

This subclause applies for requests sent from the AS to the S-CSCF via the ISC gateway function. Such requests come from the AS as a result of a request received from the S-CSCF and forwarded by the ISC gateway function.

For all SIP transactions identified:

– if priority is supported (NOTE), as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field, the ISC gateway function shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the ISC gateway function shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.

5.13.3.3 Initial requests

Upon receipt of:

– an initial request for a dialog;

– a request for a standalone transaction; or

– a request for an unknown method that does not relate to an existing dialog;

the ISC gateway function shall verify whether the request is arrived from a trusted domain or not. If the request arrived from an untrusted domain, then the ISC gateway function shall:

– remove all P-Charging-Vector header fields and all P-Charging-Function-Addresses header fields the request may contain.

Upon receipt of:

– an initial request for a dialog;

– a request for a standalone transaction except the REGISTER request; or

– a request for an unknown method that does not relate to an existing dialog;

the ISC gateway function shall:

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response;

2) remove the topmost entry from the Route header field in accordance with RFC 3261 [26] procedures for processing Route header fields;

3) if a P-Private-Network-Indication header field is included in the request, check whether the configured information allows the receipt of private network traffic from this source. If private network traffic is allowed, the ISC gateway function shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that configured information. If private network traffic is not allowed, or the received domain name does not match, then the ISC gateway function shall remove the P-Private-Network-Indication header field;

4) if the initiator of the request is understood from configured information to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that configured information;

5) if the request is an INVITE request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, then the ISC gateway function shall save the Contact, CSeq and Record-Route header field values received in the request such that the ISC gateway function is able to release the session if needed;

6) If the request is a SUBSCRIBE and the ISC gateway function does not need to act as B2BUA, based on operator policy, the ISC gateway function shall determine whether or not to retain, for the related subscription, the SIP dialog state information and the duration information; and

NOTE 1: The event package name can be taken into account to decide whether or not the SIP dialog state and the subscription duration information needs to be retained.

7) if the request is an initial request for a dialog and local policy requires the application of ISC gateway function capabilities in subsequent requests, perform record route procedures as specified in RFC 3261 [26];

NOTE 3: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

When receiving an initial request and "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain, the ISC gateway function acting as an entry point shall:

– add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier; and

– delete in the P-Charging-Vector header field any received "fe-identifier" header field parameter.

When the ISC gateway function receives a response to an initial request (e.g. 183 or 2xx), the ISC gateway function shall:

1) store the values from the P-Charging-Function-Addresses header field, if present;

2) remove the "fe-identifier" header field parameter from the P-Charging-Vector header field, if present; and

3) remove the P-Charging-Function-Addresses header field prior to forwarding the message.

With the exception of 305 (Use Proxy) responses, the ISC gateway function shall not recurse on 3xx responses.

5.13.3.4 Subsequent requests

Upon receipt of a subsequent request, the ISC gateway function shall:

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response;

3) if the request is a target refresh request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, then the ISC gateway function shall save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed;

4) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog where the method is unknown) and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, then the ISC gateway function shall save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed; and

5) if the subsequent request is received from outside the trust domain, then the ISC gateway function shall remove a P-Charging-Vector header field, if present;

and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 [26].

5.13.3.5 Call release initiated by the ISC gateway function

If the ISC gateway function provides transport plane control functionality and receives an indication of a transport plane related error the ISC gateway function may:

1) generate a BYE request for the terminating side based on information saved for the related dialog; and

2) generate a BYE request for the originating side based on the information saved for the related dialog.

NOTE: Transport plane related errors can be indicated from e.g. TrGW. The protocol for indicating transport plane related errors to the ISC gateway function is out of scope of this specification.

Upon receipt of the 2xx responses for both BYE requests, the ISC gateway function shall release all information related to the dialog and the related multimedia session.

5.13.4 THIG functionality in the ISC gateway function

The ISC gateway function shall act according to the procedures defined for the IBCF in subclause 5.10.4 with the following exceptions:

– there are no specific requirements for the REGISTER method, i.e. the REGISTER method is treated as for other SIP methods.

5.13.5 IMS-ALG functionality in the ISC gateway function

The ISC gateway function shall act according to the procedures defined for the IBCF in subclause 5.10.5.

5.13.6 Screening of SIP signalling

The ISC gateway function shall act according to the procedures defined for the IBCF in subclause 5.10.6.

NOTE 1: Subclause 5.10.6 identifies a number of header fields that should not be screened. It is not expected that the ISC gateway function will see these header fields.

NOTE 2: In identifying header fields to be screened, care is needed to ensure that header fields needed by application servers later in the filter criteria chain are not removed. The ordering of the applications in the filter criteria chain might be reordered if this is a constraint that cannot be met.