6.2 Private Calls

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.2.1 On-network / Private Call / On-demand / Automatic Commencement Mode / With Floor Control / Upgrade to Emergency Call / Cancellation of Emergency on User request / Client Originated (CO)

6.2.1.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to initiate/cancel private and private emergency calls with automatic commencement }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, applying End-to-end communication security with Floor Control }

then { UE (MCPTT Client) sends a SIP INVITE message requesting private call on-demand Automatic Commencement Mode, applying End-to-end communication security, and offering a media-level section for a media-floor control entity, and, after indication from the MCPTT Server that the call was established notifies the user }

}

(2)

with { UE (MCPTT Client) having established an MCPTT private call, on-demand Automatic Commencement Mode with Floor Control }

ensure that {

when { the MCPTT User engages in communication with the invited MCPTT User }

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server (Floor granting/release/deny) applying Floor Control confidentiality and integrity protection }

}

(3)

with { UE (MCPTT Client) having established an MCPTT private call, on-demand Automatic Commencement Mode with Floor Control }

ensure that {

when { the MCPTT User wants to upgrade the ongoing MCPTT private call to an MCPTT emergency private call with floor control }

then { UE (MCPTT Client) sends a SIP re-INVITE message requesting private emergency call on-demand Automatic Commencement Mode offering a media-level section for a media-floor control entity, and, upon receipt of a SIP 200 (OK) response considers the call as being upgraded to emergency private call (emergency private call state = "MEPC 3: emergency-pc-granted") }

}

(4)

with { UE (MCPTT Client) having upgraded an MCPTT private call, on-demand Automatic Commencement Mode with Floor Control to emergency private call with floor control }

ensure that {

when { the MCPTT User engages in communication with the invited MCPTT User }

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server including override of the invited MCPTT user (who is not in MCPTT emergency state) and applying Floor Control confidentiality and integrity protection }

}

(5)

with { UE (MCPTT Client) having upgraded an MCPTT private call, on-demand Automatic Commencement Mode with Floor Control to emergency private call with floor control }

ensure that {

when { the MCPTT User wants to cancel the ongoing MCPTT emergency private call }

then { UE (MCPTT Client) sends a SIP re-INVITE request requesting the emergency state cancellation, and. upon receipt of a SIP 200 (OK) response considers the emergency condition cancelled and the call being reverted back to MCPTT Private Call }

}

(6)

with { UE (MCPTT Client) having an ongoing MCPTT private call, on-demand Automatic Commencement Mode with Floor Control }

ensure that {

when { the MCPTT User wants to terminate the ongoing MCPTT private call }

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

}

6.2.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 4.6.2, 4.7, 6.2.1, 6.2.5.1, 6.2.8.3.4, 6.2.8.3.6, 11.1.1.2.1.1, 11.1.1.2.1.4, 11.1.1.2.1.5, 11.1.3.1.1.1, TS 24.380 clauses 4.1.1.2, 5.2.1, 5.2.2, 12.1.2.2, 13.1, 13.3.3, TS 33.180, clause 5.3.4. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379, clause 4.6.2]

Key aspects of MCPTT emergency private calls include:

– adjusted EPS bearer priority for both participants whether or not they are both in an emergency condition (i.e. both have their MCPTT emergency state set). This is achieved by using the Resource-Priority header field as specified in IETF RFC 4412 [29] with namespaces defined for use by MCPTT specified in draft-holmberg-dispatch-mcptt-rp-namespace [48];

– the initiator of the MCPTT emergency private call can override the other MCPTT user in the MCPTT emergency private call unless that user also has their MCPTT emergency state set;

…

– restoration of normal floor control priority participants when the emergency elevated priority is cancelled;

– requires the MCPTT user to be authorised to either originate or cancel an MCPTT emergency private call;

…

– the originator of the MCPTT emergency private call can request that the call use either manual or automatic commencement mode.

[TS 24.379, clause 4.7]

If a mission critical organisation requires MCPTT users to communicate using end-to-end security, a security context needs to be established between the initiator of the call and the recipient(s) of the call, prior to the establishment of media, or floor control signalling. This provides assurance to MCPTT users that no unauthorised access to communications is taking place within the MCPTT network. An MCPTT key management server (KMS) manages the security domain. For any end-point to use or access end-to-end secure communications, it needs to be provisioned with keying material associated to its identity by the KMS as specified in 3GPP TS 33.179 [46].

…

For private calls, the security context is initiated at call setup. An end-to-end security context is established that is unique to the pair of users involved in the call. The procedure involves transferral of an encapsulated private call key (PCK) and private call key id (PCK-ID) from the initiator to the terminator. The PCK is encrypted using the terminator’s MCPTT ID and domain-specific material provided from the KMS. The PCK and PCK-ID are distributed within a MIKEY payload within the SDP offer of the private call request. This payload is called a MIKEY-SAKKE I_MESSAGE, as defined in IETF RFC 6509 [75], which ensures the confidentiality, integrity and authenticity of the payload. The encoding of the MIKEY payload in the SDP offer is described in IETF RFC 4567 [47] using an "a=key-mgmt" attribute. The payload is signed using a key associated to the identity of the initiating user. At the terminating side, the signature is validated. If valid, the UE extracts and decrypts the encapsulated PCK. The MCPTT UE also extracts the PCK-ID. This process is described in 3GPP TS 33.179 [46]. With the PCK successfully shared between the two MCPTT UEs, the UEs are able to use SRTP/SRTCP to create an end-to-end secure session.

End-to-end security is independent of the transmission path and hence is applicable to both on and off-network communications. With a security context established, the group call key and private call key can be used to encrypt media and, if required, floor control traffic between the end-points as described in 3GPP TS 24.380 [5] clause 13.

[TS 33.179, clause 5.3.4]

End-to-end communication security for either group or private calls requires the provisioning of key material from the KMS. The key material provisioned to each user is listed below:

– A KMSInit Response contains the Home KMS Certificate (domain specific key material associated to the KMS), and may contain:

– An updated TrK for the user (to replace the offline-provisioned, bootstrap TrK).

– A KMSKeyProv Response contains zero, or more, KMSKeySets and may contain:

– An updated TrK for the user (to replace existing TrK).

– A KMSCertCache Response may contain:

– Home KMS Certificate(s) (current, updated or future).

