6.3 MCData server procedures

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

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

6.3.1 Distinction of requests at the MCData server

6.3.1.1 SIP MESSAGE request

Editor’s note: In the current release, support for emergency groups and emergency group communications (in particular the use of the <emergency-ind> element) may be absent, partial or limited, namely only provided to the extent of facilitating emergency alert functionality.

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

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

– SIP MESSAGE request routed to the participating MCData function 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 Report element. Such requests are known as "SIP MESSAGE request for location reporting";

– 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 originating participating MCData function 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 originating participating MCData function";

– SIP MESSAGE request routed to the originating participating MCData function 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 containing the value "msf-disc-req". Such requests are known as "SIP MESSAGE request for absolute URI discovery request for participating MCData function";

– SIP MESSAGE request routed to the terminating participating MCData function 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 containing the value "msf-disc-res". Such requests are known as "SIP MESSAGE request for absolute URI discovery response for participating MCData function";

– SIP MESSAGE request routed to the controlling MCData function 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 containing the value "msf-disc-req". Such requests are known as "SIP MESSAGE request for absolute URI discovery request for controlling MCData function";

– SIP MESSAGE request routed to the originating participating MCData function 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 originating participating MCData function";

– SIP MESSAGE request routed to the terminating participating MCData function 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 NETWORK NOTIFICATION message. Such requests are known as "SIP MESSAGE network notification for FD using HTTP for terminating participating MCData function";

– SIP MESSAGE request routed to the terminating participating MCData function 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 participating MCData function";

– SIP MESSAGE request routed to the terminating participating MCData function 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 participating MCData function";

– SIP MESSAGE request routed to an MCData server 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", 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 MCData server";

– SIP MESSAGE request routed to an MCData server 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", 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 MCData server";

– SIP MESSAGE request routed to the controlling MCData function 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 controlling MCData function";

– SIP MESSAGE request routed to the controlling MCData function 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 controlling MCData function";

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

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

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

– SIP MESSAGE requests routed to the terminating participating MCData function with the Request-URI set to the public service identity of the terminating participating MCData function and containing an "application/vnd.3gpp.mcdata-info+xml" MIME body with an <alert-ind-rcvd> element present. Such requests are known as "SIP MESSAGE requests indicating delivery of emergency notification";

– SIP MESSAGE request routed to the terminating participating MCData function 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 REQUEST message. Such requests are known as "SIP MESSAGE request for list of deferred group communications"

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

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

– SIP MESSAGE requests routed to the originating participating MCData function and the Request-URI is set to a public service identity of the originating participating MCData function 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 originating participating MCData function to remove a regroup using preconfigured group" in the procedures in the present document;

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

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

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

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

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

– SIP MESSAGE requests routed to the controlling MCData function and the Request-URI is set to a public service identity of the controlling MCData function 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 controlling MCData function to remove a regroup using preconfigured group" in the procedures in the present document;

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

– SIP MESSAGE requests routed to the non-controlling MCData function and the Request-URI is set to a public service identity of the non-controlling MCData function 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 non-controlling MCData function to remove a group regroup using preconfigured group" in the procedures in the present document;

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

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

– SIP MESSAGE requests routed to the participating MCData function with the Request-URI set to the public service identity of the participating MCData function and containing a Content-Type header field set to "application/vnd.3gpp.mcdata-info+xml" and including an XML body containing a <mcdatainfo> root element containing a <mcdata-Params> element containing an <anyExt> element with the <request-type> element set to a value of "store-comms-in-msgstore-ctrl-req". Such requests are known as "SIP MESSAGE request for controlling the storage of the MCData communications into MCData message store".

If a SIP MESSAGE request is received at an MCData server that is not in accordance with the SIP MESSAGE requests listed above, then the MCData server shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response.

6.3.1.2 SIP INVITE request

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

