The IP Multimedia Subsystem (IMS) is the platform behind VoLTE, VoWiFi and VoNR. It uses SIP to register users and set up sessions, and relies on the packet core to carry signalling and media with the right quality of service. This article walks through the key components and procedures, with a focus on what engineers need when investigating faults.

Why IMS matters

4G and 5G networks are packet-only. There is no circuit-switched domain to carry calls, so voice is delivered as a service on top of IP. IMS provides the control layer for that service: it knows who the subscriber is, where they are registered, which services they are entitled to and how to route a call to its destination — whether that is another mobile user, a fixed-line network or an emergency service.

The core components

  • P-CSCF (Proxy CSCF) — the device’s first point of contact in IMS. It secures signalling with the device, compresses or inspects SIP where configured, and interacts with the policy function so that the right bearers or QoS flows are created for voice media.
  • I-CSCF (Interrogating CSCF) — the entry point into the home network. During registration it queries the HSS to find or assign a suitable S-CSCF.
  • S-CSCF (Serving CSCF) — the central session controller. It authenticates the user, holds the registration state, downloads the user profile and applies initial filter criteria (iFC) to involve application servers.
  • HSS — stores IMS subscription data and authentication credentials. The CSCFs reach it over the Diameter Cx interface (in 5G deployments, the UDM may provide equivalent functions).
  • Telephony Application Server (TAS / MMTel AS) — provides supplementary services such as call forwarding, call waiting and barring, invoked from the S-CSCF over the ISC interface.
  • Media and interworking elements — such as the MGCF and BGCF for breaking out to circuit-switched networks, and border controllers for IP interconnect.
IMS registration message flow The UE sends REGISTER to the P-CSCF, which forwards it through the I-CSCF to the S-CSCF. The S-CSCF obtains authentication vectors from the HSS and returns 401 Unauthorized with a challenge. The UE sends a second REGISTER with its response, and the S-CSCF returns 200 OK. UE P-CSCF I-CSCF S-CSCF HSS REGISTERREGISTERREGISTER Cx MARMAA (vectors) 401 Unauthorized (challenge) REGISTER (response to challenge) 200 OK — registered
Simplified IMS registration. The I-CSCF also queries the HSS (UAR/UAA) to locate the S-CSCF, and the second REGISTER passes through the P-CSCF and I-CSCF; both steps are omitted here for clarity.

IMS registration

Before a device can make or receive calls, it registers with IMS. On a mobile network this normally uses IMS-AKA authentication:

  1. The device discovers its P-CSCF (typically from the packet core during IMS PDN or PDU session setup) and sends a SIP REGISTER.
  2. The I-CSCF asks the HSS which S-CSCF should serve the user, then forwards the request.
  3. The S-CSCF fetches authentication vectors from the HSS and replies with 401 Unauthorized, containing a challenge.
  4. The device verifies the network, computes its response and sends a second REGISTER. With IMS-AKA, IPsec security associations are set up between the device and the P-CSCF to protect subsequent signalling.
  5. The S-CSCF validates the response, downloads the user profile and returns 200 OK. The device then usually subscribes to the registration event package so it is told about changes such as network-initiated deregistration.

A registration failure usually shows itself as a repeated 401, a 403 Forbidden, a timeout, or a missing second REGISTER. Comparing traces on the device side and the P-CSCF side quickly shows whether the problem is in authentication, IPsec, routing to the S-CSCF or the subscriber profile.

Call setup with SIP

A mobile-originated VoLTE call follows a recognisable pattern:

  • INVITE carries an SDP offer listing the codecs the device supports — commonly AMR-WB and EVS for HD voice, with AMR-NB as a fallback.
  • 100 Trying confirms that each hop received the request.
  • 183 Session Progress returns the SDP answer. Where preconditions are used, the call does not alert until both ends confirm that resources (radio and core bearers) are reserved; this exchange uses PRACK and UPDATE.
  • 180 Ringing indicates that the called party is being alerted.
  • 200 OK to the INVITE means the call has been answered, and the caller confirms with ACK.
  • BYE ends the call.

Behind the scenes, the P-CSCF tells the policy function about the negotiated media, and the packet core creates a dedicated bearer for voice (QCI 1 in LTE, or a 5QI 1 QoS flow in 5G), while IMS signalling uses its own bearer (typically QCI 5).

VoWiFi

VoWiFi (Wi-Fi Calling) delivers the same IMS services over Wi-Fi networks the operator does not control. The device builds an IPsec tunnel using IKEv2 to an ePDG (evolved Packet Data Gateway), authenticating with EAP-AKA against the operator’s subscriber data. Once the tunnel is up, the device reaches its P-CSCF through it and registers with IMS as usual.

Common VoWiFi issues include blocked IKE or IPsec traffic on the Wi-Fi network (UDP ports 500 and 4500), ePDG selection problems, and handover between Wi-Fi and LTE that does not behave as expected.

Troubleshooting checklist

  • Is the device registered? Many “call failures” are really registration problems.
  • Read the final SIP response. Codes such as 403, 404, 480, 486, 488 and 503 each point in a different direction.
  • Follow the Call-ID across traces from different nodes to reconstruct one call end to end.
  • Check SDP for codec mismatches, incorrect media addresses or ports — the usual causes of one-way or no audio.
  • Confirm bearer setup. If preconditions never complete, the voice bearer may not have been created.
  • Check application server involvement when supplementary services behave unexpectedly; the iFC in the user profile controls which AS is invoked.

Summary

IMS is a SIP-based control layer that registers users, routes sessions and invokes services, while the packet core provides the bearers that carry signalling and media. Understanding the registration and call-setup flows — and how IMS interacts with the access network — is the foundation for integrating, testing and supporting VoLTE, VoWiFi and VoNR.

KL-UK provides IMS, VoLTE and VoWiFi engineering support, including SIP signalling analysis and voice service validation. For how voice fits into 5G, see Understanding 5G Standalone Architecture.

Published by KL-UK on . This article is for general information and does not replace vendor documentation or the relevant 3GPP specifications.