– External KMS Certificates. This is domain specific key material associated with other KMSs. It is required to enable secure communications across security domains.

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

…

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

On receiving a SIP 2xx response to a SIP request for an MCPTT emergency private call and if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted", the MCPTT client:

1) shall set the MCPTT emergency private priority state of the call to "MEPP 2: in-progress" if it was not already set;

2) shall set the MCPTT emergency private call state to "MEPC 3: emergency-pc-granted"; and

[TS 24.379, clause 6.2.8.3.6]

When the MCPTT emergency private call state is set to "MEPC 3: emergency-pc-granted" and the MCPTT emergency alert state is set to "MPEA 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 MCPTT client in the calling procedure has verified that the MCPTT user has made an authorised request for cancelling MCPTT the in-progress emergency private call state of the 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 clear the MCPTT emergency state; and

3) shall set MCPTT emergency private priority state of the MCPTT emergency private call to "MEPP 3: cancel-pending".

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

[TS 24.379, clause 11.1.1.2.1.1]

Upon receiving a request from an MCPTT user to establish an MCPTT private call 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) shall set the Request-URI of the SIP INVITE request to a public service identity of the participating MCPTT function serving the MCPTT user;

…

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

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 media feature tag g.3gpp.icsi-ref contain with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

8) shall insert in the SIP INVITE request a MIME resource-lists body with the MCPTT ID of the invited MCPTT user, according to rules and procedures of IETF RFC 5366 [20];

9) if an end-to-end security context needs to be established then:

a) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.179 [46];

b) shall use the keying material to generate a PCK as described in 3GPP TS 33.179 [46];

c) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.179 [46];

d) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID of the invited user and a time related parameter as described in 3GPP TS 33.179 [46];

e) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.179 [46]; and

g) shall add the MCPTT ID of the originating MCPTT to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.179 [46]; and

f) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCPTT user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.179 [46].

10) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarification given in subclause 6.2.1 and with a media stream of the offered media-floor control entity;

11) if implicit floor control is required, shall comply with the conditions specified in subclause 6.4;

…13) if force of automatic commencement mode at the invited MCPTT client is not requested by the MCPTT user and:

a) if automatic commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include in the SIP INVITE request an Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [18]; and

…

14) shall contain an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <session-type> element set to a value of "private";

…

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

Upon receiving a SIP 183(Session Progress) response to the SIP INVITE request the MCPTT client:

1) may indicate the progress of the session establishment to the inviting MCPTT user.

Upon receiving a SIP 200 (OK) response to the SIP INVITE request the MCPTT client:

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

…

3) shall notify the user that the call has been successfully established.

[TS 24.379, clause 11.1.1.2.1.4]

Upon receiving a request from an MCPTT user to cancel the in-progress emergency condition on an MCPTT emergency private call, the MCPTT client shall generate a SIP re-INVITE request by following the UE 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 condition on an MCPTT emergency private call as determined by the procedures of subclause 6.2.8.3.1.2, the MCPTT client:

a) should indicate to the MCPTT user that they are not authorised to cancel the in-progress emergency condition on an MCPTT emergency private call; 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.3.6;

…

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

5) shall include in the SIP re-INVITE request an SDP offer the media parameters as currently established;

NOTE 1: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session associated with an MCPTT group 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.

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

7) shall send the SIP re-INVITE request according to 3GPP TS 24.229 [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 private priority state of the MCPTT private call to "MEPP 1: no-emergency";

3) shall set the MCPTT emergency private call state of the call to "MEPC 1: emergency-pc-capable"; and

[TS 24.379, clause 11.1.1.2.1.5]

Upon receiving a request from an MCPTT user to upgrade the ongoing MCPTT private call to an MCPTT emergency private call, the MCPTT client shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [4], with the clarifications given below.

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

2) shall include a Resource-Priority header field and comply with the procedures in subclause 6.2.8.3.3.

3) shall include an SDP offer with the media parameters as currently established according to 3GPP TS 24.229 [4];

NOTE: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session associated with an MCPTT private call. 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.

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

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

[TS 24.379, clause 11.1.3.1.1.1]

Upon receiving a request from an MCPTT user to release an MCPTT private call session established using on-demand session signalling, the MCPTT client shall follow the procedures as specified in subclause 6.2.5.1.

[TS 24.380, clause 4.1.1.2]

At any point in time a group member can request permission to talk.

When all group members are silent, a group member can press the PTT button, meaning the request for permission to talk. The floor participant entity of this user reflects this request to the floor control server by sending a Floor Request message. If the floor control server decides to permit, it informs this permission for this request by sending a Floor Granted message to the requesting group member. The floor control server informs the initiation of the talk to the other group members by sending a Floor Taken message. Once the group member receives the permission, a permission indication (permission tone) is generated and the user can talk. The media packets (encoded voice) are sent to the controlling MCPTT server and from there they are distributed to all listeners of this group. The release of the PTT button indicates the user’s intension to end talking. Once the PTT button is released, the floor participant sends a Floor Release message to the floor control server indicating that this user has finished talking. This cycle, starting from the Floor Granted message and ending with Floor Release message, is known as ‘talk burst’ or ‘media burst’.

In the beginning of a call the initial talk permission request can be implied by the SIP message which initiates the call as specified in 3GPP TS 24.379 [2] without any specific Floor Request message.

A group member can also request for permission to talk by sending a Floor Request message during a talk burst. The floor control server can resolve this request in several ways.

1. If this request has higher priority than the ongoing talk burst, the floor control server revokes the current talk burst by sending a Floor Revoke message to the current talker. The current talker is interrupted and the current media burst is ended by the current floor participant by sending a Floor Release message. Then the floor control server sends a Floor Granted message to the revoking user and send Floor Taken message to other group members. Then a new media burst starts.

2. If this request does not have higher priority and floor request queuing is not used the floor control server rejects this request by sending a Floor Deny message to the requester. Then a reject indication (reject tone) is generated for the user. The ongoing talk burst continues.

…

During silence (when no talk burst is ongoing), the floor control server can send Floor Idle message to all floor participants from time to time. The floor control server sends Floor Idle message in the beginning of silence.

[TS 24.380, clause 5.2.1]

To be compliant with the procedures in the present document, an MCPTT client shall:

1. support the role of an MCPTT client as specified 3GPP TS 23.179 [5];

