24 Inter-UE transfer and MMTEL interactions

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

24.1 Introduction

This subclause describes the SCC AS and SC UE procedures for inter-UE transfer when execution of supplementary service as described in 3GPP TS 22.173 [2].

24.2 Originating Identification Presentation (OIP)

There are no specific procedures for the SC UE and the SCC AS for OIP besides the procedures described in 3GPP TS 24.607 [13].

24.3 Originating Identification Restriction (OIR)

There are no specific procedures for the SC UE and the SCC AS for OIR besides the procedures described in 3GPP TS 24.607 [13].

24.4 Terminating Identification Presentation (TIP)

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 3GPP TS 24.608 [14].

24.5 Terminating Identification Restriction (TIR)

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 3GPP TS 24.608 [14].

24.6 Communication Diversion (CDIV)

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 3GPP TS 24.604 [10].

24.7 Communication Hold (HOLD)

The controller UE may hold an active media component(s) on itself, by following the procedures for HOLD described in 3GPP TS 24.610 [15].

The controller UE may hold or resume an active media component(s) on a controllee UE within a collaborative session while it has an ongoing IMS session with a remote UE, by sending a SIP REFER request and including:

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

2) the Refer-To header as follows:

a) the SIP URI of the controllee UE;

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

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the media type for each of the media (m=) lines in the session shall be set as follows:

– media lines for those media components that are not terminated on the controllee UE with port number zero;

– media lines for those media components that are terminated on the controllee UE and are not to be changed with their current directionality and the current port number from the remote end; and

– media lines for those media components that are terminated on the controllee UE and:

– if those media components are to be held, set a-line to inactive or recvonly and the current port number from the remote end; or

– if those media components are to be resumed, set a-line to sendonly or sendrecv and the current port number from the remote end.

3) the Accept header field set to "message/sipfrag"; and

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of the collaborative session; and

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex B.

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according to 3GPP TS 24.229 [7].

When SCC AS receives a SIP REFER request from the controller UE to hold or resume a media component on a controllee UE, the SCC AS shall send:

1) a SIP 200 (OK) response for the SIP REFER request to the controller UE;

2) a SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and

3) send a SIP re- INVITE request to the controllee UE, containing:

a) 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]; and

b) an SDP offer as received from remote UE in the previous offer/answer exchanged and with directionality as set for the corresponding media types in the hname "body" URI header field from the SIP URI in the Refer-To header field of the SIP REFER request received from the controller.

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AS shall send:

1) a SIP NOTIFY request to the controller UE with the sipfrag body including the SIP 200 (OK) response of the SIP re-INVITE request and also include the SDP information received from the controllee UE.

2) a SIP re-INVITE request to the remote leg as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows:

– set the SDP information including the directionality as received in the SIP 200 (OK) response from the controlee UE; and

– include the SDP information for all other media components in the collaborative session as from the original session to the remote leg.

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send a SIP ACK request to the remote leg;

When a controllee UE receives a SIP re-INVITE request to hold a media component(s), it shall follow the procedures described in 3GPP TS 24.610 [15].

24.8 Communication Barring (CB)

There are no specific procedures for the SC UE and the SCC AS for CB besides the procedures described in 3GPP TS 24.611 [16].

24.9 Message Waiting Indication (MWI)

There are no specific procedures for the SC UE and the SCC AS for MWI besides the procedures described in 3GPP TS 24.606 [12].

24.10 Conference (CONF)

In a collaborative session, it shall only be possible for the controller UE to invoke the CONF service following the procedures as described in 3GPP TS 24.605 [11].

The controller UE of an existing collaborative session may be invited by the remote party or the conference AS to a conference using SIP REFER request. In this case, upon receiving a SIP REFER request from the remote party or the conference AS, the controller UE performs the same procedures as specified in subclause 24.11.2, and the SCC AS perfoms the same procedures as specified in subclause 24.11.3.

NOTE: The SIP URI in the Refer-To header field of the SIP REFER request received by the SCC AS is the conference URI, of which the SCC AS may not be aware. However, this does not affect the SCC AS procedures.

The controller UE may be invited by the conference AS to a conference using SIP INVITE request. In this case, upon receiving the SIP INVITE request from the conference AS, the controller UE and the SCC AS may perform the procedures as described in subclause 17.3 to establish a collaborative session with the conference AS. If there is an existing collaborative session between with the controller UE and the remote party, and the SIP INVITE request indicates the collaborative session is to be replaced by the new session, the procedures as described in subclause 17.3 can be performed with the following difference:

– instead of sending a SIP INVITE request toward the controllee UE to establish a new access leg, the SCC AS may send a SIP re-INVITE request towards the controllee UE using the existing access leg between the controllee UE and the SCC AS, to update the SDP information over the access leg which has been bound to the new collaborative session.

24.11 Explicit Communication Transfer (ECT)

24.11.1 General

In a collaborative session, it shall only be possible for the controller UE to invoke ECT service following the procedures as described in 3GPP TS 24.629 [17].

When the controller UE receives a notification that ECT has been performed successfully, the controller UE shall terminate the previous active session with the transferee UE by terminating all related media control sessions on the controllee UEs.

When the SCC AS receives an ECT transfer request from the remote end to transfer the collaborative session, the SCC AS shall deliver the request to the controller UE.

When the controller UE receives an ECT transfer request to transfer the collaborative session, if the controller UE decides not to continue using a collaborative session to communicate with the new remote party (i.e. transfer target), the controller UE shall establish a new session towards the transfer target following the procedures described in 3GPP TS 24.629 [17].

24.11.2 SC UE

As the transferor of the ECT service, only the controller UE can invoke the ECT service on behalf of the collaborative session and it shall send a SIP REFER request to the transferee as specified in TS 24.629 [25]. Upon receiving notification that ECT has been performed successfully, the controller UE shall terminate the previous active session with the transferee UE by terminating all related media control sessions on the controllee UEs.

Upon receiving a SIP REFER request within an existing collaborative session containing:

1) the Referred-By header field set to the URI of the remote party; and

2) the Refer-To header field containing the "method" URI parameter set to INVITE or not including the "method" URI parameter,

the controller UE, if decides to continue using a collaborative session to communicate with the new remote party (i.e. transfer target), may send to the SCC AS a SIP INVITE request including:

1) the Request-URI set to the URI in the Refer-To header field of the SIP REFER request; and

2) the SDP information as follows:

– for the media component(s) that are to be established in the controller UE, containing the port number(s) of the controller UE; and

– for the media component(s) that are to be established in the controllee UE, containing the "a=3gpp.iut.controllee" attribute set to the same SIP URI of controllee UE as in the original collaborative session.

The following procedures of the controller UE for establishing the collaborative session with the transfer target is the same as described in subclause 17.2.1.

24.11.3 SCC AS

Upon receiving from the remote party a SIP REFER request in the existing dialog for which a collaborative session is established in the local party, the SCC AS shall forward the SIP REFER request towards the controller UE using the procedures as specified in TS 24.229 [9].

Upon receiving a SIP INVITE request from the controller UE due to the SIP REFER request and the SIP INVITE request includes:

1) the Request-URI set to the URI in the Refer-To header field of the SIP REFER request; and

2) the SDP information as follows:

– for the media component(s) that are to be established on the controller UE containing the port number(s) of the controller UE; and

and if required by local policy, the SCC AS shall establish a new collaborative session towards the new remote party (i.e. transfer target), using the procedure as described in subclause 17.2.2 with the following difference:

NOTE 1: The SCC AS can not distinguish the SIP REFER request for ECT from the common SIP REFER request. However this does not affect the SCC AS procedures, i.e. the SCC AS can decide, based on the SIP INVITE request from the controller UE due to the SIP REFER request, to reuse the existing access leg of the controllee UE for the new collaborative session.

NOTE 2: The SCC AS can decide the duration that it keeps the information of the SIP REFER request based on, e.g. the expiration time of the SIP REFER request (the Expires header field in the REFER request) and the duration of the implicit subscription created by the SIP REFER request (“expires” header field parameter in the Subscription-State header field in the first NOTIFY sent in the subscription) as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48], so that the SIP INVITE request from controller UE can be associated with the SIP REFER request.

24.12 Advice of Charge (AOC)

When the AOC service specified in 3GPP TS 24.647 [23] is active, the SCC AS shall deliver charging information to the controller UE.

24.13 Closed User Groups (CUG)

There are no specific procedures for the SC UE and the SCC AS for CUG besides the procedures described in 3GPP TS 24.654 [24].

24.14 Three-Party (3PTY)

The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [11] and the interaction with inter-UE transfer is the same as that specified in subclause 24.2.10 for CONF service.

24.15 Flexible Alerting (FA)

There are no specific procedures for the SC UE and the SCC AS for FA besides the procedures described in 3GPP TS 24.239 [18].

24.16 Communication Waiting (CW)

There are no specific procedures for the SC UE and the SCC AS for CW besides the procedures described in 3GPP TS 24.615 [20].

24.17 Completion of Communications to Busy Subscriber (CCBS)/Completion of Communications by No Reply (CCNR)

There are no specific procedures for the SC UE and the SCC AS for CCBS/CCNR besides the procedures described in 3GPP TS 24.642 [22].

24.18 Customized Alerting Tones (CAT)

For Collaborative Sessions established concurrently with terminating IMS session setup, the CAT provided by the network (under the control of the SCC AS associated with the controller UE) to the remote party is the CAT associated with the controller UE.

24.19 Malicious Communication IDentification (MCID)

There are no specific procedures for the SC UE and the SCC AS for MCID besides the procedures described in 3GPP TS 24.616 [21].

24.20 Personal Network Management (PNM)

There are no specific procedures for the SC UE and the SCC AS for PNM besides the procedures described in 3GPP TS 24.259 [19].

24.21 Customized Ringing Signal (CRS)

For Collaborative Sessions established concurrently with terminating IMS session setup, the Customized Ringing Signal (CRS) provided to the controller UE is the CRS associated with the remote party. For Collaborative Sessions established concurrently with originating IMS session setup, the CRS provided to the remote party is the CRS associated with the controller UE.

Annex A (informative):
Example signalling flows