7.14 MTSI MO Video Call with preconditions at both originating 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.14.1 Test Purpose (TP)

(1)

with { UE being registered to IMS and configured to use preconditions }

ensure that {

when { UE is being made to initiate a video call }

then { UE sends INVITE for video call with preconditions }

}

(2)

with { UE having sent INVITE with preconditions }

ensure that {

when { UE receives 183 Session Progress }

then { UE sends PRACK for 183 Session Progress }

}

(3)

with { UE having sent PRACK }

ensure that {

when { UE receives 200 OK for PRACK }

then { UE sends UPDATE }

}

(4)

with { UE having sent UPDATE }

ensure that {

when { UE receives 200 OK for UPDATE followed by 180 Ringing sent reliably }

then { UE sends PRACK for 180 Ringing }

}

(5)

with { UE having sent PRACK for 180 Ringing }

ensure that {

when { UE receives 200 OK for PRACK followed by 200 OK for INVITE }

then { UE sends ACK }

}

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

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.

…

[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 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 SDP offer shall contain a subset of the allowed media types, codecs and other parameters from the SDP message bodies of all 488 (Not Acceptable Here) responses so far received for the same session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). For each media line, the UE shall order the codecs in the SDP offer according to the order of the codecs in the SDP message bodies of the 488 (Not Acceptable Here) responses.

NOTE 6: 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 message bodies 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 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.

7.14.3 Test description

7.14.3.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 and registered to IMS

7.14.3.2 Test procedure sequence

Table 7.14.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

UE is made to attempt an IMS video call.

–

–

–

–

2A-2G

Steps 2-8 from generic procedure specified in TS 38.508-1 [21] Table 4.9.24 are performed.

–

–

–

–

3

Check: Does UE send INVITE with the first SDP offer?

(Step 1 of Annex A.15.1)

–>

INVITE

1

P

4

SS sends a 100 Trying provisional response.

(Step 2 of Annex A.15.1)

<–

100 Trying

5

SS sends an SDP answer.

(Step 3 of Annex A.15.1)

<–

183 Session Progress

6

Check: Does UE acknowledge reception of 183 Session Progress?

(Step 4 of Annex A.15.1)

–>

PRACK

2

P

7

SS responds to PRACK.

(Step 5 of Annex A.15.1).

<–

200 OK

7A-7C

Steps 10-12 from generic procedure specified in TS 38.508-1 [21] Table 4.9.24 are performed.

–

–

–

–

8

Check: Does UE send a second SDP offer in an UPDATE request?

(Step 6 of Annex A.15.1)

–>

UPDATE

3

P

9

SS responds to UPDATE.

(Step 7 of Annex A.15.1)

<–

200 OK

10

SS sends 180 Ringing reliably.

(Step 8 of Annex A.15.1)

<–

180 Ringing

11

Check: Does UE acknowledge reception of 180 Ringing?

(Step 9 of Annex A.15.1)

–>

PRACK

4

P

12

SS responds to PRACK.

(Step 10 of Annex A.15.1)

<–

200 OK

13

SS responds to INVITE.

(Step 11 of Annex A.15.1)

<–

200 OK

14

Check: Does UE acknowledge?

(Step 12 of Annex A.15.1)

–>

ACK

5

P

7.14.3.3 Specific message contents

None as fully described in Annex A.15.1