12.7 Access Transfer Control Function (ATCF)

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.7.1 Distinction of requests

The ATCF needs to distinguish the following initial SIP requests:

1) SIP INVITE requests containing the STN-SR allocated to the ATCF in the Request-URI and:

A) not containing any Route header field; or

B) containing a URI in the topmost Route header field other than the ATCF URI for originating requests and other than the ATCF URI for terminating requests.

In the procedures below, such requests are known as "SIP INVITE requests due to STN-SR".

2) initial SIP INVITE requests containing the STI-rSR allocated to the ATCF in the Request-URI and with the ATCF URI for originating requests in the topmost Route header field. In the procedures below, such requests are known as "SIP INVITE requests due to STI-rSR".

3) SIP INVITE requests containing the ATCF management URI in the Request-URI and:

– not containing Route header field; or

– containing a URI in the topmost Route header field other than the ATCF URI for originating requests and other than the ATCF URI for terminating requests.

In the procedures below, such requests are known as "SIP INVITE requests due to media transfer from MSC Server to ATGW".

4) SIP INVITE requests containing the ATCF URI for anchoring additionally transferred call in ATCF allocated to the ATCF in the Request-URI.

In the procedures below, such requests are known as "SIP INVITE requests for anchoring call additionally transferred during PS to CS SRVCC in ATCF".

5) SIP OPTIONS requests:

– containing the STN-SR allocated to the ATCF in the Request-URI; and

– containing an application/vnd.3gpp.PS-to-CS-preparation+xml body specified in subclause D.6 carrying a PS-to-CS-preparation-request.

In the procedures below, such requests are known as "SIP OPTIONS requests carrying the PS-to-CS-preparation-request".

The ATCF needs to distinguish the following SIP in-dialog requests:

1) SIP INFO request:

A) with Info-Package header field with value g.3gpp.access-transfer-events; and

B) with application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer notification request.

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer notification request".

2) SIP INFO request:

A) with Info-Package header field with value g.3gpp.access-transfer-events; and

B) with application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer preparation.

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer preparation".

3) SIP INFO request:

A) with Info-Package header field with value g.3gpp.access-transfer-events; and

B) with application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer cancellation.

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer cancellation".

4) SIP INFO request:

A) with Info-Package header field with value 3gpp.state-and-event; and

B) with application/vnd.3gpp.state-and-event-info+xml MIME body associated with the info package according to IETF RFC 6086 [54] and with the event XML element containing "call-accepted" as specified in annex C.

In the procedures below, such requests are known as "SIP INFO requests carrying a "call-accepted" indication"

5) SIP REFER request:

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

B) with the Supported header field containing "norefersub" value;

C) with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field;

D) sent inside a SIP dialog:

a. created by the SIP INVITE request due to STN-SR;

b. where one of the following is true:

– the g.3gpp.mid-call feature-capability indicator as specified in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to STN-SR and the SIP REFER request contains a MIME body of MIME type specified in the subclause D.1.3; or

– the g.3gpp.srvcc-alerting feature-capability indicator as specified in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to STN-SR and the SIP REFER request contains application/vnd.3gpp.state-and-event-info+xml MIME body with the state-info XML element containing "early" or "pre-alerting"; and

E) not containing a MIME body of MIME type specified in the subclause D.4.4

In the procedures below, such requests are known as "SIP REFER requests for transferring additional call".

12.7.2 ATCF procedures for PS to CS access transfer, PS to CS SRVCC

12.7.2.1 General

Upon receiving the SIP INVITE request due to STN-SR or the SIP OPTIONS request carrying the PS-to-CS-preparation-request, the ATCF shall:

1) determine the transferable session set which are all the sessions with a speech media component:

a) associated with C-MSISDN equal:

i) to the URI in the P-Asserted-Identity header field of the SIP INVITE request due to STN-SR; or

ii) to the URI in the P-Asserted-Identity header field of the SIP OPTIONS request due to STN-SR; and

b) where during establishment of the session a Feature-Caps header field containing the g.3gpp.srvcc feature-capability indicator was received in the initial SIP request or SIP response; and

NOTE: These sessions potentially include recently released sessions for which the ATCF temporarily retains session state according to subclause 12.7.2.3.

2) determine the session being transferred which is a session:

a) in the transferable session set;

b) for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received; and

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

12.7.2.1A Determination of session being transferred when only a held session or only a session in originating pre-alerting phase or a session in alerting phase exist

If the transferable session set determined as specified in subclause 12.7.2.1 is not empty and each session in the transferable session set:

1) is in an early dialog state; or

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

the ATCF:

1) if:

a) one or more confirmed dialogs supporting a session with an inactive speech media component exists in the transferable session set;

b) the Feature-Caps header field provided by the SCC AS towards the SC UE includes the g.3gpp.mid-call feature-capability indicator as described in annex C; and

c) the Contact header field provided by the SC UE to the SCC AS includes the g.3gpp.mid-call media feature tag (as described in annex C);

shall select the confirmed dialog supporting a session with an inactive speech media component that became inactive most recently as the session being transferred; and

2) if no confirmed dialog supporting a session with an inactive speech media component exists in the transferable session set but there are one or more dialogs in the transferable session set supporting sessions where the SC UE has completed a reliable offer / answer procedure and with an active speech media component such that:

a) a SIP 180 (Ringing) response to a 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 an active speech media component;

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

c) 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;

shall select any of the early dialogs where a SIP 180 (Ringing) responses was received as the session being transferred; and

