6.3 MCPTT server procedures

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

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

6.3.1 Distinction of requests sent to the MCPTT server

6.3.1.1 SIP INVITE request

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

– SIP INVITE requests routed to the participating MCPTT function with the Request-URI set to a public service identity of the participating MCPTT function that identifies the pre-established session set-up. Such requests are known as "SIP INVITE request for establishing a pre-established session" in the procedures in the present document;

– SIP INVITE requests routed to the participating MCPTT function and the Request-URI is set to a public service identity of the participating MCPTT function that does not identify the pre-established session set-up. Such requests are known as "SIP INVITE request for originating participating MCPTT function" in the procedures in the present document;

– SIP INVITE requests routed to the participating MCPTT function and the Request-URI contains a PSI of the terminating participating MCPTT function. Such requests are known as "SIP INVITE request for terminating participating MCPTT function" in the procedures in the present document;

– SIP INVITE requests routed to the controlling MCPTT function, the Request-URI is set to a public service identity for MCPTT private call and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [16]. Such requests are known as "SIP INVITE request for controlling MCPTT function of a private call" in the procedures in the present document;

– SIP INVITE requests routed to the controlling MCPTT function, the Request-URI is set to a public service identity serving an MCPTT group and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [16]. Such requests are known as "SIP INVITE request for controlling MCPTT function of an MCPTT group" in the procedures in the present document;

– SIP INVITE requests routed to the non-controlling MCPTT function of an MCPTT group, the Request-URI is set to a public service identity serving an MCPTT group and the Contact header field contains the isfocus media feature tag specified in IETF RFC 3840 [16]; Such requests are known as "SIP INVITE request for non-controlling MCPTT function of an MCPTT group" in the procedures in the present document;

– SIP INVITE requests routed to the non-controlling MCPTT function of an MCPTT group, the Request-URI is set to a public service identity serving an MCPTT group and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [16]; Such requests are known as "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" in the procedures in the present document;

– SIP INVITE requests routed to the controlling MCPTT function, the Request-URI is set to a public service identity for first-to-answer call and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [16]. Such requests are known as "SIP INVITE request for controlling MCPTT function of a first-to-answer call" in the procedures in the present document; and

– SIP INVITE requests routed to the controlling MCPTT function, the Request-URI is set to a public service identity for MCPTT ambient listening call and the Contact header field does not contain the isfocus media feature tag specified in IETF RFC 3840 [16]. Such requests are known as "SIP INVITE request for controlling MCPTT function of an ambient listening call" in the procedures in the present document.

6.3.1.2 SIP REFER request

The MCPTT server needs to distinguish between the following initial SIP REFER request for originations and terminations:

– SIP REFER requests routed to the participating MCPTT function with the Request-URI set to a public service identity identifying the pre-established session on the participating MCPTT function. Such requests are known as "SIP REFER request for a pre-established session" in the procedures in the present document.

6.3.1.3 SIP MESSAGE request

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

– SIP MESSAGE requests routed to the participating MCPTT function with the Request-URI set to the MBMS public service identity of the participating MCPTT function. Such requests are known as "SIP MESSAGE request for an MBMS listening status update" in the procedures in the present document;

– SIP MESSAGE request routed to the participating MCPTT function containing a Content-Type header field set to "application/vnd.3gpp.mcptt-location-info+xml" and including an XML body containing a Location root element containing a Report element. Such requests are known as "SIP MESSAGE request for location reporting" in the present document;

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

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

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

– SIP MESSAGE requests routed to the originating participating MCPTT function with the Request-URI set to the public service identity of the participating MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "private-call-call-back-request" or "private-call-call-back-cancel-request", or with the <response-type> element set to a value of "private-call-call-back-response" or "private-call-call-back-cancel-response". Such requests are known as "SIP MESSAGE request for private call call-back for originating participating MCPTT function";

– SIP MESSAGE requests routed to the terminating participating MCPTT function with the Request-URI set to the public service identity of the participating MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "private-call-call-back-request" or "private-call-call-back-cancel-request", or with the <response-type> element set to a value of "private-call-call-back-response" or "private-call-call-back-cancel-response".. Such requests are known as "SIP MESSAGE request for private call call-back for terminating participating MCPTT function";

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "private-call-call-back-request". Such requests are known as "SIP MESSAGE request for private call call-back request for controlling MCPTT function";

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "private-call-call-back-cancel-request". Such requests are known as "SIP MESSAGE request for private call call-back cancel request for controlling MCPTT function";

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <response-type> element set to a value of "private-call-call-back-response" or "private-call-call-back-cancel-response". Such requests are known as "SIP MESSAGE request for private call call-back responses for controlling MCPTT function";

– SIP MESSAGE requests routed to the originating participating MCPTT function with the Request-URI set to the public service identity of the participating MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "group-selection-change-request" or with the <response-type> element set to a value of "group-selection-change-response". Such requests are known as "SIP MESSAGE request for group-selection-change for originating participating MCPTT function";

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

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "group-selection-change-request". Such requests are known as "SIP MESSAGE request for group selection change request for controlling MCPTT function";

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element with a <mcptt-Params> element containing an <anyExt> element with the <response-type> element set to a value of "group-selection-change-response". Such requests are known as "SIP MESSAGE request for group selection change response for controlling MCPTT function";

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

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

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

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

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

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

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

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

– SIP MESSAGE requests routed to the originating participating MCPTT function and the Request-URI is set to a public service identity of the originating participating MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <groups-for-regroup> element. Such requests are known as "SIP MESSAGE request to the originating participating MCPTT function to request creation of a group regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the originating participating MCPTT function and the Request-URI is set to a public service identity of the originating participating MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <users-for-regroup> element. Such requests are known as "SIP MESSAGE request to the originating participating MCPTT function to request creation of a user regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the originating participating MCPTT function and the Request-URI is set to a public service identity of the originating participating MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the originating participating MCPTT function to remove a regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the terminating participating MCPTT function and the Request-URI is set to a public service identity of the participating MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <groups-for-regroup> element. Such requests are known as "SIP MESSAGE request to the terminating participating MCPTT function to create a group regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the terminating participating MCPTT function and the Request-URI is set to a public service identity of the terminating participating MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create"and a non-empty <users-for-regroup> element. Such requests are known as "SIP MESSAGE request to the terminating participating MCPTT function to create a user regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the terminating participating MCPTT function and the Request-URI is set to a public service identity of the terminating participating MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-info+xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the terminating participating MCPTT function to remove a regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the controlling MCPTT function and the Request-URI is set to a public service identity of the controlling MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <groups-for-regroup> element. Such requests are known as "SIP MESSAGE request to the controlling MCPTT function to request creation of a group regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the controlling MCPTT function and the Request-URI is set to a public service identity of the controlling MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <users-for-regroup> element. Such requests are known as "SIP MESSAGE request to the controlling MCPTT function to request creation of a user regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the controlling MCPTT function and the Request-URI is set to a public service identity of the controlling MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup +xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the controlling MCPTT function to remove a regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to a non-controlling MCPTT function and the Request-URI is set to a public service identity of the non-controlling MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body, a <regroup-action> element set to "create", and a non-empty <groups-for-regroup> element. Such requests are known as "SIP MESSAGE request to a non-controlling MCPTT function to request creation of a group regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the non-controlling MCPTT function and the Request-URI is set to a public service identity of the non-controlling MCPTT function that contains a <preconfigured-group> element in an application/vnd.3gpp.mcptt-regroup+xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the non-controlling MCPTT function to remove a group regroup using preconfigured group" in the procedures in the present document;

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

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

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

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

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

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

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing an <mcpttinfo> root element with an <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "forward-private-call-request". Such requests are known as "SIP MESSAGE request for forwarding private call request for controlling MCPTT function";

– SIP MESSAGE requests routed to the controlling MCPTT function with the Request-URI set to the public service identity of the controlling MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and includes an XML body containing an <mcpttinfo> root element with an <mcptt-Params> element containing an <anyExt> element with the <response-type> element set to a value of "forward-private-call-response". Such requests are known as "SIP MESSAGE request for forwarding private call response for controlling MCPTT function";

– SIP MESSAGE requests routed to the originating participating MCPTT function with the Request-URI set to the public service identity of the participating MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "fa-group-binding-req". Such requests are known as "SIP MESSAGE request for binding of a functional alias with the MCPTT group(s) for the MCPTT user for originating participating MCPTT function" in the procedures in the present document; and

– SIP MESSAGE requests routed to the controlling participating MCPTT function with the Request-URI set to the public service identity of the participating MCPTT function and containing a Content-Type header field set to "application/vnd.3gpp.mcptt-info+xml" and including an XML body containing a <mcpttinfo> root element containing a <mcptt-Params> element containing an <anyExt> element with the <request-type> element set to a value of "fa-group-binding-req". Such requests are known as "SIP MESSAGE request for binding of a functional alias with the MCPTT group(s) for the MCPTT user for controlling MCPTT function" in the procedures in the present document.

6.3.1.4 SIP SUBSCRIBE request

The MCPTT server needs to distinguish between the following SIP SUBSCRIBE request for originations and terminations:

– SIP SUBSCRIBE requests routed to the participating MCPTT function with the Request-URI set to the MCPTT session identity identifying the participating MCPTT function and the Event header field set to "conference". Such requests are known as "SIP SUBSCRIBE request for conference event status subscription in the participating function" in the procedures in the present document;

– SIP SUBSCRIBE requests routed to the controlling MCPTT function with the Request-URI set to the MCPTT session identity identifying the controlling MCPTT function and containing an Event header field set to "conference". Such requests are known as "SIP SUBSCRIBE request for conference event status subscription in the controlling MCPTT function" in the procedures in the present document; and

– SIP SUBSCRIBE requests routed to the non-controlling MCPTT function with the Request-URI set to the MCPTT session identity identifying the non-controlling MCPTT function and containing an Event header field set to "conference". Such requests are known as "SIP SUBSCRIBE request for conference event status subscription in the non-controlling MCPTT function" in the procedures in the present document.

6.3.2 Participating MCPTT Function

6.3.2.1 Requests initiated by the served MCPTT user

6.3.2.1.1 SDP offer generation

6.3.2.1.1.1 On-demand session

This clause is referenced from other clauses.

The SDP offer is generated based on the received SDP offer. The SDP offer generated by the participating MCPTT function:

1) shall contain only one SDP media-level section for MCPTT speech as contained in the received SDP offer; and

2) shall contain one SDP media-level section for media plane control messages, if present in the received SDP offer.

When composing the SDP offer according to 3GPP TS 24.229 [4], the participating MCPTT function:

1) shall replace the IP address and port number for the offered media stream in the received SDP offer with the IP address and port number of the participating MCPTT function, if required;

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

2) shall replace the IP address and port number for the offered media plane control channel, if any, in the received SDP offer with the IP address and port number of the participating MCPTT function; and

NOTE 2: If the participating MCPTT function and the controlling MCPTT function or the participating MCPTT function and the non-controlling MCPTT function are in the same MCPTT server, and the participating MCPTT function does not have a dedicated IP address or a dedicated port number for media plane control channel or media stream, the replacement of the IP address or the port number is omitted.

3) shall contain an "a=key-mgmt" attribute field with a "mikey" attribute value, if present in the received SDP offer.

6.3.2.1.1.2 Pre-established session

This clause is referenced from other clauses.

When composing an SDP offer according to 3GPP TS 24.229 [4], the participating MCPTT function:

1) shall use the IP address of the participating MCPTT function for MCPTT speech from the SDP negotiated during the pre-established session establishment;

2) shall use the IP address of the participating MCPTT function for the offered media plane control channel from the SDP negotiated during the pre-established session establishment, if present in the received SDP offer;

3) shall contain only one SDP media-level section for MCPTT speech obtained from the SDP negotiated during the pre-established session establishment consisting of:

a) the port number for the MCPTT speech; and

b) the codec(s), media parameters and attributes as in the SDP negotiated during the pre-established session establishment;

4) shall include the media-level section of the offered media plane control channel from the SDP negotiated during the pre-established session establishment, if any media plane control channel is offered consisting of:

a) the media plane control channel parameters as in the SDP negotiated during the pre-established session establishment; and

b) the port number for the selected media plane control channel selected as specified in 3GPP TS 24.229 [4]; and

5) shall contain an "a=key-mgmt" attribute field with a "mikey" attribute value if present in the received SDP offer.

6.3.2.1.2 SDP answer generation

6.3.2.1.2.1 On-demand session

When composing the SDP answer according to 3GPP TS 24.229 [4], the participating MCPTT function:

1) shall replace the IP address and port number in the received SDP answer with the IP address and port number of the participating MCPTT function, for the accepted media stream in the received SDP offer, if required; and

2) shall replace the IP address and port number in the received SDP answer with the IP address and port number of the participating MCPTT function, for the accepted media plane control channel, if present in the received SDP offer.

6.3.2.1.2.2 Pre-established session establishment

When composing the SDP answer according to 3GPP TS 24.229 [4], the participating MCPTT function:

1. shall set the IP address and port number to those of the participating MCPTT function for each accepted media stream from the list contained in the received SDP offer and for each accepted media stream in the received SDP offer; and

2. shall set the IP address and port number to those of the participating MCPTT function, for the accepted media plane control channel, if present in the received SDP offer.

6.3.2.1.3 Sending an INVITE request on receipt of an INVITE request

This clause is referenced from other procedures.

When generating an initial SIP INVITE request according to 3GPP TS 24.229 [4], on receipt of an incoming SIP INVITE request, the participating MCPTT function:

1) shall include in the SIP INVITE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] if included in the incoming SIP INVITE request;

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

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

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP INVITE request to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

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

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

7) if the incoming SIP INVITE request contained an application/resource-lists+xml MIME body, shall copy the application/resource-lists+xml MIME body, according to rules and procedures of IETF RFC 5366 [20];

8) if the incoming SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request to the outgoing SIP INVITE request; and

9) if, according to clause 6.4, the SIP INVITE request is regarded as being not received with an implicit floor request, then:

a) if 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) 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 copy the application/vnd.3gpp.mcptt-location-info+xml MIME body from the SIP INVITE request into the outgoing SIP INVITE.

6.3.2.1.4 Sending an INVITE request on receipt of a REFER request

This clause is referenced from other procedures.

When generating an initial SIP INVITE request according to 3GPP TS 24.229 [4], on receipt of an incoming SIP REFER request, the participating MCPTT function:

1) shall include in the SIP INVITE request all header fields included in the headers portion of 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 the "cid" URL in the Refer-To header field in the incoming SIP REFER request;

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

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP REFER request to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

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" into the Contact header field of the outgoing SIP INVITE request;

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

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

8) shall include in the SIP INVITE request an SDP offer as specified in clause 6.3.2.1.1.2 based upon:

a) the SDP negotiated during the pre-established session establishment and any subsequent pre-established session modification; and

b) the SDP offer (if any) included in the hname "body" parameter in the headers portion of the SIP URI contained in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists MIME body, referenced by the "cid" URL in the Refer-To header field in the incoming SIP REFER request for a pre-established session;

9) shall determine if the SIP REFER request is regarded as being received with an implicit floor request;

a) if according to clause 6.4, the SIP REFER request is regarded as being received with an implicit floor request, the participating MCPTT function shall include the "mc_implicit_request" media level attribute in the associated UDP stream for the floor control in the SDP offer of the SIP INVITE request; and

b) if, according to clause 6.4, the SIP REFER request is regarded as being not received with an implicit floor request, the participating MCPTT function shall not include the "mc_implicit_request" media level attribute in the associated UDP stream for the floor control in the SDP offer of the SIP INVITE request;

10) shall determine if the SIP REFER request is regarded as being received with an implicit request to grant the floor to the terminating MCPTT client;

a) 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 terminating MCPTT client, the participating MCPTT function shall include the "mc_implicit_request" media level attribute in the associated UDP stream for the floor control in the SDP offer of the SIP INVITE request; and

b) if, according to clause 6.4, the SIP REFER request is regarded as being not received with an implicit request to grant the floor to the terminating MCPTT client, the participating MCPTT function shall not include the "mc_implicit_request" media level attribute in the associated UDP stream for the floor control in the SDP offer of the SIP INVITE request;

11) shall copy the application/vnd.3gpp.mcptt-info+xml MIME body from the hname "body" parameter in the headers portion of 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 the "cid" URL in the Refer-To header field of the SIP REFER request, to the outgoing SIP INVITE request;

11A) if the application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP INVITE request contains a <functional-alias-URI> element, shall check the status of the functional alias. If the status is not active, then the participating MCPTT function shall remove the <functional-alias-URI> element from the application/vnd.3gpp.mcptt-info+xml MIME body;

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

13) if the incoming SIP REFER request contained an application/resource-lists+xml MIME body in the hname "body" parameter in the headers portion of the SIP URI contained in a "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of an application/resource-lists+xml MIME body, referenced by the "cid" URL in the Refer-To header field, shall copy the application/resources-lists+xml MIME body in the hname "body" parameter in the headers portion of the SIP URI to the SIP INVITE request; and

14) if, according to clause 6.4, the SIP REFER request is regarded as being not received with an implicit floor request, then:

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

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

6.3.2.1.5 Response to an INVITE request

6.3.2.1.5.1 Provisional responses

NOTE: This clause is referenced from other procedures

When sending SIP provisional responses other than the SIP 100 (Trying) response, the participating MCPTT function shall generate a SIP provisional response according to 3GPP TS 24.229 [4] and:

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

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

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

c) the isfocus media feature tag; and

d) an MCPTT session identity mapped to the MCPTT session identity if provided in the Contact header field of the incoming provisional response;

2) shall include the "norefersub" option tag in a Supported header field in accordance with 3GPP TS 24.229 [4];

3) may include a Resource-Share header field in accordance with clause 5.7.1.20.2 in 3GPP TS 24.229 [4]; and

4) if the incoming SIP provisional response contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing SIP provisional response.

6.3.2.1.5.2 Final response

This clause is referenced from other procedures.

When sending SIP 200 (OK) responses, the participating MCPTT function shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [4] and:

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

2) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [7], "UAS Behavior". If the "refresher" parameter is not included in the received request, the "refresher" parameter in the Session-Expires header field shall be set to "uac";

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

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

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

c) the isfocus media feature tag;

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

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

6) may include a Resource-Share header field in accordance with clause 5.7.1.20.2 in 3GPP TS 24.229 [4]; and

7) if the incoming SIP 200 (OK) response contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing SIP 200 (OK) response.

6.3.2.1.6 Sending a SIP BYE request on receipt of a SIP BYE request

Upon receiving a SIP BYE request from the MCPTT client, the participating MCPTT function:

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

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

3) shall set the Request-URI to the MCPTT session identity as included in the received SIP BYE request;

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request;

5) if the received SIP BYE request contains an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body into the outgoing SIP BYE request; and

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

Upon receiving a SIP 200 (OK) response to the SIP BYE request the terminating MCPTT function shall forward a SIP 200 (OK) response to the MCPTT client and shall interact with the media plane as specified in clause 6.4 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the controlling MCPTT function.

6.3.2.1.7 Sending a SIP BYE request on receipt of a SIP REFER request

Upon receiving a SIP REFER request with the "method" SIP URI parameter set to value "BYE" in the URI in the Refer-To header field from the MCPTT client, the participating MCPTT function:

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

2) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID shall reject the SIP REFER request with a SIP 403 (Forbidden) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

3) if the SIP REFER request 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;

4) shall generate a SIP 200 (OK) response to the SIP REFER request, and in the SIP 200 (OK) response:

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

b) shall check the presence of the Refer-Sub header field of the SIP REFER request and if it is present and set to the value "false" shall include the Refer-Sub header field with value "false" according to rules and procedures of IETF RFC 4488 [22];

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

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

6) shall generate a SIP BYE request, and in the SIP BYE request:

a) shall set the Request-URI to the MCPTT session identity which was included at the Refer-To header field of the received REFER request; and

b) shall copy the contents of the P-Asserted-Identity header field of the received REFER request to the P-Asserted-Identity header field of the outgoing SIP BYE request; and

7) shall send the SIP BYE request toward the controlling MCPTT function according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the SIP BYE request the participating MCPTT function shall interact with the media plane as specified in clause 6.4 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the controlling MCPTT function.

6.3.2.1.8 Priority call conditions

6.3.2.1.8.0 General

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

6.3.2.1.8.1 Determining authorisation for originating a priority group call

When the participating MCPTT function receives a request from the MCPTT client to originate an MCPTT emergency group call and needs to determine if the request is an authorised request for an MCPTT emergency call, the participating MCPTT function shall check the following:

1) if the <allow-emergency-group-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true" and:

a) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element of the <EmergencyCall> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "DedicatedGroup" and if the <uri-entry> element of the <entry> element of the <MCPTTGroupInitiation> element contains the identity of the MCPTT group targeted by the calling MCPTT user; or

b) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element of the <EmergencyCall> contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup";

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

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

When the participating MCPTT function receives a request from the MCPTT client to originate an MCPTT imminent peril group call and needs to determine if the request is an authorised request for an MCPTT imminent peril group call the participating MCPTT function shall check the following:

1) if the <allow-imminent-peril-call> element of <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true"; and

a) if the "entry-info" attribute of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "DedicatedGroup" and if the <uri-entry> element of the <entry> element of the <MCPTTGroupInitiation> element contains the identity of the MCPTT group targeted by the calling MCPTT user; or

b) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup";

then the participating MCPTT function shall consider the MCPTT imminent peril group call request to be an authorised request for an MCPTT emergency group call;

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

6.3.2.1.8.2 Determining authorisation for initiating or cancelling an MCPTT emergency alert

If the participating MCPTT function receives a SIP request from the MCPTT client including a request for an MCPTT emergency alert and:

1) if the <allow-activate-emergency-alert> element of the <actions> element of the <rule> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true"; and

2) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of:

a) "DedicatedGroup", and if the <uri-entry> element of the <entry> element of the <EmergencyAlert> element of the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) contains the MCPTT group identity of the MCPTT group targeted by the calling MCPTT user; or

b) "UseCurrentlySelectedGroup" and the <allow-MCPTT-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the <list-service> element of the group document identified by the MCPTT group identity targeted for the emergency alert is set to a value of "true" as specified in 3GPP TS 24.481 [31].

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

If the participating MCPTT function receives a SIP request from the MCPTT client including a request to cancel an MCPTT emergency alert to an MCPTT group, and if the <allow-cancel-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then the MCPTT emergency alert cancellation request shall be considered to be an authorised request to cancel an MCPTT emergency alert. In all other cases, it shall be considered to be an unauthorised request to cancel an MCPTT emergency alert.

6.3.2.1.8.3 Validate priority request parameters

This clause is referenced from other procedures.

To validate the combinations of <emergency-ind>, <imminentperil-ind> and <alert-ind> which are received in SIP requests, the participating MCPTT function shall follow the procedures specified in clause 6.3.3.1.17.

6.3.2.1.8.4 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

The participating MCPTT function shall follow the procedures specified in clause 6.3.3.1.19 with the clarification that references in that procedure to the controlling MCPTT function should be replaced with references to the participating MCPTT function.

6.3.2.1.8.5 Generating a SIP re-INVITE request for priority group call origination within a pre-established session

This clause is referenced from other procedures.

Upon receipt of a SIP 2xx response which 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" to a SIP INVITE request sent to the controlling MCPTT function which contained a Resource-Priority header field populated for an MCPTT emergency group call or MCPTT imminent peril group call as specified in clause 6.3.2.1.8.4, the participating MCPTT function:

1) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] to be sent within the SIP dialog of the pre-established session;

2) shall include in the SIP re-INVITE request an SDP offer based upon the previously negotiated SDP for the pre-established session;

3) shall include in the SIP re-INVITE request a Resource-Priority header field with the contents set as in the Resource-Priority header field included in the SIP INVITE request sent to the controlling MCPTT function; and

4) shall skip the remaining steps.

NOTE 1: This is the case where the MCPTT client’s previously sent SIP REFER request was either 1) a request for an MCPTT emergency group call or MCPTT imminent peril group call or 2), was not a request for an MCPTT emergency group call or MCPTT imminent peril group call but targeted an MCPTT group which is in an in-progress emergency group state or in-progress imminent peril group state. In either case no SIP INFO pending warning was expected or received.

Upon receipt of a SIP 2xx response from the controlling MCPTT function to a request for an MCPTT emergency call or MCPTT imminent peril call, that contains a Warning header field as specified in clause 4.4 with the warning text containing the mcptt-warn-code set to "149", the participating MCPTT function shall wait for the receipt of a SIP INFO request from the controlling MCPTT function.

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

1) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] to be sent within the SIP dialog of the pre-established session;

2) shall include in the SIP re-INVITE request an SDP offer based upon the previously negotiated SDP for the pre-established session;

3) shall include in the SIP re-INVITE request a Resource-Priority header field with the contents set as in the Resource-Priority header field included in shall include a Resource-Priority header field with the contents set as in the SIP INVITE request sent to the controlling MCPTT function; and

4) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body containing:

a) an <emergency-ind> element if included in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP INFO request, set to the value of the <emergency-ind> in the SIP INFO request;

b) an <alert-ind> element if included in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP INFO request, set to the value of the <alert-ind> in the SIP INFO request; and

c) an <imminentperil-ind> element if included in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP INFO request, set to the value of the <imminentperil-ind> in the SIP INFO request.

NOTE 2: This is the case where the MCPTT client’s previously sent SIP REFER request was a request for an MCPTT emergency group call or an MCPTT imminent peril group call and a SIP INFO request was received in the dialog with the controlling MCPTT function for the MCPTT emergency group call or MCPTT imminent peril group call.

6.3.2.1.8.6 Generating a SIP re-INVITE request for emergency private call origination within a pre-established session

This clause is referenced from other procedures.

Upon receipt of a SIP 2xx response which 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" to a SIP-INVITE request sent to the controlling MCPTT function which contained a Resource-Priority header field populated for an MCPTT emergency private call as specified in clause 6.3.2.1.8.4, the participating MCPTT function:

1) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] to be sent within the SIP dialog of the pre-established session;

2) shall include in the SIP re-INVITE request an SDP offer:

a) based upon the previously negotiated SDP for the pre-established session; and

b) if the received SIP 2xx response was in response to a request for a first-to-answer call and the SDP answer contained an a=key-mgmt attribute, shall include the a=key-mgmt attribute and its value in the SDP offer as specified in IETF RFC 4567 [47];

4) shall skip the remaining steps.

NOTE 1: This is the case where the MCPTT client’s previously sent SIP REFER request was either 1) a request for an MCPTT emergency private call or 2), was not a request for an MCPTT emergency private call but MCPTT emergency private priority state was already set to "in-progress". In either case no SIP INFO pending warning was expected or received.

Upon receipt of a SIP 2xx response from the controlling MCPTT function to a request for an MCPTT emergency private call, that contains a Warning header field as specified in clause 4.4 with the warning text containing the mcptt-warn-code set to "149", the participating MCPTT function shall wait for the receipt of a SIP INFO request from the controlling MCPTT function.

Upon receipt of 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 :

1) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] to be sent within the SIP dialog of the pre-established session;

2) shall include in the SIP re-INVITE request an SDP offer:

a) based upon the previously negotiated SDP for the pre-established session; and

4) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcptt-info+xml MIME body containing:

a) an <alert-ind> element if included in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP INFO request, set to the value of the <alert-ind> in the SIP INFO request.

NOTE 2: This is the case where the MCPTT client’s previously sent SIP REFER request was a request for an MCPTT emergency private call and a SIP INFO request was received in the dialog with the controlling MCPTT function for the MCPTT emergency private call.

6.3.2.1.8.7 Generating a SIP re-INVITE request for first-to-answer call origination within a pre-established session

This clause is referenced from other procedures.

Upon receipt of a SIP 2xx response to a SIP INVITE request for a first-to-answer call which contains an SDP answer including an a=key-mgmt attribute, the participating MCPTT function:

1) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] to be sent within the SIP dialog of the pre-established session; and

2) shall include in the SIP re-INVITE request an SDP offer:

a) based upon the previously negotiated SDP for the pre-established session; and

b) containing the a=key-mgmt attribute and value as received in the SDP answer in the SDP offer as specified in IETF RFC 4567 [47].

6.3.2.1.9 Generating a SIP re-INVITE request on receipt of a SIP re-INVITE request

This clause is referenced from other procedures.

When generating a SIP re-INVITE request according to 3GPP TS 24.229 [4] on receipt of an incoming SIP re-INVITE request, the participating MCPTT function:

1) if the incoming SIP re-INVITE request contained an application/resource-lists MIME body with the MCPTT ID of the invited MCPTT user, shall copy the application/resource-lists MIME body, according to rules and procedures of IETF RFC 5366 [20];

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

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

6.3.2.1.10 Sending a SIP INVITE request towards the non-controlling MCPTT function

This clause is referenced from other procedures.

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

The participating MCPTT function:

1) shall determine the public service identity of the non-controlling MCPTT function associated with the group identity of the constituent group contained in the <associated-group-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request. If the participating MCPTT function is unable to identify the non-controlling MCPTT function for the on demand prearranged group call, it shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;

NOTE 1: The public service identity can identify the non-controlling MCPTT function in the local MCPTT system or in an interconnected MCPTT system.

NOTE 2: If the non-controlling MCPTT function is in an interconnected 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 interconnected MCPTT system from the local MCPTT system.

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

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

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

2) shall set the Request-URI of the generated SIP INVITE request to the public service identity determines in step 1;

3) shall include in the SIP INVITE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] if included in the original incoming SIP INVITE or SIP REFER request from the MCPTT client;

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

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

6) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP INVITE or SIP REFER request from the client to the P-Asserted-Identity header field of the outgoing SIP INVITE request;

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

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

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

10) if a SIP INVITE request was received from the client containing an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body of the original incoming SIP INVITE request to the outgoing SIP INVITE request;

11) if a SIP REFER request was received from the client with a "cid" URL pointing to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [20] containing 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 and the SIP URI contains an hname "body" parameter in the headers portion of the SIP URI containing an application/vnd.3gpp.mcptt-info MIME body, shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP REFER request to the outgoing SIP INVITE request; and

12) shall set the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request to the MCPTT ID of the calling user that was determined when the participating MCPTT function received the SIP INVITE request or SIP REFER request from the client.

6.3.2.2 Requests terminated to the served MCPTT user

6.3.2.2.1 SDP offer generation

The participating MCPTT function shall follow the procedures in clause 6.3.2.1.1.

6.3.2.2.2 SDP answer generation

6.3.2.2.2.1 On-demand session

The participating MCPTT function shall follow the procedures in clause 6.3.2.1.2.1.

6.3.2.2.2.2 Pre-established session

When composing an SDP answer according to 3GPP TS 24.229 [4], the MCPTT server:

1) shall set the IP address of the MCPTT server for the accepted MCPTT speech media stream from the received SDP offer, which was also negotiated during the pre-established session establishment;

2) shall set the IP address of the MCPTT server for the accepted media-floor control entity from the received SDP offer, which was also negotiated during the pre-established session establishment, if present in the received SDP offer;

3) shall include the media-level section for the accepted MCPTT speech media stream from the received SDP offer, which was also negotiated in pre-established session establishment, consisting of:

a) the port number for MCPTT speech; and

b) the codec(s) and media parameters selected by the MCPTT server from the received SDP offer; and

4) shall include for the media-floor control entity, that is offered in the SDP offer from the MCPTT server and accepted in the SDP answer by MCPTT client, the media-level section of each offered media-floor control entity consisting of:

a) the media-floor control entity parameters contained in the received SDP offer, restricted to media-floor control entity parameters negotiated during the pre-established session establishment; and

b) the port number for selected media-floor control entity selected as specified in 3GPP TS 24.229 [4].

6.3.2.2.3 SIP INVITE request towards the terminating MCPTT client

The participating MCPTT function shall generate an initial SIP INVITE request according to 3GPP TS 24.229 [4] and:

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

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

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

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

c) the isfocus media feature tag;

d) an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the incoming SIP INVITE request; and

e) any other uri-parameter provided in the Contact header field of the incoming SIP INVITE request;

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

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

7) may include a Resource-Share header field in accordance with clause 5.7.1.20.3 in 3GPP TS 24.229 [4]; and

8) if the incoming SIP 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 SIP INVITE request.

6.3.2.2.4 Response to a SIP INVITE request

6.3.2.2.4.1 Provisional response

This clause is referenced from other procedures.

When sending a SIP provisional response other than the SIP 100 (Trying) response to the SIP INVITE request, the participating MCPTT function shall generate a SIP provisional response according to 3GPP TS 24.229 [4] and:

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

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

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

2) if the outgoing SIP provisional response is to be sent in response to the receipt of a SIP provisional response and the response contains an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing SIP provisional response; and

3) if the incoming SIP INVITE request included the Supported header field with the value "100rel" and according to local policy, may include the Require header field with the value "100rel".

6.3.2.2.4.2 Final response

This clause is referenced from other procedures.

When sending SIP 200 (OK) responses, the participating MCPTT function shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [4] and:

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

2) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [7], "UAS Behavior". If no "refresher" parameter was included in the SIP INVITE request, the "refresher" parameter in the Session-Expires header field shall be set to "uas";

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

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

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

c) an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the received SIP INVITE request from the controlling MCPTT function;

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

5) if the incoming SIP response contained an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body to the outgoing SIP 200 (OK) response.

6.3.2.2.5 Automatic Commencement Mode

6.3.2.2.5.1 General

When receiving a "SIP INVITE request for terminating participating MCPTT function" that requires automatic commencement mode:

1) if:

a) the invited MCPTT client has one or more pre-established sessions without an associated MCPTT call;

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

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

then the participating MCPTT function shall perform the actions specified in clause 6.3.2.2.5.3; or

2) otherwise the participating MCPTT function shall perform the actions specified in clause 6.3.2.2.5.2.

6.3.2.2.5.2 Automatic commencement for On-Demand session

When receiving a "SIP INVITE request for terminating participating MCPTT function" for an on-demand session that requires automatic commencement mode the participating MCPTT function:

1) if:

a) the incoming SIP INVITE request contained a Priv-Answer-Mode header field set to the value of "Auto";

b) no Answer-Mode header field or Priv-Answer-Mode header field were received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as defined in clause 7.3.3 or clause 7.3.4 is set to "auto-answer"; or

c) the incoming SIP INVITE request contained an Answer-Mode header field set to "Auto" and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as defined in clause 7.3.3 or clause 7.3.4 is set to "auto-answer";

then:

a) shall generate a SIP 183 (Session Progress) response to the "SIP INVITE request for terminating participating MCPTT function" as specified in clause 6.3.2.2.4.1;

b) if the received SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body with the <ambient-listening-type> element set to a value of "remote-init" shall include in the SIP 183 (Session Progress) response an alert-info header field set to a value of "<file:///dev/null>" according to IETF RFC 3261 [24] and as updated by IETF RFC 7462 [77]; and

NOTE: The SIP 183 (session Progress) response can be sent reliably or unreliably depending on the content of the received SIP INVITE request. Regardless of if the SIP 183 (Session Progress) response is sent reliably or unreliably, SDP is not included in the SIP 183 (Session Progress) response.

c) shall set the P-Answer-State header field to "Unconfirmed" in the SIP 183 (Session Progress) response;

2) shall copy the public user identity contained in the Request-URI of the incoming "SIP INVITE request for terminating participating MCPTT function" to the P-Asserted-Identity header field of the SIP 183 (Session Progress) response;

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

4) shall set the Request-URI to the public user identity associated to the MCPTT ID of the MCPTT user to be invited;

5) shall perform the procedures specified in clause 6.3.2.2.9 to include any MIME bodies in the received SIP INVITE request, into the outgoing SIP INVITE request;

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

7) if the Priv-Answer-Mode header field is present in the incoming SIP INVITE request with a value of "Auto", shall include a Priv-Answer-Mode header field with the value "Auto" in the outgoing SIP INVITE request. Otherwise, if the Answer-Mode header field is present in the incoming SIP INVITE request, the participating MCPTT function shall include an Answer-Mode header field with the value "Auto" in the outgoing SIP INVITE request;

8) if no Answer-Mode header field or Priv-Answer-Mode header field were received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as defined in clause 7.3.3 or clause 7.3.4 is set to "auto-answer", shall set the Answer-Mode header field to "Auto" in the outgoing SIP INVITE request;

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

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

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

If the SIP 183 (Session Progress) response was sent reliably, then upon receiving a SIP PRACK request, the participating MCPTT function shall generate a SIP 200 (OK) response to the SIP PRACK request and forward the SIP 200 (OK) response, according to 3GPP TS 24.229 [4].

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

1) if the SIP 183 (Session Progress) was sent unreliably, shall send the SIP 200 (OK) response immediately; and

2) if the SIP 183 (Session Progress) was sent reliably and,

a) if the SIP PRACK request to the SIP 183 (Session Progress) response has been received by the participating MCPTT function and the SIP 200 (OK) response to the SIP PRACK request has been sent, shall send the SIP 200 (OK) response immediately;

b) if the SIP PRACK request to the SIP 183 (Session Progress) response has not yet been received, then upon receipt of the SIP PRACK request, the participating MCPTT function shall generate a SIP 200 (OK) response to the SIP PRACK request and forward the SIP 200 (OK) response, according to 3GPP TS 24.229 [4], before sending the SIP 200 (OK) response to the "SIP INVITE request for terminating participating MCPTT function".

