11.1.6 Ambient listening call

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

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

11.1.6.1 General

Clause 11.1.6 specifies the MCPTT client procedures, participating MCPTT function procedures and controlling MCPTT function procedures for on-network ambient listening calls. The procedures as specified are applicable to both locally initiated and remotely initiated ambient listening call.

The procedures for originating an ambient listening call are initiated by the MCPTT user at the MCPTT client in the following circumstances:

– an authorised MCPTT user initiates an ambient listening call in order to listen to the terminating user; or

– an authorised MCPTT user initiates an ambient listening call in order to be listened to by the terminating user.

The procedures for releasing an ambient listening call are initiated by the MCPTT user at the MCPTT client in the following circumstances:

– a listening MCPTT user initiates the ambient listening call release; or

– a listened-to MCPTT user who was the originator of the ambient listening call initiates the ambient listening call release.

The procedures for releasing an ambient listening call by the controlling MCPTT function are initiated in the following circumstances:

– can be triggered by the MCPTT administrator by a mechanism outside of the scope of the standard; or

– can be triggered by a call terminating event occurring at the controlling MCPTT function such as a timer expiration.

11.1.6.2 MCPTT client procedures

11.1.6.2.0 Ambient listening handling at the MCPTT client

The MCPTT client takes the actions needed to avoid letting the user detect that an ambient listening call is active. This includes:

– avoiding that the user is aware of the beginning of an ambient listening call, except an ambient listening call initiated by the user;

– avoiding that the user is aware of the end of an ambient listening call, except an ambient listening call initiated by the user;

– avoiding that the user is aware of the ongoing progress of an ambient listening call, even an ambient listening call initiated by the user; and

– avoiding changes in the display of information, visual, audible, or haptic, that might occur or might be absent if the ambient call was not active.

11.1.6.2.1 On-demand ambient listening call

11.1.6.2.1.1 Client originating procedures

Upon receiving a request from the MCPTT user to originate a remote initiated ambient listening call, if the <allow-request-remote-initiated-ambient-listening> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false", the MCPTT client shall inform the MCPTT user and shall exit this procedure.

Upon receiving a request from the MCPTT user to originate a locally initiated ambient listening call, if the <allow-request-locally-initiated-ambient-listening> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false", the MCPTT client shall inform the MCPTT user and shall exit this procedure.

Upon receiving a request from an MCPTT user to establish an MCPTT ambient listening call that has been authorised successfully by the requesting MCPTT client, the MCPTT client shall 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 a 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 and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [16];

4) shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters 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 contain with the value of "urn:urn-7:3gpp-service.ims.icsi.mcptt" along with parameters "require" and "explicit" according to IETF RFC 3841 [6];

7) shall include an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element set to a value of "ambient-listening";

8) shall include in the application/vnd.3gpp.mcptt-info+xml MIME body an <ambient-listening-type> element set to a value of:

a) "local-init", if the MCPTT user has requested a locally initiated ambient listening call; or

b) "remote-init", if the MCPTT user has requested a remotely initiated ambient listening call;

9) shall insert in the SIP INVITE request an application/resource-lists+xml MIME body with the MCPTT ID of the targeted MCPTT user, according to rules and procedures of IETF RFC 5366 [20];

NOTE 1: the targeted MCPTT user is the listened-to MCPTT user in the case of a remotely initiated ambient listening call or the listening MCPTT user in the case of a locally initiated listening call.

10) if an end-to-end security context needs to be established then:

a) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [78];

b) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [78];

c) 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 private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [78];

d) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID and KMS URI of the invited user and a time related parameter as described in 3GPP TS 33.180 [78];

e) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [78];

f) shall add the MCPTT ID of the originating MCPTT user to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]; and

g) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCPTT 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 [78];

11) shall include an SDP offer according to 3GPP TS 24.229 [4] with the clarification given in clause 6.2.1 and with a media stream of the offered media-floor control entity;

12) if this is a locally initiated ambient listening call, shall comply with the conditions for implicit floor control as specified in clause 6.4;

13) if this is a remotely initiated ambient listening call, shall comply with the conditions for an implicit request to grant the floor to the terminating MCPTT client as specified in clause 6.4;

14) shall include in the SIP INVITE request a Priv-Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [18]; and

15) shall send the SIP INVITE request towards the participating MCPTT function according to 3GPP TS 24.229 [4].

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

1) if the SIP 183(Session Progress) response includes an alert-info header field as specified in IETF RFC 3261 [24] and as updated by IETF RFC 7462 [77] set to a value of "<file:///dev/null>" shall not give any indication of the progress of the call setup to the MCPTT user; and

NOTE 2: The alert-info header field having the value of "<file:///dev/null>" is intended to result in having a "null" alert, i.e. an alert with no content or physical manifestation of any kind.

2) if this is a remotely initiated ambient listening call, may indicate the progress of the session establishment to the inviting MCPTT user.

Upon receiving a SIP 200 (OK) response to the SIP INVITE request the MCPTT client:

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

2) if this is a remotely initiated ambient listening call, shall notify the user that the call has been successfully established;

3) if this is a locally initiated ambient listening call, shall not provide any indication to the user that the call has been successfully established;

4) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the sent SIP INVITE request was set to a value of "local-init":

a) shall cache the value of "listened-to MCPTT user" as the ambient listening client role for this call; or

b) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body was set to a value of "remote-init" shall cache the value of "listening MCPTT user" as the ambient listening client role for this call; and

5) shall cache the value contained in the <ambient-listening-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body set in step 8) as the ambient listening type of this call.

11.1.6.2.1.2 Client terminating procedures

Upon receipt of an initial SIP INVITE request, the MCPTT client shall follow the procedures for termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [4] with the clarifications below.

The MCPTT client:

1) may reject the SIP INVITE request if either of the conditions in step a) or b) are met:

a) MCPTT client is already occupied in another session and the number of simultaneous sessions exceeds <MaxCall>, the maximum simultaneous MCPTT session for private call, as specified in TS 24.384 [50]; or

b) MCPTT client does not have enough resources to handle the call;

c) if neither condition a) nor b) are met, continue with the rest of the steps;

2) if the SIP INVITE request is rejected in step 1):

a) shall respond towards the participating MCPTT function either with:

i) an appropriate reject code as specified in 3GPP TS 24.229 [4] and warning texts as specified in clause 4.4.2; or

ii) with a SIP 480 (Temporarily unavailable) response not including warning texts if the user is authorised to restrict the reason for failure according to <allow-failure-restriction> as specified in 3GPP TS 24.384 [50]; and

b) 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 MCPTT ID of the originating MCPTT user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78];

b) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.180 [78];

c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.180 [78];

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 [47], 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.4; 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 [78]; and

ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.180 [78];

NOTE 1: With the PCK successfully shared between the originating MCPTT client and the terminating MCPTT client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.

4) may check if a Resource-Priority header field is included in the incoming SIP INVITE request and may perform further actions outside the scope of this specification to act upon an included Resource-Priority header field as specified in 3GPP TS 24.229 [4];

5) shall perform the automatic commencement procedures specified in clause 6.2.3.1.1;

NOTE 2: Auto-answer is the commencement mode for both participants in locally initiated and remotely initiated ambient listening calls.

6) if the received SIP INVITE request includes an alert-info header field as specified in IETF RFC 3261 [24] and as updated by IETF RFC 7462 [77] set to a value of "<file:///dev/null>" shall not give any indication of the progress of the call to the MCPTT user;

NOTE 3: The alert-info header field having the value of "<file:///dev/null>" is intended to result in having a "null" alert, i.e. an alert with no content or physical manifestation of any kind.

7) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request was set to a value of "remote-init":

a) shall cache the value of "listened-to MCPTT user" as the ambient listening client role for this call;

NOTE 4: The terminating user in a remotely initiated ambient listening is the listened-to MCPTT user and is intended to be totally unaware that their microphone is activated and a call is in progress.

8) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request was set to a value of "local-init":

a) shall cache the value of "listening MCPTT user" as the ambient listening client role for this call;

b) should provide an indication to the MCPTT user that the ambient listening call is in progress; and

c) may display to the MCPTT user the MCPTT ID of the inviting MCPTT user; and

9) shall cache as the ambient listening type for the call the value contained in the <ambient-listening-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP INVITE request.

11.1.6.2.1.3 Client release origination procedure

Upon receiving a request from an MCPTT user to release an MCPTT ambient listening call:

The MCPTT client:

1) if the MCPTT client has not received a g.3gpp.mcptt.ambient-listening-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [60] in;

a) a received SIP INVITE request for the ambient listening call; or

b) a received SIP 200 (OK) response to a sent SIP INVITE request for the ambient listening call;

then shall skip the rest of the steps;

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

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

4) shall send the SIP BYE request within the dialog of the MCPTT ambient call session as specified in 3GPP TS 24.229 [4].

Upon receipt of the SIP 200 (OK) response to the SIP BYE request the MCPTT client:

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

2) if the cached ambient listening client role is equal to "listened-to MCPTT user", shall provide no indication that an ambient listening call has been terminated;

3) if the cached ambient listening client role is equal to "listening MCPTT user", may provide an indication to the MCPTT user that the ambient listening call has been terminated; and

4) shall clear the cache of the data stored as:

a) ambient listening client role; and

b) ambient listening type.

11.1.6.2.1.4 Client session release termination procedure

This clause is referenced from other procedures.

Upon receipt of a SIP BYE request in the dialog of an ambient listening session, the MCPTT client:

1) shall comply with the procedures of clause 6.2.6;

2) if the cached ambient listening client role is equal to "listened-to MCPTT user", shall provide no indication that an ambient listening call has been terminated;

3) if the cached ambient listening client role is equal to "listening MCPTT user", may provide an indication to the MCPTT user that the ambient listening call has been terminated; and

4) shall clear the cache of the data stored as:

a) ambient listening client role; and

b) ambient listening type.

11.1.6.2.2 Ambient listening call using pre-established session

11.1.6.2.2.1 Client originating procedures

Upon receiving a request from an MCPTT user to establish an MCPTT ambient listening call that has been authorised successfully by the requesting MCPTT client within a pre-established session, the MCPTT client shall generate a SIP REFER request outside a dialog in accordance with the procedures specified in 3GPP TS 24.229 [4], IETF RFC 4488 [22] and IETF RFC 3515 [25] as updated by IETF RFC 6665 [26] and IETF RFC 7647 [27], with the clarifications given below.

If an end-to-end security context needs to be established the MCPTT client:

1) if necessary, shall instruct the key management client to request keying material from the key management server as described in 3GPP TS 33.180 [78];

2) shall use the keying material to generate a PCK as described in 3GPP TS 33.180 [78];

3) 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 private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.180 [78];

4) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID of the invited user and a time related parameter as described in 3GPP TS 33.180 [78];

5) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.180 [78];

6) shall add the MCPTT ID of the originating MCPTT user to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [78]; and

7) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCPTT 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 [78].

The MCPTT client populates the SIP REFER request as follows:

1) shall include the Request-URI set to the public service identity identifying the pre-established session on the MCPTT server serving the MCPTT user;

2) shall include the Refer-Sub header field with value "false" according to rules and procedures of IETF RFC 4488 [22];

3) shall include the Supported header field with value "norefersub" according to rules and procedures of IETF RFC 4488 [22];

4) shall include the option tag "multiple-refer" in the Require header field;

5) may include a P-Preferred-Identity header field in the SIP REFER request containing a public user identity as specified in 3GPP TS 24.229 [4];

6) shall include a P-Preferred-Service header field set to the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), according to IETF RFC 6050 [9];

7) shall set the Refer-To header field of the SIP REFER request as specified in IETF RFC 3515 [25] with a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [62] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [20], and with the Content-ID header field set to this "cid" URL;

8) shall include in the application/resource-lists+xml MIME body a single <entry> element in a <list> element of the <resource-lists> element where the single <entry> element contains a "uri" attribute set to the MCPTT ID of the targeted user, extended with hname "body" parameter containing:

a) an application/vnd.3gpp.mcptt-info MIME body containing:

i) a <session-type> element set to "ambient-listening";

ii) if the MCPTT user has requested a locally initiated ambient listening call, an <ambient-listening-type> element set to a value of "local-init"; or

iii) if the MCPTT user has requested a remotely initiated ambient listening call, an <ambient-listening-type> element set to a value of "remote-init";

b) a Priv-Answer-Mode header field with the value "Auto" according to the rules and procedures of IETF RFC 5373 [18];

c) if the SDP parameters of the pre-established session do not contain a media-level section of a media-floor control entity or if end-to-end security is required for the ambient listening call, an application/sdp MIME body containing the SDP parameters of the pre-established session according to 3GPP TS 24.229 [4] with the clarification given in clause 6.2.1;

d) if this is a locally initiated ambient listening call, shall comply with the conditions for implicit floor control as specified in clause 6.4;

e) if this is a remotely initiated ambient listening call, shall comply with the conditions for an implicit request to grant the floor to the terminating MCPTT client as specified in clause 6.4; and

f) if implicit floor control is to be requested per clause 6.4, then:

i) the application/sdp MIME body shall contain an implicit floor request as specified in clause 6.4; and

ii) if the <allow-location-info-when-talking> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true", then shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

9) shall include a Target-Dialog header field as specified in IETF RFC 4538 [23] identifying the pre-established session.

The MCPTT client shall send the SIP REFER request towards the MCPTT server according to 3GPP TS 24.229 [4].

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

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

2) if this is a locally initiated ambient listening call, shall not provide any indication to the user that the call setup is in progress.

On call establishment by interaction with the media plane as specified in clause 9.2.2 of 3GPP TS 24.380 [5] if the sent SIP REFER request the MCPTT client:

1) if the MCPTT user has requested a locally initiated ambient listening call shall provide no indication to the MCPTT user that the ambient listening call has been successfully established; and

2) if the MCPTT user has requested a remotely initiated ambient listening call shall provide an indication to the MCPTT user that the ambient listening call has been successfully established.

3) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the sent SIP REFER request was set to a value of "local-init":

a) shall cache the value of "listened-to MCPTT user" as the ambient listening client role for this call; or

4) shall cache the value contained in the <ambient-listening-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body set in step 8) as the ambient listening type of this call.

11.1.6.2.2.2 Client terminating procedures

The MCPTT client shall follow the procedures for termination of multimedia sessions for ambient listening calls as specified in clause 11.1.6.2.1.2.

NOTE: The terminating MCPTT client in an ambient listening call receives a SIP INVITE request with Replaces header field when using a pre-established session.

11.1.6.2.2.3 Client release origination procedure

Upon receiving a request from an MCPTT user to release an MCPTT ambient listening call when using a pre-established MCPTT session:

The MCPTT client:

a) a received SIP INVITE request for the ambient listening call; or

b) a received SIP 200 (OK) response to a sent SIP INVITE request or SIP REFER request for the ambient listening call;

then shall skip the rest of the steps; and

2) shall perform the actions specified in clause 6.2.5.2.

If the procedures of clause 6.2.5.2 were successful:

1) if the cached ambient listening client role is equal to "listened-to MCPTT user", shall provide no indication that an ambient listening call has been terminated;

2) if the cached ambient listening client role is equal to "listening MCPTT user", may provide an indication to the MCPTT user that the ambient listening call has been terminated; and

3) shall clear the cache of the data stored as:

a) ambient listening client role; and

b) ambient listening type.

11.1.6.2.2.4 Reception of SIP INFO request with release-reason

Upon receiving a SIP INFO request containing an application/vnd.3gpp.mcptt-info+xml MIME body containing a <release-reason> element, the MCPTT client:

1) if the cached ambient listening client role is equal to "listened-to MCPTT user", shall provide no indication that an ambient listening call is being terminated;

