6.2 MCData client procedures

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

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

6.2.1 Distinction of requests at the MCData client

6.2.1.1 SIP MESSAGE request

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

– SIP MESSAGE request routed to the MCData client containing a Content-Type header field set to "application/vnd.3gpp.mcdata-location-info+xml" and includes an XML body containing a Location root element containing a Configuration element. Such requests are known as "SIP MESSAGE request for location report configuration";

– SIP MESSAGE request routed to the MCData client containing a Content-Type header field set to "application/vnd.3gpp.mcdata-location-info+xml" and includes an XML body containing a Location root element containing a Request element. Such requests are known as "SIP MESSAGE request for location report request";

– SIP MESSAGE request routed to the MCData client containing a Content-Type header field set to "application/vnd.3gpp.mcdata-info+xml" and including an <alert-ind> element set to a value of "true" or "false" and/or an <emergency-ind> element set to a value of "true" or "false". Such requests are known as "SIP MESSAGE request for emergency notification";

– SIP MESSAGE request routed to the MCData client with 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.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field. Such requests are known as "SIP MESSAGE request for standalone SDS for terminating MCData client";

– SIP MESSAGE request routed to the MCData client with 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.mcdata.fd", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in a P-Asserted-Service header field. Such requests are known as "SIP MESSAGE request for FD using HTTP for terminating MCData client";

– SIP MESSAGE request routed to the MCData client with 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.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field, and with an application/vnd.3gpp.mcdata-signalling MIME body containing an SDS NOTIFICATION message Such requests are known as "SIP MESSAGE request for SDS disposition notification for terminating MCData client"; and

– SIP MESSAGE request routed to the MCData client with 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.mcdata.fd", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in a P-Asserted-Service header field, and with an application/vnd.3gpp.mcdata-signalling MIME body containing an FD NOTIFICATION message Such requests are known as "SIP MESSAGE request for FD disposition notification for terminating MCData client";

– SIP MESSAGE request routed to the MCData client with 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.mcdata.fd", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in a P-Asserted-Service header field, and with an application/vnd.3gpp.mcdata-info+xml MIME body containing a <request-type> element in of the SIP MESSAGE request contains the value "msf-disc-res". Such requests are known as "SIP MESSAGE request for absolute URI discovery response";

– SIP MESSAGE request routed to the MCData client with 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.mcdata.fd", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in a P-Asserted-Service header field, and with an application/vnd.3gpp.mcdata-signalling MIME body containing an DEFERRED DATA RESPONSE message. Such requests are known as "SIP MESSAGE response for the list of deferred group communications request"

– SIP MESSAGE requests routed to the MCData client with the Request-URI set to a public user identity of the MCData user that contains a <preconfigured-group> element in an application/vnd.3gpp.mcdata-regroup+xml MIME body and a <regroup-action> element set to "create". Such requests are known as "SIP MESSAGE request to the MCData client to request creation of a regroup using preconfigured group" in the procedures in the present document;

– SIP MESSAGE requests routed to the MCData client with the Request-URI set to a public user identity of the MCData user that contains a <preconfigured-group> element in an application/vnd.3gpp.mcdata-regroup+xml MIME body and a <regroup-action> element set to "remove". Such requests are known as "SIP MESSAGE request to the MCData client to request removal of a regroup using preconfigured group" in the procedures in the present document.

– SIP MESSAGE requests routed to the MCData client containing a Content-Type header field set to "application/vnd.3gpp.mcdata-info+xml" and including an XML body containing a <mcdata-info> root element containing the <mcdata-Params> element and an <emergency-alert-area-ind> element. Such requests are known as "SIP MESSAGE request for notification of entry into or exit from an emergency alert area"; and

– SIP MESSAGE requests routed to the MCData client containing a Content-Type header field set to "application/vnd.3gpp.mcdata-info+xml" and including an XML body containing a <mcdata-info> root element containing the <mcdata-Params> element and a <group-geo-area-ind> element. Such requests are known as "SIP MESSAGE request for notification of entry into or exit from a group geographic area".

6.2.1.2 SIP INVITE request

The MCData client needs to distinguish between the following initial SIP INVITE requests for terminations:

– SIP INVITE request routed to the terminating MCData client with 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.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-sds" or "group-sds" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for standalone SDS over media plane for terminating MCData client";

– SIP INVITE request routed to the terminating MCData client with 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.mcdata.sds", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-sds-session" or "group-sds-session" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for SDS session for terminating MCData client";

– SIP INVITE request routed to the terminating MCData client with 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.mcdata.fd", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-fd" or "group-fd" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for file distribution for terminating MCData client"; and

– SIP INVITE request routed to the terminating MCData client with 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.mcdata.ipconn", and an ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.ipconn" in a P-Asserted-Service header field and a <request-type> element set to "one-to-one-ipconn" contained in an application/vnd.3gpp.mcdata-info+xml MIME body. Such requests are known as "SIP INVITE request for IP Connectivity session for terminating MCData client".

6.2.2 MCData conversation items

6.2.2.1 Generating an SDS Message

In order to generate an SDS message, the MCData client:

1) shall generate an SDS SIGNALLING PAYLOAD message as specified in clause 15.1.2;

2) shall generate a DATA PAYLOAD message as specified in clause 15.1.4;

3) shall include in the SIP request, the SDS SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1; and

4) shall include in the SIP request, the DATA PAYLOAD message in an application/vnd.3gpp.mcdata-payload MIME body as specified in clause E.2.

When generating an SDS SIGNALLING PAYLOAD message as specified in clause 15.1.2, the MCData client:

1) shall set the Date and time IE to the current time as specified in clause 15.2.8;

2) if the SDS message starts a new conversation, shall set the Conversation ID IE to a newly generated Conversation ID value as specified in clause 15.2.9;

3) if the SDS message continues an existing unfinished conversation, shall set the Conversation ID IE to the Conversation ID value of the existing conversation as specified in clause 15.2.9;

4) shall set the Message ID IE to a newly generated Message ID value as specified in clause 15.2.10;

5) if the SDS message is in reply to a previously received SDS message, shall include the InReplyTo message ID IE with the Message ID value in the previously received SDS message;

6) if the SDS message is for user consumption, shall not include an Application ID IE as specified in clause 15.2.7and shall not include an Extended application ID IE as specified in clause 15.2.24;

7) if the SDS message is intended for an application on the terminating MCData client, shall include:

a) an Application ID IE with a Application ID value representing the intended application as specified in clause 15.2.7; or

b) an Extended application ID IE with an Extended application ID value representing the intended application as specified in clause 15.2.24;

NOTE: The value chosen for the Application ID value is decided by the mission critical organisation.

8) if only a delivery disposition notification is required shall include a SDS disposition request type IE set to "DELIVERY" as specified in clause 15.2.3;

9) if only a read disposition notification is required shall include a SDS disposition request type IE set to "READ" as specified in clause 15.2.3;

10) if both a delivery and read disposition notification is required shall include a SDS disposition request type IE set to "DELIVERY AND READ" as specified in clause 15.2.3;

11) may set the User location IE to the current location of the UE as specified in clause 15.2.25; and

12) may include an Application metadata container IE as specified in clause 15.2.28.

When generating an DATA PAYLOAD message for SDS as specified in clause 15.1.4, the MCData client:

1) shall set the Number of payloads IE to the number of Payload IEs that needs to be encoded, as specified in clause 15.2.12;

2) if end-to-end security is required for a one-to-one communication, shall include the Security parameters and Payload IE with security parameters as described in 3GPP TS 33.180 [26]. Otherwise, if end-to-end security is not required for a one-to-one communication, shall include the Payload IE as specified in clause 15.1.4; and

3) for each Payload IE included:

a) if the payload is text, shall set the Payload content type as "TEXT" as specified in clause 15.2.13;

b) if the payload is binary data, shall set the Payload content type as "BINARY" as specified in clause 15.2.13;

c) if the payload is hyperlinks, shall set the Payload content type as "HYPERLINKS" as specified in clause 15.2.13;

d) if the payload is location, shall set the Payload content type as "LOCATION" as specified in clause 15.2.13;

e) if payload is enhanced status for a group, shall set the Payload content type as "ENHANCED STATUS" as specified in subclase 15.2.13; and

f) shall include the data to be sent in the Payload data.

6.2.2.2 Generating an FD Message for FD using HTTP

In order to generate an FD message, the MCData client:

1) shall generate an FD SIGNALLING PAYLOAD message as specified in clause 15.1.3; and

2) shall include in the SIP request, the FD SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1.

When generating an FD SIGNALLING PAYLOAD message as specified in clause 15.1.3, the MCData client:

1) shall set the Date and time IE to the current time as specified in clause 15.2.8;

