11.1.1 Private call with floor control and first-to-answer call with floor control

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

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

11.1.1.1 General

Clause 11.1.1 specifies the MCPTT client procedures, participating MCPTT function procedures and controlling MCPTT function procedures for on-network private calls with floor control and first-to-answer calls with floor control. The procedures cover both on-demand and pre-established session establishment. The procedures also cover emergency private call initiation, upgrade and cancellation.

For a private call, the MCPTT client shall initiate the call to one MCPTT user

For a first-to-answer call, the MCPTT client shall initiate the call to a list of two or more MCPTT users.

11.1.1.2 MCPTT client procedures

11.1.1.2.1 On-demand private call and first-to-answer call

11.1.1.2.1.1 Client originating procedures

Upon receiving a request from an MCPTT user to establish an MCPTT private call, or upon accepting a request to perform a private call transfer or a private call forwarding, the MCPTT client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [4], with the clarifications given below.

The MCPTT client:

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

2) if the MCPTT user has requested the origination of a first-to-answer call, if the <allow-request-first-to-answer-call> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false", the MCPTT client shall inform the MCPTT user and shall exit this procedure;

3) if the MCPTT user has requested the origination of an MCPTT emergency private call or is originating an MCPTT private call and the MCPTT emergency state is already set, the MCPTT client:

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

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

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

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

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

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

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

9) for the establishment of a private call shall insert in the SIP INVITE request an application/resource-lists+xml MIME body with the MCPTT ID of the invited MCPTT user or the functional alias to be called, according to rules and procedures of IETF RFC 5366 [20];

NOTE 1: The MCPTT client indicates whether an MCPTT ID or a functional alias is to be called as specified in step 14) c) ii).

10) for the establishment of a first-to-answer call shall insert in the SIP INVITE request according to rules and procedures of IETF RFC 5366 [20] an application/resource-lists+xml MIME body with:

a) the MCPTT IDs of the potential target MCPTT users; or

b) the functional alias to be called;

NOTE 2: The MCPTT client indicates whether a list of MCPTT IDs or a functional alias is to be called as specified in step 15) b).

11) if an end-to-end security context needs to be established and if the MCPTT user is initiating a private call then:

a) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [78];

b) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [78];

c) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [78];

d) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID and KMS URI of the invited user as determined by the procedures of clause 6.2.8.3.9 and a time related parameter as described in 3GPP TS 33.180 [78];

e) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [78]; and

g) shall add the MCPTT ID of the originating MCPTT user to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]; and

f) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCPTT user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [78];

12) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarification given in clause 6.2.1 and with a media stream of the offered media-floor control entity;

13) if implicit floor control is required, shall comply with the conditions specified in clause 6.4 and:

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

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

14) if the MCPTT user is initiating a private call then:

a) if force of automatic commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include in the SIP INVITE request a Priv-Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [18];

b) if force of automatic commencement mode at the invited MCPTT client is not requested by the MCPTT user and:

i) if automatic commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include in the SIP INVITE request an Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [18]; and

ii) if manual commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include in the SIP INVITE request an Answer-Mode header field with the value "Manual" according to the rules and procedures of IETF RFC 5373 [18]; and

b1) if the MCPTT client initiates the private call upon accepting a request to perform a private call transfer, and the received SIP MESSAGE request contains a <replaces-header-value> 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 then

i) shall include a SIP Replaces header field with the header field value set to the value in the <replaces-header-value> element of the incoming SIP MESSAGE request; and

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

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

ii) an <anyExt> element containing:

A) the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the call request;

B) if the MCPTT client needs to include an active functional alias in the initial SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias; and

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

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

14A) if the MCPTT client initiates the private call upon accepting a request to perform a private call transfer then:

a) shall include in the SIP INVITE request a Priv-Answer-Mode header field with the same value as in the MCPTT call to be transferred according to the rules and procedures of IETF RFC 5373 [18]; and

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

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

ii) an <anyExt> element containing:

A) if the MCPTT client needs to include an active functional alias in the initial SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias;

B) with the <call-transfer-ind> element set to "true"; and

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

14B) if the MCPTT client initiates the private call upon accepting a request to perform a private call forwarding then:

a) shall include in the SIP INVITE request a Priv-Answer-Mode header field with the same value as in the MCPTT call to be forwarded according to the rules and procedures of IETF RFC 5373 [18];

b) if the "SIP MESSAGE request for forwarding private call request for terminating client" contained a <forwarding-reason> with a value of "immediate", shall append an entry containing the MCPTT ID of the forwarded MCPTT user to the <forwarding-immediate-list>;

c) if the "SIP MESSAGE request for forwarding private call request for terminating client" contained a <forwarding-reason> with a value of "no-answer", or "manual-input", append an entry containing the MCPTT ID of the forwarded MCPTT user to the <forwarding-other-list>;

d) shall cache both the <forwarding-immediate-list> and the <forwarding-other-list> until a final response for the SIP INVITE is received; and

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

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

ii) an <anyExt> element containing:

A) if the MCPTT client needs to include an active functional alias in the initial SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias;

B) the <call-forwarding-ind> element set to "true";

C) the <forwarding-immediate-list> element;

D) the <forwarding-other-list> element; and

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

15) if the MCPTT user is initiating a first-to-answer call shall contain an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with:

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

b) an <anyExt> element containing:

i) the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the call request;

ii) if the MCPTT client needs to include an active functional alias in the initial SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias; and

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

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

16) 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 for this private call is set to "MEPP 2: in-progress", the MCPTT client shall comply with the procedures in clause 6.2.8.3.3; and

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

Upon receiving a SIP 183(Session Progress) response to the SIP INVITE request the MCPTT client:

1) may indicate the progress of the session establishment to the inviting MCPTT user.

Upon receiving a SIP 200 (OK) response to the SIP INVITE request the MCPTT client:

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

2) if the sent SIP INVITE request was for the origination of a first-to-answer call and the SDP answer contained in the received SIP 200 (OK) response contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCPTT ID of the sender of the SIP 200 (OK) response from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78];

b) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.180 [78];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [78];

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails:

i) if the sent SIP INVITE request was a request for an MCPTT emergency private call and if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested, the MCPTT client:

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 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". and

ii) shall release the session as specified in the procedures of clause 11.1.3.1.1.1 with the following clarifications:

A) shall include in the SIP BYE request an application/vnd.3gpp.mcptt-info+xml MIME body containing a <release-reason> element set to a value of "authentication of the MIKEY-SAKE I_MESSAGE failed"; and

B) shall skip the remaining steps in the present clause; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the originating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [78]; and

ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [46];

NOTE 5: With the PCK successfully shared between the originating MCPTT client and the terminating MCPTT client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.

3) if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted", shall perform the actions specified in clause 6.2.8.3.4; and

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

4) if the sent SIP INVITE request was for the origination of a first-to-answer call and the received SIP 200 (OK) response contains an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcpttinfo> element containing the <mcptt-Params> element containing an <mcptt-called-party-id> element, may display the value of the <mcptt-called-party-id> element; and

5) shall notify the user that the call has been successfully established.

Upon receiving a SIP 300 (Multiple Choices) response to the SIP INVITE request the MCPTT client shall use the MCPTT ID of MCPTT user contained in the <mcptt-request-uri> element of the received application/vnd.3gpp.mcptt-info MIME body as the MCPTT ID of the invited MCPTT user and shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [4], with the clarifications given in this clause and with the following additional clarifications:

1) shall insert in the newly generated SIP INVITE request an application/resource-lists+xml MIME body with the MCPTT ID of the invited MCPTT user in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info MIME body in the received SIP 300 (Multiple Choices) response;

2) shall not include a <call-to-functional-alias-ind> element into the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

3) shall include a <called-functional-alias-URI> element into the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body with the target functional alias URI used in the initial SIP INVITE request for establishing a private call.

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

1) if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested"; or

2) if the MCPTT emergency private call state is set to "MEPC 3: emergency-pc-granted";

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

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

11.1.1.2.1.2 Client terminating procedures

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

The MCPTT client:

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

a) MCPTT client is already occupied in another session and the number of simultaneous sessions exceeds <MaxCall>, the maximum simultaneous MCPTT session for private call, as specified in TS 24.484 [50];

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

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

otherwise, continue with the rest of the steps.

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

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

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

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

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

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

b) if the session was established with a <session-type> of "first-to-answer"; shall temporarily save the current value of the MCPTT emergency private priority (MEPP) state;

NOTE 2: The current value of the MCPTT emergency private priority (MEPP) state needs to be temporarily saved because the MCPTT client may not be the one selected to terminate the first to answer emergency private call. Hence, the MCPTT client needs to be able to restore the MCPTT emergency private priority (MEPP) state to the saved value.

c) shall set the MCPTT emergency private priority state to "MEPP 2: in-progress" for this private call;

