9.2.1 Prearranged group call

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

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

9.2.1.1 General

9.2.1.2 MCVideo client procedures

9.2.1.2.1 On-demand prearranged group call

9.2.1.2.1.1 Client originating procedures

Upon receiving a request from an MCVideo user to establish an MCVideo prearranged group session the MCVideo client shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCVideo client:

1) should indicate to the MCVideo user that calls are not allowed on the indicated group; and

2) shall skip the remainder of this procedure.

The MCVideo client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

1) if the MCVideo user has requested the origination of an MCVideo emergency group call or is originating an MCVideo prearranged group call and the MCVideo emergency state is already set, the MCVideo client shall comply with the procedures in clause 6.2.8.1.1;

2) if the MCVideo user has requested the origination of an MCVideo imminent peril group call, the MCVideo client shall comply with the procedures in clause 6.2.8.1.9;

3) if the MCVideo user has requested the origination of a broadcast group call, the MCVideo client shall comply with the procedures in clause 6.2.8.2;

4) shall include the g.3gpp.mcvideo media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [22];

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

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-Preferred-Service header field according to IETF RFC 6050 [14] in the SIP INVITE request;

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

8) should include the "timer" option tag in the Supported header field;

9) should include the Session-Expires header field according to IETF RFC 4028 [23]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";

10) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating MCVideo function serving the MCVideo user;

NOTE 1: The MCVideo client is configured with public service identity identifying the participating MCVideo function serving the MCVideo user.

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

12) if the MCVideo emergency state is already set or the MCVideo client emergency group state for this group is set to "MVEG 2: in-progress", the MCVideo client shall include the Resource-Priority header field and comply with the procedures in clause 6.2.8.1.2;

13) if the MCVideo client imminent peril group state for this group is set to "MVIG 2: in-progress" or "MVIG 4: confirm-pending" shall include the Resource-Priority header field and comply with the procedures in clause 6.2.8.1.12;

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

a) the <session-type> element set to a value of "prearranged";

b) the <mcvideo-request-uri> element set to the group identity;

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

NOTE 2: The MCVideo client does not include the MCVideo ID of the originating MCVideo user in the body, as this will be inserted into the body of the SIP INVITE request that is sent from the originating participating MCVideo function.

d) an <anyExt> element containing:

i) if the group identity identifies a temporary group or a group regroup based on a preconfigured group, the <associated-group-id> element set to the MCVideo group ID of a constituent group the MCVideo client is member of;

ii) if the MCVideo client is aware of active functional aliases, and an active functional alias is to be included in the initial SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias; and

NOTE 3: The MCVideo client is informed about temporary groups regrouping MCVideo groups that the user is a member of as specified in 3GPP TS 24.481 [24]. The MCVideo client is informed about regroups based on a preconfigured group of MCVideo groups that the user is member of and affiliated to as specified in clause 16 of the present document.

NOTE 4: If the MCVideo user selected a TGI where there are several MCVideo groups where the MCVideo user is a member, the MCVideo client selects one of those MCVideo groups.

iii) if the MCVideo user has requested an application priority, the <user-requested-priority> element set to the user provided value;

15) shall include an SDP offer according to 3GPP TS 24.229 [11] with the clarifications given in clause 6.2.1;

16) if an implicit transmission request is required, shall indicate this as specified in clause 6.4; and

17) shall send the SIP INVITE request towards the MCVideo server according to 3GPP TS 24.229 [11].

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

1) shall interact with the user plane as specified in 3GPP TS 24.581 [5];

2) if the MCVideo emergency group call state is set to "MVEGC 2: emergency-call-requested" or "MVEGC 3: emergency-call-granted" or the MCVideo imminent peril group call state is set to "MVIGC 2: imminent-peril-call-requested" or "MVIGC 3: imminent-peril-call-granted", the MCVideo client shall perform the actions specified in clause 6.2.8.1.4; and

3) may subscribe to the conference event package as specified in clause 9.1.3.1.

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

1) if the MCVideo emergency group call state is set to "MVEGC 2: emergency-call-requested" or "MVEGC 3: emergency-call-granted"; or

2) if the MCVideo imminent peril group call state is set to "MVIGC 2: imminent-peril-call-requested" or "MVIGC 3: imminent-peril-call-granted";

the MCVideo client shall perform the actions specified in clause 6.2.8.1.5.

On receiving a SIP INFO request where the Request-URI contains an MCVideo session ID identifying an ongoing group session, the MCVideo client shall follow the actions specified in clause 6.2.8.1.13.

9.2.1.2.1.2 Client terminating procedures

In the procedures in this clause:

1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

2) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

Upon receipt of an initial SIP INVITE request, the MCVideo client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [11] with the clarifications below.

The MCVideo client:

1) may reject the SIP INVITE request if any of the following conditions are met:

a) MCVideo client does not have enough resources to handle the call;

b) the number of the maximum simultaneous MCVideo emergency group calls supported for the specific calling functional alias as specified in the <MaxSimultaneousEmergencyGroupCalls> element within the <FunctionalAliasList> list element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) has been reached; or

c) any other reason outside the scope of this specification;

2) if the SIP INVITE request is rejected in step 1), shall respond toward participating MCVideo function either with appropriate reject code as specified in 3GPP TS 24.229 [11] and warning texts as specified in clause 4.4.2 or with SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorised to restrict the reason for failure and skip the rest of the steps of this clause;

NOTE: If the SIP INVITE request contains an emergency indication or imminent peril indication, the MCVideo client can by means beyond the scope of this specification choose to accept the request.

3) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [11];

4) if the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <emergency-ind> element set to a value of "true":

a) should display to the MCVideo user an indication that this is a SIP INVITE request for an MCVideo emergency group call and:

i) should display the MCVideo ID of the originator of the MCVideo emergency group call contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body;

ii) should display the MCVideo group identity of the group with the emergency condition contained in the <mcvideo-calling-group-id> element; and

iii) if the <alert-ind> element is set to "true", should display to the MCVideo user an indication of the MCVideo emergency alert and associated information;

b) shall set the MCVideo emergency group state to "MVEG 2: in-progress";

c) shall set the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; and

d) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-gc-capable"; otherwise

5) if the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <imminentperil-ind> element set to a value of "true":

a) should display to the MCVideo user an indication that this is a SIP INVITE request for an MCVideo imminent peril group call and:

i) should display the MCVideo ID of the originator of the MCVideo imminent peril group call contained in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

ii) should display the MCVideo group identity of the group with the imminent peril condition contained in the <mcvideo-calling-group-id> element; and

b) shall set the MCVideo imminent peril group state to "MVIG 2: in-progress";

6) may display to the MCVideo user the MCVideo ID of the inviting MCVideo user;

6A) may display to the MCVideo user the functional alias of the inviting MCVideo user;

7) shall perform the automatic commencement procedures specified in clause 6.2.3.1.2 if one of the following conditions are met:

a) SIP INVITE request contains an Answer-Mode header field with the value "Auto" and the MCVideo service setting at the invited MCVideo client for answering the call is set to automatic commencement mode; or

b) SIP INVITE request contains an Answer-Mode header field with the value "Auto" and the MCVideo service setting at the invited MCVideo client for answering the call is set to manual commencement mode, yet the invited MCVideo client allows the call to be answered with automatic commencement mode;

8) shall perform the manual commencement procedures specified in clause 6.2.3.2.2 if one of the following conditions are met:

a) SIP INVITE request contains an Answer-Mode header field with the value "Manual" and the MCVideo service setting at the invited MCVideo client for answering the call is to use manual commencement mode; or

b) SIP INVITE request contains an Answer-Mode header field with the value "Manual" and the MCVideo service setting at the invited MCVideo client for answering the call is set to automatic commencement mode, yet the invited MCVideo client allows the call to be answered with manual commencement mode; and

9) when the SIP 200 (OK) response to the SIP INVITE request is sent, may subscribe to the conference event package as specified in clause 9.1.3.1.

9.2.1.2.1.3 MCVideo upgrade to in-progress emergency or imminent peril

This clause covers both on-demand session and pre-established sessions.

Upon receiving a request from an MCVideo user to upgrade the MCVideo group session to an emergency condition or an imminent peril condition on an MCVideo prearranged group, the MCVideo client shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [11], with the clarifications given below.

1) if the MCVideo user is requesting to upgrade the MCVideo group session to an in-progress emergency group state and this is an unauthorised request for an MCVideo emergency call as determined by the procedures of clause 6.2.8.1.8, the MCVideo client:

a) should indicate to the MCVideo user that they are not authorised to upgrade the MCVideo group session to an in-progress emergency group state; and

b) shall skip the remaining steps of the current clause;

2) if the MCVideo user is requesting to upgrade the MCVideo group session to an in-progress imminent peril state and this is an unauthorised request for an MCVideo imminent peril group call as determined by the procedures of clause 6.2.8.1.8, the MCVideo client:

a) should indicate to the MCVideo user that they are not authorised to upgrade the MCVideo group session to an in-progress imminent peril group state; and

b) shall skip the remaining steps of the current clause;

3) if the MCVideo user has requested to upgrade the MCVideo group session to an MCVideo emergency call, the MCVideo client:

a) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body by following the procedures in clause 6.2.8.1.1;

b) if an indication of an MCVideo emergency alert is to be included, shall perform the procedures specified in clause 6.2.9.1 for the MCVideo emergency alert trigger; and

c) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.1.2.

4) if the MCVideo user has requested to upgrade the MCVideo group session to an MCVideo imminent peril call, the MCVideo client:

a) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body by following the procedures in clause 6.2.8.1.9; and

b) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.1.12;

5) if the SIP re-INVITE request is to be sent within an on-demand session, shall include in the SIP re-INVITE request an SDP offer according to 3GPP TS 24.229 [11] with the clarifications specified in clause 6.2.1;

6) if an implicit transmission request is required, shall indicate this as specified in clause 6.4; and

7) shall send the SIP re-INVITE request according to 3GPP TS 24.229 [11].

On receiving a SIP 2xx response to the SIP re-INVITE request the MCVideo client:

1) shall interact with the user plane as specified in 3GPP TS 24.581 [5]; and

2) shall perform the actions specified in clause 6.2.8.1.4.

On receiving a SIP INFO request where the Request-URI contains an MCVideo session ID identifying an ongoing group session, the MCVideo client shall follow the actions specified in clause 6.2.8.1.13.

On receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP re-INVITE request the MCVideo client shall perform the actions specified in clause 6.2.8.1.5.

9.2.1.2.1.4 MCVideo in-progress emergency cancel

This clause covers both on-demand session and pre-established sessions.

Upon receiving a request from an MCVideo user to cancel the in-progress emergency condition on a prearranged MCVideo group, the MCVideo client shall generate a SIP re-INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

1) if the MCVideo user is not authorised to cancel the in-progress emergency group state of the MCVideo group as determined by the procedures of clause 6.2.8.1.7, the MCVideo client:

a) should indicate to the MCVideo user that they are not authorised to cancel the in-progress emergency group state of the MCVideo group; and

b) shall skip the remaining steps of the current clause;

2) shall, if the MCVideo user is cancelling an in-progress emergency condition and optionally an MCVideo emergency alert originated by the MCVideo user, include an application/vnd.3gpp.mcvideo-info+xml MIME body populated as specified in clause 6.2.8.1.3;

3) shall, if the MCVideo user is cancelling an in-progress emergency condition and an MCVideo emergency alert originated by another MCVideo user, include an application/vnd.3gpp.mcvideo-info+xml MIME body populated as specified in clause 6.2.8.1.14;

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

a) the <session-type> element set to a value of "prearranged"; and

b) the <mcvideo-request-uri> element set to the group identity;

NOTE 1: The MCVideo ID of the originating MCVideo user is not included in the body, as this will be inserted into the body of the SIP INVITE request that is sent by the originating participating MCVideo function.

