12.26 MT MTSI speech call / EVS / AMR-WB IO mode

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

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

12.26.1 Definition

Test to verify that the UE correctly performs IMS mobile originated voice call setup with EVS when using IMS Multimedia Telephony. Then a mobile terminated switch from EVS primary mode to EVS AMR-WB IO mode. 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.26.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.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.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.

[TS 26.114, clause 12.3.4.]

An MTSI client in terminal (hereinafter “local client”) using 3GPP PS access may be handed over to CS access. By that SRVCC procedure, the end-point of the IP connection moves from the local client to a CS MGW in the CS network, as described in TS 23.216 (SRVCC) [133].

In order to achieve this handover, the MSC server, controlling the CS MGW, sends a SIP INVITE message:

– either to the remote client (in case of SRVCC handover without SRVCC enhancement);

– or to the ATCF (in case of SRVCC handover with ATCF enhancement),

to change the communication end from the MTSI client in terminal to the CS MGW as described in TS 23.237 [134].

If EVS is used between local and remote client before SRVCC and if AMR-WB is used after SRVCC by the local CS UE, an MTSI MGW (e.g. MSC/CS-MGW or ATCF/ATGW) can send the RTCP_APP_EP2I request message, (see clause 10.1.2.10), or a CMR in the RTP payload requesting an EVS AMR-WB IO mode, to the remote client to request that it switches from the EVS Primary mode to the EVS AMR-WB IO mode. The mode-set used in CS shall be included in the RTCP_APP_EP2I request message. Furthermore, the RTCP_APP_EP2I request message also supports signalling to restrict the timing and destination of codec mode changes. An SDP offer/answer negotiation between the MTSI MGW and the remote client can also be performed to align the mode-sets and to optimize the resource usage and also to request switching to the EVS AMR-WB IO mode.

Correspondingly, the RTCP_APP_EI2P request message can be used to switch from the EVS AMR-WB IO mode to the EVS Primary mode, e.g. in case an SRVCC handover to a CS access and a switch to the EVS AMR-WB IO mode is followed by a reverse SRVCC to perform handover back to the PS access. An SDP offer/answer negotiation can also be performed to restore the session, e.g. bitrates, bandwidths and other configuration parameters, to what was used before SRVCC.

Reference(s)

TS 26.114 [66], clause 6.2.2.3 and 12.3.4.

12.26.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 answer the call using the codec AMR-WB IO mode.

12.26.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)

0-13) The UE executes the procedure described in TS 36.508 [94] table 4.5A.19.3-1 steps 1 to 14.

14) SS sends a re-INVITE request to the UE.

15) SS expects and receives 200 OK for re-INVITE from the UE.

15A) SS acknowledges the receipt of 200 OK for re-INVITE.

16-19) SS executes the procedure C.33.

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.
14	🡨		INVITE	The SS sends re-INVITE with second SDP offer to switch to EVS AMR-WB IO mode.
14A	🡪		100 Trying	(Optional) The UE responds with a 100 Trying provisional response.
15	🡪		200 OK	The UE responds to the re-INVITE with a 200 OK final response.
15A	🡨		ACK	The SS acknowledges the receipt of 200 OK for re-INVITE.
16-19			Steps defined in annex C.33	The SS releases the call.

Specific Message Contents

INVITE (Step 14)

Use the default message “INVITE for MT Call” in annex A.2.9 with the following exceptions:

Header/param	Value/remark
Supported
option-tag	precondition
Message-body	SDP body copied from the previous 200 OK (C.44 step 6 or 8), and modified as follows: – “o=” line identical to previous SDP sent by SS except that sess-version is incremented. – “a=fmtp” line identical to previous SDP sent by SS except that “evs-mode-switch=1” is added.

200 OK (Step 15)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Require option-tag	precondition
Content-Type
media-type	application/sdp
Content-Length	header shall be present if UE uses TCP to send this message and if there is a message body
value	length of message-body
Message-body	The following SDP types and values shall be present. Session description: v=0 o=(user-name) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 4] 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 2] 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) EVS/16000 [Note 2] a=fmtp:(format) evs-mode-switch=1; [Note 2, 3] Attributes for preconditions: a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv Note 1: At least one "c=" field shall be present. Note 2: The values for fmt, payload type and format are not checked. Note 3: The evs-mode-switch is checked, but no other codec parameters. Note 4: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one.

12.26.5 Test requirements

The UE shall send requests and responses as described in clause 12.26.4.