XCAP Support

The following diagram illustrates Sentinel VoLTE’s XCAP architecture within the IMS:

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 VoLTE 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. Sentinel VoLTE provides the XCAP Server rather than the Authentication Proxy (AP) in the 3GPP architecture.

Sentinel VoLTE’s XCAP server application requires that the Ut/HTTP Requests have been Authenticated before reaching the XCAP application. Un-authenticated requests are rejected. Authentication may be achieved through use of the Sentinel Authentication Gateway product, or by using a separate Authentication Proxy.

The Sentinel Authentication Gateway is co-located with the XCAP server application rather than being a discrete AP. See Sentinel Authentication Gateway’s Architecture Overview for further information.

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:

The specifications assign special meaning to these ‘active’ attributes when the attribute in the document does not exist:

Regardless of the active flag’s state (nonexistent, true, or 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 true or false).

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.

The Sentinel XCAP server is a layer on top of the existing provisioning services and runs alongside the Sentinel REST machine API. XCAP is defined using REST principles and the implementation uses much of the same technology as the Sentinel REST API. It can be co-deployed with the Sentinel REST Provisioning API, and web human user interface, like this: