9.2 On-network SDS

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

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

9.2.1 General

9.2.1.1 Sending an SDS message

When the MCData user wishes to send:

– a one-to-one standalone Short Data Service (SDS) message to another MCData user; or

– a group standalone Short Data Service (SDS) message to a pre-arranged 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 and the size of the payload the MCData user wishes to send:

a) is less than or equal to the value contained in the <max-payload-size-sds-cplane-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12], shall follow the procedures specified in clause 9.2.2.2.1:

b) is greater than the value contained in the <max-payload-size-sds-cplane-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12], shall follow the procedures specified in clause 9.2.3.2.3.

When the MCData user wishes to:

– initiate a Short Data Service (SDS) session with another MCData user; or

– initiate a group Short Data Service (SDS) session to a pre-configured group or to particular members of the 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, shall follow the procedures specified in clause 9.2.4.2.3.

9.2.1.2 Handling of received SDS messages with or without disposition requests

When a MCData client has received a SIP request containing:

– an application/vnd.3gpp.mcdata-signalling MIME body as specified in clause E.1; and

– an application/vnd.3gpp.mcdata-payload MIME body as specified in clause E.2;

the MCData Client:

1) shall decode the contents of the application/vnd.3gpp.mcdata-signalling MIME body;

2) shall decode the contents of the application/vnd.3gpp.mcdata-payload MIME body;

3) if the SDS SIGNALLING PAYLOAD message contains a new Conversation ID, shall instantiate a new conversation with the Message ID in the SDS SIGNALLING PAYLOAD identifying the first message in the conversation thread;

4) if the SDS SIGNALLING PAYLOAD message contains an existing Conversation ID and:

a) if the SDS SIGNALLING PAYLOAD message does not contain an InReplyTo message ID, shall use the Message ID in the SDS SIGNALLING PAYLOAD to identify a new message in the existing conversation thread; and

b) if the SDS 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 SDS SIGNALLING PAYLOAD, and use the Message ID in the SDS SIGNALLING PAYLOAD to identify the new message;

5) shall identify the number of Payload IEs in the DATA PAYLOAD message from the Number of payloads IE in the DATA PAYLOAD message;

6) if the SDS 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 DATA PAYLOAD message is for user consumption

b) may notify the MCData user;

c) may display to the MCData user the functional alias of the originating MCData user, if provided; and

d) shall render the contents of the Payload IE(s) to the MCData user.

7) if the SDS SIGNALLING PAYLOAD message contains an Application ID IE:

a) shall determine that the payload contained in the DATA PAYLOAD message is not for user consumption,

b) shall not notify the MCData user;

c) if the Application ID value is unknown, shall discard the SDS message; and

d) if the Application ID value is known, shall deliver the contents of the Payload IE(s) to the identified application;

NOTE 1: If required, the MCData client decrypts the Payload IEs before rendering the SDS message to the user or delivering the SDS message to the application.

NOTE 2: The actions taken when the payload contains application data not meant for user consumption or command instructions are based upon the contents of the payload. If the payload content is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application and delivers the payload to that application.

NOTE 3: User consent is not required before accepting the data.

8) if the SDS SIGNALLING PAYLOAD message contains an Extended application ID IE:

a) shall determine that the payload contained in the DATA PAYLOAD message is not for user consumption;

b) shall not notify the MCData user;

c) if the Extended application ID value is unknown, shall discard the SDS message; and

d) if the Extended application ID value is known, shall deliver the contents of the Payload IE(s) to the identified application;

NOTE 4: If required, the MCData client decrypts the Payload IEs before rendering the SDS message to the user or delivering the SDS message to the application.

NOTE 5: The actions taken when the payload contains application data not meant for user consumption or command instructions are based upon the contents of the payload. If the payload content is addressed to a non-MCData application that is not running, the MCData client starts the local non-MCData application and delivers the payload to that application.

NOTE 6: User consent is not required before accepting the data.

9) may store the message payload in local storage along with the Conversation ID, Message ID, InReplyTo message ID and Date and time;

10) if the received SDS SIGNALLING PAYLOAD message contains an SDS disposition request type IE shall follow the procedures in clause 9.2.1.3; and