2) if the FD message starts a new conversation, shall set the Conversation ID IE to a newly generated Conversation ID value as specified in clause 15.2.9;

3) if the FD message continues an existing unfinished conversation, shall set the Conversation ID IE to the Conversation ID value of the existing conversation as specified in clause 15.2.9;

4) shall set the Message ID IE to a newly generated Message ID value as specified in clause 15.2.10;

5) if the FD message is in reply to a previously received MCData message, shall include the InReplyTo message ID IE with the Message ID value in the previously received MCData message;

6) if the FD message is for user consumption, shall not include an Application ID IE as specified in clause 15.2.7 and shall not include an Extended application ID IE as specified in clause 15.2.24;

7) if the FD message is intended for an application on the terminating MCData client, shall include:

a) an Application ID IE with a Application ID value representing the intended application as specified in clause 15.2.7; or

b) an Extended application ID IE with an Extended application ID value representing the intended application as specified in clause 15.2.24;

NOTE: The value and field chosen for coding the identity of the application are coordinated by the mission critical organisation.

8) may include an FD disposition request type IE set to "FILE DOWNLOAD COMPLETE UPDATE" as specified in clause 15.2.4;

9) if requiring mandatory download at the recipient side, shall include a Mandatory download IE as specified in clause 15.2.16 set to the value of "MANDATORY DOWNLOAD";

10) shall include a Payload IE with:

a) the Payload content type set to "FILEURL" as specified in clause 15.2.13; and

b) the URL of the file in the Payload data as as specified in clause 15.2.13;

11) may include a Metadata IE with the required file description information and file availability information, as specified in clause 15.2.17; and

12) may include an Application metadata container IE as specified in clause 15.2.28.

6.2.2.3 Generating an FD Message for FD using media plane

In order to generate an FD message, the MCData client:

1) shall generate an FD SIGNALLING PAYLOAD message as specified in clause 15.1.3; and

2) shall include in the SIP request, the FD SIGNALLING PAYLOAD message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1.

When generating an FD SIGNALLING PAYLOAD message as specified in clause 15.1.3, the MCData client:

1) shall set the Date and time IE to the current time as specified in clause 15.2.8;

2) if the file starts a new conversation, shall set the Conversation ID IE to a newly generated Conversation ID value as specified in clause 15.2.9;

3) if the file continues an existing conversation, shall set the Conversation ID IE to the Conversation ID value of the existing conversation as specified in clause 15.2.9;

4) shall set the Message ID IE to a newly generated Message ID value as specified in clause 15.2.10;

5) if the file is in reply to a previously received SDS message or file, shall include the InReplyTo message ID IE with the Message ID value in the previously received SDS message or file;

6) if the file is for user consumption, shall not include an Application ID IE as specified in clause 15.2.7 and shall not include an Extended application ID IE as specified in clause 15.2.24;

7) if the file is intended for an application on the terminating MCData client, shall include:

a) an Application ID IE with a Application ID value representing the intended application as specified in clause 15.2.7; or

b) an Extended application ID IE with an Extended application ID value representing the intended application as specified in clause 15.2.24;

NOTE: The value and field chosen for coding the identity of the application are coordinated by the mission critical organisation.

8) if a file download complete notification is required shall include a FD disposition request type IE set to "FILE DOWNLOAD COMPLETED UPDATE" as specified in clause 15.2.4;

9) if mandatory download of a file is required, shall include and set the Mandatory download IE to "MANDATORY DOWNLOAD" as described in clause 15.2.16; and

10) may include an Application metadata container IE as specified in clause 15.2.28.

6.2.2.4 Client generating message to terminate FD over HTTP

In order to generate an message to terminate FD using HTTP, the MCData client:

1) shall generate an FD HTTP TERMINATION message as specified in clause 15.1.13; and

2) shall include in the SIP request, the FD HTTP TERMINATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1.

When generating an FD HTTP TERMINATION message as specified in clause 15.1.13, the MCData client:

1) shall set the Conversation ID IE to a value identifying the conversation, as specified in clause 15.2.9;

2) shall set the Message ID IE to a value identifying the message as specified in clause 15.2.10;

3) may set:

a) the Application ID IE to the stored value if applicable; or

b) the Extended Application ID IE to the stored value if applicable;

4) shall include a Payload IE with:

a) shall set the Payload content type set to "FILEURL" as specified in clause 15.2.13; and

b) shall set the URL of the file same as of FD transmission; and

5) Shall set the Termination information type IE set to "TERMINATION REQUEST" as specified in clause 15.2.22.

6.2.3 Disposition Notifications

6.2.3.1 Generating an SDS Notification

In order to generate an SDS notification, the MCData client:

1) shall generate an SDS NOTIFICATION message as specified in clause 15.1.5; and

2) shall include in the SIP request, the SDS NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1.

When generating an SDS NOTIFICATION message as specified in clause 15.1.5, the MCData client:

1) if sending a delivered notification, shall set the SDS disposition notification type IE as "DELIVERED" as specified in clause 15.2.5;

2) if sending a read notification, shall set the SDS disposition notification type IE as "READ" as specified in clause 15.2.5;

3) if sending a delivered and read notification, shall set the SDS disposition notification type IE as "DELIVERED AND READ" as specified in clause 15.2.5;

4) if the SDS message could not be delivered to the user or application (e.g. due to lack of storage), shall set the SDS disposition notification type IE as "UNDELIVERED" as specified in clause 15.2.5;

5) shall set the Date and time IE to the current time to as specified in clause 15.2.8;

6) shall set the Conversation ID to the value of the Conversation ID that was received in the SDS message as specified in clause 15.2.9;

7) shall set the Message ID to the value of the Message ID that was received in the SDS message as specified in clause 15.2.10;

8) if the SDS message was destined for the user, shall not include an Application ID IE (as specified in clause 15.2.7) and shall not include an Extended application ID IE (as specified in clause 15.2.24); and

9) if the SDS message was destined for an application, shall include:

a) an Application ID IE set to the value of the Application ID that was included in the SDS message as specified in clause 15.2.3; or

b) an Extended application ID IE set to the value of the Extended application ID that was included in the SDS message as specified in clause 15.2.24.

6.2.3.2 Generating an FD Notification

In order to generate an FD notification, the MCData client:

1) shall generate an FD NOTIFICATION message as specified in clause 15.1.6; and

2) shall include in the SIP request, the FD NOTIFICATION message in an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1.

When generating an FD NOTIFICATION message as specified in clause 15.1.6, the MCData client:

1) if sending a file download accept notification, shall set the FD disposition notification type IE as "FILE DOWNLOAD REQUEST ACCEPTED" as specified in clause 15.2.6;

2) if sending a file download reject notification, shall set the FD disposition notification type IE as "FILE DOWNLOAD REQUEST REJECTED" as specified in clause 15.2.6;

3) if sending a file download deferred notification, shall set the FD disposition notification type IE as "FILE DOWNLOAD REQUEST DEFERRED" as specified in clause 15.2.6;

4) shall set the Conversation ID to the value of the Conversation ID that was received in the FD message as specified in clause 15.2.9;

5) shall set the Date and time IE to the current time as specified in clause 15.2.8; and

6) if sending a file download completed notification:

a) shall set the FD disposition notification type IE as "FILE DOWNLOAD COMPLETED" as specified in clause 15.2.6;

b) shall set the Message ID to the value of the Message ID that was received in the FD message as specified in clause 15.2.10;

c) if the FD message was destined for the user, shall not include an Application ID IE as specified in clause 15.2.7 and shall not include a Extended application ID IE as specified in clause 15.2.24; and

d) if the FD message was destined for an application, shall include:

i) an Application ID IE set to the value of the Application ID that was included in the FD message as specified in clause 15.2.3; or

ii) an Extended application ID IE set to the value of the Extended application ID that was included in the FD message as specified in clause 15.2.24.

6.2.4 Sending SIP requests and receiving SIP responses

6.2.4.1 Generating a SIP MESSAGE request towards the originating participating MCData function

This clause is referenced from other procedures.

In a SIP MESSAGE request, the MCData client:

1) when sending SDS messages or SDS disposition notifications:

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

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

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

2) when sending FD messages, FD disposition notifications, FD media storage function discovery or access a list of deferred group communications messages:

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

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

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

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

4) shall set the Request-URI to the public service identity identifying the participating MCData function serving the MCData user.

6.2.5 Location information

6.2.5.1 Location information for location reporting

This procedure is initiated by the MCData client when it is including location report information:

1) as part of a SIP request for a specified location trigger;

2) as part of a SIP request containing an MCData emergency alert ; or

3) as part of a SIP request unrelated to location triggers or emergency situations (for example, responding to a location information request).

