15 Ambient viewing call

24.2813GPPMission Critical Video (MCVideo) signalling controlProtocol specificationRelease 18TS

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

15.1 General

This clause specifies the MCVideo client procedures, participating MCVideo function procedures and controlling MCVideo function procedures for on-network ambient viewing calls. The procedures as specified are applicable to both locally initiated and remotely initiated ambient viewing call.

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

– an authorised MCVideo user initiates an ambient viewing call in order to view to the terminating user; or

– an authorised MCVideo user initiates an ambient viewing call in order to be viewed to by the terminating user.

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

– a viewing MCVideo user initiates the ambient viewing call release; or

– a viewed-to MCVideo user who was the originator of the ambient viewing call initiates the ambient viewing call release.

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

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

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

15.2 MCVideo client procedures

15.2.1 On-demand ambient viewing call

15.2.1.1 Client originating procedures for remote-initiated call

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

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

Upon receiving a request from an MCVideo user to establish an MCVideo ambient viewing call that has been authorised successfully by the requesting MCVideo client, the MCVideo client shall generate an initial SIP INVITE request by following the UE originating session procedures specified in 3GPP TS 24.229 [11], with the clarifications given below.

The MCVideo client:

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

3) shall include the g.3gpp.mcvideo media feature tag and the g.3gpp.icsi-ref media feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.mcvideo" in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [22];

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

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

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

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

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

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

9) shall insert in the SIP INVITE request an application/resource-lists+xml MIME body with the MCVideo ID of the targeted MCVideo user in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body, according to the rules and procedures of IETF RFC 5366 [37];

NOTE 1: the targeted MCVideo user is the viewed-to MCVideo user in the case of a remotely initiated ambient viewing call or the viewing MCVideo user in the case of a locally initiated viewing 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 [8];

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

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

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

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

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

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

11) shall include an SDP offer according to 3GPP TS 24.229 [11] with the clarification given in clause 6.2.1;

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

13) if this is a remotely initiated ambient viewing call, shall comply with the conditions for an implicit transmit media request control to the terminating MCVideo 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 [27]; and

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

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

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

NOTE 2: The alert-info header field having the value of "<C:\dev\nullfile:///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 viewing call, may indicate the progress of the session establishment to the inviting MCVideo user.

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

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

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

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

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

a) shall cache the value of "viewed-to MCVideo user" as the ambient viewing client role for this call; or

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

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

15.2.1.2 Client terminating procedures

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

The MCVideo client:

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

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

b) MCVideo 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 MCVideo function either with:

i) an appropriate reject code as specified in 3GPP TS 24.229 [11] 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.484 [25]; 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 MCVideo ID of the originating MCVideo from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180 [8];

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

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

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 [6], 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 [8]; and

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

NOTE 1: With the PCK successfully shared between the originating MCVideo client and the terminating MCVideo 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 [11];

5) if the received SIP INVITE request contains an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <ambient-viewing-type> element set to a value of "local-init", may display to the MCVideo user the MCVideo ID of the inviting MCVideo user;

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

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

a) shall cache the value of "viewed-to MCVideo user" as the ambient viewing client role for this call; or;

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

8) if the received SIP INVITE request includes an alert-info header field as specified in IETF RFC 3261 [15] and as updated by IETF RFC 7462 [66] set to a value of "<file:///dev/null>" shall not give any indication of the progress of the call to the MCVideo 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.

9) if the <ambient-viewing-type> element contained in the application/vnd.3gpp.mcvideo-info+xml MIME body is set to a value of "local-init", should provide an indication to the MCVideo user that the ambient viewing call is in progress; and

NOTE 4: The terminating user in a remotely initiated ambient viewing is the viewed-to MCVideo user and is intended to be totally unaware that their camera is activated and a call is in progress.

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

15.2.1.3 Client release origination procedure

Upon receiving a request from an MCVideo user to release an MCVideo ambient viewing call:

The MCVideo client:

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

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

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

then shall skip the rest of the steps;

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

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

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

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

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

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

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

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

a) ambient viewing client role; and

b) ambient viewing type.

15.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 viewing session, the MCVideo client:

1) shall comply with the procedures of clause 6.2.6;

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

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

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

a) ambient viewing client role; and

b) ambient viewing type.

15.2.2 Ambient viewing call using pre-established session

15.2.2.1 Client originating procedures

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

If an end-to-end security context needs to be established the MCVideo 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 [8];

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

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

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

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

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

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

The MCVideo 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 MCVideo server serving the MCVideo user;

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

