8 Pre-established session

24.3793GPPMission Critical Push To Talk (MCPTT) call controlProtocol specificationRelease 18TS

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

8.1 General

The MCPTT client may establish one or more pre-established sessions to the participating MCPTT 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 MCPTT client may use the pre-established session for originating MCPTT calls after pre-established session establishment.

The participating MCPTT function may use the pre-established session for terminating MCPTT calls after pre-established session establishment.

The MCPTT client may initiate the modification of the media parameters of a pre-established session as defined in clause 8.3.1.1.

The participating MCPTT function may initiate the modification of the media parameters of a pre-established session as defined in clause 8.3.2.2.

The MCPTT client may initiate the release of a pre-established session as defined in clause 8.4.1.1.

The participating MCPTT function may initiate the release of a pre-established session as defined in clause 8.4.2.2.

The use of a pre-established session requires the use of resource sharing as specified in 3GPP TS 29.214 [79] and 3GPP TS 24.229 [4] by the participating MCPTT function. The participating MCPTT function use of resource sharing is defined in clause 8.1A.

8.1A Participating MCPTT function use of resource sharing

The participating MCPTT function utilises resource sharing either:

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

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

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

The participating MCPTT 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 [4].

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

8.2 Session establishment

8.2.1 MCPTT client procedures

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

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

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

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

The MCPTT client:

1) shall set the Request-URI of the SIP INVITE request to the public service identity of the participating MCPTT function serving the MCPTT 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 [4];

3) shall include the g.3gpp.mcptt 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.mcptt along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

5) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in a P-Preferred-Service header field according to IETF RFC 6050 [9] 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.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

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 [7] and should not include the "refresher" header field. The "refresher" header field parameter shall be set to "uac" if included;

9) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarifications given in clause 6.2.1, and include ICE candidates in the SDP offer as per IETF RFC 8839 [90]; and

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

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

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

NOTE 2: 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 8.3 will be needed.

8.2.2 Participating MCPTT function procedures

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

1) shall check whether the public service identity is allocated and perform the actions specified in clause 6.3.7.1 if it is not allocated. Otherwise, continue with the rest of the steps;

2) shall determine the MCPTT ID of the MCPTT user establishing the pre-established session and perform actions to verify the MCPTT ID of the MCPTT client and authorise the request according to local policy, and if not authorised, the participating MCPTT function shall return a SIP 403 (Forbidden) response with the warning text set to "100 function not allowed due to <detailed reason>" as specified in clause 4.4. Otherwise, continue with the rest of the steps;

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

4) if resource sharing is supported by the SIP core, determine that there is a binding between the MCPTT ID of the MCPTT user establishing the pre-established session and the MCPTT UE identified by the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request (see clause 8.1A) 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 MCPTT ID of the MCPTT user and the identity of the MCPTT UE identified by the "+g.3gpp.registration-token" header field parameter in the Feature-Caps header field, then the participating MCPTT function shall return a SIP 403 (Forbidden) response with the warning text set to "100 function not allowed due to pre-established session not supported" as specified in clause 4.4 and not continue with the rest of the steps;

6) shall validate the media parameters and if the MCPTT speech codec is not offered in the SIP INVITE request shall reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with 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 shall not continue with 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 clause 6.3.2.1.5.2; 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 [4] 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 [4] with the clarifications in clause 6.3.2.1.2.2 and include ICE candidates in the SDP answer as per IETF RFC 8839 [90];

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

NOTE 1: Resulting media plane processing is completed before the next step is performed.

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

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

NOTE 2: 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 8.3 will be needed.

8.3 Session modification

8.3.1 MCPTT client procedures

8.3.1.1 MCPTT client initiated

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

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

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

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

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

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

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

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

8.3.1.2 Participating MCPTT function initiated

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

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec is acceptable by the MCPTT client 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) shall include an SDP answer according to 3GPP TS 24.229 [4] with the clarifications given in clause 6.2.2, and include ICE candidates in the SDP answer as per IETF RFC 8839 [90], if required.

8.3.2 Participating MCPTT function procedures

8.3.2.1 MCPTT client initiated

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

1) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec is acceptable by the participating MCPTT 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 [4] based on the received SDP offer with the clarifications given in the 6.3.2.1.2.2, and include ICE candidates in the SDP answer as per IETF RFC 8839 [90], 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 rules and procedures of 3GPP TS 24.229[4].

8.3.2.2 Participating MCPTT function initiated

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

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

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

3) shall interact with the media plane as specified in 3GPP TS 24.380 [5], if removing a media-floor control entity; and

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

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

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

3) shall interact with media plane as specified in 3GPP TS 24.380 [5], 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 MCPTT function keeps resources for previously agreed media stream, media-floor control entities, media parameters and codecs until it receives a SIP 200 (OK) response.

8.4 Session release

8.4.1 MCPTT client procedures

8.4.1.1 MCPTT client initiated

NOTE: The MCPTT 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 MCPTT client needs to release a pre-established session as created in clause 8.2.1, the MCPTT client:

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

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

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

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

8.4.1.2 Participating MCPTT function initiated

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

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

2) if there is no MCPTT call using the pre-established session, then the MCPTT client shall:

a) interact with the media plane as specified in 3GPP TS 24.380 [5] for disconnecting the media plane resources towards the participating MCPTT function; and

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

8.4.2 Participating MCPTT function procedures

8.4.2.1 MCPTT client initiated

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

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

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

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

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

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

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

i)_ interact with the media plane as specified in 3GPP TS 24.380 [5] for disconnecting the media plane resources towards the MCPTT 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 [4].

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

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

2) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for releasing media plane resources towards the MCPTT client; and

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

8.4.2.2 Participating MCPTT function initiated

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

1) shall first release any participants of all MCPTT calls that are using the pre-established session using the procedures as follows. The participating MCPTT function:

a) shall interact with the media plane as specified in clause 6.4 in 3GPP TS 24.380 [5];

b) shall generate a SIP BYE request as specified in 3GPP TS 24.229 [4];

c) shall set the Request-URI to the MCPTT session identity;

d) shall set the contents of the P-Asserted-Identity header field to the P-Asserted-Identity header field of the MCPTT client that’s pre-established session is being release;

e) shall send the SIP BYE request toward the controlling MCPTT function, according to 3GPP TS 24.229 [4]; and

f) shall, upon receiving a SIP 200 (OK) response to the SIP BYE request the terminating MCPTT function shall interact with the media plane as specified in clause 6.4 in 3GPP TS 24.380 [5];

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

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 MCPTT client within the SIP dialog of the pre-established session according to rules and procedures of the 3GPP TS 24.229 [4]; 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.380 [5].