16 Regroup using a preconfigured group

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

16.1 General

In the procedures in this clause:

1) temporary group identity in an incoming SIP MESSAGE request refers to the temporary group identity from the <mcptt-regroup-uri> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body of the incoming SIP MESSAGE request; and

2) preconfigured group identity in an incoming SIP MESSAGE request refers to the the group identity from the <preconfigured-group> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body of the incoming SIP MESSAGE request.

Regroup using a preconfigured group refers to the creation of a user/group regroup based on the configuration information associated with an existing group that is referred to as the preconfigured group. A regroup takes its entire configuration from the preconfigured group, including security keys. If the preconfigured group document contains a <list-service> element that contains a <preconfigured-group-use-only> element, that <preconfigured-group-use-only> element is not included in the configuration of the regroup.

All MCPTT servers and all MCPTT clients are configured with the preconfigured group to allow immediate use of the regroup for a call upon creation of the regroup.

A regroup using a preconfigured group is initiated by the MCPTT client referencing a preconfigured group document in the GMS. The advantage of regroup using a preconfigured group is speed of setup of the group, especially when large numbers of users (e.g., thousands) are involved. Control of the regroup using a preconfigured group is focused in the controlling MCPTT function. Creation and removal of a regoup is normally initiated by an MCPTT client. Removal can also be initiated by the controlling MCPTT function.

16.2 Group regroup using a preconfigured group

16.2.1 Client procedures

16.2.1.1 Requesting a group regroup using a preconfigured group

Upon receiving a request from an MCPTT user to establish an MCPTT group regroup using a preconfigured group, the MCPTT client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and:

1) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

2) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

3) shall set the Request-URI to the public service identity identifying the originating participating MCPTT function serving the MCPTT user;

4) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [4];

5) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Asserted-Service-Id header field according to IETF RFC 6050 [9];

6) shall contain an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with:

a) the <mcptt-client-id> element set to the MCPTT client ID of the originating MCPTT client;

b) if the MCPTT client is aware of active functional aliases, and an active functional alias is to be included in the SIP MESSAGE request, the <anyExt> element with the <functional-alias-URI> element set to the URI of the used functional alias; and

c) if the MCPTT user has requested an application priority, the <anyExt> element with the <user-requested-priority> element set to the user provided value;

7) shall contain an application/vnd.3gpp.mcptt-regroup+xml MIME body with:

a) the <regroup-action> element set to the value "create";

b) the <mcptt-regroup-uri> element set to a unique temporary group identity URI;

NOTE: How the unique temporary group identity URI is formed is an implementation decision.

c) the <preconfigured-group> element set to the group identity of the preconfigured group; and

d) the <groups-for-regroup> element set to the list of MCPTT group identities of groups that are to be included in the regroup; and

8) shall send the SIP MESSAGE request according to 3GPP TS 24.229 [4].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCPTT client:

1) should notify the MCPTT user of the successful creation of the group regroup using preconfigured group.

On receiving a SIP 4xx response, a SIP 5xx response or a SIP 6xx response to the SIP INVITE request:

1) should notify the MCPTT user of the failure to create the group regroup using preconfigured group.

16.2.1.2 Removing a regroup using preconfigured group

Upon receiving a request from an MCPTT user to remove a user or group regroup using a preconfigured group, the MCPTT client:

1) if the MCPTT client can determine that the in-progress emergency state of the regroup is set to a value of "true":

a) should notify the user, and shall not proceed with the remaining steps;

NOTE: The MCPTT user can, if authorised, cancel the emergency state of the regroup and then reattempt to remove the regroup, if so desired.

2) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]:

3) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [6];

4) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

5) shall set the Request-URI to the public service identity identifying the originating participating MCPTT function serving the MCPTT user;

6) may include a P-Preferred-Identity header field in the SIP INVITE request containing a public user identity as specified in 3GPP TS 24.229 [4];

7) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Asserted-Service-Id header field according to IETF RFC 6050 [9];

8) shall contain an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with:

a) the <mcptt-client-id> element set to the MCPTT client ID of the originating MCPTT client; and

9) shall contain an application/vnd.3gpp.mcptt-regroup+xml MIME body with:

a) the <mcptt-regroup-uri> element set to the unique temporary group identity URI representing the regroup to be removed; and

b) the <regroup-action> element set to "remove"; and

