12.3 SCC AS

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

12.3.0 General

In the Single Radio access transfer procedures the SCC AS shall only consider sessions that have the necessary media components that meet the criteria for performing Single Radio access transfer as defined in subclause 4.2.2.

On receipt of a SIP INVITE request due to STN-SR or a SIP INVITE request due to ATU-STI the SCC AS shall for all sessions and dialogs in the transferable session set created in subclauses 12.3.0B or 12.7.2 discard any SIP message (i.e. any SIP request or SIP response) from the remote UE to the SC UE that are releated to the call until the procedures in the following subclauses states that forwarding of SIP shall be started again. The SIP 200 (OK) response to the UPDATE request and the SIP 200 (OK) respose to the re-INVITE request related to the ongoing access transfer shall be handled as specified in the following subclauses.

NOTE: SIP responses sent reliably to the initial SIP INVITE request and SIP requests will be retransmitted by the remote UE if SIP responses and SIP requests are dropped by the SCC AS.

All the time during an ongoing PS to CS SRVCC access transfer the SCC AS shall be prepared to receive SIP messages from the SC UE or the MSC server releated to the call (i.e. not related to the ongoing access transfer). When a SIP message releated to the call is received from the SC UE or the MSC server the SCC AS shall forward the SIP message towards the remote UE according to procedures in 3GPP TS 24.229 [2] and the present document.

When a PS to CS SRVCC access transfer is completed, the SCC AS shall perform interactions between the remote UE leg and the target access leg as described in subclause 12.3.11.

12.3.0A Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for PS to CS SRVCC:

– SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request-URI and containing an SDP offer with active speech media component only. These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are known as "SIP INVITE requests due to STN-SR".

– SIP INVITE requests routed to the SCC AS due to ATU-STI for PS to CS SRVCC in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to ATU-STI for PS to CS SRVCC".

– SIP INVITE request routed to the SCC AS contains the additional transferred session SCC AS URI for PS to CS SRVCC in the Request-URI, such a request is in this document known as "SIP INVITE request transferring additional session for PS to CS SRVCC".

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for vSRVCC:

– SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request-URI and containing an SDP offer with both active speech and video media components only, which includes the default codecs for speech and video (as specified in 3GPP TS 26.111 [69]). These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are known as "SIP INVITE requests for audio and video due to STN-SR".

12.3.0B Determine the transferable session set

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg the SCC AS shall determine the transferable session set.

A session is in the transferable session set when the session:

1) is a session of the SC UE whose private user identity is associated with the C-MSISDN that is contained in the P-Asserted-Identity header field of the SIP INVITE request; and

2) has completed a reliable offer answer procedure and is a session with speech media component.

The SCC AS shall:

1) if the conditions described in subclause 12.3.2.1 are fulfilled, follow the procedures in subclause 12.3.2;

2) if the conditions described in subclause 12.3.4.1 for applying the PS to CS SRVCC for calls in alerting phase in subclauses 12.3.4.2 or 12.3.4.3 are fulfilled, follow the procedures in subclause 12.3.4.2 or 12.3.4.3;

2A) if the conditions described in subclause 12.3.4.1 for applying the PS to CS SRVCC for calls in originating pre-alerting phase in subclause 12.3.4.3 are fulfilled, follow the procedures in subclause 12.3.4.3; and

3) if none of the conditions 1), 2) or 2A) above are fulfilled follow the procedure in subclause 12.3.1.

12.3.1 SCC AS procedures for PS to CS access transfer, PS to CS SRVCC

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg the SCC AS shall associate the SIP INVITE request with a session:

– within the transferable session set;

– with active speech media component that was most recently made active; and

– the related dialog is in confirmed state.

If no confirmed dialogs supporting a session with active speech media component exists in the transferable session set the SCC AS shall:

1) send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR;

2) if the transferable session set contains dialogs supporting sessions with speech media component (inactive speech media component or in an early dialog state):

a) if the speech media component is the only media component in the dialog then release the remote leg as specified in 3GPP TS 24.229 [2]; and

b) if the speech media component is not the only media component in the dialog then modify the remote leg and remove the speech media component as specified in 3GPP TS 24.229 [2].

If confirmed dialogs supporting a session with active speech media component exist in the transferable session set the SCC AS shall:

1) send a SIP re-INVITE request towards the remote UE and in a new SDP offer, include the media characteristics as received in the SIP INVITE request due to STN-SR, by following the rules of 3GPP TS 24.229 [2]; or

2) send a SIP re-INVITE request towards the remote UE according to the conditions depicted in subclause 12.3.5 and in a new SDP offer, include the media characteristics as received in the SIP INVITE request due to ATU-STI for PS to CS SRVCC, by following the rules of 3GPP TS 24.229 [2].

Upon receiving the SIP 2xx response to the SIP re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP INVITE request due to STN-SR on the target access leg by following the rules of 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response to the SIP INVITE request due to STN-SR as follows:

1) include SDP answer containing the relevant media parameter of the SDP answer in the received response;

2) if the SCC AS supports the PS to CS SRVCC of calls in alerting phase, include the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C in the Feature-Caps header field according to IETF RFC 6809 [60]; and

3) include the signalling elements described in subclause 6A.4.3A.

If the SCC AS supports the PS to CS SRVCC for calls in alerting phase and if the conditions for a terminating call in alerting phase specified in subclause 12.3.4.1 for a session in the transferable session set are fulfilled, the SCC AS shall follow the procedures in the subclause 12.3.4.4 and then continue with the procedures in this subclause.

Upon receipt of the ACK request from the MSC server, start forwarding SIP messages from the remote UE to the MSC server for the session with active speech media component as specified in 3GPP TS 24.229 [2] and the present document.

The SCC AS shall remove non-transferred audio components and superfluous session as specified in subclause 12.3.8.

12.3.2 SCC AS procedures for PS to CS access transfer with MSC server assisted mid-call feature, PS to CS SRVCC

12.3.2.1 General

The SCC AS shall apply the MSC Server assisted mid-call feature as described in subclause 12.3.2.2 if:

1. one of the conditions is true:

a. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact header field during establishment of the session associated with the SIP INVITE request due to STN-SR, the SCC AS local policy requires delaying application of the MSC Server assisted mid-call feature for a time given by local policy and the transfer request for the session with inactive speech media component has not been received within a time given by local policy after the reception of the SIP INVITE request due to STN-SR;

b. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact header field during establishment of the session associated with the SIP INVITE request due to STN-SR and the SCC AS local policy does not require delaying application of the MSC Server assisted mid-call feature for a time given by local policy; or

c. the SC UE did not include the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact header field during establishment of the session associated with the SIP INVITE request due to STN-SR;

2. the Contact header field of the SIP INVITE request due to STN-SR or SIP INVITE request due to ATU-STI for PS to CS SRVCC includes the g.3gpp.mid-call media feature tag as specified in annex C; and

3. one of the following is true for dialogs in the transferable session set:

A. at least one confirmed dialog supporting a session with active speech media component exists and the following is true for the confirmed dialog supporting a session with the active speech media component which has been most recently made active:

– the Contact header field provided by the SC UE at the establishment of the dialog includes the g.3gpp.mid-call media feature tag as described in annex C; and

– the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog included g.3gpp.mid-call feature-capability indicator; or

B. no confirmed dialog supporting a session with active speech media component exists and the following is true for the confirmed dialog supporting a session with inactive speech media component which became inactive most recently:

– the Contact header field provided by the SC UE at the establishment of the dialog includes the g.3gpp.mid-call media feature tag as described in annex C; and

– the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog included the g.3gpp.mid-call feature-capability indicator.

12.3.2.2 Transfer of the first session

When the SCC AS applies the MSC Server assisted mid-call feature for transfer of the first session the SCC AS shall select the first session to transfer as follows.

The first session to transfer is a session in the transferable session set such that:

1. if one or more confirmed dialog supporting a session with active speech media component exists in the transferable session set then:

– select the confirmed dialog supporting a session with the active speech media component which became active most recently; and

2. if no confirmed dialog supporting a session with active speech media component exists in the transferable set but one or more confirmed dialogs supporting a session with inactive speech media component exists for the user then:

– select the confirmed dialog supporting a session with inactive speech media component that became inactive most recently.

If the speech media component of the SDP offer in the SIP INVITE request due to ATU-STI is the same as the speech media component of the SDP negotiated by the ATCF in the first session to transfer, the SCC AS shall send a SIP 200 (OK) response to the SIP INVITE request. The SCC AS shall populate the SIP 200 (OK) response to the SIP INVITE request as follows:

1) include SDP answer containing the speech media component of the SDP negotiated by SCC AS towards ATCF in the first session to transfer;

2) include:

– the g.3gpp.mid-call feature-capability indicator as described in annex C; and

– if the SCC AS supports the PS to CS SRVCC of calls in alerting phase, the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;

in the Feature-Caps header field according to IETF RFC 6809 [60]; and

3) include the signalling elements described in subclause 6A.4.3A.

If the speech media component of the SDP offer in the SIP INVITE request due to ATU-STI is different from the speech media component of the SDP negotiated by the ATCF in the first session to transfer or if the SIP INVITE request due to STN-SR was received, the SCC AS shall send a SIP re-INVITE request towards the remote UE with a new SDP offer, such that:

1) if a session with the confirmed dialog supporting a session with active speech media component was selected, include the media characteristics as received in the SIP INVITE request due to ATU-STI or the SIP INVITE request due to STN-SR, by following the rules of 3GPP TS 24.229 [2] including directionality attributes indicating the directionality used at SC UE; and

2) if a session with the confirmed dialog supporting a session with inactive speech media component was selected then include an SDP offer describing the audio media streams as negotiated in the session with the remote UE and:

– if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and

– if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality.

Upon receiving the SIP 2xx response to the SIP re-INVITE request the SCC AS shall:

1) send the SIP 200 (OK) response to the SIP INVITE request due to STN-SR on the target access leg populated as follows:

a) in the SDP answer, use the relevant media parameter of the SDP answer in the received response;

b) include:

– the g.3gpp.mid-call feature-capability indicator as described in annex C; and

– if the SCC AS supports the PS to CS SRVCC of calls in alerting phase, the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;

in the Feature-Caps header field according to IETF RFC 6809 [60]; and

c) include the signalling elements described in subclause 6A.4.3A.

Upon receiving the SIP ACK request related to the SIP 200 (OK) response to the SIP INVITE request, the SCC AS shall start forwarding SIP messages from the remote UE to the MSC server for the session with active or inactive speech media component as specified in 3GPP TS 24.229 [2] and the present specification.

Upon receiving the SIP ACK request related to the SIP 200 (OK) response to the SIP INVITE request and if:

1) the session associated with the SIP INVITE request due to STN-SR is related to a subscription as described in subclause 7.3.3; and

2) a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE within the related subscription;

then the SCC AS shall send a SIP INFO request towards the MSC Server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows:

1) include the Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp.mid-call package name; and

2) include application/vnd.3gpp.mid-call+xml XML body associated with the info package according to IETF RFC 6086 [54] and containing the participants extracted as specified in the subclause 9.1A of the subscription related to the session associated with the SIP INVITE request due to STN-SR as described in subclause 7.3.3.

Upon receiving the SIP 2xx response to the SIP INFO request or receiving the ACK related to the SIP 200 (OK) response to the SIP INVITE request when the SIP INFO request was not sent, the SCC AS shall:

– if one more confirmed SIP dialogs supporting a session with speech media component exist in the transferable session set transfer the additional second confirmed SIP dialog as described in subclause 12.3.2.3 and then continue with the procedures in this subclause; and

– if no more confirmed SIP dialog supporting a session with speech media component exist in the transferable session set but SCC AS support the PS to CS SRVCC for calls in alerting phase and the conditions in the subclause 12.3.4.1 are fulfilled, perform the actions in subclause 12.3.4.4 and then continue with the procedures in this subclause.

