9.2.2 Chat group (restricted) call

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

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

9.2.2.1 General

9.2.2.2 MCVideo client procedures

9.2.2.2.1 On-demand chat group call

9.2.2.2.1.1 MCVideo client joins a chat MCVideo group session

Upon receiving a request from an MCVideo user to establish an MCVideo group session using an MCVideo group identity, identifying a chat MCVideo group, 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.

Upon receiving a request from an MCVideo user to establish an MCVideo group session using an MCVideo group identity, identifying a chat MCVideo group, 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 chat 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) 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];

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

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

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

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

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

9) 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.

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

11) 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 comply with the procedures in clause 6.2.8.1.2;

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

13) shall contain 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 "chat";

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

d) an <anyExt> element containing:

i) 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

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

NOTE 2: 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.

14) shall include in the SIP INVITE request an SDP offer according to 3GPP TS 24.229 [11] with the clarifications specified in clause 6.2.1;

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

16) shall send the SIP INVITE request 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]; and

2) if the MCVideo emergency group call state is set to "MEGC 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.

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.2.2.1.2 MCVideo client receives SIP re-INVITE request

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

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 "MIGC 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 "MVIG 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 "MIGC 1: imminent-peril-gc-capable";

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

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

9.2.2.2.1.3 MCVideo in-progress emergency cancel

This clause covers both on-demand session.

Upon receiving a request from an MCVideo user to cancel the in-progress emergency condition on a chat MCVideo group, the MCVideo client shall generate a SIP re-INVITE request as 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 optionally 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, if the SIP re-INVITE request is to be sent within an on-demand session, 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;

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

6) 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 set the MCVideo emergency group state of the group to "MVEG 1: no-emergency";

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

3) 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 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.

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.2.2.1.4 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 a chat MCVideo 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 is not authorised to do so 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 is not authorised to do so 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;

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]; and

2) shall perform the actions specified in clause 6.2.8.1.4.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the SIP re-INVITE request 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.2.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 chat 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;

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 "chat"; 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];

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 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 response, 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 "MIG 2: in-progress".

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

9.2.2.2.1.6 MCVideo client receives a SIP INVITE request for an MCVideo group call

This procedure is used for MCVideo emergency and MCVideo imminent peril calls when the MCVideo client is affiliated but not joined to the chat group.

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:

1) may reject the SIP INVITE request if either of the following conditions is met:

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

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 1: 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) 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;

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; and

iv) if the received SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing an <mcvideo-Params> element containing an <anyExt> element which includes a <functional-alias-URI> element, may display to the MCVideo user the functional alias of the inviting MCVideo user; and

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

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 <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 3: in-progress";

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

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

7) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;

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

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

10) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [23]. If no "refresher" parameter was included in the received SIP INVITE request the "refresher" parameter in the Session-Expires header field shall be set to "uas", otherwise shall include a "refresher" parameter set to the value received in the Session-Expires header field the received SIP INVITE request;

11) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [11] with the clarifications given in clause 6.2.2;

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

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

9.2.2.2.2 End group call

9.2.2.2.2.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.2.2.2.2 Client terminating procedures

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

9.2.2.3 Participating MCVideo function procedures

9.2.2.3.1 On-demand chat group call

9.2.2.3.1.1 MCVideo chat session establishment

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;

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.

Upon receipt of a "SIP INVITE request for originating participating MCVideo function" for a group identity identifying a chat MCVideo group containing an application/vnd.3gpp.mcvideo-info+xml MIME body with the <session-type> element set to a value of "chat", 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 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 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 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 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 originating participating MCVideo function, the user identified by the MCVideo ID is not authorised to make chat 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 "108 user not authorised to make chat group calls" in a Warning header field as specified in clause 4.4;

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

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 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 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 for an exception to the limit for the maximum simultaneous MCVideo sessions supported for the MCVideo user.

6) if the user identified by the MCVideo ID is not affiliated to the group identified in the "SIP INVITE request for originating participating MCVideo function" as determined by clause 8.2.2.2.11, 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.

