7 MCPTT Server – MCPTT Server operation

36.579-33GPPMission Critical (MC) services over LTEPart 3: Mission Critical Push To Talk (MCPTT) Server Application conformance specificationRelease 13TS

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

7.1 MCPTT Server – MCPTT Server / On-demand Pre-arranged Group Call / Automatic Commencement Mode / Floor Control / Controlling Server

7.1.1 Test Purpose (TP)

(1)

with { IUT (MCPTT Server) connected to SS (MCPTT Server) }

ensure that {

when { the SS-UE2 (MCPTT client) initiates a pre-arranged group call with automatic commencement mode }

then { IUT (MCPTT Server) interacts with SS (MCPTT Server) to set up the call by sending SIP messages }

}

(2)

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

ensure that {

when { the SS-UE1 (MCPTT client) and SS-UE2 (MCPTT client) engage in communication }

then { IUT (MCPTT Server) enforces floor control (Floor Taken, Floor Idle, Floor Granted ) by sending messages via the SS (MCPTT Server) }

}

(3)

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

ensure that {

when { the SS-UE1 (MCPTT client) ends the pre-arranged group call }

then { IUT (MCPTT Server) responds via the SS (MCPTT Server) by sending a SIP 200 (OK) message to the client ending the call and sends a SIP BYE message to the other participants }

}

7.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 6.3.3.2.3.1, 6.3.3.2.2, 10.1.1.4.2, 6.3.3.1.2, 6.3.3.3, 10.1.1.4.1.2, 6.3.3.2.3.2, 10.1.1.4.1.1, 6.3.3.2.4, 6.3.3.1.5, TS 24.380 clause 6.3.2.2, 6.3.5.2.2, 6.3.5.3.3, 6.3.5.5.3, 6.3.5.5.4, 6.3.5.3.5, 6.3.5.4.4. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379 clause 6.3.3.2.3.1]

When sending SIP provisional responses with the exception of the SIP 100 (Trying) response to the SIP INVITE request the controlling MCPTT function:

1) shall generate the SIP provisional response;

2) shall include a P-Asserted-Identity header field with the public service identity of the controlling MCPTT function;

3) shall include an MCPTT session identity in the Contact header field; and

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

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

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

c) the isfocus media feature tag.

[TS 24.379 clause 6.3.3.2.2]

On receipt of an initial SIP INVITE request the controlling MCPTT function shall cache SIP feature tags, if received in the Contact header field and if the specific feature tags are supported.

[TS 24.379 clause 10.1.1.4.2]

In the procedures in this subclause:

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

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

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

4) indication of required group members in a SIP 183 (Session Progress) response refers to the <required> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to "true" in a SIP 183 (Session Progress) sent by the non-controlling MCPTT function of an MCPTT group;

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

6) 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 a "SIP INVITE request for controlling MCPTT function of an MCPTT group", the controlling MCPTT function:

…

2) shall determine if the media parameters are acceptable and the MCPTT speech codec is offered in the SDP offer and if not reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

…

5) shall retrieve the necessary group document(s) from the group management server for the group identity contained in the SIP INVITE request and carry out initial processing as specified in subclause 6.3.5.2;

…

7) shall perform the actions as described in subclause 6.3.3.2.2;

8) shall maintain a local counter of the number of SIP 200 (OK) responses received from invited members and shall initialise this local counter to zero;

9) shall determine if an MCPTT group call for the group identity is already ongoing by determining if an MCPTT session identity has already been allocated for the group call and the MCPTT session is active;

…

13) if the MCPTT group call is not ongoing then:

a) if:

i) the user identified by the MCPTT ID is not affiliated to the group identity contained in the SIP INVITE request as specified in subclause 6.3.6;

ii) the group identity contained in the SIP INVITE request is not a constituent MCPTT group ID;

iii) the received SIP INVITE request does not contain an emergency indication or imminent peril indication; or

iv) the received SIP INVITE request is an authorised request for an MCPTT emergency group call as determined by subclause 6.3.3.1.13.2 or MCPTT imminent peril group call as determined by steps subclause 6.3.3.1.13.5 and is determined to not be eligible for implicit affiliation as specified in subclause 9.2.2.3.6;

then shall return a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in subclause 4.4, and skip the rest of the steps below;

…

e) shall create a prearranged group session and allocate an MCPTT session identity for the prearranged group call, and shall handle timer TNG3 (group call timer) as specified in subclause 6.3.3.5;

…

g) if the group identity in the SIP INVITE request for controlling MCPTT function of an MCPTT group is an MCPTT group ID:

i) shall determine the members to invite to the prearranged MCPTT group call as specified in subclause 6.3.5.5;

ii) if necessary, shall start timer TNG1 (acknowledged call setup timer) according to the conditions stated in subclause 6.3.3.3;

…

v) shall invite each group member determined in step 13)g)i) above, to the group session, as specified in subclause 10.1.1.4.1.1; and

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

…

Upon receiving a SIP 183 (Session Progress) response to the SIP INVITE request specified in subclause 10.1.1.4.1 containing a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [34], the timer TNG1 (acknowledged call setup timer) is not running, the controlling MCPTT function supports media buffering and the SIP final response is not yet sent to the inviting MCPTT client:

1) shall generate a SIP 200 (OK) response to SIP INVITE request as specified in the subclause 6.3.3.2.3.2;

…

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

4) shall include a P-Answer-State header field with the value "Unconfirmed";

…

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

NOTE 7: Resulting user plane processing is completed before the next step is performed.

8) shall send the SIP 200 (OK) response towards the inviting MCPTT client according to 3GPP TS 24.229 [4];

…

Upon:

1) receiving a SIP 200 (OK) response for a SIP INVITE request as specified in subclause 10.1.1.4.1;

2) the timer TNG1 (acknowledged call setup timer) is not running;

3) the local counter of the number of SIP 200 (OK) responses received from invited members is equal to the value of the <on-network-minimum-number-to-start> element of the group document;

4) the controlling MCPTT function supports media buffering; and

5) the SIP final response has not yet been sent to the inviting MCPTT client;

the controlling MCPTT function according to local policy:

1) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the subclause 6.3.3.2.2;

…

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

…

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

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

7) shall send a SIP 200 (OK) response to the inviting MCPTT client according to 3GPP TS 24.229 [4];

[TS 24.379 clause 6.3.3.1.2]

This subclause is referenced from other procedures.

The controlling MCPTT function shall generate an initial SIP INVITE request according to 3GPP TS 24.229 [4].

The controlling MCPTT function:

1) shall include in the Contact header field an MCPTT session identity for the MCPTT session with the g.3gpp.mcptt media feature tag, the isfocus media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" according to IETF RFC 3840 [16];

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

3) 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-Asserted-Service-Id header field according to IETF RFC 6050 [9] in the SIP INVITE request;

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

5) shall include a Referred-By header field with the public user identity of the inviting MCPTT client;

6) should include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [7]. The refresher parameter shall be omitted;

7) shall include the Supported header field set to "timer";

8) shall include an unmodified Priv-Answer-Mode header field if present in the incoming SIP INVITE request;

9) if a Priv-Answer-Mode header field was not present in the incoming SIP INVITE request, shall include an unmodified Answer-Mode header field if present in the incoming SIP INVITE request; and

10) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing INVITE request.

[TS 24.379 clause 6.3.3.3]

When the controlling MCPTT function receives a SIP INVITE request to initiate a group session and there are members of the group document retrieved from the group management server that are affiliated and are marked as <on-network-required> as specified in 3GPP TS 24.381 [31], then the controlling MCPTT function shall start timer TNG1 (acknowledged call setup timer) with a timer value as described in Annex B.2.1, prior to sending out SIP INVITE requests inviting group members to the group session.

When the controlling MCPTT function receives all SIP 200 (OK) responses to the SIP INVITE requests, from all affiliated and <on-network-required> members then the controlling MCPTT function shall stop timer TNG1 (acknowledged call setup timer) and if the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the value of the <on-network-minimum-number-to-start> element of the group document, the controlling MCPTT function shall send a SIP 200 (OK) response to the initiating MCPTT client.