Editor’s Note: [eMCData3, CR 0291R1, C1-221908] Text in this spec where location information is included for reporting may need to be reviewed/revised/updated to functionally harmonize with text in this procedure or, possibly, to reference this procedure directly.

The MCData client:

1) shall include, unless already present, an application/vnd.3gpp.location-info+xml MIME body as specified in clause D.4, with a <Report> element included in the <location-info> root element;

2) if the location information is being included because of the firing of a trigger configured in a <TriggeringCriteria> element or in an <EmergencyTriggeringCriteria> element of a <Configuration> element contained in an application/vnd.3gpp.mcdata-location-info+xml MIME body, as specified in clause D.4:

a) shall set the <ReportType> attribute to the "Emergency" value if the activated trigger was configured in the <EmergencyTriggeringCriteria>, otherwise shall set the <ReportType> attribute to the "NonEmergency" value;

b) shall include the <TriggerId> child elements, where each element is set to the value of the <Trigger-Id> attribute associated with the trigger that has fired;

c) shall include the location reporting elements corresponding to the triggers that have fired;

d) shall set the minimumReportInterval timer to the minimumReportInterval time and start the timer;

e) shall reset all triggers; and

f) shall skip the rest of the steps of this procedure;

3) if the location information is being included to enable processing for an emergency related situation (such as an emergency alert, emergency group communication or emergency one-to-one communication):

a) hall set the <ReportType> attribute to the "Emergency" value;

b) shall populate the <CurrentLocation> element of the <Report> element to contain values for the <longitude>, <latitude>, <CurrentServingEcgi> and <locTimestamp> elements, as well as other not already included elements indicated by the <EmergencyLocationInformation> element, if present in the <Configuration> element contained in an application/vnd.3gpp.mcdata-location-info+xml MIME body, per clause D.4; and

c) shall skip the rest of the steps of this procedure; and

4) if the location information is being included as a result of a location information request:

a) shall set the <ReportType> attribute to the "NonEmergency" value;

b) shall include the <ReportID> attribute set to the value of the <RequestID> attribute in the received location request; and

c) shall populate the <CurrentLocation> element of the <Report> element containing at least a <CurrentCoordinate> element.

6.2.6 Void

6.2.7 Handling of in-progress emergency and imminent peril conditions

6.2.7.1 MCData upgrade to in-progress emergency or in-progress imminent peril

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

Upon receiving a request from an MCData user to upgrade the MCData group session to either an emergency condition or an imminent peril condition on an MCData prearranged group, the MCData client shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [5], with the clarifications given below:

1) if the MCData user is requesting to upgrade the MCData group session to an in-progress emergency group state and this is an unauthorised request for an MCData emergency communication as determined by the procedures of clause 6.2.8.1.8, the MCData client:

a) should indicate to the MCData user that they are not authorised to upgrade the MCData group session to an in-progress emergency group state; and

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

2) if the MCData user is requesting to upgrade the MCData group session to an in-progress imminent peril state and this is an unauthorised request for an MCData imminent peril group communication as determined by the procedures of clause 6.2.8.1.8, the MCData client:

a) should indicate to the MCData user that they are not authorised to upgrade the MCData group session to an in-progress imminent peril group state; and

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

3) if the MCData user has requested to upgrade the MCData group session to an MCData emergency communication, the MCData client:

a) shall include an application/vnd.3gpp.mcdata-info+xml MIME body by following the procedures in clause 6.2.8.1.1; and

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

4) if the MCData user has requested to upgrade the MCData group session to an MCData imminent peril communication, the MCData client:

a) shall include an application/vnd.3gpp.mcdata-info+xml MIME body by following the procedures in clause 6.2.8.1.9; and

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

5) if the SIP re-INVITE request is to be sent within an on-demand session, shall include in the SIP re-INVITE request an SDP offer according to 3GPP TS 24.229 [5] with the clarifications specified in clause 9.2.4.2.1 (for SDS session), or 10.2.5.2.1 (for FD using media plane), as appropriate;

6) if the SIP re-INVITE request is to be sent within a pre-established session, shall include an SDP offer in the SIP re-INVITE request according to 3GPP TS 24.229 [5], based upon the parameters already negotiated for the pre-established session;

NOTE: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session. If the SIP re-INVITE request is sent within a pre-established session, the SDP offer for the media parameters is expected to be the same as was negotiated in the existing pre-established session.

7) shall include an application/vnd.3gpp.mcdata-location-info+xml MIME body with a <Report> element included in the <location-info> root element (see clause D.4) and include in the <Report> element the specific location information configured for the MCData emergency alert location trigger; and

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

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

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

2) shall perform the actions specified in clause 6.2.8.1.4.

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

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

6.2.7.2 MCData in-progress emergency cancel

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

Upon receiving a request from an MCData user to cancel the in-progress emergency condition on a prearranged MCData group, the MCData client shall generate a SIP re-INVITE request while in an ongoing prearranged group communication by following the UE originating session procedures specified in 3GPP TS 24.229 [5], with the clarifications given below, otherwise generate a SIP MESSAGE request by following client procedure of clause 16.2.1.4 of present document.

The MCData client:

1) if the MCData user is not authorised to cancel the in-progress emergency group state of the MCData group as determined by the procedures of clause 6.2.8.1.7, the MCData client:

a) should indicate to the MCData user that they are not authorised to cancel the in-progress emergency group state of the MCData group; and

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

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

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

4) shall include in the application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element:

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

b) the <mcdata-request-uri> element set to the group identity;

NOTE 1: The MCData ID of the originating MCData user is not included in the body, as this will be inserted into the body of the SIP INVITE request that is sent by the originating participating MCData function.

5) shall include the g.3gpp.mcdata media feature tag in the Contact header field of the SIP re-INVITE request according to IETF RFC 3840 [16];

6) if the SIP re-INVITE request is to be sent within an on-demand session, shall include in the SIP re-INVITE request an SDP offer according to 3GPP TS 24.229 [5] with the clarifications specified in clause 9.2.4.2.1 (for SDS session), or 10.2.5.2.1 (for FD using media plane), as appropriate;

7) if the SIP re-INVITE request is to be sent within a pre-established session, shall include an SDP offer in the SIP re-INVITE request according to 3GPP TS 24.229 [5], based upon the parameters already negotiated for the pre-established session;

NOTE 2: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session. If the SIP re-INVITE request is sent within a pre-established session, the SDP offer for the media parameters is expected to be the same as was negotiated in the existing pre-established session.

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

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

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

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

2) shall set the MCData emergency group state of the group to "MDEG 1: no-emergency";

3) shall set the MCData emergency group communication state of the group to "MDEGC 1: emergency-gc-capable"; and

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

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

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

1) shall set the MCData emergency group state as "MDEG 2: in-progress";

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

3) if the SIP 4xx response, SIP 5xx response or SIP 6xx response did not contain an application/vnd.3gpp.mcdata-info+xml MIME body with an <alert-ind> element and did not contain an <originated-by> element, the MCData emergency alert (MDEA) state shall revert to its value prior to entering the current procedure.

NOTE 3: If the in-progress emergency group state cancel request is rejected, the state of the session does not change, i.e. continues with MCData emergency group communication level priority.

6.2.7.3 MCData in-progress imminent peril cancel

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

Upon receiving a request from an MCData user to cancel the in-progress imminent peril condition on a prearranged MCData group, the MCData client shall generate a SIP re-INVITE request by following the procedures specified in 3GPP TS 24.229 [5], with the clarifications given below:

The MCData client:

1) if the MCData user is not authorised to cancel the in-progress imminent peril group state of the MCData group as determined by the procedures of clause 6.2.8.1.10, the MCData client:

a) should indicate to the MCData user that they are not authorised to cancel the in-progress imminent peril group state of the MCData group; and

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

2) shall include an application/vnd.3gpp.mcdata-info+xml MIME body populated as specified in clause 6.2.8.1.11;

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

4) shall include in the application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element:

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

b) the <mcdata-request-uri> element set to the group identity;

NOTE 1: The MCData ID of the originating MCData user is not included in the body, as this will be inserted into the body of the SIP re-INVITE request that is sent by the originating participating MCData function.

5) shall include the g.3gpp.mcdata media feature tag in the Contact header field of the SIP re-INVITE request according to IETF RFC 3840 [16];

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

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

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

2) shall set the MCData imminent peril group state of the group to "MDIG 1: no-imminent-peril"; and

3) shall set the MCData imminent peril group communication state of the group to "MDIGC 1: imminent-peril-gc-capable".

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

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

a) contains an application/vnd.3gpp.mcdata-info+xml MIME body with an <imminentperil-ind> element set to a value of "true"; or