3) if no confirmed dialog supporting a session with an inactive speech media component exists in the transferable session set but there are one or more dialogs in the transferable session set supporting one session where the SC UE has completed a reliable offer / answer procedure and with an active speech media component such that:

a) a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any of the existing dialogs;

b) all dialogs are early dialogs created by the same SIP INVITE request;

c) the Contact header field provided by the SC UE includes the g.3gpp.ps2cs-srvcc-orig-pre-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.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C;

shall select any of the early dialogs as the session being transferred.

12.7.2.2 Active session transfer

Upon receiving a SIP INVITE request due to STN-SR, if a session is in the transferable session set as determined in subclause 12.7.2.1 and the following conditions are true:

– the session is a confirmed dialog with an active speech media component which has been made active most recently;

– the ATGW anchors the media of the session being transferred; and

– if 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 if the ATGW can provide media transcoding between the speech media component in the received SDP offer and the speech media component in the session being transferred;

the ATCF shall act as B2BUA as described in subclause 5.6 and shall:

NOTE 1: At this point, ATCF interacts with ATGW to provide information needed in the procedures below and to request ATGW to start forwarding the audio media from the remote UE to the MSC server. The details of interaction between ATCF and ATGW are out of scope of this document.

0) if ATCF supports CS to PS SRVCC:

a) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests due to STN-SR; and

b) store the value of the g.3gpp.ti media feature tag as described in annex C of the Contact header field of the SIP INVITE request due to STN-SR;

1) send a SIP 200 (OK) response to the received SIP INVITE request due to STN-SR that contains:

a) the Contact header field of the remote UE saved in subclause 7.5.2.2 or subclause 8.4.2.2;

b) the Record-Route header field that contains only the SIP URI pointing to the ATCF;

c) the SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW, and the directionality attribute shall be the same as the SDP negotiated by ATCF towards the UE in the session being transferred;

d) include the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2] populated as follows:

i) the "icid-value" header field parameter containing the same value as received in the SIP INVITE request due to STN-SR;

ii) the "related-icid" header field parameter containing the ICID value of the source access leg in the P-Charging-Vector header field and saved in subclause 7.5.2.2 or subclause 8.4.2.2;

iii) if an "icid-generated-at" header field was generated for the source access leg, 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 and saved in subclause 7.5.2.2 or subclause 8.4.2.2;

iv) the "orig-ioi" header field parameter with the value received in the SIP INVITE request due to STN-SR; and

v) a "term-ioi" header field parameter with the value received:

– if the source access leg is terminated by the SC UE, in the "orig-ioi" header field parameter in the P-Charging-Vector header field received in the initial SIP INVITE request from the remote UE and saved in subclause 8.4.2.2; and

– if the source access leg is an originating call initiated by the SC UE, in the "term-ioi" received in the P-Charging-Vector header field in responses from the remote UE to the initial SIP INVITE request and saved in subclause 7.5.2.2;

NOTE 2: The "transit-ioi" header field parameter can not be copied from the source access leg since the SIP INVITE due to ATU-STI can traverse different transit networks compared to the transit networks traversed when the call was initiated.

e) if ATCF supports CS to PS SRVCC:

A) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

B) the Accept header fields received in the home leg of the session being transferred by PS to CS SRVCC except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type; and

C) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-events+xml MIME type of the Accept header field received in the home leg of the session being transferred by PS to CS SRVCC; and

f) the Feature-Caps header field(s) according to IETF RFC 6809 [60] received in the home leg of the session being transferred and saved in subclause 7.5.2.2 or subclause 8.4.2.2;

g) the P-Asserted-Identity header field with the identity of the remote user saved in subclause 7.5.2.2 or subclause 8.4.2.2; and

h) if available, the Privacy header field saved in subclause 7.5.2.2 or subclause 8.4.2.2; and

NOTE 3: At this point the ATCF requests the ATGW to start forwarding the audio media from the MSC server to the remote UE. The details of interaction between ATCF and ATGW are out of scope of this document.

2) initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due to ATU-STI for PS to CS SRVCC toward the SCC AS populated with:

a) the SDP offer containing the currently used media with ATGW ports and IP addresses towards the remote UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types offered in the received SIP INVITE request due to STN-SR;

b) the Request-URI containing the ATU-STI for PS to CS SRVCC previously received from the SCC AS and associated with the session being transferred; and

c) the Target-Dialog header field with the dialog identifier of the session being transferred;

d) the Require header field containing the option tag "tdialog";

e) the Contact header field that contains the contact information received in the SIP INVITE request due to STN-SR;

f) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive subsequent the in-dialog requests from the SCC AS;

NOTE 4: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route header field that the SCC AS will use when sending the in-dialog request toward the ATCF.

g) the P-Asserted-Identity header field that is the same as the P-Asserted-Identity header field received in the SIP INVITE request due to STN-SR;

h) all header fields which are included in the SIP INVITE request due to STN-SR and which contain option tag(s);

i) if the Recv-Info header field is included in the SIP INVITE request due to STN-SR, the Recv-Info header field that is the same as the Recv-Info header field received in the SIP INVITE request due to STN-SR except, if the ATCF supports the CS to PS SRVCC, the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

j) if the Accept header field is included in the SIP INVITE request due to STN-SR, the Accept header field that is the same as the Accept header field received in the SIP INVITE request due to STN-SR except, if the ATCF supports the CS to PS SRVCC, the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type;

