Amarisoft

LTE VoLTE

This tutorial shows how to do VoLTE Loopback test with a commercial UE on Amari Callbox. VoLTE loopback means UE initiate VoLTE call and Callbox accept the call and loopback the SIP/RTP back to UE. There is no independent receiving UE. If you are using USIM card from Amarisoft, you don't need to change anything in default LTE configuration. You just need to do some settings on UE side.

There are two main technology to implement Voice in LTE as below.

NOTE : Since Amarisoft Callbox VoLTE is based on Loopback mechanism, most of the connected property (e.g, type of Voice Codec) is determined by UE capability, not determined by Callbox feature.

Table of Contents

Introduction

Voice over LTE (VoLTE) represents a significant evolution in mobile telecommunications, enabling high-quality voice services to be delivered natively over LTE data networks using the IP Multimedia Subsystem (IMS) and Session Initiation Protocol/Real-time Transport Protocol (SIP/RTP) frameworks. Unlike legacy voice technologies that rely on circuit-switched (CS) domains, VoLTE leverages the packet-switched architecture of LTE to provide seamless voice, video, and supplementary services with reduced latency and enhanced spectral efficiency. The Amari Callbox, developed by Amarisoft, is a flexible and powerful testing platform widely used for LTE/NR network emulation and device validation. This tutorial focuses on performing a VoLTE loopback test using a commercial User Equipment (UE) with the Amari Callbox. In a loopback scenario, the UE initiates a VoLTE call, and the Callbox accepts and loops back the SIP and RTP streams, allowing comprehensive testing of VoLTE call setup, media handling, and codec negotiation without requiring a secondary UE. The tutorial demonstrates the operational workflow, highlights the architectural components involved—including IMS, SIP signaling, and media loopback—and provides guidance on the necessary configurations and expected outcomes. By mastering VoLTE loopback testing, network engineers and device testers can validate critical voice functionalities, ensure end-to-end interoperability, and optimize UE behavior in real-world deployment scenarios. This knowledge is essential in the broader context of LTE and 5G network rollouts, where VoLTE serves as the foundation for modern mobile voice and multimedia services.

Summary of the Tutorial

This tutorial provides a comprehensive guide for setting up and testing VoLTE functionality using the Amarisoft callbox system. The procedures cover initial configuration, execution of both Mobile Originated (MO) and Mobile Terminated (MT) calls, and basic log analysis.

The tutorial emphasizes simple default configurations for quick VoLTE testing and provides step-by-step procedures for both originating and terminating VoLTE calls, along with basic log analysis guidelines.

NOTE : For a generic technical tips about VoLTE test, refer to this wiki.

Test Setup

Test setup for this tutorial is as shown below.  

TestSetup Callbox UE 1sdr 01

Key Configuration Parameters

Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.

Configuration

NOTE : Amarisoft callbox support VoLTE by default setting. So unless you have any specific configurations of your own on device side, VoLTE should work with default settings.

I used the enb.default.cfg (LTE default configuration) as it is without changing any contents in it.

LTE SG SMS Config 01

I also used the default configuration for mme (mme-ims.cfg)  as shown below.

LTE SG SMS Config 03

In mme-ims.cfg file,  you can see that ue_db-ims.cfg  is included as the UE database file.

This part of the configuration defines the basic MME behavior, including the network interface setup script, NAS ciphering preference, NAS integrity preference, and the UE database file to be used.

The tun_setup_script parameter specifies the script used to create or configure the network interface for each PDN connection. In this example, mme-ifup is used. This script is called when the PDN interface is created, and it receives information such as the interface name, PDN index, APN, IP version, and assigned IP address range.

The nas_cipher_algo_pref parameter defines the preferred NAS ciphering algorithms. In this example, the preference is set to [1], which means EEA1 is preferred. EEA0, which means no ciphering, is always treated as the last option.

The nas_integ_algo_pref parameter defines the preferred NAS integrity algorithms. In this example, the preference is set to [2, 1], meaning EIA2 is preferred first, followed by EIA1. EIA0, which means no integrity protection, is always treated as the last option.

The most important part for this VoLTE tutorial is the UE database setting. Instead of using the normal LTE UE database file, this configuration includes ue_db-ims.cfg. This file contains the UE subscription information required for IMS and VoLTE operation. Therefore, when testing VoLTE with Amarisoft, you should make sure that the IMS-capable UE database file is included in the MME configuration.

LTE SG SMS Config 04

UE DB Configuration

In this tutorial, I am using an Anritsu test USIM. Therefore, the UE database configuration should be updated to match the USIM information.

In the ue_db-ims.cfg file, each UE entry defines the subscriber information used by the Amarisoft MME and IMS server. The main parameters are IMSI, authentication key, IMS identity, IMS domain, and IMPU.

The sim_algo parameter defines the USIM authentication algorithm. In this example, it is set to xor. Depending on the test USIM, this can also be set to milenage or tuak.

The imsi value should match the IMSI programmed in the USIM. In this example, the IMSI is set for the Anritsu test USIM. Other sample IMSI values for Agilent or R&S test USIMs are shown as comments, but they are not used in this configuration.

The K value is the authentication key for the USIM. This value must match the key programmed in the test USIM. In this example, the active K value is for the Anritsu test USIM. The K values for other test USIMs are commented out.

The impi parameter defines the IMS private identity. This is used internally for IMS authentication. In this example, it is based on the IMSI and the IMS domain.

The impu parameter defines the IMS public identity. This is the SIP URI or telephone URI used for IMS registration and VoLTE call setup. In this example, two public identities are configured. One is a SIP URI based on the IMSI, and the other is a telephone URI using tel:0600000000. This telephone URI is important because it can be used as the dialed number for the VoLTE loopback test.

The domain parameter defines the IMS domain. In this example, the domain is ims.mnc001.mcc001.3gppnetwork.org. This domain should be consistent with the IMPU and IMPI settings.

The multi_sim parameter is set to true. This allows multiple SIM-related identities to be handled in this experimental configuration.

For a standard SIP client, additional parameters such as password and authentication type can also be configured. In this example, the password and MD5 authentication type are shown as commented-out lines, so they are not active.

LTE SG SMS Config 05

NOTE : impi and impu (except tell) is set here by default is based on the assumption that UE derive those numbers from imsi. If it is not the case for your UE(DUT), set the proper impi, impu based on your UE implementation, otherwise you would get errors during IMS registraton or various other SIP messaging which carries IMPI or IMPU.

IMS Configuration

The following setting is configured in ims.default.cfg for the VoLTE loopback test. When the UE makes a VoLTE call to one of the configured echo numbers, the Amarisoft Callbox accepts the call and loops the voice media back to the UE.

The sip_addr section defines the SIP bind addresses used by the IMS server. In this example, both IPv4 and IPv6 addresses are configured. For IPv4, 192.168.4.1 and 192.168.5.1 are used as SIP bind addresses, and the RTP/UDP port range is configured from 10000 to 20000. These addresses should match the IMS network interfaces created by the Callbox configuration.

The include "ue_db-ims.cfg" line means that the IMS server also uses the same IMS UE database file. This file contains the IMS identities such as IMPI, IMPU, domain, and authentication-related information for the UE.

The most important part for the loopback test is the echo section. This section defines the phone numbers or IMPUs that trigger the echo service. In this example, tel:666 and tel:+666 are configured as echo numbers. If the UE dials 666 or +666, the Callbox treats the call as a VoLTE loopback call.

There is also an entry for tel:404 with code 404. This is used for a 404 test case, where the IMS server intentionally returns a 404 response.

The entries urn:service:sos and urn:service:sos.police are used for emergency call testing. These entries are configured with anonymous set to true and authentication set to false, so they can be used as emergency service call examples without normal IMS authentication.

The precondition parameter is set to on. This enables IMS media precondition handling, which is commonly used in VoLTE call setup before the media path becomes active.

The 100rel parameter is set to true. This enables reliable provisional response handling, such as PRACK, during SIP call setup.

The IPsec section defines the authentication and encryption algorithms used for IMS security. In this example, hmac-md5-96 and hmac-sha-1-96 are listed for authentication, and null, aes-cbc, des-cbc, and des-ede3-cbc are listed for encryption.

The mt_call_sdp_file parameter specifies the SDP file used for mobile-terminated call handling. In this example, mt_call_qos.sdp is used.

The ue_db_filename parameter specifies the persistent IMS UE database file. In this example, lte_ue_ims.db is used. This file is different from ue_db-ims.cfg. The cfg file defines the UE subscription information, while the db file is used by the IMS server to store runtime or persistent UE-related IMS information.

LTE VoLTE Loopback Config 05

On the UE side, I used the following configuration before starting the VoLTE loopback test.

First, make sure that the IMS PDN is available on the UE. In this example, two APNs are configured on the phone: internet and ims. The internet APN is used for normal data service, and the ims APN is used for IMS registration and VoLTE service.

In some phones, the IMS APN may already be configured internally by default, but it may not be shown in the APN setting menu. Therefore, even if you do not see the ims APN in the GUI, it does not always mean that the IMS APN is missing. You need to check the detailed APN behavior of your DUT.

Next, make sure that the VoLTE option is enabled on the UE. In this example, the VoLTE switch is turned on under the SIM setting menu. This allows the UE to use IMS for voice service over LTE.

Also, depending on the UE model and firmware, IMS registration may fail when roaming is turned off. For this reason, it is safer to turn roaming on first during the initial test. After confirming that IMS registration and VoLTE loopback work properly, you can try disabling roaming again and check whether the UE still registers to IMS.

In summary, before making the VoLTE loopback call, check these UE-side items carefully: the ims APN should be available, the VoLTE option should be enabled, and roaming should be turned on if the UE does not register to IMS in the default setting.

LTE VoLTE Loopback Config 06

Perform the test

In this test, I will show both MO and MT VoLTE call cases.

MO means Mobile Originated. In this case, the UE starts the VoLTE call. For the loopback test, the UE dials one of the echo numbers configured in ims.default.cfg, such as 666. Then the Callbox accepts the SIP call and loops the RTP voice packets back to the same UE.

Test 1 : VoLTE Loopback

Start the LTE service and check the basic cell configuration first. For this VoLTE loopback test, there is no special requirement on the LTE radio configuration. Any normal LTE cell configuration is acceptable as long as the UE can attach to the cell and establish IMS registration.

In this example, the LTE cell is configured with PLMN 00101 and eNB ID 0x1a2d0. The cell is operating on LTE Band 7 with 5 MHz bandwidth. The downlink ARFCN is 3350, and the uplink ARFCN is 21350. The antenna configuration is 2 antennas for downlink and 2 antennas for uplink.

From the cell information, you can also confirm that the TAC is 0x0001, PCI is 1, PRACH sequence index is 204, and PLMN is 00101.

At this step, the main purpose is simply to confirm that the LTE cell is running correctly. Once the UE can camp on this LTE cell, the next important check is whether the UE can attach and register to IMS using the IMS APN.

LTE VoLTE Loopback Run 01

Power on the UE and make sure that the UE is registered to the LTE cell.

You can check the UE registration status from the Amarisoft console using the ue command. In this example, one UE is shown in the list, which means the UE is currently connected to the eNB.

The RAN_UE_ID is 1, and the CN_UE_ID is 100. These are internal UE identifiers used by the RAN and core network side. The UE is connected to Cell 0x001, and the assigned RNTI is 0x003d.

At this step, the important point is to confirm that the UE has successfully attached to the LTE network. Once the UE is registered, you can continue with IMS registration and VoLTE call testing.

If the UE is in idle mode, the ue command may not show any active UE in the list. This does not always mean that registration failed. In that case, you can simply proceed to the next step, or generate some activity from the UE to bring it back to connected mode.

LTE VoLTE Loopback Run 02

Make sure that the UE is assigned with the IMS PDN.

You can check this from the MME console using the ue command. In this example, the UE is registered successfully, and the REG field shows Y. This means the UE is registered to the EPC.

The #BEARER value is 2, which indicates that two bearers are currently established. This is an important sign for VoLTE testing because the UE normally needs one PDN/bearer for normal internet data and another PDN/bearer for IMS.

In the IP_ADDR field, you can see multiple IP addresses assigned to the UE. In this example, 192.168.3.2 is used for the normal internet PDN, and 192.168.4.2 is used for the IMS PDN. The IPv6 address is also shown after that.

At this step, the key point is to confirm that the IMS PDN has been created. If you only see one bearer or only the normal internet IP address, the UE may not have established the IMS PDN yet. In that case, check the UE APN setting, VoLTE option, roaming setting, and the UE database configuration.

LTE VoLTE Loopback Run 03

The following output indicates that the UE is registered to the IMS server.

You can check this from the IMS console using the users command. In this example, the UE is listed with the IMPI value [001010123456789@ims.mnc001.mcc001.3gppnetwork.org](mailto:001010123456789@ims.mnc001.mcc001.3gppnetwork.org). This means that the UE has successfully completed IMS registration using this IMS private identity.

The SIP Binding section shows the current SIP contact address of the UE. In this example, the UE is registered with a SIP URI using its IPv6 address and port 5060. This is the address that the IMS server uses when sending SIP messages toward the UE.

The Expires value shows the remaining IMS registration lifetime. In this example, it is 3520 seconds, which means the IMS registration is still valid.

The Options field shows the IMS service capabilities reported by the UE. Here, sms and volte are shown. For this VoLTE test, make sure that volte is included in this list. If volte is not shown, the UE may be registered to IMS, but VoLTE service may not be enabled or supported properly.

The IMPU line shows the public identities assigned to the UE. In this example, the UE has both a SIP URI and a telephone URI. The telephone URI is tel:0600000000, which matches the UE database configuration shown earlier.

At this step, the important point is to confirm that the UE is not only attached to LTE and assigned an IMS PDN, but also successfully registered to the IMS server with VoLTE capability. Once you see the UE listed here with the volte option, you can proceed to the actual VoLTE loopback call test.

LTE VoLTE Loopback Run 04

Make a call to 666 from the UE. This is the VoLTE loopback number configured in ims.default.cfg.

When the UE dials 666, the call is sent through IMS as a VoLTE call. Since 666 is included in the echo configuration, the Amarisoft IMS server accepts the call and starts the loopback service.

After pressing the call button, check that the call is established successfully. On the phone screen, you should see the call timer running. This means the SIP call setup has completed and the media session has been established.

Then turn on the speaker and speak into the phone microphone. If the loopback is working correctly, you should hear your own voice echoed back from the phone speaker. This confirms that both SIP signaling and RTP media path are working properly.

At this point, the UE has successfully completed the MO VoLTE loopback test. The UE originated the call, the Callbox accepted the call, and the RTP voice packets were looped back to the same UE.

LTE VoLTE Loopback Run 05

Check the trace log in the IMS console, and you should see the call status as shown below.

Run the t command in the IMS console to start tracing. Once the UE makes the call to 666, the IMS trace shows that this call is recognized as an Echo call.

In this example, the trace shows the SIP binding address of the UE, followed by Echo call. This confirms that the IMS server matched the dialed number with the echo configuration in ims.default.cfg and handled the call as a VoLTE loopback call.

This is an important confirmation point. The phone screen shows that the call is connected, and the IMS trace confirms that the Callbox is treating the call as an echo call. If you can also hear your own voice from the speaker, it means the SIP call setup and RTP media loopback are both working properly.

LTE VoLTE Loopback Run 06

Test 2 : MT Call from WebGui

You can also make an MT VoLTE call from the Amarisoft WebGUI.

First, open the WebGUI and go to the IMS panel. If the UE has successfully registered to the IMS server, you will see the UE listed in the Bindings table. In this example, the UE is shown with its SIP binding and IMPI information, which means IMS registration is already completed.

To start an MT call, click the call icon beside the registered UE entry. After you click this icon, the Callbox initiates a VoLTE call toward the UE. The UE should receive an incoming call on the phone screen.

This test is useful because it confirms the MT call direction. In the previous loopback test, the UE started the call by dialing 666. In this test, the IMS server starts the call toward the UE. If the phone rings and the call can be answered, it means the UE is correctly registered to IMS and can receive incoming VoLTE calls from the Callbox.

LTE VoLTE Loopback Run Test2 01

If the VoLTE signaling flow goes well, the UE will receive an incoming call from the Amarisoft IMS server.

When the incoming call alert appears on the phone, press ANSWER. After answering the call, check that the call screen shows an active call timer. This confirms that the MT VoLTE call has been established successfully.

In this example, the incoming call is shown as Amarisoft-IMS-2022-02-23. After pressing ANSWER, the call is connected and the timer starts running. This means that the Callbox successfully initiated the SIP call toward the UE, the UE accepted the call, and the IMS call setup completed properly.