b) does not contain an application/vnd.3gpp.mcdata-info+xml MIME body with an <imminentperil-ind> element;

then the MCData client shall set the MCData imminent peril group state as "MDIG 2: in-progress".

NOTE 3: This is the case where the MCData client requested the cancellation of the MCData imminent peril in-progress state and was rejected.

6.2.7.4 MCData client receives SIP re-INVITE request

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

Upon receipt of a SIP re-INVITE request, the MCData client:

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

a) should display to the MCData user the MCData ID of the originator of the MCData emergency group communication and an indication that this is an MCData emergency group communication;

b) if the <mcdatainfo> element containing the <mcdata-Params> element contains an <alert-ind> element set to "true", should display to the MCData user an indication of the MCData emergency alert and associated information;

c) shall set the MCData emergency group state to "MDEG 2: in-progress";

d) shall set the MCData imminent peril group state to "MDIG 1: no-imminent-peril"; and

e) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-gc-capable";

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

a) should display to the MCData user the MCData ID of the originator of the MCData imminent peril group communication and an indication that this is an MCData imminent peril group communication; and

b) shall set the MCData imminent peril group state to "MDIG 2: in-progress";

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

a) should display to the MCData user the MCData ID of the MCData user cancelling the MCData emergency group communication;

b) if the <mcdatainfo> element containing the <mcdata-Params> element contains an <alert-ind> element set to "false":

i) should display to the MCData user an indication of the MCData emergency alert cancellation and the MCData ID of the MCData user cancelling the MCData emergency alert; and

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

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

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

c) shall set the MCData emergency group state to "MDEG 1: no-emergency"; and

d) if the MCData emergency group communication state of the group is set to "MDEGC 3: emergency-communication-granted", shall set the MCData emergency group communication state of the group to "MDEGC 1: emergency-gc-capable";

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

a) should display to the MCData user the MCData ID of the MCData user cancelling the MCData imminent peril group communication and an indication that this is an MCData imminent peril group communication;

b) shall set the MCData imminent peril group state to "MDIG 1: no-imminent-peril"; and

c) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-gc-capable";

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

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

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

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

9) if the SIP re-INVITE request was received within an on-demand session, shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP re-INVITE request according to 3GPP TS 24.229 [5] with the clarifications given in clause 9.2.4.2.2 (for SDS session), or 10.2.5.2.2 (for FD using media plane), as appropriate;

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

NOTE: The SIP re-INVITE request can be received within an on-demand session or a pre-established session. If the SIP re-INVITE request is sent within a pre-established session, the SDP offer for the media parameters is expected to be the same as was negotiated in the existing pre-established session.

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

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

6.2.7.5 MCData group in-progress emergency group state cancel

Upon receiving a request from an MCData user to cancel the in-progress emergency condition on a MCData group on which there is no communication ongoing, the MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

NOTE 1: This SIP MESSAGE request is assumed to be sent out-of-dialog.

The MCData client:

1) if the MCData user is not authorised to cancel the in-progress emergency group state of the MCData group as determined by the procedures of clause 6.2.8.1.7, the MCData client:

a) should indicate to the MCData user that they are not authorised to cancel the in-progress emergency group state of the MCData group; and

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

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

3) 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.mcdata" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

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

5) shall include an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with:

a) the <mcdata-request-uri> element set to the MCData group identity; and

b) the <emergency-ind> element set to a value of "false";

6) if the MCData user has additionally requested the cancellation of an MCData emergency alert originated by MCData user, shall include an <alert-ind> element set to a value of "false" in the <mcdatainfo> element containing the <mcdata-Params> element;

7) shall set the Request-URI to the public service identity identifying the participating MCData function serving the group identity;

8) if the generated SIP MESSAGE request contains an <alert -ind> element in the application/vnd.3gpp.mcdata-info+xml MIME body, shall set the MCData emergency alert state to "MDEA 4: Emergency-alert-cancel-pending"; and

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

On receipt of a SIP MESSAGE request containing an application/vnd.3gpp.mcdata-info+xml MIME body with an <emergency-ind-rcvd> element set to a value of "true" and an <mcdata-client-id> matching the MCData client ID included in the sent SIP MESSAGE request:

1) if an <emergency-ind> element is present in the application/vnd.3gpp.mcdata-info+xml MIME body of received SIP MESSAGE request and is set to a value of "false":

a) shall set the MCData emergency group state of the group to "MDEG 1: no-emergency".

NOTE 3: The case where an <emergency-ind> element is set to true is possible but not handled specifically above as it results in no state changes.

2) if the <alert-ind> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the received SIP MESSAGE request is set to a value of "true" and if the MCData emergency alert state is set to "MDEA 4: emergency-alert-cancel-pending" and the sent SIP MESSAGE request contained an <alert-ind> element set to value "false" in the application/vnd.3gpp.mcdata-info+xml MIME body, shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated"; and

NOTE 4: It would appear to be an unusual situation for the initiator of an MCData emergency alert to not be able to clear their own alert. Nevertheless, an MCData user can be configured to be authorised to initiate MCData emergency alerts but not have the authority to clear them. Hence, the case is covered here.

3) if the <alert-ind> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the received SIP MESSAGE request is set to a value of "false" and if the MCData emergency alert state is set to "MDEA 4: emergency-alert-cancel-pending" and the sent SIP MESSAGE request contained an <alert-ind> element set to value "false" in the application/vnd.3gpp.mcdata-info+xml MIME body, shall:

a) set the MCData emergency alert state to "MDEA 1: no-alert"; and

b) clear the MCData emergency state if not already cleared.

On receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to the sent SIP MESSAGE request, the MCData client:

1) if the received SIP 4xx response, SIP 5xx response or SIP 6xx response contains an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with the <alert-ind> element set to a value of "true" and the sent SIP MESSAGE request contained an <alert-ind> element set to value "false" in the application/vnd.3gpp.mcdata-info+xml MIME body and the MCData emergency alert state is set to "MDEA 4: emergency-alert-cancel-pending", shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated".

NOTE 5: In this case, <emergency-ind> element is set to true is possible but not handled specifically above as it results in no state changes.

6.2.8 Priority communication conditions

6.2.8.1 MCData emergency group communication and imminent peril communication conditions

6.2.8.1.1 SIP INVITE request or SIP REFER request for originating MCData emergency group communications

This clause is referenced from other procedures.

When the MCData emergency state is set and the MCData user is authorised to initiate an MCData emergency group communication on the targeted MCData group as determined by the procedures of clause 6.2.8.1.8, the MCData client:

1) shall include in the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP INVITE request or SIP REFER request, an <emergency-ind> element set to "true";

2) if the MCData emergency group communication state is set to "MDEGC 1: emergency-gc-capable", shall set the MCData emergency group communication state to "MDEGC 2: emergency-communication-requested";

3) if the MCData user has also requested an MCData emergency alert to be sent and this is an authorised request for MCData emergency alert as determined by the procedures of clause 6.2.8.1.6, and the MCData emergency alert state is set to "MDEA 1: no-alert", shall:

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

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

4) if the MCData user has not requested an MCData emergency alert to be sent and the MCData emergency alert state is set to "MDEA 1: no-alert", shall set the <alert-ind> element of the application/vnd.3gpp.mcdata-info+xml MIME body to "false"; and

5) if the MCData client emergency group state of the group is set to a value other than "MDEG 2: in-progress", set the MCData client emergency group state of the MCData group to "MDEG 4: confirm-pending".

NOTE 1: This is the case of an MCData user already being in the MCData emergency state it initiated previously while originating an MCData emergency group communication or MCData emergency alert. All group communications the MCData user originates while in MCData emergency state will be MCData emergency group communications.

When the MCData emergency state is clear and the MCData emergency group communication state is set to "MDEGC 1: emergency-gc-capable" and the the MCData user is authorised to initiate an MCData emergency group communication on the targetted MCData group as determined by the procedures of clause 6.2.8.1.8, the MCData client:

1) shall set the MCData emergency state;

2) shall include in the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP INVITE request or SIP REFER request an <emergency-ind> element set to "true" and set the MCData emergency group communication state to "MDEGC 2: emergency-communication-requested" state;

3) if the MCData user has also requested an MCData emergency alert to be sent and this is an authorised request for MCData emergency alert as determined by the procedures of clause 6.2.8.1.6, shall:

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

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

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

5) if the MCData client emergency group state of the group is set to a value other than "MDEG 2: in-progress", shall set the MCData client emergency group state of the MCData group to "MDEG 4: confirm-pending".

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

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

6.2.8.1.2 Resource-Priority header field for MCData emergency group communications

This clause is referenced from other procedures.

