6.1.1 Pre-arranged Group Call

36.579-23GPPMission Critical (MC) services over LTEPart 2: Mission Critical Push To Talk (MCPTT) User Equipment (UE) Protocol conformance specificationRelease 15TS

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

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

6.1.1.1.1 Test Purpose (TP)

(1)

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

ensure that {

when { the MCPTT User requests the establishment of an MCPTT On-demand Pre-arranged Group Call requesting force of Automatic Commencement Mode at the invited MCPTT client(s) and implicit floor control }

then { UE (MCPTT Client) requests On-demand Automatic Commencement Mode Pre-arranged Group Call establishment with implicit floor control by sending a SIP INVITE message, and, after indication from the MCPTT Server that the call was established and receiving a Floor Granted message, notifies the user }

}

(2)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode }

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server (Floor Request during a talk burst, Floor granting/release, Floor idle, Floor deny, Floor taken/revoked) }

}

(3)

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

ensure that {

when { the SS (MCPTT Server) needs to terminate the ongoing MCPTT Group Call and the SS (MCPTT Server) sends a SIP BYE request }

then { UE (MCPTT Client) responds with a SIP 200 (OK) and leaves the MCPTT session }

}

(4)

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

ensure that {

when { the MCPTT User (MCPTT Client) wants to upgrade the ongoing MCPTT Group Call to an MCPTT Emergency Group Call with floor control }

then { UE (MCPTT Client) sends a SIP re-INVITE request and upon receipt of a SIP 2xx response considers the call as being upgraded to Emergency Group Call (emergency group call state = "MEGC 3: emergency-call-granted") }

}

(5)

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

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server }

}

(6)

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

ensure that {

when { the MCPTT User (MCPTT Client) wants to cancel the ongoing MCPTT Emergency state }

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

}

(7)

ensure that {

when { the MCPTT User (MCPTT Client) wants to upgrade the ongoing MCPTT Group Call to an MCPTT Imminent Peril Group Call with floor control }

then { UE (MCPTT Client) sends a SIP re-INVITE request and upon receipt of a SIP 2xx response considers the call as being upgraded to Imminent Peril Group Call (imminent peril group call state = "MIG 2: in-progress") }

}

(8)

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

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server }

}

(9)

with { UE (MCPTT Client) having upgraded an On-demand Pre-arranged Group Call with Automatic Commencement Mode to an Imminent Peril Group Call and the MCPTT User being authorised for cancelling an MCPTT Imminent Peril state (MCPTT in-progress imminent peril cancel) }

ensure that {

when { the MCPTT User (MCPTT Client) wants to cancel the ongoing MCPTT Imminent Peril state }

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

}

(10)

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

ensure that {

when { the MCPTT User (MCPTT Client) wants to terminate the ongoing MCPTT Group Call }

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

}

(11)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode and pc_MCPTT_FloorRequestQueueing = “true” }

ensure that {

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

then { UE (MCPTT Client) respects the floor control queue handling imposed by the MCPTT Server (Floor request queued, Floor queue position request and Floor queue position info) }

}

6.1.1.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379, clauses 10.1.1.2.1.1, 6.2.1, 6.2.3.1.2, 6.4, 6.5, 6.2.6, 10.1.1.2.1.3, 10.1.1.2.1.4, 6.2.8.1.3, 10.1.1.2.1.5, 6.2.8.1.11, 6.2.4.1, TS 24.380, clauses 6.2.4.5.3,6.2.4.6.4, 6.2.4.3.5, 6.2.4.4.2, 6.2.4.5.4, 6.2.4.6.5, 6.2.4.4.4, 6.2.4.4.9, 6.2.4.9.9, 6.2.4.9.6, 6.2.4.9.4. Unless otherwise stated, these are Rel-13 requirements.

[TS 24.379, clause 10.1.1.2.1.1]

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

The MCPTT client:

1) if the MCPTT user has requested the origination of an MCPTT emergency group call or is originating an MCPTT prearranged group call and the MCPTT emergency state is already set, the MCPTT client shall comply with the procedures in subclause 6.2.8.1.1;

2) if the MCPTT user has requested the origination of an MCPTT imminent peril group call, the MCPTT client shall comply with the procedures in subclause 6.2.8.1.9;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the MCPTT 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 MCPTT session ID identifying an ongoing group session, the MCPTT client shall follow the actions specified in subclause 6.2.8.1.13.

[TS 24.379, clause 6.2.1]

The SDP offer shall contain only one SDP media-level section for MCPTT speech according to 3GPP TS 24.229 [4] and, if floor control shall be used during the session, shall contain one SDP media-level section for a media-floor control entity according to 3GPP TS 24.380 [5].

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

1) shall set the IP address of the MCPTT client for the offered MCPTT speech media stream and, if floor control shall be used, for the offered media-floor control entity;

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

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

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

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

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

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

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

then the MCPTT client:

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

c) "i=" field set to "speech" according to 3GPP TS 24.229 [4];

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

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

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

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

[TS 24.379, clause 6.2.3.1.2]

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

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

[TS 24.379, clause 6.4]

An initial SIP INVITE request fulfilling the following criteria shall be regarded by the MCPTT server as an implicit floor request when the MCPTT client:

1) initiates an MCPTT speech session or initiates a pre-established session; and

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

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

1) performs an upgrade of:

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

b) an MCPTT private call to an emergency MCPTT private call; or

c) an MCPTT group call to an imminent peril MCPTT group call; and

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

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

[TS 24.379, clause 6.5]

The MCPTT client and the MCPTT server shall support several MIME bodies in SIP request and SIP responses.

When the MCPTT client or the MCPTT server sends a SIP message and the SIP message contains more than one MIME body, the MCPTT client or the MCPTT server:

1) shall, as specified in IETF RFC 2046 [21], include one Content-Type header field with the value set to multipart/mixed and with a boundary delimiter parameter set to any chosen value;

2) for each MIME body:

a) shall insert the boundary delimiter;

b) shall insert the Content-Type header field with the MIME type of the MIME body; and

c) shall insert the content of the MIME body;

3) shall insert a final boundary delimiter; and

4) if an SDP offer or an SDP answer is one of the MIME bodies, shall insert the application/sdp MIME body as the first MIME body.

NOTE: The reason for inserting the application/sdp MIME body as the first body is that if a functional entity in the underlying SIP core does not understand multiple MIME bodies, the functional entity will ignore all MIME bodies with the exception of the first MIME body. The order of multiple MCPTT application MIME bodies in a SIP message is irrelevant.

When the MCPTT client or the MCPTT server sends a SIP message and the SIP message contains only one MIME body, the MCPTT client or the MCPTT server:

1) shall include a Content-Type header field set to the MIME type of the MIME body; and

2) shall insert the content of the MIME body.

[TS 24.380, clause 6.2.4.5.3]

Upon receiving an indication from the user to release the permission to send RTP media, the floor participant:

1. shall send a Floor Release message towards the floor control server The Floor Release message:

a. may include the first bit in the subtype of the Floor Release message set to ‘1’ (acknowledgement is required) as specified in subclause 8.2.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

b. if the session is a broadcast call and if the session was established as a normal call, shall include the Floor Indicator with the A-bit set to ‘1’ (Normal call); and

c. if the Floor Granted message included the G-bit set to ‘1’ (Dual floor), shall include the Floor Indicator with the G-bit set to ‘1’ (Dual floor);

2. shall remove the indication that the participant is overriding without revoke if this indication is stored;

3. shall start timer T100 (Floor Release) and initialize counter C100 (Floor Release) to 1; and

4. shall enter the ‘U: pending Release’ state.

[TS 24.380, Clause 6.2.4.6.4]

Upon receiving a Floor Idle message, the floor participant:

1. if the first bit in the subtype of the Floor Idle message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘5’ (Floor Idle); and

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

2. may provide a floor idle notification to the MCPTT user;

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

4. shall stop timer T100 (Floor Release);

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

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

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

b shall enter the ‘Releasing’ state.

[TS 24.380, clause 6.2.4.3.5]

Upon receiving an indication from the user to request permission to send media, the floor participant:

1. shall send the Floor Request message toward the floor control server; The Floor Request message:

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

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

2. shall start timer T101 (Floor Request) and initialise counter C101 (Floor Request) to 1; and

3. shall enter the ‘U: pending Request’ state.

[TS 24.380, clause 6.2.4.4.2]

Upon receiving a Floor Granted message from the floor control server or a floor granted indication in an SIP 200 (OK) response in the application and signalling layer, the floor participant:

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

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

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

2. shall provide floor granted notification to the user, if not already done;

NOTE: Providing the floor granted notification to the user prior to receiving the Floor Granted message is an implementation option.

3. if the Floor 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. if the G-bit in the Floor Indicator is set to ‘1’ (Dual floor) shall store an indication that the participant is overriding without revoke;

5. shall stop the optional timer T103 (End of RTP media), if running;

6. shall stop timer T101 (Floor Request); and

7. shall enter the ‘U: has permission’ state.

