6.7 Ambient viewing call

36.579-63GPPMission Critical (MC) services over LTEPart 6: Mission Critical Video (MCVideo) User Equipment (UE) Protocol conformance specificationRelease 15TS

6.7.1 On-network / On-demand ambient viewing call / Remote initiated ambient viewing call / Client Originated (CO)

6.7.1.1 Test Purpose (TP)

(1)

with { the UE (MCVideo Client) registered and authorised for MCVideo Service, including authorised to initiate a MCVideo remote initiated ambient viewing call }

ensure that {

when { the MCVideo User requests the establishment of a MCVideo remote initiated ambient viewing call }

then { UE (MCVideo Client) sends a SIP INVITE message requesting MCVideo remote initiated ambient viewing call and responds to a SIP 200 (OK) message with a SIP ACK message and notifies the MCVideo User that the call has been successfully established }

}

(2)

with { UE (MCVideo Client) having established a MCVideo remote initiated ambient viewing call }

ensure that {

when { the MCVideo User engages in communication with the invited MCVideo User }

then { UE (MCVideo Client) respects the Transmission Control imposed by the MCVideo Server }

}

(3)

with { UE (MCVideo Client) having an ongoing MCVideo remote initiated ambient viewing call }

ensure that {

when { the MCVideo User requests to terminate the ongoing MCVideo remote initiated ambient viewing call }

then { UE (MCVideo Client) sends a SIP BYE request and after receiving a SIP 200 (OK) and leaves the MCVideo session }

}

6.7.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.281, clauses 15.2.1.1, 15.2.1.3, and in TS 24.581, clauses 6.2.5.2.3, 6.2.5.3.2, 6.2.5.3.3, 6.2.5.4.5. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated these are Rel-15 requirements.

[TS 24.281, clause 15.2.1.1]

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 a MIME resource-lists body with the MCVideo ID of the targeted MCVideo user, according to 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.7.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.

[TS 24.281, clause 15.2.1.3]

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.

[TS 24.581, clause 6.2.5.2.3]

When an MCVideo call is established, the originating transmission participant:

1. shall create an instance of a ‘Transmission participant state transition diagram for general reception control operation’; and

2. shall enter the ‘U: reception controller’ state.

NOTE: From a transmission participant perspective the MCVideo call is established when the application and signalling plane receives the SIP 200 (OK) response.

[TS 24.581, clause 6.2.5.3.2]

Upon receiving the media transmission notification from the transmission control server, the transmission participant:

1. if the first bit in the subtype of the media transmission notification message is set to ‘1’ (Acknowledgment is required) as described in subclause 9.2.2.1, shall send a Transmission control Ack message. The Transmission control Ack message:

a. shall include the Message Type field set to ‘6’ (Media transmission notification); and

b. shall include the Source field set to ‘0’ (the transmission participant is the source);

2. shall provide media transmission notification to the user;

3. shall store the User ID and the SSRC of the user transmitting the media;

4. may display the details of the incoming media to the user; and

5. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.3.3]

Upon receiving an indication from the user to request permission to receive media, the transmission participant:

1. shall send the Receive Media Request message toward the transmission control server; The Receive Media Request message:

a. if a different priority than the normal priority is required, shall include the Reception Priority field with the priority not higher than negotiated with the transmission control server as specified in subclause 14.3.3; and

b. if the receive media request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Transmission Indicator field indicating the relevant call types;

2. shall create an instance of the ‘Transmission participant state transition diagram for basic reception control operation’;

3. shall map the stored User ID and the SSRC of the user transmitting the media with instance of ‘Transmission participant state transition diagram for basic reception control operation’ created in step 2; and

4. shall remain in the ‘U: reception controller’ state.

[TS 24.581, clause 6.2.5.4.5]

Upon receiving a granted response for Receive media request message, the transmission participant:

1. if the first bit in the subtype of the Receive media response message is set to ‘1’ (Acknowledgment is required) as described in subclause 9.2.2.1, shall send a Transmission control Ack message. The Transmission control Ack message:

a. shall include the Message Type field set to ‘7’ (Receive media response); and

b. shall include the Source field set to ‘0’ (the transmission participant is the source);

2. shall provide receive media success notification to the user;

3. if the Receive Media Indicator field is included and the B-bit is set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call;

4. shall stop timer T103 (Receive Media Request); and

5. shall enter the ‘U: has permission to receive’ state.

6.7.1.3 Test description

6.7.1.3.1 Pre-test conditions

System Simulator:

– SS (MCVideo server)

– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCVideo operation in the MCVideo configuration document).

IUT:

– UE (MCVideo client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCVideo UE registration as specified in TS 36.579-1 [2], subclause 5.4.2A.

– The MCVideo User performs the Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2A.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCVideo Client Application has been activated and User has registered-in as the MCVideo User with the Server as active user at the Client

6.7.1.3.2 Test procedure sequence

Table 6.7.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Make the MCVideo User request the establishment of a MCVideo remote initiated ambient viewing call.

(NOTE 1)

2

Check: Does the UE (MCVideo Client) correctly s perform the procedure for MCVideo CO establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to establishm an MCVideo Private Call, On-demand Automatic Commencement Mode, no force of Automatic Commencement, applying End-to-End Communication Security with Transmission Control?

1

P

3-6

Void

7

Check: Does the UE (MCVideo Client provide notification to the MCVideo User that the call has been successfully established?

(NOTE 1)

1

P

8

Check: Is the test procedure MCVideo Media Transmission Notification and Request CT as described in TS 36.579-1 [2] Table 5.3B.3.3-1 correctly performed?

2

9

Check: Does the UE (MCVideo Client provide receive media success notification to the MCVideo User?

(NOTE 1)

2

P

10

Make the UE (MCVideo Client) request to end the MCVideo remote initiated ambient listening call.

(NOTE 1)

11

Check: Does the UE (MCVideo Client) correctly perform test procedure MCX CO call release as described in TS 36.579-1 [2] Table 5.3.10.3-1?

3

NOTE 1: This action is expected to be done via a suitable implementation-dependent MMI.

6.7.1.3.3 Specific message contents

Table 6.7.1.3.3-1: SIP INVITE (Step 2, Table 6.7.1.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.1-1, condition PRIVATE-CALL

Information Element

Value/remark

Comment

Reference

Condition

Priv-Answer-Mode

"Auto"

Message-body

MIME body part

SDP message

MIME-part-headers

MIME-part-body

SDP as described in Table 6.7.1.3.3-2

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.7.1.3.3-3

MIME body part

Resource-lists

MIME-part-headers

MIME-part-body

Resource-lists as described in Table 6.7.1.3.3-4

Table 6.7.1.3.3-2: SDP in SIP INVITE (Table 6.7.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition FIRST_SDP_FROM_UE, PRIVATE-CALL, INITIAL_SDP_OFFER, IMPLICIT_GRANT_REQUESTED

Table 6.7.1.3.3-3: MCVideo-Info in SIP INVITE (Table 6.7.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"ambient-viewing"

ambient-viewing-type

"remote-init"

Table 6.7.1.3.3-4: Resource-lists in SIP INVITE (Table 6.7.1.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.3.1-2, condition PRIVATE-CALL

Table 6.7.1.3.3-5: SIP 200 (OK) (Step 5, Table 6.7.1.3.2-1; Step 4, TS 36.579-1 [2] Table 5.3B.1.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.2-1, condition INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Feature-Caps

fc-value

"+g.3gpp.mcvideo.ambient-viewing-call-release"

TS 24.281 [26] clause 15.4.2

Message-body

MIME body part

SDP message

MIME-part-header

MIME-part-body

SDP as described in Table 6.7.1.3.3-7

MIME body part

MCVideo

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.7.1.3.3-8

Table 6.7.1.3.3-6: SDP in SIP 200 (OK) (Table 6.7.1.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2, condition SDP_ANSWER

Table 6.7.1.3.3-7: MCVideo-Info in SIP 200 (OK) (Table 6.7.1.3.3-6)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-2, condition PRIVATE-CALL

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"ambient-viewing"

ambient-viewing-type

"remote-init"

Table 6.7.1.3.3-8: SIP BYE (Step 11, Table 6.7.1.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3.10.3-1)

Derivation Path: TS 36.579-1, Table 5.5.2.2.1-1, condition MO_CALL

6.7.2 On-network / On-demand ambient viewing call / Remote initiated ambient viewing call / Client Terminated (CT)

6.7.2.1 Test Purpose (TP)

(1)

with { the UE (MCVideo Client) registered and authorised for MCVideo Service }

ensure that {

when { the UE (MCVideo Client) receives a SIP INVITE message to establish a MCVideo remote initiated ambient viewing call }

then { UE (MCVideo Client) sends a SIP 200 (OK) message }

}

(2)

with { UE (MCVideo Client) having an ongoing MCVideo remote initiated ambient viewing call }

ensure that {

when { UE (MCVideo Client) engages in communication with the calling MCVideo client }

then { UE (MCVideo Client) respects the Transmission Control imposed by the MCVideo Server }

}

(3)

with { UE (MCVideo Client) having an ongoing MCVideo remote initiated ambient viewing call }

ensure that {

when { UE (MCVideo Client) receives a SIP BYE message to terminate the ongoing MCVideo remote initiated ambient viewing call }

then { UE (MCVideo Client) sends a SIP 200 (OK) message and leaves the MCVideo session }

}

6.7.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.281, clauses 15.2.1.2, 15.2.1.4, and in TS 24.581, clauses 6.2.4.2.3, 6.2.4.3.3, 6.2.4.5.7. The following represents a copy/paste extraction of the requirements relevant to the test purpose; any references within the copy/paste text should be understood within the scope of the core spec they have been copied from. Unless otherwise stated these are Rel-15 requirements.

[TS 24.281, clause 15.2.1.2]

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.

[TS 24.281, clause 15.2.1.4]

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.

[TS 24.581, clause 6.2.4.2.3]

When an MCVideo call is established, the terminating transmission participant:

1. shall create an instance of a ‘Transmission participant state transition diagram for basic transmission control operation’; and

2. shall enter the ‘U: has no permission to transmit’ state.

NOTE: From a transmission participant perspective the MCVideo call is established when the application and signalling plane sends the SIP 200 (OK) response.

[TS 24.581, clause 6.2.4.3.3]

Upon receiving a Transmission Granted message from the transmission control server due to remote Transmission request, the transmission participant:

1. if the first bit in the subtype of the Transmission Granted message is set to ‘1’ (Acknowledgment is required) as described in subclause 9.2.2.1, shall send a Transmission control Ack message. The Transmission control Ack message:

a. shall include the Message Type field set to ‘1’ (Transmission Granted); and

b. shall include the Source field set to ‘0’ (the transmission participant is the source);

2. shall store the SSRC of granted transmission participant received in the Transmission Granted message and use it in the RTP media packets until the transmission is released;

3. shall provide Transmission granted notification to the user, if not already done; and

4. shall enter the ‘U: has permission to transmit’ state.

[TS 24.581, clause 6.2.4.5.7]

Upon receiving a Transmission End Request message from transmission control server, the transmission participant:

1. shall inform the user that the permission to send RTP media is being revoked;

2. may give information to the user about the reason for terminating the permission to send media;

3. shall request the media in the MCVideo client to discard any remaining buffered RTP media packets and to stop forwarding of encoded video to the MCVideo server; and

4. shall send Transmission End Response message to the transmission control server.

5. if the session is not a broadcast group call or if the A-bit in the Transmission Indicator field is set to ‘1’ (Normal call), shall enter the ‘U: has no permission to transmit’ state; and

6. if the session was initiated as a broadcast group call:

a. shall indicate to the MCVideo client the media transmission is completed; and

b shall enter the ‘Call releasing’ state.

6.7.2.3 Test description

6.7.2.3.1 Pre-test conditions

System Simulator:

– SS (MCVideo server)

– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCVideo operation in the MCVideo configuration document).

IUT:

– UE (MCVideo client)

– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.

Preamble:

– The UE has performed the Generic Test Procedure for MCVideo UE registration as specified in TS 36.579-1 [2], subclause 5.4.2A.

– The MCVideo User performs the Generic Test Procedure for MCVideo Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2A.

– UE States at the end of the preamble

– The UE is in E-UTRA Registered, Idle Mode state.

– The MCVideo Client Application has been activated and User has registered-in as the MCVideo User with the Server as active user at the Client

6.7.2.3.2 Test procedure sequence

Table 6.7.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Is the Test Procedure for MCX CT session establishment/modification without provisional responses other than 100 Trying as described in TS 36.579-1 [2] Table 5.3.4.3-1 to establishment an MCVideo remote initiated ambient viewing call with correctly performed?

1

2

The SS (MCVideo Server) sends a Transmission Granted message.

<–

Transmission Granted

3

Check: Does the UE (MCVideo Client provide transmission granted notification to the MCVideo User?

(NOTE 1)

2

F

4

Check: Is the Test Procedure MCVideo Transmission End Request CT as described in TS 36.579-1 [2] Table 5.3B.9.3-1 correctly performed?

2

5

Check: Does the UE (MCVideo Client) inform the MCVideo User that the permission to send RTP media is being revoked?

(NOTE 1)

2

F

6

Check: Is the Test Procedure for MCX CT call release as described in TS 36.579-1 [2] Table 5.3.12.3-1 to end the MCVideo Call correctly performed?

3

NOTE 1: This action is expected to be done via a suitable implementation-dependent MMI.

6.7.2.3.3 Specific message contents

Table 6.7.2.3.3-1: SIP INVITE (Step 1, Table 6.7.2.3.2-1; Step 2, TS 36.579-1 [2] Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.5.2-1, condition PRIVATE-CALL

Information Element

Value/remark

Comment

Reference

Condition

Alert-Info

"<file:///dev/null>"

Message-body

MIME body part

SDP message

MIME-part-headers

MIME-part-body

SDP as described in Table 6.7.2.3.3-2

MIME body part

MCVideo Info

MIME-part-headers

MIME-part-body

MCVideo-Info as described in Table 6.7.2.3.3-3

Table 6.7.2.3.3-2: SDP in SIP INVITE (Table 6.7.2.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2, conditions FIRST_SDP_FROM_SS, PRIVATE-CALL, SDP_OFFER

Table 6.7.2.3.3-3: MCVideo-Info in SIP INVITE (Table 6.7.2.3.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.2-2

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"ambient-viewing"

ambient-viewing-type

"remote-init"

Table 6.7.2.3.3-4: SIP 200 (OK) (Step 1, Table 6.7.2.3.2-1; Step 4, TS 36.579-1 [2], Table 5.3.4.3-1)

Derivation Path: TS 36.579-1 [2], Table 5.5.2.17.1.1-1, condition INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

Message-body

MIME body part

SDP message

MIME-part-header

MIME-part-body

SDP as described in Table 6.7.2.3.3-5

MIME body part

MCVideo

MIME-part-header

MIME-part-body

MCVideo-Info as described in Table 6.7.2.3.3-6

Table 6.7.2.3.3-5: SDP in SIP 200 (OK) (Table 6.7.2.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.1-2, condition SDP_ANSWER

Table 6.7.2.3.3-6: MCVideo-Info in SIP 200 (OK) (Table 6.7.2.3.3-4)

Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition INVITE-RSP

Information Element

Value/remark

Comment

Reference

Condition

mcvideoinfo

mcvideo-Params

session-type

"ambient-viewing"

ambient-viewing-type

"remote-init"

Table 6.7.2.3.3-7: SIP BYE (Step 11, Table 6.7.2.3.2-1)

Derivation Path: TS 36.579-1, Table 5.5.2.2.2-1, condition MT_CALL