12.2B SC UE procedures for CS to PS SRVCC

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

12.2B.1 Distinction of requests

The SC UE needs to distinguish the following SIP requests:

1) SIP REFER request:

A) with the Refer-Sub header field containing "false" value; and

B) containing application/vnd.3gpp.mid-call+xml MIME body or the application/vnd.3gpp.state-and-event-info+xml MIME type.

In the procedures below, such requests are known as "SIP REFER requests for transfer of an additional session".

2) SIP INFO request:

A) with the Info-Package header field containing the g.3gpp.state-and-event; and

B) containing 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 direction XML element containing "receiver".

In the procedures below, such requests are known as "SIP INFO requests for transfer of incoming early session".

12.2B.2 First call transfer

12.2B.2.1 General

If SC UE supports the CS to PS SRVCC, upon receiving information from the lower layers that the CS to PS SRVCC access transfer is initiated, the SC UE shall:

1) if a CS call in Active (U10) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 3GPP TS 24.083 [43]) exists and if the ATGW transfer details were received from the lower layers:

A) determine the active call being transferred as a CS call in Active (U10) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 3GPP TS 24.083 [43]);

B) start rendering speech media of the determined active call being transferred received according to the UE information for CS to PS SRVCC sent to the network (see subclause 6.2.3); and

C) start sending speech media of the determined active call being transferred according to the ATGW information for CS to PS SRVCC received from the network (see subclause 6.2.3) where the address type, the connection address and the transport port to which the media stream is sent are replaced with the ATGW transfer details received from the lower layers; and

2) send a SIP INVITE request to STI-rSR according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request with:

A) Request-URI set to the STI-rSR received during registration (see subclause 6.2.1);

B) SDP offer set to the UE information for CS to PS SRVCC sent to the network (see subclause 6.2.3);

C) if a GRUU was received at registration, include the public GRUU or temporary GRUU in the Contact header field;

D) signalling elements described in subclause 6A.2.2.2;

E) void;

F) if the SC UE supports the CS to PS SRVCC with the assisted mid-call feature:

a) the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; and

b) the Accept header field containing the application/vnd.3gpp.mid-call+xml MIME type; and

G) if the SC UE supports CS to PS SRVCC for calls in alerting phase:

a) the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20], if not inserted already;

b) an Accept header field containing the application/vnd.3gpp.state-and-event-info+xml MIME type;

c) a Recv-Info header field containing the g.3gpp.state-and-event package name; and

d) a Supported header field with "100rel" option tag.

Upon receiving a SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR, the SC UE shall associate the dialog of the SIP 1xx response or SIP 2xx response with the CS call where the transaction identifier sent by MSC server equals to the value of the g.3gpp.ti feature-capability indicator as described in annex C of a Feature-Caps header field of the SIP response. If the value of the g.3gpp.ti feature-capability indicator as described in annex C of a Feature-Caps header field of the SIP response indicates a CS call of a conference participant of a conference, the SC UE shall associate the dialog of the SIP 1xx response or SIP 2xx response with the CS calls of all the conference participants of the conference.

If the SC UE is not aware of such CS call, or the CS call is the "disconnect request" (U11) call state, the "disconnect indication" (U12) call state, the "release request" (U19) call state or the "null" (U0) call state as described in 3GPP TS 24.008 [8], the SC UE shall release or cancel the dialog established by the SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR. If the CS call is the "disconnect request" (U11) call state as described in 3GPP TS 24.008 [8], the SC UE shall populate the SIP CANCEL request or the SIP BYE request with a Reason header field with the protocol field set to "SIP", the "cause" header field parameter indicating the selected status code and the "text" header field parameter indicating the selected reason phrase according to IETF RFC 3326 [57].

12.2B.2.2 Transfer of call with active speech media component

If SC UE supports the CS to PS SRVCC, in addition to the procedures in subclause 12.2B.2.1, if the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR in subclause 12.2B.2.1 is in the "hold request" auxiliary state (as defined in 3GPP TS 24.083 [43]), the speech media component of the session supported by the dialog is an active speech media component, and if the UE supports 3GPP TS 24.610 [28] , then UE shall invoke the hold service on a dialog according to 3GPP TS 24.610 [28] indicating that the speech media component is to be held.