If the MCData emergency group communication state is set to either "MDEGC 2: emergency-communication-requested" or "MDEGC 3: emergency-communication-granted" and this is an authorised request for an MCData emergency group communication as determined by the procedures of clause 6.2.8.1.8, or the MCData client emergency group state of the group is set to "MDEG 2: in-progress", the MCData client shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for an MCData emergency group communication as specified in clause 6.2.8.1.15.

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

If this is an authorised request to cancel the MCData emergency group communication as determined by the procedures of clause 6.2.8.1.7, and the MCData client emergency group state of the group is "no-emergency" or "cancel-pending", the MCData client shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for a normal MCData group communication as specified in clause 6.2.8.1.15.

6.2.8.1.3 SIP re-INVITE request for cancelling MCData in-progress emergency group state

This clause is referenced from other procedures.

If the MCData emergency group communication state is set to "MDEGC 3: emergency-communication-granted" and the MCData emergency alert state is set to "MDEA 1: no-alert", the MCData client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5] with the clarifications given below.

NOTE 1: This procedure assumes that the calling procedure has verified that the MCData user has made an authorised request for cancelling MCData in-progress emergency group state of the group.

The MCData client:

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

2) shall clear the MCData emergency state; and

3) shall set MCData emergency group state of the MCData group to "MDEG 3: cancel-pending"

NOTE 2: This is the case of an MCData user who has initiated an MCData emergency group communication and wants to cancel it.

If the MCData emergency group communication state is set to "MDEGC 3: emergency-communication-granted" and the MCData emergency alert state is set to a value other than "MDEA 1: no-alert" and the MCData user has indicated only the MCData emergency group communication should be cancelled, the MCData client:

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

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

NOTE 3: This is the case of an MCData user has initiated both an MCData emergency group communication and an MCData emergency alert and wishes to only cancel the MCData emergency group communication. This leaves the MCData emergency state set.

If the MCData emergency group communication state is set to "MDEGC 3: emergency-communication-granted" and the MCData emergency alert state is set to a value other than "MDEA 1: no-alert" and the MCData user has indicated that the MCData emergency alert on the MCData group should be cancelled in addition to the MCData emergency group communication, the MCData client:

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

2) if this is an authorised request to cancel an MCData emergency alert as determined by the procedures of clause 6.2.8.1.6, shall:

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

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

c) clear the MCData emergency state;

3) should, if this is not an authorised request to cancel an MCData emergency alert as determined by the procedures of clause 6.2.8.1.6, indicate to the MCData user that they are not authorised to cancel the MCData emergency alert; and

4) shall set the MCData emergency group state of the MCData group to "MDEG 3: cancel-pending".

NOTE 4: This is the case of an MCData user that has initiated both an MCData emergency group communication and an MCData emergency alert and wishes to cancel both.

6.2.8.1.4 Receiving a SIP 2xx response to a SIP request for a priority communication

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

On receiving a SIP 2xx response to a SIP request for a priority group communication, the MCData client:

1) if the MCData emergency group communication state is set to "MDEGC 2: emergency-communication-requested" or "MDEGC 3: emergency-communication-granted":

a) shall set the MCData client emergency group state of the group to "MDEG 2: in-progress";

b) if the MCData emergency alert state is set to "MDEA 2: emergency-alert-confirm-pending" and the SIP 2xx response to the SIP request for a priority group communication does not contain a Warning header field as specified in clause 4.9 with the warning text containing the mcdata-warn-code set to "149", shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated";

c) shall set the MCData emergency group communication state to "MDEGC 3: emergency-communication-granted"; and

d) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-capable" and the MCData imminent peril group state to "MDIG 1: no-imminent-peril"; or

2) if the MCData imminent peril group communication state is set to "MDIGC 2: imminent-peril-communication-requested" or "MDIGC 3: imminent-peril-communication-granted" and the SIP 2xx response to the SIP request for an imminent peril group communication does not contain a Warning header field as specified in clause 4.9, with the warning text containing the mcdata-warn-code set to "149":

a) set the MCData imminent peril group communication state to "MDIGC 3: imminent-peril-communication-granted"; and

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

6.2.8.1.5 Receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to a SIP request for a priority group communication

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

Upon receiving a SIP 4xx response, a SIP 5xx response or a SIP 6xx response to a SIP request for a priority group communication the MCData client:

1) if the MCData emergency group communication state is set to "MDEGC 2: emergency-communication-requested" or "MDEGC 3: emergency-communication-granted":

a) shall set the MCData emergency group communication state to "MDEGC 1: emergency-gc-capable";

b) if the MCData client emergency group state of the group is "MDEG 4: confirm-pending", shall set the MCData client emergency group state of the group to "MDEG 1: no-emergency"; and

c) if the sent SIP request for a priority group communication contained an application/vnd.3gpp.mcdata-info+xml MIME body with an <alert-ind> element set to a value of "true", shall set the MCData emergency alert state to "MDEA 1: "no-alert"; and

2) if the MCData imminent peril group communication state is set to "MDIGC 2: imminent-peril-communication-requested" or "MDIGC 3: imminent-peril-communication-granted":

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

b) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-gc-capable".

6.2.8.1.6 Determining authorisation for initiating or cancelling an MCData emergency alert

If the MCData client receives a request from the MCData user to send an MCData emergency alert and:

1) if the <allow-activate-emergency-alert> element of the <actions> element of a <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID of the calling MCData user (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "true" and the group document (see 3GPP TS 24.481 [11]) of the MCData group indicated by the MCData user does not contain a <list-service> element that contains a <preconfigured-group-use-only> element set to the value "true"; and

2) if the "entry-info" attribute of the <entry> element of the <GroupEmergencyAlert> element contained within the <Common> element of the <mcdata-user-profile> element within MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of:

a) "DedicatedGroup", and if the <uri-entry> element of the <entry> element of the <GroupEmergencyAlert> element of the <Common> element of the <mcdata-user-profile> element within MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) contains the MCData group identity of the MCData group targeted by the calling MCData user; or

b) "UseCurrentlySelectedGroup" and the <mcdata-allow-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 MCData group identity targeted for the emergency alert is set to a value of "true" as specified in 3GPP TS 24.481 [11];

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

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

6.2.8.1.7 Determining authorisation for cancelling the in-progress emergency state of an MCData group

When the MCData client receives a request from the MCData user to cancel the in-progress emergency state of a group, the MCData client determines, based on local policy (e.g., if the requester is dispatcher or initiator of the MCData emergency group communication, etc.), whether to send the emergency group state cancel request or not.

6.2.8.1.8 Determining authorisation for originating a priority group communication

When the MCData client receives a request from the MCData user to originate an MCData emergency group communication the MCData client shall check the following:

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

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

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

then the MCData emergency group communication request shall be considered to be an authorised request for an MCData emergency group communication only for SDS session, SDS pre-established session or FD using media plane.

Editor’s note: The restriction stated above, to limit the authorization for emergency group communications and/or imminent peril group communication only to certain types of MCData services is FFS.

In all other cases, the request to originate an MCData emergency group communication shall be considered to be an unauthorised request to originate an MCData emergency group communication.

When the MCData client receives a request from the MCData user to originate an MCData imminent peril group communication the MCData client shall check the following:

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

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

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

then the MCData imminent peril group communication request shall be considered to be an authorised request for an MCData imminent peril group communication only for SDS session, SDS pre-established session or FD using media plane.

Editor’s note: The restriction stated above, to limit the authorization for emergency group communications and/or imminent peril group communication only to certain types of MCData services is FFS.

In all other cases, the request to originate an MCData imminent peril group communication shall be considered to be an unauthorised request to originate an MCData imminent peril group communication.

6.2.8.1.9 SIP request for originating MCData imminent peril group communications

This clause is referenced from other procedures.

When the MCData client receives a request from the MCData user to originate an MCData imminent peril group communication, and this is an authorised request for an MCData imminent peril group communication as determined by the procedures of clause 6.2.8.1.8, the MCData client:

1) if the MCData client imminent peril group state is set to "MDIGC 1: imminent-peril-gc-capable" and the in-progress emergency state of the group is set to a value of "false":

a) shall include in the SIP request an application/vnd.3gpp.mcdata-info+xml MIME body as defined in Annex D.1 with the <imminentperil-ind> element set to "true" and set the MCData emergency group communication state to "MDIGC 2: imminent-peril-call-requested" state; and

b) if the MCData client imminent peril group state of the group is set to a value other than "MDIG 2: in-progress" shall set the MCData client emergency group state of the MCData group to "MDIG 4: confirm-pending".

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

6.2.8.1.10 Determining authorisation for cancelling an imminent peril group communication