5) shall include the g.3gpp.mcvideo media feature tag in the Contact header field of the SIP re-INVITE request according to IETF RFC 3840 [22];

6) if the SIP re-INVITE request is to be sent within an on-demand session, shall include in the SIP re-INVITE request an SDP offer according to 3GPP TS 24.229 [11] with the clarifications specified in clause 6.2.1;

7) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.1.2; and

8) shall send the SIP re-INVITE request according to 3GPP TS 24.229 [11].

On receiving a SIP 2xx response to the SIP re-INVITE request, the MCVideo client:

1) shall interact with the user plane as specified in 3GPP TS 24.581 [5];

2) shall set the MCVideo emergency group state of the group to "MVEG 1: no-emergency";

3) shall set the MCVideo emergency group call state of the group to "MVEGC 1: emergency-gc-capable"; and

4) if the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending", the sent SIP re-INVITE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body and the SIP 2xx response to the SIP request for a priority group call does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149", shall set the MCVideo emergency alert state to "MVEA 1: no-alert".

On receiving a SIP INFO request where the Request-URI contains an MCVideo session ID identifying an ongoing group session, the MCVideo client shall follow the actions specified in clause 6.2.8.1.13.

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

1) shall set the MCVideo emergency group state as "MVEG 2: in-progress";

2) if the SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element set to a value of "true" and the sent SIP re-INVITE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, the MCVideo client shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated"; and

3) if the SIP 4xx response, SIP 5xx response or SIP 6xx response did not contain an application/vnd.3gpp.mcvideo-info+xml MIME body with an <alert-ind> element and did not contain an <originated-by> element, the MCVideo emergency alert (MVEA) state shall revert to its value prior to entering the current procedure.

NOTE 3: If the in-progress emergency group state cancel request is rejected, the state of the session does not change, i.e. continues with MCVideo emergency group call level priority.

9.2.1.2.1.5 MCVideo in-progress imminent peril cancel

This clause covers on-demand session.

Upon receiving a request from an MCVideo user to cancel the in-progress imminent peril condition on a prearranged MCVideo group, the MCVideo client shall generate a SIP re-INVITE request by following the procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

1) if the MCVideo user is not authorised to cancel the in-progress imminent peril group state of the MCVideo group as determined by the procedures of clause 6.2.8.1.10, the MCVideo client:

a) should indicate to the MCVideo user that they are not authorised to cancel the in-progress imminent peril group state of the MCVideo group; and

b) shall skip the remaining steps of the current clause;

2) shall include an application/vnd.3gpp.mcvideo-info+xml MIME body populated as specified in clause 6.2.8.1.11; and

3) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.1.12;

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

a) the <session-type> element set to a value of "prearranged"; and

b) the <mcvideo-request-uri> element set to the group identity;

NOTE 1: The MCVideo ID of the originating MCVideo user is not included in the body, as this will be inserted into the body of the SIP re-INVITE request that is sent by the originating participating MCVideo function.

5) shall include the g.3gpp.mcvideo media feature tag in the Contact header field of the SIP re-INVITE request according to IETF RFC 3840 [22];

7) shall send the SIP re-INVITE request according to 3GPP TS 24.229 [11].

On receiving a SIP 2xx response to the SIP re-INVITE request, the MCVideo client:

1) shall interact with the user plane as specified in 3GPP TS 24.581 [5];

2) shall set the MCVideo imminent peril group state of the group to "MVIG 1: no-imminent-peril"; and

3) shall set the MCVideo imminent peril group call state of the group to "MVIGC 1: imminent-peril-gc-capable".

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

1) if the SIP 4xx response, SIP 5xx response or SIP 6xx response:

a) contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <imminentperil-ind> element set to a value of "true"; or

b) does not contain an application/vnd.3gpp.mcvideo-info+xml MIME body with an <imminentperil-ind> element;

then the MCVideo client shall set the MCVideo imminent peril group state as "MVIG 2: in-progress".

NOTE 3: This is the case where the MCVideo client requested the cancellation of the MCVideo imminent peril in-progress state and was rejected.

9.2.1.2.1.6 MCVideo client receives SIP re-INVITE request

This clause covers both on-demand session.

Upon receipt of a SIP re-INVITE request the MCVideo client:

1) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <emergency-ind> element set to a value of "true":

a) should display to the MCVideo user the MCVideo ID of the originator of the MCVideo emergency group call and an indication that this is an MCVideo emergency group call;

b) if the <mcvideoinfo> element containing the <mcvideo-Params> element contains an <alert-ind> element set to "true", should display to the MCVideo user an indication of the MCVideo emergency alert and associated information;

c) shall set the MCVideo emergency group state to "MVEG 2: in-progress";

d) shall set the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; and

e) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-gc-capable";

2) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <imminentperil-ind> element set to a value of "true":

a) should display to the MCVideo user the MCVideo ID of the originator of the MCVideo imminent peril group call and an indication that this is an MCVideo imminent peril group call; and

b) shall set the MCVideo imminent peril group state to "MIG 2: in-progress";

3) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <emergency-ind> element set to a value of "false":

a) should display to the MCVideo user the MCVideo ID of the MCVideo user cancelling the MCVideo emergency group call;

b) if the <mcvideoinfo> element containing the <mcvideo-Params> element contains an <alert-ind> element set to "false":

i) should display to the MCVideo user an indication of the MCVideo emergency alert cancellation and the MCVideo ID of the MCVideo user cancelling the MCVideo emergency alert; and

ii) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body including an <originated-by> element:

A) should display to the MCVideo user the MCVideo ID contained in the <originated-by> element of the MCVideo user that originated the MCVideo emergency alert; and

B) if the MCVideo ID contained in the <originated-by> element is the MCVideo ID of the receiving MCVideo user shall set the MCVideo emergency alert state to "MVEA 1: no-alert";

c) shall set the MCVideo emergency group state to "MVEG 1: no-emergency"; and

d) if the MCVideo emergency group call state of the group is set to "MVEGC 3: emergency-call-granted", shall set the MCVideo emergency group call state of the group to "MVEGC 1: emergency-gc-capable";

4) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <imminentperil-ind> element set to a value of "false":

a) should display to the MCVideo user the MCVideo ID of the MCVideo user cancelling the MCVideo imminent peril group call and an indication that this is an MCVideo imminent peril group call;

b) shall set the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; and

c) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-gc-capable";

5) shall check if a Resource-Priority header field is included in the incoming SIP re-INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [11];

6) shall accept the SIP re-INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [11];

7) shall include the g.3gpp.mcvideo media feature tag in the Contact header field of the SIP 200 (OK) response;

8) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP 200 (OK) response;

9) if the SIP re-INVITE request was received within an on-demand session, shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP re-INVITE request according to 3GPP TS 24.229 [11] with the clarifications given in clause 6.2.2;

10) shall send the SIP 200 (OK) response towards the MCVideo server according to rules and procedures of 3GPP TS 24.229 [11]; and

11) shall interact with the media plane as specified in 3GPP TS 24.581 [5].

9.2.1.2.3 End group call

9.2.1.2.3.1 Client originating procedures on-demand

When an MCVideo client wants to leave the MCVideo session that has been established using on-demand session, the MCVideo client shall follow the procedures as specified in clause 6.2.4.1.

9.2.1.2.3.3 Client terminating procedures

Upon receiving a SIP BYE request for releasing the prearranged MCVideo group call, the MCVideo client shall follow the procedures as specified in clause 6.2.6.

9.2.1.2.4 Re-join procedure

9.2.1.2.4.1 On demand session establishment

Upon receiving a request from an MCVideo user to re-join an ongoing MCVideo session or triggered by coming back from out of coverage, the MCVideo client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

NOTE: How an MCVideo client is informed whether it comes back from out of coverage is out of scope of present document.

The MCVideo client shall follow the procedures specified in clause 9.2.1.2.1.1 with the clarification in step 9) of clause 9.2.1.2.1.1 that the Request-URI of the SIP INVITE request shall contain a URI of the MCVideo session identity to re-join.

9.2.1.3 Participating MCVideo function procedures

9.2.1.3.1 Originating procedures

9.2.1.3.1.1 On demand prearranged group call

In the procedures in this clause:

1) group identity in an incoming SIP INVITE request refers to the group identity from the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request;

2) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

3) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP INVITE request with a SIP 500 (Server Internal Error) response. The 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]. Otherwise, continue with the rest of the steps;

NOTE 1: if the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority call as determined by clause 6.3.2.1.8.1, the participating MCVideo function can according to local policy choose to accept the request.

2) shall determine the MCVideo ID of the calling user from public user identity in the P-Asserted-Identity header field of the SIP INVITE request, and shall authorise the calling user;

NOTE 2: The MCVideo ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.

3) if through local policy in the participating MCVideo function, the user identified by the MCVideo ID is not authorised to initiate prearranged group calls, shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "109 user not authorised to make prearranged group calls" in a Warning header field as specified in clause 4.4;

4) shall validate the media parameters and if the MCVideo codecs are not offered in the SIP INVITE request shall reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

5) shall check if the number of maximum simultaneous MCVideo group calls supported for the MCVideo user as specified in the <MaxSimultaneousCallsN6> element of the <MCVideo-group-call> element of the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) has been exceeded. If exceeded, the participating MCVideo function shall respond with a SIP 486 (Busy Here) response with the warning text set to "103 maximum simultaneous MCVideo group calls reached" in a Warning header field as specified in clause 4.4. Otherwise, continue with the rest of the steps;

NOTE 3: If the SIP INVITE request contains an emergency indication or an imminent peril indication, the participating MCVideo function can by means beyond the scope of this specification choose to allow for an exception to the limit for the maximum simultaneous MCVideo sessions supported for the MCVideo user. Alternatively, a lower priority session of the MCVideo user could be terminated to allow for the new session.

6) if the user identified by the MCVideo ID is not affiliated to the group identified in the the <mcvideo-request-uri> or in <associated-group-id> element of "SIP INVITE request for originating participating MCVideo function" as determined by clause 8.2.2.2.11 and this is an authorised request for originating a priority call as determined by clause 6.3.2.1.8.1, shall perform the actions specified in clause 8.2.2.2.12 for implicit affiliation;

7) if the actions for implicit affiliation specified in step 6) above were performed but not successful in affiliating the MCVideo user due to the MCVideo user already having N2 simultaneous affiliations (specified in the <MaxAffiliationsN2> element of the <Common> element of the corresponding MCVideo user profile), shall reject the "SIP INVITE request for originating participating MCVideo function" with a SIP 486 (Busy Here) response with the warning text set to "102 too many simultaneous affiliations" in a Warning header field as specified in clause 4.4. and skip the rest of the steps.

NOTE 4: N2 is the total number of MCVideo groups that an MCVideo user can be affiliated to simultaneously as specified in 3GPP TS 23.281 [26].

NOTE 5: if the SIP INVITE request contains an emergency indication set to a value of "true" or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority call as determined by clause 6.3.2.1.8.1, the participating MCVideo function can according to local policy choose to allow an exception to the N2 limit specified in the <MaxAffiliationsN2> element of the <Common> element of the MCVideo user profile of the served MCVideo ID. Alternatively, a lower priority affiliation of the MCVideo user could be cancelled to allow for the new affiliation.

If the incoming SIP INVITE request does not contain an <associated-group-id> element, then the group identity contained in the <mcvideo-request-uri> element is determined not to be a TGI or the identity of a group regroup based on a preconfigured group and the participating MCVideo function:

1) shall determine the public service identity of the controlling MCVideo function associated with the group identity in the SIP INVITE request;

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

NOTE 7: 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 8: 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 9: How the 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 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.

2) shall generate a SIP INVITE request as specified in clause 6.3.2.1.3;