The SCC AS shall remove non-transferred audio components and superfluous session as specified in subclause 12.3.8.

12.3.2.3 Transfer of an additional session

When the SCC AS applies the MSC Server assisted mid-call feature for transfer of the additional session the SCC AS shall select the additional session to transfer as a session in the transferable session set such that:

1. if more than one confirmed dialog supporting a session exists in the transferable session set, and exactly one confirmed dialog supporting a session with active speech media component exists and there is at least one remaining confirmed dialog supporting a session with inactive speech media component then:

– select the confirmed dialog supporting a session with inactive speech media component that became inactive most recently; and

2. if more than one confirmed dialog supporting a session with active speech media component exists in the transferable session set then:

– select the confirmed dialog supporting a session with the active speech media component which became active second most recently.

When the SCC AS transfers the selected additional session the SCC AS shall:

A) send a SIP REFER request towards the MSC Server in accordance with the procedures specified in 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to STN-SR. ; or send a SIP REFER request towards the ATCF in accordance with the procedures specified in 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to ATU-STI for PS to CS SRVCC. The SCC AS shall populate the SIP REFER request as follows:

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20];

3. the Refer-To header field containing the additional transferred session SCC AS URI for PS to CS SRVCC and the following URI header fields containing information related to the additional transferred session:

a. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the session with the SC UE;

b. the Require URI header field populated with the option tag value "tdialog";

c. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity provided by the remote UE during the session establishment;

d. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity of the SC UE provided during the session establishment;

e. the Content-Type header field with "application/sdp";

f. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the session with the remote UE and:

– if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and

– if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality; and

g. optionally the P-Asserted-Identity URI header field containing value of the P-Asserted-Identity header field of the received SIP INVITE request;

4. the Content-Type header field with the value set to MIME type as specified in the subclause D.1.3;

5. a XML body compliant to the XML schema specified in the subclause D.1.2;

6. if:

a. the session associated with the SIP INVITE request due to STN-SR, is not related to any subscription as described in subclause 7.3.3;

b. the additional transferred session is related to a subscription as described in subclause 7.3.3; and

c. a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the SC UE within the related subscription;

then SCC AS shall populate the XML body with the participants extracted as specified in the subclause 9.1A of the subscription related to the additional transferred session as specified in subclause 7.3.3; and

7. if:

a. SCC AS supports CS to PS SRVCC;

b. the SIP INVITE request due to STN-SR contains Accept header field with application/vnd.3gpp.srvcc-ext+xml MIME type;

c. a private user identity of a UE (i.e. other than those according to 3GPP TS 23.003 [12], subclause 20.3.3) is associated with the C-MSISDN in the P-Asserted-Identity header field of the SIP INVITE request due to STN-SR;

d. a binding of a contact address exists for the private user identity of the UE:

i) where the g.3gpp.cs2ps-srvcc media feature tag is associated with the contact address of the UE; and

ii) such that SIP REGISTER request which registered the binding contained a Feature-Caps header field with the g.3gpp.atcf feature-capability indicator and with g.3gpp.cs2ps-srvcc feature-capability indicator;

e. the CS to PS SRVCC capability indication is indicated for the private user identity of the UE; and

f. the private user identity of the UE has the CS to PS SRVCC allowed indication in the subscription data;

then:

a. a MIME body of application/vnd.3gpp.srvcc-ext+xml MIME type:

i) containing ATU management URI of the ATCF serving the SC UE;

NOTE 1: The ATCF management URI of the ATCF is the URI contained in the g.3gpp.atcf-mgmt-uri feature-capability indicator included in a Feature-Caps header field of the SIP REGISTER request, which registered the binding for the private user identity of the UE.

ii) containing C-MSISDN; and.

iii) not indicating that information relate to a registration of MSC server with IMS.

When the SCC AS receives the SIP INVITE request transferring additional session for PS to CS SRVCC, the SCC AS shall:

1) associate the SIP INVITE request transferring additional session for PS to CS SRVCC with a previously established SIP dialog i.e. identify the source access leg;

NOTE 2: The SIP dialog on the source access leg is identified by matching the dialog present in the Target-Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE request transferring additional session for PS to CS SRVCC with the previously established SIP dialog.

NOTE 3: By a previously established SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received.

2) if the SCC AS is unable to associate the SIP INVITE with a unique previously established SIP dialog, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not processes the remaining steps;

3) if the number of media lines in the target access leg is less than the number of media lines in the source access leg or the media type for the corresponding media lines is not the same as in the original session, send a SIP 404 (Not Found) response to reject the SIP INVITE request relating to the access transfer and not process the remaining steps;

4) if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is different to the speech media component of the SDP received in the source access leg, send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall populate the SIP re-INVITE request with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following media information:

A) the media characteristics as received in the SIP INVITE request transferring additional session for PS to CS SRVCC for media streams whose port is not set to zero; and

B) for the media streams in the SIP INVITE request transferring additional session for PS to CS SRVCC whose port is set to zero, include the corresponding media characteristics of those streams from the source access leg; and

5) if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is the same as the speech media component of the SDP received in the source access leg, send the SIP 200 (OK) response to the SIP INVITE request transferring additional session for PS to CS SRVCC. In the SIP 200 (OK) response, the SCC AS shall:

a) include the SDP sent by the SCC AS in the source access leg;

b) include the g.3gpp.mid-call feature-capability indicator as described in annex C in the Feature-Caps header field; and

c) include the signalling elements described in subclause 6A.4.3A.

Upon receiving the SIP 2xx response to the SIP re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP INVITE request transferring additional session for PS to CS SRVCC on the target access leg populated as follows:

1) use the relevant media parameter of the SDP answer in the received response;

2) include the g.3gpp.mid-call feature-capability indicator as described in annex C in the Feature-Caps header field; and

3) include the signalling elements described in subclause 6A.4.3A.

Upon receiving the SIP ACK request from the MSC server, the SCC AS shall start forwarding SIP messages from the remote UE to the MSC server for the additional session as specified in 3GPP TS 24.229 [2] and the present specification.

12.3.3 SCC AS procedures for PS to CS SRVCC, abnormal case

12.3.3.1 PS to CS SRVCC cancelled by MME/SGSN or failure by UE to transition to CS domain for ongoing session

When the SCC AS 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; or

– the original source access leg of the additional transferred session if the SCC AS applies the MSC Server assisted mid-call feature;

after:

a) having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR and the SIP INVITE request due to STN-SR transaction is not yet completed; or

b) having initiated an access transfer that was triggered by a SIP INVITE request due to ATU-STI for PS to CS SRVCC and the SIP INVITE request due to ATU-STI for PS to CS SRVCC transaction is not yet completed;

then the SCC AS shall wait until this transaction has completed and then continue with the steps 1) and 2) described below.

When the SCC AS receives a SIP re-INVITE request(s) containing protocol "SIP" and reason parameter "cause" with value "487" after:

a) having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR; or

b) having performed an access transfer that was triggered by a SIP INVITE request due to ATU-STI for PS to CS SRVCC;

then the SCC AS shall:

1) not release the original source access leg once the expiration of the timer described in subclause 12.3.8; and

2) treat the SIP re-INVITE request(s) as per procedures for removing and adding media as described in subclause 13.3.1.

NOTE: The SCC AS assigns an operator specific timer to delay the release of the Source Access Leg for PS to CS SRVCC access transfer.

When the SCC AS receives a SIP response to the SIP re-INVITE request indicating success in removing all media components from a dialog that was created:

a) due to the SIP INVITE request due to STN-SR; or

b) due to the SIP INVITE request due to ATU-STI for PS to CS SRVCC;

then the SCC AS shall send a SIP BYE request on this dialog, by following the rules of 3GPP TS 24.229 [2] and start forwarding SIP message from the remote UE to the SC UE for this ongoing session as specified in 3GPP TS 24.229 [2] and the present specification.

12.3.3.1A PS to CS SRVCC cancelled by MME/SGSN or failure by UE to transition to CS domain for session in early dialog state

If the SCC AS applies the procedures for the PS to CS SRVCC for calls in alerting phase or the PS to CS SRVCC for originating calls in pre-alerting phase (as specified in subclause 12.3.4), then when the SCC AS receives a SIP UPDATE request containing Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" on:

– the original source access leg; or

– the original source access leg of the additional transferred session if the SCC AS applies the MSC Server assisted mid-call feature;

after having initiated an access transfer that was triggered by:

a) a SIP INVITE request due to STN-SR; or

b) a SIP INVITE request due to ATU-STI for PS to CS SRVCC;

for a session which is still in early dialog state the SCC AS shall:

1) not release the original access leg after the expiration of the timer described in subclause 12.3.8; and

2) treat the SIP UPDATE request(s) as per procedures for removing and adding media as described in subclause 13.3.1.

The SCC AS shall now start forwarding SIP messages from the remote UE to the SC UE for each dialog created by the SIP INVITE request due to STN-SR, the SIP INVITE request due to ATU-STI or the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2] and the present document.

When the SCC AS receives a SIP 200 (OK) response to the SIP UPDATE request, then the SCC AS shall:

1) if the SCC AS has already sent a SIP 200 (OK) response to a SIP INVITE request due to STN-SR or SIP INVITE request due to ATU-STI for PS to CS SRVCC then send a SIP BYE request on this dialog, and

a) if the SCC AS performs access transfer for an originating session which is in early dialog state , send a SIP 200 (OK) response to the SIP INVITE on the original source access leg; and

b) if the SCC AS performs access transfer for an additional transferred originating session which is still in early dialog state, send a SIP 200 (OK) response to the INVITE on the original source access leg of the additional transferred session; and

2) if the SCC AS has not sent a SIP 200 (OK) response to a SIP INVITE request due to STN-SR or SIP INVITE request due to ATU-STI for PS to CS SRVCC then send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR or the SIP INVITE request due to ATU-STI for PS to CS SRVCC.

If the SCC AS has received a SIP 200 (OK) response from the SC UE prior to receiving the SIP UPDATE request from the SC UE, then on receipt of the SIP 200 (OK) response to the SIP UPDATE request sent to the remote UE, the SCC AS shall send a SIP 200 (OK) response to the remote UE. Upon receiving the SIP ACK request from the remote UE, the SCC AS shall send a SIP ACK request to the SC UE.

12.3.3.2 P-CSCF releasing the source access leg during PS to CS SRVCC

When SCC AS receives a SIP BYE request on the Source Access Leg with the Reason header field containing a SIP 503 (Service Unavailable) response code then:

– if the SCC AS receives an initial SIP INVITE request on the Target Access Leg associated with the established dialog on the Source Access Leg, within a time defined by the operator policy after the SIP BYE request reception, then the SCC AS shall not initiate release of the Remote Leg; and

– if the SCC AS does not receive an initial SIP INVITE request on the Target Access Leg associated with the established dialog on the Source Access Leg, within a time defined by the operator policy after the SIP BYE request reception then the SCC AS shall initiate release of the Remote Leg.

NOTE: 8 seconds is an appropriate value for the operator policy.

12.3.3.3 P-CSCF releasing the source access leg when call is in alerting phase

The procedures specified in subclause 10.3.6 apply.

12.3.3.4 PS to CS SRVCC cancelled by MME/SGSN or release of the target access leg for an ongoing session

This subclause describes the procedures for cancelling calls after the SCC AS have initiated an PS to CS SRVCC access transfer that was triggered by a SIP INVITE request due to STN-SR, a SIP INVITE request due to ATU-STI or a SIP INVITE request transferring additional session for PS to CS SRVCC for a session where the dialog is in confirmed state with active or inactive speech media component.

If the SCC AS receives a SIP BYE request containing a Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value of "31" (normal unspecified) on:

– the target access leg where the dialog is in confirmed state with active speech media component;

– the target access leg where the dialog is in confirmed state with inactive speech media component, if the SCC AS applies the MSC server assisted mid-call feature;or

– the target access leg of an additional transferred session where the dialog is in confirmed state with an inactive speech media component, if the SCC AS applies the MSC server assisted mid-call feature,