When the MCData client receives a request from the MCData user to cancel an MCData imminent peril group communication the MCData client shall:

1) if the <allow-cancel-imminent-peril> element of the <actions> element of a <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID of the calling user (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "true" the MCData imminent peril communication cancellation request shall be considered to be an authorised request to cancel the MCData imminent peril group communication; or

2) if the <allow-cancel-imminent-peril> element of the <actions> element of a <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID of the calling user (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "false" the MCData imminent peril communication cancellation request shall be considered to be an unauthorised request to cancel the MCData imminent peril group communication.

6.2.8.1.11 SIP re-INVITE request for cancelling MCData in-progress imminent peril group state

This clause is referenced from other procedures.

If the MCData imminent peril group communication state is set to "MDIGC 3: imminent-peril-call-granted" or the MCData imminent peril group state of the MCData group is set to "MDIG 2: in-progress", the MCData client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5] with the clarifications given below.

NOTE 1: This procedure assumes that the calling procedure has verified that the MCData user has made an authorised request for cancelling the in-progress imminent peril group state of the group.

The MCData client:

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

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

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

6.2.8.1.12 Resource-Priority header field for MCData imminent peril group communications

This clause is referenced from other procedures.

When the MCData imminent peril group communication state is set to "MDIGC 2: imminent-peril-call-requested" or "MDIGC 3: imminent-peril-call-granted" and the MCData user is authorised to initiate an MCData imminent peril group communication on the targeted MCData group as determined by the procedures of clause 6.2.8.1.8, or the MCData client imminent peril state of the group is set to "MDIG 2: in-progress", the MCData client:

1) shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for an MCData imminent peril group communication as specified in clause 6.2.8.1.15.

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

When the MCData imminent peril group communication state is set to "MDIGC 1: imminent-peril-gc-capable" and the MCData user is authorised to cancel MCData imminent peril group communications as determined by the procedures of clause 6.2.8.1.10, or the MCData client imminent peril group state of the group is "MDIG 1: no-imminent-peril" or "MDIG 3: cancel-pending", the MCData client:

1) shall include in the SIP INVITE request or SIP REFER request a Resource-Priority header field populated with the values for a normal MCData group communication as specified in clause 6.2.8.1.15.

6.2.8.1.13 Receiving a SIP INFO request in the dialog of a SIP request for a priority group communication

This clause is referenced from other procedures.

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

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

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

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

the MCData client:

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

2) if the MCData emergency group communication state is set to "MDEGC 3: emergency-call-granted":

a) if the MCData emergency alert state is set to "MDEA 2: emergency-alert-confirm-pending":

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

ii) if the <alert-ind> element is set to a value of "true", shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated";

3) if the MCData imminent peril group communication state is set to "MDIGC 2: imminent-peril-call-requested" or "MDIGC 3: imminent-peril-call-granted":

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

i) set the MCData imminent peril group state to "MDIG 1: no-imminent-peril";

ii) set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-capable"; and

iii) set the MCData client emergency group state of the group to "MDEG 2: in-progress"; and

NOTE 1: This is the case of an MCData client attempting to make an imminent peril group communication when the group is in an in-progress emergency group state. The MCData client will then receive a notification that the imminent peril communication request was denied, however they will be participating at the emergency level priority of the group. This could occur for example when an MCData client requests an imminent peril communication to a group that they are not currently affiliated with.

NOTE 2: the MCData client emergency group state above is the MCData client’s view of the in-progress emergency state of the group.

4) if the SIP request for a priority group communication sent by the MCData client did not contain an <originated-by> element and if the MCData emergency alert state is set to "MDEA 4: Emergency-alert-cancel-pending":

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

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

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

This clause is referenced from other procedures.

Upon receiving an authorised request to cancel an in-progress emergency group state of a group as determined by the procedures of clause 6.2.8.1.7 from an MCData user, the MCData client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5] with the clarifications given below.

The MCData client:

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

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

3) if the MCData user has indicated that an MCData emergency alert on the MCData group originated by another MCData user should be cancelled and this is an authorised request for an MCData emergency alert cancellation as determined by the procedures of clause 6.2.8.1.6:

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

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

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

6.2.8.1.15 Retrieving Resource-Priority header field values

This clause is referenced from other procedures.

When determining the Resource-Priority header field MCPTT namespace and priority values as specified in IETF RFC 8101 [67] to be applied to an MCData emergency group communication or an MCData emergency private (one-to-one) communication, the MCData client:

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

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

When determining the Resource-Priority header field MCPTT namespace and priority values as specified in IETF RFC 8101 [67] to be applied to an MCData imminent peril group communication, the MCData client:

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

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

When determining the Resource-Priority header field MCPTT namespace and priority values as specified in IETF RFC 8101 [67] to be applied to a normal MCData group or private (one-to-one) communication, the MCData client:

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

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

NOTE: The "normal" Resource-Priority header field value is needed to return to a normal priority value from a priority value adjusted for an MCData emergency group or private (one-to-one) communication or an MCData imminent peril group communication. 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 communication with no Resource-Priority header field included.

6.2.8.1.16 Handling receipt of a SIP re-INVITE request for priority group communication origination status within a pre-established session

This clause is referenced from other procedures.

Upon receipt of a SIP re-INVITE request within the pre-established session targeted by the sent SIP REFER request, and if the sent SIP REFER request was a request for an MCData emergency group communication or an MCData imminent peril group communication, the MCData client:

1) if the MCData emergency group communication state is set to "MDEGC 2: emergency-call-requested":

a) if there is no <emergency-ind> element or an <emergency-ind> element set to a value of "true" contained in the application/vnd.3gpp.mcdata-info+xml MIME body received in the SIP re-INVITE request, and if no <imminentperil-ind> element is included:

i) shall set the MCData client emergency group state of the group to "MDEG 2: in-progress" if it was not already set; and

ii) shall set the MCData emergency group communication state to "MDEGC 3: emergency-call-granted"; and

b) if the MCData emergency alert state is set to "MDEA 2: emergency-alert-confirm-pending":

i) if the SIP re-INVITE request contains an <alert-ind> element set to a value of "true" or does not contain an <alert-ind> element, shall set the MCData emergency alert state to "MDEA 3: emergency-alert-initiated"; or

ii) if the SIP re-INVITE request contains an <alert-ind> element set to a value of "false", shall set the MCData emergency alert state to "MDEA 1: no-alert"; and

2) if the MCData imminent peril group communication state is set to "MDIGC 2: imminent-peril-call-requested:

a) if the sip re-INVITE request contains an <imminentperil-ind> element set to a value of "true" or does not contain an <imminentperil-ind> element, shall:

i) set the MCData imminent peril group communication state to "MDIGC 3: imminent-peril-call-granted"; and

ii) set the MCData imminent peril group state to "MDIG 2: in-progress"; or

b) if the SIP re-INVITE request contains <imminentperil-ind> element set to a value of "false" and an <emergency-ind> element set to a value of "true", shall set the MCData client emergency group state of the group to "MDEG 2: in-progress".

NOTE: This is the case of an MCData client attempting to make an imminent peril group communication when the group is in an in-progress emergency group state. The MCData client will then receive a notification that the imminent peril communication request was denied, however they will be participating at the emergency level priority of the group. This could occur, for example, when an MCData client requests an imminent peril communication to a group that they are not currently affiliated with.

6.2.8.1.17 Priority group communication conditions upon receiving communication release

This clause is referenced from other procedures.

Upon receiving a request to release the MCData emergency group communication or an MCData imminent peril group communication in an MCData group session is in-progress or is in the process of being established:

1) if the MCData emergency group communication state is set to "MDEGC 2: emergency-call-requested":

a) shall set the MCData emergency group communication state to "MDEGC 1: emergency-gc-capable";

b) if the MCData client emergency group state of the group is "MDEG 3: confirm-pending" shall set the MCData client emergency group state of the group to "MDEG 1: no-emergency"; and

c) if the MCData emergency alert state is set to "MDEA 2: emergency-alert-confirm-pending" shall set the MCData emergency alert state to "MDEA 1: "no-alert"; and

2) if the MCData imminent peril group communication state is set to "MDIGC 2: imminent-peril-call-requested":

a) if the MCData imminent peril group communication state of the group is "MDIG 4: confirm-pending", shall set the MCData imminent peril group state to "MDIG 1: no-imminent-peril"; and

b) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-capable".

6.2.8.1.18 Emergency private (one-to-one) communication conditions upon receiving communication release

This clause is referenced from other procedures.

Upon receiving a request to release the MCData session when an MCData emergency private communication is in-progress or is in the process of being established:

1) if the MCData emergency private communication state is set to "MDEPC 2: emergency-call-requested":