4) if the SDP offer of the SIP INVITE request contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

a) shall extract the MCPTT ID of the originating MCPTT user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78];

b) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.180 [78];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [78];

d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP INVITE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [47], and include warning text set to "136 authentication of the MIKEY-SAKE I_MESSAGE failed" in a Warning header field as specified in clause 4.4; and

e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [78]; and

ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [78];

NOTE 3: With the PCK successfully shared between the originating MCPTT client and the terminating MCPTT client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.

5) if an end-to-end security context needs to be established and if the <session-type> in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request is set to "first-to-answer" then:

a) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [78];

b) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [78];

d) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID and KMS URI of the originator of the SIP INVITE request as determined by the procedures of clause 6.2.8.3.9 and a time related parameter as described in 3GPP TS 33.180 [78];

e) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [78];

f) shall add the MCPTT ID of the MCPTT user to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]; and

NOTE 4: The initiator of the MIKEY-SAKKE I_MESSAGE is in this case the terminating client from the perspective of the call.

g) shall sign the MIKEY-SAKKE I_MESSAGE using the MCPTT user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [78];

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

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

7A) may display to the MCPTT user the functional alias of the inviting MCPTT user, if provided;

8) if the <session-type> in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request is set to "first-to-answer":

a) shall notify the user of the incoming call;

b) shall not forward the first-to-answer call;

c) if the MCPTT user is busy on another call, shall send a SIP 486 (Busy Here) to the SIP INVITE request according to 3GPP TS 24.229 [4] and not continue with any further steps in this clause; and

d) if the MCPTT user does not answer the call within a time decided by the client implementation, the MCPTT client shall send a SIP 480 (Temporarily Unavailable) to the SIP INVITE request according to 3GPP TS 24.229 [4] and not continue with any further steps in this clause;

NOTE 5: In the conditions below, as the SIP layer implements the actions for commencement mode, it is assumed that the Answer-Mode or Priv-Answer-Mode header fields are set correctly in line with the setting of the <session-type> in the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request.

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

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

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

c) SIP INVITE request contains a Priv-Answer-Mode header field with the value of "Auto"; and

10) shall perform the manual commencement procedures specified in clause 6.2.3.2.1 if either of the following conditions are met:

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

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

c) SIP INVITE request contains a Priv-Answer-Mode header field with the value of "Manual".

Upon receiving the SIP CANCEL request cancelling a SIP INVITE request for which a dialog exists at the MCPTT client and a SIP 200 (OK) response has not yet been sent to the SIP INVITE request then the MCPTT client:

1) if the session was established with a <session-type> of "first-to-answer", may notify the MCPTT user of the cancellation of the call;

2) if a temporary MCPTT emergency private priority (MEPP) state value was saved in step 3) b) above:

a) shall restore the MCPTT emergency private priority (MEPP) state to the temporary MCPTT emergency private priority (MEPP) state value; and

b) shall discard the temporary MCPTT emergency private priority (MEPP) state value;

3) shall send a SIP 200 (OK) response to the SIP CANCEL request according to 3GPP TS 24.229 [4]; and

4) shall send a SIP 487 (Request Terminated) response to the SIP INVITE request according to 3GPP TS 24.229 [4].

Upon receiving a SIP BYE request for an established dialog, the MCPTT client:

1) if the session was established with a <session-type> of "first-to-answer" and:

a) if the received SIP BYE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <release-reason> element set to a value of "not selected for call" or "authentication of the MIKEY-SAKE I_MESSAGE failed":

i) if a temporary MCPTT emergency private priority (MEPP) state value was saved in step 3) b) above, shall restore the MCPTT emergency private priority (MEPP) state to the temporary MCPTT emergency private priority (MEPP) state value saved in step 3) b) above; and

b) may notify the MCPTT user of the release of the call; and

2) shall follow the procedures in clause 11.1.4.2.

NOTE 6: The above conditions for SIP CANCEL and SIP BYE cover the case for a first-to-answer call where the MCPTT server has already established the private call with another MCPTT client and needs to immediately cancel or release the dialogs with other MCPTT clients.

11.1.1.2.1.3 Client terminating procedures for reception of SIP re-INVITE request

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

Upon receipt of a SIP re-INVITE request for an existing private call session, the MCPTT client shall:

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

a) should display to the MCPTT user an indication that this is a SIP re-INVITE request to upgrade this call to an MCPTT emergency private call and:

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

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

b) shall set the MCPTT emergency private priority state to "MEPP 2: in-progress" for this private call;

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

a) should display to the MCPTT user an indication that this is a SIP re-INVITE request to downgrade this emergency private call to a normal priority private call and:

i) should display the MCPTT ID of the sender of the SIP re-INVITE request contained in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

ii) if the <alert-ind> element is set to "false" should display to the MCPTT user an indication that the MCPTT emergency alert is cancelled;

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

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

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

b) shall set the MCPTT emergency private priority state to "MEPP 1: no-emergency" for this private call; and

c) if the MCPTT emergency private call state of the call is set to "MEPC 3: emergency-call-granted", shall set the MCPTT emergency private call state of the call to "MEPC 1: emergency-pc-capable";

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

4) may display to the MCPTT user the MCPTT ID of the inviting MCPTT user if not done so in step 1 or step 2 above;

NOTE 1: As this is a re-INVITE for an existing MCPTT private call session, there is no attempt made to change the answer-mode from its current state.

4A) may display to the MCPTT user the functional alias of the inviting MCPTT user, if provided;

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

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

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

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

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

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

11.1.1.2.1.4 MCPTT in-progress emergency cancel

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

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

The MCPTT client:

1) if the MCPTT user is not authorised to cancel the in-progress emergency condition on an MCPTT emergency private call as determined by the procedures of clause 6.2.8.3.1.2, the MCPTT client:

a) should indicate to the MCPTT user that they are not authorised to cancel the in-progress emergency condition on an MCPTT emergency private call; and

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

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

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

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

5) shall include in the SIP re-INVITE request an SDP offer the media parameters as currently established;

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

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

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

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

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

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

2) shall set the MCPTT emergency private priority state of the MCPTT private call to "MEPP 1: no-emergency";

3) shall set the MCPTT emergency private call state of the call to "MEPC 1: emergency-pc-capable"; and

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

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

1) if the SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcptt-info+xml MIME body with an <emergency-ind> element set to a value of "true", the MCPTT client shall set the MCPTT emergency private priority state as "MEPP 2: in-progress";

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

3) if the SIP 4xx response, SIP 5xx response or SIP 6xx response did not contain an application/vnd.3gpp.mcptt-info+xml MIME body, shall set the MCPTT emergency private priority state as "MEPP 2: in-progress" and the MCPTT emergency alert (MPEA) state shall revert to its value prior to entering the current procedure.

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

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

11.1.1.2.1.5 Upgrade to MCPTT emergency private call

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

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

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

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

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

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

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

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

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

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

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

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

2) shall perform the actions specified in clause 6.2.8.3.4.

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

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

11.1.1.2.2 Private call and first-to-answer call using pre-established session

11.1.1.2.2.1 Client originating procedures

Upon receiving a request from an MCPTT user to establish an MCPTT private call within a pre-established session, or upon accepting a request to complete a private call transfer or a private call forwarding within a pre-established session, the MCPTT client shall generate a 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], with the clarifications given below.

If the user requested the private call to be a first-to-answer call and if the <allow-request-first-to-answer-call> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false", the MCPTT client shall inform the MCPTT user and shall exit this procedure.

If the MCPTT user is initiating a private call and an end-to-end security context needs to be established the MCPTT client:

1) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [78];

2) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [78];

3) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [78];

4) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID and KMS URI of the invited user as determined by the procedures of clause 6.2.8.3.9 and a time related parameter as described in 3GPP TS 33.180 [78];

5) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [78];

6) shall add the MCPTT ID of the originating MCPTT user to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]; and

7) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCPTT user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [78].

The MCPTT client populates the SIP REFER request as follows:

1) shall include the Request-URI set to the public service identity identifying the pre-established session on the MCPTT server serving the MCPTT user;

2) shall include the Refer-Sub header field with value "false" according to rules and procedures of IETF RFC 4488 [22];

3) shall include the Supported header field with value "norefersub" according to rules and procedures of IETF RFC 4488 [22];

4) shall include the option tag "multiple-refer" in the Require header field;

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

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

7) shall set the Refer-To header field of the SIP REFER request as specified in IETF RFC 3515 [25] with a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [62] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [20], and with the Content-ID header field set to this "cid" URL;

8) for the initiation of a private call, shall include in the application/resource-lists+xml MIME body a single <entry> element in a <list> element in the <resource-lists> element, where the "uri" attribute of the single <entry> element is set to the MCPTT ID of the called user or the functional alias to be called, extended with the following URI header fields:

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