after having initiated an access transfer and when the operator specific timer is still running, the SCC AS shall:

1) send the SIP 200 (OK) response to the SIP BYE request;

2) wait until the operator specific timer expires or until a SIP re-INVITE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received; and

3) if the operator specific timer expires and no SIP re-INVITE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received, release the call according to procedures in 3GPP TS 24.229 [2].

NOTE 1: All protocol values in the Reason header field other than "Q.850" and all values of the "cause" header field parameter other than "31" (normal unspecified) will result in an immediate release of the source access leg and the remote UE leg.

NOTE 2: The SCC AS assigns an operator specific timer to delay the release of the source access leg for PS to CS SRVCC access transfers.

When the SCC AS receives SIP re-INVITE request(s) from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" after having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR and after receiving a SIP BYE request containing the Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) on the target access leg, then the SCC AS shall:

1) not release the original source access leg on expiry of the timer described in subclause 12.3.8; and

2) treat the SIP re-INVITE request(s) as per procedures for removing and adding media as described in subclause 13.3.1.

NOTE 3: In procedures in subclause 13.3.1 the SCC AS starts forwarding SIP messages from the remote UE to the SC UE for the ongoing session as specified in 3GPP TS 24.229 [2] and the present specification.

12.3.3.5 PS to CS SRVCC cancelled by MME/SGSN or release of the target access leg for a session in an early dialog phase

12.3.3.5.1 SCC AS serving an originating user

This subclause describes the procedures for cancelling calls after the SCC AS have initiated an PS to CS SRVCC access transfer that was triggered by a SIP INVITE request due to STN-SR, a SIP INVITE request due to ATU-STI or a SIP INVITE request transferring additional session for PS to CS SRVCC for a session in an early dialog phase as specified in subclause 12.3.4.3 and subclause 12.3.4.4 where the SCC AS is serving a originating user.

If the SCC AS applies the procedures for PS to CS SRVCC access transfer for calls in alerting phase when serving a originating user or if the SCC AS applies the procedures for PS to CS SRVCC access transfer for calls in pre-alerting phase, then if the SCC AS receives a SIP BYE request or a SIP CANCEL request containing a Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) on:

– the target access leg of a session in the originating pre-alerting phase, if the SCC AS applies PS to CS SRVCC access transfer for calls in pre-alerting phase;

– the target access leg of a session in the alerting phase, if the SCC AS applies PS to CS SRVCC access transfer for calls in alerting phase; and

– the target access leg of an additional transferred session in the pre-alerting phase or in the alerting phase, if the SCC AS applies the MSC server assisted mid-call feature; or

– target of an additional transferred session if the SCC AS applies PS to CS SRVCC for calls in the pre-alerting phase or in alerting phase,

after having initiated an access transfer for a session which is still in early dialog state when the operator specific timer is still running, the SCC AS shall:

1) if a SIP BYE was received, send the SIP 200 (OK) response to the SIP BYE request;

1A) if a SIP CANCEL request was received, send the SIP 200 (OK) response to the SIP CANCEL request;

2) wait until the operator specific timer expires or until a SIP UPDATE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received; and

3) if the operator specific timer expires and no SIP UPDATE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received, cancel the call according to procedures in 3GPP TS 24.229 [2].

NOTE 1: All protocol values in the Reason header field other than "Q.850" and all other values of the "cause" header field parameter other than "31" (normal unspecified) will result in an immediate release of all dialogs associated with the source access leg and cancelling of all dialogs associated with the remote UE leg.

NOTE 2: The SCC AS assigns an operator specific timer to delay the release of the source access leg for PS to CS SRVCC access transfers.

When the SCC AS receives a SIP UPDATE request(s) containing the protocol value "SIP" and the "cause" header field parameter with the value "487" from the SC UE after having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR, a SIP INVITE request due to ATU-STI or a SIP INVITE request transferring additional session for PS to CS SRVCC and after receiving a SIP BYE request or a SIP CANCEL request containing the Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) on the target access leg, then the SCC AS shall:

1) not release the original source access leg once the expiration of the timer described in subclause 12.3.8; and

2) treat the SIP UPDATE request(s) as per procedures for removing and adding media as described in subclause 13.3.1.

NOTE 3: By removing and adding media in subclause 13.3.1 the SCC AS starts forwarding SIP messages from the remote UE to the SC UE for the ongoing dialogs as specified in 3GPP TS 24.229 [2] and the present specification.

If the SCC AS has received a SIP 200 (OK) response from the SC UE prior to receiving the SIP UPDATE request from the SC UE, then on receipt of the SIP 200 (OK) response to the SIP UPDATE request sent to the remote UE, the SCC AS shall send a SIP 200 (OK) response to the remote UE. Upon receiving the SIP ACK request from the remote UE, the SCC AS shall send a SIP ACK request to the SC UE.

12.3.3.5.2 SCC AS serving a terminating user

This subclause describes the procedures for cancelling calls after the SCC AS have initiated an PS to CS SRVCC access transfer that was triggered by a SIP INVITE request due to STN-SR, a SIP INVITE request due to ATU-STI or a SIP INVITE request transferring additional session for PS to CS SRVCC for a session in an alerting phase as specified in subclause 12.3.4.2 and subclause 12.3.4.4 where the SCC AS is serving a terminating user.

If the SCC AS applies the procedures for PS to CS SRVCC access transfer for calls in alerting phase and when serving a terminating user, then if the SCC AS receives a SIP BYE request or a SIP CANCEL request containing the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) cancelling SIP INVITE request due to STN-SR on:

– the target access leg of a session in the alerting phase, if the SCC AS applies PS to CS SRVCC for calls in alerting phase;

– the target access leg of an additional transferred session in the alerting phase, if the SCC AS applies the MSC server assisted mid-call feature; or

– target of an additional transferred session in the alerting phase, if the SCC AS applies PS to CS SRVCC for calls in alerting phase,

after having initiated an access transfer for a session which is still in the alerting phase when the operator specific timer is still running, then the SCC AS shall:

1) if a SIP BYE was received, send the SIP 200 (OK) response to the BYE request;

1A) if a SIP CANCEL request was received, send a SIP 200 (OK) response to the SIP CANCEL request;

2) wait until the operator specific timer expires or until a SIP UPDATE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received; and

3) if the operator specific timer expires and no SIP UPDATE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received then:

a) send a SIP 486 (Busy) response to the SIP INVITE request due to to terminating filter criteria from the SC UE towards the remote UE as specified in 3GPP TS 24.229 [2]; and

b) if a SIP CANCEL request was received, send a SIP 487 (Request Terminated) response to the SIP INVITE request due to STN-SR, the SIP INVITE request due to ATU-STI or the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2].

NOTE 1: All protocol values in the Reason header field other than "Q.850" and all other values of the "cause" header field parameter other than "31" (normal unspecified) will result in an immediate release of the source access leg associated with the SC UE and the associated leg towards remote UE. Any other dialogs associated with the same user will remain in the early dialog phase. The procedure for handling a SIP BYE request or SIP CANCEL request with other values of the "cause" header field parameter than "31" (normal unspecified) is described in subclause 12.3.11.

NOTE 2: The SCC AS assigns an operator specific timer to delay the release of the source access leg for PS to CS SRVCC access transfers.

When the SCC AS receives a SIP UPDATE request(s) containing the protocol value "SIP" and the "cause" header field parameter with the value "487" from the SC UE after having performed an access transfer and after receiving a SIP BYE request or a SIP CANCEL request containing the Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) on the target access leg, then the SCC AS shall:

1) not release the original source access leg once the expiration of the timer as described in subclause 12.3.8;

2) treat the SIP UPDATE request(s) as per procedures for removing and adding media as described in subclause 13.3.1; and

3) start forwarding SIP messages from the remote UE to the SC UE for this dialog triggered by a SIP INVITE request due to STN-SR, a SIP INVITE request due to ATU-STI or a SIP INVITE request transferring additional session for PS to CS SRVCC for a session in an alerting phase as specified in 3GPP TS 24.229 [2] and the present specification.

If the SCC AS has received a SIP 200 (OK) response to the SIP INVITE requests due to terminating filter criteria from the SC UE prior to receiving the SIP UPDATE request from the SC UE, then on receipt of the SIP 200 (OK) response to the SIP UPDATE request sent to the remote UE, the SCC AS shall send a SIP 200 (OK) response to the remote UE. Upon receiving the SIP ACK request from the remote UE, the SCC AS shall send a SIP ACK request to the SC UE.

12.3.4 SCC AS procedures for PS to CS access transfer when call is in alerting phase or pre-alerting phase

12.3.4.1 General

The SCC AS shall apply the procedures for the PS to CS SRVCC for calls in alerting phase as described in subclauses 12.3.4.2 or 12.3.4.3 if:

NOTE 1: The transferable session can contain early dialogs supporting active speech media and video media components if the transferable session set was created due to vSRVCC otherwise the transferable session set can only contain early dialogs supporting active speech media component.

1. the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the g.3gpp.srvcc-alerting media feature tag as specified in annex C; and

2. one of the following is true:

A. there are one or more dialogs supporting sessions with speech media component or speech media and video media components existing for the served user identified in the transferable set in the P-Asserted-Identity header field, such that:

a. all dialogs are early dialogs;

b. 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;

c. the Contact header field provided by the SC UE includes the g.3gpp.srvcc-alerting media feature tag as described in annex C; and

d. the Feature-Caps header field provided by the SCC AS towards the SC UE includes the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C; or

B. there are several dialogs supporting sessions with speech media component for the served user identified in the P-Asserted-Identity header field, such that:

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

b. 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;

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

d. SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2;

e. the Contact header field provided by the SC UE at the establishment of the early dialog(s) included the g.3gpp.srvcc-alerting media feature tag as described in annex C; and

f. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of the early dialog(s) includes the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C.

The SCC AS shall apply the procedures for the PS to CS SRVCC of originating call in pre-alerting phase as described in subclauses 12.3.4.3 if:

1) the Contact header field of the SIP INVITE request due to a STN-SR includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C; and

2) one of the following is true:

A) there are zero, one or more dialogs supporting a session with speech media component in the transferable set for the served user identified in the P-Asserted-Identity header field and a SIP INVITE request was received from SC UE of the served user identified in the P-Asserted-Identity header field 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 sent yet;

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

d) the SIP INVITE request included 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 sent 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 2: SCC AS can have zero dialogs if all the early dialogs were terminated by 199 (Early Dialog Terminated) as described in RFC 6228 [80].

B) there are one or more dialogs supporting sessions with speech media component in the transferable set for the served user identified in the P-Asserted-Identity header field 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) SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2; and

d) a SIP INVITE request was received from SC UE of the served user identified in the P-Asserted-Identity header field such that:

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

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

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

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

– a SIP 1xx response to the SIP INVITE request was sent 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 SCC AS shall apply the procedures for the PS to CS SRVCC of terminating call in pre-alerting phase as described in subclauses 12.3.4.2 if:

1) the Contact header field of the SIP INVITE request due to a STN-SR includes the g.3gpp.ps2cs-srvcc-term-pre-alerting media feature tag as described in annex C; and

2) one of the following is true:

A) there are zero, one or more dialogs supporting a session with speech media component in the transferable set for the served user identified in the P-Asserted-Identity header field and a SIP INVITE request was sent to the SC UE of the served user identified in the P-Asserted-Identity header field 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 sent yet;

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

d) the SIP INVITE request included a Contact header field containing the g.3gpp.ps2cs-srvcc-term-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-term-pre-alerting feature-capability indicator as described in annex C; or

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

B) there are one or more dialogs supporting sessions with speech media component in the transferable set for the served user identified in the P-Asserted-Identity header field 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) SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2; and

d) a SIP INVITE request was sent to the SC UE of the served user identified in the P-Asserted-Identity header field such that:

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

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

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

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

– 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-term-pre-alerting feature-capability indicator as described in annex C.

