TS 24.237 Proposed Changes

The Oracle Communications Session Border Controller implements a proposed change in the processing of failed or cancelled SRVCC sessions. The new processing model has been presented to the 3GPP for inclusion in TS 24.237, IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuity; Stage 3.

Sections 12.2.4.13, 12.3.3.1, and 12.3.3.1A of 3GPP TS 24.237, IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuity; Stage 3, describe procedures in response to SRVCC handover cancellation. These procedures allow the UE to generate a e-INVITE request with the Reason header field containing a value of “SIP”, a “cause” parameter set to a value of “487” (Request Terminated), and with reason-text parameter set to a value of either “handover cancelled” or “failure to transition to CS domain”.

SCC AS processing, which does nor release the original access leg, is defined in Section 12.3.3.1 and subclause 12.3.3.1A. Section 13.3.1 describes the handling of subsequent UPDATE requests. There are, however, no defined procedures at the ATCF response to this scenario with the result that the ATCF fails to reconfigure the ATGW to reconnect the bearer in LTE.

Oracle Corporation, in conjunction with other interested parties has proposed the addition of a new Section 12.7.2.3.3 to TS 24.237. This section requires the following ACTF behavior.

Requirement 1: When the ATCF receives either a

SIP BYE request on the Source Access Leg containing a Reason header field containing a SIP 503 (Service Unavailable) response code, that is terminating an established dialog or an early dialog on the Source Access Leg
SIP CANCEL request on the Source Access Leg with the Reason header field containing a SIP 503 (Service Unavailable) response code then, that is terminating an early dialog on the Source Access Leg originated by the SC UE, or
SIP 503 (Service Unavailable) response on the Source Access Leg, that is terminating an early dialog on the Source Access Leg terminating at the SC UE

Then -- The ATCF shall retain session state information and ATGW resources associated with the session until either it receives a SIP INVITE request due to STN-SR, or a specified time period elapses (default value is 8 seconds).

The session remains recognizable for SRVCC access transfer as described in Section 12.7.2.1.

The SIP BYE request is forwarded to the SCC AS, which also delays release of the session, as described in Section 12.3.3.2.

Requirement 2: If the transferable session set determined in Section 12.7.2.1 does not contain any sessions and the identity in the P-Asserted-Identity header field is a C-MSISDN that is not bound to a registration path in the ATCF, the ATCF shall respond with a SIP 404 (Not Found) response.

Requirement 3: When the ATCF receives a SIP re-INVITE request containing Reason header field containing protocol “SIP” and reason parameter “cause” with value “487” on the original source access leg,

after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR, and
the SIP INVITE request due to ATU-STI transaction is not yet completed

Then -- The ATCF shall wait until this transaction has completed and then continue with the steps described in Requirement 4.

Requirement 4: When the ATCF receives a SIP re-INVITE request(s) containing protocol “SIP” and reason parameter “cause” with value “487” after having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR,

Then -- The ATCF shall act as B2BUA as described in Section 5.6 and shall.

Interact with ATGW to provide information needed in the procedures below and to request ATGW to start forwarding the media from the remote UE to the local UE. The details of interaction between ATCF and ATGW are out of scope of this document.
Send a SIP 200 (OK) response to the received SIP re-INVITE request. The SIP 200 (OK) response contains the SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW and the media used on the original source access leg as before the access transfer; and
Forward the received reINVITE with the Reason header intact to the SCC AS on the existing source dialog with the SDP offer containing the ATGW IP addresses and ports towards the remote UE as provided by the ATGW.

This proposed behavior, which requires no user configuration) is implemented in Version S-CX7.2.0 and later releases.

Related call flows are shown below.

BYE before handover INVITE

Cancellation after handover complete.