10) shall send the SIP MESSAGE request according to 3GPP TS 24.229 [4].

On receiving a SIP 2xx response to the SIP MESSAGE request, the MCPTT client:

1) should notify the MCPTT user of the successful removal of the regroup using preconfigured group.

On receiving a SIP 4xx response, a SIP 5xx response or a SIP 6xx response to the SIP INVITE request:

1) should notify the MCPTT user of the failure to remove the regroup using preconfigured group.

16.2.1.3 Receiving a notification of creation of a regroup using preconfigured group

Upon receiving a "SIP MESSAGE request to the MCPTT client to request creation of a regroup using preconfigured group", the MCPTT client:

1) should notify the MCPTT user of the creation of the regroup using preconfigured group;

2) shall send a 200 (OK) response to the MCPTT server according to 3GPP TS 24.229 [4];

3) in the application/vnd.3gpp.mcptt-regroup+xml MIME body contained in the incoming SIP MESSAGE request:

a) shall store the value of the <mcptt-regroup-uri> element as the temporary group identity and associate that with the group identity received in the <mcptt-regroup-uri> element;

b) if a <users-for-regroup> element is included in that MIME body, should store the contents of the <users-for-regroup> element as the list of users that are part of that regroup and shall consider the regroup as a user regroup; and

NOTE 1: The MCPTT client can choose to display the list of users in the user regroup to the MCPTT user.

c) if a <groups-for-regroup> element is included in that MIME body, should store the contents of the <groups-for-regroup> element as the list of groups that are part of that regroup and shall consider the regroup as a group regroup;

NOTE 2: The MCPTT client can choose to display the list of groups in the group regroup to the MCPTT user.

4) shall consider that the MCPTT Client is affiliated with the regroup;

5) should not initiate calls targeting any of the constituent groups but instead target the regroup for the duration of a group regroup; and

6) if the regroup is a chat group, the MCPTT client should join the regroup when this notification of creation is received.

16.2.1.4 Receiving notification of removal of a regroup using preconfigured group

Upon receiving a "SIP MESSAGE request to the MCPTT client to request removal of a regroup using preconfigured group", the MCPTT client:

1) should notify the MCPTT user of the removal of the regroup using preconfigured group;

2) shall send a 200 (OK) response to the MCPTT server according to 3GPP TS 24.229 [4]; and

3) shall consider that the MCPTT client is de-affiliated from the regroup.

16.2.2 Participating MCPTT function procedures

16.2.2.1 General

In the procedures in this clause:

16.2.2.2 Requesting a group regroup using a preconfigured group

Upon receipt of a "SIP MESSAGE request to the originating participating MCPTT function to request creation of a group regroup using preconfigured group", the originating participating MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The originating participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24]. The originating participating MCPTT function shall skip the rest of the steps;

2) shall determine the MCPTT ID of the user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

3) shall authorise the user. If the user profile identified by the MCPTT ID does not contain an <allow-regroup> element set to "true", the originating participating MCPTT function shall reject the "SIP MESSAGE request to the originating participating MCPTT function to request creation of a group regroup using preconfigured group" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "160 user not authorised to request creation of a regroup" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of these steps;

4) shall select a controlling MCPTT function to manage the regroup and determine the public service identity of that controlling MCPTT function;

NOTE 1: How the originating participating MCPTT function selects a controlling MCPTT function to manage the regroup is a deployment decision.

NOTE 2: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 3: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 4: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 5: How the participating MCPTT function determines the public service identity of the selected controlling MCPTT function or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 6: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

5) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and:

a) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

b) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCPTT function selected in step 4);

c) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP MESSAGE request;

d) shall copy the contents of the application/vnd.3gpp.mcptt-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-regroup+xml MIME body included in the outgoing SIP MESSAGE request; and

e) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

6) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

Upon receipt of a SIP 480 (Temporarily Unavailable) response to the above SIP MESSAGE request, the originating participating MCPTT function:

1) shall select a different controlling MCPTT function to manage the regroup and determine the public service identity of that controlling MCPTT function;

NOTE 7: How the originating participating MCPTT function whether it decides to retry is a deployment decision.

NOTE 8: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 9: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 10: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 11: How the participating MCPTT function determines the public service identity of the selected controlling MCPTT function or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 12: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

2) shall generate a SIP MESSAGE request as specified in this clause with the Request-URI of the outgoing SIP MESSAGE request set to the public service identity of the controlling MCPTT function selected in step 1); and

