7.26 Mobile Originating CAT / Forking Model / MO Voice Call / 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.26.1 Test Purpose (TP)

(1)

with { UE being registered to IMS and configured to use preconditions and having initiated an MO voice call with preconditions up to the last step before 180 Ringing }

ensure that {

when { UE receives 183 Session Progress on a forked dialog indicating Customized Alerting Tones }

then { UE moves forked dialog forward until up to the last step before 180 Ringing }

}

(2)

with { UE having moved both dialogs forward up to the last step before 180 Ringing }

ensure that {

when { UE receives 200 OK for INVITE for the first dialog }

then { UE acks reception of 200 OK for INVITE }

}

7.26.2 Conformance Requirements

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

[TS 24.182, clause 4.5.5.1.1]:

The UE shall follow the procedures specified in 3GPP TS 24.229 [4] for session initiation and termination.

[TS 24.628, clause 4.7.2.1]:

Procedures according to 3GPP TS 24.229 [1] shall apply.

Certain services require the usage of the Alert-Info header field, Call-Info header field and Error-Info header field according to procedures specified by IETF RFC 3261 [4].

If the UE detects that in-band information is received from the network as early media, the in-band information received from the network shall override locally generated communication progress information.

NOTE 1: In-band information received from the network overrides any locally generated communication progress information also when the most recently received P-Early-Media header fields of all early dialogs contain "inactive" or "recvonly".

NOTE 2: When multiple early dialogs exist with authorization as "sendrecv" or "sendonly", the mechanism used by the UE to associate the received early media with the correct early dialog is unspecified in this version of this specification.

The UE shall not generate the locally generated communication progress information if an early dialog exists where the last received P-Early-Media header field as described in IETF RFC 5009 [12] contains "sendrecv" or "sendonly".

If an early dialog exists where a SIP 18x response to the SIP INVITE request other than 183 (Session Progress) response was received, no early dialog exists where the last received P-Early-Media header field as described in IETF RFC 5009 [12] contained "sendrecv" or "sendonly" and in-band information is not received from the network, then the UE is expected to render the locally generated communication progress information.

NOTE 3: According to 3GPP TS 22.173 [23] the UE for an MMTel session generates the communication progress information specified in clause F.2 of 3GPP TS 22.001 [24], with parameters applicable for the home network of the UE.

If the UE supports the P-Early-Media header field as defined in IETF RFC 5009 [12], and at least one P-Early-Media header field has been received on at least one early dialog, then the UE shall send any available user generated media, e.g. speech or DTMF, on media stream(s) associated with the early dialog for which the most recent P-Early-Media header field, as described in IETF RFC 5009 [12], contained a "sendrecv" header field value. If there is more than one such early dialog, the UE shall use the early dialog where the P-Early-Media header field was most recently received.

If the UE receives a re-INVITE request containing no SDP offer, the UE shall send a 200 (OK) response containing an SDP offer according to 3GPP TS 24.229 [1] indicating the directionality used by UE as

– "sendonly" if the re-INVITE request is received on a dialog where the associated communication session has been put on hold by the user or has been put on hold by both users at both ends; and

– "sendrecv" otherwise.

7.26.3 Test description

7.26.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 is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

7.26.3.2 Test procedure sequence

Table 7.26.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

UE is made to initiate a voice call.

–

–

–

–

1A-1F

Steps 2-7 of generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed.

–

–

–

–

–

EXCEPTION: In parallel with Step 2, parallel behaviour defined in table 7.26.3.2-2 takes place

–

–

–

–

2-6

Steps 1-5 of generic procedures of MO voice call with preconditions defined in A.4.1a.

–

Setup dialog 1

–

–

6A

Step 10 of generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] is performed.

–

–

–

–

–

EXCEPTION: In parallel to steps 6B and 6C below, step 7occurs.

–

–

–

–

6B-6C

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

–

–

–

–

7-8

Steps 6-7 of generic procedures of MO voice call with preconditions defined in A.4.1a.

–

Setup dialog 1

–

–

9

SS sends an SDP answer.

(Step 3 of A.4.1a)

<–

183 Progress (dialog 2)

–

–

10

Check: Does the UE acknowledge reception of 183 Session Progress?

(Step 4 of A.4.1a)

–>

PRACK (dialog 2)

1

P

11

SS responds to PRACK.

(Step 5 of A.4.1a)

<–

200 OK (dialog 2)

–

–

12-13

Void

–

–

–

14

The SS sends 200 OK for INVITE sent in step 1 above

<–

200 OK

–

–

15

Check: Does the UE send the ACK to the 200 OK for the INVITE in step 1?

–>

ACK

2

P

16

The UE is made to release the call

–

–

–

–

17

The UE releases the call with BYE

–>

BYE

–

–

18

The SS sends 200 OK for BYE

<–

200 OK

–

–

Table 7.26.3.2-2: Parallel behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE transmits an RRCReconfigurationComplete message.

–>

NR RRC: RRCReconfigurationComplete

–

–

7.26.3.3 Specific message contents

Table 7.26.3.3-1: 183 Session Progress with an SDP offer (step 9, table 7.26.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in annex A.2.3, Condition A1

Header/param

Cond

Value/remark

Rel

Reference

To

tag

any value different from what is used in steps 1-5

Contact

addr-spec

<sip:cat-as.home1.net;+g.3gpp.icsi ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel">

P-Early-Media

em-param

sendonly

Require

TS 24.229 [7]

option-tag

precondition

Message-body

Session description:

v=0

o=- 1111111112 1111111111 IN (addrtype) (unicast-address for SS for early-media)

s=-

c=IN (addrtype) (connection-address for SS for early-media)

b=AS:37

Attributes for preconditions:

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=conf:qos remote sendrecv

Other attributes:

a=content:g.3gpp.cat

TS 24.229 [7]
RFC 4566 [38]

Table 7.26.3.3-2: PRACK (step 10, table 7.26.3.2-1)

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

Header/param

Cond

Value/remark

Rel

Reference

Require

option-tag

precondition

Message-body

Contents is copied from step 6 of annex A.4.1a with the following exceptions:

Attributes for preconditions:

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv

TS 24.229 [7]

Table 7.26.3.3-3: 200 OK (step 11, table 7.26.3.2-1)

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

Header/param

Cond

Value/remark

Rel

Reference

To

tag

Same value as used in step 9

Require

option-tag

precondition

Content-Type

media-type

application/sdp

Content-Length

value

length of message-body

Message-body

SDP body of the 200 OK response copied from the received PRACK and modified as follows:

– IP address on "c=" lines and transport port on "m=" lines changed to indicate to which IP address and port the UE should start sending the media (same as used in step 9 above);

– "o=" line identical to previous SDP sent by SS except that sess-version is incremented.

TS 24.229 [7]