In the context of IMS (IP Multimedia Subsystem) and SIP (Session Initiation Protocol), User IDs are crucial identifiers that facilitate user authentication, session management, and routing of multimedia services. These identifiers are integral to the functioning of IMS and SIP, as they ensure that the correct user is associated with the correct services, and that signaling messages are appropriately routed.

Types of User ID

Understanding the different types of User IDs in the IP Multimedia Subsystem (IMS) and Session Initiation Protocol (SIP) is essential for grasping how modern communication networks manage user interactions. These User IDs are specialized identifiers that serve various roles, from ensuring secure user authentication to accurately routing calls, messages, and multimedia services. Each type of User ID—whether public, private, temporary, or session-specific—plays a unique role in the seamless operation of communication systems. These identifiers enable the network to not only recognize and differentiate users but also to protect their privacy and maintain the integrity of their communication sessions. By categorizing User IDs into different types, IMS and SIP can efficiently manage the complexities of multiple user identities, dynamic session requirements, and the diverse service needs of users, ensuring a personalized and secure communication experience for all.

Private User Identity (IMPI)

Private User Identity (IMPI) is essentially the passport of the IMS (IP Multimedia Subsystem) world. It is used strictly by the network to verify who the user is, rather than to show how other people reach that user.

It is helpful to explain the IMPI as an internal identity used for trust, validation, and subscription binding, while the public identity is used for actual service reachability.

Core Characteristics of IMPI

• Purpose: The IMPI is primarily used for authentication and authorization. When a device tries to join the IMS network, the IMPI is checked against the credentials stored in the HSS (Home Subscriber Server).
• Visibility: The IMPI is not used for routing calls or messages to the user. It is generally hidden from anything outside the core network nodes.
• Storage: The IMPI is securely stored on the UICC, whether that is a physical SIM or an eSIM, and it is not normally modifiable by the user.

IMPI vs. IMPU: Key Differences

In technical documentation, it is important to clearly distinguish the IMPI from the IMPU (IP Multimedia Public Identity). The IMPI is for network authentication, while the IMPU is for public service identity.

Mapping Relationships

One of the most important concepts in a visual tutorial is the one-to-many mapping relationship. A user typically has one unique IMPI, but that IMPI can be associated with multiple IMPUs.

This allows a single authenticated device or subscription to support multiple public personas, such as a business number and a personal number linked to the same SIM or subscriber profile.

Public User Identity (IMPU)

Following up on the private identity, the Public User Identity (IMPU) is the visible counterpart. It is the address that other users and services actually use to reach you in the IMS network.

Understanding the IMPU

Based on the image provided, the IMPU is the user’s addressable identity within the IMS environment. It is the identity exposed to other users and to application services for actual communication.

In practical terms, other users and network services use the IMPU to interact with the subscriber. Its main role is to support routing for calls, messages, and other IMS communications.

In SIP signaling, the IMPU appears in requests such as INVITE, MESSAGE, and REGISTER to identify the user in a reachable and service-facing form.

Format and Structure

The IMPU is designed to be both human-readable and routable within the SIP infrastructure. It is commonly represented in two main formats.

1. SIP URI: This looks similar to an email address, for example sip:username@domain.com.
2. TEL URI: This represents a standard telephone number, for example tel:+1234567890.

The IMPI-IMPU Relationship

One important point for technical documentation is that the relationship between IMPI and IMPU is not one-to-one.

A single IMPI, which is the private identity, can be associated with multiple IMPUs, which are the public identities.

This gives the subscription flexibility. A single authenticated account can have multiple reachable addresses, such as different phone numbers or SIP addresses, all tied back to the same subscriber identity.

P-Preferred-Identity

The P-Preferred-Identity is a header field in SIP that indicates the user’s preferred identity for outgoing requests. This identity is used by the network when setting the user’s identity in outgoing messages, such as the From header in an INVITE.

• Format: The P-Preferred-Identity can be in the form of a SIP URI or a TEL URI, depending on the user’s preferred way of being identified.
• Usage: This identity is used in cases where the user has multiple public identities (IMPUs) and wants to ensure that a specific one is used when initiating a session. It allows users to control which of their identities is presented to the recipients of their communications.

The P-Preferred-Identity is a specific SIP header field that gives a user control over their outgoing identity.

Usage and Functionality

• Identity Selection: It indicates the user's preferred identity for outgoing requests.
• Network Role: The network uses this header to set the user's identity in outgoing messages, such as populating the From header in an INVITE request.
• Format Flexibility: It can be formatted as either a SIP URI or a TEL URI.
• User Control: It is particularly useful when a user has multiple IMPUs and wants to specify which one is presented to the recipient of a call or message.

Summary Comparison

P-Asserted-Identity

The P-Asserted-Identity is a header field used by the network to assert the identity of the user who is sending a SIP request. It is added by the network after authenticating the user and is trusted by downstream network elements.

• Format: The P-Asserted-Identity is usually in the form of a SIP URI or TEL URI and is often the same as or derived from the IMPU.
• Usage: This identity is used for call routing, billing, and presenting the caller ID to the recipient. It ensures that the identity presented in SIP signaling is verified by the network, preventing identity spoofing.

The P-Asserted-Identity is a header field added by the network to assert and verify the identity of the person sending the request.

• Network Trust: It is added only after the network has authenticated the user, making it a trusted identifier for downstream network elements.
• Format: It is usually formatted as a SIP URI or TEL URI, and is often derived directly from the user’s IMPU.
• Security & Billing: It is used for call routing, billing, and presenting verified caller ID to the recipient in order to prevent identity spoofing.

Comparison: Preference vs. Assertion

Contact URI

The Contact URI is the precise address that identifies the specific device being used during a SIP session. While other identities such as the IMPU represent the user, the Contact URI represents the actual device location currently being used for communication.

The Contact URI Concept

The Contact URI acts like a mailing address for a device during a session. It tells the network exactly where the user can be reached for the duration of that communication.

Definition and Usage

• Function: It specifies the exact address where a user can be reached for the entire duration of a session.
• Placement: It is a mandatory component included in both SIP REGISTER and INVITE messages.
• Routing: It is critical for ensuring that SIP requests and responses are routed back to the correct device.
• Mobility: It ensures that incoming communications reach the user at their current location, even as they move or their network changes.

Format and Structure

The Contact URI is a SIP URI that typically contains two main elements.

• The Device Address: The specific IP address and port number of the User Equipment (UE).
• The User Identity: The username associated with that device, for example sip:username@device-ip:port.

Key Comparison: Contact URI vs. IMPU

URI and Address Assignment

The high-level concept of URI and Address Assignment in 3GPP TS 24.229 revolves around how a User Equipment (UE) derives the identities needed to register with the IMS network based on the available hardware, credentials, or provisioning method.

Core Logic of Identity Derivation

The IMS registration process requires three primary identifiers: the Private User Identity (IMPI), the Public User Identity (IMPU), and the Home Network Domain Name. The case hierarchy defines a fallback mechanism in which the UE moves from dedicated hardware-based identities to software-based or algorithmically generated identities when necessary.

Case 1: ISIM is Available

This is the preferred case for IMS operation. The UE does not need to guess or generate information because everything is already provisioned in the IP Multimedia Services Identity Module (ISIM).

• Source: The UE extracts the IMPI, IMPU, and domain name directly from ISIM parameters defined in TS 31.103.
• Result: This provides high security and user-specific identities.

Case 2: USIM is Available (No ISIM)

When a standard mobile SIM, meaning a USIM, is present but does not contain a dedicated ISIM application, the UE must construct its IMS identity from the mobile subscription data.

• Source: The UE uses the IMSI (International Mobile Subscriber Identity) from the USIM to derive a temporary IMPU and a private identity.
• Requirement: The UE provides the private identity, temporary public identity, and home domain by mapping the USIM data into IMS identity formats.

Case 3: Only IMC (IMS Credentials) Available

In cases where no physical SIM card is present, such as some IoT devices or certain software clients, the UE relies on IMS Credentials (IMC) provisioned in device memory.

• Source: Parameters are manually or remotely provisioned directly into the IMC.
• Requirement: The UE provides the private identity, public identity, and home domain name based on this secure software storage.

Case 4: No ISIM, USIM, or IMC

This is the final fallback case. It is often used for emergency calls or limited-service situations where no subscriber credentials are available.

