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) in LTE and N3IWF (Non-3GPP InterWorking Function) in NR . This is why you need special solution for VoWiFi testing. In orther words, you need a special test setup that support ePDG /N3IWF . Amarisoft Callbox has built in ePDG / N3IWF 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.

Table of Contents

• VoWiFi (Voice over WiFi)
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Configuration
• Perform the test
• Log Analysis

Introduction

Voice over WiFi (VoWiFi) represents a significant advancement in telecommunications, enabling voice calls over WiFi networks through the IP Multimedia Subsystem (IMS) framework rather than relying on traditional cellular technologies like LTE or NR. VoWiFi leverages the robust, packet-based architecture of IMS and the flexibility of WiFi connectivity to deliver high-quality voice services, particularly in environments where cellular coverage is weak or unavailable. Unlike VoLTE (Voice over LTE) or VoNR (Voice over NR), VoWiFi requires the integration of specialized security mechanisms, such as Internet Key Exchange version 2 (IKEv2) and IPSec tunneling, to ensure carrier-grade security and authentication that matches the rigor of cellular networks. This is achieved through the involvement of a N3IWF (Non-3GPP InterWorking Function), which acts as a secure bridge between the user's WiFi connection and the operator's core network. Testing and operating VoWiFi thus necessitate a sophisticated setup, including equipment like the Amarisoft Callbox, which comes with integrated N3IWF functionality as part of its Core Network Package. Understanding the interplay of these technologies—SIP/IMS signaling, IKEv2 handshakes, secure IPSec tunnels, and the role of the ePDG—is critical for successfully configuring and operating VoWiFi services. This tutorial provides a comprehensive guide to setting up, configuring, and operating VoWiFi using Amarisoft Callbox, elucidating the detailed technical processes involved and the significance of each architectural component within the broader telecommunications ecosystem.

• Context and Background
  • Voice over WiFi (VoWiFi) is an IMS-based voice service that allows users to make and receive voice calls using WiFi networks instead of cellular radio access (LTE/NR).
  • Key Architectural Components:
    • IMS (IP Multimedia Subsystem): The core framework for delivering IP-based voice and multimedia services.
    • ePDG (Evolved Packet Data Gateway): Securely connects the WiFi network to the mobile operator’s core network, handling authentication and encryption.
    • Amarisoft Callbox: A comprehensive test platform with built-in core network functions, including ePDG, MME, and IMS.
  • Security and Authentication:
    •   VoWiFi requires secure authentication and encrypted communication via IKEv2 and IPSec tunnels, replicating cellular-grade security over WiFi.
  • Technical Challenges:
    •   Unlike basic WiFi access, VoWiFi must implement carrier-grade authentication and security, which mandates specialized equipment and configuration.
• Relevance and Importance
  •   VoWiFi expands voice service coverage, especially in areas with limited cellular signal, by utilizing existing WiFi infrastructure.
  •   It is essential for operators and testers to understand the unique security and signaling requirements to ensure interoperability and compliance with 3GPP and IETF standards.
  •   The Amarisoft Callbox enables comprehensive testing and validation of VoWiFi features, accelerating development and deployment cycles.
• Learning Outcomes
  •   Gain hands-on experience setting up and configuring VoWiFi on Amarisoft Callbox, including N3IWF and IMS components.
  •   Understand the end-to-end flow of a VoWiFi call: from WiFi attachment, IKEv2 authentication, IPSec tunnel establishment, to IMS/SIP-based call setup.
  •   Learn to troubleshoot common VoWiFi deployment issues, particularly those related to security, authentication, and signaling.
• Prerequisite Knowledge
  •   Familiarity with IP networking concepts, including WiFi configuration and basic network troubleshooting.
  •   Understanding of cellular core network architecture, particularly IMS, MME, and SIP signaling.
  •   Basic knowledge of security protocols such as IKEv2 and IPSec is beneficial.
  •   Experience with Amarisoft Callbox or similar telecom test platforms will aid in following the tutorial steps effectively.

Summary of the Tutorial

This tutorial outlines the procedures for conducting a Voice over WiFi (VoWiFi) test using a WiFi Access Point (AP) and an N3IWF implemented via Amarisoft callbox. The test validates the establishment of secure IPsec tunnels using IKEv2 protocol and the successful registration and operation of IMS voice services over WiFi without involvement from eNB/gNB radio access.

• Test Setup:
  • Configure a WiFi AP, either by using a built-in PC WiFi module or your own AP, ensuring proper SSID and IP address assignment (e.g., 10.42.0.1).
  • Implement ePDG functionality as part of the MME using Amarisoft, binding to the APs IP address.
  • Modify relevant configuration files: gnb-sa-vowifi.cfg, ims.default-voWifi.cfg, mme-ims-voWifi.cfg, and ue_db-ims-vowifi.cfg to enable VoWiFi parameters and ensure correct PLMN and SIM settings.
  • Run ‘lte service’ on the gNB/eNB and ensure correct PLMN configuration, but no further eNB/gNB involvement is needed.
• Test Execution Procedure:
  • Connect the UE (User Equipment) to the configured WiFi AP, confirming SSID visibility to ensure successful connection and initiation of the ePDG process (IKEv2).
  • Initiate a voice call from the UE to the IMS Voice Loopback number to verify call connectivity over WiFi.
• Detailed IKEv2/IPsec Tunnel Establishment:
  • Capture and analyze logs from MME and IMS (eNB log is optional).
  • Follow the IKEv2 negotiation sequence:
    • Phase 1 Initiation: Initiator proposes cryptographic parameters and NAT traversal options.
    • Phase 1 Response: Responder selects encryption/integrity parameters (e.g., AES-CBC, HMAC-SHA1) and confirms NAT traversal capabilities.
    • Key Derivation: Keys (SK_d, SK_ai, etc.) are derived for securing further exchanges.
    • Phase 2 Exchange: Authentication is performed using EAP-AKA with identity verification (e.g., FQDN "ims").
    • Phase 2 Completion: Both initiator and responder complete authentication, and the responder signals EAP success.
  • Child SA negotiation is performed to establish IPsec tunnels for both IPv4 and IPv6 traffic, with detailed traffic selectors, security parameter indexes (SPIs), and cryptographic keys assigned for each direction.
  • Responder finalizes the Child SA, providing configuration payloads such as assigned internal IP addresses, DNS, and P-CSCF addresses for IMS operation.
• SIP Registration and Call Setup:
  • After IPsec SAs are established, the UE initiates SIP registration to the IMS core.
  • If registration is successful, the UE proceeds to send a SIP INVITE for establishing a VoWiFi call.
  • If SIP registration fails, review the IKE and IPsec tunnel setup steps for issues.
• Log Analysis:
  • Review packet captures to verify correct IKEv2 exchanges, successful EAP-AKA authentication, proper IPsec tunnel establishment, and the presence of SIP REGISTER and INVITE messages.
  • Ensure that the full content of logs is analyzed for comprehensive troubleshooting.

Summary: The procedure verifies end-to-end VoWiFi operation by establishing a secure connection over WiFi using ePDG and IPsec, authenticating the UE with EAP-AKA, and validating IMS call flow through SIP signaling—all without radio access network involvement.

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. (NOTE : Regarding on configuring the WiFi module to work for this test, refer to this wiki)

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
• reject_notify_list
• error
• data
• 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, IMS for this test. ENB is not directly involved in this test, but no harm to collect the log. (NOTE : N3IWF connection is ON in the following screen, but it is not relavent for this tutorial. so you don't need to turn on N3IWF for this test)

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.