20 IP Connectivity

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

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

20.1 General

This clause describes the IP Connectivity procedures between two MCData clients for on-network. Included are the procedures for MCData client procedures, participating MCData function procedures and controlling MCData function procedures.

NOTE: IP Connectivity specified in the current document is not compatible with release 16.

20.1.1 Void

20.1.2 Void

20.1.3 Void

20.2 MCData Client Procedures

20.2.0a SDP offer generation

The SDP offer shall contain one SDP media-level section for MCData including an attribute for IP Connectivity according to 3GPP TS 24.582 [15]. When composing an SDP offer the MCData client shall:

1) set the IP address of the MCData client for the offered MCData IP Connectivity session; and

NOTE: The MC service operator policy determines if the MCData client can use an already assigned IP address or can request a new IP address following the procedures defined in 3GPP TS 24.301 [43].

2) shall include an "m=application" media-level section as specified in 3GPP TS 24.582 [15] consisting of:

a) the port number selected for the media plane as specified in 3GPP TS 24.582 [15] clause 13.5; and

b) the ‘fmtp’ attribute as specified in 3GPP TS 24.582 [15] clause 13.6.

20.2.0b SDP answer generation

When the MCData client receives an initial SDP offer for a MCData including an attribute for IP Connectivity, the MCData client shall process the SDP offer and shall compose an SDP answer.

When composing an SDP answer, the MCData client:

1) shall accept the MCData media stream in the SDP offer;

2) shall set the IP address of the MCData client for the accepted MCData media stream; and

NOTE: The MC service operator policy determines if the MCData client can use an already assigned IP address or can request a new IP address following the procedures defined in 3GPP TS 24.301 [43].

3) shall include an "m=application" media-level section for the accepted MCData media stream consisting of:

a) the port number selected for the media plane as specified in 3GPP TS 24.582 [15] clause 13.5; and

b) the ‘fmtp’ attribute as specified in 3GPP TS 24.582 [15] clause 13.6.

20.2.1 MCData client originating procedures

When a MCData client receives the request by a user or user application to establish a IP Connectivity session with another MCData client the MCData client shall generate a SIP INVITE request in accordance with 3GPP TS 24.229 [5] with the clarifications given below. The MCData ID or the functional alias of the target MCData client may be explicitly included in the request from the user or user application. If the target MCData ID or functional alias is not included in the request, the MCData client may implicitly determine the target MCData ID by using the target IP Information included in the request to find a match in the One-to-One communication list of the MCData user profile document as specified in 3GPP TS 24.484 [12]. If the MCData ID of the target MCData client is determined implicitly by the target IP Information included in the request, the client searches in leaves below /<x>/<x>/Common/OnetoOne/UserList/<x>/Entry/IPInformation/<x>/Entry/ for a match in the IP Information. The MCData ID is given by matching the user entry.

The MCData client:

1) shall include the g.3gpp.mcdata.ipconn media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.ipconn " 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.ipconn 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.ipconn" 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.ipconn" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7] in the SIP INVITE request;

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

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

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

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

a) the <request-type> element set to a value of "one-to-one-ipconn"; and

b) an <anyExt> element containing:

i) the <call-to-functional-alias-ind> element set to "true" if the functional alias is used as a target of the communication request;

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

iii) 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 1: 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 20.2.0a; 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 13.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;

2) shall not include a <call-to-functional-alias-ind> element into the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body; and

3) shall include a <called-functional-alias-URI> element into the <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of the application/vnd.3gpp.mcdata-info+xml MIME body with the target functional alias used in the initial SIP INVITE request for the IP connectivity session establishment.

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

1) shall indicate to the MCData user or user application that the IP Connectivity session could not be established; 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 IP Connectivity session could not be established, the MCData client:

1) shall generate a SIP BYE request according to 3GPP TS 24.229 [5] with:

a) Reason code set to "FAILURE_CAUSE";

b) cause set to "1"; and

c) text set to "Media bearer or QoS lost";

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

20.2.2 MCData client terminating procedures

Upon receipt of a SIP INVITE request for IP Connectivity 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 either of the following conditions are met:

a) MCData client does not have enough resources to handle the IP Connectivity session; or

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

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) may provide to the MCData user or user application the MCData ID of the inviting MCData user;

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

3B) may display to the MCData user the functional alias used in the initial communication request, if provided;

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.ipconn 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.ipconn" 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 20.2.0b; 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:

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

20.3 Participating MCData function procedures

