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

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)

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 Imminent Peril Group Call }

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

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

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]

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. 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.2A.

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

EXCEPTION: The E-UTRA/EPC actions which are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo Client) send an initial SIP INVITE requesting the establishment of an MCVideo On-demand Pre-arranged Group Call, Automatic Commencement Mode, with implicit Transmission Control?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) responds to the UE (MCVideo Client) with a SIP 100 (Trying) message.

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client), indicating that it has accepted the SIP INVITE request from the UE (MCVideo Client).

<–

SIP 200 (OK)

5

Check: Does the UE (MCVideo Client) send an acknowledgement to the SS (MCVideo Server)?

–>

SIP ACK

1

P

6

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client).

<–

Transmission Granted

7

Check: Does the UE (MCVideo Client) send a Transmission Control ACK in response to Transmission Granted message from the SS (MCVideo Server)?

–>

Transmission Control ACK

2

P

8

Check: Does the UE (MCVideo Client provide transmission granted notification to the MCVideo User?

(NOTE 1)

1

P

9

Make the MCVideo User request to upgrade the Pre-arranged Group Call to a MCVideo Emergency Group Call.

(NOTE 1)

10

Check: Does the UE (MCVideo Client) send a SIP re-INVITE message to upgrade the On-demand Pre-arranged Group Call to a MCVideo Emergency Group Call?

–>

SIP re-INVITE

3

P

11

The SS (MCVideo Server) sends a SIP 100 (Trying) message to the UE (MCVideo Client).

<–

SIP 100 (Trying)

12

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client).

<–

SIP 200 (OK)

13

Check: Does the UE (MCVideo Client) send an acknowledgement to the SS (MCVideo Server)?

–>

SIP ACK

2

P

14

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client).

<–

Transmission Granted

15

Check: Does the UE (MCVideo Client) send a Transmission Control Ack message acknowledging the Transmission Granted message from the SS (MCVideo Server)?

–>

Transmission Control Ack

4

P

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

17

Make the MCVideo User request to cancel the MCVideo Emergency Group Call.

(NOTE 1)

18

Check: Does the UE (MCVideo Client) send a SIP re-INVITE message to cancel the Emergency condition in the On-demand Pre-arranged Group Call?

–>

SIP re-INVITE

5

P

19

The SS (MCVideo Server) sends a SIP 100 (Trying) message to the UE (MCVideo Client).

<–

SIP 100 (Trying)

20

The SS (MCVideo Server) sends a SIP 200 (OK) to the UE (MCVideo Client) indicating that it has accepted the SIP re-INVITE request to cancel the emergency condition.

<–

SIP 200 (OK)

21

Check: Does the UE (MCVideo Client) send an acknowledgement to the SS (MCVideo Server)?

–>

SIP ACK

22

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client).

<–

Transmission Granted

23

Check: Does the UE (MCVideo Client) send a Transmission Control Ack message in response to the SS Transmission Granted message?

–>

Transmission Control Ack

2

P

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

25

Make the MCVideo User upgrade the Pre-arranged Group Call to a MCVideo Imminent Peril Group Call.

(NOTE 1)

26

Check: Does the UE (MCVideo Client) send a SIP re-INVITE message to upgrade the On-demand Pre-arranged Group Call to MCVideo Imminent Peril Group Call?

–>

SIP re-INVITE

6

P

27

The SS (MCVideo Server) sends a SIP 100 (Trying) message to the UE (MCVideo Client).

<–

SIP 100 (Trying)

28

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client) indicating that it has accepted the SIP re-INVITE request to upgrade to the Imminent Peril condition.

<–

SIP 200 (OK)

29

Check Does the UE (MCVideo Client) send an acknowledgement to the SS (MCVideo Server) ?

–>

SIP ACK

6

P

30

The SS (MCVideo Server) then sends a Transmission Granted message to the UE (MCVideo Client).

<–

Transmission Granted

31

Check: Does the UE (MCVideo Client) send a Transmission Control Ack message in response to the Transmission Granted message from the SS (MCVideo Server)?

–>

Transmission Control Ack

7

P

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

33

Make the MCVideo User request to downgrade the Imminent Peril state.

(NOTE 1)

34

Check: Does the UE (MCVideo Client) send a SIP re-INVITE message to cancel the Imminent Peril condition in the On-demand Pre-arranged Group Call?

–>

SIP re-INVITE

8

P

35

The SS (MCVideo Server) responds to the UE (MCVideo Client) with a SIP 100 (Trying) message.

<–

SIP 100 (Trying)

36

The SS (MCVideo Server) sends a SIP 200 (OK) indicating that it has accepted the SIP re-INVITE request to downgrade to the Imminent Peril condition.

<–

SIP 200 (OK)

37

The UE MCVideo Client) sends an acknowledgement to the SS (MCVideo Server).

–>

SIP ACK

38

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client) with an acknowledgement required

<–

Transmission Granted

39

Check: Does the UE (MCVideo Client) send a Transmission Control Ack message in response to the SS (MCVideo Server) Transmission Granted message?

–>

Transmission Control Ack

2

P

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

Make the MCVideo User request to end the transmission.

(NOTE 1)

42

Check Does the UE (MCVideo Client) send a Transmission Request indicating that it wants to terminate a MCVideo On-demand Pre-arranged Group Call, Automatic Commencement Mode, with implicit Transmission Control?

–>

Transmission End Request

9

P

43

The SS (MCVideo Server) sends a Transmission End Response message to the UE (MCVideo Client) to verify that the UE (MCVideo Client) is able to end an MCVideo On-demand Pre-arranged Group Call, Automatic Commencement Mode, with implicit Transmission Control.

<–

Transmission End Response

44

Check: Does the UE (MCVideo Client) send a Transmit Control ACK message in response to the Transmission End Response message?

–>

Transmission Control ACK

2

P

45

The SS (MCVideo Server) sends a Transmission Idle message.

<–

Transmission Idle

46

Make the MCVideo User request to end the Group Call.

(NOTE 1)

47

Check: Does the UE (MCVideo Client) send a SIP BYE message to end the On-demand Pre-arranged Group Call?

–>

SIP BYE

9

P

48

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client) to indicate acceptance to end the Group Call.

<–

SIP 200 (OK)

EXCEPTION: The SS waits 2 seconds before the SS releases the RRC connection.

NOTE: The specified wait period of 2s shall ensure that lower layer signalling (TCP) is finished and any not allowed behaviour captured.

NOTE 1: This action 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 (Step 2, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-headers

Content-Type

"application/sdp"

MIME-part-body

SDP Message as described in Table 6.1.1.1.3.3-1A

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

"application/vnd.3gpp.mcvideo-info+xml"

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 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, conditions FIRST_SDP_FROM_UE, 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, conditions GROUP-CALL, INVITE_REFER

Table 6.1.1.1.3.3-3: SIP 200 (OK) (Steps 4, 20, 36, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.1.3.3-3A

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

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

Table 6.1.1.1.3.3-4: Transmission Granted (Steps 6, 22, 38, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Subtype

“10000”

Server client

A ‘1’ in the first bit indicates acknowledgement is required.

TS 24.581 [88] 9.2.2.1-2

Table 6.1.1.1.3.3-5: Transmission Control Ack (Steps 7, 15, 23, 31, 39, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

"00010000"

Transmission Control Ack message for Transmission Granted message which requested acknowledgment.

Table 6.1.1.1.3.3-6: SIP re-INVITE (Step 10, Table 6.1.1.1.3.2.1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO, EMERGENCY-CALL, re_INVITE, MOCALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-Info

MIME-part-header

MIME-part-body

As described in Table 6.1.1.1.3.3-7

Table 6.1.1.1.3.3-7: MCVideo-Info in SIP re-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

Table 6.1.1.1.3.3-8: SIP 200 (OK) (Step 12, Table 6.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.1.3.3-7

Table 6.1.1.1.3.3-9: Transmission Granted (Step 14, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Subtype

“10000”

Server client

A ‘1’ in the first bit indicates acknowledgement is required.

TS 24.581 [88] 9.2.2.1-2

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

"1001000000000000"

D = Emergency call

TS 24.581 [27], clause 9.2.5.1

Table 6.1.1.1.3.3-10: SIP re-INVITE (Step 18, 34, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO, re_INVITE, MOCALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

As described in Table 6.1.1.1.3.3-11

Table 6.1.1.1.3.3-11: MCVideo-Info in SIP re-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

Table 6.1.1.1.3.3-12: SIP re-INVITE (Step 26, Table 6.1.1.1.3.2.1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO, IMMPERIL-CALL, re_INVITE, MOCALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

As described in Table 6.1.1.1.3.3-13

Table 6.1.1.1.3.3-13: MCVideo-Info in SIP re-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

Table 6.1.1.1.3.3-14: SIP 200 (OK) (Step 28, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.1.3.3-13

Table 6.1.1.1.3.3-15: Transmission Granted (Step 30, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Subtype

“10000”

Server client

A ‘1’ in the first bit indicates acknowledgement is required.

TS 24.581 [88] 9.2.2.1-2

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

"0000100000000000"

A ‘1’ in E position = Emergency call = Imminent peril call

TS 24.581 [27], clause 9.2.5.1

Table 6.1.1.1.3.3-16: Transmission End Response (Step 43, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.2-1

Information Element

Value/remark

Comment

Reference

Condition

Subtype

"10001"

A ‘1’ in the first bit indicates acknowledgement is required.

TS 24.581 [27], clause 9.2.2.1-2

Table 6.1.1.1.3.3-17: Transmission Control Ack (Step 44, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

"00010001"

Transmission Control Ack message for Transmission End Response message which requested acknowledgment.

Table 6.1.1.1.3.3-18: SIP BYE (Step 47, Table 6.1.1.1.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MO_CALL

Table 6.1.1.1.3.3-19: SIP 200 (OK) (Step 48, Table 6.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included

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) provides media transmission notification to the MCVideo Userreceives a Media Transmission Notification message from the SS (MCVideo Server) }

then {the UE (MCVideo Client) }

}

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

[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 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 9.2.1.2.1.2]

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 an initial SIP INVITE request, the MCVideo client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [11] with the clarifications below.

The MCVideo client:

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

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

b) 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 [51] and warning texts as specified in subclause 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 subclause;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 authorised 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 authorised to cancel the in-progress emergency group state of the MCVideo group; and

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

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

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. 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.2.3 Test description

6.1.1.2.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.2A.

– 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.2.3.2 Test procedure sequence

Table 6.1.1.2.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.4A ‘Generic Test Procedure for MCVideo CT communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

1

The SS (MCVideo Server) sends a SIP INVITE message to an On-demand Pre-arranged group call with Automatic Commencement Mode to the UE (MCVideo Client).

<–

SIP INVITE

EXCEPTION: Step 2a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that takes place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message."

2a1

Check: Does the UE (MCVideo Client) responds with a SIP 100 (Trying) message.

–>

SIP 100 (Trying)

1

P

3

Check: Does the UE (MCVideo Client) answer the call with a SIP 200 (OK)?

–>

SIP 200 (OK)

1

P

4

The SS (MCVideo Server) sends a SIP ACK message to the UE (MCVideo Client).

<–

SIP ACK

5

The SS (MCVideo Server) sends a Media Reception Notification message to the UE (MCVideo Client).

<–

Media Transmission Notification

5A

Check: Does the UE (MCVideo Client) provide media transmission notification to the MCVideo User?

(NOTE 1)

2

P

6

Make the MCVideo User request permission to receive media.

(NOTE 1)

7

Check: Does the UE (MCVideo Client) send a Receive Media Request message to the SS (MCVideo Server)?

–>

Receive Media Request

3

P

8

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client).

<–

Receive Media Response

9

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1)

3

P

10

The SS (MCVideo Server) sends a SIP re-INVITE message to the UE (MCVideoClient) to upgrade the On-demand Pre-arranged Group Call to a MCVideo Emergency Group Call.

<–

SIP re-INVITE

EXCEPTION: Step 11a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that takes place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message."

11a1

The UE (MCVideo Client) responds with a SIP 100 (Trying) message.

–>

SIP 100 (Trying)

12

Check: Does the UE (MCVideo Client) respond to the SIP re-INVITE to upgrade to an Emergency state with a SIP 200 (OK)?

–>

SIP 200 (OK)

4

P

13

The SS (MCVideo Server) sends a SIP ACK to the UE (MCVideo Client).

<–

SIP ACK

14

The SS (MCVideo Server) sends a Media Transmission Notification message to the UE (MCVideo Client).

<–

Media Transmission Notification

14A

Check: Does the UE (MCVideo Client) provide receive media transmission notification to the MCVideo User?

(NOTE 1)

2

P

15

Make the MCVideo User request permission to receive media

(NOTE 1)

16

Check: Does the UE (MCVideo Client) send a Receive Media Request?

–>

Receive Media Request

3

P

17

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client).

<–

Receive Media Response

18

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1)

3

P

19

The SS (MCVideo Server) sends a SIP re-INVITE message to the UE to cancel the Emergency state.

<–

SIP re-INVITE

EXCEPTION: Step 20a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter identifies a step sequence that takes place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message."

20a1

The UE (MCVideo Client) responds with a SIP 100 (Trying) message.

–>

SIP 100 (Trying)

21

Check: Does the UE (MCVideo Client) respond to the Emergency state cancel with a SIP 200 (OK)?

–>

SIP 200 (OK)

5

P

22

The SS (MCVideo Server) sends a SIP ACK to the UE (MCVideo Client).

<–

SIP ACK

23

The SS (MCVideo Server) sends a Media Transmission Notification message to the UE (MCVideo Client).

<–

Media Transmission Notification

23A

Check: Does the UE (MCVideo Client) provide receive media transmission notification to the MCVideo User?

(NOTE 1)

2

P

24

Make the MCVideo User request permission to receive media.

(NOTE 1)

25

Check: Does the UE (MCVideo Client) respond with a Receive Media Request?

–>

Receive Media Request

3

P

26

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client).

<–

Receive Media Response

27

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1)

2

P

28

The SS (MCVideo Server) sends a SIP re-INVITE message to the UE (MCVideo Server) to upgrade the On-demand Pre-arranged Group Call to a MCVideo Imminent Peril Group Call.

<–

SIP re-INVITE

EXCEPTION: Step 29a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter identifies a step sequence that takes place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message."

29a1

Check: Does the UE (MCVideo Client) respond with a SIP 100 (Trying) message?

–>

SIP 100 (Trying)

5

P

30

Check: Does the UE (MCVideo Client) respond to the SIP re-INVITE, to upgrade to an Imminent Peril call, with a SIP 200 (OK)?

–>

SIP 200 (OK)

6

P

31

The SS (MCVideo Server) sends a SIP ACK to the UE (MCVideo Client).

<–

SIP ACK

32

The SS (MCVideo Server) sends a Media Transmission Notification message to the UE (MCVideo Client).

<–

Media Transmission Notification

33

Make the MCVideo User request permission to receive media.

(NOTE 1)

34

Check: Does the UE (MCVideo client) respond with a Receive Media Request message?

–>

Receive Media Request

2

P

35

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client).

<–

Receive Media Response

36

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1)

3

P

37

The SS (MCVideo Server) sends a SIP re-INVITE message to the UE (MCVideo Client) to cancel the Imminent Peril state.

<–

SIP re-INVITE

EXCEPTION: Step 38a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter identifies a step sequence that takes place if the UE (MCVideo Client) responds to a SIP re-INVITE message with a SIP 100 (Trying) message."

38a1

The UE (MCVideo Client) responds with a SIP 100 (Trying) message.

–>

SIP 100 (Trying)

39

Check: Does the UE (MCVideo Client) respond to the Imminent Peril state cancellation with a SIP 200 (OK) message?

–>

SIP 200 (OK)

7

P

40

SS (MCVideo Server) sends a SIP ACK message to the UE (MCVideo Client).

<–

SIP ACK

41

The SS (MCVideo Server) sends a Media Transmission Notification message from the UE (MCVideo Client) to indicate that a media reception cancelling the Imminent Peril state has been initiated to a user.

<–

Media Transmission Notification

41A

Check: Does the UE (MCVideo Client) provide receive media transmission notification to the MCVideo User?

(NOTE 1)

2

P

42

Make the MCVideo User request permission to receive media.

(NOTE 1)

43

Check: Does the UE (MCVideo Client) respond with a Receive Media Request?

–>

Receive Media Request

3

P

44

The UE (MCVideo Client) receives a Receive Media Response message from the SS (MCVideo Server).

<–

Receive Media Response

45

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1) 1

3

P

46

Make the MCVideo User request to end the RTP media reception.

(NOTE 1)

47

Check: Does the UE (MCVideo Client) send a Media Reception End Request to indicate it wants to stop RTP packet media?

–>

Media Reception End Request

8

P

48

The SS (MCVideo Server) sends a Receive Media Reception End Response message to the UE (MCVideo Client).

<–

Media Reception End Response

49

The SS (MCVideo Server) sends a Transmission Idle message.

<–

Transmission Idle

50

The SS (MCVideo Server) sends a SIP BYE message.

<–

SIP BYE

51

Check: Does the UE (MCVideo Client) send a SIP 200 (OK) message in response to the SIP BYE message?

–>

SIP 200 (OK)

9

P

EXCEPTION: The SS (MCVideo Server) releases the E-UTRA connection.

NOTE: This is expected to be done via a suitable implementation dependent MMI.

6.1.1.2.3.3 Specific message contents

Table 6.1.1.2.3.3-1: SIP INVITE (Step 1, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36-579-1 [2], Table 5.5.2.5.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.2.3.3-2

Table 6.1.1.2.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.2.3.3-1)

Derivation Path: TS 56.379-1 [2], Table 5.5.3.2.2-2, condition GROUP CALL

Table 6.1.1.2.3.3-3: SIP 200 (OK) (Steps 3, 21, 39, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, conditions INVITE-RSP, MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.1.2.3.3-2

Table 6.1.1.2.3.3-3A: SIP re-INVITE (Step 10, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, conditions MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MCVideo-Info

MIME-Content-Type

"application/vnd.3gpp.mcvideo-info+xml"

MCVideo-Info

As described in Table 6.1.1.2.3.3-5

Table 6.1.1.2.3.3-4A: SIP 200 (OK) (Step 12, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, conditions INVITE-RSP, MCVIDEO, EMERGENCY-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.1.2.3.3-5

Table 6.1.1.2.3.3-4: MCVideo-INFO in SIP re-INVITE (Table 6.1.1.2.3.3-4)

Derivation Path: TS 56.379-1 [2], Table 5.5.3.2.1-2, conditions GROUP CALL, EMERGENCY-CALL

Table 6.1.1.2.3.3-5: Void

Table 6.1.1.2.3.3-6: Void

Table 6.1.1.2.3.3-7: Void

Table 6.1.1.2.3.3-8: Void

Table 6.1.1.2.3.3-9: Void

Table 6.1.1.2.3.3-10: Receive Media Response (Step 17, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.8-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

"0001000000000000"

D = Emergency call

Table 6.1.1.2.3.3-11: SIP re-INVITE (Steps 19, 37, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MCVideo-Info

MIME-Content-Type

"application/vnd.3gpp.mcvideo-info+xml"

MCVideo-Info

As described in Table 6.1.1.2.3.3-9

Table 6.1.1.2.3.3-12: SIP re-INVITE (Step 28, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, conditions MCVIDEO, IMMPERIL-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MCVideo-Info

MIME-Content-Type

"application/vnd.3gpp.mcvideo-info+xml"

MCVideo-Info

As described in Table 6.1.1.2.3.3-11

Table 6.1.1.2.3.3-13: MCVideo-INFO in SIP re-INVITE (Table 6.1.1.2.3.3-10)

Derivation Path: TS 36.579-1, Table 5.5.3.2.2-2, conditions GROUP-CALL, IMMPERIL-CALL

Table 6.1.1.2.3.3-14: SIP 200 (OK) (Step 30, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition INVITE-RSP, MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.1.2.3.3-11

Table 6.1.1.2.3.3-15: Void

Table 6.1.1.2.3.3-16: Receive Media Response (Step 35, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.8-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

"0000100000000000"

E = Imminent peril call

Table 6.1.1.2.3.3-17: Void

Table 6.1.1.1.3.3-18: Void

Table 6.1.1.2.3.3-19: SIP BYE (Step 50, Table 6.1.1.2.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.2-1, condition MO_CALL

Table 6.1.1.2.3.3-20: SIP 200 (OK) (Step 51, Table 6.1.1.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included

6.1.1.3 On-network / On-demand Pre-arranged Group Call / Manual Commencement Mode / Client Originated (CO)

6.1.1.3.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 with Manual Commencement Mode and implicit Transmission Control }

then { the UE (MCVideo Client) requests On-demand Manual Commencement Mode Pre-arranged Group Call establishment with implicit Transmission Control by sending a SIP INVITE message }

}

(2)

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

ensure that {

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

then { the UE (MCVideo Client) provides transmission granted notification to the MCVideo User and respects the Transmission Control imposed by the SS (MCVideo Server) ( Transmission Granted, Transmission Control ACK, Transmission Idle, Transmission End Request, Transmission End Response }

}

(3)

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

ensure that {

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

then { the UE (MCVideo Client) sends a SIP BYE request and leaves the MCVideo session }

}

6.1.1.3.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in: TS 24.281, clauses 9.2.1.2.1.1, 6.2.1, and 6.4; also TS 24.581, clauses 6.2.1, 6.2.2, 12.1.2.1, 12.1.2.2, 14.2.1, 14.2.4, and 14.2.5. . 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 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:

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

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

[TS 24.281, clause 6.2.1]

The SDP offer shall contain two SDP media-level sections for MCVideo video media according to 3GPP TS 24.229 [11] and, if transmission control shall be used during the session, shall contain one SDP media-level section for a media- transmission control entity according to 3GPP TS 24.581 [5].

When composing an SDP offer according to 3GPP TS 24.229 [11] the MCVideo client:

1) shall set the IP address of the MCVideo client for the offered MCVideo video media stream and, if transmission control shall be used, for the offered media-transmission control entity;

NOTE: If the MCVideo client is behind a NAT the IP address and port included in the SDP offer can be a different IP address and port than the actual IP address and port of the MCVideo client depending on the NAT traversal method used by the SIP/IP Core.

2) shall include an "m=audio" media-level section for the MCVideo media stream consisting of:

a) the port number for the media stream selected; and

b) the codec(s) and media parameters and attributes with the following clarification:

i) if the MCVideo client is initiating a call to a group identity;

ii) if the <preferred-voice-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [24] containing an <encoding> element with a "name" attribute; and

iii) if the MCVideo client supports the encoding name indicated in the value of the "name" attribute;

then the MCVideo client:

i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [2]; and

c) "i=" field set to "audio component of MCVideo" according to 3GPP TS 24.229 [11];

3) shall include an "m=video" media-level section for the MCVideo media stream consisting of:

a) the port number for the media stream selected; and

b) the codec(s) and media parameters and attributes with the following clarification:

i) if the MCVideo client is initiating a call to a group identity;

ii) if the <preferred-video-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [24] containing an <encoding> element with a "name" attribute; and

iii) if the MCVideo client supports the encoding name indicated in the value of the "name" attribute;

then the MCVideo client:

i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [2]; and

c) "i=" field set to "video component of MCVideo" according to 3GPP TS 24.229 [11];

4) if transmission control shall be used during the session, shall include an "m=application" media-level section as specified in 3GPP TS 24.581 [5] clause 12 for a media-transmission control entity, consisting of:

a) the port number for the media-transmission control entity selected as specified in 3GPP TS 24.581 [5]; and

b) the ‘fmtp’ attributes as specified in 3GPP TS 24.581 [5] clause 14; and

5) if end-to-end security is required for a private call and the SDP offer is not for establishing a pre-established session, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [34].

[TS 24.281, clause 6.4]

An initial SIP INVITE request fulfilling the following criteria shall be regarded by the MCVideo server as an implicit transmit media request by the originating MCVideo client when the MCVideo client:

1) initiates an MCVideo session; and

2) includes the "mc_implicit_request" ‘fmtp’ attribute in the associated UDP stream for the transmission control in the SDP offer/answer as specified in 3GPP TS 24.581 [5] clause 12.

A SIP re-INVITE request fulfilling the following criteria shall be regarded by the MCVideo server as an implicit transmit media request when the MCVideo client:

1) performs an upgrade of:

a) an MCVideo group call to an emergency MCVideo group call;

b) an MCVideo group call to an imminent peril MCVideo group call; and

2) includes the "mc_implicit_request" ‘fmtp’ attribute in the associated UDP stream for the transmission control in the SDP offer/answer as specified in 3GPP TS 24.581 [5] clause 12.

In all other cases the SIP (re-)INVITE request shall be regarded as received without an implicit transmit media request.

[TS 24.581, clause 6.2.1]

Based on the negotiations during the call establishment specified in 3GPP TS 24.281 [2], a new instance of the ‘Transmission participant state transition diagram for basic transmission control operation’, as specified in subclause 6.2.4 and a new instance of the ‘Transmission participant state transition diagram for basic reception control operation’ as specified in subclause 6.2.5, shall be created for this call.

The SIP INVITE request sent by the application and signalling plane:

1. shall be regarded an implicit Transmission request when an implicit Transmission request is negotiated; and

2. shall not be regarded as an implicit Transmission request in case of a rejoin to an already on-going group call.

NOTE: The transmission participant can negotiate the use of prioritization of the Transmission Media Request message. In that case, the transmission participant can request permission to send media at a priority level that is either the same as or lower than the highest priority that was permitted to the participant in the MCVideo call initialization. If a transmission participant is authorized for pre-emptive priority in the MCVideo call it is good practise to always request permission to send RTP media packets at a priority level that is lower than pre-emptive priority unless the user explicitly requests to pre-empt the current RTP media packets sender.

[TS 24.581, clause 6.2.2]

The MCVideo call release (whether it is initiated by the transmission participant or transmission control server) is a two-step procedure.

Step 1 The transmission participant stops sending transmission control and reception control messages and the MCVideo client stops sending and receiving RTP media packets.

Step 2 When the application and signalling plane has determined that the MCVideo call is released, the corresponding instance of the ‘Transmission participant state transition diagram for basic transmission control operation’ as specified in subclause 6.2.4 and the corresponding instance of the ‘Transmission participant state transition diagram for basic reception control operation’ as specified in subclause 6.2.5 are terminated and the transmission participant releases all the used resources.

The user plane can initiate the release step 1, but the application and signalling plane always initiates the release step 2.

[TS 24.581, clause 12.1.2.1]

This subclause defines the structure and syntax of the SDP "fmtp" attribute, when used to negotiate an MCVideo media plane control channel. The MCVideo media plane control channel, and the protocols used on the control channel, is described in the present specification.

[TS 24.581, clause 12.1.2.2]

In an SDP offer and answer, the "mc_queueing" fmtp attribute is used to indicate support of the Transmission Request message queueing mechanism, as defined in the present specification.

In an SDP offer, the "mc_priority" fmtp attribute indicates (using an integer value between ‘1’ and ‘255’) the maximum transmission priority that the offerer requests to be used with Transmission Request messages sent by the offerer. In an SDP answer, the attribute parameter indicates the maximum priority level that the answerer has granted to the offerer. The value must be equal or less than the value provided in the associated SDP offer.

NOTE 1: If the "mc_priority" fmtp attribute is not used within an SDP offer or answer, a default priority value is assumed.

In an SDP offer, the "mc_reception_priority" fmtp attribute indicates (using an integer value between ‘1’ and ‘255’) the maximum reception priority that the offerer requests to be used with Reception Request messages sent by the offerer. In an SDP answer, the attribute parameter indicates the maximum reception priority level that the answerer has granted to the offerer. The value must be equal or less than the value provided in the associated SDP offer.

NOTE 2: If the "mc_reception_priority" fmtp attribute is not used within an SDP offer or answer, a default reception priority value is assumed.

In an SDP offer, the "mc_granted" fmtp attribute parameter indicates that the offerer supports the procedure where the answerer indicates, using the fmtp attribute in the associated SDP answer, that the permission to transmit has been granted to the offerer.

NOTE 3: When the "mc_granted" fmtp attribute is used in an SDP offer, it does not indicate an actual request for the media transmission. The SDP "mc_implicit_request" fmtp attribute can be used to request the media transmission. In an SDP answer, the attribute indicates that the permission to Transmission has been granted to the offerer.

NOTE 4: Once the offerer has been granted the permission to Transmission, the offerer can perform media transmission until it receives a Transmission Revoked message, or until the offerer itself ends the media transmission by sending a Transmission end request message, as described in the present specification.

In an SDP offer, the "mc_implicit_request" fmtp attribute indicates that the offerer implicitly requests for media transmission (without the need to send a Transmission Request message). In an SDP answer, the attribute parameter indicates that the answerer has accepted the implicit Transmission Request. Once the answerer grants the permission to Transmission to the offerer, the answerer will send a Transmission Granted message.

NOTE 5: The usage of the "mc_implicit_request" fmtp attribute in an SDP answer does not mean that the answerer has granted the permission to Transmission to the offerer, only that the answerer has accepted the implicit Transmission Request.

[TS 24.581, clause 14.2.1]

When the offerer generates an SDP offer, in order to negotiate the establishment of a media plane control channel, the offerer shall include a media description ("m=" line) associated with the media plane control channel. In addition, the offerer may associate an SDP fmtp attribute with the media description.

NOTE: "Initial offer" refers to the offer when the media plane control channel is initially negotiated. It might, or might not, be the initial offer within the session.

[TS 24.581, clause 14.2.4]

The MCVideo client shall include the "mc_granted" fmtp attribute in the SDP offer of an initial SIP INVITE request when it is acceptable for the MCVideo client to receive a granted indication in the SIP 200 (OK) response to an initial INVITE request.

[TS 24.581, clause 14.2.5]

The MCVideo client shall include the "mc_implicit_request" fmtp attribute when a SIP request shall be interpreted as an implicit Transmission request. If not explicitly stated in procedures in the present document or in procedures in 3GPP TS 24.281 [2] that the "mc_implicit_request" fmtp attribute shall be included, the decision to include the "mc_implicit_request" fmtp attribute or not, is an implementation option.

6.1.1.3.3 Test description

6.1.1.3.3.1 Pre-test conditions

System Simulator:

– SS (MCVideo server)

IUT:

– UE (MCVideo Client)

– The test USIM (Universal Subscriber Identity Module – SIM Card – should apply to Video) set as defined in subclause 5.5.10 is inserted.

– The UE shall be switched off.

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 (Procedure shown under IUT above).

– 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.2A.

– 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.3.3.2 Test procedure sequence

Table 6.1.1.3.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User request the establishment of a MCVideo On-demandPre-arranged Group Call, Manual Commencement Mode, with explicit request for Transmission control

(NOTE 1)

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 56.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo Client) send an initial SIP INVITE to request the establishment of a MCVideo On-demand Pre-arranged Group Call with Manual Commencement?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) sends a SIP 100 Trying message.

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) sends a SIP 200 (OK) message indicating that the MCVideo call has been established.

<–

SIP 200 (OK)

5

Check: Does the UE (MCVideo client) send a SIP ACK in response to the SIP 200 (OK)?

–>

SIP ACK

2-

P

6

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client).

<–

Transmission Granted

7

Check: Does the UE (MCVideo Client) send an acknowledgement to the SS (MCVideo Server) in response to Transmission Granted?

–>

Transmission Control ACK

2

P

8

Check: Does the UE (MCVideo Client) provide transmission granted notification to the MCVideo User?

(NOTE 1)

2

P

9

Make the MCVideo User request to end Transmission.

(NOTE1)

10

Check: Does the UE (MCVideo Client) send a Transmission End Request?

–>

Transmission End Request

2

P

11

The SS (MCVideo Server) responds to the UE (MCVideo Client) request.

<–

Transmission End Response

12

Check: Does the UE (MCVideo Client) acknowledge the response from the SS (MCVideo Server)?

–>

Transmission Control ACK

2

P

13

Void

14

Void

15

Check: Does the UE (MCVideo Client) send a SIP BYE message to end the On-demand Group Call?

–>

SIP BYE

3

P

16

The SS (MCVideo Server) sends a SIP 200 (OK).

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.1.1.3.3.3 Specific message contents