11) if the received SDS SIGNALLING PAYLOAD message contains an Application metadata container IE, may process the content of that IE per local policy.

9.2.1.3 Handling of disposition requests

To handle the disposition requests, the MCData client:

1) If the SDS disposition request type IE is set to:

a) "DELIVERY" then, shall send a delivered notification as described in clause 12.2.1.1;

b) "READ", shall send a read notification as described in clause 12.2.1.1, when a display indication is received; or

c) "DELIVERY AND READ" then, shall start timer TDU1 (delivery and read).

Upon receiving a display indication before timer TDU1 (delivery and read) expires, the MCData client:

1) shall stop timer TDU1 (delivery and read); and

2) shall send a delivered and read notification as described in clause 12.2.1.1.

Upon expiry of timer TDU1 (delivery and read), the MCData client:

1) shall send a delivered notification as described in clause 12.2.1.1; and

2) upon receiving a display indication, send a read notification as described in clause 12.2.1.1.

9.2.2 Standalone SDS using signalling control plane

9.2.2.1 General

The procedures in the clauses of the parent clause are used by a MCData functional entity to send or receive:

– a one-to-one standalone SDS message using the signalling control plane; or

– a group standalone SDS message using the signalling control plane.

9.2.2.2 MCData client procedures

9.2.2.2.1 MCData client originating procedures

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 SDS 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 an <entry> element of a <list> element of the <resource-lists> element, according to rules and procedures of IETF RFC 4826 [9];

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

c) if end-to-end security is required and the security context does not exist or if the existing security context has expired, an application/mikey MIME body with the MIKEY-SAKKE I_MESSAGE as specified in 3GPP TS 33.180 [26]. The MCData client:

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

vi) shall add the MCData ID of the originating MCData to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [26];

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

viii) shall include the MIKEY-SAKKE I_MESSAGE in an application/mikey MIME body as specified in 3GPP TS 33.180 [26];

3) if a group standalone SDS message is to be sent:

a) if the <AllowedSDS> element present in the group document of the requested MCData group as specified in 3GPP TS 24.484 [12] is set to "false", shall reject the request to send SDS and not continue with the rest of the steps in this clause; and

NOTE 1: The group document can either be known by the group management client in case of a normal group or of a temporary, or be known by the MCData client from the group regroup based on a preconfigured group procedures in case of a group regroup based on a preconfigured group.

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

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

iii) if the group identity identifies a temporary group or a group regroup based on a preconfigured group, the <anyExt> element with the <associated-group-id> element set to the MCData group ID of a constituent group the MCData client is member of;

NOTE 2: The MCData client is informed about temporary groups regrouping MCdata groups that the user is a member of as specified in 3GPP TS 24.481 [31]. The MCData client is informed about regroups based on a preconfigured group of MCData groups that the user is member of and affiliated to as specified in clause 23.

NOTE 3: If the MCData user selected a TGI or the identity of a group regroup based on a preconfigured group where there are several constituent MCData groups where the MCData user is a member, the MCData client selects one of those MCData groups.

iv) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client;

v) an <anyExt> element containing:

A) if the MCData client is aware of active functional aliases, and 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 SDS message as specified in clause 6.2.2.1; 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 SDS message.

9.2.2.2.2 MCData client terminating procedures

Upon receipt of a "SIP MESSAGE request for standalone SDS 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 toward participating MCData function with a SIP 480 (Temporarily unavailable) response and skip the rest of the steps of this clause;

3) if the SIP MESSAGE request contains an application/mikey MIME body 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 MESSAGE request with a SIP 606 (Not Acceptable) response, 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: With the PCK successfully shared between the originating MCData client and the terminating MCData client, both clients are able to exchange end-to-end secure message.

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

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

6) shall handle the received message as specified in clause 9.2.1.2.

9.2.2.3 Participating MCData function procedures

9.2.2.3.1 Originating participating MCData function procedures

Upon receipt of a "SIP MESSAGE request for standalone SDS 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 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-sds", shall determine the public service identity of the controlling MCData function associated with:

i) if present, the MCData group indentity contained in the <associated-group-is> element in an <anyExt> element of the application/vnd.3gpp.mcdata-info+xml MIME body in the SIP MESSAGE request; or

NOTE 2: If the incoming SIP MESSAGE request contains an <associated-group-id> element in an <anyExt> element of the application/vnd.3gpp.mcdata-info+xml MIME body, then the group identity contained in the <mcdata-request-uri> element is expected to be a TGI or the identity of a group regroup based on a preconfigured group and the participating MCData function forwards the request to the non-controlling function serving the constituent MCData group identity contained in the <associated-group-id> element.

ii) the MCData group identity contained 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-sds", shall determine the public service identity of the controlling MCData function hosting the one-to-one standalone SDS service for the calling user;

5) if unable to identify the controlling MCData function for standalone SDS, 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 procedures in clause 11.1 indicate that the user identified by the MCData ID:

a) is not allowed to send MCData communications as determined by step 1) of clause 11.1, shall reject the "SIP MESSAGE request for standalone SDS 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 standalone SDS 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 standalone SDS 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) if the payload size of the message is larger than the value contained in the <max-payload-size-sds-cplane-bytes> element in the MCData service configuration document as specified in 3GPP TS 24.484 [12], shall reject the "SIP MESSAGE request for standalone SDS for originating participating MCData function" with a SIP 403 (Forbidden) response to the SIP MESSAGE request, with warning text set to "203 message too large to send over signalling control plane" in a Warning header field as specified in clause 4.9;

NOTE 3: The term "payload size" refers to the "Length of Payload contents" of the payload IE of the DATA PAYLOAD message transported in the SIP MESSAGE request, minus 1 (to account for the added "Payload content type" field).

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

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

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

NOTE 5: 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 6: 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 7: 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 8: 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 copy all MIME bodies included in the incoming SIP MESSAGE request to the outgoing SIP MESSAGE 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 MESSAGE request;

12A) 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;

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

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

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

Upon receipt of a SIP 202 (Accepted) response in response to the SIP MESSAGE request in step 15):

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 15):

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 15) 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].

9.2.2.3.2 Terminating participating MCData function procedures

Upon receipt of a "SIP MESSAGE request for standalone SDS for terminating participating MCData function", the participating MCData function:

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;

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

4) shall generate an outgoing SIP MESSAGE request as specified in clause 6.3.2.1;

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

6) 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].

9.2.2.4 Controlling MCData function procedures

9.2.2.4.1 Originating controlling MCData function procedures

9.2.2.4.1.1 SIP MESSAGE targeted to an MCData clients

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 9.2.2.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.sds 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.sds" 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;

b) application/vnd.3gpp.mcdata-signalling MIME body; and

c) application/vnd.3gpp.mcdata-payload MIME body

5) in the application/vnd.3gpp.mcdata-info+xml MIME body:

a) shall set the <mcdata-request-uri> element 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-sds", shall set the <mcdata-calling-group-id> element to the group identity;

6) 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.

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

8) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; and

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

9.2.2.4.1.2 SIP MESSAGE targeted to a non-controlling MCData function

This clause describes the procedures for sending a SIP MESSAGE from the controlling MCData function to a non-controlling MCData function and is initiated by the controlling MCData function as a result of an action in clause 9.2.2.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.sds media feature tag along with the "require" and "explicit" header field parameters in accordance with 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.sds" along with parameters "require" and "explicit" in accordance with 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;

b) application/vnd.3gpp.mcdata-signalling MIME body; and

c) application/vnd.3gpp.mcdata-payload MIME body

5) in the application/vnd.3gpp.mcdata-info+xml MIME body:

a) shall set the <mcdata-request-uri> element to the group identity of the constituent group served by the non-controlling MCData function; and

b) shall set the <mcdata-calling-group-id> element to the group identity of the group served by the controlling MCData function;

6) shall set the Request-URI to the public service identity of the non-controlling MCData function associated with the constituent group;

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

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

7) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; and

8) shall send the SIP MESSAGE request in accordance with rules and procedures of 3GPP TS 24.229 [5].

9.2.2.4.2 Terminating controlling MCData function procedures