[TS 24.380, clause 6.2.4.5.4]

Upon receiving a Floor Revoke message, the floor participant:

1. shall inform the user that the permission to send RTP media is being revoked;

2. may give information to the user about the reason for revoking the permission to send media;

3. shall request the media in the MCPTT client discard any remaining buffered RTP media packets and to stop forwarding of encoded voice to the MCPTT server;

4 if the G-bit in the Floor Indicator is set to ‘1’ (Dual floor):

a. shall send a Floor Release message. In the Floor Release message:

i. shall include the Floor Indicator with the G-bit set to ‘1’ (Dual floor); and

ii. may set the first bit in the subtype to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2;

5 if the G-bit in the Floor Indicator is set to ‘0’ (not Dual floor):

a. shall send a Floor Release message. In the Floor Release message:

i. shall include the Floor Indicator with the G-bit set to ‘0’ (not Dual floor); and

ii. may set the first bit in the subtype to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

6. shall start timer T100 (Floor Release) and initialize counter C100 (Floor Release) to 1; and

7. shall enter the ‘U: pending Release’ state.

[TS 24.380, Clause 6.2.4.6.5]

Upon receiving a Floor Taken message, the floor participant:

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

a. shall include the Message Type field set to ‘2’ (Floor Taken); and

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

2. may provide floor taken notification to the user;

3. if the Floor 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. should start the optional timer T103 (End of RTP media);

5. shall stop timer T100 (Floor Release); and

6. shall enter the ‘U: has no permission’ state.

[TS 24.380, clause 6.2.4.4.4]

Upon receiving a Floor Deny message, the floor participant:

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

a. shall include the Message Type field set to ‘3’ (Floor Deny); and

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

2. shall provide floor deny notification to the user;

3. may display the floor deny reason to the user using information in the Reject Cause field;

4. shall stop timer T101 (Floor Request); and

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

[TS 24.380, clause 6.2.4.4.9]

Upon receiving a Floor Queue Position Info message, the floor participant:

1. if the first bit in the subtype of the Floor Queue Position Info message is set to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message. The Floor Ack message:

a. shall include the Message Type field set to ‘9’ (Floor Queue Position Info); and

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

2. shall provide floor request queued response notification to the MCPTT user;

3. may provide the queue position and priority to the MCPTT user; and

4. shall enter the ‘U: queued’ state.

[TS 24.380, clause 6.2.4.9.9]

Upon receipt of an indication from the MCPTT client to request the queue position, the floor participant:

1. shall send the Floor Queue Position Request message;

2. shall start timer T104 (Floor Queue Position Request) and initialize counter C104 (Floor Queue Position Request) to 1; and

3. remain in the ‘U: queued’ state.

[TS 24.380, clause 6.2.4.9.6]

Upon receiving an indication from the MCPTT user to release the queued floor request, the floor participant:

1. shall send a Floor Release message: The Floor Release message:

a. may include the Floor Indicator field changing a broadcast group call to a normal call;

2. may set the first bit in the subtype of the Floor Release message to ‘1’ (Acknowledgment is required) as described in subclause 8.3.2;

NOTE: It is an implementation option to handle the receipt of the Floor Ack message and what action to take if the Floor Ack message is not received.

3. shall start timer T100 (Floor Release) and initialise counter C10 (Floor Release) to 1;

4. shall stop timer T104 (Floor Queue Position Request), if running; and

5. shall enter the ‘U: pending Release’ state.

[TS 24.380, clause 6.2.4.9.4]

Upon receiving a Floor Granted message, the floor participant:

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

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

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

2. shall provide a floor granted notification to the MCPTT user;

3. if the Floor 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 T104 (Floor Queue Position Request), if running;

5. shall start timer T132 (Queued granted user action);

6. shall indicate the user that the floor is granted; and

7. shall remain in the ‘U: queued’ state.

[TS 24.379, clause 6.2.6]

Upon receiving a SIP BYE request, the MCPTT client:

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

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

[TS 24.379, clause 10.1.1.2.1.3]

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

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

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

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

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

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

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

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

3) if the MCPTT user has requested to upgrade the MCPTT group session to an MCPTT emergency call, the MCPTT client:

a) shall include an application/vnd.3gpp.mcptt-info+xml MIME body populated as specified in subclause 6.2.8.1.1;

b) if an indication of an MCPTT emergency alert is to be included, shall perform the procedures specified in subclause 6.2.9.1 for the MCPTT 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 MCPTT user has requested to upgrade the MCPTT group session to an MCPTT imminent peril call, the MCPTT client:

