12.2 SC UE procedures for PS to CS access transfer, PS to CS SRVCC

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

12.2.1 General

The SC UE may be engaged in one or more ongoing sessions before PS to CS SRVCC access transfer is performed. By an ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received.

In the PS to CS SRVCC session continuity procedures the SC UE shall consider only sessions where the following applies

1. the SC UE has completed a reliable offer / answer procedure and the session does have a speech media component; and

2. the speech media is carried over PS bearer with traffic-class conversation with source statistics descriptor ="speech" as specified in 3GPP TS 23.107 [66] or over a PS bearer with QCI=1 as specified in 3GPP TS 23.203 [65].

for access transfer. Sessions considered for PS to CS SRVCC procedures are regarded as full-duplex.

12.2.2 ICS-based

If:

– SC using ICS is enabled;

– the Gm reference point is retained upon PS handover procedure;

– the SC UE is using ICS capabilities as defined in 3GPP TS 24.292 [4]; and

– PS to CS SRVCC procedures (as described in 3GPP TS 24.008 [8]) have been completed;

the SC UE, in order to add Gm control for the newly established CS session, shall:

– send a SIP re-INVITE request for each session with speech media component to be transferred, starting with the session with active speech media component that was most recently made active; and

– within the SDP offer indicate the media line for the speech media component (active or held) as an speech media component over circuit switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall indicate the related local preconditions as met.

NOTE: Within PS to CS SRVCC the handover is performed on PS level. Due to this, the SIP dialog established over the source PS access network stays the same after PS to CS SRVCC procedures, e.g. the IP address of the UE, the Call-ID or the P-CSCF do not change. Therefore in this case a SIP re-INVITE request needs to be sent to add ICS-control for the CS bearer.

12.2.3 Not based on ICS

After successful PS to CS SRVCC procedures (as described in 3GPP TS 24.008 [8]) have been completed, if the SC UE is not using ICS capabilities and the SC UE does not apply the MSC Server assisted mid-call feature as specified in subclause 12.2.3A, the SC UE shall replace the ongoing session with active speech media component which was made active most recently with the newly established CS voice call.

NOTE 1: In the case when ICS is not supported or used and the SC UE does not apply the MSC Server assisted mid-call feature, only the ongoing session with active speech media component which was made active most recently is transferred from PS to CS audio.

If the Gm reference point is:

1) retained upon successful PS handover completion;

NOTE 2: The SC UE knows that the Gm reference point is retained upon PS handover if, following handover, the SC UE has a dedicated PDP context for SIP signalling or has a general-purpose PDP context to carry the IM CN subsystem-related signalling, as described in 3GPP TS 24.229 [2] subclause B.2.2.1.

a) and there are one or more remaining non-speech media component(s) in the IMS session other than the speech media component which were transferred to the CS Target Access Leg; the SC UE shall:

– send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and

– indicate in the SDP offer the speech media component as removed;

b) and there are no more non-speech media component(s) remaining in the IMS session other than the speech media component which was transferred to the CS Target Access Leg; the SC UE shall either:

– send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1 indicating in the SDP offer the speech media component as removed;

– wait for a period of time for a SIP BYE request to be received before clearing the SIP dialog state internally; or

– clear the SIP dialog state internally; or

2) not retained upon successful PS handover completion the SC UE shall clear the SIP dialog state internally.

NOTE 3: If a SIP BYE request is received after the UE has cleared the SIP dialog state internally the UE will send a SIP 481 (Call/Transaction Does Not Exist) response according to RFC 3261 [19].

12.2.3A Not based on ICS with MSC Server assisted mid-call feature

After successful PS to CS SRVCC procedures (as described in 3GPP TS 24.008 [8]), if:

1. the SC UE is not using ICS capabilities;

2. the SC UE supports the MSC Server assisted mid-call feature; and

3. one of the following is true:

A. there is at least one ongoing session with active speech media component and the Feature-Caps header field received by the SC UE at the establishment of the ongoing session with active speech media component, which has been most recently made active, includes the g.3gpp.mid-call feature-capability indicator as described in annex C; or