– SIP INVITE requests routed to the participating MCData function with the Request-URI set to a public service identity of the participating MCData function and contain in an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdataInfo> element containing the <mcdata-Params> element with the <anyExt> element an <pre-established-session-ind> element set to a value of "true". Such requests are known as "SIP INVITE request for establishing a pre-established session" in the procedures in the present document;

– SIP INVITE request routed to the originating participating MCData function 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 originating participating MCData function";

– SIP INVITE request routed to the terminating participating MCData function 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 participating MCData function";

– SIP INVITE request routed to the controlling MCData function 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 controlling MCData function for standalone SDS over media plane";

– SIP INVITE request routed to the originating participating MCData function 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 originating participating MCData function";

– SIP INVITE request routed to the terminating participating MCData function 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 participating MCData function";

– SIP INVITE request routed to the controlling MCData function 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 controlling MCData function for SDS session";

– SIP INVITE request routed to the originating participating MCData function 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 originating participating MCData function";

– SIP INVITE request routed to the terminating participating MCData function 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 participating MCData function"; and

– SIP INVITE request routed to the controlling MCData function 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 controlling MCData function for file distribution";

– SIP INVITE request routed to the originating participating MCData function 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 originating participating MCData function;.

– SIP INVITE request routed to the terminating participating MCData function 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 participating MCData function"; and

– SIP INVITE request routed to the controlling MCData function 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 controlling MCData function for IP Connectivity session".

6.3.2 Sending SIP requests and receiving SIP responses

6.3.2.1 Generating a SIP MESSAGE request towards the terminating MCData client

This clause is referenced from other procedures.

The participating MCData function shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] and:

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

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

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

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

6.3.2.2 Generating a SIP MESSAGE request towards the controlling MCData function

This clause is referenced from other procedures.

When generating a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6], the partcipating MCData function:

1) shall set the Request-URI of the SIP MESSAGE request to the public service identity of the controlling MCData function;

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

NOTE 2: If the controlling MCData function is in an interconnected MCData system in a different trust domain, then the public service identity can identify the MCData gateway server that acts as an entry point in the interconnected MCData system from the local MCData system.

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

NOTE 4: How the participating MCData function determines the public service identity of the controlling MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

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

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the SIP MESSAGE request; and

3) shall include a P-Asserted-Identity header field in the SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP request specified in 3GPP TS 24.229 [5].

6.3.3 Retrieving a group document

This clause describes how an MCData server accesses a group document from a group management server.

NOTE 1: The group document for a user or group regroup based on a preconfigured group is the group document for the preconfigured group restricted to the users or groups included in the regroup stored by the MCData server at the time of the regroup creation and does not include a <preconfigured-group-use-only> element.

Upon receipt of a SIP request:

1) if the MCData server is not yet subscribed to the group document for the group identity in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP request, the MCData server shall subscribe to the "xcap-diff" event-package for the group document of this group identity as specified in 3GPP TS 24.481 [11];

NOTE 2: As a group document can potentially have a large content, the MCData server can subscribe to the group document indicating support of content-indirection as defined in IETF RFC 4483 [13], by following the procedures in 3GPP TS 24.481 [11].

2) upon receipt of a SIP 404 (Not Found) response as a result of attempting to subscribe to the "xcap-diff" event-package for the group document of the group identity in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP request as specified in 3GPP TS 24.481 [11], the MCData server shall send the SIP 404 (Not Found) response with the warning text set to "113 group document does not exist" in a Warning header field as specified in clause 4.9. Otherwise, continue with the rest of the steps; and

3) upon receipt of any other SIP 4xx, SIP 5xx or SIP 6xx response as a result of attempting to subscribe to the "xcap-diff" event-package for the group document of the group identity in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request as specified in 3GPP TS 24.481 [11], the MCData server shall send the SIP final response with the warning text set to "114 unable to retrieve group document" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;

6.3.4 Determining targeted group members for MCData communications

The MCData server shall only send MCData messages to affiliated group members.

The MCData server determines whether a user is affiliated to a group by following the procedures in clause 6.3.5.

If the group is not a regroup based on a preconfigured group, the MCData server determines the affiliated members from the entries contained in the <list> element of the group document by following the procedures specified in clause 6.3.5.

If the group is a regroup based on a preconfigured group, the MCData server determines the affiliated members from the list of users that was stored during successful processing of the creation of the regroup per clause 23 by following the procedures specified in clause 6.3.5.

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

6.3.5 Affiliation check

The MCData server shall determine that the MCData user, with MCData User ID, is affiliated to the MCData group, with MCData Group ID, at the MCData client, with MCData client ID, if the elements, as described in clause 8.3.3.2, exist with their expected values, as below:

1. an MCData group information entry with MCData group ID same as the MCData group ID under consideration;

2. in the MCData group information entry found in 1, an MCData user information entry with the MCData ID same as the MCData ID under consideration;

3. in the MCData user information entry found in 2, an MCData client information entry with MCData Client ID same as the MCData client ID under consideration; and

4. in the MCData user information entry found in 2, an expiration time, which has not expired.

6.3.6 MCData conversation items

6.3.6.1 Server generating a FD HTTP TERMINATION message for FD over HTTP

In order to generate an terminating response message for FD over HTTP, the MCData server:

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

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 the Application ID IE ID 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 payload of FD transmission; and

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

6.3.7 Procedures referenceable from other procedures

6.3.7.1 Emergency alert and emergency communications procedures

6.3.7.1.1 Sending a SIP re-INVITE request for MCData emergency alert or emergency group communication

This clause is referenced from other procedures.

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

The controlling MCData function:

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

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

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

a) shall include a Resource-Priority header field with the namespace populated with the values for an MCData emergency group communication as specified in clause 6.3.7.1.4;

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

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

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

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

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

a) shall include a Resource-Priority header field populated with the values for a normal MCData group communication as specified in clause 6.3.7.1.4; and

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

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

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

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

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

6.3.7.1.2 Generating a SIP MESSAGE request for notification of in-progress emergency status change

This clause is referenced from other procedures.

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

The controlling MCData function:

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

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

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

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

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

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

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

NOTE 4: How the controlling MCData function determines the public service identity of the terminating participating MCData function serving the target MCData ID or of the MCData gateway server in the interconnected MCData system is out of the scope of the present document.

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

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

6) 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-Asserted-Service-Id header field according to IETF RFC 6050 [7];

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

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

6.3.7.1.3 Populate mcdata-info and location-info MIME bodies for emergency alert

This clause is referenced from other procedures.

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

The controlling MCData function:

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

2) shall determine the value of the MCData user’s Mission Critical Organization from the <MissionCriticalOrganization> element, of the MCData user profile document identified by the MCData ID and profile index associated with MCData user (see the MCData user profile document in 3GPP TS 24.484 [12]);

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

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

6.3.7.1.4 Retrieving Resource-Priority header field values for emergency communications

This clause is referenced from other procedures.

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

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <emergency-resource-priority> element contained in the <on-network> 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 contained in the <on-network> 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 namespace and priority values as specified in IETF RFC 8101 [67] for an MCData imminent peril group communication, the controlling MCData function:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <imminent-peril-resource-priority> element contained in the <on-network> 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 contained in the <on-network> 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 namespace and priority values as specified in IETF RFC 8101 [67] for a normal MCData (group or one-to-one) communication, the controlling MCData function:

1) shall retrieve the value of the <resource-priority-namespace> element contained in the <normal-resource-priority> element contained in the <on-network> 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 contained in the <on-network> 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 communication (group or one-to-one). 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.3.7.1.5 Generating a SIP MESSAGE request to indicate successful receipt of an emergency alert or emergency cancellation

This clause is referenced from other procedures.

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

The controlling MCData function:

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

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

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

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

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

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

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

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

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

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