2. support the on-network MCPTT client role as specified in 3GPP TS 24.379 [2];

…

4. support media plane security as specified in clause 13.

To be compliant with the on-network procedures in the present document, an MCPTT client shall:

1. provide the role of a floor participant in on-network mode as specified in subclause 5.2.2;

2. provide the media mixer function as described in subclause 4.2.2 and support the related procedures in subclause 6.2;

…

4. provide PTT button events towards the on-network floor participant as specified in subclause 6.2;

5. provide means (sound, display, etc.) for indications towards the MCPTT user as specified in subclause 6.2;

6. support negotiating media plane control channel media level attributes as specified in subclause 4.3; and

[TS 24.380, clause 5.2.2]

To be compliant with the on-network procedures in the present document, a floor participant in on-network mode shall:

1. support the on-network floor control procedures as defined in 3GPP TS 23.179 [5];

2. support acting as an on-network floor participant as specified in subclause 6.2; and

3. support the on-network mode floor control protocol elements as specified in the clause 8.

A floor participant in on-network mode may:

1. support queuing of floor requests as specified in subclause 6.2 and subclause 4.1.1.2.

[TS 24.380, clause 12.1.2.2]

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

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

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

NOTE 2: When the "mc_granted" fmtp attribute is used in an SDP offer, it does not indicate an actual request for the floor. The SDP "mc_implicit_request" fmtp attribute can be used to request the floor. In an SDP answer, the attribute indicates that the floor has been granted to the offeror.

NOTE 3: Once the offeror has been granted the floor, the offeror has the floor until it receives a Floor Revoke message, or until the offeror itself releases the floor by sending a Floor Release message, as described in the present specification.

In an SDP offer, the "mc_implicit_request" fmtp attribute indicates that the offeror implicitly requests the floor (without the need to send a Floor Request message). In an SDP answer, the attribute parameter indicates that the answerer has accepted the implicit floor request. Once the answerer grants the floor to the offeror, the answerer will send a Floor Granted message.

NOTE 4: The usage of the "mc_implicit_request" fmtp attribute in an SDP answer does not mean that the answerer has granted the floor to the offeror, only that the answerer has accepted the implicit floor request.

[TS 24.380, clause 13.1]

Media plane security provides integrity and confidentiality protection of individual media streams and media plane control messages in MCPTT sessions.

The media plane security is based on 3GPP MCPTT security solution including key management and end-to-end media and floor control messages protection as defined in 3GPP TS 33.179 [14].

Various keys and associated key identifiers protect:

1. RTP transported media;

2. RTCP transported media control messages (i.e. RTCP SR packets, RTCP RR packets, RTCP SDES packets);

3. RTCP APP transported floor control messages;

…

In an on-network private call:

1. if protection of media is negotiated, the PCK and the PCK-ID protect media sent and received by the MCPTT clients;

2. if protection of floor control messages sent using unicast between the MCPTT client and the participating MCPTT function serving the MCPTT client is negotiated, the CSK and the CSK-ID protect the floor control messages sent and received by the MCPTT client and by the participating MCPTT function;

…

4. if protection of media control messages sent using unicast between the MCPTT client and the participating MCPTT function serving the MCPTT client is negotiated, the CSK and the CSK-ID protect the media control messages sent and received using unicast by the MCPTT client and by a participating MCPTT function; and

…

The CSK and the CSK-ID are generated by the MCPTT client and provided to the participating MCPTT function serving the MCPTT client using SIP signalling according to 3GPP TS 24.379 [2].

The PCK and the PCK-ID are generated by the MCPTT client initiating the private call and provided to the MCPTT client receiving the private call using SIP signalling according to 3GPP TS 24.379 [2], using Connect message described in subclause 8.3.4 or using MONP signalling according to 3GPP TS 24.379 [2].

[TS 24.380, clause 13.3.3]

3. in an on-network private call:

A) if:

i) protection of media is negotiated in originating call and the PCK and the PCK-ID were sent to the remote MCPTT client using SIP signalling according to 3GPP TS 24.379 [2]; or

…

then:

i) shall encrypt sent media according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the PCK and PCK-ID as specified in subclause 13.2; and

ii) shall decrypt received media according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the PCK and PCK-ID as specified in subclause 13.2;

B) if protection of floor control messages is negotiated and the CSK and the CSK-ID were sent to the participating MCPTT function using SIP signalling according to 3GPP TS 24.379 [2]:

i) shall encrypt sent floor control messages according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2; and

ii) shall decrypt received floor control messages according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2; and

D) if protection of media control messages sent using unicast between the participating MCPTT function and the MCPTT client is negotiated and the CSK and the CSK-ID were sent to the participating MCPTT function using SIP signalling according to 3GPP TS 24.379 [2]:

i) shall encrypt media control messages sent using unicast according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2; and

ii) shall decrypt media control messages received using unicast according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the CSK and CSK-ID as specified in subclause 13.2;

6.2.1.3 Test description

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