B. there is no ongoing session with active speech media component and:

– there is no emergency session in early dialog state with active speech media component; or

– there is an emergency session in early dialog state with active speech media component, unless the UE supports the PS to CS SRVCC for emergency session in early dialog state with active speech media component when both the emergency session in early dialog state with active speech media component and a non-emergency call in confirmed dialog state with inactive speech media component exists;

and the Feature-Caps header field received by the SC UE at the establishment of the ongoing session with inactive speech media component which became inactive most recently includes the g.3gpp.mid-call feature-capability indicator as described in annex C;

then the SC UE shall apply the MSC Server assisted mid-call feature as follows:

1. if two or more ongoing sessions with active speech media component exist, the SC UE shall:

A) replace the speech media components of the ongoing session with active speech media component which was most recently made active with the newly established active CS voice call; and

B) replace the speech media component of the ongoing session with active speech media component which was made active second most recently with the newly established held CS voice call;

2. if one ongoing session with active speech media component exists and one or more ongoing sessions with inactive speech media component exist, the SC UE shall:

A) replace the speech media components of the ongoing session with active speech media component with the newly established active CS voice call; and

B) replace the speech media component of the ongoing session with inactive speech media component which was most recently made inactive with the newly established held CS voice calls;

3. if one ongoing session with active speech media component exists and no ongoing sessions with inactive speech media component exist, the SC UE shall replace the speech media component of the ongoing session with active speech media component with the newly established active CS voice call; and

4. if no ongoing session with active speech media component exists and one or more ongoing sessions with inactive speech media component exist, the SC UE shall replace the speech media component of the ongoing session with inactive speech media component which became inactive most recently with the newly established held CS voice call.

For each session, the SC UE shall proceed as specified in subclause 12.2.3.

If two sessions are transferred, and the SC UE does not have a subscription as described in subclause 7.2.2 for the additional transferred session the SC UE shall associate the additional transferred session with CS call:

– with transaction identifier 1; and

– with TI flag value as in mobile terminated call;

and the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "call held" auxiliary state (defined in 3GPP TS 24.083 [43]), and the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call.

NOTE 1: The session with active speech media call state and component transaction identifier value are described in 3GPP TS 24.008 [8].

If single session with inactive speech media component is transferred, and the SC UE does not have a subscription as described in subclause 7.2.2 for the transferred session, then the SC UE shall associate the transferred session with CS call:

– with transaction identifier 0; and

– with TI flag value as in mobile terminated call;

and the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "call held" auxiliary state (defined in 3GPP TS 24.083 [43]), and the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call.

If a transferred session is a session with a conference focus and the SC UE has a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with active speech media component then:

1. the SC UE shall associate the transferred session and the participants extracted in subclause 9.1A with CS calls:

– with transaction identifiers 0, 2, 3, 4, 5 assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile terminating call; and

2. the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "idle" hold auxiliary state (defined in 3GPP TS 24.083 [43]), and the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls.

NOTE 2: The transaction identifier, TI flag value and "active" (U10) state for the first participant are assigned by the call activation procedures for SRVCC in 3GPP TS 24.008 [8].

If a transferred session is a session with a conference focus and the ongoing full-duplex session with active speech media component does not exist and the SC UE has a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with inactive speech media component the SC UE shall associate the transferred session and the participants extracted in subclause 9.1A with CS calls:

– with transaction identifiers 0, 2, 3, 4, 5 assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile terminating call;

and the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "call held" hold auxiliary state (defined in 3GPP TS 24.083 [43]), and the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls.

NOTE 3: The transaction identifier, TI flag value and "active" (U10) state for the first participant are assigned by the call activation procedures for SRVCC in 3GPP TS 24.008 [8].

If a transferred session is a session with a conference focus and:

1. the ongoing full-duplex session with active speech media component exists and the SC UE does not have a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with active speech media component; and

2. the SC UE has a subscription as described in subclause 7.2.2 for the additional transferred session;

then:

1. the SC UE shall associate the transferred session and the participants extracted in subclause 9.1A with CS calls:

– with transaction identifiers 1, 2, 3, 4, 5 assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile terminating call; and

2. the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "call held" hold auxiliary state (defined in 3GPP TS 24.083 [43]), and the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls.

12.2.3B Call in alerting phase

12.2.3B.1 General

The SC UE shall apply the procedures in subclauses 12.2.3B.3.1 and 12.2.3B.3.2 for the PS to CS SRVCC for calls in alerting phase if:

1) the SC UE supports the PS to CS SRVCC for calls in alerting phase; and

2) one of the following is true:

A. there are one or more dialogs supporting sessions with speech media component, such that:

– all dialogs are early dialogs;

– SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs, all such SIP 180 (Ringing) responses are responses to the same SIP INVITE request and at least one of such SIP 180 (Ringing) responses was received in an early dialog supporting session with active speech media component;

– the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C); and

– the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C); or

B. there are one or more dialogs supporting a session with speech media component such that:

– there are one or more early dialogs and the remaining dialogs are confirmed dialogs;

– SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs, all such SIP 180 (Ringing) responses are responses to the same SIP INVITE request and at least one of such SIP 180 (Ringing) responses was received in an early dialog supporting session with active speech media component;

– all the confirmed dialogs support sessions with inactive speech media component;

– SC UE does not apply the MSC server assisted mid-call feature as described in subclause 12.2.3A;

– in those early dialogs, the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C); and

– in those early dialogs, the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C); or

C. there is one dialog supporting session with speech media component, such that:

– the dialog is an early dialog;

– SIP 180 (Ringing) response to SIP INVITE request was sent in the early dialog supporting session with active speech media component;

– the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C); and

– the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C); or

D. there are one or more dialogs supporting a session with speech media component such that:

– there is one early dialog and the remaining dialogs are confirmed dialogs;

– SIP 180 (Ringing) response to SIP INVITE request was sent in the early dialog supporting session with active speech media component;

– all the confirmed dialogs support sessions with inactive speech media component;

– SC UE does not apply the MSC server assisted mid-call feature as described in subclause 12.2.3A;

– in those early dialogs, the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C); and

– in those early dialogs, the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C).

The SC UE shall apply the procedures in subclauses 12.2.3B.4.1 for the PS to CS SRVCC for calls in alerting phase if:

1) the SC UE supports the PS to CS SRVCC for calls in alerting phase;

2) one of the following is true:

A) there are two or more dialogs supporting more than one session with speech media component, such that:

a) the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C);

b) the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C).

c) one dialog supporting a session in the confirmed state with active speech media component and remaining dialogs are early dialogs; and

d) SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs, all such SIP 180 (Ringing) responses are responses to the same SIP INVITE request and at least one of such SIP 180 (Ringing) responses was received in an early dialog supporting session with active speech media component; or

B) there are two or more dialogs supporting sessions with speech media component, such that:

a) the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C); and

b) the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C);

c) one or more dialogs are confirmed dialogs supporting sessions with active speech media components, there are one or more dialogs that are confirmed dialogs with inactive speech media component and remaining dialogs are early dialogs;

d) SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs, all such SIP 180 (Ringing) responses are responses to the same SIP INVITE request and at least one of such SIP 180 (Ringing) responses was received in an early dialog supporting session with active speech media component; and

e) the SC UE does not apply the MSC server assisted mid-call feature as described in subclause 12.2.3A.

The SC UE shall apply the procedures in subclauses 12.2.3B.3.3 if one of the following is true:

1) there are zero, one or more dialogs supporting a session with speech media component and a SIP INVITE request was sent by SC UE such that:

A) all dialogs are early dialogs created by a SIP response to the SIP INVITE request;

B) a final SIP response to the SIP INVITE request has not been received yet;

C) a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any existing early dialog created by a SIP response to the SIP INVITE request;

D) the SC UE included in the SIP INVITE request a Contact header field containing the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C; and

E) a SIP 1xx response to the SIP INVITE request was received where the SIP 1xx response contained a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C; or

NOTE: The SC UE can have zero dialogs if all the early dialogs were terminated by 199 (Early Dialog Terminated) as described in RFC 6228 [80].

