6.4 Video Pull
36.579-63GPPMission Critical (MC) services over LTEPart 6: Mission Critical Video (MCVideo) User Equipment (UE) Protocol conformance specificationRelease 15TS
6.4.1 On-network / Video pull call / One-to-one video pull call / Client Originated (CO)
6.4.1.1 Test Purpose (TP)
(1)
with { the UE (MCVideo Client) registered and authorised for MCVideo Service }
ensure that {
when { the MCVideo User requests the establishment of an MCVideo Video Pull call to pull a video from another MCVideo client }
then { the UE (MCVideo Client) requests a video pull call by sending a SIP INVITE message and, responds to a SIP 200 (OK) message with a SIP ACK message }
}
(2)
with { the UE (MCVideo Client) having established a MCVideo Video Pull call }
ensure that {
when { the MCVideo User engages in communication with the invited MCVideo User }
then { the UE (MCVideo Client) respects the Transmission Control imposed by the SS (MCVideo Server) (Transmission Granted, Transmission Control ACK, Transmission Revoked, Transmission end request, Transmission end response, Media transmission notification, Receive Media Request, Receive media response, Media reception end request, Media reception end response, Transmission Idle) and provides appropriate notifications and information to the MCVideo User }
}
(3)
with { the UE (MCVideo Client) having an ongoing MCVideo Video Pull call }
ensure that {
when { the MCVideo User requests to terminate the ongoing MCVideo Video Pull call }
then { the UE (MCVideo Client) sends a SIP BYE message, and leaves the MCVideo Session }
}
6.4.1.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in TS 24.281, clauses 12.2.2.1, 12.2.2.3; and TS 24.581, clauses 6.2.5.3.2, 6.2.5.3.3, 6.2.5.4.5, 6.2.5.5.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 12.2.2.1]
In order to pull a video from another MCVideo client, the MCVideo client shall perform the procedures of the clause 10.2.2.2.1, with the following clarifications:
1) shall contain an application/vnd.3gpp.mcvideo-info+xml MIME body with the <mcvideoinfo> element containing the <mcvideo-Params> element with the <session-type> element set to a value of "one-to-one video pull".
[TS 24.281, clause 12.2.2.3]
When the MCVideo client is in an ongoing one-to-one video pull call, upon an indication from MCVideo user to release the call, the MCVideo client shall perform the procedures of the clause 10.2.4.1.
[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.
[TS 24.581, clause 6.2.5.5.5]
Upon receiving a Media reception end request message, the transmission participant:
1. if the first bit in the subtype of the Media reception end request message set to "1" (Acknowledgment is required) as described in subclause 8.3.2, shall send a Reception control Ack message. The Reception control Ack message:
a. shall include the Message Type field set to ‘2’ (Media reception end request);
b. shall include the Source field set to ‘0’ (the transmission participant is the source); and
c. shall include the Message Name field set to MCV2.
2. shall inform the user that the receiving RTP media is being ended;
3. may give information to the user about the reason for ending the received RTP media;
4. shall request the MCVideo client to discard any remaining buffered RTP media packets and stop displaying to user;
5. shall send a Media reception end response message towards the transmission control server;
6. may provide a Media reception end notification to the MCVideo user;
7. if the Receive Media Indicator field is included and the B-bit set to ‘1’ (Broadcast group call), shall provide a notification to the user indicating the type of call; and
8. shall enter the ‘terminated’ state.
6.4.1.3 Test description
6.4.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.4.1.3.2 Test procedure sequence
Table 6.4.1.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|---|---|---|---|---|---|
|
U – S |
Message |
||||
|
1 |
Make the MCVideo User request to initiate a video pull call to pull a video from another MCVideo client. (NOTE 1) |
– |
– |
– |
– |
|
2-6 |
Check: Does the UE (MCVideo Client) correctly perform steps 1a1 to 5 of test procedure ‘MCVideo CO session establishment/modification without provisional responses other than 100 Trying’ as described in TS 36.579-1 [2] Table 5.3B.1.3-1 to pull a video from another MCVideo client? |
– |
– |
1 |
– |
|
7 |
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 |
– |
|
8 |
Check: Is the test procedure MCVideo Media Reception End Request CT as described in TS 36.579-1 [2] Table 5.3B.10.3-1 correctly performed? |
– |
– |
2 |
– |
|
9 |
Make the UE (MCVideo Client) request to end the video pull call. (NOTE 1) |
– |
– |
– |
– |
|
10 |
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.4.1.3.3 Specific message contents
Table 6.4.1.3.3-1: SIP INVITE (Step 3, Table 6.4.1.3.2-1; Step 2, S 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 |
|
Message-body |
||||
|
MIME body part |
SDP message |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/sdp" |
|||
|
MIME-part-body |
SDP Message as described in Table 6.4.1.3.3-2 |
|||
|
MIME body part |
MCVideo Info |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/vnd.3gpp.mcvideo-info+xml" |
|||
|
MIME-part-body |
MCVideo-Info as described in Table 6.4.1.3.3-3 |
|||
|
MIME body part |
Resource list |
|||
|
MIME-part-headers |
||||
|
Content-Type |
"application/resource-lists+xml" |
|||
|
MIME-part-body |
Resource-lists as described in Table 6.4.1.3.3-4 |
|||
Table 6.4.1.3.3-2: SDP in SIP INVITE (Table 6.4.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, SDP_OFFER |
|---|
Table 6.4.1.3.3-3: MCVideo-Info in SIP INVITE (Table 6.4.1.3.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.2.1-2, condition PRIVATE-CALL, INVITE_REFER |
||||
|---|---|---|---|---|
|
Information Element |
Value/remark |
Comment |
Reference |
Condition |
|
mcvideoinfo |
||||
|
mcvideo-Params |
||||
|
session-type |
"one-to-one video pull" |
TS 24.281 [26] clause 12.2.2.1 |
||
Table 6.4.1.3.3-4: Resource-lists in SIP INVITE (Table 6.4.1.3.3-1)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.3.1-2, condition PRIVATE-CALL |
|---|
Table 6.4.1.3.3-5: SIP 200 (OK) (Step 5, Table 6.4.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 |
|
Message-body |
||||
|
SDP message |
SDP message as described in Table 6.4.1.3.3-6 |
|||
Table 6.4.1.3.3-6: SDP in SIP 200 (OK) (Table 6.4.1.3.3-5)
|
Derivation Path: TS 36.579-1 [2], Table 5.5.3.1.2-2, condition FIRST_SDP_FROM_SS, SDP_ANSWER |
|---|
Table 6.4.1.3.3-7: SIP BYE (Step 10, Table 6.4.1.3.2-1; Step 1, TS 36.579-1 [2] Table 5.3.10.3-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.2.2.1-1, condition MO_CALL |
|---|