7.18 MTSI MO Voice Call / EVS / AMR-WB / 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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.18.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 183 Session Progress indicating AMR-WB }

then { UE sends PRACK for 183 Session Progress and, after receiving 200 OK for PRACK, agrees to AMR-WB via UPDATE }

}

7.18.2 Conformance Requirements

[TS 24.229, clause 5.1.3.1]:

Where multiple domains exist for initiating a call/session, before sending an initial INVITE request, the UE shall perform access domain selection in accordance with the appropriate specification for the IP-CAN in use, taking into account the media to be requested. Access domain selection allows the policy of the network operator to be taken into account before the initial INVITE request is sent. Access dependent aspects of access domain selection are defined in the access technology specific annexes for each access technology.

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.

…

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].

If the UE wishes to receive early media authorization indications, as described in RFC 5009 [109], the UE shall add the P-Early-Media header field with the "supported" parameter to the initial INVITE request.

A UE supporting the Session Timer extension as described in RFC 4028 [58] may support the extension being configured using Session_Timer_Support node specified in 3GPP TS 24.167 [8G].

If the UE supports the Session Timer extension, the UE shall include the option-tag "timer" in the Supported header field and should either insert a Session-Expires header field with the header field value set to the configured session timer interval value, or should not include the Session-Expires header field in the initial INVITE request. The header field value of the Session-Expires header field may be configured using local configuration or using the Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G]. If the UE is configured with both the local configuration and the Session_Timer_Initial_Interval node specified in 3GPP 24.167 [8G], then the local configuration shall take precedence.

If the UE inserts the Session-Expires header field in the initial INVITE request, the UE may also include the "refresher" parameter with the "refresher" parameter value set to "uac".

…

The UE may include a "cic" tel URI parameter in a tel URI, or in the userinfo part of a SIP URI with user=phone, in the Request-URI of an initial INVITE request if the UE wants to identify a user-dialled carrier, as described in RFC 4694 [112].

NOTE 8: The method whereby the UE determines when to include a "cic" tel-URI parameter and what value it should contain is outside the scope of this document (e.g. the UE could use a locally configured digit map to look for special prefix digits that indicate the user has dialled a carrier).

NOTE 9: The value of the "cic" tel-URI parameter reported by the UE is not dependent on UE location (e.g. the reported value is not affected by roaming scenarios).

[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 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.

For "video" and "audio" media types that use the RTP/RTCP and where the port number is not zero, the UE may include for each RTP payload type "a=bw-info" SDP attribute(s) (defined in clause 19 of 3GPP TS 26.114 [9B]) to indicate the additional bandwidth information. The "a=bw-info" SDP attribute line(s) shall be specified in accordance with 3GPP TS 26.114 [9B]. The value of the "a=bw-info" SDP attribute(s) may affect the assigned QoS which is defined in 3GPP TS 29.213 [13C].

For "video" and "audio" media types that utilize the RTP/RTCP, in addition to the "b=AS" parameter, the UE may specify the "b=TIAS", and "a=maxprate" parameters in accordance with RFC 3890 [152]. The value of the parameter shall be determined as described in RFC 3890 [152]. The value or absence of the "b=" parameter(s) may affect the assigned QoS which is defined in 3GPP TS 29.213 [13C].

If a UE receives a media line which contains both a=ptime and a=maxprate, the UE should use the a=maxprate value, if this attribute is supported.

If multiple codecs are specified on the media line, "a=maxprate" (or "a=ptime" if "a=maxprate" is not available or not supported) should be used to derive the packetization time used for all codecs specified on the media line. Given that not all codecs support identical ranges of packetization, the UE should ensure that the packetization derived by "a=maxprate" (or "a=ptime" if "a=maxprate" is not available or not supported) is a valid packetization time for each codec specified in the list.

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.

…

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.

[TS 26.114, clause 5.2.1.1]:

MTSI clients in terminals offering speech communication shall support narrowband, wideband and super-wideband communication. The only exception to this requirement is for the MTSI client in constrained terminal offering speech communication, in which case the MTSI client in constrained terminal shall support narrowband and wideband, and should support 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 fullband 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], TS 26.452 [165] 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.

Encoding of DTMF is described in Annex G.

[TS 26.114, clause 6.2.2.1]:

For AMR or AMR-WB encoded media, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5, what RTP profile to use; if all codec modes can be used or if the operation needs to be restricted to a subset; if the bandwidth-efficient payload format can be used or if the octet-aligned payload format must be used; if codec mode changes shall be restricted to be aligned to only every other frame border or if codec mode changes can occur at any frame border; if codec mode changes must be restricted to only neighbouring modes within the negotiated codec mode set or if codec mode changes can be performed to any mode within the codec mode set; the number of speech frames that should be encapsulated in each RTP packet and the maximum number of speech frames that may be encapsulated in each RTP packet. For EVS encoded media, the session setup shall determine the RTP profile to use in the session.

If the session setup negotiation concludes that multiple configuration variants are possible in the session then the default operation should be used as far as the agreed parameters allow, see clause 7.5.2.1. It should be noted that the default configurations are slightly different for different access types.

An MTSI client offering a speech media session for narrow-band speech and/or wide-band speech should generate an SDP offer according to the examples in Annexes A.1 to A.3. An MTSI client offering EVS should generate an SDP offer according to the examples in Annex A.14.

An MTSI client in terminal supporting EVS should support the RTCP-APP signalling for speech adaptation defined clause 10.2.1, and shall support the RTCP-APP signalling when the MTSI client in terminal supports adaptation for call cases where the RTP-based CMR cannot be used.

NOTE 1: Examples of call cases where the RTP-based CMR cannot be used are: when the RTP-based CMR is disabled; or for uni-directional media (sendonly or recvonly).

Some of the request messages are generic for all speech codecs while other request messages are codec-specific. Request messages that can be used in a session are negotiated in SDP, see clause 10.2.3.

[TS 26.114, clause 6.2.2.3]:

An MTSI client in terminal must understand all the payload format options that are defined in RFC 4867 [28], and in [125]. It does not have to support operating according to all these options but must be capable to properly accepting or rejecting all options.

The SDP answer depends on many factors, for example:

– what is included in the SDP offer and in what preference order that is defined. The SDP offer will probably be different if it is generated by another MTSI client in terminal, by an MTSI MGW, a TISPAN client or some other VoIP client that does not follow this specification;

– if terminal and/or network resources are available; and:

– if there are other configurations, for example defined with OMA-DM, that mandate, recommend or prevent some configurations.

Table 6.3 describes requirements and recommendations for handling of the AMR payload format parameters and for how to generate the SDP answer.

NOTE 1: An MTSI client in terminal may support more features than what is required by this specification, e.g. crc, robust sorting and interleaving. Table 6.3 describes the handling of the AMR payload format parameters when the MTSI client implementation supports only those features that are required by this specification. Tables 6.3a-6.3c describe the handling of the EVS payload format parameters.

Table 6.3: Handling of the AMR-NB and AMR-WB SDP parameters in the received SDP offer and in the SDP answer

