6.2 MCPTT client procedures
24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS
6.2.0 Distinction of requests at the MCPTT client
6.2.0.1 SIP MESSAGE request
The MCPTT client needs to distinguish between the following SIP MESSAGE requests:
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-location-info+xml" and including an XML body containing a Location root element containing a Configuration element. Such requests are known as "SIP MESSAGE request for location report configuration" in the present document;
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-location-info+xml" and including an XML body containing a Location root element containing a Request element. Such requests are known as "SIP MESSAGE request for location report request" in the present document;
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <request-type> element set to a value of "private-call-call-back-request". Such requests are known as "SIP MESSAGE request for private call call-back request for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <request-type> element set to a value of "private-call-call-back-cancel-request". Such requests are known as "SIP MESSAGE request for private call call-back cancel request for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <response-type> element set to a value of "private-call-call-back-response". Such requests are known as "SIP MESSAGE request for private call call-back response for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <response-type> element set to a value of "private-call-call-back-cancel-response". Such requests are known as "SIP MESSAGE request for private call call-back cancel response for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <request-type> element set to a value of "group-selection-change-request". Such requests are known as "SIP MESSAGE request for group selection change request for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <response-type> element set to a value of "group-selection-change-response". Such requests are known as "SIP MESSAGE request for group selection change response for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing 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 terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing 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 terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <request-type> element set to a value of "remotely-initiated-private-call-request". Such requests are known as "SIP MESSAGE request for remotely initiated private call request for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing the <mcptt-Params> element and an <anyExt> element containing the <response-type> element set to a value of "remotely-initiated-private-call-response". Such requests are known as "SIP MESSAGE request for remotely initiated private call response for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/mikey" and a CSB-ID containing a CSK-ID. Such requests are known as "SIP MESSAGE request for CSK download for terminating client";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcptt-info> root element containing the <mcptt-Params> element and an <emergency-alert-area-ind> element. Such requests are known as "SIP MESSAGE request for notification of entry into or exit from an emergency alert area";
– SIP MESSAGE requests routed to the MCPTT client containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcptt-info> root element containing the <mcptt-Params> element and an <group-geo-area-ind> element. Such requests are known as "SIP MESSAGE request for notification of entry into or exit from a group geographic area";
– SIP MESSAGE requests routed to the MCPTT client with the Request-URI set to a public user identity of the MCPTT user that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body and a <regroup-action> element set to "create". Such requests are known as "SIP MESSAGE request to the MCPTT client to request creation of a regroup using preconfigured group" in the procedures in the present document;
– SIP MESSAGE requests routed to the MCPTT client with the Request-URI set to a public user identity of the MCPTT user that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the MCPTT client to request removal of a regroup using preconfigured group" in the procedures in the present document;
– SIP MESSAGE request routed to the MCPTT client 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 the <mcptt-Params> element and an <anyExt> element containing the <request-type> element set to a value of "transfer-private-call-request". Such requests are known as "SIP MESSAGE request for transfer private call request for terminating client";
– SIP MESSAGE request routed to the MCPTT client 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 the <mcptt-Params> element and an <anyExt> element containing the <responset-type> element set to a value of "transfer-private-call-response". Such requests are known as "SIP MESSAGE request for transfer private call response for terminating client";
– SIP MESSAGE request routed to the MCPTT client 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 the <mcptt-Params> element and an <anyExt> element containing the <request-type> element set to a value of "forward-private-call-request". Such requests are known as "SIP MESSAGE request for forwarding private call request for terminating client"; and
– SIP MESSAGE request routed to the MCPTT client 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 the <mcptt-Params> element and an <anyExt> element containing the <responset-type> element set to a value of "forward-private-call-response". Such requests are known as "SIP MESSAGE request for forwarding private call response for terminating client".
6.2.1 SDP offer generation
The SDP offer shall contain one SDP media-level clause for MCPTT speech according to 3GPP TS 24.229 [4] and, may contain one SDP media-level section for a media plane control messages according to 3GPP TS 24.380 [5].
When composing an SDP offer according to 3GPP TS 24.229 [4] the MCPTT client:
1) shall set the IP address of the MCPTT client for the offered MCPTT speech media stream and, if media plane control messages shall be used, for the offered media plane control channel;
NOTE 1: If the MCPTT client is behind a NAT the IP address and port included in the SDP offer can be a different IP address and port than the actual IP address and port of the MCPTT client depending on the NAT traversal method used by the SIP/IP Core.
2) shall include an "m=audio" media-level section for the MCPTT media stream consisting of:
a) the port number for the media stream selected; and
b) the codec(s) and media parameters and attributes with the following clarification:
i) if the MCPTT client is initiating a call to a group identity;
ii) if the <preferred-voice-encodings> element is present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [31] containing an <encoding> element with a "name" attribute; and
iii) if the MCPTT client supports the encoding name indicated in the value of the "name" attribute;
then the MCPTT client:
i) shall insert the value of the "name" attribute in the <encoding name> field of the "a=rtpmap" attribute as defined in IETF RFC 4566 [12];
c) if the SDP offer is for an ambient listening call:
i) if this is a remotely initiated ambient listening call, include an "a=recvonly" attribute; or
ii) if this is a locally initiated ambient listening call, include an "a=sendonly" attribute;
d) "i=" field set to "speech" according to 3GPP TS 24.229 [4]; and
e) if the MCPTT client is initiating a call with implicit floor request:
i) may include an "a=ssrc" attribute as specified in IETF RFC 5576 [84];
3) if media plane control messages shall be used during the session, shall include an "m=application" media-level section as specified in 3GPP TS 24.380 [5] clause 12, consisting of:
a) the port number for the media plane control channel selected as specified in 3GPP TS 24.380 [5]; and
b) the ‘fmtp’ attributes as specified in 3GPP TS 24.380 [5] clause 14; and
NOTE 2: The same media plane control channel is used for transport of messages associated with floor control, pre-established session call control and MBMS bearer management.
4) if end-to-end security is required for a private call and the SDP offer is not for establishing a pre-established session, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [47].
6.2.2 SDP answer generation
When the MCPTT client receives an initial SDP offer for an MCPTT session, the MCPTT client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [4].
When composing an SDP answer, the MCPTT client:
1) shall accept the MCPTT speech media stream in the SDP offer;
2) shall set the IP address of the MCPTT client for the accepted MCPTT speech media stream and, if included in the SDP offer, for the accepted media-floor control entity;
NOTE: If the MCPTT client is behind a NAT the IP address and port included in the SDP answer can be a different IP address and port than the actual IP address and port of the MCPTT client depending on the NAT traversal method used by the SIP/IP Core.
3) shall include an "m=audio" media-level section for the accepted MCPTT speech media stream consisting of:
a) the port number for the media stream;
b) media-level attributes as specified in 3GPP TS 24.229 [4];
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 [4];
4) if included in the SDP offer, shall include the media-level section of the offered media-floor control entity consisting of:
a) an "m=application" media-level section as specified in 3GPP TS 24.380 [5] clause 12; and
b) ‘fmtp’ attributes as specified in 3GPP TS 24.380 [5] clause 14; and
5) if end-to-end security is required for a first-to-answer call, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP answer as specified in 3GPP TS 33.180 [78].
6.2.3 Commencement modes
6.2.3.1 Automatic commencement mode
6.2.3.1.1 Automatic commencement mode for private calls
When performing the automatic commencement mode procedures, the MCPTT client:
1) shall accept the SIP INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [4];
2) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;
3) shall include the g.3gpp.mcptt media feature tag in the Contact header field of the SIP 200 (OK) response;
4) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP 200 (OK) response;
5) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [7]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";
6) shall, if the incoming SIP INVITE request contains a Replaces header field, include in the SDP answer in the SIP 200 (OK) response to the SDP offer the parameters used for the pre-established session identified by the contents of the Replaces header field;
7) shall, if the incoming SIP INVITE request does not contain a Replaces header field, include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [4] with the clarifications given in clause 6.2.2;
NOTE: In the case of a new emergency call where the terminating client is using a pre-established session, the SIP INVITE request containing a Replaces header is used to replace the pre-established session.
7a) shall, if the incoming SIP INVITE request contains a <transfer-announced-ind> element in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body, set the value of the <replaces-header-value> element contained in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body to the following value: The Call-ID header field, and the value of the from-tag header field parameter set to the value contained in the incoming SIP INVITE request. The value of the to-tag is the one set by the MCPTT client in the 200 (OK) response. Together they represent a dialog identifier;
8) shall send the SIP 200 (OK) response towards the MCPTT server according to rules and procedures of 3GPP TS 24.229 [4];
9) shall, if the incoming SIP INVITE request contains a Replaces header field, release the pre-established session identified by the contents of the Replaces header field; and
10) shall interact with the media plane as specified in 3GPP TS 24.380 [5] clause 6.2.
When NAT traversal is supported by the MCPTT client and when the MCPTT client is behind a NAT, generation of SIP responses is done as specified in this clause and as specified in IETF RFC 5626 [15].
6.2.3.1.2 Automatic commencement mode for group calls
When performing the automatic commencement mode procedures, the MCPTT client shall follow the procedures in clause 6.2.3.1.1.
6.2.3.2 Manual commencement mode
6.2.3.2.1 Manual commencement mode for private calls
When performing the manual commencement mode procedures:
1) if the MCPTT user declines the MCPTT session invitation the MCPTT client shall send a SIP 480 (Temporarily Unavailable) response towards the MCPTT server 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; and
2) if the MCPTT user requests to forward the MCPTT private call based on manual user input, the MCPTT client shall send a SIP 480 (Temporarily Unavailable) response including warning text set to "175 call is forwarded" in a Warning header field as specified in clause 4.4 and follow the procedures as specified in clause 11.1.9.2.1, and not continue with the rest of the steps in this clause.
The MCPTT client:
1) shall accept the SIP INVITE request and generate a SIP 180 (Ringing) response according to rules and procedures of 3GPP TS 24.229 [4];
2) shall include the option tag "timer" in a Require header field of the SIP 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 MCPTT server.
When sending the SIP 200 (OK) response to the incoming SIP INVITE request, the MCPTT client shall follow the procedures in clause 6.2.3.1.1.
When NAT traversal is supported by the MCPTT client and when the MCPTT client is behind a NAT, generation of SIP responses is done as specified in this clause and as specified in IETF RFC 5626 [15].
6.2.3.2.2 Manual commencement mode for group calls
When performing the manual commencement mode procedures:
1) the terminating MCPTT client may automatically generate a SIP 183 (Session Progress) in accordance with 3GPP TS 24.229 [4], prior to the MCPTT user’s acknowledgement; and
2) if the MCPTT user declines the MCPTT session invitation the MCPTT client shall send a SIP 480 (Temporarily Unavailable) response towards the MCPTT server 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.
When generating a SIP 183 (Session Progress) response, the MCPTT client:
1) 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";
When sending the SIP 200 (OK) response to the incoming SIP INVITE request, the MCPTT client shall follow the procedures in clause 6.2.3.1.2.
When NAT traversal is supported by the MCPTT client and when the MCPTT client is behind a NAT, generation of SIP responses is done as specified in this clause and as specified in IETF RFC 5626 [15].
6.2.4 Leaving an MCPTT session initiated by MCPTT client
6.2.4.1 On-demand session case
Upon receiving a request from an MCPTT user to leave an MCPTT session established using on-demand session signalling, the MCPTT client:
1) shall interact with the media plane as specified in 3GPP TS 24.380 [5];
2) shall generate a SIP BYE request according to 3GPP TS 24.229 [4];
3) shall set the Request-URI to the MCPTT session identity to leave; and
4) shall send a SIP BYE request towards MCPTT server according to 3GPP TS 24.229 [4].
Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCPTT client shall interact with the media plane as specified in 3GPP TS 24.380 [5].
6.2.4.2 Pre-established session case
Upon receiving a request from an MCPTT user to leave an MCPTT session within a pre-established session, the MCPTT client:
1) shall interact with the media plane as specified in 3GPP TS 24.380 [5];
2) shall generate an initial SIP REFER request outside a dialog in accordance with the procedures specified in 3GPP TS 24.229 [4], IETF RFC 4488 [22] and IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27];
3) shall set the Request-URI of the SIP REFER request to the public service identity identifying the pre-established session on the MCPTT server serving the MCPTT user;
4) shall include the Refer-Sub header field with value "false" according to rules and procedures of IETF RFC 4488 [22];
5) shall include the Supported header field with value "norefersub" according to rules and procedures of IETF RFC 4488 [22];
6) shall set the Refer-To header field of the SIP REFER request to the MCPTT session identity to leave;
7) shall include the "method" SIP URI parameter with the value "BYE" in the URI in the Refer-To header field;
8) shall include a Target-Dialog header field as specified in IETF RFC 4538 [23] identifying the pre-established session; and
9) shall send the SIP REFER request according to 3GPP TS 24.229 [4].
Upon receiving a SIP 2xx response to the SIP REFER request, the MCPTT client shall interact with media plane as specified in 3GPP TS 24.380 [5].
6.2.5 Releasing an MCPTT session initiated by MCPTT client
6.2.5.1 On-demand session case
When the MCPTT client wants to release an MCPTT session using on-demand session signalling, the MCPTT client:
1) if the session is in the process of being established, shall send a SIP CANCEL request according to 3GPP TS 24.229 [4] and skip the rest of the steps;
2) shall interact with the media plane as specified in 3GPP TS 24.380 [5];
3) shall generate a SIP BYE request according to 3GPP TS 24.229 [4];
4) shall set the Request-URI to the MCPTT session identity to release; and
5) shall send a SIP BYE request towards MCPTT server according to 3GPP TS 24.229 [4].
6.2.5.2 Pre-established session case
When the MCPTT client wants to release an MCPTT call using a pre-established session, the MCPTT client:
1) shall interact with the media plane as specified in 3GPP TS 24.380 [5];
2) shall generate an initial SIP REFER request outside a dialog in accordance with the procedures specified in 3GPP TS 24.229 [4], IETF RFC 4488 [22] and IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27];
3) shall set the Request-URI of the SIP REFER request to the public service identity identifying the pre-established session on the MCPTT server serving the MCPTT user;
4) shall include the Refer-Sub header field with value "false" according to rules and procedures of IETF RFC 4488 [22];
5) shall include the Supported header field with value "norefersub" according to rules and procedures of IETF RFC 4488 [22];
6) shall set the Refer-To header field of the SIP REFER request to the MCPTT session identity to release;
7) shall include the "method" SIP URI parameter with the value "BYE" in the URI in the Refer-To header field;
8) shall include a Target-Dialog header field as specified in IETF RFC 4538 [23] identifying the pre-established session; and
9) shall send the SIP REFER request according to 3GPP TS 24.229 [4].
Upon receiving a SIP 2xx response to the SIP REFER request, the MCPTT client shall interact with media plane as specified in 3GPP TS 24.380 [5].
6.2.6 Receiving an MCPTT session release request
Upon receiving a SIP BYE request, the MCPTT client:
1) shall interact with the media plane as specified in 3GPP TS 24.380 [5]; and
2) shall send SIP 200 (OK) response towards MCPTT server according to 3GPP TS 24.229 [4].
6.2.7 Void
6.2.8 Priority call conditions
6.2.8.0 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.2.8.1 MCPTT emergency group call conditions
6.2.8.1.1 SIP INVITE request or SIP REFER request for originating MCPTT emergency group calls
This clause is referenced from other procedures.
When the MCPTT emergency state is set and the MCPTT user is authorised to initiate an MCPTT emergency group call on the targeted MCPTT group as determined by the procedures of clause 6.2.8.1.8, the MCPTT client:
1) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP INVITE request or SIP REFER request, an <emergency-ind> element set to "true";
2) 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";
3) if the MCPTT user has also requested an MCPTT emergency alert to be sent and this is an authorised request for MCPTT emergency alert as determined by the procedures of clause 6.2.8.1.6, 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.2.9.1;
4) if the MCPTT user has not requested an MCPTT emergency alert 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
5) if the MCPTT client emergency group state of the group is set to a value other than "MEG 2: in-progress" set the MCPTT client emergency group state of the MCPTT group to "MEG 4: confirm-pending".
NOTE 1: This is the case of an MCPTT user 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 MCPTT user 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 the MCPTT user is authorised to initiate an MCPTT emergency group call on the targetted MCPTT group as determined by the procedures of clause 6.2.8.1.8, the MCPTT client:
1) shall set the MCPTT emergency state;
2) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP INVITE request or SIP REFER request an <emergency-ind> element set to "true" and set the MCPTT emergency group call state to "MEGC 2: emergency-call-requested" state;
3) if the MCPTT user has also requested an MCPTT emergency alert to be sent and this is an authorised request for MCPTT emergency alert as determined by the procedures of clause 6.2.8.1.6, 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 for MCPTT emergency alert as specified in clause 6.2.9.1;
4) if the MCPTT user has not requested an MCPTT emergency alert to be sent, shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to "false"; and
5) if the MCPTT client emergency group state of the group is set to a value other than "MEG 2: in-progress" shall set the MCPTT client emergency group state 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.2.8.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" and this is an authorised request for an MCPTT emergency group call as determined by the procedures of clause 6.2.8.1.8, or the MCPTT client emergency group state of the group is set to "MEG 2: in-progress", the MCPTT client shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for an MCPTT emergency group call as specified in clause 6.2.8.1.15.
NOTE: The MCPTT client ideally would not need to maintain knowledge of the in-progress emergency state of the group (as tracked on the MCPTT client by the MCPTT client emergency group 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 an authorised request to cancel the MCPTT emergency group call as determined by the procedures of clause 6.2.8.1.7, and the MCPTT client emergency group state of the group is "no-emergency" or "cancel-pending", the MCPTT client shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for a normal MCPTT group call as specified in clause 6.2.8.1.15.
6.2.8.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 MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.
NOTE 1: This procedure assumes that the calling procedure has verified that the MCPTT user has made an authorised request for cancelling MCPTT in-progress emergency group state of the group.
The MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";
2) shall clear the MCPTT emergency state; and
3) shall set MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending"
NOTE 2: This is the case of an MCPTT user 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 the MCPTT user has indicated only the MCPTT emergency group call should be cancelled, the MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false"; and
2) shall set the MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending".
NOTE 3: This is the case of an MCPTT user 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 MCPTT user has indicated that the MCPTT emergency alert on the MCPTT group should be cancelled in addition to the MCPTT emergency group call, the MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";
2) shall if this is an authorised request to cancel an MCPTT emergency alert as determined by the procedures of clause 6.2.8.1.6:
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;
3) should, if this is not an authorised request to cancel an MCPTT emergency alert as determined by the procedures of clause 6.2.8.1.6, indicate to the MCPTT user that they are not authorised to cancel the MCPTT emergency alert; and
4) shall set the MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending".
NOTE 4: This is the case of an MCPTT user that has initiated both an MCPTT emergency group call and an MCPTT emergency alert and wishes to cancel both.
6.2.8.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 MCPTT client:
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 client emergency group state of the group to "MEG 2: in-progress" if it was not already set;
b) if the MCPTT emergency alert state 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 clause 4.4 with the warning text containing the mcptt-warn-code set to "149", shall set the MCPTT emergency alert state 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 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.2.8.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 MCPTT client:
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 MCPTT client emergency group state of the group is "MEG 4: confirm-pending" shall set the MCPTT client emergency group state 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 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.2.8.1.6 Determining authorisation for initiating or cancelling an MCPTT emergency alert
If the MCPTT client receives a request from the MCPTT user to send an MCPTT emergency alert and:
1) if the <allow-activate-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true"; and
2) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of:
a) "DedicatedGroup", and if the <uri-entry> element of the <entry> element of the <EmergencyAlert> element of the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) contains the MCPTT group identity of the MCPTT group targeted by the calling MCPTT user; or
b) "UseCurrentlySelectedGroup" and the <allow-MCPTT-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the <list-service> element of the group document identified by the MCPTT group identity targeted for the emergency alert is set to a value of "true" as specified in 3GPP TS 24.481 [31];
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.
If the MCPTT client receives a request from the MCPTT user to cancel an MCPTT emergency alert to an MCPTT group, and if the <allow-cancel-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then 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.
6.2.8.1.7 Determining authorisation for cancelling the in-progress emergency state of an MCPTT group
When the MCPTT client receives a request from the MCPTT user to cancel the in-progress emergency state of a group the MCPTT client, determines, based on local policy (e.g if the requester is dispatcher or initiator of the MCPTT emergency group call etc), whether to send the emergency group state cancel request or not.
6.2.8.1.8 Determining authorisation for originating a priority group call
When the MCPTT client receives a request from the MCPTT user to originate an MCPTT emergency group call the MCPTT client shall check the following:
1) if the <allow-emergency-group-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true" and
a) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element of the <EmergencyCall> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "DedicatedGroup" and if the <uri-entry> element of the <entry> element of the <MCPTTGroupInitiation> element contains the identity of the MCPTT group targeted by the calling MCPTT user; or
b) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element of the <EmergencyCall> contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup";
then the MCPTT emergency group call request shall be considered to be an authorised request for an MCPTT emergency group call;
In all other cases, the request to originate an MCPTT emergency group call shall be considered to be an unauthorised request to originate an MCPTT emergency group call.
When the MCPTT client receives a request from the MCPTT user to originate an MCPTT imminent peril group call the MCPTT client shall check the following:
1 if the <allow-imminent-peril-call> element of <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true" and:
a) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "DedicatedGroup" and if the <MCPTTGroupInitiation> element contains the identity of the MCPTT group targeted by the calling MCPTT user; or
b) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup";
then the MCPTT imminent peril group call request shall be considered to be an authorised request for an MCPTT imminent peril group call;
In all other cases, the request to originate an MCPTT imminent peril group call shall be considered to be an unauthorised request to originate an MCPTT imminent peril group call.
6.2.8.1.9 SIP request for originating MCPTT imminent peril group calls
This clause is referenced from other procedures.
When the MCPTT client receives a request from the MCPTT user to originate an MCPTT imminent peril group call, and this is an authorised request for an MCPTT imminent peril group call as determined by the procedures of clause 6.2.8.1.8, the MCPTT client:
1) if the MCPTT client 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 Annex 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 MCPTT client imminent peril group state of the group is set to a value other than "MIG 2: in-progress" shall set the MCPTT client 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 MCPTT client by the MCPTT 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.2.8.1.10 Determining authorisation for cancelling an imminent peril group call
When the MCPTT client receives a request from the MCPTT user to cancel an MCPTT imminent peril group call the MCPTT client shall:
1) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true" the MCPTT imminent peril call cancellation request shall be considered to be an authorised request to cancel the MCPTT imminent peril group call; or
2) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "false" the MCPTT imminent peril call cancellation request shall be considered to be an unauthorised request to cancel the MCPTT imminent peril group call.
6.2.8.1.11 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 MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.
NOTE 1: This procedure assumes that the calling procedure has verified that the MCPTT user has made an authorised request for cancelling the in-progress imminent peril group state of the group.
The MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <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 2: This is the case of an MCPTT 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.2.8.1.12 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" and the MCPTT user is authorised to initiate an MCPTT imminent peril group call on the targeted MCPTT group as determined by the procedures of clause 6.2.8.1.8, or the MCPTT client imminent peril state of the group is set to "MIG 2: in-progress", the MCPTT client:
1) shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for an MCPTT imminent peril group call as specified in clause 6.2.8.1.15.
NOTE: The MCPTT client ideally would not need to maintain knowledge of the in-progress imminent peril state of the group (as tracked on the MCPTT client by the MCPTT 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 MCPTT user is authorised to cancel MCPTT imminent peril group calls as determined by the procedures of clause 6.2.8.1.10, or the MCPTT client imminent peril group state of the group is "MIG 1: no-imminent-peril" or "MIG 3: cancel-pending", the MCPTT client:
1) shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for a normal MCPTT group call as specified in clause 6.2.8.1.15.
6.2.8.1.13 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 [54]; 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 MCPTT client:
1) shall send a SIP 200 (OK) response to the SIP INFO request as specified in 3GPP TS 24.229 [4];
2) if the MCPTT emergency group call state is set to "MEGC 3: emergency-call-granted":
a) if the MCPTT emergency alert state 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 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 MCPTT client emergency group state of the group to "MEG 2: in-progress"; and
NOTE 1: This is the case of an MCPTT client attempting to make an imminent peril group call when the group is in an in-progress emergency group state. The MCPTT client will then receive a notification that the imminent peril call request was denied, however they will be participating at the emergency level priority of the group. This could occur for example when an MCPTT client requests an imminent peril call to a group that they are not currently affiliated with.
NOTE 2: the MCPTT client emergency group state above is the MCPTT client’s view of the in-progress emergency state of the group.
4) if the SIP request for a priority group call sent by the MCPTT client did not contain an <originated-by> element and if the MCPTT emergency alert state 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 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 to "MEA 1: no-alert".
6.2.8.1.14 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 receiving an authorised request to cancel an in-progress emergency group state of a group as determined by the procedures of clause 6.2.8.1.7 from an MCPTT user, the MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.
The MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";
2) shall set MCPTT emergency group state of the MCPTT group to "MEG 3: cancel-pending"; and
3) if the MCPTT user has indicated that an MCPTT emergency alert on the MCPTT group originated by another MCPTT user should be cancelled and this is an authorised request for an MCPTT emergency alert cancellation as determined by the procedures of clause 6.2.8.1.6:
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 MCPTT 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.2.8.1.15 Retrieving Resource-Priority header field values
This clause is referenced from other procedures.
When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [48] for an MCPTT emergency group call or MCPTT emergency private call the MCPTT client:
1) shall retrieve the value of the <resource-priority-namespace> element contained in the <emergency-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]); and
2) shall retrieve the value of the <resource-priority-priority> element contained in the <emergency-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]).
When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [48] for an MCPTT imminent peril group call the MCPTT client:
1) shall retrieve the value of the <resource-priority-namespace> element contained in the <imminent-peril-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]); and
2) shall retrieve the value of the <resource-priority-priority> element contained in the <imminent-peril-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]).
When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [48] for a normal MCPTT group or private call the MCPTT client:
1) shall retrieve the value of the <resource-priority-namespace> element contained in the <normal-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]); and
2) shall retrieve the value of the <resource-priority-priority> element contained in the <normal-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]).
NOTE: The "normal" Resource-Priority header field value is needed to return to a normal priority value from a priority value adjusted for an MCPTT emergency group or private call or an MCPTT imminent peril group call. The "normal" priority received from the EPS by use of the "normal" Resource-Priority header field value is expected to be the same as the "normal" priority received from the EPS when initiating a call with no Resource-Priority header field included.
6.2.8.1.16 Handling receipt of a SIP re-INVITE request for priority group call origination status within a pre-established session
This clause is referenced from other procedures.
Upon receipt of a SIP re-INVITE request within the pre-established session targeted by the sent SIP REFER request, and if the sent SIP REFER request was a request for an MCPTT emergency group call or an MCPTT imminent peril group call, the MCPTT client:
1) if the MCPTT emergency group call state is set to "MEGC 2: emergency-call-requested":
a) if there is no <emergency-ind> element or an <emergency-ind> element set to a value of "true" contained in the application/vnd.3gpp.mcptt-info+xml MIME body received in the SIP re-INVITE request, and if no <imminentperil-ind> element is included:
i) shall set the MCPTT client emergency group state of the group to "MEG 2: in-progress" if it was not already set; and
ii) shall set the MCPTT emergency group call state to "MEGC 3: emergency-call-granted"; and
b) if the MCPTT emergency alert state is set to "MEA 2: emergency-alert-confirm-pending":
i) if the SIP re-INVITE request contains an <alert-ind> element set to a value of "true" or does not contain an <alert-ind> element, shall set the MCPTT emergency alert state to "MEA 3: emergency-alert-initiated"; or
ii) if the SIP re-INVITE request contains an <alert-ind> element set to a value of "false", shall set the MCPTT emergency alert state to "MEA 1: no-alert"; and
2) if the MCPTT imminent peril group call state is set to "MIGC 2: imminent-peril-call-requested:
a) if the sip re-INVITE request contains an <imminentperil-ind> element set to a value of "true" or does not contain an <imminentperil-ind> element, shall:
i) set the MCPTT imminent peril group call state to "MIGC 3: imminent-peril-call-granted"; and
ii) set the MCPTT imminent peril group state to "MIG 2: in-progress"; or
b) if the SIP re-INVITE request contains <imminentperil-ind> element set to a value of "false" and an <emergency-ind> element set to a value of "true", shall set the MCPTT client emergency group state of the group to "MEG 2: in-progress".
NOTE: This is the case of an MCPTT client attempting to make an imminent peril group call when the group is in an in-progress emergency group state. The MCPTT client will then receive a notification that the imminent peril call request was denied, however they will be participating at the emergency level priority of the group. This could occur for example when an MCPTT client requests an imminent peril call to a group that they are not currently affiliated with.
6.2.8.1.17 Priority group call conditions upon receiving call release
This clause is referenced from other procedures.
Upon receiving a request to release the MCPTT emergency group call or an MCPTT imminent peril group call in an MCPTT group session is in-progress or is in the process of being established:
1) if the MCPTT emergency group call state is set to "MEGC 2: emergency-call-requested":
a) shall set the MCPTT emergency group call state to "MEGC 1: emergency-gc-capable";
b) if the MCPTT client emergency group state of the group is "MEG 3: confirm-pending" shall set the MCPTT client emergency group state of the group to "MEG 1: no-emergency"; and
c) if the MCPTT emergency alert state is set to "MEA 2: emergency-alert-confirm-pending" shall set the MCPTT emergency alert state to "MEA 1: "no-alert"; and
2) if the MCPTT imminent peril group call state is set to "MIGC 2: imminent-peril-call-requested":
a) if the MCPTT imminent peril group call state of the group is "MIG 3: confirm-pending", 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-capable".
NOTE: The above conditions can be applied upon a call being released within a pre-established by the procedures specified in clause 9.2.2 in 3GPP TS 24.380 [5].
6.2.8.1.18 Emergency private call conditions upon receiving call release
This clause is referenced from other procedures.
Upon receiving a request to release the MCPTT session when an MCPTT emergency private call is in-progress or is in the process of being established:
1) if the MCPTT emergency private call state is set to "MEPC 2: emergency-call-requested":
a) shall set the MCPTT emergency private call state to "MEPC 1: emergency-pc-capable";
b) if the MCPTT emergency private priority state of the private call is "MEPP 3: confirm-pending" shall set the MCPTT emergency private priority state of the private call to "MEPP 1: no-emergency"; and
c) if the MCPTT private emergency alert state is set to "MPEA 2: emergency-alert-confirm-pending shall set the MCPTT private emergency alert state to "MPEA 1: no-alert".
NOTE: The above conditions can be applied upon a call being released within a pre-established by the procedures specified in clause 9.2.2 of 3GPP TS 24.380 [5].
6.2.8.2 Request for an originating broadcast group call
NOTE: This clause is referenced from other procedures.
When the MCPTT user initiates a broadcast group call, the MCPTT client:
1) in the case of the prearranged group call is initiated on-demand, shall include in the application/vnd.3gpp.mcptt-info+xml MIME body the <broadcast-ind> element set to "true" as defined in clause F.1; and
2) in the case the prearranged group call is initiated using a pre-established session, shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the hname "body" parameter in the headers portion of the SIP URI in the Refer-To header field the <broadcast-ind> element set to "true" as defined in clause F.1.
6.2.8.3 MCPTT emergency private call conditions
6.2.8.3.1 Authorisations
6.2.8.3.1.1 Determining authorisation for initiating an MCPTT emergency private call
If the MCPTT client receives a request from the MCPTT user to originate an MCPTT emergency private call and:
1) if the <allow-emergency-private-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true"; and
a) if the "entry-info" attribute of the <entry> element of the <MCPTTPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UsePreConfigured" and if the <uri-entry> element of the <entry> element of the <MCPTTPrivateRecipient> element contains the MCPTT ID of the MCPTT user targeted by the calling MCPTT user; or
b) if the "entry-info" attribute of the <entry> element of the <MCPTTPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "LocallyDetermined";
then the MCPTT client shall consider the MCPTT emergency private call request to be an authorised request for an MCPTT emergency private call. In all other cases the MCPTT client shall consider the MCPTT emergency private call request to be an unauthorised request for an MCPTT emergency private call.
6.2.8.3.1.2 Determining authorisation for cancelling an MCPTT emergency private call
If the MCPTT client receives a request from the MCPTT user to cancel an MCPTT emergency private call and if the <allow-cancel-private-emergency-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then the MCPTT emergency private call cancellation request shall be considered to be an authorised request for an MCPTT emergency private call cancellation.
In all other cases, the MCPTT emergency private call cancellation request shall be considered to be an unauthorised request for an MCPTT emergency private call cancellation.
6.2.8.3.1.3 Determining authorisation for initiating or cancelling an MCPTT emergency alert to a MCPTT user
If the MCPTT client receives a request from the MCPTT user to send an MCPTT emergency alert to an MCPTT user and:
1) if the <allow-activate-emergency-alert> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user as specified in 3GPP TS 24.484 [50] is set to a value of "true"; and
2) if the "entry-info" attribute of the <entry> element of the <PrivateEmergencyAlert> element contained within the <OnNetwork> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of:
a) "UsePreConfigured", and if the <uri-entry> element of the <entry> element of the <PrivateEmergencyAlert> element of the <OnNetwork> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) contains the MCPTT ID of the targeted MCPTT user; or
b) "LocallyDetermined";
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.
If the MCPTT client receives a request from the MCPTT user to cancel an MCPTT emergency alert to an MCPTT user, and if the <allow-cancel-emergency-alert> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user as specified in 3GPP TS 24.484 [50] is set to a value of "true", 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.
6.2.8.3.2 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" and this is an authorised request for an MCPTT emergency private call as determined by the procedures of clause 6.2.8.3.1.1, the MCPTT client:
1) shall set the MCPTT emergency state if not already set;
2) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP request an <emergency-ind> element set to "true" and set the MCPTT emergency private call state to "MEPC 2: emergency-pc-requested";
3) if the MCPTT user has also requested an MCPTT emergency alert to be sent and this is an authorised request for MCPTT emergency alert as determined by the procedures of clause 6.2.8.3.1.3, shall:
a) include in the application/vnd.3gpp.mcptt-info+xml MIME body the <alert-ind> element set to "true" and set the MCPTT private emergency alert state to "MPEA 2: emergency-alert-confirm-pending"; and
b) include in the SIP request the specific location information for MCPTT emergency alert as specified in clause 6.2.9.1;
4) if the MCPTT user has not requested an MCPTT emergency alert to be sent, shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to "false"; and
5) if the MCPTT emergency private priority state of this private call is set to a value other than "MEPP 2: in-progress" shall set the MCPTT emergency private priority state to "MEPP 3: confirm-pending".
6.2.8.3.3 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" and this is an authorised request for an MCPTT emergency private call as determined by the procedures of clause 6.2.8.3.1.1, or the MCPTT emergency private priority state of the call is set to "MEPP 2: in-progress", the MCPTT client shall include in the SIP request a Resource-Priority header field populated with the values for an MCPTT emergency private call as specified in clause 6.2.8.1.15.
NOTE: The MCPTT client ideally would not need to maintain knowledge of the in-progress emergency state of the call (as tracked on the MCPTT client by the MCPTT client emergency private state) but can use this knowledge to provide a Resource-Priority header field set to emergency level priority, which starts the infrastructure priority adjustment process sooner than otherwise would be the case.
If this is an authorised request to cancel the MCPTT emergency private call as determined by the procedures of clause 6.2.8.3.1.2, or the MCPTT emergency private priority state of the private call is "MEPP 1: no-emergency" or "MEPP 3: cancel-pending", the MCPTT client 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.2.8.1.15.
6.2.8.3.4 Receiving a SIP 2xx response to a SIP request for an MCPTT emergency private call
This clause is referenced from other procedures.
On receiving a SIP 2xx response to a SIP request for an MCPTT emergency private call and if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted", the MCPTT client:
1) shall set the MCPTT emergency private priority state of the call to "MEPP 2: in-progress" if it was not already set;
2) shall set the MCPTT emergency private call state to "MEPC 3: emergency-pc-granted"; and
3) if the MCPTT private emergency alert state is set to "MPEA 2: emergency-alert-confirm-pending" and the SIP 2xx response to the SIP request for a priority private call does not contain a Warning header field as specified in clause 4.4 with the warning text containing the mcptt-warn-code set to "149", shall set the MCPTT private emergency alert state to "MPEA 3: emergency-alert-initiated".
6.2.8.3.5 Receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to a SIP request for an MCPTT emergency private call
Upon receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to a SIP request for an MCPTT emergency private call and if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted", the MCPTT client:
1) shall set the MCPTT emergency private call state to "MEPC 1: emergency-pc-capable";
2) if the MCPTT emergency private priority state of the private call is "MEPP 3: confirm-pending" shall set the MCPTT emergency private priority state of the private call to "MEPP 1: no-emergency"; and
3) if the sent SIP request for an MCPTT emergency private 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 private emergency alert state to "MPEA 1: no-alert".
6.2.8.3.6 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 MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.
NOTE 1: This procedure assumes that the MCPTT client in the calling procedure has verified that the MCPTT user has made an authorised request for cancelling MCPTT the in-progress emergency private call state of the call.
The MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";
2) shall clear the MCPTT emergency state; and
3) shall set MCPTT emergency private priority state of the MCPTT emergency private call to "MEPP 3: cancel-pending".
NOTE 2: This is the case of an MCPTT user who has initiated an MCPTT emergency private call and wants to cancel it.
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 MCPTT user has indicated only the MCPTT emergency private call should be cancelled, the MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false"; and
2) shall set the MCPTT emergency private priority state of the MCPTT emergency private call to "MEPP 3: cancel-pending";
NOTE 3: This is the case of an MCPTT user has initiated both an MCPTT emergency private call and an MCPTT emergency alert and wishes to only cancel the MCPTT emergency private call. 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 MCPTT user has indicated that the MCPTT emergency alert on the MCPTT private call should be cancelled in addition to the MCPTT emergency private call, the MCPTT client:
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in annex F.1 with the <emergency-ind> element set to "false";
2) shall, if this is an authorised request to cancel an MCPTT emergency alert as determined by the procedures of clause 6.2.8.3.1.3:
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) if this is not an authorised request to cancel an MCPTT emergency alert as determined by the procedures of clause 6.2.8.3.1.3, should indicate to the MCPTT user they are not authorised to cancel the MCPTT emergency alert;
4) shall set the MCPTT emergency private priority state of the MCPTT emergency private call to "MEPP 3: cancel-pending"; and
5) shall clear the MCPTT emergency state.
NOTE 4: This is the case of an MCPTT user that has initiated both an MCPTT emergency private call and an MCPTT emergency alert and wishes to cancel both.
6.2.8.3.7 Receiving a SIP INFO request in the dialog of a SIP request for a priority private call
This clause is referenced from other procedures.
Upon receiving a SIP INFO request within the dialog of the SIP request for a priority private 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 [54]; 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 MCPTT client:
1) if the MCPTT private emergency alert state is set to "MPEA 2: emergency-alert-confirm-pending":
a) if the <alert-ind> element is set to a value of "false", shall set the MCPTT private emergency alert state to "MPEA 1: no-alert"; and
b) if the <alert-ind> element set to a value of "true", shall set the MCPTT private emergency alert state to "MPEA 3: emergency-alert-initiated"; and
2) if the MCPTT private emergency alert state is set to "MPEA 4: Emergency-alert-cancel-pending":
a) if the <alert-ind> element is set to a value of "true", shall set the MCPTT private emergency alert state to "MPEA 3: emergency-alert-initiated"; and
b) if the <alert-ind> element is set to a value of "false", shall set the MCPTT private emergency alert state to "MPEA 1: no-alert".
6.2.8.3.8 SIP re-INVITE request for cancelling the MCPTT emergency private call state by a third-party
This clause is referenced from other procedures.
Upon receiving a request to cancel the MCPTT emergency private call state from an MCPTT user other than the originator of the MCPTT emergency private call, the MCPTT client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] with the clarifications given below.
The MCPTT client:
NOTE 1: This procedure assumes that the calling procedure has verified that the MCPTT user has made an authorised request for cancelling the MCPTT emergency private call state of the call.
1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body as defined in clause F.1 with the <emergency-ind> element set to "false";
2) shall set the MCPTT emergency private priority state of the MCPTT emergency private call to "MEPP 3: cancel-pending"; and
3) if the MCPTT user has indicated that an MCPTT emergency alert associated with the MCPTT emergency private call originated by another MCPTT user should be cancelled and this is an authorised request for an MCPTT emergency alert cancellation as determined by the procedures of clause 6.2.8.3.1.3:
a) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <alert-ind> element set to 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 2: When an MCPTT emergency alert is cancelled by a MCPTT user other than its originator, the <originated-by> element is needed to identify which MCPTT emergency alert is being cancelled, as conceivably each participant in the MCPTT emergency private call could have originated an MCPTT emergency alert.
6.2.8.3.9 Retrieving a KMS URI associated with an MCPTT ID
If the MCPTT client needs to retrieve a KMS URI associated to an identified MCPTT ID for on network operation, the MCPTT client:
1) shall search for the <entry> element of the <PrivateCallURI> element of the <PrivateCallList> element entry of the <Common> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) containing the identified MCPTT ID;
a) if the identified MCPTT ID is found and if the <entry> element of the <PrivateCallKMSURI> element of the <anyExt> element of the <PrivateCallList> element entry identified is not empty, shall retrieve the KMS URI contained therein; or
b) if the identified MCPTT ID is not found or the <entry> element of the <PrivateCallKMSURI> element is empty, shall retrieve the <kms> element of the <App-Server-Info> element of the <on-network> element of the MCPTT UE initial configuration document (see the MCPTT UE initial configuration document in 3GPP TS 24.484 [50]) and consider that to be the KMS URI associated with the MCPTT ID.
If the MCPTT client needs to retrieve a KMS URI associated to an identified MCPTT ID for off network operation, the MCPTT client:
1) shall search for /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/MCPTTID leaf node containing the identified MCPTT ID (see the MCPTT user profile MO in 3GPP TS 24.483 [45]);
a) if the identified MCPTT ID is found:
i) shall retrieve the /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/PrivateCallKMSURI leaf node (see the MCPTT user profile MO in 3GPP TS 24.483 [45]); and
ii) if the PrivateCallKMSURI leaf node in the same /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/ interior node as the MCPTTID leaf node containing the identified MCPTT ID is not empty, shall consider its value to be the KMS URI associated with the MCPTT ID; and
b) if the identified MCPTT ID is not found or if the /<x>/<x>/Common/PrivateCall/UserList/<x>/Entry/PrivateCallKMSURI leaf node is empty:
i) shall retrieve /<x>/OnNetwork/AppServerInfo/KMS leaf node (see the MCPTT UE initial configuration document in 3GPP TS 24.483 [45]); and
ii) shall consider the value of the /<x>/OnNetwork/AppServerInfo/KMS leaf node to be the KMS URI associated with the MCPTT ID.
6.2.9 Location information
6.2.9.1 Location information for location reporting
This procedure is initiated by the MCPTT client when it is including location report information:
1) as part of a SIP request containing an MCPTT emergency alert; or
2) as part of a SIP request for a specified location trigger.
The MCPTT client:
1) if location information is being included as part of a SIP request for a specified location trigger criteria as configured in a <TriggeringCriteria> element and <EmergencyTriggeringCriteria> element contained in a <Configuration> element contained in an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in Annex F.3 as received in a SIP MESSAGE request by the procedures of clause 13.3.2:
a) shall include in the SIP request the specific location information as specified by the procedures of clause 13.3.4.2; and
b) shall skip the rest of the steps;
2) if location information is being included as part of a SIP request containing an MCPTT emergency alert:
a) shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in Annex F.3 with a <Report> element included in the <location-info> root element;
b) shall set the <ReportType> element of the <Report> element to a value of "Emergency";
c) if the MCPTT client has been configured with an <EmergencyLocationInformation> element contained in a <Configuration> element contained in an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in Annex F.3 and received in a SIP MESSAGE request by the procedures of clause 13.3.2;
i) shall populate the <CurrentLocation> element of the <Report> element as indicated by the <EmergencyLocationInformation> element contained in the <Configuration> element contained in an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in Annex F.3 and previously received by the procedures of clause 13.3.2; and
ii) shall skip the rest of the steps; and
d) if the MCPTT client has not been configured with an <EmergencyLocationInformation> element contained in a <Configuration> element contained in an application/vnd.3gpp.mcptt-location-info+xml MIME body as specified in Annex F.3 and received in a SIP MESSAGE request by the procedures of clause 13.3.2:
i) 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 Annex F.3.3.
NOTE: According to local policy, additional location information elements specified in Annex F.3.3 can be included in the <CurrentLocation> element in the event that no <EmergencyLocationInformation> element was previously received.