The participating MCData function:

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

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

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

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

6) 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-Asserted-Service-Id header field according to IETF RFC 6050 [7];

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

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

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

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

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

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

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

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

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

The participating MCData function:

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

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

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

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

6) 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-Asserted-Service-Id header field according to IETF RFC 6050 [7];

7) void;

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

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

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

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

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

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

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

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

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

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

6.3.7.1.8 Sending a SIP re-INVITE request for MCData imminent peril group communication

This clause is referenced from other procedures.

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

The controlling MCData function:

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

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

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

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

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

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

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

a) shall include a Resource-Priority header field populated with the values for a normal MCData group communication as specified in clause 6.3.7.1.4; and

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

6.3.7.1.9 Validate priority request parameters

This clause is referenced from other procedures.

This procedure validates the combinations of <emergency-ind>, <imminentperil-ind> and <alert-ind> in the application/vnd.3gpp.mcdata-info+xml MIME body included in:

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

2) the body "URI" header field of the SIP URI included in the application/resource-lists+xml MIME body which is pointed to by a "cid" URL located in the Refer-To header of a SIP REFER request;

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

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

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

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

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

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

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

6.3.7.1.10 Sending a SIP INFO request in the dialog of a SIP request for a priority communication

This clause is referenced from other procedures.

This procedure describes how the controlling MCData function generates a SIP INFO request due to the receipt of a SIP request for a priority communication.

The controlling MCData function:

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

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

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

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

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

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

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

6.3.7.1.11 Sending a SIP INVITE request for MCData emergency group communication

This clause is referenced from other procedures.

This clause describes the procedures for inviting an MCData user to an MCData session associated with an MCData emergency group communication or MCData imminent peril group communication.

The controlling MCData function:

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

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

NOTE 1: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.

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

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

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

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

c) the <mcdata-calling-group-id> element set to the value of the MCData group ID of the emergency group communication.

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

5) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 9.2.4.4.1 (SDS communication) or 10.2.5.4.1 (FD communication);

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

a) shall include a Resource-Priority header field populated with the values for an MCData emergency group communication as specified in clause 6.3.7.1.4;

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

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

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

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

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

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

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

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

This clause is referenced from other procedures.

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

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

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

3) shall include in the SIP 183 (Session Progress) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 9.2.4.4.2 (SDS communication) or 10.2.5.4.2 (FD communication); and

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

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

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

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

3) shall include in the SIP UPDATE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 9.2.4.4.1 (SDS communication) or 10.2.5.4.1 (FD communication);

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

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

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

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

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

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

6.3.7.1.13 Generating a SIP re-INVITE request

This clause is referenced from other procedures.

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

The controlling MCData function:

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

2) shall include an SDP offer with the media parameters as currently established with the terminating MCData client according to 3GPP TS 24.229 [5] with the clarifications specified in clause 9.2.4.4.1 (SDS communication) or 10.2.5.4.1 (FD communication).

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

This clause is referenced from other procedures.

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

The controlling MCData function:

1) shall execute the procedure in clause 6.3.7.1.13;

2) in the generated SIP re-INVITE, shall include a Resource-Priority header field populated with the values for a normal MCData group communication as specified in clause 6.3.7.1.4; and

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

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

This clause covers the on-demand session case only.

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

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

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

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

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

4) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5];

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

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

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

1) shall generate a SIP 200 (OK) response and include an SDP answer consistent with the SDP answer in the received SIP 200 (OK) response;

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

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

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

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

6.3.7.1.16 Generating a SIP re-INVITE request for emergency private (one-to-one) communication origination within a pre-established session

This clause is referenced from other procedures.

Upon receipt by the participating MCData function of a SIP 2xx response from the controlling MCData function which:

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

2) is in response to a SIP INVITE request previously sent by the participating MCData function to the controlling MCData function, containing a Resource-Priority header field populated for an MCData emergency private communication;