2) if the cached ambient listening client role is equal to "listening MCPTT user", should provide an indication to the MCPTT user that an ambient listening call is being terminated;

3) shall generate and send a SIP 200 OK response to the SIP INFO request according to 3GPP TS 24.229 [4]; and

4) shall comply with the procedures of clause 11.1.6.2.2.5.

11.1.6.2.2.5 Client session release termination procedure

This clause is referenced from other procedures.

Upon receiving an interaction with the media plane indicating release of the ambient listening call but preservation of the pre-established session as specified in clause 9.2 of 3GPP TS 24.380 [5], the MCPTT client:

1) if the cached ambient listening client role is equal to "listened-to MCPTT user", shall provide no indication that an ambient listening call has been terminated;

2) if the cached ambient listening client role is equal to "listening MCPTT user", may provide an indication to the MCPTT user that the ambient listening call has been terminated; and

3) shall clear the cache of the data stored as:

a) ambient listening client role; and

b) ambient listening type.

11.1.6.3 Participating MCPTT function procedures

11.1.6.3.1 Originating procedures

11.1.6.3.1.1 On-demand ambient listening call

Upon receipt of a "SIP INVITE request for originating participating MCPTT function" containing an application/vnd.3gpp.mcptt-info+xml MIME body with the <session-type> element set to a value of "ambient-listening", the participating MCPTT 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 for originating participating MCPTT function" with a SIP 500 (Server Internal Error) response. The participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and shall not continue with the rest of the steps;

2) shall determine the MCPTT ID of the calling user from public user identity in the P-Asserted-Identity header field of the SIP INVITE request;

NOTE 1: The MCPTT 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 MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT 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.4, and shall not continue with any of the remaining steps;

4) if the <ambient-listening-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of:

a) "remote-init" and an <allow-request-remote-initiated-ambient-listening> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false"; or

b) "local-init" and an <allow-request-locally-initiated-ambient-listening> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) or is set to a value of "false";

then shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response, with warning text set to "user not authorised to make an ambient listening call" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

5) shall determine the public service identity of the controlling MCPTT function for the ambient listening call service associated with the originating user’s MCPTT ID identity. If the participating MCPTT function is unable to identify the controlling MCPTT function for the ambient listening call service associated with the originating user’s MCPTT ID identity, 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.4, and shall not continue with any of the remaining steps;

NOTE 2: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

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

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

NOTE 5: How the participating MCPTT function determines the public service identity of the controlling MCPTT function for the ambient listening call service associated with the originating user or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 6: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

6) if the incoming SIP INVITE request 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 all <list> elements of the <resource-lists> element, shall reject the "SIP INVITE request for originating participating MCPTT function" 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.4, and shall not continue with the rest of the steps;

7) if the <allow-private-call> element of the <ruleset> element is not present in the MCPTT user profile document on the participating MCPTT function or is present with the value "false" (see the MCPTT user profile document in 3GPP TS 24.484 [50]), indicating that the user identified by the MCPTT ID is not authorised to initiate private calls, shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response, with warning text set to "107 user not authorised to make private calls" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

8) if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) if the "uri" attribute of the <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body does not match with the "uri" attribute of one of the <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

b) if configuration is not set in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) that allows the MCPTT user to make a private call to users not contained within the <entry> elements of the <PrivateCall> element;

then:

a) shall reject the "SIP INVITE request for originating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "144 user not authorised to call this particular user" in a Warning header field as specified in clause 4.4 and shall not continue with the rest of the steps;

9) shall validate the media parameters and if the MCPTT speech codec is not offered in the "SIP INVITE request for originating participating MCPTT function" shall reject the request with a SIP 488 (Not Acceptable Here) response. Otherwise, continue with the rest of the steps;

10) shall generate a SIP INVITE request as specified in clause 6.3.2.1.3;

11) shall set the Request-URI to the public service identity of the controlling MCPTT function determined in step 5);

12) shall set the <mcptt-calling-user-id> element in an application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request to the MCPTT ID of the calling user;

13) if the Priv-Answer-Mode header field specified in IETF RFC 5373 [18] was received in the incoming SIP INVITE request with a value of "Auto" or if no Priv-Answer-Mode header field was received in the incoming SIP INVITE request or a Priv-Answer-Mode header field was received containing a value other than "Auto", shall include the Priv-Answer-Mode header field set to a value of "Auto" in the outgoing SIP INVITE request;

14) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received "SIP INVITE request for originating participating MCPTT function", as specified in clause 6.3.2.1.1.1;

15) if, according to clause 6.4, the SIP INVITE request is regarded as being received with an implicit request to grant the floor to the originating MCPTT client:

if:

a) the incoming SIP INVITE request contained an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

b) the <allow-location-info-when-talking> element of the <ruleset> element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 3GPP TS 24.484 [50]) is set to a value of "true";

then shall copy the application/vnd.3gpp.mcptt-location-info+xml MIME body from the received SIP INVITE request into the outgoing SIP INVITE request;

otherwise:

if:

a) the participating MCPTT function has available the location of the originating MCPTT client; and

then shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

16) shall forward the SIP INVITE request, according to 3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the SIP INVITE request, the participating MCPTT function:

1) shall generate a SIP 200 (OK) response as specified in the clause 6.3.2.1.5.2;