a) shall include an application/vnd.3gpp.mcptt-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 [4] with the clarifications specified in subclause 6.2.1;

6) if the SIP re-INVITE request is to be sent within a pre-established session, shall include an SDP offer in the SIP re-INVITE request according to 3GPP TS 24.229 [4], based upon the parameters already negotiated for the pre-established session;

NOTE: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session. If the SIP re-INVITE request is sent within a pre-established session, the media-level section for the offered MCPTT speech media stream and the media-level section of the offered media-floor control entity are expected to be the same as was negotiated in the existing pre-established session.

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

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

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

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

2) shall perform the actions specified in subclause 6.2.8.1.4.

[TS 24.379, clause 10.1.1.2.1.4]

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

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

The MCPTT client:

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

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

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

2) shall, if the MCPTT user is cancelling an in-progress emergency condition and optionally an MCPTT emergency alert originated by the MCPTT user, include an application/vnd.3gpp.mcptt-info+xml MIME body populated as specified in subclause 6.2.8.1.3;

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

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

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

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

NOTE 1: The MCPTT ID of the originating MCPTT 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 MCPTT function.

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

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 [4] with the clarifications specified in subclause 6.2.1;

7) if the SIP re-INVITE request is to be sent within a pre-established session, shall include an SDP offer in the SIP re-INVITE request according to 3GPP TS 24.229 [4], based upon the parameters already negotiated for the pre-established session;

NOTE 2: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session. If the SIP re-INVITE request is sent within a pre-established session, the media-level section for the offered MCPTT speech media stream and the media-level section of the offered media-floor control entity are expected to be the same as was negotiated in the existing pre-established session.

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

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

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

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

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

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

4) if the MCPTT emergency alert state is set to "MEA 4: Emergency-alert-cancel-pending", the sent SIP re-INVITE request did not contain an <originated-by> element in the application/vnd.3gpp.mcptt-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 mcptt-warn-code set to "149", shall set the MCPTT emergency alert state to "MEA 1: no-alert".

[TS 24.379, clause 6.2.8.1.3]

This subclause is referenced from other procedures.

If the MCPTT emergency group call state is set to "MEGC 3: emergency-call-granted" and the MCPTT emergency alert state is set to "MEA 1: no-alert", the MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.

NOTE 1: This procedure assumes that the calling procedure has verified that the MCPTT user has made an authorised request for cancelling MCPTT in-progress emergency group state of the group.

The MCPTT client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall clear the MCPTT emergency state; and

3) shall set MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending"

NOTE 2: This is the case of an MCPTT user who has initiated an MCPTT emergency group call and wants to cancel it.

If the MCPTT emergency group call state is set to "MEGC 3: emergency-call-granted" and the MCPTT emergency alert state is set to a value other than "MEA 1: no-alert" and the MCPTT user has indicated only the MCPTT emergency group call should be cancelled, the MCPTT client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false"; and

2) shall set the MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending".

NOTE 3: This is the case of an MCPTT user has initiated both an MCPTT emergency group call and an MCPTT emergency alert and wishes to only cancel the MCPTT emergency group call. This leaves the MCPTT emergency state set.

If the MCPTT emergency group call state is set to "MEGC 3: emergency-call-granted" and the MCPTT emergency alert state is set to a value other than "MEA 1: no-alert" and the MCPTT user has indicated that the MCPTT emergency alert on the MCPTT group should be cancelled in addition to the MCPTT emergency group call, the MCPTT client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";

2) shall if this is an authorised request to cancel an MCPTT emergency alert as determined by the procedures of subclause 6.2.8.1.6:

a) include in the application/vnd.3gpp.mcptt-info+xml MIME body an <alert-ind> element set to "false";

b) set the MCPTT emergency alert state to "MEA 4: Emergency-alert-cancel-pending"; and

c) clear the MCPTT emergency state;

3) should, if this is not an authorised request to cancel an MCPTT emergency alert as determined by the procedures of subclause 6.2.8.1.6, indicate to the MCPTT user that they are not authorised to cancel the MCPTT emergency alert; and

4) shall set the MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending".

NOTE 4: This is the case of an MCPTT user that has initiated both an MCPTT emergency group call and an MCPTT emergency alert and wishes to cancel both.

[TS 24.379, clause 10.1.1.2.1.5]

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

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

The MCPTT client:

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

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

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

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

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

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

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

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

NOTE 1: The MCPTT ID of the originating MCPTT 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 MCPTT function.

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

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

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

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

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

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

[TS 24.379, clause 6.2.8.1.11]

This subclause is referenced from other procedures.