Table 6.1.1.3.3.3-1: SIP INVITE (Step 2, Table 6.1.1.3.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Answer-Mode

answer-mode-value

"Manual"

Message-body

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

"application/vnd.3gpp.mcvideo-info+xml"

MIME-part-body

MCVideo-Info as described in Table 6.1.1.1.3.3-2

Table 6.1.1.3.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.3.3.3-1)

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

Table 6.1.1.3.3.3-3: SIP 200 (OK) (Step 4, Table 6.1.1.3.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.3.3.3-4

Table 6.1.1.3.3.3-4: Void

Table 6.1.1.3.3.3-5: Transmission Granted (Step 6, Table 6.1.1.3.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

‘1000000000000001’ Is this value correct

A = normal cal.

A ‘1’ in the last bit requires an acknowledgement.l

Table 6.1.1.3.3.3-6: Transmission Control Ack (Step 7, 12, Table 6.1.1.3.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

‘10000’

Transmission Control Ack message for Transmission Granted message which requested acknowledgment.

Table 6.1.1.3.3.3-7: Transmission End Response (Step 11, Table 6.1.1.3.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.2-1

Information Element

Value/remark

Comment

Reference

Condition

Subtype

‘10001’

A ‘1’ in the last bit = acknowledgement required.

Table 6.1.1.1.3.3-8: Void

Table 6.1.1.3.3.3-9: SIP BYE (Step 15, Table 6.1.1.3.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MOCALL

Table 6.1.1.3.3.3-10: SIP 200 (OK) (Step 16, Table 6.1.1.3.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

6.1.1.4 On-network / On-demand Pre-arranged Group Call / Manual Commencement Mode / Client Terminated (CT)

6.1.1.4.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 Manual Commencement Mode and the MCVideo User requests to answer the call }

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

}

(2)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Group Call with Manual 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 received a Media Transmission Notification message from the SS (MCVideo Server) }

ensure that {

when { the MCVideo User requests permission to receive media }

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

}

(4)

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

ensure that {

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

then { the UE (MCVideo Client) responds with a SIP 200 (OK) message }

6.1.1.4.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in: TS 24.281, clauses 9.2.1.2.1.2, 6.2.3.2.2, 9.2.1.2.3.3, 6.2.6, and in TS24.581, clause 6.2.5.2.2, 6.2.5.3.2, 6.2.5.3.3. 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 9.2.1.2.1.2]

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

The MCVideo client:

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

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

b) 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 [51] and warning texts as specified in subclause 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 subclause;

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

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

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

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

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

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

[TS 24.281, clause 6.2.3.2.2]

When performing the manual commencement mode procedures:

1) the terminating MCVideo client may automatically generate a SIP 183 (Session Progress) in accordance with 3GPP TS 24.229 [11], prior to the MCVideo user’s acknowledgement; and

2) if the MCVideo user declines the MCVideo session invitation the MCVideo client shall send a SIP 480 (Temporarily Unavailable) response towards the MCVideo server with the warning text set to: "110 user declined the call invitation" in a Warning header field as specified in subclause 4.4, and not continue with the rest of the steps in this subclause.

When generating a SIP 183 (Session Progress) response, the MCVideo client:

1) shall include the following in the Contact header field:

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

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

2) may include a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [30];

When sending the SIP 200 (OK) response to the incoming SIP INVITE request, the MCVideo client shall follow the procedures in subclause 6.2.3.1.2.

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

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

[TS 24.281, clause 6.2.6]

Upon receiving a SIP BYE request, the MCVideo client:

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

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

[TS 24.581, clause 6.2.5.2.2]

When an MCVideo call is established, the terminating transmission participant:

1. shall create an instance of a ‘Transmission participant state transition diagram for general reception control operation’; and

2. shall enter the ‘U: reception controller’ state.

NOTE: From a transmission participant perspective the MCVideo call is established when the application and signalling plane sends the SIP 200 (OK) response.

[TS 24.581, clause 6.2.5.3.2]

Upon receiving the media transmission notification from the transmission control server, the transmission participant:

1. if the first bit in the subtype of the media transmission notification 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 ‘6’ (Media transmission notification); and

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

2. shall provide media transmission notification to the user;

3. shall store the User ID and the SSRC of the user transmitting the media;

4. may display the details of the incoming media to the user; and

5. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.3]

Upon receiving an indication from the user to request permission to receive media, the transmission participant:

1. shall send the Receive Media Request message toward the transmission control server; The Receive Media Request message:

a. if a different priority than the normal priority is required, shall include the Reception Priority field with the priority not higher than negotiated with the transmission control server as specified in subclause 14.3.3; and

b. if the receive media request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Transmission Indicator field indicating the relevant call types;

2. shall create an instance of the ‘Transmission participant state transition diagram for basic reception control operation’;

3. shall map the stored User ID and the SSRC of the user transmitting the media with instance of ‘Transmission participant state transition diagram for basic reception control operation’ created in step 2; and

4. shall remain in the ‘U: reception controller’ state.

6.1.1.4.3 Test description

6.1.1.4.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 MCPTT operation in the MCPTT 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.2A.

– 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.4.3.2 Test procedure sequence

Table 6.1.1.4.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.4A ‘Generic Test Procedure for MCVideo CT communication in E-UTRA’. The test sequence below shows only the MCVIDEO relevant messages exchanged.

1

SS (MCVideo Server) initiates an on-demand pre-arranged group call with manual commencement mode and implicit Transmission Control.

<–

SIP INVITE

EXCEPTION: Steps 2a1 through 2a4 describe behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that take place if the UE (MCVideo Client) responds to a SIP INVITE prior to the MCVIDEO user’s acknowledgment.

2a1

Check: Does the UE (MCVideo Client) respond with a SIP 100 Trying provisional response?

–>

SIP 100 (Trying)

1

P

2a2

Check: Does the UE (MCVideo Client) respond with a SIP 183 (Session Progress) message?

–>

SIP 183 (Session Progress)

1

P

2a3

The SS (MCVideo Server) responds to the SIP 183 (Session Progress) message with a SIP PRACK message.

<–

SIP PRACK

2a4

Check: Does the UE (MCVideo Client) acknowledge the SIP PRACK message with SIP 200 (OK) message.

–>

SIP 200 (OK)

1

P

3

Make the MCVideo User answer the call.

(NOTE 1)

4

Check: Does the UE (MCVideo Client) answer the call with a SIP 200 (OK) message?

–>

SIP 200 (OK)

1

P

5

The SS (MCVideo Server) acknowledges the receipt of a SIP 200 (OK) for SIP INVITE message.

<–

SIP ACK

6

The SS (MCVideo Server) sends a Media Transmission Notification message

<–

Media Transmission Notification

7

Check: Does the UE (MCVideo Client) provide media transmission notification to the MCVideo User?

(NOTE 1)

2

P

8

Make the MCVideo User request permission to receive media.

(NOTE 1)

9

Check: Does the UE (MCVideo Client) send a Receive Media Request message?

–>

Receive Media Request

3

P

10

The SS (MCVideo Server) sends a Receive Media Response message.

<–

Receive Media Response

11

The SS ends the call by sending a SIP BYE message

<–

SIP BYE

12

Check: Does the UE (MCVideo Client) respond with a SIP 200 (OK) message?

–>

SIP 200 (OK)

4

P

EXCEPTION: SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This is expected to be done via a suitable implementation dependent MMI command.

6.1.1.4.3.3 Specific message contents

Table 6.1.1.4.3.3-1: SIP INVITE from the SS (Step 1, Table 6.1.1.4.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5-1, conditions MCVIDEO, MANUAL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.4.3.3-2

Table 6.1.1.4.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.4.3.3-1)

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

Table 6.1.1.4.3.3-3: Void

Table 6.1.1.4.3.3-4: SIP 200 (OK) (Steps 2a4, 12, Table 6.1.1.4.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.17.1.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included

Table 6.1.1.4.3.3-5: SIP 200 (OK) (Step 4, Table 6.1.1.4.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.4.3.3-6

Table 6.1.1.4.3.3-6: MCVideo-INFO in SIP 200 (OK) (Table 6.1.1.4.3.3-5)

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

Table 6.1.1.4.3.6-7: SIP BYE (Step 11, Table 6.1.1.4.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.2-1, condition MOCALL

6.1.1.5 On-network / On-demand Pre-arranged Group Call / Emergency Group Call / Client Originated (CO)

6.1.1.5.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests the establishment of a MCVideo On-demand Pre-arranged Emergency Group Call, with implicit Transmission Control }

then { the UE (MCVideo Client) requests On-demand Pre-arranged Emergency Group Call 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 an MCVideo On-demand Pre-arranged Group Call }

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 an ongoing On-demand Pre-arranged Emergency Group Call, with implicit Transmission Control }

ensure that {

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

then { the UE (MCVideo Client) sends a Transmission End Request, and acknowledges the Transmission End Response with a Transmission Control ACK, and then sends a SIP BYE request and leaves the MCVideo Session }

}

6.1.1.5.2 Conformance requirements

References: The conformance requirements covered in the current Test Caseare specified in TS 24.281, clauses 9.2.1.2.1.1, 6.2.8.1.1, 6.2.8.1.2, 6.2.8.1.3, 6.2.8.1.4, 6.2.1 and TS 24.581, Test Case 6.2.4.4.6. 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 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 6.2.8.1.1]

This subclause is referenced from other procedures.

When the MCVideo emergency state is set and this MCVideo user and MCVideo group are authorized to initiate MCVideo emergency group calls as determined by the procedures of subclause 6.2.8.1.8, the MCVideo client:

1) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP INVITE request, an <emergency-ind> element set to "true" and if the MCVideo emergency group call state is set to "MVEGC 1: emergency-gc-capable", shall set the MCVideo emergency group call state to "MVEGC 2: emergency-call-requested";

2) if the MCVideo user has also requested an MCVideo emergency alert to be sent and this is an authorized request for MCVideo emergency alert as determined by the procedures of subclause 6.2.8.1.6, and the MCVideo emergency alert state is set to "MVEA 1: no-alert", shall:

a) set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "true" and set the MCVideo emergency alert state to "MVEA 2: emergency-alert-confirm-pending"; and

b) perform the procedures specified in subclause 6.2.9.1 for the MCVideo emergency alert trigger;

3) if the MCVideo user has not requested an MCVideo emergency alert to be sent and the MCVideo emergency alert state is set to "MVEA 1: no-alert", shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "false"; and

4) if the MCVideo client emergency group state of the group is set to a value other than "MVEG 2: in-progress" set the MCVideo client emergency group state of the MCVideo group to "MVEG 3: confirm-pending".

NOTE 1: This is the case of an MCVideo user already being in the MCVideo emergency state it initiated previously while originating an MCVideo emergency group call or MCVideo emergency alert. All group calls the MCVideo user originates while in MCVideo emergency state will be MCVideo emergency group calls.

When the MCVideo emergency state is clear and the MCVideo emergency group call state is set to "MVEGC 1: emergency-gc-capable" and the received SIP request contains an authorized request for MCVideo emergency group call as determined by the procedures of subclause 6.2.8.1.8, the MCVideo client shall set the MCVideo emergency state and perform the following actions:

1) shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the SIP INVITE request an <emergency-ind> element set to "true" and set the MCVideo emergency group call state to "MVEGC 2: emergency-call-requested" state;

2) if the MCVideo user has also requested an MCVideo emergency alert to be sent and this is an authorized request for MCVideo emergency alert as determined by the procedures of subclause 6.2.8.1.6, shall:

a) include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <alert-ind> element set to "true" and set the MCVideo emergency alert state to "MVEA 2: emergency-alert-confirm-pending"; and

b) perform the procedures specified in subclause 6.2.9.1 for the MCVideo emergency alert trigger;

3) if the MCVideo user has not requested an MCVideo emergency alert to be sent, shall set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to "false"; and

4) if the MCVideo client emergency group state of the group is set to a value other than "MVEG 2: in-progress" shall set the MCVideo client emergency group state of the MCVideo group to "MVEG 3: confirm-pending".

NOTE 2: This is the case of an initial MCVideo emergency group call and optionally an MCVideo emergency alert being sent. As the MCVideo emergency state is not sent, there is no MCVideo emergency alert outstanding.

NOTE 3: An MCVideo group call originated by an affiliated member of an MCVideo group which is in an in-progress emergency state (as tracked on the MCVideo client by the MCVideo client emergency group state) but is not in an MCVideo emergency state of their own will also be an MCVideo emergency group call. The <emergency-ind> and <alert-ind> elements of the application/vnd.3gpp.mcvideo-info+xml MIME body do not need to be included in this case and hence no action needs to be taken in this subclause.

[TS 24.281, clause 6.2.8.1.2]

This subclause is referenced from other procedures.

If the MCVideo emergency group call state is set to either "MVEGC 2: emergency-call-requested" or "MVEGC 3: emergency-call-granted" and this is an authorized request for an MCVideo emergency group call as determined by the procedures of subclause 6.2.8.1.8, or the MCVideo client emergency group state of the group is set to "MVEG 2: in-progress", the MCVideo client shall include in the SIP INVITE request a Resource-Priority header field populated with the values for an MCVideo emergency group call as specified in subclause 6.2.8.1.15.

NOTE: The MCVideo client ideally would not need to maintain knowledge of the in-progress emergency state of the group (as tracked on the MCVideo client by the MCVideo client emergency group state) but can use this knowledge to provide a Resource-Priority header field set to emergency level priority, which starts the infrastructure priority adjustment process sooner than otherwise would be the case.

If this is an authorized request to cancel the MCVideo emergency group call as determined by the procedures of subclause 6.2.8.1.7, and the MCVideo client emergency group state of the group is "no-emergency" or "cancel-pending", the MCVideo client shall include in the SIP INVITE request a Resource-Priority header field populated with the values for a normal MCVideo group call as specified in subclause 6.2.8.1.15.

[TS 24.281, clause 6.2.8.1.3]

This subclause is referenced from other procedures.

Upon receiving a SIP INFO request within the dialog of the SIP request for a priority group call:

– with the Info-Package header field containing the g.3gpp.mcvideo-info package name;

– with the application/vnd.3gpp.mcvideo-info+xml MIME body associated with the info package according to IETF RFC 6086 [54]; and

– with one or more of the <alert-ind>, <imminentperil-ind> and <emergency-ind> elements set in the application/vnd.3gpp.mcvideo-info+xml MIME body;

the MCVideo client:

1) shall send a SIP 200 (OK) response to the SIP INFO request as specified in 3GPP TS 24.229 [4];

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

a) if the MCVideo emergency alert state is set to "MVEA 2: emergency-alert-confirm-pending":

i) if the <alert-ind> element is set to a value of "false", shall set the MCVideo emergency alert state to "MVEA 1: no-alert"; and

ii) if the <alert-ind> element is set to a value of "true", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated";

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

a) if the <imminentperil-ind> element is set to a value of "false" and an <emergency-ind> element is set to a value of "true", shall:

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

ii) set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-capable"; and

iii) set the MCVideo client emergency group state of the group to "MVEG 2: in-progress"; and

NOTE 1: This is the case of an MCVideo client attempting to make an imminent peril group call when the group is in an in-progress emergency group state. The MCVideo client will then receive a notification that the imminent peril call request was denied, however they will be participating at the emergency level priority of the group. This could occur for example when an MCVideo client requests an imminent peril call to a group that they are not currently affiliated with.

NOTE 2: the MCVideo client emergency group state above is the MCVideo client’s view of the in-progress emergency state of the group.

4) if the SIP request for a priority group call sent by the MCVideo client did not contain an <originated-by> element and if the MCVideo emergency alert state is set to "MVEA 4: Emergency-alert-cancel-pending":

a) if the <alert-ind> element contained in the SIP INFO request is set to a value of "true", shall set the MCVideo emergency alert state to "MVEA 3: emergency-alert-initiated"; and

b) if the <alert-ind> element contained in the SIP INFO request is set to a value of "false", shall set the MCVideo emergency alert state to "MVEA 1: no-alert".

[TS 24.281, clause 6.2.8.1.4]

In the procedures in this subclause, a priority group call refers to an MCVideo emergency group call or an MCVideo imminent peril group call.

On receiving a SIP 2xx response to a SIP request for a priority group call, the MCVideo client:

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