2) shall include in the SIP 200 (OK) response an SDP answer as specified in the clause 6.3.2.1.2.1;

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

4) shall include the P-Asserted-Identity header field received in the incoming SIP 200 (OK) response into the outgoing SIP 200 (OK) response;

5) shall include an MCPTT session identity mapped to the MCPTT session identity provided in the Contact header field of the received SIP 200 (OK) response;

6) shall include the answer state into the P-Answer-State header field of the outgoing SIP 200 (OK) response, if received in the P-Answer-State header field of the incoming SIP 200 (OK) response;

7) shall send the SIP 200 (OK) response to the inviting MCPTT client according to 3GPP TS 24.229 [4]; and

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

11.1.6.3.1.2 Receipt of SIP BYE request for on-demand ambient listening call

Upon receiving from the MCPTT client a SIP BYE request the participating MCPTT function:

1) shall follow the procedures as specified in clause 11.1.3.2.1.1.

11.1.6.3.1.3 Receipt of REFER "BYE" request for private call using pre-established session

Upon receiving from the MCPTT client a SIP REFER request when using a pre-established session with the "method" SIP URI parameter set to value "BYE" in the URI in the Refer-To header field the participating MCPTT function shall follow the procedures as specified in clause 6.3.2.1.7.

11.1.6.3.1.4 Ambient listening call initiation using pre-established session

Upon receipt of a "SIP REFER request for a pre-established session", with:

1) the Refer-To header field containing a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [62] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [20] containing one <entry> element in a <list> element of the <resource-lists> element with a "uri" attribute containing a SIP URI set to the MCPTT ID of the called user(s);

2) a "body" parameter of the SIP URI specified above containing an application/vnd.3gpp.mcptt-info MIME body with the <session-type> element set to "ambient-listening"; and

3) a Content-ID header field set to the "cid" URL;

the participating 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 participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24] and shall not continue with the rest of the steps;

2) shall determine the MCPTT ID of the calling user from public user identity in the P-Asserted-Identity header field of the SIP REFER request;

3) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT function shall reject the SIP REFER 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.4, and shall not continue with any of the remaining steps;

4) if the received SIP REFER request does not contain an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field, shall reject the "SIP REFER request for pre-established session" 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.4, and shall not continue with the rest of the steps;

5) if the received SIP REFER request contains an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field with more than one total <entry> element in all <lists> elements of the <resource-lists> element where each <entry> element contains an application/vnd.3gpp.mcptt-info MIME body with the <session-type> element, shall reject the "SIP REFER request for pre-established session" 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.4, and shall not continue with any of the remaining steps;

6) if the received SIP REFER request contains an application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field with only one <entry> element in all <list> elements of the <resource-lists> element where the <entry> element contains an application/vnd.3gpp.mcptt-info MIME body with the <session-type> element not set to "ambient-listening", shall reject the "SIP REFER request for pre-established session" 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.4, and shall not continue with any of the remaining steps;

7) if the <ambient-listening-type> element of the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP REFER request is set to a value of:

then shall reject the "SIP REFER request for a pre-established session" with a SIP 403 (Forbidden) response, with warning text set to "154 The MCPTT user is not authorised to make an ambient listening call" in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;

8) shall determine the public service identity of the controlling MCPTT function for the ambient listening call service associated with the originating user’s MCPTT ID;

NOTE 1: The public service identity can identify the controlling MCPTT function in the primary MCPTT system or in a partner MCPTT system.

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

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

NOTE 4: How the participating MCPTT function determines the public service identity of the controlling MCPTT function for the ambient listening call serviceassociated with the originating user or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

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

9) if the participating MCPTT function is unable to identify the controlling MCPTT function for the ambient listening call service associated with the originating user’s MCPTT ID, it shall reject the REFER 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.4, and shall not continue with any of the remaining steps;

10) if the <allow-private-call> element of the <ruleset> element is not present in the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the participating MCPTT function or is present with the value "false", indicating that the user identified by the MCPTT ID is not authorised to initiate private calls, shall reject the "SIP REFER request for pre-established session" with a SIP 403 (Forbidden) response to the SIP INVITE request, with warning text set to "107 user not authorised to make private calls" in a Warning header field as specified in clause 4.4;

11) if the <PrivateCall> element exists in the MCPTT user profile document with one or more <entry> elements (see the MCPTT user profile document in 3GPP TS 24.484 [50]) and:

a) the "uri" attribute of each and every <entry> element of all the <list> elements of the <resource-lists> element of the application/resource-lists+xml MIME body referenced by a "cid" URL in the Refer-To header field do not match with any of the <entry> elements of the <PrivateCall> element of the MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]); and

then:

12) if the "SIP REFER request for a pre-established session" contained a Refer-Sub header field containing "false" value and a Supported header field containing "norefersub" value, shall handle the SIP REFER request as specified in 3GPP TS 24.229 [4], IETF RFC 3515 [25] as updated by IETF RFC 6665 [26], and IETF RFC 4488 [22] without establishing an implicit subscription;

13) shall generate a final SIP 200 (OK) response to the "SIP REFER request for a pre-established session" according to 3GPP TS 24.229 [4];

NOTE 6: In accordance with IETF RFC 4488 [22], the participating MCPTT function inserts the Refer-Sub header field containing the value "false" in the SIP 200 (OK) response to the SIP REFER request to indicate that it has not created an implicit subscription.