When the participating MCPTT function sends the SIP 200 (OK) response to the "SIP INVITE request for terminating participating MCPTT function", 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;

3A) if the SIP 183 (Session Progress) was sent with the P-Answer-State header field set to "Unconfirmed", shall set the P-Answer-State header field to "Confirmed" in 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].

6.3.2.2.5.3 Automatic commencement for pre-established session

NOTE 1: This clause is referenced from other procedures.

When receiving a "SIP INVITE request for terminating participating MCPTT function" for a pre-established session that requires automatic commencement mode the participating MCPTT function:

1) if the received SIP INVITE request contains:

a) 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" or with the <imminentperil-ind> element set to a value of "true"; or

b) a Priv-Answer-Mode header field;

shall perform the procedures of clause 6.3.2.2.5.2 with the following clarifications:

a) include in the outgoing SIP INVITE request a Replaces header field populated with the call-id, to-tag and from-tag of the targeted pre-established session as specified in IETF RFC 3891 [65];

b) include in the SDP offer the current media parameters used by the targeted pre-established session identified by the Replaces header field; and

c) if the SIP core supports resource sharing, include in the outgoing SIP INVITE request a Resource-Share header field as specified in 3GPP TS 24.229 [4] with:

i) the value "media-sharing";

ii) an "origin" header field parameter set to "session-receiver";

iii) a "timestamp" header field parameter; and

iv) a "rules" header field parameter with one resource sharing rule per media stream in the same order the corresponding m-line appears in the SDP. Each resource sharing rule is constructed as follows:

– a "new-sharing-key" part containing the same key as that included when the media bearer for the pre-established session was established; and

– a "directionality" part indicating the direction of the pre-established media bearer;

and shall skip the remaining steps of this clause;

2) shall generate a SIP 200 (OK) response to the "SIP INVITE request for terminating participating MCPTT function" as described in the clause 6.3.2.2.4.2;

3) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.2.2.2 based on the SDP negotiated during the pre-established session establishment and SDP offer received in the "SIP INVITE request for terminating participating MCPTT function";

4) shall set the P-Answer-State header field to "Unconfirmed" in the SIP 200 (OK) response;

5) shall set the P-Asserted-Identity header field to the same value as included in the SIP INVITE request that was sent by the MCPTT client when the pre-established session was established, in the SIP 200 (OK) response;

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

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

NOTE 2: Received SIP INVITE requests handled by the present clause in steps 2) through 7) will result in the terminating client not receiving data normally contained in an application/ vnd.3gpp.mcptt-info+xml MIME body. This includes but is not limited to call type indicators such as XML elements <broadcast-ind> or <associated-group>.

6.3.2.2.6 Manual Commencement Mode

6.3.2.2.6.1 General

When receiving a "SIP INVITE request for terminating participating MCPTT function" that requires manual commencement mode:

1) if:

a) the invited MCPTT client has one or more pre-established sessions without an associated MCPTT call;

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

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

then the participating MCPTT function shall perform the actions specified in clause 6.3.2.2.6.3; or

2) otherwise the participating MCPTT function shall perform the actions specified in clause 6.3.2.2.6.2.

6.3.2.2.6.2 Manual commencement for On-Demand session

When receiving a "SIP INVITE request for terminating participating MCPTT function" for an on-demand session that requires manual commencement mode the participating MCPTT function:

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

2) shall set the Request-URI to the public user identity associated to the MCPTT ID of the MCPTT user to be invited;

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

4) if the Answer-Mode header field is present in the incoming SIP INVITE request, participating MCPTT function, shall include an Answer-Mode header field with the value "Manual";

5) if no Answer-Mode header field was received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application/poc-settings+xml MIME body received from the invited MCPTT client as defined in clause 7.3.3 or clause 7.3.4 is set to "manual-answer", shall set the Answer-Mode header field to "Manual" in the outgoing SIP INVITE request;

6) if the Priv-Answer-Mode header field is present in the incoming SIP INVITE request, the participating MCPTT function shall include a Priv-Answer-Mode header field with the value "Manual";

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

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

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

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

Upon receiving a SIP 180 (Ringing) response to the above SIP INVITE request, the participating MCPTT function:

NOTE 1: A SIP 180 (Ringing) response is received from a terminating MCPTT client in the case of a private call or first-to-answer call.

1) shall generate a SIP 180 (Ringing) response as specified in clause 6.3.2.2.4.1;

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

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

Upon receiving a SIP 183 (Session Progress) response to the above SIP INVITE request, the participating MCPTT function:

NOTE 2: A SIP 183 (Session Progress) response can be received from a terminating MCPTT client in the case of a group call.

1) shall generate a SIP 183 (Session Progress) response as specified in clause 6.3.2.2.4.1;

2) shall include the P-Asserted-Identity header field as received in the incoming SIP 183 (Session Progress) response;

3) void; and

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

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

When the participating MCPTT function sends the SIP 200 (OK) response 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] clause 6.4; 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].

6.3.2.2.6.3 Manual commencement for Pre-established session

When receiving a "SIP INVITE request for terminating participating MCPTT function" for a pre-established session that requires manual commencement mode the participating MCPTT function:

1) if:

a) the received 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" or with the <imminentperil-ind> element set to a value of "true"; or

b) if the Priv-Answer-Mode header field is present in the incoming SIP INVITE request;

then:

a) shall perform the procedures of clause 6.3.2.2.6.2 with the following clarifications:

i) include in the outgoing SIP INVITE request a SIP Replaces header field populated with the call-id, to-tag and from-tag of the targeted pre-established session as specified in IETF RFC 3891 [65];

ii) include in the SDP offer the current media parameters used by the targeted pre-established session identified by the Replaces header field; and

iii) if the SIP core supports resource sharing, include in the outgoing SIP INVITE request a Resource-Share header field as specified in 3GPP TS 24.229 [4] with:

A) the value "media-sharing";

B) an "origin" header field parameter set to "session-receiver";

C) a "timestamp" header field parameter; and

D) a "rules" header field parameter with one resource sharing rule per media stream in the same order the corresponding m-line appears in the SDP. Each resource sharing rule is constructed as follows:

– a "new-sharing-key" part containing the same key as that included when the media bearer for the pre-established session was established; and

– a "directionality" part indicating the direction of the pre-established media bearer; and

b) shall skip the remaining steps;

2) shall generate a SIP re-INVITE request as described in clause 6.3.2.2.3;

NOTE 1: A SIP re-INVITE request cannot include an Answer-Mode header field as specified in IETF RFC 5373 [18] so Manual Answer is implied with a SIP re-INVITE request within the existing SIP dialog of the pre-established session.

3) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming "SIP INVITE request for terminating participating MCPTT function" to the outgoing SIP re-INVITE request;

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

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

Upon receiving a SIP 180 (Ringing) response to the above SIP re-INVITE request, the participating MCPTT function:

NOTE 2: A SIP 180 (Ringing) response is received from a terminating MCPTT client in the case of a private call.

1) shall generate a SIP 180 (Ringing) response as specified in clause 6.3.2.2.4.1;

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

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

Upon receiving a SIP 183 (Session Progress) response to the above SIP re-INVITE request, the participating MCPTT function:

NOTE 3: A SIP 183 (Session Progress) response can be received from a terminating MCPTT client in the case of a group call.

1) shall generate a SIP 183 (Session Progress) response as specified in clause 6.3.2.2.4.1;

2) shall include the P-Asserted-Identity header field as received in the incoming SIP 183 (Session Progress) response;

3) void; and

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

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

1) if the received SDP answer includes changes in codecs or media formats, shall interact with the media plane as specified in 3GPP TS 24.380 [5] for updating the media plane with the newly negotiated codecs and media parameters from the received SDP answer;

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

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

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

NOTE 4: The participating MCPTT function sends a MCPC Connect message, in order to give MCPTT session identity to the terminating MCPTT client.

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

6.3.2.2.7 Void

6.3.2.2.8 SIP BYE request towards the terminating MCPTT client

6.3.2.2.8.1 On-demand

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

1) shall interact with the media plane as specified in clause 6.4 in 3GPP TS 24.380 [5] for releasing media plane resource associated with the SIP session with the controlling MCPTT function;

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

3) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP BYE request to the P-Asserted-Identity header field of the outgoing SIP BYE request;

4) if the received SIP BYE request contains an application/vnd.3gpp.mcptt-info+xml MIME body, shall copy the application/vnd.3gpp.mcptt-info+xml MIME body into the outgoing SIP BYE request; and

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

Upon receiving a SIP 200 (OK) response to the SIP BYE request the participating MCPTT function:

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

2) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the MCPTT client.

6.3.2.2.8.2 Using pre-established session

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

1) shall interact with the media plane as specified in clause 9.3 in 3GPP TS 24.380 [5] for disconnecting the media plane resources towards the controlling MCPTT function;

2) shall send a SIP 200 (OK) response to the controlling MCPTT function;

3) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for disconnecting media plane resources towards the MCPTT client from the media plane resources towards the controlling MCPTT function; and

4) shall maintain the pre-established session towards the MCPTT client.

6.3.2.2.9 Populate MIME bodies

This clause is referenced from other procedures.

If the incoming SIP request contains an application/vnd.3gpp.mcptt-info+xml MIME body, the participating MCPTT function:

1) if not already copied:

a) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body received in the SIP request into an application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP request; and

b) if an <MKFC-GKTP> element was included in the application/vnd.3gpp.mcptt-info+xml MIME body received in the SIP request, the <MKFC-GKTP> element shall not be copied into the application/vnd.3gpp.mcptt-info+xml MIME body included in the outgoing SIP request.

If the received SIP request contains an application/vnd.3gpp.location-info+xml MIME body as specified in Annex F.3:

1) if not already copied, shall copy the contents of the application/vnd.3gpp.mcptt-location-info+xml MIME body received in the SIP request into an application/vnd.3gpp.mcptt-location-info+xml MIME body included in the outgoing SIP request.

If the received SIP request contains an application/resource-lists+xml MIME body:

1) if not already copied, shall copy the contents of the application/resource-lists+xml MIME body received in the SIP request into an application/resource-lists+xml MIME body included in the outgoing SIP request.

6.3.2.2.10 Generating a SIP re-INVITE request towards the terminating MCPTT client

This clause is referenced from other procedures.

The participating MCPTT function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4] and:

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

2) may include a Resource-Share header field in accordance with clause 5.7.1.20.3 in 3GPP TS 24.229 [4];

3) shall perform the procedures specified in clause 6.3.2.2.9 to copy any MIME bodies in the received SIP (re‑)INVITE request to the outgoing SIP re-INVITE request; and

4) if the received SIP (re-)INVITE request contains a Resource-Priority header field, shall include a Resource-Priority header field with the contents set as in the received Resource-Priority header field.

6.3.2.2.11 Generating a SIP MESSAGE request towards the terminating MCPTT client

This clause is referenced from other procedures.

The participating MCPTT function shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] and:

1) shall include in the SIP MESSAGE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [6] that were received (if any) in the incoming SIP MESSAGE request;

2) shall set the Request-URI of the outgoing SIP MESSAGE request to the public user identity associated to the MCPTT ID of the terminating MCPTT user;

3) shall populate the outgoing SIP MESSAGE request MIME bodies as specified in clause 6.3.2.2.9; and

4) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP MESSAGE request to the P-Asserted-Identity header field of the outgoing SIP MESSAGE request.

6.3.2.3 Void

6.3.2.4 Request initiated by the participating MCPTT function

6.3.2.4.1 Generating a SIP MESSAGE request for notification of entry into or exit from an emergency alert area

This clause describes the procedures for generating a SIP MESSAGE request to notify an MCPTT client that it has entered a pre-defined emergency alert area or exited from a pre-defined emergency alert area. The procedure is initiated by the participating MCPTT function when the participating MCPTT function determines that the MCPTT client has entered a pre-defined emergency alert area or exited from a pre-defined emergency alert area.

NOTE: The participating MCPTT function can use additional implementation-specific selection criteria to decide the recipients of the notification, i.e., whether and when an entry/exit notification is sent. The additional criteria can be the activated functional alias, ongoing emergency or conditions related to position such as speed, heading etc.. The determination of the specific region is left to implementation.

The participating MCPTT function:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

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

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

4) shall set the Request-URI to the public user identity associated to the MCPTT ID of the targeted MCPTT user;

5) shall include a P-Asserted-Identity header field set to the public service identity of the participating MCPTT function;

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

7) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-request-uri> element set to the value of the MCPTT ID of the targeted MCPTT user;

8) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <emergency-alert-area-ind> element:

a) set to a value of "true", if the MCPTT client has entered a pre-defined emergency alert area; or

b) set to a value of "false", if the MCPTT client has exited from a pre-defined emergency alert area; and

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

Upon receiving a SIP 200 (OK) response to the SIP MESSAGE request, if the <emergency-alert-area-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP MESSAGE request was:

1) set to a value of "true", shall record that the MCPTT client has received the notification that it has entered the pre-defined emergency alert area; and

2) set to a value of "false", shall record that the MCPTT client has received the notification that it has exited the pre-defined emergency alert area.

6.3.2.4.2 Generating a SIP MESSAGE request for notification of entry into or exit from a group geographic area

This clause describes the procedures for generating a SIP MESSAGE request to notify an MCPTT client that it has entered a pre-defined group geographic area or exited from a pre-defined group geographic area requiring affiliation to or de-affiliation from a group. The procedure is initiated by the participating MCPTT function when the participating MCPTT function determines that the MCPTT client has entered a pre-defined group geographic area or exited from a pre-defined group geographic area.

NOTE: The participating MCPTT function can use additional implementation-specific selection criteria to decide the recipients of the notification, i.e., whether and when an entry/exit notification is sent. The additional criteria can be the activated functional alias, ongoing emergency or conditions related to position such as speed, heading etc. The determination of the specific region is left to implementation.

The participating MCPTT function:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

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

4) shall set the Request-URI to the public user identity associated to the MCPTT ID of the targeted MCPTT user;

5) shall include a P-Asserted-Identity header field set to the public service identity of the participating MCPTT function;

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

7) void;

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

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

b) an <associated-group-id> element set to the MCPTT group ID of the group for which a pre-defined group geographic area has been entered or exited; and

c) a <group-geo-area-ind> element:

i) set to a value of "true", if the MCPTT client has entered a pre-defined group geographic area; or

ii) set to a value of "false", if the MCPTT client has exited from a pre-defined group geographic area; and

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

Upon receiving a SIP 200 (OK) response to the SIP MESSAGE request, if the <group-geo-area-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP MESSAGE request was:

1) set to a value of "true", shall record that the MCPTT client has received the notification that it has entered the pre-defined group geographic area; and

2) set to a value of "false", shall record that the MCPTT client has received the notification that it has exited the pre-defined group geographic area.

6.3.2.5 Handling of the no answer timer (TNP1)

When the terminating participating MCPTT function receives a SIP INVITE request to initiate a private call:

If:

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

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

3) the <call-forwarding-condition> element exists and has a value of "no-answer" as specified in 3GPP TS 24.484 [50] set;

then:

1) the terminating participating MCPTT function shall start timer TNP1 (call forwarding no answer timer) with a timer value as described in Annex B.2.2, prior to sending out a SIP INVITE request inviting the called MCPTT user to a private call.

When the terminating participating MCPTT function receives a SIP 200 (OK) response to the SIP INVITE request, from the called MCPTT user before expiry of TNP1 (call forwarding no answer timer), then the terminating participating MCPTT function shall stop timer TNP1 (call forwarding no answer timer) and forward the SIP 200 (OK) response to the controlling MCPTT function.

After expiry of timer TNP1 (call forwarding no answer timer) the terminating participating MCPTT function:

1) if the received SIP INVITE request contained a <forwarding-other-list> element with one or more <entry> elements 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;

2) shall generate and send a SIP CANCEL request to the called MCPTT user, according to IETF RFC3261 [24], to cancel the SIP request for which the no answer timer has been expired;

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

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

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

5) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [4].

Upon receipt of SIP 2xx responses to the outgoing SIP MESSAGE requests, the terminating participating MCPTT function shall follow the procedures specified in 3GPP TS 24.229 [4].

6.3.2.6 Generating a SIP MESSAGE request for call forwarding of a private call

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP MESSAGE request for call forwarding of a private call.

The participating MCPTT function:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33] with the following clarifications:

a) 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 MESSAGE request;

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

c) shall include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with the <mcpttinfo> element containing the <mcptt-Params> element containing:

i) the <mcptt-called-party-id> element set to the <call-forwarding-target> element in the MCPTT user profile document in 3GPP TS 24.484 [50]); and

ii) an <anyExt> element containing:

A) the <request-type> element set to a value of "forward-private-call-request"; and

B) if the <forward-to-functional-alias> element of the <ruleset> element is present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function with the value "true", then the <call-to-functional-alias-ind> element set to "true"; otherwise, the <call-to-functional-alias-ind> element set to "false"; and

NOTE 1: For a call forwarding to an MCPTT ID the value of the <mcptt-called-party-id> is the MCPTT ID of the target user, while for call forwarding to a functional alias the value is the functional alias of the target user.

d) shall insert in the SIP MESSAGE request an application/resource-lists+xml MIME body with the MCPTT ID of the forwarded MCPTT user, according to the rules and procedures of IETF RFC 5366 [20];

2) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCPTT function associated with the call transfer service for the requesting MCPTT user;

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 associated with the private call service for the calling 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.

3) shall include a P-Asserted-Identity header field set to the public service identity of participating MCPTT function;

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

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

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

6.3.3 Controlling MCPTT function

6.3.3.1 Request initiated by the controlling MCPTT function

6.3.3.1.1 SDP offer generation

The SDP offer is generated based on the received SDP offer. The SDP offer generated by the controlling MCPTT function:

1) when initiating a new MCPTT session the SDP offer;

a) shall contain only one SDP media-level section for MCPTT speech media stream as contained in the received SDP offer; and

b) shall contain one SDP media-level section for media plane control messages, if present in the received SDP offer; and

2) when adding a new MCPTT user to an existing MCPTT Session, the SDP offer shall contain the media stream currently used in the MCPTT session.

When composing the SDP offer according to 3GPP TS 24.229 [4], the controlling MCPTT function:

1) shall replace the IP address and port number for the offered media stream in the received SDP offer with the IP address and port number of the controlling MCPTT function;

2) for the MCPTT speech media stream, shall include all media-level attributes from the received SDP offer;

3) shall replace the IP address and port number for the offered media plane control channel, if any, in the received SDP offer with the IP address and port number of the controlling MCPTT function; and

4) for the offered media plane control channel, shall include the offered media plane control channel ‘fmtp’ attributes as specified in 3GPP TS 24.380 [5] clause 14.

6.3.3.1.2 Sending an INVITE request

This clause is referenced from other procedures.

The controlling MCPTT function shall generate an initial SIP INVITE request according to 3GPP TS 24.229 [4].

The controlling MCPTT function:

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

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

3) 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-Asserted-Service-Id header field according to IETF RFC 6050 [9] in the SIP INVITE request;

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

5) shall include a Referred-By header field with the public user identity of the inviting MCPTT client;

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

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

8) if the received SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body containing an <ambient-listening-type> element and:

a) if the Priv-Answer-Mode header field specified in IETF RFC 5373 [18] was included in the received SIP INVITE request with a value of "Auto" or if no Priv-Answer-Mode header field was received in the received SIP INVITE request; or

b) a Priv-Answer-Mode header field was received containing a value other than "Auto";

shall include a Priv-Answer-Mode header field set to a value of "Auto" in the outgoing SIP INVITE request;

9) if the received SIP INVITE request contained a Priv-Answer-Mode header field and did not contain an application/vnd.3gpp.mcptt-info+xml MIME body containing an <ambient-listening-type> element, shall include an unmodified Priv-Answer-Mode header field;

10) if the received SIP INVITE request did not contain an application/vnd.3gpp.mcptt-info+xml MIME body containing an <ambient-listening-type> element and did not contain a Priv-Answer-Mode header field, shall include an unmodified Answer-Mode header field if present in the incoming SIP INVITE request; and

11) if the incoming SIP 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 INVITE request.

6.3.3.1.3 Receipt of a SIP response to a SIP INVITE request

6.3.3.1.3.1 Final response

On receipt of the SIP 200 (OK) response to the initial outgoing SIP INVITE request the controlling MCPTT function:

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

2) shall cache SIP feature tags, if received in the Contact header field, and if the specific feature tags are supported.

6.3.3.1.4 Void

6.3.3.1.5 Sending a SIP BYE request

When a participant needs to be removed from the MCPTT session, the controlling MCPTT function:

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

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

3) shall send the SIP BYE request to the MCPTT clients according to3GPP TS 24.229 [4].

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

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

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

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

This clause is referenced from other procedures.

The controlling MCPTT function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4].

The controlling MCPTT function:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.3.3.1.7 Sending a SIP INVITE request for MCPTT emergency group call

This clause is referenced from other procedures.

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

The controlling MCPTT function:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This clause is referenced from other procedures.

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

1) shall generate a SIP 183 (Session Progress) response according to 3GPP TS 24.229 [4] with the clarifications provided specified in clause 6.3.3.2.3.1;

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

3) shall include in the SIP 183 (Session Progress) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1; and

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

Upon receiving a SIP PRACK request to the SIP 183 (Session Progress) response the controlling MCPTT function:

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

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

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

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

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

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

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

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

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

6.3.3.1.9 Generating a SIP re-INVITE request

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP re-INVITE request to be sent by the controlling MCPTT function.

The controlling MCPTT function:

1) shall generate an SIP re-INVITE request according to 3GPP TS 24.229 [4]; and

2) shall include an SDP offer with the media parameters as currently established with the terminating MCPTT client according to 3GPP TS 24.229 [4] with the clarifications specified in clause 6.3.3.1.1.

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

This clause is referenced from other procedures.

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

The controlling MCPTT function:

1) shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [4] with the clarifications specified in clause 6.3.3.1.9;

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

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

6.3.3.1.11 Generating a SIP MESSAGE request for notification of in-progress emergency or imminent peril status change

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP MESSAGE request to notify affiliated but not participating members of an MCPTT group of the change of status of the in-progress emergency state, imminent peril state or emergency alert status of an MCPTT group. The procedure is initiated by the controlling MCPTT function when there has been a change of in-progress imminent peril, in-progress emergency or the emergency alert status of an MCPTT group.

The controlling MCPTT function:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

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

4) shall set the Request-URI to the public service identity of the terminating participating function associated with the MCPTT ID of the targeted MCPTT user;

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

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

5) shall include a P-Asserted-Identity header field set to the public service identity of controlling MCPTT function;

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

8) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <mcptt-calling-group-id> element set to the MCPTT group ID of the MCPTT group on which the MCPTT emergency call, imminent peril call or the emergency alert state has changed.

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

This clause is referenced from other procedures.

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

The controlling MCPTT function:

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

2) shall determine the value of the MCPTT user’s Mission Critical Organization from the <MissionCriticalOrganization> element, of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]);

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

4) shall copy the contents of the application/vnd.3gpp.mcptt-location-info+xml MIME body in the received SIP request into an application/vnd.3gpp.mcptt-location-info+xml MIME body included in the outgoing SIP request.

6.3.3.1.13 Authorisations

6.3.3.1.13.1 Determining authorisation for initiating an MCPTT emergency alert

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

1) if the <allow-activate-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true";

a) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "DedicatedGroup" and:

i) if the MCPTT group identity targeted for the emergency alert is contained in the <uri-entry> element of the <entry> element of the <EmergencyAlert> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

ii) if the <allow-MCPTT-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the <list-service> element of the group document identified by the MCPTT group identity is set to a value of "true" as specified in 3GPP TS 24.481 [31]; or

b) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> element contained within the <MCPTT-group-call> element of the MCPTT user profile (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup" and the <allow-MCPTT-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the <list-service> element of the group document identified by the MCPTT group identity targeted for the emergency alert is set to a value of "true" as specified in 3GPP TS 24.481 [31].

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

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

1) if the <allow-activate-emergency-alert> element of the <actions> element of the <rule> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true"; and

a) if the "entry-info" attribute of the <entry> element of the <PrivateEmergencyAlert> element contained within the <OnNetwork> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UsePreConfigured" and the MCPTT ID of the MCPTT user targeted for the call is contained in the <uri-entry> element of the <entry> element of the <PrivateEmergencyAlert> element contained within the <OnNetwork> element (see the MCPTT user profile document in 3GPP TS 24.484 [50]); or

b) if the "entry-info" attribute of the <entry> element of the <PrivateEmergencyAlert> element contained within the <OnNetwork> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "LocallyDetermined";

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

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

i) if the <uri-entry> element of the <entry> element of the <MCPTTGroupInitiation> element of the <EmergencyCall> contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) contains the identity of the MCPTT group targeted by the calling MCPTT user; and

ii) if the <allow-MCPTT-emergency-call> element of the <list-service> element of the group document identified by the targeted MCPTT group identity is set to a value of "true" as specified in 3GPP TS 24.481 [31];

then the controlling MCPTT function shall consider the MCPTT emergency group call request to be an authorised request for an MCPTT emergency group call and skip the remaining steps; or;

b) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element of the <EmergencyCall> element contained within the <MCPTT-group-call> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup" and if the <allow-MCPTT-emergency-call> element of the <list-service> element of the group document identified by the targeted MCPTT group identity is set to a value of "true" as specified in 3GPP TS 24.481 [31];

then the controlling MCPTT function shall consider the MCPTT emergency group call request to be an authorised request for an MCPTT emergency group call and skip the remaining steps; or

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

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

1) if the <allow-emergency-private-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true"; and

a) if the "entry-info" attribute of the <entry> element of the <MCPTTPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UsePreConfigured" and if the MCPTT ID targeted for the call is contained in the <uri-entry> element of the <entry> element of the <MCPTTPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element (see the MCPTT user profile document in 3GPP TS 24.484 [50]); or

b) if the "entry-info" attribute of the <entry> element of the <MCPTTPrivateRecipient> element of the <EmergencyCall> element contained within the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "LocallyDetermined";

then the controlling MCPTT function shall consider the MCPTT emergency private call request to be an authorised request for an MCPTT emergency private call and skip step 2) below; or

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

6.3.3.1.13.3 Determining authorisation for cancelling an MCPTT emergency alert

If the controlling MCPTT function has received a SIP request with the <alert-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "false" and:

1) if the <allow-cancel-emergency-alert> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then the MCPTT emergency alert cancellation request shall be considered to be an authorised request for an MCPTT emergency alert cancellation; and

2) if the <allow-cancel-emergency-alert> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "false", then the MCPTT emergency alert cancellation request shall be considered to be an unauthorised request for an MCPTT emergency alert cancellation.

6.3.3.1.13.4 Determining authorisation for cancelling an MCPTT emergency call

If the controlling MCPTT function has received a SIP request for an MCPTT group call with the <emergency-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "false", the controlling MCPTT function determines, based on local policy (e.g if the requester is dispatcher or not, initiator of the MCPTT emergency group call, if other participants exist in the MCPTT session who are in emergency state etc), whether the emergency group state cancel request is authorised or not.

1) if the <allow-cancel-private-emergency-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then the MCPTT emergency private call cancellation request shall be considered to be an authorised request for an MCPTT emergency private call cancellation; and

2) if the <allow-cancel-private-emergency-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "false" or not present, then the MCPTT emergency private call cancellation request shall be considered to be an unauthorised request for an MCPTT emergency private call cancellation.

Editor’s Note: [MCProtoc17, CR 0654] Whether the controlling MCPTT function examines the <allow-cancel-private-emergency-call> element or uses local policy to determine whether the calling user is authorised to cancel a private emergency call is FFS.

6.3.3.1.13.5 Determining authorisation for initiating an MCPTT imminent peril call

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

1) if the <allow-imminent-peril-call> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value other than "true" the request for initiating an MCPTT imminent peril call shall be considered to be an unauthorised request for an MCPTT imminent peril call and skip the remaining steps;

2) if the <allow-imminent-peril-call> element of the <list-service> element of the group document identified by the targeted MCPTT group identity is set to a value other than "true" as specified in 3GPP TS 24.481 [31], the request for initiating an MCPTT imminent peril call shall be considered to be an unauthorised request for an MCPTT imminent peril call and skip the remaining steps;

3) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "DedicatedGroup" and if the MCPTT group identity targeted for the call is contained in the <uri-entry> element of the <entry> element of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element (see the MCPTT user profile document in 3GPP TS 24.484 [50]); or

4) if the "entry-info" attribute of the <entry> element of the <MCPTTGroupInitiation> element contained within the <ImminentPerilCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "UseCurrentlySelectedGroup".

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

6.3.3.1.13.6 Determining authorisation for cancelling an MCPTT imminent peril call

If the controlling MCPTT function has received a SIP request with the <imminentperil-ind> element of the application/vnd.3gpp.mcptt-info+xml MIME body set to a value of "false" and:

1) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then the MCPTT emergency call cancellation request shall be considered to be an authorised request for an MCPTT imminent peril call cancellation; and

2) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "false" or not present, then the MCPTT emergency call cancellation request shall be considered to be an unauthorised request for an MCPTT imminent peril call cancellation.

6.3.3.1.13.7 void

6.3.3.1.14 Generating a SIP 403 response for priority call request rejection

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

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

6.3.3.1.15 Sending a SIP re-INVITE request for MCPTT imminent peril group call

This clause is referenced from other procedures.

The controlling MCPTT function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [4].

The controlling MCPTT function:

1) shall include in the Contact header field an MCPTT session identity for the MCPTT session with the g.3gpp.mcptt media feature tag and the isfocus media feature tag according to IETF RFC 3840 [16];

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

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

4) if the in-progress imminent peril state of the group is set to a value of "true" the controlling MCPTT function:

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

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

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

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

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

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

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

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

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

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

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

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

a) generate a SIP MESSAGE request according to clause 6.3.3.1.11 and include in the application/vnd.3gpp.mcptt-info+xml MIME body an <emergency-ind> element set to a value of "false";

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

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

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

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

6.3.3.1.17 Validate priority request parameters

This clause is referenced from other procedures. This procedure validates the combinations of <emergency-ind>, <imminentperil-ind> and <alert-ind> in the application/vnd.3gpp.mcptt-info+xml MIME body included in:

1) a SIP INVITE request or SIP re-INVITE request; or

2) the body "URI" header field of the SIP URI included 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 which is pointed to by a "cid" URL located in the Refer-To header of a SIP REFER request;

Upon receiving a SIP request as specified above with the <emergency-ind> element set to a value of "true", the controlling MCPTT function shall only consider the following as valid combinations:

1) <imminentperil-ind> not included and <alert-ind> included.

Upon receiving a SIP request as specified above with the <emergency-ind> element set to a value of "false", the controlling MCPTT function shall only consider the following as valid combinations:

1) <imminentperil-ind> not included and <alert-ind> not included; or

2) <imminentperil-ind> not included and <alert-ind> included.

Upon receiving a SIP request as specified above with the <imminentperil-ind> element included the controlling MCPTT function shall only consider the request as valid if both the <emergency-ind> and <alert-ind> are not included.

If the combination of the <emergency-ind>, <imminentperil-ind> or <alert-ind> indicators is invalid, the controlling MCPTT function shall send a SIP 403 (Forbidden) response with the warning text set to "150 invalid combinations of data received in MIME body" in a Warning header field as specified in clause 4.4.

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

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

The controlling MCPTT function:

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

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

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

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

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

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

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

6.3.3.1.19 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [48] for an MCPTT emergency group call or MCPTT emergency private call the controlling MCPTT function:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <emergency-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]); and

2) shall retrieve the value of the <resource-priority-priority> element contained in the <emergency-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]).

When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [48] for an MCPTT imminent peril group call the controlling MCPTT function:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <imminent-peril-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]); and

2) shall retrieve the value of the <resource-priority-priority> element contained in the <imminent-peril-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50])

When determining the Resource-Priority header field namespace and priority values as specified in IETF RFC 8101 [48] for a normal MCPTT group or private call the controlling MCPTT function:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <normal-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]); and

2) shall retrieve the value of the <resource-priority-priority> element contained in the <normal-resource-priority> element contained in the <OnNetwork> element of the MCPTT service configuration document (see the service configuration document in 3GPP TS 24.484 [50]).

NOTE: The "normal" Resource-Priority header field value is needed to return to a normal priority value from a priority value adjusted for an MCPTT emergency group or private call or an MCPTT imminent peril group call. The "normal" priority received from the EPS by use of the "normal" Resource-Priority header field value is expected to be the same as the "normal" priority received from the EPS when initiating a call with no Resource-Priority header field included.

6.3.3.1.20 Generating a SIP MESSAGE request to indicate successful receipt of an emergency alert or emergency cancellation

This clause is referenced from other procedures.

This clause describes the procedures for generating a SIP MESSAGE request to notify the originator of an emergency alert or emergency cancellation that the request was successfully received.

The controlling MCPTT function:

1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428 [33];

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

4) shall set the Request-URI to the public service identity of the terminating participating function associated with the MCPTT ID of the targeted MCPTT user;

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

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

5) shall include a P-Asserted-Identity header field set to the public service identity of controlling MCPTT function; and

6) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <mcpttinfo> element containing the <mcptt-Params> element with the <mcptt-request-uri> element set to the value of the MCPTT ID of the targeted MCPTT user.

6.3.3.1.21 void

6.3.3.1.22 void

6.3.3.2 Requests terminated by the controlling MCPTT function

6.3.3.2.1 SDP answer generation

When composing the SDP answer according to 3GPP TS 24.229 [4], the controlling MCPTT function:

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

a) shall replace the IP address and port number in the received SDP offer with the IP address and port number of the controlling MCPTT function; and

2) for the accepted media plane control channel, if present in the received SDP offer:

a) shall replace the IP address and port number in the received SDP offer with the IP address and port number of the controlling MCPTT function, for the accepted media plane control channel, if present in the received SDP offer; and

b) shall include ‘fmtp’ attributes as specified in 3GPP TS 24.380 clause 14.

6.3.3.2.2 Receipt of a SIP INVITE request

On receipt of an initial SIP INVITE request the controlling MCPTT function shall cache SIP feature tags, if received in the Contact header field and if the specific feature tags are supported.

6.3.3.2.3 Sending a SIP response to a SIP INVITE request

6.3.3.2.3.1 Provisional response

When sending SIP provisional responses with the exception of the SIP 100 (Trying) response to the SIP INVITE request the controlling MCPTT function:

1) shall generate the SIP provisional response;

2) shall include a P-Asserted-Identity header field with the public service identity of the controlling MCPTT function;

3) shall include an MCPTT session identity in the Contact header field; and

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

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

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

c) the isfocus media feature tag.

6.3.3.2.3.2 Final response

When sending a SIP 200 (OK) response to the initial SIP INVITE request, the controlling MCPTT function:

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

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

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

4) shall include a P-Asserted-Identity header field with the public service identity of the controlling MCPTT function;

5) shall include a SIP URI for the MCPTT session identity in the Contact header field identifying the MCPTT session at the controlling MCPTT function;

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

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

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

c) the isfocus media feature tag;

7) shall include Warning header field(s) received in incoming responses to the SIP INVITE request;

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

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

10) shall include the "explicitsub" and "nosub" option tags in a Supported header field according to IETF RFC 7614 [35]; and

11) void

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

6.3.3.2.4 Receiving a SIP BYE request

Upon receiving a SIP BYE request the controlling MCPTT function:

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

NOTE: The non-controlling MCPTT function is also regarded as a MCPTT client in a temporary MCPTT group session.

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

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

4) if release of the MCPTT session is required:

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

5) if a release of the MCPTT session is not required, shall send a SIP NOTIFY request to all remaining MCPTT clients in the MCPTT session with a subscription to the conference event package as specified in clause 10.1.3.4.2.

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

6.3.3.3 Handling of the acknowledged call setup timer (TNG1)

When the controlling MCPTT function receives a SIP INVITE request to initiate a group session and there are members of the group document retrieved from the group management server that are affiliated and are marked as <on-network-required> as specified in 3GPP TS 24.481 [31], then the controlling MCPTT function shall start timer TNG1 (acknowledged call setup timer) with a timer value as described in Annex B.2.1, prior to sending out SIP INVITE requests inviting group members to the group session.

When the controlling MCPTT function receives all SIP 200 (OK) responses to the SIP INVITE requests, from all affiliated and <on-network-required> members then the controlling MCPTT function shall stop timer TNG1 (acknowledged call setup timer) and if the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the value of the <on-network-minimum-number-to-start> element of the group document, the controlling MCPTT function shall send a SIP 200 (OK) response to the initiating MCPTT client.

NOTE 1: MCPTT clients that are affiliated but are not <on-network-required> members that have not yet responded will be considered as joining an ongoing session when the controlling MCPTT function receives SIP 200 (OK) responses from these MCPTT clients.

After expiry of timer TNG1 (acknowledged call setup timer) and the local counter of the number of SIP 200 (OK) responses received from invited members is less than the value of the <on-network-minimum-number-to-start> element of the group document, then the controlling MCPTT function shall wait until further responses have been received from invited clients and the value of the local counter of the number of SIP 200 (OK) responses received from invited members is equal to the <on-network-minimum-number-to-start>, before continuing with the timer TNG1 expiry procedures in this clause.

After expiry of timer TNG1 (acknowledged call setup timer) and the local counter of the number of SIP 200 (OK) responses received from invited members is greater or equal to the value of the <on-network-minimum-number-to-start> element of the group document, the controlling MCPTT function shall execute the steps described below:

1) if the <on-network-action-upon-expiration-of-timeout-for-acknowledgement-of-required-members> element configured in the group document for the action on expiry of the timer is set to "proceed" indicating that the controlling MCPTT function should proceed with the setup of the group call, then the controlling MCPTT function:

a) shall perform the following actions:

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

ii) include in the SIP 200 (OK) response the warning text set to "111 group call proceeded without all required group members" in a Warning header field as specified in clause 4.4;

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

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

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

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

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

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

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

2) if the <on-network-action-upon-expiration-of-timeout-for-acknowledgement-of-required-members> element configured in the group document for the action on expiry of the timer is set to "abandon" indicating that the controlling MCPTT function should abandon the setup of the group call, then the controlling MCPTT function shall:

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

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

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

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

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

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

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

If:

1) the controlling MCPTT function receives a final SIP 4xx, 5xx or 6xx response from an affiliated and <on-network-required> group member prior to expiry of timer TNG1 (acknowledged call setup timer);

2) the local counter of the number of SIP 200 (OK) responses received from invited members is greater than or equal to the value of the <on-network-minimum-number-to-start> element of the group document; and

3) based on policy, the controlling MCPTT function decides to continue with the establishment of the group call without the affiliated and <on-network-required> group member;

then the controlling MCPTT function:

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

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

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

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

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

c) include in the SIP 200 (OK) response the warning text set to "111 group call proceeded without all required group members" in a Warning header field as specified in clause 4.4;

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

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

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

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

Upon receiving a SIP ACK to the above SIP 200 (OK) response and

1) the SIP 200 (OK) response contained the warning text set to "111 group call proceeded without all required group members" in a Warning header field and

2) the user profile of MCPTT client that originated the group session contains the element <allow-to-receive-non-acknowledged-users-information> and is set to a value of "true",

then the controlling MCPTT function may:

1) generate a SIP INFO request according to rules and procedures of 3GPP TS 24229 [4] and IETF RFC 6086 [64];

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

3) include an application/vnd.3gpp.mcptt-info+xml MIME body as specified in clause F.1 with a <non-acknowledged-user> element containing the MCPTT ID of each of the invited members that have not sent a SIP 200 (OK) response; and

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

6.3.3.4 Generating a SIP NOTIFY request

The controlling MCPTT function shall generate a SIP NOTIFY request according to 3GPP TS 24.229 [4] with the clarification in this clause.

In the SIP NOTIFY request, the controlling MCPTT function:

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

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

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

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

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

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

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

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

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

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

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

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

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

i) shall for the MCPTT client, which initiated, joined or rejoined an MCPTT session, include the MCPTT ID of the MCPTT user which originates SIP INVITE request; and

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

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

i) shall include the "entity" attribute;

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

iii) may include one <functional-alias> element indicating the functional alias bound by the MCPTT user with the MCPTT group for which the notification is being sent as defined in the XML schema of clause 10.1.3.6.1; and

NOTE 1: The functional alias binding by the MCPTT user with the MCPTT group is done through either using an explicit procedure or as a part of call setup procedure.

c) may include <roles> element.

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

6.3.3.5 Handling of the group call timer (TNG3)

6.3.3.5.1 General

When the controlling MCPTT function receives a SIP INVITE request to initiate a group session, then after an MCPTT session identity has been allocated for the group session and if the <on-network-maximum-duration> element is present in the group document as specified in 3GPP TS 24.481 [31], the controlling MCPTT function: shall start timer TNG3 (group call timer) with the value obtained from the <on-network-maximum-duration> element of the group document as specified in 3GPP TS 24.481 [31].

If the <on-network-maximum-duration> element is not present in the group document as specified in 3GPP TS 24.481 [31], then the controlling MCPTT function shall not start timer TNG3 (group call timer).

NOTE 1: The configuration of <on-network-maximum-duration> element in 3GPP TS 24.481 [31] is mandated for a pre-arranged group and is optional for a chat group.

When merging two or more active group calls into a temporary group call, the controlling MCPTT function(s) hosting the active group calls shall stop timer TNG3 (group call timer) for each group call, and the controlling MCPTT function hosting the temporary group call shall start timer TNG3 (group call timer) for the temporary group call.

NOTE 2: If the MCPTT server(s) hosting the independent active group calls are different to the MCPTT server that will host the temporary group call, then the MCPTT server(s) hosting the independent active group calls become non-controlling MCPTT function(s) of an MCPTT group, for the temporary group call.

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

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

On expiry of timer (group call timer), the controlling MCPTT function shall release the MCPTT session by following the procedures in clause 6.3.3.1.5;

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

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

If timer TNG3 (group call timer) is running and the MCPTT group call is upgraded to an MCPTT emergency group call, then the controlling MCPTT function shall stop timer TNG3 (group call timer) and shall start timer TNG2 (in-progress emergency group call timer) with the value obtained from the <group-time-limit> element of the <emergency-call> element of the <on-network> element of the service configuration document as specified in 3GPP TS 24.484 [50].If timer TNG2 (in-progress emergency group call timer) is running and the MCPTT emergency group call is cancelled, then the controlling MCPTT function shall stop timer TNG2 (in-progress emergency group call timer) and shall start timer TNG3 (group call timer) with the value obtained from the <on-network-maximum-duration> element of the group document as specified in 3GPP TS 24.481 [31].

If timer TNG2 (in-progress emergency group call timer) is running and subsequently expires, then the controlling MCPTT function shall start timer TNG3 (group call timer) with the value obtained from the <on-network-maximum-duration> element of the group document as specified in 3GPP TS 24.481 [31].

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

6.3.3.6 Void

6.3.4 Non-controlling MCPTT function of an MCPTT group

6.3.4.1 Request initiated by the non-controlling MCPTT function of an MCPTT group

6.3.4.1.1 SDP offer generation

The SDP offer is generated based on the received SDP offer. The SDP offer generated by the non-controlling MCPTT function of an MCPTT group:

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

2) shall include one SDP media-level section for media plane control messages, if present in the received SDP offer.

When composing the SDP offer according to 3GPP TS 24.229 [4], the non-controlling MCPTT function of an MCPTT group:

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

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

3) shall replace the IP address and port number for the offered media plane control channel, if any, in the received SDP offer with the IP address and port number of the non-controlling MCPTT function; and

4) shall include the offered media plane control channel ‘fmtp’ attributes as specified in 3GPP TS 24.380 [5] clause 14.

6.3.4.1.2 Sending an INVITE request towards the MCPTT client

This clause is referenced from other procedures.

The non-controlling MCPTT function of an MCPTT group shall generate initial SIP INVITE requests according to 3GPP TS 24.229 [4].

For each SIP INVITE request, the non-controlling MCPTT function of an MCPTT group:

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

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

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

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

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

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

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

6a) shall update the application/vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-calling-group-id> element set to the identity of the TGI or of the group regroup based on a preconfigured group;

6b) shall update the application/vnd.3gpp.mcptt-info+xml MIME body with an <associated-group-id> element set to the identity of the constituent group;

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

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

9) shall include the received Referred-By header field with the public user identity of the inviting MCPTT client;

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

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

12) void.

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

14) void.

6.3.4.1.3 Sending a SIP INFO request

This clause is referenced from other procedures.

The non-controlling MCPTT function shall generate a SIP INFO request according to rules and procedures of 3GPP TS 24.229 [4] and IETF RFC 6086 [64].

The non-controlling MCPTT function:

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

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

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

a) the <floor-type> element set to "general" or "dual" as described in clause F.5.3;

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

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

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

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

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

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

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

4) if:

a) the non-controlling MCPTT function has location information (see clause 13.2.4) for the MCPTT client; and

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

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

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

6.3.4.1.4 Sending an INVITE request towards the controlling MCPTT function

This clause is referenced from other procedures.

The non-controlling MCPTT function shall generate a SIP INVITE request according to rules and procedures of 3GPP TS 24.229 [4].

The non-controlling MCPTT function:

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

2) 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-Asserted-Service-Id header field according to IETF RFC 6050 [9] in the SIP INVITE request;

3) shall set the Request-URI to the public service identity of the controlling MCPTT function based on the <mcptt-request-uri> element received in the "SIP INVITE request from participating MCPT function for non-controlling MCPTT function of an MCPTT group";

NOTE 1: The public service identity can identify the controlling MCPTT function in the local MCPTT system or in an interconnected MCPTT system.

NOTE 2: If the controlling MCPTT function is in an interconnected 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 interconnected MCPTT system from the local MCPTT system.

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

NOTE 4: How the non-controlling MCPTT function determines the public service identity of the controlling MCPTT function based on the <mcptt-request-uri> element received in the "SIP INVITE request from participating MCPTT function for non-controlling MCPTT function of an MCPTT group" or of the MCPTT gateway server in the interconnected MCPTT system is out of the scope of the present document.

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

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

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

NOTE 6: The <session-type> element set to "prearranged" regardless of which type of group the constituent MCPTT group is.

b) the <mcptt-request-uri> element set to the identity of the TGI or of the group regroup based on a preconfigured group received in the <mcptt-request-uri> element of the received SIP INVITE;

c) the <mcptt-calling-group-id> element set to the identity of the constituent group received in the <associated-group-id> element of the received SIP INVITE;

d) the <mcptt-calling-user-id> element set to the identity of the calling user received in the <mcptt-calling-user-id> element of the received SIP INVITE; and

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

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

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

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

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

6.3.4.2.1 SDP answer generation

When composing the SDP answer according to 3GPP TS 24.229 [4], the non-controlling MCPTT function of an MCPTT group:

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

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

2) for the accepted media plane control channel, if present in the received SDP offer:

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

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

6.3.4.2.2 Sending a SIP response to the SIP INVITE request

6.3.4.2.2.1 Sending a SIP 183 (Session Progress) response

When sending a SIP 183 (Session Progress) the non-controlling MCPTT function of an MCPTT group:

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

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

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

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

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

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

6.3.4.2.2.2 Sending a SIP 200 (OK) response

When sending a SIP 200 (OK) response, the non-controlling MCPTT function of an MCPTT group:

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

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

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

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

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

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

6) if allowed by local policy and if Warning header field(s) were received in incoming responses to SIP INVITE requests that were sent as a result of following the procedures of clause 6.3.4.1.2, shall include those Warning header field(s);

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

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

6.3.4.3 Generating a SIP NOTIFY request

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

In the SIP NOTIFY request, the non-controlling MCPTT function:

1) shall set the P-Asserted-Identity header field to the public service identity of the non-controlling MCPTT function;

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

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

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

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

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

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

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

In the SIP NOTIFY request, the non-controlling MCPTT function shall include application/conference-info+xml MIME body according to IETF RFC 4575 [30] as specified in clause 6.3.3.4 with the following exceptions:

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

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

2) the non-controlling MCPTT function shall include stored conference status information received in SIP NOTIFY requests from the controlling MCPTT function in clause 10.1.3.5.3 and status information about own participants.

6.3.4.4 Void

6.3.5 Retrieving and processing a group document

6.3.5.1 General

This clause describes how an MCPTT server accesses a group document from a group management server. The MCPTT server which accesses a group document performs the role of a controlling MCPTT function or performs the role of a non-controlling MCPTT function of an MCPTT group when accessing a group document. In such cases, for a group call:

– the controlling MCPTT function and group management server are both located in the primary MCPTT system;

– the controlling MCPTT function and group management server are both located in a partner MCPTT system;

– the controlling MCPTT function is located in the primary MCPTT system and accesses a group management server in the primary MCPTT system and a non-controlling MCPTT function of an MCPTT group is located in a partner MCPTT system and accesses a group management server in the partner MCPTT system; or

– the controlling MCPTT function and non-controlling MCPTT function(s) of an MCPTT group are located in the primary MCPTT system and access group management servers in the primary MCPTT system.

When the MCPTT server receives a SIP INVITE request that requires it to access a group document, it uses an MCPTT group ID or a temporary MCPTT group identity (TGI) which was created by the group regrouping operation as specified in 3GPP TS 24.481 [31].

The MCPTT server can cache the group document associated with an MCPTT group or temporary group, and can subscribe to be notified of changes to the group document associated with an MCPTT group or temporary group as specified in 3GPP TS 24.481 [31].

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

If the group data associated with an MCPTT group ID or TGI cached in the MCPTT server is removed, the MCPTT server re-subscribes for changes in the group information associated with the MCPTT group ID or TGI.

NOTE 2: Re-subscription can occur prior to the receipt of an SIP INVITE request containing an MCPTT group ID or TGI of a group document which is no longer cached on the MCPTT server.

6.3.5.2 Rules for retrieving Group Document(s)

