10 Roles for PS-PS access transfer

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

10.1 Introduction

This clause specifies the procedures for PS-PS access transfer for both full media transfer case and partial media transfer case. Procedures are specified for the SC UE and the SCC AS.

10.2 SC UE

10.2.0 General

The SC UE may be engaged in one or more ongoing sessions or in one or more SIP dialogs in early state before performing access transfer. By an ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received. By a SIP dialog in early state, it is meant an early SIP dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the SIP 2xx response has not yet been sent or received.

The SC UE shall follow the procedures specified in subclause 6.2 to perform registration in the IM CN subsystem on the newly selected access network before performing PS-PS access transfer. When registering a new contact address, the SC UE may either:

a) not employ the multiple registration mechanism. In this case, upon the registration of the new contact address, all dialogs associated with the old contact address are terminated by the S-CSCF. The terminated dialogs include the dialog on the Source Access Leg and the SC UE’s subscription dialog to its reg-event; or

NOTE 1: Since the SCC AS retains the information pertaining to the dialog on the Source Access Leg, as specified in subclause 10.3.4, upon receiving an initial SIP INVITE request due to PS to PS STI (i.e. on the Targer Access Leg) containing the Replaces header field, the SCC AS will be able to identify the dialog toward the the remote UE associated with the dialog on the Source Access Leg being replaced.

b) employ the multiple registration mechanism. In this case, the SC UE may either:

– add new flow that terminates at the new contact address, and leave all dialogs associated with the old flow and old contact address intact; or

– replace the old flow that terminates at the old contact address with a new flow that terminates at the new contact address, resulting in all dialogs associated with the old flow and old contact address being terminated (include the dialog on the Source Access Leg and the SC UE’s subscription dialog to its reg-event).

NOTE 2: Since the SCC AS retains the information pertaining to the dialog on the Source Access Leg, as specified in subclause 10.3.4, upon receiving an initial SIP INVITE request due to PS to PS STI (i.e. on the Targer Access Leg) containing the Replaces header field, the SCC AS will be able to identify the dialog toward the the remote UE associated with the dialog on the Source Access Leg being replaced.

NOTE 3: When transferring all media from the Source Access Leg to the Target Access Leg, the SC UE can replace the old flow with a new flow, and let the network terminate all dialogs and the registration associated with the old flow, rather than the SC UE performing these actions itself.

10.2.1 Full session transfer

This subclause specifies a full session transfer applicable to a SC UE that supports dual mode operation and multiple registration procedure.

To initiate PS-PS access transfer for a session, upon acquiring the resources for media on the Target Access Leg, the SC UE shall send a SIP INVITE request due to PS to PS STI on the Target Access Leg in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows:

1) the Request-URI set to

A) if the PS to PS STI URI is configured in the SC UE, the configured PS to PS STI URI; and

B) if the PS to PS STI URI is not configured in the SC UE, the URI contained in the Contact header field returned at the creation of the dialog on the Source Access Leg;

2) include in the Contact header field:

A) a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at registration; and

B) the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4];

3) select one of the following options:

A) if usage of SIP Replaces extension is selected:

a) the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the session to be transferred; and

b) the Require header field populated with the option tag value "replaces"; or

B) if usage of SIP Target-Dialog extension is selected:

a) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the session to be transferred; and

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

4) the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same number of media lines in the same order, where each media line corresponds to one of the media components in the original session, unless media components need to be added, and such that:

A) each media line indicates the same media type as its corresponding media component in the original session and contains at least one codec that was negotiated during the original session;

B) all or a subset of payload type numbers and their mapping to codecs and media parameters are not conflicting with those negotiated in the original session.; and

C) if the SC UE determines to:

a) remove a media component during the transfer, set the media line for this media component to a port number with value zero; and

b) add new media component(s) during the transfer, include one additional media line with the desired media type and codecs for each new media component at the end of the SDP and indicate that the resources are available;

5) if the Source Access Leg is an early dialog and this early dialog was created by the SC UE receiving a SIP INVITE request, indicate support of the info package mechanism as specified in IETF RFC 6086 [54]; and

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

