6 Roles for registration in the IM CN subsystem for service continuity

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

6.1 Introduction

Void.

6.2 SC UE

6.2.1 Distinction of requests

The SC UE needs to distinguish the following initial SIP requests:

1) SIP MESSAGE requests with the P-Asserted-Identity header field containing the STI-rSR. In the procedures below, such requests are known as "SIP MESSAGE requests with ATGW information for CS to PS SRVCC".

6.2.2 General

Prior to performing IMS registration, if the SC UE supports ICS capabilities as defined in 3GPP TS 24.292 [4], the SC UE shall check that IMS service continuity using ICS is enabled. An indication that SC using ICS is enabled or disabled can be found in the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]).

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN subsystem.

If SC using ICS is enabled then prior to making use of ICS procedures, the SC UE shall follow the procedures specified in 3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem.

The SC UE shall include the g.3gpp.accesstype media feature tag as described in clause B.3 of 3GPP TS 24.292 [4] in the Contact header field of the SIP REGISTER request.

If the SC UE supports the CS to PS SRVCC, the SC UE shall include the g.3gpp.cs2ps-srvcc media feature tag in the Contact header field of the SIP REGISTER request.

Upon receiving a SIP 2xx response to the REGISTER request and if the SIP 2xx response contains a Feature-Caps header field with the g.3gpp.atcf feature-capability indicator and with the g.3gpp.cs2ps-srvcc feature-capability indicator, the SC UE shall:

1) determine STI-rSR as the value of the g.3gpp.cs2ps-srvcc feature-capability indicator in the Feature-Caps header field containing both the g.3gpp.atcf feature-capability indicator and the g.3gpp.cs2ps-srvcc feature-capability indicator; and

2) store the determined STI-rSR.

If the SC UE supports the PS to PS access transfer and the PS to PS STI URI is configured in the SC UE, the SC UE shall include the g.3gpp.pstops-sti media feature tag in the Contact header field of the SIP REGISTER request.

6.2.3 SC UE receiving the ATGW information for CS to PS SRVCC

If the SC UE supports the CS to PS SRVCC, upon receiving a SIP MESSAGE request with ATGW information for CS to PS SRVCC, if the SIP MESSAGE request is acceptable for the UE, in addition to sending a SIP 2xx response to the SIP MESSAGE request, the SC UE shall;

1) determine the ATGW information for CS to PS SRVCC as the application/SDP MIME body of the SIP MESSAGE request;

2) store the determined ATGW information for CS to PS SRVCC;

3) generate the UE information for CS to PS SRVCC as an SDP answer to the determined ATGW information for CS to PS SRVCC according to IETF RFC 3264 [58] and 3GPP TS 24.229 [2];

4) store the generated UE information for CS to PS SRVCC; and

5) send a SIP MESSAGE request according to 3GPP TS 24.229 [2]. The SC UE shall populate the SIP MESSAGE request with:

A) Request-URI containing the determined STI-rSR;

B) Content-Disposition header field with value "render"; and

C) application/sdp MIME body containing the generated UE information for CS to PS SRVCC.

6.3 SCC AS

6.3.1 General

The SCC AS can obtain registration state information that it needs to implement SCC specific requirements from:

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third-party SIP REGISTER request) as specified in 3GPP TS 24.229 [2];

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7].

NOTE 1: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know the capabilities supported by the user registered UE(s), including the used IP-CAN(s), other than that is specified in 3GPP TS 29.328 [6], e.g. the UE PS to CS SRVCC capability and 3GPP access networks’ information related to T-ADS.

When the SCC AS obtains the registration state information including an Correlation MSISDN using one of the above procedures, the SCC AS shall determine if the registration state information is associated with ongoing CS call by matching the Correlation MSISDN against the:

a) tel URI in the P-Asserted-Identity header field or associated with the received IMRN when the SIP INVITE request was due to PS to CS STN, where the SIP INVITE request was stored according to subclause 7.3.1; or

b) tel URI in the Request-URI when the SIP INVITE request was due to processing unregistered filter criteria, where the SIP INVITE request was stored according to subclause 7.3.1.

