6 Call control common procedures

29.3793GPPMission Critical Push To Talk (MCPTT) call control interworking with Land Mobile Radio (LMR) systemsRelease 16Stage 3TS

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

6.1 SDP

6.1.1 SDP offer generation

The SDP offer shall contain only one SDP media-level clause for offered speech according to 3GPP TS 24.229 [3] and, if floor control shall be used during the session, shall contain one SDP media-level clause for a media-floor control entity according to 3GPP TS 29.380 [31].

When composing an SDP offer according to 3GPP TS 24.229 [3] the IWF:

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

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

a) the port number for the media stream selected;

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

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

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

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

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

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

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

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

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

4) if media security is required between the MCPTT client and the IWF for a private call, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [22].

6.1.2 SDP answer generation

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

When composing an SDP answer, the IWF:

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

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

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

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

a) the port number for the media stream;

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

c) if the "a=recvonly" attribute is present in the SDP offer, include an "a=sendonly" attribute;

d) if the "a=sendonly" attribute is present in the SDP offer, include an "a=recvonly" attribute; and

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

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

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

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

6.2 Commencement modes

6.2.1 Automatic commencement mode for private calls

When performing the automatic commencement mode procedures, the IWF performing the participating role:

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

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

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

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

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

6) 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 [3] with the clarifications given in clause 6.1.2;

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

8) shall interact with the media plane as specified in 3GPP TS 29.380 [31] clause 6.2.

6.2.2 Manual commencement mode for private calls

When performing the manual commencement mode procedures:

1) if the user homed in the IWF declines the MCPTT session invitation the IWF performing the participating role shall send a SIP 480 (Temporarily Unavailable) response towards the MCPTT controlling function with the warning text set to: "110 user declined the call invitation" in a Warning header field as specified in clause 4.4, and not continue with the rest of the steps in this clause.

The IWF performing the participating role:

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

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

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

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

5) shall send the SIP 180 (Ringing) response to the controlling MCPTT function.

When sending the SIP 200 (OK) response to the incoming SIP INVITE request, the IWF performing the participating role shall follow the procedures in clause 6.2.1.

6.3 Receiving an MCPTT session release request

Upon receiving a SIP BYE request, the IWF:

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

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

6.4 Priority call conditions

6.4.1 MCPTT emergency group call conditions

6.4.1.1 SIP INVITE request for originating MCPTT emergency group calls

This clause is referenced from other procedures.

When the MCPTT emergency state is set, the IWF performing the participating role:

1) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP INVITE request, an <emergency-ind> element set to "true" and if the MCPTT emergency group call state is set to "MEGC 1: emergency-gc-capable", shall set the MCPTT emergency group call state to "MEGC 2: emergency-call-requested";

2) if the IWF has determined that an MCPTT emergency alert is to be sent, and the MCPTT emergency alert state is set to "MEA 1: no-alert", shall:

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

b) include in the SIP INVITE request the specific location information for MCPTT emergency alert as specified in clause 6.5.1;

3) if the IWF has determined that an MCPTT emergency alert is not to be sent and the MCPTT emergency alert state is set to "MEA 1: no-alert", shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to "false"; and

4) if the MCPTT client emergency group state of the user homed in the IWF of the group is set to a value other than "MEG 2: in-progress" set the MCPTT client emergency group state of the user homed in the IWF of the MCPTT group to "MEG 4: confirm-pending".

NOTE 1: This is the case of a user homed in the IWF already being in the MCPTT emergency state it initiated previously while originating an MCPTT emergency group call or MCPTT emergency alert. All group calls the user homed in the IWF originates while in MCPTT emergency state will be MCPTT emergency group calls.

When the MCPTT emergency state is clear and the MCPTT emergency group call state is set to "MEGC 1: emergency-gc-capable" and the IWF determines that the request for MCPTT emergency group call is authorized by local policy, the IWF performing the participating role shall set the MCPTT emergency state and perform the following actions:

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

2) if the user homed in the IWF has also requested an MCPTT emergency alert to be sent, shall:

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

b) include in the SIP INVITE request the specific location information, if available, for MCPTT emergency alert as specified in clause 6.5.1;

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

4) if the MCPTT client emergency group state of the user homed in the IWF of the group is set to a value other than "MEG 2: in-progress" shall set the MCPTT client emergency group state of the user homed in the IWF of the MCPTT group to "MEG 4: confirm-pending".

NOTE 2: This is the case of an initial MCPTT emergency group call and optionally an MCPTT emergency alert being sent. As the MCPTT emergency state is not sent, there is no MCPTT emergency alert outstanding.

NOTE 3: An MCPTT group call originated by an affiliated member of an MCPTT group which is in an in-progress emergency state (as tracked on the MCPTT client by the MCPTT client emergency group state) but is not in an MCPTT emergency state of their own will also be an MCPTT emergency group call. The <emergency-ind> and <alert-ind> elements of the application/vnd.3gpp.mcptt-info+xml MIME body do not need to be included in this case and hence no action needs to be taken in this clause.

6.4.1.2 Resource-Priority header field for MCPTT emergency group calls

This clause is referenced from other procedures.

If the MCPTT emergency group call state is set to either "MEGC 2: emergency-call-requested" or "MEGC 3: emergency-call-granted", or the MCPTT client emergency group state of the group is set to "MEG 2: in-progress", the IWF performing the participating role shall include in the SIP INVITE request a Resource-Priority header field populated with the values for an MCPTT emergency group call as specified in clause 6.4.1.11.

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

If the MCPTT client emergency group state of the group is "no-emergency" or "cancel-pending", the IWF performing the participating role shall include in the SIP INVITE request a Resource-Priority header field populated with the values for a normal MCPTT group call as specified in clause 6.4.1.11.

6.4.1.3 SIP re-INVITE request for cancelling MCPTT in-progress emergency group state

This clause is referenced from other procedures.

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

The IWF performing the participating role:

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

2) shall clear the MCPTT emergency state; and

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

NOTE 1: This is the case of a user homed in the IWF who has initiated an MCPTT emergency group call and wants to cancel it.

If the MCPTT emergency group call state is set to "MEGC 3: emergency-call-granted" and the MCPTT emergency alert state is set to a value other than "MEA 1: no-alert" and only the MCPTT emergency group call is to be cancelled, the IWF performing the participating role:

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

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

NOTE 2: This is the case of a user homed in the IWF that has initiated both an MCPTT emergency group call and an MCPTT emergency alert and wishes to only cancel the MCPTT emergency group call. This leaves the MCPTT emergency state set.

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

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

2) shall:

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

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

c) clear the MCPTT emergency state; and

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

NOTE 3: This is the case of a user homed in the IWF that has initiated both an MCPTT emergency group call and an MCPTT emergency alert and wishes to cancel both.

6.4.1.4 Receiving a SIP 2xx response to a SIP request for a priority call

In the procedures in this clause, a priority group call refers to an MCPTT emergency group call or an MCPTT imminent peril group call.

On receiving a SIP 2xx response to a SIP request for a priority group call, the IWF:

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

a) shall set the emergency group state of the user homed in the IWF of the group to "MEG 2: in-progress" if it was not already set;

b) if the MCPTT emergency alert state of the user homed in the IWF is set to "MEA 2: emergency-alert-confirm-pending" and the SIP 2xx response to the SIP request for a priority group call does not contain a Warning header field as specified in TS 24.379 [29] clause 4.4 with the warning text containing the mcptt-warn-code set to "149", shall set the MCPTT emergency alert state of the user homed in the IWF to "MEA 3: emergency-alert-initiated;

c) shall set the MCPTT emergency group call state to "MEGC 3: emergency-call-granted"; and

d) shall set the MCPTT imminent peril group call state to "MIGC 1: imminent-peril-capable" and the MCPTT imminent peril group state to "MIG 1: no-imminent-peril"; 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" and the SIP 2xx response to the SIP request for an imminent peril group call does not contain a Warning header field as specified in TS 24.379 [29] clause 4.4 with the warning text containing the mcptt-warn-code set to "149":

a) set the MCPTT imminent peril group call state to "MIGC 3: imminent-peril-call-granted"; and

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

6.4.1.5 Receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to a SIP request for a priority group call

In the procedures in this clause, a priority group call refers to an MCPTT emergency group call or an MCPTT imminent peril group call.

Upon receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to a SIP request for a priority group call the IWF:

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

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

b) if the emergency group state of the user homed in the IWF of the group is "MEG 4: confirm-pending" shall set the emergency group state of the user homed in the IWF of the group to "MEG 1: no-emergency"; and

c) if the sent SIP request for a priority group call contained an application/vnd.3gpp.mcptt-info+xml MIME body with an <alert-ind> element set to a value of "true", shall set the MCPTT emergency alert state of the user homed in the IWF to "MEA 1: "no-alert"; and

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

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

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

6.4.1.6 SIP request for originating MCPTT imminent peril group calls

This clause is referenced from other procedures.

When the IWF performing the participating role determines to originate an MCPTT imminent peril group call, the IWF performing the participating role:

1) if the client homed in the IWF’s imminent peril group state is set to "MIGC 1: imminent-peril-gc-capable" and the in-progress emergency state of the group is set to a value of "false":

a) shall include in the SIP request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in 3GPP TS 24.379 [29], clause F.1 with the <imminentperil-ind> element set to "true" and set the MCPTT emergency group call state to "MIGC 2: imminent-peril-call-requested" state; and

b) if the client homed in the IWF’s imminent peril group state of the group is set to a value other than "MIG 2: in-progress" shall set the client homed in the IWF’s emergency group state of the MCPTT group to "MIG 4: confirm-pending".

NOTE: An MCPTT group call originated by an affiliated member of an MCPTT group which is in an in-progress imminent peril state (as tracked on the client by the client imminent peril group state) will also have the priority associated with MCPTT imminent peril group calls. The <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info MIME body does not need to be included in this case, nor do any state changes result and hence no action needs to be taken in this clause.

6.4.1.7 SIP re-INVITE request for cancelling MCPTT in-progress imminent peril group state

This clause is referenced from other procedures.

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

The IWF:

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

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

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

6.4.1.8 Resource-Priority header field for MCPTT imminent peril group calls

This clause is referenced from other procedures.

When the MCPTT imminent peril group call state is set "MIGC 2: imminent-peril-call-requested" or "MIGC 3: imminent-peril-call-granted", or the client homed in the IWF’s imminent peril state of the group is set to "MIG 2: in-progress", the IWF performing the participating role:

1) shall include in the SIP INVITE request a Resource-Priority header field populated with the values for an MCPTT imminent peril group call as specified in clause 6.4.1.11.