Upon receipt of a "SIP MESSAGE request for standalone SDS for controlling MCData function", 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:

a) an application/vnd.3gpp.mcdata-info+xml MIME body;

b) an application/vnd.3gpp.mcdata-signalling MIME body; and

c) an application/vnd.3gpp.mcdata-payload 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-signalling MIME body contained in the SIP MESSAGE;

4) if the application/vnd.3gpp.mcdata-signalling MIME body contains a SDS SIGNALLING PAYLOAD message with a SDS disposition request type IE, shall store the value of the Conversation ID IE and the value of the Message ID IE in the SDS SIGNALLING PAYLOAD message;

NOTE 1: The controlling MCData function uses the Conversation ID and Message ID for correlation with disposition notifications.

5) 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-sds" and:

a) the conditions in clause 11.1 indicate that the MCData user is not allowed to SDS communications due to message size as determined by step 3) 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 "218 user not authorised for one-to-one SDS communications due to message 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

b) the SIP MESSAGE request:

i) does not contain an application/resource-lists+xml MIME body or contains an application/resource-lists 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 "204 unable to determine targeted user for one-to-one SDS" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;

ii) 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":

A) shall identify the MCData ID(s) of the MCData user(s) that have activated the called functional alias received in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the SIP MESSAGE request by performing the actions specified in clause 22.2.2.2.8;

I) if unable to determine any MCData ID that has activated the called functional alias received in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the 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

II) selects one of the identified MCData IDs, and shall send a SIP 300 (Multiple Choices) response to the SIP MESSAGE request with an application/vnd.3gpp.mcdata-info MIME body containing an <mcdata-request-uri> element set to the selected MCData ID and shall not continue with the rest of the steps in this clause; and

NOTE 2: How the controlling MCData function selects the MCData ID is implementation-specific.

iii) contains an application/resource-lists+xml MIME body with exactly one <entry> element in the set of <list> elements of 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 9.2.2.4.1.1;

6) 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-sds":

a) if the group identity is associated with a group document maintained by the GMS:

NOTE 3: How the MCData server determines that a group identity represents a group for which a group document is stored in the GMS is an implementation detail.

i) 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; or

b) if the group identity is associated with a user or group regroup based on a preconfigured group:

i) shall retrieve the stored information for the group identity; and

ii) if there is no stored information for the group identity, the controlling MCData function:

A) shall return a SIP 404 (Not Found) response with the warning text set to "163 the group identity indicated in the request does not exist" as specified in clause 4.4 "Warning header field" and shall not continue with the rest of the steps;

NOTE 4: The user or group regroup can have been removed very recently and the client has sent the group call request prior to receiving the removal notification.

c) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall reject the SIP request with a SIP 403 (Forbidden) response with the warning text set to "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;

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

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

f) if the <list-service> element contains a <mcdata-allow-short-data-service> element in the group document set to a value of "false", shall send a SIP 403 (Forbidden) response with the warning text set to "206 short data service 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;

g) 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.sds", shall send a SIP 488 (Not Acceptable) response with the warning text set to "207 SDS 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;

h) if the group referred to by the group identity has been regrouped:

i) send a SIP 403 (Forbidden) response with the warning text set to "148 group is regrouped " in a Warning header field as specified in clause 4.9 and shall not continue with the rest of the steps;

ii) if the group referred to by the group identity has been regrouped based on a preconfigured group, shall send a copy of the notifying SIP MESSAGE that was generated and sent per clause 23.2.4.1 to the participating function for the MCData ID of the incoming SIP MESSAGE request; and

iii) skip the rest of the steps;

i) if the MCData server group SDS 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 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 send 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 send SDS communications on this group identity due to message size as determined by step 5) 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 "217 user not authorised for SDS communications on this group identity due to message 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;

j) if:

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

ii) the group identity contained in the SIP MESSAGE resquest refers to a user regroup based on a preconfigured group and the originating user is not a member of that user regroup; or

ii) the group identity contained in an <mcdata-calling-group-id> element of the SIP MESSAGE request is not a constituent group of the group identity contained in the SIP MESSAGE request;