3) shall set the Request-URI to the public service identity of the controlling MCVideo function determined in step 8);

4) shall not copy the following header fields from the incoming SIP INVITE request to the outgoing SIP INVITE request, if they were present in the incoming SIP INVITE request:

a) Answer-Mode header field as specified in IETF RFC 5373 [27]; and

b) Priv-Answer-Mode header field as specified in IETF RFC 5373 [27];

5) shall set the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request to the MCVideo ID of the calling user;

6) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the MCVideo client as specified in clause 6.3.2.1.1.1;

6a) if the received SIP request contains a <functional-alias-URI> element of the application/vnd.3gpp.mcvideo-info+xml MIME body, then check if the status of the functional alias is activated for the MCVideo ID. If the functional alias status is activated, then set the <functional-alias-URI> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP INVITE request to the received value, if the status is unequal activated then do not include a <functional-alias-URI> element;

7) if the received SIP INVITE request contains an application/vnd.3gpp.location-info+xml MIME body and if not already copied, shall copy the contents of the application/vnd.3gpp.location-info+xml MIME body received in the SIP INVITE request into an application/vnd.3gpp.location-info+xml MIME body included in the outgoing SIP request;

8) if a Resource-Priority header field was included in the received SIP INVITE request, shall include a Resource-Priority header field according to rules and procedures of 3GPP TS 24.229 [11] set to the value indicated in the Resource-Priority header field of the SIP INVITE request from the MCVideo client; and

NOTE 11: The participating MCVideo function will leave verification of the Resource-Priority header field to the controlling MCVideo function.

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

If incoming SIP INVITE request contains an <associated-group-id> element, then the group identity contained in the <mcvideo-request-uri> element is determined to be a TGI or the identity of a group regroup based on a preconfigured group and the participating MCVideo function:

1) shall generate a SIP INVITE request as specified in clause 6.3.2.1.8;

2) shall include an SDP offer based upon the SDP offer in the received SIP INVITE request from the MCVideo client as specified in clause 6.3.2.1.1.1; and

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

Upon receipt of a SIP 2xx response in response to the above SIP INVITE request, the participating MCVideo function:

1) if the received SIP 2xx response contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <MKFC-GKTPs> element, shall perform the procedures in clause 6.3.2.3.2;

2) shall generate a SIP 200 (OK) response as in clause 6.3.2.1.5.2;

3) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

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

5) 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;

6) shall include an MCVideo session identity mapped to the MCVideo session identity provided in the Contact header field of the received SIP 200 (OK) response;

7) if the procedures of clause 8.2.2.2.12 for implicit affiliation were performed in the present clause, shall complete the implicit affiliation by performing the procedures of clause 8.2.2.2.13;

8) shall send the SIP 200 (OK) response to the MCVideo client according to 3GPP TS 24.229 [11];

9) shall interact with Media Plane as specified in 3GPP TS 24.581 [5]; and

10) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [23].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request the 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;

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

4) if the implicit affiliation procedures of clause 8.2.2.2.12 were invoked in this procedure, shall perform the procedures of clause 8.2.2.2.14;

9.2.1.3.1.3 Reception of a SIP re-INVITE request from served MCVideo client

This clause covers on-demand session.

Upon receipt of a SIP re-INVITE request for an MCVideo session identifying an on-demand prearranged MCVideo group session, the 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 re-INVITE request with a SIP 500 (Server Internal Error) response. The 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] and skip the rest of the steps;

NOTE 1: If the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "true", the participating MCVideo function can choose to accept the request.

2) shall determine if the media parameters are acceptable and the MCVideo codecs are offered in the SDP offer and if not, reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

3) shall generate an outgoing SIP re-INVITE request as specified in clause 6.3.2.1.9;

4) shall, if the SIP re-INVITE request was received within an on-demand session, include in the SIP re-INVITE request an SDP offer based on the SDP offer in the received SIP re-INVITE request as specified in clause 6.3.2.1.1;

5) if the received SIP re-INVITE request contains a Resource-Priority header field, shall include a Resource-Priority header field with the contents set as in the received Resource-Priority header field; and

NOTE 3: The controlling MCVideo function will determine the validity of the Resource-Priority header field.

6) shall forward the SIP re-INVITE request according to 3GPP TS 24.229 [11].

Upon receipt of a SIP 2xx response to the above SIP re-INVITE request in step 7) the 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 in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

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

4) shall copy the contents 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;

5) shall send the SIP 200 (OK) response towards the MCVideo client according to 3GPP TS 24.229 [11]; and

6) shall interact with the media plane as specified in 3GPP TS 24.581 [5].

Upon receipt of a SIP 403 (Forbidden) response to the above SIP INVITE request in step 7) the participating MCVideo function:

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

2) shall copy, if included in the received SIP 403 (Forbidden) response, the application/vnd.3gpp.mcvideo-info+xml MIME body MIME body to the outgoing SIP (Forbidden) response;

3) shall include Warning header field(s) that were received in the incoming SIP 403 (Forbidden) response;

4) shall forward the SIP 403 (Forbidden) response to the MCVideo client according to 3GPP TS 24.229 [11]; and

5) shall interact with the media plane as specified in 3GPP TS 24.581 [5].

9.2.1.3.2 Terminating Procedures

In the procedures in this clause:

1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

2) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

NOTE 1: This clause covers on-demand session.

Upon receipt of a "SIP INVITE request for terminating participating MCVideo function", the participating MCVideo function:

NOTE 2: if the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority call as determined by clause 6.3.2.1.8.1, the participating MCVideo function can according to local policy choose to accept the request.

2) shall check the presence of the isfocus media feature tag in the URI of the Contact header field and if it is not present then the participating MCVideo function shall reject the request with a SIP 403 (Forbidden) response with the warning text set to "104 isfocus not assigned" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

3) if the Answer-Mode Indication in the application/poc-settings+xml MIME body has not yet been received from the invited MCVideo client as defined in clause 7.3.3 or clause 7.3.4, shall reject the request with a SIP 480 (Temporarily Unavailable) response with the warning text set to "146 T-PF unable to determine the service settings for the called user" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

4) shall use the MCVideo ID present in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request to retrieve the binding between the MCVideo ID and public user identity;

5) if the binding between the MCVideo ID and public user identity does not exist, then the participating MCVideo function shall reject the SIP INVITE request with a SIP 404 (Not Found) response. Otherwise, continue with the rest of the steps;

6) if the SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with an <MKFC-GKTPs> element, shall perform the procedures in clause 6.3.2.3.2;

7) shall perform the automatic commencement procedures specified in clause 6.3.2.2.5.1 and according to IETF RFC 5373 [27] if the "SIP INVITE request for terminating participating MCVideo function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as per clause 7.3.3 or clause 7.3.4 is set to "auto-answer"; and

8) shall perform the manual commencement procedures specified in clause 6.3.2.2.6.1 and according to IETF RFC 5373 [27] if the "SIP INVITE request for terminating participating MCVideo function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCVideo client as per clause 7.3.3 or clause 7.3.4 is set to "manual-answer".

9.2.1.3.3 End group call at the originating participating MCVideo function

9.2.1.3.3.1 Receipt of SIP BYE request for ending group call on-demand

Upon receiving from the MCVideo client a SIP BYE request the participating MCVideo function shall follow the procedures as specified in clause 6.3.2.1.6.

9.2.1.3.4 End group call at the terminating participating MCVideo function

9.2.1.3.4.1 Receipt of SIP BYE request for private call on-demand

Upon receiving a SIP BYE request from the controlling MCVideo function, the participating MCVideo function shall follow the procedures as specified in clause 6.3.2.2.8.1.

9.2.1.3.5 Re-join procedures

9.2.1.3.5.1 Originating procedures – on demand prearranged group call

Upon receipt of a "SIP INVITE request for originating participating MCVideo function" containing an application/vnd.3gpp.mcvideo-info+xml MIME body with the <session-type> element set to a value of "prearranged", the participating MCVideo function shall follow the procedures specified in clause 9.2.1.3.1.1 with the clarification in step 10) of clause 9.2.1.3.1.1 that the Request-URI of the SIP INVITE request shall contain a URI of the MCVideo session identity which mapped to the MCVideo session identity provided in Request-URI of the "SIP INVITE request for originating participating MCVideo function".

9.2.1.3.6 Reception of a SIP re-INVITE request for terminating MCVideo client for priority call

In the procedures in this clause:

1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

2) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

Upon receipt of a SIP re-INVITE request for a terminating MCVideo client of a MCVideo group containing an emergency indication or imminent peril indication, the participating MCVideo function:

1) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [11];

2) shall generate an outgoing SIP re-INVITE request as specified in clause 6.3.2.2.10;

3) shall include in the SIP re-INVITE request an SDP offer based on the SDP offer in the received SIP re-INVITE request as specified in clause 6.3.2.2.1; and

4) shall send the SIP re-INVITE request towards the MCVideo client according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the above SIP re-INVITE request sent to the MCVideo client, the participating MCVideo function:

1) shall generate a SIP 200 (OK) response as described in the clause 6.3.2.2.4.2;

2) shall include in the SIP 200 (OK) response an SDP answer based on the SDP answer in the received SIP 200 (OK) response as specified in clause 6.3.2.2.2.1;

3) shall interact with the media plane as specified in 3GPP TS 24.581 [5]; and

4) shall forward the SIP 200 (OK) response according to 3GPP TS 24.229 [11].

9.2.1.4 Controlling MCVideo function procedures

9.2.1.4.1 Originating Procedures

9.2.1.4.1.1 INVITE targeted to an MCVideo client

This clause describes the procedures for inviting an MCVideo user to an MCVideo session. The procedure is initiated by the controlling MCVideo function as the result of an action in clause 9.2.1.4.2 or as the result of receiving a SIP 403 (Forbidden) response as described in this clause.

The controlling MCVideo function:

1) shall generate a SIP INVITE request as specified in clause 6.3.3.1.2;

2) shall set the Request-URI to the public service identity of the terminating participating MCVideo function associated to the MCVideo user to be invited.;

NOTE 1: 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 2: 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 3: How the controlling MCVideo function determines the public service identity of the terminating participating MCVideo function associated with the MCVideo user to be invited or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

NOTE 5: If the terminating MCVideo user is part of a partner MCVideo system, then the public service identity can identify an entry point in the partner network that is able to identify the terminating participating MCVideo function.

3) shall set the P-Asserted-Identity header field to the public service identity of the controlling MCVideo function;

4) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP INVITE request:

a) the <mcvideo-request-uri> element set to the MCVideo ID of the terminating user; and

b) the <mcvideo-calling-group-id> element set to the group identity;

NOTE 6: The <mcvideo-calling-user-id> is already included in the MIME body as a result of calling clause 6.3.3.1.2 in step 1).

5) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 6.3.3.1.1;

6) if the in-progress emergency state of the group is set to a value of "true" the controlling MCVideo function:

a) shall include a Resource-Priority header field populated with the values for an MCVideo emergency group call as specified in clause 6.3.3.1.19;

b) if the received SIP INVITE request contained an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "true":

i) shall include in the outgoing SIP INVITE request in the application/vnd.3gpp.mcvideo-info+xml MIME body an <emergency-ind> element set to a value of "true"; and

ii) if the <alert-ind> element is set to "true" in the received SIP INVITE request and the requesting MCVideo user and MCVideo group are authorised for the initiation of MCVideo emergency alerts as determined by the procedures of clause 6.3.3.1.13.1, shall populate the application/vnd.3gpp.mcvideo-info+xml MIME body and the application/vnd.3gpp.location-info+xml MIME body as specified in clause 6.3.3.1.12. Otherwise, shall set the <alert-ind> element to a value of "false"; and

c) if the in-progress imminent peril state of the group is set to a value of "true" shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <imminentperil-ind> element set to a value of "false";

7) if the in-progress emergency state of the group is set to a value of "false" and the in-progress imminent peril state of the group is set to a value of "true", the controlling MCVideo function:

a) shall include a Resource-Priority header field populated with the values for an MCVideo imminent peril group call as specified in clause 6.3.3.1.19; and

b) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true";

8) if:

a) an MCVideo GKTP document exists for the group identity contained in the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request; and

b) the MCVideo GKTP document contains a <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCVideo GKTP document:

i) shall perform the procedure in clause 6.3.3.6.2 to re-generate an I_MESSAGE; and

ii) if the procedure in clause 6.3.3.6.2 was successful, shall include the I_MESSAGE in a <GKTP> element of the <MKFC-GKTPs> element of an application/vnd.3gpp.mcvideo-info+xml MIME body included in the outgoing SIP INVITE request; and

9) shall send the SIP INVITE request towards the terminating network in accordance with 3GPP TS 24.229 [11].

Upon receiving a SIP 183 (Session Progress) response containing a Require header field with the option tag "100rel" and containing a P-Answer-State header field with the value "Unconfirmed" in response to the SIP INVITE request the controlling MCVideo function:

1) shall send a SIP PRACK request towards the MCVideo client according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response for the SIP INVITE request the controlling MCVideo function:

1) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

2) shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in clause 9.2.3.4; and

3) shall increment the local counter of the number of SIP 200 (OK) responses received from invited members, by 1.

NOTE 7: The notifications above could be sent prior to the SIP 200 (OK) response being sent to the inviting MCVideo client. These notifications received by MCVideo clients that are group members do not mean that the group session will be successfully established.

NOTE 8: The procedures executed by the controlling MCVideo function prior to sending a response to the inviting MCVideo client are specified in clause 9.2.1.4.2.

9.2.1.4.1.2 INVITE targeted to the non-controlling MCVideo function of an MCVideo group

The controlling MCVideo function:

1) shall generate a SIP INVITE request as specified in clause 6.3.3.1.2;

2) shall set the Request-URI to the public service identity of the non-controlling MCVideo function serving the group identity of the MCVideo group owned by the interconnected MCVideo system;

NOTE 1: The public service identity can identify the non-controlling 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.

3) shall set the P-Asserted-Identity to the public service identity of the controlling MCVideo function;

4) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the outgoing SIP INVITE request:

a) the <mcvideo-request-uri> element set to the group identity of the MCVideo group hosted by the non-controlling MCVideo function in the interconnected MCVideo system; and

b) the <mcvideo-calling-group-id> element set to the group identity of the group served by the controlling MCVideo function;

5) shall include the Recv-Info header field set to g.3gpp.mcvideo-transmission-request;

6) if:

a) an MCVideo GKTP document exists for the group identity contained in the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request; and

b) the MCVideo GKTP document contains a <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCVideo GKTP document:

i) shall perform the procedure in clause 6.3.3.6.2 to re-generate an I_MESSAGE; and

7) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 6.3.3.1.1; and

8) shall send the SIP INVITE request towards the interconnected MCVideo system in accordance with 3GPP TS 24.229 [11].

Upon receiving a SIP 403 (Forbidden) response for the SIP INVITE request, if according to local policy and if:

1) the response contains a Warning header field with the MCVideo warning code "128"; and

2) the response contains a P-Refused-URI-List header field and an application/resource-lists+xml MIME body as specified in IETF RFC 5318 [28];

NOTE 9: The application/resource-lists+xml MIME body contains MCVideo IDs identifying MCVideo users in an interconnected MCVideo system in the "uri" attributes of <entry> elements of one or more <list> elements of the <resource-lists> element in the application/resource-lists+xml MIME body where those MCVideo users need to be invited to the prearranged group call in case of group regrouping using interrogating method.

Editor’s Note: The above note currently isn’t defined in the 23.280 and 23.281.

then the controlling MCVideo function:

1) shall check if the number of members of the MCVideo group exceeds the value contained in the <on-network-max-participant-count> element of the group document as specified in 3GPP TS 24.481 [24]. If exceeded, the controlling MCVideo function shall invite only <on-network-max-participant-count> members identified in the "uri" attributes of <entry> elements of one or more <list> elements of the <resource-lists> element of the application/resource-lists+xml MIME body; and

NOTE 10: The <on-network-max-participant-count> element indicates the maximum number of participants allowed in the prearranged group session It is operator policy that determines which participants identified in the "uri" attributes of <entry> elements of one or more <list> elements of the <resource-lists> element in the application/resource-lists+xml MIME body are invited to the group call.

2) shall invite MCVideo users as specified in this clause using the list of MCVideo IDs in URI-List.

Upon receiving a SIP 200 (OK) response for the SIP INVITE request the controlling MCVideo function:

1) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3; and

NOTE 11: The procedures executed by the controlling MCVideo function prior to sending a response to the inviting MCVideo client are specified in clause 9.2.1.4.2.

2) if at least one of the invited MCVideo clients has subscribed to the conference package, shall subscribe to the conference event package in the non-controlling MCVideo function as specified in clause 9.2.3.4.3.

9.2.1.4.2 Terminating Procedures

In the procedures in this clause:

1) MCVideo ID in an incoming SIP INVITE request refers to the MCVideo ID of the originating user from the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request;

2) group identity in an incoming SIP INVITE request refers to the group identity from the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request;

3) MCVideo ID in an outgoing SIP INVITE request refers to the MCVideo ID of the called user in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the outgoing SIP INVITE request;

4) indication of required group members in a SIP 183 (Session Progress) response refers to the <required> element of the application/vnd.3gpp.mcvideo-info+xml MIME body set to "true" in a SIP 183 (Session Progress) sent by the non-controlling MCVideo function of an MCVideo group;

5) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

6) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

Upon receipt of a "SIP INVITE request for controlling MCVideo function of an MCVideo 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 INVITE 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] and skip the rest of the steps;

NOTE 1: if the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating an MCVideo emergency group call as determined by clause 6.3.3.1.13.2, or for originating an MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5, the controlling MCVideo function can according to local policy choose to accept the request.

2) shall determine if the media parameters are acceptable and the MCVideo codecs are offered in the SDP offer and if not reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

3) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if:

a) an Accept-Contact header field does not include the g.3gpp.mcvideo media feature tag; or

b) an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

4) if received SIP INVITE request includes an application/vnd.3gpp.mcvideo-info+xml MIME body with an <emergency-ind> element included or an <imminentperil-ind> element included, shall validate the request as described in clause 6.3.3.1.17;

5) if the group identity is associated with a group document maintained by the GMS:

NOTE 1A: How the MCVideo server determines that a group identity represents a group for which a group document is stored in the GMS is an implementation detail.

a) shall retrieve the necessary group document(s) from the group management server for the group identity contained in the SIP INVITE request and carry out initial processing as specified in clause 6.3.5.2;

b) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "167 call is not allowed on the preconfigured group" as specified in clause 4.4 "Warning header field" and skip the rest of the steps;

c) if the group referred to by the group identity has been regrouped, shall:

i) stop processing the SIP INVITE request;

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

iii) if the group referred to by the group identity has been regrouped based on a preconfigured group, shall send a copy of the notifying SIP MESSAGE that was generated and sent per clause 21.2.4.1 to the participating function for the MCVideo ID of the incoming SIP INVITE request and skip the rest of the steps; and

d) if the result of the initial processing in clause 6.3.5.2 was that a SIP 4xx, 5xx or 6xx response to the "SIP INVITE request for controlling MCVideo function of an MCVideo group" has been sent, do not continue with the rest of the steps in this clause;

6) if the group identity is associated with a user or group regroup based on a preconfigured group:

a) shall retrieve the stored information for the group identity; and

b) if there is no stored information for the group identity, the controlling MCVideo function shall return a SIP 404 (Not Found) response with the warning text set to "163 the group identity indicated in the request does not exist" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps;

NOTE 1B: The user or group regroup can have been removed very recently and the client has sent the group call request prior to receiving the removal notification.

6a) if the group identity is a TGI or the identity of a group regroup based a preconfigured group and the received SIP INVITE request does not include an <mcvideo-calling-group-id> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, shall return a SIP 403 (Forbidden) response to "SIP INVITE request for controlling MCVideo function of an MCVideo group".

NOTE 1C: This is the case where the MCVideo client has requested the setup of a regroup without including the identity of the constituent group, leading to the participating MCVideo function forwarding the SIP INVITE directly to the controlling MCVideo function. This is not allowed, since the originating client is required to include the identity of the constituent group.

7) shall perform the actions as described in clause 6.3.3.2.2;

8) shall maintain a local counter of the number of SIP 200 (OK) responses received from invited members and shall initialise this local counter to zero;

9) shall determine if an MCVideo group call for the group identity is already ongoing by determining if an MCVideo session identity has already been allocated for the group call and the MCVideo session is active;

10) if the SIP INVITE request contains an unauthorised request for an MCVideo emergency group call as determined by clause 6.3.3.1.13.2:

a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response as specified in clause 6.3.3.1.14; and

b) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11] and skip the rest of the steps;

11) if the SIP INVITE request contains an unauthorised request for an MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

a) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in clause F.1 with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <imminentperil-ind> element set to a value of "false"; and

b) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11] and skip the rest of the steps;

12) if a Resource-Priority header field is included in the SIP INVITE request:

a) if the Resource-Priority header field is set to the value indicated for emergency calls and the SIP INVITE request does not contain an emergency indication and the in-progress emergency state of the group is set to a value of "false", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the rest of the steps; or

b) if the Resource-Priority header field is set to the value indicated for imminent peril calls and the SIP INVITE request does not contain an imminent peril indication and the in-progress imminent peril state of the group is set to a value of "false", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the rest of the steps;

13) if the MCVideo group call is not ongoing then:

a) if:

i) the user identified by the MCVideo ID is not affiliated to the group identity contained in the <mcvideo-request-uri> element of the SIP INVITE request as specified in clause 6.3.6;

ii) the group identity contained in an <mcvideo-calling-group-id> element of the SIP INVITE request is not a constituent MCVideo group ID;

NOTE 1D: If the SIP INVITE is for a temporary group or a group regroup based on preconfigured group, the affiliation of the calling user to the constituent group has been assured by the non-controlling MCVideo function of the constituent group before forwarding this SIP INVITE to the controlling function of the regroup.

iii) the received SIP INVITE request does not contain an emergency indication or imminent peril indication; or

iv) the received SIP INVITE request is an authorised request for an MCVideo emergency group call as determined by clause 6.3.3.1.13.2 or MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCVideo user identified in the <mcvideo-calling-user-id> of the SIP INVITE is determined to not be eligible for implicit affiliation as specified in clause 8.2.2.3.6;

then shall return a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.4, and skip the rest of the steps below;

b) if the user identified by the MCVideo ID is not authorised to initiate the prearranged group session as specified in clause 6.3.5.4, shall send a SIP 403 (Forbidden) response with the warning text set to: "119 user is not authorised to initiate the group call" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below;

c) if the received SIP INVITE request contains an an authorised request for an MCVideo emergency group call as determined by clause 6.3.3.1.13.2 or MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCVideo user is eligible to be implicitly affiliated with the MCVideo group as determined as determined in step 13) a) iv) above, shall perform the implicit affiliation as specified in clause 8.2.2.3.7;

d) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may apply any preferential treatment to the SIP request as specified in 3GPP TS 24.229 [11];

e) shall create a prearranged group session and allocate an MCVideo session identity for the prearranged group call, and shall handle timer TNG3 (group call timer) as specified in clause 6.3.3.5;

f) if the group identity in the "SIP INVITE request for controlling MCVideo function of an MCVideo group" is a TGI or the identity of a group regroup based on a preconfigured group:

i) shall, for each of the constituent MCVideo groups except for the calling MCVideo group identified in the <mcvideo-calling-group-id> element of the incoming SIP INVITE,generate a SIP INVITE request towards the MCVideo server that owns the constituent MCVideo group identity by following the procedures in clause 9.2.1.4.1.2; and

NOTE 2: The MCVideo server that the SIP INVITE request is sent to acts as a non-controlling MCVideo function;

g) if the group identity in the SIP INVITE request for controlling MCVideo function of an MCVideo group is an MCVideo group ID:

i) shall determine the members to invite to the prearranged MCVideo group call as specified in clause 6.3.5.5;

ii) if necessary, shall start timer TNG1 (acknowledged call setup timer) according to the conditions stated in clause 6.3.3.3;

iii) if the received SIP INVITE request includes an application/vnd.3gpp.mcvideo-info+xml MIME body with an <emergency-ind> element set to a value of "true":

A) shall cache the information that this MCVideo user has initiated an MCVideo emergency call;

B) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCVideo emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall cache the information that this MCVideo user has initiated an MCVideo emergency alert; and

C) if the in-progress emergency state of the group is set to a value of "false":

I) shall set the value of the in-progress emergency state of the group to "true"; and

II) shall start timer TNG2 (in-progress emergency group call timer) and handle its expiry as specified in clause 6.3.3.1.16;

iv) if the in-progress emergency state of the group is set to a value of "false" and if the received SIP INVITE request contains an imminent peril indication set to a value of "true", the controlling MCVideo function shall:

A) shall cache the information that this MCVideo user has initiated an MCVideo imminent peril call; and

B) if the in-progress imminent peril state of the group is set to a value of "false", shall set the in-progress imminent peril state of the group to a value of "true";

v) shall invite each group member determined in step 13)g)i) above, to the group session, as specified in clause 9.2.1.4.1.1; and

vi) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3; and

14) if the MCVideo group call is ongoing then:

a) if:

i) the user identified by the MCVideo ID in the SIP INVITE request is not affiliated to the group identity contained in the <mcvideo-request-uri> element of the SIP INVITE request as specified in clause 6.3.6;

ii) the group identity contained in an <mcvideo-calling-group-id> element of the SIP INVITE request is not a constituent MCVideo group ID;

iii) the received SIP INVITE request does not contain an emergency indication or imminent peril indication; or

iv) the received SIP INVITE request is an authorised request for an MCVideo emergency group call as determined by clause 6.3.3.1.13.2 or MCVideo imminent peril group call as determined clause 6.3.3.1.13.5 and is determined to not be eligible for implicit affiliation as specified in clause 8.2.2.3.6;

b) if the user identified by the MCVideo ID in the SIP INVITE request is not authorised to join the prearranged group session as specified in clause 6.3.5.3, shall send a SIP 403 (Forbidden) response with the warning text set to "121 user is not allowed to join the group call" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below;

c) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may apply any preferential treatment to the SIP request as specified in 3GPP TS 24.229 [11];

d) if <on-network-max-participant-count> as specified in 3GPP TS 24.481 [24] is already reached:

i) if, according to local policy, the user identified by the MCVideo ID in the SIP INVITE request is deemed to have a higher priority than an existing user in the group session, may remove a participant from the session by following clause 9.2.1.4.4.3, and skip the next step; and

NOTE 3: The local policy for deciding whether to admit a user to a call that has reached its maximum amount of participants can include the <user-priority> and the <participant-type> of the user as well as other information of the user from the group document as specified in 3GPP TS 24.481 [24]. The local policy decisions can also include taking into account whether the imminent-peril indicator or emergency indicator was received in the SIP INVITE request.

ii) shall return a SIP 486 (Busy Here) response with the warning text set to "122 too many participants" to the originating network as specified in clause 4.4 and skip the rest of the steps;

e) if the received SIP INVITE request contains an an authorised request for an MCVideo emergency group call as determined by clause 6.3.3.1.13.2 or MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCVideo user is eligible to be implicitly affiliated with the MCVideo group as determined in step 14) a) iv) above, shall perform the implicit affiliation as specified in clause 8.2.2.3.7;

f) if the received SIP INVITE request includes an application/vnd.3gpp.mcvideo-info+xml MIME body with an <emergency-ind> element set to a value of "true":

i) shall cache the information that this MCVideo user has initiated an MCVideo emergency call;

ii) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCVideo emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall cache the information that this MCVideo user has initiated an MCVideo emergency alert;

iii) if the in-progress emergency state of the group is set to a value of "false":

A) shall set the value of the in-progress emergency state of the group to "true";

B) shall start timer TNG2 (in-progress emergency group call timer) and handle its expiry as specified in clause 6.3.3.1.16; and

C) shall generate SIP re-INVITE requests for the MCVideo emergency group call to the other call participants of the MCVideo group as specified in clause 6.3.3.1.6;

iv) if the in-progress imminent peril state of the group is set to a value of "true":

A) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCVideo user’s imminent peril indication as specified in clause 6.3.3.1.11, setting the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "true"; and

B) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11]; and

v) upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.581 [5];

g) if the in-progress emergency state of the group is set to a value of "false" and if the SIP INVITE request contains an imminent peril indication set to a value of "true", the controlling MCVideo function:

i) shall cache the information that this MCVideo user has initiated an MCVideo imminent peril call; and

ii) if the in-progress imminent peril state of the group is set to a value of "false":

A) shall set the in-progress imminent peril state of the group to a value of "true";

B) shall generate SIP re-INVITE requests for the MCVideo imminent peril group call to the other call participants of the MCVideo group as specified in clause 6.3.3.1.15; and

C) upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.581 [5]; and

iii) if the in-progress imminent peril state of the group is set to a value of "true":

B) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11];

h) shall generate a SIP 200 (OK) response as specified in the clause 6.3.3.2.4.2;

i) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

j) shall include in the SIP 200 (OK) response with the warning text set to "123 MCVideo session already exists" as specified in clause 4.4;

k) if the received SIP re-INVITE request contains an alert indication set to a value of "true" and this is an unauthorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

l) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true" and if the in-progress emergency state of the group is set to a value of "true", shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

NOTE 4: In this case, the request was for an imminent peril call but a higher priority MCVideo emergency call was already in progress on the group. Hence, the imminent peril call request aspect of the request is denied but the request is granted with emergency level priority.

m) shall interact with media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

NOTE 5: Resulting media plane processing is completed before the next step is performed.

n) shall send the SIP 200 (OK) response towards the inviting MCVideo client or inviting non-controlling MCVideo function according to 3GPP TS 24.229 [11];

o) shall generate a notification to the MCVideo clients, which have subscribed to the conference state event package that the inviting MCVideo User has joined in the MCVideo group session, as specified in clause 6.3.3.4;

NOTE 6: As a group document can potentially have a large content, the controlling MCVideo function can notify using content-indirection as defined in IETF RFC 4483 [29].

p) shall send a SIP NOTIFY request to each MCVideo client according to 3GPP TS 24.229 [11];

q) Upon receiving a SIP ACK to the above SIP 200 (OK) response and the SIP 200 (OK) response contained a Warning header field as specified in clause 4.4 with the warning text containing the mcvideo-warn-code set to "149", shall follow the procedures in clause 6.3.3.1.18; and

r) shall not continue with the rest of the clause.

Upon receiving a SIP 183 (Session Progress) response to the SIP INVITE request specified in clause 9.2.1.4.1 containing a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [30], the timer TNG1 (acknowledged call setup timer) is not running, the controlling MCVideo function supports media buffering and the SIP final response is not yet sent to the inviting MCVideo client:

1) shall generate a SIP 200 (OK) response to SIP INVITE request as specified in the clause 6.3.3.2.3.2;

2) shall include the warning text set to "122 too many participants" as specified in clause 4.4 in the SIP 200 (OK) response, if the prearranged MCVideo group has more than <on-network-max-participant-count> members as specified in 3GPP TS 24.481 [24];

3) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

4) shall include a P-Answer-State header field with the value "Unconfirmed";

5) if the SIP INVITE request contains an alert indication set to a value of "true" and this is an unauthorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

6) if the received SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true" and if the in-progress emergency state of the group is set to a value of "true", shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

7) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

NOTE 7: Resulting user plane processing is completed before the next step is performed.

8) shall send the SIP 200 (OK) response towards the inviting MCVideo client according to 3GPP TS 24.229 [11];

9) shall generate a notification to the MCVideo clients, which have subscribed to the conference state event package that the inviting MCVideo User has joined in the MCVideo group session, as specified in clause 6.3.3.4; and

NOTE 8: As a group document can potentially have a large content, the controlling MCVideo function can notify using content-indirection as defined in IETF RFC 4483 [29].

10) shall send a SIP NOTIFY request to each MCVideo client according to 3GPP TS 24.229 [11].

Upon receiving a SIP 183 (Session Progress) response for a SIP INVITE request as specified in clause 9.2.1.4.1.2 containing an indication of required group members, the timer TNG1 (acknowledged call setup timer) is running and all SIP 200 (OK) responses have been received to all SIP INVITE requests sent to MCVideo clients specified in clause 9.2.1.4.1.1, then the controlling MCVideo function shall wait until the SIP 200 (OK) response has been received to the SIP INVITE request specified in clause 9.2.1.4.1.2 before generating a SIP 200 (OK) response to the "SIP INVITE request for controlling MCVideo function of an MCVideo group".

Upon receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 9.2.1.4.1 that was sent to an affiliated and <on-network-required> group member as specified in 3GPP TS 24.481 [24]; and

1) if the MCVideo ID in the SIP 200 (OK) response matches to the MCVideo ID in the corresponding SIP INVITE request;

2) there are no outstanding SIP 200 (OK) responses to SIP INVITE requests which were sent to affiliated and <on-network-required> group members as specified in 3GPP TS 24.481 [24]; and

3) there is no outstanding SIP 200 (OK) response to a SIP INVITE request sent in clause 9.2.1.4.1.2 where the SIP 183 (Session Progress) response contained an indication of required group members;

the controlling MCVideo function:

1) shall stop timer TNG1 (acknowledged call setup timer) as described in clause 6.3.3.3;

2) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.3.2.3.2 before continuing with the rest of the steps;

3) shall include the warning text set to "122 too many participants" as specified in clause 4.4 in the SIP 200 (OK) response, if all members were not invited because the prearranged MCVideo group has been exceeded the <on-network-max-participant-count> members as specified in 3GPP TS 24.481 [24];

4) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

5) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

NOTE 9: Resulting media plane processing is completed before the next step is performed.

6) shall send a SIP 200 (OK) response to the inviting MCVideo client according to 3GPP TS 24.229 [11];

7) shall generate a notification to the MCVideo clients, which have subscribed to the conference state event package that the inviting MCVideo user has joined in the MCVideo group session, as specified in clause 6.3.3.4; and

NOTE 10: As a group document can potentially have a large content, the controlling MCVideo function can notify using content-indirection as defined in IETF RFC 4483 [29].

8) shall send the SIP NOTIFY request to the MCVideo clients according to 3GPP TS 24.229 [11].

Upon:

1) receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 9.2.1.4.1;

2) the timer TNG1 (acknowledged call setup timer) is not running;

3) the local counter of the number of SIP 200 (OK) responses received from invited members is equal to the value of the <on-network-minimum-number-to-start> element of the group document;

4) the controlling MCVideo function supports media buffering; and

5) the SIP final response has not yet been sent to the inviting MCVideo client;

the controlling MCVideo function according to local policy:

1) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.3.2.2;

2) shall include the warning text set to "122 too many participants" as specified in clause 4.4 in the SIP 200 (OK) response, if all members were not invited because the prearranged MCVideo group has exceeded the <max-participant-count> members as specified in 3GPP TS 24.481 [24];

3) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

4) if the SIP INVITE request contains an alert indication set to a value of "true" and this is an unauthorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

