11 Roles for collaborative session establishment 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

11.1 Introduction

This clause specifies the roles of controller UE, controllee UE and the SCC AS when controller UE transfers media used in an existing session to a controllee UE or adds a new media to an existing session on the controllee UE.

11.2 SC UE

11.2.1 SC UE procedures for collaborative session establishment by transferring media used in an existing session

11.2.1.1 Controller UE procedures

To establish a collaborative session by transferring one or more media components, 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 URI;

2) the Refer-To header field set 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 set as follows:

– media lines that are not being transferred with the port number set to zero;

– media line(s) that are to be transferred containing the port number for the corresponding media types received in the media line of the SDP received during the last successful SDP offer/answer exchange; and

c) if the controller UE also wishes to transfer control of the collaborative session to the 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 existing session

5) the Contact header field containing:

– the g.3gpp.iut-controller media feature tag as described in annex B; 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 be the controller of the collaborative session; and

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

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 save the media information (i.e. media type(s) and port number(s)) related to the transferred 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. When the controller UE receives a SIP re-INVITE request from the SCC AS to update the status of the transferred media component after a successful transfer, the controller UE shall follow the procedures described in 3GPP TS 24.229 [7], including in the Contact header field of the SIP 200 (OK) response the g.3gpp.iut-controller media feature tag as described in annex B.

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.

11.2.1.2 Controllee UE procedures

There are no specific procedures for the controllee UE for the collaborative session establishment by transferring media, besides the procedures described in 3GPP TS 24.229 [7].

11.2.2 SC UE procedures for collaborative session establishment with new media

11.2.2.1 Controller UE procedures

The controller UE may establish a collaborative session with a new media at anytime while it has an ongoing IMS established session according to 3GPP TS 24.229 [7] with a remote UE.

The controller UE shall add the new media by sending 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 URI;

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

a) the SIP URI of the controllee UE;

NOTE 1: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and 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 that are not being transferred with the port number set to zero;

– media line(s )that are to be added containing the media type(s) to be added and the discard port number "9"; and

NOTE 2: The discard port number "9" indicates that this port number should be ignored.

c) if the controller UE also wishes to transfer control of the collaborative session to the controller 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 existing session

5) 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 be the controller of the collaborative session; and

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

If 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.

The controller UE may also receive SIP NOTIFY requests as the results from the SIP SUBSCRIBE request to the dialog event package between itself and the SCC AS as described in clause 15. The controller UE shall save the media information (i.e. media type(s) and port number(s)) received in the body of the SIP NOTIFY requests in order to perform further inter-UE transfer operations on the controllee UE.

11.2.2.2 Controllee UE procedures

There are no specific procedures for the controllee UE for the collaborative session establishment by adding media, besides the procedures described in 3GPP TS 24.229 [7].

11.3 SCC AS

11.3.1 Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following initial SIP REFER requests to provide specific functionality relating to the call origination:

1) SIP REFER requests routed to the SCC AS containing:

a) the Inter UE Transfer SCC AS URI in the Request-URI;

b) the Target-Dialog header field with dialog identifier identifying an existing session owned by the UE sending the SIP REFER request; and

c) the Refer-To header field containing a SIP URI:

i) of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but which is within the list of UEs which can be involved within an collaborative session with the UE which originated the SIP REFER request;

ii) with the SIP URI containing the URI header field with the hname "body" containing SDP for the media lines with media types for at least all the media components of the existing session with one or more media lines not used in the existing session and indicated with the discard port value 9; and

iii) without method parameter or with method parameter set to "INVITE".

In the procedures below, such SIP REFER requests are called "SIP REFER requests for establishing new media at controllee UE".

NOTE 1: It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from the UE.

2) SIP REFER requests routed to the SCC AS containing:

a) the Inter UE Transfer SCC AS URI in the Request-URI;

b) the Target-Dialog header field with dialog identifier identifying an existing session owned by the UE sending the SIP REFER request; and

c) the Refer-To header field containing a SIP URI:

ii) with the hname "body" URI header field containing SDP for the media lines with media types for all the media components of the existing session with one or more media lines used in the existing session and listed with non zero port value; and

iii) without method parameter or with method parameter set to "INVITE".

In the procedures below, such SIP REFER requests are called "SIP REFER requests for transferring an existing media to controllee UE".

NOTE 2: It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from the UE.

