18 Pre-established session

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

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

18.1 General

The MCData client may establish one or more pre-established sessions to the participating MCData function at any time after SIP registration and setting the service settings as defined in clause 7.2.2 or clause 7.2.3.

The MCData client may use the pre-established session for originating standalone SDS using media plane or SDS session after pre-established session establishment.

The participating MCData function may use the pre-established session for terminating standalone SDS using media plane or SDS session after pre-established session establishment.

The use of a pre-established session requires the use of resource sharing as specified in 3GPP TS 29.214 [49] and 3GPP TS 24.229 [5] by the participating MCData function. The participating MCData function use of resource sharing is defined in clause 18.2.

18.2 Participating MCData function use of resource sharing

The participating MCData function utilizes resource sharing either:

1) via the SIP core as specified in 3GPP TS 24.229 [5]; or

2) by directly interfacing to PCC to control resource sharing via the Rx reference point as specified in 3GPP TS 29.214 [49].

If resource sharing is supported then the participating MCData function may allow the use of pre-established sessions by the MCData client.

The participating MCData function can determine that the SIP core supports resource sharing from the received third-party SIP REGISTER request if the Resource-Share header field with the value "supported" is contained in the "message/sip" MIME body of the third-party SIP REGISTER request as specified in 3GPP TS 24.229 [5].

When using resource sharing the participating MCData function uses the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request to identify the MCData UE that is registering and to identify whether resource sharing and pre-established sessions can be used with a specific MCData UE.

18.3 Pre-established session for MCData SDS communication

18.3.1 General

This clause describes the procedures to establish pre-established MCData session which may be used for originating standalone SDS using media plane or SDS session. The MCData client or the participating MCData function may initiate the release of a pre-established session as defined in clause 18.3.3.

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

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

18.3.2 Session establishment

18.3.2.1 MCData client procedures

When the MCData client initiates a pre-established session the MCData client shall:

1) gather ICE candidates according to IETF RFC 8445 [77]; and

NOTE: ICE candidates are only gathered on interfaces that the MCData UE uses to obtain MCData service.

2) generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [5], with the clarifications given below.

The MCData client:

1) shall set the Request-URI of the SIP INVITE request to the public service identity of the participating MCData function serving the MCData user;

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

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

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

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

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

7) shall include the "timer" option tag in the Supported header field;

8) should include the Session-Expires header field according to IETF RFC 4028 [38] and should not include the "refresher" header field. The "refresher" header field parameter shall be set to "uac" if included;

9) shall include in the application/vnd.3gpp.mcdata-info+xml MIME body with the <mcdataInfo> element containing the <mcdata-Params> element with the <anyExt> element an <pre-established-session-ind> element set to a value of "true";

10) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in clause 18.3.1.1, and include ICE candidates in the SDP offer as per IETF RFC 8839 [78]; and

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

Upon receiving a SIP 2xx response to the SIP INVITE request the MCData client:

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

18.3.2.2 Participating MCData function procedures

Upon receipt of a "SIP INVITE request for establishing a pre-established session" the participating MCData function:

1) shall check whether the public service identity is allocated and if it is not allocated, shall return a SIP 404 (Not Found) response and skip the rest of the steps;

2) shall determine the MCData ID of the MCData user establishing the pre-established session and perform actions to verify the MCData ID of the MCData client and authorise the request according to local policy, and if not authorised, the participating MCData function shall return a SIP 403 (Forbidden) response with the warning text set to "225 User not authorized to initiate pre-established session" as specified in clause 4.9 and skip the rest of the steps;

3) shall determine whether resource sharing is supported (see clause 18.2);

4) if resource sharing is supported by the SIP core, determine that there is a binding between the MCData ID of the MCData user establishing the pre-established session and the MCData UE identified by the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request (see clause 18.2) and that this UE identity matches the identity in the "+g.3gpp.registration-token" header field parameter in the Feature-Caps header field in the "SIP INVITE request for establishing a pre-established session";

5) if resource sharing is not supported or if there is no binding between the MCData ID of the MCData user and the identity of the MCData UE identified by the "+g.3gpp.registration-token" header field parameter in the Feature-Caps header field or the participating MCData function does not support the pre-established session, then the participating MCData function shall return a SIP 403 (Forbidden) response with the warning text set to "226 function not allowed due to pre-established session not supported" as specified in clause 4.9 and skip the rest of the steps;

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