a) shall set the MCVideo client emergency group state of the group to "MVEG 2: in-progress" if it was not already set;

b) if the MCVideo emergency alert state is set to "MVEA 2: emergency-alert-confirm-pending" 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 3: emergency-alert-initiated;

c) shall set the MCVideo emergency group call state to "MVEGC 3: emergency-call-granted"; and

d) shall set the MCVideo imminent peril group call state to "MVIGC 1: imminent-peril-capable" and the MCVideo imminent peril group state to "MVIG 1: no-imminent-peril"; 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" and the SIP 2xx response to the SIP request for an imminent peril 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":

a) set the MCVideo imminent peril group call state to "MVIGC 3: imminent-peril-call-granted"; and

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

[TS 24.281, clause 6.2.1]

The SDP offer shall contain two SDP media-level sections for MCVideo video media according to 3GPP TS 24.229 [11] and, if transmission control shall be used during the session, shall contain one SDP media-level section for a media- transmission control entity according to 3GPP TS 24.581 [5].

When composing an SDP offer according to 3GPP TS 24.229 [11] the MCVideo client:

1) shall set the IP address of the MCVideo client for the offered MCVideo video media stream and, if transmission control shall be used, for the offered media-transmission control entity;

NOTE: If the MCVideo client is behind a NAT the IP address and port included in the SDP offer can be a different IP address and port than the actual IP address and port of the MCVideo client depending on the NAT traversal method used by the SIP/IP Core.

2) shall include an "m=audio" media-level section for the MCVideo media stream consisting of:

a) the port number for the media stream selected; and

b) the codec(s) and media parameters and attributes with the following clarification:

i) if the MCVideo client is initiating a call to a group identity;

ii) if the <preferred-voice-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [24] containing an <encoding> element with a "name" attribute; and

iii) if the MCVideo client supports the encoding name indicated in the value of the "name" attribute;

then the MCVideo client:

i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [2]; and

c) "i=" field set to "audio component of MCVideo" according to 3GPP TS 24.229 [11];

3) shall include an "m=video" media-level section for the MCVideo media stream consisting of:

a) the port number for the media stream selected; and

b) the codec(s) and media parameters and attributes with the following clarification:

i) if the MCVideo client is initiating a call to a group identity;

ii) if the <preferred-video-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [24] containing an <encoding> element with a "name" attribute; and

iii) if the MCVideo client supports the encoding name indicated in the value of the "name" attribute;

then the MCVideo client:

i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [2];

c) if the SDP offer is for an ambient viewing call:

i) if this is a remotely initiated ambient viewing call, include an "a=recvonly" attribute; or

ii) if this is a locally initiated ambient viewing call, include an "a=sendonly" attribute; and

d) "i=" field set to "video component of MCVideo" according to 3GPP TS 24.229 [11];

4) if transmission control shall be used during the session, shall include an "m=application" media-level section as specified in 3GPP TS 24.581 [5] clause 12 for a media-transmission control entity, consisting of:

a) the port number for the media-transmission control entity selected as specified in 3GPP TS 24.581 [5]; and

b) the ‘fmtp’ attributes as specified in 3GPP TS 24.581 [5] clause 14; and

5) if end-to-end security is required for a private call and the SDP offer is not for establishing a pre-established session, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [34].

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

6.1.1.5.3 Test description

6.1.1.5.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.2A.

– 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.5.3.2 Test procedure sequence

Table 6.1.1.5.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User request the establishment of a MCVideo On-demand Pre-arranged Emergency Group Call for the selected MCVideo Emergency Group A, with explicit Transmission Control.

(NOTE 1).

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo client) send an initial SIP INVITE request for the establishment of an MCVideo On-demand pre-arranged Emergency Group Call?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) sends a SIP 100 (Trying) message.

<–

SIP 100 (Trying)

4

The SS sends SIP 200 (OK), indicating that the MCVideo call has been established.

<–

SIP 200 (OK)

5

Does the UE (MCVideo client) send a SIP ACK in response to the SIP 200 (OK)?

–>

SIP ACK

2

P

6

The SS (MCVideo Server) sends a Transmission Granted message.

<–

Transmission Granted

7

Check: Does the UE (MCVideo client) send a Transmission Control Ack message in response to the SS Transmission Granted message?

–>

Transmission Control Ack

2

P

8

Check: Does the UE (MCVideo Client provide transmission granted notification to the MCVideo User?

(NOTE 1)

1

P

9

Make the UE (MCVideo client) end the Group Call.

(NOTE 1)

10

Check: Does the UE (MCVideo Client) send a Transmission End Request message indicating that it wants to terminate a MCVideo On-Demand Pre-Arranged Emergency Group Call, with implicit Transmission Control?

–>

Transmission End Request

3

P

11

The SS (MCVideo Server) responds with a Transmission End Response message verifying that the UE (MCVideo Client) is able to end an MCVideo On-Demand Pre-Arranged Emergency Group Call, with implicit Transmission Control.

<–

Transmission End Response

12

Check: Does the UE (MCVideo Client) send a Transmit Control ACK message?

–>

Transmission Control ACK

3

P

13

The SS (MCVideo Server) sends a Transmission Idle message. Do I need this message? No difference whether ending an emergency call or normal call?

<–

Transmission Idle

14

Check: Does the UE (MCVideo Client) send a SIP BYE message to end the On-demand Pre-arranged Emergency Group Call?

–>

SIP BYE

3

P

15

The SS (MCVideo Server) responds to the SIP BYE message with a SIP 200 (OK) message.

<–

SIP 200 (OK)

EXCEPTION: SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This action is expected to be done via a suitable implementation-dependent MMI.

6.1.1.5.3.3 Specific message contents

Table 6.1.1.5.3.3-1: SIP INVITE (Step 2, Table 6.1.1.5.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message Body

MIME-body-part

MCVideo-Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.5.3.3-2

Table 6.1.1.5.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.5.3.3-1)

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

Table 6.1.1.5.3.3-3: SIP 200 (OK) (Step 4, Table 6.1.1.5.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO, INVITE-RSP, EMERGENCY-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.1.5.3.3-2

Table 6.1.1.5.3.3-4: Transmission Granted (Steps 6, Table 6.1.1.5.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Table 6.1.1.5.3.3-5: Transmission End Response (Step 11, Table 6.1.1.5.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.2-1

Information Element

Value/remark

Comment

Reference

Condition

Subtype

"10001"

A ‘1’ in the first bit requires an acknowledgement.

TS 24.581 [27], clause 9.2.2.1-2

Table 6.1.1.5.3.3-6: Transmission Control Ack (Step 12, Table 6.1.1.5.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

"10000"

Transmission Control Ack message for Transmission End Response message which requested acknowledgment.

Table 6.1.1.5.3.3-7: SIP BYE (Step 14, Table 6.1.1.1.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MOCALL

Table 6.1.1.5.3.3-8: SIP 200 (OK) (Step 15, Table 6.1.1.5.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

6.1.1.6 On-network / On-demand Pre-arranged Group Call / Emergency Group Call / Client Terminated (CT)

6.1.1.6.1 Test Purpose (TP)

(1)

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

ensure that {

when { the UE (MCVideo Client) receives a SIP INVITE message from the SS (MCVideo Server) with an emergency indication for a MCVideo On-demand Pre-arranged Emergency Group Call }

then { the UE (MCVideo Client) displays an indication for the Pre-arranged MCVideo Emergency Group Call to the MCVideo User and responds to the SS (MCVideo Server) with a SIP 200 (OK) message }

}

(2)

with { the UE (MCVideo Client) having an incoming Pre-arranged Emergency Group Call, with implicit Transmission Control }

ensure that {

when { the 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 and sends a Receive Media Request message to 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) }

(3)

with { the UE (MCVideo Client) having sent a Receive Media Request message }

ensure that {

when { the MCVideo Client) receives a Receive Media Response message from the SS (MCVideo Server) }

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

(4)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Emergency Group Call, with implicit Transmission Control }

ensure that {

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

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

}

}

(5

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.6.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in TS 24.281, clauses 9.2.1.2.1.2, 9.2.1.2.1.6, 6.2.3.1.2, and 6.2.6. 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 9.2.1.2.1.2]

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 an initial SIP INVITE request, the MCVideo client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [11] with the clarifications below.

The MCVideo client:

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

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

b) 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 [51] and warning texts as specified in subclause 4.4.2 or with SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorized to restrict the reason for failure and skip the rest of the steps of this subclause;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9) when the SIP 200 (OK) response to the SIP INVITE request is sent, may subscribe to the conference event package as specified in subclause 9.1.3.19.2.1.2.1.6 MCVideo client receives SIP re-INVITE request

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

Upon receiving a SIP BYE request, the MCVideo client:

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

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

6.1.1.6.3 Test description

6.1.1.6.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 MCVideoUE 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.2A.

– 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.6.3.2 Test procedure sequence

Table 6.1.1.6.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.4A ‘Generic Test Procedure for MCVideo CT communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

1

The SS (MCVideo Server) sends a SIP INVITE to initiate an on-demand pre-arranged emergency group call with automatic commencement mode.

<–

SIP INVITE

EXCEPTION: Step 2a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that take place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message.

2a1

Check: Does the UE (MCVideo Client) respond with a SIP 100 (Trying) message?

–>

SIP 100 (Trying)

1

P

3

Check: Does the UE (MCVideo Client) send a SIP 200 (OK) message?

–>

SIP 200 (OK)

1

P

4

The SS (MCVideo Server) sends an acknowledgement of the SIP 200 (OK) message.

<–

SIP ACK

5

Check: Does the UE (MCVideo Client) display an indication for the Pre-arranged MCVideo emergency group call to the MCVideo User?

(NOTE 1)

1

P

6

The SS (MCVideo Server) sends a Media Transmission Notification message.

<–

Media Transmission Notification

7

Check: Does the UE (MCVideo Client) provide media transmission notification to the MCVideo User?

(NOTE 1).

2

P

8

Make the MCVideo User request permission to receive media.

(NOTE 1)

9

Check: Does the UE (MCVideo Client) respond with a Media Receive Request message?

–>

Receive Media Request

2

P

10

The SS (MCVideo Server) sends a Receive Media Response message.

<–

Receive Media Response

11

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1)

3

P

12

Make the MCVideo User request to end the RTP media reception.

(NOTE1)

13

Check: Does the UE (MCVideo Client) request to terminate the RTP media reception by sending a Media Reception End Request message?

–>

Media Reception End Request

4

P

14

The SS (MCVideo Server) responds with a Media Reception End Response message.

<–

Media Reception End Response

15

Void

16

The SS (MCVideo Server) sends a SIP BYE message to the UE (MCVideo Client) to terminate the session.

<–

SIP BYE

17

Check: Does the UE (MCVideo Client) send a SIP 200 (OK) message to the SS (MCVideo Server)?

–>

SIP 200 (OK)

5

EXCEPTION: SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This action is expected to be done via a suitable implementation dependent MMI.

6.1.1.6.3.3 Specific message contents

Table 6.1.1.6.3.3-1: SIP INVITE (Step 1, Table 6.1.1.6.3.2-1)

Derivation Path: TS 36-579-1 [2], Table 5.5.2.5.2-1, conditions MCVIDEO, EMERGENCY-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-Info

MIME-part-headers

MIME-Content-Type

"application/vnd.3gpp.mcvideo-info+xml"

MIME-part-body

MCVideo-Info as described in Table 6.1.1.6.3.3-2

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

Derivation Path: TS 56.379-1 [2], Table 5.5.3.2.2-2, condition GROUP-CALL

Table 6.1.1.6.3.3-3: SIP 200 (OK) (Step 3, Table 6.1.1.6.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.6.3.3-4

Table 6.1.1.6.3.3-4: MCVideo-Info (Table 6.1.1.6.3.3-3)

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

Table 6.1.1.6.3.3-5: Receive Media Response (Step 10, Table 6.1.1.6.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

‘0001000000000000’

D = Emergency Call

Table 6.1.1.6.3.3-6: SIP BYE (Step 16 Table 6.1.1.6.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2-1, condition MO-CALL

Table 6.1.1.6.3.3-7: SIP 200 (OK) (Step 17, Table 6.1.1.6.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

6.1.1.7 On-network / On-demand Pre-arranged Group Call / Broadcast Group Call / Client Originated (CO)

6.1.1.7.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests the establishment of a MCVideo On-demand Pre-Arranged Broadcast Group Call }

then { the UE (MCVideo Client) requests an On-demand Pre-Arranged Broadcast Group Call by sending a SIP INVITE message and acknowledges the SIP 200 (OK) message from the SS (MCVideo Server) upon receipt }

}

(2)

with { the UE (MCVideo Client) having established an MCVideo On-demand Pre-arranged Broadcast 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) provides transmission granted notification to the MCVideo User and respects the Transmission Control imposed by the MCVideo Server }

}

(3)

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

ensure that {

when {the UE (MCVideo User) requests to release to end the permission to send RTP media }

then { the UE (MCVideo Client) sends a Transmission End Request message and acknowledges the Transmission End Response from the SS (MCVideo Server) and sends a SIP BYE message and notifies the MCVideo User that the media transmission has completed and leaves the MCVideo Session }

}

6.1.1.7.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in TS 24.281, clauses 6.2.8.2 and 9.2.1.2.1.1; also TS 24.581, clauses 6.2.4.2.2, 6.2.4.5.3, 6.2.4.6.4. 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.8.2]

NOTE: This subclause is referenced from other procedures.

When the MCVideo user initiates a broadcast group call, the MCVideo client:

1) in the case of the prearranged group call is initiated on-demand, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <broadcast-ind> element set to "true" as defined in clause F.1; and

2) in the case the prearranged group call is initiated using a pre-established session, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the "body" URI header field in the Refer-To header field the <broadcast-ind> element set to "true" as defined in clause F.1.

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

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

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

[TS 24.581, clause 6.2.4.2.2]

When a call is initiated as described in 3GPP TS 24.281 [2], the transmission participant:

1. shall create an instance of the ‘Transmission participant state transition diagram for basic transmission control operation’;

2. if the originating transmission participant receives a transmission control message before it receives the SIP 200 (OK) response, shall store the transmission control message;

NOTE: The originating transmission participant might receive a transmission control message before the SIP 200 (OK) response when initiating, joining or rejoining a call because of processing delays of the SIP 200 (OK) response in the SIP core.

3. if the established MCVideo call is a chat group call and the SIP INVITE request is not an implicit Transmission request, shall enter the ‘U: has no permission to transmit’ state;

4. if for the established MCVideo call the SIP INVITE request is an implicit Transmission request:

a. shall start timer T100 (Transmission Request) and initialise counter C100 (Transmission Request) to 1;

b. shall enter the ‘U: pending request to transmit’ state; and

c. if the transmission participant has received and stored a transmission control message before the reception of the SIP 200 (OK) response, shall act as if the transmission control message was received in the ‘U: pending request to transmit’ state after entering the ‘U: pending request to transmit’ state; and

5. if the established MCVideo call is a broadcast group call, shall enter the ‘U: has permission to transmit’ state.

When the transmission participant is rejoining an ongoing MCVideo call as described in 3GPP TS 24.281 [2] the transmission participant shall enter the ‘U: has no permission to transmit’ state.

[TS 24.581, clause 6.2.4.5.3]

Upon receiving an indication from the user to end the permission to send RTP media, the transmission participant:

1. shall send a Transmission end request message towards the transmission control server. The Transmission end request message, if the session is a broadcast call and if the session was established as a normal call, shall include the Transmission Indicator with the A-bit set to ‘1’ (Normal call);

2. shall start timer T101 (Transmission End Request) and initialize counter C101 (Transmission End Request) to 1; and

3. shall enter the ‘U: pending end of transmission’ state.

[TS 24.581, clause 6.2.4.6.4]

Upon receiving a Transmission end response message, the transmission participant:

1. if the first bit in the subtype of the Transmission end response message 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 ‘1’ (Transmission end response); and

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

2. may provide a Transmission end notification to the MCVideo user;

3. if the Transmission Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T101 (Transmission End Request);

5. if the session is not a broadcast group call or if the A-bit in the Transmission Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission to transmit’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCVideo client the media transmission is completed; and

b shall enter the ‘Call releasing’ state.

