21 Regroup using a preconfigured group

24.2813GPPMission Critical Video (MCVideo) signalling controlProtocol specificationRelease 18TS

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

21.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 <mcvideo-regroup-uri> element of the application/vnd.3gpp.mcvideo-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.mcvideo-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 <listserv> 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 MCVideo servers and all MCVideo 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 MCVideo 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 MCVideo function. Creation and removal of a regoup is normally initiated by an MCVideo client. Removal can also be initiated by the controlling MCVideo function.

21.2 Group regroup using a preconfigured group

21.2.1 Client procedures

21.2.1.1 Requesting a group regroup using a preconfigured group

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

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

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.mcvideo" along with parameters "require" and "explicit" according to IETF RFC 3841 [20];

3) shall set the Request-URI to the public service identity identifying the originating participating MCVideo function serving the MCVideo 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 [11];

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

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

a) the <mcvideo-client-id> element set to the MCVideo client ID of the originating MCVideo client;

b) if the MCVideo 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 MCVideo 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.mcvideo-regroup+xml MIME body with:

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

b) the <mcvideo-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 MCVideo 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 [11].

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

1) should notify the MCVideo 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 MCVideo user of the failure to create the group regroup using preconfigured group.

21.2.1.2 Removing a regroup using preconfigured group

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

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

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

3) 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.mcvideo" along with parameters "require" and "explicit" according to IETF RFC 3841 [20];

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

5) 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 [11];

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

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

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

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

a) the <mcvideo-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

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

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

1) should notify the MCVideo 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 MCVideo user of the failure to remove the regroup using preconfigured group.

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

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

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

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

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

a) shall store the value of the <mcvideo-regroup-uri> element as the temporary group identity and associate that with the group identity received in the <mcvideo-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 the users that are part of that regroup and shall consider the regroup as a user regroup; and

NOTE 1: The MCVideo client can choose to display the list of users in the user regroup to the MCVideo 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 group regroup and shall consider the regroup as a group regroup;

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

4) shall consider that the MCVideo 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 MCVideo client should join the regroup when this notification of creation is received.

21.2.1.4 Receiving notification of removal of a regroup using preconfigured group

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

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

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

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

21.2.2 Participating MCVideo function procedures

21.2.2.1 General

In the procedures in this clause:

21.2.2.2 Requesting a group regroup using a preconfigured group

Upon receipt of a “SIP MESSAGE request to the originating participating MCVideo function to request creation of a group regroup using preconfigured group”, the originating participating MCVideo 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 MCVideo function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [15]. The originating participating MCVideo function shall skip the rest of the steps;

2) shall determine the MCVideo 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 MCVideo ID does not contain an <allow-regroup> element set to “true”, the originating participating MCVideo function shall reject the “SIP MESSAGE request to the originating participating MCVideo 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 group regroup” in a Warning header field as specified in clause 4.9, and shall not continue with the rest of these steps;

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

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

NOTE 2: The public service identity can identify the controlling MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

NOTE 5: How the originating participating MCVideo function determines the public service identity of the controlling MCVideo function associated with the group identity or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

NOTE 6: How the local MCVideo system routes the SIP request through an exit MCVideo 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 [11] and IETF RFC 3428 [17] 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 [20] 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 MCVideo function selected in step 4);

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

d) shall copy the contents of the application/vnd.3gpp.mcvideo-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcvideo-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 [11].

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

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

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

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 MCVideo function selected in step 1); and

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

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

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 MCVideo function:

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

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

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

21.2.2.3 Removing a regroup using preconfigured group

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

2) shall determine the MCVideo 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 MCVideo ID does not contain an <allow-regroup> element set to "true", the originating participating MCVideo 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.9, and shall skip the rest of these steps;

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

NOTE 1: The public service identity can identify the controlling MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

NOTE 4: How the originating participating MCVideo function determines the public service identity of the controlling MCVideo function associated with the group identity or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

NOTE 5: How the local MCVideo system routes the SIP request through an exit MCVideo 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 [11] and IETF RFC 3428 [17] and:

b) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCVideo 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 [11].

Upon receipt of a SIP 2xx response to the above SIP MESSAGE request, the originating participating MCVideo 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 MCVideo client according to 3GPP TS 24.229 [11].

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

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

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

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

21.2.2.4 Notification of creation of a regroup using preconfigured group

When receiving a "SIP MESSAGE request to the terminating participating MCVideo function to create a group regroup using preconfigured group", the terminating participating MCVideo 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 MCVideo function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [15]. The terminating participating MCVideo function shall skip the rest of the steps;

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

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

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

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 [20] 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 MCVideo ID;

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

e) shall copy the contents of the application/vnd.3gpp.mcvideo-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcvideo-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 [11]; and

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

4) shall store:

a) the value of the <mcvideo-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.mcvideo-regroup+xml MIME body as the identity of the preconfigured group; and

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

until the regroup is removed.

21.2.2.5 Notification of removal of a regroup using preconfigured group

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

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

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

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

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 [20] 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 MCVideo ID;

e) shall copy the contents of the application/vnd.3gpp.mcvideo-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcvideo-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 [11]; and

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

21.2.3 Controlling MCVideo function procedures

21.2.3.1 Request to create a group regroup using preconfigured group

