7.22 MTSI MT Voice Call / add video and remove video / 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

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

7.22.1 Test Purpose (TP)

(1)

with { UE being configured to use preconditions and having been invited to voice call and voice call being set up successfully }

ensure that {

when { UE is made to add video to the voice call }

then { UE sends re-INVITE with SDP media for both voice and video }

}

(2)

with { UE having sent re-INVITE }

ensure that {

when { UE receives 100 Trying followed by 183 Session Progress }

then { UE sends PRACK }

}

(3)

with { UE having sent PRACK }

ensure that {

when { UE receives 200 OK for PRACK and resources being reserved }

then { UE sends UPDATE with SDP offer indicating reserved resources }

}

(4)

with { UE having sent UPDATE }

ensure that {

when { UE receives 200 OK for UPDATE followed by 200 OK for re-INVITE }

then { UE sends ACK }

}

(5)

with { UE having sent ACK }

ensure that {

when { UE receives re-INVITE indicating removal of video }

then { UE may send 100 Trying and sends 200 OK for re-INVITE }

}

7.22.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229, clause 5.1.2A.1.1]

After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.

[TS 24.229, clause 5.1.3.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 [30] as updated by RFC 4032 [64].

The preconditions mechanism should be supported by the originating UE.

…

Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see subclause 6.1.2) within the next SIP request.

NOTE 3: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on one or both sides, alternatively a reINVITE request can be used for this confirmation after a 200 (OK) response has been received for the initial INVITE request, in case the terminating UE does not support the PRACK request (as described in RFC 3262 [27]) and does not support the UPDATE request (as described in RFC 3311 [29]).

[TS 24.229, clause 5.1.4A.1]

In order to indicate support of the precondition mechanism during a session modification, upon generating a reINVITE request, an UPDATE request with an SDP body, or a PRACK request with an SDP body, the UE shall:

a) indicate the support for the precondition mechanism using the Supported header field;

b) not indicate the requirement for the precondition mechanism using the Require header field; and

c) if a re-INVITE request is being generated, indicate the support for reliable provisional responses using the Supported header field;

[TS 24.229, clause 5.1.4A.2]

Upon receiving a reINVITE request, an UPDATE request, or a PRACK request that indicates support for the precondition mechanism by using the Supported header field or requires use of the precondition mechanism by using the Require header field, the UE shall:

a) if the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, use the precondition mechanism for the session modification;

…

If the precondition mechanism is used for the session modification, the UE shall indicate support for the preconditions mechanism, using the Require header field, in responses that include an SDP body, to the session modification request.

[TS 24.229, clause 6.1.1]

During the session establishment procedure, and during session modification procedures, SIP messages shall only contain an SDP message body if that is intended to modify the session description, or when the SDP message body is included in the message because of SIP rules described in RFC 3261 [26].

…

For "video" and "audio" media types that use the RTP/RTCP and where the port number is not zero, the UE shall specify the proposed bandwidth for each media stream using the "b=" media descriptor and the "AS" bandwidth modifier in the SDP.

…

If the media line in the SDP message body 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 [56], 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 [56] 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 [152].

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 or 3GPP 29.213 [13C].

NOTE 3: 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.

If an in-band DTMF codec is supported by the application associated with an audio media stream, then the UE shall include, in addition to the payload type numbers associated with the audio codecs for the media stream, for each clock rate associated with the audio codecs for the media stream, a payload type number associated with the MIME subtype "telephone-event", to indicate support of in-band DTMF as described in RFC 4733[23].

…

In case of UE initiated resource reservation and if the UE determines 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.

[TS 24.229, clause 6.1.4.2]

If the precondition mechanism is used for the session modification, the following applies:

a) if the session modification does not increase the QoS requirement of the already established media stream (e.g., all the media streams in a call hold procedure, audio stream in a call upgrade procedure), in the SDP body of the request (re-INVITE, UPDATE, or PRACK), both local and remote QoS of this media shall be indicated as met; and

