10.1.2 Chat group (restricted) call

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

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

10.1.2.1 General

10.1.2.2 MCPTT client procedures

10.1.2.2.1 On-demand chat group call

10.1.2.2.1.1 Procedure for initiating a chat MCPTT group call and procedure for joining a chat MCPTT group call

Upon receiving a request from an MCPTT user to initiate or join an MCPTT group call using an MCPTT group identity, identifying a chat MCPTT group, 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 chat 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, shall comply with the procedures in clause 6.2.8.1.9;

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

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

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

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

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

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

9) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating 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.

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

11) 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 comply with the procedures in clause 6.2.8.1.2;

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

13) shall contain 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 "chat";

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;

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;

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

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

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

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;

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

14) shall include in the SIP INVITE request an SDP offer according to 3GPP TS 24.229 [4] with the clarifications specified in clause 6.2.1;

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

16) shall send the SIP INVITE request 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; 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.2.2.1.2 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) may check if a Resource-Priority header field is included in the incoming SIP re-INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [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; and

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

10.1.2.2.1.3 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 chat MCPTT group, the MCPTT client shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client:

1) if the MCPTT user is not authorised to cancel the in-progress emergency group state of the MCPTT group as determined by the procedures of 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 optionally 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, if the SIP re-INVITE request is to be sent within an on-demand session, include in the SIP re-INVITE request an SDP offer according to 3GPP TS 24.229 [4] with the clarifications specified in clause 6.2.1;

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

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

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

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

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

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

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

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.2.2.1.4 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 a chat MCPTT 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 is not authorised to do so 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 session to an in-progress imminent peril state and is not authorised to do so 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 associated with an MCPTT group call. If the SIP re-INVITE request is sent within a pre-established session, the media-level section for the offered MCPTT speech media stream and the media-level section of the offered media-floor control entity are expected to be the same as was negotiated in the existing pre-established session.

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

b) if location information has not yet been included in the SIP re-INVITE request;

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

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

2) shall perform the actions specified in clause 6.2.8.1.4.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the SIP re-INVITE request the 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.2.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 chat 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;

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

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

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

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 response, SIP 5xx response or SIP 6xx response to the SIP re-INVITE request:

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

a) contains an application/vnd.3gpp.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 2: This is the case where the MCPTT client requested the cancellation of the MCPTT imminent peril in-progress state and was rejected.

10.1.2.2.1.6 MCPTT client receives a SIP INVITE request for an MCPTT group call

This procedure is used for MCPTT emergency and MCPTT imminent peril calls when the MCPTT client is affiliated but not joined to the chat group.

In the procedures in this clause:

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

1) may reject the SIP INVITE request if either of the following conditions is 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 1: 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) 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

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

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

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

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

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

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

10) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [7]. If no "refresher" parameter was included in the received SIP INVITE request the "refresher" parameter in the Session-Expires header field shall be set to "uas", otherwise shall include a "refresher" parameter set to the value received in the Session-Expires header field the received SIP INVITE request;

11) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [4] with the clarifications given in clause 6.2.2;

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

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

14) if the received SIP INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing an <mcptt-Params> element containing an <anyExt> element which includes a <functional-alias-URI> element, may display to the MCPTT user the functional alias of the inviting MCPTT user.

10.1.2.2.2 Chat group call within a pre-established session

10.1.2.2.2.1 Procedure for initiating a chat MCPTT group call and procedure for joining a chat MCPTT group call

Upon receiving a request from an MCPTT user to initiate or join an MCPTT group call using an MCPTT group identity identifying a chat 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:

1) shall set the Request URI of the SIP REFER request to the session identity of the pre-established session;

2) shall set the Refer-To header field of the SIP REFER request as specified in IETF RFC 3515 [25] with 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], and with the Content-ID header field set to this "cid" URL;

3) shall include in the application/resource-lists+xml MIME body a single <entry> element in a <list> element in the <resource-lists> element where the <entry> elment contains a "uri" attribute set to the chat group identity, extended with the following parameters in the headers portion of the SIP URI:

NOTE 1: Characters that are not formatted as ASCII characters are escaped in the following parameters in the headers portion of the SIP URI.