At this step, the important point is to confirm that the UE can receive and answer a VoLTE call from the network side. This verifies the MT VoLTE call path, while the previous 666 loopback test verified the MO VoLTE call path.

LTE VoLTE Loopback Run Test2 02

If you want to disconnect the MT call from the WebGUI, click the [-] icon shown in the dialog list.

Once the MT call is established, the call appears in the lower dialog table of the IMS panel. In this example, one MT call is shown with its dialog ID, call type, state, and destination UE information.

To release the call from the Callbox side, click the [-] icon on the left side of the active call entry. After clicking it, the IMS server sends the SIP call release message, and the call on the UE side should be disconnected.

This is useful when you want to terminate the MT call directly from the network side instead of pressing the end-call button on the phone.

LTE VoLTE Loopback Run Test2 03

Log Analysis

Sample Log

For log analysis, enable at least NAS, SIP, and IMS logs in the Amarisoft WebGUI. It is usually easier to apply a filter with NAS, SIP, and IMS so that you can focus only on the messages related to UE attach, IMS PDN setup, IMS registration, and VoLTE call setup.

First, check the IMS/SIP registration sequence. IMS registration normally starts after the UE completes LTE attach and establishes the IMS PDN. In the log, you can see the UE first completing the LTE/NAS procedure, then creating the default EPS bearer, and then starting SIP registration toward the IMS server.

In this example, the SIP registration starts with a REGISTER message from the UE to the IMS domain sip:ims.mnc001.mcc001.3gppnetwork.org. This is the first IMS registration attempt from the UE.

After the first REGISTER, the IMS server replies with 401 Unauthorized. This does not mean that registration failed. It is a normal SIP authentication challenge. The UE then sends another REGISTER message including the proper authentication response.

After the authenticated REGISTER is accepted, the IMS server sends 200 OK. This means the UE has successfully registered to the IMS server.

You can also see an IMS internal message showing that the UE is authenticated, followed by Register information. After this point, the UE is registered to IMS and can use IMS services such as VoLTE.

After IMS registration, the UE may also send a SUBSCRIBE message. This is used for IMS service-related subscription or status information. If the IMS server replies with 200 OK, it means the SUBSCRIBE request was accepted.

The important point in this log is the overall registration flow: the UE sends REGISTER, the IMS server challenges it with 401 Unauthorized, the UE sends REGISTER again with authentication, and finally the IMS server returns 200 OK. Once this sequence is completed, the UE is ready for VoLTE call testing.  

LTE VoLTE Loopback Log 01

When you make a VoLTE call, you can check the INVITE sequence in the SIP/IMS log. This part of the log shows the actual SIP call setup procedure.

In this example, the UE makes a call to tel:666, which is the echo number configured in ims.default.cfg. The first important SIP message is INVITE. This message is sent from the UE to the IMS server to start the VoLTE call setup.

After receiving the INVITE, the IMS server responds with 401 Unauthorized. This is a normal SIP authentication challenge, not a failure. The UE then sends another INVITE with the proper authentication information.

After that, the IMS server starts the call progress procedure. You can see provisional SIP responses such as 183 Session Progress and 100 Trying. These messages indicate that the call setup is progressing and that the media negotiation is being prepared.

During this process, you may also see NAS and RRC messages related to dedicated EPS bearer activation. This is expected for VoLTE because the network may create a dedicated bearer for IMS voice media with the required QoS setting.

Once the call is accepted, the SIP log shows 200 OK. Then the UE sends ACK. At this point, the SIP call setup is completed, and the RTP voice media path is established. For the echo call, the Callbox loops the RTP media back to the UE.

When the call is disconnected, you can see the BYE message in the SIP log. BYE is used to release the SIP call session. After BYE, the other side responds with 200 OK, confirming that the call release has been completed.

So the main VoLTE call flow shown in this log is INVITE, authentication challenge, authenticated INVITE, call progress, 200 OK, ACK, RTP media, BYE, and 200 OK for release. This confirms the full SIP call setup and release procedure for the VoLTE loopback call.

LTE VoLTE Loopback Log 02

© 2025 All rights reserved | Legal notice |