7) shall verify that the media resources are available to support the media parameters and if not shall reject the request with a SIP 500 (Server Internal Error) response, and skip the rest of the steps;

8) shall allocate a URI to be used to identify the pre-established session;

9) shall generate a SIP 200 (OK) response to the SIP INVITE request according to 3GPP TS 24.229 [5]; and

a) shall include a Contact header field containing the URI that identifies the pre-established session;

b) shall include the public service identity in the P-Asserted-Identity header field;

c) shall include a Supported header field containing the "norefersub" option tag;

d) shall if the SIP core supports resource sharing, include a Resource-Share header field answer as specified in 3GPP TS 24.229 [5] with:

A) the value "media-sharing";

B) an "origin" header field parameter set to "session-initiator";

C) a "timestamp" header field parameter; and

D) a "rules" header field parameter with one resource sharing rule per media stream in the same order the corresponding m-line appears in the SDP. Each resource sharing rule is constructed as follows:

– a "new-sharing-key" part; and

– a "directionality" part indicating the direction of the pre-established media stream; and

e) shall include an SDP answer as specified in 3GPP TS 24.229 [5] with the clarifications in clause 18.3.1.2 and include ICE candidates in the SDP answer as per IETF RFC 8839 [78];

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

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

12) shall evaluate the ICE candidates according to IETF RFC 8445 [77].

NOTE: If ICE candidate evaluation results in candidate pairs other than the default candidate pair being selected a further offer answer exchange using the procedures in clause 18.3.4 will be needed.

18.3.3 Session release

18.3.3.1 MCData client procedures

18.3.3.1.1 MCData client initiated release

NOTE: The MCData client needs to be prepared to release the pre-established session when receiving a SIP BYE request generated by the SIP core (e.g. due to network release of media plane resources).

When a MCData client needs to release a pre-established session as created in clause 18.3.2, the MCData client shall perform the procedure as described in clause 13.2.2.2.2.1.

18.3.3.1.2 Participating MCData function initiated release

Upon receiving a SIP BYE request from the participating MCData function within a pre-established session the MCData client shall check whether there are any MCData sessions using the pre-established session, and:

1) if there is an established MCData session then the MCData client shall remove the MCData client from the MCData session by performing the procedures for session release for each MCData session as specified in 3GPP TS 24.582 [15]; and

2) if there is no MCData session using the pre-established session, then the MCData client shall follow the procedure described in clause 13.2.3.2.2.

18.3.3.2 Participating MCData function procedures

18.3.3.2.1 MCData client initiated release

Upon receiving a SIP BYE request from the MCData client within a pre-established session the participating MCData function:

1) shall check whether there is a MCData session using the pre-established session, and:

a) if there is an established MCData session then the participating MCData function shall remove the MCData client from the MCData session by performing the procedures as specified in clause 13.2.2.2.3.1;

b) if there is a MCData session in the process of being established, then the participating MCData function:

i) shall send a SIP CANCEL request to cancel the MCData session in the process of being established as specified in 3GPP TS 24.229 [5]; and

ii) shall release the MCData session as specified in the clause 13.2.2.2.3.1, if a SIP 200 (OK) response for the SIP INVITE request is received from the remote side; and

c) if there is no MCData session using the pre-established session, then the participating MCData function shall:

i)_ interact with the media plane as specified in 3GPP TS 24.582 [15] for disconnecting the media plane resources towards the MCData client; and

ii) shall generate and send a SIP 200 (OK) response to the SIP BYE request according to rules and procedures of 3GPP TS 24.229 [5].

Upon receiving a SIP 200 (OK) response to the SIP BYE request from the remote side, the participating MCData function:

1) shall interact with the media plane as specified in 3GPP TS 24.582 [15] for releasing media plane resources towards the remote side;

2) shall interact with the media plane as specified in 3GPP TS 24.582 [15] for releasing media plane resources towards the MCData client; and

3) shall send a SIP 200 (OK) response to the SIP BYE request to the MCData client.

