12.25a MT MTSI speech call / EVS offered but not supported by UE / AMR-WB agreed
34.229-13GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification
12.25a.1 Definition
Test to verify that the MT UE not supporting EVS correctly performs IMS voice call establishment with AMR-WB when the call is offered with codec EVS and AMR-WB. This process is described in TS 26.114 [66], clause 6.2.2.3.
12.25a.2 Conformance requirement
[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: 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: 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.3a: Handling of SDP parameters common to EVS Primary and EVS AMR-WB IO in the received SDP offer and in the SDP answer
|
Parameter |
Comments |
Handling |
|---|---|---|
|
ptime |
||
|
maxptime |
||
|
dtx |
MTSI client in terminal shall not include dtx in the initial SDP offer. MTSI MGW may modify SDP offer to include dtx in order to disable DTX in the session. |
|
|
dtx-recv |
MTSI client in terminal shall not include dtx-recv. MTSI MGW may modify SDP offer or answer in order to disable DTX for the send direction of the receiver of dtx-recv. |
|
|
hf-only |
– |
|
|
evs-mode-switch |
This parameter is used by MTSI MGW either when starting in EVS AMR-WB IO mode instead of EVS Primary mode or when switching between EVS Primary mode and EVS AMR-WB IO mode, e.g., for SRVCC. |
MTSI client in terminal shall not include evs-mode-switch in the initial SDP offer. When including evs-mode-switch in the SDP offer during a session, the offeror shall use the requested mode when sending EVS packets. However, if a media stream is already being received, the offeror needs to be prepared to receive packets in both EVS primary and EVS AMR-WB IO modes until receiving the answer. When including evs-mode-switch in the SDP answer during a session, the answerer shall use the requested mode when sending EVS packets. When receiving SDP answer including evs-mode-switch during a session, the offeror shall use the requested mode when sending EVS packets. |
|
max-red |
See Table 6.3 |
|
|
channels |
See Table 6.3 |
|
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 offeror 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.3c: SDP parameters for the EVS AMR-WB IO parameters in the received SDP offer and in the SDP answer
|
Parameter |
Comments |
Handling |
|---|---|---|
|
mode-set |
See Table 6.3 |
|
|
mode-change-period |
||
|
mode-change-neighbor |
||
|
mode-change-capability |
The default value is re-defined in comparison to that in [28]. |
As the default and the only allowed value of mode-change-capability is 2 in EVS AMR-WB IO, it is not required to include this parameter in the SDP offer or answer. |
NOTE: ECN-triggered adaptation is currently undefined for EVS. This does not prevent ECN-triggered adaptation from being negotiated and used for AMR or AMR-WB.
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 |
If an SDP offer is received from a MTSI MGW inter-working with CS GERAN/UTRAN, and when the MTSI MGW supports ECN (see also Clause 12.3.3), then it is likely to be configured as shown in Table 6.5 if the MTSI MGW does not support redundancy.
Table 6.5: Expected configuration of SDP parameters for AMR-NB or AMR-WB in an SDP offer from an MTSI MGW inter-working with CS GERAN/UTRAN
|
Parameter |
Usage |
|
octet-align |
Either not included or set to 0 |
|
mode-set |
Included and indicates the codec modes that are allowed in the CS network |
|
mode-change-period |
Set to 2 |
|
mode-change-capability |
Set to 2 |
|
mode-change-neighbor |
Set to 1 if the CS network is GERAN |
|
maxptime |
Set to 80, see also Table 12.1 |
|
crc |
Not included |
|
robust-sorting |
Not included |
|
interleaving |
Not included |
|
ptime |
Set according to Table 12.1 |
|
channels |
Set to 1 or parameter is omitted |
|
max-red |
Set to 0 |
|
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 |
If the MTSI client in terminal accepts the offer included in Table 6.5 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 codecs as shown in Table 6.6.
Table 6.6: SDP parameters for AMR-NB or AMR-WB for SDP answer when the SDP offer is received from another MTSI MGW
|
Parameter |
Usage |
|
octet-align |
Shall be set according to the offer |
|
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 be set according to the offer |
|
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 |
Reference(s)
TS 26.114 [66], clause 6.2.2.3.
12.25a.3 Test purpose
1) To verify that within SIP signalling the UE performs the correct exchange of SIP header and parameter contents.
2) To verify that within SIP signalling the UE performs the correct exchange of SDP contents.
3) To verify that the UE is able to answer the call using the codec AMR-WB when the UE receives SDP offer including codec EVS and AMR-WB.
12.25a.4 Method of test
Initial conditions
UE contains ISIM and USIM applications or only USIM application on UICC. UE has discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step.
SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE. SS has performed AKAv1-MD5 authentication with the UE and accepted the registration (IMS security).
Expected sequence
NOTE: Only the IMS procedure relevant to the test purpose is described below.
|
Step |
Direction |
Message |
Comment |
|
|
UE |
SS |
|||
|
1 |
Step 1 defined in annex C.45 |
|||
|
2-15 |
Steps 2-15 defined in annex C.11 |
|||
Specific Message Contents
None.