10 File Distribution (FD)
24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS
10.1 General
The group administrator can disable the FD service on a MCData group by setting the <mcdata-allow-file-distribution> element under the <list-service> element, in the group document, to "false".
If the <mcdata-allow-file-distribution> element under the <list-service> element, in the group document, is set to "false" for a MCData group:
— an MCData client should not use the procedures in the clauses of the parent clause for FD to the said MCData group.
– a terminating MCData controlling function should reject the request for FD to the said MCData group.
10.2 On-network FD
10.2.1 General
10.2.1.1 Sending an FD message
When the MCData user wishes to send:
– a one-to-one standalone File Distribution (FD) message to another MCData user; or
– a group standalone File Distribution (FD) message to a pre-configured group;
the MCData client:
1) shall follow the procedures in clause 11.1 for transmission control; and
2) if the procedures in clause 11.1 are successful:
a) if the MCData client decides to use HTTP, shall follow the procedures in clause 10.2.4; and
b) if the MCData client decides to use the media plane, shall follow the the procedures in clause 10.2.5.
10.2.1.2 Handling of received FD messages
10.2.1.2.1 Initial processing of the received FD message
When a MCData client has received a SIP request containing an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1, the MCData Client:
1) shall decode the contents of the application/vnd.3gpp.mcdata-signalling MIME body;
2) if the application/vnd.3gpp.mcdata-signalling MIME body does not contain an FD SIGNALLING PAYLOAD message as specified in clause 15.1.3, shall exit this clause;
3) if more than one Payload IE is included in the FD SIGNALLING PAYLOAD message, shall exit this clause;
4) if the Payload content type in the Payload IE in the FD SIGNALLING PAYLOAD message is not set to "FILEURL", shall exit this clause;
5) if the FD SIGNALLING PAYLOAD message contains a Mandatory download IE set to the value of "MANDATORY DOWNLOAD" shall follow the procedures in clause 10.2.1.2.2;
6) if the FD SIGNALLING PAYLOAD message does not contain a Mandatory download IE, shall follow the procedures in clause 10.2.1.2.3; and
7) if the received FD SIGNALLING PAYLOAD message contains an Application metadata container IE, may process the content of that IE per local policy.
10.2.1.2.2 Mandatory Download
The MCData client:
1) if the FD SIGNALLING PAYLOAD message contains a new Conversation ID, shall instantiate a new conversation with the Message ID in the FD SIGNALLING PAYLOAD identifying the first message in the conversation thread;
2) if the FD SIGNALLING PAYLOAD message contains an existing Conversation ID and:
a) if the FD SIGNALLING PAYLOAD message does not contain an InReplyTo message ID, shall use the Message ID in the FD SIGNALLING PAYLOAD to identify a new message in the existing conversation thread; and
b) if the FD SIGNALLING PAYLOAD message contains an InReplyTo message ID, shall associate the message to an existing message in the conversation thread as identified by the InReplyTo message ID in the FD SIGNALLING PAYLOAD, and use the Message ID in the FD SIGNALLING PAYLOAD to identify the new message;
3) may store the Conversation ID, Message ID, InReplyTo message ID and Date and time in local storage;
4) if the FD SIGNALLING PAYLOAD message does not contain an Application ID IE and does not contain an Extended application ID IE:
a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is for user consumption;
b) shall notify the user or application that the file identified by file URL in the Payload data in the Payload IE will be downloaded automatically; and
c) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the user or application;
5) if the FD SIGNALLING PAYLOAD message contains an Application ID IE:
a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is not for user consumption;
b) if the Application ID value is unknown, shall discard the FD message and exit this clause;
c) if the Application ID value is known, shall notify the application that the file identified by file URL in the Payload data in the Payload IE will be downloaded automatically; and
NOTE 1: If the FD request is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application. Subsequent automatic download of the file is then started and the file is delivered to that application.
d) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the application;
6) if the FD SIGNALLING PAYLOAD message contains an Extended application ID IE:
a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is not for user consumption;
b) if the Extended application ID value is unknown, shall discard the FD message and exit this clause;
c) if the Extended application ID value is known, shall notify the application that the file identified by file URL in the Payload data in the Payload IE will be downloaded automatically; and
NOTE 2: If the FD request is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application. Subsequent automatic download of the file is then started and the file is delivered to that application.
d) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the application;
7) shall generate an FD NOTIFICATION indicating acceptance of the FD request as specified in clause 12.2.1.1;
8) shall attempt to download the file as identified by the file URL in the Payload IE in the FD SIGNALLING PAYLOAD message, as specified in clause 10.2.3.1;
9) if the received FD SIGNALLING PAYLOAD message contains an FD disposition request type IE requesting a file download completed update indication, then after the file has been successfully downloaded, shall generate an FD NOTIFICATION indicating file download completed, by following the procedures in clause 12.2.1.1 with following clarifications:
a) if the received FD SIGNALLING PAYLOAD message is not requested for a file download completed update indication in an FD disposition request type IE, shall not include the target MCData user by skipping the step 3) of clause 12.2.1.1; and
NOTE 3: The FD disposition request will be sent irrespective of whether the received FD SIGNALLING PAYLOAD message contains an FD disposition request type IE requesting a file download completed update indication or not.
10) if the received FD SIGNALLING PAYLOAD message contains an Application metadata container IE, may process the content of that IE per local policy.
10.2.1.2.3 Non-Mandatory download
The MCData client:
1) if the FD SIGNALLING PAYLOAD message does not contain an Application ID IE and does not contain an Extended application ID IE:
a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is for user consumption;
b) shall notify the user about the incoming FD request; and
c) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the user;
2) if the FD SIGNALLING PAYLOAD message contains an Application ID IE:
a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is not for user consumption;
b) if the Application ID value is unknown, shall discard the FD message and exit this clause;
c) if the Application ID value is known, shall notify the application of the incoming FD request; and
NOTE 1: If FD request is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application.
d) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the application;
2A) if the FD SIGNALLING PAYLOAD message contains an Extended application ID IE:
a) shall determine that the payload contained in the Payload IE in the FD SIGNALLING PAYLOAD message is not for user consumption;
b) if the Extended application ID value is unknown, shall discard the FD message and exit this clause;
c) if the Extended application ID value is known, shall notify the application of the incoming FD request; and
NOTE 2: If the FD request is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application.
d) if the FD SIGNALLING PAYLOAD message contains a Metadata IE, shall deliver the contents of the Metadata IE to the application;
3) shall start a timer TDU2 (FD non-mandatory download timer) with the timer value as specified in clause F.2.3;
4) shall wait for the user or application to request to download the file indicated by file URL in the Payload data in the Payload IE in the FD SIGNALLING PAYLOAD message;
5) if the user or application accepts or rejects or decides to defer the FD request, shall stop timer TDU2 (FD non-mandatory download timer);
6) if the user defered the FD request while the timer TDU2 (FD non-mandatory download timer) was running, shall generate an FD NOTIFICATION indicating deferral of the FD request as specified in clause 12.2.1.1;
NOTE 3: Once the timer TDU2 (FD non-mandatory download timer) has expired the FD request can only be accepted or rejected with an appropriate action by the MCData client.
NOTE 4: Once the timer TDU2 (FD non-mandatory download timer) has expired, no action is taken by the MCData client if the FD request is deferred.
7) if the user or application rejects the FD request, shall generate an FD NOTIFICATION indicating rejection of the FD request as specified in clause 12.2.1.1 and shall exit this clause; and
8) if the user accepts the FD request:
a) shall generate an FD NOTIFICATION indicating acceptance of the FD request as specified in clause 12.2.1.1;
b) if the FD SIGNALLING PAYLOAD message contains a new Conversation ID, shall instantiate a new conversation with the Message ID in the FD SIGNALLING PAYLOAD identifying the first message in the conversation thread;
c) if the FD SIGNALLING PAYLOAD message contains an existing Conversation ID and:
i) if the FD SIGNALLING PAYLOAD message does not contain an InReplyTo message ID, shall use the Message ID in the FD SIGNALLING PAYLOAD to identify a new message in the existing conversation thread; and
ii) if the FD SIGNALLING PAYLOAD message contains an InReplyTo message ID, shall associate the message to an existing message in the conversation thread as identified by the InReplyTo message ID in the FD SIGNALLING PAYLOAD, and use the Message ID in the FD SIGNALLING PAYLOAD to identify the new message;
d) may store the Conversation ID, Message ID, InReplyTo message ID and Date and time in local storage;
e) shall attempt to download the file as identified by the file URL in the Payload IE in the FD SIGNALLING PAYLOAD message, as specified in clause 10.2.3.1;
f) if the received FD SIGNALLING PAYLOAD message contains an FD disposition request type IE requesting a file download completed update, then after the file download has been successfully downloaded, shall generate an FD NOTIFICATION by following the procedures in clause 12.2.1.1 with following clarifications:
i) if the received FD SIGNALLING PAYLOAD message is not requested for a file download completed update indication in an FD disposition request type IE, shall not include the target MCData user by skipping the step 3) of clause 12.2.1.1; and
NOTE 5: The FD disposition request will be sent irrespective of whether the received FD SIGNALLING PAYLOAD message contains an FD disposition request type IE requesting a file download completed update indication or not.
g) if the received FD SIGNALLING PAYLOAD message contains an Application metadata container IE, may process the content of that IE per local policy.
10.2.1.3 Discovery of the Absolute URI of the media storage function
10.2.1.3.1 General
In order to upload a file to the media storage function on the controlling MCData function, the MCData UE if not aware of the absolute URI of the media storage function, discovers the absolute URI of the media storage function.
10.2.1.3.2 Void
10.2.1.3.3 Participating MCData function procedures
On receipt of a "SIP MESSAGE request for absolute URI discovery request for participating MCData function", the originating participating MCData function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE 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) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;
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 MESSAGE request;
NOTE 1: The MCData ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.
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, then the participating MCData function shall reject the SIP MESSAGE 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) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request is "msf-disc-req":
a) if the application/vnd.3gpp.mcdata-info+xml MIME body does not contain a MCData group ID, shall determine the public service identity of the controlling MCData function hosting the one-to-one FD using HTTP service for the calling user; and
b) if the application/vnd.3gpp.mcdata-info+xml MIME body contains a MCData group ID, shall determine the public service identity of the controlling MCData function hosting the group standalone FD using HTTP service, associated with the MCData group identity in the <mcdata-calling-group-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request;
NOTE 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.
NOTE 3: 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 4: 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 5: How the originating 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 6: 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) if unable to identify the controlling MCData function, it shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.9, and shall not continue with any of the remaining steps;
6) shall determine whether the MCData user identified by the MCData ID is authorised for MCData communications by following the procedures in clause 11.1;
7) if the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request does not contain a <mcdata-calling-group-id> element or the procedures in clause 11.1 indicate that the user identified by the MCData ID is not allowed to send MCData communications as determined by step 1) of clause 11.1, shall reject the "SIP MESSAGE request for and absolute URI discovery request for participating MCData function" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "200 user not authorised to transmit data" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
8) shall generate a SIP MESSAGE request accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6];
9) shall copy all MIME bodies included in the incoming SIP MESSAGE request to the outgoing SIP MESSAGE request;
10) shall include the MCData ID of the originating user in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP MESSAGE request;
11) 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 outgoing SIP MESSAGE request;
12) shall set the Request-URI of the outgoing SIP MESSAGE request to the public user identity of the controlling MCData function as determined by step 4) in this clause;
13) shall set the P-Asserted-Identity header field of the outgoing SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP MESSAGE request; and
14) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [5].
Upon receipt of a SIP 200 (OK) response in response to the SIP MESSAGE request in step 14):
1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5]; and
2) shall send the SIP 200 (OK) response to the originating MCData client according to 3GPP TS 24.229 [5].
On receipt of a "SIP MESSAGE request for absolute URI discovery response for the participating function", the participating MCData function shall: forward the SIP MESSAGE request to the originating MCData client.
Upon receipt of a SIP 200 (OK) response in response to the forwarded SIP MESSAGE request, the participating MCData function:
1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5]; and
2) shall send the SIP 200 (OK) response to the controlling MCData function according to 3GPP TS 24.229 [5].
10.2.1.3.4 Controlling MCData function procedures
Upon receiving a "SIP MESSAGE request for absolute URI discovery request" message, the controlling MCData function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The controlling MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4]. Otherwise, continue with the rest of the steps;
2) if the SIP MESSAGE does not contain an application/vnd.3gpp.mcdata-info+xml MIME body, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "199 expected MIME bodies not in the request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
3) shall decode the contents of the application/vnd.3gpp.mcdata-info+xml MIME body contained in the SIP MESSAGE;
4) if the <mcdata-calling-group-id> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request is present:
a) shall retrieve the group document associated with the group identity in the SIP MESSAGE request by following the procedures in clause 6.3.3, and shall continue with the remaining steps if the procedures in clause 6.3.3 were successful;
b) if the <on-network-disabled> element is present in the group document, shall send a SIP 403 (Forbidden) response with the warning text set to "115 group is disabled" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
b1) 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 INVITE request with a SIP 403 (Forbidden) response with the warning text set to "167 call is not allowed on the preconfigured group" as specified in clause 4.9 "Warning header field" and shall skip the rest of this procedure;
c) if the <list> element of the <list-service> element in the group document does not contain an <entry> element with a "uri" attribute matching the MCData ID of the originating user contained in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request, shall send a SIP 403 (Forbidden) response with the warning text set to "116 user is not part of the MCData group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
d) if the <list-service> element contains a<mcdata-allow-file-distribution> element in the group document set to a value of "false", shall send a SIP 403 (Forbidden) response with the warning text set to "213 file distribution not allowed for this group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
e) if the <supported-services> element is not present in the group document or is present and contains a <service> element containing an "enabler" attribute which is not set to the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd", shall send a SIP 488 (Not Acceptable) response with the warning text set to "214 FD services not supported for this group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
f) if the MCData server group FD procedures in clause 11.1 indicate that the user identified by the MCData ID:
i) is not allowed to send group MCData communications on this group identity as determined by step 1) of clause 11.1, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "201 user not authorised to transmit data on this group identity" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
ii) the originating user identified by the MCData ID is not affiliated to the group identity contained in the SIP MESSAGE request, as specified in clause 6.x.x, shall return a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;
5) shall generate a SIP 200 (OK) response in response to the "SIP MESSAGE request for absolute URI discovery request for controlling MCData function";
6) shall send the SIP 200 (OK) response towards the originating participating MCData function according to 3GPP TS 24.229 [5]; and
7) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6]. In the generation of the SIP MESSAGE request, the controlling MCData function:
a) 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.fd" along with parameters "require" and "explicit" according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;
b) shall identify the absolute URI of the media storage function associated with the controlling function:
c) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";
d) shall include an application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request, following the rules specified in clause 6.4 for the handling of MIME bodies in a SIP message, with:
i) a <request-type> element containing the value "msf-disc-res"; and
ii) an <mcdata-controller-psi> element set to the absolute URI of the media storage function if in step b) above;
e) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the participating MCData function associated to the MCData ID of the originating user mentioned in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP MESSAGE request; and
NOTE 1: The public service identity can identify the participating MCData function in the local MCData system or in an interconnected MCData system.
NOTE 2: If the 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 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 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.
f) shall copy the public user identity of the calling MCData user from the P-Asserted-Identity header field of the incoming SIP MESSAGE request into the P-Asserted-Identity header field of the outgoing SIP MESSAGE request; and
8) shall send the SIP MESSAGE request towards the participating MCData function as specified in 3GPP TS 24.229 [5].
10.2.2 File upload using HTTP
10.2.2.1 Media storage client procedures
If the file upload is intended for group file distribution, the media storage client shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the media storage client:
1) should indicate to the MCData user that group file distribution is not allowed on the indicated group; and
2) shall skip the remainder of this procedure.
The media storage client shall determine the value of the absolute URI associated with the media storage function of the MCData content server from the <MCDataContentServerURI> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [12]).
The media storage client shall send HTTP requests over a TLS connection as specified for the HTTP client in the UE in annex A of 3GPP TS 24.482 [24].
NOTE 1: The HTTP client encodes the MCData ID in the bearer access token of the Authorization header field of an HTTP request as specified in 3GPP TS 24.482 [24].
NOTE 2: The HTTP client always sends the HTTP requests to an HTTP proxy. Annex A of 3GPP TS 24.482 [24] indicates how the HTTP proxy forwards the HTTP request to the HTTP server.
To upload a UE-stored file to media storage function on the MCData content server, the media storage client:
1) shall generate an HTTP POST request as specified in IETF RFC 7230 [22] and IETF RFC 7231 [23];
2) shall set the Request-URI to the absolute URI identifying the resource on a media storage function;
3) shall set the Host header field to a hostname identifying the media storage function;
4) shall set the Content-Type header field to multipart/mixed and with a boundary delimiter parameter set to any chosen value;
5) if the file upload is for one-to-one file distribution, shall insert an application/vnd.3gpp.mcdata-info+xml MIME body with:
a) the <request-type> element set to a value of "one-to-one-fd"; and
b) the <mcdata-calling-user-id> element set to the originating MCData ID;
6) if the file upload is for group file distribution, shall insert an application/vnd.3gpp.mcdata-info+xml MIME body with:
a) the <request-type> element set to a value of "group-fd";
b) the <mcdata-request-uri> element set to the MCData group identity; and
c) the <mcdata-calling-user-id> element set to the originating MCData ID;
7) if end-to-end security is required for a one-to-one communication, the MCData client protects the binary data representing the file and prefixes the protected binary data with security parameters as described in 3GPP TS 33.180 [26];
8) if
a) end-to-end security is not required for a one-to-one communication, or
b) the file upload is for group file distribution;
shall include the binary data representing the file with Content-Type field set to application/octet-stream and Content-Length field set to the file size; and
9) shall send the HTTP POST request towards the media storage function.
To upload a network-stored file to media storage function on the MCData content server, the media storage client:
1) shall generate an HTTP POST request as specified in IETF RFC 7230 [22] and IETF RFC 7231 [23];
2) shall set the Request-URI to the absolute URI identifying the resource on a media storage function;
3) shall set the Host header field to a hostname identifying the media storage function;
4) shall set the Content-Type header field to multipart/mixed and with a boundary delimiter parameter set to any chosen value;
5) if the file upload is for one-to-one file distribution, shall insert an application/vnd.3gpp.mcdata-info+xml MIME body with:
a) the <request-type> element set to a value of "one-to-one-fd"; and
b) the <mcdata-calling-user-id> element set to the originating MCData ID;
6) if the file upload is for group file distribution, shall insert an application/vnd.3gpp.mcdata-info+xml MIME body with:
a) the <request-type> element set to a value of "group-fd";
b) the <mcdata-request-uri> element set to the MCData group identity; and
c) the <mcdata-calling-user-id> element set to the originating MCData ID;
7) shall insert a message/external-body MIME according to rules and procedures of IETF RFC 2017 [80] with:
a) the Content-Type header field set to message/external-body with:
i) the access-type parameter set to a value of "URL";
ii) the URL parameter set to an absolute URI identifying the URL of the network-stored file being requested to download; and
NOTE 3: For the network-stored file available in the MCData message store the above URL set as //{serverRoot}/nms/{apiVersion}/{storeName}/{boxId}/objects/{objectId}/payload as indicated by the object’s payLoadURL as described in the "Object" data structure in clause 5.3.2.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].
iii) the phantom body area of the message/external-body is not used and should be left blank; and
8) shall send the HTTP POST request towards the media storage function.
On receipt of a HTTP 201 Created containing a Location header field with a URL identifying the location of the resource where the file has been stored on the media storage function, then the media storage client shall store this information.
10.2.2.2 Media storage function procedures
The media storage function on the MCData content server shall act as an HTTP server as defined in annex A of 3GPP TS 24.482 [24].
NOTE 1: The HTTP server validates the MCData ID in the bearer access token of the Authorization header field of an HTTP request as specified in 3GPP TS 24.482 [24].
On receipt of an HTTP POST request with a Request-URI identifying a resource on the media storage function and message/external-body MIME is not included, the media storage function:
1) shall decode the contents of application/vnd.3gpp.mcdata-info+xml MIME body:
a) if the user indicated by <mcdata-calling-user-id> element is not allowed to upload files due to transmission control policy, shall return a HTTP 403 Forbidden response and not continue with the remaining steps in this clause;
b) If the <request-type> element is set to:
a) "one-to-one-fd" and the Content-Length header under application/octet-stream MIME is greater than <max-data-size-fd-bytes> element present in the service configuration document as specified in 3GPP TS 24.484 [12], shall generate and send a HTTP 413 Payload Too Large response and not continue with the remaing steps in this clause;
b) "group-fd":
i) shall retrieve the group document associated with the group identity indicated in the <mcdata-request-uri> element by following the procedures in clause 6.3.3, and shall continue with the remaining steps if the procedures in clause 6.3.3 were successful;
ii) if the Content-Length header under application/octet-stream MIME is greater than <mcdata-on-network-max-data-size-for-FD> element present in the group document retrieved in step i), shall generate and send a HTTP 413 Payload Too Large response and not continue with the remaing steps in this clause;
Editor’s Note: [CR 0133, WI eMCData2] it is FFS to determine how the MCData content server will apply transmission control policy by accessing the configuration documents (e.g service configuration and group configuration) from the MCData server.
2) shall process the HTTP POST request by following the procedures in IETF RFC 7230 [22] and IETF RFC 7231 [23] with the following clarifications:
a) shall store the file in the resource location as identified by the Request-URI; and
b) shall generate and send a HTTP 201 Created response containing a Location header field with a URL identifying the location of the stored file.
On receipt of an HTTP POST request with a Request-URI identifying a resource on the media storage function and message/external-body MIME is included, the media storage function:
1) shall decode the contents of application/vnd.3gpp.mcdata-info+xml MIME body:
a) if the user indicated by <mcdata-calling-user-id> element is not allowed to upload files due to transmission control policy, shall return a HTTP 403 Forbidden response and not continue with the remaining steps in this clause; and
2) shall process the HTTP POST request by following the procedures in IETF RFC 7230 [22] and IETF RFC 7231 [23] with the following clarifications:
a) shall determine the resource location as identified by the Request-URI to store the file;
b) shall use the URL parameter value of the Content-Type header field set with message/external-body and fetch the file from the MCData message store as described in clause 6.7, provided that the URL is pointing to a file in the MCData message store account of the user; and
NOTE 2: For more information on fethcing a file from the MCData message store see clause 6.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].
c) shall generate and send a HTTP 201 Created response containing a Location header field with a URL identifying the location of the stored file in the media storage function of the MCData content server.
10.2.3 File download using HTTP
10.2.3.1 Media storage client procedures
The media storage client shall send HTTP requests over a TLS connection as specified for the HTTP client in the UE, in annex A of 3GPP TS 24.482 [24].
NOTE 1: The HTTP client encodes the MCData ID in the bearer access token of the Authorization header field of an HTTP request as specified in 3GPP TS 24.482 [24].
NOTE 2: The HTTP client always sends the HTTP requests to an HTTP proxy. Annex A of 3GPP TS 24.482 [24] indicates how the HTTP proxy forwards the HTTP request to the HTTP server.
To download a file from the media storage function on the MCData content server, the media storage client:
1) shall generate an HTTP GET request as specified in IETF RFC 7230 [22] and IETF RFC 7231 [23] with a Request-URI set to an absolute URI identifying the URL of the file being requested from the media storage function on the MCData content server; and
2) shall send the HTTP GET request towards the media storage function on the MCData content server.
On receipt of a HTTP 200 OK response containing the requested file, the MCData client shall notify the user or application that the file has been successfully downloaded.
10.2.3.2 Media storage function procedures
The media storage function on the MCData content server shall act as an HTTP server as defined in annex A of 3GPP TS 24.482 [24].
NOTE 1: The HTTP server validates the MCData ID in the bearer access token of the Authorization header field of an HTTP request as specified in 3GPP TS 24.482 [24].
On receipt of an HTTP GET request with a Request-URI identifying a file, the media storage function on the MCData content server:
1) if the MCData user is not allowed to download files due to reception control policy, shall return an HTTP 403 Forbidden response;
2) shall process the HTTP GET request by following the procedures in IETF RFC 7230 [22] and IETF RFC 7231 [23], and shall return a HTTP 200 OK response containing the requested file.
Editor’s Note: [CR 0133, WI eMCData2] it is FFS to determine how the MCData content server will apply reception control policy by accessing the configuration documents (e.g service configuration and group configuration) from the MCData server.
10.2.4 FD using HTTP
10.2.4.1 General
The procedures in the clauses of the parent clause describe the SIP signalling procedures for:
– one-to-one file distribution using HTTP; and
– group standalone file distribution using HTTP.
When the MCData user wishes to perform file distribution via HTTP, the MCData client:
1) shall check that the file size is less than or equal to the:
a) <mcdata-on-network-max-data-size-for-FD> element present in the group document retrieved by the group management client as specified in 3GPP TS 24.481 [11], if the file upload is for a group file distribution; or
b) <max-data-size-fd-bytes> element present in the service configuration document as specified in 3GPP TS 24.484 [12], if the file upload is for a one-to-one file distribution;
2) if the size of the file:
a) is acceptable for upload as determined by step 1), shall determine the value of the absolute URI associated with the media storage function of the MCData content server from the <MCDataContentServerURI> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [12]);
b) is not acceptable for upload, shall not continue with the remaining steps in this clause;
3) shall request the media storage client to upload the file to the media storage function by following the procedures in clause 10.2.2.1; and
4) shall initiate an FD request containing a file URL as specified in clause 10.2.4.2.1.
10.2.4.2 MCData client procedures
10.2.4.2.1 MCData client originating procedures
If a group standalone FD message is to be sent, the MCData client shall determine whether the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCData client:
1) should indicate to the MCData user that group standalone FD is not allowed on the indicated group; and
2) shall skip the remainder of this procedure.
The MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.
The MCData client:
1) shall build the SIP MESSAGE request as specified in clause 6.2.4.1;
2) if a one-to-one standalone FD message is to be sent shall insert in the SIP MESSAGE request:
a) an application/resource-lists+xml MIME body with the MCData ID of the target MCData user or the functional alias to be called 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, according to rules and procedures of IETF RFC 4826 [9]; and
b) an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with:
i) a <request-type> element set to a value of "one-to-one-fd"; and
ii) an <anyExt> element containing:
A) a <call-to-functional-alias-ind> element set to "true" if the functional alias is used in the step a) above;
B) if the MCData client is aware of active functional aliases and if an active functional alias is to be included in the SIP MESSAGE request, the <functional-alias-URI> element set to the URI of the used functional alias; and
C) if the MCData user has requested an application priority, the <user-requested-priority> element set to the user provided value;
3) if a group standalone FD message is to be sent:
a) if the "/<x>/<x>/Common/MCData/AllowedFD" leaf node present in the group document of the requested MCData group as specified in 3GPP TS 24.483 [42] is set to "false", shall reject the request for FD and not continue with the rest of the steps in this clause; and
b) shall insert in the SIP MESSAGE request an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with:
i) the <request-type> element set to a value of "group-fd";
ii) the <mcdata-request-uri> element set to the MCData group identity;
iii) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and
iv) an <anyExt> element containing:
A) if the MCData client is aware of active functional aliases and if an active functional alias is to be included in the SIP MESSAGE request, the <functional-alias-URI> element set to the URI of the used functional alias; and
B) if the MCData user has requested an application priority, the <user-requested-priority> element set to the user provided value;
4) shall generate a standalone FD message as specified in clause 6.2.2.2; and
5) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [5].
Upon receiving a SIP 300 (Multiple Choices) response to the SIP MESSAGE request the MCData client shall use the MCData ID contained in the <mcdata-request-uri> element of the received application/vnd.3gpp.mcdata-info MIME body as the MCData ID of the invited MCData user and shall generate a new SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6], with the clarifications given in this clause and with the following additional clarifications:
1) shall insert in the newly generated SIP MESSAGE request an application/resource-lists+xml MIME body with the MCData ID of the invited MCData user 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 where the MCData ID is found in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info MIME body in the received SIP 300 (Multiple Choices) response;
2) shall not include a <call-to-functional-alias-ind> element into the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body; and
3) shall include a <called-functional-alias-URI> element into the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body with the target functional alias used in the initial SIP MESSAGE request for for sending one-to-one standalone FD message.
10.2.4.2.2 MCData client terminating procedures
Upon receipt of a "SIP MESSAGE request for FD using HTTP for terminating MCData client", the MCData client:
1) may reject the SIP MESSAGE request if there are not enough resources to handle the SIP MESSAGE request;
2) if the SIP MESSAGE request is rejected in step 1), shall respond towards the participating MCData function with a SIP 480 (Temporarily unavailable) response and skip the rest of the steps of this clause;
3) shall generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [5];
4) shall send the SIP 200 (OK) response towards the MCData server according to rules and procedures of 3GPP TS 24.229 [5]; and
5) shall handle the received message as specified in clause 10.2.1.2.
10.2.4.3 Participating MCData function procedures
10.2.4.3.1 Originating participating MCData function procedures
Upon receipt of a "SIP MESSAGE request for FD using HTTP for originating participating MCData function", the participating MCData function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE 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) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;
2) shall determine the MCData ID of the originating user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request, and shall authorise the calling user;
NOTE 1: The MCData ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.
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, then the participating MCData function shall reject the SIP MESSAGE 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) if <mcdata-controller-psi> element is present in the application/vnd.3gpp.mcdata-info+xml, shall use its value as public service identity of the controlling MCData function. Otherwise, if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request is:
a) set to a value of "group-fd", shall determine the public service identity of the controlling MCData function hosting the group standalone FD using HTTP service, associated with the MCData group identity in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request; or
b) set to a value of "one-to-one-fd", shall determine the public service identity of the controlling MCData function hosting the one-to-one FD using HTTP service for the calling user;
NOTE 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.
NOTE 3: 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 4: 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 5: 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 6: 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) if unable to identify the controlling MCData function, it shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.9, and shall not continue with any of the remaining steps;
6) shall determine whether the MCData user identified by the MCData ID is authorised for MCData communications by following the procedures in clause 11.1;
7) if <mcdata-controller-psi> in not present in the application/vnd.3gpp.mcdata-info+xml and if the procedures in clause 11.1 indicate that the user identified by the MCData ID:
a) is not allowed to initiate MCData communications as determined by step 1) of clause 11.1, shall reject the "SIP MESSAGE request for FD using HTTP for originating participating MCData function" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "200 user not authorised to transmit data" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
b) is not allowed to initiate one-to-one MCData communications due to exceeding the maximum amount of data that can be sent in a single request as determined by step 7) of clause 11.1, shall reject the "SIP MESSAGE request for FD using HTTP for originating participating MCData function" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "202 user not authorised for one-to-one MCData communications due to exceeding the maximum amount of data that can be sent in a single request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
c) is not allowed to initiate one-to-one MCData communications to the targeted user as determined by step 1a) of clause 11.1, shall reject the "SIP MESSAGE request for FD using HTTP for originating participating MCData function" with a SIP 403 (Forbidden) response including warning text set to "229 one-to-one MCData communication not authorised to the targeted user" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
8) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6];
9) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the controlling MCData function as determined by step 4) in this clause;
10) shall copy all MIME bodies included in the incoming SIP MESSAGE request to the outgoing SIP MESSAGE request;
10A) if the incoming SIP MESSAGE request contains an application/vnd.3gpp.mcdata-info+xml MIME body that contains a <functional-alias-URI> element, 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 outgoing SIP INVITE request to the received value, otherwise shall not include a <functional-alias-URI> element;
11) shall include the MCData ID of the originating user in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP MESSAGE request;
12) 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 outgoing SIP MESSAGE request;
13) shall set the P-Asserted-Identity in the outgoing SIP MESSAGE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP MESSAGE request; and
14) shall send the SIP MESSAGE request as specified to 3GPP TS 24.229 [5].
Upon receipt of a SIP 202 (Accepted) response in response to the SIP MESSAGE request in step 14):
1) shall generate a SIP 202 (Accepted) response as specified in 3GPP TS 24.229 [5]; and
2) shall send the SIP 202 (Accepted) response to the MCData client according to 3GPP TS 24.229 [5].
Upon receipt of a SIP 200 (OK) response in response to the SIP MESSAGE request in step 14):
1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5]; and
2) shall send the SIP 200 (OK) response to the MCData client according to 3GPP TS 24.229 [5].
Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP MESSAGE request in step 14) the participating MCData function:
1) shall generate a SIP response according to 3GPP TS 24.229 [5];
2) shall include Warning header field(s) that were received in the incoming SIP response; and
3) shall forward the SIP response to the MCData client according to 3GPP TS 24.229 [5].
10.2.4.3.2 Terminating participating MCData function procedures
Upon receipt of a:
– "SIP MESSAGE request for FD using HTTP for terminating participating MCData function"; or
– "SIP MESSAGE network notification for FD using HTTP for terminating participating MCData function";
the participating MCData function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE 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) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;
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 MESSAGE request to retrieve the binding between the MCData ID and public user identity of the terminating MCData user;
3) if the binding between the MCData ID and public user identity of the terminating MCData user does not exist, then the participating MCData function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response, and shall not continue with the rest of the steps;
4) if the SIP MESSAGE is a "SIP MESSAGE request for FD using HTTP for terminating participating MCData function", and if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message with a FD disposition request type IE, shall store the value of the Conversation ID IE, the value of the Message ID IE and the payload IE in the FD SIGNALLING PAYLOAD message;
5) if the SIP MESSAGE is a "SIP MESSAGE network notification for FD using HTTP for terminating participating MCData function", and if FD NETWORK NOTIFICATION message within the application/vnd.3gpp.mcdata-signalling MIME body contains an FD notification type IE with value set as "FILE EXPIRED UNAVAILABLE TO DOWNLOAD" as specified in clause 15.2.6, the file identified using Conversation ID IE shall be removed from the stored file list;
5) shall generate an outgoing SIP MESSAGE request as specified in clause 6.3.2.1;
5A) if the <IncomingOne-to-OneCommunicationList> element exists in the MCData user profile document with one or more <One-to-One-CommunicationListEntry> elements (see the MCData user profile document in 3GPP TS 24.484 [12]) and:
i) if the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP message does not match with the <entry> element of any of the <One-to-One-CommunicationListEntry> elements in the <IncomingOne-to-OneCommunicationList> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]); and
ii) if configuration is not set in the MCData user profile document that allows the MCData user to receive one-to-one MCData communication from any user (see <allow-one-to-one-communication-from-any-user> element in MCData user profile document in 3GPP TS 24.484 [12]);
then:
i) shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "230 one-to-one MCData communication not authorised from this originating user" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
6) 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 outgoing SIP MESSAGE request; and
7) shall send the SIP MESSAGE request as specified in 3GPP TS 24.229 [5].
Upon receipt of a SIP 200 (OK) response in response to the above SIP MESSAGE request, the participating MCData function:
1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5]; and
2) shall send the SIP 200 (OK) response to the controlling MCData function according to 3GPP TS 24.229 [5].
Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP MESSAGE request, the participating MCData function:
1) shall generate a SIP response according to 3GPP TS 24.229 [5];
2) shall include Warning header field(s) that were received in the incoming SIP response; and
3) shall forward the SIP response to the controlling MCData function according to 3GPP TS 24.229 [5].
10.2.4.4 Controlling MCData function procedures
10.2.4.4.1 Originating controlling MCData function procedures
This clause describes the procedures for sending a SIP MESSAGE from the controlling MCData function and is initiated by the controlling MCData function as a result of an action in clause 10.2.4.4.2.
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.fd media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;
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.fd" along with parameters "require" and "explicit" according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;
4) shall copy the following MIME bodies in the received SIP MESSAGE request into the outgoing SIP MESSAGE request by following the guidelines in clause 6.4:
a) application/vnd.3gpp.mcdata-info+xml MIME body; and
b) application/vnd.3gpp.mcdata-signalling MIME body;
5) if the application/vnd.3gpp.mcdata-signalling MIME body in the received SIP MESSAGE request contained a FD SIGNALLING PAYLOAD message without the Mandatory download IE included, then:
a) shall execute the procedures in clause 11.2;
b) if the procedures in clause 11.2 indicate that the mandatory download indication needs to be included, shall include the Mandatory download IE set to a value of "MANDATORY DOWNLOAD" in the FD SIGNALLING PAYLOAD message of the outgoing SIP MESSAGE request;
6) in the application/vnd.3gpp.mcdata-info+xml MIME body:
a) shall set the <mcdata-request-uri> element set to the MCData ID of the terminating user; and
b) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP MESSAGE request was set to a value of "group-fd", shall set the <mcdata-calling-group-id> element to the group identity;
7) shall set the Request-URI to the public service identity of the terminating participating MCData function associated to the MCData user to be invited;
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.
8) shall copy the public user identity of the calling MCData user from the P-Asserted-Identity header field of the incoming SIP MESSAGE request into the P-Asserted-Identity header field of the outgoing SIP MESSAGE request;
9) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd"; and
10) shall send the SIP MESSAGE request according to according to rules and procedures of 3GPP TS 24.229 [5].
10.2.4.4.2 Terminating controlling MCData function procedures
The procedures in this clause are executed upon:
– receipt of a "SIP MESSAGE request for FD using HTTP for controlling MCData function", the controlling MCData function; or
– a decision to now process a previously received "SIP MESSAGE request for FD using HTTP for controlling MCData function" that had been queued for later transmission.
NOTE 1: The controlling MCData function may postpone the continuation of an FD using HTTP procedure by queuing the received "SIP MESSAGE request for FD using HTTP for controlling MCData function". The management of the queue is specified in Annex B of 3GPP TS 23.282 [2].
The controlling MCData function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response or queue the received SIP MESSAGE. The controlling MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4];
2) if the received SIP MESSAGE request has been queued for later transmission, shall include warning text set to "215 request to transmit is queued by the server" in a Warning header field as specified in clause 4.9;, in the SIP 202 (Accepted) response and not continue with the remaining steps in this clause. Otherwise, continue with the rest of the steps;
3) if the SIP MESSAGE does not contain:
a) an application/vnd.3gpp.mcdata-info+xml MIME body; and
b) an application/vnd.3gpp.mcdata-signalling MIME body;
shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "199 expected MIME bodies not in the request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
4) shall decode the contents of the application/vnd.3gpp.mcdata-signalling MIME body contained in the SIP MESSAGE;
5) if the application/vnd.3gpp.mcdata-signalling MIME body does not contain only one FD SIGNALLING PAYLOAD message or FD HTTP TERMINATION message, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "209 one FD SIGNALLING PAYLOAD message or FD HTTP TERMINATION message only must be present in FD request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
6) if the FD SIGNALLING PAYLOAD message or FD HTTP TERMINATION message does not contain only one Payload IE, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "210 Only one File URL must be present in the FD request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
7) if the Payload IE has Payload contents:
a) with a Payload content type set to a value other than "FILEURL" shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "211 payload for an FD request is not FILEURL" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
b) with Payload data containing a file URL identifying a file that does not exist on the media storage function as determined by the procedures of clause 6.7.3, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "212 file referenced by file URL does not exist" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
8) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message with a FD disposition request type IE, shall store the value of the Conversation ID IE and the value of the Message ID IE in the FD SIGNALLING PAYLOAD message;
NOTE 2: The controlling MCData function uses the Conversation ID and Message ID for correlation with disposition notifications.
9) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message:
a) with a Metadata IE, shall derive a timer value for the file availability timer as the minimum of the file availability information in the metadata and the value contained in the <max-file-availability> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12];
b) without a Metadata IE, shall derive a timer value for the file availability timer as the value contained in the <default-file-availability> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12]; and
c) if the FD SIGNALLING PAYLOAD message contains an Application metadata container IE, shall keep the Application metadata container IE with the file, both in storage and in any subsequent transmissions;
10) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request is set to a value of "one-to-one-fd" and the SIP MESSAGE request:
a) does not contain an application/resource-lists+xml MIME body or contains an application/resource-lists+xml MIME body with more than one <entry> element in the set of <list> elements in the <resource-lists> element, shall return a SIP 403 (Forbidden) response with the warning text set to "205 unable to determine targeted user for one-to-one FD" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below; and
b) if the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body contains a <call-to-functional-alias-ind> element set to a value of "true":
i) shall identify the MCData ID(s) of the MCData user(s) that have activated the called functional alias received 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 SIP MESSAGE request by performing the actions specified in clause 22.2.2.2.8;
ii) if unable to determine any MCData ID that has activated the called functional alias received 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 SIP MESSAGE, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including a warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps; and
iii) selects one of the identified MCData IDs, and shall send a SIP 300 (Multiple Choices) response to the SIP MESSAGE request with:
A) an application/vnd.3gpp.mcdata-info MIME body with an <mcdata-request-uri> element set to the selected MCData ID and shall not continue with the rest of the steps in this clause;
NOTE 3: How the controlling MCData function selects the MCData ID is implementation specific.
c) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message contains an application/resource-lists+xml MIME body with exactly one <entry> element in the set of <list> elements in the <resource-lists> element, shall send a SIP MESSAGE request to the MCData user identified 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, as specified in clause 10.2.4.4.1;
11) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD HTTP TERMINATION message:
a) if the FD HTTP TERMINATION message doesn’t contain Conversation Id or Message Id, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "223 No Conversation ID or Message ID present" and shall not continue with rest of the steps; and
b) if not identified any transmission with given Conversation ID, Message ID shall send 404 with reason with waring text set to "224 No transmission available" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps;
12) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message and if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request is set to a value of "group-fd":
a) shall retrieve the group document associated with the group identity in the SIP MESSAGE request by following the procedures in clause 6.3.3, and shall continue with the remaining steps if the procedures in clause 6.3.3 were successful;
b) if the <on-network-disabled> element is present in the group document, shall send a SIP 403 (Forbidden) response with the warning text set to "115 group is disabled" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
b1) 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 MESSAGE request with a SIP 403 (Forbidden) response with the warning text set to "167 call is not allowed on the preconfigured group" as specified in clause 4.9 "Warning header field" and shall skip the rest of this procedure;
c) if the <entry> element of the <list> element of the <list-service> element in the group document does not contain an <mcdata-mcdata-id> element with a "uri" attribute matching the MCData ID of the originating user contained in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request, shall send a SIP 403 (Forbidden) response with the warning text set to "116 user is not part of the MCData group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
d) if the <list-service> element contains a <mcdata-allow-file-distribution> element in the group document set to a value of "false", shall send a SIP 403 (Forbidden) response with the warning text set to "213 file distribution not allowed for this group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
e) if the <supported-services> element is not present in the group document or is present and contains a <service> element containing an "enabler" attribute which is not set to the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd", shall send a SIP 488 (Not Acceptable) response with the warning text set to "214 FD services not supported for this group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
f) if the MCData server group FD procedures in clause 11.1 indicate that the user identified by the MCData ID:
i) is not allowed to initiate group MCData communications on this group identity as determined by step 2) of clause 11.1, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response, with warning text set to "201 user not authorised to transmit data on this group identity" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
ii) is not allowed to initiate group MCData communications on this group identity due to exceeding the maximum amount of data that can be sent in a single request as determined by step 8) of clause 11.1, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "208 user not authorised for MCData communications on this group identity due to exceeding the maximum amount of data that can be sent in a single request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
iii) is not allowed to initiate group MCData communications on this group identity due to exceeding the maximum allowed file size as determined by step 6) of clause 11.1, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "208 user not authorised for MCData communications on this group identity due to exceeding the maximum amount of data that can be sent in a single request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
g) if the originating user identified by the MCData ID is not affiliated to the group identity contained in the SIP MESSAGE request, as specified in clause 6.3.5, shall return a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;
h) shall determine targeted group members for MCData communications by following the procedures in clause 6.3.4;
i) if the procedures in clause 6.3.4 result in no affiliated members found in the selected MCData group, shall return a SIP 403 (Forbidden) response with the warning text set to "198 no users are affiliated to this group" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below; and
j) shall send SIP MESSAGE requests to the targeted group members identified in step j) above by following the procedure in clause 10.2.4.4.1;
13) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message, shall start TDC2 (file availability timer) with the value derived in step 9 of this clause;
14) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD SIGNALLING PAYLOAD message, shall associate the running timer TDC2 (file availability timer) to the Conversation ID, Message ID, Application ID (if included), and Extended application ID (if included) contained in the FD SIGNALLING PAYLOAD message;
NOTE 4: Multiple file availability timers can be running for a file. Each file availability timer is uniquely associated to a Conversation ID and Message ID.
15) shall generate a SIP 202 (Accepted) response in response to the "SIP MESSAGE request for FD using HTTP for controlling MCData function";
16) shall send the SIP 202 (Accepted) response towards the originating participating MCData function according to 3GPP TS 24.229 [5].
17) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD HTTP TERMINATION message and Termination information type IE set to "TERMINATION REQUEST" then:
a) shall identify the FILE transmission with Conversation ID and Message ID and "FILE URL". If any ongoing transmission exist then execute the procedure described in clause 12.4.2.1 with the following clarifications:
i) shall set the FD notification type IE as "FILE DELETED UNAVAILABLE TO DOWNLOAD" as specified in clause 15.2.18;
b) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6]. In the generation of the SIP MESSAGE request, the controlling MCData function:
i) 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.fd" along with parameters "require" and "explicit" according to IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;
ii) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";
iii) shall set the Request-URI of the outgoing SIP MESSAGE request to the public service identity of the participating MCData function associated to the MCData ID of the originating user mentioned in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP MESSAGE request;
NOTE 5: The public service identity can identify the participating MCData function in the local MCData system or in an interconnected MCData system.
NOTE 6: If the 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 7: If the 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 8: How the controlling MCData function determines the public service identity of the 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 9: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.
iv) shall copy the public user identity of the calling MCData user from the P-Asserted-Identity header field of the incoming SIP MESSAGE request into the P-Asserted-Identity header field of the outgoing SIP MESSAGE request;
v) shall include an application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request, following the rules specified in clause 6.4 for the handling of MIME bodies in a SIP message:
A) fill <mcdata-request-uri> element from <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml in received SIP MESSAGE;
vi) shall generate FD HTTP TERMINATION message as described in clause 6.3.6.1;
vii) shall set the Termination information type IE set to "TERMINATION RESPONSE" as specified in clause 15.2.22.
viii) if clause is successful shall set Release response type IE of FD HTTP TERMINATION MESSAGE to "RELEASE SUCCESS" else set to "RELEASE FAILED" as described in clause 15.2.23; and
ix) 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; and
c) shall send the SIP MESSAGE request towards the originating participating MCData function as specified in 3GPP TS 24.229 [5]; and
18) if the application/vnd.3gpp.mcdata-signalling MIME body contains an FD HTTP TERMINATION message and Termination information type IE set to other than "TERMINATION REQUEST" then follow procedures described on clause 13.2.5 and clause 13.2.6.
10.2.5 FD using media plane
10.2.5.1 General
The procedures in the clauses of the parent clause describe the SIP signalling procedures for:
– one-to-one file distribution using media plane; and
– group standalone file distribution using media plane.
10.2.5.2 MCData client procedures
10.2.5.2.1 SDP offer generation
When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 5547 [69], IETF RFC 6135 [19], and IETF RFC 6714 [20], the MCData client:
1) shall include an "m=message" media-level section for the MCData media stream consisting of:
a) the port number;
b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS;
c) an "a=sendonly" attribute;
d) an "a=path" attribute containing its own MSRP URI;
e) set the content type as "a=accept-types:application/vnd.3gpp.mcdata-signalling";
f) set the a=setup attribute as "actpass";
g) a file-selector attribute containing:
i) a ‘name’ selector;
ii) a ‘type’ selector;
iii) a ‘size’ selector; and
iv) a ‘hash’ selector;
h) a file-date attribute; and
i) a file-description attribute; and
2) if end-to-end security is required for a one-to-one communication and the security context does not exist or if the existing security context has expired, shall include the MIKEY-SAKKE I_MESSAGE in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [45].
10.2.5.2.2 SDP answer generation
When the MCData client receives an initial SDP offer for file distribution, the MCData client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [5] and IETF RFC 5547 [69].
When composing an SDP answer, the MCData client:
1) shall include an "m=message" media-level section for the accepted MCData media stream consisting of:
a) the port number;
b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS according to the received SDP offer;
c) an "a=recvonly" attribute;
d) an "a=path" attribute containing its own MSRP URI;
e) set the content type as a=accept-types:application/vnd.3gpp.mcdata-signalling;
f) set the a=setup attribute according to IETF RFC 6135 [19]; and
g) a file-selector attribute containing:
i) a ‘name’ selector;
ii) a ‘type’ selector;
iii) a ‘size’ selector; and
iv) a ‘hash’ selector.
10.2.5.2.3 MCData client originating procedures
The MCData client shall generate a SIP INVITE request in accordance with 3GPP TS 24.229 [5] with the clarifications given below.
The MCData client:
1) shall include the g.3gpp.mcdata.fd media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [16];
2) shall include an Accept-Contact header field containing the g.3gpp.mcdata.fd media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];
3) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];
4) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7] in the SIP INVITE request;
5) should include the "timer" option tag in the Supported header field;
6) should include the Session-Expires header field according to IETF RFC 4028 [38]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";
7) shall generate and contain an application/vnd.3gpp.mcdata-signalling MIME body with the FD SIGNALLING PAYLOAD as described in clause 6.2.2.3;
8) if a one-to-one file distribution is requested:
a0) if the MCData user has requested the origination of an MCData emergency one-to-one communication or is originating an MCData one-to-one communication and the MCData emergency state is already set, then:
i) if this is an authorised request for an MCData emergency one-to-one communication as determined by the procedures of clause 6.2.8.3.1.1, shall comply with the procedures in clause 6.2.8.3.2; or
ii) if this is an unauthorised request for an MCData emergency one-to-one communication as determined in step i) above, should indicate to the MCData user that initiation of an MCData emergency one-to-one communication is not authorized and shall release the generated SIP INVITE request and end the procedure;
a) shall insert in the SIP INVITE request an application/resource-lists+xml MIME body with the MCData ID of the invited MCData user or the functional alias to be called in the "uri" attribute of an <entry> element of the <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, according to rules and procedures of IETF RFC 5366 [18];
NOTE 0: The MCData client indicates whether an MCData ID or a functional alias is to be called as specified in step 8) b) below.
b) shall contain an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with:
i) the <request-type> element set to a value of "one-to-one-fd"; and
ii) an <anyExt> element containing:
A) the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the call request;
B) if the MCData client is aware of active functional aliases and if an active functional alias is to be included in the SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias; and
C) if the MCData user has requested an application priority, the <user-requested-priority> element set to the user provided value;
c) if an end-to-end security context needs to be established and the security context does not exist or if the existing security context has expired, then:
i) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [26];
ii) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [26];
iii) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect one-to-one communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [26];
iv) shall encrypt the PCK to a UID associated to the MCData client using the MCData ID of the invited user and a time related parameter as described in 3GPP TS 33.180 [26];
v) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [26];
vi) shall add the MCData ID of the originating MCData user to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26]; and
vii) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCData user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.180 [26]; and
d) if the MCData emergency private communication state is set to either "MDEPC 2: emergency-pc-requested" or "MDEPC 3: emergency-pc-granted" or if the MCData emergency private priority state of this one-to-one communication is set to a value other than "MDEPP 2: in-progress" or "MDEPP 3: confirm-pending", shall execute the procedures in clause 6.2.8.3.3 to include the Resource-Priority header field;
9) if a group file distribution is requested:
a) if the "/<x>/<x>/Common/MCData/AllowedFD" leaf node present in the group document of the requested MCData group as specified in 3GPP TS 24.483 [42] is set to "false", shall reject the request for FD and not continue with the rest of the steps in this clause;
a1) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element. If a <preconfigured-group-use-only> element exists and is set to the value "true", then the MCData client:
i) should indicate to the MCData user that group file distribution is not allowed on the indicated group; and
ii) shall skip the remainder of this procedure; and
b) shall contain in an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element with:
i) the <request-type> element set to a value of "group-fd";
ii) the <mcdata-request-uri> element set to the MCData group identity;
iii) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and
NOTE 1: The MCData client does not include the MCData ID of the originating MCData user in the body, as this will be inserted into the body of the SIP INVITE request that is sent from the originating participating MCData function.
iv) an <anyExt> element containing:
A) if the MCData client is aware of active functional aliases and if an active functional alias is to be included in the SIP INVITE request, the <functional-alias-URI> element set to the URI of the used functional alias; and
B) if the MCData user has requested an application priority, the <user-requested-priority> element set to the user provided value;
c) if the MCData user has requested the origination of an MCData emergency group communication or is originating an MCData pre-arranged group communication and the MCData emergency state is already set, the MCData client shall execute the procedures in clause 6.2.8.1.1;
d) if the MCData user has requested the origination of an MCData imminent peril group communication, the MCData client shall execute the procedures in clause 6.2.8.1.9;
e) if the MCData client emergency group state for this group is set to "MDEG 2: in-progress" or "MDEG 4: confirm-pending", the MCData client shall execute the procedures in clause 6.2.8.1.2 to include the Resource-Priority header field; and
f) if the MCData client imminent peril group state for this group is set to "MDIG 2: in-progress" or "MDIG 4: confirm-pending", shall execute the procedures in clause 6.2.8.1.12 to include the Resource-Priority header field;
10) shall set the Request-URI of the SIP INVITE request to the public service identity identifying the participating MCData function serving the MCData user;
NOTE 2: The MCData client is configured with public service identity identifying the participating MCData function serving the MCData user.
11) may include a P-Preferred-Identity header field in the SIP INVITE request containing a public user identity as specified in 3GPP TS 24.229 [5];
12) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in clause 10.2.5.2.1; and
13) shall send the SIP INVITE request towards the MCData server according to 3GPP TS 24.229 [5].
Upon receiving a SIP 300 (Multiple Choices) response to the SIP INVITE request the MCData client shall use the MCData ID of MCData user contained in the <mcdata-request-uri> element of the received application/vnd.3gpp.mcdata-info MIME body as the MCData ID of the invited MCData user and shall generate an initial SIP MCData request by following the UE originating session procedures specified in 3GPP TS 24.229 [5], with the clarifications given in this clause and with the following additional clarifications:
1) shall insert in the newly generated SIP INVITE request an application/resource-lists+xml MIME body with the MCData ID of the invited MCData user 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 where the MCData ID is found in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info MIME body in the received SIP 300 (Multiple Choices) response;
2) shall not include a <call-to-functional-alias-ind> element into the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body; and
3) shall include a <called-functional-alias-URI> element into the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body with the target functional alias used in the initial SIP INVITE request for establishing a session for one-to-one file distribution.
On receipt of a SIP 2xx response to the SIP INVITE request, the MCData client:
0) if the response is to a SIP INVITE request for an MCData emergency group an MCData imminent peril group communication, shall perform the actions specified in clause 6.2.8.1.4;
1) if the response is to a SIP INVITE request for an MCData emergency one-to-one communication, shall perform the actions specified in clause 6.2.8.3.4;
2) shall send a SIP ACK request as specified in 3GPP TS 24.229 [5];
3) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38]; and
4) shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.1.2.
On receipt of a SIP 4xx response, a SIP 5xx response or a SIP 6xx response to the SIP INVITE request, the MCData client:
0) if the response is to a SIP INVITE request for an MCData emergency group communication an MCData imminent peril group communication, shall perform the actions specified in clause 6.2.8.1.5;
1) if the response is to a SIP INVITE request for an MCData emergency one-to-one communication, shall perform the actions specified in clause 6.2.8.3.5;
2) shall indicate to the MCData user that the file could not be sent; and
3) shall send a SIP ACK request as specified in 3GPP TS 24.229 [5].
On receipt of a SIP INFO request where the Request-URI contains an MCData session ID identifying an ongoing group session, the MCData client shall follow the actions specified in clause 6.2.8.1.13.
On receipt of a SIP INFO request where the Request-URI contains an MCData session ID identifying an ongoing one to-one session, the MCData client shall follow the actions specified in clause 6.2.8.3.7.
On receipt of an indication from the media plane indicating that the file was not sent successfully, the MCData client shall:
1) shall generate a SIP BYE request according to 3GPP TS 24.229 [5] with:
a) Reason code set to "SIP";
b) cause set to "480"; and
c) text set to "transmission failed";
2) shall set the Request-URI to the MCData session identity to release; and
3) shall send a SIP BYE request towards MCData server according to 3GPP TS 24.229 [5].
10.2.5.2.4 MCData client terminating procedures
Upon receipt of a "SIP INVITE request for file distribution for terminating MCData client" request, the MCData client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [5] with the clarifications below.
The MCData client:
1) may reject the SIP INVITE request if any of the following conditions are met:
a) MCData client does not have enough resources to handle the communication;
b) it is an emergency group file distribution request and the number of maximum simultaneous emergency group calls supported for the specific calling functional alias as specified in the <MaxSimultaneousEmergencyGroupCalls> element within the <FunctionalAliasList> list element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) has been reached; or
c) any other reason outside the scope of this specification;
2) if the SIP INVITE request is rejected in step 1), shall respond toward the participating MCData function either with an appropriate reject code as specified in 3GPP TS 24.229 [5] and warning texts as specified in clause 4.9 or with SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorised to restrict the reason for failure and skip the rest of the steps of this clause;
3) if the SDP offer of the SIP INVITE request contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:
a) shall extract the MCData ID of the originating MCData user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26];
b) shall convert the MCData ID to a UID as described in 3GPP TS 33.180 [26];
c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [26];
d) if authentication verification of the MIKEY-SAKKE I_MESSAGE fails, shall reject the SIP INVITE request with a SIP 488 (Not Acceptable Here) response as specified in IETF RFC 4567 [45], and include warning text set to "136 authentication of the MIKEY-SAKKE I_MESSAGE failed" in a Warning header field as specified in clause 4.9 and not continue with rest of the steps in this clause; and
e) if the signature of the MIKEY-SAKKE I_MESSAGE was successfully validated:
i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.180 [26]; and
ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [26];
NOTE 1: With the PCK successfully shared between the originating MCData client and the terminating MCData client, both clients are able to create an end-to-end secure session.
4) may display to the MCData user the MCData ID of the inviting MCData user;
4A) may display to the MCData user the functional alias of the inviting MCData user, if provided;
5) may display to the MCData user the file meta-data of the incoming file as described by the SDP included in the received SIP INVITE request;
5A) if the SIP INVITE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing an <mcdata-Params> element containing an <mcdata-calling-group-id> element and containing a <request-type> element set to a value of "group-fd" and also containing the an the <emergency-ind> element set to a value of "true":
a) should display to the MCData user an indication that this is a SIP INVITE request for an MCData emergency group communication and:
i) should display the MCData ID of the originator of the MCData emergency group communication contained in the <mcdata-calling-user-id> element of the <mcdata-Params> of the application/vnd.3gpp.mcdata-info+xml MIME body;
ii) should display the MCData group identity of the group with the emergency condition contained in the <mcdata-calling-group-id> element of the <mcdata-Params> of the application/vnd.3gpp.mcdata-info+xml MIME body; and
iii) if the <alert-ind> element within the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body is set to "true", should display to the MCData user an indication of the MCData emergency alert and associated information;
b) shall set the MCData emergency group state to "MDEG 2: in-progress";
c) shall set the MCData imminent peril group state to "MDIG 1: no-imminent-peril"; and
d) shall set the MCData imminent peril group communication state to "MDIGC 1: imminent-peril-gc-capable"; otherwise
5B) if the SIP INVITE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing an <mcdata-Params> element containing an <mcdata-calling-group-id> element and containing a <request-type> element set to a value of "group-fd" and also containing an <imminentperil-ind> element set to a value of "true":
a) should display to the MCData user an indication that this is a SIP INVITE request for an MCData imminent peril group communication and:
i) should display the MCData ID of the originator of the MCData imminent peril group communication contained in the <mcdata-calling-user-id> element of the <mcdata-Params of the application/vnd.3gpp.mcdata-info+xml MIME body; and
ii) should display the MCData group identity of the group with the imminent peril condition contained in the <mcdata-calling-group-id> element of the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body;
b) shall set the MCData imminent peril group state to "MDIG 2: in-progress";
5C) if the SIP INVITE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdatainfo> element containing the <mcdata-Params> element containing a <request-type> element set to a value of "one-to-one-fd" and also containing an <emergency-ind> element set to a value of "true":
a) should display to the MCData user an indication that this is a SIP INVITE request for an MCData emergency private communication and:
i) should display the MCData ID of the originator of the MCData emergency private communication contained in the <mcdata-calling-user-id> element of the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body; and
ii) if the <alert-ind> element within the <mcdata-Params> element of the application/vnd.3gpp.mcdata-info+xml MIME body is set to "true", should display to the MCData user an indication of the MCData emergency alert and associated information; and
b) shall set the MCData emergency private priority state to "MDEPP 2: in-progress" for this private communication;
6) if the Mandatory download IE of the FD SIGNALLING PAYLOAD contained in the application/vnd.3gpp.mcdata-signalling MIME body received in the SIP INVITE request is set to "MANDATORY DOWNLOAD" or if the user has accepted the file download request, then:
a) shall accept the SIP INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [5];
b) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;
c) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [38]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";
d) shall include the g.3gpp.mcdata.fd media feature tag in the Contact header field of the SIP 200 (OK) response;
e) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in the Contact header field of the SIP 200 (OK) response;
f) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5] with the clarifications given in clause 10.2.5.2.2;
g) if a SIP CANCEL request associated with the SIP INVITE request was received, shall execute the procedure in clause 6.2.8.4.1, otherwise, shall send the SIP 200 (OK) response towards the MCData server according to rules and procedures of 3GPP TS 24.229 [5]; and
h) If the SIP 200 (OK) response to the received SIP INVITE request was sent, on receipt of an SIP ACK message to the sent SIP 200 (OK) message, the MCData client shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 6.1.2.3;
otherwise, if the user has not accepted or has rejected the file download request:
a) shall send a SIP 403 (Forbidden) response towards the MCData server according to rules and procedures of 3GPP TS 24.229 [5]; and
NOTE 2: It is possible that the file download does not proceed, but state variables (e.g., group or private emergency, imminent peril, etc.) are modified as result of the processing of the received SIP INVITE request. In this case, it is the responsibility of the implementation and of the user to set the state variables appropriately.
7) if the application/vnd.3gpp.mcdata-signalling MIME body in the received SIP INVITE request contained an FD SIGNALLING PAYLOAD message without the Mandatory download IE included, then:
a) shall notify the MCData user about the incoming FD request and wait for the MCData user to accept or reject or defer the FD request;
b) if the MCData user declines the FD session invitation:
i) shall send a SIP 480 (Temporarily Unavailable) response towards the MCData server with the warning text set to "110 user declined the call invitation" in a Warning header field as specified in clause 4.9;
and skip the rest of the steps in this clause;
c) if the MCData user defers the FD session invitation:
i) shall send a SIP 480 (Temporarily Unavailable) response towards the MCData server with the warning text set to "231 user deferred the call invitation" in a Warning header field as specified in clause 4.9;
and skip the rest of the steps in this clause; and
d) if the MCData user accepts the FD session invitation:
i) shall accept the SIP INVITE request and generate a SIP 200 (OK) response according to rules and procedures of 3GPP TS 24.229 [5];
ii) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;
iii) shall include the Session-Expires header field in the SIP 200 (OK) response and start the SIP session timer according to IETF RFC 4028 [38]. The "refresher" parameter in the Session-Expires header field shall be set to "uas";
iv) shall include the g.3gpp.mcdata.fd media feature tag in the Contact header field of the SIP 200 (OK) response;
v) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" in the Contact header field of the SIP 200 (OK) response;
vi) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5] with the clarifications given in clause 10.2.5.2.2;
vii) if a SIP CANCEL request associated with the SIP INVITE request was received, shall execute the procedure in clause 6.2.8.4.1, otherwise shall send the SIP 200 (OK) response towards the MCData server according to rules and procedures of 3GPP TS 24.229 [5];
viii) may store the Conversation ID, Message ID, InReplyTo message ID and Date and time in local storage;and
ix) if the SIP 200 (OK) response to the received SIP INVITE request was sent, on receipt of an SIP ACK message to the sent SIP 200 (OK) message, the MCData client shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 6.1.2.3;
otherwise, if the user has not accepted or has rejected the session invitation:
i) shall send a SIP 403 (Forbidden) response towards the MCData server according to rules and procedures of 3GPP TS 24.229 [5].
On receipt of an indication from the media plane of the successful download of the file:
1) if the received FD SIGNALLING PAYLOAD message contained an Application metadata container IE, then the MCData client may process the content of that IE per local policy.
10.2.5.2.5 MCData client initiates cancellation for an in-progress emergency one-to-one communication using FD media plane
The MCData client shall execute the procedure in clause 6.2.8.4.3.
10.2.5.2.6 MCData client initiates upgrade to emergency for an ongoing one-to-one communication using FD media plane
The MCData client shall execute the procedure in clause 6.2.8.4.4.
10.2.5.2.7 Terminating procedures for MCData client to upgrade or cancel an emergency one‑to‑one communication using FD media plane
The MCData client shall execute the procedure in clause 6.2.8.4.2.
10.2.5.3 Participating MCData function procedures
10.2.5.3.1 SDP offer generation
The SDP offer is generated based on the received SDP offer. The SDP offer generated by the participating MCData function:
1) shall contain only one SDP media-level section for file distribution as contained in the received SDP offer; and
2) shall contain an "a=key-mgmt" attribute field with a "mikey" attribute value, if present in the received SDP offer.
When composing the SDP offer according to 3GPP TS 24.229 [5], the participating MCData function:
1) shall replace the IP address and port number for the offered media stream in the received SDP offer with the IP address and port number of the participating MCData function, if required; and
NOTE 1: Requirements can exist for the participating MCData function to be always included in the path of the offered media stream, for example: for the support of features such as MBMS, lawful interception and recording. Other examples can exist.
NOTE 2: If the participating MCData function and the controlling MCData function are in the same MCData server, and the participating MCData function does not have a dedicated IP address or a dedicated port number for media stream, the replacement of the IP address or the port number is omitted.
2) if the IP address is replaced shall insert its MSRP URI before the MSRP URI in the "a=path" attribute in the SDP answer.
10.2.5.3.2 SDP answer generation
When composing the SDP answer according to 3GPP TS 24.229 [5], the participating MCData function:
1) shall replace the IP address and port number in the received SDP answer with the IP address and port number of the participating MCData function, for the accepted media stream in the received SDP offer, if required; and
NOTE 1: Requirements can exist for the participating MCData function to be always included in the path of the offered media stream, for example: for the support of features such as MBMS, lawful interception and recording. Other examples can exist.
NOTE 2: If the participating MCData function and the controlling MCData function are in the same MCData server, and the participating MCData function does not have a dedicated IP address or a dedicated port number for media stream, the replacement of the IP address or the port number is omitted.
2) if the IP address is replaced shall insert its MSRP URI before the MSRP URI in the "a=path" attribute in the SDP answer.
10.2.5.3.3 Originating participating MCData function procedures
Upon receipt of a "SIP INVITE request for file distribution for originating participating MCData function", the participating MCData function:
1) if unable to process the request, may reject the SIP INVITE 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) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;
NOTE 1: If the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request for originating a priority communication as determined by clause 6.3.7.2.6, the participating MCData function can, according to local policy, 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 INVITE request, and shall authorise the calling user;
NOTE 2: The MCData ID of the calling user is bound to the public user identity at the time of service authorisation, as documented in clause 7.3.
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, then the participating MCData function shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field as specified in clause 4.9, and shall not continue with any of the remaining steps;
4) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request is:
a) set to a value of "group-fd", shall determine the public service identity of the controlling MCData function associated with the MCData group identity in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP INVITE request; or
b) set to a value of "one-to-one-fd", shall determine the public service identity of the controlling MCData function hosting the file distribution service for the calling user;
NOTE 3: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.
NOTE 4: 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 5: 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 6: 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 7: 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) if unable to identify the controlling MCData function for file distribution, it shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.9, and shall not continue with any of the remaining steps;
6) shall determine whether the MCData user identified by the MCData ID is authorised for MCData communications by following the procedures in clause 11.1;
7) if the procedures in clause 11.1 indicate that the user identified by the MCData ID:
a) is not allowed to initiate MCData communications as determined by step 1) of clause 11.1, shall reject the "SIP INVITE request for file distribution for originating participating MCData function" with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "200 user not authorised to transmit data" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
b) is not allowed to initiate one-to-one MCData communications due to exceeding the maximum amount of data that can be sent in a single request as determined by step 7) of clause 11.1, shall reject the "SIP INVITE request for file distribution for originating participating MCData function" with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "202 user not authorised for one-to-one MCData communications due to exceeding the maximum amount of data that can be sent in a single request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
c) is not allowed to initiate one-to-one MCData communications to the targeted user as determined by step 1a) of clause 11.1, shall reject the "SIP INVITE request for file distribution for originating participating MCData function" with a SIP 403 (Forbidden) response including warning text set to "229 one-to-one MCData communication not authorised to the targeted user" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
7A) if the user identified by the MCData ID requests to initiate an emergency communication, but is not allowed to do so, as determined by executing the procedures in clause 6.7.3.2.6, shall reject the "SIP INVITE request for file distribution for originating participating MCData function" with a SIP 403 (Forbidden) response including warning text set to "233 user not authorised to initiate emergency communication" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
8) shall generate a SIP INVITE request in accordance with 3GPP TS 24.229 [5];
9) shall include the option tag "timer" in the Supported header field;
10) should include the Session-Expires header field according to IETF RFC 4028 [38]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";
11) shall set the Request-URI of the outgoing SIP INVITE request to the public service identity of the controlling MCData function as determined by step 4) in this clause;
11A) shall copy the application/vnd.3gpp.mcdata-info+xml MIME body from the incoming SIP INVITE request to the outgoing SIP INVITE request;
12) shall include the MCData ID of the originating user in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP INVITE request;
12A) if the incoming SIP INVITE request contains an application/vnd.3gpp.mcdata-info+xml MIME body that contains a <functional-alias-URI> element, 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 outgoing SIP INVITE request to the received value, otherwise shall not include a <functional-alias-URI> element;
13) shall include in the outgoing SIP INVITE request, the application/vnd.3gpp.mcdata-signalling MIME body that was present in the incoming SIP INVITE request;
14) 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 outgoing SIP INVITE request;
15) shall set the P-Asserted-Identity in the outgoing SIP INVITE request to the public user identity in the P-Asserted-Identity header field contained in the received SIP INVITE request;
15A) 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 INVITE request from the MCData client;
16) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the MCData client as specified in clause 10.2.5.3.1; and
17) shall send the SIP INVITE request as specified to 3GPP TS 24.229 [5].
Upon receipt of a SIP 200 (OK) response in response to the SIP INVITE request in step 16):
1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5];
2) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 10.2.5.3.2;
3) shall include the option tag "timer" in a Require header field;
4) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [38], "UAS Behavior". If the "refresher" parameter is not included in the received request, the "refresher" parameter in the Session-Expires header field shall be set to "uac";
5) shall include the following in the Contact header field:
a) the g.3gpp.mcdata.fd media feature tag;
b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd"; and
c) the isfocus media feature tag;
6) shall include Warning header field(s) that were received in the incoming SIP 200 (OK) response;
7) shall include an MCData session identity mapped to the MCData session identity provided in the Contact header field of the received SIP 200 (OK) response;
8) 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.
9) shall include the public service identity received in the P-Asserted-Identity header field of the incoming SIP 200 (OK) response into the P-Asserted-Identity header field of the outgoing SIP 200 (OK) response; and
10) shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.2.1;
11) shall send the SIP 200 (OK) response to the MCData client according to 3GPP TS 24.229 [5]; and
12) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38].
Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP INVITE request in step 16) the participating MCData function:
1) shall generate a SIP response according to 3GPP TS 24.229 [5];
2) shall include Warning header field(s) that were received in the incoming SIP response; and
3) shall forward the SIP response to the MCData client according to 3GPP TS 24.229 [5].
10.2.5.3.4 Terminating participating MCData function procedures
Upon receipt of a "SIP INVITE request for file distribution for terminating participating MCData function", the participating MCData function:
1) if unable to process the request, may reject the SIP INVITE 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) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;
NOTE 1: If the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true", the participating MCData function can, according to local policy, choose to accept the request even if the maximum number of acceptable communications is exceeded.
2) shall check the presence of the isfocus media feature tag in the URI of the Contact header field and if it is not present then the participating MCData function shall reject the request with a SIP 403 (Forbidden) response with the warning text set to "104 isfocus not assigned" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps;
3) 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 INVITE request to retrieve the binding between the MCData ID and public user identity of the terminating MCData user;
3A) if the binding between the MCData ID and public user identity of the terminating MCData user does not exist (i.e. MCData user is not available) or network congestion exists, and if later delivery is required, then the participating MCData function shall store the communication for later delivery with following additional informations included:
a) shall include a Payload IE with:
i) the Payload content type set to "FILEURL" as specified in clause 15.2.13; and
ii) the URL of the file to be stored for later delivery in the Payload data as as specified in clause 15.2.13; and
NOTE 2: The file can be stored in the temporary storage of the MCData server or in the MCData content server. The URL of the stored file for later delivery is updated accordingly.
b) may include a Metadata IE with the required file description information and file availability information;
3B) if the communication is stored in step 3A) above and to store the file content in the temporary storage, then the participating MCData function:
a) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5] with the following clarifications:
i) include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5] with the following clarifications:
A) if included in the SDP offer, shall include an "m=message" media-level section for the offered MCData media stream consisting of:
I) the IP address and port number of the participating MCData function;
II) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS;
III) a format list field set to ‘*’;
IV) an "a=recvonly" attribute;
V) an "a=path" attribute containing its own MSRP URI;
VI) set the content type as a=accept-types:application/vnd.3gpp.mcdata-signalling; and
VII) set the a=setup attribute to "passive", according to IETF RFC 6135 [19];
ii) include the option tag "timer" in a Require header field;
iii) include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [38], "UAS Behavior". If no "refresher" parameter was included in the SIP INVITE request, the "refresher" parameter in the Session-Expires header field shall be set to "uas";
iv) include the following in the Contact header field:
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) an MCData session identity mapped to the MCData session identity provided in the Contact header field of the received SIP INVITE request from the controlling MCData function;
v) start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38];
vi) include the warning text set to "232 communication is stored for later delivery" in a Warning header field as specified in clause 4.9;
vii) interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.2.5.1 to receive the file from controlling MCData function and clause 7.1.3.2 to receive the file content; and
viii) shall send the SIP 200 (OK) response to the controlling MCData function according to 3GPP TS 24.229 [5]; and
b) shall generate and send an FD NOTIFICATION indicating deferral of the FD request as specified in clause 12.2.2.3 with including the warning text set to "232 communication is stored for later delivery" in a Warning header field as specified in clause 4.9;
and skip the rest of the steps of this clause;
4) if the binding between the MCData ID and public user identity of the terminating MCData user does not exist, then the participating MCData function shall reject the SIP INVITE request with a SIP 404 (Not Found) response, and shall not continue with the rest of the steps;
4A) if the <IncomingOne-to-OneCommunicationList> element exists in the MCData user profile document with one or more <One-to-One-CommunicationListEntry> elements (see the MCData user profile document in 3GPP TS 24.484 [12]) and:
i) if the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP INVITE request does not match with the <entry> element of any of the <One-to-One-CommunicationListEntry> elements in the <IncomingOne-to-OneCommunicationList> element of the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]); and
ii) if configuration is not set in the MCData user profile document that allows the MCData user to receive one-to-one MCData communication from any user (see <allow-one-to-one-communication-from-any-user> element in MCData user profile document in 3GPP TS 24.484 [12]);
then:
i) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response including warning text set to "230 one-to-one MCData communication not authorised from this originating user" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
5) shall generate a SIP INVITE request in accordance with 3GPP TS 24.229 [5];
6) should include the Session-Expires header field according to IETF RFC 4028 [38]. It is recommended that the "refresher" header field parameter is omitted. If included, the "refresher" header field parameter shall be set to "uac";
7) shall include the option tag "timer" in the Supported header field;
8) shall include the following in the Contact header field:
a) the g.3gpp.mcdata.fd media feature tag;
b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";
c) the isfocus media feature tag;
d) an MCData session identity mapped to the MCData session identity provided in the Contact header field of the incoming SIP INVITE request; and
e) any other uri-parameter provided in the Contact header field of the incoming SIP INVITE request;
9) shall include in the SIP INVITE request all Accept-Contact header fields and all Reject-Contact header fields, with their feature tags and their corresponding values along with parameters according to rules and procedures of IETF RFC 3841 [8] that were received (if any) in the incoming SIP INVITE request;
10) shall set the Request-URI of the outgoing SIP INVITE request to the public user identity associated to the MCData ID of the terminating MCData user;
11) shall populate the outgoing SIP INVITE request with the MIME bodies that were present in the incoming SIP INVITE request;
12) shall copy the contents of the P-Asserted-Identity header field of the incoming SIP INVITE request to the P-Asserted-Identity header field of the outgoing SIP INVITE request;
13) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for file distribution for terminating participating MCData function" as specified in clause 10.2.5.3.1; and
14) shall send the SIP INVITE request as specified in 3GPP TS 24.229 [5].
Upon receipt of a SIP 200 (OK) response in response to the above SIP INVITE request, the participating MCData function:
1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5];
2) shall include in the SIP 200 (OK) response an SDP answer based on the SDP answer in the received SIP 200 (OK) response as specified in clause 10.2.5.3.2;
3) shall include the option tag "timer" in a Require header field;
4) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [38], "UAS Behavior". If no "refresher" parameter was included in the SIP INVITE request, the "refresher" parameter in the Session-Expires header field shall be set to "uas";
5) shall include the following in the Contact header field:
a) the g.3gpp.mcdata.fd media feature tag;
b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd"; and
c) an MCData session identity mapped to the MCData session identity provided in the Contact header field of the received SIP INVITE request from the controlling MCData function;
6) if the incoming SIP 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.
7) shall copy the P-Asserted-Identity header field from the incoming SIP 200 (OK) response to the outgoing SIP 200 (OK) response;
8) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38];
9) shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.2.2;
10) shall send the SIP 200 (OK) response to the controlling MCData function according to 3GPP TS 24.229 [5]; and
11) shall generate and send an FD NOTIFICATION indicating acceptance of the FD request as specified in clause 12.2.2.3.
Upon receiving a SIP 480 (Temporarily Unavailable) response with the warning text set to: "231 user deferred the call invitation" in a Warning header field as specified in clause 4.9 to the above SIP INVITE request and if later delivery is required, the participating MCData function:
1) shall store the communication for later delivery with following additional information included:
a) shall include a Payload IE with:
i) the Payload content type set to "FILEURL" as specified in clause 15.2.13; and
ii) the URL of the file to be stored for later delivery is included in the Payload data as specified in clause 15.2.13; and
NOTE 3: The file can be stored in the temporary storage of the MCData server or MCData content server. The URL of stored file for later delivery is updated accordingly.
b) may include a Metadata IE with the required file description information and file availability information;
2) if the communication is stored in step 1) above and to store the file content in the temporary storage, shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5] with the following clarifications:
a) shall include an SDP answer in the SIP 200 (OK) response to the SDP offer in the incoming SIP INVITE request according to 3GPP TS 24.229 [5] with the following clarifications:
i) shall include an "m=message" media-level section for the accepted MCData media stream consisting of:
A) shall include the IP address and port number of the participating MCData function, for the accepted media stream in the received SDP offer;
B) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS according to the received SDP offer;
C) a format list field set to ‘*’;
D) an "a=recvonly" attribute;
E) an "a=path" attribute containing its own MSRP URI;
F) set the content type as a=accept-types:application/vnd.3gpp.mcdata-signalling; and
G) set the a=setup attribute set to "passive", according to IETF RFC 6135 [19];
b) shall include the option tag "timer" in a Require header field;
c) shall include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [38], "UAS Behavior". If no "refresher" parameter was included in the SIP INVITE request, the "refresher" parameter in the Session-Expires header field shall be set to "uas";
d) shall include the following in the Contact header field:
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) an MCData session identity mapped to the MCData session identity provided in the Contact header field of the received SIP INVITE request from the controlling MCData function;
e) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38];
f) shall include the warning text set to "232 communication is stored for later delivery" in a Warning header field as specified in clause 4.9;
g) shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.2.5.1 to receive the file from controlling MCData function and clause 7.1.3.2 to receive the file content; and
h) shall send the SIP 200 (OK) response to the controlling MCData function according to 3GPP TS 24.229 [5]; and
3) shall generate and send an FD NOTIFICATION indicating deferral of the FD request as specified in clause 12.2.2.3.
Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request, the participating MCData function:
1) shall generate a SIP response according to 3GPP TS 24.229 [5];
2) shall include Warning header field(s) that were received in the incoming SIP response;
3) shall forward the SIP response to the controlling MCData function according to 3GPP TS 24.229 [5]; and
4) shall generate and send an FD NOTIFICATION indicating rejection of the FD request as specified in clause 12.2.2.3.
On receipt of an indication from the media plane of the successful download of the file or on successful download of the file after retrival of deferred FD request by the receiving MCData client and if the received FD SIGNALLING PAYLOAD message contained an FD disposition request type IE requesting a file download completed update indication in the sent SIP INVITE request, then, the participating MCData function:
1) shall follow the procedures described in clause 12.2.2.3.
On receipt of an indication from the media plane of the successful download of the file for later delivery, the participating MCData function:
1) shall update the URL of the stored file for later delivery in the Payload data.
10.2.5.3.5 Processing of request from the served user to upgrade or cancel an emergency one‑to‑one communication using FD media plane
The participating MCData function shall execute the procedure in clause 6.3.7.1.18.
10.2.5.3.6 Processing of request from controlling MCData function to upgrade or cancel an emergency one‑to‑one communication using FD media plane
The participating MCData function shall execute the procedure in clause 6.3.7.1.17.
10.2.5.4 Controlling MCData function procedures
10.2.5.4.1 SDP offer generation
When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 5547 [69], IETF RFC 6135 [19], and IETF RFC 6714 [20], the MCData client:
1) shall include an "m=message" media-level section for the MCData media stream consisting of:
a) the port number;
b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS;
c) an "a=sendonly" attribute;
d) an "a=path" attribute containing its own MSRP URI;
e) set the content type as "a=accept-types:application/vnd.3gpp.mcdata-signalling";
f) set the a=setup attribute as "actpass";
g) a file-selector attribute containing:
i) a ‘name’ selector;
ii) a ‘type’ selector;
iii) a ‘size’ selector; and
iv) a ‘hash’ selector;
h) a file-date attribute; and
i) a file-description attribute.
10.2.5.4.2 SDP answer generation
When composing the SDP answer according to 3GPP TS 24.229 [5], the controlling MCData function:
1) shall include an "m=message" media-level section for the accepted MCData media stream consisting of:
a) the port number;
b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS according to the received SDP offer;
c) a format list field set to ‘*’;
d) an "a=recvonly" attribute;
e) an "a=path" attribute containing its own MSRP URI;
f) set the content type as a=accept-types:application/vnd.3gpp.mcdata-signalling; and
g) set the a=setup attribute set to "passive", according to IETF RFC 6135 [19]; and
h) a file-selector attribute containing:
i) a ‘name’ selector;
ii) a ‘type’ selector;
iii) a ‘size’ selector; and
iv) a ‘hash’ selector.
10.2.5.4.3 Originating controlling MCData function procedures
This clause describes the procedures for inviting an MCData user to an MCData session. The procedure is initiated by the controlling MCData function as the result of an action in clause 10.2.5.4.4.
The controlling MCData function:
1) shall generate a SIP INVITE request as specified in 3GPP TS 24.229 [5] with an application/vnd.3gpp.mcdata-info+xml MIME body included;
1A) if the received SIP INVITE request contains an authorised request for an MCData emergency communication as determined by clause 6.3.7.2.6, shall, in the generated SIP INVITE request:
a) set the <emergency-ind> element of the application/vnd.3gpp.mcdata-info+xml MIME body to a value of "true";
b) include a Resource-Priority header field populated with the values for an MCData emergency communication as specified in clause 6.3.7.1.4;
c) if the <alert-ind> element is set to "true" in the received SIP INVITE request and the initiation of MCData emergency alerts is authorized, as determined by the procedures of clause 6.3.7.2.1, 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, set the <alert-ind> element to a value of "false" in the application/vnd.3gpp.mcdata-info+xml MIME body; and
d) for a group communication, if the in-progress imminent peril state of the group is set to a value of "true", include in the application/vnd.3gpp.mcdata-info+xml MIME body an <imminentperil-ind> element set to a value of "false";
NOTE 1: 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.
e) set the <request-type> element of the application/vnd.3gpp.mcdata-info+xml MIME body to the value of the <request-type> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the received SIP INVITE request;
1B) for a group communication, 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 an <imminentperil-ind> element set to a value of "true".
2) shall include the Supported header field set to "timer";
3) should include the Session-Expires header field according to rules and procedures of IETF RFC 4028 [38]. The refresher parameter shall be omitted;
4) shall include an Accept-Contact header field containing the g.3gpp.mcdata.fd media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];
5) shall include an Accept-Contact header field with the media feature tag g.3gpp.icsi-ref with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" along with parameters "require" and "explicit" according to IETF RFC 3841 [8];
6) shall include a Referred-By header field with the public user identity of the inviting MCData client;
7) shall include in the Contact header field an MCData session identity for the MCData session with the g.3gpp.mcdata.fd media feature tag, the isfocus media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" according to IETF RFC 3840 [16];
8) shall include in the application/vnd.3gpp.mcdata-info+xml MIME body in the outgoing SIP INVITE request:
a) the <mcdata-request-uri> element set to the MCData ID of the terminating user;
b) the <mcdata-calling-group-id> element set to the group identity if the request is for group file distribution; and
c) the <mcdata-calling-user-id> element set to the calling user MCData ID;
9) shall include in the outgoing SIP INVITE request, the application/vnd.3gpp.mcdata-signalling MIME body that was present in the incoming SIP INVITE request;
9A) if the application/vnd.3gpp.mcdata-signalling MIME body in the received SIP INVITE request contained a FD SIGNALLING PAYLOAD message without the Mandatory download IE included, then:
a) shall execute the procedures in clause 11.2; and
b) if the procedures in clause 11.2 indicate that the mandatory download indication needs to be included, shall include the Mandatory download IE set to a value of "MANDATORY DOWNLOAD" in the FD SIGNALLING PAYLOAD message of the outgoing SIP INVITE request;
10) shall set the Request-URI to the public service identity of the terminating participating MCData function associated to the MCData user to be invited;
NOTE 2: The public service identity can identify the terminating participating MCData function in the local MCData system or in an interconnected MCData system.
NOTE 3: 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 4: 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 5: 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 6: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.
11) shall set the P-Asserted-Identity header field to the public service identity of the controlling MCData function;
12) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service-Id header field according to IETF RFC 6050 [7] in the SIP INVITE request;
13) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating client according to the procedures specified in clause 10.2.5.4.1; and
14) shall send the SIP INVITE request towards the terminating client in accordance with 3GPP TS 24.229 [5].
Upon receiving a SIP 200 (OK) response for the SIP INVITE request the controlling MCData function:
1) shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.3.
NOTE 7: The procedures executed by the controlling MCData function prior to sending a response to the inviting MCData client are specified in clause 10.2.5.4.4.
10.2.5.4.4 Terminating controlling MCData function procedures
In the procedures in this clause:
1) MCData ID in an incoming SIP INVITE request refers to the MCData ID of the originating user from the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP INVITE request;
2) group identity in an incoming SIP INVITE request refers to the group identity from the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP INVITE request; and
3) MCData ID in an outgoing SIP INVITE request refers to the MCData ID of the called user in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP INVITE request.
The procedures in this clause are executed upon:
– receipt of a "SIP INVITE request for controlling MCData function for file distribution"; or
– a decision to now process a previously received "SIP INVITE request for controlling MCData function for file distribution" that had been queued for later transmission.
NOTE 1: The controlling MCData function may postpone the continuation of an FD using media plane procedure by queuing the received "SIP INVITE request for controlling MCData function for file distribution". The management of the queue is specified in Annex B of 3GPP TS 23.282 [2].
The controlling MCData function:
1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP INVITE request with a SIP 500 (Server Internal Error) response or queue the received SIP INVITE. The controlling MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4];
NOTE 1A: If the SIP INVITE request contains an emergency indication or an imminent peril indication set to a value of "true" and this is an authorised request originating an MCData emergency group communication as determined by clause 6.3.7.2.6, or for originating an MCData imminent peril group communication as determined by clause 6.3.7.2.4, the controlling MCData function can, according to local policy, choose to accept the request.
2) if the received SIP INVITE request has been queued for later transmission, shall include warning text set to "215 request to transmit is queued by the server" in a Warning header field as specified in clause 4.9, in the SIP 100 (Trying) response, and shall send the SIP 100 (TRYING) response towards the originating participating MCData function according to 3GPP TS 24.229 [5] and not continue with the remaining steps in this clause. Otherwise, continue with the rest of the steps;
3) shall determine if the media parameters are acceptable and the MSRP URI is offered in the SDP offer and if not reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;
3A) if the received SIP INVITE request includes an application/vnd.3gpp.mcdata-info+xml MIME body with an <emergency-ind> element included or an <imminentperil-ind> element included, shall validate the request as described in clause 6.3.7.1.9;
3B) if the SIP INVITE request contains an unauthorised request for an MCData emergency communication as determined by clause 6.3.7.2.6:
a) shall reject the SIP INVITE request with a SIP 403 (Forbidden) response as specified 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;
3C) if the SIP INVITE request contains an unauthorised request for an MCData imminent peril group communication as determined by clause 6.3.7.2.4, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response with the following clarifications:
a) shall include in the SIP 403 (Forbidden) response an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with the <imminentperil-ind> element set to a value of "false"; and
b) shall send the SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [5] and skip the rest of the steps;
3D) if a Resource-Priority header field is included in the SIP INVITE request:
a) if the Resource-Priority header field is set to the value indicated for emergency communications and the SIP INVITE request does not contain an emergency indication and the in-progress emergency state of the group is set to a value of "false", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the rest of the steps; or
b) if the Resource-Priority header field is set to the value indicated for imminent peril communications and the SIP INVITE request does not contain an imminent peril indication and the in-progress imminent peril state of the group is set to a value of "false", shall reject the SIP INVITE request with a SIP 403 (Forbidden) response and skip the rest of the steps;
4) if the incoming SIP INVITE request does not contain an application/vnd.3gpp.mcdata-signalling MIME body with the FD SIGNALLING PAYLOAD as described in clause 6.2.2.3, shall reject the SIP INVITE request with appropriate reject code;
5) shall reject the SIP request with a SIP 403 (Forbidden) response and not process the remaining steps if:
a) an Accept-Contact header field does not include the g.3gpp.mcdata.fd media feature tag; or
b) an Accept-Contact header field does not include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd";
6) shall cache SIP feature tags, if received in the Contact header field and if the specific feature tags are supported;
7) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38];
8) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request is set to a value of "one-to-one-fd" and:
a) the conditions in clause 11.1 indicate that the MCData user is not allowed to initiate FD communications due to file size exceeding allowed limits as determined by step 4) of clause 11.1, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "220 user not authorised for FD communications due to file size" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
NOTE 2: The size of the file intended for transfer over the media plane is obtained from the ‘size’ selector of the file-selector attribute in the received SDP offer.
a1) if the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of an application/vnd.3gpp.mcdata-info+xml MIME body contains an <call-to-functional-alias-ind> element set to a value of "true":
i) shall identify the MCData ID(s) of the MCData user(s) that have activated the called functional alias received 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 SIP INVITE request by performing the actions specified in clause 22.2.2.2.8, and:
A) if unable to determine any MCData ID that has activated the called functional alias received 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 SIP INVITE request, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response including a warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps; and
B) selects one of the identified MCData IDs, and shall send a SIP 300 (Multiple Choices) response to the SIP INVITE request populated according to 3GPP TS 24.229 [5], IETF RFC 3261 [4] with:
I) a Contact header field containing a SIP URI for the MCData session identity; and
II) an application/vnd.3gpp.mcdata-info MIME body with a <mcdata-request-uri> element set to the selected MCData ID and shall not continue with the rest of the steps in this clause;
NOTE 2A: How the controlling MCData function determines the appropriate MCData ID is implementation-specific.
b) the SIP INVITE request:
i) does not contain an application/resource-lists+xml MIME body or contains an application/resource-lists+xml MIME body with more than one <entry> element in the set of <list> elements in the <resource-lists> element, shall return a SIP 403 (Forbidden) response with the warning text set to "205 unable to determine targeted user for one-to-one FD" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below; and
ii) contains an application/resource-lists+xml MIME body with exactly one <entry> element in a <list> element in the <resource-lists> element, shall invite the MCData user identified by the "uri" attribute of the <entry> element of the <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, as specified in clause 10.2.5.4.3; and
shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.3; and
9) if the <request-type> element in the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request is set to a value of "group-fd":
a) shall retrieve the necessary group document(s) from the group management server for the group identity contained in the SIP INVITE request and carry out initial processing as specified in clause 6.3.3, and shall continue with the remaining steps if the procedures in clause 6.3.3 were successful;
b) if the <on-network-disabled> element is present in the group document, shall send a SIP 403 (Forbidden) response with the warning text set to "115 group is disabled" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
b1) 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 INVITE request with a SIP 403 (Forbidden) response with the warning text set to "167 call is not allowed on the preconfigured group" as specified in clause 4.9 "Warning header field" and shall skip the rest of this procedure;
c) if the <entry> element of the <list> element of the <list-service> element in the group document does not contain an <mcdata-mcdata-id> element with a "uri" attribute matching the MCData ID of the originating user contained in the <mcdata-calling-user-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP INVITE request, shall send a SIP 403 (Forbidden) response with the warning text set to "116 user is not part of the MCData group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
d) if the <list-service> element contains a <mcdata-allow-file-distribution> element in the group document set to a value of "false", shall send a SIP 403 (Forbidden) response with the warning text set to "213 file distribution not allowed for this group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
e) if the <supported-services> element is not present in the group document or is present and contains a <service> element containing an "enabler" attribute which is not set to the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.fd", shall send a SIP 488 (Not Acceptable) response with the warning text set to "214 FD services not supported for this group" in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;
f) if the user identified by the MCData ID:
i) is not allowed to initiate group MCData communications on this group identity as determined by step 2) of clause 11.1, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response, with warning text set to "201 user not authorised to transmit data on this group identity" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
ii) is not allowed to initiate group MCData communications on this group identity due to exceeding the maximum amount of data that can be sent in a single request as determined by step 8) of clause 11.1, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "208 user not authorised for MCData communications on this group identity due exceeding the maximum amount of data that can be sent in a single request" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause; and
iii) is not allowed to initiate FD communications on this group identity due to file size exceeding the allowed limits as determined by step 6) of clause 11.1, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "219 user not authorised for FD communications on this group identity due to file size" in a Warning header field as specified in clause 4.9, and shall not continue with the rest of the steps in this clause;
NOTE 3: The size of the file intended for transfer over the media plane is obtained from the ‘size’ selector of the file-selector attribute in the received SDP offer.
g) if the originating user identified by the MCData ID is not affiliated to the group identity contained in the SIP INVITE request, as specified in clause 6.3.5, shall return a SIP 403 (Forbidden) response with the warning text set to "120 user is not affiliated to this group" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;
h) shall determine targeted group members for MCData communications by following the procedures in clause 6.3.4;
i) if the procedures in clause 6.3.4 result in no affiliated members found in the selected MCData group, shall return a SIP 403 (Forbidden) response with the warning text set to "198 no users are affiliated to this group" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;
j) shall invite each group member determined in step h) above, to the group session, as specified in clause 10.2.5.4.3; and
k) shall interact with the media plane as specified in 3GPP TS 24.582 [15] clause 7.3.
Upon receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 10.2.5.4.3 and, if the MCData ID in the SIP 200 (OK) response matches to the MCData ID in the corresponding SIP INVITE request, the controlling MCData function:
1) shall invoke the procedure in clause 6.3.7.1.23 with an indication that the applicable MCData subservice is File Distribution, in order to generate a SIP 200 (OK) response to the received SIP INVITE request according to 3GPP TS 24.229 [5];
2A) if the received SIP 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;
2B) if the received SIP INVITE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <imminentperil-ind> element set to a value of "true" and if the in-progress emergency state of the group is set to a value of "true", 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
3) shall send the generated SIP 200 (OK) response to the inviting MCData client according to 3GPP TS 24.229 [5].
Upon receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 10.2.5.4.3 and if the warning text set to "232 communication is stored for later delivery" is received in a Warning header field as specified in clause 4.9, the controlling MCData function:
1) shall invoke the procedure in clause 6.3.7.1.23 with an indication that the applicable MCData subservice is File Distribution, in order to generate a SIP 200 (OK) response to the receivedSIP INVITE request according to 3GPP TS 24.229 [5];
2A) if the SIP 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;
2B) if the received SIP INVITE request contains an application/vnd.3gpp.mcdata-info+xml MIME body with the <imminentperil-ind> element set to a value of "true" and if the in-progress emergency state of the group is set to a value of "true", 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
3) shall send the generated SIP 200 (OK) response to the inviting MCData client according to 3GPP TS 24.229 [5].
NOTE 4: When requested to release the associated media plane resources and to tear down the MCData session, the controlling MCData function stores the INVITE session information that is established between the participating function and the controlling function for later delivery.
10.2.5.4.5 Controlling MCData function receiving a request for upgrade to emergency of a one‑to‑one communication using FD media plane
The controlling MCData function shall execute the procedure in clause 6.3.7.1.19, with an indication that the applicable MCData subservice is File Distribution.
10.2.5.4.6 Controlling MCData function receiving a request for cancellation of an emergency one‑to‑one communication using FD media plane
The controlling MCData function shall execute the procedure in clause 6.3.7.1.20, with an indication that the applicable MCData subservice is File Distribution.
10.2.5.4.7 Controlling MCData function sending a request for upgrade to emergency of a one‑to‑one communication using FD media plane
The controlling MCData function shall execute the procedure in clause 6.3.7.1.21.
10.2.5.4.8 Controlling MCData function sending a request for cancellation of an emergency one‑to‑one communication using FD media plane
The controlling MCData function shall execute the procedure in clause 6.3.7.1.22.
10.2.6 FD using MBMS delivery via MB2 interface
The procedures for group FD using MBMS delivery via MB2 interface can be seen as extensions of group FD using unicast session for delivery via the media plane.
Group FD using MBMS enables dynamic toggling between unicast and MBMS delivery at any time during a session, assuming the proper bearers are available. Only the terminating MCData clients and the respective associated MCData terminating participating functions become aware of and involved in the potential MBMS delivery.
The terminating participating function can signal the start/stop/resume MBMS transmissions to the MCData client by using the media control plane Map Group To Bearer and Unmap Group To Bearer messages, described in 3GPP TS 24.582 [15]. The media control plane signaling associates the TMGI of an announced MBMS bearer with the MCData group ID of the communication and with the MBMS transmission parameters (IP address and UDP port).
File download completed notifications can be requested to assess if the file transfer was successful. It is up to the terminating participating function to decide whether or not to use MBMS for a session, and it is possible that the terminating participating function will not use MBMS delivery for FD unless a file repair or retransmission capability is available.