NOTE: The IWF performing the participating role ideally would not need to maintain knowledge of the in-progress imminent peril state of the group (as tracked for the client by the client imminent peril group state) but can use this knowledge to provide a Resource-Priority header field set to imminent peril level priority, which starts the infrastructure priority adjustment process sooner than otherwise would be the case.

When the MCPTT imminent peril group call state is set to "MIGC 1: imminent-peril-gc-capable" and the IWF performing the participating role determines that cancellation of the MCPTT imminent peril group call is authorized, or the MCPTT client imminent peril group state of the group is "MIG 1: no-imminent-peril" or "MIG 3: cancel-pending", the IWF performing the participating role:

1) shall include in the SIP INVITE request a Resource-Priority header field populated with the values for a normal MCPTT group call as specified in clause 6.4.1.11.

6.4.1.9 Receiving a SIP INFO request in the dialog of a SIP request for a priority group call

This clause is referenced from other procedures.

Upon receiving a SIP INFO request within the dialog of the SIP request for a priority group call:

– with the Info-Package header field containing the g.3gpp.mcptt-info package name;

– with the application/vnd.3gpp.mcptt-info+xml MIME body associated with the info package according to IETF RFC 6086 [26]; and

– with one or more of the <alert-ind>, <imminentperil-ind> and <emergency-ind> elements set in the application/vnd.3gpp.mcptt-info+xml MIME body;

the IWF:

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

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

a) if the MCPTT emergency alert state of the user homed in the IWF is set to "MEA 2: emergency-alert-confirm-pending":

i) if the <alert-ind> element is set to a value of "false", shall set the MCPTT emergency alert state to "MEA 1: no-alert"; and

ii) if the <alert-ind> element is set to a value of "true", shall set the MCPTT emergency alert state of the user homed in the IWF to "MEA 3: emergency-alert-initiated";

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

a) if the <imminentperil-ind> element is set to a value of "false" and an <emergency-ind> element is set to a value of "true", shall:

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

ii) set the MCPTT imminent peril group call state to "MIGC 1: imminent-peril-capable"; and

iii) set the emergency group state of the user homed in the IWF of the group to "MEG 2: in-progress"; and

NOTE 1: This is the case of an IWF attempting to make an imminent peril group call when the group is in an in-progress emergency group state. The IWF will then receive a notification that the imminent peril call request was denied, however the IWF will be participating at the emergency level priority of the group.

NOTE 2: the emergency group state of the user homed in the IWF above is the view of the in-progress emergency state of the group for each user homed in the IWF.

4) if the SIP request for a priority group call sent by the IWF did not contain an <originated-by> element and if the MCPTT emergency alert state of the user homed in the IWF is set to "MEA 4: Emergency-alert-cancel-pending":

a) if the <alert-ind> element contained in the SIP INFO request is set to a value of "true", shall set the MCPTT emergency alert state of the user homed in the IWF to "MEA 3: emergency-alert-initiated"; and

b) if the <alert-ind> element contained in the SIP INFO request is set to a value of "false", shall set the MCPTT emergency alert state of the user homed in the IWF to "MEA 1: no-alert".

6.4.1.10 SIP re-INVITE request for cancelling the in-progress emergency group state of a group by a third-party

This clause is referenced from other procedures.

Upon the need to cancel an in-progress emergency group state of a group, the IWF performing the participating role shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [3] with the clarifications given below.

The IWF performing the participating role:

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

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

3) if the MCPTT emergency alert on the MCPTT group originated by a MCPTT user is to be cancelled:

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

b) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <originated-by> element set to the MCPTT ID of the MCPTT user who originated the MCPTT emergency alert.

NOTE: When an MCPTT emergency alert is cancelled by a user other than its originator, the <originated-by> element is needed to identify which MCPTT emergency alert is being cancelled, as more than one MCPTT user could have originated emergency alerts to the same group.

6.4.1.11 Resource-Priority header field values

This clause is referenced from other procedures.

The IWF performing the participating role may populate the Resource-Priority header as described for the IWF performing the controlling role in clause 6.6.3.1.12.

6.4.2 MCPTT emergency private call conditions

6.4.2.1 SIP request for originating MCPTT emergency private calls

This clause is referenced from other procedures.

When the MCPTT emergency private call state is set to "MEPC 1: emergency-pc-capable", the IWF:

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

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

3) if an MCPTT emergency alert is to be sent, shall:

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

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

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

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

6.4.2.2 Resource-Priority header field for MCPTT emergency private calls

This clause is referenced from other procedures.

If the MCPTT emergency private call state is set to either "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted", or the MCPTT emergency private priority state of the call is set to "MEPP 2: in-progress", the IWF shall include in the SIP request a Resource-Priority header field populated with the values for an MCPTT emergency private call as specified in clause 6.4.1.11.

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

If this is a request to cancel the MCPTT emergency private call and the MCPTT emergency private priority state of the private call is "MEPP 1: no-emergency" or "MEPP 3: cancel-pending", the IWF shall include in the SIP request a Resource-Priority header field populated with the values for a normal MCPTT private call as specified in clause 6.4.1.11.

6.4.2.3 SIP re-INVITE request for cancelling MCPTT emergency private call state

This clause is referenced from other procedures.

When the MCPTT emergency private call state is set to "MEPC 3: emergency-pc-granted" and the MCPTT emergency alert state is set to "MPEA 1: no-alert", the IWF performing the participating role shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [3] with the clarifications given below.

The IWF performing the participating role:

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

2) shall clear the MCPTT emergency state; and

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

NOTE 1: This is the case where a private call is in emergency and the emergency is to be cancelled.

When the MCPTT emergency private call state is set to "MEPPC 3: emergency-pc-granted" and the MCPTT emergency alert state is set to a value other than "MPEA 1: no-alert" and the IWF decides that only the MCPTT emergency private call should be cancelled, the IWF performing the participating role:

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

NOTE 2: This is the case where both an MCPTT emergency private call and an MCPTT emergency alert have been initiated and only the MCPTT emergency on the private call is to be cancelled. This leaves the MCPTT emergency state set.

When the MCPTT emergency private call state is set to "MEPC 3: emergency-pc-granted" and the MCPTT emergency alert state is set to a value other than "MPEA 1: no-alert" and the IWF performing the participating role has indicated that the MCPTT emergency alert on the MCPTT private call should be cancelled in addition to the MCPTT emergency private call, the IWF performing the participating role:

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

2) shall:

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

b) set the MCPTT private emergency alert state to "MPEA 4: emergency-alert-cancel-pending";

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

4) shall clear the MCPTT emergency state.

NOTE 3: This is the case where both an MCPTT emergency private call and an MCPTT emergency alert have been initiated and both are to be cancelled.

6.5 Location information

6.5.1 Location information for location reporting

This procedure is initiated by the IWF performing the participating role when it is including location report information as part of a SIP request containing an MCPTT emergency alert.

NOTE 1: Location triggers are out of scope of the present document.

The IWF performing the participating role:

1) shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in 3GPP TS 24.379 [29], clause F.3 with a <Report> element included in the <location-info> root element;

2) shall set the <ReportType> element of the <Report> element to a value of "Emergency"; and

3) shall include in the <CurrentLocation> element of the <Report> element of the application/vnd.3gpp.mcptt-location-info+xml MIME body a <CurrentCoordinate> element populated as specified in 3GPP TS 24.379 [29], clause F.3.3.

NOTE 2: According to local policy, additional location information elements specified in 3GPP TS 24.379 [29], clause F.3.3 can be included in the <CurrentLocation> element.

6.6 IWF server role procedures

6.6.1 Distinction of requests sent to the IWF

6.6.1.1 SIP INVITE request

The IWF needs to distinguish between the following initial SIP INVITE requests for originations and terminations:

– SIP INVITE requests routed to the IWF performing the participating role as a result of processing initial filter criteria at the S-CSCF in accordance with the termination procedures as specified in 3GPP TS 24.229 [3] and the Request-URI contains a PSI of the IWF performing the terminating participating role. Such requests are known as "SIP INVITE request for terminating participating MCPTT function" in the procedures in the present document;

– SIP INVITE requests routed to the IWF performing the controlling role as a result of PSI routing on the originating side in accordance with the originating procedures as specified in 3GPP TS 24.229 [3], or as a result of direct PSI routing, in accordance with the termination procedures as specified in 3GPP TS 24.229 [3], the Request-URI is set to a public service identity for MCPTT private call and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [9]. Such requests are known as "SIP INVITE request for controlling MCPTT function of a private call" in the procedures in the present document;

– SIP INVITE requests routed to the IWF performing the controlling role as a result of PSI routing on the originating side in accordance with the originating procedures as specified in 3GPP TS 24.229 [3], or as a result of direct PSI routing, in accordance with the termination procedures as specified in 3GPP TS 24.229 [3], the Request-URI is set to a public service identity serving an MCPTT group and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [9]. Such requests are known as "SIP INVITE request for controlling MCPTT function of an MCPTT group" in the procedures in the present document; and

– SIP INVITE requests routed to the IWF performing the non-controlling role of an MCPTT group as a result of direct PSI routing, in accordance with the termination procedures as specified in 3GPP TS 24.229 [3], the Request-URI is set to a public service identity serving an MCPTT group and the Contact header field contains the isfocus media feature tag specified in IETF RFC 3840 [9]; Such requests are known as "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" in the procedures in the present document.

6.6.1.2 SIP MESSAGE request

The IWF needs to distinguish between the following SIP MESSAGE request for originations and terminations:

– SIP MESSAGE requests routed to the IWF performing the controlling role and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "remotely-initiated-group-call-request". Such requests are known as "SIP MESSAGE request for remotely initiated group call request for controlling MCPTT function";

– SIP MESSAGE requests routed to the IWF performing the controlling role and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <response-type> element set to a value of "remotely-initiated-group-call-response". Such requests are known as "SIP MESSAGE request for remotely initiated group call response for controlling MCPTT function";

– SIP MESSAGE requests routed to the IWF performing the terminating participating role as a result of initial filter criteria with the Request-URI set to the public service identity of the IWF performing the terminating participating role and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "remotely-initiated-group-call-request" or with the <response-type> element set to a value of "remotely-initiated-group-call-response". Such requests are known as "SIP MESSAGE request for remotely initiated group call for terminating participating MCPTT function";

