8.27 MO Video Call Hold without announcement / 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

8.27.1 Test Purpose (TP)

(1)

with { UE being registered to IMS and being registered to use preconditions and having set up a video call }

ensure that {

when { UE is being made to hold the call }

then { UE sends re-INVITE or UPDATE, and completes the call hold procedure }

}

(2)

with { UE having put the video call on hold }

ensure that {

when { UE is being made to resume the call }

then { UE sends re-INVITE or UPDATE, and completes the call resume procedure }

}

8.27.2 Conformance Requirements

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

[TS 24.610 clause 4.5.2.1]:

In addition to the application of procedures according to 3GPP TS 24.229 [1], the following procedures shall be applied at the invoking UE in accordance with RFC 3264 [4].

A UE shall not invoke the HOLD service on a dialog associated with an emergency call the UE has initiated.

If not all the media streams are affected, the invoking UE shall generate a new SDP offer where:

1) for each media stream that is to be held, the SDP offer contains:

– an "inactive" SDP attribute if the stream was previously set to "recvonly"; or

– a "sendonly" SDP attribute if the stream was previously set to "sendrecv";

NOTE 1: If the directionality attribute of the media stream is currently "sendonly" or "inactive", then that media stream is not put on hold and, in the SDP offer, the directionality for that media stream remains unchanged.

2) for each held media stream that is to be resumed, the SDP offer contains:

– a "recvonly" SDP attribute if the stream was previously an inactive media stream; or

– a "sendrecv" SDP attribute if the stream was previously a sendonly media stream, or the attribute may be omitted, since sendrecv is the default; and

3) for each media stream that is unaffected, the media parameters in the SDP offer remain unchanged from the previous SDP.

If all the media streams are to be held:

– if they all have identical directionality, the invoking UE shall generate an SDP offer containing a session level direction attribute, or separate media level direction attributes, in the SDP that is set to:

1) "inactive" if the streams were previously set to "recvonly"; or

2) "sendonly" if the streams were previously set to "sendrecv"; and

NOTE 2: If the directionality attribute of all the media streams is currently "sendonly" or "inactive", then all these media streams are not put on hold and, in the SDP offer, the directionality for these media streams will remain unchanged.

– if they all do not have identical directionality, then for each media stream in the session, the invoking UE shall follow the procedure listed above for individual media streams.

If all the media streams were previously on hold and are to be resumed:

– if they all have identical directionality, the invoking UE shall generate a session level direction attribute, or separate media level direction attributes, in the SDP that is set to:

1) "recvonly" if the streams were previously inactive media streams; or

2) "sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since sendrecv is the default; and

– if they all do not have identical directionality, then for each media stream in the session, the invoking UE shall follow the procedure listed above for individual media streams.

If, in the generated SDP offer, there is at least one media stream whose directionality has changed from the previous SDP, the UE shall send the generated SDP offer in a re-INVITE request (or UPDATE request) to the remote UE.

[TS 26.114 clause 7.3.1]:

RTCP packets should be sent for all types of multimedia sessions to enable synchronization with other RTP transported media, remote end-point aliveness information, monitoring of the transmission quality, and carriage of feedback messages such as TMMBR for video and RTCP APP for speech. The RR value should be set greater than zero to enable RTCP packets to be sent when media is put on hold and during active RTP media transmission, including real-time text sessions which may have infrequent RTP media transmissions.

[TS 24.229 clause 6.1.1]:

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.

8.27.3 Test description

8.27.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 set up the MO Video call, by executing the generic test procedure in Annex A.2 up to the last step and thereafter executing the generic test procedure in A.15.1.

8.27.3.2 Test procedure sequence

Table 8.27.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE is made to hold the call

–

–

–

–

2

Check: Does the UE send INVITE or UPDATE with a SDP offer to hold the call?

(step 1 in annex A.24)

–>

INVITE or UPDATE

1

P

3-5

Steps 2-4 in annex A.24 are performed.

–

–

–

–

6

The UE is made to resume the call

–

–

–

–

7

Check: Does the UE send INVITE or UPDATE with a SDP offer to resume the call?

(step 1 in annex A.24)

–>

INVITE or UPDATE

2

P

8-10

Steps 2-4 in annex A.24 are performed.

–

–

–

–

11

The UE is made to release the call

–

–

–

–

12-13

UE releases the call
(Annex A.7)

–

–

–

–

8.27.3.3 Specific message contents

None as fully described in Annex A.24.