Parameter in the received SDP offer	Comments	Handling
Codec	Wide-band speech is preferable over narrow-band speech	If both AMR-WB and AMR-NB are offered and if AMR-WB is supported by the answering MTSI client in terminal then it shall select to use the AMR-WB codec and include this codec in the SDP answer, unless another preference order is indicated in the SDP offer. If the MTSI client in terminal only supports AMR-NB then this codec shall be selected to be used and shall be included in the SDP answer. The SDP answer shall only include one RTP Payload Type for speech, see NOTE 1.
octet-align	Both the bandwidth-efficient and the octet-aligned payload formats are supported by the MTSI client in terminal. MTSI MGWs for GERAN or UTRAN are likely to either not include the octet-align parameter or to offer octet-align=0. The bandwidth-efficient payload format is preferable over the octet-aligned payload format.	The offer shall not be rejected purely based on the offered payload format variant. If both bandwidth-efficient and octet-aligned are included in the received SDP offer then the MTSI client in terminal shall select the bandwidth-efficient payload format and include it in the configuration in the SDP answer.
mode-set	The MTSI client in terminal can interoperate properly with whatever mode-set the other end-point offers or if no mode-set is offered. The possibilities to use the higher bit rate codec modes also depend on the offered bandwidth. MTSI MGWs for GERAN or UTRAN inter-working are likely to include the mode-set in the offer if in case the intention is to use TFO or TrFO. Mode sets that give more adaptation possibilities are preferable over mode-sets with fewer or no adaptation possibilities. An MTSI client in terminal may be configured with a preferred mode set. Otherwise, the preferred mode-set for AMR-NB is {12.2, 7.4, 5.9, 4.75} and for AMR-WB it is {12.65, 8.85 and 6.60}.	The offer shall not be rejected purely based on the offered mode-set. If only one mode-set is offered then the MTSI client in terminal shall select to use this and include the same mode-set in the SDP answer. If several different payload types for the same codec with different mode-sets (possibly including one or more payload type without mode set) are included in the received SDP offer, then the MTSI client in terminal should select in the first hand the mode-set that provides the largest degrees of freedom for codec mode adaptation and in the second hand the mode-set that is closest to the preferred mode sets. If only a payload type without mode-set has been offered, or if an MTSI client in terminal selects a payload type without mode-set from among the offered ones, and the MTSI client in terminal intends to use only some modes (e.g. one of the preferred mode sets defined at left), then the MTSI client in terminal should include these modes as the mode-set. There are also dependencies between the mode-set and the SDP b=AS bandwidth parameter; see Clause 6.2.5.2.
mode-change-period	The MTSI client in terminal can interoperate properly with whatever mode-change-period the other end-point offers. MTSI MGWs for GERAN or UTRAN inter-working are likely to include mode-change-period=2 in the offer if in case the intention is to use TFO or TrFO.	The offer shall not be rejected purely based on the offered mode-change-period. If the received SDP offer defines mode-change-period=2 then this information shall be used to determine the mode changes for AMR-NB or AMR-WB encoded media that the MTSI client in terminal sends. The MTSI client in terminal should not include the mode-change-period parameter in the SDP answer since it has no corresponding limitations.
mode-change-capability	The MTSI client in terminal can interoperate with whatever capabilities the other end-point declares.	The offer shall not be rejected purely based on the offered mode-change-capability. The mode-change-capability information should be used to determine a proper value, or prevent using an improper value, for mode-change-period in the SDP answer, see above. If the offer includes mode-change-capability=1, then the MTSI client in terminal shall not offer mode-change-period=2 in the answer. The MTSI client in terminal shall include mode-change-capability=2 in the SDP answer since it is required to support restricting mode changes to every other frame.
mode-change-neighbor	The MTSI client in terminal can interoperate with whatever limitations the other end-point offers.	The offer shall not be rejected purely based on the offered mode-change-neighbor. The MTSI client in terminal shall use this information to determine how mode changes can be performed for AMR-NB or AMR-WB encoded media that the MTSI client in terminal sends. The MTSI client in terminal shall not include the mode-change-neighbor parameter in the SDP answer since it has no corresponding limitations.
maxptime	The MTSI client in terminal can interoperate with whatever value that is offered. The MTSI client in terminal may also use this information to determine a suitable value for max-red in the SDP answer.	The offer shall not be rejected purely based on the offered maxptime. The MTSI client in terminal shall use this information to control the packetization when sending RTP packets to the other end-point, see also clause 7.4.2. The maxptime parameter shall be included in the SDP answer and shall be an integer multiple of 20. If the received SDP offer includes both the max-red and ptime parameter then the MTSI client in terminal may choose to use this information to define a suitable value for maxptime in the SDP answer, see NOTE 2. The MTSI client in terminal may also choose to set the maxptime value to 240, regardless of the ptime and/or max-red parameters in the SDP offer. The maxptime value in the SDP answer shall not be smaller than ptime value in the SDP answer. The maxptime value should be selected to give at least some room for adaptation.
crc	The MTSI client in terminal is not required to support this option.	The MTSI client in terminal may have to reject offered RTP payload types including this option.
robust-sorting	The MTSI client in terminal is not required to support this option.	The MTSI client in terminal may have to reject offered RTP payload types including this option.
interleaving	The MTSI client in terminal is not required to support this option.	The MTSI client in terminal may have to reject offered RTP payload types including this option.
ptime	The MTSI client in terminal can interoperate with whatever value that is offered.	The offer shall not be rejected purely based on the offered ptime. The MTSI client in terminal should use this information and should use the requested packetization when sending RTP packets to the other end-point. The MTSI client should use the ptime value to determine how many non-redundant speech frames that can be packed into the RTP packets. The requirements in clause 7.4.2 shall be followed even if ptime in the SDP offer is larger than 80. The ptime parameter shall be included in the SDP answer and shall be an integer multiple of 20. If the received SDP offer includes the ptime parameters then the MTSI client in terminal may choose to use this information to define a suitable value for ptime in the SDP answer, see NOTE 3. The MTSI client in terminal may also choose to set the ptime value in the SDP answer according to Table 7.1, regardless of the ptime parameter in the SDP offer. The ptime value in the SDP answer shall not be larger than the maxptime value in the SDP answer.
channels	The number of channels may either be explicitly indicated in the SDP by including ‘/1’, ‘/2’, etc. on the a=rtpmap line, but the number of channels may also be omitted. When the number of channels is omitted then the default rule is that one channel is being offered. The MTSI client in terminal is only required to support audio media using one channel. Offered RTP payload types with more than one channel may therefore have to be rejected.	When the MTSI client in terminal accepts an offer for single-channel audio then the SDP answer shall either explicitly indicate ‘/1’ or omit the channels parameter. When the MTSI client in terminal accepts an offer for multi-channel audio then the number of channels shall be included in the SDP answer.
max-red	The MTSI client in terminal may use this information to bound the delay for receiving redundant frames. The MTSI client in terminal may also use this information to determine a suitable value for maxptime in the SDP answer.	The max-red parameter shall be included in the SDP answer and shall be an integer multiple of 20. If the received SDP offer includes both the ptime and maxptime parameters then the MTSI client in terminal may choose to use this information to define a suitable value for max-red in the SDP answer, see NOTE 2. The MTSI client in terminal may also choose to set the max-red value to 220. The max-red value in the SDP answer should be selected to give at least some room for adaptation.
ecn-capable-rtp: leap ect=0	An MTSI client in terminal uses this SDP attribute to offer ECN for RTP-transported media	Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation
NOTE 1: An MTSI client may include both a speech coded, e.g. AMR-NB or AMR-WB, and ‘telephone-events’ for DTMF in the SDP answer, see 3GPP TS 24.229 Clause 6.1, [7]. NOTE 2: It is possible to use the following relationship between maxptime, ptime and max-red: maxptime = ptime + max-red. There is however no mandatory requirement that these parameters must be aligned in this way. NOTE 3: It may be wise to use the same ptime value in the SDP answer as was given in the SDP offer, especially if the ptime in the SDP offer is larger than 20, since a value larger than the frame length indicates that the other end-point is somehow packet rate limited.