NOTE 1: MCPTT clients that are affiliated but are not <on-network-required> members that have not yet responded will be considered as joining an ongoing session when the controlling MCPTT function receives SIP 200 (OK) responses from these MCPTT clients.

[TS 24.379 clause 10.1.1.4.1.2]

The controlling MCPTT function:

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

2) shall set the Request-URI to the public service identity of the non-controlling MCPTT function serving the group identity of the MCPTT group owned by the partner MCPTT system;

3) shall set the P-Asserted-Identity to the public service identity of the controlling MCPTT function;

4) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP INVITE request:

a) the <mcptt-request-uri> element set to the group identity of the MCPTT group hosted by the non-controlling MCPTT function in the partner MCPTT system; and

b) the <mcptt-calling-group-id> element set to the group identity of the group served by the controlling MCPTT function;

5) shall include the Recv-Info header field set to g.3gpp.mcptt-floor-request;

6) if:

a) an MCPTT GKTP document exists for the group identity contained in the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request; and

b) the MCPTT GKTP document contains a <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCPTT GKTP document:

i) shall perform the procedure in subclause 6.3.3.6.2 to re-generate an I_MESSAGE; and

ii) if the procedure in subclause 6.3.3.6.2 was successful, shall include the I_MESSAGE in a <GKTP> element of the <MKFC-GKTPs> element of an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP INVITE request;

7) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in subclause 6.3.3.1.1; and

8) shall send the SIP INVITE request towards the partner MCPTT system in accordance with 3GPP TS 24.229 [4].

Upon receiving SIP 403 (Forbidden) response for the SIP INVITE request, if according to local policy and if:

1) the response contains a Warning header field with the MCPTT warning code "128"; and

2) the response contains a P-Refused-URI-List header field and an application/resource-lists+xml MIME body as specified in IETF RFC 5318 [36];

NOTE 1: The application/resource-lists+xml MIME body contains MCPTT IDs identifying MCPTT users in a partner MCPTT system that needs to be invited to the prearranged group call in case of group regrouping using interrogating method as specified in 3GPP TS 23.179 [3] subclause 10.6.2.4.2.

then the controlling MCPTT function:

1) shall check if the number of members of the MCPTT group exceeds the value contained in the <on-network-max-participant-count> element of the group document as specified in 3GPP TS 24.381 [31]. If exceeded, the controlling MCPTT function shall invite only <on-network-max-participant-count> members from the application/resource-lists+xml MIME body; and

NOTE 2: The <on-network-max-participant-count> element indicates the maximum number of participants allowed in the prearranged group session It is operator policy that determines which participants in the application/resource-lists+xml MIME body are invited to the group call.

2) shall invite MCPTT users as specified in this subclause using the list of MCPTT IDs in URI-List.

Upon receiving a SIP 200 (OK) response for the SIP INVITE request the controlling MCPTT function:

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

NOTE 3: The procedures executed by the controlling MCPTT function prior to sending a response to the inviting MCPTT client are specified in subclause 10.1.1.4.2.

2) if at least one of the invited MCPTT clients has subscribed to the conference package, shall subscribe to the conference event package in the non-controlling MCPTT function as specified in subclause 10.1.3.4.3; and

3) if the 200 (OK) response includes the <floor-state> element set to "floor-taken", shall wait for a SIP INFO request containing a floor request from the non-controlling MCPTT function.

Upon receiving a SIP INFO request containing a floor request where:

1) the Request-URI contains an MCPTT session ID identifying an ongoing temporary group session; and

2) the application/vnd.3gpp.mcptt-info+xml MIME body contains the <mcptt-calling-group-id> element with the MCPTT group ID of a MCPTT group invited to the temporary group session;

then the controlling MCPTT function:

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

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

[TS 24.379 clause 6.3.3.2.3.2]

When sending a SIP 200 (OK) response to the initial SIP INVITE request, the controlling MCPTT function:

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

2) shall include the Session-Expires header field and start supervising the SIP session according to rules and procedures of IETF RFC 4028 [7], "UAS Behavior". The "refresher" parameter in the Session-Expires header field shall be set to "uac";

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

4) shall include a P-Asserted-Identity header field with the public service identity of the controlling MCPTT function;

5) shall include a SIP URI for the MCPTT session identity in the Contact header field identifying the MCPTT session at the controlling MCPTT function;

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

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

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

c) the isfocus media feature tag;

7) shall include Warning header field(s) received in incoming responses to the SIP INVITE request;

8) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [23];

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

10) shall include the "explicitsub" and "nosub" option tags in a Supported header field according to IETF RFC 7614 [35];

11) if:

a) an MCPTT GKTP document exists for the group identity contained in the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the initial SIP INVITE request; and

b) the MCPTT GKTP document contains an <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCPTT GKTP document:

i) shall perform the procedure in subclause 6.3.3.6.2 to re-generate an I_MESSAGE; and

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

[TS 24.379 clause 10.1.1.4.1.2]

This subclause describes the procedures for inviting an MCPTT user to an MCPTT session. The procedure is initiated by the controlling MCPTT function as the result of an action in subclause 10.1.1.4.2 or as the result of receiving a SIP 403 (Forbidden) response as described in this subclause.

The controlling MCPTT function:

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

2) shall set the Request-URI to the public service identity of the terminating participating MCPTT function associated to the MCPTT user to be invited.;

NOTE 1: How the controlling MCPTT function finds the address of the terminating MCPTT participating function is out of the scope of the current release.

NOTE 2: If the terminating MCPTT user is part of a partner MCPTT system, then the public service identity can identify an entry point in the partner network that is able to identify the terminating participating MCPTT function.

3) shall set the P-Asserted-Identity header field to the public service identity of the controlling MCPTT function;

4) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP INVITE request:

a) the <mcptt-request-uri> element set to the MCPTT ID of the terminating user; and

b) the <mcptt-calling-group-id> element set to the group identity;

NOTE 3: The <mcptt-calling-user-id> is already included in the MIME body as a result of calling subclause 6.3.3.1.2 in step 1).

5) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in subclause 6.3.3.1.1;

6) if the in-progress emergency state of the group is set to a value of "true" the controlling MCPTT function:

a) shall include a Resource-Priority header field populated with the values for an MCPTT emergency group call as specified in subclause 6.3.3.1.19;

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

i) shall include in the outgoing SIP INVITE request in the application/vnd.3gpp.mcptt-info+xml MIME body an <emergency-ind> element set to a value of "true"; and

ii) if the <alert-ind> element is set to "true" in the received SIP INVITE request and the requesting MCPTT user and MCPTT group are authorised for the initiation of MCPTT emergency alerts as determined by the procedures of subclause 6.3.3.1.13.1, shall populate the application/vnd.3gpp.mcptt-info+xml MIME body and the application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in subclause 6.3.3.1.12. Otherwise, shall set the <alert-ind> element to a value of "false"; and

c) if the in-progress imminent peril state of the group is set to a value of "true" shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <imminentperil-ind> element set to a value of "false";

7) if the in-progress emergency state of the group is set to a value of "false" and the in-progress imminent peril state of the group is set to a value of "true", the controlling MCPTT function:

a) shall include a Resource-Priority header field populated with the values for an MCPTT imminent peril group call as specified in subclause 6.3.3.1.19; and

b) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <imminentperil-ind> element set to a value of "true";

8) if:

a) an MCPTT GKTP document exists for the group identity contained in the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request; and

b) the MCPTT GKTP document contains a <MKFC-GKTPs> element;

then:

a) for each instance of <GKTP> element of the <MKFC-GKTPs> element of the MCPTT GKTP document:

i) shall perform the procedure in subclause 6.3.3.6.2 to re-generate an I_MESSAGE; and

9) shall send the SIP INVITE request towards the terminating network in accordance with 3GPP TS 24.229 [4].

Upon receiving a SIP 183 (Session Progress) response containing a Require header field with the option tag "100rel" and containing a P-Answer-State header field with the value "Unconfirmed" in response to the SIP INVITE request the controlling MCPTT function:

1) shall send a SIP PRACK request towards the MCPTT client according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response for the SIP INVITE request the controlling MCPTT function:

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

2) shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in subclause 10.1.3.4; and

3) shall increment the local counter of the number of SIP 200 (OK) responses received from invited members, by 1.