8) 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 an interconnected MCVideo system.

NOTE 7: How the participating MCVideo server discovers the public service identity of the controlling MCVideo function associated with the group identity is out of scope of the current document.

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

10) shall set the Request-URI to the public service identity of the controlling MCVideo function associated with the group identity present in the incoming SIP INVITE request;

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

NOTE 9: 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 10: 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 11: 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 12: How the local MCVideo system routes the SIP request through an exit MCVideo gateway server is out of the scope of the present document.

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

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

12) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request as specified in clause 6.3.2.1.1.1;

13) if the received SIP INVITE request contains an application/vnd.3gpp.location-info+xml MIME body as specified in Annex F.3; and

a) if not already included, shall include a Content-Type header field set to "application/vnd.3gpp.location-info+xml"; and

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

NOTE 13: Note that the application/vnd.3gpp.mcvideo-info+xml MIME body will already have been copied into the outgoing SIP INVITE request by clause 6.3.2.1.3.

14) 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 IETF RFC 4412 [33] set to the value indicated in the Resource-Priority header field of the SIP INVITE request from the MCVideo client; and

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

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

Upon receipt of a SIP 302 (Moved Temporarily) response to the above SIP INVITE request in step 14), the participating MCVideo function:

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

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 to the above SIP INVITE request in step 14) the participating MCVideo function:

1) if the 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 specified in the 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) 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;

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

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

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request in step 14) 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 the current procedure, shall perform the procedures of clause 8.2.2.2.14.

9.2.2.3.1.2 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 a served MCVideo client of a chat MCVideo group, 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 INVITE request for terminating participating MCVideo function" 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 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 may by means beyond the scope of this specification choose to accept the request.

2) shall determine if the media parameters are acceptable and the MCVideo codec 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.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;

6) 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.

7) 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) if the SIP 200 (OK) response is to be sent within an on-demand session, 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; and

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

Upon receipt of a SIP 403 (Forbidden) response to the sent SIP re-INVITE request 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; and

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

9.2.2.3.1.3 Reception of a SIP INVITE request for terminating MCVideo client

This clause covers on-demand session.

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

NOTE: If the SIP 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 by means beyond the scope of this specification 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. Otherwise, continue with the rest of the steps;

3) shall generate a SIP INVITE request as specified in clause 6.3.2.2.3;

4) shall set the Request-URI to the public user identity associated with the MCVideo ID of the MCVideo user to be invited based on the contents of the Request-URI of the received "SIP INVITE request for terminating participating MCVideo function";

5) shall copy the contents of the P-Asserted-Identity header field of the incoming "SIP INVITE request for terminating participating MCVideo function" to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

6) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for terminating participating MCVideo function" as specified in clause 6.3.2.2.1;

7) if the received SIP 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;

8) shall perform the procedures specified in clause 6.3.2.2.9 to include any MIME bodies in the received SIP INVITE request; and

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

Upon receiving a SIP 200 (OK) response to the above SIP 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.2.3.1.4 Reception of a SIP re-INVITE request for terminating MCVideo client

This clause covers both on-demand session.

Upon receipt of a SIP re-INVITE request for a terminating MCVideo client of a chat MCVideo group, the participating MCVideo function:

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

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; and

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

9.2.2.4 Controlling MCVideo function procedures

9.2.2.4.1 On-demand chat group call

9.2.2.4.1.1 MCVideo chat session establishment

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

5) alert indication in an incoming SIP INVITE request refers to the <alert-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" containing a group identity identifying a chat 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 set to a value of "true", the controlling MCVideo function can by means beyond the scope of this specification choose to accept the request.

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;

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"; or

c) the isfocus media feature tag is present in the Contact header field;

2A) 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;

3) if the received SIP INVITE request includes an application/vnd.3gpp.mcvideoinfo+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;

4) 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 and continue with the rest of the steps if the checks in clause 6.3.5.2 succeed;

5) if the MCVideo user identified by the MCVideo ID in the SIP INVITE request is not affiliated with the MCVideo group identified by the group identity in the SIP INVITE request as determined by the procedures of clause 6.3.6:

a) shall check if the MCVideo user is eligible to be implicitly affiliated with the MCVideo chat group as determined by clause 8.2.2.3.6; and

b) if the MCVideo user is not eligible for implicit affiliation, shall reject the SIP INVITE request with 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;

6) if the SIP INVITE request contains 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;

7) 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.6, 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;

8) 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 remaining steps; and

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 remaining steps;

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

10) shall create a chat group session and allocate an MCVideo session identity for the chat group session if the MCVideo chat group session identity does not already exist, and may handle timer TNG3 (group call timer) as specified in clause 6.3.3.5;

11) if the chat group session is ongoing and the <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 chat 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;

12) if the received SIP INVITE request was determined to be eligible for implicit affiliation in step 5) and if clause 8.2.2.3.7 was not previously invoked in the present clause, shall perform the implicit affiliation as specified in clause 8.2.2.3.7;

13) if the SIP INVITE request contains an emergency indication set to a value of "true" or the in-progress emergency state of the group to "true" the controlling MCVideo function shall:

a) validate that the SIP INVITE request includes a Resource-Priority header field populated with the values for an MCVideo emergency group call as specified in clause 6.3.3.1.19, and if not:

i) perform the actions specified in clause 6.3.3.1.8;

ii) send the SIP UPDATE request generated in clause 6.3.3.1.8 towards the initiator of the SIP INVITE request according to 3GPP TS 24.229 [11]; and

iii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8, proceed with the rest of the steps.

NOTE 3: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly- entered in-progress emergency states of the specified group.

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

i) for each of the other affiliated members 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 with the following clarifications:

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

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, perform the procedures specified in clause 6.3.3.1.12; and

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

ii) cache the information that this MCVideo user has initiated an MCVideo emergency call; and

iii) if the SIP INVITE request contains an authorised request for an MCVideo emergency alert as determined in step i) B) above, 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";

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

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

iv) shall generate SIP INVITE requests for the MCVideo emergency group call to the affiliated but not joined members of the chat MCVideo group as specified in clause 6.3.3.1.7;

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

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

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

vi) if the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is set to "true" and is an authorised request for an MCVideo emergency alert as specified in clause 6.3.3.1.13.1, shall cache the information that this MCVideo user has initiated an MCVideo emergency alert; and

vii) 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";

14) 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" or the in-progress imminent peril state of the group is set to "true", the controlling MCVideo function shall:

a) validate that the SIP INVITE request includes 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 if not:

i) perform the actions specified in clause 6.3.3.1.8;

ii) send the SIP UPDATE request generated in clause 6.3.3.1.8 towards the initiator of the SIP INVITE request according to 3GPP TS 24.229 [11]; and

iii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 proceed with the rest of the steps.

NOTE 4: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly- entered in-progress imminent peril states of the specified group.

b) 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]; and

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

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

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

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

iii) shall generate SIP INVITE requests for the MCVideo imminent peril call to the affiliated but not joined members of the chat MCVideo group as specified in clause 6.3.3.1.7;

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

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

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

15) shall accept the SIP request and generate a SIP 200 (OK) response to the SIP INVITE request according to 3GPP TS 24.229 [11];

16) 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 unless the procedures of clause 6.3.3.1.8 were performed in step 13)a) or step 14)a) above;

17) should include the Session-Expires header field and start supervising the SIP session 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";

18) shall include the "timer" option tag in a Require header field;

19) shall include the following in a Contact header field:

a) the g.3gpp.mcvideo media feature tag;

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo";

c) the MCVideo session identity; and

d) the media feature tag isfocus;

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

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

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

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.

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

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

25) if the chat group session was already ongoing and 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.4.2.

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.2.4.1.2 Receipt of a SIP re-INVITE request

In the procedures in this clause:

1) emergency indication in an incoming SIP re-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 re-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 a chat 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 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) if the 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 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 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:

a) validate that the SIP re-INVITE request includes a Resource-Priority header field is populated correctly for an MCVideo emergency group call as specified in clause 6.3.3.1.19, and if not:

i) shall perform the actions specified in clause 6.3.3.1.8; and

ii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.18 shall proceed with the rest of the steps.

NOTE 2: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly-entered in-progress emergency states of the specified group.

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

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

ii) if the 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 is an authorised request for an MCVideo emergency alert as determined by clause 6.3.3.1.13.1, shall cache the MCVideo ID of the MCVideo user that has initiated an MCVideo emergency alert; and

iii) for each of the other affiliated members 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 with the following clarifications:

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

B) if the received SIP re-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, perform the procedures specified in clause 6.3.3.1.12; and

C) send the SIP MESSAGE request as specified in 3GPP TS 24.229 [11]; 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";

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

iii) if the 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 this is an authorised request for an MCVideo emergency alert as 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;

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

v) shall generate SIP re-INVITE requests for the MCVideo emergency group call to the other affiliated and joined participants of the chat MCVideo group as specified in clause 6.3.3.1.6. The MCVideo controlling function:

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

B) 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

vi) shall generate SIP INVITE requests for the MCVideo emergency group call to the affiliated but not joined members of the chat MCVideo group as specified in clause 6.3.3.1.7. The controlling MCVideo function:

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

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

vii) 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";

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

6) 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 "false" and is determined to be an authorised request for an MCVideo emergency call cancellation as specified in clause 6.3.3.1.13.4 and the in-progress emergency state of the group to is set to a value of "true" the controlling MCVideo function shall:

a) validate that the SIP re-INVITE request includes a Resource-Priority header field is populated correctly for a normal priority MCVideo group call as specified in clause 6.3.3.1.19, and if not:

i) shall perform the actions specified in clause 6.3.3.1.8; and

ii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 shall proceed with the rest of the steps;

NOTE 3: Verify that the Resource-Priority header is included and properly populated for an in-progress emergency state cancellation of the specified group.

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

c) shall clear the cache of the MCVideo ID of the MCVideo user identified by the <originated-by> element as having an outstanding MCVideo emergency group call;

d) 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; and

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;

e) shall generate SIP re-INVITE requests to the other affiliated and joined members of the MCVideo group as specified in clause 6.3.3.1.6. The MCVideo controlling function:

i) for each affiliated and joined member 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]; and

NOTE 4: Clause 6.3.3.1.5 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.

f) for each of the affiliated but not joined members of the group shall:

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 d), 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];

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

a) if the Resource-Priority header field is set to the value indicated for emergency calls and the received SIP re-INVITE request does not contain an authorised request for an MCVideo emergency call as determined in step 4) above 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 remaining steps; or

b) if the Resource-Priority header field is set to the value indicated for imminent peril calls and the received SIP re-INVITE request does not contain an authorised request for an MCVideo imminent peril call as determined by the procedures of clause 6.3.3.1.13.5 and the in-progress imminent peril 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 remaining steps;

8) if the received SIP re-INVITE request contains an imminent peril indication, shall perform the procedures specified in clause 9.2.2.4.1.3 and skip the rest of the steps;

9) 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 unless the procedures of clause 6.3.3.1.8 were performed in step 6) a) i) above;

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

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

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

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

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

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

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

In the procedures in this clause:

1) 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.

When the controlling function receives a SIP re-INVITE request with and imminent peril indication, the controlling function:

1) if the SIP re-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 re-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 Annex 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;

2) if the in-progress emergency group 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:

a) validate that the SIP re-INVITE request includes a Resource-Priority header field with the namespace set to the MCVideo-specific namespace and the priority set to the priority designated for imminent peril calls and if not:

i) perform the actions specified in clause 6.3.3.1.8;

ii) send the SIP UPDATE request generated in clause 6.3.3.1.8 towards the initiator of the SIP re-INVITE request according to 3GPP TS 24.229 [11]; and

iii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 proceed with the rest of the steps.

NOTE 3: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly- entered in-progress imminent peril states of the specified group.

b) 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:

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

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

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

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

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