If the registration state information is associated with an ongoing call the contents of the registration state information shall be bound to the ongoing CS call session identifier.

NOTE 2: The SCC AS has no responsibility for supervising the registration state of the SCC UE, nor taking any actions resulting from deregistration. If deregistration of the SC UE occurs, then the other functional entities in IMS, e.g. the S-CSCF, will initiate the release of SIP dialogs that are supported in the SCC AS.

6.3.2 Triggers for the SCC AS providing information to ATCF

This subclause applies for a contact address (or a registration flow, if multiple registration mechanism is used) in the registration state information obtained by SCC AS:

1) which is registered by the UE:

A) in NG-RAN, E-UTRAN, UTRAN or GERAN; and

NOTE: The access network where the UE performed registration can be found in the P-Access-Network-Info header field of the SIP REGISTER request.

B) for a private user identity associated with a C-MSISDN; and

2) where the SIP REGISTER request contained a Feature-Caps header field containing the g.3gpp.atcf feature-capability indicator.

The SCC AS shall identify the ATCF URI for terminating requests of the related ATCF as the URI in the g.3gpp.atcf-path feature-capability indicator included in a Feature-Caps header field of the SIP REGISTER request that created the binding.

The SCC AS shall store the feature-capability indicators indicated in the Feature-Caps header field containing the g.3gpp.atcf feature-capability indicator until the binding is removed.

The SCC AS shall determine that PS to CS SRVCC is usable for the UE if the private user identity of the UE has an associated STN-SR (see 3GPP TS 29.328 [6]) and:

1) the UE PS to CS SRVCC Capability (see 3GPP TS 29.328 [6]) of the UE has value UE-SRVCC-CAPABILITY-SUPPORTED;

2) the UE 5G SRVCC Capability (see 3GPP TS 29.328 [6]) of the UE has value UE-5G-SRVCC-CAPABILITY-SUPPORTED;

3) the g.3gpp.accesstype media feature tag is present in a Contact header field of the SIP REGISTER request from the UE;

4) the SRVCC data for the UE (see 3GPP TS 29.562 [xx]) contains the ueSrvccCapabilities attribute set to:

A) "UE_4G_SRVCC_CAPABLE";

B) "UE_5G_SRVCC_CAPABLE"; or

C) "UE_4G_SRVCC_CAPABLE" and "UE_5G_SRVCC_CAPABLE"; or

5) any combination of the above.

If SCC AS supports CS to PS SRVCC, the SCC AS shall also determine whether the CS to PS SRVCC is usable for the private user identity of the UE as described in subclause 6.3.4.

When the SCC AS becomes aware of a new contact address (or new registration flow, if multiple registration mechanism is used) that fulfils the above criteria and:

– PS to CS SRVCC is usable for the UE; or

– the SCC AS supports CS to PS SRVCC and CS to PS SRVCC is usable for the UE;

the SCC AS shall perform actions as described in subclause 6.3.3 with the related ATCF.

When the SCC AS becomes aware that, for a UE which registered the contact address (or registered the registration flow, if multiple registration mechanism is used) that fulfils the above criteria that:

1) PS to CS SRVCC was usable and PS to CS SRVCC is not usable now;

2) PS to CS SRVCC was not usable and PS to CS SRVCC is usable now; or

3) the SCC AS supports CS to PS SRVCC and:

A) CS to PS SRVCC was usable and CS to PS SRVCC is not usable now; or

B) CS to PS SRVCC was not usable and CS to PS SRVCC is usable now;

then the SCC AS shall provide the PS to CS SRVCC related information to the related ATCF as described in subclause 6.3.3.

6.3.3 SCC AS providing the PS to CS SRVCC related information to the ATCF

In order to provide the PS to CS SRVCC related information to the ATCF, the SCC AS shall perform the role of an AS acting as originating UA according to 3GPP TS 24.229 [2] subclause 5.7.3 using the procedure for sending an initial request on behalf of a PSI and shall send a SIP MESSAGE request populated as follows:

1) the Request-URI set to the ATCF management URI of the ATCF associated with the registration path (or registration flow, if multiple registration mechanism is used);