NOTE 1: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service control signalling, the SC UE can perform an access transfer of the service control signalling from the current IP-CAN to a new IP‑CAN with the same capabilities (i.e. supporting CS and PS bearers, simultaneously) while retaining the media component in the CS access network by including the description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, so that service continuity of the session is maintained.

If the dialog on the Source Access Leg is a confirmed dialog, then upon receiving SIP 2xx response for its SIP INVITE request due to PS to PS STI sent on the Target Access Leg, the SC UE shall:

1) send a SIP ACK request;

2) consider the confirmed dialog on the Source Access Leg as being successfully transferred to the Target Access Leg; and

3) send a SIP BYE request to the SCC AS on the Source Access Leg to terminate the confirmed dialog on the Source Access Leg, if the confirmed dialog is still active (e.g. it has not been released by the SCC AS).

NOTE 2: If the dialog on the Source Access Leg is a confirmed dialog, the SC UE upon sending an initial SIP INVITE request due to PS to PS STI on the Target Access Leg will not receive any SIP provisional response from the SCC AS, i.e. the initial SIP INVITE request due to PS to PS STI is either accepted with the SIP 200 (OK) response containing the SDP answer or rejected with an appropriate final SIP response.

NOTE 2A: If the contact address used by the dialog over the Source Access Leg was registered using multiple registration procedure, and the flow over the Target Access Leg did not replace the flow over the Source Access Leg, then upon transferring the dialog to the Target Access Leg, the SC UE is still registered on the Source Access Leg and its subscription dialog to its reg-event the Source Access Leg is intact.

If the dialog on the Source Access Leg is a confirmed dialog and if the SC UE receives any SIP 4xx – 6xx response to the SIP INVITE request due to PS to PS STI sent on the Target Access Leg, then PS-PS access transfer has not completed successfully and the call will continue in the Source Access Leg.

If the dialog on the Source Access Leg is an early dialog, then upon receiving a SIP 183 (Session Progress) response for its SIP INVITE request due to PS to PS STI sent on the Target Access Leg containing the SDP answer, the SC UE shall:

NOTE 3: If the dialog on the Source Access Leg is an early dialog, then the SC UE upon sending an initial SIP INVITE request due to PS to PS STI on the Target Access Leg, receives either a SIP 183 (Session Progress) response containing the SDP answer or the initial SIP INVITE request due to PS to PS STI is rejected with an appropriate final SIP response.

1) respond with a SIP PRACK request; and

2) upon receiving the SIP 200 (OK) response for the SIP PRACK request, consider the early dialog on the Source Access Leg as being successfully transferred to the Target Access Leg and being at the same early dialog stage as the early dialog on the Source Access Leg.

NOTE 4: All subsequent SIP requests or SIP responses originating from the remote UE and destined for the SC UE will be sent to the SC UE over the Target Access Leg. For example, in case of an early dialog originated by the SC UE sending an initial SIP INVITE request to the remote UE and receiving a SIP 183 (Session Progress) response on the Source Access Leg, and subsequently transferring the early dialog to the Target Access Leg, the SIP 180 (Ringing) response from the remote UE will be conveyed to the SC UE on the Target Access Leg rather than on the Source Access Leg.

Since, upon receiving the SIP 200 (OK) response for the SIP PRACK request, the early dialog and the associated media have been transferred from the Source Access Leg to the Target Access Leg (i.e. the resources for media on the Source Access Leg are not used any more), the SC UE may releases the resources on the Source Access Leg by sending a SIP UPDTE request with an appropriate SDP offer on the Source Access Leg. However, in spite of releasing the resources, the dialog on the Source Access Leg is still in the early dialog phase.

If the dialog on the Source Access Leg is an early dialog that was created by the SC UE receiving a SIP INVITE request on the Source Access Leg (i.e. an incoming call), then upon receiving the SIP 200 (OK) response for the SIP PRACK request, the SC UE shall:

1) if the served user accepted the incoming call:

a) send the SIP INFO request on the Target Access Leg containing:

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

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

b) upon receiving the SIP 200 (OK) response for the SIP INFO request, and subsequently upon receiving a SIP 200 (OK) response for its SIP INVITE request due to PS to PS STI sent on the Target Access Leg:

A) consider the early dialog becoming a confirmed dialog and as being successfully transferred to the Target Access Leg; and

B) release the early dialog on the Source Access Leg, by sending a SIP 410 (Gone) response on the Source Access Leg, if this early dialog is still active (e.g. it has not been previously terminated by the SCC AS);

2) if the incoming call is rejected:

NOTE 5: If, upon the early dialog being transferred to the Target Access Leg, the SC UE rejects the incoming call, the SC UE will terminate the early dialog on the Target Access Leg and the early dialog on the Source Access Leg.

a) send a SIP CANCEL request on the Target Access Leg that pertains to the SIP INVITE request due to PS to PS STI; and

b) send a SIP 410 (Gone) response to the initial SIP INVITE request received on the Source Access Leg; or

3) if the early dialog is transferred back from the Target Access Leg to the Source Access Leg (e.g. the radio is lost while the SC UE is ringing) before the SC UE sends the SIP INFO request on the Target Access Leg:

NOTE 6: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, it will re-acquire the resources for media on the Source Access Leg, terminate the early dialog on the Target Access Leg, and accept the incoming call on the Source Access Leg.

a) release the early dialog on the Target Access Leg, by sending a SIP CANCEL request on the Target Access Leg that pertains to the SIP INVITE request due to PS to PS STI;

b) re-acquire the resources for media on the Source Access Leg, if previously released, send a SIP UPDATE request with an appropriate SDP offer on the Source Access Leg; and

c) when the served user ether accepts the call or the call is rejected, send the respective final SIP response on the Source Access Leg, as specified in 3GPP TS 24.229 [2].

If the dialog on the Source Access Leg is an early dialog that was created by the SC UE sending a SIP INVITE request on the Source Access Leg (i.e. an outgoing call), then upon receiving SIP 200 (OK) response for the SIP PRACK request, the SC UE shall:

1) if the SC UE receives a SIP 200 (OK) response for the SIP INVITE request due to PS to PS STI sent on the Target Access Leg (i.e. the outgoing call is accepted by the remote UE):

a) send a SIP ACK request to the received SIP 200 (OK) response;

b) consider the early dialog becoming a confirmed dialog and as being successfully transferred to the Target Access Leg; and

c) terminate the early dialog on the Source Access Leg, by sending a SIP CANCEL request on the Source Access Leg, if this early dialog is still active (e.g. has not been previously terminated by the SCC AS);

2) if the SC UE receives a the SIP 410 (Gone) response to the initial SIP INVITE request on the Source Access Leg, and subsequently any SIP 4xx or 5xx final response to the SIP INVITE request due to PS to PS STI (i.e. the outgoing call is rejected by the remote UE):

a) consider the early dialogs as terminated; or

NOTE 7: If the remote UE rejects the call, the SCC AS will terminate the early dialog on the Source Access Leg prior to terminating the early dialog on the Target Access Leg. This will insure that the SC UE does not un-necessarily transfer the call to the Source Access Leg (e.g. re-acquires the resources for media) prior to the early dialog on the Source Access Leg being terminated.

3) if the early dialog is transferred back from the Target Access Leg to the Source Access Leg (e.g. the radio is lost while the remote UE is ringing) before the SC UE receives any final response on the Target Access Leg:

NOTE 8: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, it will re-acquire the resources for media on the Source Access Leg, terminate the early dialog on the Target Access Leg, and wait for the outgoing call to be either accepted or rejected by the remote UE.

a) release the early dialog on the Target Access Leg, by sending a SIP CANCEL request on the Target Access Leg that pertains to the SIP INVITE request due to PS to PS STI;

b) re-acquire the resources for media on the Source Access Leg, if previously released and send a SIP UPDATE request with an appropriate SDP offer on the Source Access Leg; and