NOTE 5: If the SIP MESSAGE is for a temporary group or a group regroup based on preconfigured group, the affiliation of the calling user to the constituent group has been assured by the non-controlling MCData function of the constituent group before forwarding this SIP MESSAGE to the controlling function of the regroup.

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;

k) if the group identity in the SIP MESSAGE request for standalone SDS for controlling MCData function is not a TGI nor the identity of a group regroup based on a preconfigured group:

i) shall determine the targeted group members for the MCData standalone SDS by following the procedures in clause 6.3.4;

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

iii) shall send SIP MESSAGE requests to the targeted group members identified in step h) above by following the procedure in clause 9.2.2.4.1.1; and

l) if the group identity in the SIP MESSAGE request for standalone SDS for controlling MCData function is a TGI or the identity of a group regroup based on a preconfigured group:

i) shall, for each of the constituent MCData groups except for the calling MCData group identified in the <mcdata-calling-group-id> element of the incoming SIP MESSAGE, generate a SIP INVITE request towards the MCData server that owns the constituent MCData group identity by following the procedures in clause 9.2.2.4.1.2; and

NOTE 6: The MCData server that the SIP MESSAGE request is sent to acts as a non-controlling MCData function;

7) shall generate a SIP 202 (Accepted) response in response to the "SIP MESSAGE request for standalone SDS for controlling MCData function"; and

8) shall send the SIP 202 (Accepted) response towards the originating participating or non-controlling MCData function according to 3GPP TS 24.229 [5].

9.2.2.5 Non-controlling function of an MCVideo group procedures

9.2.2.5.1 Terminating procedure

Upon receiving a SIP MESSAGE for standalone SDS from the controlling MCData function, the non-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, may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4], and shall skip the rest of the steps;

2) shall retrieve the group document associated with the group identified in the <mcdata-request-uri> element of the application/vnd.3gpp.mcdata-regroup+xml MIME body in the incoming 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;

3) shall send a SIP 200 (OK) response in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6]:

4) shall determine the targeted group members of the constituent group for the MCData standalone SDS by following the procedures in clause 6.3.4; and

5) for each of the targeted group members:

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

b) shall include an Accept-Contact header field containing the g.3gpp.mcdata.sds media feature tag along with the "require" and "explicit" header field parameters in accordance with IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;

c) 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.sds" along with parameters "require" and "explicit" in accordance with IETF RFC 3841 [8] in the outgoing SIP MESSAGE request;

d) 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:

i) application/vnd.3gpp.mcdata-info+xml MIME body;

ii) application/vnd.3gpp.mcdata-signalling MIME body; and

iii) application/vnd.3gpp.mcdata-payload MIME body

e) in the application/vnd.3gpp.mcdata-info+xml MIME body:

i) shall set the <mcdata-request-uri> element set to the MCData ID of the targeted terminating MCData user;

ii) shall set the <associated-group-id> element to the group identity of the constituent group received in the <mcdata-request-uri> element of the incoming SIP MESSAGE reqsuest; and

iii) shall set the <mcdata-calling-group-id> element to the group identity of the group regroup received in the <mcdata-calling-group-id> element of the incoming SIP MESSAGE reqsuest;

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

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

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

g) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; and

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

9.2.2.5.2 Originating procedure

Upon receiving a SIP MESSAGE for group standalone SDS from the participating MCData function, the non-controlling MCData function:

2) if the SIP MESSAGE does not contain:

a) an application/vnd.3gpp.mcdata-info+xml MIME body;

b) an application/vnd.3gpp.mcdata-signalling MIME body; and

c) an application/vnd.3gpp.mcdata-payload MIME body;

3) shall retrieve the group document associated with the group identified in the <associated-group-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming 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;

a) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true", shall reject the SIP request with a SIP 403 (Forbidden) response with the warning text set to "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;

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;

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-short-data-service> element in the group document set to a value of "false", shall send a SIP 403 (Forbidden) response with the warning text set to "206 short data service 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.sds", shall send a SIP 488 (Not Acceptable) response with the warning text set to "207 SDS 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 SDS procedures in clause 11.1 indicate that the user identified by the MCData ID:

g) if the originating user identified by the MCData ID is not affiliated to the group identity contained in the <associated-group-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming 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;

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