iii) shall generate SIP INVITE requests for the MCVideo imminent peril group call to the affiliated but not joined members of the chat MCVideo group as specified in clause 6.3.3.1.7;

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCVideo client as specified in 3GPP TS 24.229 [11]; and

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

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

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

i) 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";

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

iii) skip the rest of the steps;

4) 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) validate that the SIP re-INVITE request includes a Resource-Priority header field with the namespace set to the MCVideo-specific namespace, and the priority set to the priority level designated for a normal priority MCVideo group call, and if not:

i) shall perform the actions specified in clause 6.3.3.1.8; and

ii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 shall proceed with the rest of the steps;

NOTE 3: verify that the Resource-Priority header is included and properly populated for an in-progress emergency group state cancellation of the specified group.

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

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

d) shall generate SIP re-INVITES requests to the other affiliated and joined members of the MCVideo group as specified in clause 6.3.3.1.15. The MCVideo controlling function:

i) for each affiliated and joined member 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]; and

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

e) for each of the affiliated but not joined members of the group 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];

5) 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 unless the procedures of clause 6.3.3.1.8 were performed in step 2) or 4) above;

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

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

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].

9.2.2.4.2 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.2.4.3 End group call initiated by the controlling MCVideo function

9.2.2.4.3.1 General

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

9.2.2.4.3.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.4.

9.2.2.4.3.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.4.

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.2.5 Non-controlling function of an MCVideo group procedures

9.2.2.5.1 Terminating procedures

9.2.2.5.1.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 chat group call or, if a chat group call is not ongoing, be initiated as an non-controlling MCVideo function and invite MCVideo users.

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

If the "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" is received when a chat 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.2.5.1.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.2.5.1.4.

9.2.2.5.1.2 Initiating a chat group session

Upon receipt of a "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" and if a chat 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.

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 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) 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.2 before 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;

8) 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.

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

9.2.2.5.1.3 Joining an ongoing chat group call

Upon receipt of a "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" and if a chat 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 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.2 before 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;

8) shall instruct the media plane to initialise the switch to the non-controlling mode as specified in 3GPP TS 24.581 [5] clause 6.5.2.3;

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

9) if the media plane provided information about the current speaker(s), cache the information about the current speaker(s); and

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

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

1) if information about a current speaker(s) 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.2.5.1.4 Splitting an ongoing chat group call

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

1) if keeping the chat 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) shall send a SIP 200 (OK) response to the SIP BYE request; and

3) if at least one MCVideo client 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.2.5.1.5 MCVideo client joining the temporary group chat session

When acting in the non-controlling connection mode when receiving of a "SIP INVITE request for controlling MCVideo function of an MCVideo group" containing a group identity identifying a constituent chat MCVideo group being part of the temporary group call, the non-controlling MCVideo function shall act as a controlling MCVideo function towards the MCVideo client and shall perform the actions in the clause 9.2.2.4.1.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.2.5.1.6 Receipt of a SIP re-INVITE request from an MCVideo client

Upon receipt of a SIP re-INVITE request from an MCVideo client the non-controlling MCVideo function shall act as the controlling MCVideo function and shall perform the actions in clause 9.2.2.4.1.2.

9.2.2.5.1.7 void

9.2.2.5.1.8 Initiating a temporary group session

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

NOTE 1: The difference between a "SIP INVITE request "SIP INVITE request for controlling MCVideo function of an MCVideo group" and a "SIP INVITE request for non-controlling MCVideo function of an MCVideo group" 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;

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

NOTE 2: If the checks are not succesful, the SIP response to the "SIP INVITE request "SIP INVITE request for 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-id> element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the "SIP INVITE request for controlling MCVideo function of an MCVideo group" as specified in clause 6.3.5.2, if the MCVideo user is unauthorized to join a chat group session, the non-controlling MCVideo function shall send a SIP 403 (Forbidden) response with the warning text set to "106 user not authorised to join chat group" in a Warning header field as specified in clause 4.4.

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

9) 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 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; and

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.

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) perform the actions in the clause 9.2.1.5.2.4.

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.