c) wait for the final SIP response from the remote UE on the Source Access Leg that will indicate whether the call was accepted or rejected by the remote UE, and proceed as specified in 3GPP TS 24.229 [2].

If the dialog on the Source Access Leg is an early dialog and if the SC UE receives a SIP 4xx – 6xx response to its initial SIP INVITE request due to PS to PS STI sent on the Target Access Leg, (i.e. the access transfer of the early dialog has not completed successfully), the early dialog shall continue on the Source Access Leg, if this early dialog is still active. Hence, the SC UE shall:

NOTE 9: Since the early dialog on the Target Access Leg is terminated by the SCC AS, the SC UE re-acquires the resources on the Source Access Leg.

a) re-acquire the resources for media on the Source Access Leg, if previously released and send a SIP UPDATE request with an appropriate SDP offer on the Source Access Leg; and

b) respond with a SIP ACK request to the SIP 4xx – 6xx response, and consider the early dialog on the Target Access Leg as terminated, and either:

A) wait for the final SIP response from the remote UE on the Source Access Leg that will indicate whether the call was accepted or rejected by the remote UE, if the call is originated by the SC UE; or

B) send the respective final SIP response on the Source Access Leg when the call is accepted or rejected by the user, if the call is terminated at the SC UE.

10.2.1A Void

10.2.2 Partial session transfer

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request due to PS to PS STI over the Target Access Leg in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows:

1. the Request-URI set to:

A) if the PS to PS STI URI is configured in the SC UE, the configured PS to PS STI URI; and

B) if the PS to PS STI URI is not configured in the SC UE, the URI contained in the Contact header field returned at the creation of the dialog over the Source Access Leg;

2. include in the Contact header field:

A. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at registration; and

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4];

3. the Require header field with the option tag "tdialog" included;

4. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the session to be transferred;

5. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same number of media lines in the same order, where each media line corresponds to one of the media components in the original session, unless media components need to be added during the session transfer, and such that:

A) each media line indicates the same media type as its corresponding media component in the original session and contains at least one codec that was negotiated during the original session;

B) all or a subset of payload type numbers and their mapping to codecs and media parameters are not conflicting with those negotiated in the original session; and

C) if the SC UE determines to:

a. keep the media component on the Source Access Leg, set the media line for this media component to a port number with value zero; and

b. add new media component(s) during the transfer, include one additional media line with the desired media type and codecs for each new media component at the end of the SDP; and

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service control signalling, the SC UE can perform an access transfer of the service control signalling from the current IP-CAN to a new IP‑CAN with the same capabilities (i.e. supporting CS and PS bearers, simultaneously) while retaining the media component in the CS access network by including the description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, so that service continuity of the session is maintained.

6. signalling elements described in subclause 6A.2.2.2.

Upon receiving SIP 2xx response for the SIP INVITE request due to PS to PS STI sent over the Target Access Leg and sending SIP ACK request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the original session. The SC UE shall populate the SIP re-INVITE request as follows:

1. the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall set the port number for a media component to zero if that media component has been transferred to the Target Access Leg or has to be removed.

If the SC UE receives any SIP 4xx – 6xx response to the SIP INVITE request due to PS to PS STI sent over the Target Access Leg, then PS-PS access transfer has not completed successfully and the call will continue in the Source Access Leg.

10.2.3 Void

10.3 SCC AS

10.3.1 Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality relating to access transfer:

– If the g.3gpp.pstops-sti media feature tag was included in the Contact header field of the REGISTER request when the SC UE registered, SIP INVITE requests routed to the SCC AS with the Request-URI containing the PS to PS STI URI belonging to the subscribed user are known as "SIP INVITE requests due to STI".

– If the g.3gpp.pstops-sti media feature tag was not included in the Contact header field of the REGISTER request when the SC UE registered, SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request-URI and not containing the additional transferred session SCC AS URI in the Request-URI are known as "SIP INVITE requests due to STI".