a) shall set the MCData emergency private communication state to "MDEPC 1: emergency-pc-capable";

b) if the MCData emergency private priority state of the private communication is "MDEPP 3: confirm-pending" shall set the MCData emergency private priority state of the private communication to "MDEPP 1: no-emergency"; and

c) if the MCData private emergency alert state is set to "MDPEA 2: emergency-alert-confirm-pending shall set the MCData private emergency alert state to "MDPEA 1: no-alert".

6.2.8.2 Void

6.2.8.3 MCData emergency private (one-to-one) communication conditions

6.2.8.3.1 Authorisations

6.2.8.3.1.1 Determining authorisation for initiating an MCData emergency private communication

If the MCData client receives a request from the MCData user to originate an MCData emergency private communication and:

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

a) if the "entry-info" attribute of the <entry> element of the <MCDataPrivateRecipient> element of the <EmergencyCall> element contained within the <One‑to‑One‑Communication> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "UsePreConfigured" and if the <uri-entry> element of the <entry> element of the <MCDataPrivateRecipient> element contains the MCData ID of the MCData user targeted by the calling MCData user; or

b) if the "entry-info" attribute of the <entry> element of the <MCDataPrivateRecipient> element of the <EmergencyCall> element contained within the <One‑to‑One‑Communication> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "LocallyDetermined";

then the MCData client shall consider the MCData emergency private communication request to be an authorised request for an MCData emergency private communication. In all other cases the MCData client shall consider the MCData emergency private communication request to be an unauthorised request for an MCData emergency private communication.

6.2.8.3.1.2 Determining authorisation for cancelling an MCData emergency private communication

If the MCData client receives a request from the MCData user to cancel an MCData emergency private communication and if the <allow-cancel-private-emergency-call> element of the <actions> element of a <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID of the calling user (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "true", then the MCData emergency private communication cancellation request shall be considered to be an authorised request for an MCData emergency private communication cancellation.

In all other cases, the MCData emergency private communication cancellation request shall be considered to be an unauthorised request for an MCData emergency private communication cancellation.

6.2.8.3.1.3 Determining authorisation for initiating or cancelling an MCData emergency alert to a MCData user

If the MCData client receives a request from the MCData user to send an MCData emergency alert to an MCData user and:

2) if the "entry-info" attribute of the <entry> element of the <One‑to‑One‑EmergencyAlert> element contained within the <OnNetwork> element of the <mcdata-user-profile> element within the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of:

a) "UsePreConfigured", and if the <uri-entry> element of the <entry> element of the <One‑to‑One‑EmergencyAlert> element of the <OnNetwork> element of the <mcdata-user-profile> element within the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) contains the MCData ID of the targeted MCData user; or

b) "LocallyDetermined";

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

6.2.8.3.2 SIP request for originating MCData emergency private communications

This clause is referenced from other procedures.

When the MCData emergency private communication state is set to "MDEPC 1: emergency-pc-capable" and this is an authorised request for an MCData emergency private communication, as determined by the procedures of clause 6.2.8.3.1.1, the MCData client:

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

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

3) if the MCData user has also requested an MCData emergency alert to be sent and this is an authorised request for MCData emergency alert, as determined by the procedures of clause 6.2.8.3.1.3, shall:

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

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

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

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

6.2.8.3.3 Resource-Priority header field for MCData emergency private communications

This clause is referenced from other procedures.

If the MCData emergency private communication state is set to either "MDEPC 2: emergency-pc-requested" or "MDEPC 3: emergency-pc-granted" and this is an authorised request for an MCData emergency private communication as determined by the procedures of clause 6.2.8.3.1.1, or the MCData emergency private priority state of the communication is set to "MDEPP 2: in-progress", the MCData client shall include in the SIP request a Resource-Priority header field populated with the values for an MCData emergency private communication as specified in clause 6.2.8.1.15.

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

If this is an authorised request to cancel the MCData emergency private communication as determined by the procedures of clause 6.2.8.3.1.2, or the MCData emergency private priority state of the private communication is "MDEPP 1: no-emergency" or "MDEPP 3: cancel-pending", the MCData client shall include in the SIP request a Resource-Priority header field populated with the values for a normal MCData private communication as specified in clause 6.2.8.1.15.

6.2.8.3.4 Receiving a SIP 2xx response to a SIP request for an MCData emergency private communication

This clause is referenced from other procedures.

On receiving a SIP 2xx response to a SIP request for an MCData emergency private communication, and, if the MCData emergency private communication state is set to "MDEPC 2: emergency-pc-requested" or "MDEPC 3: emergency-pc-granted", the MCData client:

1) shall set the MCData emergency private priority state of the communication to "MDEPP 2: in-progress" if it was not already set;

2) shall set the MCData emergency private communication state to "MDEPC 3: emergency-pc-granted"; and

3) if the MCData private emergency alert state is set to "MDPEA 2: emergency-alert-confirm-pending" and the SIP 2xx response to the SIP request for a priority private communication does not contain a Warning header field as specified in clause 4.9 with the warning text containing the mcdata-warn-code set to "149", shall set the MCData private emergency alert state to "MDPEA 3: emergency-alert-initiated".

6.2.8.3.5 Receiving a SIP 4xx response, SIP 5xx response or SIP 6xx response to a SIP request for an MCData emergency private communication

Upon receiving a SIP 4xx response, SIP 5xx response or a SIP 6xx response to a SIP request for an MCData emergency private communication, and, if the MCData emergency private communication state is set to "MDEPC 2: emergency-pc-requested" or "MDEPC 3: emergency-pc-granted", the MCData client:

1) shall set the MCData emergency private communication state to "MDEPC 1: emergency-pc-capable";

2) if the MCData emergency private priority state of the private communication is "MDEPP 3: confirm-pending" shall set the MCData emergency private priority state of the private communication to "MDEPP 1: no-emergency"; and

3) if the sent SIP request for an MCData emergency private communication contained an application/vnd.3gpp.mcdata-info+xml MIME body with an <alert-ind> element set to a value of "true", shall set the MCData private emergency alert state to "MDPEA 1: no-alert".

6.2.8.3.6 SIP re-INVITE request for cancelling MCData emergency private communication state

This clause is referenced from other procedures.

When the MCData emergency private communication state is set to "MDEPC 3: emergency-pc-granted" and the MCData emergency alert state is set to "MDPEA 1: no-alert", the MCData client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5] with the clarifications given below.

NOTE 1: This procedure assumes that the MCData client in the calling procedure has verified that the MCData user has made an authorised request for cancelling MCData the in-progress emergency private communication state of the communication.

The MCData client:

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

2) shall clear the MCData emergency state; and

3) shall set MCData emergency private priority state of the MCData emergency private communication to "MDEPP 3: cancel-pending".

NOTE 2: This is the case of an MCData user who has initiated an MCData emergency private communication and wants to cancel it.

When the MCData emergency private communication state is set to "MDEPPC 3: emergency-pc-granted" and the MCData emergency alert state is set to a value other than "MDPEA 1: no-alert" and the MCData user has indicated only the MCData emergency private communication should be cancelled, the MCData client:

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

2) shall set the MCData emergency private priority state of the MCData emergency private communication to "MDEPP 3: cancel-pending";

NOTE 3: This is the case of an MCData user has initiated both an MCData emergency private communication and an MCData emergency alert and wishes to only cancel the MCData emergency private communication. This leaves the MCData emergency state set.

When the MCData emergency private communication state is set to "MDEPC 3: emergency-pc-granted" and the MCData emergency alert state is set to a value other than "MDPEA 1: no-alert" and the MCData user has indicated that the MCData emergency alert on the MCData private communication should be cancelled in addition to the MCData emergency private communication, the MCData client:

1) shall include in the SIP re-INVITE request an application/vnd.3gpp.mcdata-info+xml MIME body as defined in annex D.1 with the <emergency-ind> element set to "false";

2) shall, if this is an authorised request to cancel an MCData emergency alert as determined by the procedures of clause 6.2.8.3.1.3:

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

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

3) if this is not an authorised request to cancel an MCData emergency alert as determined by the procedures of clause 6.2.8.3.1.3, should indicate to the MCData user they are not authorised to cancel the MCData emergency alert;

4) shall set the MCData emergency private priority state of the MCData to "MDEPP 3: cancel-pending"; and

5) shall clear the MCData emergency state.

NOTE 4: This is the case of an MCData user that has initiated both an MCData emergency private communication and an MCData emergency alert and wishes to cancel both.

6.2.8.3.7 Receiving a SIP INFO request in the dialog of a SIP request for a priority private communication

This clause is referenced from other procedures.