NOTE 1A: The MCPTT client indicates whether an MCPTT ID or a functional alias is to be called as specified in step 8) c) ii) C).

a) if force of automatic commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include a Priv-Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [18];

b) if force of automatic commencement mode at the invited MCPTT client is not requested by the MCPTT user and:

i) if automatic commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include an Answer-Mode header field with the value "Automatic" according to rules and procedures of IETF RFC 5373 [18]; and

ii) if manual commencement mode at the invited MCPTT client is requested by the MCPTT user, shall include an Answer-Mode header field with the value "Manual" according to rules and procedures of IETF RFC 5373 [18];

i) shall include a SIP Replaces header field with the header field value set to the value in the <replaces-header-value> element of the incoming SIP MESSAGE request; and

c) shall include in an hname "body" parameter:

i) if the SDP parameters of the pre-established session do not contain a media-level section of a media-floor control entity or if end-to-end security is required for the private call, an application/sdp MIME body containing the SDP parameters of the pre-established session according to 3GPP TS 24.229 [4] with the clarifications given in clause 6.2.1. If implicit floor control is required and the pre-established session was not established with an implicit floor request, then the application/sdp MIME body shall contain an implicit floor request as specified in clause 6.4; and

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

A) the <session-type> element set to "private";

B) if the MCPTT client needs to include an active functional alias in the SIP REFER request, the <anyExt> element with the <functional-alias-URI> element set to the URI of the used functional alias;

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

C) the <anyExt> element with the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the call request;

D) if the MCPTT client initiates the private call upon accepting a request to perform a private call transfer then shall include the <call-transfer-ind> set to "true";

E) if the MCPTT client initiates the private call upon accepting a request to perform a private call forwarding then:

x1) if the "SIP MESSAGE request for forwarding private call request for terminating client" contained a <forwarding.reason> with a value of "immediate", shall append an entry containing the MCPTT ID of the forwarded MCPTT user to the <forwarding-immediate-list>;

x2) if the "SIP MESSAGE request for forwarding private call request for terminating client" contained a <forwarding.reason> with a value of "no-answer", or "manual-input", shall append an entry containing the MCPTT ID of the forwarded MCPTT user to the <forwarding-other-list>;

x3) shall cache both the <forwarding-immediate-list> and the <forwarding-other-list> until a final response for the SIP REFER is received;

x4) shall include the <call-forwarding-ind> set to "true";

x5) shall include the <forwarding-immediate-list> element; and

x6) shall include the <forwarding-other-list> element; and

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

9) for an initiation of a first-to-answer call, shall include in the application/resource-lists+xml MIME body an <entry> element in a <list> element in the <resource-lists> element for each of the targeted MCPTT users, with each <entry> element containing a "uri" attribute set to the MCPTT ID of the targeted user, extended with an hname "body" parameter in the headers portion of the SIP URI or a single <entry> element in a <list> element in the <resource-lists> element containing a "uri" attribute set to the functional alias is to be called, extended with hname "body" parameter in the headers portion of the SIP URI containing:

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

NOTE 3A: The MCPTT client indicates whether a list of MCPTT IDs or a functional alias is to be called as specified in step 9) b) ii).

a) if the SDP parameters of the pre-established session do not contain a media-level section of a media-floor control entity, an application/sdp MIME body containing the SDP parameters of the pre-established session according to 3GPP TS 24.229 [4] with the clarification given in clause 6.2.1. If implicit floor control is required and the pre-established session was not established with an implicit floor request, then the application/sdp MIME body shall contain an implicit floor request as specified in clause 6.4; and

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

i) the <session-type> element set to "first-to-answer"; and

ii) an <anyExt> element containing:

A) the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the call request;

B) if the MCPTT client needs to include an active functional alias in the SIP REFER request, the <functional-alias-URI> element set to the URI of the used functional alias; and

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

10) if the MCPTT user has requested the origination of an MCPTT emergency private call or is originating an MCPTT private call and the MCPTT emergency state is already set, the MCPTT client:

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

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

11) if the MCPTT emergency private priority state for this call is set to "MEPP 2: in-progress", the MCPTT client shall comply with the procedures in clause 6.2.8.3.3;

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

13) if:

a) implicit floor control is required;

b) the pre-established session was not established with an implicit floor request; and

c) location information has not yet been included in the SIP REFER request;

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

The MCPTT client shall send the SIP REFER request towards the MCPTT server according to 3GPP TS 24.229 [4].

Upon receiving a SIP 300 (Multiple Choices) response to the SIP REFER request the MCPTT client shall use the MCPTT ID of MCPTT user contained in the <mcptt-request-uri> element of the received application/vnd.3gpp.mcptt-info MIME body as the MCPTT ID of the invited MCPTT user and shall generate a 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], with the clarifications given below in this clause with following additional clarifications:

1) shall insert in the newly generated SIP REFER request an application/resource-lists+xml MIME body with the MCPTT ID of the invited MCPTT user in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info MIME body in the received SIP 300 (Multiple Choices) response;

2) shall not include an <call-to-functional-alias-ind> element into the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

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

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

2) if the sent SIP REFER request was for the origination of a first-to-answer call and the received SIP 200 (OK) response contains an application/vnd.3gpp.mcptt-info+xml MIME body with an <mcpttinfo> element containing the <mcptt-Params> element containing an <mcptt-called-party-id> element, may display the value of the <mcptt-called-party-id> element; and

3) shall notify the user that the call has been successfully established..

On receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to the SIP REFER request for an MCPTT emergency private call:

1) if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested", the MCPTT client shall perform the actions specified in clause 6.2.8.3.5; and

2) shall skip the remaining steps.

Upon receipt of a SIP re-INVITE request within the pre-established session targeted by the sent SIP REFER request, the MCPTT client:

1) if the sent SIP REFER request was a request to originate a first-to-answer call:

a) if the received SIP re-INVITE request contains an SDP offer including an a=key-mgmt attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:

i) shall extract the MCPTT ID of the sender of the SIP 200 (OK) response from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78];

ii) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.180 [78];

iii) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [78];

iv) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails:

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

D) shall release the session as specified in the procedures of clause 11.1.3.1.2.1 with the following clarifications:

I) shall include in the SIP BYE request an application/vnd.3gpp.mcptt-info+xml MIME body containing a <release-reason> element set to a value of "authentication of the MIKEY-SAKE I_MESSAGE failed"; and

II) shall skip the remaining steps in the present clause; and

v) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:

A) shall extract and decrypt the encapsulated PCK using the originating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [78]; and

B) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [78];

NOTE 4: With the PCK successfully shared between the originating MCPTT client and the terminating MCPTT client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.

2) if the sent SIP REFER request was a request for an MCPTT emergency private call:

a) if the MCPTT emergency private call state is set to "MEPC 2: emergency-pc-requested" or "MEPC 3: emergency-pc-granted":

i) shall set the MCPTT emergency private priority state of the call to "MEPP 2: in-progress" if it was not already set;

ii) shall set the MCPTT emergency private call state to "MEPC 3: emergency-pc-granted"; and

iii) if the MCPTT private emergency alert state is set to "MPEA 2: emergency-alert-confirm-pending" and:

A) 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 private emergency alert state to " MPEA 3: emergency-alert-initiated "; or

B) if the SIP re-INVITE request contains an <alert-ind> element set to a value of "false", shall set the MCPTT private emergency alert state to "MPEA 1: no-alert ";

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

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

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

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

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

11.1.1.2.2.2 Client terminating procedures

The MCPTT client shall follow the procedures for termination of multimedia sessions as specified in clause 11.1.1.2.1.2 with the following clarifications:

1) if the MCPTT client is targeted for a new MCPTT emergency private call, the MCPTT client receives a SIP INVITE with an application/vnd.3gpp.mcptt-info+xml MIME body with an <emergency-ind> set to a value of "true";

2) if the MCPTT client is targeted for a new normal priority MCPTT private call, the MCPTT client receives a SIP re-INVITE request rather than a SIP INVITE request; or

3) if the MCPTT client is targeted for a new MCPTT first-to-answer call, the MCPTT client receives a initial SIP INVITE request.

11.1.1.3 Participating MCPTT function procedures

11.1.1.3.1 Originating procedures

11.1.1.3.1.1 On-demand private call and first-to-answer call

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

1) may reject the SIP INVITE request depending on the value of the Resource-Priority header field if the Resource-Priority header field is included in the received SIP INVITE request according to rules and procedures specified in IETF RFC 4412 [29] and shall not continue with the rest of the steps;

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

NOTE 1: If the received SIP INVITE request contains an emergency indication set to a value of "true", the participating MCPTT function can choose to accept the request.

NOTE 2: If the received SIP INVITE request contains an emergency indication set to a value of "true", the participating MCPTT function can choose to allow an exception to the limit on the number of private calls and accept the request.

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

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

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

5) shall:

a) if the <session-type> is set to "private", determine that the call is a private call; and

b) if the <session-type> is set to "first-to-answer", determine that the call is a first-to-answer-call;

6) if the call is a:

a) private call, determine the public service identity of the controlling MCPTT function for the private call service associated with the originating user’s MCPTT ID identity; or

b) first-to-answer, determine the public service identity of the controlling MCPTT function for the first-to-answer call service associated with the originating user’s MCPTT ID identity;

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

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

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

NOTE 7: How the participating MCPTT function determines the public service identity of the controlling MCPTT function for the private call service or first-to-answer call service associated with the originating user or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

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

7) if the participating MCPTT function is unable to identify the controlling MCPTT function for the private call service or first-to-answer call service associated with the originating user’s MCPTT ID identity, it shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

8) if the incoming SIP INVITE request does not contain an application/resource-lists+xml MIME body, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

9) if the call is a private call and the incoming SIP INVITE request contains an application/resource-lists+xml MIME body with more than one <entry> element in one or more <list> elements in the <resource-lists> element, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

10) if the <allow-private-call> element of the <ruleset> element is not present in the MCPTT user profile document on the participating MCPTT function or is present with the value "false" (see the MCPTT user profile document in 3GPP TS 24.484 [50]), indicating that the user identified by the MCPTT ID is not authorised to initiate private calls, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response, with warning text set to "107 user not authorised to make private calls" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

11) if the call is a private call and:

a) if the received SIP INVITE request includes an Answer-Mode header field as specified in IETF RFC 5373 [18] with the value "Auto" and the <allow-automatic-commencement> element of the <ruleset> element is not present in the MCPTT user profile document on the participating MCPTT function or is present with the value "false" (see the MCPTT user profile document in 3GPP TS 24.484 [50]) indicating that the user identified by the MCPTT ID is not authorised to initiate private call with automatic commencement, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "125 user not authorised to make private call with automatic commencement" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

b) if the received SIP INVITE request includes an Answer-Mode header field as specified in IETF RFC 5373 [18] with the value "Manual" and the <allow-manual-commencement> element of the <ruleset> element is not present in the MCPTT user profile document on the participating MCPTT function or is present with the value "false" (see the MCPTT user profile document in 3GPP TS 24.484 [50]), indicating that the user identified by the MCPTT ID is not authorised to initiate private call with manual commencement, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "126 user not authorised to make private call with manual commencement" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

c) if the received SIP INVITE request contains a <call-transfer-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true" and the originating participating MCPTT function has no cached mapping of the MCPTT ID of the transferred user and the MCPTT ID of the transfer target, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "170 user not authorised to make a private call transfer request" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps;

d) if the received SIP INVITE request contains a <call-forwarding-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true" and the originating participating MCPTT function has no cached mapping of the MCPTT ID of the forwarded user and the MCPTT ID of the target MCPTT user, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "173 user not authorised to make a private call forwarding request" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps; and

e) if:

i) the received SIP INVITE request contains no <call-transfer-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body, or if the received SIP INVITE request contains a <call-transfer-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body and the value is set to "false"; and

ii) if the received SIP INVITE request contains no <call-forwarding-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body, or if the received SIP INVITE request contains a <call-forwarding-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body and the value is set to "false":

then:

i) if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

A) if the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body does not match with one of the <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

B) if configuration is not set in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) that allows the MCPTT user to make a private call to users not contained within the <entry> elements of the <PrivateCall> element;

then:

A) shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "144 user not authorised to call this particular user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

11A) if the call is a first-to-answer call and:

a) if the <allow-request-first-to-answer-call> element of the <ruleset> element is not present in the MCPTT user profile document or is set to a value of "false" (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

then:

a) shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "156 user not authorised to originate a first-to-answer call" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

12) if the call is a first-to-answer call and if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) if:

i) the "uri" attribute of each and every <entry> element in a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body does not match with any of the <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

ii) if configuration is not set in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) that allows the MCPTT user to make a private call to users not contained within the <entry> elements of the <PrivateCall> element;

then:

i) shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "153 user not authorised to call any of the users requested in the first-to-answer call" in a Warning header field as specified in c clause 4.4 and shall not continue with the rest of the steps;

13) if the call is a first-to-answer call or a private call, the received SIP INVITE request contains the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyEXT> element with the <call-to-functional-alias-ind> element set to "true" and the <functional-alias-URI> element, and the <ListOfAllowedFAsToCall> element exists with one or more <entry> elements within the entry of the FunctionalAliasList element corresponding to the calling <functional-alias-URI> in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) if the "uri" attribute of the <entry> element in a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body does not match with any of the <entry> elements of the <ListOfAllowedFAsToCall> element of the entry within the FunctionalAliasList element corresponding to the calling <functional-alias-URI> of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

then:

a) shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "171 functional alias not allowed to call this particular functional alias" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

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

15) shall generate a SIP INVITE request as specified in clause 6.3.2.1.3 with the following clarifications:

a) if the call is a first-to-answer call and if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]), then only the <entry> elements in a <list> element of the <resource-lists> element of the application/resource-lists MIME+xml body that have a "uri" attribute that matched with an <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) are included in the application/resource-lists+xml MIME body and the <session-type> is set to "first-to-answer" in the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request generated in clause 6.3.2.1.3;

16) shall set the Request-URI to the public service identity of the controlling MCPTT function as determined by step 6);

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

18) if the call is a private call and:

a) if a Priv-Answer-Mode header field specified in IETF RFC 5373 [18] was received in the incoming SIP INVITE request with a value of "Manual", shall not include a Priv-Answer-Mode header field in the outgoing SIP INVITE request;

b) if the <allow-force-auto-answer> element of the <ruleset> element is not present in the MCPTT user profile document on the participating MCPTT function or is present with the value "false" (see the MCPTT user profile document in 3GPP TS 24.484 [50]), and the Priv-Answer-Mode header field specified in IETF RFC 5373 [18] was received in the incoming SIP INVITE request with a value of "Auto", shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "143 not authorised to force auto answer" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

c) if the <allow-force-auto-answer> element of the <ruleset> element is present in the MCPTT user profile document with the value "true" (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function, and the Priv-Answer-Mode header field specified in IETF RFC 5373 [18] was received in the incoming SIP INVITE request with a value of "Auto", shall include the Priv-Answer-Mode header field set to a value of "Auto" in the outgoing SIP INVITE request;

d) if a Priv-Answer-Mode header field containing the value of "Auto" has not been included in the outgoing SIP INVITE request as specified in step 17) above and the incoming "SIP INVITE request for originating participating MCPTT function" contained an Answer-Mode header field as specified in IETF RFC 5373 [18], then shall populate the Answer-Mode header field of the outgoing SIP INVITE request with the contents of the Answer-Mode header field from the incoming "SIP INVITE request for originating participating MCPTT function";

19) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for originating participating MCPTT function", as specified in clause 6.3.2.1.1.1;

19a) if the received SIP INVITE request contains the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyEXT> element with the <functional-alias-URI> element, then shall check if the status of the functional alias is activated for the MCPTT ID. If the functional alias status is activated, then the participating MCPTT function shall set the <functional-alias-URI> element of the <anyEXT> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP INVITE request to the received value, otherwise shall not include a <functional-alias-URI> element;

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

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

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

if:

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

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

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

otherwise:

if:

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

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

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

Upon receiving a SIP 180 (Ringing) response, the participating MCPTT function:

1) shall generate a SIP 180 (Ringing) response to the SIP INVITE request as specified in the clause 6.3.2.1.5.1;

2) shall include the P-Asserted-Identity header field as received in the incoming SIP 180 (Ringing) response;

3) shall include Warning header field(s) received in the incoming SIP 180 (Ringing) response; and

4) shall send the SIP 180 (Ringing) response to the inviting MCPTT client according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response, the participating MCPTT function:

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

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

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

4) shall include the P-Asserted-Identity header field received in the incoming SIP 200 (OK) response into the outgoing SIP 200 (OK) response;

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

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

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

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

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

The participating MCPTT function shall forward any other SIP response that does not contain SDP, including any MIME bodies contained therein, along the signalling path to the originating network according to 3GPP TS 24.229 [4].

11.1.1.3.1.2 Private call and first-to-answer call initiation using pre-established session

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

1) the Refer-To header field containing a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [62] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [20] containing one or more <entry> element(s) in one or more <list> elements in the <resource-lists> element, where the <entry> element contains a "uri" attribute containing a SIP URI set to the MCPTT ID of the called user(s);

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

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

the participating function:

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

NOTE 1: If the application/vnd.3gpp.mcptt-info MIME body included in the SIP REFER request as described at the top of the present clause contains an <emergency-ind> element or <imminentperil-ind> element set to a value of "true", and this is an authorised request for originating a priority call as determined by clause 6.3.2.1.8.1, the participating MCPTT function can according to local policy choose to accept the request.

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

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