NOTE: The media streams that need to be transferred are identified using information described in the subsequent sections.

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner conformant with 3GPP TS 24.229 [2].

10.3.2 PS to PS access transfer procedures at the SCC AS

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only.

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall:

– associate the SIP INVITE request on the Target Access Leg with a confirmed dialog or an early dialog on the Source Access Leg by matching the dialog identifier present in either the Replaces header field (see IETF RFC 3891 [10]) or the Target Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE request with a confirmed dialog or with an early dialog. By a previously established dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received. By an early dialog, it is meant an early dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the SIP 2xx response has not yet been sent or received;

– if the SCC AS is unable to associate the SIP INVITE request with a confirmed dialog or an early dialog, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to STI and not processes the remaining steps;

– if the SIP INVITE request contains a Replaces header field:

a) void; and

b) send a SIP re-INVITE request towards the remote UE using the confirmed dialog or send SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created by the same SIP INVITE request as the Source Access Leg. The SCC AS shall populate the SIP re-INVITE request or the SIP UPDATE request(s) with a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. If priority is supported:

1) if the SIP INVITE request contains a Resource-Priority header field, copy the Resource-Priority header field to the SIP re-INVITE request or the SIP UPDATE request; or

2) otherwise, if a confirmed dialog or an early dialog on the Source Access Leg previously contained an authorised Resource-Priority header field, the SCC AS shall populate the SIP re-INVITE request or the SIP UPDATE request with the authorised Resource-Priority header field;

– otherwise, if the SIP INVITE request contains a Target Dialog header field:

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

b) otherwise, either send a SIP re-INVITE request towards the remote UE using the confirmed dialog or send a SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created by the same SIP INVITE request as the Source Access Leg. The SCC AS shall populate the SIP re-INVITE or the SIP UPDATE request(s) as follows:

1) void; and

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following media information:

i) the media characteristics as received in the SIP INVITE request due to STI received on the Target Access Leg for media streams whose port is not set to zero; and

ii) for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the corresponding media characteristics of those streams from the Source Access Leg; and

3) if priority is supported:

i) if the SIP INVITE request contains a Resource-Priority header field, copy the Resource-Priority header field to the SIP re-INVITE request or the SIP UPDATE request; or

ii) otherwise, if a confirmed dialog or an early dialog on the Source Access Leg previously contained an authorised Resource-Priority header field, the SCC AS shall populate the SIP re-INVITE request or the SIP UPDATE request with the authorised Resource-Priority header field.

If the Remote Leg is a confirmed dialog, then upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, the SCC AS shall:

1) send a SIP 200 (OK) response to the initial SIP INVITE request due to STI containing:

A) a SDP answer constructed from the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request;

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

C) the backwards indication (see 3GPP TS 24.229 [2]), if priority is supported and the SIP 200 (OK) contained a backwards indication;

2) consider the confirmed dialog on the Source Access Leg as being successfully transferred to the Target Access Leg; and

3) if the SIP INVITE request due to STI contains:

– a Replaces header field, send a SIP BYE request on the Source Access Leg to terminate the dialog on the Source Access Leg, if the dialog is still active (e.g. it has not been previously released by the SC UE); or

– a Target Dialog header field and SDP of the SIP INVITE request due to STI contains:

a) no media line whose port is set to zero, send a SIP BYE request on the Source Access Leg to terminate the dialog on the Source Access Leg if the dialog is still active (e.g. it has not been previously released by the SC UE); or

b) any media line whose port is not zero, receive the SIP BYE request or SIP re-INVITE request from the Source Access Leg in the case of removing media during full transfer or partial access transfer, respectively.

When the SCC AS receives the SIP BYE request on the Source Access Leg, the SCC AS shall:

– if any media are still remaining on the Source Access Leg,

a) send SIP 200 (OK) response for the SIP BYE request; and

b) send SIP re-INVITE request to the remote UE to delete the media on the Source Access Leg by following the rules of 3GPP TS 24.229 [2]; and

– if there are no media on the Source Access Leg, send the SIP 200 (OK) respones for the SIP BYE request.