If a SIP REFER request contains the Contact header field the media feature tag g.3gpp current-iut-controller set to "passive" and the SIP URI in the Refer-To header field contains the XML specified in annex D.3 containing a <controlTransfer> element containing a <targetController> element then in the procedures below, such SIP REFER requests are called "SIP REFER requests for transferring control of the collaborative session".

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction are handled conformant with 3GPP TS 24.229 [7].

11.3.2 SCC AS procedures for collaborative session establishment by transferring media

NOTE: If the controller UE is already involved in a collaborative session then the procedures in subclause 12.3.1 apply.

When the SCC AS establishes a collaborative session by transferring media as a result of receiving a SIP REFER request for transferring an existing media type to a controllee UE from the controller 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]; and

2) a SIP INVITE request to controllee UE, 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 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 in the SIP URI in the Refer-To header field of the received SIP REFER request; 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 and extended with

i) sendonly directionality; and

ii) bandwidth information with RS set to zero and RR set to zero.

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the media transfer and establishment of the collaborative session and continue the existing session with media components 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:

1) send a SIP re-INVITE request containing SDP information as follows:

a) for the transferred media component(s), set the SDP information as from the SDP answer received in the SIP 200 (OK) response from the controllee UE with the difference that the directionality is set to directionality used by the controller UE; and

b) for all other media components in the collaborative session, include the SDP information 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) send a SIP re-INVITE request to the controller UE following the procedures described in 3GPP TS 24.229 [7] to remove the media for the transferred media component.

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

Upon receipt of a 2xx response for the re-INVITE request sent to the controller UE, the SCC AS shall send a SIP re-INVITE request to the controllee UE 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, then include within the sipfrag body

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

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

11.3.3 SCC AS procedures for collaborative session establishment with new media

When SCC AS receives a SIP REFER request in a new dialog from the controller UE for establishing a collaborative session by adding new media to the controllee UE, the SCC AS shall send:

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

2) a SIP NOTIFY request containing a sipfrag "SIP 100 Trying" as described in IETF RFC 3515 [32] as updated by RFC 6665 [48] to the controller UE; and

3) a SIP INVITE request in accordance to 3GPP TS 24.229 [7] to the controllee UE. The SCC AS shall construct the SIP INVITE request as follows:

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

b) the Referred-By header field containing the values from Referred-By header field of the received SIP REFER request if authorized by SCC AS, according to the procedures of the 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) includes an SDP offer:

A) with the media type(s) from the media (m=) lines in the same order as in the hname "body" URI header field of the SIP URI in the Refer-To header field of the received SIP REFER request;

B) with port numbers of the media line(s) set to zero except the media line(s) of the new media, i.e. the media line(s):

i) which were listed in the received SDP of the SIP REFER request with the discard port number "9"; and

ii) which are not used yet in the session; and

C) for the media line(s) containing the media type(s) of the new media component(s) with additional SDP fields containing:

i) sendonly directionality;

ii) bandwidth information with RS set to zero and RR set to zero; and

iii) a c-line set to the unspecified address (0.0.0.0) if IPv4 or a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [43].

If a SIP non-2xx final response is received from the controllee UE, the SCC AS shall send a SIP NOTIFY request including the SIP final response as a sipfrag body to the controller UE and consider the inter-UE transfer operation failed. Otherwise, the SCC AS continues with the remainder of the steps described in this subclause.

Upon receiving a SIP 2xx response from the controllee UE with an SDP answer, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP offer in the SIP re-INVITE request as follows:

1) the SDP information as follows:

a) for the added media component(s), set the SDP information as from the SDP answer received in the SIP 200 (OK) response from the controllee UE with the difference that the directionality is set to sendrecv directionality; and

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

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the media transfer and establishment of the collaborative session.

If the SIP final response from the remote UE was a SIP 2xx response with the SDP answer, the SCC AS shall:

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

2) send to the controllee UE a SIP re-INVITE request containing the current port number for the media component to be added 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.

NOTE 0: 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.

NOTE 1: Any other changes such as IP address of the remote leg in case remote leg uses different IP addresses for different media components can also be updated in the SIP re-INVITE request.

Upon successful completion of the SDP offer answer exchange using SIP re-INVITE request with the controllee UE, the SCC AS shall:

1) send to the controllee UE a SIP ACK request

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE and if the received response was a SIP 200 (OK) response containing an SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) response along with the media (m=) line(s) from the SDP answer.