The SCC AS shall apply the procedures for the PS to CS SRVCC of call in alerting phase as described in subclauses 12.3.4.4 if:

1. the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the g.3gpp.srvcc-alerting media feature tag as described in annex C;

2. void;

3. void; and

4. one of the following is true:

A. two or more dialogs supporting sessions with speech media component exist for the served user in the transferable set, such that:

a. the Contact header fields provided by the SC UE at the establishment of sessions included the g.3gpp.srvcc-alerting media feature tag as described in annex C;

b. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of sessions included the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;

c. one dialog is a confirmed dialog with active speech media component and the remaining dialog(s) are early dialog(s); 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;

B. two or more dialogs supporting sessions with speech media component exist for the served user identified in the transferable session set, such that:

a. the Contact header fields provided by the SC UE at the establishment of sessions included the g.3gpp.srvcc-alerting media feature tag as described in annex C;

b. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of sessions included the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;

c. one or more dialogs are a confirmed dialog 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 SCC AS also applies the MSC server assisted mid-call feature as described in subclause 12.3.2; or

C. two or more dialogs supporting the sessions with speech media component exist for the served user identified in the transferable session set, such that:

a. the Contact header fields provided by the SC UE at the establishment of the sessions included the g.3gpp.srvcc-alerting media feature tag as described in annex C;

b. the Feature-Caps header field provided by the SCC AS towards the SC UE at the establishment of sessions included the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;

c. one or more dialogs are a confirmed dialogs with active speech media components, there are one or more dialogs that are confirmed dialogs 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 SCC AS does not apply the MSC server assisted mid-call feature as described in subclause 12.3.2.

The SCC AS shall apply the procedures for the PS to CS SRVCC of originating call in pre-alerting phase as described in subclause 12.3.4.4 if:

1. the Contact header field of the SIP INVITE request routed to the SCC AS due to a STN-SR includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C; and

2. there are one or more dialogs supporting sessions with speech media component exist for the served user identified in the transferable session set such that:

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 SCC AS also applies the MSC server assisted mid-call feature as described in subclause 12.3.2; and

D) a SIP INVITE request was received from the 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 SIP INVITE request received from the SC UE includes 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 sent towards the SC UE 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.3.4.2 SCC AS procedures for PS to CS access transfer for terminating call in alerting phase or pre-alerting phase using PS to CS SRVCC procedure

When the session in the transferable session set is a terminating call not accepted yet the SCC AS shall associate the SIP INVITE request with the early dialog related to the terminating session in the transferable session set.

If the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media component of the SDP received in the source access leg of the session being transferred, the SCC AS shall send a SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR containing:

a) the SDP sent by the SCC AS in the source access leg of the session being transferred; and

b) the signalling elements described in subclause 6A.4.3A.

If the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different to the speech media component of the SDP received in the source access leg of the session being transferred and the remote UE has provided an Allow header field listing the SIP UPDATE method or has not provided an Allow header field, the SCC AS shall update the remote leg by sending a SIP UPDATE request towards the remote UE using the existing established dialog according as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer received in the SIP INVITE request due to STN-SR.

Upon receiving the SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the SCC AS shall send a SIP 183 (Session Progress) response in response to the SIP INVITE request due to STN-SR towards the MSC server. The SCC AS shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request; and

b) the signalling elements described in subclause 6A.4.3A.

If:

– the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different to the speech media component of the SDP received in the source access leg of the session being transferred and the remote UE has provided an Allow header field not listing the SIP UPDATE method; or

– SIP 405 (Method Not Allowed) response was received to the SIP UPDATE sent towards the remote UE;

then the SCC AS shall create a new early dialog by sending a SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP 183 (Session Progress) response with:

1. an SDP answer:

A) with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [74]; and

B) including media of media types received in SDP offer of the SIP INVITE request due to STN-SR, which are also offered in the SIP INVITE request from the served user; and

2. the signalling elements described in subclause 6A.4.3A.

Upon receiving the SIP PRACK request from the target access leg, the SCC AS shall send a 200 (OK) response to the PRACK request and then send a SIP INFO request towards the MSC server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows:

1. include the Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

2. include an application/vnd. 3gpp.state-and-event-info +xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2:

A) if a SIP 180 (Ringing) response to the SIP INVITE request has already been sent in any of the existing early dialogs associated with the terminating call not accepted yet, with the state-info XML element containing "early" and the direction XML element containing "receiver"; or

B) if the SCC AS supports the PS to CS SRVCC for terminating calls in pre-alerting phase and if a SIP 180 (Ringing) response to the SIP INVITE request has not been sent yet in any of the existing early dialogs associated with the terminating call not accepted yet, with the state-info XML element containing "pre-alerting" and the direction XML element containing "receiver".

Upon receiving the 200 (OK) to the PRACK request from the MSC server the SCC AS shall start forwarding messages from the remote UE to the MSC server for this early dialog related to the terminating session as specified in 3GPP TS 24.229 [2] and the present specification.

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info package name and an application/vnd. 3gpp.state-and-event-info +xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 from the MSC Server with the event XML element containing "alerting-started", the SCC AS shall send a SIP 180 (Ringing) response to the SIP INVITE request received earlier from the remote UE as specified in 3GPP TS 24.229 [2].

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info package name and an application/vnd. 3gpp.state-and-event-info +xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 from the MSC Server with the event XML element containing "call-accepted", the SCC AS shall send as specified in 3GPP TS 24.229 [2]:

1) a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE indicating that the called party has answered the call;

2) if the SIP 2xx (OK) response was received to the SIP UPDATE sent towards the remote UE or the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media component of the SDP received in the source access leg of the session being transferred, a SIP 200 (OK) response to the SIP INVITE request due to STN-SR towards the MSC server to indicate the successful access transfer populated with the signalling elements described in subclause 6A.4.3A; and

3) if:

– the remote UE has provided an Allow header field not listing the SIP UPDATE method and the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different to the speech media component of the SDP received in the source access leg of the session being transferred; or

– a SIP 405 (Method Not Allowed) response was received to the SIP UPDATE sent towards the remote UE;

then when a SIP ACK request is received on the remote leg, send a SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the SDP offer received in the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, the SCC AS shall send SIP ACK request on the remote leg and shall send a SIP 200 (OK) response to the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2], using a dialog different to the dialog of SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP 200 (OK) response with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request as specified in 3GPP TS 24.229 [2]; and

b) the signalling elements described in subclause 6A.4.3A.

The SCC AS shall remove non-transferred audio and video media components and superfluous session as specified in subclause 12.3.8.

12.3.4.3 SCC AS procedures for PS to CS access transfer for originating call in alerting phase or pre-alerting phase using PS to CS SRVCC procedure

When the session in the transferable session set is an originating call not accepted yet the SCC AS shall associate the SIP INVITE request due to STN-SR with an early dialog or early dialogs related to the originating call.

If the SCC AS receives a SIP 18x response on the remote leg after receiving a SIP INVITE request due to STN-SR or a SIP INVITE request due to ATU-STI, and this SIP 18x response does not require use of reliable provisional responses, the SCC AS shall:

– store this SIP 18x response; and

– if a P-Early-Media header field is received in the SIP 18x response, store the P-Early-Media header field.

The SCC AS shall store the received SIP 18x responses separately for each early dialog. If the SCC AS has already stored a SIP 18x response for an early dialog and receives another SIP 18x response for the same early dialog, the SCC AS may remove the stored SIP 18x response for that early dialog and shall store the new SIP 18x response for that early dialog.

The SCC AS shall store the received P-Early-Media header field separately for each early dialog. If the SCC AS has already stored a P-Early-Media header field received in a SIP 18x response for an early dialog, and receives another SIP 18x response for the same early dialog containing a P-Early-Media header field, the SCC AS may remove the stored P-Early-Media header field for that early dialog and shall store the new P-Early-Media header field for that early dialog,

NOTE: The P-Early-Media header field is stored separately to prepare for the case that a subsequent SIP 18x response does not contain a P-Early-Media header field.

If there is only one early dialog related to the originating call not accepted yet available for the served user and if the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media component of the SDP received in the source access leg of the session being transferred, the SCC AS shall send a SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR containing:

– the SDP sent by the SCC AS in the source access leg of the session being transferred;

– if the SIP INVITE request due to STN-SR contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the original SIP INVITE request sent to the remote leg, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the original SIP INVITE request sent to the remote leg; and

– the signalling elements described in subclause 6A.4.3A.

If there is only one early dialog related to the originating call not accepted yet available for the served user, the remote UE has provided an Allow header field listing the SIP UPDATE method or has not provided Allow header field, the remote UE has provided the SDP answer, and the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different with the speech media component of the SDP received in the source access leg of the session being transferred, the SCC AS shall update the remote leg by sending a SIP UPDATE request towards the remote UE using the existing early dialog as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer received in the SIP INVITE request due to STN-SR.

Upon receiving the SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the SCC AS shall send a SIP 183 (Session Progress) response in response to the SIP INVITE request due to STN-SR towards the MSC server. The SCC AS shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR with:

– the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request;

– if the SIP INVITE request due to STN-SR contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE request; and

– the signalling elements described in subclause 6A.4.3A.

If there are more than one early dialogs related to the originating call not accepted yet available for the served user due to forking as described in 3GPP TS 24.229 [2], for each existing early dialog where the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media component of the SDP received in the source access leg of the session being transferred, the SCC AS shall create a new early dialog by sending a SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR containing:

– the SDP sent by the SCC AS in the source access leg of the session being transferred;

– if the SIP INVITE request due to STN-SR contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the original SIP INVITE request sent to the remote leg, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the original SIP INVITE request sent to the remote leg; and

– the signalling elements described in subclause 6A.4.3A.

If there are more than one early dialogs related to the originating call not accepted yet available for the served user due to forking as described in 3GPP TS 24.229 [2], for each existing early dialog where the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is not the same as the speech media component of the SDP received in the source access leg of the session being transferred, the remote UE has provided an Allow header field listing SIP UPDATE method or has not provided Allow header field, and the remote UE provided SDP answer, the SCC AS shall update the remote leg(s) by sending SIP UPDATE request(s) simultaneously towards remote UE using such early dialog(s) as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate each SIP UPDATE request with the SDP offer received in the SIP INVITE request due to STN-SR. Upon receiving each SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the SCC AS shall create a new early dialog by sending a SIP 183 (Session Progress) response in response to the SIP INVITE request due to STN-SR towards the MSC server. The SCC AS shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR with:

– the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request;

– If the SIP INVITE request due to STN-SR contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE request; and

– the signalling elements described in subclause 6A.4.3A.

If one or more early dialogs related to the originating call not accepted yet are available for the served user, and in each such early dialog:

– the remote UE of the early dialog has provided an Allow header field not listing the SIP UPDATE method, and the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is not the same as the speech media component of the SDP received in each such source access leg of the session being transferred; or

– SIP 405 (Method Not Allowed) response was received to the SIP UPDATE sent towards the remote UE in the early dialog;

the SCC AS shall create a new dialog by sending a SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP 183 (Session Progress) response with:

1. an SDP answer:

A) with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [74]; and

B) including media of media types received in SDP offer of the SIP INVITE request due to STN-SR, which are also offered in the SIP INVITE request from the served user; and

2. the signalling elements described in subclause 6A.4.3A.

If the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase and if there are no early dialogs related to the originating call not accepted yet available for the served user and there is a SIP INVITE request from the served user for which a final SIP response has not been received yet, the SCC AS shall send SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP 183 (Session Progress) response with:

1. an SDP answer:

A) with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [74]; and

B) including media of media types received in SDP offer of the SIP INVITE request due to STN-SR, which are also offered in the SIP INVITE request from the served user; and

2. the signalling elements described in subclause 6A.4.3A.

Upon receiving the first SIP PRACK request from the target access leg, the SCC AS shall send a 200 (OK) to the PRACK response and then send a SIP INFO request towards the MSC server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP INFO request as follows:

1. include the Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

2. include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and containing a XML body compliant to the XML schema specified in the annex D.2:

A) if a SIP 180 (Ringing) response to the SIP INVITE request has already been forwarded to the served SC UE before receiving the INVITE due to STN-SR or due to ATU-STI, with the state-info XML element containing "early" the direction XML element containing "initiator"; and

B) if the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase and if a SIP 180 (Ringing) response to the SIP INVITE request has not beenforwarded to the served SC UE before receiving the INVITE due to STN-SR or due to ATU-STI, with the state-info XML element containing "pre-alerting" and the direction XML element containing "initiator".

Upon receiving the 200 (OK) response to the SIP INFO request the SCC AS shall:

1. start forwarding SIP messages from the remote UE to the MSC server as specified in 3GPP TS 24.229 [2] and the present specification for dialogs where a PRACK request is received from the MSC server;

2. if SIP 18x responses were stored after receiving the SIP INVITE request due to STN-SR or SIP INVITE request due to ATU-STI, then for each early dialog where a PRACK request is received from the MSC server:

a) forward the that was stored most recently IP 18x responses to the MSC server; and

b) if a P-Early-Media header field is stored, include the P-Early-Media header field that was stored most recently in the SIP 18x response.

If a reliable SIP 1xx response or a SIP 2xx response is received on the remote leg, the SIP response is to the SIP INVITE request from the served user, the SIP response contains an SDP answer, and an SDP answer has not been received from the remote UE on the dialog of the SIP response yet, the SCC AS shall:

1) if the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media component of the SDP received in the source access leg of the session being transferred, forward the SIP response on the target access leg as a SIP response to the SIP INVITE request due to STN-SR; and

2) if the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is different to the speech media component of the SDP received in the source access leg of the session being transferred:

A) if the SIP 1xx response is received, send a SIP PRACK request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP PRACK request with the SDP offer received in the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP PRACK request, the SCC AS shall send a SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 183 (Session Progress) response with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP PRACK request as specified in 3GPP TS 24.229 [2];

b) if the SIP INVITE request due to STN-SR contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP PRACK request, a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP PRACK request; and

c) the signalling elements described in subclause 6A.4.3A.

B) if the SIP 2xx response is received, send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and send a SIP UPDATE request or SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request or SIP re-INVITE request with the SDP offer received in the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP UPDATE request or SIP re-INVITE request, the SCC AS shall send a SIP 200 (OK) response to the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request or SIP re-INVITE request as specified in 3GPP TS 24.229 [2]; and

b) the signalling elements described in subclause 6A.4.3A.

If a SIP 2xx response is received on the remote leg, the SIP response is to the SIP INVITE request from the served user, and an SDP answer has already been received from the remote UE on the dialog of the SIP response:

1) if the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is the same as the speech media component of the SDP received in the source access leg of the session being transferred, then forward the SIP response as specified in 3GPP TS 24.229 [2] on the target access leg as a SIP response to the SIP INVITE request due to STN-SR; and

2) if the speech media component of the SDP offer in the SIP INVITE request due to STN-SR is not the same as the speech media component of the SDP received in the source access leg of the session being transferred:

A) if the SDP offer received in the SIP INVITE request due to STN-SR has already been sent to the remote UE on the dialog of the SIP 2xx response, accepted with an subsequent SDP answer, the subsequent SDP answer was sent in a 183 (Session Progress) response on a target access leg, and SIP 2xx response does not contain an SDP answer, then forward the SIP 2xx response on the target access leg as a SIP response to the SIP INVITE request due to STN-SR;

B) if the SDP offer received in the SIP INVITE request due to STN-SR has already been sent to the remote UE on the dialog of the SIP 2xx response, accepted with an subsequent SDP answer, the subsequent SDP answer was sent in a 183 (Session Progress) response on a target access leg, and SIP 2xx response contains an SDP answer, then remove the SDP body from the SIP 2xx response or replace the SDP body in the SIP 2xx response with the subsequent SDP answer, and forward the SIP 2xx response as specified in 3GPP TS 24.229 [2] on the target access leg as a SIP response to the SIP INVITE request due to STN-SR; and

C) if:

– the SDP offer received in the SIP INVITE request due to STN-SR has not been sent to the remote UE on the dialog of the SIP response yet; or

– the SDP offer received in the SIP INVITE request due to STN-SR has already been sent to the remote UE in a SIP UPDATE request within the dialog of the SIP response and the SIP UPDATE request was rejected with SIP 405 (Method Not Allowed) response;

send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and send a SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the SDP offer received in the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, the SCC AS shall send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and shall send a SIP 200 (OK) response to the SIP INVITE request due to STN-SR as specified in 3GPP TS 24.229 [2] using a dialog different to the dialog of SIP 183 (Session Progress) response to the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP 200 (OK) response with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request as specified in 3GPP TS 24.229 [2]; and

b) the signalling elements described in subclause 6A.4.3A.

The SCC AS shall remove non-transferred audio and video media components and superfluous sessions as specified in subclause 12.3.8.

12.3.4.4 SCC AS procedures for PS to CS access transfer of additional call

This section contains procedures related to transfer of additional transferred session which is not accepted yet.

In order to transfer the additional transferred session, the SCC AS shall send a SIP REFER request according to 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to STN-SR; or the SCC AS shall send a SIP REFER request according to 3GPP TS 24.229 [2], IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to ATU-STI for PS to CS SRVCC. The SCC AS shall populate the SIP REFER request as follows:

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20];

NOTE 0: IETF RFC 3261 [19] recommends user agent client to include a Supported header field in any SIP request, listing option tags for extensions to SIP supported by the user agent client, that can be applied by the user agent server to the SIP response. In the step above, the SCC AS is mandated to include at least "norefersub" option tag in the Supported header field.

3. the Refer-To header field containing the additional transferred session SCC AS URI for PS to CS SRVCC, where the URI also includes the following header fields containing the information related to the additional transferred session:

A. if an early dialog supporting the additional transferred session exists, the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of an early dialog supporting session of the SC UE;

B. if the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase, if no early dialog supporting the additional transferred session exists, there is a SIP INVITE request from the served user for which a final SIP response has not been received yet and if an early dialog supporting the additional transferred session existed and was terminated, the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier on the source access leg of the early dialog supporting the additional transferred session which existed and was terminated;

NOTE 1: Early dialog can be terminated by SIP 199 (Early Dialog Terminated) response.

C. the Require header field populated with the option tag value "tdialog";

D. if an early dialog supporting the additional transferred session exists, the To header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the remote UE during the session establishment;

E. the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the SC UE during the session establishment;

F. the Content-Type header field with "application/sdp";

G. if an early dialog supporting the additional transferred session exists, the header field with hname "body" populated with an SDP body describing the media streams as negotiated in the session with the remote UE;

H. if the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase, no early dialog supporting the additional transferred session exists, there is a SIP INVITE request from the served user for which a final SIP response has not been received yet, the header field with hname "body" populated with the SDP offer received in the SIP INVITE request from the served user; and

I. optionally the P-Asserted-Identity URI header field containing value of the P-Asserted-Identity header field of the received SIP INVITE request;

4. if a SIP 180 (Ringing) response to the SIP INVITE request from the served user has already been received in any of the existing early dialogs associated with the additional transferred session, application/vnd.3gpp.state-and-event-info+xml MIME body with the state-info XML element containing "early" and the direction XML element containing:

A. if terminating call, the "receiver"; and

B. if originating call, the "initiator";

5. if the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase, the additional transferred session was originated by the SC UE and if a SIP 180 (Ringing) response to the SIP INVITE request from the served user has not been received yet in any of the existing early dialogs associated with the additional transferred session, application/vnd.3gpp.state-and-event-info+xml MIME body with the state-info XML element containing "pre-alerting" and the direction XML element containing the "initiator"; and

6. if:

A. SCC AS supports CS to PS SRVCC;

B. the SIP INVITE request due to STN-SR contains Accept header field with application/vnd.3gpp.srvcc-ext+xml MIME type;

C. a private user identity of a UE (i.e. other than those according to 3GPP TS 23.003 [12], subclause 20.3.3) is associated with the C-MSISDN in the P-Asserted-Identity header field of the SIP INVITE request due to STN-SR;

D. a binding of a contact address exists for the private user identity of the UE:

a) where the g.3gpp.cs2ps-srvcc media feature tag as described in annex C is associated with the contact address of the UE; and

b) such that SIP REGISTER request which registered the binding contained a Feature-Caps header field with the g.3gpp.atcf feature-capability indicator as described in annex C and with g.3gpp.cs2ps-srvcc feature-capability indicator as described in annex C;

E. the CS to PS SRVCC capability indication is indicated for the private user identity of the UE; and

F. the private user identity of the UE has the CS to PS SRVCC allowed indication in the subscription data;

then:

A. a MIME body of application/vnd.3gpp.srvcc-ext+xml MIME type:

a) containing ATU management URI of the ATCF serving the SC UE;

NOTE 2: The ATCF management URI of the ATCF is the URI contained in the g.3gpp.atcf-mgmt-uri feature-capability indicator included in a Feature-Caps header field of the SIP REGISTER request, which registered the binding for the private user identity of the UE.

b) containing C-MSISDN; and

c) not indicating that information relate to a registration of MSC server with IMS.

When the SCC AS receives the SIP INVITE request transferring additional session for PS to CS SRVCC, the SCC AS shall:

– if the Target-Dialog header field of the SIP INVITE request transferring additional session for PS to CS SRVCC identifies an existing early dialog, associate the SIP INVITE request transferring additional session for PS to CS SRVCC with the SIP early dialog i.e. identify the Source Access Leg;

NOTE 3: The SIP dialog on the Source Access Leg is identified by matching the dialog ID present in Target-Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE with a dialog in early state.

NOTE 4: By a SIP dialog in early state, it is meant an early SIP dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the SIP 2xx response has not yet been sent or received;

– if the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase, if the Target-Dialog header field of the SIP INVITE request transferring additional session for PS to CS SRVCC identifies an early dialog which has already been terminated, associate the SIP INVITE request transferring additional session for PS to CS SRVCC with the early dialog i.e. identify the Source Access Leg;

– if the SCC AS is unable to associate the SIP INVITE with a unique dialog in early state, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not processes the remaining steps;

– if the number of media lines in the Target Access Leg is less than the number of media lines in the Source Access Leg or the media type for the corresponding media lines is not the same as in the original session, send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining steps;

– if an early dialog exists on the remote leg of the additional transferred session, for each existing early dialog on the remote leg where the remote UE has provided an Allow header field listing the SIP UPDATE method or has not provided an Allow header field, SDP answer has already been sent or received in a reliable provisional response and the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is not the same as the speech media component of the SDP received in the source access leg of the early dialog, send a SIP UPDATE request(s) towards the remote UE(s) using such existing early dialog(s) which were created by the same SIP INVITE request as the Source Access Leg. The SCC AS shall populate the SIP UPDATE request(s) with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following media information:

a) the media characteristics as received in the SIP INVITE request transferring additional session for PS to CS SRVCC received on the Target Access Leg for media streams whose port is not set to zero; and

b) for the media streams in the SIP INVITE request transferring additional session for PS to CS SRVCC whose port is set to zero, include the corresponding media characteristics of those streams from the Source Access Leg;

– if one or more early dialogs exist on the remote leg of the additional transferred session, for each early dialog where the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is the same as the speech media component of the SDP received in the source access leg of the early dialog, create a new early dialog by sending a SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session for PS to CS SRVCC. In the SIP 183 (Session Progress) response, the SCC AS shall:

a) include the SDP sent by the SCC AS in the source access leg of the early dialog;

b) if the SIP INVITE request transferring additional session for PS to CS SRVCC contains a P-Early-Media header field with the "supported" parameter and the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the original SIP INVITE request sent to the remote leg, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the original SIP INVITE request sent to the remote leg; and