a) the 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];

b) 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]; and

c) an hname "body" parameter populated with:

i) an application/sdp MIME body containing an SDP offer, if the session parameters of the pre-established session require modification or if implicit floor control is required, according to the conditions specified in clause 6.4;

ii) an application/vnd.3gpp.mcptt-info MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with:

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

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

C) if the chat 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;

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

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

iii) if:

A) implicit floor control is required; and

B) an application/vnd.3gpp.mcptt-info MIME body with 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 include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element;

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

4) if the MCPTT user has requested the origination of an MCPTT emergency group call or is originating an MCPTT group call and the MCPTT emergency state is already set:

a) if this is an authorised request for an MCPTT emergency group call as determined by the procedures of clause 6.2.8.8.1.8, shall comply with the procedures in clause 6.2.8.1.1; and

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

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

6) if the MCPTT user has requested the origination of an MCPTT imminent peril group call:

a) if this is an authorised request for an MCPTT imminent peril group call as determined by the procedures of clause 6.2.8.8.1.8, shall comply with the procedures in clause 6.2.8.1.9; and

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

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

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

9) shall include the following according to IETF RFC 4488 [22]:

a) the option tag "norefersub" in the Supported header field; and

b) the value "false" in the Refer-Sub header field.

10) shall include a Target-Dialog header field as specified in IETF RFC 4538 [23] identifying the pre-established session;

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

12) shall send the SIP REFER request according to 3GPP TS 24.229 [4].

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

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

On receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP REFER 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 and shall skip the remaining steps.

On receiving a SIP re-INVITE request within the pre-established session targeted by the sent SIP REFER request, and if the sent SIP REFER request was a request for an MCPTT emergency group call or an MCPTT imminent peril group call, the MCPTT client:

1) shall perform the actions specified in clause 6.2.8.1.16;

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

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

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

5) shall send the SIP 200 (OK) response towards the participating MCPTT function according to rules and procedures of 3GPP TS 24.229 [4].

On call release by interaction with the media plane as specified in clause 9.2.2 of 3GPP TS 24.380 [5] if the sent SIP REFER request was a request for an MCPTT emergency group call or an MCPTT imminent peril group call, the MCPTT client shall perform the procedures specified in clause 6.2.8.1.17.

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.2.2.3 End group call

10.1.2.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.2.2.3.2 Client originating procedures using pre-established session

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

10.1.2.2.3.3 Client terminating procedures

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

10.1.2.3 Participating MCPTT function procedures

10.1.2.3.1 On-demand chat group call

10.1.2.3.1.1 MCPTT chat session establishment

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.

Upon receipt of a "SIP INVITE request for originating participating MCPTT function" for a group identity identifying a chat MCPTT group containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element set to a value of "chat", the participating MCPTT function:

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

NOTE 1: If the SIP INVITE request contains an emergency indication 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 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 originating participating MCPTT function, the user identified by the MCPTT ID is not authorised to make chat 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 "108 user not authorised to make chat group calls" in a Warning header field as specified in clause 4.4;

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

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 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, shall perform the actions specified in clause 9.2.2.2.12 for implicit affiliation; and

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

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

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

5) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request as specified in clause 6.3.2.1.1.1;

6) if the received SIP INVITE request contains an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in Annex F.3;

a) if not already included, shall include a Content-Type header field set to "application/vnd.3gpp.location-info+xml"; and

b) if not already copied, shall copy the contents of the application/vnd.3gpp.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;

NOTE 12: Note that the application/vnd.3gpp.mcptt-info+xml MIME body will already have been copied into the outgoing SIP INVITE request by clause 6.3.2.1.3.

7) if a Resource-Priority header field was included in the received SIP INVITE request, shall include a Resource-Priority header field according to rules and procedures of IETF RFC 4412 [29] set to the value indicated in the Resource-Priority header field of the SIP INVITE request from the MCPTT client;

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

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

9) 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 to the above SIP INVITE request, the participating MCPTT function:

1) void;

2) shall generate a SIP 200 (OK) response as specified in the 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 14: 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;

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 the 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 the current procedure, shall perform the procedures of clause 9.2.2.2.14.