12.2B.2.3 Transfer of call with inactive speech media component

If SC UE supports the CS to PS SRVCC and if the SC UE supports the CS to PS SRVCC with the assisted mid-call feature, in addition to the procedures in subclause 12.2B.2.1, if the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR in subclause 12.2B.2.1 is in the "retrieve request" auxiliary state (as defined in 3GPP TS 24.083 [43]), the speech media component of the session supported by the dialog is an inactive speech media component, and if the UE supports 3GPP TS 24.610 [28] , then UE shall invoke the hold service on a dialog according to 3GPP TS 24.610 [28] indicating that the speech media component is to be resumed.

NOTE: If the network associates the SIP INVITE request to STI-rSR with session with inactive speech media component, the SDP answer will contain a=recvonly or a=inactive.

12.2B.2.4 Transfer of originating call in alerting phase

No additional procedures in addition to the procedures in subclause 12.2B.2.1 apply.

12.2B.2.5 Transfer of terminating call in alerting phase

If SC UE supports the CS to PS SRVCC and if the SC UE supports the CS to PS SRVCC for calls in alerting phase, in addition to the procedures in subclause 12.2B.2.1, upon receiving the SIP INFO request for transfer of incoming early session inside an early dialog created with the SIP INVITE request due to STI-rSR, the SC UE shall:

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

2) consider the SIP dialog to be the transferred incoming early session.

When the served user accepts the transferred incoming early session or if the user has accepted it already (i.e. the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR in subclause 12.2B.2.1 is in the "connect request" (U8) call state or the "active" (U10) call state as described in 3GPP TS 24.008 [8]), the SC UE shall send a SIP INFO request accepting the session inside the early dialog created with the SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INFO request with:

1) an Info-Package header field 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 compliant to the XML schema specified in the clause D.2 with the event XML element containing "call-accepted".

When the served user rejects the transferred incoming early session, the SC UE shall send a SIP CANCEL request cancelling the SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP CANCEL request with a Reason header field containing protocol "SIP" and the "cause" parameter indicating the selected status code and the "text" parameter indicating the selected reason phrase.

12.2B.3 Additional call transfer

12.2B.3.1 General

If SC UE supports the CS to PS SRVCC, if the SC UE supports the CS to PS SRVCC with the assisted mid-call feature or the CS to PS SRVCC for calls in alerting phase then upon receiving a SIP REFER request for transfer of an additional session within dialog established by the SIP INVITE request to STI-rSR, the SC UE shall:

1) handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] as updated by IETF RFC 6665 [81], and IETF RFC 4488 [20] without establishing an implicit subscription;

NOTE 1: In accordance with IETF RFC 4488 [20], the SC UE inserts the Refer-Sub header field containing the value "false" in the SIP 2xx response to the SIP REFER request to indicate that it has not created an implicit subscription.

2) send a SIP INVITE request for transfer of an additional session according to 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows:

A) header fields which were included as URI header fields in the URI in the Refer-To header field of the received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field;

B) the SDP offer with:

a) the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request;

b) each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request;

c) port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has port with zero value;

d) media directionality as in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request; and

e) payload type numbers and their mapping to codecs and media parameters supported by SC UE, not conflicting with those in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request;

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has port with nonzero value.

C) if a GRUU was received at registration, include the public GRUU or temporary GRUU in the Contact header field;

D) signalling elements described in subclause 6A.2.2.2;

E) void; and

F) if the SC UE supports the CS to PS SRVCC for calls in alerting phase:

a) a Supported header field with "100rel" option tag; and

3) if the SC UE supports the CS to PS SRVCC for calls in alerting phase and if the SIP REFER request contains a XML body compliant to the XML schema specified in the clause D.2 with the state-info XML element containing "early" and direction set to "receiver" then consider the SIP dialog to be transferred incoming early session.

