10 Roles for inter-UE transfer without establishment of collaborative session

24.3373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) inter-UE transferRelease 17Stage 3TS

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

10.1 Introduction

This clause specifies the procedures for transferring all media of an existing session from one UE to another UE of the same subscriber. Procedures are specified for the SC UE and the SCC AS.

10.1A General

A UE shall implement dependent on the desired functionality, one or more of the following:

– subclause 10.2.1.1 and subclause 10.2.2.1;

– subclause 10.2.1.2 and subclause 10.2.2.1A; or

– subclause 10.2.2.2.

10.2 SC UE

10.2.1 SC UE participating in the session to be transferred

10.2.1.1 Transferor SC UE in services defining only originating session set up in UE

In order to transfer all media of an existing session from this SC UE to another UE that shares the same user subscription, the SC UE shall send a SIP REFER request as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and IETF RFC 7647 [54], and in accordance with UE procedures specified in 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER request as follows:

1. the Request-URI set to the URI of the UE where the session is to be transferred to;

NOTE: The URI of the UE needs to be a GRUU if several UEs share the same public user identity.

2. the Refer-To header field set to the Inter UE Transfer SCC AS URI and extended with the following URI header fields:

A. if usage of SIP Replaces extension is selected:

a. the Replaces header field populated as specified in IETF RFC 3891 [35], containing the dialog identifier of the Access Leg between this UE and the SCC AS; and

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

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

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of the Access Leg between this UE and the SCC AS; and

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

C. if the session is established using an IMS communication service that requires the use of an IMS communication service identifier:

a. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS communication service identifier of the existing session; and

b. the P-Preferred-Service header field set to the IMS communication service identifier of the existing session; and

3. the Contact header field: including a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [7].

If the SC UE receives any SIP 4xx, SIP 5xx, or SIP 6xx response to the SIP REFER request or if the SC UE receives a SIP NOTIFY request containing a message/sipfrag body of any SIP 4xx, SIP 5xx or SIP 6xx response, then the inter UE transfer has not completed successfully.

10.2.1.2 Transferor SC UE in services defining terminating session set up in UE

In order to transfer all media of an existing session from this SC UE to another UE that shares the same user subscription, the SC UE shall send a SIP REFER request as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and and draft-ietf-sipcore-refer-clarifications [54], in accordance with UE procedures specified in 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER request as follows:

1. the Request-URI set to the Inter UE Transfer SCC AS URI;

2. the Refer-To header field set to the SIP URI of the UE where the session is to be transferred to and if the session is established using an IMS communication service that requires the use of an IMS communication service identifier, the SIP URI may be extended with the following URI header fields:

NOTE: The SIP URI of the UE needs to be a GRUU if several UEs share the same public user identity.

A. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS communication service identifier of the existing session; and

B. the P-Preferred-Service header field set to the IMS communication service identifier of the existing session;

3. the Accept header field containing the MIME type "message/sipfrag";

4. the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and

5. the Referred-By header field containing a currently registered public user identity of the SC UE participating in the session to be transferred.

10.2.2 SC UE not participating in the session to be transferred

10.2.2.1 Transferee SC UE in services defining only originating session set up in UE

When sending a SIP INVITE request upon SIP REFER request reception in accordance with UE procedures specified in 3GPP TS 24.229 [7] and IETF RFC 3515 [32] as updated by RFC 6665 [48] IETF RFC 7647 [54], the SC UE shall populate the SIP INVITE request with header fields which were included as URI header fields in the URI in the Refer-To header field of the received SIP REFER request.

10.2.2.1A Transferee SC UE in services defining terminating session set up in UE

There are no specific procedures for the transferee SC UE in services defining terminating session set up in UE, besides the procedures described in 3GPP TS 24.229 [7].

10.2.2.2 Inter UE transfer triggered by SC UE not participating in the session

In order to transfer all media streams of an existing session of another UE to the SC UE, the SC UE shall send a SIP INVITE request as specified in 3GPP TS 24.229 [7]. The SC UE shall populate the SIP INVITE request as follows:

1. the Request-URI set to the Inter UE Transfer SCC AS URI;

2. the Replaces header field containing the dialog identifier of the session to be transferred; and

3. the Require header field containing the option tag value "replaces".

10.3 SCC AS

10.3.1 Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following SIP requests to provide specific functionality relating to inter UE transfer:

1. SIP INVITE request routed to the SCC AS upon originating or terminating filter criteria containing the Inter UE Transfer SCC AS URI in the Request-URI and a STI belonging to the same user subscription in:

A. the Target-Dialog header field; or

B. in the Replaces header field

with at least one offered media type used in session by a UE other than the UE identified by the Contact header field value. Then in the procedures below, such a request is known as "SIP INVITE request due to inter UE transfer".

2. SIP REFER request routed to the SCC AS due to the originating filter criteria where:

A. the GRUU in the Contact header field identifies a UE of the user identified in P-Asserted-Identity header field;

B. the GRUU in the Contact header field identifies a UE of the same user subscription as the SIP URI in the Request-URI;