If the MCPTT imminent peril group call state is set to "MIGC 3: imminent-peril-call-granted" or the MCPTT imminent peril group state of the MCPTT group is set to "MIG 2: in-progress", the MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.

NOTE 1: This procedure assumes that the calling procedure has verified that the MCPTT user has made an authorised request for cancelling the in-progress imminent peril group state of the group.

The MCPTT client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <imminentperil-ind> element set to "false"; and

2) shall set MCPTT imminent peril group state of the MCPTT group to "MIG 4: cancel-pending".

NOTE 2: This is the case of an MCPTT user who has initiated an MCPTT imminent peril group call and wants to cancel it, or another authorised member of the group who wishes to cancel the in-progress imminent peril state of the group.

[TS 24.379, clause 6.2.4.1]

Upon receiving a request from an MCPTT user to leave an MCPTT session established using on-demand session signalling, the MCPTT client:

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

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [4];

3) shall set the Request-URI to the MCPTT session identity to leave; and

4) shall send a SIP BYE request towards MCPTT server according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCPTT client shall interact with the media plane as specified in 3GPP TS 24.380 [5].

6.1.1.1.3 Test description

6.1.1.1.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

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

IUT:

– UE (MCPTT 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 MCPTT UE registration as specified in TS 36.579-1 [2], subclause 5.4.2.

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

– UE States at the end of the preamble

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

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

6.1.1.1.3.2 Test procedure sequence

Table 6.1.1.1.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the MCPTT User request the establishment of an MCPTT on-demand pre-arranged group call using Group A, automatic commencement mode, with implicit floor control. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT client) perform procedure for MCPTT CO session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3A.1.3-1 to establish an MCPTT on-demand pre-arranged group call, automatic commencement mode, applying End-to-end communication security with implicit floor control according to option b.i of NOTE 1 in TS 36.579.1 [2] Table 5.3A.1.3-1?	–	–	1	P
3-6	Void	–	–	–	–
7	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	1	P
8	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
9	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	2	P
10a1-11	Void	–	–	–	–
12	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
13	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	2	P
14-16	Void	–	–	–	–
17	The SS overrides the MCPTT Client and grants the floor to a higher priority MCPTT Client.	–	–	–	–
18	The SS sends a Floor Revoke message with the Reject Cause set to #4 – Media Burst pre-empted.	<–	Floor Revoke	–	–
18A	Void	–	–	–	–
–	EXCEPTION: In parallel to the events described in step 19, the step specified in Table 6.1.1.1.3.2-2 takes place.	–	–	–	–
19	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Taken as described in TS 36.579-1 [2] Table 5.3A.16.3-1?	–	–	2	P
20	Void	–	–	–	–
21	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
22	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Deny as described in TS 36.579-1 [2] Table 5.3A.14.3-1?	–	–	2	P
23-24	Void	–	–	–	–
–	EXCEPTION: Steps 25a1 – 25b2 describe behaviour that depends on pc_MCPTT_FloorRequestQueueing parameter “true” or “false”. The “lower case letter” identifies a step sequence that takes place when one or the other is the case	–	–	–	–
25a1	IF pc_MCPTT_FloorRequestQueueing: Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
25a2	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Queue Position Info as described in TS 36.579-1 [2] Table 5.3A.12.3-1?	–	–	11	P
25a3	Check: Does the MCPTT Client provide floor request queued response notification to the MCPTT user? (NOTE 1)	–	–	11	P
25a4	Make the MCPTT User request the current position in the queue. (NOTE 1)	–	–	–	–
25a5	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Queuing Position Request as described in TS 36.579-1 [2] Table 5.3A.13.3-1?	–	–	11	P
25a6	Check: Does the UE (MCPTT Client) provide floor queue position information to the MCPTT user? (NOTE 1)	–	–	11	P
25a7	Make the MCPTT User request to cancel the Floor Request and end being in the queue (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
25a8	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Taken as described in TS 36.579-1 [2] Table 5.3A.16.3-1 to cancel the queue position?	–	–	11	P
25a9	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
25a10	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Queue Position Info as described in TS 36.579-1 [2] Table 5.3A.12.3-1?	–	–	11	P
25a11	Check: Does the UE (MCPTT Client) provide floor request queued response notification to the MCPTT user? (NOTE 1)	–	–	11	P
25a12	The SS sends a Floor Granted message with no acknowledgement required	<–	Floor Granted	–	–
25a13	Check: Does the UE (MCPTT Client) provide a floor granted notification to the MCPTT user? (NOTE 1)	–	–	11	P
25b1	ELSE IF NOT pc_MCPTT_FloorRequestQueueing: Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
25b2	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	2	P
26-40	Void	–	–	–	–
41	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
42	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	2	P
43a1-44	Void	–	–	–	–
45	Check: Is the procedure for MCX CT call release as described in TS 36.579-1 [2] Table 5.3.12.3-1 correctly performed?	–	–	3	P
46	Void	–	–	–	–
47	Make the MCPTT User request the establishment of an MCPTT on-demand pre-arranged group call, automatic commencement mode, with implicit floor control. (NOTE 1)	–	–	–	–
48	Check: Does the UE (MCPTT client) perform procedure for MCPTT CO session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3A.1.3-1 to establish an MCPTT on-demand pre-arranged group call, automatic commencement mode, with implicit floor control according to option b.i of NOTE 1 in TS 36.579.1 [2] Table 5.3A.1.3-1?	–	–	1	P
49-52	Void	–	–	–	–
53	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	–	–
54	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
55	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	2	P
56a1-58	Void	–	–	–	–
59	Make the MCPTT User request upgrade of the ongoing On-Demand Pre-arranged Group Call to MCPTT Emergency Group Call with implicit floor control. (NOTE 1)	–	–	–	–
60	Check: Does the UE (MCPTT client) perform procedure for MCPTT CO session modification as described in TS 36.579-1 [2] Table 5.3A.6.3-1 to upgrade the call to an emergency call with implicit floor control?	–	–	4, 5	P
61-61C	Void	–	–	–	–
61D	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	5	P
62	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
63	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	5	P
64a1-65	Void	–	–	–	–
66	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
67	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	5	P
68-70	Void	–	–	–	–
71	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
72	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	5	P
73a1-74	Void	–	–	–	–
75	Make the MCPTT User cancel the Emergency State. (NOTE 1)	–	–	–	–
76	Check: Does the UE (MCPTT client) perform procedure for MCPTT CO session modification as described in TS 36.579-1 [2] Table 5.3A.6.3-1 to cancel the emergency state without implicit floor control?	–	–	5,6	P
77	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
77A	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	5	–
77B-D	Void	–	–	–	–
78	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
79	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	5	P
80a1-81	Void	–	–	–	–
82	Make the MCPTT User request upgrade of the ongoing On-Demand Pre-arranged Group Call to MCPTT Imminent Peril Group Call with explicit request for floor control (implicit floor control). (NOTE 1)	–	–	–	–
83	Check: Does the UE (MCPTT client) perform procedure for MCPTT CO session modification described in TS 36.579-1 [2] Table 5.3A.6.3-1 to upgrade the call to an imminent peril call with implicit floor control?	–	–	7, 8	P
84-84C	Void	–	–	–	–
84D	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	8	P
85	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
86	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	8	P
87a1-88	Void	.-	.-	–	–
89	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
90	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	8	P
91-93	Void	–	–	–	–
94	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
95	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	8	P
96a1-97	Void	–	–	–	–
98	Make the MCPTT User cancel the Imminent Peril State. (NOTE 1)	–	–	–	–
99	Check: Does the UE (MCPTT client) perform procedure for MCPTT CO session modification described in TS 36.579-1 [2] Table 5.3A.6.3-1 to cancel the imminent peril state without implicit floor control?	–	–	8, 9	P
100	Make the MCPTT User request to speak (e.g. pressing the PTT button). (NOTE 1)	–	–	–	–
100A	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	8	P
100B-D	Void	–	–	–	–
101	Make the MCPTT User indicate end of talking (e.g. releasing the PTT button). (NOTE 1)	–	–	–	–
102	Check: Does the UE (MCPTT client) perform procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	8	P
103a1-104	Void	–	–	–	–
105	Make the MCPTT User end the on-demand group call. (NOTE 1)	–	–	–	–
106	Check: Does the UE (MCPTT client) perform procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the on-demand group call?	–	–	10	P
107	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

Table 6.1.1.1.3.2-2: Parallel Behaviour

Procedure

Message Sequence

Verdict

U – S

Message

Check: Does the UE (MCPTT Client) inform the MCPTT User that the permission to send RTP media is being revoked?

NOTE 1 in Table 6.1.1.1.3.2-1

–

6.1.1.1.3.3 Specific message contents

Table 6.1.1.1.3.3-1: SIP INVITE from the UE (steps 2, 48, Table 6.1.1.1.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3A.1.3-1)

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

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

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

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

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

Table 6.1.1.1.3.3-3: Void

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

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

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

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

Table 6.1.1.1.3.3-4: Void

Table 6.1.1.1.3.3-4A: SIP BYE from the SS (step 45, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3.12.3-1)

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

Table 6.1.1.1.3.3-5: SIP INVITE from the UE (step 60, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.6.3-1)

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

Table 6.1.1.1.3.3-6: Void

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

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

Table 6.1.1.1.3.3-6B: MCPTT-Info in SIP INVITE (Tables 6.1.1.1.3.3-5)

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

Table 6.1.1.1.3.3-7: Void

Table 6.1.1.1.3.3-7B: SIP 200 (OK) from the SS (steps 60, 83 Table 6.1.1.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.6.3-1)

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

Table 6.1.1.1.3.3-7C: SDP in SIP 200 (OK) (Table 6.1.1.1.3.3-7B)

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

Table 6.1.1.1.3.3-8: SIP INVITE from the UE (step 76 Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.6.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1 condition re_INVITE
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.1.1.1.3.3-8A
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.1.1.1.3.3-9

Table 6.1.1.1.3.3-8A: SDP in SIP INVITE (Tables 6.1.1.1.3.3-8)

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

Table 6.1.1.1.3.3-9: MCPTT-Info in SIP INVITE (Table 6.1.1.1.3.3-8)

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

Table 6.1.1.1.3.3-9A: SIP 200 (OK) from the SS (steps 76, 99 Table 6.1.1.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.6.3-1)

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

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

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

Table 6.1.1.1.3.3-10: SIP INVITE from the UE (step 83, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.6.3-1)

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

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

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

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

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

Table 6.1.1.1.3.3-12: SIP-INVITE from the UE (step 99, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.6.3-1)

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

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

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

Table 6.1.1.1.3.3-14: Void

Table 6.1.1.1.3.3-15: Floor Request (step 67, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.11.3-1)

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

Table 6.1.1.1.3.3-16: Floor Request (step 90, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.11.3-1)

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

Table 6.1.1.1.3.3-17..18: Void

Table 6.1.1.1.3.3-19: Floor Release (steps 63, 72, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.15.3-1)

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

Table 6.1.1.1.3.3-20: Floor Release (steps 86, 95, Table 6.1.1.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.15.3-1)

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

Table 6.1.1.1.3.3-21: Void

Table 6.1.1.1.3.3-22: Floor Idle (steps 63, 72, Table 6.1.1.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.15.3-1)

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

Table 6.1.1.1.3.3-23: Floor Idle (steps 86, 95, Table 6.1.1.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.15.3-1)

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

Table 6.1.1.1.3.3-24: Void

Table 6.1.1.1.3.3-25: Floor Granted (step 60, 67, Table 6.1.1.1.3.2-1;
step 5a1, TS 36.579-1 [2] Table 5.3A.6.3-1; step 2, TS 36.579-1 [2] Table 5.3A.11.3-1)

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

Table 6.1.1.1.3.3-26: Floor Granted (step 83, 90, Table 6.1.1.1.3.2-1;
step 5, TS 36.579-1 [2] Table 5.3A.6.3-1; step 2, TS 36.579-1 [2] Table 5.3A.11.3-1)

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

Table 6.1.1.1.3.3-27..29: Void

Table 6.1.1.1.3.3-30: Floor Deny (step 22, Table 6.1.1.1.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3A.14.3-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.4-1
Information Element	Value/remark	Comment	Condition
Reject Cause
Reject Cause	"255"	Cause #255 – Other reason
Reject Phrase	"Other reason"

Table 6.1.1.1.3.3-31..32: Void

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

6.1.1.2.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT }

ensure that {
when { the SS (MCPTT Server) initiates an On-demand Pre-arranged group call with Automatic Commencement Mode and implicit floor control }

then { UE (MCPTT Client) responds by sending a SIP 200 (OK) message and after indication from the MCPTT Server that the call was established notifies the user }

}

(2)

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

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server (Floor Request during a talk burst, Floor granting/release, Floor idle, Floor deny, Floor taken/revoked) }

}

(3)

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

ensure that {

when { the MCPTT User (MCPTT Client) wants to terminate the ongoing MCPTT Group Call }

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

}

(4)

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

ensure that {

when { the SS (MCPTT Server) upgrades the ongoing MCPTT Group Call to an MCPTT Emergency Group Call with floor control }

then { UE (MCPTT 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 (emergency group call state = "MEGC 3: emergency-call-granted") }

}

(5)

with { UE (MCPTT Client) in an upgraded Emergency Group Call }

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server }

}

(6)

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

ensure that {

when { the SS (MCPTT Server) cancels the ongoing MCPTT Emergency state }

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

}

(7)

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

ensure that {

when { the SS (MCPTT Server) upgrades the ongoing MCPTT Group Call to an MCPTT Imminent Peril Group Call with floor control }

then { UE (MCPTT Client) responds to the SIP re-INVITE request with a SIP 200 (OK) response and considers the call as being upgraded to an cImminent Peril Group Call (imminent peril group call state = "MIG 2: in-progress") }

}

(8)

with { UE (MCPTT Client) in an upgraded Imminent Peril Group Call }

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server }

}

(9)

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

ensure that {

when { the SS (MCPTT Server) cancels the ongoing MCPTT Imminent Peril state }

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

}

(10)

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

ensure that {

when { the SS (MCPTT Server) needs to terminate the ongoing MCPTT Group Call }

then { the SS (MCPTT Server) sends a SIP BYE request and the UE (MCPTT Client) responds with a SIP 200 (OK) and leaves the MCPTT session }

}

(11)

with { UE (MCPTT Client) having established an MCPTT On-demand Pre-arranged Group Call with Automatic Commencement Mode and pc_MCPTT_FloorRequestQueueing = “true” }

ensure that {

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

then { UE (MCPTT Client) respects the floor control queue handling imposed by the MCPTT Server (Floor request queued, Floor queue position request and Floor queue position info) }

}

6.1.1.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.379 clauses 10.1.1.2.1.2, 6.2.2, 6.2.3.1.2, 6.2.6, 10.1.1.2.1.6, 6.2.5.1, 10.1.1.2.3.1, 10.1.1.2.3.3 and TS 24.380, clauses 6.2.4.5.3, 6.2.4.3.5, 6.2.4.4.2, 6.2.4.5.4, 6.2.4.4.4, 6.2.4.4.9, 6.2.4.9.9, 6.2.4.9.6, 6.2.4.9.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-13 requirements.

[TS 24.379, clause 10.1.1.2.1.2]

In the procedures in this subclause:

1) emergency indication in an incoming SIP INVITE request refers to the <emergency-ind> element of the application/vnd.3gpp.mcptt-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.mcptt-info+xml MIME body.

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

The MCPTT client:

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

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

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

and skip the rest of the steps;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[TS 24.379, clause 6.2.2]