If an SDP offer is received from another MTSI client in terminal using the AMR-NB or AMR-WB codec, then the SDP offer will include configurations as described in Table 6.1 and Table 6.2. If the MTSI client in terminal chooses to accept the offer for using the AMR-NB or AMR-WB codec, as configured in Table 6.1 or Table 6.2 then the MTSI client in terminal shall support a configuration where the MTSI client in terminal creates an SDP answer containing an RTP payload type for the AMR-NB and AMR-WB codec as shown in Table 6.4.

…

Table 6.3b: Handling of the EVS Primary SDP parameters in the received SDP offer and in the SDP answer

Parameter	Comments	Handling
br		An MTSI client in terminal supporting the EVS codec is required to support the entire bit-rate range but may offer a smaller bit-rate range or even a single bit-rate.
br-send
br-recv
bw	The session should start with the maximum bandwidth supported by the initial bit-rate up to the maximum negotiated bandwidth. If a range of bandwidth is negotiated, the codec can operate in any bandwidth in the session but the maximum bandwidth in the range should be used after the start of or update of the session. If a single audio bandwidth higher than narrowband is negotiated, the codec operates in the negotiated bandwidth but can use lower bandwidth(s) in the session, depending on the input signal.	Both the offerer and the answerer shall send according to the bandwidth parameter in the answer.
bw-send
bw-recv
ch-send
ch-recv
cmr	In EVS AMR-WB IO mode, CMR to the bit-rates of EVS AMR-WB IO mode and NO_REQ is always enabled.	If cmr=-1 and the session is in the EVS Primary mode, MTSI client in terminal shall not transmit CMR. If cmr=-1 and the session is in the EVS AMR-WB IO, MTSI client in terminal shall restrict CMR to values of EVS AMR-WB-IO bit-rates and NO_REQ in the session. MTSI client in terminal is required to accept CMR even when cmr=-1. MTSI client in terminal is required to accept RTP payload without CMR even when cmr=1.
ch-aw-recv		If a positive (2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the receiver of the parameter shall send partial redundancy (channel-aware mode) at the start of the session using the value as the offset. If ch-aw-recv=0 is declared or not present for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) at the start of the session. If ch-aw-recv=-1 is declared for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) in the session. If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, partial redundancy (channel-aware mode) can be activated or deactivated during the session based on the expected or estimated channel condition through adaptation signalling, such as CMR (see Annex A.2 of [125]) or RTCP based signalling (see clause 10.2). If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the partial redundancy offset value can also be adjusted during the session based on the expected or estimated channel condition through adaptation signalling.

…

Table 6.4: SDP parameters for AMR-NB or AMR-WB for SDP answer when the SDP offer is received from another MTSI client in terminal

