6.1.1 Pre-Arranged Group Call

36.579-63GPPMission Critical (MC) services over LTEPart 6: Mission Critical Video (MCVideo) User Equipment (UE) Protocol conformance specificationRelease 15TS

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

6.1.1.1 On-network / On-demand Pre-arranged Group Call / Automatic Commencement Mode / Transmission Control / Upgrade to Emergency Group Call / Cancel Emergency State / Upgrade to Imminent Peril Group Call / Cancel Imminent Peril State / Client Originated (CO)

6.1.1.1.1 Test Purpose (TP)

(1)

with { the UE (MCVideo Client) registered and authorised for MCVideo Service }

ensure that {

when { the MCVideo User requests the establishment of an MCVideo On-demand Pre-arranged Group Call forcing Automatic Commencement Mode and implicit Transmission Control }

then { the UE (MCVideo Client) requests an On-demand Automatic Commencement Mode Pre-arranged Group Call establishment with implicit Transmission Control by sending a SIP INVITE message, and, after indication from the SS (MCVideo Server) that the call was established, provides transmission granted notification to the MCVideo User }

}

(2)

with { the UE (MCVideo Client) having established a MCVideo On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the MCVideo User engages in communication with the invited MCVideo User(s) }

then { the UE (MCVideo Client) respects the Transmission Control imposed by the SS (MCVideo Server) (Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission End Response, Transmission Idle) }

}

(3)

with { the UE (MCVideo Client) having established an On-demand Pre-arranged Group Call with Automatic Commencement Mode and the MCVideo User being authorized for initiating a MCVideo Emergency Group Call }

ensure that {

when {the MCVideo User requests to upgrade the ongoing MCVideo Group Call to an MCVideo Emergency Group Call with Transmission Control }

then { the UE (MCVideo Client) sends a SIP re-INVITE request and upon receipt of a SIP 2xx response considers the call as being upgraded to Emergency Group Call and notifies the MCVideo User }

}

(4)

with { the UE (MCVideo Client) having upgraded to an Emergency Group Call }

ensure that {

when { the MCVideo User continues communication with the invited MCVideo User(s) }

then { the UE (MCVideo Client) respects the Transmission Control imposed by the SS (MCVideo Server) }

}

(5)

with { the UE (MCVideo Client) having upgraded an On-demand Pre-arranged Group Call with Automatic Commencement Mode to an Emergency Group Call and the MCVideo User being authorized for cancelling an MCVideo Emergency state (MCVideo in-progress emergency cancel) }

ensure that {

when { the MCVideo User requests to cancel the ongoing MCVideo Emergency state }

then { the UE (MCVideo Client) sends a SIP re-INVITE request and upon receipt of a SIP 2xx response considers the emergency condition cancelled, and notifies the user }

}

(6)

ensure that {

when { the MCVideo User requests to upgrade the ongoing MCVideo Group Call to a MCVideo Imminent Peril Group Call with Transmission Control }

then { the UE (MCVideo Client) sends a SIP re-INVITE request and upon receipt of a SIP 2xx response considers the call as being upgraded to Imminent Peril Group Call, and notifies the user }

}

(7)

with {the UE (MCVideo Client) having upgraded to an Imminent Peril Group Call}

ensure that {

when {the MCVideo User continues communication with the invited MCVideo User(s)}

then {the UE (MCVideo Client) respects the Transmission Control imposed by the SS (MCVideo Server) }

}

(8)

with {the UE (MCVideo Client) having upgraded an On-demand Pre-arranged Group Call with Automatic Commencement Mode to an Imminent Peril Group Call and the MCVideo User being authorized for cancelling a MCVideo Imminent Peril state (MCVideo In-Progress Imminent Peril Cancel) }

ensure that {

when {the MCVideo User requests to cancel the ongoing MCVideo Imminent Peril state }

then {the UE (MCVideo Client) sends a SIP re-INVITE request and upon receipt of a SIP 2xx response considers the Imminent Peril condition cancelled, and notifies the user }

}

