Sentinel VoLTE includes the following features to support XCAP.
|See also the XCAP Query Examples.|
The following diagram illustrates Sentinel VoLTE’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 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.
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 VoLTE as an image contains nginx acting as a reverse proxy to support this base URL. If Sentinel VoLTE 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.
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:
The diagram above includes these components:
The HTTP clients can be:
a web browser
a provisioning application
an XCAP client (such as XCAP-enabled user equipment connecting through an aggregation proxy).
The HTTP servlet container configuration is used to specify the IP interfaces and port numbers that the REM Web application is running on. Therefore, if the port that the REM application is running on is to be reconfigured, the HTTP servlet container needs restarting.
The REM web application is packaged as a web archive (WAR). It can be deployed into various HTTP servlet containers. OpenCloud tests the application in Apache Tomcat and Jetty HTTP servlet containers.
The three HTTP-triggered components (web user interface, REST Provisioning API, and XCAP server) are triggered from the same port. The HTTP Request URI is used to distinguish which component processes a certain request.
|Each of the components has their own security configuration.|
Each REM application includes one or more instances of the Sh Cache Microservice Client stack. Each instance is scoped to the Rhino cluster it is associated with. The Rhino cluster is selected when the REM user selects a “Rhino instance” to log into.
Each instance of the Sh Cache Microservice Client stack can select a different instance of the Sh Cache Microservice to connect to, each of which can be configured for a different Destination Realm. In other words, a single Diameter stack instance can be configured to connect to more than one distinct HSS.
Each instance of the Sh Cache Microservice Client stack is shared by both the XCAP server and parts of the web user interface.
Each Rhino cluster has connectivity to various systems. (That connectivity is not shown in the diagram above.)