6.1.2 Chat Group Call

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

6.1.2.1 On-network / Chat Group Call / Join Chat Group Session / End Chat Group Call / Client Originated (CO)

6.1.2.1.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests the establishment of an on-demand MCVideo group session using a MCVideo group identity identifying a chat MCVideo group }

then {the UE (MCVideo Client) requests to join the Chat Group Call by generating a SIP INVITE message and, after indication from the SS (MCVideo Server) that Transmission is granted, the UE (MCVideo Client) provides transmission granted notification to the user and respects Transmission Control (Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission End Response) }

}

(2)

with { UE (MCVideo Client) having an ongoing On-demand Chat Group Call }

ensure that {

when { the MCVideo User requests to release Transmission Control }

then { UE (MCVideo Client) sends a Transmission End Request, and respects Transmission Control (Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission End Response) }

}

(3)

with { UE (MCVideo Client) having an ongoing On-demand Chat Group Call }

ensure that {

when { the MCVideo User requests to end the ongoing MCVideo Chat Group Call and the UE (MCVideo Client) sends a Transmission End Request and receives a Transmission End Response from the SS (MCVideo Server) }

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

}

6.1.2.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.281, clause 9.2.2.2.1.1, 9.2.2.2.2.1 TS 24.581, clause 6.2.1, 6.2.4.1, 6.2.4.4.6, 6.2.4.5.3, 6.2.4.4.7. 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-14 requirements.

[TS 24.281 clause 9.2.2.2.1.1]

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

The MCVideo client:

1) if the MCVideo user has requested the origination of an MCVideo emergency group call or is originating an MCVideo chat group call and the MCVideo emergency state is already set, the MCVideo client shall comply with the procedures in 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) shall include the g.3gpp.mcvideo media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [22];

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

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

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

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

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

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

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

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

11) if the MCVideo emergency state is already set or the MCVideo client emergency group state for this group is set to "MVEG 2: in-progress", the MCVideo client shall comply with the procedures in subclause 6.2.8.1.2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the MCVideo client shall perform the actions specified in 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.2.2.2.1]

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

[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 re-join 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.4.1]

The transmission participant shall behave according to the state diagram and the state transitions specified in this subclause.

Figure 6.2.4.1-1 shows the state diagram for ‘Transmission participant state transition diagram for basic transmission control operation’.

State details are explained in the following subclauses.

If a transmission control message arrives in a state where there is no specific procedure specified for received transmission control message, the transmission participant shall discard the transmission control message and shall remain in the current state.

NOTE: A badly formatted transmission control message received in any state is ignored by the transmission participant and does not cause any change of the current 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.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.4.7]

Upon receiving an indication from the user to end the Transmission request, 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 stop time T100 (Transmission Request)

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

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

6.1.2.1.3 Test description

6.1.2.1.3.1 Pre-test conditions

System Simulator:

– SS (MCVideo server).

– E-UTRA related parameters are set to the default parameters for the basic single cell environment, as defined in TS 36.508 [24] subclause 4.4.

IUT:

– UE (MCVideo client) has been provisioned with the Initial UE Configuration Data as specified in TS 36.579-1 [2], subclause 5.5.8.1 allowing for the location of the configuration management server for configuration of the MCVideo UE initial configuration management object (MO) and the default MCVideo user profile configuration management object (MO).

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

Table 6.1.2.1.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User initiate an On-demand Chat Group Call.

(NOTE 1)

2

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ according to option b,ii of NOTE 1 as described in TS 36.579-1 [2] Table 5.3B.1.3-1?

1

P

3-7

Void

8

Check: Does the UE (MCVideo Client) notify the user that the call has been successfully established?

(NOTE 1)

1

P

9

Make the MCVideo User release Transmission Control.

(NOTE 1)

10

Check: Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?

2

P

11-13

Void

14

Make the MCVideo User end the on-demand chat group call.

(NOTE 1)

15

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1?

3

P

16

Void

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

6.1.2.1.3.3 Specific message contents

Table 6.1.2.1.3.3-1: SIP INVITE (Step 2, Table 6.1.2.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.1.3.3-1A

MIME body part

MCVideo Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.1.3.3-2

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

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

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

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

Table 6.1.2.1.3.3-3: SIP 200 (OK) (Step 2, Table 6.1.2.1.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

SDP Message y

SDP message as described in Table 6.1.2.1.3.3-3B

Table 6.1.2.1.3.3-3A: Void

Table 6.1.2.1.3.3-3B: SDP message in SIP 200 (OK) (Table 6.1.1.12.3.3-3)

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

Table 6.1.2.1.3.3-4 .. 6: VoidTable 6.1.2.1.3.3-7: SIP BYE (Step 15, Table 6.1.2.1.3.2-1; Step1, TS 36.579-1 [2] Table 5.3.10.3-1)

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

Table 6.1.2.1.3.3-8: Void

6.1.2.2 On-network / Chat Group Call / Upgrade to Emergency Chat Group Call / Cancel Emergency Chat Group Call / Upgrade to Imminent Peril Chat Group Call / Cancel Imminent Peril Chat Group Call / Client Origination (CO)

6.1.2.2.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests the establishment of an on-demand MCVideo group session using a MCVideo group identity identifying a chat MCVideo group }

then {the UE (MCVideo Client) requests to join the Chat Group Call by generating a SIP INVITE message and, after indication from the SS (MCVideo Server_ that Transmission is granted, the UE (MCVideo Client) provides transmission granted notification to the user and respects Transmission Control throughout the session (Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission End Response) }

}

(2)

with { UE (MCVideo Client) having established a Chat Group Call and the MCVideo User being authorized for initiating an MCVideo Emergency Group Call }

ensure that {

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

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

}

(3)

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

ensure that {

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

then { 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 that the call has been downgraded }

}

(4)

with { UE (MCVideo Client) having established an a Chat Group Call and the MCVideo User being authorized for initiating an MCVideo Imminent Peril Chat Group Call }

ensure that {

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

then { 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 Chat Group Call and notifies the user that the call has been upgraded }

}

(5)

with { UE (MCVideo Client) having upgraded an On-demand Chat Group Call to an Imminent Peril Group Call and the MCVideo User being authorized for cancelling an MCVideo Imminent Peril Chat Group Call state (MCVideo in-progress imminent peril cancel) }

ensure that {

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

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

}

(6)

with { UE (MCVideo Client) having an ongoing On-demand Chat Group Call }

ensure that {

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

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

}

6.1.2.2.2 Conformance Requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.281, clauses 9.2.2.2.1.1, 9.2.2.2.1.3, 9.2.2.2.1.4, 9.2.2.2.1.5, TS 24.581 clauses 6.2.1, 6.2.4.4.6, 6.4.1, 6.4.2, 6.4.3, 6.4.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-14 requirements.

[TS 24.281, clause 9.2.2.2.1.1]

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

The MCVideo client:

1) if the MCVideo user has requested the origination of an MCVideo emergency group call or is originating an MCVideo chat group call and the MCVideo emergency state is already set, the MCVideo client shall comply with the procedures in 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) shall include the g.3gpp.mcvideo media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [22];

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

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

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

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

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

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

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

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

11) if the MCVideo emergency state is already set or the MCVideo client emergency group state for this group is set to "MVEG 2: in-progress", the MCVideo client shall comply with the procedures in subclause 6.2.8.1.2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the MCVideo client shall perform the actions specified in 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.2.2.1.3]

This subclause covers both on-demand session.

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

The MCVideo client:

1) if the MCVideo user is not authorised to cancel the in-progress emergency group state of the MCVideo group as determined by the procedures of 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;

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 optionally 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, if the SIP re-INVITE request is to be sent within an on-demand session, include in the SIP re-INVITE request an SDP offer according to 3GPP TS 24.229 [51] with the clarifications specified in subclause 6.2.1;

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

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

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

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

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

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

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

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

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

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

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

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

This subclause covers both on-demand sessions.

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

1) if the MCVideo user is requesting to upgrade the MCVideo group session to an in-progress emergency group state and is not authorised to do so as determined by the procedures of subclause 6.2.8.1.8, the MCVideo client:

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

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

2) if the MCVideo user is requesting to upgrade the MCVideo group session to an in-progress imminent peril state and is not authorised to do so as determined by the procedures of subclause 6.2.8.1.8, the MCVideo client:

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

b) shall skip the remaining steps of the current 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;

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

2) shall perform the actions specified in subclause 6.2.8.1.4.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the SIP re-INVITE request the MCVideo client shall perform the actions specified in 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.2.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 chat MCVideo group, the MCVideo client shall generate a SIP re-INVITE request by following the procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 re-join 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.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.4.1]

Once an on-demand MCVideo session is established or a pre-established session is in use when the participating MCVideo function receives transmission control messages from the transmission participant in the MCVideo client or from the transmission control server in the controlling MCVideo function, the behaviour of the participating MCVideo function is described in the following subclauses.

[TS 24.581, clause 6.4.2]

Upon receiving a transmission control message the participating MCVideo function:

1. shall immediately forward the transmission control message to the transmission control server if the message is received from the transmission participant;

2. if an MBMS subchannel is not used for a transmission in the session the transmission control message is associated with, shall immediately forward the transmission control message to the transmission participant if the message is received from the transmission control server; and

3. if an MBMS subchannel is used for a transmission in the session the transmission control message is associated with:

a. if

i. the transmission control message is not a Transmission Idle message or a Media Transmission Notify message;

ii. the MCVideo client has not reported "listening" status as specified in 3GPP TS 24.281 [2] subclause 14.2.3; or

iii. the MCVideo client has reported "not-listening" status as specified in 3GPP TS 24.281 [2] subclause 14.2.3 in the latest received MBMS bearer listening status report;

shall immediately forward the transmission control message to the transmission participant; and

b. if

i. the MCVideo client has reported "listening" status as specified in 3GPP TS 24.281 [2] subclause 14.2.3 in the latest received MBMS bearer listening status report; and

ii if the transmission control message is the Transmission Idle message or the Media Transmission Notify message,

shall perform actions as specified in subclause 10.2.

NOTE: When the Transmit Idle or Media Transmission Notify messages are discarded the messages are sent to the MCVideo clients over the MBMS subchannel allocated for the transmission as specified in subclause 10.2.

[TS 24.581, clause 6.4.3]

Upon receiving RTP media packets the participating MCVideo function:

1. shall immediately forward the RTP media packet to the controlling MCVideo function if the RTP packet is from an MCVideo client; and

2. if an MBMS subchannel is not used for a transmission in the session the RTP media packets are associated with, shall immediately forward the RTP media packets to the MCVideo client if the RTP packet is from the controlling MCVideo function or the non-controlling MCVideo function.

3. if an MBMS subchannel is used for a transmission in the session the RTP media packets are associated with and if RTP media packets are received from the controlling MCVideo function or the non-controlling MCVideo function:

a. if

i. the MCVideo client has not reported "listening" status as specified in 3GPP TS 24.281 [2] subclause 14.2.3; or

ii. the MCVideo client has reported "not-listening" status as specified in 3GPP TS 24.281 [2] subclause 14.2.3 in the latest received MBMS bearer listening status report,

shall immediately forward the RTP media packets to the MCVideo client; and

b. if the MCVideo client has reported "listening" status as specified in 3GPP TS 24.281 [2] subclause 14.2.3 in the latest received MBMS bearer listening status report, shall perform actions as specified in subclause 10.2.

[TS 24.581, clause 6.4.4]

When the participating function receives an indication from the application and signalling plane that session release is initiated, the participating MCVideo function:

1. shall stop sending transmission control messages towards the transmission participant and the transmission control server; and

2. shall stop sending RTP media packets towards the MCVideo client and towards the controlling MCVideo function.

When the participating MCVideo function receives an indication from the application and signalling plane that the session is released, the participating MCVideo function:

1. in case of a pre-established session, shall perform the actions in subclause 9.3.2; and

2. in case of an on-demand session, shall release the media resources associated with the session.

6.1.2.2.3 Test description

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

– The MCVideo client has followed the steps defined in TS 36.579-1 [2], subclause 5.3.3A Generic Test Procedure for MCVideo pre-established session establishment CO.

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

Table 6.1.2.2.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User initiate an On-demand Chat Group Call.

(NOTE 1)

2

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ according to option b,ii of NOTE 1 as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to initiate an On-demand Chat Group Call ?

1

P

3-7

Void

8

Check: Does the UE (MCVideo Client) notify the user that the call has been successfully established?

(NOTE 1)

1

P

8A

Make the MCVideo User request to end the transmission.

(NOTE 1)

8B

Check Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?

1

P

9

Make the MCVideo User request upgrade of the ongoing On-Demand Pre-arranged Chat Group Call to MCVideo Emergency Chat Group Call with explicit request for Transmission Control (implicit Transmission Control).

(NOTE 1)

10

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘ MCVideo CO session modification with implicit Transmission Control

as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to upgrade the call to an Emergency Group Call with implicit Transmission Control?

2

P

11-15

Void

16

Check: Does the UE (MCVideo client) notify the user that the Emergency Chat Group Call has been successfully established?

(NOTE 1)

2

P

16A

Make the MCVideo User request to end the transmission.

(NOTE 1)

16B

Check Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?

2

P

17

Make the MCVideo User downgrade the Emergency state

(NOTE 1)

18

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘ MCVideo CO session modification with implicit Transmission Control as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to cancel the Emergency state?

3

P

19-23

Void

24

Check: Does the UE (MCVideo client) notify the user that the emergency state has been successfully cancelled?

(NOTE 1)

3

24A

Make the MCVideo User request to end the transmission.

(NOTE 1)

24B

Check Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?

1

P

25

Make the MCVideo User request upgrade of the ongoing On-Demand Pre-arranged Chat Group Call to MCVideo Imminent Peril Chat Group Call with explicit request for Transmission Control (implicit Transmission Control).

(NOTE 1)

26

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘ MCVideo CO session modification with implicit Transmission Control as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to upgrade the call to an Imminent Peril Group Chat Call with implicit Transmission Control?

4

P

27-31

Void

32

Check: Does the UE (MCVideo client) notify the user that the Imminent Peril Chat Group Call has been successfully established?

(NOTE 1)

4

P

32A

Make the MCVideo User request to end the transmission.

(NOTE 1)

32B

Check Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?

2

P

33

Make the MCVideo User downgrade the Imminent Peril Chat Group session.

(NOTE 1)

34

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘ MCVideo CO session modification with implicit Transmission Control

as described in TS 36.579-1 [2] Table 5.3B.11.3-1 to downgrade the Imminent Peril state?

5

P

35-39

Void

40

Check: Does the UE (MCVideo client) notify the user that the Imminent Peril Call has been successfully cancelled?

(NOTE 1)

5

P

41

Make the MCVideo User request to release Transmission Control.

(NOTE 1)

42

Check: Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1 to terminate the Group Chat Call?

1

P

43-45

Void

46

Make the MCVideo User request to end the Chat Group Call.

(NOTE 1)

47

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1?

6

P

48

Void

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

6.1.2.2.3.3 Specific message contents

Table 6.1.2.2.3.3-1: SIP INVITE (Step 2, Table 6.1.2.2.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.2.3.3-1A

MIME body part

MCVideo Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-2

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

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

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

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

Table 6.1.2.2.3.3-3: SIP 200 (OK) (Steps 2, 18, 34, Table 6.1.2.2.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

SDP Message

SDP Message as described in Table 6.1.2.2.3.3-3A

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

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

Table 6.1.2.2.3.3-4 ..6:Void

Table 6.1.2.2.3.3-7: SIP INVITE (Step 10, Table 6.1.2.2.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.2.3.3-7A

MIME body part

MCVideo Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-8

Table 6.1.2.2.3.3-7A: SDP message in SIP INVITE (Tables 6.1.2.2.3.3-7)

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

Table 6.1.2.2.3.3-8: MCVideo-Info in SIP INVITE (Table 6.1.2.2.3.3-7)

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

Table 6.1.2.2.3.3-9: SIP 200 (OK) (Step 10, Table 6.1.2.2.3.2-1; Step 3, TS 36.579-1 [2] Table 5.3B.11.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

INVITE-RSP

SDP Message

SDP Message as described in Table 6.1.2.2.3.3-9A

Table 6.1.2.2.3.3-9A: SDP message in SIP 200 (OK) (Table 6.1.2.2.3.3-9)

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

Table 6.1.2.2.3.3-10:Void

Table 6.1.2.2.3.3-11: Transmission Granted (Step 10, Table 6.1.2.2.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table 6.1.2.2.3.3-12: Void

Table 6.1.2.2.3.3-13: SIP INVITE (Step 18, 34, Table 6.1.2.2.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.2.3.3-7A

MIME body part

MCVideo Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-2

Table 6.1.2.2.3.3-14 .. 15: Void

Table 6.1.2.2.3.3-16: SIP INVITE (Step 26, Table 6.1.2.2.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.11.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition re-INVITE, IMMPERIL-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.2.3.3-7A

MIME body part

MCVideo Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-17

Table 6.1.2.2.3.3-17: MCVideo-Info in SIP INVITE (Table 6.1.2.2.3.3-16)

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

Table 6.1.2.2.3.3-18: SIP 200 (OK) (Step 26, Table 6.1.2.2.3.2-1; Step 3, TS 36.579-1 [2] Table 5.3B.11.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

INVITE-RSP

MIME body part

MSDP Message

MIME-part-body

SDP Message as described in Table 6.1.2.2.3.3-9A

Table 6.1.2.2.3.3-19:Void

Table 6.1.2.2.3.3-20: Transmission Granted (Step 26, Table 6.1.2.2.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.11.3-1)

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

Table 6.1.2.2.3-21 .. 24: Void

Table 6.1.2.2.3.3-25: SIP BYE (Step 47, Table 6.1.2.2.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3.10.3-1)

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

Table 6.1.2.2.3.3-26: Void

6.1.2.3 On-network / Chat Group Call / Upgrade to Emergency Chat Group Call / Cancel Emergency Chat Group Call / Upgrade to Imminent Peril Chat Group Call / Cancel Imminent Peril Chat Group Call / Client Terminated (CT)

6.1.2.3.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests to join a MCVideo Chat Group Session }

then { the UE (MCVideo Client) sends a SIP INVITE message to the SS (MCVideo Server) and responds to a SIP 200 (OK) message from the SS (MCVideo Server) with a SIP ACK message and, provides transmission granted notification to the MCVideo User, and respects Transmission Control through the session }

}

(2)

with { UE (MCVideo Client) having an ongoing Chat Group Call }

ensure that {

when { the UE (MCVideo Client) receives an upgrade of the ongoing MCVideo Group Call to an MCVideo Emergency Group Call via a SIP INVITE message from the SS (MCVideo Server) }

then { 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 Emergency Group Call }

}

(3)

with { UE (MCVideo Client) having an ongoing Chat Group Call, which was upgraded to an Emergency Chat Group Call }

ensure that {

when { the UE (MCVideo Client) receives a cancellation of the ongoing McVideo Emergency state via a SIP re-INVITE message from the SS (MCVideo Server)}

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

}

(4)

with { UE (MCVideo Client) having an ongoing Chat Group Call }

ensure that {

when { the UE (MCVideo Client) receives an upgrade of the ongoing MCVideo Chat Group Call to a MCVideo Imminent Peril Chat Group Call via a SIP re-INVITE message from the SS (MCVideo Server) }

then { 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 Chat Group Call ( }

}

(5)

with { UE (MCVideo Client) having an ongoing Chat Group Call, which was upgraded to an Imminent Peril Chat Group Call }

ensure that {

when { the UE (MCVideo Client) receives a cancellation of the ongoing McVideo Imminent Peril state via a SIP re-INVITE message from the SS (MCVideo Server) }

then { UE (MCVideo Client) responds to the SIP re-INVITE request with a SIP 200 (OK) response and considers the imminent peril condition cancelled.}

}

(6)

with { UE (MCVideo Client) having an ongoing Chat 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 }

}

(7)

with { UE (MCVideo Client) having provided media transmission notification to the MCVideo User after receiving 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 to the SS (MCVideo Server) and provides receive media success notification to the MCVideo User upon reception of the Receive Media Response message }

}

(8)

with { UE (MCVideo Client) having an ongoing Chat Group Call }

ensure that {

when { the UE (MCVideo User) requests to terminate the ongoing MCVideo Chat Group Call }

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

}

6.1.2.3.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.281 clauses 9.2.2.3.1.1, 9.2.2.3.1.3, 9.2.2.4.1.1, 9.2.2.4.1.2, 9.2.2.4.1.3, 9.2.2.5.1.2, 9.2.2.5.1.3, 9.2.2.5.1.6, TS 24.581, clauses 6.2.4.2.2, 6.3.2.2, 6.3.4.4.12, 6.3.5.3.9, and 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-14 requirements.

[TS 24.281, Clause 9.2.2.3.1.1]

In the procedures in this subclause:

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

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

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

Upon receipt of a "SIP INVITE request for originating participating MCVideo function" for a group identity identifying a chat MCVideo group containing an application/vnd.3gpp.mcvideo-info+xml MIME body with the <session-type> element set to a value of "chat", the participating MCVideo function:

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

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

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

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

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

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

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

NOTE 3: If the SIP INVITE request contains an emergency indication set to a value of "true" or an imminent peril indication set to a value of "true" and this is an authorized request for originating a priority call as determined by subclause 6.3.2.1.8.1, the participating MCVideo function can according to local policy choose to allow for an exception to the limit for the maximum simultaneous MCVideo sessions supported for the MCVideo user.

6) if the user identified by the MCVideo ID is not affiliated to the group identified in the "SIP INVITE request for originating participating MCVideo function" as determined by subclause 8.2.2.2.11, shall perform the actions specified in subclause 8.2.2.2.12 for implicit affiliation;

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

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

NOTE 5: if the SIP INVITE request contains an emergency indication set to a value of "true" or an imminent peril indication set to a value of "true" and this is an authorized request for originating a priority call as determined by subclause 6.3.2.1.8.1, the participating MCVideo function can according to local policy choose to allow an exception to the N2 limit. Alternatively, a lower priority affiliation of the MCVideo user could be cancelled to allow for the new affiliation.

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

NOTE 6: The public service identity can identify the controlling MCVideo function in the primary MCVideo system or a partner MCVideo system.

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

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

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

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

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

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

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

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

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

14) if a Resource-Priority header field was included in the received SIP INVITE request, shall include a Resource-Priority header field according to rules and procedures of IETF RFC 4412 [33] set to the value indicated in the Resource-Priority header field of the SIP INVITE request from the MCVideo client; and

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

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

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

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

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

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

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

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

2) shall generate a SIP 200 (OK) response as specified in the subclause 6.3.2.1.5.2;

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

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

5) shall include the public service identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response;

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

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

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

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request in step 14) the participating MCVideo function:

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

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

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

4) if the implicit affiliation procedures of subclause 8.2.2.2.12 were invoked in the current procedure, shall perform the procedures of subclause 8.2.2.2.14.

[TS 24.281, clause 9.2.2.3.1.3]

This subclause covers on-demand session.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, Clause 9.2.2.4.1.1]

In the procedures in this subclause:

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

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

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

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

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

Upon receipt of a "SIP INVITE request for controlling MCVideo function of an MCVideo group" containing a group identity identifying a chat MCVideo group, the controlling MCVideo function:

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

NOTE 1: If the SIP INVITE request contains an emergency indication set to a value of "true", the controlling MCVideo function can by means beyond the scope of this specification choose to accept the request.

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

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

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

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

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

4) shall retrieve the necessary group document(s) from the group management server for the group identity contained in the SIP INVITE request and carry out initial processing as specified in subclause 6.3.5.2 and continue with the rest of the steps if the checks in subclause 6.3.5.2 succeed;

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

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

b) if the MCVideo user is not eligible for implicit affiliation, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in subclause 4.4 and skip the rest of the steps below;

6) if the SIP INVITE request contains unauthorized request for an MCVideo emergency group call as determined by subclause 6.3.3.1.13.2:

a) shall reject the SIP 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;

7) if the SIP INVITE request contains an unauthorized request for an MCVideo imminent peril group call as determined by subclause 6.3.3.1.13.6, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

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

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

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

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

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

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

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

11) if the chat group session is ongoing and the <on-network-max-participant-count> as specified in 3GPP TS 24.481 [24] is already reached:

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

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

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

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

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

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

i) perform the actions specified in subclause 6.3.3.1.8;

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

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

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

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

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

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

B) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorized request for an MCVideo emergency alert meeting the conditions specified in subclause 6.3.3.1.13.1, perform the procedures specified in subclause 6.3.3.1.12; and

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

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

iii) if the SIP INVITE request contains an authorized request for an MCVideo emergency alert as determined in step i) B) above, cache the information that this MCVideo user has initiated an MCVideo emergency alert; and

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

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

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

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

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

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

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

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

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

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

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

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

i) perform the actions specified in subclause 6.3.3.1.8;

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

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

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

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

i) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCVideo user’s imminent peril indication as specified in 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

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

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

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

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

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

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

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

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

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

16) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [11] with the clarifications specified in subclause 6.3.3.2.1 unless the procedures of subclause 6.3.3.1.8 were performed in step 13)a) or step 14)a) above;

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

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

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

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

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

c) the MCVideo session identity; and

d) the media feature tag isfocus;

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

21) if the SIP INVITE request contains an alert indication set to a value of "true" and this is an unauthorized request for an MCVideo emergency alert as specified in 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;

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

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

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

25) if the chat group session was already ongoing and if at least one of the participants has subscribed to the conference event package, shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in subclause 9.2.3.4.2.

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

[TS 24.281, clause 9.2.2.4.1.2]

In the procedures in this subclause:

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

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

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

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

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

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

3) if the 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 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:

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

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

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

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

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

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

ii) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "true" and is an authorized request for an MCVideo emergency alert as determined by subclause 6.3.3.1.13.1, shall cache the MCVideo ID of the MCVideo user that has initiated an MCVideo emergency alert; and

iii) for each of the other affiliated members of the group, generate a SIP MESSAGE request notification of the MCVideo user’s emergency indication as specified in subclause 6.3.3.1.11 with the following clarifications:

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

B) if the received SIP re-INVITE contains an alert indication set to a value of "true" and this is an authorized request for an MCVideo emergency alert meeting the conditions specified in subclause 6.3.3.1.13.1, perform the procedures specified in subclause 6.3.3.1.12; and

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) if an <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body is included and set to "false" and is determined to be an 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; and

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

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

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

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

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

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

i) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s emergency call as specified in 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 d), set the <alert-ind> element of the application/vnd.3gpp.mcvideo-info+xml MIME body to a value of "false"; and

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

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

a) if the Resource-Priority header field is set to the value indicated for emergency calls and the received SIP re-INVITE request does not contain an authorized request for an MCVideo emergency call as determined in step 4) above and the in-progress emergency state of the group is set to a value of "false", shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps; or

b) if the Resource-Priority header field is set to the value indicated for imminent peril calls and the received SIP re-INVITE request does not contain an authorized request for an MCVideo imminent peril call as determined by the procedures of subclause 6.3.3.1.13.5 and the in-progress imminent peril state of the group is set to a value of "false", shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps;

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

9) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [11] with the clarifications specified in subclause 6.3.3.2.1 unless the procedures of subclause 6.3.3.1.8 were performed in step 6) a) i) above;

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

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

12) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <alert-ind> element set to a value of "false" and if this is an 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;

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

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

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

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.

[TS 24.281, clause 9.2.2.4.1.3]

In the procedures in this subclause:

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

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

1) if the SIP re-INVITE request contains an unauthorized request for an MCVideo imminent peril group call as determined by subclause 6.3.3.1.13.5, shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

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

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

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

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

i) perform the actions specified in subclause 6.3.3.1.8;

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

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

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

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

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

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

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

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

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

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

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

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

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

3) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "false" and is an 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:

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

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

iii) skip the rest of the steps;

4) if the SIP re-INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <imminentperil-ind> element set to a value of "false" and is determined to be an 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) validate that the SIP re-INVITE request includes a Resource-Priority header field with the namespace set to the MCVideo-specific namespace, and the priority set to the priority level designated for a normal priority MCVideo group call, and if not:

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

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

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

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

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

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

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

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

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

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

i) generate a SIP MESSAGE request notification of the cancellation of the MCVideo user’s imminent peril call as specified in 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];

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

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

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

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

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

[TS 24.281, clause 9.2.2.5.1.2]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, clause 9.2.2.5.1.3]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) if information about a current speaker(s) is cached:

a) shall generate a SIP INFO request as specified in subclause x.x.x.x; and

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

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

Editor’s Note: the need for these media plane procedures is FFS.

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

[TS 24.281, clause 9.2.2.5.1.6]

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

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

When an MCVideo call is established a new instance of the transmission control server state machine for ‘general transmission control operation’ is created.

For each MCVideo client added to the MCVideo call, a new instance of the transmission control server state machine for ‘basic transmission control operation towards the transmission participant’ is added.

If the optional "mc_queueing" feature is supported and has been negotiated as specified in clause 14, the transmission control server could queue the implicit transmission control request for the media-transmission control entity.

The original initial SIP INVITE request or SIP REFER request to establish an MCVideo chat group call or to re-join an ongoing MCVideo call is not handled as an implicit transmission control request message by the transmission control server unless explicitly stated in the SIP INVITE request or in the SIP REFER request.

The permission to send media to the inviting MCVideo client due to implicit transmission control request is applicable to both confirmed indication and unconfirmed indication.

When the first unconfirmed indication is received from the invited participating MCVideo function (see 3GPP TS 24.281 [2]) the transmission control server optionally can give an early indication to send RTP media packets, to the inviting MCVideo client.

If an early indication to send RTP media packets is given to the inviting MCVideo client, the transmission participant is granted the permission to send media and the MCVideo server buffers RTP media packets received from the MCVideo client at least until the first invited MCVideo client accepts the invitation or until the RTP media packet buffer exceeds it maximum limit to store RTP media packets.

If the MCVideo server does not support or does not allow media buffering then when an early indication to send RTP media packets is not given to the inviting MCVideo client, the transmission participant is granted the permission to send media when the first invited MCVideo client accepts the media.

Before the transmission control server sends the first transmission control message in the MCVideo call, the transmission control server has to assign itself a SSRC identifier to be included in media transmission control messages and quality feedback messages if the MCVideo server is supporting that option. A suitable algorithm to generate the SSRC identifier is described in IETF RFC 3550 [3].

The transmission participant and the transmission control server can negotiate the maximum priority level that the transmission participant is permitted to request. The transmission control server can pre-empt the current sender based on the negotiated maximum priority level that the transmission participant is permitted to request and the priority level included in the Transmission Media Request message.

NOTE: The maximum priority level that a transmission participant can use is negotiated as specified in subclause 14.3.3 and is based on group configuration data retrieved by the controlling MCVideo function from the group management server as described in 3GPP TS 24.481 [12] and service configuration data retrieved by the controlling MCVideo function from the configuration management server as described in 3GPP TS 24.484 [13].

The transmission participant and the transmission control server can negotiate queueing of Transmission requests using the "mc_queueing" fmtp attribute as described in clause 14. If queueing is supported and negotiated, the transmission control server queues the transmission control request if a Transmission Media Request message is received when another transmission participant has the transmission and the priority of the current speaker is the same or higher.

[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.2.3.3 Test description

6.1.2.3.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.2.3.3.2 Test procedure sequence

Table 6.1.2.3.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the UE (MCVideo User) request initiation of a Chat Group Call.

(NOTE 1)

2

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ according to option b,ii of NOTE 1 as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to initiate a chat group call?

1

P

3-7

Void

8

Check: Does the UE (MCVideo client) provide Transmission granted notification to the MCVideo User?

(NOTE 1)

1

P

9

Make the MCVideo User release Transmission Control.

(NOTE 1)

10

Check: Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1?

1

P

11

Void

12

Check: Is the test procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to upgrade the Chat Group Call to an Emergency state correctly performed?

2

P

13a1-15

Void

16

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?

6,7

P

17-20

Void

21

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

(NOTE 1)

7

P

21A

Check: Is the test procedure MCVideo Media Reception End Request CT as described in TS 36.579-1 [2] Table 5.3B.10.3-1 correctly performed?

1

P

22

Check: Is the test procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to downgrade the Chat Group Call from an Emergency state to a regular Chat Group Call correctly performed?

3

P

23a1-25

Void

26

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?.

6,7

P

27-30

Void

31

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

(NOTE 1)

7

P

31A

Check: Is the test procedure MCVideo Media Reception End Request CT as described in TS 36.579-1 [2] Table 5.3B.10.3-1 correctly performed?

1

P

32

Check: Is the test procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to upgrade the Chat Group Call to an Imminent Peril state correctly performed?

4

P

33a1-35

Void

36

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?

6,7

P

37-40

Void

41

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

(NOTE 1)

7

P

41A

Check: Is the test procedure MCVideo Media Reception End Request CT as described in TS 36.579-1 [2] Table 5.3B.10.3-1 correctly performed?

1

P

42

Check: Is the test procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to downgrade the Chat Group Call from an Imminent Peril state to a regular Chat Group Call correctly performed?

5

P

43a1-45

Void

46

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?

6,7

P

47-50

Void

6

P

51

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

(NOTE 1)

7

P

52

Void

53

Make the UE (MCVideo User) request termination of the MCVideo call.

(NOTE 1)

53A

Check: Is the test procedure MCVideo Media Reception End Request CO as described in TS 36.579-1 [2] Table 5.3B.8.3-1 correctly performed?

1

P

54

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the chat group call?

8

P

55

Void

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

6.1.2.3.3.3 Specific message contents

Table 6.1.2.3.3.3-1: SIP INVITE (Step 2, Table 6.1.2.3.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.3.3.3-1A

MIME body part

MCVideo Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3-2

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

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

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

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

Table 6.1.2.3.3.3-3: SIP 200 (OK) (Step 2, Table 6.1.2.3.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, conditionINVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

SDP Message

SDP message as described in Table 6.1.2.3.3.3-3A

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

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

Table 6.1.2.3.3.3-4 .. 7: Void

Table 6.1.2.3.3.3-8: SIP INVITE (Step 12, Table 6.1.2.3.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3.3-9

Table 6.1.2.3.3.3-9: MCVideo-Info in SIP INVITE (Table 6.1.2.3.3.3-8)

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

Table 6.1.2.3.3.3-10: SIP 200 (OK) (Step 12, Table 6.1.2.3.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3.3-11

Table 6.1.2.3.3.3-11: MCVideo-Info in SIP 200(OK)(Table 6.1.2.3.3.3-10)

Derivation Path: TS 56.379-1 [2], Table 5.5.3.2.1-2, condition INVITE-RSP

Table: 6.1.2.3.3.3-11A: Media Transmission Notification (Step 16, Table 6.1.2.3.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.3.3.3-12: Receive Media Request (Step 16, Table 6.1.2.3.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.3.3.3-13: Receive Media Response (Step 16, Table 6.1.2.3.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table 6.1.2.3.3.3-14: SIP INVITE (Steps 20, 38, Table 6.1.2.3.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3.3-15

Table 6.1.2.3.3.3-15: MCVideo-Info in SIP INVITE (Table 6.1.2.3.3.3-14)

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

Table 6.1.2.3.3.3-16: SIP INVITE (Step 29, Table 6.1.2.3.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, condition re_-INVITE, IMMPERIL-CALL

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3.3-17

Table 6.1.2.3.3.3-17: MCVideo-Info in SIP INVITE (Table 6.1.2.3.3.3.16)

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

Table: 6.1.2.3.3.3-17A: Media Transmission Notification (Step 36, Table 6.1.2.3.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.3.3.3-17B: Receive Media Request (Step 36, Table 6.1.2.3.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.3.3.3-17C: Receive Media Response (Step 36, Table 6.1.2.3.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table 6.1.2.3.3.3-18: SIP BYE (Step 48, Table 6.1.2.3.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3.10.3-1)

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

Table 6.1.2.3.3.3-19: Void

6.1.2.4 On-network / Chat Group Call / Emergency Call / Imminent Peril Call / Client Terminated (CT)

6.1.2.4.1 Test Purpose (TP)

(1)

with { 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 Emergency Chat Group Call }

then { the UE (MCVideo Client) displays an indication for the MCVideo Emergency Chat 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 ongoing MCVideo Emergency Chat Group Call, with implicit Reception Control }

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, upon receipt of approval from the user, 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, Transmission Granted, Media Reception End Request, Media Reception End Response) }

}

(3)

with { the UE (MCVideo Client) having an ongoing Emergency Chat Group Call, with implicit Reception Control and having sent a Receive Media Request message }

ensure that {

when { the UE (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 Emergency Chat Group Call, with implicit Reception Control }

ensure that {

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

then { the UE (MCVideo Client) notifies the MCVideo User, and upon receipt of user acceptance, sends a Media Reception End Response message to the SS (MCVideo Server }

}

(5)

with { the UE (MCVideo Client) having an ongoing Emergency Chat Group Call with Automatic Commencement Mode }

ensure that {

when { the MCVideo User requests to end the Emergency Chat Group Call, }

then { the UE (MCVideo Client) sends a SIP BYE message to the SS (MCVideo Server, receives a SIP 200 (OK) message, and leaves the MCVideo session }

}

(6)

with { 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 imminent peril indication for a MCVideo On-demand Imminent Peril Chat Group Call }

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

}

(7)

with { the UE (MCVideo Client) having an ongoing Imminent Peril Chat Group Call, with implicit Reception Control }

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, upon receipt of approval from the user, 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, Transmission Granted, Media Reception End Request, Media Reception End Response) }

(8)

with { the UE (MCVideo Client) having an ongoing Imminent Peril Chat Group Call, with implicit Reception Control and having sent a Receive Media Request message }

ensure that {

when { the UE (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 }

(9)

with { the UE (MCVideo Client) having an ongoing Imminent Peril Chat Group Call, with implicit Reception Control }

ensure that {

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

then {the UE (MCVideo Client) notifies the MCVideo User, and upon receipt of user acceptance, sends a Media Reception End Response message to the SS (MCVideo Server }

(10)

with { the UE (MCVideo Client) having an ongoing Imminent Peril Chat Group Call with Automatic Commencement Mode }

ensure that {

when { the MCVideo User requests to end the Emergency Chat Group Call, }

then { the UE (MCVideo Client) sends a SIP BYE message to the SS (MCVideo Server, receives a SIP 200 (OK) message, and leaves the MCVideo session }

}

6.1.2.4.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.281, clauses 2, 9.2.2.2.1.2, 9.2.2.2.1.6, 9.2.2.2.2.2, 6.2.6 and TS 24.581, clauses 6.2.5.3.2, 6.2.5.3.3, 6.2.5.4.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-14 requirements.

[TS 24.281, clause 9.2.2.2.1.2]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, clause 9.2.2.2.1.6]

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

In the procedures in this clause:

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

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

Upon receipt of an initial SIP INVITE request, the MCVideo client:

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

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

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

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

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

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

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

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

ii) should display the MCVideo group identity of the group with the emergency condition contained in the <mcvideo-calling-group-id> element; 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.281, clause 9.2.2.2.2.2]

Upon receiving a SIP BYE request for releasing the MCVideo chat session, 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.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.

6.1.2.4.3 Test description

6.1.2.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 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.2.4.3.2 Test procedure sequence

Table 6.1.2.4.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Is the test procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to initiate an Emergency Chat Group Call correctly performed?

1

P

2a1-4

Void

5

Check: Does the UE (MCVideo client) notify the user that the Emergency Chat Group Call has been successfully established?

(NOTE 1)

1

P

6

Void

6A

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?

2,3

P

6B-6E

Void

6F

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

3

P

6G

Check: Is the test procedure MCVideo Media Reception End Request CT as described in TS 36.579-1 [2] Table 5.3B.10.3-1 correctly performed?

4

P

6H-6I

Void

7

Make the MCVideo User request the UE (MCVideo Client) to end the Emergency Chat Group Call.

(NOTE 1)

8

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the on-demand group call.

2

P

9

Void

10

Check: Is the test procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to initiate an Imminent Peril Chat Group Call correctly performed?

3

P

11a1-13

Void

14

Check: Does the UE (MCVideo client) notify the user that the Imminent Peril Group Call has been successfully established?

(NOTE 1)

6

P

14A

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?

7

P

14B-14E

Void

14F

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

(NOTE 1)

8

P

14G

Check: Is the test procedure MCVideo Media Reception End Request CT as described in TS 36.579-1 [2] Table 5.3B.10.3-1 correctly performed?

4,9

P

14H-15

Void

16

Make the MCVideo User request to end an Imminent Peril Chat Group Call.

(NOTE 1)

17

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 To end the call?

10

P

18

Void

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

6.1.2.4.3.3 Specific message contents

Table 6.1.2.4.3.3-1: SIP INVITE (Step 1, Table 6.1.2.4.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-body

"application/vnd.3gpp.mcvideo-info+xml" as described in Table 6.1.2.4.3.3-2

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

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

Table 6.1.2.4.3.3-3: SIP 200 (OK) (Step 3, Table 6.1.2.4.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-body

"application/vnd.3gpp.mcvideo-info+xml" as described in Table 6.1.2.4.3.3-4

Table 6.1.2.4.3.3-4: MCVideo-Info in SIP 200 (OK) (Table 6.1.2.4.3.3-3)

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

Table: 6.1.2.4.3.3-5: Void

Table: 6.1.2.4.3.3-5A: Media Transmission Notification (Step 6A, Table 6.1.2.4.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.4.3.3-5B: Receive Media Request (Step 6A, Table 6.1.2.4.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.4.3.3-5C: Receive Media Response (Step 6A, Table 6.1.2.4.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.4.3.3-5D: Media Reception End Request (Step 6G, Table 6.1.2.4.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table 6.1.2.4.3.3-6: SIP BYE (Steps 8, 17, Table 6.1.2.4.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3.10.3-1)

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

Table 6.1.2.4.3.3-7: Void

Table 6.1.2.4.3.3-8: SIP INVITE (Step 10, Table 6.1.2.4.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-body

MCVideo-Info as described in Table 6.1.2.4.3.3-9

Table 6.1.2.4.3.3-9: MCVideo-Info in SIP INVITE (Table 6.1.2.4.3.3-8)

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

Table 6.1.2.4.3.3-10: SIP 200 (OK) (Step 10, Table 6.1.2.4.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-body

"application/vnd.3gpp.mcvideo-info+xml" as described in Table 6.1.2.4.3.3-11

Table 6.1.2.4.3.3-11: MCVideo-Info in SIP 200 (OK) (Table 6.1.2.4.3.3-10)

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

Table: 6.1.2.4.3.3-12: Void

Table: 6.1.2.4.3.3-13: Media Transmission Notification (Step 14A, Table 6.1.2.4.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.4.3.3-14: Receive Media Request (Step 14A, Table 6.1.2.4.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.4.3.3-15: Receive Media Response (Step 14A, Table 6.1.2.4.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

Table: 6.1.2.4.3.3-16: Media Reception End Request (Step 14G, Table 6.1.2.4.3.2-1; Step 5, TS 36.579-1 [2] Table 5.3B.3.3-1)

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

6.1.2.5 On-network / Chat Group Call / Emergency Call / Imminent Peril Call / Client Originated (CO)

6.1.2.5.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCVideo User requests to establish a MCVideo Emergency Chat Group Call with implicit Transmission Control}

then { the UE(MCVideo Client) sends a SIP INVITE message, and, upon receipt of a Transmission Granted message from the SS MCVideo Server that the call was established, notifies the user and respects Transmission Control (Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission End Response) }

}

(2)

with { UE (MCVideo Client) having an ongoing MCVideo Emergency Chat Group Call }

ensure that {

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

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

}

(3)

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

ensure that {

when { the UE(MCVideo Client) requests to establish a MCVideo Imminent Peril Chat Group Call }

then { the UE(MCVideo Client) requests the establishment of a MCVideo Imminent Peril Chat Group Call by sending a SIP INVITE message, and, upon receipt of a Transmission Granted message from the SS (MCVideo Server) that the call was established, notifies the user and respects Transmission Control ((Transmission Granted, Transmission Control ACK, Transmission End Request, Transmission End Response) }

}

}

(4)

with { UE (MCVideo Client) having an ongoing MCVideo Imminent Peril Chat Group Call }

ensure that {

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

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

}

6.1.2.5.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in TS 24.281 clauses 9.2.2.2.1.1.1, 9.2.2.2.2.1, 6.2.4.1 and TS 24.581 clause 6.2.4.3.3The 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-14 requirements.

[TS 24.281, clause 9.2.2.2.1.1.1]

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

The MCVideo client:

1) if the MCVideo user has requested the origination of an MCVideo emergency group call or is originating an MCVideo chat group call and the MCVideo emergency state is already set, the MCVideo client shall comply with the procedures in 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) shall include the g.3gpp.mcvideo media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [22];

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

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

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

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

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

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

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

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

11) if the MCVideo emergency state is already set or the MCVideo client emergency group state for this group is set to "MVEG 2: in-progress", the MCVideo client shall comply with the procedures in subclause 6.2.8.1.2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the MCVideo client shall perform the actions specified in 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.2.2.2.1]

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

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

[TS 24.581, clause 6.2.4.3.3]

Upon receiving a Transmission Granted message from the transmission control server due to remote Transmission request, 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 ‘1’ (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; and

4. shall enter the ‘U: has permission to transmit’ state.6.1.2.5.3 Test description

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

– The MCVideo User performs the Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.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.2.5.3.2 Test procedure sequence

Table 6.1.2.5.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User initiate an On-network On-demand Emergency Chat Group Call.

(NOTE 1).

2

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ according to option b,ii of NOTE 1 as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to initiate an MCVideo Emergency Chat Group Call?

1

P

3-7

Void

9

Check: Does the UE (MCVideo client) notify the user that the Emergency Chat Group Call has been successfully established?

(NOTE 1)

1

P

10

Make the UE (MCVideo User) request to end transmission.

(NOTE 1)

11a

Check: Does the UE (MCVideo Client) orrectly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1 to terminate the Group Chat Call?

1

P

12-13

Void

14

Make the MCVideo User request to end the Imminent Peril Chat Call.

15

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1to terminate the Emergency Chat Group Call?

2

P

16

Void

17

Make the MCVideo User initiate an On-network On-demand Imminent Peril Chat Group Call.

17A

Check: Does the UE (MCVideo Client) correctly perform test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ according to option b,ii of NOTE 1 as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to initiate an MCVideo Imminent Peril Chat Group Call?

3

P

18-22

Void

23

Check: Does the UE (MCVideo client) notify the user that the Imminent Peril Chat Group Call has been successfully established?

(NOTE 1)

3

P

24

Make the UE (MCVideo User) request to end the transmission.

(NOTE 1)

25

Check: Does the UE (MCVideo Client) correctly perform test procedure MCVideo transmission End Request CO as described in TS 36.579-1 [2] Table 5.3B.7.3-1to terminate the Group Chat Call?

3

P

26-27

Void

28

Make the MCVideo User request to end the On-network On-Demand Imminent Peril Chat Call.

29

Check: Does the UE (MCVideo Client) correctly perform test procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to terminate the Imminent Peril Chat Group call?

4

P

30

Void

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

6.1.2.5.3.3 Specific message contents

Table 6.1.2.5.3.3-1: SIP INVITE (Step 2, Table 6.1.2.5.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-body

SDP Message as described in Table 6.1.2.5.3.3-1A

MIME body part

MCVIDEO-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.5.3.3-2

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

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

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

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

Table 6.1.2.5.3.3-3: SIP 200 (OK) (Steps 2, 17A Table 6.1.2.5.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

SDP Message

SDP Message as described in Table 6.1.2.5.3.3-3A

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

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

Table 6.1.2.5.3.3-4: Transmission Granted (Step 2, Table 6.1.2.5.3.2-1; Step 6a1, TS 36.579-1 [2] Table 5.3B.1.3-1)

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

Table 6.1.2.5.3.3-5: SIP BYE (Steps 15, 29, Table 6.1.2.5.3.2-1)

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

Table 6.1.2.5.3.3-6: Void

Table 6.1.2.5.3.3-7: SIP INVITE (Step 17A, Table 6.1.2.5.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition IMMPERIL-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.2.5.3.3-8

Table 6.1.2.5.3.3-8: MCVideo-Info in SIP INVITE (Table 6.1.2.5.3.3-7)

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

Table 6.1.2.5.3.3-9: Transmission Granted (Step 21, Table 6.1.2.5.3.2-1; Step 6a1, TS 36.579-1 [2] Table 5.3B.1.3-1)

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