C. the dialog identifier in:

a. the Replaces URI header field of the URI in the Refer-To header field; or

b. the Target-Dialog URI header field of the URI in the Refer-To header field;

belongs to a session of the UE identified by the GRUU in the Contact header field; and

D. the Refer-To header field contains the Inter UE Transfer SCC AS URI either without method parameter or with method parameter set to "INVITE".

Then in the procedures below, such a request is known as "SIP REFER request due to inter UE transfer".

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 [7].

10.3.2 Inter UE transfer request authorization in services defining only originating session set up in UE

Upon receiving a SIP REFER requests due to inter UE transfer, the SCC AS shall:

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if:

A. the media streams of the session, one leg of which is identified by the dialog identifier in:

a. the Replaces URI header field of the URI in the Refer-To header field; or

b. the Target-Dialog URI header field of the URI in the Refer-To header field;

are delivered to two or more UEs of the same user subscription; or

B. at least one media stream of the session identified by the dialog identifier in:

a. the Replaces URI header field of the URI in the Refer-To header field; or

b. the Target-Dialog URI header field of the URI in the Refer-To header field

is delivered to a UE other than the UE identified by the GRUU in the Contact header field;

2. insert a Record-Route header field with SCC AS own address; and

3. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [7].

The SCC AS shall forward the SIP response to the SIP REFER request, the associated SIP NOTIFY request, and the SIP response to the NOTIFY request conformant with 3GPP TS 24.229 [7].

10.3.3 SCC AS procedures for inter UE transfer

10.3.3.1 Procedures for inter-UE transfer in services defining only originating session set up in UE

Upon receiving a SIP INVITE request due to inter UE transfer, the SCC AS shall:

1. if:

A. the SCC AS is not aware of a subscription created by a SIP REFER request with the dialog identifiers:

a. in the Replaces header field of the received SIP INVITE request and in the Replaces URI header field of the URI in the Refer-To header field of the SIP REFER request are equal; or

b. in the Target-Dialog header field of the received SIP INVITE request and in the Target-Dialog URI header field of the URI in the Refer-To header field of the SIP REFER request are equal; and

B. the SCC AS does not authorize the request on behalf of the served user participating in the session indicated in the Replaces header field;

then reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps;

2. associate the received SIP INVITE request with an ongoing SIP dialog by matching the dialog identifier in the Replaces header field or the Target-Dialog header field. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received;

3. if a dialog identifier is not included in either in the Replaces header field or in the Target-Dialog header field or if the included dialog identifier does not identify an existing ongoing dialog, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request and not processes the remaining steps;

4. identify the Source Access Leg by the dialog identifier present in the Replaces or the Target-Dialog header field of the SIP INVITE request;

5. if a media type used in the Source Access Leg session is not offered in the SDP offer of the SIP INVITE request then reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps;

6. if the SIP INVITE request contains a Replaces header field:

A. follow the procedures defined in IETF RFC 3891 [35] for replacing the Source Access Leg with the SIP request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [7]; and

7. send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows:

A. include a new SDP offer including the media characteristics as received in the SIP INVITE request, by following the rules of the 3GPP TS 24.229 [7]; and

B. set the Contact header field to the Contact header field value recieved in the SIP INVITE request.

Upon receiving the SIP ACK request originated from the SC UE, the SCC AS shall initiate release of the Source Access Leg by sending a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [7].

10.3.3.2 Procedures for inter-UE transfer in services defining terminating session set up in UE

Upon receiving a SIP REFER request in SCC AS for transferring all media of an existing session from the SC UE to another UE that shares the same user subscription, the SCC AS shall send:

1) a SIP 200 (OK) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 100 Trying" to the controller UE as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48]; and

2) a SIP INVITE request to the SIP URI of the UE where the session is to be transferred to, containing:

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request;

b) the Referred-By header field containing the values from the Referred-By header field of the received SIP REFER request according to the procedures of IETF RFC 3892 [36];

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted-Identity header field from the remote UE at the original session establishment; and

d) the SDP information containing the information as received during the last successful SDP offer/answer exchange from the remote UE.

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the inter UE transfer and continue the existing session prior to the failed transfer attempt.

If the SIP final response was a SIP 2xx response containing a SDP answer, the SCC AS shall send a SIP re-INVITE request on the dialog for the remote leg to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall send a SIP re-INVITE request including the SDP information as from the SDP answer received in the SIP 200 (OK) response;

Upon receiving a SIP 200 (OK) response on the remote leg, the SCC AS shall:

1) send a SIP ACK request to the remote UE and to the transferee UE;

2) initiate release of the orignal access leg by sending a SIP BYE towards the transferor SC UE in accordance with 3GPP TS 24.229; and

3) send, a SIP NOTIFY request containing the received final response code in the sipfrag body to the transferor UE.

10.3.3.3 Procedures for inter-UE transfer triggered by SC UE not participating in the session

The SCC AS procedures for inter UE transfer triggered by SC UE not participating in the session is the same as the procedure described in subclause 10.3.3.1.