IMS (IP Multimedia Subsystem)

Overview

The IP Multimedia Subsystem (IMS) is a standardized architectural framework for delivering multimedia services via IP networks. In the context of Android, IMS is the technology that powers Voice over LTE (VoLTE), Voice over Wi-Fi (VoWiFi or Wi-Fi Calling), Video Calling (ViLTE), and Advanced Messaging (RCS). Unlike legacy circuit-switched voice calls (2G/3G), IMS routes voice and data entirely over packet-switched IP networks.

IMS Architecture in Android

Supporting IMS requires a complex interplay between the Android framework, the carrier's network configurations, and the modem.

Historically, IMS implementations were deeply embedded within the proprietary modem firmware. Android provides a standardized framework architecture allowing carriers and device manufacturers to implement IMS services dynamically via an application or system service, rather than relying solely on the modem.

The ImsService

The core of Android's IMS architecture is the ImsService. This is a system service (often provided by the SoC vendor or OEM) that implements the actual IMS signaling and media management logic.

The Telephony framework binds to the ImsService via an AIDL interface (android.telephony.ims.ImsService).

The service exposes specific feature interfaces:

• MmTelFeature (Multimedia Telephony): Manages voice and video calls over VoLTE and VoWiFi, as well as supplementary services (call forwarding, holding).
• RcsFeature (Rich Communication Services): Manages advanced messaging, read receipts, and file transfers.

// Conceptual example of framework interacting with ImsService
ImsManager imsManager = (ImsManager) context.getSystemService(Context.TELEPHONY_IMS_SERVICE);
ImsMmTelManager mmTelManager = imsManager.getImsMmTelManager(subscriptionId);

// Registering to listen for VoLTE availability changes
mmTelManager.registerImsRegistrationCallback(executor, new ImsRegistrationCallback() {
    @Override
    public void onRegistered(int imsRadioTech) {
        if (imsRadioTech == AccessNetworkConstants.TRANSPORT_TYPE_WWAN) {
            // VoLTE is registered and available
        }
    }
});

The SIP Stack and Signaling

IMS relies heavily on the Session Initiation Protocol (SIP) for signaling (setting up, modifying, and tearing down sessions).

Within the ImsService (or delegated to the modem), a SIP stack manages communication with the carrier's IMS core network.

1. SIP INVITE: Sent to initiate a call.
2. SDP (Session Description Protocol): Embedded within the SIP messages to negotiate media capabilities (audio codecs like AMR-WB or EVS, IP addresses, and ports for the RTP streams).
3. SIP 200 OK: Acknowledges successful connection.

Once the SIP signaling establishes the session, the actual audio data is transmitted via Real-Time Transport Protocol (RTP), typically handled directly by the modem's DSP for lower latency and power consumption.

IMS Registration Flow

Before a device can make a VoLTE or VoWiFi call, it must register with the carrier's IMS network.

1. PDN Establishment: The device requests a specific Packet Data Network (PDN) connection from the carrier, dedicated to IMS traffic. This ensures Quality of Service (QoS) prioritization for voice packets over standard internet data.
2. P-CSCF Discovery: The device discovers the IP address of the Proxy Call Session Control Function (P-CSCF), the entry point to the carrier's IMS core.
3. SIP REGISTER: The SIP stack sends a REGISTER request to the P-CSCF.
4. Authentication (IPsec/AKA): The network challenges the device. The device uses cryptographic keys derived from the SIM card (ISIM or USIM) to calculate a response, securing the SIP signaling channel via IPsec.
5. Registration Success: The network confirms registration. The ImsService notifies the Android framework, and the "VoLTE" or "Wi-Fi Calling" icon appears in the status bar.

VoWiFi (Wi-Fi Calling) specific handling

VoWiFi utilizes the exact same IMS architecture, but routes the IP traffic over Wi-Fi instead of the cellular LTE/5G network.

Because Wi-Fi networks are untrusted, the device establishes an ePDG (Evolved Packet Data Gateway) IPsec tunnel. All SIP signaling and RTP media are encrypted and tunneled through the public internet to the carrier's ePDG, securely bridging the device into the carrier's core network.

The ImsService monitors signal strengths to perform seamless handovers (VCC - Voice Call Continuity) between Wi-Fi and Cellular networks without dropping the active call.

Debugging IMS

Debugging IMS failures (like dropped VoWiFi calls or failure to register for VoLTE) requires analyzing SIP traffic and carrier configurations.

Carrier configurations dictate exactly how the ImsService behaves (e.g., which SIP timers to use, whether to prefer Wi-Fi or Cellular). These are managed by the CarrierConfigManager.

# Dump IMS service state, registration status, and active features
adb shell dumpsys telephony.ims

To see the actual SIP signaling, engineers rely on modem traces or radio logs, looking for SIP error codes (e.g., SIP 403 Forbidden indicating authentication failure, or SIP 488 Not Acceptable Here indicating codec negotiation failure).