10.1.1 Prearranged group call

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

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

10.1.1.1 General

10.1.1.2 MCPTT client procedures

10.1.1.2.1 On-demand prearranged group call

10.1.1.2.1.1 Client originating procedures

Upon receiving a request from an MCPTT user to establish an MCPTT prearranged group session the MCPTT client shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCPTT client:

1) should indicate to the MCPTT user that calls are not allowed on the indicated group; and

2) shall skip the remainder of this procedure.

The MCPTT client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) if the group identity identifies a temporary group or a group regroup based on preconfigured group,, the <associated-group-id> element set to the MCPTT group ID of a constituent group the MCPTT client is member of;

e) if the MCPTT client is aware of active functional aliases, and an active functional alias is to be included in the initial SIP INVITE request, the <anyExt> element with the <functional-alias-URI> set to the URI of the used functional alias; and

NOTE 3: The MCPTT client is informed about temporary groups regrouping MCPTT groups that the user is a member of as specified in 3GPP TS 24.481 [31]. The MCPTT client is informed about regroups based on a preconfigured group of MCPTT groups that the user is member of and affiliated to as specified in clause 16 of the present document.

NOTE 4: If the MCPTT user selected a TGI or the identity of a group regroup based on a preconfigured group where there are several constituent MCPTT groups where the MCPTT user is a member, the MCPTT client selects one of those MCPTT groups.

NOTE 5: The MCPTT client learns the functional aliases that are activated for an MCPTT ID from procedures specified in clause 9A.2.1.3.

f) if the MCPTT user has requested an application priority, the <anyExt> element with the <user-requested-priority> element set to the user provided value;

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

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

a) if the <allow-location-info-when-talking> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

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

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

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

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

2A) may notify the answer state to the user (i.e. "Unconfirmed" or "Confirmed") if received in the P-Answer-State header field; and

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

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

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

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

the MCPTT client shall perform the actions specified in clause 6.2.8.1.5.

On receiving a SIP INFO request where the Request-URI contains an MCPTT session ID identifying an ongoing group session, the MCPTT client shall follow the actions specified in clause 6.2.8.1.13.

10.1.1.2.1.2 Client terminating procedures

In the procedures in this clause:

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

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

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

The MCPTT client:

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

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

b) the number of the maximum simultaneous MCPTT emergency group calls supported for the specific calling functional alias as specified in the <MaxSimultaneousEmergencyGroupCalls> element within the <FunctionalAliasList> list element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) has been reached; or

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6A) may display to the MCPTT user the functional alias of the inviting MCPTT user;

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

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

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

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

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

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

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

10.1.1.2.1.3 MCPTT upgrade to in-progress emergency or imminent peril

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

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

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

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

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

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

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

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

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

a) shall include an application/vnd.3gpp.mcptt-info+xml MIME body by following the procedures in clause 6.2.8.1.1; and

b) shall include a Resource-Priority header field and comply with the procedures in clause 6.2.8.1.2.

4) if the MCPTT user has requested to upgrade the MCPTT group call to an MCPTT imminent peril call, the MCPTT client:

a) shall include an application/vnd.3gpp.mcptt-info+xml MIME body by following the procedures in clause 6.2.8.1.9; and

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

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

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

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

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

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

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

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

2) shall perform the actions specified in clause 6.2.8.1.4.

On receiving a SIP INFO request where the Request-URI contains an MCPTT session ID identifying an ongoing group session, the MCPTT client shall follow the actions specified in clause 6.2.8.1.13.

On receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP re-INVITE request the MCPTT client shall perform the actions specified in clause 6.2.8.1.5.

10.1.1.2.1.4 MCPTT in-progress emergency cancel

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

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

The MCPTT client:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On receiving a SIP INFO request where the Request-URI contains an MCPTT session ID identifying an ongoing group session, the MCPTT client shall follow the actions specified in clause 6.2.8.1.13.

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

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

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

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

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

10.1.1.2.1.5 MCPTT in-progress imminent peril cancel

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

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

The MCPTT client:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.1.1.2.1.6 MCPTT client receives SIP re-INVITE request

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10) if the SIP re-INVITE request was received within a pre-established session, shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP re-INVITE request according to 3GPP TS 24.229 [4], based upon the parameters already negotiated for the pre-established session;

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

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

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

10.1.1.2.2 Prearranged group call using pre-established session

10.1.1.2.2.1 Client originating procedures

Upon receiving a request from an MCPTT user to establish an MCPTT group session using an MCPTT group identity identifying a prearranged MCPTT group within the pre-established session, the MCPTT client shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCPTT client:

1) should indicate to the MCPTT user that calls are not allowed on the indicated group; and

2) shall skip the remainder of this procedure.

The MCPTT client shall generate a SIP REFER request outside a dialog as specified in IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27], and in accordance with the UE procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client shall follow the procedures specified in clause 10.1.2.2.2.1 with the clarification in step 3) of clause 10.1.2.2.2.1 that:

1) an <entry> element of a <list> element of the <resource-lists> element in the application/resource-lists+xml MIME body shall contain a "uri" attribute set to the prearranged MCPTT group identity;

2) the <session-type> element of the application/vnd.3gpp.mcptt-info MIME body in the hname "body" parameter in the headers portion of the SIP URI shall be set to a value of "prearranged"; and

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

10.1.1.2.2.2 Client terminating procedures

Upon receiving a SIP re-INVITE request within a pre-established session without an associated MCPTT call or when generating SIP responses to the SIP re-INVITE request, the MCPTT client shall follow the procedures in clause 10.1.1.2.1.2.

NOTE: In clause 10.1.1.2.1.2, the reader is assumed to replace occurrences of SIP INVITE request with SIP re-INVITE request.

10.1.1.2.3 End group call

10.1.1.2.3.1 Client originating procedures on-demand

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

10.1.1.2.3.2 Client originating procedures using pre-established session

When an MCPTT client wants to leave the MCPTT call within a pre-established session, the MCPTT client shall follow the procedures as specified in clause 6.2.4.2.

10.1.1.2.3.3 Client terminating procedures

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

10.1.1.2.4 Rejoin procedure

10.1.1.2.4.1 On demand session establishment

Upon receiving a request from an MCPTT user to rejoin an ongoing MCPTT session or triggered by coming back from out of coverage, the MCPTT client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

NOTE: How an MCPTT client is informed whether it comes back from out of coverage is out of scope of present document.

The MCPTT client shall follow the procedures specified in clause 10.1.1.2.1.1 with the clarification in step 10) of clause 10.1.1.2.1.1 that the Request-URI of the SIP INVITE request shall contain a URI of the MCPTT session identity to rejoin.

10.1.1.2.4.2 Pre-established session

Upon receiving a request from an MCPTT user to rejoin an ongoing MCPTT call within the pre-established session or triggered by coming back from out of coverage, the MCPTT client shall generate a SIP REFER request as specified in IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27], and in accordance with the UE procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client shall follow the procedures specified in clause 10.1.1.2.2.1 with the clarification in step 3) of clause 10.1.2.2.2.1 that the Refer-To header field of the SIP REFER request:

1) shall contain a URI of the MCPTT session identity to rejoin; and

2) shall contain a Content-Type header field in the headers portion of the SIP URI containing an application/vnd.3gpp.mcptt-info+xml MIME type of the hname "body" parameter in the headers portion of the SIP URI and the hname "body" parameter in the headers portion of the SIP URI containing the <mcpttinfo> element with the <mcptt-Params> element and with the <session-type> element set to a value of "prearranged".

10.1.1.3 Participating MCPTT function procedures

10.1.1.3.1 Originating procedures

10.1.1.3.1.1 On demand prearranged group call

In the procedures in this clause:

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.

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

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 clause 7.3.

2a) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT function shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

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 clause 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.484 [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 clause 4.4. Otherwise, continue with the rest of the steps;

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

6) if the user identified by the MCPTT ID is not affiliated to the group identified in the <mcptt-request-uri> or in <associated-group-id> element of the "SIP INVITE request for originating participating MCPTT function" as determined by clause 9.2.2.2.11 and this is an authorised request for originating a priority call as determined by clause 6.3.2.1.8.1, shall perform the actions specified in clause 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 (specified in the <MaxAffiliationsN2> element of the <Common> element of the corresponding MCPTT user profile), 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 clause 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.379 [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 clause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to allow an exception to the N2 limit (specified in the <MaxAffiliationsN2> element of the <Common> element of the MCPTT user profile of the served MCPTT ID). Alternatively, a lower priority affiliation of the MCPTT user could be cancelled to allow for the new affiliation.

If the incoming SIP INVITE request does not contain an <associated-group-id> element, then the group identity contained in the <mcptt-request-uri> element is determined not to be a TGI or the identity of a group regroup based on a preconfigured group and the participating MCPTT function:

1) shall determine the public service identity of the controlling MCPTT function associated with the group identity in the SIP INVITE request. If the participating MCPTT function is unable to identify the controlling MCPTT function for the on demand prearranged group call, it shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

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