Table 6.2.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the UE (MCPTT User) request the establishment of an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, applying End-to-end communication security with Floor Control. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT client) perform the procedure for MCPTT CO session establishment/modification as described in TS 36.579-1 [2] Table 5.3A.1.3-1 to establish an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, applying End-to-end communication security with Floor Control? Option b.ii of NOTE 1 in TS 36.579.1 [2] Table 5.3A.1.3-1 is applied.	–	–	1, 2	P
3-5	Void	–	–	–	–
5A	Check: Does the UE (MCPTT client) provide floor granted notification to the MCPTT User? (NOTE 1)	–	–	1	P
6	Make the UE (MCPTT User) release the floor. (NOTE 1)	–	–	–	–
7	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Release – Floor Taken as described in TS 36.579-1 [2] Table 5.3A.16.3-1?	–	–	2	P
8-9	Void	–	–	–	–
10	Make the UE (MCPTT User) request the floor. (NOTE 1)	–	–	–	–
11	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Request – Floor Deny as described in TS 36.579-1 [2] Table 5.3A.14.3-1?	–	–	2	P
12	Void	–	–	–	–
13	Make the UE (MCPTT User) release the floor. (NOTE 1)	–	–	–	–
14	The SS (MCPTT server) sends a Floor Idle message.	<–	Floor Idle	–	–
15	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
16	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	2	P
17	Void	–	–	–	–
18	Make the UE (MCPTT User) release the floor. (NOTE 1)	–	–	–	–
18A	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
19	Make the UE (MCPTT User) request upgrade of the ongoing private call to MCPTT emergency private call. (NOTE 1).	–	–	–	–
20	Check: Does the UE (MCPTT client) perform the 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 MCPTT private emergency call with implicit Floor Control?	–	–	3, 4	P
21-22	Void	–	–	–	–
22A	The UE (MCPTT client) provides floor granted notification to the MCPTT User. (NOTE 1)	–	–	–	–
23	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
24	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Release – Floor Taken as described in TS 36.579-1 [2] Table 5.3A.16.3-1?	–	–	4	P
25-26	Void	–	–	–	–
27	Make the UE (MCPTT User) request the floor. (NOTE 1):	–	–	–	–
28	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	4	P
29	Void	–	–	–	–
30	Make the UE (MCPTT User) release the floor. (NOTE 1)	–	–	–	–
31	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	4	P
32	Void	–	–	–	–
33	Make the UE (MCPTT User) request cancelling of MCPTT emergency private call. (NOTE 1)	–	–	–	–
34	Check: Does the UE (MCPTT client) perform the procedure for MCPTT CO session modification as described in TS 36.579-1 [2] Table 5.3A.6.3-1 to cancel the private emergency call without implicit Floor Control?	–	–	5	P
34A	The SS (MCPTT server) sends a Floor Idle message.	<–	Floor Idle	–	–
35-36	Void	–	–	–	–
36A	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
36B	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Request – Floor Granted as described in TS 36.579-1 [2] Table 5.3A.11.3-1?	–	–	2	P
37	Make the UE (MCPTT User) release the PTT button indicating end of talking. (NOTE 1)	–	–	–	–
38	Check: Does the UE (MCPTT client) perform the procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	2	P
39	Void	–	–	–	–
40	Make the UE (MCPTT User) request termination of the MCPTT private call. (NOTE 1)	–	–	–	–
41	Check: Does the UE (MCPTT Client) perform the procedure for MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1 to end the private call?	–	–	5	P
42-43	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI

6.2.1.3.3 Specific message contents

Table 6.2.1.3.3-1: SIP INVITE from the UE (Step 2, Table 6.2.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, condition PRIVATE-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.2.1.3.3-1B
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.2.1.3.3-1C

Table 6.2.1.3.3-1A: Void

Table 6.2.1.3.3-1B: SDP in SIP INVITE (Tables 6.2.1.3.3-1)

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

Table 6.2.1.3.3-1C: MCPTT-Info in SIP INVITE (Tables 6.2.1.3.3-1)

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

Table 6.2.1.3.3-1D: SIP 200 (OK) from the SS (steps 2 Table 6.2.1.3.3-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.2.1.3.3-1E

Table 6.2.1.3.3-1E: SDP in SIP 200 (OK) (Table 6.2.1.3.3-1D)

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

Table 6.2.1.3.3-2: SIP INVITE from the UE (Step 20, Table 6.2.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, PRIVATE-CALL, EMERGENCY-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.2.1.3.3-2A
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.2.1.3.3-3

Table 6.2.1.3.3-2A: SDP in SIP INVITE (Tables 6.2.1.3.3-2)

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

Table 6.2.1.3.3-3: MCPTT-Info in SIP INVITE (Table 6.2.1.3.3-2)

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

Table 6.2.1.3.3-3A: SIP 200 (OK) from the SS (steps 20 Table 6.2.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.2.1.3.3-3B

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

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

Table 6.2.1.3.3-4: SIP INVITE from the UE (Step 34, Table 6.2.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, PRIVATE-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.2.1.3.3-2A
MIME body part		MCPTT Info
MIME part body	MCPTT-Info as described in Table 6.2.1.3.3-5

Table 6.2.1.3.3-4A: SDP in SIP INVITE (Tables 6.2.1.3.3-4)

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

Table 6.2.1.3.3-5: MCPTT-Info in SIP INVITE (Table 6.2.1.3.3-4)

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

Table 6.2.1.3.3-5A: SIP 200 (OK) from the SS (steps 34 Table 6.2.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.2.1.3.3-5B

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

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

Table 6.2.1.3.3-6..12: Void

Table 6.2.1.3.3-13: Floor Request (Steps 28, Table 6.2.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 conditionEMERGENCY_CALL.

Table 6.2.1.3.3-14: Floor Granted (Steps 20, 28, Table 6.2.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 conditionEMERGENCY_CALL

Table 6.2.1.3.3-15: Floor Release (Steps 24, 31, Table 6.2.1.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.16.3-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 conditionEMERGENCY_CALL

Table 6.2.1.3.3-16: Floor Taken (Step 24, Table 6.2.1.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.16.3-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 conditionEMERGENCY_CALL

Table 6.2.1.3.3-17: Floor Idle (Step 31, Table 6.2.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

6.2.2 On-network / Private Call / On-demand / Automatic Commencement Mode / With Floor Control / Upgrade to Emergency Call / Cancellation of Emergency on User request / Client Terminated (CT)

6.2.2.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to receive private and private emergency calls with automatic commencement }

ensure that {

when { the UE (MCPTT Client) receives a request for establishment of an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, applying End-to-end communication security with Floor Control }

then { UE (MCPTT Client) sends a SIP 200 (OK) accepting the establishment of an MCPTT private call, on-demand Automatic Commencement Mode applying End-to-end communication security with Floor Control, and, notifies the user for the call establishment }

(2)

with { UE (MCPTT Client) having established an On-demand Automatic Commencement Mode Private Call with Floor Control }

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server (Floor granting/release/deny) applying Floor Control confidentiality and integrity protection }

}

(3)

with { UE (MCPTT Client) having established an MCPTT private call, on-demand Automatic Commencement Mode with Floor Control }

ensure that {

when { the MCPTT User (MCPTT Client) receives a request for upgrade of the ongoing MCPTT private call to an MCPTT emergency private call with floor control }

then { UE (MCPTT Client) accepts the request and upon sending SIP 200 (OK) message considers the call as being upgraded to emergency private call (emergency private call state = "MEPC 3: emergency-pc-granted") }

}

(4)

with { UE (MCPTT Client) having upgraded an On-demand Automatic Commencement Mode Private Call to emergency private call }

ensure that {

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

then { UE (MCPTT Client) respects the floor control imposed by the MCPTT Server including being able to handle override requested by the inviting MCPTT user and applying Floor Control confidentiality and integrity protection }

}

(5)

with { UE (MCPTT Client) having upgraded an On-demand Automatic Commencement Mode Private Call to an Emergency Private Call }

ensure that {

when { the MCPTT User (MCPTT Client) receives a request to cancel the ongoing MCPTT emergency private call }

then { UE (MCPTT Client) accepts the request and after sending a SIP 200 (OK) response considers the emergency condition cancelled and the call being reverted back to MCPTT Private Call }

}

(6)

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

ensure that {

when { the MCPTT User (MCPTT Client) receives a request for termination of the ongoing MCPTT private call }

then { UE (MCPTT Client) accept the request and after sending a SIP 200 (OK) response leaves the MCPTT session }

}

6.2.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 4.6.2, 4.7, 6.2.2, 6.2.3.1.1, 6.2.6, 11.1.1.2.1.2, 11.1.1.2.1.3, 11.1.3.1.1.2, TS 24.380 clauses 4.1.1.2, 5.2.1, 5.2.2, 12.1.2.2, 13.1, 13.3.3, TS 33.180, clause 5.3.4. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379, clause 4.6.2]

Key aspects of MCPTT emergency private calls include:

– the initiator of the MCPTT emergency private call can override the other MCPTT user in the MCPTT emergency private call unless that user also has their MCPTT emergency state set;

…

– restoration of normal floor control priority participants when the emergency elevated priority is cancelled;

…

– requires the targeted MCPTT user to be authorised to receive an MCPTT emergency private call;

[TS 24.379, clause 4.7]

…

[TS 33.180, clause 5.3.4]

End-to-end communication security for either group or private calls requires the provisioning of key material from the KMS. The key material provisioned to each user is listed below:

– A KMSInit Response contains the Home KMS Certificate (domain specific key material associated to the KMS), and may contain:

– An updated TrK for the user (to replace the offline-provisioned, bootstrap TrK).

– A KMSKeyProv Response contains zero, or more, KMSKeySets and may contain:

– An updated TrK for the user (to replace existing TrK).

– A KMSCertCache Response may contain:

– Home KMS Certificate(s) (current, updated or future).

– External KMS Certificates. This is domain specific key material associated with other KMSs. It is required to enable secure communications across security domains.

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

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

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

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

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

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

5) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [7]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";

…

7) shall, if the incoming SIP INVITE request does not contain a Replaces header field, include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [4] with the clarifications given in subclause 6.2.2;

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

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

…

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

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

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

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:

…

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

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

…

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

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

a) shall extract the MCPTT ID of the originating MCPTT from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.179 [46];

b) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.179 [46];

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

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

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

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

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

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

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

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.1 if one of the following conditions are met:

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

[TS 24.379, clause 11.1.1.2.1.3]

Upon receipt of a SIP re-INVITE request for an existing private call session, the MCPTT client shall:

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 an indication that this is a SIP re-INVITE request to upgrade this call to an MCPTT emergency private call and:

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

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

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

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 <emergency-ind> element set to a value of "false":

a) should display to the MCPTT user an indication that this is a SIP re-INVITE request to downgrade this emergency private call to a normal priority private call and:

i) should display the MCPTT ID of the sender of the SIP re-INVITE request contained in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

b) shall set the MCPTT emergency private priority state to "MEPP 1: no-emergency" for this private call; and

c) if the MCPTT emergency private call state of the call is set to "MEPC 3: emergency-call-granted", shall set the MCPTT emergency private call state of the call to "MEPC 1: emergency-pc-capable";

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

4) may display to the MCPTT user the MCPTT ID of the inviting MCPTT user if not done so in step 1 or step 2 above;

NOTE 1: As this is a re-INVITE for an existing MCPTT private call session, there is no attempt made to change the answer-mode from its current state.

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

6) 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 INVITE request according to 3GPP TS 24.229 [4] with the clarifications given in subclause 6.2.2;

…

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

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

[TS 24.379, clause 11.1.3.1.1.2]

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

[TS 24.380, clause 4.1.1.2]

At any point in time a group member can request permission to talk.

A group member can also request for permission to talk by sending a Floor Request message during a talk burst. The floor control server can resolve this request in several ways.

…

[TS 24.380, clause 5.2.1]

To be compliant with the procedures in the present document, an MCPTT client shall:

1. support the role of an MCPTT client as specified 3GPP TS 23.179 [5];

2. support the on-network MCPTT client role as specified in 3GPP TS 24.379 [2];

…

4. support media plane security as specified in clause 13.

To be compliant with the on-network procedures in the present document, an MCPTT client shall:

1. provide the role of a floor participant in on-network mode as specified in subclause 5.2.2;

2. provide the media mixer function as described in subclause 4.2.2 and support the related procedures in subclause 6.2;

…

4. provide PTT button events towards the on-network floor participant as specified in subclause 6.2;

5. provide means (sound, display, etc.) for indications towards the MCPTT user as specified in subclause 6.2;

6. support negotiating media plane control channel media level attributes as specified in subclause 4.3; and

[TS 24.380, clause 5.2.2]

To be compliant with the on-network procedures in the present document, a floor participant in on-network mode shall:

1. support the on-network floor control procedures as defined in 3GPP TS 23.179 [5];

2. support acting as an on-network floor participant as specified in subclause 6.2; and

3. support the on-network mode floor control protocol elements as specified in the clause 8.

A floor participant in on-network mode may:

1. support queuing of floor requests as specified in subclause 6.2 and subclause 4.1.1.2.

[TS 24.380, clause 12.1.2.2]

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

[TS 24.380, clause 13.1]

Media plane security provides integrity and confidentiality protection of individual media streams and media plane control messages in MCPTT sessions.

The media plane security is based on 3GPP MCPTT security solution including key management and end-to-end media and floor control messages protection as defined in 3GPP TS 33.179 [14].

Various keys and associated key identifiers protect:

1. RTP transported media;

2. RTCP transported media control messages (i.e. RTCP SR packets, RTCP RR packets, RTCP SDES packets);

3. RTCP APP transported floor control messages;

…

In an on-network private call:

1. if protection of media is negotiated, the PCK and the PCK-ID protect media sent and received by the MCPTT clients;

…

The CSK and the CSK-ID are generated by the MCPTT client and provided to the participating MCPTT function serving the MCPTT client using SIP signalling according to 3GPP TS 24.379 [2].

[TS 24.380, clause 13.3.3]

3. in an on-network private call:

A) if:

…

ii) protection of media is negotiated in terminating call and the PCK and the PCK-ID were received from the remote MCPTT client using SIP signalling according to 3GPP TS 24.379 [2];

then:

i) shall encrypt sent media according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the PCK and PCK-ID as specified in subclause 13.2; and

ii) shall decrypt received media according to IETF RFC 3711 [16] and 3GPP TS 33.179 [14] using SRTP-MK, SRTP-MS and SRTP-MKI generated using the PCK and PCK-ID as specified in subclause 13.2;

B) if protection of floor control messages is negotiated and the CSK and the CSK-ID were sent to the participating MCPTT function using SIP signalling according to 3GPP TS 24.379 [2]:

6.2.2.3 Test description

6.2.2.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

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

Table 6.2.2.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to establish an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, applying End-to-end communication security with Floor Control correctly performed?	–	–	1	P
2-3	Void	–	–	–	–
4	SS (MCPTT server) sends a Floor Taken message.	<–	Floor Taken	–	–
5	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
6	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
7	Void			–	–
8	SS (MCPTT server) sends a Floor Idle message.	<–	Floor Idle	–	–
9	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
10	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
11	Void	–	–	–	–
12	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
13	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
14-15	Void	–	–	–	–
16	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to upgrade to an MCPTT private emergency call on-demand Automatic Commencement Mode offering a media-level section for a media-floor control entity correctly performed?	–	–	3	P
17	Void	–	–	–	–
–	EXCEPTION: Step 18a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE displays information to the User upon accepting establishment/releasing of Emergency call.	–	–	–	–
18a1	IF pc_MCX_DisplayInfoEmergencyCall THEN Check: Does the UE (MCPTT client) notify the user about the upgrade of the private call to an emergency private call? (NOTE 1) NOTE 2: The display information may include – indication for upgrade of the private call to an emergency private call – the MCPTT ID of the sender of the SIP re-INVITE request.	–	–	3	P
19	SS (MCPTT server) sends a Floor Taken message.	<–	Floor Taken	–	–
20	Void	–	–	–	–
21	SS (MCPTT server) sends a Floor Idle message.	<–	Floor Idle	–	–
22	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
23	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?	–	–	4	P
24	Void	–	–	–	–
25	SS (MCPTT server) sends a Floor Revoke message.	<–	Floor Revoke	–	–
26	Void	–	–	–	–
–	EXCEPTION: In parallel to the events described in step 27, the step specified in Table 6.2.2.3.2-2 takes place.	–	–	–	–
27	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?	–	–	4	P
28-30	Void	.	–	–	–
31	SS (MCPTT server) sends a Floor Idle message.	<–	Floor Idle	–	–
32	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
33	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?	–	–	4	P
34	Void	–	–	–	–
35	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to cancel the emergency call correctly performed?	–	–	5	P
36	Void	–	–	–	–
–	EXCEPTION: Step 37a1 describes behaviour that depends on the UE implementation; the "lower case letter" identifies a step sequence that take place if the UE displays information to the User upon accepting establishment/releasing of Emergency call.	–	–	–	–
37a1	IF pc_MCX_DisplayInfoEmergencyCall THEN Check: Does the UE (MCPTT client) notify the user about the downgrade of the emergency private call to a normal priority private call? (NOTE 1) (NOTE 2)	–	–	5	P
38-39	Void	–	–	–	–
39A	Make the UE (MCPTT User) release the floor (NOTE 1)	–	–	–	–
39B	Check: Does the UE (MCPTT client) correctly perform Generic Test Procedure for MCPTT Floor Release – Floor Idle as described in TS 36.579-1 [2] Table 5.3A.15.3-1?	–	–	2	P
39C	Make the UE (MCPTT User) request the floor (NOTE 1)	–	–	–	–
40	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
41	Check: Is the procedure for MCX CT call release as described in TS 36.579-1 [2] Table 5.3.12.3-1 to end the call correctly performed?	–	–	6	P
42	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI. NOTE 2: The display information may include – indication for downgrade of the emergency private call to a normal priority private call – the MCPTT ID of the sender of the SIP re-INVITE request.

Table 6.2.2.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.2.2.3.2-1)

–

6.2.2.3.3 Specific message contents

Table 6.2.2.3.3-1: SIP INVITE from the SS (Step 1, Table 6.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation path: TS 36.579-1 [2], table 5.5.2.5.2-1
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.2.2.3.3-1A
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.2.2.3.3-1B

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

Derivation Path: TS 36.579-1 [2], 5.5.3.1.2-1 condition INITIAL_SDP_OFFER, PRIVATE-CALL

Table 6.2.2.3.3-1B: MCPTT-Info in SIP INVITE (Table 6.2.2.3.3-1)

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

Table 6.2.2.3.3-2: SIP INVITE from the SS (Step 16, Table 6.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], table 5.5.2.5.2-1, condition re_INVITE
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.2.2.3.3-2A
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.2.2.3.3-3

Table 6.2.2.3.3-2A: SDP in SIP INVITE (Table 6.2.2.3.3-2)

Derivation Path: TS 36.579-1 [2], 5.5.3.1.2-1 condition SDP_OFFER, PRIVATE-CALL

Table 6.2.2.3.3-3: MCPTT-Info in SIP INVITE (Table 6.2.2.3.3-2)

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

Table 6.2.2.3.3-4: SIP INVITE from the SS (Step 35, Table 6.2.2.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], table 5.5.2.5.2-1 condition re_INVITE
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.2.2.3.3-2A
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.2.2.3.3-5

Table 6.2.2.3.3-5: MCPTT-Info in SIP INVITE (Table 6.2.2.3.3-4)

Derivation Path: TS 36.579-1 [2], table 5.5.3.2.2-1, condition PRIVATE-CALL
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
emergency-ind	"false"
alert-ind	"false"

Table 6.2.2.3.3-5A: SIP 200 (OK) from the UE (Steps 1, 16, 35, Table 6.2.2.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1 condition INVITE-RSP
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME part body	SDP Message as described in Table 6.2.2.3.3-5B
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.2.2.3.3-5C

Table 6.2.2.3.3-5B: SDP in SIP 200 (OK) (Table 6.2.2.3.3-5A)

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

Table 6.2.2.3.3-5C: MCPTT-Info in SIP 200 (OK) (Table 6.2.2.3.3-5A)

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

Table 6.2.2.3.3-6..12: Void

Table 6.2.2.3.3-13: Floor Request (Steps 23, 33, Table 6.2.2.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 conditionEMERGENCY_CALL.

Table 6.2.2.3.3-14: Floor Granted (Steps 23, 33, Table 6.2.2.3.2-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 conditionEMERGENCY_CALL.

Table 6.2.2.3.3-15: Floor Release (Steps 27, Table 6.2.2.3.2-1;
step 1, TS 36.579-1 [2] Table 5.3A.16.3-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 conditionEMERGENCY_CALL

Table 6.2.2.3.3-16: Floor Taken (Steps 19, 27, Table 6.2.2.3.2-1;
step 3, TS 36.579-1 [2] Table 5.3A.16.3-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 conditionEMERGENCY_CALL

Table 6.2.2.3.3-17: Floor Revoke (Step 25, Table 6.2.2.3.2-1)

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

Table 6.2.2.3.3-18: Floor Idle (Step 21, 31, Table 6.2.2.3.2-1)

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

6.2.3 On-network / Private Call / On-demand / Automatic Commencement Mode / Without Floor Control / Client Originated (CO)

6.2.3.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to initiate/cancel private calls with automatic commencement }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, without floor control }

then { UE (MCPTT Client) sends a SIP INVITE message requesting on-demand Automatic Commencement Mode and not offering a media-level section for a media-floor control entity, and, after indication from the MCPTT Server that the call was established notifies the user }

}

(2)

with { UE (MCPTT Client) having an ongoing On-demand Automatic Commencement Mode Private Call without Floor control }

ensure that {

when { the MCPTT User wants to terminate the ongoing MCPTT private call }

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

}

6.2.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 6.2.1, 6.2.5.1, 11.1.1.2.1.1, 11.1.2.2, 11.1.3.1.1.1. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379, clause 6.2.1]

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;

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

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

The MCPTT client:

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

…

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

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

8) shall insert in the SIP INVITE request a MIME resource-lists body with the MCPTT ID of the invited MCPTT user, according to rules and procedures of IETF RFC 5366 [20];

…

13) if force of automatic commencement mode at the invited MCPTT client is not requested by the MCPTT user and:

…

14) shall contain an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <session-type> element set to a value of "private";

…

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

Upon receiving a SIP 183(Session Progress) response to the SIP INVITE request the MCPTT client:

1) may indicate the progress of the session establishment to the inviting MCPTT user.

Upon receiving a SIP 200 (OK) response to the SIP INVITE request the MCPTT client:

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

…

3) shall notify the user that the call has been successfully established.

[TS 24.379, clause 11.1.2.2]

When the MCPTT user wants to make an on-demand private call without floor control, the MCPTT client shall follow the procedures in subclause 11.1.1.2.1.1 with the following exceptions:

1) in step 10) of subclause 11.1.1.2.1.1, the MCPTT client shall not offer a media-level section for a media-floor control entity; and

2) step 11) of subclause 11.1.1.2.1.1 shall be ignored.

[TS 24.379, clause 11.1.3.1.1.1]

6.2.3.3 Test description

6.2.3.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

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

Table 6.2.3.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the UE (MCPTT User) request the establishment of an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, without Floor Control. (NOTE 1)	–	–	–	–
2	Check: Does the UE (MCPTT client) perform the 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 private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, without Floor Control according to option a of NOTE 1 in TS 36.579.1 [2] Table 5.3A.1.3-1?	–	–	1	P
3-4	Void	–	–	–	–
5	Check: Does the UE (MCPTT client) notify the user that the call has been successfully established? (NOTE 1)	–	–	1	P
6-7	Void	–	–	–	–
8	Make the UE (MCPTT User) request termination of the MCPTT private call. (NOTE 1)	–	–	–	–
9	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 private call?	–	–	2	P
10-11	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI.

6.2.3.3.3 Specific message contents

Table 6.2.3.3.3-1: SIP INVITE from the UE (Step 2, Table 6.2.3.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, condition PRIVATE-CALL
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 6.2.3.3.3-2
MIME body part		MCPTT Info
MIME-part-body	MCPTT-Info as described in Table 6.2.3.3.3-2A

Table 6.2.3.3.3-2: SDP Message in SIP INVITE (Table 6.2.3.3.3-1)

Derivation Path: TS 36.579-1 [2], table 5.5.3.1.1-1, condition PRIVATE-CALL, INITIAL_SDP_OFFER, WITHOUT_FLOORCONTROL

Table 6.2.3.3.3-2A: MCPTT-Info in SIP INVITE (Tables 6.2.3.3.3-1)

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

Table 6.2.3.3.3-3: SIP 200 (OK) from the SS (Step 2, Table 6.2.3.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.2.3.3.3-4

Table 6.2.3.3.3-4: SDP Message in SIP 200 (OK) (Table 6.2.3.3.3-3)

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

Table 6.2.3.3.3-5: Void

6.2.4 On-network / Private Call / On-demand / Automatic Commencement Mode / Without Floor Control / Client Terminated (CT)

6.2.4.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to receive private and private emergency calls with automatic commencement }

ensure that {

when { the UE (MCPTT Client) receives a request for establishment of an MCPTT private call, on-demand Automatic Commencement Mode, no Force of automatic commencement, without Floor Control }

then { UE (MCPTT Client) sends a SIP 200 (OK) accepting the establishment of an MCPTT private call, on-demand Automatic Commencement Mode and not offering a media-level section for a media-floor control entity }

(2)

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

ensure that {

when { the MCPTT User (MCPTT Client) receives a request for termination of the ongoing MCPTT private call }

then { UE (MCPTT Client) accept the request and after sending a SIP 200 (OK) response leaves the MCPTT session }

}

6.2.4.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 6.2.2, 6.2.3.1.1, 6.2.6, 11.1.1.2.1.2, 11.1.2.2, 11.1.3.1.1.2. Unless otherwise stated these are Rel-13 requirements.

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

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

[TS 24.379, clause 6.2.3.1.1]

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

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

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

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

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

…

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

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

Upon receipt of an initial SIP INVITE request for the private call with an SDP offer not including a media-level section for a media-floor control entity, the MCPTT client shall consider it as the request for private call without floor control and shall follow the procedures as specified in subclause 11.1.1.2.1.2 for on-demand session and subclause 11.1.1.2.2.2 for pre-established session.

[TS 24.379, clause 11.1.1.2.1.2]

The MCPTT client:

…

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

a) shall extract the MCPTT ID of the originating MCPTT from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.179 [46];

b) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.179 [46];

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