14) shall include in the SIP 200 (OK) response the g.3gpp.mcptt.ambient-listening-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [60];

NOTE 7: The originator of the ambient listening call is either the initiator of a "remote-init" ambient listening type call or the originator of a "local-init" ambient listening type call. In either case, the originating user is allowed to release the ambient listening call.

15) shall send the response to the "SIP REFER request for a pre-established session" towards the MCPTT client according to 3GPP TS 24.229 [4];

16) shall generate a SIP INVITE request as specified in clause 6.3.2.1.4;

17) shall include a Priv-Answer-Mode header field set to a value of "Auto" in the outgoing SIP INVITE request;

18) shall set the Request-URI of the SIP INVITE request to the public service identity of the controlling MCPTT function as determined above in step 7);

NOTE 8: The participating MCPTT function will leave verification of the Resource-Priority header field to the controlling MCPTT function.

18a) if, according to clause 6.4, the SIP REFER request is regarded as being received with an implicit request to grant the floor to the initiating MCPTT client:

if:

a) the incoming SIP REFER request contained an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

then shall copy the application/vnd.3gpp.mcptt-location-info+xml MIME body from the received SIP REFER request into the outgoing SIP INVITE request;

otherwise:

if:

a) the participating MCPTT function has available the location of the initiating MCPTT client; and

then shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a <Report> element included in the <location-info> root element; and

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

Upon receiving SIP provisional responses for the SIP INVITE request the participating MCPTT function:

1) shall discard the received SIP responses without forwarding them.

Upon receiving a SIP 200 (OK) response for the SIP INVITE request the participating MCPTT function:

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

Upon receipt of a SIP 4xx, 5xx or 6xx response to the above SIP INVITE request in step 21) the participating MCPTT function:

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

11.1.6.3.2 Terminating procedures

11.1.6.3.2.1 Terminating procedures for ambient listening call

Upon receipt of a "SIP INVITE request for terminating participating MCPTT function", the participating MCPTT function:

NOTE: The procedures in the present clause are applicable for both on-demand and pre-established sessions.

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 for terminating participating MCPTT function" with a SIP 500 (Server Internal Error) response. The participating MCPTT function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [24], and shall not continue with the rest of the steps;

2) shall check the presence of the isfocus media feature tag in the Contact header field and if it is not present then the participating MCPTT 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.4, and shall not continue with the rest of the steps;

3) shall use the MCPTT ID present in the <mcptt-request-uri> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the incoming SIP INVITE request to retrieve the binding between the MCPTT ID and public user identity;

4) if the binding between the MCPTT ID and public user identity does not exist, then the participating MCPTT function shall reject the SIP INVITE request with a SIP 404 (Not Found) response. Otherwise, continue with the rest of the steps;

5) when the called user identified by the MCPTT ID is unable to participate in private calls as identified in the called user’s MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484 [50]) on the terminating participating MCPTT function, shall reject the "SIP INVITE request for terminating participating MCPTT function" with a SIP 403 (Forbidden) response including warning text set to "127 user not authorised to be called in private call" in a Warning header field as specified in clause 4.4; and

6) shall perform the automatic commencement procedures specified in clause 6.3.2.2.5.1 and according to IETF RFC 5373 [18].

11.1.6.3.2.2 Receipt of SIP BYE request for on-demand ambient listening call

Upon receiving a SIP BYE request from the controlling MCPTT function, the participating MCPTT function shall follow the procedures as specified in clause 11.1.3.2.2.1.

11.1.6.3.2.3 Receipt of SIP BYE request for an ongoing pre-established session

Upon receiving a SIP BYE request from the controlling MCPTT function for an ambient listening call and if the MCPTT session id refers to an MCPTT user that has a pre-established session with the participating MCPTT function, the participating MCPTT function:

1) if the SIP BYE request contains an application/vnd.3gpp.mcptt-info+xml MIME body:

a) shall generate a SIP INFO request according to rules and procedures of 3GPP TS 24.229 [4] and IETF RFC 6086 [64];

b) shall include the Info-Package header field set to g.3gpp.mcptt-info in the SIP INFO request;

c) shall copy the contents of the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP BYE request to the SIP INFO request; and

d) shall send the SIP INFO request towards the targeted MCPTT client in the dialog of the pre-established session according to 3GPP TS 24.229 [4].

Upon receiving a SIP 2xx response for the sent SIP INFO request, shall perform the procedures specified in clause 11.1.3.2.2.2.

11.1.6.4 Controlling MCPTT function procedures

11.1.6.4.1 Originating procedures

This clause describes the procedures for inviting an MCPTT user to an MCPTT ambient listening session. The procedure is initiated by the controlling MCPTT function as the result of an action in clause 11.1.6.4.2

The controlling MCPTT function:

1) shall generate a SIP INVITE request as specified in clause 6.3.3.1.2;

NOTE 1: As a result of calling clause 6.3.3.1.2, the <mcptt-calling-user-id> containing the calling user’s MCPTT ID is copied into the outgoing SIP INVITE.

2) shall copy the MCPTT ID of the MCPTT user listed in the MIME resources body of the incoming SIP INVITE request, into the <mcptt-request-uri> element in the application/vnd.3gpp.mcptt-info+xml MIME body of the outgoing SIP INVITE request;

3) shall set the Request-URI to the public service identity of the terminating participating MCPTT function associated to the MCPTT user to be invited;