5) shall set the Request-URI of the outgoing SIP MESSAGE request to 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 MESSAGE request

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

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

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

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

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

6) shall copy all MIME bodies included in the incoming SIP MESSAGE request to the outgoing SIP MESSAGE request;

7) shall set the <mcdata-calling-group-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the outgoing SIP MESSAGE request to the identity of the group identified in the <associated-group-id> element of the application/vnd.3gpp.mcdata-info+xml MIME body of the incoming SIP MESSAGE request;

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

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

10) shall send the SIP MESSAGE request to the controlling MCData function as specified in 3GPP TS 24.229 [5].

Upon receipt of a SIP 4xx, 5xx or 6xx response to the SIP MESSAGE request sent to the controlling MCData function in step 10) the non-controlling MCData function:

1) shall forward the SIP response to the originating participating MCData function in accordance with 3GPP TS 24.229 [5].

Upon receipt of a SIP 202 (Accepted) response to the SIP MESSAGE request sent to the controlling MCData function in step 10) the non-controlling MCData function:

1) shall generate a SIP 202 (Accepted) response to the received SIP MESSAGE for group standalone SDS from the participating MCData function as specified in 3GPP TS 24.229 [5];

2) shall determine the targeted group members of the constituent group for the MCData standalone SDS by following the procedures in clause 6.3.4; and

3) for each of the targeted group members:

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

d) 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:

i) application/vnd.3gpp.mcdata-info+xml MIME body;

ii) application/vnd.3gpp.mcdata-signalling MIME body; and

iii) application/vnd.3gpp.mcdata-payload MIME body

e) in the application/vnd.3gpp.mcdata-info+xml MIME body:

i) shall set the <mcdata-request-uri> element set to the MCData ID of the targeted terminating MCData user;

ii) shall set the <associated-group-id> element to the group identity of the constituent group received in the <associated-group-id> element of the incoming SIP MESSAGE reqsuest; and

iii) shall set the <mcdata-calling-group-id> element to the group identity of the group regroup received in the <mcdata-request-uri> element of the incoming SIP MESSAGE reqsuest;

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

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

NOTE 7: 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 8: 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 9: 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 10: How the local MCData system routes the SIP request through an exit MCData gateway server is out of the scope of the present document.

g) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; and

h) shall send the SIP MESSAGE request in accordance with rules and procedures of 3GPP TS 24.229 [5].

9.2.3 Standalone SDS using media plane

9.2.3.1 General

The procedures in the clauses of the parent clause are used by a MCData functional entity to send or receive:

– a one-to-one standalone SDS message using the media control plane; or

– a group standalone SDS message using the media control plane.

The procedures in the clauses of the parent clause are applicable to establish an on-demand standalone SDS using media plane.

9.2.3.2 MCData client procedures

9.2.3.2.1 SDP offer generation

When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 4975 [17], 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) a format list field set to ‘*’;

d) an "a=sendonly" 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 application/vnd.3gpp.mcdata-payload"; and

g) set the a=setup attribute as "actpass"; 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].

9.2.3.2.2 SDP answer generation

When the MCData client receives an initial SDP offer for an MCData standalone SDS, the MCData client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [5] and IETF RFC 4975 [17].

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) 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 application/vnd.3gpp.mcdata-payload; and

g) set the a=setup attribute according to IETF RFC 6135 [19].

9.2.3.2.3 MCData client originating procedures

If a group standalone SDS 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 a group standalone SDS message is not allowed on the indicated group; and

2) shall skip the remainder of this procedure.

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.sds media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" 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.sds 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.sds" 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.sds" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7] in the SIP 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) if a one-to-one standalone SDS message is to be sent:

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 a <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 1: The MCData client indicates whether an MCData ID or a functional alias is to be called as specified in step 7) 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-sds"; 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; and

NOTE 2: The MCData client learns the functional aliases that are activated for an MCData ID from procedures specified in clause 22.2.1.3.

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

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

8) if a group standalone SDS message is to be sent:

a) if the "/<x>/<x>/Common/MCData/AllowedSDS" 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 to send SDS and not continue with the rest of the steps in this clause; 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-sds";

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;