NOTE 7: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 8: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 9: How the participating MCPTT function determines the public service identity of the controlling MCPTT function associated with the group identity or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 10: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

2) shall generate a SIP INVITE request as specified in clause 6.3.2.1.3;

3) shall set the Request-URI to the public service identity of the controlling MCPTT function determined in step 8;

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

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

6) 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 clause 6.3.2.1.1.1;

6a) if the received SIP request contains a <functional-alias-URI> element of the application/vnd.3gpp.mcptt-info+xml MIME body, then check if the status of the functional alias is activated for the MCPTT ID. If the functional alias status is activated, then set the <functional-alias-URI> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP INVITE request to the received value, if the status is unequal activated then do not include a <functional-alias-URI> element;

NOTE 11: The participating MCPTT server learns the functional alias state for an MCPTT ID from procedures specified in clause 9A.2.2.2.7.

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

8) 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;

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

9) if, according to clause 6.4, the SIP INVITE request is regarded as being received with an implicit request to grant the floor to the originating MCPTT client:

if:

a) the incoming SIP INVITE request contained an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

b) the <allow-location-info-when-talking> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true";

then shall copy the application/vnd.3gpp.mcptt-location-info+xml MIME body from the received SIP INVITE request into the outgoing SIP INVITE request;

otherwise:

if:

a) the participating MCPTT function has the location of the originating MCPTT client available; and

then shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

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

If incoming SIP INVITE request contains an <associated-group-id> element, then the group identity contained in the <mcptt-request-uri> element is determined to be a TGI or the identity of a group regroup based on a preconfigured group and the participating MCPTT function:

1) shall generate a SIP INVITE request as specified in clause 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 clause 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) void;

2) shall generate a SIP 200 (OK) response as in clause 6.3.2.1.5.2 with the clarification that if an <MKFC-GKTPs> element was contained in the received SIP 2xx response it is not included in the generated SIP 200 (OK) response;

NOTE 13: If an <MKFC-GKTPs> element is received in a SIP 2xx response, the participating MCPTT function essentially ignores it and does not forward it, resulting in unicast media plane transmission being used for the originating client.

3) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 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;

6A) shall include the answer state into the P-Answer-State header field of the outgoing SIP 200 (OK) response, if received in the P-Answer-State header field of the incoming SIP 200 (OK) response;

7) if the procedures of clause 9.2.2.2.12 for implicit affiliation were performed in the present clause, shall complete the implicit affiliation by performing the procedures of clause 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 clause 9.2.2.2.12 were invoked in this procedure, shall perform the procedures of clause 9.2.2.2.14.

10.1.1.3.1.2 Prearranged group call using pre-established session

Upon receipt of a "SIP REFER request for a pre-established session", with:

1) the Refer-To header field containing a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [62] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [20] containing an <entry> element with a "uri" attribute containing a SIP URI set to a pre-arranged group identity;

2) an hname "body" parameter in the headers portion of the SIP URI specified above containing an application/vnd.3gpp.mcptt-info MIME body with the <session-type> element set to "prearranged"; and

3) a Content-ID header field set to the "cid" URL;

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 REFER 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] and shall not continue with the rest of the steps;

NOTE 1: If the application/vnd.3gpp.mcptt-info MIME body included in the SIP REFER request as described at the top of the present clause contains an <emergency-ind> element or <imminentperil-ind> element set to a value of "true", and this is an authorised request for originating a priority call as determined by clause 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 REFER request;

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 clause 7.3.

3) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT function shall reject the SIP REFER request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

4) 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 REFER request for pre-established session" with a SIP 403 (Forbidden) response to the SIP REFER request, with warning text set to "109 user not authorised to make prearranged group calls" in a Warning header field as specified in clause 4.4;

NOTE 3: If the SIP REFER 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 clause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to allow for an exception to the limit for the maximum simultaneous MCPTT sessions supported for the MCPTT user.

6) if the "SIP REFER request for a pre-established session" contained a Refer-Sub header field containing "false" value and a Supported header field containing "norefersub" value, shall handle the SIP REFER request as specified in 3GPP TS 24.229 [4], IETF RFC 3515 [25] as updated by IETF RFC 6665 [26], and IETF RFC 4488 [22] without establishing an implicit subscription;

7) if received SIP REFER request includes an application/vnd.3gpp.mcptt-info+xml MIME body with an <emergency-ind> element included or an <imminentperil-ind> element included, shall validate the request as described in clause 6.3.2.1.8.3;

8) if the SIP REFER request contains in the application/vnd.3gpp.mcptt-info+xml MIME body:

a) an <emergency-ind> element set to a value of "true" and this is an unauthorised request for an MCPTT emergency group call as determined by clause 6.3.2.1.8.1;

b) an <alert-ind> element set to a value of "true" and this is an unauthorised request for an MCPTT emergency alert as determined by clause 6.3.2.1.8.2; or

c) an <imminentperil-ind> element set to a value of "true" and this is an unauthorised request for an MCPTT imminent peril group call as determined by clause 6.3.2.1.8.1;

then shall reject the SIP REFER request with a SIP 403 (Forbidden) response and skip the rest of the steps;

9) shall retrieve the group identity within the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body referenced by the "cid" URL contained in the Refer-To header field of the SIP REFER request;

10) shall determine the public service identity of the controlling MCPTT function associated with the group identity within the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element in the application/resource-lists+xml MIME body referenced by the Refer-To header of the SIP REFER request. If the participating MCPTT function is unable to identify the controlling MCPTT function associated with the group identity, it shall reject the REFER request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

NOTE 4: The public service identity can identify the controlling function in the primary MCPTT system or a part in ner MCPTT system.

NOTE 5: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 6: If the controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 7: How the participating MCPTT function determines the public service identity of the controlling MCPTT function associated with the group identity or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 8: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

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

12) if the actions for implicit affiliation specified in step 11) above were performed but not successful in affiliating the MCPTT user due to the MCPTT user already having N2 simultaneous affiliations (specified in the <MaxAffiliationsN2> element of the <Common> element of the corresponding MCPTT user profile), shall reject the SIP REFER request 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 clause 4.4. and skip the rest of the steps.

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

NOTE 10: If the SIP REFER 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 clause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to allow an exception to the N2 limit (specified in the <MaxAffiliationsN2> element of the <Common> element of the MCPTT user profile of the served MCPTT ID). Alternatively, a lower priority affiliation of the MCPTT user could be cancelled to allow for the new affiliation.

13) shall generate a final SIP 200 (OK) response to the "SIP REFER request for a pre-established session" according to 3GPP TS 24.229 [4];

NOTE 11: In accordance with IETF RFC 4488 [22], the participating MCPTT function inserts the Refer-Sub header field containing the value "false" in the SIP 200 (OK) response to the SIP REFER request to indicate that it has not created an implicit subscription.

14) shall send the response to the "SIP REFER request for a pre-established session" towards the MCPTT client according to 3GPP TS 24.229 [4];

15) shall generate a SIP INVITE request as specified in clause 6.3.2.1.4;

16) shall set the Request-URI of the SIP INVITE request to the public service identity determined in step 10;

17) shall copy the group identity from the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body pointed to by the "cid" URL in the Refer-to header field of the SIP REFER request, to the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP INVITE request;

18) if the received SIP REFER request contained a Resource-Priority header field, shall include in the outgoing SIP INVITE request 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 received SIP REFER request from the MCPTT client;

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

18a) if, according to clause 6.4, the SIP REFER request is regarded as being received with an implicit request to grant the floor to the initiating MCPTT client:

if:

a) the incoming SIP REFER request contained an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

then shall copy the application/vnd.3gpp.mcptt-location-info+xml MIME body from the received SIP REFER request into the outgoing SIP INVITE request;

otherwise:

if:

a) the participating MCPTT function has available the location of the initiating MCPTT client; and

then shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

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

Upon receiving SIP provisional responses for the SIP INVITE request the participating MCPTT function:

1) shall discard the received SIP responses without forwarding them.

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

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

2) shall include in the SIP INVITE request an SDP offer based upon the SDP offer negotiated during the pre-established session establishment, any subsequent pre-established session modification and the SDP offer (if any) included in the hname "body" parameter in the headers portion of the SIP URI contained in the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, referenced by the "cid" URL in the Refer-To header field in the incoming SIP REFER request from the MCPTT client; and

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

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

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

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

3) if the received SIP 2xx response was in response to a request for an MCPTT group call containing a Resource-Priority header field populated for an MCPTT emergency group call or MCPTT imminent peril group call as specified in clause 6.3.2.1.8.4 and does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcptt-warn-code set to "149":

