Description
The XML Configuration Access Protocol (XCAP) is a client-server protocol that allows a client to manipulate application-specific configuration data stored on a server as XML documents. In the 3GPP ecosystem, XCAP is primarily used within the IP Multimedia Subsystem (IMS) as the standard mechanism for users to manage their service settings. The protocol is built on top of HTTP/1.1, using standard HTTP methods (GET, PUT, DELETE) to perform operations on XML document nodes, which are identified through a hierarchical URI structure. This design makes it inherently web-friendly and easily integrated with existing internet infrastructure.
An XCAP server hosts one or more "XCAP Application Usages." Each usage defines a specific XML schema (the data model) and a set of conventions for how the XML documents are structured, named, and accessed. For example, the `org.openmobilealliance.pres-rules` usage defines the XML schema for presence authorization rules (also known as the 'ruleset document'). A client, such as a UE or a web portal, can fetch this document via an HTTP GET request to a specific URI, modify the XML content locally, and then upload the changes back to the server using an HTTP PUT. The server validates the changes against the XML schema and the application usage semantics before committing them.
The protocol's power lies in its ability to target specific elements or attributes within an XML document using XPath expressions embedded in the HTTP URI. This allows for fine-grained modifications without needing to transfer and parse the entire document for every change. For instance, a user could modify a single call forwarding rule without affecting the rest of their call handling configuration. In IMS networks, the XCAP server is often co-located with or integrated into the Home Subscriber Server (HSS) or a dedicated service configuration server. The client accesses it via the Ut reference point. Authentication is typically handled using IMS Authentication and Key Agreement (AKA), ensuring that users can only modify their own data. The server also handles concurrency control through HTTP entity tags (ETags) to prevent conflicting updates from different clients.
Purpose & Motivation
XCAP was developed to solve the problem of standardized, remote management of user-specific service data in next-generation telecom services, particularly those based on SIP and IMS. Prior to XCAP, service configuration was often handled through proprietary protocols, interactive voice response (IVR) systems, or carrier-specific web portals with no unified data model. This fragmentation made it difficult to create interoperable handsets and third-party service management applications. The driving force behind its adoption in 3GPP was the need for a flexible, extensible, and internet-standard way for subscribers to manage complex IMS services like Presence, Message Waiting Indication, and Call Barring.
The protocol addresses the limitation of SIP itself, which is a signaling protocol not designed for manipulating persistent configuration data. XCAP provides the missing piece: a standardized data store and manipulation interface. It allows users to configure services from any device with an XCAP client, enabling a consistent experience across mobile phones, PCs, and web browsers. Its use of XML and HTTP was a strategic choice to leverage widely understood technologies, reducing implementation complexity and fostering a rich ecosystem of tools and developers. By decoupling service logic (in SIP Application Servers) from service configuration data (in the XCAP server), it created a clean architecture that simplified network management and enabled user empowerment through self-care portals, which became a standard feature of IMS deployments.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (8 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
- SNPN configuration in XCAP MO TS 24.424CR0013
- Adding handling of the UE configuration parameter "Access_Point_Name_Parameter_Reading_Rule" for the UE to read the XCAP APN name parameter from correct input source. TS 24.623CR0079
- Adding non-seamless wifi access type to XCAP_conn_params_policy TS 24.424CR0010
Explore further
Broader topics and technologies where XCAP plays a role.
Defining Specifications
3GPP specifications that define or reference XCAP, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 24.141 vj00 | Presence Service Protocol Details | Rel-19 |
| TS 24.259 vj00 | Personal Network Management (PNM) Protocol Details | Rel-19 |
| TS 24.337 vj00 | IMS Inter-UE Transfer Protocol Specification | Rel-19 |
| TS 24.423 v1850 | NGN PSTN/ISDN Simulation Services Protocol | Rel-8 |
| TS 24.424 vj00 | XCAP over Ut for Supplementary Services MO | Rel-19 |
| TS 24.483 vk00 | MCS Management Objects Configuration | Rel-20 |
| TS 24.484 vk00 | MCS Configuration Management Protocols | Rel-20 |
| TS 24.504 v8m0 | Communication Diversion (CDIV) Protocol Specification | Rel-8 |
| TS 24.543 vk00 | Data Delivery Management for Vertical Applications in 3GPP | Rel-20 |
| TS 24.549 vj20 | SEAL Network Slice Capability Enablement Protocol | Rel-19 |
| TS 24.604 vj00 | Communications Diversion (CDIV) Protocol Spec | Rel-19 |
| TS 24.623 vj00 | XCAP Protocol for Supplementary Services | Rel-19 |
| TS 24.841 v1600 | Presence Service IP Multimedia Subsystem | Rel-6 |
| TS 29.199 v1930 | Call Notification Web Service Specification | Rel-9 |
| TS 32.808 v1800 | Common User Profile Storage Framework | Rel-8 |