k) if the ATCF supports the CS to PS SRVCC, if an Accept header field of the SIP INVITE request due to STN-SR contains the application/vnd.3gpp.access-transfer-events+xml with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":

a) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and

b) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name.

l) if the SIP INVITE request due to STN-SR contains a P-Access-Network-Info header field, a P-Access-Network-Info header field copied from the SIP INVITE request due to STN-SR.

If a session is in the transferable session set as determined in subclause 12.7.2.1, ATCF does not support CS to PS SRVCC and one of the following conditions are true:

– the ATGW does not anchor the media of the session being transferred; or

– if the speech media component of the SDP offer in the SIP INVITE request is not the same as the speech media component of the SDP negotiated by the ATCF in the session being transferred and the ATGW cannot provide media transcoding between the speech media component in the received SDP offer and the speech media component in the session being transferred;

the ATCF shall act as proxy and shall:

1) replace the Request-URI in the received SIP INVITE request due to STN-SR with the ATU-STI for PS to CS SRVCC associated with the session being transferred;

before forwarding the request.

If a session being transferred was determined in subclause 12.7.2.1, ATCF supports CS to PS SRVCC and one of the following conditions are true:

– the ATGW does not anchor the media of the session being transferred; or

the ATCF shall act as B2BUA and shall:

1) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests due to STN-SR;

2) store the value of the g.3gpp.ti media feature tag as described in annex C of the Contact header field of the SIP INVITE request due to STN-SR; and

3) send a SIP INVITE request due to ATU-STI for PS to CS SRVCC according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INVITE request due to ATU-STI for PS to CS SRVCC with:

A) the Request-URI set to the ATU-STI for PS to CS SRVCC associated with the session being transferred;

B) all Route header fields of the SIP INVITE request due to STN-SR except the topmost Route header field;

C) the Record-Route header field containing the SIP URI of the ATCF;

D) the Recv-Info header fields of the SIP INVITE request due to STN-SR except the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

E) the Accept header fields of the SIP INVITE request due to STN-SR except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type;

F) if an Accept header field of the SIP INVITE request due to STN-SR contains the application/vnd.3gpp.access-transfer-events+xml with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":

b) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

G) if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]:

a) all MIME bodies of the SIP INVITE request due to STN-SR apart from application/sdp MIME body; and

b) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW;

NOTE 5: ATCF interacts with ATGW to provide the needed media related information. The details of interaction between ATCF and ATGW are out of scope of this document.

H) if the ATCF decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]:

a) all MIME bodies of the SIP INVITE request due to STN-SR;

I) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field.

J) if the SIP INVITE request due to STN-SR contains a P-Access-Network-Info header field, a P-Access-Network-Info header field copied from the SIP INVITE request due to STN-SR.

If the ATCF supports CS to PS SRVCC, when the ATCF receives any SIP 1xx response or SIP 2xx response to the SIP INVITE request due to ATU-STI for PS to CS SRVCC, the ATCF shall:

1) save the Contact header field included in the SIP response; and

NOTE 6: If the ATCF subsequently receives an initial SIP INVITE request due to STI-rSR, the ATCF will include the saved the Contact header field of the remote UE in its SIP 200 (OK) response to the initial SIP INVITE request due to STI-rSR.

2) generate and send a SIP response to the SIP INVITE request due to STN-SR populated with:

A) the same status code as the received SIP response to the SIP INVITE request due to ATU-STI for PS to CS SRVCC; and

B) the Record-Route header field containing the SIP URI of the ATCF;

C) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

D) if the SIP response is SIP 1xx response:

a) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the g.3gpp.access-transfer-events info package name of the Recv-Info header field of the received SIP response; and

E) if the SIP response is SIP 2xx response:

a) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

b) the Accept header fields of the received SIP response except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type; and

c) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-events+xml MIME type of the Accept header field of the received SIP response.

12.7.2.3 Abnormal procedures

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

When the ATCF receives either:

1) a SIP BYE request on the Source Access Leg containing a Reason header field containing a SIP 503 (Service Unavailable) response code, that is terminating an established dialog or an early dialog on the Source Access Leg;

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

3) a SIP 503 (Service Unavailable) response on the Source Access Leg, that is terminating an early dialog on the Source Access Leg terminating at the SC UE; or

4) a SIP 500 (Server Internal Error) response on the Source Access Leg, that is terminating an early dialog on the Source Access Leg terminating at the SC UE;

then:

– the ATCF shall retain session state information and ATGW resources associated with the session until either it receives a SIP INVITE request due to STN-SR or an operator determined period elapses.

NOTE 1: The default value of the operator determined period is 8 seconds.

NOTE 2: The session remains recognizable for PS to CS SRVCC access transfer as shown in subclause 12.7.2.1.

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

12.7.2.3.2 No transferable session exists

Upon receiving a SIP INVITE request due to STN-SR, if the transferable session set determined in subclause 12.7.2.1 does not contain any sessions and the identity in the P-Asserted-Identity header field is a C-MSISDN that is not bound to a registration path in the ATCF, the ATCF shall respond with a SIP 404 (Not Found) response.

If the transferable session set determined in subclause 12.7.2.1 does not contain any sessions and if the identity in the P-Asserted-Identity header field is a C-MSISDN that is bound to a registration path in the ATCF, the ATCF shall:

1) determine whether a transferable SIP INVITE request exists. The transferable SIP INVITE request is a SIP INVITE request sent by SC UE such that:

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

B) the session being established by the SIP INVITE request is associated with C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests due to STN-SR;

C) 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.srvcc feature-capability indicator as described in annex C;