NOTE 4: The notifications above could be sent prior to the SIP 200 (OK) response being sent to the inviting MCPTT client. These notifications received by MCPTT clients that are group members do not mean that the group session will be successfully established.

NOTE 5: The procedures executed by the controlling MCPTT function prior to sending a response to the inviting MCPTT client are specified in subclause 10.1.1.4.2.

[TS 24.379 clause 6.3.3.2.4]

Upon receiving a SIP BYE request the controlling MCPTT function:

1) shall interact with the media plane as specified in subclause 6.3 in 3GPP TS 24.380 [5] for releasing the media plane resource associated with the SIP session towards the MCPTT client;

NOTE: The non-controlling MCPTT function is also regarded as a MCPTT client in a temporary MCPTT group session.

2) shall generate a SIP 200 (OK) response and send the SIP response towards the MCPTT client according to 3GPP TS 24.229 [4];

3) shall check the MCPTT session release policy as specified in subclause 6.3.8.1 and subclause 6.3.8.2 whether the MCPTT session needs to be released for each participant of the MCPTT session;

4) if release of the MCPTT session is required, perform the procedures as specified in the subclause 6.3.3.1.5; and

5) if a release of the MCPTT session is not required, shall send a SIP NOTIFY request to all remaining MCPTT clients in the MCPTT session with a subscription to the conference event package as specified in subclause 10.1.3.4.2.

Upon receiving a SIP 200 (OK) response to the SIP BYE request the controlling MCPTT function shall interact with the media plane as specified in subclause 6.3 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the MCPTT participant.

[TS 24.379 clause 6.3.3.1.5]

When a participant needs to be removed from the MCPTT session, the controlling MCPTT function:

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

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

3) shall send the SIP BYE request to the MCPTT clients according to3GPP TS 24.229 [4].

If timer TNG3 (group call timer) has not expired, then when the last MCPTT client is removed from the MCPTT session, the controlling MCPTT function shall stop timer TNG3 (group call timer).

When the MCPTT group session needs to be released, the controlling MCPTT function shall send SIP BYE requests as described in this subclause, to all participants of the group session.

Upon receiving a SIP 200 (OK) response to a SIP BYE request the controlling MCPTT function shall interact with the media plane as specified in subclause 6.3 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the MCPTT clients.

[TS 24.380 clause 6.3.2.2]

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

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

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

The original initial SIP INVITE request or SIP REFER request to establish an MCPTT chat group call or to rejoin an ongoing MCPTT call is not handled as an implicit floor control request message by the floor control server unless explicitly stated in the SIP INVITE request or in the SIP REFER request.

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

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

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

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

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

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

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

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

[TS 24.380 clause 6.3.5.2.2]

When a SIP Session is established and if the session is not a temporary group call session or if the session is a temporary group call session and the associated floor participant is an invited MCPTT client (i.e. not a constituent MCPTT group):

NOTE 1: A MCPTT group call is a temporary group session when the <on-network-temporary> element is present in the <list-service> element as specified in 3GPP TS 24.381 [12].

1. if an MCPTT client initiates an MCPTT call with an implicit floor request, and the MCPTT call does not exist yet, the floor control interface towards the MCPTT client in the floor control server:

a. shall initialize a general state machine as specified in subclause 6.3.4.2.2; and

NOTE 2: In the subclause 6.3.4.2.2 the ‘general floor control operation’ state machine will continue with the initialization of the ‘general floor control operation’ state machine.

b. shall enter the state ‘U: permitted’ as specified in the subclause 6.3.5.5.2;

2. if the associated MCPTT client rejoins an ongoing MCPTT call without an implicit floor request or initiates or joins a chat group call without an implicit floor request or attempts to initiate an already existing MCPTT call without an implicit floor request, and

a. if an MCPTT call already exists but no MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Idle message to the MCPTT client. The Floor Idle message:

A. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1; and

B. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

ii. shall enter the state ‘U: not permitted and Floor Idle’ as specified in the subclause 6.3.5.5.2;

b. if an MCPTT call is initiated, the floor control interface towards the MCPTT client in the floor control server:

i. shall enter the state ‘U: not permitted and Floor Idle’ as specified in the subclause 6.3.5.5.2; and

ii. shall initialize a general state machine as specified in subclause 6.3.4.2.2; and

NOTE 3: In the subclause 6.3.4.2.2 the general state machine will continue with the initialization of the general state machine.

c. if another MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Taken message to the MCPTT client. The Floor Taken message:

A. shall include the granted MCPTT users MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;

B. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1;

C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

D. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’; and

E. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2;

3. if the associated floor participant attempts to initiate an already existing MCPTT call with an implicit floor request, and

a. if no MCPTT client has the permission to send media, the floor control interface towards the MCPTT client in the floor control server:

i. shall processes the implicit floor request as if a Floor Request message was receive as specified in subclause 6.3.4.3.3; and

ii. shall enter the state ‘U: permitted’ as specified in the subclause 6.3.5.5.2;

b. if the MCPTT client negotiated support of queuing floor requests as specified in clause 14 and if another MCPTT client has the permission to send media, the floor control interface towards the MCPTT client in the floor control server:

i. shall set the priority level to the negotiated maximum priority level that the MCPTT client is permitted to request, except for pre-emptive priority, when high priority is used;

NOTE 4: The maximum floor priority the floor participant is permitted to request is negotiated in the "mc_priority" fmtp attribute as specified in clause 14.

NOTE 5: The initial implicit floor request will not result in pre-emption when an MCPTT client is joining an ongoing MCPTT call. If the MCPTT client wants to pre-empt the current MCPTT client that are sending media, an explicit floor request with pre-emptive floor priority is required.

ii. shall insert the MCPTT client into the active floor request queue to the position immediately following all queued floor requests with the same floor priority;

iii. shall send a Floor Queue Position Info message to the MCPTT client. The Floor Queue Position Info message:

A shall include the queue position and floor priority in the Queue Info field; and

iv. should send a Floor Queue Position Info message with the updated status to the MCPTT clients in the active floor request queue which negotiated queuing of floor requests as specified in clause 14, which have requested the queue status, whose queue position has been changed since the previous Floor Queue Position Info message and which is not the joining MCPTT client. The Floor Queue Position Info message:

A shall include the queue position and floor priority in the Queue Info field; and

v. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and

c. if the MCPTT client did not negotiate queuing of floor requests and if another MCPTT client has the permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. shall send a Floor Taken message to the MCPTT client. The Floor Taken message:

A. shall include the granted MCPTT users MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;

B. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;

C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

D. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’; and

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and

4. if the MCPTT client is invited to the MCPTT call and

a. if another MCPTT client has permission to send a media, the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Taken message to the MCPTT client. The Floor Taken message:

A. shall include the granted MCPTT users MCPTT ID in the Granted Party’s Identity field, if privacy is not requested;

B. shall include a Message Sequence Number field with a Message Sequence Number value increased with 1;

C. if the session is a broadcast group call, shall include the Permission to Request the floor field set to ‘0’;

D. if the session is not a broadcast group call, may include the Permission to Request the floor field set to ‘1’; and

ii. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and

b. if no other MCPTT client has the permission to send a media; the floor control interface towards the MCPTT client in the floor control server:

i. should send a Floor Idle message to the MCPTT client. The Floor Idle message:

A. shall include a Message Sequence Number field with a <Message Sequence Number> value increased with 1; and

ii. shall enter the ‘U: not permitted and Floor Idle’ state as specified in the subclause 6.3.5.3.2.

When a SIP Session is established and if the session is a temporary group call session and,

1. if the associated floor participant is a constituent MCPTT group; or

2. if the associated floor participant is the initiator of the temporary group session;

then the floor control interface towards the MCPTT client:

1. shall initialize a general state machine as specified in subclause 6.3.4.2.2, if not already initiated; and

2. shall enter the ‘U: not permitted and initiating’ state as specified in subclause 6.3.5.10.2.

[TS 24.380 clause 6.3.5.3.3]

When a Floor Taken message is received from the floor control server arbitration logic, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Taken message to the associated floor participant;

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

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 enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2.

[TS 24.380 clause 6.3.5.5.3]