NOTE 1: The ATCF management URI of the ATCF is the URI contained in the g.3gpp.atcf-mgmt-uri feature-capability indicator that is included in a Feature-Caps header field of the SIP REGISTER request which the S-CSCF received from the UE using the method to obtain registration state information described in step a) of subclause 6.3.1.

2) the P-Asserted-Identity header field containing the identity of the SCC AS;

3) the application/vnd.3gpp.SRVCC-info+xml MIME body as defined in clause D.3;

NOTE 2: The ATCF URI for terminating calls of the registration path (or registration flow, if multiple registration mechanism is used) is contained in the g.3gpp.atcf-path feature-capability indicator that is included in a Feature-Caps header field of the SIP REGISTER request which the S-CSCF received from the UE using the method to obtain registration state information described in step a) of subclause 6.3.1.

4) the P-Charging-Vector header field containing a type 1 "orig-ioi" header field parameter. The SCC AS shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The SCC AS shall not include the type 1 "term-ioi" header field parameter; and

5) if the SCC AS supports indicating the traffic leg associated with a URI as specified in IETF RFC 7549 [83], the UE is roaming and if required by local policy, the SCC AS shall:

a) append the "iotl" SIP URI parameter to the URI in the Request-URI with a value set to "homeB-visitedB";

b) if required by local policy, the SCC AS may append an "iotl" SIP URI parameter with a value set to "visitedA-homeA" to:

– the ATU-STI URI in the the application/vnd.3gpp.SRVCC-info+xml MIME body defined in clause D.3; and

– the additional transferred session SCC AS URI for PS to CS SRVCC in the Refer-To URI of SIP REFER requests.

NOTE 3: The SCC AS can use the P-Visited-Network-Identity header field in the 3^rd party SIP REGISTER request received when the UE registered in PS to determine if the UE is roaming or not.

6.3.4 Triggers for the SCC AS providing information to MSC server

If the SCC AS supports the CS to PS SRVCC, this subclause applies for a contact address in the registration state information obtained by SCC AS:

1) which is registered for a private user identity associated with an MSC server enhanced for ICS according to 3GPP TS 23.003 [12], subclause 20.3.3;

2) which is registered for a private user identity associated with a C-MSISDN; and

3) where the g.3gpp.cs2ps-srvcc media feature tag and the g.3gpp.path media feature tag are associated with the contact address.

The SCC AS shall determine that the CS to PS SRVCC is usable if:

1) a private user identity of a UE (i.e. other than those according to 3GPP TS 23.003 [12], subclause 20.3.3) associated with the same C-MSISDN as the private user identity belonging to the MSC server exists;

2) a binding of a contact address exists for the private user identity of the UE:

A) such that the g.3gpp.cs2ps-srvcc media feature tag 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 and with g.3gpp.cs2ps-srvcc media feature tag;

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

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

When the SCC AS becomes aware of a new contact address that fulfils the above criteria and the CS to PS SRVCC is usable, the SCC AS shall perform actions as described in subclause 6.3.5 for the contact address.

When the SCC AS becomes aware that, for a contact address:

1) the CS to PS SRVCC was usable and the CS to PS SRVCC is not usable now; or

2) the CS to PS SRVCC was not usable and the CS to PS SRVCC is usable now;

then the SCC AS shall perform actions as described in subclause 6.3.5 for the contact address.

6.3.5 SCC AS providing the CS to PS SRVCC information to the MSC server

If the SCC AS supports the CS to PS SRVCC, in order to provide the CS to PS SRVCC information to a contact address registered by the MSC server, the SCC AS shall perform the role of an AS acting as originating UA according to 3GPP TS 24.229 [2] subclause 5.7.3 using the procedure for sending an initial request on behalf of a PSI and shall send a SIP MESSAGE request populated as follows:

1) the Request-URI set to an IMS public user identity registered at the contact address;

2) the P-Asserted-Identity header field containing the identity of the SCC AS;

3) the Accept-Contact header field with the g.3gpp.path media feature tag with value of the g.3gpp.path media feature tag associated with the contact address and with "explicit" and "require";