6.1.1.7.3 Test description

6.1.1.7.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.2A.

– 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.7.3.2 Test procedure sequence

Table 6.1.1.7.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User request the establishment of a MCVideo On-demand

Pre-arranged Broadcast Group Call for the selected MCVideo Broadcast Group GROUP A, with implicit Transmission Control.

(NOTE1)

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo client) send an initial SIP INVITE request for the establishment of a MCVideo On-demand Pre-arranged Broadcast Group Call?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) responds to the UE with a SIP 100 (Trying) message.

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client), indicating that it has accepted the SIP INVITE request from the UE.

<–

SIP 200 (OK)

5

Check: Does the UE (MCVideo Client) respond with a SIP ACK message?

–>

SIP ACK

1

P

6

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client).

<–

Transmission Granted

7

Check: Does the UE (MCVideo Client) send a Transmission Control ACK in response to Transmission Granted message from the SS (MCVideo Server)?

–>

Transmission Control ACK

2

P

8

Check: Does the UE (MCVideo Client) provide transmission granted notification to the MCVideo User?

(NOTE 1

2

P

9

Make the MCVideo User request to release transmission control.

(NOTE 1)

10

Check: Does the UE (MCVideo Client) send a Transmission End Request message indicating that it wants to terminate a MCVideo On-demand Pre-arranged Broadcast Group Call?

–>

Transmission End Request

3

P

11

The SS (MCVideo Server) responds with a Transmission end response message to the UE (MCVideo Client) to verify that the UE (MCVideo Client) is able to end a MCVideo On-demand Pre-arranged Broadcast Group Call.

<–

Transmission End Response

12

Check: Does the UE (MCVideo Client) notify the MCVideo User that the media transmission is completed?

(NOTE 1)

3

P

13

Check: Does the UE (MCVideo Client) send a SIP BYE request to terminate the MCVideo session?

–>

SIP BYE

3

P

14

The SS (MCVideo Server) responds to the UE (MCVideo Client) with a SIP 200 (OK) message to indicate acceptance to end the Broadcast Group Call.

<–

SIP 200 (OK)

EXCEPTION: SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This action is expected to be done via a suitable implementation dependent MMI.

6.1.1.7.3.3 Specific message contents

Table 6.1.1.7.3.3-1: SIP INVITE (Step 2, Table 6.1.1.7.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.7.3.3-2

Table 6.1.1.7.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.7.3.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

broadcast-ind

true

Table 6.1.1.7.3.3-3: SIP 200 (OK) (Step 4, Table 6.1.1.7.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.7.3.3-2

Table 6.1.1.7.3.3-4: Transmission Granted (Step 6, Table 6.1.1.7.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

A value of 1 in any one or more bits indicates type of condition as shown below.

Transmission Indicator

"0100000000000001"

A value of 1 in any one or more bits indicates type of condition as follows:

B = Broadcast group call

A ‘1’ in the last bit = acknowledgement is required.

TS 24.581 [27], clause 9.2.5.1

Table 6.1.1.7.3.3-5: Transmission Control Ack (Step 7, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], 5.5.11.3.5-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

"10000"

Transmission Control Ack message for Transmission Granted message that requested acknowledgment.

Table 6.1.1.7.3.3-6: SIP BYE (Step 13, Table 6.1.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2-1, condition MO_CALL

Table 6.1.1.7.3.3-7: SIP 200 (OK) (Step 14, Table 6.1.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included

6.1.1.8 On-network / On-demand Pre-arranged Group Call / Broadcast Group Call / Client Terminated (CT)

6.1.1.8.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo Client receives a SIP INVITE message of an MCVideo On-demand Pre-arranged Broadcast Group Call from the SS (MCVideo Server) }

then { the UE (MCVideo Client) responds with a SIP 200 (OK) message }

}

(2)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Broadcast Group Call, with implicit Reception Control }

ensure that {

when { the UE (MCVideo Client) receives a Media Transmission Notification message from the SS (MCVideo Server) and 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 provides receive media success notification to the MCVideo User and provides a notification to the MCVideo User indicating the type of call }

}

(3)

with { the UE (MCVideo Client) having an ongoing On-demand Pre-arranged Broadcast Group Call, with implicit Reception Control }

ensure that {

when {the UE (MCVideo Client) receives a Media Reception End Request message }

then {UE (MCVideo Client) responds with a Media Reception End Response message and informs the MCVideo User that the receiving RTP media is being ended and provides a notification to the MCVideo User indicating the type of call }

}

(4)

with { the UE (MCVideo Client) having received a Media Reception End Request message }

ensure that {

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

then { the UE (MCVideo Client) responds with a SIP 200 (OK) message and leaves the call }

}

6.1.1.8.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in TS 24.281, clauses 9.2.1.2.1.2, 6.2.6, and 10.2.2.2.2; TS 24.581, clause 6.2.5.3.3, 6.2.5.3.4, 6.2.5.3.5, and 6.2.5.5.5. 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 9.2.1.2.1.2]

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 an initial SIP INVITE request, the MCVideo client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [11] with the clarifications below.

The MCVideo client:

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

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

b) 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 [51] and warning texts as specified in subclause 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 subclause;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, clause 6.2.6]

Upon receiving a SIP BYE request, the MCVideo client:

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

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

[TS 24.281, clause 10.2.2.2.2]

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

The MCVideo client:

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

a) MCVideo client is already occupied in another session and the number of simultaneous sessions exceeds <MaxCall>, the maximum simultaneous MCVideo session for private call, as specified in TS 24.484 [25];

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

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

otherwise, continue with the rest of the steps.

NOTE 1: 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 choose to accept the request.

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 subclause 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 according to <allow-failure-restriction> as specified in 3GPP TS 24.484 [25] and skip the rest of the steps of this subclause;

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 private call and:

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

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

b) shall set the MCVideo emergency private priority state to "MVEPP 2: in-progress" for this private call;

4) if the SDP offer of the SIP INVITE request contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCVideo ID of the originating MCVideo client from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8];

b) shall convert the MCVideo ID to a UID as described in 3GPP TS 33.180 [8];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [8];

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP INVITE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [34], and include warning text set to "136 authentication of the MIKEY-SAKE I_MESSAGE failed" in a Warning header field as specified in subclause 4.4; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [8]; and

ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [8];

NOTE 2: With the PCK successfully shared between the originating MCVideo client and the terminating MCVideo client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.

5) may 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) may display to the MCVideo user the MCVideo ID of the inviting MCVideo user;

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

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

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

c) SIP INVITE request contains a Priv-Answer-Mode header field with the value of "Auto"; and

8) shall perform the manual commencement procedures specified in subclause 6.2.3.2.1 if either of the following conditions are met:

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

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

c) SIP INVITE request contains a Priv-Answer-Mode header field with the value of "Manual".

Upon receiving the SIP CANCEL request cancelling a SIP INVITE request for which a dialog exists at the MCVideo client and a SIP 200 (OK) response has not yet been sent to the SIP INVITE request then the MCVideo client:

1) shall send a SIP 200 (OK) response to the SIP CANCEL request according to 3GPP TS 24.229 [11]; and

2) shall send a SIP 487 (Request Terminated) response to the SIP INVITE request according to 3GPP TS 24.229 [11].

Upon receiving a SIP BYE request for an established dialog, the MCVideo client:

shall follow the procedures in subclause 10.2.5.2.

[TS 24.581, clause 6.2.5.3.3]

Upon receiving an indication from the user to request permission to receive media, the transmission participant:

1. shall send the Receive Media Request message toward the transmission control server; The Receive Media Request message:

a. if a different priority than the normal priority is required, shall include the Reception Priority field with the priority not higher than negotiated with the transmission control server as specified in subclause 14.3.3; and

b. if the receive media request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Transmission Indicator field indicating the relevant call types;

2. shall create an instance of the ‘Transmission participant state transition diagram for basic reception control operation’;

3. shall map the stored User ID and the SSRC of the user transmitting the media with instance of ‘Transmission participant state transition diagram for basic reception control operation’ created in step 2; and

4. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.4]

Upon receiving a Transmission end notify message, the transmission participant:

1. shall inform the user about the media transmission ended by another user; and

2. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.5]

Upon receiving an MCVideo call release step 1 request from the application and signalling plane when the MCVideo call is going to be released or when the transmission participant is leaving the MCVideo call, the transmission participant:

1. shall stop receiving reception control messages;

2. shall request the MCVideo client to stop receiving RTP media packets; and

3. shall enter the ‘Call releasing’ state.

[TS 24.581, clause 6.2.5.5.5]

Upon receiving a Media reception end request message, the transmission participant:

1. if the first bit in the subtype of the Media reception end request message set to "1" (Acknowledgment is required) as described in subclause 8.3.2, shall send a Reception control Ack message. The Reception control Ack message:

a. shall include the Message Type field set to ‘2’ (Media reception end request);

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

c. shall include the Message Name field set to MCV2.

2. shall inform the user that the receiving RTP media is being ended;

3. may give information to the user about the reason for ending the received RTP media;

4. shall request the MCVideo client to discard any remaining buffered RTP media packets and stop displaying to user;

5. shall send a Media reception end response message towards the transmission control server;

6. may provide a Media reception end notification to the MCVideo user;

7. if the Receive Media Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

8. shall enter the ‘terminated’ state.

6.1.1.8.3 Test description

6.1.1.8.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.2A.

– 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.8.3.2 Test procedure sequence

Table 6.1.1.8.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.4A ‘Generic Test Procedure for MCVideo CT communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

1

The SS (MCVideo Server) sends a SIP INVITE to the UE (MCVideo Client) to initiate an On-demand pre-arranged Broadcast Group Call, with explicit Reception Control by sending a SIP INVITE message.

<–

SIP INVITE

EXCEPTION: Step 2a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that take place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message.

2a1

Check: Does the UE (MCVideo Client) respondwith a SIP 100 (Trying) message?

–>

SIP 100 (Trying)

1

P

3

Check: Does the UE (MCVideo Client) send a SIP 200 (OK) message?

–>

SIP 200 (OK)

1

P

4

The SS (MCVideo Server) sends a SIP ACK message to the UE (MCVideo Client) to acknowledge the SIP 200 (OK) message.

<–

SIP ACK

5

The SS (MCVideo Server) notifies the UE (MCVideo Client) that there is a broadcast message waiting for him to receive.

<–

Media Transmission Notification

6

Make the MCVideo User request permission to receive media.

(NOTE 1)

7

Check: Does the UE (MCVideo Client) request permission to receive the message?

–>

Receive Media Request

2

P

8

The SS (MCVideo Server) responds to the Receive Media Request message.

<–

Receive Media Response

9

Check: Does the UE (MCVideo client) provide receive media success notification to the MCVideo User and provide a notification to the MCVideo User indicating the type of call?

(NOTE 1)

2

P

10

The SS (MCVideo Server) sends a Media Reception End Request message.

<–

Media Reception End Request

11

Check: Does the UE (MCVideo Client) respond with a Media Reception End Response message?

–>

Media Reception End Response

3

P

12

Check: Does the UE (MCVideo Client) inform the MCVideo User that the receiving RTP media is being ended and provide a notification to the MCVideo User indicating the type of call?

(NOTE 1)

3

P

13

The SS (MCVideo Server) sends a SIP BYE message.

<–

SIP BYE

14

Check: Does the UE (MCVideo Client) send a SIP 200 (OK) message?

–>

SIP 200 (OK)

4

P

EXCEPTION: SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This action is expected to be done via a suitable implementation dependent MMI.

6.1.1.8.3.3 Specific message contents

Table 6.1.1.8.3.3-1: SIP INVITE (Step 1, Table 6.1.1.8.3.2-1)

Derivation Path: TS 36-579-1 [2], Table 5.5.2.5.2-1, conditions MCVIDEO, BROADCAST CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

RFC 3261 [22]

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.8.3.3-2

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

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-2, conditions GROUP-CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

broadcast-ind

true

Table 6.1.1.8.3.3-3: SIP 200 (OK) (Step 3, Table 6.1.1.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.8.3.3-4

Table 6.1.1.8.3.3-4: MCVideo-Info in SIP INVITE (Table 6.1.1.8.3.3-3)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

broadcast-ind

true

Table 6.1.1.8.3.3-5: Receive Media Request (Step 7, Table 6.1.1.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.1.4-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0100000000000000’

B = Broadcast Call

Table 6.1.1.8.3.3-6: Receive Media Response (Step 8, Table 6.1.1.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.9-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0100000000000000’

B = Broadcast Call

Table 6.1.1.8.3.3-7: Media Reception End Request (Step 10, Table 6.1.1.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.4-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0100000000000000’

B = Broadcast Call

Table 6.1.1.8.3.3-8: SIP BYE (Step 13 Table 6.1.1.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2.2-1, condition MO_CALL

Information Element

Value/remark

Comment

Reference

Condition

Table 6.1.1.8.3.3-9: SIP 200 (OK) (Step 14, Table 6.1.1.8.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition MO_CALL

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

6.1.1.9 On-network / On-demand Pre-arranged Group Call / Broadcast Group Call with Temporary Group / Client Originated (CO)

6.1.1.9.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 a MCVideo On-demand Pre-arranged Broadcast Group Call with a Temporary Group }

then { the UE (MCVideo Client) requests On-demand Pre-arranged Broadcast Group Call by sending a SIP INVITE message and responds to a SIP 200 (OK) message with a SIP ACK message }

}

(2)

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

ensure that {

when { the MCVideo User requests to terminate the ongoing MCVideo Broadcast Group Call before the Broadcast has been completed }

then { the UE (MCVideo Client) sends a SIP BYE request and leaves the MCVideo Session }

}

6.1.1.9.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in TS 24.281, clauses 9.2.1.2.1.1, 6.2.8.2, 6.2.4.1; also, TS 24.481, clause 6.3.14. 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 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:

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

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

[TS 24.281, clause 6.2.8.2]

NOTE: This subclause is referenced from other procedures.

When the MCVideo user initiates a broadcast group call, the MCVideo client:

1) in the case of the prearranged group call is initiated on-demand, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body the <broadcast-ind> element set to "true" as defined in clause F.1; and

2) in the case the prearranged group call is initiated using a pre-established session, shall include in the application/vnd.3gpp.mcvideo-info+xml MIME body in the "body" URI header field in the Refer-To header field the <broadcast-ind> element set to "true" as defined in clause F.1.

[TS 24.281, clause 6.2.4.1]

Upon receiving a request from an MCVideo user to leave an MCVideo session established using on-demand session signalling, the MCVideo client:

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

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [11];

3) shall set the Request-URI to the MCVideo session identity to leave; and

4) shall send a SIP BYE request towards MCVideo server according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCVideo client shall interact with the media plane as specified in 3GPP TS 24.581 [5].

[TS 24.481, clause 6.3.14]

In order to form a temporary MCS group, a GMC shall send a HTTP POST request according to procedures specified in IETF RFC 2616 [21] and subclause 6.2.3. In the HTTP POST request, the GMC:

a) shall set the Request-URI to an XCAP URI:

1) in users tree where the XUI is set to a group creation XUI configuration parameter; and

2) with the document selector identifying the temporary MCS group to be created; and

b) shall include an application/vnd.3gpp.GMOP+xml MIME body containing a GMOP document requesting group regroup creation specified in subclause 7.3.4.3, with a <group> element containing a group document for an MCS group. In the group document, the GMC shall include the <on-network-temporary> element according to subclause 7.2. In the <on-network-temporary> element, the GMC shall include <constituent-MCPTT-group-IDs> element according to subclause 7.2. In the <constituent-MCPTT-group-IDs> element, the GMC shall include one <constituent-MCPTT-group-ID> element according to subclause 7.2 for each MCS group to be combined.

Upon reception of an HTTP 2xx response to the sent HTTP POST request, the GMC shall consider the temporary MCS group formation as successful.

Upon reception of an HTTP 409 (Conflict) response with at least one <alt-value> element in the <uniqueness-failure> error element, the GMC may repeat procedures of the present subclause and identify the temporary MCS group being formed with an MCS Group ID indicated in an <alt-value> element.

6.1.1.9.3 Test description

6.1.1.9.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.2A.

– The UE has affiliated to a MCVideo temporary group identity TGI, identifying a MCVideo temporary group B as a member of MCVideo broadcast group A.