a) shall generate a SIP re-INVITE request to be sent towards the MCPTT client within the pre-established session as specified in clause 6.3.2.1.8.5; and

b) shall send the SIP re-INVITE request towards the MCPTT client according to 3GPP TS 24.229 [4].

NOTE 13: There are two cases covered in the handling of the received SIP 2xx response above. The first case is when the SIP INVITE request sent to the controlling MCPTT function contained a Resource-Priority header field populated appropriately to request emergency level or imminent peril level priority but did not contain in the application/vnd.3gpp.mcptt-info+xml MIME body either an <emergency-ind> element or an <imminentperil-ind> element. The second case is when the SIP INVITE request sent to the controlling MCPTT function contained a Resource-Priority header field and contained either an <emergency-ind> element or an <imminentperil-ind> element. In either case, the received SIP 2xx response did not warn of a pending SIP INFO request.

Upon receiving a SIP INFO request from the controlling MCPTT function within the dialog of the SIP INVITE request for an MCPTT emergency call or MCPTT imminent peril call, the participating MCPTT function:

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

2) shall generate a SIP re-INVITE request to be sent towards the MCPTT client within the pre-established session as specified in clause 6.3.2.1.8.5; and

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

NOTE 14: This is the case where the SIP REFER request previously received from the MCPTT client contained a Resource-Priority header field populated for an MCPTT emergency group call or MCPTT imminent peril group call as specified in clause 6.3.2.1.8.4 but was also a request either an MCPTT emergency group call or an MCPTT imminent peril group call.

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

1) if the implicit affiliation procedures of clause 9.2.2.2.12 were invoked in this procedure, shall perform the procedures of clause 9.2.2.2.14; and

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

10.1.1.3.1.3 Reception of a SIP re-INVITE request from served MCPTT client

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

Upon receipt of a SIP re-INVITE request for an MCPTT session identifying an on-demand prearranged MCPTT group session or pre-established session, 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 re-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] and skip the rest of the steps;

NOTE 1: If the SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "true", the participating MCPTT function can choose to accept the request.

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. Otherwise, continue with the rest of the steps;

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

3) shall generate an outgoing SIP re-INVITE request as specified in clause 6.3.2.1.9;

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

5) shall, if the SIP re-INVITE request was received within an on-demand session, include in the SIP re-INVITE request an SDP offer based on the SDP offer in the received SIP re-INVITE request as specified in clause 6.3.2.1.1;

6) shall, if the SIP re-INVITE request was received within a pre-established session, include in the SIP re-INVITE request an SDP offer based upon the previously negotiated SDP for the pre-established session as specified in clause 6.3.2.1.1.2;

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

NOTE 3: The controlling MCPTT function will determine the validity of the Resource-Priority header field.

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

Upon receipt of a SIP 2xx response to the above SIP re-INVITE request in step 7) the participating MCPTT function:

1) shall generate a SIP 200 (OK) response as specified in the clause 6.3.2.1.5.2;

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

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

4) shall copy the contents 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;

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

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

Upon receipt of a SIP 403 (Forbidden) response to the above SIP INVITE request in step 7) the participating MCPTT function:

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

2) shall copy, if included in the received SIP 403 (Forbidden) response, the application/vnd.3gpp.mcptt-info+xml MIME body MIME body to the outgoing SIP (Forbidden) response;

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

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

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

10.1.1.3.2 Terminating Procedures

In the procedures in this clause:

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

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

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

Upon receipt of a "SIP INVITE request for terminating participating MCPTT function", the participating MCPTT function:

NOTE 1: if the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true", the terminating participating MCPTT function can according to local policy choose to accept the request.

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

3) if the Answer-Mode Indication in the application/poc-settings+xml MIME body has not yet been received from the invited MCPTT client as defined in clause 7.3.3 or clause 7.3.4, shall reject the request with a SIP 480 (Temporarily Unavailable) response with the warning text set to "146 T-PF unable to determine the service settings for the called user" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

4) shall use the MCPTT ID present in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request to retrieve the binding between the MCPTT ID and public user identity;

5) if the binding between the MCPTT ID and public user identity does not exist, then the participating MCPTT function shall reject the SIP INVITE request with a SIP 404 (Not Found) response. Otherwise, continue with the rest of the steps;

6) void;

NOTE 2: If an <MKFC-GKTPs> element is received in a SIP INVITE request, the participating MCPTT function essentially ignores it and does not forward it, resulting in unicast media plane transmission being used for the terminating client.

7) shall perform the automatic commencement procedures specified in clause 6.3.2.2.5.1 and according to IETF RFC 5373 [18] if the "SIP INVITE request for terminating participating MCPTT function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as per clause 7.3.3 or clause 7.3.4 is set to "auto-answer"; and

8) shall perform the manual commencement procedures specified in clause 6.3.2.2.6.1 and according to IETF RFC 5373 [18] if the "SIP INVITE request for terminating participating MCPTT function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as per clause 7.3.3 or clause 7.3.4 is set to "manual-answer".

10.1.1.3.3 End group call at the originating participating MCPTT function

10.1.1.3.3.1 Receipt of SIP BYE request for ending group call on-demand

Upon receiving from the MCPTT client a SIP BYE request the participating MCPTT function shall follow the procedures as specified in clause 6.3.2.1.6.

10.1.1.3.3.2 Receipt of SIP REFER "BYE" request for ending group call using pre-established session

Upon receiving from the MCPTT client a SIP REFER request when using a pre-established session with the "method" SIP URI parameter set to value "BYE" in the URI in the Refer-To header field the participating MCPTT function shall follow the procedures as specified in clause 6.3.2.1.7.

10.1.1.3.4 End group call at the terminating participating MCPTT function

10.1.1.3.4.1 Receipt of SIP BYE request for private call on-demand

Upon receiving a SIP BYE request from the controlling MCPTT function, the participating MCPTT function shall follow the procedures as specified in clause 6.3.2.2.8.1.

10.1.1.3.4.2 Receipt of SIP BYE request when ongoing pre-established session

Upon receiving a SIP BYE request from the controlling MCPTT function and if the MCPTT session id refers to an MCPTT user that has a pre-established session with the participating MCPTT function, the participating MCPTT function shall follow the procedures as specified in clause 6.3.2.2.8.2.

10.1.1.3.5 Rejoin procedures

10.1.1.3.5.1 Originating procedures – on demand prearranged group call

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 shall follow the procedures specified in clause 10.1.1.3.1.1 with the clarification in step 10) of clause 10.1.1.3.1.1 that the Request-URI of the SIP INVITE request shall contain a URI of the MCPTT session identity which mapped to the MCPTT session identity provided in Request-URI of the "SIP INVITE request for originating participating MCPTT function".

10.1.1.3.5.2 Originating procedures – prearranged group call using pre-established session

Upon receipt of a "SIP REFER request for a pre-established session", with the Refer-To header containing an application/vnd.3gpp.mcptt-info+xml MIME type content in an hname "body" parameter in the headers portion of the SIP URI and with the <session-type> element set to "prearranged" the participating MCPTT function shall follow the procedures specified in clause 10.1.1.3.1.2 with the clarification in step 16) of clause 10.1.1.3.1.2 that the Request-URI of the SIP INVITE request shall contain a URI of the MCPTT session identity which mapped to the MCPTT session identity provided in the Refer-to header field of the "SIP REFER request for a pre-established session".

10.1.1.3.6 Reception of a SIP re-INVITE request for terminating MCPTT client for priority call

In the procedures in this clause:

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

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

Upon receipt of a SIP re-INVITE request for a terminating MCPTT client of a MCPTT group containing an emergency indication or imminent peril indication, the participating MCPTT function:

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

2) shall generate an outgoing SIP re-INVITE request as specified in clause 6.3.2.2.10;

3) shall include in the SIP re-INVITE request an SDP offer based on the SDP offer in the received SIP re-INVITE request as specified in clause 6.3.2.2.1; and

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

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

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

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

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

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

10.1.1.4 Controlling MCPTT function procedures

10.1.1.4.1 Originating Procedures

10.1.1.4.1.1 INVITE targeted to an MCPTT client

This clause 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 clause 10.1.1.4.2 or as the result of receiving a SIP 403 (Forbidden) response as described in this clause.

The controlling MCPTT function:

1) shall generate a SIP INVITE request as specified in clause 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: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 2: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 3: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 4: How the controlling MCPTT function determines the public service identity of the terminating participating MCPTT function associated with the MCPTT user to be invited or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 5: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

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 6: The <mcptt-calling-user-id> is already included in the MIME body as a result of calling clause 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 clause 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 clause 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 clause 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 clause 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 clause 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) void

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

2) shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in clause 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 7: 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 8: The procedures executed by the controlling MCPTT function prior to sending a response to the inviting MCPTT client are specified in clause 10.1.1.4.2.

10.1.1.4.1.2 INVITE targeted to the non-controlling MCPTT function of an MCPTT group

The controlling MCPTT function:

1) shall generate a SIP INVITE request as specified in clause 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;

NOTE 1: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 2: If the non-controlling MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 3: How the controlling MCPTT function determines the public service identity of the non-controlling MCPTT function serving the MCPTT group or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 4: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

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

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 clause 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 5: 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.379 [3] clause 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.481 [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 6: 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 clause 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] clause 6.3;

NOTE 7: The procedures executed by the controlling MCPTT function prior to sending a response to the inviting MCPTT client are specified in clause 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 clause 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] clause 6.3.

10.1.1.4.2 Terminating Procedures

In the procedures in this clause:

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:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP INVITE request with a SIP 500 (Server Internal Error) response. The controlling MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and skip 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 an MCPTT emergency group call as determined by clause 6.3.3.1.13.2, or for originating an MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5, the controlling MCPTT function can according to local policy choose to accept the request.

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;

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

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

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

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

5) if the group identity is associated with a group document maintained by the GMS:

NOTE 2: How the MCPTT server determines that a group identity represents a group for which a group document is stored in the GMS is an implementation detail.

a) 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 clause 6.3.5.2;

a1) if the group document contains a <list -service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "167 call is not allowed on the preconfigured group" as specified in clause 4.4 "Warning header field" and skip the rest of the steps;

b) if the group referred to by the group identity has been regrouped, shall:

i) stop processing the SIP INVITE request;

ii) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "148 group is regrouped" as specified in clause 4.4 "Warning header field";

iii) if the group referred to by the group identity has been regrouped based on a preconfigured group, shall send a copy of the notifying SIP MESSAGE that was generated and sent per clause 16.2.4.1 to the participating function for the MCPTT ID of the incoming SIP INVITE request; and

iv) skip the rest of the steps;

c) if the result of the initial processing in clause 6.3.5.2 was that a SIP 4xx, 5xx or 6xx response to the "SIP INVITE request for controlling MCPTT function of an MCPTT group" has been sent, do not continue with the rest of the steps in this clause;

6) if the group identity is associated with a user or group regroup based on a preconfigured group:

a) shall retrieve the stored information for the group identity;

b) if there is no stored information for the group identity, the controlling MCPTT function:

i) shall return a SIP 404 (Not Found) response with the warning text set to "163 the group identity indicated in the request does not exist" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps;

NOTE 3: The user or group regroup can have been removed very recently and the client has sent the group call request prior to receiving the removal notification.

6a) if the group identity is associated with a TGI or the identity of a group regroup based a preconfigured group and the received SIP INVITE request does not include an <mcptt-calling-group-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body, shall return a SIP 403 (Forbidden) response to "SIP INVITE request for controlling MCPTT function of an MCPTT group".

NOTE 4: This is the case where the MCPTT client has requested the setup of a regroup without including the identity of the constituent group, leading to the participating MCPTT function forwarding the SIP INVITE directly to the controlling MCPTT function. This is not allowed, since the originating client is required to include the identity of the constituent group.

7) shall perform the actions as described in clause 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;

10) if the SIP INVITE request contains an unauthorised request for an MCPTT emergency group call as determined by clause 6.3.3.1.13.2:

a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response as specified in clause 6.3.3.1.14; and

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

11) if the SIP INVITE request contains an unauthorised request for an MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

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

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

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

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

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

13) if the received SIP INVITE request contains an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element, the controlling MCPTT function can remember the location information contained in the <location-info> root element;

14) 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 <mcptt-request-uri> element of the SIP INVITE request as specified in clause 6.3.6;

ii) the group identity contained in an <mcptt-calling-group-id> element of the SIP INVITE request is not a constituent MCPTT group ID;

NOTE 5: If the SIP INVITE is for a temporary group or a group regroup based on preconfigured group, the affiliation of the calling user to the constituent group has been assured by the non-controlling MCPTT function of the constituent group before forwarding this SIP INVITE to the controlling function of the regroup.

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 clause 6.3.3.1.13.2 or MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCPTT user identified in the <mcptt-calling-user-id> of the SIP INVITE is determined to not be eligible for implicit affiliation as specified in clause 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 clause 4.4, and skip the rest of the steps below;

b) if the user identified by the MCPTT ID is not authorised to initiate the prearranged group session as specified in clause 6.3.5.4, shall send a SIP 403 (Forbidden) response with the warning text set to: "119 user is not authorised to initiate the group call" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below;

c) if the received SIP INVITE request contains an authorised request for an MCPTT emergency group call as determined by clause 6.3.3.1.13.2 or MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCPTT user is eligible to be implicitly affiliated with the MCPTT group as determined in step 14) a) iv) above, shall perform the implicit affiliation as specified in clause 9.2.2.3.7;

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

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 clause 6.3.3.5;

f) if the group identity in the "SIP INVITE request for controlling MCPTT function of an MCPTT group" is a TGI or the identity of a group regroup based on a preconfigured group:

i) shall, for each of the constituent MCPTT groups except for the calling MCPTT group identified in the <mcptt-calling-group-id> element of the incoming SIP INVITE, generate a SIP INVITE request towards the MCPTT server that owns the constituent MCPTT group identity by following the procedures in clause 10.1.1.4.1.2; and

NOTE 6: The MCPTT server that the SIP INVITE request is sent to acts as a non-controlling MCPTT function;

ii) shall send the SIP 200 (OK) response towards the inviting non-controlling MCPTT function according to 3GPP TS 24.229 [4];

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 clause 6.3.5.5. If:

A) the number of affiliated members of the MCPTT group is lower than the value contained in the <on-network-minimum-number-of-affiliated-members> element of the group document as specified in 3GPP TS 24.481 [31]; or

B) the group document contains any <on-network-affiliation-to-group-required> group member as specified in 3GPP TS 24.481 [31] that is not affiliated;

then the controlling MCPTT function shall send a SIP 480 (Temporarily Unavailable) response to the MCPTT client that originated the group session with the warning text set to "112 group call abandoned due to required group members not part of the group session" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below;

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

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

A) shall cache the information that the MCPTT user has initiated an MCPTT emergency call;

B) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCPTT emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall cache the information that the MCPTT user has initiated an MCPTT emergency alert; and

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

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

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

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

A) shall cache the information that the MCPTT user has initiated an MCPTT imminent peril call; and

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

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

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

15) if the MCPTT group call is ongoing then:

a) if:

i) the user identified by the MCPTT ID in the SIP INVITE request is not affiliated to the group identity contained in the <mcptt-request-uri> element of the SIP INVITE request as specified in clause 6.3.6;

ii) the group identity contained in an <mcptt-calling-group-id> element of 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 clause 6.3.3.1.13.2 or MCPTT imminent peril group call as determined clause 6.3.3.1.13.5 and is determined to not be eligible for implicit affiliation as specified in clause 9.2.2.3.6;

b) if the user identified by the MCPTT ID in the SIP INVITE request is not authorised to join the prearranged group session as specified in clause 6.3.5.3, shall send a SIP 403 (Forbidden) response with the warning text set to "121 user is not authorised to join the group call" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below;

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

d) if <on-network-max-participant-count> as specified in 3GPP TS 24.481 [31] is already reached:

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

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

ii) shall return a SIP 486 (Busy Here) response with the warning text set to "122 too many participants" to the originating network as specified in clause 4.4 and skip the rest of the steps;

e) if the received SIP INVITE request contains an authorised request for an MCPTT emergency group call as determined by clause 6.3.3.1.13.2 or MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCPTT user is eligible to be implicitly affiliated with the MCPTT group as determined in step 15) a) iv) above, shall perform the implicit affiliation as specified in clause 9.2.2.3.7;

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

i) shall cache the information that the MCPTT user has initiated an MCPTT emergency call;

ii) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCPTT emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall cache the information that the MCPTT user has initiated an MCPTT emergency alert;

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

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

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

C) shall generate SIP re-INVITE requests for the MCPTT emergency group call to the other call participants of the MCPTT group as specified in clause 6.3.3.1.6; and

D) shall send the SIP re-INVITEs towards the other participants of the MCPTT group call;

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

A) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCPTT user’s emergency indication as specified in clause 6.3.3.1.11, setting the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "true"; and

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

v) upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCPTT function shall interact with the media plane as specified in 3GPP TS 24.380 [5];

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

i) shall cache the information that the MCPTT user has initiated an MCPTT imminent peril call; and

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

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

B) shall generate SIP re-INVITE requests for the MCPTT imminent peril group call to the other call participants of the MCPTT group as specified in clause 6.3.3.1.15;