3) shall forward the SIP MESSAGE request according to 3GPP TS 24.229 [4].

Upon receipt of a SIP 2xx response to the above SIP MESSAGE request, the originating participating MCPTT function shall send a SIP 200 (OK) response to the MCPTT client according to 3GPP TS 24.229 [4].

Upon receipt of any SIP 4xx response other than a 480 response, or a SIP 5xx or 6xx response to the above SIP MESSAGE request, the originating participating MCPTT function:

1) shall generate a SIP response according to 3GPP TS 24.229 [4];

2) shall include Warning header field(s) that were received in the incoming SIP response; and

3) shall forward the SIP response to the MCPTT client according to 3GPP TS 24.229 [4].

16.2.2.3 Removing a regroup using preconfigured group

Upon receipt of a "SIP MESSAGE request to the originating participating MCPTT function to remove a regroup using preconfigured group" for a temporary group identity, the originating participating MCPTT function:

2) shall determine the MCPTT ID of the user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

3) shall authorise the user. If the user profile identified by the MCPTT ID does not contain an <allow-regroup> element set to "true", the originating participating MCPTT function shall reject the "SIP MESSAGE request to remove a regroup using preconfigured group" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "161 user not authorised to request removal of a regroup " in a Warning header field as specified in clause 4.4, and shall skip the rest of these steps;

4) shall determine the public service identity of the controlling MCPTT function associated with the regroup identity in the SIP MESSAGE request;

NOTE 1: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 2: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 3: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 4: How the participating MCPTT function determines the public service identity of the controlling MCPTT function associated with the regroup or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

5) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and:

b) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCPTT function determined in step 4;

e) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

6) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

Upon receipt of a SIP 2xx response to the above SIP MESSAGE request, the originating participating MCPTT function:

1) shall generate a SIP 200 (OK) response as specified in the clause 6.3.2.1.5.2;

2) shall include Warning header field(s) that were received in the incoming SIP 200 (OK) response;

3) shall include the public service identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response; and

4) shall send the SIP 200 (OK) response to the MCPTT client according to 3GPP TS 24.229 [4].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP MESSAGE request, the originating participating MCPTT function:

1) shall generate a SIP response according to 3GPP TS 24.229 [4];

2) shall include Warning header field(s) that were received in the incoming SIP response; and

3) shall forward the SIP response to the MCPTT client according to 3GPP TS 24.229 [4].

16.2.2.4 Notification of creation of a regroup using preconfigured group

When receiving a "SIP MESSAGE request to the terminating participating MCPTT function to create a group regroup using preconfigured group", the terminating participating MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The terminating participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24]. The terminating participating MCPTT function shall skip the rest of the steps;

2) shall send a SIP 200 (OK) response as specified in 3GPP TS 24.229 [4];

3) for each MCPTT ID contained in the <users-for-regroup> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body, the terminating participating MCPTT function:

a) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]:

b) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

c) shall set the Request-URI of the outgoing SIP MESSAGE request to the public user identity associated with the MCPTT ID;

d) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP MESSAGE request;

e) shall copy the contents of the application/vnd.3gpp.mcptt-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-regroup+xml MIME body included in the outgoing SIP MESSAGE request with the exception that any <users-for-regroup> elements shall not be copied;

f) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request;

g) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4]; and

h) shall consider the MCPTT ID as affiliated with the temporary group identity representing the regroup identified in the <mcptt-regroup-uri> element in the incoming SIP MESSAGE request; and

4) shall store:

a) the value of the <mcptt-regroup-uri> element as the identity of the regroup based on a preconfigured group;

b) the value of the <preconfigured-group> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body as the identity of the preconfigured group; and

c) the set of MCPTT IDs contained in the <users-for-regroup> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body as the list of the users that are members of the group regroup;

until the regroup is removed.

16.2.2.5 Notification of removal of a regroup using preconfigured group

When receiving a "SIP MESSAGE request to the terminating participating MCPTT function to remove a regroup using preconfigured group", the terminating participating MCPTT function:

2) shall generate a SIP 200 (OK) response in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and shall send the SIP 200 (OK) response as specified in 3GPP TS 24.229 [4];

3) for each served MCPTT ID affiliated with the temporary group identity in the incoming SIP MESSAGE, the terminating participating MCPTT function:

a) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]:

b) include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

c) shall set the Request-URI of the outgoing SIP MESSAGE request to the public user identity associated with the MCPTT ID;

e) shall copy the contents of the application/vnd.3gpp.mcptt-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-regroup+xml MIME body included in the outgoing SIP MESSAGE request, with the exceptions that any <users-for-regroup> or <groups-for-regroup> elements shall not be copied;

f) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request;

g) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4];and

h) shall consider the MCPTT ID as deaffiliated from the regroup.

16.2.3 Controlling MCPTT function procedures

16.2.3.1 Request to create a group regroup using preconfigured group

When receiving a "SIP MESSAGE request to the controlling MCPTT function to request creation of a group regroup using preconfigured group" the controlling MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response, may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and shall skip the rest of the steps;

2) if the controlling MCPTT function is not able to handle the regroup based on the MCPTT group indicated in the <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body:

a) shall generate a SIP 480 (Temporarily Unavailable) response to the incoming SIP MESSAGE request; and

b) shall send the SIP 480 (Temporarily Unavailable) response as specified in 3GPP TS 24.229 [4] and skip the rest of the steps;

3) if the controlling MCPTT function determines that the proposed group ID for the regroup is already in use, shall reject the "SIP MESSAGE request to the controlling MCPTT function to request creation of a group regroup using preconfigured group" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "165 group ID for regroup already in use" in a Warning header field as specified in clause 4.4, and shall skip the rest of the steps;

4) for each group identified in the <groups-for-regroup> element:

a) shall determine the controlling MCPTT function serving that group;

NOTE 1: The controlling MCPTT function serving a consitituent group assumes the role of a non-controlling MCPTT function for the regroup.

b) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

c) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

d) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the non-controlling MCPTT function;

NOTE 2: The public service identity can identify the non-controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 3: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 4: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 5: How the controlling MCPTT function determines the public service identity of the non-controlling MCPTT function associated with the constituent MCPTT group or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 6: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

e) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP MESSAGE request;

f) shall copy the contents of the application/vnd.3gpp.mcptt-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-regroup+xml MIME body included in the outgoing SIP MESSAGE request;

g) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

h) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4];

5) shall wait to receive SIP responses from all of the non-controlling MCPTT functions that were sent a SIP MESSAGE request above;

6) if all of the SIP responses received above are SIP 200 (OK) responses:

a) shall send a SIP 200 (OK) response in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

b) shall store the list of group identities contained in the <groups-for-regroup> element;

c) shall store the value of the <mcptt-regroup-uri> element as the identity of the group regroup based on a preconfigured group; and

d) shall store the value of the <preconfigured-group> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body as the identity of the preconfigured group; and

7) if at least one of the SIP responses received above is not a SIP 2xx response:

a) shall send a SIP 480 (Temporarily Unavailable) response in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

b) for each non-controlling MCPTT function that returned a SIP 200 (OK) response in step 4:

i) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

ii) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the non-controlling MCPTT function;

NOTE 7: The public service identity can identify the non-controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 8: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 9: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 10: How the controlling MCPTT function determines the public service identity of the non-controlling MCPTT function associated with the constituent MCPTT group or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 11: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

iii) shall include an application/vnd.3gpp.mcptt-regroup+xml MIME body in the outgoing SIP MESSAGE request with;

A) an <mcptt-regroup-uri> element set to the identity of the regroup; and

B) a <regroup-action> element set to "remove"; and

iv) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

16.2.3.2 Request to remove a regroup using preconfigured group

When receiving a "SIP MESSAGE request to the controlling MCPTT function to remove a regroup using preconfigured group" the controlling MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The controlling MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24]. The controlling MCPTT function shall skip the rest of the steps;

2) if the in-progress emergency state of the regroup is set to a value of "true", then:

a) shall send a SIP 403 (Forbidden) response to the received SIP MESSAGE request including warning text set to "169 user not authorised to remove regroup in an emergency state" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

NOTE 1: The MCPTT client that receives the SIP 403 (Forbidden) response is expected to notify the MCPTT user that the remove of the regroup was not accomplished because the regroup is in an emergency state. The MCPTT user can then, if authorised, cancel the emergency state of the regroup and reattempt to remove the regroup, if so desired.