2) there are one or more dialogs supporting a session with speech media component such that:

A) there are zero, one or more early dialogs and the remaining dialogs are confirmed dialogs;

B) all the confirmed dialogs support sessions with inactive speech media component;

C) the UE does not apply the MSC server assisted mid-call feature according to subclause 12.2.3A;

D) a SIP INVITE request was sent by SC UE such that:

a) all early dialogs are created by a SIP response to the SIP INVITE request;

b) a final SIP response to the SIP INVITE request has not been received yet;

c) a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any existing early dialog created by a SIP response to the SIP INVITE request;

d) the SC UE included in the SIP INVITE request a Contact header field containing the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C; and

e) a SIP 1xx response to the SIP INVITE request was received where the SIP 1xx response contained a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C.

The SC UE shall apply the procedures in subclauses 12.2.3B.3.4 if it supports PS to CS SRVCC for terminating calls in pre-alerting phase and if one of the following is true:

1) there is one dialog supporting a session with speech media component and a SIP INVITE request was received by SC UE such that:

A) the dialog is an early dialog created by a SIP response to the SIP INVITE request;

B) a final SIP response to the SIP INVITE request has not been sent yet;

C) a SIP 180 (Ringing) response to the SIP INVITE request has not been sent yet;

D) the SC UE has sent a SIP 1xx response to the SIP INVITE request with a Contact header field containing the g.3gpp.ps2cs-srvcc-term-pre-alerting media feature tag (as described in annex C); and

E) the SIP INVITE request contained a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator as described in annex C; or

2) there are one or more dialogs supporting a session with speech media component such that:

A) there is one early dialog and the remaining dialogs are confirmed dialogs;

B) all the confirmed dialogs support sessions with inactive speech media component;

C) the UE does not apply the MSC server assisted mid-call feature according to subclause 12.2.3A;

D) a SIP INVITE request was received by SC UE such that:

a) the early dialog is created by a SIP response to the SIP INVITE request;

b) a final SIP response to the SIP INVITE request has not been sent yet;

c) a SIP 180 (Ringing) response to the SIP INVITE request has not been sent yet;

d) the SC UE has sent a SIP 1xx response to the SIP INVITE request with a Contact header field containing the g.3gpp.ps2cs-srvcc-term-pre-alerting media feature tag (as described in annex C); and

e) the SIP INVITE request contained a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator as described in annex C.

12.2.3B.1A Considerations for MSC server assisted mid-call feature

If the SC UE supports both the PS to CS SRVCC for calls in alerting phase and the MSC server assisted mid-call feature then in addition to supporting the procedures specified in subclauses 12.2.3B.3 and 12.2.3B.4.1, it shall apply the procedures specified in subclause 12.2.3B.4.2 where one of the following is true:

1) there are two or more dialogs supporting sessions with speech media component, such that:

a) the SC UE has sent a Contact header field containing the g.3gpp.srvcc-alerting media feature tag (as described in annex C);

b) the SC UE has received a Feature-Caps header field containing the g.3gpp.srvcc-alerting feature-capability indicator (as described in annex C);

c) one or more dialogs are in the confirmed state supporting a session with inactive speech media component and the remaining dialog(s) are early dialog(s);

d) SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs, all such SIP 180 (Ringing) responses are responses to the same SIP INVITE request and at least one of such SIP 180 (Ringing) responses was received in an early dialog supporting session with active speech media component; and

e) the SC UE applies the MSC server assisted mid-call feature according to subclause 12.2.3A;

2) there are one or more dialogs supporting sessions with speech media component according to the following conditions:

A) there are zero, one or more early dialogs and the remaining dialog(s) are confirmed dialog(s);

B) all the confirmed dialogs support sessions with inactive speech media component;

C) the UE applies the MSC server assisted mid-call feature according to subclause 12.2.3A;

D) a SIP INVITE request was sent by SC UE such that:

a) all the early dialogs are created by a SIP response to the SIP INVITE request;

b) a final SIP response to the SIP INVITE request has not been received yet;

c) a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any existing early dialog created by a SIP response to the SIP INVITE request;