– SIP MESSAGE requests routed to the IWF performing the terminating participating role with the Request-URI set to the public service identity of the IWF and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing a <mcpttinfo> root element containing a <mcptt-Params> element containing an <emergency-ind> element or an <alert-ind> element. Such requests are known as "SIP MESSAGE request for emergency notification for terminating participating MCPTT function" in the procedures in the present document; and

– SIP MESSAGE requests routed to the IWF performing the controlling role with the Request-URI set to the public service identity of the IWF and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing a <mcpttinfo> root element containing a <mcptt-Params> element containing an <emergency-ind> element or an <alert-ind> element. Such requests are known as "SIP MESSAGE request for emergency notification for controlling MCPTT function" in the procedures in the present document.

6.6.2 IWF participating role

6.6.2.1 Requests initiated by a participant homed in the IWF

6.6.2.1.1 SDP offer generation

6.6.2.1.1.1 On-demand session

This clause is referenced from other clauses.

The SDP offer generated by the IWF performing the participating role:

1) shall contain only one SDP media-level clause for speech; and

2) shall contain an SDP media-level clause for one media-floor control entity.

When composing the SDP offer according to 3GPP TS 24.229 [3], the IWF performing the participating role:

1) shall insert the IP address and port number selected by the IWF performing the participating role for the media stream in the SDP offer;

NOTE 1: Requirements can exist for the IWF performing the participating role to be always included in the path of the offered media stream, for example: for the support of features such as lawful interception and recording. Other examples can exist.

2) shall insert the IP address and port number selected by the IWF performing the participating role for the offered media floor control entity, if any, in the received SDP offer; and

3) shall include an "m=audio" media-level clause for the media stream consisting of:

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

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

i) if a call is being initiated to a group identity; and

ii) if the IWF performing the participating role determines one or more preferred codecs;

then the IWF:

i) shall include the name of the chosen codec in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [8];

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

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

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

b) the ‘fmtp’ attributes as specified in 3GPP TS 29.380 [31] clause 14;

5) if security between the IWF and the MCPTT system is required for a private call, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [22]; and

6) shall contain an "a=key-mgmt" attribute field with a "mikey" attribute value.

NOTE: End-to-end security of voice traffic is supported through the use of Interworking Security Data messages specified in 3GPP TS 29.582 [33]. Through the use of these messages, an LMR system can communicate security information to the LMR functionality of a device on the MCPTT system. This will allow the use of LMR algorithms and keys for encrypting and decrypting voice packets within the device that can be transmitted to and received from the LMR system.

6.6.2.1.2 Sending an INVITE request

This clause is referenced from other procedures.

When generating an initial SIP INVITE request according to 3GPP TS 24.229 [3] the IWF performing the participating role:

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

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

3) shall include in the P-Asserted-Identity header field the public service identity of the IWF performing the participating role;

4) shall include the g.3gpp.mcptt media feature tag into the Contact header; and

5) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [3]), into the P-Asserted-Service header field.

6.6.2.1.3 IWF sending a SIP BYE request

When the IWF is ending participation in an MCPTT session and decides to send a SIP BYE request, the IWF:

1) shall interact with the media plane as specified in clause 6.4 in 3GPP TS 29.380 [31];

2) shall generate a SIP BYE request as specified in 3GPP TS 24.229 [3];

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

4) shall set the P-Asserted-Identity header field of the outgoing SIP BYE request to the public service identity of the IWF;

5) may insert an application/vnd.3gpp.mcptt-info+xml MIME body into the outgoing SIP BYE request; and

6) shall send the SIP BYE request towards the controlling MCPTT function, according to 3GPP TS 24.229 [3].

Upon receiving a SIP 200 (OK) response to the SIP BYE request the IWF should complete any further actions necessary to dissociate the LMR user from the MCPTT session and shall interact with the media plane to release any resources as specified in clause 6.4 in 3GPP TS 29.380 [31] for releasing media plane resources associated with the SIP session with the controlling MCPTT function.

6.6.2.1.4 Priority call conditions

6.6.2.1.4.1 General

The clauses of the parent clause contain common procedures to be used for MCPTT emergency group calls and MCPTT imminent peril group calls.

6.6.2.1.4.2 Determining authorisation for originating a priority group call

When the IWF performing the participating role needs to send a request to originate an MCPTT emergency group call and needs to determine if the request is an authorised request for an MCPTT emergency call, the IWF performing the participating role shall check the following:

1) if the IWF determines that the calling user is authorized for emergency-group-call; and

2) if the IWF determines that emergency-group-calls for the selected group are allowed;

then the IWF performing the participating roled shall consider the MCPTT emergency group call request to be an authorised request for an MCPTT emergency group call;

In all other cases, the IWF performing the participating role shall consider the request to originate an MCPTT emergency group call to be an unauthorised request to originate an MCPTT emergency group call.

NOTE 1: How the IWF authorizes a user to originate a priority group call is out of scope of the present document.

When the IWF performing the participating role needs to send a request to originate an MCPTT imminent peril group call and needs to determine if the request is an authorised request for an MCPTT imminent peril group call the IWF performing the participating role shall check the following:

1) if the IWF determines that the calling user is authorized for imminent peril call; and

2) if the IWF determines that imminent paril calls for the selected group are allowed;

then the IWF performing the participating role shall consider the MCPTT imminent peril group call request to be an authorised request for an imminent peril group call;

In all other cases, the IWF performing the participating role shall consider the request to originate an MCPTT imminent peril group call to be an unauthorised request to originate an MCPTT imminent peril call.

NOTE 2: How the IWF authorizes a user to originate an imminent peril call is out of scope of the present document.

6.6.2.1.4.3 Determining authorisation for initiating or cancelling an MCPTT emergency alert

If the IWF performing the participating role needs to send a SIP request for an MCPTT emergency alert and:

1) if the calling user is authorized by the IWF to activate emergency alert; and

2) if the IWF allows emergency alert for the selected group;

then the MCPTT emergency alert request shall be considered to be an authorised request for an MCPTT emergency alert. In all other cases, it shall be considered to be an unauthorised request for an MCPTT emergency alert.

NOTE 1: How the IWF authorizes a user to originate a request for an MCPTT emergency alert is out of scope of the present document.

If the IWF performing the participating role needs to send a SIP request to cancel an MCPTT emergency alert to an MCPTT group, and if the calling user is authorized by the IWF to cancel an emergency alert, then the MCPTT emergency alert cancellation request shall be considered to be an authorised request to cancel an MCPTT emergency alert. In all other cases, it shall be considered to be an unauthorised request to cancel an MCPTT emergency alert.

NOTE 2: How the IWF authorizes a user to cancel an MCPTT emergency alert is out of scope of the present document.

6.6.2.1.4.4 Validate priority request parameters

This clause is referenced from other procedures.

To validate the combinations of <emergency-ind>, <imminentperil-ind> and <alert-ind> which need to be sent in SIP requests, the IWF performing the participating role shall follow the procedures specified in 3GPP TS 24.379 [29], clause 6.3.3.1.17, with the IWF acting as the controlling function.

6.6.2.1.4.5 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

The IWF performing the participating role shall follow the procedures specified in clause 6.6.3.1.12 with the clarification that references in that procedure to the IWF performing the controlling role should be replaced with references to the IWF participating role.

6.6.2.1.5 Sending a SIP INVITE request on receipt of SIP 3xx response

This clause is referenced from other procedures.

Upon:

1) having sent a SIP INVITE request to the controlling MCPTT function; and

2) having received a SIP 302 (Moved Temporarily) response from the controlling MCPTT function sent to the SIP INVITE request in step 1) with:

a) a Contact header field containing a SIP-URI; and

b) an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-request-uri> element;

the IWF performing the participating role:

1) shall generate a SIP INVITE request with the Request-URI set to the contents of the Contact header field of the SIP 302 (Moved Temporarily) response;

2) shall include in the SIP INVITE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [5] included in the original SIP INVITE request sent to the controlling MCPTT function;

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

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

5) shall set the P-Asserted-Identity header field of the outgoing SIP INVITE request to the contents of the P-Asserted-Identity header field of the original SIP INVITE request sent to the controlling MCPTT function;

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

7) 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 outgoing SIP INVITE request;

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

9) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body of the original SIP INVITE request sent to the controlling MCPTT function into the outgoing SIP INVITE request;

10) shall copy the contents of the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body received in the SIP 302 (Moved Temporarily) response, to the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the outgoing SIP INVITE request;

11) shall set the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request to the MCPTT ID of the calling user that was determined by the IWF performing the participating role; and

12) if the <session-type> element is received in the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP 3xx response, shall set the <session-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request to the value of the <session-type> element received in the SIP 3xx response.

6.6.2.2 Requests terminated to the IWF

6.6.2.2.1 SDP offer generation

The IWF performing the participating role shall follow the procedure in clause 6.6.2.1.1.

6.6.2.2.2 SIP BYE request towards the terminating IWF

6.6.2.2.2.1 On-demand

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

1) shall interact with the media plane as specified in clause 6.4 in 3GPP TS 29.380 [31] for releasing media plane resource associated with the SIP session; and

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

6.6.3 IWF controlling role

6.6.3.1 Requests initiated by the IWF performing the controlling role

6.6.3.1.1 Sending an INVITE request

This clause is referenced from other procedures.

The IWF performing the controlling role shall generate an initial SIP INVITE request according to 3GPP TS 24.229 [3].

The IWF performing the controlling role:

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

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

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

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

5) shall include a Referred-By header field with the public service identity of the IWF;

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

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

9) may include an unmodified Priv-Answer-Mode header field;

10) if the request will not contain a Priv-Answer-Mode header field, shall include an Answer-Mode header field; and

11) may include an application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing INVITE request.

6.6.3.1.2 Sending a SIP BYE request

When the IWF performing the controlling role needs to remove an MCPTT participant:

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

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

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

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

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

Upon receiving a SIP 200 (OK) response to a SIP BYE request the IWF performing the controlling role shall interact with the media plane as specified in clause 6.3 in 3GPP TS 29.380 [31] for releasing media plane resources associated with the session with the MCPTT clients.

6.6.3.1.3 Sending a SIP re-INVITE request for MCPTT emergency group call

This clause is referenced from other procedures.

The IWF performing the controlling role shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [3].

The IWF performing the controlling role:

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

2) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-calling-user-id> element set to the MCPTT ID of the initiating MCPTT user;

3) if the in-progress emergency group state of the group is set to a value of "true" the IWF performing the controlling role:

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

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

c) if the received request included a request for an emergency alert and MCPTT emergency alerts are authorised for this group and MCPTT user as determined by the procedures of clause 6.6.3.1.8.1, shall populate the application/vnd.3gpp.mcptt-info+xml MIME body and application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in clause 6.6.3.1.7. Otherwise, shall set the <alert-ind> element to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body; and

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