5) if the received SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true" and if the in-progress emergency state of the group is set to a value of "true", shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

6) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

NOTE 11: Resulting media plane processing is completed before the next step is performed.

7) shall send a SIP 200 (OK) response to the inviting MCVideo client according to 3GPP TS 24.229 [11];

8) shall generate a notification to the MCVideo clients, which have subscribed to the conference state event package that the inviting MCVideo user has joined in the MCVideo group session, as specified in clause 6.3.3.4; and

NOTE 12: As a group document can potentially have a large content, the controlling MCVideo function can notify using content-indirection as defined in IETF RFC 4483 [29].

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

Upon expiry of timer TNG1 (acknowledged call setup timer), if there are outstanding SIP 200 (OK) responses to SIP INVITE requests sent to affiliated and <on-network-required> group members as specified in 3GPP TS 24.481 [24], the controlling MCVideo function shall follow the procedures specified in clause 6.3.3.3.

If timer TNG1 (acknowledged call setup timer) is running and a final SIP 4xx, 5xx or 6xx response is received from an affiliated and <on-network-required> group member as specified in 3GPP TS 24.481 [24], the controlling MCVideo function shall follow the relevant procedures specified in clause 6.3.3.3.

If:

1) timer TNG1 (acknowledged call setup timer) is not running;

2) the local counter of the number of SIP 200 (OK) responses received from invited members is equal to the value of the <on-network-minimum-number-to-start> element of the group document; and

3) a final SIP 4xx, 5xx or 6xx response is received from an invited MCVideo client;

then the controlling MCVideo function shall perform one of the following based on policy:

1) send the SIP final response towards the inviting MCVideo client, according to 3GPP TS 24.229 [11], if a SIP final response was received from all the other invited MCVideo clients and the SIP 200 (OK) response is not yet sent; or

2) remove the invited MCVideo client from the MCVideo Session as specified in clause 6.3.3.1.5, if a SIP final response other than 2xx or 3xx was received from all the invited MCVideo clients and the SIP 200 (OK) response is already sent. The controlling MCVideo function may invite an additional member of the prearranged MCVideo group as specified in clause 9.2.1.4.1 that has not already been invited, if the prearranged MCVideo group has more than <on-network-max-participant-count> members as specified in 3GPP TS 24.481 [24], and all members have not yet been invited.

Upon receiving a SIP ACK to the SIP 200 (OK) response sent towards the inviting MCVideo client, and the SIP 200 (OK) response was sent with the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4, the controlling MCVideo function shall follow the procedures in clause 6.3.3.1.18.

9.2.1.4.3 End group call at the terminating controlling MCVideo function

Upon receiving a SIP BYE request the controlling MCVideo function shall follow the procedures as specified in clause 6.3.3.2.4.

9.2.1.4.4 End group call initiated by the controlling MCVideo function

9.2.1.4.4.1 General

This clause describes the procedures of each functional entity for ending the group call initiated by the controlling MCVideo function.

9.2.1.4.4.2 SIP BYE request for releasing MCVideo session for a group call

When the MCVideo session for group call needs to be released as specified in clause 6.3.8.1, the controlling MCVideo function shall follow the procedures in clause 6.3.3.1.5.

9.2.1.4.4.3 SIP BYE request toward a MCVideo client

When an MCVideo client needs to be removed from the MCVideo session (e.g. due to de-affiliation or admitting a higher priority user), the controlling MCVideo function shall follow the procedures in clause 6.3.3.1.5.

After successful removing the MCVideo client from the MCVideo session, the controlling MCVideo function may generate a notification to the MCVideo clients, which have subscribed to the conference state event package that an MCVideo user has been removed from the MCVideo session, as specified in clause 6.3.3.4 and send the SIP NOTIFY request to the MCVideo client according to 3GPP TS 24.229 [11].

9.2.1.4.5 Re-join procedures

9.2.1.4.5.1 Terminating procedures

Upon receipt of a SIP INVITE request that includes an MCVideo session identity of an ongoing MCVideo session in the Request-URI the controlling MCVideo function:

NOTE 1: If the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating an MCVideo emergency group call as determined by clause 6.3.3.1.13.2, or for originating an MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5, the controlling MCVideo function can according to local policy choose to accept the request.

2) shall reject the SIP request with a SIP 404 (Not Found) response if the MCVideo group call represented by the MCVideo session identity in Request-URI is not present;

3) shall determine if the media parameters are acceptable and the MCVideo codecs are offered in the SDP offer and if not, reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

4) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if:

a) an Accept-Contact header field does not include the g.3gpp.mcvideo media feature tag; or

b) an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

5) shall determine the MCVideo ID of the calling user;

6) if the user identified by the MCVideo ID is not authorised to join the prearranged group session as specified in clause 6.3.5.3, shall send a SIP 403 (Forbidden) response with the warning text set to "121 user is not authorised to join the group call" in a Warning header field as specified in clause 4.4. Otherwise continue with the rest of the steps below;

7) shall perform the actions on receipt of an initial SIP INVITE request as described in clause 6.3.3.2.2;

8) if the user identified by the MCVideo ID is not affiliated to the MCVideo group ID associated with the MCVideo session identity as specified in clause 6.3.3.5, shall return a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.4;

9) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may apply any preferential treatment to the SIP request as specified in 3GPP TS 24.229 [11];

10) if <on-network-max-participant-count> as specified in 3GPP TS 24.481 [24] is already reached:

a) if, according to local policy, the user identified by the MCVideo ID in the SIP INVITE request is deemed to have a higher priority than an existing user in the group session, may remove a participant from the session by following clause 9.2.1.4.4.3, and skip the next step; and

NOTE 2: The local policy for deciding whether to admit a user to a call that has reached its maximum amount of participants can include the <user-priority> and the <participant-type> of the user as well as other information of the user from the group document as specified in 3GPP TS 24.481 [24]. The local policy decisions can also include taking into account whether the imminent-peril indicator or emergency indicator was received in the SIP INVITE request.

b) shall return a SIP 486 (Busy Here) response with the warning text set to "122 too many participants" to the originating network as specified in clause 4.4. Otherwise, continue with the rest of the steps;

11) shall generate a SIP 200 (OK) response as specified in the clause 6.3.3.2.3.2;

12) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

13) shall interact with media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

NOTE 3: Resulting media plane processing is completed before the next step is performed.

14) shall send the SIP 200 (OK) response towards the inviting MCVideo client according to 3GPP TS 24.229 [11];

15) shall generate a notification to the MCVideo clients, which have subscribed to the conference state event package that the inviting MCVideo User has joined in the MCVideo group session, as specified in clause 6.3.3.4; and

NOTE 4: As a group document can potentially have a large content, the controlling MCVideo function can notify using content-indirection as defined in IETF RFC 4483 [29].

16) shall send a SIP NOTIFY request to each MCVideo client according to 3GPP TS 24.229 [11].

9.2.1.4.6 Late call entry initiated by controlling MCVideo function

When controlling MCVideo function is notified that an MCVideo client is newly affiliated or comes back from out of coverage, the controlling MCVideo function shall invite the MCVideo client to join an ongoing MCVideo group call by following the procedures specified in clause 9.2.1.4.1.

NOTE: How the MCVideo function is informed when an MCVideo client is coming back from out of coverage is out of scope of present document.

9.2.1.4.7 Receipt of a SIP re-INVITE request

In the procedures in this clause:

1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body; and

2) imminent peril indication in an incoming SIP INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

Upon receipt of a SIP re-INVITE request for an MCVideo session identity identifying an on-demand prearranged MCVideo group session, 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 re-INVITE 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] and skip the rest of the steps;

NOTE 1: If the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "true", the controlling MCVideo function can choose to accept the request.

2) if received SIP re-INVITE request includes an application/vnd.3gpp.mcvideo-info+xml MIME body with an <emergency-ind> element included or an <imminentperil-ind> element included, shall validate the request as described in clause 6.3.3.1.17;

3) if the received SIP re-INVITE request contains an unauthorised request for an MCVideo emergency call as determined by clause 6.3.3.1.13.2:

a) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response as specified in clause 6.3.3.1.14; and

b) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11] and skip the rest of the steps;

4) if the received SIP re-INVITE request contains an imminent peril indication set to "true" for an MCVideo imminent peril group call and this is an unauthorised request for an MCVideo imminent peril group call as determined by clause 6.3.3.1.13.6, shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

b) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11] and skip the rest of the steps;

5) if a Resource-Priority header field is included in the received SIP re-INVITE request:

a) if the Resource-Priority header field is set to the value indicated for emergency calls and the SIP re-INVITE request does not contain an emergency indication and the in-progress emergency state of the group is set to a value of "false", shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the rest of the steps; and

b) if the Resource-Priority header field is set to the value indicated for imminent peril calls and the SIP re-INVITE request does not contain an imminent peril indication and the in-progress imminent peril state of the group is set to a value of "false", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the rest of the steps;

6) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "true" and is an authorised request to initiate an MCVideo emergency group call as determined by clause 6.3.3.1.13.2, the controlling MCVideo function shall:

i) shall cache the MCVideo ID of the MCVideo user that has initiated an MCVideo emergency call;

ii) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCVideo emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall cache the MCVideo ID of the MCVideo user that has initiated an MCVideo emergency alert;

iii) if the in-progress emergency state of the group is set to a value of "true":

A) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCVideo user’s emergency indication as specified in clause 6.3.3.1.11, setting the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "true";

B) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11]; and

C) if the in-progress imminent peril state of the group is set to a value of "true", shall set it to a value of "false"; and

iv) if the in-progress emergency state of the group is set to a value of "false":

A) shall set the value of the in-progress emergency state of the group to "true";

B) shall start timer TNG2 (in-progress emergency group call timer) and handle its expiry as specified in clause 6.3.3.1.16;

NOTE 2: The interactions of TNG2 with the TNG3 (group call timer) are explained in clause 6.3.3.5.2.

Editor’s Note: timers need to be defined..

C) shall generate SIP re-INVITE requests for the MCVideo emergency group call to the other participants of the MCVideo group call as specified in clause 6.3.3.1.6;

D) shall send the SIP re-INVITEs towards the other participants of the MCVideo group call; and

E) upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.581 [5];

7) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "false" and is an unauthorised request for an MCVideo emergency group call cancellation as determined by clause 6.3.3.1.13.4:

a) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response;

b) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in annex F.1 with an <emergency-ind> element set to a value of "true";

c) if an <alert-ind> element of the mcvideoinfo MIME body is included in the SIP re-INVITE request set to "false", and there is an outstanding MCVideo emergency alert for this MCVideo user, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body an <alert-ind> element set to a value of "true"; and

d) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11] and skip the rest of the steps;

8) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <emergency-ind> element set to a value of "false" and is determined to be an authorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.16 and the in-progress emergency state of the group to is set to a value of "true" the controlling MCVideo function:

a) shall set the in-progress emergency group state of the group to a value of "false";

b) shall clear the cache of the MCVideo ID of the MCVideo user as having an outstanding MCVideo emergency group call;

c) if an <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is included and set to "false" and is determined to be an authorised request for an MCVideo emergency alert cancellation as specified in clause 6.3.3.1.13.3 and there is an outstanding MCVideo emergency alert for this MCVideo user shall:

i) if the received SIP re-INVITE request contains an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, clear the cache of the MCVideo ID of the MCVideo user identified by the <originated-by> element as having an outstanding MCVideo emergency alert; or

ii) if the received SIP re-INVITE request does not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body, clear the cache of the MCVideo ID of the sender of the SIP re-INVITE request as having an outstanding MCVideo emergency alert;

d) shall generate SIP re-INVITE requests to the participants in the group call as specified in clause 6.3.3.1.6. The MCVideo controlling function:

i) for each of the other participants in the group call shall send the SIP re-INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

ii) Upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.581 [5];