(9)

with {the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when {the MCVideo User requests to terminate the ongoing MCVideo Group Call}

then {the UE (MCVideo Client) sends a Transmission End Request, acknowledges the Transmission End Response from the SS (MCVideo Server), and sends a SIP BYE message, and leaves the MCVideo Session }

}

6.1.1.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in TS 24.281, clauses 6.2.3.1.2, 6.2.3.1.1, 9.2.1.2.1.1, 9.2.1.2.1.3, 9.2.1.2.1.4, 9.2.1.2.1.5, 9.2.1.2.1.6, 9.2.1.3.3.1, 9.2.1.4.7, 9.2.1.4.8; and TS 24.581, clauses 6.2.4.4.6, 6.3.4.3.6, 6.3.4.4.12, 6.3.5.3.9, 6.3.5.4.8. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated, these are Rel-15 requirements.

[TS 24.281, clause 6.2.3.1.2]

When performing the automatic commencement mode procedures, the MCVideo client shall follow the procedures in subclause 6.2.3.1.1 with the following clarification:

– The MCVideo client may include a P-Answer-State header field with the value "Confirmed" as specified in IETF RFC 4964 [30] in the SIP 200 (OK) response.

[TS 24.281, clause 6.2.3.1.1]

When performing the automatic commencement mode procedures, the MCVideo client:

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

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

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

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

5) 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]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";

6) shall, if the incoming SIP INVITE request contains a Replaces header field, include in the SDP answer in the SIP 200 (OK) response to the SDP offer the parameters used for the pre-established session identified by the contents of the Replaces header field;

7) shall, if the incoming SIP INVITE request does not contain a Replaces header field, 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 subclause 6.2.2;

NOTE: In the case of a new emergency call where the terminating client is using a pre-established session, the SIP INVITE request containing a Replaces header is used to replace the pre-established session.

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

9) shall, if the incoming SIP INVITE request contains a Replaces header field, release the pre-established session identified by the contents of the Replaces header field; and

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

When NAT traversal is supported by the MCVideo client and when the MCVideo client is behind a NAT, generation of SIP responses is done as specified in this subclause and as specified in IETF RFC 5626 [35].

[TS 24.281, clause 9.2.1.2.1.1]

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

The MCVideo client:

1) if the MCVideo user has requested the origination of an MCVideo emergency group call or is originating an MCVideo prearranged group call and the MCVideo emergency state is already set, the MCVideo client shall comply with the procedures in subclause 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 subclause 6.2.8.1.9;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) if the group identity can be determined to be a TGI and if the MCVideo client can associate the TGI with a MCVideo group ID, the <associated-group-id> element set to the MCVideo group ID;

NOTE 3: The text "can associate the TGI with a MCVideo group ID" means that the MCVideo client is able to determine that there is a constituent group of the temporary group that it is a member of.

NOTE 4: The MCVideo client is informed about temporary groups and regrouping of MCVideo groups that the user is a member of as specified in 3GPP TS 24.481 [24].

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

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

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

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

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

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

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

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

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

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

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

the MCVideo client shall perform the actions specified in subclause 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 subclause 6.2.8.1.13

[TS 24.281, clause 9.2.1.2.1.3]

This subclause covers both on-demand session.

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

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

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

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

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

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

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

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 populated as specified in subclause 6.2.8.1.1;

b) if an indication of an MCVideo emergency alert is to be included, shall perform the procedures specified in subclause 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 subclause 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 populated as specified in subclause 6.2.8.1.9; and

b) shall include a Resource-Priority header field and comply with the procedures in subclause 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 subclause 6.2.1;

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

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

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

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

2) shall perform the actions specified in subclause 6.2.8.1.4.

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

[TS 24.281, clause 9.2.1.2.1.4]

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

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