C) shall send the SIP re-INVITEs towards the other participants of the MCPTT group call; and

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

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

A) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCPTT user’s imminent peril indication as specified in clause 6.3.3.1.11, setting the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "true"; and

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

h) shall generate a SIP 200 (OK) response as specified in the clause 6.3.3.2.3.2;

i) 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 clause 6.3.3.2.1;

j) shall include in the SIP 200 (OK) response with the warning text set to "123 MCPTT session already exists" as specified in clause 4.4;

k) if the received SIP re-INVITE request contains an alert indication set to a value of "true" and this is an unauthorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

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

NOTE 8: In this case, the request was for an imminent peril call but a higher priority MCPTT emergency call was already in progress on the group. Hence, the imminent peril call request aspect of the request is denied but the request is granted with emergency level priority.

m) shall interact with media plane as specified in 3GPP TS 24.380 [5] clause 6.3;

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

n) shall send the SIP 200 (OK) response towards the inviting MCPTT client or inviting non-controlling MCPTT function according to 3GPP TS 24.229 [4];

o) shall generate a notification to the MCPTT clients, which have subscribed to the conference event package that the inviting MCPTT User has joined in the MCPTT group call, as specified in clause 6.3.3.4;

NOTE 10: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

p) shall send a SIP NOTIFY request to each MCPTT client according to 3GPP TS 24.229 [4];

q) Upon receiving a SIP ACK to the above SIP 200 (OK) response and the SIP 200 (OK) response contained a Warning header field as specified in clause 4.4 with the warning text containing the mcptt-warn-code set to "149", shall follow the procedures in clause 6.3.3.1.18; and

r) shall not continue with the rest of the clause.

Upon receiving a SIP 183 (Session Progress) response to the SIP INVITE request specified in clause 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 clause 6.3.3.2.3.2;

2) shall include the warning text set to "122 too many participants" as specified in clause 4,4 in the SIP 200 (OK) response, if the prearranged MCPTT group has more than <on-network-max-participant-count> members as specified in 3GPP TS 24.481 [31];

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 clause 6.3.3.2.1;

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

5) if the SIP INVITE request contains an alert indication set to a value of "true" and this is an unauthorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

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

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

NOTE 11: 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];

9) shall generate a notification to the MCPTT clients, which have subscribed to the conference event package that the inviting MCPTT User has joined in the MCPTT group call, as specified in clause 6.3.3.4; and

NOTE 12: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

10) shall send a SIP NOTIFY request to each MCPTT client according to 3GPP TS 24.229 [4].

Upon receiving a SIP 183 (Session Progress) response for a SIP INVITE request as specified in clause 10.1.1.4.1.2 containing an indication of required group members, the timer TNG1 (acknowledged call setup timer) is running and all SIP 200 (OK) responses have been received to all SIP INVITE requests sent to MCPTT clients specified in clause 10.1.1.4.1.1, then the controlling MCPTT function shall wait until the SIP 200 (OK) response has been received to the SIP INVITE request specified in clause 10.1.1.4.1.2 before generating a SIP 200 (OK) response to the "SIP INVITE request for controlling MCPTT function of an MCPTT group".

Upon receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 10.1.1.4.1 that was sent to an affiliated and <on-network-required> group member as specified in 3GPP TS 24.481 [31]; and

1) if the MCPTT ID in the SIP 200 (OK) response matches to the MCPTT ID in the corresponding SIP INVITE request;

2) there are no outstanding SIP 200 (OK) responses to SIP INVITE requests which were sent to affiliated and <on-network-required> group members as specified in 3GPP TS 24.481 [31]; and

3) there is no outstanding SIP 200 (OK) response to a SIP INVITE request sent in clause 10.1.1.4.1.2 where the SIP 183 (Session Progress) response contained an indication of required group members;

the controlling MCPTT function:

1) shall stop timer TNG1 (acknowledged call setup timer) as described in clause 6.3.3.3;

2) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.3.2.3.2 before continuing with the rest of the steps;

3) shall include the warning text set to "122 too many participants" as specified in clause 4.4 in the SIP 200 (OK) response, if all members were not invited because the prearranged MCPTT group has been exceeded the <on-network-max-participant-count> members as specified in 3GPP TS 24.481 [31];

4) 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 clause 6.3.3.2.1;

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

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

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

7) shall generate a notification to the MCPTT clients, which have subscribed to the conference event package that the inviting MCPTT user has joined in the MCPTT group call, as specified in clause 6.3.3.4; and

NOTE 14: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

8) shall send the SIP NOTIFY request to the MCPTT clients according to 3GPP TS 24.229 [4].

Upon:

1) receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 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 clause 6.3.3.2.3;

2) shall include the warning text set to "122 too many participants" as specified in clause 4.4 in the SIP 200 (OK) response, if all members were not invited because the prearranged MCPTT group has exceeded the <max-participant-count> members as specified in 3GPP TS 24.481 [31];

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 clause 6.3.3.2.1;

4) if the SIP INVITE request contains an alert indication set to a value of "true" and this is an unauthorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

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

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

NOTE 15: 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];

8) shall generate a notification to the MCPTT clients, which have subscribed to the conference event package that the inviting MCPTT user has joined in the MCPTT group call, as specified in clause 6.3.3.4; and

NOTE 16: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

9) shall send the SIP NOTIFY request to the MCPTT clients according to 3GPP TS 24.229 [4].

Upon expiry of timer TNG1 (acknowledged call setup timer), if there are outstanding SIP 200 (OK) responses to SIP INVITE requests sent to affiliated and <on-network-required> group members as specified in 3GPP TS 24.481 [31], the controlling MCPTT function shall follow the procedures specified in clause 6.3.3.3.

If timer TNG1 (acknowledged call setup timer) is running and a final SIP 4xx, 5xx or 6xx response is received from an affiliated and <on-network-required> group member as specified in 3GPP TS 24.481 [31], the controlling MCPTT function shall follow the relevant procedures specified in clause 6.3.3.3.

If:

1) timer TNG1 (acknowledged call setup timer) is not running;

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

3) a final SIP 4xx, 5xx or 6xx response is received from an invited MCPTT client;

then the controlling MCPTT function shall perform one of the following based on policy:

1) send the SIP final response towards the inviting MCPTT client, according to 3GPP TS 24.229 [4], if a SIP final response was received from all the other invited MCPTT clients and the SIP 200 (OK) response is not yet sent; or

2) remove the invited MCPTT client from the MCPTT Session as specified in clause 6.3.3.1.5, if a SIP final response other than 2xx or 3xx was received from all the invited MCPTT clients and the SIP 200 (OK) response is already sent. The controlling MCPTT function may invite an additional member of the prearranged MCPTT group as specified in clause 10.1.1.4.1 that has not already been invited, if the prearranged MCPTT group has more than <on-network-max-participant-count> members as specified in 3GPP TS 24.481 [31], and all members have not yet been invited.

If the group identity in the "SIP INVITE request for controlling MCPTT function of an MCPTT group" is a TGI or the identity of a group regroup based on a preconfigured group and constituent MCPTT groups were invited as specified in clause 10.1.1.4.1.2 and,

1) if all non-controlling MCPTT functions hosting the constituent MCPTT groups have responded with a SIP 2xx, SIP 3xx, SIP 4xx, SIP 5xx or SIP 6xx responses to the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group"; and

2) if all expected SIP INFO requests containing a floor request are received;

then the controlling MCPTT function shall indicate to the media plane that all final responses are received.

NOTE 17: If the SIP 200 (OK) response to the SIP INVITE request for non-controlling MCPTT function of an MCPTT group included the application/vnd.3gpp.mcptt-info+xml MIME body with the <floor-state> element set to "floor-taken", the controlling MCPTT function expects that the non-controlling MCPTT functions sends a SIP INFO request containing a floor request.

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

10.1.1.4.3 End group call at the terminating controlling MCPTT function

Upon receiving a SIP BYE request the controlling MCPTT function shall follow the procedures as specified in clause 6.3.3.2.4.

10.1.1.4.4 End group call initiated by the controlling MCPTT function

10.1.1.4.4.1 General

This clause describes the procedures of each functional entity for ending the group call initiated by the controlling MCPTT function.

10.1.1.4.4.2 SIP BYE request for releasing MCPTT session for a group call

When the MCPTT session for group call needs to be released as specified in clause 6.3.8.1, the controlling MCPTT function shall follow the procedures in clause 6.3.3.1.5.

10.1.1.4.4.3 SIP BYE request toward a MCPTT client

When an MCPTT client needs to be removed from the MCPTT session (e.g. due to de-affiliation or admitting a higher priority user), the controlling MCPTT function shall follow the procedures in clause 6.3.3.1.5.