NOTE 3: Clause 6.3.3.1.5 will inform the group call participants of the cancellation of the MCVideo group’s in-progress emergency state and the cancellation of the MCVideo emergency alert if applicable.

e) shall stop timer TNG2 (in-progress emergency group call timer); and

NOTE 4: The interactions of TNG2 with the TNG3 (group call timer) are explained in clause 6.3.3.5.2;

f) for each of the affiliated members of the group that are not participating in the call:

i) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s emergency call as specified in clause 6.3.3.1.11;

ii) set the <emergency-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "false";

iii) if indicated above in step 8) c), set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "false"; and

iv) send the SIP MESSAGE request according to 3GPP TS 24.229 [11];

9) if the received SIP re-INVITE request contains an imminent peril indication and the in-progress emergency group state of the group is set to a value of "false", shall perform the procedures specified in clause 9.2.1.4.8 and skip the rest of the steps.

Upon receiving a SIP 200 (OK) response to a SIP re-INVITE request the controlling MCVideo function shall interact with the media plane as specified in 3GPP TS 24.581 [5];

1) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [11];

2) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [11] with the clarifications specified in clause 6.3.3.2.1;

3) shall include the "norefersub" option tag in a Supported header field according to IETF RFC 4488 [31];

4) shall include the "tdialog" option tag in a Supported header field according to IETF RFC 4538 [32];

5) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "true" and if this is an unauthorised request for an MCVideo emergency alert as determined by clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

6) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false" and if this is an unauthorised request for an MCVideo emergency alert cancellation as determined by clause 6.3.3.1.13.3, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

7) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "true", this is an authorised request for an MCVideo imminent peril group call and the in-progress emergency state of the group is set to a value of "true", shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

NOTE 5: In this case, the request was for an imminent peril call but a higher priority MCVideo emergency call was already in progress on the group. Hence, the imminent peril call request aspect of the request is denied but the request is granted with emergency level priority.

8) shall interact with media plane as specified in 3GPP TS 24.581 [5]; and

9) shall send the SIP 200 (OK) response towards the MCVideo client according to 3GPP TS 24.229 [11].

Upon receipt of a SIP 2xx response for an outgoing SIP MESSAGE request, shall handle according to 3GPP TS 24.229 [11].

9.2.1.4.8 Handling of a SIP re-INVITE request for imminent peril session

This procedure is initiated by the controlling MCVideo function as the result of an action in clause 9.2.1.4.7.

In the procedures in this clause:

1) imminent peril indication in an incoming SIP re-INVITE request refers to the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body.

When the controlling function receives a SIP re-INVITE request with an imminent peril indication set to "true", the controlling function:

1) if the in-progress emergency state of the group is set to a value of "false" and if the SIP re-INVITE request contains an imminent peril indication set to a value of "true" or the in-progress imminent peril state of the group to "true", the controlling MCVideo function shall:

NOTE: 1 The calling procedure has already determined that this is not an unauthorised request for an MCVideo imminent peril call, therefore that check does not need to be repeated in the current procedure.

a) if the in-progress imminent peril state of the group is set to a value of "true" and this MCVideo user is indicating a new imminent peril indication:

i) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCVideo user’s imminent peril indication as specified in clause 6.3.3.1.11 with the following clarifications;

A) set the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "true"; and

B) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11];

b) if the in-progress imminent peril state of the group is set to a value of "false";

i) set the value of the in-progress imminent peril state of the group to "true";

ii) generate SIP re-INVITE requests for the MCVideo imminent peril group call to participants in the MCVideo group call as specified in clause 6.3.3.1.15;

iii) send the SIP re-INVITES to all of the other participants in the MCVideo group call;

iv) for each of the affiliated members of the group not participating in the group call, generate a SIP MESSAGE request notification of the MCVideo user’s imminent peril indication as specified in clause 6.3.3.1.11 with the following clarifications;

A) set the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "true"; and

B) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11]; and

c) cache the information that this MCVideo user has initiated an MCVideo imminent peril call;

2) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "false" and is an unauthorised request for an MCVideo imminent peril group call cancellation as determined by clause 6.3.3.1.13.6 shall:

a) reject the SIP re-INVITE request with a SIP 403 (Forbidden) response to the SIP re-INVITE request; and

b) include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcvideo-info+xml MIME body as specified in Annex F.1 with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <imminentperil-ind> element set to a value of "false";

c) send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [11]; and

d) skip the rest of the steps;

3) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "false" and is determined to be an authorised request for an MCVideo imminent peril call cancellation as specified in clause 6.3.3.1.13.6 and the in-progress imminent peril state of the group to is set to a value of "true" the controlling MCVideo function shall:

a) set the in-progress imminent peril state of the group to a value of "false";

b) cache the information that this MCVideo user no longer has an outstanding MCVideo imminent peril group call;

c) generate SIP re-INVITES requests to the other participants in the MCVideo group call as specified in clause 6.3.3.1.15. The MCVideo controlling function:

i) for each participant shall send the SIP re-INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

ii) Upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCVideo function interact with the media plane as specified in 3GPP TS 24.581 [5]; and

NOTE 2: Clause 6.3.3.1.14 will inform the affiliated and joined members of the cancellation of the MCVideo group’s in-progress emergency state and the cancellation of the MCVideo emergency alert if applicable.

d) for each of the affiliated members of the group not participating in the call shall:

i) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s imminent peril call as specified in clause 6.3.3.1.11;

ii) set the <imminentperil-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "false"; and

iii) send the SIP MESSAGE request according to 3GPP TS 24.229 [11];

4) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [11] with the clarifications specified in clause 6.3.3.2.1;

5) shall include the "norefersub" option tag in a Supported header field according to IETF RFC 4488 [31];

6) shall include the "tdialog" option tag in a Supported header field according to IETF RFC 4538 [32];

7) shall interact with media plane as specified in 3GPP TS 24.581 [5]; and

8) shall send the SIP 200 (OK) response towards the MCVideo client according to 3GPP TS 24.229 [11].

Upon receipt of a SIP 2xx response for an outgoing SIP MESSAGE request, shall handle according to 3GPP TS 24.229 [11].

9.2.1.5 Non-controlling function of an MCVideo group procedures

9.2.1.5.1 Originating procedures

This clause describes the procedures for inviting an MCVideo user to an MCVideo session. The procedure is initiated by the non-controlling MCVideo function of an MCVideo group as the result of an action in clause 9.2.1.5.2 or clause 9.2.1.5.5.

The non-controlling MCVideo function:

1) shall invite the MCVideo clients as specified in clause 6.3.4.1.2;

2) shall include in each SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the controlling MCVideo function according to the procedures specified in clause 6.3.4.1.1; and

3) shall send each SIP INVITE request towards the terminating network in accordance with 3GPP TS 24.229 [11].

For each SIP 183 (Session Progress) response received to each SIP INVITE request sent to an MCVideo client, the non-controlling MCVideo function of an MCVideo group:

1) For each SIP 183 (Session Progress) response containing the option tag "100rel", shall send a SIP PRACK request towards the MCVideo client according to 3GPP TS 24.229 [11]; and

2) shall cache the received response;

For each SIP 200 (OK) response received to each SIP INVITE request sent to an MCVideo client, the non-controlling MCVideo function of an MCVideo group:

1) shall cache the SIP 200 (OK) response;

2) shall start the SIP session timer according to rules and procedures of IETF RFC 4028 [23]; and

3) if at least one of the participants has subscribed to the conference event package, shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in clause 9.2.3.5.2.

On receipt of a SIP 3xx, 4xx, 5xx or 6xx response from an invited MCVideo client, the non-controlling MCVideo function of an MCVideo group:

1) shall send an SIP ACK request towards the MCVideo client as specified in 3GPP TS 24.229 [11];

2) shall remove the cached provisional responses received from the MCVideo client, if any cached provisional responses exists; and

3) if the procedures are inititated by the receipt of the "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" as specified in clause 9.2.1.5.2, shall cache the SIP 3xx, 4xx, 5xx or 6xx response.

9.2.1.5.2 Terminating procedures

9.2.1.5.2.1 General

When receiving the "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" the MCVideo server can be acting as a controller MCVideo function in an ongoing prearranged group call or, if an prearranged group call is not ongoing, be initiated as an non-controlling MCVideo function and invite MCVideo users.

If a prearranged group call is not ongoing the MCVideo server shall perform the actions specified in clause 9.2.1.5.2.2.

If the "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" is received when a prearranged group call is ongoing, the controlling MCVideo function may switch from operating in a controlling MCVideo function mode to operate in a non-controlling MCVideo function mode as specified in clause 9.2.1.5.2.3.

When operating in the non-controlling mode and a SIP BYE request is received from the controlling MCVideo function, the non-controlling MCVideo function shall change from operating in the non-controlling mode to operating in the controlling mode as specified in clause 9.2.1.5.2.4.

9.2.1.5.2.2 Initiating a prearranged group call

Upon receipt of a "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" and if a prearranged group call is not ongoing, the non-controlling MCVideo function of an MCVideo group:

NOTE 1: The Contact header field of the SIP INVITE request contains the "isfocus" feature media tag.

3) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if:

a) an Accept-Contact header field does not include the g.3gpp.mcvideo media feature tag; or

b) an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

4) if the partner MCVideo system does not have a mutual aid relationship with the primary MCVideo system identified by the contents of the P-Asserted-Identity, shall reject the "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" with a SIP 403 (Forbidden) response, with warning text set to "128 isfocus already assigned" in a Warning header field as specified in clause 4.4, and shall not process the remaining steps;

5) void

NOTE 2: In 3GPP TS 24.379 [40] clause 10.1.1.5.2.2, step 5 deals with "a trusted mutual aid relationship … between the partner MCPTT system and the primary MCPTT system" and references 3GPP TS 23.379 [78] clause 10.6.2.4.2. There is no equivalent clause in 3GPP TS 23.281 [26]. If 3GPP TS 23.281 [26] were to include an equivalent clause, this step 5 can be used for a step 5 equivalent to that of 3GPP TS 24.379 [40].

6) shall retrieve the group document from the group management server for the MCVideo group ID contained in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request and carry out initial processing as specified in clause 6.3.5.2 and continue with the rest of the steps if the checks in clause 6.3.5.2 succeed;

7) shall cache the content of the SIP INVITE request, if received in the Contact header field and if the specific feature tags are supported;

8) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may apply any preferential treatment to the SIP request as specified in 3GPP TS 24.229 [11];

9) determine the members to invite to the prearranged MCVideo group call as specified in clause 6.3.5.5;

10) if the group document retrieved from the group management server contains <on-network-required> group members as specified in 3GPP TS 24.481 [24], shall send a SIP 183 (Session Progress) response to the SIP INVITE request for non-controlling MCVideo function of an MCVideo group as specified in clause 6.3.4.2.2.1 and shall populate the response with an application/vnd.3gpp.mcvideo-info+xml MIME body containing the <required> element set to "true".

11) if the group document retrieved from the group management server does not contain any <on-network-required> group members as specified in 3GPP TS 24.481 [24], may, according to local policy, send a SIP 183 (Session Progress) response to the SIP INVITE request for non-controlling MCVideo function of an MCVideo group as specified in clause 6.3.4.2.2.1;

12) shall invite each group member determined in step 9) above, to the group session, as specified in clause 9.2.1.5.1; and

13) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3;

Unless a SIP response has been sent to the controlling MCVideo function as specified in step 10 or 11 above, the non-controlling MCVideo function of an MCVideo group shall wait for the first SIP provisional response or first SIP 200 (OK) response from one of the invited MCVideo clients, before sending a response to the SIP INVITE request for non-controlling MCVideo function of an MCVideo group.