4) the application/vnd.3gpp.srvcc-ext+xml MIME body; and

NOTE: The MSC URI for terminating calls of the contact address is contained in the g.3gpp.path media feature tag that is included in a Contact header field of the SIP REGISTER request which the S-CSCF received from the UE using the method to obtain registration state information described in step a) of subclause 6.3.1.

5) the P-Charging-Vector header field containing a type 1 "orig-ioi" header field parameter. The SCC AS shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The SCC AS shall not include the type 1 "term-ioi" header field parameter.

6.4 MSC server

6.4.1 Distinction of requests

The MSC server needs to distinguish the following initial SIP requests:

1) SIP MESSAGE requests with the Accept-Contact header field containing the g.3gpp.path media feature tag and with the application/vnd.3gpp.srvcc-ext+xml MIME body. In the procedures below, such requests are known as "SIP MESSAGE requests with MSC information for CS to PS SRVCC".

6.4.2 General

If the MSC server:

– provides the role of an MSC server enhanced for ICS; and

– determines that the served user is an ICS user;

then in addition to the procedures specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] the MSC server shall:

1) if the MSC server supports the MSC server assisted mid-call feature, include the g.3gpp.mid-call media feature tag (as described in annex C) in the Contact header field of the SIP REGISTER request; and

2) if the MSC server supports the CS to PS SRVCC:

A) include the g.3gpp.cs2ps-srvcc media feature tag in the Contact header field of the SIP REGISTER request; and

B) include the g.3gpp.path media feature tag in the Contact header field of the SIP REGISTER request with value uniquely identifying the registration path.

6.4.3 MSC server receiving the MSC information for CS to PS SRVCC

If the MSC server supports the CS to PS SRVCC, upon receiving SIP MESSAGE requests with MSC information for CS to PS SRVCC, the MSC server shall:

1) if the URI in the P-Asserted-Identity header field of the SIP MESSAGE request does not identify an SCC AS authorised to provide the CS to PS SRVCC information, reject the request with SIP 403 (Forbidden) response and do not continue with the remaining steps;

NOTE: in this version of specification, the URIs of SCC ASs authorised to provide PS to CS SRVCC information need to be specified in the roaming agreement.

2) bind the CS to PS SRVCC information received in the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP MESSAGE request to the contact address ; and

3) send a SIP 200 (OK) response to the MESSAGE request according to 3GPP TS 24.229 [2] and include in the P-Charging-Vector header field the "icid-value" header field parameter set to the value received in the request, the "orig-ioi" header field parameter, if received in the request and a type 1 "term-ioi" header field parameter that identifies the sending network.

6.5 Access Transfer Control Function (ATCF)

6.5.1 Distinction of requests

The ATCF needs to distinguish the following initial SIP requests:

1) SIP REGISTER requests with the ATCF URI for originating requests in the topmost Route header field. In the procedures below, such requests are known as "SIP REGISTER request originated by a UE".

2) SIP MESSAGE requests with the ATCF management URI 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 MESSAGE requests with the PS to CS SRVCC related information".

3) SIP MESSAGE requests with the STI-rSR allocated by 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 MESSAGE requests with UE information for CS to PS SRVCC".

6.5.2 Registration related procedures in the ATCF

Upon receiving a SIP REGISTER request originated by a UE, the ATCF shall:

1. if ATCF decides to include itself for access transfer of sessions according to operator policy:

NOTE 1: An example of the operator policy is that the ATCF is included in the signalling path only when the UE registers over the NG-RAN, E-UTRAN, UTRAN or GERAN.

A. generate a unique ATCF URI for terminating requests such that the registration path (or registration flow, if multiple registration mechanism is used) can be determined for terminating requests;

NOTE 1A: One possible construction method is to set the user portion of the ATCF URI for terminating requests to the URI of the most bottom Path header field of the SIP REGISTER request.

B. insert a Path header field with the generated ATCF URI for terminating requests;

C. insert a Feature-Caps header field as described in RFC 6809 [60] with:

a. the g.3gpp.atcf feature-capability indicator containing the STN-SR allocated to ATCF included as described in IETF RFC 6809 [60];

b. the g.3gpp.atcf-mgmt-uri feature-capability indicator containing the ATCF management URI included as described in IETF RFC 6809 [60];

c. the g.3gpp.atcf-path feature-capability indicator with value containing the generated ATCF URI for terminating requests as described in IETF RFC 6809 [60];

d. if the ATCF is aware that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the MSC server assisted mid-call feature:

– the g.3gpp.mid-call feature-capability indicator;

e. if the ATCF is aware that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the PS to CS SRVCC for calls in alerting phase:

– the g.3gpp.srvcc-alerting feature-capability indicator; and

– if the ATCF is aware that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the PS to CS SRVCC for originating calls in pre-alerting phase:

i. the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C; and

– if the ATCF is aware that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the PS to CS SRVCC for terminating calls in pre-alerting phase:

i. the g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator as described in annex C; and

f. if the Contact header field of the SIP REGISTER request contains the g.3gpp.cs2ps-srvcc media feature tag and if the ATCF supports the CS to PS SRVCC:

– the g.3gpp.cs2ps-srvcc feature-capability indicator containing the STI-rSR allocated by ATCF;

NOTE 2: Since the ATCF cannot be aware of which MSC server the SC UE can potentially be transferred to and the PS to CS SRVCC access transfer for a call in alerting phase is optional, all MSC servers in the network where the SC UE is attached needs to support the PS to CS SRVCC access transfer for a call in alerting phase before the ATCF can indicate support.

NOTE 3: Since the ATCF cannot be aware of which MSC server the SC UE can potentially be transferred to and the PS to CS SRVCC access transfer for a call in pre-alerting phase is optional, all MSC servers in the network where the SC UE is attached needs to support the PS to CS SRVCC access transfer for a call in pre-alerting phase before the ATCF can indicate support.

NOTE 4: Since the ATCF cannot be aware of which MSC server the SC UE can potentially be transferred to and the MSC server assisted mid-call feature is optional, all MSC servers in the network where the SC UE is attached needs to support the MSC server assisted mid-call feature before the ATCF can indicate support.

2. 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 exit point of the visited network and forward the request to that entry point;

NOTE 5: The list of the exit points can be either obtained as specified in RFC 3263 [72] or provisioned in the ATCF.

3. if the ATCF is located in the visited network and local policy does not require the application of IBCF capabilities in the visited network towards the home network select an entry point of the home network and forward the request to that entry point;

NOTE 6: The list of the entry points can be either obtained as specified in RFC 3263 [72] or provisioned in the ATCF. The entry point can be an IBCF or an I-CSCF.

4. if the ATCF is located in the home network select an I-CSCF of the home network and forward the request to that I-CSCF; and

NOTE 7: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [72] or provisioned in the ATCF.

5. if the ATCF fails to forward the SIP REGISTER request to any entry point, the ATCF shall send back a SIP 504 (Server Time-Out) response, in accordance with the procedures in RFC 3261 [19].

Upon receiving a SIP 2xx response to the SIP REGISTER request originated by a served UE and if ATCF decided to include itself for access transfer of sessions according to operator policy, the ATCF shall:

1) update the S-CSCF Service-Route URI bound to the registration path (see subclause 6A.3.1) identified by the ATCF Path URI;

NOTE 8: The ATCF Path URI is the URI which the ATCF inserted in the Path header field of to the SIP REGISTER request.

NOTE 9: The S-CSCF Service-Route URI is the URI in the most bottom Service-Route header field of the SIP 2xx response to the SIP REGISTER request.

2) if the Contact header field of the SIP REGISTER request contains the g.3gpp.cs2ps-srvcc media feature tag and if the ATCF supports the CS to PS SRVCC:

A) for the registration path, which has the ATCF Path URI matching the URI which the ATCF inserted in the Path header field of to the SIP REGISTER request:

a) set the route set towards the SC UE bound to the registration path (see subclause 6A.3.1) to the Path header fields in the received SIP 2xx response preceding the ATCF Path URI; and