the participating MCData function shall:

1) execute the procedures in clause 6.3.7.1.4, where references to the controlling MCData function are replaced with references to the participating MCData function;

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

3) include in the SIP re-INVITE request an SDP offer consistent with the previously negotiated SDP for the pre-established session;

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

5) send the SIP re-INVITE request to the controlling MCData function; and

6) skip the remaining steps in this procedure;

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

Upon receipt by the participating MCData function of a SIP 2xx response from the controlling MCData function which:

1) contains a Warning header field as specified in clause 4.9 with the warning text containing the mcdata-warn-code set to "149"; and

2) is in response to a SIP INVITE request previously sent by the participating MCData function to the controlling MCData function;

the participating MCData function shall wait for the receipt of a SIP INFO request from the controlling MCData function.

Upon receipt of a SIP INFO request from the controlling MCData function within the dialog of the SIP INVITE request for an MCData emergency one-to-one communication, the participating MCData function:

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

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

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

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

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

5) send the SIP re-INVITE request to the controlling MCData function.

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

6.3.7.1.17 Receiving a SIP re-INVITE request by the terminating participating function

This clause applies to the terminating participating function and is part of processing of an in-progress emergency communication cancellation or an upgrade of an ongoing communication. The incoming SIP re‑INVITE request is sent by the controlling MCData function, and the outgoing SIP re‑INVITE is sent towards the MCData client.

On receipt of a SIP re-INVITE request, the terminating participating MCData function shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5] and further:

1) if the incoming SIP re-INVITE request contained an application/sdp MIME body, shall copy the application/sdp MIME body;

2) if the incoming SIP re-INVITE request contained an application/resource-lists+xml MIME body, shall copy the application/resource-lists+xml MIME body;

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

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

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

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

6.3.7.1.18 Receipt of SIP re-INVITE for MCData one-to-one communication from the served user

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

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

1) if unable to process the request due to a lack of resources or a risk of congestion, may reject the SIP request with a SIP 500 (Server Internal Error) response. The participating MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error);

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

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

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

4) shall generate a SIP re-INVITE request according to 3GPP TS 24.229 [5], and proceed as follows:

a) if the incoming SIP re-INVITE request contained an application/resource-lists+xml MIME body with the MCData ID of the invited MCData user, shall copy the MIME application/resource-lists+xml body into the generated SIP re‑INVITE;

b) if the incoming SIP re-INVITE request contained an application/vnd.3gpp.mcdata-info+xml MIME body, shall copy the application/vnd.3gpp.mcdata-info+xml MIME body into the generated SIP re‑INVITE; and

c) if the incoming SIP re-INVITE request contained an application/vnd.3gpp.mcdata-location-info+xml MIME body, shall copy the application/vnd.3gpp.mcdata-location-info+xml MIME body into the generated SIP re‑INVITE;

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

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

7) shall include in the SIP re-INVITE request an SDP containing the SDP currently used by the existing session;

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

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

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

1) shall generate a SIP 200 (OK) response according to 3GPP TS 24.229 [5];

2) if the received SIP 200 (OK) response contained an application/vnd.3gpp.mcdata-info+xml MIME body, shall copy the application/vnd.3gpp.mcdata-info+xml MIME body into the generated SIP 200 (OK) response;

3) if the received SIP 200 (OK) included Warning header field(s), shall copy the Warning header field(s) into the generated SIP 200 (OK) response;

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

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

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

6.3.7.1.19 Controlling MCData function receiving a SIP re-INVITE for upgrade to emergency one-to-one communication

In the procedures in this clause:

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

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

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

1) shall validate that the received SDP is acceptable by the controlling MCData function and if not, reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

2) shall validate the request as described in clause 6.3.7.1.9, and if invalid, shall skip the rest of the steps;

3) if the SIP re-INVITE request contains an unauthorised request for an MCData emergency one-to-one communication as determined by clause 6.3.7.2.6:

a) shall reject the SIP re-INVITE request by generating a SIP 403 (Forbidden) response and applying the procedure in clause 6.3.7.2.7; and

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

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

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

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

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

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

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

6) shall execute the procedure in clause 6.3.7.1.21 in order to send a SIP re-INVITE request towards the MCData user listed in the "uri" attribute of the <entry> element of the <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the received SIP re-INVITE request .

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

1) shall invoke the procedure in clause 6.3.7.1.23 with the received indication of the applicable MCData subservice, in order to generate a SIP 200 (OK) response to the received SIP re-INVITE request;

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

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

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

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

6.3.7.1.20 Controlling MCData function receiving a SIP re-INVITE for cancellation of emergency one-to-one communication

In the procedures in this clause:

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

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

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

1) shall validate the request as described in clause 6.3.7.1.9, and if invalid, shall skip the rest of the steps;

2) if the SIP re-INVITE request contains an unauthorised request for an MCData emergency private (one-to-one) communication cancellation, as determined by clause 6.3.7.2.3:

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

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

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

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

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

5) if the SIP re-INVITE request contains an authorised request for an MCData emergency private communication cancellation as determined by clause 6.3.7.2.3:

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

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

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

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

6) shall execute the procedure in clause 6.3.7.1.22 in order to generate a SIP re-INVITE request and send it towards the MCData user listed in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the received SIP re-INVITE request.

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

1) shall invoke the procedure in clause 6.3.7.1.23 with the received indication of the applicable MCData subsservice, in order to generate a SIP 200 (OK) response to the received SIP re-INVITE request;

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

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

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

6.3.7.1.21 Controlling MCData function sending a SIP re-INVITE for upgrade to emergency one-to-one communication

This clause describes the procedures for the controlling MCData function sending a re-INVITE request to an MCData user in an MCData private (one-to-one) communication for the purpose of upgrading the session to an emergency private communication session. The procedure is initiated by the controlling MCData function as the result of receiving a SIP re-INVITE request, as described in clause 6.3.7.1.19.

The controlling MCData function:

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

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

3) if the received SIP re-INVITE request contains an authorised request for an MCData emergency one-to-one communication, as determined by clause 6.3.7.2.6:

a) shall set the <emergency-ind> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP re-INVITE request to a value of "true";

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

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

4) shall include a Resource-Priority header field populated with the values for an MCData emergency communication as specified in clause 6.3.7.1.4, if the received SIP re-INVITE request contains an authorised request for an MCData emergency private communication as determined in clause 6.3.7.2.6; and

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

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

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

6.3.7.1.22 Controlling MCData function sending a SIP re‑INVITE for cancellation of emergency one-to-one communication

This clause describes the procedures for the controlling MCData function sending a re-INVITE request to an MCData user in an MCData emergency private (one-to-one) communication for the purpose of downgrading the session to a normal priority private communication session. The procedure is initiated by the controlling MCData function as the result of receiving a SIP re-INVITE request, as described in clause 6.3.7.1.20.

The controlling MCData function:

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

3) if the received SIP re-INVITE request contains an authorised request for an MCData emergency private communication cancellation as determined by clause 6.3.7.2.3:

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

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

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

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

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

4) shall include a Resource-Priority header field populated with the values for a normal MCData private communication as specified in clause 6.3.7.1.4, if the received SIP re-INVITE request contains an authorised request for an MCData emergency private communication cancellation as determined in clause 6.3.7.2.3; and

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

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

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

6.3.7.1.23 Controlling MCData function generates a SIP 200 (OK) response

This procedure is invoked by other procedures in the controlling MCData function with an indication of the MCData subservice for which it is to be applied (Short Data Service using media plane or using session, File Distribution or IP Connectivity). The procedure is initiated by the controlling MCData function as the result of receiving a SIP INVITE or a SIP re-INVITE request.