The MCVideo client:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4) if the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending", the sent SIP re-INVITE request did not contain an <originated-by> element in the application/vnd.3gpp.mcvideo-info+xml MIME body and the SIP 2xx response to the SIP request for a priority group call does not contain a Warning header field as specified in subclause 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.

[TS 24.281, clause 9.2.1.2.1.5]

This subclause covers on-demand session.

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

The MCVideo client:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, clause 9.2.1.2.1.6]

This subclause covers both on-demand session.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, clause 9.2.1.3.3.1]

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

[TS 24.281, clause 9.2.1.4.7]

In the procedures in this subclause:

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

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

Upon receipt of a SIP re-INVITE request for an MCVideo session identity identifying an on-demand prearranged MCVideo group session, the controlling MCVideo function:

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

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

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

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

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

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

4) if the received SIP re-INVITE request contains an imminent peril indication set to "true" for an MCVideo imminent peril group call and this is an unauthorized request for an MCVideo imminent peril group call as determined by subclause 6.3.3.1.13.6, 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 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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Editor’s Note: timers need to be defined.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "true" and if this is an unauthorized request for an MCVideo emergency alert as determined by subclause 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 subclause 4.4;

6) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false" and if this is an unauthorized request for an MCVideo emergency alert cancellation as determined by subclause 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 subclause 4.4;

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

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

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

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

Upon 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 subclause 4.4, the controlling MCVideo function shall follow the procedures in subclause 6.3.3.1.18.

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

[TS 24.281, clause 9.2.1.4.8]

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

In the procedures in this subclause:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) skip the rest of the steps;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.581, clause 6.2.4.4.6]

Upon receiving a Transmission Granted message from the transmission control server, the transmission participant:

1. if the first bit in the subtype of the Transmission Granted message is set to ‘1’ (Acknowledgment is required) as described in subclause 9.2.2.1, shall send a Transmission control Ack message. The Transmission control Ack message:

a. shall include the Message Type field set to ‘0’ (Transmission Granted); and

b. shall include the Source field set to ‘0’ (the transmission participant is the source);

2. shall store the SSRC of granted transmission participant received in the Transmission Granted message and use it in the RTP media packets until the transmission is relased;

3. shall provide Transmission granted notification to the user, if not already done;

4. shall stop timer T100 (Transmission Request); and

5. shall enter the ‘U: has permission to transmit’ state.

[TS 24.581, clause 6.3.4.3.6]

Upon receiving an implicit Transmission request due to an upgrade to an emergency group call or due to an upgrade to imminent peril call, the transmission control arbitration logic in the transmission control server:

1. shall reject the request if there is only one MCVideo client in the MCVideo call;

2. if the Transmission request is rejected the transmission control server:

a. shall send the Transmission Reject message. The Transmission Reject message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #3 (Only one participant); and

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the Transmission request in the <Reject Phrase> value; and

b. shall remain in the ‘G: Transmit Idle’ state; and

3. if the Transmission request is granted the transmission control server:

a. shall stop the timer T1 (Inactivity);

b. shall stop the timer T2 (Transmit Idle);

c. shall store the SSRC of transmission participant granted the permission to send media until the transmission is released associated to that Transmission request; and

d. shall enter the ‘G: Transmit Taken’ state as specified in the subclause 6.3.4.4.2.

[TS 24.581, clause 6.3.4.4.12]

1. if counter Cx (Simultaneous transmission video) has not reached its upper limit:

a. shall perform the actions specified in the subclause 6.3.4.4.2;

2. if counter Cx (Simultaneous transmission video) has reached its upper limit:

a. select one of the transmission participants with permission to send media without the pre-emptive priority or low effective priority;

b. shall stop timer T4 (Transmission Grant), if running;

c. shall set the Reject Cause field in the Transmission Revoke message to #4 (Media Transmission pre-empted);

d. shall enter the ‘G: pending Transmission Revoke’ state as specified in the subclause 6.3.4.5.2;