Upon receiving a Floor Release message from the associated floor participant, the floor control interface towards the MCPTT client in the floor control server:

1. if the first bit in the subtype of the Floor Release 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 ‘4’ (Floor Release); and

b. shall include the Source field set to ‘2’ (the controlling MCPTT function is the source);

2. if an indication that the participant is overriding without revoke is stored,

a. shall forward the Floor Release message to the dual floor control operation state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set;

b. shall remove the indication that the participant is overriding without revoke; and

c. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2;

3. if an indication that the participant is overridden without revoke is stored,

a. shall forward the Floor Release message to the general floor control operation state machine of the floor control arbitration logic in the MCPTT server with the first bit in the subtype of the Floor Release message set to ‘0’ (Acknowledgment is not required), if not already set;

b. shall remove the indication that the participant is overridden without revoke; and

c. shall enter the ‘U: not permitted and Floor Taken’ state as specified in the subclause 6.3.5.4.2; and

4. if no indication is stored:

b. shall remain in the ‘U: permitted’ state.

[TS 24.380 clause 6.3.5.5.4]

Upon receiving the Floor Idle message from the floor control server arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. if the G-bit in the Floor Indicator is set to ‘1’ (Dual Floor) and an indication that the participant is overridden without revoke is stored

a. shall send Floor Idle message to the associated floor participant;

b. shall remove the indication that a participant is overridden without revoke; and

c. shall remain in ‘U: permitted state’;

2. if no indication is stored shall enter the ‘U: not permitted and Floor Idle’ state as specified in the subclause 6.3.5.3.2; and

3. if an indication that the participant is overriding without revoke is stored

a. shall send Floor Idle message to the associated floor participant;

b. shall remove the indication that a participant is overriding without revoke; and

c. shall remain in ‘U: permitted state’.

[TS 24.380 clause 6.3.5.3.5]

When a Floor Granted message is received from the floor control arbitration logic in the MCPTT server, the floor control interface towards the MCPTT client in the floor control server:

1. shall forward the Floor Granted messages to the associated floor participant;

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

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 enter the state ‘U: permitted’ as specified in subclause 6.3.5.5.2.

[TS 24.380 clause 6.3.5.4.4]

Upon receiving a Floor Request message, without a Floor Indicator field or with the Floor Indicator field included where the D-bit (Emergency call) and the E-bit (Imminent peril call) are set to ‘0’, from the associated floor participant, and if the MCPTT client did not negotiate queuing of floor requests or did not include a priority in the "mc_priority" fmtp attribute as specified in clause 14, the floor control interface towards the MCPTT client in the floor control server:

1. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

a. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

c. if the Floor Request included a Track Info field, shall include the received Track Info field; and

d. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;

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

NOTE 1: 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 remain in the ‘U: not permitted and Floor Taken’ state.

Upon receiving a Floor Request message from the associated floor participant and the session is a broadcast group call, the floor control interface towards the MCPTT client in the floor control server:

1. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

a. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only);

b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value; and

c. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications;

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

NOTE 2: 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 remain in the ‘U: not permitted and Floor Taken’ state.

Upon receiving a Floor Request message from the associated floor participant and if the MCPTT client negotiated support of queuing of floor requests or included a floor priority in the "mc_priority" or both as described in specified in clause 14 and according to local policy, the floor control interface towards the MCPTT client in the floor control server:

1. shall determine the effective priority level as described in subclause 4.1.1.4 by using the following parameters:

a. the floor priority shall be:

i. the lower of the floor priority included in Floor Request message and the negotiated maximum floor priority that the MCPTT client is permitted to request, if the MCPTT client negotiated floor priority "mc_priority" and floor priority is included in the Floor Request message;

ii. the receive only floor priority, if the MCPTT client negotiated floor priority in the "mc_priority" fmtp attribute and if the negotiated maximum floor priority that the MCPTT client is permitted to request is "receive only";

iii. the default priority, if the MCPTT client negotiated floor priority in the "mc_priority" fmtp attribute, if the negotiated maximum floor priority that the MCPTT client is permitted to request is not receive only and if the floor priority is not included in the Floor Request message; and

iv. the default priority, if the MCPTT client did not negotiate floor priority in the "mc_priority" fmtp attribute; and

b. the type of the call shall be

i. if the Floor Indicator field is included in the message and the D-bit (Emergency call bit) is set to ‘1’, determined to be an emergency call;

ii. if the Floor Indicator field is included in the message and the E-bit (Imminent peril call) is set to ‘1’, determined to be an imminent peril call; and

iii. if the Floor Indicator field is not included in the message or the Floor Indicator field is included and neither the D-bit (Emergency call bit) nor the E-bit (Imminent peril call) is set to ‘1’, determined to be a normal call;

2. if the effective priority is "receive only", the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Deny message to the floor participant. The Floor Deny message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #5 (Receive only) ;

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

iv. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state;

3. if

a. a Track Info field is included in the Floor Request message, shall use the topmost <Participant Reference> value and the SSRC in the received Floor Request message to check if the floor participant has a queued floor request; or

b. a Track Info field is not included in the Floor Request message, shall use the SSRC in the received Floor Request message to check if the floor participant has a queued floor request;

4. if the floor participant already has a queued floor request with the same effective priority level, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Queue Position Info message to the requesting MCPTT client, if the MCPTT client negotiated support of queuing of floor requests as specified in clause 14. The Floor Queue Position Info message:

i. shall include the queue position and floor priority in the Queue Info field;

ii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

iii. if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session, shall include the Floor Indicator field with appropriate indications; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state

5. if the effective priority level is pre-emptive and there are no other pre-emptive requests in the active floor request queue and the effective priority level of the current MCPTT client with permission to send a media is not the pre-emptive priority, the floor control interface towards the MCPTT client in the floor control server:

a. shall forward the Floor Request message to the floor control server arbitration logic indicating that a Floor Request message with pre-emptive priority is received; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state

NOTE 3: The Floor control server arbitration logic initiates revoking the permission to send media towards the current MCPTT client with the permission to send media as specified in the subclause 6.3.4.4.7;

6. if the MCPTT client did not negotiate support of queuing of floor requests as specified in clause 14, the effective priority level is pre-emptive and either other pre-emptive request is queued or the effective priority level of the current MCPTT client with permission to send a media is the pre-emptive priority, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state;

7. if the MCPTT client did not negotiate "queuing" and the effective priority level is not pre-emptive, the floor control interface towards the MCPTT client in the floor control server:

a. shall send a Floor Deny message to the associated floor participant. The Floor Deny message:

i. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);

ii. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value;

iii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

b. shall remain in the ‘U: not permitted and Floor Taken’ state; and

8. if the MCPTT client negotiated support of queuing of floor requests as specified in clause 14 and the effective priority level is not pre-emptive, the floor control interface towards the MCPTT client in the floor control server:

a. shall insert the MCPTT client into the active floor request queue, if not inserted yet, or update the position of the MCPTT client in the active floor request queue, if already inserted, to the position immediately following all queued requests at the same effective priority level;

b. the floor control server shall send a Floor Queue Position Info message to the floor participant. The Floor Queue Position Info message:

i. shall include the queue position and floor priority in the Queue Info field;

ii. if the Floor Request included a Track Info field, shall include the received Track Info field; and

c. shall remain in the ‘U: not permitted and Floor Taken’ state; and

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

NOTE 4: 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.

7.1.3 Test description

7.1.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT Server)

– SS (MCPTT Server) provides the participating MCPTT functions

– SS-UE1 (MCPTT client)

– SS-UE2 (MCPTT client)

IUT:

– IUT (MCPTT Server)

– IUT (MCPTT Server) provides the controlling MCPTT function

– The IUT (MCPTT Server) consists of all sub-systems of the Common Services Core, including the Group Management Server, the Configuration Management Server, the Key Management Server, the Identity Management Server, the HTTP Server, and the SIP AS. The IUT (MCPTT Server) also consists of all sub-systems of the MCPTT Server, including the Media Distribution Function, the MCPTT User Database, the SIP AS, the HTPP Server, the HTTP Client, and the Floor Control Server.

Preamble:

– The IUT (MCPTT Server) is connected to SS (MCPTT Server) defined in TS 36.579-1 [2], Figure 4.2.5.

– SS-UE1 (MCPTT client) and SS-UE2 (MCPTT client) are affiliated with Group A and are authorized to initiate prearranged group calls

– Group A is controlled by the controlling MCPTT function, IUT (MCPTT Server)

Figure 7.1.3.1-1: Functions of the testing components

7.1.3.2 Test procedure sequence

Table 7.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The SS (MCPTT Server) sends a SIP INVITE message initiating a pre-arranged group call with automatic commencement mode from SS-UE2 (MCPTT client) to SS-UE1 (MCPTT client).	<–	SIP INVITE	–	–
2	Check: Does the IUT (MCPTT Server) send a SIP 100 (Trying) message to the participating server SS (MCPTT Server)?	–>	SIP 100 (Trying)	1	P
3	Check: Does the IUT (MCPTT Server) send a SIP INVITE message for SS-UE1 (MCPTT client) to the participating server SS (MCPTT Server)?	–>	SIP INVITE	1	P
4	The SS (MCPTT Server) responds to the SIP INVITE message by sending a SIP 183 (Session Progress) message	<–	SIP 183 (Session Progress)	–	–
5	Check: Does the IUT (MCPTT Server) send a SIP PRACK message to the server SS (MCPTT Server)?	–>	SIP PRACK	1	P
5A	The SS (MCPTT Server) responds to the SIP PRACK with a SIP 200 (OK) message.	<–	SIP 200 OK	–	–
6	Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) message to SS-UE2 (MCPTT Client) via the participating server SS (MCTT Server) with the P-Answer-State header field set to "unconfirmed"?	–>	SIP 200 (OK)	1	P
7	The SS-UE1 (MCPTT Client) responds to the SIP INVITE in step 3 via the SS (MCPTT Server) by sending a SIP 200 (OK) message	<–	SIP 200 OK	–	–
8	Check: Does the IUT (MCPTT Server) respond to the SIP INVITE sent in step 1 with a SIP 200 (OK) message?	–>	SIP 200 (OK)	1	P
9	The SS (MCPTT Server) responds with a SIP ACK message	<–	SIP ACK	–	–
10	Check: The IUT (MCPTT Server) responds to the SS-UE1 (MCPTT Client) via the server SS (MCPTT server) with a SIP ACK message	–>	SIP ACK	1	P
11	Check: Does the IUT (MCPTT Server) send a Floor Taken message to the SS-UE1 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Taken	2	P
12	The SS (MCPTT Server) sends a Floor Release message with no acknowledgement required to release the floor from SS-UE2 (MCPTT client)	<–	Floor Release	–	–
13	Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE2 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Idle	2	P
14	Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE1 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Idle	2	P
15	The SS (MCPTT Server) sends a Floor Request message from SS-UE1 (MCPTT client)	<–	Floor Request	–	–
16	Check: Does the IUT (MCPTT Server) send a Floor Granted message to the SS-UE1 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Granted	2	P
17	Check: Does the IUT (MCPTT Server) send a Floor Taken message to the SS-UE2 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Taken	2	P
18	The SS (MCPTT Server) sends a Floor Release message from SS-UE1 (MCPTT client)	<–	Floor Release	–	–
19	Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE1 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Idle	2	P
20	Check: Does the IUT (MCPTT Server) send a Floor Idle message to the SS-UE2 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	Floor Idle	2	P
21	The SS (MCPTT Server) sends a SIP BYE request from SS-UE1 (MCPTT client)	<–	SIP BYE	–	–
22	Check: Does the IUT (MCPTT Server) respond with a SIP 200 (OK) message to SS-UE1 (MCPTT client) via the participating server SS (MCPTT Server)?	–>	SIP 200 (OK)	3	P
23	Check: Does the IUT (MCPTT Server) send a SIP BYE message to the SS-UE2 (MCPTT client) to end the call via the participating server SS (MCPTT Server)?	–>	SIP BYE	3	P
24	The SS (MCPTT Server) responds with a SIP 200 (OK) message from SS-UE2 (MCPTT client)	<–	SIP 200 (OK)	–	–

7.1.3.3 Specific message contents