• Source: The UE algorithmically generates its identities.
• Mechanism: The UE creates a temporary public identity, a private identity, and a domain name using device-specific identifiers such as IMEI, according to the rules defined in TS 23.003.

Summary Table for Technical Documentation

Requirement from 3GPP 23.228

3GPP 23.228 describes about this topic in E.3 Address and identity management concepts. Based on the 3GPP 23.228 requirements, the high-level concept for identity management when a dedicated ISIM application is missing from the UICC is centered on automated derivation from existing mobile credentials.

If the UICC does not contain an ISIM application, The Private User Identity shall be derived from the USIM's IMSI

• The format of the Private User Identity derived from the IMSI is specified in TS 23.003
• A Temporary Public User Identity shall be derived from the USIM's IMSI, and shall be used in SIP registration procedures. The format of the Temporary Public User Identity is specified in TS 23.003

If the UICC does not contain an ISIM application, the network and the UE rely on the USIM's IMSI, which is the International Mobile Subscriber Identity, to generate the IMS identifiers required for IMS registration.

• Private User Identity (IMPI):
  •   This must be derived directly from the USIM's IMSI.
  •   The specific structure and derivation rules are defined in TS 23.003.
• Temporary Public User Identity (Temporary IMPU):
  •   Similar to the private identity, a temporary public identity is derived from the USIM's IMSI.
  •   This temporary identity is mandatory for use during SIP registration procedures.
  •   The exact format for this temporary IMPU is also governed by TS 23.003.

Why This Matters

This derivation mechanism ensures that a device with a standard 3G, 4G, or 5G SIM card, meaning a USIM, can still access IMS services such as VoLTE or VoNR even if the card was not specifically manufactured with an IMS application, namely an ISIM.

Relationship to Signaling

Once derived, these identities play specific roles in the SIP headers already discussed.

•   The Temporary IMPU is used in the initial REGISTER request.
•   After registration, the user can use the P-Preferred-Identity header to select a specific identity for outgoing calls when multiple IMPUs are assigned.
•   The network then verifies this against the registered data and inserts the P-Asserted-Identity, ensuring that the caller identity is authenticated and helping prevent spoofing.

Which one is used ? IMPI or IMPU ? or MSISDN

The selection of which identity (IMPI, IMPU, or MSISDN) to use during registration often depends on the specific requirements of the Service Provider.

NOTE : When there are multiple items stored in IMPU list, which one should be used for the steps shown above ? - It usually depends on the requirement from Service Provider.

For example : A service provider may set the requirement as follows.

• i) If a provisioned SIM is used, use the first item in IMPU list
• ii) If a non-provisioned SIM is used, use the second item in IMPU list

NOTE :This is only a general rule..  there may be variations of UE ID application for each steps depending on the requirement from each service provider. For example, Some service provider put MSISDN ID at higher priority and require UE to use this ID for registration.

Requirement from IR 92

IR 92 2.2.1 SIP Registration Procedures specifies as follows.

All IMS public user identities provided in the implicit registration set used for VoLTE by the IMS core network must be alias user identities and must include a Tel URI. The following public user identity must be assigned to the implicit registration set used for VoLTE and it must be used by the UE when registering for VoLTE:

• a) When ISIM is used, the public user identity in the first (or only) record in the Elementary File in the ISIM
• b) The temporary public user identity derived from the IMSI.

No other implicit registration set must be used for VoLTE.

This can be summarized as follows :

VoLTE Public Identity Requirements

For a User Equipment (UE) to successfully register for VoLTE services within the IMS core network, the following rules must be followed:

• Identity Type: All IMS public user identities in the implicit registration set must be alias user identities.
• Mandatory Format: The identities must include a Tel URI.

Source Selection Hierarchy

The specific public user identity that the UE must use when registering for VoLTE is determined by the type of application available on the UICC:

• When ISIM is Available: The UE must use the public user identity found in the first (or only) record in the Elementary File (EF) within the ISIM.
• When ISIM is NOT Available: The UE must use the temporary public user identity derived from the IMSI.

Key Constraints

• Exclusivity: The specification explicitly states that no other implicit registration set must be used for VoLTE.
• Consistency: This ensures that the network and the UE are always aligned on which "face" of the user is being presented for Voice over LTE services, regardless of the underlying hardware.