After successful removing the MCPTT client from the MCPTT session, the controlling MCPTT function may generate a notification to the MCPTT clients, which have subscribed to the conference event package that an MCPTT user has been removed from the MCPTT session, as specified in clause 6.3.3.4 and send the SIP NOTIFY request to the MCPTT client according to 3GPP TS 24.229 [4].

10.1.1.4.5 Rejoin procedures

10.1.1.4.5.1 Terminating procedures

Upon receipt of a SIP INVITE request that includes an MCPTT session identity of an ongoing MCPTT session in the Request-URI the controlling MCPTT function:

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 an MCPTT emergency group call as determined by clause 6.3.3.1.13.2, or for originating an MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5, the controlling MCPTT function can according to local policy choose to accept the request.

2) shall reject the SIP request with a SIP 404 (Not Found) response if the MCPTT group call represented by the MCPTT session identity in Request-URI is not present;

3) 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. Otherwise, continue with the rest of the steps;

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

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

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

5) shall determine the MCPTT ID of the calling user;

6) if the user identified by the MCPTT ID is not authorised to join the prearranged group session as specified in clause 6.3.5.3, shall send a SIP 403 (Forbidden) response with the warning text set to "121 user is not authorised to join the group call" in a Warning header field as specified in clause 4.4. Otherwise continue with the rest of the steps below;

7) shall perform the actions on receipt of an initial SIP INVITE request as described in clause 6.3.3.2.2;

8) if the user identified by the MCPTT ID is not affiliated to the MCPTT group ID associated with the MCPTT session identity as specified in clause 6.3.6, 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 clause 4.4;

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

10) if <on-network-max-participant-count> as specified in 3GPP TS 24.481 [31] is already reached:

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

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

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

11) shall generate a SIP 200 (OK) response as specified in the clause 6.3.3.2.3.2;

12) 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 clause 6.3.3.2.1;

13) shall interact with media plane as specified in 3GPP TS 24.380 [5] clause 6.3;

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

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

15) shall generate a notification to the MCPTT clients, which have subscribed to the conference event package that the inviting MCPTT User has joined in the MCPTT group call, as specified in clause 6.3.3.4; and

NOTE 4: As a group document can potentially have a large content, the controlling MCPTT function can notify using content-indirection as defined in IETF RFC 4483 [32].

16) shall send a SIP NOTIFY request to each MCPTT client according to 3GPP TS 24.229 [4].

10.1.1.4.6 Late call entry initiated by controlling MCPTT function

When controlling MCPTT function is notified that an MCPTT client is newly affiliated or comes back from out of coverage, the controlling MCPTT function shall invite the MCPTT client to join an ongoing MCPTT group call by following the procedures specified in clause 10.1.1.4.1.

NOTE: How the MCPTT function is informed when an MCPTT client is coming back from out of coverage is out of scope of present document.

10.1.1.4.7 Receipt of a SIP re-INVITE request

In the procedures in this clause:

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

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

Upon receipt of a SIP re-INVITE request for an MCPTT session identity identifying an on-demand prearranged MCPTT group session, the controlling 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 re-INVITE request with a SIP 500 (Server Internal Error) response. The controlling MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and skip the rest of the steps;

NOTE 1: If the SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "true", the controlling MCPTT function can choose to accept the request.

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

3) if the received SIP re-INVITE request contains an unauthorised request to initiate an MCPTT emergency call as determined by clause 6.3.3.1.13.2:

a) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response as specified in clause 6.3.3.1.14; and

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

4) if the received SIP re-INVITE request contains an imminent peril indication set to "true" for an MCPTT imminent peril group call and this is an unauthorised request for an MCPTT imminent peril group call as determined by clause 6.3.3.1.13.6, shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

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

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

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

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

6) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "true" and is an authorised request to initiate an MCPTT emergency group call as determined by clause 6.3.3.1.13.2, the controlling MCPTT function:

a) shall cache the MCPTT ID of the MCPTT user that has initiated an MCPTT emergency call i.e the group in-progress emergency state;

b) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCPTT emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall cache the MCPTT ID of the MCPTT user that has initiated an MCPTT emergency alert;

c) if the in-progress emergency state of the group is set to a value of "true" and another MCPTT user is indicating a new emergency indication:

i) for each of the other affiliated members of the group:

A) shall generate a SIP MESSAGE request notification of the MCPTT user’s emergency indication as specified in clause 6.3.3.1.11;

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

C) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-calling-user-id> element set to the value of the <mcptt-calling-user-id> element in the received SIP re-INVITE request; and

D) if indicated above in step 6) b), shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "true"; and

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

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

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

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

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

NOTE 2: The interactions of TNG2 with the TNG3 (group call timer) are explained in clause 6.3.3.5.2.

iii) shall generate SIP re-INVITE requests for the MCPTT emergency group call to the other participants of the MCPTT group call as specified in clause 6.3.3.1.6;

iv) shall send the SIP re-INVITEs towards the other participants of the MCPTT group call;

v) for each of other affiliated members of the group that are not participating in the call:

A) shall generate a SIP MESSAGE request notification of the MCPTT user’s emergency indication as specified in clause 6.3.3.1.11;

B) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-calling-user-id> element set to the value of the <mcptt-calling-user-id> element in the received SIP re-INVITE request;

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

D) if indicated above in step 6) b), shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "true"; and

E) send the SIP MESSAGE request according to 3GPP TS 24.229 [4]; and

vi) upon receiving a SIP 200 (OK) response to the SIP re-INVITE request the controlling MCPTT function shall interact with the media plane as specified in 3GPP TS 24.380 [5];

7) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "false" and is an unauthorised request for an MCPTT emergency group call cancellation as determined by clause 6.3.3.1.13.4:

a) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response;

b) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcptt-info+xml MIME body as specified in annex F.1 with an <emergency-ind> element set to a value of "true";

c) if an <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body is included in the SIP re-INVITE request set to "false", and there is an outstanding MCPTT emergency alert for the MCPTT user, shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <alert-ind> element set to a value of "true"; and

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

7a) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "false" and is an authorised request for an MCPTT emergency group call cancellation as determined by clause 6.3.3.1.13.4 and if another user is in emergency state and is transmitting media as determined by interacting with the media plane as specified in 3GPP TS 24.380:

a) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response;

b) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcptt-info+xml MIME body as specified in annex F.1 with an <emergency-ind> element set to a value of "true";

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

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

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

b) shall clear the cache of the MCPTT ID of the MCPTT users having an outstanding MCPTT emergency group call;

c) if an <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body is included and set to "false" and is determined to be an authorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3 and there is an outstanding MCPTT emergency alert for the MCPTT user shall:

i) if the received SIP re-INVITE request contains an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, clear the cache of the MCPTT ID of the MCPTT user identified by the <originated-by> element as having an outstanding MCPTT emergency alert; or

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

d) shall generate SIP re-INVITE requests to the participants in the group call as specified in clause 6.3.3.1.6. The MCPTT controlling function:

i) for each of the other participants in the group call shall send the SIP re-INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

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

NOTE 3: Clause 6.3.3.1.6 will inform the group call participants of the cancellation of the MCPTT group’s in-progress emergency state and the cancellation of the MCPTT emergency alert if applicable.

e) shall stop timer TNG2 (in-progress emergency group call timer); and

NOTE 4: The interactions of TNG2 with the TNG3 (group call timer) are explained in clause 6.3.3.5.2;

f) for each of the affiliated members of the group that are not participating in the call:

i) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s emergency call as specified in clause 6.3.3.1.11;

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

iii) if indicated above in step 8) c), set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "false"; and

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

9) if the received SIP re-INVITE request contains an imminent peril indication and the in-progress emergency group state of the group is set to a value of "false", shall perform the procedures specified in clause 10.1.1.4.8 and skip the rest of the steps.

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

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

2) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [4] with the clarifications specified in clause 6.3.3.2.1;

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

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

5) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "true" and if this is an unauthorised request for an MCPTT emergency alert as determined by clause 6.3.3.1.13.1, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

6) if the received SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "false" and if this is an unauthorised request for an MCPTT emergency alert cancellation as determined by clause 6.3.3.1.13.3, shall include in the SIP 200 (OK) response the warning text set to "149 SIP INFO request pending" in a Warning header field as specified in clause 4.4;

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

NOTE 5: In this case, the request was for an imminent peril call but a higher priority MCPTT emergency call was already in progress on the group. Hence, the imminent peril call request aspect of the request is denied but the request is granted with emergency level priority.

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

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

Upon receipt of a SIP 2xx response for an outgoing SIP MESSAGE request, shall handle according to 3GPP TS 24.229 [4].

10.1.1.4.8 Handling of a SIP re-INVITE request for imminent peril session

This procedure is initiated by the controlling MCPTT function as the result of an action in clause 10.1.1.4.7.

In the procedures in this clause:

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

