18 Roles for assignment and transfer of control of a collaborative session

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

18.1 Introduction

This clause specifies the roles of controller UE, controller capable UE and the SCC AS when a controller UE transfers control of the collaborative session to another UE. The procedures in this clause may be combined with the procedures for adding, transferring or removing media on the controllee UE as specified in subclauses 11.2, 12.2 and 14.2 in order to transfer control while adding, transferring or removing media.

18.2 SC UE

18.2.1 Controller UE

To transfer control of the collaborative session 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 include:

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

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

a) the SIP URI of the UE that is requested to become a controller of the collaborative session; and

NOTE: The SIP URI of the UE that is requested to become a controller of the collaborative session needs to be a GRUU if the UE that is requested to become a controller of the collaborative session 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 the XML specified in annex C.2 containing a <controlTransfer> element containing a <targetController> element containing the SIP URI of the UE that is requested to become a controller of the collaborative 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;

5) the Contact header field containing:

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

– the g.3gpp.current-iut-controller media feature tag as described in annex B.4 set to "passive".

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to the UE that is requested to become a controller of the collaborative session.

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests according to 3GPP TS 24.229 [7] and IETF RFC 3515 [32] as updated by RFC 6665 [48]. The controller UE shall examine the Contact header field included in the sipfrag of the SIP 200 OK response in the SIP NOTIFY of the refer events package and if that Contact header field contains the g.3gpp.current-iut-controller media feature tag set to "active" then control has been successfully transferred and the controller UE shall perform the role of a controllee UE in the collaborative session, otherwise the controller UE shall consider the control transfer operation failed and continue as the controller of the collaborative session.

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 control transfer operation failed and continue as the controller of the collaborative session.

18.2.2 Controller capable UE

When the controller capable UE receives a SIP INVITE request or a SIP re-INVITE request containing a multipart/mixed MIME body containing a SDP offer and an XML body containing a <controlTransfer> element as specified in annex C.2 the controller capable UE shall when accepting the SDP offer send a SIP 200 (OK) response according to the procedures described in 3GPP TS 24.229 [7].

NOTE 1: The controller capable UE uses the media lines in the SDP offer to identify all the media types involved in the collaborative session and their order in the SDP for the collaborative session.

If the <controlTransfer> element contains a <targetController> element containing the SIP URI of this controller capable UE the controller capable UE shall determine whether to accept control of the collaborative session.

NOTE 2: Determining whether to accept control of the collaborative session could require interaction with the user.

If the controller capable UE accepts control of the collaborative session the controller capable UE shall include the media feature tag g.3gpp.current-iut-controller set to "active" in the Contact header of the SIP 200 OK response and assume the role of controller of the collaborative session.

If the controller capable UE does not accept the SDP offer or rejects the SIP INVITE request with a 3xx, 4xx, 5xx or 6xx response, the controller capable UE shall not assume the role of controller of the collaborative session.

18.3 SCC AS

18.3.1 Procedures for transferring control of the collaborative session

When the SCC AS transfers control of a collaborative session as a result of receiving a SIP REFER request for transferring control of the collaborative session, 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 or SIP re-INVITE request to the UE identified by the SIP URI in the Refer-To header field, 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;

d) the Content-Type header field set to the MIME type "multipart/mixed"; and

e) a "multipart/mixed" MIME body containing the following MIME parts:

i) the Content-Type header field set to "application/sdp" and SDP information as follows:

I) if there are media (m=) lines in the hname "body" URI header field in the SIP URI in the Refer-To header field of the received SIP REFER request then:

– include the media type(s) from the media (m=) lines from the hname "body" URI header field in the SIP URI in the Refer-To header field of the received SIP REFER request; and

– if any media (m=) lines from the hname "body" URI header field in the SIP URI in the Refer-To header field of the received SIP REFER request are set to non zero port numbers and the corresponding media component is not already on the UE to which control is being transferred then additionally follow the procedures in subclause 11.3.2, or subclause 12.3.1, or subclause 19.3.2 for transferring media or subclause 11.3.3 for adding media based on the determination procedure in 11.3.1;

II) if there are not any media (m=) lines in the hname "body" URI header field in the SIP URI in the Refer-To header field of the received SIP REFER request then include the media lines and attributes as agreed in the last SDP offer answer exchange with the UE identified by the SIP URI in the Refer-To header field;

ii) the Content-Type header field set to "application/vnd.3gpp.iut+xml" along with the handling parameter set to optional and the XML document from the hname "body" URI header field in the SIP URI in the Refer-To header field of the received SIP REFER request.

If the SIP final response to the SIP INVITE request or SIP re-INVITE request was a non 2xx response then the SCC AS shall consider the transfer of control operation failed and abort the transfer of control of the collaborative session and continue the existing session with media components and controller UE prior to the failed transfer attempt.

Upon receiving a final response to the SIP INVITE request or SIP re-INVITE request which was sent towards the controller capable UE, the SCC AS shall:

1) send a SIP ACK request to the controller UE that sent the final response;

2) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE that sent the SIP REFER request;

3) if the received response is a SIP 2xx response containing an SDP answer, then include within the sipfrag body

a) the Contact header field from the received SIP 2xx response including the media feature tags;

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

c) the SDP answer received in the SIP 2xx response; and

4) if the Contact header field from the received SIP 2xx response contains the media feature tag g.3gpp.current-iut-controller set to "active" then consider the UE that sent the SIP 2xx response as the controller of the collaborative session.