c) include the signalling elements described in subclause 6A.4.3A; and

– if one or more early dialogs exist on the remote leg of the additional transferred session and:

a) the remote UE has provided an Allow header field not listing the SIP UPDATE method; and the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is not the same as the speech media component of the SDP received in the source access leg of each such early dialog, or

b) SIP 405 (Method Not Allowed) response was received to the SIP UPDATE sent towards the remote UE;

create a new early dialog by sending a SIP 183 (Session Progress) response to SIP INVITE request transferring additional session for PS to CS SRVCC. The SCC AS shall populate the SIP 183 (Session Progress) response with:

a) an SDP answer with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [74]; and

b) the signalling elements described in subclause 6A.4.3A.

If an early dialog exists on the remote leg then when receiving SIP 2xx response to the SIP UPDATE request, the SCC AS shall create a new early dialog by sending SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session for PS to CS SRVCC. The SCC AS shall populate the SIP response as follows:

1. if the Remote Leg is an early dialog originated by the remote UE, include a Recv-Info header field containing the g.3gpp.state-and-event package name;

2. include the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request;

3. if the SIP INVITE request transferring additional session for PS to CS SRVCC contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE request; and

4. the signalling elements described in subclause 6A.4.3A.

For each received SIP PRACK request from the MSC server the SCC AS shall send the 200 (OK) response to the PRACK request according to 3GPP TS 24.229 [2] and start forwarding SIP messages from the remote UE for the associated early dialog as specified in 3GPP TS 24.229 [2] and the present specification.

If a reliable SIP 1xx response or a SIP 2xx response is received on the remote leg of the additional transferred session, the SIP response is to the SIP INVITE request from the served user, the SIP response contains an SDP answer and an SDP answer has not been received from the remote UE on the dialog of the SIP response yet, the SCC AS shall:

1. if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is the same as the speech media component of the SDP received in the source access leg of the additional transferred session, forward the SIP response on the target access leg as a SIP response to the SIP INVITE request transferring additional session for PS to CS SRVCC; and

2. if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is not the same as the speech media component of the SDP received in the source access leg of the additional transferred session:

a) if the SIP 1xx response is received, send a SIP PRACK request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP PRACK request with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP PRACK request, the SCC AS shall send a SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 183 (Session Progress) response as follows:

– include the SDP answer received in the SIP 200 (OK) response to the SIP PRACK request as specified in 3GPP TS 24.229 [2];

– if the SIP INVITE request transferring additional session for PS to CS SRVCC contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP PRACK request, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP PRACK request; and

– the signalling elements described in subclause 6A.4.3A; and

b) if the SIP 2xx response is received, send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and send a SIP UPDATE request or SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS populate the SIP UPDATE request or SIP re-INVITE request with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP UPDATE request or SIP re-INVITE request, the SCC AS shall send a SIP 200 (OK) response to the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with:

– the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request or SIP re-INVITE request as specified in 3GPP TS 24.229 [2]; and

– the signalling elements described in subclause 6A.4.3A.

If the Remote Leg is an early dialog originated by the remote UE then when receiving the SIP INFO request inside the Target Access Leg containing:

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

2. application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and with the event XML element containing "call-accepted" to indicate that the called party has answered the call;

then the SCC AS shall:

1. send SIP 200 (OK) response to the SIP INVITE request to the remote UE;

2. if the SIP 2xx (OK) response was received to the SIP UPDATE sent towards the remote UE or if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is the same as the speech media component of the SDP received in the source access leg of the additional transferred session, send SIP 200 (OK) response to the SIP INVITE request over the Target Access Leg;and

3. if:

– the remote UE has provided an Allow header field not listing the SIP UPDATE method and the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is different to the speech media component of the SDP received in the source access leg of the additional transferred session; or

– a SIP 405 (Method Not Allowed) response was received to the SIP UPDATE sent towards the remote UE;

and the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is not the same as the speech media component of the SDP received in the source access leg of the additional transferred session, then when a SIP ACK request is received on the remote leg, send a SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, the SCC AS send SIP ACK request on the remote leg and shall shall send a SIP 200 (OK) response to the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2], using a dialog different to the dialog of SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session for PS to CS SRVCC. The SCC AS shall populate the SIP 200 (OK) response with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request as specified in 3GPP TS 24.229 [2]; and

b) the signalling elements described in subclause 6A.4.3A.

If a SIP 2xx response is received on the remote leg, the SIP response is to the SIP INVITE request from the served user, and an SDP answer has already been received from the remote UE on the dialog of the SIP response:

1) if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is the same as the speech media component of the SDP received in the source access leg of the additional transferred session, then forward the SIP response as specified in 3GPP TS 24.229 [2] on the target access leg as a SIP response to the SIP INVITE request transferring additional session for PS to CS SRVCC; and

2) if the speech media component of the SDP offer in the SIP INVITE request transferring additional session for PS to CS SRVCC is not the same as the speech media component of the SDP received in the source access leg of the additional transferred session:

A) if:

– the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC has not been sent to the remote UE on the dialog of the SIP response yet; or

– the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC has already been sent to the remote UE in a SIP UPDATE request within the dialog of the SIP response and the SIP UPDATE request was rejected with SIP 405 (Method Not Allowed) response;

send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and send a SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, the SCC AS shall send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and shall send a SIP 200 (OK) response to the SIP INVITE request transferring additional session for PS to CS SRVCC as specified in 3GPP TS 24.229 [2] using a dialog different to the dialog of SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session for PS to CS SRVCC. The SCC AS shall populate the SIP 200 (OK) response with:

a) the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request as specified in 3GPP TS 24.229 [2]; and

b) the signalling elements described in subclause 6A.4.3A;

B) if the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC has already been sent to the remote UE on the dialog of the SIP 2xx response, accepted with an subsequent SDP answer, the subsequent SDP answer was sent in a 183 (Session Progress) response on a target access leg, and SIP 2xx response does not contain an SDP answer, then forward the SIP 2xx response on the target access leg as a SIP response to the SIP INVITE request transferring additional session for PS to CS SRVCC; and

C) if the SDP offer received in the SIP INVITE request transferring additional session for PS to CS SRVCC has already been sent to the remote UE on the dialog of the SIP 2xx response, accepted with an subsequent SDP answer, the subsequent SDP answer was sent in a 183 (Session Progress) response on a target access leg, and SIP 2xx response contains an SDP answer, then remove the SDP body from the SIP 2xx response or replace the SDP body in the SIP 2xx response with the subsequent SDP answer, and forward the SIP 2xx response as specified in 3GPP TS 24.229 [2] on the target access leg as a SIP response to the SIP INVITE request transferring additional session for PS to CS SRVCC.

12.3.5 SCC AS procedures for PS to CS access transfer: PS to CS SRVCC enhancement using ATCF

Upon receiving a SIP INVITE request due to ATU-STI for PS to CS SRVCC, the SCC AS shall:

1) if there is a Target-Dialog header field in the SIP INVITE request:

A) determine the transferable session set which are all the sessions of the SC UE whose private user identity is associated with Correlation MSISDN that is contained in the P-Asserted-Identity header field of the SIP INVITE request;

B) determine the session that is to be transferred which is a session:

a) in the transferable session set;

b) is in the confirmed dialog state; and

c) with active speech media component which has been made active most recently; and

C) if the session that is to be transferred is for the same dialog as the dialog identifier in the Target-Dialog header field in the SIP INVITE request, then perform the procedures described for SIP INVITE request due to STN-SR in subclause 12.3.0B with one of the following options dependent on operator policy:

a) if:

– the SDP offer in the SIP INVITE request contains speech media component only and the speech media component of the SDP offer in the SIP INVITE request is the same as the speech media component of the SDP negotiated by the ATCF in the session being transferred; or

– the SDP offer in the SIP INVITE request contains speech media component and video media component and the speech media component and the video media component of the SDP offer in the SIP INVITE request is the same as the speech media component and the video media component of the SDP negotiated by the ATCF in the session being transferred;

then the SCC AS shall:

i) not send a SIP re-INVITE request towards remote UE;

ii) send a SIP 200 (OK) response to the SIP INVITE request containing:

– the SDP negotiated by SCC AS towards ATCF in the session being transferred; and

– the signalling elements described in subclause 6A.4.3A; and

iii) upon receipt of the ACK request from the ATCF, start forwarding SIP messages from the remote UE to the MSC server for this session with active speech media component; or

b) if confirmed dialogs supporting a session with active speech media component exist in the transferable session set the SCC AS shall send a SIP re-INVITE request towards the remote UE and in a new SDP offer, include the media characteristics as received in the SIP INVITE request due to ATU-STI, by following the rules of 3GPP TS 24.229 [2];

NOTE: handling when it is determined that there is no session to be transferred or when the dialog identifier in the Target-Dialog header field in the SIP INVITE request identifies a dialog other than the session being transferred is out of scope of this release of this document.

D) if the session identified by the dialog identifier in the Target-Dialog header field is a session of the SC UE whose private user identity is associated with C-MSISDN that is contained in the P-Asserted-Identity header field of the SIP INVITE request and:

1) is in an early dialog state; or

2) is in a confirmed dialog state and contains inactive speech media component;

then

1) if the session is in an early dialog state, perform the procedures described for SIP INVITE requests due to STN-SR in subclause 12.3; and

2) if the session is in a confirmed dialog state and contains inactive speech media component, perform the procedures described for SIP INVITE requests due to STN-SR in subclause 12.3.2;

2) if there is no Target-Dialog header field in the SIP INVITE request:

a) perform the procedures described for SIP INVITE requests due to STN-SR in subclause 12.3.0B.

12.3.6 SCC AS procedures for PS to CS access transfer, vSRVCC

12.3.6.0 Determine the transferable session set

When the SCC AS receives a SIP INVITE request for audio and video due to STN-SR on the target access leg the SCC AS shall determine the transferable session set.

A session is in the transferable session set when the session:

1) is a session of the SC UE whose private user identity is associated with the C-MSISDN that is contained in the P-Asserted-Identity header field of the SIP INVITE request; and

2) is a session supporting active speech and video media components.

The SCC AS shall:

1) if the conditions in subclause 12.3.6.2 for applying the PS to CS transfer of a call in an alerting phase feature are fulfilled, follow the procedures in subclause 12.3.6.2; and

2) if the conditions in 1) are not satisfied follow the procedure in subclause 12.3.6.1.

12.3.6.1 General

When the SCC AS receives a SIP INVITE request for audio and video due to STN-SR on the target access leg the SCC AS shall associate the SIP INVITE request with a session:

– within the transferable session set;

– with active speech and video media components that was most recently made active; and

– the related dialog is in confirmed state.

If no confirmed dialogs supporting a session with active speech and video media component exists in the transferable session set the SCC AS shall:

1) send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STN-SR; and

2) if the transferable session set contains dialogs supporting sessions with speech media and/or video media components:

a) if the speech media and/or video media components are the only media component in the dialog then release the remote leg as specified in 3GPP TS 24.229 [2]; and

b) if the speech media and/or video media component are not the only media component in the dialog then modify the remote leg and remove the speech media component as specified in 3GPP TS 24.229 [2].

If confirmed dialogs supporting a session with active speech and video media components exist in the transferable session set the SCC AS shall:

1) send a SIP re-INVITE request towards the remote UE and in a new SDP offer, include the media characteristics as received in the SIP INVITE request due to STN-SR, by following the rules of 3GPP TS 24.229 [2]; or

2) send a SIP re-INVITE request towards the remote UE according to the conditions depicted in subclause 12.3.5 and in a new SDP offer, include the media characteristics as received in the SIP INVITE request due to ATU-STI for PS to CS SRVCC, by following the rules of 3GPP TS 24.229 [2].

Upon receiving the SIP 2xx response to the SIP re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP INVITE request due to STN-SR on the target access leg containing:

1) the relevant media parameter of the SDP answer in the received response, by following the rules of 3GPP TS 24.229 [2]; and

2) the signalling elements described in subclause 6A.4.3A.

The SCC AS shall remove non-transferred audio media and video media components and superfluous session as specified in subclause 12.3.8.

12.3.6.2 SCC AS procedures for PS to CS access transfer when call is in alerting phase, vSRVCC

The SCC AS shall apply the procedures for access transfer for calls in alerting phase in subclauses 12.3.4.2 and 12.3.4.3 according to the conditions specified in subclause 12.3.4.1 with the following differences:

– the SCC AS receives a SIP INVITE request for audio and video due to STN-SR instead of a SIP INVITE request due to STN-SR; and

– one or more early dialogs contain both speech and video media components.

12.3.6.3 SCC AS procedures for PS to CS access transfer: vSRVCC enhancement using ATCF

The SCC AS shall follow the procedures in subclause 12.3.5 with the following difference:

– instead of performing the procedures for SIP INVITE request due to STN-SR in subclause 12.3.1, the SCC AS performs the procedures for SIP INVITE request for audio and video due to STN-SR in subclause 12.3.6.

12.3.6.4 SCC AS procedures for vSR-VCC, abnormal case

The SCC AS shall follow the procedures in subclause 12.3.3 with the following difference:

– access transfer was triggered by the SCC AS receiving a SIP INVITE request for audio and video due to STN-SR instead of a SIP INVITE due to STN-SR.

12.3.7 SCC AS procedures for handling of SIP OPTIONS request

When the SCC AS receives a SIP OPTIONS request on the target access leg and determines for the C-MSISDN in the P-Asserted-Identity header field that the session that was most recently made active is a session with active speech and video media components, the SCC AS shall send a SIP 200 (OK) response to the SIP OPTIONS request with an SDP body containing "m=" lines for audio and video.

When the SCC AS receives a SIP OPTIONS request on the target access leg and determines for the C-MSISDN in the P-Asserted-Identity header field that the session that was most recently made active is a session with an active speech media component but not an active video media component, the SCC AS shall send a SIP 200 (OK) response to the SIP OPTIONS request with an SDP body containing an "m=" line for audio but not video.

If the SCC AS supports the MSC server assisted mid-call feature and:

– has received the g.3gpp.mid-call media feature tag as described in annex C is included in the Contact header field of the SIP INVITE request due to originating filter criteria (as described in subclause 7); or

– has received the g.3gpp.mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP INVITE request due to terminating filter criteria (as described in subclause 8)

then when the SCC AS receives a SIP OPTIONS request on the target access leg and determines for the C-MSISDN in the P-Asserted-Identity header field that there are no sessions with an active speech media component, but there are sessions that contain an inactive speech media component, the SCC AS shall send a SIP 200 (OK) response to the SIP OPTIONS request with an SDP body containing an "m=" line for audio.

NOTE: If the session that is most recently made inactive contains inactive speech and video media components, the SCC AS only returns the "m=" line for audio and not for video.

12.3.8 Removal of non-transferred audio media components and superfluous sessions

Upon receiving the SIP ACK request from target access leg, and after an operator specific timer has expired, the SCC AS shall:

1) for each session where no in-dialog request has been received in the source access leg of the session with transferred media component(s) within the operator defined time:

a) if the session is a session with an active or inactive media component, send a SIP BYE request on the source access leg;

b) if the session is an early dialog on originating side send a SIP 404 (Not Found) response on the source access leg; and

c) if the session is an early dialog on terminating side send a SIP CANCEL request on the source access leg; and

NOTE 1: The SC UE will receive the SIP request or response only if the SC UE is using Gm after the PS-CS access transfer is completed.

NOTE 2: Delaying the SIP request or response as described above allows an ICS UE to add Gm control if needed and an SC UE to reuse the PS dialog in case of SRVCC cancellation.

2) for each session in the transferable session set for which the speech media component, or the speech media and video media component in case of vSRVCC, was not transferred:

a) if the speech media component or the speech media and video media components is the only media component(s) of the session, release remote leg and source access leg; and

b) if the speech media component or the speech media and video media components are not the only media components of the session, modify the remote leg and source access leg and remove the media component(s).

NOTE 3: In case of a SIP INVITE request due to STN-SR, video media components are not removed or causing release of the remote leg.

12.3.9 Charging correlation

The SCC AS shall include in SIP 1xx and SIP 2xx responses to the SIP INVITE request due to STN-SR the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2], subclause 5.7.5.1 and include the "related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging-Vector header field. Additionally, if an "icid-generated-at" header field was generated for the source access leg, SCC AS shall include the "related‑icid-generated-at" header field parameter containing the host name or IP address included in the "icid-generated‑at" header field parameter of the source access leg.

12.3.10 SCC AS procedures for CS to PS SRVCC

12.3.10.1 Distinction of requests

The SCC AS needs to distinguish the following initial SIP requests:

1) SIP INVITE requests routed to the SCC AS due to ATU-STI for CS to PS SRVCC in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to ATU-STI for CS to PS SRVCC".

2) SIP CANCEL requests cancelling the SIP INVITE requests due to ATU-STI for CS to PS SRVCC. In the procedures below, such requests are known as "SIP CANCEL requests cancelling INVITE due to ATU-STI for CS to PS SRVCC".

3) SIP INVITE requests routed to the SCC AS due to additional transferred session SCC AS URI for CS to PS SRVCC in the Request-URI. In the procedures below, such requests are known as "SIP INVITE request transferring additional session".

12.3.10.2 First session transfer

12.3.10.2.1 General

If SCC AS supports CS to PS SRVCC, upon receiving a SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) determine the transferable dialog set which are all the dialogs (both early and confirmed):

A) where the g.3gpp.ics media feature tag with value "server" was indicated in Contact header field provided by the served user;

B) of the served user whose private user identity is associated with C-MSISDN that is contained in the P-Asserted-Identity header field of the SIP INVITE request due to ATU-STI for CS to PS SRVCC; and

C) supporting a session;

2) if there is a Target-Dialog header field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC:

A) determine the dialog being transferred as the dialog with the dialog identifier of the Target-Dialog header field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC; and

B) if the determined dialog being transferred identifies a dialog in the transferable dialog set, continue handling the procedures in the subclause 12.3.10.2.2; and

NOTE: Handling when the dialog identifier in the Target-Dialog header field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC identifies a non existing dialog is out of scope of this release of this document.

3) if there is no Target-Dialog header field in the SIP INVITE request due to ATU-STI for CS to PS SRVCC and if the transferable dialog set is not empty:

A) if SCC AS supports the CS to PS SRVCC with the assisted mid-call feature according to operator policy, the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the application/vnd.3gpp.mid-call+xml MIME type and if a dialog:

a) in the transferable dialog set;

b) which is a confirmed dialog; and

c) supporting a session with speech media component;

exists, then continue handling the procedures in the subclause 12.3.10.2.3 for the dialog and do not handle the remaining procedures of this subclause; and

B) if SCC AS supports the CS to PS SRVCC for calls in alerting phase according to operator policy, the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the application/vnd.3gpp.state-and-event-info+xml MIME type and if a dialog:

a) in the transferable dialog set;

b) which is an early dialog;

c) for which SIP 180 (Ringing) response has been sent or received; and

d) supporting a session with speech media component;

exists:

a) if the dialog was originated by the served user, then continue handling the procedures in the subclause 12.3.10.2.4 for the dialog and do not handle the remaining procedures of this subclause; and

b) if the dialog was originated by the remote UE, then continue handling the procedures in the subclause 12.3.10.2.5 for the dialog and do not handle the remaining procedures of this subclause.

12.3.10.2.2 Transfer of session with active speech media component

If SCC AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall:

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined dialog being transferred;

2) if the speech media component of the SDP offer in the SIP INVITE request due to ATU-STI for CS to PS SRVCC is the same as the speech media component of the SDP negotiated by the ATCF in session supported by the determined dialog being transferred:

A) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with:

a) signalling elements described in subclause 6A.4.3; and

b) the SDP negotiated by SCC AS towards ATCF in the determined dialog being transferred; and

3) if the speech media component of the SDP offer in the SIP INVITE request due to ATU-STI for CS to PS SRVCC differs from the speech media component of the SDP negotiated by the ATCF in the determined dialog being transferred:

A) send SIP re-INVITE request towards the remote UE inside the remote leg of the determined dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the SDP offer which includes the media characteristics as received in the SIP INVITE request due to ATU-STI for CS to PS SRVCC.

Upon receiving a SIP 2xx response to the SIP re-INVITE request sent towards the remote UE, the SCC AS shall:

1) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with:

A) signalling elements as described in subclause 6A.4.3; and

B) the SDP answer received in the SIP 2xx response to the SIP re-INVITE request.

Upon receiving SIP ACK request associated with the SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) release the source access leg of the determined dialog being transferred; and

2) continue handling the procedures in the subclause 12.3.10.3.

12.3.10.2.3 Transfer of session with inactive speech media component

If SCC AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall:

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined dialog being transferred; and

2) send SIP re-INVITE request towards the remote UE in the remote leg of the determined dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with:

A) the SDP offer which includes the media characteristics as received in the SIP INVITE request due to ATU-STI for CS to PS SRVCC; and

B) set the directionality of the speech media component in the SDP offer as used in the session with remote UE.

Upon receiving SIP 2xx response to the SIP re-INVITE request sent towards the remote UE, the SCC AS shall send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with:

1) signalling elements as described in subclause 6A.4.3;

2) the SDP answer received in the SIP 2xx response to the SIP re-INVITE request; and

3) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti media feature tag in the Contact header field received in the source access leg of the determined dialog being transferred.

Upon receiving SIP ACK request associated with the SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) release the source access leg of the determined dialog being transferred; and

2) continue handling the procedures in the subclause 12.3.10.3.

12.3.10.2.4 Transfer of originating session in alerting phase

If SCC AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall:

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined dialog being transferred; and

2) send SIP UPDATE request towards the remote UE in the remote leg of the determined dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer which includes the media characteristics as received in the SIP INVITE request due to ATU-STI for CS to PS SRVCC. If several early dialogs on the remote leg were established by the SIP INVITE request establishing the determined dialog being transferred, the SCC AS shall send SIP UPDATE request to each such early dialog.

Upon receiving a SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall establish a new early dialog by sending a SIP 180 (Ringing) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 180 (Ringing) response with:

1) signalling elements described in subclause 6A.4.3;

2) the SDP answer received in the SIP 2xx response to the SIP UPDATE request;

3) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti media feature tag in the Contact header field received in the source access leg of the determined dialog being transferred; and

4) if the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE request.

Upon receiving SIP PRACK request associated with the SIP 180 (Ringing) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) reject the source access leg of the determined dialog being transferred with SIP 404 (Not Found) response; and

2) continue handling the procedures in the subclause 12.3.10.3.

12.3.10.2.5 Transfer of terminating alerting session

If SCC AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall:

1) associate the SIP INVITE request due to ATU-STI for CS to PS SRVCC with the remote leg of the determined dialog being transferred; and

2) send SIP UPDATE request towards the remote UE in the remote leg of the determined dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer which includes the media characteristics as received in the SIP INVITE request due to ATU-STI for CS to PS SRVCC.

Upon receiving a SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall send a SIP 183 (Session Progress) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 183 (Session Progress) with:

1) signalling elements described in subclause 6A.4.3;

2) the SDP answer received in the SIP 2xx response to the SIP UPDATE request;

3) the Recv-Info header field with the 3gpp.state-and-event info package name; and

4) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti media feature tag in the Contact header field received in the source access leg of the determined dialog being transferred.

Upon receiving the SIP PRACK request from the SC UE associated with the SIP 183 (Session Progress) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) send a SIP INFO request towards the SC UE as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by SIP INVITE request due to ATU-STI for CS to PS SRVCC. The SCC AS shall populate the SIP INFO request as follows:

A) include the Info-Package header field with 3gpp.state-and-event info package name; and