4) if the received SIP REFER request does not contain an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

5) if the received SIP REFER request contains an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field with more than one <entry> element in a one or more <list> elements in the <resource-lists> element each with an application/vnd.3gpp.mcptt-info MIME body with the <session-type> element:

a) not set to "first-to-answer", shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps; or

b) set to "first-to-answer", determine that the call is a first-to-answer call;

6) if the received SIP REFER request contains an application/resource-lists MIME body referenced by a "cid" URL in the Refer-To header field with only one <entry> element with an application/vnd.3gpp.mcptt-info MIME body with the <session-type> element:

a) not set to "private", shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps; or

b) set to "private", determine that the call is a private call;

7) if the call is a:

a) private call, shall determine the public service identity of the controlling MCPTT function for the private call service associated with the originating user’s MCPTT ID; or

b) first-to-answer call, shall determine the public service identity of the controlling MCPTT function for the first-to-answer call service associated with the originating user’s MCPTT ID;

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

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

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

NOTE 5: How the participating MCPTT function determines the public service identity of the controlling MCPTT function for the private call service or first-to-answer call service associated with the originating user or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

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

8) if the participating MCPTT function is unable to identify the controlling MCPTT function for the private call service or first-to-answer call service associated with the originating user’s MCPTT ID, it shall reject the REFER request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

9) if the <allow-private-call> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function or is present with the value "false", indicating that the user identified by the MCPTT ID is not authorised to initiate private calls, shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response to the SIP REFER request, with warning text set to "107 user not authorised to make private calls" in a Warning header field as specified in clause 4.4;

10) if the call is a private call:

a) if the received SIP REFER request includes an Answer-Mode header field as specified in IETF RFC 5373 [18] set to "Auto" contained in the headers portion of the SIP URI present in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, and the <allow-automatic-commencement> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function or is present with the value "false" (indicating that the user identified by the MCPTT ID is not authorised to initiate private call with automatic commencement), shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "125 user not authorised to make private call with automatic commencement" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

b) if the received SIP REFER request includes an Answer-Mode header field as specified in IETF RFC 5373 [18] set to "Manual" contained in the headers portion of the SIP URI present in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, and the <allow-manual-commencement> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function or is present with the value "false" (indicating that the user identified by the MCPTT ID is not authorised to initiate private call with manual commencement), shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response including warning text set to "126 user not authorised to make private call with manual commencement" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

c) if the <allow-force-auto-answer> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function or is present with the value "false", and the SIP REFER request contained a Priv-Answer-Mode header field as specified in IETF RFC 5373 [18] set to "Auto" in the headers portion of the SIP URI in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "143 not authorised to force auto answer" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

d) if the received SIP REFER request contains a <call-transfer-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true" and the originating participating MCPTT function has no cached mapping of the MCPTT ID of the transferred user and the MCPTT ID of the transfer target, shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "170 user not authorised to make a private call transfer request" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps;

e) if the received SIP REFER request contains a <call-forwarding-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "true" and the originating participating MCPTT function has no cached mapping of the MCPTT ID of the forwarded user and the MCPTT ID of the target MCPTT user, shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "173 user not authorised to make a private call forwarding request" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps; and

f) if:

i) the received SIP REFER request contains no <call-transfer-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body, or if the received SIP REFER request contains a <call-transfer-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body and the value is set to "false"; and

ii) if the received SIP REFER request contains no <call-forwarding-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body, or if the received SIP REFER request contains a <call-forwarding-ind> element in the application/vnd.3gpp.mcptt-info+xml MIME body and the value is set to "false";

then:

i) if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

A) if the SIP URI in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field not match with a "uri" attribute of one of the <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

then:

A) shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "144 user not authorised to call this particular user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

10A) if the call is a first-to-answer call and:

then:

a) shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "156 user not authorised to originate a first-to-answer call" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

11) if the call is a first-to-answer call and if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) the "uri" attribute of each and every <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field does not match with the "uri" attribute of any of the <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

b) if configuration is not set in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) that allows the MCPTT user to make a private call to users not contained within the <entry> elements of the <PrivateCall> element;

then:

a) shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "153 user not authorised to call any of the users requested in the first-to-answer call" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

12) if the call is a first-to-answer call or a private call, the received SIP REFER request contains the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyEXT> element with the <call-to-functional-alias-ind> element set to "true" and the <functional-alias-URI> element, the <ListOfAllowedFAsToCall> element exists with one or more <entry> elements within the entry of the FunctionalAliasList element corresponding to the calling <functional-alias-URI> in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) if the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field does not match with the "uri" attribute of any of the <entry> elements of the <ListOfAllowedFAsToCall> element of the entry within the FunctionalAliasList element corresponding to the calling <functional-alias-URI> of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

then:

a) shall reject the "SIP REFER request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "171 functional alias not allowed to call this particular functional alias" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

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

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

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

15) if the URI of the functional alias to be called is included in the application/resource-lists+xml MIME body of the SIP REFER request, shall wait for the receipt of a SIP response to the SIP INVITE request that will be generated in step 16) and sent in step 20). Otherwise, shall send the response to the "SIP REFER request for a pre-established session" towards the MCPTT client according to 3GPP TS 24.229 [4];

16) shall generate a SIP INVITE request as specified in clause 6.3.2.1.4 with the following clarifications:

a) if the call is a first-to-answer call and if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]), then only the <entry> elements of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body that have a "uri" attribute that matched with the "uri" attribute of an <entry> element of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) are included in the application/resource-lists+xml MIME body and the <session-type> is set to "first-to-answer" in the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request generated in clause 6.3.2.1.4;

17) shall set the Request-URI of the SIP INVITE request to the public service identity of the controlling MCPTT function as determined above in step 7);

18) if the call is a private call:

a) if the SIP REFER request contained a Priv-Answer-Mode header field as specified in IETF RFC 5373 [18] set to "Manual" in the headers portion of the SIP URI in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall copy the Priv-Answer-Mode header field from the incoming SIP REFER request to the outgoing SIP INVITE request;

b) if the <allow-force-auto-answer> element of the <ruleset> element is present in the MCPTT user profile document with the value "true" (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function, and the Priv-Answer-Mode header field specified in IETF RFC 5373 [18] was received in the headers portion of the SIP URI in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, with a value set to "Auto", shall copy the Priv-Answer-Mode header field to the outgoing SIP INVITE request; and

c) if a Priv-Answer-Mode header field containing the value of "Auto" has not been copied to the outgoing SIP INVITE request as specified in step 16) above, and the incoming SIP REFER request contained an Answer-Mode header field in the headers portion of the SIP URI in the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, then copy the Answer-Mode header field to the outgoing SIP INVITE request;

19) if the received SIP REFER request contained a Resource-Priority header field, shall include in the outgoing SIP INVITE request a Resource-Priority header field according to rules and procedures of 3GPP TS 24.229 [4] set to the value indicated in the Resource-Priority header field of the received SIP REFER request;

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

19a) if the call is a private call and if the received SIP REFER request contains the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyEXT> element with the <functional-alias-URI> element, then shall check if the status of the functional alias is activated for the MCPTT ID. If the functional alias status is activated, then the participating MCPTT function shall set the <functional-alias-URI> element of the <anyEXT> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the outgoing SIP INVITE request to the received value, otherwise shall not include a <functional-alias-URI> element;

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

if:

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

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

otherwise:

if:

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

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

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

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

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

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

1) if:

a) the received SIP 2xx response was in response to a request for an MCPTT private call; or

b) the received SIP 2xx response was in response to a SIP INVITE request for a first-to-answer call which did not include an a=key-mgmt "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE in the SDP answer;

then:

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

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

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

b) shall send the SIP re-INVITE request towards the MCPTT client within the pre-established session according to 3GPP TS 24.229 [4]; and

c) if the received SIP 2xx response was in response to a request for a first-to-answer call, upon receipt of a SIP 2xx response to the SIP re-INVITE, shall interact with the media plane as specified in 3GPP TS 24.380 [5]; and

3) if the received SIP 2xx response was in response to a SIP INVITE request for a first-to-answer call which was not a request for an MCPTT emergency private call and contains an SDP answer including an a=key-mgmt "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE, the participating MCPTT function:

a) shall generate a SIP re-INVITE request as specified in clause 6.3.2.1.8.7;

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

c) upon receipt of a SIP 2xx response to the SIP re-INVITE, shall interact with the media plane as specified in 3GPP TS 24.380 [5].

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

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

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

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

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

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

2) if the generated final SIP 200 (OK) response to the "SIP REFER request for a pre-established session" has not yet been sent in step 15), shall forward the received SIP response.

11.1.1.3.1.3 Receipt of SIP re-INVITE for MCPTT private call from the served user

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