The controlling MCData function:

1) shall generate a SIP 200 (OK) response to the SIP INVITE or SIP re-INVITE request according to 3GPP TS 24.229 [5];

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

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

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

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

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

a) if the indicated MCData subservice is Short Data Service using media plane or using session:

i) the g.3gpp.mcdata.sds media feature tag;

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

iii) the isfocus media feature tag;

b) if the indicated MCData subservice is File Distribution:

i) the g.3gpp.mcdata.fd media feature tag;

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

iii) the isfocus media feature tag; or

c) if the indicated MCData subservice is IP Connectivity:

i) the g.3gpp.mcdata.ipconn media feature tag;

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

iii) the isfocus media feature tag;

7) in response to the SDP offer in the incoming SIP INVITE or SIP re-INVITE request, shall include in the SIP 200 (OK) response an SDP answer specified as follows:

a) as in clause 9.2.3.4.2, if the MCData subservice is Short Data Service using media plane; or

b) as in clause 9.2.4.4.2, if the indicated MCData subservice is Short Data Service using session; or

c) as in clause 10.2.5.4.2, if the indicated MCData subservice is File Distribution; or

d) as in clause 20.4.0b, if the indicated MCData subservice is IP Connectivity;

8) shall include Warning header field(s) received in incoming responses to the SIP INVITE or SIP re-INVITE request;

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

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

6.3.7.2 Authorisations

6.3.7.2.1 Determining authorisation for initiating an MCData emergency alert

If the controlling MCData function has received a SIP request targeted to an MCData group and if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall reject the SIP request with a SIP 403 (Forbidden) response with the warning text set to "168 alert is not allowed on the preconfigured group" as specified in clause 4.9 "Warning header field" and shall skip the rest of this procedure.

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

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

a) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> 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:

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

ii) if 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 is set to a value of "true" as specified in 3GPP TS 24.481 [11]; or

b) if the "entry-info" attribute of the <entry> element of the <EmergencyAlert> element contained within the <MCData-group-call> element of the MCData user profile (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "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 targeted to a MCData group. In all other cases, the MCData emergency alert request shall be considered to be an unauthorised request for an MCData emergency alert targeted to an MCData group.

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

1) if the <allow-activate-emergency-alert> element of the <actions> element of the <rule> element of the <ruleset> element of the MCData user profile document identified by the MCData ID and profile index 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 <One‑to‑One‑EmergencyAlert> element contained within the <OnNetwork> 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 "UsePreConfigured" and the MCData ID of the MCData user targeted for the communication is contained in the <uri-entry> element of the <entry> element of the <One‑to‑One‑EmergencyAlert> element contained within the <OnNetwork> element (see the MCData user profile document in 3GPP TS 24.484 [12]); or

b) 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 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 emergency alert request shall be considered to be an authorised request for an MCData emergency alert targeted to an MCData user. In all other cases, it shall be considered to be an unauthorised request for an MCData emergency alert targeted to an MCData user.

6.3.7.2.2 Determining authorisation for cancelling an MCData emergency alert

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

1) if the <allow-cancel-emergency-alert> element of the <ruleset> element of the MCData user profile document identified by the MCData ID and profile index 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 alert cancellation request shall be considered to be an authorised request for an MCData emergency alert cancellation; and

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

6.3.7.2.3 Determining authorisation for cancelling an MCData emergency communication

If the controlling MCData function has received a SIP request for an MCData group communication with the <emergency-ind> element of the application/vnd.3gpp.mcdata-info+xml MIME body set to a value of "false" and:

1) if the <allow-cancel-group-emergency> element of the <ruleset> element of the MCData user profile document identified by the MCData ID and profile index 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 communication cancellation request shall be considered to be an authorised request for an MCData emergency group communication cancellation; and

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

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

1) 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 and profile index 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; and