Upon receiving a SIP INFO request within the dialog of the SIP request for a priority private communication:

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

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

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

the MCData client:

1) if the MCData private emergency alert state is set to "MDPEA 2: emergency-alert-confirm-pending":

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

b) if the <alert-ind> element set to a value of "true", shall set the MCData private emergency alert state to "MDPEA 3: emergency-alert-initiated"; and

2) if the MCData private emergency alert state is set to "MDPEA 4: Emergency-alert-cancel-pending":

a) if the <alert-ind> element is set to a value of "true", shall set the MCData private emergency alert state to "MDPEA 3: emergency-alert-initiated"; and

b) if the <alert-ind> element is set to a value of "false", shall set the MCData private emergency alert state to "MDPEA 1: no-alert".

6.2.8.3.8 SIP re-INVITE request for cancelling the MCData emergency private communication state by a third-party

This clause is referenced from other procedures.

Upon receiving a request to cancel the MCData emergency private communication state from an MCData user other than the originator of the MCData emergency private communication, the MCData client shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5], with the clarifications given below.

The MCData client:

NOTE 1: This procedure assumes that the calling procedure has verified that the MCData user has made an authorised request for cancelling the MCData emergency private communication state of the communication.

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

2) shall set the MCData emergency private priority state of the MCData emergency private communication to "MDEPP 3: cancel-pending"; and

3) if the MCData user has indicated that an MCData emergency alert associated with the MCData emergency private communication originated by another MCData user should be cancelled and this is an authorised request for an MCData emergency alert cancellation, as determined by the procedures of clause 6.2.8.3.1.3:

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

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

NOTE 2: When an MCData emergency alert is cancelled by a MCData user other than its originator, the <originated-by> element is needed to identify which MCData emergency alert is being cancelled, as conceivably each participant in the MCData emergency private communication could have originated an MCData emergency alert.

6.2.8.3.9 Retrieving a KMS URI associated with an MCData ID

If the MCData client needs to retrieve a KMS URI associated to an identified MCData ID for on network operation, the MCData client:

1) shall search for the <One‑to‑One‑CommunicationListEntry> entry of the <One‑to‑One‑Communication> element of the <Common> element of the <mcdata-user-profile> element within the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) where the <One‑to‑One‑CommunicationListEntry> entry includes a <MCData-ID> element with the <uri-entry> element containing the identified MCData ID;

a) if the <One‑to‑One‑CommunicationListEntry> entry identified by MCData ID is found and contains in the <anyExt> element a non‑empty <MCData‑ID‑KMSURI> element, shall retrieve the KMS URI contained therein; or

b) if the <One‑to‑One‑CommunicationListEntry> entry identified by MCData ID is not found or the <MCData‑ID‑KMSURI> element is empty, shall retrieve the <kms> element of the <App-Server-Info> element of the <on-network> element of the UE initial configuration document (see the UE initial configuration document in 3GPP TS 24.484 [12]) and consider that to be the KMS URI associated with the MCData ID.

If the MCData client needs to retrieve a KMS URI associated to an identified MCData ID for off network operation, the MCData client:

1) shall search for /<x>/<x>/Common/OneToOne/UserList/<x>/Entry/MCDataID leaf node containing the identified MCData ID (see the MCData user profile MO in 3GPP TS 24.483 [42]);

a) if the identified MCData ID is found:

i) shall retrieve the /<x>/<x>/Common/OneToOne/UserList/<x>/Entry/MCDataIDKMSURI leaf node (see the MCData user profile MO in 3GPP TS 24.483 [42]); and

ii) if the MCDataIDKMSURI leaf node in the same /<x>/<x>/Common/OneToOne/UserList/<x>/Entry/ interior node as the MCDataID leaf node containing the identified MCData ID is not empty, shall consider its value to be the KMS URI associated with the MCData ID; and

b) if the identified MCData ID is not found or if the /<x>/<x>/Common/OneToOne/UserList/<x>/Entry/MCDataIDKMSURI leaf node is empty:

i) shall retrieve /<x>/OnNetwork/AppServerInfo/KMS leaf node (see the MCS UE initial configuration document in 3GPP TS 24.483 [42]); and

ii) shall consider the value of the /<x>/OnNetwork/AppServerInfo/KMS leaf node to be the KMS URI associated with the MCData ID.

6.2.8.4 Procedures for modifying ongoing communications

6.2.8.4.1 Cancelling or ending ongoing client terminating procedures

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

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

2) if the values of the MDEG, MDIG or MDEPP were changed due to the processing of the received SIP INVITE, shall restore those variable to the values they held prior to the processing of the received SIP INVITE; and

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

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

1) shall release the associated allocated resources; and

2) shall send SIP 200 (OK) response towards the received SIP BYE request according to 3GPP TS 24.229 [5].

6.2.8.4.2 Client terminating procedures for handling SIP re-INVITE for an existing one-to-one communication session

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

Upon receipt of a SIP re-INVITE request for an existing one-to-one communication session, the MCData client shall:

a) should display to the MCData user an indication that this is a SIP re-INVITE request to upgrade this MCData one-to-one communication to an MCData emergency one-to-one communication, and:

i) should display the MCData ID of the originator of the MCData emergency one-to-one communication contained in the <mcdata-calling-user-id> element of the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body; and

ii) if the <alert-ind> element of the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body is set to "true", should display to the MCData user an indication of the MCData emergency alert and associated information; and

b) shall set the MCData emergency private priority state to "MDEPP 2: in-progress" for this one-to-one communication;

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

a) should display to the MCData user an indication that this is a SIP re-INVITE request to downgrade this emergency one-to-one communication to a normal priority one-to-one communication, and:

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

ii) if the <alert-ind> element of the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body is set to "false", should display to the MCData user an indication that the MCData emergency alert is cancelled;

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

A) should display to the MCData user the MCData ID of the originator of the MCData emergency alert, as indicated by the <originated-by> element; and

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

b) shall set the MCData emergency private priority state to "MDEPP 1: no-emergency" for this one-to-one communication; and

c) if the MCData emergency private communication state of the communication is set to "MDEPC 3: emergency-pc-granted", shall set the MCData emergency private communication state of the communication to "MDEPC 1: emergency-pc-capable";

3) may display to the MCData user the MCData ID of the inviting MCData user, if not already done so in the preceding steps;

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

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

6) if the SIP re-INVITE request was received within an on-demand session, shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5], with the clarifications given in clauses 9.2.4.2.2 (for SDS) or 10.2.5.2.2 (for FD);

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

NOTE: The SIP re-INVITE request can be received within an on-demand session or a pre-established session. If the SIP re-INVITE request is received within a pre-established session, the value settings for the media are expected to be the same as was negotiated in the existing pre-established session.

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

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

6.2.8.4.3 MCData in-progress emergency one-to-one communication cancellation

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

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

The MCData client:

1) if the MCData user is not authorised to cancel the in-progress emergency condition on an MCData emergency one-to-one communication as determined by the procedures of clause 6.2.8.3.1.2:

a) should indicate to the MCData user that they are not authorised to cancel the in-progress emergency condition on an MCData emergency one-to-one communication; and

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

3) shall, if the MCData user is cancelling an in-progress emergency condition and optionally an MCData emergency alert originated by another MCData user, include an application/vnd.3gpp.mcdata-info+xml MIME body by executing the procedure in clause 6.2.8.3.8;

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

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

NOTE 1: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session associated with an MCData communication. If the SIP re-INVITE request is sent within a pre-established session, the settings of the media parmeters are expected to be the same as it was negotiated in the existing pre-established session.

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

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

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

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

3) shall set the MCData emergency private communication state of the call to "MDEPC 1: emergency-pc-capable"; and

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

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

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

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

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

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

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

6.2.8.4.4 Upgrade to MCData emergency one-to-one communication

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

Upon receiving a request from an MCData user to upgrade the ongoing MCData one-to-one communication to an MCData emergency one-to-one communication, if this is an unauthorised request for an MCData emergency one-to-one communication as determined by the procedures of clause 6.2.8.3.1.1, the MCData client should indicate to the MCData user that the upgrade request is not authorised and shall exit the procedure. Otherwise, the MCData client:

1) shall generate a SIP re-INVITE request as specified in 3GPP TS 24.229 [5];

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

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

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

NOTE: The SIP re-INVITE request can be sent within an on-demand session or a pre-established session associated with an MCData private call. If the SIP re-INVITE request is sent within a pre-established session, the settings of the media parmeters are expected to be the same as it was negotiated in the existing pre-established session.

5) shall perform the actions specified in clause 6.2.5.1, to include the specific location information for the emergency communication; and

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

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

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

2) shall perform the actions specified in clause 6.2.8.3.4.

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

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