3) shall include the Supported header field with value "norefersub" according to the rules and procedures of 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 [11];

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

7) shall set the Refer-To header field of the SIP REFER request as specified in IETF RFC 3515 [64] with a Content-ID ("cid") Uniform Resource Locator (URL) as specified in IETF RFC 2392 [49] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [37], 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 in the <resource-lists> element, where the <entry> element contains a "uri" attribute set to the MCVideo ID of the targeted user, extended with hname "body" parameter containing:

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

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

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

iii) if the MCVideo user has requested a remotely initiated ambient viewing call, an <ambient-viewing-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 [27];

c) if end-to-end security is required for the ambient viewing call, an application/sdp MIME body containing the SDP parameters of the pre-established session according to 3GPP TS 24.229 [11] with the clarification given in clause 6.2.1;

d) if this is a locally initiated ambient viewing call, shall comply with the implicit transmit media request as specified in clause 6.4; and

e) if this is a remotely initiated ambient viewing call, shall comply with the implicit transmit media reqeust to the terminating MCVideo client as specified in clause 6.4; and

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

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

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

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

On video establishment by interaction with the media plane as specified in 3GPP TS 24.581 [5] if the sent SIP REFER request the MCVideo client:

Editor’s Note [CT1#108, CR0033, C1-180501]: The call setup and release over the pre-established session need defined in the 3GPP TS 24.581 [5].

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

2) if the MCVideo user has requested a remotely initiated ambient viewing call shall provide an indication to the MCVideo user that the ambient viewing call has been successfully established;

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

a) shall cache the value of "viewed-to MCVideo user" as the ambient viewing client role for this call; or

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

15.2.2.2 Client terminating procedures

The MCVideo client shall follow the procedures for termination of multimedia sessions for ambient viewing calls as specified in clause 15.2.1.2.

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

15.2.2.3 Client release origination procedure

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

The MCVideo client:

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

b) a received SIP 200 (OK) response to a sent SIP INVITE request or SIP REFER request for the ambient viewing 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 viewing client role is equal to "viewed-to MCVideo user", shall provide no indication that an ambient viewing call has been terminated;

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

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

a) ambient viewing client role; and

b) ambient viewing type.

15.2.2.4 Reception of SIP INFO request with release-reason

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

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

2) if the cached ambient viewing client role is equal to "viewing MCVideo user", should provide an indication to the MCVideo user that an ambient viewing 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 [11]; and

4) shall comply with the procedures of clause 15.2.2.5.

15.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 viewing call but preservation of the pre-established session as specified in 3GPP TS 24.581 [5], the MCVideo client:.

Editor’s Note [CT1#108, CR0033, C1-180501]: The call setup and release over the pre-established session need defined in the 3GPP TS 24.581 [5].

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

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

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

a) ambient viewing client role; and

b) ambient viewing type.

15.3 Participating MCVideo function procedures

15.3.1 Originating procedures

15.3.1.1 On-demand ambient viewing call

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

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

NOTE 1: The MCVideo 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 MCVideo function cannot find a binding between the public user identity and an MCVideo ID or if the validity period of an existing binding has expired, then the participating MCVideo 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-viewing-type> element of the application/vnd.3gpp.mcvideo-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-viewing> element of the <ruleset> element is not present in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) or is set to a value of “false”; or

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

then shall reject the “SIP INVITE request for originating participating MCVideo function” with a SIP 403 (Forbidden) response, with warning text set to “154 The MCVideo user is not authorised to make an ambient viewing 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 MCVideo function for the ambient viewing call service associated with the originating user’s MCVideo ID identity. If the participating MCVideo function is unable to identify the controlling MCVideo function for the ambient viewing call service associated with the originating user’s MCVideo 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;

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 one or more <list> elements in the <resource-lists> element, shall reject the ”SIP INVITE request for originating participating MCVideo 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 MCVideo user profile document on the participating MCVideo function or is present with the value “false” (see the MCVideo user profile document in 3GPP TS 24.484 [25]), indicating that the user identified by the MCVideo ID is not authorised to initiate private calls, shall reject the ”SIP INVITE request for originating participating MCVideo 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 MCVideo user profile document with one or more <entry> elements (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

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

b) if configuration is not set in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) that allows the MCVideo 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 MCVideo 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 MCVideo video codec is not offered in the “SIP INVITE request for originating participating MCVideo 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 MCVideo function hosting the private call service;

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

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

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

NOTE 5: How the participating MCVideo function determines the public service identity of the controlling MCVideo function associated with the handled MCVideo group ID or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

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

