7.4 MTSI MO Voice Call with preconditions at both originating 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.4.1 Test Purpose (TP)
(1)
with { UE being registered to IMS and configured to use preconditions }
ensure that {
when { UE is being made to initiate a voice call }
then { UE sends INVITE for voice call with preconditions }
}
(2)
with { UE having sent INVITE with preconditions }
ensure that {
when { UE receives 100 Trying followed by 183 Session Progress }
then { UE sends PRACK for 183 Session Progress }
}
(3)
with { UE having sent PRACK }
ensure that {
when { UE receives 200 OK for PRACK and resources are available }
then { UE sends UPDATE }
}
(4)
with { UE having sent UPDATE }
ensure that {
when { UE receives 200 OK for UPDATE followed by 180 Ringing sent reliably }
then { UE sends PRACK for 180 Ringing }
}
(5)
with { UE having sent PRACK for 180 Ringing }
ensure that {
when { UE receives 200 OK for PRACK followed by 200 OK for INVITE }
then { UE sends ACK }
}
7.4.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.2A.1.1]:
The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.
When the UE re-uses a previously registered contact address, the UE shall remove any parameters dedicated to registration from the Contact header field (e.g. "expires").
When the UE sends any request, the UE shall use either a given contact address that has been previously registered or a registration flow and the associated contact address (if the multiple registration mechanism is used) and shall:
– if IMS AKA is in use as a security mechanism:
a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port and the respective contact address; and
b) include the protected server port and the respective contact address in the Via header field entry relating to the UE;
If this is a request for a new dialog, the Contact header field is populated as follows:
1) a contact header value which is one of:
– if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then the UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627 [93]; or
– if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert the temporary GRUU ("temp-gruu" header field parameter) value as specified in RFC 5627 [93];
– otherwise, a SIP URI containing the contact address of the UE that has been previously registered without any contact parameters dedicated to registration procedure;
NOTE 7: The above items are mutually exclusive.
2) include an "ob" SIP URI parameter, if the UE supports multiple registrations, and the UE wants all subsequent requests in the dialog to arrive over the same flow identified by the flow token as described in RFC 5626 [92];
3) if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3841 [56B], the ICSI value (coded as specified in subclause 7.2A.8.2) for the IMS communication service. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the terminating UE(s); and
4) if the request is related to an IMS application that is supported by the UE, then the UE may include in a g.3gpp.iari-ref media feature tag, as defined in subclause 7.9.3 and RFC 3841 [56B], the IARI value (coded as specified in subclause 7.2A.9.2) that is related to the IMS application and that applies for the dialog.
…
If this is a request for a new dialog or standalone transaction and the request is related to an IMS communication service that requires the use of an ICSI then the UE:
1) shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that is related to the request in a P-Preferred-Service header field according to RFC 6050 [121]. If a list of network supported ICSI values was received as specified in 3GPP TS 24.167 [8G], the UE shall only include an ICSI value that is in the received list;
NOTE 8: The UE only receives those ICSI values corresponding to the IMS communication services that the network provides to the user.
2) may include an Accept-Contact header field containing an ICSI value (coded as specified in subclause 7.2A.8.2) that is related to the request in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 if the ICSI for the IMS communication service is known. The UE may remove one or more subclasses from an ICSI when including it in an Accept-Contact header field provided that the included ICSI corresponds to an IMS communication service.
NOTE 9: If the UE includes the same ICSI values into the Accept-Contact header field and the P-Preferred-Service header field, there is a possibility that one of the involved S-CSCFs or an AS changes the ICSI value in the P-Asserted-Service header field, which results in the message including two different ICSI values (one in the P-Asserted-Service header field, changed in the network and one in the Accept-Contact header field).
…
If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall insert a P-Access-Network-Info header field into any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see subclause 7.2A.4). Insertion of the P-Access-Network-Info header field into the ACK request is optional.
NOTE 13: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header field in any request or response within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).
NOTE 14: The value of the P-Access-Network-Info header field could be stale if the point of attachment of the UE with the network changes before the message is received by the network.
The UE shall build a proper preloaded Route header field value for all new dialogs and standalone transactions. The UE shall build a list of Route header field values made out of the following, in this order:
a) the P-CSCF URI containing the IP address acquired at the time of the P-CSCF discovery procedures which was used in registration of the contact address (or registration flow); and
NOTE 15: If the UE is provisioned with or receives a FQDN at the time of the P-CSCF discovery procedures, the FQDN is resolved to an IP address at the time of the P-CSCF discovery procedures.
b) the P-CSCF port based on the security mechanism in use:
– if IMS AKA or SIP digest with TLS is in use as a security mechanism, the protected server port learnt during the registration procedure;
– if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is in use as a security mechanism, the unprotected server port used during the registration procedure;
c) and the values received in the Service-Route header field saved from the 200 (OK) response to the last registration or re-registration of the public user identity with associated contact address.
NOTE 16: When the UE registers multiple contact addresses, there will be a list of Service-Route headers for each contact address. When sending a request using a given contact address and the associated security associations or TLS session, the UE will use the corresponding list of Service-Route headers to construct a list of Route headers.
[TS 24.229, clause 5.1.2A.1.2]:
The UE may include a SIP URI complying with RFC 3261 [26], a tel URI complying with RFC 3966 [22], a pres URI complying with RFC 3859 [179], an im URI complying with RFC 3860 [180] or a mailto URI complying with RFC 2368 [181].
NOTE: This version of the document does not specify how the UE determines the host part of the SIP URI.
The UE may use non-international formats of E.164 numbers or non-E.164 numbers, including geo-local numbers and home-local numbers and other local numbers (e.g. private number), in the Request-URI.
The actual value of the URI depends on whether user equipment performs an analysis of the dial string input by the end user or not, see subclauses 5.1.2A.1.3 and 5.1.2A.1.4.
[TS 24.229, clause 5.1.2A.1.5]:
When the UE uses home-local number, the UE shall include in the "phone-context" tel URI parameter the home network domain name in accordance with RFC 3966 [22].
When the UE uses geo-local number, the UE shall:
– if access technology information available to the UE (i.e., the UE can insert P-Access-Network-Info header field into the request), include the access technology information in the "phone-context" tel URI parameter according to RFC 3966 [22] as defined in subclause 7.2A.10; and
– if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-Info header field into the request), include in the "phone-context" tel URI parameter the home network domain name prefixed by the "geo-local." string according to RFC 3966 [22] as defined in subclause 7.2A.10.
When the UE uses other local numbers, than geo-local number or home local numbers, e.g. private numbers that are different from home-local number or the UE is unable to determine the type of the dialled number, the UE shall include a "phone-context" tel URI parameter set according to RFC 3966 [22], e.g. if private numbers are used a domain name to which the private addressing plan is associated. The "phone-context" value used in the case of other local numbers shall be different from "phone-context" values used with geo-local numbers and home-local numbers.
NOTE 1: The "phone-context" tel URI parameter value can be entered or selected by the subscriber, or can be a "pre-configured" value (e.g. using OMA-DM with the management object specified in 3GPP TS 24.167 [8G]) inserted by the UE.
NOTE 2: The way how the UE determines whether numbers in a non-international format are geo-local, home-local or relating to another network in absence of matching UE configuration in subclause 5.1.2A.1.5A, is implementation specific.
NOTE 3: Home operator’s local policy can define a prefix string(s) to enable subscribers to differentiate dialling a geo-local number and/or a home-local number.
[TS 24.229, clause 5.1.3.1]:
Upon generating an initial INVITE request, the UE shall include the Accept header field with "application/sdp", the MIME type associated with the 3GPP IM CN subsystem XML body (see subclause 7.6.1) and any other MIME type the UE is willing and capable to accept.
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.5A]:
The precondition disabling policy indicates whether the UE is allowed to use the precondition mechanism or whether the UE is not allowed to use the precondition mechanism.
If the precondition disabling policy is not configured, the precondition disabling policy is assumed to indicate that the UE is allowed to use the precondition mechanism.
The UE may support the precondition disabling policy.
If the UE supports the precondition disabling policy, the UE may support being configured with the precondition disabling policy using one or more of the following methods:
a) the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.102 [15C];
b) the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.103 [15B]; and
c) the Precondition_disabling_policy node of 3GPP TS 24.167 [8G].
If the UE is configured with both the Precondition_disabling_policy node of 3GPP TS 24.167 [8G] and the Precondition_disabling_policy node of the EFIMSConfigData file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the Precondition_disabling_policy node of the EFIMSConfigData file shall take precedence.
NOTE: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].
The precondition mechanism is disabled, if the UE supports the precondition disabling policy and the precondition disabling policy indicates that the UE is not allowed to use the precondition mechanism.
The precondition mechanism is enabled, if:
1) the UE does not support the precondition disabling policy; or
2) the UE supports the precondition disabling policy and the precondition disabling policy indicates that the UE is allowed to use the precondition mechanism.
[TS 24.229, clause 6.1.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].
NOTE 1: A codec can have multiple payload type numbers associated with it.
In order to support accurate bandwidth calculations, the UE may include the "a=ptime" attribute for all "audio" media lines as described in RFC 4566 [39]. If a UE receives an "audio" media line with "a=ptime" specified, the UE should transmit at the specified packetization rate. If a UE receives an "audio" media line which does not have "a=ptime" specified or the UE does not support the "a=ptime" attribute, the UE should transmit at the default codec packetization rate as defined in RFC 3551 [55A]. The UE will transmit consistent with the resources available from the network.
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.
NOTE 2: The above is the minimum requirement for all UEs. Additional requirements can be found in other specifications.
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].
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.
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 draft-ietf-mmusic-sdp-simulcast [249]), apply the procedures defined in 3GPP TS 26.114 [9B] annex S.
[TS 26.114, clause 5.2.1.1]:
MTSI clients in terminals offering speech communication shall support narrowband, wideband and super-wideband communication.
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.
MTSI clients in terminals offering wideband speech communication at 16 kHz sampling frequency shall support:
– AMR-WB codec (3GPP TS 26.171 [17], 3GPP TS 26.190 [18], 3GPP TS 26.173 [19] and 3GPP TS 26.204 [20]) including all 9 modes and source controlled rate operation 3GPP TS 26.193 [21]. The MTSI client in terminal shall be capable of operating with any subset of these 9 codec modes. More detailed codec requirements for the AMR-WB codec are defined in clause 5.2.1.3. When the EVS codec is supported, the EVS AMR-WB IO mode may serve as an alternative implementation of AMR-WB as defined in clause 5.2.1.4.
MTSI clients in terminals offering super-wideband or full band speech communication shall support:
– EVS codec ( TS 26.441 [121], TS 26.444 [124], TS 26.445 [125], TS 26.447 [127], TS 26.451 [131], TS 26.442 [122] and TS 26.443 [123]) as described below including functions for backwards compatibility with AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and TS 26.450 [130]). More detailed codec requirements for the EVS codec are defined in clause 5.2.1.4.
[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].
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]. Therefore, an MTSI client shall include the "b=RS:" and "b=RR:" fields in SDP, and shall be able to interpret them. There shall be an upper limit on the allowed RTCP bandwidth for each RTP session signalled by the MTSI client. This limit is defined as follows:
– 8 000 bps for the RS field (at media level);
– 6 000 bps for the RR field (at media level).
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.
If the session described in the SDP is a point-to-point speech only session, the MTSI client may request the deactivation of RTCP by setting its RTCP bandwidth modifiers to zero.
If a MTSI client receives SDP bandwidth modifiers for RTCP equal to zero from the originating MTSI client, it should reply (via the SIP protocol) by setting its RTCP bandwidth using SDP bandwidth modifiers with values equal to zero.
7.4.2A Profile requirements (Informative)
[NG.114 Version 1.0, clause 2.3.4.1]:
The ICSI value used must indicate the IMS Multimedia Telephony service, which is urn:urn-7:3gpp-service.ims.icsi.mmtel, as specified in 3GPP TS 24.173 [10].
…
The UE must include the audio and video media feature tags, as defined in IETF RFC 3840 [18], in the Contact header field of the SIP INVITE request, and in the Contact header field of the SIP response to the SIP INVITE request, as specified in 3GPP TS 24.229 [8].
[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. If preconditions are used, and the originating UE receives the selected codec in the SDP of a SIP 18x response, then the UE must include only the same codec with its selected configuration parameters in the SDP of the SIP UPDATE request, used for precondition status update.
[NG.114 Version 1.0 and 2.0, clause 3.2.2.1]:
The UE must include in an initial SDP offer at least:
1. one EVS payload type with one of the configurations supporting super-wideband speech as defined in section 3.2.2.3 of this document.
2. one AMR-WB payload type with no mode-set specified as defined in table 6.1 of 3GPP TS 26.114 [16].
3. one AMR payload type with no mode-set specified as defined in table 6.1 of 3GPP TS 26.114 [16].
The codec preference order must be as specified in sections 5.2.1.5 and 5.2.1.6 of 3GPP TS 26.114 [16].
[NG.114 Version 1.0, clause 3.2.2.2 on AMR and AMR-WB]:
The UE must set the b=AS to match the highest codec mode for the offer (maximum codec bit rate if no mode set is included).
[NG.114 Version 1.0 and 2.0, clause 3.2.2.3 on EVS]:
The UE that sends the SDP offer for voice media must include in this SDP offer at least one EVS payload type with one of the following EVS configurations:
1. EVS Configuration A1: br=5.9-13.2; bw=nb-swb.
2. EVS Configuration A2: br=5.9-24.4; bw=nb-swb.
3. EVS Configuration B0: br=13.2; bw=swb.
4. EVS Configuration B1: br=9.6-13.2; bw=swb.
5. EVS Configuration B2: br=9.6-24.4; bw=swb.
…
SDP parameters other than br, bw, max-red and ch-aw-recv must not be included in a media format description associated with the EVS codec within the initial SDP offer (for a list of SDP parameters see table 6.2a in 3GPP TS 26.114 [16]).
…
The configuration of the EVS payload type to be included first in the initial SDP offer for EVS is defined by the EVS/Br and EVS/Bw parameters as specified in Annex C.3, which must be configured to one of the five above EVS Configurations.
[NG.114 Version 1.0, clause 3.2.3]:
The UE and the entities in the IMS core network that terminate the user plane must set the ptime attribute value to receive one speech frame encapsulated in each RTP packet, but must accept any number of frames per RTP packet, up to the maximum limit of 12 speech frames per RTP packet.
Note 1: This means that the ptime attribute must be set to 20 and the maxptime attribute must be set to 240 in the SDP negotiation.
7.4.3 Test description
7.4.3.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 (TS 38.508-1 [21]) and registered to IMS
7.4.3.2 Test procedure sequence
Table 7.4.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||||
|
U – S |
Message |
||||||||||
|
1 |
UE is made to attempt an IMS 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 to step 2 below, the steps specified in Table 7.4.3.2-2 are performed. |
– |
– |
– |
– |
||||||
|
2 |
UE sends INVITE with first SDP offer |
–> |
INVITE |
1 |
P |
||||||
|
3 |
SS sends a 100 Trying provisional response |
<– |
100 Trying |
– |
– |
||||||
|
4 |
SS sends an SDP answer |
<– |
183 Session Progress |
– |
– |
||||||
|
5 |
UE acks 183 Session Progress |
–> |
PRACK |
2 |
P |
||||||
|
6 |
SS responds to PRACK |
<– |
200 OK |
– |
– |
||||||
|
6A |
Step 10 of the 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 7 occurs. |
– |
– |
– |
– |
|||||||
|
6B-6C |
Steps 11-12 of the generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
||||||
|
7 |
UE sends UPDATE with second SDP offer |
–> |
UPDATE |
3 |
P |
||||||
|
8 |
SS sends an SDP answer |
<– |
200 OK |
– |
– |
||||||
|
9 |
SS sends 180 Ringing reliably |
<– |
180 Ringing |
– |
– |
||||||
|
10 |
UE acks 180 Ringing |
–> |
PRACK |
4 |
P |
||||||
|
11 |
SS responds to PRACK |
<– |
200 OK |
– |
– |
||||||
|
12 |
SS responds to INVITE |
<– |
200 OK |
– |
– |
||||||
|
13 |
UE acks 200 OK for INVITE |
–> |
ACK |
5 |
P |
||||||
Table 7.4.3.2-2: Parallel Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
Step 8 of the generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] is performed. |
– |
– |
– |
– |
7.4.3.3 Specific message contents
None as fully described in Annex A.4.1.