When the MCPTT client receives an initial SDP offer for an MCPTT session, the MCPTT client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [4].

When composing an SDP answer, the MCPTT client:

1) shall accept the MCPTT speech media stream in the SDP offer;

2) shall set the IP address of the MCPTT client for the accepted MCPTT speech media stream and, if included in the SDP offer, for the accepted media-floor control entity;

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

3) shall include an "m=audio" media-level section for the accepted MCPTT speech media stream consisting of:

a) the port number for the media stream;

b) media-level attributes as specified in 3GPP TS 24.229 [4]; and

c) "i=" field set to "speech" according to 3GPP TS 24.229 [4]; and

4) if included in the SDP offer, shall include the media-level section of the offered media-floor control entity consisting of:

a) an "m=application" media-level section as specified in 3GPP TS 24.380 [5] clause 12; and

b) ‘fmtp’ attributes as specified in 3GPP TS 24.380 [5] clause 14.

[TS 24.379, clause 6.2.3.1.2]

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

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

[TS 24.379, clause 6.2.6]

Upon receiving a SIP BYE request, the MCPTT client:

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

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

[TS 24.379, clause 10.1.1.2.1.6]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7) shall include the g.3gpp.mcptt 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.mcptt" 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 [4] with the clarifications given in subclause 6.2.2;

10) if the SIP re-INVITE request was received within a pre-established 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 [4], based upon the parameters already negotiated for the pre-established session;

NOTE: The SIP re-INVITE request can be received within an on-demand session or a pre-established session. If the SIP re-INVITE request is received within a pre-established session, the media-level section for the MCPTT speech media stream and the media-level section of the media-floor control entity are expected to be the same as was negotiated in the existing pre-established session.

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

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

[TS 24.379, clause 6.2.5.1]

When the MCPTT client wants to release an MCPTT session established using on-demand session signalling, the MCPTT client:

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

2) shall generate a SIP BYE request according to 3GPP TS 24.229 [4];

3) shall set the Request-URI to the MCPTT session identity to release; and

4) shall send a SIP BYE request towards MCPTT server according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCPTT client shall interact with the media plane as specified in 3GPP TS 24.380 [5].

[TS 24.379, clause 10.1.1.2.3.1]

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

[TS 24.379, clause 10.1.1.2.3.3]

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