18.3.3.2.2 Participating MCData function initiated release

When a participating MCData function needs to release a pre-established session as created in clause 8.2.2, the participating MCData function:

1) shall first release any participants of all MCData calls that are using the pre-established session. The participating MCData function shall remove the MCData client from the MCData session by performing the procedures as specified in clause 13.2.2.2.3.1;

2) shall generate a SIP BYE request according to rules and procedures of 3GPP TS 24.229 [5];

3) shall set the Request-URI of the SIP BYE request to the URI that identifies the pre-established session;

4) shall send the SIP BYE request towards the MCData client within the SIP dialog of the pre-established session according to rules and procedures of the 3GPP TS 24.229 [5]; and

5) shall, upon receiving a SIP 200 (OK) response to the SIP BYE request interact with the media plane as specified in 3GPP TS 24.582 [15].

18.3.4 Session modification

18.3.4.1 MCData client procedures

18.3.4.1.1 MCData client initiated

When the MCData client needs to modify the pre-established session outside of an MCData session, the MCData client:

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

2) shall include an SDP offer according to 3GPP TS 24.229 [5] with the clarifications given in clause 18.3.1.1, and include ICE candidates in the SDP offer as per IETF RFC 8839 [78], if required; and

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

On receipt of the SIP 200 (OK) response the MCData client:

1) shall interact with the media plane as specified in 3GPP TS 24.582 [15], if there is a change in media parameters in the received SDP answer, compared to those in the previously agreed SDP; and

2) shall interact with the media plane as specified in 3GPP TS 24.582 [15], if there is a media stream, that is currently used in the pre-established session and is removed in the received SDP answer.

NOTE: The MCData client keeps resources for previously agreed media stream and media parameters until it receives a SIP 200 (OK) response.

18.3.4.1.2 MCData client receives SIP UPDATE or SIP re-INVITE request

Upon receiving a SIP UPDATE request or a SIP re-INVITE request to modify an existing pre-established session without associated MCData session, the MCData client:

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and the MSRP URI is acceptable by the MCData client and if not reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

2) shall generate a SIP 200 (OK) response as follows:

a) shall include an SDP answer according to 3GPP TS 24.229 [5] with the clarifications given in clause 18.3.1.2, and include ICE candidates in the SDP answer as per IETF RFC 8839 [78], if required; and

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

18.3.4.2 Participating MCData function procedures

18.3.4.2.1 Reception of a SIP UPDATE or SIP re-INVITE request from served MCData client

Upon receiving a SIP UPDATE request or a SIP re-INVITE request to modify an existing pre-established session without associated MCData session, the participating MCData function:

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and the MSRP URI is acceptable by the participating MCData function and if not reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps; and

2) shall generate a SIP 200 (OK) response as follows:

a) include an SDP answer according to 3GPP TS 24.229 [5] based on the received SDP offer with the clarifications given in the clause 18.3.1.2, and include ICE candidates in the SDP answer as per IETF RFC 8839 [78], if required; and

b) include a Contact header field containing the URI that identifies the pre-established session and send a SIP 200 (OK) response according to the rules and procedures of 3GPP TS 24.229 [5].

18.3.4.2.2 Participating MCData function initiated

When the participating MCData function needs to modify the pre-established session outside of an MCData session, the participating MCData function:

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

2) shall include an SDP offer according to 3GPP TS 24.229 [5], and include ICE candidates in the SDP offer as per IETF RFC 8839 [78], if required; and

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

On receipt of the SIP 200 (OK) response, the participating MCData function:

1) shall interact with the media plane as specified in 3GPP TS 24.582 [15], if there is change in media parameters or the MSRP URI in the received SDP answer, compared to those in the previously agreed SDP;

2) shall interact with the media plane as specified in 3GPP TS 24.582 [15], if there is a media stream, that is currently used in the pre-established session, is removed in the received SDP answer; and

3) shall interact with the media plane as specified in 3GPP TS 24.582 [15], if there is a media stream accepted in the received SDP answer, that is not currently used by the participant in the pre-established session.

NOTE: The participating MCData function keeps resources for previously agreed media stream, media parameters and the MSRP URI until it receives a SIP 200 (OK) response.