When the controlling function receives a SIP re-INVITE request with an imminent peril indication set to "true", the controlling function:

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

NOTE: 1 The calling procedure has already determined that this is not an unauthorised request for an MCPTT imminent peril call, therefore that check does not need to be repeated in the current procedure.

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

i) for each of the other affiliated member of the group generate a SIP MESSAGE request notification of the MCPTT user’s imminent peril indication as specified in clause 6.3.3.1.11 with the following clarifications;

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

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

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

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

ii) generate SIP re-INVITE requests for the MCPTT imminent peril group call to participants in the MCPTT group call as specified in clause 6.3.3.1.15;

iii) send the SIP re-INVITES to all of the other participants in the MCPTT group call;

iv) for each of the affiliated members of the group not participating in the group call, generate a SIP MESSAGE request notification of the MCPTT user’s imminent peril indication as specified in clause 6.3.3.1.11 with the following clarifications;

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

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

c) cache the information that the MCPTT user has initiated an MCPTT imminent peril call;

2) if the SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <imminentperil-ind> element set to a value of "false" and is an unauthorised request for an MCPTT imminent peril group call cancellation as determined by clause 6.3.3.1.13.6 shall:

a) reject the SIP re-INVITE request with a SIP 403 (Forbidden) response to the SIP re-INVITE request; and

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

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

d) skip the rest of the steps;

3) if the SIP re-INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <imminentperil-ind> element set to a value of "false" and is determined to be an authorised request for an MCPTT imminent peril call cancellation as specified in clause 6.3.3.1.13.6 and the in-progress imminent peril state of the group to is set to a value of "true" the controlling MCPTT function shall:

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

b) cache the information that the MCPTT user no longer has an outstanding MCPTT imminent peril group call;

c) generate SIP re-INVITES requests to the other participants in the MCPTT group call as specified in clause 6.3.3.1.15. The MCPTT controlling function:

i) for each participant shall send the SIP re-INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

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

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

d) for each of the affiliated members of the group not participating in the call shall:

i) generate a SIP MESSAGE request notification of the cancellation of the MCPTT user’s imminent peril call as specified in clause 6.3.3.1.11;

ii) set the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "false"; and

iii) send the SIP MESSAGE request according to 3GPP TS 24.229 [4];

4) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [4] with the clarifications specified in clause 6.3.3.2.1;

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

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

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

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

Upon receipt of a SIP 2xx response for an outgoing SIP MESSAGE request, shall handle according to 3GPP TS 24.229 [4].

10.1.1.5 Non-controlling function of an MCPTT group procedures

10.1.1.5.1 Originating procedures

This clause describes the procedures for inviting an MCPTT user to an MCPTT session. The procedure is initiated by the non-controlling MCPTT function of an MCPTT group as the result of an action in clause 10.1.1.5.2 or clause 10.1.1.5.5.

The non-controlling MCPTT function:

1) shall invite the MCPTT clients as specified in clause 6.3.4.1.2;

2) shall include in each SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the controlling MCPTT function according to the procedures specified in clause 6.3.4.1.1; and

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

For each SIP 183 (Session Progress) response received to each SIP INVITE request sent to an MCPTT client, the non-controlling MCPTT function of an MCPTT group:

1) For each SIP 183 (Session Progress) response containing the option tag "100rel", shall send a SIP PRACK request towards the MCPTT client according to 3GPP TS 24.229 [4]; and

2) shall cache the received response;

For each SIP 200 (OK) response received to each SIP INVITE request sent to an MCPTT client, the non-controlling MCPTT function of an MCPTT group:

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

2) shall cache the SIP 200 (OK) response;

3) shall start the SIP session timer according to rules and procedures of IETF RFC 4028 [7]; and

4) if at least one of the participants has subscribed to the conference event package, shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in clause 10.1.3.5.2.

On receipt of a SIP 3xx, 4xx, 5xx or 6xx response from an invited MCPTT client, the non-controlling MCPTT function of an MCPTT group:

1) shall send an SIP ACK request towards the MCPTT client as specified in 3GPP TS 24.229 [4];

2) shall remove the cached provisional responses received from the MCPTT client, if any cached provisional responses exists; and

3) if the procedures are initiated by the receipt of the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" as specified in clause 10.1.1.5.2, shall cache the SIP 3xx, 4xx, 5xx or 6xx response.

10.1.1.5.2 Terminating procedures

10.1.1.5.2.1 General

When receiving the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" the MCPTT server can be acting as a controller MCPTT function in an ongoing prearranged group call or, if an prearranged group call is not ongoing, be initiated as an non-controlling MCPTT function and invite MCPTT users.

If a prearranged group call is not ongoing the MCPTT server shall perform the actions specified in clause 10.1.1.5.2.2.

If the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" is received when a prearranged group call is ongoing, the controlling MCPTT function may switch from operating in a controlling MCPTT function mode to operate in a non-controlling MCPTT function mode as specified in clause 10.1.1.5.2.3.

When operating in the non-controlling mode and a SIP BYE request is received from the controlling MCPTT function, the non-controlling MCPTT function shall change from operating in the non-controlling mode to operating in the controlling mode as specified in clause 10.1.1.5.2.4.

10.1.1.5.2.2 Initiating a prearranged group call

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

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

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

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

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

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

5) if a trusted mutual aid relationship exists between the partner MCPTT system and the primary MCPTT system and the procedure in 3GPP TS 23.379 [3] clause 10.6.2.4.2 is supported:

a) shall generate a SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [4];

b) shall retrieve the group members of the prearranged group identified by the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request, as specified in clause 6.3.5.2;

c) if the retrieval of group members was successful shall include a P-Refused-URI-List header field populated with affiliated members of the prearranged group in accordance with the IETF RFC 5318 [36]:

d) if the retrieval of group members was not successful, shall include the warning text set to "128 isfocus already assigned" in a Warning header field as specified in clause 4.4; and

e) shall send the SIP 403 (Forbidden) response towards the controlling MCPTT function as specified in 3GPP TS 24.229 [4]; and

f) shall not process the remaining steps;

6) shall retrieve the group document from the group management server for the MCPTT group ID contained in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request and carry out initial processing as specified in clause 6.3.5.2 and continue with the rest of the steps if the checks in clause 6.3.5.2 succeed;

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

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

9) determine the members to invite to the prearranged MCPTT group call as specified in clause 6.3.5.5;

10) if the group document retrieved from the group management server contains <on-network-required> group members as specified in 3GPP TS 24.481 [31], shall send a SIP 183 (Session Progress) response to the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" as specified in clause 6.3.4.2.2.1 and shall populate the response with an application/vnd.3gpp.mcptt-info+xml MIME body containing the <required> element set to "true".

11) if the group document retrieved from the group management server does not contain any <on-network-required> group members as specified in 3GPP TS 24.481 [31], may, according to local policy, send a SIP 183 (Session Progress) response to the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" as specified in clause 6.3.4.2.2.1;

12) shall invite each group member determined in step 9) above, to the group session, as specified in clause 10.1.1.5.1; and

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

Unless a SIP response has been sent to the controlling MCPTT function as specified in step 10 or 11 above, the non-controlling MCPTT function of an MCPTT group shall wait for the first SIP provisional response or first SIP 200 (OK) response from one of the invited MCPTT clients, before sending a response to the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group".

Upon receiving the first 18x response to a SIP INVITE request sent to an invited MCPTT client as specified in clause 10.1.1.5.1, not containing a P-Answer-State header field, and if a SIP 183 (Session Progress) response has not already been sent in response to the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group", the non-controlling MCPTT function of an MCPTT group:

1) shall generate a SIP 183 (Session Progress) response as described in clause 6.3.4.2.2.1; and

2) shall forward the SIP 183 (Session Progress) response to the controlling MCPTT function according to 3GPP TS 24.229 [4].

Upon receiving the first 18x response to a SIP INVITE request sent to an invited MCPTT client as specified in clause 10.1.1.5.1, containing a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [34], a SIP 183 (Session Progress) response has not already been sent in response to the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" and the non-controlling MCPTT function of an MCPTT group supports media buffering, the non-controlling MCPTT function of an MCPTT group:

1) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.4.2.2.2 before continuing with the rest of the steps;

2) 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 clause 6.3.4.2.1;

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

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

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

If the group document does not contain any <on-network-required> group members as specified in 3GPP TS 24.481 [31], then upon receiving the first SIP 200 (OK) response to a SIP INVITE request sent to an invited MCPTT client as specified in clause 10.1.1.5.1, the non-controlling MCPTT function of an MCPTT group:

1) shall generate SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.4.2.2.2 before continuing with the rest of the steps;

2) 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 clause 6.3.4.2.1;

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

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

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

