7.16 MTSI MT Video call with preconditions at both originating UE and terminating UE / 5GS
34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification
7.16.1 Test Purpose (TP)
(1)
with { UE being registered to IMS and configured to use preconditions }
ensure that {
when { UE receives INVITE for video call }
then { UE may respond with 100 Trying }
}
(2)
with { UE being registered to IMS and configured to use preconditions }
ensure that {
when { UE receives INVITE for video call }
then { UE responds with 183 Session Progress including SDP }
}
(3)
with { UE having sent 183 Session Progress }
ensure that {
when { UE receives PRACK for 183 Session Progress }
then { UE sends 200 OK for PRACK }
}
(4)
with { UE having sent 200 OK for PRACK }
ensure that {
when { UE receives UPDATE including SDP }
then { UE sends 200 OK for UPDATE including SDP and 180 Ringing }
}
(5)
with { UE having sent 180 Ringing, possibly reliably }
ensure that {
when { 180 Ringing was sent reliably and consequently UE receives PRACK for 180 Ringing }
then { UE sends 200 OK for PRACK }
}
(6)
with { UE having sent 180 Ringing }
ensure that {
when { User accepts the incoming video call request }
then { UE sends 200 OK for INVITE }
}
(7)
with { UE having sent 200 OK for INVITE }
ensure that {
when { UE receives ACK followed by BYE }
then { UE sends 200 OK for BYE }
}
7.16.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.229, clause 6.1.1]:
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.
[TS 24.229, clause 6.1.3]:
Upon sending an SDP answer to an SDP offer, with the SDP answer including one or more media streams for which the originating side did indicate its local preconditions as not met, if the precondition mechanism is used by the terminating UE (see subclause 5.1.4.1), the terminating UE shall indicate its local preconditions and request the confirmation for the result of the resource reservation at the originating end point.
…
Upon receiving an initial INVITE request that includes the SDP offer containing an IP address type (in the "c=" parameter) that is not supported by the UE, the UE shall:
– if the UE is a UE performing the functions of an external attached network and
1) if the received SDP offer contains an "altc" SDP attribute indicating an alternative and supported IP address; and
2) the UE supports the "altc" SDP attribute;
select an IP address type in accordance with RFC 6947 [228]; or
– otherwise respond with a 488 (Not Acceptable Here) response including a 301 Warning header field indicating "incompatible network address format".
NOTE 2: Upon receiving an initial INVITE request that does not include an SDP offer, the UE can accept the request and include an SDP offer in the first reliable response. The SDP offer will reflect the called user’s terminal capabilities and user preferences for the session.
If the UE receives an SDP offer that specifies different IP address type for media (i.e. specify it in the "c=" parameter of the SDP offer) that the UE is using for signalling, and if the UE supports both IPv4 and IPv6 addresses simultaneously, the UE shall accept the received SDP offer. Subsequently, the UE shall either acquire an IP address type or use an existing IP address type as specified in the SDP offer, and include it in the "c=" parameter in the SDP answer.
NOTE 3: Upon receiving an initial INVITE request, that includes an SDP offer containing connection addresses (in the "c=" parameter) equal to zero, the UE will select the media streams that is willing to accept for the session, reserve the QoS resources for accepted media streams, and include its valid connection address in the SDP answer.
…
If the terminating UE uses the precondition mechanism (see subclause 5.1.4.1), if the desired QoS resources for one or more media streams have not been reserved at the terminating UE when constructing the SDP offer, the terminating UE shall indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [30] and RFC 4032 [64] for the remote segment.
NOTE 7: It is out of scope of this specification which media streams are to be included in the SDP offer.
If the terminating UE uses the precondition mechanism (see subclause 5.1.4.1) and if the desired QoS resources for one or more media streams are available at the terminating UE when the SDP offer is sent, the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [30] and RFC 4032 [64] for the remote segment.
If the terminating UE sends an UPDATE request to remove one or more media streams negotiated in the session for which a final response to the INVITE request has not been sent yet, the terminating UE sets the ports of the media streams to be removed from the session to zero in the new SDP offer.
NOTE 8: Upon receiving an initial INVITE request with one or more media streams which the terminating UE supports and one or more media streams which the UE does not support, the UE is not expected to reject the INVITE request just because of the presence of the unsupported media stream.
NOTE 9: Previous versions of this document mandated the use of the SDP inactive attribute in the SDP offer if the desired QoS resources for one or more media streams had not been reserved at the originating UE when constructing the SDP offer unless the originating UE knew that the precondition mechanism was supported by the remote UE. The use can still occur when interoperating with devices based on earlier versions of this document.
[TS 26.114, clause 5.2.2]:
MTSI clients in terminals offering video communication shall support:
– H.264 (AVC) [24] Constrained Baseline Profile (CBP) Level 1.2;
– H.265 (HEVC) [119] Main Profile, Main Tier, Level 3.1.
In addition they should support:
– H.264 (AVC) [24] Constrained High Profile (CHP) Level 3.1.
[TS 26.114, clause 6.2.3.2]:
If video is used in a session, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5, RTP profile, video codec, profile and level. The "imageattr" attribute as specified in [76] should be supported. The "framesize" attribute as specified in [60] shall not be used in the session setup.
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.
An MTSI client is required to support the AVPF feedback messages trr-int, NACK and PLI [40] and the CCM feedback messages FIR, TMMBR and TMMBN [43], see Clauses 7.3.3 and 10.3. These feedback messages can only be used together with AVPF and shall be negotiated in SDP offer/answer before they can be used in the session [40]. An MTSI client sending an SDP offer for AVPF shall also include these AVPF and CCM feedback messages in the offer. An MTSI client accepting an SDP offer for AVPF for video shall also accept these AVPF and CCM feedback messages if they are offered.
If an MTSI client offers to use ECN for video in RTP streams then the MTSI client shall offer ECN Capable Transport as defined below. If an MTSI client accepts an offer for ECN for video then the MTSI client shall declare ECN Capable Transport in the SDP answer as defined below. The SDP negotiation of ECN Capable Transport is described in [84].
The use of ECN for a video stream in RTP is negotiated with the "ecn-capable-rtp" SDP attribute, [84]. ECN is enabled when both clients agree to use ECN as configured below. An MTSI client using ECN shall therefore also include the following parameters and parameter values for the ECN attribute:
– ‘leap’, to indicate that the leap-of-faith initiation method shall be used;
– ‘ect=0’, to indicate that ECT(0) shall be set for every packet.
An MTSI client offering ECN for video shall indicate support of TMMBR [43] by including the "ccm tmmbr" value within an "rtcp-fb" SDP attribute [40]. An MTSI client offering ECN for video may indicate support for RTCP AVPF ECN feedback messages [84] using the "rtcp-fb" SDP attribute with the "nack" feedback parameter and the "ecn" feedback parameter value. An MTSI client offering ECN for video may indicate support for RTCP XR ECN summary reports [84] using the "rtcp-xr" SDP attribute and the "ecn-sum" parameter.
An MTSI client receiving an offer for ECN for video with an indication of support of TMMBR [43] within an "rtcp-fb" attribute should accept the offer if it supports ECN. It shall then indicate support for TMMBR using an "rtcp-fb" attribute in the SDP answer.
An MTSI client receiving an offer for ECN for video with an indication of support of RTCP AVPF ECN feedback message but without support for TMMBR should accept the offer if it supports ECN and also the RTCP AVPF ECN feedback message. It shall then indicate support of the RTCP AVPF ECN feedback message using the "rtcp-fb" attribute in the SDP answer.
An MTSI client receiving an offer for ECN for video with an indication of support of RTCP XR ECN summary reports [84] without support for TMMBR should accept the offer if it supports ECN and also the RTCP XR ECN summary reports. It shall then indicate support of RTCP XR ECN summary reports in the SDP answer.
The use of ECN is disabled when a client sends an SDP without the "ecn-capable-rtp" SDP attribute.
An MTSI client may initiate a session re-negotiation to disable ECN to resolve ECN-related error cases. An ECN-related error case may be, for example, detecting non-ECT in the received packets when ECT(0) was expected or detecting a very high packet loss rate when ECN is used.
Examples of SDP offers and answers for video can be found in clause A.4. SDP examples for offering and accepting ECT are shown in Annex A.12.2.
NOTE: For H.264 / MPEG-4 (Part 10) AVC, the optional max-rcmd-nalu-size receiver-capability parameter of RFC 6184 [25] should be set to the smaller of the MTU size (if known) minus header size or 1 400 bytes (otherwise).
The "framerate" attribute as specified in [8] indicates the maximum frame rate the offerer wishes to receive. If the "framerate" attribute is present in the SDP offer, its value may be modified in the SDP answer when the answerer wishes to receive video with a different maximum frame rate than what was indicated in the offer.
An MTSI client in terminal setting up asymmetric video streams with H.264 (AVC) should use both the ‘level-asymmetry-allowed’ parameter and the ‘max-recv-level’ parameter that are defined in the H.264 payload format, [25]. When the ‘max-recv-level’ parameter is used then the level offered for the receiving direction using the ‘max-recv-level’ parameter must be higher than the default level that is offered with the ‘profile-level-id’ parameter.
An SDP offer-answer example showing the usage of the ‘level-asymmetry-allowed’ and ‘max-recv-level’ parameters is included in Annex A.4.5.
An MTSI client in terminal setting up asymmetric video streams with H.265 (HEVC) should use the ‘max-recv-level-id’ parameter that is defined in the H.265 payload format, [120]. The level offered for the receiving direction using the ‘max-recv-level-id’ parameter must be higher than the default level that is offered with the ‘level-id’ parameter.
An SDP offer-answer example showing the usage of the ‘max-recv-level-id’ parameter is included in Annex A.4.8.
The resolutions in the "imageattr" attribute correspond to the image size information in the encoded video bitstream such that the x-component corresponds to the image width, and the y-component corresponds to the height component. When the bit-rate is being adapted, values of image width or image height smaller than the x- or y-component(s) in the negotiated "imageattr" attribute may be temporarily used.
7.16.3 Profile requirements (Informative)
[GSMA NG.114 V1.0, cluse 3.3.1]:
The entities in the IMS core network that terminate the user plane must support ITU-T Recommendation H.264 [83] Constrained Baseline Profile (CBP) Level 1.2 implemented as specified in section 5.2.2 of 3GPP TS 26.114 [16].
The UE must support ITU-T Recommendation H.264 [83] Constrained High Profile (CHP) Level 3.1 as specified in section 5.2.2 of 3GPP TS 26.114 [16].
The UE must support ITU-T Recommendation H.265 [84] Main Profile, Main Tier Level 3.1 as specified in section 5.2.2 of 3GPP TS 26.114 [16].
For backward compatibility, the UE must also support ITU-T Recommendation H.264 [83] Constrained Baseline Profile (CBP) Level 3.1 as specified in section 5.2.2 of 3GPP TS 26.114 [16], and when H.264 [83] (Advanced Video Coding (AVC)) CHP Level 3.1 is offered, then H.264 [83] CBP Level 3.1 must also be offered.
[GSMA NG.114 V1.0, cluse 3.3.2.1]:
The Session Description Protocol (SDP) offer/answer for video media must be formatted as specified in section 6.2.3 of 3GPP TS 26.114 [16], along with the restrictions included in the present document.
Unless preconfigured otherwise by the home operator with the Media_type_restriction_policy parameter as specified in Annex C.3 and when offering video media that is not already part of the session, regardless if it is at the start of the session or at some later point in time, the UE must include in the SDP offer at least:
1. One H.265 (HEVC) Main Profile, Main Tier, Level 3.1 payload type as defined in sections 5.2.2 and 7.4.3 of 3GPP TS 26.114 [16].
2. One H.264 (AVC) Constrained High Profile Level 3.1 payload type as defined in sections 5.2.2 and 7.4.3 of 3GPP TS 26.114 [16].
3. One H.264 (AVC) Constrained Baseline Profile Level 3.1 payload type as defined in sections 5.2.2 and 7.4.3 of 3GPP TS 26.114 [16].
The payload type preference order on the SDP m= line must be as specified by the numbered list above.
Coordination of Video Orientation (CVO) as specified in 3GPP TS 26.114 [16] shall be supported with two (2) bits granularity by the UE and the entities in the IMS core network which terminate the user plane. The support for CVO shall be included in SDP offer and SDP answer as specified in section 6.2.3 of 3GPP TS 26.114 [16].
[GSMA NG.114 V1.0, cluse 3.3.2.2]:
If an asymmetric video stream for H.265 (HEVC) is supported, the parameter ‘max-recv-level-id’ should be included in the SDP offer and SDP answer, and the level offered with it must be higher than the default level offered with the ‘level-id’ parameter in the SDP offer/answer respectively, as specified in section 7.1 of IETF RFC 7798 [86] and section 6.2.3 of 3GPP TS 26.114 [16].
7.16.4 Test description
7.16.4.1 Pre-test conditions
System Simulator:
– 1 NR Cell connected to 5GC, default parameters.
UE:
– The UE contains either ISIM and USIM applications or only USIM application on UICC.
– The UE is configured to register for IMS after switch on.
– The UE is configured to use preconditions.
Preamble:
– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS
7.16.4.2 Test procedure sequence
Table 7.16.4.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||||
|
U – S |
Message |
||||||||||
|
0A-0H |
Steps 1-8 of generic procedure specified in Table 4.9.26.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
||||||
|
1 |
SS sends INVITE with the first SDP offer. (Step 1 of Annex A.16.1) |
<- |
INVITE |
– |
– |
||||||
|
2 |
Check: (Optional) Does the UE respond with a 100 Trying provisional response? (Step 2 of Annex A.16.1) |
-> |
100 Trying |
1 |
-P |
||||||
|
3 |
Check: Does the UE send 183 response reliably with the SDP answer to the offer in INVITE? (Step 3 of Annex A.16.1) |
-> |
183 Session Progress |
2 |
P |
||||||
|
4 |
SS acknowledges the receipt of 183 response from the UE. (Step 4 of Annex A.16.1) |
<- |
PRACK |
– |
– |
||||||
|
5 |
Check: Does the UE responds to PRACK with 200 OK. (Step 5 of Annex A.16.1) |
-> |
200 OK |
3 |
P |
||||||
|
5A |
SS triggers resource reservation by executing steps 10-12 of generic procedure specified in Table 4.9.26.2.2-1 of TS 38.508-1 [21]. |
– |
– |
– |
– |
||||||
|
6 |
SS sends an UPDATE with SDP offer indicating SS reserved resources. (Step 6 of Annex A.16.1) |
<- |
UPDATE |
||||||||
|
7 |
Check: Does the UE acknowledges the UPDATE with 200 OK and includes SDP answer to acknowledge its current precondition status. (Step 7 of Annex A.16.1) |
-> |
200 OK |
4 |
P |
||||||
|
8 |
Check: (Optional) Does the UE responds to INVITE with 180 Ringing? (Step 8 of Annex A.16.1) |
-> |
180 Ringing |
– |
– |
||||||
|
9 |
(Optional) SS shall send PRACK only if the 180 response contains 100rel option tag within the Require header? (Step 9 of Annex A.16.1) |
<- |
PRACK |
– |
– |
||||||
|
10 |
Check: (Optional) Does the UE acknowledges the PRACK with 200 OK? (Step 10 of Annex A.16.1) |
-> |
200 OK |
5 |
P |
||||||
|
11 |
UE is made to answer the call. |
– |
– |
– |
– |
||||||
|
12 |
Check: Does the UE responds to INVITE with a 200 OK final response after the user answers the call? (Step 12 of Annex A.16.1) |
-> |
200 OK |
6 |
P |
||||||
|
13 |
The SS acknowledges the receipt of 200 OK for INVITE. (Step 13 of Annex A.16.1) |
<- |
ACK |
– |
– |
||||||
|
14 |
The SS releases the call with BYE. (Step 1 of Annex A.8) |
<- |
BYE |
– |
– |
||||||
|
15 |
Check: Does the UE sends 200 OK for BYE. (Step 2 of Annex A.8) |
-> |
200 OK |
7 |
P |
||||||
7.16.4.3 Specific message contents
None as fully specified in A.16.1 and A.8.