NOTE 0: ATCF can have no dialogs if all the early dialogs were terminated by 199 (Early Dialog Terminated) as described in IETF RFC 6228 [80].

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

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

2) if a transferable SIP INVITE request exists:

A) if ATCF decides to not anchor media according to local policy and if ATCF does not support CS to PS SRVCC, provide the proxy role as specified in 3GPP TS 24.229 [2] and replace the Request-URI in the received SIP INVITE request due to STN-SR with ATU-STI for PS to CS SRVCC associated with SIP INVITE request before forwarding the request and do not process the remaining steps; and

B) if ATCF decides to anchor media according to local policy:

a) if ATCF supports the CS to PS SRVCC:

– associate the SIP INVITE request with the latest SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE requests due to STN-SR; and

– store the value of the g.3gpp.ti media feature tag as described in annex C of the Contact header field of the SIP INVITE request due to STN-SR; and

b) provide the role of a B2BUA in accordance with 3GPP TS 24.229 [2] and initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due to ATU-STI for PS to CS SRVCC toward the SCC AS populated with:

– if ATCF decides to anchor media according to local policy:

i) the SDP offer containing the media offered in source access leg towards the remote UE, with the currently offered ATGW ports and IP addresses towards the remote UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types offered in the received SIP INVITE request due to STN-SR; and

ii) all MIME bodies of the SIP INVITE request due to STN-SR apart from application/sdp MIME body;

– if the ATCF decides not to anchor media according to local policy, all MIME bodies of the SIP INVITE request due to STN-SR;

– the Request-URI containing the ATU-STI for PS to CS SRVCC previously received from the SCC AS and associated with the SIP INVITE request;

– the Contact header field that contains the contact information received in the SIP INVITE request due to STN-SR;

– the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive subsequent in-dialog requests from the SCC AS;

NOTE 1: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route header field that the SCC AS will use when sending the in-dialog request toward the ATCF.

– the P-Asserted-Identity header field that is the same as the P-Asserted-Identity header field received in the SIP INVITE request due to STN-SR;

– all header fields which are included in the SIP INVITE request due to STN-SR and which contain option tag(s);

– if the Recv-Info header field is included in the SIP INVITE request due to STN-SR, the Recv-Info header field that is the same as the Recv-Info header field received in the SIP INVITE request due to STN-SR except, if the ATCF supports the CS to PS SRVCC, the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

– if the Accept header field is included in the SIP INVITE request due to STN-SR, the Accept header field that is the same as the Accept header field received in the SIP INVITE request due to STN-SR. except, if the ATCF supports the CS to PS SRVCC, the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type; and

– if the ATCF supports the CS to PS SRVCC and an Accept header field of the SIP INVITE request due to STN-SR contains the application/vnd.3gpp.access-transfer-events+xml with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":

i) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and

ii) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name; and

3) if a transferable SIP INVITE request does not exist, respond with a SIP 480 (Temporarily Unavailable) response.

12.7.2.4 Transfer when only a held session or a session in originating pre-alerting phase or a session in alerting phase exist

Upon receiving a SIP INVITE request due to STN-SR, if the transferable session set determined in subclause 12.7.2.1 is not empty and each session in the transferable session set:

1) is in an early dialog state; or

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

then the ATCF shall:

1) if ATCF decides to not anchor media according to local policy and if ATCF does not support CS to PS SRVCC, provide the proxy role as specified in 3GPP TS 24.229 [2] and replace the Request-URI in the received SIP INVITE request due to STN-SR with ATU-STI for PS to CS SRVCC associated with a session in the transferable session set before forwarding the request and do not process the remaining steps;

2) if ATCF decides to anchor media according to local policy, determine the session being transferred as described in subclause 12.7.2.1A;

3) if ATCF supports the CS to PS SRVCC:

b) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request due to STN-SR; and

4) provide the role of a B2BUA in accordance with 3GPP TS 24.229 [2] and initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due to ATU-STI for PS to CS SRVCC toward the SCC AS populated with:

a) if ATCF decides to anchor media according to local policy:

A) if

– only one dialog exists in the session being transferred, the SDP offer containing the currently used media with ATGW ports and IP addresses towards the remote UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types offered in the received SIP INVITE request due to STN-SR; and

– more than one early dialog exists in a session being transferred, the SDP offer containing the ATGW ports and IP addresses of the selected dialog towards the remote UE as provided by the ATGW and the media types offered in the received SIP INVITE request due to STN-SR;

B) all MIME bodies of the SIP INVITE request due to STN-SR apart from application/sdp MIME body;

C) the Request-URI containing the ATU-STI for PS to CS SRVCC previously received from the SCC AS and associated with the session being transferred;

D) the Target-Dialog header field with the dialog identifier of the session being transferred; and

E) the Require header field containing the option tag "tdialog";

b) if the ATCF supports the CS to PS SRVCC and the ATCF decides not to anchor media according to local policy:

i) all MIME bodies of the SIP INVITE request due to STN-SR; and

ii) the Request-URI containing the ATU-STI for PS to CS SRVCC associated with a session in the transferable session set;

c) the Contact header field that contains the contact information received in the SIP INVITE request due to STN-SR;

d) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive subsequent in-dialog requests from the SCC AS;

NOTE 1: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route header field that the SCC AS will use when sending the in-dialog request toward the ATCF.

e) the P-Asserted-Identity header field that is the same as the P-Asserted-Identity header field received in the SIP INVITE request due to STN-SR;

f) all header fields which are included in the SIP INVITE request due to STN-SR and which contain option tag(s);

g) if the Recv-Info header field is included in the SIP INVITE request due to STN-SR, the Recv-Info header field that is the same as the Recv-Info header field received in the SIP INVITE request due to STN-SR except, if the ATCF supports the CS to PS SRVCC, the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

h) if the Accept header field is included in the SIP INVITE request due to STN-SR, the Accept header field that is the same as the Accept header field received in the SIP INVITE request due to STN-SR. except, if the ATCF supports the CS to PS SRVCC, the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type;

i) if the ATCF supports the CS to PS SRVCC and an Accept header field of the SIP INVITE request due to STN-SR contains the application/vnd.3gpp.access-transfer-events+xml with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":

A) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and

B) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name.

j) if the SIP INVITE request due to STN-SR contains a P-Access-Network-Info header field, a P-Access-Network-Info header field copied from the SIP INVITE request due to STN-SR.

Upon receiving a SIP 18x response or SIP 2xx response to the SIP INVITE request due to ATU-STI for PS to CS SRVCC from the SCC AS, the ATCF shall:

1) if ATCF supports CS to PS SRVCC, save the Contact header field included in the SIP response; and

NOTE 2: If the ATCF subsequently receives an initial SIP INVITE request due to STI-rSR, the ATCF will include the saved the Contact header field of the remote UE in its SIP 200 (OK) response to the initial SIP INVITE request due to STI-rSR.

2) generate and send a SIP response to the SIP INVITE request due to STN-SR populated with:

a) the Record-Route header field with a Record-Route header field that contains only the SIP URI pointing to the ATCF;

b) the same status code as the received SIP response to the SIP INVITE request due to ATU-STI for PS to CS SRVCC; and

c) if ATCF supports CS to PS SRVCC:

A) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

B) if the SIP response is SIP 1xx response, the Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the g.3gpp.access-transfer-events info package name of the Recv-Info header field of the received SIP response; and

C) if the SIP response is SIP 2xx response:

i) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

ii) the Accept header fields of the received SIP response except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type; and

iii) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-events+xml MIME type of the Accept header field of the received SIP response.

Upon receiving a SIP INFO request carrying a "call-accepted" indication the ATCF shall, if not already done according to operator policy, request the ATGW to through-connect in both directions.

NOTE 3: The details of interaction between ATCF and ATGW are out of scope of this document.

12.7.2.5 Transfer of additional session

Upon receiving a SIP REFER request for transferring additional call, the ATCF shall:

1) store the additional transferred session SCC AS URI contained in the Refer-To header field and associate it with the C-MSISDN contained in the SIP INVITE requests due to STN-SR which created the dialog in which the REFER request is received;

2) replace the additional transferred session SCC AS URI contained in the Refer-To header field with the ATCF URI for anchoring additional transferred call in ATCF allocated to the ATCF extended with any SIP URI headers of the additional transferred session SCC AS URI; and

3) forward the REFER request to the MSC Server.

Upon receiving SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF, the ATCF shall act as B2BUA and shall:

1) determine the transferable session set which are all the sessions with a speech media component:

A) associated with C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE request; and

B) where during establishment of the session a Feature-Caps header field containing the g.3gpp.srvcc feature-capability indicator was received in the initial SIP request or SIP response;

NOTE 1: The transferable sessions set potentially includes recently released sessions for which the ATCF temporarily retains session state according to subclause 12.7.2.3.

2) determine the additional session being transferred which is a session in the transferable session set with dialog identifier indicated by the Target-Dialog header field of the SIP INVITE request;

3) if ATCF supports CS to PS SRVCC and if ATCF contains an SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the <C-MSISDN> element of the <Setup-info> element of the value <srvcc-ext> root element of the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP INVITE request:

A) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE request; and

B) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request; and

4) send a SIP INVITE request towards the home network according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INVITE request towards the home network with:

A) the Request-URI set to the additional transferred session SCC AS URI previously stored and associated with the C-MSISDN equal to the URI in the P-Asserted-Identity header field of the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF;

B) all MIME bodies of the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF apart from application/sdp MIME body and apart from the application/vnd.3gpp.srvcc-ext+xml MIME body;

C) the SDP offer containing the ATGW ports and IP addresses of the selected dialog towards the remote UE as provided by the ATGW and the media types offered in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF;

D) the Target-Dialog header field set to the Target-Dialog header field of the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF;

E) the Record-Route header field containing the SIP URI of the ATCF;

F) the Contact header field that contains the contact information received in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF;

G) the P-Asserted-Identity header field that is the same as the P-Asserted-Identity header field received in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF;

H) all header fields which are included in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF and which contain option tag(s);

I) if the Recv-Info header field is included in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF, the Recv-Info header field that is the same as the Recv-Info header field received in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF except, if the ATCF supports the CS to PS SRVCC, the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

J) if the Accept header field is included in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF, the Accept header field that is the same as the Accept header field received in the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF. except, if the ATCF supports the CS to PS SRVCC, the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type;

K) if the ATCF supports the CS to PS SRVCC and an Accept header field of the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF contains the application/vnd.3gpp.access-transfer-events+xml with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":

b) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

L) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field.

M) if the SIP INVITE request due to STN-SR contains a P-Access-Network-Info header field, a P-Access-Network-Info header field copied from the SIP INVITE request due to STN-SR.

When the ATCF receives any SIP 1xx response or a SIP 2xx response to the SIP INVITE request towards the home network, the ATCF shall:

1) if ATCF supports CS to PS SRVCC, save the Contact header field included in the SIP response; and

2) generate and send a SIP response to the SIP INVITE request for anchoring call additionally transferred during PS to CS SRVCC in ATCF populated with:

A) the Record-Route header field with a Record-Route header field that contains only the SIP URI pointing to the ATCF;

B) the same status code as the received SIP response to the SIP INVITE request towards the home network;

C) if ATCF supports CS to PS SRVCC:

a) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

b) if the SIP response is a SIP 1xx response, the Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the g.3gpp.access-transfer-events info package name of the Recv-Info header field of the received SIP response; and

c) if the SIP response is a SIP 2xx response:

i) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

ii) the Accept header fields of the received SIP response except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type; and

D) all MIME bodies of the received SIP response to the SIP INVITE request towards the home network apart from application/sdp MIME body; and

E) the SDP answer containing the ATGW ports and IP addresses of the selected dialog towards the MSC server as provided by the ATGW and the media types answered in the the received SIP response to the SIP INVITE request towards the home network.

Upon receiving a SIP INFO request carrying a "call-accepted" indication the ATCF shall, if not already done according to operator policy, request the ATGW to through-connect in both directions.

NOTE 2: The details of interaction between ATCF and ATGW are out of scope of this document.

12.7.2.6 Codec inquiry prior to PS to CS SRVCC access transfer

Upon receiving a SIP OPTIONS request carrying the PS-to-CS-preparation-request, the ATCF shall send a SIP 2xx response to the SIP OPTIONS request according to 3GPP TS 24.229 [2]. In the SIP 2xx response, the ATCF shall include an application/vnd.3gpp.PS-to-CS-preparation+xml specified in subclause D.6 carrying the PS-to-CS-preparation-response. In the PS-to-CS-preparation-response, the ATCF:

1) if:

a) the session being transferred as described in subclause 12.7.2.1 is determined; or

b) the session being transferred as described in subclause 12.7.2.1 is not determined and the session being transferred as described in subclause 12.7.2.1A is determined;

then:

a) shall include a <currently-possible> XML element; and

b) shall include an <IMS-preferred-codec-list> element containing an SDP body with one audio m= line. In the m= line, in the following decreasing order of preference, the ATCF:

– shall include RTP payload type(s) with associated RTP payload type number(s) describing media received by the ATGW in a dialog of the home leg of the session being transferred. If the home leg of the session being transferred consists of several early dialogs, the ATCF shall select one early dialog according to local policy; and

– may include additional RTP payload type(s) with associated RTP payload type number(s), supported by the ATGW, describing the media which the ATGW is able to send to the MSC server, and selected by local policy.

NOTE 1: If the initial SDP offer of the session being transferred was provided by the remote UE, then the additional RTP payload type(s) can be derived from RTP payload type(s) which were offered in the initial SDP offer provided by the remote UE but which were not accepted by the SC UE. However, the SDP body received from the remote UE describes media which the remote UE wishes to receive while the SDP body in the <IMS-preferred-codec-list> element describes media which the ATGW (and the remote UE if no transcoding occurs) can send to the MSC server, i.e. media in the opposite direction. Therefore, the RTP payload types indicated in the SDP body received from the remote UE need to be adjusted before inclusion in the <IMS-preferred-codec-list> element.

The ATCF shall associate the RTP payload type(s) with the RTP payload type number(s) in the <IMS-preferred-codec-list> element so that association of the RTP payload type(s) with the RTP payload type number(s) in the <IMS-preferred-codec-list> element do not conflict with association of the RTP payload type(s) with the RTP payload type number(s) describing media received by the ATGW in the selected dialog of the home leg of the session being transferred; and

NOTE 2: RTP payload type number(s) indicated in the <MSC-server-supported-codec-list> element of the PS-to-CS-preparation-request do not influence the RTP payload type number(s) indicated in the <IMS-preferred-codec-list> element.

2) if the session being transferred as described in subclause 12.7.2.1 is not determined and the session being transferred as described n subclause 12.7.2.1A is not determined, shall include a <currently-not-possible> XML element. In the <currently-not-possible> XML element, the ATCF:

A) shall include the <state-info> element indicating the state of the session;

B) shall include the <direction> element indicating the direction of the session;

C) shall include the <speech-state> element indicating the state of the speech media component of the session;

D) if the Feature-Caps header field provided by the SCC AS in the session includes the g.3gpp.mid-call feature-capability indicator and the Contact header field provided by the SC UE in the session includes the g.3gpp.mid-call media feature tag, shall include a <feature-tag> element with the "name" attribute set to "g.3gpp.mid-call";

E) if the Feature-Caps header field provided by the SCC AS in the session includes the g.3gpp.srvcc-alerting feature-capability indicator and the Contact header field provided by the SC UE in the session includes the g.3gpp.srvcc-alerting feature tag:

i) shall include a <feature-tag> element with the "name" attribute set to "g.3gpp.srvcc-alerting"; and

ii) if the Feature-Caps header field provided by the SCC AS in the session includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting indicator and the Contact header field provided by the SC UE in the session includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag, shall include a <feature-tag> element with the "name" attribute set to "g.3gpp.ps2cs-srvcc-orig-pre-alerting";

for each session in the the transferable session set determined as specified in subclause 12.7.2.1. If the SC UE has several early dialogs created by the same SIP INVITE request, the ATCF shall include the above pieces of information for one of those early dialogs only.