b) if the session modification increases the QoS requirement of some already established media stream(s) (e.g., request of using a different audio/video codec that requires higher bandwidth), or if the session modification adds a new media stream (e.g., call upgrade), the setting of the current and desired QoS status of the modified or added media stream shall be the same as specified in subclause 6.1.2. If the network fails to modify or reserve the required resources, the UE shall send a CANCEL request to terminate the session modification.

[TS 26.114, clause 5.2.1.1]

MTSI clients in terminals offering super-wideband or full band speech communication shall support:

– EVS codec ( TS 26.441 [121], TS 26.444 [124], TS 26.445 [125], TS 26.447 [127], TS 26.451 [131], TS 26.442 [122], TS 26.452 [165], and TS 26.443 [123] ) as described below including functions for backwards compatibility with AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and TS 26.450 [130]).

[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. The only exception to this requirement is for the MTSI client in constrained terminal offering video communication, in which case the MTSI client in constrained terminal should support H.265 (HEVC) Main Profile, Main Tier, Level 3.1.

In addition they should support: – H.264 (AVC) [24] Constrained High Profile (CHP) Level 3.1.

For backwards compatibility to previous releases, if H.264 (AVC) [24] Constrained High Profile Level 3.1 is supported, then H.264 (AVC) [24] Constrained Baseline Profile (CBP) Level 3.1 should also be offered.

[TS 26.114, clause 6.2.1a.1]

MTSI clients should support SDPCapNeg to be able to negotiate RTP profiles for all media types where AVPF is supported. MTSI clients supporting SDPCapNeg shall support the complete SDPCapNeg framework.

SDPCapNeg is described in [69]. This clause only describes the SDPCapNeg attributes that are directly applicable for the RTP profile negotiation, i.e. the tcap, pcfg and acfg attributes. TS 24.229 [7] may outline further requirements needed for supporting SDPCapNeg in SDP messages.

NOTE: This clause describes only how to use the SDPCapNeg framework for RTP profile negotiation using the tcap, pcfg and acfg attributes. Implementers may therefore (incorrectly) assume that it is sufficient to implement only those specific parts of the framework that are needed for RTP profile negotiation. Doing so would however not be future proof since future versions may use other parts of the framework and there are currently no mechanisms for declaring that only a subset of the framework is supported. Hence, MTSI clients are required to support the complete framework.

[TS 26.114, clause 6.2.1a.2]

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.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 IETF RFC 6236 [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.

[TS 26.114, clause 6.2.5.1]

The SDP shall include bandwidth information for each media stream and also for the session in total. The bandwidth information for each media stream and for the session is defined by the Application Specific (AS) bandwidth modifier as defined in RFC 4566 [8].

[TS 26.114, clause 6.3]

Addition and removal of media components shall be performed based on the SDP-based offer-answer model as specified in RFC 3264 [58].

During session renegotiation for adding or removing media components, the SDP offeror should continue to use the same media (m=) line(s) from the previously negotiated SDP for the media components that are not being added or removed.

[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 [42]. Therefore, an MTSI client shall include the "b=RS:" and "b=RR:" fields in SDP, and shall be able to interpret them.

7.22.3 Test description

7.22.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– UE is configured to register for IMS after switch on.

– UE is configured to use preconditions

Preamble:

The UE has registered to IMS and MT voice call is set up by executing the generic test procedure in clause 4.9.16 of TS 38.508-1 [21] up to the last step.

7.22.3.2 Test procedure sequence

Table 7.22.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
–	Make UE add video to the ongoing voice call	–	–	–	–
1	Check: does the UE send re-INVITE with an SDP offer containing media lines for both voice and video?	–>	INVITE	1	P
2	SS responds with 100 Trying	<–	100 Trying	–	–
3	SS responds with 183 session Progress including SDP answer	<–	183 Session Progress	–	–
4	Check: does the UE acknowledge the receipt of 183 response with PRACK?	–>	PRACK	2	P
5	SS responds to PRACK with 200 OK	<–	200 OK	–	–
5A	SS reserves resources for video by executing TS 38.508-1 cl 4.9.27	–	–	–	–
6	Check: does the UE send UPDATE?	–>	UPDATE	3	P
7	SS responds UPDATE with 200 OK indicating reservation of resources	<–	200 OK	–	–
8	SS responds to re-INVITE with 200 OK	<–	200 OK	–	–
9	Check: does the UE acknowledge the receipt of 200 OK for re-INVITE?	–>	ACK	4	P
10	SS sends re-INVITE with SDP offer indicating that video component is removed from the call.	<–	INVITE	–	–
11	Optional: UE may send 100 Trying.	–>	100 Trying	–	–
12	Check: does the UE responds to re-invite with 200 OK final response?	–>	200 OK	5	P
13	SS releases the QoS flow for video by executing TS 38.508-1 cl 4.9.28.	–	–	–	–
14	The SS acknowledges the receipt of 200 OK for re-INVITE.	<–	ACK	–	–

7.22.3.3 Specific message contents

Table 7.22.3.3-1: INVITE (step 1, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.1, Conditions A1, A3, A5, A28, A30 and A31
Header/param	Cond	Value/remark	Rel	Reference
Supported
option-tag		precondition
Message-body		SDP body of INVITE copied from Annex A.15.1 Step 6 and modified as follows: For preconditions of audio media: a=curr:qos remote sendrecv SDP values for video media as mentioned in A.15.1 Step 1 and modified as follows: For preconditions of video media:a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv		TS 24.229 [7] TS 26.114 [33]

Table 7.22.3.3-2: 100 Trying (step 2, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.2, Condition A1

Table 7.22.3.3-3: 183 Session Progress (step 3, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.3, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
Require
option-tag		precondition
Message-body		SDP body of 183 Session Progress copied from Annex A.15.1 Step 7 and modified as follows: For preconditions of video media: a=curr:qos local none and a=curr:qos remote none – Video media attribute “a=acfg:1 t=1” present if tcap/pcfg attributes were included in INVITE		TS 24.229 [7] TS 26.114 [33]

Table 7.22.3.3-4: PRACK (step 4, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.4, Conditions A1 and A7

Table 7.22.3.3-5: 200 OK for PRACK (step 5, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A10 and A22

Table 7.22.3.3-6: UPDATE (step 6, table 7.22.3.2-1)

Derivation Path: Annex A.15.1 Step 6 with following exceptions
Header/param	Cond	Value/remark	Rel	Reference
Supported
option-tag		precondition
Message-body		For preconditions of audio media: a=curr:qos remote sendrecv		TS 24.229 [7]

Table 7.22.3.3-7: 200 OK for UPDATE (step 7, table 7.22.3.2-1)

Derivation Path: Annex A.15.1 Step 7

Table 7.22.3.3-8: 200 OK for re-INVITE (step 8, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A1, A10, A19 and A22

Table 7.22.3.3-9: ACK for re-INVITE (step 9, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.7, Conditions A1, A3 and A5

Table 7.22.3.3-10: INVITE (step 10, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.9, Conditions A1, A3 and A5
Header/param	Cond	Value/remark	Rel	Reference
Supported
option-tag		precondition
Message-body		Same SDP body as in Step 7 (200 OK), but setting the port for video to zero on the m-line, and incrementing sess-version on the o-line.		TS 24.229 [7] TS 26.114 [33]

Table 7.22.3.3-11: 100 Trying (step 11, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.2, Condition A2

Table 7.22.3.3-12: 200 OK for INVITE (step 12, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A2, A5, A11, A20 and A22
Header/param	Cond	Value/remark	Rel	Reference
Require
option-tag		precondition
Content-Type
media-type		application/sdp
Content-Length		header shall be present if UE uses TCP to send this message and if there is a message body
value		length of message-body
Message-body		SDP body not checked other than that sess-version on o-line is incremented by one compared to previous SDP body sent by the UE and that port is set to zero on m-line for video

Table 7.22.3.3-13: ACK (step 14, table 7.22.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.7, Conditions A2, A3 and A5