When receiving a "SIP MESSAGE request to the controlling MCVideo function to request creation of a group regroup using preconfigured group" the controlling MCVideo 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 [15], and shall skip the rest of the steps;

2) if the controlling MCVideo function is not able to handle the regroup based on the MCVideo group indicated in the <preconfigured-group> element in an application/vnd.3gpp.mcvideo-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 [11] and skip the rest of the steps;

3) if the controlling MCVideo function determines that the proposed group ID for the regroup is already in use, shall reject the "SIP MESSAGE request to the controlling MCVideo 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.9, and shall skip the rest of the steps;

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

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

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

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

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 [20] 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 MCVideo function;

NOTE 2: The public service identity can identify the non-controlling MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

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

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

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

f) shall copy the contents of the application/vnd.3gpp.mcvideo-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcvideo-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 [11];

5) shall wait to receive SIP responses from all of the non-controlling MCVideo 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 [11] and IETF RFC 3428 [17];

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

c) shall store the value of the <mcvideo-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.mcvideo-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 [11] and IETF RFC 3428 [17];

b) for each non-controlling MCVideo 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 [11] and IETF RFC 3428 [17];

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

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

A) an <mcvideo-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 [11].

21.2.3.2 Request to remove a regroup using preconfigured group

When receiving a "SIP MESSAGE request to the controlling MCVideo function to remove a regroup using preconfigured group" the controlling MCVideo 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 MCVideo function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [15]. The controlling MCVideo function shall skip the rest of the steps;

2) if the controlling MCVideo function determines that the requested group ID for the regroup removal does not exist, shall reject the "SIP MESSAGE request to the controlling MCVideo 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.9, and shall skip the rest of the steps;

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

4) 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 MCVideo function serving that group;

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

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 [20] 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 MCVideo function;

NOTE 1: The public service identity can identify the non-controlling MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

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

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

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

vi) shall copy the contents of the application/vnd.3gpp.mcvideo-regroup+xml MIME body received in the incoming SIP MESSAGE request into an application/vnd.3gpp.mcvideo-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 [11]; and

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

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

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

NOTE 6: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

NOTE 9: How the controlling MCVideo function determines the public service identity of the terminating participating MCVideo function associated with the group identity or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

f) shall use the list of affiliated MCVideo IDs for this terminating participating MCVideo function to create and include a <users-for-regroup> element contained in the application/vnd.3gpp.mcvideo-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 [11].

21.2.3.3 Decision to remove a regroup using preconfigured group

When the controlling MCVideo function decides to remove a regroup using preconfigured group, the controlling MCVideo 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 MCVideo function serving that group;

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

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

NOTE 1: The public service identity can identify the non-controlling MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

A) an <mcvideo-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 [11]; and

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

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

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

NOTE 6: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

i) an <mcvideo-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 MCVideo IDs served by this terminating participating MCVideo function that are affiliated to the regroup; and

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

21.2.4 Non-controlling MCVideo function procedures

21.2.4.1 Notification of creation of a group regroup using preconfigured group

When receiving a "SIP MESSAGE request to a non-controlling MCVideo function to request creation of a group regroup using preconfigured group" the non-controlling MCVideo 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 [15], and shall skip the rest of the steps;

2) or each group identified in the <groups-for-regroup> element of an application/vnd.3gpp.mcvideo-regroup+xml MIME body in the incoming SIP MESSAGE request for which the MCVideo function is the non-controlling MCVideo 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.9; 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 <mcvideo-regroup-uri> element as the identity of the group regroup;

c) the value of the <preconfigured-group> element of the application/vnd.3gpp.mcvideo-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 [11] and IETF RFC 3428 [17]:

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

6) shall merge the lists of MCVideo IDs associated with each terminating participating MCVideo function such that the resulting list associated with a terminating participating MCVideo function contains the MCVideo IDs of all users served by the participating MCVideo 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 MCVideo function identified above:

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

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

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

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

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

f) shall use the list of MCVideo IDs for this terminating participating MCVideo function as generated in step 6) to create and include the <users-for-regroup> element in the application/vnd.3gpp.mcvideo-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 [11].

21.2.4.2 Notification of removal of a group regroup using preconfigured group

When receiving a "SIP MESSAGE request to the non-controlling MCVideo function to remove a group regroup using preconfigured group" the non-controlling MCVideo 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 MCVideo function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [15]. The non-controlling MCVideo function shall skip the rest of the steps;

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

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

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

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

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

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

NOTE 5: How the local MCVideo system routes the SIP request through an exit MCVideo 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 MCVideo IDs affiliated to the regroup that are served by this terminating participating MCVideo 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 [11].

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

When a non-controlling MCVideo function becomes aware of an MCVideo 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 MCVideo function:

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

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

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 [20] that were received (if any) in the SIP MESSAGE request received from the controlling MCVideo 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 MCVideo function;

NOTE 1: The public service identity can identify the terminating participating MCVideo function in the local MCVideo system or in an interconnected MCVideo system.

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

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

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

7) shall use the list of MCVideo IDs as generated in step 1) to create and include the <users-for-regroup> element in the application/vnd.3gpp.mcvideo-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 [11].

21.3 User regroup using a preconfigured group

21.3.1 Client procedures

21.3.1.1 Requesting a user regroup using a preconfigured group

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