12.7.3 ATCF procedures for CS to PS SRVCC

12.7.3.1 General

If the ATCF supports the CS to PS SRVCC, upon receiving SIP INFO request carrying the session transfer notification request, the ATCF shall:

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2];

2) determine the session being transferred as the session supported by the dialog of the SIP INFO request;

3) if a SIP 2xx response to the initial SIP INVITE request has been sent in the dialog of the determined session being transferred and if the determined session being transferred includes an active speech media component:

A) if the ATGW anchors the speech media component of the determined session being transferred, continue handling the procedures in the subclause 12.7.3.2; and

B) if the ATGW does not anchor the speech media component of the determined session being transferred, continue handling the procedures in the subclause 12.7.3.3; and

4) if the determined session being transferred does not include an active speech media component, continue handling the procedures in the subclause 12.7.3.4.

12.7.3.2 Transfer of session with active speech media component anchored in ATGW

If the ATCF supports the CS to PS SRVCC, in order to transfer the determined session being transferred with the speech media component anchored in ATGW, the ATCF shall:

NOTE 1: At this point, ATCF interacts with ATGW to reserve resources and provide the information needed in the procedures below. The details of interaction between ATCF and ATGW are out of scope of this document.

1) for each registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the session of the SIP INFO request carrying the session transfer notification request, set:

A) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1); and

B) the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) to the dialog identifier of the home leg of the determined session being transferred; and

2) send a SIP INFO request within the dialog of the SIP INFO request carrying the session transfer notification request according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INFO request with:

A) Info-Package header field with value g.3gpp.access-transfer-events; and

B) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and:

a) indicating the session transfer notification response;

b) indicating that the ATCF does not require the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer; and

c) containing the ATGW transfer details.

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall:

NOTE 2: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC is cancelled.

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and

2) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1).

NOTE 3: At this point, the ATCF interacts with the ATGW to release any resources reserved on PS serving leg. The details of interaction between the ATCF and the ATGW are out of scope of this document.

NOTE 4: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of this subclause are not invoked.

Unless the determined session being transferred is released, upon receiving the SIP INFO request carrying session transfer preparation, the ATCF shall:

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2].

NOTE 5: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE towards the SC UE according to the SC UE information for CS to PS SRVCC (see subclause 6A.3.1). The details of interaction between the ATCF and the ATGW are out of scope of this document.

NOTE 6: At this point, the ATCF interacts with the ATGW to start forwarding the audio media received at the IP address and port provided in the ATGW transfer details according to the ATGW information for CS to PS SRVCC (see subclause 6A.3.1) towards the remote UE. The details of interaction between the ATCF and the ATGW are out of scope of this document.

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall:

NOTE 7: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC is cancelled.

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and

NOTE 8: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE towards the MSC server according to the SDP negotiated by the MSC server in the CS serving leg. The ATCF also interacts with the ATGW to release any resources reserved on the PS serving leg. The details of interaction between the ATCF and the ATGW are out of scope of this document.

NOTE 9: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of this subclause are not invoked.

Upon receiving SIP INVITE request due to STI-rSR and if:

1) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1) of the registration path of the SIP INVITE request due to STI-rSR is set; and

2) the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) of the registration path of the SIP INVITE request due to STI-rSR is set and the dialog of the home leg of the session being transferred by CS to PS SRVCC has not been released yet;

the ATCF shall:

1) send a SIP 200 (OK) response to the received SIP INVITE request due to STI-rSR according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP 200 (OK) response with:

A) the Contact header field of the remote UE of the home leg of the session being transferred by CS to PS SRVCC;

B) the Feature-Caps header fields received in the home leg of the session being transferred by CS to PS SRVCC;

C) the Accept header fields received in the home leg of the session being transferred by CS to PS SRVCC;

D) the Recv-Info header fields received in the home leg of the session being transferred by CS to PS SRVCC;

E) all header fields received in the home leg of the session being transferred by CS to PS SRVCC, which contain option tag(s);

F) the P-Asserted-Identity header field received in the home leg of the session being transferred by CS to PS SRVCC;

G) the Privacy header fields received in the home leg of the session being transferred by CS to PS SRVCC;

H) the Record-Route header field that contains only the SIP URI pointing to the ATCF;

I) the SDP answer that includes the ATGW ports and the IP addresses as provided by the ATGW;

J) the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2] including 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, ATCF 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; and

K) 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 serving leg of the session being transferred by CS to PS SRVCC;

2) initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with:

A) the SDP offer containing the currently used media with the ATGW ports and IP addresses towards the remote UE as provided by the ATGW. The ATCF shall include in the SDP offer only the media of the media types offered in the received SIP INVITE request due to STI-rSR;

B) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3.1) previously received from the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR;

C) the Target-Dialog header field containing the dialog identifier of the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) of the registration path of the SIP INVITE request due to STI-rSR;

D) the Require header field containing the option tag "tdialog";

E) the Contact header field that contains the contact information received in the SIP INVITE request due to STI-rSR;

F) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive subsequent in-dialog requests from the SCC AS; and

NOTE 10: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route header field that the SCC AS will use when sending the in-dialog request toward the ATCF.

G) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3.1) previously received from the SCC AS and associated with the registration path of the SIP INVITE request; and

NOTE 11: Route header field(s) included in the SIP INVITE request due to STI-rSR are not inserted in the SIP INVITE request due to ATU-STI for CS to PS SRVCC.

3) for registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the registration path of the SIP INVITE request due to STI-rSR, reset the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1).

