Content for TS 24.229 Word version: 19.0.0

1… 3… 4… 4.5… 5… 5.1.1.4… 5.1.2… 5.1.4… 5.2… 5.2.3… 5.2.6… 5.2.7… 5.3… 5.4… 5.4.1.2.2… 5.4.1.3… 5.4.2 5.4.3… 5.4.3.3… 5.4.4… 5.5… 5.7… 5.7.2… 5.8… 5.11… 6… 6.6… 7… 7.2A… 7.2A.6… 7.3… 7.9A… 8… A… A.2… A.2.1.4… A.2.1.4.7… A.2.1.4.8… A.2.1.4.10A… A.2.1.4.12… A.2.2… A.2.2.4… A.2.2.4.7… A.2.2.4.8… A.2.2.4.10A… A.2.2.4.12… A.3… A.3.3… B… C… E… F… H… I… K… L… L.2A… M… N… O… Q… R… S… U… U.2A… V… W…

I.1 Scope I.1A General I.2 Originating, transit and interconnection routeing procedures I.3 Providing IMS application services in support of transit & interconnection traffics I.4 Loopback routeing procedures I.5 Overload control
...

I (Normative) Additional routeing capabilities in support of traffics in IM CN subsystem |R7| p. 858

I.1 Scope p. 858

Additional routeing functionality is necessary for support of:

transit traffic as operators may use the IM CN subsystem as a transit network to provide transit functionality for their own CS networks, enterprise networks, or other network operators;
other traffics such as roaming traffic and incoming traffic destined to CSI UEs (Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services) traffics;
traffic for the roaming architecture for voice over IMS with local breakout; and
originating traffic if required by local policy as specified in subclause 5.4.3.2.

Depending on the additional routeing functionalities, the required specific functions may reside in a stand-alone entity or may be collocated with an MGCF, a BGCF, an I-CSCF, an S-CSCF, or an IBCF as appropriate for the specific scenario.

When colocated with an I-CSCF, the additional routeing capabilities may be performed in advance of I-CSCF procedures as specified in subclause 5.3, or after I-CSCF procedures have failed to identify an S-CSCF supporting the user identified by the Request-URI.

When colocated with an MGCF, the generated requests can be routed to an I-CSCF or to possible targets of the routeing procedures defined in subclause I.2.

The BGCF procedures specified in subclause 5.6 are a subset of the more general routeing procedures provided in this annex.

I.1A General |R11| p. 858

For all SIP transactions identified, if priority is supported, as containing an 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 additional routeing functionality shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the priority treatment of transactions or dialogs shall be adjusted according to the most recently received authorized Resource-Priority header field or backwards indication value.

If logging is in progress for this dialog, check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 and configured in the trace management object defined in TS 24.323. If a stop trigger event has occurred then stop logging of signalling, else determine, by checking its debug configuration, whether to log the response.

With the exception of 305 (Use Proxy) responses, the additional routeing functionality shall not recurse on 3xx responses.

If the additional routeing functionality inserts its own Record-Route header field, then the additional routeing functionality may require the periodic refreshment of the session to avoid hung states. If the network element requires the session to be refreshed, the additional routeing functionality shall apply the procedures described in Section 8 of RFC 4028.

Based on local policy the additional routeing function shall add in requests and in responses in the P-Charging-Vector header field a "transit-ioi" header field parameter with an entry which identifies the operator network which the request or response is transitting or with a void entry.

Based on local policy the additional routeing function shall delete or void in requests and in responses in the P-Charging-Vector header field any received "transit-ioi" header field parameter value.

I.2 Originating, transit and interconnection routeing procedures p. 859

The additional routeing functionality, or associated functional entity, performing these additional routeing procedures should analyse the destination address, and determine whether to route to another network, directly, or via the IBCF, or to the BGCF, the MGCF or the I-CSCF in its own network. This analysis may use public (e.g., DNS, ENUM) and/or private database lookups, and/or locally configured data and may, based on operator policy, modify the Request-URI (e.g. to remove number prefixes, to translate local numbers to global numbers, to update the Request-URI with the URI including an obtained ported-to routeing number, etc).

In addition, and based upon local policy, the analysis may include the carrier identified by the "cic" tel-URI parameter of the Request-URI and other signalling information from the incoming request as part of the route determination. Examples of other signalling information are: the content of the P-Access-Network-Info header field, the value of the "cpc" tel URI parameter of the P-Asserted-Identity header field, the value of the "phone-context" Tel URI parameter of the Request-URI, the SDP content, the ICSI values in the Contact header field and the content of the P-Asserted-Service header field.

If the additional routeing functionality decides that the request shall be routed via a specific entity (e.g. IBCF), it shall insert the URI of this entity in the Route header of the request.

