20 Roles for session replication / media replication performed by the SCC AS

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

20.1 General

The "3gpp.iut.replication" SDP attribute is used to indicate replication of a media component.

a = 3gpp.iut.replication

The replication attribute may be included either at the session level or at the media level. Inclusion of "a=3gpp.iut.replication" at the session level indicates replication of all media components included in the SDP. Inclusion of "a=3gpp.iut.replication" at the media level indicates replication of the specific media component that the attribute is associated with.

20.2 Session replication / media replication performed by the SCC AS – pull mode

20.2.1 SC UE

In order to replicate an existing session, the UE shall send a SIP INVITE request to the SCC AS. The SIP INVITE request shall include:

NOTE 1: Before requesting replication, the UE discovers the ongoing collaborative session with the replicated media and gets information about its media flows by subscribing to the dialog event package.

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 Accept-Contact header field containing the g.3gpp.iut-focus media feature tag with explicit and require tags;

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

4) SDP information as follows:

a) for the replicated media component(s), containing the port numbers of the UE and the "a= 3gpp. iut.replication" attribute which indicates that the replication request is sent from the controllee UE and it uses the network based solution;

b) for the media component(s) served by the UE itself, containing the port numbers of the UE; and

c) for the media component(s) not served by the UE, containing the port numbers set to zero.

Upon receiving the SIP 2xx response for the INVITE request from the SCC AS, the UE shall send a SIP ACK request to the SCC AS.

20.2.2 SCC AS serving the collaborative session

On receiving the SIP INVITE request, the SCC AS authorizes the request and sends information to the MRF to allocate the media resource for the media to be replicated. The MRF is requested to provide mixup functionality to support it.

If the SIP INVITE request has been authorized, the SCC AS shall send a SIP re-INVTE request to the controller UE to update the access leg on the controller UE for the replicated media flow with the MRF. The SIP re-INVITE request includes the SDP offer with the "a= 3gpp.iut.replication" attribute.

Upon receiving a SIP 200 (OK) response with the SDP answer from the controller UE, the SCC AS shall send a SIP ACK request to the controller UE. After that, the SCC AS shall send a SIP re-INVITE request on the dialog for the remote leg to the remote UE to update the remote leg to communicate media with the MRF.

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.

20.3 Session replication / media replication performed by the SCC AS – push mode

20.3.1 SC UE

In order to replicate an existing session to another UE, the SC UE shall send a SIP REFER request 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 Accept-Contact header field containing the g.3gpp.iut-focus media feature tag with explicit and require tags;

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

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

a) the SIP URI of the controllee UE; 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 that are not being replicated with the port number set to zero; and

– media line(s) that are to be replicated containing the "a= 3gpp.iut.replication" attribute which indicates that the replication request was sent from the controller UE and it uses the network based solution.

Upon receiving a SIP re-INVITE request from the SCC AS, the UE shall send a SIP 200 (OK) response to the SCC AS to confirm the successful media update.

Upon receiving a SIP NOTIFY request from the SCC AS, the UE shall send a SIP 200 (OK) response to the SCC AS.

20.3.2 SCC AS serving the collaborative session

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;

2) send information to the MRF to allocate the media resource for the media to be replicated; and

3) send a SIP INVITE request to the controllee UE including:

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

b) the SDP information as follows:

– the media type(s) that are to be replicated 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 the "a= 3gpp.iut.replication" attribute.

Upon receiving a SIP 200 (OK) response with the SDP answer from the controllee UE, the SCC AS shall send a SIP ACK request to the controllee UE. After that, the SCC AS shall send a SIP re-INVITE request to controller UE to update the access leg for the replicated media flow with the MRF.