B) include an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 with the state-info XML element containing "early" and the direction XML element containing "receiver"; and

2) cancel the source access leg of the determined dialog being transferred.

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info package name and an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 from the SC UE with the event XML element containing "call-accepted", the SCC AS shall:

1) send a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE as specified in 3GPP TS 24.229 [2]; and

2) send a SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC as specified in 3GPP TS 24.229 [2] populated as described in subclause 6A.4.3.

Upon receiving the SIP CANCEL request cancelling SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) send a SIP 200 (OK) response to the SIP CANCEL request;

2) send a SIP response to the SIP INVITE request received earlier from the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP response with:

A) if the SIP CANCEL request contains a Reason header field with protocol "SIP", then status code and reason text from the Reason header field of the SIP CANCEL request; and

B) if the SIP CANCEL request does not contain a Reason header field with protocol "SIP", then 486 (Busy) status code and reason text; and

3) send a SIP 487 (Request Terminated) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC as specified in 3GPP TS 24.229 [2].

Upon receiving the SIP ACK request on the target access leg of the determined dialog being transferred, the SCC AS shall cancel the source access leg of the determined dialog being transferred.

12.3.10.3 Additional session transfer

12.3.10.3.1 General

If SCC AS supports CS to PS SRVCC, if SCC AS supports the CS to PS SRVCC with the assisted mid-call feature according to operator policy and if the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the application/vnd.3gpp.mid-call+xml MIME type then for each dialog:

1) in the transferable dialog set;

2) which is a confirmed dialog;

3) supporting a session with speech media component; and

4) other than the dialog of the source access leg associated with the SIP INVITE request due to ATU-STI for CS to PS SRVCC;

the SCC AS shall perform the procedures in subclause 12.3.10.3.2.

If SCC AS supports the CS to PS SRVCC for calls in alerting phase according to operator policy and if the SIP INVITE request due to ATU-STI for CS to PS SRVCC contains an Accept header field containing the application/vnd.3gpp.state-and-event-info+xml MIME type then for each dialog:

i) in the transferable dialog set;

ii) which is an early dialog;

ii) for which SIP 180 (Ringing) response has been sent or received;

iv) supporting a session with speech media component; and

v) other than the dialog of the source access leg associated with the SIP INVITE request due to ATU-STI for CS to PS SRVCC;

the SCC AS shall perform the procedures in subclause 12.3.10.3.2.

If transfer of any dialog in the transferable dialog set has not been initiated, the SCC AS shall continue handling the procedures in the subclause 12.3.10.4.

12.3.10.3.2 Additional session transfer initiation

If SCC AS supports CS to PS SRVCC, in order to transfer the determined dialog being transferred, the SCC AS shall send a SIP REFER request according to 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to STN-SR. The SCC AS shall populate the SIP REFER request as follows:

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20];

NOTE: IETF RFC 3261 [19] recommends user agent client to include a Supported header field in any SIP request, listing option tags for extensions to SIP supported by the user agent client, that can be applied by the user agent server to the SIP response. In the step above, the SCC AS is mandated to include at least "norefersub" option tag in the Supported header field.

3. the Refer-To header field containing the additional transferred session SCC AS URI for CS to PS SRVCC, where the URI also includes the following header fields containing the information related to the determined dialog being transferred:

A. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the determined dialog being transferred;

B. the Require header field populated with the option tag value "tdialog";

C. if the remote UE of the remote leg of the determined dialog being transferred did not request privacy then the To URI header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the remote UE during the session establishment;

D. the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the SC UE during the session establishment;

E. the Content-Type header field with "application/sdp"; and

F. the header field with hname "body" populated with an SDP body describing the media streams as negotiated in the session with the remote UE; and

4. if the determined dialog being transferred is a confirmed dialog, an application/vnd.3gpp.mid-call+xml MIME body; and

5. if the determined dialog being transferred is an early dialog:

A. application/vnd.3gpp.state-and-event-info+xml MIME body with the state-info XML element containing "early" and the direction XML element containing:

a. if terminating call, the "receiver"; and

b. if originating call, the "initiator".

Upon receiving the SIP INVITE request transferring additional session, the SCC AS shall:

1) if the dialog identifier in the Target-Dialog header field of the SIP INVITE request identifies a dialog:

A) where the asserted identity of the participating served user belongs to the same subscription as the asserted identity of the sender of the SIP INVITE request: and

B) supporting a session with speech media component:

then:

A) determine the additional dialog being transferred as the dialog with the dialog identifier of the Target-Dialog header field in the SIP INVITE request transferring additional session;

B) associate the SIP INVITE request transferring additional session with the remote leg of the determined additional dialog being transferred;

C) if the dialog is a confirmed dialog, continue handling the procedures in the subclause 12.3.10.3.3;

D) if the dialog is an early dialog established by served user, continue handling the procedures in the subclause 12.3.10.3.4; and

E) if the dialog is an early dialog established by remote UE, continue handling the procedures in the subclause 12.3.10.3.5.

If receiving the SIP 3xx response, 4xx response or 6xx response to the SIP REFER request or if the SIP INVITE request transferring additional session is not received within operator defined time after the SIP REFER request sending, the SCC AS shall release, cancel or reject the remote leg, the source access leg and the target access leg of the determined dialog being transferred.

12.3.10.3.3 Transfer of session with inactive speech media component

If SCC AS supports CS to PS SRVCC, in order to transfer the determined additional dialog being transferred, the SCC AS shall:

1) send SIP re-INVITE request towards the remote UE in the remote leg of the determined additional dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP re-INVITE request with the SDP offer which includes the media characteristics as received in the SIP INVITE request transferring additional session.

Upon receiving a SIP 2xx response to the SIP re-INVITE request sent towards the remote UE, the SCC AS shall:

1) send a SIP 200 (OK) response to the SIP INVITE request transferring additional session according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 200 (OK) response with:

A) signalling elements described in subclause 6A.4.3;

B) the SDP answer received in the SIP 2xx response to the SIP re-INVITE request; and

C) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti media feature tag in the Contact header field received in the source access leg of the determined additional dialog being transferred.

Upon receiving SIP ACK request associated with the SIP 200 (OK) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) release the source access leg of the determined dialog being transferred; and

2) continue handling the procedures in the subclause 12.3.10.4.

12.3.10.3.4 Transfer of originating session in alerting phase

If SCC AS supports CS to PS SRVCC, in order to transfer the determined additional dialog being transferred, the SCC AS shall:

1) send SIP UPDATE request towards the remote UE in the remote leg of the determined additional dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer which includes the media characteristics as received in the SIP INVITE request transferring additional session. If several early dialogs on the remote leg were established by the SIP INVITE request establishing the determined additional dialog being transferred, the SCC AS shall send SIP UPDATE request to each such early dialog.

Upon receiving a SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall:

1) establish a new early dialog by sending a SIP 180 (Ringing) response to the SIP INVITE request transferring additional session according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 180 (Ringing) response with:

A) signalling elements described in subclause 6A.4.3;

B) the SDP answer received in the SIP 2xx response to the SIP UPDATE request;

C) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti media feature tag in the Contact header field received in the source access leg of the determined additional dialog being transferred; and

D) if the SIP INVITE request transferring additional session contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE request.

Upon receiving SIP PRACK request associated with the SIP 180 (Ringing) response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the SCC AS shall:

1) reject the source access leg of the determined dialog being transferred with SIP 404 (Not Found) response; and

2) continue handling the procedures in the subclause 12.3.10.4.

12.3.10.3.5 Transfer of terminating session in alerting phase

If SCC AS supports CS to PS SRVCC, in order to transfer the determined additional dialog being transferred, the SCC AS shall:

1) send SIP UPDATE request towards the remote UE in the remote leg of the determined additional dialog being transferred according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP UPDATE request with the SDP offer which includes the media characteristics as received in the SIP INVITE request transferring additional session.

Upon receiving a SIP 2xx response to the SIP UPDATE request sent towards the remote UE, the SCC AS shall:

1) send a SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session according to 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP 183 (Session Progress) with:

A) signalling elements described in subclause 6A.4.3;

B) the SDP answer received in the SIP 2xx response to the SIP UPDATE request;

C) the Recv-Info header field with the 3gpp.state-and-event info package name; and

D) the Feature-Caps header field containing the g.3gpp.ti feature-capability indicator with value of the g.3gpp.ti media feature tag in the Contact header field received in the source access leg of the determined additional dialog being transferred.

Upon receiving the SIP PRACK request from the SC UE associated with the SIP 183 (Session Progress) response to the SIP INVITE request transferring additional session, the SCC AS shall cancel the source access leg of the determined dialog being transferred.

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info package name and an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 from the MSC server with the event XML element containing "call-accepted", the SCC AS shall:

1) send a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE as specified in 3GPP TS 24.229 [2]; and

2) send a SIP 200 (OK) response to the SIP INVITE request transferring additional session as specified in 3GPP TS 24.229 [2] populated as described in subclause 6A.4.3.

Upon receiving the SIP CANCEL request cancelling SIP INVITE request transferring additional session, if the SIP CANCEL request is acceptable for the SCC AS, in addition to sending a SIP 2xx response to the SIP CANCEL request, the SCC AS shall:

1) send a SIP response to the SIP INVITE request received from the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall populate the SIP response with:

A) if the SIP CANCEL request contains a Reason header field with protocol "SIP", then status code and reason text from the Reason header field of the SIP CANCEL request; and

B) if the SIP CANCEL request does not contain a Reason header field with protocol "SIP", then 486 (Busy) status code and reason text; and

2) send a SIP 487 (Request Terminated) response to the SIP INVITE request transferring additional session as specified in 3GPP TS 24.229 [2].

12.3.10.4 Removal of non-transferred sessions

If SCC AS supports CS to PS SRVCC, in order to remove non-transferred sessions, the SCC AS shall:

1) for each session in the transferable session set for which the speech media component was not transferred:

a) release, reject or cancel the source access leg;

b) if the speech media component is the only media component(s) of the session, release, reject or cancel the remote leg; and

c) if the speech media component is not the only media components of the session, modify the session and remove the speech media component from the remote leg(s).

12.3.11 SCC AS procedures when the access transfer is completed

Once the SCC AS starts forwarding messages between the remote UE and the MSC server the SCC AS shall behave as an AS performing 3rd party call control acting as a routeing B2BUA as defined in 3GPP TS 24.229 [2] with the exceptions described in this subclause.

If SCC AS receives a SIP BYE request or SIP CANCEL request containing a Reason header field with the protocol value "Q.850" and the "cause" header field parameter with a value different than "31" (normal unspecified) on the target access and SCC AS is serving a terminating user in an early dialog phase, the SCC AS shall:

1) send a SIP 200 (OK) response to the SIP BYE request on the target access leg;

2) map the value of the "cause" header field parameter in the Reason header field to a SIP status code as specified in 3GPP TS 29.292 table 5.4.8.1.1 and table 5.4.8.1.2; and

3) send a 4xx, 5xx or 6xx response corresponding to the mapped SIP status code with the Reason header field received in the SIP BYE request included.

NOTE: The procedure when the SCC AS receives a SIP BYE request or CANCEL request containing a Reason header field with the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) is described in subclause 12.3.3.5.2.

When the access transfer is completed and if the received SIP INVITE request due to ATU-STI or due to STN-SR included a P-Access-Network-Info header field, the SCC AS may (according to operator policy):

– for active session transfer or held session transfer, send a SIP reINVITE request towards the remote UE which contains:

a) the SDP which has recently been negotiated towards the remote UE; and

b) a P-Access-Network-Info header field which is copied from the SIP INVITE request due to ATU-STI or due to STN-SR; and

– for PS to CS access transfer when call is in alerting phase or pre-alerting phase, send a SIP UPDATE request towards the remote UE which contains:

a) the SDP which has recently been negotiated towards the remote UE; and

b) a P-Access-Network-Info header field which is copied from the SIP INVITE request due to ATU-STI or due to STN-SR.