NOTE 3: 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, may include 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;

9) 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 4: The MCData client is configured with public service identity identifying the participating MCData function serving the MCData user.

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

11) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in clause 9.2.3.2.1; and

12) shall send the SIP INVITE request towards the MCData server according to 3GPP TS 24.229 [5].

On receipt of a SIP 2xx response to the SIP INVITE request, the MCData client:

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

2) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38]; and

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

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

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 sending one-to-one standalone SDS message.

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

1) shall indicate to the MCData user that the SDS message could not be sent; and

2) shall send a SIP ACK request as specified in 3GPP TS 24.229 [5].

On receipt of an indication from the media plane indicating that the standalone SDS message 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].

On receipt of an indication from the media plane indicating that the standalone SDS message has been successfully transferred, 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 "200"; and

c) text set to "transmission succeeded";

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].

Upon receiving a SIP 200 (OK) response to the SIP BYE request, the MCData client shall interact with the media plane and indicate to terminate the session, as specified in 3GPP TS 24.582 [15].

9.2.3.2.4 MCData client terminating procedures

Upon receipt of a "SIP INVITE request for standalone SDS over media plane 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 either of the following conditions are met:

a) MCData client does not have enough resources to handle the call; or

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

and skip the rest of the steps after step 2;

2) if the SIP INVITE request is rejected in step 1), shall respond toward participating MCData function either with 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: 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.

3A) may display to the MCData user the MCData ID of the inviting MCData user and the type of SDS request;

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

5) shall include the option tag "timer" in a Require header field of the SIP 200 (OK) response;

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

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

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

9) 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 9.2.3.2.2; and

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

On receipt of an SIP ACK message to the sent SIP 200 (OK) message, the MCData client shall:

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

9.2.3.3 Participating MCData function procedures

9.2.3.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 SDS message 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 offer.

9.2.3.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

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.

9.2.3.3.3 Originating participating MCData function procedures

Upon receipt of a "SIP INVITE request for standalone SDS over media plane 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-sds", 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-sds", shall determine the public service identity of the controlling MCData function hosting the one-to-one standalone SDS over media plane service for the calling user;

5) if unable to identify the controlling MCData function for standalone SDS over media plane, 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

a) is authorised for MCData communications by following the procedures in clause 11.1; and

b) 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 standalone SDS over media plane 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;

7) if the procedures in clause 11.1 indicate that the user identified by the MCData ID is not allowed to initiate MCData communications, shall reject the "SIP INVITE request for standalone SDS over media plane 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;

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;

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.

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 the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" (coded as specified in 3GPP TS 24.229 [5]), into the P-Asserted-Service header field of the outgoing SIP INVITE request;

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

15) 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 9.2.3.3.1; and

16) 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 9.2.3.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.sds media feature tag;

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; 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 6.2.1.4

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].

9.2.3.3.4 Terminating participating MCData function procedures

Upon receipt of a "SIP INVITE request for standalone SDS over media plane for terminating participating MCData function", the participating MCData function:

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

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

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 accordance with 3GPP TS 24.229 [5];

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.sds media feature tag;

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

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 standalone SDS over media plane for terminating participating MCData function" as specified in clause 9.2.3.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 9.2.3.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.sds media feature tag;

b) the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds"; 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 6.2.1.5; and

10) 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 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; and

3) shall forward the SIP response to the controlling MCData function according to 3GPP TS 24.229 [5].

9.2.3.4 Controlling MCData function procedures

9.2.3.4.1 SDP offer generation

When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 4975 [17], IETF RFC 6135 [19] and IETF RFC 6714 [20] the controlling MCData function:

1) shall include an "m=message" media-level section for the MCData media stream received from the originating MCData client consisting of:

a) the port number;

b) a protocol field value of "TCP/MSRP" or "TCP/TLS/MSRP" for TLS;

c) a format list field set to ‘*’;

d) an "a=sendonly" 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 application/vnd.3gpp.mcdata-payload"; and

g) set the a=setup attribute as "actpass".

9.2.3.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 application/vnd.3gpp.mcdata-payload; and