d) the SC UE included in the SIP INVITE request a Contact header field containing the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C; and

e) a SIP 1xx response to the SIP INVITE request was received where the SIP 1xx response contained a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C.

12.2.3B.2 Assignment of Transaction Identifiers to the transferred sessions

If the SC UE applies the procedures in subclause 12.2.3B.3 and the SC UE only has a single call:

– in alerting phase following access transfer;

– in pre-alerting phase and the SC UE supports the PS to CS SRVCC for originating calls in pre-alerting phase; or

– in pre-alerting phase and the SC UE supports the PS to CS SRVCC for terminating calls in pre-alerting phase.

the SC UE shall associate this session with transaction identifier value and TI flag as described in 3GPP TS 24.008 [8].

If the SC UE applies the procedures in subclause 12.2.3B.4 and the SC UE has an established session and an additional session in alerting phase or pre-alerting phase following access transfer, then the SC UE shall associate the transferred session that was in alerting phase or pre-alerting phase with CS call with transaction identifier 1 and TI flag value as in mobile terminated call.

NOTE: For the procedures in subclause 12.2.3B.4.2, the held transaction identifier value is described in subclause 12.2.3A as for single inactive session transfer and the active session transaction identifier value is described in 3GPP TS 24.008 [8].

12.2.3B.3 Single call in alerting phase or pre-alerting phase

12.2.3B.3.1 Terminating call in alerting phase

If the SC UE:

– has received a terminating call which is in the early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and

– successfully performs access transfer to the CS domain;

then the UE continues in Ringing state in CS, i.e. UE moves to Call Received (U7) state as described in 3GPP TS 24.008 [8].

If the SC UE:

– has received a terminating call which is in the early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and

– has sent a SIP 200 (OK) response (i.e. user answers the call when in the PS domain) prior to successfully performing access transfer to the CS domain;

then the UE sends a CC CONNECT message and will finally transitions to Active (U10) state as described in 3GPP TS 24.008 [8].

12.2.3B.3.2 Originating call in alerting phase

If the SC UE has initiated an outgoing call which is in the early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1 and the SC UE successfully performs access transfer to the CS domain, then the UE continues in Ringing state in CS, i.e. UE moves to Call Delivered (U4) state as described in 3GPP TS 24.008 [8]. If the UE has received a SIP 180 (Ringing) response, depending on the type of the ringing tone, the UE behaves as following:

– if the SC UE is playing the locally generated ringing tone, then the UE keeps playing the locally generated ringing tone; and

– if the SC UE is playing network-generated ringing tone as early media, then the UE attaches the user connection to the MSC server, as specified in 3GPP TS 24.008 [8].

12.2.3B.3.3 PS to CS SRVCC for originating calls in pre-alerting phase

If the SC UE supports the PS to CS SRVCC for originating calls in pre-alerting phase and this subclause is invoked according to the conditions in subclause 12.2.3B.1 and the SC UE successfully performs access transfer to the CS domain, then the UE continues the call in the CS domain in the "Mobile originating call proceeding" (U3) call state as described in 3GPP TS 24.008 [8].

If the SC UE has generated and rendered the locally generated communication progress information before the access transfer to the CS domain, the UE keeps generating and rending the locally generated communication progress information after the access transfer to the CS domain.

If the SC UE has rendered received early media before the access transfer to the CS domain, the UE attaches the user connection, as specified in 3GPP TS 24.008 [8].

12.2.3B.3.4 PS to CS SRVCC for terminating calls in pre-alerting phase

If the SC UE supports the PS to CS SRVCC for terminating calls in pre-alerting phase and this subclause is invoked according to the conditions in subclause 12.2.3B.1 and the SC UE successfully performs access transfer to the CS domain, then the UE continues the call in the CS domain in the "Call present" (U6) call state as described in 3GPP TS 24.008 [8].

12.2.3B.4 Established call with a session in alerting phase or in pre-alerting phase

12.2.3B.4.1 Active session with incoming call in alerting phase

If the SC UE:

– has a session with an active speech media component and has received an incoming call (waiting) which is in the early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and

– successfully performs access transfer to the CS domain;