– 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.9.3.2 Test procedure sequence

Table 6.1.1.9.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User request the establishment of a MCVideo On-demand Pre-arranged Broadcast Group call for the selected MCVideo temporary group GROUP B as a member of the MCVideo broadcast group GROUP A, with explicit Transmission Control.

(NOTE 1)

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 56.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo Client) send an initial SIP INVITE requesting the establishment of a MCVideo On-demand pre-arranged broadcast group call with temporary group?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) sends a SIP 100 (Trying) message

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) sends SIP 200 (OK), indicating that the MCVideo call has been established.

<–

SIP 200 (OK)

5

Check: Does the UE (MCVideo Client) send a SIP ACK message in response to the SIP 200 (OK) message?

–>

SIP ACK

1

P

6

Make the MCVideo User request to terminate the Broadcast Group call.

(NOTE 1)

7

Check: Does the UE (MCVideo Client) send a SIP BYE request to terminate the MCVideo Broadcast session before the broadcast has been completed?

–>

SIP BYE

2

P

8

The SS (MCVideo Server) sends a SIP 200 (OK) to the UE (MCVideo Client).

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This is expected to be done via a suitable implementation dependent MMI command.

6.1.1.9.3.3 Specific message contents

Table 6.1.1.9.3.3-1: SIP INVITE (Step 2, Table 6.1.1.9.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, conditions GROUP-CALL, MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.9.3.3-2

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

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

broadcast-ind

"True"

mcvideo-request-uri

px_MCVideo_Group_B_ID

associated-group-id

px_MCVideo_Group_A_ID

Table 6.1.1.9.3.3-3: SIP 200 (OK) (Step 2, Table 6.1.1.9.3.2-1)

Derivation Path: TS 36.579-1, Table 5.5.2.17.1.2.-1, conditions INVITE-RSP, MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.9.3.3-4

Table 6.1.1.9.3.3-4: MCVideo-Info in SIP 200 (OK) (Table 6.1.1.9.3.3-3)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

broadcast-ind

"True"

mcvideo-request-uri

px_MCVideo_Group_B_ID

Table 6.1.1.9.3.3-5: SIP BYE (Step 7, Table 6.1.1.9.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MO_CALL

Table 6.1.1.9.3.3-6: SIP 200 (OK) (Step 8, Table 6.1.1.9.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included

6.1.1.10 On-network / On-demand Pre-arranged Group Call / Imminent Peril Group Call / Client Originated (CO)

6.1.1.10.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 Imminent Peril Group Call }

then { the UE (MCVideo Client) sends a SIP INVITE message to setup the Imminent Peril Group Call }

}

(2)

with { the UE (MCVideo Client) having established an MCVideo On-demand Pre-arranged Imminent Peril Group Call }

ensure that {

when { the MCVideo User receives a Transmission Granted message ) }

then { the UE (MCVideo Client) responds with a Transmission Control Ack message and provides Transmission granted notification to the MCVideo User and respects Transmission Control (Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission Control Response) }

}

(3)

with { the UE (MCVideo Client) having an ongoing MCVideo On-demand Pre-arranged Imminent Peril Group Call }

ensure that {

when { the MCVideo User requests to release Transmission control }

then { the UE (MCVideo Client) sends a Transmission End Request message and then responds to the Transmission End Response message with a Transmission Control ACK message }

}

(4)

with { the UE (MCVideo Client) having released Transmission control }

ensure that {

when { the MCVideo User requests to terminate the On-demand Pre-arranged Imminent Peril Group Call }

then { the UE (MCVideo Client) sends a SIP BYE request and leaves the MCVideo Session }

}

6.1.1.10.2 Conformance requirements

References: The conformance requirements covered in the current Test Caseare specified in TS 24.281, clauses 9.2.1.2.1.1 and 6.2.8.1.9; TS24.581 clauses 6.2.4.2.2, 6.2.4.4.6, 6.2.4.5.3, 6.2.4.6.4. 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 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 6.2.8.1.9]

This subclause is referenced from other procedures.

When the MCVideo client receives a request from the MCVideo user to originate an MCVideo imminent peril group call, and this is an authorised request for an MCVideo imminent peril group call as determined by the procedures of subclause 6.2.8.1.8, the MCVideo client:

1) if the MCVideo client imminent peril group state is set to "MVIGC 1: imminent-peril-capable" and the in-progress emergency state of the group is set to a value of "false":

a) shall include in the SIP request a MIME mcvideoinfo body as defined in Annex F.1 with the <imminentperil-ind> element set to "true" and set the MCVideo emergency group call state to "MVIGC 2: imminent-peril-call-requested" state; and

b) if the MCVideo client imminent peril group state of the group is set to a value other than "MVIG 2: in-progress" shall set the MCVideo client emergency group state of the MCVideo group to "MVIG 3: confirm-pending".

NOTE: An MCVideo group call originated by an affiliated member of an MCVideo group which is in an in-progress imminent peril state (as tracked on the MCVideo client by the MCVideo client imminent peril group state) will also have the priority associated with MCVideo imminent peril group calls. The <imminentperil-ind> element of the MIME mcvideoinfo body does not need to be included in this case, nor do any state changes result and hence no action needs to be taken in this subclause.

[TS 24.581, clause 6.2.4.2.2]

When a call is initiated as described in 3GPP TS 24.281 [2], the transmission participant:

1. shall create an instance of the ‘Transmission participant state transition diagram for basic transmission control operation’;

2. if the originating transmission participant receives a transmission control message before it receives the SIP 200 (OK) response, shall store the transmission control message;

NOTE: The originating transmission participant might receive a transmission control message before the SIP 200 (OK) response when initiating, joining or rejoining a call because of processing delays of the SIP 200 (OK) response in the SIP core.

3. if the established MCVideo call is a chat group call and the SIP INVITE request is not an implicit Transmission request, shall enter the ‘U: has no permission to transmit’ state;

4. if for the established MCVideo call the SIP INVITE request is an implicit Transmission request:

a. shall start timer T100 (Transmission Request) and initialise counter C100 (Transmission Request) to 1;

b. shall enter the ‘U: pending request to transmit’ state; and

c. if the transmission participant has received and stored a transmission control message before the reception of the SIP 200 (OK) response, shall act as if the transmission control message was received in the ‘U: pending request to transmit’ state after entering the ‘U: pending request to transmit’ state; and

5. if the established MCVideo call is a broadcast group call, shall enter the ‘U: has permission to transmit’ state.

When the transmission participant is rejoining an ongoing MCVideo call as described in 3GPP TS 24.281 [2] the transmission participant shall enter the ‘U: has no permission to transmit’ state.

[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 provide Transmission granted notification to the user, if not already done;

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

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

[TS 24.581, clause 6.2.4.5.3]

Upon receiving an indication from the user to end the permission to send RTP media, the transmission participant:

1. shall send a Transmission end request message towards the transmission control server. The Transmission end request message, if the session is a broadcast call and if the session was established as a normal call, shall include the Transmission Indicator with the A-bit set to ‘1’ (Normal call);

2. shall start timer T101 (Transmission End Request) and initialize counter C101 (Transmission End Request) to 1; and

3. shall enter the ‘U: pending end of transmission’ state.

[TS 24.581, clause 6.2.4.6.4]

Upon receiving a Transmission end response message, the transmission participant:

1. if the first bit in the subtype of the Transmission end response message 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 ‘1’ (Transmission end response); and

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

2. may provide a Transmission end notification to the MCVideo user;

3. if the Transmission Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T101 (Transmission End Request);

5. if the session is not a broadcast group call or if the A-bit in the Transmission Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission to transmit’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCVideo client the media transmission is completed; and

b shall enter the ‘Call releasing’ state.

6.1.1.10.3 Test description

6.1.1.10.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.2A.

– 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.10.3.2 Test procedure sequence

Table 6.1.1.10.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User request the establishment of a MCVideo On-demand Pre-arranged Imminent Peril Group call for the selected MCVideo Imminent Peril Group g A, with implicit Transmission Control.

(NOTE 1)

EXCEPTION: The E-UTRA/EPC actions which are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo client) send an initial SIP INVITE message requesting the establishment of an MCVideo On-demand pre-arranged Imminent Peril Group Call with implicit Transmission Control?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) sends a SIP 100 (Trying) message

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) sends SIP 200 (OK) message, indicating that the MCVideo call has been established.

<–

SIP 200 (OK)

5

Check: Does the UE (MCVideo client) send a SIP ACK message in response to the SIP 200 (OK) message?

–>

SIP ACK

1

P

6

The SS (MCVideo Server) sends a Transmission Granted message.

<–

Transmission Granted

7

Check: Does the UE (MCVideo Client) responds with a Transmission Control ACK message?

–>

Transmission Control ACK

2

P

8

Check: Does the UE (MCVideo Client) provide Transmission granted notification to the user?

(NOTE 1).

2

P

9

Make the MCVideo User release Transmission Control.

(NOTE 1)

10

Check: Does the UE (MCVideo Client send a Transmission End Request message to leave the Group Call?

–>

Transmission End Request

3

P

11

The SS (MCVideo Server) responds to the Transmission End Request message.

<–

Transmission End Response

12

Check: Does the UE (MCVideo Client acknowledge the SS (MCVideo Server) Response?

–>

Transmission Control ACK

3

P

13

Make the MCVideo User end the call.

(NOTE 1)

14

Check: Does the UE (MCVideo Client) send a SIP BYE message?

–>

SIP BYE

4

P

15

The SS (MCVideo Server) sends a SIP 200 (OK) message.

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) releases the E-UTRA connection.

Note 1: On-network / On-demand Pre-arranged Group Call / Imminent Peril Group Call / Client Originated (CO)

6.1.1.10.3.3 Specific message contents

Table 6.1.1.10.3.3-1: SIP INVITE (Step 2, Table 6.1.1.10.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, conditions MCVIDEO, IMMINENT PERIL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.10.3.3-2

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

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, conditions GROUP-CALL, IMMINENT PERIL

Table 6.1.1.10.3.3-3: SIP 200 (OK) (Step 4, Table 6.1.1.10.3.2.-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditions MCVIDEO, INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.1.10.3.3-4

Table 6.1.1.10.3.3-4: MCVideo-Info in SIP INVITE (Table 6.1.1.10.3.3-3)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-2, conditions GROUP-CALL, IMMINENT PERIL

Table 6.1.1.10.3.3-5: Transmission Granted (Step 6, Table 6.1.1.10.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

"0000100000000000"

bit E=1 (Imminent Peril).

Table 6.1.1.10.3.3-6: Transmission End Response (Step 12, Table 6.1.1.10.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.2-1

Information Element

Value/remark

Comment

Reference

Condition

Subtype

"10001"

A ‘1’ in the first bit = Acknowledgement Required

Table: 6.1.1.10.3.3-6A: Transmission Control Ack

Derivation Path: TS 24.581 [88] Table 9.2.31-1

Information Element

Value/remark

Comment

Reference

Condition

Message type

Message Type

"00010001"

value is an 8 bit binary value containing the binary value consisting of the 5 bit message subtype as coded in table 9.2.2.1-1, table 9.2.2.1-2 and table 9.2.2.1-3 (including the first bit (used by some transmission control messages to indicate that a Transmission control Ack message is requested) of the five bit subtype) preceded by "000".

Table 6.1.1.10.3.3-7: SIP BYE (Step 14, Table 6.1.1.10.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MO_CALL

Table 6.1.1.10 3.3-8: SIP 200 (OK) (Step 15, Table 6.1.1.10.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included

6.1.1.11 On-network / On-demand Pre-arranged Group Call / Imminent Peril Group Call / Client Terminated (CT)

6.1.1.11.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo Client receives a SIP INVITE message of an MCVideo On-demand Pre-arranged Imminent Peril Group Call and the MCVideo User answers the call }

then { the MCVideo Client responds to the SS (MCVideo Server) with a SIP 200 (OK) message }

}

(2)

with { the UE (MCVideo Client) having an ongoing MCVideo Pre-arranged Imminent Peril Group Call }

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 and sends a Receive Media Request message to the SS (MCVideo Server) }

(3)

with { the UE (MCVideo Client) having an ongoing MCVideo On-network Pre-arranged Imminent Peril Group Call }

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 }

}

(4)

with { the UE (MCVideo Client) having an ongoing MCVideo On-demand Pre-arranged Imminent Peril Group Call }

ensure that {

when { the MCVideo User requests to terminate the On-demand Pre-arranged Imminent Peril Group Call }

then { the UE (MCVideo Client) sends a SIP BYE message and leaves the MCVideo Session }

}

6.1.1.11.2 Conformance requirements

References: The conformance requirements covered in the current Test Case are specified in TS 24.281, clauses 9.2.1.2.1.2, TS 24.581 clauses 6.2.5.2.2, 6.2.5.3.2, 6.2.5.3.3, 6.2.5.4.5, 6.2.5.5.3, 6.2.5.6.4. 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 9.2.1.2.1.2]

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 an initial SIP INVITE request, the MCVideo client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [11] with the clarifications below.

The MCVideo client:

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

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

b) 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 [51] and warning texts as specified in subclause 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 subclause;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.581, clause 6.2.5.2.2]

When an MCVideo call is established, the terminating transmission participant:

1. shall create an instance of a ‘Transmission participant state transition diagram for general reception control operation’; and

2. shall enter the ‘U: reception controller’ state.

NOTE: From a transmission participant perspective the MCVideo call is established when the application and signalling plane sends the SIP 200 (OK) response.

[TS 24.581, clause 6.2.5.3.2]

Upon receiving the media transmission notification from the transmission control server, the transmission participant:

1. if the first bit in the subtype of the media transmission notification 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 ‘6’ (Media transmission notification); and

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

2. shall provide media transmission notification to the user;

3. shall store the User ID and the SSRC of the user transmitting the media;

4. may display the details of the incoming media to the user; and

5. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.3]

Upon receiving an indication from the user to request permission to receive media, the transmission participant:

1. shall send the Receive Media Request message toward the transmission control server; The Receive Media Request message:

a. if a different priority than the normal priority is required, shall include the Reception Priority field with the priority not higher than negotiated with the transmission control server as specified in subclause 14.3.3; and

b. if the receive media request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Transmission Indicator field indicating the relevant call types;

2. shall create an instance of the ‘Transmission participant state transition diagram for basic reception control operation’;

3. shall map the stored User ID and the SSRC of the user transmitting the media with instance of ‘Transmission participant state transition diagram for basic reception control operation’ created in step 2; and

4. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.4.5]

Upon receiving a granted response for Receive media request message, the transmission participant:

1. if the first bit in the subtype of the Receive media response 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 ‘7’ (Receive media response); and

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

2. shall provide receive media success notification to the user;

3. if the Receive Media Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T103 (Receive Media Request); and

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

[TS 24.581, clause 6.2.5.5.3]

Upon receiving an indication from the user to end the RTP media reception, the transmission participant:

1. shall send a Media reception end request message towards the transmission control server The Media reception end request message:

a. if the session is a broadcast call and if the session was established as a normal call, shall include the Transmission Indicator with the A-bit set to ‘1’ (Normal call); and

b. shall include the SSRC of user transmitting the media in the Media reception end request message;

2. shall remove the indication that the participant is overriding without revoke if this indication is stored;

3. shall remove the indication that the participant is overridden without revoke if this indication is stored;

4. shall start timer T104 (Receive Media Release) and initialize counter C104 (Receive Media Release) to 1; and

5. shall enter the ‘U: pending reception release’ state.

[TS 24.581, clause 6.2.5.6.4]

Upon receiving a MRE response message, the transmission participant:

1. if the first bit in the subtype of the MRE response message 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 ‘3’ (Media reception end response); and

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

2. may provide a Media reception end notification to the MCVideo user;

3. if the Receive Media Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T104 (Receive Media Release); and

5. shall enter the ‘terminated’ state.

6.1.1.11.3 Test description

6.1.1.11.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 MCPTT operation in the MCPTT 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 MCPTT User performs the Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2A.

– 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.11.3.2 Test procedure sequence

Table 6.1.1.11.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: The E-UTRA/EPC actions that are related to the MCVIDEO call establishment are described in TS 36.579-1 [2], subclause 5.4.4A ‘Generic Test Procedure for MCVideo CT communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