2) 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 and profile index of the calling user (see the MCData user profile document in 3GPP TS 24.484 [12]) is set to a value of "false" or is not present, then the MCData emergency private communication cancellation request shall be considered to be an unauthorised request for an MCData emergency private communication cancellation.

Editor’s Note: Whether the controlling MCData function examines the <allow-cancel-private-emergency-call> element or uses local policy to determine whether the calling user is authorised to cancel a private emergency communication is FFS.

6.3.7.2.4 Determining authorisation for initiating an MCData imminent peril communication

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

1) if the <allow-imminent-peril-call> element of the <ruleset> element of the 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 other than "true" the request for initiating an MCData imminent peril communication shall be considered to be an unauthorised request for an MCData imminent peril communication and skip the remaining steps;

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

3) if the "entry-info" attribute of the <entry> element of the <MCDataGroupInitiation> element contained within the <ImminentPerilCall> 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 MCData group identity targeted for the communication is contained in the <uri-entry> element of the <entry> element of the <MCDataGroupInitiation> element contained within the <ImminentPerilCall> element (see the MCData user profile document in 3GPP TS 24.484 [12]); or

4) if the "entry-info" attribute of the <entry> element of the <MCDataGroupInitiation> element contained within the <ImminentPerilCall> 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 communication request shall be considered to be an authorised request for an MCData imminent peril communication. In all other cases, it shall be considered to be an unauthorised request for an MCData imminent peril communication.

6.3.7.2.5 Determining authorisation for cancelling an MCData imminent peril communication

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

1) if the <allow-cancel-imminent-peril> element of the <ruleset> element of the 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 communication cancellation request shall be considered to be an authorised request for an MCData imminent peril communication cancellation; and

2) if the <allow-cancel-imminent-peril> 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" or not present, then the MCData emergency communication cancellation request shall be considered to be an unauthorised request for an MCData imminent peril communication cancellation.

6.3.7.2.6 Determining authorisation for initiating an MCData emergency group or private communication

When the participating MCData function receives a request from the MCData client to originate an MCData emergency group communication or if the controlling MCData function receives a SIP request for an MCData group communication with the <emergency-ind> element of the application/vnd.3gpp.mcdata-info+xml MIME body set to a value of "true":

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:

i) if the <uri-entry> element of the <entry> element of the <MCDataGroupInitiation> element of the <EmergencyCall> 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]) contains the identity of the MCData group targeted by the calling MCData user and if the <allow-MCData-emergency-call> element of the <list-service> element of the group document identified by the targeted MCData group identity is set to a value of "true" as specified in 3GPP TS 24.481 [11], then the participating MCData function or the controlling MCData function shall consider the MCData emergency group communication request to be an authorised request for an MCData emergency group communication and skip the remaining steps;

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" and if the <allow-MCData-emergency-call> element of the <list-service> element of the group document identified by the targeted MCData group identity is set to a value of "true" as specified in 3GPP TS 24.481 [11], then the participating MCData function or the controlling MCData function shall consider the MCData emergency group communication request to be an authorised request for an MCData emergency group communication and skip the remaining steps; or

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

When the participating MCData function receives a request from the MCData client to originate an MCData emergency one-to-one communication or if the controlling MCData function receives a SIP request for an MCData private call with the <emergency-ind> element of the application/vnd.3gpp.mcdata-info+xml MIME body set to a value of "true":

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 MCData ID targeted for the communication is contained in the <uri-entry> element of the <entry> element of the <MCDataPrivateRecipient> element (see the MCData user profile document in 3GPP TS 24.484 [12]); 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 participating MCData function or the controlling MCData function shall consider the MCData emergency private communication request to be an authorised request for an MCData emergency private communication and skip step 2) below; or

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

6.3.7.2.7 Generating a SIP 403 response for priority communication request rejection

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

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

6.3.8 Disposition Notifications

6.3.8.1 Generating an FD Notification

In order to generate an FD notification, the participating MCData function:

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 participating MCData function:

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.