NOTE 2: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

NOTE 3: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the public service identity can identify the MCPTT gateway server that acts as an entry point in the partner MCPTT system from the primary MCPTT system.

NOTE 4: If the terminating participating MCPTT function is in a partner MCPTT system in a different trust domain, then the primary MCPTT system can route the SIP request through an MCPTT gateway server that acts as an exit point from the primary MCPTT system to the partner MCPTT system

NOTE 5: How the controlling MCPTT function determines the public service identity of the terminating participating MCPTT function associated with the MCPTT user to be invited or of the MCPTT gateway server in the partner MCPTT system is out of the scope of the present document.

NOTE 6: How the primary MCPTT system routes the SIP request through an exit MCPTT gateway server is out of the scope of the present document.

4) shall copy the public user identity of the calling MCPTT user from the P-Asserted-Identity header field of the incoming SIP INVITE request into the P-Asserted-Identity header field of the SIP INVITE request;

5) shall include in the SIP INVITE request an SDP offer based on the SDP offer in the received SIP INVITE request from the originating network according to the procedures specified in clause 6.3.3.1.1;

6) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of "local-init", shall include the g.3gpp.mcptt.ambient-listening-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [60];

NOTE 7: The only case where the terminating user can release the ambient listening call is when the terminating client is the "listening MCPTT user";

7) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of "remote-init", shall include in the outgoing SIP INVITE request an alert-info header field set to a value of "<file:///dev/null>" according to IETF RFC 3261 [24];

8) shall send the SIP INVITE request towards the core network according to 3GPP TS 24.229 [4]; and

9) shall start a private call timer with a value set to the configured max private call duration for the user.

Upon receiving SIP 200 (OK) response for the SIP INVITE request the controlling MCPTT function:

1) shall cache the contact received in the Contact header field; and

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

Upon expiry of the private call timer, the controlling MCPTT function shall follow the procedure for releasing the ambient listening call session as specified in clause 11.1.6.4.3 with the clarification that the <release-reason> element included in the SIP BYE request shall be set to "private-call-timer-expiry".

11.1.6.4.2 Terminating procedures

Upon receiving of a "SIP INVITE request for controlling MCPTT function of an ambient listening call" the controlling MCPTT function:

1) shall check whether the public service identity contained in the Request-URI is allocated for ambient listening call and perform the actions specified in clause 6.3.7.1 if it is not allocated and skip the rest of the steps;

2) shall perform actions to verify the MCPTT ID of the inviting MCPTT user in the <mcptt-calling-user-id> element of the application/vnd.3gpp.mcptt-info+xml MIME body of the SIP INVITE request, and authorise the request according to local policy; and

3) if the request is not authorised as determined by step 2) above, the controlling MCPTT function shall return a SIP 403 (Forbidden) response with the warning text as specified in "Warning header field" and skip the rest of the steps;

4) shall validate that the received SDP offer includes at least one media stream for which the media parameters and at least one codec or media format is acceptable by the controlling MCPTT function and if not, reject the request with a SIP 488 (Not Acceptable Here) response and skip the rest of the steps;

5) shall perform actions as described in clause 6.3.3.2.2;

6) shall allocate an MCPTT session identity for the MCPTT ambient listening call session; and

7) shall invite the MCPTT user listed in the application/resource-lists+xml MIME body of received SIP INVITE request as specified in clause 11.1.6.4.1.

Upon receiving a SIP 183 (Session Progress) response to the SIP INVITE request specified in clause 11.1.6.4.1 containing a P-Answer-State header field with the value "Unconfirmed" as specified in IETF RFC 4964 [34], the controlling MCPTT function supports media buffering and the SIP final response is not yet sent to the inviting MCPTT client, the controlling MCPTT function:

1) shall generate a SIP 200 (OK) response to SIP INVITE request as specified in the clause 6.3.3.2.3.2;

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.1;

3) shall include a P-Answer-State header field with the value "Unconfirmed";

4) shall include in the SIP 200 (OK) response the g.3gpp.mcptt.ambient-listening-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [60];

NOTE 1: The originator of the ambient listening call is either the initiator of a "remote-init" ambient listening type call or the originator of a "local-init" ambient listening type call. In either case, the originating user is allowed to release the ambient listening call.

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

6) shall send the SIP 200 (OK) response towards the inviting MCPTT client according to 3GPP TS 24.229 [4];

7) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of "remote-init":

a) shall cache the MCPTT ID contained in the <mcptt-calling-user-id> element of the received SIP INVITE request as the listening MCPTT user of the ambient listening call and cache the MCPTT ID contained in the application/resource-lists+xml MIME body of the received SIP INVITE request as the listened-to MCPTT user; and

b) shall cache the ambient listening type of the ambient listening call as "remote-init"; and

8) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of "local-init":

a) shall cache the MCPTT ID contained in the <mcptt-calling-user-id> element of the received SIP INVITE request as the listened-to MCPTT user of the ambient listening call and cache the MCPTT ID contained in the application/resource-lists+xml MIME body of received SIP INVITE request as the listening MCPTT user; and

b) shall cache the ambient listening type of the ambient listening call as "local-init".

If the procedures of clause 11.1.6.4.1 were successful in inviting the MCPTT user listed in the application/resource-lists+xml MIME body of received SIP INVITE request and the SIP final response is not yet sent to the inviting MCPTT client, the controlling MCPTT function:

1) shall generate a SIP 200 (OK) response to the SIP INVITE request as specified in the clause 6.3.3.2.3.2 before continuing with the rest of the steps;

2) shall include in the SIP 200 (OK) response an SDP answer to the SDP offer in the incoming SIP INVITE request as specified in the clause 6.3.3.2.2;

3) shall include in the SIP 200 (OK) response the g.3gpp.mcptt.ambient-listening-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [60];

NOTE 2: The originator of the ambient listening call is either the initiator of a "remote-init" ambient listening type call or the originator of a "local-init" ambient listening type call. In either case, the originating user is allowed to release the ambient listening call.

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

5) shall send a SIP 200 (OK) response towards the inviting MCPTT client according to 3GPP TS 24.229 [4];

6) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of "remote-init":

b) shall cache the ambient listening type of the ambient listening call as "remote-init"; and

7) if the <ambient-listening-type> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body in the received SIP INVITE request is set to a value of "local-init":

b) shall cache the ambient listening type of the ambient listening call as "local-init".

If the procedures of clause 11.1.6.4.1 were not successful in inviting the MCPTT user listed in the application/resource-lists+xml MIME body of received SIP INVITE request, the controlling MCPTT function shall reject the received SIP INVITE request with a SIP 480 (Temporarily Unavailable) response and skip the remaining procedures of the present clause.

The controlling MCPTT function shall forward any other SIP response that does not contain SDP, including any MIME bodies contained therein, along the signalling path to the originating network according to 3GPP TS 24.229 [4].

11.1.6.4.3 Server initiated ambient call release

The ambient listening call release is triggered by an MCPTT administrator by a mechanism outside of the scope of the standard, or directly by the controlling MCPTT function as a result of an event as specified in clause 10.14.3.3 of 3GPP TS 23.379 [3].

This clause is referenced from other procedures.

Upon receipt of a trigger to release an ongoing ambient listening call identified by the MCPTT ID of the listening MCPTT user, the MCPTT ID of the listened-to MCPTT user and the ambient listening type of the call, the controlling MCPTT function:

1) shall identify the MCPTT sessions of the listening MCPTT user and the MCPTT ID of the listened-to MCPTT user for the ambient listening call to be released;

2) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for the MCPTT session release;

3) shall generate a SIP BYE request according to rules and procedures of 3GPP TS 24.229 [4] to be sent in the dialog for the ambient listening call with the MCPTT client of the listened-to MCPTT user; and

4) shall send the SIP BYE request in the dialog for the ambient listening call with the MCPTT client of the listened-to MCPTT user.

Upon receipt of a SIP 200 (OK) response to the SIP BYE request the controlling MCPTT function:

1) shall interact with the media plane as specified in 3GPP TS 24.380 [5] for the MCPTT session release;

2) shall generate a SIP BYE requests according to 3GPP TS 24.229 [4];

3) shall include an application/vnd.3gpp.mcptt-info+xml MIME body in the SIP BYE request including a <release-reason> element set to a value of:

a) "administrator-action" if triggered by an MCPTT administrator;

b) "private-call-expiry" if the ambient listening call is released due to the expiry of the private call timer;

c) "call-request-for-listened-to-client" if there is a call request targeted to the listened-to client; or

d) "call-request-initiated-by-listened-to-client" if there is a call request initiated by the listened-to client; and

4) shall send the SIP BYE requests in the dialog for the ambient listening call with the MCPTT client of the listening MCPTT user according to3GPP TS 24.229 [4].

Upon receipt of a SIP 200 (OK) response to the SIP BYE request sent to MCPTT client of the listening MCPTT user the controlling MCPTT function:

1) shall delete the following cached data for the ambient listening call:

a) the MCPTT ID of the listened-to MCPTT user

b) the MCPTT ID of the listening MCPTT user; and

c) the ambient listening type.

Upon receipt of a SIP 200 (OK) response to the SIP BYE request the controlling MCPTT function:

1) shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP sessions with the MCPTT clients;

2) shall delete the following cached data for the ambient listening call:

a) the MCPTT ID of the listened-to MCPTT user;

b) the MCPTT ID of the listening MCPTT user; and

c) the value of the ambient listening type.

11.1.6.4.4 Reception of a SIP BYE request

Upon receipt of a SIP BYE request for an ambient listening session the controlling MCPTT function:

1) shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.380 [5] for releasing the media plane resource associated with the SIP session towards the MCPTT client;

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

3) shall send the SIP BYE request in the dialog of the other participant in the ambient listening call according to3GPP TS 24.229 [4];

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

5) shall send the SIP BYE request in the dialog of the participant in the ambient listening call according to3GPP TS 24.229 [4].

Upon receiving a SIP 200 (OK) response to the sent SIP BYE request the controlling MCPTT function:

1) shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.380 [5] for releasing media plane resources associated with the SIP session with the MCPTT ambient listening call participant;

2) shall generate a SIP 200 (OK) response to the received SIP BYE request and send the SIP 200 (OK) response towards the MCPTT client according to 3GPP TS 24.229 [4]; and

3) shall delete the following cached data for the ambient listening call:

a) the MCPTT ID of the listened-to MCPTT user;

b) the MCPTT ID of the listening MCPTT user; and

c) the value of the ambient listening type.