b) set the contact address of the SC UE bound to the registration path (see subclause 6A.3.1) to the Contact header field of the SIP REGISTER request; and

3) insert a Feature-Caps header field with:

A) the g.3gpp.atcf feature-capability indicator containing the STN-SR allocated to ATCF included as described in IETF RFC 6809 [60]; and

B) if the Contact header field of the SIP REGISTER request contains the g.3gpp.cs2ps-srvcc media feature tag and if the ATCF supports the CS to PS SRVCC:

a) the g.3gpp.cs2ps-srvcc feature-capability indicator containing the STI-rSR allocated by ATCF.

6.5.3 ATCF receiving the SRVCC-related information

Upon receiving SIP MESSAGE request with the SRVCC-related information, the ATCF shall:

1) if the URI in the P-Asserted-Identity header field of the SIP MESSAGE request does not identify an SCC AS authorised to provide the SRVCC-related information, reject the request with SIP 403 (Forbidden) response and do not continue with the remaining steps;

NOTE: in this version of specification, the URIs of SCC ASs authorised to provide SRVCC-related information need to be specified in the roaming agreement.

2) update the SRVCC-related information bound to the registration path(s) (see subclause 6A.3.1) with information in the application/vnd.3gpp.SRVCC-info+xml MIME body of the SIP MESSAGE request;

3) determine session(s) established using the registration path(s) (see subclause 6A.3.1) whose SRVCC-related information were updated by the SRVCC-related information received in the SIP MESSAGE request and associate those session(s) with the SRVCC-related information bound to the registration path(s);

4) for each registration path in the SRVCC-related information received in the SIP MESSAGE request:

A) if:

a) the ATCF indicated the support of the CS to PS SRVCC when handling the SIP REGISTER request establishing the registration path;

b) the SRVCC-related information for the registration path contains the ATU-STI for CS to PS SRVCC; and

c) the ATCF does not have the UE information for CS to PS SRVCC bound to the registration path;

send the ATGW information for CS to PS SRVCC to the SC UE within the registration path using procedure described in subclause 6.5.4; and

5) send a SIP 200 (OK) response to the MESSAGE request according to 3GPP TS 24.229 [2] and include in the P-Charging-Vector header field the "icid-value" header field parameter set to the value received in the request, the "orig-ioi" header field parameter, if received in the request and a type 1 "term-ioi" header field parameter that identifies the sending network.

6.5.4 ATCF sending the ATGW information for CS to PS SRVCC

If the ATCF supports the CS to PS SRVCC, in order to send the ATGW information for CS to PS SRVCC to the SC UE within a registration path, the ATCF shall:

1) generate the ATGW information for CS to PS SRVCC. When generating the SDP, the ATCF shall:

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

B) set port number of the media line to 9;

2) set the ATGW information for CS to PS SRVCC bound to the registration path (see subclause 6A.3.1) to the generated ATGW information for CS to PS SRVCC; and

3) send SIP MESSAGE request according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP MESSAGE request with:

A) Request-URI containing the contact address of the SC UE bound to the registration path (see subclause 6A.3.1);

B) Route header fields containing the route set towards the SC UE of the registration path (see subclause 6A.3.1);

C) P-Asserted-Identity header field containing the STI-rSR allocated by ATCF;

D) Content-Disposition header field with value "render"; and

E) application/sdp MIME body containing the generated ATGW information for CS to PS SRVCC.

6.5.5 ATCF receiving the UE information for CS to PS SRVCC

If the ATCF supports the CS to PS SRVCC, upon receiving SIP MESSAGE request with UE information for CS to PS SRVCC and if the SIP MESSAGE request is acceptable for the ATCF, in addition to sending a SIP 2xx response to the SIP MESSAGE request, the ATCF shall:

1) determine the related registration path, which is a registration path with the ATCF Path URI matching the URI in the top Route header field of the SIP MESSAGE request; and

2) set the UE information for CS to PS SRVCC bound to the determined related registration path (see subclause 6A.3.1) to the application/sdp MIME body of the SIP MESSAGE request.