Upon receipt of a SIP re-INVITE request for an existing MCPTT private call session the participating MCPTT function:

1) may reject the SIP re-INVITE request depending on the value of the Resource-Priority header field if the Resource-Priority header field is included in the received SIP re-INVITE request according to rules and procedures specified in IETF RFC 4412 [29] and skip the rest of the steps;

NOTE 1: If the SIP re-INVITE request contains an emergency indication, the participating MCPTT function can choose to accept the request.

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

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

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

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

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

5) shall generate a SIP re-INVITE request as specified in clause 6.3.2.1.9;

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

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

7) shall, if the SIP re-INVITE request was received within an on-demand session include in the SIP re-INVITE request an SDP containing the current media parameters used by the existing session;

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

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

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

Upon receiving a SIP 200 (OK) response, the participating MCPTT function:

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

2) if the SIP 200 (OK) response is to be sent within an on-demand session shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

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

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

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

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

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

11.1.1.3.2 Terminating procedures

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

In the procedure in this clause a private call requested by an MCPTT user refers to a private call:

1) with no <call-transfer-ind> element present in the application/vnd.3gpp.mcptt-info+xml MIME body element or with a <call-transfer-ind> element present in the application/vnd.3gpp.mcptt-info+xml MIME body element and the value is set to "false"; and

2) with no <call-forwarding-ind> element present in the application/vnd.3gpp.mcptt-info+xml MIME body element or with a <call-forwarding-ind> element present in the application/vnd.3gpp.mcptt-info+xml MIME body element and the value is set to "false".

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

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

NOTE: If the received SIP INVITE request contains an emergency indication set to a value of "true", the participating MCPTT function can choose to accept the request.

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

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

4) if :

a) the <allow-call-forwarding> element exists in the MCPTT user profile document, and the value is set to "true" (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

b) the <call-forwarding-on> element exists in the MCPTT user profile document and the value is set to "true" (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

c) the <call-forwarding-condition> element exists in the MCPTT user profile document, and the value is set to "immediate" (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

then:

a) if the <forwarding-immediate-list> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request exists, shall check if the number of maximum immediate private call forwardings as specified in the <max-immediate-forwardings> element of the <anyExt> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]) has been reached. If reached, the MCPTT server shall reject the "SIP INVITE request for terminating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "174 maximum number of allowed forwardings exceeded" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps;

b) shall reject the "SIP INVITE request for terminating participating MCPTT function" with 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;

c) shall generate a SIP MESSAGE request as described in clause 6.3.2.6 to trigger the call forwarding of a private call and shall include in the application/vnd.3gpp.mcptt-info+xml MIME body:

i) a <forwarding-reason> element set to a value of "immediate";

d) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [4]; and

e) upon receipt of SIP 2xx response to the outgoing SIP MESSAGE requests, the participating MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4] and shall skip the rest of the steps;

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

6) if the binding between the MCPTT ID and public user identity does not exist and if the <allow-call-forwarding> element exists in the MCPTT user profile document, and the value is set to "true" (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and if the <call-forwarding-on> element exists in the MCPTT user profile document, and the value is set to "true" (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and if the <call-forwarding-condition> element exists in the MCPTT user profile document, and the value is set to "no-answer" (see the MCPTT user profile document in 3GPP TS 24.484 [50]):

a) if the incoming SIP INVITE request contains a <forwarding-other-list> element with one or more <entry> elements the MCPTT server shall reject the "SIP INVITE request for terminating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "174 maximum number of allowed forwardings exceeded" in a Warning header field as specified in clause 4.4 and shall skip the rest of the steps;

c) shall generate a SIP MESSAGE request as described in clause 6.3.2.6 to trigger the call forwarding of a private call and shall include in the application/vnd.3gpp.mcptt-info+xml MIME body;

d) shall set the <forwarding-reason> element to a value of "no-answer";

e) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [4]; and

f) Upon receipt of SIP 2xx response to the outgoing SIP MESSAGE requests, the participating MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4] and shall skip the rest of the steps;

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

8) if the call is a private call requested by an MCPTT user and if the called user identified by the MCPTT ID is unable to participate in private calls as identified in the called user’s MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the terminating participating MCPTT function, shall reject the "SIP INVITE request for terminating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "127 user not authorised to be called in private call" in a Warning header field as specified in clause 4.4;

9) if the call is a private call requested by an MCPTT user and if the <session-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body is set to "private" and if the <IncomingPrivateCallList> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) if the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request does not match with one of the <entry> elements of the <IncomingPrivateCallList> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

b) if configuration is not set in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) that allows the MCPTT user to receive a private call by users not contained within the <entry> elements of the <IncomingPrivateCallList> element;

then:

a) shall reject the "SIP INVITE request for terminating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "159 user not authorised to be called by this originating user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

10) if the call is a first-to-answer call or a private call, the received SIP INVITE request contains the application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to "true", the <called-functional-alias-URI> element, and a <functional-alias-URI> element, and the <ListOfAllowedFAsToBeCalledFrom> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) if the functional-alias-URI> element of the <anyEXT> element of the <mcptt-Params> element of the <mcpttinfo> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request does not match with any of the <entry> elements of the <ListOfAllowedFAsToBeCalledFrom> element of the entry within the FunctionalAliasList element corresponding to the called functional alias of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

then:

a) shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "172 functional alias not allowed to be called from this functional alias" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

11) if necessary, shall start timer TNP1 (call forwarding no answer timer) according to the conditions stated in clause 6.3.2.5. If the procedures in clause 6.3.2.5 results in a call forwarding, skip the rest of the steps in this clause.

12) shall perform the automatic commencement procedures specified in clause 6.3.2.2.5.1 and according to IETF RFC 5373 [18] if one of the following conditions are met:

a) "SIP INVITE request for terminating participating MCPTT function" contains an Answer-Mode header field with the value "Auto";

b) "SIP INVITE request for terminating participating MCPTT function" does not contain an Answer-Mode header field and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as per clause 7.3.3 or clause 7.3.4 is set to "auto-answer"; or

c) "SIP INVITE request for terminating participating MCPTT function" contains a Priv-Answer-Mode header field with the value "Auto"; and

13) shall perform the manual commencement procedures specified in clause 6.3.2.2.6.1 and according to IETF RFC 5373 [18] if either of the following conditions are met:

a) "SIP INVITE request for terminating participating MCPTT function" contains an Answer-Mode header field with the value "Manual";

b) "SIP INVITE request for terminating participating MCPTT function" does not contain an Answer-Mode header field and Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as per clause 7.3.3 or clause 7.3.4 is set to "manual-answer"; or

c) "SIP INVITE request for terminating participating MCPTT function" contains a Priv-Answer-Mode header field with the value "Manual".

11.1.1.3.3 Receipt of SIP re-INVITE request by terminating participating function

This clause covers the on-demand session case only.

Upon receipt of a SIP re-INVITE request for an existing MCPTT private call session the participating MCPTT function:

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

NOTE 1: If the SIP re-INVITE request contains an emergency indication, the participating MCPTT function can choose to accept the request.

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

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

4) shall generate a SIP re-INVITE as specified in clause 6.3.2.2.10;

NOTE 2: As this is the modification of an in-progress MCPTT private call, this procedure does not attempt modification of the existing answer-mode of the call.

5) shall include in the SIP re-INVITE request an SDP offer containing the current media parameters used by the existing session; and

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

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

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

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

3) shall copy the P-Asserted-Identity header field from the incoming SIP 200 (OK) response to the outgoing SIP 200 (OK) response;

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

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

The participating MCPTT function shall forward any other SIP response that does not contain SDP along the signalling path to the originating network according to 3GPP TS 24.229 [4].

11.1.1.4 Controlling MCPTT function procedures

11.1.1.4.1 Originating procedures

This clause describes the procedures for inviting an MCPTT user to an MCPTT session. The procedure is initiated by the controlling MCPTT function as the result of an action in clause 11.1.1.4.2

The controlling MCPTT function:

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

NOTE 1: As a result of calling clause 6.3.3.1.2, the <mcptt-calling-user-id> containing the calling user’s MCPTT ID is copied into the outgoing SIP INVITE.

2) if the received SIP INVITE request contains an authorised request for an MCPTT emergency private call as determined by clause 6.3.3.1.13.2:

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

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

c) if the received SIP INVITE request did not contain an alert indication or contains an alert indication set to a value of "true" and is not an authorised request for an MCPTT emergency alert meeting the conditions specified in clause 6.3.3.1.13.1, shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "false";

3) if the received SIP INVITE request contained a <session-type> element in an application/vnd.3gpp.mcptt-info+xml MIME body set to "first-to-answer" shall include in the SIP INVITE request a Priv-Answer-Mode header field with the value "Manual" according to the rules and procedures of IETF RFC 5373 [18];