1

The SS (MCVideo Server) initiates an on-demand Imminent Peril group call with implicit Transmission Control.

<–

SIP INVITE

EXCEPTION: Steps 2a1 through 2a4 describe behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that take place if the UE (MCVideo Client) responds to a SIP INVITE prior to the MCVIDEO user’s acknowledgment.

2a1

(Optional) The UE (MCVideo Client) responds with a SIP 100 Trying provisional response.

–>

SIP 100 (Trying)

2a2

(Optional) The UE (MCVideo Client) respond with a SIP 183 (Session Progress) message?

–>

SIP 183 (Session Progress)

2a3

The SS (MCVideo Server) responds to the SIP 183 (Session Progress) message with a SIP PRACK message.

<–

SIP PRACK

2a4

The UE (MCVideo Client) acknowledges the SIP PRACK message with SIP 200 (OK) message.

–>

SIP 200 (OK)

3

Make the MCVideo User answer the call.

(NOTE 1)

4

Check: Does the UE (MCVideo Client) answer the call with a SIP 200 (OK)?

–>

SIP 200 (OK)

1

P

5

The SS (MCVideo Server) acknowledges the receipt of a SIP 200 (OK) for the SIP INVITE message.

<–

SIP ACK

6

The SS (MCVideo Server) sends a Media Transmission Notification message.

<–

Media Transmission Notification

7

Check: Does the UE (MCVideo Client) provide media transmission notification to the MCVideo User?

2

P

8

Make the MCVideo User request permission to receive media.

(NOTE 1)

9

Check: Does the UE (MCVideo Client) send a Receive Media Request message?

–>

Receive Media Request

2

P

10

The SS (MCVideo Server) sends a Receive Media Response message.

<–

Receive Media Response

11

Make the MCVideo User request to end the RTP media reception.

(NOTE 1)

12

Check: Does the UE (MCVideo Client) send a Media Reception End Request to indicate that the user wishes to end the RTP media reception?

–>

Media Reception End Request

3

P

13

The SS (MCVideo Server) responds with a Media Reception End Response message.

<–

Media Reception End Response

14

Make the MCVideo User end the call.

(NOTE 1)

15

Check: Does the UE (MCVideo Client) send a SIP BYE message to leave the MCVideo session?

–>

SIP BYE

4

P

16

The SS (MCVideo Server) sends a SIP 200 (OK).

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.1.1.11.3.3 Specific message contents

Table 6.1.1.11.3.3-1: SIP INVITE (Step 1, Table 6.1.1.11.3.2-1)

Derivation Path: TS 56.379-1 [2], Table 5.5.2.5.2-1, conditions GROUP-CALL, IMMPERIL-CALL, MANUAL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.11.3.3-2

Table 6.1.1.11.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.11.3.3-1)

Derivation Path: TS 56.379-1 [2], Table 5.5.3.2.2-2, conditions GROUP-CALL, IMMPERIL-CALL

Table 6.1.1.11.3.3-3: SIP 183 (Session Progress) (Step 2a2, Table 6.1.1.11.3.2-1)

Derivation Path: TS 56.379-1 [2], Table 5.5.2.16.3.1-1, conditions MCVIDEO

Table 6.1.1.11.3.3-4: SIP 200 (OK) (Step 2a4, Table 6.1.1.11.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

Table 6.1.1.11.3.3-5: Void

Table 6.1.1.11.3.3-6: VoidTable 6.1.1.11.3.3-7: Receive Media Request (Step 9, Table 6.1.1.6.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.1.4-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0000100000000000’

E = Imminent Peril

Table 6.1.1.11.3.3-8: Receive Media Response (Step 10, Table 6.1.1.6.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.8-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0000100000000000’

E = Imminent Peril

Table 6.1.1.11.3.3-9: Media Reception End Request (Step 12, Table 6.1.1.6.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.3-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0000100000000000’

E = Imminent Peril

Table 6.1.1.11.3.3-10: SIP BYE (Step 13 Table 6.1.1.11.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.2-1, condition MO-CALL

Table 6.1.1.11.3.3-11: SIP 200 (OK) (Step 16, Table 6.1.1.11.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

6.1.1.12 On-network / On-demand Pre-arranged Group Call / Transmission Control State Transitions / Client Originated (CO)

6.1.1.12.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) and requests to terminate the ongoing MCVideo Group Call }

then { the UE (MCVi Media Reception Notification, deo Client) respects the Transmission Control imposed by the SS(MCVideo Server) (Transmission Granted, Media Reception Notification, Transmission Revoked, Queue Position Request, Queue Position Info, Transmission Control ACK, Transmission End Request, Transmission End Response, Transmission Request, Transmission Rejected, Transmission Cancel Request Notify }

}

(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 to end the call }

then { the UE (MCVideo Client sends SIP BYE message, and leaves the MCVideo Session }

}

6.1.1.12.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.4.1, 9.2.1.2.1.1, TS 24.581, clauses 6.2.4.2.2, 6.2.4.3.2, 6.2.4.4.2, 6.2.4.4.5, 6.2.4.4.6, 6.2.4.5.5, 6.2.4.5.6, 6.2.4.5.7, 6.2.4.6.4, 6.2.4.8.2, 6.2.4.9.2, 6.2.4.9.4, 6.2.4.9.6. 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.4.1]

Upon receiving a request from an MCVideo user to leave an MCVideo session established using on-demand session signalling, the MCVideo client:

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

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [11];

3) shall set the Request-URI to the MCVideo session identity to leave; and

4) shall send a SIP BYE request towards MCVideo server according to 3GPP TS 24.229 [11].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCVideo client shall interact with the media plane as specified in 3GPP TS 24.581 [5].

[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.581, clause 6.2.4.2.2]

When a call is initiated as described in 3GPP TS 24.281 [2], the transmission participant:

1. shall create an instance of the ‘Transmission participant state transition diagram for basic transmission control operation’;

2. if the originating transmission participant receives a transmission control message before it receives the SIP 200 (OK) response, shall store the transmission control message;

NOTE: The originating transmission participant might receive a transmission control message before the SIP 200 (OK) response when initiating, joining or re-joining a call because of processing delays of the SIP 200 (OK) response in the SIP core.

3. if the established MCVideo call is a chat group call and the SIP INVITE request is not an implicit Transmission request, shall enter the ‘U: has no permission to transmit’ state;

4. if for the established MCVideo call the SIP INVITE request is an implicit Transmission request:

a. shall start timer T100 (Transmission Request) and initialise counter C100 (Transmission Request) to 1;

b. shall enter the ‘U: pending request to transmit’ state; and

c. if the transmission participant has received and stored a transmission control message before the reception of the SIP 200 (OK) response, shall act as if the transmission control message was received in the ‘U: pending request to transmit’ state after entering the ‘U: pending request to transmit’ state; and

5. if the established MCVideo call is a broadcast group call, shall enter the ‘U: has permission to transmit’ state.

When the transmission participant is re-joining an ongoing MCVideo call as described in 3GPP TS 24.281 [2] the transmission participant shall enter the ‘U: has no permission to transmit’ state.

[TS 24.581, clause 6.2.4.3.2]

Upon receiving an indication from the user to request permission to send media, the transmission participant:

1. void

2. shall send the Transmission Request message toward the transmission control server; The Transmission Request message:

a. if a different priority than the normal priority is required, shall include the Transmission Priority field with the priority not higher than negotiated with the transmission control server as specified in subclause 14.3.3; and

b. if the Transmission request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Transmission Indicator field indicating the relevant call types;

3. shall start timer T100 (Transmission Request) and initialise counter C100 (Transmission Request) to 1; and

4. shall enter the ‘U: pending request to transmit’ state.

[TS 24.581, clause 6.2.4.4.2]

Upon receiving a Transmission rejected message, the transmission participant:

1. if the first bit in the subtype of the Transmission rejected 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 ‘1’ (Transmission rejected); and

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

2. shall provide Transmission rejected notification to the user;

3. may display the Transmission rejected reason to the user using information in the Reject Cause field;

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

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

[TS 24.581, clause 6.2.4.4.5]

Upon receiving a Queue Position Info message, the transmission participant:

1. if the first bit in the subtype of the Queue Position Info 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 ‘5’ (Queue Position Info); and

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

2. shall provide Transmission request queued notification to the MCVideo user;

3. may provide the queue position and priority to the MCVideo user; and

4. shall enter the ‘U: queued transmission’ state.

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

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

Upon receiving a Transmission Revoked message, the transmission participant:

1. shall inform the user that the permission to send RTP media is being revoked;

2. may give information to the user about the reason for revoking the permission to send media:

3. shall request the media in the MCVideo client discard any remaining buffered RTP media packets and to stop forwarding of encoded video to the MCVideo server; and

4. if the revoke reason is:

a. terminate the RTP stream, shall enter the ‘U: pending end of transmission’ state:

i. shall send a Transmission end request message towards the transmission control server; and

ii. shall start timer T101 (Transmission End Request) and initialize counter C101 (Transmission End Request) to 1; or

b. queue the transmission, shall enter the ‘U: queued transmission’ state:

i. shall send a Queue Position Request message towards the transmission control server; and

ii. shall start timer T102 (Transmission Queue Position Request) and initialize counter C102 (Queue Position Request) to 1.

[TS 24.581, clause 6.2.4.5.6]

Upon receiving a Media Reception notification message, the transmission participant:

1. shall inform the user about the media reception by another user; and

2. shall remain in the ‘U: has permission to transmit’ state.

[TS 24.581, clause 6.2.4.5.7]

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

1. shall inform the user that the permission to send RTP media is being revoked;

2. may give information to the user about the reason for terminating the permission to send media;

3. shall request the media in the MCVideo client to discard any remaining buffered RTP media packets and to stop forwarding of encoded video to the MCVideo server; and

4. shall send Transmission End Response message to the transmission control server.

5. if the session is not a broadcast group call or if the A-bit in the Transmission Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission to transmit’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCVideo client the media transmission is completed; and

b shall enter the ‘Call releasing’ state.

[TS 24.581, clause 6.2.4.6.4]

Upon receiving a Transmission end response message, the transmission participant:

1. if the first bit in the subtype of the Transmission end response message 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 ‘1’ (Transmission end response); and

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

2. may provide a Transmission end notification to the MCVideo user;

3. if the Transmission Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T101 (Transmission End Request);

5. if the session is not a broadcast group call or if the A-bit in the Transmission Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission to transmit’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCVideo client the media transmission is completed; and

b shall enter the ‘Call releasing’ state.

[TS 24.581, clause 6.2.4.8.2]

Upon receiving an MCVideo call release step 2 request from the application and signalling, the transmission participant:

1. shall release all resources including any running timers associated with the MCVideo call; and

2. shall enter the ‘Start-stop’ state and terminate the current instance of the ‘Transmission control state machine – basic’.

[TS 24.581, clause 6.2.4.9.2]

Upon receiving a Queue Position Info message, the transmission participant:

1. if the first bit in the subtype of the Queue Position Info 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 ‘5’ (Queue Position Info); and

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

2. if the message indicates that the request has been queued or if a request for the queue position was sent, the transmission participant:

a. may provide the queue position and priority (if available) to the MCVideo user;

3. shall stop the timer T102 (Transmission Queue Position Request), if running; and

4. shall remain in the ‘U: queued transmission’ state.

[TS 24.581, clause 6.2.4.9.4]

Upon receipt of an indication from the MCVideo client to cancel the media transmit request from the queue, the transmission participant:

1. shall send the Transmission end request message to the transmission control server. The Transmission end request message, if the session is a broadcast call and if the session was established as a normal call, shall include the Transmission Indicator with the A-bit set to ‘1’ (Normal call);

2. shall start timer T101 (Transmission End Request) and initialize counter C101 (Transmission End Request) to 1; and

3. shall enter the ‘U: pending end of transmission’ state.

[TS 24.581, clause 6.2.4.9.6]

Upon receiving a Transmission cancel request notify message, the transmission participant:

1. if the first bit in the subtype of the Transmission cancel request notify 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 ’10’ (Transmission cancel request notify); and

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

2. shall enter in the ‘U: has no permission to transmit’ state.

6.1.1.12.3 Test description

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

UE:

– 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.2A.

– 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.12.3.2 Test procedure sequence

Table 6.1.1.12.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)

EXCEPTION: The E-UTRA/EPC actions which are related to the MCVIDEO call establishment; steps are described in TS 36.579-1 [2], subclause 5.4.3A ‘Generic Test Procedure for MCVideo CO communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

2

Check: Does the UE (MCVideo Client) send an initial SIP INVITE requesting the establishment of an MCVideo On-demand Pre-arranged Group Call, Automatic Commencement Mode, with implicit Transmission Control?

–>

SIP INVITE

1

P

3

The SS (MCVideo Server) responds to the UE with a SIP 100 (Trying) message.

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client), indicating that it has accepted the SIP INVITE request from the UE.

<–

SIP 200 (OK)

5

Check: Does the UE (MCVideo Client) send an acknowledgement to the SS (MCVideo Server)?

–>

SIP ACK

1

P

6

The SS (MCVideo Server) sends a Transmission Granted message to the UE (MCVideo Client)

<–

Transmission Granted

6a

Check: Does the UE (MCVideo Client) provide transmission granted notification to the MCVideo User?

(NOTE1)

2

P

7

The SS (MCVideo Server) sends information about the media reception of another user.

<–

Media Reception Notification

7a

Check: Does the UE (MCVideo Client) inform the MCVideo User about the media reception from another user?

(NOTE1)

2

P

8

The SS (MCVideo Server) is revoking permission to transmit with revoke reason queue the transmission

<–

Transmission Revoked

8a

Check: Does the UE (MCVideo Client) inform the MCVideo User that the permission to send RTP media is being revoked?

(NOTE1)

2

P

9

Check: Does the UE (MCVideo Client) ask for queue information.?

(NOTE1)

–>

Queue Position Request

2

P

10

The SS (MCVideo Server) sends the queue information to the Client, with the first bit set to ‘1’.

<–

Queue Position Info

11

Check: Does the UE (MCVideo Client) acknowledges receipt of information about the queue position?

–>

Transmission Control Ack

2

P

12-

Make the MCVideo User request to end the transmission request and be removed from the queue.

(NOTE1)

12a

Check: Does the UE (MCVideo Client) requests to cancel the media transmit request from the queue?

–>

Transmission End Request

2

P

13

The SS (MCVideo Server) responds to end transmission.

<–

Transmission End Response

14

Make the MCVideo User request permission to send a video transmission.

(NOTE 1)

14a

Check: Does the UE (MCVideo Client) request permission to send a video transmission?

–>

Transmission Request

2

P

15

The SS (MCVideo Server) rejects the request.

<–

Transmission Rejected

15a

Check: Does the UE (MCVideo Client) inform the MCVideo User that the request to transmit was rejected?

(NOTE 1)

2

P

16

Make the MCVideo User request permission to send a video transmission.

(NOTE 1)

16a

Check: Does the UE (MCVideo Client) request permission to send a video transmission?

–>

Transmission Request

2

P

17

The SS (MCVideo Server) has queued the UE (MCVideo Client).

(NOTE 1)

<–

Queue Position Info

17a

Does the UE (MCVideo Client) provide Transmission request queued notification to the MCVideo User?

(NOTE 1)

18

The SS (MCVideo Server) removes the UE (MCVideo Client) from the queue.

<–

Transmission Cancel Request Notify

19

Make the MCVideo User request permission to send a video transmission.

(NOTE 1)

19a

Check: Does the UE (MCVideo Client) request permission to send a video transmission?

–>

Transmission Request

2

P

20

The SS (MCVideo Server) provides transmission granted notification to the MCVideo User.

<–

Transmission Granted

20a

Check: Does the UE (MCVideo Client) provide transmission granted notification to the MCVideo User?

(NOTE1)

2

P

21

The SS (MCVideo Server) sends the Transmission end request.

<–

Transmission End Request

21a

Check Does the UE (MCVideo Client) inform the MCVideo User that the permission to send RTP media is being revoked?

(NOTE 1)

2

P

22

Check: Does the UE (MCVideo Client) respond to the Transmission end request?

–>

Transmission End Response

2

P

23

Make the MCVideo User request to end the session.

(NOTE 1)

23a