…

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

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

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

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

…

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

[TS 24.379, clause 11.1.3.1.1.2]

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

6.2.4.3 Test description

6.2.4.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT server)

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

Table 6.2.4.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Is the procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to establish MCPTT private call, on-demand Automatic Commencement, no Force of automatic commencement, without Floor Control correctly performed?	–	–	1	P
2-4	Void	–	–	–	–
5	Check: Is the procedure for MCX CT call release as described in TS 36.579-1 [2] Table 5.3.12.3-1 to end the private call correctly performed?	–	–	2	P
6-7	Void	–	–	–	–
NOTE 1: This is expected to be done via a suitable implementation dependent MMI

6.2.4.3.3 Specific message contents

Table 6.2.4.3.3-1: SIP INVITE from the SS (Step 1, Table 6.2.4.3.2-1;
step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

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

Table 6.2.4.3.3-2: SDP Message in SIP INVITE (Table 6.2.4.3.3-1)

Derivation Path: TS 36.579-1 [2], table 5.5.3.1.2-1, condition PRIVATE-CALL, INITIAL_SDP_OFFER, WITHOUT_FLOORCONTROL

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

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

Table 6.2.4.3.3-3: SIP 200 (OK) from the UE (Step 1, Table 6.2.4.3.2-1;
step 4, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], table 5.5.2.17.1.1-1 condition INVITE-RSP,
Information Element	Value/remark	Comment	Reference	Condition
Message-body
MIME body part		SDP Message
MIME-part-body	SDP Message as described in Table 6.2.4.3.3-4
MIME body part		MCPTT Info
MIME part body	MCPTT Info as described in Table 6.2.4.3.3-6

Table 6.2.4.3.3-4: SDP Message in SIP 200 (OK) (Table 6.2.4.3.3-3)

Derivation Path: TS 36.579-1 [2], table 5.5.3.1.1-1 condition SDP_ANSWER, WITHOUT_FLOORCONTROL

Table 6.2.4.3.3-5: Void

Table 6.2.4.3.3-6: MCPTT-Info in SIP 200 (OK) (Table 6.2.4.3.3-3)

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

6.2.5 On-network / Private Call / Emergency Private Call / On-demand / Automatic Commencement Mode / Force of automatic commencement mode / Without Floor Control / Client Originated (CO)

6.2.5.1 Test Purpose (TP)

(1)

with { UE (MCPTT Client) registered and authorised for MCPTT Service including authorization to initiate and cancel emergency calls }

ensure that {

when { the MCPTT User requests the establishment of an MCPTT private emergency call, on-demand, automatic commencement mode, Force of automatic commencement mode without floor control }

then { UE (MCPTT Client) requests Private Emergency Call establishment without floor control by sending a SIP INVITE message including a Priv-Answer-Mode header field with the value "Auto" not offering a media-level section for a media-floor control entity, and, after indication from the MCPTT Server that the call was established notifies the user}

}

(2)

with { UE (MCPTT Client) having established an Emergency Private Call }

ensure that {

when { the MCPTT User wants to terminate the ongoing MCPTT emergency private call }

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

}

6.2.5.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 6.2.1, 6.2.5.1, 6.2.8.3.2, 6.2.8.3.3, 6.2.8.3.4, 6.2.8.3.6, 11.1.1.2.1.1, 11.1.2.2, 11.1.3.1.1.1. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379, clause 6.2.1]

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;

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:

…

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

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

When the MCPTT emergency private call state is set to "MEPC 1: emergency-pc-capable" and this is an authorised request for an MCPTT emergency private call as determined by the procedures of subclause 6.2.8.3.1.1, the MCPTT client:

1) shall set the MCPTT emergency state if not already set;

2) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP request an <emergency-ind> element set to "true" and set the MCPTT emergency private call state to "MEPC 2: emergency-pc-requested";

3) if the MCPTT user has also requested an MCPTT emergency alert to be sent and this is an authorised request for MCPTT emergency alert as determined by the procedures of subclause 6.2.8.3.1.3, shall:

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

b) include in the SIP request the specific location information for MCPTT emergency alert as specified in subclause 6.2.9.1;

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

5) if the MCPTT emergency private priority state of this private call is set to a value other than "MEPP 2: in-progress" shall set the MCPTT emergency private priority state to "MEPP 4: confirm-pending".

[TS 24.379, clause 6.2.8.3.3]

If the MCPTT emergency private call state is set to either "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted" and this is an authorised request for an MCPTT emergency private call as determined by the procedures of subclause 6.2.8.3.1.1, or the MCPTT emergency private priority state of the call is set to "MEPP 2: in-progress", the MCPTT client shall include in the SIP request a Resource-Priority header field populated with the values for an MCPTT emergency private call as specified in subclause 6.2.8.1.15.

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

[TS 24.379, clause 6.2.8.3.4]

1) shall set the MCPTT emergency private priority state of the call to "MEPP 2: in-progress" if it was not already set;

2) shall set the MCPTT emergency private call state to "MEPC 3: emergency-pc-granted"; and

[TS 24.379, clause 6.2.8.3.6]

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 private priority state of the MCPTT emergency private call to "MEPP 3: cancel-pending".

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

[TS 24.379, clause 11.1.1.2.1.1]

The MCPTT client:

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

2) if the MCPTT user has requested the origination of an MCPTT emergency private call or is originating an MCPTT private call and the MCPTT emergency state is already set, the MCPTT client:

a) shall, if this is an authorised request for an MCPTT emergency private call as determined by the procedures of subclause 6.2.8.3.1.1, comply with the procedures in subclause 6.2.8.3.2; and

b) should, if this is an unauthorised request for an MCPTT emergency private call as determined in step a) above, indicate to the MCPTT user that they are not authorised to initiate an MCPTT emergency private call;