The XCAP Server is a software component that runs inside a web application called Rhino Element Manager (or REM for short).
It uses OpenCloud’s Sh Cache Microservice to communicate with the HSS.
|
For information on this piece of the Sentinel VoLTE product architecture, please see XCAP Support. |
Example XCAP queries
XCAP Query Examples provide several examples of XCAP queries to get and modify the simservs document.
Sh Cache Microservice Client configuration
The Sh Cache Microservice Client stack must be configured before running the XCAP server. See Configuring the Sh Cache Microservice Client for the XCAP Server and REM.
HTTP configuration
The XCAP Server runs inside an HTTP servlet container. To configure it, please see that container’s documentation.
XCAP simservs configuration
The XCAP simservs configuration defines how an XML simservs document (typically coming from a UE) is mapped into an MMTel services document (stored in transparent data in the HSS). This mapping must be configured into the product post install. A tool is available that will populate simservs and XCAP server settings.
The rest of this section describes how to manually configure those same settings, it can be skipped if the tool is used.
This configuration is defined using XPath:
1 |
Select Sentinel ▶ XCAP — Simservs. The resulting panel differs depending on whether a configuration has already been entered for the network operator.
|
||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2 |
For an existing configuration, to enter sufficient XCAP Simservs mappings for IR.92:
A popup prompts you to enter details. 
|
||||||||||||||||||
3 |
With the mapping group created, add mappings:
A prompt displays to enter the mapping. 
Enter these defaults:
|
XCAP simservs extensions mappings
The XCAP server also supports simservs extensions mappings.
This allows arbitrary elements of any transparent user data XML document from the HSS to be mapped to an element in the simservs document under the extensions parent element.
Examples:
| Simservs Path | HSS Document Path |
|---|---|
extensions/operator-flexible-alerting |
complete-flexible-alerting/operator-flexible-alerting |
extensions/operator-flexible-alerting-group |
complete-flexible-alerting/operator-flexible-alerting-group |
In these examples, select parts of operator data from the MMTel services document are being exposed to the UE for viewing and updating via XCAP as part of the Simservs document. Each can be specifically accessed via the simservs XCAP URL with the node selector specified as per the simservs path in the mapping.
Rules for creating extensions mappings
-
An extension simservs path must start with
extensions/. -
The element name after
extensions/can be any alphanumeric string. Special characters are not allowed. -
The element name must be singular. e.g.
extensions/path1is ok, butextensions/path1/path2is not. -
The HSS document path has to match an actual location in the HSS data.
-
Only simple element names can be used for the HSS Document Path. i.e. no positional or attribute selectors.
|
|
Extensions mappings have to be created in the group corresponding to the service indication they are for, alongside the pre-configured mappings. |
XCAP authentication
In the absence of an Authentication Proxy (AP), the XCAP server can be configured to authenticate requests itself using OpenCloud Sentinel AGW. Sentinel AGW provides an implementation of 3GPP GAA (Generic Authentication Architecture) procedures.
For more information, and instructions on configuring the XCAP Server with Sentinel AGW, see the Sentinel AGW Guide.
Normalization
The XCAP server tries to normalize any numbers contained in CDIV rule targets and ICB/OCB conditions before accepting the request. If any number cannot be normalized, the request is rejected. Normalization is done using the Normalization Component.
Normalization can be disabled by setting the following config property, as described in the Provisioning Configuration section.
MMTelCDIV Non-Provisionable Retarget URIs
The MMTelCDIV feature can be configured with a list of NonProvisionableRetargetURIs.
As the name implies, any XCAP request containing a diversion rule with a target equal to a URI on this list, after they are both normalized, is rejected.
Operator Determined Barring
When any request is received, the XCAP server checks if the subscriber is barred from using the XCAP server (due to Barring of Supplementary Services Management being set), or if updating diversion rules, is barred
from registering diverted numbers (Diverted to Address Registration Barring).
To do so, it queries the Sh Cache Microservice for the IMS-ODB-Information service indication.
If the XCAP server determines the request is not allowed, it is rejected with response code 403.