When provided as a stand-alone entity, the network element performing these functions need not Record-Route the INVITE request.

When provided as a stand-alone entity, the network element performing these functions shall not apply the procedures of RFC 3323 relating to privacy.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call and the additional routeing function shall route such INVITE request received during a certain period of timeto the same next hop.

When colocated with a MGCF, based on local policy for calls originated from circuit-switched networks, if the circuit-switched is a transit network the additional routeing function shall add in requests in the P-Charging-Vector header field a "transit-ioi" header field parameter with an entry which identifies the PSTN network which the request was transitting or with a void entry.

The entity implementing the additional routeing functionality shall remove the P-Served-User header field prior to forwarding the request.

the additional routeing functionality supports indicating the traffic leg as specified in RFC 7549;
the Request-URI does not already include an "iotl" SIP URI parameter, and

NOTE 3:
If an "iotl" SIP URI parameter is included it contains the value "visitedA-homeB" inserted by the TRF in the roaming architecture for voice over IMS with local breakout scenario.
required by local policy;

then the additional routeing functionality shall:

if the Request-URI contains a SIP URI, append the "iotl" SIP URI parameter set to "homeA-homeB" to the Request-URI; and
if the Request-URI contains a tel URI:
- convert the tel URI in the Request-URI to the form of a SIP URI with user=phone; and
- append an "iotl" SIP URI parameter with a value set to "homeA-homeB" in the Request-URI.

I.3 Providing IMS application services in support of transit & interconnection traffics |R11| p. 860

I.3.1 Introduction p. 860

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.

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 p. 860

I.3.2.1 Treatment for dialog and standalone transactions p. 860

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:

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.
remove its own SIP URI from the topmost Route header field;
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.
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;
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;
in case of an initial request for a dialog, based on local policy record-route; and
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:

remove its own URI from the topmost Route header field; and
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 p. 861

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 p. 862

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).

I.4 Loopback routeing procedures |R11| p. 863

I.4.1 Introduction p. 863

In order to support traffics for the roaming architecture for voice over IMS with local breakout the additional routeing functionality will perform the procedures described in this subclause. An additional routeing functionality performing the procedures in this subclause is always located in the visited PLMN and is referred to as Transit and Roaming Function (TRF).

The TRF performs local break out and routes the INVITE request via a specific entity e.g. IBCF or BGCF.

Loopback routeing requires support in the visited network and the home network. If the visited network supports loopback routeing then the P-CSCF will, based on local policy, express this support by adding a g.3gpp.trf feature-capability indicator value to the URI of the desired TRF.

The home network decides based on local operator policy if loopback routeing shall be applied. If loopback routeing is applied, the home network routes the INVITE request back to the TRF located in the visited network indicating that loopback routeing is used by including the g.3gpp.loopback feature-capability indicator in a Feature-Caps header field.

In the loopback scenario OMR as specified in TS 29.079 is used to determine the optimal media path between the visited network and the terminating network without passing through the home network.

I.4.2 TRF procedure p. 863

When the TRF receives an initial request for a dialog, the TRF shall:

retain the "icid-value" header field parameter in the P-Charging-Vector header field;

store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present, and remove the "orig-ioi" header field parameter from the P-Charging-Vector header field. Insert a type 2 "orig-ioi" header field parameter into the P-Charging-Vector header field. Set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network in which the TRF resides. The TRF shall not include the "term-ioi" header field parameter. Store the value of a "transit-ioi" header field parameter received in the P-Charging-Vector header field, if present, and remove the "transit-ioi" header field parameter from the P-Charging-Vector header field before forwarding the request;

if required by local policy, perform number normalization and enum translation in the same way as performed by S-CSCF in subclause 5.4.3.2 step 10);

if the P-Access-Network header field is available, determine the entity for local break out (e.g. IBCF or BGCF) using:

the location of the originating user; and
the destination address,

then include a Route header field set to the URI associated with the determined entity in the forwarded request;

create a Record-Route header field containing the TRF own SIP URI;

remove the "+g.3gpp.loopback" header field parameter from the Feature-Caps header field of the outgoing request;

6A)

if the TRF supports indicating the traffic leg as specified in RFC 7549 and required by local policy:

if the Request-URI in the INVITE request contains a SIP URI, append an "iotl" SIP URI parameter set to "visitedA-homeB" to the Request-URI; and
if the Request-URI in the INVITE request contains a tel URI:
- convert the tel URI in the Request-URI to the form of a SIP URI with user=phone; and
- append the "iotl" SIP URI parameter set to "visitedA-homeB" in the Request-URI; and

route the request based on SIP routeing procedures.

When the TRF receives a 1xx or 2xx response to the INVITE request above, the TRF shall:

