ePDG : VoWiFi (Voice over WiFi)

This tutorial is to show how to setup, configure and operate VoWiFi (Voice over WiFi) with Amarisoft Callbox. What is VoWiFi ?  Simply put, it is IMS Voice Call through WiFi without using cellular network like LTE or NR.  Putting it other way, in terms of high level functionality is similar to VoLTE (Voice over LTE) or VoNR (Voice or NR), the only difference is the type of communication channel being used for the IMS voice call. As name implies, WiFi channel (instead of LTE or NR) is used for VoWiFi.

Why it requires any special equipment to test ? Everybody would have at least one WiFi AP(Access Point) at home. Can I just use it for the test ?  NO, the situation is not so simple. IMS based Voice Call service provided by Carriers (Network Operators) require very sophiticated security mechanism which is almost same level as the security mechanism in cellular network. To provide this security mechanism over WiFi network, the call should go through a special gateway called ePDG (evolved Packet Gateway). This is why you need special solution for VoWiFi testing. In orther words, you need a special test setup that support ePDG. Amarisoft Callbox has built in ePDG as part of MME(Core Network Package).

The overall procedure for VoWIFI can be illustrated as follows. IMS/SIP procedure happening at the last step is same as regular IMS/SIP voice call. The main difference between VoWiFi and regular IMS/SIP voice call (e.g, VoLTE or VoNR) is the procedure happening before the IMS/SIP procedure.

In case of VoWiFi, following unique procedure happens before IMS/SIP voice call establishment

• IKEv2 (Internet Key Exchange) : Handshaking procedure to authenticate and security setup to ePDG. This is an equivalent to Authentication, Security Mode Command procedure in cellular network (e.g, LTE, NR network)
• Establishing IPSec Tunnels : UE and ePDG establishes IPsec tunnel based on the security settings configured during IKE, through which IMS/SIP traffic is going through.

NOTE : This IKE procedure is pretty complicated and only high level procedure is defined by 3GPP. The full details of each steps are based on RFC. You may refer to this note if you are not familiar with this process and want to get some big picture before jumping into the test procedure.

NOTE : Even before ePDG disvery process is necessary IKE, but this process is not part of this tutorial. Regarding this procedure, refer to this note.

Table of Contents

• ePDG : VoWiFi (Voice over WiFi)
• Test Setup
• Key Configuration Parameters
• Configuration
• Perform the test
• Log Analysis

Test Setup

Test setup for this tutorial is as shown below.  

For this test, a WiFi Access Point (AP) is required. You may use your own AP connected to Callbox PC if you can configure it as described here.  In this test setup, we modified the configuration of the built-in WiFi module of the PC to work as a WiFi AP.

Another essential component for this test in addition to WiFi AP is ePDG. Amarisoft ePDG is implemented (supported) as a part of MME.

The basic configuration to be noted for the WiFi AP is SSID (shown below) since this is the one you need to get your Phone to be connected for the test.

The IP address assigned for the WiFi AP is 10.42.0.1. You may assign any IP but the IP should be consistantly used as epdg bining address in the configuration file.

Key Configuration Parameters

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

• ims_vops_eps
• ims_vops_5gs_n3gpp
• epdg
• bind_addr
• certificate
• esp_duration
• ike_duration
• omit_auth_in_first_auth_rsp
• ike_encryption_algo_list
• ike_integrity_algo_list
• ike_prf_list
• ike_dh_group_list
• esp_encryption_algo_list
• esp_integrity_algo_list
• esp_dh_group_list
• dpd_timer_value
• mobike
• ike_generate_error
• exchange
• error
• idr_for_emergency
• dont_fragment
• additional_ue_auth_type

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 gnb-sa-vowifi.cfg which is modified from gnb-sa.cfg

I also used ims.default-voWifi.cfg modified from ims.default.cfg and mme-ims-voWifi.cfg modified from mme-ims.cfg. The default ue_db-ims.cfg was replaced by ue_db-ims-vowifi.cfg in this test.

Change the configuration in gnb-sa-vowifi.cfg as follows.

I changed plmn because usually most of the phone enables VoWiFi dedicated for specific carriers.  Specify PLMN for the specific carrier that your DUT support VoWiFi (NOTE : Make it sure that you use proper USIM with matching this imsi)

In mme-ims-voWifi.cfg , enable all the parameters that are related to VoWiFi. ims_vops_eps and ims_vops_5gs_n3gpp are the essential parameters for this test, but ims_vops_5gs_3gpp is also enabled as well for possible other test (e.g, VoNR). Also note that plmn is changed from the default since the plmn on cell configuration is changed.

Then add epdg configuration. In this test, we configured a single parameter bind_addr in epdg object. This is the most basic configuration and you can fine controll the behavior of ePDG in various different way using the configuration parameters listed here

Lastly change (or add) UE sim information in ue_db-ims-vowifi.cfg to match with your SIM card.  

Perform the test

Since this test is voice over WiFi only which does not require any involvement of eNB or gNB, running procedure on gNB/eNB side is very simple (almost nothing).  Just run 'lte service' and make it sure that PLMN is configured as required.

Wait until UE WiFi get connected to the WiFi AP configured for ePDG.  If the UE shows the configured SSID properly, it indicates UE went through the initial ePDG process (IKEv2) properly.

Now try to make a voice call to IMS Voice Loopback number and see if the call gets connected.

Log Analysis

Sample Log

Unlike the log analysis for other tutorial, the log analysis in this tutorial is NOT about 3GPP since the traffic is going through the non-3GPP network which is WiFi and ePDG.

NOTE : many of the screen capture shown here shows only the first part of a ePDG packet which does not show the full contents. But the description/comments are the summary for the full contents of the packets. So I would recommend you to look into the entire contents of the log by opening up the log file and compare it with the description/comments shown here.

NOTE : If you are not familiar with ePDG protocol (especially IKE protocol), you may refer to this note and get some big picture first.

First of all, for this test you need to collect log from almost all components - MME,N3WF,IMS for this test. ENB is not directly involved in this test, but no harm to collect the log.

N3IWF stands for Non 3GPP Inter Working Function which is related to ePDG only for now.

The first two IKEv2 message shown here may not be seen in every test since they are failed attempt for SA_INIT.

This is the first message in an IKE Phase 1 negotiation (Main Mode) where the initiator proposes multiple combinations of cryptographic algorithms and parameters for securing the IKE Security Association (SA), along with NAT traversal capabilities.

Short summary of the contents of the message are :

• IKE Phase 1 Initiation: The Exchange type: 2 and the presence of Security Association and Key Exchange payloads indicate this is the start of an IKE Phase 1 negotiation.
• Security Proposals: The initiator is offering a variety of options for encryption (ENCR), pseudo-random functions (PRF), integrity/authentication (INTEG), and Diffie-Hellman groups (D-H) to the responder.
• NAT Traversal: The inclusion of NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notify messages signals that the initiator is prepared to handle Network Address Translation (NAT) issues that might arise during the VPN connection establishment.

This is an IKE Phase 1 response message where the responder acknowledges the initiator's proposals and selects specific security parameters (AES-CBC encryption, HMAC-SHA1 integrity, and DH Group 14) for establishing the IKE Security Association (SA). It also includes NAT traversal capabilities.

Short summary of the contents of the message are :

• IKE Phase 1 Response:
• The Exchange type: 2 and Flags: 32 (R) clearly indicate this is a response message in the second step of IKE Phase 1 negotiation.
• The responder's SPI (0x1BEC5D6ABED9DB4E in this case) is now present, signifying its participation in the SA establishment.
• Security Parameter Selection
• The Security Association payload with Num transforms: 4 shows the responder has chosen a specific set of security algorithms and parameters from the initiator's proposals. which includes
• ENCR_AES_CBC for encryption with a 128-bit key.
• PRF_HMAC_SHA1 for generating pseudo-random keys.
• AUTH_HMAC_SHA1_96 for integrity and authentication.
• DH_GROUP_14 for the Diffie-Hellman key exchange, which will be used to create the shared secret key for the IKE SA.
• Key Exchange Payload:
• This payload contains the responder's Diffie-Hellman public value, essential for completing the key exchange process with the initiator.
• NAT Traversal:
• The presence of NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notify messages indicates that the responder is also prepared to handle potential NAT issues in the network.

This is the list of the derived keys (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr) generated during IKE Phase 1 (previous two steps).

 This is an IKE Phase 2 response message where the responder authenticates itself using EAP-AKA and confirms its identity as "ims."

Short summary of the contents of the message are :

• IKE Phase 2 Response: The Exchange type: 3 and Flags: 32 (R) indicate this is a response within IKE Phase 2, likely following a Phase 2 initiation message from the initiator.
• Encrypted and Authenticated Payload: This payload carries the core of the message, protected by encryption and integrity checks derived from the IKE SA established in Phase 1.
• Identification: The responder identifies itself using an FQDN (Fully Qualified Domain Name) "ims."
• EAP-AKA Authentication: This is the key part of the message. The responder is using EAP-AKA, a specialized authentication method commonly used in mobile networks, to prove its identity to the initiator. The payload includes:
• EAP AKA Challenge request: This indicates the responder is likely requesting authentication information from the initiator.
• AT_RAND, AT_AUTN, AT_MAC: These are specific parameters used in the EAP-AKA authentication exchange.
• Device Identity Notification: The DEVICE_IDENTITY notification might convey additional information about the responder's device type or capabilities.