NOTE: If the imminent peril state of the group is true at this point, the controlling function will be setting it to false as part of the calling procedure. This is in effect an upgrade of an MCPTT imminent peril group call to an MCPTT emergency group call.

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

a) shall include a Resource-Priority header field populated with the values for a normal MCPTT group call as specified in clause 6.6.3.1.12; and

b) if the received SIP re-INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body with the <emergency-ind> element set to a value of "false" and this is an authorised request to cancel an MCPTT emergency group call as determined by the procedures of clause 6.6.3.1.8.4:

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

ii) if the received SIP re-INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "false" and this is an authorised request to cancel an MCPTT emergency alert as determined by the procedures of 3GPP TS 24.379 [29], clause 6.3.3.1.15 with the IWF acting as the controlling function, shall:

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

B) if the received SIP request contains an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body, copy the contents of the received <originated-by> element to an <originated-by> element in the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP re-INVITE request.

6.6.3.1.4 Sending a SIP INVITE request for MCPTT emergency group call

This clause is referenced from other procedures.

This clause describes the procedures for inviting an MCPTT user to an MCPTT session associated with an MCPTT emergency group call or MCPTT imminent peril group call. The procedure is initiated by the IWF performing the controlling role as the result of an action in clause 10.2.3.1.1.

The IWF performing the controlling role:

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

2) shall set the Request-URI to the address of the terminating participating MCPTT function associated with the MCPTT ID of the targeted MCPTT user;

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

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

b) the <mcptt-calling-user-id> element set to the value of the MCPTT ID of the calling user; and

c) the <mcptt-calling-group-id> element set to the value of the MCPTT group ID of the emergency group call.

4) shall include in the P-Asserted-Identity header field the public service identity of the IWF performing the controlling role;

5) shall include in the SIP INVITE request an SDP offer according to the procedures specified in 3GPP TS 24.379 [29], clause 6.3.3.1.1, with the IWF acting as the controlling function; and

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

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

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

c) if

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

ii) the call request originated from the IWF, and the IWF decides to indicate an emergency alert, shall populate the application/vnd.3gpp.mcptt-info+xml MIME body and the application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in clause 6.6.3.1.7. Otherwise, shall set the <alert-ind> element to a value of "false" in the application/vnd.3gpp.mcptt-info+xml MIME body;

NOTE: If the imminent peril state of the group is true at this point, the controlling function will set it to false as part of the calling procedure.

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

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

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

6.6.3.1.5 Sending a SIP UPDATE request for Resource-Priority header field correction

This clause is referenced from other procedures.

This clause describes the procedures for updating an MCPTT session associated with an MCPTT emergency group call or MCPTT imminent peril group call when the received SIP INVITE request did not include a correctly populated Resource-Priority header field. The procedure is initiated by the IWF performing the controlling role for the purpose of providing the correct Resource-Priority header field.

1) shall generate a SIP 183 (Session Progress) response according to 3GPP TS 24.229 [3] with the clarifications provided specified in 3GPP TS 24.379 [29], clause 6.3.3.2.3.1, with the IWF acting as the controlling function;

2) shall include the option tag "100rel" in a Require header field in the SIP 183 (Session Progress) response;

3) shall include in the SIP 183 (Session Progress) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in 3GPP TS 24.379 [29], clause 6.3.3.2.1, with the IWF acting as the controlling MCPTT function; and

4) shall send the SIP 183 (Session Progress) response towards the MCPTT client according to 3GPP TS 24.229 [3].

Upon receiving a SIP PRACK request to the SIP 183 (Session Progress) response the IWF performing the controlling role:

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

2) shall generate a SIP UPDATE request according to 3GPP TS 24.229 [3] with the following clarifications:

3) shall include in the SIP UPDATE 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 3GPP TS 24.379 [29], clause 6.3.3.1.1, with the IWF acting as the controlling function;

4) if the in-progress emergency group state of the group is set to a value of "true" the IWF performing the controlling role shall include a Resource-Priority header field populated for an MCPTT emergency group call as specified in clause 6.6.3.1.12; and

NOTE 1: This is the case when the sending MCPTT client did not send a Resource-Priority header field populated appropriately to receive emergency-level priority. In this case, the Resource-Priority header field is populated appropriately to provide emergency-level priority.

5) if the in-progress emergency group state of the group is set to a value of "false" the IWF performing the controlling role:

a) if the in-progress imminent peril state of the group is set to a value of "false", shall include a Resource-Priority header field populated for a normal priority MCPTT group call as specified in clause 6.6.3.1.12; and

b) if the in-progress imminent peril state of the group is set to a value of "true", shall include a Resource-Priority header field populated for an MCPTT imminent peril group call as specified in clause 6.6.3.1.12.

NOTE 2: This is the case when the sending MCPTT client incorrectly populated a Resource-Priority header field for emergency-level or imminent peril-level priority and the controlling MCPTT function re-populates it as appropriate to an imminent peril level priority or normal priority level.

6.6.3.1.6 Generating a SIP re-INVITE request to cancel an in-progress emergency

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP re-INVITE request to cancel the in-progress emergency state of a group. The procedure is initiated by the IWF performing the controlling role when it determines the cancellation of the in-progress emergency state of a group is required.

The IWF performing the controlling role:

1) shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [3] with the clarifications specified in 3GPP TS 24.379 [29] clause 6.3.3.1.9, with the IWF acting as the controlling function;

2) shall include a Resource-Priority header field populated with the values for a normal MCPTT group call as specified in clause 6.6.3.1.12; and

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

6.6.3.1.7 Populate mcptt-info and location-info MIME bodies for emergency alert

This clause is referenced from other procedures.

This clause describes the procedures for populating the application/vnd.3gpp.mcptt-info+xml and application/vnd.3gpp.mcptt-location-info+xml MIME bodies for an MCPTT emergency alert. The procedure is initiated by the IWF performing the controlling role when it has received request initiating an MCPTT emergency alert and generates a message containing the MCPTT emergency alert information required by 3GPP TS 23.379 [2].

The IWF performing the controlling role:

1) shall include, if not already present, an application/vnd.3gpp.mcptt-info+xml MIME body as specified in 3GPP TS 24.379 [29], clause F.1, and set the <alert-ind> element to a value of "true";

2) shall determine the value of the user’s Mission Critical Organization identity.

NOTE: How the IWF determines the user’s Mission Critical Organization identity is out of scope of the present document;

3) shall include in the <mcpttinfo> element containing the <mcptt-Params> element containing an <mc-org> element set to the value of the user’s Mission Critical Organization identity; and

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

6.6.3.1.8 Authorisations

6.6.3.1.8.1 Determining authorisation for initiating an MCPTT emergency alert

If the IWF performing the controlling role has received a SIP request targeted to an MCPTT group with the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true", the IWF performing the controlling role shall check the following conditions:

1) if the user is authorized by the IWF to initiate an emergency alert; and

2) if the IWF allows emergency alerts on the group;

then the MCPTT emergency alert request shall be considered to be an authorised request for an MCPTT emergency alert targeted to an MCPTT group. In all other cases, the MCPTT emergency alert request shall be considered to be an unauthorised request for an MCPTT emergency alert targeted to an MCPTT group.

NOTE 1: How the IWF authorizes a user to initiate alerts and how the IWF decides to allow emergency alerts on a group is out of scope of the present document.

If the IWF performing the controlling role has received a SIP request targeted to a user with the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true", the IWF performing the controlling role shall check the following condition:

1) if the calling user is authorized by the IWF for emergency alerts;

then the MCPTT emergency alert request shall be considered to be an authorised request for an MCPTT emergency alert targeted to a user. In all other cases, it shall be considered to be an unauthorised request for an MCPTT emergency alert targeted to a user.

NOTE 2: How the IWF authorizes a user to initiate alerts to other users is out of scope of the present document.

NOTE 3: How the IWF determines relevant contents of the MCPTT user profile document is out of scope of the present document.

NOTE 4: How and whether the IWF obtains user profile information for MCPTT users, and whether the MCPTT system needs access to IWF user profile information is not specified in the present document.

6.6.3.1.8.2 Determining authorisation for initiating an MCPTT emergency group or private call

If the IWF performing the controlling role has received a SIP request for an MCPTT group call with the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true" and:

1) if the MCPTT user is authorized by the IWF to initiate emergency calls and if the group is configured to allow emergency calls, then the IWF performing the controlling role shall consider the MCPTT emergency group call request to be an authorised request for an MCPTT emergency group call and skip the remaining step; or

NOTE 1: How the IWF determines whether the user is authorized to initiate an emergency group call and whether the group supports emergency calls is out of scope of the current document.

2) if the IWF performing the controlling role does not consider the MCPTT emergency group call request to be an authorised request for an MCPTT emergency group call by step 1) above, then the IWF performing the controlling role shall consider the MCPTT emergency group call request to be an unauthorised request for an MCPTT emergency group call.

If the IWF performing the controlling role has received a SIP request for an MCPTT private call with the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true", the IWF performing the controlling role determines whether the user is authorized to initiate an emergency private call.

NOTE 2: How the IWF determines whether the user is authorized to initiate an emergency private call is out of scope of the current document.

NOTE 3: How the IWF determines relevant contents of the MCPTT user profile document is out of scope of the present document.

NOTE 4: How and whether the IWF obtains user profile information for MCPTT users, and whether the MCPTT system needs access to IWF user profile information is not specified in the present document.

6.6.3.1.8.3 Determining authorisation for cancelling an MCPTT emergency alert

If the IWF performing the controlling role has received a SIP request with the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "false", the IWF may authorize the MCPTT emergency alert cancellation.

NOTE: How the IWF determines whether to authorize a user to cancel an emergency alert is out of scope of the present document.

6.6.3.1.8.4 Determining authorisation for cancelling an MCPTT emergency group or private call

NOTE 1: How the IWF determines whether to authorize a user to cancel a group call emergency is out of scope of the present document.

If the IWF performing the controlling role has received a SIP request for an MCPTT private call with the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "false", the IWF may authorize the MCPTT emergency private call cancellation request.

NOTE 2: How the IWF determines whether to authorize a user to cancel a private call emergency is out of scope of the present document.

6.6.3.1.8.5 Determining authorisation for initiating an MCPTT imminent peril call

If the IWF performing the controlling role has received a SIP request with the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true"; and

1) if the MCPTT user is authorized by the IWF performing the controlling role to initiate an imminent peril call; and

2) if the IWF allows the group to support imminent peril calls;

NOTE 1: How the IWF authorizes the user to initiate imminent peril calls and how the IWF determines whether to allow imminent peril calls on a group is out of scope of the present document.

then the MCPTT imminent peril call request shall be considered to be an authorised request for an MCPTT imminent peril call. In all other cases, it shall be considered to be an unauthorised request for an MCPTT imminent peril call.

NOTE 2: How the IWF determines relevant contents of the MCPTT user profile document is out of scope of the present document.

NOTE 3: How and whether the IWF obtains user profile information for MCPTT users, and whether the MCPTT system needs access to IWF user profile information is not specified in the present document.

6.6.3.1.8.6 Determining authorisation for cancelling an MCPTT imminent peril call

If the IWF performing the controlling role has received a SIP request with the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "false", the IWF may authorize the MCPTT imminent peril call cancellation request.

NOTE: How the IWF determines whether to authorize a user to cancel an imminent peril call is out of scope of the present document.

6.6.3.1.8.7 Sending a SIP OPTIONS request to authorise an MCPTT user at a non-controlling MCPTT function of a MCPTT group

This clause is referenced from other procedures.

The IWF performing the controlling role:

1) if the <associated-group-id> element is included in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request, shall generate a SIP OPTIONS request according to 3GPP TS 24.229 [3] and the IETF RFC 3261 [14] populated as follows:

a) shall set the Request-URI to the public service identity of the non-controlling MCPTT function associated with the MCPTT Group ID which was present in the <associated-group-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request;

NOTE 1: How the IWF performing the controlling role finds the address of the non-controlling MCPTT function is out of the scope of the current release.

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

c) shall include in the P-Asserted-Identity header field, the public service identity of the IWF performing the controlling role;

d) shall include an application/vnd.3gpp.mcptt-info+xml MIME body where:

i) the <mcptt-request-uri> element shall be set to the value of the <associated-group-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request; and

ii) the <mcptt-calling-user-id> element is set to the same value as in the <mcptt-calling-user-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request;

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

i) the g.3gpp.mcptt media feature tag; and

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

f) send the SIP OPTIONS request as specified in 3GPP TS 24.229 [3]; and

2) if the <associated-group-id> element is not included in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request, shall for each constituent MCPTT group not homed in the IWF performing the controlling role generate a SIP OPTIONS request according to 3GPP TS 24.229 [3] and IETF RFC 3261 [14] populated as follows:

a) shall set the Request-URI to the public service identity of the non-controlling MCPTT function associated with the MCPTT group ID of the constituent group;

NOTE 2: How the IWF performing the controlling role finds the address of the non-controlling MCPTT function is out of the scope of the current release.

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

c) shall include in the P-Asserted-Identity header field, the public service identity of the IWF performing the controlling role;

d) shall include an application/vnd.3gpp.mcptt-info+xml MIME body where:

i) the <mcptt-request-uri> element shall be set to the MCPTT group ID of the constituent group; and

ii) the <mcptt-calling-user-id> element is set to the same value as in the <mcptt-calling-user-id> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request;

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

i) the g.3gpp.mcptt media feature tag; and

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

f) send the SIP OPTIONS request as specified in 3GPP TS 24.229 [3].

Upon receipt of the first SIP 200 (OK) response to the SIP OPTIONS request with the mcptt-warn-code set to "147" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, the IWF acting as the controlling function shall return a SIP 302 (Moved Temporarily) response to the "SIP INVITE request for controlling MCPTT function of an MCPTT group" populated as follows:

1) the URI in the Contact header field set to the P-Asserted-Identity received in the SIP 200 (OK) response;

2) an application/vnd.3gpp.mcptt-info MIME body with:

a) the <mcptt-request-uri> element set to the same value as received in the <mcptt-request-uri> in the SIP 2xx response to the SIP OPTIONS request; and

b) the <session-type> element set to the value received in the <session-type> element in the application/vnd.3gpp.mcptt.info+xml MIME body of the received SIP 2xx response to the SIP OPTIONS request; and

3) if more than one OPTIONS request were sent, shall remove any cached SIP response and ignore any other responses to any other OPTIONS request.

Upon receipt of a SIP 404 (Not Found) response to the SIP OPTIONS request such that the mcptt-warn-code set to "113" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, with the IWF acting as the controlling function:

1) if more than one SIP OPTIONS request were sent and if no other responses to SIP OPTIONS request are expected; shall send a SIP 404 (Not Found) response to "SIP INVITE request for controlling MCPTT function of an MCPTT group" and include the Warning header field received in the SIP 404 (Not Found) response; and

2) if more than one OPTIONS request were sent and other responses to SIP OPTIONS request are expected, shall cache the received SIP 404 (Not Found) response.

Upon receipt of a SIP 403 (Forbidden) response to the SIP OPTIONS request, the mcptt-warn-code set to "106" or "109" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, with the IWF acting as the MCPTT server, and if more than one OPTIONS request were sent and if no other responses to the SIP OPTIONS request are expected, the IWF performing the controlling role:

1) if a SIP 404 (Not Found) response is cached, send a SIP 404 (Not Found) response to "SIP INVITE request for controlling MCPTT function of an MCPTT group" and include the Warning header field received in the SIP 404 (Not Found) response; and

2) if a SIP 404 (Not Found) response is not cached, shall return a SIP 403 (Forbidden) response to "SIP INVITE request for controlling MCPTT function of an MCPTT group" and include the Warning header field received in the SIP 403 (Forbidden) response.

Upon receipt of any other response to the SIP OPTIONS response than specified above and if more than one OPTIONS request were sent and if no other responses to the SIP OPTIONS request are expected, the IWF performing the controlling role:

2) if a SIP 404 (Not Found) response is not cached, shall return a SIP 403 (Forbidden) response to "SIP INVITE request for controlling MCPTT function of an MCPTT group".

NOTE 3: The reason for selecting the SIP 404 (Not Found) response when a SIP 404 (Not Found) response is cached is to indicate that it was a valid request but the MCPTT user identified in the <mcptt-calling-user-id> is not a member of any of the constituent MCPTT groups in the temporary group.

6.6.3.1.9 Generating a SIP 403 response for priority call request rejection

If the IWF performing the controlling role has received a SIP request with the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body is set to "true" and this is an unauthorised request for an MCPTT emergency call as determined by the procedures of clause 6.6.3.1.8.2, the controlling MCPTT function shall:

1) include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcptt-info+xml MIME body as specified in 3GPP TS 24.379 [29], clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element with the <emergency-ind>.

6.6.3.1.10 Handling the expiry of timer TNG2 (in-progress emergency group call timer)

Upon expiry of timer TNG2 (in-progress emergency group call timer) for an MCPTT group, the IWF performing the controlling role:

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

2) shall, if an MCPTT group call or MCPTT group session is in progress on the indicated group, for each of the participating members:

a) generate a SIP re-INVITE request as specified in clause 6.6.3.1.6; and

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

3) shall for each affiliated but non-participating member of the group:

a) generate a SIP MESSAGE request according to 3GPP TS 24.379 [29] clause 6.3.3.1.11, with the IWF acting as the controlling function and include in the application/vnd.3gpp.mcptt-info+xml MIME body an <emergency-ind> element set to a value of "false";

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

c) include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [3]), in a P-Asserted-Service-Id header field according to IETF RFC 6050 [7]; and

d) send the SIP MESSAGE request towards the MCPTT client according to rules and procedures of 3GPP TS 24.229 [3].

Upon receiving a SIP 200 (OK) response to a re-SIP INVITE request the IWF performing the controlling role shall interact with the media plane as specified in 3GPP TS 29.380 [31].

6.6.3.1.11 Sending a SIP INFO request in the dialog of a SIP request for a priority call

This clause is referenced from other procedures and describes how the IWF performing the controlling role generates a SIP INFO request due to the receipt of a SIP request for a priority call.

The IWF performing the controlling role:

1) shall generate a SIP INFO request according to rules and procedures of 3GPP TS 24.229 [3] and IETF RFC 6086 [26];

2) shall include the Info-Package header field set to g.3gpp.mcptt-info in the SIP INFO request;

3) shall include an application/vnd.3gpp.mcptt-info+xml MIME body in the SIP INFO request and:

a) if the received SIP request contained application/vnd.3gpp.mcptt-info+xml MIME body with the <alert-ind> element set to a value of "true" and this is an unauthorised request for an MCPTT emergency alert as specified in clause 6.6.3.1.8.1, shall set the <emergency-ind> element to a value of "true" and the <alert-ind> element to a value of "false";

b) if the received SIP 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, shall set <alert-ind> element to a value of "true"; and

c) if the received SIP request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <imminentperil-ind> element set to a value of "true", this is an authorised request for an MCPTT imminent peril group call and the in-progress emergency state of the group is set to a value of "true", shall set the <imminentperil-ind> element to a value of "false" and the <emergency-ind> element set to a value of "true"; and

4) shall send the SIP INFO request towards the inviting MCPTT client in the dialog created by the SIP request from the inviting MCPTT client, as specified in 3GPP TS 24.229 [3].

6.6.3.1.12 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

The IWF performing the controlling role may populate the Resource-Priority header field to assist interworked MC systems in setting bearer priorities. The IWF can set emergency, imminent peril and normal priorities for private and group calls. The priority values and namespaces are as specified in IETF RFC 8101 [23].

NOTE: How the IWF obtains the values for Resource-Priority header fields is out of scope of the present document.

6.6.3.2 Requests terminated by the IWF performing the controlling role

6.6.3.2.1 Receiving a SIP BYE request

Upon receiving a SIP BYE request the IWF performing the controlling role:

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

NOTE: The IWF performing the non-controlling role is also regarded as a MCPTT client in a temporary MCPTT group session.

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

3) shall check the MCPTT session release policy as specified in clause 6.6.7.1 and clause 6.6.7.2 whether the MCPTT session needs to be released for each participant of the MCPTT session;

4) if release of the MCPTT session is required:

a) shall perform the procedures as specified in the clause 6.6.3.1.2 with the clarification that if the received SIP BYE request contains an application/vnd.3gpp.mcptt-info+xml MIME body, copy the application/vnd.3gpp.mcptt-info+xml MIME body into the outgoing SIP BYE request; and

5) if a release of the MCPTT session is not required:

a) shall send a SIP NOTIFY request to all remaining MCPTT clients in the MCPTT session with a subscription to the conference event package as specified in 3GPP TS 24.379 [29], clause 10.1.3.4.2 with the IWF acting as the controlling MCPTT function.

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

6.6.3.3 Handling of the acknowledged call setup timer (TNG1)

When the IWF performing the controlling role receives a SIP INVITE request to initiate a group session and there are members of the group that are affiliated and are deemed by the IWF to be required for the call, then the IWF performing the controlling role shall start timer TNG1 (acknowledged call setup timer), prior to sending out SIP INVITE requests inviting group members to the group session.

NOTE 1: How the IWF obtains the value of the TNG1 timer is out of scope of the present document.

NOTE 2: How the IWF determines the required participants for the call, whether to require certain participants for the call or whether to require a certain number of participants for the call is out of scope of the present document.

When the IWF performing the controlling role receives all SIP 200 (OK) responses to the SIP INVITE requests, from all affiliated and required members then the IWF performing the controlling role shall stop timer TNG1 (acknowledged call setup timer) and if the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the required number of participants, the IWF performing the controlling role shall send a SIP 200 (OK) response to the initiating MCPTT client and shall interact with the media plane as specified in 3GPP TS 29.380 [31].

NOTE 3: MCPTT clients that are affiliated but are not required members that have not yet responded will be considered as joining an ongoing session when the IWF performing the controlling role receives SIP 200 (OK) responses from these MCPTT clients.

After expiry of timer TNG1 (acknowledged call setup timer) and the local counter of the number of SIP 200 (OK) responses received from invited members is less than the value required by the IWF performing the controlling role, then the IWF performing the controlling role shall wait until further responses have been received from invited clients and the value of the local counter of the number of SIP 200 (OK) responses received from invited members is equal to the number required by the IWF performing the controlling role, before continuing with the timer TNG1 expiry procedures in this clause.

After expiry of timer TNG1 (acknowledged call setup timer) and the local counter of the number of SIP 200 (OK) responses received from invited members is greater or equal to the number required by the IWF performing the controlling role, the IWF performing the controlling role shall execute the steps described below:

1) if the IWF is configured to "proceed" with the setup of the group call, then the IWF performing the controlling role:

a) shall perform the following actions:

i) generate a SIP 200 (OK) response to the SIP INVITE request as specified in the 3GPP TS 24.379 [29] clause 6.3.3.2.2 before continuing with the rest of the steps;

ii) include in the SIP 200 (OK) response the warning text set to "111 group call proceeded without all required group members" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, with the IWF acting as the MCPTT server MCPTT function;

iii) include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the 3GPP TS 24.379 [29] clause 6.3.3.2.1, with the IWF acting as the controlling MCPTT function;

iv) interact with the media plane as specified in 3GPP TS 29.380 [31]; and

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

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

b) when a SIP 200 (OK) response to a SIP INVITE request is received from an invited MCPTT client the IWF performing the controlling role may send an in-dialog SIP MESSAGE request to the MCPTT client that originated the group session with the text "group call proceeded without all required group members";

c) when the IWF performing the controlling role receives a SIP BYE request from an invited MCPTT client, shall take the actions specified in clause 6.6.3.2.1 and may send an in-dialog SIP MESSAGE request to the MCPTT client that originated the group session with the text "group call proceeded without all required group members"; and

d) shall generate a notification package as specified in clause 6.6.3.4 and send a SIP NOTIFY request according to 3GPP TS 24.229 [3] to the MCPTT clients which have subscribed to the conference event package; and

2) if the IWF is configured to "abandon" the setup of the group call, then the IWF performing the controlling role shall:

a) send a SIP 480 (Temporarily Unavailable) response to the MCPTT client that originated the group session with the warning text set to "112 group call abandoned due to required group members not part of the group session" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, with the IWF acting as the MCPTT server;

b) for each confirmed dialog at the IWF performing the controlling role, send a SIP BYE request towards the MCPTT clients invited to the group session in accordance with 3GPP TS 24.229 [3] and interact with the media plane as specified in 3GPP TS 29.380 [31]; and

c) for each non-confirmed dialog at the IWF performing the controlling role, send a SIP CANCEL request towards the MCPTT clients invited to the group session in accordance with 3GPP TS 24.229 [3].

If the IWF performing the controlling role receives a final SIP 4xx, 5xx or 6xx response from an affiliated and required group member prior to expiry of timer TNG1 (acknowledged call setup timer) and based on policy, the IWF performing the controlling role decides not to continue with the establishment of the group call without the affiliated and required group member, then the IWF performing the controlling role:

NOTE 5: It is expected that this action is taken if the policy is to abandon the call on expiry of timer TNG1 (acknowledged call setup timer).

1) shall stop timer TNG1 (acknowledged call setup timer); and

2) shall forward the final SIP 4xx, 5xx or 6xx response towards the inviting MCPTT client with the warning text set to "112 group call abandoned due to required group member not part of the group session" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, with the IWF acting as the MCPTT server.

If:

1) the IWF performing the controlling role receives a final SIP 4xx, 5xx or 6xx response from an affiliated and required group member prior to expiry of timer TNG1 (acknowledged call setup timer);

2) the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the required number of participants; and

3) based on policy, the IWF performing the controlling role decides to continue with the establishment of the group call without the affiliated and required group member;

then the IWF performing the controlling role:

NOTE 6: It is expected that this action is taken if the policy is to proceed with the call on expiry of timer TNG1 (acknowledged call setup timer).

1) if all other invited clients have not yet responded, shall continue running timer TNG1 (acknowledged call setup timer); and

2) if all other invited clients have responded with SIP 200 (OK) responses, shall

a) stop timer TNG1 (acknowledged call setup timer);

b) generate SIP 200 (OK) response to the SIP INVITE request as specified in the 3GPP TS 24.379 [29] clause 6.3.3.2.2 before continuing with the rest of the steps;

c) include in the SIP 200 (OK) response the warning text set to "111 group call proceeded without all required group members" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, with the IWF acting as the MCPTT server;

d) include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the 3GPP TS 24.379 [29] clause 6.3.3.2.1, with the IWF acting as the controlling MCPTT function;

e) interact with the media plane as specified in 3GPP TS 29.380 [31]; and

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

f) send a SIP 200 (OK) response to the inviting MCPTT client according to 3GPP TS 24.229 [3].

6.6.3.4 Generating a SIP NOTIFY request

The IWF performing the controlling role shall generate a SIP NOTIFY request according to 3GPP TS 24.229 [3] with the clarification in this clause.

In the SIP NOTIFY request, the IWF performing the controlling role:

1) shall set the P-Asserted-Identity header field to the public service identity of the IWF performing the controlling role;

2) shall include an Event header field set to "conference";

3) shall include an Expires header field set to 3600 seconds according to IETF RFC 4575 [15], as default value;

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

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

a) the <mcptt-calling-group-id> set to the value of the MCPTT group ID;

b) if the target is a MCPTT user, the value of <mcptt-request-uri> element set to the value of MCPTT ID of the targeted MCPTT user; and

c) if the target is the non-controlling MCPTT function, the value of <mcptt-request-uri> element set to the constituent MCPTT group ID.

In the SIP NOTIFY request, the IWF performing the controlling role shall include an application/conference-info+xml MIME body according to IETF RFC 4575 [15] with the following limitations:

1) the IWF performing the controlling role shall include the MCPTT group ID of the MCPTT group in the "entity" attribute of the <conference-info> element;

2) for each non-IWF connected participant in the MCPTT session with the exception of non-controlling MCPTT functions, the IWF performing the controlling role shall include a <user> element. The <user> element:

NOTE 1: Non-controlling MCPTT functions will appear as a participant in temporary group sessions.

a) shall include the "entity" attribute. The "entity" attribute:

i) shall for the MCPTT client, which initiated, joined or re-joined an MCPTT session, include the MCPTT ID of the user that originated the request; and

ii) shall for an invited MCPTT client include the MCPTT ID of the invited MCPTT user in case of a prearranged group call or chat group call;

b) shall include a single <endpoint> element. The <endpoint> element:

i) shall include the "entity" attribute; and

ii) shall include the <status> element indicating the status of the MCPTT session according to IETF RFC 4575 [14]; and

c) may include the <roles> element.

NOTE 2: The usage of <roles> is only applicable for human consumption.

6.6.3.5 Handling of the group call timer (TNG3)

6.6.3.5.1 General

When the IWF performing the controlling role receives a SIP INVITE request to initiate a group session, then after an MCPTT session identity has been allocated for the group session, the IWF performing the controlling role shall start timer TNG3 (group call timer).

NOTE 1: How the IWF determines the value of the TNG3 timer is out of scope of the present document.

If the IWF does not have a TNG3 timer value, then the IWF performing the controlling role shall not start timer TNG3 (group call timer).

NOTE 2: The group call timer is mandated for a pre-arranged group and is optional for a chat group.

When merging two or more active group calls into a temporary group call, if the IWF is hosting at least one of the active group calls shall stop timer TNG3 (group call timer) for each hosted group call, and the IWF performing the controlling role hosting the temporary group call shall start timer TNG3 (group call timer) for the temporary group call.

NOTE 3: MCPTT server(s) other than the IWF that are hosting the independent active group calls become non-controlling MCPTT function(s) of an MCPTT group, for the temporary group call.

When splitting a temporary group call into independent group calls, the IWF performing the controlling role hosting the temporary group call shall stop timer TNG3 (group call timer) and the controlling MCPTT function(s) hosting the independent group calls shall start TNG3 (group call timer) for each group call.

When the last MCPTT client leaves the MCPTT session, the IWF performing the controlling role shall stop timer TNG3 (group call timer).

On expiry of timer TNG3 (group call timer), the IWF performing the controlling role shall release the MCPTT session by following the procedures in clause 6.6.3.1.2;

6.6.3.5.2 Interaction with the in-progress emergency group call timer (TNG2)

If the IWF performing the controlling role starts timer TNG2 (in-progress emergency group call timer), it shall not start timer TNG3 (group call timer).

If timer TNG3 (group call timer) is running and the MCPTT group call is upgraded to an MCPTT emergency group call, then the IWF performing the controlling role shall stop timer TNG3 (group call timer) and shall start timer TNG2 (in-progress emergency group call timer). If timer TNG2 (in-progress emergency group call timer) is running and the MCPTT emergency group call is cancelled, then the IWF performing the controlling role shall stop timer TNG2 (in-progress emergency group call timer) and shall start timer TNG3 (group call timer).

NOTE 1: How the IWF determines the value of the TNG2 and TNG3 timers is out of scope of the present document.

If timer TNG2 (in-progress emergency group call timer) is running and sequentially expires, then the controlling MCPTT function shall start timer TNG3 (group call timer).