10.1.2.3.1.2 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 a served MCPTT client of a chat MCPTT group, the participating MCPTT function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the "SIP INVITE request for terminating participating MCPTT function" 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 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 may by means beyond the scope of this specification 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 call, 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.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) if the SIP 200 (OK) response is to be sent within an on-demand session, shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

3) if the SIP 200 (OK) response is to be sent within a pre-established session shall include in the SIP 200 (OK) response an SDP answer based upon the previously negotiated SDP for the pre-established session;

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

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

Upon receipt of a SIP 403 (Forbidden) response to the sent SIP re-INVITE request 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; and

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

10.1.2.3.1.3 Reception of a SIP INVITE request for terminating MCPTT client

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

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

NOTE 1: If the SIP 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 by means beyond the scope of this specification choose to accept the request.

2) shall check the presence of the isfocus media feature tag in the 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. Otherwise, continue with the rest of the steps;

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

4) if:

a) the invited MCPTT client has a pre-established session without an associated MCPTT call such that:

i) the media-level section for the offered MCPTT speech media stream is the same as the media-level section for MCPTT speech media stream in the existing pre-established session; and

ii) the media-level section of the offered media-floor control entity is the same as the media-level section for media-floor control entity in the existing pre-established session;

then the participating MCPTT function may according to local policy perform the actions specified in clause 10.1.2.3.2.2 and skip the remaining steps of the current procedure;

5) shall generate a SIP INVITE request as specified in clause 6.3.2.2.3;

6) shall set the Request-URI to the public user identity associated with the MCPTT ID of the MCPTT user to be invited based on the contents of the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the received "SIP INVITE request for terminating participating MCPTT function";

7) shall copy the contents of the P-Asserted-Identity header field of the incoming "SIP INVITE request for terminating participating MCPTT function" to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

8) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for terminating participating MCPTT function" as specified in clause 6.3.2.2.1;

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

10) shall perform the procedures specified in clause 6.3.2.2.9 to include any MIME bodies in the received SIP INVITE request; and

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

Upon receiving a SIP 200 (OK) response to the above SIP 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.2.3.1.4 Reception of a SIP re-INVITE request for terminating MCPTT client

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

Upon receipt of a SIP re-INVITE request for a terminating MCPTT client of a chat MCPTT group, the participating MCPTT function:

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

2) if the outgoing SIP re-INVITE request will be sent in the dialog of a pre-established session, perform the actions in clause 10.1.2.3.2.2 and skip the remaining steps of the current procedure;

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

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

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

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

10.1.2.3.2 Chat group call within a pre-established session

10.1.2.3.2.1 MCPTT chat session establishment

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

1) the Refer-To header 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 a <resource-lists> element that contains a <list> element that contains an <entry> element with a "uri" attribute containing a SIP URI set to a chat 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 "chat"; 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.4and 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 make chat group calls, shall reject the SIP REFER request with a SIP 403 (Forbidden) response to the SIP REFER request, with warning text set to "108 user not authorised to make group calls" in a Warning header field as specified in clause 4.4.2;

5) shall retrieve the group identity in the "uri" attribute within the <entry> element of a <list> element within 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;

6) 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, and shall not continue with the rest of the steps;

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.

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) if the user identified by the MCPTT ID is not affiliated to the group identified in the SIP REFER request or in the <associated-group-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body as determined by clause 9.2.2.2.11, shall perform the actions specified in clause 9.2.2.2.12 for implicit affiliation;

10) if the actions for implicit affiliation specified in step 9) 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 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 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.

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

12) if the "SIP REFER request for a pre-established session" contained a Refer-Sub header field containing the value "false" 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;

If the incoming SIP REFER request does not contain an <associated-group-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body, then the group identity contained in the application/resource-lists MIME body 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 "uri" attribute within the <entry> element of a <list> element within the <resource-lists> element in the application/resource-lists+xml MIME body pointed to by the "cid" URL in the Refer-To header field 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 the remaining steps;

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

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 send the SIP 200 (OK) response to the SIP REFER request towards the MCPTT client 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.

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