store the value of the "transit-ioi" header field parameter received in the P-Charging-Vector header field and remove the "transit-ioi" header field parameter from the P-Charging-Vector header field, if present;
remove the "orig-ioi" header field parameter and the "term-ioi" header field parameter from the P-Charging-Vector header field before forwarding the response; and

NOTE:
Any received "term-ioi" header field parameter will be a type 2 IOI identifying the sending network of the response.
insert in the P-Charging-Vector header field the "orig-ioi" header field parameter, if received in the request, and the type 1 "term-ioi" header field parameter in the response. The TRF shall set the type 1 "term-ioi" header field parameter to a value that identifies the network in which the TRF resides and the type 1 "orig-ioi" header field parameter is set to the previously received value of the type 1 "orig-ioi" header field parameter.

When the TRF receives subsequent requests or responses to subsequent requests containing the "+g.3gpp.loopback" header field parameter from the Feature-Caps header field, the TRF shall remove the "+g.3gpp.loopback" header field parameter from the Feature-Caps header field of the outgoing request or the outgoing response.

When the TRF receives responses to initial or subsequent requests from the terminating side, the TRF shall insert in the P-Charging-Vector header field, if present, the "loopback" header field parameter to the outgoing response.

When the TRF receives subsequent requests from the terminating side, the TRF shall insert in the P-Charging-Vector header field, if present, the "loopback" header field parameter to the outgoing request.

When the TRF receives a subsequent request, the TRF shall:

retain the "icid-value" header field parameter in the P-Charging-Vector header field;
store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present, and remove the "orig-ioi" header field parameter from the P-Charging-Vector header field;
if the subsequent request is:
1. received from originating home network and forwarded to terminating home network, insert a type 2 "orig-ioi" header field parameter into the P-Charging-Vector header field, and set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network in which the TRF resides. The TRF shall not include the "term-ioi" header field parameter; or
2. received from terminating home network and forwarded to originating home network, insert a type 1 "orig-ioi" header field parameter into the P-Charging-Vector header field, and set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network in which the TRF resides. The TRF shall not include the "term-ioi" header field parameter; and
store the value of a "transit-ioi" header field parameter received in the P-Charging-Vector header field, if present, and remove the "transit-ioi" header field parameter from the P-Charging-Vector header field before forwarding the request.

When the TRF receives a response to a subsequent request, the TRF shall:

store the value of the "transit-ioi" header field parameter received in the P-Charging-Vector header field and remove the "transit-ioi" header field parameter from the P-Charging-Vector header field, if present;
remove the "orig-ioi" header field parameter and the "term-ioi" header field parameter from the P-Charging-Vector header field before forwarding the response; and
if the response to the subsequent request is:
1. received from terminating home network and forwarded to originating home network, insert in the P-Charging-Vector header field the "orig-ioi" header field parameter, if received in the request, and the type 1 "term-ioi" header field parameter in the response. The TRF shall set the type 1 "term-ioi" header field parameter to a value that identifies the network in which the TRF resides and the type 1 "orig-ioi" header field parameter is set to the previously received value of the type 1 "orig-ioi" header field parameter; and
2. received from originating home network and forwarded to terminating home network, insert in the P-Charging-Vector header field the "orig-ioi" header field parameter, if received in the request, and the type 2 "term-ioi" header field parameter in the response. The TRF shall set the type 2 "term-ioi" header field parameter to a value that identifies the network in which the TRF resides and the type 2 "orig-ioi" header field parameter is set to the previously received value of the type 2 "orig-ioi" header field parameter.

I.5 Overload control |R11| p. 865

I.5.1 Introduction p. 865

The additional routeing functionality, or associated functional entity, performing additional routeing procedures described in subclause I.3 may support the event-based overload control mechanism.

I.5.2 Outgoing subscriptions to load-control event p. 865

Based on operator policy, the additional routeing functionality may subscribe to the load-control event package with one ore more target SIP entities. The list of target SIP entities is provisioned.

Subscription to the load-control event package is triggered by internal events (e.g. the physical device hosting the SIP entity is power-cycled) or through a management interface.

The AS shall perform subscriptions to the load-control event package to a target entity in accordance with RFC 6665 and with RFC 7200. When subscribing to the load-control event, additional routeing functionality shall:

Send a SUBSCRIBE request in accordance with RFC 6665 and with RFC 7200 to the target entity, with the following elements:
- an Expires header field set to a network specific value;
If the target entity is located in a different network and local policy requires the application of IBCF capabilities, forward the request to an IBCF acting as an exit point.

The additional routeing functionalit shall automatically refresh ongoing subscriptions to the load-control event package either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less.

The additional routeing functionality can terminate a subscription according to RFC 6665.