Parameter	Usage
octet-align	Shall not be included
mode-set	See Table 6.3
mode-change-period	Shall not be included
mode-change-capability	May be included. If it is included then it shall be set to 2
mode-change-neighbor	Shall not be included
maxptime	Shall be set to 240, see also Table 7.1
crc	Shall not be included
robust-sorting	Shall not be included
interleaving	Shall not be included
ptime	Shall be set according to Table 7.1
channels	Shall either be set to 1 or be omitted
max-red	Shall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0	Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation

7.18.3 Test description

7.18.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 the precondition mechanism.

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

7.18.3.2 Test procedure sequence

Table 7.18.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is made to attempt an IMS voice call.	–	–
2-7	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 8, parallel behaviour defined in table 7.18.3.2-2 takes place	–	–	–	–
8	Step 1 of Annex A.4.1 happens	–>	INVITE	1	P
9	Step 2 of Annex A.4.1 happens	<–	100 Trying
10	Step 3 of Annex A.4.1 happens	<–	183 Session Progress
11	Step 4 of Annex A.4.1 happens	–>	PRACK
12	Step 5 of Annex A.4.1 happens	<–	200 OK
12A	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 12B and 12C below, step 13 occurs.	–	–	–	–
12B-12C	Steps 11-12 of generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed.
13	Step 6 of Annex A.4.1 happens	–>	UPDATE	2	P
14	Step 7 of Annex A.4.1 happens	<–	200 OK
15	Step 8 of Annex A.4.1 happens	<–	180 Ringing
16	Step 9 of Annex A.4.1 happens	–>	PRACK
17	Step 10 of Annex A.4.1 happens	<–	200 OK
18	Step 11 of Annex A.4.1 happens	<–	200 OK
19	Step 12 of Annex A.4.1 happens	–>	ACK

Table 7.18.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.18.3.3 Specific message contents

183 Session Progress (Step 10)

Use the default message "183 Session Progress" in annex A.4.1 with the following exceptions:

Header/param	Value/Remark
Require
option-tag	precondition
Message-body	The following SDP types and values. Session description: v=0 o=- 1111111111 1111111111 IN (addrtype) (unicast-address for SS) s=- c=IN (addrtype) (connection-address for SS) b=AS:38 Time description: t=0 0 Media description: m=audio (transport port) RTP/AVP (fmt) [Note 1, 2] b=AS:38 b=RS: (bandwidth-value) [Note 3] b=RR: (bandwidth-value) [Note 3] Attributes for media: a=rtpmap: (payload type) AMR-WB/16000/1 [Note 1] a=fmtp: (format) mode-change-capability=2; max-red=220 [Note 1] a=ecn-capable-rtp: leap ect=0 [Note 4] a=rtcp-fb: nack ecn* [Note 4] a=rtcp-xr:ecn-sum [Note 4] a=ptime:20 a=maxptime:240 Attributes for media security mechanism: a=3ge2ae: requested [Note 5] a=crypto:1 AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR\|2^20\|1:4 [Note 5] Attributes for preconditions: a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=conf:qos remote sendrecv Note 1: The values for fmt, payload type and format are copied from step 2. Note 2: Transport port is the port number of the SS (see RFC 3264 clause 6). Note 3: The bandwidth-value is copied from step 2. Note 4: Attributes for ECN Capability are present if the UE supports Explicit Congestion Notification. Note 5: Attributes for media plane security are present if the use of end-to-access-edge security is supported by UE.

UPDATE (Step 13)

Use the default message "UPDATE" in annex A.4.1 with the following exceptions:

Header/param

Value/Remark

Require

option-tag

precondition

Message-body

The following SDP types and values shall be present.

Session description:

v=0

o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 2]

s=(session name)

c=IN (addrtype) (connection-address for UE) [Note 1]

b=AS: (bandwidth-value)

Time description:

t=0 0

Media description:

m=audio (transport port) RTP/AVP (fmt) [Note 3]

c=IN (addrtype) (connection-address for UE) [Note 1]

b=AS: (bandwidth-value)

b=RS: (bandwidth-value)

b=RR: (bandwidth-value)

Attributes for media:

a=rtpmap: (payload type) AMR-WB/16000 [Note 3] [Note 5]

a=fmtp: (format) [Note 3] [Note 4]

Attributes for preconditions:

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

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

Note 1: At least one "c=" field shall be present.

Note 2: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one

Note 3: The value for fmt, payload type and format is not checked

Note 4: Parameters for the AMR codec are not checked

Note 5: The AMR channel number shall be "/1" or omitted.