4) shall set the Request-URI of the SIP INVITE request to the public service identity of the controlling MCPTT function determined in step 13);

5) shall copy the group identity from the "uri" attribute of the <entry> element of a <list> element within 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;

6) if the received SIP REFER request contained a Resource-Priority header field, 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 received SIP REFER request from the MCPTT client;

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

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

If incoming SIP REFER request contains an <associated-group-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body, then the group identity contained in the application/resource-lists MIME body 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 send the SIP 200 (OK) response to the SIP REFER request towards the MCPTT client according to 3GPP TS 24.229 [4];

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

3) shall set the Request-URI of the SIP INVITE request to the public service identity of the non-controlling MCPTT function associated with the group identity contained in the <associated-gourp-id> element of the incoming SIP REFER request;

4) shall copy the group identity from the "uri" attribute of the <entry> element of the application/resource-lists 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;

5) if the received SIP REFER request contained a Resource-Priority header field, 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 received SIP REFER request from the MCPTT client; and

6) 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 the application/resource-lists MIME body, referenced by the "cid" URL in the Refer-To header field in the incoming SIP REFER request from the MCPTT client;

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

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

Upon receipt of a SIP 2xx response to the above SIP INVITE request in step 19) the participating MCPTT function shall follow procedures specified in 3GPP TS 24.229 [4], with the clarifications given below:

1) shall cache the contact received in the Contact header field;

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;

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 to the MCPTT client according to 3GPP TS 24.229 [4]; and

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

NOTE 12: 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 13: 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 for 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 sent to the controlling MCPTT function, the participating MCPTT function:

1) if the implicit affiliation procedures of clause 9.2.2.2.12 were invoked in the present clause, 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.2.3.2.2 MCPTT chat session establishment for terminating user within a pre-established session

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

Upon receipt of a SIP INVITE request or a SIP re-INVITE request for a terminating MCPTT client of a chat MCPTT group using a pre-established session, the participating MCPTT function:

1) shall generate an outgoing SIP re-INVITE request as specified in clause 6.3.2.2.10 to be sent within the dialog of the pre-established session;

2) if the received SIP INVITE request or 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;

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

NOTE 2: 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 in the existing pre-established session as per the conditions for pre-established session usage specified in clause 10.1.2.3.1.3.

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 as specified in clause 6.3.2.2.2.2; and

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

10.1.2.3.3 End group call at the originating participating MCPTT function

10.1.2.3.3.1 Receipt of SIP BYE request for ending on-demand chat session

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.2.3.3.2 Receipt of SIP REFER "BYE" request for ending chat session 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.2.3.4 End group call at the terminating participating MCPTT function

10.1.2.3.4.1 Receipt of SIP BYE request for on-demand chat session

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.2.3.4.2 Receipt of SIP BYE request for 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.2.4 Controlling MCPTT function procedures

10.1.2.4.1 On-demand chat group call

10.1.2.4.1.1 Procedure for establishing an MCPTT chat session and procedure for joining an established MCPTT chat session

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

5) alert indication in an incoming SIP INVITE request refers to the <alert-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" containing a group identity identifying a chat 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 set to a value of "true", the controlling MCPTT function can by means beyond the scope of this specification choose to accept the request.

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

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

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

c) the isfocus media feature tag is present in the Contact header field;

3) if received SIP INVITE request includes an application/vnd.3gpp.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;

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

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;

b) 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 and skip the rest of the steps;

c) if the group referred to by the group identity has been regrouped:

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

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

iii) shall skip the rest of the steps;

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

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

5a) if the group identity is associated with a TGI or the identity of a group regroup based on 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".

6) if the MCPTT user identified by the MCPTT ID in the SIP INVITE request is not affiliated with the MCPTT group identified by the group identity in the SIP INVITE request as determined by the procedures of clause 6.3.6:

a) if the MCPTT user is eligible to be implicitly affiliated with the MCPTT chat group as determined by clause 9.2.2.3.6; and

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

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

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

7) if the SIP INVITE request contains 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;

8) 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.6, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the following clarifications:

a) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.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;

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

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

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

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

11) if the chat group session is not ongoing then:

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