Upon receiving SIP INVITE request due to STI-rSR and if:

1) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1) of the registration path of the SIP INVITE request due to STI-rSR is set; and

the ATCF shall initiate a new dialog toward the SCC AS (i.e. a target access leg) by sending an initial SIP INVITE request due to ATU-STI for CS to PS SRVCC. The ATCF shall populate the SIP INVITE request with:

1) if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]:

A) all MIME bodies of the SIP INVITE request due to STI-rSR apart from the application/sdp MIME body; and

B) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW;

NOTE 12: ATCF interacts with ATGW to provide the needed media related information. The details of interaction between ATCF and ATGW are out of scope of this document.

2) if the ATCF decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9], all MIME bodies of the originating SIP INVITE request from MSC server;

3) the Request-URI containing the ATU-STI for CS to PS SRVCC (see subclause 6A.3.1) previously received from the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR;

4) the Contact header field that contains the contact information received in the SIP INVITE request due to STI-rSR;

5) the Record-Route header field that includes only the ATCF SIP URI, where the ATCF wants to receive subsequent in-dialog requests from the SCC AS; and

NOTE 13: The ATCF SIP URI included in the Record-Route header field is used by the SCC AS to build a Route header field that the SCC AS will use when sending the in-dialog request toward the ATCF.

6) the P-Asserted-Identity header field set to the C-MSISDN (see subclause 6A.3.1) previously received from the SCC AS and associated with the registration path of the SIP INVITE request due to STI-rSR.

Upon receiving SIP 1xx response or SIP 2xx response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC, the ATCF shall:

1) save the Contact header field included in the SIP response; and

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

A) the same response code as the received SIP response to the SIP INVITE request due to ATU-STI for CS to PS SRVCC;

B) Record-Route header field containing the SIP URI of the ATCF; and

C) the P-Charging-Vector header field as specified in 3GPP TS 24.229 [2] including 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, ATCF 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.7.3.3 Transfer of session with active speech media component not anchored in ATGW

In order to transfer the determined session being transferred with the speech media component not anchored in ATGW, the ATCF shall:

1) for each registration path(s), which have the C-MSISDN equal to the C-MSISDN associated with the session of the SIP INFO request carrying the session transfer notification request, set:

A) the CS to PS SRVCC access transfer in progress flag (see subclause 6A.3.1); and

B) the home leg of the session being transferred by CS to PS SRVCC (see subclause 6A.3.1) to the dialog identifier of the home leg of the determined session being transferred; and

A) Info-Package header field with value g.3gpp.access-transfer-events; and

B) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and:

a) indicating the session transfer notification response;

b) indicating that the ATGW requires MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer; and

c) containing the ATGW transfer details.

NOTE 2: The ATCF can bind the reserved resources in the ATGW with the C-MSISDN, which will be used to associate the SIP INVITE request due to media transfer from MSC server to ATGW with the session to be transferred.

Upon receiving a SIP INVITE request due to media transfer from MSC server to ATGW, the ATCF shall:

1) use the C-MSISDN in the SIP INVITE request to associate the SIP INVITE request due to media transfer from MSC server to ATGW with the session to be transferred and send a SIP 200 (OK) response to the SIP INVITE request according to 3GPP TS 24.229 [2].

NOTE 3: At this point, ATCF interacts with ATGW to establish the media bearer between MGW and ATGW. The details of interaction between ATCF and ATGW are out of scope of this document.

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall:

NOTE 4: the SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC is cancelled.

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and

NOTE 5: At this point, the ATCF interacts with the ATGW to release any resources reserved on PS serving leg. The details of interaction between the ATCF and the ATGW are out of scope of this document.

NOTE 6: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of this subclause are not invoked.

Unless the determined session being transferred is released, upon receiving the SIP INFO request carrying session transfer preparation, the ATCF shall:

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2].

NOTE 7: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE towards the SC UE according to the SC UE information for CS to PS SRVCC (see subclause 6A.3.1). The details of interaction between the ATCF and the ATGW are out of scope of this document.

NOTE 8: At this point, the ATCF interacts with the ATGW to start forwarding the audio media received at the IP address and port provided in the ATGW transfer details according to the ATGW information for CS to PS SRVCC (see subclause 6A.3.1) towards the remote UE. The details of interaction between the ATCF and the ATGW are out of scope of this document.

If receiving the SIP INFO request carrying the session transfer cancellation, the ATCF shall:

NOTE 9: The SIP INFO request carrying the session transfer cancellation is received only when CS to PS SRVCC is cancelled.

1) send SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2]; and

NOTE 10: At this point, the ATCF interacts with the ATGW to start forwarding the audio media from the remote UE towards the MSC server according to the SDP negotiated by the MSC server in the CS serving leg. The ATCF also interacts with the ATGW to release any resources reserved on the PS serving leg. The details of interaction between the ATCF and the ATGW are out of scope of this document.

NOTE 11: If the SIP INFO request carrying the session transfer cancellation is received, remaining procedures of this subclause are not invoked.

Upon receiving a SIP INVITE request due to STI-rSR and if:

1) the CS to PS SRVCC access transfer in progress flag (see subclause subclause 6A.3.1) of the registration path of the SIP INVITE request due to STI-rSR is set; and

the ATCF shall:

NOTE 12: At this point, the ATCF interacts with the ATGW to provide information needed in the procedures below and to request the ATGW to forward the audio media of the session being transferred from the remote UE to the SC UE. The details of interaction between the ATCF and the ATGW are out of scope of this document.