If the SCC AS receives the SIP 200 (OK) response about the SIP re-INVITE request to the remote UE (created by SIP BYE request), the SCC AS sends a SIP ACK request to acknowledge the received SIP 200 (OK) response.

When the SCC AS receives the SIP re-INVITE request on the Source Access Leg, the SCC AS shall send a SIP 200 (OK) response on the Source Access Leg to acknowledge the receipt of the SIP re-INVITE request.

If the Remote Leg is a confirmed dialog, and if subsequent to sending the SIP re-INVITE request to the remote UE and prior to sending any final SIP response on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request, the SCC AS shall release the Target Access Leg (e.g. by sending a SIP 4xx response), retain the Source Access Leg, and update the Remote Leg to match the Source Access Leg.

If the Remote Leg is an early dialog then upon receiving the SIP 2xx response to the SIP UPDATE request, the SCC AS shall send SIP 183 (Session Progress) response to the SIP INVITE request due to STI. The SCC AS shall populate the SIP 183 (Session Progress) response as follows:

a) include a SDP answer constructed from the SDP answer received in the SIP 2xx response to the SIP UPDATE request;

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

c) if the Remote Leg is an early dialog originated by the SC UE, if the SIP INVITE request due to STI contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE request, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP UPDATE request; and

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

If the dialog on the Source Access Leg is an early dialog, then upon receiving the SIP PRACK request for the SIP 183 (Session Progress) response and responding with a SIP 200 (OK) response, the SCC AS shall consider the early dialog on the Source Access Leg as being successfully transferred to the Target Access Leg and being at the same early dialog stage as the early dialog on the Source Access Leg.

NOTE 1: All subsequent SIP requests or SIP responses originating from the remote UE and destined for the SC UE will be sent to the SC UE over the Target Access Leg. If the SCC AS receives any SIP request on the Source Access Leg, the SCC AS will not convey the received SIP request to the remote UE.

If, upon sending the SIP 200 (OK) response for the SIP PRACK request, the SCC AS receives a SIP UPDATE request on the Source Access Leg that contains an SDP offer that indicates that the SC UE is releasing the resources for media on the Source Access Leg, the SCC AS will respond with a SIP 200 (OK) response containing the appropriate SDP answer, as specified in 3GPP TS 24.229 [2]. However, in spite of the resources being released, the dialog on the Source Access Leg is still active and in the early dialog phase.

If the Remote Leg is an early dialog originated by the remote UE, then upon sending the SIP 200 (OK) response for the SIP PRACK request, and when the SCC AS:

1) receives the SIP INFO request on the Target Access Leg(indicating that the SC UE has accepted the call) containing:

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

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

the SCC AS shall:

a) send a SIP 200 (OK) response on the Target Access Leg to acknowledge the receipt of the SIP INFO request;

b) send SIP 200 (OK) response to the initial SIP INVITE request to the remote UE;

c) upon sending the SIP 200 (OK) response to the SIP INFO request, send another SIP 200 (OK) response on the Target Access Leg that pertains to the SIP INVITE request due to STI received on the Target Access Leg. The SCC AS shall populate the SIP 200 (OK) response to the SIP INVITE request due to STI with signalling elements described in subclause 6A.4.3;

d) terminate the early dialog on the Source Access Leg, if still active (i.e. if not previously terminated by the SC UE) by sending a SIP CANCEL request on the Source Access Leg; and

NOTE 2: The SCC AS may delay the termination of the early dialog on the Source Access Leg to let the SC UE terminate this early dialog.

e) consider the early dialog becoming a confirmed dialog and successfully transferred to the Target Access Leg; or

2) receives both:

NOTE 3: If the SC UE wants to reject the incoming call, upon initiating the transfer of the early dialog to the Target Access Leg, the SC UE will terminate both early dialogs, i.e. the early dialog on the Target Access Leg and the early dialog on the Source Access Leg.

a) a SIP CANCEL request on the Target Access Leg cancelling the SIP INVITE request due to STI; and