b) 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 non-controlling function that owns the constituent MCPTT group identity by following the procedures in clause 10.1.2.4.1.1A;

12) if the chat group session is ongoing and the <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 chat 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 5: 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;

13) if the received SIP INVITE request was determined to be eligible for implicit affiliation in step 5) and if clause 9.2.2.3.7 was not previously invoked in the present clause, shall perform the implicit affiliation as specified in clause 9.2.2.3.7;

14) if the SIP INVITE request contains an emergency indication set to a value of "true" or the in-progress emergency state of the group to "true" the controlling MCPTT function shall:

a) validate that the SIP INVITE request includes a Resource-Priority header field populated with the values for an MCPTT emergency group call as specified in clause 6.3.3.1.19, and if not:

i) perform the actions specified in clause 6.3.3.1.8;

ii) send the SIP UPDATE request generated in clause 6.3.3.1.8 towards the initiator of the SIP INVITE request according to 3GPP TS 24.229 [4]; and

iii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8, proceed with the rest of the steps.

NOTE 6: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly- entered in-progress emergency states of the specified group.

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

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

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

B) if the received SIP INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCPTT emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, perform the procedures specified in clause 6.3.3.1.12; and

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

ii) cache the information that the MCPTT user has initiated an MCPTT emergency call; and

iii) if the SIP INVITE request contains an authorised request for an MCPTT emergency alert as determined in step i) B) above, 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";

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

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

iv) shall generate SIP INVITE requests for the MCPTT emergency group call to the affiliated but not joined members of the chat MCPTT group as specified in clause 6.3.3.1.7;

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

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

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

vi) if the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body is set to "true" and is an authorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1, shall cache the information that the MCPTT user has initiated an MCPTT emergency alert; and

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

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

a) validate that the SIP INVITE request includes 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 if not:

i) perform the actions specified in clause 6.3.3.1.8;

ii) send the SIP UPDATE request generated in clause 6.3.3.1.8 towards the initiator of the SIP INVITE request according to 3GPP TS 24.229 [4]; and

iii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 proceed with the rest of the steps.

NOTE 7: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly- entered in-progress imminent peril states of the specified group.

b) if the in-progress imminent peril state of the group is set to a value of "true" and 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]; and

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

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

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

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

iii) shall generate SIP INVITE requests for the MCPTT imminent peril call to the affiliated but not joined members of the chat MCPTT group as specified in clause 6.3.3.1.7;

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

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

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

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

17) 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 unless the procedures of clause 6.3.3.1.8 were performed in step 13)a) or step 14)a) above;

18) should include the Session-Expires header field and start supervising the SIP session 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";

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

20) shall include the following in a Contact header field:

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

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

c) the MCPTT session identity; and

d) the media feature tag isfocus;

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

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

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

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.

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

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

26) if the chat group session was already ongoing and if at least one of the participants has subscribed to the conference event package, shall send a SIP NOTIFY request to all participants with a subscription to the conference event package as specified in clause 10.1.3.4.2.

Upon receiving a SIP ACK to the SIP 200 (OK) response sent towards the inviting MCPTT client or towards the inviting non-controlling MCPTT function, 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.2.4.1.1A SIP 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 constituent MCPTT group;

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 constituent MCPTT group served by the non-controlling MCPTT; 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) 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

7) shall send the SIP INVITE request towards the non-controlling MCPTT function in accordance with 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) if at least one 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.2.4.1.2 Receipt of a SIP re-INVITE request

In the procedures in this clause:

1) emergency indication in an incoming SIP re-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 re-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 a chat 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 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) if the 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 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 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 shall:

a) validate that the SIP re-INVITE request includes a Resource-Priority header field is populated correctly for an MCPTT emergency group call as specified in clause 6.3.3.1.19, and if not:

i) shall perform the actions specified in clause 6.3.3.1.8; and

ii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 shall proceed with the rest of the steps.

NOTE 2: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly-entered in-progress emergency states of the specified group.

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

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

ii) if the 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 is an authorised request for an MCPTT emergency alert as determined by clause 6.3.3.1.13.1, shall cache the MCPTT ID of the MCPTT user that has initiated an MCPTT emergency alert; and

