12.21 MO MTSI Video call
34.229-13GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification
12.21.1 Definition
Test to verify that the UE correctly performs IMS mobile originated video call setup and release when using IMS Multimedia Telephony with preconditions. This process is described in 3GPP TS 24.229 [10], clauses 5.1.3 and 6.1, TS 24.173 [65] and TS 26.114 [66].
12.21.2 Conformance requirement
[TS 24.229, clause 6.1.1]:
The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.
In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, the UE shall not encrypt the SDP payloads.
During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to modify the session description, or when the SDP payload must be included in the message because of SIP rules described in RFC 3261.
…
For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP.
…
If the media line in the SDP indicates the usage of RTP/RTCP, and if the UE is configured to request an RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556, then in addition to the "AS" bandwidth modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 to specify the required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR: lines may include transport overhead as described in subclause 6.1 of RFC 3890.
For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will affect the assigned QoS which is defined in 3GPP TS 29.208.
NOTE 1: In a two-party session where both participants are active, the RTCP receiver reports are not sent, therefore, the RR bandwidth modifier will typically get the value of zero.
The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for audio media flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 4733.
The UE shall inspect the SDP contained in any SIP request or response, looking for possible indications of grouping of media streams according to RFC 3524 and perform the appropriate actions for IP-CAN bearer establishment for media according to IP-CAN specific procedures (see subclause B.2.2.5 for IP-CAN implemented using GPRS).
If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available.
NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.
…
[TS 24.229, clause 6.1.2]:
An INVITE request generated by a UE shall contain a SDP offer and at least one media description. The SDP offer shall reflect the calling user’s terminal capabilities and user preferences for the session.
If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the SDP offer, the UE shall:
– indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1); and,
– set the related media streams to inactive, by including an "a=inactive" line, according to the procedures described in RFC 4566, unless the UE knows that the precondition mechanism is supported by the remote UE.
NOTE 1: When setting the media streams to the inactive mode, the UE can include in the first SDP offer the proper values for the RS and RR modifiers and associate bandwidths to prevent the receiving of the RTCP packets, and not send any RTCP packets.
If the desired QoS resources for one or more media streams are available at the UE when the initial SDP offer is sent, the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1).
NOTE 2: If the originating UE does not support the precondition mechanism it will not include any precondition information in SDP.
…
Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, as described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the allowed media types, codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses related to the same session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). The UE shall order the codecs in the SDP payload according to the order of the codecs in the SDP payload of the 488 (Not Acceptable Here) response.
NOTE 3: The UE can attempt a session establishment through multiple networks with different policies and potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) responses from different CSCF nodes. The UE therefore takes into account the SDP contents of all the 488 (Not Acceptable Here) responses received related to the same session establishment when building a new INVITE request.
Upon confirming successful local resource reservation, the UE shall create a SDP offer in which:
– the related local preconditions are set to meet, using the segmented status type, as defined in RFC 3312 and RFC 4032; and
– the media streams previously set to inactive mode are set to active (sendrecv, sendonly or recvonly) mode.
Upon receiving an SDP answer, which includes more than one codec for one or more media streams, the UE shall send an SDP offer at the first possible time, selecting only one codec per media stream.
[TS 26.114 Rel-8, clause 5.2.2]
MTSI clients in terminals offering video communication shall support:
– ITU-T Recommendation H.263 [22] Profile 0 Level 45.
In addition they should support:
– ITU-T Recommendation H.263 [22] Profile 3 Level 45;
– MPEG-4 (Part 2) Visual [23] Simple Profile Level 3with the following constraints:
– Number of Visual Objects supported shall be limited to 1.
– The maximum frame rate shall be 30 frames per second.
– The maximum f_code shall be 2.
– The intra_dc_vlc_threshold shall be 0.
– The maximum horizontal luminance pixel resolution shall be 352 pels/line.
– The maximum vertical luminance pixel resolution shall be 288 pels/VOP.
– If AC prediction is used, the following restriction applies: QP value shall not be changed within a VOP (or within a video packet if video packets are used in a VOP). If AC prediction is not used, there are no restrictions to changing QP value.
– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Baseline Profile Level 1.1 with constraint_set1_flag=1 and without requirements on output timing conformance (annex C of [24]). Each sequence parameter set of H.264 (AVC) shall contain the vui_parameters syntax structure including the num_reorder_frames syntax element set equal to 0.
[TS 26.114 Rel-10, clause 5.2.2]
MTSI clients in terminals offering video communication shall support:
– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Constrained Baseline Profile (CBP) Level 1.2.
In addition they should support:
– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Constrained Baseline Profile Level 3.1.
In addition they may support:
– ITU-T Recommendation H.263 [22] Profile 0 Level 45.
[TS 26.114, clause 6.2.1a2]:
For voice and real-time text, SDPCapNeg shall be used when offering AVPF the first time for a new media type in the session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client shall either offer AVPF and AVP together using SDPCapNeg, or the MTSI client shall offer only AVPF, without using SDPCapNeg. If an MTSI client has offered only AVPF for video, and then receives as response either an SDP answer where the video media component has been rejected, or an SIP 488 or 606 failure response with an SDP body indicating that only AVP is supported for video media, the MTSI client should send a new SDP offer with AVP as transport for video. Subsequent SDP offers, in a re-INVITE or UPDATE, may offer AVPF without SDPCapNeg if it is known from an earlier re-INVITE or UPDATE that the answering client supports this RTP profile. If the offer includes only AVP then SDPCapNeg does not need to be used, which can occur for: text; speech if RTCP is not used; and in re-INVITEs or UPDATEs where the RTP profile has already been negotiated for the session in a preceding INVITE or UPDATE.
When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:
– The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF shall be preferred over AVP.
– At least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.
[TS 26.114, clause 6.2.3]:
If video is used in a session, the session setup shall determine the bandwidth, RTP profile, video codec, profile and level. The "imageattr" attribute as specified in [76] should be supported.
An MTSI client shall offer AVPF for all media streams containing video. RTP profile negotiation shall be done as described in clause 6.2.1a.
Examples of SDP offers and answers for video can be found in clause A.4.
NOTE: For H.264 / MPEG-4 (Part 10) AVC, the optional max-rcmd-nalu-size receiver-capability parameter of RFC 3984 [25] should be set to the smaller of the MTU size (if known) minus header size or 1 400 bytes (otherwise).
[TS 26.114, clause 7.3.1]:
The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers at media level, as specified by RFC 3556. Therefore, an MTSIclient shall include the "b=RS:" and "b=RR:" fields in SDP, and shall be able to interpret them. There shall be an upper limit on the allowed RTCP bandwidth for each RTP session signalled by the MTSI client. This limit is defined as follows:
– 4 000 bps for the RS field (at media level);
– 3 000 bps for the RR field (at media level).
Reference(s)
3GPP TS 24.229 [10], clauses 6.1.1 and 6.1.2, and TS 26.114 [66], clauses 5.2.2, 6.2.1a2, 6.2.3 and 7.3.1.
12.21.3 Test purpose
1) To verify that when initiating MO video call the UE performs correct exchange of SIP protocol signalling messages for setting up the session; and
2) To verify that within SIP signalling the UE performs the correct exchange of SDP messages for negotiating media and indicating preconditions for resource reservation (as described by 3GPP TS 24.229 [10], clause 6.1).
3) To verify that the UE is able to release the video call.
12.21.4 Method of test
Initial conditions
UE contains either SIM application (GIBA), ISIM and USIM applications or only USIM application on UICC. UE has discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 or C.2a (GIBA only) up to the last step.
SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE. SS has performed AKAv1-MD5 authentication with the UE and accepted the registration (IMS security).
Test procedure applicable for a UE with E-UTRA support (TS 34.229-2 [5] A.18/1)
1-15) UE executes the procedures described in TS 36.508 [94] table 4.5A.8.3-1, steps 1 to 15.
Expected sequence
NOTE: Only the IMS procedure relevant to the test purpose is described below.
|
Step |
Direction |
Message |
Comment |
|
|
UE |
SS |
|||
|
1-13 |
Steps defined in annex C.25 |
MTSI MO video call. Referred from 36.508 [94] table 4.5A.8.3-1 for a UE with E-UTRA support. |
||
|
14 |
🡪 |
BYE |
The UE releases the call with BYE |
|
|
15 |
🡨 |
200 OK |
The SS sends 200 OK for BYE |
|
Specific Message Contents
Steps 1 – 13 as specified in annex C.25
BYE (Step 14)
Use the default message “BYE” in annex A.2.8.
200 OK for BYE (Step 15)
Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1.
12.21.5 Test requirements
SS must check that if the UE uses IMS security, it sends all the requests over the security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.1.
Step 14: the UE shall send a BYE request with the correct content, according to common message definitions