13) if the Priv-Answer-Mode header field specified in IETF RFC 5373 [27] 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 MCVideo function", as specified in clause 6.3.2.1.1.1; and

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

15.3.1.2 Receipt of SIP BYE request for on-demand ambient viewing call

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

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

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

Upon receiving from the MCVideo 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 MCVideo function shall follow the procedures as specified in clause X1.

Editor’s Note [CT1#108, CR0034, C1-180568]: The procedures will defined in the future.

15.3.1.4 Ambient viewing 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 [49] that points to an application/resource-lists+xml MIME body as specified in IETF RFC 5366 [37] containing one <entry> element in a <list> element in the <resource-lists> element where the <entry> element contains a "uri" attribute containing a SIP URI set to the MCVideo ID of the called user(s);

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

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

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

2) shall determine the MCVideo 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 MCVideo function cannot find a binding between the public user identity and an MCVideo ID or if the validity period of an existing binding has expired, then the participating MCVideo 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 <entry> element in one or more <list> elements in the <resource-lists> element where each <entry> element contains an application/vnd.3gpp.mcvideo-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 a <list> element in the <rersource-lists> element where that <entry> element contains an application/vnd.3gpp.mcvideo-info MIME body with the <session-type> element not set to "ambient-viewing", 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-viewing-type> element of the application/vnd.3gpp.mcvideo-info+xml MIME body in the received SIP REFER request is set to a value of:

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

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 MCVideo user is not authorised to make an ambient viewing 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 MCVideo function for the ambient viewing call service associated with the originating user’s MCVideo ID;

NOTE 1: How the participating MCVideo server discovers the public service identity of the controlling MCVideo function associated with the ambient viewing call service of the calling user is out of scope of the current document.

9) if the participating MCVideo function is unable to identify the controlling MCVideo function for the ambient viewing call service associated with the originating user’s MCVideo 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 MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the participating MCVideo function or is present with the value "false", indicating that the user identified by the MCVideo 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 MCVideo user profile document with one or more <entry> elements (see the MCVideo user profile document in 3GPP TS 24.484 [25]) and:

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

then:

a) shall reject the "SIP INVITE request for originating participating MCVideo 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;

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 [11], IETF RFC 3515 [64] as updated by IETF RFC 6665 [16], and IETF RFC 4488 [31] 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 [11];

NOTE 2: In accordance with IETF RFC 4488 [31], the participating MCVideo 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.mcvideo.ambient-viewing-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [63];

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

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

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

Editor’s Note [CT1#108, CR0034, C1-180568]: The procedures will defined in the future.

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 MCVideo function hosting the ambient viewing call service for the calling MCVideo user as determined above in step 7); and

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

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

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

NOTE 7: How the participating MCVideo function determines the public service identity of the controlling MCVideo function associated with the handled MCVideo group ID or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

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

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

Upon receiving SIP provisional responses for the SIP INVITE request the participating MCVideo 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 MCVideo function:

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

15.3.2 Terminating procedures

15.3.2.1 Terminating procedures for ambient viewing call

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

2) shall check the presence of the isfocus media feature tag in the URI of the Contact header field and if it is not present then the participating MCVideo 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 MCVideo ID present in the <mcvideo-request-uri> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the incoming SIP INVITE request to retrieve the binding between the MCVideo ID and public user identity;

4) if the binding between the MCVideo ID and public user identity does not exist, then the participating MCVideo 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 MCVideo ID is unable to participate in private calls as identified in the called user’s MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 [25]) on the terminating participating MCVideo function, shall reject the "SIP INVITE request for terminating participating MCVideo 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 [27].

15.3.2.2 Receipt of SIP BYE request for on-demand ambient viewing call

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

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

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

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

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

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

c) shall copy the contents of the application/vnd.3gpp.mcvideo-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 MCVideo client in the dialog of the pre-established session according to 3GPP TS 24.229 [11].

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

Editor’s Note [CT1#108, CR0034, C1-180568]: The procedures will defined in the future.

15.4 Controlling MCVideo function procedures

15.4.1 Originating procedures

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

The controlling MCVideo 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 <mcvideo-calling-user-id> containing the calling user’s MCVideo ID is copied into the outgoing SIP INVITE.

2) shall copy the MCVideo ID of the MCVideo user listed in the MIME resources body of the incoming SIP INVITE request, into the <mcvideo-request-uri> element in the application/vnd.3gpp.mcvideo-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 MCVideo function associated to the MCVideo user to be invited;

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

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

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