iii) for each of the other affiliated members 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 with the following clarifications:

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

B) if the received SIP re-INVITE contains an alert indication set to a value of "true" and this is an authorised request for an MCPTT emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, perform the procedures specified in clause 6.3.3.1.12; and

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

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

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

ii) shall cache the MCPTT ID of the MCPTT user that has initiated an MCPTT emergency call;

iii) if the 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 this is an authorised request for an MCPTT emergency alert as 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;

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

v) shall generate SIP re-INVITE requests for the MCPTT emergency group call to the other affiliated and joined participants of the chat MCPTT group as specified in clause 6.3.3.1.6. The MCPTT controlling function:

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

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

vi) shall generate SIP INVITE requests for the MCPTT emergency group call to the affiliated but not joined members of the chat MCPTT group as specified in clause 6.3.3.1.7. The controlling MCPTT function:

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

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

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

5) if the SIP re-INVITE request contains an application/vnd.3gpp.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 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 and <alert-ind> element set to a value of "true"; and

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

6) 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 "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 shall:

a) validate that the SIP re-INVITE request includes a Resource-Priority header field is populated correctly for a normal priority MCPTT group call as specified in clause 6.3.3.1.19, and if not:

i) shall perform the actions specified in clause 6.3.3.1.8; and

ii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 shall proceed with the rest of the steps;

NOTE 3: Verify that the Resource-Priority header is included and properly populated for an in-progress emergency state cancellation of the specified group.

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

c) shall clear the cache of the MCPTT ID of the MCPTT user identified by the <originated-by> element as having an outstanding MCPTT emergency group call;

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

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;

e) shall generate SIP re-INVITE requests to the other affiliated and joined members of the MCPTT group as specified in clause 6.3.3.1.6. The MCPTT controlling function:

i) for each affiliated and joined member 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]; and

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

f) for each of the affiliated but not joined members of the group shall:

i) generate a SIP MESSAGE request notification of the cancellation of the 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 d), 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];

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

a) if the Resource-Priority header field is set to the value indicated for emergency calls and the received SIP re-INVITE request does not contain an authorised request for an MCPTT emergency call as determined in step 4) above and the in-progress emergency state of the group is set to a value of "false", shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps; or

b) if the Resource-Priority header field is set to the value indicated for imminent peril calls and the received SIP re-INVITE request does not contain an authorised request for an MCPTT imminent peril call as determined by the procedures of clause 6.3.3.1.13.5 and the in-progress imminent peril state of the group is set to a value of "false", shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps;

8) if the received SIP re-INVITE request contains an imminent peril indication, shall perform the procedures specified in clause 10.1.2.4.1.3 and skip the rest of the steps;

9) shall include in the SIP 200 (OK) response an SDP answer according to 3GPP TS 24.229 [4] with the clarifications specified in clause 6.3.3.2.1 unless the procedures of clause 6.3.3.1.8 were performed in step 6) a) i) above;

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

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

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

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

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

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

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.2.4.1.3 Handling of a SIP re-INVITE request for imminent peril session

In the procedures in this clause:

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

When the controlling function receives a SIP re-INVITE request with and imminent peril indication, the controlling function:

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

a) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.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"; and

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

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

a) validate that the SIP re-INVITE request includes a Resource-Priority header field with the namespace set to the MCPTT-specific namespace specified in IETF RFC 8101 [48] and the priority set to the priority designated for imminent peril calls and if not:

i) perform the actions specified in clause 6.3.3.1.8;

ii) send the SIP UPDATE request generated in clause 6.3.3.1.8 towards the initiator of the SIP re-INVITE request according to 3GPP TS 24.229 [4]; and

iii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 proceed with the rest of the steps.

NOTE 3: Verify that the Resource-Priority header is included and properly populated for both ongoing and newly- entered in-progress imminent peril states of the specified group.

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

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

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

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

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

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

iii) shall generate SIP INVITE requests for the MCPTT imminent peril group call to the affiliated but not joined members of the chat MCPTT group as specified in clause 6.3.3.1.7;

