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)

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

2

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

–>

SIP INVITE

1

P

3

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

<–

SIP 100 (Trying)

4

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

<–

SIP 200 (OK)

5

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

–>

SIP ACK

1

P

6

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

<–

Transmission Granted

7

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

–>

Transmission Control Ack

1

P

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: This is expected to be done via a suitable implementation-dependent MMI.

10

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

–>

Transmission End Request

2

P

11

The SS (MCVideo Server) sends a Transmission End Response to the UE (MCVideo Client) in response to the Transmission End Request.

<–

Transmission End Response

12

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

–>

Transmission Control Ack

2

P

13

Void

14

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

(NOTE 1)

15

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

–>

SIP BYE

3

P

16

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

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

(NOTE 2)

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

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

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)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

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

MIME-part-body

MCVideo-Info as described in Table 6.1.2.1.3.3-2

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 GROUP-CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.1.3.3-3: SIP 200 (OK) (Steps 4, Table 6.1.2.1.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.2.1.3.3-2

Table 6.1.2.1.3.3-3A: MCVideo-Info in SIP 200 (OK) (Table 6.1.2.1.3.3-3)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.1.3.3-4: Transmission Granted (Step 6, Table 6.1.2.1.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

‘1000000000000000’

A = normal call

Table 6.1.2.1.3.3-5: Transmission Control Ack (Steps 7,12, Table 6.1.2.1.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

‘00010001’

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

Table 6.1.2.1.3.3-6: Void

Derivation Path: TS 24.581 [88], Table 5.5.11.3.5-1

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

‘00010001’

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

Table 6.1.2.1.3.3-7: SIP BYE (Step 15, Table 6.1.2.1.3.2-1)

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

Table 6.1.2.1.3.3-8: SIP 200 (OK) (Step 16, Table 6.1.2.1.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

Content-Length

value

‘0’

No message body included

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

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

2

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

–>

SIP INVITE

1

P

3

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

<–

SIP 100 (Trying)

4

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

<–

SIP 200 (OK)

5

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

–>

SIP ACK

1

P

6

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

<–

Transmission Granted

7

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

–>

Transmission Control Ack

1

P

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 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) send a SIP re-INVITE request message to upgrade the call to an Emergency Group Call with implicit Transmission Control?

–>

SIP re-INVITE

2

P

11

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

<–

SIP 100 (Trying)

12

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

<–

SIP 200 (OK)

13

Check: Does the UE (MCVideo Client) acknowledges the SIP 200 (OK)?

–>

SIP ACK

2

P

14

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

<–

Transmission Granted

15

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

–>

Transmission Control ACK

1

P

16

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

(NOTE 1)

2

P

17

Make the MCVideo User downgrade the Emergency state

(NOTE 1)

18

Check: Does the UE (MCVideo Client) send a SIP re-INVITE request message to cancel the Emergency state?

–>

SIP re-INVITE

3

P

19

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

<–

SIP 100 (Trying)

20

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

<–

SIP 200 (OK)

21

Check: Does the UE (MCVideo Client) acknowledges the SIP 200 (OK)?

–>

SIP ACK

22

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

<–

Transmission Granted

23

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

–>

Transmission Control ACK

1

P

24

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

(NOTE 1)

3

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) send a SIP re-INVITE request message to upgrade the call to an Imminent Peril Group Chat Call with implicit Transmission Control?

–>

SIP re-INVITE

4

P

27

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

<–

SIP 100 (Trying)

28

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

<–

SIP 200 (OK)

29

Check: Does the UE (MCVideo Client) acknowledges the SIP 200 (OK)?

–>

SIP ACK

30

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

<–

Transmission Granted

31

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

–>

Transmission Control ACK

1

P

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

33

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

(NOTE 1)

34

Check: Does the UE (MCVideo Client) send a SIP re-INVITE request message to downgrade the Imminent Peril state?

–>

SIP re-INVITE

5

P

35

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

<–

SIP 100 (Trying)

36

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

<–

SIP 200 (OK)

37

Check: Does the UE (MCVideo Client) acknowledges the SIP 200 (OK)?

–>

SIP ACK

38

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

<–

Transmission Granted

39

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

–>

Transmission Control ACK

1

P

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) send a Transmission End Request to terminate the Group Chat Call?

–>

Transmission End Request

1

P

43

The SS (MCVideo Server) sends a Transmission End Response message.

<–

Transmission End Response

44

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

–>

Transmission Control ACK

1

P

45

Void

46

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

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

47

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

–>

SIP BYE

6

P

48

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

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

(NOTE 2)

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

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

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)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

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

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-2

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 GROUP-CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.2.3.3-3: SIP 200 (OK) (Steps 4, 20, 36, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo-info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-4

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

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.2.3.3-5: Transmission Granted (Steps 6, 22, 38, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘1000000000000000’

A = normal

Table 6.1.2.2.3.3-6: Void

Table 6.1.2.2.3.3-7: SIP re_INVITE (Step 10, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

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

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-8

Table 6.1.2.2.3.3-8: MCVideo-Info in SIP re_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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.2.3.3-9: SIP 200 (OK) (Steps 12, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

INVITE-RSP

MIME body part

MCVideo-info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-10

Table 6.1.2.2.3.3-10: MCVideo-Info (Table 6.1.2.2.3.3-9)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.2.3.3-11: Transmission Granted (Step 14, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

‘0001000000000000’

D = Emergency Call

Table 6.1.2.2.3.3-12: Void

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

Information Element

Value/remark

Comment

Reference

Condition

Message Type

Message Type

‘00010000’

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

Table 6.1.2.2.3.3-13: SIP re_INVITE (Step 18, 34, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

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

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-2

Table 6.1.2.2.3.3-14: Transmission Granted (Steps 22, 38, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

‘1000000000000000’

A = normal

Table 6.1.2.2.3.3-15: Void

Table 6.1.2.2.3.3-16: SIP re-INVITE (Step 26, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

Content-Type

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

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-17

Table 6.1.2.2.3.3-17: MCVideo-Info in SIP re_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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.2.3.3-18: SIP 200 (OK) (Step 28, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

INVITE-RSP

MIME body part

MCVideo-info

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.2.2.3.3-19

Table 6.1.2.2.3.3-19: MCVideo-Info (Table 6.1.2.2.3.3-16)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.2.3.3-20: Transmission Granted (Step 30, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

Transmission Indicator

‘0000100000000000’

E = Imminent Peril

Table 6.1.2.2.3-21: Void

Table 6.1.2.2.3.3-22: Transmission End Response (Step 42, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Subtype

‘10001’

Table 6.1.2.2.3.3-23: Void

Table: 6.1.2.2.3.3-24: Void

Table 6.1.2.2.3.3-25: SIP BYE (Step 47, Table 6.1.2.2.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

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)

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

2

Check: Does the UE (MCVideo Client) send a SIP INVITE to initiate a chat group call?

–>

SIP INVITE

1

P

3

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

<–

SIP 100 (Trying)

4

The SS (MCVideo Server) responds with a SIP 200 (OK).

<–

SIP 200 (OK)

5

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

–>

SIP ACK

1

P

6

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

<–

Transmission Granted

7

Check: Does the UE (MCVideo Client) send a Transmission Control ACK Message?

–>

Transmission Control ACK Message

1

P

8

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

(NOTE 1)

1

P

9

Make the MCVideo User release Transmission Control.

(NOTE 1)

10

Check: Does the UE (MCVideo Client) send a Transmission Release message?

–>

Transmission Release

1

P

11

The SS (MCVideo Server) sends a Transmission Idle to indicate that the transmission has ended and there are no current active transmissions.

<–

Transmission Idle

12

The SS (MCVideo Server) sends a SIP-re-INVITE message to indicate an upgrade of the Chat Group Call to an Emergency state.

<–

SIP re-INVITE

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

13a1

The UE (MCVideo Client) sends a SIP 100 (Trying) message in response

–>

SIP 100 (Trying)

14

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

–>

SIP 200 (OK)

2

P

15

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

<–

SIP ACK

16

The SS (MCVideo Server) sends a Media Transmission Notification message to notify the UE client that an emergency media transmission is available from another user.

<–

Media Transmission Notification

17

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

(NOTE 1)

6

P

18

Make the MCVideo User to request permission to receive media.

(NOTE 1)

19

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

–>

Receive Media Request

7

P

20

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

<–

Receive Media Response

21

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

(NOTE 1)

7

P

22

The SS (MCVideo Server) sends a SIP re-INVITE message to downgrade the Chat Group Call from an Emergency state to a regular Chat Group Call.

<–

SIP re-INVITE

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

23a1

The UE (MCVideo Client) sends a SIP 100 (Trying) message in response

–>

SIP 100 (Trying)

24

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

–>

SIP 200 (OK)

3

P

25

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

<–

SIP ACK

26

The SS (MCVideo Server) sends a Media Transmission Notification message to notify the UE Client that a normal media transmission is available from another user.

<–

Media Transmission Notification

27

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

(NOTE 1)

6

P

28

Make the MCVideo User to request permission to receive media.

(NOTE 1)

29

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

–>

Receive Media Request

7

P

30

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

<–

Receive Media Response

31

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

(NOTE 1)

7

P

32

The SS (MCVideo Server) sends a SIP-re-INVITE message to upgrade the Chat Group Call to an Imminent Peril state.

<–

SIP re-INVITE

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

33a1

The UE (MCVideo Client) sends a SIP 100 (Trying) message in response

–>

SIP 100 (Trying)

-*

34

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

–>

SIP 200 (OK)

4

P

35

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

<–

SIP ACK

36

The SS (MCVideo Server) sends a Media Transmission Notification message to notify the UE client that an imminent peril media transmission is available from another user.

<–

Media Transmission Notification

37

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

(NOTE 1)

6

P

38

Make the MCVideo User to request permission to receive media.

(NOTE 1)

39

Check: Does the UE respond with a Receive Media Request message?

–>

Receive Media Request

7

P

40

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

<–

Receive Media Response

41

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

(NOTE 1)

7

P

42

The SS (MCVideo Server) sends a SIP re-INVITE message to downgrade the Chat Group Call from an Imminent Peril state to a regular Chat Group Call.

<–

SIP re-INVITE

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

43a1

The UE (MCVideo Client) sends a SIP 100 (Trying) message in response

–>

SIP 100 (Trying)

-*

44

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

–>

SIP 200 (OK)

5

P

45

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

<–

SIP ACK

46

The SS (MCVideo Server) sends a Media Transmission Notification message to notify the UE Client that a normal media transmission is available from another user.

<–

Media Transmission Notification

47

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

(NOTE 1)

6

P

48

Make the MCVideo User to request permission to receive media.

(NOTE 1)

49

Check: Does the UE respond with a Receive Media Request message?

–>

Receive Media Request

7

P

50

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

<–

Receive Media Response

51

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

(NOTE 1)

7

P

52

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

<–

Transmission Idle

53

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

(NOTE 1)

54

Check: Does the UE (MCVideo Client) sends a SIP BYE message to end the chat group call?

–>

SIP BYE

8

P

55

The SS responds with a SIP 200 (OK)

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

(NOTE 2)

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

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

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)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3-2

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 GROUP-CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.3.3.3-3: SIP 200 (OK) (Step 4, Table 6.1.2.3.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3.3-4

Table 6.1.2.3.3.3-4: MCVideo-Info in SIP INVITE (Table 6.1.2.3.3.3-3)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.3.3.3-5: Void

Table 6.1.2.3.3.3-6: Void

Table 6.1.2.3.3.3-7: Transmission Idle (Step 11, Table 6.1.2.3.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.11.2.16-1

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘1000010000000000’

A= normal call

F = Queueing supported

Table 6.1.2.3.3.3-8: SIP re-INVITE (Step 12, Table 6.1.2.3.3.2-1)

Derivation Path: TS 36.579-1, Table 5.5.2.5.2-1, condition re_INVITE, EMERGENCY-CALL, MCVIDEO

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-header

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 re-INVITE (Table 6.1.2.3.3.3-8)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.3.3.3-10: SIP 200 (OK) (Step 14, Table 6.1.2.3.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-Content-Type

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

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 INVITE (Table 6.1.2.3.3.3-10)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table: 6.1.2.3.3.3-12: Receive Media Request (Step 19, Table 6.1.2.3.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0001000000000000’

D = Emergency Call

Table: 6.1.2.3.3.3-13: Receive Media Response (Step 20, Table 6.1.2.3.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Transmission Indicator

‘0001000000000000’

D = Emergency Call

Table 6.1.2.3.3.3-14: SIP re-INVITE (Steps 20, 38, Table 6.1.2.3.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.1.2.3.3.3-15

Message-body

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

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.3.3.3-16: SIP re-INVITE (Steps 29, Table 6.1.2.3.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

McVideo

MIME-part-header

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 re-INVITE (Table 6.1.2.3.3.3.16)

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

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.4.3.3-18: SIP BYE (Step 48, Table 6.1.2.2.3.2-1)

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

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

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

1

The SS (MCVideo Server) sends a SIP INVITE message to initiate an Emergency Chat Group Call

<–

SIP INVITE

1

P

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

2a1

The UE (MCVideo Client) sends a SIP 100 (Trying) message

–>

SIP 100 (Trying)

3

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

–>

SIP 200 (OK)

1

P

4

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

<–

SIP ACK

5

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

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

<–

Media Transmission Notification

6B

Check: Does the UE (MCVideo Client) notify the MCVideo User of the Media Transmission Notification?

(NOTE 1)

2

P

6C

Make the MCVideo User accept the transmission indicated by the Media Transmission Notification message from the SS (MCVideo Server)

(NOTE 1)

6D

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

–>

Receive Media Request

2

P

6E

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

<–

Receive Media Response

3

P

6F

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

3

P

6G

The SS (MCVideo Server) requests to terminate the RTP media reception by sending a Media Reception End Request message.

<–

Media Reception End Request

6H

Check: Does the UE (MCVideo Client) notify the MCVideo User of receipt of the Media Reception End Request?

(NOTE 1)

4

P

6I

Check: Does the UE (MCVideo Client) send a Media Reception End Response to the SS (MCVideo Server)?

–>

Media Reception End Response

4

P

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) send a SIP BYE message to end the on-demand group call.

–>

SIP BYE

2

P

9

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

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

(NOTE 2)

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

10

The SS (MCVideo Server) sends a SIP INVITE message to initiate an Imminent Peril Chat Group Call

<–

SIP INVITE

3

P

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

11a1

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

–>

SIP 100 (Trying)

12

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

–>

SIP 200 (OK)

3

P

13

The SS (MCVideo Server) sends a SIP ACK.

<–

SIP ACK

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

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

<–

Media Transmission Notification

14B

Check: Does the UE (MCVideo Client) notify the MCVideo User of the Media Transmission Notification?

(NOTE 1)

7

P

14C

Make the MCVideo User accept the transmission indicated by the Media Transmission Notification message from the SS (MCVideo Server)

(NOTE 1)

14D

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

–>

Receive Media Request

7

P

14E

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

<–

Receive Media Response

14F

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

(NOTE 1)

8

P

14G

The SS (MCVideo Server) requests to terminate the RTP media reception by sending a Media Reception End Request message?

<–

Media Reception End Request

14H

Check: Does the UE (MCVideo Client) notify the MCVideo User of receipt of the Media Reception End Request?

9

P

14I

Check: Does the UE (MCVideo Client) send a Media Reception End Response to the SS (MCVideo Server)?

–>

Media Reception End Response

4

P

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) send a SIP BYE (to terminate the media plane)?

–>

SIP BYE

10

P

18

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

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

(NOTE 2):

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

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

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)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-headers

MIME-Content-Type

"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, Table 5.5.3.2.2-2, condition MCVIDEO, GROUP-CALL, EMERGENCY-CALL, CHAT-GROUPCALL, INVITE-REFER

Table 6.1.2.4.3.3-3: SIP 200 (OK) (Step 3, Table 6.1.2.4.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-headers

MIME-Content-Type

"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 (Table 6.1.2.4.3.3-3)

Derivation Path: TS 36.579-1, Table 5.5.3.2.1-2, condition MCVIDEO, GROUP-CALL, EMERGENCY-CALL, CHAT-GROUPCALL, INVITE-REFER

Table: 6.1.2.4.3.3-5: Void

Table 6.1.2.4.3.3-6: SIP BYE (Steps 8, 17, Table 6.1.2.4.3.2-1)

Derivation Path: TS 36.579-1, Table 5.5.2.2.1-1, condition MO_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)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-headers

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, Table 5.5.3.2.2-2, condition MCVIDEO, GROUP-CALL, IMMPERIL-CALL, CHAT-GROUPCALL, , INVITE-REFER

Table 6.1.2.4.3.3-10: SIP 200 (OK) (Step 12, Table 6.1.2.4.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVideo

MIME-part-headers

MIME-Content-Type

"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 (Table 6.1.2.4.3.3-10)

Derivation Path: TS 36.579-1, Table 5.5.3.2.1-2, condition MCVIDEO, GROUP-CALL, IMMPERIL-CALL, CHAT-GROUPCALL, INVITE-REFER

Table: 6.1.2.4.3.3-12: Void

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

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

2

Upon receipt of a request from the MCVideo User, the UE (MCVideo Client) sends a SIP INVITE message to initiate a MCVideo Emergency Chat Group Call?

–>

SIP INVITE

3

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

<–

SIP 100 (Trying)

4

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

<–

SIP 200 (OK)

5

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

–>

SIP ACK

1

P

6

Check: Does the UE (MCVideo Client) receive a Transmission Granted message from the SS( MCVideo Server)?

<–

Transmission Granted

1

P

7

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

–>

Transmission Control Ack

1

P

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) send a Transmission End Request to terminate the Group Chat Call?

–>

Transmission End Request

1

P

12

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

<–

Transmission End Response

13

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

–>

Transmission Control ACK

1

P

14

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

15

Check: Does the UE (MCVideo Client) send a SIP BYE (to terminate the Emergency Chat Group Call)?

–>

SIP BYE

2

P

16

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

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

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

17

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

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

17

Check: Does the UE (MCVideo Client) send an SIP INVITE message to initiate a MCVideo Imminent Peril Chat Group Call?

–>

SIP INVITE

3

P

18

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

<–

SIP 100 (Trying)

19

The SS (MCVideo Server) answers the call with a SIP 200 (OK).

<–

SIP 200 (OK)

20

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

–>

SIP ACK

3

P

21

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

<–

Transmission Granted

22

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

–>

Transmission Control Ack

3

P

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) send a Transmission End Request to terminate the Group Chat Call?

–>

Transmission End Request

3

P

26

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

<–

Transmission End Response

27

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

–>

Transmission Control ACK

3

P

28

Make the MCVideo User request to end the On-network On-Demand Imminent Peril Chat Call.

29

Check: Does the UE (MCVideo Client) send a SIP BYE (to terminate the Imminent Peril Chat Group call)?

–>

SIP BYE

4

P

30

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

<–

SIP 200 (OK)

EXCEPTION: The SS (MCVideo Server) waits 2 seconds before the SS (MCVideo Server) deactivates the dedicated EPS bearer and releases the RRC connection.

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

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

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

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

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

MCVIDEO-Info

MIME-part-body

MCVideo-Info as described in Table 6.1.2.5.3.3-2

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, Table 5.5.3.2.2-1, condition EMERGENCY CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

Table 6.1.2.5.3.3-3: SIP 200 (OK) (Steps 4, 19 Table 6.1.2.5.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

 

 

 

Content-Length

 

 

 

 

  value

"0"

No message body included

 

 

Table 6.1.2.5.3.3-4: Transmission Granted (Step 6, Table 6.1.2.5.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

  Transmission Indicator

"1001000000000000"

D = Emergency call

TS 24.581 [27], clause 9.2.5.1

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, Table 5.5.2.2-1, condition MO_CALL

Information Element

Value/remark

Comment

Reference

Condition

Table 6.1.2.5.3.3-6 SIP 200 (OK) (Steps 16, 30, Table 6.1.2.5.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Content-Type

not present

 

 

 

Content-Length

 

 

 

 

  value

"0"

No message body included

 

 

Table 6.1.2.5.3.3-7: SIP INVITE (Step 17, Table 6.1.2.5.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition MCVIDEO, GROUP-CALL, 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, Table 5.5.3.2.2-1, condition IMMPERIL-CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"chat"

I

Table 6.1.2.5.3.3-9: Transmission Granted (Step 21, Table 6.1.2.5.3.2-1)

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

Information Element

Value/remark

Comment

Reference

Condition

Transmission Indicator

Length is 16 bits, A-P.

  Transmission Indicator

"1000100000000000"

E = Imminent Peril call

TS 24.581 [27], clause 9.2.5.1