NOTE 2: The above conditions for starting timer TNG2 (in-progress emergency group call timer) and timer TNG3 (group call timer) also apply in the case that these timers are re-started. For example: the case where the timer TNG3 was initially running, the MCPTT group call is upgraded to an MCPTT emergency group call and then the MCPTT emergency group call is cancelled.

6.6.4 IWF non-controlling role

6.6.4.1 Request initiated by the IWF performing the non-controlling role of a group

6.6.4.1.1 SDP offer generation

The SDP offer is generated based on the received SDP offer to be sent to MCPTT clients that are a member of the group homed in the IWF. The SDP offer generated by the IWF performing the non-controlling role of a group:

1) shall include only one SDP media-level clause for speech as contained in the received SDP offer; and

2) shall include an SDP media-level clause for one media-floor control entity, if present in the received SDP offer.

When composing the SDP offer according to 3GPP TS 24.229 [3], the IWF performing the non-controlling role of a group:

1) shall replace the IP address and port number for the offered media stream in the received SDP offer with the IP address and port number of the IWF performing the non-controlling role;

2) shall include all media-level attributes from the received SDP offer;

3) shall replace the IP address and port number for the offered media floor control entity, if any, in the received SDP offer with the IP address and port number of the IWF performing the non-controlling role; and

4) shall include the offered media floor control entity ‘fmtp’ attributes as specified in 3GPP TS 29.380 [31] clause 14.

6.6.4.1.2 Sending an INVITE request towards the MCPTT client

This clause is referenced from other procedures.

This clause covers the situation where a group homed in the IWF is a constituent group of a group homed in an MCPTT system.

If the IWF receives a "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" and does not support group regroup procedures, the IWF shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "100 function not allowed due to local policy" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, and shall not execute the remainder of this procedure.

If there are MCPTT clients that are members of the group, the IWF performing the non-controlling role of a group shall generate initial SIP INVITE requests according to 3GPP TS 24.229 [3].

NOTE 1: How the IWF includes participants homed in the IWF is out of scope.

For each SIP INVITE request, the IWF performing the non-controlling role of a group:

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

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

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

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

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

6) shall copy the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request to the outgoing SIP INVITE request;

7) shall update the application/vnd.3gpp.mcptt-info+xml MIME body with: a <mcptt-request-uri> element set to the MCPTT ID of the invited MCPTT user;

8) shall include the public service identity of the IWF in the P-Asserted-Identity header field;

9) shall include the received Referred-By header field with the public service identity of the IWF;

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

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

12) shall include an unmodified Answer-Mode header field, if present in the incoming SIP INVITE request; and

13) shall include the warning text set to "148 MCPTT group is regrouped" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4.

NOTE 4: 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 29.380 [31].

6.6.4.1.3 Sending a SIP INFO request

This clause is referenced from other procedures.

This clause covers the situation where a group homed in the IWF is a constituent group of a group homed in an MCPTT system.

If the IWF performing the non-controlling role receives a "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" and does not support group regroup procedures, the IWF shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "100 function not allowed due to local policy" in a Warning header field as specified in 3GPP TS 24.379 [29] clause 4.4, and shall not execute the remainder of this procedure.

The IWF shall generate a SIP INFO request according to rules and procedures of 3GPP TS 24.229 [3] and IETF RFC 6086 [26].

The IWF:

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

2) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-request-uri> set to the temporary MCPTT group ID and the <mcptt-calling-group-id> element with the constituent MCPTT group ID;

3) shall include an application/vnd.3gpp.mcptt-floor-request+xml MIME body with the Content-Disposition header field set to "Info-Package". For each current speaker the application/vnd.3gpp.mcptt-floor-request+xml MIME body shall be populated as follows:

a) the <floor-type> element set to "general" or "dual" as described in 3GPP TS 24.379 [29] clause F.5.3;

b) the SSRC of the MCPTT client or participant homed in the IWF with the permission to send media in the <ssrc> element;

c) the actual floor priority in the <floor-priority> element;

d) the MCPTT ID of the MCPTT user or participant homed in the IWF with the permission to send media in the <user-id> element;

e) the queueing capability in the <queueing-capability> element of the <track-info> element;

f) the participant type in the <participant-type> in the <track-info> element;

g) one or more <floor-participant-reference> elements in the <track-info> element in the same order as the would appear in the Track Info field as specified in 3GPP TS 29.380 [31] clause 8.2.3.13; and

h) if available, additional information in the <floor-indicator> element; and

4) if:

a) the user with permission to send media is an MCPTT client, and if:

i) the IWF has location information (see 3GPP TS 24.379 [29] clause 13.2.4) for the MCPTT client;

ii) the location information for the MCPTT client either has not been sent to the controlling MCPTT function or has changed since last sent to the MCPTT controlling function; and

iii) the IWF determines that the location of the MCPTT client is allowed to be sent when the MCPTT user is talking; or

b) the user with permission to send media is a participant homed in the IWF, and if:

i) location information for the user with permission to send media homed in the IWF is available;

ii) the location information for the participant homed in the IWF has either not been sent to the controlling MCPTT function or has changed since last sent to the controlling MCPTT function; and

iii) the IWF determines that the location of the participant homed in the IWF is allowed to be sent when the participant homed in the IWF is talking;

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

6.6.4.1.4 Sending an INVITE request towards the controlling MCPTT function

This clause is referenced from other procedures.

The IWF shall generate a SIP INVITE request according to rules and procedures of 3GPP TS 24.229 [3].

The IWF:

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

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

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

4) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with:

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

b) the <mcptt-calling-user-id> element set to the MCPTT ID of the calling user; and

c) the <required> element set to "true", if the group document retrieved from the group management server contains <on-network-required> group members as specified in 3GPP TS 24.481 [16];

5) shall include the public service identity of the IWF in the P-Asserted-Identity header field;

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

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

6.6.4.2 Requests terminated by the non-controlling MCPTT function of an MCPTT group

6.6.4.2.1 SDP answer generation

When composing the SDP answer according to 3GPP TS 24.229 [3], the IWF performing the non-controlling role of a group:

1) for the accepted media stream in the received SDP offer:

a) shall replace the IP address and port number in the received SDP offer with the IP address and port number of the IWF performing the non-controlling role; and

2) for the accepted media-floor control entity, if present in the received SDP offer:

a) shall replace the IP address and port number in the received SDP offer with the IP address and port number of the IWF performing the non-controlling role; and

b) shall include ‘fmtp’ attributes as specified in 3GPP TS 29.380 [31] clause 14.

6.6.4.2.2 Sending a SIP response to the SIP INVITE request

6.6.4.2.2.1 Sending a SIP 183 (Session Progress) response

When sending a SIP 183 (Session Progress) the IWF performing the non-controlling role of a group:

1) shall generate a SIP 183 (Session Progress) response according to 3GPP TS 24.229 [3];

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

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

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

3) shall include the public service identity determined by the IWF performing the non-controlling role in the P-Asserted-Identity header field; and

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

6.6.4.2.2.2 Sending a SIP 200 (OK) response

When sending a SIP 200 (OK) response, the IWF performing the non-controlling role of a group homed in the IWF:

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

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

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

4) shall include the public service identity of the IWF performing the non-controlling role in the P-Asserted-Identity header field;

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

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

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

6) shall include Warning header field(s) received from MCPTT clients in incoming responses to the SIP INVITE request;

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

8) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-called-party-id> element set to the constituent MCPTT group ID and the <floor-state> element set to the state of the floor.

6.6.4.3 Generating a SIP NOTIFY request

The IWF performing the non-controlling role shall generate a SIP NOTIFY request according to 3GPP TS 24.229 [3] with the clarification in this clause.

In the SIP NOTIFY request, the IWF:

1) shall set the P-Asserted-Identity header field to the public service identity of the IWF;

2) shall include an Event header field set to "conference";

3) shall include an Expires header field set to 3600 seconds according to IETF RFC 4575 [15], as default value;

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

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

a) the <mcptt-calling-group-id> set to the value of the constituent MCPTT group ID;

b) if the target is a MCPTT user, the value of <mcptt-request-uri> element set to the MCPTT ID of the targeted MCPTT user; and

c) if the target is the controlling MCPTT function the value of <mcptt-request-uri> element set to the temporary MCPTT group ID.

In the SIP NOTIFY request, the IWF shall include application/conference-info+xml MIME body according to IETF RFC 4575 [15] as specified in clause 6.6.3.4 with the following exceptions:

1) the IWF performing the non-controlling role shall not regard the controlling MCPTT function as a participant and not include the controlling MCPTT function in a <user> element; and

NOTE: The controlling MCPTT function initiated the temporary group call and will appear as a participant in the group session.

2) the IWF shall include stored conference status information received in SIP NOTIFY requests from the controlling MCPTT function in 3GPP TS 24.379 [29] clause 10.1.3.5.3 and status information about MCPTT participants that are members of the group.

6.6.5 Retrieving and processing a group document

6.6.5.1 General

How an IWF performing the controlling role of a group or performing the non-controlling role of a group obtains information about the group is out of scope of the present document.

NOTE: During the group regrouping operation as specified in 3GPP TS 24.481 [16], the IWF performing the controlling role is notified of the constituent MCPTT group identities associated with the TGI.

6.6.5.2 Rules for joining a group session

The following conditions shall be met for the IWF performing the controlling role to allow an MCPTT user to join an existing group session:

1) the MCPTT user is a member of the group; and

2) the MCPTT user is authorized to join the group;

If both of the above conditions are met, then the MCPTT user shall be authorised to join the group session.

6.6.5.3 Determining the group members to invite

The IWF shall only invite affiliated group members to a group session. The IWF determines whether MCPTT users are affiliated members of its group by following the procedures specified in 3GPP TS 24.379 [29], clause 6.3.6.

NOTE 1: The term "affiliated group members" used above also includes those members that are implicitly affiliated by the IWF performing the controlling role.

NOTE 2: The IWF need not store its group parameters in a GMS as described in 3GPP TS 24.481 [16] the IWF will have to respond to queries from other systems on its IWF-3 interface, which is based upon the CSC-16 interface described in 3GPP TS 23.283 [28].

The IWF may limit the maximum number of participants.

6.6.6 Error handling

6.6.6.1 Public service identity does not exist

Upon receiving a request that includes the Request-URI set to a public service identity that is not allocated in the IWF, the IWF performing the participating role or the controlling role shall return a SIP 404 (Not Found) response.

6.6.7 Session release policy

6.6.7.1 Session release policy for group call

If:

1) the call is a pre-arranged group call and if the IWF performing the controlling role receives an indication from the media plane that the T4 (Inactivity) timer specified in 3GPP TS 29.380 [31] expired and if there is at least one participant of the prearranged group call that is an MCPTT user;

2) there are only one or no participants in the call, including both MCPTT participants and participants homed in the IWF;

3) if the call is a pre-arranged group call and if it is according to local policy, the initiator of the group call leaves the call;

4) less than the minimum number of affiliated group members is present;

5) timer TNG3 (group call timer) expires; or

6) the call is a broadcast group call and if the controlling MCPTT function receives an indication from the media plane that the T4 (Inactivity) timer specified in 3GPP TS 29.380 [31] expired;

then the IWF performing the controlling role;

1) shall release the MCPTT session for the group call if any participants are MCPTT users.

6.6.7.2 Session release policy for private call

If:

1) IWF performing the controlling role decides that a private call has been inactive for longer than a locally determined period; or

2) there are only one or no participants in the MCPTT session;

the IWF performing the controlling role shall release the MCPTT session for a private call.

6.7 Implicit floor request

A SIP re-INVITE request fulfilling the following criteria shall be regarded by the IWF performing the controlling role as an implicit floor request when the originator of the request:

1) performs an upgrade of:

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

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

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

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

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

6.8 Confidentiality and Integrity Protection

6.8.1 General

6.8.1.1 Applicability and exclusions

The procedures in clause 6.8 apply in general to all procedures described in clause 9, clause 10, clause 11 and clause 12.

6.8.1.2 Performing XML content encryption

Whenever the IWF includes XML elements or attributes pertaining to the data specified in 3GPP TS 24.379 [29] clause 4.8 in SIP requests or SIP responses, the IWF shall perform the procedures in clause 6.8.2.1.1, with the exception that when the IWF receives a SIP request with XML elements or attributes in an MIME body that need to be copied from the incoming SIP request to an outgoing SIP request without modification, the IWF shall perform the procedures specified in clause 6.8.2.2.

NOTE: The procedure in clause 6.8.2.1.1 first determines (by referring to configuration) if confidentiality protection is enabled and then call the necessary procedures to encrypt the contents of the XML elements if confidentiality protection is enabled.

6.8.1.3 Performing integrity protection on an XML body

The IWF shall perform the procedures in clause 6.8.3.2 just prior to sending a SIP request or SIP response.

NOTE: The procedure in clause 6.8.3.2 first determines if integrity protection of XML MIME bodies is required and then calls the necessary procedures to integrity protect each XML MIME body if integrity protection is required. Each XML MIME body has its own signature.

6.8.1.4 Keys used in confidentiality protection procedures

Confidentiality protection uses an XPK to encrypt the data which (depending on who is the sender and who is the receiver of the encrypted information) can be an SPK as specified in 3GPP TS 24.379 [29] clause 4.8. An XPK-ID (SPK-ID) is used to key the XPK (SPK). It is assumed that before the procedures in this clause are called, the SPK/SPK-ID is available on the sender and recipient of the encrypted content as described in 3GPP TS 24.379 [29] clause 4.8.

The procedures in 3GPP TS 24.379 [29], clause 6.6.2.3 and 3GPP TS 24.379 [29] clause 6.6.2.4 are used with an XPK equal to the SPK and a XPK-ID equal to the SPK-ID in the following circumstances as described in 3GPP TS 33.180 [27]:

1) IWF sends confidentiality protected content to an MCPTT server in the same domain; and

2) IWF sends confidentiality protected content to an MCPTT server in another domain.

6.8.2 Confidentiality Protection

6.8.2.1 Procedures for sending confidentiality protected content

6.8.2.1.1 IWF performing any role of an MCPTT server

If the IWF performing any role of an MCPTT server determines locally that it needs to confidentiality protect content sent to an MCPTT server, then sending confidentiality protected content between MCPTT servers is enabled.

When sending confidentiality protected content, the IWF:

1) shall use the appropriate keying information specified in clause 6.8.1.4;

2) shall perform the procedures in 3GPP TS 24.379 [29] clause 6.6.2.3.3 to confidentiality protect XML elements containing the content described in 3GPP TS 24.379 [29] clause 4.8; and

3) shall perform the procedures in 3GPP TS 24.379 [29] clause 6.6.2.3.4 to confidentiality protect URIs in XML attributes for URIs described in 3GPP TS 24.379 [29] clause 4.8.

If the IWF determines locally that it does not need to confidentiality protect content sent to an MCPTT server, then sending confidentiality protected content between MCPTT servers is disabled, and content is included in XML elements and attributes without encryption.

6.8.2.2 IWF copying received XML content

The following procedure is executed when an IWF receives a SIP request containing XML MIME bodies, where the content needs to be copied from the incoming SIP request to the outgoing SIP request.

The IWF:

1) shall copy the XML elements from the XML MIME body of the incoming SIP request that do not contain a <EncryptedData> XML element, to the same XML body in the outgoing SIP request;

2) for each encrypted XML element in the XML MIME body of the incoming SIP request as determined by 3GPP TS 24.379 [29] clause 6.6.2.4.1:

a) shall use the keying information described in clause 6.8.1.4 to decrypt the content within the XML element by following the procedures specified in 3GPP TS 24.379 [29] clause 6.6.2.4.2, and shall continue with the steps below if the encrypted XML element was successfully decrypted;

b) if confidentiality protection is enabled as specified in clause 6.8.2.1.1, then for each decrypted XML element:

i) shall re-encrypt the content within the XML element using the keying information described in clause 6.8.1.4 and by following the procedures specified in 3GPP TS 24.379 [29] clause 6.6.2.3.3; and

ii) shall include the re-encrypted content into the same XML MIME body of the outgoing SIP request; and

c) if confidentiality protection is disabled as specified in clause 6.8.2.1.1, shall include the decrypted content in the same XML MIME body of the outgoing SIP request.

3) for each encrypted XML URI attribute in the XML MIME body of the incoming SIP request as determined by 3GPP TS 24.379 [29] clause 6.6.2.4.1:

a) shall use the keying information described in clause 6.8.1.4 to decrypt the URI value of the XML attribute by following the procedures specified in 3GPP TS 24.379 [29] clause 6.6.2.4.3, and shall continue with the steps below if the encrypted XML attribute value was successfully decrypted;

b) if confidentiality protection is enabled as specified in clause 6.8.2.1.1, then for each decrypted XML element:

i) shall re-encrypt the URI value of the XML attribute using the keying information described in clause 6.8.1.4 and by following the procedures specified in 3GPP TS 24.379 [29] clause 6.6.2.3.4; and

ii) shall include the re-encrypted attribute value into the same XML MIME body of the outgoing SIP request; and

c) if confidentiality protection is disabled as specified in clause 6.8.2.1.1, shall include the decrypted value in the same XML MIME body of the outgoing SIP request.

6.8.3 Integrity Protection of XML documents

6.8.3.1 Keys used in integrity protection procedures

Integrity protection uses an XPK to sign the data which (depending on who is the sender and who is the receiver of the signed information) can be an SPK as specified in 3GPP TS 24.379 [29] clause 4.8. An XPK-ID (SPK-ID) is used to key the XPK (SPK). It is assumed that before the procedures in 3GPP TS 24.379 [29] clause 6.6.3.3 and 3GPP TS 24.379 [29] clause 6.6.3.4 are called, the SPK/SPK-ID are available on the sender and recipient of the integrity protected content, as described in 3GPP TS 24.379 [29] clause 4.8.

The procedures in 3GPP TS 24.379 [29] clause 6.6.3.3 and 3GPP TS 24.379 [29] clause 6.6.3.4 shall be used with a XPK equal to the SPK and a XPK-ID equal to the SPK-ID in the following circumstances as described in 3GPP TS 33.180 [27]:

1) IWF sends integrity protected content to an MCPTT server in the same domain; and

2) IWF sends integrity protected content to an MCPTT server in another domain.

6.8.3.2 Integrity protection at the IWF

The IWF determines locally whether sending integrity protected content from the IWF to an MCPTT server is enabled.

NOTE 1: How the IWF determines whether to integrity protect content is out of scope of the present document.

When sending integrity protected content, the IWF shall use the appropriate keying information specified in clause 6.8.3.1 and shall perform the procedures in 3GPP TS 24.379 [29] clause 6.6.3.3.3 to integrity protect XML MIME bodies.

NOTE 2: Each XML MIME body is integrity protected separately.

6.9 Priority sharing

The IWF performing the participating role shall enable or disable priority sharing as specified in 3GPP TS 24.229 [3].

6.10 Private call parameters

6.10.1 Private call parameter check

Parameters of an incoming SIP INVITE are indicated as follows:

1) floor control. Floor control operation is indicated by an SDP offer with a media-level clause for a media-floor control entity;

2) commencement mode. The requested commencement mode is according to the Answer-mode header, i.e. either "auto" or "manual"; and

3) implicit floor request. An implicit floor request is indicated by inclusion of the "mc_implicit_request" ‘fmtp’ attribute for the floor control in the SDP offer/answer as specified in 3GPP TS 29.380 [31] clause 12.

Additional LMR specific parameters, such as LMR encryption mode, are out of scope of the present document. The LMR specific parameters may be conveyed in the <LMR-specific-params> element of the <private-call-params> element of the <anyExt> element of the MIME body <mcpttinfo> root element as defined in 3GPP TS 24.379 [29], clause F.1.

6.10.2 Private call parameter response values

To reject a private call due to unsupported parameters, the IWF performing the participating role shall include in its response to the SIP INVITE a list of parameters from the incoming SIP INVITE that it does support.

To indicate support for one or more private call parameters, in the <private-call-params> element of the <anyExt> element of the <mcpttinfo> root element in the XML body, the IWF:

1) if floor control is requested in the incoming SIP INVITE and is supported, shall include the <floor-control> element;

2) if "without" floor control is requested in the incoming SIP INVITE and is supported by the IWF (i.e. full duplex is not supported), shall include the <without-floor-control> element;

3) if implicit floor is requested in the incoming SIP INVITE and is supported by the IWF (i.e. the IWF need not talk first), shall include the <implicit-floor> element;

4) if floor is not implicitly requested in the incoming SIP INVITE and the IWF supports floor not being implicitly requested (i.e. the IWF must talk first), shall include the <without-implicit-floor> element;

5) if manual commencement is requested in the incoming SIP INVITE and is supported by the IWF, shall include the <manual-commencement> element; and

6) if automatic commencement is requested in the incoming SIP INVITE and is supported by the IWF, shall include the <automatic-commencement> element.