12.23 MO MTSI speech call / EVS
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.23.1 Definition
Test to verify that the UE correctly performs IMS mobile originated voice call setup with EVS when using IMS Multimedia Telephony. This process is described in 3GPP TS 24.229 [10], clauses 5.1.3 and 6.1, TS 24.173 [65] and TS 26.114 [66].
12.23.2 Conformance requirement
[TS 26.114, clause 6.2.2.2]
When speech is offered, an MTSI client in terminal sending a first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for AMR-NB and the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.1.
If wideband speech is also offered, then the SDP offer shall also include at least one RTP payload type for AMR-WB according to RFC4867 [28] and the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.1.
If super-wideband speech is offered, the SDP offer shall include at least one RTP payload type for EVS and the MTSI client in terminal shall support a configuration where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a.
If full band speech is offered, the SDP offer shall include at least one RTP payload type for EVS and the MTSI client in terminal shall support a configuration where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a.
When EVS is offered, the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a. When EVS is offered, the RTP payload type shall also use parameters for EVS AMR-WB IO mode as defined in Table 6.1, except for the ‘ecn-capable-rtp’ and ‘leap ect’ parameters.
NOTE 1: RFC4867 can also be used for EVS AMR-WB IO when EVS is supported.
NOTE 2: 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.
Clause 5.2.1.6 describes the preference order for how different configurations should be ordered in the list of payload type numbers that is given on the m= line.
Table 6.1: SDP parameters for AMR-NB or AMR-WB, when the MTSI client in terminal offers the bandwidth-efficient payload format
|
Parameter |
Usage |
|
octet-align |
Shall not be included |
|
mode-set |
Shall not be included |
|
mode-change-period |
Shall not be included |
|
mode-change-capability |
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 if offering to use ECN and if the session setup allows for bit-rate adaptation |
Table 6.2: SDP parameters for AMR-NB or AMR-WB, when the MTSI client in terminal offers the octet-aligned payload format
|
Parameter |
Usage |
|
octet-align |
Shall be set to 1 |
|
mode-set |
Shall not be included |
|
mode-change-period |
Shall not be included |
|
mode-change-capability |
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 if offering to use ECN and if the session setup allows for bit-rate adaptation |
Table 6.2a: SDP parameters for EVS Primary mode, when the MTSI client in terminal offers EVS
|
Parameter |
Usage |
|
ptime |
Shall be set according to Table 7.1 |
|
maxptime |
Shall be set to 240, see also Table 7.1 |
|
dtx |
MTSI client in terminal shall not include dtx in the initial SDP offer. |
|
dtx-recv |
MTSI client in terminal shall not include dtx-recv. |
|
hf-only |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
evs-mode-switch |
MTSI client in terminal shall not include evs-mode-switch in the initial SDP offer. |
|
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 |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
br-recv |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
bw |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
bw-send |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
bw-recv |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
ch-send |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
ch-recv |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
cmr |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
ch-aw-recv |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
channels |
The SDP offer-answer considerations in 3GPP TS 26.445 [125] apply. |
|
max-red |
Shall be included and shall be set to 220 or less. |
When the channels parameter is omitted then this means that one channel is being offered.
The mode-set parameter is omitted, allowing maximum freedom for the visited network.
The mode-change-capability parameter is included and set to 2, to support potential interworking with 2G radio access (GERAN).
An example of an SDP offer for AMR-NB is shown in Table A.1.1. An example of an SDP offer for both AMR-NB and AMR-WB is shown in Table A.1.2. An example of SDP offer for AMR-NB, AMR-WB, and EVS is shown in Table A.14.1.
An SDP example for offering and accepting a dual-mono session for EVS is shown in Annex A.14.1 and A.14.3.
An MTSI client in terminal may divide the offer-answer negotiation into several phases and offer different configurations in different SDP offers. If this is done then the first SDP offer in the initial offer-answer negotiation shall include the most preferable configurations. For AMR-NB, this means that the first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for AMR-NB with the parameters as defined in Table 6.1. If wideband speech is offered then the first SDP offer in the initial offer-answer negotiation shall include also at least one RTP payload type for AMR-WB with the parameters as defined in Table 6.1. This also means that offers for octet-aligned payload format do not need to be included in the first SDP offer. If super-wideband or full band speech is offered, the first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for EVS with the parameters as defined in [125]. One example of dividing the offer-answer negotiation into two phases, and the corresponding SDP offers, is shown in clause A.1.1.2.2.
NOTE: Dividing the offer-answer negotiation into several phases may lead to never offering the less preferred configurations, if the other end-point accepts to use at least one of the configurations offered in the initial SDP offer.
If the speech media is re-negotiated during the session then the knowledge from earlier offer-answer negotiations should be used in order to shorten the session re-negotiation time. I.e., failed offer-answer transactions shall not be repeated.
Reference(s)
TS 26.114 [66], clause 6.2.2.2.
12.23.3 Test purpose
1) To verify that when initiating MO MTSI speech call and SS needs to reserve resources, the UE performs correct exchange of SIP protocol signalling messages for setting up the session.
2) To verify that within SIP signalling the UE performs the correct exchange of SIP header and parameter contents.
3) To verify that within SIP signalling the UE performs the correct exchange of SDP contents.
4) To verify that the UE is able to release the call.
12.23.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).
Test procedure applicable for a UE with E-UTRA support (TS 34.229-2 [5] A.18/1)
1-14) The UE executes the procedure described in TS 36.508 [94] table 4.5A.19.3-1 steps 1 to 14.
Expected sequence
NOTE: Only the IMS procedure relevant to the test purpose is described below.
|
Step |
Direction |
Message |
Comment |
|
|
UE |
SS |
|||
|
1-13 |
Steps defined in annex C.44 |
MTSI MO speech call. Referred from 36.508 [94] table 4.5A.19.3-1 for a UE with E-UTRA support. |
||
|
13A |
The UE is triggered by MMI to release the call |
|||
|
14 |
🡪 |
BYE |
The UE releases the call with BYE |
|
|
15 |
🡨 |
200 OK |
The SS sends 200 OK for BYE |
|
Specific Message Contents
None.
12.23.5 Test requirements
The UE shall send requests and responses as described in clause 12.23.4.