NOTE 1: In this clause, "MCPTT server" can refer to either the controlling MCPTT function of an MCPTT group or the non-controlling MCPTT function of an MCPTT group.

When the group document is retrieved for the controlling MCPTT function procedures or for the non-controlling MCPTT function terminating procedures (clauses 10.1.1.5.2), the requested group identity refers to the group identity in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request.

When the group document is retrieved for the non-controlling MCPTT function to initiate a temporary group session (clause 10.1.1.5.5), the requested group identity refers to the group identity of the constituent group contained in the <associated-group-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request.

Upon receipt of a SIP INVITE request:

1) if the MCPTT server is not yet subscribed to the group document for the requested group, the MCPTT server shall subscribe to the "xcap-diff" event-package for the group document of this group identity as specified in 3GPP TS 24.481 [31];

NOTE 2: The requested group identity is either an MCPTT group ID or a temporary MCPTT group identity (TGI).

NOTE 3: As a group document can potentially have a large content, the controlling MCPTT function of an MCPTT group can subscribe to the group document indicating support of content-indirection as defined in IETF RFC 4483 [32], by following the procedures in 3GPP TS 24.481 [31].

2) upon receipt of a SIP 404 (Not Found) response as a result of attempting to subscribe to the "xcap-diff" event-package for the group document of the requested group as specified in 3GPP TS 24.481 [31], the MCPTT server shall send the SIP 404 (Not Found) response with the warning text set to "113 group document does not exist" in a Warning header field as specified in clause 4.4. Otherwise, continue with the rest of the steps;

3) upon receipt of any other SIP 4xx, SIP 5xx or SIP 6xx response as a result of attempting to subscribe to the "xcap-diff" event-package for the group document of the requested group identity as specified in 3GPP TS 24.481 [31], the MCPTT server shall send the SIP final response with the warning text set to "114 unable to retrieve group document" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

4) upon receipt of a notification from the group management server containing the group document for the requested group identity, or if the group document is already cached:

a) if the MCPTT server is a non-controlling function of an MCPTT group, then the MCPTT server shall exit this clause; and

b) if the MCPTT server is a controlling function of an MCPTT group, then the MCPTT server shall determine if the group document is for a TGI or an MCPTT group ID as follows:

i) if the group document includes an <on-network-temporary> element, then the group document is associated with a TGI;

ii) if the group document does not include an <on-network-temporary> element or an <on-network-regrouped> element, then the group document is associated with an MCPTT group ID that has not been regrouped; and

iii) if the group document does not include an <on-network-temporary> element but includes an <on-network-regrouped> element, then the group document is associated with an MCPTT group ID that has been regrouped;

5) if the requested group identity is an MCPTT group ID that has not been re-grouped, then:

a) if the <on-network-disabled> element is present in the group document, shall send a SIP 403 (Forbidden) response with the warning text set to "115 group is disabled" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

b) if the <list> element of the <list-service> element does not contain an entry matching the MCPTT ID of the user in the SIP INVITE request, shall send a SIP 403 (Forbidden) response with the warning text set to "116 user is not part of the MCPTT group" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

c) if the <on-network-invite-members> element is set to "true" and if the SIP INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element containing a value not set to "prearranged", shall return a SIP 404 (Not Found) response with the warning text set to "117 the group identity indicated in the request is a prearranged group" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps; and

d) if the <on-network-invite-members> element is set to "false" and if the SIP INVITE request contains an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element containing a value not set to "chat" shall return a SIP 404 (Not Found) response with the warning text set to "118 the group identity indicated in the request is a chat group" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps; and

6) if the requested group identity is an MCPTT group ID that has been regrouped then the MCPTT server:

a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the warning text set to "148 group is regrouped" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps.

6.3.5.3 Rules for joining a group session

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

1) an <entry> element exists in the <list> element of the group document for the MCPTT user;

2) a <rule> exists in the group document with:

a) the <is-list-member> element of the <conditions> element present and with the <join-handling> element of the corresponding <actions> element set to "true"; or

b) the <identity> element of the <conditions> element containing an entry matching the MCPTT ID in the SIP INVITE request, with the <join-handling> element of the <actions> element set to "true"; and

3) if the <supported-services> element is present, it contains:

a) a <service> element containing an "enabler" attribute which is set to the MCPTT ICSI; and

b) if a <group-media> element is present, an entry set to "MCPTT speech".

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

6.3.5.4 Rules for initiating a prearranged group session

When the non-controlling MCPTT function of an MCPTT group receives a request to intiate a group session for the calling MCPTT user, if:

1) one of the following conditions is met:

a) the <on-network-regrouped> element in the <list-service> element is present in the group document associated with the MCPTT group ID identified in the <associated-group-id> element of the incoming SIP INVITE and if the MCPTT group ID indicated in the <mcptt-request-uri> element of the incoming INVITE request is the same as the MCPTT group ID in the "temporary-MCPTT-group-ID" attribute of the <on-network-regrouped> element; or

b) according to the information stored per procedures of clause 16, the group identified in the <mcptt-request-uri> of the incoming SIP INVITE is a group regroup based on a preconfigured group and if the group identified in the <associated-group-id> of the incoming SIP INVITE is a constituent group of that group regroup based on a preconfigured group according;

NOTE 1: In this step 1),the non-controlling MCPTT function checks the consistency of the constituent group with the called group regroup.

2) an <entry> element set to the MCPTT IDof the calling MCPTT user exists in the <list> element of the group document associated with the MCPTT group ID identified in the <associated-group-id> element of the incoming SIP INVITE;

NOTE 2: In this step 2),the non-controlling MCPTT function checks that the calling MCPTT user is a member of the constituent group.

3) a <rule> exists in the group document with:

a) the <is-list-member> element of the <conditions> element present and with the <allow-initiate-conference> element of the corresponding <actions> element set to "true"; or

b) the <identity> element of the <conditions> element containing an entry matching the MCPTT ID of the calling MCPTT user identified in the <mcptt-calling-user-id> element of the SIP INVITE request, with the <allow-initiate-conference> element of the <actions> element is set to "true"; and

4) the <supported-services> element exists in the group document with:

a) a <service> element containing an "enabler" attribute which is set to the MCPTT ICSI; and

b) a <group-media> element containing an entry set to "MCPTT speech".

NOTE 3: In these steps 3) and 4) the non-controlling MCPTT function checks that the calling MCPTT user is allowed to initiate the group call per the rules in the group document, and that the group is supporting MCPTT services.

then the calling MCPTT user shall be authorised by the non-controlling MCPTT function to initiate the group session. Otherwise the calling MCPTT user shall not be authorised by the non-controlling MCPTT function to initiate the group session.

When the controlling MCPTT function of an MCPTT group receives a request to intiate a group session for the calling MCPTT user, if:

NOTE 4: The check that the MCPTT group has not been regrouped (is not a constituent group) is done in the parent procedure and in clause 6.3.5.2.

1) the MCPTT group ID identified in the <mcptt-request-uri> element of the incoming SIP INVITE is a temporary group or a group regroup based on preconfigured group, then the calling MCPTT user shall be authorised by the controlling MCPTT function to initiate the group session and the rest of the steps in this clause shall be skipped;

NOTE 5: The consistency of the constituent group with the called regroup has been checked at the non-controlling MCPTT function.

NOTE 6: The check that the requesting user is authorised to initiate the group call has been done at the non-controlling of the constituent group.

2) one of the following conditions is met:

a) an <entry> element set to the MCPTT ID of the calling MCPTT user exists in the <list> element of the group document associated with the MCPTT group ID identified in the <mcptt-request-uri > element of the incoming SIP INVITE; or

b) the group is a user regroup based on a preconfigured group and the MCPTT ID contained in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the SIP INVITE request is included in the list of users that was stored during successful processing of the creation of the user regroup per clause 16;

NOTE 7: In this step 2), the controlling MCPTT function checks that the calling MCPTT user is a member of the normal group (i.e. not a constituent group nor a regroup) or a user regroup.

3) a <rule> exists in the group document with:

a) the <is-list-member> element of the <conditions> element present and with the <allow-initiate-conference> element of the corresponding <actions> element set to "true"; or

4) the <supported-services> element exists in the group document with:

a) a <service> element containing an "enabler" attribute which is set to the MCPTT ICSI; and

b) a <group-media> element containing an entry set to "MCPTT speech".

NOTE 8: In these steps 3) and 4), the controlling MCPTT function checks that the calling MCPTT user is allowed to initiate the group call per the rules in the group document, and that the group is supporting MCPTT services.

then the calling MCPTT user shall be authorised by the controlling MCPTT function to initiate the group session. Otherwise the calling MCPTT user shall not be authorised by the controlling MCPTT function to initiate the group session.

6.3.5.5 Determining the group members to invite

The MCPTT server shall only invite affiliated group members to a group session.

If the group is not a regroup based on a preconfigured group, the MCPTT server determines the affiliated members from the entries contained in the <list> element of the group document by following the procedures specified in clause 6.3.6.

If the group is a regroup based on a preconfigured group, the MCPTT server determines the affiliated members from the list of users that was stored during successful processing of the creation of the regroup per clause 16 by following the procedures specified in clause 6.3.6.

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

If the number of members of the MCPTT group exceeds the value contained in the <on-network-max-participant-count> element the MCPTT server shall invite only <on-network-max-participant-count> members from the list, but shall prioritise inviting those group members to the group session that have an <entry> element in the <list> element with a <on-network-required> element present.

NOTE 2: The <on-network-max-participant-count> element indicates the maximum number of participants allowed in the group session. The <on-network-required> element is used to determine which group members need to acknowledge the group call before audio transmission can proceed.

NOTE 3: Other requirements for how the controlling MCPTT function selects which of the <on-network-max-participant-count> members to invite is outside the scope of this specification.

NOTE 4: It is assumed that validation checks are performed at the group management server to ensure that the <on-network-max-participant-count> cannot be less than the number of <on-network-required> users.

6.3.6 Affiliation check

The MCPTT server checks if an MCPTT user is affiliated to an MCPTT group at an MCPTT client by following the procedures specified below:

1. the MCPTT server shall find the applicable MCPTT group information entry as an MCPTT group information entry of the list of MCPTT group information entries described in clause 9.2.2.3.2, such that the MCPTT group ID of the MCPTT group information entry is equal to the MCPTT group identity of the MCPTT group. If the applicable MCPTT group information entry cannot be found, then the MCPTT server shall determine that the MCPTT user is not affiliated to the MCPTT group at the MCPTT client and the MCPTT server shall not continue with rest of the steps;

2. the MCPTT server shall find the applicable MCPTT user information entry as an MCPTT user information entry of the list of MCPTT user information entries of the applicable MCPTT group information entry, such that the MCPTT ID of the MCPTT user information entry is equal to the MCPTT ID of the MCPTT user. If the applicable MCPTT user information entry cannot be found, then the MCPTT server shall determine that the MCPTT user is not affiliated to the MCPTT group at the MCPTT client and the MCPTT server shall not continue with rest of the steps;

3. if the MCPTT client ID of the MCPTT client cannot be found in the list of MCPTT client information entries of the applicable MCPTT user information entry, then the MCPTT server shall determine that the MCPTT user is not affiliated to the MCPTT group at the MCPTT client and the MCPTT server shall not continue with rest of the steps;

NOTE: the MCPTT client ID of the originating MCPTT client can be found in the <mcptt-client-id> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body of a SIP INVITE request, SIP REFER request or SIP MESSAGE request originated by the MCPTT client.

4. if the expiration time of the applicable MCPTT user information entry has been reached, then the MCPTT server shall determine that the MCPTT user is not affiliated to the MCPTT group at the MCPTT client and the MCPTT server shall not continue with rest of the steps; and

5. the MCPTT server shall determine that the MCPTT user is affiliated to the MCPTT group at the MCPTT client.

6.3.7 Error handling

6.3.7.1 Public service identity does not exist

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

6.3.8 Session release policy

6.3.8.1 Session release policy for group call

If:

1) the call is a pre-arranged group call and if the controlling MCPTT function receives an indication from the media plane that the T4 (Inactivity) timer specified in 3GPP TS 24.380 [5] expired;

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

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

4) the minimum number of affiliated MCPTT group members is not present;

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

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

the controlling MCPTT function shall release the MCPTT session for the group call.

6.3.8.2 Session release policy for private call

If:

1) the controlling MCPTT function receives an indication from the media plane that the T4 (Inactivity) timer specified in 3GPP TS 24.380 [5] expired;

2) the MCPTT session has lasted longer than the maximum of duration of private call; or

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

the controlling MCPTT function shall release the MCPTT session for a private call.