Table 7.1.3.3-1: SIP INVITE (Step 1, Table 7.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1 condition MCPTT
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCPTT_PublicServiceId_B	The public service identity of the controlling MCPTT function
From
addr-spec
user-info and host	px_MCPTT_Client_B_ID
Session-Expires
generic-param	any allowed value	The recommended initial value is 1800 in RFC 4028 [30].
P-Asserted-Identity
addr-spec
user-info and host	px_MCX_SIP_PublicUserId_B_1
Answer-Mode	not present
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 7.1.3.3-1A
MIME body part		MCPTT-INFO
MIME-part-body	MCPTT-Info as described in Table 7.1.3.3-2
MIME body part		Resource-Lists
MIME-part-body	Resource-lists as described in TS 36.579-1 [2], Table 5.5.3.3.2-1

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

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

Table 7.1.3.3-2: MCPTT-INFO in SIP INVITE (Table 7.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1 conditions GROUP-CALL, INVITE_REFER
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-calling-user-id	encrypted (NOTE 1) <mcptt-calling-user-id> with mcpttURI set to px_MCPTT_ID_User_B
NOTE 1: Encrypted element as described in TS 36.579-1 [2] Table 5.5.3.2.1-1A

Table 7.1.3.3-3: SIP INVITE (Step 3, Table 7.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCPTT_PublicServiceId_A	The public service identity of the terminating participating MCPTT function
Contact
addr-spec	SIP URI
user-info and host	tsc_MCPTT_PublicServiceId_B
Session-Expires
generic-param	any allowed value	The recommended initial value is 1800 in RFC 4028 [30].
P-Asserted-Identity
addr-spec	tsc_MCPTT_PublicServiceId_B	The public service identity of the controlling MCPTT function
Referred-By
addr-spec	px_MCPTT_ID_User_B	Contains the public user identity of the inviting MCPTT user	TS 24.379 [9] clause 6.3.3.1.2
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 7.1.3.3-3A
MIME body part		MCPTT-INFO
MIME-part-body	MCPTT-Info as described in Table 7.1.3.3-4

Table 7.1.3.3-3A: SDP in SIP INVITE (Table 7.1.3.3-3)

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

Table 7.1.3.3-4: MCPTT-INFO in SIP INVITE (Table 7.1.3.3-3)

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

Table 7.1.3.3-5: SIP 183 (Session Progress) (Step 4, Table 7.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.16.3.2-1 conditions 100rel, MCPTT

Table 7.1.3.3-6: Void

Table 7.1.3.3-7: SIP 200 (OK) (Step 6, Table 7.1.3.2-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
Contact
addr-spec	tsc_MCPTT_PublicServiceId_B
P-Answer-State
value	"unconfirmed"
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 7.1.3.3-7A

Table 7.1.3.3-7A: SDP in SIP 200 (OK) (Table 7.1.3.3-1)

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

Table 7.1.3.3-8: SIP 200 (OK) (Step 7, Table 7.1.3.2-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
MIME body part		SDP message
MIME-part-body	SDP message as described in Table 7.1.3.3-8A
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info message as described in Table 7.1.3.3-8B

Table 7.1.3.3-8A: SDP in SIP 200 (OK) (Table 7.1.3.3-8)

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

Table 7.1.3.3-8B: MCPTT-Info in SIP 200 (OK) (Table 7.1.3.3-8)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-1 conditions GROUP-CALL, INVITE_RSP
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-calling-user-id	not present
mcptt-called-party-id	encrypted <mcptt-called-party-id> with mcpttURI set to px_MCPTT_ID_User_A	Encrypted element as described in TS 36.579-1 [2] Table 5.5.3.2.1-1A

Table 7.1.3.3-9: SIP 200 (OK) (Step 8, Table 7.1.3.2-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
Contact
addr-spec
user-info and host	tsc_MCPTT_PublicServiceId_B
Message-body
MIME body part		SDP message
MIME-part-body	SDP message as described in Table 7.1.3.3-9A

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

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

Table 7.1.3.3-10: Void

Table 7.1.3.3-11: Void

Table 7.1.3.3-12: SIP BYE (Step 21, Table 7.1.3.2-1)

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

Table 7.1.3.3-13: SIP BYE (Step 23, Table 7.1.3.2-1)

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

Table 7.1.3.3-14: Void

Table 7.1.3.3-15: Void

Table 7.1.3.3-16: Floor Taken (Step 11, Table 7.1.3.2-1)

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

Table 7.1.3.3-17: Floor Taken (Step 17, Table 7.1.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 condition ON-NETWORK
Information Element	Value/remark	Comment	Condition
Granted Party’s Identity
Granted Party’s Identity	px_MCPTT_User_A_ID

Table 7.1.3.3-18: Floor Release (Steps 12, 18, Table 7.1.3.2-1)

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

Table 7.1.3.3-19: Void

Table 7.1.3.3-20: Void

Table 7.1.3.3-21: Floor Request (Step 15, Table 7.1.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition ON-NETWORK
Information Element	Value/remark	Comment	Condition
Floor priority	"0"

Table 7.1.3.3-22: Floor Granted (Step 16, Table 7.1.3.2-1)

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

7.2 MCPTT Server – MCPTT Server / On-demand Pre-arranged Group Call / Automatic Commencement Mode / Floor Control / Participating Server

7.2.1 Test Purpose (TP)

(1)

with { IUT (MCPTT Server) connected to PLMN1 }

ensure that {

when { the SS-UE2 (MCPTT client) initiates registration }

then { IUT (MCPTT Server) initially responds to the SS-UE2 (MCPTT client) with a SIP 401 Unauthorized message and continues the process by responding to the SS-UE2 (MCPTT client) with SIP 200 (OK) messages}

}

(2)

with { IUT (MCPTT Server) connected to SS (MCPTT Server) and PLMN1 }

ensure that {

when { the SS-UE2 (MCPTT client) initiates a pre-arranged group call with automatic commencement mode }

then { IUT (MCPTT Server) interacts with SS (MCPTT Server) and SS-UE2 (MCPTT client) to set up the call by sending SIP messages }

}

(3)

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

ensure that {

when { the SS-UE1 (MCPTT client) and SS-UE2 (MCPTT client) engage in communication }

then { IUT (MCPTT Server) forwards floor control messages to the controlling server SS (MCPTT Server) and to the SS (MCCPT Client B) }

}

(4)

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

ensure that {

when { the SS (MCPTT Server) ends the pre-arranged group call }

then { IUT (MCPTT Server) responds to the SS (MCPTT Server) by sending a SIP 200 (OK) message and sends a SIP BYE message to the SS-UE2 (MCPTT client) }

}

7.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.379 clause 10.1.1.3.1.1, 6.3.2.1.3, 6.3.2.2.4.2, 6.3.2.1.5.2, 6.3.2.2.8.1, TS 24.380 clause 6.4.2. Unless otherwise stated these are Rel-13 requirements.

[TS 24.379 clause 10.1.1.3.1.1]

In the procedures in this subclause:

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

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

3) 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 a "SIP INVITE request for originating participating MCPTT function" containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element set to a value of "prearranged", the participating MCPTT function:

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

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

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

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

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

4) shall validate the media parameters and if the MCPTT speech codec is not offered in the SIP INVITE request shall reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

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

NOTE 3: If the SIP INVITE request contains an emergency indication or an imminent peril indication, the participating MCPTT function can by means beyond the scope of this specification choose to allow for an exception to the limit for the maximum simultaneous MCPTT sessions supported for the MCPTT user. Alternatively, a lower priority session of the MCPTT user could be terminated to allow for the new session.

6) if the user identified by the MCPTT ID is not affiliated to the group identified in the "SIP INVITE request for originating participating MCPTT function" as determined by subclause 9.2.2.2.11 and this is an authorised request for originating a priority call as determined by subclause 6.3.2.1.8.1, shall perform the actions specified in subclause 9.2.2.2.12 for implicit affiliation;

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

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

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

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

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

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

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

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

11) shall not copy the following header fields from the incoming SIP INVITE request to the outgoing SIP INVITE request, if they were present in the incoming SIP INVITE request:

a) Answer-Mode header field as specified in IETF RFC 5373 [18]; and

b) Priv-Answer-Mode header field as specified in IETF RFC 5373 [18];

12) shall set the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request to the MCPTT ID of the calling user;

13) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the MCPTT client as specified in subclause 6.3.2.1.1.1;

14) if the received SIP INVITE request contains an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in clause F.3 and if not already copied, shall copy the contents of the application/vnd.3gpp.mcptt-location-info+xml MIME body received in the SIP INVITE request into an application/vnd.3gpp.mcptt-location-info+xml MIME body included in the outgoing SIP request;

15) if a Resource-Priority header field was included in the received SIP INVITE request, shall include a Resource-Priority header field according to rules and procedures of 3GPP TS 24.229 [4] set to the value indicated in the Resource-Priority header field of the SIP INVITE request from the MCPTT client; and

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

16) shall forward the SIP INVITE request, according to 3GPP TS 24.229 [4].

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

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

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

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

Upon receipt of a SIP 2xx response in response to the above SIP INVITE request, the participating MCPTT function:

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

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

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

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

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

6) shall include an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the received SIP 200 (OK) response;

7) if the procedures of subclause 9.2.2.2.12 for implicit affiliation were performed in the present subclause, shall complete the implicit affiliation by performing the procedures of subclause 9.2.2.2.13;

8) shall send the SIP 200 (OK) response to the MCPTT client according to 3GPP TS 24.229 [4];

9) shall interact with Media Plane as specified in 3GPP TS 24.380 [5]; and

10) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [7].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request, the participating MCPTT function:

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

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

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

4) if the implicit affiliation procedures of subclause 9.2.2.2.12 were invoked in this procedure, shall perform the procedures of subclause 9.2.2.2.14;

[TS 24.379 clause 6.3.2.1.3]

This subclause is referenced from other procedures.

When generating an initial SIP INVITE request according to 3GPP TS 24.229 [4], on receipt of an incoming SIP INVITE request, the participating MCPTT function:

1) shall include in the SIP INVITE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] if included in the incoming SIP INVITE request;

2) 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";

3) shall include the option tag "timer" in the Supported header field;

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP INVITE request to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

5) shall include the g.3gpp.mcptt media feature tag into the Contact header field of the outgoing SIP INVITE request;

6) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), into the P-Asserted-Service header field of the outgoing SIP INVITE request;

7) if the incoming SIP INVITE request contained a MIME resource-lists body with the MCPTT ID of the invited MCPTT user, shall copy the MIME resource-lists body, according to rules and procedures of IETF RFC 5366 [20];

8) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request to the outgoing SIP INVITE request; and

9) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcptt-location-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.mcptt-location-info+xml MIME body of the incoming SIP INVITE request to the outgoing SIP INVITE request.

[TS 24.379 clause 6.3.2.2.4.2]

This subclause is referenced from other procedures.

When sending SIP 200 (OK) responses, the participating MCPTT function shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [4] and:

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

2) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [7], "UAS Behavior". If no "refresher" parameter was included in the SIP INVITE request, the "refresher" parameter in the Session-Expires header field shall be set to "uas";

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

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

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

c) an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the received SIP INVITE request from the controlling MCPTT function;

4) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [23]; and

5) if the incoming SIP response contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing SIP 200 (OK) response.

[TS 24.379 clause 6.3.2.1.5.2]

This subclause is referenced from other procedures.

When sending SIP 200 (OK) responses, the participating MCPTT function shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [4] and:

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

2) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [7], "UAS Behavior". If the "refresher" parameter is not included in the received request, the "refresher" parameter in the Session-Expires header field shall be set to "uac";

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

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

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

c) the isfocus media feature tag;

4) shall include the option tag "tdialog" in a Supported header field according to rules and procedures of IETF RFC 4538 [23];

5) shall include the option tag "norefersub" in a Supported header field according to rules and procedures of IETF RFC 4488 [22];

6) may include a Resource-Share header field in accordance with subclause 5.7.1.20.2 in 3GPP TS 24.229 [4]; and

7) if the incoming SIP 200 (OK) response contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing SIP 200 (OK) response.