b) a SIP 410 (Gone) response to the initial SIP INVITE request sent on the Source Access Leg;

the SCC AS shall:

a) respond to the SIP CANCEL request as specified in 3GPP TS 24.229 [2];

b) respond to the SIP 410 (Gone) response as specified in 3GPP TS 24.229 [2];

c) send the appropriate SIP 4xx response to the initial SIP INVITE request received from the remote UE that indicates to the remote UE that the call has been rejected; and

d) consider the early dialogs as terminated; or

3) receives:

NOTE 4: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, it will terminate the early dialog on the Target Access Leg, re-acquire the resources for media on the Source Access Leg, and accept the incoming call on the Source Access Leg.

a) a SIP CANCEL request on the Target Access Leg cancelling the SIP INVITE request due to STI; and

b) a SIP UPDATE request containing a SDP offer on the Source Access Leg, that indicates that the SC UE has re-acquired the resources for media on the Source Access Leg, if previously released;

NOTE 5: If the resources for media on the Source Access Leg have not been previously released, the SCC AS will not receive the SIP UPDATE request containing a SDP offer.

the SCC AS shall:

a) respond to the SIP CANCEL request as specified in 3GPP TS 24.229 [2];

b) if a SIP UPDATE request containing a SDP offer on the Source Access Leg was received:

A) send a SIP UPDATE request to the remote UE containing a SDP offer constructed from the SDP offer included in the SIP UPDATE request received on the Source Access Leg; and

B) when the SIP 2xx response to the SIP UPDATE request containing the SDP answer is received from the remote UE, send a SIP 200 (OK) response to the SIP UPDATE request received on the Source Access Leg that includes a SDP answer constructed from the SDP answer received in the SIP 2xx response to the SIP UPDATE request received from the remote UE; and

c) consider the early dialog as being transferred back to the Source Access Leg.

If the Remote Leg is an early dialog terminated at the remote UE, then upon sending the SIP 200 (OK) response for the SIP PRACK request, if the SCC AS:

1) receives SIP 200 (OK) response to the initial SIP INVITE request from the remote UE indicating that the remote UE has answered the call;

the SCC AS shall:

a) send a SIP 200 (OK) response toward the SC UE on the Target Access Leg that pertains to the SIP INVITE request due to STI. The SCC AS shall populate the SIP 200 (OK) response to the SIP INVITE request due to STI with signalling elements described in subclause 6A.4.3;

b) terminate the early dialog on the Source Access Leg, if still active (i.e. if not previously terminated by the SC UE) by sending the SIP 410 (Gone); and

c) consider the early dialog becoming a confirmed dialog and as successfully transferred to the Target Access Leg;

2) receives any final response (e.g. SIP 4xx response or SIP 5xx response) from the remote UE that indicates that the remote UE has rejected the call, the SCC AS shall:

NOTE 6: If the remote UE rejects the call, the SCC AS will terminate the early dialog on Source Access Leg prior to terminating the early dialog on the Target Access Leg. This will insure that the SC UE does not un-necessarily transfer the call to the Source Access Leg (e.g. re-acquires the resources) prior to the early dialog on the Source Access Leg being terminated.

a) send the SIP 410 (Gone) response to the initial SIP INVITE request received on the Source Access Leg;

b) then send a final response to the SIP INVITE request due to STI that is identical to the final response (e.g. SIP 4xx response or SIP 5xx response) received from the remote UE; and

c) consider the early dialogs as terminated; or

3) receives:

NOTE 7: If the SC UE transfers back the early dialog from the Target Access Leg to the Source Access Leg, before the SC UE receives any final response on the Target Access Leg, the SC UE will terminate the early dialog on the Target Access Leg,, re-acquire the resources for media on the Source Access Leg, and update the early dialog on the Source Access Leg.

a) a SIP CANCEL request on the Target Access Leg cancelling the SIP INVITE request due to STI; and

b) a SIP UPDATE request containing a SDP offer on the Source Access Leg, that indicates that the SC UE has re-acquired the resources for media on the Source Access Leg, if previously released;

