7.23 MTSI MT Voice Call / add video and remove video / without 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.23.1 Test Purpose (TP)

(1)

with { UE configured to not use preconditions and having been invited to a 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 followed by 200 OK for INVITE and resources are reserved }

then { UE sends ACK }

}

(4)

with { UE having sent ACK }

ensure that {

when { UE receives re-INVITE indicating that video is being removed from the call }

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

}

7.23.2 Conformance Requirements

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

[TS 24.173, clause 5.2]:

The IMS multimedia telephony communication service can support different types of media, including media types listed in 3GPP TS 22.173 [2]. The session control procedures for the different media types shall be in accordance with 3GPP TS 24.229 [13] and 3GPP TS 24.247 [14], with the following additions:

a) Multimedia telephony is an IMS communication service and the P-Preferred-Service and P-Asserted-Service headers shall be treated as described in 3GPP TS 24.229 [13]. The coding of the ICSI value in the P-Preferred-Service and P-Asserted-Service headers shall be according to subclause 5.1.

[TS 24.229, clause 5.1.2A.2]:

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.4A.1]:

If the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, the UE shall indicate support of the precondition mechanism during a session modification. If the precondition mechanism was not used during the session establishment, the UE shall not indicate support of the precondition mechanism during a session modification.

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;

and follow the SDP procedures in clause 6 for the precondition mechanism.

[TS 24.229, clause 6.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].

In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect SDP message bodies. Hence, the UE shall not encrypt SDP message bodies.

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].

The UE shall inspect the SDP message body contained in any SIP request or response, looking for possible indications of grouping of media streams according to RFC 3524 [54] 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, subclause L.2.2.5 for IP-CAN implemented using EPS, and subclause U.2.2.5 for IP-CAN implemented using 5GS).

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.

NOTE 4: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.

In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources. In this case the UE shall indicate as met the local preconditions related to the media stream, for which resources are re-used.

[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. This 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 [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 UE uses the precondition mechanism (see subclause 5.1.3.1); and

– if the UE uses the precondition mechanism (see subclause 5.1.3.1), shall not request confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE.

NOTE 1: Previous versions of this document mandated the use of the SDP inactive attribute. This document does not prohibit specific services from using direction attributes to implement their service-specific behaviours.

If the UE uses the precondition mechanism (see subclause 5.1.3.1), and the desired QoS resources for one or more media streams are available at the 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 and shall not request confirmation for the result of the resource reservation (as defined in RFC 3312 [30]) at the terminating UE.

NOTE 2: If the originating UE does not use the precondition mechanism (see subclause 5.1.3.1), it will not include any precondition information in the SDP message body.

…

Upon confirming successful local resource reservation, the UE shall create an SDP offer in which the related local preconditions are set to met, using the segmented status type, as defined in RFC 3312 [30] and RFC 4032 [64].

Upon receiving an SDP answer, which includes more than one codec per media stream, excluding the in-band DTMF codec, as described in subclause 6.1.1, the UE shall:

send an SDP offer at the first possible time, selecting only one codec per media stream; or

– if the UE is participant in a multi-stream multiparty multimedia conference session using simulcast (indicated by the presence of "a=simulcast" SDP attribute(s) in the SDP answer, as defined in RFC 8853 [249]), apply the procedures defined in 3GPP TS 26.114 [9B] annex S.

If the UE sends an initial INVITE request that includes only an IPv6 address in the SDP offer, and receives an error response (e.g., 488 (Not Acceptable Here) with 301 Warning header field) indicating "incompatible network address format", the UE shall send an ACK as per standard SIP procedures. Subsequently, the UE may acquire an IPv4 address or use an existing IPv4 address, and send a new initial INVITE request to the same destination containing only the IPv4 address in the SDP offer.

[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 [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].

An MTSI client in terminal should include the ‘a=bw-info’ attribute in the SDP offer. When accepting a media type where the ‘a=bw-info’ attribute is included the MTSI client in terminal shall include the ‘a=bw-info’ attribute in the SDP answer if it supports the attribute. The ‘a=bw-info’ attribute and the below used bandwidth properties are defined in clause 19.

[TS 26.114, clause 6.3]:

During session renegotiation for adding or removing media components, the SDP offerer 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.

An MTSI client in terminal may support multiple media components including media components of the same media type. An MTSI client in terminal may support adding one or more media components to an on-going session which already contains a media component of the same media type. If an MTSI client in terminal needs to have multiple media components of the same media type in a single MTSI session, then the MTSI client in terminal should use the SDP content attributes as defined in [81] for identifying different media components.

[TS 26.114, clause 7.3.1]

The RS and RR values included in the SDP answer should be treated as the negotiated values for the session and should be used to calculate the total RTCP bandwidth for all terminals in the session.

7.23.3 Test description

7.23.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 not 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.23.3.2 Test procedure sequence

Table 7.23.3.2-1: Main Behaviour

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

7.23.3.3 Specific message contents

Table 7.23.3.3-1: re-INVITE (step 2, table 7.23.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1, A5 and A28

Header/param

Cond

Value/remark

Rel

Reference

Message-body

Same SDP body as in Step 1 (INVITE) of Annex A.15.2, with following exceptions:

Session description:

"o=" line identical to previous SDP sent by UE except that sess-version is incremented by one

TS 24.229 [7]

TS 26.114 [33]

Table 7.23.3.3-2: 100 Trying (step 3, table 7.23.3.2-1)

Derivation Path: Annex A.15.2, Step 2

Table 7.23.3.3-3: 183 Session in Progress (step 4, table 7.23.3.2-1)

Derivation Path: Annex A.15.2, Step 3, using additional condition A15 of Annex A.2.3 of TS 34.229-1 [2]

Table 7.23.3.3-4: PRACK (step 5, table 7.23.3.2-1)

Derivation Path: Annex A.15.2, Step 4

Table 7.23.3.3-5: 200 OK for PRACK (step 6, table 7.23.3.2-1)

Derivation Path: Annex A.15.2, Step 5

Table 7.23.3.3-6: 200 OK for re-INVITE (step 7, table 7.23.3.2-1)

Derivation Path: Annex A.15.2, Step 9

Table 7.23.3.3-7: ACK for re-INVITE (step 8, table 7.23.3.2-1)

Derivation Path: Annex A.15.2, Step 10

Table 7.23.3.3-8: re-INVITE (step 9, table 7.23.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1 and A5

Header/param

Cond

Value/remark

Rel

Reference

Message-body

Same SDP body as in Step 4 (183 Session Progress),, 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.23.3.3-9: 100 Trying (step 10, table 7.23.3.2-1)

Derivation Path: TS 34.229-1, Annex A.2.2, condition A2.

Table 7.23.3.3-10: 200 OK for INVITE (step 12, table 7.23.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, conditions A2, A5, A8, A11, and A22

Header/param

Cond

Value/remark

Rel

Reference

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.

TS 24.229 [7]

TS 26.114 [33]

Table 7.23.3.3-11: ACK (step 13, table 7.23.3.2-1)

Derivation Path: TS 34.229-1, Annex A.2.7, conditions A2 and A5