Upon receiving the first 18x response to a SIP INVITE request sent to an invited MCVideo client as specified in clause 9.2.1.5.1, not containing a P-Answer-State header field, and if a SIP 183 (Session Progress) response has not already been sent in response to the SIP INVITE request for non-controlling MCVideo function of an MCVideo group, the non-controlling MCVideo function of an MCVideo group:

1) shall generate a SIP 183 (Session Progress) response as described in clause 6.3.4.2.2.1; and

2) shall forward the SIP 183 (Session Progress) response to the controlling MCVideo function according to 3GPP TS 24.229 [11].

Upon receiving the first 18x response to a SIP INVITE request sent to an invited MCVideo client as specified in clause 9.2.1.5.1, containing a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [30], a SIP 183 (Session Progress) response has not already been sent in response to the SIP INVITE request for non-controlling MCVideo function of an MCVideo group and the non-controlling MCVideo function of an MCVideo group supports media buffering, the non-controlling MCVideo function of an MCVideo group:

1) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.4.2.2.2before continuing with the rest of the steps;

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.4.2.1;

3) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3.5; and

NOTE 2: Resulting media plane processing is completed before the next step is performed.

4) shall send a SIP 200 (OK) response to the controlling MCVideo function according to 3GPP TS 24.229 [11].

If the group document does not contain any <on-network-required> group members as specified in 3GPP TS 24.481 [24], then upon receiving the first SIP 200 (OK) response to a SIP INVITE request sent to an invited MCVideo client as specified in clause 9.2.1.5.1, the non-controlling MCVideo function of an MCVideo group:

1) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.4.2.2.2before continuing with the rest of the steps;

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.4.2.1;

3) shall interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.3.5; and

NOTE 3: Resulting media plane processing is completed before the next step is performed.

4) shall send a SIP 200 (OK) response to the controlling MCVideo function according to 3GPP TS 24.229 [11];

If the group document contains <on-network-required> group member(s) as specified in 3GPP TS 24.481 [24], then the non-controlling MCVideo function of an MCVideo group shall wait until all SIP 200 (OK) responses to SIP INVITE requests have been received from the <on-network-required> MCVideo clients before sending a SIP 200 (OK) response back to the controlling MCVideo function, as specified above.

If all invited MCVideo clients have rejected SIP INVITE requests with a SIP 3xx, 4xx, 5xx or 6xx response, the non-controlling MCVideo function of an MCVideo group:

1) shall generate a SIP reject response as specified in 3GPP TS 24.229 [11];

2) shall, from the list of reject response codes cached by the non-controlling MCVideo function of an MCVideo group, select the highest prioritized cached reject response code as specified in IETF RFC 3261 [15]; and

3) shall send the reject response towards the controlling MCVideo function as specified in 3GPP TS 24.229 [11].

9.2.1.5.2.3 Joining an ongoing prearranged group call

Upon receipt of a "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" and if a prearranged group call is already ongoing, the non-controlling MCVideo function of an MCVideo group:

NOTE 1: The Contact header field of the SIP INVITE request contains the "isfocus" feature media tag.

1) shall determine if the media parameters are acceptable and the MCVideo codecs are offered in the SDP offer and if not, reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

2) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if:

a) an Accept-Contact header field does not include the g.3gpp.mcvideo media feature tag; or

b) an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

3) if the partner MCVideo system does not have a mutual aid relationship to merge an ongoing prearranged call with the primary MCVideo system identified by the contents of the P-Asserted-Identity, shall reject the "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" with a SIP 403 (Forbidden) response, with warning text set to "128 isfocus already assigned" in a Warning header field as specified in clause 4.4, and shall not process the remaining steps;

4) shall cache the content of the SIP INVITE request, if received in the Contact header field and if the specific feature tags are supported;

5) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may apply any preferential treatment to the SIP request as specified in 3GPP TS 24.229 [11];

6) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.4.2.2.2before continuing with the rest of the steps;

7) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.4.2.1;

NOTE 2: Resulting media plane processing is completed before the next step is performed.

8) shall send a SIP 200 (OK) response to the controlling MCVideo function according to 3GPP TS 24.229 [11]; and

9) if at least one of the MCVideo clients in the pre-arranged group session has a subscription to the conference event package, shall subscribe to the conference event package from the controlling MCVideo function as specified in clause 9.2.3.5.3.

Upon receipt of the SIP ACK request, the non-controlling MCVideo function of an MCVideo group:

1) if information about a currently transmitting MCVideo client is cached:

a) shall generate a SIP INFO request as specified in clause 6.3.4.1.3; and

b) shall send the SIP INFO request to the controlling MCVideo function as specified in 3GPP TS 24.229 [11];

2) shall instruct the media plane to finalise the switch to the non-controlling mode as specified in 3GPP TS 24.581 [5] clause 6.3.5.3; and

3) if at least one of the MCVideo clients in the chat group session has a subscription to the conference event package, shall subscribe to the conference event package from the controlling MCVideo function as specified in clause 9.2.3.5.3.

9.2.1.5.2.4 Splitting an ongoing prearranged group call

Upon receipt of a SIP BYE request or a final SIP reject response from the controlling MCVideo function, the non-controlling MCVideo function of an MCVideo group:

1) if keeping the prearranged group call active is according to the release policy in clause 6.3.8.1, shall request media plane to switch to controlling mode as specified in 3GPP TS 24.581 [5] clause 6.3.5;

NOTE 1: Resulting media plane processing is completed before the next step is performed.

2) if a SIP BYE request was received, shall send a SIP 200 (OK) response to the SIP BYE request; and

3) if keeping the prearranged group call active is according to the release policy in clause 6.3.8.1 and if at least one of the remaining MCVideo clients has subscribed to the conference package, shall send a NOTIFY request to all participants with a subscription to the conference event package as specified in clause 9.2.3.5.2.

NOTE 2: The SIP NOTIFY request will indicate that all participants, with the exception of the MCVideo users belonging to the constituent MCVideo group hosted by the non-controlling MCVideo function, have left the group session.

9.2.1.5.3 Rejoin procedures

9.2.1.5.3.1 Terminating procedures

Upon receipt of a SIP INVITE request that includes an MCVideo session identity of an ongoing MCVideo session in the Request-URI the non-controlling MCVideo function act as a controlling MCVideo function towards the MCVideo client and shall perform the actions in the clause 9.2.1.4.5.1 with the following clarifications:

1) the MCVideo session identity in the Contact header field of the SIP 200 (OK) response shall be the MCVideo session identity generated by the non-controlling MCVideo function; and

2) the clause 9.2.3.5.2 shall be used when sending the SIP NOTIFY request for subscriptions to the conference event package.

9.2.1.5.3.2 Late call entry initiated by non-controlling MCVideo function

When non-controlling MCVideo function is notified that an MCVideo client is newly affiliated or comes back from out of coverage, the non-controlling MCVideo function shall invite the MCVideo client to join an ongoing MCVideo group call by following the procedures specified in clause 9.2.1.5.1.

NOTE: How the MCVideo function is informed when an MCVideo client is coming back from out of coverage is out of scope of present document.

9.2.1.5.4 void

9.2.1.5.5 Initiating a temporary group session

Upon receiving a "SIP INVITE request "SIP INVITE request from participating MCVideo function for controlling MCVideo function of an MCVideo group" when a prearranged group session is not ongoing, the non-controlling MCVideo-function shall:

NOTE 1: The difference between a "SIP INVITE request from participating MCVideo function for controlling MCVideo function of an MCVideo group" and a "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" (from the controlling MCVideo function) is that the latter SIP INVITE request contains the isfocus media feature tag in the Contact header field.

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP INVITE 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]. Otherwise, continue with the rest of the steps;

3) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if:

a) an Accept-Contact header field does not include the g.3gpp.mcvideo media feature tag; or

b) an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

4) shall retrieve the group document from the group management server for the MCVideo group ID contained in the <associated-group-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request and carry out initial processing as specified in clause 6.3.5.2 and continue with the rest of the steps if the checks in clause 6.3.5.2 succeed;

NOTE 2: If the checks are not succesful, the SIP response to the "SIP INVITE request from participating MCVideo function for non-controlling MCVideo function of an MCVideo group" is already sent in the clause 6.3.5.2.

5) shall cache the content of the SIP INVITE request;

6) shall check if a Resource-Priority header field is included in the incoming SIP INVITE request and may apply any preferential treatment to the SIP request as specified in 3GPP TS 24.229 [11];

7) shall authorize the MCVideo user in the <mcvideo-calling-user-identity> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the "SIP INVITE request from participating MCVideo function for non-controlling MCVideo function of an MCVideo group" as specified in clause 6.3.5.4, if the MCVideo user is unauthorized to initiated a pre-arranged group session the non-controlling MCVideo function shall send a SIP 403 (Forbidden) response with the warning text set to "119 user is not authorised to initiate the group call" in a Warning header field as specified in clause 4.4.

8) if:

a) the MCVideo user identified in the <mcvideo-calling-user-id> of the incoming SIP INVITE is not affiliated to the group identity contained in the <associated-group-id> element of the incoming SIP INVITE request as specified in clause 6.3.6;

b) the incoming SIP INVITE request does not contain an emergency indication or an imminent peril indication; or

c) the incoming SIP INVITE request is an authorised request for an MCVideo emergency group call as determined by clause 6.3.3.1.13.2 or for an MCVideo imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCVideo user identified in the <mcvideo-calling-user-id> of the incoming SIP INVITE is determined to not be eligible for implicit affiliation as specified in clause 8.2.2.3.6;

9) shall generate a SIP INVITE request towards the controlling MCVideo function as specified in clause 6.3.4.1.4; and

10) shall send the SIP INVITE request to the controlling MCVideo function as specified in 3GPP TS 24.229 [11].

Upon receipt of a SIP 2xx response to the SIP INVITE request sent to the controlling MCVideo function as specified above, the non-controlling MCVideo function:

1) shall send the SIP ACK request to the controlling MCVideo function as specified in 3GPP TS 24.229 [11];

2) shall generate a SIP 200 (OK) to the "SIP INVITE request for controlling MCVideo function of an MCVideo group" as specified in 3GPP TS 24.229 [11] populated as follows:

a) shall include an SDP answer as specified in clause 6.3.4.2.1 based on the SDP answer in the SIP 200 (OK) response;

b) shall include the public service identifier of the non-controlling MCVideo function in the P-Asserted-Identity header field; and

c) shall include the warning text set to "148 MCVideo group is regrouped" in a Warning header field as specified in clause 4.4;

3) shall start acting as a non-controlling MCVideo function and interact with the media plane as specified in 3GPP TS 24.581 [5] clause 6.5;

4) shall determine the members to invite to the prearranged MCVideo group call as specified in clause 6.3.5.2; and

5) shall invite each group member determined in step 2) above, to the group session, as specified in clause 9.2.1.5.1.

Upon receipt of other final SIP responses with the exception of the SIP 2xx response to the INVITE request sent to the controlling MCVideo function as specified above, the non-controlling MCVideo function:

1) shall send the SIP ACK response to the controlling MCVideo function as specified in 3GPP TS 24.229 [11]; and

2) shall start acting as a controlling MCVideo function as specified in clause 9.2.1.4 and invite members as specified in clause 6.3.4.1.2.

NOTE 4: Regardless if the controlling MCVideo function accepts or rejects the SIP INVITE request sent above the prearranged group session continues to be initiated with only the members of the group homed on the non-controlling MCVideo function of the group being invited to the group call.

The non-controlling MCVideo function shall handle SIP responses (other than the SIP 2xx response) to the SIP INVITE requests sent to invited members as specified in 3GPP TS 24.229 [11].

Upon receipt of a SIP 2xx response to SIP INVITE requests sent to invited members, the non-controlling MCVideo function:

1) shall send the SIP ACK request as specified in 3GPP TS 24.229 [11]; and

2) shall interact with the media plane as specified in 3GPP TS 24.581 [5].