[TS 24.379 clause 6.3.2.2.8.1]

Upon receiving a SIP BYE request from the controlling MCPTT function, the participating MCPTT function:

1) shall interact with the media plane as specified in subclause 6.4 in 3GPP TS 24.380 [5] for releasing media plane resource associated with the SIP session with the controlling MCPTT function;

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

3) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request; and

4) shall send the SIP BYE request to the MCPTT client according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the SIP BYE request the participating MCPTT function:

1) shall send a SIP 200 (OK) response to the SIP BYE request received from the controlling MCPTT function according to 3GPP TS 24.229 [4]; and

2) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the MCPTT client.

[TS 24.380 clause 6.4.2]

Upon receiving a floor control message the participating MCPTT function:

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

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

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

a. if

i. the floor control message is not a Floor Idle message or a Floor Taken message;

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

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

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

b. if

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

ii if the floor control message is the Floor Idle message or the Floor Taken message,

shall perform actions as specified in subclause 10.2.

NOTE: When the Floor Idle or Floor Taken messages are discarded the messages are sent to the MCPTT clients over the MBMS subchannel allocated for the conversation as specified in subclause 10.2.

7.2.3 Test description

7.2.3.1 Pre-test conditions

System Simulator:

– SS (MCPTT Server)

– SS (MCPTT Server) provides the controlling MCPTT function and the terminating participating MCPTT function

– SS-UE1 (MCPTT client)

– SS-UE2 (MCPTT client)

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

IUT:

– IUT (MCPTT Server)

– IUT (MCPTT Server) provides the originating participating MCPTT function

Preamble:

– The IUT (MCPTT Server) is connected to SS (MCPTT Server) and to PLMN1 defined in TS 36.579-1 [2], Figure 4.2.6.

– SS-UE1 (MCPTT client) and SS-UE2 (MCPTT client) are affiliated with Group A and are authorized to initiate prearranged group calls

– Group A is controlled by the controlling MCPTT function, SS (MCPTT Server)

Figure 7.2.3.1-1: Functions of the testing components

7.2.3.2 Test procedure sequence

Table 7.2.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
–	EXCEPTION: In parallel to the event described in steps 1 to 4 below the SS-UE2 (MCPTT client) user authentication, authorization, and configuration as according to Table 5.1.3.2-1 takes place.	–	–	–	–
1	The SS-UE2 (MCPTT client) sends initial registration for IMS services	<–	SIP REGISTER	–	–
2	Check: Does the IUT (MCPTT Server) respond with a valid AKAv1-MD5 authentication challenge and security mechanisms supported by the network?	–>	SIP 401 Unauthorized	1	P
3	The SS-UE2 (MCPTT client) completes the security negotiation procedures, sets up a temporary set of SAs and uses those for sending another REGISTER with AKAv1-MD5 credentials	<–	SIP REGISTER	–	–
4	Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) to the SS-UE2 (MCPTT client)?	–>	SIP 200 OK	1	P
5-6	Void	–	–	–	–
7	The SS-UE2 (MCPTT client) sends a SIP INVITE message initiating a pre-arranged group call with automatic commencement mode	<–	SIP INVITE	–	–
8	Check: Does the IUT (MCPTT Server) send a SIP 100 (Trying) message to SS-UE2 (MCPTT client)?	–>	SIP 100 (Trying)	2	P
9	Check: Does the IUT (MCPTT Server) send a SIP INVITE message to the controlling server SS (MCPTT Server) for SS-UE1 (MCPTT client)?	–>	SIP INVITE	2	P
10	The SS (MCPTT Server) responds to the SIP INVITE message by sending a SIP 183 (Session Progress) message	<–	SIP 183 (Session Progress)	–	–
10A	Check: Does the IUT (MCPTT Server) send a SIP PRACK message to the server SS (MCPTT Server)?	–>	SIP PRACK	2	P
10B	The SS (MCPTT Server) responds to the SIP PRACK with a SIP 200 (OK) message.	<–	SIP 200 OK	–	–
10C	Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) message to SS-UE2 (MCPTT Client) via the participating server SS (MCTT Server) with the P-Answer-State header field set to "unconfirmed"?	–>	SIP 200 (OK)	2	P
11	The SS (MCPTT Server) responds to the SIP INVITE message in step 9 by sending a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
–	EXCEPTION: In parallel to the events described in steps 12 to 13 the steps specified in Table 7.2.3.2-2 should take place.	–	–	–	–
12	Check: Does the IUT (MCPTT Server) respond to the SIP INVITE from the SS-UE2 (MCPTT client) sent in step 7 with a SIP 200 (OK) message?	–>	SIP 200 (OK)	2	P
13	The SS-UE2 (MCPTT client) responds with a SIP ACK message	<–	SIP ACK	–	–
14	Void	–	–	–	–
15	The SS-UE2 (MCPTT client) sends a Floor Release message with no acknowledgement required	<–	Floor Release	–	–
16	Check: Does the IUT (MCPTT Server) forward the Floor Release message to the SS (MCPTT Server)?	–>	Floor Release	3	P
17	The SS (MCPTT Server) sends a Floor Idle message to SS-UE2 (MCPTT client) via the IUT (MCPTT Server)	<–	Floor Idle	–	–
18	Check: Does the IUT (MCPTT Server) forward the Floor Idle message to the SS-UE2 (MCPTT client)?	–>	Floor Idle	3	P
19	The SS (MCPTT Server) sends a Floor Taken message to SS-UE2 (MCPTT client) via the IUT (MCPTT Server) informing that the floor has been taken by SS (MCPPT Client A)	<–	Floor Taken	–	–
20	Check: Does the IUT (MCPTT Server) forward the Floor Taken message to the SS-UE2 (MCPTT client)?	–>	Floor Taken	3	P
21	The SS (MCPTT Server) sends a Floor Idle message to SS-UE2 (MCPTT client) via the IUT (MCPTT Server)	<–	Floor Idle	–	–
22	Check: Does the IUT (MCPTT Server) forward the Floor Idle message to the SS-UE2 (MCPTT client)?	–>	Floor Idle	3	P
23	The SS (MCPTT Server) sends a SIP BYE request to SS-UE2 (MCPTT client) via the IUT (MCPTT Server)	<–	SIP BYE	–	–
24	Check: Does the IUT (MCPTT Server) send a SIP BYE message to the SS-UE2 (MCPTT client) to end the call?	–>	SIP BYE	4	P
25	The SS-UE2 (MCPTT client) responds with a SIP 200 (OK) message	<–	SIP 200 (OK)	–	–
26	Check: Does the IUT (MCPTT Server) send a SIP 200 (OK) message to SS (MCPTT Server)?	–>	SIP 200 (OK)	4	P

Table 7.2.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Check: Does the IUT (MCPTT Server) respond with a SIP ACK message to the controlling server SS (MCPTT Server)?	–>	SIP ACK	2	P

7.2.3.3 Specific message contents