If the group document contains <on-network-required> group member(s) as specified in 3GPP TS 24.481 [31], then the non-controlling MCPTT function of an MCPTT group shall wait until all SIP 200 (OK) responses to SIP INVITE requests have been received from the <on-network-required> MCPTT clients before sending a SIP 200 (OK) response back to the controlling MCPTT function, as specified above.

If all invited MCPTT clients have rejected SIP INVITE requests with a SIP 3xx, 4xx, 5xx or 6xx response, the non-controlling MCPTT function of an MCPTT group:

1) shall generate a SIP reject response as specified in 3GPP TS 24.229 [4];

2) shall, from the list of reject response codes cached by the non-controlling MCPTT function of an MCPTT group, select the highest prioritized cached reject response code as specified in IETF RFC 3261 [24]; and

3) shall send the reject response towards the controlling MCPTT function as specified in 3GPP TS 24.229 [4].

10.1.1.5.2.3 Joining an ongoing prearranged group call

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

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

1) 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. Otherwise, continue with the rest of the steps;

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

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

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

2A) if the MCPTT emergency group call state is set to either "MEGC 2: emergency-call-requested" or "MEGC 3: emergency-call-granted" shall reject the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" with a SIP 403 (Forbidden) response, with warning text set to "166 constituent group is in an emergency call state " in a Warning header field as specified in clause 4.4, and shall not process the remaining steps;

NOTE 2: 3GPP TS 23.280 includes the possibility that local policy could allow a constituent group that is in an emergency state to be included in a group regroup; however, the transfer of that emergency state to the group regroup from the constituent group is not supported in the present document.

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

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

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

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

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

8) shall instruct the media plane to initialise the switch to non-controlling mode as specified in 3GPP TS 24.380 [5] clause 6.5.2.3.2;

NOTE 3: Resulting media plane processing is completed before the next step is performed. The media plane indicates the state of the floor and if the state is "floor-taken", information about the current speaker.

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

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

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

1) if information about a current speaker is cached:

a) shall generate a SIP INFO request as specified in clause 6.3.4.1.3; and

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

2) shall instruct the media plane to finalise the switch to the non-controlling mode as specified in 3GPP TS 24.380 [5] clause 6. 5.2.3.3; and

3) if at least one of the MCPTT clients in the pre-arranged group session has a subscription to the conference event package, shall subscribe to the conference event package from the controlling MCPTT function as specified in clause 10.1.3.5.3.

10.1.1.5.2.4 Splitting an ongoing prearranged group call

Upon receipt of a SIP BYE request or a final SIP reject response from the controlling MCPTT function, the non-controlling MCPTT function of an MCPTT group:

1) if keeping the prearranged group call active is according to the release policy in clause 6.3.8.1, shall request media plane to switch to controlling mode as specified in 3GPP TS 24.380 [5] clause 6.3.5;

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

2) if a SIP BYE request was received, shall send a SIP 200 (OK) response to the SIP BYE request; and

3) if keeping the prearranged group call active is according to the release policy in clause 6.3.8.1 and if at least one of the remaining MCPTT clients has subscribed to the conference package, shall send a NOTIFY request to all participants with a subscription to the conference event package as specified in clause 10.1.3.5.2.

NOTE 2: The SIP NOTIFY request will indicate that all participants, with the exception of the MCPTT users belonging to the constituent MCPTT group hosted by the non-controlling MCPTT function, have left the group session.

10.1.1.5.3 Rejoin procedures

10.1.1.5.3.1 Terminating procedures

Upon receipt of a SIP INVITE request that includes an MCPTT session identity of an ongoing MCPTT session in the Request-URI the non-controlling MCPTT function act as a controlling MCPTT function towards the MCPTT client and shall perform the actions in the clause 10.1.1.4.5.1 with the following clarifications:

1) the MCPTT session identity in the Contact header field of the SIP 200 (OK) response shall be the MCPTT session identity generated by the non-controlling MCPTT function; and

2) the clause 10.1.3.5.2 shall be used when sending the SIP NOTIFY request for subscriptions to the conference event package.

10.1.1.5.3.2 Late call entry initiated by non-controlling MCPTT function

When non-controlling MCPTT function is notified that an MCPTT client is newly affiliated or comes back from out of coverage, the non-controlling MCPTT function shall invite the MCPTT client to join an ongoing MCPTT group call by following the procedures specified in clause 10.1.1.5.1.

NOTE: How the MCPTT function is informed when an MCPTT client is coming back from out of coverage is out of scope of present document.

10.1.1.5.4 void

10.1.1.5.5 Initiating a temporary group session

Upon receiving a "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" when a prearranged group session is not ongoing, the non-controlling MCPTT-function shall:

NOTE 1: The difference between a "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" and a "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" (from the controlling MCPTT function) is that the latter SIP INVITE request contains the isfocus media feature tag in the Contact header field.

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 non-controlling 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;

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

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

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

4) shall retrieve the group document from the group management server for the MCPTT group ID contained in the <associated-group-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request and carry out initial processing as specified in clause 6.3.5.2 and continue with the rest of the steps if the checks in clause 6.3.5.2 succeed;

NOTE 2: If the checks are not successful, the SIP response to the "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" is already sent in the clause 6.3.5.2.

5) shall cache the content of the SIP INVITE request;

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

7) shall authorize the MCPTT user in the <mcptt-calling-user-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" as specified in clause 6.3.5.4, if the MCPTT user is unauthorized to initiate a pre-arranged group session the non-controlling MCPTT function shall send a SIP 403 (Forbidden) response with the warning text set to "119 user is not authorised to initiate the group call" in a Warning header field as specified in clause 4.4.

8) if:

a) the MCPTT user identified in the <mcptt-calling-user-id> of the incoming SIP INVITE is not affiliated to the group identity contained in the <associated-group-id> element of the incoming SIP INVITE request as specified in clause 6.3.6;

b) the incoming SIP INVITE request does not contain an emergency indication or an imminent peril indication; or

c) the incoming SIP INVITE request is an authorised request for an MCPTT emergency group call as determined by clause 6.3.3.1.13.2 or for an MCPTT imminent peril group call as determined by clause 6.3.3.1.13.5 and the MCPTT user identified in the <mcptt-calling-user-id> of the incoming SIP INVITE is determined to not be eligible for implicit affiliation as specified in clause 9.2.2.3.6;

9) shall generate a SIP INVITE request towards the controlling MCPTT function as specified in clause 6.3.4.1.4; and

10) shall send the SIP INVITE request to the controlling MCPTT function as specified in 3GPP TS 24.229 [4].

Upon receipt of a SIP 2xx response to the SIP INVITE request sent to the controlling MCPTT function as specified above, the non-controlling MCPTT function:

1) shall send the SIP ACK request to the controlling MCPTT function as specified in 3GPP TS 24.229 [4];

2) shall generate a SIP 200 (OK) to the "SIP INVITE request for controlling MCPTT function of an MCPTT group" as specified in 3GPP TS 24.229 populated as follows:

a) shall include an SDP answer as specified in clause 6.3.4.2.1 based on the SDP answer in the SIP 200 (OK) response;

b) shall include the public service identifier of the non-controlling MCPTT function in the P-Asserted-Identity header field;

c) shall include the warning text set to "148 group is regrouped" in a Warning header field as specified in clause 4.4; and

d) shall send the SIP 200 (OK) request according to 3GPP TS 24.229;

NOTE 3: As long as the MCPTT group is regrouped the floor control messages in the media plane includes a grouped regrouped indication as specified in 3GPP TS 24.380 [5].

3) shall start acting as a non-controlling MCPTT function and interact with the media plane as specified in 3GPP TS 24.380 [5] clause 6.5;

4) shall determine the members to invite to the prearranged MCPTT group call as specified in clause 6.3.5.5; and

5) shall invite each group member determined in step 4) immediately above, to the group session, as specified in clause 10.1.1.5.1.

Upon receipt of other final SIP responses with the exception of the SIP 2xx response to the INVITE request sent to the controlling MCPTT function as specified above, the non-controlling MCPTT function:

1) shall send the SIP ACK response to the controlling MCPTT function as specified in 3GPP TS 24.229 [4]; and

2) shall start acting as a controlling MCPTT function as specified in clause 10.1.1.4 and invite members as specified in clause 6.3.4.1.2.

NOTE 4: Regardless if the controlling MCPTT function accepts or rejects the SIP INVITE request sent above the prearranged group session continues to be initiated with only the members of the group homed on the non-controlling MCPTT function of the group being invited to the group call.

The non-controlling MCPTT function shall handle SIP responses (other than the SIP 2xx response) to the SIP INVITE requests sent to invited members as specified in 3GPP TS 24.229.

Upon receipt of a SIP 2xx response to SIP INVITE requests sent to invited members, the non-controlling MCPTT function:

1) shall send the SIP ACK request as specified in 3GPP TS 24.229 [4]; and

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