7.6 MTSI MT Voice 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.6.1 Test Purpose (TP)

(1)

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

ensure that {

when { UE receives INVITE for voice call }

then { UE responds with 183 Session Progress including SDP }

}

(2)

with { UE having sent 183 Session Progress }

ensure that {

when { UE receives PRACK for 183 Session Progress }

then { UE sends 200 OK for PRACK }

}

(3)

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 }

}

(4)

with { UE having sent 180 Ringing, possibly reliably }

ensure that {

when { 180 was sent reliably and consequently UE receives PRACK for 180 Ringing }

then { UE sends 200 OK for PRACK }

}

(5)

with { UE having sent 180 Ringing }

ensure that {

when { User accepts the incoming voice call request }

then { UE sends 200 OK for INVITE }

}

(6)

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

If an initial INVITE request is received the terminating UE shall check whether the terminating UE requires local resource reservation.

NOTE 1: The terminating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.

During the session initiation, if local resource reservation is required at the terminating UE and the terminating UE supports the precondition mechanism, and:

a) the received INVITE request includes the "precondition" option-tag in the Supported header field or Require header field and the precondition mechanism is enabled as specified in subclause 5.1.5A, the terminating UE shall use the precondition mechanism and shall include a Require header field with the "precondition" option-tag:

…

If the terminating UE included an SDP offer or an SDP answer in a reliable provisional response to the INVITE request and both the terminating UE and the originating UE support UPDATE method, then in order 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 shall send an UPDATE request with a new SDP offer and delays sending of 200 (OK) response to the INVITE request till after reception of 200 (OK) response to the UPDATE request.

If the user does not accept a media stream accepted in the SDP answer and the terminating UE, the originating UE or both do not support the UPDATE method, then after reception of ACK request related to 200 (OK) response to the INVITE request, the UE shall modify the session.

The terminating UE shall include the media feature tags as defined in RFC 3840 [62] for all supported streaming media types in the SIP response other than the 100 (Trying) response to the SIP INVITE 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].

[TS 24.229, clause 6.1.3]

If the terminating UE had previously set one or more media streams to inactive mode and the QoS resources for those media streams are now ready, the UE shall set the media streams to active mode by applying the procedures described in RFC 4566 [39] with respect to setting the direction of media streams.

…

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.

[TS 26.114, clause 5.2.1]

In addition, MTSI clients in terminals offering speech communication shall support:

– AMR speech codec (3GPP TS 26.071 [11], 3GPP TS 26.090 [12], 3GPP TS 26.073 [13] and 3GPP TS 26.104 [14]) including all 8 modes and source controlled rate operation ‎3GPP TS 26.093 [15]. The MTSI client in terminal shall be capable of operating with any subset of these 8 codec modes. More detailed codec requirements for the AMR codec are defined in clause 5.2.1.2.

[TS 26.114, clause 6.2.2.1]

An MTSI client offering a speech media session for narrow-band speech and/or wide-band speech should generate an SDP offer according to the examples in Annexes A.1 to A.3. An MTSI client offering EVS should generate an SDP offer according to the examples in Annex A.14.

An MTSI client in terminal supporting EVS should support the RTCP-APP signalling for speech adaptation defined clause 10.2.1, and shall support the RTCP-APP signalling when the MTSI client in terminal supports adaptation for call cases where the RTP-based CMR cannot be used.

[TS 26.114, clause 6.2.5]

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

7.6.2A Profile requirements (Informative)

[NG.114 Version 1.0, clause 2.3.5]:

For MMTEL Voice/Conversational Video sessions, the UE must support the preconditions mechanism as specified in sections 5.1.3.1 and 5.1.4.1 of 3GPP TS 24.229 [8]. If the precondition mechanism is enabled by the Precondition_disabling_policy node in Annex C.3, the UE must use the precondition mechanism.

[NG.114 Version 1.0, clause 3.2.2.3]:

A UE must answer according to both the received SDP Offer and the UE’s EVS configuration (i.e. EVS/Br and EVS/Bw parameters as specified in see Annex C.3) as described in Table 3.2.2.3-1 below:

EVS configuration of the UE that received the SDP Offer

Received SDP Offer for EVS (preferred payload type listed first)

A1

A2

B0

B1

B2

A1

A1

A1

A1

A1

A1

A2

A1

A2

A1

A1

A2

B0

B0

B0

B0

B0

B0

B1

A1

A1

B1

B1

B1

B2

A1

A2

B1

B1

B2

Note 2: This table applies only to received SDP Offers compliant with this PRD, i.e. including A1, if B0 or B1 are listed first and including A2, if B2 is listed first.

If the selected EVS configuration is A1, B0 or B1 then "mode set = 0,1,2" must be included in the SDP answer.

The UE must add only SDP parameters that are applicable to EVS in the SDP answer that are already present in the corresponding received and accepted SDP Offer. If SDP parameters applicable to EVS, are included in the accepted SDP offer, then the UE must handle these parameters as specified in 3GPP TS 26.445 [58].

If the SDP parameter ch-aw-recv is present in the corresponding received and accepted SDP offer, then the SDP parameter ch-aw-recv must be included in the SDP answer with the same value as received.

Default values as specified in 3GPP TS 26.445 [58] apply for all other SDP parameters applicable to EVS that are not included in the SDP Answer.

7.6.3 Test description

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

– The UE is configured to use preconditions.

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

7.6.3.2 Test procedure sequence

Table 7.6.3.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.16.2.2-1 of TS 38.508-1 [21] are performed.

–

–

–

–

1

SS sends INVITE for voice call
(Step 1 of Annex A.5.1) happens

<–

INVITE

–

–

2

UE may send 100 Trying response
(Step 2 of Annex A.5.1) happens

–>

100 Trying

–

–

3

UE sends 183 Session Progress response
(Step 3 of Annex A.5.1)

–>

183 Session Progress

1

P

4

SS sends PRACK
(Step 4 of Annex A.5.1)

<–

PRACK

–

–

5

UE sends 200 OK for PRACK
(Step 5 of Annex A.5.1)

–>

200 OK

2

P

5A-5C

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

–

–

–

–

6

SS sends UPDATE
(Step 6 of Annex A.5.1)

<–

UPDATE

–

–

7

UE sends 200 OK for UPDATE
(Step 7 of Annex A.5.1)

–>

200 OK

3

P

8

UE sends 180 Ringing
(Step 8 of Annex A.5.1)

–>

180 Ringing

–

–

9

SS sends PRACK if 180 Ringing was sent reliably
(Step 9 of Annex A.5.1)

<–

PRACK

–

–

10

UE sends 200 OK for PRACK if SS sent PRACK
(Step 10 of Annex A.5.1)

–>

200 OK

4

P

10A

Make UE accept the voice call

–

–

–

–

11

UE accepts the call
(Step 11 of Annex A.5.1)

–>

200 OK

5

P

12

SS sends ACK
(Step 12 of Annex A.5.1)

<–

ACK

–

–

13

SS releases the call
(Step 1 of Annex A.8)

<–

BYE

–

–

14

UE sends 200 OK for BYE
(Step 2 of Annex A.8)

–>

200 OK

6

P

7.6.3.3 Specific message contents

None as fully described in Annexes A.5.1 and A.8.