3) if the controlling MCPTT function determines that the requested group ID for the regroup removal does not exist, shall reject the "SIP MESSAGE request to the controlling MCPTT function to remove a regroup using preconfigured group" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "163 the group identity indicated in the request does not exist" in a Warning header field as specified in clause 4.4, and shall skip the rest of the steps;

4) shall send a SIP 200 (OK) response in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

5) if the regroup is a group regroup based on preconfigured group, then:

a) for each constituent group belonging to the regroup:

i) shall determine the non-controlling MCPTT function serving that group;

ii) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

iii) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

iv) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the non-controlling MCPTT function;

NOTE 2: The public service identity can identify the non-controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 6: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

v) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP MESSAGE request;

vi) shall copy the contents of the application/vnd.3gpp.mcptt-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcptt-regroup+xml MIME body included in the outgoing SIP MESSAGE request;

vii) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

viii) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4]; and

6) if the regroup is a user regroup based on preconfigured group, then for each user belonging to the regroup, the controlling MCPTT function shall create a separate list of MCPTT IDs for users belonging to and affiliated with the regroup who are served by the same terminating participating MCPTT function and for each terminating participating MCPTT function;

a) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

c) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the terminating participating MCPTT function;

NOTE 7: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 8: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 9: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 10: How the controlling MCPTT function determines the public service identity of the targeted terminating participating MCPTT function or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 11: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

f) shall use the list of affiliated MCPTT IDs for this terminating participating MCPTT function to create and include a <users-for-regroup> element contained in the application/vnd.3gpp.mcptt-regroup+xml MIME body;

g) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

h) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

16.2.3.3 Decision to remove a regroup using preconfigured group

When the controlling MCPTT function decides to remove a regroup using preconfigured group, the controlling MCPTT function:

1) if the regroup is a group regroup based on preconfigured group, then:

a) for each constituent group belonging to the regroup:

i) shall determine the non-controlling MCPTT function serving that group;

ii) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

iii) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the non-controlling MCPTT function determined in step i);

NOTE 1: The public service identity can identify the non-controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 2: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 3: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 4: How the controlling MCPTT function determines the public service identity of the non-controlling MCPTT function associated with the constituent MCPTT group or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

iv) shall create an application/vnd.3gpp.mcptt-regroup+xml MIME body and include it in the outgoing SIP MESSAGE request with:

A) an <mcptt-regroup-uri> element set to the identity of the regroup;

B) a <regroup-action> element set to "remove"; and

v) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4]; and

2) if the regroup is a user regroup based on preconfigured group, then the controlling MCPTT function shall create a list of terminating participating MCPTT functions serving users belonging to and affiliated with the regroup and shall create a list of MCPTT IDs that are affiliated to the regroup and served by the same terminating partificpating MCPTT function for each of the members of the list of terminating participating MCPTT functions, and for each terminating participating MCPTT function in the list:

a) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

b) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the terminating participating MCPTT function;

NOTE 6: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 7: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 8: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 9: How the controlling MCPTT function determines the public service identity of the targeted terminating participating MCPTT function or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 10: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

c) shall create an application/vnd.3gpp.mcptt-regroup+xml MIME body and include it in the outgoing SIP MESSAGE request with:

i) an <mcptt-regroup-uri> element set to the identity of the regroup;

ii) a <regroup-action> element set to "remove"; and

iii) a <users-for-regroup> element set to the list of MCPTT IDs served by this terminating participating MCPTT function that are affiliated to the regroup; and

d) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

16.2.4 Non-controlling MCPTT function procedures

16.2.4.1 Notification of creation of a group regroup using preconfigured group

When receiving a "SIP MESSAGE request to a non-controlling MCPTT function to request creation of a group regroup using preconfigured group" the non-controlling MCPTT function:

2) or each group identified in the <groups-for-regroup> element of an application/vnd.3gpp.mcptt-regroup+xml MIME body in the incoming SIP MESSAGE request for which the MCPTT function is the non-controlling MCPTT function:

a) shall determine if the group is already regrouped, and if the group is already regrouped:

i) shall reject the SIP request with a SIP 403 (Forbidden) response including warning text set to "148 group is regrouped" in a Warning header field as specified in clause 4.4; and

ii) shall not process the remaining steps;

3) shall store:

a) the list of group identities contained in the <groups-for-regroup> element;

b) the value of the <mcptt-regroup-uri> element as the identity of the group regroup;

c) the value of the <preconfigured-group> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body as the identity of the preconfigured group; and