Table 7.2.3.3-1: SIP REGISTER (Step 1, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.13-1 condition SIP_REGISTER_INITIAL
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCPTT_PublicServiceId_B	The public service identity of the MCPTT server under test
From
addr-spec
user-info and host	px_MCX_SIP_PublicUserId_B_1
AuthorizationTo
username addr-spec	px_MCX_SIP_PrivateUserId_Bpx_MCPTT_Server_B_URI

Table 7.2.3.3-2: Void

Table 7.2.3.3-2A: SIP REGISTER (Step 3, Table 6.1.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.13-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCPTT_PublicServiceId_B	SIP URI of the home domain name

Table 7.2.3.3-3: SIP 200 (OK) (Step 4, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1 condition REGISTER-RSP
Information Element	Value/remark	Comment	Reference	Condition
P-Associated-URI
addr-spec[1]	SIP URI
host	px_MCX_SIP_PublicUserId_B_1

Table 7.2.3.3-3A: SIP 200 (OK) (Step 10C, Table 7.2.3.2-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
Contact
addr-spec	tsc_MCPTT_PublicServiceId_B
P-Answer-State
value	"unconfirmed"
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 7.2.3.3-3B

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

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

Table 7.2.3.3-4: SIP 200 (OK) (Step 11, Table 7.2.3.2-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
MIME body part		SDP message
MIME-part-body	SDP message as described in Table 7.2.3.3-4A
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info message as described in Table 7.2.3.3-4B

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

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

Table 7.2.3.3-4B: MCPTT-Info in SIP 200 (OK) (Table 7.2.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-1 conditions GROUP-CALL
Information Element	Value/remark	Comment	Reference	Condition
mcpttinfo
mcptt-Params
mcptt-calling-user-id	not present
mcptt-called-party-id	encrypted <mcptt-called-party-id> with mcpttURI set to px_MCPTT_ID_User_A	Encrypted element as described in TS 36.579-1 [2] Table 5.5.3.2.1-1A

Table 7.2.3.3-5: SIP 200 (OK) (Step 12, Table 7.2.3.2-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
Contact
addr-spec
user-info and host	tsc_MCPTT_PublicServiceId_B
Content-Type
value	"multipart/mixed"
Message-body
MIME body part		SDP message
MIME-part-body	SDP message as described in Table 7.2.3.3-5A
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info message as described in Table 7.2.3.3-4B

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

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

Table 7.2.3.3-6: Void

Table 7.2.3.3-7: Void

Table 7.2.3.3-8: SIP INVITE (Step 7, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1 condition MCPTT
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCPTT_PublicServiceId_B
From
addr-spec
user-info and host	Default public user id (px_MCX_SIP_PublicUserId_B_1)
Session-Expires
generic-param	"1800"	1800 seconds, or 30 minutes
P-Asserted-Identity
addr-spec	px_MCPTT_User_B_ID
Message-body
MIME body part		SDP message
MIME-part-body	SDP message as described in Table 7.2.3.3-9
MIME body part		MCPTT-Info
MIME-part-body	MCPTT-Info message as described in Table 7.2.3.3-10
MIME body part		Resource-lists
MIME-part-body	Resource-lists message as described in Table 7.2.3.3-10A

Table 7.2.3.3-9: SDP in SIP INVITE (Table 7.2.3.3-8)

TS 36.579-1 [2], Table 5.5.3.1.1-1 conditions SDP_OFFER, IMPLICIT_GRANT_REQUESTED

Table 7.2.3.3-10: MCPTT-Info in SIP INVITE (Table 7.2.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
mcptt-calling-user-id	encrypted (NOTE 1) <mcptt-calling-user-id> with mcpttURI set to px_MCPTT_ID_User_A
NOTE 1: Encrypted element as described in TS 36.579-1 [2], Table 5.5.3.2.1-1A

Table 7.2.3.3-10A: Resource-lists in SIP INVITE (Table 7.2.3.3-8)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.3.1-1
Information Element	Value/remark	Comment	Reference	Condition
resource-lists	encrypted (NOTE 1)
list[1]	encrypted (NOTE 1)
name attribute	Not present
display-name	Not present
entry[1]	NOTE 4,5
uri attribute	px_MCPTT_ID_User_A	The MCPTT ID of the invited user
NOTE 1: XML encryption may be done by – element content encryption of the root element <resource-lists> as described in TS 36.579-1 [2], Table 5.5.13.2-1 – element content encryption of (each) <list> element as described in TS 36.579-1 [2], Table 5.5.13.2-1 – attribute URI encryption of the entry’s uri attribute as described in TS 36.579-1 [2], Table 5.5.13.3-1

Table 7.2.3.3-11: SIP INVITE (Step 9, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1
Information Element	Value/remark	Comment	Reference	Condition
Request-Line
Request-URI	tsc_MCPTT_PublicServiceId_A	The public service identity of the controlling MCPTT function
From
addr-spec
user-info and host	px_MCPTT_Client_B_ID
Session-Expires
generic-param	any allowed value	The recommended initial value is 1800 in RFC 4028 [30].
P-Asserted-Identity
addr-spec
user-info and host	px_MCX_SIP_PublicUserId_B_1
Answer-Mode	not present
Message-body
MIME body part		SDP message
MIME-part-body	SDP Message as described in Table 7.2.3.3-11A
MIME body part		MCPTT-INFO
MIME-part-body	MCPTT-Info as described in Table 7.2.3.3-12
MIME body part		Resource-Lists
MIME-part-body	Resource-lists as described in Table 7.2.3.3-10A

Table 7.2.3.3-11A: SDP in SIP INVITE (Table 7.2.3.3-11)

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

Table 7.2.3.3-12: MCPTT-Info in SIP INVITE (Table 7.2.3.3-11)

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
mcptt-calling-user-id	encrypted (NOTE 1) <mcptt-calling-user-id> with mcpttURI set to px_MCPTT_ID_User_B
NOTE 1: Encrypted element as described in TS 36.579-1 [2] Table 5.5.3.2.1-1A

Table 7.2.3.3-12A: SIP 183 (Session Progress) (Step 10, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.16.3.2-1 conditions 100rel, MCPTT

Table 7.2.3.3-13: SIP BYE (Step 23, Table 7.2.3.2-1)

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

Table 7.2.3.3-14: SIP BYE (Step 24, Table 7.2.3.2-1)

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

Table 7.2.3.3-15: SIP ACK (Step 13, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.1.1-1
Information Element	Value/remark	Comment	Reference	Condition
Via
sent-protocol	"SIP/2.0/UDP"
sent-by	"sip:[5555::aaa:bbb:ccc:eed]"	SIP URI with IP address or FQDN and protected server port of UE
	px_MCPTT_Client_B_ID":"protected server port as chosen by the UE
via-branch	"z9hG4bKmcpttss33"
Via
sent-protocol	"SIP/2.0/UDP"
sent-by	px_MCPTT_Server_A_URI
via-branch	"z9hG4bKmcpttss3"
From
addr-spec	px_MCPTT_Client_B_URI
To
addr-spec	px_MCPTT_Server_A_URI

Table 7.2.3.3-16: SIP ACK (Step 14, Table 7.2.3.2-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.1.2-1
Information Element	Value/remark	Comment	Reference	Condition
From
addr-spec	px_MCPTT_Server_B_URI
To
addr-spec	px_MCPTT_Server_A_URI

Table 7.2.3.3-17: Floor Release (Steps 15, 16, Table 7.2.3.2-1)

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

Table 7.2.3.3-18: Void

Table 7.2.3.3-19: Floor Taken (Steps 19, 20, Table 7.2.3.2-1)

Derivation Path: 36.579-1 [2], Table 5.5.6.7-1 condition ON-NETWORK
Information Element	Value/remark	Comment	Condition
Granted Party’s Identity
Granted Party’s Identity	px_MCPTT_ID_User_A

Annex A (informative):
Change history

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
2017-02	RAN5#74	R5-171300	–	–	–	Introduction of TS 36.579-3.	0.0.1
2018-03	RAN5#78	R5-180688	–	–	–	Incorporates changes agreed in: R5-181269 "New MCPTT Server TC 5.1" R5-181270 "New MCPTT Server TC 6.1" R5-181271 "New MCPTT Server TC 7.1" R5-181272 "New MCPTT Server TC 7.2"	0.1.0
2018-03	RAN#79	RP-180128	–	–	–	Draft version for information purposes to the RAN Plenary	1.0.0
2018-05	RAN5#79	R5-182438	–	–	–	Incorporates changes agreed in: R5-182421 R5-183162 R5-182486 R5-182487 R5-182488	2.0.0
2018-06	RAN#80	RP-180655	–	–	–	put under revision control as v13.0.0 with small editorial changes	13.0.0
2018-09	RAN#81	R5-192160	0001	–	F	Update 36.579-3 Typos in Forward and Section 4.1.2	13.1.0
2021-12	RAN#93	R5-217642	0002	–	F	Update of Test Case 5.1 – Authentication Authorization Configuration	13.2.0
2021-12	RAN#93	R5-217972	0003	1	F	Update of Test Case 6.1 – Client-Server Call	13.2.0
2021-12	RAN#93	R5-217973	0004	1	F	Update of Test Case 7.1 – Controlling Server Call	13.2.0
2021-12	RAN#93	R5-217974	0005	1	F	Update of Test Case 7.2 – Participating Server Call	13.2.0