This is an IKE Phase 2 response message where the initiator completes the EAP-AKA authentication exchange by providing its response to the challenge issued by the responder.

Short summary of the contents of the message are :

• IKE Phase 2 Response: The Exchange type: 3 and Flags: 8 (I) indicate this is a response within IKE Phase 2, sent by the initiator.
• Encrypted and Authenticated Payload: This payload carries the core of the message, protected by the security mechanisms negotiated in Phase 1.
• EAP-AKA Authentication: This is the key part of the message. The initiator is completing the EAP-AKA authentication exchange initiated by the responder in the previous message. The payload includes:
• EAP AKA Challenge response: This signifies the initiator's response to the EAP-AKA challenge.
• AT_RES: The "result" parameter within EAP-AKA, containing the initiator's calculated response to the challenge.
• Attribute type unknown: 134: This might indicate a vendor-specific or non-standard EAP-AKA attribute.
• AT_MAC: The message authentication code, ensuring the integrity and authenticity of the EAP-AKA response.

This is an IKE Phase 2 response message where the responder signals successful completion of the EAP authentication exchange.

Short summary of the contents of the message are :

• IKE Phase 2 Response: The Exchange type: 3 and Flags: 32 (R) indicate that this is a response within IKE Phase 2, sent by the responder.
• Encrypted and Authenticated Payload: This payload carries the core of the message, protected by the security mechanisms negotiated in Phase 1.
• EAP Success:  This is the key part of the message. It signals that the EAP authentication exchange, likely initiated by the responder in a previous message, has concluded successfully. This means both sides have successfully proven their identities to each other.