g) set the a=setup attribute set to "passive" according to IETF RFC 6135 [19].

9.2.3.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 9.2.3.4.4.

The controlling MCData function:

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

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

b) the <mcdata-calling-group-id> element set to the group identity;

9) 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 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.

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

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

12) 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 9.2.3.4.1; and

13) 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 6.3.1.

NOTE 6: The procedures executed by the controlling MCData function prior to sending a response to the inviting MCData client are specified in clause 9.2.3.4.4.

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

Upon receipt of a "SIP INVITE request for controlling MCData function for standalone SDS over media plane", 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. 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] and skip the rest of the steps;

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

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

3) 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.sds 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.sds";

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

5) shall start the SIP Session timer according to rules and procedures of IETF RFC 4028 [38];

6) 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-sds" and the SIP INVITE 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 "204 unable to determine targeted user for one-to-one SDS" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;

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, shall reject the SIP INVITE request with a SIP 403 (Forbidden) response including warning text set to "145 unable to determine called party" in a Warning header field as specified in clause 4.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 1: How the controlling MCData function selects the appropriate MCData ID is implementation-specific.

b) 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 invite the MCData user identified by the "uri" attribute of the <entry> element in the <resource-lists> element of the application/resource-lists+xml MIME body, as specified in clause 9.2.3.4.3; and

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

7) 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-sds":

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;

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;

f) if the MCData server group SDS procedures in clause 11.1 indicate that the user identified by the MCData ID is not allowed to send 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;

g) 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 9.2.3.4.3; and

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

Upon receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 9.2.3.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 Short Data Service using media, in order to generate a SIP 200 (OK) response to the received SIP INVITE request; and

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

9.2.4 SDS session

9.2.4.1 General

The procedures in the clauses of the parent clause are used by a MCData functional entity to establish:

– a one-to-one SDS session; or

– a group SDS session.

The procedures in the clauses of the parent clause are applicable to establish an on-demand SDS session.

9.2.4.2 MCData client procedures

9.2.4.2.1 SDP offer generation

When composing an SDP offer according to 3GPP TS 24.229 [5], IETF RFC 4975 [17], 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=sendrecv" 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 application/vnd.3gpp.mcdata-payload"; and

f) set the a=setup attribute as "actpass"; and

9.2.4.2.2 SDP answer generation

When the MCData client receives an initial SDP offer for an MCData SDS session, the MCData client shall process the SDP offer and shall compose an SDP answer according to 3GPP TS 24.229 [5] and IETF RFC 4975 [17].

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=sendrecv" 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 application/vnd.3gpp.mcdata-payload; and

f) set the a=setup attribute according to IETF RFC 6135 [19].

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

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

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

7) if a one-to-one SDS session 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 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 5366 [18];

NOTE 0: The MCData client indicates whether an MCData ID or a functional alias is to be called as specified in step 7) 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-sds-session"; 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;

NOTE 0A: The MCData client learns the functional aliases that are activated for an MCData ID from procedures specified in clause 22.2.1.3.

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

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

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;

8) if a group SDS session is requested:

a1) if the group document contains a <list-service> element that contains a <preconfigured-group-use-only> element that is set to the value "true":

i) should notify the MCData user that an SDS session is not allowed on this preconfigured group; and

ii) shall skip the rest of this procedure;

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

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) if the MCData client is aware of active functional aliases, and an active functional alias is to be included in the SIP INVITE request, the <anyExt> element with the <functional-alias-URI> element set to the URI of the used functional alias;

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;

9) 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.

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

11) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in clause 9.2.4.2.1; and

12) shall send the SIP INVITE request towards the MCData server according to 3GPP TS 24.229 [5].

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

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

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 communication or if 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 6.1.2.2.

Upon receiving a SIP 300 (Multiple Choices) response to the SIP INVITE 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 an initial SIP INVITE 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 set to the value 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 with 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 with 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 sending one-to-one standalone SDS message.

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 or 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 SDS message 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 SDS message was not sent successfully, the MCData client:

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].

9.2.4.2.4 MCData client terminating procedures

Upon receipt of a "SIP INVITE request for SDS session 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 SDS session 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;