then the UE moves to Call Received (U7) state (defined in 3GPP TS 24.008 [8]) for the incoming call (waiting) (i.e. continues in Ringing state in CS for the incoming call waiting).

12.2.3B.4.2 Held session with new outgoing call in alerting phase or in pre-alerting phase

If the SC UE:

– has a session with an inactive speech media component and has initiated a new outgoing call which is in the early dialog state according to the conditions in subclauses 12.1 and 12.2.3B.1; and

– successfully performs access transfer to the CS domain;

then:

– if the new outgoing call is in alerting phase, the UE moves to Call Delivered (U4) state (defined in 3GPP TS 24.008 [8]) for the new outgoing call (i.e. UE continues in Ringing state in CS for the outgoing call);

– if the new outgoing call is in pre-alerting phase, the UE moves to Mobile originating call proceeding (U3) state (defined in 3GPP TS 24.008 [8]) for the new outgoing call; and

– the UE moves to Call Active (U10) state (defined in 3GPP TS 24.008 [8]) and Call Held Auxiliary State (defined in 3GPP TS 24.083 [43]) for the held call.

12.2.4 Abnormal cases

12.2.4.1 Confirmed dialog

If the SC UE engaged in one or more ongoing IMS sessions and:

– receives a SM NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re-establishment required" as described in 3GPP TS 24.008 [8] or 3GPP TS 24.301 [52] or receives an event notification containing an "SRVCC handover cancelled, IMS session re-establishment required" indicator from the lower layers as described in 3GPP TS 24.501 [98] depending on the access in use; or

– does not successfully retune to the 3GPP UTRAN or 3GPP GERAN after it receives the handover command from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 3GPP TS 25.331 [61]);

then the SC UE shall send a SIP re-INVITE request containing:

1) an SDP offer, including the media characteristics as used in the existing dialog; and

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in IETF RFC 3326 [57] and with reason-text text set to either "handover cancelled" or "failure to transition to CS domain";

by following the rules of 3GPP TS 24.229 [2] in each transferred session.

12.2.4.2 Early dialog

If the SC UE is engaged in a session in early dialog state and:

– receives a SM NOTIFICATION message containing an "SRVCC handover cancelled, IMS session re-establishment required" as described in 3GPP TS 24.008 [8] or 3GPP TS 24.301 [52] or receives an event notification containing an "SRVCC handover cancelled, IMS session re-establishment required" indicator from the lower layers as described in 3GPP TS 24.501 [98]depending on the access in use; or

– does not successfully retune to the 3GPP UTRAN or 3GPP GERAN after it receives the handover command from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 3GPP TS 25.331 [61]);

then the SC UE shall:

a) send a SIP UPDATE request containing:

1) an SDP offer, including the media characteristics as used in the existing dialog; and

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in IETF RFC 3326 [57], and with reason-text set to either "handover cancelled" or "failure to transition to CS domain";

by following the rules of 3GPP TS 24.229 [2] in each transferred session; and

b) if the SC UE is a terminating side UE and has already sent a CC CONNECT on the target access leg, send a SIP 200 (OK) response to the SIP INVITE request received on the source access leg.

12.2.4.3 Moving from a 3GPP access to non-3GPP access colliding with SRVCC access transfer

If the SC UE engaged in one or more IMS sessions receives a handover command from the eNodeB (as described in 3GPP TS 36.331 [62]) or from the NodeB (as described in 3GPP TS 25.331 [61]) when the UE is engaged in moving the PDN connection from an 3GPP access to a non-3GPP access as described in 24.302 [84], the UE shall either:

1) accept the handover command and abort the move to the non-3GPP access; or

2) continue with the move to the non-3GPP access and ignore the handover command.

If the SC UE continues with the move to the non-3GPP access, the SC UE shall for each transferred session send a SIP re-INVITE request containing:

1) an SDP offer, including the media characteristics as used in the existing dialog; and

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in IETF RFC 3326 [57];

NOTE: The reason-text text in the Reason header field can be set to either "handover cancelled" or "failure to transition to CS domain".

by following the rules of 3GPP TS 24.229 [2].