Check: Does the UE (MCVideo Client) send a SIP BYE message to end the On-demand Pre-arranged Group Call?

–>

SIP BYE

3

P

24

The SS (MCVideo Server) sends a SIP 200 (OK) message to the UE (MCVideo Client) to indicate acceptance to end the Group Call.

<–

SIP 200 (OK)

EXCEPTION: SS (MCVideo Server) releases the E-UTRA connection.

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.1.1.12.3.3 Specific message contents

Table 6.1.1.12.3.3-1: SIP INVITE (Step 2, Table 6.1.1.12.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.1.3.3-2

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

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

Table 6.1.1.12.3.3-3: SIP 200 (OK) (Step 4, Table 6.1.1.12.3.2-1)

Derivation Path: RFC 3261 [22], Table 5.5.2.17.1.2-1, Conditions MCVIDEO, INVITE-RSP, GROUP CALL

Information Element

Value/remark

Comment

Reference

Condition

Contact

REGISTER-RSP

feature-param

"+g.3gpp.mcvideo"

MCVIDEO

expires

"600000"

Contact

SUBSCRIBE-RSP

addr-spec

user-info and host

px_MCVideo_PublicServiceId_A

MCVIDEO

Contact

INVITE-RSP

addr-spec

user-info and host

px_MCVideo_Client_B_ID

MCVIDEO

“audio”

MCPTT OR MCVIDEO

“video”

MCVIDEO

feature-param

Call-ID

same value as received in the request

callid

INVITE-RSP

CSeq

"timer"

value

INVITE-RSP

Session-Expires

INVITE-RSP

generic-param

"tdialog"

refresher

"norefersub"

Supported

"explicitsub"

uri-parameters

RFC 5621 [58]

INVITE-RSP

Content-Type

length of message-body

media-type

RFC 3261 [22]

INVITE-RSP

Message-body

"application/sdp"

RFC 4566 [27]

MIME-part-header

SDP message as described in Table 5.5.3.1.2-2

MCVIDEO

MIME-part-body

MCPTT/MCVideo/MCData Info

"application/vnd.3gpp.mcvideo-info+xml"

MCVIDEO

MIME body part

MCVideo-Info as described in Table 6.1.1.12.3.3-2

TS 24.281 [86] clause F.1

MCVIDEO

Table 6.1.1.12.3.3-5: Transmission Granted (Steps 6, 20, Table 6.1.1.12.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.1-1, condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

"1000000000000000"

A = Normal call

TS 24.581 [27], clause 9.2.5.1

Table: 6.1.1.12.3.3-6: Queue Position Info (Steps 10, 17, Table 6.1.1.12.3.2-1)

Derivation Path: TS 24.581 [88] Table 9.2.12-1, Condition ON-NETWORK

Information Element

Value/remark

Comment

Reference

Condition

Subtype

“00101”

Server client

TS 24.581 [88] 9.2.2.1-1

Table 6.1.1.12.3.3-7: Transmission Control Ack (Step 11, Table 6.1.1.12.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

"00010000"

Transmission Control Ack message for Transmission Granted message which requested acknowledgment.

Table 6.1.1.12.3.3-8: SIP 200 (OK) (Step 24, Table 6.1.1.12.3.2-1)

Derivation Path: RFC 3261 [22], Table 5.5.2.17.1.2-1, Conditions MCVIDEO, GROUP CALL

Information Element

Value/remark

Comment

Reference

Condition

MIME-part-body

MCVideo-Info Not present

TS 24.281 [86] clause F.1

MCVIDEO

Table 6.1.1.13.2.2-9: SIP BYE (Step 23a, Table 6.1.1.12.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MO-CALL

6.1.1.13 On-network / On-demand Pre-arranged Group Call / Reception Control State Transitions / Client Terminated (CT)

6.1.1.13.1 Test Purpose (TP)

(1)

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

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 incoming On-demand Pre-arranged Group Call, with implicit Transmission Control }

ensure that {

when { the 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 and sends a Receive Media Request message to 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, Transmission End Notify, Media Transmission Notification, Transmission Control ACK) }

}

(3)

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

ensure that {

when { the UE (MCVideo Client) receives a Media Reception Override Notification }

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

}

(4)

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

ensure that {

when { the UE (MCVideo Client) receives a Transmission End Notify from the SS (MCVideo Server) }

then { the UE (MCVideo Client)notifies the MCVideo User that the another user’s transmission has ended.

(5)

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 }

}

(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 BYE message }

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

}

6.1.1.13.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.281 clauses 6.2.3.1.1, 6.2.3.1.2, 9.2.1.2.3.3; also TS 24.581, clauses 6.2.5.2.2, 6.2.5.3.2, 6.2.5.3.3, 6.2.5.3.4, 6.2.5.4.5, 6.2.5.5.3, 6.2.5.5.4, 6.2.5.5.5, 6.2.5.6.4, and 6.2.5.8.1. 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.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 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 9.2.1.2.3.3]

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

[TS 24.581, clause 6.2.5.2.2]

When an MCVideo call is established, the terminating transmission participant:

1. shall create an instance of a ‘Transmission participant state transition diagram for general reception control operation’; and

2. shall enter the ‘U: reception controller’ state.

NOTE: From a transmission participant perspective the MCVideo call is established when the application and signalling plane sends the SIP 200 (OK) response.

[TS 24.581, clause 6.2.5.3.2]

Upon receiving the media transmission notification from the transmission control server, the transmission participant:

1. if the first bit in the subtype of the media transmission notification 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 ‘6’ (Media transmission notification); and

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

2. shall provide media transmission notification to the user;

3. shall store the User ID and the SSRC of the user transmitting the media;

4. may display the details of the incoming media to the user; and

5. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.3]

Upon receiving an indication from the user to request permission to receive media, the transmission participant:

1. shall send the Receive Media Request message toward the transmission control server; The Receive Media Request message:

a. if a different priority than the normal priority is required, shall include the Reception Priority field with the priority not higher than negotiated with the transmission control server as specified in subclause 14.3.3; and

b. if the receive media request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Transmission Indicator field indicating the relevant call types;

2. shall create an instance of the ‘Transmission participant state transition diagram for basic reception control operation’;

3. shall map the stored User ID and the SSRC of the user transmitting the media with instance of ‘Transmission participant state transition diagram for basic reception control operation’ created in step 2; and

4. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.4]

Upon receiving a Transmission end notify message, the transmission participant:

1. shall inform the user about the media transmission ended by another user; and

2. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.4.5]

Upon receiving a granted response for Receive media request message, the transmission participant:

1. if the first bit in the subtype of the Receive media response 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 ‘7’ (Receive media response); and

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

2. shall provide receive media success notification to the user;

3. if the Receive Media Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T103 (Receive Media Request); and

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

[TS 24.581, clause 6.2.5.5.3]

Upon receiving an indication from the user to end the RTP media reception, the transmission participant:

1. shall send a Media reception end request message towards the transmission control server The Media reception end request message:

a. if the session is a broadcast call and if the session was established as a normal call, shall include the Transmission Indicator with the A-bit set to ‘1’ (Normal call); and

b. shall include the SSRC of user transmitting the media in the Media reception end request message;

2. shall remove the indication that the participant is overriding without revoke if this indication is stored;

3. shall remove the indication that the participant is overridden without revoke if this indication is stored;

4. shall start timer T104 (Receive Media Release) and initialize counter C104 (Receive Media Release) to 1; and

5. shall enter the ‘U: pending reception release’ state.

[TS 24.581, clause 6.2.5.5.4]

Upon receiving a Media reception override notify message, the transmission participant:

1. shall inform the user that the permission to receive a RTP media is being overridden;

2. may give information to the user about the reason for overriding the received RTP media;

3. shall send a Media reception end request message towards the transmission control server;

4. shall start timer T104 (Receive Media Release) and initialize counter C104 (Receive Media Release) to 1; and

5. shall enter the ‘U: pending reception release’ state.

This state is part of the ‘Transmission participant state transition diagram for basic reception control operation’. On entering this state, the transmission participant:

1. shall delete the instance of this basic reception control state machine; and

2. if the session was initiated as a broadcast group call, shall indicate to the ‘Transmission participant state transition diagram for general reception control operation’ state machine to move to ‘Call releasing’ state.

[TS 24.581, clause 6.2.5.5.5]

Upon receiving a Media reception end request message, the transmission participant:

1. if the first bit in the subtype of the Media reception end request message set to "1" (Acknowledgment is required) as described in subclause 8.3.2, shall send a Reception control Ack message. The Reception control Ack message:

a. shall include the Message Type field set to ‘2’ (Media reception end request);

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

c. shall include the Message Name field set to MCV2.

2. shall inform the user that the receiving RTP media is being ended;

3. may give information to the user about the reason for ending the received RTP media;

4. shall request the MCVideo client to discard any remaining buffered RTP media packets and stop displaying to user;

5. shall send a Media reception end response message towards the transmission control server;

6. may provide a Media reception end notification to the MCVideo user;

7. if the Receive Media Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and

8. shall enter the ‘terminated’ state.

[TS 24.581, clause 6.2.5.6.4]

Upon receiving a MRE response message, the transmission participant:

1. if the first bit in the subtype of the MRE response message 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 ‘3’ (Media reception end response); and

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

2. may provide a Media reception end notification to the MCVideo user;

3. if the Receive Media Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T104 (Receive Media Release); and

5. shall enter the ‘terminated’.

[TS 24.581, clause 6.2.5.8.1]

This state is part of the ‘Transmission participant state transition diagram for basic reception control operation’. On entering this state, the transmission participant:

1. shall delete the instance of this basic reception control state machine; and

2. if the session was initiated as a broadcast group call, shall indicate to the ‘Transmission participant state transition diagram for general reception control operation’ state machine to move to ‘Call releasing’ state.

6.1.1.13.3 Test description

6.1.1.13.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.2A.

– 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.13.3.2 Test procedure sequence

Table 6.1.1.13.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: The E-UTRA/EPC actions which are related to the MCVideo call establishment; steps are described in TS 36.579-1 [2], subclause 5.4.4A ‘Generic Test Procedure for MCVIDEO CT communication in E-UTRA’. The test sequence below shows only the MCVideo relevant messages exchanged.

1

The SS (MCVideo Server) sends an On-demand Pre-arranged group call with Automatic Commencement Mode and implicit Reception Control to the UE (MCVideo Client).

<–

SIP INVITE

EXCEPTION: Step 2a1 describes behaviour that depends on the UE (MCVideo Client) implementation; the "lower case letter" identifies a step sequence that takes place if the UE (MCVideo Client) responds to a SIP INVITE message with a SIP 100 (Trying) message.

2a1

The UE (MCVideo Client) responds with a SIP 100 (Trying) message.

–>

SIP 100 (Trying)

3

Check: Does the UE (MCVideo Client) answer the call with a SIP 200 (OK)?

–>

SIP 200 (OK)

1

P

4

The SS (MCVideo Server) sends a SIP ACK to the UE (MCVideo Client).

<–

SIP ACK

5

The SS (MCVideo Server) sends a Media Reception Notification message to the UE (MCVideo Client) to notify the UE (MCVideo Client) that data is available to transmit to the UE (MCVideo Client).

<–

Media Transmission Notification

6

Make the MCVideo User request permission to receive media.

(NOTE 1)

7

Check: Does the UE (MCVideo Client) send a Receive Media Request message to the SS (MCVideo Server)?

–>

Receive Media Request

2

P

8

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client).

<–

Receive Media Response

9

Check: Does the UE (MCVideo Client) provide receive media success notification to the MCVideo User?

(NOTE 1)

2

P

10

The SS (MCVideo Server) notifies the UE (MCVideo Client) that right of Reception of media has been overridden.

<–

Media Reception Override Notification

11

Check: Does the Client respond to the Media Reception Override Notify message?

–>

Media Reception End Request

3

P

12

The SS (MCVideo Server) responds to end the UE (MCVideo Client) Media Reception End Request

<–

Media Reception End Response

12a

The SS (MCVideo Server) sends a Transmission End Notify message to inform the US (MCVideo Client) that another user’s transmission has ended.

<–

Transmission End Notify

13

Check: Does the UE (MCVideo Client) inform the user about the media transmission ended by another user?

4

P

14

The SS (MCVideo Server) sends a Media Reception Notification message to the UE (MCVideo Client) to notify the Client that data is available to transmit to the UE (MCVideo Client).

<–

Media Reception Notification

15

Make the MCVideo User request permission to receive media.

(NOTE 1)

16

Check: Does the UE (MCVideo Client) send a Receive Media Request message to the SS (MCVideo Server)?

–>

Receive Media Request

2

P

17

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client) with the first bit in the subtype of the Receive Media Response message set to ‘1’ (meaning Acknowledgement is required). The SS ( MCVideo Server) response permits the Client to receive media.

<–

Receive Media Response

18

Check: Does the UE (MCVideo Client) notify the MCVideo User of media reception permission success?

(NOTE 1)

2

P

19

Check: Does the UE (MCVideo Client) acknowledge the Receive Media Response message?

–>

Transmission Control ACK

2

P

20

The SS (MCVideo Server) notifies the Client that the transmission is ending

<–

Media Reception End Request

21

Check: Does the UE (MCVideo Client) responds to the Media reception end request?

–>

Media Reception End Response

5

P

22

The SS (MCVideo Server) sends a Media Reception Notification message to the UE (MCVideo Client) to notify the UE (MCVideo Client) that data is available to transmit to the UE (MCVideo Client).

<–

Media Reception Notification

23

Make the MCVideo User request permission to receive media.

(NOTE 1)

24

Check: Does the UE (MCVideo Client) send a Receive Media Request message to the SS (MCVideo Server)?

–>

Receive Media Request

2

P

25

The SS (MCVideo Server) sends a Receive Media Response message to the UE (MCVideo Client).

<–

Receive Media Response

26

Check: When the UE (MCVideo Client) receives an indication from the User to end reception (Click video reception end button), does the UE (MCVideo Client) send the Media Reception End Request message?

–>

Media Reception End Request

5

P

27

The Server responds to the Media Reception End Request message.

<–

Media Reception End Response

28

The SS (MCVideo Server) sends a SIP BYE message.

<–

SIP BYE

29

Check: Does the UE send a SIP 200 (OK) message in response to the SIP BYE message?

–>

SIP 200 (OK)

6

P

EXCEPTION: SS releases the E-UTRA connection.

NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.1.1.13.3.3 Specific message contents

Table 6.1.1.13.3.3-1: SIP INVITE (Step 1, Table 6.1.1.13.3.2-1)

Derivation Path: TS 36-579-1 [2], Table 5.5.2.5.2-1, condition MCVIDEO, MO-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.1.13.3.3-2

Table 6.1.1.13.3.3-2: MCVideo-INFO in SIP INVITE (Table 6.1.1.13.3.3-1)

Derivation Path: TS 56.379-1 [2], Table 5.5.3.2.2-2, condition GROUP CALL

Table 6.1.1.13.3.3-3: SIP 200 (OK) (Step 3, Table 6.1.1.13.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, conditions INVITE-RSP, MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

INVITE-RSP

MIME body part

MCVideo-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.1.13.3.3-2

Table 6.1.1.13.3.3-4: Transmission Control ACK (Step 19, Table 6.1.1.13.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

"10000"

Transmission Control Ack message for Transmission Granted message which requested acknowledgment.

Table 6.1.1.13.3.3-5: Receive Media Response (Steps 17, Table 6.1.1.13.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.8-1

Information Element

Value/remark

Comment

Reference

Condition

Subtype

“10111”

Server client.

The first bit in the subtype of the Receive Media Response message set to ‘1’ means that acknowledgement is required.

TS 24.581 [88] 9.2.2.1-1

Table 6.1.1.13.3.3-6: Media Reception End Response (Steps 21, Table 6.1.1.13.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.11.2.8-1

Information Element

Value/remark

Comment

Reference

Condition

Subtype

“00011”

Client Server

TS 24.581 [88] 9.2.2.1-3

Table 6.1.1.13.3.3-7: SIP BYE (Step 28, Table 6.1.1.13.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.2.2.2-1, condition MO-CALL

Table 6.1.1.13.3.3-8: SIP 200 (OK) (Step 29, Table 6.1.1.13.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

"0"

No message body included