Upon receiving a SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session, the SC UE shall associate the dialog of the SIP 1xx response or SIP 2xx response with the CS call where the transaction identifier sent by MSC server equals to the value of the g.3gpp.ti feature-capability indicator as described in annex C of a Feature-Caps header field of the SIP response. If the value of the g.3gpp.ti feature-capability indicator as described in annex C of a Feature-Caps header field of the SIP response indicates a CS call of a conference participant of a conference, the SC UE shall associate the dialog of the SIP 1xx response or SIP 2xx response with the CS calls of all the conference participants of the conference.

If the SC UE is not aware of such CS call, or the CS call is the "disconnect request" (U11) call state, the "disconnect indication" (U12) call state, the "release request" (U19) call state or the "null" (U0) call state as described in 3GPP TS 24.008 [8], the SC UE shall release or cancel the dialog established by SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session. If the CS call is the "disconnect request" (U11) call state as described in 3GPP TS 24.008 [8], the SC UE shall populate the SIP CANCEL request or the SIP BYE request with a Reason header field with the protocol field set to "SIP", the "cause" header field parameter indicating the selected status code and the "text" header field parameter indicating the selected reason phrase according to IETF RFC 3326 [57].

12.2B.3.2 Transfer of call with active speech media component

No additional procedures in addition to the procedures in subclause 12.2B.3.1 apply.

12.2B.3.3 Transfer of call with inactive speech media component

If SC UE supports the CS to PS SRVCC and if the SC UE supports the CS to PS SRVCC with the assisted mid-call feature, in addition to the procedures in subclause 12.2B.3.1, if the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session in subclause 12.2B.3.1 is in the "retrieve request" auxiliary state (as defined in 3GPP TS 24.083 [43]), the speech media component of the session supported by the dialog is an inactive speech media component, and if the UE supports 3GPP TS 24.610 [28] , then UE shall invoke the hold service on a dialog according to 3GPP TS 24.610 [28] indicating that the speech media component is to be resumed.

NOTE: If the network associates the SIP INVITE request to STI-rSR with session with inactive speech media component, the SDP answer will contain a=recvonly or a=inactive.

12.2B.3.4 Transfer of originating call in alerting phase

No additional procedures in addition to the procedures in subclause 12.2B.3.1 apply.

12.2B.3.5 Transfer of terminating call in alerting phase

If SC UE supports the CS to PS SRVCC, if the SC UE supports the CS to PS SRVCC for calls in alerting phase, in addition to the procedures in subclause 12.2B.3.1, when the served user accepts the transferred incoming early session or if the user has accepted it already (i.e. the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session in subclause 12.2B.3.1 is in the "connect request" (U8) call state or the "active" (U10) call state as described in 3GPP TS 24.008 [8]), the SC UE shall send a SIP INFO request accepting the session inside the early dialog created with the SIP INVITE request for transfer of an additional session according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INFO request with:

1) an Info-Package header field with 3gpp.state-and-event info package name; and

If the SC UE supports the CS to PS SRVCC for calls in alerting phase then when the served user rejects the transferred incoming early session, the SC UE shall send a SIP CANCEL request cancelling the SIP INVITE request for transfer of an additional session according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP CANCEL request with:

1) a Reason header field containing protocol "SIP" and the "cause" parameter indicating the selected status code and the "text" parameter indicating the selected reason phrase.

12.2B.4 Procedures after calls are transferred

If:

1) the multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR in subclause 12.2B.2.1 is "MPTY request";

2) the multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call which was associated with the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session in subclause 12.2B.3.1 is "MPTY request";

3) SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR contains a Contact header field without the isfocus media feature tag specified in IETF RFC 3840 [53]; and

4) SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session contains a Contact header field without the isfocus media feature tag specified in IETF RFC 3840 [53];

and if the UE supports 3GPP TS 24.605 [31], then UE shall create a conference according to 3GPP TS 24.605 [31], subclause 4.5.2.1.4. If the conference creation was successful, the UE shall invite remote user of the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request to STI-rSR and remote user of the dialog of the SIP 1xx response or SIP 2xx response to the SIP INVITE request for transfer of an additional session to the conference according to 3GPP TS 24.605 [31], subclause 4.5.2.1.2.