12 Roles for media transfer within collaborative session for inter-UE transfer

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

12.1 Introduction

This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when media transfer from the controller UE to a controllee UE or from a controllee UE to another controllee UE within a collaborative session.

12.2 SC UE

12.2.1 Procedures for controller UE initiated media transfer from controller UE to controllee UE

12.2.1.1 Controller UE procedures

The SC UE procedures for media transfer from controller UE to a controllee UE is the same as the procedures described in subclause 11.2.1.1 with exception that the controller UE sets the port numbers for the media types of the media components (in the hname "body" URI header field from the SIP URI in the Refer-To header field of the SIP REFER request) which are being transferred to the controllee UE to values from the corresponding media lines received during the last successful SDP offer and answer exchange with the remote party.

12.2.1.2 Controllee UE procedures

There are no specific procedures for the controllee UE for media transfer from controller UE to controllee, besides the procedures described in 3GPP TS 24.229 [7].

12.2.2 Procedures for controller UE initiated media transfer from controllee UE to another controllee UE

12.2.2.1 Controller UE procedures

To transfer a media component within a collaborative session from one controllee UE to another controllee UE, the controller UE shall send a SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and IETF RFC 7647 [54] and include:

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

2) the Refer-To header field set as follows:

a) the SIP URI of the controllee UE to which the media m-lines are to be transferred; and

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 set as follows:

– media lines which are not served by the target controllee UE and which are not being transferred with the port numbers set to zero;

– media lines which are already served by the target controllee UE, therefore are not to be transferred containing the port numbers of the remote UE; and

– media line(s) which are to be transferred containing the port numbers of the remote UE; and

c) if the controller UE also wishes to transfer control of the collaborative session to the target controllee UE then the SIP URI additionally containing the XML body specified for the Refer-To URI in subclause 18.2.1;

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 collaborative session;

5) the Referred-By header field containing a currently registered public user identity of the user to be delivered to the controllee UE; and

6) the Contact header field containing:

– the g.3gpp.iut-controller media feature tag as described in annex C; and

– the g.3gpp current-iut-controller media feature tag as described in annex C set to "passive" if the controller UE does not wish to remain the controller of the collaborative session.

The controller UE shall handle the subsequent SIP NOTIFY requests to the SIP REFER request according to 3GPP TS 24.229 [7], IETF RFC 3515 [32] as updated by RFC 6665 [48].

The controller UE shall save the media information (i.e. media types(s) and port number(s)) related to the media component(s) received in the sipfrag body of the SIP NOTIFY requests in order to perform further inter-UE transfer operations on the controllee UE.

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx final response, the controller UE shall consider the transfer operation failed and continue the existing session with media components prior to the failed transfer attempt.

12.2.2.2 Controllee UE procedures

There are no specific procedures for the controllee UE for transferring media form one controllee UE to another controllee UE, besides the procedures described in 3GPP TS 24.229 [7].

12.3 SCC AS

12.3.1 Procedures for controller UE initiated media transfer from controller UE to controllee UE

The SCC AS procedures for media transfer from the controller UE to a controllee UE is the same as the procedures described in subclause 11.3.2 with the exception that upon receipt of a SIP REFER request from the controller UE the SCC AS sends a SIP re-INVITE request instead of a SIP INVITE request to the controllee UE. The SIP re-INVITE request is within the dialog established when establishing the collaborative session with the controllee UE.

12.3.2 Procedures for controller UE initiated media transfer from controllee UE to another controllee UE

When the SCC AS maintaining a collaborative session and transferring media as a result of receiving a SIP REFER request for transferring one ore more media components from one controllee UE to another controllee UE, 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] for the dialog on which the SIP REFER request was received; and

2) a SIP re-INVITE request to controllee UE, to which the media component(s) is to be transferred, containing the SDP information for the media component to be transferred as follows:

a) the media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in the Refer-To header field of the received SIP REFER request including the associated attributes (a) set to sendonly and the associated bandwidth information (b) with RS set to zero and RR set to zero for those media compontents which are to be transferred to the target controllee UE; and

b) for media lines which have non zero port numbers the SDP parameters from the corresponding media lines as received during the last successful SDP offer-answer exchange from the remote UE.

Upon receipt of a 2xx response for the re-INVITE request sent to the controllee UE to which the media component is to be transferred, the SCC AS shall:

1) send a SIP re-INVITE request to controllee UE, from which the media component(s) is to be transferred, containing the SDP information for the media component to be transferred as follows

a) the media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in the Refer-To header field of the received SIP REFER request including the associated attributes (a) set to sendonly and the associated bandwidth information (b) with RS set to zero and RR set to zero for those media components which are to be transferred to the target controllee UE; and

b) for media line(s) which have non zero port numbers the SDP parameters from the corresponding media lines as received during the last successful SDP offer-answer exchange from the remote UE;and

2) 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].

NOTE 1: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request.

If a 2xx response was received to the re-INVITE request sent to the controllee UE from which the media component(s) is to be transferred, the SCC AS shall send a SIP re-INVITE request to the remote UE containing an SDP body as follows:

1) for the transferred media component(s), set the SDP information as received from the SDP answer in the SIP 2xx response from the controllee UE to which the media component is to be transferred with the difference that the attributes (a) is set to directionality used by the controlee UE from which the media component was transferred;

2) for all other media components in the collaborative session, include the associated media line(s) as from the original session to the remote leg.

Upon receipt of a 2xx response for the re-INVITE request sent to the remote UE, the SCC AS shall:

1) if the transferred media component was the only media component active at the controllee UE from which the media component was transferred from, send a SIP BYE request to the controllee UE from which the media component was transferred from; or

2) if after the transfer of the media component the controllee UE from which the media was transferred from still has other media components within the collaborative session, send a SIP re-INVITE request to the controllee UE, from which the media component was transferred, following the procedures described in 3GPP TS 24.229 [7] and set the port value of the associated media type(s) for the transferred media to zero.

Upon receipt of a 2xx response for the re-INVITE request or the SIP BYE request sent to the controllee UE from which the media component was transferred the SCC AS shall send a SIP re-INVITE request to the controllee UE to which the media component was transferred following the procedures described in 3GPP TS 24.229 [7] and set the directionality (i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the transferred media component to according to the SDP answer received from the remote UE.

Upon receiving a final response to the SIP re-INVITE request which was sent towards the controllee UE to set the directionality attributes associated to the transferred media component, the SCC AS shall:

1) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE;

2) if the received response to the SIP re-INVITE is a SIP 2xx response containing an SDP answer, include within the sipfrag body

a) the Content-Type header field from the received SIP 2xx response; and

b) the SDP answer as received in the SIP 2xx response.

If any final response to a SIP re-INVITE request (apart from the SIP re-INVITE request which was sent towards the controllee UE to set the attributes (a) associated to the transferred media component to its previous status) was a 3xx or a 6xx response then the SCC AS shall consider the Inter-UE Transfer operation failed and shall send the SIP NOTIFY request to controller UE with the body populated with SIP/2.0 603 Declined.