I.3 Providing IMS application services in support of transit & interconnection traffics

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

I.3.1 Introduction

When the IM CN subsystem provides transit functionality to other operator networks or enterprise networks, it may also provide IMS applications services to the operator network or enterprise network.

The transit service invocation, performed by a transit function, is performed based on local configured transit invocation criteria that are provided for the specific transit scenario.

NOTE: The transit invocation criteria for invocation is intended to be per served network basis, for which transit functionality is provided, and not per subscriber basis.

Similar to the initial filter criteria for a user profile, the transit invocation criteria may have service point triggers, used to generate an ordered list of transit invocation criteria to be applied to a request, based on different information in the request, SIP method, SIP header field, and SIP body. The service invocation procedure shall support suppression/avoidance of conflicting services, multiple invocations of the same service and loopback scenarios.

I.3.2 Procedures

I.3.2.1 Treatment for dialog and standalone transactions

When the transit function receives an initial request for a dialog, or a request for a standalone transaction, and the request is received either from a functional entity within the same trust domain or contains a valid original dialog identifier (see step 3) or the dialog identifier (From, To and Call-ID header fields) relates to an existing request processed by the transit function, then prior to forwarding the request, the transit function shall:

1) check if an original dialog identifier that the transit function previously placed in a Route header field is present in the topmost Route header field of the incoming request.

– If not present, the transit function shall build an ordered list of transit invocation criteria.

– If present, the request has been sent from an AS in response to a previously sent request, an ordered list of transit invocation criteria already exists and the transit function shall not change the ordered list of transit invocation criteria.

2) remove its own SIP URI from the topmost Route header field;

3) check whether the initial request matches any unexecuted transit invocation criteria. If there is a match, then the transit function shall select the first matching unexecuted transit invocation criteria from the ordered list of transit invocation criteria and the transit function shall insert the AS URI to be contacted into the Route header field as the topmost entry followed by its own URI populated;

NOTE: Depending on the result of processing the transit invocation criteria the transit function can contact one or more AS(s) before processing the outgoing Request-URI.

4) if the request is not forwarded to an AS and if local policy requires the application of other additional routeing capabilities, handled by entities other than the transit function, the transit function shall apply the additional routeing capabilities if they are locally available or forward the request to an entity that implements the additional routeing capabilities;

5) determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header field if present, otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. the destination address is of an IP address type other than the IP address type used in the IM CN subsystem), the transit function shall forward the request to the destination address via an IBCF in the same network;

6) in case of an initial request for a dialog, based on local policy record-route; and

7) route the request based on SIP routeing procedures.

When the transit function receives a target refresh request, or a a subsequent request other than target refresh request, for a dialog, prior to forwarding the request, the transit function shall:

1) remove its own URI from the topmost Route header field; and

2) forward the request based on the topmost Route header field.

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

I.3.2.1A Handling of header fields related to charging

When the transit function receives a request from a functional entity that is not an AS and if the request is forwarded to an AS the transit function shall:

– store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;

NOTE 1: Any received "orig-ioi" header field parameter will be a type 2 IOI. The type 2 IOI identifies the service provider from which the request was sent.

– remove the "orig-ioi" header field parameter from the P-Charging-Vector header field, if present;

– store the value of the "transit-ioi" header field parameter and remove the "transit-ioi" header field parameter, if present; and

– insert in the P-Charging-Vector header field an IOI type 3 value in an "orig-ioi" header field parameter identifying the network sending the request and based on operator option a Relayed-Charge header field with contents set to the value of the received "transit-ioi" header field parameter.

When forwarding the request from an AS to a functional entity that is not an AS the transit function shall:

– store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;

NOTE 2: Any received "orig-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the request was sent.

– remove the "orig-ioi" header field parameter from the P-Charging-Vector header field, if present; and

– insert in the P-Charging-Vector header field the "orig-ioi" header field parameter with the IOI type 2 value stored when the initial request for a dialog or the request for a standalone transaction was received from an entity that was not an AS;

– insert the "transit-ioi" header field parameter if previously stored; and

– remove the Relayed-Charge header field, if present.

When the transit function receives a 1xx or 2xx response to a request from a functional entity that is not an AS and if the response is forwarded to an AS the transit function shall:

– store the values of the "orig-ioi", the "term-ioi" and the "transit-ioi" header field parameter received in the P-Charging-Vector header field if present;

NOTE 3: Any received "term-ioi" header field parameter will be a type 2 IOI. The type 2 IOI identifies the service provider from which the response was sent.

– remove the "orig-ioi", the "term-ioi", and the "transit-ioi" header field parameters from the P-Charging-Vector header field, if present; and

– insert in the P-Charging-Vector header field an IOI type 3 value in a "term-ioi" header field parameter identifying the network sending the response, an IOI type 3 value in an "orig-ioi" header field parameter stored when the request was received from an AS, and based on operator option a Relayed-Charge header field with contents set to the value of the received "transit-ioi" header field parameter.

When forwarding any response to a request from an AS to a functional entity that is not an AS the transit function shall remove the Relayed-Charge header field, if present.

When forwarding the 1xx or 2xx response to a request from an AS to a functional entity that is not an AS the transit function shall:

– remove the "orig-ioi" and the "term-ioi" header field parameter from the P-Charging-Vector header field, if present; and

NOTE 4: Any received "term-ioi" and "orig-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the response was sent.

– insert in the P-Charging-Vector header field an "orig-ioi" header field parameter with the IOI type 2 value, an "term-ioi" header field parameter with the IOI type 2 value received in the 1xx or 2xx response to the request from a functional entity that was not an AS, insert the "transit-ioi" header field parameter if previously stored.

I.3.2.2 Original dialog identifier for transit function

The original dialog identifier is an implementation specific token that the transit function encodes into the own transit function URI in a Route header field, prior to forwarding the request to an AS. This is possible because the transit function is the only entity that creates and consumes the value.

The token may identify the original dialog of the request, so in case an AS acting as a B2BUA changes the dialog, the transit function is able to identify the original dialog when the request returns to the transit function. In a case of a standalone transaction, the token indicates that the request has been sent to the transit function from an AS in response to a previously sent request. The token can be encoded in different ways, such as e.g., a character string in the user-part of the transit function URI, a parameter in the transit function URI or port number in the transit function URI.

The transit function shall ensure that the value chosen is unique, in order for the transit function to recognize the value when received in a subsequent message of one or more dialogs and make the proper association between related dialogs that pass through an AS.

An original dialog identifier is sent to each AS invoked due to transit invocation criteria evaluation such that the transit function can associate requests as part of the same sequence that trigger transit invocation criteria evaluation in priority order (and not rely on SIP dialog information that may change due to B2BUA AS).

NOTE: If the same original dialog identifier is included in more than one request from a particular AS (based on service logic in the AS), then the transit function will continue the transit invocation criteria evaluation sequence. If the AS wants transit invocation criteria evaluation to start from the beginning for a request, then AS does not include an original dialog identifier.