21 Roles for session replication / media replication performed by the remote UE

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

21.1 General

This clause specifies the SC UE and SCC AS procedures for:

– the push mode session replication / media replication performed by the remote UE; and

– the pull mode session replication / media replication performed by the remote UE.

This solution:

– assumes that the existing dialog does not need to be indicated in session replication as all sessions established towards a URI of the remote UE provide the same media, e.g. an INVITE to a URI identifying a movie at an AS will always result to playback of the same movie.

– does not require extension of remote UE as playback state is exchanged between the SC UEs.

21.2 Session replication / media replication performed by the remote UE – pull mode

21.2.1 Introduction

This clause specifies the SC UE and SCC AS procedures for the pull mode session replication / media replication performed by the remote UE.

21.2.2 SC UE

21.2.2.1 SC UE not participating in the session to be replicated

21.2.2.1.1 Triggering pull mode session replication

The SC UE shall fetch the dialog information of a UE as described in clause 15 and select an existing session for replication.

In order to replicate the session, the SC UE:

1. shall send a SIP INVITE request according to 3GPP TS 24.229 [7]. The SC UE shall populate the SIP INVITE request as follows:

A. the Request-URI is set to the remote URI (as defined in IETF RFC 3261 [30]) of the existing session; and

B. SDP offer containing the same media components as used in the existing session selected for replication.

21.2.2.1.2 Requesting playback state

In order to get playback state from another UE participating in an existing session, the SC UE shall send a SIP REFER request as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER request as follows:

1. the Request-URI set to the URI of the UE participating in the existing session;

NOTE 1: The URI of the UE needs to be a GRUU if several UEs share the same identity.

2. the Refer-To header field set to the own SIP URI extended with:

NOTE 2: The own SIP URI needs to be a GRUU if several UEs share the same identity.

A. method parameter set to "MESSAGE"; and

B. In-Reply-To URI header field set to the value of the Call-Id header field of the SIP REFER request;

3. the Target-Dialog header field set to the dialog identifier of the session whose playback state is to be provided;

NOTE 3: The dialog identifiers of sessions of other UEs can be found using dialog event package subscription.

4. the Require header field populated with the option tag value "tdialog"; and

5. application/vnd.3gpp.replication+xml MIME body containing the playback state parameters to be provided.

The SC UE receives the playback state upon receiving SIP MESSAGE request with:

1. In-Reply-To header field containing the call-id of the dialog of the subscription created by SIP REFER request; and

2. application/vnd.3gpp.replication+xml MIME body.

21.2.2.2 SC UE participating in the session to be replicated

21.2.2.2.1 Providing playback state on request of other UE

Upon receiving SIP REFER request containing:

1. the Refer-To header field containing a SIP URI with method parameter equal to "MESSAGE";

2. the Target-Dialog header field containing the dialog identifier of an existing session with playback state; and

3. application/vnd.3gpp.replication+xml MIME body containing the playback state parameters to be provided;

then the SC UE shall handle the SIP REFER request as specified in 3GPP TS 24.229 [7] and IETF RFC 3515 [32] as updated by RFC 6665 [48]. The UE shall populate the SIP MESSAGE request with

1. header fields which were included as URI header fields in the URI in the Refer-To header field of the received SIP REFER request; and

2. application/vnd.3gpp.replication+xml MIME body containing the playback state of the session identified by Target-Dialog header field as requested in the application/vnd.3gpp.replication+xml MIME body included in the REFER request.

21.2.3 SCC AS

21.2.3.1 Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following SIP requests to provide specific functionality related to session replication:

1. SIP REFER request routed to the SCC AS due to the terminating filter criteria:

A. where the Refer-To header field contains a SIP URI with method parameter set to "MESSAGE"; and

B. containing application/vnd.3gpp.replication+xml MIME body.

In the procedures below, such request is known as "SIP REFER request for providing playback state".

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner conformant with 3GPP TS 24.229 [7].

21.2.3.2 Providing playback state on request of other UE

Upon receiving a SIP REFER request for providing playback state, the SCC AS shall:

1. if not authorized, reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; and

2. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [7].

21.3 Session replication / media replication performed by the remote UE – push mode

21.3.1 Introduction

This clause specifies the SC UE and SCC AS procedures for the push mode session replication / media replication performed by the remote UE.

21.3.2 SC UE

21.3.2.1 SC UE participating in the session to be replicated

21.3.2.1.1 Triggering push mode session replication request

In order to replicate an existing session of this SC UE to other UE, the SC UE shall send a SIP REFER request as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and 3GPP TS 24.229 [7]. The SC UE shall populate the SIP REFER request as follows:

1. the Request-URI set to the URI of the UE where the session is to be replicated;

NOTE: The URI of the UE needs to be a GRUU if multiple UEs share the same identity.

2. the Refer-To header field set:

A. if the asserted remote UE identity of the existing session is known, then to the asserted remote UE identity of the existing session; and

B. if the asserted remote UE identity of the existing session is not known, then to the remote URI (as defined in IETF RFC 3261 [30]) of the existing session;

and extended with the following URI header fields:

A. if the session is established using an IMS communication service that requires the use of an IMS communication service identifier:

a. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS communication service identifier of the existing session; and

b. the P-Preferred-Service header field set to the IMS communication service identifier of the existing session; and

B. SDP body listing the media as used in the existing session selected for replication; and

3. application/vnd.3gpp.replication+xml MIME body which optionally can include the playback state.

21.3.2.2 SC UE not participating in the session to be replicated

21.3.2.2.1 Handling push mode session replication request

Upon receiving a SIP REFER request containing:

1. Refer-To header field containing a URI with method parameter equal to "INVITE" or without method parameter; and

2. application/vnd.3gpp.replication+xml MIME body,

NOTE: the application/vnd.3gpp.replication+xml MIME body can contain the playback state.

the SC UE:

1. shall handle the SIP REFER request as specified in 3GPP TS 24.229 [7] and IETF RFC 3515 [32] as updated by RFC 6665 [48].

21.3.3 SCC AS

21.3.3.1 Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following SIP requests to provide specific functionality related to session replication:

1. SIP REFER request routed to the SCC AS due to the originating filter criteria containing:

A. Refer-To header field with a SIP URI with method parameter set to "INVITE" or without method parameter; and

B. application/vnd.3gpp.replication+xml MIME body.

In the procedures below, such request is known as "SIP REFER request due to session replication".

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner conformant with 3GPP TS 24.229 [7].

21.3.3.2 Session replication from the served UE

Upon receiving a SIP REFER request due to session replication, the SCC AS shall:

1. if not authorized, reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; and

2. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [7].