7.13 MTSI MT Voice Call with RTCP disabled / 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.13.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 with both b=RS and b=RR attributes set to zero }
then { UE may respond with 100 Trying and then sends 183 Session Progress with SDP with both b=RS and b=RR set to zero and completes setup of voice call with preconditions }
}
7.13.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 26.114, clause 7.3.1]
Point-to-point speech only sessions may not require the above functionalities and may therefore turn off RTCP by setting the SDP bandwidth modifiers (RR and RS) to zero. When RTCP is turned off (for point-to-point speech only sessions) and the media is put on hold, the MTSI client should re-negotiate the RTCP bandwidth with the SDP bandwidth modifier RR value set greater than zero, and send RTCP packets (i.e., Receiver Reports) to the other end. This allows the remote end to detect link aliveness during hold. When media is resumed, the resuming MTSI client should request to turn off the RTCP sending again through a re-negotiation of the RTCP bandwidth with SDP bandwidth modifiers equal to zero.
When RTCP is turned off (for point-to-point speech only sessions) and if sending of an additional associated RTP stream becomes required and both RTP streams need to be synchronized, or if transport feedback due to lack of end-to-end QoS guarantees is needed, a MTSI client should re-negotiate the bandwidth for RTCP by sending an SDP with the RR bandwidth modifier greater than zero. Setting the RR bandwidth modifier greater than zero allows sending of RTCP Receiver Reports even when the session is put on hold and neither terminal is actively sending RTP media.
7.13.3 Profile requirements (Informative)
[GSMA NG.114 V1.0, cl3.6.3]
The RTP implementation must include an RTP Control Protocol (RTCP) implementation according to section 7.3.1 of 3GPP TS 26.114 [16].
The UE and the entities in the IMS core network that terminate the user plane must use symmetric RTCP as defined in IETF RFC 4961 [77], and section 7.3.1 of 3GPP TS 26.114 [16].
The bandwidth for RTCP traffic must be described using the "RS" and "RR" SDP bandwidth modifiers at media level, as specified by IETF RFC 3556 [78], and section 7.3.1 of 3GPP TS 26.114 [16]. Therefore, a UE must include the "b=RS:" and "b=RR:" fields in SDP, and a UE and the entities in the IMS core network that terminate the user plane must be able to interpret them. If the “b=RS:” field or “b=RR:” field or both these fields are not included in a received SDP (offer or answer), then the UE must use the recommended default value for the missing field(s) as defined in IETF RFC 3556 [78].
RTCP is controlled on a per session basis by the SDP offer/answer exchange as defined in section 7.3 of 3GPP TS 26.114 [16] with the following clarifications:
1. If the UE receives an SDP offer that contains “b=RS:” attribute set to zero, then the UE must set the “b=RS:” attribute to zero in an SDP answer to that SDP offer. If the UE receives an SDP offer that contains “b=RR:” attribute set to zero, then the UE must set the “b=RR:” attribute to zero in an SDP answer to that SDP offer. If the UE receives an SDP offer that contains both "b=RR:" and "b=RS:" attributes set to zero, then the UE must not send RTCP packets and must consider RTCP to be disabled for the session.
2. If the UE received an SDP answer containing zero values in both of the “b=RS:” and “b=RR:” attributes, then (regardless of the values assigned to these attributes in the corresponding SDP offer) the UE must not send RTCP packets and must consider RTCP to be disabled for the session.
3. The UE must accept receiving RTCP packets for a session that the UE considers RTCP to be disabled. The UE is not required to process these received RTCP packets.
…
7.13.4 Test description
7.13.4.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.13.4.2 Test procedure sequence
Table 7.13.4.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, with both b=RS and b=RR attributes set to zero in SDP. (Step 1 of Annex A.5.1) |
<– |
INVITE |
||||||||
|
2 |
Optional step: UE may send a 100 Trying provisional response. (Step 2 of Annex A.5.1) |
–> |
100 Trying |
||||||||
|
3 |
Check: Does the UE send 183 Session Progress with both b=RS and b=RR set to zero in SDP? |
–> |
183 Session Progress |
1 |
P |
||||||
|
4 |
SS acknowledges reception of 183 Session Progress. (Step 4 of Annex A.5.1) |
<– |
PRACK |
||||||||
|
5 |
UE responds to PRACK. (Step 5 of Annex A.5.1) |
–> |
200 OK |
1 |
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 a second SDP offer. (Step 6 of Annex A.5.1) |
UPDATE |
|||||||||
|
7 |
UE responds to UPDATE, including an SDP answer. (Step 7 of Annex A.5.1) |
200 OK |
|||||||||
|
8 |
UE sends 180 Ringing. (Step 8 of Annex A.5.1) |
–> |
180 Ringing |
1 |
P |
||||||
|
9 |
Conditional step: if UE sent 180 Ringing reliably, SS acknowledges reception of 180 Ringing. (Step 9 of Annex A.5.1) |
<– |
PRACK |
||||||||
|
10 |
Conditional step: if UE sent 180 Ringing reliably, UE responds to PRACK. (Step 10 of Annex A.5.1) |
–> |
200 OK |
||||||||
|
11 |
Make UE accept the voice call. |
||||||||||
|
12 |
UE responds to INVITE. (Step 11 of Annex A.5.1) |
–> |
200 OK |
||||||||
|
13 |
SS acknowledges. (Step 12 of Annex A.5.1) |
<– |
ACK |
||||||||
7.13.4.3 Specific message contents
Table 7.13.4.3-1: INVITE (step 1, table 7.13.4.2-1)
|
Derivation Path: TS 34.229-5, Step 1 of A.5.1, with following exceptions |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
Media description: b=RR:0 |
TS 26.114 [33] GSMA NG.114 [31] |
||
Table 7.13.4.3-2: 183 Session Progress (step 3, table 7.13.4.2-1)
|
Derivation Path: TS 34.229-5, Step 3 of A.5.1, with following exceptions |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
Media description: b=RS: 0 b=RR: 0 |
TS 26.114 [33] GSMA NG.114 [31] |
||
Table 7.13.4.3-3: UPDATE (step 6, table 7.13.4.2-1)
|
Derivation Path: TS 34.229-5, Step 6 of A.5.1, with following exceptions |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
Media description: b=RR:0 |
TS 26.114 [33] GSMA NG.114 [31] |
||
Table 7.13.4.3-4: 200 OK (step 7, table 7.13.4.2-1)
|
Derivation Path: TS 34.229-5, Step 7 of A.5.1, with following exceptions |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
Media description: b=RS: 0 b=RR: 0 |
TS 26.114 [33] GSMA NG.114 [31] |
||