19 Roles for media flow 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

19.1 Introduction

The following subclauses describe the procedures and call flows of media flows transfer initiated by the target UE and by a UE other than the target UE.

19.2 SC UE

19.2.1 Media flows transfer initiated by a UE not participating in the ongoing collaborative session

For requesting media transfer to the requesting UE (the target UE), the target UE sends a SIP REFER to the controller UE in the ongoing collaborative session with transferred media. The SIP REFER request includes:

NOTE 1: Before requesting media flow transfer, the target UE of media transfer discovers the ongoing collaborative session with transferred media and gets information about its media flows by subscribing to dialog event.

1) the Request-URI set to the SIP URI of the controller UE in the ongoing collaborative session with transferred media;

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

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

a) The SIP URI of the Target UE;

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target 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 being transferred with the port numbers set to zero

– Media lines which are to be transferred containing the port number of the Remote UE;

3) the Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with explicit and require tags;

4) the Accept header field containing the MIME type “message/sipfrag”;

5) the Target-Dialog header field containing the dialog parameters for the dialog of the ongoing collaborative session with the transferred media; and

NOTE 4: The dialog parameters are obtained by subscribing to dialog event package.

6) the Referred-By header field containing a currently registered public user identity of the user.

19.2.2 Media flow transfer initiated by a UE not participating in the ongoing collaborative session – media on controllee UE

The procedures of the SC UE are identical as described in subclause 19.2.1.

19.2.3 Media flows transfer initiated when no collaborative session has been established

To transfer a media component when no collaborative session has been established, the Target UE shall send a SIP REFER request to the SCC AS as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and include:

NOTE 1: Before requesting media flow transfer, the target UE of media transfer discovers the ongoing session with transferred media and gets information about its media flow by subscribing to dialog event.

1) the Request-URI set to the SIP URI of the local UE that currently holds the media for the session;

NOTE 2: The SIP URI of the local UE need to be a GRUU if multiple UEs share the same public user identity.

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

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

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target 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 being transferred with the port numbers set to zero; and

– media lines which are to be transferred containing the port numbers of the remote UE.

3) an Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with explicit and require tags;

4) an Accept header field containing the MIME type "message/sipfrag";

5) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and

NOTE 4: The dialog parameters are obtained by subscribing to the dialog event package.

6) the Referred-By header field containing a currently registered public user identity of the user.

19.2.4 Media flows transfer initiated by a controllee UE of an ongoing collaborative session

The controllee UE initiates the transfer of Media flow from the controller UE to itself by sending a SIP REFER request to the SCC AS 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 SIP URI of the local UE that currently holds the media for the session;

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

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

a) The SIP URI of the Target UE;

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target 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 being transferred with the port numbers set to zero;

– Media lines which are to be transferred containing the port number of the Remote UE.

3) The Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with explicit and require tags; and

4) The Accept header field containing the MIME type “message/sipfrag”; and

5) The Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and

NOTE 4: The dialog parameters are obtained by subscribing to the dialog event package.

6) The Referred-By header field containing a currently registered public user identity of the user.

19.2.5 Controllee UE initiated addition of media to another controllee UE

For requesting addition of media to another controllee UE, the requesting controllee UE sends a SIP REFER request to the controller UE. The SIP REFER request includes:

NOTE 1: Before requesting addition of media, the requesting controllee UE of addition of media discovers the ongoing collaborative session and gets information about its media flows by subscribing to dialog event.

1) the Request-URI set to the SIP URI of the controller UE in the ongoing collaborative session to be added media;

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

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

a) the SIP URI of the target UE;

NOTE 3: The SIP URI of Target UE needs to be a GRUU if the Target 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 added with the port numbers set to zero;

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

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

3) the Accept-Contact header field containing the g.3gpp.iut-focus media feature tag as described in annex B.3 with explicit and require tags;

4) the Accept header field containing the MIME type “message/sipfrag”;

5) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; and

NOTE 4: The dialog parameters are obtained by subscribing to the dialog event package.

6) the Referred-By header field containing a currently registered public user identity of the user.

19.2.6 Inter-UE transfer solicited by a target UE without prior information about the existing sessions

For support of inter-UE transfer solicited by a target UE without prior information about the existing sessions:

– the UE shall implement the "application/pidf+xml" content type as described in RFC 3863 [47] and the PIDF extension specified in annex C.4 of this document.

– the UE shall subscribe for presence information state changes of the other UEs that are candidate UEs for inter UE transfer (see subclause 9.1) by generating for each candidate UE, a SUBSCRIBE request in accordance with RFC 6665 [48] and RFC 3856 [49], including:

a) the Request-URI set to the SIP URI of the candidate UE.

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

b) a filter in accordance with RFC 4661 [50] and RFC 4660 [51] which selects, via the <include> element, the element <IUT-solicitation >.

– the UE shall publish its presence status by generating a PUBLISH request, acting as an Event Publication Agent (EPA) in accordance with RFC 3903 [52], with the following precisions:

a) the UE shall include the class element set to “IUT” according to RFC 4480 [53].

b) if the UE has no wish to be the target of an IUT operation, the <status> element of the PIDF XML document shall contain the <basic> element set to "open" as defined in RFC 3863 [47].

c) when the UE wants to be the target of an IUT operation, the <status> element of the PIDF XML document shall contain the <IUT-solicitation> element as defined in annex C.4 that may contain:

i) one or more <mediaType> element if the UE wants to specify one or more type of media that it wants receive as a target of media transfer.

ii) the <sessionControl> element set to the value "true" if the UE wants to take the control of the collaborative session related to the transferred media(s).

then;

i) if the UE receives multiple IUT transfer, as a target UE, it may decide to accept one or more IUT transfer; and

ii) the UE shall update its presence status by including the <status> element of the PIDF XML document with the <basic> element set to "open" as defined in RFC 3863 [47].

– when the UE receives a NOTIFY request indicating presence information change of another UE status to “IUT-solicitation” i.e. containing the <IUT-solicitation> XML element:

a) if the <IUT-solicitation> element contains one or more <mediaType> elements that indicates a media that the UE controls or no <mediaType> element is included in the <IUT-solicitation> element and the UE control one or media:

– if the < IUT-solicitation> element contains one or more <mediaType> elements that indicates one or more media that the UE controls or no <mediaType> element is included in the < IUT-solicitation>, the UE shall decide whether or not to transfer the solicited media(s). If the <IUT-solicitation> element contains the <sessionControl> element set to "true" and the UE decides to accept media transfer, the UE shall decide whether or not to transfer the corresponding collaborative session control. Then, if the UE decides to transfer one or media flow, it shall procede the relevant IUT procedures to transfer the media to the soliciting UE as described in clauses 10, 11, and 12.

19.3 SCC AS

19.3.1 Media flows transfer initiated by a UE not participating in the ongoing collaborative session

On receiving the SIP REFER request, the SCC AS requests the controller UE to authorize the pull request or the SCC AS authorizes the request on behalf of the controller UE (e.g. pre-configured).

The SCC AS performs the steps as described in subclause 12.3.1, except that the SCC AS sends:

– a SIP INVITE request to the controllee UE to which the media component(s) is to be transferred (i.e. the target UE), instead of a SIP re-INVITE request; and

– the SIP 200 (OK) response and SIP and SIP NOTIFY request to the target UE instead of the controller UE.

19.3.2 Media flow transfer initiated by a UE not participating in the ongoing collaborative session – media on controllee UE

On receiving the SIP REFER request, the SCC AS requests the controller UE to authorize the pull request or the SCC AS authorizes the request on behalf of the controller UE (e.g. pre-configured).

The SCC AS performs the steps as described in subclause 12.3.2, except that the SCC AS sends:

– a SIP INVITE request to the controllee UE to which the media component(s) is to be transferred (i.e. the target UE), instead of a SIP re-INVITE request;

– the SIP 200 (OK) response and SIP NOTIFY request to the target UE instead of the controller UE.

19.3.3 Media flows transfer initiated when no collaborative session has been established

On receiving the SIP REFER request, the SCC AS requests the local UE to authorize the pull request or the SCC AS authorizes the request on behalf of local UE (e.g. pre-configured).

The SCC AS performs the steps as described in subclause 11.3.2, except that the SIP 200 (OK) response and SIP NOTIFY request are sent to the target UE instead of the local UE.

19.3.4 Media flows transfer initiated by a controllee UE of an ongoing collaborative session

On receiving the SIP REFER request, the SCC AS requests the local UE to authorize the pull request or the SCC AS authorizes the request on behalf of the local UE (e.g. pre-configured).

The SCC AS performs the steps as described in subclause 12.3.1, except that the SIP 200 (OK) response and SIP NOTIFY request are sent the target UE instead of the local UE.

19.3.5 Controllee UE initiated addition of media to another controllee UE

On receiving the SIP REFER, the SCC AS requests the controller UE to authorize the adding media request or the SCC AS authorizes the request on behalf of the controller UE (e.g. pre-configured).

The SCC AS performs the steps as described in subclause 14.3.1, except that the SIP 200 (OK) response and SIP NOTIFY request are sent tothe UE that sent the SIP REFER request instead of the controller UE.

19.3.6 Inter-UE transfer solicited by a target UE without prior information about the existing sessions

The SCC AS shall implement the presence server functionality as specified in 3GPP TS 24.141 [46] and shall accept any subscription request from a UE to the presence information status having a filter selecting the <IUT-solicitation> element, in accordance with RFC 4661 [50] and RFC 4660 [51], of another UE that belongs to the same list of candidate UEs for inter-UE transfer (see subclause 9.1).

UE publications within the class "IUT" (according to RFC 4480 [53]) shall only be notified to UEs belonging to the same list of candidate UEs for inter-UE transfer (see subclause 9.1) and for a subscriptions containg a filter selecting the <IUT-solicitation>.