The following diagram illustrates Sentinel Authentication Gateway’s XCAP architecture within the IMS:
|XCAP’s use within IMS is described in 3GPP TS 33.222.|
The Ut interface provides a user’s device with the ability to manipulate a configuration document. This document may contain user specific service settings such as privacy setting, communication barring and forwarding rules. TS 33.222 does not define how the MMTel-AS stores this document. However, 3GPP TS 29.364 defines a standardised XML schema for representing both the User and Operator settings for these services. TS 29.364 also defines the XML schema for transporting the user specific settings via the XCAP interface. This is called the "simservs" document. TS 29.364 also defines that an Application Server can store this service data on the HSS through the Sh interface as transparent data.
Sentinel AGW provides an XCAP server web application that implements the XCAP protocol towards the UE, and supports the XML schemas for user and operator data defined in TS 29.364, and stores and retrieves this information according to 29.364 in the HSS using Sh Transparent Data.
The diagram above shows several XCAP servers, as MMTEL-AS and Other-AS.
The Sentinel Authentication Gateway is co-located with the XCAP server application rather than being a discrete AP. See [Architecture Overview] for further information.
If the XCAP host is running on xcap.server.net, the base XCAP URL for the XCAP Server application will be
The standard distribution of Sentinel AGW as an image contains nginx acting as a reverse proxy to support this base URL. If Sentinel AGW is installed in any other manner, the base XCAP URL for the XCAP Server application will be
unless a similar reverse proxy is manually installed.
There is a subtlety worth noting with respect to the per-service "active" attribute in the User portion of each MMTel Service.
The active attribute is specified as an optional boolean attribute in the XML schema for the simservs and MMTel-Services documents.
In an XML document, this means they can have three possible values:
does not exist (that is, attribute is not declared)
exists with the value
exists with the value
The specifications assign special meaning to these ‘active’ attributes when the attribute in the document does not exist:
during session processing - logic should treat a nonexistent attribute as though the value is
XCAP requests from the user equipment are subject to special rules when the attribute does not exist:
A request is not allowed to directly or indirectly create or otherwise modify a nonexistent
A request is allowed to configure other portions of that service’s data.
Regardless of the
active flag’s state (nonexistent,
false) a request can configure other portions of the service.
For example, if Communication Diversion has no ‘active’ attribute, a request can configure communication diversion rules.
In summary, if an active flag is nonexistent this means that the user equipment cannot disable the feature.
If the operator wants the user equipment to be able to enable or disable the feature, then the ‘active’ attribute should exist (and therefore be either
If a user’s MMTel-Services document does not contain a named service (for example,
<communication-diversion>) the UE cannot indirectly or directly create this element.
Child elements of a named service can be modified/created/removed, provided that the named service is present.
The IMS Operator Determined Barring service has both session processing and XCAP related behaviour. The XCAP related Operator Determined barring behaviour enables the operator to disallow a user’s capability to view and change their service settings.