e. shall insert the transmission participant into the active Transmission request queue to the position in front of all queued requests, if not inserted yet or update the position of the transmission participant in the active Transmission request queue to the position in front of all other queued requests, if already inserted; and

f. shall send a Transmission Queue Position Info message to the requesting transmission participant, if negotiated support of queueing Transmission requests as specified in clause 14. The Queue Position Request message:

i. shall include the queue position and transmission priority in the Queue Info field; and

ii. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Transmission Indicator field with appropriate indications.

[TS 24.581, clause 6.3.5.3.9]

When an ongoing session is upgraded to an emergency group call and when the application and signalling plane indicates that a subsequent SDP offer included the "mc_implicit_request" fmtp attribute as described in clause 14, the transmission control interface towards the MCVideo client in the transmission control server:

1. shall indicate to the transmission control server arbitration logic that an implicit Transmission request is received due to an upgrade to an emergency group call; and

2. shall remain in the ‘U: not permitted and Transmit Idle’ state.

[TS 24.581, clause 6.3.5.4.8]

When an ongoing session is upgraded to an emergency group call and when the application and signalling plane indicates that a subsequent SDP offer included the "mc_implicit_request" fmtp attribute as specified in clause 14, the transmission control interface towards the MCVideo client in the transmission control server:

1. shall indicate to the transmission control server arbitration logic that an implicit Transmission request is received due to an upgrade to an emergency group call; and

2. shall remain in the ‘U: not permitted and Transmit Taken’ state.

6.1.1.1.3 Test description

6.1.1.1.3.1 Pre-test conditions

System Simulator:

– SS (MCVideo server)

– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCVideo operation in the MCVideo configuration document).

IUT:

– UE (MCVideo Client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCVideo UE registration as specified in TS 36.579-1 [2], subclause 5.4.2A.

– The MCVideo User performs the Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCVideo Client Application has been activated and User has registered-in as the MCVideo User with the Server as active user at the Client.

6.1.1.1.3.2 Test procedure sequence

Table 6.1.1.1.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCVideo User request the establishment of an MCVideo On-demand Pre-arranged Group Call using, Automatic Commencement Mode, with request for implicit Transmission Control. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ according to option b,ii of NOTE 1 as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to establish an MCVideo On-demand Pre-arranged Group Call, Automatic Commencement Mode, with implicit Transmission Control?	–	–	1,2	P
3-7	Void	–	–	–	–
8	Check: Does the UE (MCVideo Client) provide transmission granted notification to the MCVideo User? (NOTE 1)	–	–	1	P
8A	Make the MCVideo User request to end the transmission. (NOTE 1)	–	–	–	–
8B	Check Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo transmission End Request CO’ as described in TS 36.579-1 [2] Table 5.3B.7.3-1?	–	–	2	P
9	Make the MCVideo User request to upgrade the Pre-arranged Group Call to an MCVideo Emergency Group Call. (NOTE 1)	–	–	–	–
10	Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session modification’ as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to upgrade the On-demand Pre-arranged Group Call to an MCVideo Emergency Group Call with implicit transmit media request?	–	–	3,4	P
11-15	Void	–	–	–	–
16	Check: Does the UE (MCVideo Client) provide notification to the MCVideo User that the Pre-arranged Group Call has been upgraded to an Emergency condition? (NOTE 1)	–	–	3	P
16A	Make the MCVideo User request to end the transmission. (NOTE 1)	–	–	–	–
16B	Check Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo transmission End Request CO’ as described in TS 36.579-1 [2] Table 5.3B.7.3-1?	–	–	4	P
17	Make the MCVideo User request to cancel the Emergency State. (NOTE 1)	–	–	–	–
18	Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session modification’ as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to cancel the Emergency condition in the On-demand Pre-arranged Group Call without implicit transmit media request?	–	–	5, 2	P
19-23	Void	–	–	–	–
24	Check: Does the UE (MCVideo Client) provide notification to the MCVideo User that the Pre-Arranged Group Call has been downgraded from an Emergency condition to a normal group call? (NOTE 1)	–	–	5	P
24A-24B	Void	–	–	–	–
25	Make the MCVideo User upgrade the Pre-arranged Group Call to an MCVideo Imminent Peril Group Call. (NOTE 1)	–	–	–	–
26	Check: Does the UE (MCVideo Client) c correctly perform test procedure ‘MCVideo CO session modification’ as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to upgrade the On-demand Pre-arranged Group Call to MCVideo Imminent Peril Group Call with implicit transmit media request?	–	–	6, 7	P
27-31	Void	–	–	–	–
32	Check: Does the UE (MCVideo Client) provide notification to the MCVideo User that the Pre-arranged Group Call has been upgraded to an Imminent Peril state? (NOTE 1)	–	–	6	P
32A	Make the MCVideo User request to end the transmission. (NOTE 1)	–	–	–	–
32B	Check Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo transmission End Request CO’ as described in TS 36.579-1 [2] Table 5.3B.7.3-1?	–	–	4	P
33	Make the MCVideo User request to downgrade the Imminent Peril state. (NOTE 1)	–	–	–	–
34	Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session modification’ as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to cancel the Imminent Peril condition in the On-demand Pre-arranged Group Call without implicit transmit media request?	–	–	8, 2	P
35-39	Void	–	–	–	–
40	Check: Does the UE (MCVideo Client) provide notification to the MCVideo User that the Imminent Peril state has been downgraded? (NOTE 1)	–	–	8	P
41-45	Void	–	–	–	–
46	Make the MCVideo User request to end the Group Call. (NOTE 1)	–	–	–	–
47	Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCX CO call release’ as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the On-demand Pre-arranged Group Call?	–	–	9	P
48	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation-dependent MMI.

6.1.1.1.3.3 Specific message contents

Table 6.1.1.1.3.3-1: SIP INVITE from the UE (Step 2, Table 6.1.1.1.3.2-1;
Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.1.1.1.3.3-1A
MIME body part		MCVideo-Info
MIME-part-body	MCVideo-Info as described in Table 6.1.1.1.3.3-2

Table 6.1.1.1.3.3-1A: SDP message in SIP INVITE (Table 6.1.1.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition INITIAL_SDP_OFFER, IMPLICIT_GRANT_REQUESTED

Table 6.1.1.1.3.3-2: MCVideo-Info in SIP INVITE (Table 6.1.1.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition GROUP-CALL, INVITE_REFER

Table 6.1.1.1.3.3-3: SIP 200 (OK) from the SS (Step 2, Table 6.1.1.1.3.2-1;
Step 4, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP Message	As described in Table 6.1.1.1.3.3-3A

Table 6.1.1.1.3.3-3A: SDP message in SIP 200 (OK) (Table 6.1.1.1.3.3-3)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2, conditions SDP_ANSWER, IMPLICIT_GRANT_REQUESTED

Table 6.1.1.1.3.3-4..5: Void

Table 6.1.1.1.3.3-6: SIP INVITE from the UE (Step 10, Table 6.1.1.1.3.2-1;
Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition EMERGENCY-CALL, re_INVITE
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.1.1.1.3.3-6A
MIME body part		MCVideo-Info
MIME-part-body	MCVideo-Info as described in Table 6.1.1.1.3.3-7

Table 6.1.1.1.3.3-6A: SDP message in SIP INVITE (Table 6.1.1.1.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition SDP_OFFER, IMPLICIT_GRANT_REQUESTED

Table 6.1.1.1.3.3-7: MCVideo-Info in SIP INVITE (Table 6.1.1.1.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition GROUP-CALL, EMERGENCY-CALL, INVITE_REFER

Table 6.1.1.1.3.3-8: SIP 200 (OK) from the SS (Steps 10, 26, Table 6.1.1.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP Message	As described in Table 6.1.1.1.3.3-8A

Table 6.1.1.1.3.3-8A: SDP message in SIP 200 (OK) (Table 6.1.1.1.3.3-8)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2 condition SDP_ANSWER, IMPLICIT_GRANT_REQUESTED

Table 6.1.1.1.3.3-9: Transmission Granted from the SS (Step 10, Table 6.1.1.1.3.2-1;
Step 5a1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ACK, EMERGENCY-CALL

Table 6.1.1.1.3.3-9A: Transmission Idle from the SS (Step 16B, Table 6.1.1.1.3.2-1;
Step 4, TS 36.579-1 [2] Table 5.3B.7.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.16-1, condition EMERGENCY-CALL

Table 6.1.1.1.3.3-10: SIP INVITE from the UE (Step 18, Table 6.1.1.1.3.2-1;
Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition re_INVITE
Information Element		Value/remark		Comment	Reference	Condition
Message-body
MIME body part			SDP message
MIME-part-body	SDP Message as described in Table 6.1.1.1.3.3-10A
MIME body part			MCVideo-Info
MIME-part-body	MCVideo-Info as described in Table 6.1.1.1.3.3-11

Table 6.1.1.1.3.3-10A: SDP message in SIP INVITE (Table 6.1.1.1.3.3-10)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition SDP_OFFER

Table 6.1.1.1.3.3-11: MCVideo-Info in SIP INVITE (Table 6.1.1.1.3.3-10)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition GROUP-CALL, INVITE_REFER
Information Element	Value/remark	Comment	Reference	Condition
mcvideoinfo
mcvideo-Params
emergency-ind	"false"

Table 6.1.1.1.3.3-11A: SIP 200 (OK) from the SS (Steps 18, 34, Table 6.1.1.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
SDP Message	As described in Table 6.1.1.1.3.3-11B

Table 6.1.1.1.3.3-11B: SDP message in SIP 200 (OK) (Table 6.1.1.1.3.3-11A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2 condition SDP_ANSWER

Table 6.1.1.1.3.3-12: SIP INVITE from the UE (Step 26, Table 6.1.1.1.3.2-1;
Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition IMMPERIL-CALL, re_INVITE
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.1.1.1.3.3-12A
MIME body part		MCVideo-Info
MIME-part-body	MCVideo-Info as described in Table 6.1.1.1.3.3-13

Table 6.1.1.1.3.3-12A: SDP message in SIP INVITE (Table 6.1.1.1.3.3-12)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition SDP_OFFER, IMPLICIT_GRANT_REQUESTED

Table 6.1.1.1.3.3-13: MCVideo-Info in SIP INVITE (Table 6.1.1.1.3.3-12)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition GROUP-CALL, IMMPERIL-CALL, INVITE_REFER

Table 6.1.1.1.3.3-14: Void

Table 6.1.1.1.3.3-15: Transmission Granted from the SS (Step 26, Table 6.1.1.1.3.2-1;
Step 5a1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ACK, IMMPERIL-CALL

Table 6.1.1.1.3.3-15A: Transmission Idle from the SS (Step 32B, Table 6.1.1.1.3.2-1;
Step 4, TS 36.579-1 [2] Table 5.3B.7.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.16-1, condition IMMPERIL-CALL

Table 6.1.1.1.3.3-16..17: Void

Table 6.1.1.1.3.3-17A: SIP INVITE from the UE (Step 34, Table 6.1.1.1.3.2-1;
Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition re_INVITE
Information Element		Value/remark		Comment	Reference	Condition
Message-body
MIME body part			SDP message
MIME-part-body	SDP Message as described in Table 6.1.1.1.3.3-17B
MIME body part			MCVideo-Info
MIME-part-body	MCVideo-Info as described in Table 6.1.1.1.3.3-17C

Table 6.1.1.1.3.3-17B: SDP message in SIP INVITE (Table 6.1.1.1.3.3-17A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition SDP_OFFER

Table 6.1.1.1.3.3-17C: MCVideo-Info in SIP INVITE (Table 6.1.1.1.3.3-17A)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition GROUP-CALL, INVITE_REFER
Information Element	Value/remark	Comment	Reference	Condition
mcvideoinfo
mcvideo-Params
imminentperil-ind	"false"

Table 6.1.1.1.3.3-18..19: Void

6.1.1.2 On-network / On-demand Pre-arranged Group Call / Automatic Commencement Mode / Reception Control / Upgrade to Emergency Group Call / Cancel Emergency State / Upgrade to Imminent Peril Group Call / Cancel Imminent Peril State / Client Terminated (CT)

6.1.1.2.1 Test Purpose (TP)

(1)

with { the UE (MCVideo Client) registered and authorised for MCVideo }

ensure that {
when { the UE (MCVideo Client) receives a SIP INVITE from the SS (MCVideo Server)to initiate an On-demand Pre-arranged Group Call with Automatic Commencement Mode and implicit Reception Control }

then { the UE (MCVideo Client) responds by sending a SIP 200 (OK) }

}

(2)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode}

ensure that {

when { the UE (MCVideo Client) receives a Media Transmission Notification message from the SS (MCVideo Server) }

then {the UE (MCVideo Client) provides media transmission notification to the MCVideo User }

}

(3)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the MCVideo User requests permission to receive media }

then { The UE (MCVideo Client) sends a Receive Media Request message to the SS (MCVideo Server) and notifies the MCVideo User of the successful Receive Media Request upon receipt of a Receive Media Response message from the SS (MCVideo Server) and respects the Reception Control imposed by the SS (MCVideo Server) (Media Transmission Notification, Receive Media Request, Receive Media Response, Media Reception End Request, Media Reception End Response }

(4)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCVideo Client) receives a SIP re-INVITE from the SS (MCVideo Server) to upgrade the ongoing MCVideo Group Call to a MCVideo Emergency Group Call with Reception Control }

then { the UE (MCVideo Client) responds to the SIP re-INVITE request with a SIP 200 (OK) and considers the call as being upgraded to an Emergency Group) }

}

(5)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode that was upgraded to an Emergency Group Call}

ensure that {

when { the UE (MCVideo Client)receives a SIP re-INVITE from the SS (MCVideo Server) to cancel the ongoing MCVideo Emergency state}

then { the UE (MCVideo Client) responds to the SIP re-INVITE request with a SIP 200 (OK) and considers the emergency state cancelled }

}

(6)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCVideo Client)receives a SIP re-INVITE from the SS (MCVideo Server) to upgrade the ongoing MCVideo Group Call to a MCVideo Imminent Peril Group Call with Reception Control }

then { the UE (MCVideo Client) responds to the SIP re-INVITE request with a SIP 200 (OK) response and considers the call as being upgraded to an Imminent Peril Group Call }

}

(7)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode that was upgraded to an Imminent Peril Group Call }

ensure that {

when { the UE (MCVideo Client)receives a SIP re-INVITE from the SS (MCVideo Server) to cancel the ongoing MCVideo Imminent Peril state }

then { the UE (MCVideo Client) responds to the SIP re-INVITE request with a SIP 200 (OK) and considers the Imminent Peril state cancelled }

}

(8)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the MCVideo User requests to end the RTP media reception }

then { the UE (MCVideo Client) sends a Media Reception End Request message }

}

(9)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

when { the UE (MCVideo Client) receives a SIP BYE message }

then { the UE (MCVideo Client) sends a SIP 200 (OK) message and leaves the MCVideo session }

}

6.1.1.2.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in: TS 24.281, clauses 6.2.3.1.1, 6.2.3.1.2, 9.2.1.2.1.2, 9.2.1.2.1.4, 9.2.1.2.1.6, ; also TS 24.581, clauses 6.3.4.3.6, 6.3.4.4.12, 6.3.5.3.9, 6.3.5.4.8. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated, these are Rel-15 requirements.