A) for each affiliated but not joined member shall send the SIP INVITE request towards the MCPTT client as specified in 3GPP TS 24.229 [4]; and

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

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

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

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

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

iii) skip the rest of the steps;

4) 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) validate that the SIP re-INVITE request includes a Resource-Priority header field with the namespace set to the MCPTT-specific namespace specified in IETF RFC 8101 [48], and the priority set to the priority level designated for a normal priority MCPTT group call, and if not:

i) shall perform the actions specified in clause 6.3.3.1.8; and

ii) upon receiving a SIP 200 (OK) response to the SIP UPDATE request sent in clause 6.3.3.1.8 shall proceed with the rest of the steps;

NOTE 3: verify that the Resource-Priority header is included and properly populated for an in-progress emergency group state cancellation of the specified group.

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

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

d) shall generate SIP re-INVITES requests to the other affiliated and joined members of the MCPTT group as specified in clause 6.3.3.1.15. The MCPTT controlling function:

i) for each affiliated and joined member 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]; and

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

e) for each of the affiliated but not joined members of the group shall:

i) generate a SIP MESSAGE request notification of the cancellation of the 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];

5) 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 unless the procedures of clause 6.3.3.1.8 were performed in step 2) or 4) above;

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

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

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

10.1.2.4.2 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.2.4.3 End group call initiated by the controlling MCPTT function

10.1.2.4.3.1 General

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

10.1.2.4.3.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.2.4.3.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.2.5 Non-controlling function of an MCPTT group procedures

10.1.2.5.1 Terminating procedures

10.1.2.5.1.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 chat group call or, if a chat group call is not ongoing, be initiated as an non-controlling MCPTT function and invite MCPTT users.

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

If the "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" is received when a chat 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.2.5.1.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.2.5.1.4.

10.1.2.5.1.2 Initiating a chat group session

Upon receipt of a "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" and if a chat 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) 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 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.

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

10.1.2.5.1.3 Joining an ongoing chat group call

Upon receipt of a "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" and if a chat 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 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 the non-controlling mode as specified in 3GPP TS 24.380 [5] clause 6.5.2.3;

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

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

10) shall send a SIP 200 (OK) response to the controlling 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(s) 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.3.5.3; and

3) if at least one of the MCPTT clients in the chat 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.2.5.1.4 Splitting an ongoing chat group call

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

1) if keeping the chat 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) shall send a SIP 200 (OK) response to the SIP BYE request; and

3) if at least one MCPTT client 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.2.5.1.5 MCPTT client joining the temporary group chat session

Upon receiving of a "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" when a chat session is ongoing, the non-controlling MCPTT function shall act as a controlling MCPTT function towards the MCPTT client and shall perform the actions in the clause 10.1.2.4.1.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.2.5.1.6 Receipt of a SIP re-INVITE request from an MCPTT client

Upon receipt of a SIP re-INVITE request from an MCPTT client the non-controlling MCPTT function shall act as the controlling MCPTT function and shall perform the actions in clause 10.1.2.4.1.2.

10.1.2.5.1.7 void

10.1.2.5.1.8 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 chat 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;

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;

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 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 controlling MCPTT function of an MCPTT group" as specified in clause 6.3.5.2, if the MCPTT user is unauthorized to join a chat group session, the non-controlling MCPTT function shall send a SIP 403 (Forbidden) response with the warning text set to "106 user not authorised to join chat group" in a Warning header field as specified in clause 4.4.

8) if the MCPTT user identified by the MCPTT ID in the SIP INVITE request is not affiliated with the MCPTT group identified by the group identity conained in the <associated-group-id> element element in the application/vnd.3gpp.mcptt-info+xml MIME body of the received SIP INVITE request as determined by the procedures of clause 6.3.6:

a) shall check if the MCPTT user is eligible to be implicitly affiliated with the MCPTT chat group as determined by clause 9.2.2.3.6; and

b) if the MCPTT user is not eligible for implicit affiliation, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.4 and skip the rest of the steps below;

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 from participating MCPTT function for non-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; and

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

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.

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) perform the actions in the clause 10.1.1.5.2.4.

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.