This is an IKE Phase 2 request message where the initiator is for adding the Child SA negotiation and potentially including additional configuration requests. (NOTE : Since the payload data is not decoded in the log, we don't know exactly what this message is for. I am just guessing it is for child SA addition by looking subsequent messages)

• IKE Phase 2 Request: The Exchange type: 3 and Flags: 8 (I) indicate this is a request within IKE Phase 2, sent by the initiator.
• Encrypted and Authenticated Payload: This payload carries the core of the message, protected by the security mechanisms negotiated in Phase 1.
• Authentication Payload: This payload likely contains authentication information related to the Child SA negotiation. It could be a confirmation of the responder's authentication or some additional authentication data related to the Child SA itself.
• No Next Payload: This suggests that this might be the final message in this particular IKE exchange, or that any further payloads are optional and not included in this specific message.

This is the list of key material for an ESP Security Association (SA) used in IPsec. This process is likely part of establishing a secure IPsec tunnel within an existing IKE session.

Adding a IPSec Tunnel with following IP and Security Parameters

• Tunnel Endpoints:
• Tunnel src=10.42.0.1:500: The source IP address and port of the IPsec tunnel.
• Tunnel dst=10.42.0.241:500: The destination IP address and port of the IPsec tunnel.
• Traffic Selectors:
• src=0.0.0.0:0/0: This indicates that all traffic from any source IP address and any port is included in this SA.
• dst=192.168.4.2:0/32: This specifies that only traffic destined for the IP address 192.168.4.2 and any port is included in this SA.
• Security Parameters:
• spi=0xdec51d3: The Security Parameter Index (SPI) used to identify this specific SA.
• auth=hmac-sha-1-96 0x8b76b7cdfa56d0daaade148bb829774a10fe40cb: The authentication algorithm (HMAC-SHA1-96) and the corresponding authentication key.
• cipher=aes-cbc 0x12acbbbac55ef9aae85d76c89d6b0243: The encryption algorithm (AES-CBC) and the corresponding encryption key.

Adding a IPSec Tunnel with following IP and Security Parameters. this time for the opposite direction of the IPsec tunnel compared to the previous message.

• Tunnel Endpoints (Reversed from previous message):
• Tunnel src=10.42.0.241:500: The source IP address and port of the IPsec tunnel (note this was the destination in the previous message).
• Tunnel dst=10.42.0.1:500: The destination IP address and port (previously the source).
• Traffic Selectors (Reversed from previous message):
• src=192.168.4.2:0/32: This indicates that only traffic from the IP address 192.168.4.2 and any port is included in this SA.
• dst=0.0.0.0:0/0: This specifies that traffic destined for any destination IP address and any port is included.
• Security Parameters:
• spi=0x296ce5ac: The Security Parameter Index (SPI) for this SA (different from the previous one).
• auth=hmac-sha-1-96 0x73eb09699b0e143916b84286868241eabda65070: The authentication algorithm and key.
• cipher=aes-cbc 0x4da428751ed36eba3285a9d76f6aa7da: The encryption algorithm and key.

This is for adding an IPsec Security Association (SA) specifically for IPv6 traffic. (NOTE : In this case, the end point is still the same IPv4 address as previous case, but the traffic going through the tunnel is IPv6 packet)

• Tunnel Endpoints:
• Tunnel src=10.42.0.1:500: The source IP address (IPv4) and port of the IPsec tunnel.
• Tunnel dst=10.42.0.241:500: The destination IP address (IPv4) and port of the IPsec tunnel.
• Traffic Selectors (IPv6):
• src=[::]:0/0: This indicates that all traffic from any IPv6 source address and any port is included in this SA. [::] represents the unspecified IPv6 address (equivalent to 0.0.0.0 in IPv4).
• dst=[2001:468:3000:1:2001:468:3000:1]:0/64: This specifies that only traffic destined for the IPv6 subnet 2001:468:3000:1::/64 and any port is included in this SA.
• Security Parameters:
• spi=0xdec51d3: The Security Parameter Index (SPI) used to identify this specific SA.
• auth=hmac-sha-1-96 0x8b76b7cdfa56d0daaade148bb829774a10fe40cb: The authentication algorithm (HMAC-SHA1-96) and the corresponding authentication key.
• cipher=aes-cbc 0x12acbbbac55ef9aae85d76c89d6b0243: The encryption algorithm (AES-CBC) and the corresponding encryption key.

This is for adding an IPsec Security Association (SA) specifically for IPv6 traffic.  this time for the opposite direction of the IPsec tunnel compared to the previous message.

• Tunnel Endpoints (Reversed):
• Tunnel src=10.42.0.241:500: The source IP address (IPv4) and port of the IPsec tunnel (note this was the destination in the previous IPv6 SA message).
• Tunnel dst=10.42.0.1:500: The destination IP address (IPv4) and port (previously the source).
• Traffic Selectors (IPv6, Reversed):
• src=[2001:468:3000:1:2001:468:3000:1]:0/64: This indicates that only traffic from the IPv6 subnet 2001:468:3000:1::/64 and any port is included in this SA.
• dst=[::]:0/0: This specifies that traffic destined for any IPv6 destination address and any port is included.
• Security Parameters:
• spi=0x296ce5ac: The Security Parameter Index (SPI) for this SA (different from the previous IPv6 SA).
• auth=hmac-sha-1-96 0x73eb09699b0e143916b84286868241eabda65070: The authentication algorithm and key.
• cipher=aes-cbc 0x4da428751ed36eba3285a9d76f6aa7da: The encryption algorithm and key.

This is an IKE Phase 2 response message where the responder is finalizing the Child SA negotiation by authenticating itself, confirming the IPsec SA parameters, and providing configuration information like IP addresses and DNS server details.

Followings are the summary of the contents

• IKE Phase 2 Response: The Exchange type: 3 and Flags: 32 (R) indicate this is a response within IKE Phase 2, sent by the responder.
• Encrypted and Authenticated Payload: This payload carries the core of the message, protected by the security mechanisms negotiated in Phase 1.
• Authentication Payload: This payload contains the responder's authentication data, confirming its identity to the initiator.
• Security Association Payload: This payload confirms the IPsec SA parameters, including the SPI (0x296CE5AC), encryption algorithm (ENCR_AES_CBC), and integrity algorithm (AUTH_HMAC_SHA1_96).
• Configuration Payload: This is a key part of the message. The responder is providing configuration information to the initiator, which may include:
• INTERNAL_IP4_ADDRESS: An IPv4 address assigned to the initiator within the VPN.
• INTERNAL_IP4_NETMASK: The subnet mask associated with the IPv4 address.
• INTERNAL_IP6_ADDRESS: An IPv6 address with a prefix length assigned to the initiator.
• INTERNAL_IP4_DNS: IPv4 address of a DNS server.
• INTERNAL_IP6_DNS: IPv6 address of a DNS server.
• P_CSCF_IP4_ADDRESS and P_CSCF_IP6_ADDRESS: Addresses for the Proxy-Call Session Control Function (P-CSCF), a component in IMS (IP Multimedia Subsystem) networks.
• Traffic Selectors: These payloads define the traffic that will be protected by the IPsec SA. In this case, it appears to be traffic from the assigned IP addresses (both IPv4 and IPv6) to any destination.

Once all the steps of IKE and SA addition are properly done, UE is supposed to send SIP Register and complete all the registration process. (NOTE : If you don't see SIP registration from UE in VoWiFi settings, you'd better go through all the IKE and SA addition procedure described above and make it sure that the entire procedure is done properly)

Once SIP Registration went through properly and you make a call from the UE, UE should send SIP INVITE message and go through the call setup process.