NOTE 8: If the resources for media on the Source Access Leg have not been previously released, the SCC AS will not receive an SIP UPDATE request containing a SDP offer.

then the SCC AS shall:

a) respond to the SIP CANCEL request as specified in 3GPP TS 24.229 [2];

b) if a SIP UPDATE request containing a SDP offer on the Source Access Leg was received:

A) send a SIP UPDATE request to the remote UE containing a SDP offer constructed from the SDP offer included in the SIP UPDATE request received on the Source Access Leg; and

c) consider the early dialog as being transferred back to the Source Access Leg.

If the Remote Leg is an early dialog, and if subsequent to sending the SIP UPDATE request to the remote UE, and prior to sending any final SIP response on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request, the SCC AS shall release the Target Access Leg (e.g. by sending a SIP 4xx response), retain the Source Access Leg, and update the remote leg to match the Source Access Leg.

10.3.3 Void

10.3.4 S-CSCF releasing the source access leg during PS to PS access transfer

When SCC AS receives a SIP BYE request on an existing dialog on the Source Access Leg with the status code 480 (Temporarily Unavailable) in a Reason header field indicating that this dialog was released by the S-CSCF, the SCC AS shall delay the release of the dialog toward the the remote UE and retaining the information pertaining to the dialog on the Source Access Leg for a specific time interval. If the SCC AS:

a) receives within this time interval an initial INVITE request (i.e. on the Targer Access Leg) indicating that this dialog is replacing the dialog on the Source Access Leg, then the SCC AS shall not initiate the release of the dialog toward the the remote UE; or

NOTE 1: By retaining the information pertaining to the dialog on the Source Access Leg, and upon receiving an initial SIP INVITE request (i.e. on the Targer Access Leg), the SCC AS will be able to identify the dialog on the Source Access Leg and the associated dialog toward the the remote UE.

b) does not receive within this time interval an initial SIP INVITE request (i.e. on the Target Access Leg) indicating that this dialog is replacing the dialog on the Source Access Leg, then the SCC AS shall initiate the release of the dialog toward the the remote UE and delete the information pertaining to the dialog on the Source Access Leg.

NOTE 2: The time interval is defined by the operator policy. The value of 8 seconds is an appropriate value for the time interval.

NOTE 3: When the UE, prior to sending the initial SIP INVITE request on the Target Access Leg, registers new contact address and either uses the multiple registrations where new flow on the Target Access Leg replaces an old flow on the Source Access Leg or does not uses the multiple registrations, the S-CSCF will terminate all dialogs associated with the old constant address or old flow, as specified in 24.229. By retaining the information pertaining to the dialog on the Source Access Leg, the SCC AS knows which dialog is being replaced.

10.3.5 P-CSCF releasing the source access leg during PS to PS access transfer

The procedures specified in subclause 12.3.3.2 apply.

10.3.6 P-CSCF releasing early dialog during PS to PS access transfer

When the SCC AS that supports PS to PS access transfer for early dialogs, receives either:

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

2) a SIP CANCEL request on the Source Access Leg, with the Reason header field containing a SIP 503 (Service Unavailable) response code, that is releasing 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 releasing an early dialog on the Source Access Leg terminating at the SC UE;

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

the SCC AS shall delay the release of the associated early dialog toward the the remote UE on the Remote Leg and retaining the information pertaining to the early dialog on the Source Access Leg for a specific time interval. Subsequently, if the SCC AS:

– receives within this time interval an initial SIP INVITE request on the Target Access Leg associated with the early dialog on the Source Access Leg, then the SCC AS shall not initiate the release of the early dialog toward the the remote UE on the Remote Leg; or

– does not receive within this time interval an initial SIP INVITE request on the Target Access Leg associated with the early dialog on the Source Access Leg, then the SCC AS shall initiate the release of the early dialog toward the the remote UE on the Remote Leg and delete the information pertaining to the early dialog on the Source Access Leg.

NOTE: The time interval is defined by the operator policy. The value of 8 seconds is an appropriate value for the time interval.