NOTE 5: How the controlling MCVideo function determines the public service identity of the terminating participating MCVideo function associated with the handled MCVideo group ID or of the MCVideo gateway server in the interconnected MCVideo system is out of the scope of the present document.

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

4) shall copy the public user identity of the calling MCVideo 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-viewing-type> element contained in the application/vnd.3gpp.mcvideo-info+xml MIME body in the received SIP INVITE request is set to a value of "local-init", shall include the g.3gpp.mcvideo.ambient-viewing-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [63];

NOTE 4: The only case where the terminating user can release the ambient viewing call is when the terminating client is the "viewing MCVideo user";

7) if the <ambient-viewing-type> element contained in the application/vnd.3gpp.mcvideo-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 [15];

8) shall send the SIP INVITE request towards the core network according to 3GPP TS 24.229 [11]; 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 MCVideo 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.581 [5].

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

15.4.2 Terminating procedures

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

1) shall check whether the public service identity contained in the Request-URI is allocated for ambient viewing 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 MCVideo ID of the inviting MCVideo user in the <mcvideo-calling-user-id> element of the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP INVITE request, and authorise the request according to local policy;

3) if the request is not authorised as determined by step 2) above, the controlling MCVideo 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 MCVideo 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 MCVideo session identity for the MCVideo ambient viewing call session; and

7) shall invite the MCVideo user listed in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element in the application/resource-lists+xml MIME body of received SIP INVITE request as specified in clause 15.4.1.

If the procedures of clause 15.4.1 were successful in inviting the MCVideo user listed in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element in the application/resource-lists+xml MIME body of received SIP INVITE request, the controlling MCVideo 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.mcvideo.ambient-viewing-call-release feature-capability indicator as described in clause D.3 in the Feature-Caps header field according to IETF RFC 6809 [63];

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

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

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

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

a) shall cache the MCVideo ID contained in the <mcvideo-calling-user-id> element of the received SIP INVITE request as the viewing MCVideo user of the ambient viewing call and cache the MCVideo ID contained in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the received SIP INVITE request as the viewed-to MCVideo user; and

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

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

a) shall cache the MCVideo ID contained in the <mcvideo-calling-user-id> element of the received SIP INVITE request as the viewed-to MCVideo user of the ambient viewing call and cache the MCVideo ID contained in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the received SIP INVITE request as the viewing MCVideo user; and

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

If the procedures of clause 15.4.1 were not successful in inviting the MCVideo user listed in the "uri" attribute of an <entry> element of a <list> element of the <resource-lists> element of the application/resource-lists+xml MIME body of the received SIP INVITE request, the controlling MCVideo 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 MCVideo 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 [11].

15.4.3 Server initiated ambient call release

The ambient viewing call release is triggered by an MCVideo administrator by a mechanism outside of the scope of the standard, or directly by the controlling MCVideo function.

This clause is referenced from other procedures.

Upon receipt of a trigger to release an ongoing ambient viewing call identified by the MCVideo ID of the viewing MCVideo user, the MCVideo ID of the viewed-to MCVideo user and the ambient viewing type of the call, the controlling MCVideo function:

1) shall identify the MCVideo sessions of the viewing MCVideo user and the MCVideo ID of the viewed-to MCVideo user for the ambient viewing call to be released;

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

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

4) shall send the SIP BYE request in the dialog for the ambient viewing call with the MCVideo client of the viewed-to MCVideo user.

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

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

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

3) shall include an application/vnd.3gpp.mcvideo-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 MCVideo administrator;

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

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

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

4) shall send the SIP BYE requests in the dialog for the ambient viewing call with the MCVideo client of the viewing MCVideo user according to 3GPP TS 24.229 [11].

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

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

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

a) the MCVideo ID of the viewed-to MCVideo user;

b) the MCVideo ID of the viewing MCVideo user; and

c) the value of the ambient viewing type.

15.4.4 Reception of a SIP BYE request

Upon receipt of a SIP BYE request for an ambient viewing session the controlling MCVideo function:

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

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

3) shall send the SIP BYE request in the dialog of the other participant in the ambient viewing call according to 3GPP TS 24.229 [11].

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

1) shall interact with the media plane as specified in clause 6.3 in 3GPP TS 24.581 [5] for releasing media plane resources associated with the SIP session with the MCVideo ambient viewing 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 MCVideo client according to 3GPP TS 24.229 [11]; and

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

a) the MCVideo ID of the viewed-to MCVideo user;

b) the MCVideo ID of the viewing MCVideo user; and

c) the value of the ambient viewing type.