20.3.0a 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 including an attribute for IP Connectivity as contained in the received SDP offer.

When composing the SDP offer the participating MCData function:

1) shall set the IP address and port number for the offered media stream in the received SDP offer to the IP address and port number of the participating MCData function.

20.3.0b SDP answer generation

When composing the SDP answer the participating MCData function:

1) shall set the IP address and port number in the received SDP answer to the IP address and port number of the participating MCData function; and

2) shall include an ‘fmtp’ attribute as specified in 3GPP TS 24.582 [15] clause 13.6.

20.3.1 Originating participating MCData function procedures

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

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 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 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 "one-to-one-ipconn", shall determine the public service identity of the controlling MCData function hosting the one-to-one IP Connectivity service for the calling user.

5) if unable to identify the controlling MCData function for IP Connectivity session, shall reject the SIP INVITE request with a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in a Warning header field as specified in clause 4.9, and shall not continue with any of the remaining steps;

6) shall determine whether the MCData user identified by the MCData ID is authorised for MCData communications by following the procedures in clause 11.1;

7) if the procedures in clause 11.1 indicate that the user identified by the MCData ID is not allowed to initiate MCData communications, shall reject the "SIP INVITE request for IP Connectivity session 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 2: The public service identity can identify the controlling MCData function in the local MCData system or in an interconnected MCData system.

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

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

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

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

13) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.ipconn" (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 an SDP offer according to 3GPP TS 24.229 [5] based on the clause 20.3.0a;

16) if the received 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; and

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

Upon receipt of a SIP 200 (OK) response in response to the SIP INVITE request in step 16):

1) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5];

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

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

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

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

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

c) the isfocus media feature tag;

5) shall include Warning header field(s) that were received in the incoming SIP 200 (OK) response;

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

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

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

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

10) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 20.3.0b;

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

20.3.2 Terminating participating MCData function procedures

Upon receipt of a "SIP INVITE request for IP Connectivity session for terminating participating MCData function", the participating MCData function:

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;

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

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

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 according to 3GPP TS 24.229 [5] with the clarifications given in clause 20.3.0a; 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 the option tag "timer" in a Require header field;

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

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

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

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

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

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

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

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

9) 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 20.3.0b; 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].

20.4 Controlling MCData function procedures

20.4.0a SDP offer generation

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

1) the SDP offer shall contain only one SDP media-level section including an attribute for MCData IP Connectivity media stream as contained in the received SDP offer.

When composing the SDP offer the controlling MCData function:

1) shall set the IP address and port number for the offered media stream in the received SDP offer to the IP address and port number of the controlling MCData function.

20.4.0b SDP answer generation

When composing the SDP answer the controlling MCData function:

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

a) shall set the IP address and port number in the received SDP offer with the IP address and port number to the IP address and port number of the controlling MCData function; and

b) shall include an ‘fmtp’ attribute as specified in 3GPP TS 24.582 [15] clause 13.6.

20.4.1 Originating procedures

This clause describes the procedures for inviting an MCData client to an MCData session. The procedure is initiated by the controlling MCData function as the result of an action in clause 20.4.2.

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.ipconn 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.ipconn" 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.ipconn 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.ipconn" 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

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

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.ipconn" (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 according to 3GPP TS 24.229 [5] with the clarifications given in clause 20.4.0a; 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].

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

20.4.2 Terminating 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) 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 IP Connectivity session", the controlling MCData function:

1) if unable to process the request 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;

2) 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.ipconn 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.ipconn";

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

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

5) 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-ipconn" 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 "227 unable to determine targeted user for one-to-one IP Connectivity" in a Warning header field as specified in clause 4.9, and skip the rest of the steps below;

a1) contains an <anyExt> element of the <mcdata-Params> element of the <mcdatainfo> element of an application/vnd.3gpp.mcdata-info+xml MIME body with a <call-to-functional-alias-ind> element set to a value of "true":

i) shall identify the MCData ID(s) of the MCData user(s) that have activated the called functional alias received in the "uri" attribute of the <entry> element of the <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the SIP 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) shall select 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: 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 of the <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, as specified in clause 20.4.1; and

c) can interact with the media plane, in case routing or transmission control is necessary.

Upon receiving a SIP 200 (OK) response for a SIP INVITE request as specified in clause 20.4.1 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 IP Connectivity, in order to generate a SIP 200 (OK) response to the received SIP INVITE request according to 3GPP TS 24.229 [5]; and

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