4) shall copy the MCPTT ID of the MCPTT user listed in the MIME resources body of the incoming SIP INVITE request, into the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the outgoing SIP INVITE request;

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

NOTE 2: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

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

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

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

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

6) shall copy the public user identity of the calling MCPTT user from the P-Asserted-Identity header field of the incoming SIP INVITE request into the P-Asserted-Identity header field of the SIP INVITE request;

7) shall include a Resource-Priority header field populated with the values for an MCPTT emergency private call as specified in clause 6.3.3.1.19, if either of the following conditions is met:

a) if the received SIP INVITE request contains an authorised request for an MCPTT emergency private call as determined in step 2 above; or

b) the originating MCPTT user is in an in-progress emergency private call state with the targeted MCPTT user;

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

9) shall send the SIP INVITE request towards the core network according to 3GPP TS 24.229 [4]; and

10) shall start a private call timer with a value set to the configured max private call duration for the user.

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

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

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

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

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

Upon expiry of the private call timer, the controlling MCPTT function shall follow the procedure for releasing private call session as specified in clause 11.1.4.4.

11.1.1.4.2 Terminating procedures

In the procedures in this clause:

1) <emergency–ind> refers to the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body;

2) <alert–ind> refers to the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body; and

3) <session-type> refers to the <session-type> element of an application/vnd.3gpp.mcptt-info+xml MIME body.

Upon receipt of:

– a "SIP INVITE request for controlling MCPTT function of a private call"; or

– a "SIP INVITE request for controlling MCPTT function of a first-to-answer call";

the controlling MCPTT function:

1) if the <session-type> in the SIP INVITE request is set to "private":

a) shall check whether the public service identity contained in the Request-URI is allocated for private call and perform the actions specified in clause 6.3.7.1 if it is not allocated and skip the rest of the steps; and

b) shall perform actions to verify the MCPTT ID of the inviting MCPTT user in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request, and authorise the request according to local policy, and if it is not authorised the controlling MCPTT function shall return a SIP 403 (Forbidden) response with the warning text as specified in "Warning header field" and skip the rest of the steps;

2) if the <session-type> in the SIP INVITE request is set to "first-to-answer" shall check whether the public service identity contained in the Request-URI is allocated for first-to-answer call and perform the actions specified in clause 6.3.7.1 if it is not allocated and skip the rest of the steps;

3) if the incoming SIP INVITE request does not contain an application/resource-lists+xml MIME body shall reject the SIP INVITE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

4) if the <session-type> is set to "private" and the application/resource-lists+xml MIME body contains more than one <entry> element in a <list> element of the <resource-lists> element, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

5) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec or media format is acceptable by the controlling MCPTT function and if not, reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

6) if received SIP INVITE request includes an <emergency-ind>, shall validate the request as described in clause 6.3.3.1.17;

7) if the received SIP INVITE request contains an unauthorised request for an MCPTT emergency private call as determined by clause 6.3.3.1.13.2:

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

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

8) if a Resource-Priority header field is included in the received SIP INVITE request and if the Resource-Priority header field is set to the value indicated for emergency calls, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps if neither one of the following conditions are true:

a) the SIP INVITE request does not contain an authorised request for an MCPTT emergency call as determined in step 7 above; or

b) the originating MCPTT user is not in an in-progress emergency private call state with the targeted MCPTT user;

8a) if the <session-type> in the received SIP INVITE request is set to "private" and if the SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to a value of "true":

a) shall identify the MCPTT ID(s) of the MCPTT user(s) that have activated the received called functional alias in the application/resource-lists+xml MIME body of the SIP INVITE request by performing the actions specified in clause 9A.2.2.2.8;

b) if unable to determine any MCPTT ID that has activated the received called functional alias in the application/resource-lists+xml MIME body of the SIP INVITE request, shall reject the "SIP INVITE request for controlling MCPTT function of a private call" with a SIP 403 (Forbidden) response including a warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps; and

c) selects one of the identified MCPTT IDs, and shall send a SIP 300 (Multiple Choices) response to the "SIP INVITE request for controlling MCPTT function of a private call" populated according to 3GPP TS 24.229 [4], IETF RFC 3261 [24] with:

A) a Contact header field containing a SIP URI for the MCPTT session identity; and

B) an application/vnd.3gpp.mcptt-info MIME body with an <mcptt-request-uri> element set to the selected MCPTT ID and shall not continue with the rest of the steps in this clause;

NOTE 1: How the controlling MCPTT function selects the appropriate MCPTT ID is implementation-specific.

9) if:

a) the received SIP INVITE request contains an emergency indication set to a value of "true";

b) the originating MCPTT user is not in an in-progress emergency private call state with the targeted MCPTT user; and

c) the <session-type> in the SIP INVITE request is set to "private";

then:

a) shall cache the information that the MCPTT user has initiated an MCPTT emergency private call to the targeted user; and

b) shall cache the information that the MCPTT user is in an in-progress emergency private call state with the targeted MCPTT user;

10) shall perform actions as described in clause 6.3.3.2.2;

11) shall allocate an MCPTT session identity for the MCPTT session;

12) if the <session-type> in the received SIP INVITE request is set to "first-to-answer" and if the SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing the <anyExt> element with the <call-to-functional-alias-ind> element set to a value of "true":

b) if unable to determine any MCPTT ID that has activated the received called functional alias in the application/resource-lists+xml MIME body of the SIP INVITE, shall reject the "SIP INVITE request for controlling MCPTT function of a private call" with a SIP 403 (Forbidden) response including a warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

c) shall copy the URI of the functional alias to be called listed in the application/resource-lists+xml MIME body of the incoming SIP INVITE request, into the <called-functional-alias-URI> element of the <anyEXT> element of the <mcptt-Params> element of the <mcpttinfo> element in the application/vnd.3gpp.mcptt-info+xml MIME body; and

d) shall invite the identified MCPTT ID(s) as specified in clause 11.1.1.4.1;

otherwise shall invite the MCPTT user(s) listed in the application/resource-lists+xml MIME body of received SIP INVITE request as specified in clause 11.1.1.4.1; and

13) if the <session-type> in the received SIP INVITE request is set to "private", shall invite the MCPTT user listed in the application/resource-lists+xml MIME body of received SIP INVITE request as specified in clause 11.1.1.4.1.

Upon receiving a SIP 180 (Ringing) response and if the SIP 180 (Ringing) response or the SIP final response has not yet been sent to the inviting MCPTT client, the controlling MCPTT function:

1) if the SIP 180 (Ringing) response is associated with a SIP INVITE that contained a <session-type> set to "private", shall generate a SIP 180 (Ringing) response to the SIP INVITE request and send the SIP 180 (Ringing) response towards the inviting MCPTT client according to 3GPP TS 24.229 [4]; and

2) if the SIP 180 (Ringing) response is associated with a SIP INVITE that contained a <session-type> set to "first-to-answer", and no other SIP 180 (Ringing) responses have been received that are associated with a SIP INVITE that contained a <session-type> set to "first-to-answer", shall generate a SIP 183 (Session Progress) response to the SIP INVITE request and send the SIP 183 (Session Progress) response towards the inviting MCPTT client according to 3GPP TS 24.229 [4].

Upon receiving a SIP 183 (Session Progress) response to the SIP INVITE request specified in clause 11.1.1.4.1 containing a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [34], if the <session-type> in the SIP INVITE request is set to "private", the controlling MCPTT function supports media buffering and the SIP final response is not yet sent to the inviting MCPTT client, the controlling MCPTT function:

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

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

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

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

NOTE 2: This is the case when the MCPTT user’s request for an MCPTT emergency private call was granted but the request for the MCPTT emergency alert was denied.

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

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

Upon receiving a SIP 200 (OK) response for the SIP INVITE request, the SIP dialog was established as a result of receiving a SIP INVITE request with a <session-type> element set to the value of "private" and the SIP final response has not yet been sent to the inviting MCPTT client, the controlling MCPTT function:

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

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

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

NOTE 3: This is the case when the MCPTT user’s request for an MCPTT emergency private call was granted but the request for the MCPTT emergency alert was denied.

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

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

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

Upon receiving a SIP 200 (OK) response for the SIP INVITE request, the SIP dialog was established as a result of receiving a SIP INVITE request with a <session-type> element set to the value of "first-to-answer" and the SIP final response has not yet been sent to the inviting MCPTT client the controlling MCPTT function:

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

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

3) the received SIP INVITE request contains an emergency indication set to a value of "true":

a) shall cache the information that the MCPTT user has initiated an MCPTT emergency private call to the targeted user; and

b) shall cache the information that the MCPTT user is in an in-progress emergency private call state with the targeted MCPTT user;

NOTE 5: This is the case when the MCPTT user’s request for an MCPTT emergency private call was granted but the request for the MCPTT emergency alert was denied.

5) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element containing an <mcptt-called-party-id> element set to the MCPTT ID that was sent in the corresponding SIP INVITE request;

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

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

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

8) for all other MCPTT clients that were invited due to the controlling MCPTT function receiving a SIP INVITE request with a <session-type> element set to the value of "first-to-answer":

a) shall send a SIP BYE request to release a SIP dialog that has been established since the SIP 200 (OK) response was sent in step6) by following the procedures in clause 6.3.3.1.5 with the clarification that the SIP BYE request contain an application/vnd.3gpp.mcptt-info+xml MIME body including a <release-reason> element set to a value of "not selected for call";

b) shall generate and send a SIP CANCEL request according SIP IETF RFC 3261 [24], to cancel a SIP dialog that has not yet been established since the SIP 200 (OK) response was sent in step 6);

c) on receiving a SIP 200 (OK) to a SIP CANCEL request, shall wait to receive a SIP 487 (Request Terminated) to the original SIP INVITE request sent to the client; and

d) if a SIP 487 (Request Terminated) from the MCPTT client is not received within a time determined by the MCPTT server implementation, shall send a SIP BYE towards the MCPTT client by following the procedures in clause 6.3.3.1.5 with the clarification that the SIP BYE request contain an application/vnd.3gpp.mcptt-info+xml MIME body including a <release-reason> element set to a value of "not selected for call"; and

9) if not successful in cancelling or terminating SIP dialogs in step 7) above, may repeat the SIP CANCEL and SIP BYE requests.

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

The controlling MCPTT function shall forward any other SIP response that does not contain SDP, including any MIME bodies contained therein, along the signalling path to the originating network according to 3GPP TS 24.229 [4].

Upon receiving a SIP BYE request from the originating MCPTT client containing an application/vnd.3gpp.mcptt-info+xml MIME body containing a <release-reason> element set to a value of "authentication of the MIKEY-SAKE I_MESSAGE failed", the controlling MCPTT function:

1) if the received "SIP INVITE request for controlling MCPTT function of a first-to-answer call" contains an emergency indication set to a value of "true":

a) shall delete from cache the information that the MCPTT user has initiated an MCPTT emergency private call to the targeted user; and

b) shall delete from cache the information that the MCPTT user is in an in-progress emergency private call state with the targeted MCPTT user; and

2) shall follow the procedures in clause 11.1.3.3.1.

11.1.1.4.3 Receiving a SIP re-INVITE for upgrade to emergency private call

In the procedures in this clause:

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

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

Upon receiving a SIP re-INVITE request with an emergency indication set to a value of "true", the controlling MCPTT function:

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec or media format is acceptable by the controlling MCPTT function and if not, reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

2) shall validate the request as described in clause 6.3.3.1.17;

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

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

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

4) if a Resource-Priority header field is included in the received SIP re-INVITE request and if the Resource-Priority header field is set to the value indicated for emergency calls, shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response and skip the remaining steps if neither of the following conditions are true:

a) the SIP re-INVITE request does contains an authorised request for an MCPTT emergency call as determined in step 2 above; or

b) the originating MCPTT user is in an in-progress emergency private call state with the targeted MCPTT user;

5) if the SIP re-INVITE request contains an emergency indication set to a value of "true" and the originating MCPTT user is not in an in-progress emergency private call state with the targeted MCPTT user:

a) shall cache the information that the MCPTT user is in an in-progress emergency private call state with the targeted MCPTT user; and

b) if the SIP re-INVITE request contains an alert indication set to "true" and this is an authorised request for an MCPTT emergency alert as specified in clause 6.3.3.1.13.1, shall cache the information that the MCPTT user has sent an MCPTT emergency alert to the targeted user; and

6) shall send a SIP re-INVITE invite towards the MCPTT user listed in the application/resource-lists+xml MIME body of received SIP re-INVITE request as specified in clause 11.1.1.4.5.

Upon receiving a SIP 200 (OK) response for the SIP re-INVITE request and if the SIP response has not yet been sent to the inviting MCPTT client, the controlling MCPTT function:

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

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP re-INVITE request containing the current media parameters used by the existing session;

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

NOTE: When a SIP 200 (OK) response sent to the originator as a response to a SIP INVITE request that contained authorised request(s) for an MCPTT emergency private call and optionally an MCPTT emergency alert, the originator will consider a SIP 200 (OK) response populated in this manner as confirmation that its request(s) for an upgrade to an MCPTT emergency private call and optionally an MCPTT emergency alert were accepted by the controlling function.

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

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

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

11.1.1.4.4 Receiving a SIP re-INVITE for cancellation of emergency private call

In the procedures in this clause:

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

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

Upon receiving a SIP re-INVITE request with an emergency indication set to a value of "false", the controlling MCPTT function:

2) shall validate the request as described in clause 6.3.3.1.17;

3) if the SIP re-INVITE request contains an unauthorised request for an MCPTT emergency private call cancellation as determined by clause 6.3.3.1.13.4:

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

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

c) if the SIP re-INVITE request contains an alert indication set to "false" and this is an unauthorised request for an MCPTT emergency alert cancellation as specified in clause 6.3.3.1.13.3, shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcptt-info+xml MIME body with an <alert-ind> element set to "true; and

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

4) shall reject the SIP re-INVITE request with a SIP 403 (Forbidden) response if a Resource-Priority header field is included in the received SIP re-INVITE request set to the value configured for emergency calls, and skip the remaining steps; and

5 if the SIP re-INVITE request contains an authorised request for an MCPTT emergency private call cancellation as determined by clause 6.3.3.1.13.4:

a) shall clear the cache of the MCPTT ID of the originator of the MCPTT emergency private call that is no longer in an in-progress emergency private call state with the targeted MCPTT user; and

b) if the SIP re-INVITE request contains an alert indication set to "false" and this is an authorised request for an MCPTT emergency alert cancellation meeting the conditions specified in clause 6.3.3.1.13.3:

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

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

6) shall send a SIP re-INVITE request towards the MCPTT user listed in the application/resource-lists+xml MIME body of received SIP re-INVITE request as specified in clause 11.1.1.4.6.

Upon receiving a SIP 200 (OK) response for the SIP re-INVITE request and if the SIP response has not yet been sent to the inviting MCPTT client, the controlling MCPTT function:

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

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP re-INVITE request as specified in the clause 6.3.3.2.2;

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

NOTE: When a SIP 200 (OK) response sent to the originator as a response to a SIP INVITE request that contained authorised request(s) for an MCPTT emergency private call cancellation and optionally an MCPTT emergency alert cancellation, the originator will consider a SIP 200 (OK) response populated in this manner as confirmation that its request(s) for cancellation of an MCPTT emergency private call and optionally an MCPTT emergency alert were accepted by the controlling function.

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

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

11.1.1.4.5 Sending a SIP re-INVITE for upgrade to emergency private call

This clause describes the procedures for sending a re-INVITE request to an MCPTT user in an MCPTT private call for the purpose of upgrading the session to an emergency private call session. The procedure is initiated by the controlling MCPTT function as the result of an action in clause 11.1.1.4.3.

The controlling MCPTT function:

1) shall generate a SIP re-INVITE request as specified in clause 6.3.3.1.9;

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

3) if the received SIP re-INVITE request contains an authorised request for an MCPTT emergency private call as determined by clause 6.3.3.1.13.2:

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

4) shall include a Resource-Priority header field populated with the values for an MCPTT emergency private call as specified in clause 6.3.3.1.19, if the received SIP re-INVITE request contains an authorised request for an MCPTT emergency private call as determined in step 2 above; and

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

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

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

11.1.1.4.6 Sending a SIP re-INVITE for cancellation of emergency private call

This clause describes the procedures for sending a re-INVITE request to an MCPTT user in an MCPTT emergency private call for the purpose of downgrading the session to a normal priority private call session. The procedure is initiated by the controlling MCPTT function as the result of an action in clause 11.1.1.4.4.

The controlling MCPTT function:

1) shall generate a SIP re-INVITE request as specified in clause 6.3.3.1.9;

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

3) if the received SIP re-INVITE request contains an authorised request for an MCPTT emergency private call cancellation as determined by clause 6.3.3.1.13.4:

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

b) if the received SIP INVITE request contains an alert indication set to a value of "false" and this is an authorised request for an MCPTT emergency alert cancellation meeting the conditions specified in clause 6.3.3.1.13.3:

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

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

c) if the received SIP INVITE request contains an alert indication set to a value of "false" and is not an authorised request for an MCPTT emergency alert cancellation meeting the conditions specified in clause 6.3.3.1.13.3, shall set the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body to a value of "true";

4) shall include a Resource-Priority header field populated with the values for a normal MCPTT private call as specified in clause 6.3.3.1.19, if the received SIP re-INVITE request contains an authorised request for an MCPTT emergency private call cancellation as determined in step 3 above; and

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

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

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