7.20 MTSI MO Voice Call / add video and remove video / 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.20.1 Test Purpose (TP)
(1)
with { UE is configured to use preconditions and has set up a voice call with preconditions }
ensure that {
when { UE is made to add video to the voice call }
then { UE sends re-INVITE with SDP media for both voice and video }
}
(2)
with { UE having sent re-INVITE }
ensure that {
when { UE receives 100 Trying and 183 Session in Progress with SDP answer }
then { UE acks with PRACK }
}
(3)
with { UE having sent PRACK }
ensure that {
when { UE receives 200 OK for PRACK and indication that resources are reserved }
then { UE sends UPDATE with SDP offer indicating reserved resources }
}
(4)
with { UE having sent UPDATE }
ensure that {
when { UE receives 200 OK for UPDATE followed by 200 OK for re-INVITE }
then { UE sends ACK }
}
(5)
with { UE having successfully added video }
ensure that {
when { UE is made to remove video again }
then { UE sends re-INVITE with SDP indicating that video is being removed from the call }
}
(6)
with { UE having sent re-INVITE }
ensure that {
when { UE receives 100 Trying followed by 200 OK and indication that video resources have been removed }
then { UE sends ACK }
}
7.20.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.173, clause 5.2]:
The IMS multimedia telephony communication service can support different types of media, including media types listed in 3GPP TS 22.173 [2]. The session control procedures for the different media types shall be in accordance with 3GPP TS 24.229 [13] and 3GPP TS 24.247 [14], with the following additions:
a) Multimedia telephony is an IMS communication service and the P-Preferred-Service and P-Asserted-Service headers shall be treated as described in 3GPP TS 24.229 [13]. The coding of the ICSI value in the P-Preferred-Service and P-Asserted-Service headers shall be according to subclause 5.1.
[TS 24.229, clause 5.1.2A.1]:
If this is a request within an existing dialog, and the request includes a Contact header field, then the UE should insert the previously used Contact header field.
…
After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.
[TS 24.229, clause 5.1.3]:
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].
The preconditions mechanism should be supported by the originating UE.
If the precondition mechanism is disabled as specified in subclause 5.1.5A, the UE shall not use the precondition mechanism.
The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource reservation.
NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.
In order to allow the peer entity to reserve its required resources, if the precondition mechanism is enabled as specified in subclause 5.1.5A; the originating UE supporting the precondition mechanism should make use of the precondition mechanism, even if it does not require local resource reservation.
Upon generating an initial INVITE request using the precondition mechanism, the UE shall:
– indicate the support for reliable provisional responses and specify it using the Supported header field; and
– indicate the support for the preconditions mechanism and specify it using the Supported header field.
Upon generating an initial INVITE request using the precondition mechanism, the UE shall not indicate the requirement for the precondition mechanism by using the Require header field.
During the session initiation, if the originating UE indicated the support for the precondition mechanism in the initial INVITE request and:
a) the received response with an SDP body includes a Require header field with "precondition" option-tag, the originating UE shall include a Require header field with the "precondition" option-tag:
– in subsequent requests that include an SDP body, that the originating UE sends in the same dialog as the response is received from; and
– in responses with an SDP body to subsequent requests that include an SDP body and include "precondition" option-tag in Supported header field or Require header field received in-dialog; or
b) the received response with an SDP body does not include the "precondition" option-tag in the Require header field,
– in subsequent requests that include an SDP body, the originating UE shall not include a Require or Supported header field with "precondition" option-tag in the same dialog;
– in responses with an SDP body to subsequent requests with an SDP body but without "precondition" option-tag in the Require or Supported header field, the originating UE shall not include a Require or Supported header field with "precondition" option-tag in the same dialog; and
– in responses with an SDP body to subsequent requests with an SDP body and with "precondition" option-tag in the Require or Supported header field, the originating UE shall include a Require header field with "precondition" option-tag in the same dialog.
NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. The UE can accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited number of simultaneous transactions or early dialogs.
Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see subclause 6.1.2) within the next SIP request.
NOTE 3: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on one or both sides, alternatively a reINVITE request can be used for this confirmation after a 200 (OK) response has been received for the initial INVITE request, in case the terminating UE does not support the PRACK request (as described in RFC 3262 [27]) and does not support the UPDATE request (as described in RFC 3311 [29]).
NOTE 4: The UE can receive a P-Early-Media header field authorizing an early-media flow while the required preconditions, if any, are not met and/or the flow direction is not enabled by the SDP direction parameter. According to RFC 5009 [109], an authorized early-media flow can be established only if the necessary conditions related to the SDP negotiation are met. These conditions can evolve during the session establishment.
NOTE 5: When the UE is confirming the successful resource reservation using an UPDATE request (or a PRACK request) and the UE receives a 180 (Ringing) response or a 200 (OK) response to the initial INVITE request before receiving a 200 (OK) response to the UPDATE request (or a 200 (OK) response to the PRACK request), the UE does not treat this as an error case and does not release the session.
NOTE 6: The UE procedures for rendering of the received early media and of the locally generated communication progress information are specified in 3GPP TS 24.628 [8ZF].
[TS 24.229, clause 5.1.4A.1]:
If the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, the UE shall indicate support of the precondition mechanism during a session modification. If the precondition mechanism was not used during the session establishment, the UE shall not indicate support of the precondition mechanism during a session modification.
In order to indicate support of the precondition mechanism during a session modification, upon generating a reINVITE request, an UPDATE request with an SDP body, or a PRACK request with an SDP body, the UE shall:
a) indicate the support for the precondition mechanism using the Supported header field;
b) not indicate the requirement for the precondition mechanism using the Require header field; and
c) if a re-INVITE request is being generated, indicate the support for reliable provisional responses using the Supported header field;
[TS 24.229, clause 5.1.4A.2]:
Upon receiving a reINVITE request, an UPDATE request, or a PRACK request that indicates support for the precondition mechanism by using the Supported header field or requires use of the precondition mechanism by using the Require header field, the UE shall:
a) if the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, use the precondition mechanism for the session modification; and
…
If the precondition mechanism is used for the session modification, the UE shall indicate support for the preconditions mechanism, using the Require header field, in responses that include an SDP body, to the session modification request.
[TS 24.229, clause 6.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.
In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources. In this case the UE shall indicate as met the local preconditions related to the media stream, for which resources are re-used.
[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 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.
[TS 26.114, clause 6.2.1a.1]
MTSI clients should support SDPCapNeg to be able to negotiate RTP profiles for all media types where AVPF is supported. MTSI clients supporting SDPCapNeg shall support the complete SDPCapNeg framework.
SDPCapNeg is described in [69]. This clause only describes the SDPCapNeg attributes that are directly applicable for the RTP profile negotiation, i.e. the tcap, pcfg and acfg attributes. TS 24.229 [7] may outline further requirements needed for supporting SDPCapNeg in SDP messages.
NOTE: This clause describes only how to use the SDPCapNeg framework for RTP profile negotiation using the tcap, pcfg and acfg attributes. Implementers may therefore (incorrectly) assume that it is sufficient to implement only those specific parts of the framework that are needed for RTP profile negotiation. Doing so would however not be future proof since future versions may use other parts of the framework and there are currently no mechanisms for declaring that only a subset of the framework is supported. Hence, MTSI clients are required to support the complete framework.
[TS 26.114, clause 6.2.1a.2]
For voice and real-time text, SDPCapNeg shall be used when offering AVPF the first time for a new media type in the session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client shall either offer AVPF and AVP together using SDPCapNeg, or the MTSI client shall offer only AVPF without using SDPCapNeg. If an MTSI client has offered only AVPF for video, and then receives as response either an SDP answer where the video media component has been rejected, or an SIP 488 or 606 failure response with an SDP body indicating that only AVP is supported for video media, the MTSI client should send a new SDP offer with AVP as transport for video. Subsequent SDP offers, in a re-INVITE or UPDATE, may offer AVPF without SDPCapNeg if it is known from an earlier re-INVITE or UPDATE that the answering client supports this RTP profile. If the offer includes only AVP then SDPCapNeg does not need to be used, which can occur for: text; speech if RTCP is not used; and in re-INVITEs or UPDATEs where the RTP profile has already been negotiated for the session in a preceding INVITE or UPDATE.
When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:
the support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF shall be preferred over AVP.
at least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.
[TS 26.114, clause 6.2.3.2]:
If video is used in a session, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5, RTP profile, video codec, profile and level. The "imageattr" attribute as specified in [76] should be supported. The "framesize" attribute as specified in [60] shall not be used in the session setup.
An MTSI client shall offer AVPF for all media streams containing video. RTP profile negotiation shall be done as described in clause 6.2.1a.
[TS 26.114, clause 6.2.5.1]:
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].
An MTSI client in terminal should include the ‘a=bw-info’ attribute in the SDP offer. When accepting a media type where the ‘a=bw-info’ attribute is included the MTSI client in terminal shall include the ‘a=bw-info’ attribute in the SDP answer if it supports the attribute. The ‘a=bw-info’ attribute and the below used bandwidth properties are defined in clause 19.
[TS 26.114, clause 6.3]:
During session renegotiation for adding or removing media components, the SDP offerer should continue to use the same media (m=) line(s) from the previously negotiated SDP for the media components that are not being added or removed.
An MTSI client in terminal may support multiple media components including media components of the same media type. An MTSI client in terminal may support adding one or more media components to an on-going session which already contains a media component of the same media type. If an MTSI client in terminal needs to have multiple media components of the same media type in a single MTSI session, then the MTSI client in terminal should use the SDP content attributes as defined in [81] for identifying different media components.
[TS 26.114, clause 7.3.1]
The RS and RR values included in the SDP answer should be treated as the negotiated values for the session and should be used to calculate the total RTCP bandwidth for all terminals in the session.
7.20.3 Test description
7.20.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:
– UE has registered to IMS services and set up the MO call, by executing annex A.4.1.
7.20.3.2 Test procedure sequence
Table 7.20.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||||
|
U – S |
Message |
||||||||||
|
1 |
Make UE add video to the voice call |
– |
– |
||||||||
|
2 |
Check: Does the UE send re-INVITE with an SDP offer containing media lines for both voice and video? |
-> |
INVITE |
1 |
P |
||||||
|
3 |
The SS responds with a 100 Trying provisional response |
<- |
100 Trying |
– |
– |
||||||
|
4 |
SS responds with an SDP answer indicating that SS has not reserved its resources for video |
<- |
183 Session in Progress |
– |
– |
||||||
|
5 |
Check: Does the UE acknowledge the receipt of 183 response with PRACK? |
-> |
PRACK |
2 |
P |
||||||
|
6 |
The SS responds PRACK with 200 OK. |
<- |
200 OK |
– |
– |
||||||
|
6A |
SS reserves resources for video by executing TS 38.508-1 cl 4.9.27 |
– |
– |
– |
– |
||||||
|
7 |
Check: Does the UE send an UPDATE after having reserved the resources for video if meeting the preconditions indicated in step 4? |
-> |
UPDATE |
3 |
P |
||||||
|
8 |
The SS responds UPDATE with 200 OK and indicates having reserved the resources |
<- |
200 OK |
– |
– |
||||||
|
9 |
The SS responds re-INVITE with 200 OK |
<- |
200 OK |
– |
– |
||||||
|
10 |
Check: Does the UE acknowledge the receipt of 200 OK for re-INVITE? |
-> |
ACK |
4 |
P |
||||||
|
11 |
Make UE release video from the media call |
– |
– |
||||||||
|
12 |
Check: Does the UE send re-INVITE with a SDP offer indicating that the video component is removed from the call? |
-> |
INVITE |
5 |
P |
||||||
|
13 |
The SS responds with a 100 Trying provisional response |
<- |
100 Trying |
– |
– |
||||||
|
14 |
SS releases the QoS flow for video by executing TS 38.508-1 cl 4.9.28. |
– |
– |
||||||||
|
15 |
The SS responds re-INVITE with 200 OK |
<- |
200 OK |
– |
– |
||||||
|
16 |
Check: Does the UE acknowledge the receipt of 200 OK for re-INVITE? |
-> |
ACK |
6 |
P |
||||||
|
17 |
Make the UE release the call. |
– |
– |
– |
– |
||||||
|
18-19 |
UE releases the call |
— |
– |
– |
– |
||||||
7.20.3.3 Specific message contents
Table 7.20.3.3-1: re-INVITE (step 2, table 7.20.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1, A5 and A28. |
|||||||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|||||
|
Supported |
|||||||||
|
option-tag |
precondition |
||||||||
|
Message-body |
Same SDP body as in Step 6 (UPDATE) of Annex A.15.1, with following differences: For preconditions of audio media: a=curr:qos remote sendrecv For preconditions of video media: a=curr:qos local none |
TS 24.229 [7] TS 26.114 [33] |
|||||||
Table 7.20.3.3-2: 100 Trying (step 3, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, Step 2 |
Table 7.20.3.3-3: 183 Session in Progress (step 4, table 7.20.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Annex A.2.3, Condition A1 |
|||||||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|||||
|
Require |
|||||||||
|
option-tag |
precondition |
||||||||
|
Message-body |
Same SDP body as in Step 3 (183 Session in Progress) of Annex A.15.1, with following exceptions: For preconditions of audio media: a=curr:qos local sendrecv a=curr:qos remote sendrecv Session description: "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one |
TS 24.229 [7] TS 26.114 [33] |
|||||||
Table 7.20.3.3-4: PRACK (step 5, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, Step 4 |
Table 7.20.3.3-5: 200 OK for PRACK (step 6, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, Step 5 |
Table 7.20.3.3-6: UPDATE (step 7, table 7.20.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Annex A.2.5, conditions A1 and A6. |
|||||||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|||||
|
Supported |
|||||||||
|
option-tag |
precondition |
||||||||
|
Message-body |
Same contents as specified in step 6 (UPDATE) of A.15.1 with the following exceptions: For preconditions of audio media: |
TS 24.229 [7] TS 26.114 [33] |
|||||||
Table 7.20.3.3-7: 200 OK for UPDATE (step 8, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1 Step 7 |
Table 7.20.3.3-8: 200 OK for re-INVITE (step 9, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, Step 11 |
Table 7.20.3.3-9: ACK for re-INVITE (step 10, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, Step 12 |
Table 7.20.3.3-10: re-INVITE (step 12, table 7.20.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Annex A.2.1, conditions A1, A5 and A28. |
|||||||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|||||
|
Supported |
|||||||||
|
option-tag |
precondition |
||||||||
|
Message-body |
Same SDP body as in Step 2 (re-INVITE), with following exceptions and no requirements on b-, c- or a-lines on the video stream: Media description: m=video 0 RTP/AVPF (fmt) |
TS 24.229 [7] TS 26.114 [33] |
|||||||
Table 7.20.3.3-11: 100 Trying (step 13, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, step 2 |
Table 7.20.3.3-12: 200 OK for INVITE (step 15, table 7.20.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A2, A5, A11, A20 and A22 |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Require |
||||
|
option-tag |
precondition |
|||
|
Content-Type |
||||
|
media-type |
application/sdp |
|||
|
Content-Length |
header shall be present if UE uses TCP to send this message and if there is a message body |
|||
|
value |
length of message-body |
|||
|
Message-body |
SDP body copied from the received re-INVITE in step 12 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; – "o=" line identical to previous SDP sent by SS except that sess-version is incremented |
|||
Table 7.20.3.3-13: ACK (step 16, table 7.20.3.2-1)
|
Derivation Path: Annex A.15.1, step 12 |