12.27 MO MTSI speech call / SRVCC on MT side / Codec Change from AMR-WB to AMR-NB
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.27.1 Definition
Test to verify that the MO UE correctly performs codec change from AMR-WB to AMR-NB when SRVCC happens on MT UE. This process is described in 3GPP TS 23.237 [155], clauses B.2.1.
12.27.2 Conformance requirement
[TS 23.237, clause B.2.1]:
After SRVCC has been successfully performed (see clauses 6.3.2.1.9.1 and 6.3.2.1.9.2), MSC Sever may initiates a SIP REINVITE to modify the Selected Codec towards the remote end in order to minimize the transcoding points in the voice path.
Figure B.2-1 below illustrates this procedure with the assumption that the remote end supports the selected target RAN codec (B) in the Re-INVITE.
Figure B.2.1-1: Re-negotiation method towards the remote end
1. SRVCC is performed. MSC Server has included all supported codecs into the session transfer request to the ATCF. In this flow the codec list may include the codec that is currently used in the ongoing IMS session and ATCF has selected this codec, therefore there is no transcoding in ATGW but there may be transcoding in CS-MGW. The session between UE and CS-MGW uses the codec-B. The session between CS-MGW, ATGW and remote end uses the codec-A.
NOTE 1: If the codec list from MSC Server does not include the codec that is currently used in the ongoing session, ATCF initiates transcoding.
2. The MSC server sends a Re-INVITE to remote end with list of supported codecs in MSC server to ATCF, codec B is the most preferred codec in the list.
NOTE 2: It may be that the CS MGW or ATGW supports the audio Codec that is compatible or equal to the audio Codec used for the PS session but a change of the codec mode (such as bitrate, audio bandwidth, EVS Primary/AMR-WB IO modes) of the audio Codec used for the PS session is required. In this case the MSC server or ATCF may initiates a signalling towards to remote end to modify the codec mode of the audio Codec used for the PS session. The signalling to modify the codec mode is specific to the audio Codec used for the PS session as discussed in TS 26.114 [35], i.e. this procedure may be taken place by SIP invite, but may also be taken place by RTCP-APP or CMR (Codec Mode Request).
3. ATCF passes the Re-INVITE towards the SCC AS with the codec list.
4. SCC AS performs a remote leg update towards the remote end.
5-7. The remote end accepts the offer and selects the most preferred codec it can support, in this case codec B was selected. From now on the codec B is used e2e in TrFO manner.
Reference(s)
3GPP TS 23.237 [155], clauses B.2.1.
12.27.3 Test purpose
1) To verify that the MO UE correctly performs codec change from AMR-WB to AMR-NB after call establishment.
12.27.4 Method of test
Initial conditions
UE contains either SIM application (GIBA), 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 or C.2a (GIBA only) 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.6.3-1 steps 1 to 14.
15) SS sends a re-INVITE request to the UE.
16) Optional: SS waits for the UE to respond to the INVITE request with a 100 Trying response.
17) SS waits for the UE to respond to the INVITE request with valid 200 OK response..
18) SS sends an ACK to acknowledge receipt of the 200 OK for INVITE..
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.21 |
MTSI MO speech call. Referred from 36.508 [94] table 4.5A.6.3-1 for a UE with E-UTRA support. |
||
|
14 |
🡨 |
INVITE |
SS sends re-INVITE with an SDP offer to switch to AMR-NB. |
|
|
15 |
🡪 |
100 Trying |
(Optional) The UE responds with a 100 Trying provisional response |
|
|
16 |
🡪 |
200 OK |
The UE responds re-INVITE with 200 OK final response. |
|
|
17 |
🡨 |
ACK |
The SS acknowledges the receipt of 200 OK for re-INVITE. |
|
Specific Message Contents
INVITE (Step 14)
Use the default message “INVITE for MT Call” in annex A.2.9 with condition A5 and the following exceptions:
|
Header/param |
Value/remark |
|
Message-body |
SDP body copied from the previous 200 OK (C.21 step 6 or 8), and modified as follows: – “o=” line identical to previous SDP sent by SS except that sess-version is incremented. Media description:
Attributes for media:
– Attribute for preconditions are removed. |
200 OK (Step 16)
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 |
|
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:
Time description:
Media description:
Attributes for media:
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: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one. |