d) information that each of the groups identified in the <groups-for-regroup> element has been regrouped using a preconfigured group;

4) shall send a SIP 200 (OK) response in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]:

5) for each group identified in the <groups-for-regroup> element of an application/vnd.3gpp.mcptt-regroup+xml MIME body in the incoming SIP MESSAGE request for which the MCPTT function is the non-controlling MCPTT function shall create a separate list of MCPTT IDs for users belonging to and affiliated with the identified group who are served by the same terminating participating MCPTT function;

6) shall merge the lists of MCPTT IDs associated with each terminating participating MCPTT function such that the resulting list associated with a terminating participating MCPTT function contains the MCPTT IDs of all users served by the participating MCPTT function that belong to and are affiliated with any of the groups identified in the <groups-for-regroup> element; and

7) for each terminating participating MCPTT function identified above:

a) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

c) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the terminating participating MCPTT function;

NOTE 1: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 2: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 3: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 4: How the non-controlling MCPTT function determines the public service identity of the targeted terminating participating MCPTT function or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

f) shall use the list of MCPTT IDs for this terminating participating MCPTT function as generated in step 3) to create and include the <users-for-regroup> element in the application/vnd.3gpp.mcptt-regroup+xml MIME body;

g) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

h) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

16.2.4.2 Notification of removal of a group regroup using preconfigured group

When receiving a "SIP MESSAGE request to the non-controlling MCPTT function to remove a group regroup using preconfigured group" the non-controlling MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The non-controlling MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24]. The non-controlling MCPTT function shall skip the rest of the steps;

2) shall send a SIP 200 (OK) response in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33]:

3) shall identify the constituent groups belonging to the regroup identified in the <mcptt-regroup-uri> in the application/vnd.3gpp.mcptt-regroup+xml MIME body contained in the incoming SIP MESSAGE for which this MCPTT function is the non-controlling MCPTT function and shall create a list of terminating participating MCPTT functions serving MCPTT IDs belonging to the identified constituent groups and for each member of the list of terminating participating MCPTT functions in the list shall create a list of MCPTT IDs affiuliated to the regroup and served by that terminating participating MCPTT function;

4) for each terminating participating MCPTT function identified in step 3):

a) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

c) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the terminating participating MCPTT function;

NOTE 1: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

i) shall create and include a <users-for-regroup> element containing the list of MCPTT IDs affiliated to the regroup that are served by this terminating participating MCPTT function as determined in step 3); and

f) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and

g) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

16.2.4.3 Notification of additional members of a group regroup using preconfigured group

When a non-controlling MCPTT function becomes aware of an MCPTT client affiliating with a group that it controls, where that group is a constituent group of a group regroup using preconfigured group, the non-controlling MCPTT function:

1) shall create a list of MCPTT IDs for users belonging to and affiliated with the identified constituent group who are served by the same terminating participating MCPTT function as the MCPTT client affiliating with the constituent group;

2) shall generate an outgoing SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

3) shall create in the SIP MESSAGE request copies of all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the SIP MESSAGE request received from the controlling MCPTT function for the group regroup to notify creation of the group regroup using preconfigured group;

4) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the terminating participating MCPTT function;

NOTE 1: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

5) shall create an application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP MESSAGE request using the information from the application/vnd.3gpp.mcptt-info+xml MIME body originally included in the SIP MESSAGE request received from the controlling MCPTT function for the group regroup to notify creation of the group regroup using preconfigured group;

6) shall create an application/vnd.3gpp.mcptt-regroup+xml MIME body in the outgoing SIP MESSAGE request using the information from the application/vnd.3gpp.mcptt-regroup+xml MIME body originally included in the SIP MESSAGE request received from the controlling MCPTT function for the group regroup to notify creation of the group regroup using preconfigured group;

7) shall use the list of MCPTT IDs as generated in step 1) to create and include the <users-for-regroup> element in the application/vnd.3gpp.mcptt-regroup+xml MIME body;

8) shall copy the P-Asserted-Identity header field included in the received SIP MESSAGE request into the outgoing SIP MESSAGE request; and

9) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [4].

16.3 User regroup using a preconfigured group

16.3.1 Client procedures

16.3.1.1 Requesting a user regroup using a preconfigured group

Upon receiving a request from an MCPTT user to establish an MCPTT user regroup using a preconfigured group, the MCPTT client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and: